AMD/ATi UVD with bad H.264 error concealment

[CiNcH]

AMD/ATi UVD with bad H.264 error concealment

 

 

Live streams via satellite are always more prone to errors, for example due to the influence of weather conditions. But also buggy encoders/muxers or reading a polluted disc may lead to garbled data. The audio/video processing chain has to cope with it and conceal errors as good as possible during playback.

 

I found major weaknesses in the error concealment of ATi's Unified Video Decoder (UVD) or the bitstream parser being used in case of H.264. This was tested with Radeon HD 3000, 4000 and even latest 5000 series GPU's. It seem that all GPU's with UVD/UVD2 are affected.

 

Here you'll find a short sample clip (TransportStream file with H.264 Main Profile @ Level 4.0 at 720p50 resolution) to reproduce the mentioned weakness (of course UVD has to be used for decoding). The sample is explicitly trimmed to only show the error to make testing easier. Directly at the beginning of the trimmed sample (as we will find out later most likely at 00:00:01,72; frame #87 in GOP #6), UVD stumbles over a glitch in the H.264 bitstream and will produce artefacts from then on (see figure 1). When jumping past this glitch, decoding is fine for the rest of the sample. The glitch is rather small and UVD simply does not recover from it.

 

Figure 1 - Corruption with UVD

When analyzing the sample with TMPGEnc 4.0 XPress, one may find out that its software decoder eliminates frames #87 to #97 (timecode 00:00:01,72 till 00:00:01,94). At least frame #87 seems to be erroneous as we will find out later. As a consequence, TMPGEnc replaces all remaining frames within this GOP with the last intact frame (#86), see figure 2. Frame #87 is a copy of the intact frame #86. The next original frame, which is not a copy of frame #86, is #98, belonging to the following GOP.

 

Figure 2 - TMPGEnc - Erroneous GOP

Stepping through the frames with MPC Home Cinema reveals that frame #87 indeed seems to be erroneous (MPC Home Cinema does not skip anything), see figure 3. This frame is most likely the mentioned glitch that UVD stumbles over.

 

Figure 3 - Glitch within the H.264 bitstream

Several software H.264 decoders perfectly conceal this error (ffdshow/ffmpeg, CoreAVC, DiAVC). But what is even more important is that nVIDIA's video processor (PureVideo) also DID NOT show any weaknesses, tested with a GeForce 8600 GTS. The glitch is not visible at all. Only stepping through the sample frame by frame with MPC Home Cinema reveals the little corruption in the GOP that TMPGEnc skipped.

As H.264 decoder taking advantage of UVD, one may want to use CyberLink, ArcSoft, MS or MPC to reproduce the problem. 'ATi MPEG Video Decoder' does not seem to apply DXVA for this sample. So it is just another software decoder that will play the sample just fine. UVD is not used with this decoder!

 

Depending on the Catalyst driver version being used, the outcome of the error is different. Catalyst drivers < version 9.5 would produce an endless loop when the glitch occurs. Newer driver versions produce artefacts (see figure 1) until UVD is "reset" (by clearing DXVA buffers?). So it seems that ATi already tried to tackle the issue, the "fix" is not too effective however.

 

As mentioned earlier, playback (or UVD) does not recover by itself. One has to execute a little jump within the player application to resolve the issue (which is not always easy in case of a live stream). The reason may be that DXVA buffers are cleared in case of a position change.

 

As the above sample is a recording from a DVB live stream (ORF 1 HD), I also analyzed on a TransportStream (TS) level whether there are errors in it. The packet sequence is complete, so nothing is missing. The FEC circuit of a DVB demodulator should make sure that packets which it could not repair are rejected. Or at least it should set the 'Transport Error Indicator' (TEI) within the affected TS packets. In the latter case, the TS demuxer would evaluate this field and skip the packet in case of an error. Both did not happen as one can see in figure 4. But it may very well be that the demodulator did neither even if FEC could not repair a packet.

 

Figure 4 - Analysis on a TransportStream level

So it may still be a transmission error (even though the TS Analyzer can't see it) or a H.264 coding error. The latter was also reported with some Blu-Ray Discs, where UVD also stumbled over. Either way, UVD should be able to handle this just like all software decoders and even nVIDIA's PureVideo do.

Edited February 10, 2010 by CiNcH

[CiNcH]

Mal ein paar aktuelle Infos dazu... (der Beitrag oben ist übrigens auf Englisch, weil ich in meinem Blog versuche, damit so viele Menschen wie möglich zu erreichen)

 

Die Engländer scheinen mit ihrem BBC HD auf dieselben Probleme gestoßen zu sein und stehen bei ATi schon auf der Matte. Mit dem Catalyst 10.2 RC2 hat sich auch schon etwas getan und der UVD/H.264 Bitstream-Parser stolpert nun zumindest bei dem mir vorliegenden BBC HD Sample im WMC WTV Format nicht mehr. Mein ORF 1 HD Sample wird leider immer noch gleich fehlerhaft abgespielt .

[Portisch]

Super!

 

Das habe ich auch schon öfters gesehen. Hatte keine Ahnung woher das kommt.

Dann bin ich mal gesapnnt ob die das hinbekommen.

[craig_s]

Hey mach mal in der Überschrift aus Ati AMD sonst denken die internationalen das wär von vorgestern..

[craig_s]

Cinch, deinen neuen ATi UVD vs. nVIDIA VP Blog find ich ganz hervorragend und ich überlege auch dauernd hin und her was ich nehmen soll.

International gesehen: Ich hab immer gedacht die Panikmacher stizen alle in central Europe aber AVS hat mich eines besseren belehrt - sie sind in rauen Massen überall auf der ganzen Welt. Deswegen hat die Nvidia Alternative grad schlechte Karten, alle stürzen sich wie die Lemminge auf HD Audio Bitstreaming (HD 5xxx) dabei hat warsch. nur 2% überhaupt ne Anlage um den Unterschied schwach zu hören, aber davon spricht niemand... Nvidia kann momentan scheints *nur* LPCM und braucht mehr Watt. Ausser ein paar bissigen Kommentaren da und dort bei denen ich gerne das ganze AVS als nicht weniger als nen Haufen Wahnsinniger bezichtige fällt mir nicht mehr ein. Immerhin nehmen sie's locker, das find ich jetzt wieder gut an den Amis.

 

Da du da aktiv wirst behalte also auch den tagespolitischen Modeaspekt im Auge, Top oder Flop, das kann sich praktisch stündlich ändern obwohl das dann meistens garnix mit dem zu tun hat was du eigentlich wissen wolltest.. Fakten und Argumente verpuffen schnell obwohl natürlich jeder die anführt, wie eine flüchtige Bugwelle. Das erinnert mich dran wie vor paar Jahren die Passantin zum Agitator des Bush Kontahenten Al Gore (der später den Friedensnobelpreis bekam) sagte "Al Gore? Den wähl ich nicht weil - der gewinnt doch nie..".

Edited February 14, 2010 by craig_s

[CiNcH]

Es ist wirklich verflixt. Ich komme auch auf keinen grünen Zweig. Für mich scheidet eigentlich jede aktuelle GPU aus, weil ich gerne PowerStrip-Support für 'Custom Timings' hätte. Ich habe es bereits mit 'EDID Overrides' und mit dem Timing Utility im nVIDIA Control Panel probiert. Aber mit keiner dieser Methoden kann man die Pixelclock fein genug einstellen. Bei ATi ist die Wahrscheinlichkeit dank OSS/Open Specs Initiative aber größer, dass die Unterstützung noch kommt.

 

Vom Video-Prozessor bzw. der Treiber-Unterstützung desselben ist nVIDIA ganz klar besser.

 

Wie praktikabel diese ganzen Video Post-Prozessoren von ATi/nVIDIA sind, weiß ich nicht. Temporales Deinterlacing machen wohl beide ganz gut und es wird auch direkt nach der Dekodierung an der richtigen Stelle ausgeführt. Rauschen zu unterdrücken hatte ich bei DVB/DVD/BD Content noch nie das Bedürfnis für. Schärfefilter wird an der falschen Stelle auf das Bild losgelassen, nämlich im DXVA-Kontext, wo das Bild noch nicht hochskaliert wurde. Durch die Schärfung eingeführte Artefakte werden also mit hochskaliert. Halte ich also auch in beiden Fällen (nVIDIA/ATi) nichts von.

Da würde ich mir mehr Lösungen außerhalb von ATi/nVIDIA wünschen, wo man mehr Transparenz über die Funktionalität der Filter hat und auch eine sinnige Kette von Post-Prozessoren selber erstellen kann.

Das von ATi beworbene DVD Scaling auf HD-Auflösungen kann man übrigens knicken. Das Scaling wird immer zum Schluss im Renderer ausgeführt. Da verwenden wahrscheinlich alle aktuellen Renderer den bilinearen Filter in DirectX. Was ATi damit meint ist, dass mittels ArcSoft SimHD und der durch die GPU zur Verfügung gestellten Rechenpower es möglich ist, SD auf 1080p hochzuskalieren, siehe hier.

 

Bist jetzt habe ich das Bitstreaming komprimierter Audiodaten strikt vermieden, weil durch die unterschiedliche Zeitbasis von GPU und APU man in die rohen Audio-Frames eingreifen können muss, um das zu kompensieren (ReClock, bzw. Rate-Matching im DirectSound-Renderer). Aus genau diesem Grund (unterschiedliche Zeitbasis) könnte es natürlich revolutionär sein, GPU und APU zu konsolidieren, denn dann ist erst eine vernünftige Synchronisation gegeben, egal ob Bitstreaming oder LPCM. Wenn man denn so eine HD-Audio-Anlage hat, ist natürlich PaP eine feine Sache, damit man das Bitstreaming auch für geschützte BD's in den gängigen Playern verwenden kann. Das kann halt im Moment nur ATi. Aber bis es bei mir soweit ist, habe ich aus Frustration wahrscheinlich schon wieder zigmal die Grafikkarte gewechselt.

Praktisch weiß ich aber nicht, wie gut das läuft. Hängt auch wieder vom Treiber ab. Wer weiß, vielleicht werden GPU-Kern und RealTek-APU sogar noch von unterschiedlichen Quartzen gespeist .

 

Bei ATi ist meiner Meinung nach noch hervorzuheben, dass es einfach bessere Boards mit effektiveren und gleichzeitig leiseren Kühllösungen gibt und der Shaderdurchsatz bei gleichzeitig kleinerem Verbrauch höher ist, was Video Post-Processing und GPGPU zugute kommen könnte.

Edited February 14, 2010 by CiNcH

[CiNcH]

Im AMD/ATi-Forum wurde das Thema gelockt, weil immer mehr Leute das Problem bestätigt haben. Die letzte Meldung von einem Moderator war:

I already said it will be improved in the future, that wont be any time soon.

Na dann schauen wir halt mal, wieviele Jahre noch ins Land ziehen..

[craig_s]

Aber immerhin, du hast es bis dort hingetragen! Schade das AnandTech mit ihrem "Roten Telefon zu AMD" (noch) nicht drauf angesprungen ist.

Um das Thema anzuschärfen müsste man jetzt genauer bestimmen welche Fehler in der Übertragungskette die Glitches auslösen, was ohne laborähnliche Bedingungen schwer ist. Eine riesige Leidensgruppe ist die WTV-Fraktion, wo ich das Thema mal eingebracht habe. Wie man im ARD und ZDF HD Thread mal wieder sieht löst der MS Decoder bei 720p Artefakte aus.

 

Die Frage ist kann ein fehlerhafter Decoder Glitches an den UVD liefern? Jedenfalls ist auffällig, dass die WTV-Leute alle ihr DXVA abstellen mussten damit die Artefakte verschwinden mit den Nachteilen, die fehlendes DXVA mit sich bringt. Da sie beobachteten, dass es mit Nvidia nicht klötzt und auch evl. aufgrund deines Threads fangen sie jetzt mit Beschwerden an Ati an. Da machen die Olympics jetzt noch mehr Druck. Sie haben nämlich keine Chance auf Wechsel zu Cyberlink, ich durfte mich belehren lassen: "da im Windows 7 der MS-Decoder für WTV zwingend vorausgesetzt wird (das ist wie eine Art von Kopierschutz den bisher keiner "geknackt" hat)." -- hier

 

Ganz nebenbei, FFDShow kann jetzt DXVA (H.264 + VC-1), leider haben sie wohl nur den MPC Decoder eingebaut, d.h. DVBViewer stürzt damit ab, schade..

Edited February 16, 2010 by craig_s

[nuts]

Ganz nebenbei, FFDShow kann jetzt DXVA (H.264 + VC-1), leider haben sie wohl nur den MPC Decoder eingebaut, d.h. DVBViewer stürzt damit ab, schade..

Hey,

 

DXVA -> Deinterlacing per GPU -> FFDShow für den Rest geht aber weiterhin nicht oder? Also sobald man im DXVA-Sprudel steckt ist man aufs GPU Processing angewiesen (+Shadereinsatz je nach Software).

[CiNcH]

DXVA -> Deinterlacing per GPU -> FFDShow für den Rest geht aber weiterhin nicht oder?

Man kann prinzipiell die DXVA-Puffer zurücklesen. Die CPU-Zyklen, die man sich aber durch DXVA spart, gehen dann für die Kopierei drauf (je nach CPU und SIMD-Unterstützung kann das Kopieren sogar erheblich mehr CPU-Zyklen beanspruchen). Das ganze ist nicht wirklich praktikabel. Was ffdshow aber ganz gut macht, und das auch relativ schnell und ohne viel CPU-Zeit, ist so eine Art OSD über das Bild zu blenden (e.g. für applikationsunabhängiges Rendern von Untertiteln trotz DXVA).

Edited February 16, 2010 by CiNcH

[Griga]

The packet sequence is complete, so nothing is missing.

Wahrscheinlich. Wenn in einem Stream mehrere aufeinanderfolgende TS-Pakete fehlen (also ein zusammenhängendes Stück), deren Anzahl ein Vielfaches von 16 beträgt, wird dies nicht als Lücke erkannt, da der continuity_counter in den TS-Paketen mit seinen 4 Bit ein Modulo 16-Zähler ist, d.h. er läuft von 0 bis 15 und springt dann auf 0 zurück.

[craig_s]

Wow, CPU-Zyklen, Modulo...

 

DXVA -> Deinterlacing per GPU -> FFDShow für den Rest geht aber weiterhin nicht oder? Also sobald man im DXVA-Sprudel steckt ist man aufs GPU Processing angewiesen (+Shadereinsatz je nach Software).

H.264 bis 1080 i und p läuft.

VC-1 bis 1080 nur p.

 

Also genau wie MPC Video Decoder.

 

Postprocessing und sonst. Features vorläufig wenige, starte es halt mal, dann siehstes.

Einige waren glücklich unter best. Bedingungen im WMC erstmals Untertitel damit zu sehen.

 

 

PS. Cinch bin ganz gespannt auf die WTV-MS Decoder Geschichte, sorry, keine Drängelei

Edited February 16, 2010 by craig_s

[CiNcH]

PS. Cinch bin ganz gespannt auf die WTV-MS Decoder Geschichte, sorry, keine Drängelei

Welche Geschichte? Habe ich was verpasst? Gibt es was zu tun?

[craig_s]

... Die Frage ist kann ein fehlerhafter Decoder Glitches an den UVD liefern? ...

s. Post #8

Wenn ja könnte man das den WTV-Leuten erzählen, das würde sie zwar nicht "retten" aber den Feldzug Richtung AMD jedenfalls anheizen und weiter Licht ins Dunkel bringen usw..

[CiNcH]

Die Frage ist kann ein fehlerhafter Decoder Glitches an den UVD liefern?

Ehrlich gesagt tu ich mir etwas schwer, den Schuldigen zu entlarven. Ich weiß zu wenig über die Inner-Workings von DXVA. IMHO ist der Schuldige der Bitstream-Parser, welcher die Häppchen für den Dekoder/UVD (wohl die komprimierten Daten eines zu dekodierenden Frames) aufbereitet. Bei einem Glitch stolpert der und liefert anschließend fehlerhafte Häppchen an den Dekoder/UVD. Wo das aber gemacht wird, weiß ich nicht. In Frage kommen DirectShow-Wrapper (CyberLink, ArcSoft, ffdshow/MPC, MS usw.), wobei ich das in meinem Fall fast ausschließe, weil die Wahrscheinlichkeit, dass alle denselben Mist veranstalten, relativ klein ist, DXVA (also die MS-Zwischenschicht) oder ganz unten der Grafikkartentreiber.

 

Kann also schon sein, dass da im Wrapper ein fehlerhaftes Parsing gemacht wird. Im Fall von nVIDIA wird evtl. auf Treiberniveau dieser Vorgang wiederholt und der Fehler korrigiert. ATi hat ja bereits von einem Workaround im nVIDIA-Treiber gesprochen...

 

Wie man im ARD und ZDF HD Thread mal wieder sieht löst der MS Decoder bei 720p Artefakte aus.

Bei mir ist das wie gesagt mit allen DXVA-Dekodern reproduzierbar, wie du auch selber schon festgestellt hast. Ich traue da nicht allen Aussagen. Es haben schon mehrere geglaubt, das Problem durch den Wechsel des DirectShow-Wrappers (oder durch Treiberwechsel) im Griff zu haben. Dann war halt vielleicht mal eine Zeit lang kein Glitch im Stream. Mit einem Sample, wo ein Glitch drin ist, kann man das besser reproduzieren, wie auf so einen Fall zu warten.

 

 

WTV ist das TV-Modul in WMC?

Edited February 16, 2010 by CiNcH

[CiNcH]

Kann also schon sein, dass da im Wrapper ein fehlerhaftes Parsing gemacht wird. Im Fall von nVIDIA wird evtl. auf Treiberniveau dieser Vorgang wiederholt und der Fehler korrigiert. ATi hat ja bereits von einem Workaround im nVIDIA-Treiber gesprochen...

Auf Grund der Tatsache, dass die Dekoder im SW-Modus dann doch problemlos arbeiten, würde ich das Problem doch eher in Richtung MS bzw. ATi schieben. Ob nVIDIA da einen Workaround für ein MS-Problem drin hat, wage ich auch zu bezweifeln. Ich tendiere doch sehr stark zu ATi-Problem...

[craig_s]

Wiki:

WTV is the new container format used to record television shows in Microsoft Windows Vista Media Center starting with Windows Media Center TV Pack 2008.

 

WTV is the successor of DVR-MS which is is being replaced with WTV since the introduction of Windows Media Center TV Pack 2008.[1][2] WRT is also the default recording format for Windows 7 Media Center, its video encoder will support encoding to H.264 1-pass CBR Baseline profile up to 1.5 Mbit/s, 640x480pixels at 30 frame/s, and the aadio encoder will support low complexity AAC stereo at 44.1 or 48 kHz sample rate and 96, 128, 160 or 192 kbit/s bit rate.

Betroffen ist TimeShift bzw. Wiedergabe, ob auch LiveTV weiss ich nicht:

 

Bei Live-TV und TV-Aufzeichnungen von HD-Sendern (hier Arte HD) wird in anderen Threads von sehr groben Kästchen auf den schnell veränderten Bereichen des Bildes berichtet. Das Problem tritt häufig, aber nicht immer, nach dem Vor- oder Zurückspringen im Film auf. Wenn man dann noch zwei, drei mal mehr 7 Sekunden zurückgespringt, ist das Bild wieder klar. Die Aufnahmen sind dabei ok und beim Wiederholen der Stelle fehlerfrei. Das Problem ist die Wiedergabe.

Das klingt schon so, als ob im aufgenommenen Video Glitches sind. Auch *beim Wiederholen der Stelle fehlerfrei*, ändert daran nichts, da der BadFrame ja weiter vorne gewesen sein könnte.

[CiNcH]

Das WTV-Format kenne ich:

 

Riecht doch sehr nach DRM .

Edited February 16, 2010 by CiNcH

[craig_s]

Bei mir ist das wie gesagt mit allen DXVA-Dekodern reproduzierbar, wie du auch selber schon festgestellt hast. Ich traue da nicht allen Aussagen. Es haben schon mehrere geglaubt, das Problem durch den Wechsel des DirectShow-Wrappers (oder durch Treiberwechsel) im Griff zu haben. Dann war halt vielleicht mal eine Zeit lang kein Glitch im Stream. Mit einem Sample, wo ein Glitch drin ist, kann man das besser reproduzieren, wie auf so einen Fall zu warten.

Nein, die Aussagen tendieren zu MS-Decoder weg, jetzt läufts dauerhaft super (DVBViewer's LiveTV + Aufnahme). ABER, es sieht natürlich anders aus bei Leuten mit möglicherweise - schlechtem Sat-Empfang, CI-Modulen usw., das wird wohl alles noch mit reinpinkeln.

Edited February 16, 2010 by craig_s

[craig_s]

Das WTV-Format kenne ich:

 

Riecht doch sehr nach DRM .

Tja, es ist aber nur H.264 720p auf Ati betroffen, alles andere läuft...

Edited February 16, 2010 by craig_s

[CiNcH]

Kann ich selber nicht beurteilen, weil ich selber eigentlich nur auf 720p Kanälen schaue. Aber BBC HD ist soweit ich weiß nicht 720p. Da hab ich ein Sample, das ebenfalls verpixelt..

Edited February 16, 2010 by CiNcH

[gwr]

Bin ja nur ein Laie. Wenn ich mir diese fehlerhaften Videostreams so anschaue, dann sieht es für mich so so aus, als ob dort nach einem Fehler immer wiederkehrende alte Daten zur Berechnung der neuen Bilder hergenommen würden. Eine Endlosschleife im Hintergrund sozusagen.

 

Eine Unterbrechung im zeitlichen Ablauf,durch vor- oder zurückspulen bzw. bei LiveTV im DVBV. durch Video/Audio deaktivieren/aktivieren = Graph Stop/Play, sagt dem Decoder dann vergiss alles und fang bei null an. (sehr laienhaft ausgedrückt) das ist mein Eindruck.

 

Was der MS-Decoder da mit den 720p Sendern fabriziert, kann ich nicht beurteilen. Bei mir unter Windows XP laufen ARD-, ZDF-, arte-HD mit dem H.264-Decoder aus PDVD 9/1501 oder dem Cyberlink-Combi-Decoder (aus der bekannten Quelle) wie der Teufel. HD 3650 AGP mit CAT 9.9 AGP-Hotfix (OT: der letzte mit brauchbaren Installer )

Edited February 16, 2010 by gwr

[craig_s]

Dienen Eindruck teile ich gwr, einleuchtenderweise sieht es so aus. Und die grosse *720p mit Cyberl. läuft wie der Teufel* Gemeinde, zu der ich auch gehöre, zeigt doch dass es geht.

 

Da hab ich ein Sample, das ebenfalls verpixelt..

Warsch. gibts da auch ein Forum, das sich beschwert? Schauen die mit Cyberlink?

 

Leider kann ich mit XP immer nur anregen. Aber wartet nur, wenn mir mal Win7 in die Hände fällt - dann lass ich Feuer und Schwerter regnen...

[CiNcH]

Warsch. gibts da auch ein Forum, das sich beschwert? Schauen die mit Cyberlink?

Das ist ein WTV-Sample. Weiß jetzt nicht, ob ich da was anderes als MS in den Graph bekomme.

 

Bei mir ist das Problem auch nur noch seeeehr selten! Früher hatte ich es öfter. Ich ändere aber täglich so viele Sachen, die den Empfang bzw. die Fehlerträchtigkeit des Signals beeinflussen. Ich kann also keine Schlüsse mehr darüber ziehen, wer da nun zur Verbesserung beigetragen hat. Hier hat jemand das Problem auch mit Anixe. Auch ein interessanter Beitrag, wo auch der Demuxer eine Rolle spielt. Der kann natürlich auch Glitches verursachen...

Edited February 16, 2010 by CiNcH

[craig_s]

Mei liiieber Mann, da ham se dich jetzt zugeschmissen mit Arbeit, aber ich hab dich gewarnt..

Wäre nett, könntest du mir denen ihr Test rar auch mal pn'en? Da wär ich echt heiss drauf!

Edited February 16, 2010 by craig_s

[CiNcH]

Ich habe keine Samples. Bin auf demselben Stand wie du. Ich werde die Probleme und den Grafikkartenkauf jetzt erstmal aussitzen...

[nuts]

Naja am mpeg2 oder h.264 decoding wirds wohl eher nicht liegen. Zumindest gibt es genug hardware die es fehlerfrei vormacht

[CiNcH]

Ohaa, das BBC HD WTV Sample ist wohl MPEG-2 . Mit Catalyst 10.2 läuft das nun ohne Artefaktbildung durch. Ich blick da gar nicht mehr durch... Mein Sample macht nach wie vor Stress.

Edited February 17, 2010 by CiNcH

[craig_s]

Ich sag doch immer, die Übergänge sind fliessender als man denkt. Nichts ist unmöglich bzw. das ist wohl die Antwort drauf warum 10.2 BBC heilen konnte 720p H.264 mit MS Decoder nicht. Selbiges Prob dürfte sogar in der weltweiten Rangordnung rel. weit unten stehen, da ist MPEG-2 viel verbreiteter..

[CiNcH]

Wie bekommt man aus so einem WTV-File den Video-ES heraus? In den MS DRM Graph bekomme ich nichts anderes als MS Dekoder hinein. Das ist doch echt der Gipfel, wie MS das ganze DirectShow unter W7 vergenusszwergelt...

 

Mich würde interessieren, was bei dem Sample mit CyberLink + DXVA passiert, Catalyst 10.1 vs. 10.2.

Edited February 18, 2010 by CiNcH

[CiNcH]

Also ich kann mit dem BBC HD WTV Sample rein gar nichts anfangen. Diverse Tools sagen, die im Container befindlichen Streams würden nicht unterstützt werden.

 

Im Default-Graph verbindet sich der MS-Dekoder über 'MEDIASUBTYPE_MPEG2_VIDEO'. Hänge ich einen anderen MPEG-2 Dekoder hinter den Filter 'PBDA DTFilter', z.B. CyberLink, kommen scheinbar keine Daten mehr beim Dekoder an, oder er kann nichts damit anfangen, weil es gar kein MPEG-2 ist.

 

Ich bezweifle, dass da wirklich MPEG-2 drin steckt. Im AMD Forum ist die Lösung ja die Dekodierung von H.264 über den UVD abzuschalten. Könnte man noch probieren... Die mittlere Datenrate ist laut Media Player 10.57 MBit/s bei 1440x1080. Über das Format schweigt sich jeder aus..

 

Was unflexibleres wie dieses WTV-Format habe ich noch nicht gesehen, DRM halt. Ich frage mich echt, was man an diesem WMC finden kann...

Edited February 18, 2010 by CiNcH

[gwr]

Ich glaube nicht das sich mit dem 10.2 viel geändert hat. Ich habe den normalen Catalysttreiber gestern abend mal meiner 3650 agp aufgedrückt.

Vorher CCC deinstalliert die ID in die Inf reinkopiert und einfach den Treiber aktualisiert. Ohne CCC erstmal. Läuft soweit. Die Ergebnisse sind so natürlich nicht gerichtsverwertbar.

Aber wenn ich mein Fehlervideo von Astra HD (von 2009) wieder mal teste, dann verhält sich der normale 10.2 ganz genauso wie der 9.9 agp hotfix.

Das Video ist recht lang (300MB) und hat glaube ich 3 Stellen mit Fehlern. Manchmal läuft es problemlos durch. Spätestens nach einigen Wiederholungen des Videos, dann kommen die Artefakte und irgendwann dann ein einfrieren mit BSOD mit einer ati...dll

(das Abstürzen kann jetzt auch was mit meiner alten Kiste hier sein)

Wie gesagt, absolut unverändertes Verhalten.

Edit: vergessen zu schreiben, abgespielt mit DVBViewer und Cyberlink-H.264 decoder

 

 

OT: es gibt ja jetzt auch den agp-hotfix 10.2 da habe ich ehrlich gesagt nach den letzten 4 keinen grossen Bock mehr.

Beim 9.11 lies sich das CCC nicht starten, irgend was mit MOM...... konnte nicht gestartet werden. Alles mögliche probiert, diese VC++ 2005 und 2008 Dinger deinstalliert und wieder neu, hat alles nix gebracht. Den 9.10 hatte ich erst danach probiert, das gleiche.

Bei der 9.12 installiert der Manager nur das CCC, nicht den Treiber. Er installiert nur signierte Treiber, AGP-hotfix Treiber waren noch nie signiert.

Den Treiber muss man dann extra von Hand installieren. Wenn mans weiss. Oder man nimmt eine gemoddete Version, die ein User im Catalyst-Forum zur Verfügung stellt.

Beim 10.1 noch mal der selbe Quatsch mit dem Manager.

 

Deshalb (gilt nicht nur für ATI): mache niemals aus einem Wizzard, Helfer oder Dienstprogramm einen MANAGER! geht schief

 

Liegt vermutlich alles an mir (dem User), komisch das bis zum 9.9 Hotfix meine Fähigkeiten ausgereicht haben. Der funktioniert auf Anhieb.

Edited February 18, 2010 by gwr

[craig_s]

Hey gwr,

yeah, meine Intuition.. bin einfach mal bei 9.9 stehengeblieben ohne wirklichen Grund..

 

Jetzt hatte ich auch das Prob (XP SP3) mit Hotfix 10.2 (die andern übersprungen), im Net hab ich dann was über *installiert nur signierte Treiber* bla bla gelesen. Das war aber nicht das Prob mit 10.2 sondern im Gegenteil, CCC wurde nicht g'scheit installiert. Dann hab ich nen Braten gerochen und nach Jahrhunderten mal wieder ein WinUpdate gemacht. Dann nochmal installiert und CCC war da! Vermute mal es liegt am veralteten Windows Installer?

 

Weil mit dem 10.2 nix neues zu sehen war (also auch kein ESVP) bin ich aber wieder auf das 9.9 Image zurück. Deshalb kann ich jetzt nicht sagen ob es evl. auch am NET.Framework 3.5 lag, das ich zwischenzeitlich installiert hatte (vorher NET.Framework 2).

Edited February 19, 2010 by craig_s

[Portisch]

Habe mir am Wochenende einmal 10.2 Installiert.

 

Die Fehler sind noch immer da, jedoch auf eine andere Art und Weise.

Vorher hat es so ausgesehen, wie im ersten Post - Verpixelt.

 

Nun gibt's bei mir das Verpixeln nicht mehr, jedoch sieht man eindeutig, dass manchmal Bildruckler (<1s) (so als würde der TS kurz stehen bleiben) drinnen sind.

Die Anzahl kommt mir mehr vor als bei 10.1.

 

Zumindest bleibt das Bild nicht mehr voll hängen wie beim 10.1.

[CiNcH]

Ich habe nun eine Digital Devices cine S2 mit CI im produktiven Test. Damit beobachte ich das Klötzchen-Phänomen alle paar Minuten auf ORF 1 HD (70 dBuV Signalstärke, 13.5 dB SNR). Mit einer FloppyDTV-S2 passiert es nur sehr selten. TransEdit bekommt in beiden Fällen keine fehlenden(kaputten) Pakete mit. Irgendwer produziert da aber Stream-Errors. Evtl. liefert da der Demodulator teilweise fehlerhafte Daten oder es werden im Treiber Daten in TS-Paketen überschrieben,.. Ich tu mir etwas schwer, das zu bewerten.

[nuts]

Mit Mulitentschlüsselung oder kann man da gar nichts einstellen (mein CI-Modul ist immernoch unterwegs )?

[CiNcH]

Ja, mit MTD. Aber das liegt meiner Meinung nach nicht daran. Ich hatte früher schon das Gefühl, dass ST basierte Geräte mehr zu solchen Fehlern im Stream tendieren als Conexant. Ich kann mir das nur so erklären, dass die Fehlerkorrektur nicht immer ganz sauber arbeitet.

 

mein CI-Modul ist immernoch unterwegs

Ja, verspätet sich leider immer wieder. Hoffentlich die Woche...

[CiNcH]

Ich habe nun eine Digital Devices cine S2 mit CI im produktiven Test. Damit beobachte ich das Klötzchen-Phänomen alle paar Minuten auf ORF 1 HD (70 dBuV Signalstärke, 13.5 dB SNR). Mit einer FloppyDTV-S2 passiert es nur sehr selten. TransEdit bekommt in beiden Fällen keine fehlenden(kaputten) Pakete mit. Irgendwer produziert da aber Stream-Errors. Evtl. liefert da der Demodulator teilweise fehlerhafte Daten oder es werden im Treiber Daten in TS-Paketen überschrieben,.. Ich tu mir etwas schwer, das zu bewerten.

So, Problem erkannt. Es hat nichts mit ST vs. Conexant zu tun, sondern ist ein Bug in den MASCOM-Modulen, der verstärkt mit der cine S2 und MTD zum Tragen kommt. MASCOM-Module entschlüsseln unter bestimmten Umständen ein paar Bytes nicht. Es wird dafür einen Workaround im DD-Treiber geben. Ich werde dann in meinem Produktivsystem wohl auf die cine S2 umsteigen. Somit ist dieses Problem für mich hoffentlich generell erstmal vom Tisch.

 

Für Live-Streams kann man ATi einfach nicht empfehlen. Ein fehlerhafter Stream kann durch folgende Umstände hervorgerufen werden:

 

- empfangsbedingte Stöhrungen

- Entschlüsselungsfehler durch das CAM bzw. die CSA-Engine

- Random Access Problem: der Dekoder liefert keinen sauberen Einstieg in den Stream (Microsoft DTV-DVD Video Decoder)

[craig_s]

Ganz doll recherchiert, Cinch, und ich finde so fliessend die Verhältnisse auch sein mögen, diese epochalen Erkenntnisse sollten nicht in diesem Thread versacken sondern als einfach verständlicher Tip ins HDTV-Wiki. Leider bin ich zu doof um die nötigen Schritte gegen Mascom-Module zu beschreiben. Eine Bemerkung zum MS-Decoder ist schon drin im WIKI, die kannste umformen und setzt alles unter ne neue Überschrift so wie 'Wenn 720p Klötzchen macht...', wie wärs? Wenn du mir das mit den Mascoms noch erklärst kann ich das meinetwegen auch machen...

[Flecktarnloewe]

Ist denn schon etwas bekannt, wie mman die Fehler beheben kann?

Ich selbst habe eine Sky Star HD2 mit CI und AC Light und Sky Abo und langsam verlier ich echt den Nerv.

Mitlerweile kann ich ein Decoder Fehler auch ausschliessen, da die Fehler nur bei allen 7 Sky HD Kanälen auftreten. Mein AC Light ist in Ordnung, da im TV selbst über Kabel keine Fehler auftreten. Mein HTPC rennt sogar mitlerweile so gut, das ich selbst bei 720i50 ala ARD und ZDF HD ohne Fehler den MS DTV Decoder verwenden kann.

 

Ich werd woghl auf PCIe umsteigen, nur wenn der Fehler mit der Cine S2 auch auftritt wäre das ein wirklich teurer Spass.

 

Was mir aber auch aufgefallen ist, das meine SkyStar HD2 unter Windows XP auf meinem neusten Mainboard (M4A89GTD Pro/USB3) überhaupt nicht mehr rennt. Kein Decoder liefert ein Fehlerfreies Bild. Und unter Windows 7 ist nach etwa 30-60 sek. das Bild verschlüsselt wenn Timshift aktiv ist und ich mehr als 2 Platten im Raid 0 habe. Habe jetzt nur noch 2 Platten im Raid 0 und da haut es hin.

 

Achso.. weiss jemand wozu auf dem CI Interface der Skystar HD2 die Pins sind mit der Beschriftung "COM2"??? Habe im Netz nix gefundenn dazu.

 

 

Gruss Thomas