[FFmpeg-devel] [PATCH] RTMP seek support

Howard Chu hyc
Sun Apr 11 01:27:00 CEST 2010


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.

If you round up while seeking forward, it's possible to overshoot the target 
and completely miss it, 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.

https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086318.html

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



More information about the ffmpeg-devel mailing list