Mea Culpa, NV_Codec = Nvidia PureVideo Decoder (ganz früher name Nvidia DVD Decoder).
Aber um den Codec alleine gehts hier ja nicht. Da hier scheinbar einige Probleme mit den Sender der Pro7 gruppe haben wollte ich nur mal meine kleine erfahrung posten.
Ich bin erst kürzlich auf DVB-C, nutzte zuvor noch DVB-T in verbindung mit dem NV Codec(sowie für DVD), das lief sahne. Als ich dann DVB-C hatte fiel mir recht schnell der umstand auf, das bei den Pro7 Sendern (Sat1, Kabel1, N24, 9Live(der liegt auch auf den Kanal), das in den jeweiligen streams der Sender das Progressiv Frame Flag gelegentlich alterniert, wo es aber oft nicht sollte. Das führt dazu das (bei aktiven Flagreading zb. NV Codec oder Intervideo) dann zwischen dem Filmmodus(Weaving, VideoRenderer 25fps) und Videomodus(2:2 Pulldown oder VideoDeinterlacing je nachdem was die Pulldowndetection so ermittelt, Videorenderer 50fps) hin und her geschaltet wurde. Dies ist äuserst nervig, zumal dann auch teils das nötige videodeinterlacing bei videomaterial fehlte. Also forcierte ich im NV_Codec den Videomodus(umgehen des Flagreading), jedoch kam es dann zu fehldarstellungen, Fieldorder war nich korrekt. Die Fieldorder war immer genau dann nicht korrekt in denen momenten bei denen im Stream das ProgresivFlag gesetzt war( warum auch immer, sollte eigentlich nicht sein).
Summa summarum musste ich für TV mein Heißgeliebten NV Codec gegen den PDVD9 für den Videoteil wechseln, dieser kommt besser klar. Auch auf DSF und Dmax gab es diese erscheinungen, auf DVB-T habe ich hier nur die Pro7Gruppe und die ist hier fehlerfrei.
Also analysierte ich alle Sender auf dem Pro7 Kanal, die Aufnahmen weisen über den TSPE (TransportStream Packet Editor) tausende PTS Gap fehler auf. Bei meinen bisher geprüften Kanälen betrifft es auch DSF, sowie NICk,MTV,Viva, leztere jedoch mit leicht anderen fehleren aber auch tausende am band. Auf dem Selben Kanal wie DSF, MTV, Viva, Nick, sind auch TELE5 und Das Vierte, diese sind 100% fehlerfrei.
Ansehen kann ich mir die Sender der Pro7 gruppe jedoch bisher nach der codec umstellung sehr problemfrei die anderen sehe ich nicht so oft, bisher okay, bis wie schon erwähnt das Formel 1 training auf DSF.
Also macht mal test aufnahmen von euren Problemsender und jagt die mal durch den TSPE, mich würde interessieren ob bei anderen auch diese PTS Gap fehler auftauchen, und ob diese die auslöser für die Problematik einiger hier sein könnten.
Das schöne ist ja das ein Video mit einer länge von einer Stunde, laut PTS nur etwa 5 min lang ist, die PTS daten sind in den Pro7Streams über DVB-C bei mir crap.
Bei mir ist es mit beiden DVB-C KArten auf Pro7 und co so, auch unter MP1.0.2 und auch unter verwendung der TV Software von meiner TT 1501.
Aktuell bei mir für TV:
Audio -> NV PureVideo Decoder
Video ->PDVD9 aus der 1501 Demo Build
Video HD -> PDVD9 aus der 1501 Demo Build
Aktuell für DVD:
Audio -> NV PureVideo Decoder (bei nur DTS ggf. sprung auf MPA) -> Reclock AudioRenderer
Video -> NV PureVideo Decoder
Aktuell für Video:
Audio -> NV PureVideo Decoder (bei DTS ggf. sprung auf MPA) -> Reclock AudioRenderer
Video ->PDVD9 aus der 1501 Demo Build
Video HD-> PDVD9 aus der 1501 Demo Build
Voher hatte ich halt bis auf für HDVideo nur den NV_Codec, luppt so nun bisher auch bei DVB-C sahne, auch mit Arte HD und Anixe HD.
Der Reclock Renderer benötige ich bei Video hauptsächlich für den PalSpeedup von 24p Material auf 25p.
Sowie bei Video und DVD bei Wiedergabe im Film/progressiv Modus (VideoRenderer 25fps) um die resync ruckler mit 50hz ansteuerrung zu vermeiden.
TV läuft nun mit dem PDVD immer im Videomodus(selbst wenn stream von DVB prog. geflagt wäre, was sie zumeist eh nicht sind und wenn dann gehts gerne mal daneben) also mit VideoRenderer 50fps,
das läuft bei mir mit LCD@50hz auch ohne recklock soweit einwandfrei.
Vielen Dank nochmal für deine ausführliche Erklärung - der NV hat allerdings seit dem June 28, 2006 kein update mehr bekommen - das ist natürlich auch nicht so toll.
Heho ich weis jetzt nicht ob dieser Ansatz hier schon mal in den 13 Seiten gepostet wurde, ich habe mich der Tage auch mit einigen Rucklen und Aussetzern bei DVB-C beschäftigt und bin dabei über ein kleines Tool gestolpert. Heißt DPC Latency Checker und ist hier zu bekommen: DPC Latency Checker Damit kann man checken on das System fähig ist Audio oder Videodaten ruckelfrei bzw. ohne Aussetzer zu verarbeiten. Es gab wohl einige Boards die einen Bug hatten und die Latency zu hoch war, wurde dann auch teilweise mit Bios Updates behoben. Hab auch mal zwei Sreenshots angehängt wie es aussehen sollte und wie nicht!
So sollte es aussehen wenn alles sauber ist:
Ist auf nem alten Pentium 4 HT mit 3.0 Ghz gemacht worden.
So sollte es nicht aussehen:
Ist auf nem Dualcore T3200 mit 2x 2.0Ghz gemacht! Ich habe nebenher die Taktfrequenz beobachtet die Ausschläge treten immer dann auf wenn die CPU die Taktfrequenz ändert!
Hab um Strom zu sparen Crystal_CPUID installiert, jedes mal wenn das Tool die Taktfrequenz wechseln gibt es einen kurzen Ruckler...
Allerdings bei mir nur im HD-Bereich, da es hier keine Einstellmöglichkeit gibt, dass Crystal im SD-Bereich ganz unten und im HD-Bereich ganz oben bleibt...
Wir kommen dem Problem langsam auf die Spur. So wie es aussieht ist das Problem gar nicht beim Client gelegen (d.h. TsReader etc.) sondern eher beim TsWriter. Bzw. genauer gesagt sieht es so aus, dass tatsächlich der vom Broadcaster gesendete Stream fehlerhafte Zeitstempel enthält. D.h. dem TsWriter fehlt der passende Workaround die Zeitstempel zu korrigieren.
Wenn man sich eine Aufnahme von MP im VLC angeguckt und dabei das Message-Window laufen lässt werden massiv viele Fehler ausgegeben und das Bild ruckelt regelmäßig. Allerdings liefert bei mir eine Aufnahme mit DVBViewer im TS format das gleiche Ergebnis. MPG funktioniert allerdings wiederum einwandfrei.
Außerdem habe ich gerade ein wenig rumprobiert und rausgefunden, dass wenn man ne Aufnahme von MP demuxed und remuxed die Probleme weg sind. D.h. im Klartext, dass man das Problem generell in Griff bekommen kann, allerdings müssen wir noch rausfinden wie genau und dann noch nen weg finden den Workaround zu implementieren ohne die Funktionalität vom Rest zu gefährden
Danke für den Statusbericht und toll, dass daran gearbeitet wird. Ich denke, es ist generell sinnvoll eigene Zeitstempel zu setzen - man weiss ja nie, was da so ausgestrahlt wird