[FFmpeg-user] MPEG-TS CBR?

Fri Apr 13 15:40:56 CEST 2012

Oh, in case it's important, trying to encode with a grab of current HEAD yields an error:

ffmpeg.Darwin -i /mvl/test/16_9_DVD_Low.mpg   -c:v mpeg2video -pix_fmt yuv420p -ec +deblock -vf yadif -r 25 -s 720x576 -b:v 4000k -minrate:v 4000k -maxrate:v 4000k  -bufsize 1000k -g 12 -bf 2 -flags +cgop -flags2 sgop -sc_threshold 1000000000 -streamid:v 0:480 -streamid:a 1:481 -packetsize 188  -c:a mp2 -ar 48000 -b:a 192k -f mpegts -y /outgoing/KabelBW/test/16_9_HD.mpg_mpegts.mpg
ffmpeg version git-2011-09-16-0f692db Copyright (c) 2000-2012 the FFmpeg developers
  built on Apr 13 2012 15:23:06 with gcc 4.0.1 (Apple Inc. build 5493)
  configuration: --prefix=/Users/ak/sffmpeg/build --datadir=/Users/ak/sffmpeg/build/etc --arch=x86_64 --disable-shared --enable-static --enable-gpl --enable-version3 --enable-nonfree --disable-doc --disable-debug --disable-ffplay --disable-ffserver --disable-avdevice --disable-indevs --disable-outdevs --enable-runtime-cpudetect --enable-memalign-hack --extra-cflags=-I/Users/ak/sffmpeg/build/include --extra-cflags=--static --extra-cflags=-m64 --extra-ldflags=-L/Users/ak/sffmpeg/build/lib --extra-ldflags=-m64 --extra-ldflags=-arch --extra-ldflags=x86_64 --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libfaac --enable-libmp3lame --disable-libspeex --enable-libx264 --disable-libxvid --disable-librtmp
  libavutil      51. 46.100 / 51. 46.100
  libavcodec     54. 14.101 / 54. 14.101
  libavformat    54.  3.100 / 54.  3.100
  libavfilter     2. 67.101 /  2. 67.101
  libswscale      2.  1.100 /  2.  1.100
  libswresample   0. 11.100 /  0. 11.100
  libpostproc    52.  0.100 / 52.  0.100
[mpeg @ 0x10180a220] max_analyze_duration 5000000 reached at 5000000
Input #0, mpeg, from '/mvl/test/16_9_DVD_Low.mpg':
  Duration: 00:00:20.18, start: 0.193189, bitrate: 4550 kb/s
    Stream #0:0[0x1e0]: Video: mpeg2video (Main), yuv420p, 720x576 [SAR 64:45 DAR 16:9], 8500 kb/s, 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x1c0]: Audio: mp2, 48000 Hz, stereo, s16, 224 kb/s
[buffer @ 0x101100fe0] w:720 h:576 pixfmt:yuv420p tb:1/1000000 sar:64/45 sws_param:flags=2
[yadif @ 0x1011025c0] mode:0 parity:-1 auto_enable:0
[mpegts @ 0x101815e20] muxrate VBR, pcr every 2 pkts, sdt every 200, pat/pmt every 40 pkts
Output #0, mpegts, to '/outgoing/KabelBW/test/16_9_HD.mpg_mpegts.mpg':
  Metadata:
    encoder         : Lavf54.3.100
    Stream #0:0: Video: mpeg2video, yuv420p, 720x576 [SAR 64:45 DAR 16:9], q=2-31, 4000 kb/s, 90k tbn, 25 tbc
    Stream #0:1: Audio: mp2, 48000 Hz, stereo, s16, 192 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (mpeg2video -> mpeg2video)
  Stream #0:1 -> #0:1 (mp2 -> mp2)
Press [q] to stop, [?] for help
[mpegts @ 0x101815e20] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 14400 >= 14400
av_interleaved_write_frame(): Invalid argument

Cheers, Anjo

Am 13.04.2012 um 14:28 schrieb Anjo Krank:

> So I got some more info on the rejected CBR TS. Checking the generated streams with "crosscheck" yields a long list of errors:
> 
> http://www.krank.net/report.txt
> 
> The problem seems to the in fact the muxer, as de- and remuxing with a different muxer yielded no more errors.
> 
> How "usable" or "broadcast-ready" is the muxing in ffmpeg? Searching the web and other comments seemed to say that there is no actually working open-source muxer out there… at least in the sense that it could create broadcast-ready files. Is that true?
> 
> I also found a discussion about some patches that were written in the Google SOC 2009 which seemed to end in abandonment. Was that stuff actually working or better than the current implementation? Would it be worth the bother to clean it up and try to commit it?
> 
> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/52773/focus=56011
> 
> Cheers, Anjo
> 
> Am 04.04.2012 um 09:43 schrieb Anjo Krank:
> 
>> 
>> Am 03.04.2012 um 20:28 schrieb Michael Niedermayer:
>> 
>>>> It's the tiny white line at the left, where throughput drops to 3.5m. The resulting movie files looks totally normal at this location. From mucho googling I had the impression that it could maybe be a wrong setting for the  -bufsize 1000k. Is this on any way calculable or are they simply a bunch of legal settings?
>>> 
>>> there are simply a bunch of legal settings, try a smaller bufsize and
>>> see if this fixes the issue
>> 
>> Can you tell me where to find those legal settings? Are they dependent on the target (TV vs DVD)? I searched high and low on google but found only very contradictory info, which is why I came up with the bufsize=bandwidth/4 scheme in the first place...
>> 
>> Cheers, Anjo
>> _______________________________________________
>> ffmpeg-user mailing list
>> ffmpeg-user at ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user