Fórum Digizone.cz

Hlavní témata => Zemské digitální vysílání (DVB-T) => Téma založeno: Ivan z Kolína 16. 09. 2013, 00:43:09

Název: Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 16. 09. 2013, 00:43:09
Už pěkně dlouhou řadu let používám pro zpracování záznamů z DVB-T i DVB-S programy ProjectX a PVAStrumento. Pokud nevíte, jsou dobré hlavně k tomu, aby se po demultiplexu obrazové a zvukové stopy v případě sebedrobnějších výpadků postupně nerozjela synchronizace. Při zpracování transportních toků z Pařízkových multiplexů 4 (např. Fanda) nebo RS7 (např. Déčko/Art) mi ale oba zmíněné programy zahazují podstatné kusy záznamu kvůli masově se vyskytujícím formálním chybám tohoto typu:

!> startPTS of GOP# 35 is earlier than the end of last GOP.. (exp. 1676262094)
!> PTS difference of -14400 (23:59:59.840) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 35 / new Timecode 00:00:20.080

TS přitom jde normálně přehrávat playery (VLCPlayer, MPC) bez nějakého subjektivního výpadku a i běžný nesynchronizovaný demultiplex (např. TSDemuxer) vyplivne M2V+MP2 prakticky v celé jejich délce v pořádku. Bohužel nesynchronizovat záznamy právě z těchto signálově sporných muxů je dost velký risk, že se to dříve či později někde rozjede (to si dobře pamatuju ještě z dob začátků DVB-T, než jsem tyto - doposud skvělé - nástroje objevil). Nezáleží ani jak TS pořídím, zda na PC (DVB-T karta + DVBViewer) nebo přes PVR (Dreambox 8000), takže chybu zachytávacího zařízení bych skoro vyloučil. Při zpracování TS z muxů 1, 2, 3 ani ze satelitu se mi nic takového neděje.

Zaznamenali jste něco podobného? Má podle vás Pařízek head-endy špatně nastavené nebo jde o nějakou dosud prakticky nevyuživanou větev v normě MPEG-2 transport streamu, kterou nemají uvedené programy dosud implementovanou? A co s tím? Co pro synchronizovaný demultiplex takto uplácaných transportních toků použít?

P.S. Pavel Hanuš tu v nedávném rozhovoru tvrdil, že transportní tok jako takový (na datové úrovni) produkuje kompletně ČT, zatímco Pařízek ho jen odvysílá. Vzhledem k tomu, že při zpracování TS z muxu 4 a muxu RS7 dochází k úplně stejným typům chyb, k nimž v muxu 1 nedochází, mám silné podezření, že pan Hanuš buďto neví (a to bych se dost divil), anebo tak trochu kecá  :-[.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Martin Patera 16. 09. 2013, 06:29:42
Mam k dispozici IceCrypt STC6000HDPVR a ten uklada program z MUXu DVB-T/T2/S/S2/C do nativniho souboru.ts .
Kdyz pote soubor zkonvertuji do DivX (VirtualDub), tak nepozoruji zadne problemy.
Mohu nahravat vsechny programy z MUXu najednou a vsechny se nahravaji v poradku.
Tudiz bych rekl, ze problem bude na tve prijimaci strane.
 
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Jan Novák 16. 09. 2013, 09:12:20
Mam k dispozici IceCrypt STC6000HDPVR a ten uklada program z MUXu DVB-T/T2/S/S2/C do nativniho souboru.ts .
Kdyz pote soubor zkonvertuji do DivX (VirtualDub), tak nepozoruji zadne problemy.
Mohu nahravat vsechny programy z MUXu najednou a vsechny se nahravaji v poradku.
Tudiz bych rekl, ze problem bude na tve prijimaci strane.
Nemyslím si, že problém bude na straně příjmu.
Když si otevřu nahrávku z běžného muxu v MPEG Validatoru, tak je každému GOPu přiřazen timekód, který je v rámci nahrávky kontinuální. To v Muxu4 neplatí, tam se mi timekód nezobrazí buď vůbec (je nulový), nebo se zobrazuje jen pro každý x-tý GOP. Nepovažuji MPEG Validator za něco směrodatného, ale jisté problémy to naznačuje.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Petr Š. 16. 09. 2013, 11:03:07
Kdyz pote soubor zkonvertuji do DivX (VirtualDub), tak nepozoruji zadne problemy.
Který VirtualDub dokáže načíst TS? Já DVB-T zpracovávám už nějakých 7 let, používám na to VirtualDubMod, ale nejdřív musím TS překonvertovat pomocí PVAStrumento a Cuttermaran. Kvůli používání HD jsem ale musel začít používat VideoReDo.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ondřej Caletka 16. 09. 2013, 11:56:53
Už pěkně dlouhou řadu let používám pro zpracování záznamů z DVB-T i DVB-S programy ProjectX a PVAStrumento. Pokud nevíte, jsou dobré hlavně k tomu, aby se po demultiplexu obrazové a zvukové stopy v případě sebedrobnějších výpadků postupně nerozjela synchronizace. Při zpracování transportních toků z Pařízkových multiplexů 4 (např. Fanda) nebo RS7 (např. Déčko/Art) mi ale oba zmíněné programy zahazují podstatné kusy záznamu kvůli masově se vyskytujícím formálním chybám tohoto typu:

!> startPTS of GOP# 35 is earlier than the end of last GOP.. (exp. 1676262094)
!> PTS difference of -14400 (23:59:59.840) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 35 / new Timecode 00:00:20.080
Ano, obdobné problémy pozoruji také. Nejdřív jsem si myslel, že je chyba v signálu, ale po opravení antény chyby přetrvávají.  Citovaná chyba vypadá na přetočení PTS po nějaké dřívější hodnotě než na plném měřítku, což ProjectX vyhodnotí jako návrat v čase a GOP zahodí.

Je klidně možné, že kodéry/muxy Ateme podporují něco, co do ProjectX nebylo implemetováno, přeci jen ProjectX už se hodně dlouho nevyvíjí. Takže bych si nebyl tak jistý, že jde o chybu ve streamu.  Chce to nastudovat specifikace a s hexeditorem v ruce zkoumat, kde přesně může být problém. Ale to chce čas.


P.S. Pavel Hanuš tu v nedávném rozhovoru tvrdil, že transportní tok jako takový (na datové úrovni) produkuje kompletně ČT, zatímco Pařízek ho jen odvysílá. Vzhledem k tomu, že při zpracování TS z muxu 4 a muxu RS7 dochází k úplně stejným typům chyb, k nimž v muxu 1 nedochází, mám silné podezření, že pan Hanuš buďto neví (a to bych se dost divil), anebo tak trochu kecá  :-[.
Přiznali hlavně, že používají technologii od Ateme, zřejmě tedy stejnou, co používá Pařízek pro mux 4. Pokud je to vlastnost té technologie, pak není divu, že se to chová stejně a nezáleží, jestli ta technologie patří Pařízkovi nebo ČT. Je klidně možné, že ČT si Ateme koupila sama na základě Pařízkova doporučení. Ono totiž asi nebude moc technologií, co by uměly statisticky multiplexovat MPEG2 a MPEG4 navzájem.

Ale jinak tvrzení, že sami sestavují multiplex 22Mbps, do kterého si Pařízek přidává dvě další stanice je z technického hlediska nesmysl. Jeden multiplex může mít jen jednu sadu servisních informací, jako je PAT, CAT, NIT, SDT, EIT a podle mého laického výkladu sestavuje multiplex ten, kdo  sestavuje právě tyto servisní informace.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: pajas2 16. 09. 2013, 12:04:33
přeci jen ProjectX už se hodně dlouho nevyvíjí.
Poslední build je z února 2013, to není zase tak dlouho.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ondřej Caletka 16. 09. 2013, 12:52:39
přeci jen ProjectX už se hodně dlouho nevyvíjí.
Poslední build je z února 2013, to není zase tak dlouho.
Build si dokážu udělat i dnes ráno, záleží, jaké zdrojové kódy budu mít k dispozici. Na domovské stránce (http://project-x.sourceforge.net/) je poslední vydání datováno k březnu 2011 a letmý pohled do CVS naznačuje, že se toho moc neděje (http://project-x.cvs.sourceforge.net/project-x/Project-X/). Ale je možné, že se to vyvíjí někde jinde, kde o tom nevím, ostatně je to opensource.

Já už jsem delší dobu v pokušení napsat si vlastní obdobu ProjectX.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 17. 09. 2013, 01:46:46
Mam k dispozici IceCrypt STC6000HDPVR a ten uklada program z MUXu DVB-T/T2/S/S2/C do nativniho souboru.ts .
Kdyz pote soubor zkonvertuji do DivX (VirtualDub), tak nepozoruji zadne problemy.
Mohu nahravat vsechny programy z MUXu najednou a vsechny se nahravaji v poradku.
Tudiz bych rekl, ze problem bude na tve prijimaci strane.
Díky za info. Prosím jen o konkrétní postup konverze z TS do DivX a hlavně způsob jak zajistíš synchronizaci obrazové a zvukové stopy. Já se při tom bez ProjectX neobejdu. Můj běžný postup je následující:
DGIndex se dá vynechat (použít jiný plugin nebo VirtualDubMod), ale ProjectX nebo něco podobného dost těžko. Jak jsem už řekl, TSDemuxer nebo jiné hloupé demuxery sice fungují i na TS z muxu 4 a RS7, ale zadělávají na problém s rozjetím obrazové a zvukové stopy při sebemenších (i subjetivně nepostřehnutelných) výpadcích primárního záznamu.

Pokud existuje jiný postup, který synchronizaci AV z TS zajistí taky a navíc funguje na TS ze všech muxů, pak šup sem s ním! Díky.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 17. 09. 2013, 02:03:00
...letmý pohled do CVS naznačuje, že se toho moc neděje...
Ona ta norma pro MPEG-2 TS taky moc změn neprodělala. Z funkčního hlediska v zásadě nevidím důvod ho upgradovat (kromě podpory H.264, freeware na způsob ProjectX pro H.264 zoufale chybí). V tomto případě jde podle mě asi opravdu o chybový stav na vysílací straně, tj. enkodér produkující TS mimo normu. Nevidím nejmenší důvod proč by měl GOP podle PTS začínat dřív než má podle PTS + počtu snímků končit GOP předchozí. Každý program, který vnímá PTS a kontroluje jeho validitu, s tím musí mít problém. Playery a simple demuxery na kontrolu PTS zjevně kašlou.

...Já už jsem delší dobu v pokušení napsat si vlastní obdobu ProjectX.
Tak tohle už mám za sebou. Není to bohužel vůbec legrace. Mezi tím co všechno norma pro MPEG-2 TS teoreticky umožňuje a co a jak se pak reálně používá je propastný rozdíl. Co TS, to originál. Nejspíš by šlo do ProjectX sáhnout a tu kontrolu asynchronního PTS vypnout (v nastavení PX jsem to nenašel), ale pak je otázka jestli bude pro synchronizaci AV z TS ještě tak spolehlivý jak tradičně je.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: ivovi 19. 09. 2013, 22:54:02
..ProjectX .. Při zpracování transportních toků z Pařízkových multiplexů[/b] 4 (např. Fanda) nebo RS7 (např. Déčko/Art) mi ale oba zmíněné programy zahazují podstatné kusy záznamu kvůli masově se vyskytujícím formálním chybám tohoto typu:
!> startPTS of GOP# 35 is earlier than the end of last GOP.. (exp. 1676262094)
!> PTS difference of -14400 (23:59:59.840) to last exported GOP detected
!> dropping useless B-Frames @ GOP# 35 / new Timecode 00:00:20.080

...
Zaznamenali jste něco podobného? Má podle vás Pařízek head-endy špatně nastavené nebo jde o nějakou dosud prakticky nevyuživanou větev v normě MPEG-2 transport streamu, kterou nemají uvedené programy dosud implementovanou? ...


Zaznamenal jsem to same (Decko/Art, Fanda, Telka, Smichov). Podle meho nejde primarne o problem transportniho toku, ale kodovani obrazku MPEG-2 v raritnim "field encoding" misto bezneho "frame encoding", ktery jsem tu uz popsal (http://forum.digizone.cz/index.php?topic=3061.msg47367;topicseen#msg47367). Ve stejnych mistech, kde ProjectX haze tyto chyby v GOPech, je prave pouzito "field encoding" a ve stejnych mistech se take zasekava Digipal 2.

Podle meho nazoru ProjectX vubec neumi "field encoding" zpracovat (nebo chybne protoze to nikdo netestoval). Pri kontrole struktury GOPu a casovani PTS jeho obrazku proto haze jinak tezko dosazitelnou chybu (PTS diff. 0 nebo 20 ms).

Citace: ProjectX 0.91.0.00-Regmux7-Decko/Art
[08:42:22.691] !> dropping GOP# 33 @ orig.PTS 04:25:12.074 (1432086661), errorcode: 24
[08:42:22.691] !> Pics exp/cnt 15/19, inGOP PTS diff. 0ms, new Timecode 00:00:14.600
[08:42:22.742] !> PTS difference of 54000 (00:00:00.600) to last exported GOP detected
[08:42:22.742] !> dropping useless B-Frames @ GOP# 34 / new Timecode 00:00:14.600
[08:42:22.792] !> dropping GOP# 35 @ orig.PTS 04:25:13.274 (1432194661), errorcode: 24
[08:42:22.793] !> Pics exp/cnt 17/19, inGOP PTS diff. 20ms, new Timecode 00:00:15.080

Ta chyba "PTS diff. 0ms" "PTS diff. 20ms" je nejcastejsi, casto jsou to cele serie GOPu, ktere tak ProjectX vystrihne.
Mimochodem, kterou verzi ProjectX pouzivate?
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 20. 09. 2013, 03:25:27
Přesně tuhle informaci jsem potřeboval. Díky moc.
Používám nejčastěji verzi 0.90.4 (rozzáložkované GUI novějších verzí mi nevyhovuje), ale zjevně to tím není. PX to prostě neumí :-(.

Norma je věc jedna. Jiná věc ovšem je, jestli např. CME nebo ČT vůbec ví o tom, že s tím někteří diváci můžou mít (a podle vašeho příspěvku i mají) problémy a jediné co je potřeba udělat pro to aby ty problémy zmizely, je jemně přenastavit kodér. Negativní efekt (méně účinná komprese?) by byl podle mě naprosto minimální (subjektivně nepozorovatelný) a přínos jednoznačný.

Spíš mi ale přijde to ani nebyl záměr. Prostě Pařízkovi chlapci nevěděli co, proč a jak nastavit, tak tam dali AUTO. Poradit se jak se to nastavuje ve veřejných DVB sítích jinde (a zdá se že jinak úplně všude)? To by ale bylo pod jejich úroveň se na něco ptát zkušenějších kolegů. Že jsou pak za trubky zcela veřejně jim zřejmě nevadí ;-).
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ondřej Caletka 21. 09. 2013, 14:28:00
Zaznamenal jsem to same (Decko/Art, Fanda, Telka, Smichov). Podle meho nejde primarne o problem transportniho toku, ale kodovani obrazku MPEG-2 v raritnim "field encoding" misto bezneho "frame encoding", ktery jsem tu uz popsal (http://forum.digizone.cz/index.php?topic=3061.msg47367;topicseen#msg47367). Ve stejnych mistech, kde ProjectX haze tyto chyby v GOPech, je prave pouzito "field encoding" a ve stejnych mistech se take zasekava Digipal 2.
Díky, tohle vypadá velmi pravděpodobně. V tom vedlejším vlákně jsem to bohužel nezaznamenal. Tohle by nemusel být tak velký problém opravit v ProjectX.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 22. 09. 2013, 09:07:10
Tohle by nemusel být tak velký problém opravit v ProjectX.
Taky mi to tak přijde. Zvlášť když není potřeba snímky fyzicky rekonstruovat (v náhledu by nekompatibilita nevadila, podstatný je výstup demuxu), snad by stačilo po detekci půlsnímkového kódování počet vzorků (v tomto případě půlsnímků) v GOPu vydělit dvěma a pak by následující PTS nejspíš sedět měl. Pokud se do toho pustíte, dejte určitě vědět. Já teď bohužel absolutně nemám čas :-\, ale pokud by s tím byl problém, snad se na chvilku urvu a mrknu na to.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ondřej Caletka 22. 09. 2013, 17:27:42
Tak jsem do toho kódu trochu vlezl. Není to tak, že by PX hodnotu picture_structure zcela ignoroval, nicméně při pasování GOPů provádí kontroly, které nejsou kompatibilní s field encodingem (dále jen FE). Konkrétně vyčítá z každého snímku jeho time reference(TR), a kontroluje, zda nejsou duplicitní (což v případě FE není vadou ale vlastností), a zda počet různých TR odpovídá počtu zakódovaných snímků (což vzhledem k duplicitám neodpovídá). Opravení těchto kontrol tak, aby braly v potaz i FE není triviální, v podstatě to znamená celou tuto část kódu vymyslet znovu a jinak.

Co ale jednoduché je, je vypnutí těchto kontrol. To dělá přiložený patch (proti aktuálnímu CVS). Jen nevím, jestli se tím nějak zásadně nerozbije možnost detekce opravdových chyb ve streamu, ale myslím že ty by měly odchytit kontroly na jiných vrstvách.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 22. 09. 2013, 18:32:25
Dobrá práce! 8) Na vzorku cca 2 GB z Fandy a 1,5 GB z Déčka mi patchnutý PX žádné chyby nehází. Jestli to pořád ještě synchronizuje je možná zatím předčasné hodnotit, ale vypadá to dobře. Fakt díky moc ;).
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 22. 09. 2013, 23:36:37
Pokud to chcete někdo testnout a nechce se vám to buildovat, ProjectX s Ondřejovým patchem je ke stažení zde:

http://ulozto.cz/x5p76D2b/projectx-fe-patch-zip
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: peter30 24. 09. 2013, 15:19:58
Zdravím, přečetl jsem si zdejší nářky a mohu se k nim jen přidat. Mne navíc TS záznam z ČT Art v pc (DVBViewer) zlobí již při běžném přehrávání v MPC, kdy v samotném místě dojde ke zpomalení a rozmazání inkriminovaného místa zaznamu a po krátkém záseku obraz i zvuk poskočí a pokračuje synchroně dále. Daný úsek se pak při ripování pomocí nejen kodeku Xvid prostě a jednoduše zahodí a udělá to co se zde popisovalo u ProjectX a rozjede se video se zvukem. V patchovaném ProjectX se sice dané místo již nevystřihne, ale protože z něho vypadne originální video stream projevuje se v něm chyba záznamu stále. Zajímavé je též například i to, že pokud provedu demultiplexaci originálního videa a zvuku v ProjectX (jakémkoliv) má poté po spojení v programu MKVMerge výsledný soubor najednou velikost jen o něco více než poloviční a problémy při přehrávání zůstavají. U jiných multiplexů a záznamů se to neděje. Jediné co mi pomáhá je sledování záznamu v programu VLC, kde se záseky neprojevují a obraz se zvukem je synchroní po celou dobu. Četl jsem úvodní topic a jsem ochoten věřit, že Vám MPC záznam přehraje v pořádku, protože já sám jsem si ho již v minulosti různě optimalizoval pro DirectX přehrávání, ale nechce se mi věřit, že se jiným při ripování uvedené vadné místo nezahodí. Já jako nástavbu při ripování využívám MeGui a tam to nastavené profily kodeků Xvid a x264 zatím udělali vždy. Jinak můj obvyklý způsob práce se záznamem je obdobný co zde uvedl Ivan z Kolína. U hd záznamu pořízenéhe ze stejného muxu problémy nejsou a pro pořádek uvedu, že záznam ze satelitu těmito problémy netrpí.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Ivan z Kolína 24. 09. 2013, 15:57:30
Zajímavé. Mně se originální TS opravdu přehrává dobře (popravdě to přehrávám v PC jen při testování, jinak používám všelijaké HW playery v rámci LAN, takže jsem si občasného zadrhnutí ani nemusel všimnout) a ProjectX s patchem produkuje uspokojivé M2V + MP2, které po muxu do MPG (bez rekomprese) je při přehrávání v PC i jinde subjektivně bez vad. Váš problém by tedy mohl být až následný, tedy při rekompresi. Je poměrně hodně možností jaký nástroj na to použít (několik AviSynth pluginů, VirtualDubMod ...). Zkuste tedy jiný.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: ivovi 24. 09. 2013, 16:29:28
Pokud to dobre chapu, tak VLC ok, MPC spatny a transkodovani do xvid,x264 spatny. To do sebe zapada. Zalezi co za MPEG-2 dekoder je nastaven v MPC a jaky dekoder MPEG-2 pouzivaji kodeky xvid,x264. Oboje muze byt deafault z windows. VLC pouziva jine. Mam pocit, ze kdyz jsem to testoval, tak byl dekoder MPEG-2 Elecard bez problemu, ale napr. Intervideo a Arcsoft mely problem.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Jan Novák 24. 09. 2013, 18:04:31
Pokud to dobre chapu, tak VLC ok, MPC spatny a transkodovani do xvid,x264 spatny. To do sebe zapada. Zalezi co za MPEG-2 dekoder je nastaven v MPC a jaky dekoder MPEG-2 pouzivaji kodeky xvid,x264. Oboje muze byt deafault z windows. VLC pouziva jine. Mam pocit, ze kdyz jsem to testoval, tak byl dekoder MPEG-2 Elecard bez problemu, ale napr. Intervideo a Arcsoft mely problem.
MPC při defaultním nastavení taky používá vlastní dekodér, který umí DXVA a u něj jsem problém nezaznamenal. Nahrávky byly z DVBVieweru ukládané do mpeg2, ne ts.
Ale na rozdíl od ostatních muxů jsem z muxu4 z klonů Novy nikdy nic nestříhal, tak nevím, jaké problémy by to způsobilo třeba v Nerovision - dělám z SD nahrávek DVD.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Petr Svoboda 24. 09. 2013, 18:30:46
Mne navíc TS záznam z ČT Art v pc (DVBViewer) zlobí již při běžném přehrávání...
Nemůžeš někde zpřístupnit svůj záznam TS, ke zkoušce?
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: peter30 24. 09. 2013, 19:45:12
Prvních 10:00 min. vystřižených z nahrávky pomocí programu VideoReDo TVSuite V4.20.6.619. mají velikost 449 MB. Mělo by jít jinak o původní stream.
http://www.uloz.to/xC3REj4M/09-09_20-20-09_CT+D+++CT+art_Figarova+svatba%2C+Z+prvn%C3%AD+%C5%99ady+%2802%29.ts
Zkrácený výpis (max. 500 varován/errors) z origo ProjectX při demultiplexu nahrávky.
http://www.uloz.to/xtSaEXNX/09-09_20-20-09_CT+D+++CT+art_Figarova+svatba%2C+Z+prvn%C3%AD+%C5%99ady+%2802%29_log.txt
Všiml jsem si, že audio vypadne dlouhé jen 3:14 min. (4,43 MB) a video má délku 10:57 min. (399MB). Člověk pak nechá projet video v programu MKVMerge v.5.8.0, který mi obvykle slouží jen  pro spojení audia a videa bez zásahu do nahrávky a výsledkem je video nahrávka dlouhá 9:34 min o velikosti 151 MB. Uvedené časy a velikosti jsou převzaty z programu MediaInfo. Prostě z mého uživatelského pohledu k nepochopení.
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: pajas2 24. 09. 2013, 20:30:39
Zkusil jsem výše nahraný záznam demuxovat a pak znovu muxnout a zdá se mi, že je to v pořádku. Na chyby při přehrávání ani posun ve zvuku jsem nenarazil. Délka 10:00.
http://uloz.to/xKefNiqP/figarova-svatba-mpg (http://uloz.to/xKefNiqP/figarova-svatba-mpg)
Název: Re:Formální chyby v transportních tocích z muxů 4 a RS7?
Přispěvatel: Petr Svoboda 25. 09. 2013, 09:16:50
Prvních 10:00 min. vystřižených z nahrávky pomocí programu VideoReDo TVSuite V4.20.6.619. mají velikost 449 MB. Mělo by jít jinak o původní stream.
http://www.uloz.to/xC3REj4M/09-09_20-20-09_CT+D+++CT+art_Figarova+svatba%2C+Z+prvn%C3%AD+%C5%99ady+%2802%29.ts

tohle je jen vzdáleně podobné streamu, který lítá ve vzduchu. Takže ti moc nepomůžu.
Stream je vlastně prázdný, jsou v něm jen elementární toky obrazu, zvuku, teletextu. A PAT obsahuje jen odkaz na PMT s navázáním těchto elementárních toků na sebe. Některé vazby se používají původní (PMT->PCR), některé jsou doplněny nově (PAT->PMT). Zkusil jsem to pohnat do nějakých televizí, nový čipset si s tím poradil, ovšem na kabelovém tuneru - kromě absencí a chybějících vazeb, jsem doplňoval PCR a TOT. Je zřejmé, že někde při zpracování jsi původní tok značně osekal. Samotné elementární toky vykazují výpadky, ale nic, co by dobrý dekodér nebyl schopen překonat. Absence času ve streamu ovšem znamená úplnou ztrátu schopnosti synchronizace, TOT (Víme, že správný časový údaj je pro DVB naprosto zásadní ?!). Zvuk okolo správné hodnoty osciluje, někdy se přiblíží více, někdy se zase vzdálí.
Proto bych ti doporučil opustit formát streamu ve zpracování podstatně dříve.
Název: Opravený Project-X pro field-encoded picture
Přispěvatel: Ondřej Caletka 02. 10. 2013, 12:47:04
Opravení těchto kontrol tak, aby braly v potaz i FE není triviální, v podstatě to znamená celou tuto část kódu vymyslet znovu a jinak.
Tak jsem se zamyslel a provedl minimální úpravy tak aby kontroly fungovaly i s field-encoded obrazy. Nyní se ke každému časovému kódu přidá jeden bit za horní půlsnímek a jeden bit za spodní půlsnímek a pak se zkontroluje jestli jsou přítomny oba půlsnímky a jestli jsou zaplněny všechny časové pozice.

Patch je přiložen, poslal jsem ho i na SourceForge, ale nejsem si jist, jestli to tam ještě někdo udržuje.

Kompletní build je zde: http://leteckaposta.cz/677800229