[FFmpeg-devel] Bug when using the codec copy command line...

Andy Sheen sheen.andy
Wed Jan 28 22:02:24 CET 2009


Hi all,

Apologies if this is posted in the wrong place - it seems more suited to
the developers list...

I think I've found an issue with the handling of "-[av]codec copy"
command line...

The symptoms:

When choosing "copy" as either the audio or video codec, for example as in:

ffmpeg -i video.mkv -vcodec copy -acodec ac3 video1.mkv

sometimes the program fails with the following error:

[NULL @ 0x8076d00]error, non monotone timestamps xxxxxx >= yyyyy
av_interleaved_write_frame(): Error while opening file

Doing some debug, this is because of line (around 2540 of
libavformat/utils.c)

     if(st->cur_dts && st->cur_dts != AV_NOPTS_VALUE && st->cur_dts >=
pkt->dts){

Basically, the line is checking to see if the current packet DTS is
after the streams DTS. If it isn't it causes an error.

If you copy both streams (i.e. command ffmpeg -i x.mkv -acodec copy
-vcodec copy y.mkv), the error is:

[NULL @ 0x8076d00]error, non monotone timestamps yyyy >= yyyy
av_interleaved_write_frame(): Error while opening file

where the timestamps are equal. I can't find a command line variable
which affects this (tried -dts_delta_threshold, -muxdelay, -muxpreload)

There appear to be a number of issues here:

1) A&V copy results in a failure as the test is >=. Perhaps the test in
    the code line above should be just > instead of >=?
2) Reencoding one of the streams causes the DTS timestamp to be moved.
    When copying the other stream, would it be sensible to move the
    timestamp of the copied stream out by the same amount (to remain in
    sync with the original stream)?
3) The error returned to the command line is pretty confusing ("non
    monotone timestamps" would probably be better as "packet timestamp is
    before container timestamp" or something like that) and the fact that
    the routine returns -1 means that the error reporting thinks it is a
    file error is also very confusing!!

The workaround is to demux, reencode then mux back in, but this seems
very painful when the copy is there to do just what I want in a single
line....


Any comments form the developers on this - I can code in C, but I'm not
familiar with the overall structure of ffmpeg so don't feel confident to
implement the "correct" solution (although if someone points me in the
right direction...).

Thanks

Andy





More information about the ffmpeg-devel mailing list