<div class="gmail_extra"><br><div class="gmail_quote">2012/4/24 Aaron Plattner <span dir="ltr"><<a href="mailto:aplattner@nvidia.com" target="_blank">aplattner@nvidia.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Sorry for the slow reply.<div><br> <br> On 02/29/2012 01:46 PM, Emeric Grange wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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> </blockquote> <br></div> 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></blockquote><div><br></div><div>Yes the caller must read the three "refresh_*_frame" flags by decompressing just enough data from the first compressed partition, with its own arithmetic decoder.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <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.</blockquote><div><br></div><div>Problem is, the first partition go way further the frame header. The RFC6386 says about it:</div><div>"The first compressed partition has two subsections:</div><div><div> 1. Header information that applies to the frame as a whole.</div> <div>2. Per-macroblock information specifying how each macroblock is predicted from the already-reconstructed data that is available to the decompressor."</div></div><div><br></div><div>As only 1/ is useful to us, I don't think that we should decompress the whole first partition inside the client and pass the content through the VdpPictureInfoVP8 structure.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - The first patch (<a href="https://github.com/emericg/libvdpau-vp8/commit/f7e3e25cadace8b5dff2f4ee9870f7e86faf30d8" target="_blank">https://github.com/emericg/<u></u>libvdpau-vp8/commit/<u></u>f7e3e25cadace8b5dff2f4ee9870f7<u></u>e86faf30d8</a>)<br> </blockquote> <br></div> 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></blockquote><div><br></div><div>No I meant all of the VP8 frames type ("golden" "altref" and "previous") must go through a VDPAU bitstream buffer, but this comment may be unnecessary. I was trying to match the descriptions of the other codecs that mentioned what type of slices must be included. At a media player level there is not much distinction between the different partitions of a VP8 frame (unlike mpeg slices), so I don't think that's necessary to mention that all partitions must be passed.</div> <div>Regarding VDPAU bitstream buffer, the patch ask for the inclusion of a start code (0x9D012A, usually found in the headers of VP8 uncompressed key-frame only) before each buffer containing a frame. This behaviour also matches the one of the other codecs. As this is maybe more an issue of compatibility with hardware decoders, and because there is none available for VP8 (in graphic hardware anyway), does the mandatory inclusion of the start code made sense?</div> <div> </div><div><br></div><div>Emeric</div></div></div>