>>>>>> I have read this patch some problem for this patch. >>>>>> >>>>>> 1. maybe there will have a problem when duration is not same when every >>>>>> fragment, for example: >>>>>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i >>>>>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls >>>>>> -hls_list_size 0 output_test.m3u8 >>>>>> liuqideMacBook-Pro:xxx liuqi$ head -n 10 output_test.m3u8 >>>>>> #EXTM3U >>>>>> #EXT-X-VERSION:3 >>>>>> #EXT-X-TARGETDURATION:8 >>>>>> #EXT-X-MEDIA-SEQUENCE:0 >>>>>> #EXTINF:3.866667, >>>>>> output_test0.ts >>>>>> #EXTINF:7.300000, >>>>>> output_test1.ts >>>>>> #EXTINF:8.333333, >>>>>> output_test2.ts >>>>>> >>>>>> the output_test0.ts’s duration is short than output_test1.ts, the >>>>>> #EXT-X-TARGETDURATION need update to the longest duration. >>>>>> this operation (check the longest duration) will happen at every >>>>>> fragment write complete. >>>>>> it will not update when move the update option to the hls_write_header, >>>>>> >>>>> >>>>> This is a problem in the code that splits the mpegts files. I've filed a >>>>> separate issue for this here: https://trac.ffmpeg.org/ticket/7341. Mpegts >>>>> segmentation should be following the hls_time parameter (or the default >>>>> length). >>>> This is whatever hls_time, is decide by keyframe position, this is happen >>>> when GOP size is not a permanent t position. >>>> > >>>>> This is happening now with fMP4 assets, but not with mpegts. >>>> Whatever fmp4 or mpegts, all of them need fix the problem of duration >>>> refresh. >>>> >>>> for example: >>>> >>>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss -v quiet -i >>>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls >>>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8 >>>> liuqideMacBook-Pro:xxx liuqi$ head -n 10 output_test.m3u8 >>>> #EXTM3U >>>> #EXT-X-VERSION:7 >>>> #EXT-X-TARGETDURATION:8 >>>> #EXT-X-MEDIA-SEQUENCE:0 >>>> #EXT-X-MAP:URI="init.mp4" >>>> #EXTINF:3.866667, >>>> output_test0.m4s >>>> #EXTINF:7.300000, >>>> output_test1.m4s >>>> #EXTINF:8.333333, >>>> liuqideMacBook-Pro:xxx liuqi$ >>> >>> This is after your patch: >>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -ss 17 -v quiet -i >>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls >>> -hls_list_size 0 -hls_segment_type fmp4 -hls_time 3 output_test.m3u8 >>> liuqideMacBook-Pro:xxx liuqi$ head -n 10 output_test.m3u8 >>> #EXTM3U >>> #EXT-X-VERSION:7 >>> #EXT-X-TARGETDURATION:3 >>> #EXT-X-MEDIA-SEQUENCE:0 >>> #EXT-X-MAP:URI="init.mp4" >>> #EXTINF:3.866667, >>> output_test0.m4s >>> #EXTINF:7.300000, >>> output_test1.m4s >>> #EXTINF:8.333333, >>> >>> The RFC https://www.rfc-editor.org/rfc/rfc8216.txt describe: >>> >>> 4.3.3.1. EXT-X-TARGETDURATION >>> >>> The EXT-X-TARGETDURATION tag specifies the maximum Media Segment >>> duration. The EXTINF duration of each Media Segment in the Playlist >>> file, when rounded to the nearest integer, MUST be less than or equal >>> to the target duration; longer segments can trigger playback stalls >>> or other errors. It applies to the entire Playlist file. Its format >>> is: >>> >>> #EXT-X-TARGETDURATION:<s> >>> >>> where s is a decimal-integer indicating the target duration in >>> seconds. The EXT-X-TARGETDURATION tag is REQUIRED. >>> >>> your patch make the EXT-X-TARGETDURATION less than EXTINF:7.300000 >>> EXTINF:8.333333 >> >> >>>>>> 2. the version maybe will update when use hls_segment_type or >>>>>> append_list etc. when the operation is support from different version >>>>>> m3u8. >>>>> >>>>> I don't follow what you mean here. The version number is known up front, >>>>> based on the options that were passed in. It should be illegal to switch >>>>> between versions when trying to update an existing manifest. When can >>>>> this legitimately happen? >>>> there maybe have some player cannot support high version of m3u8, for >>>> example old parser or player just support the VERSION 3, >>>> this must think about all of the player or parser, because ffmpeg is not >>>> used only by myself. >>>> >>>> Or what about get the #EXT-X-VERSION position, to update it? looks like >>>> flvenc.c or movenc.c date shift >>>> >>>>> >>>>>> 3. need update segments vs->segments when hls_list_size option is set. >>>>>> >>>>> >>>>> What do you mean by this and where should I do it? >>>> for example, hls_list_size is 4, the m3u8 list should refresh every time >>>> when make a new fragment. >>>> >>>> first time: >>>> 1.m4s >>>> 2.m4s >>>> 3.m4s >>>> 4.m4s >>>> >>>> sencond time: >>>> 2.m4s >>>> 3.m4s >>>> 4.m4s >>>> 5.m4s >>> >>> after your patch: >>> >>> liuqideMacBook-Pro:xxx liuqi$ ./ffmpeg -v quiet -i >>> ~/Movies/Test/bbb_sunflower_1080p_30fps_normal.mp4 -c copy -f hls >>> -hls_list_size 4 -hls_segment_type fmp4 -hls_time 3 -t 50 output_test.m3u8 >>> liuqideMacBook-Pro:xxx liuqi$ cat output_test.m3u8 >>> #EXTM3U >>> #EXT-X-VERSION:7 >>> #EXT-X-TARGETDURATION:3 >>> #EXT-X-MEDIA-SEQUENCE:0 >>> #EXT-X-MAP:URI="init.mp4" >>> #EXTINF:3.866667, >>> output_test0.m4s >>> #EXTINF:7.300000, >>> output_test1.m4s >>> #EXTINF:8.333333, >>> output_test2.m4s >>> #EXTINF:3.966667, >>> output_test3.m4s >>> #EXTINF:8.333333, >>> output_test4.m4s >>> #EXTINF:4.033333, >>> output_test5.m4s >>> #EXTINF:8.333333, >>> output_test6.m4s >>> #EXTINF:4.633333, >>> output_test7.m4s >>> liuqideMacBook-Pro:xxx liuqi$ >>> liuqideMacBook-Pro:xxx liuqi$ >>> >>> the m3u8 list is incorrect, because users want control the m3u8 list >>> length, because their disk do not have enough space to save the fragments. >>> >> >> Ok I will fix this.
I'm attaching a new patch that resolves all of these issues, while still resolving this bug for VOD playlists. Can you please review?
0001-libavformat-hlsenc-Fix-HLS-Manifest-Generation-from-.patch
Description: Binary data
Thanks, Ronak
_______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
