<br><br><div class="gmail_quote">On Thu, Jul 19, 2012 at 8:31 AM, Carl Eugen Hoyos <span dir="ltr"><<a href="mailto:cehoyos@ag.or.at" target="_blank">cehoyos@ag.or.at</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>Isn't this necessary for some codecs / at least for H264? Wouldn't<br>
the API do exactly the same?<br></blockquote><div><br>Sure, if you end up seeking to a non-keyframe, it should not decode garbage frames.<br>The point here is that we would want to actually end up on a proper keyframe.<br>
 <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>
> But the idea is to ensure that you can decode as of time X,<br>
> which means you need to seek to the last keyframe *before*<br>
> time X, which is something that is not supported currently.<br>
<br>
</div>I see.<br>
(But am I wrong to assume that this is not generally possible,<br>
assuming large GOPs?)<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote></div><br>Even a large GOP has a start somewhere. Granted seeking might take a bit longer because reading data backwards to find the keyframe is not as ideal as going forward, but it should be possible.<br>