[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Thu Jan 22 21:40:31 CET 2009
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
Baptiste COUDURIER GnuPG Key Id: 0x5C1ABAAA
Key fingerprint 8D77134D20CC9220201FC5DB0AC9325C5C1ABAAA
checking for life_signs in -lkenny... no
FFmpeg maintainer http://www.ffmpeg.org
More information about the ffmpeg-devel