[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

On Wed, Apr 07, 2010 at 08:48:44AM -0700, Howard Chu wrote:
> 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.

av_rescale_rnd() in this case

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates
-------------- 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/26922984/attachment.pgp>