One of the issues I've consistently run into with the cortado player app is seek behavior, so I was curious to see how cortado handles video encoded with the latest ffmpeg2theora (0.26) and the new -seek-index option, so I tried converting an h.264 video: ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index This output the following advisory messages:> Allocated 372 bytes for theora keyframe index, 114 are unused. Rerun with '--theora-index-reserve 258' to encode with the optimal sized theora index, or use OggIndex to re-index. > Allocated 372 bytes for vorbis keyframe index, 59 are unused. Rerun with '--vorbis-index-reserve 313' to encode with the optimal sized vorbis index, or use OggIndex to re-index.So, I re-encoded using the recommended parameters: ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index --theora-index-reserve 258 --vorbis-index-reserve 313 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? Are there any workarounds for reliably getting and setting the playback position? Thanks! Nigel
When I looked at oggindex a few months ago the seeking was completely broken. The only player I know of which can seek reliably in ogg is the one which I wrote for LiVES: http://lives.svn.sourceforge.net/viewvc/lives/trunk/lives-plugins/plugins/decoders/ogg_theora_decoder.c It also has some nice optimisations, for example it will create a keyframe index as it discovers keyframes, and if you are playing sequentially it will just decode from the current position. Salsaman. http://lives.sourceforge.net https://www.ohloh.net/accounts/salsaman On Wed, Mar 10, 2010 at 11:12 PM, Nigel Simpson <nigel at matsuplace.com> wrote:> One of the issues I've consistently run into with the cortado player app is seek behavior, so I was curious to see how cortado handles video encoded with the latest ffmpeg2theora (0.26) and the new -seek-index option, so I tried converting an h.264 video: > > ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index > > This output the following advisory messages: > >> Allocated 372 bytes for theora keyframe index, 114 are unused. Rerun with '--theora-index-reserve 258' to encode with the optimal sized theora index, or use OggIndex to re-index. >> Allocated 372 bytes for vorbis keyframe index, 59 are unused. Rerun with '--vorbis-index-reserve 313' to encode with the optimal sized vorbis index, or use OggIndex to re-index. > > > So, I re-encoded using the recommended parameters: > > ffmpeg2theora tronlegacy-tsr1_480p.mov --seek-index --theora-index-reserve 258 --vorbis-index-reserve 313 > > 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? > Are there any workarounds for reliably getting and setting the playback position? > > Thanks! > > Nigel > _______________________________________________ > theora-dev mailing list > theora-dev at xiph.org > http://lists.xiph.org/mailman/listinfo/theora-dev >
ogg.k.ogg.k at googlemail.com
2010-Mar-15 10:59 UTC
[theora-dev] Seek issue in cortado player
> 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.> 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.
<HTML>
<BR>
I also have a pressing need to have the seeking/pausing issues in Cortado
resolved.<BR>
<BR>
What do we need to do to get these issues addressed and resolved?<BR>
<BR>
Thanks,<BR>
<BR>
John<BR>
<BR>
<span style="font-weight: bold;">On Mon Mar 15 11:54 , Nigel
Simpson <nigel@matsuplace.com> sent:<BR>
<BR>
</nigel@matsuplace.com></span><blockquote
style="border-left: 2px solid rgb(245, 245, 245); margin-left: 5px;
margin-right: 0px; padding-left: 5px; padding-right: 0px;">On Mar 15,
2010, at 3:59 AM, "<a
href="javascript:top.opencompose('ogg.k.ogg.k@googlemail.com','','','')">ogg.k.ogg.k@googlemail.com</a>"
<<a
href="javascript:top.opencompose('ogg.k.ogg.k@googlemail.com','','','')">ogg.k.ogg.k@googlemail.com</a>
<BR>
> wrote:<BR>
<BR>
>> When I play the converted video using cortado 0.5.2, seeking still
<BR>
>> seems to<BR>
>> be broken. For example: play a video, pause and then press play,
<BR>
>> the player<BR>
>> resumes several seconds after the paused position. Also, pause and
<BR>
>> drag the<BR>
>> time slider. The slider jumps to a new position after you release
<BR>
>> the drag<BR>
>> rather than where the slider was dragged.<BR>
>><BR>
>> Does cortado support OggIndex?<BR>
><BR>
> No. The index is a very new addition and is still being worked
on.<BR>
> Support at the moment is limited to ffmpeg2theora and OggIndex
(plus<BR>
> patches for Firefox). It is expected that various players will be<BR>
> patched to support the index, however. Cortado would probably be
one<BR>
> of them.<BR>
<BR>
That would be great to see in Cortado.<BR>
<BR>
>> Are there any workarounds for reliably getting and setting the
<BR>
>> playback<BR>
>> position?<BR>
><BR>
> Seeking is known to have problems in Cortado. They're fixed as
<BR>
> they're found.<BR>
> Also, a recently released version of Cortado had a non-working<BR>
> playback position access from Javascript, in case you're also
seeing<BR>
> this problem. I'm unsure whether there was a release since this
was<BR>
> found.<BR>
<BR>
I'm using Cortado in a Java application, and have been trying to <BR>
figure out why Cortado can seek reliably (well, reproducibly perhaps)
<BR>
but doesn't reliably report the current position, or resume from pause
<BR>
properly. It sounds like these are known issues though. Is there any <BR>
way to raise the priority of these issues?<BR>
<BR>
Nigel<BR>
_______________________________________________<BR>
theora-dev mailing list<BR>
<a
href="javascript:top.opencompose('theora-dev@xiph.org','','','')">theora-dev@xiph.org</a><BR>
<a
href="parse.pl?redirect=http%3A%2F%2Flists.xiph.org%2Fmailman%2Flistinfo%2Ftheora-dev"
target="_blank"><span style="color:
red;">http://lists.xiph.org/mailman/listinfo/theora-dev</span></a><BR>
)<BR>
</blockquote></HTML>
<BR>
salsaman wrote:> 2) Begin reading pages until we get at least one packet. Then check > the granulepos to find the first keyframe number (0 or 1). Store this > as e.g. keyframe_offset.Note that a stream can begin with any arbitrary offset (e.g., a live stream that was joined part-way through), not merely 0 or 1. The actual difference between 0 and 1 for normal, complete streams, however, is determined by the subminor version field in the info header, and relates to how a timestamp is computed from a granule position. You must respect this version field if you are going to accurately synchronize multiple streams, regardless of what the granule position of the first frame is.