Autor Téma: Formální chyby v transportních tocích z muxů 4 a RS7?  (Přečteno 16274 krát)

Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
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á  :-[.
« Poslední změna: 16. 09. 2013, 00:53:12 od Ivan z Kolína »

Reklama

  • Stálý člen
  • *****
  • Příspěvků: 0


Martin Patera

  • Stálý člen
  • ***
  • Příspěvků: 191
    • Zobrazit profil
    • OK1MJO
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #1 kdy: 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.
 
Zatec-Podmesti JO60SH
www.ok1mjo.com
www.ok0bez.com
DVB-S/S2: stb IceCrypt S4000 HDPVR
Toroidal90, LNB 0.4dB, PreAmp 14dB + 25m koax (9dB/100m),
28E/26E/23E/19E/13E/9E/5E/1W,
Uncommitted Switch 16in/1out EMP-CENTAURI P.168 V2,
DiSEqC 1.1
DVB-T/T2/C: tv Sony Bravia KDL-40EX653


Jan Novák

  • Profík
  • *****
  • Příspěvků: 2 445
    • Zobrazit profil
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #2 kdy: 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.


Petr Š.

  • Stálý člen
  • ***
  • Příspěvků: 158
    • Zobrazit profil
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #3 kdy: 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.


Ondřej Caletka

  • Stálý člen
  • ***
  • Příspěvků: 185
    • Zobrazit profil
    • Oskarův Weblog
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #4 kdy: 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.

Reklama

  • Stálý člen
  • *****
  • Příspěvků: 0


pajas2

  • Profík
  • *****
  • Příspěvků: 724
    • Zobrazit profil
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #5 kdy: 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.
DVB-S: tuner 3x DVB-S2; motor (cca 45°E-cca 10°W); solo 23,5°E/19,2°E
DVB-T: tuner 1x DVB-T; od Krašova přes Ještěd, Krásné po Javořici,  Cukrák + celá Praha
FM: tuner; 5prvková anténa; rotátor
DAB+: Yamaha T-D500
DreamBox 7080 HD s 2 TB HDD (4 tunery)


Ondřej Caletka

  • Stálý člen
  • ***
  • Příspěvků: 185
    • Zobrazit profil
    • Oskarův Weblog
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #6 kdy: 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 je poslední vydání datováno k březnu 2011 a letmý pohled do CVS naznačuje, že se toho moc neděje. 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.


Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #7 kdy: 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í:
  • ProjectX (demultiplex, synchronizace, střih)
  • DGIndex (vyrobí D2V, indexy pro AviSynth plugin DGDecode)
  • VirtualDub (otevřu AVS script s případnými dalšími úpravami)
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.


Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #8 kdy: 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.


ivovi

  • Profík
  • *****
  • Příspěvků: 1 540
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #9 kdy: 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. 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?


Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #10 kdy: 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í ;-).


Ondřej Caletka

  • Stálý člen
  • ***
  • Příspěvků: 185
    • Zobrazit profil
    • Oskarův Weblog
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #11 kdy: 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. 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.


Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #12 kdy: 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.


Ondřej Caletka

  • Stálý člen
  • ***
  • Příspěvků: 185
    • Zobrazit profil
    • Oskarův Weblog
    • E-mail
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #13 kdy: 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.


Ivan z Kolína

  • Člen
  • **
  • Příspěvků: 53
    • Zobrazit profil
Re:Formální chyby v transportních tocích z muxů 4 a RS7?
« Odpověď #14 kdy: 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 ;).