[FFmpeg-devel] [PATCH] RTMP seek support

[Howard Chu]

Michael Niedermayer wrote:
> 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?

I've been trying to fix it. But while you're telling me that it's wrong, no 
one is telling me how to do it right.

No, I will not fix it. I've spent enough time on it already.

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/