[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

On Sat, Apr 10, 2010 at 07:20:46PM -0700, Howard Chu wrote:
> Michael Niedermayer wrote:
>> On Sat, Apr 10, 2010 at 04:27:00PM -0700, Howard Chu wrote:
>>> Michael Niedermayer wrote:
>>>> On Sat, Apr 10, 2010 at 09:26:31AM -0700, Howard Chu wrote:
>>>>> Michael Niedermayer wrote:
>>>>>> On Wed, Apr 07, 2010 at 08:48:44AM -0700, Howard Chu wrote:
>>>>>>> Michael Niedermayer wrote:
>>>>>>>> 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
>>>>>
>>>>> One more go-round.
>>>> [...]
>>>>
>>>>> Index: libavformat/librtmp.c
>>>>> ===================================================================
>>>>> --- libavformat/librtmp.c	(revision 22813)
>>>>> +++ libavformat/librtmp.c	(working copy)
>>>>> @@ -124,10 +141,12 @@
>>>>>        RTMP *r = s->priv_data;
>>>>>
>>>>>        if (flags&   AVSEEK_FLAG_BYTE)
>>>>> -        return AVERROR_NOTSUPP;
>>>>> +        return AVERROR(ENOSYS);
>>>>>
>>>>>        /* seeks are in milliseconds */
>>>>> -    timestamp = av_rescale(timestamp, AV_TIME_BASE, 1000);
>>>>> +    if (stream_index<   0)
>>>>> +        timestamp = av_rescale_rnd(timestamp, 1000, AV_TIME_BASE,
>>>>> AV_ROUND_DOWN);
>>>>
>>>> the rounding direction depends on the the flags for the old seeking
>>>> API
>>>
>>> I thought about that, but I disagree. The stream is playing forward
>>> regardless, so any difference between rounding up or rounding down will
>>> disappear by the time the next frame plays.
>>
>> The old as well as new APIs clearly specify what a demuxer should do.
>> unless you suggest to change a deprecated API implementing it to the
>> best that is possible is what should be done
>
> Ok.
>
> Should certainly think about it again in the new API. There's no 
> information available for a caller to decide what min_ts/max_ts intervals 
> to use. E.g., typically the minimum seek quantum will be the distance 
> between two keyframes, and that won't necessarily be a constant in any 
> given stream. Looks like the caller would have to go to a lot of trouble to 
> get this info.

the idea is generally for a calling application to use
for forward seeks:
min_ts = current displayed time +1
max_ts = INT64_MAX
target_ts= min_ts + how far the cursor "->" key should seek

for backward seeks:
min_ts = INT64_MIN
max_ts = current displayed time -1
target_ts= max_ts - how far the cursor "<-" key should seek

for an exact seek:
min_ts = INT64_MIN
max_ts = target_ts= the time the user wants to seek to



>
>>> If you round up while seeking forward, it's possible to overshoot the
>>> target and completely miss it,
>>
>> no, i dont think its possible in this case.
>> If it where then no rounding could be done because rounding down is wrong
>> that would mean the code would need to work with the exact timestamp
>
> Even if you have the exact timestamp it may be useless, if you're trying to 
> seek to a non-keyframe. I don't know what apps you're thinking of that 
> depend on this accuracy, certainly most users watching their media players 
> don't care.

Video editing applications requir frame exact seeking


> But there will be plenty of cases where rounding up can 
> overshoot, if the underlying stream is forced to seek to the next keyframe.

please show me an example


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

I hate to see young programmers poisoned by the kind of thinking
Ulrich Drepper puts forward since it is simply too narrow -- Roman Shaposhnik
-------------- 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/20100411/ed933787/attachment.pgp>