[FFmpeg-devel] [PATCH] RTMP seek support

[Howard Chu]

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 
av_url_read_seek?)

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/