[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

On Wed, Apr 07, 2010 at 08:37:23AM -0700, Howard Chu wrote:
> Michael Niedermayer wrote:
>> On Tue, Apr 06, 2010 at 10:50:21PM -0700, Howard Chu wrote:
>>> Michael Niedermayer wrote:
>>>> On Thu, Apr 01, 2010 at 01:11:24PM -0700, Howard Chu wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> On Wed, Mar 31, 2010 at 05:24:49PM -0700, Howard Chu wrote:
>>>>>>> Howard Chu wrote:
>>>>>>>> Michael Niedermayer wrote:
>>>>>>>>> removial is planed but the new API might be changed if we find the
>>>>>>>>> need
>>>>>>>>> to change it still ...
>>>>>>>
>>>>>>> It seems to me that one thing that ought to be changed is that
>>>>>>> rescaling
>>>>>>> the timestamp should still be done by the caller, not in read_seek2.
>>>>>>> Right
>>>>>>> now each implementation of read_seek2() has to duplicate this code.
>>>>>>
>>>>>> if rescaling is done outside then exact seeking becomes impossible
>>>>>> because rescaling implicates rounding
>>>>>
>>>>> But that's always true, regardless. If you sepcify a seek timestamp in
>>>>> nanoseconds and the stream only supports microseconds, it is going to
>>>>> have
>>>>> to round anyway.
>>>>
>>>> there are normally several streams, and their timebases normally differ.
>>>
>>> That cannot be true in an FLV.
>>
>> indeed
>> so your code uses timebase even though you know its 1000, thats not 
>> optimal
>> either
>
> It's #if 0'd so at this point it's irrelevant. Someone else who knows how 
> it's really supposed to work can write a correct implementation.
>

>> also my original point is still true rounding the way you do breaks exact
>> seeking. if i say seek to 0.9 or before and you change this to
>> 1.0 or before thats just a different range and can seek to a different 
>> point
>> thats also not just seek2 its in the remaining code too
>
> There is no way to convey this intent to the RTMP server. No matter how 
> exactly you compute the timestamp the server will only seek to what it 
> thinks is the nearest frame.

so will you fix it? or will you knowingly round the wrong direction
because there are other unrelated problems?

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu
-------------- 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/20100407/24c8ad6e/attachment.pgp>