Re: [FFmpeg-devel] [PATCH] avfilter/f_loop: do not loop if loop size is 0
2019.05.20. 7:02 keltezéssel, Gyan írta:
On 20-05-2019 02:18 AM, Marton Balint wrote:
On Sun, 19 May 2019, Paul B Mahol wrote:
On 5/19/19, Marton Balint wrote:
On Sun, 19 May 2019, Paul B Mahol wrote:
On 5/19/19, Marton Balint wrote:
Fixes infinte loop with -vf loop=loop=1.
Possible regression since ef1aadffc785b48ed62c45d954289e754f43ef46.
Signed-off-by: Marton Balint
---
libavfilter/f_loop.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/f_loop.c b/libavfilter/f_loop.c
index d9d55f9837..3da753dd1e 100644
--- a/libavfilter/f_loop.c
+++ b/libavfilter/f_loop.c
@@ -343,7 +343,7 @@ static int activate(AVFilterContext *ctx)
FF_FILTER_FORWARD_STATUS_BACK(outlink, inlink);
- if (!s->eof && (s->nb_frames < s->size || !s->loop)) {
+ if (!s->eof && (s->nb_frames < s->size || !s->loop ||
!s->size)) {
ret = ff_inlink_consume_frame(inlink, &frame);
if (ret < 0)
return ret;
--
2.16.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
I think better fix is to change default and minimal allowed loop
size to
1.
Does that sounds ok to you?
Well, looping the whole length of the input would be more intuitive
to me
as the default.
That would require infinite memory.
So as the reverse filter. As long as it is properly documented that
the looped stuff is kept in memory so the user should not use this
for long clips, then I think it is fine.
I disagree. Yes, for loop with only loop specified, it would be
intuitive to loop the whole stream, but relying on users to exercise
due diligence can't be counted upon. We're talking about a scenario
where the user hasn't bothered to specify the size variable because
they don't know or don't care or are sloppy. They won't take heed of
the documentation until the command fails. The defaults should be
robust against lax use.
just an idea. What about to have no-default value for loop length/size
at all? I mean to let the size as mandatory parameter?
bb
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] av_format/hlsenc: fix %v handling by format_name function
Hi All,
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the
input pattern buffer, so you must allocate it before calling format_name
function. It also means, that it is silently assumed that the result
string will NOT be
longer that the pattern string. It is true most of the time, because %v
may appear only once in the pattern string and number of variant streams
is less than 100 in practical cases. But theoretically it will fail if
specified number of variant streams is greater than 100 (i.e. longer
than 2 digits).
This patch fixes this behaviour by altering format_name function to
allocate the
result buffer and return it to the caller.
Please, review this patch.
best,
Bela
>From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 17 Jun 2019 14:31:36 +0200
Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Most of %v handlng is done in format_name function. Currently
in this function the result buffer is the same as the input pattern
buffer, so you must allocate it before calling format_name function. It
also means, that it is silently assumed that the result string will NOT
be longer that the pattern string. It is true most of the time, because
%v may appear only once in the pattern string and number of variant
streams is less than 100 in practical cases. But theoretically it will
fail if specified number of variant streams is greater than 100. This
patch fixes this behaviour by altering format_name function to allocate
the result buffer and return it to the caller.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9884f74d51..ebe1ab62e5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1761,33 +1761,34 @@ fail:
return ret;
}
-static int format_name(char *buf, int buf_len, int index)
+static int format_name(const char *buf, char **s, int index)
{
const char *proto, *dir;
-char *orig_buf_dup = NULL, *mod_buf = NULL, *mod_buf_dup = NULL;
+char *orig_buf_dup = NULL, *mod_buf_dup = NULL;
int ret = 0;
-if (!av_stristr(buf, "%v"))
-return ret;
-
orig_buf_dup = av_strdup(buf);
if (!orig_buf_dup) {
ret = AVERROR(ENOMEM);
goto fail;
}
-if (replace_int_data_in_filename(&mod_buf, orig_buf_dup, 'v', index) < 1) {
+if (!av_stristr(buf, "%v")) {
+*s = orig_buf_dup;
+return ret;
+}
+
+if (replace_int_data_in_filename(s, orig_buf_dup, 'v', index) < 1) {
ret = AVERROR(EINVAL);
goto fail;
}
-av_strlcpy(buf, mod_buf, buf_len);
proto = avio_find_protocol_name(orig_buf_dup);
dir = av_dirname(orig_buf_dup);
/* if %v is present in the file's directory, create sub-directory */
if (av_stristr(dir, "%v") && proto && !strcmp(proto, "file")) {
-mod_buf_dup = av_strdup(buf);
+mod_buf_dup = av_strdup(*s);
if (!mod_buf_dup) {
ret = AVERROR(ENOMEM);
goto fail;
@@ -1803,7 +1804,6 @@ static int format_name(char *buf, int buf_len, int index)
fail:
av_freep(&orig_buf_dup);
av_freep(&mod_buf_dup);
-av_freep(&mod_buf);
return ret;
}
@@ -2634,7 +2634,7 @@ static int hls_init(AVFormatContext *s)
ret = AVERROR(ENOMEM);
goto fail;
}
-ret = format_name(vs->m3u8_name, strlen(s->url) + 1, i);
+ret = format_name(s->url, i, vs->m3u8_name);
if (ret < 0)
goto fail;
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: enhanced %v handling with variant names
Dear All,
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Currently %v is substituted by its variant index value (0, 1, 2
etc.). In some use cases it would be handy to specify names for variants
instead of numerical indexes. This patch makes it possible to use names
instead of default indexes. In var_stream_map option each or some of the
variant streams may use an optional name attributum (e.g.
-var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is
specified for a variant, then this name value will be used as
substitution value of %v instead of the default index value.
example:
ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
-map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map
"v:0,a:0,name:my_hd v:1,a:1,name:mysd" \
http://example.com/live/out_%v.m3u8
This example creates two hls variant streams, the two output media playlist
with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created.
Please review this patch.
best regards,
Bela
>From 690670d8c66fce71662292b44b9927a7f46917b5 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Tue, 18 Jun 2019 22:44:49 +0200
Subject: [PATCH] avformat/hlsenc: enhanced %v handling with variant names
When multiple variant streams are specified by var_stream_map option, %v
placeholder in various names ensures that each variant has its unique
names. Currently %v is substituted by its variant index value (0, 1, 2
etc.). In some use cases it would be handy to specify names for variants
instead of numerical indexes. This patch makes it possible to use names
instead of default indexes. In var_stream_map option each or some of the
variant streams may use an optional name attributum (e.g.
-var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is
specified for a variant, then this name value will be used as
substitution value of %v instead of the default index value.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 16 +++-
libavformat/hlsenc.c | 95 +---
2 files changed, 95 insertions(+), 16 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 50147c4d20..8370b6dc2e 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -943,7 +943,21 @@ This example creates two hls variant streams. The first
variant stream will
contain video stream of bitrate 1000k and audio stream of bitrate 64k and the
second variant stream will contain video stream of bitrate 256k and audio
stream of bitrate 32k. Here, two media playlist with file names out_0.m3u8 and
-out_1.m3u8 will be created.
+out_1.m3u8 will be created. If you want something meaningful text instead of
indexes
+in result names, you may specify names for each or some of the variants
+as in the following example.
+
+
+@example
+ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \
+ -map 0:v -map 0:a -map 0:v -map 0:a -f hls -var_stream_map
"v:0,a:0,name:my_hd v:1,a:1,name:mysd" \
+ http://example.com/live/out_%v.m3u8
+@end example
+
+This example creates two hls variant streams as in the previous one.
+But here, the two media playlist with file names out_my_hd.m3u8 and
+out_mysd.m3u8 will be created.
+
@example
ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k \
-map 0:v -map 0:a -map 0:v -f hls -var_stream_map "v:0 a:0 v:1" \
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 6d00a70041..f88b8a9618 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -164,6 +164,7 @@ typedef struct VariantStream {
char *agroup; /* audio group name */
char *ccgroup; /* closed caption group name */
char *baseurl;
+char *varname; // variant name
} VariantStream;
typedef struct ClosedCaptionsStream {
@@ -340,6 +341,47 @@ fail:
return;
}
+static int replace_str_data_in_filename(char **s, const char *filename, char
placeholder, const char *datastring)
+{
+const char *p;
+char *new_filename;
+char c;
+int addchar_count;
+int found_count = 0;
+AVBPrint buf;
+
+av_bprint_init(&buf, 0, AV_BPRINT_SIZE_UNLIMITED);
+
+p = filename;
+for (;;) {
+c = *p;
+if (c == '\0')
+break;
+if (c == '%' && *(p+1) == '%') // %%
+addchar_count = 2;
+else if (c == '%' && *(p+1) == placeholder) {
+av_bprintf(&buf, "%s", datastring);
+p += 2;
+addchar_count = 0;
+found_count ++;
+} else
+addchar_count = 1;
+
+if (addchar_count > 0) {
+av_bprint_append_data(&buf, p, addchar_count);
+p += addchar_count;
+}
+}
+if (!av_bprint_is_complete(&buf)) {
+av_bprint_finalize(&buf, NULL);
+return -1;
+}
+if (av_bprint_finalize(&buf, &new_filename) < 0 || !new_filename)
+return -1;
+*s = new_filename;
+return found_count;
+}
+
static
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: enhanced %v handling with variant names
this patch assumes/requires my previous patch to be applied 2019 jun 17 [PATCH] av_format/hlsenc: fix %v handling by format_name function best, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: enhanced %v handling with variant names
2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: Dear All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. example: ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ http://example.com/live/out_%v.m3u8 This example creates two hls variant streams, the two output media playlist with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. Please review this patch. best regards, maybe i made a mistake but this seems not to apply Applying: avformat/hlsenc: enhanced %v handling with variant names error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] I think it relates to the fact - as I mentioned my other post - that I created two related patches and I send them into the list as unrelated patches. I will wait for my earlier patch to be applied and then I reissue this patch again. best, bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: enhanced %v handling with variant names
2019.06.19. 12:17 keltezéssel, Liu Steven írta: 在 2019年6月19日，下午6:00，Bodecs Bela 写道： 2019.06.19. 11:37 keltezéssel, Michael Niedermayer írta: On Tue, Jun 18, 2019 at 11:09:12PM +0200, Bodecs Bela wrote: Dear All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. example: ffmpeg -re -i in.ts -b:v:0 1000k -b:v:1 256k -b:a:0 64k -b:a:1 32k \ -map 0:v:0 -map 0:a:0 -map 0:v:1 -map 0:a:1 -f hls -var_stream_map "v:0,a:0,name:my_hd v:1,a:1,name:mysd" \ http://example.com/live/out_%v.m3u8 This example creates two hls variant streams, the two output media playlist with file names out_my_hd.m3u8 and out_mysd.m3u8 will be created. Please review this patch. best regards, maybe i made a mistake but this seems not to apply Applying: avformat/hlsenc: enhanced %v handling with variant names error: sha1 information is lacking or useless (libavformat/hlsenc.c). error: could not build fake ancestor Patch failed at 0001 avformat/hlsenc: enhanced %v handling with variant names hint: Use 'git am --show-current-patch' to see the failed patch When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". [...] I think it relates to the fact - as I mentioned my other post - that I created two related patches and I send them into the list as unrelated patches. I will wait for my earlier patch to be applied and then I reissue this patch again. I have pushed the first patch, and this patch cannot be merged: muhanmoeMacBook:ffmpeg StevenLiu$ git am ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch fatal: previous rebase directory .git/rebase-apply still exists but mbox given. muhanmoeMacBook:ffmpeg StevenLiu$ patch -p1 < ~/Downloads/0001-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch (Stripping trailing CRs from patch.) patching file doc/muxers.texi (Stripping trailing CRs from patch.) patching file libavformat/hlsenc.c Hunk #8 FAILED at 2693. Hunk #9 FAILED at 2754. Hunk #10 FAILED at 2811. Hunk #11 FAILED at 2876. Hunk #12 succeeded at 2938 (offset 11 lines). 4 out of 12 hunks FAILED -- saving rejects to file libavformat/hlsenc.c.rej muhanmoeMacBook:ffmpeg StevenLiu$ best, bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". I have created the patch again to the current head. Please try it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". From 3e9f4cb98420a7edb6517281c125975c16f185b9 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Wed, 19 Jun 2019 15:05:25 +0200 Subject: [PATCH] avformat/hlsenc: enhanced %v handling with variant names When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Currently %v is substituted by its variant index value (0, 1, 2 etc.). In some use cases it would be handy to specify names for variants instead of numerical indexes. This patch makes it possible to use names instead of default indexes. In var_stream_map option each or some of the variant streams may use an optional name attributum (e.g. -var_stream_map "v:0,a:0,name:sd v:1,a:1,name:720p") If a name is specified for a variant, then this name value will be used as substitution value of %v instead of the default index value. Signed-off-by: Bela Bodecs --- doc/muxers.texi | 16 ++- libavformat/hlsenc.c | 110 +++ 2 files changed, 96 insertions(+), 30 deletions(-) diff --git a/doc/muxers.texi b/doc/muxers.texi index 50147c4d20..
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Are you sure, you have applied my patch file? Because in the patch the first error should not have been: - ret = format_name(s->url, i, vs->m3u8_name); + ret = format_name(s->url, &vs->m3u8_name, i, vs->varname); bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing li
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Dear Michael, thank you for review my patch. This patch requires one of my earlier other patch to be applied. Steven Liu applied that earlier patch very shortly before you tested this patch. Maybe you applied this patch against an earlier head than Seven Liu applied the necessary patch? I have tested the current head with my sent public patch file without any problem. The commands I have used at 2019jun19 22:40 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg git apply --stat 0003-avformat-hlsenc-enhanced-v-handling-with-variant-nam.patch git apply --check 0003-av
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.19. 23:49 keltezéssel, Bodecs Bela írta: 2019.06.19. 19:37 keltezéssel, Michael Niedermayer írta: On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela >From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] Dear Michael, thank you for review my patch. This patch requires one of my earlier other patch to be applied. Steven Liu applied that earlier patch very shortly before you tested this patch. Maybe you applied this patch against an earlier head than Seven Liu applied the necessary patch? I have tested the current head with my sent public patch file without any problem. The commands I have used at 2019jun19 22:40 git clone https://git.ffmpeg.org/ffmpeg.git ffmpeg cd ffmpeg git apply --stat 0003-av
Re: [FFmpeg-devel] [FFmpeg-cvslog] av_format/hlsenc: fix %v handling by format_name function
2019.06.20. 5:11 keltezéssel, Liu Steven írta: 在 2019年6月20日，上午1:37，Michael Niedermayer 写道： On Wed, Jun 19, 2019 at 10:03:51AM +, Bodecs Bela wrote: ffmpeg | branch: master | Bodecs Bela | Mon Jun 17 23:05:21 2019 +0200| [09a4853930e7950f423e9161004871afe659ed84] | committer: Steven Liu av_format/hlsenc: fix %v handling by format_name function Hi All, When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100 (i.e. longer than 2 digits). This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Please, review this patch. best, Bela From 6377ebee8a106a9684d41b270c7d6c8e57cd3e7b Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Mon, 17 Jun 2019 14:31:36 +0200 Subject: [PATCH] av_format/hlsenc: fix %v handling by format_name function When multiple variant streams are specified by var_stream_map option, %v placeholder in various names ensures that each variant has its unique names. Most of %v handlng is done in format_name function. Currently in this function the result buffer is the same as the input pattern buffer, so you must allocate it before calling format_name function. It also means, that it is silently assumed that the result string will NOT be longer that the pattern string. It is true most of the time, because %v may appear only once in the pattern string and number of variant streams is less than 100 in practical cases. But theoretically it will fail if specified number of variant streams is greater than 100. This patch fixes this behaviour by altering format_name function to allocate the result buffer and return it to the caller. Signed-off-by: Bela Bodecs This broke fate (segfaults) also it produces new compiler warnings which probably are pointing to the cause libavformat/hlsenc.c: In function ‘hls_init’: libavformat/hlsenc.c:2643:9: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2643:9: warning: passing argument 3 of ‘format_name’ makes integer from pointer without a cast [enabled by default] ret = format_name(s->url, i, vs->m3u8_name); ^ libavformat/hlsenc.c:1764:12: note: expected ‘int’ but argument is of type ‘char *’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2712:13: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->basename, basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2767:25: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] format_name(vs->fmp4_init_filename, fmp4_init_filename_len, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) ^ libavformat/hlsenc.c:2832:17: warning: passing argument 2 of ‘format_name’ makes pointer from integer without a cast [enabled by default] ret = format_name(vs->vtt_m3u8_name, vtt_basename_size, i); ^ libavformat/hlsenc.c:1764:12: note: expected ‘char **’ but argument is of type ‘int’ static int format_name(const char *buf, char **s, int index) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe”. Fixed after mer
[FFmpeg-devel] [PATCH] avformat/hlsenc: better checking var_stream_map content
Dear All,
When multiple variant streams are specified by var_stream_map option,
implementation assumes that each elementary stream is assigned only once
to any variant. But this is not checked currently. But 2nd and further
instances
of same elementary source streams are silently neglected without any notice.
Examples for invalid var_stream_map content:
"v:0,a:0 v:1,a:0"
This is invalid because 1st and 2nd variant also contains a:0 source
"v:0,a:0,v:0 v:1,a:1"
This is invalid because 1st variant source contains v:0 twice.
This patch makes this checking early, during the var_stream_map parsing
phase.
please review this patch.
best
Bela
>From 902cae77b8f7f45634d949cba25bc82ff75653a8 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Wed, 19 Jun 2019 10:25:36 +0200
Subject: [PATCH] avformat/hlsenc: better checking var_stream_map content
When multiple variant streams are specified by var_stream_map option,
implementation assumes that each elementary stream is assigned only once
to any variant. But this is not checked. This patch makes this checking.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f88b8a9618..77f84dd547 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1887,7 +1887,7 @@ static int parse_variant_stream_mapstring(AVFormatContext
*s)
{
HLSContext *hls = s->priv_data;
VariantStream *vs;
-int stream_index;
+int stream_index, i, j;
enum AVMediaType codec_type;
int nb_varstreams, nb_streams;
char *p, *q, *saveptr1, *saveptr2, *varstr, *keyval;
@@ -1989,6 +1989,23 @@ static int
parse_variant_stream_mapstring(AVFormatContext *s)
atoi(val));
if (stream_index >= 0 && nb_streams < vs->nb_streams) {
+for(i = 0; nb_streams > 0 && i < nb_streams; i++) {
+if (vs->streams[i] == s->streams[stream_index]) {
+av_log(s, AV_LOG_ERROR, "Same elementary stream found
more than once inside "
+ "variant definition #%d\n", nb_varstreams - 1);
+return AVERROR(EINVAL);
+}
+}
+for(j = 0; nb_varstreams > 1 && j < nb_varstreams - 1; j++) {
+for(i = 0; i < hls->var_streams[j].nb_streams; i++) {
+if (hls->var_streams[j].streams[i] ==
s->streams[stream_index]) {
+av_log(s, AV_LOG_ERROR, "Same elementary stream
found more than once "
+ "in two different variant definitions #%d
and #%d\n",
+ j, nb_varstreams - 1);
+return AVERROR(EINVAL);
+}
+}
+}
vs->streams[nb_streams++] = s->streams[stream_index];
} else {
av_log(s, AV_LOG_ERROR, "Unable to map stream at %s\n",
keyval);
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: better error log message for var_stream_map content
Dear All,
When multiple variant streams are specified by var_stream_map option,
%v is expected either in the filename or in the last sub-directory name,
but only in one of them. When both of them contain %v string, current
error message only states half of the "truth".
Additionally %v may appears several times inside the last sub-directory name
or in filename pattern.
This patch clarifies this in the log message and in the doc also.
please review this patch.
best
Bela
>From d30e63edefc69a057d8157151b307600dc6383f3 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sat, 22 Jun 2019 15:55:54 +0200
Subject: [PATCH] avformat/hlsenc: better error log message for var_stream_map
content
When multiple variant streams are specified by var_stream_map option,
%v is expected either in the filename or in the last sub-directory name,
but only in one of them. When both of them contains %v string, current
error message only states half of the truth.
And even %v may appears several times inside the last sub-directory name
or in filename pattern.
This patch clarifies this in the log message and in the doc also.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 3 ++-
libavformat/hlsenc.c | 8
2 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4410a5f5bb..6c5b4bb637 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -656,7 +656,8 @@ This example will produce the playlists segment file sets:
@file{file_1_000.ts}, @file{file_1_001.ts}, @file{file_1_002.ts}, etc.
The string "%v" may be present in the filename or in the last directory name
-containing the file. If the string is present in the directory name, then
+containing the file, but only in one of them. (Additionally, %v may appear
multiple times in the last
+sub-directory or filename.) If the string %v is present in the directory name,
then
sub-directories are created after expanding the directory name pattern. This
enables creation of segments corresponding to different variant streams in
subdirectories.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f6330ec2d5..9f5eee5491 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1792,15 +1792,15 @@ static int validate_name(int nb_vs, const char *fn)
subdir_name = av_dirname(fn_dup);
if (nb_vs > 1 && !av_stristr(filename, "%v") && !av_stristr(subdir_name,
"%v")) {
-av_log(NULL, AV_LOG_ERROR, "More than 1 variant streams are present,
%%v is expected in the filename %s\n",
-fn);
+av_log(NULL, AV_LOG_ERROR, "More than 1 variant streams are present,
%%v is expected "
+ "either in the filename or in the sub-directory name of file
%s\n", fn);
ret = AVERROR(EINVAL);
goto fail;
}
if (av_stristr(filename, "%v") && av_stristr(subdir_name, "%v")) {
-av_log(NULL, AV_LOG_ERROR, "%%v is expected either in filename or in
the sub-directory name of file %s\n",
-fn);
+av_log(NULL, AV_LOG_ERROR, "%%v is expected either in the filename or "
+ "in the sub-directory name of file %s, but only in one of
them\n", fn);
ret = AVERROR(EINVAL);
goto fail;
}
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 4.2
+1 vote Ada 2019.06.23. 13:02 keltezéssel, Reto Kromer írta: FFMPEG 4.2 PANDORA? FFmpeg 4.2 CARLS CANS Ada (She deserves much better than that horrible programming language!) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt playlist
Dear All,
currently master playlist and subtitle playlist creation does not use
temporary files even when temp_file flag is set. Most of the use cases
it is not a problem because master playlist creation happens once on the
beginning of the whole process. But if master playlist is periodically
re-created because of master_pl_refresh_rate is set, non-atomic playlist
creation may cause problems in case of live streaming. This poblem (i.e
non-atomic playlist
creation) may also apply for subtitle playlist (vtt) creation in live
streaming.
This patch correct this behavior by adding missing functionality.
please review this patch.
thank you in advance,
best regards,
Bela
>From 04e70ba586646b927e1b05a9df3860a635871603 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 24 Jun 2019 17:41:49 +0200
Subject: [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt
playlist
currently master playlist and subtitle playlist creation does not use
temporary files even when temp_file flag is set. Most of the use cases
it is not a problem because master playlist creation happens once on the
beginning of the whole process. But if master playlist is periodically
re-created because of master_pl_refresh_rate is set, non-atomic playlist
creation may cause problems in case of live streaming. This patch
correct this behavior by adding this functionality.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 6 +-
libavformat/hlsenc.c | 30 +-
2 files changed, 26 insertions(+), 10 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 6c5b4bb637..d969e39fff 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -893,7 +893,11 @@ This will produce segments like this:
@item temp_file
Write segment data to filename.tmp and rename to filename only once the
segment is complete. A webserver
serving up segments can be configured to reject requests to *.tmp to prevent
access to in-progress segments
-before they have been added to the m3u8 playlist.
+before they have been added to the m3u8 playlist. This flag also affects how
m3u8 playlist files are created.
+If this flag is set, all playlist files will written into temporary file and
renamed after they are complete, similarly as segments are handled.
+But playlists with @code{file} protocol and with type
(@code{hls_playlist_type}) other than @code{vod}
+are always written into temporary file regardles of this flag. Master playlist
files (@code{master_pl_name}), if any, with @code{file} protocol,
+are always written into temporary file regardles of this flag if
@code{master_pl_publish_rate} value is other than zero.
@end table
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 9f5eee5491..eaeafcbb6b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1260,8 +1260,12 @@ static int create_master_playlist(AVFormatContext *s,
AVDictionary *options = NULL;
unsigned int i, j;
int m3u8_name_size, ret, bandwidth;
-char *m3u8_rel_name, *ccgroup;
+char *m3u8_rel_name = NULL, *ccgroup;
ClosedCaptionsStream *ccs;
+const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
+int is_file_proto = proto && !strcmp(proto, "file");
+int use_temp_file = is_file_proto && ((hls->flags & HLS_TEMP_FILE) ||
hls->master_publish_rate);
+char temp_filename[1024];
input_vs->m3u8_created = 1;
if (!hls->master_m3u8_created) {
@@ -1277,12 +1281,12 @@ static int create_master_playlist(AVFormatContext *s,
}
set_http_options(s, &options, hls);
-
-ret = hlsenc_io_open(s, &hls->m3u8_out, hls->master_m3u8_url, &options);
+snprintf(temp_filename, sizeof(temp_filename), use_temp_file ? "%s.tmp" :
"%s", hls->master_m3u8_url);
+ret = hlsenc_io_open(s, &hls->m3u8_out, temp_filename, &options);
av_dict_free(&options);
if (ret < 0) {
av_log(NULL, AV_LOG_ERROR, "Failed to open master play list file
'%s'\n",
-hls->master_m3u8_url);
+temp_filename);
goto fail;
}
@@ -1413,7 +1417,10 @@ fail:
if(ret >=0)
hls->master_m3u8_created = 1;
av_freep(&m3u8_rel_name);
-hlsenc_io_close(s, &hls->m3u8_out, hls->master_m3u8_url);
+hlsenc_io_close(s, &hls->m3u8_out, temp_filename);
+if (use_temp_file)
+ff_rename(temp_filename, hls->master_m3u8_url, s);
+
return ret;
}
@@ -1424,6 +1431,7 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
int target_duration = 0;
int ret = 0;
char temp_filename[1024];
+char temp_vtt_filename[1024];
int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
vs->nb_entries);
const char *proto = avio_find_protocol_name(vs->m3u8_name);
int is_file_proto = proto && !strcmp(proto, "file");
@@ -1505,8 +1513,9 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
if (last && (hls->flags & HLS_OMIT_ENDLIST)==0)
ff_hls_write
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: temp_file usage for master playlist and vtt playlist
ping 2019.06.24. 18:01 keltezéssel, Bodecs Bela írta: Dear All, currently master playlist and subtitle playlist creation does not use temporary files even when temp_file flag is set. Most of the use cases it is not a problem because master playlist creation happens once on the beginning of the whole process. But if master playlist is periodically re-created because of master_pl_refresh_rate is set, non-atomic playlist creation may cause problems in case of live streaming. This poblem (i.e non-atomic playlist creation) may also apply for subtitle playlist (vtt) creation in live streaming. This patch correct this behavior by adding missing functionality. please review this patch. thank you in advance, best regards, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: changing all filename length to MAX_URL_SIZE
Dear All,
throughout hlsenc code, all filename related buffer lengths are set
hardcoded as 1024. This PATCH change it to general value as MAX_URL_SIZE
of internal.h
please review this patch.
thank you in advance,
best regards,
Bela
>From 6814aa8c06a37e4f298dd5acc84081cc4283321e Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 28 Jun 2019 13:52:18 +0200
Subject: [PATCH] avformat/hlsenc: changing all filename length to MAX_URL_SIZE
Throughout hlsenc code, all filename related buffer lengths are set
hardcoded as 1024. This PATCH change it to general value as MAX_URL_SIZE
in internal.h
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5b0121f016..057134f410 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -64,13 +64,13 @@ typedef enum {
} CodecAttributeStatus;
#define KEYSIZE 16
-#define LINE_BUFFER_SIZE 1024
+#define LINE_BUFFER_SIZE MAX_URL_SIZE
#define HLS_MICROSECOND_UNIT 100
#define POSTFIX_PATTERN "_%d"
typedef struct HLSSegment {
-char filename[1024];
-char sub_filename[1024];
+char filename[MAX_URL_SIZE];
+char sub_filename[MAX_URL_SIZE];
double duration; /* in seconds */
int discont;
int64_t pos;
@@ -149,7 +149,7 @@ typedef struct VariantStream {
char *m3u8_name;
double initial_prog_date_time;
-char current_segment_final_filename_fmt[1024]; // when renaming segments
+char current_segment_final_filename_fmt[MAX_URL_SIZE]; // when renaming
segments
char *fmp4_init_filename;
char *base_output_dirname;
@@ -,7 +,7 @@ static int parse_playlist(AVFormatContext *s, const char
*url, VariantStream *vs
AVIOContext *in;
int ret = 0, is_segment = 0;
int64_t new_start_pos;
-char line[1024];
+char line[MAX_URL_SIZE];
const char *ptr;
const char *end;
@@ -1268,7 +1268,7 @@ static int create_master_playlist(AVFormatContext *s,
const char *proto = avio_find_protocol_name(hls->master_m3u8_url);
int is_file_proto = proto && !strcmp(proto, "file");
int use_temp_file = is_file_proto && ((hls->flags & HLS_TEMP_FILE) ||
hls->master_publish_rate);
-char temp_filename[1024];
+char temp_filename[MAX_URL_SIZE];
input_vs->m3u8_created = 1;
if (!hls->master_m3u8_created) {
@@ -1433,8 +1433,8 @@ static int hls_window(AVFormatContext *s, int last,
VariantStream *vs)
HLSSegment *en;
int target_duration = 0;
int ret = 0;
-char temp_filename[1024];
-char temp_vtt_filename[1024];
+char temp_filename[MAX_URL_SIZE];
+char temp_vtt_filename[MAX_URL_SIZE];
int64_t sequence = FFMAX(hls->start_sequence, vs->sequence -
vs->nb_entries);
const char *proto = avio_find_protocol_name(vs->m3u8_name);
int is_file_proto = proto && !strcmp(proto, "file");
@@ -1594,7 +1594,7 @@ static int hls_start(AVFormatContext *s, VariantStream
*vs)
if (c->use_localtime) {
time_t now0;
struct tm *tm, tmpbuf;
-int bufsize = strlen(vs->basename) + 1024;
+int bufsize = strlen(vs->basename) + MAX_URL_SIZE;
char *buf = av_mallocz(bufsize);
if (!buf)
return AVERROR(ENOMEM);
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/f_cue: add cue and acue filters
Hi Balint,
2018.08.25. 20:35 keltezéssel, Marton Balint írta:
To delay filtering until a given wallclock timestamp.
Signed-off-by: Marton Balint
---
doc/filters.texi | 36 ++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_cue.c | 182 +++
libavfilter/version.h| 2 +-
5 files changed, 223 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/f_cue.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..79eec0c808 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -551,6 +551,11 @@ Set LFO range.
Set LFO rate.
@end table
+@section acue
+
+Delay audio filtering until a given wallclock timestamp. See the @ref{cue}
+filter.
+
@section adeclick
Remove impulsive noise from input audio.
@@ -6987,6 +6992,37 @@ indicates 'never reset', and returns the largest area encountered during
playback.
@end table
+@anchor{cue}
+@section cue
+
+Delay video filtering until a given wallclock timestamp. The filter first
+passes on @option{preroll} amount of frames, then it buffers at most
+@option{buffer} amount of frames and waits for the cue. After reaching the cue
+it forwards the buffered frames and also any subsequent frames coming in its
+input.
+
+The filter can be used synchronize the output of multiple ffmpeg processes for
+realtime output devices like decklink. By putting the delay in the filtering
+chain and pre-buffering frames the process can pass on data to output almost
+immediately after the target wallclock timestamp is reached.
+
+Perfect frame accuracy cannot be guaranteed, but the result is good enough for
+some use cases.
just for my curiousity, will you please give an example/use_case how to
use these filters?
+
+@table @option
+
+@item cue
+The cue timestamp expressed in a UNIX timestamp in microseconds. Default is 0.
+
+@item preroll
+The duration of content to pass on as preroll expressed in seconds. Default is
0.
+
+@item buffer
+The maximum duration of content to buffer before waiting for the cue expressed
+in seconds. Default is 0.
+
+@end table
+
@anchor{curves}
@section curves
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e5d3a57af7..37a06e0ec0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -36,6 +36,7 @@ OBJS-$(CONFIG_ACONTRAST_FILTER) += af_acontrast.o
OBJS-$(CONFIG_ACOPY_FILTER) += af_acopy.o
OBJS-$(CONFIG_ACROSSFADE_FILTER) += af_afade.o
OBJS-$(CONFIG_ACRUSHER_FILTER) += af_acrusher.o
+OBJS-$(CONFIG_ACUE_FILTER) += f_cue.o
OBJS-$(CONFIG_ADECLICK_FILTER) += af_adeclick.o
OBJS-$(CONFIG_ADECLIP_FILTER)+= af_adeclick.o
OBJS-$(CONFIG_ADELAY_FILTER) += af_adelay.o
@@ -178,6 +179,7 @@ OBJS-$(CONFIG_COREIMAGE_FILTER) +=
vf_coreimage.o
OBJS-$(CONFIG_COVER_RECT_FILTER) += vf_cover_rect.o lavfutils.o
OBJS-$(CONFIG_CROP_FILTER) += vf_crop.o
OBJS-$(CONFIG_CROPDETECT_FILTER) += vf_cropdetect.o
+OBJS-$(CONFIG_CUE_FILTER)+= f_cue.o
OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
OBJS-$(CONFIG_DATASCOPE_FILTER) += vf_datascope.o
OBJS-$(CONFIG_DCTDNOIZ_FILTER) += vf_dctdnoiz.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9732ae5345..6c6d0f43f0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -27,6 +27,7 @@ extern AVFilter ff_af_abench;
extern AVFilter ff_af_acompressor;
extern AVFilter ff_af_acontrast;
extern AVFilter ff_af_acopy;
+extern AVFilter ff_af_acue;
extern AVFilter ff_af_acrossfade;
extern AVFilter ff_af_acrusher;
extern AVFilter ff_af_adeclick;
@@ -167,6 +168,7 @@ extern AVFilter ff_vf_coreimage;
extern AVFilter ff_vf_cover_rect;
extern AVFilter ff_vf_crop;
extern AVFilter ff_vf_cropdetect;
+extern AVFilter ff_vf_cue;
extern AVFilter ff_vf_curves;
extern AVFilter ff_vf_datascope;
extern AVFilter ff_vf_dctdnoiz;
diff --git a/libavfilter/f_cue.c b/libavfilter/f_cue.c
new file mode 100644
index 00..732b5e218a
--- /dev/null
+++ b/libavfilter/f_cue.c
@@ -0,0 +1,182 @@
+/*
+ * Copyright (c) 2018 Marton Balint
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not
Re: [FFmpeg-devel] [PATCH] avfilter/f_cue: add cue and acue filters
Hi Balint,
2018.09.06. 22:20 keltezéssel, Marton Balint írta:
On Sat, 1 Sep 2018, Bodecs Bela wrote:
Hi Balint,
2018.08.25. 20:35 keltezéssel, Marton Balint írta:
To delay filtering until a given wallclock timestamp.
Signed-off-by: Marton Balint
---
doc/filters.texi | 36 ++
libavfilter/Makefile | 2 +
libavfilter/allfilters.c | 2 +
libavfilter/f_cue.c | 182
+++
libavfilter/version.h | 2 +-
5 files changed, 223 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/f_cue.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 32c95b591c..79eec0c808 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -551,6 +551,11 @@ Set LFO range.
Set LFO rate.
@end table
+@section acue
+
+Delay audio filtering until a given wallclock timestamp. See the
@ref{cue}
+filter.
+
@section adeclick
Remove impulsive noise from input audio.
@@ -6987,6 +6992,37 @@ indicates 'never reset', and returns the
largest area encountered during
playback.
@end table
+@anchor{cue}
+@section cue
+
+Delay video filtering until a given wallclock timestamp. The filter
first
+passes on @option{preroll} amount of frames, then it buffers at most
+@option{buffer} amount of frames and waits for the cue. After
reaching the cue
+it forwards the buffered frames and also any subsequent frames
coming in its
+input.
+
+The filter can be used synchronize the output of multiple ffmpeg
processes for
+realtime output devices like decklink. By putting the delay in the
filtering
+chain and pre-buffering frames the process can pass on data to
output almost
+immediately after the target wallclock timestamp is reached.
+
+Perfect frame accuracy cannot be guaranteed, but the result is good
enough for
+some use cases.
just for my curiousity, will you please give an example/use_case how
to use these filters?
Here is a shell script:
#!/bin/bash
UNIX_TIMESTAMP=`date +%s`
TS=$((UNIX_TIMESTAMP*100 + 250))
ffmpeg -nostdin -nostats -stream_loop -1 -i input1.mp4 \
-vf "format=uyvy422,cue=$TS:preroll=0.5:buffer=0.5" \
-af "acue=$TS:preroll=0.5:buffer=0.5" -f decklink "DeckLink Duo (1)" &
ffmpeg -nostdin -nostats -stream_loop -1 -i input2.mp4 \
-vf "format=uyvy422,cue=$TS:preroll=0.5:buffer=0.5" \
-af "acue=$TS:preroll=0.5:buffer=0.5" -f decklink "DeckLink Duo (2)" &
ffmpeg -nostdin -nostats -stream_loop -1 -i input3.mp4 \
-vf "format=uyvy422,cue=$TS:preroll=0.5:buffer=0.5" \
-af "acue=$TS:preroll=0.5:buffer=0.5" -f decklink "DeckLink Duo (3)" &
ffmpeg -nostdin -nostats -stream_loop -1 -i input4.mp4 \
-vf "format=uyvy422,cue=$TS:preroll=0.5:buffer=0.5" \
-af "acue=$TS:preroll=0.5:buffer=0.5" -f decklink "DeckLink Duo (4)" &
Thank you.
what about to create a new parameter for the filters: relcue/arelcue ?
relcue would be a relative value to current timestamp. This way the
shell variable will be unneeded.
usage of cue and relcue would be mutally esclusive parameters.
We are doing something similar to drive 16 TVs in a studio set
simultaneously.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: add shift options
see may comment in text
2020.05.03. 20:08 keltezéssel, Manolis Stamatogiannakis írta:
Allows shifting of subtitle display times to align them with the video.
This avoids having to rewrite the subtitle file in order to display
subtitles correctly when input is seeked (-ss).
Also handy for minor subtitle timing corrections without rewriting the
subtitles file.
Signed-off-by: Manolis Stamatogiannakis
---
doc/filters.texi | 8
libavfilter/vf_subtitles.c | 29 +++--
2 files changed, 35 insertions(+), 2 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index d19fd346ae..94323495f0 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17851,6 +17851,9 @@ The filter accepts the following options:
@item filename, f
Set the filename of the subtitle file to read. It must be specified.
+@item shift
+Shift subtitles timings by the specified amount.
+
@item original_size
Specify the size of the original video, the video for which the ASS file
was composed. For the syntax of this option, check the
@@ -17907,6 +17910,11 @@ To make the subtitles stream from @file{sub.srt}
appear in 80% transparent blue
subtitles=sub.srt:force_style='FontName=DejaVu Serif,PrimaryColour=&HCCFF'
@end example
+To re-sync subtitles after seeking the input e.g. with @code{-ss 20:20}, use:
+@example
+subtitles=filename=sub.srt:shift=-20\:20
+@end example
+
@section super2xsai
Scale the input by 2x and smooth using the Super2xSaI (Scale and
diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index a3b4029af4..74a902941a 100644
--- a/libavfilter/vf_subtitles.c
+++ b/libavfilter/vf_subtitles.c
@@ -52,6 +52,8 @@ typedef struct AssContext {
char *filename;
char *fontsdir;
char *charenc;
+int64_t shift;
+char *shift_opt;
char *force_style;
int stream_index;
int alpha;
@@ -68,6 +70,7 @@ typedef struct AssContext {
#define COMMON_OPTIONS \
{"filename", "set the filename of file to read",
OFFSET(filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS }, \
{"f", "set the filename of file to read",
OFFSET(filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS }, \
+{"shift", "set the tilename of file to read",
OFFSET(shift_opt), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS }, \
desciption is wrong:
{"original_size", "set the size of the original video (used to scale
fonts)", OFFSET(original_w), AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, FLAGS }, \
{"fontsdir", "set the directory containing the fonts to read",
OFFSET(fontsdir), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, FLAGS }, \
{"alpha", "enable processing of alpha channel",
OFFSET(alpha), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0,1, FLAGS }, \
@@ -103,6 +106,16 @@ static av_cold int init(AVFilterContext *ctx)
return AVERROR(EINVAL);
}
+if (ass->shift_opt) {
+if (av_parse_time(&ass->shift, ass->shift_opt, 1) < 0) {
+av_log(ctx, AV_LOG_ERROR, "Invalid subtitles shift: %s\n",
+ ass->shift_opt);
+return AVERROR(EINVAL);
+}
+ass->shift = av_rescale_q(ass->shift, AV_TIME_BASE_Q, av_make_q(1,
1000));
+av_log(ctx, AV_LOG_DEBUG, "Shifting subtitles by %0.3fsec.\n",
ass->shift/1000.0);
+}
+
ass->library = ass_library_init();
if (!ass->library) {
av_log(ctx, AV_LOG_ERROR, "Could not initialize libass.\n");
@@ -297,7 +310,7 @@ AVFILTER_DEFINE_CLASS(subtitles);
static av_cold int init_subtitles(AVFilterContext *ctx)
{
-int j, ret, sid;
+int j, ret, sid, nskip;
int k = 0;
AVDictionary *codec_opts = NULL;
AVFormatContext *fmt = NULL;
@@ -448,6 +461,7 @@ static av_cold int init_subtitles(AVFilterContext *ctx)
av_init_packet(&pkt);
pkt.data = NULL;
pkt.size = 0;
+nskip = 0;
while (av_read_frame(fmt, &pkt) >= 0) {
int i, got_subtitle;
AVSubtitle sub = {0};
@@ -458,8 +472,17 @@ static av_cold int init_subtitles(AVFilterContext *ctx)
av_log(ctx, AV_LOG_WARNING, "Error decoding: %s (ignored)\n",
av_err2str(ret));
} else if (got_subtitle) {
-const int64_t start_time = av_rescale_q(sub.pts,
AV_TIME_BASE_Q, av_make_q(1, 1000));
+const int64_t start_time = av_rescale_q(sub.pts, AV_TIME_BASE_Q,
av_make_q(1, 1000)) + ass->shift;
const int64_t duration = sub.end_display_time;
+
+if (start_time + duration < 0) {
+nskip++;
+goto pkt_end;
+} else if (nskip > 0) {
+av_log(ctx, AV_LOG_INFO, "Skipped %d subtitles out of time
rang
Re: [FFmpeg-devel] [RFC]separation of multiple outputs' encoding
2020.05.19. 17:27 keltezéssel, Zhong Li írta: Tomas Härdin 于2020年5月19日周二 下午10:25写道： fre 2020-05-15 klockan 10:14 +0800 skrev Tao Zhang: Marton Balint 于2020年5月15日周五 上午2:33写道： On Thu, 14 May 2020, Tao Zhang wrote: Hi, FFmpeg supports multiple outputs created out of the same input in the same process like ffmpeg -i input -filter_complex '[0:v]yadif,split=3[out1][out2][out3]' \ -map '[out1]' -s 1280x720 -acodec … -vcodec … output1 \ -map '[out2]' -s 640x480 -acodec … -vcodec … output2 \ -map '[out3]' -s 320x240 -acodec … -vcodec … output3 In ffmpeg.c, multiple outputs are processed sequentially like for (i = 0; i < nb_output_streams; i++) encoding one frame; As below wiki noted, the slowest encoder will slow down the whole process. Some encoders (like libx264) perform their encoding "threaded and in the background", but x264_encoder_encode still cost some time. And it is noticeable when multiple x264_encoder_encodes run in the same thread. https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs For API users, they can use separate thread for multiple encoding in their own code. But is there any way to rescue command line users? I am not sure I understand what you want. Processing will still be limited to the slowest encoder, because input processing will still be driven by the slowest encoder, even if the encoders run in separate threads. Buffering encoder input frames is not an option, because input frames are uncompressed, therefore huge. So if you want the faster x264 encoder to finish faster, you have to drive it from a different input, ultimately you should run 3 separate encode processes and accept that decoding and yadif processing happens in all 3 cases separately causing some overhead. Currently FFmpeg works like below: main thread: encoding frame 1 for output 1; encoding frame 1 for output 2; encoding frame 1 for output 3; encoding frame 2 for output 1; encoding frame 2 for output 2; encoding frame 2 for output 3;... What I want to do is thread 1: encoding frame 1 for output 1; encoding frame 2 for output 1;... thread 2: encoding frame 1 for output 2; encoding frame 2 for output 2;... thread 3: encoding frame 1 for output 3; encoding frame 2 for output 3;... Why not just run multiple copies of the ffmpeg program? Decoding should almost always be very minor work compared to encoding. Not vey minor IMHO. For same resolution, H264 decoding is about 10% computing cost of encoding. And if adding the filter computing cost (just as yadif filter listed above), the redundant computing cost is huge. I agree. I was several times in similar situations. bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] ffmpeg Filtergraph Output
2020.05.24. 4:55 keltezéssel, Dennis Mungai írta: On Sun, 24 May 2020 at 05:44, Soft Works wrote: Hello, I've seen the commit about the option for dumping the filtergraph and that reminded me about something that I'd be willing to contribute in case anybody likes it. A while ago I was looking for a way to get information about the filtergraphs that ffmpeg builds at runtime, the individual formats that have been negotiated between input and output pins and which filters have a hardware context. I had expected that this is what the graph2dot is intended to do, but that wasn't the case. Turning a filter string into a graph is not what I was looking for. Eventually I have implemented a feature that iterates all filters, their connections and the negotiated media formats during runtime and writes them out as json or xml (using the same methods that ffprobe uses). I have attached an example output and an image as an example for what could be done with the output. Let me know whether there's some interest in this. Regards Softworkz Direct links to the attachments: https://gist.github.com/softworkz/4f4bf2c1365d2ce3f6ac70b1b434aa40 https://github.com/softworkz/ffmpegfiltergraphs/issues/1 This is very fascinating, thanks for working on this. +1 vote Such output would allow for troubleshooting filter performance, especially in complex filter setups where hardware contexts are in use. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Add Timing Info to Log Lines
2019.09.02. 1:03 keltezéssel, Soft Works írta:
Hi,
I’m not sure whether this has been discussed, considered or disregarded before.
I have some code ready for adding timestamps to the log output, similar to this:
$ ffmpegd -loglevel +timing
ffmpeg version 4.2.git Copyright (c) 2000-2019 the FFmpeg developers….
built with msvc
00:57:06.469 Hyper fast Audio and Video encoder
00:57:06.470 usage: ffmpeg [options] [[infile options] -i infile]... {[outfile
options] outfile}...
00:57:06.471
00:57:06.472 Use -h to get full help or, even better, run 'man ffmpeg'
00:57:06.474
When there’s interest in adding this, I could create a patch.
during streaming sometimes it would be very useful, so +1 vote,
I suggest to put full date-time into log.
softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Add option to log timing
Hi,
2019.09.04. 20:53 keltezéssel, Soft Works írta:
This commit adds two logging flags: 'timing' and 'datetiming'.
Usage: ffmpeg -logleve +timing
Timing information will only be added to log lines once transcoding has started.
Why this restriction? I think all log lines should be start with
time/date if corresponding flag is present. This makes the log to be
easy to parse by scripts.
---
fftools/cmdutils.c | 14 ++
fftools/ffmpeg.c | 3 +++
libavutil/log.c| 37 -
libavutil/log.h| 17 +
4 files changed, 66 insertions(+), 5 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index fdcd376b76..7805058f8b 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -912,6 +912,20 @@ int opt_loglevel(void *optctx, const char *opt, const char
*arg)
flags |= AV_LOG_PRINT_LEVEL;
}
arg = token + 5;
+} else if (!strncmp(token, "timing", 6)) {
+if (cmd == '-') {
+flags &= ~AV_LOG_PRINT_TIME;
+} else {
+flags |= AV_LOG_PRINT_TIME;
+}
+arg = token + 6;
+} else if (!strncmp(token, "datetiming", 10)) {
+if (cmd == '-') {
+flags &= ~AV_LOG_PRINT_DATETIME;
+} else {
+flags |= AV_LOG_PRINT_DATETIME;
+}
+arg = token + 10;
} else {
break;
}
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..ed1c6ab6fc 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4668,6 +4668,9 @@ static int transcode(void)
av_log(NULL, AV_LOG_INFO, "Press [q] to stop, [?] for help\n");
}
+/* Enable log timestamps if configured */
+av_log_set_flags(av_log_get_flags() | AV_LOG_PRINT_STARTUPCOMPLETE);
+
timer_start = av_gettime_relative();
#if HAVE_THREADS
diff --git a/libavutil/log.c b/libavutil/log.c
index 93a156b8e4..a374a68c4e 100644
--- a/libavutil/log.c
+++ b/libavutil/log.c
@@ -40,6 +40,8 @@
#include "internal.h"
#include "log.h"
#include "thread.h"
+#include "time.h"
+#include "time_internal.h"
static AVMutex mutex = AV_MUTEX_INITIALIZER;
@@ -243,14 +245,32 @@ static const char *get_level_str(int level)
}
}
+static void format_date_now(AVBPrint* timeBuf, int include_date)
+{
+struct tm *ptm, tmbuf;
+int64_t time_us = av_gettime();
+int64_t time_ms = time_us / 1000;
+const time_t time_s = time_ms / 1000;
+int millisec = time_ms - (time_s * 1000);
+ptm = localtime_r(&time_s, &tmbuf);
+if (ptm) {
+if (include_date)
+av_bprint_strftime(timeBuf, "%Y-%m-%d ", ptm);
+
+av_bprint_strftime(timeBuf, "%H:%M:%S", ptm);
+av_bprintf(timeBuf, ".%03d ", millisec);
+}
+}
+
static void format_line(void *avcl, int level, const char *fmt, va_list vl,
-AVBPrint part[4], int *print_prefix, int type[2])
+AVBPrint part[5], int *print_prefix, int type[2])
{
AVClass* avc = avcl ? *(AVClass **) avcl : NULL;
av_bprint_init(part+0, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(part+1, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(part+2, 0, AV_BPRINT_SIZE_AUTOMATIC);
av_bprint_init(part+3, 0, 65536);
+av_bprint_init(part+4, 0, AV_BPRINT_SIZE_AUTOMATIC);
if(type) type[0] = type[1] = AV_CLASS_CATEGORY_NA + 16;
if (*print_prefix && avc) {
@@ -277,6 +297,10 @@ static void format_line(void *avcl, int level, const char
*fmt, va_list vl,
char lastc = part[3].len && part[3].len <= part[3].size ?
part[3].str[part[3].len - 1] : 0;
*print_prefix = lastc == '\n' || lastc == '\r';
}
+
+if (*print_prefix && part[3].len > 1 && (flags &
AV_LOG_PRINT_STARTUPCOMPLETE)
+&& ((flags & AV_LOG_PRINT_TIME) || (flags & AV_LOG_PRINT_DATETIME)))
+format_date_now(&part[4], flags & AV_LOG_PRINT_DATETIME);
}
void av_log_format_line(void *ptr, int level, const char *fmt, va_list vl,
@@ -288,12 +312,12 @@ void av_log_format_line(void *ptr, int level, const char
*fmt, va_list vl,
int av_log_format_line2(void *ptr, int level, const char *fmt, va_list vl,
char *line, int line_size, int *print_prefix)
{
-AVBPrint part[4];
+AVBPrint part[5];
int ret;
format_line(ptr, level, fmt, vl, part, print_prefix, NULL);
ret = snprintf(line, line_size, "%s%s%s%s", part[0].str, part[1].str,
part[2].str, part[3].str);
-av_bprint_finalize(part+3, NULL);
+av_bprint_finalize(part+4, NULL);
return ret;
}
@@ -302,7 +326,7 @@ void av_log_default_callback(void* ptr, int level, const
char* fmt, va_list vl)
static int print_prefix = 1;
static int count;
static char prev[LINE_SZ];
-AVBPrint part[4];
+AVBPrint part[5];
char line[LINE_SZ];
static int is_atty;
int type[2];
@@ -337,6 +361,9 @@ void av_log_default_c
Re: [FFmpeg-devel] FW: [PATCH] Add option to log timing
2019.09.13. 12:05 keltezéssel, Gyan írta: On 13-09-2019 03:10 AM, Soft Works wrote: -Original Message- From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Thursday, September 12, 2019 11:29 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] FW: [PATCH] Add option to log timing On Wed, Sep 11, 2019 at 08:43:36PM +, Soft Works wrote: Michael - you probably missed my question... -Original Message- From: Soft Works Sent: Friday, September 6, 2019 11:44 PM To: FFmpeg development discussions and patches Subject: RE: [FFmpeg-devel] [PATCH] Add option to log timing From: ffmpeg-devel On Behalf Of Michael Niedermayer Sent: Friday, September 6, 2019 8:56 PM To: FFmpeg development discussions and patches Subject: Re: [FFmpeg-devel] [PATCH] Add option to log timing On Wed, Sep 04, 2019 at 07:35:11PM +, Soft Works wrote: Why this restriction? I think all log lines should be start with time/date if corresponding flag is present. This makes the log to be easy to parse by scripts. Initially I didn’t have this restriction, but it doesn’t work well together with some multi-line logging. See below for an example. To get this nice, it would require a larger amount of changes, and probably result in something that nobody wants to merge in. Anyway, there’s a flag controlling this behavior and if you really want, you can set it. Then you’ll see something like this: [...] i just enabled prefixes for all calls, and i get this: [] libavutil 56. 35.100 / 56. 35.100 [] libavcodec 58. 56.101 / 58. 56.101 [...] This looks much better than your example, so i have to disagree that theres a problem for calls during startup or some requirment of high complexity I need to apologize. I had been driven by another complication that exists in my branch but not in the ffmpeg trunk. I will submit an updated patch. What would you prefer - should I: 1. Activate the flag for adding log timing during startup by default (to allow opt-out behavior from the command line) or 2. Remove that flag and add log timing either all or nothing depending On the other two flags? i think i dont understand the question fully The default behavior should not change there could be one or 2 flags that control the timestamp output, yes What I meant was whether to keep that third flag for controlling whether the timing should be printed from the very first line (default) or just be printed once transcoding has started. I prefer from startup - timeline of input probing can be helpful. +1 vote Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict
Dear All, When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The initial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all the real new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. please review this patch! thank you in advance, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict
sorry for missing patch file, here it is. Bela 2020.01.18. 18:56 keltezéssel, Bodecs Bela írta: Dear All, When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The initial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all the real new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. please review this patch! thank you in advance, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". From 7e10fcb0a150259bdb0bf01f3ded7e92ed1447b8 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Sat, 18 Jan 2020 17:41:55 +0100 Subject: [PATCH] avformat/hlsenc: program_date_time and append_list flags conflict When program_date_time flag is present, in m3u8 playlist file each segment has a corresponding EXT-X-PROGRAM-DATE-TIME value. The intial program-date-time value is the actual current time at init and each new segment increments this value by its duration. When append_list flags is also present, existing playlist parsing by hls_append_segment treats existing segments as new segments regarding the program-date-time calculation. But it should not do that, because this way all real the new segments' EXT-X-PROGRAM-DATE-TIME values will be shifted erroneously by the sum duration of existing segments. Instead it should have decremented the initial program-date-time value by its duration. This would ensure that the first new segment's program-date-time value had the current time as it is expected. This patch corrects this behaviour and prevent existing segments to increment the value of initial_prog_date_time variable but decrements it. Signed-off-by: Bela Bodecs --- libavformat/hlsenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 9884f74d51a..7eeb0df48ae 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -1130,6 +1130,7 @@ static int parse_playlist(AVFormatContext *s, const char *url, VariantStream *vs is_segment = 0; new_start_pos = avio_tell(vs->avf->pb); vs->size = new_start_pos - vs->start_pos; +vs->initial_prog_date_time -= vs->duration; // this is a previously existing segment ret = hls_append_segment(s, hls, vs, vs->duration, vs->start_pos, vs->size); if (ret < 0) goto fail; -- 2.20.1.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: fix default AES key file url with variant streams
Dear All,
Currently when hls_enc is active and there are multiple variant stream
outputs, default key file url construction does not work, because it is
based on the FormatContext' url field. (m3u8 playlist output)
But in case of multiple variant streams,
it contains the variant m3u8 output playlist url that contains
the %v placeholder. So the result key file url also will hold the %v
placeholder causing run time error message about "could not write the
key file".
This patch correct this behaviour, and use the master playlist url for
constructing the output key file url when master playlist is vailable.
please review this patch!
thank you in advance,
Bela
>From 0d299e323bf04ae97c5e20778423537d10b16b4b Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sun, 19 Jan 2020 23:01:32 +0100
Subject: [PATCH] avformat/hlsenc: fix default AES key file url with variant
streams
Currently when hls_enc is active and there are multiple variant stream
outputs, default key file url construction does not work, because it is
based on the FormatContext' url field. But in case of multiple variant
streams, it contains the variant m3u8 output playlist url that contains
the %v placeholder. So the result key file url will hold the %v
placeholder causing run time error message about "could not write the
key file".
This patch correct this behaviour, and use the master playlist url for
constructing the output key file url when master playlist is vailable.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d130f03ea62..dd6343a9fe9 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -642,13 +642,14 @@ static int do_encrypt(AVFormatContext *s, VariantStream
*vs)
int len;
AVIOContext *pb;
uint8_t key[KEYSIZE];
+char * key_basename_source = (hls->master_m3u8_url) ? hls->master_m3u8_url
: s->url;
-len = strlen(s->url) + 4 + 1;
+len = strlen(key_basename_source) + 4 + 1;
hls->key_basename = av_mallocz(len);
if (!hls->key_basename)
return AVERROR(ENOMEM);
-av_strlcpy(hls->key_basename, s->url, len);
+av_strlcpy(hls->key_basename, key_basename_source, len);
av_strlcat(hls->key_basename, ".key", len);
if (hls->key_url) {
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
Dear All,
This patch corrects compiler warning about returning possibly uninitialized
variable in hls_write_header function.
please review this patch!
Thank you in advance.
Bela
>From e7b3a680f13fd6113f3bf118803d9609d0fe8bda Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 20 Jan 2020 08:31:38 +0100
Subject: [PATCH] avformat/hlsenc: compiler warning fix
Correcting compiler warning about returning possibly uninitialized
variable in hls_write_header function.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d130f03ea62..1661f7aacba 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2170,7 +2170,7 @@ fail:
static int hls_write_header(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
-int ret, i, j;
+int ret = 0, i, j;
VariantStream *vs = NULL;
for (i = 0; i < hls->nb_varstreams; i++) {
--
2.20.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
2020.01.20. 8:46 keltezéssel, Andreas Rheinhardt írta: On Mon, Jan 20, 2020 at 8:35 AM Bodecs Bela wrote: Dear All, This patch corrects compiler warning about returning possibly uninitialized variable in hls_write_header function. Which compiler warns about this? libavformat/hlsenc.c: In function ‘hls_write_header’: libavformat/hlsenc.c:2174: warning: ‘ret’ may be used uninitialized in this function gcc version 4.4.7 20120313 (Red Hat 4.4.7-23) (GCC) Regarding the patch: It's probably better to explicitly return 0 at the end of hls_write_header() (as well as dash_write_header()). I have no objection, but maybe in a separate patch? - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
2020.01.20. 13:07 keltezéssel, Carl Eugen Hoyos írta: Am Mo., 20. Jan. 2020 um 09:41 Uhr schrieb Bodecs Bela : 2020.01.20. 8:46 keltezéssel, Andreas Rheinhardt írta: On Mon, Jan 20, 2020 at 8:35 AM Bodecs Bela wrote: Dear All, This patch corrects compiler warning about returning possibly uninitialized variable in hls_write_header function. Which compiler warns about this? libavformat/hlsenc.c: In function ‘hls_write_header’: libavformat/hlsenc.c:2174: warning: ‘ret’ may be used uninitialized in this function Looks like a false positive, does not warn with newer compilers. yes and no. no, because if hls->nb_varstreams == 0, then for loop body never executes and so ret does not get any value. yes, because there is no chance for hls->nb_varstreams to be zero. so, I think setting ret to 0 at its declaration does not do any problem and logically right. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
2020.01.20. 13:46 keltezéssel, Carl Eugen Hoyos írta: Am Mo., 20. Jan. 2020 um 13:18 Uhr schrieb Bodecs Bela : 2020.01.20. 13:07 keltezéssel, Carl Eugen Hoyos írta: Am Mo., 20. Jan. 2020 um 09:41 Uhr schrieb Bodecs Bela : 2020.01.20. 8:46 keltezéssel, Andreas Rheinhardt írta: On Mon, Jan 20, 2020 at 8:35 AM Bodecs Bela wrote: Dear All, This patch corrects compiler warning about returning possibly uninitialized variable in hls_write_header function. Which compiler warns about this? libavformat/hlsenc.c: In function ‘hls_write_header’: libavformat/hlsenc.c:2174: warning: ‘ret’ may be used uninitialized in this function Looks like a false positive, does not warn with newer compilers. yes and no. no, because if hls->nb_varstreams == 0, then for loop body never executes and so ret does not get any value. yes, because there is no chance for hls->nb_varstreams to be zero. so, I think setting ret to 0 at its declaration does not do any problem and logically right. No, update your compiler instead. which of my statements did your "No" reference? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
2020.01.20. 14:02 keltezéssel, Carl Eugen Hoyos írta: This patch corrects compiler warning about returning possibly uninitialized variable in hls_write_header function. Which compiler warns about this? libavformat/hlsenc.c: In function ‘hls_write_header’: libavformat/hlsenc.c:2174: warning: ‘ret’ may be used uninitialized in this function Looks like a false positive, does not warn with newer compilers. yes and no. no, because if hls->nb_varstreams == 0, then for loop body never executes and so ret does not get any value. yes, because there is no chance for hls->nb_varstreams to be zero. so, I think setting ret to 0 at its declaration does not do any problem and logically right. No, update your compiler instead. which of my statements did your "No" reference? Both. Thank you for your help. Maybe due to my poor english, but I really do not see, I really did test with other compiler and really did not give warning any longer, but it does not help that the ret varaiable remain uninitalized but may be returned. As I know theoretically there is no default value of an int variable. So why the warning did disappear? Please cut your quotes, Carl Eugen ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: compiler warning fix
2020.01.20. 14:25 keltezéssel, Carl Eugen Hoyos írta: Am Mo., 20. Jan. 2020 um 14:18 Uhr schrieb Bodecs Bela : 2020.01.20. 14:02 keltezéssel, Carl Eugen Hoyos írta: This patch corrects compiler warning about returning possibly uninitialized variable in hls_write_header function. Which compiler warns about this? libavformat/hlsenc.c: In function ‘hls_write_header’: libavformat/hlsenc.c:2174: warning: ‘ret’ may be used uninitialized in this function Looks like a false positive, does not warn with newer compilers. yes and no. no, because if hls->nb_varstreams == 0, then for loop body never executes and so ret does not get any value. yes, because there is no chance for hls->nb_varstreams to be zero. so, I think setting ret to 0 at its declaration does not do any problem and logically right. No, update your compiler instead. which of my statements did your "No" reference? Both. Thank you for your help. Maybe due to my poor english, but I really do not see, I really did test with other compiler and really did not give warning any longer, but it does not help that the ret varaiable remain uninitalized but may be returned. As I know theoretically there is no default value of an int variable. So why the warning did disappear? I believe newer compilers detect that hls->nb_varstreams cannot be zero. ok Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCHv2] configure: request explicitly enabled components
2019.02.03. 12:46 keltezéssel, Marton Balint írta:
On Mon, 28 Jan 2019, Marton Balint wrote:
If we enable a component but a dependant library is disabled, then
the enabled
component get silently disabled. Requesting all explicitly enabled
components
allows configure to fail and show the missing dependencies instead of
ignoring
our request.
For example if libdav1d is not availble ./configure
--enable-decoder=libdav1d
succeeds but the libdav1d decoder will not be enabled. After the
patch the
configure line will fail with the following message:
ERROR: libdav1d_decoder requested, but not all dependencies are
satisfied: libdav1d
Signed-off-by: Marton Balint
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index e1412352fa..afe64bf98a 100755
--- a/configure
+++ b/configure
@@ -3880,6 +3880,7 @@ for opt do
name=$(echo "${optval}" | sed "s/,/_${thing}|/g")_${thing}
list=$(filter "$name" $list)
[ "$list" = "" ] && warn "Option $opt did not match
anything"
+ test $action = enable && request $list
$action $list
;;
--enable-yasm|--disable-yasm)
--
Ping.
I can not tell wheter this patch is correct or not technically, but the
functionality/behaviour it provides, is the one that I assumed
originally. So I give one vote to use this patch.
bb
Thanks,
Marton
___
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] configure: request explicitly enabled components
2019.02.05. 0:45 keltezéssel, Carl Eugen Hoyos írta: 2019-02-03 16:24 GMT+01:00, Marton Balint : On Sun, 3 Feb 2019, Carl Eugen Hoyos wrote: 2019-01-28 2:00 GMT+01:00, Marton Balint : If we enable a component but a dependant library is disabled, then the enabled component get silently disabled. Requesting all explicitly enabled components allows configure to fail and show the missing dependencies instead of ignoring our request. For example if libdav1d is not availble ./configure --enable-decoder=libdav1d succeeds but the libdav1d decoder will not be enabled. After the patch the configure line will fail with the following message: ERROR: libdav1d_decoder requested, but not all dependencies are satisfied: libdav1d Signed-off-by: Marton Balint --- configure | 1 + 1 file changed, 1 insertion(+) diff --git a/configure b/configure index e1412352fa..1f6c6a7311 100755 --- a/configure +++ b/configure @@ -3881,6 +3881,7 @@ for opt do list=$(filter "$name" $list) [ "$list" = "" ] && warn "Option $opt did not match anything" $action $list +test $action = enable && request $list I strongly suspect that this will break regression tests. You mean fate with different configure options? No, I believe this would break regression tests with --disable-everything (and an enable for a feature that was added in the meantime and is needed to reproduce the issue). Please print a warning like for "--enable-decoder=foo" to fix the issue you see. what about to have a new switch of configure script that controls the behaviour at missing dependencies? Something like --stop_on_missing_deps its defult value would be "no" as current state, but Marton Balint new patch functionality may work at "yes" state? bb 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] [PATCH v2] avformat/flvdec: check FLVHeader PreviousTagSize0
2017.03.25. 14:15 keltezéssel, Steven Liu írta:
refer to SPEC:
Annex E. The FLV File Format said:
E.3 TheFLVFileBody have a table:
FieldTypeComment
PreviousTagSize0 UI32Always 0
Signed-off-by: Steven Liu
---
libavformat/flvdec.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index cdcfb9c..94c9e28 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -709,6 +709,7 @@ static int flv_read_header(AVFormatContext *s)
int flags;
FLVContext *flv = s->priv_data;
int offset;
+int pre_tag_size = 0;
avio_skip(s->pb, 4);
flags = avio_r8(s->pb);
@@ -719,7 +720,16 @@ static int flv_read_header(AVFormatContext *s)
offset = avio_rb32(s->pb);
avio_seek(s->pb, offset, SEEK_SET);
-avio_skip(s->pb, 4);
+
+/* Annex E. The FLV File Format
+ * E.3 TheFLVFileBody
+ * Field TypeComment
+ * PreviousTagSize0UI32Always 0
+ * */
+pre_tag_size = avio_rb32(s->pb);
+if (pre_tag_size) {
+av_log(s, AV_LOG_WARNING, "Read FLV header error, input file is not a
standard flv format, first PreviousTagSize0 always is 0\n");
+}
s->start_time = 0;
flv->sum_flv_tag_size = 0;
I think this forgiving behaviour is better, than the earlier rigorous
one. I agree that showing warning is more useful than returning error
and stopping execution because if
PreviousTagSize0 is not zero that causes no harm.
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/patchwork: Document the patchwork states
2016.10.22. 18:29 keltezéssel, Stephen Hutchinson írta: On 10/22/2016 8:25 AM, Michael Niedermayer wrote: On Sat, Oct 22, 2016 at 02:12:18PM +0200, Clément Bœsch wrote: On Sat, Oct 22, 2016 at 01:38:47PM +0200, Michael Niedermayer wrote: Signed-off-by: Michael Niedermayer --- doc/patchwork | 9 + 1 file changed, 9 insertions(+) create mode 100644 doc/patchwork diff --git a/doc/patchwork b/doc/patchwork new file mode 100644 index 000..9486e07 --- /dev/null +++ b/doc/patchwork @@ -0,0 +1,9 @@ +Patchwork states + +NEW: Initial state of new patches +Accepted: The patch was pushed to the main master repository +Rejected: The patch has been rejected +Not Applicable:The patch does not apply to the main master repository +Superseded:A newer version of the patch has been posted +Changes Requested: The patch has been or is under review and changes have been requested +RFC: The patch is not intended to be applied but only for comments no "dropped" or "invalid" state? (similar to a self rejected patch) Dropped state added anything else we need ? [...] The other ones that appear in the list on Patchwork are 'Under Review', 'Deferred', and 'Awaiting Upstream'. 'Under Review' is fairly self-explanatory, but when and why a patch should be flagged that way (as opposed to simply remaining as 'New' until it gets committed) isn't. 'Deferred' sounds like either holding off on commit to a later date or kicking the can to somebody else, and... 'Awaiting Upstream' isn't all that clear about its purpose - awaiting upstream for what? Review, commit, something else I've not thought of? Is this the state that should be used for patches that are queued up for commit? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel under review: someone marked it because he/she investigate this patch. So the patch submitter and other potential reviewers may feel/be_sure that this patch is already handled by someone else. I suggest to use it. This is psychologic aspect that the patch submitter may feel more patienty toward review process opposite to mere "new" state. I think if we will use under_review state it will have an impact for community communication: if a patch remains in under_review state for long period the patch submitter may contact directly the specific person who put his/her patch into this state. But if a patch remains in new state for a longer period the submitter will ping the whole communitiy. I think the new->under_review is not a one-way change. The opposite direction under_review->new also should be available. I also suggest to communicate clearly the valid/expected state changes: new->(under_review|deferred|rejected|accepted|superseed|not_app) deferred->(new|under_review|deferred|rejected|accepted|superseed|not_app) under_review->(new||deferred|rejected|accepted|superseed|not_app) etc. bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/options_table: Set the default maximum number of streams to 100
2016.12.08. 19:36 keltezéssel, Michael Niedermayer írta:
On Thu, Dec 08, 2016 at 07:25:59PM +0100, wm4 wrote:
On Thu, 8 Dec 2016 18:37:42 +0100
Michael Niedermayer wrote:
Suggested-by: Andreas Cadhalpun
Signed-off-by: Michael Niedermayer
---
libavformat/options_table.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/options_table.h b/libavformat/options_table.h
index d5448e503f..19cb87ae4e 100644
--- a/libavformat/options_table.h
+++ b/libavformat/options_table.h
@@ -105,7 +105,7 @@ static const AVOption avformat_options[] = {
{"format_whitelist", "List of demuxers that are allowed to be used",
OFFSET(format_whitelist), AV_OPT_TYPE_STRING, { .str = NULL }, CHAR_MIN, CHAR_MAX, D },
{"protocol_whitelist", "List of protocols that are allowed to be used",
OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL }, CHAR_MIN, CHAR_MAX, D },
{"protocol_blacklist", "List of protocols that are not allowed to be used",
OFFSET(protocol_blacklist), AV_OPT_TYPE_STRING, { .str = NULL }, CHAR_MIN, CHAR_MAX, D },
-{"max_streams", "maximum number of streams", OFFSET(max_streams),
AV_OPT_TYPE_INT, { .i64 = INT_MAX }, 0, INT_MAX, D },
+{"max_streams", "maximum number of streams", OFFSET(max_streams),
AV_OPT_TYPE_INT, { .i64 = 100 }, 0, INT_MAX, D },
{NULL},
};
That seems awfully low. Why limit stream count to 100,
Is this too little for real world streams ?
what limit would not interfere with a positive user experience ?
255 is acceptable for me.
I saw several times more than 100 streams in one input/output but never
more than 255.
while allowing
e.g. 2GB large font attachments?
theres no limit on attachments currently except the natural int size
we may want to have a tighter limit there too
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/1] flv demuxer supports live rtmp inputs but there is no any info about it in the docs
>From af75a5bbfe9f37672478b6a67f8bcfe32b7b997f Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sat, 24 Dec 2016 00:21:23 +0100
Subject: [PATCH 1/1] flv demuxer supports live rtmp inputs but there is no any
info about it in the docs.
Signed-off-by: Bela Bodecs
---
doc/demuxers.texi | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index 2934a1c..c12c07e 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -243,11 +243,17 @@ file subdir/file-2.wav
@end example
@end itemize
-@section flv
+@section flv, live_flv
Adobe Flash Video Format demuxer.
-This demuxer is used to demux FLV files and RTMP network streams.
+This demuxer is used to demux FLV files and RTMP network streams. In case of live network streams, if you force format, you may use live_flv option instead of flv to survive timestamp discontinuities.
+
+@example
+ffmpeg -f flv -i myfile.flv ...
+ffmpeg -f live_flv -i rtmp:///anything/key
+@end example
+
@table @option
@item -flv_metadata @var{bool}
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: detecting duplicated segment filenames
Dear All,
with use_localtime parameter hlsenc may produce identical filenames for
different but still existing segments. It happens when
hls_segment_filename contains
syntacticaly correct but inadequate format parameters. Currently there
is no any log message when such a situaton occurs but these cases should
be avoided in most times. This patch generate warning log messages in these
cases.
best regards,
bb
>From 7055e0b0bec3fee61373dd446bcab24d15117b7e Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 26 Dec 2016 02:00:49 +0100
Subject: [PATCH] avformat/hlsenc: detecting duplicated segment filenames
with use_localtime parameter hlsenc may produce identical filenames for
different but still existing segments. It happens when
hls_segment_filename contains
syntacticaly correct but inadequate format parameters. Currently there
is no any log message when such a situaton occurs but these cases should
be avoided in most times. This patch generate warning messages in these
cases.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index acf3a30..11ec3b8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -653,6 +653,38 @@ fail:
return ret;
}
+static HLSSegment * find_segment_by_filename(HLSSegment * segment, const char * filename)
+{
+/* filename may contain rel/abs path, but segments store only basename */
+char *p, *dirname, *path;
+int path_size;
+HLSSegment *ret_segment = NULL;
+dirname = av_strdup(filename);
+if (!dirname)
+return NULL;
+p = (char *)av_basename(dirname); // av_dirname would return . in case of no dir
+*p = '\0'; // maybe empty
+
+while (segment) {
+path_size = strlen(dirname) + strlen(segment->filename) + 1;
+path = av_malloc(path_size);
+if (!path)
+goto end;
+av_strlcpy(path, dirname, path_size);
+av_strlcat(path, segment->filename, path_size);
+if (!strcmp(path,filename)) {
+ret_segment = segment;
+av_free(path);
+goto end;
+}
+av_free(path);
+segment = segment->next;
+}
+end:
+av_free(dirname);
+return ret_segment;
+}
+
static int hls_start(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
@@ -685,6 +717,8 @@ static int hls_start(AVFormatContext *s)
av_log(oc, AV_LOG_ERROR, "Could not get segment filename with use_localtime\n");
return AVERROR(EINVAL);
}
+if (find_segment_by_filename(c->segments, oc->filename) || find_segment_by_filename(c->old_segments, oc->filename))
+av_log(c, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n",oc->filename);
if (c->use_localtime_mkdir) {
const char *dir;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Change bitrate on-the-fly
2016.08.01. 19:46 keltezéssel, Aman Gupta írta: I would find your patch useful and am looking forward to reviewing it. Using a socket isn't a bad way to do it IMHO- it's portable and allows easy integration from any language. Another option would be to extend the existing ffmpeg interactive mode to handle your new command. Currently ffmpeg allows sending commands to filters, but tbh it's pretty confusing to use and not well documented. I'd love to see a generic control interface for ffmpeg that was easy to use programatically, and could handle simple commands like "pause", "resume", "seek ", etc. Aman On Sun, Jul 31, 2016 at 9:32 AM, Llorx wrote: Hi, About 1 or 2 years ago I had written an addition for ffmpeg to change the video bitrate while ffmpeg is running. The way I've done it is by listening to a UDP socket for an int32, and each time a 4 byte packet enters, changes the bitrate, taking effect instantly. Works like a charm, and the UDP way fits my needings without problems. I needed it because currently I have a business that requires streaming video in some difficult and bandwith-changing environments, so I have a thrid party program than launchs ffmpeg and analyzes the packets sent to detect bandwidth alterations, changing the bitrate accordingly. Now I would like to share it with the community, as I had some messages from some users telling me to release it (As I posted a question about this on Stack Overflow). I know that the UDP thing is a bit hackish, so I would like to ask you, ffmpeg masters, how do you consider that this can be applied in a more "professional" way. I thought that instead of listening to a UDP socket (configurable at launch time with a parameter), I can use named pipes, memory mapped files or simply process signaling. The last method is only available on Unix with SA_SIGINFO. Windows can't handle such signal behaviour. What do you think is the best option? ___ 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 Hi, for filters there is zmq. It works well. Quite few filters support it via commands. Would not zmq be good for this purpose, also? best, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.2
Shannon https://en.wikipedia.org/wiki/Claude_Shannon 2016.09.27. 15:30 keltezéssel, Michael Niedermayer írta: Hi all Its long since FFmpeg 3.1, so its time to make 3.2 ill branch release/3.2 off master and make 3.2 in maybe about a week or 2 unless something delays it also a name needs to be choosen Thanks ___ 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] [PATCH]concatdec: measure duration when it is not available
Hi All,
This patch is a bug fix for a problem I faced recently.
There are cases when duration info is not available. e.g. reading an
mpegts file via a fifo file. But for concatenation this info is
mandatory to adjust next file timestamps. So we need to measure it to
have this value.
please include my patch in official ffmpeg tree.
thanks in advance,
best regards,
Bela Bodecs
>From 3512d551fbf9d93398373edb37e4e92158bf4227 Tue, 16 Feb 2016 00:10:55 +0100
From: Bela Bodecs
Date: Tue, 16 Feb 2016 00:08:13 +0100
Subject: [PATCH] concatdec: measure duration when it is not available
There are cases when duration info is not available. e.g. reading an
mpegts file via a fifo file. But for concatenation this info is
mandatory to adjust next file timestamps. So we need to measure it to
have this value.
Signed-off-by: Bela Bodecs
diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
index d226e15..68c4701 100644
--- a/libavformat/concatdec.c
+++ b/libavformat/concatdec.c
@@ -47,10 +47,11 @@
ConcatStream *streams;
int64_t inpoint;
int64_t outpoint;
AVDictionary *metadata;
int nb_streams;
+int64_t measured_duration;
} ConcatFile;
typedef struct {
AVClass *class;
ConcatFile *files;
@@ -478,11 +479,11 @@
{
ConcatContext *cat = avf->priv_data;
unsigned fileno = cat->cur_file - cat->files;
if (cat->cur_file->duration == AV_NOPTS_VALUE)
-cat->cur_file->duration = cat->avf->duration - (cat->cur_file->file_inpoint - cat->cur_file->file_start_time);
+cat->cur_file->duration = ((cat->avf->duration == AV_NOPTS_VALUE) ? cat->cur_file->measured_duration : cat->avf->duration) - (cat->cur_file->file_inpoint - cat->cur_file->file_start_time);
if (++fileno >= cat->nb_files) {
cat->eof = 1;
return AVERROR_EOF;
}
@@ -544,10 +545,11 @@
ConcatContext *cat = avf->priv_data;
int ret;
int64_t delta;
ConcatStream *cs;
AVStream *st;
+int64_t new_dur;
if (cat->eof)
return AVERROR_EOF;
if (!cat->avf)
@@ -587,10 +589,14 @@
av_log(avf, AV_LOG_DEBUG, "file:%d stream:%d pts:%s pts_time:%s dts:%s dts_time:%s",
(unsigned)(cat->cur_file - cat->files), pkt->stream_index,
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, &st->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, &st->time_base));
+new_dur = av_rescale_q(pkt->pts + pkt->duration, cat->avf->streams[pkt->stream_index]->time_base, AV_TIME_BASE_Q) - cat->cur_file->file_inpoint;
+if (cat->cur_file->measured_duration < new_dur)
+cat->cur_file->measured_duration = new_dur;
+
delta = av_rescale_q(cat->cur_file->start_time - cat->cur_file->file_inpoint,
AV_TIME_BASE_Q,
cat->avf->streams[pkt->stream_index]->time_base);
if (pkt->pts != AV_NOPTS_VALUE)
pkt->pts += delta;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available
2016.02.16. 0:30 keltezéssel, Nicolas George írta: L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit : This patch is a bug fix for a problem I faced recently. There are cases when duration info is not available. e.g. reading an mpegts file via a fifo file. But for concatenation this info is mandatory to adjust next file timestamps. So we need to measure it to have this value. As far as I know and can seen in the code, lavf is supposed to be already doing that on its own. It would probably be better to find out why it does not happen in the case of piped MPEG-TS instead of fixing it in a single API user. Regards, this problem also occurs if the input is a live hls stream via http or via hls+file protocol. I thought it is a peculiarity of concat demuxer in case of non-seekable input items. This patch is a workaroud for this. bb ___ 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]concatdec: measure duration when it is not available
2016.02.16. 0:53 keltezéssel, Nicolas George írta: L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit : this problem also occurs if the input is a live hls stream via http or via hls+file protocol. I thought it is a peculiarity of concat demuxer in case of non-seekable input items. This patch is a workaroud for this. As I said: it looks like a bug in the libavformat infrastructure, not a quirk of the concat demuxer. If it is a bug, or even a misfeature, it should be fixed, not worked around. Regards, Do you have any suggestion for me what to do now? Please give me a hint where to find this bug or should I open a trac ticket for it? Thank you in advance, ___ 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]concatdec: measure duration when it is not available
2016.02.16. 10:42 keltezéssel, Nicolas George írta: L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit : Do you have any suggestion for me what to do now? Please give me a hint where to find this bug or should I open a trac ticket for it? I already told you: find out exactly WHY the result is different. I suggest you use this kind of test case: ffprobe -show_packets -show_streams input.ts cat input.ts | ffprobe -show_packets -show_streams - When we know why, we can discuss how. Regards, I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. best regars, ___ 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]concatdec: measure duration when it is not available
ping 2016.02.17. 14:13 keltezéssel, Bodecs Bela írta: 2016.02.16. 10:42 keltezéssel, Nicolas George írta: L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit : Do you have any suggestion for me what to do now? Please give me a hint where to find this bug or should I open a trac ticket for it? I already told you: find out exactly WHY the result is different. I suggest you use this kind of test case: ffprobe -show_packets -show_streams input.ts cat input.ts | ffprobe -show_packets -show_streams - When we know why, we can discuss how. Regards, I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. best regars, ___ 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]concatdec: measure duration when it is not available
ping 2016.02.23. 9:21 keltezéssel, Bodecs Bela írta: ping 2016.02.17. 14:13 keltezéssel, Bodecs Bela írta: 2016.02.16. 10:42 keltezéssel, Nicolas George írta: L'octidi 28 pluviôse, an CCXXIV, Bodecs Bela a écrit : Do you have any suggestion for me what to do now? Please give me a hint where to find this bug or should I open a trac ticket for it? I already told you: find out exactly WHY the result is different. I suggest you use this kind of test case: ffprobe -show_packets -show_streams input.ts cat input.ts | ffprobe -show_packets -show_streams - When we know why, we can discuss how. Regards, I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. best regars, ___ 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]concatdec: measure duration when it is not available
2016.03.01. 10:57 keltezéssel, Nicolas George írta: Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit : I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. Sorry for the late reply, I was distracted. If I summarize correctly your findings: Thank you. You summarized correctly my findings. For formats without a reliable duration header with seekable backing, the duration is evaluated at the opening by peeking at the last timestamps. With unseekable backing, the duration is not evaluated at all. In particular, the duration is not updated once the end of the file is reached. Well, I thought it was and wrote the code in consequence, thanks for correcting me. Still, the logic for tracking the duration can be a bit tricky, possibly trickier than your original patch if there are B-frames and timestamps resets. I would rather have it in a common part of the code than in the concat demuxer. I agree. I suspect we could consider adding AVStream.current_duration that tracks the maximum recently seen PTS for each stream. yes, it sounds good. (We could also have a function that peeks in AVStream.pts_buffer, but that looks tricky; and the corresponding duration is not available.) I hope other can give advice about this issue. Regards, I hope somebody will give a better solution than me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel best, bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]concatdec: measure duration when it is not available
2016.03.01. 11:26 keltezéssel, Michael Niedermayer írta: On Tue, Mar 01, 2016 at 10:57:57AM +0100, Nicolas George wrote: Le nonidi 29 pluviôse, an CCXXIV, Bodecs Bela a écrit : I have checked the code where and when duration filled and made some reasoning about it. Duration value for input files has been populated some time after opening. (estimate_timings function in utils.c) And never again corrected or called this function.. So, if early in processing there is no duration info, it remains empty. When input is not a seekable file but a not-seekable stream, the only chance to get a duration info when the stream itself contains info about this value. (eg. flv metadata, mp4-moov) But mpegts format does not contain this info. So the only moment when duration calculatable is when we finish the reading. I think contoniously updating the duration value after each packet would not be a good idea. (cur_dts is updated is AVStream->info struct) So reading a file via pipe or reading hls stream via http it is normal that duration value remains empty. thus, I think to handle the cases when duration value is not populated, this is not a bug fix but a reasonable solution for these cases. I agree with you that we should not "measure" our-own the pts values but I could not find any existing/available data member to have this info. Sorry for the late reply, I was distracted. If I summarize correctly your findings: For formats without a reliable duration header with seekable backing, the duration is evaluated at the opening by peeking at the last timestamps. With unseekable backing, the duration is not evaluated at all. In particular, the duration is not updated once the end of the file is reached. Well, I thought it was and wrote the code in consequence, thanks for correcting me. Still, the logic for tracking the duration can be a bit tricky, possibly trickier than your original patch if there are B-frames and timestamps resets. I would rather have it in a common part of the code than in the concat demuxer. I suspect we could consider adding AVStream.current_duration that tracks the maximum recently seen PTS for each stream. (We could also have a function that peeks in AVStream.pts_buffer, but that looks tricky; and the corresponding duration is not available.) I hope other can give advice about this issue. somewhat independant of this, but i thik some kind of "indexer" input would be usefull i mean a input format that opens another input and sequentially reads the whole at open and creates an index with that exact seeking, exact bitrate, exact duration would become available. the index could also be stored in a on disk cache if the user wants making repeated opening of the same file not require sequentially scaning the whole [...] like a lookup map ___ 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] remove the hls_wrap option
2016.03.26. 15:10 keltezéssel, Steven Liu írta:
Because the hls_flags use delete_segments flag can delete the old
segment files and instead of the hls_wrap option, so remove it.
I suggest to leave hls_wrap option to be available. If you use this
option, the set of output file names is the same as the value of
hls_wrap, so it depends on you and sometimes it is very convinent.
Mainly when you use ffmpeg in scripting environment.
Signed-off-by: LiuQi
---
doc/muxers.texi | 9 -
libavformat/hlsenc.c | 8 +++-
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c36c72c..4dabfd1 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -284,15 +284,6 @@ Set output format options using a :-separated list of
key=value
parameters. Values containing @code{:} special characters must be
escaped.
-@item hls_wrap @var{wrap}
-Set the number after which the segment filename number (the number
-specified in each segment file) wraps. If set to 0 the number will be
-never wrapped. Default value is 0.
-
-This option is useful to avoid to fill the disk with many segment
-files, and limits the maximum number of segment files written to disk
-to @var{wrap}.
-
@item start_number @var{number}
Start the playlist sequence number from @var{number}. Default value is
0.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index fd36b21..a22543a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -84,7 +84,6 @@ typedef struct HLSContext {
float time;// Set by a private option.
int max_nb_segments; // Set by a private option.
-int wrap; // Set by a private option.
uint32_t flags;// enum HLSFlags
uint32_t pl_type; // enum PlaylistType
char *segment_filename;
@@ -373,7 +372,7 @@ static int hls_append_segment(struct AVFormatContext
*s, HLSContext *hls, double
en = hls->segments;
hls->segments = en->next;
if (en && hls->flags & HLS_DELETE_SEGMENTS &&
-!(hls->flags & HLS_SINGLE_FILE || hls->wrap)) {
+!(hls->flags & HLS_SINGLE_FILE)) {
en->next = hls->old_segments;
hls->old_segments = en;
if ((ret = hls_delete_old_segments(hls)) < 0)
@@ -561,13 +560,13 @@ static int hls_start(AVFormatContext *s)
av_free(fn_copy);
}
} else if (av_get_frame_filename(oc->filename,
sizeof(oc->filename),
- c->basename, c->wrap ? c->sequence %
c->wrap : c->sequence) < 0) {
+ c->basename, c->sequence) < 0) {
av_log(oc, AV_LOG_ERROR, "Invalid segment filename template
'%s' you can try use -use_localtime 1 with it\n", c->basename);
return AVERROR(EINVAL);
}
if( c->vtt_basename) {
if (av_get_frame_filename(vtt_oc->filename,
sizeof(vtt_oc->filename),
- c->vtt_basename, c->wrap ? c->sequence %
c->wrap : c->sequence) < 0) {
+ c->vtt_basename, c->sequence) < 0) {
av_log(vtt_oc, AV_LOG_ERROR, "Invalid segment filename
template '%s'\n", c->vtt_basename);
return AVERROR(EINVAL);
}
@@ -911,7 +910,6 @@ static const AVOption options[] = {
{"hls_list_size", "set maximum number of playlist entries",
OFFSET(max_nb_segments),AV_OPT_TYPE_INT,{.i64 = 5}, 0, INT_MAX,
E},
{"hls_ts_options","set hls mpegts list of options for the container
format used for hls", OFFSET(format_options_str), AV_OPT_TYPE_STRING, {.str
= NULL}, 0, 0,E},
{"hls_vtt_options","set hls vtt list of options for the container
format used for hls", OFFSET(vtt_format_options_str), AV_OPT_TYPE_STRING,
{.str = NULL}, 0, 0,E},
-{"hls_wrap", "set number after which the index wraps",
OFFSET(wrap),AV_OPT_TYPE_INT,{.i64 = 0}, 0, INT_MAX, E},
{"hls_allow_cache", "explicitly set whether the client MAY (1) or MUST
NOT (0) cache media segments", OFFSET(allowcache), AV_OPT_TYPE_INT, {.i64 =
-1}, INT_MIN, INT_MAX, E},
{"hls_base_url", "url to prepend to each playlist entry",
OFFSET(baseurl), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
{"hls_segment_filename", "filename template for segment files",
OFFSET(segment_filename), AV_OPT_TYPE_STRING, {.str = NULL},
0, 0, E},
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FFmpeg 3.1 name
2016.06.23. 23:23 keltezéssel, Paul B Mahol írta: On 6/23/16, Rostislav Pehlivanov wrote: On 23 June 2016 at 22:00, Michael Niedermayer wrote: Hi all what shall FFmpeg 3.1 be called ? I still have these ideas from past suggestions: Von Neumann, Einstein, lorentz, poincare, desitter, de broglie, Gauss, Galois, Viterbi, Darwin Are there other suggestions? Is something preferred ? In absence of any preferrance ill pick something randomly Thanks -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No great genius has ever existed without some touch of madness. -- Aristotle ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Laplace. Carl ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel Lorentz or Laplace And a suggestion for later times: Heaviside https://en.wikipedia.org/wiki/Oliver_Heaviside best, Bela ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: strftime identifiers and segment index in segment filenames
Dear All,
Putting date/time values into segment filenames is very usefull.
But to produce non-conflicting segment filenames with -use_localtime
option with date/time
values in hls_segment_filename option, sometimes is not enough.
Like in cases when multiple segments produced in the same second.
But hlsenc currently does not make possible to use segment index (%d) at the
same time whe use_localtime is in effect, due to identifier conflict.
This patch makes possible to use strftime identifiers and still put
segment index (%d) at same time in segment filenames by introducing
second_level_segment_index flag. When -use_localtime is active,
identifier %d is for month day index, so %%d is the segment index
placeholder. This enhanced behaviour only exists when new
second_level_segment_index flag is specified.
For instance putting 'segment_%Y%m%d%H%M%S_%%05d.ts' value into
-hls_segment_filename option and specifing -hls_flags
second_level_segment_index and -use_localtime 1, may produce segment
filename as 'segment_20161230235758_2.ts'
An example:
ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i anullsrc=r=44100:cl=stereo -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags delete_segments+second_level_segment_index -use_localtime 1
-hls_segment_filename "segment_%Y%m%d%H%M%S_%%05d.ts" stream.m3u8
will produce segments filenames:
segment_20161227005902_00013.ts
segment_20161227005902_00014.ts
segment_20161227005902_00015.ts
segment_20161227005903_00016.ts
segment_20161227005903_00017.ts
segment_20161227005903_00018.ts
segment_20161227005903_00019.ts
segment_20161227005903_00020.ts
thank you,
best regards,
Bela Bodecs
>From 2b1025485a74337030f05d96bb24238fc4fd92c0 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Tue, 27 Dec 2016 02:16:45 +0100
Subject: [PATCH] avformat/hlsenc: strftime identifiers and segment index
in filenames
Putting date/time values into segment filenames is very usefull.
But to produce non-conflicting segment filenames with -use_localtime
option with date/time
values in hls_segment_filename option, sometimes is not enough.
Like in cases when multiple segments produced in the same second.
But hlsenc currently does not make possible to use segment index (%d) at
the
same time whe use_localtime is in effect, due to identifier conflict.
This patch makes possible to use strftime identifiers and still put
segment index (%d) at same time in segment filenames by introducing
second_level_segment_index flag. When -use_localtime is active,
identifier %d is for month day index, so %%d is the segment index
placeholder. This enhanced behaviour only exists when new
second_level_segment_index flag is specified.
For instance putting 'segment_%Y%m%d%H%M%S_%%05d.ts' value into
-hls_segment_filename option and specifing -hls_flags
second_level_segment_index and -use_localtime 1, may produce segment
filename as 'segment_20161230235758_2.ts'
An example:
ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i anullsrc=r=44100:cl=stereo -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags delete_segments+second_level_segment_index -use_localtime 1
-hls_segment_filename "segment_%Y%m%d%H%M%S_%%05d.ts" stream.m3u8
will produce segments filenames:
segment_20161227005902_00013.ts
segment_20161227005902_00014.ts
segment_20161227005902_00015.ts
segment_20161227005903_00016.ts
segment_20161227005903_00017.ts
segment_20161227005903_00018.ts
segment_20161227005903_00019.ts
segment_20161227005903_00020.ts
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 11 ++-
libavformat/hlsenc.c | 22 --
2 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 075b8d3..3520120 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -443,12 +443,18 @@ This example will produce the playlist, @file{out.m3u8}, and segment files:
@item use_localtime
Use strftime on @var{filename} to expand the segment filename with localtime.
-The segment number (%d) is not available in this mode.
+The segment number is also available in this mode, but to use it, you need to specify second_level_segment_index
+hls_flag and %%d will be the specifier.
@example
ffmpeg -i in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+@example
+ffmpeg -i in.nut -use_localtime 1 -hls_flags second_level_segment_index -hls_segment_filename 'file-%Y%m%d-%%04d.ts' out.m3u8
+@end example
+This example will produce the playlist, @file{out.m3u8}, and segment files:
+@file{file-20160215-0001.ts}, @file{file-20160215-0002.ts}, etc.
@item use_localtime_mkdir
Used together with
[FFmpeg-devel] [PATCH] libavformat/hlsenc: fix delete_segments when use_localtime_mkdir
Dear All,
when delete_segments hls_flag is specified, deleting old segments may
fail in certain cases when use_localtime_mkdir is in effect and
hls_segment_filename expression contains subdirs. This patch fixes this
behaviour.
Command to reproduce the bug:
ffmpeg -loglevel info -y -re -f lavfi -i color=c=red:size=640x480:r=25
-f lavfi -i anullsrc=r=44100:cl=stereo -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags delete_segments -use_localtime_mkdir 1 -use_localtime 1
-hls_segment_filename "bb/bb%Y%m%d%H%I%S.ts" stream.m3u8
thank you in advance,
Bela Bodecs
>From ac4c24c2826d2704e595fbde515b184429a64073 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Thu, 29 Dec 2016 00:30:00 +0100
Subject: [PATCH 1/1] libavformat/hlsenc: fix delete_segments when
use_localtime_mkdir
When delete_segments hls_flag is specified, deleting old segments may
fail in certain cases when use_localtime_mkdir is in effect and
hls_segment_filename expression contains subdirs. This patch fixes this
behaviour.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index cf4d4bd..c9d8e3c 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -194,7 +194,7 @@ static int hls_delete_old_segments(HLSContext *hls) {
}
}
-if (segment) {
+if (segment && !hls->use_localtime_mkdir) {
if (hls->segment_filename) {
dirname = av_strdup(hls->segment_filename);
} else {
@@ -211,15 +211,20 @@ static int hls_delete_old_segments(HLSContext *hls) {
while (segment) {
av_log(hls, AV_LOG_DEBUG, "deleting old segment %s\n",
segment->filename);
-path_size = strlen(dirname) + strlen(segment->filename) + 1;
+path_size = (hls->use_localtime_mkdir ? 0 : strlen(dirname)) + strlen(segment->filename) + 1;
path = av_malloc(path_size);
if (!path) {
ret = AVERROR(ENOMEM);
goto fail;
}
-av_strlcpy(path, dirname, path_size);
-av_strlcat(path, segment->filename, path_size);
+if (hls->use_localtime_mkdir)
+av_strlcpy(path, segment->filename, path_size);
+else { // segment->filename contains basename only
+av_strlcpy(path, dirname, path_size);
+av_strlcat(path, segment->filename, path_size);
+}
+
if (unlink(path) < 0) {
av_log(hls, AV_LOG_ERROR, "failed to delete old segment %s: %s\n",
path, strerror(errno));
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] libavformat/hlsenc + configure: question about default strftime() format string
Dear All, in hlcenc.c, in the hls_write_header() function the default format string for strftime() function contains %s specifier. const char *pattern_localtime_fmt = "-%s.ts"; This %s specifier will insert the seconds since EPOCH. But %s is not available on all system/environment. I have found this bug, but to retain current behavior, this situation is manageable by a test-run of strftime() with %s and only if it fails then alter the format string for something else. But I thought that It should be handled at preprocessing like: #if HAVE const char *pattern_localtime_fmt = "-%s.ts"; #else const char *pattern_localtime_fmt = "-%Y%m%d%H%I%S.ts"; #endif I tried to find in config.h something similar like #define HAVE_EPOCH_SECONDS 1, but did not find. My questions are the followings: 1. is there a pre-defined config parameter to use here? 2. If not, is there a prefered way: a new config parameter on %s availability or a function to test the %s parameter availability at runtime? thank you in advance, Bela Bodecs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavformat/hlsenc + configure: question about default strftime() format string
2016.12.29. 3:33 keltezéssel, Steven Liu írta: 2016-12-29 8:32 GMT+08:00 Bodecs Bela : Dear All, in hlcenc.c, in the hls_write_header() function the default format string for strftime() function contains %s specifier. const char *pattern_localtime_fmt = "-%s.ts"; This %s specifier will insert the seconds since EPOCH. But %s is not available on all system/environment. I have found this bug, but to retain current behavior, this situation is manageable by a test-run of strftime() with %s and only if it fails then alter the format string for something else. But I thought that It should be handled at preprocessing like: #if HAVE const char *pattern_localtime_fmt = "-%s.ts"; #else const char *pattern_localtime_fmt = "-%Y%m%d%H%I%S.ts"; #endif I tried to find in config.h something similar like #define HAVE_EPOCH_SECONDS 1, but did not find. My questions are the followings: 1. is there a pre-defined config parameter to use here? 2. If not, is there a prefered way: a new config parameter on %s availability or a function to test the %s parameter availability at runtime? thank you in advance, You can refer to configure file HAVE_LIST to support this option. I have investigated and concluded that %s support may change by installing new modul/kernel, so I stick to check %s availability at runtime. I will send patch soon. Bela Bodecs ___ 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] [PATCH] libavformat/hlsenc: default segment name and, use_localtime
Dear All, in hlcenc.c, in the hls_write_header() function the default format string for strftime() function contains %s specifier when use_localtime is true. This %s specifier will insert the seconds since EPOCH. But %s is not available on all system/environment. This patch checks %s availabilty at runtine and alter the default format string if necessary. thank you, Bela Bodecs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: default segment name and, use_localtime
2016.12.30. 18:11 keltezéssel, Moritz Barsnick írta:
On Fri, Dec 30, 2016 at 15:38:25 +0100, Bodecs Bela wrote:
is not available on all system/environment. This patch checks %s
availabilty at runtine and alter the default format string if necessary.
You forgot to add the patch.
please, forgive me. I attached it now.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Bela
>From 00530d632427c8e9170e0aff6b807a704af60e51 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 30 Dec 2016 15:15:39 +0100
Subject: [PATCH] libavformat/hlsenc: default segment name and
use_localtime
in hlcenc.c, in the hls_write_header() function the default format
string for strftime() function contains %s specifier when use_localtime
is true. This %s specifier will insert the seconds since EPOCH. But %s
is not available on all system/environment. This patch check %s
availabilty at runtine and alter the default format string if necessary.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c9d8e3c..76b85e8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -829,13 +829,22 @@ fail:
return err;
}
+static const char * get_default_pattern_localtime_fmt(void)
+{
+char b[21];
+time_t t = time(NULL);
+struct tm *p, tmbuf;
+p = localtime_r(&t, &tmbuf);
+return (strftime(b, sizeof(b), "%s", p) > 2) ? "-%s.ts" : "-%Y%m%d%H%I%S.ts";
+}
+
static int hls_write_header(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
int ret, i;
char *p;
const char *pattern = "%d.ts";
-const char *pattern_localtime_fmt = "-%s.ts";
+const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt();
const char *vtt_pattern = "%d.vtt";
AVDictionary *options = NULL;
int basename_size;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: default segment name and, use_localtime
2016.12.31. 11:48 keltezéssel, Steven Liu írta:
2016-12-31 1:24 GMT+08:00 Bodecs Bela :
2016.12.30. 18:11 keltezéssel, Moritz Barsnick írta:
On Fri, Dec 30, 2016 at 15:38:25 +0100, Bodecs Bela wrote:
is not available on all system/environment. This patch checks %s
availabilty at runtine and alter the default format string if necessary.
You forgot to add the patch.
please, forgive me. I attached it now.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Bela
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c9d8e3c..76b85e8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -829,13 +829,22 @@ fail:
return err;
}
+static const char * get_default_pattern_localtime_fmt(void)
+{
+char b[21];
+time_t t = time(NULL);
+struct tm *p, tmbuf;
+p = localtime_r(&t, &tmbuf);
+return (strftime(b, sizeof(b), "%s", p) > 2) ? "-%s.ts" :
"-%Y%m%d%H%I%S.ts";
Why check strftime result bigger than 2,not 1 not 3?
I have faced different strftime behaviours on two different environments
where unknown specifier was in format string.
On one of them strftime returned 0, this was the expected return value
by me.
But on the other one, strftime returned 2 and put unknown specifier (%s)
as is into the result buffer.
So >2 will handle each cases. In normal behaviour, nowadays, length of
seconds string will be always longer than 2.
Should I put a comment about it into the code?
+}
+
static int hls_write_header(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
int ret, i;
char *p;
const char *pattern = "%d.ts";
-const char *pattern_localtime_fmt = "-%s.ts";
+const char *pattern_localtime_fmt =
get_default_pattern_localtime_fmt();
const char *vtt_pattern = "%d.vtt";
AVDictionary *options = NULL;
int basename_size;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/hlsenc: default segment name and, use_localtime
2016.12.31. 14:19 keltezéssel, Steven Liu írta:
2016-12-31 19:16 GMT+08:00 Bodecs Bela :
2016.12.31. 11:48 keltezéssel, Steven Liu írta:
2016-12-31 1:24 GMT+08:00 Bodecs Bela :
2016.12.30. 18:11 keltezéssel, Moritz Barsnick írta:
On Fri, Dec 30, 2016 at 15:38:25 +0100, Bodecs Bela wrote:
is not available on all system/environment. This patch checks %s
availabilty at runtine and alter the default format string if
necessary.
You forgot to add the patch.
please, forgive me. I attached it now.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Bela
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 11 ++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c9d8e3c..76b85e8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -829,13 +829,22 @@ fail:
return err;
}
+static const char * get_default_pattern_localtime_fmt(void)
+{
+char b[21];
+time_t t = time(NULL);
+struct tm *p, tmbuf;
+p = localtime_r(&t, &tmbuf);
+return (strftime(b, sizeof(b), "%s", p) > 2) ? "-%s.ts" :
"-%Y%m%d%H%I%S.ts";
Why check strftime result bigger than 2,not 1 not 3?
I have faced different strftime behaviours on two different environments
where unknown specifier was in format string.
On one of them strftime returned 0, this was the expected return value by
me.
But on the other one, strftime returned 2 and put unknown specifier (%s)
as is into the result buffer.
So >2 will handle each cases. In normal behaviour, nowadays, length of
seconds string will be always longer than 2.
Should I put a comment about it into the code?
Maybe add a comment for the value 2 is better.
you are right. I have changed the testing line to be more self-explanatory.
I have attached the new patch.
+}
+
static int hls_write_header(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
int ret, i;
char *p;
const char *pattern = "%d.ts";
-const char *pattern_localtime_fmt = "-%s.ts";
+const char *pattern_localtime_fmt =
get_default_pattern_localtime_fmt();
const char *vtt_pattern = "%d.vtt";
AVDictionary *options = NULL;
int basename_size;
___
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
>From 5f1b673d9ee48139ebe5f3d26bae9c2195e92678 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 31 Dec 2016 17:54:39 +0100
Subject: [PATCH] libavformat/hlsenc: default segment name and
use_localtime
in hlcenc.c, in the hls_write_header() function the default format
string for strftime() function contains %s specifier when use_localtime
is true. This %s specifier will insert the seconds since EPOCH. But %s
is not available on all system/environment. This patch check %s
availabilty at runtine and alter the default format string if necessary.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index c9d8e3c..57fc9c1 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -829,13 +829,23 @@ fail:
return err;
}
+static const char * get_default_pattern_localtime_fmt(void)
+{
+char b[21];
+time_t t = time(NULL);
+struct tm *p, tmbuf;
+p = localtime_r(&t, &tmbuf);
+// no %s support when strftime returned error or left format string unchanged
+return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? "-%Y%m%d%H%I%S.ts" : "-%s.ts";
+}
+
static int hls_write_header(AVFormatContext *s)
{
HLSContext *hls = s->priv_data;
int ret, i;
char *p;
const char *pattern = "%d.ts";
-const char *pattern_localtime_fmt = "-%s.ts";
+const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt();
const char *vtt_pattern = "%d.vtt";
AVDictionary *options = NULL;
int basename_size;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: Duplicated segment filenames and use_localtime_mkdir
Dear All,
current implementation of finding duplicated segment filenames may fail
if use_localtime_mkdir and use_localtime are in effect and
segment_filename option expression contains subdirectories with
date/time specifiers in them.
This patch fixes this false behaviour.
thank you,
Bela
>From d2348ff291279e22d31c6d4f6ca09a5bef0c1ea0 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sat, 31 Dec 2016 17:23:08 +0100
Subject: [PATCH] Duplicated segment filenames and use_localtime_mkdir
Current implementation of finding duplicate segment filenames may fail
if use_localtime_mkdir and use_localtime are in effect and
segment_filename option expression contains subdirectories with
date/time specifiers in them. This patch fixes this false behaviour.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 50 ++
1 file changed, 14 insertions(+), 36 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 57fc9c1..67df1cf 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -367,6 +367,16 @@ static int hls_mux_init(AVFormatContext *s)
return 0;
}
+static HLSSegment *find_segment_by_filename(HLSSegment *segment, const char *filename)
+{
+while (segment) {
+if (!strcmp(segment->filename,filename))
+return segment;
+segment = segment->next;
+}
+return (HLSSegment *) NULL;
+}
+
/* Create a new segment and append it to the segment list */
static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, double duration,
int64_t pos, int64_t size)
@@ -383,6 +393,10 @@ static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, double
if (hls->use_localtime_mkdir) {
filename = hls->avf->filename;
}
+if (find_segment_by_filename(hls->segments, filename)
+|| find_segment_by_filename(hls->old_segments, en->filename)) {
+av_log(hls, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n", filename);
+}
av_strlcpy(en->filename, filename, sizeof(en->filename));
if(hls->has_subtitle)
@@ -659,38 +673,6 @@ fail:
return ret;
}
-static HLSSegment *find_segment_by_filename(HLSSegment *segment, const char *filename)
-{
-/* filename may contain rel/abs path, but segments store only basename */
-char *p = NULL, *dirname = NULL, *path = NULL;
-int path_size;
-HLSSegment *ret_segment = NULL;
-dirname = av_strdup(filename);
-if (!dirname)
-return NULL;
-p = (char *)av_basename(dirname); // av_dirname would return . in case of no dir
-*p = '\0'; // maybe empty
-
-while (segment) {
-path_size = strlen(dirname) + strlen(segment->filename) + 1;
-path = av_malloc(path_size);
-if (!path)
-goto end;
-av_strlcpy(path, dirname, path_size);
-av_strlcat(path, segment->filename, path_size);
-if (!strcmp(path,filename)) {
-ret_segment = segment;
-av_free(path);
-goto end;
-}
-av_free(path);
-segment = segment->next;
-}
-end:
-av_free(dirname);
-return ret_segment;
-}
-
static int hls_start(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
@@ -736,10 +718,6 @@ static int hls_start(AVFormatContext *s)
}
av_free(filename);
}
-if (find_segment_by_filename(c->segments, oc->filename)
-|| find_segment_by_filename(c->old_segments, oc->filename)) {
-av_log(c, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n", oc->filename);
-}
if (c->use_localtime_mkdir) {
const char *dir;
char *fn_copy = av_strdup(oc->filename);
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: Duplicated segment filenames and use_localtime_mkdir
2017.01.01. 12:57 keltezéssel, Steven Liu írta:
2017-01-01 19:40 GMT+08:00 Bodecs Bela :
Dear All,
current implementation of finding duplicated segment filenames may fail if
use_localtime_mkdir and use_localtime are in effect and segment_filename
option expression contains subdirectories with date/time specifiers in them.
This patch fixes this false behaviour.
thank you,
Bela
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+static HLSSegment *find_segment_by_filename(HLSSegment *segment, const
char *filename)
+{
+while (segment) {
+if (!strcmp(segment->filename,filename))
+return segment;
+segment = segment->next;
+}
+return (HLSSegment *) NULL;
+}
+
use av_strcasecmp will better。
yes, I have changed it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 1fec0300d75130f3c398ef3a4a403886a5016916 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sun, 1 Jan 2017 13:11:08 +0100
Subject: [PATCH] Duplicated segment filenames and use_localtime_mkdir
Current implementation of finding duplicate segment filenames may fail
if use_localtime_mkdir and use_localtime are in effect and
segment_filename option expression contains subdirectories with
date/time specifiers. This patch fixes this false behaviour.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 50 ++
1 file changed, 14 insertions(+), 36 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 57fc9c1..591ab73 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -367,6 +367,16 @@ static int hls_mux_init(AVFormatContext *s)
return 0;
}
+static HLSSegment *find_segment_by_filename(HLSSegment *segment, const char *filename)
+{
+while (segment) {
+if (!av_strcasecmp(segment->filename,filename))
+return segment;
+segment = segment->next;
+}
+return (HLSSegment *) NULL;
+}
+
/* Create a new segment and append it to the segment list */
static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, double duration,
int64_t pos, int64_t size)
@@ -383,6 +393,10 @@ static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, double
if (hls->use_localtime_mkdir) {
filename = hls->avf->filename;
}
+if (find_segment_by_filename(hls->segments, filename)
+|| find_segment_by_filename(hls->old_segments, en->filename)) {
+av_log(hls, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n", filename);
+}
av_strlcpy(en->filename, filename, sizeof(en->filename));
if(hls->has_subtitle)
@@ -659,38 +673,6 @@ fail:
return ret;
}
-static HLSSegment *find_segment_by_filename(HLSSegment *segment, const char *filename)
-{
-/* filename may contain rel/abs path, but segments store only basename */
-char *p = NULL, *dirname = NULL, *path = NULL;
-int path_size;
-HLSSegment *ret_segment = NULL;
-dirname = av_strdup(filename);
-if (!dirname)
-return NULL;
-p = (char *)av_basename(dirname); // av_dirname would return . in case of no dir
-*p = '\0'; // maybe empty
-
-while (segment) {
-path_size = strlen(dirname) + strlen(segment->filename) + 1;
-path = av_malloc(path_size);
-if (!path)
-goto end;
-av_strlcpy(path, dirname, path_size);
-av_strlcat(path, segment->filename, path_size);
-if (!strcmp(path,filename)) {
-ret_segment = segment;
-av_free(path);
-goto end;
-}
-av_free(path);
-segment = segment->next;
-}
-end:
-av_free(dirname);
-return ret_segment;
-}
-
static int hls_start(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
@@ -736,10 +718,6 @@ static int hls_start(AVFormatContext *s)
}
av_free(filename);
}
-if (find_segment_by_filename(c->segments, oc->filename)
-|| find_segment_by_filename(c->old_segments, oc->filename)) {
-av_log(c, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n", oc->filename);
-}
if (c->use_localtime_mkdir) {
const char *dir;
char *fn_copy = av_strdup(oc->filename);
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename, use_localtime, , use_localtime_mkdir, hls_flags
Dear All, I added some more details and example to hls muxer documentation. I reformatted hls_flags option list to table. thank you, Bela Bodecs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename, use_localtime, , use_localtime_mkdir, hls_flags
2017.01.02. 0:12 keltezéssel, Steven Liu írta:
2017-01-02 5:53 GMT+08:00 Bodecs Bela :
Dear All,
I added some more details and example to hls muxer documentation. I
reformatted hls_flags option list to table.
Where is the patch?
I am sorry. I have atteched it now,
thank you,
Bela Bodecs
___
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
>From ea151c46c50e4b717d71f605ce57ffd345f62bb6 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sun, 1 Jan 2017 22:48:27 +0100
Subject: [PATCH] doc/hlsenc: hls_segment_filename, use_localtime,
use_localtime_mkdir
added some more details and example. hls_flags option list reformatted
to table
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2598b2..e8a883f 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,15 +441,20 @@ ffmpeg -i in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
+@var{filename} may contain full path or relative path specification, but only the file name part without any path info will be contained in the m3u8 segment list.
+Should relative path is specified, path of created segment files will be relative to the current working directory.
+When use_localtime_mkdir is set, the whole expanded value of @var{filename} will be written into m3u8 segment list.
+
+
@item use_localtime
-Use strftime on @var{filename} to expand the segment filename with localtime.
+Use strftime() on @var{filename} to expand the segment filename with localtime.
The segment number is also available in this mode, but to use it, you need to specify second_level_segment_index
hls_flag and %%d will be the specifier.
@example
ffmpeg -i in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will produce the playlist, @file{out.m3u8}, and segment files:
-@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc. (Notice: in some systems/environments %s specifier is not available. See strftime() documentation!)
@example
ffmpeg -i in.nut -use_localtime 1 -hls_flags second_level_segment_index -hls_segment_filename 'file-%Y%m%d-%%04d.ts' out.m3u8
@end example
@@ -457,14 +462,21 @@ This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-0001.ts}, @file{file-20160215-0002.ts}, etc.
@item use_localtime_mkdir
-Used together with -use_localtime, it will create up to one subdirectory which
+Used together with use_localtime, it will create all subdirectories which
is expanded in @var{filename}.
@example
ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will create a directory 201560215 (if it does not exist), and then
produce the playlist, @file{out.m3u8}, and segment files:
-@file{201560215/file-20160215-1455569023.ts}, @file{201560215/file-20160215-1455569024.ts}, etc.
+@file{20160215/file-20160215-1455569023.ts}, @file{20160215/file-20160215-1455569024.ts}, etc.
+
+@example
+ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename '%Y/%m/%d/file-%Y%m%d-%s.ts' out.m3u8
+@end example
+This example will create a directory hierarchy 2016/02/15 (if any of them does not exist), and then
+produce the playlist, @file{out.m3u8}, and segment files:
+@file{2016/02/15/file-20160215-1455569023.ts}, @file{2016/02/15/file-20160215-1455569024.ts}, etc.
@item hls_key_info_file @var{key_info_file}
@@ -523,7 +535,12 @@ ffmpeg -f lavfi -re -i testsrc -c:v h264 -hls_flags delete_segments \
-hls_key_info_file file.keyinfo out.m3u8
@end example
-@item hls_flags single_file
+
+@item hls_flags @var{flags}
+Possible values:
+
+@table @samp
+@item single_file
If this flag is set, the muxer will store all segments in a single MPEG-TS
file, and will use byte ranges in the playlist. HLS playlists generated with
this way will have the version number 4.
@@ -534,37 +551,39 @@ ffmpeg -i in.nut -hls_flags single_file out.m3u8
Will produce the playlist, @file{out.m3u8}, and a single segment file,
@file{out.ts}.
-@item hls_flags delete_segments
+@item delete_segments
Segment files removed from the playlist are deleted after a period of time
equal to the duration of the segment plus the duration of the playlist.
-@item hls_flags append_list
+@item append_list
Append new segments into the
Re: [FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename, use_localtime, , use_localtime_mkdir, hls_flags
2017.01.02. 1:29 keltezéssel, Steven Liu írta:
2017-01-02 7:22 GMT+08:00 Bodecs Bela :
2017.01.02. 0:12 keltezéssel, Steven Liu írta:
2017-01-02 5:53 GMT+08:00 Bodecs Bela :
Dear All,
I added some more details and example to hls muxer documentation. I
reformatted hls_flags option list to table.
Where is the patch?
I am sorry. I have atteched it now,
thank you,
Bela Bodecs
___
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
title： doc/hlsenc to doc/muxers
text:
-Used together with -use_localtime, it will create up to one subdirectory
which
+Used together with use_localtime, it will create all subdirectories which
change to
-Used together with -use_localtime, it will create up to one subdirectory
which
+Used together with -use_localtime, it will create all subdirectories which
I have corrected.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 18a85221d6c7044baa0e40250bf18dfe165da777 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sun, 1 Jan 2017 22:48:27 +0100
Subject: [PATCH] doc/muxers: hls_segment_filename, use_localtime,
use_localtime_mkdir
added some more details and example. hls_flags option list reformatted
to table
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 45 -
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2598b2..3cb2918 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,15 +441,20 @@ ffmpeg -i in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
+@var{filename} may contain full path or relative path specification, but only the file name part without any path info will be contained in the m3u8 segment list.
+Should relative path is specified, path of created segment files will be relative to the current working directory.
+When -use_localtime_mkdir is set, the whole expanded value of @var{filename} will be written into m3u8 segment list.
+
+
@item use_localtime
-Use strftime on @var{filename} to expand the segment filename with localtime.
+Use strftime() on @var{filename} to expand the segment filename with localtime.
The segment number is also available in this mode, but to use it, you need to specify second_level_segment_index
hls_flag and %%d will be the specifier.
@example
ffmpeg -i in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will produce the playlist, @file{out.m3u8}, and segment files:
-@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc. (Notice: in some systems/environments %s specifier is not available. See strftime() documentation!)
@example
ffmpeg -i in.nut -use_localtime 1 -hls_flags second_level_segment_index -hls_segment_filename 'file-%Y%m%d-%%04d.ts' out.m3u8
@end example
@@ -457,14 +462,21 @@ This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-0001.ts}, @file{file-20160215-0002.ts}, etc.
@item use_localtime_mkdir
-Used together with -use_localtime, it will create up to one subdirectory which
+Used together with -use_localtime, it will create all subdirectories which
is expanded in @var{filename}.
@example
ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will create a directory 201560215 (if it does not exist), and then
produce the playlist, @file{out.m3u8}, and segment files:
-@file{201560215/file-20160215-1455569023.ts}, @file{201560215/file-20160215-1455569024.ts}, etc.
+@file{20160215/file-20160215-1455569023.ts}, @file{20160215/file-20160215-1455569024.ts}, etc.
+
+@example
+ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename '%Y/%m/%d/file-%Y%m%d-%s.ts' out.m3u8
+@end example
+This example will create a directory hierarchy 2016/02/15 (if any of them does not exist), and then
+produce the playlist, @file{out.m3u8}, and segment files:
+@file{2016/02/15/file-20160215-1455569023.ts}, @file{2016/02/15/file-20160215-1455569024.ts}, etc.
@item hls_key_info_file @var{key_info_file}
@@ -523,7 +535,12 @@ ffmpeg -f lavfi -re -i testsrc -c:v h264 -hls_flags delete_segments \
-hls_key_info_file file.keyinfo out.m3u8
Re: [FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename, use_localtime, , use_localtime_mkdir, hls_flags
2017.01.02. 13:54 keltezéssel, Moritz Barsnick írta:
On Mon, Jan 02, 2017 at 12:49:50 +0100, Bodecs Bela wrote:
Subject: [FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename,
use_localtime, , use_localtime_mkdir, hls_flags
^^
There's a ", " too much in that part of the commit message.
+@var{filename} may contain full path or relative path specification, but only
the file name part without any path info will be contained in the m3u8 segment
list.
You should break this line.
+Should relative path is specified, path of created segment files will be
relative to the current working directory.
->
Should a relative path be specified, the path of the created segment
files will be relative to the current working directory.
+When -use_localtime_mkdir is set, the whole expanded value of @var{filename}
will be written into m3u8 segment list.
^ I think you should omit the dashes, as these are primarily
library options, not command line options.
And do add an article: "... will be written into the m3u8 segment
list."
-@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
(Notice: in some systems/environments %s specifier is not available. See
strftime() documentation!)
->
Note: On some systems/environments, the code{%s} specifier is not available.
See
code{strftime()} documentation.
(Avoid exclamation marks.)
+This example will create a directory hierarchy 2016/02/15 (if any of them does
not exist), and then
^
do
Thank you. I have made all suggested changes.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 2720f2410feb9c51a6d37477f432780dc2594c5d Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Sun, 1 Jan 2017 22:48:27 +0100
Subject: [PATCH] doc/muxers: hls_segment_filename, use_localtime,
use_localtime_mkdir, hls_flags
added some more details and example. hls_flags option list reformatted
to table
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 47 +++
1 file changed, 35 insertions(+), 12 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2598b2..018f289 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,8 +441,15 @@ ffmpeg -i in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
+@var{filename} may contain full path or relative path specification,
+but only the file name part without any path info will be contained in the m3u8 segment list.
+Should a relative path be specified, the path of the created segment
+files will be relative to the current working directory.
+When use_localtime_mkdir is set, the whole expanded value of @var{filename} will be written into the m3u8 segment list.
+
+
@item use_localtime
-Use strftime on @var{filename} to expand the segment filename with localtime.
+Use strftime() on @var{filename} to expand the segment filename with localtime.
The segment number is also available in this mode, but to use it, you need to specify second_level_segment_index
hls_flag and %%d will be the specifier.
@example
@@ -450,6 +457,8 @@ ffmpeg -i in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' out.
@end example
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+Note: On some systems/environments, the @code{%s} specifier is not available. See
+ @code{strftime()} documentation.
@example
ffmpeg -i in.nut -use_localtime 1 -hls_flags second_level_segment_index -hls_segment_filename 'file-%Y%m%d-%%04d.ts' out.m3u8
@end example
@@ -457,14 +466,21 @@ This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-0001.ts}, @file{file-20160215-0002.ts}, etc.
@item use_localtime_mkdir
-Used together with -use_localtime, it will create up to one subdirectory which
+Used together with -use_localtime, it will create all subdirectories which
is expanded in @var{filename}.
@example
ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename '%Y%m%d/file-%Y%m%d-%s.ts' out.m3u8
@end example
This example will create a directory 201560215 (if it does not exist), and then
produce the playlist, @file{out.m3u8}, and segment files:
-@file{201560215/file-20160215-1455569023.ts}, @file{201560215/file-20160215-1455569024.ts}, etc.
+@file{20160215/file-20160215-1455569023.ts}, @file{20160215/file-20160215-1455569024.ts},
[FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
this will produce segments like this:
segment_20170102194334_0003_00122200_00300.ts
segment_20170102194334_0004_00120072_00300.ts
etc.
thank you in advance,
Bela Bodecs
>From 2c11ecb0875f5e9f147ddd8071df4832e97438de Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 2 Jan 2017 18:41:31 +0100
Subject: [PATCH] avformat/hlsenc: size and duration in segment filenames
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 154 ---
1 file changed, 147 insertions(+), 7 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 591ab73..aaa6b90 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -67,6 +67,8 @@ typedef enum HLSFlags {
HLS_APPEND_LIST = (1 << 6),
HLS_PROGRAM_DATE_TIME = (1 << 7),
HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in segment filenames when use_localtime e.g.: %%03d
+HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration (microsec) in segment filenames when use_localtime e.g.: %%09t
+HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) in segment filenames when use_localtime e.g.: %%014s
} HLSFlags;
typedef enum {
@@ -134,6 +136,7 @@ typedef struct HLSContext {
char *method;
double initial_prog_date_time;
+char current_segment_final_filename_fmt[1024]; // when renaming segments
} HLSContext;
static int mkdir_p(const char *path) {
@@ -169,6 +172,58 @@ static int mkdir_p(const char *path) {
return ret;
}
+static int replace_int_data_in_filename(char *buf, int buf_size, const char *filename, char placeholder, int64_t number)
+{
+const char *p;
+char *q, buf1[20], c;
+int nd, len, addchar_count;
+int found_count = 0;
+
+q = buf;
+p = filename;
+for (;;) {
+c = *p; //
+if (c == '\0')
+break;
+if (c == '%' && *(p+1) == '%') // %%
+addchar_count = 2;
+else if (c == '%' && (av_isdigit(*(p+1)) || *(p+1) == placeholder)) {
+nd = 0;
+addchar_count = 1;
+while (av_isdigit(*(p + addchar_count))) {
+nd = nd * 10 + *(p + addchar_count) - '0';
+addchar_count++;
+}
+
+if (*(p + addchar_count) == placeholder) {
+len = snprintf(buf1, sizeof(buf1), "%0*"PRId64, (number < 0) ? nd : nd++, number);
+if (len < 1) // returned error or empty buf1
+goto fail;
+if ((q - buf + len) > buf_size - 1)
+goto fail;
+memcpy(q, buf1, len);
+q += len;
+p += (addchar_count + 1);
+addchar_count = 0;
+found_count++;
+}
+
+} else
+addchar_count = 1;
+
+while (addchar_count--)
+if ((q - buf) < buf_size - 1)
+*q++ = *p++;
+else
+
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 2:34 keltezéssel, Steven Liu írta:
2017-01-03 8:22 GMT+08:00 Steven Liu :
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_
level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
this will produce segments like this:
segment_20170102194334_0003_00122200_00300.ts
segment_20170102194334_0004_00120072_00300.ts
etc.
thank you in advance,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
you should add document for the new option.
in +static int replace_int_data_in_filename(char *buf, int buf_size, const
char *filename, char placeholder, int64_t number)
+c = *p; //
will add comment?
in @@ -388,6 +443,38 @@ static int hls_append_segment(struct
AVFormatContext *s, HLSContext *hls, double
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
strlen(hls->current_segment_final_filename_fmt)) {
This is one line and the line is too long, maybe split to or three line be
better, The other too long line should be split.
I have shortened and splitted the lines and removed empty comment sign.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 31c9826fc8c0b68c87c94feea268cedacfb8ac9d Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 2 Jan 2017 18:41:31 +0100
Subject: [PATCH] avformat/hlsenc: size and duration in segment filenames
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 174 ---
1 file changed, 166 insertions(+), 8 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 591ab73..4975d2a 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -67,6 +67,8 @@ typedef enum HLSFlags {
HLS_APPEND_LIST = (1 << 6),
HLS_PROGRAM_DATE_TIME = (1 << 7),
HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in segment filenames when use_localtime e.g.: %%03d
+HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration (microsec) in segment filenames when use_localtime e.g.: %%09t
+HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) in segment filenames when use_localtime e.g.: %%014s
} HLSFlags;
typedef enum {
@@ -134,6 +136,7 @@ typedef struct HLSContext {
char *method;
double initial_prog_date_time;
+char current_segment_final_filename_fmt[1024]; // when renaming segments
} HLSContext;
static int mkdir_p(const char *path) {
@@ -169,6 +172,58 @@ static int mkdir_p(const char *path) {
return ret;
}
+static int replace_int_data_in_filename(char *buf, int buf_size, const char *filename, char placeholder, int64_t number)
+{
+const char *p;
+char *q, buf1[20], c;
+int nd, len, addchar_count;
+int found_count = 0;
+
+q = buf;
+p = filename;
+
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 1:22 keltezéssel, Steven Liu írta:
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_
level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
this will produce segments like this:
segment_20170102194334_0003_00122200_00300.ts
segment_20170102194334_0004_00120072_00300.ts
etc.
thank you in advance,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
you should add document for the new option.
I have enclosed it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 83346eaedb3d4be2ec0494ffd6f49244bf44c920 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Tue, 3 Jan 2017 09:34:38 +0100
Subject: [PATCH] doc/muxers: hls second_level_segment_duration,
second_level_segment_size
Documentation of new feature of hlsenc to include segment size and
duration in their name.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 018f289..b97e9f9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -584,7 +584,24 @@ seeking. This flag should be used with the @code{hls_time} option.
Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
@item second_level_segment_index
-Makes it possible to use segment indexes as %%d besides date/time values when use_localtime is on.
+Makes it possible to use segment indexes as %%d in hls_segment_filename expression besides date/time values when use_localtime is on. To get fixed width numbers with trailing zeroes, %%0xd format is available where x is the required width.
+
+@item second_level_segment_size
+Makes it possible to use segment sizes (counted in bytes) as %%s in hls_segment_filename expression besides date/time values when use_localtime is on. To get fixed width numbers with trailing zeroes, %%0xs format is available where x is the required width.
+
+@item second_level_segment_duration
+Makes it possible to use segment duration (calculated in microseconds) as %%t in hls_segment_filename expression besides date/time values when use_localtime is on. To get fixed width numbers with trailing zeroes, %%0xt format is available where x is the required width.
+
+@example
+./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 \
+ -f lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac -cutoff 2 -ac 2 -ar 44100 -ab 192k \
+ -f hls -hls_time 3 -hls_list_size 5 \
+ -hls_flags second_level_segment_index+second_level_segment_size+second_level_segment_duration \
+ -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename "segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
+@end example
+This will produce segments like this:
+@file{segment_20170102194334_0003_00122200_00300.ts}, @file{segment_20170102194334_0004_00120072_00300.ts} etc.
+
@end table
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 9:23 keltezéssel, Steven Liu írta:
2017-01-03 16:11 GMT+08:00 Bodecs Bela :
2017.01.03. 2:34 keltezéssel, Steven Liu írta:
2017-01-03 8:22 GMT+08:00 Steven Liu :
2017-01-03 2:58 GMT+08:00 Bodecs Bela :
Dear All,
this patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_
level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
this will produce segments like this:
segment_20170102194334_0003_00122200_00300.ts
segment_20170102194334_0004_00120072_00300.ts
etc.
thank you in advance,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
you should add document for the new option.
in +static int replace_int_data_in_filename(char *buf, int buf_size,
const
char *filename, char placeholder, int64_t number)
+c = *p; //
will add comment?
in @@ -388,6 +443,38 @@ static int hls_append_segment(struct
AVFormatContext *s, HLSContext *hls, double
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
strlen(hls->current_segment_final_filename_fmt)) {
This is one line and the line is too long, maybe split to or three line be
better, The other too long line should be split.
I have shortened and splitted the lines and removed empty comment sign.
___
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
for example:
+av_log(c, AV_LOG_ERROR,
+ "Invalid second level segment filename template
'%s', you can try to remove second_level_segment_index flag\n",
+av_log(c, AV_LOG_ERROR,"Invalid second level segment
filename template '%s', "
+ "you can try to remove
second_level_segment_index flag\n",
What about this?
ok, I have done.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 92c7985a32dabf6041a566dcb8f2f4d5da5a34d3 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Mon, 2 Jan 2017 18:41:31 +0100
Subject: [PATCH] avformat/hlsenc: size and duration in segment filenames
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 180 ---
1 file changed, 172 insertions(+), 8 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 591ab73..4b1f12f 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -67,6 +67,8 @@ typedef enum HLSFlags {
HLS_APPEND_LIST = (1 << 6),
HLS_PROGRAM_DATE_TIME = (1 << 7),
HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in segment filenames when use_localtime e.g.: %%03d
+HLS_SECOND_LEVEL_SEGMENT_DUR
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta:
On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
doc/muxers.texi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
You should probably squash this with the other patch, into one commit.
-Makes it possible to use segment indexes as %%d besides date/time values when
use_localtime is on.
+Makes it possible to use segment indexes as %%d in hls_segment_filename
expression besides date/time values when use_localtime is on. To get fixed
width numbers with trailing zeroes, %%0xd format is available where x is the
required width.
You could break these lines (texinfo formatting will handle the real
representation later), but I'm not sure it's totally necessary.
+@example
+./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 \
+ -f lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k \
+ -f hls -hls_time 3 -hls_list_size 5 \
a) replace ./ffmpeg with ffmpeg (as most users would expect to use it),
b) please use simpler syntax for the stuff not related to what you are
trying to document; i.e.: ffmpeg -i input.mov -f hls -hls_time 3 -hls_list_size
5 [...]
+This will produce segments like this:
+@file{segment_20170102194334_0003_00122200_00300.ts},
@file{segment_20170102194334_0004_00120072_00300.ts} etc.
I have made the suggested modifications.
The rest seems fine to me!
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 4d12c80ad8db7040053a2dbf52a7634fe7fca960 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Tue, 3 Jan 2017 09:34:38 +0100
Subject: [PATCH] doc/muxers: hls second_level_segment_duration,
second_level_segment_size
Documentation of new feature of hlsenc to include segment size and
duration in their name.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 24 +++-
1 file changed, 23 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 018f289..b4a107c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -584,7 +584,29 @@ seeking. This flag should be used with the @code{hls_time} option.
Generate @code{EXT-X-PROGRAM-DATE-TIME} tags.
@item second_level_segment_index
-Makes it possible to use segment indexes as %%d besides date/time values when use_localtime is on.
+Makes it possible to use segment indexes as %%d in hls_segment_filename expression
+besides date/time values when use_localtime is on.
+To get fixed width numbers with trailing zeroes, %%0xd format is available where x is the required width.
+
+@item second_level_segment_size
+Makes it possible to use segment sizes (counted in bytes) as %%s in hls_segment_filename
+expression besides date/time values when use_localtime is on.
+To get fixed width numbers with trailing zeroes, %%0xs format is available where x is the required width.
+
+@item second_level_segment_duration
+Makes it possible to use segment duration (calculated in microseconds) as %%t in hls_segment_filename
+expression besides date/time values when use_localtime is on.
+To get fixed width numbers with trailing zeroes, %%0xt format is available where x is the required width.
+
+@example
+ffmpeg -i sample.mpeg \
+ -f hls -hls_time 3 -hls_list_size 5 \
+ -hls_flags second_level_segment_index+second_level_segment_size+second_level_segment_duration \
+ -use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename "segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
+@end example
+This will produce segments like this:
+@file{segment_20170102194334_0003_00122200_00300.ts}, @file{segment_20170102194334_0004_00120072_00300.ts} etc.
+
@end table
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 12:48 keltezéssel, Steven Liu írta:
2017-01-03 19:41 GMT+08:00 Bodecs Bela :
2017.01.03. 11:42 keltezéssel, Moritz Barsnick írta:
On Tue, Jan 03, 2017 at 09:38:18 +0100, Bodecs Bela wrote:
doc/muxers.texi | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
You should probably squash this with the other patch, into one commit.
-Makes it possible to use segment indexes as %%d besides date/time values
when use_localtime is on.
+Makes it possible to use segment indexes as %%d in hls_segment_filename
expression besides date/time values when use_localtime is on. To get fixed
width numbers with trailing zeroes, %%0xd format is available where x is
the required width.
You could break these lines (texinfo formatting will handle the real
representation later), but I'm not sure it's totally necessary.
+@example
+./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 \
+ -f lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k \
+ -f hls -hls_time 3 -hls_list_size 5 \
a) replace ./ffmpeg with ffmpeg (as most users would expect to use it),
b) please use simpler syntax for the stuff not related to what you are
trying to document; i.e.: ffmpeg -i input.mov -f hls -hls_time 3
-hls_list_size 5 [...]
+This will produce segments like this:
+@file{segment_20170102194334_0003_00122200_00300.ts},
@file{segment_20170102194334_0004_00120072_00300.ts} etc.
I have made the suggested modifications.
The rest seems fine to me!
Moritz
___
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
make to commit into one commit,
like this:
doc/muxers.texi | 19 ++-
libavformat/hlsenc.c | 180
---
in one commit. make one patch.
I have technical difficulties to merge them into one commit. I am not a
git expert.
This muxers.texi patch is based on my earlier accepted, but yet not
applied doc patch on this same file.
I created the related code patch in a different local git branch. Now I
tried to merge the two local branches into one
but a terrible result occured when I created a common patch file.
Is it a problem to remain two seperate patches?
___
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] avformat/hlsenc: actual segment file size and duration in segment filenames
2017.01.03. 13:58 keltezéssel, Steven Liu írta:
2017-01-03 20:52 GMT+08:00 Moritz Barsnick :
On Tue, Jan 03, 2017 at 13:38:44 +0100, Bodecs Bela wrote:
I have technical difficulties to merge them into one commit. I am not a
git expert.
This muxers.texi patch is based on my earlier accepted, but yet not
applied doc patch on this same file.
I created the related code patch in a different local git branch. Now I
tried to merge the two local branches into one
but a terrible result occured when I created a common patch file.
I usually work on a local branch: feature-soandso.01
If I want to rearrange the patches, I create a new branch from master:
$ git checkout master
$ git pull
$ git checkout -b feature-soandso.02
then I can e.g. reintegrate those two commits as one:
$ git cherry-pick --no-commit
$ git cherry-pick --no-commit
$ git commit # don't forget to re-edit the now merged commit messages
and then I (re-)submit that last commit from this new branch to the
mailing list.
(Untested, from memory.) Good luck.
Is it a problem to remain two seperate patches?
I don't declare the recommendations on this list, I just interpret
them. ;-) Generally, there's no use in separating the doc from the
feature commit.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
try Moritz's way, and test base the attachement file maybe better.
ok, here it is. It was hard for me, but it includes all my 3 earlier
patches in one commit as you suggested.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From fbe330bd0bbd6e0a958b9196751641fb77b9e4ec Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Tue, 3 Jan 2017 15:01:34 +0100
Subject: [PATCH] avformat/hlsenc: size and duration in segment filenames
1st:
This patch makes it possible to put actual segment file size (measured
in bytes) and/or duration (calculated in microseconds) into segment
filenames. This feature is useful when post-processing live streaming
access log files. New behaviour works only when -use_localtime option
is set and second_level_segment_size or/and
second_level_segment_duration new hls_flags are specified. %%s is the
placeholder for size and %%t for duration in hls_segment_filename
option. Fix sized trailing zeropadding also works eg. %%09s or %%023t.
A command to test new features:
./ffmpeg -loglevel info -y -f lavfi -i color=c=red:size=640x480:r=25 -f
lavfi -i sine=f=440:b=4:r=44100 -c:v mpeg2video -g 25 -acodec aac
-cutoff 2 -ac 2 -ar 44100 -ab 192k -f hls -hls_time 3 -hls_list_size
5 -hls_flags
second_level_segment_index+second_level_segment_size+second_level_segment_duration
-use_localtime 1 -use_localtime_mkdir 1 -hls_segment_filename
"segment_%Y%m%d%H%M%S_%%04d_%%08s_%%013t.ts" stream.m3u8
2nd:
doc/muxers: beside second_level_segment_duration and second_level_segment_size,
added some more details and example to hls_segment_filename,
use_localtime, use_localtime_mkdir, hls_flags. hls_flags option list
reformatted to table
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 71
libavformat/hlsenc.c | 180 ---
2 files changed, 230 insertions(+), 21 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index c2598b2..b4a107c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -441,8 +441,15 @@ ffmpeg -i in.nut -hls_segment_filename 'file%03d.ts' out.m3u8
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file000.ts}, @file{file001.ts}, @file{file002.ts}, etc.
+@var{filename} may contain full path or relative path specification,
+but only the file name part without any path info will be contained in the m3u8 segment list.
+Should a relative path be specified, the path of the created segment
+files will be relative to the current working directory.
+When use_localtime_mkdir is set, the whole expanded value of @var{filename} will be written into the m3u8 segment list.
+
+
@item use_localtime
-Use strftime on @var{filename} to expand the segment filename with localtime.
+Use strftime() on @var{filename} to expand the segment filename with localtime.
The segment number is also available in this mode, but to use it, you need to specify second_level_segment_index
hls_flag and %%d will be the specifier.
@example
@@ -450,6 +457,8 @@ ffmpeg -i in.nut -use_localtime 1 -hls_segment_filename 'file-%Y%m%d-%s.ts' out.
@end example
This example will produce the playlist, @file{out.m3u8}, and segment files:
@file{file-20160215-1455569023.ts}, @file{file-20160215-1455569024.ts}, etc.
+Note: On some systems/environments, the @code{%s} specifier is not available. See
+ @code{strftime()} documentation.
@example
ffmpeg -i in.nut -use_localtime 1 -hls_flags second_l
[FFmpeg-devel] [PATCH] avformat/hlsenc: bugfix in duplicate filename detection
Dear All,
in hlsenc.c at detecting duplicate segment filenames a wrong,
unitialized variable is used for testing. This patch fixes this
typo. Please apply my patch.
Thank you in advance.
Bela Bodecs
>From 2459227d3c304b9e45ae52071e8bcea36e287dac Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Wed, 4 Jan 2017 20:12:48 +0100
Subject: [PATCH] avformat/hlsenc: bugfix in duplicate filename detection
A wrong, unitialized variable is used for testing. This patch fixes this
typo.
Signed-off-by: Bela Bodecs
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 4b1f12f..808a797 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -490,7 +490,7 @@ static int hls_append_segment(struct AVFormatContext *s, HLSContext *hls, double
filename = hls->avf->filename;
}
if (find_segment_by_filename(hls->segments, filename)
-|| find_segment_by_filename(hls->old_segments, en->filename)) {
+|| find_segment_by_filename(hls->old_segments, filename)) {
av_log(hls, AV_LOG_WARNING, "Duplicated segment filename detected: %s\n", filename);
}
av_strlcpy(en->filename, filename, sizeof(en->filename));
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix memleak in hlsenc
2017.01.05. 1:20 keltezéssel, Steven Liu írta:
fix CID: 1398364 Resource leak
refine the code of the new options
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 808a797..feeb853 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -446,11 +446,18 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
strlen(hls->current_segment_final_filename_fmt)) {
char * old_filename = av_strdup(hls->avf->filename); // %%s will be
%s after strftime
+if (!old_filename) {
+av_free(en);
+return AVERROR(ENOMEM);
+}
av_strlcpy(hls->avf->filename, hls->current_segment_final_filename_fmt,
sizeof(hls->avf->filename));
+char * filename = av_strdup(hls->avf->filename); // %%s will be %s
after strftime
+if (!filename) {
+av_free(old_filename);
+av_free(en);
+return AVERROR(ENOMEM);
+}
if (hls->flags & HLS_SECOND_LEVEL_SEGMENT_SIZE) {
-char * filename = av_strdup(hls->avf->filename); // %%s will be
%s after strftime
-if (!filename)
-return AVERROR(ENOMEM);
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
filename, 's', pos + size) < 1) {
av_log(hls, AV_LOG_ERROR,
@@ -459,14 +466,11 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
filename);
av_free(filename);
av_free(old_filename);
+av_free(en);
return AVERROR(EINVAL);
}
-av_free(filename);
}
if (hls->flags & HLS_SECOND_LEVEL_SEGMENT_DURATION) {
-char * filename = av_strdup(hls->avf->filename); // %%t will be
%t after strftime
-if (!filename)
-return AVERROR(ENOMEM);
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
filename, 't', (int64_t)round(100 * duration)) < 1) {
av_log(hls, AV_LOG_ERROR,
@@ -475,10 +479,11 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
filename);
av_free(filename);
av_free(old_filename);
+av_free(en);
return AVERROR(EINVAL);
}
-av_free(filename);
}
+av_free(filename);
ff_rename(old_filename, hls->avf->filename, hls);
av_free(old_filename);
}
if you remove av_strdup after if branch, this way if
HLS_SECOND_LEVEL_SEGMENT_SIZE and HLS_SECOND_LEVEL_SEGMENT_DURATION also set,
only later one will applied because filename will be the original one in second
if branch.
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix memleak in hlsenc
2017.01.05. 9:43 keltezéssel, Steven Liu írta:
2017-01-05 15:47 GMT+08:00 Bodecs Bela :
2017.01.05. 1:20 keltezéssel, Steven Liu írta:
fix CID: 1398364 Resource leak
refine the code of the new options
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 808a797..feeb853 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -446,11 +446,18 @@ static int hls_append_segment(struct
AVFormatContext *s, HLSContext *hls, double
if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
strlen(hls->current_segment_final_filename_fmt)) {
char * old_filename = av_strdup(hls->avf->filename); // %%s
will be %s after strftime
+if (!old_filename) {
+av_free(en);
+return AVERROR(ENOMEM);
+}
av_strlcpy(hls->avf->filename,
hls->current_segment_final_filename_fmt,
sizeof(hls->avf->filename));
+char * filename = av_strdup(hls->avf->filename); // %%s will
be %s after strftime
+if (!filename) {
+av_free(old_filename);
+av_free(en);
+return AVERROR(ENOMEM);
+}
if (hls->flags & HLS_SECOND_LEVEL_SEGMENT_SIZE) {
-char * filename = av_strdup(hls->avf->filename); // %%s
will be %s after strftime
-if (!filename)
-return AVERROR(ENOMEM);
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
filename, 's', pos + size) < 1) {
av_log(hls, AV_LOG_ERROR,
@@ -459,14 +466,11 @@ static int hls_append_segment(struct
AVFormatContext *s, HLSContext *hls, double
filename);
av_free(filename);
av_free(old_filename);
+av_free(en);
return AVERROR(EINVAL);
}
-av_free(filename);
}
if (hls->flags & HLS_SECOND_LEVEL_SEGMENT_DURATION) {
-char * filename = av_strdup(hls->avf->filename); // %%t
will be %t after strftime
-if (!filename)
-return AVERROR(ENOMEM);
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
filename, 't', (int64_t)round(100 * duration)) <
1) {
av_log(hls, AV_LOG_ERROR,
@@ -475,10 +479,11 @@ static int hls_append_segment(struct
AVFormatContext *s, HLSContext *hls, double
filename);
av_free(filename);
av_free(old_filename);
+av_free(en);
return AVERROR(EINVAL);
}
-av_free(filename);
}
+av_free(filename);
ff_rename(old_filename, hls->avf->filename, hls);
av_free(old_filename);
}
if you remove av_strdup after if branch, this way if
HLS_SECOND_LEVEL_SEGMENT_SIZE and HLS_SECOND_LEVEL_SEGMENT_DURATION also
set, only later one will applied because filename will be the original one
in second if branch.
bb
new patch update.
yes, it os ok now, thank you.
___
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] [PATCH] avformat/hlsenc: typo in default localtime pattern
Dear All, in hlsenc.c at get_default_pattern_localtime_fmt function the default pattern contains %Y%m%d%H%I%S but the original intention was %Y%m%d%H%M%S Please apply this patch. thank you, Bela Bodecs >From 9a11e116ad50bae635ce7c16821975b3d584ddc7 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Thu, 5 Jan 2017 11:19:33 +0100 Subject: [PATCH] avformat/hlsenc: typo in default localtime pattern in get_default_pattern_localtime_fmt the default pattern contains %Y%m%d%H%I%S but the original intention was %Y%m%d%H%M%S Signed-off-by: Bela Bodecs --- libavformat/hlsenc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index 808a797..ac744a5 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -944,7 +944,7 @@ static const char * get_default_pattern_localtime_fmt(void) struct tm *p, tmbuf; p = localtime_r(&t, &tmbuf); // no %s support when strftime returned error or left format string unchanged -return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? "-%Y%m%d%H%I%S.ts" : "-%s.ts"; +return (!strftime(b, sizeof(b), "%s", p) || !strcmp(b, "%s")) ? "-%Y%m%d%H%M%S.ts" : "-%s.ts"; } static int hls_write_header(AVFormatContext *s) -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] doc/muxers/hlsenc: typo hls_flag: discont_starts => discont_start
Dear All,
in doc/muxers/hlsenc, there is a typo in hls_flags section:
discont_starts instead of discont_start
best regards,
Bela Bodecs
>From d6c3375508750886bc7edf82b5282c93e70a8e62 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Thu, 5 Jan 2017 13:21:13 +0100
Subject: [PATCH] doc/muxers/hlsenc: typo hls_flag: discont_starts =>
discont_start
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index b4a107c..351cd8c 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -567,7 +567,7 @@ and remove the @code{#EXT-X-ENDLIST} from the old segment list.
Round the duration info in the playlist file segment info to integer
values, instead of using floating point.
-@item discont_starts
+@item discont_start
Add the @code{#EXT-X-DISCONTINUITY} tag to the playlist, before the
first segment's information.
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
Dear All,
in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
>From 3901ca87d9918e9002681b55a6984d3d0d0eaea5 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: start_number new options
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 7 +--
libavformat/hlsenc.c | 22 --
2 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 351cd8c..ae877c9 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -417,8 +417,11 @@ files, and limits the maximum number of segment files written to disk
to @var{wrap}.
@item start_number @var{number}
-Start the playlist sequence number from @var{number}. Default value is
-0.
+Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the specified @var{number}.
+Unless @code{hls_flags single_file} is set, it also specifies starting sequence numbers of segment and subtitle filenames.
+Default value is 0.
+If set to -1, then the start number will be the seconds since epoch (1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current date/time as mmddHHMMSS. e.g. 20161231235659.
@item hls_allow_cache @var{allowcache}
Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index eeb450a..de37be5 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,9 @@
#include "internal.h"
#include "os_support.h"
+#define HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH -1
+#define HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME -2
+
#define KEYSIZE 16
#define LINE_BUFFER_SIZE 1024
@@ -586,7 +589,7 @@ static int parse_playlist(AVFormatContext *s, const char *url)
while (!avio_feof(in)) {
read_chomp_line(in, line, sizeof(line));
if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
-hls->sequence = atoi(ptr);
+hls->sequence = strtoll(ptr, NULL, 10);
} else if (av_strstart(line, "#EXT-X-DISCONTINUITY", &ptr)) {
is_segment = 1;
hls->discontinuity = 1;
@@ -971,6 +974,21 @@ static int hls_write_header(AVFormatContext *s)
int basename_size;
int vtt_basename_size;
+if (hls->start_sequence == HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH || hls->start_sequence == HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME) {
+time_t t = time(NULL); // we will need it in either case
+if (hls->start_sequence == HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH)
+hls->start_sequence = (int64_t)t;
+else if (hls->start_sequence == HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME) {
+char b[21];
+struct tm *p, tmbuf;
+if (!(p = localtime_r(&t, &tmbuf)))
+return AVERROR(ENOMEM);
+if (!strftime(b, sizeof(b), "%Y%m%d%H%M%S", p))
+return AVERROR(ENOMEM);
+hls->start_sequence = strtoll(b, NULL, 10);
+}
+}
+
hls->sequence = hls->start_sequence;
hls->recording_time = (hls->init_time ? hls->init_time : hls->time) * AV_TIME_BASE;
hls->start_pts = AV_NOPTS_VALUE;
@@ -1318,7 +1336,7 @@ static int hls_write_trailer(struct AVFormatContext *s)
#define OFFSET(x) offsetof(HLSContext, x)
#define E AV_OPT_FLAG_ENCODING_PARAM
static const AVOption options[] = {
-{"start_number", "set first number in the sequence",OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, E},
+{"start_number", "set first number in the sequence",OFFSET(
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2, INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
>From 4560890d877af6d3e2f10a499c0cfd847ded8f37 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: start_number new options
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
Hls speficication allow 64 bit integers as sequence numbers. This patch
changes some code where only 32 bit integer values were handled.
Signed-off-by: Bela Bodecs
---
doc/muxers.texi | 8 ++--
libavformat/hlsenc.c | 42 +++---
2 files changed, 37 insertions(+), 13 deletions(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 351cd8c..746f231 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -417,8 +417,12 @@ files, and limits the maximum number of segment files written to disk
to @var{wrap}.
@item start_number @var{number}
-Start the playlist sequence number from @var{number}. Default value is
-0.
+Start the playlist sequence number (@code{#EXT-X-MEDIA-SEQUENCE}) from the specified @var{number}.
+Unless @code{hls_flags single_file} is set, it also specifies starting sequence numbers of segment and subtitle filenames.
+If set to -1, then the start number will be the seconds since epoch (1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0. If @code{hls_flags append_list} is set and read playlist sequence number is greater than specified
+@var{number}, then that value will be used as start_number value.
@item hls_allow_cache @var{allowcache}
Explicitly set whether the client MAY (1) or MUST NOT (0) cache media segments.
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index eeb450a..1679607 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -39,6 +39,9 @@
#include "internal.h"
#include "os_support.h"
+#define HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH -1
+#define HLS_START_SEQUNCE_AS_FORMATTED_STRFTIME -2
+
#define KEYSIZE 16
#define LINE_BUFFER_SIZE 1024
@@ -586,7 +589,11 @@ static int parse_playlist(AVFormatContext *s, const char *url)
while (!avio_feof(in)) {
read_chomp_line(in, line, sizeof(line));
if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
-hls->sequence = atoi(ptr);
+in
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is default, -1:
second since epoch, -2: current datetime as MMDDhhmmss, actual value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX, E},
I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
I thought that there should be 3 options beside this start_number option.
hls_start_number_playlist, hls_start_number_segment and hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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] avformat/hlsenc: start_number new options
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01 00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
I thought that there should be 3 options beside this start_number option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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] avformat/hlsenc: start_number new options
2017.01.10. 6:53 keltezéssel, Steven Liu írta:
2017-01-08 8:22 GMT+08:00 Steven Liu :
2017-01-08 1:37 GMT+08:00 Bodecs Bela :
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist
sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where
greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is
default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
yes, of course ;-)
I thought that there should be 3 options beside this start_number option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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
Hi Bodecs,
If you don't have enough time, i think i can do it together with
you;)
I have done it yesterday. I will send it very soon.
___
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] avformat/hlsenc: start_number new options
2017.01.10. 6:53 keltezéssel, Steven Liu írta:
2017-01-08 8:22 GMT+08:00 Steven Liu :
2017-01-08 1:37 GMT+08:00 Bodecs Bela :
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist
sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where
greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is
default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
yes, of course ;-)
I thought that there should be 3 options beside this start_number option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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
Hi Bodecs,
If you don't have enough time, i think i can do it together with
you;)
here it is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>From 5222dc3bb369186a7a185c4a133503b1ea694885 Mon Sep 17 00:00:00 2001
From: Bela Bodecs
Date: Fri, 6 Jan 2017 14:52:08 +0100
Subject: [PATCH] avformat/hlsenc: hls_start_number_source and start_number
start_number option starts the playlist sequence number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless hls_flags
single_file is set, it also specifies starting sequence numbers of
segme
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.10. 13:02 keltezéssel, Moritz Barsnick írta:
On Tue, Jan 10, 2017 at 10:42:21 +0100, Bodecs Bela wrote:
Hls speficication allow 64 bit integers as sequence numbers. This patch
^ specification allows
+typedef enum {
+ HLS_START_SEQUNCE_AS_START_NUMBER,
+ HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH,
+ HLS_START_SEQUNCE_AS_FORMATTED_DATETIME, // MMDDhhmmss
^ correct spelling would be SEQUENCE :)
Otherwise, grammar looks okay to me.
Missing documentation in doc/muxers.texi.
my patch included the muxers.texi also.
Moritz
___
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] avformat/hlsenc: start_number new options
2017.01.10. 12:10 keltezéssel, Steven Liu írta:
2017-01-10 17:42 GMT+08:00 Bodecs Bela :
2017.01.10. 6:53 keltezéssel, Steven Liu írta:
2017-01-08 8:22 GMT+08:00 Steven Liu :
2017-01-08 1:37 GMT+08:00 Bodecs Bela :
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist
sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where
greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is
default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
yes, of course ;-)
I thought that there should be 3 options beside this start_number
option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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
Hi Bodecs,
If you don't have enough time, i think i can do it together with
you;)
here it is.
___
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
+typedef enum {
+ HLS_START_SEQUNCE_AS_START_NUMBER = 0,
+ HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH = -1,
+ HLS_START_SEQUNCE_AS_FORMATTED_DATETIME =
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.10. 12:10 keltezéssel, Steven Liu írta:
2017-01-10 17:42 GMT+08:00 Bodecs Bela :
2017.01.10. 6:53 keltezéssel, Steven Liu írta:
2017-01-08 8:22 GMT+08:00 Steven Liu :
2017-01-08 1:37 GMT+08:00 Bodecs Bela :
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist
sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0}, -2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation, for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where
greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is
default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
yes, of course ;-)
I thought that there should be 3 options beside this start_number
option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.
This way anybody could use the old option (start_number) and it won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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
Hi Bodecs,
If you don't have enough time, i think i can do it together with
you;)
here it is.
___
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
+typedef enum {
+ HLS_START_SEQUNCE_AS_START_NUMBER = 0,
+ HLS_START_SEQUNCE_AS_SECONDS_SINCE_EPOCH = -1,
+ HLS_START_SEQUNCE_AS_FORMATTED_DATETIME =
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.10. 16:40 keltezéssel, Steven Liu írta:
2017-01-10 23:22 GMT+08:00 Bodecs Bela :
2017.01.10. 12:10 keltezéssel, Steven Liu írta:
2017-01-10 17:42 GMT+08:00 Bodecs Bela :
2017.01.10. 6:53 keltezéssel, Steven Liu írta:
2017-01-08 8:22 GMT+08:00 Steven Liu :
2017-01-08 1:37 GMT+08:00 Bodecs Bela :
2017.01.07. 0:32 keltezéssel, Steven Liu írta:
2017-01-07 0:47 GMT+08:00 Bodecs Bela :
2017.01.06. 17:33 keltezéssel, Steven Liu írta:
2017-01-07 0:22 GMT+08:00 Bodecs Bela :
2017.01.06. 16:50 keltezéssel, Steven Liu írta:
2017-01-06 22:07 GMT+08:00 Bodecs Bela :
Dear All,
in avformat/hlsenc the start_number option starts the playlist
sequence
number
(#EXT-X-MEDIA-SEQUENCE) from the specified number. Unless
hls_flags
single_file is set, it also specifies starting sequence numbers
of
segment and subtitle filenames. Sometimes it is usefull to have
unique
starting numbers at each run, but currently it is only
achiveable
by
setting this parameter manually.
This patch enables to set start_number parameter automatically
for
practically unique numbers. If start_number is set to -1, then
the start number will be the seconds since epoch (1970-01-01
00:00:00).
If set to -2, then the start number will be based on the current
date/time value as mmddHHMMSS. e.g. 20161231235659.
thank you,
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Two question:
1. char b[21]; Why this is 21 ?
you are right, 15 is enough.
2. +{"start_number", "set first number in the sequence",
OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX,
E},
Why is this -2 and the help message maybe need more infomation,
for
example
-2 mean -1 mean 0 mean, and default value.
yes, I have altered now but I have written verbosly into the doc
(muxers.texi), here:
+If set to -1, then the start number will be the seconds since
epoch
(1970-01-01 00:00:00).
+If set to -2, then the start number will be based on the current
date/time as mmddHHMMSS. e.g. 20161231235759.
+Default value is 0.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I have enclosed a fixed version. A have changed some code, where
greater
than 32 bit long sequence numbers were not handled correctly.
(av_get_frame_filename2)
thank you.
Bela Bodecs
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
+{"start_number", "set first number in the sequence, 0 is
default,
-1:
second since epoch, -2: current datetime as MMDDhhmmss, actual
value
otherwise", OFFSET(start_sequence),AV_OPT_TYPE_INT64, {.i64 = 0},
-2,
INT64_MAX, E},
I have check this option, i think add flag to control the
start_number
maybe better,
for example:
hls_flags
hls_playlist_type
maybe add a start_number_flags is better, What about you think?
Using hls_flags is not enough to specify different values for them.
NO, i am not mean use hls_flags, i mean you can creat a new flags,
start_number_flags
generic
epoch
datetime
Ok, I see it. May I implement it?
yes, of course ;-)
I thought that there should be 3 options beside this start_number
option.
hls_start_number_playlist, hls_start_number_segment and
hls_start_number_vtt
Using start_number and any of the new 3 ones would be mutualy
exlusive.
This way anybody could use the old option (start_number) and it
won't
break the current behaviour.
But those who want to have finer control, they may use the new
options.
of course -start_number x has the same effect as using
-hls_start_number_playlist x -hls_start_number_segment x
-hls_start_number_vtt x
___
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
Hi Bodecs,
If you don't have enough time, i think i can do it together
with
you;)
here it is.
___
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
+typedef enum {
+ HLS_START_SEQUNCE_AS_START_NUMBE
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: start_number new options
2017.01.10. 22:02 keltezéssel, Moritz Barsnick írta: On Tue, Jan 10, 2017 at 16:02:34 +0100, Bodecs Bela wrote: Missing documentation in doc/muxers.texi. my patch included the muxers.texi also. D'uh, sorry! ;) Will you please review it? ___ 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] avformat/hlsenc: fix hlsenc bug at windows system
2017.01.12. 6:03 keltezéssel, Steven Liu írta:
when hlsenc use flag second_level_segment_index,
second_level_segment_size and second_level_segment_duration,
the rename is ok but the output filename always use the old filename
so move the rename operation after the close the ts file and
before open new segment
It is strange. I have tested my original patch on windows 7. Sorry.
Reported-by: Christian Johannesen
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a2c606c..772232b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -499,7 +499,6 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
}
av_free(filename);
}
-ff_rename(old_filename, hls->avf->filename, hls);
av_free(old_filename);
}
I suggest to remove here, in this same scope all old_filename related
code, because it was used by ff_rename only:
-char * old_filename = av_strdup(hls->avf->filename); // %%s
will be %s after strftime
-if (!old_filename) {
-av_free(en);
-return AVERROR(ENOMEM);
-}
and at several places inside if() branch:
-av_free(old_filename);
@@ -1239,14 +1238,22 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
if (can_split && av_compare_ts(pkt->pts - hls->start_pts, st->time_base,
end_pts, AV_TIME_BASE_Q) >= 0) {
int64_t new_start_pos;
+char *old_filename = av_strdup(hls->avf->filename);
+
+if (!old_filename) {
+return AVERROR(ENOMEM);
+}
+
av_write_frame(oc, NULL); /* Flush any buffered data */
new_start_pos = avio_tell(hls->avf->pb);
hls->size = new_start_pos - hls->start_pos;
ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
hls->size);
hls->start_pos = new_start_pos;
-if (ret < 0)
+if (ret < 0) {
+av_free(old_filename);
return ret;
+}
hls->end_pts = pkt->pts;
hls->duration = 0;
@@ -1261,6 +1268,10 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (hls->start_pos >= hls->max_seg_size) {
hls->sequence++;
ff_format_io_close(s, &oc->pb);
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
+ strlen(hls->current_segment_final_filename_fmt)) {
+ff_rename(old_filename, hls->avf->filename, hls);
+}
if (hls->vtt_avf)
ff_format_io_close(s, &hls->vtt_avf->pb);
ret = hls_start(s);
@@ -1272,22 +1283,30 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
hls->number++;
} else {
ff_format_io_close(s, &oc->pb);
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
+strlen(hls->current_segment_final_filename_fmt)) {
+ff_rename(old_filename, hls->avf->filename, hls);
+}
if (hls->vtt_avf)
ff_format_io_close(s, &hls->vtt_avf->pb);
ret = hls_start(s);
}
-if (ret < 0)
+if (ret < 0) {
+av_free(old_filename);
return ret;
+}
if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE )
oc = hls->vtt_avf;
else
oc = hls->avf;
-if ((ret = hls_window(s, 0)) < 0)
+if ((ret = hls_window(s, 0)) < 0) {
+av_free(old_filename);
return ret;
+}
}
ret = ff_write_chained(oc, stream_index, pkt, s, 0);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix hlsenc bug at windows system
Have you noticed my second comment also about code change in my earlier
reply?
2017.01.12. 10:39 keltezéssel, Steven Liu írta:
2017-01-12 17:18 GMT+08:00 Bodecs Bela :
2017.01.12. 6:03 keltezéssel, Steven Liu írta:
when hlsenc use flag second_level_segment_index,
second_level_segment_size and second_level_segment_duration,
the rename is ok but the output filename always use the old filename
so move the rename operation after the close the ts file and
before open new segment
It is strange. I have tested my original patch on windows 7. Sorry.
That's ok :)
the mail title:
[FFmpeg-user] issue with [PATCH] avformat/hlsenc: actual segment file size
and duration in segment filenames
I have read it now. I have compiled under windows with cygwin. It may
be the reason It did not occured for me.
I think to make the actual renaming after closing ts is a better
approach than mine was.
Reported-by: Christian Johannesen
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index a2c606c..772232b 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -499,7 +499,6 @@ static int hls_append_segment(struct AVFormatContext
*s, HLSContext *hls, double
}
av_free(filename);
}
-ff_rename(old_filename, hls->avf->filename, hls);
av_free(old_filename);
}
I suggest to remove here, in this same scope all old_filename related
code, because it was used by ff_rename only:
-char * old_filename = av_strdup(hls->avf->filename); // %%s will
be %s after strftime
-if (!old_filename) {
-av_free(en);
-return AVERROR(ENOMEM);
-}
and at several places inside if() branch:
-av_free(old_filename);
@@ -1239,14 +1238,22 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (can_split && av_compare_ts(pkt->pts - hls->start_pts,
st->time_base,
end_pts, AV_TIME_BASE_Q) >= 0) {
int64_t new_start_pos;
+char *old_filename = av_strdup(hls->avf->filename);
+
+if (!old_filename) {
+return AVERROR(ENOMEM);
+}
+
av_write_frame(oc, NULL); /* Flush any buffered data */
new_start_pos = avio_tell(hls->avf->pb);
hls->size = new_start_pos - hls->start_pos;
ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
hls->size);
hls->start_pos = new_start_pos;
-if (ret < 0)
+if (ret < 0) {
+av_free(old_filename);
return ret;
+}
hls->end_pts = pkt->pts;
hls->duration = 0;
@@ -1261,6 +1268,10 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (hls->start_pos >= hls->max_seg_size) {
hls->sequence++;
ff_format_io_close(s, &oc->pb);
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
+ strlen(hls->current_segment_final_filename_fmt)) {
+ff_rename(old_filename, hls->avf->filename, hls);
+}
if (hls->vtt_avf)
ff_format_io_close(s, &hls->vtt_avf->pb);
ret = hls_start(s);
@@ -1272,22 +1283,30 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
hls->number++;
} else {
ff_format_io_close(s, &oc->pb);
+if ((hls->flags & (HLS_SECOND_LEVEL_SEGMENT_SIZE |
HLS_SECOND_LEVEL_SEGMENT_DURATION)) &&
+strlen(hls->current_segment_final_filename_fmt)) {
+ff_rename(old_filename, hls->avf->filename, hls);
+}
if (hls->vtt_avf)
ff_format_io_close(s, &hls->vtt_avf->pb);
ret = hls_start(s);
}
-if (ret < 0)
+if (ret < 0) {
+av_free(old_filename);
return ret;
+}
if( st->codecpar->codec_type == AVMEDIA_TYPE_SUBTITLE )
oc = hls->vtt_avf;
else
oc = hls->avf;
-if ((ret = hls_window(s, 0)) < 0)
+if ((ret = hls_window(s, 0)) < 0) {
+av_free(old_filename);
return ret;
+}
}
ret = ff_write_chained(oc, stream_index, pkt, s, 0);
___
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 1/2 v2] avformat/hlsenc: fix typo of AV_TIME_BASE
2017.01.23. 10:05 keltezéssel, Steven Liu írta:
the code use 100 * duration, use AV_TIME_BASE replace 100
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 85d3955..f070bc3 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -501,7 +501,7 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
return AVERROR(ENOMEM);
}
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
-filename, 't', (int64_t)round(100 * duration)) < 1) {
+filename, 't', (int64_t)round(AV_TIME_BASE * duration)) < 1) {
av_log(hls, AV_LOG_ERROR,
"Invalid second level segment filename template '%s', "
"you can try to remove second_level_segment_time
flag\n",
I used 100 because the duration is in seconds and the replacement
should be in microseconds.
The filename will contain the duration in microseconds.
So this is a "seconds to microseconds" conversion. It would be a
mistake to use AV_TIME_BASE here.
Maybe a comment should be added to the code about it.
The reasoning behind to put duration in microseconds into filename
instead of seconds was to avoid comma in filename.
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: improve the code readable of 1000000
2017.01.23. 12:01 keltezéssel, Steven Liu írta:
Reviewed-by: Bodecs Bela
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 85d3955..0170b34 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -47,6 +47,7 @@ typedef enum {
#define KEYSIZE 16
#define LINE_BUFFER_SIZE 1024
+#define HLS_MICROSECOND_UNIT 100
typedef struct HLSSegment {
char filename[1024];
@@ -501,7 +502,7 @@ static int hls_append_segment(struct AVFormatContext *s,
HLSContext *hls, double
return AVERROR(ENOMEM);
}
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
-filename, 't', (int64_t)round(100 * duration)) < 1) {
+filename, 't', (int64_t)round(duration * HLS_MICROSECOND_UNIT))
< 1) {
av_log(hls, AV_LOG_ERROR,
"Invalid second level segment filename template '%s', "
"you can try to remove second_level_segment_time
flag\n",
I think it is good.
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avformat/hlsenc: improve the code readable of 1000000
2017.01.23. 15:55 keltezéssel, James Almer írta:
On 1/23/2017 11:25 AM, Steven Liu wrote:
2017-01-23 22:14 GMT+08:00 James Almer :
On 1/23/2017 8:01 AM, Steven Liu wrote:
Reviewed-by: Bodecs Bela
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 85d3955..0170b34 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -47,6 +47,7 @@ typedef enum {
#define KEYSIZE 16
#define LINE_BUFFER_SIZE 1024
+#define HLS_MICROSECOND_UNIT 100
You could instead use AV_TIME_BASE. It's more in line with the rest of the
codebase.
No, the 1st version, Bodecs Bela has point the 100 is not AV_TIME_BASE
mean.
I'm not sure i understand his reasoning, seeing that AV_TIME_BASE is
defined as 100 in avutil.h and i don't see it changing anytime soon,
but it's just a nit so not really important. This patch is good as is.
I used 100 because the duration is in seconds and the replacement
should be in microseconds.
The filename will contain the duration in microseconds.
So this is a "seconds to microseconds" conversion. It would be a
mistake to use AV_TIME_BASE here, because i think it is a coincindence
that the 2 numbers is the same.
We want ot use microseconds in filenames not AV_TIME_BASE units.
Maybe a comment should be added to the code about it.
The reasoning behind to put duration in microseconds into filename
instead of seconds was to avoid comma in filename.
typedef struct HLSSegment {
char filename[1024];
@@ -501,7 +502,7 @@ static int hls_append_segment(struct AVFormatContext
*s, HLSContext *hls, double
return AVERROR(ENOMEM);
}
if (replace_int_data_in_filename(hls->avf->filename,
sizeof(hls->avf->filename),
-filename, 't', (int64_t)round(100 * duration)) <
1) {
+filename, 't', (int64_t)round(duration *
HLS_MICROSECOND_UNIT)) < 1) {
av_log(hls, AV_LOG_ERROR,
"Invalid second level segment filename template
'%s', "
"you can try to remove
second_level_segment_time flag\n",
___
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] FFmpeg 3.3
2017.01.25. 9:40 keltezéssel, Tobias Rapp írta: On 23.01.2017 02:11, Michael Niedermayer wrote: Its a while since the last relase so ill make 3.3 within the next week(s) Name suggestions needed like always What about "Hilbert", named after David Hilbert? +1 vote I also intend to make some new point releases from the currently maintained branches if someone wants to backport something If not already done, please backport commit http://git.videolan.org/?p=ffmpeg.git;a=commit;h=6d579d7c1bdc4126955cae7f385208e455685986 Regards, Tobias ___ 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] avformat/hlsenc: add hls_flag option to create segments atomically
2017.01.31. 21:29 keltezéssel, Aman Gupta írta:
From: Aman Gupta
Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete
and before the file is added to the m3u8 playlist.
This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
---
libavformat/hlsenc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..23b9011 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -76,6 +76,7 @@ typedef enum HLSFlags {
HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in
segment filenames when use_localtime e.g.: %%03d
HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration
(microsec) in segment filenames when use_localtime e.g.: %%09t
HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size
(bytes) in segment filenames when use_localtime e.g.: %%014s
+HLS_TEMP_FILE = (1 << 11),
} HLSFlags;
typedef enum {
@@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
set_http_options(&options, c);
+if (c->flags & HLS_TEMP_FILE) {
+av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
+}
+
if (c->key_info_file) {
if ((err = hls_encryption_start(s)) < 0)
goto fail;
@@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
av_write_frame(oc, NULL); /* Flush any buffered data */
+if (hls->flags & HLS_TEMP_FILE) {
+size_t len = strlen(oc->filename);
+char final_filename[sizeof(oc->filename)];
+av_strlcpy(final_filename, oc->filename, len);
+final_filename[len-4] = '\0';
+ff_rename(oc->filename, final_filename, s);
+oc->filename[len-4] = '\0';
+}
+
new_start_pos = avio_tell(hls->avf->pb);
hls->size = new_start_pos - hls->start_pos;
ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
hls->size);
@@ -1406,6 +1420,7 @@ static const AVOption options[] = {
{"hls_subtitle_path", "set path of hls subtitles",
OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,E},
{"hls_flags", "set flags affecting HLS playlist and media file generation",
OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E, "flags"},
{"single_file", "generate a single media file indexed with byte ranges", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX, E, "flags"},
+{"temp_file", "write segment to temporary file and rename when complete", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX, E, "flags"},
{"delete_segments", "delete segment files that are no longer part of the playlist",
0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0, UINT_MAX, E, "flags"},
{"round_durations", "round durations in m3u8 to whole numbers", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX, E, "flags"},
{"discont_start", "start the playlist with a discontinuity tag", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
I think the phrase in your email subject "to create atomically"
misleading because another renaming may occur afterwards your temp
renaming if second_level_segment_size or second_level_segment_duration
flag is on.
But the idea to write segment content into a temp file is good by me. To
ensure the amoticity the two distinct renamings may be merged.
I have never thought of it but after your idea I concluded that the
segment file names are predictable.
In live streaming enviroment somebody predicting the segment name may
see the program some seconds earlier than any other viewer by
downloading the unpublished segment. (with one segment duration seconds
earlier)
If the temp file name would be random name, then your idea may be seen
as a security feature.
What is your opinion about this possibility?
bb
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: add hls_flag option to create segments atomically
2017.02.03. 0:27 keltezéssel, Aman Gupta írta:
On Wed, Feb 1, 2017 at 6:03 AM, Bodecs Bela wrote:
2017.01.31. 21:29 keltezéssel, Aman Gupta írta:
From: Aman Gupta
Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete
and before the file is added to the m3u8 playlist.
This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
---
libavformat/hlsenc.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..23b9011 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -76,6 +76,7 @@ typedef enum HLSFlags {
HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index
in segment filenames when use_localtime e.g.: %%03d
HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment
duration (microsec) in segment filenames when use_localtime e.g.: %%09t
HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size
(bytes) in segment filenames when use_localtime e.g.: %%014s
+HLS_TEMP_FILE = (1 << 11),
} HLSFlags;
typedef enum {
@@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
set_http_options(&options, c);
+if (c->flags & HLS_TEMP_FILE) {
+av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
+}
+
if (c->key_info_file) {
if ((err = hls_encryption_start(s)) < 0)
goto fail;
@@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
av_write_frame(oc, NULL); /* Flush any buffered data */
+if (hls->flags & HLS_TEMP_FILE) {
+size_t len = strlen(oc->filename);
+char final_filename[sizeof(oc->filename)];
+av_strlcpy(final_filename, oc->filename, len);
+final_filename[len-4] = '\0';
+ff_rename(oc->filename, final_filename, s);
+oc->filename[len-4] = '\0';
+}
+
new_start_pos = avio_tell(hls->avf->pb);
hls->size = new_start_pos - hls->start_pos;
ret = hls_append_segment(s, hls, hls->duration, hls->start_pos,
hls->size);
@@ -1406,6 +1420,7 @@ static const AVOption options[] = {
{"hls_subtitle_path", "set path of hls subtitles",
OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0,E},
{"hls_flags", "set flags affecting HLS playlist and media file
generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E,
"flags"},
{"single_file", "generate a single media file indexed with byte
ranges", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX, E,
"flags"},
+{"temp_file", "write segment to temporary file and rename when
complete", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX, E,
"flags"},
{"delete_segments", "delete segment files that are no longer part
of the playlist", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0,
UINT_MAX, E, "flags"},
{"round_durations", "round durations in m3u8 to whole numbers", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX, E,
"flags"},
{"discont_start", "start the playlist with a discontinuity tag", 0,
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX, E, "flags"},
I think the phrase in your email subject "to create atomically"
misleading because another renaming may occur afterwards your temp renaming
if second_level_segment_size or second_level_segment_duration flag is on.
But the idea to write segment content into a temp file is good by me. To
ensure the amoticity the two distinct renamings may be merged.
I agree my use of "atomic" is confusing. I removed this from the commit
message in v2 of the patch.
I have never thought of it but after your idea I concluded that the
segment file names are predictable.
In live streaming enviroment somebody predicting the segment name may see
the program some seconds earlier than any other viewer by downloading the
unpublished segment. (with one segment duration seconds earlier)
If the temp file name would be random name, then your idea may be seen as
a security feature.
What is your opinion about this possibility?
I don't have a strong opinion on this. Presumably if someone is concerned
about this, they can still use my temp_file patch and configure their web
server to reject any requests for *.tmp
Yes, I agree with you. Maybe You can put
Re: [FFmpeg-devel] [PATCH v3] avformat/hlsenc: add hls_flag option to write segments to temporary file until complete
2017.02.04. 20:45 keltezéssel, Hendrik Leppkes írta: On Sat, Feb 4, 2017 at 6:55 PM, Aman Gupta wrote: From: Aman Gupta Adds a `-hls_flags +temp_file` which will write segment data to filename.tmp, and then rename to filename when the segment is complete. This patch is similar in spirit to one used in Plex's ffmpeg fork, and allows a transcoding webserver to ensure incomplete segment files are never served up accidentally. Wouldnt a segment only show up in the playlist when its finished? How can they be served accidentally? the segment file names are predictable. In live streaming enviroment somebody predicting the segment name may see the program some seconds earlier than any other viewer by downloading continously the unpublished segment. (with one segment duration seconds earlier) if the currently writed segment name is constant you may prohibit to acces it in web server config - Hendrik ___ 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] [PATCH] avformat/hlsenc: fix stream level metadata handling
Dear All, hls-encoder currently does not provide stream level metadata to mpegts muxer. This patch also fixes track #3848 bug. Please review this bug fix. Thank you in advance. best regards, Bela Bodecs >From 06a5e2dff962d0e2127ddbb00f6bd8a3d03d3e51 Mon Sep 17 00:00:00 2001 From: Bela Bodecs Date: Sat, 11 Feb 2017 22:22:24 +0100 Subject: [PATCH] avformat/hlsenc: fix stream level metadata handling hls-encoder currenlty does not provide stream level metadata to mpegts muxer. This patch fixes track #3848 bug. Signed-off-by: Bela Bodecs --- libavformat/hlsenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index bd1e684..a58ded9 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s) avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar); st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio; st->time_base = s->streams[i]->time_base; +av_dict_copy(&st->metadata, s->streams[i]->metadata, 0); } hls->start_pos = 0; hls->new_start = 1; -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: fix stream level metadata handling
2017.02.12. 2:36 keltezéssel, Steven Liu írta: 2017-02-12 5:31 GMT+08:00 Bodecs Bela : Dear All, hls-encoder currently does not provide stream level metadata to mpegts muxer. This patch also fixes track #3848 bug. Please review this bug fix. Thank you in advance. best regards, Bela Bodecs ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel hls-encoder currenlty does not provide stream level metadata to mpegts muxer. This patch fixes track #3848 bug. Signed-off-by: Bela Bodecs --- libavformat/hlsenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index bd1e684..a58ded9 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -446,6 +446,7 @@ static int hls_mux_init(AVFormatContext *s) avcodec_parameters_copy(st->codecpar, s->streams[i]->codecpar); st->sample_aspect_ratio = s->streams[i]->sample_aspect_ratio; st->time_base = s->streams[i]->time_base; +av_dict_copy(&st->metadata, s->streams[i]->metadata, 0); } hls->start_pos = 0; hls->new_start = 1; Should I change the status of the track ticket or is there somebody who is the maintainer of trac? bb ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
