[FFmpeg-devel] FOMS 2009 FFmpeg outbrief
Tue Jan 27 07:17:11 CET 2009
Hi Carl Eugen,
Baptiste Coudurier wrote:
> 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.
Demuxer now seek at 0 when negative timestamp is requested. Could you
please check that everything is fine ? Thanks.
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