English please!
I try to debug the problems with va-api.
One problem is that the decoder buffers never more than 1 decoded frame, the above "+1".
I added the vdpau improvements to va-api.
This code is never reached.
Johns
Edit: old patch removed.
English please!
I try to debug the problems with va-api.
One problem is that the decoder buffers never more than 1 decoded frame, the above "+1".
I added the vdpau improvements to va-api.
This code is never reached.
Johns
Edit: old patch removed.
My logs show this kind of behaviour (pesintta's vpp_support + your patch):
...
D - D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - 874ms 0ms 238ms
D - D - D - D - D - D - D - D - D - D - D - D - D - D - D error not reached
- D - D - P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- P error not reached
- D - P error not reached
- P error not reached
- D - P error not reached
- D - P error not reached
...
Alles anzeigen
How can I help you?
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
Alles anzeigen
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.
johns vai-api from sep 30 + patch on braswell
on ZDF HD I get only lines as follows :
13 upto 26 -D's per line ending with "error not reached"
vbuf is staying at (very low about 0-3) +1 v-buf
Greetings Rene
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.
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
Just tried the v2 patch with vpp_support code and the video is jerky and pretty much unwatchable:
The vbuf varies from 7 to 22, but usually stays around 18:
Reverting the VaapiSyncRenderFrame change fixes the issue and the output looks like:
ffmpeg 2.8 is working with my version, sometimes i get only black picture.
This sounds exactly the same as I had with ffmpeg-2.7 until I enabled USE_MPEG_COMPLETE/H264_EOS_TRICKSPEED defines.
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 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
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
Could you be a bit more detailed about the new mpeg parser? I just didn't get your PIC reference...
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/
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
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
Enabled USE_PIP, but the artefacts are still there. It looks like wrong field order, but couldn't find any working combination.
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
Got ffmpeg-2.8 and your patch working with help of pesintta. Checkout the latest vpp_support changes from github and then apply this over your patch:
...and the results:
ffmpeg-2.8 requires this one:
--- a/video.c
+++ b/video.c
@@ -167,7 +167,7 @@ typedef enum
#include <libavcodec/vaapi.h>
#include <libavutil/pixdesc.h>
-#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(54,86,100)
+#if LIBAVCODEC_VERSION_INT >= AV_VERSION_INT(54,86,100) && LIBAVCODEC_VERSION_INT < AV_VERSION_INT(56,60,100)
///
/// ffmpeg version 1.1.1 calls get_format with zero width and height
/// for H264 codecs.
Alles anzeigen
What comes to the FirstField and SecondField: for my knowledge there're just crude hacks to make Intel driver to output fields in a correct order. Otherwise, some hardware / driver versions messed up the deinterlace. In utopia, you don't need those or their values are [0,0] as in my Haswell setup.
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
Edit: The vpp_support branch is now up-to-date.
I have installed SoftHdDevice on my new laptop with a Pentium N3700 processor. It works, but after a few seconds and sometimes directly after switching channels I see flickering horizontal lines (see this screen recording).
But I have still the bad frames. which appears every random seconds. Which are green or red or blue horizontal bars.
Sounds like you have the same problem or is yours different?
When I comment out the vpp queue, it is fine.
Could you please explain how to do this and which effects it has?
My second problem is that the OSD is corrupted. My laptop screen has a resolution of 1366x768. If I connect my FullHD TV via HDMI the OSD looks good. I have the same problem with my Haswell based VDR if I start the plugin in window mode and scale it down. Any ideas how to fix this?
PS: I am using
x11-libs/libva-9999
x11-libs/libva-intel-driver-9999
x11-drivers/xf86-video-intel-2.99.917
media-video/ffmpeg-2.6.3
Kernel 4.3.0-rc6+ (drm-intel-nightly)
This is exact the failure i'm seeing too.
IIRC I disabled denose, shapren, ... filters. I have currently no patch.
Johns
My second problem is that the OSD is corrupted. My laptop screen has a resolution of 1366x768. If I connect my FullHD TV via HDMI the OSD looks good. I have the same problem with my Haswell based VDR if I start the plugin in window mode and scale it down. Any ideas how to fix this?
Go to the Softhddevice-Plugin-Setup:
Video - OSD Size - NOT auto, choose another resolution and now the OSD in window mode should be ok. That was you're problem?
With my Haswell it's nearly perfect now with softhhdevice from johns or from pesintta. It's only not ok on my Desktop with 60 Hz. The mode isn't integrated, isnt' it?
Stefan
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!