Flash 11 RTMP h264 non monotonically increasing error

[Jeremy]

When trying to capture an RTMP stream that's published with Flash 11 using H264, I'm getting a "non monotonically increasing dts to muxer" error.

The command I'm running is: /usr/local/bin/ffmpeg -i rtmp://[server address]/[application]/myStream -acodec libfaac -vcodec copy -f flv test.flv

The same issue happens when running ffmpeg on the attached file which was recorded using wowza from the same Flash 11 application. Any idea what might be causing this issue and when there might be a fix available?

Console output below...

[root@domU-12-31-39-16-DD-83 test]# /usr/local/bin/ffmpeg -i rtmp://live.finalweb.net/94blbnunn/myStream -acodec libfaac -vcodec copy -f flv test.flv
ffmpeg version N-38999-g5ca595f Copyright (c) 2000-2012 the FFmpeg developers

built on Mar 21 2012 19:14:15 with gcc 4.4.5 20110214 (Red Hat 4.4.5-6)
configuration: --enable-version3 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfaac --enable-libmp3lame --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --disable-ffplay --enable-shared --enable-gpl --enable-postproc --enable-nonfree --enable-avfilter --enable-pthreads --extra-cflags=-fPIC
libavutil 51. 43.100 / 51. 43.100
libavcodec 54. 12.100 / 54. 12.100
libavformat 54. 2.100 / 54. 2.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 65.102 / 2. 65.102
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 7.100 / 0. 7.100
libpostproc 52. 0.100 / 52. 0.100

[flv @ 0x1ce63a0] Estimating duration from bitrate, this may be inaccurate
Input #0, flv, from 'rtmp://live.finalweb.net/94blbnunn/myStream':

Metadata:

description :

Duration: N/A, start: 0.000000, bitrate: 96 kb/s

Stream #0:0: Video: h264 (Baseline), yuv420p, 320x240 [SAR 1:1 DAR 4:3], 15 tbr, 1k tbn, 30 tbc
Stream #0:1: Audio: nellymoser, 44100 Hz, mono, s16, 96 kb/s

Output #0, flv, to 'test.flv':

Metadata:

description :
encoder : Lavf54.2.100
Stream #0:0: Video: h264 ([7][0][0][0] / 0x0007), yuv420p, 320x240 [SAR 1:1 DAR 4:3], q=2-31, 1k tbn, 1k tbc
Stream #0:1: Audio: aac ([10][0][0][0] / 0x000A), 44100 Hz, mono, s16, 128 kb/s

Stream mapping:

Stream #0:0 -> #0:0 (copy)
Stream #0:1 -> #0:1 (nellymoser -> libfaac)

Press [q] to stop, ? for help
[flv @ 0x1dab5a0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 226 >= 226
av_interleaved_write_frame(): Invalid argument

[Carl Eugen Hoyos]

Do you think this is a regression?

Is this only reproducible with rtmp://, or also if you use the source file as input?

[Jeremy]

I'm not sure if this is a regression or not, but it is reproducible with the attached source file as well as with rtmp://

[Carl Eugen Hoyos]

$ ffmpeg -i myStream_721267590_1_1.flv -vcodec copy -an out.mp4
ffmpeg version N-39200-gb222c28 Copyright (c) 2000-2012 the FFmpeg developers
  built on Mar 24 2012 08:09:50 with gcc 4.3.2
  configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl
  libavutil      51. 44.100 / 51. 44.100
  libavcodec     54. 12.100 / 54. 12.100
  libavformat    54.  2.100 / 54.  2.100
  libavdevice    53.  4.100 / 53.  4.100
  libavfilter     2. 65.102 /  2. 65.102
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0.  7.100 /  0.  7.100
  libpostproc    52.  0.100 / 52.  0.100
Input #0, flv, from 'myStream_721267590_1_1.flv':
  Metadata:
    creationdate    : Thu Mar 22 15:04:02
  Duration: 00:00:27.48, start: 0.000000, bitrate: 478 kb/s
    Stream #0:0: Video: h264 (Main), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 15.08 tbr, 1k tbn, 60 tbc
    Stream #0:1: Audio: nellymoser, 44100 Hz, mono, s16
Output #0, mp4, to 'out.mp4':
  Metadata:
    creationdate    : Thu Mar 22 15:04:02
    encoder         : Lavf54.2.100
    Stream #0:0: Video: h264 (![0][0][0] / 0x0021), yuv420p, 640x480 [SAR 1:1 DAR 4:3], q=2-31, 1k tbn, 1k tbc
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
Press [q] to stop, [?] for help
[mp4 @ 0x8ff30e0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 138 >= 138
av_interleaved_write_frame(): Invalid argument

[compn]

workaround: use rtmpdump project to record rtmp streams.

[Greeny]

Replying to compn:

workaround: use rtmpdump project to record rtmp streams.

Thought I'd just stop by in here and say that rtmpdump creates the same problem with live streams as you know via my ticket.

[Jeremy]

Just to be clear, the problem is that we want to transcode the audio on the stream and send it back out via another rtmp connection, and we'd like to use vcodec -copy to pass the video through. If we transcode the video with vcodec -libx264, it works, but with the number of streams we are handling at once this creates a CPU issue. As soon as we use vcodec -copy, ffmpeg throws the non-monotonically increasing error.

Given the needs as described here, I don't believe rtmpdump alone is enough to accomplish our goal since it doesn't transcode. Am I missing something?

Thanks...

[vestigal]

I had this same problem today. I managed to solve the issue by editing libavformat/flvenc.c and adding the AVFMT_TS_NONSTRICT flag to the AVOutputFormat struct.

I'm not sure if this has other ramifications but it seems to work for the time being.

[Carl Eugen Hoyos]

Replying to vestigal:

I had this same problem today. I managed to solve the issue by editing libavformat/flvenc.c and adding the AVFMT_TS_NONSTRICT flag to the AVOutputFormat struct.

I'm not sure if this has other ramifications

It ensures that your resulting file is not valid.

[vestigal]

Replying to cehoyos:

It ensures that your resulting file is not valid.

In mine and finalweb's situation (unless I missed something) there is no file involved. We're using a live rtmp source as input to ffmpeg, transcoding the audio, and publishing the remuxed stream over to another server. In my case the setup is:

Flash 11(H.264, Nellymoser)->FMS 3.5->FFMPEG(H.264, AAC)->Wowza

If I have time later I'll see what happens if the partially transcoded stream gets recorded.

[Jeremy]

I believe that if you try and bypass the issue that way, the stream won't play via flash either. Are you seeing a different result?

[vestigal]

Replying to finalweb:

I believe that if you try and bypass the issue that way, the stream won't play via flash either. Are you seeing a different result?

I'm seeing a completely playable stream via flash with my solution. More importantly for me, since the point of transcoding audio to AAC was for HLS, its playing back on my ios devices.

I guess its worth noting that simply adjusting the code in libavformat/utils.c:compute_pkt_fields2() to ignore the error didn't work for me. I had to leave that stuff as-is and instead mess with the flags like I previously noted.

In case it helps, here's my configuration:

ffmpeg version 0.10.2 Copyright (c) 2000-2012 the FFmpeg developers

built on Apr 3 2012 17:01:58 with gcc 4.1.2 20080704 (Red Hat 4.1.2-48)
configuration: --enable-gpl --enable-libfaac --enable-libmp3lame --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvorbis --enable-libx264 --enable-libxvid --enable-nonfree --enable-postproc --enable-version3 --enable-x11grab --enable-zlib --enable-shared --enable-libspeex --enable-librtmp
libavutil 51. 35.100 / 51. 35.100
libavcodec 53. 61.100 / 53. 61.100
libavformat 53. 32.100 / 53. 32.100
libavdevice 53. 4.100 / 53. 4.100
libavfilter 2. 61.100 / 2. 61.100
libswscale 2. 1.100 / 2. 1.100
libswresample 0. 6.100 / 0. 6.100
libpostproc 52. 0.100 / 52. 0.100

[Jeremy]

Looks like that works for the live stream, but once you try to record, you end up having sync issues with the recorded file, so that doesn't seem to completely resolve the issue.

[vestigal]

Replying to finalweb:

Looks like that works for the live stream, but once you try to record, you end up having sync issues with the recorded file, so that doesn't seem to completely resolve the issue.

I had audio/video syncing problems too, but not just with recorded streams I had them with the live transcoded stream also. My guess was that the sync problem was a result of transcoding audio; not because of the nonstrict timestamp flag.

I had some excellent results using the -copyts flag. Your result may vary.

I'm still curious why the AVFORMAT_TS_NONSTRICT flag isn't considered a good solution. My understanding of a monotonic function doesn't preclude two identical timestamps. Monotonically increasing, in my head, means that the timestamps never go backward.

[Carl Eugen Hoyos]

I believe this has been fixed.