Re: [FFmpeg-devel] [PATCH] avformat/dashenc: Add hls_master_name option
On 6/14/20 8:43 PM, Przemysław Sobala wrote:
> Any comments about that?
>
> --
> Best regards
> Przemysław Sobala
>
> On Wed, Jun 10, 2020 at 1:15 PM Przemysław Sobala <
> przemyslaw.sob...@gmail.com> wrote:
>
>> ---
>> doc/muxers.texi | 4 +++-
>> libavformat/dashenc.c | 8 +---
>> 2 files changed, 8 insertions(+), 4 deletions(-)
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>> index d6f9de3702..b1389a3227 100644
>> --- a/doc/muxers.texi
>> +++ b/doc/muxers.texi
>> @@ -267,8 +267,10 @@ Override User-Agent field in HTTP header. Applicable
>> only for HTTP output.
>> @item http_persistent @var{http_persistent}
>> Use persistent HTTP connections. Applicable only for HTTP output.
>> @item hls_playlist @var{hls_playlist}
>> -Generate HLS playlist files as well. The master playlist is generated
>> with the filename master.m3u8.
>> +Generate HLS playlist files as well. The master playlist is generated
>> with the filename @var{hls_master_name}.
>> One media playlist file is generated for each stream with filenames
>> media_0.m3u8, media_1.m3u8, etc.
>> +@item hls_master_name @var{file_name}
>> +HLS master playlist name. Default is "master.m3u8".
>> @item streaming @var{streaming}
>> Enable (1) or disable (0) chunk streaming mode of output. In chunk
>> streaming
>> mode, each frame will be a moof fragment which forms a chunk.
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 00a37b175d..3e587acdff 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -171,6 +171,7 @@ typedef struct DASHContext {
>> const char *user_agent;
>> AVDictionary *http_opts;
>> int hls_playlist;
>> +const char *hls_master_name;
>> int http_persistent;
>> int master_playlist_created;
>> AVIOContext *mpd_out;
>> @@ -1261,9 +1262,9 @@ static int write_manifest(AVFormatContext *s, int
>> final)
>> return 0;
>>
>> if (*c->dirname)
>> -snprintf(filename_hls, sizeof(filename_hls), "%smaster.m3u8",
>> c->dirname);
>> +snprintf(filename_hls, sizeof(filename_hls), "%s%s",
>> c->dirname, c->hls_master_name);
>> else
>> -snprintf(filename_hls, sizeof(filename_hls), "master.m3u8");
>> +snprintf(filename_hls, sizeof(filename_hls), "%s",
>> c->hls_master_name);
>>
>> snprintf(temp_filename, sizeof(temp_filename), use_rename ?
>> "%s.tmp" : "%s", filename_hls);
>>
>> @@ -2292,7 +2293,7 @@ static int dash_write_trailer(AVFormatContext *s)
>>
>> if (c->hls_playlist && c->master_playlist_created) {
>> char filename[1024];
>> -snprintf(filename, sizeof(filename), "%smaster.m3u8",
>> c->dirname);
>> +snprintf(filename, sizeof(filename), "%s%s", c->dirname,
>> c->hls_master_name);
>> dashenc_delete_file(s, filename);
>> }
>> }
>> @@ -2349,6 +2350,7 @@ static const AVOption options[] = {
>> { "http_user_agent", "override User-Agent field in HTTP header",
>> OFFSET(user_agent), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 0, E},
>> { "http_persistent", "Use persistent HTTP connections",
>> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>> { "hls_playlist", "Generate HLS playlist files(master.m3u8,
>> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0,
>> 1, E },
>> +{ "hls_master_name", "HLS master playlist name",
>> OFFSET(hls_master_name), AV_OPT_TYPE_STRING, {.str = "master.m3u8"}, 0, 0,
>> E },
>> { "streaming", "Enable/Disable streaming mode of output. Each frame
>> will be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 },
>> 0, 1, E },
>> { "timeout", "set timeout for socket I/O operations",
>> OFFSET(timeout), AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags =
>> E },
>> { "index_correction", "Enable/Disable segment index correction
>> logic", OFFSET(index_correction), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E },
>> --
>> 2.25.4
>>
>>
Pushed. Thanks.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://urldefense.proofpoint.com/v2/url?u=https-3A__ffmpeg.org_mailman_listinfo_ffmpeg-2Ddevel&d=DwIGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=xOoesbz-6ff1GPXp5Lg4jf1ZG99yp4a1qhxVn_YOwRU&m=J4ur_c-YVlnfJvWviasMhbv_AZhB63VFkaL4Afm5XyI&s=Jgwmj43pX8S5nR_4ipFwPcgt1e7vg4UJoNUjqVKDN9E&e=
>
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: Error out on duplicated utf16 strings
sön 2020-06-14 klockan 20:19 +0200 skrev Marton Balint: > > On Sun, 14 Jun 2020, Michael Niedermayer wrote: > > > Alternatively we could free the already allocated element > > Yeah, I kind of prefer that, we potentially allow non-string values to > occur multiple times, so I'd say let's allow string values as well, even > if that is not common. (I am not sure if it is strictly invalid or just > uncommon). Are there files in the wild that do this? Being stricter is often the better option when it comes to MXF. A muxer that outputs metadata more than once might be doing something wrong. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Kicked out Paul from IRC
sön 2020-06-14 klockan 20:37 +0200 skrev Michael Niedermayer: > Also iam interrested in designing a modern audio codec for fun once (if i find > the time), and if by then sonic.c is still around i might just put the code in > there. Just because that would be the obvious place to put such code in. You might want to talk to Xiph and the IETF, and some of the usual suspects (jmspeex, gmaxwell etc). Lots of lessons were learned while developing Opus, plenty of ideas to explore. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] MPEG-2 FLAGS2_FAST benchmarks
On Sun, Jun 14, 2020 at 12:47:30AM +0200, Michael Niedermayer wrote: > On Sat, Jun 13, 2020 at 05:11:05PM +0100, Kieran Kunhya wrote: [...] > Problem 2 > We do not meassure speed this way because its not realiable nor practical > just look at this, especially the difference and variation > ./ffmpeg -threads 1 -i ~/videos/matrixbench_mpeg2.mpg -f null - >8941 decicycles in non-intra, 2097003 runs,149 skipste=N/A speed=53.2x > >8941 decicycles in non-intra, 2097013 runs,139 skipste=N/A speed=54.1x > >8942 decicycles in non-intra, 2097038 runs,114 skipste=N/A speed=54.1x > >8970 decicycles in non-intra, 2097037 runs,115 skipste=N/A speed= 54x > > > ./ffmpeg -threads 1 -flags2 fast -i ~/videos/matrixbench_mpeg2.mpg -f null - >8718 decicycles in non-intra, 2097020 runs,132 skipste=N/A speed=54.6x > >8701 decicycles in non-intra, 2097044 runs,108 skipste=N/A speed=54.6x > >8718 decicycles in non-intra, 2097034 runs,118 skipste=N/A speed=54.5x > >8702 decicycles in non-intra, 2097029 runs,123 skipste=N/A speed=54.5x > As it was requested, some semi proper statistical analysis while eating breakfast Iam sure i have made mistakes heres as i dont regularly do such analysis. Two sample t-test (Welch), using T distribution (DF=5.2188) (left-tailed) (validation) 1. H0 hypothesis Since p-value < α, H0 is rejected. The average of fast's population is considered to be less than the average. of the default's population. In other words, the average of the default's population is bigger than the fast's population, and the difference is big enough to be statistically significant 2. P-value p-value equals 3.60652e-7, ( p(x≤T) = 3.60652e-7 ). This means that the chance of type1 error (rejecting a correct H0) is small: 3.607e-7 (0.36%). The smaller the p-value the more it supports H1. Two sample mann-whitney u, using Normal tables (n=4.) (left-tailed) (validation) 1. H0 hypothesis Since p-value < α, H0 is rejected. The randomly selected value of fast's population is considered to be less than the randomly selected value. of the default's population. 2. P-value p-value equals 0.0142148, ( p(x≤Z) = 0.0142148 ). This means that the chance of type1 error (rejecting a correct H0) is small: 0.01421 (1.42%). The smaller the p-value the more it supports H1. Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Breaking DRM is a little like attempting to break through a door even though the window is wide open and the only thing in the house is a bunch of things you dont want and which you would get tomorrow for free anyway signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat: AMQP: add option delivery_mode
Signed-off-by: Levis Florian
---
doc/protocols.texi| 13 +
libavformat/libamqp.c | 6 +-
2 files changed, 18 insertions(+), 1 deletion(-)
diff --git a/doc/protocols.texi b/doc/protocols.texi
index 7aa758541c..336246e67a 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -109,6 +109,19 @@ the received message may be truncated causing decoding
errors.
The timeout in seconds during the initial connection to the broker. The
default value is rw_timeout, or 5 seconds if rw_timeout is not set.
+@item delivery_mode @var{mode}
+Sets the delivery mode.
+
+The following values are recognized:
+@table @samp
+@item persistent
+Delivery mode set to "persistent" (2). This is the default value.
+
+@item non-persistent
+Delivery mode set to "non-persistent" (1)
+
+@end table
+
@end table
@section async
diff --git a/libavformat/libamqp.c b/libavformat/libamqp.c
index aaf0e51152..83de2229fb 100644
--- a/libavformat/libamqp.c
+++ b/libavformat/libamqp.c
@@ -39,6 +39,7 @@ typedef struct AMQPContext {
int pkt_size;
int64_t connection_timeout;
int pkt_size_overflow;
+int delivery_mode;
} AMQPContext;
#define STR_LEN 1024
@@ -52,6 +53,9 @@ static const AVOption options[] = {
{ "exchange", "Exchange to send/read packets", OFFSET(exchange),
AV_OPT_TYPE_STRING, { .str = "amq.direct" }, 0, 0, .flags = D | E },
{ "routing_key", "Key to filter streams", OFFSET(routing_key),
AV_OPT_TYPE_STRING, { .str = "amqp" }, 0, 0, .flags = D | E },
{ "connection_timeout", "Initial connection timeout",
OFFSET(connection_timeout), AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT64_MAX,
.flags = D | E},
+{ "delivery_mode", "Delivery mode", OFFSET(delivery_mode),
AV_OPT_TYPE_INT, { .i64 = AMQP_DELIVERY_PERSISTENT }, 1, 2, .flags = E,
"delivery_mode"},
+{ "persistent", "persistent delivery mode", 0, AV_OPT_TYPE_CONST,
{.i64=AMQP_DELIVERY_PERSISTENT }, 0, 0, E, "delivery_mode" },
+{ "non-persistent", "non-persistent delivery mode", 0, AV_OPT_TYPE_CONST,
{.i64=AMQP_DELIVERY_NONPERSISTENT }, 0, 0, E, "delivery_mode" },
{ NULL }
};
@@ -222,7 +226,7 @@ static int amqp_proto_write(URLContext *h, const unsigned
char *buf, int size)
props._flags = AMQP_BASIC_CONTENT_TYPE_FLAG |
AMQP_BASIC_DELIVERY_MODE_FLAG;
props.content_type = amqp_cstring_bytes("octet/stream");
-props.delivery_mode = 2; /* persistent delivery mode */
+props.delivery_mode = s->delivery_mode;
ret = amqp_basic_publish(s->conn, DEFAULT_CHANNEL,
amqp_cstring_bytes(s->exchange),
amqp_cstring_bytes(s->routing_key), 0, 0,
--
2.27.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: extracting and outputing klv from vanc
Hello,
I appreciate the comments.
Missing docs for the new option.
>
Does this refer to .texi files? I'll update the docs.
> Avoid these if possible. Yes, this is C++ code but only because the
> decklink
> API requires it. Also it gives me a compile error, and I am not familiar
> enough
> with C++ to figure out what is going on
>
It makes everything much easier (just like using std::atomic for ref
counting does).
It also doesn't change the needed version of C++ since std::atomic is
available in C++11 and above.
However, that error message is concerning and I'd like to fix it. Which
compiler is it?
You only use this to avoid calling ->Release() right? If that is the case,
> then
> I'd avoid this as well, I am not sure about the compiler support of such
> templating.
>
Yes, it's used to avoid manually releasing COM pointers which can become
quite a hassle especially if multiple COM objects are involved.
Error handling is simplified as well since there's no need to worry which
COM object(s) should be released.
As far as compiler support goes, this is the most basic C++ template that's
supported by basically every C++ compiler in the last 20+ years.
I'm willing to remove it if you still feel strongly that it's unnecessary.
This interface is only available from DeckLink SDK 10.10 or so, but you
> have not
> bumped the version requirement in configure.
>
Wasn't sure which files should be edited for this.
I'll get the exact SDK version that introduces it and bump it in configure.
Is the sorting really needed? Aren't they supposed to be sorted in the
> VANC?
>
Well, they should be, but it's not guaranteed so this is just a safety net.
If it was guaranteed there would be no need for PSC fields.
Maybe avoid the error message and increase ctx->dropped like other similar
> code
> does it.
>
Will do.
Mixed code and declaration.
>
I'll move that block below the declaration.
Lose the error message for ENOMEM.
>
I was just following what the other code that adds streams does.
AV_OPT_TYPE_BOOL
>
I'll change that asap.
Thanks,
Milos
On Sun, Jun 14, 2020 at 4:27 PM Marton Balint wrote:
>
> On Tue, 9 Jun 2020, Zivkovic, Milos wrote:
>
> > Hello,
> >
> > I've attached a patch that adds support for extraction of KLV data from
> SDI
> > VANC.
> > Code is enabled with a special *output_klv* option and is otherwise
> unused.
> >
> > This was tested with an off the shelf UDP -> SDI decoder that preserves
> KLV
> > and inserts them in VANC, following the guidelines in MISB ST 0605.
> >
> > I'm working on another patch that will enable *avdevice/decklink_enc* to
> do
> > that as well, and it will also require *output_klv* option to be used.
>
> > From 7371747b86dd3de4889c28d8b6536e8aff08be2b Mon Sep 17 00:00:00 2001
> > From: Milos Zivkovic
> > Date: Mon, 8 Jun 2020 11:56:37 +0200
> > Subject: [PATCH] avdevice/decklink_dec: extracting and outputing klv
> from vanc
> >
> > Signed-off-by: Milos Zivkovic
> > ---
> > libavdevice/decklink_common.h | 2 +
> > libavdevice/decklink_common_c.h | 1 +
> > libavdevice/decklink_dec.cpp| 160
> +++-
> > libavdevice/decklink_dec_c.c| 1 +
> > 4 files changed, 163 insertions(+), 1 deletion(-)
>
> Missing docs for the new option.
>
> >
> > diff --git a/libavdevice/decklink_common.h
> b/libavdevice/decklink_common.h
> > index 27ce6a8..2d57b85 100644
> > --- a/libavdevice/decklink_common.h
> > +++ b/libavdevice/decklink_common.h
> > @@ -120,12 +120,14 @@ struct decklink_ctx {
> > unsigned int dropped;
> > AVStream *audio_st;
> > AVStream *video_st;
> > +AVStream *klv_st;
> > AVStream *teletext_st;
> > uint16_t cdp_sequence_num;
> >
> > /* Options */
> > int list_devices;
> > int list_formats;
> > +int output_klv;
> > int64_t teletext_lines;
> > double preroll;
> > int duplex_mode;
> > diff --git a/libavdevice/decklink_common_c.h
> b/libavdevice/decklink_common_c.h
> > index 88b1eae..953aebe 100644
> > --- a/libavdevice/decklink_common_c.h
> > +++ b/libavdevice/decklink_common_c.h
> > @@ -40,6 +40,7 @@ struct decklink_cctx {
> > /* Options */
> > int list_devices;
> > int list_formats;
> > +int output_klv;
> > int64_t teletext_lines;
> > double preroll;
> > int audio_channels;
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index 82106aa..7b39dd5 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -22,6 +22,8 @@
> > */
> >
> > #include
> > +#include
> > +#include
>
> Avoid these if possible. Yes, this is C++ code but only because the
> decklink
> API requires it. Also it gives me a compile error, and I am not familiar
> enough
> with C++ to figure out what is going on:
>
> cc1plus: warning: command line option ‘-Wdeclaration-after-statement’ is
> valid for C/ObjC but not for C++
> cc1plus: warning: command line option ‘-Wmissing-prototypes’ is valid fo
[FFmpeg-devel] [PATCH 1/2] avformat/hlsenc: check fragment size plus start_pos large than hls_segment_size
if vs->size + vs->start_pos > hls->max_seg_size, should split segment.
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 71fa3db060..ca2e1bb4a8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2392,7 +2392,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
&& (hls->flags & HLS_TEMP_FILE);
}
-if ((hls->max_seg_size > 0 && (vs->size >= hls->max_seg_size)) ||
!byterange_mode) {
+if ((hls->max_seg_size > 0 && (vs->size + vs->start_pos >=
hls->max_seg_size)) || !byterange_mode) {
AVDictionary *options = NULL;
char *filename = NULL;
if (hls->key_info_file || hls->encrypt) {
@@ -2487,14 +2487,15 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (hls->flags & HLS_SINGLE_FILE) {
vs->start_pos += vs->size;
} else if (hls->max_seg_size > 0) {
-vs->start_pos = new_start_pos;
-if (vs->size >= hls->max_seg_size) {
+if (vs->size + vs->start_pos >= hls->max_seg_size) {
vs->sequence++;
sls_flag_file_rename(hls, vs, old_filename);
ret = hls_start(s, vs);
vs->start_pos = 0;
/* When split segment by byte, the duration is short than
hls_time,
* so it is not enough one segment duration as hls_time, */
+} else {
+vs->start_pos = new_start_pos;
}
} else {
vs->start_pos = new_start_pos;
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] tests/fate/hlsenc: add testcase of ac3 surround sound input in hlsenc
add probeaudiostream for get audio stream's codec_name,codec_time_base,
sample_fmt,channels and channel_layout.
Signed-off-by: Steven Liu
---
tests/fate-run.sh | 4
tests/fate/hlsenc.mak | 14 +-
2 files changed, 17 insertions(+), 1 deletion(-)
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 002944b010..414ac6f825 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -89,6 +89,10 @@ probefmt(){
run ffprobe${PROGSUF}${EXECSUF} -show_entries format=format_name
-print_format default=nw=1:nk=1 -v 0 "$@"
}
+probeaudiostream(){
+run ffprobe${PROGSUF}${EXECSUF} -show_entries
stream=codec_name,codec_time_base,sample_fmt,channels,channel_layout -v 0 "$@"
+}
+
probetags(){
run ffprobe${PROGSUF}${EXECSUF} -show_entries format_tags -v 0 "$@"
}
diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak
index 43f93c8c5b..c56a541f43 100644
--- a/tests/fate/hlsenc.mak
+++ b/tests/fate/hlsenc.mak
@@ -97,5 +97,17 @@ FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER
MPEGTS_DEMUXER AEVALSRC_FILT
fate-hls-fmp4: tests/data/hls_segment_type_fmp4.m3u8
fate-hls-fmp4: CMD = framecrc -flags +bitexact -i
$(TARGET_PATH)/tests/data/hls_fmp4.m3u8 -vf setpts=N*23
-FATE_FFMPEG += $(FATE_HLSENC-yes)
+tests/data/hls_fmp4_ac3.m3u8: TAG = GEN
+tests/data/hls_fmp4_ac3.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
+ $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
+ -stream_loop 4 -i $(SAMPLES)/ac3/monsters_inc_5.1_448_small.ac3 -c copy
-map 0 \
+ -hls_segment_type fmp4 -hls_fmp4_init_filename now.mp4 -hls_list_size 0
\
+ -hls_time 2 -hls_segment_filename
"$(TARGET_PATH)/tests/data/hls_fmp4_%d.m4s" \
+ $(TARGET_PATH)/tests/data/hls_fmp4_ac3.m3u8 2>/dev/null
+
+FATE_HLSENC-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3
+fate-hls-fmp4_ac3: tests/data/hls_fmp4_ac3.m3u8
+fate-hls-fmp4_ac3: CMD = probeaudiostream $(TARGET_PATH)/tests/data/now.mp4
+
+FATE_SAMPLES_FFMPEG += $(FATE_HLSENC-yes)
fate-hlsenc: $(FATE_HLSENC-yes)
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] tests/fate/hlsenc: add testcase of ac3 surround sound input in hlsenc
add probeaudiostream for get audio stream's codec_name,codec_time_base,
sample_fmt,channels and channel_layout.
Signed-off-by: Steven Liu
---
tests/fate-run.sh | 4
tests/fate/hlsenc.mak | 14 +-
tests/ref/fate/hls-fmp4_ac3 | 9 +
3 files changed, 26 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/hls-fmp4_ac3
diff --git a/tests/fate-run.sh b/tests/fate-run.sh
index 002944b010..414ac6f825 100755
--- a/tests/fate-run.sh
+++ b/tests/fate-run.sh
@@ -89,6 +89,10 @@ probefmt(){
run ffprobe${PROGSUF}${EXECSUF} -show_entries format=format_name
-print_format default=nw=1:nk=1 -v 0 "$@"
}
+probeaudiostream(){
+run ffprobe${PROGSUF}${EXECSUF} -show_entries
stream=codec_name,codec_time_base,sample_fmt,channels,channel_layout -v 0 "$@"
+}
+
probetags(){
run ffprobe${PROGSUF}${EXECSUF} -show_entries format_tags -v 0 "$@"
}
diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak
index 43f93c8c5b..c56a541f43 100644
--- a/tests/fate/hlsenc.mak
+++ b/tests/fate/hlsenc.mak
@@ -97,5 +97,17 @@ FATE_HLSENC-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER
MPEGTS_DEMUXER AEVALSRC_FILT
fate-hls-fmp4: tests/data/hls_segment_type_fmp4.m3u8
fate-hls-fmp4: CMD = framecrc -flags +bitexact -i
$(TARGET_PATH)/tests/data/hls_fmp4.m3u8 -vf setpts=N*23
-FATE_FFMPEG += $(FATE_HLSENC-yes)
+tests/data/hls_fmp4_ac3.m3u8: TAG = GEN
+tests/data/hls_fmp4_ac3.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data
+ $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \
+ -stream_loop 4 -i $(SAMPLES)/ac3/monsters_inc_5.1_448_small.ac3 -c copy
-map 0 \
+ -hls_segment_type fmp4 -hls_fmp4_init_filename now.mp4 -hls_list_size 0
\
+ -hls_time 2 -hls_segment_filename
"$(TARGET_PATH)/tests/data/hls_fmp4_%d.m4s" \
+ $(TARGET_PATH)/tests/data/hls_fmp4_ac3.m3u8 2>/dev/null
+
+FATE_HLSENC-$(call ALLYES, HLS_DEMUXER EAC3_DEMUXER) += fate-hls-fmp4_ac3
+fate-hls-fmp4_ac3: tests/data/hls_fmp4_ac3.m3u8
+fate-hls-fmp4_ac3: CMD = probeaudiostream $(TARGET_PATH)/tests/data/now.mp4
+
+FATE_SAMPLES_FFMPEG += $(FATE_HLSENC-yes)
fate-hlsenc: $(FATE_HLSENC-yes)
diff --git a/tests/ref/fate/hls-fmp4_ac3 b/tests/ref/fate/hls-fmp4_ac3
new file mode 100644
index 00..1f45172a0e
--- /dev/null
+++ b/tests/ref/fate/hls-fmp4_ac3
@@ -0,0 +1,9 @@
+[STREAM]
+codec_name=ac3
+codec_time_base=1/48000
+sample_fmt=fltp
+channels=6
+channel_layout=5.1(side)
+[SIDE_DATA]
+[/SIDE_DATA]
+[/STREAM]
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/2] avformat/hlsenc: check fragment size plus start_pos large than hls_segment_size
if vs->size + vs->start_pos > hls->max_seg_size, should split segment.
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 71fa3db060..ca2e1bb4a8 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2392,7 +2392,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
&& (hls->flags & HLS_TEMP_FILE);
}
-if ((hls->max_seg_size > 0 && (vs->size >= hls->max_seg_size)) ||
!byterange_mode) {
+if ((hls->max_seg_size > 0 && (vs->size + vs->start_pos >=
hls->max_seg_size)) || !byterange_mode) {
AVDictionary *options = NULL;
char *filename = NULL;
if (hls->key_info_file || hls->encrypt) {
@@ -2487,14 +2487,15 @@ static int hls_write_packet(AVFormatContext *s,
AVPacket *pkt)
if (hls->flags & HLS_SINGLE_FILE) {
vs->start_pos += vs->size;
} else if (hls->max_seg_size > 0) {
-vs->start_pos = new_start_pos;
-if (vs->size >= hls->max_seg_size) {
+if (vs->size + vs->start_pos >= hls->max_seg_size) {
vs->sequence++;
sls_flag_file_rename(hls, vs, old_filename);
ret = hls_start(s, vs);
vs->start_pos = 0;
/* When split segment by byte, the duration is short than
hls_time,
* so it is not enough one segment duration as hls_time, */
+} else {
+vs->start_pos = new_start_pos;
}
} else {
vs->start_pos = new_start_pos;
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [IMPORTANT] FOSDEM meeting
Am 10.06.20 um 19:16 schrieb Thilo Borgmann: > Hi, > >> As a reminder, this week-end is the FOSDEM, in Brussels. >> >> As promised, we will do a FFmpeg developer meeting, where we will vote on >> the decisions taken during VDD. >> Notably, re-elect the committees, and the voted will now be done by the new >> electors. >> >> This will take place on Saturday (Sunday is the dev room), probably at 14:00 >> if we can. >> It will be joinable through some VideoConf tool. >> >> If you cannot go to FOSDEM for money reasons, please contact me. Both FFmpeg >> and VideoLAN can sponsor your venue to Brussels! >> >> Hoping on seeing you in BRU. > > having settled (hopefully) on an implementation that complies to the voting > scheme we agreed upon during the last developer meeting I just created a test > vote as a final check. > > During the meeting we agreed upon some requirements for selecting the General > Assembly. A corresponding preliminary implementation from Josh has been used > to identify 49 members of the General Assemby: > > https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2020-April/261323.html > > If your name appears in the output of the script you should have received an > email form ffmpeg.vot...@gmail.com announcing the test vote. > > If this test succeeds, the votes announced during the meeting can finally > happen soon. The vote just closed with 31/49 ballots received and the the bike shed will be painted Blue / Purple. Everything worked as expected so we are good to go for the actual votes. Stay tuned. All ballots are online for anyone who wants to do a reprodution of the vote. If you need assistance to do so, feel free to send me a mail. Thanks for participation, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] lavdevice: Add AudioToolbox output device.
Am 12.06.20 um 17:55 schrieb Thilo Borgmann: > Am 08.06.20 um 21:45 schrieb Thilo Borgmann: >> $subject, v3. > > If there are no more comments I'll push this next week. Pushed, thanks! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 01/26] avformat/matroskadec: Move AVBufferRef instead of copying, fix memleak
Andreas Rheinhardt: > EBML binary elements are already made reference-counted when read; > so when populating the AVStream.attached_pic, one does not need to > allocate a new buffer for the data; instead the current code just > creates a new reference to the underlying AVBuffer. But this can be > improved even further: Just move the already existing reference. > > This also fixes a memleak that happens upon error because > matroska_read_close has not been called in this scenario. > > Signed-off-by: Andreas Rheinhardt > --- > This fixes one of the memleaks that I found during the work on my patchset > [1] that intended to automatically call a demuxer's read_close function > if reading the header fails. Several other of the patches of this > patchset also fix such memleaks. > > I intend to apply this patchset soon so that 4.3 can finally be > released. > > [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-March/258831.html > > libavformat/matroskadec.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c > index bb3a126c29..b1da40983f 100644 > --- a/libavformat/matroskadec.c > +++ b/libavformat/matroskadec.c > @@ -2938,9 +2938,8 @@ static int matroska_read_header(AVFormatContext *s) > st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO; > > av_init_packet(pkt); > -pkt->buf = av_buffer_ref(attachments[j].bin.buf); > -if (!pkt->buf) > -return AVERROR(ENOMEM); > +pkt->buf = attachments[j].bin.buf; > +attachments[j].bin.buf = NULL; > pkt->data = attachments[j].bin.data; > pkt->size = attachments[j].bin.size; > pkt->stream_index = st->index; > Will apply 1-26. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/hevcdec: create AVFrame side data from HEVC timecodes like H.264
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/hevcdec.c | 44
1 file changed, 44 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index c9e28f5..39abbb9 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2808,6 +2808,50 @@ static int set_side_data(HEVCContext *s)
}
s->sei.unregistered.nb_buf_ref = 0;
+if (s->sei.timecode.present) {
+uint32_t tc = 0;
+uint32_t *tc_sd;
+AVFrameSideData *tcside = av_frame_new_side_data(out,
AV_FRAME_DATA_S12M_TIMECODE,
+ sizeof(uint32_t) * 4);
+if (!tcside)
+return AVERROR(ENOMEM);
+
+tc_sd = (uint32_t*)tcside->data;
+tc_sd[0] = s->sei.timecode.num_clock_ts;
+
+for (int i = 0; i < tc_sd[0]; i++) {
+uint32_t frames;
+
+/* For SMPTE 12-M timecodes, frame count is a special case if > 30
FPS.
+ See SMPTE ST 12-1:2014 Sec 12.1 for more info. */
+if (av_cmp_q(s->avctx->framerate, (AVRational) {30, 1}) == 1) {
+frames = s->sei.timecode.n_frames[i] / 2;
+if (s->sei.timecode.n_frames[i] % 2 == 1) {
+if (av_cmp_q(s->avctx->framerate, (AVRational) {50, 1}) ==
0)
+tc |= (1 << 7);
+else
+tc |= (1 << 23);
+}
+} else {
+frames = s->sei.timecode.n_frames[i];
+}
+
+tc |= s->sei.timecode.cnt_dropped_flag[i] << 30;
+tc |= (frames / 10) << 28;
+tc |= (frames % 10) << 24;
+tc |= (s->sei.timecode.seconds_value[i] / 10) << 20;
+tc |= (s->sei.timecode.seconds_value[i] % 10) << 16;
+tc |= (s->sei.timecode.minutes_value[i] / 10) << 12;
+tc |= (s->sei.timecode.minutes_value[i] % 10) << 8;
+tc |= (s->sei.timecode.hours_value[i] / 10) << 4;
+tc |= (s->sei.timecode.hours_value[i] % 10);
+
+tc_sd[i + 1] = tc;
+}
+
+s->sei.timecode.num_clock_ts = 0;
+}
+
return 0;
}
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/hevc_sei: support HEVC timecode decode
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/hevc_sei.c | 49 +
libavcodec/hevc_sei.h | 21 +
2 files changed, 70 insertions(+)
diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index 1736891..6d484b5 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -306,6 +306,53 @@ static int
decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer *s, Ge
return 0;
}
+static int decode_nal_sei_timecode(HEVCSEITimeCode *s, GetBitContext *gb)
+{
+s->num_clock_ts = get_bits(gb, 2) & 3;
+
+for (int i = 0; i < s->num_clock_ts; i++) {
+s->clock_timestamp_flag[i] = get_bits(gb, 1);
+
+if (s->clock_timestamp_flag[i]) {
+s->units_field_based_flag[i] = get_bits(gb, 1);
+s->counting_type[i] = get_bits(gb, 5);
+s->full_timestamp_flag[i]= get_bits(gb, 1);
+s->discontinuity_flag[i] = get_bits(gb, 1);
+s->cnt_dropped_flag[i] = get_bits(gb, 1);
+
+s->n_frames[i] = get_bits(gb, 9);
+
+if (s->full_timestamp_flag[i]) {
+s->seconds_value[i] = av_clip(get_bits(gb, 6), 0, 59);
+s->minutes_value[i] = av_clip(get_bits(gb, 6), 0, 59);
+s->hours_value[i]= av_clip(get_bits(gb, 6), 0, 59);
+} else {
+s->seconds_flag[i] = get_bits(gb, 1);
+if (s->seconds_flag[i]) {
+s->seconds_value[i] = av_clip(get_bits(gb, 6), 0, 59);
+s->minutes_flag[i] = get_bits(gb, 1);
+if (s->minutes_flag[i]) {
+s->minutes_value[i] = av_clip(get_bits(gb, 6), 0, 59);
+s->hours_flag[i] = get_bits(gb, 1);
+if (s->hours_flag[i]) {
+s->hours_value[i] = av_clip(get_bits(gb, 6), 0,
59);
+}
+}
+}
+}
+
+s->time_offset_length[i] = get_bits(gb, 5);
+if (s->time_offset_length[i] > 0) {
+s->time_offset_value[i] = get_bits(gb,
s->time_offset_length[i]);
+}
+}
+}
+
+s->present = 1;
+return 0;
+}
+
+
static int decode_nal_sei_prefix(GetBitContext *gb, void *logctx, HEVCSEI *s,
const HEVCParamSets *ps, int type, int size)
{
@@ -330,6 +377,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb, void
*logctx, HEVCSEI *s,
return decode_nal_sei_user_data_unregistered(&s->unregistered, gb,
size);
case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
return decode_nal_sei_alternative_transfer(&s->alternative_transfer,
gb);
+case HEVC_SEI_TYPE_TIME_CODE:
+return decode_nal_sei_timecode(&s->timecode, gb);
default:
av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
skip_bits_long(gb, 8 * size);
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index 3618d16..5ee7a47 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -115,6 +115,26 @@ typedef struct HEVCSEIAlternativeTransfer {
int preferred_transfer_characteristics;
} HEVCSEIAlternativeTransfer;
+typedef struct HEVCSEITimeCode {
+int present;
+uint8_t num_clock_ts;
+uint8_t clock_timestamp_flag[3];
+uint8_t units_field_based_flag[3];
+uint8_t counting_type[3];
+uint8_t full_timestamp_flag[3];
+uint8_t discontinuity_flag[3];
+uint8_t cnt_dropped_flag[3];
+uint16_t n_frames[3];
+uint8_t seconds_value[3];
+uint8_t minutes_value[3];
+uint8_t hours_value[3];
+uint8_t seconds_flag[3];
+uint8_t minutes_flag[3];
+uint8_t hours_flag[3];
+uint8_t time_offset_length[3];
+int32_t time_offset_value[3];
+} HEVCSEITimeCode;
+
typedef struct HEVCSEI {
HEVCSEIPictureHash picture_hash;
HEVCSEIFramePacking frame_packing;
@@ -126,6 +146,7 @@ typedef struct HEVCSEI {
HEVCSEIContentLight content_light;
int active_seq_parameter_set_id;
HEVCSEIAlternativeTransfer alternative_transfer;
+HEVCSEITimeCode timecode;
} HEVCSEI;
struct HEVCParamSets;
--
1.8.3.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 3/3] fate: add yuv420p10 and yuv422p10 tests for overlay filter
On Fri, Jun 05, 2020 at 09:58:02PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > tests/fate/filter-video.mak | 8 > tests/filtergraphs/overlay_yuv420p10| 5 + > tests/filtergraphs/overlay_yuv422p10| 5 + > tests/ref/fate/filter-overlay_yuv420p10 | 8 > tests/ref/fate/filter-overlay_yuv422p10 | 8 > 5 files changed, 34 insertions(+) > create mode 100644 tests/filtergraphs/overlay_yuv420p10 > create mode 100644 tests/filtergraphs/overlay_yuv422p10 > create mode 100644 tests/ref/fate/filter-overlay_yuv420p10 > create mode 100644 tests/ref/fate/filter-overlay_yuv422p10 > > diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak > index cfeb53e..def6079 100644 > --- a/tests/fate/filter-video.mak > +++ b/tests/fate/filter-video.mak > @@ -223,6 +223,10 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER > SCALE_FILTER PAD_FILTER OVERLAY_F > fate-filter-overlay_yuv420: tests/data/filtergraphs/overlay_yuv420 > fate-filter-overlay_yuv420: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420 > > +FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER > OVERLAY_FILTER) += fate-filter-overlay_yuv420p10 > +fate-filter-overlay_yuv420p10: tests/data/filtergraphs/overlay_yuv420p10 > +fate-filter-overlay_yuv420p10: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv420p10 -frames:v 3 > + > FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER > OVERLAY_FILTER) += fate-filter-overlay_nv12 > fate-filter-overlay_nv12: tests/data/filtergraphs/overlay_nv12 > fate-filter-overlay_nv12: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_nv12 > @@ -237,6 +241,10 @@ FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER > SCALE_FILTER PAD_FILTER OVERLAY_F > fate-filter-overlay_yuv422: tests/data/filtergraphs/overlay_yuv422 > fate-filter-overlay_yuv422: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv422 > > +FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER > OVERLAY_FILTER) += fate-filter-overlay_yuv422p10 > +fate-filter-overlay_yuv422p10: tests/data/filtergraphs/overlay_yuv422p10 > +fate-filter-overlay_yuv422p10: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script > $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv422p10 -frames:v 3 > + > FATE_FILTER_VSYNTH-$(call ALLYES, SPLIT_FILTER SCALE_FILTER PAD_FILTER > OVERLAY_FILTER) += fate-filter-overlay_yuv444 > fate-filter-overlay_yuv444: tests/data/filtergraphs/overlay_yuv444 > fate-filter-overlay_yuv444: CMD = framecrc -c:v pgmyuv -i $(SRC) > -filter_complex_script $(TARGET_PATH)/tests/data/filtergraphs/overlay_yuv444 > diff --git a/tests/filtergraphs/overlay_yuv420p10 > b/tests/filtergraphs/overlay_yuv420p10 > new file mode 100644 > index 000..7cc9dcb > --- /dev/null > +++ b/tests/filtergraphs/overlay_yuv420p10 > @@ -0,0 +1,5 @@ > +sws_flags=+accurate_rnd+bitexact; > +split [main][over]; > +[over] scale=88:72, pad=96:80:4:4 [overf]; > +[main] format=yuv420p10 [mainf]; > +[mainf][overf] overlay=240:16:format=yuv420p10 > diff --git a/tests/filtergraphs/overlay_yuv422p10 > b/tests/filtergraphs/overlay_yuv422p10 > new file mode 100644 > index 000..459d140 > --- /dev/null > +++ b/tests/filtergraphs/overlay_yuv422p10 > @@ -0,0 +1,5 @@ > +sws_flags=+accurate_rnd+bitexact; > +split [main][over]; > +[over] scale=88:72, pad=96:80:4:4 [overf]; > +[main] format=yuv420p10 [mainf]; > +[mainf][overf] overlay=240:16:format=yuv422p10 > diff --git a/tests/ref/fate/filter-overlay_yuv420p10 > b/tests/ref/fate/filter-overlay_yuv420p10 > new file mode 100644 > index 000..cc90fb5 > --- /dev/null > +++ b/tests/ref/fate/filter-overlay_yuv420p10 > @@ -0,0 +1,8 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 352x288 > +#sar 0: 0/1 > +0, 0, 0,1, 304128, 0x85348342 > +0, 1, 1,1, 304128, 0x2871d7dc > +0, 2, 2,1, 304128, 0x75819b2a > diff --git a/tests/ref/fate/filter-overlay_yuv422p10 > b/tests/ref/fate/filter-overlay_yuv422p10 > new file mode 100644 > index 000..a601931 > --- /dev/null > +++ b/tests/ref/fate/filter-overlay_yuv422p10 > @@ -0,0 +1,8 @@ > +#tb 0: 1/25 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 352x288 > +#sar 0: 0/1 > +0, 0, 0,1, 608256, 0x8e3fe595 > +0, 1, 1,1, 608256, 0x38512396 > +0, 2, 2,1, 608256, 0x0195cb34 > -- > 1.8.3.1 > ping -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Re: [FFmpeg-devel] [PATCH] avcodec/libx265: Fix integer overflow in computation of max and avg bitrate
On Mon, Jun 08, 2020 at 11:02:38PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/libx265.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c > index f560d7f62f..686c205b6b 100644 > --- a/libavcodec/libx265.c > +++ b/libavcodec/libx265.c > @@ -310,8 +310,8 @@ static av_cold int libx265_encode_init(AVCodecContext > *avctx) > if (!cpb_props) > return AVERROR(ENOMEM); > cpb_props->buffer_size = ctx->params->rc.vbvBufferSize * 1000; > -cpb_props->max_bitrate = ctx->params->rc.vbvMaxBitrate * 1000; > -cpb_props->avg_bitrate = ctx->params->rc.bitrate * 1000; > +cpb_props->max_bitrate = ctx->params->rc.vbvMaxBitrate * 1000LL; > +cpb_props->avg_bitrate = ctx->params->rc.bitrate * 1000LL; > > if (!(avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)) > ctx->params->bRepeatHeaders = 1; > -- > 2.21.0 > ping for review. -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] Kicked out Paul from IRC
On Mon, Jun 15, 2020 at 10:46:31AM +0200, Tomas Härdin wrote: > sön 2020-06-14 klockan 20:37 +0200 skrev Michael Niedermayer: > > Also iam interrested in designing a modern audio codec for fun once (if i > > find > > the time), and if by then sonic.c is still around i might just put the code > > in > > there. Just because that would be the obvious place to put such code in. > > You might want to talk to Xiph and the IETF, and some of the usual > suspects (jmspeex, gmaxwell etc). Lots of lessons were learned while > developing Opus, plenty of ideas to explore. yes, that would make sense, but first i need to have the time for this whole idea ... thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/tiff: Check stride for dng
On Mon, Jun 15, 2020 at 09:08:21AM +0800, lance.lmw...@gmail.com wrote: > On Mon, Jun 15, 2020 at 12:10:14AM +0200, Michael Niedermayer wrote: > > Fixes: assertion failure > > Fixes: > > 23422/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-5746026064642048 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/tiff.c | 4 > > 1 file changed, 4 insertions(+) > > > > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c > > index 010943c38c..26a936074f 100644 > > --- a/libavcodec/tiff.c > > +++ b/libavcodec/tiff.c > > @@ -679,6 +679,10 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame > > *p, uint8_t *dst, int strid > > return 0; > > } > > > > +if (is_dng && stride == 0) > > +return AVERROR_INVALIDDATA; > > + > > + > > why add two blank line here? that was unintended will apply without the extra blank line, thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_showpalette: Don't pretend disp_palette can fail
It can't fail, yet it returns an int and other code checks whether it
failed; yet if it did fail, an AVFrame would leak. One could of course
add an av_frame_free for this (that compilers could optimize away), yet
it is easier to simply stop pretending that disp_palette could fail.
Signed-off-by: Andreas Rheinhardt
---
libavfilter/vf_showpalette.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_showpalette.c b/libavfilter/vf_showpalette.c
index 5b0772bc0b..f715d6bc2c 100644
--- a/libavfilter/vf_showpalette.c
+++ b/libavfilter/vf_showpalette.c
@@ -76,7 +76,7 @@ static int config_output(AVFilterLink *outlink)
return 0;
}
-static int disp_palette(AVFrame *out, const AVFrame *in, int size)
+static void disp_palette(AVFrame *out, const AVFrame *in, int size)
{
int x, y, i, j;
uint32_t *dst = (uint32_t *)out->data[0];
@@ -88,12 +88,10 @@ static int disp_palette(AVFrame *out, const AVFrame *in,
int size)
for (j = 0; j < size; j++)
for (i = 0; i < size; i++)
dst[(y*dst_linesize + x) * size + j*dst_linesize + i] =
pal[y*16 + x];
-return 0;
}
static int filter_frame(AVFilterLink *inlink, AVFrame *in)
{
-int ret;
AVFrame *out;
AVFilterContext *ctx = inlink->dst;
const ShowPaletteContext *s = ctx->priv;
@@ -105,9 +103,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
return AVERROR(ENOMEM);
}
av_frame_copy_props(out, in);
-ret = disp_palette(out, in, s->size);
+disp_palette(out, in, s->size);
av_frame_free(&in);
-return ret < 0 ? ret : ff_filter_frame(outlink, out);
+return ff_filter_frame(outlink, out);
}
static const AVFilterPad showpalette_inputs[] = {
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: extracting and outputing klv from vanc
On Mon, 15 Jun 2020, Zivkovic, Milos wrote: Hello, I appreciate the comments. Missing docs for the new option. Does this refer to .texi files? I'll update the docs. Yes. Avoid these if possible. Yes, this is C++ code but only because the decklink API requires it. Also it gives me a compile error, and I am not familiar enough with C++ to figure out what is going on It makes everything much easier (just like using std::atomic for ref counting does). It also doesn't change the needed version of C++ since std::atomic is available in C++11 and above. However, that error message is concerning and I'd like to fix it. Which compiler is it? GCC 7.5.0, full compiler log is attached. You only use this to avoid calling ->Release() right? If that is the case, then I'd avoid this as well, I am not sure about the compiler support of such templating. Yes, it's used to avoid manually releasing COM pointers which can become quite a hassle especially if multiple COM objects are involved. Error handling is simplified as well since there's no need to worry which COM object(s) should be released. As far as compiler support goes, this is the most basic C++ template that's supported by basically every C++ compiler in the last 20+ years. I'm willing to remove it if you still feel strongly that it's unnecessary. Yes please. This interface is only available from DeckLink SDK 10.10 or so, but you have not bumped the version requirement in configure. Wasn't sure which files should be edited for this. I'll get the exact SDK version that introduces it and bump it in configure. Is the sorting really needed? Aren't they supposed to be sorted in the VANC? Well, they should be, but it's not guaranteed so this is just a safety net. If it was guaranteed there would be no need for PSC fields. Maybe avoid the error message and increase ctx->dropped like other similar code does it. Will do. Mixed code and declaration. I'll move that block below the declaration. Lose the error message for ENOMEM. I was just following what the other code that adds streams does. AV_OPT_TYPE_BOOL I'll change that asap. Thanks, Milos Thanks, Martong++ -I. -I./ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DZLIB_CONST -std=c11 -fomit-frame-pointer -pthread -I/usr/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/freetype2 -D_REENTRANT -DOPENSSL_LOAD_CONF -pthread -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng12 -DOPENSSL_LOAD_CONF -I/usr//usr/include -I/usr//usr/include/srt-DOPENSSL_LOAD_CONF -I/usr/include/alsa-g -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -Wno-char-subscripts -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -D_REENTRANT -I/usr/include/SDL2 -D__STDC_CONSTANT_MACROS -std=c++11 -c -o libavdevice/decklink_dec.o libavdevice/decklink_dec.cpp cc1plus: warning: command line option â-Wdeclaration-after-statementâ is valid for C/ObjC but not for C++ cc1plus: warning: command line option â-Wmissing-prototypesâ is valid for C/ObjC but not for C++ cc1plus: warning: command line option â-Wno-pointer-to-int-castâ is valid for C/ObjC but not for C++ cc1plus: warning: command line option â-Wstrict-prototypesâ is valid for C/ObjC but not for C++ cc1plus: warning: command line option â-Wno-pointer-signâ is valid for C/ObjC but not for C++ cc1plus: warning: â-Werror=â argument â-Werror=implicit-function-declarationâ is not valid for C++ cc1plus: warning: â-Werror=â argument â-Werror=missing-prototypesâ is not valid for C++ cc1plus: warning: command line option â-std=c11â is valid for C/ObjC but not for C++ In file included from /usr/include/c++/7/ext/new_allocator.h:33:0, from /usr/include/c++/7/x86_64-suse-linux/bits/c++allocator.h:33, from /usr/include/c++/7/bits/allocator.h:46, from /usr/include/c++/7/vector:61, from libavdevice/decklink_dec.cpp:25: ./new:1:1: error: expected unqualified-id before â[â token [PACKET] ^ In file included from /usr/include/c++/7/bits/allocator.h:46:0, from /usr/
Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfdec: Error out on duplicated utf16 strings
On Mon, 15 Jun 2020, Tomas Härdin wrote: sön 2020-06-14 klockan 20:19 +0200 skrev Marton Balint: On Sun, 14 Jun 2020, Michael Niedermayer wrote: > Alternatively we could free the already allocated element Yeah, I kind of prefer that, we potentially allow non-string values to occur multiple times, so I'd say let's allow string values as well, even if that is not common. (I am not sure if it is strictly invalid or just uncommon). Are there files in the wild that do this? Being stricter is often the better option when it comes to MXF. A muxer that outputs metadata more than once might be doing something wrong. I am not sure, but I wanted to be safe rather than sorry, because it is not unusual in MXF to repeat certain metadata in the footer partition which is already present in the header, and I did not want to take the risk of rejecting a valid file. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: extracting and outputing klv from vanc
I'll submit the patch with the proposed changes once that build issue is resolved. I'm not having any build issues on multiple compilers, and there's one really weird error in the log that you shared. In file included from /usr/include/c++/7/ext/new_allocator.h:33:0, > from > /usr/include/c++/7/x86_64-suse-linux/bits/c++allocator.h:33, > from /usr/include/c++/7/bits/allocator.h:46, > from /usr/include/c++/7/vector:61, > from libavdevice/decklink_dec.cpp:25: > ./new:1:1: error: expected unqualified-id before ‘[’ token > [PACKET] > ^ > I'd say that basically everything goes to hell due to that error and invalid token [PACKET] located in /usr/include/c++/7/new, on the first line. Do you mind checking the file and confirming that it actually contains it? Those kinds of tokens shouldn't really ever be in the standard headers. I created a very simple sample on Compiler Explorer (with GCC 7.5) where token [PACKET] is above the includes. Basically everything after it is treated as an error, just like in the shared log. You can check it out here: https://godbolt.org/z/zTJn_9 Thanks, Milos On Mon, Jun 15, 2020 at 9:20 PM Marton Balint wrote: > > > On Mon, 15 Jun 2020, Zivkovic, Milos wrote: > > > Hello, > > > > I appreciate the comments. > > > > Missing docs for the new option. > >> > > > > Does this refer to .texi files? I'll update the docs. > > Yes. > > > > > > >> Avoid these if possible. Yes, this is C++ code but only because the > >> decklink > >> API requires it. Also it gives me a compile error, and I am not familiar > >> enough > >> with C++ to figure out what is going on > >> > > > > It makes everything much easier (just like using std::atomic for ref > > counting does). > > It also doesn't change the needed version of C++ since std::atomic is > > available in C++11 and above. > > However, that error message is concerning and I'd like to fix it. Which > > compiler is it? > > GCC 7.5.0, full compiler log is attached. > > > > > You only use this to avoid calling ->Release() right? If that is the > case, > >> then > >> I'd avoid this as well, I am not sure about the compiler support of such > >> templating. > >> > > > > Yes, it's used to avoid manually releasing COM pointers which can become > > quite a hassle especially if multiple COM objects are involved. > > Error handling is simplified as well since there's no need to worry which > > COM object(s) should be released. > > As far as compiler support goes, this is the most basic C++ template > that's > > supported by basically every C++ compiler in the last 20+ years. > > I'm willing to remove it if you still feel strongly that it's > unnecessary. > > Yes please. > > > > > This interface is only available from DeckLink SDK 10.10 or so, but you > >> have not > >> bumped the version requirement in configure. > >> > > > > Wasn't sure which files should be edited for this. > > I'll get the exact SDK version that introduces it and bump it in > configure. > > > > Is the sorting really needed? Aren't they supposed to be sorted in the > >> VANC? > >> > > > > Well, they should be, but it's not guaranteed so this is just a safety > net. > > If it was guaranteed there would be no need for PSC fields. > > > > Maybe avoid the error message and increase ctx->dropped like other > similar > >> code > >> does it. > >> > > > > Will do. > > > > Mixed code and declaration. > >> > > > > I'll move that block below the declaration. > > > > Lose the error message for ENOMEM. > >> > > > > I was just following what the other code that adds streams does. > > > > AV_OPT_TYPE_BOOL > >> > > > > I'll change that asap. > > > > Thanks, > > Milos > > Thanks, > Marton___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: extracting and outputing klv from vanc
On Mon, 15 Jun 2020, Zivkovic, Milos wrote: I'll submit the patch with the proposed changes once that build issue is resolved. I'm not having any build issues on multiple compilers, and there's one really weird error in the log that you shared. In file included from /usr/include/c++/7/ext/new_allocator.h:33:0, from /usr/include/c++/7/x86_64-suse-linux/bits/c++allocator.h:33, from /usr/include/c++/7/bits/allocator.h:46, from /usr/include/c++/7/vector:61, from libavdevice/decklink_dec.cpp:25: ./new:1:1: error: expected unqualified-id before ‘[’ token [PACKET] ^ I'd say that basically everything goes to hell due to that error and invalid token [PACKET] located in /usr/include/c++/7/new, on the first line. Do you mind checking the file and confirming that it actually contains it? Those kinds of tokens shouldn't really ever be in the standard headers. I created a very simple sample on Compiler Explorer (with GCC 7.5) where token [PACKET] is above the includes. Basically everything after it is treated as an error, just like in the shared log. You can check it out here: https://godbolt.org/z/zTJn_9 Thanks, I found the issue. My local directory had a file called "new" and the compiler included that instead of the proper c++ header file /usr/include/c++/7/new Sorry for the noise. Thanks, Marton Milos On Mon, Jun 15, 2020 at 9:20 PM Marton Balint wrote: On Mon, 15 Jun 2020, Zivkovic, Milos wrote: > Hello, > > I appreciate the comments. > > Missing docs for the new option. >> > > Does this refer to .texi files? I'll update the docs. Yes. > > >> Avoid these if possible. Yes, this is C++ code but only because the >> decklink >> API requires it. Also it gives me a compile error, and I am not familiar >> enough >> with C++ to figure out what is going on >> > > It makes everything much easier (just like using std::atomic for ref > counting does). > It also doesn't change the needed version of C++ since std::atomic is > available in C++11 and above. > However, that error message is concerning and I'd like to fix it. Which > compiler is it? GCC 7.5.0, full compiler log is attached. > > You only use this to avoid calling ->Release() right? If that is the case, >> then >> I'd avoid this as well, I am not sure about the compiler support of such >> templating. >> > > Yes, it's used to avoid manually releasing COM pointers which can become > quite a hassle especially if multiple COM objects are involved. > Error handling is simplified as well since there's no need to worry which > COM object(s) should be released. > As far as compiler support goes, this is the most basic C++ template that's > supported by basically every C++ compiler in the last 20+ years. > I'm willing to remove it if you still feel strongly that it's unnecessary. Yes please. > > This interface is only available from DeckLink SDK 10.10 or so, but you >> have not >> bumped the version requirement in configure. >> > > Wasn't sure which files should be edited for this. > I'll get the exact SDK version that introduces it and bump it in configure. > > Is the sorting really needed? Aren't they supposed to be sorted in the >> VANC? >> > > Well, they should be, but it's not guaranteed so this is just a safety net. > If it was guaranteed there would be no need for PSC fields. > > Maybe avoid the error message and increase ctx->dropped like other similar >> code >> does it. >> > > Will do. > > Mixed code and declaration. >> > > I'll move that block below the declaration. > > Lose the error message for ENOMEM. >> > > I was just following what the other code that adds streams does. > > AV_OPT_TYPE_BOOL >> > > I'll change that asap. > > Thanks, > Milos Thanks, Marton___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avdevice/decklink_dec: extracting and outputing klv from vanc
> > > Thanks, I found the issue. > Glad to hear it. Regards, Milos On Mon, Jun 15, 2020 at 10:58 PM Marton Balint wrote: > > > On Mon, 15 Jun 2020, Zivkovic, Milos wrote: > > > I'll submit the patch with the proposed changes once that build issue is > > resolved. > > > > I'm not having any build issues on multiple compilers, and there's one > > really weird error in the log that you shared. > > > > In file included from /usr/include/c++/7/ext/new_allocator.h:33:0, > >> from > >> /usr/include/c++/7/x86_64-suse-linux/bits/c++allocator.h:33, > >> from /usr/include/c++/7/bits/allocator.h:46, > >> from /usr/include/c++/7/vector:61, > >> from libavdevice/decklink_dec.cpp:25: > >> ./new:1:1: error: expected unqualified-id before ‘[’ token > >> [PACKET] > >> ^ > >> > > > > I'd say that basically everything goes to hell due to that error and > > invalid token [PACKET] located in /usr/include/c++/7/new, on the first > > line. > > Do you mind checking the file and confirming that it actually contains > it? > > Those kinds of tokens shouldn't really ever be in the standard headers. > > > > I created a very simple sample on Compiler Explorer (with GCC 7.5) where > > token [PACKET] is above the includes. > > Basically everything after it is treated as an error, just like in the > > shared log. > > You can check it out here: https://godbolt.org/z/zTJn_9 > > Thanks, I found the issue. My local directory had a file called "new" and > the compiler included that instead of the proper c++ header file > /usr/include/c++/7/new > > Sorry for the noise. > > Thanks, > Marton > > > Milos > > > > > > > > On Mon, Jun 15, 2020 at 9:20 PM Marton Balint wrote: > > > >> > >> > >> On Mon, 15 Jun 2020, Zivkovic, Milos wrote: > >> > >> > Hello, > >> > > >> > I appreciate the comments. > >> > > >> > Missing docs for the new option. > >> >> > >> > > >> > Does this refer to .texi files? I'll update the docs. > >> > >> Yes. > >> > >> > > >> > > >> >> Avoid these if possible. Yes, this is C++ code but only because the > >> >> decklink > >> >> API requires it. Also it gives me a compile error, and I am not > familiar > >> >> enough > >> >> with C++ to figure out what is going on > >> >> > >> > > >> > It makes everything much easier (just like using std::atomic for ref > >> > counting does). > >> > It also doesn't change the needed version of C++ since std::atomic is > >> > available in C++11 and above. > >> > However, that error message is concerning and I'd like to fix it. > Which > >> > compiler is it? > >> > >> GCC 7.5.0, full compiler log is attached. > >> > >> > > >> > You only use this to avoid calling ->Release() right? If that is the > >> case, > >> >> then > >> >> I'd avoid this as well, I am not sure about the compiler support of > such > >> >> templating. > >> >> > >> > > >> > Yes, it's used to avoid manually releasing COM pointers which can > become > >> > quite a hassle especially if multiple COM objects are involved. > >> > Error handling is simplified as well since there's no need to worry > which > >> > COM object(s) should be released. > >> > As far as compiler support goes, this is the most basic C++ template > >> that's > >> > supported by basically every C++ compiler in the last 20+ years. > >> > I'm willing to remove it if you still feel strongly that it's > >> unnecessary. > >> > >> Yes please. > >> > >> > > >> > This interface is only available from DeckLink SDK 10.10 or so, but > you > >> >> have not > >> >> bumped the version requirement in configure. > >> >> > >> > > >> > Wasn't sure which files should be edited for this. > >> > I'll get the exact SDK version that introduces it and bump it in > >> configure. > >> > > >> > Is the sorting really needed? Aren't they supposed to be sorted in the > >> >> VANC? > >> >> > >> > > >> > Well, they should be, but it's not guaranteed so this is just a safety > >> net. > >> > If it was guaranteed there would be no need for PSC fields. > >> > > >> > Maybe avoid the error message and increase ctx->dropped like other > >> similar > >> >> code > >> >> does it. > >> >> > >> > > >> > Will do. > >> > > >> > Mixed code and declaration. > >> >> > >> > > >> > I'll move that block below the declaration. > >> > > >> > Lose the error message for ENOMEM. > >> >> > >> > > >> > I was just following what the other code that adds streams does. > >> > > >> > AV_OPT_TYPE_BOOL > >> >> > >> > > >> > I'll change that asap. > >> > > >> > Thanks, > >> > Milos > >> > >> Thanks, > >> Marton___ > >> ffmpeg-devel mailing list > >> ffmpeg-devel@ffmpeg.org > >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > >> > >> To unsubscribe, visit link above, or email > >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To
Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index
> -Original Message- > From: ffmpeg-devel On Behalf Of Guo > Yejun > Sent: 2020年6月10日 22:01 > To: ffmpeg-devel@ffmpeg.org > Cc: Guo, Yejun > Subject: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index > > it fixed the issue in https://trac.ffmpeg.org/ticket/8716 > > Signed-off-by: Guo Yejun > --- > libavfilter/dnn/dnn_backend_native.c | 6 +- > libavfilter/dnn/dnn_backend_native_layer_conv2d.c | 7 ++- > libavfilter/dnn/dnn_backend_native_layer_conv2d.h | 2 +- > libavfilter/dnn/dnn_backend_native_layer_depth2space.c | 6 +- > libavfilter/dnn/dnn_backend_native_layer_depth2space.h | 2 +- > libavfilter/dnn/dnn_backend_native_layer_mathbinary.c | 12 +++- > libavfilter/dnn/dnn_backend_native_layer_mathbinary.h | 2 +- > libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 6 +- > libavfilter/dnn/dnn_backend_native_layer_mathunary.h | 2 +- > libavfilter/dnn/dnn_backend_native_layer_maximum.c | 6 +- > libavfilter/dnn/dnn_backend_native_layer_maximum.h | 2 +- > libavfilter/dnn/dnn_backend_native_layer_pad.c | 6 +- > libavfilter/dnn/dnn_backend_native_layer_pad.h | 2 +- > libavfilter/dnn/dnn_backend_native_layers.h| 2 +- > 14 files changed, 49 insertions(+), 14 deletions(-) > will push tomorrow if no other comments, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] dnn_backend_native: check operand index
On Wed, Jun 10, 2020 at 10:04 PM Guo Yejun wrote:
>
> it fixed the issue in https://trac.ffmpeg.org/ticket/8716
>
> Signed-off-by: Guo Yejun
> ---
> libavfilter/dnn/dnn_backend_native.c | 6 +-
> libavfilter/dnn/dnn_backend_native_layer_conv2d.c | 7 ++-
> libavfilter/dnn/dnn_backend_native_layer_conv2d.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_depth2space.c | 6 +-
> libavfilter/dnn/dnn_backend_native_layer_depth2space.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_mathbinary.c | 12 +++-
> libavfilter/dnn/dnn_backend_native_layer_mathbinary.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_mathunary.c | 6 +-
> libavfilter/dnn/dnn_backend_native_layer_mathunary.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_maximum.c | 6 +-
> libavfilter/dnn/dnn_backend_native_layer_maximum.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layer_pad.c | 6 +-
> libavfilter/dnn/dnn_backend_native_layer_pad.h | 2 +-
> libavfilter/dnn/dnn_backend_native_layers.h| 2 +-
> 14 files changed, 49 insertions(+), 14 deletions(-)
>
> diff --git a/libavfilter/dnn/dnn_backend_native.c
> b/libavfilter/dnn/dnn_backend_native.c
> index 12695a0..35236fc 100644
> --- a/libavfilter/dnn/dnn_backend_native.c
> +++ b/libavfilter/dnn/dnn_backend_native.c
> @@ -196,7 +196,7 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
> }
>
> network->layers[layer].type = layer_type;
> -parsed_size =
> layer_funcs[layer_type].pf_load(&network->layers[layer], model_file_context,
> file_size);
> +parsed_size =
> layer_funcs[layer_type].pf_load(&network->layers[layer], model_file_context,
> file_size, network->operands_num);
> if (!parsed_size) {
> goto fail;
> }
> @@ -209,6 +209,10 @@ DNNModel *ff_dnn_load_model_native(const char
> *model_filename)
> int32_t operand_index = (int32_t)avio_rl32(model_file_context);
> dnn_size += 4;
>
> +if (operand_index >= network->operands_num) {
> +goto fail;
> +}
> +
I prefer
if (expr)
statements();
without the braces if only a single statement.
> oprd = &network->operands[operand_index];
> name_len = (int32_t)avio_rl32(model_file_context);
> dnn_size += 4;
> diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
> b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
> index 7b29697..c05bb5e 100644
> --- a/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
> +++ b/libavfilter/dnn/dnn_backend_native_layer_conv2d.c
> @@ -23,7 +23,7 @@
>
> #define CLAMP_TO_EDGE(x, w) ((x) < 0 ? 0 : ((x) >= (w) ? (w - 1) : (x)))
>
> -int dnn_load_layer_conv2d(Layer *layer, AVIOContext *model_file_context, int
> file_size)
> +int dnn_load_layer_conv2d(Layer *layer, AVIOContext *model_file_context, int
> file_size, int operands_num)
> {
> ConvolutionalParams *conv_params;
> int kernel_size;
> @@ -80,6 +80,11 @@ int dnn_load_layer_conv2d(Layer *layer, AVIOContext
> *model_file_context, int fil
> layer->input_operand_indexes[0] = (int32_t)avio_rl32(model_file_context);
> layer->output_operand_index = (int32_t)avio_rl32(model_file_context);
> dnn_size += 8;
> +
> +if (layer->input_operand_indexes[0] >= operands_num ||
> layer->output_operand_index >= operands_num) {
> +return 0;
> +}
> +
> return dnn_size;
> }
>
> diff --git a/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
> b/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
> index bf87264..eeb15fd 100644
> --- a/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
> +++ b/libavfilter/dnn/dnn_backend_native_layer_conv2d.h
> @@ -36,7 +36,7 @@ typedef struct ConvolutionalParams{
> float *biases;
> } ConvolutionalParams;
>
> -int dnn_load_layer_conv2d(Layer *layer, AVIOContext *model_file_context, int
> file_size);
> +int dnn_load_layer_conv2d(Layer *layer, AVIOContext *model_file_context, int
> file_size, int operands_num);
> int dnn_execute_layer_conv2d(DnnOperand *operands, const int32_t
> *input_operand_indexes,
> int32_t output_operand_index, const void
> *parameters);
> #endif
> diff --git a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
> b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
> index 7dab19d..324871c 100644
> --- a/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
> +++ b/libavfilter/dnn/dnn_backend_native_layer_depth2space.c
> @@ -27,7 +27,7 @@
> #include "libavutil/avassert.h"
> #include "dnn_backend_native_layer_depth2space.h"
>
> -int dnn_load_layer_depth2space(Layer *layer, AVIOContext
> *model_file_context, int file_size)
> +int dnn_load_layer_depth2space(Layer *layer, AVIOContext
> *model_file_context, int file_size, int operands_num)
> {
> DepthToSpaceParams *params;
> int dnn_size = 0;
> @@ -42,6 +42,10 @@ int dnn_load_layer_depth2
