[FFmpeg-devel] [PATCH] RTMP seek support

Howard Chu hyc
Thu Apr 1 00:25:12 CEST 2010

Michael Niedermayer wrote:
> On Wed, Mar 31, 2010 at 01:09:02PM -0700, Howard Chu wrote:
>> Michael Niedermayer wrote:
>>> On Tue, Mar 30, 2010 at 01:24:47PM -0700, Howard Chu wrote:
>>>> Howard Chu wrote:
>>>>> Howard Chu wrote:
>>>>>> Howard Chu wrote:
>>>>>>> This is a first stab at getting seek working on an RTMP stream.
>>>>>>> Unfortunately,
>>>>>>> it usually fails. Sometimes it works correctly, but most times it just
>>>>>>> hangs.
>>>>>>> Apparently there's something getting out of sync, but I don't have any
>>>>>>> idea
>>>>>>> where. Any help would be appreciated.
>>>>>>> I've been testing with this stream:
>>>>>>> gdb --args ./ffplay_g
>>>>>>> "rtmp://fms.scctv.net/annenberg//vod/world_of_chemistry_01
>>>>>>> swfurl=http://www.learner.org/vod/swfs/player-licensed.swf
>>>>>>> pageurl=http://www.learner.org/vod/vod_window.html?pid=793"
>>>>>> Thanks to a tip from uau this is now working.
>>>>> Some confusion over whether to implement read_seek or read_seek2.
>>>>> av_seek_frame() already rescales the timestamp correctly for the stream,
>>>>> so
>>>>> the protocol handler shouldn't be doing that. (But avformat_seek_file
>>>>> doesn't
>>>>> rescale, so read_seek2 would need to do it.)
>>>> Cleaned up some more. Since it looks like the read_seek2 API is still a
>>>> work in progress I've dropped it from the patch.
>>> please elaborate
>>> its a huge amount of work to port every demuxer to read_seek2().
>>> Thus every that implements the old API means more work for us
>> I just didn't find a lot of examples to convince myself that this API was
>> being used. And nobody chimed in before on my doubt about whether I should
>> even implement it or not. And the API itself seems untenable; if the
>> handler is actually responsible for rescaling the timestamps, it needs to
>> have access to the stream table to be able to get the correct time bases.
>> But down at this layer of the API, there is no way to get to the stream
>> table.
> iam not sure i understand you,
> AVFormatContext.streams[].time_base
> contains all the timebases

>> It would help if someone could point to a doc describing the plans for the
>> new API vs the old API. Is the old API going to be removed?
> removial is planed but the new API might be changed if we find the need
> to change it still ...

So it seems safer to me to avoid it at this stage. I'd rather get base 
functionality working first, to make sure I understand how things work today, 
and then revisit later when the new approach is settled.

And most of the pieces I touched only implement the old API. URLProtocol only 
has read_seek. aviobuf.c only provides av_url_read_fseek. (And what's the 
significance of the 'f' in the name here? Why wasn't it just called 

At these layers, all the handlers get passed are URLContext or ByteIOContext. 
So the stream_index being passed to them seems to be unusable, certainly they 
have no way to reach the AVFormatContext from there.

   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

More information about the ffmpeg-devel mailing list