[FFmpeg-trac] #7403(avformat:reopened): HLS Master Playlist fails being generated correctly
FFmpeg
trac at avcodec.org
Wed Aug 2 20:13:49 EEST 2023
#7403: HLS Master Playlist fails being generated correctly
------------------------------------+------------------------------------
Reporter: barhom | Owner: (none)
Type: defect | Status: reopened
Priority: minor | Component: avformat
Version: git-master | Resolution:
Keywords: hls | Blocked By:
Blocking: | Reproduced by developer: 1
Analyzed by developer: 0 |
------------------------------------+------------------------------------
Comment (by alexey.rodionov):
It's definitely a bug. And here's why:
I'm working on a service that takes a video file as input and generates
HLS streams in various resolutions as output (like YouTube does).
If the input file has no audio, running the following command:
{{{
ffmpeg -i input.mp4 -map 0:v:0 -map 0:v:0 -map 0:v:0 -map 0:v:0
-filter:v:0 scale=-2:360 -filter:v:1 scale=-2:480 -filter:v:2 scale=-2:720
-filter:v:3 scale=-2:1080 -f hls -hls_playlist_type vod -hls_flags
independent_segments -master_pl_name master.m3u8 -hls_segment_filename
stream_%v/chunk_%08d.ts -strftime_mkdir 1 -var_stream_map "v:0,name:360p
v:1,name:480p v:2,name:720p v:3,name:1080p" stream_%v.m3u8
}}}
causes the following warning(s):
{{{
Bandwidth info not available, set audio and video bitrates
Last message repeated 3 times
}}}
and produce the following broken HLS master playlist:
{{{
#EXTM3U
#EXT-X-VERSION:6
}}}
This can be fixed by specifying the bitrate explicitly, e.g. `-b:v:0 1000k
-b:v:1 2000k -b:v:2 4000k -b:v:3 6000k`.
But I don't want to explicitly specify the video bitrate for each stream.
I want to use ffmpeg's default values. By the way, I don't know the
ffmpeg's default values for various resolutions. Moreover, to get a high-
quality output video, I need to consider not only the resolution, but also
the frame rate. E.g., a video with 60 fps needs a higher bitrate than a
video with the same resolution but 30 fps. And the problem is that I don't
know the frame rate of the input video that the user can upload.
The interesting thing is that there is another way to create an HLS
streams using `dash` muxer with `-hls_playlist true` option:
{{{
ffmpeg -i input.mp4 -map 0:v:0 -map 0:v:0 -map 0:v:0 -map 0:v:0
-filter:v:0 scale=-2:360 -filter:v:1 scale=-2:480 -filter:v:2 scale=-2:720
-filter:v:3 scale=-2:1080 -use_template 1 -use_timeline 1 -adaptation_sets
"id=0,streams=v" -f dash -hls_playlist true manifest.mpd
}}}
This also causes the following warning(s):
{{{
[dash @ 000001fe89d20cc0] No bit rate set for stream 0
[dash @ 000001fe89d20cc0] No bit rate set for stream 1
[dash @ 000001fe89d20cc0] No bit rate set for stream 2
[dash @ 000001fe89d20cc0] No bit rate set for stream 3
}}}
but produce the following correct `master.m3u8` HLS master playlist
(alongside `manifest.mpd` DASH master playlist):
{{{
#EXTM3U
#EXT-X-VERSION:7
#EXT-X-STREAM-INF:BANDWIDTH=987359,RESOLUTION=640x360,CODECS="avc1.64001f"
media_0.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=1504372,RESOLUTION=854x480,CODECS="avc1.64001f"
media_1.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=2787800,RESOLUTION=1280x720,CODECS="avc1.640020"
media_2.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=5181173,RESOLUTION=1920x1080,CODECS="avc1.64002a"
media_3.m3u8
}}}
This means that ffmpeg actually has all the info about video bitrate it
needs and that this is definitely a bug in `hls` muxer that expects the
user to specify the bitrate explicitly.
Moreover, if the `hls` muxer is used, but the input video file has audio,
running the following command:
{{{
ffmpeg -i input.mp4 -map 0:v:0 -map 0:v:0 -map 0:v:0 -map 0:v:0 -map 0:a:0
-filter:v:0 scale=-2:360 -filter:v:1 scale=-2:480 -filter:v:2 scale=-2:720
-filter:v:3 scale=-2:1080 -f hls -hls_playlist_type vod -hls_flags
independent_segments -master_pl_name master.m3u8 -hls_segment_filename
stream_%v/chunk_%08d.ts -strftime_mkdir 1 -var_stream_map
"v:0,name:360p,agroup:audio v:1,name:480p,agroup:audio
v:2,name:720p,agroup:audio v:3,name:1080p,agroup:audio
a:0,name:audio,agroup:audio" stream_%v.m3u8
}}}
doesn't cause any warnings and produce the following master playlist:
{{{
#EXTM3U
#EXT-X-VERSION:6
#EXT-X-MEDIA:TYPE=AUDIO,GROUP-
ID="group_audio",NAME="audio_4",DEFAULT=YES,URI="stream_audio.m3u8"
#EXT-X-STREAM-
INF:BANDWIDTH=140800,RESOLUTION=640x360,CODECS="avc1.64001f,mp4a.40.2",AUDIO="group_audio"
stream_360p.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=140800,RESOLUTION=854x480,CODECS="avc1.64001f,mp4a.40.2",AUDIO="group_audio"
stream_480p.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=140800,RESOLUTION=1280x720,CODECS="avc1.640020,mp4a.40.2",AUDIO="group_audio"
stream_720p.m3u8
#EXT-X-STREAM-
INF:BANDWIDTH=140800,RESOLUTION=1920x1080,CODECS="avc1.64002a,mp4a.40.2",AUDIO="group_audio"
stream_1080p.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=140800,CODECS="mp4a.40.2",AUDIO="group_audio"
stream_audio.m3u8
}}}
But all video streams have the same bandwidth as the audio stream that is
obviously incorrect.
--
Ticket URL: <https://trac.ffmpeg.org/ticket/7403#comment:13>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker
More information about the FFmpeg-trac
mailing list