[Ffmpeg-devel] How to retrieve audio or video stream at same timestamp using av_read_frame
Michel Bardiaux
mbardiaux
Mon May 23 14:00:40 CEST 2005
Martin Boehme wrote:
> Michel Bardiaux wrote:
>
>> Martin Boehme wrote:
>>
>>> Michel Bardiaux wrote:
>>>
>>>> av_seek_frame and av_read_frame should work independently on each
>>>> stream.
>>>
>>>
>>> Really? av_seek_frame() does have a "stream" parameter, but AFAICT
>>> that just specifies the stream you want to use as an timebase.
>>
>>
>> Sorry, bad wording on my part. *should* in the sense that 'this is
>> what I would like', not 'would work if used correctly'.
>
>
> OK, I'm with you now.
>
>>> And even if av_seek_frame() did seek streams independently, that
>>> would just shift the burden of buffering frames to the disk cache or
>>> (worse) cause the disk to thrash... Keith seems to be doing the
>>> equivalent of seeking frames independently by using two different
>>> AVFormatContexts on the same file, which (for the above reason) is
>>> not a good idea IMO.
>>
>>
>> There are not that many alternatives. Either you buffer yourself and
>> thrash userspace memory, or you let some lowery level do it and you
>> thrash the buffer cache. To me the simplest API is the best, and
>> things are certainly simpler if you dont have to take side effects of
>> one stream on the other into account.
>
>
> Agreed, if there's an offset in the video file, you're going to have to
> buffer at some point...
>
>> Besides, I dont feel having 2 AVFormatContext (only way now to have
>> independently seekable streams) is going the thrash memory anyway
>> (strictly SOTP of course).
>
>
> SOTP? Could you decode that for me...? ;-)
Seat-of-the-pants :-)
>
> I wasn't that worried about thrashing memory... more worried about
> thrashing the disk. The OS's disk cache and/or the HD's built-in cache
> is probably going to catch that, but if not, the disk head is going to
> be going back and forth a lot. ;-) That's what I was referring to...
It is unlikely that the disk blocks for V and A at the same timestamp
will be very far from each other.
>
> Martin
>
--
Michel Bardiaux
Peaktime Belgium S.A. Bd. du Souverain, 191 B-1160 Bruxelles
Tel : +32 2 790.29.41
More information about the ffmpeg-devel
mailing list