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

Reimar Döffinger Reimar.Doeffinger
Thu Mar 4 21:08:01 CET 2010


On Thu, Mar 04, 2010 at 07:42:05PM +0000, M?ns Rullg?rd wrote:
> Reimar D?ffinger <Reimar.Doeffinger at gmx.de> writes:
> >> > Is this "misuse" of fseek covered by our API specification?
> >> > It assumes that seeking with url_is_streamed does never have a
> >> > negative effect, however I'm not sure it couldn't be horribly
> >> > slow or it might not keep the state the same or it might be possible
> >> > to seek backward but seeking forward to the original position might fail...
> >> 
> >> Seeking within the buffer is always fast.  The seek function of the
> >> underlying protocol is only invoked if the target is outside the buffer.
> >
> > I don't understand what that has to do with what I said at all.
> > There's nothing in the documented API that would allow you to assume
> > that url_fseek will not seek outside the buffer if url_is_streamed
> > is true.
> 
> So fix the documentation.  I don't understand what you are complaining
> about.

I don't want it documented because I think that wouldn't be the best API!

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



More information about the ffmpeg-cvslog mailing list