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

[Reimar Döffinger]

On Thu, Mar 04, 2010 at 05:37:24PM -0500, David Conrad wrote:
> 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.

First off to clarify: I am trying to point out what looks like an API
issue or at least a API documentation issue, not an actual bug.

I can't think of a reasonable example where it is an issue, but for
the purpose of showing what could happen:
There might be a write protocol that writes as a HTTP PUT request.
It could support seeking forward by filling with 0 and seeking backwards
by reading the data previously written and writing it back up to the
seek position.
So seeking back would be unreasonable (close to unusably) slow and it would
loose any data beyond the seek condition.
Even if it would keep the data, some users might prefer the previous behaviour
because it would be faster.
Of course that can quickly be done by just disabling the seek function, but
that might not be ideal, also in the model of the API I had in mind, the seek
function would be called for is_streamed I/O only when the absolutely only
alternative would be to fail.