[Ffmpeg-devel] [RFC] av_seek_frame behaviour

[Baptiste Coudurier]

Reimar D?ffinger a ?crit :
> Hello,
> On Sun, Apr 22, 2007 at 04:13:42PM +0200, Baptiste Coudurier wrote:
>> Reimar D?ffinger a ?crit :
>>> On Sun, Apr 22, 2007 at 02:50:52AM +0200, Baptiste Coudurier wrote:
>>>>  I think about always returning after demuxer seek function, see patch.
>>>>  It might be wrong, and missed some demuxers behaviour.
>>> This will most likely break seeking for gxf files without index.
>> Ouch, therefore problem is there for 10gb without index GXF files as 
>> well. Btw, it would be very much more efficient to seek on MEDIA packet 
>> for GXF, when no index is found.
> 
> That is what av_seek_frame_binary does for gxf. And your patch removes
> that av_seek_frame_binary fallback...

Humm it seems av_seek_frame_binary does use index when it is present, 
why not always using av_seek_frame_binary for GXF ?

>>> If anything, introduce two different return values, one indicating that
>>> the frame definitely is not there and another one to indicate that we
>>> should try the other seek methods.
>>> But that still will not fix your problem. From the description I'd say
>>> what you want is a FAST_SEEK_ONLY flag or similar that would only allow
>>> seek methods with O(log n) max.

Basically, no. I'd like the seek to just fail and not trying anything 
else, since there is absolutely no packet with that timestamp if MXF 
seek function fails.

Before r7871 it failed much faster, since av_seek_frame_generic failed 
immediately without index.

>>> (which is another things that IMO is
>>> wrong with that patch, av_seek_frame_binary is O(log n), so except for
>>> streamed content there is not much reason to try that as well.
>> That has nothing to do with my patch, current code will always try 
>> av_seek_frame_binary if demuxer has read_timestamp and no seek function 
>> or if its seek function returned < 0.
> 
> ?? Why do my suggestions to fix the problem in a "proper" way (i.e. without
> removing the feature of falling back to possibly more reliable seek methods
> as your patch does) have nothing to do with your patch?

What's you suggestion ? "av_seek_frame_binary is O(log n), so except for 
stream context there is not much reason to try that as well ?"

I get that to mean that there is no point using av_seek_frame_binary 
except for stream context, and that has nothing to do with that patch.

Or did you mean that "av_seek_frame_binary" should be tried except for 
stream context ?

>> What about calling av_seek_frame_generic only for formats having 
>> AVFMT_GENERIC_INDEX ?
> 
> Well, IMO any such fixed problem does not solve what I feel is the real
> problem: Some people will want fast seeks, others need them to be as
> precise as possible.

Real problem is to fail quickly when it has to fail. Trying other 
methods is a plus. So maybe returning AVSEEK_FAIL, AVSEEK_TRY_BINARY, 
AVSEEK_TRY_GENERIC, or AVSEEK_FLAG_TRY_ALL user can pass.

A failing demuxer seek function should not mean that other methods 
should be tried.

av_seek_frame_generic when no index is present does read all packets 
since the beginning that is clearly too expansive and should not be done 
unless explicitely asked.

> But solving that problem might be too much effort
> just for this one issue.

Oh yes.

> Don't know what exactly AVFMT_GENERIC_INDEX is intended for, so also not
> sure if that's a good use for it.

Demuxer asks libavormat internals to generate index in a generic way, 
that is registering one key frame when it reads one.

> And what about av_seek_frame_binary?  till always calling it whenever
> the "main" seek function is fails?

IMO if demuxer knows that av_seek_frame_binary works, it should call it
itself from its seek function.

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no