[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