[FFmpeg-user] AVCHD from a Canon HF G10: 'non monotonically increasing dts' + dts mess

[Robert Krüger]

Damian,
On Aug 21, 2011, at 21:24 , Damian Stewart wrote:

> Hi all,
> 
> I'm trying to convert a number of AVCHD 1080i 50fps videos from a Canon HF G10 to mp4/mov container format, but ffmpeg is failing with a 'non monotonically increasing dts' error message at the start of each one. I'm on Mac OSX 10.6, I've tried both ffmpeg 0.8.0 (compiled by Homebrew) and 0.8.2 (compiled by ./configure && make).
> 
> Here's the commandline. The file is here: http://frey.co.nz/share/00167.MTS (2.2MB)
> 
> $ ffmpeg -i 00167.MTS -vcodec copy -acodec copy out/00167.mp4
> 
> Output fails with:
> 
> Input #0, mpegts, from '00167.MTS':
>  Duration: 00:00:01.44, start: 0.483578, bitrate: 12967 kb/s
>  Program 1 
>    Stream #0.0[0x1011]: Video: h264 (High), yuv420p, 1920x1080 [PAR 1:1 DAR 16:9], 50 fps, 50 tbr, 90k tbn, 50 tbc
>    Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, stereo, s16, 256 kb/s
> ...
> [mp4 @ 0x101071200] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 1 >= 1
> 
> If I run ffprobe, the timestamps seem to be scrambled:
> 
> $ ffprobe -show_packets 00167.MTS | grep dts
> 
> ...
> dts=47119
> dts_time=0.523544 
> dts=49999
> dts_time=0.555544 
> dts=52879
> dts_time=0.587544 
> dts=55759
> dts_time=0.619544 
> dts=43519
> dts_time=0.483544 
> dts=45319
> dts_time=0.503544 
> dts=47119
> dts_time=0.523544 
> dts=48919
> dts_time=0.543544 
> dts=50719
> dts_time=0.563544 
> dts=58639
> dts_time=0.651544 
> dts=52519
> dts_time=0.583544 
> ...
> dts=75919
> dts_time=0.843544 
> dts=75919
> dts_time=0.843544 
> dts=78799
> dts_time=0.875544 
> dts=77719
> dts_time=0.863544 
> dts=79519
> dts_time=0.883544 
> dts=81679
> dts_time=0.907544 
> dts=81319
> dts_time=0.903544 
> dts=83119
> dts_time=0.9
> 
> 
> What's going on here? Is my camera really putting out such scrambled timestamps? Is there anything I can do about it?
> 
> Any help appreciated.
> 
> Cheers,
> Damian
> 

could you please file a bug report in the bug tracker and supply a very short sample clip with it?

I've had a similar problem in the past and it is buried somewhere in the old roundup bugtracker that I don't know if anyone is using it or if the information is essentially lost. I managed to get this working in my case with a hack in the code by replacing a ">"-Check with ">=" where the error occurred but it might be something else in your case and of course that was not a proper fix but if you want to get your material transcoded, you probably don't really care about that (I didn't). In any case, having this in the bug tracker with a small sample increases chances that someone can/will fix it. Please provide the camera model and recording mode in your bug report so others find this when they run into the same problem.

Cheers,

Robert