Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Skip writing trailer for MP4 output when in streaming mode
On 1/31/19 7:08 AM, myp...@gmail.com wrote:
> On Thu, Jan 24, 2019 at 2:01 PM Karthick J wrote:
>>
>> In streaming mode mp4 trailer is not required for playout.
>> ---
>> libavformat/dashenc.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 9c90cf17e5..6299e179c2 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -1210,7 +1210,7 @@ static int dash_init(AVFormatContext *s)
>>
>> if (os->segment_type == SEGMENT_TYPE_MP4) {
>> if (c->streaming)
> Can we add some comments when setting some special flags in the code,
> not just comments in the commit message?
Thanks for your suggestion. Have added the comments in this patch
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/240258.html
>> -av_dict_set(, "movflags",
>> "frag_every_frame+dash+delay_moov+skip_sidx", 0);
>> +av_dict_set(, "movflags",
>> "frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer", 0);
>> else
>> av_dict_set(, "movflags",
>> "frag_custom+dash+delay_moov", 0);
>> } else {
>> --
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/dashenc: Added comments
Added comments regarding usage of certain movflags in streaming mode.
---
libavformat/dashenc.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index a0b44a0ec3..f8782756b4 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -1216,6 +1216,17 @@ static int dash_init(AVFormatContext *s)
if (os->segment_type == SEGMENT_TYPE_MP4) {
if (c->streaming)
+// Explanation for why certain movflags are used for streaming:
+// frag_every_frame :- Every frame should be moof fragment, so
+// the data from current frame can be streamed without
+// waiting for the completion of the entire segment.
+// skip_sidx :- The SIDX atom for each moof will result in a
+// significant bitrate overhead. Hence disabling it here.
+// skip_trailer :- Writing mp4 trailer means that a list of all
+// fragment's information is stored, which results
continuous
+// growth in memory usage as more fragments are muxed.
+// Disabling trailer results in deterministic memory usage.
+// Anyways trailer is unnecessary of fmp4 segment.
av_dict_set(, "movflags",
"frag_every_frame+dash+delay_moov+skip_sidx+skip_trailer", 0);
else
av_dict_set(, "movflags", "frag_custom+dash+delay_moov",
0);
--
2.17.1 (Apple Git-112)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avformat/dashenc: Added option to repeatedly publish master playlist
The master playlist can be published at a specified interval with this option
---
doc/muxers.texi | 3 +++
libavformat/dashenc.c | 9 -
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 36010cf2d1..372fab2f92 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -315,6 +315,9 @@ This option will also try to comply with the above open
spec, till Apple's spec
Applicable only when @var{streaming} and @var{hls_playlist} options are
enabled.
This is an experimental feature.
+@item -master_m3u8_publish_rate @var{master_m3u8_publish_rate}
+Publish master playlist repeatedly every after specified number of segment
intervals.
+
@end table
@anchor{framecrc}
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 37a7547b12..a0b44a0ec3 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -141,6 +141,7 @@ typedef struct DASHContext {
SegmentType segment_type_option; /* segment type as specified in options
*/
int ignore_io_errors;
int lhls;
+int master_publish_rate;
} DASHContext;
static struct codec_string {
@@ -965,13 +966,18 @@ static int write_manifest(AVFormatContext *s, int final)
return ret;
}
-if (c->hls_playlist && !c->master_playlist_created) {
+if (c->hls_playlist) {
char filename_hls[1024];
const char *audio_group = "A1";
char audio_codec_str[128] = "\0";
int is_default = 1;
int max_audio_bitrate = 0;
+// Publish master playlist only the configured rate
+if (c->master_playlist_created && (!c->master_publish_rate ||
+ c->streams[0].segment_index % c->master_publish_rate))
+return 0;
+
if (*c->dirname)
snprintf(filename_hls, sizeof(filename_hls), "%smaster.m3u8",
c->dirname);
else
@@ -1798,6 +1804,7 @@ static const AVOption options[] = {
{ "webm", "make segment file in WebM format", 0, AV_OPT_TYPE_CONST, {.i64
= SEGMENT_TYPE_WEBM }, 0, UINT_MAX, E, "segment_type"},
{ "ignore_io_errors", "Ignore IO errors during open and write. Useful for
long-duration runs with network output", OFFSET(ignore_io_errors),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
{ "lhls", "Enable Low-latency HLS(Experimental). Adds #EXT-X-PREFETCH tag
with current segment's URI", OFFSET(lhls), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
1, E },
+{ "master_m3u8_publish_rate", "Publish master playlist every after this
many segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 =
0}, 0, UINT_MAX, E},
{ NULL },
};
--
2.17.1 (Apple Git-112)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled
> > At least from my understanding it would be perfectly legal to exclude > > the CUDA kernel code from ffmpeg and add an option to the filters > > for specifying a file containing the compiled CUDA kernel to be loaded > > at runtime (via cuModuleLoadData). > > > > What do you think? > > It's certainly something you could do, but the kernels would need to be > distributed separately, respecting the licence of the individual kernel > source files. In the case of the nvidia authored filters, the kernels > are under an MIT style licence, so you'd be able to distribute compiled > kernels, but for yadif_cuda, the kernel source is still covered by the > lgpl and you would have to evaluate what is required for compliance > (IANAL, etc, etc) in that case. Thanks again for your kind reply. Although I’m not a lawyer myself, I know that if you’re the sole(!) author of the yadif_cuda kernel source, then you would be allowed to publish that code under any additional license you want. But that would be your very own decision, I wouldn’t dare to ask you about doing so. ;-) --- Another way might be local compilation via NVRTC or NVCC, but this would require the CUDA SDK to be installed. I guess you’ve already thought about that..? -- softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions
VP9 decoding speed improved about 109.3%(from 32fps to 67fps, tested on loongson 3A3000). --- libavcodec/mips/Makefile | 1 + libavcodec/mips/vp9_mc_mmi.c | 680 + libavcodec/mips/vp9dsp_init_mips.c | 42 +++ libavcodec/mips/vp9dsp_mips.h | 50 +++ 4 files changed, 773 insertions(+) create mode 100644 libavcodec/mips/vp9_mc_mmi.c diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile index c827649..c5b54d5 100644 --- a/libavcodec/mips/Makefile +++ b/libavcodec/mips/Makefile @@ -88,3 +88,4 @@ MMI-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_mmi.o MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o MMI-OBJS-$(CONFIG_HEVC_DECODER) += mips/hevcdsp_mmi.o MMI-OBJS-$(CONFIG_VP3DSP) += mips/vp3dsp_idct_mmi.o +MMI-OBJS-$(CONFIG_VP9_DECODER)+= mips/vp9_mc_mmi.o diff --git a/libavcodec/mips/vp9_mc_mmi.c b/libavcodec/mips/vp9_mc_mmi.c new file mode 100644 index 000..145bbff --- /dev/null +++ b/libavcodec/mips/vp9_mc_mmi.c @@ -0,0 +1,680 @@ +/* + * Copyright (c) 2019 gxw + * + * 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, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA + */ + +#include "libavcodec/vp9dsp.h" +#include "libavutil/mips/mmiutils.h" +#include "vp9dsp_mips.h" + +#define GET_DATA_H_MMI \ +"pmaddhw%[ftmp4],%[ftmp4], %[filter1]\n\t" \ +"pmaddhw%[ftmp5],%[ftmp5], %[filter2]\n\t" \ +"paddw %[ftmp4],%[ftmp4], %[ftmp5] \n\t" \ +"punpckhwd %[ftmp5],%[ftmp4], %[ftmp0] \n\t" \ +"paddw %[ftmp4],%[ftmp4], %[ftmp5] \n\t" \ +"pmaddhw%[ftmp6],%[ftmp6], %[filter1]\n\t" \ +"pmaddhw%[ftmp7],%[ftmp7], %[filter2]\n\t" \ +"paddw %[ftmp6],%[ftmp6], %[ftmp7] \n\t" \ +"punpckhwd %[ftmp7],%[ftmp6], %[ftmp0] \n\t" \ +"paddw %[ftmp6],%[ftmp6], %[ftmp7] \n\t" \ +"punpcklwd %[srcl], %[ftmp4], %[ftmp6] \n\t" \ +"pmaddhw%[ftmp8],%[ftmp8], %[filter1]\n\t" \ +"pmaddhw%[ftmp9],%[ftmp9], %[filter2]\n\t" \ +"paddw %[ftmp8],%[ftmp8], %[ftmp9] \n\t" \ +"punpckhwd %[ftmp9],%[ftmp8], %[ftmp0] \n\t" \ +"paddw %[ftmp8],%[ftmp8], %[ftmp9] \n\t" \ +"pmaddhw%[ftmp10], %[ftmp10], %[filter1]\n\t" \ +"pmaddhw%[ftmp11], %[ftmp11], %[filter2]\n\t" \ +"paddw %[ftmp10], %[ftmp10], %[ftmp11] \n\t" \ +"punpckhwd %[ftmp11], %[ftmp10], %[ftmp0] \n\t" \ +"paddw %[ftmp10], %[ftmp10], %[ftmp11] \n\t" \ +"punpcklwd %[srch], %[ftmp8], %[ftmp10] \n\t" + +#define GET_DATA_V_MMI \ +"punpcklhw %[srcl], %[ftmp4], %[ftmp5] \n\t" \ +"pmaddhw%[srcl], %[srcl],%[filter10] \n\t" \ +"punpcklhw %[ftmp12], %[ftmp6], %[ftmp7] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter32] \n\t" \ +"paddw %[srcl], %[srcl],%[ftmp12] \n\t" \ +"punpcklhw %[ftmp12], %[ftmp8], %[ftmp9] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter54] \n\t" \ +"paddw %[srcl], %[srcl],%[ftmp12] \n\t" \ +"punpcklhw %[ftmp12], %[ftmp10], %[ftmp11] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter76] \n\t" \ +"paddw %[srcl], %[srcl],%[ftmp12] \n\t" \ +"punpckhhw %[srch], %[ftmp4], %[ftmp5] \n\t" \ +"pmaddhw%[srch], %[srch],%[filter10] \n\t" \ +"punpckhhw %[ftmp12], %[ftmp6], %[ftmp7] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter32] \n\t" \ +"paddw %[srch], %[srch],%[ftmp12] \n\t" \ +"punpckhhw %[ftmp12], %[ftmp8], %[ftmp9] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter54] \n\t" \ +"paddw %[srch], %[srch],%[ftmp12] \n\t" \ +"punpckhhw %[ftmp12], %[ftmp10], %[ftmp11] \n\t" \ +"pmaddhw%[ftmp12], %[ftmp12], %[filter76] \n\t" \ +"paddw %[srch], %[srch],%[ftmp12] \n\t" + +#define ROUND_POWER_OF_TWO_MMI
Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled
On Mon, 18 Feb 2019 21:44:33 + Soft Works wrote: > > Hi Phil, > > thanks for replying. I was just about to start migrating the filters > to dynamic loading (nv-codec-headers).. > > From your explanations, the situation doesn't seem to be as bad as it > could be. When the CPU code of the filters can be changed to dynamic > linking, then there's just the CUDA kernel code left to deal with. > > The GPL may forbid to include and distribute it inside or as part of > ffmpeg. But it cannot forbid ffmpeg to copy some external binary code > at runtime from the filesystem to the GPU and execute it there > (different process, different harware). That would be similar like a > non-GPL application being allowed to bundle ffmpeg.exe (GPL-compiled). > > At least from my understanding it would be perfectly legal to exclude > the CUDA kernel code from ffmpeg and add an option to the filters > for specifying a file containing the compiled CUDA kernel to be loaded > at runtime (via cuModuleLoadData). > > What do you think? It's certainly something you could do, but the kernels would need to be distributed separately, respecting the licence of the individual kernel source files. In the case of the nvidia authored filters, the kernels are under an MIT style licence, so you'd be able to distribute compiled kernels, but for yadif_cuda, the kernel source is still covered by the lgpl and you would have to evaluate what is required for compliance (IANAL, etc, etc) in that case. --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
Fixes: runtime error: signed integer overflow: 2147483598 + 128 cannot be represented in type 'int' Fixes: 12926/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5705100733972480 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/jpeg2000dwt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/jpeg2000dwt.c b/libavcodec/jpeg2000dwt.c index ce1678a3d7..badf0f8cd0 100644 --- a/libavcodec/jpeg2000dwt.c +++ b/libavcodec/jpeg2000dwt.c @@ -531,7 +531,7 @@ static void dwt_decode97_int(DWTContext *s, int32_t *t) } for (i = 0; i < w * h; i++) -data[i] = (data[i] + ((1<>1)) >> I_PRESHIFT; +data[i] = (data[i] + ((1LL<>1)) >> I_PRESHIFT; } int ff_jpeg2000_dwt_init(DWTContext *s, int border[2][2], -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] doc/formats: add reference to ffmpeg(1) stream specifiers as that docs is more complete
On Sun, Feb 17, 2019, at 10:58 AM, Marton Balint wrote: > Signed-off-by: Marton Balint > --- > doc/formats.texi | 24 ++-- LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] MAINTAINERS: add myself for tonemap_opencl
> -Original Message- > From: Song, Ruiling > Sent: Wednesday, February 13, 2019 9:29 AM > To: ffmpeg-devel@ffmpeg.org > Cc: Song, Ruiling > Subject: [PATCH] MAINTAINERS: add myself for tonemap_opencl > > Signed-off-by: Ruiling Song > --- > MAINTAINERS | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 7ac2d22..412a739 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -362,6 +362,7 @@ Filters: >vf_ssim.c Paul B Mahol >vf_stereo3d.c Paul B Mahol >vf_telecine.c Paul B Mahol > + vf_tonemap_opencl.c Ruiling Song >vf_yadif.cMichael Niedermayer >vf_zoompan.c Paul B Mahol Ping? > > -- > 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] lavf/mpeg: fix indent
On Sun, Feb 17, 2019, at 4:56 PM, Morris Stock wrote: > > Ah, yes, but seems no one else use short name, see new attachment, thanks. You can use whatever name or alias you want. We only want consistency, so future patches from the same address should ideally have the same author name. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [Patch] lavf/mpeg: fix indent
On Mon, Feb 18, 2019 at 01:56:22AM +, Morris Stock wrote: > On 2/17/19 2:06 AM, Michael Niedermayer wrote: > > On Fri, Feb 15, 2019 at 01:48:04AM +, Morris Stock wrote: > >> mpeg.c | 56 > >> 1 file changed, 28 insertions(+), 28 deletions(-) > >> 2c6d9fc35eaf3f348761d553ec3029275709acba 0001-lavf-mpeg-fix-indent.patch > >> From 2a2dc1dd417a78650675f327f6db832e58e229a8 Mon Sep 17 00:00:00 2001 > >> From: wxf > >> Date: Fri, 15 Feb 2019 09:41:29 +0800 > >> Subject: [PATCH] lavf/mpeg: fix indent > >> > >> Signed-off-by: wxf > >> --- > >> libavformat/mpeg.c | 56 > >> +++--- > >> 1 file changed, 28 insertions(+), 28 deletions(-) > > > > LGTM, if the 3 letter author name is Intended instead of a full name > > > > Ah, yes, but seems no one else use short name, see new attachment, thanks. > > > [...] > > > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > mpeg.c | 56 > 1 file changed, 28 insertions(+), 28 deletions(-) > db4ff47863d9b8c5968cddf316882364c93bab8f 0001-lavf-mpeg-fix-indent.patch > From 80ec71bf54f3b29169d5eb0a9375a11ceef8e692 Mon Sep 17 00:00:00 2001 > From: Xiaofeng Wang > Date: Mon, 18 Feb 2019 09:16:58 +0800 > Subject: [PATCH] lavf/mpeg: fix indent > > Signed-off-by: Xiaofeng Wang > --- > libavformat/mpeg.c | 56 > +++--- > 1 file changed, 28 insertions(+), 28 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCHv2 2/4] avformat/utils: be more strict about stream specifiers
This reworks the code to be more strict about accepting stream specifiers. From
now on we strictly enforce the syntax in the documentation up until the
decisive part of the stream specifier. Therefore matching stream specifiers
always need to be correct, non matching specifiers only need to be correct
until the decisive part.
Also recursion is changed to a simple loop.
Signed-off-by: Marton Balint
---
libavformat/utils.c | 82 +
1 file changed, 51 insertions(+), 31 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index d113a16c80..2e50c5c0ee 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -5100,18 +5100,19 @@ AVRational av_guess_frame_rate(AVFormatContext *format,
AVStream *st, AVFrame *f
/**
* Matches a stream specifier (but ignores requested index).
*
- * @param index set if a specific index is requested from the matching streams
+ * @param indexptr set to point to the requested stream index if there is one
*
* @return <0 on error
* 0 if st is NOT a matching stream
* >0 if st is a matching stream
*/
static int match_stream_specifier(AVFormatContext *s, AVStream *st,
- const char *spec, int *index)
+ const char *spec, const char **indexptr)
{
+while (*spec) {
if (*spec <= '9' && *spec >= '0') { /* opt:index */
-if (index)
-*index = strtol(spec, NULL, 0);
+if (indexptr)
+*indexptr = spec;
return 1;
} else if (*spec == 'v' || *spec == 'a' || *spec == 's' || *spec == 'd' ||
*spec == 't' || *spec == 'V') { /* opt:[vasdtV] */
@@ -5127,6 +5128,9 @@ static int match_stream_specifier(AVFormatContext *s,
AVStream *st,
case 'V': type = AVMEDIA_TYPE_VIDEO; nopic = 1; break;
default: av_assert0(0);
}
+if (*spec && *spec++ != ':') /* If we are not at the end, then
another specifier must follow. */
+return AVERROR(EINVAL);
+
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
if (type != st->codecpar->codec_type
@@ -5139,37 +5143,39 @@ FF_ENABLE_DEPRECATION_WARNINGS
#endif
if (nopic && (st->disposition & AV_DISPOSITION_ATTACHED_PIC))
return 0;
-if (*spec++ == ':') /* possibly followed by another specifier */
-return match_stream_specifier(s, st, spec, index);
-return 1;
} else if (*spec == 'p' && *(spec + 1) == ':') {
int prog_id, i, j;
+int found = 0;
char *endptr;
spec += 2;
prog_id = strtol(spec, , 0);
+/* Disallow empty id and make sure that if we are not at the end, then
another specifier must follow. */
+if (spec == endptr || (*endptr && *endptr++ != ':'))
+return AVERROR(EINVAL);
+spec = endptr;
for (i = 0; i < s->nb_programs; i++) {
if (s->programs[i]->id != prog_id)
continue;
for (j = 0; j < s->programs[i]->nb_stream_indexes; j++) {
if (st->index == s->programs[i]->stream_index[j]) {
-if (*endptr++ == ':') { // p::
-return match_stream_specifier(s, st, endptr, index);
-} else {
-return 1;
-}
+found = 1;
+i = s->nb_programs;
+break;
}
}
}
-return 0;
+if (!found)
+return 0;
} else if (*spec == '#' ||
(*spec == 'i' && *(spec + 1) == ':')) {
int stream_id;
char *endptr;
spec += 1 + (*spec == 'i');
stream_id = strtol(spec, , 0);
-if (!*endptr)
-return stream_id == st->id;
+if (spec == endptr || *endptr)/* Disallow empty id and
make sure we are at the end. */
+return AVERROR(EINVAL);
+return stream_id == st->id;
} else if (*spec == 'm' && *(spec + 1) == ':') {
AVDictionaryEntry *tag;
char *key, *val;
@@ -5193,7 +5199,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
av_freep();
return ret;
-} else if (*spec == 'u') {
+} else if (*spec == 'u' && *(spec + 1) == '\0') {
AVCodecParameters *par = st->codecpar;
#if FF_API_LAVF_AVCTX
FF_DISABLE_DEPRECATION_WARNINGS
@@ -5238,40 +5244,54 @@ FF_ENABLE_DEPRECATION_WARNINGS
#else
return par->codec_id != AV_CODEC_ID_NONE && val != 0;
#endif
-} else if (!*spec) /* empty specifier, matches everything */
-return 1;
+} else {
+return AVERROR(EINVAL);
+}
+}
-return AVERROR(EINVAL);
+/* empty specifier, matches everything */
+return 1;
}
int avformat_match_stream_specifier(AVFormatContext *s, AVStream *st,
const char *spec)
{
-int ret;
-
Re: [FFmpeg-devel] [PATCH v2] ffmpeg: Add option to force a specific decode format
On Tue, Nov 13, 2018 at 11:43:31PM +, Mark Thompson wrote: > Fixes #7519. > --- > doc/ffmpeg.texi | 13 > fftools/ffmpeg.c | 10 ++ > fftools/ffmpeg.h | 4 > fftools/ffmpeg_opt.c | 47 > 4 files changed, 74 insertions(+) i did already "LGTM" this IIRC, but as its being pinged ... LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled
> > in the above context I'm wondering about whether it is mandatory to > > treat the "cuda_sdk" option as a non-free option? > > > > In case of libnpp it's obviously required to statically link to > > proprietary Nvidia code code for which there's not public source code > > available. > > > > But for yadif_cuda and scale_cuda it's just about dynamic linking to > > a system component (driver), which seems to be allowed by the GPL or > > GPLv3 at least. > > > > Are my assumptions correct? > > > > If yes, could we move 'cuda_sdk' from the > > HWACCEL_LIBRARY_NONFREE_LIST to the HWACCEL_LIBRARY_LIST in order to > > allow using the cuda filters even with GPL builds? > > Unfortunately, it is not possible, and I say this as someone who has > spent some time investigating how to remove the SDK dependency from the > filters. While it is possible to adjust the CPU-side filter code to use > the nv-codec-headers, the cuda kernels cannot be built without > statically linking them against a library that ships with the SDK, > under the GPL-incompatible SDK licence. > > To completely remove the dependency, you'd need to rewrite the kernels, > and I'm not even sure that works in practice. The clang nvptx compiler > works for a subset of the cuda API but even that seems to require the > same SDK library to actually link and fully resolve all symbols. I > imagine one could write a kernel using only core primitives, but that > would require implementing your own versions of a bunch of the higher > level code used by the kernels we have today. (eg: You couldn't use > texture or surface references, and would need to pass raw memory and do > all your own bounds checking, etc) > > --phil Hi Phil, thanks for replying. I was just about to start migrating the filters to dynamic loading (nv-codec-headers).. From your explanations, the situation doesn't seem to be as bad as it could be. When the CPU code of the filters can be changed to dynamic linking, then there's just the CUDA kernel code left to deal with. The GPL may forbid to include and distribute it inside or as part of ffmpeg. But it cannot forbid ffmpeg to copy some external binary code at runtime from the filesystem to the GPU and execute it there (different process, different harware). That would be similar like a non-GPL application being allowed to bundle ffmpeg.exe (GPL-compiled). At least from my understanding it would be perfectly legal to exclude the CUDA kernel code from ffmpeg and add an option to the filters for specifying a file containing the compiled CUDA kernel to be loaded at runtime (via cuModuleLoadData). What do you think? --softworkz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avformat/utils: be more strict about stream specifiers
On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote: 2019-02-17 20:55 GMT+01:00, Marton Balint : This reworks the code to be more strict about accepting stream specifiers. From now on we strictly enforce the syntax in the documentation up until the decisive part of the stream specifier. Therefore matching stream specifiers always need to be correct, non matching specifiers only need to be correct until the decisive part. Could you give an example for something that changes behaviour with this patch? ffmpeg -f lavfi -i testsrc -codec:voohoo mpeg2video out.avi Example for the next patch: ffmpeg -f lavfi -i testsrc -codec:a:xxx mpeg2video out.avi Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] FW: Requirements for compiling with CUDA_SDK option enabled
On Sun, 17 Feb 2019 06:24:05 + Soft Works wrote: > Hi, > > in the above context I'm wondering about whether it is mandatory to > treat the "cuda_sdk" option as a non-free option? > > In case of libnpp it's obviously required to statically link to > proprietary Nvidia code code for which there's not public source code > available. > > But for yadif_cuda and scale_cuda it's just about dynamic linking to > a system component (driver), which seems to be allowed by the GPL or > GPLv3 at least. > > Are my assumptions correct? > > If yes, could we move 'cuda_sdk' from the > HWACCEL_LIBRARY_NONFREE_LIST to the HWACCEL_LIBRARY_LIST in order to > allow using the cuda filters even with GPL builds? Unfortunately, it is not possible, and I say this as someone who has spent some time investigating how to remove the SDK dependency from the filters. While it is possible to adjust the CPU-side filter code to use the nv-codec-headers, the cuda kernels cannot be built without statically linking them against a library that ships with the SDK, under the GPL-incompatible SDK licence. To completely remove the dependency, you'd need to rewrite the kernels, and I'm not even sure that works in practice. The clang nvptx compiler works for a subset of the cuda API but even that seems to require the same SDK library to actually link and fully resolve all symbols. I imagine one could write a kernel using only core primitives, but that would require implementing your own versions of a bunch of the higher level code used by the kernels we have today. (eg: You couldn't use texture or surface references, and would need to pass raw memory and do all your own bounds checking, etc) --phil ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] RTMFP integration
On Sat, Feb 16, 2019 at 09:40:06PM +0100, Thomas Jammet wrote:
> Hi everybody,
>
> You will find in attachment a patch proposal to add an optional RTMFP
> support in ffmpeg using librtmfp.
>
> For more information : https://github.com/MonaSolutions/librtmfp
>
> *--*
>
> *Thomas JAMMET*
> configure |4
> doc/protocols.texi | 120 ++
> libavformat/Makefile|1
> libavformat/librtmfp.c | 260
>
> libavformat/protocols.c |1
> 5 files changed, 386 insertions(+)
> a4c87a2eea01d1e0886f6bdcfb96a39f5b38cd97
> 0001-Added-RTMFP-protocol-to-ffmpeg.patch
> From 2d6877f5cb7a9eeb65ed93fe1f6e1ba06229159d Mon Sep 17 00:00:00 2001
> From: Jammet Thomas
> Date: Sat, 16 Feb 2019 21:35:46 +0100
> Subject: [PATCH] Added RTMFP protocol to ffmpeg
>
> ---
> configure | 4 +
> doc/protocols.texi | 120 ++
> libavformat/Makefile| 1 +
> libavformat/librtmfp.c | 260
>
> libavformat/protocols.c | 1 +
> 5 files changed, 386 insertions(+)
> create mode 100644 libavformat/librtmfp.c
>
> diff --git a/configure b/configure
> index bf40c1dcb9..1b1fae433d 100755
> --- a/configure
> +++ b/configure
> @@ -257,6 +257,7 @@ External library support:
>--enable-librsvg enable SVG rasterization via librsvg [no]
>--enable-librubberband enable rubberband needed for rubberband filter
> [no]
>--enable-librtmp enable RTMP[E] support via librtmp [no]
> + --enable-librtmfpenable RTMFP support via librtmfp [no]
>--enable-libshineenable fixed-point MP3 encoding via libshine [no]
>--enable-libsmbclientenable Samba protocol via libsmbclient [no]
>--enable-libsnappy enable Snappy compression, needed for hap
> encoding [no]
> @@ -1754,6 +1755,7 @@ EXTERNAL_LIBRARY_LIST="
> libpulse
> librsvg
> librtmp
> +librtmfp
> libshine
> libsmbclient
> libsnappy
> @@ -3365,6 +3367,7 @@ librtmpe_protocol_deps="librtmp"
> librtmps_protocol_deps="librtmp"
> librtmpt_protocol_deps="librtmp"
> librtmpte_protocol_deps="librtmp"
> +librtmfp_protocol_deps="librtmfp"
> libsmbclient_protocol_deps="libsmbclient gplv3"
> libsrt_protocol_deps="libsrt"
> libsrt_protocol_select="network"
> @@ -6169,6 +6172,7 @@ enabled libopus && {
> enabled libpulse && require_pkg_config libpulse libpulse
> pulse/pulseaudio.h pa_context_new
> enabled librsvg && require_pkg_config librsvg librsvg-2.0
> librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
> enabled librtmp && require_pkg_config librtmp librtmp
> librtmp/rtmp.h RTMP_Socket
> +enabled librtmfp && require_pkg_config librtmfp librtmfp
> librtmfp/librtmfp.h RTMFP_Connect
> enabled librubberband && require_pkg_config librubberband "rubberband >=
> 1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append
> librubberband_extralibs "-lstdc++"
> enabled libshine && require_pkg_config libshine shine
> shine/layer3.h shine_encode_buffer
> enabled libsmbclient && { check_pkg_config libsmbclient smbclient
> libsmbclient.h smbc_init ||
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index fb7725e058..e2e974a5cb 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -834,6 +834,126 @@ To play the same stream using @command{ffplay}:
> ffplay "rtmp://myserver/live/mystream live=1"
> @end example
>
> +@section librtmfp
> +
> +Real-Time Media Flow Protocol.
> +
> +Requires the presence of the librtmfp headers and library during
> +configuration. You need to explicitly configure the build with
> +"--enable-librtmfp".
> +
> +This protocol provides most functionalities of the UDP protocol RTMFP :
> +unicast, direct p2p and multicast (via NetGroup).
> +
> +The required syntax for an RTMFP URL is:
> +@example
> +rtmfp://@var{hostname}[:@var{port}][/@var{app}][/@var{playpath}]
> +@end example
> +
> +The accepted parameters are:
> +@table @option
> +
> +@item hostname
> +The address of the RTMFP server.
> +
> +@item port
> +The number of the UDP port to use (by default is 1935).
> +
> +@item app
> +It is the name of the application to access. It usually corresponds to the
> +path where the application is installed on the RTMFP server (e.g.
> +/ondemand/,/flash/live/, etc.).
> +
> +@item playpath
> +It is the path or name of the resource to play with reference to the
> +application specified in app.
> +@end table
> +
> +Additionally, the following parameters can be set via command line options
> +(or in code via @code{AVOption}s):
> +@table @option
> +
> +@item rtmfp_socketReceiveSize
> +Socket receive buffer size.
> +
> +@item rtmfp_socketSendSize
> +Socket send buffer size.
> +
> +@item rtmfp_audioUnbuffered
> +Unbuffered audio mode (default to false).
> +
> +@item rtmfp_videoUnbuffered
> +Unbuffered video mode (default
Re: [FFmpeg-devel] [PATCH 2/4] avformat/utils: be more strict about stream specifiers
On Sun, Feb 17, 2019 at 08:55:38PM +0100, Marton Balint wrote: > This reworks the code to be more strict about accepting stream specifiers. > From > now on we strictly enforce the syntax in the documentation up until the > decisive part of the stream specifier. Therefore matching stream specifiers > always need to be correct, non matching specifiers only need to be correct > until the decisive part. > > Also recursion is changed to a simple loop. > > Signed-off-by: Marton Balint > --- > libavformat/utils.c | 81 > + > 1 file changed, 50 insertions(+), 31 deletions(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index d113a16c80..39290a647d 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -5100,18 +5100,19 @@ AVRational av_guess_frame_rate(AVFormatContext > *format, AVStream *st, AVFrame *f > /** > * Matches a stream specifier (but ignores requested index). > * > - * @param index set if a specific index is requested from the matching > streams > + * @param indexptr set to point to the requested stream index if there is one > * > * @return <0 on error > * 0 if st is NOT a matching stream > * >0 if st is a matching stream > */ > static int match_stream_specifier(AVFormatContext *s, AVStream *st, > - const char *spec, int *index) > + const char *spec, const char **indexptr) this produces a warning: libavformat/utils.c: In function ‘avformat_match_stream_specifier’: libavformat/utils.c:5267:5: warning: passing argument 4 of ‘match_stream_specifier’ from incompatible pointer type [enabled by default] [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] hls m3u8-playlist decoding question
Hello, I know it's off-topic, but I hope someone could help me. I use the xupnpd2-mediaserver (https://github.com/clark15b/xupnpd2) on my router to display some hls-streams on the TV. I try to receive this stream: https://www.mall.tv/planespotting. I solved the missing https-support in xupnpd2 by using haproxy as reverse proxy. I'm not a developer, but I think there is an "error" in the m3u8 parsing/decoding (this file: https://github.com/clark15b/xupnpd2/blob/master/plugin_hls_common.cpp), because the stream https://www.mall.tv/planespotting is 4 hours behind the actual time. The russian original-author doesn't reply. Maybe someone could take a look in plugin_hls_common.cpp. Sorry again for this off-topic question. Best regards, Thomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or BFF together with progressive
> -Original Message-
> From: Li, Zhong
> Sent: Monday, February 18, 2019 13:48
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Cc: Fu, Linjie
> Subject: RE: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or
> BFF together with progressive
>
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Linjie Fu
> > Sent: Saturday, February 16, 2019 3:50 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [FFmpeg-devel] [PATCH, RFC] lavf/deinterlace_qsv: set TFF or BFF
> > together with progressive
> >
> > Currently, BFF or TFF will not be set if the frame is progressive.
> > This will break the Input PicStruct check in MSDK because of absence of the
> > specific PicStruct check for:
> > MFX_PICSTRUCT_PROGRESSIVE | MFX_PICSTRUCT_FIELD_REPEATED
> >
> > Set PicStruct to MFX_PICSTRUCT_FIELD_TFF or
> MFX_PICSTRUCT_FIELD_BFF
> > to match the CheckInputPicStruct in MSDK.
> >
> > Fix #7701.
>
> After checking this ticket, I believe this is not a MSDK issue, and current
> fix in
> this patch is not correct.
> If I understand correctly, this issue only happens when H264 pic_struct = 5 or
> 6.
> In this case, MFX_PICSTRUCT_FIELD_TFF or MFX_PICSTRUCT_FIELD_BFF
> should be set, else we don't know which filed should be repeated.
>
> > Signed-off-by: Linjie Fu
> > ---
> > Is it acceptable to add the TFF or BFF to PicStruct according to the
> > attribute
> > of the input frames, even if it's not interlaced?
> > Or it should be fixed in MSDK level to support more PicStruct?
> >
> > libavfilter/vf_deinterlace_qsv.c | 5 +++--
> > 1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavfilter/vf_deinterlace_qsv.c
> b/libavfilter/vf_deinterlace_qsv.c
> > index d6b02e98c5..f03d65f029 100644
> > --- a/libavfilter/vf_deinterlace_qsv.c
> > +++ b/libavfilter/vf_deinterlace_qsv.c
> > @@ -417,8 +417,9 @@ static int submit_frame(AVFilterContext *ctx,
> > AVFrame *frame,
> > qf->surface.Info.CropH = qf->frame->height;
> >
> > qf->surface.Info.PicStruct = !qf->frame->interlaced_frame ?
> > MFX_PICSTRUCT_PROGRESSIVE :
> > - (qf->frame->top_field_first ?
> > MFX_PICSTRUCT_FIELD_TFF :
> > -
> > MFX_PICSTRUCT_FIELD_BFF);
> > +
> > MFX_PICSTRUCT_UNKNOWN;
> > +qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
> > MFX_PICSTRUCT_FIELD_TFF :
> > +
> > + MFX_PICSTRUCT_FIELD_BFF;
> > if (qf->frame->repeat_pict == 1)
> > qf->surface.Info.PicStruct |= MFX_PICSTRUCT_FIELD_REPEATED;
>
> I believe the correct fix should be here (previous code change is not needed
> and should be removed):
> if (qf->frame->repeat_pict == 1) {
> qf->surface.Info.PicStruct |= MFX_PICSTRUCT_FIELD_REPEATED;
> qf->surface.Info.PicStruct |= qf->frame->top_field_first ?
> MFX_PICSTRUCT_FIELD_TFF : MFX_PICSTRUCT_FIELD_BFF;
> }
>
> > else if (qf->frame->repeat_pict == 2)
Thanks, it seems more reasonable in the repeated_first_field cases in #7701.
But I still have concerns:
Progressive| TFF or Progressive | BFF frames will never be set after the
modification.
A discussion on " Is progresive TFF or BFF in mpeg2" :
https://forum.doom9.org/showthread.php?t=165176
I think it is a more common way to suit all probable cases (not only in #7701):
Allow FFmpeg qsv to set all attributes got from each frame, and pass down to
MSDK/driver.
It depends on MSDK/driver to decide whether the TFF and BFF flag is valid and
useful in progressive mode.
--
Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]lavf/mxfdec: Export EIA608 Closed Captions by default
sön 2019-02-17 klockan 16:28 +0100 skrev Marton Balint: > > On Sun, 17 Feb 2019, Marton Balint wrote: > > > > > > > On Sun, 17 Feb 2019, Carl Eugen Hoyos wrote: > > > > > > > > 2019-02-17 1:40 GMT+01:00, Marton Balint : > > > > > > > > On Sat, 16 Feb 2019, Carl Eugen Hoyos wrote: > > > > > > > > > > I am not sure why there is an option to disable Closed Captions > > > > > export, > > > > > but disabling the export by default seems like a bad idea to me. > > > > > > > > SMPTE 436M can be any kind of ancillary data, not only closed captions. > > > > That is why the default behaviour (pass all the data to userspace so a > > > > userspace app can parse it properly) makes sense. > > > > Some applications might depend on this. > > > > > > Wouldn't it still make more sense to change the default? > > > > Sorry, no. We should not change existing behaviour for this. > > > > > The application that knows it needs the ancillary data, well, knows > > > it while the average user who reads the mxf file has no idea that > > > there is a subtitle stream and has no idea that FFmpeg can read > > > the subtitle stream. > > > > > > I would bump micro in any case and the option also works fine > > > with older FFmpeg versions so I don't really see the issue. > > > > Issue is that you are removing a data stream which was previously > > provided. Also CC extraction in MXF decoder is a hack. It should be > > deprecated after the API will be capable of bitstream filtering between > > different codecs. And the VANC data can be parsed to multiple > > subtitle/data streams. Why eia608 has the perference? Why not teletext, or > > SCTE messages? All in all, it is better to keep hacks under the > > option until we come up with better API. > > One more thing is that the fact that a file has VANC data does not mean > that it actually has Closed Captions data. It might, or it might not, so > unconditionally advertising a CC stream just because there _might_ be CC > data would also be bad. Isn't this stuff also used for teletext and whatnot? I generally agree that we shouldn't assume it's subtitles /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
