[FFmpeg-devel] vstats info options
Hello, Is there a possibility to provide the option to write vstats info from an encoding session remotely, say to another DB or to memory from where it can be handled by another process. The only possibility for consuming vstats info in real-time seems to be to have some kind of watch+notifier that will act upon modifications to the vstats log file. I want to be able to use these stats from a live encoding session for other purposes. Please suggest. Would you accept patches to ffmpeg.c so that it would provide more options to export the vstats info? Thanks for the time. Thanks Kamal ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Sun, Jan 1, 2017 at 6:00 PM, wrote: > From: Pavel Koshevoy > > NVDEC (CUVID) does not support unlimited video resolutions, so if the > resolution of the source is known it can be used during avcodec_open2 > call to fail early, rather than failing later during > avcodec_send_packet call. > > This problem surfaced when trying to decode 5120x2700 h246 video on > Geforce GT 730 -- avcodec_open2 succeeded but decoding failed. > --- > libavcodec/cuvid.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c > index 8fc713d..2e70b62 100644 > --- a/libavcodec/cuvid.c > +++ b/libavcodec/cuvid.c > @@ -625,8 +625,8 @@ static int cuvid_test_dummy_decoder(AVCodecContext > *avctx, CUVIDPARSERPARAMS *cu > cuinfo.ChromaFormat = cudaVideoChromaFormat_420; > cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12; > > -cuinfo.ulWidth = 1280; > -cuinfo.ulHeight = 720; > +cuinfo.ulWidth = avctx->coded_width ? avctx->coded_width : 1280; > +cuinfo.ulHeight = avctx->coded_height ? avctx->coded_height : 720; > cuinfo.ulTargetWidth = cuinfo.ulWidth; > cuinfo.ulTargetHeight = cuinfo.ulHeight; > > -- > 2.9.2 > Perhaps a more comprehensive solution is needed. I've run into the same problem again (avcodec_open2 succeeds, decoding spits errors) when I tried to play back an mpeg2 stream with YUV422P pixel format. I have a new patch but I'd like to test it on a Pascal GPU first. I am still hoping that 422 decoding will work. It looks like it should be supported, but I've observed on Geforce GT 730 that even though I can instantiate a cuvid decoder with cudaVideoChromaFormat_422 without error -- the decoded video is garbage everywhere except for 16-pixel wide column along the left edge of the frame. In ee88dcb2 cuvid_handle_video_sequence was hard-coded to error-out if the chroma format is not 420. This looks like an NVIDIA driver/cuvid bug... does anyone know how to bring it to their attention? Pavel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] vstats info options
On Mon, 2 Jan 2017, Kamaldeep Tumkur wrote: Hello, Is there a possibility to provide the option to write vstats info from an encoding session remotely, say to another DB or to memory from where it can be handled by another process. The only possibility for consuming vstats info in real-time seems to be to have some kind of watch+notifier that will act upon modifications to the vstats log file. I want to be able to use these stats from a live encoding session for other purposes. Please suggest. Would you accept patches to ffmpeg.c so that it would provide more options to export the vstats info? Thanks for the time. Have you checked the -progress option? Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] vstats info options
On Mon, 2 Jan 2017, Marton Balint wrote: On Mon, 2 Jan 2017, Kamaldeep Tumkur wrote: Hello, Is there a possibility to provide the option to write vstats info from an encoding session remotely, say to another DB or to memory from where it can be handled by another process. The only possibility for consuming vstats info in real-time seems to be to have some kind of watch+notifier that will act upon modifications to the vstats log file. I want to be able to use these stats from a live encoding session for other purposes. Please suggest. Would you accept patches to ffmpeg.c so that it would provide more options to export the vstats info? Thanks for the time. Have you checked the -progress option? Also please respond on ffmpeg-user mailing list, as this question clearly belongs there. Thanks, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Input metadata not updated inside mux context
Happy New Year to all!
I am trying to create a patch for metadata-aware hls splitting.
Unfortunately, i cannot seem to get updated metadata from the
AVFormatContext object inside the muxer scope. For example, within hlsenc.c
I have this::
static int hls_start(AVFormatContext *s)
{
HLSContext *c = s->priv_data;
AVFormatContext *oc = c->avf;
AVFormatContext *vtt_oc = c->vtt_avf;
AVDictionary *options = NULL;
char *filename, iv_string[KEYSIZE*2 + 1];
int err = 0;
int ret = 0;
AVDictionaryEntry *tag = NULL;
av_log(s, AV_LOG_DEBUG, "Lets check if there's metadata now.. ");
tag = av_dict_get(oc->metadata, "StreamTitle", tag,
AV_DICT_IGNORE_SUFFIX);
printf("%s\n",tag->value);
However, what is logged is always the original StreamTitle that was valid
when the initial connection to the input url was made, and is not updating
it further. Granted, this is the output stream context, but it does contain
the initial metadata, apparently. What would be the way to update it, or to
access the input context's metadata? Or is the only solution to re-poll the
input stream in a separate process?
Thanks in advance
Christo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavc/psd: Support indexed files
2016-12-31 3:29 GMT+01:00 Michael Niedermayer : > On Fri, Dec 30, 2016 at 02:48:12PM +0100, Carl Eugen Hoyos wrote: >> Fixes ticket #6045. > > in the absence of other replies, this LGTM Replaced a for loop with a presumably faster memset and pushed. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Input metadata not updated inside mux context
2017-01-02 17:10 GMT+08:00 Christo Grozev :
>
> Happy New Year to all!
>
> I am trying to create a patch for metadata-aware hls splitting.
> Unfortunately, i cannot seem to get updated metadata from the
> AVFormatContext object inside the muxer scope. For example, within hlsenc.c
> I have this::
>
> static int hls_start(AVFormatContext *s)
> {
> HLSContext *c = s->priv_data;
> AVFormatContext *oc = c->avf;
> AVFormatContext *vtt_oc = c->vtt_avf;
> AVDictionary *options = NULL;
> char *filename, iv_string[KEYSIZE*2 + 1];
> int err = 0;
> int ret = 0;
> AVDictionaryEntry *tag = NULL;
>
> av_log(s, AV_LOG_DEBUG, "Lets check if there's metadata now.. ");
>
> tag = av_dict_get(oc->metadata, "StreamTitle", tag,
> AV_DICT_IGNORE_SUFFIX);
> printf("%s\n",tag->value);
>
>
>
> However, what is logged is always the original StreamTitle that was valid
> when the initial connection to the input url was made, and is not updating
> it further. Granted, this is the output stream context, but it does contain
> the initial metadata, apparently. What would be the way to update it, or to
> access the input context's metadata? Or is the only solution to re-poll the
> input stream in a separate process?
>
You can use hls_ts_options to set the mpegts metadata.
>
>
>
> Thanks in advance
>
> Christo
>
>
>
> ___
> 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] 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
@end example
-@item hls_flags single_file
+
+@item hls
Re: [FFmpeg-devel] [PATCH] doc/hlsenc: hls_segment_filename, use_localtime, , use_localtime_mkdir, hls_flags
2017-01-02 19:49 GMT+08:00 Bodecs Bela : > > > 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 >> > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > LGTM ___ 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
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
Moritz
___
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. 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}, etc.
+
+@example
+ffmpeg -i in.nut -use_localtime 1 -use_localtime_mkdir 1 -hl
Re: [FFmpeg-devel] [PATCH] lavf: add ffprobe demuxer
On date Tuesday 2016-12-13 00:16:24 +0100, Andreas Cadhalpun encoded:
> On 10.12.2016 17:55, Stefano Sabatini wrote:
> > From ebc34da37648a07f25da94a1662c278c13ca7383 Mon Sep 17 00:00:00 2001
> > From: Nicolas George
> > Date: Sat, 11 Jan 2014 19:42:41 +0100
> > Subject: [PATCH] lavf: add ffprobe demuxer
> >
> > With several modifications and documentation by Stefano Sabatini
> > .
> >
> > Signed-off-by: Nicolas George
> > ---
> > doc/demuxers.texi| 19 ++
> > doc/ffprobe-format.texi | 121 +
> > doc/formats.texi | 1 +
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/ffprobedec.c | 452
> > +++
> > 6 files changed, 595 insertions(+)
> > create mode 100644 doc/ffprobe-format.texi
> > create mode 100644 libavformat/ffprobedec.c
> >
> [...]
> > diff --git a/libavformat/ffprobedec.c b/libavformat/ffprobedec.c
> > new file mode 100644
> > index 000..f5d5ed7
> > --- /dev/null
> > +++ b/libavformat/ffprobedec.c
> [...]
> > +if (av_strstart(buf, "codec_name=", &val)) {
> > +const AVCodecDescriptor *desc =
> > avcodec_descriptor_get_by_name(val);
> > +if (desc) {
> > +st->codecpar->codec_id = desc->id;
> > +st->codecpar->codec_type = desc->type;
> > +}
> > +if (!desc) {
> > +av_log(avf, AV_LOG_WARNING, "Cannot recognize codec name
> > '%s'", val);
>
> This log message is missing a newline at the end.
>
> Other than that this only needs adding the format to doc/general.texi,
> a minor version bump and a changelog entry.
Updated.
--
FFmpeg = Friendly & Forgiving Mournful Proud Evil Guru
>From 37d6308014eacba11a87b0df86f95b94814bd663 Mon Sep 17 00:00:00 2001
From: Nicolas George
Date: Sat, 11 Jan 2014 19:42:41 +0100
Subject: [PATCH] lavf: add ffprobe demuxer
With several modifications and documentation by Stefano Sabatini
.
TODO: bump libavformat minor
Signed-off-by: Nicolas George
---
Changelog| 2 +
doc/demuxers.texi| 19 ++
doc/ffprobe-format.texi | 121 +
doc/formats.texi | 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/ffprobedec.c | 452 +++
7 files changed, 597 insertions(+)
create mode 100644 doc/ffprobe-format.texi
create mode 100644 libavformat/ffprobedec.c
diff --git a/Changelog b/Changelog
index aff9ab0..6d05963 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,8 @@ version :
- 16.8 floating point pcm decoder
- 24.0 floating point pcm decoder
- Apple Pixlet decoder
+- ffprobe demuxer
+
version 3.2:
- libopenmpt demuxer
diff --git a/doc/demuxers.texi b/doc/demuxers.texi
index c12c07e..9eb7f20 100644
--- a/doc/demuxers.texi
+++ b/doc/demuxers.texi
@@ -260,6 +260,25 @@ ffmpeg -f live_flv -i rtmp:///anything/key
Allocate the streams according to the onMetaData array content.
@end table
+@section ffprobe
+
+ffprobe internal demuxer. It is able to demux files in the format
+specified in the @ref{FFprobe demuxer format} chapter.
+
+This demuxer is experimental, use it with the libavformat
+@option{strict_std_compliance} option set to @code{"experimental"}
+(use @code{-strict experimental} with the commandline tools).
+
+This format is useful to generate streams in a textual format, easily
+generated with scripting or by hand (by editing the output of
+@command{ffprobe}).
+
+In particular, it can be also used to inject data stream generated by
+scripts in the @command{ffmpeg} output, for example with the command:
+@example
+ffmpeg -i INPUT -i data.ffprobe -f_strict experimental -map 0:0 -map 0:1 -map 1:0 -codec:d copy OUTPUT
+@end example
+
@section gif
Animated GIF demuxer.
diff --git a/doc/ffprobe-format.texi b/doc/ffprobe-format.texi
new file mode 100644
index 000..95ac644
--- /dev/null
+++ b/doc/ffprobe-format.texi
@@ -0,0 +1,121 @@
+@anchor{FFprobe demuxer format}
+@chapter FFprobe demuxer format
+@c man begin FFPROBE DEMUXER FORMAT
+
+The ffprobe demuxer format is inspired by the output generated by the
+ffprobe default format.
+
+It consists of several sections (@samp{FORMAT}, @samp{STREAM},
+@samp{PACKET}). Each section starts with a single line in the format
+@samp{[SECTION]} and ends with the corresponding line
+@samp{[/SECTION]}, where @samp{SECTION} is the name of the section.
+
+A well-formed file consists of an initial @samp{FORMAT} section,
+followed by several @samp{STREAM} sections (one per stream), and
+several @samp{PACKET} sections.
+
+Each section contains a sequence of lines in the form
+@samp{key=value}. In the case of data the key and the value must
+stay on different lines.
+
+Unrecognized values are discarded.
+
+This format can be read by the @code{ffprobe} demuxer. It is an
+internal format and thus should not be used for archiving purposes.
+
+The following sections document the f
Re: [FFmpeg-devel] PATCH for building with nasm
Hi, On Sun, Jan 1, 2017 at 8:36 PM, Michael Niedermayer wrote: > On Sun, Jan 01, 2017 at 08:16:00AM +, Rostislav Pehlivanov wrote: > > On 1 January 2017 at 07:52, John Comeau wrote: > > > > > fixes `operation size not specified` errors as described here: > > > http://stackoverflow.com/questions/36854583/compiling- > > > ffmpeg-for-kali-linux-2 > > > > > > I rebuilt again with yasm and made sure it didn't break that. > > > -- > > > John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/ > > > "A place for everything, and everything all over the place" > > > > > > ___ > > > ffmpeg-devel mailing list > > > ffmpeg-devel@ffmpeg.org > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > Odd, I've been using nasm to build ffmpeg for years now. > > What version do you use? It sure works on nasm 2.12.01 here. > > do you see a disadvantage in the change by the patch ? > if not, then i think it should be applied as it seems improving > support for some nasm version be that the only issue or one of > several I think it's fine to merge. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Mon, 2 Jan 2017 00:56:18 -0700 Pavel Koshevoy wrote: > On Sun, Jan 1, 2017 at 6:00 PM, wrote: > > From: Pavel Koshevoy > > > > NVDEC (CUVID) does not support unlimited video resolutions, so if > > the resolution of the source is known it can be used during > > avcodec_open2 call to fail early, rather than failing later during > > avcodec_send_packet call. > > > > This problem surfaced when trying to decode 5120x2700 h246 video on > > Geforce GT 730 -- avcodec_open2 succeeded but decoding failed. > > --- > > libavcodec/cuvid.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c > > index 8fc713d..2e70b62 100644 > > --- a/libavcodec/cuvid.c > > +++ b/libavcodec/cuvid.c > > @@ -625,8 +625,8 @@ static int > > cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS > > *cu cuinfo.ChromaFormat = cudaVideoChromaFormat_420; > > cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12; > > > > -cuinfo.ulWidth = 1280; > > -cuinfo.ulHeight = 720; > > +cuinfo.ulWidth = avctx->coded_width ? avctx->coded_width : > > 1280; > > +cuinfo.ulHeight = avctx->coded_height ? avctx->coded_height : > > 720; cuinfo.ulTargetWidth = cuinfo.ulWidth; > > cuinfo.ulTargetHeight = cuinfo.ulHeight; > > > > -- > > 2.9.2 > > > > > Perhaps a more comprehensive solution is needed. I've run into the > same problem again (avcodec_open2 succeeds, decoding spits errors) > when I tried to play back an mpeg2 stream with YUV422P pixel format. > > I have a new patch but I'd like to test it on a Pascal GPU first. I > am still hoping that 422 decoding will work. It looks like it should > be supported, but I've observed on Geforce GT 730 that even though I > can instantiate a cuvid decoder with cudaVideoChromaFormat_422 without > error -- the decoded video is garbage everywhere except for 16-pixel > wide column along the left edge of the frame. > > In ee88dcb2 cuvid_handle_video_sequence was hard-coded to error-out if > the chroma format is not 420. This looks like an NVIDIA driver/cuvid > bug... does anyone know how to bring it to their attention? It is documented as only supporting 420, even though it doesn't return an error, so it's not a bug per-se - it's just that they don't detect and return an error, so we do it ourselves. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[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 for building with nasm
On Mon, Jan 02, 2017 at 10:54:18AM -0500, Ronald S. Bultje wrote: > Hi, > > On Sun, Jan 1, 2017 at 8:36 PM, Michael Niedermayer > wrote: > > > On Sun, Jan 01, 2017 at 08:16:00AM +, Rostislav Pehlivanov wrote: > > > On 1 January 2017 at 07:52, John Comeau wrote: > > > > > > > fixes `operation size not specified` errors as described here: > > > > http://stackoverflow.com/questions/36854583/compiling- > > > > ffmpeg-for-kali-linux-2 > > > > > > > > I rebuilt again with yasm and made sure it didn't break that. > > > > -- > > > > John Comeau KE5TFZ j...@unternet.net http://jc.unternet.net/ > > > > "A place for everything, and everything all over the place" > > > > > > > > ___ > > > > ffmpeg-devel mailing list > > > > ffmpeg-devel@ffmpeg.org > > > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > > > > > > > > Odd, I've been using nasm to build ffmpeg for years now. > > > What version do you use? It sure works on nasm 2.12.01 here. > > > > do you see a disadvantage in the change by the patch ? > > if not, then i think it should be applied as it seems improving > > support for some nasm version be that the only issue or one of > > several > > > I think it's fine to merge. applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/rtmphttp: fix bug for rtmphttp
On Mon, Jan 02, 2017 at 10:05:35AM +0800, Steven Liu wrote: > if the http server don't response the http command, > then the thread will be blocked and never be interrupted. > > Reported-by: yinyunjiang > Signed-off-by: Steven Liu > --- > libavformat/rtmphttp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/x86/vc1dsp_mc: Fix build with NASM 2.09.10
make fate passes Signed-off-by: Michael Niedermayer --- libavcodec/x86/vc1dsp_mc.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/vc1dsp_mc.asm b/libavcodec/x86/vc1dsp_mc.asm index 7eaf043964..175c397ae9 100644 --- a/libavcodec/x86/vc1dsp_mc.asm +++ b/libavcodec/x86/vc1dsp_mc.asm @@ -155,7 +155,7 @@ cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, src, rnd, h movhq, 8 sub srcq, 2 sub rndd, (-1+9+9-1) * 1024 ; add -1024 bias -LOAD_ROUNDER_MMX rndq +LOAD_ROUNDER_MMX rndd mova m5, [pw_9] mova m6, [pw_128] pxor m0, m0 -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/x86/vc1dsp_mc: Fix build with NASM 2.09.10
Hi, On Mon, Jan 2, 2017 at 3:35 PM, Michael Niedermayer wrote: > make fate passes > > Signed-off-by: Michael Niedermayer > --- > libavcodec/x86/vc1dsp_mc.asm | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/x86/vc1dsp_mc.asm b/libavcodec/x86/vc1dsp_mc.asm > index 7eaf043964..175c397ae9 100644 > --- a/libavcodec/x86/vc1dsp_mc.asm > +++ b/libavcodec/x86/vc1dsp_mc.asm > @@ -155,7 +155,7 @@ cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, > src, rnd, h > movhq, 8 > sub srcq, 2 > sub rndd, (-1+9+9-1) * 1024 ; add -1024 bias > -LOAD_ROUNDER_MMX rndq > +LOAD_ROUNDER_MMX rndd > mova m5, [pw_9] > mova m6, [pw_128] > pxor m0, m0 > -- > 2.11.0 > LGTM. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale wrote: > On Mon, 2 Jan 2017 00:56:18 -0700 > Pavel Koshevoy wrote: >> Perhaps a more comprehensive solution is needed. I've run into the >> same problem again (avcodec_open2 succeeds, decoding spits errors) >> when I tried to play back an mpeg2 stream with YUV422P pixel format. >> >> I have a new patch but I'd like to test it on a Pascal GPU first. I >> am still hoping that 422 decoding will work. It looks like it should >> be supported, but I've observed on Geforce GT 730 that even though I >> can instantiate a cuvid decoder with cudaVideoChromaFormat_422 without >> error -- the decoded video is garbage everywhere except for 16-pixel >> wide column along the left edge of the frame. >> >> In ee88dcb2 cuvid_handle_video_sequence was hard-coded to error-out if >> the chroma format is not 420. This looks like an NVIDIA driver/cuvid >> bug... does anyone know how to bring it to their attention? > > It is documented as only supporting 420, even though it doesn't return > an error, so it's not a bug per-se - it's just that they don't detect > and return an error, so we do it ourselves. > > --phil I don't recall seeing it mentioned that they do not support 422 and 444 in nvidia docs, but I haven't looked very hard yet. I find it odd that they have enum values to represent these chroma formats, yet they don't work... I'll see if I can file a bug with nvidia about this, tomorrow. I'll send another patch in about an hour to address the original problem that got me looking in cuvid.c. Pavel. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Jan 3, 2017 07:52, "Pavel Koshevoy" wrote: On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale wrote: > On Mon, 2 Jan 2017 00:56:18 -0700 > Pavel Koshevoy wrote: >> Perhaps a more comprehensive solution is needed. I've run into the >> same problem again (avcodec_open2 succeeds, decoding spits errors) >> when I tried to play back an mpeg2 stream with YUV422P pixel format. >> >> I have a new patch but I'd like to test it on a Pascal GPU first. I >> am still hoping that 422 decoding will work. It looks like it should >> be supported, but I've observed on Geforce GT 730 that even though I >> can instantiate a cuvid decoder with cudaVideoChromaFormat_422 without >> error -- the decoded video is garbage everywhere except for 16-pixel >> wide column along the left edge of the frame. >> >> In ee88dcb2 cuvid_handle_video_sequence was hard-coded to error-out if >> the chroma format is not 420. This looks like an NVIDIA driver/cuvid >> bug... does anyone know how to bring it to their attention? > > It is documented as only supporting 420, even though it doesn't return > an error, so it's not a bug per-se - it's just that they don't detect > and return an error, so we do it ourselves. > > --phil I don't recall seeing it mentioned that they do not support 422 and 444 in nvidia docs, but I haven't looked very hard yet. I find it odd that they have enum values to represent these chroma formats, yet they don't work... I'll see if I can file a bug with nvidia about this, tomorrow. I'll send another patch in about an hour to address the original problem that got me looking in cuvid.c. It's a rather well known limitation of the hardware. Only 4:2:0 and nothing else. Now what one has to keep in mind is that the parser is somewhat independent of the hardware capabilities (and the decoder), so it can inform you about stream properties even if the hardware doesn't support it, while the decoder is of course more tightly coupled to the hardware and therefore excludes it directly. Feel free to open a bug if you must, but I don't see what good that's going to do. The parser tells you what is in the stream, not if the hardware can process it. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Input metadata not updated inside mux context
>You can use hls_ts_options to set the mpegts metadata.
I am sorry, but won't this simply copy the metadata to the resulting mgets
segments - but if the stream metadata is not updated following the initial
copy, wouldn't that be the same (initial) metadata, and not the updated one as
it comes in on the input stream?
Thanks!
Christo
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Steven
Liu
Sent: Monday, January 2, 2017 12:04 PM
To: FFmpeg development discussions and patches
Subject: Re: [FFmpeg-devel] Input metadata not updated inside mux context
2017-01-02 17:10 GMT+08:00 Christo Grozev :
>
> Happy New Year to all!
>
> I am trying to create a patch for metadata-aware hls splitting.
> Unfortunately, i cannot seem to get updated metadata from the
> AVFormatContext object inside the muxer scope. For example, within
> hlsenc.c I have this::
>
> static int hls_start(AVFormatContext *s)
> {
> HLSContext *c = s->priv_data;
> AVFormatContext *oc = c->avf;
> AVFormatContext *vtt_oc = c->vtt_avf;
> AVDictionary *options = NULL;
> char *filename, iv_string[KEYSIZE*2 + 1];
> int err = 0;
> int ret = 0;
> AVDictionaryEntry *tag = NULL;
>
> av_log(s, AV_LOG_DEBUG, "Lets check if there's metadata now.. ");
>
> tag = av_dict_get(oc->metadata, "StreamTitle", tag,
> AV_DICT_IGNORE_SUFFIX);
> printf("%s\n",tag->value);
>
>
>
> However, what is logged is always the original StreamTitle that was
> valid when the initial connection to the input url was made, and is
> not updating it further. Granted, this is the output stream context,
> but it does contain the initial metadata, apparently. What would be
> the way to update it, or to access the input context's metadata? Or is
> the only solution to re-poll the input stream in a separate process?
>
You can use hls_ts_options to set the mpegts metadata.
>
>
>
> Thanks in advance
>
> Christo
>
>
>
> ___
> 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] avcodec/x86/vc1dsp_mc: Fix build with NASM 2.09.10
On Mon, Jan 02, 2017 at 03:42:17PM -0500, Ronald S. Bultje wrote: > Hi, > > On Mon, Jan 2, 2017 at 3:35 PM, Michael Niedermayer > wrote: > > > make fate passes > > > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/x86/vc1dsp_mc.asm | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavcodec/x86/vc1dsp_mc.asm b/libavcodec/x86/vc1dsp_mc.asm > > index 7eaf043964..175c397ae9 100644 > > --- a/libavcodec/x86/vc1dsp_mc.asm > > +++ b/libavcodec/x86/vc1dsp_mc.asm > > @@ -155,7 +155,7 @@ cglobal vc1_%2_hor_16b_shift2, 4, 5, 0, dst, stride, > > src, rnd, h > > movhq, 8 > > sub srcq, 2 > > sub rndd, (-1+9+9-1) * 1024 ; add -1024 bias > > -LOAD_ROUNDER_MMX rndq > > +LOAD_ROUNDER_MMX rndd > > mova m5, [pw_9] > > mova m6, [pw_128] > > pxor m0, m0 > > -- > > 2.11.0 > > > > LGTM. applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video parameters
From: Pavel Koshevoy
Evidently CUVID doesn't support decoding 422 or 444 chroma formats,
and only a limited set of resolutions per codec are supported.
Given that stream resolution and pixel format are typically known as a
result of probing it is better to use this info during avcodec_open2
call and fail early in case the video parameters are not supported,
rather than failing later during avcodec_send_packet calls.
This problem surfaced when trying to decode 5120x2700 h246 video on
Geforce GT 730, or when decoding 422 mpeg2 stream on same GPU --
avcodec_open2 succeeded but decoding failed.
---
libavcodec/cuvid.c | 58 +-
1 file changed, 53 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index 8fc713d..febdd71 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -612,7 +612,11 @@ static av_cold int cuvid_decode_end(AVCodecContext *avctx)
return 0;
}
-static int cuvid_test_dummy_decoder(AVCodecContext *avctx, CUVIDPARSERPARAMS
*cuparseinfo)
+static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
+const CUVIDPARSERPARAMS *cuparseinfo,
+cudaVideoChromaFormat probed_chroma_format,
+int probed_width,
+int probed_height)
{
CuvidContext *ctx = avctx->priv_data;
CUVIDDECODECREATEINFO cuinfo;
@@ -622,11 +626,11 @@ static int cuvid_test_dummy_decoder(AVCodecContext
*avctx, CUVIDPARSERPARAMS *cu
memset(&cuinfo, 0, sizeof(cuinfo));
cuinfo.CodecType = cuparseinfo->CodecType;
-cuinfo.ChromaFormat = cudaVideoChromaFormat_420;
+cuinfo.ChromaFormat = probed_chroma_format;
cuinfo.OutputFormat = cudaVideoSurfaceFormat_NV12;
-cuinfo.ulWidth = 1280;
-cuinfo.ulHeight = 720;
+cuinfo.ulWidth = probed_width;
+cuinfo.ulHeight = probed_height;
cuinfo.ulTargetWidth = cuinfo.ulWidth;
cuinfo.ulTargetHeight = cuinfo.ulHeight;
@@ -653,6 +657,36 @@ static int cuvid_test_dummy_decoder(AVCodecContext *avctx,
CUVIDPARSERPARAMS *cu
return 0;
}
+static int convert_to_cuda_video_chroma_format(enum AVPixelFormat pix_fmt,
+ cudaVideoChromaFormat *out)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(pix_fmt);
+if (!(out && desc &&
+ (desc->nb_components == 1 || desc->nb_components == 3) &&
+ (desc->log2_chroma_w < 2 && desc->log2_chroma_h < 2)))
+{
+return AVERROR(EINVAL);
+}
+
+if (desc->nb_components == 1)
+{
+*out = cudaVideoChromaFormat_Monochrome;
+}
+else if (desc->flags == AV_PIX_FMT_FLAG_PLANAR)
+{
+*out = ((desc->log2_chroma_w == 0) ? cudaVideoChromaFormat_444 :
+(desc->log2_chroma_h == 0) ? cudaVideoChromaFormat_422 :
+cudaVideoChromaFormat_420);
+}
+else
+{
+return AVERROR(EINVAL);
+}
+
+// unfortunately, 420 is the only one that works:
+return (*out == cudaVideoChromaFormat_420) ? 0 : AVERROR_EXTERNAL;
+}
+
static av_cold int cuvid_decode_init(AVCodecContext *avctx)
{
CuvidContext *ctx = avctx->priv_data;
@@ -663,12 +697,23 @@ static av_cold int cuvid_decode_init(AVCodecContext
*avctx)
CUcontext cuda_ctx = NULL;
CUcontext dummy;
const AVBitStreamFilter *bsf;
+cudaVideoChromaFormat probed_chroma_format;
+int probed_width;
+int probed_height;
int ret = 0;
enum AVPixelFormat pix_fmts[3] = { AV_PIX_FMT_CUDA,
AV_PIX_FMT_NV12,
AV_PIX_FMT_NONE };
+ret = convert_to_cuda_video_chroma_format(avctx->pix_fmt,
&probed_chroma_format);
+if (ret < 0) {
+// pixel format is not supported:
+return ret;
+}
+probed_width = avctx->coded_width ? avctx->coded_width : 1280;
+probed_height = avctx->coded_height ? avctx->coded_height : 720;
+
// Accelerated transcoding scenarios with 'ffmpeg' require that the
// pix_fmt be set to AV_PIX_FMT_CUDA early. The sw_pix_fmt, and the
// pix_fmt for non-accelerated transcoding, do not need to be correct
@@ -824,7 +869,10 @@ static av_cold int cuvid_decode_init(AVCodecContext *avctx)
if (ret < 0)
goto error;
-ret = cuvid_test_dummy_decoder(avctx, &ctx->cuparseinfo);
+ret = cuvid_test_dummy_decoder(avctx, &ctx->cuparseinfo,
+ probed_chroma_format,
+ probed_width,
+ probed_height);
if (ret < 0)
goto error;
--
2.9.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Mon, Jan 2, 2017 at 2:00 PM, Hendrik Leppkes wrote: > On Jan 3, 2017 07:52, "Pavel Koshevoy" wrote: > > On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale wrote: >> It is documented as only supporting 420, even though it doesn't return >> an error, so it's not a bug per-se - it's just that they don't detect >> and return an error, so we do it ourselves. >> >> --phil > > > I don't recall seeing it mentioned that they do not support 422 and > 444 in nvidia docs, but I haven't looked very hard yet. I find it odd > that they have enum values to represent these chroma formats, yet they > don't work... I'll see if I can file a bug with nvidia about this, > tomorrow. I'll send another patch in about an hour to address the > original problem that got me looking in cuvid.c. > > > It's a rather well known limitation of the hardware. Only 4:2:0 and nothing > else. > > Now what one has to keep in mind is that the parser is somewhat independent > of the hardware capabilities (and the decoder), so it can inform you about > stream properties even if the hardware doesn't support it, while the > decoder is of course more tightly coupled to the hardware and therefore > excludes it directly. > > Feel free to open a bug if you must, but I don't see what good that's going > to do. The parser tells you what is in the stream, not if the hardware can > process it. > > - Hendrik Actually, I have a 4:2:2 file that does decode "fine" with mjpeg_cuvid: Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '422.mov': Metadata: creation_time : 2004-04-12T14:27:11.00Z Duration: 00:00:26.28, start: 0.00, bitrate: 27683 kb/s Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj422p(pc, bt470bg/unknown/unknown), 720x486 [SAR 72:72 DAR 40:27], 27538 kb/s, 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default) Metadata: creation_time : 2004-04-12T14:27:11.00Z handler_name: Apple Alias Data Handler encoder : Photo - JPEG Stream #0:1(eng): Audio: mp3 (ms[0]U / 0x5500736D), 44100 Hz, stereo, s16p, 128 kb/s (default) Metadata: creation_time : 2004-04-12T14:27:11.00Z handler_name: Apple Alias Data Handler It decodes "fine", except for one green line along the bottom edge of the frame. The other file I have that decodes with severe artifacts with mpeg2_cuvid is: Input #0, mxf, from '422.mxf': Metadata: uid : 903476a1-f73c-11df-bbb6-001c23d05b47 generation_uid : 903476a2-f73c-11df-b56d-001c23d05b47 company_name: Telestream product_name: FlipFactory product_version : 3.0 application_platform: win32 product_uid : ffeeddcc-bbaa-9988-7766-554433221100 modification_date: 2010-11-23T20:02:13.00Z material_package_umid: 0x060A2B340101010501010D12134CFC7B94BB4C04235505834F1F001C23D05B47 timecode: 00:00:00:00 Duration: 00:03:35.05, start: 0.00, bitrate: 62607 kb/s Stream #0:0: Video: mpeg2video (4:2:2), yuv422p(tv, bt470bg/bt470m/bt470m, top first), 720x512 [SAR 128:135 DAR 4:3], 5 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 59.94 tbc Metadata: file_package_umid: 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47 file_package_name: Source Package track_name : Track 1 Stream #0:1: Audio: pcm_s24le, 48000 Hz, 4 channels, s32 (24 bit), 4608 kb/s Metadata: file_package_umid: 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47 file_package_name: Source Package track_name : Track 2 Still feels like an NVIDIA bug, Pavel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv3] add signature filter for MPEG7 video signature
Hi,
I made a new thread because of the delay between this mail and my last one.
Attached is the next iteration of the patch (rebased to current master).
Main change is, that I've moved the writing and lookup code from uninit to
request_frame (thank you for the suggestion). Please comment.
Kind regards,
Gerion>From 01d96a18deaf6904cf140858e653195d50bc8fb2 Mon Sep 17 00:00:00 2001
From: Gerion Entrup
Date: Mon, 2 Jan 2017 02:08:57 +0100
Subject: [PATCH] add signature filter for MPEG7 video signature
This filter does not implement all features of MPEG7. Missing features:
- compression of signature files
- work only on (cropped) parts of the video
---
Changelog | 1 +
configure | 1 +
doc/filters.texi | 89 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/signature.h| 569 ++
libavfilter/signature_lookup.c | 573 ++
libavfilter/version.h | 2 +-
libavfilter/vf_signature.c | 768 +
9 files changed, 2004 insertions(+), 1 deletion(-)
create mode 100644 libavfilter/signature.h
create mode 100644 libavfilter/signature_lookup.c
create mode 100644 libavfilter/vf_signature.c
diff --git a/Changelog b/Changelog
index aff9ab0..687131c 100644
--- a/Changelog
+++ b/Changelog
@@ -12,6 +12,7 @@ version :
- 16.8 floating point pcm decoder
- 24.0 floating point pcm decoder
- Apple Pixlet decoder
+- MPEG-7 Video Signature filter
version 3.2:
- libopenmpt demuxer
diff --git a/configure b/configure
index f035f35..3e68a44 100755
--- a/configure
+++ b/configure
@@ -3126,6 +3126,7 @@ showspectrum_filter_deps="avcodec"
showspectrum_filter_select="fft"
showspectrumpic_filter_deps="avcodec"
showspectrumpic_filter_select="fft"
+signature_filter_deps="gpl avcodec avformat"
smartblur_filter_deps="gpl swscale"
sofalizer_filter_deps="netcdf avcodec"
sofalizer_filter_select="fft"
diff --git a/doc/filters.texi b/doc/filters.texi
index 42cdd2e..8174b5b 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12543,6 +12543,95 @@ saturation maximum: %@{metadata:lavfi.signalstats.SATMAX@}
@end example
@end itemize
+@anchor{signature}
+@section signature
+
+Calculates the MPEG-7 Video Signature. The filter could handle more than one
+input. In this case the matching between the inputs could be calculated. The
+filter passthrough the first input. The signature of each stream could be written
+into a file.
+
+It accepts the following options:
+
+@table @option
+@item detectmode
+Enable or disable the matching process.
+
+Available values are:
+
+@table @samp
+@item off
+Disable the calculation of a matching (default).
+@item full
+Calculate the mathing for the whole video and output whether the whole video
+matches or only parts.
+@item fast
+Calculate as long as a matching is found or the video ends. Should be faster in
+some cases.
+@end table
+
+@item nb_inputs
+Set the number of inputs. The option value must be a non negative integer.
+Default value is 1.
+
+@item filename
+Set the path to which the output is written. If there is more than one input,
+the path must be a prototype, i.e. must contain %d or %0nd (where n is a positive
+integer), that will be replaced with the input number. If no filename is
+specified, no output will be written. This is the default.
+
+@item format
+Choose the output format.
+
+Available values are:
+
+@table @samp
+@item binary
+Use the specified binary representation (default).
+@item xml
+Use the specified xml representation.
+@end table
+
+@item th_d
+Set threshold to detect one word as similar. The option value must be an integer
+greater than zero. The default value is 9000.
+
+@item th_dc
+Set threshold to detect all words as similar. The option value must be an integer
+greater than zero. The default value is 6.
+
+@item th_xh
+Set threshold to detect frames as similar. The option value must be an integer
+greater than zero. The default value is 116.
+
+@item th_di
+Set the minimum length of a sequence in frames to recognize it as matching
+sequence. The option value must be a non negative integer value.
+The default value is 0.
+
+@item th_it
+Set the minimum relation, that matching frames to all frames must have.
+The option value must be a double value between 0 and 1. The default value is 0.5.
+@end table
+
+@subsection Examples
+
+@itemize
+@item
+To calculate the signature of an input video and store it in signature.bin:
+@example
+ffmpeg -i input.mkv -vf signature=filename=signature.bin -map 0:v -f null -
+@end example
+
+@item
+To detect whether two videos matches and store the signatures in XML format in
+signature0.xml and signature1.xml:
+@example
+ffmpeg -i input1.mkv -i input2.mkv -filter_complex "[0:v][1:v] signature=nb_inputs=2:detectmode=full:format=xml:filename=signature%d.xml" -map :v -f null -
+@end example
+
+@end itemize
+
@anc
Re: [FFmpeg-devel] [PATCH 2/2] wmavoice: prevent division by zero crash
On 02.01.2017 04:09, Ronald S. Bultje wrote: > On Sun, Jan 1, 2017 at 5:51 PM, Andreas Cadhalpun > wrote: > Fine for me. Patch doing that is attached. > > > LGTM. Pushed. Best regards, Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] wmavoice: truncate spillover_nbits if too large
On 02.01.2017 04:14, Ronald S. Bultje wrote: > On Sun, Jan 1, 2017 at 5:55 PM, Andreas Cadhalpun > wrote: > So what would you do instead? > > I'd just remove the message, but otherwise what you're doing (truncate > spillover_nbits) seems fine. OK. While I think that the message could have been useful, the important thing is that the code doesn't crash. So I've just pushed the patch without the log message. Best regards, Andreas ___ 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 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. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution
On Mon, Jan 2, 2017 at 3:08 PM, Pavel Koshevoy wrote: > On Mon, Jan 2, 2017 at 2:00 PM, Hendrik Leppkes wrote: >> On Jan 3, 2017 07:52, "Pavel Koshevoy" wrote: >> >> On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale wrote: > >>> It is documented as only supporting 420, even though it doesn't return >>> an error, so it's not a bug per-se - it's just that they don't detect >>> and return an error, so we do it ourselves. >>> >>> --phil >> >> >> I don't recall seeing it mentioned that they do not support 422 and >> 444 in nvidia docs, but I haven't looked very hard yet. I find it odd >> that they have enum values to represent these chroma formats, yet they >> don't work... I'll see if I can file a bug with nvidia about this, >> tomorrow. I'll send another patch in about an hour to address the >> original problem that got me looking in cuvid.c. >> >> >> It's a rather well known limitation of the hardware. Only 4:2:0 and nothing >> else. >> >> Now what one has to keep in mind is that the parser is somewhat independent >> of the hardware capabilities (and the decoder), so it can inform you about >> stream properties even if the hardware doesn't support it, while the >> decoder is of course more tightly coupled to the hardware and therefore >> excludes it directly. >> >> Feel free to open a bug if you must, but I don't see what good that's going >> to do. The parser tells you what is in the stream, not if the hardware can >> process it. >> >> - Hendrik > > > Actually, I have a 4:2:2 file that does decode "fine" with mjpeg_cuvid: > Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '422.mov': > Metadata: > creation_time : 2004-04-12T14:27:11.00Z > Duration: 00:00:26.28, start: 0.00, bitrate: 27683 kb/s > Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj422p(pc, > bt470bg/unknown/unknown), 720x486 [SAR 72:72 DAR 40:27], 27538 kb/s, > 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default) > Metadata: > creation_time : 2004-04-12T14:27:11.00Z > handler_name: Apple Alias Data Handler > encoder : Photo - JPEG > Stream #0:1(eng): Audio: mp3 (ms[0]U / 0x5500736D), 44100 Hz, > stereo, s16p, 128 kb/s (default) > Metadata: > creation_time : 2004-04-12T14:27:11.00Z > handler_name: Apple Alias Data Handler > > It decodes "fine", except for one green line along the bottom edge of the > frame. > > > The other file I have that decodes with severe artifacts with mpeg2_cuvid is: > Input #0, mxf, from '422.mxf': > Metadata: > uid : 903476a1-f73c-11df-bbb6-001c23d05b47 > generation_uid : 903476a2-f73c-11df-b56d-001c23d05b47 > company_name: Telestream > product_name: FlipFactory > product_version : 3.0 > application_platform: win32 > product_uid : ffeeddcc-bbaa-9988-7766-554433221100 > modification_date: 2010-11-23T20:02:13.00Z > material_package_umid: > 0x060A2B340101010501010D12134CFC7B94BB4C04235505834F1F001C23D05B47 > timecode: 00:00:00:00 > Duration: 00:03:35.05, start: 0.00, bitrate: 62607 kb/s > Stream #0:0: Video: mpeg2video (4:2:2), yuv422p(tv, > bt470bg/bt470m/bt470m, top first), 720x512 [SAR 128:135 DAR 4:3], > 5 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 59.94 tbc > Metadata: > file_package_umid: > 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47 > file_package_name: Source Package > track_name : Track 1 > Stream #0:1: Audio: pcm_s24le, 48000 Hz, 4 channels, s32 (24 bit), 4608 > kb/s > Metadata: > file_package_umid: > 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47 > file_package_name: Source Package > track_name : Track 2 > > Still feels like an NVIDIA bug, > Pavel I've tested three 4:2:2 mjpeg samples so far that decode fine with mjpeg_cuvid, and one 4:4:4 mjpeg sample that also decoded correctly with mjpeg_cuvid ... so it seems at least MJPEG support is not limited to 4:2:0 by CUVID Pavel. ___ 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 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.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Input metadata not updated inside mux context
2017-01-03 5:06 GMT+08:00 Christo Grozev :
>
> >You can use hls_ts_options to set the mpegts metadata.
> I am sorry, but won't this simply copy the metadata to the resulting mgets
> segments - but if the stream metadata is not updated following the initial
> copy, wouldn't that be the same (initial) metadata, and not the updated one
> as it comes in on the input stream?
>
I just found the describe of metadata for hls in IETF *3.5. WebVTT*
So i think you can save it into two place:
1. mpegts
2. webvtt
Is that right?
>
> Thanks!
>
> Christo
>
>
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Steven Liu
> Sent: Monday, January 2, 2017 12:04 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] Input metadata not updated inside mux context
>
> 2017-01-02 17:10 GMT+08:00 Christo Grozev :
>
> >
> > Happy New Year to all!
> >
> > I am trying to create a patch for metadata-aware hls splitting.
> > Unfortunately, i cannot seem to get updated metadata from the
> > AVFormatContext object inside the muxer scope. For example, within
> > hlsenc.c I have this::
> >
> > static int hls_start(AVFormatContext *s)
> > {
> > HLSContext *c = s->priv_data;
> > AVFormatContext *oc = c->avf;
> > AVFormatContext *vtt_oc = c->vtt_avf;
> > AVDictionary *options = NULL;
> > char *filename, iv_string[KEYSIZE*2 + 1];
> > int err = 0;
> > int ret = 0;
> > AVDictionaryEntry *tag = NULL;
> >
> > av_log(s, AV_LOG_DEBUG, "Lets check if there's metadata now.. ");
> >
> > tag = av_dict_get(oc->metadata, "StreamTitle", tag,
> > AV_DICT_IGNORE_SUFFIX);
> > printf("%s\n",tag->value);
> >
> >
> >
> > However, what is logged is always the original StreamTitle that was
> > valid when the initial connection to the input url was made, and is
> > not updating it further. Granted, this is the output stream context,
> > but it does contain the initial metadata, apparently. What would be
> > the way to update it, or to access the input context's metadata? Or is
> > the only solution to re-poll the input stream in a separate process?
> >
>
> You can use hls_ts_options to set the mpegts metadata.
>
> >
> >
> >
> > Thanks in advance
> >
> > Christo
> >
> >
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]lavf/matroska: Fix the A_MPEG/L1 codec_id
Hi!
Attached patch fixes MP1 muxing in mkv.
Please comment, Carl Eugen
From 649977cf7af3734ec81204514874e9d16fcb6b29 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 3 Jan 2017 03:43:34 +0100
Subject: [PATCH] lavf/matroska: Fix the codec_id for mkv tag A_MPEG/L1.
When the mapping was originally added AV_CODEC_ID_MP1 did not exist.
---
libavformat/matroska.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index f3e1be7..c8e5341 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -35,7 +35,7 @@ const CodecTags ff_mkv_codec_tags[]={
{"A_FLAC" , AV_CODEC_ID_FLAC},
{"A_MLP", AV_CODEC_ID_MLP},
{"A_MPEG/L2", AV_CODEC_ID_MP2},
-{"A_MPEG/L1", AV_CODEC_ID_MP2},
+{"A_MPEG/L1", AV_CODEC_ID_MP1},
{"A_MPEG/L3", AV_CODEC_ID_MP3},
{"A_OPUS" , AV_CODEC_ID_OPUS},
{"A_OPUS/EXPERIMENTAL",AV_CODEC_ID_OPUS},
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] mac, ios clock_gettime patch
If ffmpeg is build with iOS 10 sdk, program will crash on iOS 9. This patch fixes the crash. 0001-check-clock_gettime-at-runtime-for-apple-platforms.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: Fix bug that the QSV encoded frames'width and height are 32-aligned
From 8b1bcc0634f6ce36acfbd2bfdd26690a6323d09c Mon Sep 17 00:00:00 2001 From: Zhengxu Date: Fri, 16 Dec 2016 11:10:34 +0800 Subject: [PATCH] libavutil/hwcontext_qsv: Fix bug that the QSV encoded frames' width and height are 32-aligned. Description: If an input is of 1280x720, the encoded stream created by command below is of 1280x736: ffmpeg -hwaccel qsv -c:v h264_qsv -i test.h264 -c:v h264_qsv out.h264 Reason: When creating a AVQSVFramesContext, width and height shouldn't be aligned, or the mfxSurfaces' cropW and cropH will be wrong. Fix: User should configure AVQSVFramesContext with origin width and height and AVFramesContext will align the width and height when being initiallized. Signed-off-by: ChaoX A Liu Signed-off-by: Huang, Zhengxu Signed-off-by: Andrew, Zhang --- ffmpeg_qsv.c | 8 libavutil/hwcontext_qsv.c | 8 ++-- 2 files changed, 10 insertions(+), 6 deletions(-) diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c index 68ff5bd..aab7375 100644 --- a/ffmpeg_qsv.c +++ b/ffmpeg_qsv.c @@ -76,8 +76,8 @@ int qsv_init(AVCodecContext *s) frames_ctx = (AVHWFramesContext*)ist->hw_frames_ctx->data; frames_hwctx = frames_ctx->hwctx; -frames_ctx->width = FFALIGN(s->coded_width, 32); -frames_ctx->height= FFALIGN(s->coded_height, 32); +frames_ctx->width = s->coded_width; +frames_ctx->height= s->coded_height; frames_ctx->format= AV_PIX_FMT_QSV; frames_ctx->sw_format = s->sw_pix_fmt; frames_ctx->initial_pool_size = 64; @@ -152,8 +152,8 @@ int qsv_transcode_init(OutputStream *ost) encode_frames = (AVHWFramesContext*)encode_frames_ref->data; qsv_frames = encode_frames->hwctx; -encode_frames->width = FFALIGN(ist->resample_width, 32); -encode_frames->height= FFALIGN(ist->resample_height, 32); +encode_frames->width = ist->resample_width; +encode_frames->height= ist->resample_height; encode_frames->format= AV_PIX_FMT_QSV; encode_frames->sw_format = AV_PIX_FMT_NV12; encode_frames->initial_pool_size = 1; diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index 03244a6..2dc9aca 100644 --- a/libavutil/hwcontext_qsv.c +++ b/libavutil/hwcontext_qsv.c @@ -308,9 +308,13 @@ static int qsv_init_pool(AVHWFramesContext *ctx, uint32_t fourcc) surf->Info.ChromaFormat = MFX_CHROMAFORMAT_YUV444; surf->Info.FourCC = fourcc; -surf->Info.Width = ctx->width; +/* + * WxH being aligned with 32x32 is needed by MSDK. + * CropW and CropH are the real size of the frame. + */ +surf->Info.Width = FFALIGN(ctx->width, 32); surf->Info.CropW = ctx->width; -surf->Info.Height = ctx->height; +surf->Info.Height = FFALIGN(ctx->height, 32); surf->Info.CropH = ctx->height; surf->Info.FrameRateExtN = 25; surf->Info.FrameRateExtD = 1; -- 1.8.3.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavutil/hwcontext_qsv: Command line using hwaccel 'QSV' doesn't work
From 687ce9c804b2618f021100235c46a33b48fa522c Mon Sep 17 00:00:00 2001
From: Zhengxu
Date: Wed, 14 Dec 2016 11:55:31 +0800
Subject: [PATCH] libavutil/hwcontext_qsv: Command line using hwaccel 'QSV'
doesn't work.
Command: ffmpeg -hwaccel qsv -c:v h264_qsv -i test.264 -c:v h264_qsv out.264
Reason: hwcontext_qsv will create a child hwcontext_vaapi. VAAPI will
open X11 display ":0.0" defaultly. However, MSDK doesn't support X11 so
far. This results in the failure of this command.
Fix: When using VAAPI, let VAAPI try to create DRM display handle by scanning
device nodes under '/dev/dri/'.
Signed-off-by: ChaoX A Liu
Signed-off-by: Huang, Zhengxu
Signed-off-by: Andrew, Zhang
---
libavutil/hwcontext_qsv.c | 44 +++-
1 file changed, 31 insertions(+), 13 deletions(-)
diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 2dc9aca..2701b5a 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -707,12 +707,41 @@ static mfxIMPL choose_implementation(const char *device)
return impl;
}
+static int create_proper_child_device(AVBufferRef **ctx, const char *device,
int flags)
+{
+enum AVHWDeviceType child_device_type;
+char adapter[256];
+int adapter_num;
+
+if (CONFIG_VAAPI)
+child_device_type = AV_HWDEVICE_TYPE_VAAPI;
+else if (CONFIG_DXVA2)
+child_device_type = AV_HWDEVICE_TYPE_DXVA2;
+else
+return AVERROR(ENOSYS);
+
+if (device || CONFIG_DXVA2)
+return av_hwdevice_ctx_create(ctx, child_device_type, device, NULL,
flags);
+
+for (adapter_num = 0; adapter_num < 6; adapter_num++) {
+if (adapter_num < 3)
+snprintf(adapter,sizeof(adapter),
+"/dev/dri/renderD%d", adapter_num+128);
+else
+snprintf(adapter,sizeof(adapter),
+"/dev/dri/card%d", adapter_num-3);
+if (av_hwdevice_ctx_create(ctx, child_device_type, adapter, NULL,
flags) == 0)
+return 0;
+}
+
+return AVERROR(ENOSYS);
+}
+
static int qsv_device_create(AVHWDeviceContext *ctx, const char *device,
AVDictionary *opts, int flags)
{
AVQSVDeviceContext *hwctx = ctx->hwctx;
QSVDevicePriv *priv;
-enum AVHWDeviceType child_device_type;
AVDictionaryEntry *e;
mfxVersionver = { { 3, 1 } };
@@ -730,18 +759,7 @@ static int qsv_device_create(AVHWDeviceContext *ctx, const
char *device,
ctx->free= qsv_device_free;
e = av_dict_get(opts, "child_device", NULL, 0);
-
-if (CONFIG_VAAPI)
-child_device_type = AV_HWDEVICE_TYPE_VAAPI;
-else if (CONFIG_DXVA2)
-child_device_type = AV_HWDEVICE_TYPE_DXVA2;
-else {
-av_log(ctx, AV_LOG_ERROR, "No supported child device type is
enabled\n");
-return AVERROR(ENOSYS);
-}
-
-ret = av_hwdevice_ctx_create(&priv->child_device_ctx, child_device_type,
- e ? e->value : NULL, NULL, 0);
+ret = create_proper_child_device(&priv->child_device_ctx, e ? e->value :
NULL, 0);
if (ret < 0)
return ret;
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
