Re: [FFmpeg-devel] [PATCH] libavformat/mpegtsenc: fix incorrect PCR with multiple programs
Ping ‐‐‐ Original Message ‐‐‐ On Monday, 22 de July de 2019 14:22, Andreas Håkon wrote: > Hi, > > Based on the discussion of my previous patch > https://patchwork.ffmpeg.org/patch/13487/ > Here I publish a first part of the patch that only addresses the PCR problem. > > This supersedes too: https://patchwork.ffmpeg.org/patch/13745/ Waiting for comments or acceptance. https://trac.ffmpeg.org/ticket/8039 Regards. A.H. --- ___ 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/assdec: undefined use of memcpy()
On 7/24/19, Michael Niedermayer wrote: > Fixes: null pointer passed as argument 2, which is declared to never be null > Fixes: > 16008/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SSA_fuzzer-5650582821404672 > (this is a separate issue found in this testcase) > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/assdec.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/assdec.c b/libavcodec/assdec.c > index 3178f2953c..f0b1069cd2 100644 > --- a/libavcodec/assdec.c > +++ b/libavcodec/assdec.c > @@ -31,7 +31,8 @@ static av_cold int ass_decode_init(AVCodecContext *avctx) > avctx->subtitle_header = av_malloc(avctx->extradata_size + 1); > if (!avctx->subtitle_header) > return AVERROR(ENOMEM); > -memcpy(avctx->subtitle_header, avctx->extradata, > avctx->extradata_size); > +if (avctx->extradata_size) > +memcpy(avctx->subtitle_header, avctx->extradata, > avctx->extradata_size); > avctx->subtitle_header[avctx->extradata_size] = 0; > avctx->subtitle_header_size = avctx->extradata_size; > 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". i guess it is fine ___ 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 for IPC SHM
On 7/23/19, aran.clau...@wwu.edu wrote:
> From: Chad Fraleigh
>>
>> On 7/22/2019 11:14 AM, aran.clau...@wwu.edu wrote:
>>
>>> +static void rm_shmid(AVFormatContext *s) {
>>> +XCBGrabContext *c = s->priv_data;
>>> +if(c->shmid != -1) {
>>> + shmctl(c->shmid, IPC_RMID, 0);
>>> + c->shmid == -1;
>> ^^
>> Assignment/compare operator mismatch.
>>
>>
>>> +}
>>> +}
>>> +
>
> Well, that's embarrassing.
Do not simply concat your patch to rest of mail.
Please use git format-patch and then attach it to new mail.
Or use git send-email.
>
> diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
> index b7e689343e..1acf3cdf28 100644
> --- a/libavdevice/xcbgrab.c
> +++ b/libavdevice/xcbgrab.c
> @@ -75,6 +75,7 @@ typedef struct XCBGrabContext {
> const char *framerate;
>
> int has_shm;
> +int shmid;
> } XCBGrabContext;
>
> #define FOLLOW_CENTER -1
> @@ -221,6 +222,14 @@ static int check_shm(xcb_connection_t *conn)
> return 0;
> }
>
> +static void rm_shmid(AVFormatContext *s) {
> +XCBGrabContext *c = s->priv_data;
> +if(c->shmid != -1) {
> + shmctl(c->shmid, IPC_RMID, 0);
> + c->shmid = -1;
> +}
> +}
> +
> static int allocate_shm(AVFormatContext *s)
> {
> XCBGrabContext *c = s->priv_data;
> @@ -230,7 +239,8 @@ static int allocate_shm(AVFormatContext *s)
>
> if (c->buffer)
> return 0;
> -id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
> +
> +id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0666);
> if (id == -1) {
> char errbuf[1024];
> int err = AVERROR(errno);
> @@ -239,15 +249,20 @@ static int allocate_shm(AVFormatContext *s)
> size, errbuf);
> return err;
> }
> +
> xcb_shm_attach(c->conn, c->segment, id, 0);
> data = shmat(id, NULL, 0);
> -shmctl(id, IPC_RMID, 0);
> -if ((intptr_t)data == -1 || !data)
> -return AVERROR(errno);
> +
> +if ((intptr_t)data == -1 || !data) {
> + shmctl(id, IPC_RMID, 0);
> + return AVERROR(errno);
> +}
> c->buffer = data;
> +c->shmid = id;
> return 0;
> }
>
> +
> static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
> {
> XCBGrabContext *c = s->priv_data;
> @@ -268,6 +283,8 @@ static int xcbgrab_frame_shm(AVFormatContext *s,
> AVPacket *pkt)
>
> xcb_flush(c->conn);
>
> +rm_shmid(s);
> +
> if (e) {
> av_log(s, AV_LOG_ERROR,
> "Cannot get the image data "
>
>
>
___
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] IRC disrupts (was: avcodec/rl2: set dimensions)
Lynne (12019-07-23):
> IRC.
Each time I ask where something horrible that causes a flamewar between
developers had been said, I get the same answer: IRC.
I am starting to believe that the problem is IRC.
Has IRC ever been useful for the development of FFmpeg?
I do not know if it has, but I am pretty sure that when the discussion
starts to become unhelpful, IRC makes it ten time worse. The need for
short and fast answers, the lack of threading, the mixed discussions,
the synchronicity: all that make it hard to express things with
subtlety, and makes the bad bits stand out.
For what it is worth, I have observed the same thing on Twitter, for the
same reasons.
Therefore, I would like to give that advice to everybody who hang on
IRC: Whenever you see something hurtful, do not take it personally, say
"STOP" and move the discussion to the mailing list.
And when on the mailing-list, remember: it is not IRC. You are not
required to reply in less than a minute and less than two lines. Take
your time, express your ideas and disagreements with accuracy and
details. It will eventually save time, for you and for everybody.
As for the current issue, I think it would be better if objections, when
they are not about a precise technical issue ("this patch breaks
decoding of file X"), were constructive.
In other words, tell us not only why you dislike these patches, but what
you would do about the issues they fix instead.
Otherwise, it seems like you are despising other people's efforts.
Regards,
--
Nicolas George
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 v5 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
On Wed, Jul 24, 2019 at 01:20:13PM +0300, velocit...@gmail.com wrote: > From: Nick Renieris > > Main image data in DNGs is usually comprised of tiles, each of which is a > Huffman-encoded lossless JPEG. > > Tested for ljpeg regressions with: > `ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi` > `ffmpeg test.avi out.avi` > The modified code in ljpeg_decode_rgb_scan runs without issues. > > Signed-off-by: Nick Renieris > --- > libavcodec/mjpegdec.c | 54 --- > libavcodec/mjpegdec.h | 1 + > 2 files changed, 47 insertions(+), 8 deletions(-) breaks tickets/842/testimgl.jpg should be here: https://trac.ffmpeg.org/raw-attachment/ticket/842/testimgl.jpg thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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 v6 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
configure | 1 +
libavcodec/Makefile | 2 +-
libavcodec/tiff.c | 310 +++-
libavcodec/tiff.h | 2 +
4 files changed, 307 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 5a4f507246..54163822a8 100755
--- a/configure
+++ b/configure
@@ -2813,6 +2813,7 @@ theora_decoder_select="vp3_decoder"
thp_decoder_select="mjpeg_decoder"
tiff_decoder_suggest="zlib lzma"
tiff_encoder_suggest="zlib"
+tiff_decoder_select="mjpeg_decoder"
truehd_decoder_select="mlp_parser"
truehd_encoder_select="lpc audio_frame_queue"
truemotion2_decoder_select="bswapdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fbcc6..f814c69996 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -616,7 +616,7 @@ OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
OBJS-$(CONFIG_TDSC_DECODER)+= tdsc.o
OBJS-$(CONFIG_TIERTEXSEQVIDEO_DECODER) += tiertexseqv.o
-OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o
+OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o mjpegdec.o
OBJS-$(CONFIG_TIFF_ENCODER)+= tiffenc.o rle.o lzwenc.o tiff_data.o
OBJS-$(CONFIG_TMV_DECODER) += tmv.o cga_data.o
OBJS-$(CONFIG_TRUEHD_DECODER) += mlpdec.o mlpdsp.o
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..4f6ba256c6 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -46,6 +46,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +55,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +81,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +93,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,6 +272,9 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
@@ -712,6 +730,203 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut) value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+}
+
+static void dng_blit(TiffContext *s, uint8_t *dst, int dst_stride,
+ const uint8_t *src, int src_stride,
+ int width, int height, int is_u16)
+{
+int line
[FFmpeg-devel] [PATCH v6 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 54 ---
libavcodec/mjpegdec.h | 1 +
2 files changed, 47 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..d622305298 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,26 +1052,36 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
+
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
-
s->restart_count = s->restart_interval;
-av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if (mb_y * s->width % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(&s->gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (!s->bayer || mb_x) {
+pred = left[i];
+} else { /* This path runs only for the first line in bayer
images */
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb_x < width; mb_x++) {
+((uint16_t*)ptr)[2*mb_x + 0] = buffer[mb_x][0];
+
Re: [FFmpeg-devel] Patch for IPC SHM
On Tue, Jul 23, 2019 at 19:23:12 +, aran.clau...@wwu.edu wrote:
Some style nits for a first time contributer:
> +if(c->shmid != -1) {
^ Please stick to the style "if (" (whitespace).
> -id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0777);
> +
> +id = shmget(IPC_PRIVATE, size, IPC_CREAT | 0666);
Is this change required for your fix?
And please don't introduce arbitrary new empty lines and such.
> }
> +
> xcb_shm_attach(c->conn, c->segment, id, 0);
Needless change, please remove.
> }
>
> +
> static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket *pkt)
Needless change, please remove.
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
On Thu, Jul 25, 2019 at 15:12:53 +0300, velocit...@gmail.com wrote:
Nit:
> tiff_decoder_suggest="zlib lzma"
> tiff_encoder_suggest="zlib"
> +tiff_decoder_select="mjpeg_decoder"
> truehd_decoder_select="mlp_parser"
You should pair the new decoder line with the other decoder line, not
place it below the encoder.
> +int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
"is" makes this sound boolean, perhaps better "jpeg_type" or something
like that.
OTOH, I can't find the differentiation between 1 and 2 used anywhere.
> +// Lookup table lookup
> +if (lut) value = lut[value];
You probably need to break the line, according to ffmpeg coding rules.
> +float scale_factor;
> +
> +scale_factor = 1.0 / (s->white_level - s->black_level);
This is promoting the floating point operation to a double precision
operation (significant for some platforms). Either use double variables
in the first place - if the extra precision can be justified - or use
the "f" suffix to the constant: "1.0f".
> +ret = avcodec_receive_frame(s->avctx_mjpeg, s->jpgframe);
> +if (ret < 0) {
> +av_log(avctx, AV_LOG_ERROR, "JPEG decoding error (%d).\n", ret);
I believe the return value can be decoded into a string, e.g. with
av_err2str().
> +/* Copy the outputted tile's pixels from 'jpgframe' to to 'frame' (final
> buffer */
Outputted is not a word. ;-) Don't worry about that, but there's a
duplicate "to" in there, and the bracket is not closed.
> +uint32_t lut_offset = value;
> +uint32_t lut_size = count;
> +uint32_t lut_wanted_size = 1 << s->bpp;
> +if (lut_wanted_size != lut_size)
> +av_log(s->avctx, AV_LOG_WARNING, "DNG contains LUT with invalid
> size (%d), disabling LUT\n", lut_size);
> +else if (lut_offset >= bytestream2_size(&s->gb))
> +av_log(s->avctx, AV_LOG_WARNING, "DNG contains LUT with invalid
> offset (%d), disabling LUT\n", lut_offset);
Nit: the proper format identifier for uint32_t is '"%" PRIu32'. (
> +} else {
> +av_log(avctx, AV_LOG_ERROR, "DNG JPG-compressed
> non-bayer-encoded images are not supported\n");
> +return AVERROR_PATCHWELCOME;
Alternatively (to av_log()) use avpriv_report_missing_feature().
> +}
> +} else if (s->is_tiled) {
> +av_log(avctx, AV_LOG_ERROR, "DNG uncompressed tiled images are
> not supported\n");
> +return AVERROR_PATCHWELCOME;
Ditto.
> +s->jpgframe = av_frame_alloc();
> +if (!s->jpgframe)
> +return AVERROR(ENOMEM);
> +
> +/* Prepare everything needed for JPEG decoding */
> +codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG);
> +if (!codec)
> +return AVERROR_BUG;
> +s->avctx_mjpeg = avcodec_alloc_context3(codec);
> +if (!s->avctx_mjpeg)
> +return AVERROR(ENOMEM);
Don't you need to free s->jpgframe here? (And codec?)
Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
On Thu, Jul 25, 2019 at 15:12:52 +0300, velocit...@gmail.com wrote:
> From: Nick Renieris
Nit:
> -if (s->nb_components != 3 && s->nb_components != 4)
> +if (s->nb_components <= 0 || s->nb_components > 4)
> return AVERROR_INVALIDDATA;
> +
> if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
> return AVERROR_INVALIDDATA;
>
> -
> s->restart_count = s->restart_interval;
Arbitrary addition and removal of newlines.
> +if (mb_y * s->width % s->restart_interval == 0) {
I personally would prefer an extra set of brackets to at least make it
more obvious which operation takes precedence.
Cheers,
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] avcodec/adpcm: add support for 5.1 adpcm ms
Hi, patches attached. 0001-avcodec-adpcm-add-support-for-5.1-ADPCM-MS.patch Description: Binary data 0002-avcodec-adpcm-reindent-after-last-commit.patch Description: Binary data ___ 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/adpcm: add support for 5.1 adpcm ms
On Thu, Jul 25, 2019 at 16:19:19 +0200, Paul B Mahol wrote:
> patches attached.
> if (block_predictor > 6) {
> -av_log(avctx, AV_LOG_ERROR, "ERROR: block_predictor[1] =
> %d\n",
> +av_log(avctx, AV_LOG_ERROR, "ERROR: block_predictor[0] =
> %d\n",
> block_predictor);
This is not a reindent. ;-)
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/adpcm: add support for 5.1 adpcm ms
On 7/25/19, Moritz Barsnick wrote:
> On Thu, Jul 25, 2019 at 16:19:19 +0200, Paul B Mahol wrote:
>> patches attached.
>
>> if (block_predictor > 6) {
>> -av_log(avctx, AV_LOG_ERROR, "ERROR: block_predictor[1] =
>> %d\n",
>> +av_log(avctx, AV_LOG_ERROR, "ERROR: block_predictor[0] =
>> %d\n",
>> block_predictor);
>
> This is not a reindent. ;-)
It is. Look more carefully.
You need brain to look too.
___
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] AAC LC playback issue
Hi, I apologize for reporting a bug here but since your Trac instance doesn't send verification mails for the account I created, I can't use Trac and was advised on IRC to report my bug here. The file hosted there: https://cloud.igalia.com/index.php/s/GpHxzsfMRbsXJfB doesn't play well with ffplay, the sound is heavily distorded. The same issue happens when ffmpeg's AAC decoder is used in a GStreamer pipeline. The issue doesn't happen if the ffmpeg AAC decoder is swaped with the fdkaac decoder. I've tried the latest release and a git master snapshot. Attaching report log for git master. Philippe ffplay started on 2019-07-25 at 16:17:05 Report written to "ffplay-20190725-161705.log" Command line: ./ffplay /tmp/SourceBuffer-1-audio-0.mp4 ffplay version N-94387-g923d5c489f-1 Copyright (c) 2003-2019 the FFmpeg developers built with gcc 8 (Debian 8.3.0-6) configuration: --prefix=/usr --extra-version=1 --toolchain=hardened --libdir=/usr/lib/x86_64-linux-gnu --incdir=/usr/include/x86_64-linux-gnu --arch=amd64 --enable-gpl --disable-stripping --enable-avresample --disable-filter=resample --enable-avisynth --enable-gnutls --enable-libaom --enable-libass --enable-libbluray --enable-libbs2b --enable-libcaca --enable-libcdio --enable-libcodec2 --enable-libflite --enable-libfontconfig --enable-libfreetype --enable-libfribidi --enable-libgme --enable-libgsm --enable-libjack --enable-libopenjpeg --enable-libopenmpt --enable-libopus --enable-libpulse --enable-librsvg --enable-librubberband --enable-libshine --enable-libsnappy --enable-libsoxr --enable-libspeex --enable-libssh --enable-libtheora --enable-libtwolame --enable-libvidstab --enable-libvorbis --enable-libvpx --enable-libwavpack --enable-libwebp --enable-libx265 --enable-libxml2 --enable-libxvid --enable-libzmq --enable-libzvbi --enable-lv2 --enable-omx libavutil 56. 32.100 / 56. 32.100 libavcodec 58. 55.100 / 58. 55.100 libavformat58. 30.100 / 58. 30.100 libavdevice58. 9.100 / 58. 9.100 libavfilter 7. 58.100 / 7. 58.100 libavresample 4. 0. 0 / 4. 0. 0 libswscale 5. 6.100 / 5. 6.100 libswresample 3. 6.100 / 3. 6.100 libpostproc55. 6.100 / 55. 6.100 Initialized opengl renderer. [NULL @ 0x7f5c64000b80] Opening '/tmp/SourceBuffer-1-audio-0.mp4' for reading [file @ 0x7f5c64001740] Setting default whitelist 'file,crypto' [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] Format mov,mp4,m4a,3gp,3g2,mj2 probed with size=2048 and score=100 nan: 0.000 fd= 0 aq=0KB vq=0KB sq=0B f=0/0 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] ISO: File Type Major Brand: isom [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] Unknown dref type 0x206c7275 size 12 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 480979, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 959187, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] ISO: File Type Major Brand: isom [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] Found duplicated MOOV Atom. Skipped it [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 1439443, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 1918675, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 1440361, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 2398825, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 1440361, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 2398825, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 1440361, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 2879486, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 3358718, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 3838974, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 4318206, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 4799486, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] found tfdt time 5278718, using it for dts [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] Before avformat_find_stream_info() pos: 2396134 bytes read:491520 seeks:14 nb_streams:1 [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] All info found [mov,mp4,m4a,3gp,3g2,mj2 @ 0x7f5c64000b80] After avformat_find_stream_info() pos: 9047 bytes read:524288 seeks:15 frames:1 Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/tmp/SourceBuffer-1-audio-0.mp4': Metadata: creation_time : 1970-01-01T00:00:02.00Z major_brand : isom minor_version : 1 compatible_brands: isomavc1 Duration: 00:01:59.98, start: 10.020396, bitrate: 170 kb/s Stream #0:0(und), 1, 1/48000: Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 160 kb/s (default) Metadata: creation_time : 1970-01-01T00:00:02.00Z ha
[FFmpeg-devel] [PATCH v7 1/2] lavc/mjpegdec: Decode Huffman-coded lossless JPEGs embedded in DNGs
From: Nick Renieris
Main image data in DNGs is usually comprised of tiles, each of which is a
Huffman-encoded lossless JPEG.
Tested for ljpeg regressions with:
`ffmpeg -f lavfi -i testsrc=d=1 -vcodec ljpeg test.avi`
`ffmpeg test.avi out.avi`
The modified code in ljpeg_decode_rgb_scan runs without issues.
Signed-off-by: Nick Renieris
---
libavcodec/mjpegdec.c | 52 +--
libavcodec/mjpegdec.h | 1 +
2 files changed, 46 insertions(+), 7 deletions(-)
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index a65bc8df15..6391107f78 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -412,6 +412,14 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
return AVERROR_PATCHWELCOME;
}
+/* Lossless JPEGs encoded in DNGs are commonly bayer-encoded. They contain
2
+ interleaved components and the width stored in their SOF3 markers is the
+ width of each one. We only output a single component, therefore we need
+ to adjust the output image width. */
+if (s->lossless == 1 && nb_components == 2) {
+s->bayer = 1;
+width *= 2;
+}
/* if different size, realloc/alloc picture */
if (width != s->width || height != s->height || bits != s->bits ||
@@ -488,6 +496,9 @@ int ff_mjpeg_decode_sof(MJpegDecodeContext *s)
}
switch (pix_fmt_id) {
+case 0x: /* for bayer-encoded huffman lossless JPEGs embedded
in DNGs */
+s->avctx->pix_fmt = AV_PIX_FMT_GRAY16LE;
+break;
case 0x1100:
if (s->rgb)
s->avctx->pix_fmt = s->bits <= 9 ? AV_PIX_FMT_BGR24 :
AV_PIX_FMT_BGR48;
@@ -1041,17 +1052,20 @@ static int handle_rstn(MJpegDecodeContext *s, int
nb_components)
return reset;
}
+/* Handles 1 to 4 components */
static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s, int nb_components, int
predictor, int point_transform)
{
int i, mb_x, mb_y;
+unsigned width;
uint16_t (*buffer)[4];
int left[4], top[4], topleft[4];
const int linesize = s->linesize[0];
const int mask = ((1 << s->bits) - 1) << point_transform;
int resync_mb_y = 0;
int resync_mb_x = 0;
+int vpred[6];
-if (s->nb_components != 3 && s->nb_components != 4)
+if (s->nb_components <= 0 || s->nb_components > 4)
return AVERROR_INVALIDDATA;
if (s->v_max != 1 || s->h_max != 1 || !s->lossless)
return AVERROR_INVALIDDATA;
@@ -1059,8 +1073,15 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
s->restart_count = s->restart_interval;
-av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size,
- (unsigned)s->mb_width * 4 * sizeof(s->ljpeg_buffer[0][0]));
+if (s->restart_interval == 0)
+s->restart_interval = INT_MAX;
+
+if (s->bayer)
+width = s->mb_width / nb_components; /* Interleaved, width stored is
the total so need to divide */
+else
+width = s->mb_width;
+
+av_fast_malloc(&s->ljpeg_buffer, &s->ljpeg_buffer_size, width * 4 *
sizeof(s->ljpeg_buffer[0][0]));
if (!s->ljpeg_buffer)
return AVERROR(ENOMEM);
@@ -1078,7 +1099,12 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
for (i = 0; i < 4; i++)
top[i] = left[i] = topleft[i] = buffer[0][i];
-for (mb_x = 0; mb_x < s->mb_width; mb_x++) {
+if ((mb_y * s->width) % s->restart_interval == 0) {
+for (i = 0; i < 6; i++)
+vpred[i] = 1 << (s->bits-1);
+}
+
+for (mb_x = 0; mb_x < width; mb_x++) {
int modified_predictor = predictor;
if (get_bits_left(&s->gb) < 1) {
@@ -1102,12 +1128,19 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
topleft[i] = top[i];
top[i] = buffer[mb_x][i];
-PREDICT(pred, topleft[i], top[i], left[i], modified_predictor);
-
dc = mjpeg_decode_dc(s, s->dc_index[i]);
if(dc == 0xF)
return -1;
+if (!s->bayer || mb_x) {
+pred = left[i];
+} else { /* This path runs only for the first line in bayer
images */
+vpred[i] += dc;
+pred = vpred[i] - dc;
+}
+
+PREDICT(pred, topleft[i], top[i], pred, modified_predictor);
+
left[i] = buffer[mb_x][i] =
mask & (pred + (unsigned)(dc * (1 << point_transform)));
}
@@ -1151,6 +1184,11 @@ static int ljpeg_decode_rgb_scan(MJpegDecodeContext *s,
int nb_components, int p
ptr[3*mb_x + 0] = buffer[mb_x][1] + ptr[3*mb_x + 1];
ptr[3*mb_x + 2] = buffer[mb_x][2] + ptr[3*mb_x + 1];
}
+} else if (s->bayer && nb_components == 2) {
+for (mb_x = 0; mb
[FFmpeg-devel] [PATCH v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
From: Nick Renieris
Used a technique similar to lavc/tdsc.c for invoking the MJPEG decoder.
This commit adds support for:
- DNG tiles
- DNG tile huffman lossless JPEG decoding
- DNG 8-bpp ("packed" as dcraw calls it) decoding
- DNG color scaling [1]
- LinearizationTable tag
- BlackLevel tag
[1]: As specified in the DNG Specification - Chapter 5
Signed-off-by: Nick Renieris
---
configure | 1 +
libavcodec/Makefile | 2 +-
libavcodec/tiff.c | 315 +++-
libavcodec/tiff.h | 2 +
4 files changed, 312 insertions(+), 8 deletions(-)
diff --git a/configure b/configure
index 5a4f507246..6726883d5b 100755
--- a/configure
+++ b/configure
@@ -2811,6 +2811,7 @@ tdsc_decoder_deps="zlib"
tdsc_decoder_select="mjpeg_decoder"
theora_decoder_select="vp3_decoder"
thp_decoder_select="mjpeg_decoder"
+tiff_decoder_select="mjpeg_decoder"
tiff_decoder_suggest="zlib lzma"
tiff_encoder_suggest="zlib"
truehd_decoder_select="mlp_parser"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3cd73fbcc6..f814c69996 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -616,7 +616,7 @@ OBJS-$(CONFIG_TARGA_ENCODER) += targaenc.o rle.o
OBJS-$(CONFIG_TARGA_Y216_DECODER) += targa_y216dec.o
OBJS-$(CONFIG_TDSC_DECODER)+= tdsc.o
OBJS-$(CONFIG_TIERTEXSEQVIDEO_DECODER) += tiertexseqv.o
-OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o
+OBJS-$(CONFIG_TIFF_DECODER)+= tiff.o lzw.o faxcompr.o tiff_data.o
tiff_common.o mjpegdec.o
OBJS-$(CONFIG_TIFF_ENCODER)+= tiffenc.o rle.o lzwenc.o tiff_data.o
OBJS-$(CONFIG_TMV_DECODER) += tmv.o cga_data.o
OBJS-$(CONFIG_TRUEHD_DECODER) += mlpdec.o mlpdsp.o
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index c520d7df83..09cec2 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -35,6 +35,7 @@
#include "libavutil/attributes.h"
#include "libavutil/avstring.h"
+#include "libavutil/error.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/imgutils.h"
#include "libavutil/opt.h"
@@ -46,6 +47,7 @@
#include "mathops.h"
#include "tiff.h"
#include "tiff_data.h"
+#include "mjpegdec.h"
#include "thread.h"
#include "get_bits.h"
@@ -54,6 +56,10 @@ typedef struct TiffContext {
AVCodecContext *avctx;
GetByteContext gb;
+/* JPEG decoding for DNG */
+AVCodecContext *avctx_mjpeg; // wrapper context for MJPEG
+AVFrame *jpgframe; // decoded JPEG tile
+
int get_subimage;
uint16_t get_page;
int get_thumbnail;
@@ -76,7 +82,9 @@ typedef struct TiffContext {
int is_bayer;
uint8_t pattern[4];
+unsigned black_level;
unsigned white_level;
+const uint16_t *dng_lut; // Pointer to DNG linearization table
uint32_t sub_ifd;
uint16_t cur_page;
@@ -86,6 +94,14 @@ typedef struct TiffContext {
int stripsizesoff, stripsize, stripoff, strippos;
LZWState *lzw;
+/* Tile support */
+int is_tiled;
+int tile_byte_counts_offset, tile_offsets_offset;
+int tile_width, tile_length;
+int tile_count;
+
+int is_jpeg;
+
uint8_t *deinvert_buf;
int deinvert_buf_size;
uint8_t *yuv_line;
@@ -257,6 +273,9 @@ static int add_metadata(int count, int type,
};
}
+static void av_always_inline dng_blit(TiffContext *s, uint8_t *dst, int
dst_stride,
+ const uint8_t *src, int src_stride, int
width, int height, int is_u16);
+
static void av_always_inline horizontal_fill(TiffContext *s,
unsigned int bpp, uint8_t* dst,
int usePtr, const uint8_t *src,
@@ -712,6 +731,204 @@ static int tiff_unpack_strip(TiffContext *s, AVFrame *p,
uint8_t *dst, int strid
return 0;
}
+/**
+ * Map stored raw sensor values into linear reference values.
+ * See: DNG Specification - Chapter 5
+ */
+static uint16_t av_always_inline dng_raw_to_linear16(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+// Lookup table lookup
+if (lut)
+value = lut[value];
+
+// Black level subtraction
+value = av_clip_uint16_c((unsigned)value - black_level);
+
+// Color scaling
+value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
0x));
+
+return value;
+}
+
+static uint16_t av_always_inline dng_raw_to_linear8(uint16_t value,
+const uint16_t *lut,
+uint16_t black_level,
+float scale_factor) {
+return dng_raw_to_linear16(value, lut, black_level, scale_factor) >> 8;
+}
+
+static void dng_blit(TiffContext *s,
Re: [FFmpeg-devel] avcodec: add a WavPack DSD decoder
Jul 25, 2019, 6:12 AM by da...@wavpack.com: >>> + crc += (crc << 1) + code; >>> >> Don't NIH CRCs, we have av_crc in lavu. See below how to use it. >> > > It's not a standard crc, but more of a recirculating checksum, so the NIH > code is required. > Could you not call it a CRC then? "checksum" is more appropriate. Wish a CRC was used, its so much better than a checksum and only slightly slower. >>> + frame->nb_samples = s->samples + 1; >>> + if ((ret = ff_get_buffer(avctx, frame, 0)) < 0) >>> + return ret; >>> + frame->nb_samples = s->samples; >>> >> ?. Is the extra sample used as temporary buffer or something? >> > > Your guess is as good as mine. This was part of the code "borrowed" from the > PCM version (with the threading removed) so maybe > there is (or was) a situation that was writing one extra sample off the end. > The code here certainly doesn't, but it seemed > pretty innocuous and I don't like just ripping out things I don't understand. > Just change it and run it through valgrind, I can't see the code using it. Rest looks fine to me. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
Thanks for the review Moritz, pushed fixes.
"outputted" is a word actually :)
https://forum.wordreference.com/threads/is-outputted-a-word.2707379
Στις Πέμ, 25 Ιουλ 2019 στις 4:57 μ.μ., ο/η Moritz Barsnick
έγραψε:
>
> On Thu, Jul 25, 2019 at 15:12:53 +0300, velocit...@gmail.com wrote:
>
> Nit:
>
> > tiff_decoder_suggest="zlib lzma"
> > tiff_encoder_suggest="zlib"
> > +tiff_decoder_select="mjpeg_decoder"
> > truehd_decoder_select="mlp_parser"
>
> You should pair the new decoder line with the other decoder line, not
> place it below the encoder.
>
> > +int is_jpeg; // 0 - Not JPEG, 1 - JPEG, 2 - New JPEG
>
> "is" makes this sound boolean, perhaps better "jpeg_type" or something
> like that.
>
> OTOH, I can't find the differentiation between 1 and 2 used anywhere.
>
> > +// Lookup table lookup
> > +if (lut) value = lut[value];
>
> You probably need to break the line, according to ffmpeg coding rules.
>
> > +float scale_factor;
> > +
> > +scale_factor = 1.0 / (s->white_level - s->black_level);
>
> This is promoting the floating point operation to a double precision
> operation (significant for some platforms). Either use double variables
> in the first place - if the extra precision can be justified - or use
> the "f" suffix to the constant: "1.0f".
>
> > +ret = avcodec_receive_frame(s->avctx_mjpeg, s->jpgframe);
> > +if (ret < 0) {
> > +av_log(avctx, AV_LOG_ERROR, "JPEG decoding error (%d).\n", ret);
>
> I believe the return value can be decoded into a string, e.g. with
> av_err2str().
>
> > +/* Copy the outputted tile's pixels from 'jpgframe' to to 'frame'
> > (final buffer */
>
> Outputted is not a word. ;-) Don't worry about that, but there's a
> duplicate "to" in there, and the bracket is not closed.
>
> > +uint32_t lut_offset = value;
> > +uint32_t lut_size = count;
> > +uint32_t lut_wanted_size = 1 << s->bpp;
> > +if (lut_wanted_size != lut_size)
> > +av_log(s->avctx, AV_LOG_WARNING, "DNG contains LUT with
> > invalid size (%d), disabling LUT\n", lut_size);
> > +else if (lut_offset >= bytestream2_size(&s->gb))
> > +av_log(s->avctx, AV_LOG_WARNING, "DNG contains LUT with
> > invalid offset (%d), disabling LUT\n", lut_offset);
>
> Nit: the proper format identifier for uint32_t is '"%" PRIu32'. (
>
> > +} else {
> > +av_log(avctx, AV_LOG_ERROR, "DNG JPG-compressed
> > non-bayer-encoded images are not supported\n");
> > +return AVERROR_PATCHWELCOME;
>
> Alternatively (to av_log()) use avpriv_report_missing_feature().
>
> > +}
> > +} else if (s->is_tiled) {
> > +av_log(avctx, AV_LOG_ERROR, "DNG uncompressed tiled images are
> > not supported\n");
> > +return AVERROR_PATCHWELCOME;
>
> Ditto.
>
> > +s->jpgframe = av_frame_alloc();
> > +if (!s->jpgframe)
> > +return AVERROR(ENOMEM);
> > +
> > +/* Prepare everything needed for JPEG decoding */
> > +codec = avcodec_find_decoder(AV_CODEC_ID_MJPEG);
> > +if (!codec)
> > +return AVERROR_BUG;
> > +s->avctx_mjpeg = avcodec_alloc_context3(codec);
> > +if (!s->avctx_mjpeg)
> > +return AVERROR(ENOMEM);
>
> Don't you need to free s->jpgframe here? (And codec?)
>
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote: > Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc: > > > > > What did you expect ? IIRC you have asked for whole classes of security > > issues to be not fixed. > > > > Something like that would require a vote and majority of developers. > > > > The way I interpret this: "Of course I ignored you, you're mental!", doesn't > help. And I don't think its just me. You are reading something into this that i have never meant or written > And you do remember incorrectly in saying that I want this whole class of > security issues not fixed. In this thread I specifically raised the issue of > what is considered to be a security issue by asking whether a speedup of > failing to decode from 2 to 0.4 seconds is considered such or what's > considered acceptable in general. > And I think I'll disagree that it is. 16 seconds to 2 seconds I can accept, > but not 2 to 0.4. These durations are the testcases found by the fuzzer, they say nothing about what the worst case for an issue is. The fuzzer builds a testcase trying to exceed a timeout it stops trying to "improve" it once it found something that takes a few seconds. You can in general make these cases significantly longer running. The reason why the fuzzer doesnt produce hour or day long timeouts is just because it doesnt search for anything longer than a few seconds. > > > > >> These patches affect decoding of real world broken files in favor of > >> fixing specially crafted fuzzed files. > >> > > > > Iam happy to look into such cases. Can you provide me with such > > "real world broken files"? > > Its not intended to worsen the output from such files > > > > Simple logical analysis, "if file is somewhat broken, don't try decoding" > does very well indicate that it won't only apply for _this_ broken file, but > in general. > Thus, this is for you to prove. I've said it before that otherwise its a > burden to other developers to have to screen all of these patches. The changes i do in general, i think about potential effects on slightly broken files and try to test with what iam able to find as matching input material. I find it a bit rude from you that you assume i would not already consider this case. Do i never make a mistake ? well i wish so but iam a human. So again if you know of specific cases where theres a problem, tell me about them please > > > > >> Sure, protecting against ddos attacts is important, but not important > >> enough to make decoders give up early and return nothing. Especially in > >> cases where the timeout speedup is of the order of 2s to 400ms. > >> Yet in all of those timeout patches all you've cared about is shutting up > >> the tool. You've never once shown any figures if this could affect > >> decoding, because its a lot harder than just showing they fix something > >> some tool calls a timeout and forgetting about it. You haven't even > >> commented on this when I asked you on IRC. > >> You also sneak this type of patches in when there's an overflow later on > >> during decoding, which is completely incorrect in almost all cases, for > >> the same reason above. > >> > > > > if you know of issues in a patch or commit you should report this > > during patch review or as soon as you find out about the issue > > as a reply to that patch or commit or as mail to the author. > > > > That's what I'm doing. > That aside, you've completely ignored my statements on what's considered > acceptable, showing figures, and sneaking this type of patches to fix > undefined behavior. > Making your reply a simple refutation, rather than addressing anything I've > said. > So I'm asking you again, what is considered a security issue and what is > considered acceptable? And what is considered not a security issue but a > complaint from an overzealous automated tool. undefined behavior is unacceptable. Its not allowed in C. It doesnt matter here if its a security issue or not. Timeouts can in general be used for denial of service attacks. While this is less critical than many other security issues it is a security issue. Also for Timeouts many point to bugs, to missing end of input checks, to missing checks in or before loops, to missing EOF checks, to missing checks that the input actually contains enough data resembling a fraction of the smallest half valid frame. We can spend many hours and days arguing if a issue is critical enough to be a security issue. maybe the one we would look at is not but then i still would try to fix it. If we dont fix one it will block the fuzzer from finding another timeout issue in the same decoder. And that one could be security relevant. So fixing as many as possible is the awnser here too About the fuzzer, if it reports a timeout then there is a timeout, if it reports undefined behavior then there is undefined behavior. Always ? no, it contained bugs but that is rather uncommon. Also the fuzzer has no mercy with you, you
Re: [FFmpeg-devel] [PATCH] avcodec/rl2: set dimensions
On 7/25/19, Michael Niedermayer wrote: > On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote: >> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc: >> >> > >> > What did you expect ? IIRC you have asked for whole classes of security >> > issues to be not fixed. >> > >> > Something like that would require a vote and majority of developers. >> > >> >> The way I interpret this: "Of course I ignored you, you're mental!", >> doesn't help. And I don't think its just me. > > You are reading something into this that i have never meant or written > > >> And you do remember incorrectly in saying that I want this whole class of >> security issues not fixed. In this thread I specifically raised the issue >> of what is considered to be a security issue by asking whether a speedup >> of failing to decode from 2 to 0.4 seconds is considered such or what's >> considered acceptable in general. >> And I think I'll disagree that it is. 16 seconds to 2 seconds I can >> accept, but not 2 to 0.4. > > These durations are the testcases found by the fuzzer, they say nothing > about > what the worst case for an issue is. > The fuzzer builds a testcase trying to exceed a timeout it stops trying to > "improve" it once it found something that takes a few seconds. > > You can in general make these cases significantly longer running. > > The reason why the fuzzer doesnt produce hour or day long timeouts is just > because > it doesnt search for anything longer than a few seconds. > > >> >> >> >> >> These patches affect decoding of real world broken files in favor of >> >> fixing specially crafted fuzzed files. >> >> >> > >> > Iam happy to look into such cases. Can you provide me with such >> > "real world broken files"? >> > Its not intended to worsen the output from such files >> > >> >> Simple logical analysis, "if file is somewhat broken, don't try decoding" >> does very well indicate that it won't only apply for _this_ broken file, >> but in general. >> Thus, this is for you to prove. I've said it before that otherwise its a >> burden to other developers to have to screen all of these patches. > > The changes i do in general, i think about potential effects on > slightly broken files and try to test with what iam able to find as > matching > input material. > I find it a bit rude from you that you assume i would not already consider > this > case. > Do i never make a mistake ? well i wish so but iam a human. So again if you > know of specific cases where theres a problem, tell me about them please > > >> >> >> >> >> Sure, protecting against ddos attacts is important, but not important >> >> enough to make decoders give up early and return nothing. Especially in >> >> cases where the timeout speedup is of the order of 2s to 400ms. >> >> Yet in all of those timeout patches all you've cared about is shutting >> >> up the tool. You've never once shown any figures if this could affect >> >> decoding, because its a lot harder than just showing they fix something >> >> some tool calls a timeout and forgetting about it. You haven't even >> >> commented on this when I asked you on IRC. >> >> You also sneak this type of patches in when there's an overflow later >> >> on during decoding, which is completely incorrect in almost all cases, >> >> for the same reason above. >> >> >> > >> > if you know of issues in a patch or commit you should report this >> > during patch review or as soon as you find out about the issue >> > as a reply to that patch or commit or as mail to the author. >> > >> >> That's what I'm doing. >> That aside, you've completely ignored my statements on what's considered >> acceptable, showing figures, and sneaking this type of patches to fix >> undefined behavior. >> Making your reply a simple refutation, rather than addressing anything >> I've said. >> So I'm asking you again, what is considered a security issue and what is >> considered acceptable? And what is considered not a security issue but a >> complaint from an overzealous automated tool. > > undefined behavior is unacceptable. Its not allowed in C. It doesnt matter > here if its a security issue or not. > > Timeouts can in general be used for denial of service attacks. While this > is less critical than many other security issues it is a security issue. > Also for Timeouts many point to bugs, to missing end of input checks, to > missing > checks in or before loops, to missing EOF checks, to missing checks that > the input actually contains enough data resembling a fraction of the > smallest > half valid frame. > > We can spend many hours and days arguing if a issue is critical enough to > be > a security issue. maybe the one we would look at is not but then i still > would > try to fix it. > If we dont fix one it will block the fuzzer from finding another timeout > issue in the same decoder. And that one could be security relevant. > So fixing as many as possible is the awnser here too > > About the fuzzer, if it reports a timeout then there is a timeout, > if it
Re: [FFmpeg-devel] IRC disrupts (was: avcodec/rl2: set dimensions)
On 7/25/19, Nicolas George wrote: > Lynne (12019-07-23): >> IRC. > > Each time I ask where something horrible that causes a flamewar between > developers had been said, I get the same answer: IRC. > > I am starting to believe that the problem is IRC. I'm starting to believe its problem in certain developer(s). *hint* *hint* ___ 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/rl2: set dimensions
Jul 25, 2019, 4:47 PM by mich...@niedermayer.cc: > On Wed, Jul 24, 2019 at 02:42:24PM +0200, Lynne wrote: > >> Jul 24, 2019, 11:08 AM by mich...@niedermayer.cc: >> >> > >> > What did you expect ? IIRC you have asked for whole classes of security >> > issues to be not fixed. >> > >> > Something like that would require a vote and majority of developers. >> > >> >> The way I interpret this: "Of course I ignored you, you're mental!", doesn't >> help. And I don't think its just me. >> > > You are reading something into this that i have never meant or written > > >> And you do remember incorrectly in saying that I want this whole class of >> security issues not fixed. In this thread I specifically raised the issue of >> what is considered to be a security issue by asking whether a speedup of >> failing to decode from 2 to 0.4 seconds is considered such or what's >> considered acceptable in general. >> And I think I'll disagree that it is. 16 seconds to 2 seconds I can accept, >> but not 2 to 0.4. >> > > These durations are the testcases found by the fuzzer, they say nothing about > what the worst case for an issue is. > The fuzzer builds a testcase trying to exceed a timeout it stops trying to > "improve" it once it found something that takes a few seconds. > > You can in general make these cases significantly longer running. > > The reason why the fuzzer doesnt produce hour or day long timeouts is just > because > it doesnt search for anything longer than a few seconds. > > >> >> >> >> >> These patches affect decoding of real world broken files in favor of >> >> fixing specially crafted fuzzed files. >> >> >> > >> > Iam happy to look into such cases. Can you provide me with such >> > "real world broken files"? >> > Its not intended to worsen the output from such files >> > >> >> Simple logical analysis, "if file is somewhat broken, don't try decoding" >> does very well indicate that it won't only apply for _this_ broken file, but >> in general. >> Thus, this is for you to prove. I've said it before that otherwise its a >> burden to other developers to have to screen all of these patches. >> > > The changes i do in general, i think about potential effects on > slightly broken files and try to test with what iam able to find as matching > input material. > I find it a bit rude from you that you assume i would not already consider > this > case. > Do i never make a mistake ? well i wish so but iam a human. So again if you > know of specific cases where theres a problem, tell me about them please > I told you its up to you to find them. I am sorry if I was rude however none of your timeout patches have shown any lenience, regardless of how short of a timeout they addressed. As such, I can't help but feel like you've never thought of what the side effects of the patches were. Just that the fuzzer's random opinion on what a timeout is was more important. >> >> Sure, protecting against ddos attacts is important, but not important >> >> enough to make decoders give up early and return nothing. Especially in >> >> cases where the timeout speedup is of the order of 2s to 400ms. >> >> Yet in all of those timeout patches all you've cared about is shutting up >> >> the tool. You've never once shown any figures if this could affect >> >> decoding, because its a lot harder than just showing they fix something >> >> some tool calls a timeout and forgetting about it. You haven't even >> >> commented on this when I asked you on IRC. >> >> You also sneak this type of patches in when there's an overflow later on >> >> during decoding, which is completely incorrect in almost all cases, for >> >> the same reason above. >> >> >> > >> > if you know of issues in a patch or commit you should report this >> > during patch review or as soon as you find out about the issue >> > as a reply to that patch or commit or as mail to the author. >> > >> >> That's what I'm doing. >> That aside, you've completely ignored my statements on what's considered >> acceptable, showing figures, and sneaking this type of patches to fix >> undefined behavior. >> Making your reply a simple refutation, rather than addressing anything I've >> said. >> So I'm asking you again, what is considered a security issue and what is >> considered acceptable? And what is considered not a security issue but a >> complaint from an overzealous automated tool. >> > > undefined behavior is unacceptable. Its not allowed in C. It doesnt matter > here if its a security issue or not. > > Timeouts can in general be used for denial of service attacks. While this > is less critical than many other security issues it is a security issue. > Also for Timeouts many point to bugs, to missing end of input checks, to > missing > checks in or before loops, to missing EOF checks, to missing checks that > the input actually contains enough data resembling a fraction of the smallest > half valid frame. > > We can spend many hours and days arguing if a issue is
Re: [FFmpeg-devel] [PATCH] Setup for extracting quantization parameters from encoded streams
I submitted another patch in a new email thread addressing your concerns, apologies for the confusion. The subject is "[PATCH] Extract QP from h264 encoded videos". Here is the link to the archive http://ffmpeg.org/pipermail/ffmpeg-devel/2019-July/247037.html ___ 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/adpcm: add support for 5.1 adpcm ms
> > This is not a reindent. ;-) > It is. Look more carefully. > You need brain to look too. Sorry, I see it now. The indent, I mean, not the brain, which is not there. Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Extract QP from h264 encoded videos
On Wed, Jul 24, 2019 at 12:18:59PM -0700, Juan De León wrote:
> ---
> libavcodec/avcodec.h| 1 +
> libavcodec/h264dec.c| 37
> libavcodec/options_table.h | 1 +
> libavutil/Makefile | 2 +
> libavutil/frame.h | 6 ++
> libavutil/quantization_params.c | 40 +
> libavutil/quantization_params.h | 102
the changes to libavutil and libavcodec should be in separate patches
> 7 files changed, 189 insertions(+)
> create mode 100644 libavutil/quantization_params.c
> create mode 100644 libavutil/quantization_params.h
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index d234271c5b..9e3185720a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2671,6 +2671,7 @@ typedef struct AVCodecContext {
> #endif
> #define FF_DEBUG_BUFFERS 0x8000
> #define FF_DEBUG_THREADS 0x0001
> +#define FF_DEBUG_EXTRACTQP 0x0002
> #define FF_DEBUG_GREEN_MD0x0080
> #define FF_DEBUG_NOMC0x0100
>
> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> index 8d1bd16a8e..07b85f4e0a 100644
> --- a/libavcodec/h264dec.c
> +++ b/libavcodec/h264dec.c
> @@ -33,6 +33,7 @@
> #include "libavutil/opt.h"
> #include "libavutil/stereo3d.h"
> #include "libavutil/timer.h"
> +#include "libavutil/quantization_params.h"
> #include "internal.h"
> #include "bytestream.h"
> #include "cabac.h"
> @@ -922,6 +923,42 @@ static int finalize_frame(H264Context *h, AVFrame *dst,
> H264Picture *out, int *g
> }
> }
>
> +if (h->avctx->debug & FF_DEBUG_EXTRACTQP) {
> +int mb_height = h->height / 16;
> +int mb_width = h->width / 16;
> +int mb_xy = mb_width * mb_height;
> +
> +AVFrameSideData *sd;
> +sd = av_frame_new_side_data(dst, AV_FRAME_DATA_QUANTIZATION_PARAMS,
> + sizeof(AVQuantizationParamsArray));
> +
> +AVQuantizationParamsArray *params;
> +params = (AVQuantizationParamsArray *)sd->data;
> +params->nb_blocks = mb_xy;
> +params->qp_arr = av_malloc_array(mb_xy,
> sizeof(AVQuantizationParams));
> +
> +params->codec_id = h->avctx->codec_id;
missing failure checks for av_frame_new_side_data and av_malloc_array
> +
> +// loop allocate QP
> +int qp_index = 0;
> +for (int mb_y = 0; mb_y < mb_height; mb_y++) {
> +for (int mb_x = 0; mb_x < mb_width; mb_x++) {
> +int qs_index = mb_x + mb_y * h->mb_stride;
> +AVQuantizationParams *qp_block = &(params->qp_arr[qp_index]);
> +
> +qp_block->x = mb_x * 16;
> +qp_block->y = mb_y * 16;
> +qp_block->w = qp_block->h = 16;
> +
> +// ALLOCATE MEMORY TO THE QP ARRAY
> +qp_block->type = av_malloc(QP_TYPE_ARR_SIZE_H264 *
> sizeof(int));
> +qp_block->type[QP_H264] = out->qscale_table[qs_index];
> +
> +qp_index++;
> +}
> +}
> +}
> +
> return 0;
> }
>
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 4a266eca16..e0e78a69c5 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -219,6 +219,7 @@ static const AVOption avcodec_options[] = {
> {"buffers", "picture buffer allocations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_BUFFERS }, INT_MIN, INT_MAX, V|D, "debug"},
> {"thread_ops", "threading operations", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_THREADS }, INT_MIN, INT_MAX, V|A|D, "debug"},
> {"nomc", "skip motion compensation", 0, AV_OPT_TYPE_CONST, {.i64 =
> FF_DEBUG_NOMC }, INT_MIN, INT_MAX, V|A|D, "debug"},
> +{"extractqp", "enable QP extraction per frame", 0, AV_OPT_TYPE_CONST, {.i64
> = FF_DEBUG_EXTRACTQP }, INT_MIN, INT_MAX, V|D, "debug"},
> {"dia_size", "diamond type & size for motion estimation", OFFSET(dia_size),
> AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN, INT_MAX, V|E},
> {"last_pred", "amount of motion predictors from the previous frame",
> OFFSET(last_predictor_count), AV_OPT_TYPE_INT, {.i64 = DEFAULT }, INT_MIN,
> INT_MAX, V|E},
> #if FF_API_PRIVATE_OPT
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 8a7a44e4b5..be1a9c3a9c 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -60,6 +60,7 @@ HEADERS = adler32.h
> \
>pixdesc.h \
>pixelutils.h \
>pixfmt.h \
> + quantization_params.h \
>random_seed.h \
>rc4.h \
>rational.h
Re: [FFmpeg-devel] [PATCH v8] Fix integer parameters size check in SDP fmtp line
On Wed, Jul 24, 2019 at 10:20:14AM +0200, Olivier Maignial wrote: > === PROBLEM === > > I was trying to record h264 + aac streams from an RTSP server to mp4 file. > using this command line: > ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a > aac_adtstoasc test.mp4 > > FFmpeg then fail to record audio and output this logs: > [rtsp @ 0xcda1f0] The profile-level-id field size is invalid (40) > [rtsp @ 0xcda1f0] Error parsing AU headers > ... > [rtsp @ 0xcda1f0] Could not find codec parameters for stream 1 (Audio: > aac, 48000 Hz, 1 channels): unspecified sample format > > In SDP provided by my RTSP server I had this fmtp line: > a=fmtp:98 streamType=5; profile-level-id=40; mode=AAC-hbr; config=1188; > sizeLength=13; indexLength=3; indexDeltaLength=3; > > In FFmpeg code, I found a check introduced by commit > 24130234cd9dd733116d17b724ea4c8e12ce097a. It disallows values greater than 32 > for fmtp line parameters. > RFC-4566 (SDP: Session Description Protocol) do not give any limit of size on > interger parameters given in an fmtp line. > > However, In RFC-6416 (RTP Payload Format for MPEG-4 Audio/Visual Streams) > give examples of "profile-level-id" values for AAC, up to 55. > > === FIX === > > As each parameter may have its own min and max values > I propose to introduce a range for each parameter. > For this patch I used RFC-3640 and ISO/IEC 14496-1 as reference for validity > ranges. > > This patch fix my problem and I now can record my RTSP AAC stream to mp4. > It has passed the full fate tests suite sucessfully. > > Signed-off-by: Olivier Maignial > --- > Changes v7 --> v8: > Indroduced a per parameter validity range thanks, yes this should resolve the issue [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact 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] lafv/wavdec: Fail bext parsing on incomplete reads
From 7966786250d9581891e0859f769a63f35a5c2729 Mon Sep 17 00:00:00 2001
From: Matt Wolenetz
Date: Thu, 25 Jul 2019 15:54:49 -0700
Subject: [PATCH] lafv/wavdec: Fail bext parsing on incomplete reads
avio_read can successfully return even when less than the requested
amount of input was read. wavdec's bext parsing mistakenly assumed a
successful avio_read always read the full amount that was requested.
The result could be dictionary tags populated with partially
uninitialized values.
This change also fixes a broken assertion in wav_parse_bext_string that
was off-by-one, though no known current usage of that method hits that
broken case.
Chromium bug: 987270
Signed-off-by: Matt Wolenetz
---
libavformat/wavdec.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index 1b131ee2c1..684efd97f9 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -233,9 +233,9 @@ static inline int wav_parse_bext_string(AVFormatContext *s, const char *key,
char temp[257];
int ret;
-av_assert0(length <= sizeof(temp));
-if ((ret = avio_read(s->pb, temp, length)) < 0)
-return ret;
+av_assert0(length < sizeof(temp));
+if ((ret = avio_read(s->pb, temp, length)) != length)
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
temp[length] = 0;
@@ -304,8 +304,10 @@ static int wav_parse_bext_tag(AVFormatContext *s, int64_t size)
if (!(coding_history = av_malloc(size + 1)))
return AVERROR(ENOMEM);
-if ((ret = avio_read(s->pb, coding_history, size)) < 0)
-return ret;
+if ((ret = avio_read(s->pb, coding_history, size)) != size) {
+av_free(coding_history);
+return ret < 0 ? ret : AVERROR_INVALIDDATA;
+}
coding_history[size] = 0;
if ((ret = av_dict_set(&s->metadata, "coding_history", coding_history,
--
2.22.0.709.g102302147b-goog
___
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 v7 2/2] lavc/tiff: Decode embedded JPEGs in DNG images
On 25.07.2019, at 17:35, velocit...@gmail.com wrote:
> +// Lookup table lookup
> +if (lut)
> +value = lut[value];
As this function is in the innermost loop, doing the if here instead of having
2 different implementations is likely not ideal speed-wise.
> +// Color scaling
> +value = av_clip_uint16_c((unsigned)(((float)value * scale_factor) *
> 0x));
As input and output are both 16 bit I wonder if floating-point isn't rather
overkill compared to doing fixed-point arithmetic.
>
> +if (is_u16) {
> +for (line = 0; line < height; line++) {
> +uint16_t *dst_u16 = (uint16_t *)dst;
> +uint16_t *src_u16 = (uint16_t *)src;
> +
> +for (col = 0; col < width; col++)
> +*dst_u16++ = dng_raw_to_linear16(*src_u16++, s->dng_lut,
> s->black_level, scale_factor);
> +
> +dst += dst_stride * sizeof(uint16_t);
> +src += src_stride * sizeof(uint16_t);
Is all this casting working correctly on e.g. big-endian?
Also using sizeof on uint16_t and uint8_t seems a bit overkill.
Also not sure if since these are essentially brightness/contrast adjustments if
we should't rather just have a way to export the transform to use...
> @@ -1519,6 +1773,26 @@ again:
> return AVERROR_INVALIDDATA;
> }
>
> +/* Handle DNG images with JPEG-compressed tiles */
> +
> +if (s->tiff_type == TIFF_TYPE_DNG || s->tiff_type ==
> TIFF_TYPE_CINEMADNG) {
> +if (s->is_jpeg) {
> +if (s->is_bayer) {
> +if ((ret = dng_decode(avctx, (AVFrame*)data, avpkt)) > 0)
> +*got_frame = 1;
> +return ret;
> +} else {
> +avpriv_report_missing_feature(avctx, "DNG JPG-compressed
> non-bayer-encoded images");
> +return AVERROR_PATCHWELCOME;
> +}
> +} else if (s->is_tiled) {
> +avpriv_report_missing_feature(avctx, "DNG uncompressed tiled
> images");
> +return AVERROR_PATCHWELCOME;
> +}
There is no need for an "else" block if the "if" block ends in a return.
Also putting the error handling first/at the deepest indentation level results
in more readable code generally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
Is there a mips maintainer? otherwise:
On 24.07.2019, at 08:46, Shiyou Yin wrote:
> Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
> ---
> libavcodec/mips/simple_idct_mmi.c | 2 +-
> libavutil/mips/mmiutils.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/mips/simple_idct_mmi.c
> b/libavcodec/mips/simple_idct_mmi.c
> index 7f4bb74..73d797f 100644
> --- a/libavcodec/mips/simple_idct_mmi.c
> +++ b/libavcodec/mips/simple_idct_mmi.c
> @@ -39,7 +39,7 @@
> #define COL_SHIFT 20
> #define DC_SHIFT 3
>
> -DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
> +DECLARE_ALIGNED(16, const int16_t, W_arr)[46] = {
> W4, W2, W4, W6,
> W1, W3, W5, W7,
> W4, W6, -W4, -W2,
This should be fine, simply as it should not be possible for it to cause issues.
> diff --git a/libavutil/mips/mmiutils.h b/libavutil/mips/mmiutils.h
> index 05f6b31..bfa6d8b 100644
> --- a/libavutil/mips/mmiutils.h
> +++ b/libavutil/mips/mmiutils.h
> @@ -205,7 +205,7 @@
> * backup register
> */
> #define BACKUP_REG \
> - double temp_backup_reg[8];\
> + double __attribute__ ((aligned (16))) temp_backup_reg[8]; \
I don't think we're supposed to use raw __attribute__ in FFmpeg, and for stack
variables there can be even more issues.
Maybe check with what other code does...
___
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/vp3: Check that theora is theora
On 24.07.2019, at 14:37, Michael Niedermayer wrote: > On Mon, Jul 22, 2019 at 07:07:57AM +0200, Reimar Döffinger wrote: >> >> >> On 22.07.2019, at 01:25, Michael Niedermayer wrote: >> >>> Fixes: Timeout (2min -> 100ms) >>> Fixes: >>> 15366/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_THEORA_fuzzer-5737849938247680 >>> >>> Found-by: continuous fuzzing process >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> Signed-off-by: Michael Niedermayer >>> --- >>> libavcodec/vp3.c | 2 ++ >>> 1 file changed, 2 insertions(+) >>> >>> diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c >>> index a6f759ebf5..8a165c1275 100644 >>> --- a/libavcodec/vp3.c >>> +++ b/libavcodec/vp3.c >>> @@ -2957,6 +2957,8 @@ static int theora_decode_header(AVCodecContext >>> *avctx, GetBitContext *gb) >>>s->theora_header = 0; >>>s->theora = get_bits_long(gb, 24); >>>av_log(avctx, AV_LOG_DEBUG, "Theora bitstream version %X\n", s->theora); >>> +if (!s->theora) >>> +return AVERROR_INVALIDDATA; >> >> That seems rather strict, a 1-bit error in this field and we don't even try? >> Maybe set to 1 instead with a request for sample? > > ok, will post a new patch Thanks. Sorry if it was maybe a bit nitpicky comment, but seemed like doing it a but nicer might be worth the effort. ___ 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/vqavideo: Set video size
Fixes: out of array access
Fixes:
15919/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VQA_fuzzer-5657368257363968
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vqavideo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vqavideo.c b/libavcodec/vqavideo.c
index 0e70be1000..b9743abda9 100644
--- a/libavcodec/vqavideo.c
+++ b/libavcodec/vqavideo.c
@@ -147,7 +147,7 @@ static av_cold int vqa_decode_init(AVCodecContext *avctx)
}
s->width = AV_RL16(&s->avctx->extradata[6]);
s->height = AV_RL16(&s->avctx->extradata[8]);
-if ((ret = av_image_check_size(s->width, s->height, 0, avctx)) < 0) {
+if ((ret = ff_set_dimensions(avctx, s->width, s->height)) < 0) {
s->width= s->height= 0;
return ret;
}
--
2.22.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V1 1/3] lavf/hls: remove redundancy reset_packet() after av_packet_unref()
On Thu, Jul 25, 2019 at 2:00 PM Steven Liu wrote:
>
> Jun Zhao 于2019年7月21日周日 下午10:55写道：
> >
> > From: Jun Zhao
> >
> > av_packet_unref have reseted the AVPacket, so don't need to call
> > reset_packet after that.
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavformat/hls.c |4
> > 1 files changed, 0 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 8c12fce..238ebd0 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -2120,7 +2120,6 @@ static int hls_read_packet(AVFormatContext *s,
> > AVPacket *pkt)
> > }
> > }
> > av_packet_unref(&pls->pkt);
> > -reset_packet(&pls->pkt);
> > }
> > }
> > /* Check if this stream has the packet with the lowest dts */
> > @@ -2149,7 +2148,6 @@ static int hls_read_packet(AVFormatContext *s,
> > AVPacket *pkt)
> > ret = update_streams_from_subdemuxer(s, pls);
> > if (ret < 0) {
> > av_packet_unref(&pls->pkt);
> > -reset_packet(&pls->pkt);
> > return ret;
> > }
> >
> > @@ -2174,7 +2172,6 @@ static int hls_read_packet(AVFormatContext *s,
> > AVPacket *pkt)
> > av_log(s, AV_LOG_ERROR, "stream index inconsistency: index %d,
> > %d main streams, %d subdemuxer streams\n",
> > pls->pkt.stream_index, pls->n_main_streams,
> > pls->ctx->nb_streams);
> > av_packet_unref(&pls->pkt);
> > -reset_packet(&pls->pkt);
> > return AVERROR_BUG;
> > }
> >
> > @@ -2262,7 +2259,6 @@ static int hls_read_seek(AVFormatContext *s, int
> > stream_index,
> > ff_format_io_close(pls->parent, &pls->input_next);
> > pls->input_next_requested = 0;
> > av_packet_unref(&pls->pkt);
> > -reset_packet(&pls->pkt);
> > pls->pb.eof_reached = 0;
> > /* Clear any buffered data */
> > pls->pb.buf_end = pls->pb.buf_ptr = pls->pb.buffer;
> > --
> > 1.7.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> LGTM
>
> Thanks
Will apply, 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 V1 3/3] lavf/hls: replace the same code logic with ensure_playlist()
On Thu, Jul 25, 2019 at 2:06 PM Steven Liu wrote:
>
> Jun Zhao 于2019年7月21日周日 下午10:32写道：
> >
> > From: vacingfang
> >
> > Replace the same code logic with ensure_playlist(), it's will
> > help reusable blocks of code.
> >
> > Reviewed-by: Jun Zhao
> > Signed-off-by: vacingfang
> > ---
> > libavformat/hls.c | 10 +++---
> > 1 files changed, 3 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 238ebd0..0522445 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -861,13 +861,9 @@ static int parse_playlist(HLSContext *c, const char
> > *url,
> > }
> > if (is_segment) {
> > struct segment *seg;
> > -if (!pls) {
> > -if (!new_variant(c, 0, url, NULL)) {
> > -ret = AVERROR(ENOMEM);
> > -goto fail;
> > -}
> > -pls = c->playlists[c->n_playlists - 1];
> > -}
> > +ret = ensure_playlist(c, &pls, url);
> > +if (ret < 0)
> > +goto fail;
> > seg = av_malloc(sizeof(struct segment));
> > if (!seg) {
> > ret = AVERROR(ENOMEM);
> > --
> > 1.7.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
> LGTM
>
> Thanks
Will apply, Thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] libavfilter: Update derain filter doc.
Add the usage of tensorflow model in derain filter. Training scripts
as well as scripts for tf/native model generation are provided in the
repository at https://github.com/XueweiMeng/derain_filter.git.
Signed-off-by: Xuewei Meng
---
doc/filters.texi | 16
1 file changed, 12 insertions(+), 4 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index c4ba907981..8e67dddecf 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -8367,9 +8367,12 @@ Recurrent Squeeze-and-Excitation Context Aggregation
Net (RESCAN).
See @url{
http://openaccess.thecvf.com/content_ECCV_2018/papers/Xia_Li_Recurrent_Squeeze-and-Excitation_Context_ECCV_2018_paper.pdf
}.
@end itemize
-Training scripts as well as scripts for model generation are provided in
+Training as well as model generation scripts are provided in
the repository at @url{https://github.com/XueweiMeng/derain_filter.git}.
+Native model files (.model) can be generated from TensorFlow model
+files (.pb) by using tools/python/convert.py
+
The filter accepts the following options:
@table @option
@@ -8380,14 +8383,19 @@ the following values:
@table @samp
@item native
Native implementation of DNN loading and execution.
+
+@item tensorflow
+TensorFlow backend. To enable this backend you
+need to install the TensorFlow for C library (see
+@url{https://www.tensorflow.org/install/install_c}) and configure FFmpeg
with
+@code{--enable-libtensorflow}
@end table
Default value is @samp{native}.
@item model
Set path to model file specifying network architecture and its parameters.
-Note that different backends use different file formats. TensorFlow backend
-can load files for both formats, while native backend can load files for
only
-its format.
+Note that different backends use different file formats. TensorFlow and
native
+backend can load files for only its format.
@end table
@section deshake
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org]
>On Behalf Of
>Reimar D?ffinger
>Sent: Friday, July 26, 2019 7:28 AM
>To: FFmpeg development discussions and patches
>Subject: Re: [FFmpeg-devel] [PATCH v2] avutil/mips: Avoid instruction
>exception caused by gssqc1/gslqc1.
>
>Is there a mips maintainer? otherwise:
Since Manojkumar Bhosale stoped take care of mips section last year,
I applied to be the mips maintainer, and trying to be qualified. Will keep
learning and be rigorous.
>On 24.07.2019, at 08:46, Shiyou Yin wrote:
>
>> Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
>> ---
>> libavcodec/mips/simple_idct_mmi.c | 2 +-
>> libavutil/mips/mmiutils.h | 2 +-
>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/mips/simple_idct_mmi.c
>> b/libavcodec/mips/simple_idct_mmi.c
>> index 7f4bb74..73d797f 100644
>> --- a/libavcodec/mips/simple_idct_mmi.c
>> +++ b/libavcodec/mips/simple_idct_mmi.c
>> @@ -39,7 +39,7 @@
>> #define COL_SHIFT 20
>> #define DC_SHIFT 3
>>
>> -DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
>> +DECLARE_ALIGNED(16, const int16_t, W_arr)[46] = {
>> W4, W2, W4, W6,
>> W1, W3, W5, W7,
>> W4, W6, -W4, -W2,
>
>This should be fine, simply as it should not be possible for it to cause
>issues.
>
>> diff --git a/libavutil/mips/mmiutils.h b/libavutil/mips/mmiutils.h
>> index 05f6b31..bfa6d8b 100644
>> --- a/libavutil/mips/mmiutils.h
>> +++ b/libavutil/mips/mmiutils.h
>> @@ -205,7 +205,7 @@
>> * backup register
>> */
>> #define BACKUP_REG \
>> - double temp_backup_reg[8];\
>> + double __attribute__ ((aligned (16))) temp_backup_reg[8]; \
>
>
>I don't think we're supposed to use raw __attribute__ in FFmpeg, and for stack
>variables there can be
>even more issues.
>Maybe check with what other code does...
Will replaced with DECLARE_ALIGNED.
>___
>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 v3] avutil/mips: Avoid instruction exception caused by gssqc1/gslqc1.
Ensure the address accesed by gssqc1/gslqc1 are 16-bits memory-aligned.
---
libavcodec/mips/simple_idct_mmi.c | 2 +-
libavutil/mips/mmiutils.h | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/mips/simple_idct_mmi.c
b/libavcodec/mips/simple_idct_mmi.c
index 7f4bb74..73d797f 100644
--- a/libavcodec/mips/simple_idct_mmi.c
+++ b/libavcodec/mips/simple_idct_mmi.c
@@ -39,7 +39,7 @@
#define COL_SHIFT 20
#define DC_SHIFT 3
-DECLARE_ALIGNED(8, const int16_t, W_arr)[46] = {
+DECLARE_ALIGNED(16, const int16_t, W_arr)[46] = {
W4, W2, W4, W6,
W1, W3, W5, W7,
W4, W6, -W4, -W2,
diff --git a/libavutil/mips/mmiutils.h b/libavutil/mips/mmiutils.h
index 05f6b31..14b6d20 100644
--- a/libavutil/mips/mmiutils.h
+++ b/libavutil/mips/mmiutils.h
@@ -205,7 +205,7 @@
* backup register
*/
#define BACKUP_REG \
- double temp_backup_reg[8];\
+ DECLARE_ALIGNED(16, double, temp_backup_reg)[8]; \
if (_MIPS_SIM == _ABI64) \
__asm__ volatile ( \
"gssqc1 $f25, $f24, 0x00(%[temp]) \n\t" \
--
2.1.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] lafv/wavdec: Fail bext parsing on incomplete reads
On Thu, Jul 25, 2019 at 04:09:35PM -0700, Matthew Wolenetz wrote: > > wavdec.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) > 3e8d230a42a4a12aaf1c375f5a064924238992f9 > 0001-lafv-wavdec-Fail-bext-parsing-on-incomplete-reads.patch > From 7966786250d9581891e0859f769a63f35a5c2729 Mon Sep 17 00:00:00 2001 > From: Matt Wolenetz > Date: Thu, 25 Jul 2019 15:54:49 -0700 > Subject: [PATCH] lafv/wavdec: Fail bext parsing on incomplete reads > > avio_read can successfully return even when less than the requested > amount of input was read. wavdec's bext parsing mistakenly assumed a > successful avio_read always read the full amount that was requested. > The result could be dictionary tags populated with partially > uninitialized values. > > This change also fixes a broken assertion in wav_parse_bext_string that > was off-by-one, though no known current usage of that method hits that > broken case. > > Chromium bug: 987270 > > Signed-off-by: Matt Wolenetz > --- > libavformat/wavdec.c | 12 +++- > 1 file changed, 7 insertions(+), 5 deletions(-) will apply thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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".
