[FFmpeg-devel] [PATCH] RTMP seek support
Wed Mar 31 22:09:02 CEST 2010
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.
>>>>> it usually fails. Sometimes it works correctly, but most times it just
>>>>> Apparently there's something getting out of sync, but I don't have any
>>>>> where. Any help would be appreciated.
>>>>> I've been testing with this stream:
>>>>> gdb --args ./ffplay_g
>>>> 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,
>>> the protocol handler shouldn't be doing that. (But avformat_seek_file
>>> 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.
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? What's the benefit of
and motivation for the new one?
-- 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