Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Fu, Linjie > Sent: Saturday, August 31, 2019 12:40 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > Of Fu, Linjie > > Sent: Thursday, August 1, 2019 22:51 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > Behalf > > > Of Michael Niedermayer > > > Sent: Wednesday, July 31, 2019 14:04 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > > > AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > > > > On Tue, Jul 30, 2019 at 10:27:10AM -0300, James Almer wrote: > > > > On 7/30/2019 6:33 AM, Carl Eugen Hoyos wrote: > > > > > Am Di., 30. Juli 2019 um 11:25 Uhr schrieb Fu, Linjie > > : > > > > >> > > > > >>> -Original Message- > > > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] > > On > > > Behalf > > > > >>> Of Carl Eugen Hoyos > > > > >>> Sent: Tuesday, July 30, 2019 16:06 > > > > >>> To: FFmpeg development discussions and patches > > > >>> de...@ffmpeg.org> > > > > >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/4] avc/avcodec: add > > > > >>> AV_CODEC_CAP_VARIABLE_DIMENSIONS flag > > > > >>> > > > > >>> Am Di., 30. Juli 2019 um 06:46 Uhr schrieb Linjie Fu > > > : > > > > > > > > Add AV_CODEC_CAP_VARIABLE_DIMENSIONS flag to indicate > > > > whether encoder supports variable dimension encoding. > > > > >>> > > > > >>> Isn't this about variable (or "changing") "resolutions" instead of > > > dimensions? > > > > >>> > > > > >> > > > > >> Comment is welcome and "variable resolutions" is good. > > > > > > > > > >> But is "dimension" not quite suitable for the meaning of "variable > size"? > > > > > > > > > > It took me some time to understand that "dimension" implies > > resolution, > > > > > especially since the FFmpeg documentation mentions resolution iirc. > > > > > > > > > > Carl Eugen > > > > > > > > We have a AV_SIDE_DATA_PARAM_CHANGE_DIMENSIONS flag to > signal > > > resolution > > > > changes, so both words seem to be used interchangeably. > > > > > > > > > > > This also makes me think that the existing > > > AV_CODEC_CAP_PARAM_CHANGE > > > > codec cap can be used for this already, without the need for a new one. > > > > It should a matter of using AV_PKT_DATA_PARAM_CHANGE packet > side > > > data > > > > afterwards in some form. > > > > > > if AV_PKT_DATA_PARAM_CHANGE is used then other parameters would > > > need to > > > be handled too i think. > > > For example pixel format changes alongside width and height. > > > And it leaves some areas of uncertanity which may require more flags > > > like does a aspect ratio change or a change of one of the colorspace > > > parameters need a encoder "flush/restart". (the flush is done from > > > outside the encoder in the patch so the code would need to know) > > > > > > Also for symmetry, if AV_PKT_DATA_PARAM_CHANGE expects sidedata > > on > > > the input side of the decoder, something should produce matching > > > side data on the encoder side. > > > > > > encoder -> decoder should continue working. So only a demuxer > > > generating the side data could be a problem. > > > > Sounds like a new flag will be more robust? > > Ping for this patch set? > https://patchwork.ffmpeg.org/patch/14122/ > https://patchwork.ffmpeg.org/patch/14139/ > https://patchwork.ffmpeg.org/patch/14140/ > Anything I could do for this patch set? ___ 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
On Wed, Sep 11, 2019 at 5:20 AM Fu, Linjie wrote: > > > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Carl Eugen Hoyos > > Sent: Wednesday, September 11, 2019 03:25 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > > ayuv/y210/y410 > > > > Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu : > > > > > > Add some packed pixel formats for hardware decode support > > > in VAAPI and QSV: > > > > > > 4:2:2 10 bit: Y210 > > > 4:4:4 8 bit: AYUV > > > 4:4:4 10 bit: Y410 > > > > Please add a short explanation (either in the commit message or > > only in this thread) for which kind of samples these pixel formats > > are needed. > > > > Or to say it differently: Why is the hardware outputting planar > > formats for some samples and packed for others? > > I kind of remember that it was discussed in previous patch thread: > Previously, media driver provided planar format(like 420 8 bit), > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > is produced in packed format. And the reason is " because Windows > expects it" as you have pointed. > > It could be updated in the commit message if this is good enough. > > > I see you added LE and BE versions: Why are both needed? > > And if they are needed, why is there only AYUV and not AYUV > > and VUYA? > > I noticed LE and BE versions are added for some of the added pixel > format, out of the compatibility for big-endian and little-endian(IMHO). > And that's the reason I add it for Y210 and Y410. > > I'm not sure I understood it correctly, LE/BE version is necessary for > newly added pixel format right? > It depends on the definition of the pixel format. AYUV is defined as 4 consecutive BYTEs, which means its identical on LE and BE. Y210 is defined as being stored as an array of 4 WORDs (Y0, U, Y1, V). For a WORD, the difference of LE/BE matters. Y410 is defined as being stored as a single DWORD, again LE/BE matters here. Obviously the differences in LE/BE need to be implemented properly as well, for Y210 for each WORD, and for Y410 for the entire DWORD. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/2] libavuitl: add A2R10G10B10 & A2B10G10R10
On Wed, Sep 11, 2019 at 13:39:55 +0800, Zachary Zhou wrote: > Subject: [PATCH v4 1/2] libavuitl: add A2R10G10B10 & A2B10G10R10 ^ Nit: libavutil Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 2/2] avfilter: Add tonemap vaapi filter
On Wed, Sep 11, 2019 at 13:39:56 +0800, Zachary Zhou wrote: > +@section tonemap_vappi ^ Typo - the filter has a different name. Moritz ___ 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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Hendrik Leppkes > Sent: Wednesday, September 11, 2019 15:28 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > ayuv/y210/y410 > > On Wed, Sep 11, 2019 at 5:20 AM Fu, Linjie wrote: > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Carl Eugen Hoyos > > > Sent: Wednesday, September 11, 2019 03:25 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel > format > > > ayuv/y210/y410 > > > > > > Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu > : > > > > > > > > Add some packed pixel formats for hardware decode support > > > > in VAAPI and QSV: > > > > > > > > 4:2:2 10 bit: Y210 > > > > 4:4:4 8 bit: AYUV > > > > 4:4:4 10 bit: Y410 > > > > > > Please add a short explanation (either in the commit message or > > > only in this thread) for which kind of samples these pixel formats > > > are needed. > > > > > > Or to say it differently: Why is the hardware outputting planar > > > formats for some samples and packed for others? > > > > I kind of remember that it was discussed in previous patch thread: > > Previously, media driver provided planar format(like 420 8 bit), > > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > > is produced in packed format. And the reason is " because Windows > > expects it" as you have pointed. > > > > It could be updated in the commit message if this is good enough. > > > > > I see you added LE and BE versions: Why are both needed? > > > And if they are needed, why is there only AYUV and not AYUV > > > and VUYA? > > > > I noticed LE and BE versions are added for some of the added pixel > > format, out of the compatibility for big-endian and little-endian(IMHO). > > And that's the reason I add it for Y210 and Y410. > > > > I'm not sure I understood it correctly, LE/BE version is necessary for > > newly added pixel format right? > > > > It depends on the definition of the pixel format. AYUV is defined as > 4 consecutive BYTEs, which means its identical on LE and BE. > Y210 is defined as being stored as an array of 4 WORDs (Y0, U, Y1, V). > For a WORD, the difference of LE/BE matters. > Y410 is defined as being stored as a single DWORD, again LE/BE matters here. Got it. > Obviously the differences in LE/BE need to be implemented properly as > well, for Y210 for each WORD, and for Y410 for the entire DWORD. Thanks Hendrik, for the detailed explanation. It seems AV_RL16 should be used for Y210LE, but for Y410LE, AV_RL32 is needed instead. 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".
[FFmpeg-devel] [PATCH] avformat/hlsenc: Fix memleak when using single_file
This commit fixes a memleak in the hls muxer when one uses a single file
as output. It has been forgotten to free the temporary buffers used to write
the packets so that the size of the leaks basically amounts to the size
of the output file. This commit adds the necessary free.
Signed-off-by: Andreas Rheinhardt
---
I used av_freep instead of av_free (as happens in other places) in order
not to leave an inconsistent state behind. There is actually no reason
to keep the pointer to the temporary buffer; an automatic variable would
be enough.
Furthermore, if flush_dynbuf fails at opening a new dynamic buffer, the
temporary buffer needs to be freed nevertheless. Yet this isn't done for
the other two calls to flush_dynbuf.
libavformat/hlsenc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index f881bb9d60..a6a3947ac7 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2365,6 +2365,7 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
if (hls->flags & HLS_SINGLE_FILE) {
ret = flush_dynbuf(vs, &range_length);
+av_freep(&vs->temp_buffer);
if (ret < 0) {
return ret;
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: ffio_free_dyn_buf the oc->pb at hls_write_trailer
Steven Liu: > fix memleak at hls_write_trailer > > Found-by: Andreas Rheinhardt > Signed-off-by: Steven Liu > --- > libavformat/hlsenc.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c > index f881bb9d60..218bfb2cba 100644 > --- a/libavformat/hlsenc.c > +++ b/libavformat/hlsenc.c > @@ -2641,6 +2641,7 @@ failed: > ff_format_io_close(s, &vs->out); > hls_window(s, 1, vs); > } > +ffio_free_dyn_buf(&oc->pb); > avformat_free_context(oc); > > vs->avf = NULL; > This patch fixes the memleaks I reported. I don't know if anything ever gets written in av_write_trailer(oc); if yes, it will be discarded and not output. But if you are ok with this (or know for sure that it won't happen), it's fine. There are other memleaks, though: A big one when using HLS_SINGLE_FILE (more on this in another mail) and then there are three places in hls_write_trailer where you simply return AVERROR(ENOMEM) when there is not enough memory available for another string. This guarantees leaks. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/h2645_parse: refine the code for better readiablity
On 9/10/2019 2:38 AM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/h2645_parse.c | 10 --
> 1 file changed, 4 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 307e8643e6..f077900617 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -453,16 +453,15 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
> uint8_t *buf, int length,
> }
> }
>
> -if (pkt->nals_allocated < pkt->nb_nals + 1) {
> -int new_size = pkt->nals_allocated + 1;
> -void *tmp = av_realloc_array(pkt->nals, new_size,
> sizeof(*pkt->nals));
> +if (pkt->nb_nals >= pkt->nals_allocated) {
> +void *tmp = av_realloc_array(pkt->nals, pkt->nals_allocated + 1,
> sizeof(*pkt->nals));
>
> if (!tmp)
> return AVERROR(ENOMEM);
>
> pkt->nals = tmp;
> -memset(pkt->nals + pkt->nals_allocated, 0,
> - (new_size - pkt->nals_allocated) * sizeof(*pkt->nals));
> +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals));
> +pkt->nals_allocated++;
The nal->skipped_bytes_pos allocation below can still fail. This counter
shouldn't increase until all allocations have succeeded.
>
> nal = &pkt->nals[pkt->nb_nals];
> nal->skipped_bytes_pos_size = 1024; // initial buffer size
> @@ -470,7 +469,6 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
> *buf, int length,
> if (!nal->skipped_bytes_pos)
> return AVERROR(ENOMEM);
>
> -pkt->nals_allocated = new_size;
> }
> nal = &pkt->nals[pkt->nb_nals];
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/h2645_parse: simplify memset call
On 9/7/2019 4:55 PM, Andriy Gelman wrote: > From: Andriy Gelman > > Removed (new_size - pkt->nals_allocated) because this value is always 1 > during the call. > --- > libavcodec/h2645_parse.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c > index 307e8643e6..ef6a6b4b4f 100644 > --- a/libavcodec/h2645_parse.c > +++ b/libavcodec/h2645_parse.c > @@ -461,8 +461,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t > *buf, int length, > return AVERROR(ENOMEM); > > pkt->nals = tmp; > -memset(pkt->nals + pkt->nals_allocated, 0, > - (new_size - pkt->nals_allocated) * sizeof(*pkt->nals)); > +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals)); > > nal = &pkt->nals[pkt->nb_nals]; > nal->skipped_bytes_pos_size = 1024; // initial buffer size Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 0/3] avformat/hashenc: add streamhash muxer
Adds a streamhash muxer, much like the hash muxer, but analyzing each stream independently. I chose not to add a "streammd5" muxer, as the other *md5 muxers are just legacy versions of the *hash muxers with a different default algorithm. The first two patches re-arrange the code in preparation for new muxer. The patch "use an array of hashes" makes no sense without the subsequent addition of the new muxer, but the patch "rearrange options definition" could be seen independently. Do squash if you will. Moritz Barsnick (3): avformat/hashenc: rearrange options definition avformat/hashenc: use an array of hashes avformat/hashenc: add streamhash muxer Changelog| 1 + doc/muxers.texi | 46 + libavformat/Makefile | 1 + libavformat/allformats.c | 1 + libavformat/hashenc.c| 197 ++- libavformat/version.h| 4 +- 6 files changed, 205 insertions(+), 45 deletions(-) -- 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 v2 1/3] avformat/hashenc: rearrange options definition
Only the frame* muxers support the format_version option.
Use macros to ease the proliferation of identical options to
coming muxers as well.
---
libavformat/hashenc.c | 35 +++
1 file changed, 27 insertions(+), 8 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 06fc085d18..210bfdea0e 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -36,18 +36,37 @@ struct HashContext {
#define OFFSET(x) offsetof(struct HashContext, x)
#define ENC AV_OPT_FLAG_ENCODING_PARAM
-#if CONFIG_HASH_MUXER || CONFIG_FRAMEHASH_MUXER
+#define HASH_OPT(defaulttype) \
+{ "hash", "set hash to use", OFFSET(hash_name), AV_OPT_TYPE_STRING, {.str
= defaulttype}, 0, 0, ENC }
+#define FORMAT_VERSION_OPT \
+{ "format_version", "file format version", OFFSET(format_version),
AV_OPT_TYPE_INT, {.i64 = 2}, 1, 2, ENC }
+
+#if CONFIG_HASH_MUXER
static const AVOption hash_options[] = {
-{ "hash", "set hash to use", OFFSET(hash_name), AV_OPT_TYPE_STRING, {.str
= "sha256"}, 0, 0, ENC },
-{ "format_version", "file format version", OFFSET(format_version),
AV_OPT_TYPE_INT, {.i64 = 2}, 1, 2, ENC },
+HASH_OPT("sha256"),
+{ NULL },
+};
+#endif
+
+#if CONFIG_FRAMEHASH_MUXER
+static const AVOption framehash_options[] = {
+HASH_OPT("sha256"),
+FORMAT_VERSION_OPT,
{ NULL },
};
#endif
-#if CONFIG_MD5_MUXER || CONFIG_FRAMEMD5_MUXER
+#if CONFIG_MD5_MUXER
static const AVOption md5_options[] = {
-{ "hash", "set hash to use", OFFSET(hash_name), AV_OPT_TYPE_STRING, {.str
= "md5"}, 0, 0, ENC },
-{ "format_version", "file format version", OFFSET(format_version),
AV_OPT_TYPE_INT, {.i64 = 2}, 1, 2, ENC },
+HASH_OPT("md5"),
+{ NULL },
+};
+#endif
+
+#if CONFIG_FRAMEMD5_MUXER
+static const AVOption framemd5_options[] = {
+HASH_OPT("md5"),
+FORMAT_VERSION_OPT,
{ NULL },
};
#endif
@@ -219,7 +238,7 @@ static int framehash_write_trailer(struct AVFormatContext
*s)
static const AVClass framehash_class = {
.class_name = "frame hash muxer",
.item_name = av_default_item_name,
-.option = hash_options,
+.option = framehash_options,
.version= LIBAVUTIL_VERSION_INT,
};
@@ -242,7 +261,7 @@ AVOutputFormat ff_framehash_muxer = {
static const AVClass framemd5_class = {
.class_name = "frame MD5 muxer",
.item_name = av_default_item_name,
-.option = md5_options,
+.option = framemd5_options,
.version= LIBAVUTIL_VERSION_INT,
};
--
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 v2 3/3] avformat/hashenc: add streamhash muxer
Implemented as a variant of the hash muxer, reusing most functions,
and making use of the previously introduced array of hashes.
---
Changelog| 1 +
doc/muxers.texi | 46 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/hashenc.c| 82 +++-
libavformat/version.h| 4 +-
6 files changed, 124 insertions(+), 11 deletions(-)
diff --git a/Changelog b/Changelog
index 4b29e015a0..8eeed65680 100644
--- a/Changelog
+++ b/Changelog
@@ -9,6 +9,7 @@ version :
- Supoort AMD AMF encoder on Linux (via Vulkan)
- IMM5 video decoder
- ZeroMQ protocol
+- streamhash muxer
version 4.2:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 20d31b279c..014f952d68 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2064,6 +2064,52 @@ Specify whether to remove all fragments when finished.
Default 0 (do not remove)
@end table
+@anchor{streamhash}
+@section streamhash
+
+Per stream hash testing format.
+
+This muxer computes and prints a cryptographic hash of all the input frames,
+on a per-stream basis. This can be used for equality checks without having
+to do a complete binary comparison.
+
+By default audio frames are converted to signed 16-bit raw audio and
+video frames to raw video before computing the hash, but the output
+of explicit conversions to other codecs can also be used. Timestamps
+are ignored. It uses the SHA-256 cryptographic hash function by default,
+but supports several other algorithms.
+
+The output of the muxer consists of one line per stream of the form:
+@var{streamindex},@var{algo}=@var{hash}, where @var{streamindex} is the
+index of the mapped stream, @var{algo} is a short string representing the
+hash function used, and @var{hash} is a hexadecimal number representing the
+computed hash.
+
+@table @option
+@item hash @var{algorithm}
+Use the cryptographic hash function specified by the string @var{algorithm}.
+Supported values include @code{MD5}, @code{murmur3}, @code{RIPEMD128},
+@code{RIPEMD160}, @code{RIPEMD256}, @code{RIPEMD320}, @code{SHA160},
+@code{SHA224}, @code{SHA256} (default), @code{SHA512/224}, @code{SHA512/256},
+@code{SHA384}, @code{SHA512}, @code{CRC32} and @code{adler32}.
+
+@end table
+
+@subsection Examples
+
+To compute the SHA-256 hash of the input converted to raw audio and
+video, and store it in the file @file{out.sha256}:
+@example
+ffmpeg -i INPUT -f streamhash out.sha256
+@end example
+
+To print an MD5 hash to stdout use the command:
+@example
+ffmpeg -i INPUT -f streamhash -hash md5 -
+@end example
+
+See also the @ref{hash} and @ref{framehash} muxers.
+
@anchor{fifo}
@section fifo
diff --git a/libavformat/Makefile b/libavformat/Makefile
index efa3a112ae..a61d42b721 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -494,6 +494,7 @@ OBJS-$(CONFIG_SRT_DEMUXER) += srtdec.o
subtitles.o
OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
OBJS-$(CONFIG_STL_DEMUXER) += stldec.o subtitles.o
OBJS-$(CONFIG_STR_DEMUXER) += psxstr.o
+OBJS-$(CONFIG_STREAMHASH_MUXER) += hashenc.o
OBJS-$(CONFIG_STREAM_SEGMENT_MUXER) += segment.o
OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index cd00834807..f7fea32b45 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -393,6 +393,7 @@ extern AVInputFormat ff_srt_demuxer;
extern AVOutputFormat ff_srt_muxer;
extern AVInputFormat ff_str_demuxer;
extern AVInputFormat ff_stl_demuxer;
+extern AVOutputFormat ff_streamhash_muxer;
extern AVInputFormat ff_subviewer1_demuxer;
extern AVInputFormat ff_subviewer_demuxer;
extern AVInputFormat ff_sup_demuxer;
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 4fd41e41b6..18dc4dc825 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -31,6 +31,7 @@ struct HashContext {
const AVClass *avclass;
struct AVHashContext **hashes;
char *hash_name;
+int per_stream;
int format_version;
};
@@ -56,6 +57,13 @@ static const AVOption framehash_options[] = {
};
#endif
+#if CONFIG_STREAMHASH_MUXER
+static const AVOption streamhash_options[] = {
+HASH_OPT("sha256"),
+{ NULL },
+};
+#endif
+
#if CONFIG_MD5_MUXER
static const AVOption md5_options[] = {
HASH_OPT("md5"),
@@ -76,6 +84,7 @@ static int hash_init(struct AVFormatContext *s)
{
int res;
struct HashContext *c = s->priv_data;
+c->per_stream = 0;
c->hashes = av_mallocz_array(1, sizeof(c->hashes));
if (!c->hashes)
return AVERROR(ENOMEM);
@@ -87,24 +96,32 @@ static int hash_init(struct AVFormatContext *s)
av_hash_init(c->hashes[0]);
return 0;
}
+#endif
+#if CONFIG_HASH_MUXER || CONFIG_MD5_MUXER || CONFIG_STREAMHASH_MUXER
static int hash_write_packet(struct AVFormatCont
[FFmpeg-devel] [PATCH v2 2/3] avformat/hashenc: use an array of hashes
Only the first element of the array is used currently, the other
elements are in preparation for a new muxer calculating multiple
hashes.
Also move alloc/init code from the write_header() functions to
dedicated init() functions, and the cleanup code from the
write_trailer() functions to dedicated deinit() functions.
---
libavformat/hashenc.c | 88 ---
1 file changed, 58 insertions(+), 30 deletions(-)
diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
index 210bfdea0e..4fd41e41b6 100644
--- a/libavformat/hashenc.c
+++ b/libavformat/hashenc.c
@@ -29,7 +29,7 @@
struct HashContext {
const AVClass *avclass;
-struct AVHashContext *hash;
+struct AVHashContext **hashes;
char *hash_name;
int format_version;
};
@@ -72,20 +72,26 @@ static const AVOption framemd5_options[] = {
#endif
#if CONFIG_HASH_MUXER || CONFIG_MD5_MUXER
-static int hash_write_header(struct AVFormatContext *s)
+static int hash_init(struct AVFormatContext *s)
{
+int res;
struct HashContext *c = s->priv_data;
-int res = av_hash_alloc(&c->hash, c->hash_name);
-if (res < 0)
+c->hashes = av_mallocz_array(1, sizeof(c->hashes));
+if (!c->hashes)
+return AVERROR(ENOMEM);
+res = av_hash_alloc(&c->hashes[0], c->hash_name);
+if (res < 0) {
+av_freep(&c->hashes);
return res;
-av_hash_init(c->hash);
+}
+av_hash_init(c->hashes[0]);
return 0;
}
static int hash_write_packet(struct AVFormatContext *s, AVPacket *pkt)
{
struct HashContext *c = s->priv_data;
-av_hash_update(c->hash, pkt->data, pkt->size);
+av_hash_update(c->hashes[0], pkt->data, pkt->size);
return 0;
}
@@ -93,16 +99,22 @@ static int hash_write_trailer(struct AVFormatContext *s)
{
struct HashContext *c = s->priv_data;
char buf[AV_HASH_MAX_SIZE*2+128];
-snprintf(buf, sizeof(buf) - 200, "%s=", av_hash_get_name(c->hash));
+snprintf(buf, sizeof(buf) - 200, "%s=", av_hash_get_name(c->hashes[0]));
-av_hash_final_hex(c->hash, buf + strlen(buf), sizeof(buf) - strlen(buf));
+av_hash_final_hex(c->hashes[0], buf + strlen(buf), sizeof(buf) -
strlen(buf));
av_strlcatf(buf, sizeof(buf), "\n");
avio_write(s->pb, buf, strlen(buf));
avio_flush(s->pb);
-av_hash_freep(&c->hash);
return 0;
}
+
+static void hash_free(struct AVFormatContext *s)
+{
+struct HashContext *c = s->priv_data;
+av_hash_freep(&c->hashes[0]);
+av_freep(&c->hashes);
+}
#endif
#if CONFIG_HASH_MUXER
@@ -119,9 +131,10 @@ AVOutputFormat ff_hash_muxer = {
.priv_data_size= sizeof(struct HashContext),
.audio_codec = AV_CODEC_ID_PCM_S16LE,
.video_codec = AV_CODEC_ID_RAWVIDEO,
-.write_header = hash_write_header,
+.init = hash_init,
.write_packet = hash_write_packet,
.write_trailer = hash_write_trailer,
+.deinit= hash_free,
.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
AVFMT_TS_NEGATIVE,
.priv_class= &hashenc_class,
@@ -142,9 +155,10 @@ AVOutputFormat ff_md5_muxer = {
.priv_data_size= sizeof(struct HashContext),
.audio_codec = AV_CODEC_ID_PCM_S16LE,
.video_codec = AV_CODEC_ID_RAWVIDEO,
-.write_header = hash_write_header,
+.init = hash_init,
.write_packet = hash_write_packet,
.write_trailer = hash_write_trailer,
+.deinit= hash_free,
.flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
AVFMT_TS_NEGATIVE,
.priv_class= &md5enc_class,
@@ -164,24 +178,36 @@ static void framehash_print_extradata(struct
AVFormatContext *s)
char buf[AV_HASH_MAX_SIZE*2+1];
avio_printf(s->pb, "#extradata %d, %31d, ", i,
par->extradata_size);
-av_hash_init(c->hash);
-av_hash_update(c->hash, par->extradata, par->extradata_size);
-av_hash_final_hex(c->hash, buf, sizeof(buf));
+av_hash_init(c->hashes[0]);
+av_hash_update(c->hashes[0], par->extradata, par->extradata_size);
+av_hash_final_hex(c->hashes[0], buf, sizeof(buf));
avio_write(s->pb, buf, strlen(buf));
avio_printf(s->pb, "\n");
}
}
}
-static int framehash_write_header(struct AVFormatContext *s)
+static int framehash_init(struct AVFormatContext *s)
{
+int res;
struct HashContext *c = s->priv_data;
-int res = av_hash_alloc(&c->hash, c->hash_name);
-if (res < 0)
+c->hashes = av_mallocz_array(1, sizeof(c->hashes));
+if (!c->hashes)
+return AVERROR(ENOMEM);
+res = av_hash_alloc(&c->hashes[0], c->hash_name);
+if (res < 0) {
+av_freep(&c->hashes);
return res;
+}
+return 0;
+}
+
+static int framehash_write_header(struct AVFormatContext *s)
+{
+struct HashContext *c = s->priv_data;
avio_pri
Re: [FFmpeg-devel] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU
On 02.09.2019 18:24, Timo Rothenpieler wrote: I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and AMF/Vulkan integration. Since there is personal information on the receipts, I won't post them here, but can send them to the responsible person on request easily. Packaging: PackSet M: 1.99€ Bubble-Wrap "Protection Kit": 4.99€ Shipping: Insured shipping via DHL (DE->US): 37.99€ Total cost: 44.97€ ping ___ 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 2/3] avformat/hashenc: use an array of hashes
On 9/11/2019 10:34 AM, Moritz Barsnick wrote:
> Only the first element of the array is used currently, the other
> elements are in preparation for a new muxer calculating multiple
> hashes.
>
> Also move alloc/init code from the write_header() functions to
> dedicated init() functions, and the cleanup code from the
> write_trailer() functions to dedicated deinit() functions.
> ---
> libavformat/hashenc.c | 88 ---
> 1 file changed, 58 insertions(+), 30 deletions(-)
>
> diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
> index 210bfdea0e..4fd41e41b6 100644
> --- a/libavformat/hashenc.c
> +++ b/libavformat/hashenc.c
> @@ -29,7 +29,7 @@
>
> struct HashContext {
> const AVClass *avclass;
> -struct AVHashContext *hash;
> +struct AVHashContext **hashes;
> char *hash_name;
> int format_version;
> };
> @@ -72,20 +72,26 @@ static const AVOption framemd5_options[] = {
> #endif
>
> #if CONFIG_HASH_MUXER || CONFIG_MD5_MUXER
> -static int hash_write_header(struct AVFormatContext *s)
> +static int hash_init(struct AVFormatContext *s)
> {
> +int res;
> struct HashContext *c = s->priv_data;
> -int res = av_hash_alloc(&c->hash, c->hash_name);
> -if (res < 0)
> +c->hashes = av_mallocz_array(1, sizeof(c->hashes));
> +if (!c->hashes)
> +return AVERROR(ENOMEM);
> +res = av_hash_alloc(&c->hashes[0], c->hash_name);
> +if (res < 0) {
> +av_freep(&c->hashes);
> return res;
> -av_hash_init(c->hash);
> +}
> +av_hash_init(c->hashes[0]);
> return 0;
> }
>
> static int hash_write_packet(struct AVFormatContext *s, AVPacket *pkt)
> {
> struct HashContext *c = s->priv_data;
> -av_hash_update(c->hash, pkt->data, pkt->size);
> +av_hash_update(c->hashes[0], pkt->data, pkt->size);
> return 0;
> }
>
> @@ -93,16 +99,22 @@ static int hash_write_trailer(struct AVFormatContext *s)
> {
> struct HashContext *c = s->priv_data;
> char buf[AV_HASH_MAX_SIZE*2+128];
> -snprintf(buf, sizeof(buf) - 200, "%s=", av_hash_get_name(c->hash));
> +snprintf(buf, sizeof(buf) - 200, "%s=", av_hash_get_name(c->hashes[0]));
>
> -av_hash_final_hex(c->hash, buf + strlen(buf), sizeof(buf) - strlen(buf));
> +av_hash_final_hex(c->hashes[0], buf + strlen(buf), sizeof(buf) -
> strlen(buf));
> av_strlcatf(buf, sizeof(buf), "\n");
> avio_write(s->pb, buf, strlen(buf));
> avio_flush(s->pb);
>
> -av_hash_freep(&c->hash);
> return 0;
> }
> +
> +static void hash_free(struct AVFormatContext *s)
> +{
> +struct HashContext *c = s->priv_data;
> +av_hash_freep(&c->hashes[0]);
AVOutputFormat.deinit() is called when AVOutputFormat.init() fails, so
c->hashes can be NULL. same with the framehash muxer.
> +av_freep(&c->hashes);
> +}
> #endif
>
> #if CONFIG_HASH_MUXER
> @@ -119,9 +131,10 @@ AVOutputFormat ff_hash_muxer = {
> .priv_data_size= sizeof(struct HashContext),
> .audio_codec = AV_CODEC_ID_PCM_S16LE,
> .video_codec = AV_CODEC_ID_RAWVIDEO,
> -.write_header = hash_write_header,
> +.init = hash_init,
> .write_packet = hash_write_packet,
> .write_trailer = hash_write_trailer,
> +.deinit= hash_free,
> .flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
> AVFMT_TS_NEGATIVE,
> .priv_class= &hashenc_class,
> @@ -142,9 +155,10 @@ AVOutputFormat ff_md5_muxer = {
> .priv_data_size= sizeof(struct HashContext),
> .audio_codec = AV_CODEC_ID_PCM_S16LE,
> .video_codec = AV_CODEC_ID_RAWVIDEO,
> -.write_header = hash_write_header,
> +.init = hash_init,
> .write_packet = hash_write_packet,
> .write_trailer = hash_write_trailer,
> +.deinit= hash_free,
> .flags = AVFMT_VARIABLE_FPS | AVFMT_TS_NONSTRICT |
> AVFMT_TS_NEGATIVE,
> .priv_class= &md5enc_class,
> @@ -164,24 +178,36 @@ static void framehash_print_extradata(struct
> AVFormatContext *s)
> char buf[AV_HASH_MAX_SIZE*2+1];
>
> avio_printf(s->pb, "#extradata %d, %31d, ", i,
> par->extradata_size);
> -av_hash_init(c->hash);
> -av_hash_update(c->hash, par->extradata, par->extradata_size);
> -av_hash_final_hex(c->hash, buf, sizeof(buf));
> +av_hash_init(c->hashes[0]);
> +av_hash_update(c->hashes[0], par->extradata,
> par->extradata_size);
> +av_hash_final_hex(c->hashes[0], buf, sizeof(buf));
> avio_write(s->pb, buf, strlen(buf));
> avio_printf(s->pb, "\n");
> }
> }
> }
>
> -static int framehash_write_header(struct AVFormatContext *s)
> +static int framehash_init(struct AVFormatContext *s)
> {
> +int res;
> struct HashContext *c = s->priv_data;
> -int res = av_ha
Re: [FFmpeg-devel] [PATCH v2 2/3] avformat/hashenc: use an array of hashes
On Wed, Sep 11, 2019 at 10:39:40 -0300, James Almer wrote:
> On 9/11/2019 10:34 AM, Moritz Barsnick wrote:
> > +static void hash_free(struct AVFormatContext *s)
> > +{
> > +struct HashContext *c = s->priv_data;
> > +av_hash_freep(&c->hashes[0]);
>
> AVOutputFormat.deinit() is called when AVOutputFormat.init() fails, so
> c->hashes can be NULL. same with the framehash muxer.
>
> > +av_freep(&c->hashes);
> > +}
Does this mean there should just be a check for "if (c->hashes)" here,
or can the suggestion in
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248014.html
actually not be implemented? No common freeing function?
Thanks,
Moritz
___
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 2/3] avformat/hashenc: use an array of hashes
On 9/11/2019 10:53 AM, Moritz Barsnick wrote:
> On Wed, Sep 11, 2019 at 10:39:40 -0300, James Almer wrote:
>> On 9/11/2019 10:34 AM, Moritz Barsnick wrote:
>>> +static void hash_free(struct AVFormatContext *s)
>>> +{
>>> +struct HashContext *c = s->priv_data;
>>> +av_hash_freep(&c->hashes[0]);
>>
>> AVOutputFormat.deinit() is called when AVOutputFormat.init() fails, so
>> c->hashes can be NULL. same with the framehash muxer.
>>
>>> +av_freep(&c->hashes);
>>> +}
>
> Does this mean there should just be a check for "if (c->hashes)" here,
> or can the suggestion in
> http://ffmpeg.org/pipermail/ffmpeg-devel/2019-August/248014.html
> actually not be implemented? No common freeing function?
av_freep() can be used with NULL variables without issues. The problem
is that you're dereferencing c->hashes for the av_hash_freep() call. If
it's NULL, you'll get a segfault. So just do
if (c->hashes)
av_hash_freep(&c->hashes[0]);
av_freep(&c->hashes);
In both muxers. Then adapt it in PATCH 3/3 for the streamhash muxer
addition.
>
> Thanks,
> Moritz
> ___
> 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 v2 3/3] avformat/hashenc: add streamhash muxer
On 9/11/2019 10:34 AM, Moritz Barsnick wrote:
> Implemented as a variant of the hash muxer, reusing most functions,
> and making use of the previously introduced array of hashes.
> ---
> Changelog| 1 +
> doc/muxers.texi | 46 ++
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/hashenc.c| 82 +++-
> libavformat/version.h| 4 +-
> 6 files changed, 124 insertions(+), 11 deletions(-)
>
> diff --git a/Changelog b/Changelog
> index 4b29e015a0..8eeed65680 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -9,6 +9,7 @@ version :
> - Supoort AMD AMF encoder on Linux (via Vulkan)
> - IMM5 video decoder
> - ZeroMQ protocol
> +- streamhash muxer
>
>
> version 4.2:
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 20d31b279c..014f952d68 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2064,6 +2064,52 @@ Specify whether to remove all fragments when finished.
> Default 0 (do not remove)
>
> @end table
>
> +@anchor{streamhash}
> +@section streamhash
> +
> +Per stream hash testing format.
> +
> +This muxer computes and prints a cryptographic hash of all the input frames,
> +on a per-stream basis. This can be used for equality checks without having
> +to do a complete binary comparison.
> +
> +By default audio frames are converted to signed 16-bit raw audio and
> +video frames to raw video before computing the hash, but the output
> +of explicit conversions to other codecs can also be used. Timestamps
> +are ignored. It uses the SHA-256 cryptographic hash function by default,
> +but supports several other algorithms.
> +
> +The output of the muxer consists of one line per stream of the form:
> +@var{streamindex},@var{algo}=@var{hash}, where @var{streamindex} is the
> +index of the mapped stream, @var{algo} is a short string representing the
> +hash function used, and @var{hash} is a hexadecimal number representing the
> +computed hash.
> +
> +@table @option
> +@item hash @var{algorithm}
> +Use the cryptographic hash function specified by the string @var{algorithm}.
> +Supported values include @code{MD5}, @code{murmur3}, @code{RIPEMD128},
> +@code{RIPEMD160}, @code{RIPEMD256}, @code{RIPEMD320}, @code{SHA160},
> +@code{SHA224}, @code{SHA256} (default), @code{SHA512/224}, @code{SHA512/256},
> +@code{SHA384}, @code{SHA512}, @code{CRC32} and @code{adler32}.
> +
> +@end table
> +
> +@subsection Examples
> +
> +To compute the SHA-256 hash of the input converted to raw audio and
> +video, and store it in the file @file{out.sha256}:
> +@example
> +ffmpeg -i INPUT -f streamhash out.sha256
> +@end example
> +
> +To print an MD5 hash to stdout use the command:
> +@example
> +ffmpeg -i INPUT -f streamhash -hash md5 -
> +@end example
> +
> +See also the @ref{hash} and @ref{framehash} muxers.
> +
> @anchor{fifo}
> @section fifo
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index efa3a112ae..a61d42b721 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -494,6 +494,7 @@ OBJS-$(CONFIG_SRT_DEMUXER) += srtdec.o
> subtitles.o
> OBJS-$(CONFIG_SRT_MUXER) += srtenc.o
> OBJS-$(CONFIG_STL_DEMUXER) += stldec.o subtitles.o
> OBJS-$(CONFIG_STR_DEMUXER) += psxstr.o
> +OBJS-$(CONFIG_STREAMHASH_MUXER) += hashenc.o
> OBJS-$(CONFIG_STREAM_SEGMENT_MUXER) += segment.o
> OBJS-$(CONFIG_SUBVIEWER1_DEMUXER)+= subviewer1dec.o subtitles.o
> OBJS-$(CONFIG_SUBVIEWER_DEMUXER) += subviewerdec.o subtitles.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index cd00834807..f7fea32b45 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -393,6 +393,7 @@ extern AVInputFormat ff_srt_demuxer;
> extern AVOutputFormat ff_srt_muxer;
> extern AVInputFormat ff_str_demuxer;
> extern AVInputFormat ff_stl_demuxer;
> +extern AVOutputFormat ff_streamhash_muxer;
> extern AVInputFormat ff_subviewer1_demuxer;
> extern AVInputFormat ff_subviewer_demuxer;
> extern AVInputFormat ff_sup_demuxer;
> diff --git a/libavformat/hashenc.c b/libavformat/hashenc.c
> index 4fd41e41b6..18dc4dc825 100644
> --- a/libavformat/hashenc.c
> +++ b/libavformat/hashenc.c
> @@ -31,6 +31,7 @@ struct HashContext {
> const AVClass *avclass;
> struct AVHashContext **hashes;
> char *hash_name;
> +int per_stream;
> int format_version;
> };
>
> @@ -56,6 +57,13 @@ static const AVOption framehash_options[] = {
> };
> #endif
>
> +#if CONFIG_STREAMHASH_MUXER
> +static const AVOption streamhash_options[] = {
> +HASH_OPT("sha256"),
> +{ NULL },
> +};
> +#endif
> +
> #if CONFIG_MD5_MUXER
> static const AVOption md5_options[] = {
> HASH_OPT("md5"),
> @@ -76,6 +84,7 @@ static int hash_init(struct AVFormatContext *s)
> {
> int res;
> struct HashContext *c = s->priv_data;
> +c->per_stream = 0;
> c->hashes = av_mallocz_array(1,
Re: [FFmpeg-devel] [PATCH v2 3/3] avformat/hashenc: add streamhash muxer
On Wed, Sep 11, 2019 at 11:08:01 -0300, James Almer wrote:
> > +static int streamhash_init(struct AVFormatContext *s)
> > +{
> > +int res, i;
> > +struct HashContext *c = s->priv_data;
> > +c->per_stream = 1;
> > +c->hashes = av_mallocz_array(s->nb_streams, sizeof(c->hashes));
> > +if (!c->hashes)
> > +return AVERROR(ENOMEM);
> > +for (i = 0; i < s->nb_streams; i++) {
> > +res = av_hash_alloc(&c->hashes[i], c->hash_name);
> > +if (res < 0) {
> > +hash_free(s);
>
> No need to call this. It's done automatically by the generic code when
> this function returns an error.
Nice. I actually thought that, from your comment on patch 2/3. Will
resubmit (including 1/3, for completeness' sake) in a moment.
Thanks for the feedback,
Moritz
___
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 3/3] avformat/hashenc: add streamhash muxer
On 11-09-2019 07:04 PM, Moritz Barsnick wrote:
Implemented as a variant of the hash muxer, reusing most functions,
and making use of the previously introduced array of hashes.
---
Changelog| 1 +
doc/muxers.texi | 46 ++
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/hashenc.c| 82 +++-
libavformat/version.h| 4 +-
6 files changed, 124 insertions(+), 11 deletions(-)
diff --git a/Changelog b/Changelog
index 4b29e015a0..8eeed65680 100644
--- a/Changelog
+++ b/Changelog
@@ -9,6 +9,7 @@ version :
- Supoort AMD AMF encoder on Linux (via Vulkan)
- IMM5 video decoder
- ZeroMQ protocol
+- streamhash muxer
version 4.2:
diff --git a/doc/muxers.texi b/doc/muxers.texi
index 20d31b279c..014f952d68 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -2064,6 +2064,52 @@ Specify whether to remove all fragments when finished.
Default 0 (do not remove)
@end table
+@anchor{streamhash}
+@section streamhash
+
+Per stream hash testing format.
+
+This muxer computes and prints a cryptographic hash of all the input frames,
+on a per-stream basis. This can be used for equality checks without having
+to do a complete binary comparison.
+
+By default audio frames are converted to signed 16-bit raw audio and
+video frames to raw video before computing the hash, but the output
+of explicit conversions to other codecs can also be used. Timestamps
+are ignored. It uses the SHA-256 cryptographic hash function by default,
+but supports several other algorithms.
+
+The output of the muxer consists of one line per stream of the form:
+@var{streamindex},@var{algo}=@var{hash}, where @var{streamindex} is the
+index of the mapped stream, @var{algo} is a short string representing the
+hash function used, and @var{hash} is a hexadecimal number representing the
+computed hash.
+
+@table @option
+@item hash @var{algorithm}
+Use the cryptographic hash function specified by the string @var{algorithm}.
+Supported values include @code{MD5}, @code{murmur3}, @code{RIPEMD128},
+@code{RIPEMD160}, @code{RIPEMD256}, @code{RIPEMD320}, @code{SHA160},
+@code{SHA224}, @code{SHA256} (default), @code{SHA512/224}, @code{SHA512/256},
+@code{SHA384}, @code{SHA512}, @code{CRC32} and @code{adler32}.
+
+@end table
+
+@subsection Examples
+
+To compute the SHA-256 hash of the input converted to raw audio and
+video, and store it in the file @file{out.sha256}:
+@example
+ffmpeg -i INPUT -f streamhash out.sha256
+@end example
+
+To print an MD5 hash to stdout use the command:
+@example
+ffmpeg -i INPUT -f streamhash -hash md5 -
+@end example
Since there's no mapping, this will select only one video and audio
stream, but more importantly the video will be first, which may not be
the case in the input. Maybe add mapping to the examples and/or add
stream type to the hash printout.
Gyan
___
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 3/3] avformat/hashenc: add streamhash muxer
On Wed, Sep 11, 2019 at 19:57:43 +0530, Gyan wrote: > > +ffmpeg -i INPUT -f streamhash -hash md5 - > > +@end example > Since there's no mapping, this will select only one video and audio > stream, but more importantly the video will be first, which may not be > the case in the input. Maybe add mapping to the examples and/or add > stream type to the hash printout. The original user suggesting this muxer also requested a stream type indicator. Is that info really useful and not redundant, assuming the user will need to understand the implications of remuxing anyway? If I add this, and don't make it optional, what should the format be? Thus?: 0,v,SHA256=... 1,a,SHA256=... 2,s,SHA256=... Thanks, Moritz ___ 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] Testing failure paths (Was: Re: [PATCH v2 2/3] avformat/hashenc: use an array of hashes)
On Wed, Sep 11, 2019 at 10:39:40 -0300, James Almer wrote:
> > +static void hash_free(struct AVFormatContext *s)
> > +{
> > +struct HashContext *c = s->priv_data;
> > +av_hash_freep(&c->hashes[0]);
>
> AVOutputFormat.deinit() is called when AVOutputFormat.init() fails, so
> c->hashes can be NULL. same with the framehash muxer.
BTW, do we have any tools or methods for triggering these failure paths
(without modifying the tested code)? Like an LD_PRELOAD lib to randomly
or directedly fail av_malloc*()? Or is all this covered by review and
fuzzing(?) only?
I only do random short use cases and corner/error cases with valgrind,
but that doesn't hit ENOMEM.
Thanks,
Moritz
___
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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
Content-Type: text/plain; charset=y error: cannot convert from y to UTF-8 fatal: could not parse patch On Wed, Sep 11, 2019 at 12:05:58AM +0800, Linjie Fu wrote: > Add some packed pixel formats for hardware decode support in VAAPI > and QSV: > > 4:2:2 10 bit: Y210 > 4:4:4 8 bit: AYUV > 4:4:4 10 bit: Y410 > > Signed-off-by: Linjie Fu > --- > libavutil/pixdesc.c | 62 > +++ > libavutil/pixfmt.h| 9 +++ > libavutil/tests/pixfmt_best.c | 1 + > libavutil/version.h | 2 +- > 4 files changed, 73 insertions(+), 1 deletion(-) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Elect your leaders based on what they did after the last election, not based on what they say before an election. 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 v2] avcodec/h2645_parse: refine the code for better readiablity
On Wed, Sep 11, 2019 at 10:29:14AM -0300, James Almer wrote:
> On 9/10/2019 2:38 AM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/h2645_parse.c | 10 --
> > 1 file changed, 4 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> > index 307e8643e6..f077900617 100644
> > --- a/libavcodec/h2645_parse.c
> > +++ b/libavcodec/h2645_parse.c
> > @@ -453,16 +453,15 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
> > uint8_t *buf, int length,
> > }
> > }
> >
> > -if (pkt->nals_allocated < pkt->nb_nals + 1) {
> > -int new_size = pkt->nals_allocated + 1;
> > -void *tmp = av_realloc_array(pkt->nals, new_size,
> > sizeof(*pkt->nals));
> > +if (pkt->nb_nals >= pkt->nals_allocated) {
> > +void *tmp = av_realloc_array(pkt->nals, pkt->nals_allocated +
> > 1, sizeof(*pkt->nals));
> >
> > if (!tmp)
> > return AVERROR(ENOMEM);
> >
> > pkt->nals = tmp;
> > -memset(pkt->nals + pkt->nals_allocated, 0,
> > - (new_size - pkt->nals_allocated) * sizeof(*pkt->nals));
> > +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals));
> > +pkt->nals_allocated++;
>
> The nal->skipped_bytes_pos allocation below can still fail. This counter
> shouldn't increase until all allocations have succeeded.
Yes, if the next line code use pkt->nals_allocated to get nal to allocate
by nal->skipped_bytes_pos then it's easy understand to move the counter
until all allocation are done.
>
> >
> > nal = &pkt->nals[pkt->nb_nals];
> > nal->skipped_bytes_pos_size = 1024; // initial buffer size
> > @@ -470,7 +469,6 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
> > uint8_t *buf, int length,
> > if (!nal->skipped_bytes_pos)
> > return AVERROR(ENOMEM);
> >
> > -pkt->nals_allocated = new_size;
> > }
> > nal = &pkt->nals[pkt->nb_nals];
> >
> >
>
> ___
> 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] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU
On Mon, Sep 02, 2019 at 06:24:08PM +0200, Timo Rothenpieler wrote: > I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and > AMF/Vulkan integration. > > Since there is personal information on the receipts, I won't post them here, > but can send them to the responsible person on request easily. > > Packaging: > PackSet M: 1.99€ > Bubble-Wrap "Protection Kit": 4.99€ > > Shipping: > Insured shipping via DHL (DE->US): 37.99€ > > Total cost: 44.97€ LGTM 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] Testing failure paths (Was: Re: [PATCH v2 2/3] avformat/hashenc: use an array of hashes)
On 9/11/2019 11:53 AM, Moritz Barsnick wrote:
> On Wed, Sep 11, 2019 at 10:39:40 -0300, James Almer wrote:
>>> +static void hash_free(struct AVFormatContext *s)
>>> +{
>>> +struct HashContext *c = s->priv_data;
>>> +av_hash_freep(&c->hashes[0]);
>>
>> AVOutputFormat.deinit() is called when AVOutputFormat.init() fails, so
>> c->hashes can be NULL. same with the framehash muxer.
>
> BTW, do we have any tools or methods for triggering these failure paths
> (without modifying the tested code)? Like an LD_PRELOAD lib to randomly
> or directedly fail av_malloc*()? Or is all this covered by review and
> fuzzing(?) only?
>
> I only do random short use cases and corner/error cases with valgrind,
> but that doesn't hit ENOMEM.
There's ulimit on Linux, but never used it. I know it's the standard way
to emulate low RAM environments to trigger ENOMEM errors and detect
unchecked allocs.
>
> Thanks,
> Moritz
> ___
> 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 v2 3/3] avformat/hashenc: add streamhash muxer
On 11-09-2019 08:19 PM, Moritz Barsnick wrote: On Wed, Sep 11, 2019 at 19:57:43 +0530, Gyan wrote: +ffmpeg -i INPUT -f streamhash -hash md5 - +@end example Since there's no mapping, this will select only one video and audio stream, but more importantly the video will be first, which may not be the case in the input. Maybe add mapping to the examples and/or add stream type to the hash printout. The original user suggesting this muxer also requested a stream type indicator. Is that info really useful and not redundant, assuming the user will need to understand the implications of remuxing anyway? A bit of redundancy is useful for error-checking. If I add this, and don't make it optional, what should the format be? Thus?: 0,v,SHA256=... 1,a,SHA256=... 2,s,SHA256=... Looks fine. Thanks, Gyan ___ 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 v1] fate: remove fate-checkasm-opusdsp for the segment fault for mac and linux system
From: Limin Wang Signed-off-by: Limin Wang --- tests/fate/checkasm.mak | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak index 3893245..618bde5 100644 --- a/tests/fate/checkasm.mak +++ b/tests/fate/checkasm.mak @@ -19,7 +19,6 @@ FATE_CHECKASM = fate-checkasm-aacpsdsp \ fate-checkasm-jpeg2000dsp \ fate-checkasm-llviddsp \ fate-checkasm-llviddspenc \ -fate-checkasm-opusdsp \ fate-checkasm-pixblockdsp \ fate-checkasm-sbrdsp\ fate-checkasm-synth_filter \ -- 2.6.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, v2 1/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
Previously, media driver provided planar format(like 420 8 bit),
but for HEVC Range Extension (422/444 8/10 bit), the decoded image
is produced in packed format because Windows expects it.
Add some packed pixel formats for hardware decode support in VAAPI
and QSV:
4:2:2 10 bit: Y210
4:4:4 8 bit: AYUV
4:4:4 10 bit: Y410
Signed-off-by: Linjie Fu
---
libavutil/pixdesc.c | 62 +++
libavutil/pixfmt.h| 9 +++
libavutil/tests/pixfmt_best.c | 1 +
libavutil/version.h | 2 +-
4 files changed, 73 insertions(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 05dd4a1..c2de0d8 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -205,6 +205,68 @@ static const AVPixFmtDescriptor
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
{ 0, 4, 1, 0, 8, 3, 7, 2 },/* V */
},
},
+[AV_PIX_FMT_Y210LE] = {
+.name = "y210le",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
+{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
+{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
+},
+},
+[AV_PIX_FMT_Y210BE] = {
+.name = "y210be",
+.nb_components = 3,
+.log2_chroma_w = 1,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 0, 6, 10, 3, 9, 1 },/* Y */
+{ 0, 8, 2, 6, 10, 7, 9, 3 },/* U */
+{ 0, 8, 6, 6, 10, 7, 9, 7 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_BE,
+},
+[AV_PIX_FMT_AYUV] = {
+.name = "ayuv",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 4, 1, 0, 8, 3, 7, 2 },/* Y */
+{ 0, 4, 2, 0, 8, 3, 7, 3 },/* U */
+{ 0, 4, 3, 0, 8, 3, 7, 4 },/* V */
+{ 0, 4, 0, 0, 8, 3, 7, 1 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA,
+},
+[AV_PIX_FMT_Y410LE] = {
+.name = "y410le",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
+{ 0, 32, 0, 0, 10, 31, 9, 1 },/* U */
+{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
+{ 0, 32, 30, 0, 2, 31, 1, 31 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM,
+},
+[AV_PIX_FMT_Y410BE] = {
+.name = "y410be",
+.nb_components = 4,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 32, 10, 0, 10, 31, 9, 11 },/* Y */
+{ 0, 32, 0, 0, 10, 31, 9, 1 },/* U */
+{ 0, 32, 20, 0, 10, 31, 9, 21 },/* V */
+{ 0, 32, 30, 0, 2, 31, 1, 31 },/* A */
+},
+.flags = AV_PIX_FMT_FLAG_ALPHA | AV_PIX_FMT_FLAG_BITSTREAM |
AV_PIX_FMT_FLAG_BE,
+},
[AV_PIX_FMT_RGB24] = {
.name = "rgb24",
.nb_components = 3,
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index d78e863..072a0b7 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -348,6 +348,12 @@ enum AVPixelFormat {
AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1
plane for the UV components, which are interleaved (first byte U and the
following byte V)
AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
+AV_PIX_FMT_Y210BE,///< packed YUV 4:2:2, 20bpp, Y0 Cb Y1 Cr, big-endian
+AV_PIX_FMT_Y210LE,///< packed YUV 4:2:2, 20bpp, Y0 Cb Y1 Cr,
little-endian
+AV_PIX_FMT_AYUV, ///< packed YUV 4:4:4, 32bpp, A Y Cb Cr,
+AV_PIX_FMT_Y410LE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A,
little-endian
+AV_PIX_FMT_Y410BE,///< packed YUV 4:4:4, 32bpp, Cr Y Cb A, big-endian
+
AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you
want to link with shared libav* because the number of formats might differ
between versions
};
@@ -436,6 +442,9 @@ enum AVPixelFormat {
#define AV_PIX_FMT_P010 AV_PIX_FMT_NE(P010BE, P010LE)
#define AV_PIX_FMT_P016 AV_PIX_FMT_NE(P016BE, P016LE)
+#define AV_PIX_FMT_Y210 AV_PIX_FMT_NE(Y210BE, Y210LE)
+#define AV_PIX_FMT_Y410 AV_PIX_FMT_NE(Y410BE, Y410LE)
+
/**
* Chromaticity coordinates of the source primaries.
* These values match the ones defined by ISO/IEC 23001-8_2013 § 7.1.
diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c
index 53f7264..2939e48 100644
--- a/libavutil/tests/pixfmt_best.c
+++ b/libavutil/tests/pixfmt_best.c
@@ -91,6 +91,7 @@ int main(void)
TEST(AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUV420P);
TEST(AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUV422P);
TEST(AV_PIX_FMT_YUVA444P, AV_PIX_FMT_YUV444P);
+
Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Wednesday, September 11, 2019 23:06 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > ayuv/y210/y410 > > > Content-Type: text/plain; charset=y > > error: cannot convert from y to UTF-8 > fatal: could not parse patch Occasionally meet this prompt while sending out the patch: "The following files are 8bit, but do not declare a Content-Transfer-Encoding. 0001-lavu-pixfmt-add-new-pixel-format-ayuv-y210-y410.patch Which 8bit encoding should I declare [UTF-8]?" Seems I should press enter to choose the default [UTF-8] charset instead of pressing "y". This patch has been resent, thanks. - 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] avformat/rtpdec_rfc4175: support non-zero based line numbers
On Wed, Aug 28, 2019 at 11:12:51PM +0800, Kah Goh wrote:
> There are differing standards that define different starting line
> numbers. For example, VSF TR-03 says the line numbers starts at 1,
> whereas SMPTE 2110-20 says it should start at 0.
>
> This change fixes the following issues when the line numbering start
> at 1:
> - The first scan line was being incorrectly interpreted as the second
> scan line. This means the first line in the frame was never being
> populated.
> - The last packet for the video frame would be treated as invalid
> because it would have been copied outside of the frame. Consequently,
> the packet would never be "finalized" and the next packet triggers a
> missed RTP marker ("Missed previous RTP marker" would keep being
> logged).
>
> VSF TR-03:
> http://www.videoservicesforum.org/download/technical_recommendations/VSF_TR-03_2015-11-12.pdf
>
> Co-Authored-By: Jacob Siddall
> Co-Authored-By: Kah Goh
> Signed-off-by: Kah Goh
> ---
> libavformat/rtpdec_rfc4175.c | 41 +---
> 1 file changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> index e9c62c1389..427d4b31e2 100644
> --- a/libavformat/rtpdec_rfc4175.c
> +++ b/libavformat/rtpdec_rfc4175.c
> @@ -25,6 +25,7 @@
> #include "rtpdec_formats.h"
> #include "libavutil/avstring.h"
> #include "libavutil/pixdesc.h"
> +#include
>
> struct PayloadContext {
> char *sampling;
> @@ -37,6 +38,12 @@ struct PayloadContext {
> unsigned int pgroup; /* size of the pixel group in bytes */
> unsigned int xinc;
>
> +/* The line number of the first line in the frame (usually either 0 or
> 1). */
> +int first_line_number;
> +
> +/* This is set to true once the first line number is confirmed. */
> +bool first_line_number_known;
> +
> uint32_t timestamp;
> };
>
> @@ -136,6 +143,13 @@ static int rfc4175_finalize_packet(PayloadContext *data,
> AVPacket *pkt,
> return ret;
> }
>
> +static int rfc4175_initialize(AVFormatContext *s, int st_index,
> PayloadContext *data)
> +{
> +data->first_line_number = 0;
> +data->first_line_number_known = false;
> +return 0;
> +}
> +
> static int rfc4175_handle_packet(AVFormatContext *ctx, PayloadContext *data,
> AVStream *st, AVPacket *pkt, uint32_t
> *timestamp,
> const uint8_t * buf, int len,
> @@ -199,6 +213,11 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> cont = headers[4] & 0x80;
> headers += 6;
>
> +if (line == 0) {
> +data->first_line_number = 0;
> +data->first_line_number_known = true;
> +}
> +
> if (length % data->pgroup)
> return AVERROR_INVALIDDATA;
>
> @@ -206,9 +225,15 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> length = payload_len;
>
> /* prevent ill-formed packets to write after buffer's end */
> -copy_offset = (line * data->width + offset) * data->pgroup /
> data->xinc;
> -if (copy_offset + length > data->frame_size)
> -return AVERROR_INVALIDDATA;
> +copy_offset = ((line - data->first_line_number) * data->width +
> offset) * data->pgroup / data->xinc;
> +if (copy_offset + length > data->frame_size) {
> +if (data->first_line_number_known)
> +return AVERROR_INVALIDDATA;
> +
> +// This would happen if the line numbering is 1 based. We still
> need to check for the RTP flag
> +// marker (as per after the while loop).
> +break;
> +}
>
> dest = data->frame + copy_offset;
> memcpy(dest, payload, length);
> @@ -218,6 +243,15 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> } while (cont);
>
> if ((flags & RTP_FLAG_MARKER)) {
> +if (!data->first_line_number_known) {
> +data->first_line_number = line - data->height + 1;
> +if (data->first_line_number < 0) {
> +// This could happen if the frame does not fill up the
> entire height.
> +data->first_line_number = 0;
> +av_log(ctx, AV_LOG_WARNING, "Video frame does not fill
> entire height");
> +}
> +data->first_line_number_known = true;
What if the last line is larger than height ?
first_line_number is only checked for <0 not >1 nor >height
but maybe ive missed some check
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-
[FFmpeg-devel] [PATCH 1/4] cbs: Add some common code for read/write of miscellaneous user data
From: Mark Thompson
Supports closed captions, active format and bar data as defined by
SCTE 128 part 1 or A/53 part 4, suitable for use with both MPEG-2
and H.264.
---
libavcodec/cbs_misc.c | 217 ++
libavcodec/cbs_misc.h | 109 +
libavcodec/cbs_misc_syntax_template.c | 150 ++
3 files changed, 476 insertions(+)
create mode 100644 libavcodec/cbs_misc.c
create mode 100644 libavcodec/cbs_misc.h
create mode 100644 libavcodec/cbs_misc_syntax_template.c
diff --git a/libavcodec/cbs_misc.c b/libavcodec/cbs_misc.c
new file mode 100644
index 00..d0ced562f5
--- /dev/null
+++ b/libavcodec/cbs_misc.c
@@ -0,0 +1,217 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/attributes.h"
+#include "libavutil/avassert.h"
+
+#include "cbs.h"
+#include "cbs_internal.h"
+#include "cbs_misc.h"
+
+#define CHECK(call) do { \
+err = (call); \
+if (err < 0) \
+return err; \
+} while (0)
+
+#define FUNC_NAME(rw, codec, name) cbs_ ## codec ## _ ## rw ## _ ## name
+#define FUNC_MISC(rw, name) FUNC_NAME(rw, misc, name)
+#define FUNC(name) FUNC_MISC(READWRITE, name)
+
+
+#define READWRITE read
+#define RWContext GetBitContext
+
+#define xui(width, name, var) do { \
+uint32_t value = 0; \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, NULL, \
+ &value, 0, MAX_UINT_BITS(width))); \
+var = value; \
+} while (0)
+
+#define ui(width, name) \
+xui(width, name, current->name)
+
+#define fixed(width, name, expected) do { \
+av_unused uint32_t value; \
+CHECK(ff_cbs_read_unsigned(ctx, rw, width, #name, NULL, \
+ &value, expected, expected)); \
+} while (0)
+
+#include "cbs_misc_syntax_template.c"
+
+#undef READWRITE
+#undef RWContext
+#undef xui
+#undef ui
+#undef fixed
+
+
+#define READWRITE write
+#define RWContext PutBitContext
+
+#define xui(width, name, var) do { \
+CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, NULL, \
+var, 0, MAX_UINT_BITS(width))); \
+} while (0)
+
+#define ui(width, name) \
+xui(width, name, current->name)
+
+#define fixed(width, name, value) do { \
+CHECK(ff_cbs_write_unsigned(ctx, rw, width, #name, NULL, \
+value, value, value)); \
+} while (0)
+
+#include "cbs_misc_syntax_template.c"
+
+#undef READWRITE
+#undef RWContext
+#undef xui
+#undef ui
+#undef fixed
+
+
+int ff_cbs_read_a53_user_data(CodedBitstreamContext *ctx,
+ A53UserData *data,
+ const uint8_t *read_buffer, size_t length)
+{
+GetBitContext gbc;
+int err;
+
+err = init_get_bits(&gbc, read_buffer, 8 * length);
+if (err < 0)
+return err;
+
+return cbs_misc_read_a53_user_data(ctx, &gbc, data);
+}
+
+int ff_cbs_write_a53_user_data(CodedBitstreamContext *ctx,
+ uint8_t *write_buffer, size_t *length,
+ A53UserData *data)
+{
+PutBitContext pbc;
+int err;
+
+init_put_bits(&pbc, write_buffer, *length);
+
+err = cbs_misc_write_a53_user_data(ctx, &pbc, data);
+if (err < 0) {
+// Includes AVERROR(ENOSPC).
+return err;
+}
+
+// That output must be aligned.
+av_assert0(put_bits_count(&pbc) % 8 == 0);
+
+*length = put_bits_count(&pbc) / 8;
+
+flush_put_bits(&pbc);
+
+return 0;
+}
+
+int ff_cbs_read_a53_cc_side_data(CodedBitstreamContext *ctx,
+ A53UserData *data,
+ const uint8_t *side_data,
+ size_t side_data_size)
+{
+GetBitContext gbc;
+CEA708CCData *cc;
+int err, i, cc_count;
+
+if (side_data_size % 3) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "A53 CC side data length must "
+ "be a multiple of 3 (got %zu).\n", side_data_size);
+return AVERROR(EINVAL);
+}
+cc_count = side_data_size / 3;
+if (cc_count > 31) {
+av_log(ctx->log_ctx, AV_LOG_ERROR, "A53 CC can only fit 31 packets "
+ "in a single user dat
[FFmpeg-devel] [PATCH 2/4] h264_metadata: Add support for A/53 closed captions
From: Mark Thompson
Allows insertion (from side data), extraction (to side data), and removal
of closed captions in SEI messages.
---
libavcodec/Makefile| 2 +-
libavcodec/h264_metadata_bsf.c | 133 +
2 files changed, 134 insertions(+), 1 deletion(-)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6bc4383c8f..b10064776c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1079,7 +1079,7 @@ OBJS-$(CONFIG_EAC3_CORE_BSF) +=
eac3_core_bsf.o
OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF) += extract_extradata_bsf.o\
av1_parse.o h2645_parse.o
OBJS-$(CONFIG_FILTER_UNITS_BSF) += filter_units_bsf.o
-OBJS-$(CONFIG_H264_METADATA_BSF) += h264_metadata_bsf.o h264_levels.o
+OBJS-$(CONFIG_H264_METADATA_BSF) += h264_metadata_bsf.o h264_levels.o
cbs_misc.o
OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF) += h264_mp4toannexb_bsf.o
OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
OBJS-$(CONFIG_HAPQA_EXTRACT_BSF) += hapqa_extract_bsf.o hap.o
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 5de74be9d6..65c7b7b55e 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -24,6 +24,7 @@
#include "bsf.h"
#include "cbs.h"
#include "cbs_h264.h"
+#include "cbs_misc.h"
#include "h264.h"
#include "h264_levels.h"
#include "h264_sei.h"
@@ -84,6 +85,7 @@ typedef struct H264MetadataContext {
int flip;
int level;
+int a53_cc;
} H264MetadataContext;
@@ -281,6 +283,8 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket
*pkt)
CodedBitstreamFragment *au = &ctx->access_unit;
int err, i, j, has_sps;
H264RawAUD aud;
+uint8_t *a53_side_data = NULL;
+size_t a53_side_data_size = 0;
err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
@@ -556,6 +560,122 @@ static int h264_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
}
}
+if (ctx->a53_cc == INSERT) {
+uint8_t *data;
+int size;
+
+data = av_packet_get_side_data(pkt, AV_PKT_DATA_A53_CC, &size);
+if (data) {
+A53UserData a53_ud;
+
+err = ff_cbs_read_a53_cc_side_data(ctx->cbc, &a53_ud,
+ data, size);
+if (err < 0) {
+av_log(bsf, AV_LOG_WARNING, "Invalid A/53 closed captions "
+ "in packet side data dropped.\n");
+} else {
+H264RawSEIPayload payload = {
+.payload_type = H264_SEI_TYPE_USER_DATA_REGISTERED,
+};
+H264RawSEIUserDataRegistered *udr =
+&payload.payload.user_data_registered;
+size_t size = 9 + 3 * a53_ud.atsc.cc_data.cc_count;
+
+udr->data_ref = av_buffer_alloc(2 + size);
+if (!udr->data_ref) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+udr->data = udr->data_ref->data;
+
+udr->itu_t_t35_country_code = 181;
+AV_WB16(udr->data, 49); // provider_code
+
+err = ff_cbs_write_a53_user_data(ctx->cbc, udr->data + 2,
+ &size, &a53_ud);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to write "
+ "A/53 user data.\n");
+av_buffer_unref(&udr->data_ref);
+goto fail;
+}
+udr->data_length = size + 2;
+
+err = ff_cbs_h264_add_sei_message(ctx->cbc, au, &payload);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to add A/53 user data "
+ "SEI message to access unit.\n");
+av_buffer_unref(&udr->data_ref);
+goto fail;
+}
+}
+}
+
+} else if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
+for (i = 0; i < au->nb_units; i++) {
+H264RawSEI *sei;
+if (au->units[i].type != H264_NAL_SEI)
+continue;
+sei = au->units[i].content;
+
+for (j = 0; j < sei->payload_count; j++) {
+H264RawSEIUserDataRegistered *udr;
+A53UserData a53_ud;
+
+if (sei->payload[j].payload_type !=
+H264_SEI_TYPE_USER_DATA_REGISTERED)
+continue;
+udr = &sei->payload[j].payload.user_data_registered;
+if (udr->data_length < 6) {
+// Can't be relevant.
+continue;
+}
+
+err = ff_cbs_read_a53_user_data(ctx->cbc, &a53_ud,
+udr->data + 2,
+
[FFmpeg-devel] [PATCH 4/4] mpeg2_metadata: Add support for A/53 closed captions
From: Mark Thompson
Allows extraction (to side data) and removal of closed captions in
user data blocks.
---
doc/bitstream_filters.texi | 12 ++
libavcodec/Makefile | 2 +-
libavcodec/mpeg2_metadata_bsf.c | 76 -
3 files changed, 88 insertions(+), 2 deletions(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 8e957ae4a8..05f88e466d 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -548,6 +548,18 @@ table 6-6).
Set the colour description in the stream (see H.262 section 6.3.6
and tables 6-7, 6-8 and 6-9).
+@item a53_cc
+Modify A/53 closed captions in user data blocks.
+
+@table @samp
+@item remove
+Remove all closed caption data from the stream.
+
+@item extract
+Extract closed captions from the stream so that they are available as
+as packet side data.
+@end table
+
@end table
@section mpeg4_unpack_bframes
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b10064776c..e691181996 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1092,7 +1092,7 @@ OBJS-$(CONFIG_MPEG4_UNPACK_BFRAMES_BSF) +=
mpeg4_unpack_bframes_bsf.o
OBJS-$(CONFIG_MOV2TEXTSUB_BSF)+= movsub_bsf.o
OBJS-$(CONFIG_MP3_HEADER_DECOMPRESS_BSF) += mp3_header_decompress_bsf.o \
mpegaudiodata.o
-OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o
+OBJS-$(CONFIG_MPEG2_METADATA_BSF) += mpeg2_metadata_bsf.o cbs_misc.o
OBJS-$(CONFIG_NOISE_BSF) += noise_bsf.o
OBJS-$(CONFIG_NULL_BSF) += null_bsf.o
OBJS-$(CONFIG_PRORES_METADATA_BSF)+= prores_metadata_bsf.o
diff --git a/libavcodec/mpeg2_metadata_bsf.c b/libavcodec/mpeg2_metadata_bsf.c
index 3f371a028d..e82758d2eb 100644
--- a/libavcodec/mpeg2_metadata_bsf.c
+++ b/libavcodec/mpeg2_metadata_bsf.c
@@ -22,9 +22,17 @@
#include "bsf.h"
#include "cbs.h"
+#include "cbs_misc.h"
#include "cbs_mpeg2.h"
#include "mpeg12.h"
+enum {
+PASS,
+INSERT,
+REMOVE,
+EXTRACT,
+};
+
typedef struct MPEG2MetadataContext {
const AVClass *class;
@@ -42,6 +50,8 @@ typedef struct MPEG2MetadataContext {
int transfer_characteristics;
int matrix_coefficients;
+int a53_cc;
+
int mpeg1_warned;
} MPEG2MetadataContext;
@@ -173,7 +183,9 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
{
MPEG2MetadataContext *ctx = bsf->priv_data;
CodedBitstreamFragment *frag = &ctx->fragment;
-int err;
+int err, i;
+uint8_t *a53_side_data = NULL;
+size_t a53_side_data_size = 0;
err = ff_bsf_get_packet_ref(bsf, pkt);
if (err < 0)
@@ -191,6 +203,57 @@ static int mpeg2_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
goto fail;
}
+if (ctx->a53_cc == REMOVE || ctx->a53_cc == EXTRACT) {
+for (i = 0; i < frag->nb_units; i++) {
+MPEG2RawUserData *ud;
+A53UserData a53_ud;
+
+if (frag->units[i].type != MPEG2_START_USER_DATA)
+continue;
+ud = frag->units[i].content;
+
+err = ff_cbs_read_a53_user_data(ctx->cbc, &a53_ud, ud->user_data,
+ud->user_data_length);
+if (err < 0) {
+// Invalid or something completely different.
+continue;
+}
+if (a53_ud.user_identifier != A53_USER_IDENTIFIER_ATSC ||
+a53_ud.atsc.user_data_type_code !=
+A53_USER_DATA_TYPE_CODE_CC_DATA) {
+// Valid but something else (e.g. AFD).
+continue;
+}
+
+if (ctx->a53_cc == REMOVE) {
+ff_cbs_delete_unit(ctx->cbc, frag, i);
+--i;
+break;
+} else if(ctx->a53_cc == EXTRACT) {
+err = ff_cbs_write_a53_cc_side_data(ctx->cbc,
+&a53_side_data,
+&a53_side_data_size,
+&a53_ud);
+if (err < 0) {
+av_log(bsf, AV_LOG_ERROR, "Failed to write "
+ "A/53 user data for packet side data.\n");
+goto fail;
+}
+
+if (a53_side_data) {
+err = av_packet_add_side_data(pkt, AV_PKT_DATA_A53_CC,
+ a53_side_data,
a53_side_data_size);
+if (err) {
+av_log(bsf, AV_LOG_ERROR, "Failed to attach extracted
A/53 "
+ "side data to packet.\n");
+goto fail;
+}
+a53_side_data = NULL;
+}
+}
+}
+}
+
err = ff_cbs_write_packet(ctx->cbc, pkt, frag);
if (err < 0) {
av_lo
[FFmpeg-devel] [PATCH 3/4] h264_metadata: Update documentation
From: Mark Thompson
Improve documentation for the delete_filler option, and add the
display_orientation and a53_cc options.
---
doc/bitstream_filters.texi | 51 +-
1 file changed, 50 insertions(+), 1 deletion(-)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 50a1679fc7..8e957ae4a8 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -274,7 +274,56 @@ For example,
@samp{086f3693-b7b3-4f2c-9653-21492feee5b8+hello} will
insert the string ``hello'' associated with the given UUID.
@item delete_filler
-Deletes both filler NAL units and filler SEI messages.
+Delete all filler in the stream: both filler data NAL units and
+filler payload SEI messages.
+
+Filler zero bytes between NAL units in Annex B format (leading_zero_8bits
+and trailing_zero_8bits) will be discarded from the stream with or
+without this option - as such, HRD parameters are not expected to be
+accurate after any rewriting transformation made by this filter.
+
+@item display_orientation
+Modify display orientation SEI messages.
+
+@table @samp
+@item insert
+Insert new display orientation messages, overwriting any currently in
+the stream. The new value is taken from the packet side data, modified
+by the @option{rotate} and @option{flip} options.
+
+@item remove
+Remove all display orientation messages from the stream.
+
+@item extract
+Extract display orientation messages so that they are available as
+packet side data.
+@end table
+
+@item rotate
+Set the rotation angle in the display orientation data. This is an
+anticlockwise rotation angle in degrees.
+@item flip
+Set the flip fields in the display orientation data. This can be any
+combination of the flags:
+@table @samp
+@item horizontal
+@item vertical
+@end table
+
+@item a53_cc
+Modify A/53 closed caption data in SEI messages.
+
+@table @samp
+@item insert
+Insert closed captions taken from packet side data into the stream.
+
+@item remove
+Remove all closed caption data from the stream.
+
+@item extract
+Extract closed captions from the stream so that they are available as
+as packet side data.
+@end table
@item level
Set the level in the SPS. Refer to H.264 section A.3 and tables A-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] avcodec/dvdec: correctly decode bottom mb row in 1080i field mode
---
libavcodec/dv.h| 2 ++
libavcodec/dvdec.c | 90 +++---
2 files changed, 72 insertions(+), 20 deletions(-)
diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 0e97bb200e..7ef5b7c552 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -31,6 +31,7 @@
#include "dv_profile.h"
#include "me_cmp.h"
#include "vlc.h"
+#include "idctdsp.h"
typedef struct DVwork_chunk {
uint16_t buf_offset;
@@ -52,6 +53,7 @@ typedef struct DVVideoContext {
me_cmp_func ildct_cmp;
DVwork_chunk work_chunks[4 * 12 * 27];
uint32_t idct_factor[2 * 4 * 16 * 64];
+IDCTDSPContext idsp;
int quant_deadzone;
} DVVideoContext;
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 89864f2edc..4345cd9e29 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -45,7 +45,6 @@
#include "dv_profile_internal.h"
#include "dvdata.h"
#include "get_bits.h"
-#include "idctdsp.h"
#include "internal.h"
#include "put_bits.h"
#include "simple_idct.h"
@@ -177,24 +176,22 @@ static void dv_init_weight_tables(DVVideoContext *ctx,
const AVDVProfile *d)
static av_cold int dvvideo_decode_init(AVCodecContext *avctx)
{
DVVideoContext *s = avctx->priv_data;
-IDCTDSPContext idsp;
int i;
-memset(&idsp,0, sizeof(idsp));
-ff_idctdsp_init(&idsp, avctx);
+ff_idctdsp_init(&s->idsp, avctx);
for (i = 0; i < 64; i++)
-s->dv_zigzag[0][i] = idsp.idct_permutation[ff_zigzag_direct[i]];
+s->dv_zigzag[0][i] = s->idsp.idct_permutation[ff_zigzag_direct[i]];
if (avctx->lowres){
for (i = 0; i < 64; i++){
int j = ff_dv_zigzag248_direct[i];
-s->dv_zigzag[1][i] = idsp.idct_permutation[(j & 7) + (j & 8) * 4 +
(j & 48) / 2];
+s->dv_zigzag[1][i] = s->idsp.idct_permutation[(j & 7) + (j & 8) *
4 + (j & 48) / 2];
}
}else
memcpy(s->dv_zigzag[1], ff_dv_zigzag248_direct,
sizeof(s->dv_zigzag[1]));
-s->idct_put[0] = idsp.idct_put;
+s->idct_put[0] = s->idsp.idct_put;
s->idct_put[1] = ff_simple_idct248_put;
return ff_dvvideo_init(avctx);
@@ -272,6 +269,49 @@ static inline void bit_copy(PutBitContext *pb,
GetBitContext *gb)
put_bits(pb, bits_left, get_bits(gb, bits_left));
}
+static av_always_inline void put_block_8x4(int16_t *block, uint8_t *restrict
p, int stride)
+{
+int i, j;
+const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
+
+for (i = 0; i < 4; i++) {
+for (j = 0; j < 8; j++)
+p[j] = cm[block[j]];
+block += 8;
+p += stride;
+}
+}
+
+static void dv100_idct_put_last_row_field_chroma(DVVideoContext *s, uint8_t
*data,
+ int stride, int16_t *blocks)
+{
+s->idsp.idct(blocks + 0*64);
+s->idsp.idct(blocks + 1*64);
+
+put_block_8x4(blocks+0*64, data, stride<<1);
+put_block_8x4(blocks+0*64 + 4*8, data + 8, stride<<1);
+put_block_8x4(blocks+1*64, data + stride, stride<<1);
+put_block_8x4(blocks+1*64 + 4*8, data + 8 + stride, stride<<1);
+}
+
+static void dv100_idct_put_last_row_field_luma(DVVideoContext *s, uint8_t
*data,
+ int stride, int16_t *blocks)
+{
+s->idsp.idct(blocks + 0*64);
+s->idsp.idct(blocks + 1*64);
+s->idsp.idct(blocks + 2*64);
+s->idsp.idct(blocks + 3*64);
+
+put_block_8x4(blocks+0*64, data, stride<<1);
+put_block_8x4(blocks+0*64 + 4*8, data + 16, stride<<1);
+put_block_8x4(blocks+1*64, data + 8, stride<<1);
+put_block_8x4(blocks+1*64 + 4*8, data + 24, stride<<1);
+put_block_8x4(blocks+2*64, data + stride, stride<<1);
+put_block_8x4(blocks+2*64 + 4*8, data + 16 + stride, stride<<1);
+put_block_8x4(blocks+3*64, data + 8 + stride, stride<<1);
+put_block_8x4(blocks+3*64 + 4*8, data + 24 + stride, stride<<1);
+}
+
/* mb_x and mb_y are in units of 8 pixels */
static int dv_decode_video_segment(AVCodecContext *avctx, void *arg)
{
@@ -443,14 +483,18 @@ retry:
}
y_ptr= s->frame->data[0] +
((mb_y * s->frame->linesize[0] + mb_x) << log2_blocksize);
-linesize = s->frame->linesize[0] << is_field_mode[mb_index];
-mb[0].idct_put(y_ptr, linesize, block + 0 * 64);
-if (s->sys->video_stype == 4) { /* SD 422 */
-mb[2].idct_put(y_ptr + (1 << log2_blocksize),linesize,
block + 2 * 64);
+if (mb_y == 134 && is_field_mode[mb_index]) {
+dv100_idct_put_last_row_field_luma(s, y_ptr,
s->frame->linesize[0], block);
} else {
-mb[1].idct_put(y_ptr + (1 << log2_blocksize),linesize,
block + 1 * 64);
-mb[2].idct_put(y_ptr + y_stride, linesize,
block + 2 * 64);
-mb[3].idct_put(y_ptr + (1 << log2_blocksize) + y_stride, linesize,
block + 3 * 64)
[FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd
---
libavcodec/dv.h| 1 +
libavcodec/dvenc.c | 576 -
2 files changed, 522 insertions(+), 55 deletions(-)
diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 7ef5b7c552..0205d72347 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -83,6 +83,7 @@ enum dv_pack_type {
#define DV_PROFILE_IS_HD(p) ((p)->video_stype & 0x10)
#define DV_PROFILE_IS_1080i50(p) (((p)->video_stype == 0x14) && ((p)->dsf ==
1))
+#define DV_PROFILE_IS_1080i60(p) (((p)->video_stype == 0x14) && ((p)->dsf ==
0))
#define DV_PROFILE_IS_720p50(p) (((p)->video_stype == 0x18) && ((p)->dsf ==
1))
/**
diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
index ce2fc75daa..b7a771fa18 100644
--- a/libavcodec/dvenc.c
+++ b/libavcodec/dvenc.c
@@ -60,10 +60,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
ff_dv_print_profiles(avctx, AV_LOG_ERROR);
return AVERROR(EINVAL);
}
-if (avctx->height > 576) {
-av_log(avctx, AV_LOG_ERROR, "DVCPRO HD encoding is not supported.\n");
-return AVERROR_PATCHWELCOME;
-}
+
ret = ff_dv_init_dynamic_tables(s, s->sys);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Error initializing work tables.\n");
@@ -90,6 +87,7 @@ static av_cold int dvvideo_encode_init(AVCodecContext *avctx)
}
/* bit budget for AC only in 5 MBs */
+static const int vs_total_ac_bits_hd = (68 * 6 + 52*2) * 5;
static const int vs_total_ac_bits = (100 * 4 + 68 * 2) * 5;
static const int mb_area_start[5] = { 1, 6, 21, 43, 64 };
@@ -158,6 +156,11 @@ typedef struct EncBlockInfo {
uint8_t sign[64];
uint8_t partial_bit_count;
uint32_t partial_bit_buffer; /* we can't use uint16_t here */
+/* used by DV100 only: a copy of the weighted and classified but
+ not-yet-quantized AC coefficients. This is necessary for
+ re-quantizing at different steps. */
+int16_t save[64];
+int min_qlevel; /* DV100 only: minimum qlevel (for AC coefficients
>255) */
} EncBlockInfo;
static av_always_inline PutBitContext *dv_encode_ac(EncBlockInfo *bi,
@@ -243,13 +246,135 @@ static const int dv_weight_248[64] = {
170627, 170627, 153560, 153560, 165371, 165371, 144651, 144651,
};
-static av_always_inline int dv_init_enc_block(EncBlockInfo *bi, uint8_t *data,
- ptrdiff_t linesize,
- DVVideoContext *s, int bias)
+/* setting this to 1 results in a faster codec but
+ * somewhat lower image quality */
+#define DV100_SACRIFICE_QUALITY_FOR_SPEED 1
+#define DV100_ENABLE_FINER 1
+
+/* pack combination of QNO and CNO into a single 8-bit value */
+#define DV100_MAKE_QLEVEL(qno,cno) ((qno<<2) | (cno))
+#define DV100_QLEVEL_QNO(qlevel) (qlevel>>2)
+#define DV100_QLEVEL_CNO(qlevel) (qlevel&0x3)
+
+#define DV100_NUM_QLEVELS 31
+
+/* The quantization step is determined by a combination of QNO and
+ CNO. We refer to these combinations as "qlevels" (this term is our
+ own, it's not mentioned in the spec). We use CNO, a multiplier on
+ the quantization step, to "fill in the gaps" between quantization
+ steps associated with successive values of QNO. e.g. there is no
+ QNO for a quantization step of 10, but we can use QNO=5 CNO=1 to
+ get the same result. The table below encodes combinations of QNO
+ and CNO in order of increasing quantization coarseness. */
+static const uint8_t dv100_qlevels[DV100_NUM_QLEVELS] = {
+DV100_MAKE_QLEVEL( 1,0), // 1*1= 1
+DV100_MAKE_QLEVEL( 1,0), // 1*1= 1
+DV100_MAKE_QLEVEL( 2,0), // 2*1= 2
+DV100_MAKE_QLEVEL( 3,0), // 3*1= 3
+DV100_MAKE_QLEVEL( 4,0), // 4*1= 4
+DV100_MAKE_QLEVEL( 5,0), // 5*1= 5
+DV100_MAKE_QLEVEL( 6,0), // 6*1= 6
+DV100_MAKE_QLEVEL( 7,0), // 7*1= 7
+DV100_MAKE_QLEVEL( 8,0), // 8*1= 8
+DV100_MAKE_QLEVEL( 5,1), // 5*2=10
+DV100_MAKE_QLEVEL( 6,1), // 6*2=12
+DV100_MAKE_QLEVEL( 7,1), // 7*2=14
+DV100_MAKE_QLEVEL( 9,0), // 16*1=16
+DV100_MAKE_QLEVEL(10,0), // 18*1=18
+DV100_MAKE_QLEVEL(11,0), // 20*1=20
+DV100_MAKE_QLEVEL(12,0), // 22*1=22
+DV100_MAKE_QLEVEL(13,0), // 24*1=24
+DV100_MAKE_QLEVEL(14,0), // 28*1=28
+DV100_MAKE_QLEVEL( 9,1), // 16*2=32
+DV100_MAKE_QLEVEL(10,1), // 18*2=36
+DV100_MAKE_QLEVEL(11,1), // 20*2=40
+DV100_MAKE_QLEVEL(12,1), // 22*2=44
+DV100_MAKE_QLEVEL(13,1), // 24*2=48
+DV100_MAKE_QLEVEL(15,0), // 52*1=52
+DV100_MAKE_QLEVEL(14,1), // 28*2=56
+DV100_MAKE_QLEVEL( 9,2), // 16*4=64
+DV100_MAKE_QLEVEL(10,2), // 18*4=72
+DV100_MAKE_QLEVEL(11,2), // 20*4=80
+DV100_MAKE_QLEVEL(12,2), // 22*4=88
+DV100_MAKE_QLEVEL(13,2), // 24*4=96
+// ...
+DV100_MAKE_QLEVEL(15,3), // 52*8=416
+};
+
+/* how much to increase qlevel when we need to compress more coarsely */
+/* this is a tradeoff between encoding speed and space efficiency */
+/* the highest-quality, lowest-speed option it to use 1 for all qlevel
[FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff
---
libavcodec/dvdec.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
index 4345cd9e29..cfa0fb9905 100644
--- a/libavcodec/dvdec.c
+++ b/libavcodec/dvdec.c
@@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext *avctx,
void *data,
if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
return ret;
-frame.f->interlaced_frame = 1;
-frame.f->top_field_first = 0;
/* Determine the codec's field order from the packet */
if ( *vsc_pack == dv_video_control ) {
-frame.f->top_field_first = !(vsc_pack[3] & 0x40);
+if (avctx->height == 720) {
+frame.f->interlaced_frame = 0;
+frame.f->top_field_first = 0;
+} else if (avctx->height == 1080) {
+frame.f->interlaced_frame = 1;
+frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
+} else {
+frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
+frame.f->top_field_first = !(vsc_pack[3] & 0x40);
+}
}
s->buf = buf;
--
2.20.1 (Apple Git-117)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff
Am Mi., 11. Sept. 2019 um 21:31 Uhr schrieb Baptiste Coudurier
:
>
> ---
> libavcodec/dvdec.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> index 4345cd9e29..cfa0fb9905 100644
> --- a/libavcodec/dvdec.c
> +++ b/libavcodec/dvdec.c
> @@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext *avctx,
> void *data,
>
> if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
> return ret;
> -frame.f->interlaced_frame = 1;
> -frame.f->top_field_first = 0;
>
> /* Determine the codec's field order from the packet */
> if ( *vsc_pack == dv_video_control ) {
> -frame.f->top_field_first = !(vsc_pack[3] & 0x40);
> +if (avctx->height == 720) {
> +frame.f->interlaced_frame = 0;
> +frame.f->top_field_first = 0;
> +} else if (avctx->height == 1080) {
> +frame.f->interlaced_frame = 1;
> +frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
> +} else {
> +frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
> +frame.f->top_field_first = !(vsc_pack[3] & 0x40);
Does this fix ticket #5092?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dvenc: support encoding dvcprohd
Am Mi., 11. Sept. 2019 um 21:30 Uhr schrieb Baptiste Coudurier : > > --- > libavcodec/dv.h| 1 + > libavcodec/dvenc.c | 576 - > 2 files changed, 522 insertions(+), 55 deletions(-) Please mention ticket #1370. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdec: correctly set interlaced and tff
Hey Carl,
> On Sep 11, 2019, at 12:38 PM, Carl Eugen Hoyos wrote:
>
> Am Mi., 11. Sept. 2019 um 21:31 Uhr schrieb Baptiste Coudurier
> :
>>
>> ---
>> libavcodec/dvdec.c | 13 ++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
>> index 4345cd9e29..cfa0fb9905 100644
>> --- a/libavcodec/dvdec.c
>> +++ b/libavcodec/dvdec.c
>> @@ -592,12 +592,19 @@ static int dvvideo_decode_frame(AVCodecContext *avctx,
>> void *data,
>>
>> if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
>> return ret;
>> -frame.f->interlaced_frame = 1;
>> -frame.f->top_field_first = 0;
>>
>> /* Determine the codec's field order from the packet */
>> if ( *vsc_pack == dv_video_control ) {
>> -frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>> +if (avctx->height == 720) {
>> +frame.f->interlaced_frame = 0;
>> +frame.f->top_field_first = 0;
>> +} else if (avctx->height == 1080) {
>> +frame.f->interlaced_frame = 1;
>> +frame.f->top_field_first = (vsc_pack[3] & 0x40) == 0x40;
>> +} else {
>> +frame.f->interlaced_frame = (vsc_pack[3] & 0x10) == 0x10;
>> +frame.f->top_field_first = !(vsc_pack[3] & 0x40);
>
> Does this fix ticket #5092?
Yes, I think it does
—
Baptiste Coudurier
___
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/6] lavu/pixfmt: add new pixel format ayuv/y210/y410
Am Mi., 11. Sept. 2019 um 09:35 Uhr schrieb Hendrik Leppkes : > > On Wed, Sep 11, 2019 at 5:20 AM Fu, Linjie wrote: > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > > Of Carl Eugen Hoyos > > > Sent: Wednesday, September 11, 2019 03:25 > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH 1/6] lavu/pixfmt: add new pixel format > > > ayuv/y210/y410 > > > > > > Am Di., 10. Sept. 2019 um 18:08 Uhr schrieb Linjie Fu > > > : > > > > > > > > Add some packed pixel formats for hardware decode support > > > > in VAAPI and QSV: > > > > > > > > 4:2:2 10 bit: Y210 > > > > 4:4:4 8 bit: AYUV > > > > 4:4:4 10 bit: Y410 > > > > > > Please add a short explanation (either in the commit message or > > > only in this thread) for which kind of samples these pixel formats > > > are needed. > > > > > > Or to say it differently: Why is the hardware outputting planar > > > formats for some samples and packed for others? > > > > I kind of remember that it was discussed in previous patch thread: > > Previously, media driver provided planar format(like 420 8 bit), > > but for HEVC Range Extension (422/444 8/10 bit), the decoded image > > is produced in packed format. And the reason is " because Windows > > expects it" as you have pointed. > > > > It could be updated in the commit message if this is good enough. > > > > > I see you added LE and BE versions: Why are both needed? > > > And if they are needed, why is there only AYUV and not AYUV > > > and VUYA? > > > > I noticed LE and BE versions are added for some of the added pixel > > format, out of the compatibility for big-endian and little-endian(IMHO). > > And that's the reason I add it for Y210 and Y410. > > > > I'm not sure I understood it correctly, LE/BE version is necessary for > > newly added pixel format right? > > > > It depends on the definition of the pixel format. AYUV is defined as > 4 consecutive BYTEs, which means its identical on LE and BE. > Y210 is defined as being stored as an array of 4 WORDs (Y0, U, Y1, V). > For a WORD, the difference of LE/BE matters. > Y410 is defined as being stored as a single DWORD, again LE/BE matters here. > > Obviously the differences in LE/BE need to be implemented properly as > well, for Y210 for each WORD, and for Y410 for the entire DWORD. I wonder if only the LE variants would be sufficient for the time being. Or is it (theoretically) possible to use this code on BE? Carl Eugen ___ 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] avcodec/vp56rac: delay signaling an error on truncated input
On Tue, Aug 20, 2019 at 11:51:49AM +0200, Michael Niedermayer wrote: > A threshold of 1 is sufficient for simple_dump_cut.webm, 10 is used > just to be sure the next truncated file doesnt cause the same issue > > Obvious alternative fixes are to simply accept that the file is broken or to > write some advanced error concealment or to > simply accept that the decoder wont stop at the end of input. > > Fixes: Ticket 8069 (artifacts not the differing md5 which was there before > 1afd246960202917e244c844c534e9c1e3c323f5) > Fixes: simple_dump_cut.webm > Fixes: regression of 1afd246960202917e244c844c534e9c1e3c323f5 > > fate-vp5 changes because the last frame is truncated and now handled > differently. > > Signed-off-by: Michael Niedermayer > --- > libavcodec/vp56.h| 5 - > libavcodec/vp56rac.c | 1 + > tests/ref/fate/vp5 | 2 +- > 3 files changed, 6 insertions(+), 2 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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 2/4] h264_metadata: Add support for A/53 closed captions
Am Mi., 11. Sept. 2019 um 20:56 Uhr schrieb Aman Gupta : > > From: Mark Thompson > > Allows insertion (from side data), extraction (to side data), and removal > of closed captions in SEI messages. Please mention ticket #5283. Carl Eugen ___ 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 v1] libavutil: add A2R10G10B10 & A2B10G10R10
Am Mi., 11. Sept. 2019 um 07:59 Uhr schrieb Zhou, Zachary
:
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of Carl
> > Eugen Hoyos
> > Sent: Wednesday, September 11, 2019 7:30 AM
> > To: FFmpeg development discussions and patches
> > Subject: Re: [FFmpeg-devel] [PATCH v1] libavutil: add A2R10G10B10 &
> > A2B10G10R10
> >
> > Am Di., 10. Sept. 2019 um 11:35 Uhr schrieb Zachary Zhou
> > :
> > >
> > > ---
> > > libavutil/hwcontext_vaapi.c | 6 ++
> > > libavutil/pixfmt.h | 3 +++
> > > 2 files changed, 9 insertions(+)
> > >
> > > diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> > > index cf117640f2..9838250b66 100644
> > > --- a/libavutil/hwcontext_vaapi.c
> > > +++ b/libavutil/hwcontext_vaapi.c
> > > @@ -125,6 +125,12 @@ static const VAAPIFormatDescriptor
> > > vaapi_format_map[] = { #endif
> > > MAP(BGRA, RGB32, BGRA, 0),
> > > MAP(BGRX, RGB32, BGR0, 0),
> > > +#ifdef VA_FOURCC_A2R10G10B10
> > > +MAP(A2R10G10B10, RGB32_10, A2R10G10B10, 0), #endif #ifdef
> > > +VA_FOURCC_A2B10G10R10
> > > +MAP(A2B10G10R10, RGB32_10, A2B10G10R10, 0), #endif
> > > MAP(RGBA, RGB32, RGBA, 0),
> > > MAP(RGBX, RGB32, RGB0, 0),
> > > #ifdef VA_FOURCC_ABGR
> > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h index
> > > d78e863d4b..e00f129b46 100644
> > > --- a/libavutil/pixfmt.h
> > > +++ b/libavutil/pixfmt.h
> > > @@ -348,6 +348,9 @@ enum AVPixelFormat {
> > > AV_PIX_FMT_NV24, ///< planar YUV 4:4:4, 24bpp, 1 plane for Y
> > > and 1
> > plane for the UV components, which are interleaved (first byte U and the
> > following byte V)
> > > AV_PIX_FMT_NV42, ///< as above, but U and V bytes are swapped
> > >
> > > +AV_PIX_FMT_A2R10G10B10, ///< 10-bit Pixel RGB formats.
> > > +AV_PIX_FMT_A2B10G10R10, ///< 10-bit Pixel BGR formats.
> >
> > The patch looks insufficient, see the patch to add AYUV and other packed
> > formats.
>
> Thank you for the review, I will refer these patches.
>
> >
> > The more important question imo is: Why are these formats needed, which
> > hardware produces them for which input?
>
> These formats target to Intel Ice Lake platform. will be use in HDR tone
> mapping filter. input is P010.
>
> welcome to review my HDR patch: https://patchwork.ffmpeg.org/patch/15018/
> I appreciate any comments.
Wouldn't it be more useful if your new filter outputs AV_PIX_FMT_GBRP10
for HDR output?
Carl Eugen
___
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] FW: [PATCH] Add option to log timing
Michael - you probably missed my question... -Original Message- From: Soft Works Sent: Friday, September 6, 2019 11:44 PM To: FFmpeg development discussions and patches Subject: RE: [FFmpeg-devel] [PATCH] Add option to log timing > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Friday, September 6, 2019 8:56 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Add option to log timing > > On Wed, Sep 04, 2019 at 07:35:11PM +, Soft Works wrote: > > > > > Why this restriction? I think all log lines should be start with > > > time/date if corresponding flag is present. This makes the log to > > > be easy to parse by scripts. > > > > Initially I didn’t have this restriction, but it doesn’t work well > > together with > some multi-line logging. > > See below for an example. > > > > To get this nice, it would require a larger amount of changes, and > > probably > result in something that nobody wants to merge in. > > > > Anyway, there’s a flag controlling this behavior and if you really > > want, you > can set it. > > Then you’ll see something like this: [...] > i just enabled prefixes for all calls, and i get this: > > [] libavutil 56. 35.100 / 56. 35.100 > [] libavcodec 58. 56.101 / 58. 56.101 [...] > > This looks much better than your example, so i have to disagree that > theres a problem for calls during startup or some requirment of high > complexity I need to apologize. I had been driven by another complication that exists in my branch but not in the ffmpeg trunk. I will submit an updated patch. What would you prefer - should I: 1. Activate the flag for adding log timing during startup by default (to allow opt-out behavior from the command line) or 2. Remove that flag and add log timing either all or nothing depending On the other two flags? Thanks, softworkz ___ 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/6] avcodec/aacps: Fix integer overflows in hybrid_synthesis()
On Sat, Aug 24, 2019 at 08:18:24PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: -822667928 + -1399761199 cannot be > represented in type 'int' > Fixes: > 15756/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AAC_FIXED_fuzzer-5645182051024896 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/aacps.c | 36 ++-- > 1 file changed, 18 insertions(+), 18 deletions(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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 4/6] avcodec/takdec: Fix integer overflow in decorrelate()
On Sun, Aug 25, 2019 at 08:41:56PM +0200, Michael Niedermayer wrote: > Fixes: signed integer overflow: -2424832 - 2145653689 cannot be represented > in type 'int' > Fixes: > 16138/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TAK_fuzzer-5643451346976768 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/takdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Never trust a computer, one day, it may think you are the virus. -- Compn 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 6/6] avcodec/alsdec: Check k from being outside what our implementation can handle
On Sun, Aug 25, 2019 at 08:41:58PM +0200, Michael Niedermayer wrote: > The specification does not seem to list what the maximum valid > value is > > Fixes: shift exponent 32 is too large for 32-bit type 'unsigned int' > Fixes: > 16268/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ALS_fuzzer-5638164544225280 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/alsdec.c | 3 +++ > 1 file changed, 3 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin 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 v1] avcodec/pngenc: fix the warning: assigning to 'Bytef *' (aka 'unsigned char *') from 'const uint8_t *
Am Di., 10. Sept. 2019 um 16:19 Uhr schrieb : > > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavcodec/pngenc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c > index d4d8dc8..e78a829 100644 > --- a/libavcodec/pngenc.c > +++ b/libavcodec/pngenc.c > @@ -274,7 +274,7 @@ static int png_write_row(AVCodecContext *avctx, const > uint8_t *data, int size) > int ret; > > s->zstream.avail_in = size; > -s->zstream.next_in = data; > +s->zstream.next_in = (uint8_t*)data; Same comment: I am not convinced that this is a good change as FFmpeg requests const next_in from libz via a compile option but in any case, the commit message should contain the actual, complete warning. Carl Eugen ___ 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/2] avcodec/mpeg12enc: Add FF_CODEC_CAP_INIT_CLEANUP
On Tue, Aug 27, 2019 at 11:21:50PM +0200, Michael Niedermayer wrote: > Fixes: Multiple memleaks > Fixes: ffmpeg-memory-leak > > Found-by: Francis Provencher > Signed-off-by: Michael Niedermayer > --- > libavcodec/mpeg12enc.c | 2 ++ > 1 file changed, 2 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many things microsoft did are stupid, but not doing something just because microsoft did it is even more stupid. If everything ms did were stupid they would be bankrupt already. 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 2/2] avcodec/htmlsubtitles: Avoid locale dependant isdigit()
On Wed, Aug 28, 2019 at 11:17:20PM +0200, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/htmlsubtitles.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Any man who breaks a law that conscience tells him is unjust and willingly accepts the penalty by staying in jail in order to arouse the conscience of the community on the injustice of the law is at that moment expressing the very highest respect for law. - Martin Luther King Jr 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 v4 2/2] avfilter: Add tonemap vaapi filter
Am Mi., 11. Sept. 2019 um 07:41 Uhr schrieb Zachary Zhou
:
>
> It supports ICL platform.
> H2H (HDR to HDR): P010 -> A2R10G10B10
> H2S (HDR to SDR): P010 -> ARGB
> +if (ctx->hdr_type == HDR_VAAPI_H2H) {
> +vpp_ctx->output_format = AV_PIX_FMT_A2R10G10B10;
I believe that even if you tell me that a conversion to planar on the
gpu is impossible (why?), a slow C conversion still makes the filter
more useful.
Carl Eugen
___
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] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU
Am Mi., 11. Sept. 2019 um 17:46 Uhr schrieb Michael Niedermayer : > > On Mon, Sep 02, 2019 at 06:24:08PM +0200, Timo Rothenpieler wrote: > > I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and > > AMF/Vulkan integration. > > > > Since there is personal information on the receipts, I won't post them here, > > but can send them to the responsible person on request easily. > > > > Packaging: > > PackSet M: 1.99€ > > Bubble-Wrap "Protection Kit": 4.99€ > > > > Shipping: > > Insured shipping via DHL (DE->US): 37.99€ > > > > Total cost: 44.97€ > > LGTM +1 Carl Eugen ___ 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] avcodec/g2meet: Check for end of input in jpg_decode_block()
tis 2019-09-10 klockan 16:16 +0200 skrev Michael Niedermayer: > On Mon, Sep 09, 2019 at 11:04:32PM +0200, Tomas Härdin wrote: > > mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer: > > > Fixes: Timeout (100sec -> 0.7sec) > > > Fixes: > > > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/g2meet.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c > > > index 19e1c130ce..731d29a5d4 100644 > > > --- a/libavcodec/g2meet.c > > > +++ b/libavcodec/g2meet.c > > > @@ -244,6 +244,9 @@ static int jpg_decode_block(JPGContext *c, > > > GetBitContext *gb, > > > const int is_chroma = !!plane; > > > const uint8_t *qmat = is_chroma ? chroma_quant : luma_quant; > > > > > > +if (get_bits_left(gb) < 1) > > > +return AVERROR_INVALIDDATA; > > > + > > > c->bdsp.clear_block(block); > > > dc = get_vlc2(gb, c->dc_vlc[is_chroma].table, 9, 3); > > > > Why doesn't the VLC stuff have EOF handling? > > Because it doesnt need it in most of the cases and the get_vlc code > is quite speed critical in some codecs. > Also it would add a error return to cases that previously never > could receive an error. That would require callers to be changed > and check for this error in some cases > > > > There's bound to be a > > metric bajillion of cases like this strewn across the codebase.. > > if that was the case, the fuzzer would have likely found more cases. That's only a matter of time. For some formats it may even be impossible to know whether there are parser issues lurking in there, even if you employ formal verification. I've said multiple times that worrying about these timeout things is mostly a waste of time since any serious user will know to put time limits on jobs. Resources would be better spent gearing the fuzzing toward finding memory corruption issues, since the harm from them is far more serious. /Tomas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avcodec/cbs_h264: Automatically free SEI payload on error
If adding an SEI message to an access unit fails, said SEI message was
not touched, so that the caller had to free any data associated with it
that might need to be freed. But given that ff_cbs_h264_add_sei_message
can simply call cbs_h264_free_sei_payload, one can easily free
the content of the SEI payload.
This fixes a memleak when inserting a user data unregistered string for
h264_metadata fails.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h264.h | 5 -
libavcodec/cbs_h2645.c | 16 +++-
2 files changed, 15 insertions(+), 6 deletions(-)
diff --git a/libavcodec/cbs_h264.h b/libavcodec/cbs_h264.h
index b39e7480c9..9f7c2a0d30 100644
--- a/libavcodec/cbs_h264.h
+++ b/libavcodec/cbs_h264.h
@@ -468,10 +468,13 @@ typedef struct CodedBitstreamH264Context {
/**
* Add an SEI message to an access unit.
+ *
+ * On success, the payload will be owned by a unit in access_unit;
+ * on failure, the content of the payload will be freed.
*/
int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
CodedBitstreamFragment *access_unit,
-const H264RawSEIPayload *payload);
+H264RawSEIPayload *payload);
/**
* Delete an SEI message from an access unit.
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 8da8421e47..2dc261f7a5 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1586,7 +1586,7 @@ const CodedBitstreamType ff_cbs_type_h265 = {
int ff_cbs_h264_add_sei_message(CodedBitstreamContext *ctx,
CodedBitstreamFragment *au,
-const H264RawSEIPayload *payload)
+H264RawSEIPayload *payload)
{
H264RawSEI *sei = NULL;
int err, i;
@@ -1608,8 +1608,10 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
*ctx,
AVBufferRef *sei_ref;
sei = av_mallocz(sizeof(*sei));
-if (!sei)
-return AVERROR(ENOMEM);
+if (!sei) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
sei->nal_unit_header.nal_unit_type = H264_NAL_SEI;
sei->nal_unit_header.nal_ref_idc = 0;
@@ -1618,7 +1620,8 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
*ctx,
&cbs_h264_free_sei, NULL, 0);
if (!sei_ref) {
av_freep(&sei);
-return AVERROR(ENOMEM);
+err = AVERROR(ENOMEM);
+goto fail;
}
for (i = 0; i < au->nb_units; i++) {
@@ -1631,13 +1634,16 @@ int ff_cbs_h264_add_sei_message(CodedBitstreamContext
*ctx,
sei, sei_ref);
av_buffer_unref(&sei_ref);
if (err < 0)
-return err;
+goto fail;
}
memcpy(&sei->payload[sei->payload_count], payload, sizeof(*payload));
++sei->payload_count;
return 0;
+fail:
+cbs_h264_free_sei_payload(payload);
+return err;
}
void ff_cbs_h264_delete_sei_message(CodedBitstreamContext *ctx,
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] avcodec/h264_metadata: Add feature to repeat x264 SEI
x264 adds a user data unregistered SEI containing its version number and
encoding parameters to the first access unit. This SEI is mostly
informative, but it can also be used by a decoder (like FFmpeg's H.264
decoder) to decide whether to use workarounds for certain bugs in old
versions of x264. This in particular affects 4:4:4 content with the 8x8dct
option set. For such files it is imperative to know the x264 version and
there were scenarios where this information would be lost or not
gathered: The former can happen when the file is split, the latter can
happen when one doesn't decode from the very beginning.
Therefore this commit adds a feature to insert the x264 SEI in every
keyframe, but only to access units that don't already contain an x264
SEI. Changing x264 SEIs (which can be produced by concatenating x264
encodes) are supported.
Fixes ticket #8126.
Signed-off-by: Andreas Rheinhardt
---
I vaguely remember that in mp4 the SEI can also be in another
out-of-band structure. But creating mp4 files with an x264 binary with
lsmash suppport only had the SEI in the first access unit, so I didn't
do anything special for this.
doc/bitstream_filters.texi | 6 +++
libavcodec/h264_metadata_bsf.c | 80 ++
2 files changed, 86 insertions(+)
diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
index 50a1679fc7..5f1eda6369 100644
--- a/doc/bitstream_filters.texi
+++ b/doc/bitstream_filters.texi
@@ -273,6 +273,12 @@ possibly separated by hyphens, and the string can be
anything.
For example, @samp{086f3693-b7b3-4f2c-9653-21492feee5b8+hello} will
insert the string ``hello'' associated with the given UUID.
+@item x264_sei
+Repeat the x264 SEI message containing the x264 version and encoding
+parameters used in every keyframe. This allows to split the file while
+retaining this information and also fixes decoding problems with
+spec-incompliant content created by old versions of x264.
+
@item delete_filler
Deletes both filler NAL units and filler SEI messages.
diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 5de74be9d6..94b6934ba3 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -77,6 +77,9 @@ typedef struct H264MetadataContext {
const char *sei_user_data;
+H264RawSEIPayload x264_sei;
+int x264_sei_status;
+
int delete_filler;
int display_orientation;
@@ -275,6 +278,26 @@ static int h264_metadata_update_sps(AVBSFContext *bsf,
return 0;
}
+static int h264_metadata_copy_x264_sei(H264RawSEIPayload *dst,
+ const H264RawSEIPayload *src)
+{
+H264RawSEIUserDataUnregistered *udu = &dst->payload.user_data_unregistered;
+AVBufferRef *data_ref;
+
+av_buffer_unref(&udu->data_ref);
+
+data_ref = av_buffer_ref(src->payload.user_data_unregistered.data_ref);
+if (!data_ref) {
+memset(dst, 0, sizeof(*dst));
+return AVERROR(ENOMEM);
+}
+
+memcpy(dst, src, sizeof(*dst));
+udu->data_ref = data_ref;
+
+return 0;
+}
+
static int h264_metadata_filter(AVBSFContext *bsf, AVPacket *pkt)
{
H264MetadataContext *ctx = bsf->priv_data;
@@ -416,6 +439,58 @@ static int h264_metadata_filter(AVBSFContext *bsf,
AVPacket *pkt)
}
}
+if (ctx->x264_sei_status) {
+int has_x264_sei = 0;
+
+for (i = 0; i < au->nb_units; i++) {
+CodedBitstreamUnit *unit = &au->units[i];
+H264RawSEI *sei;
+
+if (unit->type != H264_NAL_SEI)
+continue;
+
+sei = unit->content;
+
+for (j = 0; j < sei->payload_count; j++) {
+H264RawSEIPayload *payload = &sei->payload[j];
+H264RawSEIUserDataUnregistered *udu;
+int e, build;
+
+if (payload->payload_type !=
H264_SEI_TYPE_USER_DATA_UNREGISTERED)
+continue;
+
+udu = &payload->payload.user_data_unregistered;
+// The following is safe because udu->data always
+// contains zeroed padding at the end.
+e = sscanf(udu->data, "x264 - core %d", &build);
+if (e == 1 && build > 0) {
+err = h264_metadata_copy_x264_sei(&ctx->x264_sei,
+ payload);
+if (err < 0) {
+ctx->x264_sei_status = 1;
+goto fail;
+}
+ctx->x264_sei_status = -1;
+has_x264_sei = 1;
+}
+}
+}
+
+if (!has_x264_sei && ctx->x264_sei_status < 0
+ && pkt->flags & AV_PKT_FLAG_KEY) {
+H264RawSEIPayload payload = { 0 };
+
+err = h264_metadata_copy_x264_sei(&payload,
+ &ctx->x264_sei);
+if (err < 0)
+
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/g2meet: Check for end of input in jpg_decode_block()
On Wed, Sep 11, 2019 at 11:18:47PM +0200, Tomas Härdin wrote: > tis 2019-09-10 klockan 16:16 +0200 skrev Michael Niedermayer: > > On Mon, Sep 09, 2019 at 11:04:32PM +0200, Tomas Härdin wrote: > > > mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer: > > > > Fixes: Timeout (100sec -> 0.7sec) > > > > Fixes: > > > > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/g2meet.c | 3 +++ > > > > 1 file changed, 3 insertions(+) > > > > > > > > diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c > > > > index 19e1c130ce..731d29a5d4 100644 > > > > --- a/libavcodec/g2meet.c > > > > +++ b/libavcodec/g2meet.c > > > > @@ -244,6 +244,9 @@ static int jpg_decode_block(JPGContext *c, > > > > GetBitContext *gb, > > > > const int is_chroma = !!plane; > > > > const uint8_t *qmat = is_chroma ? chroma_quant : luma_quant; > > > > > > > > +if (get_bits_left(gb) < 1) > > > > +return AVERROR_INVALIDDATA; > > > > + > > > > c->bdsp.clear_block(block); > > > > dc = get_vlc2(gb, c->dc_vlc[is_chroma].table, 9, 3); > > > > > > Why doesn't the VLC stuff have EOF handling? > > > > Because it doesnt need it in most of the cases and the get_vlc code > > is quite speed critical in some codecs. > > Also it would add a error return to cases that previously never > > could receive an error. That would require callers to be changed > > and check for this error in some cases > > > > > > > There's bound to be a > > > metric bajillion of cases like this strewn across the codebase.. > > > > if that was the case, the fuzzer would have likely found more cases. > > That's only a matter of time. There is something wrong with this argument. Because one could say this about anything that is not static no matter if true or false. And theres no practical way to disproof it even if one waited, because maybe one just didnt wait long enough ... [...] > > I've said multiple times that worrying about these timeout things is > mostly a waste of time since any serious user will know to put time > limits on jobs. Everyone probably has timelimits on jobs but these timeouts are still a big problem. And i think this was discussed before ... I think if you just think about what timeout to use for each case A. a web browser loading image, video and audio files B. a online video encoding service C. ... I think you will find that there is no timeout that works well You just do not want 50 byte files or files with the resolution of an icon to take days to decode > Resources would be better spent gearing the fuzzing > toward finding memory corruption issues, since the harm from them is > far more serious. Then fixing the timeouts would be a priority as they hold the fuzzer up from finding other issues. Time spend waiting for a timeout is time the fuzzer cannot search for other issues Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Old school: Use the lowest level language in which you can solve the problem conveniently. New school: Use the highest level language in which the latest supercomputer can solve the problem without the user falling asleep waiting. 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] [REFUND-REQUEST] Packaging and Shipping cost AMD GPU
On date Monday 2019-09-02 18:24:08 +0200, Timo Rothenpieler wrote: > I have sent one of my spare AMD GPUs to Rodger Combs for work on AMF and > AMF/Vulkan integration. > > Since there is personal information on the receipts, I won't post them here, > but can send them to the responsible person on request easily. > > Packaging: > PackSet M: 1.99€ > Bubble-Wrap "Protection Kit": 4.99€ > > Shipping: > Insured shipping via DHL (DE->US): 37.99€ Approved by me. Please send documentation to me and to Michael so that I can send the payment request to SPI. ___ 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 v3] avcodec/tscc: fix for the backward compatibility to use const in the z_stream interface
From: Limin Wang Signed-off-by: Limin Wang --- libavcodec/tscc.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c index 6d03081..9eb17e3 100644 --- a/libavcodec/tscc.c +++ b/libavcodec/tscc.c @@ -88,7 +88,11 @@ static int decode_frame(AVCodecContext *avctx, void *data, int *got_frame, av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret); return AVERROR_UNKNOWN; } -c->zstream.next_in = buf; +#if defined(z_const) +c->zstream.next_in = (z_const uint8_t*) buf; +#else +c->zstream.next_in = (uint8_t*) buf; +#endif c->zstream.avail_in = buf_size; c->zstream.next_out = c->decomp_buf; c->zstream.avail_out = c->decomp_size; -- 2.6.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 v2] avcodec/tscc: fix the warning: assigning to 'Bytef *' (aka 'unsigned char *') from 'const uint8_t *
On Wed, Sep 11, 2019 at 01:42:38AM +0200, Carl Eugen Hoyos wrote:
> Am Do., 5. Sept. 2019 um 00:45 Uhr schrieb :
> >
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/tscc.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/tscc.c b/libavcodec/tscc.c
> > index 6d03081..b0dbef4 100644
> > --- a/libavcodec/tscc.c
> > +++ b/libavcodec/tscc.c
> > @@ -88,7 +88,7 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> > av_log(avctx, AV_LOG_ERROR, "Inflate reset error: %d\n", ret);
> > return AVERROR_UNKNOWN;
> > }
> > -c->zstream.next_in = buf;
> > +c->zstream.next_in = (uint8_t*)buf;
>
> Iirc, the warning also happens when compiling for android and the reason
> is that their zlib header is different / old and therefore doesn't mark the
> input as const (as the zlib header does on different systems here, both
> new and old). I therefore believe this line should not be changed.
>
> If it is changed, the commit message should first state was is done
> ("cast a pointer to avoid a warning") and the actual complete warning
> should be part of the commit message.
>
Thanks for the feedback, I update the patch to use z_const to keep
backward compatibility. Now the default configure will define ZLIB_CONST,
so for new version zlib, it'll use z_const, or for old system, it'll force
to avoid comiler warning. I have tested with mac pro(old zlib) and imac(new
zlib).
reference link:
https://gitlab.kitware.com/third-party/zlib/commit/5ab9f47745fe9353291b217f705086b6070575d5
> Carl Eugen
>
> (Checking Android sources seems to show that they have fixed
> this issue in more recent versions.)
> ___
> 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 v1] fate: remove fate-checkasm-opusdsp for the segment fault for mac and linux system
I'm not sure it's my system issue only? Have make distclean to build. [lmwang@vpn ffmpeg]$ make fate-checkasm-opusdsp SAMPLES=../fate-suite TESTcheckasm-opusdsp Test checkasm-opusdsp failed. Look at tests/data/fate/checkasm-opusdsp.err for details. make: *** [fate-checkasm-opusdsp] Error 139 [lmwang@vpn ffmpeg]$ cat tests/data/fate/checkasm-opusdsp.err checkasm: using random seed 685983831 ./tests/fate-run.sh: line 78: 15437 Segmentation fault $target_exec $target_path/"$@" On Thu, Sep 12, 2019 at 12:16:41AM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > tests/fate/checkasm.mak | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/tests/fate/checkasm.mak b/tests/fate/checkasm.mak > index 3893245..618bde5 100644 > --- a/tests/fate/checkasm.mak > +++ b/tests/fate/checkasm.mak > @@ -19,7 +19,6 @@ FATE_CHECKASM = fate-checkasm-aacpsdsp > \ > fate-checkasm-jpeg2000dsp \ > fate-checkasm-llviddsp \ > fate-checkasm-llviddspenc \ > -fate-checkasm-opusdsp \ > fate-checkasm-pixblockdsp \ > fate-checkasm-sbrdsp\ > fate-checkasm-synth_filter \ > -- > 2.6.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] x86/opusdps: clear the high bits from some gprs
Fixes checkasm on systems like win64. Signed-off-by: James Almer --- libavcodec/x86/opusdsp.asm | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/x86/opusdsp.asm b/libavcodec/x86/opusdsp.asm index f5d206a8b1..53a799d3d6 100644 --- a/libavcodec/x86/opusdsp.asm +++ b/libavcodec/x86/opusdsp.asm @@ -64,7 +64,7 @@ cglobal opus_deemphasis, 4, 4, 8, out, in, coeff, len add inq, mmsize add outq, mmsize -sub lenq, mmsize >> 2 +sub lend, mmsize >> 2 jg .loop %if ARCH_X86_64 == 0 @@ -80,7 +80,7 @@ cglobal opus_postfilter, 4, 4, 8, data, period, gains, len VBROADCASTSS m1, [gainsq + 4] VBROADCASTSS m2, [gainsq + 8] -lea periodq, [periodq*4 + 8] +lea periodd, [periodd*4 + 8] neg periodq movups m3, [dataq + periodq] @@ -104,7 +104,7 @@ cglobal opus_postfilter, 4, 4, 8, data, period, gains, len movaps [dataq], m5 add dataq, mmsize -sub lenq, mmsize >> 2 +sub lend, mmsize >> 2 jg .loop RET -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] x86/opusdps: clear the high bits from some gprs
On 9/11/2019 8:23 PM, James Almer wrote: > Fixes checkasm on systems like win64. > > Signed-off-by: James Almer > --- > libavcodec/x86/opusdsp.asm | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/libavcodec/x86/opusdsp.asm b/libavcodec/x86/opusdsp.asm > index f5d206a8b1..53a799d3d6 100644 > --- a/libavcodec/x86/opusdsp.asm > +++ b/libavcodec/x86/opusdsp.asm > @@ -64,7 +64,7 @@ cglobal opus_deemphasis, 4, 4, 8, out, in, coeff, len > > add inq, mmsize > add outq, mmsize > -sub lenq, mmsize >> 2 > +sub lend, mmsize >> 2 > jg .loop > > %if ARCH_X86_64 == 0 > @@ -80,7 +80,7 @@ cglobal opus_postfilter, 4, 4, 8, data, period, gains, len > VBROADCASTSS m1, [gainsq + 4] > VBROADCASTSS m2, [gainsq + 8] > > -lea periodq, [periodq*4 + 8] > +lea periodd, [periodd*4 + 8] > neg periodq > > movups m3, [dataq + periodq] > @@ -104,7 +104,7 @@ cglobal opus_postfilter, 4, 4, 8, data, period, gains, len > movaps [dataq], m5 > > add dataq, mmsize > -sub lenq, mmsize >> 2 > +sub lend, mmsize >> 2 > jg .loop > > RET Approved by Lynne on IRC, and pushed. ___ 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 v1] fate: remove fate-checkasm-opusdsp for the segment fault for mac and linux system
On 9/11/2019 7:51 PM, Limin Wang wrote: > > I'm not sure it's my system issue only? Have make distclean to build. > > [lmwang@vpn ffmpeg]$ make fate-checkasm-opusdsp SAMPLES=../fate-suite > TESTcheckasm-opusdsp > Test checkasm-opusdsp failed. Look at tests/data/fate/checkasm-opusdsp.err > for details. > make: *** [fate-checkasm-opusdsp] Error 139 > [lmwang@vpn ffmpeg]$ cat tests/data/fate/checkasm-opusdsp.err > checkasm: using random seed 685983831 > ./tests/fate-run.sh: line 78: 15437 Segmentation fault $target_exec > $target_path/"$@" I just pushed a fix. Can you try and see if it fixes the segfaults for you? ___ 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/3] lavformat: Prepare to make avio_enum_protocols const correct
Andreas Rheinhardt:
> Using avio_enum_protocols works as follows: One initializes a pointer to
> void and gives avio_enum_protocols the address of said pointer as
> argument; the pointer will be updated to point to a member of the
> url_protocols array. Now the address of the pointer can be reused for
> another call to avio_enum_protocols.
> Said array consists of constant pointers (to constant URLProtocols),
> but the user now has a pointer to non-const to it; of course it was always
> intended that the user is not allowed to modify what the pointer points
> to and this has been enforced by hiding the real type of the underlying
> object. But it is better to use a const void ** as parameter to enforce
> this. This way avio_enum_protocols can be implemented without resorting
> to casting a const away or ignoring constness as is done currently.
>
> Given that this amounts to an ABI and API break, this can only be done
> at the next major version bump; as usual, the break is currently hidden
> behind an appropriate #if.
>
> It was also necessary to change the type of a pointer used in
> avio_enum_protocols. This makes the line that is not const correct move
> as long as the old function signature is used. With the new signature,
> avio_enum_protocols will be const correct.
>
> This change will eventually force changes in their callers, e.g. to
> show_protocols in fftools/cmdutils. (This function contains all currently
> existing calls to avio_enum_protocols in FFmpeg's codebase. It hasn't
> been touched in this commit.)
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avio.h | 4
> libavformat/protocols.c | 6 +-
> libavformat/version.h | 3 +++
> 3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 9141642e75..e067ea8985 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -805,7 +805,11 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t
> **pbuffer);
> *
> * @return A static string containing the name of current protocol or NULL
> */
> +#if FF_API_NONCONST_ENUM_PROTOCOLS
> const char *avio_enum_protocols(void **opaque, int output);
> +#else
> +const char *avio_enum_protocols(const void **opaque, int output);
> +#endif
>
> /**
> * Pause and resume playing - only meaningful if using a network streaming
> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> index ad95659795..c722f9a897 100644
> --- a/libavformat/protocols.c
> +++ b/libavformat/protocols.c
> @@ -91,9 +91,13 @@ const AVClass *ff_urlcontext_child_class_next(const
> AVClass *prev)
> }
>
>
> +#if FF_API_NONCONST_ENUM_PROTOCOLS
> const char *avio_enum_protocols(void **opaque, int output)
> +#else
> +const char *avio_enum_protocols(const void **opaque, int output)
> +#endif
> {
> -const URLProtocol **p = *opaque;
> +const URLProtocol * const *p = *opaque;
>
> p = p ? p + 1 : url_protocols;
> *opaque = p;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 9814db8633..b0b9264382 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -106,6 +106,9 @@
> #ifndef FF_API_AVIOFORMAT
> #define FF_API_AVIOFORMAT (LIBAVFORMAT_VERSION_MAJOR < 59)
> #endif
> +#ifndef FF_API_NONCONST_ENUM_PROTOCOLS
> +#define FF_API_NONCONST_ENUM_PROTOCOLS (LIBAVFORMAT_VERSION_MAJOR < 59)
> +#endif
>
>
> #ifndef FF_API_R_FRAME_RATE
> I am unsure what to do next given the feedback I received: If ABI
compability is no problem, then should I simply add the const and add
an entry to doc/APIchanges? Or is a deprecation period necessary?
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] mpeg4_unpack_bframes: Avoid allocations and copies of packet structures
Andreas Rheinhardt:
> 1. Since bd90a2ec, mpeg4_unpack_bframes caches whole packets instead of
> just the pointer to the buffer and the buffer's size in order to be able
> to make use of refcounting to avoid copying of data; this unfortunately
> introduced copies of packet structures and side data (if existing),
> although the only fields that are needed are the buffer-related ones
> (data, size and buf). This can be changed without compromising the
> advantages of refcounting by storing a reference to the buffer.
>
> 2. This change also makes it easy to use only one packet throughout
> so that an allocation and free of an AVPacket structure per filtered
> packet can be saved by switching to ff_bsf_get_packet_ref.
>
> 3. Furthermore, this commit also fixes a memleak introduced in bd90a2ec:
> If a stored b_frame with side data was used for a later frame, the side
> data would leak when the input frame's properties were copied into the
> output frame.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/mpeg4_unpack_bframes_bsf.c | 77 ---
> 1 file changed, 35 insertions(+), 42 deletions(-)
>
> diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c
> b/libavcodec/mpeg4_unpack_bframes_bsf.c
> index 1daf133ce5..382070b423 100644
> --- a/libavcodec/mpeg4_unpack_bframes_bsf.c
> +++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
> @@ -25,7 +25,7 @@
> #include "mpeg4video.h"
>
> typedef struct UnpackBFramesBSFContext {
> -AVPacket *b_frame;
> +AVBufferRef *b_frame_ref;
> } UnpackBFramesBSFContext;
>
> /* determine the position of the packed marker in the userdata,
> @@ -56,32 +56,32 @@ static void scan_buffer(const uint8_t *buf, int buf_size,
> }
> }
>
> -static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *out)
> +static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, AVPacket *pkt)
> {
> UnpackBFramesBSFContext *s = ctx->priv_data;
> int pos_p = -1, nb_vop = 0, pos_vop2 = -1, ret = 0;
> -AVPacket *in;
>
> -ret = ff_bsf_get_packet(ctx, &in);
> +ret = ff_bsf_get_packet_ref(ctx, pkt);
> if (ret < 0)
> return ret;
>
> -scan_buffer(in->data, in->size, &pos_p, &nb_vop, &pos_vop2);
> +scan_buffer(pkt->data, pkt->size, &pos_p, &nb_vop, &pos_vop2);
> av_log(ctx, AV_LOG_DEBUG, "Found %d VOP startcode(s) in this packet.\n",
> nb_vop);
>
> if (pos_vop2 >= 0) {
> -if (s->b_frame->data) {
> +if (s->b_frame_ref) {
> av_log(ctx, AV_LOG_WARNING,
> "Missing one N-VOP packet, discarding one B-frame.\n");
> -av_packet_unref(s->b_frame);
> +av_buffer_unref(&s->b_frame_ref);
> }
> -/* store the packed B-frame in the BSFContext */
> -ret = av_packet_ref(s->b_frame, in);
> -if (ret < 0) {
> +/* store a reference to the packed B-frame's data in the BSFContext
> */
> +s->b_frame_ref = av_buffer_ref(pkt->buf);
> +if (!s->b_frame_ref) {
> +ret = AVERROR(ENOMEM);
> goto fail;
> }
> -s->b_frame->size -= pos_vop2;
> -s->b_frame->data += pos_vop2;
> +s->b_frame_ref->data = pkt->data + pos_vop2;
> +s->b_frame_ref->size = pkt->size - pos_vop2;
> }
>
> if (nb_vop > 2) {
> @@ -89,56 +89,49 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx,
> AVPacket *out)
> "Found %d VOP headers in one packet, only unpacking one.\n", nb_vop);
> }
>
> -if (nb_vop == 1 && s->b_frame->data) {
> -/* use frame from BSFContext */
> -av_packet_move_ref(out, s->b_frame);
> +if (nb_vop == 1 && s->b_frame_ref) {
> +AVBufferRef *tmp = pkt->buf;
>
> -/* use properties from current input packet */
> -ret = av_packet_copy_props(out, in);
> -if (ret < 0) {
> -goto fail;
> -}
> +/* make tmp accurately reflect the packet's data */
> +tmp->data = pkt->data;
> +tmp->size = pkt->size;
> +
> +/* replace data in packet with stored data */
> +pkt->buf = s->b_frame_ref;
> +pkt->data = s->b_frame_ref->data;
> +pkt->size = s->b_frame_ref->size;
> +
> +/* store reference to data into BSFContext */
> +s->b_frame_ref = tmp;
>
> -if (in->size <= MAX_NVOP_SIZE) {
> -/* N-VOP */
> +if (s->b_frame_ref->size <= MAX_NVOP_SIZE) {
> +/* N-VOP - discard stored data */
> av_log(ctx, AV_LOG_DEBUG, "Skipping N-VOP.\n");
> -} else {
> -/* copy packet into BSFContext */
> -av_packet_move_ref(s->b_frame, in);
> +av_buffer_unref(&s->b_frame_ref);
> }
> } else if (nb_vop >= 2) {
> /* use first frame of the packet */
> -av_packet_move_ref(out, in);
> -out->size = pos_vop2;
> +pkt->size = pos_vop2;
> } else if (pos_p >= 0) {
> -ret = av_packet_make_wr
Re: [FFmpeg-devel] [PATCH v1] fate: remove fate-checkasm-opusdsp for the segment fault for mac and linux system
On Wed, Sep 11, 2019 at 08:44:47PM -0300, James Almer wrote: > On 9/11/2019 7:51 PM, Limin Wang wrote: > > > > I'm not sure it's my system issue only? Have make distclean to build. > > > > [lmwang@vpn ffmpeg]$ make fate-checkasm-opusdsp SAMPLES=../fate-suite > > TESTcheckasm-opusdsp > > Test checkasm-opusdsp failed. Look at tests/data/fate/checkasm-opusdsp.err > > for details. > > make: *** [fate-checkasm-opusdsp] Error 139 > > [lmwang@vpn ffmpeg]$ cat tests/data/fate/checkasm-opusdsp.err > > checkasm: using random seed 685983831 > > ./tests/fate-run.sh: line 78: 15437 Segmentation fault $target_exec > > $target_path/"$@" > > I just pushed a fix. Can you try and see if it fixes the segfaults for you? Yes, the issue is fixed after testing. Thank for your good job. > ___ > 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] avformat/hlsenc: Fix memleak when using single_file
> 在 2019年9月11日，下午8:36，Andreas Rheinhardt 写道：
>
> This commit fixes a memleak in the hls muxer when one uses a single file
> as output. It has been forgotten to free the temporary buffers used to write
> the packets so that the size of the leaks basically amounts to the size
> of the output file. This commit adds the necessary free.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> I used av_freep instead of av_free (as happens in other places) in order
> not to leave an inconsistent state behind. There is actually no reason
> to keep the pointer to the temporary buffer; an automatic variable would
> be enough.
> Furthermore, if flush_dynbuf fails at opening a new dynamic buffer, the
> temporary buffer needs to be freed nevertheless. Yet this isn't done for
> the other two calls to flush_dynbuf.
>
> libavformat/hlsenc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index f881bb9d60..a6a3947ac7 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2365,6 +2365,7 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
>
> if (hls->flags & HLS_SINGLE_FILE) {
> ret = flush_dynbuf(vs, &range_length);
> +av_freep(&vs->temp_buffer);
> if (ret < 0) {
> return ret;
> }
> --
> 2.21.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".
LGTM
Thanks
Steven
___
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] lavu/hwcontext_qsv: update crop width/height when mapping frames
This fixes an issue where the context could be configured with one resolution, but incoming frames could have another, and our output AVFrames wouldn't match the underlying surfaces' resolution, which is usually the value that MFX code uses. In particular, this would happen when mapping from DXVA2 decoders, since DXVA2 aligns the width/height fields in its context to the required alignment for the particular codec being used, and those values are then propagated into the QSV context, rather than the crop dimensions. --- libavutil/hwcontext_qsv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c index 8f9838d7d8..fe5a705c19 100644 --- a/libavutil/hwcontext_qsv.c +++ b/libavutil/hwcontext_qsv.c @@ -1031,8 +1031,8 @@ static int qsv_map_to(AVHWFramesContext *dst_ctx, if (err) return err; -dst->width = src->width; -dst->height = src->height; +hwctx->surfaces[i].Info.CropW = dst->width = src->width; +hwctx->surfaces[i].Info.CropH = dst->height = src->height; dst->data[3] = (uint8_t*)&hwctx->surfaces[i]; return 0; -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] cmdutils: promote report level if loglevel is higher
On 09-09-2019 11:44 PM, Gyan wrote: From 9581ee61d2eaeac1cf2a0262d010e95d316228db Mon Sep 17 00:00:00 2001 From: Gyan Doshi Date: Mon, 9 Sep 2019 23:37:08 +0530 Subject: [PATCH] cmdutils: promote report level if loglevel is higher Plan to push tonight. Gyan ___ 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] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Monday, August 19, 2019 10:04
> To: FFmpeg development discussions and patches de...@ffmpeg.org>; Mark Thompson
> Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> vaMapBuffer returns multiple buffers
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Fu, Linjie
> > Sent: Tuesday, August 6, 2019 16:12
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>; Mark Thompson
> > Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet
> if
> > vaMapBuffer returns multiple buffers
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Fu, Linjie
> > > Sent: Tuesday, June 4, 2019 17:11
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Mark Thompson
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow
> packet
> > if
> > > vaMapBuffer returns multiple buffers
> > >
> > > > -Original Message-
> > > > From: Fu, Linjie
> > > > Sent: Friday, May 31, 2019 08:35
> > > > To: ffmpeg-devel@ffmpeg.org
> > > > Cc: Fu, Linjie
> > > > Subject: [PATCH,v2] lavc/vaapi_encode: grow packet if vaMapBuffer
> > > returns
> > > > multiple buffers
> > > >
> > > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > > map
> > > > buffer for each slice.
> > > >
> > > > Currently, assigning new buffer for pkt when multiple buffer returns
> > > > from vaMapBuffer will cover the previous encoded pkt data and lead
> > > > to encode issues.
> > > >
> > > > Iterate through the buf_list first to find out the total buffer size
> > > > needed for the pkt, allocate the whole pkt to avoid repeated
> reallocation
> > > > and memcpy, then copy data from each buf to pkt.
> > > >
> > > > Signed-off-by: Linjie Fu
> > > > ---
> > > > [v2]: allocate the whole pkt to avoid repeated reallocation
> > > > and memcpy
> > > >
> > > > libavcodec/vaapi_encode.c | 18 +-
> > > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > > index 2dda451..9c9e5dd 100644
> > > > --- a/libavcodec/vaapi_encode.c
> > > > +++ b/libavcodec/vaapi_encode.c
> > > > @@ -489,6 +489,8 @@ static int
> vaapi_encode_output(AVCodecContext
> > > > *avctx,
> > > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > > VACodedBufferSegment *buf_list, *buf;
> > > > VAStatus vas;
> > > > +int total_size = 0;
> > > > +uint8_t *ptr;
> > > > int err;
> > > >
> > > > err = vaapi_encode_wait(avctx, pic);
> > > > @@ -505,15 +507,21 @@ static int
> > vaapi_encode_output(AVCodecContext
> > > > *avctx,
> > > > goto fail;
> > > > }
> > > >
> > > > +for (buf = buf_list; buf; buf = buf->next)
> > > > +total_size += buf->size;
> > > > +
> > > > +err = av_new_packet(pkt, total_size);
> > > > +ptr = pkt->data;
> > > > +
> > > > +if (err < 0)
> > > > +goto fail_mapped;
> > > > +
> > > > for (buf = buf_list; buf; buf = buf->next) {
> > > > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > > "(status %08x).\n", buf->size, buf->status);
> > > >
> > > > -err = av_new_packet(pkt, buf->size);
> > > > -if (err < 0)
> > > > -goto fail_mapped;
> > > > -
> > > > -memcpy(pkt->data, buf->buf, buf->size);
> > > > +memcpy(ptr, buf->buf, buf->size);
> > > > +ptr += buf->size;
> > > > }
> > > >
> > > > if (pic->type == PICTURE_TYPE_IDR)
> > > > --
> > > > 2.7.4
> > >
> > > Ping?
> > > This can fix the encoding issue for vaapi_vp8:
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -v verbose -f
> > > rawvideo -pix_fmt yuv420p -s:v 1280x720 -i ./input_I420.yuv -vf
> > > 'format=nv12,hwupload' -c:v vp8_vaapi -rc_mode CQP -g 1 -
> global_quality
> > 14
> > > -loop_filter_sharpness 0 -loop_filter_level 0 -vframes 10 -y out.ivf
> >
> > Media driver will return 2 buffers in fact. The first buffer is
> > VACodedBufferSegment
> > buffer which includes encoded output. And the second buffer is extra
> > VACodedBufferVP9Status.
> > https://github.com/intel/media-driver/issues/624
> >
> > Fixes vp8 encoding issues for core platforms(Kaby Lake) and could be
> verified.
> > Ping?
> >
> Another ping?
> Had passed the regression patch check in https://github.com/intel-media-
> ci/ffmpeg/pull/44
>
ping x 4?
This fixes vp8/vp9 encoding.
- 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] DVB EPG decoder
> > But I'd like to see data decoder in the future to use more easily > > EPG/NIT/BAT etc tables. > > Will it be possible? With modifications if it needs to be? > > I don't see how, as it does not fit into the concept of the libav* > libraries. I feel this belongs to a separate library. A new libavdata library for data handling ? > In case of a scrambled EIT (which I have never seen myself in the wild) you'd > print this at every packet. You should either remove the warning, or check if > this is the first time (e.g. by checking if the EPG stream was just created). > You should remove this, there are tons of captures where EIT PID is > intentionally filtered, we should not spam the user. I made both of this log print on AV_LOG_TRACE level, I rather keep them here if i need them. > Not needed, as context is zero initialized. I deleted the unnecessary init. Anthony Delannoy From 4fe946f525a9409321ea2bc4f78a74857b9ee2b0 Mon Sep 17 00:00:00 2001 From: Anthony Delannoy Date: Fri, 26 Jul 2019 11:41:00 +0200 Subject: [PATCH 1/3] avformat/mpegts: add all pids & tids --- libavformat/mpegts.h | 74 1 file changed, 68 insertions(+), 6 deletions(-) diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h index 272e2be4f7..560c319ef1 100644 --- a/libavformat/mpegts.h +++ b/libavformat/mpegts.h @@ -30,17 +30,79 @@ #define TS_MAX_PACKET_SIZE 204 #define NB_PID_MAX 8192 +#define USUAL_SECTION_SIZE 1024 /* except EIT which is limited to 4096 */ #define MAX_SECTION_SIZE 4096 /* pids */ -#define PAT_PID 0x -#define SDT_PID 0x0011 +#define PAT_PID 0x /* Program Association Table */ +#define CAT_PID 0x0001 /* Conditional Access Table */ +#define TSDT_PID0x0002 /* Transport Stream Description Table */ +#define IPMP_PID0x0003 +/* PID from 0x0004 to 0x000F are reserved */ +#define NIT_PID 0x0010 /* Network Information Table */ +#define SDT_PID 0x0011 /* Service Description Table */ +#define BAT_PID SDT_PID /* Bouquet Association Table */ +#define EIT_PID 0x0012 /* Event Information Table */ +#define RST_PID 0x0013 /* Running Status Table */ +#define TDT_PID 0x0014 /* Time and Date Table */ +#define TOT_PID TDT_PID +#define NET_SYNC_PID0x0015 +#define RNT_PID 0x0016 /* RAR Notification Table */ +/* PID from 0x0017 to 0x001B are reserved for future use */ +/* PID value 0x001C allocated to link-local inband signalling shall not be + * used on any broadcast signals. It shall only be used between devices in a + * controlled environment. */ +#define LINK_LOCAL_PID 0x001C +#define MEASUREMENT_PID 0x001D +#define DIT_PID 0x001E /* Discontinuity Information Table */ +#define SIT_PID 0x001F /* Selection Information Table */ +/* PID from 0x0020 to 0x1FFA may be assigned as needed to PMT, elementary + * streams and other data tables */ +/* PID 0x1FFB is used by DigiCipher 2/ATSC MGT metadata */ +/* PID from 0x1FFC to 0x1FFE may be assigned as needed to PMT, elementary + * streams and other data tables */ +#define NULL_PID0x1FFF /* Null packet (used for fixed bandwidth padding) */ /* table ids */ -#define PAT_TID 0x00 -#define PMT_TID 0x02 -#define M4OD_TID 0x05 -#define SDT_TID 0x42 +#define PAT_TID 0x00 /* Program Association section */ +#define CAT_TID 0x01 /* Conditional Access section */ +#define PMT_TID 0x02 /* Program Map section */ +#define TSDT_TID0x03 /* Transport Stream Description section */ +/* TID from 0x04 to 0x3F are reserved */ +#define M4OD_TID0x05 +#define NIT_TID 0x40 /* Network Information section - actual network */ +#define ONIT_TID0x41 /* Network Information section - other network */ +#define SDT_TID 0x42 /* Service Description section - actual TS */ +/* TID from 0x43 to 0x45 are reserved for future use */ +#define OSDT_TID0x46 /* Service Descrition section - other TS */ +/* TID from 0x47 to 0x49 are reserved for future use */ +#define BAT_TID 0x4A /* Bouquet Association section */ +#define UNT_TID 0x4B /* Update Notification Table section */ +#define DFI_TID 0x4C /* Downloadable Font Info section */ +/* TID 0x4D is reserved for future use */ +#define EIT_TID 0x4E /* Event Information section - actual TS */ +#define OEIT_TID0x4F /* Event Information section - other TS */ +#define EITS_START_TID 0x50 /* Event Information section schedule - actual TS */ +#define EITS_END_TID0x5F /* Event Information section schedule - actual TS */ +#define OEITS_START_TID 0x60 /* Event Information section schedule - other TS */ +#define OEITS_END_TID 0x6F /* Event Information section schedule - other TS */ +#define TDT_TID 0x70 /* Time Date section */ +#define RST_TID 0x71 /* Running Status section */ +#define ST_TID 0x72 /* Stuffing section */ +#define TOT_TI
Re: [FFmpeg-devel] [PATCH V8] avcodec/libvpxenc: add ROI-based encoding support for VP8/VP9
Hi, On Tue, Sep 10, 2019 at 6:13 PM Guo, Yejun wrote: > > example command line to verify it: > ./ffmpeg -i input.stream -vf addroi=0:0:iw/3:ih/3:-0.8 -c:v libvpx -b:v 2M > tmp.webm > > Signed-off-by: Guo, Yejun > --- > libavcodec/libvpxenc.c | 188 > + > libavcodec/version.h | 2 +- > 2 files changed, 189 insertions(+), 1 deletion(-) > Thanks for updating the patch. Could you run tools/patcheck on it? I think the gcc 2.95 comment might be dated [1], so you can ignore that one. ___ 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".
