Re: [FFmpeg-devel] [PATCH] avcodec/qsvdec:flush the buffered data before reinit

[Li, Zhong]

> From: Fu, Linjie
> Sent: Sunday, September 30, 2018 9:01 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie ; Li, Zhong 
> Subject: [PATCH] avcodec/qsvdec:flush the buffered data before reinit
> 
> Flush the buffered data in libmfx before video param reinit in case the
> frames drop.
> 
> Cache the first frame causing the reinit and decode zero-size pkt to flush the
> buffered pkt before reinit. After all the buffered pkts being flushed, resume
> to reinit and decode.
> 
> Fix the issue in ticket #7399.
> 
> Modified in qsvdec_other.c as well.
> 
> Signed-off-by: Linjie Fu 
> Signed-off-by: Zhong  Li 
> ---
>  libavcodec/qsvdec.c   | 12 
>  libavcodec/qsvdec.h   |  2 ++
>  libavcodec/qsvdec_h2645.c | 11 +++  libavcodec/qsvdec_other.c |
> 10 +++---
>  4 files changed, 28 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c index
> 22e7a46a85..ca4500b456 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -372,6 +372,8 @@ static int qsv_decode(AVCodecContext *avctx,
> QSVContext *q,
>  ++q->zero_consume_run;
>  if (q->zero_consume_run > 1)
>  ff_qsv_print_warning(avctx, ret, "A decode call did not
> consume any data");
> +} else if (!*sync && bs.DataOffset) {
> +++q->buffered_count;
>  } else {
>  q->zero_consume_run = 0;
>  }
> @@ -493,6 +495,7 @@ int ff_qsv_process_data(AVCodecContext *avctx,
> QSVContext *q,
>  int dummy_size;
>  int ret;
>  const AVPixFmtDescriptor *desc;
> +AVPacket zero_pkt = {0};
> 
>  if (!q->avctx_internal) {
>  q->avctx_internal = avcodec_alloc_context3(NULL); @@ -527,6
> +530,15 @@ int ff_qsv_process_data(AVCodecContext *avctx, QSVContext
> *q,
> AV_PIX_FMT_NONE };
>  enum AVPixelFormat qsv_format;

Should be better to move zero_pkt here.
The reset LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

[Michael Niedermayer]

On Tue, Oct 09, 2018 at 10:52:58PM +0200, Martin Vignali wrote:
> >
> > porting code and removing code sounds like 2 seperate things,
> > that should not be in the same patch
> >
> 
> Split patch in attach

the split should be
the removal of the code that stays removed
the porting of the remaining code

I understand its easier to drop both and then add one but thats a ugly way
to split the patch. The patch porting the code should show both the code
thats removed as well as the added code. That makes it much clearer what it
does.

thx

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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

[FFmpeg-devel] [PATCH 4/4] avcodec/ilbcdec: Fix multiple integer overflows

[Michael Niedermayer]

Fixes: 
10651/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5202341540659200
Fixes: signed integer overflow: -1707705920 - 1703592888 cannot be represented 
in type 'int'

This tries to follow the webrtc code. For example using cliping and 64 bit as 
in WebRtcSpl_DotProductWithScale()
and not doing so in other places.
I could not find anything in rfc3951 and the reference code inside which would
explain what to do in these corner cases.

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

diff --git a/libavcodec/ilbcdec.c b/libavcodec/ilbcdec.c
index 58044f4ba8..8f234b98e1 100644
--- a/libavcodec/ilbcdec.c
+++ b/libavcodec/ilbcdec.c
@@ -381,7 +381,7 @@ static void get_lsp_poly(int16_t *lsp, int32_t *f)
 tmp = ((high * lsp[k]) * 4) + (((low * lsp[k]) >> 15) * 4);
 
 f[l] += f[l - 2];
-f[l] -= tmp;
+f[l] -= (unsigned)tmp;
 }
 
 f[l] -= lsp[k] * (1 << 10);
@@ -402,16 +402,16 @@ static void lsf2poly(int16_t *a, int16_t *lsf)
 get_lsp_poly([1], f[1]);
 
 for (i = 5; i > 0; i--) {
-f[0][i] += f[0][i - 1];
-f[1][i] -= f[1][i - 1];
+f[0][i] += (unsigned)f[0][i - 1];
+f[1][i] -= (unsigned)f[1][i - 1];
 }
 
 a[0] = 4096;
 for (i = 5; i > 0; i--) {
-tmp = f[0][6 - i] + f[1][6 - i];
+tmp = f[0][6 - i] + (unsigned)f[1][6 - i];
 a[6 - i] = (tmp + 4096) >> 13;
 
-tmp = f[0][6 - i] - f[1][6 - i];
+tmp = f[0][6 - i] - (unsigned)f[1][6 - i];
 a[5 + i] = (tmp + 4096) >> 13;
 }
 }
@@ -508,10 +508,10 @@ static void filter_arfq12(const int16_t *data_in,
 int output = 0, sum = 0;
 
 for (j = coefficients_length - 1; j > 0; j--) {
-sum += coefficients[j] * data_out[i - j];
+sum += (unsigned)(coefficients[j] * data_out[i - j]);
 }
 
-output = coefficients[0] * data_in[i] - sum;
+output = coefficients[0] * data_in[i] - (unsigned)sum;
 output = av_clip(output, -134217728, 134215679);
 
 data_out[i] = (output + 2048) >> 12;
@@ -901,12 +901,12 @@ static int16_t get_size_in_bits(uint32_t n)
 
 static int32_t scale_dot_product(const int16_t *v1, const int16_t *v2, int 
length, int scaling)
 {
-int32_t sum = 0;
+int64_t sum = 0;
 
 for (int i = 0; i < length; i++)
 sum += (v1[i] * v2[i]) >> scaling;
 
-return sum;
+return av_clipl_int32(sum);
 }
 
 static void correlation(int32_t *corr, int32_t *ener, int16_t *buffer,
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/4] avcodec/ilbcdec: Limit indexes in create_augmented_vector()

[Michael Niedermayer]

These limits are based on limiting done in WebRtcIlbcfix_CreateAugmentedVec()
Fixes: out of array accesses
Fixes: 
10652/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5638941487661056
Fixes: 
10655/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5699970020147200

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

diff --git a/libavcodec/ilbcdec.c b/libavcodec/ilbcdec.c
index dc8f961bbc..76ecdf0e18 100644
--- a/libavcodec/ilbcdec.c
+++ b/libavcodec/ilbcdec.c
@@ -631,15 +631,16 @@ static void add_vector_and_shift(int16_t *out, const 
int16_t *in1,
 static void create_augmented_vector(int index, int16_t *buffer, int16_t *cbVec)
 {
 int16_t cbVecTmp[4];
-int16_t ilow = index - 4;
+int interpolation_length = FFMIN(4, index);
+int16_t ilow = index - interpolation_length;
 
 memcpy(cbVec, buffer - index, index * 2);
 
-vector_multiplication([ilow], buffer - index - 4, alpha, 4, 15);
-vector_rmultiplication(cbVecTmp, buffer - 4, [3], 4, 15);
-add_vector_and_shift([ilow], [ilow], cbVecTmp, 4, 0);
+vector_multiplication([ilow], buffer - index - interpolation_length, 
alpha, interpolation_length, 15);
+vector_rmultiplication(cbVecTmp, buffer - interpolation_length, 
[interpolation_length - 1], interpolation_length, 15);
+add_vector_and_shift([ilow], [ilow], cbVecTmp, 
interpolation_length, 0);
 
-memcpy(cbVec + index, buffer - index, (SUBL - index) * sizeof(*cbVec));
+memcpy(cbVec + index, buffer - index, FFMIN(SUBL - index, index) * 
sizeof(*cbVec));
 }
 
 static void get_codebook(int16_t * cbvec,   /* (o) Constructed codebook vector 
*/
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 3/4] avcodec/ilbcdec: Fix multiple invalid left shifts

[Michael Niedermayer]

Fixes: 
10651/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_ILBC_fuzzer-5202341540659200
Fixes: left shift of negative value -512

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

diff --git a/libavcodec/ilbcdec.c b/libavcodec/ilbcdec.c
index 76ecdf0e18..58044f4ba8 100644
--- a/libavcodec/ilbcdec.c
+++ b/libavcodec/ilbcdec.c
@@ -376,15 +376,15 @@ static void get_lsp_poly(int16_t *lsp, int32_t *f)
 
 for (j = i; j > 1; j--, l--) {
 high = f[l - 1] >> 16;
-low = (f[l - 1] - (high << 16)) >> 1;
+low = (f[l - 1] - (high * (1 << 16))) >> 1;
 
-tmp = ((high * lsp[k]) << 2) + (((low * lsp[k]) >> 15) << 2);
+tmp = ((high * lsp[k]) * 4) + (((low * lsp[k]) >> 15) * 4);
 
 f[l] += f[l - 2];
 f[l] -= tmp;
 }
 
-f[l] -= lsp[k] << 10;
+f[l] -= lsp[k] * (1 << 10);
 l += i;
 }
 }
@@ -1269,7 +1269,7 @@ static int xcorr_coeff(int16_t *target, int16_t 
*regressor,
 /* Calculate the total number of (dynamic) right shifts that have
been performed on (cross_corr*cross_corr)/energy
  */
-totscale = energy_scale - (cross_corr_scale << 1);
+totscale = energy_scale - (cross_corr_scale * 2);
 
 /* Calculate the shift difference in order to be able to compare 
the two
(cross_corr*cross_corr)/energy in the same domain
@@ -1322,7 +1322,7 @@ static void hp_output(int16_t *signal, const int16_t *ba, 
int16_t *y,
 tmp = (tmp >> 15);
 tmp += SPL_MUL_16_16(y[0], ba[3]);/* (-a[1])*y[i-1] (high part) */
 tmp += SPL_MUL_16_16(y[2], ba[4]);/* (-a[2])*y[i-2] (high part) */
-tmp = (tmp << 1);
+tmp = (tmp * 2);
 
 tmp += SPL_MUL_16_16(signal[i], ba[0]);   /* b[0]*x[0] */
 tmp += SPL_MUL_16_16(x[0], ba[1]);/* b[1]*x[i-1] */
@@ -1345,11 +1345,11 @@ static void hp_output(int16_t *signal, const int16_t 
*ba, int16_t *y,
 } else if (tmp < -268435456) {
 tmp = INT32_MIN;
 } else {
-tmp = tmp << 3;
+tmp = tmp * 8;
 }
 
 y[0] = tmp >> 16;
-y[1] = (tmp - (y[0] << 16)) >> 1;
+y[1] = (tmp - (y[0] * (1 << 16))) >> 1;
 }
 }
 
-- 
2.19.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

[Banana M.]

> No, you need to set this during init.
> You should also set avctx->delay to the same value.

This value is part of the bitstream, so theoretically can appear in any
packet after the first. Can you confirm it doesn't?

How could it be set on init? You'd need to read the bitstream then rewind?
And what if there are multiple skips in different packets?


> Usually true? Decoders aren't usually true, they're always true.

Usually true as those values are optional yet common, there is an "if"
right below.


> No, this is wrong. Codecs don't need to do this manually, this is done by
> libavcodec/decode.c, based on the packet's AV_PKT_DATA_SKIP_SAMPLES side
> data.

All code with  AV_PKT_DATA_SKIP_SAMPLES I see imply the use of
av_packet_new_side_data and look like it'd need many changes, how should it
be done?


> This is confusing, you should split the patches affecting different
codecs.

XMA and WMAPRO are the same codec with minor configs differences, it seemed
redundant to do 2 patches forcing 2 reviews of the same thing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

[Banana M.]

> Can you confirm that if you break the decoder intentionally, the test
> (still) fails?
>
> Thank you, Carl Eugen

It does. Since file now writes 1 extra packet (as intended) so it'll always
differ SIZE_TOLERANCE at min, so decoder changes will go over than value, I
think.

I tried -frames:a 108 (the original file has 108 packets, but now I output
109) so it wouldn't need SIZE_TOLERANZE, but I couldn't get FATE to use it.

If I manually decode with frames:a 108 and compare old decoder vs new
decode, files are identical.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

[Rostislav Pehlivanov]

On Wed, 10 Oct 2018 at 00:15,  wrote:

> From: bnnm 
>
> Improves trac issue #6722. Fixes truncated WMAPRO/XMA output due to delay
> samples and partially applies bitstream gapless info.
>
> This can be tested with files encoding a small nb_samples (like 400),
> which couldn't output anything due to missing delay at the end.
>
> Applying end_skip and partial delay samples would require some extra
> changes, so files are slightly bigger than what should be.
>

> Signed-off-by: bnnm 
> ---
>  libavcodec/wmaprodec.c | 100
> -
>  tests/fate/wma.mak |   1 +
>  2 files changed, 74 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
> index 9439bfa771..e18e2e438f 100644
> --- a/libavcodec/wmaprodec.c
> +++ b/libavcodec/wmaprodec.c
> @@ -216,9 +216,9 @@ typedef struct WMAProDecodeCtx {
>  GetBitContextgb;///< bitstream reader
> context
>  int  buf_bit_size;  ///< buffer size in
> bits
>  uint8_t  drc_gain;  ///< gain for the DRC
> tool
> -int8_t   skip_frame;///< skip output step
>  int8_t   parsed_all_subframes;  ///< all subframes
> decoded?
>  uint8_t  skip_packets;  ///< packets to skip
> to find next packet in a stream (XMA1/2)
> +int8_t   eof_done;  ///< set when EOF
> reached and extra subframe is written (XMA1/2)
>

>  /* subframe/block decode state */
>  int16_t  subframe_len;  ///< current subframe
> length
> @@ -379,12 +379,6 @@ static av_cold int decode_init(WMAProDecodeCtx *s,
> AVCodecContext *avctx, int nu
>  return AVERROR_PATCHWELCOME;
>  }
>
> -/** frame info */
> -if (avctx->codec_id != AV_CODEC_ID_WMAPRO)
> -s->skip_frame = 0;
> -else
> -s->skip_frame = 1; /* skip first frame */
> -
>  s->packet_loss = 1;
>  s->len_prefix  = (s->decode_flags & 0x40);
>
> @@ -1450,21 +1444,38 @@ static int decode_frame(WMAProDecodeCtx *s,
> AVFrame *frame, int *got_frame_ptr)
>  ff_dlog(s->avctx, "drc_gain %i\n", s->drc_gain);
>  }
>
> -/** no idea what these are for, might be the number of samples
> -that need to be skipped at the beginning or end of a stream */
> +/** read encoder delay/padding (gapless) info */
>  if (get_bits1(gb)) {
> -int av_unused skip;
> +int start_skip, end_skip;
> +
>
> -/** usually true for the first frame */
> +/** usually true for the first frame and equal to 1 frame */
>

Usually true? See below.


 if (get_bits1(gb)) {
> -skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "start skip: %i\n", skip);
> +start_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +start_skip = FFMIN(start_skip, s->samples_per_frame);
> +
> +/* must add for XMA to respect starting skip_samples */
> +s->avctx->internal->skip_samples += start_skip;
>

No, you need to set this during init.
You should also set avctx->delay to the same value.



>  }
>
> -/** sometimes true for the last frame */
> +/** usually true for the last frame and less than 1 frame */


Usually true? Decoders aren't usually true, they're always true.


 if (get_bits1(gb)) {
>
-skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "end skip: %i\n", skip);
> +end_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +end_skip = FFMIN(end_skip, s->samples_per_frame);
> +
> +//TODO fix end_skip (also needs changes in XMA multistream's
> handling)
> +/* for XMA/WMAPRO end_skip may span last frame + final delay
> samples,
> + * so we'd need some counter to (possibly) skip some in this
> frame and
> + * rest after last frame (buf_size 0), so final samples would
> be:
> + * samples_per_frame + delay_samples - start_skip - end_skip
> + * (files with 1 packet are possible so both skips are
> considered).
> + *
> + * WMAPRO 5.1 in XWMA does't do this and audio is padded
> instead,
> + * and min packets is 2 (assumes only 1/2ch need it). */
> +
> +if (s->avctx->codec_id == AV_CODEC_ID_WMAPRO &&
> s->nb_channels > 2) {
> +frame->nb_samples = s->samples_per_frame - end_skip;
> +}
>

No, this is wrong. Codecs don't need to do this manually, this is done by
libavcodec/decode.c, based on the packet's AV_PKT_DATA_SKIP_SAMPLES side
data.


 }
>
>  }
> @@ -1500,13 +1511,9 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame
> *frame, int *got_frame_ptr)
> s->samples_per_frame * sizeof(*s->channel[i].out) >> 1);
>  }

Re: [FFmpeg-devel] [PATCH 0/6] Improvements for EBU R128 plugin (third round)

[Paul B Mahol]

On 10/10/18, Paul B Mahol  wrote:
> On 10/10/18, Daniel Molkentin  wrote:
>> On 09.10.2018 14:32, Daniel Molkentin wrote:
>>> Changes over second round:
>>>
>>>  - gauge option: Add 'm' and 's' as alias parameter for
>>>momentary and short-term
>>>  - fix spelling error in documentation
>>>  - remove "mabsolute" documentation which was added to the range
>>>patch by accident
>>>  - fixed ranges for parameters
>>>  - bumped micro version for libavfilter
>> Is there anything left to do until this can go in?
>
> Give me some time to apply it.
>

Pushed, with minor fix.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified

[Marc-Antoine ARNAUD]

I have updated the patch with our discussion.
It took information only from the codec context.

Marc-Antoine

Le mer. 10 oct. 2018 à 11:36, Paul B Mahol  a écrit :

> On 10/10/18, Marc-Antoine ARNAUD  wrote:
> > For me it's the only codec who use picture colorspace as source.
> > All others uses only the CodecContext.
> > I don't know the exact reason, but I suppose it can be easiest to manage
> > output colorspace during merge of video, as a video can have only one
> > "static" video colorspace.
> >
> > So for me it made sense to keep that patch. Maybe with removing the
> `else`
> > to don't take colorspace from pictures as other codecs can do.
>
> That seems reasonable. What other people think?
>
> >
> > Marc-Antoine
> >
> > Le ven. 5 oct. 2018 `a 10:15, Paul B Mahol  a ecrit :
> >
> >> On 10/5/18, Marc-Antoine ARNAUD  wrote:
> >> > In our case we have some files with bad colorspaces (in HD but with
> >> > bt601
> >> > colorspace).
> >> > So we use -colorspace, -color_trc, -color_primaries to force the
> output
> >> > colorspace.
> >> >
> >> > We keep compatibility with "old command line", we get source
> colorspace
> >> if
> >> > nothing is mentionned.
> >> > It work like that for Mpeg2video codec, so we expect to have the same
> >> here.
> >>
> >> Correct patch should be one that changes frame properties, otherwise
> >> every encoder that uses these properties needs to be updated with extra
> >> lines to maintain.
> >>
> >> >
> >> > Marc-Antoine
> >> >
> >> >
> >> > Le jeu. 4 oct. 2018 `a 18:36, Paul B Mahol  a
> ecrit :
> >> >
> >> >> On 10/4/18, Marc-Antoine ARNAUD 
> wrote:
> >> >> >
> >> >> >
> >> >>
> >> >> Why?
> >> >>
> >> >> IIRC this patch is not needed.
> >> >> ___
> >> >> ffmpeg-devel mailing list
> >> >> ffmpeg-devel@ffmpeg.org
> >> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >>
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> >
> > --
> > *Marc-Antoine*
> > |e:arnaud.marcanto...@gmail.com
> > |tel: 06-84-71-84-45 <06%2084%2071%2084%2045>
> > | ohloh: http://bit.ly/1iwtlsU
> > [image: LinkedIn]
> > <
> http://s.wisestamp.com/links?url=https%3A%2F%2Fwww.linkedin.com%2Fpub%2Fmarc-antoine-arnaud%2Fb%2F7b8%2F2a3=YXJuYXVkLm1hcmNhbnRvaW5lQGdtYWlsLmNvbQ%3D%3D
> >
> > [image:
> > Google Plus]
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


0001-prores_ks-use-CodecContext-for-color-information.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avcodec/prores aw improvment

[Martin Vignali]

Le mer. 10 oct. 2018 à 11:52, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :

> Great patches ;-)
> I have submit a patch too, regarding colospace in prores:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235034.html
> You have also in your patch 2, the same purpose (take colorspace from
> picture), do you have any objection to take it from the CodecContext as it
> works like that in others codecs ?
>
> Thanks,
>
>
No strong opinion about how to manage the colorspace property for prores

But on a Mov Prores file, you can have a colorspace info in the muxer side
(moov atom)
and a colorspace information on each frame (not always the same in each
frame of a file)
(same thing, for interlacing)

Is not very convenient to have these kind of information at two place of a
file
and create various problem, because software doesn't manage these info in
the same way.

I'm not enough familiar, with ffmpeg code, to choose the best option
in order to correctly set or use existing colorspace information :
- in simple decoding/encoding
- when using video filtering / pixel conversion

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

[FFmpeg-devel] [PATCH] avcodec: add Amuse Graphics decoder

[Paul B Mahol]

This work is partially sponsored by VideoLAN.

Signed-off-by: Paul B Mahol 
---

The AGM3 variant decodes with some artifacts.

---
 libavcodec/Makefile |   1 +
 libavcodec/agm.c| 692 
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavformat/riff.c  |   2 +
 6 files changed, 704 insertions(+)
 create mode 100644 libavcodec/agm.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ce766aa466..3a396c2d85 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -173,6 +173,7 @@ OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o 
ac3dec_data.o ac3.o kbd
 OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o ac3enc.o ac3tab.o \
   ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o 
ac3.o
+OBJS-$(CONFIG_AGM_DECODER) += agm.o
 OBJS-$(CONFIG_AIC_DECODER) += aic.o
 OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
 OBJS-$(CONFIG_ALAC_ENCODER)+= alacenc.o alac_data.o
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
new file mode 100644
index 00..424b906eac
--- /dev/null
+++ b/libavcodec/agm.c
@@ -0,0 +1,692 @@
+/*
+ * Amuse Graphics Movie decoder
+ *
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+
+#define BITSTREAM_READER_LE
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "copy_block.h"
+#include "get_bits.h"
+#include "idctdsp.h"
+#include "internal.h"
+
+static const uint8_t unscaled_luma[64] = {
+16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19,
+26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56,
+14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56,
+68,109,103, 77, 24, 35, 55, 64, 81,104,113, 92,
+49, 64, 78, 87,103,121,120,101, 72, 92, 95, 98,
+112,100,103,99
+};
+
+static const uint8_t unscaled_chroma[64] = {
+17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66,
+99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99,
+47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99
+};
+
+typedef struct MotionVector {
+int16_t x, y;
+} MotionVector;
+
+typedef struct AGMContext {
+const AVClass  *class;
+AVCodecContext *avctx;
+GetBitContext   gb;
+GetByteContext  gbyte;
+
+int key_frame;
+int bitstream_size;
+int compression;
+int blocks_w;
+int blocks_h;
+int size[3];
+int plus;
+int flags;
+
+MotionVector *mvectors;
+int   mvectors_size;
+
+AVFrame *prev_frame;
+
+int luma_quant_matrix[64];
+int chroma_quant_matrix[64];
+
+ScanTable scantable;
+DECLARE_ALIGNED(32, int16_t, block)[64];
+IDCTDSPContext idsp;
+} AGMContext;
+
+static int read_code2(GetBitContext *gb, int *oskip, int *level)
+{
+int max, len = 0, skip = 0;
+
+if (show_bits(gb, 2)) {
+switch (show_bits(gb, 4)) {
+case 1:
+case 9:
+len = 1;
+skip = 3;
+break;
+case 2:
+len = 3;
+skip = 4;
+break;
+case 3:
+len = 7;
+skip = 4;
+break;
+case 5:
+case 0xD:
+len = 2;
+skip = 3;
+break;
+case 6:
+len = 4;
+skip = 4;
+break;
+case 7:
+len = 8;
+skip = 4;
+break;
+case 0xA:
+len = 5;
+skip = 4;
+break;
+case 0xB:
+len = 9;
+skip = 4;
+break;
+case 0xE:
+len = 6;
+skip = 4;
+break;
+case 0xF:
+len = ((show_bits(gb, 5) & 0x10) | 0xA0) >> 4;
+skip = 5;
+break;
+default:
+return AVERROR_INVALIDDATA;
+}
+skip_bits(gb, skip);
+*level = get_bits(gb, len);
+*oskip = 0;
+max = 1 << (len - 1);
+if (*level < max)
+*level = -(max + 

[FFmpeg-devel] [PATCH] avformat/dashenc: Dont ignore the codec tag from codec parameters

[Jeyapal, Karthick]

My git send-email is not working. Hence attaching the patch.

Regards,
Karthick


0001-avformat-dashenc-Dont-ignore-the-codec-tag-from-code.patch
Description: 0001-avformat-dashenc-Dont-ignore-the-codec-tag-from-code.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] LICENSE: add libdavs2 and libxavs2 into compatible libraries section

[hwren]

Signed-off-by: hwren 
---
 LICENSE.md | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/LICENSE.md b/LICENSE.md
index ba65b05..1340ee4 100644
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -83,11 +83,13 @@ affect the licensing of binaries resulting from the 
combination.
 The following libraries are under GPL:
 - frei0r
 - libcdio
+- libdavs2
 - librubberband
 - libvidstab
 - libx264
 - libx265
 - libxavs
+- libxavs2
 - libxvid
 
 When combining them with FFmpeg, FFmpeg needs to be licensed as GPL as well by
-- 
2.7.4

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

Re: [FFmpeg-devel] avcodec/prores aw improvment

[Marc-Antoine ARNAUD]

Great patches ;-)
I have submit a patch too, regarding colospace in prores:
http://ffmpeg.org/pipermail/ffmpeg-devel/2018-October/235034.html
You have also in your patch 2, the same purpose (take colorspace from
picture), do you have any objection to take it from the CodecContext as it
works like that in others codecs ?

Thanks,

Le lun. 8 oct. 2018 à 20:32, Carl Eugen Hoyos  a écrit :

> 2018-10-08 16:12 GMT+02:00, Martin Vignali :
>
> > Resend previous patch (from July)
>
> I didn't test but the patchset looks very useful to me, thank you!
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


-- 
*Marc-Antoine*
|e:arnaud.marcanto...@gmail.com
|tel: 06-84-71-84-45
| ohloh: http://bit.ly/1iwtlsU
[image: LinkedIn]

[image:
Google Plus]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified

[Paul B Mahol]

On 10/10/18, Marc-Antoine ARNAUD  wrote:
> For me it's the only codec who use picture colorspace as source.
> All others uses only the CodecContext.
> I don't know the exact reason, but I suppose it can be easiest to manage
> output colorspace during merge of video, as a video can have only one
> "static" video colorspace.
>
> So for me it made sense to keep that patch. Maybe with removing the `else`
> to don't take colorspace from pictures as other codecs can do.

That seems reasonable. What other people think?

>
> Marc-Antoine
>
> Le ven. 5 oct. 2018 `a 10:15, Paul B Mahol  a ecrit :
>
>> On 10/5/18, Marc-Antoine ARNAUD  wrote:
>> > In our case we have some files with bad colorspaces (in HD but with
>> > bt601
>> > colorspace).
>> > So we use -colorspace, -color_trc, -color_primaries to force the output
>> > colorspace.
>> >
>> > We keep compatibility with "old command line", we get source colorspace
>> if
>> > nothing is mentionned.
>> > It work like that for Mpeg2video codec, so we expect to have the same
>> here.
>>
>> Correct patch should be one that changes frame properties, otherwise
>> every encoder that uses these properties needs to be updated with extra
>> lines to maintain.
>>
>> >
>> > Marc-Antoine
>> >
>> >
>> > Le jeu. 4 oct. 2018 `a 18:36, Paul B Mahol  a ecrit :
>> >
>> >> On 10/4/18, Marc-Antoine ARNAUD  wrote:
>> >> >
>> >> >
>> >>
>> >> Why?
>> >>
>> >> IIRC this patch is not needed.
>> >> ___
>> >> ffmpeg-devel mailing list
>> >> ffmpeg-devel@ffmpeg.org
>> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >>
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
> --
> *Marc-Antoine*
> |e:arnaud.marcanto...@gmail.com
> |tel: 06-84-71-84-45
> | ohloh: http://bit.ly/1iwtlsU
> [image: LinkedIn]
> 
> [image:
> Google Plus]
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified

[Marc-Antoine ARNAUD]

For me it's the only codec who use picture colorspace as source.
All others uses only the CodecContext.
I don't know the exact reason, but I suppose it can be easiest to manage
output colorspace during merge of video, as a video can have only one
"static" video colorspace.

So for me it made sense to keep that patch. Maybe with removing the `else`
to don't take colorspace from pictures as other codecs can do.

Marc-Antoine

Le ven. 5 oct. 2018 à 10:15, Paul B Mahol  a écrit :

> On 10/5/18, Marc-Antoine ARNAUD  wrote:
> > In our case we have some files with bad colorspaces (in HD but with bt601
> > colorspace).
> > So we use -colorspace, -color_trc, -color_primaries to force the output
> > colorspace.
> >
> > We keep compatibility with "old command line", we get source colorspace
> if
> > nothing is mentionned.
> > It work like that for Mpeg2video codec, so we expect to have the same
> here.
>
> Correct patch should be one that changes frame properties, otherwise
> every encoder that uses these properties needs to be updated with extra
> lines to maintain.
>
> >
> > Marc-Antoine
> >
> >
> > Le jeu. 4 oct. 2018 `a 18:36, Paul B Mahol  a ecrit :
> >
> >> On 10/4/18, Marc-Antoine ARNAUD  wrote:
> >> >
> >> >
> >>
> >> Why?
> >>
> >> IIRC this patch is not needed.
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


-- 
*Marc-Antoine*
|e:arnaud.marcanto...@gmail.com
|tel: 06-84-71-84-45
| ohloh: http://bit.ly/1iwtlsU
[image: LinkedIn]

[image:
Google Plus]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] Improvements for EBU R128 plugin (third round)

[Paul B Mahol]

On 10/10/18, Daniel Molkentin  wrote:
> On 09.10.2018 14:32, Daniel Molkentin wrote:
>> Changes over second round:
>>
>>  - gauge option: Add 'm' and 's' as alias parameter for
>>momentary and short-term
>>  - fix spelling error in documentation
>>  - remove "mabsolute" documentation which was added to the range
>>patch by accident
>>  - fixed ranges for parameters
>>  - bumped micro version for libavfilter
> Is there anything left to do until this can go in?

Give me some time to apply it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel