<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 17 September 2015 at 17:52, Ilia Mirkin <span dir="ltr"><<a href="mailto:imirkin@alum.mit.edu" target="_blank">imirkin@alum.mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, Sep 16, 2015 at 8:22 AM, Julien Isorce <<a href="mailto:j.isorce@samsung.com">j.isorce@samsung.com</a>> wrote:<br>
> I added below version4 updates. It works for all codecs expect h264.<br>
> Video is visible but lot of blockiness.<br>
> Can someone with a Radeon confirm that "LIBVA_DRIVER_NAME=gallium mpv --hwdec=vaapi"<br>
> is working on h264 videos ?<br>
> I want to make sure it is not a bug in st/va.<br>
<br>
</span>The sad reality is that h264 is the only thing that matters (at least<br>
from this list of supported codecs). My concern is that this series<br>
will regress the situation for people who want to use VA-API -- right<br>
now they can use the vdpau <-> vaapi adapter, whereas with this patch<br>
series, they will end up with a va-api driver that doesn't work. So I<br>
can't merge this as-is.<br></blockquote><div><br></div><div>Make perfectly sense.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Are the various lengths (for inter-bo size/etc) being computed<br>
properly</blockquote><div> </div><div>In the past I compared the final content of the nouveau_bo buffer at each endFrame step , with the content using vdpau. There were the same.<br></div><div>I will re-check.<br></div><div>Does it make sense to do that actually ?<br></div><div>Is there anything else I could compare with vdpau ?<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you writing stuff to the correct inter bo? IIRC we flip<br>
between two of them, perhaps that logic got upset?</blockquote><div> </div><div>Probably I missed something. Does the flip happen at each endFrame ?<br></div><div>Could you point out where this flip is in the current upstream code exactly ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Are you perhaps<br>
feeding it NAL types that it doesn't expect to see?<br></blockquote><div><br></div><div>Good point, I'll check.<br><br></div><div>Thx<br></div><div>Julien<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
><br>
> v4:<br>
> Update caps after number of slices.<br>
> Fixed debug build.<br>
> After trying debug build I made a new patch "st/va: properly set max number of ref frames".<br>
> Tested videos:<br>
> * mpeg4 work ok:<br>
> mpv --hwdec=vaapi big_buck_bunny_720p_surround.avi (from <a href="http://download.blender.org/peach/bigbuckbunny_movies/" rel="noreferrer" target="_blank">http://download.blender.org/peach/bigbuckbunny_movies/</a>)<br>
> * vc1 works ok:<br>
> mpv --hwdec=vaapi To_The_Limit_720_230.ismv (from <a href="http://playready.directtaps.net/smoothstreaming/" rel="noreferrer" target="_blank">http://playready.directtaps.net/smoothstreaming/</a>)<br>
> * mpeg12 works ok:<br>
> mpv --hwdec=vaapi centaur_2.mpg (from <a href="https://github.com/malek0512/PLS/raw/master/Tests/centaur_2.mpg" rel="noreferrer" target="_blank">https://github.com/malek0512/PLS/raw/master/Tests/centaur_2.mpg</a>)<br>
> * h264 has blockiness like it was dropping some slices:<br>
> mpv --hwdec=vaapi any_video (from <a href="http://www.h264info.com/clips.html" rel="noreferrer" target="_blank">http://www.h264info.com/clips.html</a>)<br>
> Depending on the video it can have more or much less blockiness.<br>
> * All this videos still work with option --hwdec=vdpau<br>
><br>
> v3:<br>
> Indent to 3 spaces.<br>
> Move "unsigned bsp_size" and unsigned int nb_slices" in<br>
> commits that use it.<br>
><br>
> v2:<br>
> Squash some commits as requested.<br>
><br>
> Currently nouveau does not support chunk decoding<br>
> which is required to support st/va.<br>
><br>
> The low level code is already there since it supports<br>
> vpau. But it is missing the possibility to feed<br>
> the nouveau_bo buffers gradually.<br>
> Resizing is already there too. But it also requires<br>
> to preserve the content after resizing.<br>
><br>
> The following patches refactor nouveau_vp3_bsp<br>
> and nvc0_decoder_bsp in order to implement<br>
> pipe_video_codec::begin_frame/decode_bitstream/end_frame.<br>
> So that decode_bitstream can be call multiple times<br>
> between each begin/end.<br>
><br>
> There is nothing really new in these patches.<br>
> All the low level code relative to nouveau was already there.<br>
> The patches are moving code in order to call nouveau_vp3_bsp and<br>
> nvc0_decoder_bsp multiple times between each begin/end frame.<br>
><br>
> I made sure that vdpau was still working. Actually it was more than that,<br>
> without vdpau I think I would not have been able to do this refactoring.<br>
> I also compared that for one begin/end frame the nouveau_bo buffer contains<br>
> the same data for vdpau and vaapi. I dumped them for the same stream and<br>
> for several seconds. There were all the same.<br>
><br>
> Regression tests:<br>
> No regression for vdpau backend.<br>
><br>
> TODO:<br>
> Apply same logic for nv98 but I do not have the<br>
> material to test it. Ilia Mirkin suggested to do it after.<br>
><br>
> <a href="https://bugs.freedesktop.org/show_bug.cgi?id=89969" rel="noreferrer" target="_blank">https://bugs.freedesktop.org/show_bug.cgi?id=89969</a><br>
><br>
> Julien Isorce (6):<br>
> nouveau: split nouveau_vp3_bsp in begin/next/end<br>
> nvc0: add support for st/va<br>
> nouveau: fix chunk decoding by updating number of slices<br>
> st/va: properly set max number of ref frames<br>
> build: enable st/va with nouveau driver<br>
> WIP: implement vaapi export / import and vpp<br>
><br>
> src/gallium/drivers/nouveau/nouveau_vp3_video.h | 22 +-<br>
> .../drivers/nouveau/nouveau_vp3_video_bsp.c | 115 ++++--<br>
> src/gallium/drivers/nouveau/nv50/nv98_video_bsp.c | 5 +-<br>
> src/gallium/drivers/nouveau/nvc0/nvc0_resource.c | 3 +-<br>
> src/gallium/drivers/nouveau/nvc0/nvc0_video.c | 44 +-<br>
> src/gallium/drivers/nouveau/nvc0/nvc0_video.h | 18 +-<br>
> src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c | 141 +++++--<br>
> src/gallium/state_trackers/va/buffer.c | 175 +++++++-<br>
> src/gallium/state_trackers/va/config.c | 20 +<br>
> src/gallium/state_trackers/va/context.c | 101 +++--<br>
> src/gallium/state_trackers/va/image.c | 145 ++++++-<br>
> src/gallium/state_trackers/va/picture.c | 89 +++-<br>
> src/gallium/state_trackers/va/surface.c | 449 ++++++++++++++++++---<br>
> src/gallium/state_trackers/va/va_private.h | 69 +++-<br>
> src/gallium/targets/va/Makefile.am | 2 +<br>
> 15 files changed, 1195 insertions(+), 203 deletions(-)<br>
><br>
> --<br>
> 1.9.1<br>
><br>
> _______________________________________________<br>
> mesa-dev mailing list<br>
> <a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
> <a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
_______________________________________________<br>
mesa-dev mailing list<br>
<a href="mailto:mesa-dev@lists.freedesktop.org">mesa-dev@lists.freedesktop.org</a><br>
<a href="http://lists.freedesktop.org/mailman/listinfo/mesa-dev" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/mesa-dev</a><br>
</div></div></blockquote></div><br></div></div>