Opened 8 months ago

Last modified 4 months ago

#10930 new defect

reencoding to x264 introduces playback stutter in Chrome

Reported by: diviaki Owned by:
Priority: normal Component: avcodec
Version: git-master Keywords: libx264
Cc: MasterQuestionable Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
Out of several videos one plays back with a weird jitter or stuttering in Chrome after I reencode it to x264. The original plays back normally.
Brave also affected, Safari, Firefox is not affected.
Happens in several ffmpeg versions across multiple platforms.

How to reproduce:

% ffmpeg -i source.mp4 -c:v libx264 re264.mp4
ffmpeg version N-68533-gcc774cd962-static arm64
built on 20240203

Attachments (3)

source-short.mp4 (1.3 MB ) - added by diviaki 8 months ago.
re264.mp4 (381.0 KB ) - added by diviaki 8 months ago.
screenrecord-chrome-on-macos.mov (1.4 MB ) - added by diviaki 4 months ago.
The issue is most noticeable on how the lips move so attaching a close-up screen recording on how Chrome on Macos plays back re263.mp4

Change History (8)

by diviaki, 8 months ago

Attachment: source-short.mp4 added

by diviaki, 8 months ago

Attachment: re264.mp4 added

comment:1 by diviaki, 8 months ago

The stutter intoduced propagated to a hls video converted from the bogus 264 video.

Other ffmpeg 264 encoders (h264_videotoolbox, libopenh264) does not suffer from this issue

comment:2 by Balling, 4 months ago

I cannot see any obvious stutter. The issue is with what? Her talking?

comment:3 by MasterQuestionable, 4 months ago

Cc: MasterQuestionable added
Version: unspecifiedgit-master

͏    Supposedly inconsistency between the output and source. (probably not apparently obvious)

by diviaki, 4 months ago

The issue is most noticeable on how the lips move so attaching a close-up screen recording on how Chrome on Macos plays back re263.mp4

comment:4 by diviaki, 4 months ago

Might relate that in the original, 30 minutes long video the sound slowly gets out of sync finishing about 3 seconds earlier when video ends.

comment:5 by MasterQuestionable, 4 months ago

͏    So it might mean the original has bad audio?
͏    No matter. Shouldn't be much relevant.
͏    (audio, video various streams can be each independent)

͏    At most it should mean the original was poorly produced. (therefore potentially broken)

͏    If such is the case, caution that FFmpeg currently may not handle non-perfectly-valid files in the most sensible way.
͏    E.g. https://trac.ffmpeg.org/ticket/11055

Note: See TracTickets for help on using tickets.