Menu do struktur AVCHD (BR) - jak to robić?

Sydon777

Klub HDTV.com.pl
vip
Wkrótce po ukazaniu się mojego postu o istnieniu błędów nawigacji w multiAVCHD (http://www.hdtv.com.pl/forum/500317-post853.html), Dean wykrył błąd nawigacji ujawniający się przy większej niż 10 liczbie tytułów, opisał przyczynę jego powstania i dokonał odpowiedniej poprawki w build 744 (Doom9's Forum - View Single Post - multiAVCHD - author AVCHD/Blu-ray for Blu-ray players, camcoders & Viera TV or HD-DVD). Byłem więc przekonany, że sprawa błędów nawigacji jest zamknięta. Jednak dla upewnienia się, że istotnie tak jest zrobiłem powtórkę kompilacji opisanej uprzednio i okazało się, że wynik nadal jest obarczony błędami nawigacji. Już po tytule 11 (ostatnim z pierwszej struktury AVCHD/BR) została umieszczona strona menu głównego dla tytułu 25 wraz z przynależnymi stronami rozdziałów (z tej drugiej dodawanej struktury). Jeżeli się jednak uruchamia ów 25 tytuł, to w rzeczywistości odtwarza się plik filmowy przynależny do tytułu 12 czyli tak jak powinno być. Również rozdziały wywoływane ze stron tytułu 25 uruchamiają odtwarzanie odpowiednich rozdziałów z tytułu 12. Podobne sytuacje powtarzają się przy innych tytułach, czyli niektóre strony menu zostały błędnie przypisane do nie swoich plików filmowych.
Wygląda więc na to, że Dean jeszcze nie usunął wszystkich błędów nawigacji i nadal na pojawiające się na początku kompilacji pytanie "This compilations contains a menu. Do you to keep it from re-encoding if possible?" odpowiedź "Yes" może prowadzić nie do oszczędności czasu, a do powstania wielu kłopotów-bo trzeba bedzie powtórzyć całą kompilację.
 

Sydon777

Klub HDTV.com.pl
vip
Brak reakcji na powyższy post jest zniechęcający, ale nie jest to przecież "walka z wiatrakami" - piszę o konkretnych problemach, które powinny być poprawione, aby multiAVCHD nie był programem "kalekim" przez jakieś "stupid bugs". Poświęciłem ogromną ilość czasu, aby spopularyzować ten program u nas, bo ogólna idea programu i sposób jej realizacji jest wart tego. Teraz gdy już tak mało potrzeba, aby multiAVCHD był pod każdym względem wyjątkowy, nie mogę tak poprostu wycofać się z dalszego zabiegania, aby tak właśnie się stało. I nie chodzi tu tylko o moją wygodę użytkowania tego programu, bo algorytmy jego funkcjonowania wystarczająco dobrze poznałem, aby napisać uzupełniające własne programy, które korygują to, co moim zdaniem jest konieczne do zmiany. Chodzi mi też o to, aby wszycy ci, którzy uwierzyli, że jest to program wyjątkowy, mogli z niego korzystać bez większych problemów i z pełną satysfakcją.
Nie czekając na usunięcie opisanych już błędów, powrócę więc jeszcze szczegółowo do problemów, które wcześniej były tylko sygnalizowane.
Unikam pisania tekstów w języku angielskim, bo to dla wielu użytkowników może być niezrozumiałe i zniechęcające, a jak wskazuje praktyka, Dean (znając istotę rzeczy) bez trudności rozumie opisywane problemy. Jest tylko kwestia, czy zechce post przeczytać i się do niego odnieść.
Wspominałem już wielokrotnie o tym, że dla materiału z kamer HD często występuje zjawisko podwójnego obrazu przy tworzeniu ikon dla różnych stron menu . Jest to słaba strona multiAVCHD i wymaga od użytkownika dużego nakładu pracy, aby ręcznie (w Title properties) wyszukać takie klatki, które dają ostry obraz lub po pierwszej kompilacji trzeba ręcznie podmieniać rozmyte lub rozdwojone ikony na własne (wcześniej przygotowane) i powtórnie kompilować. Ale z ikonami jakoś sobie można poradzić, natomiast bardzo niska jakość ruchomego tła w menu jest dla użytkownika trudna do zakceptowania. Obraz ruchomego tła jest nieporównywalnie gorszy od obrazu HD, na którym bazuje. Obawiam się, że Dean nawet nie ma świadomości występowania takich problemów przy materiale filmowym z kamer HD, które zapisują przecież filmy z przeplotem.
Już dawno sugerowałem, aby ikony do menu tworzone były nie w oparciu o dwa półobrazy danej klatki filmowej, lecz w oparciu o półobraz dla linii parzystych lub półobraz dla linii nieparzystych (odd lines, even lines). To samo można powiedzieć o tworzeniu obrazów ruchomych. Ponieważ pisanie scryptów AviSynth nie jest mi obce (jest bardzo użyteczne przy tworzeniu własnych filmów 3D HD), sprawdziłem swoją koncepcję z uwzględnieniem tych zapisów, które aktualnie wykorzystuje Dean. Zacząłem od ikon, do których Dean wykorzystuje skrypt "chap-extract.avs". W tym skrypcie należy podmienić poniższą instrukcję (ścieżka dojścia jest tu przykładowa):
v=directshowsource("H:\AVCHD\BDMV\STREAM\00000.m2ts",audio=false).ChangeFPS(25.000).LanczosResize(640,360).ConvertToRGB24()
przez np następującą sekwencję instrukcji:
directshowsource("h:\avchd\bdmv\stream\00000.m2ts",audio=false).ConvertToRGB24()
SeparateFields
L=SelectEven
directshowsource("h:\avchd\bdmv\stream\00000.m2ts",audio=false).ConvertToRGB24()
SeparateFields
P=SelectEven
Interleave(L,P)
AssumeFieldBased
v=Weave.ChangeFPS(25.000).LanczosResize(640,360)
Oczywiście porównałem wyniki ze skryptu oryginalnego i tego zmodyfikowanego wg powyższej propozycji dla tego samego materiału filmowego. Otrzymane nowe ikony są naprawdę bez zarzutu, niezależnie z jakiego miejsca się je pobiera.
Ilustruje to dobrze przykładowa para ikon utworzonych z tej samej klatki filmowej w oparciu o skrypt oryginalny i skorygowany:

Ikona ze skryptu oryginalnego.jpg

Ikona ze skryptu skorygowanego.jpg

Obrazki są mało ciekawe, ale je zamieszczam, bo występują tu pionowe słupki i narciarze na dalszym planie, co wyraźnie akcentuje rozdwojenie się obrazu ze skryptu oryginalnego.
Zachęcony tym rezultatem postanowiłem przeanalizować skrypt, jaki Dean wykorzystuje do tworzenia strony głównej dla menu jednotytułowego z ruchomym tłem. Doszedłem do wniosku, że wystarczy odpowiednio podmienić instrukcję:
ovbg=directshowsource("h:\avchd\bdmv\stream\00000.m2ts", audio=false).ChangeFPS(24000,1001).convertfps(24000,1001)
Ja powyższy zapis zastąpiłem nstępującą sekwncją instrukcji (dla uproszczenia pominąłem zmianę FPS) :
directshowsource("h:\avchd\bdmv\stream\00000.m2ts",audio=false)
SeparateFields
L=SelectEven
directshowsource("h:\avchd\bdmv\stream\00000.m2ts",audio=false)
SeparateFields
P=SelectEven
Interleave(L,P)
AssumeFieldBased
ovbg=Weave
return ovbg
Wyniki działania powyższego skryptu sprawdziłem w GraphEdit oraz VirtualDubMod i muszę powiedzieć, że są naprawdę znakomite. Tło ruchome jest porównywalne z oryginałem HD i mnie całkowicie satysfakcjonuje. Wreszcie znika to okropne rozdwajanie się obrazu.
Nie zamieszczam przykładowych filmów porównawczych, otrzymanych z powyższych skryptów, bo zajmują dużo miejsca, a każdy użytkownik wykorzystując powyższe zapisy, może je otrzymać we własnym zakresie ze swojego materiału filmowego.
Nie uruchamiałem całego skryptu Deana, który jest dość długi, ale tam dalej już nie ma nic co mogłoby zepsuć ten obraz bazowy. Pozostałe części skryptu bowiem dotyczą:
- tworzenia 8 wycinków filmu z video, które tu ma nazwę ovbg
-złożenia tych 8 sekwencji filmowych w klip (zachowując kolejność ich występowania zdefiniowaną w template)
-zdefiniowania wszystkich napisów dla strony głównej menu i umieszczenia ich na określonych pozycjach ekranu (wszystkie napisy są traktowane jako Subtitle w ovbg).

No i teraz jest prośba do Deana, aby uwzględnił powyższe sugestie (opcjonalnie), bo to naprawdę zasadniczo zmieni wygląd menu dla materiału filmowego z kamer HD.
Wiemy, że Dean jest teraz mocno zaangażowany w poszukiwanie przyczyn, dlaczego struktury zaprojektowane w multiAVCHD v 4.0 i następnie nagrane na płytki, nie są poprawnie odtwarzane w niektórych odtwarzaczach BR, mimo że z v 3.0 odtwarzane były poprawnie. Musimy mieć też na uwadze, że posiadacze kamer HD to jednak margines ogółu użytkowników multiAVCHD. Nie dziwi zatem, że Dean coraz rzadziej gości na naszym forum, nie mając wystarczającego wsparcia z tej strony.
Niezależnie od tego czy nasze uwagi zostaną uwzględnione czy nie, aktualnie analizuję szczegółowo, jak korzystając z dostępnej wersji multiAVCHD ominąć wszelkie problemy, a jednocześnie:
-poprawić jakość strony głównej menu z ruchomym tłem
-umożliwić przebudowę i rozbudowę istniejących struktur bez nadmiernej straty czasu na ich wielokrotną kompilację
Mam już wstępną koncepcję jak to robić, ale muszę to wszystko jeszcze sprawdzić praktycznie. Oczywiście w swoim czasie wszystko szczegółowo opiszę, aby każdy mógł z tego skorzystać.
 

zieloony

New member
super sprawa z tym nierozmytym menu, szkoda że nie czaje jak to zrobiłeś i muszę zaczekać aż Dean to uwzględni- właśnie na to czekam. Zrobiłem swoją strukturę z rodzinnymi filmami i nie zadawala mnie jakość menu zarówno poszczególnych klatek jak i menu ruchomego. I cieszę się że jest szansa że będzie to zrobione.
Dean naprawdę na to czekamy.
 

bluray

Banned
Wielokrotnie pisałem:
[1] Unikalna cecha multiAVCHD to zachowywanie audio HD i obsługa wielu strumieni Audio.
Te unikalne cechy nie są w ogóle potrzebne przy preparowaniu materiałów z kamer.
Dlatego na nim pracuję już tylko przy tytułach muzycznych.

[2] NeroVision: Jego funkcjonalność, prostota, przejżystość, logiczność, skuteczność, zakres narzędziowy NeroVision 5 bije na głowę multiAVCHD.
Więc jeżeli nie ma Audio HD i wielu ścieżek audio to bezwzględnie lepszy jest NeroVision.
To może być powód ograniczonego zainteresowania.
Wyważanie otwartych drzwi ?

PODSTAWOWE MANKAMENTY multiAVCHD:
- brak możliwości zastąpienia ikon tytułów filmowych prostą, aktywną listą w/w tytułów
- brak możliwości zastąpienia ikon rozdziałów prostą listą nazw w/w rozdziałów.
- brak (zupełnie nie zrozumiały) możliwości opracowania własnego TITLE MENU !
A jest przycisk ale wygaszony = pasywny.
TITLE Menu powinno być oknem do dalszego poruszania się w strukturze.

WIęc logika poruszania się powinna być taka:
MAIN MENU pokazuje listę wyboru filmów. Bez setupu. Bez chapterów. Tylko goła lista wyboru.
Czyli taki ekran powitalny ale AKTYWNY !!!
To tu przechodzimy do wybranego filmu.
Jesteśmy teraz w MENU uprzednio wskazanego filmu - tu dopiero mamy:
- wybór audio
- wybór [play all] / [rozdział]

Tymczasem walka trwa na poziomie korelacji opcji główych z opcjami USER na poziomie poszczególnych tytułów.
 

deank

New member
@Sydon: I visit the forum almost everyday. Please understand that sometimes I don't have the nerves to try to understand what GOOGLE translated from polish - it is really confusing.

I encountered the problem with 'not reencoding the menus' but I have no idea why is that. I didn't change anything (or at least I thought so). I'll get to it soon.

About the quality of the motion menus - I made some changes today to get better looking encodes... Of course it does not include the deinterlacing for interlaced (like camcoder) sources.

You must understand that multiAVCHD can use various video formats and framerates and it is really hard to cover everything.

For example using 25fps for background but 23.976 for the title thumbnail... Or even worse: 59.94p for background and 29.97i for the motion thumbnail. Can you imagine how many paths the logic has to follow only to create the motion menu.

In a case when framerates don't match or cannot be converted to the selected TV system framerate (23.976p or 50i) it causes ALL to crash.

I'll see what I can do about the deinterlacing for the background. I'm already using similar avisynth commands when transcoding/uncropping interlaced sources.

Believe me - it is not easy at all to cover all bases.

Dean
 

bluray

Banned
Dzisiaj eksperymentowałem z ruchomym menu.
Bo tak jest w CREAM HD DVD.
Program padał mi cały dzień. Jakieś 40 prób.
Ok. 25 razy. Dzień w plecy.
To właśnie jest powód braku zainteresowania powszechnego.

Niezrozumiełe przesunięcia treści. Szkielet wersji ginie wraz z kasowniem nieudanej wersji.
Niewiadomo dobrze gdzie sie sejwuje projekt.
Template ? Bałagan. A automatu zachowuje sie ta sama nazwa zestawu danych tpd. itp.
Autor powinien zapoznać się jak te groźne dla nas procedury są zabezpieczane w:
- SONY VEGAS
- NeroVision
i tym im podobnych aplikacją.

Nie może być, żeby tylko posiadacz tytułu [doktora] bezpiecznie mógł tworzyć menu do swoich archiwalnych materiałów filmowych !

Po prostu grożny bałagan i można nawet stracić źródłowe materiały.
Brak zabezpieczeń alertowych na właściwym poziomie.

A to, że nikt od miesięcy nie odnosi się do moich "jedynie słusznych" wniosków wskazuje, że użytkownik sobie a autor sobie.
NIe tędy droga.
Ale jest blisko.
ps. zdaję sobie sprawę, że zwykle nad takim projektem pracuje zespół (opłacanych godziwie) kilkuset wybitnych speców.
A tu jeden DEAN z grupą beta-testerów. To za mało.
 
Ostatnia edycja:

deank

New member
Please, if you're not satisfied with multiAVCHD just use any other application like Sony Vegas or Nero. I never forced anyone to use or test multiAVCHD. I started all this because I needed a simple tool for my needs and I rarely use it.

* I don't have an HD camcoder
* I don't have a Blu-ray disc burner
* I don't have downloaded HD / Blu-ray audio or video discs
* I don't have an AVCHD capable Viera TV

After your post I don't really plan on posting here soon. multiAVCHD has its forum + the doom9 forum. If anyone has problems or questions he can ask there in English. It was a courtesy to visit your forum for the last year.

Dean
 

Sydon777

Klub HDTV.com.pl
vip
Ja to widzę znacznie bardziej optymistycznie. Główne procedury programu multiAVCHD są dopracowane, stabilne i z nimi nie ma żadnego problemu. Natomiast wraz z wprowadzeniem jakieś nowej opcji, nieuniknione jest pojawienie się jakichś błędów, ale te są szybko usuwane. Pewnym problemem dla nowych użytkowników może być brak instrukcji obsługi programu, ale wkrótce taka pojawi się. Coś takiego już finalizuje Adub (ten od instrukcji dla SD DVD w multiAVCHD). Niedługo zapewne będzie można także tworzyć teksty w GUI w narodowych językach, bo prace nad v 4.0 wg. mnie dobiegają końca.
Ja wiem (jak mało kto) z jakimi trudnościami Dean musiał się zmierzyć pisząc multAVCHD zarówno w v. 3.0 jak i 4.0. Od samego początku śledzę rozwój tego programu i cały czas z pełnym przekonaniem podkreślam jego wyjątkowość. Determinacja Deana, upór, wiedza i bezgraniczne poświęcenie swego czasu na jego udoskonalanie, jest czymś równie wyjątkowym jak sam program. A do tego ta niesamowita presja niezliczonych użytkowników z różnorodnymi problemami i potrzebami, a często i z brakiem zrozumienia. Zdecydowana większość problemów i postulatów, które zgłaszaliśmy została uwzględniona i to często w znacznie szerszym zakresie niż było sugerowane. Wiem, że nie było to łatwe, ale zostało zrobione. Zyskali na tym wszyscy użytkownicy (obecni i przyszli), bo multiAVCHD stał się wielostronnym narzędziem uwzględniającym potrzeby różnych użytkowników. Może liczebnie użytkownicy kamer HD są marginesem, ale ta grupa będzie szybko się rozrastała i nowi użytkownicy będą mogli korzystać od początku z tego niezwykłego programu uwzględniającego już ich potrzeby i w większym stopniu będą wspierać jego autora.
Dzisiaj chcę zwrócić uwagę na pewną wyjątkową cechę multiAVCHD w v. 4.0, która nie została jeszcze doceniona i wykorzystana. Konstrukcja programu multiAVCHD w v. 4.0 jest znacznie korzystniejsza dla użytkownika, gdyż otrzymywane wyniki stosunkowo łatwo można modyfikować wg własnych potrzeb. Im dłużej analizuję nowy układ programu i sposób realizacji obliczeń w odniesieniu do wersji 3.0, tym wyraźniej widzę jak zasadniczo i jak bardzo korzystnie zostało wszystko zmienione.
Już korzystając z programu w wersji 3.0 podjąłem różne próby modyfikacji wyników i częściowo to opisałem. Dotyczyło to min usprawnienia nawigacji w strukturze AVCHD/BR przy dużej ilości tytułów. Do dnia dzisiejszego korzystam z takiej modyfikacji, bo brak kompatybilności wstecznej projektów z multiAVCHD nie pozwala na szybką konwersję struktury starej do nowej, gdzie mamy już do dyspozycji dwupoziomowe menu dla tytułów, które zasadniczo ułatwia nawigację.
Podstawowa trudność w modyfikacji wyników z wersji 3.0 wynikała z faktu umieszczenia kodów nawigacyjnych (IGS) wewnątrz kontenera .m*ts. Są programy, które umożliwiają "wyjęcie" takiego strumienia w drodze demuksowania. Nie potrafi tego zrobić tsMuxer, ale potrafi TsRemux. Natomiast nie znalazłem programu do muksowania IGS. Pamiętam jak długo Dean poszukiwał sposobu na lokowanie takich kodów w kontener. Jakoś to w końcu rozwiązał, ale jeszcze później gdzieś wspominał, że są problemy, bo trzeba wpisywać ręcznie "byte by byte". Program multiAVCHD w v. 4.0 zasadniczo zmienił sytuację dla użytkownika. Teraz IGS nie są pakowane do kontenera łącznie ze strumieniem video, ale są zapisywane jako wydzielone strumienie, choć nadal w kontenerze .m*ts. To zasadniczo ułatwia wszelkie modyfikacje struktur AVCHD/BR. Dzisiaj opiszę jak ten fakt można w prosty sposób wykorzystać do utworzenia w swojej strukturze AVCHD/BR dowolnego ruchomego menu, bez jakichkolwiek ograniczeń i to w najwyższej jakości HD.
Do tego celu ja tworzę strukturę AVCHD/BR, korzystając z template, które zamieściłem w jednym z poprzednich postów.
Następnie w jakimś programie edycyjnym NLE tworzę klip video. Materiał video może być dowolną kompozycją fragmentów video z tytułu, który ma reprezentować. Można tu zastosować dowolne przejścia między tymi fragmentami lub jakiekolwiek inne efekty cyfrowe. Nie ma żadnych ograniczeń co do charakteru tego video. Na obraz nakładamy dowolne napisy, które informują jaki to jest tytuł. Tu oczywiście też nie ma żadnych ograniczeń co do miejsca ulokowania napisów, wielkości, rodzaju czcionki, kolorów, ilości tekstu itp. Mogą to być nawet napisy animowane. Do tego wszystkiego dokładamy stosowną muzyczkę. Następnie cały klip zapisujemy jako .m*ts i wstawiamy w miejsce tego, który wytworzył multiAVCHD zgodnie ze wspomnianym template. Jeszcze potrzebujemy plik informacyjny .CPI (.clpi) dla naszego tytułu. Aby go uzyskać wczytujemy plik menu tytułowego do tsMuxer i tworzymy strukturę BDMV, gdzie potrzebny nam plik zostanie zapisany. Teraz wystarczy mu zmienić nazwę na wynikającą z położenia naszego tytułu, wstawić w strukturę AVCHD/BR i ją uruchomić. To wszystko. Nie musimy się martwić żadnymi kodami IGS - one są tam gdzie być powinny i zadbają o to, aby nasze nowe menu było całkowicie funkcjonalne z punktu widzenia nawigacji, niezależnie na jakiej pozycji znajduje się nasz tytuł, w którym zmieniamy stronę główną menu.
Zawsze o czymś takim marzyłem. Żadnych ograniczeń, prosto, szybko i w dowolnym czasie, a do tego pełne HD (bez szarpania, rozdwajania itp). I to już nie jest życzenie, ale coś co każdy użytkownik multAVCHD może już teraz zrobić.
Być może Dean pisząc wersję 4.0 nawet nie myślał, że coś takiego będzie można robić. Ale to nie koniec. Możemy jeszcze więcej - możemy swoje struktury modyfikować na inne sposoby, o czym w stosownym czasie.
Czyli potęga multiAVCHD nie wynika tylko z jego uniwersalności, ale także z pewnej otwartości. Użytkownik może wpływać na końcową strukturę AVCHD/BR nie tylko poprzez sam program, ale także poprzez łatwo dającą się zrealizować modyfikację tej struktury wynikowej. Tę indywidualną modyfikację wyników można realizować pośrednio tylko dlatego, że cała organizacja pracy programu przystosowana została do łatwego wprowadzania wszelkich zmian w jego wnętrzu.
 

zieloony

New member
hmm z tego co piszesz to da się jakoś osiągnąć lepszą jakość ruchomego menu. (mi najbardziej pasuje ruchome menu XMB z widocznymi ikonami 3 tytułów poprzednich i 3 następnych)
Szkoda tylko że nic nie czaje z tego co napisałeś.
Poczekam aż Dean to zmieni w multiAVCHD
 

Sydon777

Klub HDTV.com.pl
vip
Oczywiście na forum może wypowiadać swoje myśli i poglądy każdy w dowolnej formie. Źle się jednak stało, że Dean poczuł się urażony. Nie dziwię się zresztą jego reakcji. Był naszym wyjątkowym gościem i powinniśmy to sobie bardzo cenić i zabiegać o rodzaj jego patronatu nad tym wątkiem. Nie wiem czy słowo "przepraszam" coś tu zmieni. Mam nadzieję, że przez ten kilkunasto-miesięczny okres zmagania się z programem i jego użytkownikami, Dean wyrobił sobie pewną odporność osobistą i potrafi zachować dystans zarówno do problemów jaki i rzeczy niemiłych. Jego aktywna współpraca na tym forum, dla mnie była bardzo cenna i inspirująca. Dobrze jest mieć świadomość, że ktoś taki jak Dean jest gdzieś w tle i może w każdej chwili coś dopowiedzieć, wyjaśnić czy też skorygować. Ja zakładam, że nadal tak będzie.
Wspomniałem, że Adub finalizuje rodzaj instrukcji do multiAVCHD. Już to co opracował zostało udostępnione w sieci: Blu-ray to DVD with multiAVCHD Screencast | Adubvideo Jest to rodzaj instrukcji filmowej, w której autor objaśnia jak krok po kroku postępować przy tworzeniu SD-DVD z materiału BR. Oczywiście wszystko jest ilustrowane aktywnym ekranem komputerowym. Taka forma przekazu ma charakter uniwersalny. Nawet osoby nie znające języka angielskiego, na podstawie oglądanego filmu (nawet w HD) mogą łatwo zrozumieć co i gdzie należy zrobić, aby uzyskać pożądany efekt. Spodziewałem się, że to nowe opracowanie zrobione przez Adub, wykroczy poza ten wątek z SD-DVD. Sama idea takiego instruktarzu najwyraźniej się spodobała Deanowi, bo poprosił o wskazówki jego wykonania i prwadopodobnie podejmie pracę nad opracowaniem podobnej instrukcji dla ogółu zagadnień związanych z multiAVCHD.
 

bluray

Banned
SYDON 777:
[1]
Czyta sę Ciebie jak dzieła Lenina.
Czyli ciężko.

[2]

SD w programie multiAVCHD to jedna wielka POMYŁKA.
Właśnie tego nie chce HD FAN na tym forum i w tej aplikacji.
PERFEKT śpiewał : "Idź precz"
Tak działać.

Na razie tyle.

ps. poziom gniewu autora nie może wpływać na ocenę sktutków pracy setek beta-testerów
, do których zaliczył się zmordowany

BLURAY
 

zieloony

New member
SD w programie multiAVCHD to jedna wielka POMYŁKA.
Właśnie tego nie chce HD FAN na tym forum i w tej aplikacji.

BLURAY

I tu się mylisz. Ktoś kto ma materiały z kamery i dla siebie robi struktury AVCHD może to samo, tą samą aplikacją nagrać na płytkę DVD, dla rodzinki która nie ma odtwarzacza BD.
Ja np. czekałem na taką opcję. (myślę że nie tylko ja)

I mam nadzieję że Dean ochłonie i nadal będzie brał pod uwagę propozycję zmian z naszego forum. Mimo wszystko jest to ważna aplikacja dla posiadaczy kamer HD. Ja osobiście polecam tą aplikację wszystkim którzy są na etapie zakupu kamery HD.
 
Ostatnia edycja:

Tomanek

New member
Popieram kolegów w 100% opcja (SD DVD) jak najbardziej potrzebna i oczekiwana. Wiele osób na forum doom9 pytało kiedy taka opcja będzie dostępna i bardzo dobrze się stało , że jest.
A to, że ktoś jej nie używa nie znaczy że powinno jej nie być.
Tak to już jest w naszym narodzie , że jak Polak za coś zapłaci to będzie wychwalał a jak coś dostanie za darmo to będzie tylko psy wieszał....
Dean bardzo dobrze napisał , że nikt nikogo nie zmusza do używania multiAVCHD jak dla kogoś to zły program to.....
Ja tam raczej uważam , że Dean-owi należą się podziękowania za czas i chęci w tworzeniu czegoś co używamy i należy go zachęcać do dalszej pracy a nie pisać posty które nic nie wnoszą a tylko sieją zamęt.
 

Sydon777

Klub HDTV.com.pl
vip
Ja nie studiowałem dzieł Lenina i nie wiem czy są "ciężkie" do czytania. Studiowałem natomiast różne języki programowania komputerowego i każdy z nich na początku wydawał mi się trudny. Tak też było gdy poznawałem AviSynth, jeszcze w oparciu o anglojęzyczne materiały (teraz są już polskie opracowania np. AviSynth 2.5x). Ponieważ w tym wątku ten specjalizowany język programowania AviSynth często jest wymieniany (i jeszcze będzie) polecam do poduszki lekturę o nim. Może łatwiej będzie zrozumieć o czym piszę. Polecam też ewentualne studiowanie oficjalnych dokumentów o strukturach AVCHD/BR, a nawet instrukcję do multiAVCHD (choć już trochę zdeaktualizowaną) i wówczas zapewne więcej użytkowników będzie chciało się podzielić swoimi przemyśleniami na ten temat. Ten wątek nie ma charakteru rozrywkowego, a że jest potrzebny i czytany świadczą o tym statystyki forum. Tu staramy się omawiać kwestie zupełnie nowe, z którymi przyjdzie nam obcować przez wiele lat. Wszystko co nowe zawsze wydaje się trudne. Ale tu nikt nikogo nie zmusza do czytania czegokolwiek, jak i do użytkowania multiAVCHD czy testowania wprowadzanych nowych opcji. Ja staram się przybliżyć i wyjaśniać pewne kwestie o znaczeniu czysto praktycznym, a także sugerować pewne istotne dla użytkowników tego forum (i nie tylko) korekty programowe.
Przypomniano co śpiewał Perfekt, to warto przypomnieć też, że np. Młynarski śpiewał "Róbmy swoje". Powracam zatem do tematyki wątku.

Poprawa jakości ikon i video w menu multiAVCHD w wyniku korekty skryptów programowych i modyfikacja menu przez wprowadzenie własnego video-clipu do istniejącej strukturyAVCHD/BR, to oczywiście dwie różne metody wzajemnie nie wykluczające się. Korekta skryptów w multiAVCHD umożliwiłaby uzyskanie poprawy jakości wszystkich stron menu w ramach form dotychczas oferowanych przez ten program. Wprowadzenie takich korekt do programu byłoby zatem niezwykle cenne dla użytkownika i dotyczyłoby zawsze wszystkich tworzonych od nowa stron menu. Natomiast modyfikacja menu przez wprowadzenie własnego video-clipu pozwala użytkownikowi utworzenie menu wg całkowicie własnego pomysłu jako full HD i może dotyczyć dowolnie wybranego tytułu w strukturze już istniejącej, bez jej powtórnej kompilacji. Przy okazji omawiania modyfikacji tytułu warto wyjaśnić organizację nazw wszystkich plików (związanych z nawigacją) w całej strukturze, bo to będzie przydatne do właściwego zrozumienia czynności przy modyfikacji struktury, o czym chcę wkrótce napisać.

Kody nawigacyjne (IGS) dla poszczególnych stron menu są umieszczone w następujących plikach:
90010.MTS, 90020.MTS itd do 92520.MTS - dla stron głównych poszczególnych tytułów
90011.MTS, 90012.MTS itd dla stron rozdziałów tytułu pierwszego
90021.MTS, 90022.MTS itd dla stron rozdziałów tytułu drugiego
...........................
92521.MTS, 92522.MTS itd dla stron rozdziałów tytułu ostatniego (252-go)
93001.MTS, 93002 itd do 93021.MTS dla stron Title list menu
Jak wspomniałem oddzielenie w/w kodów od plików video, do których się odnoszą, ma dla nas kapitalne znaczenie. To dzięki temu staje się możliwa prosta modyfikacja strony menu głównego, a nawet rozbudowa i przebudowa całej struktury AVCHD/BR. Należy jeszcze objaśnić znaczenie pozostałych plików całej struktury, aby dobrze rozumieć na czym polegają wspomniane modyfikacjie i jak je powinno się wykonywć.
Każdy plik .MTS (.m2ts) musi mieć swój plik informacyjny .CPI (.clpi) i pliki te mają te same nazwy co odpowiadające im pliki .MTS (.m2ts).
Natomiast każda główna strona menu dla tytułu musi mieć swój plik .MPL (.mpls). Przy tworzeniu nazw tych plików obowiązuje prosta zasada:
00301.MPL, 00302.MPL itd do 00552.MPL - to są playlisty dla kolejnych stron tytułowych menu głównego.
Również wszystkie strony rozdziałów przynależne do danego tytułu mają swoje pliki .MPL (.mpls) i mają nazwy:
00601.MPL, 00602.MPL itd do 00852.MPL dla wszystkich stron rozdziałów kolejnych tytułów
Pliki z kodami nawigacyjnymi nie mają swoich playlist, bo nie są to struktury złożone.
Pliki filmowe dla stron głównych poszczególnych tytułów mają nazwy: 80010.MTS, 80020.MTS itd do 82520.MTS
Pliki filmowe dla stron rozdziałów mają nazwy:
80011.MTS, 80012.MTS itd do 80018.MTS dla tytułu pierwszego
80021.MTS, 80022.MTS itd do 80028.MTS dla tytułu drugiego
..............................................
82521.MTS, 82522.MTS itd do 82528.MTS dla tytułu ostatniego
(w przypadku 96 rozdziałów jest bowiem 8 stron po 12 rozdziałów na każdej stronie - oczywiście gdy rozdziałów w danym tytule jest mniej to i stron rozdziałów będzie odpowiednio mniej, np dla 16 rozdziałów będą tylko dwie strony)
Pliki 83001.MTS, 83002.MTS...do 83021.MTS reprezentują strony Title list (21 stron potrzebnych do ulokowania 252 tytułów po 12 na stronie).

Jest bardzo ważne, aby dobrze się orientować jakie są pliki w strukturze, jakie mają nazwy i jakie jest ich wzajemne powiązanie i oczywiście jaką pełnią funkcję. Tylko wówczas można przystąpić do modyfikacji struktury z gwarancją, że uzyska się zamierzony efekt.
Ale aktualnie zajmujemy się modyfikacją samego menu, więc na powyższym tle omówiony zostanie konkretny przykład jako ilustracja takiej modyfikacji.
Załóżmy, że nasz tytuł w jakiejś strukturze AVCHD/BR jest w kolejności pięćdziesiątym, czyli jego plik filmowy dla menu głównego będzie miał nazwę 80500.MTS. Ta podmieniana stara strona menu dla tytułu nie koniecznie musi być ruchoma - może być statyczna, a przy okazji uczynimy ją ruchomą. Jest to ważna informacja, bo jak wiadomo z materiału filmowego pochodzącego ze starszych kamer HD Sony, nie da się zrobić ruchomego menu. Można więc w kompilacji zrobić menu statyczne, a następnie je podmienić na ruchome. Ale nawet dowolne inne menu statyczne (niekoniecznie pochodzące z kamer Sony), możemy chcieć zamienić na ruchome i nie ma żadnych przeszkód, aby to zrobić, bez ponownej kompilacji całej struktury.
Strony menu dla rozdziałów pięćdziesiątego tytułu będą odpowiednio jako 80501.MTS, 80502.MTS itd do 80508.MTS i one pozostają bez zmiany (nie zajmujemy się tym, ale oczywiście na podobnych zasadach jak główną stronę menu tytułowego, bez powtórnej kompilacji można także podmienić każdą stronę menu rozdziałów).
Trzeba mieć też na uwadze, że liczby w nazwach tytułów są o jeden mniejsze niż numer tytułu, bo przecież pierwszy tytuł odnosi się do pliku filmowego 00000.MTS.
Dla kogoś, kto pierwszy raz spotyka się z organizacją struktury AVCHD/BR w obszarze nawigacji, może to wydawać się zbyt skomplikowane-ale tak nie jest, ponieważ obowiązują tu proste i łatwe do zapamiętania zasady. Myślę, że każdy użytkownik, który utworzy dla siebie kompletną strukturę dla 252 tytułów szybko się zorientuje gdzie co jest - ale tym zajmiemy się w następnej kolejności.
Powróćmy do naszego pliku 80500.MTS, który usuniemy z naszej struktury i w jego miejsce podstawimy swój video-clip utworzony w dowolnym programie edycyjnym NLE (ale może to być też dowolna strona tytułowa menu głównego pochodząca z multiAVCHD). Dla aktualnej wersji multiAVCHD odtwarzanie video-clipu powinno trwać 32" (jeżeli będzie dłuższy czas odtwarzania, to na ekranie będziemy obserwować odtwarzanie w pętli tytlko te 32" - Dean zapowiedział, że wkrótce ten limit zostanie zniesiony także dla menu bazującego na template). Pliki przynależne do tego tytułu zgodnie z powyższymi zasadami to: 90500.MTS, 350.MPL oraz 80500.CPI. Pierwsze dwa pliki zachowują swą aktualność także dla tej naszej nowej strony menu tytułowego, natomiast plik 80500.CPI musimy stworzyć korzystając z tsMuxer lub z multiAVCHD (w przypadku wstawiania strony menu z multiAVCHD, możemy wykorzystać odpowiedni plik związany z tą stroną po zmianie jego nazwy na 80500.CPI).
To tyle dodatkowych wyjaśnień do modyfikacji menu i wstępnych informacji przydatnych przy modyfikacji struktur AVCHD/BR
Dużo tego wyszło i może trochę "ciężkiego" tekstu, ale w algorytmach musi być absolutna jednoznaczność. Najmniejsze odstępstwo od obowiązujących zasad, zawsze zburzy poprawność odtwarzania całej struktury. Dalej będzie już wszystko prostsze czyli "z górki", bo grunt jest przygotowany, a finał bliski.
 
Ostatnia edycja:

krzysztofradio

Well-known member
Bez reklam
Po updacie MultiAVCHD do built 746 wyskakuje mi komunikat:

ERROR: multiAVCHD.dat version/structure error! Update!

MultiAVCHD mam na trzech różnych komputerach i na kazdym to samo. Probowalem podmienic sam plik multiAVCHD.dat, probowałem instalowac na nowo i tez nic.

O co chodzi?
 

Tomanek

New member
@krzysztofradio - a zrobiłeś update całego programu czy tylko multiAVCHD.dat ?
Ściągnij może jeszcze raz pełną instalkę i wgraj wsio od nowa.
Teraz zrobiłem update do 746+ i działa....
 

krzysztofradio

Well-known member
Bez reklam
próbowałem sam plik, próbowałem caly program i nic. Niestety jestem w pracy i mam zablokowana strony typu rapidshare, wiec sciagne dopiero w domu. Dzieki.
 

Sydon777

Klub HDTV.com.pl
vip
Czas na finał!
Dla mnie możliwość modyfikacji istniejącej struktury AVCHD/BR zawsze była zagadnieniem docelowym. To wynika z naturalnego trybu pracy posiadacza kamery HD. W miarę powstawania nowego materiału filmowego chcemy go na bieżąco opracowywać i dokładać do istniejącej struktury, która może być praktycznie dowolnie duża. Nie wydaje mi się właściwe, aby przy każdej takiej czynności należało podejmować kompilację całości posiadanego materiału filmowego od nowa. To prawda, że możliwość częściowego wykorzystywania już raz wykonanych stron menu, która ostatnio została wprowadzona przez Deana, dość znacznie skraca czas kompilacji, ale... Jednak jeszcze przy niektórych takich kompilacjach ujawniają się błędy nawigacji i mimo wszystko ten czas ponownej kompilacji jest jeszcze stanowczo za długi. Miałem zawsze absolutną pewność, że tę sytuację można radykalnie zmienić. Głównie chodzi mi tu o skrócenie tego czasu w drodze modyfikacji struktury, a nie jej powtórnej kompilacji. Usunięcie błędów nawigacji, to oczywiście odrębny problem i jeżeli zastosuje się sugerowany przeze mnie algorytm postępowania, to istnienie tych błędów będzie już bez znaczenia.
Już pisałem, że szczegółowa analiza struktury AVCHD/BR z multiAVCHD oraz analiza pracy samego programu i procedur AviSynth wskazywała, że modyfikację struktur można będzie realizować w bardzo prosty sposób. Tak prosty, że obawiałem się, że czegoś w swych rozważaniach nie uwzględniłem i prawdopodobnie gdzieś tkwi pułapka, która "wyłoży" w praktyce całą koncepcję. Jednak okazało się, że realizacja mojej koncepcji jest możliwa, co zostało sprawdzone na kilku przykładowych strukturach.
Opiszę ten algorytm w miarę szczegółowo, bo w moim przekonaniu warto go stosować w praktyce, nawet przy "ręcznej" modyfikacji struktury. Ja go teraz z powodzeniem stosuję w takim właśnie wydaniu (choć można napisać programik, który za nas to zrobi), więc być może i innym użytkownikom będzie to przydatne. Opiszę też dlatego, że mam taką cichą nadzieję, że może i Dean podejmie implementację takiego algorytmu w multiAVCHD. Z punktu widzenia programowego byłoby to raczej proste zadanie. Oto moja koncepcja:

I. Do multiAVCHD wczytujemy 252 możliwie króciutkich plików .m*ts (mogą to być pliki dla dowolnych pojedynczych ujęć kamery HD), które utworzą nam strukturę bazową dla 252 tytułów. Nazwami tytułów niech będą liczby od 1 do 252. Na początku dla uproszczenia przyjmiemy, że każdy tytuł ma 12 rozdziałów. Aby skrócić czas wykonania kompilacji ja zastosowałem omawiane już template (dołączone do mojego wcześniejszego postu), ale dla menu statycznego. Wynik kompilacji jest rodzajem szkieletu naszej przyszłej budowli, w której już jest przygotowane miejsce na 252 pełnowymiarowe tytuły i co najważniejsze będą już utworzone pliki z kodami nawigacyjnymi stron menu dla wszystkich tytułów i ich rozdziałów, a także docelowe pliki MOVIEOBJ.BDM i INDEX.BDM dla całej struktury. Warto bliżej przyglądnąć się jak wyglądają pliki w poszczególnych folderach tej struktury bazowej i myślowo przypisać im sens objaśniony już poprzednio. W zasadzie moglibyśmy większość plików ze struktury bazowej już usunąć (za wyjątkiem plików ze strefy nawigacyjnej - w szczególności plików z kodami IGS), ale ponieważ ich sumaryczna objętość jest mała, to równie dobrze mogą tam zostać do czasu ich naturalnej eliminacji.
Jeżeli mamy jakąś wielotytułową strukturę, która spełnia pewne założenia (każdy tytuł bazuje na pojedynczym pliku do 4 GB o dowolnej ilość rozdziałów i struktura pochodzi z multiAVCHD v 4.0 ), to wszystkie pliki z folderów STREAM, CLIPINF i PLAYLIST tej struktury możemy przekopiować doj struktury bazowej zachowując ich pierwotne nazwy (nadpisując ewentualnie istniejące pliki o tych samych nazwach) i zobaczymy, że to wszystko bez dodatkowych zabiegów da się już uruchomić i cała nawigacja będzie funkcjonować prawidłowo.
II. Po uzbieraniu pewnej ilość nowego materiału filmowego wykonujemy w multiAVCHD strukturę AVCHD/BR dla jednego tytułu z 12 rozdziałami. Gdy struktura jest gotowa i jesteśmy z niej zadowoleni przepakowujemy pliki do struktury bazowej, tak aby ten nowy tytuł znalazł się na pierwszej wolnej pozycji (gdzie jeszcze mamy ewentualnie tymczasowo rezydujące pliki robocze dla krótkiego tytułu wstępnego). To przepakowanie plików (na zasadzie nadkopiowania na istniejące, po wcześniejszych zmianach w nazwach plików zgodnie z pozycją, którą teraz mają zajmować) nie może dotyczyć plików z kodami nawigacyjnymi - te bazowe są nietykalne. Jeżeli będziemy robić to sprawnie, to dobudowanie jednego tytułu zajmie nam naprawdę mało czasu. Przecież to jest bardzo proste. I już ta struktura bazowa powiększona o kolejny tytuł będzie się uruchamiała wraz z prawidłową nawigacją. Jedynie na odpowiedniej stronie Title list nie pojawi nam się nazwa nowego tytułu, ale z pozycji mu należnej, możemy go uruchamiać. I w przyszłości będziemy sobie dokładać tytuł po tytułe i struktura nam bezboleśnie będzie się rozrastać i ciągle będzie działać prawidłowo. Jeżeli dołożyliśmy kolejnych 12 tytułów możemy spreparować odpowiednią stronę do Title list menu, tak aby wszystkie aktualne tytuły i ich nazwy były tam ujawnione. Zrobienie stron dla Title list też nie jest trudne, bo Dean dostarcza nam odpowiednie narzędzie (o nazwie TLMP-0x.avs czyli skrypt AviSynth Title List Menu Page), które umożliwi nam ich wykonanie. Gdzie znaleźć takie narzędzie i jak go wykorzystać napiszę, o ile będzie taka potrzeba. Ale stronę dla Title list menu możemy też wykonać w dowolnym programie NLE (lub wstępnie wykonać plansze w jakimś programie graficznym i następnie w NLE ją przekształcić na 32" video) i wynik podstawić w odpowiednie miejsce. Można też do zrobienia potrzebnych stron Title list menu wykorzystać wprost multiAVCHD (szybko wykonać strukturę bez menu głównego i rozdziałów, na małych plikach odpowiednio zatytułowanych).

Aby nie było wątpliwości którym plikom należy zmienić nazwę przed ich wkopiowaniem w strukturę bazową i jak to zrobić, można posłużyć się następującym zestawieniem:
We folderze STREAM struktury jednotytułowej zmieniamy
00000.MTS ---> 00N.MTS
80010.MTS ---> 8n0.MTS
80011.MTS ---> 8n1.MTS
We folderze CLIPINF zmieniamy
00000.CPI ---> 00N.CPI
80010.CPI ---> 8n0.CPI ( też kopiujemy, bo np. menu statyczne mogło być zmienione na ruchome)
gdzie:
n - trzycyfrowy numer tytułu dla struktury bazowej (n może być od 001do 252)
N=n-1
W pozostałych plikach nie zmieniamy nazw i ich nie przekopiowujemy do struktury bazowej.
Nawet ci użytkownicy, którzy nie chcą zaprzątać sobie głowy poznaniem wzajemnych powiązań między plikami struktury AVCHD/BR w strefie nawigacji , mogą z powodzeniem rozbudowywać strukturę bazową realizując tylko ten pięciolinijkowy zapis przekształcania nazw plików.
Piszę o dobudowywaniu kolejnych tytułów w istniejącej strukturze, ale nic nie stoi na przeszkodzie, aby np wymienić jakiś tytuł na dowolnej pozycji i zastąpić go nowym (np po jakimś poprawieniu lub uzupełnieniu) i to bez naruszania całej konstrukcji, która przecież może mieć już setki GB.
Jak widzicie jedyna "ręczna" czynność w tym algorytmie polega na umiejętnej zmianie nazw w plikach tytułu, który wprowadzamy do struktury bazowej. To nie jest trudne ani czasochłonne i po tym co wcześniej napisałem powinno być jasne, ale gdyby tak...
No właśnie, gdyby tak do multiAVCHD Dean wmontował gdzieś opcję do zaznaczenia np. "tytuł przeznaczony do rozbudowy istniejącej struktury na pozycji ..." (tu wpisywałoby się nr tytułu n) i w wyniku otrzymywalibyśmy już pliki o właściwej numeracji w nazwach, gotowe do wkopiowania w strukturę bazową. Program nawet sam mógłby te pliki wkopiować po wskazaniu nazwy struktury bazowej. Można pójść dalej i tworzyć w multiAVCHD nawet do 96 rozdziałów, gdyby program w kodach nawigacyjnych dla stron rozdziałów uwzględnił usytuowanie kompilowanego tytułu w strukturze bazowej (czyli n zamiast 1), Wówczas można byłoby przekopiowywać wszystkie pliki dla stron rozdziałów wraz z plikami kodów nawigacyjnych do tych stron się odnoszących. - dla programisty jest to dodanie do programu kilkunastu prostych instrukcji, a komputer całą pracę wykona w kilku sekundach.
Coś takiego miałem na myśli pisząc swego czasu o "bajkowo prostej" rozbudowie i przebudowie struktur, bez "dotykania" już istniejących plików dla innych tytułów.
Czy potrzeba rozbudowy istniejących struktur wynika tylko ze specyfiki pracy użytkowników kamer HD? Sądzę, że jest to absolutnie ogólna potrzeba. Ktoś może chcieć rozbudowywać swoją strukturę w oparciu o sukcesywne dokupywanie płyt BD (lub DVD, nie wspominając o torentowcach). Nawet gdy ma już ich dziesiątki czy nawet setki, to przecież i tak transfer do wspólnej struktury będzie rozłożony w czasie. Opracownie pojedynczego tytułu wymaga przecież czasu i każdy użytkownik chętnie korzystał będzie z takiego prostego dokładania tytułów do istniejącej struktury. To tak jakbyśmy w komputerze mieli wirtualną kolumnę do składowania 252 płytek z tytułami filmowymi, do której wkładamy na dowolnej pozycji kolejne tytuły w miarę ich nabywania.
Również jeżeli jakiś tytuł w strukturze bazowej chcemy zlikwidować, możemy bez problemów jego pliki usunąć, a na to miejsce wstawić pliki innego tytułu (zaraz po likwidacji tytułu lub w dowolnym czasie później).
Ja doprowadziłem swoją wizję do końca, wskazując dokładnie co, gdzie, jak i dlaczego należy zmienić. Tę koncepcję można z powodzeniem realizować (do czego zachęcam), nawet gdy nie będzie już żadnych zmian w programie multiAVCHD. Rozpocznijcie więc budowę swojej gigantycznej struktury już teraz. Poczujcie się architektami tej niezwykłej budowli, wprowadzając do niej swoje indywidualnie projektowane elementy. Na jej początku ulokujcie strukturę, którą już macie. Wypełnienie tej budowli 252 tytułami może potrwać kilka lat, ale na każdym etapie budowy będziecie mieć pełną satysfakcję z oglądania tego co już stworzyliście. A jeżeli coś będziecie chcieli udoskonalić, można to zawsze bardzo prosto zrobić nie naruszając całości.
Jeżeli Dean jednak da się również na coś takiego namówić, multiAVCHD zyska wg mnie nową jakość i wyjątkowo cenną funkcjonalność, umożliwiającą ogromną oszczędność czasu pracy użytkownika i komputera (jak wielką oszczędność, to już kiedyś obliczałem) oraz niezwykłą elastczność tworzenia.
Powtórzę jeszcze: moim zdaniem jest moło prawdopodobne, aby ktokolwiek mógł wykorzystać potencjalne możliwości tkwiące w multiAVCHD bez zastosowania tego typu algorytmu. Z punktu widzenia zmian programowych jest to zaledwie mała kosmetyka w istniejących zapisach.
Uff.. Finito!
 
Ostatnia edycja:

Tomanek

New member
Sydon - dzięki za Tutorial rozbudowy struktur.
Przeczytałem całość i muszę stwierdzić , że ma to sens.
Martwi mnie natomiast to , iż Dean poprzez google niestety nie zrozumie w pełni co napisałeś. Zrób może tłumaczenie dla Deana tylko najważniejszych kwestii jak Ty to widzisz aby działało. Trzeba by Deanowi wskazać szkielet takiego działania cos na zasadzie schematu blokowego co ma program pobrać co przetworzyć co gdzie i jak zapisać. Do tego najlepiej by się nadawał osobny mały program albo dodatkowa zakładka w multiAVCHD realizująca to o czym piszesz a nie jako jakaś opcja dla niektórych niezrozumiała zakopana w programie.
 
Do góry