[SoftHdDevice] va-api VAAPI / VPP support for SoftHdDevice

English please!

I try to debug the problems with va-api.

vdr[12071]: video:  2:17:36.801  +18  364   0/\ms  66+1 v-buf

One problem is that the decoder buffers never more than 1 decoded frame, the above "+1".

I added the vdpau improvements to va-api.

fprintf(stderr,"error not reached\n");

This code is never reached.

Johns

Edit: old patch removed.

You get a perfect (not perfect too, see edit:) log.

I get

- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reache

Now i get some reached, but the log should look like yours :/.

Now i get a bad log:

- D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D

Do you have a bigger number before "v-buf"? (in syslog every 5min).

I try to find the bugs and i have too less decoded frames buffered, the missing frames can be my errors.

I have no difference here between vpp branch and my branch and glx and !glx.

It should be -D not reached -D not reached .... .
It should decode 1 frame and display 1 frame, but he seems to reach the sync display not often.

And it should be "+3 v-buf or "+4 v-buf" for HDTV.

Edit:
I see your log contains -P, these are too wrong. -P is nothing todo. It can -D -P or -D -P -P.
It should always be 1x -D each line. 1 decode each line.

Johns

P.S.: above tests with 720p Das Erste HD + ZDF HD.

See:
http://projects.vdr-developer.…86175ad85ea04ccab227b8051

I removed this old cruft from vdpau now. This is also included in the va-api part with a little difference.
I will test this later with va-api.

Edit: I made a new patch, should work with both SoftHdDevice versions.

-3 +S
-3 +S
-3 +-3 +S
-P S
-3 +-3 +-P S
-P S
-3 +-3 +-P S
-P S
-3 +S
....

Numbers are the used buffers, P is pause, S is sync+display.

Now my softhddevice works fine with skylake and "va-api" and "va-api-glx". No drops, no dups, audio+video in sync.

Johns

ffmpeg 2.8 is working with my version, sometimes i get only black picture.
with vpp-version i get always back picture.

Johns

Zitat von rofafor

Just tried the v2 patch with vpp_support code and the video is jerky and pretty much unwatchable:

Code

-3 +S
-P S
...

I can't say that i get a good picture with vpp-branch. There are still bad frames in the queue.
I see no difference between patch and without patch.

Zitat

The vbuf varies from 7 to 22, but usually stays around 18:

Code

video: 25:51:25.189  +16  328   0/\ms   8+7 v-buf
video: 25:51:55.189  +16  328   0/\ms  22+7 v-buf

The number before the "+" are the undecoded frames, should not become 0, than
the decoder has nothing todo. Important are the +7 which says 7 frames (interlaced 1/2 frames) are prepared.

Zitat

Reverting the VaapiSyncRenderFrame change fixes the issue and the output looks like:

Code

-3 +S
-3 +S
...

I think you must enable USE_PIP, without USE_PIP the new mpeg parser is not enabled.

Zitat

This sounds exactly the same as I had with ffmpeg-2.7 until I enabled USE_MPEG_COMPLETE/H264_EOS_TRICKSPEED defines.

I thought the same, but -DUSE_MPEG_COMPLETE and -DH264_EOS_TRICKSPEED are enabled.

With -DDEBUG ffmpeg says something about can't initialize hardware decoder.
I still need to check where the difference between my and the vpp branch is.

Johns

Edit: i corrected my spelling error PIC -> PIP. USE_PIP should it be.

I get the video packet from VDR, how the TV stations transmit them.

Normaly 1 packet contains only 1 video frame. But some TV stations sends packets which contains multiple frames.
In the old version I just waited for a free slot in the video frame buffer, but this didn't work, if you want to decode multiple streams.
Multiple streams are needed to support PIP.

Before i send the video packets to the decoder, I parse them and make sure that they contain only 1 frame.

.RenderFrame => VdpauSyncRenderFrame, VaapiSyncRenderFrame should now get only 1 frame and there is 1 free frame in the decoded video ring buffer.

.DisplayHandlerThread = VdpauDisplayHandlerThread, VaapiDisplayHandlerThread is now the only position where waiting and sync happens.

Johns

Zitat von rofafor

The ffmpeg compatibility might due the change of including avctx->hwaccl_context as a private data now:
http://fossies.org/diffs/ffmpeg/2.7.2_vs_2.8/

There must be some difference between my branch and the vpp branch.

My version is working with 2.8 with the patch. Sometimes i get a black picture after channel switch, can be a 2.8 bug or a general bug.
I must do more tests.

Johns

In the vpp branch could something be wrong with the ringbuffer.

There is a difference between the main loop code and the code VaapiSyncRenderFrame:
The main loop fills the ring buffer until #VIDEO_SURFACES_MAX are decoded.
VaapiSyncRenderFrame uses VIDEO_SURFACES_MAX - 1.

I'm still searching and try to understand where VideoFirstField abd VideoSecondField are used and why.

Edit: I see a problem, vpp branch adds two surfaces to the ringbuffer.

Than it should look like this:

@@ -5079,7 +5079,7 @@ static void VaapiQueueSurface(VaapiDecoder * decoder, VASurfaceID surface,
     ++decoder->FrameCounter;
 
     if (1) {                           // can't wait for output queue empty
-       if (atomic_read(&decoder->SurfacesFilled) >= VIDEO_SURFACES_MAX) {
+       if (atomic_read(&decoder->SurfacesFilled) >= VIDEO_SURFACES_MAX - 1) {
            ++decoder->FramesDropped;
            Warning(_("video: output buffer full, dropping frame (%d/%d)\n"),
                decoder->FramesDropped, decoder->FrameCounter);

Johns

Nice. I was until "FFMPEG_BUG1_WORKAROUND" and that my new Vaapi_get_format or VaapiGetSurface are a little different.

FFmpeg 2.8 is working now.

But I have still the bad frames. which appears every random seconds. Which are green or red or blue horizontal bars.
When I comment out the vpp queue, it is fine.

Johns

I added the patch (without the debug) to my GIT.

I added the check to enforce USE_PIP:

#ifndef USE_PIP
#error  "-DUSE_PIP or #define USE_PIP is needed,"
#endif

Johns

This is exact the failure i'm seeing too.

IIRC I disabled denose, shapren, ... filters. I have currently no patch.

Johns