[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

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 Kombination

Meldung 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

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?

Zitat von jinx

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

Zitat von 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 VDPAU

I 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.

Zitat

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!

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.

Moin, Moin,

Zitat

Du kannst prüfen ob ffplay (hat kein VDPAU) oder mplayer die gleichen Probleme haben.

Habe mir gestern aus:

svn checkout svn://svn.mplayerhq.hu/mplayer/trunk mplayer

ein Paket unter Debian 6.0 gebaut..... gleiches Problem......

Frank

Zitat von 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. :\

Zitat

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.

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 Ton

In der Logdatei wird immer das hier wiederholt

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: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?

Also unter Arch steht das bei der Paketaktualisierung an:

==> 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

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.