[FFmpeg-devel] First Patch for hlsenc.c for https://trac.ffmpeg.org/ticket/7281

[Ronak]

>>>>>> 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?


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-libavformat-hlsenc-Fix-HLS-Manifest-Generation-from-.patch
Type: application/octet-stream
Size: 7322 bytes
Desc: not available
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20180803/ed764a77/attachment.obj>
-------------- next part --------------


Thanks,

Ronak