[FFmpeg-devel] [PATCH] Support for variable frame duration

[Michael Niedermayer]

On Fri, Apr 18, 2008 at 07:06:00AM +0200, Henrik Gulbrandsen wrote:
> Well, time for the bug I am really trying to fix. What I have is a small
> slide show generated as a set of timed JPEG images in an MP4 container.
> This file should be converted to various other video formats, but FFmpeg
> currently doesn't cope well with randomly varying frame durations.
> 
> The original set of test slides and Ogg Theora files generated before
> and after my preliminary patch attempt are found at the following URLs:
> 
>     http://www.gulbra.net/ffmpeg-devel/movies/slides.mov
>     http://www.gulbra.net/ffmpeg-devel/movies/before_video_duration_patch.ogv
>     http://www.gulbra.net/ffmpeg-devel/movies/after_video_duration_patch.ogv
> 
> Attached output of the mp4info and mp4videoinfo tools from MPEG4IP shows
> what the slides.mov file looks like. It's exactly 24 seconds long, with
> new slides appearing at 1, 2, 3, 4, 6, 8, 12, and 16 seconds. Each slide
> shows the slide number and the time when it should ideally be presented.
> 
> Now, in an attempt to make a minimal patch set, I am trying to fix the
> problem by hooking into the existing video synchronization code. This is
> based on syncing all the way up to the next PTS, so it requires correct
> duration info from the demuxer. Replacing our pts with next_pts actually
> does the right thing (in terms of frame count) without other changes, so
> there may potentially have been an off-by-one problem in the past...
> 
> These changes are more central, more extensive, and probably much more
> controversial than my earlier patches, so feel free to flame me now! :-)
> I haven't checked the regression tests either, but will be back with any
> needed updates within a day or two. Right now, I have a train to catch.

The change to mov demuxer change might be ok (ill leave it to baptiste to
review)
Ill review the ffmpeg change after you confirm that the regression tests
do passs.
Also mov and ffmpeg changes are independant and should be 2 seperate
patches.

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20080418/91c4ec6e/attachment.pgp>