Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

[Ronak Patel]

> On Dec 17, 2018, at 9:58 AM, Steven Liu  wrote:
> 
> 
> 
>>> On Dec 17, 2018, at 21:07, Ronak Patel  
>>> wrote:
>>> 
>>> 
>>> On Dec 13, 2018, at 9:15 PM, Ronak Patel 
>>>  wrote:
>>> 
>>> 
>>> 
>>>> On Dec 12, 2018, at 2:46 AM, Liu Steven  wrote:
>>>> 
>>>> 
>>>> 
>>>>>> 在 2018年12月12日，上午5:08，Ronak  写道：
>>>>>> 
>>>>>> 
>>>>>> On Dec 11, 2018, at 3:28 PM, Gyan  wrote:
>>>>>> 
>>>>>> 
>>>>>>> On 12-12-2018 01:13 AM, Ronak wrote:
>>>>>>> 
>>>>>>> Looks like I found out why: 
>>>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L790. 
>>>>>>> The hlsenc.c file overwrites whatever I pass in the command line...
>>>>>> 
>>>>>> That is a bug but there's still an error in your command. It should be,
>>>>>> 
>>>>>> 
>>>>>> -hls_ts_options movflags=+skip_sidx
>>>>>> 
>>>>>> This is because mp4 is a child muxer in this context. That hls option 
>>>>>> should be renamed.
>>>>>> 
>>>>>> Line 790 should be patched by adding + before frag_custom
>>>>> 
>>>>> That doesn't work.
>>>>> 
>>>>> ffmpeg -i input.mp4 -hls_ts_options movflags=+skip_sidx -codec copy 
>>>>> -hls_time 0.97523809523809 -hls_segment_type fmp4 -hls_flags single_file 
>>>>> -hls_playlist_type vod output.m3u8
>>>>> ffmpeg version N-92677-gdd7d6034f1 Copyright (c) 2000-2018 the FFmpeg 
>>>>> developers
>>>>> built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
>>>>> configuration: --prefix=/home/ronakp/ffmpeg_build 
>>>>> --pkg-config-flags=--static 
>>>>> --extra-cflags=-I/home/ronakp/ffmpeg_build/include 
>>>>> --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
>>>>> --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl 
>>>>> --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-nonfree
>>>>> libavutil  56. 24.101 / 56. 24.101
>>>>> libavcodec 58. 42.100 / 58. 42.100
>>>>> libavformat58. 24.100 / 58. 24.100
>>>>> libavdevice58.  6.101 / 58.  6.101
>>>>> libavfilter 7. 46.101 /  7. 46.101
>>>>> libswscale  5.  4.100 /  5.  4.100
>>>>> libswresample   3.  4.100 /  3.  4.100
>>>>> libpostproc55.  4.100 / 55.  4.100
>>>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
>>>>> Metadata:
>>>>> major_brand : isom
>>>>> minor_version   : 1
>>>>> compatible_brands: isom
>>>>> creation_time   : 2013-11-14T18:23:26.00Z
>>>>> Duration: 02:39:09.39, start: 0.00, bitrate: 31 kb/s
>>>>> Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 22050 Hz, mono, 
>>>>> fltp, 30 kb/s (default)
>>>>> Metadata:
>>>>>  creation_time   : 2013-11-14T18:23:26.00Z
>>>>>  handler_name: GPAC ISO Audio Handler
>>>>> [hls @ 0x23e1b00] Opening 'output.m4s' for writing
>>>>> [hls @ 0x23e1b00] Some of provided format options in 
>>>>> 'movflags=+skip_sidx' are not recognized
>>>>> Could not write header for output file #0 (incorrect codec parameters ?): 
>>>>> Invalid argument
>>>>> Stream mapping:
>>>>> Stream #0:0 -> #0:0 (copy)
>>>>> Last message repeated 1 times
>>>>> 
>>>>> Also, I think whatever options I set on the command line are going to be 
>>>>> overwritten by line 790 in hlsenc.c anyway no?
>>>> https://patchwork.ffmpeg.org/patch/11378/
>>>> 
>>>> Try this patch please :D
>>> 
>>> Thanks that works.
>>> 
>>> Let’s merge it!
>> 
>> Were you able to merge this patch?
> No, i need more time to check that.
> and look at this mail please,
> i need check this patch first, [PATCH] Fix usage of temp_file flag in 
> hls_flags option
> 

Hi Steven,

Would we be able to merge this now?

Ronak



>> 
>>> 
>>> 
>>>>> 
>>>>>> 
>>>>>> Gyan
>>>>>> 
>>>>>> ___
>>>>>> ffmpeg-devel mailing list
>>>>>> ffmpeg-devel@ffmpeg.org
>>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>>> 
>>>>> ___
>>>>> ffmpeg-devel mailing list
>>>>> ffmpeg-devel@ffmpeg.org
>>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> Thanks
> Steven
> 
> 
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: fix broken -hls_flags +temp_file

[Ronak Patel]

> On Dec 16, 2018, at 10:31 PM, Steven Liu  wrote:
> 
> Aleksey Skripka  于2018年12月14日周五 下午10:58写道：
>> 
>> 
>> From e85edcc4d8b0312c7871f78ed0859ec7436be460 Mon Sep 17 00:00:00 2001
>> From: Aleksey Skripka 
>> Date: Fri, 14 Dec 2018 14:48:31 +
>> Subject: [PATCH] libavformat/hlsenc: fix broken -hls_flags +temp_file
>> 
>> 1. fix addressing '->flags' while assigning 'use_temp_file'.
>> 2. before 223d2bde22ce33dcbcb6f17f234b609cb98f1fb6 playlist file was always 
>> created via .tmp for 'file' proto, now not. keep old behavior.
>> 3. rename logic in hls_write_packet() incorrectly placed (in fMP4-only 
>> code), thus not renaming files for mpegts.
>> 4. needless av_free() call.

Hi Aleksey,

Just wanted to make sure this wouldn’t affect standard VOD use cases running on 
a file on disk. We have some really gigantic audio files and we can’t sustain 
fragmentation times over a few minutes. Taking a week to fragment something is 
not acceptable.

I hope we don’t make temp files in those cases. Did you test that on the 
command line?

Ronak



>> ---
>> libavformat/hlsenc.c | 23 +++
>> 1 file changed, 7 insertions(+), 16 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index bdd2a11..70eee19 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1358,7 +1358,7 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>> char temp_filename[1024];
>> int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>> vs->nb_entries);
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file");
>> static unsigned warned_non_file;
>> char *key_uri = NULL;
>> char *iv_string = NULL;
>> @@ -1478,7 +1478,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>> AVFormatContext *vtt_oc = vs->vtt_avf;
>> AVDictionary *options = NULL;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (c->flags & 
>> HLS_TEMP_FILE);
>> char *filename, iv_string[KEYSIZE*2 + 1];
>> int err = 0;
>> 
>> @@ -2143,7 +2143,7 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> int stream_index = 0;
>> int range_length = 0;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags & 
>> HLS_TEMP_FILE);
>> uint8_t *buffer = NULL;
>> VariantStream *vs = NULL;
>> AVDictionary *options = NULL;
>> @@ -2266,7 +2266,6 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> if (hls->flags & HLS_SINGLE_FILE) {
>> ret = flush_dynbuf(vs, &range_length);
>> if (ret < 0) {
>> -av_free(old_filename);
>> return ret;
>> }
>> vs->size = range_length;
>> @@ -2284,20 +2283,12 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>> return ret;
>> }
>> ff_format_io_close(s, &vs->out);
>> -
>> -// rename that segment from .tmp to the real one
>> -if (use_temp_file && oc->url[0]) {
>> -hls_rename_temp_file(s, oc);
>> -av_free(old_filename);
>> -old_filename = av_strdup(vs->avf->url);
>> -
>> -if (!old_filename) {
>> -return AVERROR(ENOMEM);
>> -}
>> -}
>> }
>> }
>> 
>> +if (use_temp_file && oc->url[0] && !(hls->flags & HLS_SINGLE_FILE))
>> +hls_rename_temp_file(s, oc);
>> +
>> old_filename = av_strdup(vs->avf->url);
>> if (!old_filename) {
>> return AVERROR(ENOMEM);
>> @@ -2367,7 +2358,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
>> AVFormatContext *vtt_oc = NULL;
>> char *old_filename = NULL;
>> const char *proto = avio_find_protocol_name(s->url);
>> -int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (hls->flags & 
>> HLS_TEMP_FILE);
>> int i;
>> int ret = 0;
>> VariantStream *vs = NULL;
>> --
>> 1.8.3.1
>> 
>> --
>> Aleksey Skripka
>> 
>> 
>> 
>>> On 14 Dec 2018, at 17:21, Steven Liu  wrote:
>>> 
>>> 
>>> 
> On Dec 14, 2018, at 19:23, Aleksey Skripka  wrote:
> 
> 
> On 14 Dec 2018, at 13:10, Liu Steven  wrote:
> 
> 
> 
>> 在 2018年12月14日，下午5:27，Aleksey Skripka  写道：
>> 
>> greetings!
>> 
>>>

Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

[Ronak Patel]

> On Dec 13, 2018, at 9:15 PM, Ronak Patel  
> wrote:
> 
> 
> 
>> On Dec 12, 2018, at 2:46 AM, Liu Steven  wrote:
>> 
>> 
>> 
>>>> 在 2018年12月12日，上午5:08，Ronak  写道：
>>>> 
>>>> 
>>>> On Dec 11, 2018, at 3:28 PM, Gyan  wrote:
>>>> 
>>>> 
>>>>> On 12-12-2018 01:13 AM, Ronak wrote:
>>>>> 
>>>>> Looks like I found out why: 
>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L790. 
>>>>> The hlsenc.c file overwrites whatever I pass in the command line...
>>>> 
>>>> That is a bug but there's still an error in your command. It should be,
>>>> 
>>>> 
>>>>  -hls_ts_options movflags=+skip_sidx
>>>> 
>>>> This is because mp4 is a child muxer in this context. That hls option 
>>>> should be renamed.
>>>> 
>>>> Line 790 should be patched by adding + before frag_custom
>>> 
>>> That doesn't work.
>>> 
>>> ffmpeg -i input.mp4 -hls_ts_options movflags=+skip_sidx -codec copy 
>>> -hls_time 0.97523809523809 -hls_segment_type fmp4 -hls_flags single_file 
>>> -hls_playlist_type vod output.m3u8
>>> ffmpeg version N-92677-gdd7d6034f1 Copyright (c) 2000-2018 the FFmpeg 
>>> developers
>>> built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
>>> configuration: --prefix=/home/ronakp/ffmpeg_build 
>>> --pkg-config-flags=--static 
>>> --extra-cflags=-I/home/ronakp/ffmpeg_build/include 
>>> --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
>>> --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-libfdk_aac 
>>> --enable-libmp3lame --enable-libopus --enable-nonfree
>>> libavutil  56. 24.101 / 56. 24.101
>>> libavcodec 58. 42.100 / 58. 42.100
>>> libavformat58. 24.100 / 58. 24.100
>>> libavdevice58.  6.101 / 58.  6.101
>>> libavfilter 7. 46.101 /  7. 46.101
>>> libswscale  5.  4.100 /  5.  4.100
>>> libswresample   3.  4.100 /  3.  4.100
>>> libpostproc55.  4.100 / 55.  4.100
>>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
>>> Metadata:
>>>  major_brand : isom
>>>  minor_version   : 1
>>>  compatible_brands: isom
>>>  creation_time   : 2013-11-14T18:23:26.00Z
>>> Duration: 02:39:09.39, start: 0.00, bitrate: 31 kb/s
>>>  Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 22050 Hz, mono, 
>>> fltp, 30 kb/s (default)
>>>  Metadata:
>>>creation_time   : 2013-11-14T18:23:26.00Z
>>>handler_name: GPAC ISO Audio Handler
>>> [hls @ 0x23e1b00] Opening 'output.m4s' for writing
>>> [hls @ 0x23e1b00] Some of provided format options in 'movflags=+skip_sidx' 
>>> are not recognized
>>> Could not write header for output file #0 (incorrect codec parameters ?): 
>>> Invalid argument
>>> Stream mapping:
>>> Stream #0:0 -> #0:0 (copy)
>>>  Last message repeated 1 times
>>> 
>>> Also, I think whatever options I set on the command line are going to be 
>>> overwritten by line 790 in hlsenc.c anyway no?
>> https://patchwork.ffmpeg.org/patch/11378/
>> 
>> Try this patch please :D
> 
> Thanks that works.
> 
> Let’s merge it!

Were you able to merge this patch?

> 
> 
>>> 
>>>> 
>>>> Gyan
>>>> 
>>>> ___
>>>> ffmpeg-devel mailing list
>>>> ffmpeg-devel@ffmpeg.org
>>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> 
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4] avformat/movenc: Added an option to disable SIDX atom

[Ronak Patel]

> On Dec 12, 2018, at 2:46 AM, Liu Steven  wrote:
> 
> 
> 
>>> 在 2018年12月12日，上午5:08，Ronak  写道：
>>> 
>>> 
>>> On Dec 11, 2018, at 3:28 PM, Gyan  wrote:
>>> 
>>> 
 On 12-12-2018 01:13 AM, Ronak wrote:
 
 Looks like I found out why: 
 https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L790. 
 The hlsenc.c file overwrites whatever I pass in the command line...
>>> 
>>> That is a bug but there's still an error in your command. It should be,
>>> 
>>> 
>>>   -hls_ts_options movflags=+skip_sidx
>>> 
>>> This is because mp4 is a child muxer in this context. That hls option 
>>> should be renamed.
>>> 
>>> Line 790 should be patched by adding + before frag_custom
>> 
>> That doesn't work.
>> 
>> ffmpeg -i input.mp4 -hls_ts_options movflags=+skip_sidx -codec copy 
>> -hls_time 0.97523809523809 -hls_segment_type fmp4 -hls_flags single_file 
>> -hls_playlist_type vod output.m3u8
>> ffmpeg version N-92677-gdd7d6034f1 Copyright (c) 2000-2018 the FFmpeg 
>> developers
>> built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
>> configuration: --prefix=/home/ronakp/ffmpeg_build 
>> --pkg-config-flags=--static 
>> --extra-cflags=-I/home/ronakp/ffmpeg_build/include 
>> --extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
>> --extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-libfdk_aac 
>> --enable-libmp3lame --enable-libopus --enable-nonfree
>> libavutil  56. 24.101 / 56. 24.101
>> libavcodec 58. 42.100 / 58. 42.100
>> libavformat58. 24.100 / 58. 24.100
>> libavdevice58.  6.101 / 58.  6.101
>> libavfilter 7. 46.101 /  7. 46.101
>> libswscale  5.  4.100 /  5.  4.100
>> libswresample   3.  4.100 /  3.  4.100
>> libpostproc55.  4.100 / 55.  4.100
>> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'input.mp4':
>> Metadata:
>>   major_brand : isom
>>   minor_version   : 1
>>   compatible_brands: isom
>>   creation_time   : 2013-11-14T18:23:26.00Z
>> Duration: 02:39:09.39, start: 0.00, bitrate: 31 kb/s
>>   Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 22050 Hz, mono, 
>> fltp, 30 kb/s (default)
>>   Metadata:
>> creation_time   : 2013-11-14T18:23:26.00Z
>> handler_name: GPAC ISO Audio Handler
>> [hls @ 0x23e1b00] Opening 'output.m4s' for writing
>> [hls @ 0x23e1b00] Some of provided format options in 'movflags=+skip_sidx' 
>> are not recognized
>> Could not write header for output file #0 (incorrect codec parameters ?): 
>> Invalid argument
>> Stream mapping:
>> Stream #0:0 -> #0:0 (copy)
>>   Last message repeated 1 times
>> 
>> Also, I think whatever options I set on the command line are going to be 
>> overwritten by line 790 in hlsenc.c anyway no?
> https://patchwork.ffmpeg.org/patch/11378/
> 
> Try this patch please :D

Thanks that works.

Let’s merge it!



>> 
>>> 
>>> Gyan
>>> 
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Revert "lavc/v4l2_m2m_enc: Add missing braces around initializers."

[Ronak Patel]

> On Oct 27, 2018, at 5:25 PM, Carl Eugen Hoyos  wrote:
> 
> 2018-10-27 20:50 GMT+02:00, Mark Thompson :
>> This reverts commit 6dbb64fdccafe846aaec75d3784f7ad49d8af5df.
>> 
>> The additional braces cause build errors with Linux headers earlier
>> than 4.5 because the first element of the structure was not originally
>> a union.
> 
>> Not sure what compiler was warning about these, but it's definitely
>> incorrect for it to do so.
> 
> Must have been NDK clang.

This fix isn’t enough for this. The references to the variables in the union 
fail to compile. This doesn’t fix that.


> 
> Sorry, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronak Patel]

> On Aug 17, 2018, at 10:40 AM, Steven Liu  wrote:
> 
> 
> 
>> On Aug 17, 2018, at 21:01, Ronak  wrote:
>> 
>> From 99e28c807a49cecf6ceb47ee44a85a3fdf78af64 Mon Sep 17 00:00:00 2001
>> From: "Ronak Patel" 
>> Date: Thu, 2 Aug 2018 09:25:12 -0400
>> Subject: [PATCH v3] libavformat/hlsenc: Fix HLS Manifest Generation from an
>> N^2 algorithm to N.
>> 
>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>> unaffected.
>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>> -hlsflags temp_file is specified, instead of always relying on use_rename, 
>> which caused these problems.
>> 
>> Files that would previously take over a week to fragment now take 1 minute 
>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>> 
>> Signed-off-by: Ronak Patel 
>> ---
>> libavformat/hlsenc.c | 51 ---
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b5644f0..55983a1 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>> AVFormatContext *oc)
>>return AVERROR(ENOMEM);
>>final_filename[len-4] = '\0';
>>ret = ff_rename(oc->url, final_filename, s);
>> -oc->url[len-4] = '\0';
>>av_freep(&final_filename);
>>return ret;
>> }
>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>char temp_filename[1024];
>>int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>> vs->nb_entries);
>>const char *proto = avio_find_protocol_name(s->url);
>> -int use_rename = proto && !strcmp(proto, "file");
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>static unsigned warned_non_file;
>>char *key_uri = NULL;
>>char *iv_string = NULL;
>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>hls->version = 7;
>>}
>> 
>> -if (!use_rename && !warned_non_file++)
>> +if (!use_temp_file && !warned_non_file++)
>>av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>> may lead to races and temporary partial files\n");
>> 
>>set_http_options(s, &options, hls);
>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
>> "%s", vs->m3u8_name);
>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" 
>> : "%s", vs->m3u8_name);
>>if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>> 0)
>>goto fail;
>> 
>> @@ -1472,8 +1471,8 @@ fail:
>>av_dict_free(&options);
>>hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>> -if (ret >= 0 && use_rename)
>> -ff_rename(temp_filename, vs->m3u8_name, s);
>> +if (use_temp_file)
>> +ff_rename(temp_filename, vs->m3u8_name, s);
>> 
>>if (ret >= 0 && hls->master_pl_name)
>>if (create_master_playlist(s, vs) < 0)
>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>AVFormatContext *oc = vs->avf;
>>AVFormatContext *vtt_oc = vs->vtt_avf;
>>AVDictionary *options = NULL;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>char *filename, iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>> 
>> @@ -1583,7 +1584,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>> 
>>set_http_options(s, &options, c);
>> 
>> -if (c->flags & HLS_TEMP_FILE) {
>> +if (use_temp_file) {
>>char *new_name = av_asprintf("%s.tmp", oc->url);
>>if (!new_name)
>>return AVERROR(ENOMEM);
>> @@ -2145,6 +2146,8 @@ static int hls_write_packet(AVFormatCon

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

[Ronak Patel]

> On Aug 15, 2018, at 8:21 PM, Steven Liu  wrote:
> 
> 
> 
>>> On Aug 16, 2018, at 07:41, Ronak Patel  wrote:
>>> 
>>> 
>>> On Aug 15, 2018, at 11:08 AM, Steven Liu  wrote:
>>> 
>>> 
>>> 
>>>> On Aug 15, 2018, at 09:31, Ronak  wrote:
>>>> 
>>>> From: "Ronak Patel" mailto:ron...@audible.com>yahoo.com>
>>>> 
>>>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>>>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>>>> unaffected.
>>>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>>>> -hlsflags temp_file is specified, instead of always relying on use_rename, 
>>>> which caused these problems.
>>>> 
>>>> Files that would previously take over a week to fragment now take 1 minute 
>>>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>>>> 
>>>> Signed-off-by: Ronak Patel >>> <mailto:ronak2...@yahoo.com>>
>>>> ---
>>>> libavformat/hlsenc.c | 51 
>>>> ---
>>>> 1 file changed, 36 insertions(+), 15 deletions(-)
>>>> 
>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>> index b5644f0..7933b79 100644
>>>> --- a/libavformat/hlsenc.c
>>>> +++ b/libavformat/hlsenc.c
>>>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>>>> AVFormatContext *oc)
>>>>  return AVERROR(ENOMEM);
>>>>  final_filename[len-4] = '\0';
>>>>  ret = ff_rename(oc->url, final_filename, s);
>>>> -oc->url[len-4] = '\0';
>>>>  av_freep(&final_filename);
>>>>  return ret;
>>>> }
>>>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>>>> VariantStream *vs)
>>>>  char temp_filename[1024];
>>>>  int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>>>> vs->nb_entries);
>>>>  const char *proto = avio_find_protocol_name(s->url);
>>>> -int use_rename = proto && !strcmp(proto, "file");
>>>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>>>> HLS_TEMP_FILE);
>>>>  static unsigned warned_non_file;
>>>>  char *key_uri = NULL;
>>>>  char *iv_string = NULL;
>>>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int 
>>>> last, VariantStream *vs)
>>>>  hls->version = 7;
>>>>  }
>>>> -if (!use_rename && !warned_non_file++)
>>>> +if (!use_temp_file && !warned_non_file++)
>>>>  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>>>> may lead to races and temporary partial files\n");
>>>>  set_http_options(s, &options, hls);
>>>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" 
>>>> : "%s", vs->m3u8_name);
>>>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? 
>>>> "%s.tmp" : "%s", vs->m3u8_name);
>>>>  if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>>>> 0)
>>>>  goto fail;
>>>> @@ -1472,8 +1471,8 @@ fail:
>>>>  av_dict_free(&options);
>>>>  hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>>>  hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>>>> -if (ret >= 0 && use_rename)
>>>> -ff_rename(temp_filename, vs->m3u8_name, s);
>>>> +if (use_temp_file)
>>>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>>>  if (ret >= 0 && hls->master_pl_name)
>>>>  if (create_master_playlist(s, vs) < 0)
>>>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, 
>>>> VariantStream *vs)
>>>>  AVFormatContext *oc = vs->avf;
>>>>  AVFormatContext *vtt_oc = vs->vtt_avf;
>>>>  AVDictionary *options = NULL;
>>>> +const char *proto = avio_find_protocol_name(s->url);
>>>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
&

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

[Ronak Patel]

> On Aug 15, 2018, at 8:39 PM, Ronak Patel  wrote:
> 
> 
>> On Aug 15, 2018, at 8:21 PM, Steven Liu  wrote:
>> 
>> 
>> 
>>>> On Aug 16, 2018, at 07:41, Ronak Patel  wrote:
>>>> 
>>>> 
>>>> On Aug 15, 2018, at 11:08 AM, Steven Liu  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Aug 15, 2018, at 09:31, Ronak  
>>>>> wrote:
>>>>> 
>>>>> From: "Ronak Patel" mailto:ron...@audible.com>yahoo.com>
>>>>> 
>>>>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>>>>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>>>>> unaffected.
>>>>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>>>>> -hlsflags temp_file is specified, instead of always relying on 
>>>>> use_rename, which caused these problems.
>>>>> 
>>>>> Files that would previously take over a week to fragment now take 1 
>>>>> minute on the same hardware. This was a 153 hour audio file (2.2GB of 
>>>>> audio).
>>>>> 
>>>>> Signed-off-by: Ronak Patel >>>> <mailto:ronak2...@yahoo.com>>
>>>>> ---
>>>>> libavformat/hlsenc.c | 51 
>>>>> ---
>>>>> 1 file changed, 36 insertions(+), 15 deletions(-)
>>>>> 
>>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>>> index b5644f0..7933b79 100644
>>>>> --- a/libavformat/hlsenc.c
>>>>> +++ b/libavformat/hlsenc.c
>>>>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>>>>> AVFormatContext *oc)
>>>>> return AVERROR(ENOMEM);
>>>>> final_filename[len-4] = '\0';
>>>>> ret = ff_rename(oc->url, final_filename, s);
>>>>> -oc->url[len-4] = '\0';
>>>>> av_freep(&final_filename);
>>>>> return ret;
>>>>> }
>>>>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>>>>> VariantStream *vs)
>>>>> char temp_filename[1024];
>>>>> int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>>>>> vs->nb_entries);
>>>>> const char *proto = avio_find_protocol_name(s->url);
>>>>> -int use_rename = proto && !strcmp(proto, "file");
>>>>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>>>>> HLS_TEMP_FILE);
>>>>> static unsigned warned_non_file;
>>>>> char *key_uri = NULL;
>>>>> char *iv_string = NULL;
>>>>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int 
>>>>> last, VariantStream *vs)
>>>>> hls->version = 7;
>>>>> }
>>>>> -if (!use_rename && !warned_non_file++)
>>>>> +if (!use_temp_file && !warned_non_file++)
>>>>> av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>>>>> may lead to races and temporary partial files\n");
>>>>> set_http_options(s, &options, hls);
>>>>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" 
>>>>> : "%s", vs->m3u8_name);
>>>>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? 
>>>>> "%s.tmp" : "%s", vs->m3u8_name);
>>>>> if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>>>>> 0)
>>>>> goto fail;
>>>>> @@ -1472,8 +1471,8 @@ fail:
>>>>> av_dict_free(&options);
>>>>> hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>>>> hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>>>>> -if (ret >= 0 && use_rename)
>>>>> -ff_rename(temp_filename, vs->m3u8_name, s);
>>>>> +if (use_temp_file)
>>>>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>>>> if (ret >= 0 && hls->master_pl_name)
>>>>> if (create_master_playlist(s, vs) < 0)
>>>>> @@ -1488,6 +1487,8 @@ static int hls_sta

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

[Ronak Patel]

> On Aug 15, 2018, at 11:08 AM, Steven Liu  wrote:
> 
> 
> 
>> On Aug 15, 2018, at 09:31, Ronak  wrote:
>> 
>> From: "Ronak Patel" mailto:ron...@audible.com>yahoo.com>
>> 
>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>> unaffected.
>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>> -hlsflags temp_file is specified, instead of always relying on use_rename, 
>> which caused these problems.
>> 
>> Files that would previously take over a week to fragment now take 1 minute 
>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>> 
>> Signed-off-by: Ronak Patel mailto:ronak2...@yahoo.com>>
>> ---
>> libavformat/hlsenc.c | 51 ---
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b5644f0..7933b79 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>> AVFormatContext *oc)
>>return AVERROR(ENOMEM);
>>final_filename[len-4] = '\0';
>>ret = ff_rename(oc->url, final_filename, s);
>> -oc->url[len-4] = '\0';
>>av_freep(&final_filename);
>>return ret;
>> }
>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>char temp_filename[1024];
>>int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>> vs->nb_entries);
>>const char *proto = avio_find_protocol_name(s->url);
>> -int use_rename = proto && !strcmp(proto, "file");
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>static unsigned warned_non_file;
>>char *key_uri = NULL;
>>char *iv_string = NULL;
>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>hls->version = 7;
>>}
>> -if (!use_rename && !warned_non_file++)
>> +if (!use_temp_file && !warned_non_file++)
>>av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>> may lead to races and temporary partial files\n");
>>set_http_options(s, &options, hls);
>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
>> "%s", vs->m3u8_name);
>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" 
>> : "%s", vs->m3u8_name);
>>if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>> 0)
>>goto fail;
>> @@ -1472,8 +1471,8 @@ fail:
>>av_dict_free(&options);
>>hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>> -if (ret >= 0 && use_rename)
>> -ff_rename(temp_filename, vs->m3u8_name, s);
>> +if (use_temp_file)
>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>if (ret >= 0 && hls->master_pl_name)
>>if (create_master_playlist(s, vs) < 0)
>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>AVFormatContext *oc = vs->avf;
>>AVFormatContext *vtt_oc = vs->vtt_avf;
>>AVDictionary *options = NULL;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>char *filename, iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>> @@ -1583,7 +1584,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>set_http_options(s, &options, c);
>> -if (c->flags & HLS_TEMP_FILE) {
>> +if (use_temp_file) {
>>char *new_name = av_asprintf("%s.tmp", oc->url);
>>if (!new_name)
>>return AVERROR(ENOMEM);
>> @@ -2145,6 +2146,8 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>int ret = 0, can_split = 1, i, j;
>>int stream_index = 0;
>>int range_length = 0;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_

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

[Ronak Patel]

> On Aug 15, 2018, at 6:46 AM, Liu Steven  wrote:
> 
> 
> 
>>> 在 2018年8月15日，下午6:37，Ronak Patel  写道：
>>> 
>>> 
>>> On Aug 14, 2018, at 10:57 PM, Liu Steven  wrote:
>>> 
>>> 
>>> 
>>>> 在 2018年8月15日，上午9:31，Ronak  写道：
>>>> 
>>>> From: "Ronak Patel" mailto:ronak2...@yahoo.com>yahoo.com>
>>>> 
>>>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>>>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>>>> unaffected.
>>>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>>>> -hlsflags temp_file is specified, instead of always relying on use_rename, 
>>>> which caused these problems.
>>>> 
>>>> Files that would previously take over a week to fragment now take 1 minute 
>>>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>>>> 
>>>> Signed-off-by: Ronak Patel >>> <mailto:ronak2...@yahoo.com>>
>>>> ---
>>>> libavformat/hlsenc.c | 51 
>>>> ---
>>>> 1 file changed, 36 insertions(+), 15 deletions(-)
>>>> 
>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>> index b5644f0..7933b79 100644
>>>> --- a/libavformat/hlsenc.c
>>>> +++ b/libavformat/hlsenc.c
>>>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>>>> AVFormatContext *oc)
>>>>  return AVERROR(ENOMEM);
>>>>  final_filename[len-4] = '\0';
>>>>  ret = ff_rename(oc->url, final_filename, s);
>>>> -oc->url[len-4] = '\0';
>>>>  av_freep(&final_filename);
>>>>  return ret;
>>>> }
>>>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>>>> VariantStream *vs)
>>>>  char temp_filename[1024];
>>>>  int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>>>> vs->nb_entries);
>>>>  const char *proto = avio_find_protocol_name(s->url);
>>>> -int use_rename = proto && !strcmp(proto, "file");
>>>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>>>> HLS_TEMP_FILE);
>>>>  static unsigned warned_non_file;
>>>>  char *key_uri = NULL;
>>>>  char *iv_string = NULL;
>>>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int 
>>>> last, VariantStream *vs)
>>>>  hls->version = 7;
>>>>  }
>>>> -if (!use_rename && !warned_non_file++)
>>>> +if (!use_temp_file && !warned_non_file++)
>>>>  av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>>>> may lead to races and temporary partial files\n");
>>>>  set_http_options(s, &options, hls);
>>>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" 
>>>> : "%s", vs->m3u8_name);
>>>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? 
>>>> "%s.tmp" : "%s", vs->m3u8_name);
>>>>  if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>>>> 0)
>>>>  goto fail;
>>>> @@ -1472,8 +1471,8 @@ fail:
>>>>  av_dict_free(&options);
>>>>  hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>>>  hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>>>> -if (ret >= 0 && use_rename)
>>>> -ff_rename(temp_filename, vs->m3u8_name, s);
>>>> +if (use_temp_file)
>>>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>>>  if (ret >= 0 && hls->master_pl_name)
>>>>  if (create_master_playlist(s, vs) < 0)
>>>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, 
>>>> VariantStream *vs)
>>>>  AVFormatContext *oc = vs->avf;
>>>>  AVFormatContext *vtt_oc = vs->vtt_avf;
>>>>  AVDictionary *options = NULL;
>>>> +const char *proto = avio_find_protocol_name(s->url);
>>>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>>>> HL

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

[Ronak Patel]

> On Aug 14, 2018, at 10:57 PM, Liu Steven  wrote:
> 
> 
> 
>> 在 2018年8月15日，上午9:31，Ronak  写道：
>> 
>> From: "Ronak Patel" mailto:ronak2...@yahoo.com>yahoo.com>
>> 
>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>> entire manifest at the end for VOD playlists. Live & Event Playlists are 
>> unaffected.
>> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
>> -hlsflags temp_file is specified, instead of always relying on use_rename, 
>> which caused these problems.
>> 
>> Files that would previously take over a week to fragment now take 1 minute 
>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>> 
>> Signed-off-by: Ronak Patel mailto:ronak2...@yahoo.com>>
>> ---
>> libavformat/hlsenc.c | 51 ---
>> 1 file changed, 36 insertions(+), 15 deletions(-)
>> 
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index b5644f0..7933b79 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -1168,7 +1168,6 @@ static int hls_rename_temp_file(AVFormatContext *s, 
>> AVFormatContext *oc)
>>return AVERROR(ENOMEM);
>>final_filename[len-4] = '\0';
>>ret = ff_rename(oc->url, final_filename, s);
>> -oc->url[len-4] = '\0';
>>av_freep(&final_filename);
>>return ret;
>> }
>> @@ -1374,7 +1373,7 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>char temp_filename[1024];
>>int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>> vs->nb_entries);
>>const char *proto = avio_find_protocol_name(s->url);
>> -int use_rename = proto && !strcmp(proto, "file");
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>static unsigned warned_non_file;
>>char *key_uri = NULL;
>>char *iv_string = NULL;
>> @@ -1397,11 +1396,11 @@ static int hls_window(AVFormatContext *s, int last, 
>> VariantStream *vs)
>>hls->version = 7;
>>}
>> -if (!use_rename && !warned_non_file++)
>> +if (!use_temp_file && !warned_non_file++)
>>av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, this 
>> may lead to races and temporary partial files\n");
>>set_http_options(s, &options, hls);
>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" : 
>> "%s", vs->m3u8_name);
>> +snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" 
>> : "%s", vs->m3u8_name);
>>if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options)) < 
>> 0)
>>goto fail;
>> @@ -1472,8 +1471,8 @@ fail:
>>av_dict_free(&options);
>>hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
>>hlsenc_io_close(s, &hls->sub_m3u8_out, vs->vtt_m3u8_name);
>> -if (ret >= 0 && use_rename)
>> -ff_rename(temp_filename, vs->m3u8_name, s);
>> +if (use_temp_file)
>> +ff_rename(temp_filename, vs->m3u8_name, s);
>>if (ret >= 0 && hls->master_pl_name)
>>if (create_master_playlist(s, vs) < 0)
>> @@ -1488,6 +1487,8 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>AVFormatContext *oc = vs->avf;
>>AVFormatContext *vtt_oc = vs->vtt_avf;
>>AVDictionary *options = NULL;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_temp_file = proto && !strcmp(proto, "file") && (s->flags & 
>> HLS_TEMP_FILE);
>>char *filename, iv_string[KEYSIZE*2 + 1];
>>int err = 0;
>> @@ -1583,7 +1584,7 @@ static int hls_start(AVFormatContext *s, VariantStream 
>> *vs)
>>set_http_options(s, &options, c);
>> -if (c->flags & HLS_TEMP_FILE) {
>> +if (use_temp_file) {
>>char *new_name = av_asprintf("%s.tmp", oc->url);
>>if (!new_name)
>>return AVERROR(ENOMEM);
>> @@ -2145,6 +2146,8 @@ static int hls_write_packet(AVFormatContext *s, 
>> AVPacket *pkt)
>>int ret = 0, can_split = 1, i, j;
>>int stream_index = 0;
>>int range_length = 0;
>> +const char *proto = avio_find_protocol_name(s->url);
>> +int use_

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

[Ronak Patel]

On Aug 10, 2018, at 7:30 AM, Liu Steven  wrote:

 
>>> 
>>> Hi Steven,
>>> 
>>> Please see my new patch taking your feedback into account.
>>> 
>>> Ronak
>> 
>> Hi Steven,
>> 
>> Did you have a chance to review? I’m going to send you a new patch for 
>> dashenc.c shortly.
> Don’t worry, i will review it weekend, but i think your ways is not a better 
> way, maybe just change the hls_window maybe ok. the other code need not 
> modify.
>> 

The other code fixes the problem that HLS_TEMP option wasn’t working. 
Use_rename should only be on if it’s been specified on the command line.


>> For dashenc.c, ffmpeg again always assumes we are doing live streaming. It 
>> doesn’t even have another profile. I’m going to add a VOD profile to it and 
>> fix this problem there. I will have to add a new cli parameter so we can 
>> specify the profile now.
>> 
>> Ronak
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronak Patel]

> On Aug 8, 2018, at 5:37 PM, Ronak  wrote:
> 
> 
> 
>> On Aug 8, 2018, at 3:52 PM, Ronak  wrote:
>> 
>> 
>> 
>>> On Aug 6, 2018, at 10:20 AM, Steven Liu  wrote:
>>> 
>>> 
>>> 
>>>>> On Aug 6, 2018, at 19:29, Ronak Patel  
>>>>> wrote:
>>>>> 
>>>>> 
>>>>> On Aug 6, 2018, at 7:19 AM, Liu Steven  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>>> 在 2018年8月6日，下午7:12，Ronak Patel  写道：
>>>>>>> 
>>>>>>> 
>>>>>>> On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> 在 2018年8月4日，上午2:17，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.87,
>>>>>>>>>>>>>> output_test0.ts
>>>>>>>>>>>>>> #EXTINF:7.30,
>>>>>>>>>>>>>> output_test1.ts
>>>>>>>>>>>>>> #EXTINF:8.33,
>>>>>>>>>>>>>> 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
>>>>>&g

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

[Ronak Patel]

> On Aug 6, 2018, at 7:19 AM, Liu Steven  wrote:
> 
> 
> 
>>> 在 2018年8月6日，下午7:12，Ronak Patel  写道：
>>> 
>>> 
>>> On Aug 5, 2018, at 10:54 PM, Liu Steven  wrote:
>>> 
>>> 
>>> 
>>>> 在 2018年8月4日，上午2:17，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.87,
>>>>>>>>>> output_test0.ts
>>>>>>>>>> #EXTINF:7.30,
>>>>>>>>>> output_test1.ts
>>>>>>>>>> #EXTINF:8.33,
>>>>>>>>>> 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.87,
>>>>>>>> output_test0.m4s
>>>>>>>> #EXTINF:7.30,
>>>>>>>> output_test1.m4s
>>>>>>>> #EXTINF:8.33,
>>>>>>>> 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.87,
>>>>>>&

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

[Ronak Patel]

gt;>>> is:
>>>>> 
>>>>> #EXT-X-TARGETDURATION:
>>>>> 
>>>>> 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.30 
>>>>> EXTINF:8.33
>>>> 
>>>> 
>>>>>>>> 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.87,
>>>>> output_test0.m4s
>>>>> #EXTINF:7.30,
>>>>> output_test1.m4s
>>>>> #EXTINF:8.33,
>>>>> output_test2.m4s
>>>>> #EXTINF:3.97,
>>>>> output_test3.m4s
>>>>> #EXTINF:8.33,
>>>>> output_test4.m4s
>>>>> #EXTINF:4.03,
>>>>> output_test5.m4s
>>>>> #EXTINF:8.33,
>>>>> output_test6.m4s
>>>>> #EXTINF:4.63,
>>>>> 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>
> 
> From bbc4870c0d685f5c07e82042c3f2ef153d83f3d1 Mon Sep 17 00:00:00 2001
> From: "Ronak Patel (Audible)" 
> Date: Thu, 2 Aug 2018 09:25:12 -0400
> Subject: [PATCH] libavformat/hlsenc: Fix HLS Manifest Generation from an N^2
> algorithm to N.
> 
> This fixes the creation of the hls manifest in hlsenc.c by writing the entire 
> manifest at the end for VOD playlists. Live & Event Playlists are unaffected.
> This also fixes the behavior with HLS_TEMP_FILE to work correctly when 
> -hlsflags temp_file is specified, instead of always relying on use_rename, 
> which caused these problems.
> 
>

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

[Ronak Patel]

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

Hi Steven,

Can you please have a look at the updated patch and tell me what you think?

I also fixed the temp_file implementation.

If you like this approach, I’ll do this for dash as well.

I’ve noticed that ffmpeg always assumes the dash stream is live until the very 
end and doesn’t support profiles (onDemand, live, etc) like mp4box does. I’m 
going to have to add that to dashenc.

Ronak

> 
> Thanks,
> 
> Ronak
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronak Patel]

> On Aug 1, 2018, at 9:30 PM, Ronak Patel  
> wrote:
> 
> 
>> On Aug 1, 2018, at 7:30 PM, Steven Liu  wrote:
>> 
>> 
>> 
>>> On Aug 2, 2018, at 07:22, Steven Liu  wrote:
>>> 
>>> 
>>> 
>>>>> On Aug 2, 2018, at 06:20, Ronak  wrote:
>>>>> 
>>>>> 
>>>>> On Aug 1, 2018, at 4:41 PM, Steven Liu  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Aug 2, 2018, at 03:50, Ronak  
>>>>>> wrote:
>>>>>> 
>>>>>> <0001-libavformat-hlsenc-Fix-HLS-Manifest-Generation-from-.patch>
>>>>> From e7ff03ed52c709d647a112833427b44c41e3ed12 Mon Sep 17 00:00:00 2001
>>>>> From: "Ronak Patel (Audible)" 
>>>>> Date: Tue, 31 Jul 2018 19:05:18 -0400
>>>>> Subject: [PATCH] libavformat/hlsenc: Fix HLS Manifest Generation from an 
>>>>> N^2
>>>>> algorithm to N.
>>>>> 
>>>>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>>>>> header once in hls_write_header, and the segments individually in the 
>>>>> hls_window method.
>>>>> Files that would previously take over a week to fragment now take 1 
>>>>> minute on the same hardware. This was a 153 hour audio file (2.2GB of 
>>>>> audio).
>>>>> 
>>>>> Signed-off-by: Ronak Patel 
>>>>> ---
>>>>> libavformat/hlsenc.c | 143 
>>>>> +++
>>>>> 1 file changed, 76 insertions(+), 67 deletions(-)
>>>>> 
>>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>>> index b5644f0..b15645d 100644
>>>>> --- a/libavformat/hlsenc.c
>>>>> +++ b/libavformat/hlsenc.c
>>>>> @@ -488,7 +488,6 @@ static int hls_delete_old_segments(AVFormatContext 
>>>>> *s, HLSContext *hls,
>>>>>  }
>>>>>  p = (char *)av_basename(dirname);
>>>>>  *p = '\0';
>>>>> -
>>>>>  }
>>>>> 
>>>>>  while (segment) {
>>>>> @@ -1365,63 +1364,37 @@ fail:
>>>>>  return ret;
>>>>> }
>>>>> 
>>>>> -static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
>>>>> +static int hls_write_manifest_segment(AVFormatContext *s, int last, 
>>>>> VariantStream *vs)
>>>>> {
>>>>>  HLSContext *hls = s->priv_data;
>>>>>  HLSSegment *en;
>>>>> -int target_duration = 0;
>>>>>  int ret = 0;
>>>>> -char temp_filename[1024];
>>>>> -int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>>>>> vs->nb_entries);
>>>>> -const char *proto = avio_find_protocol_name(s->url);
>>>>> -int use_rename = proto && !strcmp(proto, "file");
>>>>> -static unsigned warned_non_file;
>>>>> +int byterange_mode;
>>>>>  char *key_uri = NULL;
>>>>>  char *iv_string = NULL;
>>>>>  AVDictionary *options = NULL;
>>>>>  double prog_date_time = vs->initial_prog_date_time;
>>>>>  double *prog_date_time_p = (hls->flags & HLS_PROGRAM_DATE_TIME) ? 
>>>>> &prog_date_time : NULL;
>>>>> -int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || 
>>>>> (hls->max_seg_size > 0);
>>>>> -
>>>>> -hls->version = 3;
>>>>> -if (byterange_mode) {
>>>>> -hls->version = 4;
>>>>> -sequence = 0;
>>>>> -}
>>>>> -
>>>>> -if (hls->flags & HLS_INDEPENDENT_SEGMENTS) {
>>>>> -hls->version = 6;
>>>>> -}
>>>>> 
>>>>> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>>>> -hls->version = 7;
>>>>> -}
>>>>> +if (last) {
>>>>> 
>>>>> -if (!use_rename && !warned_non_file++)
>>>>> -av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, 
>>>>> this may lead to races and temporary partial files\n");
>>>>> +if ((hls->flags & HLS_OMIT_ENDLIST==0)) {
>>>>&g

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

[Ronak Patel]

> On Aug 1, 2018, at 7:30 PM, Steven Liu  wrote:
> 
> 
> 
>> On Aug 2, 2018, at 07:22, Steven Liu  wrote:
>> 
>> 
>> 
>>>> On Aug 2, 2018, at 06:20, Ronak  wrote:
>>>> 
>>>> 
>>>> On Aug 1, 2018, at 4:41 PM, Steven Liu  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Aug 2, 2018, at 03:50, Ronak  wrote:
>>>>> 
>>>>> <0001-libavformat-hlsenc-Fix-HLS-Manifest-Generation-from-.patch>
>>>> From e7ff03ed52c709d647a112833427b44c41e3ed12 Mon Sep 17 00:00:00 2001
>>>> From: "Ronak Patel (Audible)" 
>>>> Date: Tue, 31 Jul 2018 19:05:18 -0400
>>>> Subject: [PATCH] libavformat/hlsenc: Fix HLS Manifest Generation from an 
>>>> N^2
>>>> algorithm to N.
>>>> 
>>>> This fixes the creation of the hls manifest in hlsenc.c by writing the 
>>>> header once in hls_write_header, and the segments individually in the 
>>>> hls_window method.
>>>> Files that would previously take over a week to fragment now take 1 minute 
>>>> on the same hardware. This was a 153 hour audio file (2.2GB of audio).
>>>> 
>>>> Signed-off-by: Ronak Patel 
>>>> ---
>>>> libavformat/hlsenc.c | 143 
>>>> +++
>>>> 1 file changed, 76 insertions(+), 67 deletions(-)
>>>> 
>>>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>>>> index b5644f0..b15645d 100644
>>>> --- a/libavformat/hlsenc.c
>>>> +++ b/libavformat/hlsenc.c
>>>> @@ -488,7 +488,6 @@ static int hls_delete_old_segments(AVFormatContext *s, 
>>>> HLSContext *hls,
>>>>   }
>>>>   p = (char *)av_basename(dirname);
>>>>   *p = '\0';
>>>> -
>>>>   }
>>>> 
>>>>   while (segment) {
>>>> @@ -1365,63 +1364,37 @@ fail:
>>>>   return ret;
>>>> }
>>>> 
>>>> -static int hls_window(AVFormatContext *s, int last, VariantStream *vs)
>>>> +static int hls_write_manifest_segment(AVFormatContext *s, int last, 
>>>> VariantStream *vs)
>>>> {
>>>>   HLSContext *hls = s->priv_data;
>>>>   HLSSegment *en;
>>>> -int target_duration = 0;
>>>>   int ret = 0;
>>>> -char temp_filename[1024];
>>>> -int64_t sequence = FFMAX(hls->start_sequence, vs->sequence - 
>>>> vs->nb_entries);
>>>> -const char *proto = avio_find_protocol_name(s->url);
>>>> -int use_rename = proto && !strcmp(proto, "file");
>>>> -static unsigned warned_non_file;
>>>> +int byterange_mode;
>>>>   char *key_uri = NULL;
>>>>   char *iv_string = NULL;
>>>>   AVDictionary *options = NULL;
>>>>   double prog_date_time = vs->initial_prog_date_time;
>>>>   double *prog_date_time_p = (hls->flags & HLS_PROGRAM_DATE_TIME) ? 
>>>> &prog_date_time : NULL;
>>>> -int byterange_mode = (hls->flags & HLS_SINGLE_FILE) || 
>>>> (hls->max_seg_size > 0);
>>>> -
>>>> -hls->version = 3;
>>>> -if (byterange_mode) {
>>>> -hls->version = 4;
>>>> -sequence = 0;
>>>> -}
>>>> -
>>>> -if (hls->flags & HLS_INDEPENDENT_SEGMENTS) {
>>>> -hls->version = 6;
>>>> -}
>>>> 
>>>> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>>>> -hls->version = 7;
>>>> -}
>>>> +if (last) {
>>>> 
>>>> -if (!use_rename && !warned_non_file++)
>>>> -av_log(s, AV_LOG_ERROR, "Cannot use rename on non file protocol, 
>>>> this may lead to races and temporary partial files\n");
>>>> +if ((hls->flags & HLS_OMIT_ENDLIST==0)) {
>>>> +ff_hls_write_end_list(hls->m3u8_out);
>>>> +}
>>>> 
>>>> -set_http_options(s, &options, hls);
>>>> -snprintf(temp_filename, sizeof(temp_filename), use_rename ? "%s.tmp" 
>>>> : "%s", vs->m3u8_name);
>>>> -if ((ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, 
>>>> &options)) < 0)
>>>> -goto fail;

Re: [FFmpeg-devel] [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

> On Jul 25, 2018, at 11:25 PM, Ronak Patel  
> wrote:
> 
> 
> 
>> On Jul 25, 2018, at 11:12 PM, Liu Steven  wrote:
>> 
>> 
>> 
>>> 在 2018年7月26日，上午7:04，Ronak Patel  写道：
>>> 
>>> Hi,
>>> 
>>> We’d like to start working on this real soon and want to make sure we 
>>> properly fix this. We understand this code is used by more than just fMP4 
>>> assets and even live streaming use cases.
>>> 
>>> Can anyone please help shed some light on all use cases we should make sure 
>>> are working after we make our fixes?
>>> 
>>> We’re afraid that the number of use cases here are unknown and we’ll be 
>>> stuck fixing this for an unknown time.
>>> 
>>> Can anyone please shed some light on this?
>> 
>> you can try -f segment or -f hls or -f dash to do waht you want try, if all 
>> of them cannot suuport your feature, you can submmit patch here.
>> or you can submmit a new hls muxer patch here if you cannot fix all the 
>> parameters for the old hls muxer.
>> 

Ok I’m going to try to fix mpegts, live streams, fmp4 and the other options 
that you already have.

Are there any unit tests or other tests we can run to ensure everything is 
still working?

If not we will have to make sure it works manually.


>>> 
>>> Thanks
>>> 
>>> Ronak
>>> 
>>>> On Jul 13, 2018, at 8:05 AM, Ronak Patel 
>>>>  wrote:
>>>> 
>>>> I was wondering if anyone on the development list was familiar with this 
>>>> code and could provide pointers on how to fix up the code due to the below 
>>>> problem.
>>>> 
>>>> 
>>>>> On Jul 12, 2018, at 7:27 PM, Ronak Patel 
>>>>>  wrote:
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Jul 12, 2018, at 6:21 PM, Ronak Patel 
>>>>>>  wrote:
>>>>>> 
>>>>>> Hey Carl,
>>>>>> 
>>>>>> So I dug into this more today and I have root caused what's exactly 
>>>>>> happening here. 
>>>>>> 
>>>>>> The problematic code is this: 
>>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 
>>>>>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368>
>>>>>> This is where the filename is set and the next line actually opens the 
>>>>>> file. 
>>>>>> 
>>>>>> The logic for this hls_window method is the following:
>>>>>> 
>>>>>> 1. Make a new temporary file.
>>>>>> 2. Write out a new HLS manifest header.
>>>>>> 3. Loop through all available segments and write out all of the entries 
>>>>>> for them.
>>>>>> 4. Close the temporary file when finished.
>>>>>> 5. Rename the temporary file to the target file name.
>>>>>> 6. Rinse and repeat for every single fragment.
>> 
>> do you mean append fragment info to the m3u8 list, don’t refresh it?
> 
> Yup that’s what I mean. The fact that ffmpeg is refreshing the entire 
> manifest hundreds of thousands of times is the reason for this massive slow 
> down.
> 
> We tried changing the code a little to only write the manifest once once at 
> end, and we can now fragment a 60 hour audio file in less than one minute. 
> Less than one minute compared to 4 days is a BIG time savings.
> 
> 
>>>>>> 
>>>>>> Therefore, if you can imagine a 153 hour audio file, we write out a 
>>>>>> totally new HLS manifest 550800 times (153 * 60 * 60 assuming a 1s 
>>>>>> fragment duration) that gets progressively larger as each fragment is 
>>>>>> generated.
>>>>>> 
>>>>>> This is a classic O(N^2) algorithm implementation, instead of:
>>>>>> 
>>>>>> 1. Creating the destination file up front & write the manifest header.
>>>>>> 2. Append the new segment to the file.
>>>>>> 3. If this is the last segment, write out EXT-X-ENDLIST.
>>>>>> 
>>>>>> There's no looping involved, nor the need to make temporary files.
>>>>>> 
>>>>>> FYI that I've noticed the same sort of pattern being applied to MPEG 
>>>>>> DASH: 
>>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 
>>>>&

Re: [FFmpeg-devel] [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

> On Jul 25, 2018, at 11:12 PM, Liu Steven  wrote:
> 
> 
> 
>> 在 2018年7月26日，上午7:04，Ronak Patel  写道：
>> 
>> Hi,
>> 
>> We’d like to start working on this real soon and want to make sure we 
>> properly fix this. We understand this code is used by more than just fMP4 
>> assets and even live streaming use cases.
>> 
>> Can anyone please help shed some light on all use cases we should make sure 
>> are working after we make our fixes?
>> 
>> We’re afraid that the number of use cases here are unknown and we’ll be 
>> stuck fixing this for an unknown time.
>> 
>> Can anyone please shed some light on this?
> 
> you can try -f segment or -f hls or -f dash to do waht you want try, if all 
> of them cannot suuport your feature, you can submmit patch here.
> or you can submmit a new hls muxer patch here if you cannot fix all the 
> parameters for the old hls muxer.
> 
>> 
>> Thanks
>> 
>> Ronak
>> 
>>> On Jul 13, 2018, at 8:05 AM, Ronak Patel 
>>>  wrote:
>>> 
>>> I was wondering if anyone on the development list was familiar with this 
>>> code and could provide pointers on how to fix up the code due to the below 
>>> problem.
>>> 
>>> 
>>>> On Jul 12, 2018, at 7:27 PM, Ronak Patel 
>>>>  wrote:
>>>> 
>>>> 
>>>> 
>>>>> On Jul 12, 2018, at 6:21 PM, Ronak Patel 
>>>>>  wrote:
>>>>> 
>>>>> Hey Carl,
>>>>> 
>>>>> So I dug into this more today and I have root caused what's exactly 
>>>>> happening here. 
>>>>> 
>>>>> The problematic code is this: 
>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 
>>>>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368>
>>>>> This is where the filename is set and the next line actually opens the 
>>>>> file. 
>>>>> 
>>>>> The logic for this hls_window method is the following:
>>>>> 
>>>>> 1. Make a new temporary file.
>>>>> 2. Write out a new HLS manifest header.
>>>>> 3. Loop through all available segments and write out all of the entries 
>>>>> for them.
>>>>> 4. Close the temporary file when finished.
>>>>> 5. Rename the temporary file to the target file name.
>>>>> 6. Rinse and repeat for every single fragment.
> 
> do you mean append fragment info to the m3u8 list, don’t refresh it?

Yup that’s what I mean. The fact that ffmpeg is refreshing the entire manifest 
hundreds of thousands of times is the reason for this massive slow down.

We tried changing the code a little to only write the manifest once once at 
end, and we can now fragment a 60 hour audio file in less than one minute. Less 
than one minute compared to 4 days is a BIG time savings.


>>>>> 
>>>>> Therefore, if you can imagine a 153 hour audio file, we write out a 
>>>>> totally new HLS manifest 550800 times (153 * 60 * 60 assuming a 1s 
>>>>> fragment duration) that gets progressively larger as each fragment is 
>>>>> generated.
>>>>> 
>>>>> This is a classic O(N^2) algorithm implementation, instead of:
>>>>> 
>>>>> 1. Creating the destination file up front & write the manifest header.
>>>>> 2. Append the new segment to the file.
>>>>> 3. If this is the last segment, write out EXT-X-ENDLIST.
>>>>> 
>>>>> There's no looping involved, nor the need to make temporary files.
>>>>> 
>>>>> FYI that I've noticed the same sort of pattern being applied to MPEG 
>>>>> DASH: 
>>>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 
>>>>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786>
>>>>> 
>>>>> To implement something like this, looks like we'd have to significantly 
>>>>> re-engineer the code. Do you have any pointers on how to go about doing 
>>>>> this? Or, would you be able to help do this?
>>>>> 
>>>> 
>>>> I was thinking about this and I think it must have been implemented this 
>>>> way because of live hls streams? Not writing to the main manifest directly 
>>>> and keeping that stream open does release any file system locks that there 
>>>> would be otherwise. 
>>>> 
>>>> Is this the reason why this was done this way at all?
>>>> 
>>>> 
>>>>> Thanks for all your help,
>>>>> 
>>>>> Ronak
>>>>> 
>>>>>> On Jun 27, 2018, at 2:04 PM, Carl Zwanzig  wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I haven't traced it out completely, but take a look at the flag 
>>>>>> HLS_TEMP_FILE in libavformat/hlsenc.c.
>>>>>> 
>>>>>> Later,
>>>>>> 
>>>>>> z!
>>>>> ___
> 
> Thanks
> 
> Steven Liu
>> 
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

Hi,

We’d like to start working on this real soon and want to make sure we properly 
fix this. We understand this code is used by more than just fMP4 assets and 
even live streaming use cases.

Can anyone please help shed some light on all use cases we should make sure are 
working after we make our fixes?

We’re afraid that the number of use cases here are unknown and we’ll be stuck 
fixing this for an unknown time.

Can anyone please shed some light on this?

Thanks

Ronak

> On Jul 13, 2018, at 8:05 AM, Ronak Patel  
> wrote:
> 
> I was wondering if anyone on the development list was familiar with this code 
> and could provide pointers on how to fix up the code due to the below problem.
> 
> 
>> On Jul 12, 2018, at 7:27 PM, Ronak Patel  
>> wrote:
>> 
>> 
>> 
>>> On Jul 12, 2018, at 6:21 PM, Ronak Patel 
>>>  wrote:
>>> 
>>> Hey Carl,
>>> 
>>> So I dug into this more today and I have root caused what's exactly 
>>> happening here. 
>>> 
>>> The problematic code is this: 
>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 
>>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368>
>>> This is where the filename is set and the next line actually opens the 
>>> file. 
>>> 
>>> The logic for this hls_window method is the following:
>>> 
>>> 1. Make a new temporary file.
>>> 2. Write out a new HLS manifest header.
>>> 3. Loop through all available segments and write out all of the entries for 
>>> them.
>>> 4. Close the temporary file when finished.
>>> 5. Rename the temporary file to the target file name.
>>> 6. Rinse and repeat for every single fragment.
>>> 
>>> Therefore, if you can imagine a 153 hour audio file, we write out a totally 
>>> new HLS manifest 550800 times (153 * 60 * 60 assuming a 1s fragment 
>>> duration) that gets progressively larger as each fragment is generated.
>>> 
>>> This is a classic O(N^2) algorithm implementation, instead of:
>>> 
>>> 1. Creating the destination file up front & write the manifest header.
>>> 2. Append the new segment to the file.
>>> 3. If this is the last segment, write out EXT-X-ENDLIST.
>>> 
>>> There's no looping involved, nor the need to make temporary files.
>>> 
>>> FYI that I've noticed the same sort of pattern being applied to MPEG DASH: 
>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 
>>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786>
>>> 
>>> To implement something like this, looks like we'd have to significantly 
>>> re-engineer the code. Do you have any pointers on how to go about doing 
>>> this? Or, would you be able to help do this?
>>> 
>> 
>> I was thinking about this and I think it must have been implemented this way 
>> because of live hls streams? Not writing to the main manifest directly and 
>> keeping that stream open does release any file system locks that there would 
>> be otherwise. 
>> 
>> Is this the reason why this was done this way at all?
>> 
>> 
>>> Thanks for all your help,
>>> 
>>> Ronak
>>> 
>>>> On Jun 27, 2018, at 2:04 PM, Carl Zwanzig  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I haven't traced it out completely, but take a look at the flag 
>>>> HLS_TEMP_FILE in libavformat/hlsenc.c.
>>>> 
>>>> Later,
>>>> 
>>>> z!
>>> ___
>>> ffmpeg-user mailing list
>>> ffmpeg-u...@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>>> 
>>> To unsubscribe, visit link above, or email
>>> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
>> 
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-u...@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-user] fMP4 generation speed

[Ronak Patel]

I was wondering if anyone on the development list was familiar with this code 
and could provide pointers on how to fix up the code due to the below problem.


> On Jul 12, 2018, at 7:27 PM, Ronak Patel  
> wrote:
> 
> 
> 
>> On Jul 12, 2018, at 6:21 PM, Ronak Patel  
>> wrote:
>> 
>> Hey Carl,
>> 
>> So I dug into this more today and I have root caused what's exactly 
>> happening here. 
>> 
>> The problematic code is this: 
>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368 
>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c#L1368>
>> This is where the filename is set and the next line actually opens the file. 
>> 
>> The logic for this hls_window method is the following:
>> 
>> 1. Make a new temporary file.
>> 2. Write out a new HLS manifest header.
>> 3. Loop through all available segments and write out all of the entries for 
>> them.
>> 4. Close the temporary file when finished.
>> 5. Rename the temporary file to the target file name.
>> 6. Rinse and repeat for every single fragment.
>> 
>> Therefore, if you can imagine a 153 hour audio file, we write out a totally 
>> new HLS manifest 550800 times (153 * 60 * 60 assuming a 1s fragment 
>> duration) that gets progressively larger as each fragment is generated.
>> 
>> This is a classic O(N^2) algorithm implementation, instead of:
>> 
>> 1. Creating the destination file up front & write the manifest header.
>> 2. Append the new segment to the file.
>> 3. If this is the last segment, write out EXT-X-ENDLIST.
>> 
>> There's no looping involved, nor the need to make temporary files.
>> 
>> FYI that I've noticed the same sort of pattern being applied to MPEG DASH: 
>> https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786 
>> <https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/dashenc.c#L786>
>> 
>> To implement something like this, looks like we'd have to significantly 
>> re-engineer the code. Do you have any pointers on how to go about doing 
>> this? Or, would you be able to help do this?
>> 
> 
> I was thinking about this and I think it must have been implemented this way 
> because of live hls streams? Not writing to the main manifest directly and 
> keeping that stream open does release any file system locks that there would 
> be otherwise. 
> 
> Is this the reason why this was done this way at all?
> 
> 
>> Thanks for all your help,
>> 
>> Ronak
>> 
>>> On Jun 27, 2018, at 2:04 PM, Carl Zwanzig  wrote:
>>> 
>>> Hi,
>>> 
>>> I haven't traced it out completely, but take a look at the flag 
>>> HLS_TEMP_FILE in libavformat/hlsenc.c.
>>> 
>>> Later,
>>> 
>>> z!
>> ___
>> ffmpeg-user mailing list
>> ffmpeg-u...@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
>> 
>> To unsubscribe, visit link above, or email
>> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".
> 
> ___
> ffmpeg-user mailing list
> ffmpeg-u...@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> 
> To unsubscribe, visit link above, or email
> ffmpeg-user-requ...@ffmpeg.org with subject "unsubscribe".

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] fmp4 and HE-AACv2

[Ronak Patel]

Hi,

I was wondering if anyone more in the know about this can help fix this issue.

https://trac.ffmpeg.org/ticket/7282#comment:11

It’s preventing us from supporting adaptive Streaming between LCAAC and HEAAC.

Thanks

Ronak

Sent from my iPhone
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Atempo limits

[Ronak Patel]

We did consider rubberband, but the audio quality is too poor. The audio has 
echo artifacts in it that makes it sound robotic.

Sent from my iPhone

> On Jun 4, 2018, at 8:32 PM, Lou Logan  wrote:
> 
>> On Mon, Jun 4, 2018, at 10:09 AM, Ronak wrote:
>> 
>> We are looking to use the atempo filter for our audio files. However, 
>> the limit between 0.5 - 2x is too restrictive for us. We would like to 
>> expand the limit to 0.5x - 3x.
> 
> Consider using the rubberband filter instead if atempo is too simple or 
> restrictive.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Atempo limits

[Ronak Patel]

Thanks. Is it okay if I push a patch for this? How high of a limit does the 
algorithm support today?

Sent from my iPhone

> On Jun 4, 2018, at 8:00 PM, Pavel Koshevoy  wrote:
> 
>> On 06/04/2018 12:09 PM, Ronak wrote:
>> Hello,
>> 
>> How are you all?
>> 
>> We are looking to use the atempo filter for our audio files. However, the 
>> limit between 0.5 - 2x is too restrictive for us. We would like to expand 
>> the limit to 0.5x - 3x.
>> 
>> I tried changing the range in atempo.c and the rest of the tempo filter just 
>> worked.
>> 
> 
> Going below 0.5 is likely not going to sound good. Going above 2.0 should be 
> fine.  The reason for current [0.5, 2.0] range is mostly for symmetry. 
> atempo=0.5 followed by atempo=2.0 should sound like original audio.  This 
> should also point you to an alternative solution -- put 2 atempo filters one 
> after another to achieve tempo greater than 2  (atempo=2.0,atempo=1.5), or 
> like this:
> 
> ffmpeg -i /scratch/Music/02\ Feeling\ Good.mp3 -af 
> 'atempo=sqrt(3.0),atempo=sqrt(3.0)' -y /tmp/tempo-3x.wav
> 
>   Pavel.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] HLS Questions

[Ronak Patel]

No I’ll give it a try and let you know. 

Since this is just audio (no keyframes) I wouldn’t have thought this would have 
mattered.

Sent from my iPhone

> On May 7, 2018, at 3:52 PM, Aman Gupta  wrote:
> 
> On Wed, May 2, 2018 at 7:59 AM, Ronak Patel <
> ronak2121-at-yahoo@ffmpeg.org> wrote:
> 
>> Hi all,
>> 
>> So I’ve noticed that ffmpeg does not always properly follow the number we
>> specify for hls_time when generating hls content.
>> 
>> For example, if we have an MP4/AAC file at 44.1kHz sampling rate, we would
>> expect that specifying 9.75238095238095 (420 frames) would return a
>> manifest with the same exact amount of frames throughout.
>> Instead, we see the AAC encoder vary the amount of frames without any real
>> explanation.
>> 
> 
> Did you try -hls_flags split_by_time ?
> 
> Aman
> 
> 
>> 
>> When we run the following command:
>> 
>> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time
>> 9.75238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list
>> -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>> 
>> We get a manifest that looks like so:
>> 
>> #EXTM3U
>> #EXT-X-VERSION:7
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXT-X-PLAYLIST-TYPE:VOD
>> #EXT-X-MAP:URI="bk_acx0_006556_22_32_10sec_v7.m4s",BYTERANGE="738@0"
>> #EXT-X-DISCONTINUITY
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38733@738
>> bk_acx0_006556_22_32_10sec_v7.m4s
>> #EXTINF:9.752381,
>> #EXT-X-BYTERANGE:38531@39471
>> bk_acx0_006556_22_32_10sec_v7.m4s
>> #EXTINF:9.752381,
>> #EXT-X-BYTERANGE:38616@78002
>> bk_acx0_006556_22_32_10sec_v7.m4s
>> #EXTINF:9.752381,
>> #EXT-X-BYTERANGE:38545@116618
>> bk_acx0_006556_22_32_10sec_v7.m4s
>> 
>> Notice the first segment there contains 2 more AAC frames...
>> 
>> Now, when we run the following command:
>> 
>> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time
>> 0.975238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list
>> -hls_playlist_type vod "${FILE}_10sec_v7.m3u8"
>> 
>> #EXTM3U
>> #EXT-X-VERSION:7
>> #EXT-X-TARGETDURATION:1
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXT-X-PLAYLIST-TYPE:VOD
>> #EXT-X-MAP:URI="bk_reco_004353_22_32_1sec_v7.m4s",BYTERANGE="738@0"
>> #EXT-X-DISCONTINUITY
>> #EXTINF:0.975238,
>> #EXT-X-BYTERANGE:4110@738
>> bk_reco_004353_22_32_1sec_v7.m4s
>> #EXTINF:0.975238,
>> #EXT-X-BYTERANGE:3897@4848
>> bk_reco_004353_22_32_1sec_v7.m4s
>> #EXTINF:0.975238,
>> #EXT-X-BYTERANGE:4236@8745
>> bk_reco_004353_22_32_1sec_v7.m4s
>> #EXTINF:0.975238,
>> 
>> It seems to have the correct amount of frames everywhere.
>> 
>> Even more bizarre is if we run this command:
>> 
>> /home/ronakp/bin/ffmpeg -i "../${FILE}.mp4" -codec copy -hls_time
>> 9.75238095238095 -hls_segment_filename 'file%03d.ts' -hls_segment_type
>> mpegts -hls_playlist_type vod "${FILE}_10sec_v3.m3u8"
>> 
>> The manifest looks like the following:
>> 
>> #EXTM3U
>> #EXT-X-VERSION:3
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:0
>> #EXT-X-PLAYLIST-TYPE:VOD
>> #EXTINF:9.799778,
>> file000.ts
>> #EXTINF:9.706889,
>> file001.ts
>> #EXTINF:9.75,
>> file002.ts
>> #EXTINF:9.799778,
>> file003.ts
>> #EXTINF:9.75,
>> file004.ts
>> #EXTINF:9.706889,
>> file005.ts
>> #EXTINF:9.799778,
>> file006.ts
>> 
>> The ts segments do not all have the same size, and seems like ffmpeg is
>> unable to properly honor the supplied time.
>> 
>> And finally, when I run the following command:
>> 
>> /home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -f dash
>> -single_file_name "${FILE}_1sec.m4s" -min_seg_duration 975238.095238095
>> -hls_playlist 1 "${FILE}_1sec.mpd"
>> 
>> I get a manifest that looks like:
>> 
>> #EXTM3U
>> #EXT-X-VERSION:6
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:1
>> #EXT-X-MAP:URI="bk_reco_004353_22_32_10sec.m4s",BYTERANGE="738@0"
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38996@738
>> bk_reco_004353_22_32_10sec.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38754@39734
>> bk_reco_004353_22_32_10sec.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38765@78488
>> bk_reco_004353_22_32_10sec.m4s
>> #EXTINF:9.798821,
>>

[FFmpeg-devel] HLS Questions

[Ronak Patel]

Hi all,

So I’ve noticed that ffmpeg does not always properly follow the number we 
specify for hls_time when generating hls content.

For example, if we have an MP4/AAC file at 44.1kHz sampling rate, we would 
expect that specifying 9.75238095238095 (420 frames) would return a manifest 
with the same exact amount of frames throughout.
Instead, we see the AAC encoder vary the amount of frames without any real 
explanation.

When we run the following command:

/home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time 9.75238095238095 
-hls_segment_type fmp4 -hls_flags single_file+append_list -hls_playlist_type 
vod "${FILE}_10sec_v7.m3u8"

We get a manifest that looks like so:

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="bk_acx0_006556_22_32_10sec_v7.m4s",BYTERANGE="738@0"
#EXT-X-DISCONTINUITY
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38733@738
bk_acx0_006556_22_32_10sec_v7.m4s
#EXTINF:9.752381,
#EXT-X-BYTERANGE:38531@39471
bk_acx0_006556_22_32_10sec_v7.m4s
#EXTINF:9.752381,
#EXT-X-BYTERANGE:38616@78002
bk_acx0_006556_22_32_10sec_v7.m4s
#EXTINF:9.752381,
#EXT-X-BYTERANGE:38545@116618
bk_acx0_006556_22_32_10sec_v7.m4s

Notice the first segment there contains 2 more AAC frames...

Now, when we run the following command:

/home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -hls_time 
0.975238095238095 -hls_segment_type fmp4 -hls_flags single_file+append_list 
-hls_playlist_type vod "${FILE}_10sec_v7.m3u8"

#EXTM3U
#EXT-X-VERSION:7
#EXT-X-TARGETDURATION:1
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXT-X-MAP:URI="bk_reco_004353_22_32_1sec_v7.m4s",BYTERANGE="738@0"
#EXT-X-DISCONTINUITY
#EXTINF:0.975238,
#EXT-X-BYTERANGE:4110@738
bk_reco_004353_22_32_1sec_v7.m4s
#EXTINF:0.975238,
#EXT-X-BYTERANGE:3897@4848
bk_reco_004353_22_32_1sec_v7.m4s
#EXTINF:0.975238,
#EXT-X-BYTERANGE:4236@8745
bk_reco_004353_22_32_1sec_v7.m4s
#EXTINF:0.975238,

It seems to have the correct amount of frames everywhere.

Even more bizarre is if we run this command:

/home/ronakp/bin/ffmpeg -i "../${FILE}.mp4" -codec copy -hls_time 
9.75238095238095 -hls_segment_filename 'file%03d.ts' -hls_segment_type mpegts 
-hls_playlist_type vod "${FILE}_10sec_v3.m3u8"

The manifest looks like the following:

#EXTM3U
#EXT-X-VERSION:3
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:0
#EXT-X-PLAYLIST-TYPE:VOD
#EXTINF:9.799778,
file000.ts
#EXTINF:9.706889,
file001.ts
#EXTINF:9.75,
file002.ts
#EXTINF:9.799778,
file003.ts
#EXTINF:9.75,
file004.ts
#EXTINF:9.706889,
file005.ts
#EXTINF:9.799778,
file006.ts

The ts segments do not all have the same size, and seems like ffmpeg is unable 
to properly honor the supplied time.

And finally, when I run the following command:

/home/ronakp/bin/ffmpeg -i "${FILE}.mp4" -codec copy -f dash -single_file_name 
"${FILE}_1sec.m4s" -min_seg_duration 975238.095238095 -hls_playlist 1 
"${FILE}_1sec.mpd"

I get a manifest that looks like:

#EXTM3U
#EXT-X-VERSION:6
#EXT-X-TARGETDURATION:10
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-MAP:URI="bk_reco_004353_22_32_10sec.m4s",BYTERANGE="738@0"
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38996@738
bk_reco_004353_22_32_10sec.m4s
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38754@39734
bk_reco_004353_22_32_10sec.m4s
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38765@78488
bk_reco_004353_22_32_10sec.m4s
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38583@117253
bk_reco_004353_22_32_10sec.m4s
#EXTINF:9.798821,
#EXT-X-BYTERANGE:38752@155836
bk_reco_004353_22_32_10sec.m4s

Where every fragment has 1 extra frame in it.

Can someone please help get this fixed? The fragmentation should have been 
uniform throughout and exactly the same no matter which options I specify here.

For reference, I'm using the following versions of ffmpeg:

ffmpeg version N-90757-g2fc12f4 Copyright (c) 2000-2018 the FFmpeg developers
  built with gcc 4.4.6 (GCC) 20110731 (Red Hat 4.4.6-3)
  configuration: --prefix=/home/ronakp/ffmpeg_build --pkg-config-flags=--static 
--extra-cflags=-I/home/ronakp/ffmpeg_build/include 
--extra-ldflags=-L/home/ronakp/ffmpeg_build/lib --extra-libs=-lpthread 
--extra-libs=-lm --bindir=/home/ronakp/bin --enable-gpl --enable-avisynth 
--enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libvorbis 
--enable-nonfree --enable-libvorbis --enable-version3 --disable-ffplay
  libavutil  56. 15.100 / 56. 15.100
  libavcodec 58. 19.100 / 58. 19.100
  libavformat58. 13.100 / 58. 13.100
  libavdevice58.  4.100 / 58.  4.100
  libavfilter 7. 18.100 /  7. 18.100
  libswscale  5.  2.100 /  5.  2.100
  libswresample   3.  2.100 /  3.  2.100
  libpostproc55.  2.100 / 55.  2.100

Thanks,

Ronak

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/dashenc: change the hls version from 6 to 7

[Ronak Patel]

Awesome guys thanks for the fix! That was fast!

Sent from my iPhone

> On Apr 19, 2018, at 11:41 PM, Jeyapal, Karthick  wrote:
> 
> 
> 
>> On 4/20/18 9:02 AM, Steven Liu wrote:
>> reference hls support fmp4 file from  draft-pantos-http-live-streaming-20
>> the spec describes version 7 of hls protocol
>> 
>> Suggested-by: Ronak 
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/dashenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 9e72636f0e..fefe3ce0ca 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -827,7 +827,7 @@ static int write_manifest(AVFormatContext *s, int final)
>> }
>> av_dict_free(&opts);
>> 
>> -ff_hls_write_playlist_version(out, 6);
>> +ff_hls_write_playlist_version(out, 7);
>> 
>> for (i = 0; i < s->nb_streams; i++) {
>> char playlist_file[64];
> LGTM. Thanks for the fix.
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] HLS Segmenting/Fragmentation Questions

[Ronak Patel]

Hey guys,

So I think this may be my own lack of knowledge in the encoder.

Because we were specifying -b:a 32k in our encoding step, I thought the byte 
ranges should align properly, but I’ve since learned that is incorrect.

The compression is still variable in terms of bytes.

Therefore this is correct.

I did see other issues that I’ll send a separate email about.

Thanks

Ronak

Sent from my iPhone

> On Apr 19, 2018, at 11:47 PM, Jeyapal, Karthick  wrote:
> 
> 
> 
>> On 4/20/18 2:20 AM, Ronak wrote:
>> Hi,
>> 
>> I've been testing FFMPEG's HLS fragmented MP4 options with some M4A audio 
>> files.
>> 
>> I've noticed that if I ask ffmpeg to fragment an 11 minute file vs a 10 hour 
>> file, the byte ranges are different, even if the channel count/sampling 
>> rate/bit rate and codec are the same.
>> 
>> Here's an example of what I'm talking about:
>> 
>> #EXTM3U
>> #EXT-X-VERSION:6
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:1
>> #EXT-X-MAP:URI="someAudio.m4s",BYTERANGE="738@0"
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38977@738
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38735@39715
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38650@78450
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38688@117100
>> someAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38820@155788
>> someAudio.m4s
>> 
>> And 
>> 
>> #EXTM3U
>> #EXT-X-VERSION:6
>> #EXT-X-TARGETDURATION:10
>> #EXT-X-MEDIA-SEQUENCE:1
>> #EXT-X-MAP:URI="someOtherAudio.m4s",BYTERANGE="738@0"
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38724@738
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38812@39462
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38632@78274
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38804@116906
>> someOtherAudio.m4s
>> #EXTINF:9.798821,
>> #EXT-X-BYTERANGE:38720@155710
>> someOtherAudio.m4s
>> 
>> Why would these byte ranges be different? I've been trying to look through 
>> the libavformat source code 
>> (https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/hlsenc.c 
>> ) but it 
>> looks like this determination is done in whoever calls hls_write_packet.
> Yes, you are right. It is determined by the AV encoder(say AAC encoder in 
> your case). HLS segmenter will just cut at the segment boundaries and it 
> doesn't worry about the number of bytes that are present in that segment.
>> 
>> Thanks,
>> 
>> Ronak
>> 
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel