[FFmpeg-trac] #11430(avformat:new): [Regression] Data stream in output may glitch "-stats" display since 7.0
FFmpeg
trac at avcodec.org
Fri Apr 11 10:13:52 EEST 2025
#11430: [Regression] Data stream in output may glitch "-stats" display since 7.0
-------------------------------------+-------------------------------------
Reporter: Denis | Owner: (none)
Filippov |
Type: defect | Status: new
Priority: normal | Component: avformat
Version: 7.0 | Resolution:
Keywords: mpegts | Blocked By:
scte_35 |
Blocking: | Reproduced by developer: 0
Analyzed by developer: 1 |
-------------------------------------+-------------------------------------
Comment (by Denis Filippov):
I could add the same case, but in other conditions. It more simplest for
detect problem in code.
Just generate file, that has 1 hour video and 10 seconds audio. I was show
PTS on video, that prove that PTS are present:
{{{
ffmpeg -f lavfi -i smptehdbars=size=1280x720:rate=25:duration=3600 -f
lavfi \
-i sine=frequency=1000:sample_rate=48000:duration=10 \
-vf
"drawtext=fontsize=40:text='PTS\:%{pts\:hms\:3}':x=(w-tw)/2:y=(h-lh)/2:fontcolor=white:box=1:boxcolor=0x00000000 at 1"
\
-pix_fmt yuv420p -c:v libx264 -preset superfast -c:a aac -f mp4 -y
dropped_audio.mp4
}}}
Next step, try to process this file by command:
{{{
ffmpeg -re -i dropped_audio.mp4 -c copy -f null -
}}}
As a result, the time stops at 10 seconds, and the speed starts to drop,
because it cannot be calculated because the PTS is missing in one of the
streams. But we can see that they are present in the video!
There is simply incorrect logic in the code when the data that is
available is not taken, but rather overwritten.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/11430#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list