<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 September 2015 at 21:34, 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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Fri, Sep 18, 2015 at 4:29 PM, Julien Isorce <<a href="mailto:julien.isorce@gmail.com">julien.isorce@gmail.com</a>> wrote:<br>
><br>
><br>
> On 17 September 2015 at 17:52, Ilia Mirkin <<a href="mailto:imirkin@alum.mit.edu">imirkin@alum.mit.edu</a>> wrote:<br>
>><br>
>> On Wed, Sep 16, 2015 at 8:22 AM, Julien Isorce <<a href="mailto:j.isorce@samsung.com">j.isorce@samsung.com</a>><br>
>> 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<br>
>> > --hwdec=vaapi"<br>
>> > is working on h264 videos ?<br>
>> > I want to make sure it is not a bug in st/va.<br>
>><br>
>> 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>
><br>
><br>
> Make perfectly sense.<br>
><br>
>><br>
>><br>
>> Are the various lengths (for inter-bo size/etc) being computed<br>
>> properly<br>
><br>
><br>
> In the past I compared the final content of the nouveau_bo buffer at each<br>
> endFrame step , with the content using vdpau. There were the same.<br>
> I will re-check.<br>
> Does it make sense to do that actually ?<br>
> Is there anything else I could compare with vdpau ?<br>
<br>
</span>If you're feeding the exact same stuff and everything is exactly the<br>
same, then the results would also be the same. Clearly there's SOME<br>
difference SOMEWHERE :)<br></blockquote><div><br></div><div>Indeed I compared only dec->bsp_bo, not dec->inter_bo :) I'll check that.<br></div><div>But in the first place I do not see where dec->inter_bo is filled. Could you point out where this is done ?<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
><br>
>><br>
>> Are you writing stuff to the correct inter bo? IIRC we flip<br>
>> between two of them, perhaps that logic got upset?<br>
><br>
><br>
> Probably I missed something. Does the flip happen at each endFrame ?<br>
> Could you point out where this flip is in the current upstream code exactly<br>
> ?<br></span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">
<br>
</span>I mean stuff like this:<br>
<br>
   struct nouveau_bo *bsp_bo = dec->bsp_bo[comm_seq % NOUVEAU_VP3_VIDEO_QDEPTH];<br></blockquote><div><br></div><div>I see what you meant by flip now. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
src/gallium/drivers/nouveau/nvc0/nvc0_video_bsp.c:      bo_refs[1].bo<br>
= dec->inter_bo[comm_seq & 1] = inter_bo = tmp_bo;<br>
<br>
and so on. Make sure that comm_seq is incremented once per frame, not<br>
once per chunk :)<br></blockquote><div> </div><div>Yes it is incremented just once per frame, not per chunk. See "nvc0_decoder_begin_frame" in "[PATCH v4 2/6] nvc0: add support for st/va"<br><br></div><div>Thx for your comments<br></div><div>Julien<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><font color="#888888"><br>
  -ilia<br>
</font></span></blockquote></div><br></div></div>