Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/tiff: do not abort decoding if strips are available

[Paul B Mahol]

On Wed, Oct 07, 2020 at 09:13:52PM -0300, James Almer wrote:
> > ffmpeg | branch: master | Paul B Mahol  > > | Fri Oct  2 12:16:49 
> > 2020 +0200| [da5b3d002862d1e105002a6dc1567e6551860896] | committer: Paul B 
> > Mahol
> >
> > avcodec/tiff: do not abort decoding if strips are available
> >
> > Even if such files are invalid, they can be decoded just fine.
> > Also stored tiles may have bigger dimensions than displayed ones,
> > so do not abort decoding in such cases.
> >
> > >/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=da5b3d002862d1e105002a6dc1567e6551860896
> > /---
> >
> >  libavcodec/tiff.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index 359d613bb3..9bf08b1900 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -929,8 +929,8 @@ static int dng_decode_jpeg(AVCodecContext *avctx, 
> > AVFrame *frame,
> >  s->avctx_mjpeg->height == h / 2 &&
> >  s->avctx_mjpeg->pix_fmt == AV_PIX_FMT_GRAY16LE) {
> >  is_single_comp = 1;
> > -} else if (s->avctx_mjpeg->width  == w &&
> > -   s->avctx_mjpeg->height == h &&
> > +} else if (s->avctx_mjpeg->width  >= w &&
> > +   s->avctx_mjpeg->height >= h &&
> > s->avctx_mjpeg->pix_fmt == (is_u16 ? AV_PIX_FMT_GRAY16 : 
> > AV_PIX_FMT_GRAY8)
> >) {
> >  is_single_comp = 0;
> > @@ -1923,8 +1923,7 @@ again:
> >  has_strip_bits = s->strippos || s->strips || s->stripoff || s->rps || 
> > s->sot || s->sstype || s->stripsize || s->stripsizesoff;
> >  
> >  if (has_tile_bits && has_strip_bits) {
> > -av_log(avctx, AV_LOG_ERROR, "Tiled TIFF is not allowed to 
> > strip\n");
> > -return AVERROR_INVALIDDATA;
> > +av_log(avctx, AV_LOG_WARNING, "Tiled TIFF is not allowed to 
> > strip\n");
> 
> Wont this reintroduce the crash fixed by 70faa9f6181?

It should not, if still, then I would need a sample to properly fix it.

> 
> 
> ___
> 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 v4 0/9] avformat: wav-s337m support + new probe_stream option

[Carl Eugen Hoyos]

Am Mo., 5. Okt. 2020 um 12:23 Uhr schrieb Nicolas Gaullier
:
>
> >> Because of the dependencies, I had to group all the patches in a serie, 
> >> but they are 3 functional parts :
> >> * patch 1 is necessary to fix dolby_e pts that will be part of the
> >> test in patch 8
> >> * patch 2,3,4,5,6,7,8 : s337m support in wav
> >> this is a rework of a precedent serie
> >> (https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=106)
> >
> >Sorry if this is not related at all but isn't dolby-e mostly found in some 
> >dvb streams?
> dolby_e is a "professional" codec, it is not used for distribution and not 
> supported by end user chips, so the most common formats are :

> - contribution: mpegts (or dvb for satt etc.) with s302m data -> s337m (this 
> could be interesting for ffmpeg to support it)

I believe we only had such samples until recently.

> - broadcast muxers: mxf, mov, gxf, lxf : in s337m, within stereo tracks or 
> most commonly sadly split into mono tracks (limited support for a simple case 
> such as mxf stereo would still be welcome). There is also a newer form with 
> AMWA-AS 11 with audio samples not encoded, but with single separated audio 
> metadata bistream in VANC : this is not strictly "dolby E", just the metadata 
> part of it (dialnorm et.), and currently dolby_e.c does not support parsing 
> these metadata.
> - wav
>
> >> * patch 9 : AVOption to disable codec auto-detect : it seems it is a
> >> general request from many users, and it is also critical here for dolby_e 
> >> as many broadcasters will still need to just pass-through dolby_e data as 
> >> they already do.
> >> Thus, the patchset 2,3,4,5,6,7 should not be applied without the last 
> >> patch 9 applied quickly behind...
> >
> >As said, this surprises me, please elaborate.
> >
> Most of the time, broadcast users just want to pass-through dolby E

What I meant was:
What did you try to pass-through (command line)?
I still believe that your new option is not necessary or at least not
needed for this
use-case (but I may of course be wrong).

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 v4 0/9] avformat: wav-s337m support + new probe_stream option

[Nicolas Gaullier]

>> - contribution: mpegts (or dvb for satt etc.) with s302m data -> s337m 
>> (this could be interesting for ffmpeg to support it)
>
>I believe we only had such samples until recently.

With things moving from SDI to IP, I think this is going to be commonplace. I 
have two s302m samples with DolbyE 20 bits, one muxed in AES 20 bits, another 
in AES 24 bits, I can share short samples.

>> >> * patch 9 : AVOption to disable codec auto-detect : it seems it is 
>> >> a general request from many users, and it is also critical here for 
>> >> dolby_e as many broadcasters will still need to just pass-through dolby_e 
>> >> data as they already do.
>> >> Thus, the patchset 2,3,4,5,6,7 should not be applied without the last 
>> >> patch 9 applied quickly behind...
>> >
>> >As said, this surprises me, please elaborate.
>> >
>> Most of the time, broadcast users just want to pass-through dolby E
>
>What I meant was:
>What did you try to pass-through (command line)?
>I still believe that your new option is not necessary or at least not needed 
>for this use-case (but I may of course be wrong).

Here is one of my personal real-life use cases : we have a big old archive with 
.mpg files that holds mp2 stereo audios plus additionnal .wav files for titles 
that provide DolbyE (those two formats were choose because they were the best 
mezzanine formats, the most supported).
Now, I typically wants to build a fresh new mxf holding the DolbyE :
ffmpeg -i input.mpg -i input_1.wav -map 0:v -map 1 -c copy output.mxf
This fails because dolby_e is not supported by the current mxf wrapper (nor the 
44.8KHz of my DolbyE @25fps).

So I have to use the new option:
ffmpeg -i input.mpg -probe_streams 0 -i input_1.wav -map 0:v -map 1 -c copy 
output.mxf

Ouput.mxf will be generated as a standard mxf with pcm audio, which is fine 
(Dolby E signalisation in mxf is possible but very rarely used in my experience 
- aside ZDF).
Note many people (I would think I am not the only one) already use scripts to 
pass-through DolbyE data with ffmpeg. We will have to update our command lines 
to insert the new -probe_stream, which is ok, but indeed this is really 
necessary otherwise some works that could be done in earlier/current ffmpeg 
will not be possible to do in future ffmpeg.

Nicolas


___
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/dpxenc: stop hardcoding color trc/primaries

[Kieran O Leary]

Woah, more amazing film preservation patches, thank you!
From my uninformed reading of the code, does this only support the
detection of Linear, 709, 240M, 170M, Gamm22?  The reason I ask is that you
frequently see Printing Density appear as well, which has a value of  '1'
in the 801/802 offset..

Best,

Kieran O'Leary,
National Library of Ireland
___
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] Allow using only the mfra info for seeking using the fragment index

[Derek Buitenhuis]

On 07/10/2020 16:44, Derek Buitenhuis wrote:
>> The mfra has enough information to enable seeking, and reading it is
>> behind an AVOption flag, so we shouldn't require that sidx information
>> also be present in order to seek using the fragment index.
>>
>> Signed-off-by: Derek Buitenhuis 
>> ---
>> This is especially important want I/O is networked, since otherwise it will
>> read essentially the entire file by seeking to every sidx in the file, which
>> for a live-style FMP4 can be a *lot*.
>>
>> Dale Curtis is CC'd, as this is probably highly relevant to him.
>>
>> Note: If a global sidx is present, that information will override the mfra, 
>> but
>> if sidx are before each moof, those will no longer be parsed in 
>> mov_read_header
>> if you set use_mfra_for, which can result in a wrong duration since mfra 
>> isn't
>> used for setting duration while sidx is.
>> ---
>>  libavformat/mov.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> Ping.

Will push late today, or tomorrow, if nobody objects.

- Derek

___
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] FATE/dnn: only run unit test when CONFIG_DNN enabled

[Peter Ross]

Signed-off-by: Peter Ross 
---
 tests/fate/dnn.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/dnn.mak b/tests/fate/dnn.mak
index 90a1bb3cac..c5e458708e 100644
--- a/tests/fate/dnn.mak
+++ b/tests/fate/dnn.mak
@@ -33,6 +33,6 @@ fate-dnn-layer-avgpool: 
$(DNNTESTSDIR)/dnn-layer-avgpool-test$(EXESUF)
 fate-dnn-layer-avgpool: CMD = run 
$(DNNTESTSDIR)/dnn-layer-avgpool-test$(EXESUF)
 fate-dnn-layer-avgpool: CMP = null
 
-FATE-yes += $(FATE_DNN)
+FATE-$(CONFIG_DNN) += $(FATE_DNN)
 
 fate-dnn: $(FATE_DNN)
-- 
2.28.0

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avformat/mspdec: Microsoft Paint (MSP) demuxer

[Peter Ross]

Signed-off-by: Peter Ross 
---
Week nine or so of lockdown...

 Changelog |  1 +
 doc/general_contents.texi |  2 +
 libavformat/Makefile  |  1 +
 libavformat/allformats.c  |  1 +
 libavformat/mspdec.c  | 95 +++
 5 files changed, 100 insertions(+)
 create mode 100644 libavformat/mspdec.c

diff --git a/Changelog b/Changelog
index 0ecda9ed52..84690791af 100644
--- a/Changelog
+++ b/Changelog
@@ -35,6 +35,7 @@ version :
 - AVS3 demuxer
 - AVS3 video decoder via libuavs3d
 - Cintel RAW decoder
+- Microsoft Paint (MSP) demuxer
 
 
 version 4.3:
diff --git a/doc/general_contents.texi b/doc/general_contents.texi
index 598e0e74da..cd3391fc8d 100644
--- a/doc/general_contents.texi
+++ b/doc/general_contents.texi
@@ -727,6 +727,8 @@ following image formats are supported:
 @item JPEG-LS  @tab X @tab X
 @item LJPEG@tab X @tab
 @tab Lossless JPEG
+@item MSP  @tab   @tab X
+@tab Microsoft Paint image
 @item PAM  @tab X @tab X
 @tab PAM is a PNM extension with alpha support.
 @item PBM  @tab X @tab X
diff --git a/libavformat/Makefile b/libavformat/Makefile
index a5e8bddb87..5cf3db630e 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -352,6 +352,7 @@ OBJS-$(CONFIG_MPEGVIDEO_DEMUXER) += mpegvideodec.o 
rawdec.o
 OBJS-$(CONFIG_MPJPEG_DEMUXER)+= mpjpegdec.o
 OBJS-$(CONFIG_MPJPEG_MUXER)  += mpjpeg.o
 OBJS-$(CONFIG_MPL2_DEMUXER)  += mpl2dec.o subtitles.o
+OBJS-$(CONFIG_MSP_DEMUXER)   += mspdec.o rawdec.o
 OBJS-$(CONFIG_MSF_DEMUXER)   += msf.o
 OBJS-$(CONFIG_MPSUB_DEMUXER) += mpsubdec.o subtitles.o
 OBJS-$(CONFIG_MSNWC_TCP_DEMUXER) += msnwc_tcp.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 96b9bc2a0c..1ba00439b9 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -282,6 +282,7 @@ extern AVInputFormat  ff_mpjpeg_demuxer;
 extern AVOutputFormat ff_mpjpeg_muxer;
 extern AVInputFormat  ff_mpl2_demuxer;
 extern AVInputFormat  ff_mpsub_demuxer;
+extern AVInputFormat  ff_msp_demuxer;
 extern AVInputFormat  ff_msf_demuxer;
 extern AVInputFormat  ff_msnwc_tcp_demuxer;
 extern AVInputFormat  ff_mtaf_demuxer;
diff --git a/libavformat/mspdec.c b/libavformat/mspdec.c
new file mode 100644
index 00..8f67a82424
--- /dev/null
+++ b/libavformat/mspdec.c
@@ -0,0 +1,95 @@
+/*
+ * Microsoft Paint (MSP) demuxer
+ * Copyright (c) 2020 Peter Ross (pr...@xvid.org)
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Microsoft Paint (MSP) demuxer
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "libavutil/imgutils.h"
+#include "avformat.h"
+#include "internal.h"
+#include "rawdec.h"
+
+static int msp_probe(const AVProbeData *p)
+{
+unsigned int i, sum;
+
+if (p->buf_size <= 32 || memcmp(p->buf, "DanM", 4))
+return 0;
+
+sum = 0;
+for (i = 0; i < 24; i += 2)
+sum ^= AV_RL16(p->buf + i);
+
+return AV_RL16(p->buf + 24) == sum ? AVPROBE_SCORE_MAX : 0;
+}
+
+static int msp_read_header(AVFormatContext *s)
+{
+FFRawDemuxerContext * cntx = s->priv_data;
+AVIOContext *pb = s->pb;
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+avio_skip(pb, 4);
+
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = s->iformat->raw_codec_id;
+st->codecpar->width  = avio_rl16(pb);
+st->codecpar->height = avio_rl16(pb);
+st->codecpar->format = AV_PIX_FMT_MONOBLACK;
+
+st->sample_aspect_ratio.num = avio_rl16(pb);
+st->sample_aspect_ratio.den = avio_rl16(pb);
+avio_skip(pb, 20);
+
+cntx->raw_packet_size = av_image_get_buffer_size(st->codecpar->format, 
st->codecpar->width, st->codecpar->height, 1);
+if (cntx->raw_packet_size < 0)
+return cntx->raw_packet_size;
+
+return 0;
+}
+
+static int msp_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+FFRawDemuxerContext *cntx = s->priv_data;
+int ret = av_get_packet(s->pb, pkt, cntx->raw_packet_size);
+if (ret < 0)
+return ret;
+pkt->stream_index = 0;
+return 0;
+}
+
+AVInputFormat ff_msp_demuxer = {
+.name = "msp",
+.

[FFmpeg-devel] [PATCH 2/3] avcodec/msp2dec: Microsoft Paint (MSP) version 2 decoder

[Peter Ross]

Signed-off-by: Peter Ross 
---
 Changelog   |   1 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/codec_desc.c |   7 +++
 libavcodec/codec_id.h   |   1 +
 libavcodec/msp2dec.c| 100 
 libavformat/mspdec.c|   8 ++--
 7 files changed, 114 insertions(+), 5 deletions(-)
 create mode 100644 libavcodec/msp2dec.c

diff --git a/Changelog b/Changelog
index 84690791af..3d81e52e86 100644
--- a/Changelog
+++ b/Changelog
@@ -36,6 +36,7 @@ version :
 - AVS3 video decoder via libuavs3d
 - Cintel RAW decoder
 - Microsoft Paint (MSP) demuxer
+- Microsoft Paint (MSP) version 2 decoder
 
 
 version 4.3:
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 2af93586dc..f307b1c7d0 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -506,6 +506,7 @@ OBJS-$(CONFIG_MSMPEG4V2_DECODER)   += msmpeg4dec.o 
msmpeg4.o msmpeg4data.o
 OBJS-$(CONFIG_MSMPEG4V2_ENCODER)   += msmpeg4enc.o msmpeg4.o msmpeg4data.o
 OBJS-$(CONFIG_MSMPEG4V3_DECODER)   += msmpeg4dec.o msmpeg4.o msmpeg4data.o
 OBJS-$(CONFIG_MSMPEG4V3_ENCODER)   += msmpeg4enc.o msmpeg4.o msmpeg4data.o
+OBJS-$(CONFIG_MSP2_DECODER)+= msp2dec.o
 OBJS-$(CONFIG_MSRLE_DECODER)   += msrle.o msrledec.o
 OBJS-$(CONFIG_MSS1_DECODER)+= mss1.o mss12.o
 OBJS-$(CONFIG_MSS2_DECODER)+= mss2.o mss12.o mss2dsp.o wmv2data.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index fb8b2ad035..486175ecc6 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -215,6 +215,7 @@ extern AVCodec ff_msmpeg4v2_decoder;
 extern AVCodec ff_msmpeg4v3_encoder;
 extern AVCodec ff_msmpeg4v3_decoder;
 extern AVCodec ff_msmpeg4_crystalhd_decoder;
+extern AVCodec ff_msp2_decoder;
 extern AVCodec ff_msrle_decoder;
 extern AVCodec ff_mss1_decoder;
 extern AVCodec ff_mss2_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 3b148883b8..40a5a9a9e5 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1419,6 +1419,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("AVS3-P2/IEEE1857.10"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_MSP2,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "msp2",
+.long_name = NULL_IF_CONFIG_SMALL("Microsoft Paint (MSP) version 2"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
 {
 .id= AV_CODEC_ID_Y41P,
 .type  = AVMEDIA_TYPE_VIDEO,
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 668c565788..6133e03bb9 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -243,6 +243,7 @@ enum AVCodecID {
 AV_CODEC_ID_AVS2,
 AV_CODEC_ID_PGX,
 AV_CODEC_ID_AVS3,
+AV_CODEC_ID_MSP2,
 
 AV_CODEC_ID_Y41P = 0x8000,
 AV_CODEC_ID_AVRP,
diff --git a/libavcodec/msp2dec.c b/libavcodec/msp2dec.c
new file mode 100644
index 00..8ea7cf3238
--- /dev/null
+++ b/libavcodec/msp2dec.c
@@ -0,0 +1,100 @@
+/*
+ * Microsoft Paint (MSP) version 2 decoder
+ * Copyright (c) 2020 Peter Ross (pr...@xvid.org)
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * Microsoft Paint (MSP) version 2 decoder
+ */
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "internal.h"
+
+static int msp2_decode_frame(AVCodecContext *avctx,
+void *data, int *got_frame,
+AVPacket *avpkt)
+{
+const uint8_t *buf = avpkt->data;
+int buf_size   = avpkt->size;
+AVFrame *p = data;
+int ret;
+unsigned int x, y, width = (avctx->width + 7) / 8;
+GetByteContext idx, gb;
+
+if (buf_size <= 2 * avctx->height)
+return AVERROR_INVALIDDATA;
+
+if ((ret = ff_get_buffer(avctx, p, 0)) < 0)
+return ret;
+
+p->pict_type = AV_PICTURE_TYPE_I;
+p->key_frame = 1;
+
+bytestream2_init(&idx, buf, 2 * avctx->height);
+buf += 2 * avctx->height;
+buf_size -= 2 * avctx->height;
+
+for (y = 0; y < avctx->height; y++) {
+unsigned int pkt_size = bytestream2_get_le16(&idx);
+if (!pkt_size) {
+memset(p->data[0] + 

[FFmpeg-devel] [PATCH 3/3] fate: add Microsoft Paint (MSP) test cases

[Peter Ross]

---
 tests/fate/video.mak| 6 ++
 tests/ref/fate/msp-msp1 | 6 ++
 tests/ref/fate/msp-msp2 | 6 ++
 3 files changed, 18 insertions(+)
 create mode 100644 tests/ref/fate/msp-msp1
 create mode 100644 tests/ref/fate/msp-msp2

diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index f2e1eb3af8..6abf413b9e 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -248,6 +248,12 @@ fate-mpeg2-ticket6024: CMD = framecrc -flags +bitexact 
-idct simple -flags +trun
 FATE_VIDEO-$(call DEMDEC, MPEGVIDEO, MPEG2VIDEO) += fate-mpeg2-ticket6677
 fate-mpeg2-ticket6677: CMD = framecrc -flags +bitexact -idct simple -vsync 
drop -i $(TARGET_SAMPLES)/mpeg2/sony-ct3.bs
 
+FATE_VIDEO-$(call DEMDEC, MSP, RAWVIDEO) += fate-msp-msp1
+fate-msp-msp1: CMD = framecrc -i $(TARGET_SAMPLES)/msp/pirate.msp -an -pix_fmt 
monob -vf scale
+
+FATE_VIDEO-$(call DEMDEC, MSP, MSP2) += fate-msp-msp2
+fate-msp-msp2: CMD = framecrc -i $(TARGET_SAMPLES)/msp/mexhat1.msp -an 
-pix_fmt monob -vf scale
+
 FATE_VIDEO-$(call DEMDEC, MV, MVC1) += fate-mv-mvc1
 fate-mv-mvc1: CMD = framecrc -i $(TARGET_SAMPLES)/mv/posture.mv -an -frames 25 
-pix_fmt rgb555le -vf scale
 
diff --git a/tests/ref/fate/msp-msp1 b/tests/ref/fate/msp-msp1
new file mode 100644
index 00..57ba8b8d6b
--- /dev/null
+++ b/tests/ref/fate/msp-msp1
@@ -0,0 +1,6 @@
+#tb 0: 1/9
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 576x720
+#sar 0: 1/1
+0,  0,  0,0,51840, 0x0f3a9a3a
diff --git a/tests/ref/fate/msp-msp2 b/tests/ref/fate/msp-msp2
new file mode 100644
index 00..ca92a17eb5
--- /dev/null
+++ b/tests/ref/fate/msp-msp2
@@ -0,0 +1,6 @@
+#tb 0: 1/9
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 721x666
+#sar 0: 0/1
+0,  0,  0,0,60606, 0xf0d66d30
-- 
2.28.0

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


pirate.msp
Description: Binary data


mexhat1.msp
Description: Binary data


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: stop hardcoding color trc/primaries

[Harry Mallon]

> On 7 Oct 2020, at 22:02, Paul B Mahol  wrote:
> 
> Signed-off-by: Paul B Mahol 
> ---
> libavcodec/dpxenc.c | 36 ++--
> tests/ref/lavf/dpx  |  2 +-
> 2 files changed, 35 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
> index a5960334d5..56840a8d33 100644
> --- a/libavcodec/dpxenc.c
> +++ b/libavcodec/dpxenc.c
> @@ -173,6 +173,38 @@ static void encode_gbrp12(AVCodecContext *avctx, const 
> AVFrame *pic, uint16_t *d
> }
> }
> 
> +static int get_dpx_pri(int color_pri)
> +{
> +switch (color_pri) {
> +case AVCOL_PRI_BT709:
> +return 6;
> +case AVCOL_PRI_SMPTE240M:
> +case AVCOL_PRI_SMPTE170M:
> +return 9;

I think perhaps this should be 8 (ITU 601 525), rather than 9 (Composite video 
SMPTE 170M), but I am not sure?

> +case AVCOL_PRI_BT470BG:
> +return 10;

Perhaps this should be 7 (ITU 601 625), rather than 10 (ITU 624-4 Composite 
video PAL), again not sure which is most widely used?

> +default:
> +return 0;
> +}
> +}

In DPX files containing colour difference information the colorspace would also 
be keyed off the value returned from this function. Perhaps it should be taken 
into account here (for files containing YCbCr)?

> +
> +static int get_dpx_trc(int color_trc)
> +{
> +switch (color_trc) {
> +case AVCOL_TRC_LINEAR:
> +return 2;
> +case AVCOL_TRC_BT709:
> +return 6;
> +case AVCOL_TRC_SMPTE240M:
> +case AVCOL_TRC_SMPTE170M:
> +return 9;

This value could be 7, 8 or 9. From my reading of the spec the best might be to 
take colour_primaries into account and do something like:

if (AVCOL_PRI_BT470BG) return 7 (ITU 601 625)
else return 8 (ITU 601 525)

> +case AVCOL_TRC_GAMMA22:
> +return 10;

10 is ITU 624-4 Composite video PAL, which says it has gamma = 2.8 
(AVCOL_TRC_GAMMA28). 
https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.624-4-1990-PDF-E.pdf

> +default:
> +return 0;
> +}
> +}
> +
> 
> [..]
> 

Best,
Harry

___
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/dpxenc: stop hardcoding color trc/primaries

[Paul B Mahol]

On Thu, Oct 08, 2020 at 12:27:02PM +0100, Harry Mallon wrote:
> 
> 
> > On 7 Oct 2020, at 22:02, Paul B Mahol  wrote:
> > 
> > Signed-off-by: Paul B Mahol 
> > ---
> > libavcodec/dpxenc.c | 36 ++--
> > tests/ref/lavf/dpx  |  2 +-
> > 2 files changed, 35 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/dpxenc.c b/libavcodec/dpxenc.c
> > index a5960334d5..56840a8d33 100644
> > --- a/libavcodec/dpxenc.c
> > +++ b/libavcodec/dpxenc.c
> > @@ -173,6 +173,38 @@ static void encode_gbrp12(AVCodecContext *avctx, const 
> > AVFrame *pic, uint16_t *d
> > }
> > }
> > 
> > +static int get_dpx_pri(int color_pri)
> > +{
> > +switch (color_pri) {
> > +case AVCOL_PRI_BT709:
> > +return 6;
> > +case AVCOL_PRI_SMPTE240M:
> > +case AVCOL_PRI_SMPTE170M:
> > +return 9;
> 
> I think perhaps this should be 8 (ITU 601 525), rather than 9 (Composite 
> video SMPTE 170M), but I am not sure?

The smpte170m is explicitly mention in specification, so make sure you use 
latest version of it.

> 
> > +case AVCOL_PRI_BT470BG:
> > +return 10;
> 
> Perhaps this should be 7 (ITU 601 625), rather than 10 (ITU 624-4 Composite 
> video PAL), again not sure which is most widely used?

see first comment.

> 
> > +default:
> > +return 0;
> > +}
> > +}
> 
> In DPX files containing colour difference information the colorspace would 
> also be keyed off the value returned from this function. Perhaps it should be 
> taken into account here (for files containing YCbCr)?

Sorry, this does not make sense, the color_prim/trc is meaningfull for both yuv 
and rgb.

> 
> > +
> > +static int get_dpx_trc(int color_trc)
> > +{
> > +switch (color_trc) {
> > +case AVCOL_TRC_LINEAR:
> > +return 2;
> > +case AVCOL_TRC_BT709:
> > +return 6;
> > +case AVCOL_TRC_SMPTE240M:
> > +case AVCOL_TRC_SMPTE170M:
> > +return 9;
> 
> This value could be 7, 8 or 9. From my reading of the spec the best might be 
> to take colour_primaries into account and do something like:
> 
> if (AVCOL_PRI_BT470BG) return 7 (ITU 601 625)
> else return 8 (ITU 601 525)
> 

see first comment.

> > +case AVCOL_TRC_GAMMA22:
> > +return 10;
> 
> 10 is ITU 624-4 Composite video PAL, which says it has gamma = 2.8 
> (AVCOL_TRC_GAMMA28). 
> https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.624-4-1990-PDF-E.pdf
> 

Hmm i will double check.

> > +default:
> > +return 0;
> > +}
> > +}
> > +
> > 
> > [..]
> > 
> 
> Best,
> Harry
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavformat/dashdec: Fix issue with dash on Windows

[Christopher Degawa]

Use xmlFree instead of av_freep

snip from libxml2:

 * xmlGetProp:
...
 * Returns the attribute value or NULL if not found.
 * It's up to the caller to free the memory with xmlFree().

According to libxml2, you are supposed to use xmlFree instead of free
on the pointer returned by it, and also using av_freep on Windows will
call _aligned_free instead of normal free, causing _aligned_free to raise
SIGTRAP and crashing ffmpeg and ffplay.

To reproduce, download a build from gyan or BtBN for windows
(also happens with some of Zeranoe's builds)

https://www.gyan.dev/ffmpeg/builds/
https://github.com/BtbN/FFmpeg-Builds

and run either

ffplay.exe 
http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd

or

ffmpeg.exe -i 
http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd
 -f null -

Signed-off-by: Christopher Degawa 
---
 libavformat/dashdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 99b9c45439..42ea74635b 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1145,7 +1145,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
*s, const char *url,
 }
 
 err:
-av_freep(&c->adaptionset_lang);
+xmlFree(c->adaptionset_lang);
 return ret;
 }
 
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/msp2dec: Microsoft Paint (MSP) version 2 decoder

[Paul B Mahol]

On Thu, Oct 08, 2020 at 10:02:32PM +1100, Peter Ross wrote:
> Signed-off-by: Peter Ross 
> ---
>  Changelog   |   1 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/codec_desc.c |   7 +++
>  libavcodec/codec_id.h   |   1 +
>  libavcodec/msp2dec.c| 100 
>  libavformat/mspdec.c|   8 ++--
>  7 files changed, 114 insertions(+), 5 deletions(-)
>  create mode 100644 libavcodec/msp2dec.c
> 
> diff --git a/Changelog b/Changelog
> index 84690791af..3d81e52e86 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -36,6 +36,7 @@ version :
>  - AVS3 video decoder via libuavs3d
>  - Cintel RAW decoder
>  - Microsoft Paint (MSP) demuxer
> +- Microsoft Paint (MSP) version 2 decoder
>  
>  

This unfortunately always assumes that pixel format is set in demuxer.

This is not correct, therefore patch is not acceptable.
___
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] avfilter/vf_minterpolate: Reject too small dimensions

[Andreas Rheinhardt]

Andreas Rheinhardt:
> The latter code relies upon the dimensions to be not too small;
> otherwise one will call av_clip() with min > max lateron which aborts
> in case ASSERT_LEVEL is >= 2 or one will get a nonsense result that may
> lead to a heap-buffer-overflow/underflow. The latter has happened in
> ticket #8248 which this commit fixes.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_minterpolate.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
> index c9ce80420d..e1fe5e32b5 100644
> --- a/libavfilter/vf_minterpolate.c
> +++ b/libavfilter/vf_minterpolate.c
> @@ -363,6 +363,11 @@ static int config_input(AVFilterLink *inlink)
>  }
>  
>  if (mi_ctx->mi_mode == MI_MODE_MCI) {
> +if (mi_ctx->b_width < 2 || mi_ctx->b_height < 2) {
> +av_log(inlink->dst, AV_LOG_ERROR, "Height or width < %d\n",
> +   2 * mi_ctx->mb_size);
> +return AVERROR(EINVAL);
> +}
>  mi_ctx->pixel_mvs = av_mallocz_array(width * height, 
> sizeof(PixelMVS));
>  mi_ctx->pixel_weights = av_mallocz_array(width * height, 
> sizeof(PixelWeights));
>  mi_ctx->pixel_refs = av_mallocz_array(width * height, 
> sizeof(PixelRefs));
> 

Will apply this patchset tomorrow unless there are objections.

- 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] libavformat/dashdec: Fix issue with dash on Windows

[James Almer]

On 10/8/2020 9:45 AM, Christopher Degawa wrote:
> Use xmlFree instead of av_freep
> 
> snip from libxml2:
> 
>  * xmlGetProp:
> ...
>  * Returns the attribute value or NULL if not found.
>  * It's up to the caller to free the memory with xmlFree().
> 
> According to libxml2, you are supposed to use xmlFree instead of free
> on the pointer returned by it, and also using av_freep on Windows will
> call _aligned_free instead of normal free, causing _aligned_free to raise
> SIGTRAP and crashing ffmpeg and ffplay.
> 
> To reproduce, download a build from gyan or BtBN for windows
> (also happens with some of Zeranoe's builds)
> 
> https://www.gyan.dev/ffmpeg/builds/
> https://github.com/BtbN/FFmpeg-Builds
> 
> and run either
> 
> ffplay.exe 
> http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd
> 
> or
> 
> ffmpeg.exe -i 
> http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd
>  -f null -
> 
> Signed-off-by: Christopher Degawa 
> ---
>  libavformat/dashdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 99b9c45439..42ea74635b 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -1145,7 +1145,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
>  }
>  
>  err:
> -av_freep(&c->adaptionset_lang);
> +xmlFree(c->adaptionset_lang);
>  return ret;
>  }

Applied, thanks!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] Add atsc_a53 dependency to h264/hevc decoders

[James Almer]

On 10/6/2020 1:09 AM, Chris Miceli wrote:
> As per ticket #8901 there is a compilation issue where there is
> an undefined reference when compiled with a minimal set of filters.
> This commit remedies that by ensuring decoders which have SEI parsers
> import the relevent caption object and hence functionality.
> ---
>  libavcodec/Makefile | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 421aec984a..d255876d5e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -96,7 +96,7 @@ OBJS-$(CONFIG_H264DSP) += h264dsp.o 
> h264idct.o
>  OBJS-$(CONFIG_H264PARSE)   += h264_parse.o h2645_parse.o 
> h264_ps.o
>  OBJS-$(CONFIG_H264PRED)+= h264pred.o
>  OBJS-$(CONFIG_H264QPEL)+= h264qpel.o
> -OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o 
> hevc_ps.o hevc_sei.o hevc_data.o
> +OBJS-$(CONFIG_HEVCPARSE)   += hevc_parse.o h2645_parse.o 
> hevc_ps.o hevc_sei.o hevc_data.o atsc_a53.o
>  OBJS-$(CONFIG_HPELDSP) += hpeldsp.o
>  OBJS-$(CONFIG_HUFFMAN) += huffman.o
>  OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
> @@ -361,7 +361,7 @@ OBJS-$(CONFIG_H263_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
>  OBJS-$(CONFIG_H264_DECODER)+= h264dec.o h264_cabac.o 
> h264_cavlc.o \
>h264_direct.o h264_loopfilter.o  \
>h264_mb.o h264_picture.o \
> -  h264_refs.o h264_sei.o \
> +  h264_refs.o h264_sei.o atsc_a53.o \
>h264_slice.o h264data.o
>  OBJS-$(CONFIG_H264_AMF_ENCODER)+= amfenc_h264.o
>  OBJS-$(CONFIG_H264_CUVID_DECODER)  += cuviddec.o
> @@ -1087,7 +1087,7 @@ OBJS-$(CONFIG_GIF_PARSER)  += gif_parser.o
>  OBJS-$(CONFIG_GSM_PARSER)  += gsm_parser.o
>  OBJS-$(CONFIG_H261_PARSER) += h261_parser.o
>  OBJS-$(CONFIG_H263_PARSER) += h263_parser.o
> -OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o h264data.o
> +OBJS-$(CONFIG_H264_PARSER) += h264_parser.o h264_sei.o 
> h264data.o atsc_a53.o
>  OBJS-$(CONFIG_HEVC_PARSER) += hevc_parser.o hevc_data.o
>  OBJS-$(CONFIG_IPU_PARSER)  += ipu_parser.o
>  OBJS-$(CONFIG_JPEG2000_PARSER) += jpeg2000_parser.o

Fixed these dependencies in configure instead. Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix issue with dash on Windows

[Andreas Rheinhardt]

Christopher Degawa:
> Use xmlFree instead of av_freep
> 
> snip from libxml2:
> 
>  * xmlGetProp:
> ...
>  * Returns the attribute value or NULL if not found.
>  * It's up to the caller to free the memory with xmlFree().
> 
> According to libxml2, you are supposed to use xmlFree instead of free
> on the pointer returned by it, and also using av_freep on Windows will
> call _aligned_free instead of normal free, causing _aligned_free to raise
> SIGTRAP and crashing ffmpeg and ffplay.
> 
> To reproduce, download a build from gyan or BtBN for windows
> (also happens with some of Zeranoe's builds)
> 
> https://www.gyan.dev/ffmpeg/builds/
> https://github.com/BtbN/FFmpeg-Builds
> 
> and run either
> 
> ffplay.exe 
> http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd
> 
> or
> 
> ffmpeg.exe -i 
> http://download.tsi.telecom-paristech.fr/gpac/DASH_CONFORMANCE/TelecomParisTech/mp4-live/mp4-live-mpd-AV-NBS.mpd
>  -f null -
> 
> Signed-off-by: Christopher Degawa 
> ---
>  libavformat/dashdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 99b9c45439..42ea74635b 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -1145,7 +1145,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
> *s, const char *url,
>  }
>  
>  err:
> -av_freep(&c->adaptionset_lang);
> +xmlFree(c->adaptionset_lang);
>  return ret;
>  }
>  
> 
You should also reset c->adaptionset_lang to NULL after freeing it. (I
remember finding this issue myself, but somehow forgot to fix it. Strange.)
(Actually, the lifetime of adaptionset_lang does not extend beyond
parse_manifest_adaptationset(), so one could even use a local variable
for it.)

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/h2645_parse: remove initial skipped_bytes_pos buffer

[James Almer]

Allocate it only when needed, and instead of giving it a fixed initial size
that's doubled on each realloc, ensure it's always big enough for the NAL
currently being parsed.

Fixes: OOM
Fixes: 
23817/clusterfuzz-testcase-minimized-ffmpeg_BSF_H264_METADATA_fuzzer-6300869057576960

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: James Almer 
---
 libavcodec/h2645_parse.c | 28 ++--
 1 file changed, 10 insertions(+), 18 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 0f98b49fbe..f5c76323c1 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -108,22 +108,20 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 dst[di++] = 0;
 si   += 3;
 
-if (nal->skipped_bytes_pos) {
-nal->skipped_bytes++;
-if (nal->skipped_bytes_pos_size < nal->skipped_bytes) {
-nal->skipped_bytes_pos_size *= 2;
-av_assert0(nal->skipped_bytes_pos_size >= 
nal->skipped_bytes);
-av_reallocp_array(&nal->skipped_bytes_pos,
+nal->skipped_bytes++;
+if (nal->skipped_bytes_pos_size < nal->skipped_bytes) {
+nal->skipped_bytes_pos_size = length / 3;
+av_assert0(nal->skipped_bytes_pos_size >= 
nal->skipped_bytes);
+av_reallocp_array(&nal->skipped_bytes_pos,
 nal->skipped_bytes_pos_size,
 sizeof(*nal->skipped_bytes_pos));
-if (!nal->skipped_bytes_pos) {
-nal->skipped_bytes_pos_size = 0;
-return AVERROR(ENOMEM);
-}
+if (!nal->skipped_bytes_pos) {
+nal->skipped_bytes_pos_size = 0;
+return AVERROR(ENOMEM);
 }
-if (nal->skipped_bytes_pos)
-nal->skipped_bytes_pos[nal->skipped_bytes-1] = di - 1;
 }
+if (nal->skipped_bytes_pos)
+nal->skipped_bytes_pos[nal->skipped_bytes-1] = di - 1;
 continue;
 } else // next start code
 goto nsc;
@@ -466,12 +464,6 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
*buf, int length,
 pkt->nals = tmp;
 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
-nal->skipped_bytes_pos = 
av_malloc_array(nal->skipped_bytes_pos_size, sizeof(*nal->skipped_bytes_pos));
-if (!nal->skipped_bytes_pos)
-return AVERROR(ENOMEM);
-
 pkt->nals_allocated = new_size;
 }
 nal = &pkt->nals[pkt->nb_nals];
-- 
2.27.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/dashdec: Reset pointer to NULL after freeing it

[Andreas Rheinhardt]

This is currently safe here, because the effective lifetime of
adaptionset_lang is parse_manifest_adaptationset() (i.e. the pointer
gets overwritten each time on entry to the function and gets freed
before exiting the function), but it is nevertheless safer to reset the
pointer.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/dashdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 42ea74635b..c28bb07f44 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1146,6 +1146,7 @@ static int parse_manifest_adaptationset(AVFormatContext 
*s, const char *url,
 
 err:
 xmlFree(c->adaptionset_lang);
+c->adaptionset_lang = NULL;
 return ret;
 }
 
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] libavformat/dashdec: Fix issue with dash on Windows

[Christopher Degawa]

> You should also reset c->adaptionset_lang to NULL after freeing it. (I
> remember finding this issue myself, but somehow forgot to fix it. Strange.)

Ah, I forgot that's what av_freep does in addition to freeing, do you
wish to make the change, or do you want me to?

> (Actually, the lifetime of adaptionset_lang does not extend beyond
> parse_manifest_adaptationset(), so one could even use a local variable
> for it.)

I do also see it being used in parse_manifest_representation, so that
would be one more place you would need to make sure to pass the local
variable, but that would save space on the struct.
___
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/libopenmpt: Don't discard const

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/libopenmpt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
index 52511aba56..b07da5f078 100644
--- a/libavformat/libopenmpt.c
+++ b/libavformat/libopenmpt.c
@@ -218,7 +218,7 @@ static int read_seek_openmpt(AVFormatContext *s, int 
stream_idx, int64_t ts, int
 return 0;
 }
 
-static int probe_openmpt_extension(AVProbeData *p)
+static int probe_openmpt_extension(const AVProbeData *p)
 {
 const char *ext;
 if (p->filename) {
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/dpxenc: stop hardcoding color trc/primaries

[Harry Mallon]

>> 
>>> 
>>> [..]
>>> +static int get_dpx_pri(int color_pri)
>>> +{
>>> +switch (color_pri) {
>>> +case AVCOL_PRI_BT709:
>>> +return 6;
>>> +case AVCOL_PRI_SMPTE240M:
>>> +case AVCOL_PRI_SMPTE170M:
>>> +return 9;
>> 
>> I think perhaps this should be 8 (ITU 601 525), rather than 9 (Composite 
>> video SMPTE 170M), but I am not sure?
> 
> The smpte170m is explicitly mention in specification, so make sure you use 
> latest version of it.

Let me try to explain myself a little better. AVCOL_PRI_SMPTE170M does not mean 
SMPTE170M, it means SMPTE170M, ITU-R BT601-6 525, ITU-R BT1358 525 or ITU-R 
BT1700 NTSC (see pixfmt.h). We will have to pick a DPX option though, which 
could either be 9 (SMPTE170M) or 8 (ITU-R 601 525). My guess is that the ITU 
601 standard would be the most obvious choice. I guess it probably doesn't 
matter as the options amount to the same thing, DPX does prefer that the two 
bytes match in V2.0 though.

> 
>> 
>>> +case AVCOL_PRI_BT470BG:
>>> +return 10;
>> 
>> Perhaps this should be 7 (ITU 601 625), rather than 10 (ITU 624-4 Composite 
>> video PAL), again not sure which is most widely used?
> 
> see first comment.

The primaries of ITU 624-4 PAL and ITU 601 625 are the same here, so choosing 
between 7 and 10 is difficult. I wonder whether the ITU 601 option is the least 
surprising. BT470BG is not explicitly mentioned in the DPX specification.

> 
>> 
>>> +default:
>>> +return 0;
>>> +}
>>> +}
>> 
>> In DPX files containing colour difference information the colorspace would 
>> also be keyed off the value returned from this function. Perhaps it should 
>> be taken into account here (for files containing YCbCr)?
> 
> Sorry, this does not make sense, the color_prim/trc is meaningfull for both 
> yuv and rgb.

In FFMPEG we have 3 things AVColorPrimaries, AVColorTransferCharacteristic and 
AVColorSpace. In DPX we have only two; Transfer Characteristic and Colorimetric 
Specification. If we were to read these values when decoding dpx files we would 
choose what to set for AVColorSpace (the YCbCr matrix) based on the 
Colorimetric Specification. I think that should mean that we should take the 
AVColorSpace and the AVColorPrimaries into consideration when choosing what to 
put in this byte, when writing YUV DPX files.

> 
>> 
>>> +
>>> +static int get_dpx_trc(int color_trc)
>>> +{
>>> +switch (color_trc) {
>>> +case AVCOL_TRC_LINEAR:
>>> +return 2;
>>> +case AVCOL_TRC_BT709:
>>> +return 6;
>>> +case AVCOL_TRC_SMPTE240M:
>>> +case AVCOL_TRC_SMPTE170M:
>>> +return 9;
>> 
>> This value could be 7, 8 or 9. From my reading of the spec the best might be 
>> to take colour_primaries into account and do something like:
>> 
>> if (AVCOL_PRI_BT470BG) return 7 (ITU 601 625)
>> else return 8 (ITU 601 525)
>> 
> 
> see first comment.

See my first comment

> 
>>> +case AVCOL_TRC_GAMMA22:
>>> +return 10;
>> 
>> 10 is ITU 624-4 Composite video PAL, which says it has gamma = 2.8 
>> (AVCOL_TRC_GAMMA28). 
>> https://www.itu.int/dms_pub/itu-r/opb/rep/R-REP-BT.624-4-1990-PDF-E.pdf
>> 
> 
> Hmm i will double check.
> 
>>> +default:
>>> +return 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] libavformat/dashdec: Fix issue with dash on Windows

[Andreas Rheinhardt]

Christopher Degawa:
>> You should also reset c->adaptionset_lang to NULL after freeing it. (I
>> remember finding this issue myself, but somehow forgot to fix it. Strange.)
> 
> Ah, I forgot that's what av_freep does in addition to freeing, do you
> wish to make the change, or do you want me to?
> 
I already made a patch and sent it to the ML a few minutes ago, but
somehow it is still stuck. I'll just apply it, it's trivial anyway.

>> (Actually, the lifetime of adaptionset_lang does not extend beyond
>> parse_manifest_adaptationset(), so one could even use a local variable
>> for it.)
> 
> I do also see it being used in parse_manifest_representation, so that
> would be one more place you would need to make sure to pass the local
> variable, but that would save space on the struct.

Yeah, but parse_manifest_representation() is only called from
parse_manifest_adaptationset(), so it is possible.
(This is also the reason why I forgot to fix it: Initially I believed
there was a memleak when adaptionset_lang is simply overwritten without
checking whether it is not NULL, but then I saw that it actually always
is NULL at that point and so I didn't change anything, despite noticing
that it should use xmlFree().)

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] libavcodec/adts_header: add frame_length field and avpriv function to parse AAC ADTS header

[Nachiket Tarate]

These will be used by HLS demuxer in case of SAMPLE-AES encryption.

Signed-off-by: Nachiket Tarate 
---
 libavcodec/adts_header.c |  1 +
 libavcodec/adts_header.h |  1 +
 libavcodec/adts_parser.c | 29 -
 libavcodec/adts_parser.h |  4 
 4 files changed, 34 insertions(+), 1 deletion(-)

diff --git a/libavcodec/adts_header.c b/libavcodec/adts_header.c
index 0889820f8a..c6680b0fc8 100644
--- a/libavcodec/adts_header.c
+++ b/libavcodec/adts_header.c
@@ -66,6 +66,7 @@ int ff_adts_header_parse(GetBitContext *gbc, 
AACADTSHeaderInfo *hdr)
 hdr->sample_rate= avpriv_mpeg4audio_sample_rates[sr];
 hdr->samples= (rdb + 1) * 1024;
 hdr->bit_rate   = size * 8 * hdr->sample_rate / hdr->samples;
+hdr->frame_length  = size;
 
 return size;
 }
diff --git a/libavcodec/adts_header.h b/libavcodec/adts_header.h
index f615f6a9f9..c362ce46a5 100644
--- a/libavcodec/adts_header.h
+++ b/libavcodec/adts_header.h
@@ -34,6 +34,7 @@ typedef struct AACADTSHeaderInfo {
 uint8_t  sampling_index;
 uint8_t  chan_config;
 uint8_t  num_aac_frames;
+uint32_t frame_length;
 } AACADTSHeaderInfo;
 
 /**
diff --git a/libavcodec/adts_parser.c b/libavcodec/adts_parser.c
index 5c9f8ff6f2..7513b64181 100644
--- a/libavcodec/adts_parser.c
+++ b/libavcodec/adts_parser.c
@@ -21,7 +21,6 @@
 #include 
 #include 
 
-#include "adts_header.h"
 #include "adts_parser.h"
 
 int av_adts_header_parse(const uint8_t *buf, uint32_t *samples, uint8_t 
*frames)
@@ -42,3 +41,31 @@ int av_adts_header_parse(const uint8_t *buf, uint32_t 
*samples, uint8_t *frames)
 return AVERROR(ENOSYS);
 #endif
 }
+
+int avpriv_adts_header_parse (AACADTSHeaderInfo **phdr, const uint8_t *buf, 
size_t size)
+{
+#if CONFIG_ADTS_HEADER
+int ret = 0;
+GetBitContext gb;
+
+if (size < AV_AAC_ADTS_HEADER_SIZE)
+return AVERROR_INVALIDDATA;
+
+if (!*phdr)
+*phdr = av_mallocz(sizeof(AACADTSHeaderInfo));
+if (!*phdr)
+return AVERROR(ENOMEM);
+
+ret = init_get_bits8(&gb, buf, AV_AAC_ADTS_HEADER_SIZE);
+if (ret < 0)
+return ret;
+
+ret = ff_adts_header_parse(&gb, *phdr);
+if (ret < 0)
+return ret;
+
+return 0;
+#else
+return AVERROR(ENOSYS);
+#endif
+}
diff --git a/libavcodec/adts_parser.h b/libavcodec/adts_parser.h
index f85becd131..faa6e47426 100644
--- a/libavcodec/adts_parser.h
+++ b/libavcodec/adts_parser.h
@@ -22,6 +22,8 @@
 #include 
 #include 
 
+#include "adts_header.h"
+
 #define AV_AAC_ADTS_HEADER_SIZE 7
 
 /**
@@ -34,4 +36,6 @@
 int av_adts_header_parse(const uint8_t *buf, uint32_t *samples,
  uint8_t *frames);
 
+int avpriv_adts_header_parse (AACADTSHeaderInfo **phdr, const uint8_t *buf, 
size_t size);
+
 #endif /* AVCODEC_ADTS_PARSER_H */
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/isom: add support for RAW ASC Bayer BGGR in mov

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/raw.c   | 1 +
 libavformat/isom.c | 2 ++
 2 files changed, 3 insertions(+)

diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index b6fb91c1c6..079d5c5d10 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -246,6 +246,7 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
 { AV_PIX_FMT_GRAY16BE,MKTAG('b', '1', '6', 'g') },
 { AV_PIX_FMT_RGB48BE, MKTAG('b', '4', '8', 'r') },
 { AV_PIX_FMT_RGBA64BE,MKTAG('b', '6', '4', 'a') },
+{ AV_PIX_FMT_BAYER_RGGB16BE, MKTAG('B', 'G', 'G', 'R') },
 
 /* vlc */
 { AV_PIX_FMT_YUV410P, MKTAG('I', '4', '1', '0') },
diff --git a/libavformat/isom.c b/libavformat/isom.c
index 019175d814..d1ef6e3407 100644
--- a/libavformat/isom.c
+++ b/libavformat/isom.c
@@ -316,6 +316,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
 
 { AV_CODEC_ID_NOTCHLC, MKTAG('n', 'c', 'l', 'c') },
 
+{ AV_CODEC_ID_RAWVIDEO, MKTAG('B', 'G', 'G', 'R') }, /* ASC Bayer BGGR */
+
 { AV_CODEC_ID_NONE, 0 },
 };
 
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Use correct number of codes for VLC tables

[Andreas Rheinhardt]

Commit 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 made
ff_mjpeg_decode_dht() call build_vlc() with a wrong (too hight)
number of codes. The reason it worked is that the lengths of the extraneous
entries is initialized to zero and ff_init_vlc_sparse() ignores codes
with a length of zero. But using a too high number of codes was
nevertheless bad, because a) the assert in build_vlc() could have been
triggered (namely if the real amount of codes is 256) and b) the loop in
build_vlc() uses initialized data (leading to Valgrind errors [1]).
Furthermore, the old code spend CPU cycles in said loop although the
result won't be used anyway.

[1]: 
http://fate.ffmpeg.org/report.cgi?slot=x86_64-archlinux-gcc-valgrind&time=20201008025137

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mjpegdec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 44bbae010c..4128c47303 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -78,7 +78,7 @@ static int build_vlc(VLC *vlc, const uint8_t *bits_table,
 
 build_huffman_codes(huff_size, huff_code, bits_table);
 
-for (i = 0; i < 256; i++) {
+for (i = 0; i < nb_codes; i++) {
 huff_sym[i] = val_table[i] + 16 * is_ac;
 
 if (is_ac && !val_table[i])
@@ -295,15 +295,15 @@ int ff_mjpeg_decode_dht(MJpegDecodeContext *s)
 /* build VLC and flush previous vlc if present */
 ff_free_vlc(&s->vlcs[class][index]);
 av_log(s->avctx, AV_LOG_DEBUG, "class=%d index=%d nb_codes=%d\n",
-   class, index, n + 1);
+   class, index, n);
 if ((ret = build_vlc(&s->vlcs[class][index], bits_table, val_table,
- n + 1, 0, class > 0)) < 0)
+ n, 0, class > 0)) < 0)
 return ret;
 
 if (class > 0) {
 ff_free_vlc(&s->vlcs[2][index]);
 if ((ret = build_vlc(&s->vlcs[2][index], bits_table, val_table,
- n + 1, 0, 0)) < 0)
+ n, 0, 0)) < 0)
 return ret;
 }
 
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: Use correct number of codes when init default VLCs

[Andreas Rheinhardt]

Commit bbc0d0c1fe2b7ecdc4367295594f084f85ad22f5 made the mjpeg decoder
use default Huffman tables when none are given, yet when initializing
the default Huffman tables, it did not use the correct number of entries
of the arrays used to initialize the tables, but instead it used the
biggest entry + 1 (as if it were a continuous array 0..biggest entry).
This worked because the ff_init_vlc_sparse() (and its predecessors)
always skipped entries with a length of zero and the length of the
corresponding elements was always initialized to zero with only the
sizes of the actually existing elements being set to a size > 0 lateron.

Yet since commit 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 this is no
longer so, as build_vlc() actually read the array containing the values
itself. This implies that the wrong length now leads to a read beyond
the end of the given array; this could lead to crashs (but usually
doesn't); it is detectable by ASAN* and this commit fixes it.

*: AddressSanitizer: global-buffer-overflow on address xy
...
xy is located 0 bytes to the right of global variable 
'avpriv_mjpeg_val_ac_luminance'

Signed-off-by: Andreas Rheinhardt 
---
Hard to believe that this wrong number has not been found earlier.
The code in question has been touched by about a dozen commits.

 libavcodec/mjpegdec.c | 15 +++
 1 file changed, 7 insertions(+), 8 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 4128c47303..0a5ef110d1 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -96,27 +96,26 @@ static int init_default_huffman_tables(MJpegDecodeContext 
*s)
 int index;
 const uint8_t *bits;
 const uint8_t *values;
-int codes;
 int length;
 } ht[] = {
 { 0, 0, avpriv_mjpeg_bits_dc_luminance,
-avpriv_mjpeg_val_dc, 12, 12 },
+avpriv_mjpeg_val_dc, 12 },
 { 0, 1, avpriv_mjpeg_bits_dc_chrominance,
-avpriv_mjpeg_val_dc, 12, 12 },
+avpriv_mjpeg_val_dc, 12 },
 { 1, 0, avpriv_mjpeg_bits_ac_luminance,
-avpriv_mjpeg_val_ac_luminance,   251, 162 },
+avpriv_mjpeg_val_ac_luminance,   162 },
 { 1, 1, avpriv_mjpeg_bits_ac_chrominance,
-avpriv_mjpeg_val_ac_chrominance, 251, 162 },
+avpriv_mjpeg_val_ac_chrominance, 162 },
 { 2, 0, avpriv_mjpeg_bits_ac_luminance,
-avpriv_mjpeg_val_ac_luminance,   251, 162 },
+avpriv_mjpeg_val_ac_luminance,   162 },
 { 2, 1, avpriv_mjpeg_bits_ac_chrominance,
-avpriv_mjpeg_val_ac_chrominance, 251, 162 },
+avpriv_mjpeg_val_ac_chrominance, 162 },
 };
 int i, ret;
 
 for (i = 0; i < FF_ARRAY_ELEMS(ht); i++) {
 ret = build_vlc(&s->vlcs[ht[i].class][ht[i].index],
-ht[i].bits, ht[i].values, ht[i].codes,
+ht[i].bits, ht[i].values, ht[i].length,
 0, ht[i].class == 1);
 if (ret < 0)
 return ret;
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mjpegdec: Use correct number of codes when init default VLCs

[Paul B Mahol]

On Thu, Oct 08, 2020 at 07:57:56PM +0200, Andreas Rheinhardt wrote:
> Commit bbc0d0c1fe2b7ecdc4367295594f084f85ad22f5 made the mjpeg decoder
> use default Huffman tables when none are given, yet when initializing
> the default Huffman tables, it did not use the correct number of entries
> of the arrays used to initialize the tables, but instead it used the
> biggest entry + 1 (as if it were a continuous array 0..biggest entry).
> This worked because the ff_init_vlc_sparse() (and its predecessors)
> always skipped entries with a length of zero and the length of the
> corresponding elements was always initialized to zero with only the
> sizes of the actually existing elements being set to a size > 0 lateron.
> 
> Yet since commit 1249698e1b424cff8e77e6a83cfdbc9d11e01aa7 this is no
> longer so, as build_vlc() actually read the array containing the values
> itself. This implies that the wrong length now leads to a read beyond
> the end of the given array; this could lead to crashs (but usually
> doesn't); it is detectable by ASAN* and this commit fixes it.
> 
> *: AddressSanitizer: global-buffer-overflow on address xy
> ...
> xy is located 0 bytes to the right of global variable 
> 'avpriv_mjpeg_val_ac_luminance'
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Hard to believe that this wrong number has not been found earlier.
> The code in question has been touched by about a dozen commits.
> 

Patchset LGTM
___
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/libopenmpt: Don't discard const

[Andreas Rheinhardt]

Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/libopenmpt.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/libopenmpt.c b/libavformat/libopenmpt.c
> index 52511aba56..b07da5f078 100644
> --- a/libavformat/libopenmpt.c
> +++ b/libavformat/libopenmpt.c
> @@ -218,7 +218,7 @@ static int read_seek_openmpt(AVFormatContext *s, int 
> stream_idx, int64_t ts, int
>  return 0;
>  }
>  
> -static int probe_openmpt_extension(AVProbeData *p)
> +static int probe_openmpt_extension(const AVProbeData *p)
>  {
>  const char *ext;
>  if (p->filename) {
> 

Will apply.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] avcodec/mjpegdec: Remove use_static from build_vlc()

[Andreas Rheinhardt]

It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
been removed in 595324e143b57a52e2329eb47b84395c70f93087.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mjpegdec.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 0a5ef110d1..a56afc0fb7 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -67,7 +67,7 @@ static void build_huffman_codes(uint8_t *huff_size, uint16_t 
*huff_code,
 
 static int build_vlc(VLC *vlc, const uint8_t *bits_table,
  const uint8_t *val_table, int nb_codes,
- int use_static, int is_ac)
+ int is_ac)
 {
 uint8_t huff_size[256] = { 0 };
 uint16_t huff_code[256];
@@ -86,7 +86,7 @@ static int build_vlc(VLC *vlc, const uint8_t *bits_table,
 }
 
 return ff_init_vlc_sparse(vlc, 9, nb_codes, huff_size, 1, 1,
-  huff_code, 2, 2, huff_sym, 2, 2, use_static);
+  huff_code, 2, 2, huff_sym, 2, 2, 0);
 }
 
 static int init_default_huffman_tables(MJpegDecodeContext *s)
@@ -116,7 +116,7 @@ static int init_default_huffman_tables(MJpegDecodeContext 
*s)
 for (i = 0; i < FF_ARRAY_ELEMS(ht); i++) {
 ret = build_vlc(&s->vlcs[ht[i].class][ht[i].index],
 ht[i].bits, ht[i].values, ht[i].length,
-0, ht[i].class == 1);
+ht[i].class == 1);
 if (ret < 0)
 return ret;
 
@@ -296,13 +296,13 @@ int ff_mjpeg_decode_dht(MJpegDecodeContext *s)
 av_log(s->avctx, AV_LOG_DEBUG, "class=%d index=%d nb_codes=%d\n",
class, index, n);
 if ((ret = build_vlc(&s->vlcs[class][index], bits_table, val_table,
- n, 0, class > 0)) < 0)
+ n, class > 0)) < 0)
 return ret;
 
 if (class > 0) {
 ff_free_vlc(&s->vlcs[2][index]);
 if ((ret = build_vlc(&s->vlcs[2][index], bits_table, val_table,
- n, 0, 0)) < 0)
+ n, 0)) < 0)
 return ret;
 }
 
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] avcodec/mjpegdec: Remove redundant initialization

[Andreas Rheinhardt]

Now that the correct number of codes is used, it is no longer necessary
to initialize the lengths of the codes at all any more as the length of
the actually used codes is set later anyway.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mjpegdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a56afc0fb7..147dd819e5 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -69,7 +69,7 @@ static int build_vlc(VLC *vlc, const uint8_t *bits_table,
  const uint8_t *val_table, int nb_codes,
  int is_ac)
 {
-uint8_t huff_size[256] = { 0 };
+uint8_t huff_size[256];
 uint16_t huff_code[256];
 uint16_t huff_sym[256];
 int i;
-- 
2.25.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 3/4] avcodec/magicyuvenc: Avoid sorting Huffman table unnecessarily

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/magicyuvenc.c | 41 ++--
 1 file changed, 14 insertions(+), 27 deletions(-)

diff --git a/libavcodec/magicyuvenc.c b/libavcodec/magicyuvenc.c
index 0bd6b8ef6a..1b8bb53114 100644
--- a/libavcodec/magicyuvenc.c
+++ b/libavcodec/magicyuvenc.c
@@ -40,7 +40,6 @@ typedef enum Prediction {
 } Prediction;
 
 typedef struct HuffEntry {
-uint8_t  sym;
 uint8_t  len;
 uint32_t code;
 } HuffEntry;
@@ -245,32 +244,18 @@ static av_cold int magy_encode_init(AVCodecContext *avctx)
 return 0;
 }
 
-static int magy_huff_cmp_len(const void *a, const void *b)
+static void calculate_codes(HuffEntry *he, uint16_t codes_count[33])
 {
-const HuffEntry *aa = a, *bb = b;
-return (aa->len - bb->len) * 256 + aa->sym - bb->sym;
-}
-
-static int huff_cmp_sym(const void *a, const void *b)
-{
-const HuffEntry *aa = a, *bb = b;
-return bb->sym - aa->sym;
-}
-
-static void calculate_codes(HuffEntry *he)
-{
-uint32_t code;
-int i;
-
-AV_QSORT(he, 256, HuffEntry, magy_huff_cmp_len);
-
-code = 1;
-for (i = 255; i >= 0; i--) {
-he[i].code  = code >> (32 - he[i].len);
-code   += 0x8000u >> (he[i].len - 1);
+for (unsigned i = 32, nb_codes = 0; i > 0; i--) {
+uint16_t curr = codes_count[i];   // # of leafs of length i
+codes_count[i] = nb_codes / 2;// # of non-leaf nodes on level i
+nb_codes = codes_count[i] + curr; // # of nodes on level i
 }
 
-AV_QSORT(he, 256, HuffEntry, huff_cmp_sym);
+for (unsigned i = 0; i < 255; i++) {
+he[i].code = codes_count[he[i].len];
+codes_count[he[i].len]++;
+}
 }
 
 static void count_usage(uint8_t *src, int width,
@@ -301,6 +286,7 @@ static int compare_by_prob(const void *a, const void *b)
 }
 
 static void magy_huffman_compute_bits(PTable *prob_table, HuffEntry *distincts,
+  uint16_t codes_counts[33],
   int size, int max_length)
 {
 PackageMergerList list_a, list_b, *to = &list_a, *from = &list_b, *temp;
@@ -356,8 +342,8 @@ static void magy_huffman_compute_bits(PTable *prob_table, 
HuffEntry *distincts,
 }
 
 for (i = 0; i < size; i++) {
-distincts[i].sym = i;
 distincts[i].len = nbits[i];
+codes_counts[nbits[i]]++;
 }
 }
 
@@ -366,6 +352,7 @@ static int encode_table(AVCodecContext *avctx, uint8_t *dst,
 PutBitContext *pb, HuffEntry *he)
 {
 PTable counts[256] = { {0} };
+uint16_t codes_counts[33] = { 0 };
 int i;
 
 count_usage(dst, width, height, counts);
@@ -375,9 +362,9 @@ static int encode_table(AVCodecContext *avctx, uint8_t *dst,
 counts[i].value = 255 - i;
 }
 
-magy_huffman_compute_bits(counts, he, 256, 12);
+magy_huffman_compute_bits(counts, he, codes_counts, 256, 12);
 
-calculate_codes(he);
+calculate_codes(he, codes_counts);
 
 for (i = 0; i < 256; i++) {
 put_bits(pb, 1, 0);
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/4] avcodec/magicyuvenc: Use more correct cast in compare function

[Andreas Rheinhardt]

There is no need to cast const away (even if it was harmless) and to
copy the object at all.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/magicyuvenc.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/magicyuvenc.c b/libavcodec/magicyuvenc.c
index 1b8bb53114..440b3514c3 100644
--- a/libavcodec/magicyuvenc.c
+++ b/libavcodec/magicyuvenc.c
@@ -280,9 +280,9 @@ typedef struct PackageMergerList {
 
 static int compare_by_prob(const void *a, const void *b)
 {
-PTable a_val = *(PTable *)a;
-PTable b_val = *(PTable *)b;
-return a_val.prob - b_val.prob;
+const PTable *a2 = a;
+const PTable *b2 = b;
+return a2->prob - b2->prob;
 }
 
 static void magy_huffman_compute_bits(PTable *prob_table, HuffEntry *distincts,
-- 
2.25.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 3/3] avformat/flvdec: Check for EOF in amf_parse_object()

[Michael Niedermayer]

Fixes: Timeout (too long -> 1ms)
Fixes: 
26108/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5653887668977664

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavformat/flvdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index d480d0bc67..e6786e8b38 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -493,8 +493,11 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 double num_val;
 amf_date date;
 
+
 num_val  = 0;
 ioc  = s->pb;
+if (avio_feof(ioc))
+return AVERROR_EOF;
 amf_type = avio_r8(ioc);
 
 switch (amf_type) {
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avcodec/h264_slice: fix undefined integer overflow with POC in error concealment

[Michael Niedermayer]

Alternatively the POC could be changed to 64bit. the large values seem to be 
within what is allowed.

Fixes: signed integer overflow: 2147483646 + 2 cannot be represented in type 
'int'
Fixes: 
26076/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5711127201447936

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264_slice.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 74575bccd4..fa7a639053 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1606,7 +1606,7 @@ static int h264_field_start(H264Context *h, const 
H264SliceContext *sl,
   prev->f->format,
   prev->f->width,
   prev->f->height);
-h->short_ref[0]->poc = prev->poc + 2;
+h->short_ref[0]->poc = prev->poc + 2U;
 } else if (!h->frame_recovered && !h->avctx->hwaccel)
 ff_color_frame(h->short_ref[0]->f, c);
 h->short_ref[0]->frame_num = h->poc.prev_frame_num;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] avcodec/pgxdec: Check depth more completely

[Michael Niedermayer]

Fixes: shift exponent -1 is negative
Fixes: 
26107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-5378790047612928

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/pgxdec.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
index 150f8bbf66..5c735894ab 100644
--- a/libavcodec/pgxdec.c
+++ b/libavcodec/pgxdec.c
@@ -133,14 +133,14 @@ static int pgx_decode_frame(AVCodecContext *avctx, void 
*data,
 if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
 return ret;
 
-if (depth <= 8) {
+if (depth > 0 && depth <= 8) {
 avctx->pix_fmt = AV_PIX_FMT_GRAY8;
 bpp = 8;
-} else if (depth <= 16) {
+} else if (depth > 0 && depth <= 16) {
 avctx->pix_fmt = AV_PIX_FMT_GRAY16;
 bpp = 16;
 } else {
-av_log(avctx, AV_LOG_ERROR, "Maximum depth of 16 bits supported.\n");
+av_log(avctx, AV_LOG_ERROR, "depth %d is invalid or unsupported.\n", 
depth);
 return AVERROR_PATCHWELCOME;
 }
 if (bytestream2_get_bytes_left(&g) < width * height * (bpp >> 3))
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/apedec: use ff_clz() instead of while loop

[Michael Niedermayer]

On Wed, Oct 07, 2020 at 05:12:47PM +0200, Paul B Mahol wrote:
> On Wed, Oct 07, 2020 at 04:45:56PM +0200, Michael Niedermayer wrote:
> > On Tue, Oct 06, 2020 at 12:08:27PM +0200, Anton Khirnov wrote:
> > > Quoting Paul B Mahol (2020-10-06 10:19:13)
> > > > On Tue, Oct 06, 2020 at 10:08:58AM +0200, Anton Khirnov wrote:
> > > > > Quoting Paul B Mahol (2020-10-06 02:17:14)
> > > > > > Signed-off-by: Paul B Mahol 
> > > > > > ---
> > > > > >  libavcodec/apedec.c | 10 +++---
> > > > > >  1 file changed, 3 insertions(+), 7 deletions(-)
> > > > > > 
> > > > > > diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
> > > > > > index 8fe7b5ee86..ea36247eb9 100644
> > > > > > --- a/libavcodec/apedec.c
> > > > > > +++ b/libavcodec/apedec.c
> > > > > > @@ -575,14 +575,10 @@ static inline int 
> > > > > > ape_decode_value_3990(APEContext *ctx, APERice *rice)
> > > > > >  base = range_decode_culfreq(ctx, pivot);
> > > > > >  range_decode_update(ctx, 1, base);
> > > > > >  } else {
> > > > > > -int base_hi = pivot, base_lo;
> > > > > > -int bbits = 0;
> > > > > > +int base_hi, base_lo;
> > > > > > +int bbits = 16 - ff_clz(pivot);
> > > > > 
> > > > > This assumes unsigned is always 32bit, no?
> > > > 
> > > > ksum is 32 bit, from which pivot is derived.
> > > > 
> > > > Should I use explicitly uint32_t type instead?
> > > > Where is unsigned not 32bit?
> > > 
> > > I don't think uint32_t would help, as ff_clz() can expand to a compiler
> > > builtin.
> > > 
> > > What I'm concerned about is the unstated assumption about
> > > sizeof(int/unsigned) == 4 spreading through the codebase. It's already
> > > present in plenty of places, so I certainly don't intend to block your
> > > patch over this. But we should consider explitly documenting this, and
> > > maybe testing in configure.
> > 
> > At least in code i wrote and write i consider it a bug if it would
> > assume sizeof(int/unsigned) == 4
> > 
> > We also could add a ILP64 fate target, that way we would better understand
> > how much really assumes 32bit int
> 
> So you basically saying we should not use ff_clz() at all because of this.
> Then we should remove it from our code.

i guess thats the conclusion yes or
the hardcoded 32 that is used by code calling it would need to be changed

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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 9/9] avformat/aviobuf: increase default read buffer size to 2*max_buffer_size for streamed data

[Marton Balint]

On Tue, 6 Oct 2020, Marton Balint wrote:




On Wed, 30 Sep 2020, Paul B Mahol wrote:


On Tue, Sep 29, 2020 at 11:10:21PM +0200, Marton Balint wrote:
This should increase the effectiveness of ffio_ensure_seekback by reducing 

the

number of buffer reallocations and memmoves/memcpys because even a small
seekback window requires max_buffer_size+window_size buffer space.

Signed-off-by: Marton Balint 
---
 libavformat/aviobuf.c | 5 +
 1 file changed, 5 insertions(+)



This patch set fixes demuxing chained oggs via pipe,
so I'm not against it.


Thanks for testing.

Is there anybody who would like to comment on the patch series 
before I push it?


I know that some regression tests for avio would be good, but it is not 
something I plan working on.


Last ping, will apply soon.

Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/pgxdec: Check depth more completely

[Andreas Rheinhardt]

Michael Niedermayer:
> Fixes: shift exponent -1 is negative
> Fixes: 
> 26107/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-5378790047612928
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/pgxdec.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
> index 150f8bbf66..5c735894ab 100644
> --- a/libavcodec/pgxdec.c
> +++ b/libavcodec/pgxdec.c
> @@ -133,14 +133,14 @@ static int pgx_decode_frame(AVCodecContext *avctx, void 
> *data,
>  if ((ret = ff_set_dimensions(avctx, width, height)) < 0)
>  return ret;
>  
> -if (depth <= 8) {
> +if (depth > 0 && depth <= 8) {
>  avctx->pix_fmt = AV_PIX_FMT_GRAY8;
>  bpp = 8;
> -} else if (depth <= 16) {
> +} else if (depth > 0 && depth <= 16) {
>  avctx->pix_fmt = AV_PIX_FMT_GRAY16;
>  bpp = 16;
>  } else {
> -av_log(avctx, AV_LOG_ERROR, "Maximum depth of 16 bits supported.\n");
> +av_log(avctx, AV_LOG_ERROR, "depth %d is invalid or unsupported.\n", 
> depth);
>  return AVERROR_PATCHWELCOME;
>  }
>  if (bytestream2_get_bytes_left(&g) < width * height * (bpp >> 3))
> 
I presume the parsed depth to be zero in your testcase. Said number
comes from pgx_get_number() which is only used to parse values for which
a value of zero makes no sense. Wouldn't it make more sense to error out
there if the number is zero?

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avcodec/mpeg12: Reduce size of motion-vector VLC

[Andreas Rheinhardt]

It currently uses 9 bits per table, but there are no codes with
nine bits at all, while there are codes with eight, ten and eleven bits.
So reducing the table size to eight bits will not reduce the amount of
codes that can be parsed in the first step, but it allows to reduce the
size of the motion-vector VLC.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12.c| 2 +-
 libavcodec/mpeg12vlc.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/mpeg12.c b/libavcodec/mpeg12.c
index ab6c19c615..e4f007aec5 100644
--- a/libavcodec/mpeg12.c
+++ b/libavcodec/mpeg12.c
@@ -149,7 +149,7 @@ av_cold void ff_mpeg12_init_vlcs(void)
 ff_mpeg12_vlc_dc_chroma_code, 2, 2, 514);
 INIT_VLC_STATIC(&ff_mv_vlc, MV_VLC_BITS, 17,
 &ff_mpeg12_mbMotionVectorTable[0][1], 2, 1,
-&ff_mpeg12_mbMotionVectorTable[0][0], 2, 1, 518);
+&ff_mpeg12_mbMotionVectorTable[0][0], 2, 1, 266);
 INIT_VLC_STATIC(&ff_mbincr_vlc, MBINCR_VLC_BITS, 36,
 &ff_mpeg12_mbAddrIncrTable[0][1], 2, 1,
 &ff_mpeg12_mbAddrIncrTable[0][0], 2, 1, 538);
diff --git a/libavcodec/mpeg12vlc.h b/libavcodec/mpeg12vlc.h
index c5abae96b6..70aca645cb 100644
--- a/libavcodec/mpeg12vlc.h
+++ b/libavcodec/mpeg12vlc.h
@@ -31,7 +31,7 @@
 #include "vlc.h"
 
 #define DC_VLC_BITS 9
-#define MV_VLC_BITS 9
+#define MV_VLC_BITS 8
 #define TEX_VLC_BITS 9
 
 #define MBINCR_VLC_BITS 9
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] avcodec/mpeg12: Don't pretend reading dct_dc_size_* VLCs can fail

[Andreas Rheinhardt]

It can't because the corresponding trees don't have any loose ends.

Removing the checks also removed an instance of av_log(NULL (with a
nonsense message) from the codebase.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mdec.c  | 2 --
 libavcodec/mpeg12.h| 4 
 libavcodec/mpeg12dec.c | 4 
 3 files changed, 10 deletions(-)

diff --git a/libavcodec/mdec.c b/libavcodec/mdec.c
index 7e34ec568e..b16cbb6a79 100644
--- a/libavcodec/mdec.c
+++ b/libavcodec/mdec.c
@@ -71,8 +71,6 @@ static inline int mdec_decode_block_intra(MDECContext *a, 
int16_t *block, int n)
 } else {
 component = (n <= 3 ? 0 : n - 4 + 1);
 diff = decode_dc(&a->gb, component);
-if (diff >= 0x)
-return AVERROR_INVALIDDATA;
 a->last_dc[component] += diff;
 block[0] = a->last_dc[component] * (1 << 3);
 }
diff --git a/libavcodec/mpeg12.h b/libavcodec/mpeg12.h
index 1ec99f17e1..345d473d3a 100644
--- a/libavcodec/mpeg12.h
+++ b/libavcodec/mpeg12.h
@@ -47,10 +47,6 @@ static inline int decode_dc(GetBitContext *gb, int component)
 } else {
 code = get_vlc2(gb, ff_dc_chroma_vlc.table, DC_VLC_BITS, 2);
 }
-if (code < 0){
-av_log(NULL, AV_LOG_ERROR, "invalid dc code at\n");
-return 0x;
-}
 if (code == 0) {
 diff = 0;
 } else {
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 2494226aa3..7b448d3648 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -490,8 +490,6 @@ static inline int mpeg2_decode_block_intra(MpegEncContext 
*s,
 component= (n & 1) + 1;
 }
 diff = decode_dc(&s->gb, component);
-if (diff >= 0x)
-return AVERROR_INVALIDDATA;
 dc  = s->last_dc[component];
 dc += diff;
 s->last_dc[component] = dc;
@@ -578,8 +576,6 @@ static inline int 
mpeg2_fast_decode_block_intra(MpegEncContext *s,
 component= (n & 1) + 1;
 }
 diff = decode_dc(&s->gb, component);
-if (diff >= 0x)
-return AVERROR_INVALIDDATA;
 dc = s->last_dc[component];
 dc += diff;
 s->last_dc[component] = dc;
-- 
2.25.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 3/3] avcodec/mpeg12dec: Optimize reading mpeg2 intra escape codes

[Andreas Rheinhardt]

Said escape code is only six bits long, so that one has at least 25 - 6
bits in the bitstream reader's cache after reading it; therefore the
whole following 18 bits (containing the actual code) are already in the
bitstream reader's cache, making it unnecessary to reload the cache.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg12dec.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 7b448d3648..3be90d7f25 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -524,10 +524,9 @@ static inline int mpeg2_decode_block_intra(MpegEncContext 
*s,
 } else {
 /* escape */
 run = SHOW_UBITS(re, &s->gb, 6) + 1;
-LAST_SKIP_BITS(re, &s->gb, 6);
-UPDATE_CACHE(re, &s->gb);
+SKIP_BITS(re, &s->gb, 6);
 level = SHOW_SBITS(re, &s->gb, 12);
-SKIP_BITS(re, &s->gb, 12);
+LAST_SKIP_BITS(re, &s->gb, 12);
 i += run;
 if (i > MAX_INDEX)
 break;
@@ -606,10 +605,9 @@ static inline int 
mpeg2_fast_decode_block_intra(MpegEncContext *s,
 } else {
 /* escape */
 run = SHOW_UBITS(re, &s->gb, 6) + 1;
-LAST_SKIP_BITS(re, &s->gb, 6);
-UPDATE_CACHE(re, &s->gb);
+SKIP_BITS(re, &s->gb, 6);
 level = SHOW_SBITS(re, &s->gb, 12);
-SKIP_BITS(re, &s->gb, 12);
+LAST_SKIP_BITS(re, &s->gb, 12);
 i += run;
 j = scantable[i];
 if (level < 0) {
-- 
2.25.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/magicyuvenc: Use more correct cast in compare function

[Paul B Mahol]

On Thu, Oct 08, 2020 at 09:18:42PM +0200, Andreas Rheinhardt wrote:
> There is no need to cast const away (even if it was harmless) and to
> copy the object at all.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/magicyuvenc.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

lgtm
___
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 3/4] avcodec/magicyuvenc: Avoid sorting Huffman table unnecessarily

[Paul B Mahol]

On Thu, Oct 08, 2020 at 09:18:41PM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/magicyuvenc.c | 41 ++--
>  1 file changed, 14 insertions(+), 27 deletions(-)
> 

should be ok if encoding still works
___
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/4] avcodec/mjpegdec: Remove use_static from build_vlc()

[Paul B Mahol]

On Thu, Oct 08, 2020 at 09:18:39PM +0200, Andreas Rheinhardt wrote:
> It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
> been removed in 595324e143b57a52e2329eb47b84395c70f93087.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mjpegdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

probably ok
___
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] avcodec/mjpegdec: Remove redundant initialization

[Paul B Mahol]

On Thu, Oct 08, 2020 at 09:18:40PM +0200, Andreas Rheinhardt wrote:
> Now that the correct number of codes is used, it is no longer necessary
> to initialize the lengths of the codes at all any more as the length of
> the actually used codes is set later anyway.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mjpegdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

lgtm
___
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/4] avcodec/mjpegdec: Remove use_static from build_vlc()

[Michael Niedermayer]

On Thu, Oct 08, 2020 at 09:18:39PM +0200, Andreas Rheinhardt wrote:
> It is always zero; it referred to the INIT_VLC_USE_STATIC flag which has
> been removed in 595324e143b57a52e2329eb47b84395c70f93087.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mjpegdec.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)

LGTM

thx


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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] VP9 Profile 2 VDPAU support

[Philip Langdale]

On Thu, 8 Oct 2020 11:48:51 +0530
ManojGuptaBonda  wrote:

> Added VDPAU to list of supported formats for VP9 420 10 and 12 bit
> formats. Add VP9 10/12 Bit support for VDPAU
> ---
>  libavcodec/vp9.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index fd0bab14a2..8b89fd68e2 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -223,6 +223,9 @@ static int update_size(AVCodecContext *avctx, int
> w, int h) #endif
>  #if CONFIG_VP9_VAAPI_HWACCEL
>  *fmtp++ = AV_PIX_FMT_VAAPI;
> +#endif
> +#if CONFIG_VP9_VDPAU_HWACCEL
> +*fmtp++ = AV_PIX_FMT_VDPAU;
>  #endif
>  break;
>  case AV_PIX_FMT_YUV420P12:
> @@ -231,6 +234,9 @@ static int update_size(AVCodecContext *avctx, int
> w, int h) #endif
>  #if CONFIG_VP9_VAAPI_HWACCEL
>  *fmtp++ = AV_PIX_FMT_VAAPI;
> +#endif
> +#if CONFIG_VP9_VDPAU_HWACCEL
> +*fmtp++ = AV_PIX_FMT_VDPAU;
>  #endif
>  break;
>  }

Pushed. Thanks,


--phil
___
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] Revert "aviobuf: Discard old buffered, previously read data in ffio_read_partial"

[Marton Balint]

This is unneeded after 2ca48e466675a8a3630061cd2c15325eab8eda97 and it breaks
ffio_ensure_seekback().

This reverts commit 53c25ee0736497b46bb76064cc2c84c976b2d295.
---
 libavformat/aviobuf.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index a77517d712..b55b206be2 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -719,13 +719,6 @@ int avio_read_partial(AVIOContext *s, unsigned char *buf, 
int size)
 
 len = s->buf_end - s->buf_ptr;
 if (len == 0) {
-/* Reset the buf_end pointer to the start of the buffer, to make sure
- * the fill_buffer call tries to read as much data as fits into the
- * full buffer, instead of just what space is left after buf_end.
- * This avoids returning partial packets at the end of the buffer,
- * for packet based inputs.
- */
-s->buf_end = s->buf_ptr = s->buffer;
 fill_buffer(s);
 len = s->buf_end - s->buf_ptr;
 }
-- 
2.26.2

___
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/isom: add support for RAW ASC Bayer BGGR in mov

[Peter Ross]

On Thu, Oct 08, 2020 at 07:25:33PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/raw.c   | 1 +
>  libavformat/isom.c | 2 ++
>  2 files changed, 3 insertions(+)
> 
> diff --git a/libavcodec/raw.c b/libavcodec/raw.c
> index b6fb91c1c6..079d5c5d10 100644
> --- a/libavcodec/raw.c
> +++ b/libavcodec/raw.c
> @@ -246,6 +246,7 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
>  { AV_PIX_FMT_GRAY16BE,MKTAG('b', '1', '6', 'g') },
>  { AV_PIX_FMT_RGB48BE, MKTAG('b', '4', '8', 'r') },
>  { AV_PIX_FMT_RGBA64BE,MKTAG('b', '6', '4', 'a') },
> +{ AV_PIX_FMT_BAYER_RGGB16BE, MKTAG('B', 'G', 'G', 'R') },
>  
>  /* vlc */
>  { AV_PIX_FMT_YUV410P, MKTAG('I', '4', '1', '0') },
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index 019175d814..d1ef6e3407 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -316,6 +316,8 @@ const AVCodecTag ff_codec_movvideo_tags[] = {
>  
>  { AV_CODEC_ID_NOTCHLC, MKTAG('n', 'c', 'l', 'c') },
>  
> +{ AV_CODEC_ID_RAWVIDEO, MKTAG('B', 'G', 'G', 'R') }, /* ASC Bayer BGGR */
> +
>  { AV_CODEC_ID_NONE, 0 },
>  };
>  
> -- 
> 2.17.1

looks good

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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] FATE/dnn: only run unit test when CONFIG_DNN enabled

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Peter
> Ross
> Sent: 2020年10月8日 19:01
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH] FATE/dnn: only run unit test when
> CONFIG_DNN enabled
> 
> Signed-off-by: Peter Ross 
> ---
>  tests/fate/dnn.mak | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/fate/dnn.mak b/tests/fate/dnn.mak index
> 90a1bb3cac..c5e458708e 100644
> --- a/tests/fate/dnn.mak
> +++ b/tests/fate/dnn.mak
> @@ -33,6 +33,6 @@ fate-dnn-layer-avgpool:
> $(DNNTESTSDIR)/dnn-layer-avgpool-test$(EXESUF)
>  fate-dnn-layer-avgpool: CMD = run
> $(DNNTESTSDIR)/dnn-layer-avgpool-test$(EXESUF)
>  fate-dnn-layer-avgpool: CMP = null
> 
> -FATE-yes += $(FATE_DNN)
> +FATE-$(CONFIG_DNN) += $(FATE_DNN)
LGTM, will push soon, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v6] avdevice/xcbgrab: Add select_region option

[Andriy Gelman]

On Sat, 11. Jul 11:29, Omar Emara wrote:
> This patch adds a select_region option to the xcbgrab input device.
> If set to 1, the user will be prompted to select the grabbing area
> graphically by clicking and dragging. A rectangle will be drawn to
> mark the grabbing area. A single click with no dragging will select
> the whole screen. The option overwrites the video_size, grab_x, and
> grab_y options if set by the user.
> 
> For testing, just set the select_region option as follows:
> 
> ffmpeg -f x11grab -select_region 1 -i :0.0 output.mp4
> 
> The drawing happens directly on the root window using standard rubber
> banding techniques, so it is very efficient and doesn't depend on any
> X extensions or compositors.
> 
> Signed-off-by: Omar Emara 
> ---
>  doc/indevs.texi   |   8 +++
>  libavdevice/xcbgrab.c | 127 ++
>  2 files changed, 135 insertions(+)
> 
> diff --git a/doc/indevs.texi b/doc/indevs.texi
> index 6f5afaf344..90ccc917aa 100644
> --- a/doc/indevs.texi
> +++ b/doc/indevs.texi
> @@ -1478,6 +1478,14 @@ ffmpeg -f x11grab -framerate 25 -video_size cif -i 
> :0.0+10,20 out.mpg
>  @subsection Options
>  
>  @table @option
> +@item select_region
> +Specify whether to select the grabbing area graphically using the pointer.
> +A value of @code{1} prompts the user to select the grabbing area graphically
> +by clicking and dragging. A single click with no dragging will select the
> +whole screen. A region with zero width or height will also select the whole
> +screen. This option overwrites the @var{video_size}, @var{grab_x}, and
> +@var{grab_y} options. Default value is @code{0}.
> +
>  @item draw_mouse
>  Specify whether to draw the mouse pointer. A value of @code{0} specifies
>  not to draw the pointer. Default value is @code{1}.
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index 6f6b2dbf15..bcd91e54af 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -22,6 +22,7 @@
>  #include "config.h"
>  
>  #include 
> +#include 
>  #include 
>  
>  #if CONFIG_LIBXCB_XFIXES
> @@ -69,6 +70,7 @@ typedef struct XCBGrabContext {
>  int show_region;
>  int region_border;
>  int centered;
> +int select_region;
>  
>  const char *framerate;
>  
> @@ -92,6 +94,7 @@ static const AVOption options[] = {
>  { "centered", "Keep the mouse pointer at the center of grabbing region 
> when following.", 0, AV_OPT_TYPE_CONST, { .i64 = -1 }, INT_MIN, INT_MAX, D, 
> "follow_mouse" },
>  { "show_region", "Show the grabbing region.", OFFSET(show_region), 
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
>  { "region_border", "Set the region border thickness.", 
> OFFSET(region_border), AV_OPT_TYPE_INT, { .i64 = 3 }, 1, 128, D },
> +{ "select_region", "Select the grabbing region graphically using the 
> pointer.", OFFSET(select_region), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, D },
>  { NULL },
>  };
>  
> @@ -668,6 +671,122 @@ static void setup_window(AVFormatContext *s)
>  draw_rectangle(s);
>  }
>  
> +#define CROSSHAIR_CURSOR 34
> +
> +static xcb_rectangle_t rectangle_from_corners(xcb_point_t *corner_a,
> +  xcb_point_t *corner_b)
> +{
> +xcb_rectangle_t rectangle;
> +rectangle.x = FFMIN(corner_a->x, corner_b->x);
> +rectangle.y = FFMIN(corner_a->y, corner_b->y);
> +rectangle.width = FFABS(corner_a->x - corner_b->x);
> +rectangle.height = FFABS(corner_a->y - corner_b->y);
> +return rectangle;
> +}
> +
> +static int select_region(AVFormatContext *s)
> +{
> +XCBGrabContext *c = s->priv_data;
> +xcb_connection_t *conn = c->conn;
> +xcb_screen_t *screen = c->screen;
> +
> +int ret = 0;
> +int done = 0;
> +int was_pressed = 0;
> +xcb_cursor_t cursor;
> +xcb_font_t cursor_font;
> +xcb_point_t press_position;
> +xcb_generic_event_t *event;
> +xcb_rectangle_t rectangle = {0};
> +xcb_grab_pointer_reply_t *reply;
> +xcb_grab_pointer_cookie_t cookie;
> +
> +xcb_window_t root_window = screen->root;
> +xcb_gcontext_t gc = xcb_generate_id(conn);
> +uint32_t mask = XCB_GC_FUNCTION | XCB_GC_SUBWINDOW_MODE;
> +uint32_t values[] = {XCB_GX_INVERT,
> + XCB_SUBWINDOW_MODE_INCLUDE_INFERIORS};
> +xcb_create_gc(conn, gc, root_window, mask, values);
> +
> +cursor_font = xcb_generate_id(conn);
> +xcb_open_font(conn, cursor_font, strlen("cursor"), "cursor");
> +cursor = xcb_generate_id(conn);
> +xcb_create_glyph_cursor(conn, cursor, cursor_font, cursor_font,
> +CROSSHAIR_CURSOR, CROSSHAIR_CURSOR + 1, 0, 0, 0,
> +0x, 0x, 0x);
> +cookie = xcb_grab_pointer(conn, 0, root_window,
> +  XCB_EVENT_MASK_BUTTON_PRESS |
> +  XCB_EVENT_MASK_BUTTON_RELEASE |
> +  XCB_EVENT_MASK_BUTTON_MOTION,
> +   

Re: [FFmpeg-devel] [PATCH 4/7] lavfi/vf_spp: convert to the video_enc_params API

[Anton Khirnov]

Quoting Michael Niedermayer (2020-10-06 00:15:06)
> On Mon, Oct 05, 2020 at 10:26:24AM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2020-10-03 20:23:02)
> > > On Fri, Oct 02, 2020 at 08:03:28PM +0200, Anton Khirnov wrote:
> > > > ---
> > > >  libavfilter/Makefile|  2 +-
> > > >  libavfilter/vf_spp.c| 57 -
> > > >  libavfilter/vf_spp.h|  3 +-
> > > >  tests/fate/filter-video.mak |  4 +--
> > > >  4 files changed, 29 insertions(+), 37 deletions(-)
> > > > 
> > > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > > > index d20f2937b6..2669d7b84b 100644
> > > > --- a/libavfilter/Makefile
> > > > +++ b/libavfilter/Makefile
> > > > @@ -404,7 +404,7 @@ OBJS-$(CONFIG_SOBEL_FILTER)  += 
> > > > vf_convolution.o
> > > >  OBJS-$(CONFIG_SOBEL_OPENCL_FILTER)   += 
> > > > vf_convolution_opencl.o opencl.o \
> > > >  opencl/convolution.o
> > > >  OBJS-$(CONFIG_SPLIT_FILTER)  += split.o
> > > > -OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o
> > > > +OBJS-$(CONFIG_SPP_FILTER)+= vf_spp.o qp_table.o
> > > >  OBJS-$(CONFIG_SR_FILTER) += vf_sr.o
> > > >  OBJS-$(CONFIG_SSIM_FILTER)   += vf_ssim.o framesync.o
> > > >  OBJS-$(CONFIG_STEREO3D_FILTER)   += vf_stereo3d.o
> > > > diff --git a/libavfilter/vf_spp.c b/libavfilter/vf_spp.c
> > > > index 4bcc6429e0..2eb383be03 100644
> > > > --- a/libavfilter/vf_spp.c
> > > > +++ b/libavfilter/vf_spp.c
> > > > @@ -36,6 +36,7 @@
> > > >  #include "libavutil/opt.h"
> > > >  #include "libavutil/pixdesc.h"
> > > >  #include "internal.h"
> > > > +#include "qp_table.h"
> > > >  #include "vf_spp.h"
> > > >  
> > > >  enum mode {
> > > > @@ -289,7 +290,7 @@ static void filter(SPPContext *p, uint8_t *dst, 
> > > > uint8_t *src,
> > > >  } else{
> > > >  const int qps = 3 + is_luma;
> > > >  qp = qp_table[(FFMIN(x, width - 1) >> qps) + (FFMIN(y, 
> > > > height - 1) >> qps) * qp_stride];
> > > > -qp = FFMAX(1, ff_norm_qscale(qp, p->qscale_type));
> > > > +qp = FFMAX(1, ff_norm_qscale(qp, 
> > > > FF_QSCALE_TYPE_MPEG2));
> > > 
> > > wouldnt this break the cases where qscale_type is not 
> > > FF_QSCALE_TYPE_MPEG2 ?
> > 
> > There should be no such cases - in the new API, only TYPE_MPEG2 exists
> > (disregarding newer codecs that were not supported by this filter
> > anyway).
> 
> before the patch the code was intended to convert the quantization step size
> used in the codec to the same scale as the filter used. disregarding if the
> codec was 8x8 dct based. In fact spp should not require the input to be 8x8 
> dct
> based at all, why should it? It uses the DCT as a means to favor real images
> and remove "noise" that is not part of real images. It should for example also
> work if a image has blocking artifacts that look like hexagons or triangles
> 
> I never tried but H264 with disabled loop filter should benefit from spp in
> terms of subjective quality as long as the filter strength is set 
> appropriately
> That is for streams where the bitrate is low enough to see artifacts

Are you saying I should expand this filter to support new codecs? That
does not seem appropriate for a patch that only adapts it to new API.

-- 
Anton Khirnov
___
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".