Re: [FFmpeg-devel] [PATCH 2/2] lavc/mjpegdec: make code aligned
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Friday, June 28, 2019 8:55 PM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH 2/2] lavc/mjpegdec: make code aligned > > On Thu, Jun 27, 2019 at 04:58:24PM +0800, Zhong Li wrote: > > Signed-off-by: Zhong Li > > --- > > libavcodec/mjpegdec.c | 450 > +- > > 1 file changed, 225 insertions(+), 225 deletions(-) > > LGTM > > thx 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] libavformat/subfile: Improve AVSEEK_SIZE/SEEK_END seeking
Andreas Rheinhardt:
> The subfile protocol treats an end of 0 as meaning "until EOF"; this got
> implemented by simply setting the end to INT64_MAX. But seeking relative
> to EOF or AVSEEK_SIZE seeking hasn't been adapted; the result is that
> e.g. the duration of transport streams isn't correctly determined when
> this option is used. This is fixed in this patch.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/subfile.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/subfile.c b/libavformat/subfile.c
> index b527f2bee1..2f162e0a34 100644
> --- a/libavformat/subfile.c
> +++ b/libavformat/subfile.c
> @@ -116,11 +116,17 @@ static int subfile_read(URLContext *h, unsigned char
> *buf, int size)
> static int64_t subfile_seek(URLContext *h, int64_t pos, int whence)
> {
> SubfileContext *c = h->priv_data;
> -int64_t new_pos = -1;
> +int64_t new_pos = -1, end;
> int ret;
>
> +if (whence == AVSEEK_SIZE || whence == SEEK_END) {
> +end = c->end;
> +if (end == INT64_MAX && (end = ffurl_seek(c->h, 0, AVSEEK_SIZE)) < 0)
> +return end;
> +}
> +
> if (whence == AVSEEK_SIZE)
> -return c->end - c->start;
> +return end - c->start;
> switch (whence) {
> case SEEK_SET:
> new_pos = c->start + pos;
> @@ -129,7 +135,7 @@ static int64_t subfile_seek(URLContext *h, int64_t pos,
> int whence)
> new_pos += pos;
> break;
> case SEEK_END:
> -new_pos = c->end + c->pos;
> +new_pos = end + c->pos;
> break;
> }
> if (new_pos < c->start)
>
Ping.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Michael Niedermayer
> Sent: Friday, June 28, 2019 8:52 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function
> ff_mjpeg_decode_header
>
> On Thu, Jun 27, 2019 at 08:59:12PM +0800, Zhong Li wrote:
> > It will be reused in the following mjpeg_parser patch
> >
> > Signed-off-by: Zhong Li
> > ---
> > Mark Thompson: This seems suspicious - MJPEG is generally 4:2:2 (e.g.
> > UVC requires it), so I would expect a 4:2:2 format to be the default
> > here? (Or maybe a longer list - VAAPI certainly supports 4:2:2, 4:2:0
> > and 4:4:4 on the same hardware.)
> > Zhong: libmfx can support jpeg baseline profile with more output formats,
> but current ffmpeg-qsv decoder/vpp can't. Will extend supported format list
> as separated patch.
> >
> > libavcodec/mjpegdec.c | 37 -
> > libavcodec/mjpegdec.h | 4
> > 2 files changed, 32 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c index
> > a65bc8d..5da66bb 100644
> > --- a/libavcodec/mjpegdec.c
> > +++ b/libavcodec/mjpegdec.c
> > @@ -157,6 +157,8 @@ av_cold int
> ff_mjpeg_decode_init(AVCodecContext *avctx)
> > s->start_code= -1;
> > s->first_picture = 1;
> > s->got_picture = 0;
> > +s->reinit_idct = 0;
> > +s->size_change = 0;
> > s->org_height= avctx->coded_height;
> > avctx->chroma_sample_location = AVCHROMA_LOC_CENTER;
> > avctx->colorspace = AVCOL_SPC_BT470BG; @@ -302,9 +304,9 @@
> int
> > ff_mjpeg_decode_dht(MJpegDecodeContext *s)
> > return 0;
> > }
> >
> > -int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> > +int ff_mjpeg_decode_header(MJpegDecodeContext *s)
> > {
> > -int len, nb_components, i, width, height, bits, ret, size_change;
> > +int len, nb_components, i, width, height, bits, ret;
> > unsigned pix_fmt_id;
> > int h_count[MAX_COMPONENTS] = { 0 };
> > int v_count[MAX_COMPONENTS] = { 0 }; @@ -324,7 +326,7 @@ int
> > ff_mjpeg_decode_sof(MJpegDecodeContext *s)
> > if (s->avctx->bits_per_raw_sample != bits) {
> > av_log(s->avctx, s->avctx->bits_per_raw_sample > 0 ?
> AV_LOG_INFO : AV_LOG_DEBUG, "Changing bps from %d to %d\n",
> s->avctx->bits_per_raw_sample, bits);
> > s->avctx->bits_per_raw_sample = bits;
> > -init_idct(s->avctx);
> > +s->reinit_idct = 1;
> > }
>
> I think the avctx->bits_per_raw_sample value should stay in sync with the
> initialized idct
>
> This patch would allow the bits_per_raw_sample to change and then a
> subsequent error to skip init_idct() maybe this is ok as it would be probably
> called later in a subsequent frame but i think its better if they stay closer
> together or there is nothing between them that can cause ine to exeucute
> without the other
Thanks for detail comment, actually this is an intended way to resolve a
dependency:
Calling init_idct requires the decoder has been initialized.
static void init_idct(AVCodecContext *avctx)
{
MJpegDecodeContext *s = avctx->priv_data;
...
}
But I hope ff_mjpeg_decode_header can be used for mjpeg_parser, if don't use
current way, will cause segment fault when call init_idct() due to
avctx->priv_data is NULL.
Probably we can change the definition of init_idct(AVCodecContext *avctx) to be
init_idct(MJpegDecodeContext *s) ? (But init_idct is useless for parser).
___
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] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of James Almer
> Sent: Saturday, June 29, 2019 12:56 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpeg_parser: use
> ff_mjpeg_decode_header to parse frame info
>
> On 6/27/2019 9:59 AM, Zhong Li wrote:
> > Signed-off-by: Zhong Li
> > ---
> > libavcodec/mjpeg_parser.c | 158
> > +-
> > 1 file changed, 157 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/mjpeg_parser.c b/libavcodec/mjpeg_parser.c
> > index 07a6b2b..f59aa3e 100644
> > --- a/libavcodec/mjpeg_parser.c
> > +++ b/libavcodec/mjpeg_parser.c
> > @@ -27,12 +27,131 @@
> > */
> >
> > #include "parser.h"
> > +#include "mjpeg.h"
> > +#include "mjpegdec.h"
> > +#include "get_bits.h"
> >
> > typedef struct MJPEGParserContext{
> > ParseContext pc;
> > +MJpegDecodeContext dec_ctx;
>
> This is not acceptable. The parser shouldn't use decoder structs, as it makes
> the former depend on the latter.
>
> A reusable header parsing function should be standalone, so it may be called
> from decoders, parsers, bitstream filters, and anything that may require it.
Thanks for your comment, James.
This is not the first time to introduce decoder dependency, please see
mpeg4video_parser.c
And IMHO no matter what is the form you parse a header, actually it is a part
of decoding process.
Refusing to reuse decoder context or function will introduce huge code
duplication and bring trouble to maintain later.
Probably set up a middle layer just like h264_ps.c for both decoder and parser
to use is a better idea?
(But a tricky thing is that mjpeg header parser is a litter more complex h264,
pix_fmt and color_range is not just desided by frame header makers, but also
comment makers:
See:
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
else {
if ( s->adobe_transform == 0
|| s->component_id[0] == 'R' - 1 && s->component_id[1] ==
'G' - 1 && s->component_id[2] == 'B' - 1) {
s->avctx->pix_fmt = s->bits <= 8 ? AV_PIX_FMT_GBRP :
AV_PIX_FMT_GBRP16;
} else {
if (s->bits <= 8) s->avctx->pix_fmt = s->cs_itu601 ?
AV_PIX_FMT_YUV444P : AV_PIX_FMT_YUVJ444P;
else s->avctx->pix_fmt = AV_PIX_FMT_YUV444P16;
s->avctx->color_range = s->cs_itu601 ? AVCOL_RANGE_MPEG :
AVCOL_RANGE_JPEG;
}
}
Here cs_itu601 is parsed from comment makers.
)
Any suggestion/comment is welcome.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: changing all filename length to MAX_URL_SIZE
> 在 2019年6月28日，下午7:55，Bodecs Bela 写道： > > Dear All, > > throughout hlsenc code, all filename related buffer lengths are set > hardcoded as 1024. This PATCH change it to general value as MAX_URL_SIZE > of internal.h > > please review this patch. > > thank you in advance, > > best regards, > > Bela > > <0001-avformat-hlsenc-changing-all-filename-length-to-MAX_.patch>___ > 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". Applied Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] lavc/mjpegdec: add function ff_mjpeg_decode_header
>Sorry for not realizing this earlier (I searched for "SOF0"): >Why is this function duplicated? > >Carl Eugen Hi Carl: You can find the difference: here I just find frame header markers (SOF0 ~ SOF 3), mjpeg decoder try to find all markers. Thanks Zhong ___ 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] lavc/mjpeg_parser: use ff_mjpeg_decode_header to parse frame info
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Michael Niedermayer > Sent: Friday, June 28, 2019 4:12 PM > To: FFmpeg development discussions and patches > > Subject: Re: [FFmpeg-devel] [PATCH 2/3] lavc/mjpeg_parser: use > ff_mjpeg_decode_header to parse frame info > > On Thu, Jun 27, 2019 at 08:59:13PM +0800, Zhong Li wrote: > > Signed-off-by: Zhong Li > > --- > > libavcodec/mjpeg_parser.c | 158 > > +- > > 1 file changed, 157 insertions(+), 1 deletion(-) > > this breaks mjpeg decoding > > for example tickets/3229/bad.avi > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket3229/ Ok, will fix and update. (Probably adding this case to fate is a good idea?) ___ 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/hevcdec: Fix memleak of a53_caption
On 6/30/2019 10:43 PM, James Almer wrote: > On 6/30/2019 7:16 PM, Michael Niedermayer wrote: >> Fixes: >> 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/hevcdec.c | 2 ++ >> 1 file changed, 2 insertions(+) >> >> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c >> index 515b346535..b5d918d07d 100644 >> --- a/libavcodec/hevcdec.c >> +++ b/libavcodec/hevcdec.c >> @@ -3331,6 +3331,8 @@ static av_cold int hevc_decode_free(AVCodecContext >> *avctx) >> >> ff_h2645_packet_uninit(>pkt); >> >> +ff_hevc_reset_sei(>sei); >> + >> return 0; >> } > > LGTM. You could also add it to hevc_decode_flush() while at 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".
Re: [FFmpeg-devel] [PATCH 1/4] avcodec/hevcdec: Fix memleak of a53_caption
On 6/30/2019 7:16 PM, Michael Niedermayer wrote: > Fixes: > 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hevcdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > index 515b346535..b5d918d07d 100644 > --- a/libavcodec/hevcdec.c > +++ b/libavcodec/hevcdec.c > @@ -3331,6 +3331,8 @@ static av_cold int hevc_decode_free(AVCodecContext > *avctx) > > ff_h2645_packet_uninit(>pkt); > > +ff_hevc_reset_sei(>sei); > + > return 0; > } 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 5/5] startcode: Filter out non-startcodes earlier
Andreas, On Sun, 09. Jun 13:00, Andreas Rheinhardt wrote: > Up until now, the bitmasks used to initially find out when one needs > to take a closer look and search for startcodes were rather primitive: > If a block (of four or eight bytes, depending on the system) contained a > zero, it was treated as a target for closer inspection. > This can be improved: Using the same technique of bitmasking as before, > one can test whether an arbitrary continuous range of bits consists of > zeros alone (and one can or the results of tests for non-overlapping > ranges of bits). A simple improvement would consist in simply testing > for whether every even byte does not vanish. But even better masks are > possible, in particular for big endian systems: > If all of the bits called 'a' or all of the bits called 'b' in the > uint32_t aaax bbby vanish, then this is > a candidate for closer inspection. If not, then it follows that > the three least serious bytes can't be the position of the 0x01 byte of > a 0x00 0x00 0x01 startcode. And if the most significant byte is the > position of the 0x01 of a startcode and if the same test is performed on > each block of four bytes in sequence, then all the b bits (as well as > the y bit) of the previous uint32_t would vanish and it would have been > considered a candidate for closer inspection. In other words: All > startcodes can be found with this test. The amount of candidates is > thereby reduced by a factor of about 256 (from about 4/2^8 to about > 2/2^15). For eight bytes at a time, the patterns are simply applied to > the high and low 32 bits at the same time. > Unfortunately, not so much is possible for little-endian systems because > continuous blocks of bits in the input byte array won't be continuous > blocks in the integer read. But one can nevertheless even improve upon > the "check every even/odd byte" test using the following mask: > > If any of these three blocks of bits vanishes, the block is a candidate > for further inspection. In the byte array, this mask corresponds to the > following situation: > > If a startcode's 0x01 is at the second or third position, the c block > vanishes; if it is at the fourth position, the b block vanishes and if > it is at the first position, the a block of the previous four-byte block > vanishes. (This derivation just made use of the fact that there must be > two vanishing bytes in sequence; I couldn't find a way to utilize that > the third byte also has nearly no bits set.) So all startcodes can be > found with this mask. Doubling this mask yields a mask for eight bytes > at a time. I haven't found a better mask for eight bytes than this one. > Using this, one can detect reduce the amount of false positives by about > 72% compared to the earlier check whether one of the bytes vanishes. > > Being more effective at initial filtering makes the whole process more > efficient, of course. Here are some benchmarks for a 30.2 Mb/s transport > stream A (10 iterations of 8192 runs each) and another 7.4 Mb/s transport > stream B (10 iterations of 131072 runs each) on an x64; except for > "vanilla" all versions tested didn't return false positives. > > | vanilla | aligned | aligned | > | (unaligned) | bad masks | good masks | > --|-|---|| > A |411578 | 323355 |233494 | > B | 55476 |44147 | 31793 | > > "vanilla" is the version before this patchset, i.e. before the switch to > aligned reads. "aligned bad masks" is the version before this commit. > "aligned good masks" is the current version. > > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/startcode.c | 12 ++-- > 1 file changed, 10 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/startcode.c b/libavcodec/startcode.c > index b29c1490c0..fa506a37d1 100644 > --- a/libavcodec/startcode.c > +++ b/libavcodec/startcode.c > @@ -95,10 +95,18 @@ int ff_startcode_find_candidate_c(const uint8_t *buf, int > size) > > #if HAVE_FAST_64BIT > INITIALIZATION(8); > -MAIN_LOOP(64, 0x0101010101010101ULL, 0x8080808080808080ULL); > +#if HAVE_BIGENDIAN > +MAIN_LOOP(64, 0x0002000200020002ULL, 0x8000800080008000ULL); > +#else > +MAIN_LOOP(64, 0x0010010100100101ULL, 0x8008008080080080ULL); > +#endif > #else > INITIALIZATION(4); > -MAIN_LOOP(32, 0x01010101U, 0x80808080U); > +#if HAVE_BIGENDIAN > +MAIN_LOOP(32, 0x00020002U, 0x80008000U); > +#else > +MAIN_LOOP(32, 0x00100101U, 0x80080080U); > +#endif > #endif > > /* For the end, buf is the earliest possible position > -- > 2.21.0 Below are the results of this patchset on Armv7 using OdroidXU4. OdroidXU4 has 8 cores - 4xARM Cortex A15 and 4xARM Cortex A7. Only the A15 cores were used for this test. Test sequences: Sequence C - 2560x1440, 20.4Mb/s, 8105 frames Source:
[FFmpeg-devel] [PATCH]lavc/zmbvenc: Do not left-shift negative values
Hi!
Attached patch fixes the only (remaining) issue I see with the sample
of ticket #7980.
Please comment, Carl Eugen
From e6ff8f43c0d9275b52290e18231438ce7770 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 Jul 2019 01:45:36 +0200
Subject: [PATCH] lavc/zmbvenc: Do not left-shift negative values.
Fixes the following ubsan errors with the sample from ticket #7980:
libavcodec/zmbvenc.c:243:29: runtime error: left shift of negative value -4
libavcodec/zmbvenc.c:244:28: runtime error: left shift of negative value -2
---
libavcodec/zmbvenc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/zmbvenc.c b/libavcodec/zmbvenc.c
index 48871758e0..0e22ce687f 100644
--- a/libavcodec/zmbvenc.c
+++ b/libavcodec/zmbvenc.c
@@ -240,8 +240,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
tprev = prev + x * c->bypp;
zmbv_me(c, tsrc, p->linesize[0], tprev, c->pstride, x, y, , , );
-mv[0] = (mx << 1) | !!xored;
-mv[1] = my << 1;
+mv[0] = (mx * 2) | !!xored;
+mv[1] = my * 2;
tprev += mx * c->bypp + my * c->pstride;
if(xored){
for(j = 0; j < bh2; j++){
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument
Hi! Undefined behaviour was reported in ticket #7981, attached patch tries to fix it. Please review, Carl Eugen From d77386d4a18d6d749d15516b5eb6df90507bf1eb Mon Sep 17 00:00:00 2001 From: Carl Eugen Hoyos Date: Mon, 1 Jul 2019 01:09:19 +0200 Subject: [PATCH] lavf/nutenc: Do not call memcmp() with NULL argument. Reported in ticket #7981 --- libavformat/nutenc.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c index e9a3bb49db..a3a097aacc 100644 --- a/libavformat/nutenc.c +++ b/libavformat/nutenc.c @@ -791,6 +791,7 @@ static int get_needed_flags(NUTContext *nut, StreamContext *nus, FrameCode *fc, flags |= FLAG_CHECKSUM; if (pkt->size < nut->header_len[fc->header_idx] || (pkt->size > 4096 && fc->header_idx)|| +nut->header[fc->header_idx] && memcmp(pkt->data, nut->header[fc->header_idx], nut->header_len[fc->header_idx])) flags |= FLAG_HEADER_IDX; -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavf/nutenc: Do not call memcmp() with NULL argument
Am Mo., 1. Juli 2019 um 01:12 Uhr schrieb Carl Eugen Hoyos : > > Hi! > > Undefined behaviour was reported in ticket #7981, attached patch tries Actually #7980. > to fix it. > > Please review, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavc/frame_thread_encoder: Do not memcpy() from NULL
Hi!
I believe attached patch fixes undefined behaviour and ticket #7981.
Please comment, Carl Eugen
From d72fe544d6d7cdf816a75df858b17f1744049d97 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 Jul 2019 00:49:44 +0200
Subject: [PATCH] lavc/frame_thread_encoder: Do not memcpy() from NULL.
Fixes ticket #7981.
---
libavcodec/frame_thread_encoder.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/frame_thread_encoder.c b/libavcodec/frame_thread_encoder.c
index 55756c4c54..bb2a5ed222 100644
--- a/libavcodec/frame_thread_encoder.c
+++ b/libavcodec/frame_thread_encoder.c
@@ -209,8 +209,9 @@ int ff_frame_thread_encoder_init(AVCodecContext *avctx, AVDictionary *options){
int ret = av_opt_copy(thread_avctx->priv_data, avctx->priv_data);
if (ret < 0)
goto fail;
-} else
+} else if (avctx->priv_data) {
memcpy(thread_avctx->priv_data, avctx->priv_data, avctx->codec->priv_data_size);
+}
thread_avctx->thread_count = 1;
thread_avctx->active_thread_type &= ~FF_THREAD_FRAME;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Only accept the appropriate stream type for raw muxers
Am Mo., 1. Juli 2019 um 00:40 Uhr schrieb Carl Eugen Hoyos :
>
> Hi!
>
> Attached patch fixes ticket #7979 for me.
Now attached.
> Please comment, Carl Eugen
From 702506c37b239bf26335fb8f42d06511b8604bb5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 Jul 2019 00:37:08 +0200
Subject: [PATCH] lavf/rawenc: Only accept the appropriate stream type for raw
muxers.
This does not affect the rawvideo muxer.
Fixes ticket #7979.
---
libavformat/rawenc.c | 12
1 file changed, 12 insertions(+)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 993d232b70..32704f9bfd 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -39,6 +39,18 @@ static int force_one_stream(AVFormatContext *s)
s->oformat->name);
return AVERROR(EINVAL);
}
+if ( s->oformat->audio_codec != AV_CODEC_ID_NONE
+&& s->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_AUDIO) {
+av_log(s, AV_LOG_ERROR, "%s files have exactly one audio stream\n",
+ s->oformat->name);
+return AVERROR(EINVAL);
+}
+if ( s->oformat->video_codec != AV_CODEC_ID_NONE
+&& s->streams[0]->codecpar->codec_type != AVMEDIA_TYPE_VIDEO) {
+av_log(s, AV_LOG_ERROR, "%s files have exactly one video stream\n",
+ s->oformat->name);
+return AVERROR(EINVAL);
+}
return 0;
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH]lavf/rawenc: Only accept the appropriate stream type for raw muxers
Hi! Attached patch fixes ticket #7979 for me. Please comment, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/4] avcodec/agm: Fix overflow of signed shift
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes:
15328/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_AGM_fuzzer-5637545171353600
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/agm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index a499c09082..2c4c9805e9 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -918,7 +918,7 @@ static void get_tree_codes(uint32_t *codes, Node *nodes,
int idx, uint32_t pfx,
codes[idx] = pfx;
} else if (idx >= 0) {
get_tree_codes(codes, nodes, nodes[idx].child[0], pfx + (0 << bitpos),
bitpos + 1);
-get_tree_codes(codes, nodes, nodes[idx].child[1], pfx + (1 << bitpos),
bitpos + 1);
+get_tree_codes(codes, nodes, nodes[idx].child[1], pfx + (1U <<
bitpos), bitpos + 1);
}
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/4] avcodec/ilbcdec: Simplify use of unsigned and fix more undefined overflows
Fixes: signed integer overflow: 2147475672 + 8192 cannot be represented in type
'int'
Fixes:
15415/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5712074128228352
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/ilbcdec.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ilbcdec.c b/libavcodec/ilbcdec.c
index bba83a5896..a82a27525c 100644
--- a/libavcodec/ilbcdec.c
+++ b/libavcodec/ilbcdec.c
@@ -724,7 +724,7 @@ static void construct_vector (
int16_t cbvec0[SUBL];
int16_t cbvec1[SUBL];
int16_t cbvec2[SUBL];
-int32_t a32;
+unsigned a32;
int16_t *gainPtr;
int j;
@@ -745,9 +745,9 @@ static void construct_vector (
for (j = 0; j < veclen; j++) {
a32 = SPL_MUL_16_16(*gainPtr++, cbvec0[j]);
a32 += SPL_MUL_16_16(*gainPtr++, cbvec1[j]);
-a32 += (unsigned)SPL_MUL_16_16(*gainPtr, cbvec2[j]);
+a32 += SPL_MUL_16_16(*gainPtr, cbvec2[j]);
gainPtr -= 2;
-decvector[j] = (a32 + 8192) >> 14;
+decvector[j] = (int)(a32 + 8192) >> 14;
}
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Do not allow encoding 0 audio channels
Am Mo., 1. Juli 2019 um 00:12 Uhr schrieb James Almer :
>
> On 6/30/2019 7:01 PM, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #7979 for me, please comment.
> >
> > Thank you, Carl Eugen
> >
> >
> > 0001-lavf-rawenc-Do-not-allow-encoding-0-audio-channels.patch
> >
> > From 976b294c10be32667852729c3652dbec466ac091 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Mon, 1 Jul 2019 00:00:38 +0200
> > Subject: [PATCH] lavf/rawenc: Do not allow encoding 0 audio channels.
> >
> > Fixes ticket #7979.
> > ---
> > libavformat/rawenc.c | 4
> > 1 file changed, 4 insertions(+)
> >
> > diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
> > index 993d232b70..0d00e5a0c5 100644
> > --- a/libavformat/rawenc.c
> > +++ b/libavformat/rawenc.c
> > @@ -39,6 +39,10 @@ static int force_one_stream(AVFormatContext *s)
> > s->oformat->name);
> > return AVERROR(EINVAL);
> > }
> > +if (s->streams[0]->codecpar->channels == 0) {
> > +av_log(s, AV_LOG_ERROR, "Encoding 0 channels is impossible\n");
>
> This looks like something that should be checked in init_muxer() from
> mux.c instead, same way it's checking sample_rate <= 0 for audio, and
> dimensions for video. That way it will apply to all muxers.
Unfortunately, the crash cannot be fixed in init_muxer() - at least not
where the sample_rate check is.
I am not saying my suggestion is the only solution, but it is what I
successfully tested.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/4] avcodec/hevcdec: Fix memleak of a53_caption
Fixes: 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/hevcdec.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c index 515b346535..b5d918d07d 100644 --- a/libavcodec/hevcdec.c +++ b/libavcodec/hevcdec.c @@ -3331,6 +3331,8 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx) ff_h2645_packet_uninit(>pkt); +ff_hevc_reset_sei(>sei); + return 0; } -- 2.22.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/4] avcodec/h264_refs: Also check reference in ff_h264_build_ref_list()
Fixes: out of array read
Fixes:
15409/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5758846959616000
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_refs.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/libavcodec/h264_refs.c b/libavcodec/h264_refs.c
index eaf965e43d..74087ff266 100644
--- a/libavcodec/h264_refs.c
+++ b/libavcodec/h264_refs.c
@@ -373,9 +373,11 @@ int ff_h264_build_ref_list(H264Context *h,
H264SliceContext *sl)
av_assert0(0);
}
-if (i < 0) {
+if (i < 0 || mismatches_ref(h, ref)) {
av_log(h->avctx, AV_LOG_ERROR,
- "reference picture missing during reorder\n");
+ i < 0 ? "reference picture missing during reorder\n" :
+ "mismatching reference\n"
+ );
memset(>ref_list[list][index], 0,
sizeof(sl->ref_list[0][0])); // FIXME
} else {
for (i = index; i + 1 < sl->ref_count[list]; i++) {
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH]lavf/rawenc: Do not allow encoding 0 audio channels
On 6/30/2019 7:01 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #7979 for me, please comment.
>
> Thank you, Carl Eugen
>
>
> 0001-lavf-rawenc-Do-not-allow-encoding-0-audio-channels.patch
>
> From 976b294c10be32667852729c3652dbec466ac091 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Mon, 1 Jul 2019 00:00:38 +0200
> Subject: [PATCH] lavf/rawenc: Do not allow encoding 0 audio channels.
>
> Fixes ticket #7979.
> ---
> libavformat/rawenc.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
> index 993d232b70..0d00e5a0c5 100644
> --- a/libavformat/rawenc.c
> +++ b/libavformat/rawenc.c
> @@ -39,6 +39,10 @@ static int force_one_stream(AVFormatContext *s)
> s->oformat->name);
> return AVERROR(EINVAL);
> }
> +if (s->streams[0]->codecpar->channels == 0) {
> +av_log(s, AV_LOG_ERROR, "Encoding 0 channels is impossible\n");
This looks like something that should be checked in init_muxer() from
mux.c instead, same way it's checking sample_rate <= 0 for audio, and
dimensions for video. That way it will apply to all muxers.
> +return AVERROR(EINVAL);
> +}
> return 0;
> }
>
> -- 2.22.0
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
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]lavf/rawenc: Do not allow encoding 0 audio channels
Hi!
Attached patch fixes ticket #7979 for me, please comment.
Thank you, Carl Eugen
From 976b294c10be32667852729c3652dbec466ac091 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 1 Jul 2019 00:00:38 +0200
Subject: [PATCH] lavf/rawenc: Do not allow encoding 0 audio channels.
Fixes ticket #7979.
---
libavformat/rawenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/rawenc.c b/libavformat/rawenc.c
index 993d232b70..0d00e5a0c5 100644
--- a/libavformat/rawenc.c
+++ b/libavformat/rawenc.c
@@ -39,6 +39,10 @@ static int force_one_stream(AVFormatContext *s)
s->oformat->name);
return AVERROR(EINVAL);
}
+if (s->streams[0]->codecpar->channels == 0) {
+av_log(s, AV_LOG_ERROR, "Encoding 0 channels is impossible\n");
+return AVERROR(EINVAL);
+}
return 0;
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/hevc_ps: fix valid range of num_tile_{columns, rows}_minus1
From 7.4.3.3.1:
num_tile_columns_minus1 shall be in the range of 0 to PicWidthInCtbsY - 1,
inclusive.
num_tile_rows_minus1 shall be in the range of 0 to PicHeightInCtbsY - 1,
inclusive.
Signed-off-by: James Almer
---
Sorry for not noticing it when reviewing c692051252 and 3b2082c663.
libavcodec/hevc_ps.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
index f6e80e1609..abf08b919b 100644
--- a/libavcodec/hevc_ps.c
+++ b/libavcodec/hevc_ps.c
@@ -1588,14 +1588,14 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
AVCodecContext *avctx,
int num_tile_rows_minus1= get_ue_golomb(gb);
if (num_tile_columns_minus1 < 0 ||
-num_tile_columns_minus1 >= sps->ctb_width - 1) {
+num_tile_columns_minus1 >= sps->ctb_width) {
av_log(avctx, AV_LOG_ERROR, "num_tile_columns_minus1 out of range:
%d\n",
num_tile_columns_minus1);
ret = num_tile_columns_minus1 < 0 ? num_tile_columns_minus1 :
AVERROR_INVALIDDATA;
goto err;
}
if (num_tile_rows_minus1 < 0 ||
-num_tile_rows_minus1 >= sps->ctb_height - 1) {
+num_tile_rows_minus1 >= sps->ctb_height) {
av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of range:
%d\n",
num_tile_rows_minus1);
ret = num_tile_rows_minus1 < 0 ? num_tile_rows_minus1 :
AVERROR_INVALIDDATA;
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.
Am 30.06.19 um 21:40 schrieb Thilo Borgmann:
> Am 30.06.19 um 19:17 schrieb Moritz Barsnick:
>> On Sun, Jun 30, 2019 at 14:14:13 +0200, Thilo Borgmann wrote:
>>> -{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
>>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
>>> AV_OPT_FLAG_DECODING_PARAM },
>>> -{ "capture_mouse_clicks", "capture the screen mouse clicks",
>>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0,
>>> 1, AV_OPT_FLAG_DECODING_PARAM },
>>> +{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
>>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>>> +{ "capture_mouse_clicks", "capture the screen mouse clicks",
>>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0,
>>> 1, AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
>>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>>
>> Can't you just make the options AV_OPT_TYPE_BOOL? No additional consts
>> requires.
>
> Yes. Changed locally.
Also changed for the new option in patch 4/4, of course.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.
Am 30.06.19 um 19:17 schrieb Moritz Barsnick:
> On Sun, Jun 30, 2019 at 14:14:13 +0200, Thilo Borgmann wrote:
>> -{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM
>> },
>> -{ "capture_mouse_clicks", "capture the screen mouse clicks",
>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
>> AV_OPT_FLAG_DECODING_PARAM },
>> +{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
>> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
>> +{ "capture_mouse_clicks", "capture the screen mouse clicks",
>> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
>> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
>
> Can't you just make the options AV_OPT_TYPE_BOOL? No additional consts
> requires.
Yes. Changed locally.
Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: new interlaced mux mode
On 6/30/19, Marton Balint wrote:
>
>
> On Wed, 26 Jun 2019, Andreas Håkon wrote:
>
>>> > > > -ts_st->payload = av_mallocz(ts->pes_payload_size);
>>> > > > +ts_st->payload = av_mallocz(ts->parallel_mux ?
>>> > > > MAX_PES_PAYLOAD : ts->pes_payload_size);
>>> > >
>>> > > Could you clarify why this needs to be changed?
>>> >
>>> > Sure! Because when you write in parallel you're delaying the writing of
>>> > the PES packet.
>>> > So you need to save the entire PES packet. And the ts->pes_payload_size
>>> > it's defined to
>>> > a very small value (2734 Bytes only)... See at the top of the
>>> > mpegtsenc.c file:
>>> > #define DEFAULT_PES_HEADER_FREQ 16
>>> > #define DEFAULT_PES_PAYLOAD_SIZE ((DEFAULT_PES_HEADER_FREQ - 1) * 184 +
>>> > 170)
>>>
>>> OK, but you shold override ts->pes_payload_size, and not the malloc, no?
>>> There is code in mpegts_init which sets pes_payload_size, you should
>>> force
>>> it to MAX_PES_PAYLOAD there before doing the round up.
>>
>> No, no! If I override the ts->pes_payload_size then when not using the
>> interleaved some unused memory will be allocated.
>> Please note that when using the sequential mode the payload is writed
>> "directly" to the output stream. And this is true with PES packets with
>> a size greater than pes_payload_size (i.e. video). So the
>> ts->pes_payload_size is used only to store small writes until a PES
>> packet is complete. However, when using the interleaved mode the entire
>> PES packet requires to be saved until the last part is writed in the
>> output stream. For this reason the malloc has different values.
>
> I don't understand your reasoning. Sequential mode is not affected if you
> only increase pes_payload_size if parallel mode is used. Is parallel
> mode affected?
>
>>> > > > + for (i = 0; i < ts->nb_services; i++) {
>>> > > > +service = ts->services[i];
>>> > > > ...
>>> > > > }
>>> > > >
>>> > >
>>> > > Why do you need the loop over the services here? It seems unrelated
>>> > > unless
>>> > > I missed something.
>>> >
>>> > I explained it in my original message...
>>> > The current code has a bug and it doesn't set correctly the value of
>>> > the
>>> > service->pcr_pid. And this patch requires correct values of pcr_pid for
>>> > each
>>> > program. Please note that this patch makes complete sense when mixing
>>> > multiple
>>> > video streams, such as when using multiple programs.
>>>
>>> This should be a separate patch then. I suggest implementing this before
>>> adding interleaving support.
>>
>> Yes and not...
>>
>> 1. This interleaved mode requires correct value of the service->pcr_pid,
>> as it have
>> sense with multiple programs. So the "patch" here is mandatory. We can
>> assume that
>> it's part of the new mux mode.
>>
>> 2. With the sequential mode, the service->pcr_pid bug is hidden, because
>> no one uses
>> multiple programs. So a lot of work for me for an irrelevant fix.
>>
>> So I'd prefer to just comment here, and make it all one single change.
>
> We generally split features to different patches to make patch review
> easier. Or to put it in a different way, your patch has bigger chance to
> be reviewed and merged if it touches a single feature.
>
> I see no reason why one couldn't use multiple programs in sequential mode
> so it totally makes sense to implement it, and then implement parallel
> mode on top of that as a separete patch.
>
>>
>>
>>> > > > + - NOTE: 'payload' contains a complete PES payload.
>>> > > > + - NOTE2: When 'mode' < -1 it writes the rest of the payload
>>> > > > (without header);
>>> > > > + - When 'mode' = -1 it writes the entire payload with
>>> > > > the header;
>>> > > > + - when 'mode' = 0 it writes only one TS packet with
>>> > > > the header;
>>> > > > + - when 'mode' > 0 it writes only one TS packet.
>>> > > >
>>> > >
>>> > > Enum for mode would make more sense to me
>>> >
>>> > Yes and not. The code is more compact in this case with numerical
>>> > values, as you
>>> > don't need to do checks when you call to the function.
>>>
>>> The code might be more compact, and tons of less readable. Use enums, or
>>> defines. You might also use flags for mode, if that makes the code more
>>> readable.
>>
>>
>> I'm sorry, no. In my opinion it's more legible and compact like that.
>> I accept all your comments, and I appreciate them. But in this case I do
>> not
>> see the advantage.
>
> I disagree. Based on your code the 4 modes do this:
>
> < -1 = 0
>-1 = WRITE_HEADER
> 0 = WRITE_HEADER | ONE_PACKET_ONLY
>> 0 = ONE_PACKET_ONLY
>
> You documented the meaning of the "modes" in two places and created two
> helper functions to make sure you pass the correct modes to the underlying
> function. Why is that if not because you can't seem to remember yourself
> the meaning of modes? Please reconsider using defines or enums.
>
Hardcoded values are unacceptable. Every such patch will not be applied
and if
Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: new interlaced mux mode
On Wed, 26 Jun 2019, Andreas Håkon wrote:
> > > -ts_st->payload = av_mallocz(ts->pes_payload_size);
> > > +ts_st->payload = av_mallocz(ts->parallel_mux ? MAX_PES_PAYLOAD
: ts->pes_payload_size);
> >
> > Could you clarify why this needs to be changed?
>
> Sure! Because when you write in parallel you're delaying the writing of the
PES packet.
> So you need to save the entire PES packet. And the ts->pes_payload_size it's
defined to
> a very small value (2734 Bytes only)... See at the top of the mpegtsenc.c
file:
> #define DEFAULT_PES_HEADER_FREQ 16
> #define DEFAULT_PES_PAYLOAD_SIZE ((DEFAULT_PES_HEADER_FREQ - 1) * 184 + 170)
OK, but you shold override ts->pes_payload_size, and not the malloc, no?
There is code in mpegts_init which sets pes_payload_size, you should force
it to MAX_PES_PAYLOAD there before doing the round up.
No, no! If I override the ts->pes_payload_size then when not using the
interleaved some unused memory will be allocated.
Please note that when using the sequential mode the payload is writed
"directly" to the output stream. And this is true with PES packets with
a size greater than pes_payload_size (i.e. video). So the
ts->pes_payload_size is used only to store small writes until a PES
packet is complete. However, when using the interleaved mode the entire
PES packet requires to be saved until the last part is writed in the
output stream. For this reason the malloc has different values.
I don't understand your reasoning. Sequential mode is not affected if you
only increase pes_payload_size if parallel mode is used. Is parallel
mode affected?
> > > + for (i = 0; i < ts->nb_services; i++) {
> > > +service = ts->services[i];
> > > ...
> > > }
> > >
> >
> > Why do you need the loop over the services here? It seems unrelated unless
> > I missed something.
>
> I explained it in my original message...
> The current code has a bug and it doesn't set correctly the value of the
> service->pcr_pid. And this patch requires correct values of pcr_pid for each
> program. Please note that this patch makes complete sense when mixing multiple
> video streams, such as when using multiple programs.
This should be a separate patch then. I suggest implementing this before
adding interleaving support.
Yes and not...
1. This interleaved mode requires correct value of the service->pcr_pid, as it
have
sense with multiple programs. So the "patch" here is mandatory. We can assume
that
it's part of the new mux mode.
2. With the sequential mode, the service->pcr_pid bug is hidden, because no one
uses
multiple programs. So a lot of work for me for an irrelevant fix.
So I'd prefer to just comment here, and make it all one single change.
We generally split features to different patches to make patch review
easier. Or to put it in a different way, your patch has bigger chance to
be reviewed and merged if it touches a single feature.
I see no reason why one couldn't use multiple programs in sequential mode
so it totally makes sense to implement it, and then implement parallel
mode on top of that as a separete patch.
> > > + - NOTE: 'payload' contains a complete PES payload.
> > > + - NOTE2: When 'mode' < -1 it writes the rest of the payload
(without header);
> > > + - When 'mode' = -1 it writes the entire payload with the
header;
> > > + - when 'mode' = 0 it writes only one TS packet with the
header;
> > > + - when 'mode' > 0 it writes only one TS packet.
> > >
> >
> > Enum for mode would make more sense to me
>
> Yes and not. The code is more compact in this case with numerical values, as
you
> don't need to do checks when you call to the function.
The code might be more compact, and tons of less readable. Use enums, or
defines. You might also use flags for mode, if that makes the code more
readable.
I'm sorry, no. In my opinion it's more legible and compact like that.
I accept all your comments, and I appreciate them. But in this case I do not
see the advantage.
I disagree. Based on your code the 4 modes do this:
< -1 = 0
-1 = WRITE_HEADER
0 = WRITE_HEADER | ONE_PACKET_ONLY
0 = ONE_PACKET_ONLY
You documented the meaning of the "modes" in two places and created two
helper functions to make sure you pass the correct modes to the underlying
function. Why is that if not because you can't seem to remember yourself
the meaning of modes? Please reconsider using defines or enums.
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/4] lavd/avfoundation: Add human readable option arguments.
On Sun, Jun 30, 2019 at 14:14:13 +0200, Thilo Borgmann wrote:
> -{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM
> },
> -{ "capture_mouse_clicks", "capture the screen mouse clicks",
> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
> capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM,
> "capture_cursor" },
> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
> AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
> +{ "capture_mouse_clicks", "capture the screen mouse clicks",
> offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
> +{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
> +{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
> AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
Can't you just make the options AV_OPT_TYPE_BOOL? No additional consts
requires.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter: add deesser audio filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 36 ++
libavfilter/Makefile | 1 +
libavfilter/af_deesser.c | 240 +++
libavfilter/allfilters.c | 1 +
4 files changed, 278 insertions(+)
create mode 100644 libavfilter/af_deesser.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 2d9af46a6b..8cca5d008a 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3045,6 +3045,42 @@ Optional. It should have a value much less than 1 (e.g.
0.05 or 0.02) and is
used to prevent clipping.
@end table
+@section deesser
+
+Apply de-essing to the audio samples.
+
+@table @option
+@item i
+Set intensity for triggering de-essing. Allowed range is from 0 to 1.
+Default is 0.
+
+@item m
+Set amount of ducking on treble part of sound. Allowed range is from 0 to 1.
+Default is 0.5.
+
+@item f
+How much of original frequency content to keep when de-essing. Allowed range
is from 0 to 1.
+Default is 0.5.
+
+@item s
+Set the output mode.
+
+It accepts the following values:
+@table @option
+@item i
+Pass input unchanged.
+
+@item o
+Pass ess filtered out.
+
+@item e
+Pass only ess.
+
+Default value is @var{o}.
+@end table
+
+@end table
+
@section drmeter
Measure audio dynamic range.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 07ea8d7edc..455c809b15 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -101,6 +101,7 @@ OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER) +=
af_compensationdelay.o
OBJS-$(CONFIG_CROSSFEED_FILTER) += af_crossfeed.o
OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
+OBJS-$(CONFIG_DEESSER_FILTER)+= af_deesser.o
OBJS-$(CONFIG_DRMETER_FILTER)+= af_drmeter.o
OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
diff --git a/libavfilter/af_deesser.c b/libavfilter/af_deesser.c
new file mode 100644
index 00..1775dc7d4c
--- /dev/null
+++ b/libavfilter/af_deesser.c
@@ -0,0 +1,240 @@
+/*
+ * Copyright (c) 2018 Chris Johnson
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+#include "libavutil/channel_layout.h"
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "audio.h"
+#include "formats.h"
+
+typedef struct DeesserChannel {
+double s1, s2, s3;
+double m1, m2;
+double ratioA, ratioB;
+double iirSampleA, iirSampleB;
+int flip;
+} DeesserChannel;
+
+typedef struct DeesserContext {
+const AVClass *class;
+
+double intensity;
+double max;
+double frequency;
+intmode;
+
+DeesserChannel *chan;
+} DeesserContext;
+
+enum OutModes {
+IN_MODE,
+OUT_MODE,
+ESS_MODE,
+NB_MODES
+};
+
+#define OFFSET(x) offsetof(DeesserContext, x)
+#define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption deesser_options[] = {
+{ "i", "set intensity",OFFSET(intensity), AV_OPT_TYPE_DOUBLE,
{.dbl=0.0}, 0.0, 1.0, A },
+{ "m", "set max deessing", OFFSET(max), AV_OPT_TYPE_DOUBLE,
{.dbl=0.5}, 0.0, 1.0, A },
+{ "f", "set frequency",OFFSET(frequency), AV_OPT_TYPE_DOUBLE,
{.dbl=0.5}, 0.0, 1.0, A },
+{ "s", "set output mode", OFFSET(mode), AV_OPT_TYPE_INT,
{.i64=OUT_MODE}, 0, NB_MODES-1, A, "mode" },
+{ "i", "input", 0, AV_OPT_TYPE_CONST,
{.i64=IN_MODE}, 0, 0, A, "mode" },
+{ "o", "output", 0, AV_OPT_TYPE_CONST,
{.i64=OUT_MODE}, 0, 0, A, "mode" },
+{ "e", "ess", 0, AV_OPT_TYPE_CONST,
{.i64=ESS_MODE}, 0, 0, A, "mode" },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(deesser);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats = NULL;
+AVFilterChannelLayouts *layouts = NULL;
+static const enum AVSampleFormat sample_fmts[] = {
+
[FFmpeg-devel] [PATCH] avcodec/golomb: Correct the doxy about get_ue_golomb() and errors
Signed-off-by: Michael Niedermayer
---
libavcodec/golomb.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index fcc78f44c1..5cdfa0945d 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -49,6 +49,8 @@ extern const uint8_t
ff_interleaved_dirac_golomb_vlc_code[256];
/**
* Read an unsigned Exp-Golomb code in the range 0 to 8190.
+ *
+ * @returns the read value or a negative error code.
*/
static inline int get_ue_golomb(GetBitContext *gb)
{
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/hevc_ps: Change num_tile_rows/columns checks to sps->ctb_height/weight
On Tue, Jun 25, 2019 at 10:32:55AM -0300, James Almer wrote:
> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
> > Suggested-by: James Almer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/hevc_ps.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> > index 07d220a5c8..f6e80e1609 100644
> > --- a/libavcodec/hevc_ps.c
> > +++ b/libavcodec/hevc_ps.c
> > @@ -1588,14 +1588,14 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> > AVCodecContext *avctx,
> > int num_tile_rows_minus1= get_ue_golomb(gb);
> >
> > if (num_tile_columns_minus1 < 0 ||
> > -num_tile_columns_minus1 >= sps->width - 1) {
> > +num_tile_columns_minus1 >= sps->ctb_width - 1) {
> > av_log(avctx, AV_LOG_ERROR, "num_tile_columns_minus1 out of
> > range: %d\n",
> > num_tile_columns_minus1);
> > ret = num_tile_columns_minus1 < 0 ? num_tile_columns_minus1 :
> > AVERROR_INVALIDDATA;
> > goto err;
> > }
> > if (num_tile_rows_minus1 < 0 ||
> > -num_tile_rows_minus1 >= sps->height - 1) {
> > +num_tile_rows_minus1 >= sps->ctb_height - 1) {
> > av_log(avctx, AV_LOG_ERROR, "num_tile_rows_minus1 out of
> > range: %d\n",
> > num_tile_rows_minus1);
> > ret = num_tile_rows_minus1 < 0 ? num_tile_rows_minus1 :
> > AVERROR_INVALIDDATA;
> >
>
> LGTM
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
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 1/2] avcodec/hevc_ps: Fix integer overflow with num_tile_rows and num_tile_columns
On Wed, Jun 26, 2019 at 10:29:05AM -0300, James Almer wrote:
> On 6/26/2019 9:41 AM, Michael Niedermayer wrote:
> > On Tue, Jun 25, 2019 at 10:30:45AM -0300, James Almer wrote:
> >> On 6/25/2019 5:55 AM, Michael Niedermayer wrote:
> >>> Fixes: signed integer overflow: -2147483648 - 1 cannot be represented in
> >>> type 'int'
> >>> Fixes:
> >>> 14880/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5130977304641536
> >>>
> >>> Found-by: continuous fuzzing process
> >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>> libavcodec/hevc_ps.c | 23 +--
> >>> libavcodec/hevc_ps.h | 4 ++--
> >>> 2 files changed, 15 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/libavcodec/hevc_ps.c b/libavcodec/hevc_ps.c
> >>> index 80df417e4f..07d220a5c8 100644
> >>> --- a/libavcodec/hevc_ps.c
> >>> +++ b/libavcodec/hevc_ps.c
> >>> @@ -1584,22 +1584,25 @@ int ff_hevc_decode_nal_pps(GetBitContext *gb,
> >>> AVCodecContext *avctx,
> >>> pps->entropy_coding_sync_enabled_flag = get_bits1(gb);
> >>>
> >>> if (pps->tiles_enabled_flag) {
> >>> -pps->num_tile_columns = get_ue_golomb_long(gb) + 1;
> >>> -pps->num_tile_rows= get_ue_golomb_long(gb) + 1;
> >>> -if (pps->num_tile_columns <= 0 ||
> >>> -pps->num_tile_columns >= sps->width) {
> >>> +int num_tile_columns_minus1 = get_ue_golomb(gb);
> >>> +int num_tile_rows_minus1= get_ue_golomb(gb);
> >>> +
> >>> +if (num_tile_columns_minus1 < 0 ||
> >>
> >> num_tile_columns_minus1 can never be < 0 for an int now that you're
> >> using get_ue_golomb(gb). It returns values from 0 to 8190.
> >> Add an av_assert0, at most. A value < 0 would mean there's a huge bug in
> >> golomb.h, and not invalid bitstream data.
> >>
> >> And since you got rid of the "- 1" calculation below, which was your
> >> original concern, you could also just make this unsigned. There's really
> >> no need for an int at all.
> >
> > If you look at get_ue_golomb() in golomb.h
> > static inline int get_ue_golomb(GetBitContext *gb)
> > ...
> > there is a case that does:
> > return AVERROR_INVALIDDATA;
> >
> > That is a negative value an should be checked for before
> > truncating to uint8_t. There is no gurantee that error codes
> > when cast to uint8_t would not map to valid values.
>
> I had not seen that. The doxy for the function mentioned the valid range
> it can return, but made no mention of the chance for an AVERROR* value.
>
> int is ok and the patch should be good, then. Sorry for the noise.
>
> Any opinion about the struct field size? Is uint8_t enough? Your
> original suggestion of uint16_t may be a safer bet, as i mentioned.
> Looking at CBS Mark limited these fields to the max allowed value level
> 6.2 allows for them (20 and 22), but we're not doing that here, so
> num_tile_[cols,rows}_minus1 could in theory and in some extreme cases go
> beyond 255.
ok, will apply with uint16_t
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowflake in an avalanche ever feels responsible. -- Voltaire
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/apedec: Add k < 24 check to the only k++ case which lacks such a check
On Sun, Jun 16, 2019 at 11:56:59AM +0200, Michael Niedermayer wrote: > Fixes: > 15255/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5718831688843264 > Fixes: left shift of 1 by 31 places cannot be represented in type 'int' > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/apedec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope 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] avformat/aviobuf: Delay buffer downsizing until asserts are met
On Sun, Jun 30, 2019 at 01:07:00PM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Jun 17, 2019 at 11:12:00PM +, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> Fixes: Assertion failure
> >>> Fixes:
> >>> 15151/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5757079496687616
> >>>
> >>> Signed-off-by: Michael Niedermayer
> >>> ---
> >>> libavformat/aviobuf.c | 3 +--
> >>> 1 file changed, 1 insertion(+), 2 deletions(-)
> >>>
> >>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> >>> index 5a33f82950..6a5cd97b0a 100644
> >>> --- a/libavformat/aviobuf.c
> >>> +++ b/libavformat/aviobuf.c
> >>> @@ -570,7 +570,7 @@ static void fill_buffer(AVIOContext *s)
> >>> }
> >>>
> >>> /* make buffer smaller in case it ended up large after probing */
> >>> -if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> >>> s->orig_buffer_size) {
> >>> +if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> >>> s->orig_buffer_size && len >= s->orig_buffer_size) {
> >>> if (dst == s->buffer && s->buf_ptr != dst) {
> >>> int ret = ffio_set_buf_size(s, s->orig_buffer_size);
> >>> if (ret < 0)
> >>> @@ -578,7 +578,6 @@ static void fill_buffer(AVIOContext *s)
> >>>
> >>> s->checksum_ptr = dst = s->buffer;
> >>> }
> >>> -av_assert0(len >= s->orig_buffer_size);
> >>> len = s->orig_buffer_size;
> >>> }
> >>>
> >>>
> >> I just noticed that ticket #7094 is about this assert. Could you test
> >> whether everything works fine with your fix applied (and then mention
> >> said this ticket in the commit message)?
> >
> > The ticket does not contain a full testcase, just a code snippet,
> > and the person reporting the issue has not yet replied
> > I suggest we apply this fix with a "May fix Ticket7094"
> >
> >
> Agreed.
will apply
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
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] Add DICOM Support
On 6/29/19 3:39 AM, Paul B Mahol wrote: On 6/29/19, Michael Niedermayer wrote: On Fri, Jun 28, 2019 at 02:02:29PM +0530, Shivam wrote: On 6/27/19 9:21 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: On 6/26/19 4:37 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: On 6/26/19, Michael Niedermayer wrote: On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: On 6/25/19 2:12 AM, Michael Niedermayer wrote: On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: Hi! The code is to add DICOM Support. The patch is only for uncompressed dicom files using explicit value representation. I would extend it, once i clarify some doubts. As dicom image files contain lots of metadata about the patient. So, should i display that data while demuxing or should i ignore and only demux the image data ?. In the current patch, i have made an option "-metadata", which when used will print the data on the terminal while demuxing. metadata should be exported to be usable by applications. For teh API design a one test is that it should be possible to have a dicom file as input and a format with similar features as output and not loose any significant data. Printing to the terminal cannot achieve that easily. So, should i export it to a csv file ? does it fit into the metadata system we have ? To clarify, you mean frame metadata system? data that is specific to a frame would belong in the frame metadata data that is specific to a stream would belong into that streams metadata data that is specific to the container would belong to its metadata iam not sure if multiple streams or frames can be in a single dicom "container" / file. If they can then it should be clear what goes where if not then all 3 options would from the point of view of dicom be the same. And in that case what is most convenient for interoperation with other formats should be picked. That is lets introduce the least amount of differences to how similar data is handled in other formats Dicom files contain multiple frames, but number of streams is always one (video) like GIF,( I haven't done multiframe support yet i am working on it ), The data specific to image/frames/pixels can be fit in the three categories of our metadata system, but their is extradata in DICOM files like : patient_name, medical_device_name , medical_procedure_done, study_date why could this not be fit in metadata ? Yeah this can fit in the key, value pair of our AVDictionaryEntry (and can be written with "-f ffmetadata"). So, should i assign this to streams metadata or containers metadata as this data is not stream specific or container specific ?. whatever paul preferrs, if he has an oppinion on it. Otherwise choose what feels better to you. Depends where is metadata stored, if its on container level, then obviously as stream metadata, otherwise as frame metadata. Ok, Thank You Shivam Goyal ___ 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 DICOM Support
On 6/29/19 3:35 AM, Michael Niedermayer wrote: On Fri, Jun 28, 2019 at 02:02:29PM +0530, Shivam wrote: On 6/27/19 9:21 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 11:33:05PM +0530, Shivam wrote: On 6/26/19 4:37 PM, Michael Niedermayer wrote: On Wed, Jun 26, 2019 at 09:54:56AM +0200, Paul B Mahol wrote: On 6/26/19, Michael Niedermayer wrote: On Tue, Jun 25, 2019 at 01:52:09PM +0530, Shivam wrote: On 6/25/19 2:12 AM, Michael Niedermayer wrote: On Mon, Jun 24, 2019 at 09:18:13PM +0530, Shivam wrote: Hi! The code is to add DICOM Support. The patch is only for uncompressed dicom files using explicit value representation. I would extend it, once i clarify some doubts. As dicom image files contain lots of metadata about the patient. So, should i display that data while demuxing or should i ignore and only demux the image data ?. In the current patch, i have made an option "-metadata", which when used will print the data on the terminal while demuxing. metadata should be exported to be usable by applications. For teh API design a one test is that it should be possible to have a dicom file as input and a format with similar features as output and not loose any significant data. Printing to the terminal cannot achieve that easily. So, should i export it to a csv file ? does it fit into the metadata system we have ? To clarify, you mean frame metadata system? data that is specific to a frame would belong in the frame metadata data that is specific to a stream would belong into that streams metadata data that is specific to the container would belong to its metadata iam not sure if multiple streams or frames can be in a single dicom "container" / file. If they can then it should be clear what goes where if not then all 3 options would from the point of view of dicom be the same. And in that case what is most convenient for interoperation with other formats should be picked. That is lets introduce the least amount of differences to how similar data is handled in other formats Dicom files contain multiple frames, but number of streams is always one (video) like GIF,( I haven't done multiframe support yet i am working on it ), The data specific to image/frames/pixels can be fit in the three categories of our metadata system, but their is extradata in DICOM files like : patient_name, medical_device_name , medical_procedure_done, study_date why could this not be fit in metadata ? Yeah this can fit in the key, value pair of our AVDictionaryEntry (and can be written with "-f ffmetadata"). So, should i assign this to streams metadata or containers metadata as this data is not stream specific or container specific ?. whatever paul preferrs, if he has an oppinion on it. Otherwise choose what feels better to you. Ok, Thank You, Shivam Goyal ___ 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/aviobuf: Delay buffer downsizing until asserts are met
Michael Niedermayer:
> On Mon, Jun 17, 2019 at 11:12:00PM +, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> Fixes: Assertion failure
>>> Fixes:
>>> 15151/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5757079496687616
>>>
>>> Signed-off-by: Michael Niedermayer
>>> ---
>>> libavformat/aviobuf.c | 3 +--
>>> 1 file changed, 1 insertion(+), 2 deletions(-)
>>>
>>> diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
>>> index 5a33f82950..6a5cd97b0a 100644
>>> --- a/libavformat/aviobuf.c
>>> +++ b/libavformat/aviobuf.c
>>> @@ -570,7 +570,7 @@ static void fill_buffer(AVIOContext *s)
>>> }
>>>
>>> /* make buffer smaller in case it ended up large after probing */
>>> -if (s->read_packet && s->orig_buffer_size && s->buffer_size >
>>> s->orig_buffer_size) {
>>> +if (s->read_packet && s->orig_buffer_size && s->buffer_size >
>>> s->orig_buffer_size && len >= s->orig_buffer_size) {
>>> if (dst == s->buffer && s->buf_ptr != dst) {
>>> int ret = ffio_set_buf_size(s, s->orig_buffer_size);
>>> if (ret < 0)
>>> @@ -578,7 +578,6 @@ static void fill_buffer(AVIOContext *s)
>>>
>>> s->checksum_ptr = dst = s->buffer;
>>> }
>>> -av_assert0(len >= s->orig_buffer_size);
>>> len = s->orig_buffer_size;
>>> }
>>>
>>>
>> I just noticed that ticket #7094 is about this assert. Could you test
>> whether everything works fine with your fix applied (and then mention
>> said this ticket in the commit message)?
>
> The ticket does not contain a full testcase, just a code snippet,
> and the person reporting the issue has not yet replied
> I suggest we apply this fix with a "May fix Ticket7094"
>
>
Agreed.
- 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] avformat/aviobuf: Delay buffer downsizing until asserts are met
On Mon, Jun 17, 2019 at 11:12:00PM +, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: Assertion failure
> > Fixes:
> > 15151/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5757079496687616
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/aviobuf.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
> > index 5a33f82950..6a5cd97b0a 100644
> > --- a/libavformat/aviobuf.c
> > +++ b/libavformat/aviobuf.c
> > @@ -570,7 +570,7 @@ static void fill_buffer(AVIOContext *s)
> > }
> >
> > /* make buffer smaller in case it ended up large after probing */
> > -if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> > s->orig_buffer_size) {
> > +if (s->read_packet && s->orig_buffer_size && s->buffer_size >
> > s->orig_buffer_size && len >= s->orig_buffer_size) {
> > if (dst == s->buffer && s->buf_ptr != dst) {
> > int ret = ffio_set_buf_size(s, s->orig_buffer_size);
> > if (ret < 0)
> > @@ -578,7 +578,6 @@ static void fill_buffer(AVIOContext *s)
> >
> > s->checksum_ptr = dst = s->buffer;
> > }
> > -av_assert0(len >= s->orig_buffer_size);
> > len = s->orig_buffer_size;
> > }
> >
> >
> I just noticed that ticket #7094 is about this assert. Could you test
> whether everything works fine with your fix applied (and then mention
> said this ticket in the commit message)?
The ticket does not contain a full testcase, just a code snippet,
and the person reporting the issue has not yet replied
I suggest we apply this fix with a "May fix Ticket7094"
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
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/fitsdec: Check data_min/max
On Tue, Jun 25, 2019 at 12:05:19PM +0200, Michael Niedermayer wrote: > Fixes: division by 0 > Fixes: > 15206/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FITS_fuzzer-5657260212092928 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/fitsdec.c | 8 > 1 file changed, 8 insertions(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org 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] lavd/avfoundation: Support muxed type of devices
$SUBJECT
-Thilo
From 3287fbbcbf625a8eebf3aac17871836a6f28c824 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 30 Jun 2019 14:01:56 +0200
Subject: [PATCH 4/4] lavd/avfoundation: Support muxed type of devices
including raw muxed data capture.
---
libavdevice/avfoundation.m | 91 +-
1 file changed, 82 insertions(+), 9 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 5dd6ea5..715b7b3 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -97,6 +97,8 @@ typedef struct
int capture_cursor;
int capture_mouse_clicks;
+int capture_raw_data;
+int video_is_muxed;
int list_devices;
int video_device_index;
@@ -291,6 +293,10 @@ static int configure_video_device(AVFormatContext *s,
AVCaptureDevice *video_dev
NSObject *selected_range = nil;
NSObject *selected_format = nil;
+// try to configure format by formats list
+// might raise an exception if no format list is given
+// (then fallback to default, no configuration)
+@try {
for (format in [video_device valueForKey:@"formats"]) {
CMFormatDescriptionRef formatDescription;
CMVideoDimensions dimensions;
@@ -324,19 +330,29 @@ static int configure_video_device(AVFormatContext *s,
AVCaptureDevice *video_dev
if (!selected_range) {
av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by
the device.\n",
framerate);
+if (ctx->video_is_muxed) {
+av_log(s, AV_LOG_ERROR, "Falling back to default.\n");
+} else {
goto unsupported_format;
+}
}
if ([video_device lockForConfiguration:NULL] == YES) {
+if (selected_format) {
+[video_device setValue:selected_format forKey:@"activeFormat"];
+}
+if (selected_range) {
NSValue *min_frame_duration = [selected_range
valueForKey:@"minFrameDuration"];
-
-[video_device setValue:selected_format forKey:@"activeFormat"];
[video_device setValue:min_frame_duration
forKey:@"activeVideoMinFrameDuration"];
[video_device setValue:min_frame_duration
forKey:@"activeVideoMaxFrameDuration"];
+}
} else {
av_log(s, AV_LOG_ERROR, "Could not lock device for configuration.\n");
return AVERROR(EINVAL);
}
+} @catch(NSException *e) {
+av_log(ctx, AV_LOG_WARNING, "Configuration of video device failed,
falling back to default.\n");
+}
return 0;
@@ -468,12 +484,18 @@ static int add_video_device(AVFormatContext *s,
AVCaptureDevice *video_device)
}
}
+// set videoSettings to an empty dict for receiving raw data of muxed
devices
+if (ctx->capture_raw_data) {
+ctx->pixel_format = pxl_fmt_spec.ff_id;
+ctx->video_output.videoSettings = @{ };
+} else {
ctx->pixel_format = pxl_fmt_spec.ff_id;
pixel_format = [NSNumber numberWithUnsignedInt:pxl_fmt_spec.avf_id];
capture_dict = [NSDictionary dictionaryWithObject:pixel_format
forKey:(id)kCVPixelBufferPixelFormatTypeKey];
[ctx->video_output setVideoSettings:capture_dict];
+}
[ctx->video_output setAlwaysDiscardsLateVideoFrames:YES];
ctx->avf_delegate = [[AVFFrameReceiver alloc] initWithContext:ctx];
@@ -540,6 +562,7 @@ static int get_video_config(AVFormatContext *s)
{
AVFContext *ctx = (AVFContext*)s->priv_data;
CVImageBufferRef image_buffer;
+CMBlockBufferRef block_buffer;
CGSize image_buffer_size;
AVStream* stream = avformat_new_stream(s, NULL);
@@ -558,14 +581,22 @@ static int get_video_config(AVFormatContext *s)
avpriv_set_pts_info(stream, 64, 1, avf_time_base);
-image_buffer = CMSampleBufferGetImageBuffer(ctx->current_frame);
-image_buffer_size = CVImageBufferGetEncodedSize(image_buffer);
+image_buffer = CMSampleBufferGetImageBuffer(ctx->current_frame);
+block_buffer = CMSampleBufferGetDataBuffer(ctx->current_frame);
+
+if (image_buffer) {
+image_buffer_size = CVImageBufferGetEncodedSize(image_buffer);
stream->codecpar->codec_id = AV_CODEC_ID_RAWVIDEO;
stream->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
stream->codecpar->width = (int)image_buffer_size.width;
stream->codecpar->height = (int)image_buffer_size.height;
stream->codecpar->format = ctx->pixel_format;
+} else {
+stream->codecpar->codec_id = AV_CODEC_ID_DVVIDEO;
+stream->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+stream->codecpar->format = ctx->pixel_format;
+}
CFRelease(ctx->current_frame);
ctx->current_frame = nil;
@@ -670,8 +701,9 @@ static int avf_read_header(AVFormatContext *s)
AVCaptureDevice *audio_device = nil;
// Find capture device
NSArray *devices =
[FFmpeg-devel] [PATCH 3/4] lavd/avfoundation: Refine some log messages.
$SUBJECT
-Thilo
From 312df3342b98fd805c3bda584de88b261a59329e Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 30 Jun 2019 14:00:42 +0200
Subject: [PATCH 3/4] lavd/avfoundation: Refine some log messages.
---
libavdevice/avfoundation.m | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 0ce0a37..5dd6ea5 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -316,13 +316,13 @@ static int configure_video_device(AVFormatContext *s,
AVCaptureDevice *video_dev
}
if (!selected_format) {
-av_log(s, AV_LOG_ERROR, "Selected video size (%dx%d) is not supported
by the device\n",
+av_log(s, AV_LOG_ERROR, "Selected video size (%dx%d) is not supported
by the device.\n",
ctx->width, ctx->height);
goto unsupported_format;
}
if (!selected_range) {
-av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by
the device\n",
+av_log(s, AV_LOG_ERROR, "Selected framerate (%f) is not supported by
the device.\n",
framerate);
goto unsupported_format;
}
@@ -334,7 +334,7 @@ static int configure_video_device(AVFormatContext *s,
AVCaptureDevice *video_dev
[video_device setValue:min_frame_duration
forKey:@"activeVideoMinFrameDuration"];
[video_device setValue:min_frame_duration
forKey:@"activeVideoMaxFrameDuration"];
} else {
-av_log(s, AV_LOG_ERROR, "Could not lock device for configuration");
+av_log(s, AV_LOG_ERROR, "Could not lock device for configuration.\n");
return AVERROR(EINVAL);
}
@@ -908,7 +908,7 @@ static int copy_cvpixelbuffer(AVFormatContext *s,
status = CVPixelBufferLockBaseAddress(image_buffer, 0);
if (status != kCVReturnSuccess) {
-av_log(s, AV_LOG_ERROR, "Could not lock base address: %d\n", status);
+av_log(s, AV_LOG_ERROR, "Could not lock base address: %d (%dx%d)\n",
status, width, height);
return AVERROR_EXTERNAL;
}
--
1.8.3.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".
[FFmpeg-devel] [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.
$SUBJECT
-Thilo
From 4e39cb25ac2dd75899989d87ac48cc55293db515 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 30 Jun 2019 13:57:54 +0200
Subject: [PATCH 2/4] lavd/avfoundation: Add human readable option arguments.
---
libavdevice/avfoundation.m | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 88fe050..0ce0a37 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -1064,8 +1064,12 @@ static const AVOption options[] = {
{ "pixel_format", "set pixel format", offsetof(AVFContext, pixel_format),
AV_OPT_TYPE_PIXEL_FMT, {.i64 = AV_PIX_FMT_YUV420P}, 0, INT_MAX,
AV_OPT_FLAG_DECODING_PARAM},
{ "framerate", "set frame rate", offsetof(AVFContext, framerate),
AV_OPT_TYPE_VIDEO_RATE, {.str = "ntsc"}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM
},
{ "video_size", "set video size", offsetof(AVFContext, width),
AV_OPT_TYPE_IMAGE_SIZE, {.str = NULL}, 0, 0, AV_OPT_FLAG_DECODING_PARAM },
-{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM },
-{ "capture_mouse_clicks", "capture the screen mouse clicks",
offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
AV_OPT_FLAG_DECODING_PARAM },
+{ "capture_cursor", "capture the screen cursor", offsetof(AVFContext,
capture_cursor), AV_OPT_TYPE_INT, {.i64=0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM,
"capture_cursor" },
+{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
+{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
AV_OPT_FLAG_DECODING_PARAM, "capture_cursor" },
+{ "capture_mouse_clicks", "capture the screen mouse clicks",
offsetof(AVFContext, capture_mouse_clicks), AV_OPT_TYPE_INT, {.i64=0}, 0, 1,
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
+{ "true", "", 0, AV_OPT_TYPE_CONST, {.i64=1}, 0, 0,
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
+{ "false", "", 0, AV_OPT_TYPE_CONST, {.i64=0}, 0, 0,
AV_OPT_FLAG_DECODING_PARAM, "capture_mouse_clicks" },
{ NULL },
};
--
1.8.3.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 1/4] lavd/avfoundation: Remove useless index increment.
including patch...
From 4b85b80cdbf3c5e041eab3b5d1171c0ff3f913ad Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 30 Jun 2019 13:56:08 +0200
Subject: [PATCH 1/4] lavd/avfoundation: Remove useless index increment.
---
libavdevice/avfoundation.m | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 98552ac..88fe050 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -690,7 +690,6 @@ static int avf_read_header(AVFormatContext *s)
const char *name = [[device localizedName] UTF8String];
index= [devices indexOfObject:device];
av_log(ctx, AV_LOG_INFO, "[%d] %s\n", index, name);
-index++;
}
#if !TARGET_OS_IPHONE && __MAC_OS_X_VERSION_MIN_REQUIRED >= 1070
if (num_screens > 0) {
--
1.8.3.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".
[FFmpeg-devel] [PATCH 1/4] lavd/avfoundation: Remove useless index increment.
$SUBJECT -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 0/4] lavd/avfoundation: Support muxed device types
Hi, some cleanup and $SUBJECT. Documentation and reindent follows afterwards. Thanks, Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] JPEG2000 multiple SOC and SIZ
When I truncate the packet at next SOC, I get: [jpeg2000 @ 0x55ce0298aa40] SIZ [jpeg2000 @ 0x55ce0298aa40] SIZ width=2056 height=2168 tile_width=2056 tile_height=2168 tile_offset_x=0 tile_offset_y=0 xtiles=1 ytiles=1 [jpeg2000 @ 0x55ce0298aa40] SIZ Rsiz=0x8040 2056 2168 [jpeg2000 @ 0x55ce0298aa40] POC [jpeg2000 @ 0x55ce0298aa40] unsupported marker 0xFF79 at pos 0x70 [jpeg2000 @ 0x55ce0298aa40] COD [jpeg2000 @ 0x55ce0298aa40] extra cblk styles E [jpeg2000 @ 0x55ce0298aa40] QCD [jpeg2000 @ 0x55ce0298aa40] SOT Last message repeated 3 times [jpeg2000 @ 0x55ce0298aa40] Psot 1451180 too big [jpeg2000 @ 0x55ce0298aa40] error during processing marker segment ff90 Moreover, in both SIZes, tile offsets are 0, I can't get the idea how the file should be handled correctly. file: https://www.file-up.org/niuxrl31dyij fmpeg commits are attached вс, 30 июн. 2019 г. в 15:17, Paul B Mahol : > On 6/30/19, Anton Novikov wrote: > > Hi everyone, > > I'm reversing the recent version of r3d file format, and have > encountered a > > JPEG2000-related thing. > > I've got a memory dump of something that seems to be JPEG2000, and > modified > > ffmpeg to consume it. The log follows: > > [r3d @ 0x558d304077c0] test > > [r3d @ 0x558d304077c0] error reading end atom > > Input #0, r3d, from '/home/anek/src/red/frame2.without0.r3d': > > Duration: N/A, bitrate: N/A > > Stream #0:0: Video: jpeg2000, bayer_rggb16le, 8192x4320, 24 fps, 24 > > tbr, 134286336 tbn, 134286336 tbc > > Metadata: > > filename: ? > > File 'frame.jpg' already exists. Overwrite ? [y/N] y > > Stream mapping: > > Stream #0:0 -> #0:0 (jpeg2000 (native) -> mjpeg (native)) > > Press [q] to stop, [?] for help > > Truncating packet of size 9496960 to 7595371 > > /home/anek/src/red/frame2.without0.r3d: corrupt input packet in stream 0 > > /home/anek/src/red/frame2.without0.r3d: Operation not permitted > > [jpeg2000 @ 0x558d3041c280] SIZ > > [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 > > [jpeg2000 @ 0x558d3041c280] POC > > [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x70 > > [jpeg2000 @ 0x558d3041c280] COD > > [jpeg2000 @ 0x558d3041c280] extra cblk styles E > > [jpeg2000 @ 0x558d3041c280] QCD > > [jpeg2000 @ 0x558d3041c280] SOT > > Last message repeated 3 times > > [jpeg2000 @ 0x558d3041c280] Duplicate SOC at 3821997=0x3A51AD > > [jpeg2000 @ 0x558d3041c280] SIZ > > [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 > > [jpeg2000 @ 0x558d3041c280] POC > > [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x3A5203 > > [jpeg2000 @ 0x558d3041c280] COD > > [jpeg2000 @ 0x558d3041c280] extra cblk styles E > > [jpeg2000 @ 0x558d3041c280] QCD > > [jpeg2000 @ 0x558d3041c280] SOT > > Last message repeated 3 times > > [jpeg2000 @ 0x558d3041c280] Progression order RPCL > > Last message repeated 3 times > > [swscaler @ 0x558d30425900] deprecated pixel format used, make sure you > did > > set range correctly > > [mjpeg @ 0x558d3040e780] removing common factors from framerate > > Output #0, image2, to 'frame.jpg': > > Metadata: > > encoder : Lavf58.27.103 > > Stream #0:0: Video: mjpeg, yuvj444p(pc), 2056x2168, q=2-31, 200 kb/s, > > 24 fps, 24 tbn, 24 tbc > > Metadata: > > filename: ? > > encoder : Lavc58.52.102 mjpeg > > Side data: > > cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1 > > [image2 @ 0x558d3040abc0] Application provided invalid, non monotonically > > increasing dts to muxer in stream 0: 101000 >= 0 > > /home/anek/src/red/frame2.without0.r3d: Operation not permitted > > frame=1 fps=0.4 q=2.9 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= > > 0x > > video:96kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > > muxing overhead: unknown > > > > picture dimensions are 8192x4320, but in JPEG2000 bytestream there are 2 > > SOC and SIZ markers with SIZ mentioning 2056x2168. The image is decoded, > > but colors and area are wrong. What can I do? > > Make sure it uses tiles (each jpeg2000 is special tile) and that your > packet is trimmed. > ___ > 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". From ce21789b0da6e7f16c21ea33dcf67586b32630bd Mon Sep 17 00:00:00 2001 From: Anek Date: Sun, 30 Jun 2019 16:32:21 +0500 Subject: [PATCH 2/2] jpeg2000 decoding dbginfo --- libavcodec/jpeg2000dec.c | 43 +++- 1 file changed, 34 insertions(+), 9 deletions(-) diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c index a40726f4b8..5de7e042c6 100644 --- a/libavcodec/jpeg2000dec.c +++ b/libavcodec/jpeg2000dec.c @@ -1907,9 +1907,10 @@ next_marker: marker = bytestream2_get_be16u(>g); oldpos = bytestream2_tell(>g); - if (marker == JPEG2000_SOC) - goto
Re: [FFmpeg-devel] JPEG2000 multiple SOC and SIZ
On 6/30/19, Anton Novikov wrote: > Hi everyone, > I'm reversing the recent version of r3d file format, and have encountered a > JPEG2000-related thing. > I've got a memory dump of something that seems to be JPEG2000, and modified > ffmpeg to consume it. The log follows: > [r3d @ 0x558d304077c0] test > [r3d @ 0x558d304077c0] error reading end atom > Input #0, r3d, from '/home/anek/src/red/frame2.without0.r3d': > Duration: N/A, bitrate: N/A > Stream #0:0: Video: jpeg2000, bayer_rggb16le, 8192x4320, 24 fps, 24 > tbr, 134286336 tbn, 134286336 tbc > Metadata: > filename: ? > File 'frame.jpg' already exists. Overwrite ? [y/N] y > Stream mapping: > Stream #0:0 -> #0:0 (jpeg2000 (native) -> mjpeg (native)) > Press [q] to stop, [?] for help > Truncating packet of size 9496960 to 7595371 > /home/anek/src/red/frame2.without0.r3d: corrupt input packet in stream 0 > /home/anek/src/red/frame2.without0.r3d: Operation not permitted > [jpeg2000 @ 0x558d3041c280] SIZ > [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 > [jpeg2000 @ 0x558d3041c280] POC > [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x70 > [jpeg2000 @ 0x558d3041c280] COD > [jpeg2000 @ 0x558d3041c280] extra cblk styles E > [jpeg2000 @ 0x558d3041c280] QCD > [jpeg2000 @ 0x558d3041c280] SOT > Last message repeated 3 times > [jpeg2000 @ 0x558d3041c280] Duplicate SOC at 3821997=0x3A51AD > [jpeg2000 @ 0x558d3041c280] SIZ > [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 > [jpeg2000 @ 0x558d3041c280] POC > [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x3A5203 > [jpeg2000 @ 0x558d3041c280] COD > [jpeg2000 @ 0x558d3041c280] extra cblk styles E > [jpeg2000 @ 0x558d3041c280] QCD > [jpeg2000 @ 0x558d3041c280] SOT > Last message repeated 3 times > [jpeg2000 @ 0x558d3041c280] Progression order RPCL > Last message repeated 3 times > [swscaler @ 0x558d30425900] deprecated pixel format used, make sure you did > set range correctly > [mjpeg @ 0x558d3040e780] removing common factors from framerate > Output #0, image2, to 'frame.jpg': > Metadata: > encoder : Lavf58.27.103 > Stream #0:0: Video: mjpeg, yuvj444p(pc), 2056x2168, q=2-31, 200 kb/s, > 24 fps, 24 tbn, 24 tbc > Metadata: > filename: ? > encoder : Lavc58.52.102 mjpeg > Side data: > cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1 > [image2 @ 0x558d3040abc0] Application provided invalid, non monotonically > increasing dts to muxer in stream 0: 101000 >= 0 > /home/anek/src/red/frame2.without0.r3d: Operation not permitted > frame=1 fps=0.4 q=2.9 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= > 0x > video:96kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB > muxing overhead: unknown > > picture dimensions are 8192x4320, but in JPEG2000 bytestream there are 2 > SOC and SIZ markers with SIZ mentioning 2056x2168. The image is decoded, > but colors and area are wrong. What can I do? Make sure it uses tiles (each jpeg2000 is special tile) and that your packet is trimmed. ___ 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] JPEG2000 multiple SOC and SIZ
Hi everyone, I'm reversing the recent version of r3d file format, and have encountered a JPEG2000-related thing. I've got a memory dump of something that seems to be JPEG2000, and modified ffmpeg to consume it. The log follows: [r3d @ 0x558d304077c0] test [r3d @ 0x558d304077c0] error reading end atom Input #0, r3d, from '/home/anek/src/red/frame2.without0.r3d': Duration: N/A, bitrate: N/A Stream #0:0: Video: jpeg2000, bayer_rggb16le, 8192x4320, 24 fps, 24 tbr, 134286336 tbn, 134286336 tbc Metadata: filename: ? File 'frame.jpg' already exists. Overwrite ? [y/N] y Stream mapping: Stream #0:0 -> #0:0 (jpeg2000 (native) -> mjpeg (native)) Press [q] to stop, [?] for help Truncating packet of size 9496960 to 7595371 /home/anek/src/red/frame2.without0.r3d: corrupt input packet in stream 0 /home/anek/src/red/frame2.without0.r3d: Operation not permitted [jpeg2000 @ 0x558d3041c280] SIZ [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 [jpeg2000 @ 0x558d3041c280] POC [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x70 [jpeg2000 @ 0x558d3041c280] COD [jpeg2000 @ 0x558d3041c280] extra cblk styles E [jpeg2000 @ 0x558d3041c280] QCD [jpeg2000 @ 0x558d3041c280] SOT Last message repeated 3 times [jpeg2000 @ 0x558d3041c280] Duplicate SOC at 3821997=0x3A51AD [jpeg2000 @ 0x558d3041c280] SIZ [jpeg2000 @ 0x558d3041c280] SIZ Rsiz=0x8040 2056 2168 [jpeg2000 @ 0x558d3041c280] POC [jpeg2000 @ 0x558d3041c280] unsupported marker 0xFF79 at pos 0x3A5203 [jpeg2000 @ 0x558d3041c280] COD [jpeg2000 @ 0x558d3041c280] extra cblk styles E [jpeg2000 @ 0x558d3041c280] QCD [jpeg2000 @ 0x558d3041c280] SOT Last message repeated 3 times [jpeg2000 @ 0x558d3041c280] Progression order RPCL Last message repeated 3 times [swscaler @ 0x558d30425900] deprecated pixel format used, make sure you did set range correctly [mjpeg @ 0x558d3040e780] removing common factors from framerate Output #0, image2, to 'frame.jpg': Metadata: encoder : Lavf58.27.103 Stream #0:0: Video: mjpeg, yuvj444p(pc), 2056x2168, q=2-31, 200 kb/s, 24 fps, 24 tbn, 24 tbc Metadata: filename: ? encoder : Lavc58.52.102 mjpeg Side data: cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: -1 [image2 @ 0x558d3040abc0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 101000 >= 0 /home/anek/src/red/frame2.without0.r3d: Operation not permitted frame=1 fps=0.4 q=2.9 Lsize=N/A time=00:00:00.00 bitrate=N/A speed= 0x video:96kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: unknown picture dimensions are 8192x4320, but in JPEG2000 bytestream there are 2 SOC and SIZ markers with SIZ mentioning 2056x2168. The image is decoded, but colors and area are wrong. What can I do? Thanks, Anton ___ 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".
