Jo
[SoftHdDevice] und >= ffmpeg 1.1
-
-
So,
habe die neue Version mit dem aktuellen git von ffmpeg mal ein wenig getestet.
Wie ich schon geschrieben hatte, läuft hier alles ziemlich rund.
Schön ist, dass das "Spulen" bisher ohne irgendwelche Abstürze funktionierte (habe den Trickspeed Patch wieder aktiviert).
HD-Bild und Ton ist gut.
Bei SD ist der Micky Maus Ton weg, das Bild hat leider noch Artefakte und Blöcke.
Habe mal ein Bild angehängt, bei dem man im Gesicht und um den linken Arm herum gut erkennen kann, was ich meine.Du hattest schon geschrieben, dass das am Dolby Digital Ton liegen kann.
Da ich mich viel zu wenig mit der Materie auskenne kann ich leider nur berichten was ich sehe und keine Lösungsansätze bieten.grappi
-
Es liegt an ffmpeg GIT. Dies produziert diese Streifen.
Sollte es im nächsten stabilen Release auch so sein, dann muß ich suchen.
Im Moment gehe ich von einen Temporären Fehler in ffmpeg aus.
Du kannst prüfen ob ffplay (hat kein VDPAU) oder mplayer die gleichen Probleme haben.Kannst gucken ob es bei ffmpeg bereits gemeldet ist und wenn nicht melden.
Johns
-
Habe heute Morgen noch ein Test mit der stabilen ffmpeg-1.1.1 ausprobiert.
Dort ist auch das SD-Bild OK.
Leider gibt es damit wieder die Abstürze beim Rewind/FastForward mit aktiviertem Trickspeed Patch. Ohne den Patch ist alles OK, selbst Rewind bei 1080i Material geht in dieser KombinationMeldung bei ffmpeg, bzgl. der Streifen, habe ich noch nicht überprüft.
grappi
-
I have no clue what any of you are saying but since this thread must be about softhddevice being broken with newer/git ffmpeg, has the problem been fixed where the audio is high-pitched (sounds like the chipmunks) and some kind of echo effect? I had this problem when I updated my ffmpeg git a few weeks ago. All I was told at the time was to use an old ffmpeg, which I have been doing since then. But if this is fixed now, I'd like to know so I can upgrade ffmpeg back. Thanks.
-
Yes, high-pitched sound should be fixed since this commit --> http://projects.vdr-developer.…ab872221c4bc65966fa23f0b9
-
I have no clue what any of you are saying but since this thread must be about softhddevice being broken with newer/git ffmpeg, has the problem been fixed where the audio is high-pitched (sounds like the chipmunks) and some kind of echo effect? I had this problem when I updated my ffmpeg git a few weeks ago. All I was told at the time was to use an old ffmpeg, which I have been doing since then. But if this is fixed now, I'd like to know so I can upgrade ffmpeg back. Thanks.
You can try it, but ffmpeg GIT contains the next problem. There are artefacts or lighter and darker lines with mpeg.
ffmpeg 1.1 works fine now.Johns
-
Zitat
You can try it, but ffmpeg GIT contains the next problem. There are artefacts or lighter and darker lines with mpeg.
Is this something that needs to be fixed in ffmpeg, or in softhddevice? -
Is this something that needs to be fixed in ffmpeg, or in softhddevice?
Seems that this has to be fixed in ffmpeg!Currently I am using the latest stable relase from ffmpeg 1.1.1 and todays git version from softhddeivce.
This combination works really great for me!grappi
-
Seems that this has to be fixed in ffmpeg!
I found a little information about this. Apparently the breakage is caused by merged patches by someone named Rémi Denis-Courmont:
vdpau: Add MPEG-1/2 decoding via hwaccel infrastructure
vdpau: Add context and common helpers for hwaccel support
pixfmt: add picture format for VDPAUI assume these patches weren't actually tested or else they wouldn't have been merged. To verify you can revert the above patches and test, which I was told should fix the problem.
ZitatCurrently I am using the latest stable relase from ffmpeg 1.1.1 and todays git version from softhddeivce.
This combination works really great for me!
I grabbed that tarball for this based on your note. Hopefully I'll have the same result here as well but I'm about to watch a movie so the test will have to wait until afterwards. -
-
I found a little information about this. Apparently the breakage is caused by merged patches by someone named Rémi Denis-Courmont:
vdpau: Add MPEG-1/2 decoding via hwaccel infrastructure
vdpau: Add context and common helpers for hwaccel support
pixfmt: add picture format for VDPAUI assume these patches weren't actually tested or else they wouldn't have been merged. To verify you can revert the above patches and test, which I was told should fix the problem.
I grabbed that tarball for this based on your note. Hopefully I'll have the same result here as well but I'm about to watch a movie so the test will have to wait until afterwards.These patches didn't look like they cause the trouble. They add a new way to use VDPAU, the same which is used for VA-API.
But I have not the time to look and report. When there is a stable release with the same bug, I will check if the bug is in my
code.Johns
-
I don't need to assume the person who merged them (Diego Biurrun) didn't even test them. He admitted to me in email he didn't but they worked for Remi and that was good enough.... Nice to know yet another person with merge access is so willing to sign-off and merge patches without testing them based 100% on someone else saying there's no problem. :\ZitatThese patches didn't look like they cause the trouble. They add a new way to use VDPAU, the same which is used for VA-API.
But I have not the time to look and report. When there is a stable release with the same bug, I will check if the bug is in my
code.
I forgot a few on accident. The full patchset is:
vdpau: Remove av_unused attribute from function declaration
vdpau: Add VC-1 decoding via hwaccel infrastructure
vdpau: Add H.264 decoding via hwaccel infrastructure
vdpau: Add MPEG-4 decoding via hwaccel infrastructure
vdpau: Add MPEG-1/2 decoding via hwaccel infrastructure
vdpau: Add context and common helpers for hwaccel support
pixfmt: add picture format for VDPAU -
Archlinux hat heute das neue FFMpeg bekommen. Irgendwas geht bei mir aber schief. Neukompilieren hat auch nichts gebracht.
SDTV funktioniert
Das Erste HD geht mit extrem flackerndem Bild
Prosieben HD geht nur TonIn der Logdatei wird immer das hier wiederholt
CodeFeb 17 10:30:35 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use Feb 17 10:30:35 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use Feb 17 10:30:35 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use Feb 17 10:30:35 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use Feb 17 10:30:35 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use Feb 17 10:30:36 archvdr vdr[3080]: video/vdpau: release surface 0x00000b, which is not in use
-
Ich bin jetzt nochmal alles durchgegangen. Ich finde den Fehler nicht.
Der letzte GIT Stand sollte doch out-of-the-box mit dem neuen FFMpeg funktionieren, oder muss ich da noch etwas machen?
-
Eigentlich ja, im Moment ist nur die neue Version im Code.
Welche Version von ffmpeg haste genau? Dann kann ich nochmal gucken.
Johns
-
Also unter Arch steht das bei der Paketaktualisierung an:
Code==> Software upgrade (new version) : extra/x264 20121113-1 -> 20130206-1 extra/ffmpeg 1:1.0.1-1 -> 1:1.1.2-2 extra/mplayer 35421-2 -> 35915-1 ==> New package : extra/opus 1.0.2-1 (required by ffmpeg)
Laut https://projects.archlinux.org…KGBUILD?h=packages/ffmpeg
Wird da http://ffmpeg.org/releases/ffmpeg-1.1.2.tar.bz2 als Basis verwendet. -
Ja genau: 1.1.2
-
Aha 1.1.1 war die letzte die getestet wurde, wenn die GIT als 1.1.2 gepackt haben,
dann gibt es mehr zum suchen.Johns
-
Kann man da irgendwo helfen? Das kommt nämlich gerade ziemlich ungelegen.
Edit: OK, habe jetzt das alte Paket wieder installiert. Jetzt funktioniert wieder alles.
Jetzt mitmachen!
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!