[FFmpeg-devel] [PATCH] Seeking and resync support in nuv demuxer

elupus elupus
Sun Jun 8 14:11:32 CEST 2008

On Sun, 8 Jun 2008 13:04:27 +0200, Michael Niedermayer wrote:

> On Sun, Jun 08, 2008 at 12:31:12AM +0200, Reimar D?ffinger wrote:
>> On Sat, Jun 07, 2008 at 11:07:54PM +0200, Michael Niedermayer wrote:
>>> On Sat, Jun 07, 2008 at 07:40:18PM +0200, Reimar D?ffinger wrote:
>>> > > +                av_add_index_entry(s->streams[frametype == NUV_VIDEO ? ctx->v_id : ctx->a_id]
>>> > > +                                 , pos, dts, size + HDRSIZE, 0, hdr[2] == 0 ? AVINDEX_KEYFRAME : 0);
>>> > 
>>> > And either way I really think this should not be done here at least.
>>> That one should be fine, other demuxers do it as well
>> Well, IMO either this is desirable in general, then it should be done in some layer
>> above, if not it should still be done in some layer above just
>> conditionally.
> read_timestamp() searches for a timestamp in a specific stream, the call
> above adds timestamps for any stream.
> If you now suggest redesign read_timestamp() so it always returns the first
> found and keep the whole stream check outside then theres a problem. And that
> are containers which have fewer points where reading can start than
> timestamps. 
> <can start here> <timestamp stream 0> <timestamp stream 1> <can start here> ...
> [...]

nuv being one of them. It doesn't have that many resync points, so it's
alot better to know a few positions in the stream where reading "can" start
if you know the exact location. 

It's also alot faster with that call since otherwise avformat keeps trying
to find an end timestamp in the stream on each seek so the binary search
can continue. With that call it only needs todo this on the initial seek,
then everything starts going smoothly.


More information about the ffmpeg-devel mailing list