Opened 3 months ago

Last modified 7 weeks 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 Changed 3 months ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Keywords segment m3u8 removed

Is the issue also reproducible with the native opus encoder?

comment:2 Changed 7 weeks ago by haywirez

  • Component changed from undetermined to ffmpeg
  • 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 7 weeks ago by haywirez (previous) (diff)

comment:3 Changed 7 weeks ago by haywirez

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.