No subject

4) Subtract 1 from the keyframe, then repeat step 3).

5) Begin reading from the frame discovered in step 4. Drop any packets
which are output on the first page. Count down until we reach the
keyframe, dropping packets until then.

6) Continue counting down until we reach the target frame, we are now
decoding each frame/packet. At the target frame produce the YUV
output.

Steps 4 and 5 are necessary because ogg only tells you where a frame ends,
not where it starts.



My code has two further optimisations:
- if playing sequentially (current_frame - last_frame < threshold), you
don't need to seek again (from trial and error I found threshold is best if
it is around 1/4 of the keyframe_granule_shift). Just continue decoding.

- I create a hash table of largest granule pos -> keyframe as this is
discovered. Doing a binary tree search of this first can help narrow the
initial search range for keyframes which have already been discovered

It's all in the code here:
http://lives.svn.sourceforge.net/viewvc/lives/trunk/lives-plugins/plugins/decoders/ogg_theora_decoder.c

The only function to really consider is get_frame() which takes a (const)
char *URI (actually the current version really only takes a local file
name), and an int64_t frame number and returns the output in void
*pixel_data[3] which should be pre-allocated to take a correctly sized
YUV420 frame. The rest is just internal functions or decoration, apart from
get_clip_data() which returns a struct with all the details about (const)
char *URI. I only implemented video (theora) decoding, but it should be
fairly easy to implement audio decoding from the same pages.

Yes, it is a bit complicated, but it really is the only way if you want 100%
accurate seeking in an ogg container.



Salsaman.


http://lives.sourceforge.net
https://www.ohloh.net/accounts/salsaman



On Mon, Mar 15, 2010 at 4:22 PM, Nigel Simpson <nigel at matsuplace.com> wrote:

> I know of a bunch of developers and students who might be available to help
> out. I figure this issue needs Cortado experts rather than lots of
> developers, though. If that's not the case and you need some help, I can
> send some people to the project.
>
> Nigel
>
> On Mar 15, 2010, at 12:08 PM, "ozemale at ozemail.com.au" <
> ozemale at ozemail.com.au> wrote:
>
>
> I also have a pressing need to have the seeking/pausing issues in Cortado
> resolved.
>
> What do we need to do to get these issues addressed and resolved?
>
> Thanks,
>
> John
>
> On Mon Mar 15 11:54 , Nigel Simpson sent:
>
> On Mar 15, 2010, at 3:59 AM, "ogg.k.ogg.k at googlemail.com" <
> ogg.k.ogg.k at googlemail.com
> > wrote:
>
> >> When I play the converted video using cortado 0.5.2, seeking still
> >> seems to
> >> be broken. For example: play a video, pause and then press play,
> >> the player
> >> resumes several seconds after the paused position. Also, pause and
> >> drag the
> >> time slider. The slider jumps to a new position after you release
> >> the drag
> >> rather than where the slider was dragged.
> >>
> >> Does cortado support OggIndex?
> >
> > No. The index is a very new addition and is still being worked on.
> > Support at the moment is limited to ffmpeg2theora and OggIndex (plus
> > patches for Firefox). It is expected that various players will be
> > patched to support the index, however. Cortado would probably be one
> > of them.
>
> That would be great to see in Cortado.
>
> >> Are there any workarounds for reliably getting and setting the
> >> playback
> >> position?
> >
> > Seeking is known to have problems in Cortado. They're fixed as
> > they're found.
> > Also, a recently released version of Cortado had a non-working
> > playback position access from Javascript, in case you're also seeing
> > this problem. I'm unsure whether there was a release since this was
> > found.
>
> I'm using Cortado in a Java application, and have been trying to
> figure out why Cortado can seek reliably (well, reproducibly perhaps)
> but doesn't reliably report the current position, or resume from pause
> properly. It sounds like these are known issues though. Is there any
> way to raise the priority of these issues?
>
> Nigel
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev<http://parse.pl?redirect=http%3A%2F%2Flists.xiph.org%2Fmailman%2Flistinfo%2Ftheora-dev>
> )
>
>
>
> _______________________________________________
> theora-dev mailing list
> theora-dev at xiph.org
> http://lists.xiph.org/mailman/listinfo/theora-dev
>
>

--00504502d3bcaab7500481dcf5d6
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Just for reference, here is the ogg seeking algorithm I use, which has prov=
en 100% accurate for me:<br><br><br><br>1) Parse stream headers to get data=
. Some files have a first keyframe<br>
of 0, others have a first keyframe of 1. So:-<br>
<br>
2) Begin reading pages until we get at least one packet. Then check<br>
the granulepos to find the first keyframe number (0 or 1). Store this<br>
as e.g. keyframe_offset.<br>
<br>
Then:<br>
<br>
3) To get a target frame, first search through the file to find the<br>
largest granulepos&lt;=3Dtarget, taking into account the keyframe_offset.<b=
r>