Summary: | VPP: deinterlacing of mpeg-2 produces green boarders artifacts on haswell | ||
---|---|---|---|
Product: | libva | Reporter: | Peter Frühberger <fritsch> |
Component: | intel | Assignee: | haihao <haihao.xiang> |
Status: | RESOLVED FIXED | QA Contact: | Sean V Kelley <seanvk> |
Severity: | normal | ||
Priority: | medium | CC: | berndkuhls, freedesktop.arad85, gb.devel, holger.k, olli.salonen, zhixinx.liu |
Version: | unspecified | ||
Hardware: | Other | ||
OS: | All | ||
Whiteboard: | |||
i915 platform: | i915 features: | ||
Attachments: |
Image with green artifacts
Green Image (now really png) A scratch patch |
Description
Peter Frühberger
2013-12-09 14:18:27 UTC
Created attachment 90515 [details]
Green Image (now really png)
Decoded and deinterlaced 576i frame
Are you sure the image attached at comment 2 is grabbed from your sample ? The screenshot is an example from a mpeg-2 live TV stream. The sample I posted (Walker Texas Ranger) is the same codec / stream type, but of course other content. Green Bars are the same. I wanted to make clear, that it's not sample dependend but a general defect. @Haihao: Could you reproduce in the meantime? Anything needed from my side to update that bugreport? Problem still happening with libva 1.3.0 and corresponding libva-driver-intel use gst-launch-0.10 to play this video, cannot find this problem. the cmd is: "gst-launch-0.10 filesrc location=/home/Stream/walker_interlaced.ts ! tsdemux ! vaapidecode ! vaapipostproc deinterlace=1 deinterlace-method=1 ! vaapisink" you can get gst-vaapi from following URL: git://gitorious.org/gst-plugins-vaapi/gst-plugins-vaapi.git 0.4 It is not a MPEG-2 related issue, actually I can reproduce this issue with a 720x576 H.264 video. Created attachment 98439 [details] [review] A scratch patch Hi Haihao, yes that fixes it with the VPP implementation of btbns branch. Madi / Maci still has issues, but I need to look more into this. Thanks much. I think my other response was not that clear: - VPP BOB: all fine now - VPP MADI/MACI: Jumping forth and back (I am not sure for that part, if that's our programming error). I compared the latter code with the gst implementation and yeah it's quite similar, despite the forward references which are not quite clear to me how gst computes them. The code is (of course) OpenSource and available here, perhaps the error jumps out quite easily: https://github.com/BtbN/xbmc/blob/vaapi-vpp-deinterlacing/xbmc/cores/dvdplayer/DVDCodecs/Video/VAAPI_VPP.cpp#L364 That patch applied for BOB would be really great. I think we'd need some support on the latter issues - Would be brilliant for the low power baytrail chips. Hi, (In reply to comment #9) > I think my other response was not that clear: > > - VPP BOB: all fine now > - VPP MADI/MACI: Jumping forth and back (I am not sure for that part, if > that's our programming error). > > I compared the latter code with the gst implementation and yeah it's quite > similar, despite the forward references which are not quite clear to me how > gst computes them. > > The code is (of course) OpenSource and available here, perhaps the error > jumps out quite easily: > https://github.com/BtbN/xbmc/blob/vaapi-vpp-deinterlacing/xbmc/cores/ > dvdplayer/DVDCodecs/Video/VAAPI_VPP.cpp#L364 > > That patch applied for BOB would be really great. I think we'd need some > support on the latter issues - Would be brilliant for the low power baytrail > chips. Some precisions, I probably omitted in the spec? 1. The reference frames used for MADI and MCDI shall be organized, i.e. sorted, by temporal proximity to the current picture we want to deinterlace. [0] is the immediately preceding picture, [1] the one preceding it, etc. The implementation in gst maintains that as a ring buffer, but the list is really constructed in order by querying index 0 frame, index 1, etc. 2. VA_DEINTERLACING_BOTTOM_FIELD_FIRST and VA_DEINTERLACING_ONE_FIELD flags pertain to how frames in the history buffer are organized. i.e. that's the additional hint to the driver to determine the temporal order of the fields to be used. 3. Only VA_DEINTERLACING_BOTTOM_FIELD flag is a way to indicate what the current picture to process represents, i.e. what you want to deinterlace from: the one you provide to vaBeginPicture() for the VPP pipeline. 4. The filter_flags with VA_TOP_FIELD|VA_BOTTOM_FIELD are only to be seen as a "fast-path" for BobDI, thus avaoiding VPP/deinterlace specific buffers. They should not have any meaning/effect when appropriate VPP/Deinterlace buffers are used for MADI, MCDI, etc. What I described is the theory of operations. In practice, this is what is implemented in gstreamer-vaapi, down to the VA driver except maybe a few quirks wrt. (4). If it doesn't work with gstreamer-vaapi (http://gitorious.org/vaapi/gstreamer-vaapi) + the latest driver, then please file a bug, and we will have to examine where the reality doesn't match the steps (1) to (4) described above. @Gwenole Beauchesne: Thank you very much for taking the time. Highly appreciated. I will close this bug as the original issue has been fixed. It would be better to file new bug if driver is the culprit for your new issue. I took the time over the weekend and tested our Code on different Intel Archs. Here is the summary: IVB (core i5 3400 mhz), libva master, libva-intel-driver master + the scratch patch: VAAPI-BOB: works VAAPI-MADI: works VAAPI-MACI: not supported HSW (core i5-4200U), libva master, libva-intel-driver master + the scratch patch: VAAPI-BOB: works (!) VAAPI-MADI: green surfaces mixed with images, stuttering VAAPI-MACI: jumping forth and back I am still the opinion that this is a driver bug in the hsw implementation of VPP, some other alignments missing? Concerning gstreamer-vaapi 0.4: I don't get that compiled on a "normal user desktop" system. Is there any other application out there that can show if VPP is working correctly on HSW platform? Could you tell me how to swith DI method in xbmc ? I can give a try on HSW. Yes, I can do: First we build the vpp branch, btbn rebased it on final gotham release, if you already have build btbn branch before - then skip that step: git clone https://github.com/btbn/xbmc.git git checkout vaapi-vpp-deinterlacing ./bootstrap ./configure make -j5 Then you need to enable it via advancedsettings.xml - we disabled the advanced methods cause they did not work for now: Create ~/.xbmc/userdata/advancedsettings.xml with the following content: <advancedsettings> <video> <vaapiadvanceddeint>true</vaapiadvanceddeint> </video> </advancedsettings> Now start xbmc (./xbmc.bin) and enable VAAPI, it's under Video -> Acceleration (see the screenshot here: https://dl.dropboxusercontent.com/u/55728161/vdpau-settingshowto.png Next is open a video file by adding a directory to your Video File Sources: Video -> Files -> Add Sources (here choose the folder with your interlaced content). Now start playing one of those, press enter, click on the film reel and change Deinterlace to Auto and Deinterlacing Method to e.g. VAAPI (BOB) VAAPI (MADI) and so on. Thank you very much in advanced xbmc passes invalid parameters VAProcPipelineParameterBuffer::num_forward_references (0) and VAProcPipelineParameterBuffer::forward_references[0] to the driver. So the new issue is different from the original issue. Fixed as the original issue has gone away. Feel free to file a new bug to track the new issue if the driver is the culprit for the new issue. |
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.