Re: [FFmpeg-devel] [PATCH 5/5] avformat/matroskaenc: update AV1 support
On 30/07/2018 17:13, James Almer wrote:
On 7/30/2018 2:03 AM, Steve Lhomme wrote:
On 26/07/2018 03:11, James Almer wrote:
Make sure to not write forbidden OBUs to CodecPrivate, and do the same
with
unnecessary OBUs for packets.
Does this include reordering the OBUs ? The first one must be the
Sequence Header OBU. Also it must be the only one of that kind.
No, it doesn't. I can make that change, but why does it matter if it's
the first? Why can't a metadata OBU be before a Seq Header? isobmff
Because if the spec say it's the first and its enforced, the OBU parser
needed at the container level may be simpler. The muxing side can have
more complexity if needed.
doesn't care what's first, only what's in.
I requested that the same constraint be applied in ISOBMFF
https://github.com/AOMediaCodec/av1-isobmff/pull/47#issuecomment-408598719
A parser is currently forced to know how to read OBUs anyway, and it
could just skip any metadata obu before the sequence header.
For that matter, i do agree with
https://github.com/AOMediaCodec/av1-isobmff/issues/7#issuecomment-406257234
and
https://github.com/AOMediaCodec/av1-isobmff/issues/46#issuecomment-406516226
that perhaps av1C should, much like hvcC, avcC and in it's own way also
vpcC, contain a bunch of header bytes listing some basic information
(and therefore the entire thing, sans atom size and fourcc, be included
in CodecPrivate verbatim). Things like profile, level, and maybe number
of OBUs, before the raw OBUs.
As an extra benefit than simply removing the requirement for demuxers to
parse OBUs that may even only be in sample data just to see if the file
can be decoded (firing up a hardware decoder can be expensive), it would
also give us a way to identify the source of the bitstream (mp4/mkv vs
ivf/raw/annexb/etc), for example for the purpose of inserting the
extradata Seq Header if not present on key frames (Matroska allows to
remove it, but isobmff in section 2.5 seems to want a sync sample to be
a fully compliant RAP without the need of extradata obus, despite the
description in section 2.4.4), achieved by writing and using an
av1_mp4tolobf bsf or similar, which would then be included where needed
instead of the naive dump_extradata one from patch 2/5 of this set, for
example.
I totally support this. In the end storing OBUs in extra data is
becoming a PITA, especially if it needs to be prepended to some frames
but not all. If we stick to a simpler structure with what's needed to
identify decoder properties (mostly the profile) it would make things a
lot easier.
Signed-off-by: James Almer
---
libavformat/matroskaenc.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index b7ff1950d3..816ddd059a 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -21,6 +21,7 @@
#include
+#include "av1.h"
#include "avc.h"
#include "hevc.h"
#include "avformat.h"
@@ -769,6 +770,9 @@ static int
mkv_write_native_codecprivate(AVFormatContext *s, AVIOContext *pb,
ff_isom_write_hvcc(dyn_cp, par->extradata,
par->extradata_size, 0);
return 0;
+ case AV_CODEC_ID_AV1:
+ return ff_isom_write_av1c(dyn_cp, par->extradata,
+ par->extradata_size);
case AV_CODEC_ID_ALAC:
if (par->extradata_size < 36) {
av_log(s, AV_LOG_ERROR,
@@ -2120,6 +2124,8 @@ static void mkv_write_block(AVFormatContext *s,
AVIOContext *pb,
(AV_RB24(par->extradata) == 1 ||
AV_RB32(par->extradata) == 1))
/* extradata is Annex B, assume the bitstream is too and
convert it */
ff_hevc_annexb2mp4_buf(pkt->data, &data, &size, 0, NULL);
+ else if (par->codec_id == AV_CODEC_ID_AV1)
+ ff_av1_filter_obus_buf(pkt->data, &data, &size);
else if (par->codec_id == AV_CODEC_ID_WAVPACK) {
int ret = mkv_strip_wavpack(pkt->data, &data, &size);
if (ret < 0) {
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/5] avformat/mov: add support for AV1 streams
On 7/19/2018 12:16 PM, James Almer wrote:
> On 7/19/2018 9:57 AM, Francois Cartegnie wrote:
>> Hi,
>>
>> Sorry, can't reply to thread.
>>
>>> +if (version != 0) {
>>> +av_log(c->fc, AV_LOG_WARNING, "Unknown AV1 Codec Configuration Box
>>> version %d\n", version);
>>> +return 0;
>>> +}
>>> +avio_skip(pb, 3); /* flags */
>>> +
>>> +avio_skip(pb, 1); /* reserved, initial_presentation_delay_present,
>>> initial_presentation_delay_minus_one */
>>> +
>>> +ret = ff_get_extradata(c->fc, st->codecpar, pb, atom.size - 5);
>>
>> Seems to me that using OBU only as internal extradata, unlike h264 or
>> hevc, will only cause issues.
>>
>> There's no version as a guarantee on which OBU should be found, and it
>> implies parsing OBU just like with AnnexB.
>
> Unlike avcc and hvcc, the spec didn't define a custom encapsulation for
> av1c, but it does state which types should be found:
>
> "The configOBUs field is expected to contain only OBU_SEQUENCE_HEADER
> and OBU_METADATA when the metadata OBU is applicable to all the
> associated samples"
>
> Matroska has the same requirements.
>
>> Parsing might also not be possible without accessing samples data when
>> there's potentially zero OBU in DCR.
>
> Steve Lhomme opened a issue[1] about it. The spec states "zero or more
> OBUs" in av1c, whereas In Matroska the Sequence Header is guaranteed to
> be present as they say "one or more OBUs".
>
> Fwiw, in ffmpeg's case at least, libavformat will generate the internal
> extradata on its own by extracting the first Sequence Header from the
> bitstream if the demuxer didn't allocate it itself. This is what's done
> for ivf and such containers.
>
>>
>> I've raised the issue on the spec, as the DCR itself does not seems to
>> contain enough extracted information, like profile for routing to a
>> proper decoder.
>
> Like you said, you're clearly expected to parse the Sequence Header OBU
> in configOBUs. Profile is the very first value in it after the OBU header.
>
> [1] https://github.com/AOMediaCodec/av1-isobmff/issues/46
I made a summary of all the comments/suggestions scattered across
issues/PRs into https://github.com/AOMediaCodec/av1-isobmff/issues/50.
Yours, and those by Steve Lhomme. We'll see what, if anything, comes out
of it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/svq3: Fix regression decoding some files.
Fixes some SVQ3 encoded files which fail to decode correctly after 6d6faa2a2d.
These files exhibit lots of artifacts and logs show "Media key encryption is
not implemented".
However they decode without artifacts before 6d6faa2a2d.
The attatched patch allows these files to successfully decode, but also reject
media key files.
Tested on the files in #6094 and
http://samples.mplayerhq.hu/V-codecs/SVQ3/Vertical400kbit.sorenson3.mov
---
libavcodec/svq3.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libavcodec/svq3.c b/libavcodec/svq3.c
index fc17081ecf..18a4448ffa 100644
--- a/libavcodec/svq3.c
+++ b/libavcodec/svq3.c
@@ -1064,16 +1064,15 @@ static int svq3_decode_slice_header(AVCodecContext
*avctx)
av_log(s->avctx, AV_LOG_ERROR, "illegal slice type %u \n", slice_id);
return -1;
}
-if (get_bits1(&s->gb_slice)) {
-avpriv_report_missing_feature(s->avctx, "Media key encryption");
-return AVERROR_PATCHWELCOME;
-}
s->slice_type = ff_h264_golomb_to_pict_type[slice_id];
if ((header & 0x9F) == 2) {
-i = (s->mb_num < 64) ? 5 : av_log2(s->mb_num - 1);
+i = (s->mb_num < 64) ? 6 : (1 + av_log2(s->mb_num - 1));
get_bits(&s->gb_slice, i);
+} else if (get_bits1(&s->gb_slice)) {
+avpriv_report_missing_feature(s->avctx, "Media key encryption");
+return AVERROR_PATCHWELCOME;
}
s->slice_num = get_bits(&s->gb_slice, 8);
--
2.18.0.345.g5c9ce644c3-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior when start_time_text is -1<<63
On Mon, Jul 30, 2018 at 01:49:24PM -0700, Fredrik Hubinette wrote: > Is casting a negative integer to unsigned defined behavior? yes 6.3.1.3 Signed and unsigned integers 2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.49) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avformat/av1: reorder av1C OBUs before writting them
Make sure Sequence Header is first, and only allow one of its kind.
Signed-off-by: James Almer
---
Both these patches should be applied before "[PATCH 5/5] avformat/matroskaenc:
update AV1 support"
Was not planning on sending them until
https://github.com/AOMediaCodec/av1-isobmff/issues/50 and all the quoted issues
were dealt with, but might as well just get this up to date to the current
revision in the meantime.
libavformat/av1.c | 61 ++-
1 file changed, 50 insertions(+), 11 deletions(-)
diff --git a/libavformat/av1.c b/libavformat/av1.c
index 7c55a100bf..14e2abd3ff 100644
--- a/libavformat/av1.c
+++ b/libavformat/av1.c
@@ -79,33 +79,72 @@ int ff_av1_filter_obus_buf(const uint8_t *buf, uint8_t
**out, int *size)
int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf, int size)
{
+AVIOContext *seq_pb = NULL, *meta_pb = NULL;
+uint8_t *seq = NULL, *meta = NULL;
int64_t obu_size;
int start_pos, type, temporal_id, spatial_id;
+int ret, nb_seq = 0, seq_size, meta_size;
if (size <= 0)
return AVERROR_INVALIDDATA;
+ret = avio_open_dyn_buf(&seq_pb);
+if (ret < 0)
+return ret;
+ret = avio_open_dyn_buf(&meta_pb);
+if (ret < 0)
+goto fail;
+
while (size > 0) {
-int ret = parse_obu_header(buf, size, &obu_size, &start_pos,
+int len = parse_obu_header(buf, size, &obu_size, &start_pos,
&type, &temporal_id, &spatial_id);
-if (ret < 0)
-return ret;
-
-obu_size += start_pos;
-if (obu_size > INT_MAX)
-return AVERROR_INVALIDDATA;
+if (len < 0) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
switch (type) {
case AV1_OBU_SEQUENCE_HEADER:
+nb_seq++;
+
+if (!obu_size || nb_seq > 1) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+avio_write(seq_pb, buf, len);
+break;
case AV1_OBU_METADATA:
-avio_write(pb, buf, obu_size);
+if (!obu_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+avio_write(meta_pb, buf, len);
break;
default:
break;
}
-size -= obu_size;
-buf += obu_size;
+size -= len;
+buf += len;
}
-return 0;
+seq_size = avio_close_dyn_buf(seq_pb, &seq);
+if (!seq_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+avio_write(pb, seq, seq_size);
+
+meta_size = avio_close_dyn_buf(meta_pb, &meta);
+if (meta_size)
+avio_write(pb, meta, meta_size);
+
+fail:
+if (!seq)
+avio_close_dyn_buf(seq_pb, &seq);
+if (!meta)
+avio_close_dyn_buf(meta_pb, &meta);
+av_free(seq);
+av_free(meta);
+
+return ret;
}
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/av1_parse: return size of the parsed obu in parse_obu_header()
Signed-off-by: James Almer
---
libavcodec/av1_parse.c | 6 ++
libavcodec/av1_parse.h | 8 +++-
2 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/libavcodec/av1_parse.c b/libavcodec/av1_parse.c
index 48feb9fb8a..b1da44ec72 100644
--- a/libavcodec/av1_parse.c
+++ b/libavcodec/av1_parse.c
@@ -42,12 +42,10 @@ int ff_av1_extract_obu(AV1OBU *obu, const uint8_t *buf, int
length, void *logctx
obu->temporal_id = temporal_id;
obu->spatial_id = spatial_id;
-length = obu_size + start_pos;
-
obu->data = buf + start_pos;
obu->size = obu_size;
obu->raw_data = buf;
-obu->raw_size = length;
+obu->raw_size = ret;
ret = init_get_bits(&obu->gb, obu->data, obu->size * 8);
if (ret < 0)
@@ -57,7 +55,7 @@ int ff_av1_extract_obu(AV1OBU *obu, const uint8_t *buf, int
length, void *logctx
"obu_type: %d, temporal_id: %d, spatial_id: %d, payload size: %d\n",
obu->type, obu->temporal_id, obu->spatial_id, obu->size);
-return length;
+return obu->raw_size;
}
int ff_av1_packet_split(AV1Packet *pkt, const uint8_t *buf, int length, void
*logctx)
diff --git a/libavcodec/av1_parse.h b/libavcodec/av1_parse.h
index 3a4151491a..9a6e6835ab 100644
--- a/libavcodec/av1_parse.h
+++ b/libavcodec/av1_parse.h
@@ -95,6 +95,7 @@ static inline int parse_obu_header(const uint8_t *buf, int
buf_size,
{
GetBitContext gb;
int ret, extension_flag, has_size_flag;
+int64_t size;
ret = init_get_bits8(&gb, buf, FFMIN(buf_size, 2 + 8)); // OBU header
fields + max leb128 length
if (ret < 0)
@@ -124,7 +125,12 @@ static inline int parse_obu_header(const uint8_t *buf, int
buf_size,
*start_pos = get_bits_count(&gb) / 8;
-return 0;
+size = *obu_size + *start_pos;
+
+if (size > INT_MAX)
+return AVERROR(ERANGE);
+
+return size;
}
#endif /* AVCODEC_AV1_PARSE_H */
--
2.18.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg decoder
On Mon, Jul 30, 2018 at 01:31:59PM -0700, Fredrik Hubinette wrote: > Not sure how to update the commit message. git commit --amend > The undefined behavior occurs in av_add_stable, which is called from > compute_packet_fields. > In that code PTS can be equal to -(1<<63), which then causes a int64_t to > overflow. This does not sound specific to oggdec. Thus a change in oggdec would likely not fix it outside ogg. Or am i missing something ? thx > > On Wed, Jul 18, 2018 at 4:04 AM Michael Niedermayer > wrote: > > > On Mon, Jul 16, 2018 at 04:32:14PM -0700, Fredrik Hubinette wrote: > > > With some (garbled) OGG data, PTS can overflow causing undefined > > behavior. > > > This patch avoids that by zeroing out PTS values greater than 2^62. > > > > > oggdec.h |3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > ff003b78842c7724ccc1a42f9584b1f8aa0b0b3d > > 0001-Avoid-undefined-behavior-by-limiting-PTS-to-62-bits-.patch > > > From 26a8582bc04f5bddc037ffcce99025e2f977abe0 Mon Sep 17 00:00:00 2001 > > > From: Fredrik Hubinette > > > Date: Mon, 16 Jul 2018 14:54:43 -0700 > > > Subject: [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in > > ogg > > > decoder > > > > > > --- > > > libavformat/oggdec.h | 3 ++- > > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > I think someone reading this commit message would like to know more > > about where that undefined behaviour occurs and how this is guranteeing > > to fix it > > > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > "Nothing to hide" only works if the folks in power share the values of > > you and everyone you know entirely and always will -- Tom Scott > > > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [FFmpeg-user] fMP4 generation speed
> On Jul 25, 2018, at 11:42 PM, Liu Steven wrote: > > > >> 在 2018年7月26日，上午11:30，Ronak Patel 写道： >> >> >> >>> On Jul 25, 2018, at 11:25 PM, Ronak Patel >>> wrote: >>> >>> >>> On Jul 25, 2018, at 11:12 PM, Liu Steven wrote: > 在 2018年7月26日，上午7:04，Ronak Patel 写道： > > Hi, > > We’d like to start working on this real soon and want to make sure we > properly fix this. We understand this code is used by more than just fMP4 > assets and even live streaming use cases. > > Can anyone please help shed some light on all use cases we should make > sure are working after we make our fixes? > > We’re afraid that the number of use cases here are unknown and we’ll be > stuck fixing this for an unknown time. > > Can anyone please shed some light on this? you can try -f segment or -f hls or -f dash to do waht you want try, if all of them cannot suuport your feature, you can submmit patch here. or you can submmit a new hls muxer patch here if you cannot fix all the parameters for the old hls muxer. >> >> Ok I’m going to try to fix mpegts, live streams, fmp4 and the other options >> that you already have. >> >> Are there any unit tests or other tests we can run to ensure everything is >> still working? >> >> If not we will have to make sure it works manually. > You can add fate for the current hls. > > BTW, you can try hls_list_size 0 to make sure it can make the feature which > you need. I tried this, but it has no effect. So, here's what I'm thinking to solve this: 1. The HLS Manifest Header should be written in the hls_init method, not in the hls_window one. 2. Hls_window should only append a new segment definition to the end of the manifest file. 3. We can write out HLS_X_ENDLIST if we've reached the end of the file, or if the option says to attach it. Would there be any reason why this algorithm wouldn't work to solve all possible use cases? We wouldn't have to keep regenerating the entire file just to append a new segment to the end of it. Ronak ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC] [PATCH] On the fly generation of default DNN models and code style fixes
On Mon, Jul 30, 2018 at 07:59:00PM +0300, Sergey Lavrushkin wrote:
> 2018-07-30 2:01 GMT+03:00 Michael Niedermayer :
>
> > On Sat, Jul 28, 2018 at 01:00:53PM +0300, Sergey Lavrushkin wrote:
> > > 2018-07-28 4:31 GMT+03:00 Michael Niedermayer :
> > >
> > > > On Fri, Jul 27, 2018 at 08:06:15PM +0300, Sergey Lavrushkin wrote:
> > > > > Hello,
> > > > >
> > > > > The first patch provides on the fly generation of default DNN models,
> > > > > that eliminates data duplication for model weights. Also, files with
> > > > > internal weights
> > > > > were replaced with automatically generated one for models I trained.
> > > > > Scripts for training and generating these files can be found here:
> > > > > https://github.com/HighVoltageRocknRoll/sr
> > > > > Later, I will add a description to this repo on how to use it and
> > > > benchmark
> > > > > results for trained models.
> > > > >
> > > > > The second patch fixes some code style issues for pointers in DNN
> > module
> > > > > and sr filter. Are there any other code style fixes I should make for
> > > > this
> > > > > code?
> > > >
> > > >
> > > > It seems the code with these patches produces some warnings:
> > > >
> > > > In file included from libavfilter/dnn_backend_native.c:27:0:
> > > > libavfilter/dnn_srcnn.h:2113:21: warning: ‘srcnn_consts’ defined but
> > not
> > > > used [-Wunused-variable]
> > > > static const float *srcnn_consts[] = {
> > > > ^
> > > > libavfilter/dnn_srcnn.h:2122:24: warning: ‘srcnn_consts_dims’ defined
> > but
> > > > not used [-Wunused-variable]
> > > > static const long int *srcnn_consts_dims[] = {
> > > > ^
> > > > libavfilter/dnn_srcnn.h:2142:20: warning: ‘srcnn_activations’ defined
> > but
> > > > not used [-Wunused-variable]
> > > > static const char *srcnn_activations[] = {
> > > > ^
> > > > In file included from libavfilter/dnn_backend_native.c:28:0:
> > > > libavfilter/dnn_espcn.h:5401:21: warning: ‘espcn_consts’ defined but
> > not
> > > > used [-Wunused-variable]
> > > > static const float *espcn_consts[] = {
> > > > ^
> > > > libavfilter/dnn_espcn.h:5410:24: warning: ‘espcn_consts_dims’ defined
> > but
> > > > not used [-Wunused-variable]
> > > > static const long int *espcn_consts_dims[] = {
> > > > ^
> > > > libavfilter/dnn_espcn.h:5432:20: warning: ‘espcn_activations’ defined
> > but
> > > > not used [-Wunused-variable]
> > > > static const char *espcn_activations[] = {
> > > > ^
> > > >
> > >
> > > Here is the patch, that fixes these warnings.
> >
> > > dnn_backend_tf.c | 64 ++
> > -
> > > dnn_espcn.h | 37 ---
> > > dnn_srcnn.h | 35 --
> > > 3 files changed, 63 insertions(+), 73 deletions(-)
> > > 1faef51b86165326a4693c07a203113e2c85f7fb 0003-libavfilter-Fixes-
> > warnings-for-unused-variables-in-d.patch
> > > From 37cd7bdf2610e1c3e89210a49e8f5f3832726281 Mon Sep 17 00:00:00 2001
> > > From: Sergey Lavrushkin
> > > Date: Sat, 28 Jul 2018 12:55:02 +0300
> > > Subject: [PATCH 3/3] libavfilter: Fixes warnings for unused variables in
> > > dnn_srcnn.h, dnn_espcn.h, dnn_backend_tf.c.
> > >
> > > ---
> > > libavfilter/dnn_backend_tf.c | 64 ++
> > +-
> > > libavfilter/dnn_espcn.h | 37 -
> > > libavfilter/dnn_srcnn.h | 35
> > > 3 files changed, 63 insertions(+), 73 deletions(-)
> > >
> > > diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> > > index 6307c794a5..7a4ad72d27 100644
> > > --- a/libavfilter/dnn_backend_tf.c
> > > +++ b/libavfilter/dnn_backend_tf.c
> > > @@ -374,9 +374,71 @@ DNNModel
> > > *ff_dnn_load_default_model_tf(DNNDefaultModel
> > model_type)
> > > TFModel *tf_model = NULL;
> > > TF_OperationDescription *op_desc;
> > > TF_Operation *op;
> > > -TF_Operation *const_ops_buffer[6];
> > > TF_Output input;
> > > int64_t input_shape[] = {1, -1, -1, 1};
> > > +const char tanh[] = "Tanh";
> > > +const char sigmoid[] = "Sigmoid";
> > > +const char relu[] = "Relu";
> > > +
> > > +const float *srcnn_consts[] = {
> > > +srcnn_conv1_kernel,
> > > +srcnn_conv1_bias,
> > > +srcnn_conv2_kernel,
> > > +srcnn_conv2_bias,
> > > +srcnn_conv3_kernel,
> > > +srcnn_conv3_bias
> > > +};
> > > +const long int *srcnn_consts_dims[] = {
> > > +srcnn_conv1_kernel_dims,
> > > +srcnn_conv1_bias_dims,
> > > +srcnn_conv2_kernel_dims,
> > > +srcnn_conv2_bias_dims,
> > > +srcnn_conv3_kernel_dims,
> > > +srcnn_conv3_bias_dims
> > > +};
> > > +const int srcnn_consts_dims_len[] = {
> > > +4,
> > > +1,
> > > +4,
> > > +1,
> > > +4,
> > > +1
> > > +};
>
Re: [FFmpeg-devel] [PATCH] avcodec/h264_mp4toannexb_bsf: use enum constants for the NAL unit type values
On 7/29/2018 9:24 PM, myp...@gmail.com wrote: > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior when start_time_text is -1<<63
Is casting a negative integer to unsigned defined behavior? On Wed, Jul 18, 2018 at 3:55 AM Michael Niedermayer wrote: > On Tue, Jul 17, 2018 at 02:37:55PM -0700, Fredrik Hubinette wrote: > > > > > utils.c |2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > e69f1a3a447e331cad7ea85e28c0ed13e48ce33c > 0001-Avoid-undefined-behavior-when-start_time_text-is-1-6.patch > > From d7bd55c3d280c10b990577003a985296f10a2b59 Mon Sep 17 00:00:00 2001 > > From: Fredrik Hubinette > > Date: Tue, 17 Jul 2018 14:35:55 -0700 > > Subject: [PATCH] Avoid undefined behavior when start_time_text is -1<<63 > > > > --- > > libavformat/utils.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/libavformat/utils.c b/libavformat/utils.c > > index c9cdd2b470..5b83ed7872 100644 > > --- a/libavformat/utils.c > > +++ b/libavformat/utils.c > > @@ -2666,7 +2666,7 @@ static void update_stream_timings(AVFormatContext > *ic) > > duration = FFMAX(duration, duration1); > > } > > } > > -if (start_time == INT64_MAX || (start_time > start_time_text && > start_time - start_time_text < AV_TIME_BASE)) > > +if (start_time == INT64_MAX || (start_time > start_time_text && > start_time - AV_TIME_BASE < start_time_text )) > > Casting to uint64_t should be a more complete fix. > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Awnsering whenever a program halts or runs forever is > On a turing machine, in general impossible (turings halting problem). > On any real computer, always possible as a real computer has a finite > number > of states N, and will either halt in less than N cycles or never halt. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in ogg decoder
Not sure how to update the commit message. The undefined behavior occurs in av_add_stable, which is called from compute_packet_fields. In that code PTS can be equal to -(1<<63), which then causes a int64_t to overflow. On Wed, Jul 18, 2018 at 4:04 AM Michael Niedermayer wrote: > On Mon, Jul 16, 2018 at 04:32:14PM -0700, Fredrik Hubinette wrote: > > With some (garbled) OGG data, PTS can overflow causing undefined > behavior. > > This patch avoids that by zeroing out PTS values greater than 2^62. > > > oggdec.h |3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > ff003b78842c7724ccc1a42f9584b1f8aa0b0b3d > 0001-Avoid-undefined-behavior-by-limiting-PTS-to-62-bits-.patch > > From 26a8582bc04f5bddc037ffcce99025e2f977abe0 Mon Sep 17 00:00:00 2001 > > From: Fredrik Hubinette > > Date: Mon, 16 Jul 2018 14:54:43 -0700 > > Subject: [PATCH] Avoid undefined behavior by limiting PTS to 62 bits in > ogg > > decoder > > > > --- > > libavformat/oggdec.h | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > I think someone reading this commit message would like to know more > about where that undefined behaviour occurs and how this is guranteeing > to fix it > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > "Nothing to hide" only works if the folks in power share the values of > you and everyone you know entirely and always will -- Tom Scott > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/utils: set AV_PKT_FLAG_KEY for data packets
--- libavformat/utils.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavformat/utils.c b/libavformat/utils.c index c9cdd2b470..b15f20dd23 100644 --- a/libavformat/utils.c +++ b/libavformat/utils.c @@ -1405,7 +1405,7 @@ static void compute_pkt_fields(AVFormatContext *s, AVStream *st, presentation_delayed, delay, av_ts2str(pkt->pts), av_ts2str(pkt->dts), av_ts2str(st->cur_dts)); /* update flags */ -if (is_intra_only(st->codecpar->codec_id)) +if (st->codecpar->codec_type == AVMEDIA_TYPE_DATA || is_intra_only(st->codecpar->codec_id)) pkt->flags |= AV_PKT_FLAG_KEY; #if FF_API_CONVERGENCE_DURATION FF_DISABLE_DEPRECATION_WARNINGS -- 2.17.0 (Apple Git-106) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Media Player Dveloper
Deat Sir, We are looking for a developer to help us build a Media Player for providing IPTV Services. Sanjeev K Narula CEO, Brands TV Media New Delhi M +919818719906 ( What's App ) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libopusenc: allow encoding channel mapping 2
On Sat, Jul 28, 2018 at 10:46 AM Rostislav Pehlivanov
wrote:
> On 27 July 2018 at 20:44, Felicia Lim
> wrote:
>
> > ---
> > libavcodec/libopusenc.c | 22 ++
> > 1 file changed, 22 insertions(+)
> >
> > diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> > index 4ae81b0bb2..6b450ec317 100644
> > --- a/libavcodec/libopusenc.c
> > +++ b/libavcodec/libopusenc.c
> > @@ -27,6 +27,7 @@
> > #include "bytestream.h"
> > #include "internal.h"
> > #include "libopus.h"
> > +#include "mathops.h"
> > #include "vorbis.h"
> > #include "audio_frame_queue.h"
> >
> > @@ -200,6 +201,21 @@ static int
> libopus_check_vorbis_layout(AVCodecContext
> > *avctx, int mapping_family
> > return 0;
> > }
> >
> > +static int libopus_check_ambisonics_channels(AVCodecContext *avctx) {
> > +int channels = avctx->channels;
> > +int ambisonic_order = ff_sqrt(channels) - 1;
> > +if (channels != ((ambisonic_order + 1) * (ambisonic_order + 1)) &&
> > +channels != ((ambisonic_order + 1) * (ambisonic_order + 1) +
> 2)) {
> > +av_log(avctx, AV_LOG_ERROR,
> > + "Ambisonics coding is only specified for channel counts"
> > + " which can be written as (n + 1)^2 or (n + 1)^2 + 2"
> > + " for nonnegative integer n\n");
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > static int libopus_validate_layout_and_get_channel_map(
> > AVCodecContext *avctx,
> > int mapping_family,
> > @@ -231,6 +247,12 @@ static int libopus_validate_layout_and_
> > get_channel_map(
> > channel_map =
> ff_vorbis_channel_layout_offsets[avctx->channels
> > - 1];
> > }
> > break;
> > +case 2:
> > +ret = libopus_check_max_channels(avctx, 227);
> > +if (ret == 0) {
> > +ret = libopus_check_ambisonics_channels(avctx);
> > +}
> >
>
> No brackets needed, also if (ret) looks better imo.
>
Thanks for reviewing. Would this change would break with the style
elsewhere in this function? I'm happy to change if you still think I should
do it.
I also just realized the patch description should be "Remove warning when
trying to encode channel mapping 2": it already encodes even without this
patch. Will send an update after the above comment is resolved.
> Does libopus understand channel mapping 2 as ambisonics? What about the
> libopus_generic_encoder_() API? Doesn't that need to be used to encode
> ambisonics, like the patch by Drew did?
>
Yes, libopus also understands channel mapping 2 as ambisonics by default
now.
Ch map 2 uses the normal opus_multistream_encode(), so no further changes
are needed. On the other hand, ch map 3 uses the new
opus_projection_encode(), hence Drew's introduction of
libopus_generic_encoder_() to handle the switch as needed.
___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [GSOC] [PATCH] On the fly generation of default DNN models and code style fixes
2018-07-30 2:01 GMT+03:00 Michael Niedermayer :
> On Sat, Jul 28, 2018 at 01:00:53PM +0300, Sergey Lavrushkin wrote:
> > 2018-07-28 4:31 GMT+03:00 Michael Niedermayer :
> >
> > > On Fri, Jul 27, 2018 at 08:06:15PM +0300, Sergey Lavrushkin wrote:
> > > > Hello,
> > > >
> > > > The first patch provides on the fly generation of default DNN models,
> > > > that eliminates data duplication for model weights. Also, files with
> > > > internal weights
> > > > were replaced with automatically generated one for models I trained.
> > > > Scripts for training and generating these files can be found here:
> > > > https://github.com/HighVoltageRocknRoll/sr
> > > > Later, I will add a description to this repo on how to use it and
> > > benchmark
> > > > results for trained models.
> > > >
> > > > The second patch fixes some code style issues for pointers in DNN
> module
> > > > and sr filter. Are there any other code style fixes I should make for
> > > this
> > > > code?
> > >
> > >
> > > It seems the code with these patches produces some warnings:
> > >
> > > In file included from libavfilter/dnn_backend_native.c:27:0:
> > > libavfilter/dnn_srcnn.h:2113:21: warning: ‘srcnn_consts’ defined but
> not
> > > used [-Wunused-variable]
> > > static const float *srcnn_consts[] = {
> > > ^
> > > libavfilter/dnn_srcnn.h:2122:24: warning: ‘srcnn_consts_dims’ defined
> but
> > > not used [-Wunused-variable]
> > > static const long int *srcnn_consts_dims[] = {
> > > ^
> > > libavfilter/dnn_srcnn.h:2142:20: warning: ‘srcnn_activations’ defined
> but
> > > not used [-Wunused-variable]
> > > static const char *srcnn_activations[] = {
> > > ^
> > > In file included from libavfilter/dnn_backend_native.c:28:0:
> > > libavfilter/dnn_espcn.h:5401:21: warning: ‘espcn_consts’ defined but
> not
> > > used [-Wunused-variable]
> > > static const float *espcn_consts[] = {
> > > ^
> > > libavfilter/dnn_espcn.h:5410:24: warning: ‘espcn_consts_dims’ defined
> but
> > > not used [-Wunused-variable]
> > > static const long int *espcn_consts_dims[] = {
> > > ^
> > > libavfilter/dnn_espcn.h:5432:20: warning: ‘espcn_activations’ defined
> but
> > > not used [-Wunused-variable]
> > > static const char *espcn_activations[] = {
> > > ^
> > >
> >
> > Here is the patch, that fixes these warnings.
>
> > dnn_backend_tf.c | 64 ++
> -
> > dnn_espcn.h | 37 ---
> > dnn_srcnn.h | 35 --
> > 3 files changed, 63 insertions(+), 73 deletions(-)
> > 1faef51b86165326a4693c07a203113e2c85f7fb 0003-libavfilter-Fixes-
> warnings-for-unused-variables-in-d.patch
> > From 37cd7bdf2610e1c3e89210a49e8f5f3832726281 Mon Sep 17 00:00:00 2001
> > From: Sergey Lavrushkin
> > Date: Sat, 28 Jul 2018 12:55:02 +0300
> > Subject: [PATCH 3/3] libavfilter: Fixes warnings for unused variables in
> > dnn_srcnn.h, dnn_espcn.h, dnn_backend_tf.c.
> >
> > ---
> > libavfilter/dnn_backend_tf.c | 64 ++
> +-
> > libavfilter/dnn_espcn.h | 37 -
> > libavfilter/dnn_srcnn.h | 35
> > 3 files changed, 63 insertions(+), 73 deletions(-)
> >
> > diff --git a/libavfilter/dnn_backend_tf.c b/libavfilter/dnn_backend_tf.c
> > index 6307c794a5..7a4ad72d27 100644
> > --- a/libavfilter/dnn_backend_tf.c
> > +++ b/libavfilter/dnn_backend_tf.c
> > @@ -374,9 +374,71 @@ DNNModel *ff_dnn_load_default_model_tf(DNNDefaultModel
> model_type)
> > TFModel *tf_model = NULL;
> > TF_OperationDescription *op_desc;
> > TF_Operation *op;
> > -TF_Operation *const_ops_buffer[6];
> > TF_Output input;
> > int64_t input_shape[] = {1, -1, -1, 1};
> > +const char tanh[] = "Tanh";
> > +const char sigmoid[] = "Sigmoid";
> > +const char relu[] = "Relu";
> > +
> > +const float *srcnn_consts[] = {
> > +srcnn_conv1_kernel,
> > +srcnn_conv1_bias,
> > +srcnn_conv2_kernel,
> > +srcnn_conv2_bias,
> > +srcnn_conv3_kernel,
> > +srcnn_conv3_bias
> > +};
> > +const long int *srcnn_consts_dims[] = {
> > +srcnn_conv1_kernel_dims,
> > +srcnn_conv1_bias_dims,
> > +srcnn_conv2_kernel_dims,
> > +srcnn_conv2_bias_dims,
> > +srcnn_conv3_kernel_dims,
> > +srcnn_conv3_bias_dims
> > +};
> > +const int srcnn_consts_dims_len[] = {
> > +4,
> > +1,
> > +4,
> > +1,
> > +4,
> > +1
> > +};
>
> not important at all but, why do you remove "static" from these ?
>
I moved it to the function where it is only used, and thought it should not
be static in it.
Are there some reasons to declare these consts static?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
ht
Re: [FFmpeg-devel] [PATCH 5/5] avformat/matroskaenc: update AV1 support
On 7/30/2018 2:03 AM, Steve Lhomme wrote:
> On 26/07/2018 03:11, James Almer wrote:
>> Make sure to not write forbidden OBUs to CodecPrivate, and do the same
>> with
>> unnecessary OBUs for packets.
>
> Does this include reordering the OBUs ? The first one must be the
> Sequence Header OBU. Also it must be the only one of that kind.
No, it doesn't. I can make that change, but why does it matter if it's
the first? Why can't a metadata OBU be before a Seq Header? isobmff
doesn't care what's first, only what's in.
A parser is currently forced to know how to read OBUs anyway, and it
could just skip any metadata obu before the sequence header.
For that matter, i do agree with
https://github.com/AOMediaCodec/av1-isobmff/issues/7#issuecomment-406257234
and
https://github.com/AOMediaCodec/av1-isobmff/issues/46#issuecomment-406516226
that perhaps av1C should, much like hvcC, avcC and in it's own way also
vpcC, contain a bunch of header bytes listing some basic information
(and therefore the entire thing, sans atom size and fourcc, be included
in CodecPrivate verbatim). Things like profile, level, and maybe number
of OBUs, before the raw OBUs.
As an extra benefit than simply removing the requirement for demuxers to
parse OBUs that may even only be in sample data just to see if the file
can be decoded (firing up a hardware decoder can be expensive), it would
also give us a way to identify the source of the bitstream (mp4/mkv vs
ivf/raw/annexb/etc), for example for the purpose of inserting the
extradata Seq Header if not present on key frames (Matroska allows to
remove it, but isobmff in section 2.5 seems to want a sync sample to be
a fully compliant RAP without the need of extradata obus, despite the
description in section 2.4.4), achieved by writing and using an
av1_mp4tolobf bsf or similar, which would then be included where needed
instead of the naive dump_extradata one from patch 2/5 of this set, for
example.
>
>>
>> Signed-off-by: James Almer
>> ---
>> libavformat/matroskaenc.c | 6 ++
>> 1 file changed, 6 insertions(+)
>>
>> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
>> index b7ff1950d3..816ddd059a 100644
>> --- a/libavformat/matroskaenc.c
>> +++ b/libavformat/matroskaenc.c
>> @@ -21,6 +21,7 @@
>> #include
>> +#include "av1.h"
>> #include "avc.h"
>> #include "hevc.h"
>> #include "avformat.h"
>> @@ -769,6 +770,9 @@ static int
>> mkv_write_native_codecprivate(AVFormatContext *s, AVIOContext *pb,
>> ff_isom_write_hvcc(dyn_cp, par->extradata,
>> par->extradata_size, 0);
>> return 0;
>> + case AV_CODEC_ID_AV1:
>> + return ff_isom_write_av1c(dyn_cp, par->extradata,
>> + par->extradata_size);
>> case AV_CODEC_ID_ALAC:
>> if (par->extradata_size < 36) {
>> av_log(s, AV_LOG_ERROR,
>> @@ -2120,6 +2124,8 @@ static void mkv_write_block(AVFormatContext *s,
>> AVIOContext *pb,
>> (AV_RB24(par->extradata) == 1 ||
>> AV_RB32(par->extradata) == 1))
>> /* extradata is Annex B, assume the bitstream is too and
>> convert it */
>> ff_hevc_annexb2mp4_buf(pkt->data, &data, &size, 0, NULL);
>> + else if (par->codec_id == AV_CODEC_ID_AV1)
>> + ff_av1_filter_obus_buf(pkt->data, &data, &size);
>> else if (par->codec_id == AV_CODEC_ID_WAVPACK) {
>> int ret = mkv_strip_wavpack(pkt->data, &data, &size);
>> if (ret < 0) {
>> --
>> 2.18.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/3] enable multi-slices in vaapi_h264/265 encoder
V6: - Use rectangular slices and refine the code. V5: - In h265_vaapi encoder, when setting slice number > max slice number supported by driver, report error and return. Same as h264_vaapi. - Clean the logic when setting first_slice_segment_in_pic_flags. V4: - Change the array malloc function. - Clean the pointless condition check when free the memory. V3: - Making pic->slices be VAAPIEncodeSlice* instead of VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc pic->param_buffers fail. - Adjust max_slices location in VAAPIEncodeContext. - Re-work distributing the macro-blocks for multi-slices function. V2: - Change the slice/parameter buffers to dynamic alloc and split the mutil-slice support for AVC/HEVC. Jun Zhao (3): lavc/vaapi_encode: Add max slices number query. lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder libavcodec/vaapi_encode.c |4 libavcodec/vaapi_encode.h |4 libavcodec/vaapi_encode_h264.c | 31 +-- libavcodec/vaapi_encode_h265.c | 30 -- 4 files changed, 57 insertions(+), 12 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder
Enable multi-slice support in HEVC/H.265 vaapi encoder.
Signed-off-by: Wang, Yi A
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h265.c | 30 --
1 files changed, 24 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index bbba2b8..cfdbeae 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -618,6 +618,7 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
VAAPIEncodeH265Options *opt = ctx->codec_options;
VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
int i;
+int slices;
if (pic->type == PICTURE_TYPE_IDR) {
av_assert0(pic->display_order == pic->encode_order);
@@ -788,7 +789,17 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
av_assert0(0 && "invalid picture type");
}
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= FFMIN(ctx->max_slices, priv->ctu_height)) {
+slices = FFMAX(avctx->slices, slices);
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+ "cannot more than %d.\n", FFMIN(ctx->max_slices,
priv->ctu_height));
+return AVERROR_INVALIDDATA;
+}
+}
+pic->nb_slices = slices;
return 0;
}
@@ -814,9 +825,8 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
sh->slice_pic_parameter_set_id = pps->pps_pic_parameter_set_id;
-// Currently we only support one slice per frame.
-sh->first_slice_segment_in_pic_flag = 1;
-sh->slice_segment_address = 0;
+sh->first_slice_segment_in_pic_flag = !!(slice->index == 0);
+sh->slice_segment_address = slice->index * priv->ctu_width *
(priv->ctu_height / pic->nb_slices);
sh->slice_type = priv->slice_type;
@@ -906,7 +916,6 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
*vslice = (VAEncSliceParameterBufferHEVC) {
.slice_segment_address = sh->slice_segment_address,
-.num_ctu_in_slice = priv->ctu_width * priv->ctu_height,
.slice_type = sh->slice_type,
.slice_pic_parameter_set_id = sh->slice_pic_parameter_set_id,
@@ -927,7 +936,6 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
.slice_tc_offset_div2 = sh->slice_tc_offset_div2,
.slice_fields.bits = {
-.last_slice_of_pic_flag = 1,
.dependent_slice_segment_flag = sh->dependent_slice_segment_flag,
.colour_plane_id = sh->colour_plane_id,
.slice_temporal_mvp_enabled_flag =
@@ -945,6 +953,12 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
.collocated_from_l0_flag = sh->collocated_from_l0_flag,
},
};
+if (slice->index == pic->nb_slices - 1) {
+vslice->num_ctu_in_slice = priv->ctu_width * priv->ctu_height
+ - slice->index * priv->ctu_width *
(priv->ctu_height / pic->nb_slices);
+vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
+} else
+vslice->num_ctu_in_slice = priv->ctu_width * (priv->ctu_height /
pic->nb_slices);
for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
vslice->ref_pic_list0[i].picture_id = VA_INVALID_ID;
@@ -1019,6 +1033,10 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
av_assert0(0 && "Invalid RC mode.");
}
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+ "supported with the driver.\n");
+
return 0;
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] lavc/vaapi_encode: Add max slices number query.
From: Jun Zhao
Add max slices number query.
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode.c |4
libavcodec/vaapi_encode.h |4
2 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 910fd1b..53d6424 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -971,6 +971,7 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
{ VAConfigAttribRTFormat },
{ VAConfigAttribRateControl },
{ VAConfigAttribEncMaxRefFrames },
+{ VAConfigAttribEncMaxSlices },
{ VAConfigAttribEncPackedHeaders },
};
@@ -1103,6 +1104,9 @@ static av_cold int
vaapi_encode_config_attributes(AVCodecContext *avctx)
}
}
break;
+case VAConfigAttribEncMaxSlices:
+ctx->max_slices = attr[i].value;
+break;
case VAConfigAttribEncPackedHeaders:
if (ctx->va_packed_headers & ~attr[i].value) {
// This isn't fatal, but packed headers are always
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index bcb9d57..6fcc83d 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -164,6 +164,10 @@ typedef struct VAAPIEncodeContext {
} quality_params;
#endif
+// Supported max-slices number per frame. (0 means driver cannot
+// support max multi-slices query)
+int max_slices;
+
// Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
void *codec_sequence_params;
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder
Enable multi-slice support in AVC/H.264 vaapi encoder.
Signed-off-by: Wang, Yi A
Signed-off-by: Jun Zhao
---
libavcodec/vaapi_encode_h264.c | 31 +--
1 files changed, 25 insertions(+), 6 deletions(-)
diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 905c507..70c89e8 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -581,6 +581,7 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
H264RawSPS *sps = &priv->sps;
VAEncPictureParameterBufferH264 *vpic = pic->codec_picture_params;
int i;
+int slices;
memset(&priv->current_access_unit, 0,
sizeof(priv->current_access_unit));
@@ -690,7 +691,17 @@ static int
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
vpic->pic_fields.bits.idr_pic_flag = (pic->type == PICTURE_TYPE_IDR);
vpic->pic_fields.bits.reference_pic_flag = (pic->type != PICTURE_TYPE_B);
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= FFMIN(ctx->max_slices, priv->mb_height)) {
+slices = FFMAX(avctx->slices, slices);
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+ "cannot be more than %d.\n", FFMIN(ctx->max_slices,
priv->mb_height));
+return AVERROR_INVALIDDATA;
+}
+}
+pic->nb_slices = slices;
return 0;
}
@@ -716,8 +727,7 @@ static int
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
sh->nal_unit_header.nal_ref_idc = pic->type != PICTURE_TYPE_B;
}
-// Only one slice per frame.
-sh->first_mb_in_slice = 0;
+sh->first_mb_in_slice = !!slice->index;
sh->slice_type= priv->slice_type;
sh->pic_parameter_set_id = pps->pic_parameter_set_id;
@@ -738,14 +748,19 @@ static int
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
sh->slice_qp_delta = priv->fixed_qp_idr - (pps->pic_init_qp_minus26 +
26);
-vslice->macroblock_address = sh->first_mb_in_slice;
-vslice->num_macroblocks= priv->mb_width * priv->mb_height;
+vslice->macroblock_address = slice->index * priv->mb_width *
(priv->mb_height / pic->nb_slices);
+if (slice->index == pic->nb_slices - 1) {
+vslice->num_macroblocks = priv->mb_width * priv->mb_height
+ - slice->index * priv->mb_width *
(priv->mb_height / pic->nb_slices);
+priv->idr_pic_count++;
+} else
+vslice->num_macroblocks = priv->mb_width * (priv->mb_height /
pic->nb_slices);
vslice->macroblock_info = VA_INVALID_ID;
vslice->slice_type = sh->slice_type % 5;
vslice->pic_parameter_set_id = sh->pic_parameter_set_id;
-vslice->idr_pic_id = sh->idr_pic_id;
+vslice->idr_pic_id = priv->idr_pic_count;
vslice->pic_order_cnt_lsb = sh->pic_order_cnt_lsb;
@@ -855,6 +870,10 @@ static av_cold int
vaapi_encode_h264_configure(AVCodecContext *avctx)
}
}
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+ "supported with the driver.\n");
+
return 0;
}
--
1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] hardware codec acceleration of ffmpeg
hi folks: how to utilize the hardware video decoder on specify platform based on ffmpeg framework? now a have a platform with hardware decoder which supports full video format, but i cant use the utility because the decoder process go through the software flow. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Why not integrate libyuv as a scale filter
On Tue, Jul 24, 2018 at 01:41:14 +0200, Michael Niedermayer wrote: > > Finding out why it has better performance (figures?) and integrating the > > same optimizations would be more in line with the project policy, I > > think. > > same oppinion here, if its better in some case, please integrate whatever > it does better You should also compare with the performance of a further scaling filter ffmpeg has, also dependant on an external library: zscale Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] fate: add tests for audio channel up-/downmixing with pan filter
On 27.07.2018 16:10, Nicolas George wrote: Tobias Rapp (2018-07-26): Add tests for upmixing and downmixing with audio channel counts that have a corresponding default layout and also tests where there is no default layout. Update the existing "stereo4" test so it actually outputs stereo like the other stereo tests. Rename the previous "stereo4" test into "upmix1". Signed-off-by: Tobias Rapp Looks reasonable. Applied, thanks for the review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] tests/audiogen: raise channel count limit to 12
On 27.07.2018 21:48, Michael Niedermayer wrote: On Thu, Jul 26, 2018 at 09:13:41AM +0200, Tobias Rapp wrote: Signed-off-by: Tobias Rapp --- tests/audiogen.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tests/audiogen.c b/tests/audiogen.c index 8d596b5..c43bb70 100644 --- a/tests/audiogen.c +++ b/tests/audiogen.c @@ -26,7 +26,7 @@ #include #include -#define MAX_CHANNELS 8 +#define MAX_CHANNELS 12 LGTM Applied, thanks for the review. Regards, Tobias ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
