Opened 5 years ago

Last modified 5 years ago

#7711 new defect

Segmenting with libopus produces incorrect segment durations in output playlist

Reported by: haywirez Owned by:
Priority: normal Component: ffmpeg
Version: unspecified Keywords: hls opus segment
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no


Fffmpeg should subtract or handle the OPUS priming samples duration (312 frames) from the segment duration in the playlist EXTINF: entries.

How to reproduce:

% ffmpeg -i xyz.wav -f segment -segment_time 1 -c:a libopus -segment_list opus-segment-test.m3u8 -segment_list_type m3u8 opus-segment-test_%03d.oga

produces a .m3u8 with:


Actual EXTINF segment duration in this case should reflect the true value: 0.9934920634920634, which corresponds to the difference made by the mentioned priming sample frames.

Tested with ffmpeg version 4.1
OS: macOS Mojave 10.14.1 Apple LLVM version 10.0.0 (clang-1000.11.45.5)

Change History (3)

comment:1 by Carl Eugen Hoyos, 5 years ago

Component: ffmpegundetermined
Keywords: segment m3u8 removed

Is the issue also reproducible with the native opus encoder?

comment:2 by haywirez, 5 years ago

Component: undeterminedffmpeg
Keywords: segment added

Yes. On further investigation, the segments produced are shorter than expected (at the tail), the difference corresponding to the duration of priming samples. To clarify, the #EXTINF:1.000000 should stay, just the produced file content length is wrong.

Last edited 5 years ago by haywirez (previous) (diff)

comment:3 by haywirez, 5 years ago

Can be confirmed by running the following conversion to wav, then converting individual wav segments and transcoding to opus. In that case, the durations are identical, but not in case of direct segmentation

% ffmpeg -i xyz.wav -f segment -segment_time 1 -segment_list opus-segment-test.m3u8 -segment_list_type m3u8 opus-segment-test_%03d.wav
Note: See TracTickets for help on using tickets.