[mythtv-users] mytharchive: non monotone timestamps error in ffmpeg

[Will Dormann]

As mentioned in a previous thread, I've got a recording that fails to
transcode into MPEG2.   The specific error is:  non monotone timestamps

The details for the video are:

Seems stream 0 codec frame rate differs from container frame rate: 59.94
(60000/1001) -> 59.94 (60000/1001)

Input #0, mpegts, from '/mnt/slanky/mythtv/2198_20110107010000.mpg':


  Duration: 00:05:47.11, start: 0.387056, bitrate: 66824 kb/s


  Program 1


    Stream #0.0[0x1011]: Video: h264, yuv420p, 1920x1080 [PAR 1:1 DAR
16:9], 59.96 fps, 59.94 tbr, 90k tbn, 59.94 tbc

    Stream #0.1[0x1100]: Audio: ac3, 48000 Hz, 5.1, s16, 448 kb/s


Assuming NTSC for target.


[mpeg2video @ 0x81c5d80]impossible bitrate constraints, this will fail


Output #0, dvd, to '/var/lib/mytharchive/temp/work/1/newfile2.mpg':


  Metadata:


    encoder         : Lavf52.64.2


    Stream #0.0: Video: mpeg2video, yuv420p, 720x480 [PAR 32:27 DAR
16:9], q=2-31, pass 1, 9000 kb/s, 90k tbn, 29.97 tbc

    Stream #0.1: Audio: ac3, 48000 Hz, 5.1, 448 kb/s


Stream mapping:


  Stream #0.0 -> #0.0


  Stream #0.1 -> #0.1


The transcode stops with:

[dvd @ 0x81c7bb0]st:1 error, non monotone timestamps 291611519 >= -1


av_interleaved_write_frame(): Operation not permitted



Is my understanding of "st:1" correct in that the bug is in stream #1,
which is the AC3 audio stream?   I recently switched the hd-pvr to
record AC3 over the optical spdif from my motorola 6200 stb, where it
used to be just the stereo RCA jacks (AAC format).

The closest ffmpeg bug I can see is: https://roundup.ffmpeg.org/issue807
But that is for cases where the timestamp numbers are the same, and the
patch is to change the check from ">=" to just ">".   However in my case
that patch would have no effect as I'm seeing 291611519 and -1.

I think for now I'll switch to RCA audio recording to see if the problem
disappears, though in the long run I'd like to have spdif working.
Can anybody confirm whether my conclusions are correct about the problem
being in the AC3 stream?   Given that my chances of having
Comcast/Motorola fix the 6200, I assume something needs to happen to
ffmpeg to work around this issue?


Thanks
-WD