arte HD h264 Bitstream bringt dgavcindex 1.0.9 zum Absturz

Ein Verdacht ohne weitere Analyse: DGAVCDec unterstützt mit seiner etwas veralteten libavcodec-Version nur MBAFF-Interlacing. PAFF führt oft zwar zu Bildfehlern, Abstürze sollten aber nicht gerade die Regel sein...

Vielleicht mal den Stream durch Cypheros TS-Doctor laufen lassen,...

DGAVCDec wird nicht weiterentwickelt.

Zumindest nicht solange die Programmierer von libavcodec nicht das Problem selber korrigieren, das Großmeister Donald Graft höchstselbst in deren Code entdeckt haben will, was verantwortlich für unvorhersehbare Frame-Verluste sei ... oder einer der Programmierer von anderen, schnelleren Decoderfiltern nicht eine API (Programmierschnittstelle) bereitstellt, mit der ein zukünftiges DGAVCDec diesen dann für frameakkurate Decodierung nutzen könnte.

Angeblich gibt es bereits Gespräche mit schweinsz, dem Programmierer von DiAVC. Sein Decoder soll zwar kommerziell werden, aber versprochenermaßen billig...

Würde sonst den Input mal per ffmpegSource laden,..

tach! habe das selbe problem mit aufnahmen bei ard & zdf hd! die senden auch in 720p mit 50 fps. die einzige möglichkeit, die ich habe ist mit das ganze mit staxrip in der "aktuellen" preview8 mit directshowsource umzuwandeln. dgavcindex funktioniert überhaupt nicht. weder automatisch (über staxrip) noch manuell! macht zwar den umweg über wav-datei in virtualdub aufzeichnen, aber ist bei mir die einzige methode die funktioniert! die previe8 hat bei mir auch bisher keinen fehler oder absturz verursacht!

Ich hab ja bisher auch die ganzen ÖR-HD-Aufnahmen mit Staxrip recodiert bis ich heute das gelesen habe. Ich habe dann die Aufnahme mit tsMuxeR demuxt und mit mkvmerge als mkv neu gemuxt und siehe da, die Dateien waren größtenteils nur noch halbsogroß wie die ts-Dateien.

hatte die aufnahme mal mit h264tsto in mkv umgewandelt und dann war die datei auch 2 gig kleiner. interessanter bericht!!! können dadurch eventuell auch die abstürze von dgavcindex erklärt werden??

edit: mkv löst das problem auch nicht. der video-stream führt bei dgavcindex scheinbar grundsätzich zum absturz!

Da wird nur remuxed, aber der .m2ts/.ts Container hat je nach Inhalt einen sehr hohen Overhead.

Aber der muss schon ziehmlich viel entfernt haben.

Die aufgenommene ts hatte zeigte eine konstante Bitrate so um die 12 Mbit an und die geremuxte mkv hatte dann eine variable Bitrate.
z.B. arte HD Aufnahme von Rampenlicht hatte als ts 12 GB und dann geremuxt als mkv nur noch 6 GB

Hat doch nichts mit Overhead zu tun.
Der Stream ist halt CBR gemuxt um Bufferprobleme zu vermeiden. Es werden im TS-Stream Null-Pakete eingefügt um eine vorgegebene Datenrate zu halten.
Nach dem Neumuxen als VBR-TS oder in einen anderen Container sind diese Füllbytes natürlich weg.
Kann man z.b auch mit tsMuxeR erstellen (General - Mux CBR).

Stimmt, Füllbytes gibt's ja auch noch. (Wobei mir ihr Sinn aber irgendwie verschlossen bleibt.) Der reine ContainerOverhead von .m2ts/.ts ist trotzdem ein Verbrechen. (und Füllbytes könnte man durchaus auch als Overhead bezeichnen);)

Je kleiner die Pakete, umso mehr Paket-Header pro Gesamt-Dateigröße. Und ein Transport-Stream hat nun mal "den kleinsten".

Unf Fülldaten sind kein Multiplexing-Overhead, weil sie nicht zum Zweck des Multiplexings notwendig sind. Sie dienen nur dazu, die Datenrate scheinbar konstant zu halten -- damit sich der Decodierpuffer nicht zu schnell füllt und der Decodier-Zeitpunkt (Decoding Time Stamp, DTS) dem Abspiel-Zeitpunkt (Presentation Time Stamp, PTS) nicht allzu weit vorauseilt ... anscheinend ist es wohl nicht so ganz einfach, weniger Nutzdaten tatsächlich einfach mal bloß später zu senden.

Naja, ist vermutlich wie der ganze DVB Container-Kram vor allem darauf ausgelegt mit irgendwelcher alten Hardware (vermutlich Satelliten) noch kompatibel zu sein.

Zitat von bigotti5

Hat doch nichts mit Overhead zu tun.
Der Stream ist halt CBR gemuxt um Bufferprobleme zu vermeiden. Es werden im TS-Stream Null-Pakete eingefügt um eine vorgegebene Datenrate zu halten.
Nach dem Neumuxen als VBR-TS oder in einen anderen Container sind diese Füllbytes natürlich weg.
Kann man z.b auch mit tsMuxeR erstellen (General - Mux CBR).

Ich habe ARTE HD Dokus durch TS Doctor, multiAVCHD und ImgBurn auf BD-9 gebannt. Die Grossen der Dateien waren ziemlich gleich (Overhead betrachtet), der BD Player zeigte aber eine schwankende BitRate (zB von 5 bis 20 Mbps). Bin ziemlich sicher das TS Doctor und tsmuxer (von multiAVCHD, normalerweise auf Mux VBR eingestellt) den Datenstrom schon bereinigt haben, wie hier -> http://forum.digitalfernsehen.de/forum/hd-tv-di…hd-bitrate.html.

Vielleicht kann man das erklären.

Hallo zusammen.
Hatte das selbe Problem mit aufnahmen von ARD HD, ZDF HD und Arte HD! mit dgavcdec_info.
Problemlösung für mich war die kostenpflichtige Version dgdecnv2001 habe eine NVIDIA 8800GT mit CUDA Unterstützung Nebeneffekt 50% schneller Encodieren. Die 15$ sind es mir wert.

HD SUISSE sendet auch in 720p mit 50 fps. da hatte ich noch nie Probleme wie auch bei ANIXE HD und BBC HD ging alles ohne Probleme.