Re: [libav-devel] [kinda PATCH] imc: support mode 1
On 07/11/2013 07:07 AM, Kostya Shishkov wrote:
---
I don't have samples for it so it's rather theoretical.
---
libavcodec/imc.c | 151
--
1 file changed, 102 insertions(+), 49 deletions(-)
This
+for (i = 0; i BANDS; i++) {
+chctx-sumLenArr[i] = 0;
+chctx-skipFlagRaw[i] = 0;
+for (j = band_tab[i]; j band_tab[i + 1]; j++)
+chctx-sumLenArr[i] += chctx-CWlengthT[j];
+if (chctx-bandFlagsBuf[i])
+if band_tab[i + 1] - band_tab[i]) * 1.5)
chctx-sumLenArr[i]) (chctx-sumLenArr[i] 0))
+chctx-skipFlagRaw[i] = 1;
+}
-imc_get_skip_coeff(q, chctx);
+imc_get_skip_coeff(q, chctx);
-for (i = 0; i BANDS; i++) {
-chctx-flcoeffs6[i] = chctx-flcoeffs1[i];
-/* band has flag set and at least one coded coefficient */
-if (chctx-bandFlagsBuf[i] (band_tab[i + 1] - band_tab[i]) !=
chctx-skipFlagCount[i]) {
-chctx-flcoeffs6[i] *= q-sqrt_tab[ band_tab[i + 1] -
band_tab[i]] /
- q-sqrt_tab[(band_tab[i + 1] -
band_tab[i] - chctx-skipFlagCount[i])];
+for (i = 0; i BANDS; i++) {
+chctx-flcoeffs6[i] = chctx-flcoeffs1[i];
+/* band has flag set and at least one coded coefficient */
+if (chctx-bandFlagsBuf[i] (band_tab[i + 1] - band_tab[i]) !=
chctx-skipFlagCount[i]) {
+chctx-flcoeffs6[i] *= q-sqrt_tab[ band_tab[i + 1] -
band_tab[i]] /
+ q-sqrt_tab[(band_tab[i + 1] -
band_tab[i] - chctx-skipFlagCount[i])];
+}
}
-}
-/* calculate bits left, bits needed and adjust bit allocation */
-bits = summer = 0;
+/* calculate bits left, bits needed and adjust bit allocation */
+bits = summer = 0;
-for (i = 0; i BANDS; i++) {
-if (chctx-bandFlagsBuf[i]) {
-for (j = band_tab[i]; j band_tab[i + 1]; j++) {
-if (chctx-skipFlags[j]) {
-summer += chctx-CWlengthT[j];
-chctx-CWlengthT[j] = 0;
+for (i = 0; i BANDS; i++) {
+if (chctx-bandFlagsBuf[i]) {
+for (j = band_tab[i]; j band_tab[i + 1]; j++) {
+if (chctx-skipFlags[j]) {
+summer += chctx-CWlengthT[j];
+chctx-CWlengthT[j] = 0;
+}
}
+bits += chctx-skipFlagBits[i];
+summer -= chctx-skipFlagBits[i];
}
-bits += chctx-skipFlagBits[i];
-summer -= chctx-skipFlagBits[i];
}
+imc_adjust_bit_allocation(q, chctx, summer);
might be moved in a separate function. Beside that doesn't look wrong,
assuming your theory matches reality =)
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] ac3dec: Increment channel pointers only once per channel
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-sta...@libav.org
---
libavcodec/ac3dec.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index abfd380..01da328 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1393,10 +1393,10 @@ static int ac3_decode_frame(AVCodecContext * avctx,
void *data,
if (err)
for (ch = 0; ch s-out_channels; ch++)
memcpy(s-outptr[channel_map[ch]], output[ch], 1024);
-for (ch = 0; ch s-out_channels; ch++) {
+for (ch = 0; ch s-out_channels; ch++)
output[ch] = s-outptr[channel_map[ch]];
-s-outptr[channel_map[ch]] += AC3_BLOCK_SIZE;
-}
+for (ch = 0; ch s-channels; ch++)
+s-outptr[ch] += AC3_BLOCK_SIZE;
}
/* keep last block for error concealment in next frame */
--
1.7.10.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] ac3dec: Consistently use AC3_BLOCK_SIZE and sizeof
---
This makes the code slightly more understandable to newcomers,
at least to me.
---
libavcodec/ac3dec.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index 01da328..fdaa4cb 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1370,7 +1370,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
avctx-audio_service_type = AV_AUDIO_SERVICE_TYPE_KARAOKE;
/* get output buffer */
-frame-nb_samples = s-num_blocks * 256;
+frame-nb_samples = s-num_blocks * AC3_BLOCK_SIZE;
if ((ret = ff_get_buffer(avctx, frame, 0)) 0) {
av_log(avctx, AV_LOG_ERROR, get_buffer() failed\n);
return ret;
@@ -1392,7 +1392,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
}
if (err)
for (ch = 0; ch s-out_channels; ch++)
-memcpy(s-outptr[channel_map[ch]], output[ch], 1024);
+memcpy(s-outptr[channel_map[ch]], output[ch], sizeof(*output)
* AC3_BLOCK_SIZE);
for (ch = 0; ch s-out_channels; ch++)
output[ch] = s-outptr[channel_map[ch]];
for (ch = 0; ch s-channels; ch++)
@@ -1401,7 +1401,7 @@ static int ac3_decode_frame(AVCodecContext * avctx, void
*data,
/* keep last block for error concealment in next frame */
for (ch = 0; ch s-out_channels; ch++)
-memcpy(s-output[ch], output[ch], 1024);
+memcpy(s-output[ch], output[ch], sizeof(*output) * AC3_BLOCK_SIZE);
*got_frame_ptr = 1;
--
1.7.10.4
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ac3dec: Increment channel pointers only once per channel
On 07/11/2013 03:36 PM, Martin Storsjö wrote:
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-sta...@libav.org
---
libavcodec/ac3dec.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index abfd380..01da328 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1393,10 +1393,10 @@ static int ac3_decode_frame(AVCodecContext * avctx,
void *data,
if (err)
for (ch = 0; ch s-out_channels; ch++)
memcpy(s-outptr[channel_map[ch]], output[ch], 1024);
-for (ch = 0; ch s-out_channels; ch++) {
+for (ch = 0; ch s-out_channels; ch++)
output[ch] = s-outptr[channel_map[ch]];
-s-outptr[channel_map[ch]] += AC3_BLOCK_SIZE;
-}
+for (ch = 0; ch s-channels; ch++)
+s-outptr[ch] += AC3_BLOCK_SIZE;
}
If our samples are fine with the change, looks great.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ac3dec: Consistently use AC3_BLOCK_SIZE and sizeof
On 07/11/2013 03:42 PM, Martin Storsjö wrote: --- This makes the code slightly more understandable to newcomers, at least to me. --- libavcodec/ac3dec.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) Agreed. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] ac3dec: Increment channel pointers only once per channel
On Thu, 11 Jul 2013, Luca Barbato wrote:
On 07/11/2013 03:36 PM, Martin Storsjö wrote:
If the channel mapping map multiple output channels to one
input channel, we should only increment the actual pointer once.
Cc: libav-sta...@libav.org
---
libavcodec/ac3dec.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
index abfd380..01da328 100644
--- a/libavcodec/ac3dec.c
+++ b/libavcodec/ac3dec.c
@@ -1393,10 +1393,10 @@ static int ac3_decode_frame(AVCodecContext * avctx,
void *data,
if (err)
for (ch = 0; ch s-out_channels; ch++)
memcpy(s-outptr[channel_map[ch]], output[ch], 1024);
-for (ch = 0; ch s-out_channels; ch++) {
+for (ch = 0; ch s-out_channels; ch++)
output[ch] = s-outptr[channel_map[ch]];
-s-outptr[channel_map[ch]] += AC3_BLOCK_SIZE;
-}
+for (ch = 0; ch s-channels; ch++)
+s-outptr[ch] += AC3_BLOCK_SIZE;
}
If our samples are fine with the change, looks great.
Yes, this passes fate.
// Martin___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] configure: Check for support for labels in the inline assembly
Use this for enabling the ppc timer.h implementation only on assemblers that support labels in the inline assembly. --- configure |3 +++ libavutil/ppc/timer.h |6 ++ 2 files changed, 9 insertions(+) diff --git a/configure b/configure index e1edbe6..0e6b450 100755 --- a/configure +++ b/configure @@ -1294,6 +1294,7 @@ HAVE_LIST= ibm_asm inet_aton io_h +inline_asm_labels isatty jack_port_get_latency_range ldbrx @@ -3405,6 +3406,8 @@ unsigned int endian = 'B' 24 | 'I' 16 | 'G' 8 | 'E'; EOF od -t x1 $TMPO | grep -q '42 *49 *47 *45' enable bigendian +check_inline_asm inline_asm_labels '1:\n' + if enabled alpha; then check_cflags -mieee diff --git a/libavutil/ppc/timer.h b/libavutil/ppc/timer.h index 0981d0c..8d08d28 100644 --- a/libavutil/ppc/timer.h +++ b/libavutil/ppc/timer.h @@ -23,6 +23,10 @@ #include stdint.h +#include config.h + +#if HAVE_INLINE_ASM_LABELS + #define AV_READ_TIME read_time static inline uint64_t read_time(void) @@ -44,4 +48,6 @@ static inline uint64_t read_time(void) return (((uint64_t)tbu)32) | (uint64_t)tbl; } +#endif /* HAVE_INLINE_ASM_LABELS */ + #endif /* AVUTIL_PPC_TIMER_H */ -- 1.7.9.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Check for support for labels in the inline assembly
Check for support of ..? On 2013-07-11 16:23, Martin Storsjö wrote: --- a/configure +++ b/configure @@ -3405,6 +3406,8 @@ unsigned int endian = 'B' 24 | 'I' 16 | 'G' 8 | 'E'; EOF od -t x1 $TMPO | grep -q '42 *49 *47 *45' enable bigendian +check_inline_asm inline_asm_labels '1:\n' + if enabled alpha; then check_cflags -mieee I guess this is more general than just AIX PPC, but AIX PPC is the only affected platform AFAIU. I'm somewhat undecided if we shouldn't restrict this to PPC then. Patch looks good otherwise and is probably OK as-is. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Check for support for labels in the inline assembly
On Thu, 11 Jul 2013, Diego Biurrun wrote: Check for support of ..? I'd say 'support for' is just as correct, so I'm keeping it like this. (I also checked a few dictionaries and didn't found anything telling me otherwise.) On 2013-07-11 16:23, Martin Storsjö wrote: --- a/configure +++ b/configure @@ -3405,6 +3406,8 @@ unsigned int endian = 'B' 24 | 'I' 16 | 'G' 8 | 'E'; EOF od -t x1 $TMPO | grep -q '42 *49 *47 *45' enable bigendian +check_inline_asm inline_asm_labels '1:\n' + if enabled alpha; then check_cflags -mieee I guess this is more general than just AIX PPC, but AIX PPC is the only affected platform AFAIU. I'm somewhat undecided if we shouldn't restrict this to PPC then. Well, labels in inline assembly is something that is supported on most/all platforms that gas/gcc supports, afaik. And if we have the HAVE_INLINE_ASM_LABELS item, it would feel weird to have it set to 0 on most platforms except PPC. So I'd rather keep the check generic. Would there be any point to putting this behind a enabled inline_asm ...? I don't think doing this check would hurt even if the compiler doesn't support inline asm. (It doesn't hurt for MSVC.) Patch looks good otherwise and is probably OK as-is. Ok, good. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] configure: Check for support for labels in the inline assembly
On 2013-07-11 17:24, Martin Storsjö wrote: On Thu, 11 Jul 2013, Diego Biurrun wrote: On 2013-07-11 16:23, Martin Storsjö wrote: --- a/configure +++ b/configure @@ -3405,6 +3406,8 @@ unsigned int endian = 'B' 24 | 'I' 16 | 'G' 8 | 'E'; EOF od -t x1 $TMPO | grep -q '42 *49 *47 *45' enable bigendian +check_inline_asm inline_asm_labels '1:\n' + if enabled alpha; then check_cflags -mieee I guess this is more general than just AIX PPC, but AIX PPC is the only affected platform AFAIU. I'm somewhat undecided if we shouldn't restrict this to PPC then. Well, labels in inline assembly is something that is supported on most/all platforms that gas/gcc supports, afaik. And if we have the HAVE_INLINE_ASM_LABELS item, it would feel weird to have it set to 0 on most platforms except PPC. So I'd rather keep the check generic. Fine. Would there be any point to putting this behind a enabled inline_asm ...? I don't think doing this check would hurt even if the compiler doesn't support inline asm. (It doesn't hurt for MSVC.) It does not, except for the wasted cycles. Feel free to push whenever. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] Invitation to VideoLAN Dev Days 2013
My fellow geeks and friends, We would like to invite you to join us for the VideoLAN Dev Days 2013 This technical conference about open source multimedia, will see developers from VLC, libav, FFmpeg, x264, Phonon, DVBlast, PulseAudio, KDE, Gnome, Xiph, handbrake, tomahawk and other projects gather to discuss about open source development of multimedia projects. It will be held in Paris, France, on August 31st (saturday) and September 1st (sunday) 2013. The schedule includes technical talks and presentation, meetings and dev/BoF rooms to discuss about multimedia. A contrario from previous years, the day before the event, Friday 30th, a special optional day in the Asterix amusement park, will be held for our community to bound together. Also, FOMS will not be held together to VDD, which will likely decrease the size of the event. As last years, VideoLAN will pay travel, hotels, food and Asterix park to active contributors to an Open Source project that do not have a corporate sponsorship. If you read this email, please take your flights to Paris as soon as possible. If you have a doubt about your sponsorship for VideoLAN, please ask on IRC or private mail. Please send this email to other multimedia folks, so that this event will be a success! We are actively seeking for talks! And for sponsors! More information on: http://www.videolan.org/videolan/events/vdd13/ Mandatory registration: http://goo.gl/mUEER Hoping to see all of you soon, JB, for VideoLAN -- Jean-Baptiste Kempf http://www.jbkempf.com/ - +33 672 704 734 Sent from my Electronic Device ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Invitation to VideoLAN Dev Days 2013
On 2013-07-11 18:06, Jean-Baptiste Kempf wrote: My fellow geeks and friends, We would like to invite you to join us for the VideoLAN Dev Days 2013 Yay, looking forward to it! Thanks for the invitation! Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] dca: Report the current limits in the downmixing capabilities
On Wed, 10 Jul 2013, Luca Barbato wrote:
Reported-by: Mateusz j00ru Jurczyk and Gynvael Coldwind
CC: libav-sta...@libav.org
---
libavcodec/dcadec.c | 6 ++
1 file changed, 6 insertions(+)
Perhaps s/Report/Respect/ in the commit subject?
diff --git a/libavcodec/dcadec.c b/libavcodec/dcadec.c
index de24e4e..9b00d30 100644
--- a/libavcodec/dcadec.c
+++ b/libavcodec/dcadec.c
@@ -807,6 +807,12 @@ static int dca_subframe_header(DCAContext *s, int
base_channel, int block_index)
Invalid channel mode %d\n, am);
return AVERROR_INVALIDDATA;
}
+if (s-prim_channels FF_ARRAY_ELEMS(dca_default_coeffs[0])) {
+avpriv_request_sample(s-avctx, Downmixing %d channels,
+ s-prim_channels);
+return AVERROR_PATCHWELCOME;
+}
+
for (j = base_channel; j s-prim_channels; j++) {
s-downmix_coef[j][0] = dca_default_coeffs[am][j][0];
s-downmix_coef[j][1] = dca_default_coeffs[am][j][1];
--
1.8.2.1
Looks good to me although I'm not familiar with the decoder.
// Martin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] build: Skip FATE dependency check when making certain targets
On Tue, 28 May 2013, Diego Biurrun wrote: On 2013-05-27 00:18, Martin Storsjö wrote: On Mon, 27 May 2013, Martin Storsjö wrote: From: Diego Biurrun di...@biurrun.de During each make run, the build system checks that any specified dependencies do actually exist, to prevent typos and other errors from fouling up correct dependency settings. However, it also causes make to trip up when new components have been added to the code, but not yet registered in the build system by configure. A manual configure call is required in this case. The config target is designed precisely to reinitialize the build without having to manually call configure. Skip the dependency check when running the config target to allow automatic reconfiguration in such cases. Also skip the dependency check when doing clean, distclean and fate-rsync. --- a/tests/Makefile +++ b/tests/Makefile @@ -20,7 +20,11 @@ tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) +# Do not check existence of config variables when reconfiguring to allow new +# config variables getting registered in the build system. +ifneq ($(filter clean config distclean fate-rsync, $(MAKECMDGOALS)), $(MAKECMDGOALS)) CHKCFG = $(if $($(1))$(!$(1)),$($(1)), $(error No such config: $(1))) +endif Another less backwards way of writing this probably would be ifneq ($(filter-out clean config distclean fate-rsync, $(MAKECMDGOALS)), ) I can amend it to that if you prefer that version. I think both versions are too brittle. You already missed testclean from that list. I'll try to cook something up that only applies to fate- targets later. Given that there's still no better solution, and this still is an issue I run into every now and then, I'd still like to get a version of this included - until a better solution appears obviously. I can resubmit a new version of the patch with testclean included. // Martin___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
[libav-devel] [PATCH] build: Skip FATE dependency check when making certain targets
From: Diego Biurrun di...@biurrun.de During each make run, the build system checks that any specified dependencies do actually exist, to prevent typos and other errors from fouling up correct dependency settings. However, it also causes make to trip up when new components have been added to the code, but not yet registered in the build system by configure. A manual configure call is required in this case. The config target is designed precisely to reinitialize the build without having to manually call configure. Skip the dependency check when running the config target to allow automatic reconfiguration in such cases. Also skip the dependency check when doing clean, distclean, fate-rsync and testclean. --- tests/Makefile |4 1 file changed, 4 insertions(+) diff --git a/tests/Makefile b/tests/Makefile index e32320d..e507c9e 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -24,7 +24,11 @@ tests/data/filtergraphs/%: TAG = COPY tests/data/filtergraphs/%: $(SRC_PATH)/tests/filtergraphs/% | tests/data/filtergraphs $(M)cp $ $@ +# Do not check existence of config variables when reconfiguring to allow new +# config variables getting registered in the build system. +ifneq ($(filter-out clean config distclean fate-rsync testclean, $(MAKECMDGOALS)), ) CHKCFG = $(if $($(1))$(!$(1)),$($(1)), $(error No such config: $(1))) +endif ALLYES = $(strip $(call XYES, $(1))) XYES= $(if $(strip $(1)), \ -- 1.7.9.4 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH] build: Skip FATE dependency check when making certain targets
On 2013-07-11 20:57, Martin Storsjö wrote: On Tue, 28 May 2013, Diego Biurrun wrote: On 2013-05-27 00:18, Martin Storsjö wrote: On Mon, 27 May 2013, Martin Storsjö wrote: From: Diego Biurrun di...@biurrun.de During each make run, the build system checks that any specified dependencies do actually exist, to prevent typos and other errors from fouling up correct dependency settings. However, it also causes make to trip up when new components have been added to the code, but not yet registered in the build system by configure. A manual configure call is required in this case. The config target is designed precisely to reinitialize the build without having to manually call configure. Skip the dependency check when running the config target to allow automatic reconfiguration in such cases. Also skip the dependency check when doing clean, distclean and fate-rsync. --- a/tests/Makefile +++ b/tests/Makefile @@ -20,7 +20,11 @@ tests/data/vsynth2.yuv: tests/rotozoom$(HOSTEXESUF) +# Do not check existence of config variables when reconfiguring to allow new +# config variables getting registered in the build system. +ifneq ($(filter clean config distclean fate-rsync, $(MAKECMDGOALS)), $(MAKECMDGOALS)) CHKCFG = $(if $($(1))$(!$(1)),$($(1)), $(error No such config: $(1))) +endif Another less backwards way of writing this probably would be ifneq ($(filter-out clean config distclean fate-rsync, $(MAKECMDGOALS)), ) I can amend it to that if you prefer that version. I think both versions are too brittle. You already missed testclean from that list. I'll try to cook something up that only applies to fate- targets later. Given that there's still no better solution, and this still is an issue I run into every now and then, I'd still like to get a version of this included - until a better solution appears obviously. I can resubmit a new version of the patch with testclean included. Please ping me about this sometime next week. Diego ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] Invitation to VideoLAN Dev Days 2013
On 07/11/2013 06:32 PM, Diego Biurrun wrote: On 2013-07-11 18:06, Jean-Baptiste Kempf wrote: My fellow geeks and friends, We would like to invite you to join us for the VideoLAN Dev Days 2013 Yay, looking forward to it! Thanks for the invitation! +1 ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
Re: [libav-devel] [PATCH 2/2] dca: Report the current limits in the downmixing capabilities
On 07/11/2013 08:44 PM, Martin Storsjö wrote: On Wed, 10 Jul 2013, Luca Barbato wrote: Reported-by: Mateusz j00ru Jurczyk and Gynvael Coldwind CC: libav-sta...@libav.org --- libavcodec/dcadec.c | 6 ++ 1 file changed, 6 insertions(+) Perhaps s/Report/Respect/ in the commit subject? It is both, probably better your suggestion. lu ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel
