[FFmpeg-trac] #11622(undetermined:new): Low bitrate data PID in MPEGTS disrupts live output rate
FFmpeg
trac at avcodec.org
Tue Jun 3 17:54:55 EEST 2025
#11622: Low bitrate data PID in MPEGTS disrupts live output rate
-------------------------------------+-------------------------------------
Reporter: Thierry | Type: defect
Lelegard |
Status: new | Priority: normal
Component: | Version: 7.1
undetermined |
Keywords: | Blocked By:
Blocking: | Reproduced by developer: 0
Analyzed by developer: 0 |
-------------------------------------+-------------------------------------
During live transcoding of MPEG transport stream, when a data PID has rare
packets, the output bitrate suddenly doubles when an input data packet is
found. Then, the output bitrate drops to zero (to compensate the previous
burst) and then stabilizes again, until the next data packet.
Impact: When ffmpeg is used as part of a live transmission chain, the
playback is broken on all clients.
== ffmpeg version
{{{
ffmpeg version 7.1.1 Copyright (c) 2000-2025 the FFmpeg developers
built with Apple clang version 17.0.0 (clang-1700.0.13.3)
configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/7.1.1_3 --enable-
shared --enable-pthreads --enable-version3 --cc=clang --host-c\
flags= --host-ldflags='-Wl,-ld_classic' --enable-ffplay --enable-gnutls
--enable-gpl --enable-libaom --enable-libaribb24 --enable-l\
ibbluray --enable-libdav1d --enable-libharfbuzz --enable-libjxl --enable-
libmp3lame --enable-libopus --enable-librav1e --enable-lib\
rist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-
libssh --enable-libsvtav1 --enable-libtesseract --enable-li\
btheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-
libvpx --enable-libwebp --enable-libx264 --enable-libx265 \
--enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig
--enable-libfreetype --enable-frei0r --enable-libass --enabl\
e-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg
--enable-libspeex --enable-libsoxr --enable-libzmq --enable-lib\
zimg --disable-libjack --disable-indev=jack --enable-videotoolbox
--enable-audiotoolbox --enable-neon
libavutil 59. 39.100 / 59. 39.100
libavcodec 61. 19.101 / 61. 19.101
libavformat 61. 7.100 / 61. 7.100
libavdevice 61. 3.100 / 61. 3.100
libavfilter 10. 4.100 / 10. 4.100
libswscale 8. 3.100 / 8. 3.100
libswresample 5. 3.100 / 5. 3.100
libpostproc 58. 3.100 / 58. 3.100
}}}
== Reproducer materials
Files are available at https://tsduck.io/test/ffmpeg-issue/
Input transport stream is file [https://tsduck.io/test/ffmpeg-issue
/ffmpeg-input-2.ts ffmpeg-input-2.ts]. The global bitrate is 50 Mb/s.
There is one video and one audio PID.
There is also one PES data PID with rare packets, only 8 TS packets in
that PID out of 450k packets in the TS. The TS packets in the data PID
contains PCR and PTS values. The analysis shows that these PCR and PTS are
synchronous with the surrounding video and audio packets (see file
[https://tsduck.io/test/ffmpeg-issue/ffmpeg-input-2.pcr-pts-dts.csv
ffmpeg-input-2.pcr-pts-dts.csv]).
Analysis files of the input TS are available from ffprobe
([https://tsduck.io/test/ffmpeg-issue/ffmpeg-input-2.ffprobe.txt ffmpeg-
input-2.ffprobe.txt]) and tsanalyze, part of the TSDuck toolset
([https://tsduck.io/test/ffmpeg-issue/ffmpeg-input-2.tsanalyze.txt ffmpeg-
input-2.tsanalyze.txt]).
The tests use TSDuck to play the file into ffmpeg and to monitor the
packets in the data PID as well as the global bitrate. See
https://tsduck.io/ and https://github.com/tsduck/tsduck to get TSDuck.
== First test: Demonstrate the problem
Test script: [https://tsduck.io/test/ffmpeg-issue/test-ffmpeg-2.sh test-
ffmpeg-2.sh]
Output: [https://tsduck.io/test/ffmpeg-issue/test-ffmpeg-2.log test-
ffmpeg-2.log]
The input TS file is played at its native speed, approximately 50 Mb/s.
The complete play time is approximately one minute.
Using tsp plugins, part of TSDuck, the input data packets (PID 6000) are
traced and the global bitrate is displayed once per second (tag "before-
ffmpeg").
The output of tsp is piped into ffmpeg. All codecs are set to "copy".
However, for some reason, the AES3 PCM audio is transcoded to mp2
(mp3float) audio, reducing the global bitrate by 2 Mb/s. The data PID uses
"-map 0:d -c:d copy".
The full ffmpeg command is:
{{{
ffmpeg -loglevel error -copyts \
-f mpegts -i - \
-map 0:d -c:d copy \
-map 0:v -c:v copy \
-map 0:a -c:v copy \
-mpegts_start_pid 100 \
-f mpegts -
}}}
The output of ffmpeg is piped into another tsp where the output data
packets (PID 100) are traced and the global bitrate is displayed once per
second (tag "after-ffmpeg").
The ffmpeg input bitrate remains steady all along the test, around 50.6
Mb/s. The ffmpeg output bitrate is initially stable around 48 Mb/s (due to
audio transcoding from PCM to MP2).
However, each time a data packet arrives, the ffmpeg output bitrate
suddenly doubles around 120 Mb/s, then drop to zero (because ffmpeg is
probably starving, waiting for input) and then stabilizes again around 48
Mb/s.
Note that there is a huge latency of 10 seconds between the first input
packet in ffmpeg and its first output packet. Therefore, there are enough
data in the ffmpeg buffer to feed the output burst.
== Second test: The problem disappears when the data PID is removed
Test script: [https://tsduck.io/test/ffmpeg-issue/test-ffmpeg-3.sh test-
ffmpeg-3.sh]
Output: [https://tsduck.io/test/ffmpeg-issue/test-ffmpeg-3.log test-
ffmpeg-3.log]
The second test is identical to the first one with one exception: the data
PID is removed from the TS before going into ffmpeg ("-P filter -n -p
6000").
This time, we see that the ffmpeg output bitrate remains steady all the
time, demonstrating that the problem is created by the data packets.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11622>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list