[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