>> The statement is partly right though. E.g. mplayer svn at some point
>> defaulted to lavf for mp4 demuxing, which doesn't care for the edit
>> list atom implementing the start time delay, in nonconformance with
>> the standard. RC2 on the other hand defaults to libquicktime for
>> demuxing, which does honor it.
>
> Actually, mplayer used it's own quicktime demuxer, which is still there,
> but deprecated. It is somewhat messy and unmaintained. You can use it
> with '-demuxer mov'.
Ye right. Thought it was libquicktime because it used to crash on the
same interlaced video height resolutions not being mod32
situations. In demux_mov.c now I read heroine though. Either way, it
was the default mp4 demuxer in rc2, and it handled edit list
atoms. The current default, lavf, does not. That was the whole point.
>> It's one of several issues I ran into with svn. By now, I tend to
>> advise against using it and rather revert to rc2, if reliable and
>> predictable behavior is desired.
>
> I don't pay much attention to quicktime stuff, but if the ffmpeg
> developers are unaware of deficiencies in the lavf demuxer, you ought to
> file a bugreport for them.
Sure, when I come around to it. I believe it's a known issue though,
as there have been page long discussions on the handbrake forums about
mplayer not correctly handling their video due to it's ignoring edit
lists.
It's been about mp4, by the way, not particularly about quicktime.
_______________________________________________
MEncoder-users mailing list
MEncoder-users@mplayerhq.hu
https://lists.mplayerhq.hu/mailman/listinfo/mencoder-users
No comments:
Post a Comment