While I am waiting for a reply, I just thought I would explain the search algorithm used, so you verify it is very efficient.<br><br>We create an index on the fly, this index is basically:<br>offset in file -> maximum frame number<br clear="all">
<br>When asked to seek to a particular frame, we first check the index to see if we have approximate boundaries for the seek, otherwise we will seek in the whole file, from data_start until the end.<br><br>The area to be searched is divided into two halves. We first check the upper half, and get the highest and lowest granulepos. (The granulepos is basically keyframe * keyframe_offset + frame offset). If our target frame lies in this region we subdivide it into two halves, otherwise we check the lower half from earlier. We stop when we have found the keyframe for our target frame, or the search region is < minimum_page_size.<br>
<br>What we are aiming to find on this first pass, is the highest keyframe (sync point) which is <= target frame.<br><br>Once we have found this, we need to rewind a bit further, because the ogg container only discloses where a frame ends, not where it begins. So we do a second pass and find the highest granulepos < target granulepos from the last step. We begin decoding from here, ignoring any frames which are output on this first page. We then start counting down until we reach the target frame.<br>
<br>As we discover keyframes (sync points) these are added to the index. Also, if we discover a higher frame number which is based on the same keyframe we update our index. Additionally, during normal playback the index is updated with keyframes as we play them.<br>
<br><br>If the codec/demuxer is installed and working properly you can see this in operation - the first seek takes a noticable fraction of a second, subsequent seeks become increasingly faster as the keyframe -> highest frame index is built up.<br>
<br><br>I believe this is the most efficient way of seeking in ogg (at least for theora - and probably for dirac; although dirac seems a little different in that there is a lower bound but no upper bound for dirac, and according to the dirac spec the granulepos shows the first frame decoded on a page rather than the last frame).<br>
<br>There is currently one known issue, which is if the entire file is < min_page_size, we never find any keyframes. I am working on a fix for this, I believe the solution in this case is simply to divide the min_page_size by 2 until we get a keyframe produced.<br>
<br>Regards,<br>Gabriel.<br><br><br><a href="http://lives.sourceforge.net">http://lives.sourceforge.net</a><br><a href="https://www.ohloh.net/accounts/salsaman">https://www.ohloh.net/accounts/salsaman</a><br><br>
<br><br><div class="gmail_quote">On Wed, Jun 9, 2010 at 2:35 PM, salsaman <span dir="ltr"><<a href="mailto:salsaman@gmail.com">salsaman@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
As a result of my work, I would like to propose a new flag for the stream:<br><br>STREAM_CAN_EXACTSEEK<br><br>- the proposed meaning of this flag is that within the stream one can seek exactly to any given frame without artifacts in the frame. This flag must be settable by the demuxer plugin, and is not fixed - for example you could have a container with two video streams one after the other, the first could set this flag and the second (using a different codec) could be not seekable.<br>
<br>Rationale:<br>I understand that you are creating libvlc with the intention of this being used for video editing applications. I know from my own experience with LiVES that such applications require demuxers which can deliver the exact frame requested, so generally one would need to look at STREAM_CAN_EXACTSEEK | STREAM_CAN_FASTSEEK to see if the stream is immediately usable or requires further processing (caching, indexing, etc).<div class="im">
<br>
<br><br><br>Regards,<br>Gabriel.<br><br><br><br><br clear="all"><br><a href="http://lives.sourceforge.net" target="_blank">http://lives.sourceforge.net</a><br><a href="https://www.ohloh.net/accounts/salsaman" target="_blank">https://www.ohloh.net/accounts/salsaman</a><br>
<br>
<br><br></div><div><div></div><div class="h5"><div class="gmail_quote">On Wed, Jun 9, 2010 at 10:37 AM, salsaman <span dir="ltr"><<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
You could also try uncommenting some of the fprintf in oggseek.c and seeing what happens.<br><br>You should see it homing in on the keyframe before the target frame.<div><br><br>Gabriel.<br><br clear="all"><br>
<a href="http://lives.sourceforge.net" target="_blank">http://lives.sourceforge.net</a><br>
<a href="https://www.ohloh.net/accounts/salsaman" target="_blank">https://www.ohloh.net/accounts/salsaman</a><br><br>
<br><br></div><div><div></div><div><div class="gmail_quote">On Wed, Jun 9, 2010 at 10:19 AM, salsaman <span dir="ltr"><<a href="mailto:salsaman@gmail.com" target="_blank">salsaman@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
OK, here is the patch updated with FASTSEEK.<br><br>If you are seeing problems even after downloading elephants dream, then I think there is some other problem. Maybe you are using a different demuxer (avformat ?) instead of the ogg demuxer ?<div>
<br>
<br><br>Regards,<br>Gabriel.<br clear="all"><br><a href="http://lives.sourceforge.net" target="_blank">http://lives.sourceforge.net</a><br><a href="https://www.ohloh.net/accounts/salsaman" target="_blank">https://www.ohloh.net/accounts/salsaman</a><br>
<br>
<br><br></div><div class="gmail_quote"><div><div></div><div>On Wed, Jun 9, 2010 at 3:52 AM, Ilkka Ollakka <span dir="ltr"><<a href="mailto:ileoo@videolan.org" target="_blank">ileoo@videolan.org</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div><div></div><div>
<div>On Tue, Jun 08, 2010 at 07:28:27PM -0300, salsaman wrote:<br>
> Please check back in this thread. I asked how to tell if we are dealing<br>
> with a stream or a file, and I was told to use stream_Control( stream_t *,<br>
> STREAM_CAN_SEEK, &boolean );<br>
<br>
</div>Hi,<br>
<br>
You don't really need to know if access has file or stream coming in do<br>
you? Seems that you just need to know if it can be seeked (fast in this<br>
case seems like the info you need ) so STREAM_CAN_FASTSEEK would tell you if<br>
seeking is really a fast one (like local files etc) or not (not able to<br>
seek, or slow seek like in http-case).<br>
<br>
I think there could be still seeking problem even with local files. I<br>
tried that elephantsdream as local file, and it behaved same as behind<br>
http, so maybe patch is missing some boundary limit, or I just had some<br>
other problem in that case. I'll try to test more tonight.<br>
<font color="#888888"><br>
--<br>
Ilkka Ollakka<br>
"I've seen, I SAY, I've seen better heads on a mug of beer"<br>
-- Senator Claghorn<br>
</font><br></div></div><div>_______________________________________________<br>
vlc-devel mailing list<br>
To unsubscribe or modify your subscription options:<br>
<a href="http://mailman.videolan.org/listinfo/vlc-devel" target="_blank">http://mailman.videolan.org/listinfo/vlc-devel</a><br>
<br></div></blockquote></div><br>
</blockquote></div><br>
</div></div></blockquote></div><br>
</div></div></blockquote></div><br>