https://bugs.kde.org/show_bug.cgi?id=526029
Bug ID: 526029
Summary: First frame is never painted on low-frame-rate videos;
picture only appears after seeking
Classification: Applications
Product: dragonplayer
Version First 26.08.1
Reported In:
Platform: Fedora RPMs
OS: Linux
Status: REPORTED
Severity: normal
Priority: NOR
Component: general
Assignee: [email protected]
Reporter: [email protected]
CC: [email protected], [email protected]
Target Milestone: ---
Created attachment 196418
--> https://bugs.kde.org/attachment.cgi?id=196418&action=edit
packet/frame dump plus the clean decode check
DESCRIPTION
On videos with a very low frame rate and only a single sync sample, Dragon
Player plays the audio but never paints the picture - the window stays blank.
Dragging the position slider in either direction makes the image appear at
once, and it stays visible for the rest of playback.
The file is a valid, error-free H.264/AAC MP4: it decodes cleanly end to end
under ffmpeg (exit 0, no warnings) and renders immediately in mpv and VLC on
the same machine. Only Dragon Player fails to show it.
Its distinguishing property is the video track structure: 720x1280 H.264 High
at exactly 1 fps, 20 frames over 20 seconds, with sample 1 as the only entry in
the stss table. Nearly all the payload is in that first keyframe (414,357
bytes); the other 19 frames are ~85-byte P-frames encoding no visible change.
The renderer therefore receives exactly one buffer with real content, at t=0,
and the next arrives a full second later carrying nothing new.
This looks like the pre-roll frame being handed to the video sink before the
surface is realized, so the paint is lost. At 25-30 fps the next buffer arrives
33-40 ms later and the loss is invisible; at 1 fps there is no second chance
for a whole second, and the later frames have no change to force a repaint.
Seeking flushes the decoder and re-decodes the lone keyframe, and that fresh
buffer is the one that finally gets painted - matching the workaround exactly.
The file is not an exotic hand-made file. Downloaders for photo-plus-audio
social posts routinely emit this structure (a still image held for the length
of an audio track), so ordinary users reach it with ordinary files.
STEPS TO REPRODUCE
1. Open the attached repro-1fps-singlekeyframe.mp4 in Dragon Player. (To build
one:
`ffmpeg -f lavfi -i "color=c=0x1e3a5f:s=720x1280:d=20" -f lavfi -i
"sine=frequency=440:duration=20" -c:v libx264 -crf 23 -pix_fmt yuv420p -r 1 -g
1000 -keyint_min 1000 -sc_threshold 0 -c:a aac -shortest out.mp4`)
2. Let it play from the beginning without touching any control.
3. After a few seconds, drag the position slider backwards slightly.
OBSERVED RESULT
Through step 2 the video area stays blank while audio plays and the slider
advances normally. At step 3 the picture appears immediately and remains
visible.
EXPECTED RESULT
The picture appears as soon as playback starts — as it does in mpv and VLC with
the same file, and as it does in Dragon Player with the attached
control-30fps.mp4 (identical content at 30 fps with keyframes every 2 s).
SOFTWARE/OS VERSIONS
Operating System: **FILL IN**
KDE Plasma Version: **FILL IN**
KDE Frameworks Version: **FILL IN**
Qt Version: **FILL IN**
Dragon Player version: **FILL IN**
Phonon backend in use: **FILL IN**
ADDITIONAL INFORMATION
Analysis of the original affected file (attached as ffprobe-analysis.txt):
- MP4, isom/iso2/avc1/mp41, 563,220 bytes, 20.13 s; video h264 [email protected]
720x1280 yuv420p
r_frame_rate 1/1, 20 frames; audio HE-AAC 44100 Hz stereo
- Video stts: one entry (sample_count=20, sample_delta=16384) at timescale
16384 — exactly
1.000 s per frame, no irregular timing
- Video stss: [1] — the only sync sample in the track
- Video packet sizes: 414357 (keyframe), then 106, 88, 76, 77, 81, 80, 85, 81,
89, 86, 86,
88, 83, 86, 86, 84, 83, 90, 86
- Video edit list: one entry, duration 20000, media_time 0, rate 1 — no offset
that could
explain a delayed start. Audio elst has the ordinary AAC encoder-delay trim
(media_time 5058). start_time is 0.000000 on both streams.
- `ffmpeg -i <file> -f null -` completes with exit 0 and no warnings
User-side workaround: re-encode to a normal frame rate with periodic keyframes
-
`ffmpeg -i in.mp4 -c:v libx264 -crf 22 -pix_fmt yuv420p -r 30 -g 60
-sc_threshold 0 -tune stillimage -c:a aac -b:a 128k -movflags +faststart
out.mp4`
--
You are receiving this mail because:
You are watching all bug changes.
