FFmpeg 2.0 und softhddevice

I have reenabled my trickspeed workaround for H264.
This is no default. Some ffmpeg version crashed with it.

Edit Makefile:

#CONFIG += -DH264_EOS_TRICKSPEED        # insert seq end packets for trickspeed

to

CONFIG += -DH264_EOS_TRICKSPEED        # insert seq end packets for trickspeed

to enable it.

ffmpeg 2.0.0 didn't crash here and my test streams have a working fast backward.

Johns

ui... fein. Das probier ich heut Abend gleich mal aus.

[EDIT] Funzt! ...getestet mit Aufnahmen auf SKY HD, HD+ und ServusTV HD [/EDIT]

thx
iNOB

Zitat von johns

I have reenabled my trickspeed workaround for H264.
This is no default. Some ffmpeg version crashed with it.

Edit Makefile:

Code

#CONFIG += -DH264_EOS_TRICKSPEED        # insert seq end packets for trickspeed

to

Code

CONFIG += -DH264_EOS_TRICKSPEED        # insert seq end packets for trickspeed

to enable it.

ffmpeg 2.0.0 didn't crash here and my test streams have a working fast backward.

Alles anzeigen

I updated my softhddevice to newest git and tried this. It does work here but I can tell it's still buggy somehow. It's not nearly as smooth and frame-precise as the vdr-xine/xine-lib combo. That being said, I emailed Christophe Thommeret asking how possible it would be to get permission to use his vdpau decoder code in softhddevice if you were willing to include it. He's fine with it as long as no licensing issues would interfere. The latest email I received from him said, "AGPL seems fine. Feel free to give the decoder a try. It should have little xine dependancy so should be easy to port". So, he's given the green light and the question now is, would you be willing to drop his decoder into softhddevice? According to Christophe it should be easy to do and by doing so, softhddevice would have a rock solid vdpau decoder immune from buggy ffmpeg or anything else. Is this something you'd at least consider on behalf of all the softhddevice vdpau users?

I can forward all my email correspondence with Christophe on this subject as well if needed.

Zitat von jinx

It's not nearly as smooth and frame-precise as the vdr-xine/xine-lib combo.

Stimmt... allerdings bin ich froh, dass es überhaupt funktioniert, das Zurückspulen. Verbesserungspotential wäre allerdings im direkten Vergleich zu xine-lib + xine-plugin noch vorhanden.

Gruß
iNOB

Wieso antwortest du auf Deutsch?

a) weil ich Deutsch besser kann als Englisch
b) weil jinx meine Antworten auch mit Translator versteht, siehe hier
c) weil in diesem Thread sowohl englische als auch deutsche Kommentare vorkommen
d) weil nirgends geschrieben steht, dass ich meine Muttersprache vernachlässigen soll

Such dir was aus...

Gruß
iNOB

I have currently no time to add an own VDPAU decoder.
I don't want to include the decoder of others.
I want to understand it and use the code of others as cookbook.

This needs some more time, than just to add the decoder of others,
but than I'm able to find and fix bugs myself.

This should not keep others from just adding the xine vdpau decoder.
Johns

iNOB: You mentioned my name, what are you saying?

Johns: Oh well, it was worth a shot. I just wished softhddevice would be the best possible for everyone, that's all.

Johns, I spoke with a ffmpeg dev and he said that frame-stepping likely not implemented in the ffmpeg vdpau decoder. If this is the case then they may be able to add it. He said if you have specific information, you can email him directly. He also speaks German so that may make things easier. I will send his email to your inbox.

This would be fine, than all take advantage of this way.

I must add a patch which dumps the single frame packets, these can be combined and tested with other players.

Edit: It is now available in git.

Edit Makefile uncomment (remove the first #)

#CONDIF += -DDUMP_TRICKSPEED            # dump trickspeed packets

Than in the current directory are the files "frame_xxxxxx_yyyyyyyy.raw" created,
Each file contains one VDR trickspeed packet. x is the pid of the vdr process, y is the frame counter.

To combine the files and play

cat frame_* > video.raw
ffmpeg -i video.raw

Which does nothing.

Johns

Johns, does that test confirm what cehoyos suggested, that frame-stepping is not implemented in the ffmpeg vdpau decoder?

Afaik ffplay didn't support vdpau.
The software h264 decoder should be used.
I must control if h264 streams, which are good with trickspeed, are played ok.
And check different ffmpeg versions.

Johns