[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

On Sun, Apr 11, 2010 at 04:40:06PM -0700, Howard Chu wrote:
> Michael Niedermayer wrote:
>> 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
>
> Thanks for the explanation. In each case one of the 3 ts parameters is 
> always a constant. Sounds to me like this was better handled with only two 
> ts parameters at most, in combination with AVSEEK_FLAG_BACKWARD.
>
> Also sounds like the convention for exact seek was pretty arbitrary, it 
> could just as easily have been min_ts = target_ts, max_ts = INT64_MAX.

streams play forward not backward, so no that would not work, it would
not reach the wanted position


>
> Instead of these magical conventions that aren't at all obvious from 
> reading the code or its documentation, why not use:
>   current_ts, target_ts, flag.
>
> For exact seek you can still use current_ts = INT64_MIN as a special case 
> but otherwise you drop one useless parameter.

an application might prefer to do seeking with all 3 timestamps different,
above where just examples.

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"
-------------- 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/20100412/51ef7a15/attachment.pgp>