Das klingt gut
Vielleicht erhalten wir so mehr Aufmerksamkeit. Für SD habe ich das Problem nicht explizit beschrieben.
Gruß
Atech
Das klingt gut
Vielleicht erhalten wir so mehr Aufmerksamkeit. Für SD habe ich das Problem nicht explizit beschrieben.
Gruß
Atech
So ich bin mal gespannt was von der ML kommt Mit der Änderung von I420 auf NV12 in i965_media_mpeg2.c:517 kann ich tatsächlich deinterlacing ein- und ausschalten, sowohl über xine (video.output.vaapi_deinterlace) als auch im xbmc. Im xbmc sieht man das Ergebnis direkt beim Ein-Ausschalten. Aber wie gesagt, muss auch I420 gehen, sonst krieg ich auf Dauer Probleme mit den Augen.
So Gestern gab es eine vaapi-ext Branch update.
mit vdr-xinelibout / xine-lib-vaapi GIT / ffmpeg-0.10 / xf86-video-intel-2.17.0-r3 / mesa-8.0_rc1 / kernel-3.2.1
guarded render : 1
habe ich keine "GPU hung" mit Sandy Bridge, guten Scaler, guten Deinterlacer und ca. 5% CPU load.
Johns
Hatte ich gesehen, aber die committs waren ja alle sandy/ivy related. Ich seh' schon, ich brauch eine neue Plattform
Nabend,
ist ist denn da besonderes? Eigentlich braucht man doch nur die Deinterlacer und Decoding. Den ganzen anderen Kram wie "jpeg decoding", brightness, saturation benötigt man doch garnicht. Das hab ich schon bei Nvidia alles unnütz gefunden. Unter Windows klappt ja sogar das VC1 Decoding mit Clarkdale und Deinterlacing mit dxva funktioniert auch Super. Kann nicht ganz nachvollziehen warum das unter Linux nicht gehen soll.
Gruß
Atech
Nabend,
hatte auch den CPU Hung. Habe alle den trace mit allen Informationen an die gfx-liste gesendet.
Gruß
Atech
Darüber habe ich mich auch gewundert.
Für meinen vorherigen Patch, habe ich eine einfachere noch ungetestete Lösung:
So habe die Ganze Sache zu Ende analysiert. Der Patch bekämpft nur die Symtome und nicht die Ursache.
Also es gibt Fernsehsender (z.b. Nick/CC) die schicken mehrere Bilder in einem Packet.
Diese Packet übergebe ich so an ffmpeg. ffmpeg erkennt aber bei VAAPI und wahrscheinlich
auch VDPAU nicht, daß ein neues Bild kommt. Für Software Decoder ist etwas vorhanden.
Dadurch erzeugt der VAAPI Teil von ffmpeg Buffer die nicht verwendet werden und in den
Speicher gemappt werden. Alle erzeugten Slice Buffer werden dann an libva übergeben,
was dann bei dem nächsten Aufruf von vaPutSurface mit "GPU hung" quittiert wird.
Meine Ursache habe ich nun überarbeitet. xine-lib scheint hier mit einer anderen Logic zuarbeiten
und ist vermutlich nicht betroffen. Beim Rest weiss ich nicht ob es echte Fehler sind.
Johns
Display MoreSo habe die Ganze Sache zu Ende analysiert. Der Patch bekämpft nur die Symtome und nicht die Ursache.
Also es gibt Fernsehsender (z.b. Nick/CC) die schicken mehrere Bilder in einem Packet.
Diese Packet übergebe ich so an ffmpeg. ffmpeg erkennt aber bei VAAPI und wahrscheinlich
auch VDPAU nicht, daß ein neues Bild kommt. Für Software Decoder ist etwas vorhanden.
Dadurch erzeugt der VAAPI Teil von ffmpeg Buffer die nicht verwendet werden und in den
Speicher gemappt werden. Alle erzeugten Slice Buffer werden dann an libva übergeben,
was dann bei dem nächsten Aufruf von vaPutSurface mit "GPU hung" quittiert wird.
Meine Ursache habe ich nun überarbeitet. xine-lib scheint hier mit einer anderen Logic zuarbeiten
und ist vermutlich nicht betroffen. Beim Rest weiss ich nicht ob es echte Fehler sind.
Johns
Kann schon sein das xine-lib auch davon betroffen ist. Kannst Du einen testclip erstellen und verfügbar machen ? Würd das gerne mit dem xine mpeg2 parser mal checken.
Haihao Xiang hat noch mal das bestätigt, was johns gestern geschrieben hatte:
QuoteFor some reason, the native pixel format
for MPEG-2 decoding on Clarkdale is I420, however the input pixel format
of deinterlacing is NV12 in the driver, so the driver doesn't support
deinterlacing for MPEG-2 on Clardale. We will try to fix this issue but
don't expect it too soon.
Damit sollte die Sache klar sein.
Dies sollte man aber ziemlich einfach umgehen können.
Mpeg hardware decoder -> per Software nach NV12 wandeln -> weiter an hardware postprocessor und deinterlacer -> per hardware darstellen.
Probiere doch mal mein Plugin aus und lass Deinterlacer Bob und starte vdr mit export HW_NO=1 /bin/vdr.
Bin mir nicht sicher ob es auch mit xine-lib mpeg2 softdecode = 1 und bob Beinterlacer klappt.
Johns
Moin Jungs,
habt ihr schon gelesen?
Mit diesem Kernel können die Intel-GPU's am HDMI interlaced-Ausgabe.
Habe ich mir gestern mal angeschaut, sieht um Welten besser aus mit der Stabilität und Qualität in Verbindung mit xine.
Das softhddevice hängt sich nach einiger Zeit weg.
Ist ein aktueller 3.2.0er-Kernel mit entsprechenden Patches für die Interlaced-Modes.
Ich habe hier ne Intel Sandybridge Mobile GT2+ am Rennen mit einem i5-2540m.
Eventuell wäre das ja was um die Intel-GPU's besser in vaapi zu integrieren.
Gruß
Wolfgang
Hi wbreu (auch mal wieder hier)
ja den link hatte irgendwer in den letzten Tagen gepostet, aber mir fehlt da gerade die Motivation den Kernel selbst zu bauen.
Hallo zusammen,
der Threadinitiator meldet sich nochmal zu Wort - sehr schön
Das Thema interlaced output erzeugt im moment sehr viel Mails in der gfx Liste. Nur mal damit ich das richtig verstehe:
- ich verwende ein I Modeline (oder einfach entsprechende Einstellung des X-servers)
- benutzte das normale xine oder sofhddevice ohne aktives Deinterlacing (logisch)
- Fehrnseher übernimmt das Deiterlacing
so wollte ich das früher immer machen als ich noch die Nvidia Karte hatte. Irgendwann habe ich dann aufgegeben weil ich es nicht hinbekommen habe und ausßerdem hier im Forum mal gelesen habe, dass es mit xine und co. garnicht funktioniert.
QuoteHaihao Xiang hat noch mal das bestätigt, was johns gestern geschrieben hatte:
Damit sollte die Sache klar sein.
OK das heisst für mpeg2 kommt vielleicht mal irgendwann ein Bugfix. Aber bei mir springt es ja auch nicht bei h264 an. Ich werde das nochmal explizit auf der libva Mailingliste berichten. Xiang hat mir dort auch schon geantwortet. Mehr heute Abend.
Gruß
Atech
OK das heisst für mpeg2 kommt vielleicht mal irgendwann ein Bugfix. Aber bei mir springt es ja auch nicht bei h264 an. Ich werde das nochmal explizit auf der libva Mailingliste berichten. Xiang hat mir dort auch schon geantwortet. Mehr heute Abend.
Bei interlaced H.264 bekomme ich mit xine sofort einen GPU-Hung (es kommt erst gar kein Bild). In xbmc scheint es zu funktionieren, jedoch habe ich da super viele framedrops und dementsrepchend ein ruckelndes Bild.
Edit: Okay, gerade mal gpu top nebenher laufen gehabt. Ist teilweise bei 100% Auslastung. Würde dann die framedrops erklären
Display MoreDies sollte man aber ziemlich einfach umgehen können.
Mpeg hardware decoder -> per Software nach NV12 wandeln -> weiter an hardware postprocessor und deinterlacer -> per hardware darstellen.
Probiere doch mal mein Plugin aus und lass Deinterlacer Bob und starte vdr mit export HW_NO=1 /bin/vdr.
Bin mir nicht sicher ob es auch mit xine-lib mpeg2 softdecode = 1 und bob Beinterlacer klappt.
Werte ich heute Abend mal versuchen!
Mahlzeit,
jepp ne interlaced Modeline in die xorg.conf, und man sieht jetzt im Log und am TV dass er interlaced nutzt.
Beim softhddevice bei 1080i die Interlacer auf none und es rennt.
Der TV übernimmt dann das Deinterlacing.
Mal sehen, wenn ich Zeit finde, mache ich mal einen längeren Test und schau mal tiefer auf die Facts.
Gruß
Wolfgang
Bei interlaced H.264 bekomme ich mit xine sofort einen GPU-Hung (es kommt erst gar kein Bild). In xbmc scheint es zu funktionieren, jedoch habe ich da super viele framedrops und dementsrepchend ein ruckelndes Bild.
Edit: Okay, gerade mal gpu top nebenher laufen gehabt. Ist teilweise bei 100% Auslastung. Würde dann die framedrops erklären
Dann ist es wahrscheinlich schlecht implementiert. Ich habe ja unter WIndows zahlreiche Tests gemacht und da ist die GPU nicht zu langsam.
Interlaced zum Fernseher wäre ja ne gute Möglichkeit. Mal sehen ob ich den kernel compiliert bekomme....
Atech
welcome back wbreu,
jepp ne interlaced Modeline in die xorg.conf, und man sieht jetzt im Log und am TV dass er interlaced nutzt.
bisher habe ich keine xorg.conf gebraucht und würde es auch gern so halten. Für jedes mögliche Format extra was zu konfigurieren, würde ich vermeiden wollen.
Mit diesem Kernel können die Intel-GPU's am HDMI interlaced-Ausgabe.
es braucht nicht unbedingt den neuesten Kernel. Bei mir tut's der 2.38 auch. Nur aktuelles libva(ext), intel treiber, xorg etc sind nötig
VG
Kurt
Meinst du Kernel 2.6.38? Aber die Patches sind recht frisch. Wie wählst du denn einen i mode aus?
Atech
@Atech
ja, ich meinte 2.6.38. Habe mit xine getestet und die Einstellungen über das Xine UI gemacht. Dort werden 0/1/2 (2=Bob) als iMode angeboten. Habe ich vor kurzem schon mal gepostet.
VG
Don’t have an account yet? Register yourself now and be a part of our community!