Created attachment 100593 [details] Madi deinterlacing showing artifacts As we are currently implementing VPP into xbmc via: and: I made some quality tests in comparing MADI with BOB and a state of the art yadif deinterlacer. It seems that MADI in VPP propagates artifacts from between the reference frames and make especially test looking quite bad. I used the famous burosch samples for comparing. Screenshots are attached. Program used gst-launch with gstreamer-vaapi-plugins 0.4.
The links to the other bug reports were missing: https://bugs.freedesktop.org/show_bug.cgi?id=79698 and https://bugs.freedesktop.org/show_bug.cgi?id=79528
Created attachment 100594 [details] Yadif deinterlacing of burosch sample
Created attachment 100595 [details] Burosch VPP bob When using BOB as method no artifacts are visible.
Running Hardware: IVB core i5 3570K with libva and libva-driver-intel master: libva info: VA-API version 0.35.1 libva info: va_getDriverName() returns 0 libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_35 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.35 (libva 1.3.2.pre1) vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Desktop - 1.3.2.pre1 vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD
(In reply to comment #4) > Running Hardware: IVB core i5 3570K with libva and libva-driver-intel master: > libva info: VA-API version 0.35.1 > libva info: va_getDriverName() returns 0 > libva info: Trying to open /usr/local/lib/dri/i965_drv_video.so > libva info: Found init function __vaDriverInit_0_35 > libva info: va_openDriver() returns 0 > vainfo: VA-API version: 0.35 (libva 1.3.2.pre1) > vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Desktop - > 1.3.2.pre1 > vainfo: Supported profile and entrypoints > VAProfileMPEG2Simple : VAEntrypointVLD > VAProfileMPEG2Simple : VAEntrypointEncSlice > VAProfileMPEG2Main : VAEntrypointVLD > VAProfileMPEG2Main : VAEntrypointEncSlice > VAProfileH264ConstrainedBaseline: VAEntrypointVLD > VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice > VAProfileH264Main : VAEntrypointVLD > VAProfileH264Main : VAEntrypointEncSlice > VAProfileH264High : VAEntrypointVLD > VAProfileH264High : VAEntrypointEncSlice > VAProfileVC1Simple : VAEntrypointVLD > VAProfileVC1Main : VAEntrypointVLD > VAProfileVC1Advanced : VAEntrypointVLD > VAProfileNone : VAEntrypointVideoProc > VAProfileJPEGBaseline : VAEntrypointVLD Did you see the issue on haswell?
No chance to see it on HSW, HSW is fully non working with those burosch samples. Btw. those samples are public domains, here are the links for easy testing: https://samples.libav.org/MPEG2/interlaced/ This is how it should be looking: https://dl.dropboxusercontent.com/u/55728161/burosch1-yadif.mp4 I don't think you can ever get this sample working correctly with only one forward reference, but happy to be proven wrong.
Hi, (In reply to comment #6) > No chance to see it on HSW, HSW is fully non working with those burosch > samples. > > Btw. those samples are public domains, here are the links for easy testing: > https://samples.libav.org/MPEG2/interlaced/ > > This is how it should be looking: > https://dl.dropboxusercontent.com/u/55728161/burosch1-yadif.mp4 > > I don't think you can ever get this sample working correctly with only one > forward reference, but happy to be proven wrong. I have reviewed and identified several issues in the VA driver. I will work on a few fixes (2 trivial, 1 more involved, 1 woule require API clarification). Besides, you are right, it is required to have past and future frames for advanced deinterlacing modes.
Is there any news on the state of SNB / IVB. HSW is already fine (in staging). Furthermore is there a timeline until the vebox fixes hit a real release? We currently package custom libva-driver-intel packages - cause there is not a single stable driver out there that has deinterlacing working (besides bob, of course).
Hi, (In reply to Peter Frühberger from comment #8) > Is there any news on the state of SNB / IVB. > > HSW is already fine (in staging). > > Furthermore is there a timeline until the vebox fixes hit a real release? We > currently package custom libva-driver-intel packages - cause there is not a > single stable driver out there that has deinterlacing working (besides bob, > of course). I have just pushed work-in-progress code: <https://github.com/gbeauchesne/libva-intel-driver/tree/17.vpp.vebox> Changes: - Synced with git master and integrated the AVS changes ; - Fixed advanced deinterlacing modes for Sandybridge & Ivybridge ; - Added support for Motion-Compensated Deinterlacing mode on Ivybridge. Note: The Sandybridge path is not tested at all yet. Please let me know if this works for you. If so, I will split the mega patch in at least 3 parts: (i) fix advanced deinterlacing modes, (ii) add support for motion-compensated deinterlacing on Ivybridge, and (iii) fix memory leak on exist (temporary surfaces). And push to git master. Thanks.
Hi Gwenole, thank you very much for that fast work. We are building ppa packages from that new code and will get it tested via: http://forum.kodi.tv/showthread.php?tid=165707 Do you want direct user feedback in this bugreport?
First testing with some basic content and it does not look good. I am directly running into a driver assert: http://sprunge.us/IYeH #2 0x00007fffeffdaa76 in __assert_fail_base ( fmt=0x7ffff012c370 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x7fffa414c820 "obj_surface && obj_surface != dst_obj_surface", file=file@entry=0x7fffa414c4b6 "i965_post_processing.c", line=line@entry=3816, function=function@entry=0x7fffa414cc90 "gen7_pp_nv12_dndi_initialize") at assert.c:92 This happens with live TV and or the mentioned burosch samples. Happens with all three MADI / MACI and even BOB. Hardware core i5 3400 with IVB graphics.
(In reply to Peter Frühberger from comment #11) > First testing with some basic content and it does not look good. I am > directly running into a driver assert: > > http://sprunge.us/IYeH > > #2 0x00007fffeffdaa76 in __assert_fail_base ( > fmt=0x7ffff012c370 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", > assertion=assertion@entry=0x7fffa414c820 "obj_surface && obj_surface != > dst_obj_surface", file=file@entry=0x7fffa414c4b6 "i965_post_processing.c", > line=line@entry=3816, > function=function@entry=0x7fffa414cc90 "gen7_pp_nv12_dndi_initialize") > at assert.c:92 > > This happens with live TV and or the mentioned burosch samples. Happens with > all three MADI / MACI and even BOB. > > Hardware core i5 3400 with IVB graphics. This assert() cannot be triggered with bob deinterlacing. I have only tested with tennis, Fields, CrossSpin, and a few others from another customer.
You are right of course. BOB is still working fine. I was tricked by a "per video" setting. It's quite hard when you set "MCDI" as default algorithm and have per "video" settings that use it automatically. Btw. Do you have a chance to test xbmc? (github.com/xbmc - master branch)? The good side here is: No regressions on HSW.
Removing the assert and returning "something" else makes it work quite fine: - assert(obj_surface && obj_surface != dst_obj_surface); - assert(obj_surface->base.id != dst_obj_surface->base.id); + if(!obj_surface || obj_surface == dst_obj_surface) + return VA_STATUS_ERROR_INVALID_SURFACE; + if(obj_surface->base.id == dst_obj_surface->base.id) + return VA_STATUS_ERROR_INVALID_SURFACE; Not really sure if this is a valid workaround, it seems to be doing something at least. This error only happens after the first frame it seems. Sadly the quality of both still look really bad (see attachment). I hope that's cause by my "just make it work" driver patch.
Created attachment 108529 [details] Artifacts with latest driver (patched)
Created attachment 108531 [details] This is a video demonstrating comparison between (De-Interlace (e.g. ffmpeg yadif), OpenGL Bob, MCDI, MADI and VPP-BOB) This is a video demonstrating comparison between (De-Interlace (e.g. ffmpeg yadif), OpenGL Bob, MCDI, MADI and VPP-BOB). You can especially see when you press the "pause" key that MCDI and MADI seem to do something strange (especially look at the ticker). Yadif Deinterlace has a really great quality. It looks like MCDI /MADI on HSW platform.
Created attachment 108533 [details] [review] Workaround the assert Workaround the driver assert. In fact one should never assert if error can be propagated.
(In reply to Peter Frühberger from comment #17) > Created attachment 108533 [details] [review] [review] > Workaround the assert > > Workaround the driver assert. In fact one should never assert if error can > be propagated. The assert() is here for programmatic errors, it should not occur. Actually, I still can't reproduce it. This could be two things, (i) different driver, probably didn't I upload the right thing, or (ii) I am using gstreamer-vaapi only for testing. BTW, your video is empty. I will dump videos from gst-vaapi too and compare them on HSW/IVB. I will try to review at least the xbmc code too. No guarantee that I will actually compile the whole thing yet. :)
I am testing the very same xbmc code, that is running really fine on HSW - so no code change involved in the userspace application. Concerning the posted Video: I downloaded it here (at work) and it even works on Windows (vlc), so there is definitely some content in it. Perhaps try another player? Offtopic: xbmc helix release will have VPP (mcdi, madi, bob) support - it would be nice to get that correctly working with a driver. Our code is not immune to bugs, so pointers into the right direction would be highly appreciated. It is running fine on all HSW gpus since some months already now. We have some x million users and a high number of users are intel nuc, chromebox, baytrail and so on users.
Edit: Can you verify you uploaded the right driver (git diff something)?
(In reply to Peter Frühberger from comment #20) > Edit: Can you verify you uploaded the right driver (git diff something)? I have local changes, but I pretty doubt this has any impact. I will merge a few bits to lower diffs. Anyway, I could finally download your video. Based on it, it seems that some frames don't get deinterlaced at all, this is suprising.
(In reply to Gwenole Beauchesne from comment #21) > (In reply to Peter Frühberger from comment #20) > > Edit: Can you verify you uploaded the right driver (git diff something)? > > I have local changes, but I pretty doubt this has any impact. I will merge a > few bits to lower diffs. > > Anyway, I could finally download your video. Based on it, it seems that some > frames don't get deinterlaced at all, this is suprising. Moved the VEBOX (HSW+) code to master and updated the IVB code path here: <https://github.com/gbeauchesne/libva-intel-driver/tree/19.vpp.adi>
(In reply to Gwenole Beauchesne from comment #18) > (In reply to Peter Frühberger from comment #17) > > Created attachment 108533 [details] [review] [review] [review] > > Workaround the assert > > > > Workaround the driver assert. In fact one should never assert if error can > > be propagated. > > The assert() is here for programmatic errors, it should not occur. Actually, > I still can't reproduce it. This could be two things, (i) different driver, > probably didn't I upload the right thing, or (ii) I am using gstreamer-vaapi > only for testing. > > BTW, your video is empty. I will dump videos from gst-vaapi too and compare > them on HSW/IVB. I compared MADI results from HSW and IVB for Fields & burosch1 and SSIM consistently yields >= 0.99 and this looks visually the same. Though, better eyes are welcome. :) > I will try to review at least the xbmc code too. No guarantee that I will > actually compile the whole thing yet. :) The XBMC part looks correct too.
BTW, a 3rd iteration of the patch series is possible but this would affect both VEBOX (HSW) and legacy DI on IVB+. I need to first check results are on part between IVB and HSW now.
Hi Gwenole, thanks much for the review. I will retry with the updated codepath tonight. Thank you very much.
Waoh! This is a really big improvement to yesterday. The segfault is gone and now it actually does deinterlacing. Though, it kind of looks blurred and not so sharp as normal BOB - I tried to capture it into a video (but it seems barely visible on it). It might be possible that the deinterlacing is quite fine (as your SSIMD also states) but that display is doing something odd. I will ask other people from the xbmc forum thread to test it for me. In the meantime, here is the video: https://dl.dropboxusercontent.com/u/55728161/gwenole-sample2.m4v Thank you very much.
I tried, and with the caveat that I am testing xbmc(s) from source with other things - mesa/ddx/kernel git versions I only get frame rate out of the ma/mc deints so depending on content it looks film juddery, vaapi bob is OK and field rate. On burosch letters there are still a few weave artifacts, though not many. By repeatedly switching deints and clicking back to near the start on an h264 HDTV sample I was testing I eventually got a segfault (at the moment of clicking near to the beginning of the progress bar) - Vaapi-Output[7339]: segfault at 20 ip 00007f5bc03230c0 sp 00007f5baa4fb7e8 error 4 in libdrm_intel.so.1.0.0[7f5bc0320000+20000] This is actually better than before - with vanilla intel-driver doing the same thing I have previously hardlocked. I haven't had this j1900 board (asrock Q1900DC-ITX) long, so don't have any historic reference to anything working or not.
@Andy: What does that mean you only got "frame rate" out of the videos? That means basically - no deinterlacing at all is happening. Please try xbmc master branch from github, make sure your TV supports 50hz and play some 1080i50 or 576i samples. Adding other software stack, that is additionally _unknown_ will confuse all participants.
(In reply to Peter Frühberger from comment #28) > @Andy: > What does that mean you only got "frame rate" out of the videos? I mean it looks like say yadif=0 would on another player. > That means basically - no deinterlacing at all is happening. No, it's not still weaved. > Please try xbmc > master branch from github, make sure your TV supports 50hz and play some > 1080i50 or 576i samples. There seems to be an added complication with letters on master which seems to mess up everything for me except normal bob, few days old FernetMenta saveme doesn't have this issue. Looking at logs one difference is there seems to be a pullup cadence detected with master - but then I don't know how to read the logs - will upload. > Adding other software stack, that is additionally _unknown_ will confuse all > participants. While I accept that I am a total noob WRT xbmc and building a stripped down version so may be reporting issues because of that, I can't imagine the Intel guys not wanting to know the status of current code. If the forum testers all call working, then I will try building old code and if I can get it to work will then find what regressed the current code.
Created attachment 108600 [details] saveme log playing letters debug osd showing 50 fps
Created attachment 108601 [details] master log playing letters debug osd showing 35fps Tried this one with and without sync to video - same result
That's your hardware: 18:13:46 T:140233711003648 NOTICE: Host CPU: Intel(R) Celeron(R) CPU J1900 @ 1.99GHz, 4 cores available Make sure it does not do Lanczos3 Optimized upscaling, cause this Baytrail plain sucks in doing it and this might explain your only 35 fps. Also not sure about: Linux x86 64-bit version 3.18.0-rc1-10539-g6f628cb I tested yesterday on my Baytrail (J1800) and it at least was doing the above correctly, but fonts in tickers (like bursosch1) look kind of bad. From your log I see, that you still test "xbmc" whereas master (that I am talking about) has long transitioned to kodi. Please post a debuglog with latest code (fernetmenta master is possible) to the forum thread and if possible, please sort out userspace. It's hard to test regressions when userspace is latest alpha.
I made another Desktop Video (now real 50 fps) which clearly shows the differences between all the methods we have implemented. Deinterlace: SSE4 copy + CPU deinterlacing with yadif BOB: OpenGL Bobbing VPP Implementations VAAP-BOB VAAPI-MADI VAAPI-MCDI Please concentrate on the running text, that is running from right to the left. Here MCDI, MADI produces artifacts (not visible in yadif and the BOBs), furthermore it looks like some heavy blending between the images. On a hsw system everything is fine. Here is the link (12 MB): https://dl.dropboxusercontent.com/u/55728161/madi-mcdi-comparison-gwenole3.mkv
And so, that we have to compare something. Here is a recording from an HSW system that is doing MCDI / MADI with the very same software stack. I hope this helps to get that issue sorted (14 MB): https://dl.dropboxusercontent.com/u/55728161/mcdi-madi-hsw-gwenole4.mkv Best Regards Peter
(In reply to Peter Frühberger from comment #33) > I made another Desktop Video (now real 50 fps) which clearly shows the > differences between all the methods we have implemented. > > Deinterlace: SSE4 copy + CPU deinterlacing with yadif > BOB: OpenGL Bobbing > > VPP Implementations > VAAP-BOB > VAAPI-MADI > VAAPI-MCDI > > Please concentrate on the running text, that is running from right to the > left. Here MCDI, MADI produces artifacts (not visible in yadif and the > BOBs), furthermore it looks like some heavy blending between the images. > > On a hsw system everything is fine. > > Here is the link (12 MB): > https://dl.dropboxusercontent.com/u/55728161/madi-mcdi-comparison-gwenole3. > mkv Thanks for comparing. I will analyze further. So far, one unknown I have yet to check depper is that STMM surfaces might be cloberred with the stats output. The STMM buffer is where we store motion measures.
I reviewed the Deinterlacing Code and as far as I understand it looks fine from an architecture point of view concerning the code path. I don't understand all those non documented fixed values at the beginning of the postprocessor - when I see our task as a paramater optimization problem, which of those would you suggest changing? :-) Some of those: https://github.com/gbeauchesne/libva-intel-driver/blob/3eff1b3b8e220f17c65250e93a7c4963a1f6ab30/src/i965_post_processing.c#L3449 The only thing, I could have seen is probably: https://github.com/gbeauchesne/libva-intel-driver/commit/3eff1b3b8e220f17c65250e93a7c4963a1f6ab30#diff-0353de05c34d6a348fabc4731f1797cfR3809 You comment to set value 5, as you set 3 and 4 before, but don't use the last parameter, but the one before.
Hi Gwenole, is there something we can help you with? Any parameters that you want me and others to tune in the driver? Would be really nice to get that feature into upcoming 1.4.2 or at least into a quick 1.4.3 release. Thanks in advance Peter
Hi, just stumbled over this ticket during evaluation of a Bay Trail-M based STB. Using gstreamer-1.x (git master of last week) we ran into the same problems with vaapipostproc and deinterlace-method>2: Artifacts especially with news-ticker like moving text. No problem on a Haswell based system. Also on Baytrail with advanced deinterlacing on 1080i25 content it looks like the GPU runs really at its limits. intel_gpu_top shows "render busy" close to 100% and playback is not completely smooth. (Again fine on Haswell.) Can this be considered as a hardware shortcoming? Thanks for investigating!
The Baytrail has only 4 Execution Units, you need to take great care on the later rendering and also on scaling algorithms used. You can try kodi, which has an optimized render path using vaPutsurface and later OpenGL rendering. Does that work better? (Make sure to set scaling to bilinear). 1080i50 right? In order to succesfully use deinterlacing (mcdi, madi) at all, you need to use Gwenole's tree.
(In reply to Peter Frühberger from comment #39) > The Baytrail has only 4 Execution Units, you need to take great care on the > later rendering and also on scaling algorithms used. You can try kodi, which > has an optimized render path using vaPutsurface and later OpenGL rendering. > Does that work better? (Make sure to set scaling to bilinear). Well we were using most basic gst-1.0 pipelines like gst-launch-1.0 -m -v filesrc location=/tmp/t.ts ! tsdemux ! queue ! h264parse ! vaapidecode ! vaapipostproc deinterlace-mode=1 deinterlace-method=3 ! vaapisink There should be no scaling involved, no? Hmm, LIBVA_TRACE tells me there is a minor diff between src- and dest-rect, not sure how this is handled internally: [27871.946454] ==========va_TracePutSurface [27871.946473] surface = 0x04000008 [27871.946475] draw = 0x01400001 [27871.946477] srcx = 0 [27871.946478] srcy = 0 [27871.946480] srcw = 1920 [27871.946481] srch = 1088 [27871.946482] destx = 7 [27871.946483] desty = 0 [27871.946484] destw = 1905 [27871.946486] desth = 1080 [27871.946487] cliprects = 0x00000000 [27871.946488] number_cliprects = 0 [27871.946490] flags = 0x00000020 We also tested xbmc nightly builds and GPU usage looked for the same "VAAPI Motion*" (scaling=bilinear, yes). > 1080i50 right? I meant 1920x1080i content @25fps. If you refer to the 1080i50 snippet you linked in bug #79528: Same problem. > > In order to succesfully use deinterlacing (mcdi, madi) at all, you need to > use Gwenole's tree. Yes also tried Gwenoles github branch, commit 19256196e01eb1184425f684eb19e74f71e2d438. $ vainfo libva info: VA-API version 0.36.0 libva info: va_getDriverName() returns 0 libva info: Trying to open /opt/gstreamer-1.x/lib/dri/i965_drv_video.so libva info: Found init function __vaDriverInit_0_36 libva info: va_openDriver() returns 0 vainfo: VA-API version: 0.36 (libva 1.4.1.pre1) vainfo: Driver version: Intel i965 driver for Intel(R) Bay Trail - 1.4.1.pre1 () vainfo: Supported profile and entrypoints VAProfileMPEG2Simple : VAEntrypointVLD VAProfileMPEG2Simple : VAEntrypointEncSlice VAProfileMPEG2Main : VAEntrypointVLD VAProfileMPEG2Main : VAEntrypointEncSlice VAProfileH264ConstrainedBaseline: VAEntrypointVLD VAProfileH264ConstrainedBaseline: VAEntrypointEncSlice VAProfileH264Main : VAEntrypointVLD VAProfileH264Main : VAEntrypointEncSlice VAProfileH264High : VAEntrypointVLD VAProfileH264High : VAEntrypointEncSlice VAProfileH264StereoHigh : VAEntrypointVLD VAProfileVC1Simple : VAEntrypointVLD VAProfileVC1Main : VAEntrypointVLD VAProfileVC1Advanced : VAEntrypointVLD VAProfileNone : VAEntrypointVideoProc VAProfileJPEGBaseline : VAEntrypointVLD Does MCDI/MADI on 1080i content work for you on Baytrail? Then we might have an issue with our setup. Or maybe the gpu_top output is misleading?
It works, kind of - yes :-), tested with an J1800 MCDI and MADI. It basically looked like the videos from here: https://bugs.freedesktop.org/show_bug.cgi?id=79765#c26
Sorry, C33 from above.
Those are both SD, which works fine here, too, except for the artifacts in the text (we saw on N24). What do the 'skipped' frames tell me exactly, I saw in xbmc's codec OSD ('o') when playing back 1080i25 content with madi/mcdi? We are testing on Celeron N2930.
Skip: Render is late and already prepared frames were not displayed Drop: Decoder is also late, already decoded frames are thrown away (more sever issue). Hopefully you come away with render skipping.
That little Baytrail is at its limits when doing VPP + rendering at the same time. We are looking forward to use EGL in the future, cause we could save the "vaPutSurface" path which does an RGB conversion internally. With the EGL approach you can just render what you already have, without the need to transform and copy.
(In reply to Holger Kaelberer from comment #38) > Also on Baytrail with advanced deinterlacing on 1080i25 content it looks > like the GPU runs really at its limits. intel_gpu_top shows "render busy" > close to 100% and playback is not completely smooth. (Again fine on > Haswell.) Can this be considered as a hardware shortcoming? Well I don't know how close to the limit my j1900 is, but it can do 50 fps HD sometimes. Using xbmc and fdo driver git mc/madi will wither work or will get the wrong field order. This can be "fixed" by repeated pausing, but is likely to fall out sync after some time - but it shows that fieldrate is possible. With Gwenoles github branch I only get framerate. Both have more artifacts than you would want.
(In reply to Andy Furniss from comment #46) > Using xbmc and fdo driver git mc/madi Just to correct myself, fdo only does madi of course. Also forgot to put neither drivers were stable for me testing last week - skipping around eventually resulted in a segfault. I've failed to provoke this using vaapi bob on the same samples.
(In reply to Andy Furniss from comment #46) > This can be "fixed" by repeated pausing, but is likely to fall > out sync after some time - but it shows that fieldrate is possible. It seems the ability to get correct fieldorder by pausing doesn't work with recent xbmc, but does with an older Fernetmenta branch xbmc I have. While repeatedly pausing xbmc madi + fdo driver + nightly kernel I just hardlocked.
(In reply to Andy Furniss from comment #48) > While repeatedly pausing xbmc madi + fdo driver + nightly kernel I just > hardlocked. Turns out the hardlock may not have been madi related. There was a ddx change which deselected dri3. Without this it seems I am glitchy and sometimes liable to hardlock with anything where frame or field rate = refresh.
Hi Gwenole, sorry to be a PITA. But is there anything we can do / help you prior to the release of 1.4.2 libva-driver-intel?
This is my monthly reminder for asking if we can do anything else to provide input data to get this issue resolved. Version 1.5.0 would be a nice driver version that correctly works for what the driver is announcing.
(In reply to Peter Frühberger from comment #51) > This is my monthly reminder for asking if we can do anything else to provide > input data to get this issue resolved. > > Version 1.5.0 would be a nice driver version that correctly works for what > the driver is announcing. Summarize for me your current issues. This thread is getting really long in the bugzilla. Please provide details on test conditions and what exactly is currently failing for you. We are cutting a new release soon. Sean
Hi Sean, quite easy (even with videos): https://bugs.freedesktop.org/show_bug.cgi?id=79765#c34 (HSW) how it should be https://bugs.freedesktop.org/show_bug.cgi?id=79765#c33 (how it is on SNB and IVB). Use Case: Post processing with VPP on SNB/IVB (driver faulty) and HSW (driver working correctly - Version 1.5.0 pre2), all drivers before had issues until Gwenole did his vebox fixes. Code: https://github.com/xbmc/xbmc/blob/master/xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI.cpp#L2708 (Verified by Gwenole).
Hi Sean, did you see the issue on my posted videos? Any chance to get that fixed?
We at WeTek - are currently investigating x86 hardware (Atom Z373X and so on), and the non working deinterlacing functionality is an absolute showstopper.
Hi Sean, sorry I forgot my monthly reminder in Feburary. I hope the reminder in March is still okay. We (and our users) still have this bug and it would be nice if those BYT, SNB, IVB users out there would get a sign if it is being worked on.
Created attachment 114242 [details] [review] A patch to adjust the parameter setting This patch is based on Gwenole's tree. I only tested it with gst-vaapi(0.5.10) on IVB. Could you give a try. The command used in my testing is $> gst-launch-1.0 filesrc location={URL to the video file} ! mpegpsdemux ! mpegvideoparse ! vaapidecode ! vaapipostproc deinterlace-method=3 ! vaapisink
Thanks very much. As said via Mail it looks okay, when using gstreamer. I still get issues with kodi that works with the hsw edition of the driver, something like PTS values going foobar. I need more time to investigate. Would be nice if Holger could test on his sw stack.
With this patch applied on top of Gwenole's 19.vpp.adi branch the artifacts observed with madi/mcdi have completely gone for our news-ticker test-snippet (N24). Great! Testing with the burosch example there seem to be few artifacts remaining, but ways better than before. Thanks!
Hi Holger, thx very much. Can you compare the commits that are still missing of Gwenole's branch, so - that we can send something in combination with Haihaos Addition upstream (perhaps 1.5.1) soon? Sadly I currently cannot test on my IVB system, therefore cannot do it myself. Thanks very much in advance. Peter
With the following from gwenole's branch: https://github.com/gbeauchesne/libva-intel-driver/commit/8294e43e809923eb6f8231a085c76595028cafad https://github.com/gbeauchesne/libva-intel-driver/commit/ec6e26656c580871787343c71b4c6f670911775f https://github.com/gbeauchesne/libva-intel-driver/commit/19256196e01eb1184425f684eb19e74f71e2d438 Plus haihao's https://bugs.freedesktop.org/attachment.cgi?id=114242 On top of intel-driver master (b4777133a1e87a8b75df8366c0d72b544ae4794e) I tested successfully.
Thanks much Holger. @Haihao, @Gwenole: Could you get those into staging / master soon? Ideally we could have a 1.5.1 release with this improved functionality - as current state (1.5.0) is broken anyways?
Verified working (after you sent the patches to ML). Thank you and Haihao very much for doing this. Feel free to close when everything is in somewhere.
(In reply to Peter Frühberger from comment #63) > Verified working (after you sent the patches to ML). Thank you and Haihao > very much for doing this. > > Feel free to close when everything is in somewhere. Hmm, testing with head intel-driver + four patches as above on baytrail with git kodi I can see it's fixed WRT the artifacts, but it isn't fixed for me properly as I am only getting framerate output.
Not sure what you are testing / content wise. All my real life Live TV samples are fine: http://solidrun.maltegrosse.de/~fritsch/ Be it 1080i50, 576i50 Here are some screenshots: MADI: https://dl.dropboxusercontent.com/u/55728161/screen1-madi.png https://dl.dropboxusercontent.com/u/55728161/screen2-madi.png https://dl.dropboxusercontent.com/u/55728161/screen3-madi.png MCDI: https://dl.dropboxusercontent.com/u/55728161/screen4-mcdi.png https://dl.dropboxusercontent.com/u/55728161/screen5-mcdi.png As you had some issues with your experimental software setup before, please verify the details on your side.
(In reply to Peter Frühberger from comment #65) > Not sure what you are testing / content wise. > > All my real life Live TV samples are fine: > http://solidrun.maltegrosse.de/~fritsch/ Be it 1080i50, 576i50 > > Here are some screenshots: > MADI: > https://dl.dropboxusercontent.com/u/55728161/screen1-madi.png > https://dl.dropboxusercontent.com/u/55728161/screen2-madi.png > https://dl.dropboxusercontent.com/u/55728161/screen3-madi.png > > MCDI: > https://dl.dropboxusercontent.com/u/55728161/screen4-mcdi.png > https://dl.dropboxusercontent.com/u/55728161/screen5-mcdi.png > > As you had some issues with your experimental software setup before, please > verify the details on your side. I have plenty of samples and could produce screens just like above - but they wouldn't prove anything other than the artifacts are gone. Using eg, burosch the display pressing "o" looks exactly the same for madi/mcdi and vaapi bob - 50fps no drops/skips. There is a big difference between them though in that vaapi bob is clearly field rate and the others aren't. Of course anyone testing on a TV would need to make sure that all frame interpolation was off or the TV would hide the difference. I am testing on a monitor and am quite sensetive to film judder it's night and day between field/frame rate for me. Of course if you aren't testing baytrail then maybe it works for you.
Ah! Now I get what you meant. I thought you'd say the codec screen would only show 25 fps all the time. No you are right, if one exactly looks - it seems like a very fast flickering - is it the same you see in my video I did for Gwenole above? That should be another param of the deint block: https://01.org/linuxgraphics/documentation <- they uploaded the RPM here - perhaps you find something?
sampler_dndi[index].dw7.fmd_for_1st_field_of_current_frame = 0; sampler_dndi[index].dw7.fmd_for_2nd_field_of_previous_frame = 0; ^^ can you play with those?
(In reply to Peter Frühberger from comment #68) > sampler_dndi[index].dw7.fmd_for_1st_field_of_current_frame = 0; > sampler_dndi[index].dw7.fmd_for_2nd_field_of_previous_frame = 0; > > ^^ can you play with those? Haven't had time to read docs, but have put some fprintf around - to try and see what's happening/what code I hit. Changing the above does not help, elsewhere in the code they are 2 1 but testing 1 1, 2 1, 1 2, and 2 2 all just got me weaved output. Of course I know that madi can work at fieldrate because that's what happens with vanilla - but without field sync so it's pot luck (well maybe more complicated) whether it works or is out of order - but working is possible by repeated pause/unpause. Gwenoles big patch vpp: fix advanced deinterlacing on Sandybridge and Ivybridge changes things to framerate. I can see from my fprintfs that the code is called at field rate - so it could be that a minor tweak is needed somewhere to do with what field of some reference or current frame is used the second call as currently it seems that the same result is produced twice. At 5K lines it may take some looking though :-)
(In reply to Andy Furniss from comment #69) > I can see from my fprintfs that the code is called at field rate - so it > could be that a minor tweak is needed somewhere to do with what field of > some reference or current frame is used the second call as currently it > seems that the same result is produced twice. Bit pushed for time - no diffs as it would be big including the 4 patches + my debugging due to the lazy way I've gone so far. I played some more and can "fix" it, but doing so involves changing code that looks to be protecting against using a surface that isn't there - but in practice with kodi at least there is no difference in changing it - possibly because there is other code elsewhere that doesn't seem to do what was intended. I will upload a couple of screens showing what I changed in src/i965_post_processing.c. I've tested quite a bit with tff and bff samples and it seems OK for me. The hacky-fix.png should let you see how to find and change to "fix" - the line with the cursor is added by me to replace the \\ style code commented out. There are two instances of this code - you'll hit one depending on your h/w - for me gen7 so that's all I changed/tested. The effect of the change is to make dndi_top_frame alternate rather than be stuck on 0 or 1 (depending on field order of sample) when is_first_frame is 1 the results are the same between vanilla and hacked version. The never-reached.png shows code that looks like is_first_frame should be set twice but it isn't - the printf at 1228 never prints - which may be why the vanilla code and the hacked don't differ. Either way I don't get any warnings and it seems to work fine.
Created attachment 114521 [details] hacky-fix to get field rate from madi/mcdi
Created attachment 114522 [details] never-reached code
Thanks for your investigation first, but hey please: Upload a patch! No one wants to read "images" in 2K15.
(In reply to Peter Frühberger from comment #73) > Thanks for your investigation first, but hey please: Upload a patch! > > No one wants to read "images" in 2K15. 1 Time - just wanted to get what I found this morning out, going to be AFK soon. 2 There isn't a patch - that would imply I understood the best fix. and also if I uploaded my "big diff" that includes the 4 patches + debugging + hack, it still wouldn't be any use for some as I only touched the code that my specific h/w uses.
Created attachment 114651 [details] Allows field rate madi/mcdi with kodi on baytrail. With this patch field rate madi/mcdi works for me with kodi on baytrail. This is tested/applied on top of - https://github.com/fritsch/libva-intel-driver.git ppa-new-1.5.0 branch
This was fixed during 1.6.0 driver circle. Thanks to everybody involved.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.