Opened 3 years ago

Closed 17 months ago

#10786 closed enhancement (fixed)

CODECS for HLS mux hard coded to 4

Reported by: David Johansen Owned by: Jack Lau
Priority: normal Component: avformat
Version: git-master Keywords: HLS
Cc: David Johansen, Jack Lau Blocked By:
Blocking: Reproduced by developer: yes
Analyzed by developer: yes

Description

Summary of the bug:
How to reproduce:

ffmpeg -i test.mp4 -c:v copy -c:a copy -map v:0 -map a:0 -tag:v hvc1 -master_pl_name index.m3u8 -f hls "%v/index.m3u8"
6.1.1
Built on macOS with homebrew

The tier is hard coded to 4 and I'd be glad to submit a patch to fix this, but need some guidance on where the value should be pulled from:
https://git.ffmpeg.org/gitweb/ffmpeg.git/blob/e38092ef9395d7049f871ef4d5411eb410e283e0:/libavformat/hlsenc.c#l413

Change History (11)

comment:1 by David Johansen, 3 years ago

The problem is actually the B01 on the end of CODECS and I'm guessing that needs to be made dynamic instead of being hard coded

Here's the issues it's causing with playback in Chrome:
https://github.com/videojs/video.js/issues/8549
https://github.com/video-dev/hls.js/issues/6086

comment:2 by David Johansen, 2 years ago

It appears that the logic is in section 5.2.1 of this document:
https://www.etsi.org/deliver/etsi_ts/103200_103299/103285/01.01.01_60/ts_103285v010101p.pdf

comment:3 by Jack Lau, 18 months ago

Is this still a problem?
I test it on newer chrome and didn't meet this error.

comment:4 by Balling, 18 months ago

I test it on newer chrome and didn't meet this error.

It is not an issue in Chrome, but in Video.js javascript library...

" ffmpeg has part of CODECS hard coded to 4 and B01 on the end. "

Was that fixed?

Last edited 18 months ago by Balling (previous) (diff)

in reply to:  4 comment:5 by Jack Lau, 17 months ago

Replying to Balling:

I test it on newer chrome and didn't meet this error.

It is not an issue in Chrome, but in Video.js javascript library...

" ffmpeg has part of CODECS hard coded to 4 and B01 on the end. "

Was that fixed?

https://ffmpeg.org/pipermail/ffmpeg-devel/2025-March/340524.html
or
https://patchwork.ffmpeg.org/project/ffmpeg/patch/tencent_886E16976F6A0C014A440BEF65EEA4694405@qq.com/
Please check if this patch is useful?

Last edited 17 months ago by Jack Lau (previous) (diff)

comment:6 by Jack Lau, 17 months ago

Analyzed by developer: set
Cc: Jack Lau added
Owner: set to Jack Lau
Priority: importantnormal
Reproduced by developer: set
Status: newopen
Type: defectenhancement
Version: 6.1git-master

comment:7 by Jack Lau, 17 months ago

I tested many cases, and found the reason of this bug.

Refer to ISO/IEC14496-15, CONSTRAINTS(like b0.1 or 90.0) is a hexadecimal representation of the general_constraint_indicator_flags. And each byte is separated by a '.', and trailing zero bytes may be omitted. (I write this descriptions in my patch)

So the hard code(B01) is not the only problem, the main problem is that "B01" does not conform to the correct syntax, the correct syntax should be "B0.1"

Of course, i test that video with coded "b0.1", it can played well in hls.js.

you can test the video (coded "b0.1")"https://raw.githubusercontent.com/JackLau1222/hls_test/refs/heads/main/master_videotoolbox_test.m3u8" using hls.js, and you'll see it works well

I tested this patch on my computer and it worked fine, so please let me know if this patch solves your problem or if there is something else wrong
thx

Last edited 17 months ago by Jack Lau (previous) (diff)

comment:8 by Balling, 17 months ago

"So the hard code(B01) is not the only problem, the main problem is that "B01" does not conform to the correct syntax, the correct syntax should be "B0.1""

Wow, you are right.

comment:9 by Balling, 17 months ago

Would be nice to fix #10775 and #11316 while at it.

comment:10 by Steven Liu, 17 months ago

Great job,
Thanks Jack Lau

fix by commit: 1502551dd363b3651a0e41f981f47657a8d29f82

comment:11 by Jack Lau, 17 months ago

Resolution: fixed
Status: openclosed
Note: See TracTickets for help on using tickets.