Witamy.

Oczywiście. Film o rozdzielczości 640x272 ma proporcje około 2.35:1. Gdy powiększamy go tak, aby wypełni ekran, który ma proporcje 16:9 lub 4:3, musimy stracić część obrazu po bokach (tak robi ZOOM w Twoim odtwarzaczu... i w prawie wszystkich innych) albo zaburzyć prawidłowe proporcje obrazu (czyli rozciągnąć go w pionie - ludzie będą „wychudzeni”). Niestety takie są odwieczne prawa geometrii.
Niektóre odtwarzacze stacjonarne obsługują znacznik proporcji zawarty w filmie *.avi / *.divx. Można go dodać/zmienić programem MPEG-4 Modifier (w sekcji Display AR zaznaczamy proporcje obrazu jakie chcemy uzyskać, po czym zapisujemy nowy plik przyciskiem Save). Jak już wspomniałem, niestety wiąże się to z zaburzeniem prawidłowych proporcji postaci i obiektów.


Wyżej wymieniony MPEG-4 Modifier robi to w kilka minut, bo nie ma żadnej rekompresji.

Tak.

Zresztą można przeprowadzić test na króciutkim fragmencie (np. 1000 klatek) dodając na końcu skryptu instrukcję Trim(pierwsza_klatka,ostatnia_klatka). Może być to np. Trim(0,999) (początek filmu) lub Trim(10000,10999) (kawałeczek siódmej minuty filmu).

To nam mówi, że obraz jest już w YV12, a to właśnie chcemy osiągnąć (x264 potrzebuje wejścia w YV12) Więc pewnie to rzeczywiście błąd w MeGUI. Jeśli na podglądzie w VirtualDubie kolory wyglądają prawidłowo (nie ma „niebieskich twarzy”), to również po kompresji w x264 wszystko powinno być w porządku.

Może to po prostu dziwny błąd w MeGUI, bo nie wiem jak skrypt AviSynth może być rozpoznawany jako I420.

Wrzuć skrypt (ten bez linijki ConvertToYV12()) do VirtualDuba. Tam w File -> File Information -> Video Stream -> Decompressor powinien być podany kod FourCC przestrzeni kolorów którą skrypt daje na wyjściu.

Rzeczywiście błąd bardzo dziwny, bo teoretycznie AviSynth nie obsługuje I420 (więc nie rozumiem jak MeGUI może rozpoznawać skrypt jako I420). Ale I420 to po prostu YV12 z wartościami U i V zamienionymi miejscami, AviSynth pewnie poradziłby sobie poprzez instrukcję SwapUV().

RealVideo 9/10 wewnętrznie używa I420.

Proponuję wkleić treść skryptu, może to nam coś powie.

Która wersja MKVToolnix? Właśnie spróbowałem z wersją 3.4.0 i nie było takich problemów z VobSubami stworzonymi AVIAddXSubs (ani żadnymi innymi).

W najnowszej wersji MKVToolnix (4.1.1) dla VobSubów domyślnie jest stosowana kompresja zlib, może to powoduje problemy. Spróbuj ustawić Compression na none w Extra options.

A jakich ustawień filtra deblockingu x264 używasz podczas kompresji? Przy w miarę „rozsądnych” ustawieniach filtra deblockingu (np. -1,-1) wskutek kompresji nie powinny powstać wyraźne bloki, nawet gdy bitrate jest dość niski (za niski bitrate w x264 objawi się raczej rozmyciem obrazu spowodowanym właśnie przez deblocking).

A może po prostu masz wyłączony deblocking w dekoderze formatu AVC którego używasz do odtwarzania stworzonych plików wynikowych?

Nie wspomniałem o Yambie, bo nie mogłem w nim znaleźć opcji ustawiania proporcji (teraz już znalazłem - Pixel aspect ratio pod przyciskiem Properties przy muxowaniu ).

Może w tym przypadku chodzi o obraz anamorficzny który nie posiada odpowiedniego znacznika proporcji i jest wyświetlany nieprawidłowo (jako 4:3 zamiast 16:9).

Nie przypominam sobie jak ustawić taki znacznik w MP4, ale można to po prostu przemuxować to do MKV. W MKVMerge GUI zaznaczamy strumień obrazu, przechodzimy do zakładki Format specific options i tam możemy ustawić proporcje wyświetlania w polu Aspect ratio.

Programem Chapter Xtractor otwieramy plik IFO, w Format -> Presets wybieramy "OGG" i zapisujemy plik TXT przyciskiem Save Data. Ten plik TXT otwieramy w MKVToolnix (zakładka Global, sekcja Chapters, pole Chapter file) i muxujemy strumienie jak zwykle.

Ten format rozdziałów ma postać:

W plikach IFO nie ma zapisanych nazw rozdziałów, ale w Matrosce możemy ich używać. Po prostu zmieniamy łańcuchy „Chapter X” w uzyskanym pliku TXT przed zmuxowaniem ostatecznego pliku MKV (jak już wyżej wspomniano).

Przykleiłem - temat z pewnością na to zasługuje. Świetna robota

Zauważyłem też że nie ma wzmianki o wyjściach SCART RGB i S-Video. To spory mankament dla wielu ludzi - SCART jest niezwykle popularny w Europie a S-Video w innych regionach (bo jakość Composite najczęściej jest dość paździerzasta ).

Qpel w MPEG-4 ASP w ogóle jest lepiej obsługiwany przez tańsze urządzenia

GMC było częściej stosowane w filmach kompresowanych DivXem 5/6 niż w tych kompresowanych XviDem - niektórzy użytkownicy DivXa lubią zaznaczać wszystko jak leci (z początku sam tak robiłem ). Około wersji 6.8.5 DivX zaczął stosować 2 „punkty zakrzywienia” (przedtem stosował 1, choć deklarował 2), warto sprawdzić jak urządzonko sobie poradzi. Brak obsługi 3 punktów to niestety norma, bo nie ma na nią dużego zapotrzebowania.

Ale ten MBox nie obsługuje zwykłych płyt Blu-ray, prawda? Bo producent nie wspomina o ich obsłudze

Niestety pełnej obsługi MPEG-4 ASP (w tym również 3wp-GMC) pewnie już nigdy się nie doczekamy. Rozwój chipów do „zwykłych” odtwarzaczy DVD już kilka lat temu zatrzymał się na jednym warppoincie GMC, bo DivX 5/6 używał tylko jednego (od niedawna używa dwóch;) ). Zresztą projektanci chipów (i firmware'u) nie zawsze podchodzą do swojej pracy z należytą powagą - dobrym przykładem jest MediaTek MT1389 i jego dziwne kaprysy odnośnie niektórych matryc kwantyzacji Ale niektórzy ludzie i tak wciąż będą się sugerowali jedynie znaczkiem "DivX" na obudowie... Nasza wieloletnia działalność uświadamiająca nie odnosi rewelacyjnych skutków.


Bo jest Ale te wszystkie „upiększające” tagi (pochylenie itp.) trochę wzbogacają oglądanie na komputerze, nie chciałbym z nich rezygnować.

To pewnie da się poprawić w sofcie... o ile producentowi będzie się chciało (a na ogół producentom się nie chce ).

Kilka mankamentów:

- brak obsługi XSubów
- traktowanie tagów w napisach jak zwykłego tekstu (nawet „zwykłe” odtwarzacze DVD są inteligentniejsze pod tym względem)
- brak obsługi Qpela w MPEG-4 ASP (również krok w tył w stosunku do tanich odtwarzaczy DVD)

Moje przypuszczenia okazały się słuszne - to "KiSS Bis" Ma mnóstwo bajerów, ale wystarczy jeden mały Qpel aby się zakrztusił. Takie fundamentalne wady w urządzeniu za 1800 złotych są co najmniej dziwne. Doświadczenia z KiSSami pokazały że bajery nie pomogą jeśli urządzenie po prostu nie odtwarza części filmów z kolekcji właściciela...

Prosimy o umieszczanie obrazków jako załączniki do postów, nie zaś w zewnętrznych serwisach (Regulamin pkt. 20). Przeniosłem obrazek.


„Masa” kodeków nie pomoże... Tu wystarczy jeden kodek który obsłuży format dźwięku zastosowany w tym pliku

Wrzuć plik źródłowy do programu GSpot. W sekcji Audio będzie napisane w jakim formacie jest dźwięk. To pomoże nam znaleźć odpowiedni kodek architektury ACM. Zresztą do identyfikacji formatów obrazu i dźwięku można wykorzystać też np. MediaInfo lub AVINaptic.

Tak wyglądają ekrany menu ustawień odtwarzacza:

Funkcja „Stretch by” nigdy nie działała zbyt dobrze dla dźwięku... a w tym przypadku i tak pewnie by nie pomogła. Różnica 13m 9s jest za duża aby mogła wynikać tylko z różnicy FPS.

Ten film (jak wiele innych) ma wersję „kinową” oraz „reżyserską” (dłuższą). Polska ścieżka pewnie pochodzi z wersji kinowej a obraz i ścieżka angielska z reżyserskiej. To nie może do siebie pasować z powodu brakujących i alternatywnych scen.

Potrzebny będzie kodek x264 w wersji VfW (tutaj jest 32-bitowy a tutaj 64-bitowy).

No to świetnie

Dodam jeszcze, że Decomb (ten drugi plugin) zazwyczaj bywa nieco szybszy niż TIVTC (ten pierwszy), a szybkość ma przecież szczególne znaczenie przy przerabianiu HD. Dla „czystych” materiałów (tzn. takich które zawierają tylko 3:2 pulldown bez żadnych wstawek “30p” / “60i” itp.) efekty działania obu pluginów są równie dobre, tyle że prędkość może się trochę różnić.

To nie zadziała przy tzw. „twardym pulldown” (gdy powtórzone półobrazy naprawdę są obecne w strumieniu, nie zaś tworzone na podstawie znaczników).


TIVTC:

albo Decomb:


Tutaj mamy artykuł - dość stary, ale w zasadzie aktualny, tyle że Telecide() nie ma już opcji order (obecnie używa informacji parzystości klipu otrzymanej od AviSynth).

Połączenie wideo jest proste - łączymy wyjście wideo magnetowidu (żółte gniazdo cinch oznaczone „Video”) z wejściem „Composite” (również żółte gniazdo cinch) karty telewizyjnej przy pomocy zwykłego kabla cinch-cinch (do kupienia w każdym sklepie RTV).

Do połączenia audio też będzie potrzebny kabel cinch-cinch (można wykorzystać kabel podwójny - za jednym zamachem połączylibyśmy obraz i dźwięk) oraz przejściówka z cinch na minijack taka jak na zdjęciu:


Widzę że jest tylko jedno wyjście audio (białe gniazdo cinch oznaczone „Audio”). Trzeba je podłączyć kablem cinch-cinch do białego gniazda w wyżej wymienionej przejściówce (białe gniazdo to dźwięk mono, a w przypadku dźwięku stereo jest to kanał lewy). Cienką wtyczkę typu minijack na drugim końcu przejściówki podłączamy do wejścia Line-In (niebieskie) karty dźwiękowej lub karty TV. Gdy podłączymy do karty TV, zminimalizujemy prawdopodobieństwo wystąpienia desynchronizacji audio/wideo w przechwyconym pliku. Z kolei gdy podłączymy do karty dźwiękowej, być może uzyskamy nieco lepsza jakość nagrywania dźwięku (dotyczy to zwłaszcza kart niezintegrowanych z płytą główną). Problem desynchronizacji właściwie nie istnieje w najnowszym VirtualDubie (jeśli ustawimy go tak jak na obrazku w tym poście), więc pozostaje problem jakości dźwięku - sprawdź które wejście (karta TV czy karta dźwiękowa) daje lepszą jakość.

Tutaj mamy artykuł o przechwytywaniu VHS.

I w dodatku strata kanałów (5.1 -> 2.0 -> 5.1).

Jeśli już chcemy przekodować, można zrobić tak jak w tym poście. W tym przypadku skrypt AviSynth będzie bardzo prosty:


W ten sposób będzie tylko jedna kompresja i zachowamy wszystkie kanały bez zmian.

Tak. W 2005 roku x264 był bardzo niedojrzały (w porównaniu z wersjami z 2009 roku), nie miał VAQ, PsyRDO/PsyTrellis, MB-Tree i zawierał sporo błędów które od tego czasu poprawiono. Ponadto wydajność algorytmów szukania ruchu (i pewnie wielu innych) została znacznie ulepszona od tego czasu.

Ach, MP4... Z MP4 wyciągamy strumienie programem YAMB (http://yamb.unite-video.com/Yamb-2.1.0.0_beta2_setup.exe) - zakładka Editing, dwukrotnie klikamy „Click here to extract streams from...”.