[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

On Wed, Mar 31, 2010 at 03:25:12PM -0700, Howard Chu wrote:
> 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.

iam not truely happy but ok

[...]
-- 
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/20100401/2de247e7/attachment.pgp>