[FFmpeg-devel] [PATCH] avutil/fifo: func could return less bytes in av_fifo_generic_write()
---
libavutil/fifo.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/fifo.c b/libavutil/fifo.c
index 4ff3194..f2fe93d 100644
--- a/libavutil/fifo.c
+++ b/libavutil/fifo.c
@@ -129,7 +129,8 @@ int av_fifo_generic_write(AVFifoBuffer *f, void *src, int
size,
do {
int len = FFMIN(f->end - wptr, size);
if (func) {
-if (func(src, wptr, len) <= 0)
+len = func(src, wptr, len);
+if (len <= 0)
break;
} else {
memcpy(wptr, src, len);
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/12] libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [1/3]
>On Tue, Jun 30, 2015 at 11:53:07AM +0200, Nedeljko Babic wrote:
>> From: Djordje Pesut
>>
>> Move the existing code to a new template file.
>>
>> Signed-off-by: Nedeljko Babic
>> ---
>> libavcodec/aacsbr.c| 1419
>> +---
>> libavcodec/aacsbr.h| 45 +
>> libavcodec/{aacsbr.c => aacsbr_template.c} | 377
>> libavcodec/sbrdsp.c| 75 +-
>> libavcodec/sbrdsp_template.c | 95 ++
>> 5 files changed, 142 insertions(+), 1869 deletions(-)
>> copy libavcodec/{aacsbr.c => aacsbr_template.c} (78%)
>> create mode 100644 libavcodec/sbrdsp_template.c
>
>seems not to apply cleanly
>
>Applying: libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [1/3]
>Using index info to reconstruct a base tree...
>Falling back to patching base and 3-way merge...
>Auto-merging libavcodec/aacsbr.c
>CONFLICT (content): Merge conflict in libavcodec/aacsbr.c
>Failed to merge in the changes.
>Patch failed at 0001 libavcodec: Implementation of AAC_fixed_decoder
>(SBR-module) [1/3]
>When you have resolved this problem run "git am --resolved".
>If you would prefer to skip this patch, instead run "git am --skip".
>To restore the original branch and stop patching run "git am --abort".
The reason is in the recent changes to the file libavcodec/aacsbr.c.
I'll rebase this as well as other patches and resend them.
Thanks,
- Nedeljko
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/12] libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [2/3]
>On Tue, Jun 30, 2015 at 11:53:08AM +0200, Nedeljko Babic wrote: >> From: Jovan Zelincevic >> >> Create tables for fixed point code. > >Can you make the first line of the commit messages a bit more >informative > >when looking at it with git log --oneline >they would all be nearly identical and one wouldnt know which is >doing what Ok. I'll make changes in the new patch set. -Nedeljko ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec: add libkvazaar HECV encoder
Signed-off-by: Arttu Ylä-Outinen
---
Changelog |1 +
configure |4 +
doc/encoders.texi | 24 +
doc/general.texi| 10 +-
libavcodec/Makefile |1 +
libavcodec/allcodecs.c |1 +
libavcodec/libkvazaar.c | 248 +++
libavcodec/version.h|2 +-
8 files changed, 289 insertions(+), 2 deletions(-)
create mode 100644 libavcodec/libkvazaar.c
diff --git a/Changelog b/Changelog
index ccd8d4a..a4451f9 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- adrawgraph audio and drawgraph video filter
- removegrain video filter
- Intel QSV-accelerated MPEG-2 video and HEVC encoding
+- libkvazaar HEVC encoder
version 2.7:
diff --git a/configure b/configure
index 88ee936..5616b59 100755
--- a/configure
+++ b/configure
@@ -222,6 +222,7 @@ External library support:
--enable-libgsm enable GSM de/encoding via libgsm [no]
--enable-libiec61883 enable iec61883 via libiec61883 [no]
--enable-libilbc enable iLBC de/encoding via libilbc [no]
+ --enable-libkvazaar enable HEVC encoding via libkvazaar [no]
--enable-libmfx enable HW acceleration through libmfx
--enable-libmodplug enable ModPlug via libmodplug [no]
--enable-libmp3lame enable MP3 encoding via libmp3lame [no]
@@ -1386,6 +1387,7 @@ EXTERNAL_LIBRARY_LIST="
libgsm
libiec61883
libilbc
+libkvazaar
libmfx
libmodplug
libmp3lame
@@ -2464,6 +2466,7 @@ libgsm_ms_decoder_deps="libgsm"
libgsm_ms_encoder_deps="libgsm"
libilbc_decoder_deps="libilbc"
libilbc_encoder_deps="libilbc"
+libkvazaar_encoder_deps="libkvazaar"
libmodplug_demuxer_deps="libmodplug"
libmp3lame_encoder_deps="libmp3lame"
libmp3lame_encoder_select="audio_frame_queue"
@@ -5152,6 +5155,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h"
"gsm/gsm.h"; do
check_lib "${gsm_hdr}" gsm_create -lgsm &&
break;
done || die "ERROR: libgsm not found"; }
enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc
+enabled libkvazaar&& require2 libkvazaar kvazaar.h kvz_api_get
-lkvazaar
enabled libmfx&& require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit
enabled libmodplug&& require_pkg_config libmodplug
libmodplug/modplug.h ModPlug_Load
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
lame_set_VBR_quality -lmp3lame
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 5946644..6e50a90 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2315,6 +2315,30 @@ Setting a higher @option{bits_per_mb} limit will improve
the speed.
For the fastest encoding speed set the @option{qscale} parameter (4 is the
recommended value) and do not set a size constraint.
+@section libkvazaar
+
+Kvazaar H.265/HEVC encoder.
+
+Requires the presence of the libkvazaar headers and library during
+configuration. You need to explicitly configure the build with
+@option{--enable-libkvazaar}.
+
+@subsection Options
+
+@table @option
+
+@item b
+Set target video bitrate in bit/s and enable rate control.
+
+@item threads
+Set number of encoding threads.
+
+@item kvazaar-params
+Set kvazaar parameters as a list of @var{name}=@var{value} pairs separated
+by commas (,). See kvazaar documentation for a list of options.
+
+@end table
+
@c man end VIDEO ENCODERS
@chapter Subtitles Encoders
diff --git a/doc/general.texi b/doc/general.texi
index 5089c36..dc22d90 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -145,6 +145,14 @@ x265 is under the GNU Public License Version 2 or later
details), you must upgrade FFmpeg's license to GPL in order to use it.
@end float
+@section kvazaar
+
+FFmpeg can make use of the kvazaar library for HEVC encoding.
+
+Go to @url{https://github.com/ultravideo/kvazaar} and follow the
+instructions for installing the library. Then pass
+@code{--enable-libkvazaar} to configure to enable it.
+
@section libilbc
iLBC is a narrowband speech codec that has been made freely available
@@ -688,7 +696,7 @@ following image formats are supported:
@item H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10 @tab E @tab X
@tab encoding supported through external library libx264 and OpenH264
@item HEVC @tab X @tab X
-@tab encoding supported through the external library libx265
+@tab encoding supported through external library libx265 and libkvazaar
@item HNM version 4 @tab @tab X
@item HuffYUV@tab X @tab X
@item HuffYUV FFmpeg variant @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 70755f6..b7fe1c9 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -768,6 +768,7 @@ OBJS-$(CONFIG_LIBGSM_MS_DECODER) += libgsmdec.o
OBJS-$(CONFIG_LIBGSM_MS_ENCODER) += libgsmenc.o
OBJS-$(CONFIG_LIBILBC_DECODER)+= libilb
Re: [FFmpeg-devel] [PATCH] vf_ssim: x86 simd for ssim_4x4xN and ssim_endN.
On Mon, Jul 13, 2015 at 11:39:15PM -0300, James Almer wrote: > On 12/07/15 8:33 PM, Ronald S. Bultje wrote: > > +INIT_XMM sse4 > > +cglobal ssim_end_line, 3, 3, 6, sum0, sum1, w > > +pxor m0, m0 > > +.loop: > > +mova m1, [sum0q+mmsize*0] > > +mova m2, [sum0q+mmsize*1] > > +mova m3, [sum0q+mmsize*2] > > +mova m4, [sum0q+mmsize*3] > > +paddd m1, [sum1q+mmsize*0] > > +paddd m2, [sum1q+mmsize*1] > > +paddd m3, [sum1q+mmsize*2] > > +paddd m4, [sum1q+mmsize*3] > > +paddd m1, m2 > > +paddd m2, m3 > > +paddd m3, m4 > > +paddd m4, [sum0q+mmsize*4] > > +paddd m4, [sum1q+mmsize*4] > > +TRANSPOSE4x4D 1, 2, 3, 4, 5 > > + > > +; m1 = fs1, m2 = fs2, m3 = fss, m4 = fs12 > > +pslld m3, 6 > > +pslld m4, 6 > > +pmulldm5, m1, m2; fs1 * fs2 > > +pmulldm1, m1; fs1 * fs1 > > +pmulldm2, m2; fs2 * fs2 > > If these values are guaranteed to be always positive then this could also > be implemented with pmuludq to get an sse2 version working. Although I'm > not sure if it's worth doing. It will be six pmuludq and an awful lot of > shuffling and unpacking when the speed up of the sse4 version is already > only ~2x the C version. > > This was already oked (Same with the psnr sse2 code), so it should be > pushed already. /me wonders a little bit why noone else applied it yet, but applied thanks [...] -- 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 signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_ssim: x86 simd for ssim_4x4xN and ssim_endN.
On 12/07/15 8:33 PM, Ronald S. Bultje wrote: > +INIT_XMM sse4 > +cglobal ssim_end_line, 3, 3, 6, sum0, sum1, w > +pxor m0, m0 > +.loop: > +mova m1, [sum0q+mmsize*0] > +mova m2, [sum0q+mmsize*1] > +mova m3, [sum0q+mmsize*2] > +mova m4, [sum0q+mmsize*3] > +paddd m1, [sum1q+mmsize*0] > +paddd m2, [sum1q+mmsize*1] > +paddd m3, [sum1q+mmsize*2] > +paddd m4, [sum1q+mmsize*3] > +paddd m1, m2 > +paddd m2, m3 > +paddd m3, m4 > +paddd m4, [sum0q+mmsize*4] > +paddd m4, [sum1q+mmsize*4] > +TRANSPOSE4x4D 1, 2, 3, 4, 5 > + > +; m1 = fs1, m2 = fs2, m3 = fss, m4 = fs12 > +pslld m3, 6 > +pslld m4, 6 > +pmulldm5, m1, m2; fs1 * fs2 > +pmulldm1, m1; fs1 * fs1 > +pmulldm2, m2; fs2 * fs2 If these values are guaranteed to be always positive then this could also be implemented with pmuludq to get an sse2 version working. Although I'm not sure if it's worth doing. It will be six pmuludq and an awful lot of shuffling and unpacking when the speed up of the sse4 version is already only ~2x the C version. This was already oked (Same with the psnr sse2 code), so it should be pushed already. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] WebP native muxer bugfix: frames should have alpha blending off
On Tue, Jul 14, 2015 at 12:20:43AM +, Urvang Joshi wrote: > Hi Michael, > How about sending the blend method info using side_data in the AVFrame? the encoders input are AVFrames, the encoder does not output AVFrames so you cannot send anything with an AVFrame from the encoder to the muxer. The data struct between encoder and muxer is a AVPacket the ANMF chunk which carries the blend information could be put like any other chunk in AVPacket.data together with the rest of the frame. I think thats cleaner than putting strings in side data but such side data would also work > > Here's the patch using that method. If this looks fine, I can separate it > out into avformat/* changes and avcodec/* changes. [...] > Two cases here: > > (1) With the default encoder options, all the frames that the native muxer > gets are fully reconstructed frames, and they should NOT be alpha-blended > with the previous frames. > > As per the WebP container spec > https://developers.google.com/speed/webp/docs/riff_container#animation, > ANMF chunk should specify blending method = do not blend (and disposal > method = do not dispose). > > However, the native muxer was wrongly setting blending method = use > alpha blending for this case. > This bug can be reproduced by converting a source with transparency > (e.g. animated GIF with transparency) to an animated WebP, and viewing > it with vwebp. > > (2) In presence of options like 'cr_threshold' and 'cr_size', the frames > may be modified to introduce some transparent pixels and they SHOULD be > alpha-blended with the previous frames. However, such introduction of > transparent pixels should only be allowed when the original frame didn't > already contain some transparent pixels. this seems not to work: ./ffmpeg -i matrixbench_mpeg2.mpg -cr_threshold 1 -cr_size 16 -t 1 -loop 2 -vcodec libwebp -flags +bitexact ref.webp apply patch ./ffmpeg -i matrixbench_mpeg2.mpg -cr_threshold 1 -cr_size 16 -t 1 -loop 2 -vcodec libwebp -flags +bitexact new.webp ./ffmpeg -i matrixbench_mpeg2.mpg -t 1 -loop 2 -vcodec libwebp -flags +bitexact new-nocr.webp ls -alF *.webp -rw-r- 1 michael michael 191978 Jul 14 03:29 new-nocr.webp -rw-r- 1 michael michael 191978 Jul 14 03:15 new.webp -rw-r- 1 michael michael 139126 Jul 14 03:12 ref.webp theres no transparency in matrixbench_mpeg2.mpg, yet the cr_* options no longer work [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mem_internal: add missing header includes
On 13/07/15 9:50 PM, Michael Niedermayer wrote: > On Mon, Jul 13, 2015 at 06:07:29PM -0300, James Almer wrote: >> Fixes make checkheaders >> >> Signed-off-by: James Almer >> --- >> libavutil/mem_internal.h | 3 +++ >> 1 file changed, 3 insertions(+) > > LGTM > > thanks Pushed ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil/mem_internal: add missing header includes
On Mon, Jul 13, 2015 at 06:07:29PM -0300, James Almer wrote: > Fixes make checkheaders > > Signed-off-by: James Almer > --- > libavutil/mem_internal.h | 3 +++ > 1 file changed, 3 insertions(+) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.
On Mon, Jul 13, 2015 at 11:26:41PM +0200, Gwenole Beauchesne wrote: > Hi, > > 2015-07-13 16:22 GMT+02:00 Ivan Uskov : > > Hello All, > > > > Current QSV engine implementation does allocate but never does release > > a display handler under linux platforms. > > The attached patch solved this issue, please review. > > LGTM. However, missing newline IMHO before > ff_qsv_close_internal_session() and after QSVSession definition. newlines added applied thanks > > Note it would also be interesting to provide a means to import a > VADisplay from the user through an additional function. e.g. in view > to interop VA decode to MSDK encode and/or video processing. > > Regards, > -- > Gwenole Beauchesne > Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France > Registration Number (RCS): Nanterre B 302 456 199 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Asymptotically faster algorithms should always be preferred if you have asymptotical amounts of data signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v4] Add support for Audible AAX (and AAX+) files
Thanks for all the feedback, and help.
VesselinFrom 1ed235454a61fe1f8d993d09d3d6398e7609c624 Mon Sep 17 00:00:00 2001
From: Vesselin Bontchev
Date: Sat, 11 Jul 2015 18:02:47 +
Subject: [PATCH] Add support for Audible AAX (and AAX+) files
---
libavformat/isom.h |5 ++
libavformat/mov.c | 138
2 files changed, 143 insertions(+)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index 5d48989..9fa02e7 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -198,6 +198,11 @@ typedef struct MOVContext {
MOVFragmentIndex** fragment_index_data;
unsigned fragment_index_count;
int atom_depth;
+unsigned int aax_mode; ///< 'aax' file has been detected
+unsigned char file_key[20];
+unsigned char file_iv[20];
+void *activation_bytes;
+int activation_bytes_size;
} MOVContext;
int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index d1b29a2..6f9bf50 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -26,6 +26,7 @@
#include
#include
#include
+#include
#include "libavutil/attributes.h"
#include "libavutil/channel_layout.h"
@@ -37,6 +38,8 @@
#include "libavutil/dict.h"
#include "libavutil/display.h"
#include "libavutil/opt.h"
+#include "libavutil/aes.h"
+#include "libavutil/sha.h"
#include "libavutil/timecode.h"
#include "libavcodec/ac3tab.h"
#include "avformat.h"
@@ -807,6 +810,109 @@ static int mov_read_mdat(MOVContext *c, AVIOContext *pb, MOVAtom atom)
return 0; /* now go for moov */
}
+static void hex_encode(unsigned char *s, int len, unsigned char *o)
+{
+char itoa16_private[16] = "0123456789abcdef";
+int i;
+for (i = 0; i < len; ++i) {
+o[0] = itoa16_private[s[i] >> 4];
+o[1] = itoa16_private[s[i] & 15];
+o += 2;
+}
+}
+
+#define DRM_BLOB_SIZE 56
+
+static int mov_read_adrm(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+// extracted from libAAX_SDK.so and AAXSDKWin.dll files!
+unsigned char fixed_key[] = { 0x77, 0x21, 0x4d, 0x4b, 0x19, 0x6a, 0x87, 0xcd,
+ 0x52, 0x00, 0x45, 0xfd, 0x20, 0xa5, 0x1d, 0x67 };
+unsigned char intermediate_key[20] = {0};
+unsigned char intermediate_iv[20] = {0};
+unsigned char input[64] = {0};
+unsigned char output[64] = {0};
+unsigned char file_checksum[20] = {0};
+unsigned char file_checksum_encoded[41] = {0};
+unsigned char file_key_encoded[41] = {0};
+unsigned char file_iv_encoded[41] = {0};
+unsigned char calculated_checksum[20];
+struct AVSHA *ctx;
+struct AVAES *aes_decrypt;
+int i;
+unsigned char *activation_bytes = (unsigned char*) c->activation_bytes;
+
+av_log(c->fc, AV_LOG_DEBUG, "[aax] aax file detected!\n");
+c->aax_mode = 1;
+
+ctx = av_sha_alloc();
+aes_decrypt = av_aes_alloc();
+if (!aes_decrypt) {
+return AVERROR(ENOMEM);
+}
+
+/* drm blob processing */
+ffio_read_size(pb, output, 8); // go to offset 8, absolute postion 0x251
+ffio_read_size(pb, input, DRM_BLOB_SIZE);
+ffio_read_size(pb, output, 4); // go to offset 4, absolute postion 0x28d
+ffio_read_size(pb, file_checksum, 20);
+hex_encode(file_checksum, 20, file_checksum_encoded);
+av_log(c->fc, AV_LOG_DEBUG, "[aax] file checksum == %s\n", file_checksum_encoded);
+
+/* verify activation data */
+if (!activation_bytes || c->activation_bytes_size != 4) {
+av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes option is missing!\n");
+return AVERROR_INVALIDDATA;
+}
+if (c->activation_bytes_size != 4) {
+av_log(c->fc, AV_LOG_FATAL, "[aax] activation_bytes value needs to be 4 bytes!\n");
+return AVERROR_INVALIDDATA;
+}
+
+/* AAX (and AAX+) key derivation */
+av_sha_init(ctx, 160);
+av_sha_update(ctx, fixed_key, 16);
+av_sha_update(ctx, activation_bytes, 4);
+av_sha_final(ctx, intermediate_key);
+av_sha_init(ctx, 160);
+av_sha_update(ctx, fixed_key, 16);
+av_sha_update(ctx, intermediate_key, 20);
+av_sha_update(ctx, activation_bytes, 4);
+av_sha_final(ctx, intermediate_iv);
+av_sha_init(ctx, 160);
+av_sha_update(ctx, intermediate_key, 16);
+av_sha_update(ctx, intermediate_iv, 16);
+av_sha_final(ctx, calculated_checksum);
+if (memcmp(calculated_checksum, file_checksum, 20)) {
+av_log(c->fc, AV_LOG_ERROR, "[aax] mismatch in checksums!\n");
+return AVERROR_INVALIDDATA;
+}
+av_aes_init(aes_decrypt, intermediate_key, 128, 1);
+av_aes_crypt(aes_decrypt, output, input, DRM_BLOB_SIZE >> 4, intermediate_iv, 1);
+for (i = 0; i < 4; i++) {
+if (activation_bytes[i] != output[3 - i]) {
+av_log(c->fc, AV_LOG_ERROR, "[aax] error in drm blob decryption!\n");
+return AVERROR_INVALIDDATA;
+}
+}
+memcpy(c->file_key, output + 8, 16);
+memcpy(input, output + 26, 16);
+av_sha_i
Re: [FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.
Hi, 2015-07-13 16:22 GMT+02:00 Ivan Uskov : > Hello All, > > Current QSV engine implementation does allocate but never does release > a display handler under linux platforms. > The attached patch solved this issue, please review. LGTM. However, missing newline IMHO before ff_qsv_close_internal_session() and after QSVSession definition. Note it would also be interesting to provide a means to import a VADisplay from the user through an additional function. e.g. in view to interop VA decode to MSDK encode and/or video processing. Regards, -- Gwenole Beauchesne Intel Corporation SAS / 2 rue de Paris, 92196 Meudon Cedex, France Registration Number (RCS): Nanterre B 302 456 199 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/mem_internal: add missing header includes
Fixes make checkheaders
Signed-off-by: James Almer
---
libavutil/mem_internal.h | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavutil/mem_internal.h b/libavutil/mem_internal.h
index 54e14ac..6fdbcb0 100644
--- a/libavutil/mem_internal.h
+++ b/libavutil/mem_internal.h
@@ -21,6 +21,9 @@
#ifndef AVUTIL_MEM_INTERNAL_H
#define AVUTIL_MEM_INTERNAL_H
+#include "avassert.h"
+#include "mem.h"
+
static inline int ff_fast_malloc(void *ptr, unsigned int *size, size_t
min_size, int zero_realloc)
{
void *val;
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add deband filter
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_deband.c | 283 +++
3 files changed, 285 insertions(+)
create mode 100644 libavfilter/vf_deband.c
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a623433..ea5c7c8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -111,6 +111,7 @@ OBJS-$(CONFIG_CROP_FILTER) += vf_crop.o
OBJS-$(CONFIG_CROPDETECT_FILTER) += vf_cropdetect.o
OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
OBJS-$(CONFIG_DCTDNOIZ_FILTER) += vf_dctdnoiz.o
+OBJS-$(CONFIG_DEBAND_FILTER) += vf_deband.o
OBJS-$(CONFIG_DECIMATE_FILTER) += vf_decimate.o
OBJS-$(CONFIG_DEJUDDER_FILTER) += vf_dejudder.o
OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ab0dc1d..5128708 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -127,6 +127,7 @@ void avfilter_register_all(void)
REGISTER_FILTER(CROPDETECT, cropdetect, vf);
REGISTER_FILTER(CURVES, curves, vf);
REGISTER_FILTER(DCTDNOIZ, dctdnoiz, vf);
+REGISTER_FILTER(DEBAND, deband, vf);
REGISTER_FILTER(DECIMATE, decimate, vf);
REGISTER_FILTER(DEJUDDER, dejudder, vf);
REGISTER_FILTER(DELOGO, delogo, vf);
diff --git a/libavfilter/vf_deband.c b/libavfilter/vf_deband.c
new file mode 100644
index 000..a6e2066
--- /dev/null
+++ b/libavfilter/vf_deband.c
@@ -0,0 +1,283 @@
+/*
+ * Copyright (c) 2015 Niklas Haas
+ * Copyright (c) 2015 Paul B Mahol
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE
+ * SOFTWARE.
+ */
+
+/*
+ * TODO: fix obvious bugs
+ */
+
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "video.h"
+
+typedef struct DebandContext {
+const AVClass *class;
+
+float threshold[4];
+int range;
+float direction;
+
+int nb_components;
+int planewidth[4];
+int planeheight[4];
+int thr[4];
+
+int (*deband)(AVFilterContext *ctx, void *arg, int jobnr, int nb_jobs);
+} DebandContext;
+
+#define OFFSET(x) offsetof(DebandContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+
+static const AVOption deband_options[] = {
+{ "1thr", "set 1st plane threshold", OFFSET(threshold[0]),
AV_OPT_TYPE_FLOAT, {.dbl=0.02}, 0.0, 0.1, .flags = FLAGS },
+{ "2thr", "set 2nd plane threshold", OFFSET(threshold[1]),
AV_OPT_TYPE_FLOAT, {.dbl=0.02}, 0.0, 0.1, .flags = FLAGS },
+{ "3thr", "set 3rd plane threshold", OFFSET(threshold[2]),
AV_OPT_TYPE_FLOAT, {.dbl=0.02}, 0.0, 0.1, .flags = FLAGS },
+{ "4thr", "set 4th plane threshold", OFFSET(threshold[3]),
AV_OPT_TYPE_FLOAT, {.dbl=0.02}, 0.0, 0.1, .flags = FLAGS },
+{ "range", "set range", OFFSET(range),
AV_OPT_TYPE_INT, {.i64=16}, 1, INT_MAX, .flags = FLAGS },
+{ "r", "set range", OFFSET(range),
AV_OPT_TYPE_INT, {.i64=16}, 1, INT_MAX, .flags = FLAGS },
+{ "direction", "set direction", OFFSET(direction),
AV_OPT_TYPE_FLOAT, {.dbl=0.00}, 0.0, 2 * M_PI, .flags = FLAGS },
+{ "d", "set direction", OFFSET(direction),
AV_OPT_TYPE_FLOAT, {.dbl=0.00}, 0.0, 2 * M_PI, .flags = FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(deband);
+
+static int query_formats(AVFilterContext *ctx)
+{
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_YUVJ444P, AV_PIX_FMT_YUVJ422P, AV
[FFmpeg-devel] [PATCH] lavfi: add erosion, dilation, deflate & inflate filter
Signed-off-by: Paul B Mahol
---
Changelog | 1 +
doc/filters.texi | 78 +
libavfilter/Makefile | 4 +
libavfilter/allfilters.c | 4 +
libavfilter/vf_neighbor.c | 402 ++
5 files changed, 489 insertions(+)
create mode 100644 libavfilter/vf_neighbor.c
diff --git a/Changelog b/Changelog
index ccd8d4a..31a21a0 100644
--- a/Changelog
+++ b/Changelog
@@ -15,6 +15,7 @@ version :
- adrawgraph audio and drawgraph video filter
- removegrain video filter
- Intel QSV-accelerated MPEG-2 video and HEVC encoding
+- erosion, dilation, deflate and inflate video filters
version 2.7:
diff --git a/doc/filters.texi b/doc/filters.texi
index 9f7b976..d4d8bad 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -3718,6 +3718,24 @@ Set whether or not chroma is considered in the metric
calculations. Default is
@code{1}.
@end table
+@section deflate
+
+Apply deflate effect to the video.
+
+This filter replaces the pixel by the local(3x3) average by taking into account
+only values lower than the pixel.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section dejudder
Remove judder produced by partially interlaced telecined content.
@@ -3904,6 +3922,27 @@ A number representing position of the first frame with
respect to the telecine
pattern. This is to be used if the stream is cut. The default value is
@code{0}.
@end table
+@section dilation
+
+Apply dilation effect to the video.
+
+This filter replaces the pixel by the local(3x3) maximum.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 i.e. all eight
+pixels are used.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section drawbox
Draw a colored box on the input image.
@@ -4759,6 +4798,27 @@ value.
@end table
+@section erosion
+
+Apply erosion effect to the video.
+
+This filter replaces the pixel by the local(3x3) minimum.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item coordinates
+Flag which specifies the pixel to refer to. Default is 255 i.e. all eight
+pixels are used.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section extractplanes
Extract color channel components from input video stream into
@@ -6356,6 +6416,24 @@ Default value is @code{none}.
Swap luma/chroma/alpha fields. Exchange even & odd lines. Default value is
@code{0}.
@end table
+@section inflate
+
+Apply inflate effect to the video.
+
+This filter replaces the pixel by the local(3x3) average by taking into account
+only values higher than the pixel.
+
+It accepts the following options:
+
+@table @option
+@item threshold
+Allows to limit the maximum change, default is 65535.
+
+@item planes
+Flag which specifies which planes to filter. Default is 15 i.e. all four
+planes.
+@end table
+
@section interlace
Simple interlacing filter from progressive contents. This interleaves upper (or
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a623433..058b9e9 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -112,10 +112,12 @@ OBJS-$(CONFIG_CROPDETECT_FILTER) +=
vf_cropdetect.o
OBJS-$(CONFIG_CURVES_FILTER) += vf_curves.o
OBJS-$(CONFIG_DCTDNOIZ_FILTER) += vf_dctdnoiz.o
OBJS-$(CONFIG_DECIMATE_FILTER) += vf_decimate.o
+OBJS-$(CONFIG_DEFLATE_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_DEJUDDER_FILTER) += vf_dejudder.o
OBJS-$(CONFIG_DELOGO_FILTER) += vf_delogo.o
OBJS-$(CONFIG_DESHAKE_FILTER)+= vf_deshake.o
OBJS-$(CONFIG_DETELECINE_FILTER) += vf_detelecine.o
+OBJS-$(CONFIG_DILATION_FILTER) += vf_neighbor.o
OBJS-$(CONFIG_DRAWBOX_FILTER)+= vf_drawbox.o
OBJS-$(CONFIG_DRAWGRAPH_FILTER) += f_drawgraph.o
OBJS-$(CONFIG_DRAWGRID_FILTER) += vf_drawbox.o
@@ -123,6 +125,7 @@ OBJS-$(CONFIG_DRAWTEXT_FILTER) +=
vf_drawtext.o
OBJS-$(CONFIG_ELBG_FILTER) += vf_elbg.o
OBJS-$(CONFIG_EDGEDETECT_FILTER) += vf_edgedetect.o
OBJS-$(CONFIG_EQ_FILTER) += vf_eq.o
+OBJS-$(CONFIG_EROSION_FILTER)+= vf_neighbor.o
OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
@@ -147,6 +150,7 @@ OBJS-$(CONFIG_HQX_FILTER)
Re: [FFmpeg-devel] [PATCH] vf_psnr: sse2 optimizations for sum-squared-error.
On 13/07/15 5:07 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Jul 13, 2015 at 3:50 PM, James Darnley
> wrote:
>
>> On 2015-07-13 01:34, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Jul 12, 2015 at 5:54 PM, Paul B Mahol wrote:
>>>
On 7/12/15, Ronald S. Bultje wrote:
> +typedef struct PSNRDSPContext {
> +uint64_t (*sse_line)(const uint8_t *buf, const uint8_t *ref, int
>> w);
Besides naming of function sse_line rest LGTM.
>>>
>>> That was sort of inspired by other functions in lavfi. I'm open to
>>> alternative suggestions.
>>
>> If it was called sse after Intel's Streaming SIMD Extensions then it
>> would be "bad" because it implies it must use those instructions. (Or
>> some reason like that.)
>>
>> If it was called sse after Sum of Squared Errors then it would be "good"
>> because the name is correctly reflecting what it does.
>>
>> Perhaps ssd is more acceptable after Sum of Squared Differences?
>
>
> Libavcodec calls this thing sum-of-squared-errors already (grep -i squared
> libavcodec/x86/*.asm).
>
> Ronald
Yeah, me_cmp uses sse as abbreviation for Sum of Squared Errors, so IMO it's
fine here as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_psnr: sse2 optimizations for sum-squared-error.
Hi,
On Mon, Jul 13, 2015 at 3:50 PM, James Darnley
wrote:
> On 2015-07-13 01:34, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Sun, Jul 12, 2015 at 5:54 PM, Paul B Mahol wrote:
> >
> >> On 7/12/15, Ronald S. Bultje wrote:
> >>> +typedef struct PSNRDSPContext {
> >>> +uint64_t (*sse_line)(const uint8_t *buf, const uint8_t *ref, int
> w);
> >>
> >> Besides naming of function sse_line rest LGTM.
> >>
> >
> > That was sort of inspired by other functions in lavfi. I'm open to
> > alternative suggestions.
>
> If it was called sse after Intel's Streaming SIMD Extensions then it
> would be "bad" because it implies it must use those instructions. (Or
> some reason like that.)
>
> If it was called sse after Sum of Squared Errors then it would be "good"
> because the name is correctly reflecting what it does.
>
> Perhaps ssd is more acceptable after Sum of Squared Differences?
Libavcodec calls this thing sum-of-squared-errors already (grep -i squared
libavcodec/x86/*.asm).
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vf_psnr: sse2 optimizations for sum-squared-error.
On 2015-07-13 01:34, Ronald S. Bultje wrote:
> Hi,
>
> On Sun, Jul 12, 2015 at 5:54 PM, Paul B Mahol wrote:
>
>> On 7/12/15, Ronald S. Bultje wrote:
>>> +typedef struct PSNRDSPContext {
>>> +uint64_t (*sse_line)(const uint8_t *buf, const uint8_t *ref, int w);
>>
>> Besides naming of function sse_line rest LGTM.
>>
>
> That was sort of inspired by other functions in lavfi. I'm open to
> alternative suggestions.
If it was called sse after Intel's Streaming SIMD Extensions then it
would be "bad" because it implies it must use those instructions. (Or
some reason like that.)
If it was called sse after Sum of Squared Errors then it would be "good"
because the name is correctly reflecting what it does.
Perhaps ssd is more acceptable after Sum of Squared Differences?
signature.asc
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/12] libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [2/3]
On Tue, Jun 30, 2015 at 11:53:08AM +0200, Nedeljko Babic wrote: > From: Jovan Zelincevic > > Create tables for fixed point code. Can you make the first line of the commit messages a bit more informative when looking at it with git log --oneline they would all be nearly identical and one wouldnt know which is doing what [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Democracy is the form of government in which you can choose your dictator signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/12] libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [1/3]
On Tue, Jun 30, 2015 at 11:53:07AM +0200, Nedeljko Babic wrote:
> From: Djordje Pesut
>
> Move the existing code to a new template file.
>
> Signed-off-by: Nedeljko Babic
> ---
> libavcodec/aacsbr.c| 1419
> +---
> libavcodec/aacsbr.h| 45 +
> libavcodec/{aacsbr.c => aacsbr_template.c} | 377
> libavcodec/sbrdsp.c| 75 +-
> libavcodec/sbrdsp_template.c | 95 ++
> 5 files changed, 142 insertions(+), 1869 deletions(-)
> copy libavcodec/{aacsbr.c => aacsbr_template.c} (78%)
> create mode 100644 libavcodec/sbrdsp_template.c
seems not to apply cleanly
Applying: libavcodec: Implementation of AAC_fixed_decoder (SBR-module) [1/3]
Using index info to reconstruct a base tree...
Falling back to patching base and 3-way merge...
Auto-merging libavcodec/aacsbr.c
CONFLICT (content): Merge conflict in libavcodec/aacsbr.c
Failed to merge in the changes.
Patch failed at 0001 libavcodec: Implementation of AAC_fixed_decoder
(SBR-module) [1/3]
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use the old parser only when hevc decoder is available
On 13/07/15 2:52 PM, Michael Niedermayer wrote: > On Mon, Jul 13, 2015 at 02:14:18PM -0300, James Almer wrote: >> If it's not, then the new dependence-free parser will be used instead >> >> Signed-off-by: James Almer >> --- >> configure| 2 -- >> libavcodec/hevc_parser.c | 10 +- >> 2 files changed, 5 insertions(+), 7 deletions(-) > > LGTM > > thanks Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/hevc_parser: use the old parser only when hevc decoder is available
On Mon, Jul 13, 2015 at 02:14:18PM -0300, James Almer wrote: > If it's not, then the new dependence-free parser will be used instead > > Signed-off-by: James Almer > --- > configure| 2 -- > libavcodec/hevc_parser.c | 10 +- > 2 files changed, 5 insertions(+), 7 deletions(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Raise max channels to 64
Le duodi 22 messidor, an CCXXIII, Carl Eugen Hoyos a écrit :
> A user claims that attached patch helps him
> with a 64-channel software input device on
> avfoundation that does not work with current
> git head.
> diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
> index 4ba77a7..9117cc0 100644
> --- a/libavfilter/af_pan.c
> +++ b/libavfilter/af_pan.c
> @@ -37,7 +37,7 @@
> #include "formats.h"
> #include "internal.h"
>
> -#define MAX_CHANNELS 63
> +#define MAX_CHANNELS 64
>
> typedef struct PanContext {
> const AVClass *class;
No objection from me on this hunk.
But I wonder what it will do with AV_CH_LAYOUT_NATIVE. Probably nothing too
bad, though.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/hevc_parser: use the old parser only when hevc decoder is available
If it's not, then the new dependence-free parser will be used instead
Signed-off-by: James Almer
---
configure| 2 --
libavcodec/hevc_parser.c | 10 +-
2 files changed, 5 insertions(+), 7 deletions(-)
diff --git a/configure b/configure
index ac32a1f..88ee936 100755
--- a/configure
+++ b/configure
@@ -2441,8 +2441,6 @@ wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel"
# parsers
h264_parser_select="h264_decoder"
hevc_parser_select="golomb"
-#If ADVANCED_PARSER is enabled then the decoder is needed otherwise the next
line can be removed
-hevc_parser_select="hevc_decoder"
mpegvideo_parser_select="mpegvideo"
mpeg4video_parser_select="error_resilience h263dsp mpeg_er mpegvideo qpeldsp"
vc1_parser_select="mpegvideo startcode vc1_decoder"
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 77ca017..fd879a6 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -30,7 +30,7 @@
#define IS_IRAP_NAL(nal) (nal->type >= 16 && nal->type <= 23)
-#define ADVANCED_PARSER
+#define ADVANCED_PARSER CONFIG_HEVC_DECODER
typedef struct HEVCParserContext {
ParseContext pc;
@@ -40,11 +40,12 @@ typedef struct HEVCParserContext {
int parsed_extradata;
-#ifdef ADVANCED_PARSER
+#if ADVANCED_PARSER
HEVCContext h;
#endif
} HEVCParserContext;
+#if !ADVANCED_PARSER
static int hevc_parse_slice_header(AVCodecParserContext *s, HEVCNAL *nal,
AVCodecContext *avctx)
{
@@ -81,7 +82,6 @@ static int hevc_parse_slice_header(AVCodecParserContext *s,
HEVCNAL *nal,
return 0;
}
-#ifndef ADVANCED_PARSER
static int parse_nal_units(AVCodecParserContext *s, const uint8_t *buf,
int buf_size, AVCodecContext *avctx)
{
@@ -166,6 +166,7 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
return END_NOT_FOUND;
}
+#if ADVANCED_PARSER
/**
* Parse NAL units of found picture and decode some basic information.
*
@@ -174,7 +175,6 @@ static int hevc_find_frame_end(AVCodecParserContext *s,
const uint8_t *buf,
* @param buf buffer with field/frame data.
* @param buf_size size of the buffer.
*/
-#ifdef ADVANCED_PARSER
static inline int parse_nal_units(AVCodecParserContext *s, const uint8_t *buf,
int buf_size, AVCodecContext *avctx)
{
@@ -418,7 +418,7 @@ static void hevc_parser_close(AVCodecParserContext *s)
HEVCParserContext *ctx = s->priv_data;
int i;
-#ifdef ADVANCED_PARSER
+#if ADVANCED_PARSER
HEVCContext *h = &ctx->h;
av_freep(&h->HEVClc);
#endif
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: discard packets correctly
On Mon, Jul 13, 2015 at 6:14 PM, Ganesh Ajjanagadde wrote: > On Mon, Jul 13, 2015 at 12:02 PM, Michael Niedermayer > wrote: >> On Mon, Jul 13, 2015 at 09:32:06AM -0400, Ganesh Ajjanagadde wrote: >>> On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer >>> wrote: >>> > On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: >>> >> libav commit 13f6917c merged in 574dcb5b results in >>> >> unnecessary seeks due to discarded packets; >>> >> especially problematic over a network. >>> >> >>> >> Fixes Ticket4126 >>> >> >>> >> Signed-off-by: Ganesh Ajjanagadde >>> >> --- >>> >> ffmpeg_opt.c | 10 +++--- >>> >> 1 file changed, 7 insertions(+), 3 deletions(-) >>> > >>> > i dont think that not marking streams for discarding can be correct >>> > to fix a speed regression. >>> > >>> > Reading should not become significantly slower in a >>> > real world (non constructed) case when a stream is marked as discard >>> > >>> > See short_seek_threshold, maybe it can be adjusted for http or >>> > network protocols or maybe ff_configure_buffers_for_index() could >>> > adjust things to avoid seeks for discarded streams >>> > >>> > A fix purely in ffmpeg_opt also has the disadvanatge that it would >>> > not help any other applications which use libavformat with discarded >>> > streams >>> >>> Before I dive deeper into this, I have a few comments and questions: >>> 1. I tested against not just the example in the ticket, >>> but also against random test files obtained at >>> http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm; >>> I don't know whether these are close enough to real world examples. >>> It therefore seems like reading (without above patch) does become >>> significantly slower for at least mp4 files delivered over http. >>> Basically, there are a huge number of redundant partial chunk http requests, >>> due to seeks that don't fall within existing buffers as they have been >>> discarded. >> >> yes >> >> >>> >>> 2. I used the above simple fix as libav commit 13f6917c >>> did not offer any clear reason as to what was being fixed >>> (on the mailing list archive): >>> https://lists.libav.org/pipermail/libav-devel/2012-February/022525.html >>> https://lists.libav.org/pipermail/libav-devel/2012-February/022527.html >>> beyond "useful for debugging" and "not return packets for streams we >>> are not interested in". >>> Can someone give me a clearer reason or concrete use case >>> where the above libav commit did something beneficial? >> >> in a network protocol where streams can be disabled so they are not >> transmitted enabling all streams would be a problem due to possibly >> significantly increased bandwidth usage. >> i do not know if the commit actually did help this case but >> simply not using a feature is not fixing a bug in that feature. >> even if we revert that commit, there still would be a problem >> with http and disabled streams > > The irony is that the commit on first glance would decrease network usage > due to the disabled stream. > However, in reality, the only observed effect right now (at least for me) > is an increased network usage (precisely responsible for the slowdown). > This requires further investigation as you pointed out. > Often this can be a case where avformat starts to seek the stream instead of just reading it - while that uses less data overall, the latency from the seek will sometimes add more time than simply reading the unwanted data. Over HTTP for example, a continous stream is usually always going to be much faster than byte-seeking the file for every input packet. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/pthread_slice: for large job counts, avoid lock/unlock between jobs on the same thread
Currently for large job counts, pthread_slice.c acquires and releases a lock
between each job. Acquiring the locks can take more time than the job itself.
The DDS and Hap decoders naively create a job per 4x4 pixel block. For a 4Kx2K
frame:
decode before patch: 1562ms
decode after patch: 14ms
Clients probably should be able to submit jobs without having to consider the
number of threads the jobs will be run on, and this is a possible solution to
that. It makes the assumption that all jobs will take roughly the same amount
of time and that threads will be scheduled evenly.
---
libavcodec/pthread_slice.c | 39 ---
1 file changed, 32 insertions(+), 7 deletions(-)
diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index c8e69f0..751e5f4 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
@@ -50,9 +50,11 @@ typedef struct SliceThreadContext {
action_func2 *func2;
void *args;
int *rets;
+int *subjob_limits;
+int *subjob_offsets;
int rets_count;
int job_count;
-int job_size;
+int subjob_size;
pthread_cond_t last_job_cond;
pthread_cond_t current_job_cond;
@@ -76,6 +78,7 @@ static void* attribute_align_arg worker(void *v)
int our_job = c->job_count;
int thread_count = avctx->thread_count;
int self_id;
+int i;
pthread_mutex_lock(&c->current_job_lock);
self_id = c->current_job++;
@@ -96,8 +99,10 @@ static void* attribute_align_arg worker(void *v)
}
pthread_mutex_unlock(&c->current_job_lock);
-c->rets[our_job%c->rets_count] = c->func ? c->func(avctx,
(char*)c->args + our_job*c->job_size):
- c->func2(avctx, c->args,
our_job, self_id);
+for (i = c->subjob_offsets[our_job]; i < c->subjob_limits[our_job];
i++) {
+c->rets[i%c->rets_count] = c->func ? c->func(avctx, (char*)c->args
+ i*c->subjob_size):
+c->func2(avctx, c->args, i, self_id);
+}
pthread_mutex_lock(&c->current_job_lock);
our_job = c->current_job++;
@@ -133,6 +138,8 @@ void ff_slice_thread_free(AVCodecContext *avctx)
av_freep(&c->progress_cond);
av_freep(&c->workers);
+av_freep(&c->subjob_limits);
+av_freep(&c->subjob_offsets);
av_freep(&avctx->internal->thread_ctx);
}
@@ -146,7 +153,7 @@ static av_always_inline void
thread_park_workers(SliceThreadContext *c, int thre
static int thread_execute(AVCodecContext *avctx, action_func* func, void *arg,
int *ret, int job_count, int job_size)
{
SliceThreadContext *c = avctx->internal->thread_ctx;
-int dummy_ret;
+int dummy_ret, i;
if (!(avctx->active_thread_type&FF_THREAD_SLICE) || avctx->thread_count <=
1)
return avcodec_default_execute(avctx, func, arg, ret, job_count,
job_size);
@@ -157,8 +164,14 @@ static int thread_execute(AVCodecContext *avctx,
action_func* func, void *arg, i
pthread_mutex_lock(&c->current_job_lock);
c->current_job = avctx->thread_count;
-c->job_count = job_count;
-c->job_size = job_size;
+c->job_count = FFMIN(job_count, avctx->thread_count);
+c->subjob_offsets[0] = 0;
+c->subjob_limits[0] = (job_count / c->job_count) + (job_count %
c->job_count);
+for (i = 1; i < c->job_count; i++) {
+c->subjob_offsets[i] = c->subjob_limits[i-1];
+c->subjob_limits[i] = c->subjob_offsets[i] + (job_count /
c->job_count);
+}
+c->subjob_size = job_size;
c->args = arg;
c->func = func;
if (ret) {
@@ -218,17 +231,29 @@ int ff_slice_thread_init(AVCodecContext *avctx)
av_free(c);
return -1;
}
+c->subjob_offsets = av_mallocz_array(thread_count, sizeof(int));
+if (!c->subjob_offsets) {
+av_free(c);
+return -1;
+}
+c->subjob_limits = av_mallocz_array(thread_count, sizeof(int));
+if (!c->subjob_limits) {
+av_free(c);
+return -1;
+}
+
avctx->internal->thread_ctx = c;
c->current_job = 0;
c->job_count = 0;
-c->job_size = 0;
+c->subjob_size = 0;
c->done = 0;
pthread_cond_init(&c->current_job_cond, NULL);
pthread_cond_init(&c->last_job_cond, NULL);
pthread_mutex_init(&c->current_job_lock, NULL);
pthread_mutex_lock(&c->current_job_lock);
for (i=0; isubjob_limits[i] = c->subjob_offsets[i] = 0;
if(pthread_create(&c->workers[i], NULL, worker, avctx)) {
avctx->thread_count = i;
pthread_mutex_unlock(&c->current_job_lock);
--
2.3.2 (Apple Git-55)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: discard packets correctly
On Mon, Jul 13, 2015 at 12:02 PM, Michael Niedermayer wrote: > On Mon, Jul 13, 2015 at 09:32:06AM -0400, Ganesh Ajjanagadde wrote: >> On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer >> wrote: >> > On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: >> >> libav commit 13f6917c merged in 574dcb5b results in >> >> unnecessary seeks due to discarded packets; >> >> especially problematic over a network. >> >> >> >> Fixes Ticket4126 >> >> >> >> Signed-off-by: Ganesh Ajjanagadde >> >> --- >> >> ffmpeg_opt.c | 10 +++--- >> >> 1 file changed, 7 insertions(+), 3 deletions(-) >> > >> > i dont think that not marking streams for discarding can be correct >> > to fix a speed regression. >> > >> > Reading should not become significantly slower in a >> > real world (non constructed) case when a stream is marked as discard >> > >> > See short_seek_threshold, maybe it can be adjusted for http or >> > network protocols or maybe ff_configure_buffers_for_index() could >> > adjust things to avoid seeks for discarded streams >> > >> > A fix purely in ffmpeg_opt also has the disadvanatge that it would >> > not help any other applications which use libavformat with discarded >> > streams >> >> Before I dive deeper into this, I have a few comments and questions: >> 1. I tested against not just the example in the ticket, >> but also against random test files obtained at >> http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm; >> I don't know whether these are close enough to real world examples. >> It therefore seems like reading (without above patch) does become >> significantly slower for at least mp4 files delivered over http. >> Basically, there are a huge number of redundant partial chunk http requests, >> due to seeks that don't fall within existing buffers as they have been >> discarded. > > yes > > >> >> 2. I used the above simple fix as libav commit 13f6917c >> did not offer any clear reason as to what was being fixed >> (on the mailing list archive): >> https://lists.libav.org/pipermail/libav-devel/2012-February/022525.html >> https://lists.libav.org/pipermail/libav-devel/2012-February/022527.html >> beyond "useful for debugging" and "not return packets for streams we >> are not interested in". >> Can someone give me a clearer reason or concrete use case >> where the above libav commit did something beneficial? > > in a network protocol where streams can be disabled so they are not > transmitted enabling all streams would be a problem due to possibly > significantly increased bandwidth usage. > i do not know if the commit actually did help this case but > simply not using a feature is not fixing a bug in that feature. > even if we revert that commit, there still would be a problem > with http and disabled streams The irony is that the commit on first glance would decrease network usage due to the disabled stream. However, in reality, the only observed effect right now (at least for me) is an increased network usage (precisely responsible for the slowdown). This requires further investigation as you pointed out. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > In a rich man's house there is no place to spit but his face. > -- Diogenes of Sinope > > ___ > 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] [PATCH] ffmpeg_opt: discard packets correctly
On Mon, Jul 13, 2015 at 09:32:06AM -0400, Ganesh Ajjanagadde wrote: > On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer > wrote: > > On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: > >> libav commit 13f6917c merged in 574dcb5b results in > >> unnecessary seeks due to discarded packets; > >> especially problematic over a network. > >> > >> Fixes Ticket4126 > >> > >> Signed-off-by: Ganesh Ajjanagadde > >> --- > >> ffmpeg_opt.c | 10 +++--- > >> 1 file changed, 7 insertions(+), 3 deletions(-) > > > > i dont think that not marking streams for discarding can be correct > > to fix a speed regression. > > > > Reading should not become significantly slower in a > > real world (non constructed) case when a stream is marked as discard > > > > See short_seek_threshold, maybe it can be adjusted for http or > > network protocols or maybe ff_configure_buffers_for_index() could > > adjust things to avoid seeks for discarded streams > > > > A fix purely in ffmpeg_opt also has the disadvanatge that it would > > not help any other applications which use libavformat with discarded > > streams > > Before I dive deeper into this, I have a few comments and questions: > 1. I tested against not just the example in the ticket, > but also against random test files obtained at > http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm; > I don't know whether these are close enough to real world examples. > It therefore seems like reading (without above patch) does become > significantly slower for at least mp4 files delivered over http. > Basically, there are a huge number of redundant partial chunk http requests, > due to seeks that don't fall within existing buffers as they have been > discarded. yes > > 2. I used the above simple fix as libav commit 13f6917c > did not offer any clear reason as to what was being fixed > (on the mailing list archive): > https://lists.libav.org/pipermail/libav-devel/2012-February/022525.html > https://lists.libav.org/pipermail/libav-devel/2012-February/022527.html > beyond "useful for debugging" and "not return packets for streams we > are not interested in". > Can someone give me a clearer reason or concrete use case > where the above libav commit did something beneficial? in a network protocol where streams can be disabled so they are not transmitted enabling all streams would be a problem due to possibly significantly increased bandwidth usage. i do not know if the commit actually did help this case but simply not using a feature is not fixing a bug in that feature. even if we revert that commit, there still would be a problem with http and disabled streams [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] libavcodec/qsv.c: Issue fixed: QSV engine does not release display handler under linux platform.
Hello All, Current QSV engine implementation does allocate but never does release a display handler under linux platforms. The attached patch solved this issue, please review. -- Best regards, Ivan mailto:ivan.us...@nablet.com 0001-libavcodec-qsv.c-Issue-fixed-QSV-engine-does-not-rel.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: discard packets correctly
On Mon, Jul 13, 2015 at 7:11 AM, Michael Niedermayer wrote: > On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: >> libav commit 13f6917c merged in 574dcb5b results in >> unnecessary seeks due to discarded packets; >> especially problematic over a network. >> >> Fixes Ticket4126 >> >> Signed-off-by: Ganesh Ajjanagadde >> --- >> ffmpeg_opt.c | 10 +++--- >> 1 file changed, 7 insertions(+), 3 deletions(-) > > i dont think that not marking streams for discarding can be correct > to fix a speed regression. > > Reading should not become significantly slower in a > real world (non constructed) case when a stream is marked as discard > > See short_seek_threshold, maybe it can be adjusted for http or > network protocols or maybe ff_configure_buffers_for_index() could > adjust things to avoid seeks for discarded streams > > A fix purely in ffmpeg_opt also has the disadvanatge that it would > not help any other applications which use libavformat with discarded > streams Before I dive deeper into this, I have a few comments and questions: 1. I tested against not just the example in the ticket, but also against random test files obtained at http://download.wavetlan.com/SVV/Media/HTTP/http-mp4.htm; I don't know whether these are close enough to real world examples. It therefore seems like reading (without above patch) does become significantly slower for at least mp4 files delivered over http. Basically, there are a huge number of redundant partial chunk http requests, due to seeks that don't fall within existing buffers as they have been discarded. 2. I used the above simple fix as libav commit 13f6917c did not offer any clear reason as to what was being fixed (on the mailing list archive): https://lists.libav.org/pipermail/libav-devel/2012-February/022525.html https://lists.libav.org/pipermail/libav-devel/2012-February/022527.html beyond "useful for debugging" and "not return packets for streams we are not interested in". Can someone give me a clearer reason or concrete use case where the above libav commit did something beneficial? > > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User > questions about the command line tools should be sent to the ffmpeg-user ML. > And questions about how to use libav* should be sent to the libav-user ML. > > ___ > 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] vlc0.8.6i contrib ffmpeg losing swscale.h
On Mon, Jul 13, 2015 at 01:05:30PM +0800, 朱文澔 wrote: > Hi All: > for learning vlc source, I'm try build vlc0.8.6i(stable version) > but while building ffmpeg0.4.8, which lose source code for swscale.h we have 2015! these are versions are 12 years old [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] vlc0.8.6i contrib ffmpeg losing swscale.h
Hi All: for learning vlc source, I'm try build vlc0.8.6i(stable version) but while building ffmpeg0.4.8, which lose source code for swscale.h which version of libswscale, I should find. thanks! vvrobin...@163.com ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Controlling the server reply (was: 9/9] doc/example: Add http multi-client) example code
Le quartidi 24 messidor, an CCXXIII, Stephan Holljes a écrit : > the best thing I thought of was some kind of generic communication > function that either uses the client's AVOption system to pass around > values or just uses an AVDictionary. > Giving the application access to the results of the library could be > done in a similar way it is being done in http_read_header() by > repeatedly calling the communicate function and checking for its error > code (return < 0 in case of error, > 0 in case of success, but > unfinished processing and 0 on success and finished processing.) Since > we have to deal with protocol-specific decisions, each protocol should > implement its own communication function with something like a > url_comm_params() function added to the URLProtocol struct, which is > called like most (all?) other URLProtocol functions with > ffurl_comm_params() and avio_comm_params(). I'm not really sure how to > tell the application what parameters were negotiated, but maybe this > can be done in a similar fashion it has been done with unused_opts, > but instead with used_opts. This is more or less what I had in mind. To hold the options, I believe the AVOption system is better, because it has types: using AVDictionary would require converting everything to strings. Furthermore, AVOption object have inheritance, that can be used to access parameters in nested protocols: if the HTTP context inherits from the TCP context, getting the IP address is transparent; the same applies to TLS parameters with appropriate inheritance. As for the communication function, I believe it can just be url_handshake() / avio_handshake(). In other words: if avio_handshake() returns 0 that means the handshake is finished, it if returns >0 that means the handshake has progressed by one step but is not finished, and of course <0 means error. (We could try maintaining the convention that the return value is decreasing: 2+x for the underlying protocol, 1 during the headers. I am not sure if this would be very useful. It may also be a bit of trouble to maintain if the underlying protocol handshake is not the first step or if there are several underlying protocols, but I suspect these cases will not happen.) As for notifying the application of received parameters: this is not speed-critical, so the application could just repeatedly check if the option is still NULL or any corresponding default value. Does that sound ok to you? Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Need help with threading issue (possible deadlock?)
Hi, On Mon, Jul 13, 2015 at 7:15 AM, Donny Yang wrote: > On 13 July 2015 at 20:50, Ronald S. Bultje wrote: > > > Hi, > > > > On Mon, Jul 13, 2015 at 4:26 AM, Donny Yang wrote: > > > > > Hello > > > > > > I'm trying to fix ffmpeg's APNG decoding for images with the PREVIOUS > > > dispose op while trying to keep it multithreaded, but it seems to > > deadlock > > > whenever I use more that one thread. > > > > > > How do I reproduce? ffmpeg -threads 2 -i test.apng -f null - works for > me. > > So does ffplay -threads 2 test.apng > > > > It hangs for me when I run: ffmpeg -threads 2 -i test.apng test_%02d.png > Additionally, ffmpeg -threads 2 -i test.apng -f null - also hangs. > > Maybe it's due to system differences? Can you run it in gdb and - when it hangs - press ctrl-c and run "thread apply all bt"? We can also do some more interactive debugging on IRC. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: clean whitespace with [:space:]
On Mon, Jul 13, 2015 at 04:29:28PM +0800, Zhang Rui wrote: > Gmail seems do not recognize 'in-reply-to' > Previous patch is here: > http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175291.html > > With NDKr10e on Cygwin, CC_IDENT is defined as > #define CC_IDENT "gcc 4.8 \r(GCC)" applied with this added to the commit message [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB You can kill me, but you cannot change the truth. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Need help with threading issue (possible deadlock?)
On 13 July 2015 at 20:50, Ronald S. Bultje wrote: > Hi, > > On Mon, Jul 13, 2015 at 4:26 AM, Donny Yang wrote: > > > Hello > > > > I'm trying to fix ffmpeg's APNG decoding for images with the PREVIOUS > > dispose op while trying to keep it multithreaded, but it seems to > deadlock > > whenever I use more that one thread. > > > How do I reproduce? ffmpeg -threads 2 -i test.apng -f null - works for me. > So does ffplay -threads 2 test.apng > It hangs for me when I run: ffmpeg -threads 2 -i test.apng test_%02d.png Additionally, ffmpeg -threads 2 -i test.apng -f null - also hangs. Maybe it's due to system differences? I've also attached some debug output, if it helps $ uname -a Linux home 3.19.0-22-generic #22~14.04.1-Ubuntu SMP Wed Jun 17 10:03:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux $ ldd ffmpeg linux-vdso.so.1 => (0x7ffd5727a000) libXv.so.1 => /usr/lib/x86_64-linux-gnu/libXv.so.1 (0x7fc939451000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x7fc93911c000) libXext.so.6 => /usr/lib/x86_64-linux-gnu/libXext.so.6 (0x7fc938f0a000) libva.so.1 => /usr/lib/x86_64-linux-gnu/libva.so.1 (0x7fc938cf4000) libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x7fc938ad5000) libxcb-shm.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shm.so.0 (0x7fc9388d2000) libxcb-xfixes.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-xfixes.so.0 (0x7fc9386cb000) libxcb-shape.so.0 => /usr/lib/x86_64-linux-gnu/libxcb-shape.so.0 (0x7fc9384c7000) libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x7fc9381d7000) libSDL-1.2.so.0 => /usr/lib/x86_64-linux-gnu/libSDL-1.2.so.0 (0x7fc937f41000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7fc937c3b000) liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x7fc937a19000) libbz2.so.1.0 => /lib/x86_64-linux-gnu/libbz2.so.1.0 (0x7fc937809000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x7fc9375f) libvdpau.so.1 => /usr/lib/x86_64-linux-gnu/libvdpau.so.1 (0x7fc9373ec000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x7fc9371ce000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7fc936e09000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x7fc936c05000) libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x7fc936a01000) libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x7fc9367fb000) librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x7fc9365f3000) /lib64/ld-linux-x86-64.so.2 (0x7fc939656000) libpulse-simple.so.0 => /usr/lib/x86_64-linux-gnu/libpulse-simple.so.0 (0x7fc9363ef000) libpulse.so.0 => /usr/lib/x86_64-linux-gnu/libpulse.so.0 (0x7fc9361a6000) libcaca.so.0 => /usr/lib/x86_64-linux-gnu/libcaca.so.0 (0x7fc935ed9000) libpulsecommon-4.0.so => /usr/lib/x86_64-linux-gnu/pulseaudio/ libpulsecommon-4.0.so (0x7fc935c72000) libjson-c.so.2 => /lib/x86_64-linux-gnu/libjson-c.so.2 (0x7fc935a67000) libdbus-1.so.3 => /lib/x86_64-linux-gnu/libdbus-1.so.3 (0x7fc935822000) libslang.so.2 => /lib/x86_64-linux-gnu/libslang.so.2 (0x7fc935492000) libncursesw.so.5 => /lib/x86_64-linux-gnu/libncursesw.so.5 (0x7fc93525e000) libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x7fc935035000) libwrap.so.0 => /lib/x86_64-linux-gnu/libwrap.so.0 (0x7fc934e2b000) libsndfile.so.1 => /usr/lib/x86_64-linux-gnu/libsndfile.so.1 (0x7fc934bc3000) libasyncns.so.0 => /usr/lib/x86_64-linux-gnu/libasyncns.so.0 (0x7fc9349bd000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x7fc9347a3000) libFLAC.so.8 => /usr/lib/x86_64-linux-gnu/libFLAC.so.8 (0x7fc934572000) libvorbisenc.so.2 => /usr/lib/x86_64-linux-gnu/libvorbisenc.so.2 (0x7fc9340a3000) libvorbis.so.0 => /usr/lib/x86_64-linux-gnu/libvorbis.so.0 (0x7fc933e76000) libogg.so.0 => /usr/lib/x86_64-linux-gnu/libogg.so.0 (0x7fc933c6d000) libresolv.so.2 => /lib/x86_64-linux-gnu/libresolv.so.2 (0x7fc933a52000) log Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg_opt: discard packets correctly
On Mon, Jul 13, 2015 at 02:44:00AM -0400, Ganesh Ajjanagadde wrote: > libav commit 13f6917c merged in 574dcb5b results in > unnecessary seeks due to discarded packets; > especially problematic over a network. > > Fixes Ticket4126 > > Signed-off-by: Ganesh Ajjanagadde > --- > ffmpeg_opt.c | 10 +++--- > 1 file changed, 7 insertions(+), 3 deletions(-) i dont think that not marking streams for discarding can be correct to fix a speed regression. Reading should not become significantly slower in a real world (non constructed) case when a stream is marked as discard See short_seek_threshold, maybe it can be adjusted for http or network protocols or maybe ff_configure_buffers_for_index() could adjust things to avoid seeks for discarded streams A fix purely in ffmpeg_opt also has the disadvanatge that it would not help any other applications which use libavformat with discarded streams [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: clean whitespace with [:space:]
Zhang Rui gmail.com> writes:
> cleanws(){
> -echo "$ " | sed 's/^ *//;s/ */ /g;s/ *$//;s/\\r//g'
> +echo "$ " | sed "s/^ *//;s/[[:space:]][[:space:]]*/ /g;s/ *$//"
If this fixes compiler X on Y, please mention this
in the commit message.
(The link to wikibooks seems less important to me.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Need help with threading issue (possible deadlock?)
Hi, On Mon, Jul 13, 2015 at 4:26 AM, Donny Yang wrote: > Hello > > I'm trying to fix ffmpeg's APNG decoding for images with the PREVIOUS > dispose op while trying to keep it multithreaded, but it seems to deadlock > whenever I use more that one thread. How do I reproduce? ffmpeg -threads 2 -i test.apng -f null - works for me. So does ffplay -threads 2 test.apng Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: Use ff_configure_buffers_for_index()
On Tue, Jun 02, 2015 at 06:40:55PM +0200, Michael Niedermayer wrote: > Fixes Ticket2513 > Fixes Ticket4432 > > Signed-off-by: Michael Niedermayer > --- > libavformat/mov.c |1 + > 1 file changed, 1 insertion(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avformat: Add ff_configure_buffers_for_index()
On Tue, Jun 02, 2015 at 06:40:54PM +0200, Michael Niedermayer wrote: > This allows configuring the io buffer in such way that few seeks are needed > for playback > > Signed-off-by: Michael Niedermayer > --- > libavformat/internal.h |2 ++ > libavformat/utils.c| 38 ++ > 2 files changed, 40 insertions(+) applied [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Observe your enemies, for they first find out your faults. -- Antisthenes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: clean whitespace with [:space:]
Gmail seems do not recognize 'in-reply-to' Previous patch is here: http://ffmpeg.org/pipermail/ffmpeg-devel/2015-July/175291.html With NDKr10e on Cygwin, CC_IDENT is defined as #define CC_IDENT "gcc 4.8 \r(GCC)" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] Need help with threading issue (possible deadlock?)
Hello
I'm trying to fix ffmpeg's APNG decoding for images with the PREVIOUS
dispose op while trying to keep it multithreaded, but it seems to deadlock
whenever I use more that one thread.
Is there something obvious I'm missing, or otherwise misunderstanding how
ffmpeg's threads work?
Or should I just disable threading?
PS. I already asked my GSoC mentor about this and he said to disable
threading, but I submitted a patch a while ago to disable threading and
another dev was against that.
From f801fd3934f83d0bc0edf389a50967207c6be168 Mon Sep 17 00:00:00 2001
From: Donny Yang
Date: Mon, 13 Jul 2015 18:19:52 +1000
Subject: [PATCH] [WIP] apng: Fix decoding images with the PREVIOUS dispose op
---
libavcodec/pngdec.c | 47 +++
1 file changed, 27 insertions(+), 20 deletions(-)
diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 60c4975..525e340 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -643,6 +643,11 @@ static int decode_idat_chunk(AVCodecContext *avctx, PNGDecContext *s,
if ((ret = ff_thread_get_buffer(avctx, &s->picture, AV_GET_BUFFER_FLAG_REF)) < 0)
return ret;
+if (avctx->codec_id == AV_CODEC_ID_APNG && s->dispose_op != APNG_DISPOSE_OP_PREVIOUS) {
+ff_thread_release_buffer(avctx, &s->previous_picture);
+if ((ret = ff_thread_get_buffer(avctx, &s->previous_picture, AV_GET_BUFFER_FLAG_REF)) < 0)
+return ret;
+}
ff_thread_finish_setup(avctx);
p->pict_type= AV_PICTURE_TYPE_I;
@@ -917,20 +922,20 @@ static int handle_p_frame_apng(AVCodecContext *avctx, PNGDecContext *s,
return AVERROR_PATCHWELCOME;
}
-// Copy the previous frame to the buffer
-ff_thread_await_progress(&s->last_picture, INT_MAX, 0);
-memcpy(buffer, s->last_picture.f->data[0], s->image_linesize * s->height);
-
// Do the disposal operation specified by the last frame on the frame
-if (s->last_dispose_op == APNG_DISPOSE_OP_BACKGROUND) {
-for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y)
-memset(buffer + s->image_linesize * y + s->bpp * s->last_x_offset, 0, s->bpp * s->last_w);
-} else if (s->last_dispose_op == APNG_DISPOSE_OP_PREVIOUS) {
+if (s->last_dispose_op != APNG_DISPOSE_OP_PREVIOUS) {
+ff_thread_await_progress(&s->last_picture, INT_MAX, 0);
+memcpy(buffer, s->last_picture.f->data[0], s->image_linesize * s->height);
+
+if (s->last_dispose_op == APNG_DISPOSE_OP_BACKGROUND)
+for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y)
+memset(buffer + s->image_linesize * y + s->bpp * s->last_x_offset, 0, s->bpp * s->last_w);
+
+memcpy(s->previous_picture.f->data[0], buffer, s->image_linesize * s->height);
+ff_thread_report_progress(&s->previous_picture, INT_MAX, 0);
+} else {
ff_thread_await_progress(&s->previous_picture, INT_MAX, 0);
-for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; ++y) {
-size_t row_start = s->image_linesize * y + s->bpp * s->last_x_offset;
-memcpy(buffer + row_start, s->previous_picture.f->data[0] + row_start, s->bpp * s->last_w);
-}
+memcpy(buffer, s->previous_picture.f->data[0], s->image_linesize * s->height);
}
// Perform blending
@@ -1206,13 +1211,9 @@ static int decode_frame_apng(AVCodecContext *avctx,
PNGDecContext *const s = avctx->priv_data;
int ret;
AVFrame *p;
-ThreadFrame tmp;
-ff_thread_release_buffer(avctx, &s->previous_picture);
-tmp = s->previous_picture;
-s->previous_picture = s->last_picture;
-s->last_picture = s->picture;
-s->picture = tmp;
+ff_thread_release_buffer(avctx, &s->last_picture);
+FFSWAP(ThreadFrame, s->picture, s->last_picture);
p = s->picture.f;
if (!(s->state & PNG_IHDR)) {
@@ -1291,8 +1292,14 @@ static int update_thread_context(AVCodecContext *dst, const AVCodecContext *src)
pdst->state |= psrc->state & (PNG_IHDR | PNG_PLTE);
ff_thread_release_buffer(dst, &pdst->last_picture);
-if (psrc->last_picture.f->data[0])
-return ff_thread_ref_frame(&pdst->last_picture, &psrc->last_picture);
+if (psrc->last_picture.f->data[0] &&
+(ret = ff_thread_ref_frame(&pdst->last_picture, &psrc->last_picture)) < 0)
+return ret;
+
+ff_thread_release_buffer(dst, &pdst->previous_picture);
+if (psrc->previous_picture.f->data[0] &&
+(ret = ff_thread_ref_frame(&pdst->previous_picture, &psrc->previous_picture)) < 0)
+return ret;
}
return 0;
--
2.4.5
test.apng
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: clean whitespace with [:space:]
https://en.wikibooks.org/wiki/Regular_Expressions/POSIX_Basic_Regular_Expressions
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index cc23991..2e54930 100755
--- a/configure
+++ b/configure
@@ -476,7 +476,7 @@ sh_quote(){
}
cleanws(){
-echo "$@" | sed 's/^ *//;s/ */ /g;s/ *$//;s/\\r//g'
+echo "$@" | sed "s/^ *//;s/[[:space:]][[:space:]]*/ /g;s/ *$//"
}
filter(){
--
2.0.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] apng: Fix wrong default final frame delay in muxer
---
libavformat/apngenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/apngenc.c b/libavformat/apngenc.c
index dcf6b90..9b2c634 100644
--- a/libavformat/apngenc.c
+++ b/libavformat/apngenc.c
@@ -173,7 +173,7 @@ static void flush_packet(AVFormatContext *format_context,
AVPacket *packet)
"Frame rate is too high or specified too
precisely. Unable to copy losslessly.\n");
apng->framerate_warned = 1;
}
-} else if (apng->last_delay.den > 0) {
+} else if (apng->last_delay.num > 0) {
delay = apng->last_delay;
} else {
delay = apng->prev_delay;
--
2.4.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] apng: Support inter-frame compression
The current algorithm is just "try all the combinations, and pick the best".
It's not very fast either, probably due to a lot of copying, but will do for
an initial implementation.
---
libavcodec/pngenc.c | 423 +++-
1 file changed, 387 insertions(+), 36 deletions(-)
diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
index 7a9d0b0..c78c8dc 100644
--- a/libavcodec/pngenc.c
+++ b/libavcodec/pngenc.c
@@ -36,6 +36,14 @@
#define IOBUF_SIZE 4096
+typedef struct APNGFctlChunk {
+uint32_t sequence_number;
+uint32_t width, height;
+uint32_t x_offset, y_offset;
+uint16_t delay_num, delay_den;
+uint8_t dispose_op, blend_op;
+} APNGFctlChunk;
+
typedef struct PNGEncContext {
AVClass *class;
HuffYUVEncDSPContext hdsp;
@@ -59,6 +67,12 @@ typedef struct PNGEncContext {
// APNG
uint32_t palette_checksum; // Used to ensure a single unique palette
uint32_t sequence_number;
+
+AVFrame *prev_frame;
+AVFrame *last_frame;
+APNGFctlChunk last_frame_fctl;
+uint8_t *last_frame_packet;
+size_t last_frame_packet_size;
} PNGEncContext;
static void png_get_interlaced_row(uint8_t *dst, int row_size,
@@ -403,7 +417,7 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
uint8_t *progressive_buf = NULL;
uint8_t *top_buf = NULL;
-row_size = (avctx->width * s->bits_per_pixel + 7) >> 3;
+row_size = (pict->width * s->bits_per_pixel + 7) >> 3;
crow_base = av_malloc((row_size + 32) << (s->filter_type ==
PNG_FILTER_VALUE_MIXED));
if (!crow_base) {
@@ -430,16 +444,16 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
for (pass = 0; pass < NB_PASSES; pass++) {
/* NOTE: a pass is completely omitted if no pixels would be
* output */
-pass_row_size = ff_png_pass_row_size(pass, s->bits_per_pixel,
avctx->width);
+pass_row_size = ff_png_pass_row_size(pass, s->bits_per_pixel,
pict->width);
if (pass_row_size > 0) {
top = NULL;
-for (y = 0; y < avctx->height; y++)
+for (y = 0; y < pict->height; y++)
if ((ff_png_pass_ymask[pass] << (y & 7)) & 0x80) {
ptr = p->data[0] + y * p->linesize[0];
FFSWAP(uint8_t *, progressive_buf, top_buf);
png_get_interlaced_row(progressive_buf, pass_row_size,
s->bits_per_pixel, pass,
- ptr, avctx->width);
+ ptr, pict->width);
crow = png_choose_filter(s, crow_buf, progressive_buf,
top, pass_row_size,
s->bits_per_pixel >> 3);
png_write_row(avctx, crow, pass_row_size + 1);
@@ -449,7 +463,7 @@ static int encode_frame(AVCodecContext *avctx, const
AVFrame *pict)
}
} else {
top = NULL;
-for (y = 0; y < avctx->height; y++) {
+for (y = 0; y < pict->height; y++) {
ptr = p->data[0] + y * p->linesize[0];
crow = png_choose_filter(s, crow_buf, ptr, top,
row_size, s->bits_per_pixel >> 3);
@@ -530,6 +544,275 @@ static int encode_png(AVCodecContext *avctx, AVPacket
*pkt,
return 0;
}
+static int apng_do_inverse_blend(AVFrame *output, const AVFrame *input,
+ APNGFctlChunk *fctl_chunk, uint8_t bpp)
+{
+// output: background, input: foreground
+// output the image such that when blended with the background, will
produce the foreground
+
+uint32_t x, y;
+uint32_t leftmost_x = input->width;
+uint32_t rightmost_x = 0;
+uint32_t topmost_y = input->height;
+uint32_t bottommost_y = 0;
+const uint8_t *input_data = input->data[0];
+uint8_t *output_data = output->data[0];
+size_t input_linesize = input->linesize[0];
+size_t output_linesize;
+
+// Find bounding box of changes
+for (y = 0; y < input->height; ++y) {
+for (x = 0; x < input->width; ++x) {
+if (!memcmp(input_data + bpp * x, output_data + bpp * x, bpp))
+continue;
+
+if (x < leftmost_x)
+leftmost_x = x;
+if (x >= rightmost_x)
+rightmost_x = x + 1;
+if (y < topmost_y)
+topmost_y = y;
+if (y >= bottommost_y)
+bottommost_y = y + 1;
+}
+
+input_data += input_linesize;
+output_data += input_linesize;
+}
+
+if (leftmost_x == input->width && rightmost_x == 0) {
+// Empty frame
+// APNG does not support empty frames, so we make it a 1x1 frame
+leftmost_x = topmost_y = 0;
+rightmost_x = bottommost_y = 1;
+}
+
+output_linesize = FFALIGN(o
Re: [FFmpeg-devel] [PATCH 4/4] avcodec: loongson optimized h264pred with mmi
> > building libavcodec/dca_parser.c with
> > -O0
> > fixes the fate-dca-core and fate-dca-xll failure
>
> looks like a compiler bug:
>
> @@ -66,6 +66,7 @@ static int dca_find_frame_end(DCAParseContext *pc1, const
> uint8_t *buf,
> for (i = 0; i < buf_size; i++) {
> state = (state << 8) | buf[i];
> if (IS_MARKER(state)) {
> +av_log(0,0, "MRK0 %d %LX %X %d %d\n", i, state,
> pc1->lastmarker,pc1->framesize, pc1->size);
> if (!pc1->lastmarker ||
> pc1->lastmarker == CORE_MARKER(state) ||
> pc1->lastmarker == DCA_SYNCWORD_SUBSTREAM) {
> @@ -75,6 +76,7 @@ static int dca_find_frame_end(DCAParseContext *pc1, const
> uint8_t *buf,
> else
> pc1->lastmarker = CORE_MARKER(state);
> i++;
> +av_log(0,0, "END0 %d %LX %X %d %d\n", i, state,
> pc1->lastmarker,pc1->framesize, pc1->size);
> break;
> }
> }
>
> I get this diff between working and not working:
>
> MRK0 5 7FFE8001FC3C 0 0 0
> END0 6 7FFE8001FC3C 7FFE8001 0 0
> END1 1011 7FFE8001FC3C 7FFE8001 0 1006
> dca_parse_params
> dca_parse_params END
> MRK0 5 7FFE8001FC3C 7FFE8001 1006 0
> -END0 6 7FFE8001FC3C 7FFE8001 1006 0
> ENF
> -END1 5 80007FFE8001FC3C 7FFE8001 1006 1006
>
>
> assuming this is really a compiler bug
> can you fix the compiler or where can i find a working "gcc" package ?
>
yes, i find out the bug in gcc. its -fexpensive-optimizations at levels -O2,
-O3, -Os.
-O0 and -O1 is ok for fate-dca test, because not include this option.
i am fixing up this bug, so please wait for few days.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
