[FFmpeg-devel] [HACK] mov edl desync fix
Sun Jan 11 10:21:35 CET 2009
On Fri, Jan 09, 2009 at 02:20:51PM -0800, Baptiste Coudurier wrote:
> Reimar D?ffinger wrote:
> > I am really certain this is wrong (does FFmpeg even allow negative
> > timestamps? They mean the thing you might naively assume them to mean
> > in this case, namely parts that are "before" the start of the track/video).
> > Nevertheless it works quite nicely...
> > At the very least the debug message should be changed to print the track
> > and the exact delay in seconds so it can be fixed manually.
> > A sample currently is available here:
> > http://www.doppelbauer.name/desync.mov
> > but I guess there are also some somewhere on samples @mphq.
> Well I'd love to get this fixed, and I would not mind such hack after
> all, but the problems I see here are:
> - This is valid if only 1 edit list element is present, so this would
> need to be checked.
That's simple to do. Also time values of -1 should be ignored it seems,
since they mean an empty list (sounds weird, since there is also a
length entry and it is unclear what other values < 0 are supposed to
Though it seems more correct to me to also do this for edls with more
than one part (of course only the time of the first chunk is relevant),
attached patch would do that.
> - The time value refers to the pts not the dts according to specs,
> typically this value is 1 for there is delay (first pts is 1 and first
> dts is 0)
The specification pdf from May 1996 that I have at hand says nothing
about that. But assuming that were true, the current check for time != 0
would be wrong already.
Also, why does the delay (I assume you mean decoder delay) get hard-coded
into the pts, after all such stuff depends on the decoder implementation,
does mov really assume a specific decoder implementation to code pts?
If so, that really sounds like a container deficiency we could not do
much about, unless you want to hard-code the assumed decoder delays.
And what about audio? Is there some delay you have to "guess" as well,
or it at least be used for audio tracks?
-------------- next part --------------
--- libavformat/mov.c (revision 16516)
+++ libavformat/mov.c (working copy)
@@ -124,6 +124,7 @@
+ int time_offset;
unsigned int bytes_per_frame;
unsigned int samples_per_frame;
@@ -1215,7 +1216,7 @@
MOVStreamContext *sc = st->priv_data;
- int64_t current_dts = 0;
+ int64_t current_dts = -sc->time_offset / sc->time_rate;
unsigned int stts_index = 0;
unsigned int stsc_index = 0;
unsigned int stss_index = 0;
@@ -1731,7 +1734,8 @@
/* edit list atom */
static int mov_read_elst(MOVContext *c, ByteIOContext *pb, MOVAtom atom)
- MOVStreamContext *sc = c->fc->streams[c->fc->nb_streams-1]->priv_data;
+ int streamnr = c->fc->nb_streams-1;
+ MOVStreamContext *sc = c->fc->streams[streamnr]->priv_data;
int i, edit_count;
get_byte(pb); /* version */
@@ -1743,9 +1747,11 @@
get_be32(pb); /* Track duration */
time = get_be32(pb); /* Media time */
get_be32(pb); /* Media rate */
- if (time != 0)
- av_log(c->fc, AV_LOG_WARNING, "edit list not starting at 0, "
- "a/v desync might occur, patch welcome\n");
+ if (i == 1 && time != -1)
+ sc->time_offset = time;
+ if (time != 0 && time != -1)
+ av_log(c->fc, AV_LOG_WARNING, "edit list %i for track %i not starting at 0 (but %i), "
+ "a/v desync might occur, patch welcome\n", i, streamnr, time);
dprintf(c->fc, "track[%i].edit_count = %i\n", c->fc->nb_streams-1, sc->edit_count);
More information about the ffmpeg-devel