[FFmpeg-cvslog] r22197 - trunk/libavformat/matroskaenc.c

[David Conrad]

On Mar 4, 2010, at 5:30 PM, Reimar D?ffinger wrote:

> On Thu, Mar 04, 2010 at 09:27:53PM +0000, M?ns Rullg?rd wrote:
>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>>> On Thu, Mar 04, 2010 at 07:42:05PM +0000, M?ns Rullg?rd wrote:
>>>> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
>>>>> So above code adds the assumption that seeking backwards will be either
>>>>> reasonably fast or fail even in the url_is_streamed case, while the
>>>>> documentation would not even give someone implementing a protocol any hint
>>>>> about this - they might reasonably say "well, seek is so horribly slow
>>>>> we absolutely need avoid it, so we set is_streamed, however we would still
>>>>> be able to somehow play formats that absolutely require seeking, so we implement
>>>>> it anyway". If they wanted it to work well with the matroska muxer too they
>>>>> now would have to add a special hack...
>>>> 
>>>> The protocol seek function _is never called_ in this case.  No, the
>>>> documentation of url_fseek() doesn't mention this.  Patches welcome.
>>> 
>>> Either I'm blind again or you have no idea what you are talking about...
>>> The seek function is called even for is_streamed if it is considered
>>> necessary, and I consider than good and sensible behaviour, however
>>> it somewhat clashes with this newly added code.
>>> Now it's not such an important issue, but considering that at least one
>>> of us is confused I conclude it wasn't such a bad idea to mention it anyway.
>> 
>> The low-level seek function is only called if the seek target is
>> outside the buffer.  This is handled in generic code, and protocols
>> need not worry.  Why don't you go and read the source yourself?
> 
> I've been talking only and exclusively about the case when the seek
> is outside the buffer, and this new code assumes basically that url_fseek
> will fail if the seek went outside the buffer and is_streamed is set.

If it doesn't fail, isn't the protocol asserting that this code work? If a protocol doesn't support seeking backwards, it should return an error if asked to do so in read_seek and leave the state unchanged, which is all this code assumes.

That, and if seeking backwards worked then returning to the original position will too, which I don't see why it wouldn't.