[FFmpeg-devel] [PATCH] Seeking to beginning of avi file skips first audio packet

Michael Niedermayer michaelni
Tue May 18 14:44:08 CEST 2010

On Mon, May 17, 2010 at 11:24:47AM -0700, John Stebbins wrote:
> On 05/17/2010 10:56 AM, Michael Niedermayer wrote:
> > On Sun, May 16, 2010 at 04:31:07PM -0700, John Stebbins wrote:
> >   
> >> When seeking to the beginning of an avi file with av_seek_frame,
> >> avi_read_seek seeks to the correct position for stream index 0, then
> >> seeks to the next interleaved packet for all other streams.  
> >>     
> > no, it does not, there is just 1 seek. The code just initializes
> > internal variables for the other streams.
> >
> >   
> I realize that.  My language was imprecise.
> >   
> >> When
> >> seeking to the beginning of the file, this causes packets for other
> >> streams to be skipped if these streams start earlier in the file than
> >> stream 0.
> >>     
> > yes thats how the code works, i can see that this may be undesireable
> > but instead of hacking around on the old seeking api. I think we should
> > look into getting the new api (avformat_seek_file) in shape and implemented.
> > otoh if one really wanted to work on the old, a prerequesite of your
> > change would be to update the old api to describe this issue and
> > preferred behavior otherwise one can be sure that no 2 demuxers would
> > behave equal.
> >
> >   
> I didn't know there was a new api being worked on.  If the old is being
> deprecated, then by all means, the effort should go into the new.
> >   
> >> This patch changes the logic only when a backward seek is requested. It
> >>     
> > yes and maybe this makes sense or maybe not
> > so why just for backward seeks?
> >
> >
> >   
> To be honest, I wanted to change the behaviour for all cases.  It seems
> more correct to adjust to a position that is at or before the desired
> timestamp after searching for that timestamp in all stream indexes. But
> I was afraid this could cause issues for programs that expected the
> current behaviour.   For example, a small forward seek request could
> result in a backward seek if the packets of one stream span a much
> larger duration than the packets of another stream in the file.  So by
> checking the direction flag, I am guaranteeing that the seek will always
> result in a movement in the desired direction.

the advantage of the new api is that it specifies these things more
precissely, and that the user can specify to libavformat more flexibly what
she wants.
Maybe you want to port avi to the new api? :)
Or maybe you even have suggestions to improve the new API, as we can still
change it if needed


Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Incandescent light bulbs waste a lot of energy as heat so the EU forbids them.
Their replacement, compact fluorescent lamps, much more expensive, dont fit in
many old lamps, flicker, contain toxic mercury, produce a fraction of the light
that is claimed and in a unnatural spectrum rendering colors different than
in natural light. Ah and we now need to turn the heaters up more in winter to
compensate the lower wasted heat. Who wins? Not the environment, thats for sure
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100518/a66e6ba1/attachment.pgp>

More information about the ffmpeg-devel mailing list