Re: [FFmpeg-devel] [PATCH 2/2] libavformat: add WebP demuxer
On Wed, Jul 8, 2020 at 10:34 PM Carl Eugen Hoyos wrote:
> Am Mi., 8. Juli 2020 um 07:28 Uhr schrieb Josef Zlomek :
> >
> > Fixes: 4907
>
> It seems surprising that two commits should fix a ticket.
>
My understanding of ffmpeg internals is limited:
The parser is used for input from a pipe, the demuxer is used for input
from a file or other seekable streams.
I did not find out how parsers can set frame rate and time base of the
input stream so the playback speed is not correct.
The demuxer sets the frame rate and time base based on the information in
the input file. It also supports looping the input file.
> Adds support for demuxing of animated WebP.
>
> Does this demuxer also support single frame files?
> What about concatenated webps?
>
Non-animated/single frame files are still supported.
Concatenated files are also supported.
> +static int webp_probe(const AVProbeData *p)
> > +{
> > +const uint8_t *b = p->buf;
> > +
> > +if (p->filename && ff_guess_image2_codec(p->filename)) {
>
> Why is this useful?
>
This is a not very nice way to check that the input is from a file, and not
from a pipe.
Probably it will not be needed if demuxer uses ffio_ensure_seekback() as
you suggested below.
> +frame_end = avio_tell(pb);
> > +
> > +if (avio_seek(pb, frame_start, SEEK_SET) != frame_start)
> > +return AVERROR(EIO);
>
> Instead I believe you should use ffio_ensure_seekback() or do
>
I miss something?
>
I guess this will help to use the demuxer also for input from a pipe, right?
Then probably we could get rid of the parser and keep only the demuxer.
Josef
___
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] libavformat: add WebP demuxer
On Wed, Jul 8, 2020 at 10:04 AM Steven Liu wrote: > > (base) liuqi05:dash liuqi$ ./ffplay_g test.webp > [...] > Segmentation fault: 11 > (base) liuqi05:dash liuqi$ > The segfault was caused by the usage of unaligned buffers for frames. When using aligned buffers, it does not crash anymore. Thank you for finding this bug. -- Josef Zlomek ___ 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] libavformat: add WebP demuxer
Josef Zlomek (12020-07-08):
> Fixes: 4907
>
> Adds support for demuxing of animated WebP.
>
> The WebP demuxer splits the input stream into packets containing one frame.
> It also sets the timing information properly.
Thanks for the patch. A few comments.
>
> Signed-off-by: Josef Zlomek
> ---
> Changelog| 1 +
> doc/demuxers.texi| 28
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/version.h| 2 +-
> libavformat/webpdec.c| 322 +++
> 6 files changed, 354 insertions(+), 1 deletion(-)
> create mode 100644 libavformat/webpdec.c
>
> diff --git a/Changelog b/Changelog
> index 1e41040a8e..fc0bbdca45 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -6,6 +6,7 @@ version :
> - MacCaption demuxer
> - PGX decoder
> - animated WebP parser/decoder
> +- animated WebP demuxer
>
>
> version 4.3:
> diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> index 3c15ab9eee..9b5932308b 100644
> --- a/doc/demuxers.texi
> +++ b/doc/demuxers.texi
> @@ -832,4 +832,32 @@ which in turn, acts as a ceiling for the size of scripts
> that can be read.
> Default is 1 MiB.
> @end table
>
> +@section webp
> +
> +Animated WebP demuxer.
> +
> +It accepts the following options:
> +
> +@table @option
> +@item min_delay
> +Set the minimum valid delay between frames in milliseconds.
> +Range is 0 to 6. Default value is 10.
> +
> +@item max_webp_delay
> +Set the maximum valid delay between frames in milliseconds.
> +Range is 0 to 16777215. Default value is 16777215 (over four hours),
> +the maximum value allowed by the specification.
> +
> +@item default_delay
> +Set the default delay between frames in milliseconds.
> +Range is 0 to 6. Default value is 100.
Make these durations, with option type AV_OPT_TYPE_DURATION and internal
semantic in microseconds.
> +
> +@item ignore_loop
> +WebP files can contain information to loop a certain number of times (or
> +infinitely). If @option{ignore_loop} is set to 1, then the loop setting
> +from the input will be ignored and looping will not occur. If set to 0,
> +then looping will occur and will cycle the number of times according to
> +the WebP. Default value is 1.
Make it boolean.
Why default to true?
> +@end table
> +
> @c man end DEMUXERS
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 26af859a28..93793de45d 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -557,6 +557,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+= matroskaenc.o
> matroska.o \
> wv.o vorbiscomment.o
> OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
> OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
> +OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
> OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
> OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
> OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index f8527b1fd4..389273ea52 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -455,6 +455,7 @@ extern AVOutputFormat ff_webm_muxer;
> extern AVInputFormat ff_webm_dash_manifest_demuxer;
> extern AVOutputFormat ff_webm_dash_manifest_muxer;
> extern AVOutputFormat ff_webm_chunk_muxer;
> +extern AVInputFormat ff_webp_demuxer;
> extern AVOutputFormat ff_webp_muxer;
> extern AVInputFormat ff_webvtt_demuxer;
> extern AVOutputFormat ff_webvtt_muxer;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 75c03fde0a..33cebed85e 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> // Also please add any ticket numbers that you believe might be affected here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> -#define LIBAVFORMAT_VERSION_MINOR 48
> +#define LIBAVFORMAT_VERSION_MINOR 49
> #define LIBAVFORMAT_VERSION_MICRO 100
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
> new file mode 100644
> index 00..8d6e6df9c0
> --- /dev/null
> +++ b/libavformat/webpdec.c
> @@ -0,0 +1,322 @@
> +/*
> + * WebP demuxer
> + * Copyright (c) 2020 Pexeso Inc.
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You
Re: [FFmpeg-devel] Project orientation
Hi, Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis Stamatogiannakis: > On Tue, 7 Jul 2020 at 16:27, Nicolas George wrote: > > > Is tree threading that important? A PR is essentially a single thread of > > > discussion. > > > > It is a single thread of discussion until the discussion becomes complex > > and has branches. > > > > This doesn't sound like the common case. > But it should be straightforward to get some statistics on that from the > list archives when a transition is officially discussed. This whole current discussion here would be a lot more confusing without branches. Maybe you like the Gentoo approach: Do the majority of changes in pull requests, in Gentoo this are changes of packages, here it would be changes on codecs/demuxers/filters/etc. And then do all changes of the framework itself and discussions via mailinglist. In Gentoo this are changes of eclasses (i.e. code libraries for packages). For FFmpeg it would be the introduction of new API, API changes, decoupling or merging of libraries etc. The first is likely to produce no to little (conflicting) discussion, has a huge benefit from CI, is the part where most of the newcomers begin development and includes a lot of easy tasks. Here by far the most developments happens. The latter is likely to produce huge discussions, needs deep knowledge of the libraries, so it is not likely done by newcomers and has little gain from CI since it adds e.g. something completely new. Here happens not so much development in terms of frequency or code lines but the impact is much higher. Just a suggestion, since I follow both projects... Regards, Gerion ___ 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] libavformat: add WebP demuxer
Hi,
On Thu, Jul 9, 2020 at 11:44 AM Nicolas George wrote:
> Josef Zlomek (12020-07-08):
> > Fixes: 4907
> >
> > Adds support for demuxing of animated WebP.
> >
> > The WebP demuxer splits the input stream into packets containing one
> frame.
> > It also sets the timing information properly.
>
> Thanks for the patch. A few comments.
>
> >
> > Signed-off-by: Josef Zlomek
> > ---
> > Changelog| 1 +
> > doc/demuxers.texi| 28
> > libavformat/Makefile | 1 +
> > libavformat/allformats.c | 1 +
> > libavformat/version.h| 2 +-
> > libavformat/webpdec.c| 322 +++
> > 6 files changed, 354 insertions(+), 1 deletion(-)
> > create mode 100644 libavformat/webpdec.c
> >
> > diff --git a/Changelog b/Changelog
> > index 1e41040a8e..fc0bbdca45 100644
> > --- a/Changelog
> > +++ b/Changelog
> > @@ -6,6 +6,7 @@ version :
> > - MacCaption demuxer
> > - PGX decoder
> > - animated WebP parser/decoder
> > +- animated WebP demuxer
> >
> >
> > version 4.3:
> > diff --git a/doc/demuxers.texi b/doc/demuxers.texi
> > index 3c15ab9eee..9b5932308b 100644
> > --- a/doc/demuxers.texi
> > +++ b/doc/demuxers.texi
> > @@ -832,4 +832,32 @@ which in turn, acts as a ceiling for the size of
> scripts that can be read.
> > Default is 1 MiB.
> > @end table
> >
> > +@section webp
> > +
> > +Animated WebP demuxer.
> > +
> > +It accepts the following options:
> > +
> > +@table @option
>
> > +@item min_delay
> > +Set the minimum valid delay between frames in milliseconds.
> > +Range is 0 to 6. Default value is 10.
> > +
> > +@item max_webp_delay
> > +Set the maximum valid delay between frames in milliseconds.
> > +Range is 0 to 16777215. Default value is 16777215 (over four hours),
> > +the maximum value allowed by the specification.
> > +
> > +@item default_delay
> > +Set the default delay between frames in milliseconds.
> > +Range is 0 to 6. Default value is 100.
>
> Make these durations, with option type AV_OPT_TYPE_DURATION and internal
> semantic in microseconds.
>
> > +
> > +@item ignore_loop
> > +WebP files can contain information to loop a certain number of times (or
> > +infinitely). If @option{ignore_loop} is set to 1, then the loop setting
> > +from the input will be ignored and looping will not occur. If set to 0,
> > +then looping will occur and will cycle the number of times according to
> > +the WebP. Default value is 1.
>
> Make it boolean.
>
> Why default to true?
>
> > +@end table
> > +
> > @c man end DEMUXERS
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index 26af859a28..93793de45d 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -557,6 +557,7 @@ OBJS-$(CONFIG_WEBM_MUXER)+=
> matroskaenc.o matroska.o \
> > wv.o vorbiscomment.o
> > OBJS-$(CONFIG_WEBM_DASH_MANIFEST_MUXER) += webmdashenc.o
> > OBJS-$(CONFIG_WEBM_CHUNK_MUXER) += webm_chunk.o
> > +OBJS-$(CONFIG_WEBP_DEMUXER) += webpdec.o
> > OBJS-$(CONFIG_WEBP_MUXER)+= webpenc.o
> > OBJS-$(CONFIG_WEBVTT_DEMUXER)+= webvttdec.o subtitles.o
> > OBJS-$(CONFIG_WEBVTT_MUXER) += webvttenc.o
> > diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> > index f8527b1fd4..389273ea52 100644
> > --- a/libavformat/allformats.c
> > +++ b/libavformat/allformats.c
> > @@ -455,6 +455,7 @@ extern AVOutputFormat ff_webm_muxer;
> > extern AVInputFormat ff_webm_dash_manifest_demuxer;
> > extern AVOutputFormat ff_webm_dash_manifest_muxer;
> > extern AVOutputFormat ff_webm_chunk_muxer;
> > +extern AVInputFormat ff_webp_demuxer;
> > extern AVOutputFormat ff_webp_muxer;
> > extern AVInputFormat ff_webvtt_demuxer;
> > extern AVOutputFormat ff_webvtt_muxer;
> > diff --git a/libavformat/version.h b/libavformat/version.h
> > index 75c03fde0a..33cebed85e 100644
> > --- a/libavformat/version.h
> > +++ b/libavformat/version.h
> > @@ -32,7 +32,7 @@
> > // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> > // Also please add any ticket numbers that you believe might be
> affected here
> > #define LIBAVFORMAT_VERSION_MAJOR 58
> > -#define LIBAVFORMAT_VERSION_MINOR 48
> > +#define LIBAVFORMAT_VERSION_MINOR 49
> > #define LIBAVFORMAT_VERSION_MICRO 100
> >
> > #define LIBAVFORMAT_VERSION_INT
> AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> > diff --git a/libavformat/webpdec.c b/libavformat/webpdec.c
> > new file mode 100644
> > index 00..8d6e6df9c0
> > --- /dev/null
> > +++ b/libavformat/webpdec.c
> > @@ -0,0 +1,322 @@
> > +/*
> > + * WebP demuxer
> > + * Copyright (c) 2020 Pexeso Inc.
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at y
[FFmpeg-devel] [PATCH 3/7] avformat/sdp: Fix potential write beyond end of buffer
Signed-off-by: Andreas Rheinhardt
---
libavformat/sdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 34e9839b67..2ce1a62262 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -212,7 +212,7 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
p += strlen(p);
r = r1;
}
-if (sps && sps_end - sps >= 4) {
+if (sps && sps_end - sps >= 4 && p - psets <= MAX_PSET_SIZE -
strlen(profile_string) - 7) {
memcpy(p, profile_string, strlen(profile_string));
p += strlen(p);
ff_data_to_hex(p, sps + 1, 3, 0);
--
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".
[FFmpeg-devel] [PATCH 4/7] avformat/mm: Check for existence of audio stream
No audio stream is created unconditionally and if none has been created, no packet with stream_index 1 may be returned. This fixes an assert in ff_read_packet() in libavformat/utils reported in ticket #8782. Signed-off-by: Andreas Rheinhardt --- libavformat/mm.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavformat/mm.c b/libavformat/mm.c index d40fd12acc..02ffbcd824 100644 --- a/libavformat/mm.c +++ b/libavformat/mm.c @@ -175,6 +175,8 @@ static int read_packet(AVFormatContext *s, return 0; case MM_TYPE_AUDIO : +if (s->nb_streams < 2) +return AVERROR_INVALIDDATA; if ((ret = av_get_packet(s->pb, pkt, length)) < 0) return ret; pkt->stream_index = 1; -- 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".
[FFmpeg-devel] [PATCH 6/7] avformat/sdp: Store strings instead of pointers to strings in array
Signed-off-by: Andreas Rheinhardt
---
libavformat/sdp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 3acbf5d197..aa0569cd0d 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -231,7 +231,7 @@ static char *extradata2psets_hevc(AVCodecParameters *par)
int extradata_size = par->extradata_size;
AVIOContext *pb = NULL;
int ps_pos[3] = { 0 };
-static const char * const ps_names[3] = { "vps", "sps", "pps" };
+static const char ps_names[3][4] = { "vps", "sps", "pps" };
int num_arrays, num_nalus;
int pos, i, j;
--
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".
[FFmpeg-devel] [PATCH 5/7] avformat/sdp: Avoid allocation for small HEVC annex B extradata
In this case, extradata2psets_hevc would have used avio_open_dyn_buf() +
avio_close_dyn_buf() to convert the annex B extradata to the hvcc format
(which is easier parseable); the temporary buffer would then be freed.
avio_close_dyn_buf() + av_free() can be replaced by avio_get_dyn_buf() +
ffio_free_dyn_buf(). This saves an allocation and a memcpy if the hvcc
is so small that it fits into the dynamic buffer's write buffer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/sdp.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 2ce1a62262..3acbf5d197 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -27,6 +27,7 @@
#include "libavcodec/xiph.h"
#include "libavcodec/mpeg4audio.h"
#include "avformat.h"
+#include "avio_internal.h"
#include "internal.h"
#include "avc.h"
#include "hevc.h"
@@ -228,7 +229,7 @@ static char *extradata2psets_hevc(AVCodecParameters *par)
char *psets;
uint8_t *extradata = par->extradata;
int extradata_size = par->extradata_size;
-uint8_t *tmpbuf = NULL;
+AVIOContext *pb = NULL;
int ps_pos[3] = { 0 };
static const char * const ps_names[3] = { "vps", "sps", "pps" };
int num_arrays, num_nalus;
@@ -239,15 +240,12 @@ static char *extradata2psets_hevc(AVCodecParameters *par)
// other anyway, we get away with a little less work by using the hvcc
// format.
if (par->extradata[0] != 1) {
-AVIOContext *pb;
if (avio_open_dyn_buf(&pb) < 0)
return NULL;
if (ff_isom_write_hvcc(pb, par->extradata, par->extradata_size, 0) <
0) {
-avio_close_dyn_buf(pb, &tmpbuf);
goto err;
}
-extradata_size = avio_close_dyn_buf(pb, &extradata);
-tmpbuf = extradata;
+extradata_size = avio_get_dyn_buf(pb, &extradata);
}
if (extradata_size < 23)
@@ -315,12 +313,12 @@ static char *extradata2psets_hevc(AVCodecParameters *par)
pos += len;
}
}
-av_free(tmpbuf);
+ffio_free_dyn_buf(&pb);
return psets;
err:
-av_free(tmpbuf);
+ffio_free_dyn_buf(&pb);
return NULL;
}
--
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".
[FFmpeg-devel] [PATCH 2/7] avformat/avc: Fix undefined pointer arithmetic for small buffers
avc_find_startcode_internal() would subtract 6 from a pointer
(representing the end of a buffer) without checking whether the buffer
was actually large enough; but pointer arithmetic is undefined except
when one stays in the buffer.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 55494eb08a..cc92fb1038 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -44,14 +44,15 @@ static inline unsigned get_ue_golomb(GetBitContext *gb)
static const uint8_t *avc_find_startcode_internal(const uint8_t *p, const
uint8_t *end)
{
-const uint8_t *a = p + 4 - ((intptr_t)p & 3);
+if (end - p <= 5)
+goto rest;
-for (end -= 3; p < a && p < end; p++) {
+for (; (uintptr_t)p & 3; p++) {
if (p[0] == 0 && p[1] == 0 && p[2] == 1)
return p;
}
-for (end -= 3; p < end; p += 4) {
+for (end -= 6; p < end; p += 4) {
uint32_t x = *(const uint32_t*)p;
// if ((x - 0x01000100) & (~x) & 0x80008000) // little endian
// if ((x - 0x00010001) & (~x) & 0x00800080) // big endian
@@ -70,13 +71,15 @@ static const uint8_t *avc_find_startcode_internal(const
uint8_t *p, const uint8_
}
}
}
+end += 6;
-for (end += 3; p < end; p++) {
+rest:
+for (; end - p > 3; p++) {
if (p[0] == 0 && p[1] == 0 && p[2] == 1)
return p;
}
-return end + 3;
+return end;
}
const uint8_t *ff_avc_find_startcode(const uint8_t *p, const uint8_t *end){
--
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".
[FFmpeg-devel] [PATCH 7/7] avformat/sdp: Actually check that parameter set is SPS
Signed-off-by: Andreas Rheinhardt
---
libavformat/sdp.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index aa0569cd0d..023c88a583 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -24,6 +24,7 @@
#include "libavutil/dict.h"
#include "libavutil/parseutils.h"
#include "libavutil/opt.h"
+#include "libavcodec/h264.h"
#include "libavcodec/xiph.h"
#include "libavcodec/mpeg4audio.h"
#include "avformat.h"
@@ -161,7 +162,7 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
uint8_t *extradata = par->extradata;
int extradata_size = par->extradata_size;
uint8_t *tmpbuf = NULL;
-const uint8_t *sps = NULL, *sps_end;
+const uint8_t *sps = NULL;
if (par->extradata_size > MAX_EXTRADATA_SIZE) {
av_log(s, AV_LOG_ERROR, "Too much extradata!\n");
@@ -199,10 +200,9 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
*p = ',';
p++;
}
-if (!sps) {
+if (nal_type == H264_NAL_SPS && !sps && r1 - r >= 4)
sps = r;
-sps_end = r1;
-}
+
if (!av_base64_encode(p, MAX_PSET_SIZE - (p - psets), r, r1 - r)) {
av_log(s, AV_LOG_ERROR, "Cannot Base64-encode %"PTRDIFF_SPECIFIER"
%"PTRDIFF_SPECIFIER"!\n", MAX_PSET_SIZE - (p - psets), r1 - r);
av_free(psets);
@@ -213,7 +213,7 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
p += strlen(p);
r = r1;
}
-if (sps && sps_end - sps >= 4 && p - psets <= MAX_PSET_SIZE -
strlen(profile_string) - 7) {
+if (sps && p - psets <= MAX_PSET_SIZE - strlen(profile_string) - 7) {
memcpy(p, profile_string, strlen(profile_string));
p += strlen(p);
ff_data_to_hex(p, sps + 1, 3, 0);
--
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 2/2] libavformat: add WebP demuxer
On Thu, Jul 9, 2020 at 11:44 AM Nicolas George wrote:
> Josef Zlomek (12020-07-08):
>
> > +@item min_delay
> > +Set the minimum valid delay between frames in milliseconds.
> > +Range is 0 to 6. Default value is 10.
> > +
> > +@item max_webp_delay
> > +Set the maximum valid delay between frames in milliseconds.
> > +Range is 0 to 16777215. Default value is 16777215 (over four hours),
> > +the maximum value allowed by the specification.
> > +
> > +@item default_delay
> > +Set the default delay between frames in milliseconds.
> > +Range is 0 to 6. Default value is 100.
>
> Make these durations, with option type AV_OPT_TYPE_DURATION and internal
> semantic in microseconds.
>
OK.
> +@item ignore_loop
> > +WebP files can contain information to loop a certain number of times (or
> > +infinitely). If @option{ignore_loop} is set to 1, then the loop setting
> > +from the input will be ignored and looping will not occur. If set to 0,
> > +then looping will occur and will cycle the number of times according to
> > +the WebP. Default value is 1.
>
> Make it boolean.
>
OK. I have just copied the options from gif demuxer.
Why default to true?
>
The loop count in the WebP files is usually 0 = forever.
If decoding/transcoding the file, people probably do not want to loop the
file forever, exhausting the disk capacity.
Also when reading from pipe, the whole file would have to be buffered in
memory to be able to loop.
So in my opinion, it is better to ignore loop count by default. Also gif
demuxer ignores loop by default..
> +while (1) {
> > +chunk_type = avio_rl32(pb);
> > +chunk_size = avio_rl32(pb);
> > +if (chunk_size == UINT32_MAX)
> > +return AVERROR_INVALIDDATA;
> > +chunk_size += chunk_size & 1;
>
> chunk_size needs to be validated better than that. Otherwise,
> chunk_size-10 or such can underflow and that could be bad.
>
Here it is just a validation that chunk_size will not overflow when making
it even.
I will add validations to the cases of the switch statement below.
> +if (avio_feof(pb))
> > +break;
> > +
> > +switch (chunk_type) {
> > +case MKTAG('V', 'P', '8', 'X'):
> > +avio_skip(pb, 4);
> > +width = avio_rl24(pb) + 1;
> > +height = avio_rl24(pb) + 1;
> > +break;
> > +case MKTAG('V', 'P', '8', ' '):
> > +avio_skip(pb, 6);
> > +width = avio_rl16(pb) & 0x3fff;
> > +height = avio_rl16(pb) & 0x3fff;
> > +duration += wdc->delay;
> > +nb_frames++;
> > +avio_skip(pb, chunk_size - 10);
> > +break;
> > +case MKTAG('V', 'P', '8', 'L'):
> > +avio_skip(pb, 1);
> > +n = avio_rl32(pb);
> > +width = (n & 0x3fff) + 1; /* first 14 bits */
> > +height = ((n >> 14) & 0x3fff) + 1; /* next 14 bits */
> > +duration += wdc->delay;
> > +nb_frames++;
> > +avio_skip(pb, chunk_size - 5);
> > +break;
> > +case MKTAG('A', 'N', 'M', 'F'):
> > +avio_skip(pb, 6);
> > +width = avio_rl24(pb) + 1;
> > +height = avio_rl24(pb) + 1;
> > +wdc->delay = avio_rl24(pb);
> > +if (wdc->delay < wdc->min_delay)
> > +wdc->delay = wdc->default_delay;
> > +wdc->delay = FFMIN(wdc->delay, wdc->max_delay);
> > +duration += wdc->delay;
> > +nb_frames++;
> > +avio_skip(pb, chunk_size - 15);
> > +break;
> > +default:
> > +avio_skip(pb, chunk_size);
> > +}
>
[...]
> +pkt->stream_index = 0;
> > +pkt->duration = is_frame ? wdc->delay : 0;
>
> What is the packet, if it is not a frame?
>
It may be metadata (chunk "XMP " or "EXIF") or garbage at the end of the
file.
--
Josef
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hls: Use probing parameters for actual stream
Hi, Could someone please take a look at this? It's a pretty small fix and it has been sitting in the queue since March. Best Regards, Jacek pon., 16 mar 2020 o 11:54 Jacek Tomasiak napisał(a): > HLS input streams ignored CLI parameters which control the probing > process. Each stream was initialized with fresh context and used > the default values for probing. > --- > libavformat/hls.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/libavformat/hls.c b/libavformat/hls.c > index 1f58e745a7..5954b1d2d9 100644 > --- a/libavformat/hls.c > +++ b/libavformat/hls.c > @@ -1919,6 +1919,14 @@ static int hls_read_header(AVFormatContext *s) > pls->needed = 1; > pls->parent = s; > > +/* Pass top-level probing parameters to actual stream */ > +pls->ctx->probesize = s->probesize; > +pls->ctx->format_probesize = s->format_probesize; > +pls->ctx->max_analyze_duration = s->max_analyze_duration; > +pls->ctx->fps_probe_size = s->fps_probe_size; > +pls->ctx->max_ts_probe = s->max_ts_probe; > +pls->ctx->max_probe_packets = s->max_probe_packets; > + > /* > * If this is a live stream and this playlist looks like it is > one segment > * behind, try to sync it up so that every substream starts at > the same > -- > 2.16.4 > > -- | PZDR Jacek aka SkaZi \\ | mail: jacek.tomas...@gmail.com "Oset nie ma zadnego /O `. | XMPP/Jabber: sk...@tomasiak.pl pozytku z tego, ze * (_.-. )\ | sie na nim siedzi..." *|* rs //--// X ___ 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] Project orientation
Thanks Gerion. This sounds more or less like what I had in mind (but I was trying to keep it short). – The present thread is a non-technical discussion, and branching indeed helps. The mailing list is perfect for this kind of discussions. – Patches with narrow scope are focused, technical discussion, which is unlikely to branch. They can be dispatched and discussed directly as a PR, either via the web interface or email. This should keep this list more focused. – Patches that involve deeper changes can be discussed before materializing in a PR, in whatever way core developers prefer. To be clear, by no means I am in favour of deprecating the mailing list. PRs and Issues are not a panacea. E.g. asking questions by opening issues on GH/GL is something I would frown upon (and I have seen happening elsewhere). Best regards, Manolis On Thu, 9 Jul 2020 at 12:27, Gerion Entrup wrote: > Hi, > > Am Donnerstag, 9. Juli 2020, 02:56:28 CEST schrieb Manolis > Stamatogiannakis: > > On Tue, 7 Jul 2020 at 16:27, Nicolas George wrote: > > > > Is tree threading that important? A PR is essentially a single > thread of > > > > discussion. > > > > > > It is a single thread of discussion until the discussion becomes > complex > > > and has branches. > > > > > > > This doesn't sound like the common case. > > But it should be straightforward to get some statistics on that from the > > list archives when a transition is officially discussed. > > This whole current discussion here would be a lot more confusing without > branches. > > Maybe you like the Gentoo approach: Do the majority of changes in pull > requests, in Gentoo this are changes of packages, here it would be > changes on codecs/demuxers/filters/etc. And then do all changes of the > framework itself and discussions via mailinglist. In Gentoo this are > changes of eclasses (i.e. code libraries for packages). For FFmpeg it > would be the introduction of new API, API changes, decoupling or merging > of libraries etc. > > The first is likely to produce no to little (conflicting) discussion, > has a huge benefit from CI, is the part where most of the newcomers begin > development and includes a lot of easy tasks. Here by far the most > developments happens. > > The latter is likely to produce huge discussions, needs deep knowledge > of the libraries, so it is not likely done by newcomers and has little > gain from CI since it adds e.g. something completely new. Here happens > not so much development in terms of frequency or code lines but the > impact is much higher. > > Just a suggestion, since I follow both projects... > > Regards, > Gerion > > > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/7] avformat/avc: Fix undefined shift and assert when reading exp-golomb num
The current code for parsing unsigned exponential-golomb codes is not
suitable for long codes: If there are enough leading zeroes, it
left-shifts 1 by 32 places and uses get_bitsz to read 32 bits, although
it is only suitable to read 0-25 bits. There is an av_assert2 to
ensure this when using the uncached bitstream reader; with valid input
one can still run into the assert and left-shift 1 by 31 which is
undefined.
This commit changes this. All valid data is parsed correctly; invalid
data does no longer lead to undefined behaviour or to asserts. Parsing
all valid data correctly also necessitated changing the return value to
unsigned; also an intermediate variable used for parsing signed
exponential-golomb codes needed to be made unsigned, too, in order to
parse long signed codes correctly.
Signed-off-by: Andreas Rheinhardt
---
Moving the function to the beginning is done in preparation for another
commit that I'll send soon.
libavformat/avc.c | 24
1 file changed, 16 insertions(+), 8 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index b5e2921388..55494eb08a 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -27,6 +27,21 @@
#include "avc.h"
#include "avio_internal.h"
+static inline unsigned get_ue_golomb(GetBitContext *gb)
+{
+int i;
+for (i = 1; i <= 32; i++) {
+if (get_bits_left(gb) < i)
+return 0;
+if (show_bits1(gb))
+break;
+skip_bits1(gb);
+}
+if (i > 32)
+return 0;
+return get_bits_long(gb, i) - 1;
+}
+
static const uint8_t *avc_find_startcode_internal(const uint8_t *p, const
uint8_t *end)
{
const uint8_t *a = p + 4 - ((intptr_t)p & 3);
@@ -318,15 +333,8 @@ static const AVRational avc_sample_aspect_ratio[17] = {
{ 2, 1 },
};
-static inline int get_ue_golomb(GetBitContext *gb) {
-int i;
-for (i = 0; i < 32 && !get_bits1(gb); i++)
-;
-return get_bitsz(gb, i) + (1 << i) - 1;
-}
-
static inline int get_se_golomb(GetBitContext *gb) {
-int v = get_ue_golomb(gb) + 1;
+unsigned v = get_ue_golomb(gb) + 1;
int sign = -(v & 1);
return ((v >> 1) ^ sign) - sign;
}
--
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] libavformat/dashenc.c:support mpd update period
On 7/9/2020 3:01 AM, Jeyapal, Karthick wrote:
> Pushed the patch, with minor change to commit message.
>
> Thanks,
> Karthick
> On 6/30/20 11:14 AM, Siyuan Huang wrote:
>> Update with no file mode changes :
>>
>>
>>
>> From 818095d4f0aa50dfee3cb0622146a2180801c5fe Mon Sep 17 00:00:00 2001
>>
>> From: Siyuan Huang
>>
>> Date: Tue, 30 Jun 2020 13:41:46 +0800
>>
>> Subject: [PATCH] libavformat/dashenc.c:support mpd update period v3
>>
>>
>>
>> according iso 23009-1 , in live cases , mpd refresh
>>
>> period should be changeable
>>
>>
>>
>> Signed-off-by: Siyuan Huang
>>
>> ---
>>
>> doc/muxers.texi | 4
>>
>> libavformat/dashenc.c | 4
>>
>> 2 files changed, 8 insertions(+)
>>
>>
>>
>> diff --git a/doc/muxers.texi b/doc/muxers.texi
>>
>> index b1389a3227..86976f4f61 100644
>>
>> --- a/doc/muxers.texi
>>
>> +++ b/doc/muxers.texi
>>
>> @@ -366,6 +366,10 @@ adjusting playback latency and buffer occupancy during
>> normal playback by client
>>
>> Set the maximum playback rate indicated as appropriate for the purposes of
>> automatically
>>
>> adjusting playback latency and buffer occupancy during normal playback by
>> clients.
>>
>> +@item update_period @var{update_period}
>>
>> + Set the mpd update period ,for dynamic content.
>>
>> + The unit is second.
>>
>> +
>>
>> @end table
>>
>> @anchor{framecrc}
>>
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>>
>> index 62193058d7..dc3306a56a 100644
>>
>> --- a/libavformat/dashenc.c
>>
>> +++ b/libavformat/dashenc.c
>>
>> @@ -198,6 +198,7 @@ typedef struct DASHContext {
>>
>> int target_latency_refid;
>>
>> AVRational min_playback_rate;
>>
>> AVRational max_playback_rate;
>>
>> +int64_t update_period;
>>
>> } DASHContext;
>>
>> static struct codec_string {
>>
>> @@ -1184,6 +1185,8 @@ static int write_manifest(AVFormatContext *s, int
>> final)
>>
>> char now_str[100];
>>
>> if (c->use_template && !c->use_timeline)
>>
>> update_period = 500;
>>
>> +if (c->update_period)
>>
>> +update_period = c->update_period;
>>
>> avio_printf(out, "\tminimumUpdatePeriod=\"PT%"PRId64"S\"\n",
>> update_period);
Since update_period is now configurable, the option should be of type
AV_OPT_TYPE_DURATION and this line changed to use write_time() to get
the correct format that denotes hours, minutes, seconds, etc.
>>
>> if (!c->ldash)
>>
>> avio_printf(out,
>> "\tsuggestedPresentationDelay=\"PT%"PRId64"S\"\n", c->last_duration /
>> AV_TIME_BASE);
>>
>> @@ -2380,6 +2383,7 @@ static const AVOption options[] = {
>>
>> { "target_latency", "Set desired target latency for Low-latency dash",
>> OFFSET(target_latency), AV_OPT_TYPE_DURATION, { .i64 = 0 }, 0, INT_MAX, E },
>>
>> { "min_playback_rate", "Set desired minimum playback rate",
>> OFFSET(min_playback_rate), AV_OPT_TYPE_RATIONAL, { .dbl = 1.0 }, 0.5, 1.5, E
>> },
>>
>> { "max_playback_rate", "Set desired maximum playback rate",
>> OFFSET(max_playback_rate), AV_OPT_TYPE_RATIONAL, { .dbl = 1.0 }, 0.5, 1.5, E
>> },
>>
>> +{ "update_period", "Set the mpd update interval",
>> OFFSET(update_period), AV_OPT_TYPE_INT64, {.i64 = 0}, 0, INT64_MAX, E},
>>
>> { NULL },
>>
>> };
>>
>>
>> ___
>> 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=4YPMEclN8LjEF9ay98BehLzHoqtCqzgK4hxGam47mRQ&s=5Xpoq0cZZUGetVqh7mK1Wpmgm1JwFfS8cH8wVHYwpuk&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".
>
___
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 3/3] x86/vf_blend: fix warnings about trailing empty parameters
Signed-off-by: James Almer --- libavfilter/x86/vf_blend.asm | 90 ++-- 1 file changed, 45 insertions(+), 45 deletions(-) diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm index 251bbb5a12..77a6ed04c7 100644 --- a/libavfilter/x86/vf_blend.asm +++ b/libavfilter/x86/vf_blend.asm @@ -38,7 +38,7 @@ pb_255: times 16 db 255 SECTION .text -%macro BLEND_INIT 2-3 +%macro BLEND_INIT 2 %if ARCH_X86_64 cglobal blend_%1, 6, 9, %2, top, top_linesize, bottom, bottom_linesize, dst, dst_linesize, width, end, x movwidthd, dword widthm @@ -66,8 +66,8 @@ cglobal blend_%1, 5, 7, %2, top, top_linesize, bottom, bottom_linesize, dst, end REP_RET %endmacro -%macro BLEND_SIMPLE 2-3 -BLEND_INIT %1, 2, %3 +%macro BLEND_SIMPLE 2 +BLEND_INIT %1, 2 .nextrow: movxq, widthq @@ -82,8 +82,8 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro GRAINEXTRACT 3-4 -BLEND_INIT %1, 6, %4 +%macro GRAINEXTRACT 3 +BLEND_INIT %1, 6 pxor m4, m4 %if %0 == 4 ; 16 bit VBROADCASTI128 m5, [pd_32768] @@ -182,8 +182,8 @@ BLEND_END %endmacro ;%1 name, %2 (b or w), %3 (set if 16 bit) -%macro AVERAGE 2-3 -BLEND_INIT %1, 3, %3 +%macro AVERAGE 2 +BLEND_INIT %1, 3 pcmpeqbm2, m2 .nextrow: @@ -203,8 +203,8 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro GRAINMERGE 3-4 -BLEND_INIT %1, 6, %4 +%macro GRAINMERGE 3 +BLEND_INIT %1, 6 pxor m4, m4 %if %0 == 4 ; 16 bit VBROADCASTI128 m5, [pd_32768] @@ -288,9 +288,9 @@ BLEND_INIT divide, 4 BLEND_END %endmacro -%macro PHOENIX 2-3 +%macro PHOENIX 2 ; %1 name, %2 b or w, %3 (opt) 1 if 16 bit -BLEND_INIT %1, 4, %3 +BLEND_INIT %1, 4 VBROADCASTI128 m3, [pb_255] .nextrow: movxq, widthq @@ -311,8 +311,8 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro DIFFERENCE 3-4 -BLEND_INIT %1, 5, %4 +%macro DIFFERENCE 3 +BLEND_INIT %1, 5 pxor m2, m2 .nextrow: movxq, widthq @@ -340,8 +340,8 @@ BLEND_END %endmacro ; %1 name , %2 src (b or w), %3 inter (w or d), %4 (1 if 16bit, not set if 8 bit) -%macro EXTREMITY 3-4 -BLEND_INIT %1, 8, %4 +%macro EXTREMITY 3 +BLEND_INIT %1, 8 pxor m2, m2 %if %0 == 4; 16 bit VBROADCASTI128 m4, [pd_65535] @@ -375,8 +375,8 @@ BLEND_INIT %1, 8, %4 BLEND_END %endmacro -%macro NEGATION 3-4 -BLEND_INIT %1, 8, %4 +%macro NEGATION 3 +BLEND_INIT %1, 8 pxor m2, m2 %if %0 == 4; 16 bit VBROADCASTI128 m4, [pd_65535] @@ -433,12 +433,12 @@ EXTREMITY extremity, b, w NEGATION negation, b, w %if ARCH_X86_64 -BLEND_SIMPLE addition_16, addusw, 1 -BLEND_SIMPLE and_16, and,1 -BLEND_SIMPLE or_16, or, 1 -BLEND_SIMPLE subtract_16, subusw, 1 -BLEND_SIMPLE xor_16, xor,1 -AVERAGE average_16, w, 1 +BLEND_SIMPLE addition_16, addusw +BLEND_SIMPLE and_16, and +BLEND_SIMPLE or_16, or +BLEND_SIMPLE subtract_16, subusw +BLEND_SIMPLE xor_16, xor +AVERAGE average_16, w %endif INIT_XMM ssse3 @@ -448,14 +448,14 @@ NEGATION negation, b, w INIT_XMM sse4 %if ARCH_X86_64 -BLEND_SIMPLE darken_16, minuw, 1 -BLEND_SIMPLE lighten_16, maxuw, 1 -GRAINEXTRACT grainextract_16, w, d, 1 -GRAINMERGE grainmerge_16, w, d, 1 -PHOENIX phoenix_16, w, 1 -DIFFERENCE difference_16, w, d, 1 -EXTREMITYextremity_16, w, d, 1 -NEGATION negation_16, w, d, 1 +BLEND_SIMPLE darken_16, minuw +BLEND_SIMPLE lighten_16, maxuw +GRAINEXTRACT grainextract_16, w, d +GRAINMERGE grainmerge_16, w, d +PHOENIX phoenix_16, w +DIFFERENCE difference_16, w, d +EXTREMITYextremity_16, w, d +NEGATION negation_16, w, d %endif %if HAVE_AVX2_EXTERNAL @@ -480,19 +480,19 @@ EXTREMITY extremity, b, w NEGATION negation, b, w %if ARCH_X86_64 -BLEND_SIMPLE addition_16, addusw, 1 -BLEND_SIMPLE and_16, and,1 -BLEND_SIMPLE darken_16, minuw, 1 -BLEND_SIMPLE lighten_16, maxuw, 1 -BLEND_SIMPLE or_16, or, 1 -BLEND_SIMPLE subtract_16, subusw, 1 -BLEND_SIMPLE xor_16, xor,1 -GRAINEXTRACT grainextract_16, w, d, 1 -AVERAGE average_16, w, 1 -GRAINMERGE grainmerge_16, w, d, 1 -PHOENIX phoenix_16, w, 1 -DIFFERENCE difference_16, w, d, 1 -EXTREMITYextremity_16, w, d, 1 -NEGATION negation_16, w, d, 1 +BLEND_SIMPLE addition_16, addusw +BLEND_SIMPLE and_16, and +BLEND_SIMPLE darken_16, minuw +BLEND_SIMPLE lighten_16, maxuw +BLEND_SIMPLE or_16, or +BLEND_SIMPLE subtract_16, subusw +BLEND_SIMPLE xor_16, xor +GRAINEXTRACT grainextract_16, w, d +AVERAGE average_16, w +GRAINMERGE grainmerge_16, w, d +PHOENIX phoenix_16, w +DIFFERENCE difference_16, w, d +EXTREMITYextremity_16, w, d +NEGATION negation_16, w, d %endif %endif -- 2.27
[FFmpeg-devel] [PATCH 2/3] x86/h264_deblock: fix warnings about trailing empty parameters
Signed-off-by: James Almer --- libavcodec/x86/h264_deblock.asm | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/x86/h264_deblock.asm b/libavcodec/x86/h264_deblock.asm index 6702ae98d4..a2e745cd8e 100644 --- a/libavcodec/x86/h264_deblock.asm +++ b/libavcodec/x86/h264_deblock.asm @@ -1185,7 +1185,7 @@ cglobal deblock_h_chroma_8, 5, 7, 8, 0-16, pix_, stride_, alpha_, beta_, tc0_ STORE_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6) RET -cglobal deblock_h_chroma422_8, 5, 7, 8, 0-16, pix_, stride_, alpha_, beta_, tc0_, +cglobal deblock_h_chroma422_8, 5, 7, 8, 0-16, pix_, stride_, alpha_, beta_, tc0_ CHROMA_H_START_XMM r5, r6 LOAD_8_ROWS PASS8ROWS(pix_q - 2, r5 - 2, stride_q, r6) TRANSPOSE_8x4B_XMM -- 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".
[FFmpeg-devel] [PATCH 1/3] avutil/x86inc: fix warnings when assembling with Nasm 2.15
From: Henrik Gramner Some new warnings regarding use of empty macro parameters has been added, so adjust some x86inc code to silence those Signed-off-by: James Almer --- libavutil/x86/x86inc.asm | 46 ++-- 1 file changed, 30 insertions(+), 16 deletions(-) diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm index 5044ee86f0..01c35e3a4b 100644 --- a/libavutil/x86/x86inc.asm +++ b/libavutil/x86/x86inc.asm @@ -411,16 +411,6 @@ DECLARE_REG_TMP_SIZE 0,1,2,3,4,5,6,7,8,9,10,11,12,13,14 %endif %endmacro -%macro DEFINE_ARGS_INTERNAL 3+ -%ifnum %2 -DEFINE_ARGS %3 -%elif %1 == 4 -DEFINE_ARGS %2 -%elif %1 > 4 -DEFINE_ARGS %2, %3 -%endif -%endmacro - %if WIN64 ; Windows x64 ;= DECLARE_REG 0, rcx @@ -439,7 +429,7 @@ DECLARE_REG 12, R15, 104 DECLARE_REG 13, R12, 112 DECLARE_REG 14, R13, 120 -%macro PROLOGUE 2-5+ 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names... +%macro PROLOGUE 2-5+ 0, 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names... %assign num_args %1 %assign regs_used %2 ASSERT regs_used >= num_args @@ -451,7 +441,15 @@ DECLARE_REG 14, R13, 120 WIN64_SPILL_XMM %3 %endif LOAD_IF_USED 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 -DEFINE_ARGS_INTERNAL %0, %4, %5 +%if %0 > 4 +%ifnum %4 +DEFINE_ARGS %5 +%else +DEFINE_ARGS %4, %5 +%endif +%elifnnum %4 +DEFINE_ARGS %4 +%endif %endmacro %macro WIN64_PUSH_XMM 0 @@ -547,7 +545,7 @@ DECLARE_REG 12, R15, 56 DECLARE_REG 13, R12, 64 DECLARE_REG 14, R13, 72 -%macro PROLOGUE 2-5+ 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names... +%macro PROLOGUE 2-5+ 0, 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names... %assign num_args %1 %assign regs_used %2 %assign xmm_regs_used %3 @@ -557,7 +555,15 @@ DECLARE_REG 14, R13, 72 PUSH_IF_USED 9, 10, 11, 12, 13, 14 ALLOC_STACK %4 LOAD_IF_USED 6, 7, 8, 9, 10, 11, 12, 13, 14 -DEFINE_ARGS_INTERNAL %0, %4, %5 +%if %0 > 4 +%ifnum %4 +DEFINE_ARGS %5 +%else +DEFINE_ARGS %4, %5 +%endif +%elifnnum %4 +DEFINE_ARGS %4 +%endif %endmacro %define has_epilogue regs_used > 9 || stack_size > 0 || vzeroupper_required @@ -598,7 +604,7 @@ DECLARE_REG 6, ebp, 28 DECLARE_ARG 7, 8, 9, 10, 11, 12, 13, 14 -%macro PROLOGUE 2-5+ ; #args, #regs, #xmm_regs, [stack_size,] arg_names... +%macro PROLOGUE 2-5+ 0, 0 ; #args, #regs, #xmm_regs, [stack_size,] arg_names... %assign num_args %1 %assign regs_used %2 ASSERT regs_used >= num_args @@ -613,7 +619,15 @@ DECLARE_ARG 7, 8, 9, 10, 11, 12, 13, 14 PUSH_IF_USED 3, 4, 5, 6 ALLOC_STACK %4 LOAD_IF_USED 0, 1, 2, 3, 4, 5, 6 -DEFINE_ARGS_INTERNAL %0, %4, %5 +%if %0 > 4 +%ifnum %4 +DEFINE_ARGS %5 +%else +DEFINE_ARGS %4, %5 +%endif +%elifnnum %4 +DEFINE_ARGS %4 +%endif %endmacro %define has_epilogue regs_used > 3 || stack_size > 0 || vzeroupper_required -- 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".
[FFmpeg-devel] [PATCH 1/7] lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding
Version bump would be added when upstreamed.
Signed-off-by: Linjie Fu
---
libavcodec/avcodec.h | 1 +
libavcodec/hevc_ps.c | 2 ++
libavcodec/profiles.c | 1 +
3 files changed, 4 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c91b2fd..32e4770 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1948,6 +1948,7 @@ typedef struct AVCodecContext {
#define FF_PROFILE_HEVC_MAIN_10 2
#define FF_PROFILE_HEVC_MAIN_STILL_PICTURE 3
#define FF_PROFILE_HEVC_REXT4
+#define FF_PROFILE_HEVC_SCC 9
#define FF_PROFILE_AV1_MAIN 0
#define FF_PROFILE_AV1_HIGH 1
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index ea6fd53..584e2ba 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -281,6 +281,8 @@ static int decode_profile_tier_level(GetBitContext *gb,
AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Main Still Picture profile bitstream\n");
else if (ptl->profile_idc == FF_PROFILE_HEVC_REXT)
av_log(avctx, AV_LOG_DEBUG, "Range Extension profile bitstream\n");
+else if (ptl->profile_idc == FF_PROFILE_HEVC_SCC)
+av_log(avctx, AV_LOG_DEBUG, "Screen Content Coding Extension profile
bitstream\n");
else
av_log(avctx, AV_LOG_WARNING, "Unknown HEVC profile: %d\n",
ptl->profile_idc);
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index e59a3a5..e815b90 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -79,6 +79,7 @@ const AVProfile ff_hevc_profiles[] = {
{ FF_PROFILE_HEVC_MAIN_10, "Main 10" },
{ FF_PROFILE_HEVC_MAIN_STILL_PICTURE, "Main Still Picture" },
{ FF_PROFILE_HEVC_REXT, "Rext"},
+{ FF_PROFILE_HEVC_SCC, "Scc" },
{ FF_PROFILE_UNKNOWN },
};
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/7] HEVC native support for Screen content coding
As a part of the support for VA-API HEVC SCC decoding (gen12, Tiger Lake+). The full support could be accessed in: https://github.com/intel-media-ci/ffmpeg/pull/231 The VAAPI part would be provided later once the implementations of native parsing and reference management are all decent. [Request for comment]. Linjie Fu (7): lavc/avcodec: Add FF_PROFILE_HEVC_SCC for screen content coding lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax lavc/hevc_ps: Add pps parse support for hevc scc extension lavc/hevc_ps: Add slice parse support for HEVC SCC extension lavc/hevcdec: Fix the parsing for use_integer_mv_flag lavc/hevcdec: Set max_num_merge_cand to uint8_t lavc/hevc: update reference list for SCC libavcodec/avcodec.h | 1 + libavcodec/hevc.h | 3 ++ libavcodec/hevc_ps.c | 87 +++--- libavcodec/hevc_ps.h | 32 +++ libavcodec/hevc_refs.c | 21 ++-- libavcodec/hevcdec.c | 19 +-- libavcodec/hevcdec.h | 7 +++- libavcodec/profiles.c | 1 + 8 files changed, 161 insertions(+), 10 deletions(-) -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/7] lavc/hevc_ps: Add slice parse support for HEVC SCC extension
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 6 ++
libavcodec/hevcdec.h | 4
2 files changed, 10 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index e363e68..8194f18 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -800,6 +800,12 @@ static int hls_slice_header(HEVCContext *s)
sh->slice_cr_qp_offset = 0;
}
+if (s->ps.pps->pps_slice_act_qp_offsets_present_flag) {
+sh->slice_act_y_qp_offset = get_se_golomb(gb);
+sh->slice_act_cb_qp_offset = get_se_golomb(gb);
+sh->slice_act_cr_qp_offset = get_se_golomb(gb);
+}
+
if (s->ps.pps->chroma_qp_offset_list_enabled_flag)
sh->cu_chroma_qp_offset_enabled_flag = get_bits1(gb);
else
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 39c5c7f..6e22e04 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -292,6 +292,10 @@ typedef struct SliceHeader {
int slice_cb_qp_offset;
int slice_cr_qp_offset;
+int slice_act_y_qp_offset;
+int slice_act_cb_qp_offset;
+int slice_act_cr_qp_offset;
+
uint8_t cu_chroma_qp_offset_enabled_flag;
int beta_offset;///< beta_offset_div2 * 2
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/7] lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax
According to 7.3.2.2.3 in T-REC-H.265-201911.
Signed-off-by: Linjie Fu
---
libavcodec/hevc.h| 3 +++
libavcodec/hevc_ps.c | 32 +---
libavcodec/hevc_ps.h | 15 +++
3 files changed, 47 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index 1804755..6b454a7 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -154,6 +154,9 @@ enum {
// get near that, though, so set a lower limit here with the maximum
// possible value for 4K video (at most 135 16x16 Ctb rows).
HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
+
+// A.3.7: Screen content coding extensions
+HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
};
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 584e2ba..7610d3b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -909,7 +909,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
HEVCWindow *ow;
int ret = 0;
int log2_diff_max_min_transform_block_size;
-int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
+int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
num_comps;
int i;
// Coded parameters
@@ -1130,8 +1130,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
decode_vui(gb, avctx, apply_defdispwin, sps);
if (get_bits1(gb)) { // sps_extension_flag
-sps->sps_range_extension_flag = get_bits1(gb);
-skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
+sps->sps_range_extension_flag = get_bits1(gb);
+sps->sps_multilayer_extension_flag = get_bits1(gb);
+sps->sps_3d_extension_flag = get_bits1(gb);
+sps->sps_scc_extension_flag= get_bits1(gb);
+skip_bits(gb, 4); //sps_extension_4bits = get_bits(gb, 4);
if (sps->sps_range_extension_flag) {
sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
sps->transform_skip_context_enabled_flag = get_bits1(gb);
@@ -1157,6 +1160,29 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
unsigned int *sps_id,
av_log(avctx, AV_LOG_WARNING,
"cabac_bypass_alignment_enabled_flag not yet
implemented\n");
}
+if (sps->sps_multilayer_extension_flag || sps->sps_3d_extension_flag)
+av_log(avctx, AV_LOG_WARNING,
+ "multilayer_extension or 3d_extension not yet
implemented\n");
+
+if (sps->sps_scc_extension_flag) {
+sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
+sps->palette_mode_enabled_flag = get_bits1(gb);
+if (sps->palette_mode_enabled_flag) {
+sps->palette_max_size = get_ue_golomb_long(gb);
+sps->delta_palette_max_predictor_size = get_ue_golomb_long(gb);
+sps->sps_palette_predictor_initializers_present_flag =
get_bits1(gb);
+
+if (sps->sps_palette_predictor_initializers_present_flag) {
+sps->sps_num_palette_predictor_initializers_minus1 =
get_ue_golomb_long(gb);
+num_comps = sps->chroma_format_idc == 0 ? 1 : 3;
+for (int comp = 0; comp < num_comps; comp++)
+for (i = 0; i <=
sps->sps_num_palette_predictor_initializers_minus1; i++)
+sps->sps_palette_predictor_initializer[comp][i] =
get_ue_golomb_long(gb);
+}
+}
+sps->motion_vector_resolution_control_idc = get_bits(gb, 2);
+sps->intra_boundary_filtering_disabled_flag = get_bits1(gb);
+}
}
if (apply_defdispwin) {
sps->output_window.left_offset += sps->vui.def_disp_win.left_offset;
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 2a1bbf6..1501811 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -223,6 +223,21 @@ typedef struct HEVCSPS {
int persistent_rice_adaptation_enabled_flag;
int cabac_bypass_alignment_enabled_flag;
+// not yet implemented
+int sps_multilayer_extension_flag;
+int sps_3d_extension_flag;
+
+int sps_scc_extension_flag;
+int sps_curr_pic_ref_enabled_flag;
+int palette_mode_enabled_flag;
+int palette_max_size;
+int delta_palette_max_predictor_size;
+int sps_palette_predictor_initializers_present_flag;
+int sps_num_palette_predictor_initializers_minus1;
+int sps_palette_predictor_initializer[3][HEVC_MAX_PALETTE_PREDICTOR_SIZE];
+int motion_vector_resolution_control_idc;
+int intra_boundary_filtering_disabled_flag;
+
///< coded frame dimension in various units
int width;
int height;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subj
[FFmpeg-devel] [PATCH 7/7] lavc/hevc: update reference list for SCC
Screen Content Coding allows P slice in an IDR frame, and would add
frames themselves to the short term rps in RefList0 (8-10 in spec),
hence some previous restricts are not suitable any more.
[Request for comments].
Signed-off-by: Linjie Fu
---
libavcodec/hevc_refs.c | 21 +++--
libavcodec/hevcdec.c | 5 +++--
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
index 4f6d985..13a7bf6 100644
--- a/libavcodec/hevc_refs.c
+++ b/libavcodec/hevc_refs.c
@@ -301,7 +301,7 @@ int ff_hevc_slice_rpl(HEVCContext *s)
return ret;
if (!(s->rps[ST_CURR_BEF].nb_refs + s->rps[ST_CURR_AFT].nb_refs +
- s->rps[LT_CURR].nb_refs)) {
+ s->rps[LT_CURR].nb_refs) &&
!s->ps.pps->pps_curr_pic_ref_enabled_flag) {
av_log(s->avctx, AV_LOG_ERROR, "Zero refs in the frame RPS.\n");
return AVERROR_INVALIDDATA;
}
@@ -328,6 +328,12 @@ int ff_hevc_slice_rpl(HEVCContext *s)
rpl_tmp.nb_refs++;
}
}
+
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag) {
+rpl_tmp.ref[rpl_tmp.nb_refs]= s->ref;
+rpl_tmp.isLongTerm[rpl_tmp.nb_refs] = 0;
+rpl_tmp.nb_refs++;
+}
}
/* reorder the references if necessary */
@@ -423,7 +429,8 @@ static int add_candidate_ref(HEVCContext *s, RefPicList
*list,
{
HEVCFrame *ref = find_ref_idx(s, poc, use_msb);
-if (ref == s->ref || list->nb_refs >= HEVC_MAX_REFS)
+if ((ref == s->ref && !s->ps.pps->pps_curr_pic_ref_enabled_flag) ||
+list->nb_refs >= HEVC_MAX_REFS)
return AVERROR_INVALIDDATA;
if (!ref) {
@@ -482,6 +489,12 @@ int ff_hevc_frame_rps(HEVCContext *s)
goto fail;
}
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag) {
+ret = add_candidate_ref(s, &rps[ST_FOLL], s->poc,
HEVC_FRAME_FLAG_SHORT_REF, 1);
+if (ret < 0)
+goto fail;
+}
+
/* add the long refs */
for (i = 0; i < long_rps->nb_refs; i++) {
int poc = long_rps->poc[i];
@@ -518,5 +531,9 @@ int ff_hevc_frame_nb_refs(const HEVCContext *s)
for (i = 0; i < long_rps->nb_refs; i++)
ret += !!long_rps->used[i];
}
+
+if (s->ps.pps->pps_curr_pic_ref_enabled_flag)
+ret++;
+
return ret;
}
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index fc8a77d..d7a10c4 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -617,7 +617,8 @@ static int hls_slice_header(HEVCContext *s)
sh->slice_type);
return AVERROR_INVALIDDATA;
}
-if (IS_IRAP(s) && sh->slice_type != HEVC_SLICE_I) {
+if (IS_IRAP(s) && sh->slice_type != HEVC_SLICE_I &&
+s->ps.sps->ptl.general_ptl.profile_idc != FF_PROFILE_HEVC_SCC) {
av_log(s->avctx, AV_LOG_ERROR, "Inter slices in an IRAP frame.\n");
return AVERROR_INVALIDDATA;
}
@@ -729,7 +730,7 @@ static int hls_slice_header(HEVCContext *s)
sh->rpl_modification_flag[0] = 0;
sh->rpl_modification_flag[1] = 0;
nb_refs = ff_hevc_frame_nb_refs(s);
-if (!nb_refs) {
+if (!nb_refs && !s->ps.pps->pps_curr_pic_ref_enabled_flag) {
av_log(s->avctx, AV_LOG_ERROR, "Zero refs for a frame with P
or B slices.\n");
return AVERROR_INVALIDDATA;
}
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/7] lavc/hevcdec: Set max_num_merge_cand to uint8_t
uint8_t is big enough and keep consistent with the definition in
cbs_h265.h.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 1164af2..464eb7c 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -301,7 +301,7 @@ typedef struct SliceHeader {
int beta_offset;///< beta_offset_div2 * 2
int tc_offset; ///< tc_offset_div2 * 2
-unsigned int max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
+uint8_t max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
uint8_t use_integer_mv_flag;
unsigned *entry_point_offset;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/7] lavc/hevc_ps: Add pps parse support for hevc scc extension
Signed-off-by: Linjie Fu
---
libavcodec/hevc_ps.c | 53 ++--
libavcodec/hevc_ps.h | 17 +
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index 7610d3b..887b960 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1388,6 +1388,45 @@ static int pps_range_extensions(GetBitContext *gb,
AVCodecContext *avctx,
return(0);
}
+static int pps_scc_extensions(GetBitContext *gb, AVCodecContext *avctx,
+HEVCPPS *pps, HEVCSPS *sps) {
+int num_comps;
+int i, ret;
+
+pps->pps_curr_pic_ref_enabled_flag = get_bits1(gb);
+if (pps->residual_adaptive_colour_transform_enabled_flag = get_bits1(gb)) {
+pps->pps_slice_act_qp_offsets_present_flag = get_bits1(gb);
+pps->pps_act_y_qp_offset = get_se_golomb_long(gb) - 5;
+pps->pps_act_cb_qp_offset = get_se_golomb_long(gb) - 5;
+pps->pps_act_cr_qp_offset = get_se_golomb_long(gb) - 3;
+
+#define CHECK_QP_OFFSET(name) (pps->pps_act_ ## name ## _qp_offset < -12 || \
+ pps->pps_act_ ## name ## _qp_offset > 12)
+ret = CHECK_QP_OFFSET(y) || CHECK_QP_OFFSET(cb) || CHECK_QP_OFFSET(cr);
+#undef CHECK_QP_OFFSET
+if (ret) {
+av_log(avctx, AV_LOG_ERROR,
+ "PpsActQpOffsetY/Cb/Cr shall be in the range of [-12,
12].\n");
+return AVERROR_INVALIDDATA;
+}
+}
+
+if (pps->pps_palette_predictor_initializers_present_flag = get_bits1(gb)) {
+if ((pps->pps_num_palette_predictor_initializers =
get_ue_golomb_long(gb)) > 0) {
+pps->monochrome_palette_flag = get_bits1(gb);
+pps->luma_bit_depth_entry_minus8 = get_ue_golomb_long(gb);
+if (!pps->monochrome_palette_flag)
+pps->chroma_bit_depth_entry_minus8 = get_ue_golomb_long(gb);
+num_comps = pps->monochrome_palette_flag ? 1 : 3;
+for (int comp = 0; comp < num_comps; comp++)
+for (i = 0; i < pps->pps_num_palette_predictor_initializers;
i++)
+pps->pps_palette_predictor_initializer[comp][i] =
get_ue_golomb_long(gb);
+}
+}
+
+return 0;
+}
+
static inline int setup_pps(AVCodecContext *avctx, GetBitContext *gb,
HEVCPPS *pps, HEVCSPS *sps)
{
@@ -1740,12 +1779,22 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
pps->slice_header_extension_present_flag = get_bits1(gb);
if (get_bits1(gb)) { // pps_extension_present_flag
-pps->pps_range_extensions_flag = get_bits1(gb);
-skip_bits(gb, 7); // pps_extension_7bits
+pps->pps_range_extensions_flag = get_bits1(gb);
+pps->pps_multilayer_extension_flag = get_bits1(gb);
+pps->pps_3d_extension_flag = get_bits1(gb);
+pps->pps_scc_extensions_flag = get_bits1(gb);
+skip_bits(gb, 4); // pps_extension_4bits
if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_REXT &&
pps->pps_range_extensions_flag) {
if ((ret = pps_range_extensions(gb, avctx, pps, sps)) < 0)
goto err;
}
+if (pps->pps_multilayer_extension_flag || pps->pps_3d_extension_flag)
+av_log(avctx, AV_LOG_WARNING,
+ "multilayer_extension or 3d_extension not yet
implemented\n");
+if (sps->ptl.general_ptl.profile_idc == FF_PROFILE_HEVC_SCC &&
pps->pps_scc_extensions_flag) {
+if ((ret = pps_scc_extensions(gb, avctx, pps, sps)) < 0)
+goto err;
+}
}
ret = setup_pps(avctx, gb, pps, sps);
diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
index 1501811..0cfac43 100644
--- a/libavcodec/hevc_ps.h
+++ b/libavcodec/hevc_ps.h
@@ -312,6 +312,9 @@ typedef struct HEVCPPS {
uint8_t slice_header_extension_present_flag;
uint8_t log2_max_transform_skip_block_size;
uint8_t pps_range_extensions_flag;
+uint8_t pps_multilayer_extension_flag;
+uint8_t pps_3d_extension_flag;
+uint8_t pps_scc_extensions_flag;
uint8_t cross_component_prediction_enabled_flag;
uint8_t chroma_qp_offset_list_enabled_flag;
uint8_t diff_cu_chroma_qp_offset_depth;
@@ -321,6 +324,20 @@ typedef struct HEVCPPS {
uint8_t log2_sao_offset_scale_luma;
uint8_t log2_sao_offset_scale_chroma;
+// Scc extension parameters
+uint8_t pps_curr_pic_ref_enabled_flag;
+uint8_t residual_adaptive_colour_transform_enabled_flag;
+uint8_t pps_slice_act_qp_offsets_present_flag;
+int8_t pps_act_y_qp_offset; // _plus5
+int8_t pps_act_cb_qp_offset; // _plus5
+int8_t pps_act_cr_qp_offset; // _plus3
+uint8_t pps_palette_predictor_initializers_present_flag;
+uint8_t pps_num_palette_predictor_initializers;
+uint8_t monochrome_palette_flag;
+uint8_t luma_bit_depth_entry_minus8;
+uint8_t chroma_bit_depth_entry_m
[FFmpeg-devel] [PATCH 5/7] lavc/hevcdec: Fix the parsing for use_integer_mv_flag
According to 7.3.6.1, use_integer_mv_flag should be parsed if
motion_vector_resolution_control_idc equals to 2.
Otherwise wrong parameters in the subsequent parsing procedures
would be got.
Signed-off-by: Linjie Fu
---
libavcodec/hevcdec.c | 8
libavcodec/hevcdec.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 8194f18..fc8a77d 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -788,6 +788,14 @@ static int hls_slice_header(HEVCContext *s)
sh->max_num_merge_cand);
return AVERROR_INVALIDDATA;
}
+
+// Syntax in 7.3.6.1
+if (s->ps.sps->motion_vector_resolution_control_idc == 2)
+sh->use_integer_mv_flag = get_bits1(gb);
+else
+// Inferred to be equal to
motion_vector_resolution_control_idc if not present
+sh->use_integer_mv_flag =
s->ps.sps->motion_vector_resolution_control_idc;
+
}
sh->slice_qp_delta = get_se_golomb(gb);
diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
index 6e22e04..1164af2 100644
--- a/libavcodec/hevcdec.h
+++ b/libavcodec/hevcdec.h
@@ -302,6 +302,7 @@ typedef struct SliceHeader {
int tc_offset; ///< tc_offset_div2 * 2
unsigned int max_num_merge_cand; ///< 5 - 5_minus_max_num_merge_cand
+uint8_t use_integer_mv_flag;
unsigned *entry_point_offset;
int * offset;
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/7] lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax
On 7/9/2020 1:17 PM, Linjie Fu wrote:
> According to 7.3.2.2.3 in T-REC-H.265-201911.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/hevc.h| 3 +++
> libavcodec/hevc_ps.c | 32 +---
> libavcodec/hevc_ps.h | 15 +++
> 3 files changed, 47 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> index 1804755..6b454a7 100644
> --- a/libavcodec/hevc.h
> +++ b/libavcodec/hevc.h
> @@ -154,6 +154,9 @@ enum {
> // get near that, though, so set a lower limit here with the maximum
> // possible value for 4K video (at most 135 16x16 Ctb rows).
> HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
> +
> +// A.3.7: Screen content coding extensions
> +HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
> };
>
>
> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> index 584e2ba..7610d3b 100644
> --- a/libavcodec/hevc_ps.c
> +++ b/libavcodec/hevc_ps.c
> @@ -909,7 +909,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> HEVCWindow *ow;
> int ret = 0;
> int log2_diff_max_min_transform_block_size;
> -int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
> +int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
> num_comps;
> int i;
>
> // Coded parameters
> @@ -1130,8 +1130,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> decode_vui(gb, avctx, apply_defdispwin, sps);
>
> if (get_bits1(gb)) { // sps_extension_flag
> -sps->sps_range_extension_flag = get_bits1(gb);
> -skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
> +sps->sps_range_extension_flag = get_bits1(gb);
> +sps->sps_multilayer_extension_flag = get_bits1(gb);
> +sps->sps_3d_extension_flag = get_bits1(gb);
> +sps->sps_scc_extension_flag= get_bits1(gb);
> +skip_bits(gb, 4); //sps_extension_4bits = get_bits(gb, 4);
> if (sps->sps_range_extension_flag) {
> sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
> sps->transform_skip_context_enabled_flag = get_bits1(gb);
> @@ -1157,6 +1160,29 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> unsigned int *sps_id,
> av_log(avctx, AV_LOG_WARNING,
> "cabac_bypass_alignment_enabled_flag not yet
> implemented\n");
> }
> +if (sps->sps_multilayer_extension_flag || sps->sps_3d_extension_flag)
> +av_log(avctx, AV_LOG_WARNING,
> + "multilayer_extension or 3d_extension not yet
> implemented\n");
> +
> +if (sps->sps_scc_extension_flag) {
> +sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
> +sps->palette_mode_enabled_flag = get_bits1(gb);
> +if (sps->palette_mode_enabled_flag) {
> +sps->palette_max_size = get_ue_golomb_long(gb);
> +sps->delta_palette_max_predictor_size =
> get_ue_golomb_long(gb);
> +sps->sps_palette_predictor_initializers_present_flag =
> get_bits1(gb);
> +
> +if (sps->sps_palette_predictor_initializers_present_flag) {
> +sps->sps_num_palette_predictor_initializers_minus1 =
> get_ue_golomb_long(gb);
> +num_comps = sps->chroma_format_idc == 0 ? 1 : 3;
> +for (int comp = 0; comp < num_comps; comp++)
> +for (i = 0; i <=
> sps->sps_num_palette_predictor_initializers_minus1; i++)
> +sps->sps_palette_predictor_initializer[comp][i]
> = get_ue_golomb_long(gb);
This isn't an ue value. Its length is a fixed value (each plane's
bitdepth, afaics).
> +}
> +}
> +sps->motion_vector_resolution_control_idc = get_bits(gb, 2);
> +sps->intra_boundary_filtering_disabled_flag = get_bits1(gb);
> +}
> }
> if (apply_defdispwin) {
> sps->output_window.left_offset +=
> sps->vui.def_disp_win.left_offset;
> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
> index 2a1bbf6..1501811 100644
> --- a/libavcodec/hevc_ps.h
> +++ b/libavcodec/hevc_ps.h
> @@ -223,6 +223,21 @@ typedef struct HEVCSPS {
> int persistent_rice_adaptation_enabled_flag;
> int cabac_bypass_alignment_enabled_flag;
>
> +// not yet implemented
> +int sps_multilayer_extension_flag;
> +int sps_3d_extension_flag;
> +
> +int sps_scc_extension_flag;
> +int sps_curr_pic_ref_enabled_flag;
> +int palette_mode_enabled_flag;
> +int palette_max_size;
> +int delta_palette_max_predictor_size;
> +int sps_palette_predictor_initializers_present_flag;
> +int sps_num_palette_predictor_initializers_minus1;
> +int
> sps_palette_predictor_initializer[3][HEVC_MAX_PALETTE_PREDICTOR_SIZE];
> +int motion_vector_resolution_control_idc;
> +int intra_bou
Re: [FFmpeg-devel] [PATCH 2/7] lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax
On 7/9/2020 1:51 PM, James Almer wrote:
> On 7/9/2020 1:17 PM, Linjie Fu wrote:
>> According to 7.3.2.2.3 in T-REC-H.265-201911.
>>
>> Signed-off-by: Linjie Fu
>> ---
>> libavcodec/hevc.h| 3 +++
>> libavcodec/hevc_ps.c | 32 +---
>> libavcodec/hevc_ps.h | 15 +++
>> 3 files changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
>> index 1804755..6b454a7 100644
>> --- a/libavcodec/hevc.h
>> +++ b/libavcodec/hevc.h
>> @@ -154,6 +154,9 @@ enum {
>> // get near that, though, so set a lower limit here with the maximum
>> // possible value for 4K video (at most 135 16x16 Ctb rows).
>> HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
>> +
>> +// A.3.7: Screen content coding extensions
>> +HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
>> };
>>
>>
>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
>> index 584e2ba..7610d3b 100644
>> --- a/libavcodec/hevc_ps.c
>> +++ b/libavcodec/hevc_ps.c
>> @@ -909,7 +909,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
>> unsigned int *sps_id,
>> HEVCWindow *ow;
>> int ret = 0;
>> int log2_diff_max_min_transform_block_size;
>> -int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
>> +int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
>> num_comps;
>> int i;
>>
>> // Coded parameters
>> @@ -1130,8 +1130,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
>> *gb, unsigned int *sps_id,
>> decode_vui(gb, avctx, apply_defdispwin, sps);
>>
>> if (get_bits1(gb)) { // sps_extension_flag
>> -sps->sps_range_extension_flag = get_bits1(gb);
>> -skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
>> +sps->sps_range_extension_flag = get_bits1(gb);
>> +sps->sps_multilayer_extension_flag = get_bits1(gb);
>> +sps->sps_3d_extension_flag = get_bits1(gb);
>> +sps->sps_scc_extension_flag= get_bits1(gb);
>> +skip_bits(gb, 4); //sps_extension_4bits = get_bits(gb, 4);
>> if (sps->sps_range_extension_flag) {
>> sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
>> sps->transform_skip_context_enabled_flag = get_bits1(gb);
>> @@ -1157,6 +1160,29 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
>> *gb, unsigned int *sps_id,
>> av_log(avctx, AV_LOG_WARNING,
>> "cabac_bypass_alignment_enabled_flag not yet
>> implemented\n");
>> }
>> +if (sps->sps_multilayer_extension_flag ||
>> sps->sps_3d_extension_flag)
>> +av_log(avctx, AV_LOG_WARNING,
>> + "multilayer_extension or 3d_extension not yet
>> implemented\n");
Also, you can't just ignore these. If you don't parse both, you'll be
reading the wrong bits for SCC.
Either add support for these two, or return AVERROR_PATCHWELCOME. Same
for PPS.
>> +
>> +if (sps->sps_scc_extension_flag) {
>> +sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
>> +sps->palette_mode_enabled_flag = get_bits1(gb);
>> +if (sps->palette_mode_enabled_flag) {
>> +sps->palette_max_size = get_ue_golomb_long(gb);
>> +sps->delta_palette_max_predictor_size =
>> get_ue_golomb_long(gb);
>> +sps->sps_palette_predictor_initializers_present_flag =
>> get_bits1(gb);
>> +
>> +if (sps->sps_palette_predictor_initializers_present_flag) {
>> +sps->sps_num_palette_predictor_initializers_minus1 =
>> get_ue_golomb_long(gb);
>> +num_comps = sps->chroma_format_idc == 0 ? 1 : 3;
>> +for (int comp = 0; comp < num_comps; comp++)
>> +for (i = 0; i <=
>> sps->sps_num_palette_predictor_initializers_minus1; i++)
>> +sps->sps_palette_predictor_initializer[comp][i]
>> = get_ue_golomb_long(gb);
>
> This isn't an ue value. Its length is a fixed value (each plane's
> bitdepth, afaics).
>
>> +}
>> +}
>> +sps->motion_vector_resolution_control_idc = get_bits(gb, 2);
>> +sps->intra_boundary_filtering_disabled_flag = get_bits1(gb);
>> +}
>> }
>> if (apply_defdispwin) {
>> sps->output_window.left_offset +=
>> sps->vui.def_disp_win.left_offset;
>> diff --git a/libavcodec/hevc_ps.h b/libavcodec/hevc_ps.h
>> index 2a1bbf6..1501811 100644
>> --- a/libavcodec/hevc_ps.h
>> +++ b/libavcodec/hevc_ps.h
>> @@ -223,6 +223,21 @@ typedef struct HEVCSPS {
>> int persistent_rice_adaptation_enabled_flag;
>> int cabac_bypass_alignment_enabled_flag;
>>
>> +// not yet implemented
>> +int sps_multilayer_extension_flag;
>> +int sps_3d_extension_flag;
>> +
>> +int sps_scc_extension_flag;
>> +int sps_curr_pic_ref_enabled_flag;
>> +int palette_mode_enabled_flag;
>>
Re: [FFmpeg-devel] [PATCH] avdevice/gdigrab: client_only option to discard decorations such as titlebar or borders
On Fri, 2020-06-19 at 10:33 +0200, Sergio Acereda wrote:
> +/**
> + * Fetch titlebar height from handle.
> + *
> + * @param hwnd Handle of the window.
> + * @return titlebar height
> + */
> +static int
> +calc_titlebar_height(HWND hwnd) {
> +TITLEBARINFOEX tinfo;
> +tinfo.cbSize = sizeof(tinfo);
> +SendMessage(hwnd, WM_GETTITLEBARINFOEX, 0, (LPARAM)&tinfo);
> +return tinfo.rcTitleBar.bottom - tinfo.rcTitleBar.top;
> +}
> +
> /**
> * Initializes the gdi grab device demuxer (public device demuxer
> API).
> *
> @@ -284,6 +299,15 @@ gdigrab_read_header(AVFormatContext *s1)
>
> if (hwnd) {
> GetClientRect(hwnd, &virtual_rect);
> +if (gdigrab->client_only) {
> +int cxborder = GetSystemMetrics(SM_CXBORDER);
> +int cyborder = GetSystemMetrics(SM_CYBORDER);
> +int titlebar_height = calc_titlebar_height(hwnd);
> +virtual_rect.left += cxborder;
> +virtual_rect.right += -cxborder;
> +virtual_rect.top+= cxborder + titlebar_height;
> +virtual_rect.bottom += -cyborder;
> +}
This seems fine - my only comment is that you need to test this with
high DPI support (display scale values >100%) on both native high-dpi
applications and legacy (scaled by windows) applications to ensure the
correct adjustments are being applied where needed.
--
Calvin Walton
___
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 v2 1/3] libavutil/imgutils: add utility to get plane sizes
[...] On Wed, Jul 8, 2020 at 7:42 PM James Almer wrote: > The sum of all sizes should be size_t if each size is a size_t. But if > you do that you can't return error values, so i'm not sure what to > suggest other than just stick to ints for both (ptrdiff_t linesizes > should be ok). > I'd like to hear Michael's opinion about it. > > For that matter, as it is right now i think this would be the first > function that returns ptrdiff_t to signal AVERROR values. Yeah, I wasn't sure what the best thing to do here would be since it seemed like switching back to ints for the outputs would make the ptrdiff_t linesizes less useful. We could have each size be a ptrdiff_t as well, but that seems a bit weird too. There is one function in libavformat (ff_subtitles_read_line) that returns a negative error ptrdiff_t to signal errors. [...] > > -if (linesizes[0] > (INT_MAX - 1024) / height) > > +if (linesizes[0] > (PTRDIFF_MAX - 1024) / height) > > This check would need to ensure the calculation below fits in a size_t > instead. If the return type is ptrdiff_t, then I guess we would need to check both. I had thought ptrdiff_t was the corresponding signed type for size_t (so it would be guaranteed to have a lower max), but I guess that isn't guaranteed? ___ 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/7] lavc/hevc_ps: Add sps parse support for HEVC SCC extension syntax
On Fri, Jul 10, 2020 at 12:54 AM James Almer wrote:
>
> On 7/9/2020 1:51 PM, James Almer wrote:
> > On 7/9/2020 1:17 PM, Linjie Fu wrote:
> >> According to 7.3.2.2.3 in T-REC-H.265-201911.
> >>
> >> Signed-off-by: Linjie Fu
> >> ---
> >> libavcodec/hevc.h| 3 +++
> >> libavcodec/hevc_ps.c | 32 +---
> >> libavcodec/hevc_ps.h | 15 +++
> >> 3 files changed, 47 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
> >> index 1804755..6b454a7 100644
> >> --- a/libavcodec/hevc.h
> >> +++ b/libavcodec/hevc.h
> >> @@ -154,6 +154,9 @@ enum {
> >> // get near that, though, so set a lower limit here with the maximum
> >> // possible value for 4K video (at most 135 16x16 Ctb rows).
> >> HEVC_MAX_ENTRY_POINT_OFFSETS = HEVC_MAX_TILE_COLUMNS * 135,
> >> +
> >> +// A.3.7: Screen content coding extensions
> >> +HEVC_MAX_PALETTE_PREDICTOR_SIZE = 128,
> >> };
> >>
> >>
> >> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >> index 584e2ba..7610d3b 100644
> >> --- a/libavcodec/hevc_ps.c
> >> +++ b/libavcodec/hevc_ps.c
> >> @@ -909,7 +909,7 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext *gb,
> >> unsigned int *sps_id,
> >> HEVCWindow *ow;
> >> int ret = 0;
> >> int log2_diff_max_min_transform_block_size;
> >> -int bit_depth_chroma, start, vui_present, sublayer_ordering_info;
> >> +int bit_depth_chroma, start, vui_present, sublayer_ordering_info,
> >> num_comps;
> >> int i;
> >>
> >> // Coded parameters
> >> @@ -1130,8 +1130,11 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
> >> *gb, unsigned int *sps_id,
> >> decode_vui(gb, avctx, apply_defdispwin, sps);
> >>
> >> if (get_bits1(gb)) { // sps_extension_flag
> >> -sps->sps_range_extension_flag = get_bits1(gb);
> >> -skip_bits(gb, 7); //sps_extension_7bits = get_bits(gb, 7);
> >> +sps->sps_range_extension_flag = get_bits1(gb);
> >> +sps->sps_multilayer_extension_flag = get_bits1(gb);
> >> +sps->sps_3d_extension_flag = get_bits1(gb);
> >> +sps->sps_scc_extension_flag= get_bits1(gb);
> >> +skip_bits(gb, 4); //sps_extension_4bits = get_bits(gb, 4);
> >> if (sps->sps_range_extension_flag) {
> >> sps->transform_skip_rotation_enabled_flag = get_bits1(gb);
> >> sps->transform_skip_context_enabled_flag = get_bits1(gb);
> >> @@ -1157,6 +1160,29 @@ int ff_hevc_parse_sps(HEVCSPS *sps, GetBitContext
> >> *gb, unsigned int *sps_id,
> >> av_log(avctx, AV_LOG_WARNING,
> >> "cabac_bypass_alignment_enabled_flag not yet
> >> implemented\n");
> >> }
> >> +if (sps->sps_multilayer_extension_flag ||
> >> sps->sps_3d_extension_flag)
> >> +av_log(avctx, AV_LOG_WARNING,
> >> + "multilayer_extension or 3d_extension not yet
> >> implemented\n");
>
> Also, you can't just ignore these. If you don't parse both, you'll be
> reading the wrong bits for SCC.
>
> Either add support for these two, or return AVERROR_PATCHWELCOME. Same
> for PPS.
Ah, should have noticed this.
Will fix, thx.
> >> +
> >> +if (sps->sps_scc_extension_flag) {
> >> +sps->sps_curr_pic_ref_enabled_flag = get_bits1(gb);
> >> +sps->palette_mode_enabled_flag = get_bits1(gb);
> >> +if (sps->palette_mode_enabled_flag) {
> >> +sps->palette_max_size = get_ue_golomb_long(gb);
> >> +sps->delta_palette_max_predictor_size =
> >> get_ue_golomb_long(gb);
> >> +sps->sps_palette_predictor_initializers_present_flag =
> >> get_bits1(gb);
> >> +
> >> +if (sps->sps_palette_predictor_initializers_present_flag)
> >> {
> >> +sps->sps_num_palette_predictor_initializers_minus1 =
> >> get_ue_golomb_long(gb);
> >> +num_comps = sps->chroma_format_idc == 0 ? 1 : 3;
> >> +for (int comp = 0; comp < num_comps; comp++)
> >> +for (i = 0; i <=
> >> sps->sps_num_palette_predictor_initializers_minus1; i++)
> >> +
> >> sps->sps_palette_predictor_initializer[comp][i] = get_ue_golomb_long(gb);
> >
> > This isn't an ue value. Its length is a fixed value (each plane's
> > bitdepth, afaics).
> >
It's u(v), shall be in the range of 0 to (1 << BitDepth) - 1, inclusive, thx.
- Linjie
___
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 v2 1/3] libavutil/imgutils: add utility to get plane sizes
On 7/9/2020 3:20 PM, Brian Kim wrote: > [...] > > On Wed, Jul 8, 2020 at 7:42 PM James Almer wrote: >> The sum of all sizes should be size_t if each size is a size_t. But if >> you do that you can't return error values, so i'm not sure what to >> suggest other than just stick to ints for both (ptrdiff_t linesizes >> should be ok). >> I'd like to hear Michael's opinion about it. >> >> For that matter, as it is right now i think this would be the first >> function that returns ptrdiff_t to signal AVERROR values. > > Yeah, I wasn't sure what the best thing to do here would be since it > seemed like switching back to ints for the outputs would make the > ptrdiff_t linesizes less useful. We could have each size be a > ptrdiff_t as well, but that seems a bit weird too. Yes, the sizes (total or per plane) are for objects in memory, so they should be either size_t, or int to be consistent with other functions in this module. > > There is one function in libavformat (ff_subtitles_read_line) that > returns a negative error ptrdiff_t to signal errors. > > [...] > >>> -if (linesizes[0] > (INT_MAX - 1024) / height) >>> +if (linesizes[0] > (PTRDIFF_MAX - 1024) / height) >> >> This check would need to ensure the calculation below fits in a size_t >> instead. > > If the return type is ptrdiff_t, then I guess we would need to check > both. I had thought ptrdiff_t was the corresponding signed type for > size_t (so it would be guaranteed to have a lower max), but I guess > that isn't guaranteed? Technically, the signed type for size_t is ssize_t, but afaik that's not portable so we don't use it. My point is, linesize[0] * height could fit in a size_t but not in a ptrdiff_t, and you care about the former since that's the type for size[0]. I still think the best course of action here is to just stick with ints, but i want to hear what other devs have to say about it. Another option is to return the sum of all plane sizes in another function parameter, and make the return value an int where 0 means success and <0 failure, so: int av_image_fill_plane_sizes(size_t *size, size_t planesizes[4], enum AVPixelFormat pix_fmt, int height, const ptrdiff_t linesizes[4]) But it's also somewhat ugly and inconsistent with other functions in this module. ___ 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 08/17] avformat/avc: Add helper function to parse annex B NAL unit in one go
Up until now, a caller had no function to easily parse a single annex B
NAL unit. There was a "low-level" function that returned the position of
the beginning of the next start code, which could be used to get the
beginning and the end of NAL units. Yet using this function still
required calling the startcode function twice and actually getting the
start of the NAL unit data required a loop (because the offset from the
start of the unit might be three or four). In practice, several
functions that transformed from annex B to mp4 used the same scheme to
do so while other (the functions to write H.264/HEVC extradata) used the
former to at first transform the input into something more manageable.
This commit adds a helper function to easily parse one annex B NAL unit
in one go.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 30 +-
libavformat/avc.h | 2 ++
2 files changed, 31 insertions(+), 1 deletion(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index cc92fb1038..39078aa5be 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -79,15 +79,43 @@ rest:
return p;
}
-return end;
+return NULL;
}
const uint8_t *ff_avc_find_startcode(const uint8_t *p, const uint8_t *end){
const uint8_t *out = avc_find_startcode_internal(p, end);
+out = out ? out : end;
if(p p && !next[-1] ? next - 1 : next;
+next+= 3;
+} else {
+*nal_end = end;
+}
+*start = next;
+return p;
+}
+
int ff_avc_parse_nal_units(AVIOContext *pb, const uint8_t *buf_in, int size)
{
const uint8_t *p = buf_in;
diff --git a/libavformat/avc.h b/libavformat/avc.h
index 9792b77913..b3df0a7b6b 100644
--- a/libavformat/avc.h
+++ b/libavformat/avc.h
@@ -29,6 +29,8 @@ int ff_avc_parse_nal_units(AVIOContext *s, const uint8_t
*buf, int size);
int ff_avc_parse_nal_units_buf(const uint8_t *buf_in, uint8_t **buf, int
*size);
int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len);
const uint8_t *ff_avc_find_startcode(const uint8_t *p, const uint8_t *end);
+const uint8_t *ff_avc_parse_nalu(const uint8_t **start, const uint8_t
**nal_end,
+ const uint8_t *end);
int ff_avc_write_annexb_extradata(const uint8_t *in, uint8_t **buf, int *size);
const uint8_t *ff_avc_mp4_find_startcode(const uint8_t *start,
const uint8_t *end,
--
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".
[FFmpeg-devel] [PATCH 12/17] avformat/avc: Discard empty NAL units during annex B->mp4 conversion
When an empty annex B NAL unit (i.e. 0x01 immediately followed by a
three or four-byte start code) is encountered during annex B->mp4
conversion, a NAL unit of size zero is created; this is invalid.
Furthermore, several functions simply presumed all NAL units to be
nonempty and treated the first byte as the NAL unit type.
Ticket #7200 contains a sample with such NAL units.
This commit skips empty NAL units during annex B->mp4 conversion,
ensuring that the callers don't need to check for themselves.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 98462940ad..17fcd1e73f 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -104,6 +104,7 @@ const uint8_t *ff_avc_parse_nalu(const uint8_t **start,
const uint8_t **nal_end,
p += 3;
}
+search_again:
next = avc_find_startcode_internal(p, end);
if (next) {
@@ -112,6 +113,12 @@ const uint8_t *ff_avc_parse_nalu(const uint8_t **start,
const uint8_t **nal_end,
} else {
*nal_end = end;
}
+if (*nal_end == p) {
+if (!next)
+return NULL;
+p = next;
+goto search_again;
+}
*start = next;
return p;
}
--
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".
[FFmpeg-devel] [PATCH 09/17] avformat/avc, movenccenc: Simplify annex B->mp4 transformation
by using the new ff_avc_parse_nalu function.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c| 11 ++-
libavformat/movenccenc.c | 12 ++--
2 files changed, 4 insertions(+), 19 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 39078aa5be..d089051034 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -120,20 +120,13 @@ int ff_avc_parse_nal_units(AVIOContext *pb, const uint8_t
*buf_in, int size)
{
const uint8_t *p = buf_in;
const uint8_t *end = p + size;
-const uint8_t *nal_start, *nal_end;
+const uint8_t *nal_start, *nal_end = NULL;
size = 0;
-nal_start = ff_avc_find_startcode(p, end);
-for (;;) {
-while (nal_start < end && !*(nal_start++));
-if (nal_start == end)
-break;
-
-nal_end = ff_avc_find_startcode(nal_start, end);
+while (nal_start = ff_avc_parse_nalu(&p, &nal_end, end)) {
avio_wb32(pb, nal_end - nal_start);
avio_write(pb, nal_start, nal_end - nal_start);
size += 4 + nal_end - nal_start;
-nal_start = nal_end;
}
return size;
}
diff --git a/libavformat/movenccenc.c b/libavformat/movenccenc.c
index b91294f706..75244ab70b 100644
--- a/libavformat/movenccenc.c
+++ b/libavformat/movenccenc.c
@@ -194,7 +194,7 @@ int ff_mov_cenc_avc_parse_nal_units(MOVMuxCencContext* ctx,
AVIOContext *pb,
{
const uint8_t *p = buf_in;
const uint8_t *end = p + size;
-const uint8_t *nal_start, *nal_end;
+const uint8_t *nal_start, *nal_end = NULL;
int ret;
ret = mov_cenc_start_packet(ctx);
@@ -203,14 +203,7 @@ int ff_mov_cenc_avc_parse_nal_units(MOVMuxCencContext*
ctx, AVIOContext *pb,
}
size = 0;
-nal_start = ff_avc_find_startcode(p, end);
-for (;;) {
-while (nal_start < end && !*(nal_start++));
-if (nal_start == end)
-break;
-
-nal_end = ff_avc_find_startcode(nal_start, end);
-
+while (nal_start = ff_avc_parse_nalu(&p, &nal_end, end)) {
avio_wb32(pb, nal_end - nal_start);
avio_w8(pb, *nal_start);
mov_cenc_write_encrypted(ctx, pb, nal_start + 1, nal_end - nal_start -
1);
@@ -218,7 +211,6 @@ int ff_mov_cenc_avc_parse_nal_units(MOVMuxCencContext* ctx,
AVIOContext *pb,
auxiliary_info_add_subsample(ctx, 5, nal_end - nal_start - 1);
size += 4 + nal_end - nal_start;
-nal_start = nal_end;
}
ret = mov_cenc_end_packet(ctx);
--
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".
[FFmpeg-devel] [PATCH 10/17] avformat/sdp: Simplify creating H.264 media attributes
by using ff_avc_parse_nalu() which means that one no longer has to
take care of finding both the start as well as the end of a NAL unit
separately.
Signed-off-by: Andreas Rheinhardt
---
libavformat/sdp.c | 34 +++---
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/libavformat/sdp.c b/libavformat/sdp.c
index 023c88a583..bc0c39c8b5 100644
--- a/libavformat/sdp.c
+++ b/libavformat/sdp.c
@@ -156,11 +156,10 @@ static int sdp_get_address(char *dest_addr, int size, int
*ttl, const char *url)
static char *extradata2psets(AVFormatContext *s, AVCodecParameters *par)
{
char *psets, *p;
-const uint8_t *r;
static const char pset_string[] = "; sprop-parameter-sets=";
static const char profile_string[] = "; profile-level-id=";
-uint8_t *extradata = par->extradata;
-int extradata_size = par->extradata_size;
+const uint8_t *r = par->extradata, *end = r + par->extradata_size;
+const uint8_t *nal, *nal_end = NULL;
uint8_t *tmpbuf = NULL;
const uint8_t *sps = NULL;
@@ -170,10 +169,12 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
return NULL;
}
if (par->extradata[0] == 1) {
-if (ff_avc_write_annexb_extradata(par->extradata, &extradata,
+int extradata_size = par->extradata_size;
+if (ff_avc_write_annexb_extradata(par->extradata, &tmpbuf,
&extradata_size))
return NULL;
-tmpbuf = extradata;
+r = tmpbuf;
+end = r + extradata_size;
}
psets = av_mallocz(MAX_PSET_SIZE);
@@ -184,34 +185,29 @@ static char *extradata2psets(AVFormatContext *s,
AVCodecParameters *par)
}
memcpy(psets, pset_string, strlen(pset_string));
p = psets + strlen(pset_string);
-r = ff_avc_find_startcode(extradata, extradata + extradata_size);
-while (r < extradata + extradata_size) {
-const uint8_t *r1;
-uint8_t nal_type;
-
-while (!*(r++));
-nal_type = *r & 0x1f;
-r1 = ff_avc_find_startcode(r, extradata + extradata_size);
+while (nal = ff_avc_parse_nalu(&r, &nal_end, end)) {
+uint8_t nal_type = *nal & 0x1f;
+ptrdiff_t size = nal_end - nal;
+
if (nal_type != 7 && nal_type != 8) { /* Only output SPS and PPS */
-r = r1;
continue;
}
if (p != (psets + strlen(pset_string))) {
*p = ',';
p++;
}
-if (nal_type == H264_NAL_SPS && !sps && r1 - r >= 4)
-sps = r;
+if (nal_type == H264_NAL_SPS && !sps && size >= 4)
+sps = nal;
-if (!av_base64_encode(p, MAX_PSET_SIZE - (p - psets), r, r1 - r)) {
-av_log(s, AV_LOG_ERROR, "Cannot Base64-encode %"PTRDIFF_SPECIFIER"
%"PTRDIFF_SPECIFIER"!\n", MAX_PSET_SIZE - (p - psets), r1 - r);
+if (!av_base64_encode(p, MAX_PSET_SIZE - (p - psets), nal, size)) {
+av_log(s, AV_LOG_ERROR, "Cannot Base64-encode %"PTRDIFF_SPECIFIER"
"
+ "%"PTRDIFF_SPECIFIER"!\n", MAX_PSET_SIZE - (p - psets),
size);
av_free(psets);
av_free(tmpbuf);
return NULL;
}
p += strlen(p);
-r = r1;
}
if (sps && p - psets <= MAX_PSET_SIZE - strlen(profile_string) - 7) {
memcpy(p, profile_string, strlen(profile_string));
--
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".
[FFmpeg-devel] [PATCH 11/17] avformat/avc, hevc: Avoid intermediate buffers when parsing annex B
When creating H.264 or HEVC extradata from annex B extradata or when
transforming annex B into HEVC while also filtering parameter sets away,
the whole input has first been transformed into mp4-style H.264/HEVC
in order to simplify parsing at the next step. By using ff_avc_parse_nalu,
one can avoid these intermediate steps (which involved (re)allocations).
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 28 -
libavformat/hevc.c | 52 +-
2 files changed, 23 insertions(+), 57 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index d089051034..98462940ad 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -147,7 +147,7 @@ int ff_avc_parse_nal_units_buf(const uint8_t *buf_in,
uint8_t **buf, int *size)
int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
{
AVIOContext *sps_pb = NULL, *pps_pb = NULL, *sps_ext_pb = NULL;
-uint8_t *buf, *end, *start;
+const uint8_t *nal, *nal_end, *end;
uint8_t *sps, *pps, *sps_ext;
uint32_t sps_size = 0, pps_size = 0, sps_ext_size = 0;
int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0;
@@ -162,12 +162,6 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
return 0;
}
-ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
-if (ret < 0)
-return ret;
-start = buf;
-end = buf + len;
-
ret = avio_open_dyn_buf(&sps_pb);
if (ret < 0)
goto fail;
@@ -179,12 +173,11 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
goto fail;
/* look for sps and pps */
-while (end - buf > 4) {
-uint32_t size;
-uint8_t nal_type;
-size = FFMIN(AV_RB32(buf), end - buf - 4);
-buf += 4;
-nal_type = buf[0] & 0x1f;
+nal_end = NULL;
+end = data + len;
+while (nal = ff_avc_parse_nalu(&data, &nal_end, end)) {
+uint32_t size = nal_end - nal;
+uint8_t nal_type = nal[0] & 0x1f;
if (nal_type == 7) { /* SPS */
nb_sps++;
@@ -193,7 +186,7 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
goto fail;
}
avio_wb16(sps_pb, size);
-avio_write(sps_pb, buf, size);
+avio_write(sps_pb, nal, size);
} else if (nal_type == 8) { /* PPS */
nb_pps++;
if (size > UINT16_MAX || nb_pps >= H264_MAX_PPS_COUNT) {
@@ -201,7 +194,7 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
goto fail;
}
avio_wb16(pps_pb, size);
-avio_write(pps_pb, buf, size);
+avio_write(pps_pb, nal, size);
} else if (nal_type == 13) { /* SPS_EXT */
nb_sps_ext++;
if (size > UINT16_MAX || nb_sps_ext >= 256) {
@@ -209,10 +202,8 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
goto fail;
}
avio_wb16(sps_ext_pb, size);
-avio_write(sps_ext_pb, buf, size);
+avio_write(sps_ext_pb, nal, size);
}
-
-buf += size;
}
sps_size = avio_get_dyn_buf(sps_pb, &sps);
pps_size = avio_get_dyn_buf(pps_pb, &pps);
@@ -252,7 +243,6 @@ fail:
ffio_free_dyn_buf(&sps_pb);
ffio_free_dyn_buf(&pps_pb);
ffio_free_dyn_buf(&sps_ext_pb);
-av_free(start);
return ret;
}
diff --git a/libavformat/hevc.c b/libavformat/hevc.c
index 94eb3a9cb1..095988b7df 100644
--- a/libavformat/hevc.c
+++ b/libavformat/hevc.c
@@ -35,7 +35,7 @@ typedef struct HVCCNALUnitArray {
uint8_t NAL_unit_type;
uint16_t numNalus;
uint16_t *nalUnitLength;
-uint8_t **nalUnit;
+const uint8_t **nalUnit;
} HVCCNALUnitArray;
typedef struct HEVCDecoderConfigurationRecord {
@@ -657,7 +657,7 @@ static void nal_unit_parse_header(GetBitContext *gb,
uint8_t *nal_type)
skip_bits(gb, 9);
}
-static int hvcc_array_add_nal_unit(uint8_t *nal_buf, uint32_t nal_size,
+static int hvcc_array_add_nal_unit(const uint8_t *nal_buf, uint32_t nal_size,
uint8_t nal_type, int ps_array_completeness,
HEVCDecoderConfigurationRecord *hvcc)
{
@@ -710,7 +710,7 @@ static int hvcc_array_add_nal_unit(uint8_t *nal_buf,
uint32_t nal_size,
return 0;
}
-static int hvcc_add_nal_unit(uint8_t *nal_buf, uint32_t nal_size,
+static int hvcc_add_nal_unit(const uint8_t *nal_buf, uint32_t nal_size,
int ps_array_completeness,
HEVCDecoderConfigurationRecord *hvcc)
{
@@ -1000,26 +1000,16 @@ int ff_hevc_annexb2mp4(AVIOContext *pb, const uint8_t
*buf_in,
int size, int filter_ps, int *ps_count)
{
int num_ps = 0, ret = 0;
-uint8_t *buf, *end, *start = NULL;
+const uint8_t *nal, *nal_end = NULL, *end = buf_in + size;
if (!fi
[FFmpeg-devel] [PATCH 15/17] avformat/avc: Use the constraint_setx_flags as is
and also keep the reserved_zero_2bits in the corresponding H264SPS member.
This simplifies parsing and will prove beneficial in ff_isom_write_avcc.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c| 8 +---
libavformat/avc.h| 2 +-
libavformat/mxfenc.c | 2 +-
3 files changed, 3 insertions(+), 9 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 6246410ad0..c106fe5792 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -410,13 +410,7 @@ int ff_avc_decode_sps(H264SPS *sps, const uint8_t *buf,
int buf_size)
memset(sps, 0, sizeof(*sps));
sps->profile_idc = get_bits(&gb, 8);
-sps->constraint_set_flags |= get_bits1(&gb) << 0; // constraint_set0_flag
-sps->constraint_set_flags |= get_bits1(&gb) << 1; // constraint_set1_flag
-sps->constraint_set_flags |= get_bits1(&gb) << 2; // constraint_set2_flag
-sps->constraint_set_flags |= get_bits1(&gb) << 3; // constraint_set3_flag
-sps->constraint_set_flags |= get_bits1(&gb) << 4; // constraint_set4_flag
-sps->constraint_set_flags |= get_bits1(&gb) << 5; // constraint_set5_flag
-skip_bits(&gb, 2); // reserved_zero_2bits
+sps->constraint_set_flags = get_bits(&gb, 8);
sps->level_idc = get_bits(&gb, 8);
GET_UE_GOLOMB(sps->id, H264_MAX_SPS_COUNT - 1);
diff --git a/libavformat/avc.h b/libavformat/avc.h
index db1d3334dd..2c7004a5ef 100644
--- a/libavformat/avc.h
+++ b/libavformat/avc.h
@@ -42,7 +42,7 @@ typedef struct {
uint8_t id;
uint8_t profile_idc;
uint8_t level_idc;
-uint8_t constraint_set_flags;
+uint8_t constraint_set_flags; /* Also contains the reserved_zero_*bits. */
uint8_t chroma_format_idc;
uint8_t bit_depth_luma_minus8;
uint8_t bit_depth_chroma_minus8;
diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 5eeeb9ab84..5168b17a2c 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2204,7 +2204,7 @@ static int mxf_parse_h264_frame(AVFormatContext *s,
AVStream *st,
sc->aspect_ratio.den = st->codecpar->height * sps->sar.den;
av_reduce(&sc->aspect_ratio.num, &sc->aspect_ratio.den,
sc->aspect_ratio.num, sc->aspect_ratio.den, 1024*1024);
-intra_only = (sps->constraint_set_flags >> 3) & 1;
+intra_only = (sps->constraint_set_flags >> 4) & 1;
sc->interlaced = !sps->frame_mbs_only_flag;
sc->component_depth = sps->bit_depth_luma_minus8 + 8;
--
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".
[FFmpeg-devel] [PATCH 13/17] avformat/avc: Remove trailing zero bytes during annex B->mp4 conversion
The annex B format of H.264 and HEVC allows there to be trailing zero
bytes in byte stream NAL units; this means that there can be trailing
zero bytes after the actual NAL units (besides start codes
prepended to them).
Samples in mp4 contain a sequence of length-prefixed NAL units and not
byte stream NAL units; as such, the trailing zero bytes are actually
not allowed. Therefore this commit strips them away.
Two fate-tests needed to be updated: hevc-bsf-mp4toannexb because the
HEVC parser does not properly check for four byte startcodes and instead
assigns the leading zero to the end of the preceding packet (it is now
stripped away) and lavf-fate-h264.mp4 because of an oddity of
ff_h2645_extract_rbsp: It also assigns the first byte of a four-byte
startcode to the preceding unit and this meant that the extradata (from
the extract extradata bsf) has a trailing zero at the end which is now
discarded.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c| 11 +++
tests/fate/hevc.mak | 2 +-
tests/ref/lavf-fate/h264.mp4 | 4 ++--
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 17fcd1e73f..9f375ca992 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -92,7 +92,7 @@ const uint8_t *ff_avc_find_startcode(const uint8_t *p, const
uint8_t *end){
const uint8_t *ff_avc_parse_nalu(const uint8_t **start, const uint8_t
**nal_end,
const uint8_t *end)
{
-const uint8_t *p = *start, *next;
+const uint8_t *p = *start, *next, *end_temp;
if (!p)
return NULL;
@@ -108,18 +108,21 @@ search_again:
next = avc_find_startcode_internal(p, end);
if (next) {
-*nal_end = next > p && !next[-1] ? next - 1 : next;
+end_temp = next;
next+= 3;
} else {
-*nal_end = end;
+end_temp = end;
}
-if (*nal_end == p) {
+while (end_temp > p && !end_temp[-1])
+end_temp--;
+if (end_temp == p) {
if (!next)
return NULL;
p = next;
goto search_again;
}
*start = next;
+*nal_end = end_temp;
return p;
}
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 65c5a262e9..bd94cc6cff 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -251,7 +251,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER
HEVC_MP4TOANNEXB_BSF MOV_MUXER
fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
fate-hevc-bsf-mp4toannexb: CMD = md5 -i $(TARGET_PATH)/tests/data/hevc-mp4.mov
-c:v copy -fflags +bitexact -f hevc
fate-hevc-bsf-mp4toannexb: CMP = oneline
-fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
+fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
$(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact
FATE_HEVC += fate-hevc-skiploopfilter
diff --git a/tests/ref/lavf-fate/h264.mp4 b/tests/ref/lavf-fate/h264.mp4
index bb52f45758..7a84b7a983 100644
--- a/tests/ref/lavf-fate/h264.mp4
+++ b/tests/ref/lavf-fate/h264.mp4
@@ -1,3 +1,3 @@
-6d158b25efe7391c803f6f61c7a80aa0 *tests/data/lavf-fate/lavf.h264.mp4
-547908 tests/data/lavf-fate/lavf.h264.mp4
+aaf8b3d9340ab1fdebced54ada2447d5 *tests/data/lavf-fate/lavf.h264.mp4
+547907 tests/data/lavf-fate/lavf.h264.mp4
tests/data/lavf-fate/lavf.h264.mp4 CRC=0x9da2c999
--
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 1/7] avformat/avc: Fix undefined shift and assert when reading exp-golomb num
On 7/9/2020 7:35 AM, Andreas Rheinhardt wrote:
> The current code for parsing unsigned exponential-golomb codes is not
> suitable for long codes: If there are enough leading zeroes, it
> left-shifts 1 by 32 places and uses get_bitsz to read 32 bits, although
> it is only suitable to read 0-25 bits. There is an av_assert2 to
> ensure this when using the uncached bitstream reader; with valid input
> one can still run into the assert and left-shift 1 by 31 which is
> undefined.
>
> This commit changes this. All valid data is parsed correctly; invalid
> data does no longer lead to undefined behaviour or to asserts. Parsing
> all valid data correctly also necessitated changing the return value to
> unsigned; also an intermediate variable used for parsing signed
> exponential-golomb codes needed to be made unsigned, too, in order to
> parse long signed codes correctly.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Moving the function to the beginning is done in preparation for another
> commit that I'll send soon.
>
> libavformat/avc.c | 24
> 1 file changed, 16 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/avc.c b/libavformat/avc.c
> index b5e2921388..55494eb08a 100644
> --- a/libavformat/avc.c
> +++ b/libavformat/avc.c
> @@ -27,6 +27,21 @@
> #include "avc.h"
> #include "avio_internal.h"
>
> +static inline unsigned get_ue_golomb(GetBitContext *gb)
> +{
> +int i;
> +for (i = 1; i <= 32; i++) {
> +if (get_bits_left(gb) < i)
> +return 0;
> +if (show_bits1(gb))
> +break;
> +skip_bits1(gb);
> +}
> +if (i > 32)
> +return 0;
> +return get_bits_long(gb, i) - 1;
> +}
> +
> static const uint8_t *avc_find_startcode_internal(const uint8_t *p, const
> uint8_t *end)
> {
> const uint8_t *a = p + 4 - ((intptr_t)p & 3);
> @@ -318,15 +333,8 @@ static const AVRational avc_sample_aspect_ratio[17] = {
> { 2, 1 },
> };
>
> -static inline int get_ue_golomb(GetBitContext *gb) {
> -int i;
> -for (i = 0; i < 32 && !get_bits1(gb); i++)
> -;
> -return get_bitsz(gb, i) + (1 << i) - 1;
> -}
> -
> static inline int get_se_golomb(GetBitContext *gb) {
> -int v = get_ue_golomb(gb) + 1;
> +unsigned v = get_ue_golomb(gb) + 1;
> int sign = -(v & 1);
> return ((v >> 1) ^ sign) - sign;
> }
I think it's best if we use the lavc golomb code instead. When i
suggested to re implement it here i wasn't aware it was shared with lavf
within the golomb_tab.c source file.
___
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 16/17] avformat/avc: Improve writing AVCDecoderConfigurationRecord
According to the specifications, both the SPS as well as the PPS in
an AVCDecoderConfigurationRecord (the mp4-style extradata for H.264) are
supposed to be ordered according to increasing SPS/PPS id.
ff_isom_write_avcc did not ensure this; in fact, it did not even ensure
that there are no two parameter sets of the same type with the same id.
This commit changes this. Only the last occurence of any SPS/PPS id is
kept, i.e. just like with in-band parameter sets, new parameter sets
overwrite old parameter sets with the same id, and those parameter sets
that are kept are written in the order of their id.
This also led to the removal of one round of copying implicit in the
usage of dynamic buffers.
(mkvextract simply converts the mp4-style extradata contained in the
CodecPrivate of a Matroska file and prepends it to the frame data (which
is also converted to annex B); if the file had in-band extradata, the
created file would have the extradata twice at the beginning and
extract_extradata would include all of these parameter sets.)
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 131 +++---
1 file changed, 66 insertions(+), 65 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index c106fe5792..0f43b295a4 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -167,13 +167,32 @@ int ff_avc_parse_nal_units_buf(const uint8_t *buf_in,
uint8_t **buf, int *size)
return 0;
}
+static void write_array(AVIOContext *pb, const uint8_t *const *ps,
+const uint16_t *const ps_sizes,
+int nb_ps, int array_size, uint8_t reserved)
+{
+avio_w8(pb, reserved | nb_ps);
+for (int i = 0; i < array_size; i++) {
+if (ps_sizes[i]) {
+avio_wb16(pb, ps_sizes[i]);
+avio_write(pb, ps[i], ps_sizes[i]);
+nb_ps--;
+}
+}
+av_assert1(nb_ps == 0);
+}
+
int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
{
-AVIOContext *sps_pb = NULL, *pps_pb = NULL, *sps_ext_pb = NULL;
const uint8_t *nal, *nal_end, *end;
-uint8_t *sps, *pps, *sps_ext;
-uint32_t sps_size = 0, pps_size = 0, sps_ext_size = 0;
int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0;
+const uint8_t *sps[H264_MAX_SPS_COUNT];
+const uint8_t *pps[H264_MAX_PPS_COUNT];
+const uint8_t *sps_ext[H264_MAX_SPS_COUNT];
+uint16_t sps_sizes[H264_MAX_SPS_COUNT] = { 0 };
+uint16_t pps_sizes[H264_MAX_PPS_COUNT] = { 0 };
+uint16_t sps_ext_sizes[H264_MAX_SPS_COUNT] = { 0 };
+H264SPS seq;
if (len <= 6)
return AVERROR_INVALIDDATA;
@@ -185,16 +204,6 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
return 0;
}
-ret = avio_open_dyn_buf(&sps_pb);
-if (ret < 0)
-goto fail;
-ret = avio_open_dyn_buf(&pps_pb);
-if (ret < 0)
-goto fail;
-ret = avio_open_dyn_buf(&sps_ext_pb);
-if (ret < 0)
-goto fail;
-
/* look for sps and pps */
nal_end = NULL;
end = data + len;
@@ -203,71 +212,63 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
uint8_t nal_type = nal[0] & 0x1f;
if (nal_type == 7) { /* SPS */
-nb_sps++;
-if (size > UINT16_MAX || nb_sps >= H264_MAX_SPS_COUNT) {
-ret = AVERROR_INVALIDDATA;
-goto fail;
-}
-avio_wb16(sps_pb, size);
-avio_write(sps_pb, nal, size);
-} else if (nal_type == 8) { /* PPS */
-nb_pps++;
-if (size > UINT16_MAX || nb_pps >= H264_MAX_PPS_COUNT) {
-ret = AVERROR_INVALIDDATA;
-goto fail;
-}
-avio_wb16(pps_pb, size);
-avio_write(pps_pb, nal, size);
-} else if (nal_type == 13) { /* SPS_EXT */
-nb_sps_ext++;
-if (size > UINT16_MAX || nb_sps_ext >= 256) {
-ret = AVERROR_INVALIDDATA;
-goto fail;
+if (size > UINT16_MAX)
+return AVERROR_INVALIDDATA;
+ret = ff_avc_decode_sps(&seq, nal + 1, size - 1);
+if (ret < 0)
+return ret;
+nb_sps += 1 - !!sps_sizes[seq.id];
+sps[seq.id] = nal;
+sps_sizes[seq.id] = size;
+} else if (nal_type == H264_NAL_PPS || nal_type == H264_NAL_SPS_EXT) {
+GetBitContext gb;
+unsigned id;
+if (size > UINT16_MAX)
+return AVERROR_INVALIDDATA;
+/* No need to unescape here */
+ret = init_get_bits8(&gb, nal + 1, size - 1);
+av_assert1(ret >= 0);
+ret = get_ue_golomb(&gb, &id);
+if (ret < 0)
+return ret;
+if (nal_type == H264_NAL_PPS) {
+if (id >= H264_MAX_PPS_COUNT)
+return AVERROR_INVALIDDATA;
+
[FFmpeg-devel] [PATCH 17/17] avformat/avc: Don't discard SPS extensions for some profiles
For some profiles, the AVCDecoderConfigurationRecord contains an array
containing all the SPS Extension NAL units; for the other profiles,
these NAL units should be put into the SPS array. Yet the latter hasn't
been done. This commit implements it.
Signed-off-by: Andreas Rheinhardt
---
Honestly, I have no sample containing an SPS extension, so this is
untested.
Btw: The spec is quiet on the order in the SPS array in this case.
Should it be all SPS first, then the extensions or should the it be that
an SPS is immediately followed by its extension (if present) followed by
the next SPS? All it says is that they should be placed in the SPS
array.
libavformat/avc.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 0f43b295a4..84a55fdc98 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -185,13 +185,13 @@ static void write_array(AVIOContext *pb, const uint8_t
*const *ps,
int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
{
const uint8_t *nal, *nal_end, *end;
-int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0;
-const uint8_t *sps[H264_MAX_SPS_COUNT];
+int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0, ext_in_sps_array;
+const uint8_t *sps[2 * H264_MAX_SPS_COUNT];
const uint8_t *pps[H264_MAX_PPS_COUNT];
-const uint8_t *sps_ext[H264_MAX_SPS_COUNT];
-uint16_t sps_sizes[H264_MAX_SPS_COUNT] = { 0 };
+uint16_t sps_sizes[2 * H264_MAX_SPS_COUNT] = { 0 };
uint16_t pps_sizes[H264_MAX_PPS_COUNT] = { 0 };
-uint16_t sps_ext_sizes[H264_MAX_SPS_COUNT] = { 0 };
+const uint8_t **const sps_ext = &sps[H264_MAX_SPS_COUNT];
+uint16_t *const sps_ext_sizes = &sps_sizes[H264_MAX_SPS_COUNT];
H264SPS seq;
if (len <= 6)
@@ -249,8 +249,14 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
}
}
-if (!nb_sps || nb_sps == H264_MAX_SPS_COUNT ||
-!nb_pps || nb_pps == H264_MAX_PPS_COUNT)
+if (!nb_sps || !nb_pps)
+return AVERROR_INVALIDDATA;
+ext_in_sps_array = seq.profile_idc == 66 ||
+ seq.profile_idc == 77 ||
+ seq.profile_idc == 88;
+if (ext_in_sps_array)
+nb_sps += nb_sps_ext;
+if (nb_sps >= H264_MAX_SPS_COUNT || nb_pps >= H264_MAX_PPS_COUNT)
return AVERROR_INVALIDDATA;
avio_w8(pb, 1); /* version */
@@ -258,10 +264,11 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
avio_w8(pb, seq.constraint_set_flags); /* profile compat */
avio_w8(pb, seq.level_idc);
avio_w8(pb, 0xff); /* 6 bits reserved (11) + 2 bits nal size length -
1 (11) */
-write_array(pb, sps, sps_sizes, nb_sps, H264_MAX_SPS_COUNT, 0xe0);
+write_array(pb, sps, sps_sizes, nb_sps,
+H264_MAX_SPS_COUNT * (1 + ext_in_sps_array), 0xe0);
write_array(pb, pps, pps_sizes, nb_pps, H264_MAX_PPS_COUNT, 0x00);
-if (seq.profile_idc != 66 && seq.profile_idc != 77 && seq.profile_idc !=
88) {
+if (!ext_in_sps_array) {
avio_w8(pb, 0xfc | seq.chroma_format_idc); /* 6 bits reserved
(11) + chroma_format_idc */
avio_w8(pb, 0xf8 | seq.bit_depth_luma_minus8); /* 5 bits reserved
(1) + bit_depth_luma_minus8 */
avio_w8(pb, 0xf8 | seq.bit_depth_chroma_minus8); /* 5 bits reserved
(1) + bit_depth_chroma_minus8 */
--
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".
[FFmpeg-devel] [PATCH 14/17] avformat/avc: Be more strict when parsing SPS
This commit adds some basic checks for invalid values when parsing an
SPS; e.g. the earlier code did not check whether the values read from
the bitstream get truncated when returned via the H264SPS struct (whose
members are uint8_t), so that a caller could not even check for this
error itself.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c| 91
libavformat/avc.h| 4 +-
libavformat/mxfenc.c | 2 +-
3 files changed, 61 insertions(+), 36 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index 9f375ca992..6246410ad0 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -27,19 +27,32 @@
#include "avc.h"
#include "avio_internal.h"
-static inline unsigned get_ue_golomb(GetBitContext *gb)
+static int get_ue_golomb(GetBitContext *gb, unsigned *val)
{
int i;
for (i = 1; i <= 32; i++) {
if (get_bits_left(gb) < i)
-return 0;
+return AVERROR_INVALIDDATA;
if (show_bits1(gb))
break;
skip_bits1(gb);
}
if (i > 32)
-return 0;
-return get_bits_long(gb, i) - 1;
+return AVERROR_INVALIDDATA;
+*val = get_bits_long(gb, i) - 1;
+return 0;
+}
+
+static int get_se_golomb(GetBitContext *gb, int *val)
+{
+unsigned v;
+int sign, ret = get_ue_golomb(gb, &v);
+
+if (ret < 0)
+return ret;
+sign = -(v & 1);
+*val = ((v >> 1) ^ sign) - sign;
+return 0;
}
static const uint8_t *avc_find_startcode_internal(const uint8_t *p, const
uint8_t *end)
@@ -242,8 +255,8 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
goto fail;
avio_w8(pb, 0xfc | seq.chroma_format_idc); /* 6 bits reserved
(11) + chroma_format_idc */
-avio_w8(pb, 0xf8 | (seq.bit_depth_luma - 8)); /* 5 bits reserved
(1) + bit_depth_luma_minus8 */
-avio_w8(pb, 0xf8 | (seq.bit_depth_chroma - 8)); /* 5 bits reserved
(1) + bit_depth_chroma_minus8 */
+avio_w8(pb, 0xf8 | seq.bit_depth_luma_minus8); /* 5 bits reserved
(1) + bit_depth_luma_minus8 */
+avio_w8(pb, 0xf8 | seq.bit_depth_chroma_minus8); /* 5 bits reserved
(1) + bit_depth_chroma_minus8 */
avio_w8(pb, nb_sps_ext); /* number of sps ext */
if (nb_sps_ext)
avio_write(pb, sps_ext, sps_ext_size);
@@ -357,12 +370,26 @@ static const AVRational avc_sample_aspect_ratio[17] = {
{ 2, 1 },
};
-static inline int get_se_golomb(GetBitContext *gb) {
-unsigned v = get_ue_golomb(gb) + 1;
-int sign = -(v & 1);
-return ((v >> 1) ^ sign) - sign;
-}
-
+#define GET_UE_GOLOMB(dst, max) do { \
+unsigned val;\
+ret = get_ue_golomb(&gb, &val); \
+if (ret < 0) \
+goto end;\
+if (val > (max)) { \
+ret = AVERROR_INVALIDDATA; \
+goto end;\
+}\
+(dst) = val; \
+} while (0)
+#define GET_SE_GOLOMB(dst) do { \
+int val; \
+ret = get_se_golomb(&gb, &val); \
+if (ret < 0) \
+goto end;\
+(dst) = val; \
+} while (0)
+#define SKIP_UE_GOLOMB GET_UE_GOLOMB(val, UINT_MAX)
+#define SKIP_SE_GOLOMB GET_SE_GOLOMB(val)
int ff_avc_decode_sps(H264SPS *sps, const uint8_t *buf, int buf_size)
{
int i, j, ret, rbsp_size, aspect_ratio_idc, pic_order_cnt_type;
@@ -391,19 +418,19 @@ int ff_avc_decode_sps(H264SPS *sps, const uint8_t *buf,
int buf_size)
sps->constraint_set_flags |= get_bits1(&gb) << 5; // constraint_set5_flag
skip_bits(&gb, 2); // reserved_zero_2bits
sps->level_idc = get_bits(&gb, 8);
-sps->id = get_ue_golomb(&gb);
+GET_UE_GOLOMB(sps->id, H264_MAX_SPS_COUNT - 1);
if (sps->profile_idc == 100 || sps->profile_idc == 110 ||
sps->profile_idc == 122 || sps->profile_idc == 244 || sps->profile_idc
== 44 ||
sps->profile_idc == 83 || sps->profile_idc == 86 || sps->profile_idc
== 118 ||
sps->profile_idc == 128 || sps->profile_idc == 138 || sps->profile_idc
== 139 ||
sps->profile_idc == 134) {
-sps->chroma_format_idc = get_ue_golomb(&gb); // chroma_format_idc
+GET_UE_GOLOMB(sps->chroma_format_idc, 3);
if (sps->chroma_format_idc == 3) {
skip_bits1(&gb); // separate_colour_plane_flag
}
-sps->bit_depth_luma = get_ue_golomb(&gb) + 8;
-sps->bit_depth_chroma = get_ue_golomb(&gb) + 8;
+GET_UE_GOLOMB(sps->bit_depth_luma_minus8, 6);
+GET_UE_GOLOMB(sps->bit_depth_chroma_minus8, 6);
skip_bits1(&gb); // qpprime_y_zero_transform_bypass_flag
if (get_bits1(&gb)) { // seq_scaling_matrix_present_flag
for (i = 0; i < ((sps->chroma_format_idc != 3) ? 8 : 12); i++) {
@@ -414,7 +441,7 @@ int ff_avc_decode_sps(H264S
Re: [FFmpeg-devel] [PATCH v1 1/3] doc/developer.texi: Improvements in "Submitting patches" section.
On Thu, Jul 09, 2020 at 02:01:45AM +0200, Manolis Stamatogiannakis wrote:
> On Tue, 7 Jul 2020 at 16:00, Nicolas George wrote:
>
> > Manolis Stamatogiannakis (12020-07-05):
[...]
> > > +Additionally, it is recommended to register for a
> > > +@uref{https://patchwork.ffmpeg.org, patchwork account}.
> > > +This will allow you to mark previous version of your patches as
> > "Superseded",
> > > +and reduce the chance of someone spending time to review a stale patch.
> >
> > Is interacting with Patchwork to become mandatory when submitting
> > patches?
> >
>
> Nicolas, why would you ever interpret "recommended" as mandatory? I think
> it's as clear as it gets that it is not mandatory.
>
> Again, this is a good practice which was not mentioned in the
> documentation. I have no attachment whatsoever to the tool, or intention to
> impose it to anyone.
>
> @Michael Niedermayer, since you seem to be the most involved with patchwork
> in the thread, what would be better for this? Keep the wording as a
> recommendation, or to move it outside the list as purely informational text?
I think there are 2 aspects here
First is a "mostly automatic patchwork with only people who want to play with
it obtaining accounts and doing something with them" vs one where its
recommanded to get accounts
These are 2 different philosophies ;)
Second is, time vs time
Is the gain from manually working with patchwork saving us more time elsewhere
while
we achieve the same quality of code?
and Third
Can we not automate whatever we would do manually ?
And describing the actual cases with examples what is wrong and needs manual
update would be interresting.
Are these caseses that are clear to human but unclear to a computer ?
or we are just missing a line or 2 in the script ?
or are they maybe unclear to humans too ? which could then lead
a discussion on how to make that clear to humans first ...
I think its needed to understand where automation fails to really discuss
this all
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides
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 v6 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Thu, 9 Jul 2020, lance.lmw...@gmail.com wrote:
On Wed, Jul 08, 2020 at 11:59:17PM +0200, Marton Balint wrote:
On Wed, 8 Jul 2020, lance.lmw...@gmail.com wrote:
> On Wed, Jul 01, 2020 at 09:39:58PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavdevice/decklink_dec.cpp | 16
> > 1 file changed, 16 insertions(+)
> >
> > diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
> > index 82106aa..0fc1489 100644
> > --- a/libavdevice/decklink_dec.cpp
> > +++ b/libavdevice/decklink_dec.cpp
> > @@ -41,6 +41,7 @@ extern "C" {
> > #include "libavutil/imgutils.h"
> > #include "libavutil/intreadwrite.h"
> > #include "libavutil/time.h"
> > +#include "libavutil/timecode.h"
> > #include "libavutil/mathematics.h"
> > #include "libavutil/reverse.h"
> > #include "avdevice.h"
> > @@ -778,6 +779,21 @@ HRESULT
decklink_input_callback::VideoInputFrameArrived(
> > AVDictionary* metadata_dict = NULL;
> > int metadata_len;
> > uint8_t* packed_metadata;
> > +AVTimecode tcr;
> > +uint32_t tc_data;
> > +uint8_t *sd;
> > +int size = sizeof(uint32_t) * 4;
You can push some of these initializers into the blocks in which they are
used.
Sure, will fix it.
> > +
> > +if (av_timecode_init_from_string(&tcr,
ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > +if ((tc_data =
av_timecode_get_smpte_from_framenum(&tcr, 0)) > 0) {
av_timecode_get_smpte_from_framenum() always succeeds, so this check is
wrong.
OK, will fix it.
Also in theory you could query the color framing flag from the decklink api.
av_timecode_get_smpte_from_framenum() assume the Color Frame flag is zero
always, and the conversion from frame to string didn't support the color frame
flag also, so even we set the flag, it's not used still.
It is a matter of setting a single bit of tc_data, you don't need to add
API for it.
Do you insist that this version must support this feature?
No, but if the DeckLink API supports it, and the side data supports it
then why not? It should be no more than 2 lines of additional code:
unsigned color_flag = !!(timecode->GetFlags() & bmdTimecodeColorFrame);
...
tc_data |= color_flag << 31;
Or am I missing something?
Regards,
Marton
Regards,
Marton
> > +sd = av_packet_new_side_data(&pkt,
AV_PKT_DATA_S12M_TIMECODE, size);
> > +if (sd) {
> > +AV_WL32(sd, 1); // one TC ;
> > +AV_WL32(sd + 4, tc_data); // TC;
> > +}
> > +}
> > +}
> > +
> > if (av_dict_set(&metadata_dict, "timecode", tc,
AV_DICT_DONT_STRDUP_VAL) >= 0) {
> > packed_metadata =
av_packet_pack_dictionary(metadata_dict, &metadata_len);
> > av_dict_free(&metadata_dict);
> > --
> > 1.8.3.1
> >
>
> Marton, please help to review and give comments.
>
> --
> 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".
___
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".
--
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".
___
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] libavfilter/vf_codecview: enable qp visualization for H264 and VP9
On Mon, Jul 6, 2020 at 10:56 AM Yongle Lin wrote:
>
>
> On Thu, Jun 25, 2020 at 12:09 PM Yongle Lin
> wrote:
>
>> Add qp visualization in codecview filter which supports H264 and VP9
>> codecs. Add options for luma/chroma qp and AC/DC qp as well. There is a old
>> way to visualize it but it's deprecated since version 58.
>> example command line to visualize qp:
>> ./ffmpeg -export_side_data +venc_params -i input.mp4 -vf
>> codecview=qp=true output.mp4
>> ---
>> doc/filters.texi | 6
>> libavfilter/vf_codecview.c | 69 +-
>> 2 files changed, 74 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 84567dec16..f4a57e993f 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -7285,6 +7285,12 @@ backward predicted MVs of B-frames
>> @item qp
>> Display quantization parameters using the chroma planes.
>>
>> +@item chroma_qp
>> +Display chroma quantization parameters (default luma qp) using the
>> chroma planes. Should use with qp option. (e.g.
>> codecview=qp=true:chroma_qp=true)
>> +
>> +@item dc_qp
>> +Display DC quantization parameters (default AC qp) using the chroma
>> planes. Should use with qp option. (e.g. codecview=qp=true:dc_qp=true)
>> +
>> @item mv_type, mvt
>> Set motion vectors type to visualize. Includes MVs from all frames
>> unless specified by @var{frame_type} option.
>>
>> diff --git a/libavfilter/vf_codecview.c b/libavfilter/vf_codecview.c
>> index 331bfba777..f585dfe28e 100644
>> --- a/libavfilter/vf_codecview.c
>> +++ b/libavfilter/vf_codecview.c
>> @@ -34,6 +34,7 @@
>> #include "libavutil/opt.h"
>> #include "avfilter.h"
>> #include "internal.h"
>> +#include "libavutil/video_enc_params.h"
>>
>> #define MV_P_FOR (1<<0)
>> #define MV_B_FOR (1<<1)
>> @@ -51,6 +52,8 @@ typedef struct CodecViewContext {
>> unsigned mv_type;
>> int hsub, vsub;
>> int qp;
>> +int chroma_qp;
>> +int dc_qp;
>> } CodecViewContext;
>>
>> #define OFFSET(x) offsetof(CodecViewContext, x)
>> @@ -63,6 +66,8 @@ static const AVOption codecview_options[] = {
>> CONST("bf", "forward predicted MVs of B-frames", MV_B_FOR,
>> "mv"),
>> CONST("bb", "backward predicted MVs of B-frames", MV_B_BACK,
>> "mv"),
>> { "qp", NULL, OFFSET(qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, .flags =
>> FLAGS },
>> +{ "chroma_qp", NULL, OFFSET(chroma_qp), AV_OPT_TYPE_BOOL, {.i64=0},
>> 0, 1, .flags = FLAGS },
>> +{ "dc_qp", NULL, OFFSET(dc_qp), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
>> .flags = FLAGS },
>> { "mv_type", "set motion vectors type", OFFSET(mv_type),
>> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
>> { "mvt", "set motion vectors type", OFFSET(mv_type),
>> AV_OPT_TYPE_FLAGS, {.i64=0}, 0, INT_MAX, FLAGS, "mv_type" },
>> CONST("fp", "forward predicted MVs", MV_TYPE_FOR, "mv_type"),
>> @@ -212,6 +217,52 @@ static void draw_arrow(uint8_t *buf, int sx, int sy,
>> int ex,
>> draw_line(buf, sx, sy, ex, ey, w, h, stride, color);
>> }
>>
>> +static int qp_color_calculate(int qp, enum AVVideoEncParamsType type) {
>> +return type == AV_VIDEO_ENC_PARAMS_H264 ? qp * 128 / 31 : qp;
>> +}
>> +
>> +static void get_block_color(AVVideoEncParams *par, AVVideoBlockParams
>> *b, CodecViewContext *s, enum AVColorRange color_range, int *cu, int *cv)
>> +{
>> +const int plane_qp_cu_index = s->chroma_qp ? 1 : 0;
>> +const int plane_qp_cv_index = s->chroma_qp ? 2 : 0;
>> +const int ac_dc_index = s->dc_qp ? 0 : 1;
>> +*cu = qp_color_calculate(par->qp +
>> par->delta_qp[plane_qp_cu_index][ac_dc_index] + b->delta_qp, par->type);
>> +*cv = qp_color_calculate(par->qp +
>> par->delta_qp[plane_qp_cv_index][ac_dc_index] + b->delta_qp, par->type);
>> +if (color_range == AVCOL_RANGE_MPEG) {
>> +// map jpeg color range(0-255) to mpeg color range(16-235)
>> +*cu = av_rescale(*cu, 73, 85) + 16;
>> +*cv = av_rescale(*cv, 73, 85) + 16;
>> +}
>> +}
>> +
>> +static void color_block(AVFrame *frame, CodecViewContext *s, const int
>> src_x, const int src_y, const int b_w, const int b_h, const int cu, const
>> int cv)
>> +{
>> +const int w = AV_CEIL_RSHIFT(frame->width, s->hsub);
>> +const int h = AV_CEIL_RSHIFT(frame->height, s->vsub);
>> +const int lzu = frame->linesize[1];
>> +const int lzv = frame->linesize[2];
>> +
>> +const int plane_src_x = src_x >> s->hsub;
>> +const int plane_src_y = src_y >> s->vsub;
>> +const int plane_b_w = b_w >> s->hsub;
>> +const int plane_b_h = b_h >> s->vsub;
>> +uint8_t *pu = frame->data[1] + plane_src_y * lzu;
>> +uint8_t *pv = frame->data[2] + plane_src_y * lzv;
>> +
>> +for (int y = plane_src_y; y < plane_src_y + plane_b_h; y++) {
>> +for (int x = plane_src_x; x < plane_src_x + plane_b_w; x++) {
>> +if (x >= w)
>> +break;
>> +pu[x] = cu;
>> +pv[x] = cv;
>> +}
>> +if
Re: [FFmpeg-devel] [PATCH] libavcodec/vp9: export block structure when segmentation isn't enable
On Mon, Jul 6, 2020 at 11:31 AM Yongle Lin wrote:
> it makes sense to export block structure like src_x, src_y, width and
> height when segmentation isn't enable so we could visualize and see the
> structure of the block.
> ---
> libavcodec/vp9.c | 8 +++-
> 1 file changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index fd0bab14a2..e700def70e 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -1501,10 +1501,8 @@ static int vp9_export_enc_params(VP9Context *s,
> VP9Frame *frame)
> AVVideoEncParams *par;
> unsigned int tile, nb_blocks = 0;
>
> -if (s->s.h.segmentation.enabled) {
> -for (tile = 0; tile < s->active_tile_cols; tile++)
> -nb_blocks += s->td[tile].nb_block_structure;
> -}
> +for (tile = 0; tile < s->active_tile_cols; tile++)
> +nb_blocks += s->td[tile].nb_block_structure;
>
> par = av_video_enc_params_create_side_data(frame->tf.f,
> AV_VIDEO_ENC_PARAMS_VP9, nb_blocks);
> @@ -1536,7 +1534,7 @@ static int vp9_export_enc_params(VP9Context *s,
> VP9Frame *frame)
> b->w = 1 << (3 +
> td->block_structure[block_tile].block_size_idx_x);
> b->h = 1 << (3 +
> td->block_structure[block_tile].block_size_idx_y);
>
> -if (s->s.h.segmentation.feat[seg_id].q_enabled) {
> +if (s->s.h.segmentation.enabled &&
> s->s.h.segmentation.feat[seg_id].q_enabled) {
> b->delta_qp = s->s.h.segmentation.feat[seg_id].q_val;
> if (s->s.h.segmentation.absolute_vals)
> b->delta_qp -= par->qp;
> --
> 2.27.0.383.g050319c2ae-goog
>
>
Dear FFmpeg Developers,
Currently ffmpeg doesn't export the block data for VP9 if there is no
segmentation. Because it's only used to export QP value. I think it makes
more sense to export the block information without segmentation so we could
visualize the block structure for VP9 video.
Could you please review and merge this patch? Thanks.
Best,
Yongle
___
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] libavfilter/vf_codecview: add block structure visualization
On Thu, Jul 2, 2020 at 8:09 AM Michael Niedermayer wrote: > On Wed, Jul 01, 2020 at 05:42:48PM +, Yongle Lin wrote: > > example command line to visualize block decomposition: > > ./ffmpeg -export_side_data +venc_params -i input.webm -vf > > codecview=bs=true output.webm > > --- > > > doc/filters.texi | 3 +++ > > libavcodec/vp9.c | 8 +++- > > libavfilter/vf_codecview.c | 41 ++ > > the vp9 and vf_codecview changes belong in seperate patches, these are 2 > seperate libs > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In a rich man's house there is no place to spit but his face. > -- Diogenes of Sinope > ___ > 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". Hey Michael, I have splitted the patches and sent it to you. Do you have any other suggestions on this patch? Thanks Best Regards, Yongle ___ 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] avcodec/mjpeg_parser: Adjust size rejection threshold
Fixes: 86987846-429c8d80-c197-11ea-916b-bb4738e09687.jpg
Fixes: Regression since ec3d8a0e6945fe015d16cd98a1e7dbb4be815c15
Signed-off-by: Michael Niedermayer
---
libavcodec/mjpeg_parser.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
index c642b2ecbc..f54fdd37cb 100644
--- a/libavcodec/mjpeg_parser.c
+++ b/libavcodec/mjpeg_parser.c
@@ -82,7 +82,7 @@ static int find_frame_end(MJPEGParserContext *m, const
uint8_t *buf, int buf_siz
return i-3;
} else if(state<0xFFD0 || state>0xFFD9){
m->size= (state&0x)-1;
-if (m->size >= 0x8000)
+if (m->size >= 0xF000)
m->size = 0;
}
}
--
2.17.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 v6 2/3] API: add AV_PKT_DATA_S12M_TIMECODE to AVPacketSideDataType
Given the questions regarding the format used for the timecodes, this
patch from my personal repo might help:
commit e4c9ae661fb55e59eff1461140a8cd039b7c3f04
Author: Devin Heitmueller
Date: Thu Jul 5 17:18:36 2018 -0400
Clarify where the binary representation comes from for ffmpeg's SMPTE struct
There are a number of different binary representations in which
SMPTE timecodes can use. Make clear that the specific representation
that ffmpeg refers to corresponds to the DV video spec, which is
SMPTE S314M:2005 for standard definition video and ST 370-2013 for
high definition video.
diff --git a/libavutil/timecode.c b/libavutil/timecode.c
index e9d8504ee7..93bba2af31 100644
--- a/libavutil/timecode.c
+++ b/libavutil/timecode.c
@@ -117,6 +117,7 @@ static unsigned bcd2uint(uint8_t bcd)
char *av_timecode_make_smpte_tc_string(char *buf, uint32_t tcsmpte,
int prevent_df)
{
+/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */
unsigned hh = bcd2uint(tcsmpte & 0x3f);// 6-bit hours
unsigned mm = bcd2uint(tcsmpte>>8 & 0x7f);// 7-bit minutes
unsigned ss = bcd2uint(tcsmpte>>16 & 0x7f);// 7-bit seconds
On Wed, Jul 1, 2020 at 9:40 AM wrote:
>
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> doc/APIchanges| 3 +++
> libavcodec/avpacket.c | 1 +
> libavcodec/decode.c | 1 +
> libavcodec/packet.h | 8
> libavcodec/version.h | 2 +-
> libavformat/dump.c| 21 +
> 6 files changed, 35 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 1d6cc36..7aa8d9e 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2020-06-xx - xx - lavc 58.94.101 - packet.h
> + Add AV_PKT_DATA_S12M_TIMECODE.
> +
> 2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
>Add AV_PIX_FMT_X2RGB10.
>
> diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> index dce26cb..4801163 100644
> --- a/libavcodec/avpacket.c
> +++ b/libavcodec/avpacket.c
> @@ -400,6 +400,7 @@ const char *av_packet_side_data_name(enum
> AVPacketSideDataType type)
> case AV_PKT_DATA_PRFT: return "Producer Reference
> Time";
> case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
> case AV_PKT_DATA_DOVI_CONF: return "DOVI configuration
> record";
> +case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST 12-1:2014
> timecode";
> }
> return NULL;
> }
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index de9c079..f2244fc 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1699,6 +1699,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> AVFrame *frame)
> { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
> { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
> { AV_PKT_DATA_ICC_PROFILE,AV_FRAME_DATA_ICC_PROFILE
> },
> +{ AV_PKT_DATA_S12M_TIMECODE,
> AV_FRAME_DATA_S12M_TIMECODE },
> };
>
> if (pkt) {
> diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> index 96f237f..0a19a0e 100644
> --- a/libavcodec/packet.h
> +++ b/libavcodec/packet.h
> @@ -283,6 +283,14 @@ enum AVPacketSideDataType {
> AV_PKT_DATA_DOVI_CONF,
>
> /**
> + * Timecode which conforms to SMPTE ST 12-1:2014. The data is an array
> of 4 uint32_t
> + * where the first uint32_t describes how many (1-3) of the other
> timecodes are used.
> + * The timecode format is described in the documentation of
> av_timecode_get_smpte_from_framenum()
> + * function in libavutil/timecode.h.
> + */
> +AV_PKT_DATA_S12M_TIMECODE,
> +
> +/**
> * The number of side data types.
> * This is not part of the public API/ABI in the sense that it may
> * change when new side data types are added.
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 05f5990..51fba22 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -28,7 +28,7 @@
> #include "libavutil/version.h"
>
> #define LIBAVCODEC_VERSION_MAJOR 58
> -#define LIBAVCODEC_VERSION_MINOR 93
> +#define LIBAVCODEC_VERSION_MINOR 94
> #define LIBAVCODEC_VERSION_MICRO 101
>
> #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 1083d7d..46db039 100644
> --- a/libavformat/dump.c
> +++ b/libavformat/dump.c
> @@ -34,6 +34,7 @@
> #include "libavutil/replaygain.h"
> #include "libavutil/spherical.h"
> #include "libavutil/stereo3d.h"
> +#include "libavutil/timecode.h"
>
> #include "avformat.h"
>
> @@ -407,6 +408,22 @@ static void dump_dovi_conf(void *ctx, const
> AVPacketSideData *sd)
> dovi->dv_bl_signal_compatibility_id);
> }
>
> +static void dump_s12m_timecode(void *ctx, const AVPacketSideD
Re: [FFmpeg-devel] [PATCH] avformat/hls: Use probing parameters for actual stream
On Mon, Mar 16, 2020 at 7:00 PM Jacek Tomasiak wrote: > > HLS input streams ignored CLI parameters which control the probing > process. Each stream was initialized with fresh context and used > the default values for probing. > --- > libavformat/hls.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/libavformat/hls.c b/libavformat/hls.c > index 1f58e745a7..5954b1d2d9 100644 > --- a/libavformat/hls.c > +++ b/libavformat/hls.c > @@ -1919,6 +1919,14 @@ static int hls_read_header(AVFormatContext *s) > pls->needed = 1; > pls->parent = s; > > +/* Pass top-level probing parameters to actual stream */ > +pls->ctx->probesize = s->probesize; > +pls->ctx->format_probesize = s->format_probesize; > +pls->ctx->max_analyze_duration = s->max_analyze_duration; I think HLS demuxer have enable the probesize/max_analyze_duration > +pls->ctx->fps_probe_size = s->fps_probe_size; > +pls->ctx->max_ts_probe = s->max_ts_probe; > +pls->ctx->max_probe_packets = s->max_probe_packets; > + > /* > * If this is a live stream and this playlist looks like it is one > segment > * behind, try to sync it up so that every substream starts at the > same > -- > 2.16.4 > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 2/3] API: add AV_PKT_DATA_S12M_TIMECODE to AVPacketSideDataType
On Thu, Jul 09, 2020 at 07:16:28PM -0400, Devin Heitmueller wrote:
> Given the questions regarding the format used for the timecodes, this
> patch from my personal repo might help:
>
> commit e4c9ae661fb55e59eff1461140a8cd039b7c3f04
> Author: Devin Heitmueller
> Date: Thu Jul 5 17:18:36 2018 -0400
> Clarify where the binary representation comes from for ffmpeg's SMPTE
> struct
>
> There are a number of different binary representations in which
> SMPTE timecodes can use. Make clear that the specific representation
> that ffmpeg refers to corresponds to the DV video spec, which is
> SMPTE S314M:2005 for standard definition video and ST 370-2013 for
> high definition video.
>
> diff --git a/libavutil/timecode.c b/libavutil/timecode.c
> index e9d8504ee7..93bba2af31 100644
> --- a/libavutil/timecode.c
> +++ b/libavutil/timecode.c
> @@ -117,6 +117,7 @@ static unsigned bcd2uint(uint8_t bcd)
>
> char *av_timecode_make_smpte_tc_string(char *buf, uint32_t tcsmpte,
> int prevent_df)
> {
> +/* See SMPTE ST 314M-2005 Sec 4.4.2.2.1 "Time code pack (TC)" */
Thanks for the clarify, I'll merge this comment for reference, but it seems
that it's not free, so I'll keep the detail format document without any change.
> unsigned hh = bcd2uint(tcsmpte & 0x3f);// 6-bit hours
> unsigned mm = bcd2uint(tcsmpte>>8 & 0x7f);// 7-bit minutes
> unsigned ss = bcd2uint(tcsmpte>>16 & 0x7f);// 7-bit seconds
>
>
> On Wed, Jul 1, 2020 at 9:40 AM wrote:
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > doc/APIchanges| 3 +++
> > libavcodec/avpacket.c | 1 +
> > libavcodec/decode.c | 1 +
> > libavcodec/packet.h | 8
> > libavcodec/version.h | 2 +-
> > libavformat/dump.c| 21 +
> > 6 files changed, 35 insertions(+), 1 deletion(-)
> >
> > diff --git a/doc/APIchanges b/doc/APIchanges
> > index 1d6cc36..7aa8d9e 100644
> > --- a/doc/APIchanges
> > +++ b/doc/APIchanges
> > @@ -15,6 +15,9 @@ libavutil: 2017-10-21
> >
> > API changes, most recent first:
> >
> > +2020-06-xx - xx - lavc 58.94.101 - packet.h
> > + Add AV_PKT_DATA_S12M_TIMECODE.
> > +
> > 2020-06-12 - b09fb030c1 - lavu 56.55.100 - pixdesc.h
> >Add AV_PIX_FMT_X2RGB10.
> >
> > diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
> > index dce26cb..4801163 100644
> > --- a/libavcodec/avpacket.c
> > +++ b/libavcodec/avpacket.c
> > @@ -400,6 +400,7 @@ const char *av_packet_side_data_name(enum
> > AVPacketSideDataType type)
> > case AV_PKT_DATA_PRFT: return "Producer
> > Reference Time";
> > case AV_PKT_DATA_ICC_PROFILE:return "ICC Profile";
> > case AV_PKT_DATA_DOVI_CONF: return "DOVI
> > configuration record";
> > +case AV_PKT_DATA_S12M_TIMECODE: return "SMPTE ST
> > 12-1:2014 timecode";
> > }
> > return NULL;
> > }
> > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > index de9c079..f2244fc 100644
> > --- a/libavcodec/decode.c
> > +++ b/libavcodec/decode.c
> > @@ -1699,6 +1699,7 @@ int ff_decode_frame_props(AVCodecContext *avctx,
> > AVFrame *frame)
> > { AV_PKT_DATA_CONTENT_LIGHT_LEVEL,
> > AV_FRAME_DATA_CONTENT_LIGHT_LEVEL },
> > { AV_PKT_DATA_A53_CC, AV_FRAME_DATA_A53_CC },
> > { AV_PKT_DATA_ICC_PROFILE,
> > AV_FRAME_DATA_ICC_PROFILE },
> > +{ AV_PKT_DATA_S12M_TIMECODE,
> > AV_FRAME_DATA_S12M_TIMECODE },
> > };
> >
> > if (pkt) {
> > diff --git a/libavcodec/packet.h b/libavcodec/packet.h
> > index 96f237f..0a19a0e 100644
> > --- a/libavcodec/packet.h
> > +++ b/libavcodec/packet.h
> > @@ -283,6 +283,14 @@ enum AVPacketSideDataType {
> > AV_PKT_DATA_DOVI_CONF,
> >
> > /**
> > + * Timecode which conforms to SMPTE ST 12-1:2014. The data is an array
> > of 4 uint32_t
> > + * where the first uint32_t describes how many (1-3) of the other
> > timecodes are used.
> > + * The timecode format is described in the documentation of
> > av_timecode_get_smpte_from_framenum()
> > + * function in libavutil/timecode.h.
> > + */
> > +AV_PKT_DATA_S12M_TIMECODE,
> > +
> > +/**
> > * The number of side data types.
> > * This is not part of the public API/ABI in the sense that it may
> > * change when new side data types are added.
> > diff --git a/libavcodec/version.h b/libavcodec/version.h
> > index 05f5990..51fba22 100644
> > --- a/libavcodec/version.h
> > +++ b/libavcodec/version.h
> > @@ -28,7 +28,7 @@
> > #include "libavutil/version.h"
> >
> > #define LIBAVCODEC_VERSION_MAJOR 58
> > -#define LIBAVCODEC_VERSION_MINOR 93
> > +#define LIBAVCODEC_VERSION_MINOR 94
> > #define LIBAVCODEC_VERSION_MICRO 101
> >
> > #define LIBAVCODEC_VERSION_INT AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> > diff --git a/libavformat/dump.c b/libavformat/dump.c
> > index 1083
Re: [FFmpeg-devel] [PATCH v6 3/3] avdevice/decklink_dec: export timecode with s12m side data
On Thu, Jul 09, 2020 at 11:15:51PM +0200, Marton Balint wrote:
>
>
> On Thu, 9 Jul 2020, lance.lmw...@gmail.com wrote:
>
> > On Wed, Jul 08, 2020 at 11:59:17PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Wed, 8 Jul 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Wed, Jul 01, 2020 at 09:39:58PM +0800, lance.lmw...@gmail.com wrote:
> > > > > From: Limin Wang
> > > > > > > Signed-off-by: Limin Wang
> > > > > ---
> > > > > libavdevice/decklink_dec.cpp | 16
> > > > > 1 file changed, 16 insertions(+)
> > > > > > > diff --git a/libavdevice/decklink_dec.cpp
> > > b/libavdevice/decklink_dec.cpp
> > > > > index 82106aa..0fc1489 100644
> > > > > --- a/libavdevice/decklink_dec.cpp
> > > > > +++ b/libavdevice/decklink_dec.cpp
> > > > > @@ -41,6 +41,7 @@ extern "C" {
> > > > > #include "libavutil/imgutils.h"
> > > > > #include "libavutil/intreadwrite.h"
> > > > > #include "libavutil/time.h"
> > > > > +#include "libavutil/timecode.h"
> > > > > #include "libavutil/mathematics.h"
> > > > > #include "libavutil/reverse.h"
> > > > > #include "avdevice.h"
> > > > > @@ -778,6 +779,21 @@ HRESULT
> > > > > decklink_input_callback::VideoInputFrameArrived(
> > > > > AVDictionary* metadata_dict = NULL;
> > > > > int metadata_len;
> > > > > uint8_t* packed_metadata;
> > > > > +AVTimecode tcr;
> > > > > +uint32_t tc_data;
> > > > > +uint8_t *sd;
> > > > > +int size = sizeof(uint32_t) * 4;
> > >
> > > You can push some of these initializers into the blocks in which they are
> > > used.
> >
> > Sure, will fix it.
> >
> > >
> > > > > +
> > > > > +if (av_timecode_init_from_string(&tcr,
> > > > > ctx->video_st->r_frame_rate, tc, ctx) >= 0) {
> > > > > +if ((tc_data =
> > > > > av_timecode_get_smpte_from_framenum(&tcr, 0)) > 0) {
> > >
> > > av_timecode_get_smpte_from_framenum() always succeeds, so this check is
> > > wrong.
> >
> > OK, will fix it.
> >
> > >
> > > Also in theory you could query the color framing flag from the decklink
> > > api.
> >
> > av_timecode_get_smpte_from_framenum() assume the Color Frame flag is zero
> > always, and the conversion from frame to string didn't support the color
> > frame
> > flag also, so even we set the flag, it's not used still.
>
> It is a matter of setting a single bit of tc_data, you don't need to add API
> for it.
>
> > Do you insist that this version must support this feature?
>
> No, but if the DeckLink API supports it, and the side data supports it then
> why not? It should be no more than 2 lines of additional code:
>
> unsigned color_flag = !!(timecode->GetFlags() & bmdTimecodeColorFrame);
>
> ...
>
> tc_data |= color_flag << 31;
>
> Or am I missing something?
No, your change is good to me, but I don't know how to create such input test
signal
with the flag is on, so I can't test it really. So I prefer to add it in future
with separate patch, I'll update the patch without the color_flag support.
>
> Regards,
> Marton
>
> >
> > >
> > > Regards,
> > > Marton
> > >
> > > > > +sd = av_packet_new_side_data(&pkt,
> > > > > AV_PKT_DATA_S12M_TIMECODE, size);
> > > > > +if (sd) {
> > > > > +AV_WL32(sd, 1); // one TC ;
> > > > > +AV_WL32(sd + 4, tc_data); // TC;
> > > > > +}
> > > > > +}
> > > > > +}
> > > > > +
> > > > > if (av_dict_set(&metadata_dict, "timecode",
> > > > > tc, AV_DICT_DONT_STRDUP_VAL) >= 0) {
> > > > > packed_metadata =
> > > > > av_packet_pack_dictionary(metadata_dict, &metadata_len);
> > > > > av_dict_free(&metadata_dict);
> > > > > -- > > 1.8.3.1
> > > > > > > Marton, please help to review and give comments.
> > > > > -- > 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".
> > > ___
> > > 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".
> >
> > --
> > 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
> > ff
Re: [FFmpeg-devel] [PATCH] libavcodec/jpeg2000dec: Fix RPCL progression order
On Thu, Jul 9, 2020 at 11:30 AM wrote: > > From: Gautam Ramakrishnan > > This patch fixes a check in the RPCL progression order, > tested on p1_07.j2k. > --- > libavcodec/jpeg2000dec.c | 19 --- > 1 file changed, 12 insertions(+), 7 deletions(-) > > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c > index 18a933077e..3ea939f7d9 100644 > --- a/libavcodec/jpeg2000dec.c > +++ b/libavcodec/jpeg2000dec.c > @@ -1393,22 +1393,28 @@ static int > jpeg2000_decode_packets_po_iteration(Jpeg2000DecoderContext *s, Jpeg2 > uint8_t reducedresno = codsty->nreslevels - 1 > -reslevelno; // ==> N_L - r > Jpeg2000ResLevel *rlevel = comp->reslevel + > reslevelno; > unsigned prcx, prcy; > +int trx0, try0; > > -int xc = x / s->cdx[compno]; > -int yc = y / s->cdy[compno]; > +if (!s->cdx[compno] || !s->cdy[compno]) > +return AVERROR_INVALIDDATA; > + > +trx0 = ff_jpeg2000_ceildiv(tile->coord[0][0], > s->cdx[compno] << reslevelno); > +try0 = ff_jpeg2000_ceildiv(tile->coord[1][0], > s->cdy[compno] << reslevelno); > > if (reslevelno >= codsty->nreslevels) > continue; > > -if (yc % (1LL << (rlevel->log2_prec_height + > reducedresno)) && y != tile->coord[1][0]) //FIXME this is a subset of the > check > +if (!(y % ((uint64_t)s->cdy[compno] << > (rlevel->log2_prec_height + reducedresno)) == 0 || > + (y == tile->coord[1][0] && (try0 << > reducedresno) % (1U << (reducedresno + rlevel->log2_prec_height) > continue; > > -if (xc % (1LL << (rlevel->log2_prec_width + > reducedresno)) && x != tile->coord[0][0]) //FIXME this is a subset of the > check > +if (!(x % ((uint64_t)s->cdx[compno] << > (rlevel->log2_prec_width + reducedresno)) == 0 || > + (x == tile->coord[0][0] && (trx0 << > reducedresno) % (1U << (reducedresno + rlevel->log2_prec_width) > continue; > > // check if a precinct exists > -prcx = ff_jpeg2000_ceildivpow2(xc, reducedresno) > >> rlevel->log2_prec_width; > -prcy = ff_jpeg2000_ceildivpow2(yc, reducedresno) > >> rlevel->log2_prec_height; > +prcx = ff_jpeg2000_ceildiv(x, s->cdx[compno] << > reducedresno) >> rlevel->log2_prec_width; > +prcy = ff_jpeg2000_ceildiv(y, s->cdy[compno] << > reducedresno) >> rlevel->log2_prec_height; > prcx -= > ff_jpeg2000_ceildivpow2(comp->coord_o[0][0], reducedresno) >> > rlevel->log2_prec_width; > prcy -= > ff_jpeg2000_ceildivpow2(comp->coord_o[1][0], reducedresno) >> > rlevel->log2_prec_height; > > @@ -1906,7 +1912,6 @@ static inline void > tile_codeblocks(Jpeg2000DecoderContext *s, Jpeg2000Tile *tile > continue; > x = cblk->coord[0][0] - band->coord[0][0]; > y = cblk->coord[1][0] - band->coord[1][0]; > - > if (comp->roi_shift) > roi_scale_cblk(cblk, comp, &t1); > if (codsty->transform == FF_DWT97) > -- > 2.17.1 > Please ignore this patch, there is still a small error. Sorry for the mistake. I shall send another patch. -- - Gautam | ___ 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".
