[FFmpeg-devel] FOMS 2009 FFmpeg outbrief

[Baptiste Coudurier]

Hi Carl Eugen,

Carl Eugen Hoyos wrote:
> M?ns Rullg?rd <mans <at> mansr.com> writes:
> 
>>>> mplayer now uses lavf mp4 demuxer by default. the only big bug i can
>>>> see is that the binary svq3 and qdm2 (and probably all binary codecs)
>>>> are broken (extradata problem?).
>>> Seeking before beginning (which is not unusual using MPlayer and
>>> well supported by the mov native demuxer) does not work:
>> I don't see how such an operation could possibly work.  It could
>> fail in a number of different ways, but never actually do what was
>> asked, which is a typical definition of "work".
> 
> Then please test mplayer with -demuxer mov. It (reliably) shows the first frame
> of the movie and does not report problems.
> -demxuer lavf often reads the whole file, decides that no recovery is possible,
> prints a few errors and exits.

Yes this is true, however "mplayer" is asking for a "negative"
timestamp. Demuxer returns an _error_, why isn't this correclty handled ?

Also, yes, retrying with generic seeking is odd, and I proposed a patch
a long time ago (21/04/2007), it was discussed in:
[Ffmpeg-devel] [RFC] av_seek_frame behaviour

I still maintain that each demuxer having a seek function should handle
fallback to generic internally if wanted/needed, not av_seek_frame, this
means that if demuxer seek function returned error, av_seek_frame _must_
return this error IMHO, not trying to fall back on generic.

I don't think I have objection with negative timestamp being reset to 0
however.

[...]

-- 
Baptiste COUDURIER                              GnuPG Key Id: 0x5C1ABAAA
Key fingerprint                 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer                                  http://www.ffmpeg.org