[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

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 ...


> What's the 
> benefit of and motivation for the new one?

the benefits are quite simply explained
1. to simply seek forward or backward with the cursor keys one needs
   to provide the API with at least the current timestamp + the direction
   + the distance.
   The old API just had te target timestamp and the direction, it did not
   know the current position and thanks to the possibility of a packet que
   between demuxer and decoder it could not assume that the last demuxed
   packed was very close to the current position.
   To see the problem this causes consider that seeking is requested to
   time 10 and the direction is a seek forward, there might be a keyframe
   at time 7 and the next at time 80. The old code had to pick the one
   at 80 because picked it 7 a forward seek could actually become a
   backward seek if the distance from the current position was small.
   By providing the seeking code with more complete information it can
   make a more better decission
2. when one wished to seek "exactly" to position 10 then one needs to
   seek so that all the streams have a keyframe before they reach position
   10. otherwise the target could not be decoded and displayed to the user


[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100331/bef82062/attachment.pgp>