[FFmpeg-devel] [PATCH] RTMP seek support

[Michael Niedermayer]

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


>
> 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


> thus necessitating another seek attempt. If 
> you round down, there's no chance to overshoot, and you definitely will not 
> miss the target.
>>
>>
>>> +
>>>       if (!RTMP_SendSeek(r, timestamp))
>>>           return -1;
>>>       return timestamp;
>>
>>> Index: libavformat/aviobuf.c
>>> ===================================================================
>>> --- libavformat/aviobuf.c	(revision 22813)
>>> +++ libavformat/aviobuf.c	(working copy)
>>> @@ -698,8 +698,11 @@
>>>           return AVERROR(ENOSYS);
>>>       ret = s->read_seek(h, stream_index, timestamp, flags);
>>>       if(ret>= 0) {
>>> +        int64_t pos;
>>>           s->buf_ptr = s->buf_end; // Flush buffer
>>> -        s->pos = s->seek(h, 0, SEEK_CUR);
>>> +        pos = s->seek(h, 0, SEEK_CUR);
>>> +        if (pos != AVERROR(ENOSYS))
>>> +            s->pos = pos;
>>>       }
>>>       return ret;
>>>   }
>>
>> this should be a seperate patch
>
> I specifically asked about this 9 days ago and nobody addressed it. This 
> review process would be a lot less unpleasant and wasteful if you folks 
> didn't wait so long to address these issues.

i can refrain from commenting issues i see, i cant comment issues/questions
i miss, lack the motivation to deal with or lack the time to deal with.
Suggestion to improve this are welcome, unconstructive complaints that our
review process isnt ideal are less welcome

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

Asymptotically faster algorithms should always be preferred if you have
asymptotical amounts of data
-------------- 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/815a54d4/attachment.pgp>