<div class="gmail_extra"><br><br><div class="gmail_quote">2012/4/25 Stephen Warren <span dir="ltr"><<a href="mailto:swarren@nvidia.com" target="_blank">swarren@nvidia.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Aaron Plattner wrote at Tuesday, April 24, 2012 2:01 PM:<br>
<div><div class="h5">> Sorry for the slow reply.<br>
><br>
> On 02/29/2012 01:46 PM, Emeric Grange wrote:<br>
> > I have been using this implementation to develop and test the mesa decoder.<br>
> > The flaws of this simple method are that some fields like "color_space" or<br>
> > "clamping_type" could be used by the decoder.<br>
> > As Aaron said the calling application still needs to parse out the<br>
> > refresh_golden_frame, refresh_alternate_frame and refresh_last_frame. This is<br>
> > bad news because these fields are binary arithmetic encoded, there positions<br>
> > cannot be guessed, and so every fields preceding them must be decoded too. That<br>
> > also mean that the calling application must implement a VP8 "boolean decoder".<br>
><br>
> Yeah, that's pretty lame. If I'm reading it right, the caller just needs to keep<br>
> track of the arithmetic decoder state for the first partition, and can pass the<br>
> other partitions as-is into the library.<br>
><br>
> The question is whether it's better to pass the entire compressed first<br>
> partition in too, or have the caller decompress the whole thing first, or some<br>
> hybrid approach.<br>
><br>
> > - The first patch (<a href="https://github.com/emericg/libvdpau-" target="_blank">https://github.com/emericg/libvdpau-</a><br>
> vp8/commit/f7e3e25cadace8b5dff2f4ee9870f7e86faf30d8)<br>
><br>
> This is the "pass in all the partitions" approach, right? When it says "Include<br>
> all frames," do you mean all compressed partitions in the frame?<br>
><br>
> Stephen, does this new interface look like it makes sense? It's just the parsed<br>
> uncompressed header plus reference frame handles, and then leaves parsing<br>
> everything else up to the decoder.<br>
<br>
</div></div>I think this looks basically fine. A couple thoughts though:<br>
<br>
* We should validate this with internal VP8 experts, just in case there's<br>
some problem more obvious to them. I'm not at all familiar with VP8.<br></blockquote><div>Of course.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* I would be tempted to require inclusion of all frame header in the<br>
bitstream buffer - starting right at the first byte of the "uncompressed<br>
data chunk". If a driver doesn't need it, it's fixed-size so easy to skip.<br>
If a driver does need it, having it already in the bitstream buffer avoids<br>
the need to reconstruct it from VdpPictureInfoVP8 before sending it to<br>
hardware.</blockquote><div>Yes it make sense, I'm ok with it.</div><div><br></div><div><br></div><div>Thanks,</div><div>Emeric</div></div></div>