Re: [FFmpeg-devel] [PATCH v3] avcodec/jpeg2000dec: fix HT block decoder
Will apply on 5/30 unless I hear otherwise.
On Mon, May 27, 2024 at 9:25 AM wrote:
>
> From: Pierre-Anthony Lemieux
>
> Addresses https://trac.ffmpeg.org/ticket/10905
>
> Co-authored-by: Osamu Watanabe
> Signed-off-by: Pierre-Anthony Lemieux
> ---
> libavcodec/jpeg2000htdec.c | 122 ---
> tests/ref/fate/jpeg2000dec-ds0_ht_01_b11 | 2 +-
> 2 files changed, 63 insertions(+), 61 deletions(-)
>
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index fa704b665e..eba0936089 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -196,7 +196,7 @@ static void jpeg2000_bitbuf_refill_forward(StateVars
> *buffer, const uint8_t *arr
> while (buffer->bits_left < 32) {
> buffer->tmp = 0xFF;
> buffer->bits = (buffer->last == 0xFF) ? 7 : 8;
> -if (buffer->pos <= length) {
> +if (buffer->pos < length) {
> buffer->tmp = array[buffer->pos];
> buffer->pos += 1;
> buffer->last = buffer->tmp;
> @@ -413,7 +413,7 @@ static void recover_mag_sgn(StateVars *mag_sgn, uint8_t
> pos, uint16_t q, int32_t
>
> static int jpeg2000_import_bit(StateVars *stream, const uint8_t *array,
> uint32_t length)
> {
> -int cond = stream->pos <= length;
> +int cond = stream->pos < length;
> int pos = FFMIN(stream->pos, length);
> if (stream->bits == 0) {
> stream->bits = (stream->tmp == 0xFF) ? 7 : 8;
> @@ -427,7 +427,7 @@ static int jpeg2000_import_bit(StateVars *stream, const
> uint8_t *array, uint32_t
> static int jpeg2000_peek_bit(StateVars *stream, const uint8_t *array,
> uint32_t length)
> {
> if (stream->bits == 0) {
> -int cond = stream->pos <= length;
> +int cond = stream->pos < length;
> int pos = FFMIN(stream->pos, length);
> stream->bits = (stream->tmp == 0xFF) ? 7 : 8;
> stream->pos += cond;
> @@ -508,17 +508,17 @@ static int jpeg2000_decode_sig_emb(const
> Jpeg2000DecoderContext *s, MelDecoderSt
> }
>
> av_always_inline
> -static int jpeg2000_get_state(int x1, int x2, int width, int shift_by,
> +static int jpeg2000_get_state(int x1, int x2, int stride, int shift_by,
>const uint8_t *block_states)
> {
> -return (block_states[(x1 + 1) * (width + 2) + (x2 + 1)] >> shift_by) & 1;
> +return (block_states[(x1 + 1) * stride + (x2 + 1)] >> shift_by) & 1;
> }
>
> av_always_inline
> -static void jpeg2000_modify_state(int x1, int x2, int width,
> - int value, uint8_t *block_states)
> +static void jpeg2000_modify_state(int x1, int x2, int stride,
> + int value, uint8_t *block_states)
> {
> -block_states[(x1 + 1) * (width + 2) + (x2 + 1)] |= value;
> +block_states[(x1 + 1) * stride + (x2 + 1)] |= value;
> }
>
> av_always_inline
> @@ -528,8 +528,8 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
>StateVars *mel_stream,
> StateVars *vlc_stream,
>StateVars *mag_sgn_stream,
> const uint8_t *Dcup,
>uint32_t Lcup, uint32_t Pcup,
> uint8_t pLSB,
> - int width, int height, int32_t
> *sample_buf,
> - uint8_t *block_states)
> + int width, int height, const
> int stride,
> + int32_t *sample_buf, uint8_t
> *block_states)
> {
> uint16_t q = 0; // Represents current quad
> position
> uint16_t q1, q2;
> @@ -958,26 +958,26 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
> j1 = 2 * y;
> j2 = 2 * x;
>
> -sample_buf[j2 + (j1 * width)] = (int32_t)*mu;
> -jpeg2000_modify_state(j1, j2, width, *sigma, block_states);
> +sample_buf[j2 + (j1 * stride)] = (int32_t)*mu;
> +jpeg2000_modify_state(j1, j2, stride, *sigma, block_states);
> sigma += 1;
> mu += 1;
>
> x1 = y != quad_height - 1 || is_border_y == 0;
> -sample_buf[j2 + ((j1 + 1) * width)] = ((int32_t)*mu) * x1;
> -jpeg2000_modify_state(j1 + 1, j2, width, (*sigma) * x1,
> block_states);
> +sample_buf[j2 + ((j1 + 1) * stride)] = ((int32_t)*mu) * x
Re: [FFmpeg-devel] [RFC PATCH] all: Adapt BSD license headers to avoid fate-source exceptions
On Sat, May 25, 2024 at 7:57 AM Andreas Rheinhardt wrote: > > Andreas Rheinhardt: > > This is against the 80 char line length limit, but it is not > > a hard rule anyway. > > > > Signed-off-by: Andreas Rheinhardt > > --- > > This is an alternative to modifying check-source.sh (for which I also > > sent a patch). > > > > doc/mips.txt | 5 ++--- > > libavcodec/aacsbr_fixed.c | 5 ++--- > > libavcodec/ac3dec_fixed.c | 5 ++--- > > libavcodec/aom_film_grain_template.c | 4 ++-- > > libavcodec/arm/vp8dsp_armv6.S | 5 ++--- > > libavcodec/ilbcdata.h | 5 ++--- > > libavcodec/ilbcdec.c | 5 ++--- > > libavcodec/j2kenc.c | 5 ++--- > > libavcodec/mips/ac3dsp_mips.c | 5 ++--- > > libavcodec/mips/acelp_filters_mips.c | 5 ++--- > > libavcodec/mips/acelp_vectors_mips.c | 5 ++--- > > libavcodec/mips/amrwbdec_mips.c | 5 ++--- > > libavcodec/mips/amrwbdec_mips.h | 5 ++--- > > libavcodec/mips/celp_filters_mips.c | 5 ++--- > > libavcodec/mips/celp_math_mips.c | 5 ++--- > > libavcodec/mips/compute_antialias_fixed.h | 5 ++--- > > libavcodec/mips/compute_antialias_float.h | 5 ++--- > > libavcodec/mips/fmtconvert_mips.c | 5 ++--- > > libavcodec/mips/iirfilter_mips.c | 5 ++--- > > libavcodec/mips/lsp_mips.h| 5 ++--- > > libavcodec/mips/mpegaudiodsp_mips_fixed.c | 5 ++--- > > libavcodec/mips/mpegaudiodsp_mips_float.c | 5 ++--- > > libavcodec/riscv/startcode_rvb.S | 4 ++-- > > libavcodec/riscv/startcode_rvv.S | 4 ++-- > > libavcodec/speexdata.h| 5 ++--- > > libavcodec/speexdec.c | 5 ++--- > > libavcodec/vvc/itx_1d.c | 4 ++-- > > libavfilter/af_arnndn.c | 5 ++--- > > libavformat/imf.h | 4 ++-- > > libavformat/imf_cpl.c | 4 ++-- > > libavformat/imfdec.c | 4 ++-- > > libavformat/tests/imf.c | 4 ++-- > > libavutil/fixed_dsp.c | 5 ++--- > > libavutil/fixed_dsp.h | 5 ++--- > > libavutil/mips/float_dsp_mips.c | 5 ++--- > > libavutil/mips/libm_mips.h| 5 ++--- > > libavutil/softfloat_tables.h | 5 ++--- > > libavutil/uuid.c | 5 ++--- > > tests/ref/fate/source | 5 - > > 39 files changed, 76 insertions(+), 111 deletions(-) > > > > diff --git a/doc/mips.txt b/doc/mips.txt > > index d66ce3b447..65ae48cf1d 100644 > > --- a/doc/mips.txt > > +++ b/doc/mips.txt > > @@ -15,9 +15,8 @@ Example of copyright notice: > > * Copyright (c) 2012 > > * MIPS Technologies, Inc., California. > > * > > - * Redistribution and use in source and binary forms, with or without > > - * modification, are permitted provided that the following conditions > > - * are met: > > + * Redistribution and use in source and binary forms, with or without > > modification, > > + * are permitted provided that the following conditions are met: > > * 1. Redistributions of source code must retain the above copyright > > *notice, this list of conditions and the following disclaimer. > > * 2. Redistributions in binary form must reproduce the above copyright > > diff --git a/libavcodec/aacsbr_fixed.c b/libavcodec/aacsbr_fixed.c > > index 06d07e1941..422bb21c20 100644 > > --- a/libavcodec/aacsbr_fixed.c > > +++ b/libavcodec/aacsbr_fixed.c > > @@ -2,9 +2,8 @@ > > * Copyright (c) 2013 > > * MIPS Technologies, Inc., California. > > * > > - * Redistribution and use in source and binary forms, with or without > > - * modification, are permitted provided that the following conditions > > - * are met: > > + * Redistribution and use in source and binary forms, with or without > > modification, > > + * are permitted provided that the following conditions are met: > > * 1. Redistributions of source code must retain the above copyright > > *notice, this list of conditions and the following disclaimer. > > * 2. Redistributions in binary form must reproduce the above copyright > > diff --git a/libavcodec/ac3dec_fixed.c b/libavcodec/ac3dec_fixed.c > > index c9e5cda69c..59b7492733 100644 > > --- a/libavcodec/ac3dec_fixed.c > > +++ b/libavcodec/ac3dec_fixed.c > > @@ -2,9 +2,8 @@ > > * Copyright (c) 2012 > > * MIPS Technologies, Inc., California. > > * > > - * Redistribution and use in source and binary forms, with or without > > - * modification, are permitted provided that the following conditions > > - * are met: > > + * Redistribution and use in source and binary forms, with or without > > modification, > > + * are permitted provided that the following conditions are met: > > * 1. Redistributions of source code must retain the above copyright > > *notice, this list of conditions
Re: [FFmpeg-devel] [RFC PATCH 2/2] tests/fate/source-check: Relax BSD licence check
On Wed, May 22, 2024 at 4:38 AM Andreas Rheinhardt wrote: > > Several files already had standard license header (namely > 2-clause BSD files), yet due to the 80 char line length limit, > they were not treated as such by source-check.sh (which > fate-source uses). Therefore relax the BSD check. LGTM > > Signed-off-by: Andreas Rheinhardt > --- > This is the first variant. The second variant follows shortly. > > tests/fate/source-check.sh | 2 +- > tests/ref/fate/source | 5 - > 2 files changed, 1 insertion(+), 6 deletions(-) > > diff --git a/tests/fate/source-check.sh b/tests/fate/source-check.sh > index 658823fc0b..4d7e175784 100755 > --- a/tests/fate/source-check.sh > +++ b/tests/fate/source-check.sh > @@ -11,7 +11,7 @@ git grep -L -E "This file is part of FFmpeg|This file is > part of libswresample|" > "Permission is hereby granted to use, copy, modify, and distribute this|"\ > "Permission is granted to anyone to use this software for any purpose|"\ > "This work is licensed under the terms of the GNU GPL|"\ > -"Redistribution and use in source and binary forms, with or without > modification|"\ > +"Redistribution and use in source and binary forms, with or without|"\ > "This library is free software; you can redistribute it and/or|"\ > "This program is free software; you can redistribute it and/or modify|"\ > "Licensed under the Apache License|"\ > diff --git a/tests/ref/fate/source b/tests/ref/fate/source > index 723e2e06c7..a3beb35093 100644 > --- a/tests/ref/fate/source > +++ b/tests/ref/fate/source > @@ -1,15 +1,10 @@ > Files without standard license headers: > libavcodec/file_open.c > -libavcodec/ilbcdata.h > -libavcodec/ilbcdec.c > libavcodec/interplayacm.c > libavcodec/log2_tab.c > libavcodec/reverse.c > -libavcodec/riscv/startcode_rvb.S > -libavcodec/riscv/startcode_rvv.S > libavdevice/file_open.c > libavdevice/reverse.c > -libavfilter/af_arnndn.c > libavfilter/file_open.c > libavfilter/log2_tab.c > libavformat/bitstream.c > -- > 2.40.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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/jpeg2000dec: fix HT block decoder
On Sun, May 19, 2024 at 9:02 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses https://trac.ffmpeg.org/ticket/10905
> >
> > Co-authored-by: Osamu Watanabe
> > Signed-off-by: Pierre-Anthony Lemieux
> > --> @@ -1297,14 +1299,14 @@ ff_jpeg2000_decode_htj2k(const
> Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c
> > for (int y = 0; y < height; y++) {
> > for (int x = 0; x < width; x++) {
> > n = x + (y * t1->stride);
> > -val = sample_buf[x + (y * width)];
> > +val = sample_buf[x + (y * quad_buf_width)];
> > /* Convert sign-magnitude to two's complement. */
> > val = val >> 31 ? 0x8000 - val : val;
> > val >>= (pLSB - 1);
> > t1->data[n] = val;
> > }
> > }
> > -free:
> > +free:
>
> Spurious change. It also seems unintentional and undesirable.
Yes. Will fix before merging.
>
> > av_freep(_buf);
> > av_freep(_states);
> > return ret;
>
> ___
> 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] SOW deadline + lessons
On Thu, Feb 8, 2024 at 5:37 AM Derek Buitenhuis wrote: > > Hello, > > On 2/8/2024 6:02 AM, Pierre-Anthony Lemieux wrote: > > The suggested approach is that interested individuals email me, no > > later than Feb 10 at 23:59 UTC, a completed SOW using the template at > > [2]. > > I feel obliged to point out that the GA vote Michael called n this ends > on 11 Feb,after the due date listed here. Thanks. I am happy to withhold submitting the SOWs until after the vote. It will take some time to collate the responses anyway. > > Turns out dropping this on the list under 2 weeks before the due date was > a poor choice. Yes, it significantly reduces the chances of success. The lessons learned here will hopefully be useful for future grants. > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] Call for SOWs [due Feb 10 at 23:59 UTC]
Hi all, Below is a proposal for creating a proposal to the STF -- I offered to Michael to help, and here we are. The objective, as I understand it, is to unlock funds for individuals that are interested in contributing to the FFMPEG codebase, subject to the STF criteria [1]. The suggested approach is that interested individuals email me, no later than Feb 10 at 23:59 UTC, a completed SOW using the template at [2]. It is important IMHO that there is a developer and a defined amount attached to each SOW, otherwise it creates uncertainty and thus increases the management burden and reduces the chances that the proposal is accepted. It is also important that the aggregate value of the SOWs is greater than €150,000 (minimum STF funding). This call for SOWs is completely voluntary, there is no guarantee that all SOWs are accepted by SPI, and the chances of success are unknown (to me). The SOWs (minus personal information and amounts) will be published. I am happy to collate the SOWs and forward them to SPI, who would handle the submission to STF and payments to contributors as the case may be. I am also happy to be educated and proven wrong. I am also happy to do nothing. Best, -- Pierre [1] https://www.sovereigntechfund.de/programs/applications#evaluation-criteria [2] https://docs.google.com/document/d/1unVsF5nwvKQ8rKbrEHN9NZIEvL73CV5zpB9OK0DrSG8 ___ 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] [MXF] - Set aspect ratio for jpeg2000 images
On Fri, Jan 26, 2024 at 10:02 AM Cédric Le Barz wrote: > > Set aspect ratio for jpeg2000 images. "The image area on the reference grid is defined by its upper left hand reference grid point at location (XOsiz, YOsiz), and its lower right hand reference grid point at location (Xsiz – 1, Ysiz – 1)" (15444-1, 8.2) AFAIK setting the MXF aspect ratio item to the ratio of the image pixel dimensions only works if (a) the pixel aspect ratio is 1 and (b) the video is not interlaced -- see 6.2.1.2 and Annex H at https://pub.smpte.org/doc/st2067-21/20221124-pub/. > ___ > 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] J2K in HEIF was: [RFC]avformat: introduce AVStreamGroup
On Wed, Sep 13, 2023 at 2:35 AM Tomas Härdin wrote:
>
> ons 2023-09-06 klockan 16:16 -0300 skrev James Almer:
> > On 9/6/2023 2:53 PM, Tomas Härdin wrote:
> > > ons 2023-09-06 klockan 11:38 -0300 skrev James Almer:
> > > > Signed-off-by: James Almer
> > > > ---
> > > > This is an initial proof of concept for AVStream groups,
> > > > something
> > > > that's
> > > > needed for quite a few existing and upcoming formats that lavf
> > > > has no
> > > > way to
> > > > currently export. Said formats define a single video or audio
> > > > stream
> > > > composed
> > > > by merging several individualy multiplexed streams within a media
> > > > file.
> > > > This is the case of HEIF, a format defining a tiled image where
> > > > each
> > > > tile is a
> > > > separate image (either hevc, av1, etc) all of which need to be
> > > > decoded
> > > > individualy and then stitched together for presentation using
> > > > container level
> > > > information;
> > >
> > > I remember this blocking HEIF as a GSoC project. Honestly the way
> > > that
> > > format is designed is immensely horrible.
> > >
> > > > MPEG-TS programs, currently exported as
> > > > AVProgram, which this new general purpose API would replace.
> > >
> > > I can foresee this being a nuisance for users accustomed to
> > > AVProgram.
> > > Also this feature borders on NLE territory. Not necessarily a bad
> > > thing, but FFmpeg is overall poorly architectured for NLE stuff. I
> > > believe I raised this issue back when lavfi was proposed, it being
> > > wholly unsuitable for NLE work.
> > >
> > >
> > > > +typedef struct AVStreamGroup {
> > > > +/**
> > > > + * A class for @ref avoptions. Set on stream creation.
> > > > + */
> > > > +const AVClass *av_class;
> > > > +
> > > > +/**
> > > > + * Group index in AVFormatContext.
> > > > + */
> > > > +int index;
> > > > +
> > > > +/**
> > > > + * Format-specific group ID.
> > > > + * decoding: set by libavformat
> > > > + * encoding: set by the user, replaced by libavformat if
> > > > left
> > > > unset
> > > > + */
> > > > +int id;
> > > > +
> > > > +/**
> > > > + * Codec parameters associated with this stream group.
> > > > Allocated
> > > > and freed
> > > > + * by libavformat in avformat_new_stream_group() and
> > > > avformat_free_context()
> > > > + * respectively.
> > > > + *
> > > > + * - demuxing: filled by libavformat on stream group
> > > > creation or
> > > > in
> > > > + * avformat_find_stream_info()
> > > > + * - muxing: filled by the caller before
> > > > avformat_write_header()
> > > > + */
> > > > +AVCodecParameters *codecpar;
> > > > +
> > > > +void *priv_data;
> > > > +
> > > > +/**
> > > > + * Number of elements in AVStreamGroup.stream_index.
> > > > + *
> > > > + * Set by av_stream_group_add_stream() and
> > > > av_stream_group_new_stream(), must not
> > > > + * be modified by any other code.
> > > > + */
> > > > +int nb_stream_indexes;
> > > > +
> > > > +/**
> > > > + * A list of indexes of streams in the group. New entries
> > > > are
> > > > created with
> > > > + * av_stream_group_add_stream() and
> > > > av_stream_group_new_stream().
> > > > + *
> > > > + * - demuxing: entries are created by libavformat in
> > > > avformat_open_input().
> > > > + * If AVFMTCTX_NOHEADER is set in ctx_flags,
> > > > then
> > > > new entries may also
> > > > + * appear in av_read_frame().
> > > > + * - muxing: entries are created by the user before
> > > > avformat_write_header().
> > > > + *
> > > > + * Freed by libavformat in avformat_free_context().
> > > > + */
> > > > +int *stream_index;
> > > > +} AVStreamGroup;
> > >
> > > I see no provisions for attaching metadata, for example HEIF
> > > stitching.
> > > Putting it in coderpar seems wrong, since it is container-level
> > > metadata. We could just have an HEIF specific struct as container
> > > metadata.
> >
> > The doxy for AVCodecParameters says "This struct describes the
> > properties of an encoded stream.", so It's not about container level
> > props.
>
> It *is* container level props. The underlying codecs have no concept of
> this kind of stitching. The closest you're going to get is tiles in
> JPEG2000, but I doubt HEIF support JPEG2000.
Just an FYI.
HEIF supports JPEG 2000:
https://www.itu.int/rec/T-REC-T.815/en
One implementation:
https://github.com/strukturag/libheif/pull/874
>
> We might say "well the resulting stream group has resolution so it's
> like a codec" but see below.
>
> > Although codecpar will be used to export the merged/stitched stream
> > props like dimensions and channel layout, maybe you're right about
> > the
> > metadata because there would be a clash between actual
> > HEVC/Opus/AAC/AV1
> > extradata and the HEIF/IAMF/etc specific info if both use
> > codecpar.extradata, even if one will be in AVStream
Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000htdec: check if block decoding will exceed internal precision
On Mon, Aug 14, 2023 at 1:14 AM Tomas Härdin wrote:
>
> lör 2023-08-12 klockan 13:31 -0700 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Intended to replace
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230802000135.26482-3-mich...@niedermayer.cc/
> > with a more accurate block decoding magnitude bound.
> >
> > ---
> > libavcodec/jpeg2000htdec.c | 34 +-
> > 1 file changed, 33 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> > index 2c4cea5dd9..a7329206de 100644
> > --- a/libavcodec/jpeg2000htdec.c
> > +++ b/libavcodec/jpeg2000htdec.c
> > @@ -572,6 +572,14 @@ static int
> > jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
> >
> > const uint8_t *vlc_buf = Dcup + Pcup;
> >
> > +/*
> > + * Bound on the recision needed to process the codeblock. The
> > number of
>
> precision
>
> > + * decoded bit planes is equal to at most cblk->zbp + 2 since
> > S_blk = P if
> > + * there are no placeholder passes or HT Sets and P = cblk->zbp.
> > See Rec.
> > + * ITU-T T.814, 7.6.
> > + */
> > +int maxbp = cblk->zbp + 2;
> > +
> > /* convert to raster-scan */
> > const uint16_t is_border_x = width % 2;
> > const uint16_t is_border_y = height % 2;
> > @@ -590,6 +598,12 @@ static int
> > jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
> > goto free;
> > }
> >
> > +/* do we have enough precision, assuming a 32-bit decoding path
> > */
> > +if (maxbp >= 32) {
> > +return AVERROR_INVALIDDATA;
> > +goto free;
> > +}
>
> Why not move this check to just after maxbp is declared? That way a
> bunch of allocations are avoided
I had it that way but then the compiler complained about mixing
declarations and code.
>
> The rest of the patch looks fine, though I haven't studied the HT spec
> deeply. The +2 on maxbp is familiar.
>
> /Tomas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/jpeg2000htdec: check if block decoding will exceed internal precision
On Sat, Aug 12, 2023 at 1:31 PM Pierre-Anthony Lemieux wrote: > > On Sat, Aug 12, 2023 at 11:39 AM Michael Niedermayer > wrote: > > > > On Thu, Aug 10, 2023 at 04:48:56PM -0700, p...@sandflow.com wrote: > > > From: Pierre-Anthony Lemieux > > > > > > Intended to replace > > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230802000135.26482-3-mich...@niedermayer.cc/ > > > with a more accurate block decoding magnitude bound. > > > > > > --- > > > libavcodec/jpeg2000htdec.c | 32 +++- > > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c > > > index 2c4cea5dd9..713dba17e3 100644 > > > --- a/libavcodec/jpeg2000htdec.c > > > +++ b/libavcodec/jpeg2000htdec.c > > > @@ -572,6 +572,14 @@ static int jpeg2000_decode_ht_cleanup_segment(const > > > Jpeg2000DecoderContext *s, > > > > > > const uint8_t *vlc_buf = Dcup + Pcup; > > > > > > +/* > > > + * Bound on the recision needed to process the codeblock. The number > > > of > > > + * decoded bit planes is equal to at most cblk->zbp + 2 since S_blk > > > = P if > > > + * there are no placeholder passes or HT Sets and P = cblk->zbp. See > > > Rec. > > > + * ITU-T T.814, 7.6. > > > + */ > > > +int maxbp = cblk->zbp + 2; > > > + > > > /* convert to raster-scan */ > > > const uint16_t is_border_x = width % 2; > > > const uint16_t is_border_y = height % 2; > > > @@ -590,6 +598,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const > > > Jpeg2000DecoderContext *s, > > > goto free; > > > } > > > > > > +/* do we have enough precision, assuming a 32-bit decoding path */ > > > +if (maxbp >= 32) > > > +return AVERROR_INVALIDDATA; > > > > doesnt this need a goto free ? > > Yes. Just pushed v2 of the patchset. I meant "sent it to this reflector". > > > > > thx > > > > [...] > > > > -- > > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > > > No human being will ever know the Truth, for even if they happen to say it > > by chance, they would not even known they had done so. -- Xenophanes > > ___ > > ffmpeg-devel mailing list > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/jpeg2000htdec: check if block decoding will exceed internal precision
On Sat, Aug 12, 2023 at 11:39 AM Michael Niedermayer wrote: > > On Thu, Aug 10, 2023 at 04:48:56PM -0700, p...@sandflow.com wrote: > > From: Pierre-Anthony Lemieux > > > > Intended to replace > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230802000135.26482-3-mich...@niedermayer.cc/ > > with a more accurate block decoding magnitude bound. > > > > --- > > libavcodec/jpeg2000htdec.c | 32 +++- > > 1 file changed, 31 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c > > index 2c4cea5dd9..713dba17e3 100644 > > --- a/libavcodec/jpeg2000htdec.c > > +++ b/libavcodec/jpeg2000htdec.c > > @@ -572,6 +572,14 @@ static int jpeg2000_decode_ht_cleanup_segment(const > > Jpeg2000DecoderContext *s, > > > > const uint8_t *vlc_buf = Dcup + Pcup; > > > > +/* > > + * Bound on the recision needed to process the codeblock. The number of > > + * decoded bit planes is equal to at most cblk->zbp + 2 since S_blk = > > P if > > + * there are no placeholder passes or HT Sets and P = cblk->zbp. See > > Rec. > > + * ITU-T T.814, 7.6. > > + */ > > +int maxbp = cblk->zbp + 2; > > + > > /* convert to raster-scan */ > > const uint16_t is_border_x = width % 2; > > const uint16_t is_border_y = height % 2; > > @@ -590,6 +598,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const > > Jpeg2000DecoderContext *s, > > goto free; > > } > > > > +/* do we have enough precision, assuming a 32-bit decoding path */ > > +if (maxbp >= 32) > > +return AVERROR_INVALIDDATA; > > doesnt this need a goto free ? Yes. Just pushed v2 of the patchset. > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > No human being will ever know the Truth, for even if they happen to say it > by chance, they would not even known they had done so. -- Xenophanes > ___ > 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 3/3] avcodec/jpeg2000htdec: Check m
On Sun, Aug 6, 2023 at 9:28 AM Pierre-Anthony Lemieux wrote:
>
> On Sat, Aug 5, 2023 at 9:30 AM Michael Niedermayer
> wrote:
> >
> > On Fri, Aug 04, 2023 at 06:19:46PM -0700, Pierre-Anthony Lemieux wrote:
> > > On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
> > > wrote:
> > > >
> > > > This also fixes assertion failures
> > > >
> > > > Fixes: shift exponent 95 is too large for 64-bit type 'unsigned long
> > > > long'
> > > > Fixes:
> > > > 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5828618092937216
> > > >
> > > > Found-by: continuous fuzzing process
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavcodec/jpeg2000htdec.c | 22 --
> > > > 1 file changed, 20 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> > > > index 3985783f3a..ae2ee6d6ee 100644
> > > > --- a/libavcodec/jpeg2000htdec.c
> > > > +++ b/libavcodec/jpeg2000htdec.c
> > > > @@ -689,6 +689,10 @@ static int
> > > > jpeg2000_decode_ht_cleanup_segment(const Jpeg2000DecoderContext *s,
> > > > for (int i = 0; i < 4; i++) {
> > > > m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> > > > ((emb_pat_k[J2K_Q1] >> i) & 1);
> > > > m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] -
> > > > ((emb_pat_k[J2K_Q2] >> i) & 1);
> > > > +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
> > >
> > > AFAIK, m[i], which is m_n in the standard, can never be larger than
> > > the sample bit depth (including the sign bit, if any). Is it worth
> > > comparing it to a value more precise than 63?
> >
> > probably, yes
> > I think you know the spec better than i do, so you can probably pick
> > the tightest bound quicker ...
> > can you submit a patch doing that ?
>
> I plan to do so before week's end.
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20230810234856.2636-1-...@sandflow.com/
>
> >
> > thx
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > The greatest way to live with honor in this world is to be what we pretend
> > to be. -- Socrates
> > ___
> > 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 3/3] avcodec/jpeg2000htdec: Check m
On Sat, Aug 5, 2023 at 9:30 AM Michael Niedermayer
wrote:
>
> On Fri, Aug 04, 2023 at 06:19:46PM -0700, Pierre-Anthony Lemieux wrote:
> > On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
> > wrote:
> > >
> > > This also fixes assertion failures
> > >
> > > Fixes: shift exponent 95 is too large for 64-bit type 'unsigned long long'
> > > Fixes:
> > > 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5828618092937216
> > >
> > > Found-by: continuous fuzzing process
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/jpeg2000htdec.c | 22 --
> > > 1 file changed, 20 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> > > index 3985783f3a..ae2ee6d6ee 100644
> > > --- a/libavcodec/jpeg2000htdec.c
> > > +++ b/libavcodec/jpeg2000htdec.c
> > > @@ -689,6 +689,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> > > Jpeg2000DecoderContext *s,
> > > for (int i = 0; i < 4; i++) {
> > > m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> > > ((emb_pat_k[J2K_Q1] >> i) & 1);
> > > m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] -
> > > ((emb_pat_k[J2K_Q2] >> i) & 1);
> > > +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
> >
> > AFAIK, m[i], which is m_n in the standard, can never be larger than
> > the sample bit depth (including the sign bit, if any). Is it worth
> > comparing it to a value more precise than 63?
>
> probably, yes
> I think you know the spec better than i do, so you can probably pick
> the tightest bound quicker ...
> can you submit a patch doing that ?
I plan to do so before week's end.
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The greatest way to live with honor in this world is to be what we pretend
> to be. -- Socrates
> ___
> 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 2/3] avcodec/jpeg2000htdec: Consolidate jpeg2000 spec bits in jpeg2000_bitbuf_refill_backwards()
On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
wrote:
>
> Code should make more sense now
>
> Fixes: out of array access
> Fixes:
> 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-6627570448465920
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/jpeg2000htdec.c | 13 +++--
> 1 file changed, 3 insertions(+), 10 deletions(-)
>
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index 2b082b3b2f..3985783f3a 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -159,21 +159,14 @@ static int jpeg2000_bitbuf_refill_backwards(StateVars
> *buffer, const uint8_t *ar
> */
> position -= 4;
Can't we get rid of this line and the comment above, and instead
replace `int32_t position = buffer->pos;` with `int32_t position =
buffer->pos - 4;`?
LGTM otherwise.
>
> -tmp = AV_RB32([position + 1]);
> -
> -if (buffer->pos < 4){
> -/* mask un-needed bits if we are close to input end */
> -uint64_t mask = (1ull << (buffer->pos + 1) * 8) - 1;
> -tmp &= mask;
> -}
> -
> /**
> * Unstuff bits. Load a temporary byte, which precedes the position we
> * currently at, to ensure that we can also un-stuff if the stuffed bit
> is
> * the bottom most bits.
> */
> -tmp <<= 8;
> -tmp |= array[buffer->pos + 1];
> +
> +for(int i = FFMAX(0, position + 1); i <= buffer->pos + 1; i++)
> +tmp = 256*tmp + array[i];
>
> if ((tmp & 0x7FFF00) > 0x7F8F00) {
> tmp &= 0x7F;
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/jpeg2000htdec: Check m
On Tue, Aug 1, 2023 at 5:02 PM Michael Niedermayer
wrote:
>
> This also fixes assertion failures
>
> Fixes: shift exponent 95 is too large for 64-bit type 'unsigned long long'
> Fixes:
> 58299/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-5828618092937216
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/jpeg2000htdec.c | 22 --
> 1 file changed, 20 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c
> index 3985783f3a..ae2ee6d6ee 100644
> --- a/libavcodec/jpeg2000htdec.c
> +++ b/libavcodec/jpeg2000htdec.c
> @@ -689,6 +689,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
> for (int i = 0; i < 4; i++) {
> m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> ((emb_pat_k[J2K_Q1] >> i) & 1);
> m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] -
> ((emb_pat_k[J2K_Q2] >> i) & 1);
> +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
AFAIK, m[i], which is m_n in the standard, can never be larger than
the sample bit depth (including the sign bit, if any). Is it worth
comparing it to a value more precise than 63?
> +ret = AVERROR_INVALIDDATA;
> +goto free;
> +}
> }
>
> recover_mag_sgn(mag_sgn_stream, J2K_Q1, q1, m_n, known_1, emb_pat_1,
> v, m,
> @@ -723,8 +727,13 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
>
> U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
>
> -for (int i = 0; i < 4; i++)
> +for (int i = 0; i < 4; i++) {
> m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> ((emb_pat_k[J2K_Q1] >> i) & 1);
> +if (m[J2K_Q1][i] > 63) {
> +ret = AVERROR_INVALIDDATA;
> +goto free;
> +}
> +}
>
> recover_mag_sgn(mag_sgn_stream, J2K_Q1, q1, m_n, known_1, emb_pat_1,
> v, m,
> E, mu_n, Dcup, Pcup, pLSB);
> @@ -855,6 +864,10 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
> for (int i = 0; i < 4; i++) {
> m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> ((emb_pat_k[J2K_Q1] >> i) & 1);
> m[J2K_Q2][i] = sigma_n[4 * q2 + i] * U[J2K_Q2] -
> ((emb_pat_k[J2K_Q2] >> i) & 1);
> +if (m[J2K_Q1][i] > 63 || m[J2K_Q2][i] > 63) {
> +ret = AVERROR_INVALIDDATA;
> +goto free;
> +}
> }
> recover_mag_sgn(mag_sgn_stream, J2K_Q1, q1, m_n, known_1,
> emb_pat_1, v, m,
> E, mu_n, Dcup, Pcup, pLSB);
> @@ -920,8 +933,13 @@ static int jpeg2000_decode_ht_cleanup_segment(const
> Jpeg2000DecoderContext *s,
>
> U[J2K_Q1] = kappa[J2K_Q1] + u[J2K_Q1];
>
> -for (int i = 0; i < 4; i++)
> +for (int i = 0; i < 4; i++) {
> m[J2K_Q1][i] = sigma_n[4 * q1 + i] * U[J2K_Q1] -
> ((emb_pat_k[J2K_Q1] >> i) & 1);
> +if (m[J2K_Q1][i] > 63) {
> +ret = AVERROR_INVALIDDATA;
> +goto free;
> +}
> +}
>
> recover_mag_sgn(mag_sgn_stream, J2K_Q1, q1, m_n, known_1,
> emb_pat_1, v, m,
> E, mu_n, Dcup, Pcup, pLSB);
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avcodec/jpeg2000htdec: Avoid freeing uninitialized pointers in ff_jpeg2000_decode_htj2k()
On Thu, Aug 3, 2023 at 1:50 PM Tomas Härdin wrote: > > tor 2023-08-03 klockan 17:36 +0200 skrev Michael Niedermayer: > > On Thu, Aug 03, 2023 at 10:20:29AM +0200, Tomas Härdin wrote: > > > ons 2023-08-02 klockan 02:01 +0200 skrev Michael Niedermayer: > > > > Fixes: freeing of uninitialized pointers > > > > Fixes: part of 58299 > > > > > > > > Found-by: continuous fuzzing process > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > > Signed-off-by: Michael Niedermayer > > > > --- > > > > libavcodec/jpeg2000htdec.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/libavcodec/jpeg2000htdec.c > > > > b/libavcodec/jpeg2000htdec.c > > > > index 4c4e54710d..2b082b3b2f 100644 > > > > --- a/libavcodec/jpeg2000htdec.c > > > > +++ b/libavcodec/jpeg2000htdec.c > > > > @@ -1174,8 +1174,8 @@ ff_jpeg2000_decode_htj2k(const > > > > Jpeg2000DecoderContext *s, Jpeg2000CodingStyle *c > > > > int ret; > > > > > > > > /* Temporary buffers */ > > > > -int32_t *sample_buf; > > > > -uint8_t *block_states; > > > > +int32_t *sample_buf = NULL; > > > > +uint8_t *block_states = NULL; > > > > > > Looks OK > > > > will apply > > I should add that I don't know if the two other patches are fine I am working on them. > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] avformat/imf_cpl: Replace NULL content_title_utf8 by ""
LGTM.
On Mon, Jul 24, 2023 at 5:46 PM Michael Niedermayer
wrote:
>
> Suggested-by: Pierre-Anthony Lemieux
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/imf_cpl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index 69155d786d..5f1a67443f 100644
> --- a/libavformat/imf_cpl.c
> +++ b/libavformat/imf_cpl.c
> @@ -182,6 +182,10 @@ static int fill_content_title(xmlNodePtr cpl_element,
> FFIMFCPL *cpl)
> cpl->content_title_utf8 = xmlNodeListGetString(cpl_element->doc,
> element->xmlChildrenNode,
> 1);
> +if (!cpl->content_title_utf8)
> +cpl->content_title_utf8 = xmlStrdup("");
> +if (!cpl->content_title_utf8)
> +return AVERROR(ENOMEM);
>
> return 0;
> }
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/5] avformat/imf_cpl: xmlNodeListGetString() can return NULL
Would this patch be an opportunity to set `cpl->content_title_utf8` to an empty string at fill_content_title() at libavformat/imf_cpl.c if xmlNodeListGetString() returns NULL? It could be done as a separate patch alternatively. LGTM otherwise. On Sun, Jul 23, 2023 at 11:03 AM Michael Niedermayer wrote: > > Fixes: NULL pointer dereference > Fixes: > 60166/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5998301577871360 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/imf_cpl.c | 8 ++-- > 1 file changed, 6 insertions(+), 2 deletions(-) > > diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c > index fe975c2f0c..69155d786d 100644 > --- a/libavformat/imf_cpl.c > +++ b/libavformat/imf_cpl.c > @@ -75,6 +75,8 @@ int ff_imf_xml_read_uuid(xmlNodePtr element, AVUUID uuid) > int ret = 0; > > xmlChar *element_text = xmlNodeListGetString(element->doc, > element->xmlChildrenNode, 1); > +if (!element_text) > +return AVERROR_INVALIDDATA; > ret = av_uuid_urn_parse(element_text, uuid); > if (ret) > ret = AVERROR_INVALIDDATA; > @@ -88,7 +90,7 @@ int ff_imf_xml_read_rational(xmlNodePtr element, AVRational > *rational) > int ret = 0; > > xmlChar *element_text = xmlNodeListGetString(element->doc, > element->xmlChildrenNode, 1); > -if (sscanf(element_text, "%i %i", >num, >den) != 2) > +if (element_text == NULL || sscanf(element_text, "%i %i", > >num, >den) != 2) > ret = AVERROR_INVALIDDATA; > xmlFree(element_text); > > @@ -100,7 +102,7 @@ int ff_imf_xml_read_uint32(xmlNodePtr element, uint32_t > *number) > int ret = 0; > > xmlChar *element_text = xmlNodeListGetString(element->doc, > element->xmlChildrenNode, 1); > -if (sscanf(element_text, "%" PRIu32, number) != 1) > +if (element_text == NULL || sscanf(element_text, "%" PRIu32, number) != > 1) > ret = AVERROR_INVALIDDATA; > xmlFree(element_text); > > @@ -245,6 +247,8 @@ static int fill_timecode(xmlNodePtr cpl_element, FFIMFCPL > *cpl) > return AVERROR_INVALIDDATA; > > tc_str = xmlNodeListGetString(element->doc, element->xmlChildrenNode, 1); > +if (!tc_str) > +return AVERROR_INVALIDDATA; > ret = parse_cpl_tc_type(tc_str, comps); > xmlFree(tc_str); > if (ret) > -- > 2.17.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] doc/developer: Make tests a requirement
+1 On Mon, Jul 3, 2023 at 19:32 Tomas Härdin wrote: > tis 2023-07-04 klockan 01:00 +0200 skrev Michael Niedermayer: > > Suggested-by: Anton > > > > Signed-off-by: Michael Niedermayer > > --- > > doc/developer.texi | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/doc/developer.texi b/doc/developer.texi > > index 0c2f2cd7d1..67f7f78e86 100644 > > --- a/doc/developer.texi > > +++ b/doc/developer.texi > > @@ -806,7 +806,7 @@ improves readability. > > > > @item > > Consider adding a regression test for your code. All new modules > > -should be covered by tests. That includes demuxers, muxers, > > decoders, encoders > > +must be covered by tests. That includes demuxers, muxers, decoders, > > encoders > > +1 > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/imf: clean-up logging * remove log to NULL * remove extraneous logging
Will apply "soon".
On Mon, May 29, 2023 at 9:59 AM wrote:
>
> From: Pierre-Anthony Lemieux
>
> ---
> libavformat/imf.h | 6 +-
> libavformat/imf_cpl.c | 179 +++-
> libavformat/imfdec.c| 2 +-
> libavformat/tests/imf.c | 4 +-
> 4 files changed, 91 insertions(+), 100 deletions(-)
>
> diff --git a/libavformat/imf.h b/libavformat/imf.h
> index 70ed007312..ef124bf412 100644
> --- a/libavformat/imf.h
> +++ b/libavformat/imf.h
> @@ -140,6 +140,7 @@ typedef struct FFIMFCPL {
>
> /**
> * Parse an IMF CompositionPlaylist element into the FFIMFCPL data structure.
> + * @param[in] log_ctx Logging context (points to an instance of AVClass).
> May be NULL.
> * @param[in] doc An XML document from which the CPL is read.
> * @param[out] cpl Pointer to a memory area (allocated by the client), where
> the
> * function writes a pointer to the newly constructed FFIMFCPL structure (or
> @@ -147,10 +148,11 @@ typedef struct FFIMFCPL {
> * the FFIMFCPL structure using ff_imf_cpl_free().
> * @return A non-zero value in case of an error.
> */
> -int ff_imf_parse_cpl_from_xml_dom(xmlDocPtr doc, FFIMFCPL **cpl);
> +int ff_imf_parse_cpl_from_xml_dom(void *log_ctx, xmlDocPtr doc, FFIMFCPL
> **cpl);
>
> /**
> * Parse an IMF Composition Playlist document into the FFIMFCPL data
> structure.
> + * @param[in] log_ctx Logging context (points to an instance of AVClass).
> May be NULL.
> * @param[in] in The context from which the CPL is read.
> * @param[out] cpl Pointer to a memory area (allocated by the client), where
> the
> * function writes a pointer to the newly constructed FFIMFCPL structure (or
> @@ -158,7 +160,7 @@ int ff_imf_parse_cpl_from_xml_dom(xmlDocPtr doc, FFIMFCPL
> **cpl);
> * the FFIMFCPL structure using ff_imf_cpl_free().
> * @return A non-zero value in case of an error.
> */
> -int ff_imf_parse_cpl(AVIOContext *in, FFIMFCPL **cpl);
> +int ff_imf_parse_cpl(void *log_ctx, AVIOContext *in, FFIMFCPL **cpl);
>
> /**
> * Allocates and initializes an FFIMFCPL data structure.
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index a7cf5fa360..fe975c2f0c 100644
> --- a/libavformat/imf_cpl.c
> +++ b/libavformat/imf_cpl.c
> @@ -76,10 +76,8 @@ int ff_imf_xml_read_uuid(xmlNodePtr element, AVUUID uuid)
>
> xmlChar *element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> ret = av_uuid_urn_parse(element_text, uuid);
> -if (ret) {
> -av_log(NULL, AV_LOG_ERROR, "Invalid UUID\n");
> +if (ret)
> ret = AVERROR_INVALIDDATA;
> -}
> xmlFree(element_text);
>
> return ret;
> @@ -90,10 +88,8 @@ int ff_imf_xml_read_rational(xmlNodePtr element,
> AVRational *rational)
> int ret = 0;
>
> xmlChar *element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> -if (sscanf(element_text, "%i %i", >num, >den) != 2) {
> -av_log(NULL, AV_LOG_ERROR, "Invalid rational number\n");
> +if (sscanf(element_text, "%i %i", >num, >den) != 2)
> ret = AVERROR_INVALIDDATA;
> -}
> xmlFree(element_text);
>
> return ret;
> @@ -104,10 +100,8 @@ int ff_imf_xml_read_uint32(xmlNodePtr element, uint32_t
> *number)
> int ret = 0;
>
> xmlChar *element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> -if (sscanf(element_text, "%" PRIu32, number) != 1) {
> -av_log(NULL, AV_LOG_ERROR, "Invalid unsigned 32-bit integer");
> +if (sscanf(element_text, "%" PRIu32, number) != 1)
> ret = AVERROR_INVALIDDATA;
> -}
> xmlFree(element_text);
>
> return ret;
> @@ -181,10 +175,8 @@ static int fill_content_title(xmlNodePtr cpl_element,
> FFIMFCPL *cpl)
> {
> xmlNodePtr element = NULL;
>
> -if (!(element = ff_imf_xml_get_child_element_by_name(cpl_element,
> "ContentTitle"))) {
> -av_log(NULL, AV_LOG_ERROR, "ContentTitle element not found in the
> IMF CPL\n");
> +if (!(element = ff_imf_xml_get_child_element_by_name(cpl_element,
> "ContentTitle")))
> return AVERROR_INVALIDDATA;
> -}
> cpl->content_title_utf8 = xmlNodeListGetString(cpl_element->doc,
> element->xmlChildrenNode,
> 1);
> @@ -242,22 +234,15 @@ static int fill_timecode(xmlNodePtr cpl_element,
> FFIMFCPL *cpl)
> return 0;
>
> element = ff_imf_xml_get_chil
Re: [FFmpeg-devel] [PATCH] avformat/tests/imf: fix memleak
On Fri, May 19, 2023 at 5:21 AM "zhilizhao(赵志立)" wrote: > > > > On May 20, 2023, at 01:40, Zhao Zhili wrote: > > > > From: Zhao Zhili > > > > It breaks fate test with asan. > > > > Signed-off-by: Zhao Zhili > > --- > > libavformat/tests/imf.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > It has already been fixed. Please drop the patch. https://github.com/FFmpeg/FFmpeg/commit/dbe43bca25b84f2c2f5f713eeff5ab2dae89fc25 > > ___ > 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 v3 1/2] fate/imf: fix memory leak
Will apply shortly.
On Mon, May 15, 2023 at 11:33 AM wrote:
>
> From: Pierre-Anthony Lemieux
>
> ---
> libavformat/tests/imf.c | 11 ++-
> 1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
> index cfd84fb8c8..c02cd87ceb 100644
> --- a/libavformat/tests/imf.c
> +++ b/libavformat/tests/imf.c
> @@ -402,6 +402,9 @@ static int test_bad_cpl_parsing(FFIMFCPL **cpl)
> return ret;
> }
>
> +ff_imf_cpl_free(*cpl);
> +*cpl = NULL;
> +
> return 0;
> }
>
> @@ -423,6 +426,9 @@ static int test_bad_resource_cpl_parsing(FFIMFCPL **cpl)
> return ret;
> }
>
> +ff_imf_cpl_free(*cpl);
> +*cpl = NULL;
> +
> return 0;
> }
>
> @@ -594,8 +600,11 @@ int main(int argc, char *argv[])
> printf(" End failing test \n");
>
> printf(" The following should emit errors \n");
> -if (test_bad_resource_cpl_parsing() != 0)
> +if (test_bad_resource_cpl_parsing() != 0) {
> +if (cpl)
> +printf("Improper cleanup after failed CPL parsing\n");
> ret = 1;
> +}
> printf(" End emission of errors \n");
>
> return ret;
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] MXF - Add jpeg2000 subdescriptor - Sponsored by INA
Couple of follow-up comments.
- "mxf_parse_jpeg2000_frame" could be moved to one of jpeg2000 source
files, to keep J2K parsing code together. Maybe there is a way to
reuse jpeg2000_read_main_headers() at jpeg2000dec.c?
- when defining the J2K descriptor items, please refer to the symbol
name from the SMPTE registers, it make following/debugging the code a
lot easier:
{ 0x8405,
{0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x05,0x00,0x00,0x00}},
/* Vertical offset from the origin of the reference grid to the left
side of the image area */
becomes
{ 0x8405,
{0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x05,0x00,0x00,0x00}},
/* YOsiz: vertical offset from the origin of the reference grid to the
left side of the image area */
___
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] avformat/imfdec: fail on probing non xml file extension
On Mon, May 8, 2023 at 3:01 PM Michael Niedermayer wrote: > > On Mon, May 08, 2023 at 11:40:49AM -0700, Pierre-Anthony Lemieux wrote: > > On Mon, May 8, 2023 at 11:23 AM Michael Niedermayer > > wrote: > > > > > > On Sun, May 07, 2023 at 10:09:58PM -0700, Pierre-Anthony Lemieux wrote: > > > > On Sun, May 7, 2023 at 12:18 PM Michael Niedermayer > > > > wrote: > > > > > > > > > > On Sat, May 06, 2023 at 11:01:20AM -0700, Pierre-Anthony Lemieux > > > > > wrote: > > > > > > On Sat, May 6, 2023 at 6:25 AM Michael Niedermayer > > > > > > wrote: > > > > > > > > > > > > > > Its unexpected that a .avi or other "standard" file turns into a > > > > > > > playlist. > > > > > > > The goal of this patch is to avoid this unexpected behavior and > > > > > > > possible > > > > > > > privacy or security differences. > > > > > > > > > > > > Per the IMF specification, a CPL can have any extension or, in fact, > > > > > > no extension. The latter is routinely used. > > > > > > > > > > is there a restriction on the URL/URIs used in it ? > > > > > that is in practice, can they be restricted to the same server, > > > > > child directories, or some other restriction ? > > > > > > > > Below is a brief overview of the linkage between the various of > > > > components of an IMF composition: > > > > > > > > - the Composition Playlist (CPL) is the file that is passed to FFMPEG > > > > as input (-i) > > > > - the CPL is an XML document and defines a playlist > > > > - each of the components that make up the playlist is identified by a > > > > UUID, i.e. the CPL does not contain file paths/URLs. > > > > - the mapping between UUIDs and URLs is done through separate XML > > > > files called Asset Maps. Paths to Asset Maps can be provided > > > > explicitly through the "-assetmaps" argument, otherwise FFMPEG looks > > > > for a file called "ASSETMAP.xml" in the same directory as the CPL > > > > file. > > > > - according to the standard, all URLs in each Asset Map is relative to > > > > the location of the Asset Map, and thus the CPL and the Asset Map have > > > > the same origin > > > > - some applications have relaxed this constraint and allowed absolute > > > > URLs in the Asset Map > > > > > > Thank you for this information > > > > > > > > > > > > > > What is the threat scenario? Is the concern that a malicious actor > > > > provides a CPL and Asset Map from origin A that makes malicious > > > > requests to a different origin B? > > > > > > I do not have an exhaustive list of what can be done, but ill list a > > > few things i can think of with some random ideas. > > > > > > First if i pretend to be the attacker, i want one file not 2 because > > > thats easier > > > can i just send the victim a ASSETMAP.xml that parses correctly as > > > CPL too ? > > > > Both ASSETMAP.xml and CPL are XML files. The root element of the > > former is "AssetMap" and the root element of the latter is > > "CompositionPlaylist". > > The IMF demuxer fails if this is not true, so an Asset Map document > > cannot be mistaken for a CPL, and vice-versa. > > That is good > > > > > > > If yes, i think that can be checked for and trigger an error because > > > i dont think a valid file would use itself as assetmap > > > we could go a bit further here and play with things like > > > ASSETMAP.xml?video.avi > > > or something like that to make the link look more normal > > > i didint look at if that would work but it just makes it more harmless > > > looking > > > > > > now what can one do with this > > > > > > A Spying > > > 1. User downloads a video file > > > now every time she plays the file, the file pings a URL revealing time, > > > frequency and IP of the watched file > > > This is probably not expected by the user > > > > > > B1 Poking > > > 1. User downloads or plays a video file > > > now the file refers to various urls testing the users local network and > > > network services > > > timing of remote accesses re
Re: [FFmpeg-devel] [PATCH 2/3] avformat/imfdec: fail on probing non xml file extension
On Mon, May 8, 2023 at 11:23 AM Michael Niedermayer wrote: > > On Sun, May 07, 2023 at 10:09:58PM -0700, Pierre-Anthony Lemieux wrote: > > On Sun, May 7, 2023 at 12:18 PM Michael Niedermayer > > wrote: > > > > > > On Sat, May 06, 2023 at 11:01:20AM -0700, Pierre-Anthony Lemieux wrote: > > > > On Sat, May 6, 2023 at 6:25 AM Michael Niedermayer > > > > wrote: > > > > > > > > > > Its unexpected that a .avi or other "standard" file turns into a > > > > > playlist. > > > > > The goal of this patch is to avoid this unexpected behavior and > > > > > possible > > > > > privacy or security differences. > > > > > > > > Per the IMF specification, a CPL can have any extension or, in fact, > > > > no extension. The latter is routinely used. > > > > > > is there a restriction on the URL/URIs used in it ? > > > that is in practice, can they be restricted to the same server, > > > child directories, or some other restriction ? > > > > Below is a brief overview of the linkage between the various of > > components of an IMF composition: > > > > - the Composition Playlist (CPL) is the file that is passed to FFMPEG > > as input (-i) > > - the CPL is an XML document and defines a playlist > > - each of the components that make up the playlist is identified by a > > UUID, i.e. the CPL does not contain file paths/URLs. > > - the mapping between UUIDs and URLs is done through separate XML > > files called Asset Maps. Paths to Asset Maps can be provided > > explicitly through the "-assetmaps" argument, otherwise FFMPEG looks > > for a file called "ASSETMAP.xml" in the same directory as the CPL > > file. > > - according to the standard, all URLs in each Asset Map is relative to > > the location of the Asset Map, and thus the CPL and the Asset Map have > > the same origin > > - some applications have relaxed this constraint and allowed absolute > > URLs in the Asset Map > > Thank you for this information > > > > > > What is the threat scenario? Is the concern that a malicious actor > > provides a CPL and Asset Map from origin A that makes malicious > > requests to a different origin B? > > I do not have an exhaustive list of what can be done, but ill list a > few things i can think of with some random ideas. > > First if i pretend to be the attacker, i want one file not 2 because > thats easier > can i just send the victim a ASSETMAP.xml that parses correctly as > CPL too ? Both ASSETMAP.xml and CPL are XML files. The root element of the former is "AssetMap" and the root element of the latter is "CompositionPlaylist". The IMF demuxer fails if this is not true, so an Asset Map document cannot be mistaken for a CPL, and vice-versa. > If yes, i think that can be checked for and trigger an error because > i dont think a valid file would use itself as assetmap > we could go a bit further here and play with things like > ASSETMAP.xml?video.avi > or something like that to make the link look more normal > i didint look at if that would work but it just makes it more harmless looking > > now what can one do with this > > A Spying > 1. User downloads a video file > now every time she plays the file, the file pings a URL revealing time, > frequency and IP of the watched file > This is probably not expected by the user > > B1 Poking > 1. User downloads or plays a video file > now the file refers to various urls testing the users local network and > network services > timing of remote accesses reveals this to an attacker > This is probably not expected by the user either > > B2 same as B1 but a attacker uploads the file to a server where the attacker > pokes around using it > > B3 the URL requests to other services may or may not be able to do more than > just reading > > C DOS > a attacker uploads a file with many references and lets the server repeatly > attempt connections > to them > This one is tricky because we liekly want to continue if one reference fails > but also not do thousands of odd accesses to anything > > This could plausibly even be used to bruteforcing some auth parameters > upload a file with all 4 digit pin codes in their URL and then depending on > what is encoding, maybe what length the resulting encoded file has one could > maybe figure out which URL access succeeded. > > Iam not an expert in this so quite likely theres more that can be done that > iam not thinking of > > Thus anything that isnt part of normal use cases, i suggest to
Re: [FFmpeg-devel] [PATCH 1/3] avformat/dashdec: fail on probing non mpd file extension
On Mon, May 8, 2023 at 10:11 AM Michael Niedermayer
wrote:
>
> On Mon, May 08, 2023 at 04:05:40PM +0200, Tobias Rapp wrote:
> > On 08/05/2023 14:00, James Almer wrote:
> >
> > > On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
> > > > Its unexpected that a .avi or other "standard" file turns into a
> > > > playlist.
> > > > The goal of this patch is to avoid this unexpected behavior and possible
> > > > privacy or security differences.
> > > >
> > > > This is similar to the same change to hls
> > > >
> > > > Signed-off-by: Michael Niedermayer
> > > > ---
> > > > libavformat/dashdec.c | 11 +++
> > > > 1 file changed, 7 insertions(+), 4 deletions(-)
> > > >
> > > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> > > > index 29d4680c68..294e14150d 100644
> > > > --- a/libavformat/dashdec.c
> > > > +++ b/libavformat/dashdec.c
> > > > @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p)
> > > > av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> > > > av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> > > > av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
> > > > -av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) {
> > > > -return AVPROBE_SCORE_MAX;
> > > > -}
> > > > -if (av_stristr(p->buf, "dash:profile")) {
> > > > +av_stristr(p->buf, "3GPP:PSS:profile:DASH1") ||
> > > > +av_stristr(p->buf, "dash:profile")) {
> > > > +if (!av_match_ext(p->filename, "mpd")) {
> > > > +av_log(NULL, AV_LOG_ERROR, "Not detecting dash with non
> > > > standard extension\n");
> > > > +return 0;
> > > > +}
> > > > +
> > > > return AVPROBE_SCORE_MAX;
> > > > }
> > >
> > > Failing because it didn't match an extensions sort of goes against the
> > > point of probing, which even has a low score return value that's
> > > basically "it matched extension" as a sort of last resort.
>
> True
>
>
> > >
> > > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the
> > > spec does state mpd must be the extension), but i think we have no
> > > access to the AVFormatContext here?
>
> Thats not what this was intended to do.
>
> The whole idea is more like a user clicking on a readme.txt and not
> expecting that to downloade a list of URLs in it because it happens to be a
> valid list or URLs
That presumes that "readme.txt":
(a) is detected as a playlist
(b) is a valid XML file (in the case of IMF or dash playlists)
(c) is structured to be interpreted as a playlist by the demuxer
This is unlikely to happen with a random "readme.txt". It sounds like
we are specifically trying to protect against a maliciously-crafted
"readme.txt".
If so, could enforcing, by default, same origin mitigate risks?
>
> The problem here is the information available to the user suggests one thing
> but the action of the user of opening this file does something different,
> something
> unexpected
>
> Thats not an issue if the difference is between 2 of 1000 similar formats
> but If the user believes the format cannot open random local and remote
> URLs but is just a single monolithic file and then when she clicks it
> does open other things without the user even ever knowing. That is not
> ideal.
>
>
> >
> > DASH is usually transferred over HTTP where file extensions are of minor
> > interest, the relevant type information is in the Mime-Type header.
>
> yes, true
>
>
> >
> > I think we already have the "format_whitelist" API for applications that
> > want to restrict the list of formats when loading a file from untrusted
> > sources?
>
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
> ___
> 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 1/3] avformat/dashdec: fail on probing non mpd file extension
On Mon, May 8, 2023 at 7:05 AM Tobias Rapp wrote:
>
> On 08/05/2023 14:00, James Almer wrote:
>
> > On 5/6/2023 10:25 AM, Michael Niedermayer wrote:
> >> Its unexpected that a .avi or other "standard" file turns into a
> >> playlist.
> >> The goal of this patch is to avoid this unexpected behavior and possible
> >> privacy or security differences.
> >>
> >> This is similar to the same change to hls
> >>
> >> Signed-off-by: Michael Niedermayer
> >> ---
> >> libavformat/dashdec.c | 11 +++
> >> 1 file changed, 7 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> >> index 29d4680c68..294e14150d 100644
> >> --- a/libavformat/dashdec.c
> >> +++ b/libavformat/dashdec.c
> >> @@ -2336,10 +2336,13 @@ static int dash_probe(const AVProbeData *p)
> >> av_stristr(p->buf, "dash:profile:isoff-live:2011") ||
> >> av_stristr(p->buf, "dash:profile:isoff-live:2012") ||
> >> av_stristr(p->buf, "dash:profile:isoff-main:2011") ||
> >> -av_stristr(p->buf, "3GPP:PSS:profile:DASH1")) {
> >> -return AVPROBE_SCORE_MAX;
> >> -}
> >> -if (av_stristr(p->buf, "dash:profile")) {
> >> +av_stristr(p->buf, "3GPP:PSS:profile:DASH1") ||
> >> +av_stristr(p->buf, "dash:profile")) {
> >> +if (!av_match_ext(p->filename, "mpd")) {
> >> +av_log(NULL, AV_LOG_ERROR, "Not detecting dash with non
> >> standard extension\n");
> >> +return 0;
> >> +}
> >> +
> >> return AVPROBE_SCORE_MAX;
> >> }
> >
> > Failing because it didn't match an extensions sort of goes against the
> > point of probing, which even has a low score return value that's
> > basically "it matched extension" as a sort of last resort.
> >
> > I'd say wrap this in a FF_COMPLIANCE_STRICT check (since i assume the
> > spec does state mpd must be the extension), but i think we have no
> > access to the AVFormatContext here?
>
> DASH is usually transferred over HTTP where file extensions are of minor
> interest, the relevant type information is in the Mime-Type header.
>
> I think we already have the "format_whitelist" API for applications that
> want to restrict the list of formats when loading a file from untrusted
> sources?
Yes, the IMF playlist, for example, is only allowed to reference MXF files:
https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/imfdec.c#L393
>
> Regards, Tobias
>
> ___
> 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 2/3] avformat/imfdec: fail on probing non xml file extension
On Sun, May 7, 2023 at 12:18 PM Michael Niedermayer wrote: > > On Sat, May 06, 2023 at 11:01:20AM -0700, Pierre-Anthony Lemieux wrote: > > On Sat, May 6, 2023 at 6:25 AM Michael Niedermayer > > wrote: > > > > > > Its unexpected that a .avi or other "standard" file turns into a playlist. > > > The goal of this patch is to avoid this unexpected behavior and possible > > > privacy or security differences. > > > > Per the IMF specification, a CPL can have any extension or, in fact, > > no extension. The latter is routinely used. > > is there a restriction on the URL/URIs used in it ? > that is in practice, can they be restricted to the same server, > child directories, or some other restriction ? Below is a brief overview of the linkage between the various of components of an IMF composition: - the Composition Playlist (CPL) is the file that is passed to FFMPEG as input (-i) - the CPL is an XML document and defines a playlist - each of the components that make up the playlist is identified by a UUID, i.e. the CPL does not contain file paths/URLs. - the mapping between UUIDs and URLs is done through separate XML files called Asset Maps. Paths to Asset Maps can be provided explicitly through the "-assetmaps" argument, otherwise FFMPEG looks for a file called "ASSETMAP.xml" in the same directory as the CPL file. - according to the standard, all URLs in each Asset Map is relative to the location of the Asset Map, and thus the CPL and the Asset Map have the same origin - some applications have relaxed this constraint and allowed absolute URLs in the Asset Map What is the threat scenario? Is the concern that a malicious actor provides a CPL and Asset Map from origin A that makes malicious requests to a different origin B? > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Breaking DRM is a little like attempting to break through a door even > though the window is wide open and the only thing in the house is a bunch > of things you dont want and which you would get tomorrow for free anyway > ___ > 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 2/3] avformat/imfdec: fail on probing non xml file extension
On Sat, May 6, 2023 at 6:25 AM Michael Niedermayer
wrote:
>
> Its unexpected that a .avi or other "standard" file turns into a playlist.
> The goal of this patch is to avoid this unexpected behavior and possible
> privacy or security differences.
Per the IMF specification, a CPL can have any extension or, in fact,
no extension. The latter is routinely used.
>
> This is similar to the same change to hls
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/imfdec.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> index 7d04d0d853..eafe9a6a26 100644
> --- a/libavformat/imfdec.c
> +++ b/libavformat/imfdec.c
> @@ -926,6 +926,11 @@ static int imf_probe(const AVProbeData *p)
> if (!strstr(p->buf, "ContentTitle>"))
> return 0;
>
> +if (!av_match_ext(p->filename, "xml")) {
> +av_log(NULL, AV_LOG_ERROR, "Not detecting imf with non standard
> extension\n");
> +return 0;
> +}
> +
> return AVPROBE_SCORE_MAX;
> }
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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/jpeg2000dec: Explicitly cast quad_width and quad_height to size_t
On Tue, Apr 25, 2023 at 11:25 AM wrote: > > From: caleb > > Prevents un-necessary casts when calculating buf_size This is to address Coverity CID 1528149: """Suspicious implicit sign extension: "quad_height" with type "uint16_t const" (16 bits, unsigned) is promoted in "4 * quad_width * quad_height" to type "int" (32 bits, signed), then sign-extended to type "unsigned long" (64 bits, unsigned). If "4 * quad_width * quad_height" is greater than 0x7FFF, the upper bits of the result will all be 1.""" > --- > libavcodec/jpeg2000htdec.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavcodec/jpeg2000htdec.c b/libavcodec/jpeg2000htdec.c > index 51cd96e0f1..8907820806 100644 > --- a/libavcodec/jpeg2000htdec.c > +++ b/libavcodec/jpeg2000htdec.c > @@ -592,8 +592,8 @@ static int jpeg2000_decode_ht_cleanup_segment(const > Jpeg2000DecoderContext *s, > const uint16_t is_border_x = width % 2; > const uint16_t is_border_y = height % 2; > > -const uint16_t quad_width = ff_jpeg2000_ceildivpow2(width, 1); > -const uint16_t quad_height = ff_jpeg2000_ceildivpow2(height, 1); > +const size_t quad_width = ff_jpeg2000_ceildivpow2(width, 1); > +const size_t quad_height = ff_jpeg2000_ceildivpow2(height, 1); Shouldn't quad_width and quad_height be kept as uint16_t, and instead be explicitly cast to (size_t) when computing buf_size? > > size_t buf_size = 4 * quad_width * quad_height; > > -- > 2.39.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] MXF - Add jpeg2000 subdescriptor - Sponsored by INA
On Wed, Mar 29, 2023 at 1:54 PM Cédric Le Barz wrote:
>
> Add jpeg2000 subdescriptor in MXF file.
>
> Signed-off-by: Cedric Le Barz
> ---
> ffmpeg/libavformat/mxf.h| 1 +
> ffmpeg/libavformat/mxfenc.c | 74 -
> 2 files changed, 74 insertions(+), 1 deletion(-)
>
> diff --git a/ffmpeg/libavformat/mxf.h b/ffmpeg/libavformat/mxf.h
> index 2561605..7dd1681 100644
> --- a/ffmpeg/libavformat/mxf.h
> +++ b/ffmpeg/libavformat/mxf.h
> @@ -55,6 +55,7 @@ enum MXFMetadataSetType {
> SoundfieldGroupLabelSubDescriptor,
> GroupOfSoundfieldGroupsLabelSubDescriptor,
> FFV1SubDescriptor,
> +JPEG2000SubDescriptor,
> };
>enum MXFFrameLayout {
> diff --git a/ffmpeg/libavformat/mxfenc.c b/ffmpeg/libavformat/mxfenc.c
> index a29d678..3bdf90a 100644
> --- a/ffmpeg/libavformat/mxfenc.c
> +++ b/ffmpeg/libavformat/mxfenc.c
> @@ -390,6 +390,20 @@ static const MXFLocalTagPair mxf_local_tag_batch[] = {
> { 0x8302, FF_MXF_MasteringDisplayWhitePointChromaticity },
> { 0x8303, FF_MXF_MasteringDisplayMaximumLuminance },
> { 0x8304, FF_MXF_MasteringDisplayMinimumLuminance },
> +// ff_mxf_jpeg2000_local_tags
> +{ 0x8400,
> {0x06,0x0E,0x2B,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x04,0x06,0x10,0x00,0x00}},
> /* Sub Descriptors / Opt Ordered array of strong references to sub
> descriptor sets */
> +{ 0x8401,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00}},
> /* 2 bytes : An enumerated value that defines the decoder capabilities. */
Please add to the comment the symbol and type of the attribute as
specified in the SMPTE registers [1] -- it makes it easier to
review/debug.
In the case above, it would be Riz (UInt16).
[1] https://registry.smpte-ra.org/view/published/elements_by_group_view.html
> +{ 0x8402,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x02,0x00,0x00,0x00}},
> /* 4 bytes : Width of the reference grid */
> +{ 0x8403,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x03,0x00,0x00,0x00}},
> /* 4 bytes : Height of the reference grid */
> +{ 0x8404,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x04,0x00,0x00,0x00}},
> /* 4 bytes : Horizontal offset from the origin of the reference grid to
> the left side of the image area */
> +{ 0x8405,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x05,0x00,0x00,0x00}},
> /* 4 bytes : Vertical offset from the origin of the reference grid to
> the left side of the image area */
> +{ 0x8406,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x06,0x00,0x00,0x00}},
> /* 4 bytes : Width of one reference tile with respect to the reference
> grid, */
> +{ 0x8407,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x07,0x00,0x00,0x00}},
> /* 4 bytes : Height of one reference tile with respect to the reference
> grid, */
> +{ 0x8408,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x08,0x00,0x00,0x00}},
> /* 4 bytes : Horizontal offset from the origin of the reference grid to
> the left side of the first tile */
> +{ 0x8409,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x09,0x00,0x00,0x00}},
> /* 4 bytes : Vertical offset from the origin of the reference grid to
> the left side of the first tile */
> +{ 0x840A,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x0A,0x00,0x00,0x00}},
> /* 2 bytes : The number of components in the picture */
> +{ 0x840B,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x0B,0x00,0x00,0x00}},
> /* 8+3n bytes : Array of picture components where each component
> comprises 3 bytes named Ssizi, XRSizi, YRSizi The array of 3-byte
> groups is preceded by the array header comprising a 4-byte value of the
> number of components followed by a 4-byte value of 3. */
> +{ 0x840C,
> {0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x0E,0x00,0x00,0x00}},
> /* The nature and order of the image components in the compressed domain
> as carried in the J2C codestream.. */
> };
>#define MXF_NUM_TAGS FF_ARRAY_ELEMS(mxf_local_tag_batch)
> @@ -1095,8 +1109,8 @@ static const UID mxf_wav_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,
> static const UID mxf_aes3_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x47,0x00
> };
> static const UID mxf_cdci_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x28,0x00
> };
> static const UID mxf_generic_sound_descriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x42,0x00
> };
> -
> static const UID mxf_avc_subdescriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,0x01,0x6E,0x00
> };
> +static const UID mxf_jpeg2000_subdescriptor_key = {
> 0x06,0x0E,0x2B,0x34,0x02,0x53,0x01,0x01,0x0D,0x01,0x01,0x01,0x01,0x01,0x5A,00
> };
>
Re: [FFmpeg-devel] [PATCH v3 2/3] avcodec/jpeg2000dec: add support for HTJ2K block decoding
On Wed, Apr 19, 2023 at 1:55 PM Tomas Härdin wrote: > > Looks like my comments have been addressed, especially per-CB style Thanks for the review. I plan to merge the patchset this weekend. > > /Tomas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] avformat/mxfenc: fix stored/sampled/displayed width/height
On Mon, Mar 13, 2023 at 3:30 PM Marton Balint wrote: > > > > On Fri, 10 Mar 2023, Marton Balint wrote: > > > > > > > On Mon, 6 Mar 2023, Nicolas Gaullier wrote: > > > > The width is one thing; for whatever reason, there is a divergence > > between DV100 on one hand and AVCI/XDCAMHD35 on the other. In my > > understanding, in current practices, DV obey s337 (stored width > > includes scaling) but >xdcam does not, so current code is fine > > >but maybe this is an opportunity to document this ? > > AFAIK: > - DV in MXF: found old Omneon with no scaling for stored value, no > sampled value (so stored value), scaled value for displayed value, old > Quantel with scaling everywhere. From my understanding of spec, I would > keep the scaling. > - MPEG-2 Video including XDCAMHD35 in MXF obey "including any decoder > scaling or padding" wording with a 16x16 rounding for height, I have no > file not 1920 or 3840 width > - AVC in MXF: found old Omneon or old Quantel or old Telestream with no > padding value for stored value (height of 540 for interlaced). I don't > understand why it is not same as with MPEG-2 Video so I don't touch > FFmpeg behavior >there (rounding). Actually checking >again SMPTE ST > 381-2013, there is an explicit example: "1088: 1080-line progressive". > >>> > >>> I totally agree they are so many weird things in the wild, particularly > >>> looking at some early implementations. I also have fully broken DV100 and > >>> XDCAMHD35 Omneon records with release v6.1 (2010) at the early stages of > >>> HD, but it was fixed afterwards (with many other >issues too!). Looking > >>> at GVG, 1440x1088i stored size was implemented from the early beginnings > >>> (2010 too) : sample clips are still available here : > >>> http://www.gvgdevelopers.com/concrete/products/k2/test_clips/ > >>> There is also "kind of" reference sony implementation available here both > >>> for xdcamhd35/avc-1440: > >>> https://www.sonycreativesoftware.com/catalystbrowse > >>> Anyway, I think we all agree not to change anything related to MPEG2 and > >>> AVC. > >>> > I don't have DV in MXF with non multiple of 16 (I thought that DV is > only 720x576 or 720x480 or 1280x720 or 1920x1080, all values multiple of > 16) and don't know about video encoding in DV so I didn't want to change > the behavior of FFmpeg when I don't know, but case AV_CODEC_ID_DVVIDEO: > line could be definitely removed if it is fine for you. > >>> DV is questionable. Currently, the dust is under the rug (as a defaults > >>> behaviour), which is an issue with very little concern. > >>> Now, with the patch, the dust become visible, the DV rule is made > >>> explicit and moreover it is presented as an exception, sharing code with > >>> macroblock codecs... I think it is time to fix, even if it was not your > >>> prior intention. > >>> I don't have an extensive experience with DV too, I just have samples > >>> here and there like you, but it seems we share the same information. > >>> Let see if someone else react and ask for keeping the current 1088 lines > >>> for DV stored height, but if nobody does, I think it should be okay. > >>> > Do you want me to add a comment line e.g. "obey 'including any decoder > scaling or padding' from SMPTE ST 377"? > >>> I am not a core developer and will let others give their feedback. My > >>> personal opinion is that the spec is supposed to be well known and does > >>> not require commenting, but that it would be interesting to explicit why > >>> we make a difference between DV and MPEG2/AVC. And >personally, I don't > >>> have the answer to this question. If nobody has one, maybe a comment > >>> could say "because this is the observed common practice". > >>> > >>> Nicolas > >> > >> Some weeks later now and no replies, maybe time to go on ? > >> I think the "case AV_CODEC_ID_DVVIDEO:" can be removed as discussed, fate > >> updated and that should be ok for everybody. > >> (Ideally, it could have been an opportunity to document why we have this > >> "DV exception", but I understand it is not very comfortable to write as > >> there is no meaningful reason, so forget about this, this won't hold up > >> the patch anyway) > >> For information, there was a long thread recently on ffmpeg-user about a > >> "bug" in dnxhd stored_height (will be fixed with your patch): > >> https://ffmpeg.org/pipermail/ffmpeg-user/2023-February/056111.html > > > > Will apply the patch in a couple of days unless somebody objects. If you > > want > > to change DV height (seems reasonable), please send a follow up patch with > > fate updates after that. > > Oh, this patch needs a fate update as well. On that note, DNXHD is a > macroblock-based codec, so why are we changing 1088 height to 1080? I > could ask the same for ProRes. The patch should explain better why those >
[FFmpeg-devel] Making progress re: jpeg2000dec patchsets
Hi Caleb, Tomas et al., I have been experimenting with combining the HTJ2K patchset [1] and the J2K test patchset [2]: (a) neither valgrind nor the fuzzer seem to complain (b) there are code style/cosmetic issues (c) the HTJ2K block decoder does not yet support placeholder passes [3], which are not necessarily present I do not think that (c) is a blocker and recommend that we plan on merging the combined patchset once the code style/cosmetic issues are fixed. The idea is to have a baseline from which performance and feature set can be improved. Any major concerns with this plan? I am happy to take a stab at cleaning up the code, unless someone wishes to do it. Best, -- Pierre [1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8117 [2] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8108 [3] https://ds.jpeg.org/documents/jpeg2000/wg1n100431-098-COM-Guidelines_on_Packet_Parsing_and_Construction_for_HTJ2K.pdf ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/imfdec: remove the experimental flag
On Mon, Feb 20, 2023 at 9:55 AM Anton Khirnov wrote:
>
> Quoting p...@sandflow.com (2023-01-06 00:29:44)
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > libavformat/imfdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > index 03de9ce151..a92686e93b 100644
> > --- a/libavformat/imfdec.c
> > +++ b/libavformat/imfdec.c
> > @@ -1018,7 +1018,7 @@ static const AVClass imf_class = {
> > const AVInputFormat ff_imf_demuxer = {
> > .name = "imf",
> > .long_name = NULL_IF_CONFIG_SMALL("IMF (Interoperable Master
> > Format)"),
> > -.flags = AVFMT_EXPERIMENTAL | AVFMT_NO_BYTE_SEEK,
> > +.flags = AVFMT_NO_BYTE_SEEK,
>
> The demuxer has been upstream for quite a while without too many issues,
> so I'd say this is reasonable.
Ok. Will apply tomorrow unless objections are raised.
>
> --
> Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] lavfi/vf_colorspace: Add SMPTE ST 2084 support
On Fri, Feb 3, 2023 at 7:54 AM Tomas Härdin wrote: > > We need something better for proper tonemap support, but this is at > least useful for getting the HDR discussion going. Below is a demonstration of two tonemap methods: https://www.sandflow.com/public/tone-mapping/index.html > > /Tomas > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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/matroska: add support for ARIB captions
On Fri, Jan 13, 2023 at 9:27 AM rcombs wrote:
>
> Not yet ready for merge, pending finalization of the standard proposal for
> this mapping:
> https://github.com/ietf-wg-cellar/matroska-specification/pull/724
Is sample ARIB caption available?
> ---
> libavformat/matroska.c| 1 +
> libavformat/matroskadec.c | 30 ++
> libavformat/matroskaenc.c | 23 +++
> 3 files changed, 54 insertions(+)
>
> diff --git a/libavformat/matroska.c b/libavformat/matroska.c
> index 90d94b65bf..79b2d09984 100644
> --- a/libavformat/matroska.c
> +++ b/libavformat/matroska.c
> @@ -76,6 +76,7 @@ const CodecTags ff_mkv_codec_tags[]={
> {"S_DVBSUB" , AV_CODEC_ID_DVB_SUBTITLE},
> {"S_HDMV/PGS" , AV_CODEC_ID_HDMV_PGS_SUBTITLE},
> {"S_HDMV/TEXTST", AV_CODEC_ID_HDMV_TEXT_SUBTITLE},
> +{"S_ARIBSUB", AV_CODEC_ID_ARIB_CAPTION},
>
> {"V_AV1", AV_CODEC_ID_AV1},
> {"V_AVS2" , AV_CODEC_ID_AVS2},
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d582f566a2..3a888e3ada 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -50,6 +50,7 @@
> #include "libavutil/time_internal.h"
> #include "libavutil/spherical.h"
>
> +#include "libavcodec/avcodec.h"
> #include "libavcodec/bytestream.h"
> #include "libavcodec/flac.h"
> #include "libavcodec/mpeg4audio.h"
> @@ -2813,6 +2814,35 @@ static int matroska_parse_tracks(AVFormatContext *s)
> /* we don't need any value stored in CodecPrivate.
> make sure that it's not exported as extradata. */
> track->codec_priv.size = 0;
> +} else if (codec_id == AV_CODEC_ID_ARIB_CAPTION &&
> track->codec_priv.size == 3) {
> +int component_tag = track->codec_priv.data[0];
> +int data_component_id = AV_RB16(track->codec_priv.data + 1);
> +
> +switch (data_component_id) {
> +case 0x0008:
> +// [0x30..0x37] are component tags utilized for
> +// non-mobile captioning service ("profile A").
> +if (component_tag >= 0x30 && component_tag <= 0x37) {
> +st->codecpar->profile = FF_PROFILE_ARIB_PROFILE_A;
> +}
> +break;
> +case 0x0012:
> +// component tag 0x87 signifies a mobile/partial reception
> +// (1seg) captioning service ("profile C").
> +if (component_tag == 0x87) {
> +st->codecpar->profile = FF_PROFILE_ARIB_PROFILE_C;
> +}
> +break;
> +default:
> +break;
> +}
> +
> +if (st->codecpar->profile == FF_PROFILE_UNKNOWN)
> +av_log(matroska->ctx, AV_LOG_WARNING,
> + "Unknown ARIB caption profile utilized: %02x /
> %04x\n",
> + component_tag, data_component_id);
> +
> +track->codec_priv.size = 0;
> }
> track->codec_priv.size -= extradata_offset;
>
> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> index 2deb4284e8..67cfec761a 100644
> --- a/libavformat/matroskaenc.c
> +++ b/libavformat/matroskaenc.c
> @@ -58,6 +58,7 @@
> #include "libavutil/stereo3d.h"
>
> #include "libavcodec/av1.h"
> +#include "libavcodec/avcodec.h"
> #include "libavcodec/codec_desc.h"
> #include "libavcodec/xiph.h"
> #include "libavcodec/mpeg4audio.h"
> @@ -1142,6 +1143,27 @@ static int
> mkv_assemble_native_codecprivate(AVFormatContext *s, AVIOContext *dyn
> else
> *size_to_reserve = MAX_PCE_SIZE;
> break;
> +case AV_CODEC_ID_ARIB_CAPTION: {
> +unsigned stream_identifier, data_component_id;
> +switch (par->profile) {
> +case FF_PROFILE_ARIB_PROFILE_A:
> +stream_identifier = 0x30;
> +data_component_id = 0x0008;
> +break;
> +case FF_PROFILE_ARIB_PROFILE_C:
> +stream_identifier = 0x87;
> +data_component_id = 0x0012;
> +break;
> +default:
> +av_log(s, AV_LOG_ERROR,
> + "Unset/unknown ARIB caption profile %d utilized!\n",
> + par->profile);
> +return AVERROR_INVALIDDATA;
> +}
> +avio_w8(dyn_cp, stream_identifier);
> +avio_wb16(dyn_cp, data_component_id);
> +break;
> +}
> #endif
> default:
> if (CONFIG_MATROSKA_MUXER && par->codec_id == AV_CODEC_ID_PRORES &&
> @@ -3274,6 +3296,7 @@ static const AVCodecTag additional_subtitle_tags[] = {
> { AV_CODEC_ID_DVB_SUBTITLE, 0x },
> { AV_CODEC_ID_DVD_SUBTITLE, 0x },
> { AV_CODEC_ID_HDMV_PGS_SUBTITLE, 0x },
> +{ AV_CODEC_ID_ARIB_CAPTION, 0x },
> { AV_CODEC_ID_NONE, 0x }
> };
>
> --
> 2.38.1
>
>
Re: [FFmpeg-devel] [PATCH v1] fate/imfdec: add audio test
Quick ping. This adds an audio test for the IMF demuxer FATE suite, which currently only has image tests. On Thu, Dec 29, 2022 at 11:12 PM wrote: > > From: Pierre-Anthony Lemieux > > Adds an audio test for the IMF demuxer. > > FATE content at https://www.sandflow.com/public/countdown-audio.zip > > --- > tests/fate/imf.mak| 3 + > tests/ref/fate/imf-cpl-with-audio | 207 ++ > 2 files changed, 210 insertions(+) > create mode 100644 tests/ref/fate/imf-cpl-with-audio > > diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak > index feb54d1361..49ab35e7d9 100644 > --- a/tests/fate/imf.mak > +++ b/tests/fate/imf.mak > @@ -1,6 +1,9 @@ > FATE_IMF += fate-imf-cpl-with-repeat > fate-imf-cpl-with-repeat: CMD = framecrc -f imf -i > $(TARGET_SAMPLES)/imf/countdown/CPL_bb2ce11c-1bb6-4781-8e69-967183d02b9b.xml > -c:v copy > > +FATE_IMF += fate-imf-cpl-with-audio > +fate-imf-cpl-with-audio: CMD = framecrc -f imf -i > $(TARGET_SAMPLES)/imf/countdown-audio/CPL_688f4f63-a317-4271-99bf-51444ff39c5b.xml > -c:a copy > + > FATE_SAMPLES_FFMPEG-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF) > > fate-imfdec: $(FATE_IMF) > diff --git a/tests/ref/fate/imf-cpl-with-audio > b/tests/ref/fate/imf-cpl-with-audio > new file mode 100644 > index 00..0a1d87631a > --- /dev/null > +++ b/tests/ref/fate/imf-cpl-with-audio > @@ -0,0 +1,207 @@ > +#tb 0: 1/24 > +#media_type 0: video > +#codec_id 0: rawvideo > +#dimensions 0: 640x360 > +#sar 0: 0/1 > +#tb 1: 1/48000 > +#media_type 1: audio > +#codec_id 1: pcm_s24le > +#sample_rate 1: 48000 > +#channel_layout_name 1: stereo > +0, 0, 0,1, 1382400, 0x6a2c410c > +1, 0, 0, 1920,11520, 0x974f4bab > +1, 1920, 1920, 1920,11520, 0xdf793f69 > +0, 1, 1,1, 1382400, 0x5f0c67d2 > +1, 3840, 3840, 1920,11520, 0xfd69559a > +0, 2, 2,1, 1382400, 0x408e1262 > +1, 5760, 5760, 1920,11520, 0x28fa469b > +0, 3, 3,1, 1382400, 0x3567d455 > +1, 7680, 7680, 1920,11520, 0xe49161cf > +0, 4, 4,1, 1382400, 0x2312e68b > +1, 9600, 9600, 1920,11520, 0xb92c49ae > +0, 5, 5,1, 1382400, 0xe3d84ec2 > +1, 11520, 11520, 1920,11520, 0xd2b75d46 > +0, 6, 6,1, 1382400, 0xdbb3ab8c > +1, 13440, 13440, 1920,11520, 0xa13b5a9b > +0, 7, 7,1, 1382400, 0xeb250513 > +1, 15360, 15360, 1920,11520, 0xfe804299 > +0, 8, 8,1, 1382400, 0x26c3c8c0 > +1, 17280, 17280, 1920,11520, 0x7a8654d4 > +0, 9, 9,1, 1382400, 0xbc41a23e > +1, 19200, 19200, 1920,11520, 0x1a2e48a4 > +0, 10, 10,1, 1382400, 0x49d6a8de > +1, 21120, 21120, 1920,11520, 0x20504669 > +0, 11, 11,1, 1382400, 0x5e05cfa4 > +1, 23040, 23040, 960, 5760, 0x74bf38f6 > +0, 12, 12,1, 1382400, 0x01327a34 > +1, 24000, 24000, 1920,11520, 0x974f4bab > +1, 25920, 25920, 1920,11520, 0xdf793f69 > +0, 13, 13,1, 1382400, 0x06ce3c36 > +1, 27840, 27840, 1920,11520, 0xfd69559a > +0, 14, 14,1, 1382400, 0x6aa24e6c > +1, 29760, 29760, 1920,11520, 0x28fa469b > +0, 15, 15,1, 1382400, 0x55d8b694 > +1, 31680, 31680, 1920,11520, 0xe49161cf > +0, 16, 16,1, 1382400, 0xcc6f136d > +1, 33600, 33600, 1920,11520, 0xb92c49ae > +0, 17, 17,1, 1382400, 0xe92b6ce5 > +1, 35520, 35520, 1920,11520, 0xd2b75d46 > +0, 18, 18,1, 1382400, 0x664d30a1 > +1, 37440, 37440, 1920,11520, 0xa13b5a9b > +0, 19, 19,1, 1382400, 0x09d80a1f > +1, 39360, 39360, 1920,11520, 0xfe804299 > +0, 20, 20,1, 1382400, 0x2b58536e > +1, 41280, 41280, 1920,11520, 0x7a8654d4 > +0, 21, 21,1, 1382400, 0xf24b7a34 > +1, 43200, 43200, 1920,11520, 0x1a2e48a4 > +0, 22, 22,1, 1382400, 0xe2a524c4 > +1, 45120, 45120, 1920,11520, 0x20504669 > +0, 23, 23,1, 1382400, 0xe841e6b7 > +1, 47040, 47040, 1920,11520, 0x7ad44ba6 > +0, 24, 24,
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/imfdec: remove the experimental flag
On Fri, Jan 6, 2023 at 8:09 AM Tomas Härdin wrote:
>
> fre 2023-01-06 klockan 07:50 -0800 skrev Pierre-Anthony Lemieux:
> > On Fri, Jan 6, 2023 at 7:45 AM Tomas Härdin wrote:
> > >
> > > tor 2023-01-05 klockan 15:29 -0800 skrev p...@sandflow.com:
> > > > From: Pierre-Anthony Lemieux
> > > >
> > > > ---
> > > > libavformat/imfdec.c | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > > > index 03de9ce151..a92686e93b 100644
> > > > --- a/libavformat/imfdec.c
> > > > +++ b/libavformat/imfdec.c
> > > > @@ -1018,7 +1018,7 @@ static const AVClass imf_class = {
> > > > const AVInputFormat ff_imf_demuxer = {
> > > > .name = "imf",
> > > > .long_name = NULL_IF_CONFIG_SMALL("IMF (Interoperable
> > > > Master Format)"),
> > > > -.flags = AVFMT_EXPERIMENTAL | AVFMT_NO_BYTE_SEEK,
> > > > +.flags = AVFMT_NO_BYTE_SEEK,
> > > > .flags_internal = FF_FMT_INIT_CLEANUP,
> > > > .priv_class = _class,
> > > > .priv_data_size = sizeof(IMFContext),
> > >
> > > This demuxer is really limited though, right?
> >
> > Can you clarify what you mean by "limited"?
> >
> > The demuxer is intended to only process IMF packages (playlist +
> > track files).
>
> Perhaps I was speaking ahead. Last time I looked lavf was not capable
> of performing the kind of NLE functionality required for full IMF
> support. Perhaps imfdec does that internally? It doesn't seem so..
The demuxer supports the full range of playlist (CPL) functionality,
including multiple non-coincident resources and resource repeats.
Only audio and image are supported for now.
See the current FATE test and the additional proposal sample at:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20221230071243.24762-1-...@sandflow.com/
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/imfdec: remove the experimental flag
On Fri, Jan 6, 2023 at 7:45 AM Tomas Härdin wrote:
>
> tor 2023-01-05 klockan 15:29 -0800 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > libavformat/imfdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > index 03de9ce151..a92686e93b 100644
> > --- a/libavformat/imfdec.c
> > +++ b/libavformat/imfdec.c
> > @@ -1018,7 +1018,7 @@ static const AVClass imf_class = {
> > const AVInputFormat ff_imf_demuxer = {
> > .name = "imf",
> > .long_name = NULL_IF_CONFIG_SMALL("IMF (Interoperable
> > Master Format)"),
> > -.flags = AVFMT_EXPERIMENTAL | AVFMT_NO_BYTE_SEEK,
> > +.flags = AVFMT_NO_BYTE_SEEK,
> > .flags_internal = FF_FMT_INIT_CLEANUP,
> > .priv_class = _class,
> > .priv_data_size = sizeof(IMFContext),
>
> This demuxer is really limited though, right?
Can you clarify what you mean by "limited"?
The demuxer is intended to only process IMF packages (playlist + track files).
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] GSoC 2023
I have updated the page with the HTJ2K project. This is a good opportunity to ask for help completing the review of the patchset: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=8078 All known issues have been resolved and it would be good to merge soon, i.e. beat the iron while it is hot. On Thu, Dec 15, 2022 at 6:47 AM Jean-Baptiste Kempf wrote: > > Hello, > > Also, please don’t copy paste ideas from previous years. If the idea did not > get picked up for years, it won’t be more useful this year. > > jb > > On Thu, 15 Dec 2022, at 15:42, Thilo Borgmann wrote: > > Hi, > > > > as we figured during the last dev meeting on December 2nd we want to > > apply again for GSoC 2023. > > > > I told mentors often enough already that it's a vital point in our > > applications to have a properly filled results page from the last GSoC > > we did. > > Last time no mentor cared about this - we can be quite sure that our > > application will fail if we don't have [1] up-to-date until we send our > > application. > > > > Also vital for the application are already existing project ideas so > > everyone interested in mentoring a project in 2023, please add your > > idea(s) to [2]. > > > > The application deadline is January 23rd, I will aim for sending an > > application mid January. > > > > Thanks, > > Thilo > > > > [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022/Results > > [2] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2023 > > ___ > > 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". > > -- > Jean-Baptiste Kempf - President > +33 672 704 734 > ___ > 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 2/2] avcodec/jpeg2000dec: Add support for HTJ2K decoding.
On Fri, Dec 2, 2022 at 10:46 AM Tomas Härdin wrote:
>
> fre 2022-12-02 klockan 21:11 +0300 skrev etemesica...@gmail.com:
> >
> > +/**
> > + * Given a precomputed c, checks whether n % d == 0
> > + */
> > +static av_always_inline uint32_t is_divisible(uint32_t n, uint64_t
> > c)
> > +{
> > +return n * c <= c - 1;
> > +}
>
> This looks like something that could go in lavu, say intmath.h
Two thoughts:
- `is_divisible(n, c)` doesn't make sense without the matching
`precompute_c(d)`. I suggest at least modifying the documentation for
`is_divisible` and possibly defining `precompute_c(d)`
- I suggest focusing this patchset on Part 15 decoding, and
refactoring common math functions into intmath.h as a follow-up step
>
> > +
> > +/**
> > + * @brief Refill the buffer backwards in little Endian while
> > skipping
> > + * over stuffing bits
> > + *
> > + * Stuffing bits are those that appear in the position of any byte
> > whose
> > + * LSBs are all 1's if the last consumed byte was larger than 0x8F
> > + */
> > +static int jpeg2000_bitbuf_refill_backwards(StateVars *buffer,
> > +const uint8_t *array)
>
> Don't we already have sufficient bitreading capabilities already? Maybe
> it doesn't do the necessary unstuffing..
>
>
> > +/*
> > + * As an optimization, we can replace modulo operations with
> > + * checking if a number is divisible , since that's the only
> > thing we need.
> > + * this is paired with is_divisible.
> > + * Credits to Daniel Lemire blog post:
> > + *
> > https://lemire.me/blog/2019/02/08/faster-remainders-when-the-divisor-is-a-constant-beating-compilers-and-libdivide/
> > + * It's UB on zero, but we can't have a quad being zero, the
> > spec doesn't allow,
> > + * so we error out early in case that's the case.
> > + */
> > +
> > +c = 1 + UINT64_C(0x) / quad_width;
>
> Just 0xULL would work
+1
>
> > +
> > +for (int row = 1; row < quad_height; row++) {
> > +while ((q - (row * quad_width)) < quad_width - 1 && q <
> > (quad_height * quad_width)) {
> > +q1 = q;
> > +q2 = q + 1;
> > +context1 = sigma_n[4 * (q1 - quad_width) + 1];
> > +context1 += sigma_n[4 * (q1 - quad_width) + 3] << 2; //
> > ne
> > +
> > +if (!is_divisible(q1, c)) {
>
> These divisibility checks look like they could be even simpler given
> that q always increases by 2
Is the idea that `q1 mod d` can be sped up knowing that `d = 2 n + {0,
1}`? Per the below, I suggest tackling finer optimizations in
follow-up patchsets.
>
> > +context1 |= sigma_n[4 * (q1 - quad_width) -
> > 1]; // nw
> > +context1 += (sigma_n[4 * q1 - 1] | sigma_n[4 * q1 -
> > 2]) << 1; // sw| q
> > +}
> > +if (!is_divisible(q1 + 1, c))
> > +context1 |= sigma_n[4 * (q1 - quad_width) + 5] << 2;
> > +
> > +if ((ret = jpeg2000_decode_sig_emb(s, mel_state,
> > mel_stream, vlc_stream,
> > + dec_CxtVLC_table1,
> > Dcup, sig_pat, res_off,
> > + emb_pat_k, emb_pat_1,
> > J2K_Q1, context1, Lcup,
> > + Pcup))
> > +< 0)
> > +goto free;
> > +
> > +for (int i = 0; i < 4; i++)
> > +sigma_n[4 * q1 + i] = (sig_pat[J2K_Q1] >> i) & 1;
> > +
> > +context2 = sigma_n[4 * (q2 - quad_width) + 1];
> > +context2 += sigma_n[4 * (q2 - quad_width) + 3] << 2;
> > +
> > +if (!is_divisible(q2, c)) {
> > +context2 |= sigma_n[4 * (q2 - quad_width) - 1];
> > +context2 += (sigma_n[4 * q2 - 1] | sigma_n[4 * q2 -
> > 2]) << 1;
> > +}
> > +if (!is_divisible(q2 + 1, c))
> > +context2 |= sigma_n[4 * (q2 - quad_width) + 5] << 2;
> > +
> > +if ((ret = jpeg2000_decode_sig_emb(s, mel_state,
> > mel_stream, vlc_stream,
> > + dec_CxtVLC_table1,
> > Dcup, sig_pat, res_off,
> > + emb_pat_k, emb_pat_1,
> > J2K_Q2, context2, Lcup,
> > + Pcup))
> > +< 0)
> > +goto free;
> > +
> > +for (int i = 0; i < 4; i++)
> > +sigma_n[4 * q2 + i] = (sig_pat[J2K_Q2] >> i) & 1;
> > +
> > +u[J2K_Q1] = 0;
> > +u[J2K_Q2] = 0;
> > +
> > +jpeg2000_bitbuf_refill_backwards(vlc_stream, vlc_buf);
> > +
> > +if (res_off[J2K_Q1] == 1 && res_off[J2K_Q2] == 1) {
> > +u_pfx[J2K_Q1] = vlc_decode_u_prefix(vlc_stream,
> > vlc_buf);
> > +u_pfx[J2K_Q2] = vlc_decode_u_prefix(vlc_stream,
> > vlc_buf);
> > +
> > +u_sfx[J2K_Q1] = vlc_decode_u_suffix(vlc_stream,
Re: [FFmpeg-devel] [PATCH v2 1/3] avformat/imfdec: use CPL start timecode if available
Hi Zane et al.,
Quick ping on the revised patchset below.
It addresses https://trac.ffmpeg.org/ticket/9842.
Best,
-- Pierre
On Sun, Oct 2, 2022 at 9:28 AM wrote:
>
> From: Pierre-Anthony Lemieux
>
> The IMF CPL contains an optional timecode start address. This patch reads the
> latter, if present, into the context's timecode metadata parameter.
> This addresses https://trac.ffmpeg.org/ticket/9842.
>
> ---
> libavformat/imf.h | 2 +
> libavformat/imf_cpl.c | 106 ++
> libavformat/imfdec.c | 11 +
> 3 files changed, 119 insertions(+)
>
> diff --git a/libavformat/imf.h b/libavformat/imf.h
> index 4271cd9582..70ed007312 100644
> --- a/libavformat/imf.h
> +++ b/libavformat/imf.h
> @@ -59,6 +59,7 @@
> #include "libavformat/avio.h"
> #include "libavutil/rational.h"
> #include "libavutil/uuid.h"
> +#include "libavutil/timecode.h"
> #include
>
> /**
> @@ -130,6 +131,7 @@ typedef struct FFIMFCPL {
> AVUUID id_uuid; /**<
> CompositionPlaylist/Id element */
> xmlChar *content_title_utf8; /**<
> CompositionPlaylist/ContentTitle element */
> AVRational edit_rate;/**<
> CompositionPlaylist/EditRate element */
> +AVTimecode *tc; /**<
> CompositionPlaylist/CompositionTimecode element */
> FFIMFMarkerVirtualTrack *main_markers_track; /**< Main Marker
> Virtual Track */
> FFIMFTrackFileVirtualTrack *main_image_2d_track; /**< Main Image Virtual
> Track */
> uint32_t main_audio_track_count; /**< Number of Main
> Audio Virtual Tracks */
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index 474db6b7f5..183e6dd84e 100644
> --- a/libavformat/imf_cpl.c
> +++ b/libavformat/imf_cpl.c
> @@ -116,6 +116,22 @@ int ff_imf_xml_read_uint32(xmlNodePtr element, uint32_t
> *number)
> return ret;
> }
>
> +static int ff_imf_xml_read_boolean(xmlNodePtr element, int *value)
> +{
> +int ret = 0;
> +
> +xmlChar *element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> +if (xmlStrcmp(element_text, "true") == 0 || xmlStrcmp(element_text, "1")
> == 0)
> +*value = 1;
> +else if (xmlStrcmp(element_text, "false") == 0 ||
> xmlStrcmp(element_text, "0") == 0)
> +*value = 0;
> +else
> +ret = 1;
> +xmlFree(element_text);
> +
> +return ret;
> +}
> +
> static void imf_base_virtual_track_init(FFIMFBaseVirtualTrack *track)
> {
> memset(track->id_uuid, 0, sizeof(track->id_uuid));
> @@ -179,6 +195,90 @@ static int fill_content_title(xmlNodePtr cpl_element,
> FFIMFCPL *cpl)
> return 0;
> }
>
> +static int digit_to_int(char digit)
> +{
> +if (digit >= '0' && digit <= '9')
> +return digit - '0';
> +return -1;
> +}
> +
> +/**
> + * Parses a string that conform to the TimecodeType used in IMF CPL and
> defined
> + * in SMPTE ST 2067-3.
> + * @param[in] s string to parse
> + * @param[out] tc_comps pointer to an array of 4 integers where the parsed
> HH,
> + * MM, SS and FF fields of the timecode are returned.
> + * @return 0 on success, < 0 AVERROR code on error.
> + */
> +static int parse_cpl_tc_type(const char *s, int *tc_comps)
> +{
> +if (av_strnlen(s, 11) != 11)
> +return AVERROR(EINVAL);
> +
> +for (int i = 0; i < 4; i++) {
> +int hi;
> +int lo;
> +
> +hi = digit_to_int(s[i * 3]);
> +lo = digit_to_int(s[i * 3 + 1]);
> +
> +if (hi == -1 || lo == -1)
> +return AVERROR(EINVAL);
> +
> +tc_comps[i] = 10 * hi + lo;
> +}
> +
> +return 0;
> +}
> +
> +static int fill_timecode(xmlNodePtr cpl_element, FFIMFCPL *cpl)
> +{
> +xmlNodePtr tc_element = NULL;
> +xmlNodePtr element = NULL;
> +xmlChar *tc_str = NULL;
> +int df = 0;
> +int comps[4];
> +int ret = 0;
> +
> +tc_element = ff_imf_xml_get_child_element_by_name(cpl_element,
> "CompositionTimecode");
> +if (!tc_element)
> + return 0;
> +
> +element = ff_imf_xml_get_child_element_by_name(tc_element,
> "TimecodeDropFrame");
> +if (!element) {
> +av_log(NULL, AV_LOG_ERROR, "CompositionTimecode element is missing\
> +a TimecodeDropFrame child element\n");
> +return AVERROR_INVALIDDATA;
> +}
&
Re: [FFmpeg-devel] [PATCH] Encrypted SMPTE DC MXF - additional UL needed to unpack EKLV packet
On Tue, Oct 4, 2022 at 7:59 AM Tomas Härdin wrote: > > tis 2022-10-04 klockan 07:50 -0700 skrev Pierre-Anthony Lemieux: > > On Tue, Oct 4, 2022 at 7:29 AM Tomas Härdin wrote: > > > > > > mån 2022-10-03 klockan 11:47 + skrev Richard Ayres: > > > > Thanks, Pierre-Anthony. I've updated the patch to remove the > > > > unnecessary UL and it's now using mxf_match_uid() to detect the > > > > EKLV > > > > packet. > > > > > > > > Signed-off-by: Richard Ayres > > > > --- > > > > libavformat/mxfdec.c | 4 ++-- > > > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > > > > index badd2be224..b1ab90f25f 100644 > > > > --- a/libavformat/mxfdec.c > > > > +++ b/libavformat/mxfdec.c > > > > @@ -3737,7 +3737,7 @@ static int mxf_read_header(AVFormatContext > > > > *s) > > > > > > > > PRINT_KEY(s, "read header", klv.key); > > > > av_log(s, AV_LOG_TRACE, "size %"PRIu64" offset > > > > %#"PRIx64"\n", klv.length, klv.offset); > > > > -if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key) || > > > > +if (mxf_match_uid(klv.key, mxf_encrypted_triplet_key, > > > > > > Why do we have IS_KLV_KEY at all? I feel it is only appropriate in > > > cases where we have to deal with less-than-standard files, or if we > > > explicitly have to differentiate between different versions of > > > relevant > > > specs. > > > > SMPTE ULs should always be compared ignoring the version byte -- but > > for exceptional cases. > > > > mxf_match_uid() should probably be renamed mxf_match_ul() since a UID > > can also be a UUID and. > > Oh yeah, UUIDs *must* be just memcpy()'d IIRC. Perhaps we should have > three functions to be extra explicit: mxf_match_ul(), mxf_match_uid() > and mxf_match_uuid().. av_uuid_equal() already exists. > > /Tomas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] Encrypted SMPTE DC MXF - additional UL needed to unpack EKLV packet
On Tue, Oct 4, 2022 at 7:29 AM Tomas Härdin wrote: > > mån 2022-10-03 klockan 11:47 + skrev Richard Ayres: > > Thanks, Pierre-Anthony. I've updated the patch to remove the > > unnecessary UL and it's now using mxf_match_uid() to detect the EKLV > > packet. > > > > Signed-off-by: Richard Ayres > > --- > > libavformat/mxfdec.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c > > index badd2be224..b1ab90f25f 100644 > > --- a/libavformat/mxfdec.c > > +++ b/libavformat/mxfdec.c > > @@ -3737,7 +3737,7 @@ static int mxf_read_header(AVFormatContext *s) > > > > PRINT_KEY(s, "read header", klv.key); > > av_log(s, AV_LOG_TRACE, "size %"PRIu64" offset > > %#"PRIx64"\n", klv.length, klv.offset); > > -if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key) || > > +if (mxf_match_uid(klv.key, mxf_encrypted_triplet_key, > > Why do we have IS_KLV_KEY at all? I feel it is only appropriate in > cases where we have to deal with less-than-standard files, or if we > explicitly have to differentiate between different versions of relevant > specs. SMPTE ULs should always be compared ignoring the version byte -- but for exceptional cases. mxf_match_uid() should probably be renamed mxf_match_ul() since a UID can also be a UUID and. > > Patch looks OK +1 > > /Tomas > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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/1] Enable building with WSL and MSVC
On Mon, Oct 3, 2022 at 1:11 AM Julio C. Rocha wrote:
>
> On Sun, Oct 2, 2022 at 5:19 PM Pierre-Anthony Lemieux
> wrote:
>
> > On Sun, Oct 2, 2022 at 5:14 PM Timo Rothenpieler
> > wrote:
> > >
> > > On 03.10.2022 01:47, Julio C. Rocha wrote:
> > > > ---
> > > > configure | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/configure b/configure
> > > > index 6712d045d9..f5f5eb29dd 100755
> > > > --- a/configure
> > > > +++ b/configure
> > > > @@ -4847,7 +4847,12 @@ probe_cc(){
> > > > else
> > > > _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d
> > '\r')
> > > > fi
> > > > -_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1
> > | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> > > > +if [ "$(grep -i Microsoft /proc/version)" ]; then
> > >
> > > Not convinced that this is a good check.
> > > I can think of a few other situations where Microsoft might appear in
> > > there. Like, for example on one of their servers, Azure Cloud, Github
> > > Actions and so on.
> > >
> > > > +# Windows Subsystem for Linux
> > > > +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $<
> > 2>&1 | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) { cmd="/usr/bin/wslpath \x27" $$0 "\x27"; cmd |& getline
> > pth; print "$@:", pth } }'\'' > $(@:.o=.d)'
> > > > +else
> > > > +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $<
> > 2>&1 | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> > > > +fi
> > > > _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> > > > _cflags_speed="-O2"
> > > > _cflags_size="-O1"
> > >
> > >
> > > What actual issue is this solving?
> > > I've been building in WSL for years, including MSVC builds, and never
> > > encountered any problems.
> >
> > FWIW. I am currently building on WSL:
> >
> > $ uname -a
> > Linux pal-x 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2
> > 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
> >
> > $ lsb_release -a
> > No LSB modules are available.
> > Distributor ID: Ubuntu
> > Description:Ubuntu 20.04.4 LTS
> > Release:20.04
> > Codename: focal
> >
>
> Noted, Pierre.
> Are you able to build using the Visual Studio compilers (MSVC) without any
> further hacking?
I had never tried it. Quick attempt results in:
$ ./configure --toolchain=msvc
cl.exe is unable to create an executable file.
If cl.exe is a cross-compiler, use the --enable-cross-compile option.
>
> Example workflow:
> cd /path/to/ffmpeg-clone
> ./configure --toolchain=msvc
> make
> make install
>
> 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 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/1] Enable building with WSL and MSVC
On Sun, Oct 2, 2022 at 5:14 PM Timo Rothenpieler wrote:
>
> On 03.10.2022 01:47, Julio C. Rocha wrote:
> > ---
> > configure | 7 ++-
> > 1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/configure b/configure
> > index 6712d045d9..f5f5eb29dd 100755
> > --- a/configure
> > +++ b/configure
> > @@ -4847,7 +4847,12 @@ probe_cc(){
> > else
> > _ident=$($_cc --version 2>/dev/null | head -n1 | tr -d '\r')
> > fi
> > -_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk
> > '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, /
> > /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> > +if [ "$(grep -i Microsoft /proc/version)" ]; then
>
> Not convinced that this is a good check.
> I can think of a few other situations where Microsoft might appear in
> there. Like, for example on one of their servers, Azure Cloud, Github
> Actions and so on.
>
> > +# Windows Subsystem for Linux
> > +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> > awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) { cmd="/usr/bin/wslpath \x27" $$0 "\x27"; cmd |& getline
> > pth; print "$@:", pth } }'\'' > $(@:.o=.d)'
> > +else
> > +_DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 |
> > awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if
> > (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
> > +fi
> > _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
> > _cflags_speed="-O2"
> > _cflags_size="-O1"
>
>
> What actual issue is this solving?
> I've been building in WSL for years, including MSVC builds, and never
> encountered any problems.
FWIW. I am currently building on WSL:
$ uname -a
Linux pal-x 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2
00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:Ubuntu 20.04.4 LTS
Release:20.04
Codename: focal
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/2] avformat/imfdec: use CPL start timecode if available
On Tue, Sep 27, 2022 at 5:40 AM Zane van Iperen wrote:
>
> Looks mostly ok from a cursory glance, just one minor nit.
>
> On 23/8/22 15:10, p...@sandflow.com wrote:
> >
> > +static int ff_imf_xml_read_boolean(xmlNodePtr element, int *value)
> > +{
> > +xmlChar *element_text = NULL;
> > +int ret = 0;
> > +
> > +element_text = xmlNodeListGetString(element->doc,
> > element->xmlChildrenNode, 1);
> > +
>
> No need for "element_text = NULL".
Addressed at v2.
>
> >
> > +static int digit_to_int(char digit)
> > +{
> > +if (digit >= '0' && digit <= '9')
> > +return digit - '0';
> > +return -1;
> > +}
> > +
>
> I feel like there should be a av_* helper for this, but apparently there
> isn't.
> Maybe it's worth adding one in a future patch? av_isdigit() is in avstring.h,
> so
> perhaps there?
Ok. This probably requires more planning since the idioms `x >= '0' &&
x <= '9'` and `x >= 'a' && x <= 'z'` are used in many places.
> ___
> 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] Encrypted SMPTE DC MXF - additional UL needed to unpack EKLV packet
On Fri, Sep 30, 2022 at 7:08 AM Richard Ayres
wrote:
>
> We had an issue where ffmpeg was unable to unpack the EKLV of an encrypted 3D
> SMPTE DC MXF.
>
> The patch adds the SMPTE UL for EKLV packets
> (060e2b34.02040101.0d010301.027e0100), to mxfdec.c in order to unpack an EKLV
> packet found within an Encrypted SMPTE Digital Cinema MXF.
>
> Signed-off-by: Richard Ayres
> ---
> libavformat/mxfdec.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index badd2be224..ebd64b1c68 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -343,6 +343,7 @@ static const uint8_t mxf_apple_coll_prefix[]
> = { 0x06,0x0e,0x2b,0x
> /* complete keys to match */
> static const uint8_t mxf_crypto_source_container_ul[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x09,0x06,0x01,0x01,0x02,0x02,0x00,0x00,0x00
> };
> static const uint8_t mxf_encrypted_triplet_key[] = {
> 0x06,0x0e,0x2b,0x34,0x02,0x04,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x7e,0x01,0x00
> };
> +static const uint8_t mxf_encrypted_triplet_smpte_key[] = {
> 0x06,0x0e,0x2b,0x34,0x02,0x04,0x01,0x01,0x0d,0x01,0x03,0x01,0x02,0x7e,0x01,0x00
> };
> static const uint8_t mxf_encrypted_essence_container[] = {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
> };
> static const uint8_t mxf_sony_mpeg4_extradata[]= {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
> };
> static const uint8_t mxf_ffv1_extradata[] = {
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x04,0x01,0x06,0x0c,0x01,0x00,0x00,0x00
> }; // FFV1InitializationMetadata
> @@ -3738,6 +3739,7 @@ static int mxf_read_header(AVFormatContext *s)
> PRINT_KEY(s, "read header", klv.key);
> av_log(s, AV_LOG_TRACE, "size %"PRIu64" offset %#"PRIx64"\n",
> klv.length, klv.offset);
> if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key) ||
> +IS_KLV_KEY(klv.key, mxf_encrypted_triplet_smpte_key) ||
Calling one UL "mxf_encrypted_triplet_key" and the other
"mxf_encrypted_triplet_smpte_key" is misleading IMHO.
The only difference is the version byte, which should be ignored in
most, if not all, SMPTE UL comparisons.
I would instead use mxf_match_uid(), which ignores the version byte,
to compare the UL keys.
> IS_KLV_KEY(klv.key, mxf_essence_element_key) ||
> IS_KLV_KEY(klv.key, mxf_canopus_essence_element_key) ||
> IS_KLV_KEY(klv.key, mxf_avid_essence_element_key) ||
> @@ -3983,7 +3985,8 @@ static int mxf_read_packet(AVFormatContext *s, AVPacket
> *pkt)
> pos = klv.next_klv - klv.length;
> PRINT_KEY(s, "read packet", klv.key);
> av_log(s, AV_LOG_TRACE, "size %"PRIu64" offset %#"PRIx64"\n",
> klv.length, klv.offset);
> -if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key)) {
> +if (IS_KLV_KEY(klv.key, mxf_encrypted_triplet_key) ||
> +IS_KLV_KEY(klv.key, mxf_encrypted_triplet_smpte_key)) {
> ret = mxf_decrypt_triplet(s, pkt, );
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR, "invalid encoded triplet\n");
> --
> 2.25.1
>
> This e-mail and any attachments are intended only for use by the addressee(s)
> named herein and may contain confidential information. If you are not the
> intended recipient of this e-mail, you are hereby notified any dissemination,
> distribution or copying of this email and any attachments is strictly
> prohibited. If you receive this email in error, please immediately notify the
> sender by return email and permanently delete the original, any copy and any
> printout thereof. The integrity and security of e-mail cannot be guaranteed.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
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] Ping Re: [PATCH v1 1/2] avformat/imfdec: use CPL start timecode if available
Hi all,
I would very much appreciate a review of the following, which was
posted on August 22.
It addresses https://trac.ffmpeg.org/ticket/9842 and works in concert with [2].
Best,
-- Pierre
[1] https://trac.ffmpeg.org/ticket/9842
[2]
https://github.com/FFmpeg/FFmpeg/commit/48fa27e77a6d71be89f216cee13ae7e99d2b5003
Now that [1] has been merged,
On Mon, Sep 5, 2022 at 11:06 AM Pierre-Anthony Lemieux
wrote:
>
> Just a quick ping.
>
> Looking forward to feedback.
>
> This patchset is intended to address https://trac.ffmpeg.org/ticket/9842.
>
>
> On Mon, Aug 22, 2022 at 10:11 PM wrote:
> >
> > From: Pierre-Anthony Lemieux
> >
> > The IMF CPL contains an optional timecode start address. This patch reads
> > the
> > latter, if present, into the context's timecode metadata parameter.
> > This addresses https://trac.ffmpeg.org/ticket/9842.
> >
> > ---
> > libavformat/imf.h | 2 +
> > libavformat/imf_cpl.c | 109 ++
> > libavformat/imfdec.c | 11 +
> > 3 files changed, 122 insertions(+)
> >
> > diff --git a/libavformat/imf.h b/libavformat/imf.h
> > index 4271cd9582..70ed007312 100644
> > --- a/libavformat/imf.h
> > +++ b/libavformat/imf.h
> > @@ -59,6 +59,7 @@
> > #include "libavformat/avio.h"
> > #include "libavutil/rational.h"
> > #include "libavutil/uuid.h"
> > +#include "libavutil/timecode.h"
> > #include
> >
> > /**
> > @@ -130,6 +131,7 @@ typedef struct FFIMFCPL {
> > AVUUID id_uuid; /**<
> > CompositionPlaylist/Id element */
> > xmlChar *content_title_utf8; /**<
> > CompositionPlaylist/ContentTitle element */
> > AVRational edit_rate;/**<
> > CompositionPlaylist/EditRate element */
> > +AVTimecode *tc; /**<
> > CompositionPlaylist/CompositionTimecode element */
> > FFIMFMarkerVirtualTrack *main_markers_track; /**< Main Marker
> > Virtual Track */
> > FFIMFTrackFileVirtualTrack *main_image_2d_track; /**< Main Image
> > Virtual Track */
> > uint32_t main_audio_track_count; /**< Number of Main
> > Audio Virtual Tracks */
> > diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> > index 4acc20feee..1868d7db45 100644
> > --- a/libavformat/imf_cpl.c
> > +++ b/libavformat/imf_cpl.c
> > @@ -116,6 +116,25 @@ int ff_imf_xml_read_uint32(xmlNodePtr element,
> > uint32_t *number)
> > return ret;
> > }
> >
> > +static int ff_imf_xml_read_boolean(xmlNodePtr element, int *value)
> > +{
> > +xmlChar *element_text = NULL;
> > +int ret = 0;
> > +
> > +element_text = xmlNodeListGetString(element->doc,
> > element->xmlChildrenNode, 1);
> > +
> > +if (xmlStrcmp(element_text, "true") == 0 || xmlStrcmp(element_text,
> > "1") == 0)
> > +*value = 1;
> > +else if (xmlStrcmp(element_text, "false") == 0 ||
> > xmlStrcmp(element_text, "0") == 0)
> > +*value = 0;
> > +else
> > +ret = 1;
> > +
> > +xmlFree(element_text);
> > +
> > +return ret;
> > +}
> > +
> > static void imf_base_virtual_track_init(FFIMFBaseVirtualTrack *track)
> > {
> > memset(track->id_uuid, 0, sizeof(track->id_uuid));
> > @@ -179,6 +198,90 @@ static int fill_content_title(xmlNodePtr cpl_element,
> > FFIMFCPL *cpl)
> > return 0;
> > }
> >
> > +static int digit_to_int(char digit)
> > +{
> > +if (digit >= '0' && digit <= '9')
> > +return digit - '0';
> > +return -1;
> > +}
> > +
> > +/**
> > + * Parses a string that conform to the TimecodeType used in IMF CPL and
> > defined
> > + * in SMPTE ST 2067-3.
> > + * @param[in] s string to parse
> > + * @param[out] tc_comps pointer to an array of 4 integers where the parsed
> > HH,
> > + * MM, SS and FF fields of the timecode are returned.
> > + * @return 0 on success, < 0 AVERROR code on error.
> > + */
> > +static int parse_cpl_tc_type(const char *s, int *tc_comps)
> > +{
> > +if (av_strnlen(s, 11) != 11)
> > +return AVERROR(EINVAL);
> > +
> > +for (int i = 0; i < 4; i++) {
> > +int hi;
> > +int lo;
> > +
> > +hi = digit_to_int(s[i *
Re: [FFmpeg-devel] [PATCH] format/imfdec: improve error handling when selecting tracks for playback
On Mon, Sep 19, 2022 at 7:42 AM Michael Niedermayer
wrote:
>
> On Sat, Sep 17, 2022 at 08:57:37AM -0700, Pierre-Anthony Lemieux wrote:
> > On Sat, Sep 17, 2022 at 7:43 AM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Sep 16, 2022 at 01:19:09PM -0700, Pierre-Anthony Lemieux wrote:
> > > > On Fri, Sep 16, 2022 at 1:15 PM Michael Niedermayer
> > > > wrote:
> > > > >
> > > > > On Fri, Sep 16, 2022 at 10:39:22AM -0700, Pierre-Anthony Lemieux
> > > > > wrote:
> > > > > > On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> > > > > > wrote:
> > > > > > >
> > > > > > > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > > > > > > From: Pierre-Anthony Lemieux
> > > > > > > >
> > > > > > > > Addresses coverity 1512414
> > > > > > > >
> > > > > > > > ---
> > > > > > > > libavformat/imfdec.c | 15 ---
> > > > > > > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > > > >
> > > > > > > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > > > > > > > index 5bbe7a53f8..58b1455c9f 100644
> > > > > > > > --- a/libavformat/imfdec.c
> > > > > > > > +++ b/libavformat/imfdec.c
> > > > > > > > @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> > > > > > > > *get_next_track_with_minimum_timestamp(AVForma
> > > > > > > > {
> > > > > > > > IMFContext *c = s->priv_data;
> > > > > > > > IMFVirtualTrackPlaybackCtx *track;
> > > > > > >
> > > > > > > > +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> > > > > > > > -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
> > > > > > >
> > > > > > > iam not sure thats a good idea, it would change behavior on
> > > > > > > different platforms
> > > > > >
> > > > > > I was following the earlier observations that "The initialization of
> > > > > > minimum_timestamp presumes that int are 32bit which need not be
> > > > > > true":
> > > > > >
> > > > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300587.html
> > > > > >
> > > > > > If I am not mistaken, the numerator and denominator of AVRational
> > > > > > are
> > > > > > defined as `int`:
> > > > > >
> > > > > > https://www.ffmpeg.org/doxygen/trunk/structAVRational.html
> > > > > >
> > > > > > What would be the alternative?
> > > > >
> > > > > I dont understand why this code uses AVRational for timestamps
> > > > > normally timestamps are int64_t with a AVRational timebase and would
> > > > > use
> > > > > av_compare_ts() for comparing
> > > >
> > > > Temporal offsets on IMF tracks are typically expressed as rationals,
> > > > and each track can have its own timebase.
> > >
> > > av_compare_ts() can compare 2 timestamps in 2 different timebases
> > >
> > > the problem with using AVRational for timestamps in 1sec units is
> > > that alot of 64bit * 32/32bit timestamps cannot be represented exactly
> >
> > Ok. It might be possible to refactor the imfdec timing model in terms
> > of (int) time offset + timebase instead of (rational) time offset, or
> > at least detect when the current scheme fails. This will require
> > careful study.
> >
>
> > Any objections to tackling this refactoring as a separate patchset,
> > since this patchet is intended to address the coverity issue?
>
> you can do it in whichever way works best for you.
> Iam just saying that AVRational with more than 32/32bit is problematic
Ok. Will revert to initializing minimum_timestamp with INT32_MAX for
now so that we can merge this fix.
>
> consider av_add_q() it expects the product of various fields to fit
> int64_t
>
> if int is 64bit AND AVRational uses teh extra range the implementation
> needs a 128bit type or some other modification
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Into a blind darkness they enter who follow after the Ignorance,
> they as if into a greater darkness enter who devote themselves
> to the Knowledge alone. -- Isha Upanishad
> ___
> 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] format/imfdec: improve error handling when selecting tracks for playback
On Sat, Sep 17, 2022 at 7:43 AM Michael Niedermayer
wrote:
>
> On Fri, Sep 16, 2022 at 01:19:09PM -0700, Pierre-Anthony Lemieux wrote:
> > On Fri, Sep 16, 2022 at 1:15 PM Michael Niedermayer
> > wrote:
> > >
> > > On Fri, Sep 16, 2022 at 10:39:22AM -0700, Pierre-Anthony Lemieux wrote:
> > > > On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> > > > wrote:
> > > > >
> > > > > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > > > > From: Pierre-Anthony Lemieux
> > > > > >
> > > > > > Addresses coverity 1512414
> > > > > >
> > > > > > ---
> > > > > > libavformat/imfdec.c | 15 ---
> > > > > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > > > > > index 5bbe7a53f8..58b1455c9f 100644
> > > > > > --- a/libavformat/imfdec.c
> > > > > > +++ b/libavformat/imfdec.c
> > > > > > @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> > > > > > *get_next_track_with_minimum_timestamp(AVForma
> > > > > > {
> > > > > > IMFContext *c = s->priv_data;
> > > > > > IMFVirtualTrackPlaybackCtx *track;
> > > > >
> > > > > > +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> > > > > > -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
> > > > >
> > > > > iam not sure thats a good idea, it would change behavior on different
> > > > > platforms
> > > >
> > > > I was following the earlier observations that "The initialization of
> > > > minimum_timestamp presumes that int are 32bit which need not be true":
> > > >
> > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300587.html
> > > >
> > > > If I am not mistaken, the numerator and denominator of AVRational are
> > > > defined as `int`:
> > > >
> > > > https://www.ffmpeg.org/doxygen/trunk/structAVRational.html
> > > >
> > > > What would be the alternative?
> > >
> > > I dont understand why this code uses AVRational for timestamps
> > > normally timestamps are int64_t with a AVRational timebase and would use
> > > av_compare_ts() for comparing
> >
> > Temporal offsets on IMF tracks are typically expressed as rationals,
> > and each track can have its own timebase.
>
> av_compare_ts() can compare 2 timestamps in 2 different timebases
>
> the problem with using AVRational for timestamps in 1sec units is
> that alot of 64bit * 32/32bit timestamps cannot be represented exactly
Ok. It might be possible to refactor the imfdec timing model in terms
of (int) time offset + timebase instead of (rational) time offset, or
at least detect when the current scheme fails. This will require
careful study.
Any objections to tackling this refactoring as a separate patchset,
since this patchet is intended to address the coverity issue?
>
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In fact, the RIAA has been known to suggest that students drop out
> of college or go to community college in order to be able to afford
> settlements. -- The RIAA
> ___
> 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] format/imfdec: improve error handling when selecting tracks for playback
On Fri, Sep 16, 2022 at 1:15 PM Michael Niedermayer
wrote:
>
> On Fri, Sep 16, 2022 at 10:39:22AM -0700, Pierre-Anthony Lemieux wrote:
> > On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> > wrote:
> > >
> > > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > > From: Pierre-Anthony Lemieux
> > > >
> > > > Addresses coverity 1512414
> > > >
> > > > ---
> > > > libavformat/imfdec.c | 15 ---
> > > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > > > index 5bbe7a53f8..58b1455c9f 100644
> > > > --- a/libavformat/imfdec.c
> > > > +++ b/libavformat/imfdec.c
> > > > @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> > > > *get_next_track_with_minimum_timestamp(AVForma
> > > > {
> > > > IMFContext *c = s->priv_data;
> > > > IMFVirtualTrackPlaybackCtx *track;
> > >
> > > > +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> > > > -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
> > >
> > > iam not sure thats a good idea, it would change behavior on different
> > > platforms
> >
> > I was following the earlier observations that "The initialization of
> > minimum_timestamp presumes that int are 32bit which need not be true":
> >
> > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300587.html
> >
> > If I am not mistaken, the numerator and denominator of AVRational are
> > defined as `int`:
> >
> > https://www.ffmpeg.org/doxygen/trunk/structAVRational.html
> >
> > What would be the alternative?
>
> I dont understand why this code uses AVRational for timestamps
> normally timestamps are int64_t with a AVRational timebase and would use
> av_compare_ts() for comparing
Temporal offsets on IMF tracks are typically expressed as rationals,
and each track can have its own timebase.
>
> thx
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When you are offended at any man's fault, turn to yourself and study your
> own failings. Then you will forget your anger. -- Epictetus
> ___
> 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] format/imfdec: improve error handling when selecting tracks for playback
On Fri, Sep 16, 2022 at 10:39 AM Pierre-Anthony Lemieux
wrote:
>
> On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
> wrote:
> >
> > On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Addresses coverity 1512414
> > >
> > > ---
> > > libavformat/imfdec.c | 15 ---
> > > 1 file changed, 12 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > > index 5bbe7a53f8..58b1455c9f 100644
> > > --- a/libavformat/imfdec.c
> > > +++ b/libavformat/imfdec.c
> > > @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> > > *get_next_track_with_minimum_timestamp(AVForma
> > > {
> > > IMFContext *c = s->priv_data;
> > > IMFVirtualTrackPlaybackCtx *track;
> >
> > > +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> > > -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
> >
> > iam not sure thats a good idea, it would change behavior on different
> > platforms
>
> I was following the earlier observations that "The initialization of
> minimum_timestamp presumes that int are 32bit which need not be true":
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300587.html
>
> If I am not mistaken, the numerator and denominator of AVRational are
> defined as `int`:
>
> https://www.ffmpeg.org/doxygen/trunk/structAVRational.html
>
> What would be the alternative?
... and see similar code at:
https://github.com/FFmpeg/FFmpeg/blob/f05247f6a4698c14f1cd523daa90188f50dcf6ad/libavcodec/mpeg12framerate.c#L51
>
> >
> > thx
> >
> > [...]
> > --
> > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >
> > it is not once nor twice but times without number that the same ideas make
> > their appearance in the world. -- Aristotle
> > ___
> > 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] format/imfdec: improve error handling when selecting tracks for playback
On Fri, Sep 16, 2022 at 10:27 AM Michael Niedermayer
wrote:
>
> On Wed, Sep 07, 2022 at 01:02:33PM -0700, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses coverity 1512414
> >
> > ---
> > libavformat/imfdec.c | 15 ---
> > 1 file changed, 12 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > index 5bbe7a53f8..58b1455c9f 100644
> > --- a/libavformat/imfdec.c
> > +++ b/libavformat/imfdec.c
> > @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> > *get_next_track_with_minimum_timestamp(AVForma
> > {
> > IMFContext *c = s->priv_data;
> > IMFVirtualTrackPlaybackCtx *track;
>
> > +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> > -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
>
> iam not sure thats a good idea, it would change behavior on different
> platforms
I was following the earlier observations that "The initialization of
minimum_timestamp presumes that int are 32bit which need not be true":
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/300587.html
If I am not mistaken, the numerator and denominator of AVRational are
defined as `int`:
https://www.ffmpeg.org/doxygen/trunk/structAVRational.html
What would be the alternative?
>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
> ___
> 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] MAINTAINERS: add maintainer for the imf demuxer
On Thu, Sep 15, 2022 at 4:07 PM Lynne wrote: > > Sep 16, 2022, 00:46 by p...@sandflow.com: > > > From: Pierre-Anthony Lemieux > > > > --- > > MAINTAINERS | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index ed2ec0b90c..2d37f0b86a 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -436,6 +436,7 @@ Muxers/Demuxers: > > idcin.c Mike Melanson > > idroqdec.cMike Melanson > > iff.c Jaikrishnan Menon > > + imf* Pierre-Anthony Lemieux > > img2*.c Michael Niedermayer > > ipmovie.c Mike Melanson > > ircam*Paul B Mahol > > @@ -633,6 +634,7 @@ Nikolay Aleksandrov 8978 1D8C FB71 588E 4B27 > > EAA8 C4F0 B5FC E011 13B1 > > Panagiotis Issaris6571 13A3 33D9 3726 F728 AA98 F643 B12E ECF3 > > E029 > > Peter RossA907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 > > DD6B > > Philip Langdale 5DC5 8D66 5FBA 3A43 18EC 045E F8D6 B194 6A75 > > 682E > > +Pierre-Anthony Lemieux (pal) F4B3 9492 E6F2 E4AF AEC8 46CB 698F A1F0 F8D4 > > EED4 > > Ramiro Polla 7859 C65B 751B 1179 792E DAE8 8E95 8B2F 9B6C > > 5700 > > Reimar Doeffinger C61D 16E5 9E2C D10C 8958 38A4 0899 A2B9 06D4 > > D9C7 > > Reinhard Tartler 9300 5DC2 7E87 6C37 ED7B CA9A 9808 3544 9453 > > 48A4 > > > > That list is for those with push access. Are you sure you want that? You make it sound unpleasant :) In all seriousness, my objective is being responsive to issues filed against the IMF demuxer. I am happy to set aside the time to be a maintainer if it helps achieve that objective. I am also happy to not be a maintainer if it will not help. > We don't have strict requirements for that, but you're just past > the #commits to get a vote on TC questions. > Reviewing patches takes a while, but that's just how it is when > they're of little interest to most. Yes. Isn't this particularly true when there is no maintainer for that module -- as is currently the case for the IMF demuxer? On a related note, I would think that review of narrow bug fixes like [1] would require relatively less time than, say, the addition of an imf muxer. [1] https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=7416 In any case thanks for your help/input since the beginning of my involvement with the codebase. > ___ > 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] format/imfdec: improve error handling when selecting tracks for playback
Ping.
This patchset addresses a coverity issue #1512414.
On Wed, Sep 7, 2022 at 1:02 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> Addresses coverity 1512414
>
> ---
> libavformat/imfdec.c | 15 ---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> index 5bbe7a53f8..58b1455c9f 100644
> --- a/libavformat/imfdec.c
> +++ b/libavformat/imfdec.c
> @@ -681,8 +681,11 @@ static IMFVirtualTrackPlaybackCtx
> *get_next_track_with_minimum_timestamp(AVForma
> {
> IMFContext *c = s->priv_data;
> IMFVirtualTrackPlaybackCtx *track;
> +AVRational minimum_timestamp = av_make_q(INT_MAX, 1);
> +
> +if (!c->track_count)
> +return NULL;
>
> -AVRational minimum_timestamp = av_make_q(INT32_MAX, 1);
> for (uint32_t i = c->track_count; i > 0; i--) {
> av_log(s, AV_LOG_TRACE, "Compare track %d timestamp "
> AVRATIONAL_FORMAT
> " to minimum " AVRATIONAL_FORMAT
> @@ -697,8 +700,6 @@ static IMFVirtualTrackPlaybackCtx
> *get_next_track_with_minimum_timestamp(AVForma
> }
> }
>
> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: %lf /
> %lf)\n",
> - track->index, av_q2d(track->current_timestamp),
> av_q2d(minimum_timestamp));
> return track;
> }
>
> @@ -761,6 +762,14 @@ static int imf_read_packet(AVFormatContext *s, AVPacket
> *pkt)
>
> track = get_next_track_with_minimum_timestamp(s);
>
> +if (!track) {
> +av_log(s, AV_LOG_ERROR, "No track found for playback\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +av_log(s, AV_LOG_DEBUG, "Found track %d to read at timestamp %lf\n",
> + track->index, av_q2d(track->current_timestamp));
> +
> ret = get_resource_context_for_timestamp(s, track, );
> if (ret)
> return ret;
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] avformat/mxf: set stream frame rates for ST 422 essence containers
Ping. All outstanding feedback has been addressed AFAIK.
This patchset addresses https://trac.ffmpeg.org/ticket/9856
On Tue, Sep 6, 2022 at 2:51 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> The MXF demuxer does not currently set AVStream::avg_frame_rate and
> ::r_frame_rate
> when J2K essence is wrapped according to SMPTE ST 422.
>
> ---
> libavformat/mxfdec.c | 25 +
> 1 file changed, 25 insertions(+)
>
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index feebff67aa..043e2e06ec 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -2140,6 +2140,13 @@ finish_decoding_index:
> return ret;
> }
>
> +static int mxf_is_st_422(const UID *essence_container_ul) {
> +static const uint8_t st_422_essence_container_ul[] = {
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c };
> +
> +return essence_container_ul && mxf_match_uid(*essence_container_ul,
> st_422_essence_container_ul,
> +
> sizeof(st_422_essence_container_ul));
> +}
> +
> static int mxf_is_intra_only(MXFDescriptor *descriptor)
> {
> return mxf_get_codec_ul(mxf_intra_only_essence_container_uls,
> @@ -2892,6 +2899,24 @@ static int mxf_parse_structural_metadata(MXFContext
> *mxf)
> av_log(mxf->fc, AV_LOG_INFO, "Unknown frame layout type:
> %d\n", descriptor->frame_layout);
> }
>
> +if (mxf_is_st_422(essence_container_ul)) {
> +switch ((*essence_container_ul)[14]) {
> +case 2: /* Cn: Clip- wrapped Picture Element */
> +case 3: /* I1: Interlaced Frame, 1 field/KLV */
> +case 4: /* I2: Interlaced Frame, 2 fields/KLV */
> +case 6: /* P1: Frame- wrapped Picture Element */
> +st->avg_frame_rate = source_track->edit_rate;
> +st->r_frame_rate = st->avg_frame_rate;
> +break;
> +case 5: /* F1: Field-wrapped Picture Element */
> +st->avg_frame_rate = av_mul_q(av_make_q(2, 1),
> source_track->edit_rate);
> +st->r_frame_rate = st->avg_frame_rate;
> +break;
> +default:
> +break;
> +}
> +}
> +
> if (st->codecpar->codec_id == AV_CODEC_ID_PRORES) {
> switch (descriptor->essence_codec_ul[14]) {
> case 1: st->codecpar->codec_tag = MKTAG('a','p','c','o');
> break;
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it
See [1] for a patchset that is intended to address the coverity issue and simplify error handling. [1] https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220907200233.21255-1-...@sandflow.com/ On Sat, Aug 27, 2022 at 10:25 AM Pierre-Anthony Lemieux wrote: > > On Sat, Aug 27, 2022 at 5:25 AM Steven Liu wrote: > > > > Pierre-Anthony Lemieux 于2022年8月27日周六 00:06写道： > > > > > > On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt > > > wrote: > > > > > > > > Pierre-Anthony Lemieux: > > > > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > > > > wrote: > > > > >> > > > > >> Steven Liu: > > > > >>> fix CID: 1512414 > > > > >>> And return AVERROR_INVALIDDATA when > > > > >>> get_next_track_with_minimum_timestamp > > > > >>> incorrect in imf_read_packet; > > > > >>> > > > > >>> Signed-off-by: Steven Liu > > > > >>> --- > > > > >>> libavformat/imfdec.c | 7 +-- > > > > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > > > > >>> > > > > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > > > > >>> index 5bbe7a53f8..08f342bc1a 100644 > > > > >>> --- a/libavformat/imfdec.c > > > > >>> +++ b/libavformat/imfdec.c > > > > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > > > > >>> *get_next_track_with_minimum_timestamp(AVForma > > > > >>> } > > > > >>> } > > > > >>> > > > > >>> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > > >>> (timestamp: %lf / %lf)\n", > > > > >>> - track->index, av_q2d(track->current_timestamp), > > > > >>> av_q2d(minimum_timestamp)); > > > > >>> +if (track) > > > > >>> +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > > >>> (timestamp: %lf / %lf)\n", > > > > >>> + track->index, av_q2d(track->current_timestamp), > > > > >>> av_q2d(minimum_timestamp)); > > > > >> > > > > >> Coverity actually complained about track being uninitialized, which > > > > >> this > > > > >> patch does not address. And the reason it does this is that it > > > > >> doesn't > > > > >> understand the algorithm: track will always be initialized in the > > > > >> first > > > > >> iteration of the loop. > > > > > > > > > > Is it possible to tell coverity that c->track_count > 0 is a > > > > > pre-condition, or should we modify the loop/algorithm? > > > > > > > > > > > > > The typical way to do this is to add an av_assert1 or av_assert2; > > > > but this must only be done if it is indeed ensured that the assert will > > > > not be triggered. > > > > > > > > >> (If there is a first iteration of the loop -- is > > > > >> this actually guaranteed? A file without tracks seems to be pretty > > > > >> useless.) > > > > > > > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > > > > there are no streams/tracks and (b) a track will always be found. > > > > > > > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > > > > it can always be true for a malformed one. > > > > > > > > > > > > > Can't we make it true by adding the relevant checks to read_header? > > > > > > Yes. > > Can imf add or remove track when processing? Looks like the live > > streaming change resolution or bitrate when playing. > > The number of tracks is fixed and determined when the Composition > Playlist (CPL) is parsed. > > > > > > > > > > > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > > > > a patch separately from addressing the coverity issue? > > > > > > > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > > > > >> assumed that track is not initialized in the loop (which boils down > >
Re: [FFmpeg-devel] [PATCH v2 2/2] fate/mxf: add JPEG 2000 test
On Tue, Sep 6, 2022 at 2:33 PM Andreas Rheinhardt wrote: > > Pierre-Anthony Lemieux: > > On Tue, Sep 6, 2022 at 2:24 PM Andreas Rheinhardt > > wrote: > >> > >> p...@sandflow.com: > >>> From: Pierre-Anthony Lemieux > >>> > >>> --- > >>> tests/fate/mxf.mak | 4 ++ > >>> tests/ref/fate/mxf-probe-j2k | 78 > >>> 2 files changed, 82 insertions(+) > >>> create mode 100644 tests/ref/fate/mxf-probe-j2k > >>> > >>> diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak > >>> index 3ab936b5de..38d1c2ef38 100644 > >>> --- a/tests/fate/mxf.mak > >>> +++ b/tests/fate/mxf.mak > >>> @@ -29,6 +29,10 @@ FATE_MXF_PROBE-$(call ENCDEC, DNXHD, MXF) += > >>> fate-mxf-probe-dnxhd > >>> fate-mxf-probe-dnxhd: SRC = $(TARGET_SAMPLES)/mxf/multiple_components.mxf > >>> fate-mxf-probe-dnxhd: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i > >>> "$(SRC)" > >>> > >>> +FATE_MXF_PROBE-$(call ENCDEC, JPEG2000, MXF) += fate-mxf-probe-j2k > >> > >> ENCDEC? Since when does ffprobe run encoders at all? > > > > I did wonder, but ended-up using the same template as fate-mxf-probe-dnxhd. > > > > Should they all be changed to DEC? > > > > I have not looked at these tests in particular, but DEMDEC is the > expected command here. Notice that there might be scenarios where you > need more (like an additional parser or the extract extradata bsf (I > expect the mxf-probe-d10 test to need the latter and maybe the former in > addition to the mpeg2video decoder.)). Fixed at v3 > > >> > >>> +fate-mxf-probe-j2k: SRC = > >>> $(TARGET_SAMPLES)/imf/countdown/countdown-small.mxf > >>> +fate-mxf-probe-j2k: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > >>> + > >>> FATE_MXF_PROBE-$(call ENCDEC2, DVVIDEO, PCM_S16LE, MXF) += > >>> fate-mxf-probe-dv25 > >>> fate-mxf-probe-dv25: SRC = $(TARGET_SAMPLES)/mxf/Avid-5.mxf > >>> fate-mxf-probe-dv25: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i > >>> "$(SRC)" > >>> diff --git a/tests/ref/fate/mxf-probe-j2k b/tests/ref/fate/mxf-probe-j2k > >>> new file mode 100644 > >>> index 00..2dbf2ac37d > >>> --- /dev/null > >>> +++ b/tests/ref/fate/mxf-probe-j2k > >>> @@ -0,0 +1,78 @@ > >>> +[STREAM] > >>> +index=0 > >>> +codec_name=jpeg2000 > >>> +profile=1798 > >>> +codec_type=video > >>> +codec_tag_string=[0][0][0][0] > >>> +codec_tag=0x > >>> +width=640 > >>> +height=360 > >>> +coded_width=640 > >>> +coded_height=360 > >>> +closed_captions=0 > >>> +film_grain=0 > >>> +has_b_frames=0 > >>> +sample_aspect_ratio=1:1 > >>> +display_aspect_ratio=16:9 > >>> +pix_fmt=rgb48le > >>> +level=-99 > >>> +color_range=unknown > >>> +color_space=unknown > >>> +color_transfer=bt709 > >>> +color_primaries=bt709 > >>> +chroma_location=unspecified > >>> +field_order=progressive > >>> +refs=1 > >>> +id=N/A > >>> +r_frame_rate=24/1 > >>> +avg_frame_rate=24/1 > >>> +time_base=1/24 > >>> +start_pts=0 > >>> +start_time=0.00 > >>> +duration_ts=24 > >>> +duration=1.00 > >>> +bit_rate=N/A > >>> +max_bit_rate=N/A > >>> +bits_per_raw_sample=16 > >>> +nb_frames=N/A > >>> +nb_read_frames=N/A > >>> +nb_read_packets=N/A > >>> +DISPOSITION:default=0 > >>> +DISPOSITION:dub=0 > >>> +DISPOSITION:original=0 > >>> +DISPOSITION:comment=0 > >>> +DISPOSITION:lyrics=0 > >>> +DISPOSITION:karaoke=0 > >>> +DISPOSITION:forced=0 > >>> +DISPOSITION:hearing_impaired=0 > >>> +DISPOSITION:visual_impaired=0 > >>> +DISPOSITION:clean_effects=0 > >>> +DISPOSITION:attached_pic=0 > >>> +DISPOSITION:timed_thumbnails=0 > >>> +DISPOSITION:captions=0 > >>> +DISPOSITION:descriptions=0 > >>> +DISPOSITION:metadata=0 > >>> +DISPOSITION:dependent=0 > >>> +DISPOSITION:still_image=0 > >>> +TAG:file_package_umid=0x060A2B340101010501010F20130035E05073878E4B2FB69D2369F25AD
Re: [FFmpeg-devel] [PATCH v2 2/2] fate/mxf: add JPEG 2000 test
On Tue, Sep 6, 2022 at 2:24 PM Andreas Rheinhardt wrote: > > p...@sandflow.com: > > From: Pierre-Anthony Lemieux > > > > --- > > tests/fate/mxf.mak | 4 ++ > > tests/ref/fate/mxf-probe-j2k | 78 > > 2 files changed, 82 insertions(+) > > create mode 100644 tests/ref/fate/mxf-probe-j2k > > > > diff --git a/tests/fate/mxf.mak b/tests/fate/mxf.mak > > index 3ab936b5de..38d1c2ef38 100644 > > --- a/tests/fate/mxf.mak > > +++ b/tests/fate/mxf.mak > > @@ -29,6 +29,10 @@ FATE_MXF_PROBE-$(call ENCDEC, DNXHD, MXF) += > > fate-mxf-probe-dnxhd > > fate-mxf-probe-dnxhd: SRC = $(TARGET_SAMPLES)/mxf/multiple_components.mxf > > fate-mxf-probe-dnxhd: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > > > > +FATE_MXF_PROBE-$(call ENCDEC, JPEG2000, MXF) += fate-mxf-probe-j2k > > ENCDEC? Since when does ffprobe run encoders at all? I did wonder, but ended-up using the same template as fate-mxf-probe-dnxhd. Should they all be changed to DEC? > > > +fate-mxf-probe-j2k: SRC = > > $(TARGET_SAMPLES)/imf/countdown/countdown-small.mxf > > +fate-mxf-probe-j2k: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > > + > > FATE_MXF_PROBE-$(call ENCDEC2, DVVIDEO, PCM_S16LE, MXF) += > > fate-mxf-probe-dv25 > > fate-mxf-probe-dv25: SRC = $(TARGET_SAMPLES)/mxf/Avid-5.mxf > > fate-mxf-probe-dv25: CMD = run $(PROBE_FORMAT_STREAMS_COMMAND) -i "$(SRC)" > > diff --git a/tests/ref/fate/mxf-probe-j2k b/tests/ref/fate/mxf-probe-j2k > > new file mode 100644 > > index 00..2dbf2ac37d > > --- /dev/null > > +++ b/tests/ref/fate/mxf-probe-j2k > > @@ -0,0 +1,78 @@ > > +[STREAM] > > +index=0 > > +codec_name=jpeg2000 > > +profile=1798 > > +codec_type=video > > +codec_tag_string=[0][0][0][0] > > +codec_tag=0x > > +width=640 > > +height=360 > > +coded_width=640 > > +coded_height=360 > > +closed_captions=0 > > +film_grain=0 > > +has_b_frames=0 > > +sample_aspect_ratio=1:1 > > +display_aspect_ratio=16:9 > > +pix_fmt=rgb48le > > +level=-99 > > +color_range=unknown > > +color_space=unknown > > +color_transfer=bt709 > > +color_primaries=bt709 > > +chroma_location=unspecified > > +field_order=progressive > > +refs=1 > > +id=N/A > > +r_frame_rate=24/1 > > +avg_frame_rate=24/1 > > +time_base=1/24 > > +start_pts=0 > > +start_time=0.00 > > +duration_ts=24 > > +duration=1.00 > > +bit_rate=N/A > > +max_bit_rate=N/A > > +bits_per_raw_sample=16 > > +nb_frames=N/A > > +nb_read_frames=N/A > > +nb_read_packets=N/A > > +DISPOSITION:default=0 > > +DISPOSITION:dub=0 > > +DISPOSITION:original=0 > > +DISPOSITION:comment=0 > > +DISPOSITION:lyrics=0 > > +DISPOSITION:karaoke=0 > > +DISPOSITION:forced=0 > > +DISPOSITION:hearing_impaired=0 > > +DISPOSITION:visual_impaired=0 > > +DISPOSITION:clean_effects=0 > > +DISPOSITION:attached_pic=0 > > +DISPOSITION:timed_thumbnails=0 > > +DISPOSITION:captions=0 > > +DISPOSITION:descriptions=0 > > +DISPOSITION:metadata=0 > > +DISPOSITION:dependent=0 > > +DISPOSITION:still_image=0 > > +TAG:file_package_umid=0x060A2B340101010501010F20130035E05073878E4B2FB69D2369F25ADFC9 > > +TAG:file_package_name=File Package: SMPTE ST 422 / ST 2067-5 frame > > wrapping of JPEG 2000 codestreams > > +TAG:track_name=Image Track > > +[/STREAM] > > +[FORMAT] > > +format_name=mxf > > +duration=1.00 > > +bit_rate=577792 > > +TAG:operational_pattern_ul=060e2b34.04010101.0d010201.01010100 > > +TAG:uid=f1994e51-a844-49e4-9459-1ddd622eb65d > > +TAG:generation_uid=1be151ac-cc95-4314-b09f-7420eda9932b > > +TAG:company_name=Sandflow Consulting LLC > > +TAG:product_name=dcdm2imf > > +TAG:product_version_num=0.0.0.0.0 > > +TAG:product_version=1.0-beta1 > > +TAG:product_uid=927fc4d1-89a3-4f88-88bb-d363ed33084a > > +TAG:modification_date=2022-01-07T22:05:01.00Z > > +TAG:toolkit_version_num=2.10.38.27240.1 > > +TAG:application_platform=win32 > > +TAG:material_package_umid=0x060A2B340101010501010F20130072BAF0557DA749308C14738BCD4FA116 > > +TAG:material_package_name=Material Package > > +[/FORMAT] > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avformat/imfdec: check if Asset/Id exists before trying to read it
Ping.
This fixes Coverity issue #1512406.
On Thu, Aug 25, 2022 at 8:22 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> Fixes Coverity issue #1512406
>
> ---
> libavformat/imfdec.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> index 5bbe7a53f8..fde91a6419 100644
> --- a/libavformat/imfdec.c
> +++ b/libavformat/imfdec.c
> @@ -233,7 +233,12 @@ static int
> parse_imf_asset_map_from_xml_dom(AVFormatContext *s,
>
> asset = &(asset_map->assets[asset_map->asset_count]);
>
> -if
> (ff_imf_xml_read_uuid(ff_imf_xml_get_child_element_by_name(asset_element,
> "Id"), asset->uuid)) {
> +if (!(node = ff_imf_xml_get_child_element_by_name(asset_element,
> "Id"))) {
> +av_log(s, AV_LOG_ERROR, "Unable to parse asset map XML - missing
> Id node\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (ff_imf_xml_read_uuid(node, asset->uuid)) {
> av_log(s, AV_LOG_ERROR, "Could not parse UUID from asset in
> asset map.\n");
> return AVERROR_INVALIDDATA;
> }
> --
> 2.25.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 1/2] avformat/imfdec: use CPL start timecode if available
Just a quick ping.
Looking forward to feedback.
This patchset is intended to address https://trac.ffmpeg.org/ticket/9842.
On Mon, Aug 22, 2022 at 10:11 PM wrote:
>
> From: Pierre-Anthony Lemieux
>
> The IMF CPL contains an optional timecode start address. This patch reads the
> latter, if present, into the context's timecode metadata parameter.
> This addresses https://trac.ffmpeg.org/ticket/9842.
>
> ---
> libavformat/imf.h | 2 +
> libavformat/imf_cpl.c | 109 ++
> libavformat/imfdec.c | 11 +
> 3 files changed, 122 insertions(+)
>
> diff --git a/libavformat/imf.h b/libavformat/imf.h
> index 4271cd9582..70ed007312 100644
> --- a/libavformat/imf.h
> +++ b/libavformat/imf.h
> @@ -59,6 +59,7 @@
> #include "libavformat/avio.h"
> #include "libavutil/rational.h"
> #include "libavutil/uuid.h"
> +#include "libavutil/timecode.h"
> #include
>
> /**
> @@ -130,6 +131,7 @@ typedef struct FFIMFCPL {
> AVUUID id_uuid; /**<
> CompositionPlaylist/Id element */
> xmlChar *content_title_utf8; /**<
> CompositionPlaylist/ContentTitle element */
> AVRational edit_rate;/**<
> CompositionPlaylist/EditRate element */
> +AVTimecode *tc; /**<
> CompositionPlaylist/CompositionTimecode element */
> FFIMFMarkerVirtualTrack *main_markers_track; /**< Main Marker
> Virtual Track */
> FFIMFTrackFileVirtualTrack *main_image_2d_track; /**< Main Image Virtual
> Track */
> uint32_t main_audio_track_count; /**< Number of Main
> Audio Virtual Tracks */
> diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
> index 4acc20feee..1868d7db45 100644
> --- a/libavformat/imf_cpl.c
> +++ b/libavformat/imf_cpl.c
> @@ -116,6 +116,25 @@ int ff_imf_xml_read_uint32(xmlNodePtr element, uint32_t
> *number)
> return ret;
> }
>
> +static int ff_imf_xml_read_boolean(xmlNodePtr element, int *value)
> +{
> +xmlChar *element_text = NULL;
> +int ret = 0;
> +
> +element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> +
> +if (xmlStrcmp(element_text, "true") == 0 || xmlStrcmp(element_text, "1")
> == 0)
> +*value = 1;
> +else if (xmlStrcmp(element_text, "false") == 0 ||
> xmlStrcmp(element_text, "0") == 0)
> +*value = 0;
> +else
> +ret = 1;
> +
> +xmlFree(element_text);
> +
> +return ret;
> +}
> +
> static void imf_base_virtual_track_init(FFIMFBaseVirtualTrack *track)
> {
> memset(track->id_uuid, 0, sizeof(track->id_uuid));
> @@ -179,6 +198,90 @@ static int fill_content_title(xmlNodePtr cpl_element,
> FFIMFCPL *cpl)
> return 0;
> }
>
> +static int digit_to_int(char digit)
> +{
> +if (digit >= '0' && digit <= '9')
> +return digit - '0';
> +return -1;
> +}
> +
> +/**
> + * Parses a string that conform to the TimecodeType used in IMF CPL and
> defined
> + * in SMPTE ST 2067-3.
> + * @param[in] s string to parse
> + * @param[out] tc_comps pointer to an array of 4 integers where the parsed
> HH,
> + * MM, SS and FF fields of the timecode are returned.
> + * @return 0 on success, < 0 AVERROR code on error.
> + */
> +static int parse_cpl_tc_type(const char *s, int *tc_comps)
> +{
> +if (av_strnlen(s, 11) != 11)
> +return AVERROR(EINVAL);
> +
> +for (int i = 0; i < 4; i++) {
> +int hi;
> +int lo;
> +
> +hi = digit_to_int(s[i * 3]);
> +lo = digit_to_int(s[i * 3 + 1]);
> +
> +if (hi == -1 || lo == -1)
> +return AVERROR(EINVAL);
> +
> +tc_comps[i] = 10 * hi + lo;
> +}
> +
> +return 0;
> +}
> +
> +static int fill_timecode(xmlNodePtr cpl_element, FFIMFCPL *cpl)
> +{
> +xmlNodePtr tc_element = NULL;
> +xmlNodePtr element = NULL;
> +xmlChar *tc_str = NULL;
> +int df = 0;
> +int comps[4];
> +int ret = 0;
> +
> +tc_element = ff_imf_xml_get_child_element_by_name(cpl_element,
> "CompositionTimecode");
> +if (!tc_element)
> + return 0;
> +
> +element = ff_imf_xml_get_child_element_by_name(tc_element,
> "TimecodeDropFrame");
> +if (!element) {
> +av_log(NULL, AV_LOG_ERROR, "CompositionTimecode element is missing\
> +a TimecodeDropFrame child element\n");
&
Re: [FFmpeg-devel] [PATCH v1] avformat/mxf: set stream frame rates for ST 422 essence containers
On Sat, Sep 3, 2022 at 11:26 AM Tomas Härdin wrote:
>
> sön 2022-08-28 klockan 08:31 -0700 skrev p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > The MXF demuxer does not currently set AVStream::avg_frame_rate and
> > ::r_frame_rate
> > when J2K essence is wrapped according to SMPTE ST 422.
> >
> > ---
> > libavformat/mxfdec.c | 25 +
> > 1 file changed, 25 insertions(+)
> >
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index feebff67aa..043e2e06ec 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -2140,6 +2140,13 @@ finish_decoding_index:
> > return ret;
> > }
> >
> > +static int mxf_is_st_422(const UID *essence_container_ul) {
> > +static const uint8_t st_422_essence_container_ul[] = {
> > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0c
> > };
> > +
> > +return essence_container_ul &&
> > mxf_match_uid(*essence_container_ul, st_422_essence_container_ul,
> > +
> > sizeof(st_422_essence_container_ul));
> > +}
>
> Seems unnecessary to have a function for this
Ok. I was trying to avoid a long if() line but I am happy to move the
logic to mxf_parse_structural_metadata().
Would you like me to update the patch?
>
> > +
> > static int mxf_is_intra_only(MXFDescriptor *descriptor)
> > {
> > return mxf_get_codec_ul(mxf_intra_only_essence_container_uls,
> > @@ -2892,6 +2899,24 @@ static int
> > mxf_parse_structural_metadata(MXFContext *mxf)
> > av_log(mxf->fc, AV_LOG_INFO, "Unknown frame
> > layout type: %d\n", descriptor->frame_layout);
> > }
> >
> > +if (mxf_is_st_422(essence_container_ul)) {
> > +switch ((*essence_container_ul)[14]) {
> > +case 2: /* Cn: Clip- wrapped Picture Element */
> > +case 3: /* I1: Interlaced Frame, 1 field/KLV */
> > +case 4: /* I2: Interlaced Frame, 2 fields/KLV */
> > +case 6: /* P1: Frame- wrapped Picture Element */
> > +st->avg_frame_rate = source_track->edit_rate;
> > +st->r_frame_rate = st->avg_frame_rate;
> > +break;
> > +case 5: /* F1: Field-wrapped Picture Element */
> > +st->avg_frame_rate = av_mul_q(av_make_q(2, 1),
> > source_track->edit_rate);
> > +st->r_frame_rate = st->avg_frame_rate;
> > +break;
> > +default:
> > +break;
> > +}
> > +}
>
> Looks OK, but we should have a test for this as well I think
Ok. imf/countdown/countdown-small.mxf contained ST 422-wrapped essence
and ffprobe reports `24 fps`. Should this patchset include the test?
>
> At some point we'll probably need to implement proper timecode
> support..
+1
Happy to collaborate.
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it
On Sat, Aug 27, 2022 at 5:25 AM Steven Liu wrote: > > Pierre-Anthony Lemieux 于2022年8月27日周六 00:06写道： > > > > On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt > > wrote: > > > > > > Pierre-Anthony Lemieux: > > > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > > > wrote: > > > >> > > > >> Steven Liu: > > > >>> fix CID: 1512414 > > > >>> And return AVERROR_INVALIDDATA when > > > >>> get_next_track_with_minimum_timestamp > > > >>> incorrect in imf_read_packet; > > > >>> > > > >>> Signed-off-by: Steven Liu > > > >>> --- > > > >>> libavformat/imfdec.c | 7 +-- > > > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > > > >>> > > > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > > > >>> index 5bbe7a53f8..08f342bc1a 100644 > > > >>> --- a/libavformat/imfdec.c > > > >>> +++ b/libavformat/imfdec.c > > > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > > > >>> *get_next_track_with_minimum_timestamp(AVForma > > > >>> } > > > >>> } > > > >>> > > > >>> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > >>> (timestamp: %lf / %lf)\n", > > > >>> - track->index, av_q2d(track->current_timestamp), > > > >>> av_q2d(minimum_timestamp)); > > > >>> +if (track) > > > >>> +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > > > >>> (timestamp: %lf / %lf)\n", > > > >>> + track->index, av_q2d(track->current_timestamp), > > > >>> av_q2d(minimum_timestamp)); > > > >> > > > >> Coverity actually complained about track being uninitialized, which > > > >> this > > > >> patch does not address. And the reason it does this is that it doesn't > > > >> understand the algorithm: track will always be initialized in the first > > > >> iteration of the loop. > > > > > > > > Is it possible to tell coverity that c->track_count > 0 is a > > > > pre-condition, or should we modify the loop/algorithm? > > > > > > > > > > The typical way to do this is to add an av_assert1 or av_assert2; > > > but this must only be done if it is indeed ensured that the assert will > > > not be triggered. > > > > > > >> (If there is a first iteration of the loop -- is > > > >> this actually guaranteed? A file without tracks seems to be pretty > > > >> useless.) > > > > > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > > > there are no streams/tracks and (b) a track will always be found. > > > > > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > > > it can always be true for a malformed one. > > > > > > > > > > Can't we make it true by adding the relevant checks to read_header? > > > > Yes. > Can imf add or remove track when processing? Looks like the live > streaming change resolution or bitrate when playing. The number of tracks is fixed and determined when the Composition Playlist (CPL) is parsed. > > > > > > > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > > > a patch separately from addressing the coverity issue? > > > > > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > > > >> assumed that track is not initialized in the loop (which boils down to > > > >> saying that it presumed the tracks' current_timestamp to be invalid > > > >> (denominator 0). I hope this can't happen. > > > >> (There is btw another issue: The initialization of minimum_timestamp > > > >> presumes that int are 32bit which need not be true.) > > > > > > > > INT32_MAX -> INT_MAX should fix this right? > > > > > > > > > > Yes. > > > > > > >> > > > >>> return track; > > > >>> } > > > >>> > > > >>> @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, > > > >>> AVPac
Re: [FFmpeg-devel] [PATCH v2] avformat/imfdec: check track valid before use it
On Fri, Aug 26, 2022 at 9:01 AM Andreas Rheinhardt wrote: > > Pierre-Anthony Lemieux: > > On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt > > wrote: > >> > >> Steven Liu: > >>> fix CID: 1512414 > >>> And return AVERROR_INVALIDDATA when get_next_track_with_minimum_timestamp > >>> incorrect in imf_read_packet; > >>> > >>> Signed-off-by: Steven Liu > >>> --- > >>> libavformat/imfdec.c | 7 +-- > >>> 1 file changed, 5 insertions(+), 2 deletions(-) > >>> > >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > >>> index 5bbe7a53f8..08f342bc1a 100644 > >>> --- a/libavformat/imfdec.c > >>> +++ b/libavformat/imfdec.c > >>> @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > >>> *get_next_track_with_minimum_timestamp(AVForma > >>> } > >>> } > >>> > >>> -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: > >>> %lf / %lf)\n", > >>> - track->index, av_q2d(track->current_timestamp), > >>> av_q2d(minimum_timestamp)); > >>> +if (track) > >>> +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d > >>> (timestamp: %lf / %lf)\n", > >>> + track->index, av_q2d(track->current_timestamp), > >>> av_q2d(minimum_timestamp)); > >> > >> Coverity actually complained about track being uninitialized, which this > >> patch does not address. And the reason it does this is that it doesn't > >> understand the algorithm: track will always be initialized in the first > >> iteration of the loop. > > > > Is it possible to tell coverity that c->track_count > 0 is a > > pre-condition, or should we modify the loop/algorithm? > > > > The typical way to do this is to add an av_assert1 or av_assert2; > but this must only be done if it is indeed ensured that the assert will > not be triggered. > > >> (If there is a first iteration of the loop -- is > >> this actually guaranteed? A file without tracks seems to be pretty > >> useless.) > > > > imfdec currently assumes that (a) imf_read_packet() is not called if > > there are no streams/tracks and (b) a track will always be found. > > > > (b) will be true for a conformant IMF Composition, but I am not sure > > it can always be true for a malformed one. > > > > Can't we make it true by adding the relevant checks to read_header? Yes. > > > I think imf_read_packet() can probably be hardened. Perhaps do this as > > a patch separately from addressing the coverity issue? > > > >> FYI: In Coverity's analysis there are loop iterations, but it just > >> assumed that track is not initialized in the loop (which boils down to > >> saying that it presumed the tracks' current_timestamp to be invalid > >> (denominator 0). I hope this can't happen. > >> (There is btw another issue: The initialization of minimum_timestamp > >> presumes that int are 32bit which need not be true.) > > > > INT32_MAX -> INT_MAX should fix this right? > > > > Yes. > > >> > >>> return track; > >>> } > >>> > >>> @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, > >>> AVPacket *pkt) > >>> AVRational next_timestamp; > >>> > >>> track = get_next_track_with_minimum_timestamp(s); > >>> +if (!track) > >>> +return AVERROR_INVALIDDATA; > >>> > >>> ret = get_resource_context_for_timestamp(s, track, ); > >>> if (ret) > >> > >> ___ > >> 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 mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/tests/imf: Test ff_imf_parse_cpl_from_xml_dom cleanup on error
On Fri, Aug 26, 2022 at 1:22 AM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Thu, Aug 25, 2022 at 1:58 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Improves the test; also should fix Coverity issue #1512408.
> >>
> >> Signed-off-by: Andreas Rheinhardt
> >> ---
> >> libavformat/tests/imf.c | 10 ++
> >> 1 file changed, 6 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
> >> index e65629ccbc..a7b2ed3b4d 100644
> >> --- a/libavformat/tests/imf.c
> >> +++ b/libavformat/tests/imf.c
> >> @@ -338,10 +338,9 @@ static int test_cpl_parsing(void)
> >> return 0;
> >> }
> >>
> >> -static int test_bad_cpl_parsing(void)
> >> +static int test_bad_cpl_parsing(FFIMFCPL **cpl)
> >> {
> >> xmlDocPtr doc;
> >> -FFIMFCPL *cpl;
> >> int ret;
> >>
> >> doc = xmlReadMemory(cpl_bad_doc, strlen(cpl_bad_doc), NULL, NULL, 0);
> >> @@ -350,7 +349,7 @@ static int test_bad_cpl_parsing(void)
> >> return 1;
> >> }
> >>
> >> -ret = ff_imf_parse_cpl_from_xml_dom(doc, );
> >> +ret = ff_imf_parse_cpl_from_xml_dom(doc, cpl);
> >> xmlFreeDoc(doc);
> >> if (ret) {
> >> printf("CPL parsing failed.\n");
> >> @@ -506,6 +505,7 @@ fail:
> >>
> >> int main(int argc, char *argv[])
> >> {
> >> +FFIMFCPL *cpl;
> >> int ret = 0;
> >>
> >> if (test_cpl_parsing() != 0)
> >> @@ -518,8 +518,10 @@ int main(int argc, char *argv[])
> >> ret = 1;
> >>
> >> printf(" The following should fail \n");
> >> -if (test_bad_cpl_parsing() == 0)
> >> +if (test_bad_cpl_parsing() == 0)
> >> ret = 1;
> >> +else if (cpl)
> >> +printf("Improper cleanup after failed CPL parsing\n");
> >
> > Shouldn't `ret` be set to 1 here as well?
> >
>
> Will do. (When run as part of FATE, the test would nevertheless fail,
> because the ref file does not contain the "Improper cleanup" line.)
Thanks, and yes.
>
> >> printf(" End failing test \n");
> >>
> >> return ret;
> >> --
> >> 2.34.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] avformat/imfdec: check track valid before use it
On Fri, Aug 26, 2022 at 1:37 AM Andreas Rheinhardt wrote: > > Steven Liu: > > fix CID: 1512414 > > And return AVERROR_INVALIDDATA when get_next_track_with_minimum_timestamp > > incorrect in imf_read_packet; > > > > Signed-off-by: Steven Liu > > --- > > libavformat/imfdec.c | 7 +-- > > 1 file changed, 5 insertions(+), 2 deletions(-) > > > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > > index 5bbe7a53f8..08f342bc1a 100644 > > --- a/libavformat/imfdec.c > > +++ b/libavformat/imfdec.c > > @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > > *get_next_track_with_minimum_timestamp(AVForma > > } > > } > > > > -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: %lf > > / %lf)\n", > > - track->index, av_q2d(track->current_timestamp), > > av_q2d(minimum_timestamp)); > > +if (track) > > +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: > > %lf / %lf)\n", > > + track->index, av_q2d(track->current_timestamp), > > av_q2d(minimum_timestamp)); > > Coverity actually complained about track being uninitialized, which this > patch does not address. And the reason it does this is that it doesn't > understand the algorithm: track will always be initialized in the first > iteration of the loop. Is it possible to tell coverity that c->track_count > 0 is a pre-condition, or should we modify the loop/algorithm? > (If there is a first iteration of the loop -- is > this actually guaranteed? A file without tracks seems to be pretty useless.) imfdec currently assumes that (a) imf_read_packet() is not called if there are no streams/tracks and (b) a track will always be found. (b) will be true for a conformant IMF Composition, but I am not sure it can always be true for a malformed one. I think imf_read_packet() can probably be hardened. Perhaps do this as a patch separately from addressing the coverity issue? > FYI: In Coverity's analysis there are loop iterations, but it just > assumed that track is not initialized in the loop (which boils down to > saying that it presumed the tracks' current_timestamp to be invalid > (denominator 0). I hope this can't happen. > (There is btw another issue: The initialization of minimum_timestamp > presumes that int are 32bit which need not be true.) INT32_MAX -> INT_MAX should fix this right? > > > return track; > > } > > > > @@ -760,6 +761,8 @@ static int imf_read_packet(AVFormatContext *s, AVPacket > > *pkt) > > AVRational next_timestamp; > > > > track = get_next_track_with_minimum_timestamp(s); > > +if (!track) > > +return AVERROR_INVALIDDATA; > > > > ret = get_resource_context_for_timestamp(s, track, ); > > if (ret) > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/tests/imf: Test ff_imf_parse_cpl_from_xml_dom cleanup on error
On Thu, Aug 25, 2022 at 1:58 PM Andreas Rheinhardt
wrote:
>
> Improves the test; also should fix Coverity issue #1512408.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/tests/imf.c | 10 ++
> 1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/tests/imf.c b/libavformat/tests/imf.c
> index e65629ccbc..a7b2ed3b4d 100644
> --- a/libavformat/tests/imf.c
> +++ b/libavformat/tests/imf.c
> @@ -338,10 +338,9 @@ static int test_cpl_parsing(void)
> return 0;
> }
>
> -static int test_bad_cpl_parsing(void)
> +static int test_bad_cpl_parsing(FFIMFCPL **cpl)
> {
> xmlDocPtr doc;
> -FFIMFCPL *cpl;
> int ret;
>
> doc = xmlReadMemory(cpl_bad_doc, strlen(cpl_bad_doc), NULL, NULL, 0);
> @@ -350,7 +349,7 @@ static int test_bad_cpl_parsing(void)
> return 1;
> }
>
> -ret = ff_imf_parse_cpl_from_xml_dom(doc, );
> +ret = ff_imf_parse_cpl_from_xml_dom(doc, cpl);
> xmlFreeDoc(doc);
> if (ret) {
> printf("CPL parsing failed.\n");
> @@ -506,6 +505,7 @@ fail:
>
> int main(int argc, char *argv[])
> {
> +FFIMFCPL *cpl;
> int ret = 0;
>
> if (test_cpl_parsing() != 0)
> @@ -518,8 +518,10 @@ int main(int argc, char *argv[])
> ret = 1;
>
> printf(" The following should fail \n");
> -if (test_bad_cpl_parsing() == 0)
> +if (test_bad_cpl_parsing() == 0)
> ret = 1;
> +else if (cpl)
> +printf("Improper cleanup after failed CPL parsing\n");
Shouldn't `ret` be set to 1 here as well?
> printf(" End failing test \n");
>
> return ret;
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avformat/imfdec: check track valid before use it
Since we are protecting against the algorithm within get_next_track_with_minimum_timestamp() return NULL, should this patch also include immediately returning from imf_read_packet() if get_next_track_with_minimum_timestamp() returns NULL? On Thu, Aug 25, 2022 at 7:53 PM Steven Liu wrote: > > fix CID: 1512414 > > Signed-off-by: Steven Liu > --- > libavformat/imfdec.c | 5 +++-- > 1 file changed, 3 insertions(+), 2 deletions(-) > > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c > index 5bbe7a53f8..a97dcc3b8b 100644 > --- a/libavformat/imfdec.c > +++ b/libavformat/imfdec.c > @@ -697,8 +697,9 @@ static IMFVirtualTrackPlaybackCtx > *get_next_track_with_minimum_timestamp(AVForma > } > } > > -av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: %lf / > %lf)\n", > - track->index, av_q2d(track->current_timestamp), > av_q2d(minimum_timestamp)); > +if (track) > +av_log(s, AV_LOG_DEBUG, "Found next track to read: %d (timestamp: > %lf / %lf)\n", > + track->index, av_q2d(track->current_timestamp), > av_q2d(minimum_timestamp)); > return track; > } > > -- > 2.25.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".
Re: [FFmpeg-devel] [PATCH] avformat/imf_cpl: Check the right variable
LGTM On Thu, Aug 25, 2022 at 2:01 PM Andreas Rheinhardt wrote: > > Fixes Coverity issue #1512407. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/imf_cpl.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c > index 4acc20feee..474db6b7f5 100644 > --- a/libavformat/imf_cpl.c > +++ b/libavformat/imf_cpl.c > @@ -625,7 +625,7 @@ static int fill_virtual_tracks(xmlNodePtr cpl_element, > FFIMFCPL *cpl) > av_log(NULL, AV_LOG_DEBUG, "Processing IMF CPL Segment\n"); > > sequence_list_elem = > ff_imf_xml_get_child_element_by_name(segment_elem, "SequenceList"); > -if (!segment_list_elem) > +if (!sequence_list_elem) > continue; > > sequence_elem = xmlFirstElementChild(sequence_list_elem); > -- > 2.34.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Tue, Aug 9, 2022 at 6:05 PM Pierre-Anthony Lemieux wrote:
>
> On Mon, Aug 8, 2022 at 7:50 AM Pierre-Anthony Lemieux
> wrote:
> >
> > On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
> > wrote:
> > >
> > > p...@sandflow.com:
> > > > From: Pierre-Anthony Lemieux
> > > >
> > > > Addresses
> > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> > > >
> > > > ---
> > > > libavformat/avformat.c | 66
> > > > libavformat/fifo.c | 8 ++---
> > > > libavformat/internal.h | 11 +++
> > > > libavformat/mux.h| 9 --
> > > > libavformat/mux_utils.c | 28 -
> > > > libavformat/segment.c| 6 ++--
> > > > libavformat/tee.c| 7 ++---
> > > > libavformat/webm_chunk.c | 6 ++--
> > > > 8 files changed, 86 insertions(+), 55 deletions(-)
> > > >
> > > > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > > > index 30d6ea6a49..19c7219471 100644
> > > > --- a/libavformat/avformat.c
> > > > +++ b/libavformat/avformat.c
> > > > @@ -235,6 +235,72 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > > > AVStream *src)
> > > > return 0;
> > > > }
> > > >
> > > > +/**
> > > > + * Copy all stream parameters from source to destination stream, with
> > > > the
> > > > + * exception of the index field, which is usually set by
> > > > avformat_new_stream().
> > > > + *
> > > > + * @param dst pointer to destination AVStream
> > > > + * @param src pointer to source AVStream
> > > > + * @return >=0 on success, AVERROR code on error
> > > > + */
> > > > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > > > +{
> > > > +int ret;
> > > > +
> > > > +dst->id = src->id;
> > > > +dst->time_base = src->time_base;
> > > > +dst->start_time = src->start_time;
> > > > +dst->duration= src->duration;
> > > > +dst->nb_frames = src->nb_frames;
> > > > +dst->disposition = src->disposition;
> > > > +dst->discard = src->discard;
> > > > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > > > +dst->avg_frame_rate = src->avg_frame_rate;
> > > > +dst->event_flags = src->event_flags;
> > > > +dst->r_frame_rate= src->r_frame_rate;
> > > > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > > > +
> > > > +av_dict_free(>metadata);
> > > > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +ret = ff_stream_side_data_copy(dst, src);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +
> > > > +av_packet_unref(>attached_pic);
> > > > +if (src->attached_pic.data) {
> > > > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > > > +if (ret < 0)
> > > > +return ret;
> > > > +}
> > > > +
> > > > +return 0;
> > > > +}
> > > > +
> > > > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream
> > > > *src)
> > > > +{
> > > > +AVStream *st;
> > > > +int ret;
> > > > +
> > > > +st = avformat_new_stream(dst_ctx, NULL);
> > > > +if (!st)
> > > > +return NULL;
> > > > +
> > > > +ret = stream_params_copy(st, src);
> > > > +if (ret < 0) {
> > > > +ff_remove_stream(dst_ctx, st);
> > > > +return NULL;
> > > > +}
> > > > +
> > > > +return st;
> > > > +}
> > > > +
> > > > AVProgram *av_new_program(AVFormatContext *ac, int id)
>
Re: [FFmpeg-devel] [PATCH v7 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Mon, Aug 8, 2022 at 7:50 AM Pierre-Anthony Lemieux wrote:
>
> On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
> wrote:
> >
> > p...@sandflow.com:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> > >
> > > ---
> > > libavformat/avformat.c | 66
> > > libavformat/fifo.c | 8 ++---
> > > libavformat/internal.h | 11 +++
> > > libavformat/mux.h| 9 --
> > > libavformat/mux_utils.c | 28 -
> > > libavformat/segment.c| 6 ++--
> > > libavformat/tee.c| 7 ++---
> > > libavformat/webm_chunk.c | 6 ++--
> > > 8 files changed, 86 insertions(+), 55 deletions(-)
> > >
> > > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > > index 30d6ea6a49..19c7219471 100644
> > > --- a/libavformat/avformat.c
> > > +++ b/libavformat/avformat.c
> > > @@ -235,6 +235,72 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > > AVStream *src)
> > > return 0;
> > > }
> > >
> > > +/**
> > > + * Copy all stream parameters from source to destination stream, with the
> > > + * exception of the index field, which is usually set by
> > > avformat_new_stream().
> > > + *
> > > + * @param dst pointer to destination AVStream
> > > + * @param src pointer to source AVStream
> > > + * @return >=0 on success, AVERROR code on error
> > > + */
> > > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > > +{
> > > +int ret;
> > > +
> > > +dst->id = src->id;
> > > +dst->time_base = src->time_base;
> > > +dst->start_time = src->start_time;
> > > +dst->duration= src->duration;
> > > +dst->nb_frames = src->nb_frames;
> > > +dst->disposition = src->disposition;
> > > +dst->discard = src->discard;
> > > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > > +dst->avg_frame_rate = src->avg_frame_rate;
> > > +dst->event_flags = src->event_flags;
> > > +dst->r_frame_rate= src->r_frame_rate;
> > > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > > +
> > > +av_dict_free(>metadata);
> > > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +ret = ff_stream_side_data_copy(dst, src);
> > > +if (ret < 0)
> > > +return ret;
> > > +
> > > +av_packet_unref(>attached_pic);
> > > +if (src->attached_pic.data) {
> > > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > > +if (ret < 0)
> > > +return ret;
> > > +}
> > > +
> > > +return 0;
> > > +}
> > > +
> > > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream *src)
> > > +{
> > > +AVStream *st;
> > > +int ret;
> > > +
> > > +st = avformat_new_stream(dst_ctx, NULL);
> > > +if (!st)
> > > +return NULL;
> > > +
> > > +ret = stream_params_copy(st, src);
> > > +if (ret < 0) {
> > > +ff_remove_stream(dst_ctx, st);
> > > +return NULL;
> > > +}
> > > +
> > > +return st;
> > > +}
> > > +
> > > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > > {
> > > AVProgram *program = NULL;
> > > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > > index ead2bdc5cf..55d413b952 100644
> > > --- a/libavformat/fifo.c
> > > +++ b/libavformat/fifo.c
> > > @@ -505,13 +505,11 @@ static int fifo_mux_init(AVFormatContext *avf,
> > > const AVOutputFormat *oformat,
> > > avf2->flags = avf->flags;
> > >
> > > for (i = 0; i < avf->nb_streams; ++i) {
> > > -AVStream *st = avformat_new_stream(avf2, NULL);
> > > +AVStream *s
Re: [FFmpeg-devel] [PATCH v7 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Mon, Aug 8, 2022 at 7:48 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299726.html
> >
> > ---
> > libavformat/avformat.c | 66
> > libavformat/fifo.c | 8 ++---
> > libavformat/internal.h | 11 +++
> > libavformat/mux.h| 9 --
> > libavformat/mux_utils.c | 28 -
> > libavformat/segment.c| 6 ++--
> > libavformat/tee.c| 7 ++---
> > libavformat/webm_chunk.c | 6 ++--
> > 8 files changed, 86 insertions(+), 55 deletions(-)
> >
> > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > index 30d6ea6a49..19c7219471 100644
> > --- a/libavformat/avformat.c
> > +++ b/libavformat/avformat.c
> > @@ -235,6 +235,72 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > AVStream *src)
> > return 0;
> > }
> >
> > +/**
> > + * Copy all stream parameters from source to destination stream, with the
> > + * exception of the index field, which is usually set by
> > avformat_new_stream().
> > + *
> > + * @param dst pointer to destination AVStream
> > + * @param src pointer to source AVStream
> > + * @return >=0 on success, AVERROR code on error
> > + */
> > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > +{
> > +int ret;
> > +
> > +dst->id = src->id;
> > +dst->time_base = src->time_base;
> > +dst->start_time = src->start_time;
> > +dst->duration= src->duration;
> > +dst->nb_frames = src->nb_frames;
> > +dst->disposition = src->disposition;
> > +dst->discard = src->discard;
> > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > +dst->avg_frame_rate = src->avg_frame_rate;
> > +dst->event_flags = src->event_flags;
> > +dst->r_frame_rate= src->r_frame_rate;
> > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > +
> > +av_dict_free(>metadata);
> > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = ff_stream_side_data_copy(dst, src);
> > +if (ret < 0)
> > +return ret;
> > +
> > +av_packet_unref(>attached_pic);
> > +if (src->attached_pic.data) {
> > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream *src)
> > +{
> > +AVStream *st;
> > +int ret;
> > +
> > +st = avformat_new_stream(dst_ctx, NULL);
> > +if (!st)
> > +return NULL;
> > +
> > +ret = stream_params_copy(st, src);
> > +if (ret < 0) {
> > +ff_remove_stream(dst_ctx, st);
> > +return NULL;
> > +}
> > +
> > +return st;
> > +}
> > +
> > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > {
> > AVProgram *program = NULL;
> > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > index ead2bdc5cf..55d413b952 100644
> > --- a/libavformat/fifo.c
> > +++ b/libavformat/fifo.c
> > @@ -505,13 +505,11 @@ static int fifo_mux_init(AVFormatContext *avf, const
> > AVOutputFormat *oformat,
> > avf2->flags = avf->flags;
> >
> > for (i = 0; i < avf->nb_streams; ++i) {
> > -AVStream *st = avformat_new_stream(avf2, NULL);
> > +AVStream *st = NULL;
> > +
> > +st = ff_stream_clone(avf2, avf->streams[i]);
>
> I don't know why you stopped initializing st directly with its eventual
> value (if I see this corrently, the line wouldn't be overlong). I can
> fix this upon commit if you allow. Anyway, I will apply this in two days
> unless there are any comments from anyone else.
I thought if() was not favored.
Please modify as you see fit.
Thanks.
>
> > if (!st)
> > return AVERROR(ENOMEM);
> > -
> > -ret = ff_stream_encode_params_copy(st, avf->stream
Re: [FFmpeg-devel] [PATCH v6 1/2] avformat: refactor ff_stream_encode_params_copy() to stream_params_copy()
On Sat, Aug 6, 2022 at 2:43 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299685.html
> >
> > ---
> > libavformat/avformat.c | 68
> > libavformat/fifo.c | 8 ++---
> > libavformat/internal.h | 12 +++
> > libavformat/mux.h| 9 --
> > libavformat/mux_utils.c | 28 -
> > libavformat/segment.c| 6 ++--
> > libavformat/tee.c| 7 ++---
> > libavformat/webm_chunk.c | 6 ++--
> > 8 files changed, 89 insertions(+), 55 deletions(-)
> >
> > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > index 30d6ea6a49..64c9d71a24 100644
> > --- a/libavformat/avformat.c
> > +++ b/libavformat/avformat.c
> > @@ -235,6 +235,74 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > AVStream *src)
> > return 0;
> > }
> >
> > +/**
> > + * Copy all stream parameters from source to destination stream, with the
> > + * exception of:
> > + * * the index field, which is usually set by avformat_new_stream()
> > + * * the attached_pic field, if attached_pic.size is 0 or less
> > + *
> > + * @param dst pointer to destination AVStream
> > + * @param src pointer to source AVStream
> > + * @return >=0 on success, AVERROR code on error
> > + */
> > +static int stream_params_copy(AVStream *dst, const AVStream *src)
> > +{
> > +int ret;
> > +
> > +dst->id = src->id;
> > +dst->time_base = src->time_base;
> > +dst->start_time = src->start_time;
> > +dst->duration= src->duration;
> > +dst->nb_frames = src->nb_frames;
> > +dst->disposition = src->disposition;
> > +dst->discard = src->discard;
> > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > +dst->avg_frame_rate = src->avg_frame_rate;
> > +dst->event_flags = src->event_flags;
> > +dst->r_frame_rate= src->r_frame_rate;
> > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > +
> > +av_dict_free(>metadata);
> > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = ff_stream_side_data_copy(dst, src);
> > +if (ret < 0)
> > +return ret;
> > +
> > +av_packet_unref(>attached_pic);
> > +if (src->attached_pic.size > 0) {
>
> I'd rather have it that you check for attached_pic.data instead (even if
> this might mean that avformat_queue_attached_pictures() might warn for
> the dst stream lateron because of a packet with size zero). That way you
> would be copying the packet iff the src packet is set (side-data only
> attached pics don't exist).
> This would also mean that the behaviour of attached pic would no longer
> be exceptional, i.e. it needn't be documented.
Addressed at v7
>
> > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > +AVStream *ff_stream_clone(AVFormatContext *dst_ctx, const AVStream *src)
> > +{
> > +AVStream *st;
> > +int ret;
> > +
> > +st = avformat_new_stream(dst_ctx, NULL);
> > +if (!st)
> > +return NULL;
> > +
> > +ret = stream_params_copy(st, src);
> > +if (ret < 0) {
> > +ff_remove_stream(dst_ctx, st);
> > +return NULL;
> > +}
> > +
> > +return st;
> > +}
> > +
> > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > {
> > AVProgram *program = NULL;
> > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > index ead2bdc5cf..55d413b952 100644
> > --- a/libavformat/fifo.c
> > +++ b/libavformat/fifo.c
> > @@ -505,13 +505,11 @@ static int fifo_mux_init(AVFormatContext *avf, const
> > AVOutputFormat *oformat,
> > avf2->flags = avf->flags;
> >
> > for (i = 0; i < avf->nb_streams; ++i) {
> > -AVStream *st = avformat_new_stream(avf2, NULL);
> > +AVStream *st = NULL;
> > +
>
Re: [FFmpeg-devel] [PATCH v5 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Thu, Aug 4, 2022 at 4:24 PM Pierre-Anthony Lemieux wrote:
>
> On Thu, Aug 4, 2022 at 4:13 PM Andreas Rheinhardt
> wrote:
> >
> > Pierre-Anthony Lemieux:
> > > On Thu, Aug 4, 2022 at 3:22 PM Andreas Rheinhardt
> > > wrote:
> > >>
> > >> Pierre-Anthony Lemieux:
> > >>> On Thu, Aug 4, 2022 at 10:15 AM Andreas Rheinhardt
> > >>> wrote:
> > >>>>
> > >>>> Pierre-Anthony Lemieux:
> > >>>>> On Thu, Aug 4, 2022 at 9:53 AM Andreas Rheinhardt
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> p...@sandflow.com:
> > >>>>>>> From: Pierre-Anthony Lemieux
> > >>>>>>>
> > >>>>>>> As discussed at
> > >>>>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> > >>>>>>> Note that ff_stream_params_copy() does not copy:
> > >>>>>>> * the index field
> > >>>>>>> * the attached_pic if its size is 0
> > >>>>>>>
> > >>>>>>> Addresses
> > >>>>>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299514.html
> > >>>>>>>
> > >>>>>>> ---
> > >>>>>>> libavformat/avformat.c | 40
> > >>>>>>>
> > >>>>>>> libavformat/fifo.c | 2 +-
> > >>>>>>> libavformat/internal.h | 12
> > >>>>>>> libavformat/mux.h| 9 -
> > >>>>>>> libavformat/mux_utils.c | 28
> > >>>>>>> libavformat/segment.c| 2 +-
> > >>>>>>> libavformat/tee.c| 2 +-
> > >>>>>>> libavformat/webm_chunk.c | 2 +-
> > >>>>>>> 8 files changed, 56 insertions(+), 41 deletions(-)
> > >>>>>>>
> > >>>>>>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > >>>>>>> index 30d6ea6a49..242187c359 100644
> > >>>>>>> --- a/libavformat/avformat.c
> > >>>>>>> +++ b/libavformat/avformat.c
> > >>>>>>> @@ -235,6 +235,46 @@ int ff_stream_side_data_copy(AVStream *dst,
> > >>>>>>> const AVStream *src)
> > >>>>>>> return 0;
> > >>>>>>> }
> > >>>>>>>
> > >>>>>>> +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> > >>>>>>> +{
> > >>>>>>> +int ret;
> > >>>>>>> +
> > >>>>>>> +dst->id = src->id;
> > >>>>>>> +dst->time_base = src->time_base;
> > >>>>>>> +dst->start_time = src->start_time;
> > >>>>>>> +dst->duration= src->duration;
> > >>>>>>> +dst->nb_frames = src->nb_frames;
> > >>>>>>> +dst->disposition = src->disposition;
> > >>>>>>> +dst->discard = src->discard;
> > >>>>>>> +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > >>>>>>> +dst->avg_frame_rate = src->avg_frame_rate;
> > >>>>>>> +dst->event_flags = src->event_flags;
> > >>>>>>> +dst->r_frame_rate= src->r_frame_rate;
> > >>>>>>> +dst->pts_wrap_bits = src->pts_wrap_bits;
> > >>>>>>> +
> > >>>>>>> +av_dict_free(>metadata);
> > >>>>>>> +ret = av_dict_copy(>metadata, src->metadata, 0);
> > >>>>>>> +if (ret < 0)
> > >>>>>>> +return ret;
> > >>>>>>> +
> > >>>>>>> +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > >>>>>>> +if (ret < 0)
> > >>>>>>> +return ret;
> > >>>>>>> +
> > >>>>>>> +
Re: [FFmpeg-devel] [PATCH v5 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Thu, Aug 4, 2022 at 4:13 PM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Thu, Aug 4, 2022 at 3:22 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Pierre-Anthony Lemieux:
> >>> On Thu, Aug 4, 2022 at 10:15 AM Andreas Rheinhardt
> >>> wrote:
> >>>>
> >>>> Pierre-Anthony Lemieux:
> >>>>> On Thu, Aug 4, 2022 at 9:53 AM Andreas Rheinhardt
> >>>>> wrote:
> >>>>>>
> >>>>>> p...@sandflow.com:
> >>>>>>> From: Pierre-Anthony Lemieux
> >>>>>>>
> >>>>>>> As discussed at
> >>>>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> >>>>>>> Note that ff_stream_params_copy() does not copy:
> >>>>>>> * the index field
> >>>>>>> * the attached_pic if its size is 0
> >>>>>>>
> >>>>>>> Addresses
> >>>>>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299514.html
> >>>>>>>
> >>>>>>> ---
> >>>>>>> libavformat/avformat.c | 40
> >>>>>>>
> >>>>>>> libavformat/fifo.c | 2 +-
> >>>>>>> libavformat/internal.h | 12
> >>>>>>> libavformat/mux.h| 9 -
> >>>>>>> libavformat/mux_utils.c | 28
> >>>>>>> libavformat/segment.c| 2 +-
> >>>>>>> libavformat/tee.c| 2 +-
> >>>>>>> libavformat/webm_chunk.c | 2 +-
> >>>>>>> 8 files changed, 56 insertions(+), 41 deletions(-)
> >>>>>>>
> >>>>>>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> >>>>>>> index 30d6ea6a49..242187c359 100644
> >>>>>>> --- a/libavformat/avformat.c
> >>>>>>> +++ b/libavformat/avformat.c
> >>>>>>> @@ -235,6 +235,46 @@ int ff_stream_side_data_copy(AVStream *dst,
> >>>>>>> const AVStream *src)
> >>>>>>> return 0;
> >>>>>>> }
> >>>>>>>
> >>>>>>> +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> >>>>>>> +{
> >>>>>>> +int ret;
> >>>>>>> +
> >>>>>>> +dst->id = src->id;
> >>>>>>> +dst->time_base = src->time_base;
> >>>>>>> +dst->start_time = src->start_time;
> >>>>>>> +dst->duration= src->duration;
> >>>>>>> +dst->nb_frames = src->nb_frames;
> >>>>>>> +dst->disposition = src->disposition;
> >>>>>>> +dst->discard = src->discard;
> >>>>>>> +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> >>>>>>> +dst->avg_frame_rate = src->avg_frame_rate;
> >>>>>>> +dst->event_flags = src->event_flags;
> >>>>>>> +dst->r_frame_rate= src->r_frame_rate;
> >>>>>>> +dst->pts_wrap_bits = src->pts_wrap_bits;
> >>>>>>> +
> >>>>>>> +av_dict_free(>metadata);
> >>>>>>> +ret = av_dict_copy(>metadata, src->metadata, 0);
> >>>>>>> +if (ret < 0)
> >>>>>>> +return ret;
> >>>>>>> +
> >>>>>>> +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> >>>>>>> +if (ret < 0)
> >>>>>>> +return ret;
> >>>>>>> +
> >>>>>>> +ret = ff_stream_side_data_copy(dst, src);
> >>>>>>> +if (ret < 0)
> >>>>>>> +return ret;
> >>>>>>> +
> >>>>>>> +av_packet_unref(>attached_pic);
> >>>>>>> +if (src->attached_pic.size > 0) {
> >>>>>>> +ret = av_packet_ref(>attached_pic, >attached_pic);
&g
Re: [FFmpeg-devel] [PATCH v5 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Thu, Aug 4, 2022 at 3:22 PM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Thu, Aug 4, 2022 at 10:15 AM Andreas Rheinhardt
> > wrote:
> >>
> >> Pierre-Anthony Lemieux:
> >>> On Thu, Aug 4, 2022 at 9:53 AM Andreas Rheinhardt
> >>> wrote:
> >>>>
> >>>> p...@sandflow.com:
> >>>>> From: Pierre-Anthony Lemieux
> >>>>>
> >>>>> As discussed at
> >>>>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> >>>>> Note that ff_stream_params_copy() does not copy:
> >>>>> * the index field
> >>>>> * the attached_pic if its size is 0
> >>>>>
> >>>>> Addresses
> >>>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299514.html
> >>>>>
> >>>>> ---
> >>>>> libavformat/avformat.c | 40
> >>>>> libavformat/fifo.c | 2 +-
> >>>>> libavformat/internal.h | 12
> >>>>> libavformat/mux.h| 9 -
> >>>>> libavformat/mux_utils.c | 28
> >>>>> libavformat/segment.c| 2 +-
> >>>>> libavformat/tee.c| 2 +-
> >>>>> libavformat/webm_chunk.c | 2 +-
> >>>>> 8 files changed, 56 insertions(+), 41 deletions(-)
> >>>>>
> >>>>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> >>>>> index 30d6ea6a49..242187c359 100644
> >>>>> --- a/libavformat/avformat.c
> >>>>> +++ b/libavformat/avformat.c
> >>>>> @@ -235,6 +235,46 @@ int ff_stream_side_data_copy(AVStream *dst, const
> >>>>> AVStream *src)
> >>>>> return 0;
> >>>>> }
> >>>>>
> >>>>> +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> >>>>> +{
> >>>>> +int ret;
> >>>>> +
> >>>>> +dst->id = src->id;
> >>>>> +dst->time_base = src->time_base;
> >>>>> +dst->start_time = src->start_time;
> >>>>> +dst->duration= src->duration;
> >>>>> +dst->nb_frames = src->nb_frames;
> >>>>> +dst->disposition = src->disposition;
> >>>>> +dst->discard = src->discard;
> >>>>> +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> >>>>> +dst->avg_frame_rate = src->avg_frame_rate;
> >>>>> +dst->event_flags = src->event_flags;
> >>>>> +dst->r_frame_rate= src->r_frame_rate;
> >>>>> +dst->pts_wrap_bits = src->pts_wrap_bits;
> >>>>> +
> >>>>> +av_dict_free(>metadata);
> >>>>> +ret = av_dict_copy(>metadata, src->metadata, 0);
> >>>>> +if (ret < 0)
> >>>>> +return ret;
> >>>>> +
> >>>>> +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> >>>>> +if (ret < 0)
> >>>>> +return ret;
> >>>>> +
> >>>>> +ret = ff_stream_side_data_copy(dst, src);
> >>>>> +if (ret < 0)
> >>>>> +return ret;
> >>>>> +
> >>>>> +av_packet_unref(>attached_pic);
> >>>>> +if (src->attached_pic.size > 0) {
> >>>>> +ret = av_packet_ref(>attached_pic, >attached_pic);
> >>>>> +if (ret < 0)
> >>>>> +return ret;
> >>>>> +}
> >>>>> +
> >>>>> +return 0;
> >>>>> +}
> >>>>> +
> >>>>> AVProgram *av_new_program(AVFormatContext *ac, int id)
> >>>>> {
> >>>>> AVProgram *program = NULL;
> >>>>> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> >>>>> index ead2bdc5cf..fef116d040 100644
> >>>>> --- a/libavformat/fifo.c
> >>>>> +++ b/libavformat/fifo.c
> >>>>> @@ -509,7 +509,7 @@ static int fifo_mux_init(A
Re: [FFmpeg-devel] [PATCH v5 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Thu, Aug 4, 2022 at 10:15 AM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Thu, Aug 4, 2022 at 9:53 AM Andreas Rheinhardt
> > wrote:
> >>
> >> p...@sandflow.com:
> >>> From: Pierre-Anthony Lemieux
> >>>
> >>> As discussed at
> >>> https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> >>> Note that ff_stream_params_copy() does not copy:
> >>> * the index field
> >>> * the attached_pic if its size is 0
> >>>
> >>> Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299514.html
> >>>
> >>> ---
> >>> libavformat/avformat.c | 40
> >>> libavformat/fifo.c | 2 +-
> >>> libavformat/internal.h | 12
> >>> libavformat/mux.h| 9 -
> >>> libavformat/mux_utils.c | 28
> >>> libavformat/segment.c| 2 +-
> >>> libavformat/tee.c| 2 +-
> >>> libavformat/webm_chunk.c | 2 +-
> >>> 8 files changed, 56 insertions(+), 41 deletions(-)
> >>>
> >>> diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> >>> index 30d6ea6a49..242187c359 100644
> >>> --- a/libavformat/avformat.c
> >>> +++ b/libavformat/avformat.c
> >>> @@ -235,6 +235,46 @@ int ff_stream_side_data_copy(AVStream *dst, const
> >>> AVStream *src)
> >>> return 0;
> >>> }
> >>>
> >>> +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> >>> +{
> >>> +int ret;
> >>> +
> >>> +dst->id = src->id;
> >>> +dst->time_base = src->time_base;
> >>> +dst->start_time = src->start_time;
> >>> +dst->duration= src->duration;
> >>> +dst->nb_frames = src->nb_frames;
> >>> +dst->disposition = src->disposition;
> >>> +dst->discard = src->discard;
> >>> +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> >>> +dst->avg_frame_rate = src->avg_frame_rate;
> >>> +dst->event_flags = src->event_flags;
> >>> +dst->r_frame_rate= src->r_frame_rate;
> >>> +dst->pts_wrap_bits = src->pts_wrap_bits;
> >>> +
> >>> +av_dict_free(>metadata);
> >>> +ret = av_dict_copy(>metadata, src->metadata, 0);
> >>> +if (ret < 0)
> >>> +return ret;
> >>> +
> >>> +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> >>> +if (ret < 0)
> >>> +return ret;
> >>> +
> >>> +ret = ff_stream_side_data_copy(dst, src);
> >>> +if (ret < 0)
> >>> +return ret;
> >>> +
> >>> +av_packet_unref(>attached_pic);
> >>> +if (src->attached_pic.size > 0) {
> >>> +ret = av_packet_ref(>attached_pic, >attached_pic);
> >>> +if (ret < 0)
> >>> +return ret;
> >>> +}
> >>> +
> >>> +return 0;
> >>> +}
> >>> +
> >>> AVProgram *av_new_program(AVFormatContext *ac, int id)
> >>> {
> >>> AVProgram *program = NULL;
> >>> diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> >>> index ead2bdc5cf..fef116d040 100644
> >>> --- a/libavformat/fifo.c
> >>> +++ b/libavformat/fifo.c
> >>> @@ -509,7 +509,7 @@ static int fifo_mux_init(AVFormatContext *avf, const
> >>> AVOutputFormat *oformat,
> >>> if (!st)
> >>> return AVERROR(ENOMEM);
> >>>
> >>> -ret = ff_stream_encode_params_copy(st, avf->streams[i]);
> >>> +ret = ff_stream_params_copy(st, avf->streams[i]);
> >>> if (ret < 0)
> >>> return ret;
> >>> }
> >>> diff --git a/libavformat/internal.h b/libavformat/internal.h
> >>> index b6b8fbf56f..87a00bbae3 100644
> >>> --- a/libavformat/internal.h
> >>> +++ b/libavformat/internal.h
> >>> @@ -625,6 +625,18 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt,
> >>> int be, int s
Re: [FFmpeg-devel] [PATCH v5 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Thu, Aug 4, 2022 at 9:53 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > As discussed at
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> > Note that ff_stream_params_copy() does not copy:
> > * the index field
> > * the attached_pic if its size is 0
> >
> > Addresses http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299514.html
> >
> > ---
> > libavformat/avformat.c | 40
> > libavformat/fifo.c | 2 +-
> > libavformat/internal.h | 12
> > libavformat/mux.h| 9 -
> > libavformat/mux_utils.c | 28
> > libavformat/segment.c| 2 +-
> > libavformat/tee.c| 2 +-
> > libavformat/webm_chunk.c | 2 +-
> > 8 files changed, 56 insertions(+), 41 deletions(-)
> >
> > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > index 30d6ea6a49..242187c359 100644
> > --- a/libavformat/avformat.c
> > +++ b/libavformat/avformat.c
> > @@ -235,6 +235,46 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > AVStream *src)
> > return 0;
> > }
> >
> > +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> > +{
> > +int ret;
> > +
> > +dst->id = src->id;
> > +dst->time_base = src->time_base;
> > +dst->start_time = src->start_time;
> > +dst->duration= src->duration;
> > +dst->nb_frames = src->nb_frames;
> > +dst->disposition = src->disposition;
> > +dst->discard = src->discard;
> > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > +dst->avg_frame_rate = src->avg_frame_rate;
> > +dst->event_flags = src->event_flags;
> > +dst->r_frame_rate= src->r_frame_rate;
> > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > +
> > +av_dict_free(>metadata);
> > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = ff_stream_side_data_copy(dst, src);
> > +if (ret < 0)
> > +return ret;
> > +
> > +av_packet_unref(>attached_pic);
> > +if (src->attached_pic.size > 0) {
> > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > +if (ret < 0)
> > +return ret;
> > +}
> > +
> > +return 0;
> > +}
> > +
> > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > {
> > AVProgram *program = NULL;
> > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > index ead2bdc5cf..fef116d040 100644
> > --- a/libavformat/fifo.c
> > +++ b/libavformat/fifo.c
> > @@ -509,7 +509,7 @@ static int fifo_mux_init(AVFormatContext *avf, const
> > AVOutputFormat *oformat,
> > if (!st)
> > return AVERROR(ENOMEM);
> >
> > -ret = ff_stream_encode_params_copy(st, avf->streams[i]);
> > +ret = ff_stream_params_copy(st, avf->streams[i]);
> > if (ret < 0)
> > return ret;
> > }
> > diff --git a/libavformat/internal.h b/libavformat/internal.h
> > index b6b8fbf56f..87a00bbae3 100644
> > --- a/libavformat/internal.h
> > +++ b/libavformat/internal.h
> > @@ -625,6 +625,18 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt,
> > int be, int sflags);
> > */
> > int ff_stream_side_data_copy(AVStream *dst, const AVStream *src);
> >
> > +/**
> > + * Copy all stream parameters from source to destination stream, with the
> > + * exception of:
> > + * * the index field, which is usually set by avformat_new_stream()
> > + * * the attached_pic field, if attached_pic.size is 0 or less
> > + *
> > + * @param dst pointer to destination AVStream
> > + * @param src pointer to source AVStream
> > + * @return >=0 on success, AVERROR code on error
> > + */
> > +int ff_stream_params_copy(AVStream *dst, const AVStream *src);
> > +
> > /**
> > * Wrap ffurl_move() and log if error happens.
> > *
> > diff --git a/libavformat/mux.h b/libavformat/mux.h
> > index c01da82194..1bfcaf795f 100644
Re: [FFmpeg-devel] [PATCH v4 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Sun, Jul 31, 2022 at 2:02 PM James Almer wrote:
>
> On 7/31/2022 5:37 PM, p...@sandflow.com wrote:
> > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > index 30d6ea6a49..1d0ac5ab7e 100644
> > --- a/libavformat/avformat.c
> > +++ b/libavformat/avformat.c
> > @@ -235,6 +235,47 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > AVStream *src)
> > return 0;
> > }
> >
> > +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> > +{
> > +int ret;
> > +
> > +dst->id = src->id;
> > +dst->time_base = src->time_base;
> > +dst->start_time = src->start_time;
> > +dst->duration= src->duration;
> > +dst->nb_frames = src->nb_frames;
> > +dst->disposition = src->disposition;
> > +dst->discard = src->discard;
> > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > +dst->avg_frame_rate = src->avg_frame_rate;
> > +dst->event_flags = src->event_flags;
> > +dst->r_frame_rate= src->r_frame_rate;
> > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > +
> > +av_dict_free(>metadata);
> > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = ff_stream_side_data_copy(dst, src);
> > +if (ret < 0)
> > +return ret;
> > +
> > +if (src->attached_pic.size > 0) {
> > +ret = av_packet_ref(>attached_pic, >attached_pic);
> > +if (ret < 0)
> > +return ret;
> > +} else {
> > +av_packet_unref(>attached_pic);
>
> This would need to be called unconditionally, like you did for
> dst->metadata, and just if src->attached_pic is empty.
Thanks. I had incorrectly assumed that av_packet_ref() first unref'ed
the destination.
Addressed at v5:
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299515.html
>
> > +}
> > +
> > +return 0;
> > +}
> > +
> > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > {
> > AVProgram *program = NULL;
> ___
> 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 1/3] avformat/mxfdec: SMPTE RDD 48:2018 support
On Fri, Jul 29, 2022 at 4:19 PM Tomas Härdin wrote:
>
> fre 2022-07-29 klockan 14:14 +0200 skrev Pierre-Anthony Lemieux:
> > On Fri, Jul 29, 2022 at 6:15 AM Tomas Härdin
> > wrote:
> > >
> > > fre 2022-07-29 klockan 01:18 +0200 skrev Michael Niedermayer:
> > > > On Tue, Jul 19, 2022 at 03:48:59PM +0200, Tomas Härdin wrote:
> > > > > mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> > > > > >
> > > > > > +{ {
> > > > > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0
> > > > > > x03,
> > > > > > 0x09
> > > > > > ,0x01,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> > > > > > +{ {
> > > > > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0
> > > > > > x03,
> > > > > > 0x09
> > > > > > ,0x02,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V1 */
> > > > > > +{ {
> > > > >
> > > > > Double-checked, these are correct
> >
> > I recommend the draft SMPTE metadata registry at the following as the
> > reference for ULs:
> >
> > https://registry.smpte-ra.org/apps/pages/
> >
> > The registry is kept up-to-date, machine readable and free to access.
>
> Neato. I actually have a tool for parsing ULs that I call wtful. For
> now it parses relevant RP spreadsheets, but it's kinda shitty. Maybe I
> can improve and publish it.
The canonical format for the SMPTE registers is XML. The data (and
corresponding XSDs) can also be found at:
https://registry.smpte-ra.org/apps/pages/draft/
("draft" registries are 99% correct. "published" are 99.9% correct but
lag by about 6 months.)
The following are Java bindings for folks that are into that :)
https://github.com/sandflow/regxmllib/tree/master/src/main/java/com/sandflow/smpte/register
> >
>
> > > > >
> > > > > > +{ {
> > > > > > 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0
> > > > > > x01,
> > > > > > 0x01
> > > > > > ,0x81,0x03 }, mxf_read_ffv1_sub_descriptor,
> > > > > > sizeof(MXFFFV1SubDescriptor), FFV1SubDescriptor },
> > > > >
> > > > > The spec says 0x7F not 0x53. 0x53 is used in groups with 2-byte
> > > > > tags
> > > >
> > > > If i put 0x7F with no other change there, it will break demuxing
> > > > the
> > > > files i have
> > > > I guess i must have copied this from the files without noticing
> > > > it
> > > > mismatches
> > > > the spec
> > >
> > > Yeah I would expect it to break with 0x7F. Perhaps this will change
> > > when the spec becomes official. If you have contact with the people
> > > involved in this then I suggest asking them about this. It could
> > > also
> > > be a typo in the spec.
> >
> > Byte 6 of Group ULs is set by convention to the wildcard value 0x7F
> > to
> > indicate that the encoding of the Group is not limited to 0x53 (local
> > set with 2-byte local tags and length field). See the following:
> >
> >
> > https://registry.smpte-ra.org/view/draft/docs/Submissions%20Overview/Document-Editors-Information--Style-Guide/#groups-ul
> >
> > MXF restricts header metadata to local sets with 2-byte local tags
> > and
> > 2-byte or BER lengths, so byte 6 can be 0x13 or 0x53.
>
> Alright, then it's fine. Maybe at some point we'll need to implement
> BER lengths in local sets, but not now
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avformat/mxfdec: SMPTE RDD 48:2018 support
On Fri, Jul 29, 2022 at 6:15 AM Tomas Härdin wrote:
>
> fre 2022-07-29 klockan 01:18 +0200 skrev Michael Niedermayer:
> > On Tue, Jul 19, 2022 at 03:48:59PM +0200, Tomas Härdin wrote:
> > > mån 2022-07-11 klockan 23:44 +0200 skrev Michael Niedermayer:
> > > >
> > > > +{ {
> > > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,
> > > > 0x09
> > > > ,0x01,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> > > > +{ {
> > > > 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,
> > > > 0x09
> > > > ,0x02,0x00 }, 15, AV_CODEC_ID_FFV1 }, /*FFV1 V1 */
> > > > +{ {
> > >
> > > Double-checked, these are correct
I recommend the draft SMPTE metadata registry at the following as the
reference for ULs:
https://registry.smpte-ra.org/apps/pages/
The registry is kept up-to-date, machine readable and free to access.
> > >
> > > > +typedef struct MXFFFV1SubDescriptor {
> > > > +MXFMetadataSet meta;
> > > > +uint8_t *extradata;
> > > > +int extradata_size;
> > >
> > > Is FFV1 extradata size bounded? It so we could avoid an allocation.
> > > Either way the local set syntax limits this to 64k, see below.
> >
> > the extradata is extensible so future versions can be bigger.
> > For the current version there should be a maximum. As the extradata
> > uses
> > an adaptive range coder it is not trivial to give a tight limit. It
> > would
> > be easy to give some non tight limit. But iam not sure this has any
> > point
> > as future versions can be bigger
> > [...]
> > i also dont think a static array is a good idea, there is
> > no size limit unless you want to limit to a specific version and
> > compute a worst case bound on a adaptive coder. And then
> > that worst case would be orders of magnitude bigger than real
> > extradata
> > because real extradata compresses quite well. While the worst case
> > would
> > be the case that is biggest and compresses worst. So a static array
> > would waste space
>
> Values in (0x53) local sets are limited to 64k, so it should be fine in
> this context
>
>
> > >
> > > > +{ {
> > > > 0x06,0x0e,0x2b,0x34,0x02,0x53,0x01,0x01,0x0d,0x01,0x01,0x01,0x01,
> > > > 0x01
> > > > ,0x81,0x03 }, mxf_read_ffv1_sub_descriptor,
> > > > sizeof(MXFFFV1SubDescriptor), FFV1SubDescriptor },
> > >
> > > The spec says 0x7F not 0x53. 0x53 is used in groups with 2-byte
> > > tags
> >
> > If i put 0x7F with no other change there, it will break demuxing the
> > files i have
> > I guess i must have copied this from the files without noticing it
> > mismatches
> > the spec
>
> Yeah I would expect it to break with 0x7F. Perhaps this will change
> when the spec becomes official. If you have contact with the people
> involved in this then I suggest asking them about this. It could also
> be a typo in the spec.
Byte 6 of Group ULs is set by convention to the wildcard value 0x7F to
indicate that the encoding of the Group is not limited to 0x53 (local
set with 2-byte local tags and length field). See the following:
https://registry.smpte-ra.org/view/draft/docs/Submissions%20Overview/Document-Editors-Information--Style-Guide/#groups-ul
MXF restricts header metadata to local sets with 2-byte local tags and
2-byte or BER lengths, so byte 6 can be 0x13 or 0x53.
>
> >
> >
> > > rather than full KLVs. The intent here seems to be to use local
> > > tags,
> > > which fortuitously limits extradata_size to 64k. This makes me
> > > think
> > > Amendment 1:2022 is wrong or that 0x7F is just to signal private
> > > use
> > > until it gets rolled into the next version of RDD 48.
> > >
> > > Tables 18 and 23 in S377m-1-2009 say that 0x7F corresponds to
> > > "Abstract
> > > Groups" which are "never encoded as Metadata Sets".
> > >
> > > Reading S336m-2007 it seems one can actually use various lengths
> > > and
> > > tag sizes. 0x53 corresponds to 2 byte length and 2 byte tag. S377m
> > > says
> > > that in addition to this, 0x13 is allowed in MXF which uses ASN.1
> > > BER
> > > encoded lengths. Don't know if any files in the wild use that.
> > > Probably
> > > not.
> >
> > couldnt they make this more complex and bizarr?
>
> Welcome to the world of MXF.
>
> The flip side here is that extradata over 64k *can* be encoded legally,
> but I have never seen it in the wild and mxfdec doesn't support it
> (yet). In that light it makes sense to keep the extradata allocation
> dynamic
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 v3 1/2] avformat: refactor ff_stream_encode_params_copy() to ff_stream_params_copy()
On Tue, Jul 26, 2022 at 8:17 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > As discussed at
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2022-July/298491.html.
> > Note that ff_stream_params_copy() does not copy the index field, which is
> > usually set by avformat_new_stream().
> >
> > ---
> > libavformat/avformat.c | 37 +
> > libavformat/fifo.c | 2 +-
> > libavformat/internal.h | 10 ++
> > libavformat/mux.h| 9 -
> > libavformat/mux_utils.c | 28
> > libavformat/segment.c| 2 +-
> > libavformat/tee.c| 2 +-
> > libavformat/webm_chunk.c | 2 +-
> > 8 files changed, 51 insertions(+), 41 deletions(-)
> >
> > diff --git a/libavformat/avformat.c b/libavformat/avformat.c
> > index 30d6ea6a49..c426dbfa45 100644
> > --- a/libavformat/avformat.c
> > +++ b/libavformat/avformat.c
> > @@ -235,6 +235,43 @@ int ff_stream_side_data_copy(AVStream *dst, const
> > AVStream *src)
> > return 0;
> > }
> >
> > +int ff_stream_params_copy(AVStream *dst, const AVStream *src)
> > +{
> > +int ret;
> > +
> > +dst->id = src->id;
> > +dst->time_base = src->time_base;
> > +dst->start_time = src->start_time;
> > +dst->duration= src->duration;
> > +dst->nb_frames = src->nb_frames;
> > +dst->disposition = src->disposition;
> > +dst->discard = src->discard;
> > +dst->sample_aspect_ratio = src->sample_aspect_ratio;
> > +dst->avg_frame_rate = src->avg_frame_rate;
> > +dst->event_flags = src->event_flags;
> > +dst->r_frame_rate= src->r_frame_rate;
> > +dst->pts_wrap_bits = src->pts_wrap_bits;
> > +
> > +av_dict_free(>metadata);
> > +ret = av_dict_copy(>metadata, src->metadata, 0);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = avcodec_parameters_copy(dst->codecpar, src->codecpar);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = ff_stream_side_data_copy(dst, src);
> > +if (ret < 0)
> > +return ret;
> > +
> > +ret = av_packet_ref(>attached_pic, >attached_pic);
>
> This will allocate a buffer of size AV_INPUT_BUFFER_PADDING_SIZE in
> dst->attached_pic (and set the size of the data of said packet to 0) if
> the size of the data of src->attached_pic is zero (in particular, if it
> is truely blank). This is not desired.
As I understand it, this behavior is triggered if src->attached_pic is
not null and not ref-counted. Is that right? If so, are there
circumstances where src->attached_pic is not ref-counted?
ff_add_attached_pic() seems to add ref-counted data.
av_packet_ref() creates a ref-counted buffer if the src packet does
not contain one. Changing that behavior would require duplicating the
mechanics of av_packet_ref().
... or maybe there is a much simpler approach?
>
> > +if (ret < 0)
> > +return ret;
> > +
> > +return 0;
> > +}
> > +
> > AVProgram *av_new_program(AVFormatContext *ac, int id)
> > {
> > AVProgram *program = NULL;
> > diff --git a/libavformat/fifo.c b/libavformat/fifo.c
> > index ead2bdc5cf..fef116d040 100644
> > --- a/libavformat/fifo.c
> > +++ b/libavformat/fifo.c
> > @@ -509,7 +509,7 @@ static int fifo_mux_init(AVFormatContext *avf, const
> > AVOutputFormat *oformat,
> > if (!st)
> > return AVERROR(ENOMEM);
> >
> > -ret = ff_stream_encode_params_copy(st, avf->streams[i]);
> > +ret = ff_stream_params_copy(st, avf->streams[i]);
> > if (ret < 0)
> > return ret;
> > }
> > diff --git a/libavformat/internal.h b/libavformat/internal.h
> > index b6b8fbf56f..774ff57698 100644
> > --- a/libavformat/internal.h
> > +++ b/libavformat/internal.h
> > @@ -625,6 +625,16 @@ enum AVCodecID ff_get_pcm_codec_id(int bps, int flt,
> > int be, int sflags);
> > */
> > int ff_stream_side_data_copy(AVStream *dst, const AVStream *src);
> >
> > +/**
> > + * Copy all stream parameters from source to destination stream, with the
> > + * exception of the index field, which is usually set by
> > avformat_new_stream().
> > + *
> > + * @param dst pointe
Re: [FFmpeg-devel] [PATCH] fate/imf: Rename IMF fate-target
LGTM. On Sun, Jul 24, 2022 at 9:43 PM Andreas Rheinhardt wrote: > > It conflicts with the name of the test using the testtool > in libavformat.mak. > > Fixes ticket #9841. > > Signed-off-by: Andreas Rheinhardt > --- > Other naming suggestions welcome. > > tests/fate/imf.mak | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak > index 70a3efdfbd..feb54d1361 100644 > --- a/tests/fate/imf.mak > +++ b/tests/fate/imf.mak > @@ -3,4 +3,4 @@ fate-imf-cpl-with-repeat: CMD = framecrc -f imf -i > $(TARGET_SAMPLES)/imf/countdo > > FATE_SAMPLES_FFMPEG-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF) > > -fate-imf: $(FATE_IMF) > +fate-imfdec: $(FATE_IMF) > -- > 2.34.1 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel 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] avformat/imfdec: preserve stream information
On Sun, Jul 3, 2022 at 2:13 PM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Sun, Jul 3, 2022 at 12:15 PM Andreas Rheinhardt
> > wrote:
> >>
> >> Pierre-Anthony Lemieux:
> >>> On Sun, Jul 3, 2022 at 11:28 AM Andreas Rheinhardt
> >>> wrote:
> >>>>
> >>>> p...@sandflow.com:
> >>>>> From: Pierre-Anthony Lemieux
> >>>>>
> >>>>> As discussed at https://trac.ffmpeg.org/ticket/9818, the IMF demuxer
> >>>>> does not
> >>>>> currently preserve stream information such as language in the case of
> >>>>> audio
> >>>>> streams. This patch is modeled on copy_stream_props() at
> >>>>> avformat/concatdec.c.
> >>>>>
> >>>>> ---
> >>>>> libavformat/imfdec.c | 5 +
> >>>>> 1 file changed, 5 insertions(+)
> >>>>>
> >>>>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> >>>>> index 71dfb26958..7aa66a06bf 100644
> >>>>> --- a/libavformat/imfdec.c
> >>>>> +++ b/libavformat/imfdec.c
> >>>>> @@ -580,11 +580,16 @@ static int
> >>>>> set_context_streams_from_tracks(AVFormatContext *s)
> >>>>> return AVERROR(ENOMEM);
> >>>>> }
> >>>>> asset_stream->id = i;
> >>>>> +asset_stream->r_frame_rate =
> >>>>> first_resource_stream->r_frame_rate;
> >>>>> +asset_stream->avg_frame_rate =
> >>>>> first_resource_stream->avg_frame_rate;
> >>>>> +asset_stream->sample_aspect_ratio =
> >>>>> first_resource_stream->sample_aspect_ratio;
> >>>>> ret = avcodec_parameters_copy(asset_stream->codecpar,
> >>>>> first_resource_stream->codecpar);
> >>>>> if (ret < 0) {
> >>>>> av_log(s, AV_LOG_ERROR, "Could not copy stream
> >>>>> parameters\n");
> >>>>> return ret;
> >>>>> }
> >>>>> +av_dict_copy(_stream->metadata,
> >>>>> first_resource_stream->metadata, 0);
> >>>>> +ff_stream_side_data_copy(asset_stream, first_resource_stream);
> >>>>> avpriv_set_pts_info(asset_stream,
> >>>>> first_resource_stream->pts_wrap_bits,
> >>>>> first_resource_stream->time_base.num,
> >>>>
> >>>> Seems to me like one should use ff_stream_encode_params_copy here. Of
> >>>> course, it would have to be renamed and moved if used in a demuxer.
> >>>
> >>> Would copy_stream_props() in concatdec.c need to be refactored as well?
> >>>
> >>
> >> I often wondered about this. The problem with copy_stream_props is that
> >> it is not only called during read_header, but lateron as well, but e.g.
> >> the documentation of AVStream.side_data says that it is populated when
> >> the stream is created and not later.
> >> This issue does of course not exist in your case.
> >
> > ff_stream_encode_params_copy() does not seem to set pts_wrap_bits,
> > i.e. it does not call avpriv_set_pts_info().
> >
>
> The reason for this is that pts_wrap_bits is irrelevant for muxing.
Do you have in mind:
(a) a single av_stream_params_copy(), which copies all parameters
(b) two separate functions av_stream_demux_params_copy() and
av_stream_mux_params_copy(), which copies only relevant parameters?
(c) something else?
In the case of (b), should both be defined now, or only
av_stream_demux_params_copy() be implemented now since avformat/imfdec
would only use av_stream_demux_params_copy()?
I have not seen anyone else chime in.
>
> >>
> >>> Note that, in the case of avformat/imfdec.c, AVStream::id is not
> >>> copied across, so ff_stream_encode_params_copy() would need to be
> >>> followed by asset_stream->id = i;
> >>>
> >>
> >> Yeah, I know.
> >>
> >> - Andreas
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel 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 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] avformat/imfdec: preserve stream information
On Sun, Jul 3, 2022 at 12:15 PM Andreas Rheinhardt
wrote:
>
> Pierre-Anthony Lemieux:
> > On Sun, Jul 3, 2022 at 11:28 AM Andreas Rheinhardt
> > wrote:
> >>
> >> p...@sandflow.com:
> >>> From: Pierre-Anthony Lemieux
> >>>
> >>> As discussed at https://trac.ffmpeg.org/ticket/9818, the IMF demuxer does
> >>> not
> >>> currently preserve stream information such as language in the case of
> >>> audio
> >>> streams. This patch is modeled on copy_stream_props() at
> >>> avformat/concatdec.c.
> >>>
> >>> ---
> >>> libavformat/imfdec.c | 5 +
> >>> 1 file changed, 5 insertions(+)
> >>>
> >>> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> >>> index 71dfb26958..7aa66a06bf 100644
> >>> --- a/libavformat/imfdec.c
> >>> +++ b/libavformat/imfdec.c
> >>> @@ -580,11 +580,16 @@ static int
> >>> set_context_streams_from_tracks(AVFormatContext *s)
> >>> return AVERROR(ENOMEM);
> >>> }
> >>> asset_stream->id = i;
> >>> +asset_stream->r_frame_rate = first_resource_stream->r_frame_rate;
> >>> +asset_stream->avg_frame_rate =
> >>> first_resource_stream->avg_frame_rate;
> >>> +asset_stream->sample_aspect_ratio =
> >>> first_resource_stream->sample_aspect_ratio;
> >>> ret = avcodec_parameters_copy(asset_stream->codecpar,
> >>> first_resource_stream->codecpar);
> >>> if (ret < 0) {
> >>> av_log(s, AV_LOG_ERROR, "Could not copy stream
> >>> parameters\n");
> >>> return ret;
> >>> }
> >>> +av_dict_copy(_stream->metadata,
> >>> first_resource_stream->metadata, 0);
> >>> +ff_stream_side_data_copy(asset_stream, first_resource_stream);
> >>> avpriv_set_pts_info(asset_stream,
> >>> first_resource_stream->pts_wrap_bits,
> >>> first_resource_stream->time_base.num,
> >>
> >> Seems to me like one should use ff_stream_encode_params_copy here. Of
> >> course, it would have to be renamed and moved if used in a demuxer.
> >
> > Would copy_stream_props() in concatdec.c need to be refactored as well?
> >
>
> I often wondered about this. The problem with copy_stream_props is that
> it is not only called during read_header, but lateron as well, but e.g.
> the documentation of AVStream.side_data says that it is populated when
> the stream is created and not later.
> This issue does of course not exist in your case.
ff_stream_encode_params_copy() does not seem to set pts_wrap_bits,
i.e. it does not call avpriv_set_pts_info().
>
> > Note that, in the case of avformat/imfdec.c, AVStream::id is not
> > copied across, so ff_stream_encode_params_copy() would need to be
> > followed by asset_stream->id = i;
> >
>
> Yeah, I know.
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] avformat/imfdec: preserve stream information
On Sun, Jul 3, 2022 at 11:28 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > As discussed at https://trac.ffmpeg.org/ticket/9818, the IMF demuxer does
> > not
> > currently preserve stream information such as language in the case of audio
> > streams. This patch is modeled on copy_stream_props() at
> > avformat/concatdec.c.
> >
> > ---
> > libavformat/imfdec.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> > index 71dfb26958..7aa66a06bf 100644
> > --- a/libavformat/imfdec.c
> > +++ b/libavformat/imfdec.c
> > @@ -580,11 +580,16 @@ static int
> > set_context_streams_from_tracks(AVFormatContext *s)
> > return AVERROR(ENOMEM);
> > }
> > asset_stream->id = i;
> > +asset_stream->r_frame_rate = first_resource_stream->r_frame_rate;
> > +asset_stream->avg_frame_rate =
> > first_resource_stream->avg_frame_rate;
> > +asset_stream->sample_aspect_ratio =
> > first_resource_stream->sample_aspect_ratio;
> > ret = avcodec_parameters_copy(asset_stream->codecpar,
> > first_resource_stream->codecpar);
> > if (ret < 0) {
> > av_log(s, AV_LOG_ERROR, "Could not copy stream parameters\n");
> > return ret;
> > }
> > +av_dict_copy(_stream->metadata,
> > first_resource_stream->metadata, 0);
> > +ff_stream_side_data_copy(asset_stream, first_resource_stream);
> > avpriv_set_pts_info(asset_stream,
> > first_resource_stream->pts_wrap_bits,
> > first_resource_stream->time_base.num,
>
> Seems to me like one should use ff_stream_encode_params_copy here. Of
> course, it would have to be renamed and moved if used in a demuxer.
Would copy_stream_props() in concatdec.c need to be refactored as well?
Note that, in the case of avformat/imfdec.c, AVStream::id is not
copied across, so ff_stream_encode_params_copy() would need to be
followed by asset_stream->id = i;
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 v3 6/6] avfilter/showinfo: refactor to use avutil/uuid
On Tue, May 31, 2022 at 12:10 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > libavfilter/vf_showinfo.c | 17 +
> > 1 file changed, 5 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
> > index 12d39310ef..0d6f2805bb 100644
> > --- a/libavfilter/vf_showinfo.c
> > +++ b/libavfilter/vf_showinfo.c
> > @@ -42,6 +42,7 @@
> > #include "libavutil/mastering_display_metadata.h"
> > #include "libavutil/video_enc_params.h"
> > #include "libavutil/detection_bbox.h"
> > +#include "libavutil/uuid.h"
> >
> > #include "avfilter.h"
> > #include "internal.h"
> > @@ -421,29 +422,21 @@ static void dump_video_enc_params(AVFilterContext
> > *ctx, const AVFrameSideData *s
> >
> > static void dump_sei_unregistered_metadata(AVFilterContext *ctx, const
> > AVFrameSideData *sd)
> > {
> > -const int uuid_size = 16;
> > const uint8_t *user_data = sd->data;
> > int i;
> >
> > -if (sd->size < uuid_size) {
> > +if (sd->size < AV_UUID_LEN) {
> > av_log(ctx, AV_LOG_ERROR, "invalid data(%"SIZE_SPECIFIER" < "
> > - "UUID(%d-bytes))\n", sd->size, uuid_size);
> > + "UUID(%d-bytes))\n", sd->size, AV_UUID_LEN);
> > return;
> > }
> >
> > av_log(ctx, AV_LOG_INFO, "User Data Unregistered:\n");
> > -av_log(ctx, AV_LOG_INFO, "UUID=");
> > -for (i = 0; i < uuid_size; i++) {
> > -av_log(ctx, AV_LOG_INFO, "%02x", user_data[i]);
> > -if (i == 3 || i == 5 || i == 7 || i == 9)
> > -av_log(ctx, AV_LOG_INFO, "-");
> > -}
> > -av_log(ctx, AV_LOG_INFO, "\n");
> > +av_log(ctx, AV_LOG_INFO, "UUID=" AV_PRI_UUID "\n",
> > AV_UUID_ARG(user_data));
> >
> > av_log(ctx, AV_LOG_INFO, "User Data=");
> > -for (; i < sd->size; i++) {
> > +for (i = 16; i < sd->size; i++)
>
> You can (and should) now use a for-loop with variable-declaration (and
> the type should be changed to size_t, as AVFrameSideData is now size_t,
> too).
Will fix. Thanks.
>
> > av_log(ctx, AV_LOG_INFO, "%02x", user_data[i]);
> > -}
> > av_log(ctx, AV_LOG_INFO, "\n");
> > }
> >
>
> ___
> 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 v3 1/6] avutil/uuid: add utility library for manipulating UUIDs as specified in RFC 4122
On Tue, May 31, 2022 at 3:40 AM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Zane van Iperen
> >
> > Addresses review comments including:
> >
> > * simplifying av_uuid_parse_range()
> > * removing avcodec/cbs_sei from this refactoring exercise
> >
> > Co-authored-by: Pierre-Anthony Lemieux
> > Signed-off-by: Zane van Iperen
> > ---
> > libavutil/Makefile | 2 +
> > libavutil/uuid.c | 142 +++
> > libavutil/uuid.h | 147 +
> > 3 files changed, 291 insertions(+)
> > create mode 100644 libavutil/uuid.c
> > create mode 100644 libavutil/uuid.h
> >
> > diff --git a/libavutil/uuid.c b/libavutil/uuid.c
> > new file mode 100644
> > index 00..8943212f30
> > --- /dev/null
> > +++ b/libavutil/uuid.c
> > @@ -0,0 +1,142 @@
> > +/*
> > + * Copyright (c) 2022 Pierre-Anthony Lemieux
> > + *Zane van Iperen
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +
> > +/*
> > + * Copyright (C) 1996, 1997 Theodore Ts'o.
> > + *
> > + * Redistribution and use in source and binary forms, with or without
> > + * modification, are permitted provided that the following conditions
> > + * are met:
> > + * 1. Redistributions of source code must retain the above copyright
> > + *notice, and the entire permission notice in its entirety,
> > + *including the disclaimer of warranties.
> > + * 2. Redistributions in binary form must reproduce the above copyright
> > + *notice, this list of conditions and the following disclaimer in the
> > + *documentation and/or other materials provided with the distribution.
> > + * 3. The name of the author may not be used to endorse or promote
> > + *products derived from this software without specific prior
> > + *written permission.
> > + *
> > + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED
> > + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
> > + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, ALL OF
> > + * WHICH ARE HEREBY DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE
> > + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> > + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT
> > + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
> > + * BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
> > + * LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
> > + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
> > + * USE OF THIS SOFTWARE, EVEN IF NOT ADVISED OF THE POSSIBILITY OF SUCH
> > + * DAMAGE.
> > + */
> > +
> > +/**
> > + * @file
> > + * UUID parsing and serialization utilities.
> > + * The library treat the UUID as an opaque sequence of 16 unsigned bytes,
> > + * i.e. ignoring the internal layout of the UUID, which depends on the type
> > + * of the UUID.
> > + *
> > + * @author Pierre-Anthony Lemieux
> > + * @author Zane van Iperen
> > + */
> > +
> > +#include "uuid.h"
> > +#include "error.h"
> > +#include "avstring.h"
> > +#include
>
> What is this used for?
Nothing as far as I can tell. Left over from now-removed libuuid code.
Will remove.
>
> > +
> > +int av_uuid_parse(const char *in, AVUUID uu)
> > +{
> > +if (strlen(in) != 36)
> > +return AVERROR(EINVAL);
> > +
> > +return av_uuid_parse_range(in, in + 36, uu);
> > +}
> > +
> > +static int xdigit_to_int(char c)
> > +{
> > +c = av_tolower(c);
> > +
> > +if (c >= '
Re: [FFmpeg-devel] [PATCH v2 1/7] avutil/uuid: add utility library for manipulating UUIDs as specified in RFC 4122
On Wed, May 11, 2022 at 8:02 AM Zane van Iperen wrote:
>
>
>
> On 10/5/22 23:18, Andreas Rheinhardt wrote:
>
> >> +int av_uuid_parse_range(const char *in_start, const char *in_end, AVUUID
> >> uu)
> >> +{
> >> +int i;
> >> +const char *cp;
> >> +char buf[3];
> >> +
> >> +if ((in_end - in_start) != 36)
> >> +return -1;
> >> +
> >> +for (i = 0, cp = in_start; i < 36; i++, cp++) {
> >> +if (i == 8 || i == 13 || i == 18 || i == 23) {
> >> +if (*cp == '-')
> >> +continue;
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> +if (!av_isxdigit(*cp))
> >> +return AVERROR(EINVAL);
> >> +}
> >> +
> >> +buf[2] = '\0';
> >> +for (i = 0, cp = in_start; i < 16; i++) {
> >> +if (i == 4 || i == 6 || i == 8 || i == 10)
> >> +cp++;
> >> +
> >> +buf[0] = *cp++;
> >> +buf[1] = *cp++;
> >> +
> >> +errno = 0;
> >> +uu[i] = strtoul(buf, NULL, 16);
> >> +if (errno)
> >> +return AVERROR(errno);
> >
> > How could this ever happen given that you have already checked that the
> > buffer only contains hex digits? And isn't using strtoul a bit overkill
> > anyway? I'd just check and parse this stuff in one loop.
> >
>
> Yeah, good point. It's based off libuuid's, which has some time/clock uuid
> handling
> between the two loops. I'll tidy it up in the next few days... hopefully...
>
> >> +/**
> >> + * @file
> >> + * UUID parsing and serialization utilities.
> >> + * The library treat the UUID as an opaque sequence of 16 unsigned bytes,
> > ^
> > s
>
> Fixed.
>
> >> +/**
> >> + * Parses a string representation of a UUID formatted according to IETF
> >> RFC 4122
> >> + * into an AVUUID. The parsing is case-insensitive. The string must be 37
> >> + * characters long, including the terminating NULL character.
> >
> > NUL, NULL is for pointers.
> >
>
> Changed.
>
> >> +/**
> >> + * Parses a string representation of a UUID formatted according to IETF
> >> RFC 4122
> >> + * into an AVUUID. The parsing is case-insensitive. The string must
> >> consist of
> >> + * 36 characters, i.e. `in_end - in_start == 36`
> >> + *
> >> + * @param[in] in_start Pointer to the first character of the string
> >> representation
> >> + * @param[in] in_end Pointer to the character after the last character
> >> of the
> >> + * string representation. That memory location is
> >> never
> >> + * accessed
> >> + * @param[out] uu AVUUID
> >> + * @return A non-zero value in case of an error.
> >> + */
> >> +int av_uuid_parse_range(const char *in_start, const char *in_end, AVUUID
> >> uu);
> >
> > This sounds like in_end is actually redundant. Does retaining it improve
> > extensibility?
> >
>
> I believe so. The main difference is av_uuid_parse_range() can handle non
> NUL-termiated
> strings. I can just remove the entire last sentence (or change "must" to
> "should").
I have modified the documentation in v3 of the patchset to emphasize
that `in_end - in_start != 36` results in an error.
>
> >> +
> >> +/**
> >> + * Serializes a AVUUID into a string representation according to IETF RFC
> >> 4122.
> >> + * The string is lowercase and always 37 characters long, including the
> >> + * terminating NULL character.
> >> + *
> >> + * @param[in] uu AVUUID
> >> + * @param[out] out Pointer to a array of no less than 37 characters.
> >^
> >n
> >
>
> Fixed.
>
>
> >> +/**
> >> + * Sets a UUID to nil
> >> + *
> >> + * @param[in,out] uu UUID to be set to nil
> >> + */
> >> +void av_uuid_nil_set(AVUUID uu);
> >
> > Why are these three functions not static inline? Exporting them seems
> > like a waste.
> >
>
> No particular reason, it's easy enough to change.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 1/7] avutil/uuid: add utility library for manipulating UUIDs as specified in RFC 4122
On Wed, May 11, 2022 at 8:03 AM Zane van Iperen wrote: > > > > On 11/5/22 21:53, Anton Khirnov wrote: > > Quoting Zane van Iperen (2022-04-24 12:14:03) > >> +void av_uuid_nil_set(AVUUID uu) > > ^^^ > > sounds weird > > > > av_uuid_zero()? > > av_uuid_reset()? > > > > Good point, `av_uuid_zero()` has a nice ring to it. I think we should keep `nil` in the name since the _nil UUID_ has a special meaning in RFC 4122. have proposed av_uuid_nil() in v3 of the patchset. > ___ > 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/jpeg2000: Fast fail if HTJ2K codeblocks are present.
LGTM
On Thu, May 5, 2022 at 11:56 PM caleb wrote:
>
> ---
> libavcodec/jpeg2000.h| 2 ++
> libavcodec/jpeg2000dec.c | 4
> 2 files changed, 6 insertions(+)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index d06313425e..e5ecb4cbf9 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -110,6 +110,8 @@ enum Jpeg2000Quantsty { // quantization style
> #define JPEG2000_CSTY_PREC 0x01 // Precincts defined in coding style
> #define JPEG2000_CSTY_SOP 0x02 // SOP marker present
> #define JPEG2000_CSTY_EPH 0x04 // EPH marker present
> +#define JPEG2000_CTSY_HTJ2K_F 0x40 // Only HT code-blocks (Rec. ITU-T
> T.814 | ISO/IEC 15444-15) are present
> +#define JPEG2000_CTSY_HTJ2K_M 0xC0 // HT code blocks (Rec. ITU-T T.814 |
> ISO/IEC 15444-15) can be present
>
> // Progression orders
> #define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
> level-component-position progression
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 92966b11f5..30f8c878d1 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -521,6 +521,10 @@ static int get_cox(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c)
>
> c->cblk_style = bytestream2_get_byteu(>g);
> if (c->cblk_style != 0) { // cblk style
> +if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
> JPEG2000_CTSY_HTJ2K_F) {
> +av_log(s->avctx, AV_LOG_ERROR, "Support for High throughput JPEG
> 2000 is not yet available\n");
> +return AVERROR_PATCHWELCOME;
> +}
> av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
> bypass\n");
> --
> 2.34.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] avcodec/jpeg2000:fast-fail if HTJ2K codeblocks are present
Hi Caleb,
There is a space missing in the commit message before "fast-fail".
Few minor comments below.
Looks good otherwise -- it works as expected on an MXF file that
contains JPEG 2000 Part 15 code-blocks.
Looking forward to the full implementation!
Best,
-- Pierre
On Tue, Apr 19, 2022 at 1:17 AM caleb wrote:
>
> ---
> This patch adds support for detecting Part 15 codeblocks to JPEG2000
> specified in (Rec. ITU-T T.814 | ISO/IEC 15444-15).
>
> The decoder on detecting Part 15 codeblocks now fails gracefully with a
> AVERROR_PATCHWELCOME return code
>
> libavcodec/jpeg2000.h| 2 ++
> libavcodec/jpeg2000dec.c | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index d06313425e..e5ecb4cbf9 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -110,6 +110,8 @@ enum Jpeg2000Quantsty { // quantization style
> #define JPEG2000_CSTY_PREC 0x01 // Precincts defined in coding style
> #define JPEG2000_CSTY_SOP 0x02 // SOP marker present
> #define JPEG2000_CSTY_EPH 0x04 // EPH marker present
> +#define JPEG2000_CTSY_HTJ2K_F 0x40 // Only HT code-blocks (Rec. ITU-T
> T.814 | ISO/IEC 15444-15) are present
> +#define JPEG2000_CTSY_HTJ2K_M 0xC0 // HT code blocks (Rec. ITU-T T.814 |
> ISO/IEC 15444-15) can be present
>
> // Progression orders
> #define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
> level-component-position progression
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 92966b11f5..ef4a653afe 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -521,6 +521,15 @@ static int get_cox(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c)
>
> c->cblk_style = bytestream2_get_byteu(>g);
> if (c->cblk_style != 0) { // cblk style
> +if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
> JPEG2000_CTSY_HTJ2K_F) {
> +/*
> + * HT code-blocks (Rec. ITU-T T.814 | ISO/IEC 15444-15)
> bit-stream
> + * Not yet supported in ffmpeg, cannot continue.
The comment above can be removed since the av_log and return code are
sufficiently descriptive.
> + */
> +av_log(s->avctx, AV_LOG_FATAL, "Support for High throughput JPEG
> 2000 is not yet available\n");
That should probably be AV_LOG_ERROR.
> +return AVERROR_PATCHWELCOME;
> +}
> +
> av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
> bypass\n");
> --
> 2.34.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".
Re: [FFmpeg-devel] [PATCH v2 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On Sat, Apr 30, 2022 at 12:26 PM Mark Thompson wrote:
>
> On 30/04/2022 18:53, Pierre-Anthony Lemieux wrote:
> > On Sat, Apr 30, 2022 at 10:31 AM Mark Thompson wrote:
> >>
> >> On 24/04/2022 11:14, Zane van Iperen wrote:
> >>> From: Pierre-Anthony Lemieux
> >>>
> >>> ---
> >>>libavcodec/cbs_sei.h | 3 ++-
> >>>libavcodec/vaapi_encode_h264.c | 8
> >>>2 files changed, 6 insertions(+), 5 deletions(-)
> >>>
> >>> diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
> >>> index c7a7a95be0..67c6e6cbbd 100644
> >>> --- a/libavcodec/cbs_sei.h
> >>> +++ b/libavcodec/cbs_sei.h
> >>> @@ -23,6 +23,7 @@
> >>>#include
> >>>
> >>>#include "libavutil/buffer.h"
> >>> +#include "libavutil/uuid.h"
> >>>
> >>>#include "cbs.h"
> >>>#include "sei.h"
> >>> @@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
> >>>} SEIRawUserDataRegistered;
> >>>
> >>>typedef struct SEIRawUserDataUnregistered {
> >>> -uint8_t uuid_iso_iec_11578[16];
> >>> +AVUUID uuid_iso_iec_11578;
> >>>uint8_t *data;
> >>>AVBufferRef *data_ref;
> >>>size_t data_length;
> >>
> >> This feels like a step backwards? The syntax template files are
> >> explicitly relying on this being uint8_t[16], so giving it a different
> >> name is confusing.
> >
> > What/where are the syntax template files?
>
> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/cbs_sei_syntax_template.c#l87>
>
> (It's included twice by cbs_h2645.c for read/write with different macro
> setups.)
Ok. Thanks. Are you concerned that the following line assumes that
uuid_iso_iec_11578 is uint8_t[16] instead of being the opaque AVUUID?
us(8, uuid_iso_iec_11578[i], 0x00, 0xff, 1, i);
Did I get this right? If so, couple of options come to mind:
(a) revert the change
(b) define a macro to access individual bytes of AVUUID, thereby
keeping AVUUID opaque
(c) not handle AVUUID as opaque, but instead always as uint8_t[16]
Maybe additional options exist.
I do not have a definitive opinion. Some folks expressed strong
interest in having a consistent scheme for manipulating UUIDs.
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 5/7] avcodec/cbs_sei: refactor to use avutil/uuid
On Sat, Apr 30, 2022 at 10:31 AM Mark Thompson wrote:
>
> On 24/04/2022 11:14, Zane van Iperen wrote:
> > From: Pierre-Anthony Lemieux
> >
> > ---
> > libavcodec/cbs_sei.h | 3 ++-
> > libavcodec/vaapi_encode_h264.c | 8
> > 2 files changed, 6 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavcodec/cbs_sei.h b/libavcodec/cbs_sei.h
> > index c7a7a95be0..67c6e6cbbd 100644
> > --- a/libavcodec/cbs_sei.h
> > +++ b/libavcodec/cbs_sei.h
> > @@ -23,6 +23,7 @@
> > #include
> >
> > #include "libavutil/buffer.h"
> > +#include "libavutil/uuid.h"
> >
> > #include "cbs.h"
> > #include "sei.h"
> > @@ -41,7 +42,7 @@ typedef struct SEIRawUserDataRegistered {
> > } SEIRawUserDataRegistered;
> >
> > typedef struct SEIRawUserDataUnregistered {
> > -uint8_t uuid_iso_iec_11578[16];
> > +AVUUID uuid_iso_iec_11578;
> > uint8_t *data;
> > AVBufferRef *data_ref;
> > size_t data_length;
>
> This feels like a step backwards? The syntax template files are explicitly
> relying on this being uint8_t[16], so giving it a different name is confusing.
What/where are the syntax template files?
>
> > diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> > index 7a6b54ab6f..b3105d6ccc 100644
> > --- a/libavcodec/vaapi_encode_h264.c
> > +++ b/libavcodec/vaapi_encode_h264.c
> > @@ -25,6 +25,7 @@
> > #include "libavutil/common.h"
> > #include "libavutil/internal.h"
> > #include "libavutil/opt.h"
> > +#include "libavutil/uuid.h"
> >
> > #include "avcodec.h"
> > #include "cbs.h"
> > @@ -43,7 +44,7 @@ enum {
> > };
> >
> > // Random (version 4) ISO 11578 UUID.
> > -static const uint8_t vaapi_encode_h264_sei_identifier_uuid[16] = {
> > +static const AVUUID vaapi_encode_h264_sei_identifier_uuid = {
> > 0x59, 0x94, 0x8b, 0x28, 0x11, 0xec, 0x45, 0xaf,
> > 0x96, 0x75, 0x19, 0xd4, 0x1f, 0xea, 0xa9, 0x4d,
> > };
> > @@ -1089,9 +1090,8 @@ static av_cold int
> > vaapi_encode_h264_configure(AVCodecContext *avctx)
> > const char *driver;
> > int len;
> >
> > -memcpy(priv->sei_identifier.uuid_iso_iec_11578,
> > - vaapi_encode_h264_sei_identifier_uuid,
> > - sizeof(priv->sei_identifier.uuid_iso_iec_11578));
> > +av_uuid_copy(priv->sei_identifier.uuid_iso_iec_11578,
> > + vaapi_encode_h264_sei_identifier_uuid);
> >
> > driver = vaQueryVendorString(ctx->hwctx->display);
> > if (!driver)
>
> This is fair.
>
> - Mark
> ___
> 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/jpeg2000:fast-fail if HTJ2K codeblocks are present
FYI. This is the qualification task for the GSOC project at [1].
[1]
https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022#AddsupportforPart15totheJPEG2000decoder
On Tue, Apr 19, 2022 at 1:17 AM caleb wrote:
>
> ---
> This patch adds support for detecting Part 15 codeblocks to JPEG2000
> specified in (Rec. ITU-T T.814 | ISO/IEC 15444-15).
>
> The decoder on detecting Part 15 codeblocks now fails gracefully with a
> AVERROR_PATCHWELCOME return code
>
> libavcodec/jpeg2000.h| 2 ++
> libavcodec/jpeg2000dec.c | 9 +
> 2 files changed, 11 insertions(+)
>
> diff --git a/libavcodec/jpeg2000.h b/libavcodec/jpeg2000.h
> index d06313425e..e5ecb4cbf9 100644
> --- a/libavcodec/jpeg2000.h
> +++ b/libavcodec/jpeg2000.h
> @@ -110,6 +110,8 @@ enum Jpeg2000Quantsty { // quantization style
> #define JPEG2000_CSTY_PREC 0x01 // Precincts defined in coding style
> #define JPEG2000_CSTY_SOP 0x02 // SOP marker present
> #define JPEG2000_CSTY_EPH 0x04 // EPH marker present
> +#define JPEG2000_CTSY_HTJ2K_F 0x40 // Only HT code-blocks (Rec. ITU-T
> T.814 | ISO/IEC 15444-15) are present
> +#define JPEG2000_CTSY_HTJ2K_M 0xC0 // HT code blocks (Rec. ITU-T T.814 |
> ISO/IEC 15444-15) can be present
>
> // Progression orders
> #define JPEG2000_PGOD_LRCP 0x00 // Layer-resolution
> level-component-position progression
> diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c
> index 92966b11f5..ef4a653afe 100644
> --- a/libavcodec/jpeg2000dec.c
> +++ b/libavcodec/jpeg2000dec.c
> @@ -521,6 +521,15 @@ static int get_cox(Jpeg2000DecoderContext *s,
> Jpeg2000CodingStyle *c)
>
> c->cblk_style = bytestream2_get_byteu(>g);
> if (c->cblk_style != 0) { // cblk style
> +if (c->cblk_style & JPEG2000_CTSY_HTJ2K_M || c->cblk_style &
> JPEG2000_CTSY_HTJ2K_F) {
> +/*
> + * HT code-blocks (Rec. ITU-T T.814 | ISO/IEC 15444-15)
> bit-stream
> + * Not yet supported in ffmpeg, cannot continue.
> + */
> +av_log(s->avctx, AV_LOG_FATAL, "Support for High throughput JPEG
> 2000 is not yet available\n");
> +return AVERROR_PATCHWELCOME;
> +}
> +
> av_log(s->avctx, AV_LOG_WARNING, "extra cblk styles %X\n",
> c->cblk_style);
> if (c->cblk_style & JPEG2000_CBLK_BYPASS)
> av_log(s->avctx, AV_LOG_WARNING, "Selective arithmetic coding
> bypass\n");
> --
> 2.34.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".
Re: [FFmpeg-devel] [PATCH v2 4/7] avutil/mathematics: add av_rescale_interval() function
On Fri, Mar 4, 2022 at 12:40 PM Pierre-Anthony Lemieux
wrote:
>
> On Fri, Mar 4, 2022 at 12:13 PM Andreas Rheinhardt
> wrote:
> >
> > p...@sandflow.com:
> > > From: Pierre-Anthony Lemieux
> > >
> > > Refactors a function used by avformat/concat and avformat/imf.
> > >
> > > ---
> > > libavutil/mathematics.c | 10 ++
> > > libavutil/mathematics.h | 21 +
> > > 2 files changed, 31 insertions(+)
> > >
> > > diff --git a/libavutil/mathematics.c b/libavutil/mathematics.c
> > > index f4e541fa24..2c7f57b950 100644
> > > --- a/libavutil/mathematics.c
> > > +++ b/libavutil/mathematics.c
> > > @@ -212,3 +212,13 @@ int64_t av_add_stable(AVRational ts_tb, int64_t ts,
> > > AVRational inc_tb, int64_t i
> > > return av_sat_add64(av_rescale_q(old + 1, inc_tb, ts_tb), ts -
> > > old_ts);
> > > }
> > > }
> > > +
> > > +void av_rescale_interval(AVRational tb_in, AVRational tb_out,
> > > + int64_t *min_ts, int64_t *ts, int64_t *max_ts)
> > > +{
> > > +*ts = av_rescale_q(*ts, tb_in, tb_out);
> > > +*min_ts = av_rescale_q_rnd(*min_ts, tb_in, tb_out,
> > > + AV_ROUND_UP | AV_ROUND_PASS_MINMAX);
> > > +*max_ts = av_rescale_q_rnd(*max_ts, tb_in, tb_out,
> > > + AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX);
> > > +}
> > > diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
> > > index 64d4137a60..eb8a3f4002 100644
> > > --- a/libavutil/mathematics.h
> > > +++ b/libavutil/mathematics.h
> > > @@ -161,6 +161,27 @@ int64_t av_rescale_q(int64_t a, AVRational bq,
> > > AVRational cq) av_const;
> > > int64_t av_rescale_q_rnd(int64_t a, AVRational bq, AVRational cq,
> > > enum AVRounding rnd) av_const;
> > >
> > > +/**
> > > + * Rescales a timestamp and the endpoints of an interval to which the
> > > temstamp
> > > + * belongs, from a timebase `tb_in` to a timebase `tb_out`.
> > > + *
> > > + * The upper (lower) bound of the output interval is rounded up (down)
> > > such that
> > > + * the output interval always falls within the intput interval. The
> > > timestamp is
> > > + * rounded to the nearest integer and halfway cases away from zero, and
> > > can
> > > + * therefore fall outside of the output interval.
> > > + *
> > > + * Useful to simplify the rescaling of the arguments of
> > > AVInputFormat::read_seek2()
> > > + *
> > > + * @param[in] tb_in Timebase of the input `min_ts`, `ts` and
> > > `max_ts`
> > > + * @param[in] tb_out Timebase of the ouput `min_ts`, `ts` and
> > > `max_ts`
> > > + * @param[in,out] min_ts Lower bound of the interval
> > > + * @param[in,out] ts Timestamp
> > > + * @param[in,out] max_ts Upper bound of the interval
> > > + */
> > > +void av_rescale_interval(AVRational tb_in, AVRational tb_out,
> > > + int64_t *min_ts, int64_t *ts, int64_t *max_ts);
> > > +
> > > +
> > > /**
> > > * Compare two timestamps each in its own time base.
> > > *
> >
> > I don't see why this function should be public at all. It seems very
> > specific to a usecase in lavf.
>
> Ok. Unless someone objects/has a better idea, I cam move it to seek.c
> as ff_rescale_interval() since it is primarily useful (today) with
> seek_file().
Addressed by v3 at
http://ffmpeg.org/pipermail/ffmpeg-devel/2022-March/293795.html
>
> >
> > - Andreas
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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 4/7] avutil/mathematics: add av_rescale_interval() function
On Fri, Mar 4, 2022 at 12:13 PM Andreas Rheinhardt
wrote:
>
> p...@sandflow.com:
> > From: Pierre-Anthony Lemieux
> >
> > Refactors a function used by avformat/concat and avformat/imf.
> >
> > ---
> > libavutil/mathematics.c | 10 ++
> > libavutil/mathematics.h | 21 +
> > 2 files changed, 31 insertions(+)
> >
> > diff --git a/libavutil/mathematics.c b/libavutil/mathematics.c
> > index f4e541fa24..2c7f57b950 100644
> > --- a/libavutil/mathematics.c
> > +++ b/libavutil/mathematics.c
> > @@ -212,3 +212,13 @@ int64_t av_add_stable(AVRational ts_tb, int64_t ts,
> > AVRational inc_tb, int64_t i
> > return av_sat_add64(av_rescale_q(old + 1, inc_tb, ts_tb), ts -
> > old_ts);
> > }
> > }
> > +
> > +void av_rescale_interval(AVRational tb_in, AVRational tb_out,
> > + int64_t *min_ts, int64_t *ts, int64_t *max_ts)
> > +{
> > +*ts = av_rescale_q(*ts, tb_in, tb_out);
> > +*min_ts = av_rescale_q_rnd(*min_ts, tb_in, tb_out,
> > + AV_ROUND_UP | AV_ROUND_PASS_MINMAX);
> > +*max_ts = av_rescale_q_rnd(*max_ts, tb_in, tb_out,
> > + AV_ROUND_DOWN | AV_ROUND_PASS_MINMAX);
> > +}
> > diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
> > index 64d4137a60..eb8a3f4002 100644
> > --- a/libavutil/mathematics.h
> > +++ b/libavutil/mathematics.h
> > @@ -161,6 +161,27 @@ int64_t av_rescale_q(int64_t a, AVRational bq,
> > AVRational cq) av_const;
> > int64_t av_rescale_q_rnd(int64_t a, AVRational bq, AVRational cq,
> > enum AVRounding rnd) av_const;
> >
> > +/**
> > + * Rescales a timestamp and the endpoints of an interval to which the
> > temstamp
> > + * belongs, from a timebase `tb_in` to a timebase `tb_out`.
> > + *
> > + * The upper (lower) bound of the output interval is rounded up (down)
> > such that
> > + * the output interval always falls within the intput interval. The
> > timestamp is
> > + * rounded to the nearest integer and halfway cases away from zero, and can
> > + * therefore fall outside of the output interval.
> > + *
> > + * Useful to simplify the rescaling of the arguments of
> > AVInputFormat::read_seek2()
> > + *
> > + * @param[in] tb_in Timebase of the input `min_ts`, `ts` and `max_ts`
> > + * @param[in] tb_out Timebase of the ouput `min_ts`, `ts` and `max_ts`
> > + * @param[in,out] min_ts Lower bound of the interval
> > + * @param[in,out] ts Timestamp
> > + * @param[in,out] max_ts Upper bound of the interval
> > + */
> > +void av_rescale_interval(AVRational tb_in, AVRational tb_out,
> > + int64_t *min_ts, int64_t *ts, int64_t *max_ts);
> > +
> > +
> > /**
> > * Compare two timestamps each in its own time base.
> > *
>
> I don't see why this function should be public at all. It seems very
> specific to a usecase in lavf.
Ok. Unless someone objects/has a better idea, I cam move it to seek.c
as ff_rescale_interval() since it is primarily useful (today) with
seek_file().
>
> - Andreas
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel 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] Ping Re: [PATCH v2 7/7] avformat/concat: refactor to use av_rescale_interval()
Hi all, Just a quick note to check if additional work is needed on this patchset that has been LGTMed? The patchset is intended to address https://trac.ffmpeg.org/ticket/9648 . Best, -- Pierre On Mon, Feb 21, 2022 at 2:30 AM Nicolas George wrote: > > p...@sandflow.com (12022-02-20): > > From: Pierre-Anthony Lemieux > > > > --- > > libavformat/concatdec.c | 19 +-- > > 1 file changed, 5 insertions(+), 14 deletions(-) > > LGTM. > > Regards, > > -- > Nicolas George ___ 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".
