[FFmpeg-devel] [PATCH] -- Convert decklink input module to use codecpar

[Felt, Patrick]

This patch converts decklink input to use codecpar.  There are still a couple 
of deprecated calls that I’m not sure what to do with.  They are both related 
to some logic around AVCodecContext.coded_frame.   I couldn’t find anywhere 
that really documented what that was, or where it was intended to move to.  I 
left the warnings on.


---
 libavdevice/decklink_dec.cpp | 50 +++-
 1 file changed, 22 insertions(+), 28 deletions(-)

diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 9d7dc97..1c305f3 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -249,9 +249,7 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 // Handle Video Frame
 if (videoFrame) {
 AVPacket pkt;
-AVCodecContext *c;
 av_init_packet();
-c = ctx->video_st->codec;
 if (ctx->frameCount % 25 == 0) {
 unsigned long long qsize = avpacket_queue_size(>queue);
 av_log(avctx, AV_LOG_DEBUG,
@@ -354,7 +352,6 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 }
 #endif

-c->frame_number++;
 if (avpacket_queue_put(>queue, ) < 0) {
 ++ctx->dropped;
 }
@@ -362,14 +359,12 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(

 // Handle Audio Frame
 if (audioFrame) {
-AVCodecContext *c;
 AVPacket pkt;
 BMDTimeValue audio_pts;
 av_init_packet();

-c = ctx->audio_st->codec;
 //hack among hacks
-pkt.size = audioFrame->GetSampleFrameCount() * 
ctx->audio_st->codec->channels * (16 / 8);
+pkt.size = audioFrame->GetSampleFrameCount() * 
ctx->audio_st->codecpar->channels * (16 / 8);
 audioFrame->GetBytes();
 audioFrame->GetPacketTime(_pts, ctx->audio_st->time_base.den);
 pkt.pts = audio_pts / ctx->audio_st->time_base.num;
@@ -386,7 +381,6 @@ HRESULT decklink_input_callback::VideoInputFrameArrived(
 pkt.stream_index = ctx->audio_st->index;
 pkt.data = (uint8_t *)audioFrameBytes;

-c->frame_number++;
 if (avpacket_queue_put(>queue, ) < 0) {
 ++ctx->dropped;
 }
@@ -551,10 +545,10 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
 av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
 goto error;
 }
-st->codec->codec_type  = AVMEDIA_TYPE_AUDIO;
-st->codec->codec_id= AV_CODEC_ID_PCM_S16LE;
-st->codec->sample_rate = bmdAudioSampleRate48kHz;
-st->codec->channels= cctx->audio_channels;
+st->codecpar->codec_type  = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id= AV_CODEC_ID_PCM_S16LE;
+st->codecpar->sample_rate = bmdAudioSampleRate48kHz;
+st->codecpar->channels= cctx->audio_channels;
 avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
 ctx->audio_st=st;

@@ -563,21 +557,21 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
 av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
 goto error;
 }
-st->codec->codec_type  = AVMEDIA_TYPE_VIDEO;
-st->codec->width   = ctx->bmd_width;
-st->codec->height  = ctx->bmd_height;
+st->codecpar->codec_type  = AVMEDIA_TYPE_VIDEO;
+st->codecpar->width   = ctx->bmd_width;
+st->codecpar->height  = ctx->bmd_height;

-st->codec->time_base.den  = ctx->bmd_tb_den;
-st->codec->time_base.num  = ctx->bmd_tb_num;
-st->codec->bit_rate= av_image_get_buffer_size(st->codec->pix_fmt, 
ctx->bmd_width, ctx->bmd_height, 1) * 1/av_q2d(st->codec->time_base) * 8;
+st->time_base.den  = ctx->bmd_tb_den;
+st->time_base.num  = ctx->bmd_tb_num;
+st->codecpar->bit_rate= 
av_image_get_buffer_size((AVPixelFormat)st->codecpar->format, ctx->bmd_width, 
ctx->bmd_height, 1) * 1/av_q2d(st->time_base) * 8;

 if (cctx->v210) {
-st->codec->codec_id= AV_CODEC_ID_V210;
-st->codec->codec_tag   = MKTAG('V', '2', '1', '0');
+st->codecpar->codec_id= AV_CODEC_ID_V210;
+st->codecpar->codec_tag   = MKTAG('V', '2', '1', '0');
 } else {
-st->codec->codec_id= AV_CODEC_ID_RAWVIDEO;
-st->codec->pix_fmt = AV_PIX_FMT_UYVY422;
-st->codec->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
+st->codecpar->codec_id= AV_CODEC_ID_RAWVIDEO;
+st->codecpar->format  = AV_PIX_FMT_UYVY422;
+st->codecpar->codec_tag   = MKTAG('U', 'Y', 'V', 'Y');
 }

 avpriv_set_pts_info(st, 64, 1, 100);  /* 64 bits pts in us */
@@ -590,16 +584,16 @@ av_cold int ff_decklink_read_header(AVFormatContext 
*avctx)
 av_log(avctx, AV_LOG_ERROR, "Cannot add stream\n");
 goto error;
 }
-st->codec->codec_type  = AVMEDIA_TYPE_SUBTITLE;
-st->codec->time_base.den  = ctx->bmd_tb_den;
-st->codec->time_base.num  = ctx->bmd_tb_num;
-st->codec->codec_id   

Re: [FFmpeg-devel] [PATCH] fate: Remove duplicate wmv8_x8intra.wmv test

[Michael Niedermayer]

On Sun, May 08, 2016 at 12:54:10AM +0100, Derek Buitenhuis wrote:
> On 5/8/2016 12:42 AM, Michael Niedermayer wrote:
> > Also temporary enable the test so we get updated fate failure statistics
> > 
> > Note, this does not work on all platforms, it fails on MIPS
> > and ml archives indicate it failed on x86 openbsd with some compilers as 
> > well
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  tests/fate/microsoft.mak|8 +-
> >  tests/ref/fate/wmv8-intrax8 |  475 
> > ---
> >  2 files changed, 2 insertions(+), 481 deletions(-)
> >  delete mode 100644 tests/ref/fate/wmv8-intrax8
> 
> Sounds good to me.

applied

thx

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

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

[Michael Niedermayer]

On Sat, May 07, 2016 at 06:12:43PM +0100, Rostislav Pehlivanov wrote:
> The problem is that with particularly complex images and especially at
> high bit depths and 5-level transforms the coefficients would overflow,
> causing huge artifacts to appear. This was discovered thanks to the fate
> tests, which will have to be redone as this fixes a multitude of
> problems and increases PSNR.
> 
> There is a slight performance drop associated with this change, making
> the encoder slower by 1.15 times, however this is necessary in order to
> avoid undefined behavior and overflows.
> 
> It would be worth to template the transforms to keep the performance for
> 8 bit images as 32 bit coefficients are unnecessary for that case, but
> the primary use of the encoder is to encode video at 10 bits.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/vc2enc_dwt.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

i guess things first should be correct and then be optimized so
LGTM

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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

Re: [FFmpeg-devel] [PATCH] fate: Remove duplicate wmv8_x8intra.wmv test

[Derek Buitenhuis]

On 5/8/2016 12:42 AM, Michael Niedermayer wrote:
> Also temporary enable the test so we get updated fate failure statistics
> 
> Note, this does not work on all platforms, it fails on MIPS
> and ml archives indicate it failed on x86 openbsd with some compilers as well
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  tests/fate/microsoft.mak|8 +-
>  tests/ref/fate/wmv8-intrax8 |  475 
> ---
>  2 files changed, 2 insertions(+), 481 deletions(-)
>  delete mode 100644 tests/ref/fate/wmv8-intrax8

Sounds good to me.

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

[FFmpeg-devel] [PATCH] fate: Remove duplicate wmv8_x8intra.wmv test

[Michael Niedermayer]

Also temporary enable the test so we get updated fate failure statistics

Note, this does not work on all platforms, it fails on MIPS
and ml archives indicate it failed on x86 openbsd with some compilers as well

Signed-off-by: Michael Niedermayer 
---
 tests/fate/microsoft.mak|8 +-
 tests/ref/fate/wmv8-intrax8 |  475 ---
 2 files changed, 2 insertions(+), 481 deletions(-)
 delete mode 100644 tests/ref/fate/wmv8-intrax8

diff --git a/tests/fate/microsoft.mak b/tests/fate/microsoft.mak
index c4af7d1..1d518d9 100644
--- a/tests/fate/microsoft.mak
+++ b/tests/fate/microsoft.mak
@@ -47,15 +47,11 @@ fate-wmv8-drm: CMD = framecrc -cryptokey 
137381538c84c068111902a59c5cf6c340247c3
 FATE_WMV8_DRM += fate-wmv8-drm-nodec
 fate-wmv8-drm-nodec: CMD = framecrc -cryptokey 
137381538c84c068111902a59c5cf6c340247c39 -i $(TARGET_SAMPLES)/wmv8/wmv_drm.wmv 
-acodec copy -vcodec copy
 
-#FATE_MICROSOFT += fate-wmv8-x8intra
-FATE_TESTS-no += fate-wmv8-x8intra
-fate-wmv8-x8intra: CMD = framecrc -flags +bitexact -idct 19 -i 
$(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv -an
-
 FATE_MICROSOFT-$(call DEMDEC, ASF, WMV3) += $(FATE_WMV8_DRM)
 fate-wmv8_drm: $(FATE_WMV8_DRM)
 
-FATE_SAMPLES_AVCONV-$(call DEMDEC, ASF, WMV2) += fate-wmv8-intrax8
-fate-wmv8-intrax8: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv -an
+FATE_MICROSOFT-$(call DEMDEC, ASF, WMV2) += fate-wmv8-x8intra
+fate-wmv8-x8intra: CMD = framecrc -flags +bitexact -i 
$(TARGET_SAMPLES)/wmv8/wmv8_x8intra.wmv -an
 
 FATE_VC1-$(CONFIG_VC1_DEMUXER) += fate-vc1_sa00040
 fate-vc1_sa00040: CMD = framecrc -i $(TARGET_SAMPLES)/vc1/SA00040.vc1
diff --git a/tests/ref/fate/wmv8-intrax8 b/tests/ref/fate/wmv8-intrax8
deleted file mode 100644
index 103e8da..000
--- a/tests/ref/fate/wmv8-intrax8
+++ /dev/null
@@ -1,475 +0,0 @@
-#tb 0: 1/1000
-0,  0,  0,0,   115200, 0x03fbd838
-0,200,200,0,   115200, 0x8911d86f
-0,266,266,0,   115200, 0x7c5dd82e
-0,333,333,0,   115200, 0x7c5ed82e
-0,   2000,   2000,0,   115200, 0xd323d838
-0,   2066,   2066,0,   115200, 0x6e7479ab
-0,   2133,   2133,0,   115200, 0x14674bf6
-0,   2200,   2200,0,   115200, 0x074c2e3d
-0,   2266,   2266,0,   115200, 0x9b3025ef
-0,   2333,   2333,0,   115200, 0x76882dae
-0,   2400,   2400,0,   115200, 0xedf3421b
-0,   2466,   2466,0,   115200, 0xb5378486
-0,   2533,   2533,0,   115200, 0xc4a53420
-0,   2600,   2600,0,   115200, 0x559cb60f
-0,   2666,   2666,0,   115200, 0xcc034ddd
-0,   2733,   2733,0,   115200, 0xb77b7779
-0,   2800,   2800,0,   115200, 0x0ad9c3e6
-0,   2866,   2866,0,   115200, 0x4e673027
-0,   2933,   2933,0,   115200, 0x54717979
-0,   3000,   3000,0,   115200, 0xf9e557c9
-0,   3066,   3066,0,   115200, 0xbdcf6358
-0,   3133,   3133,0,   115200, 0xd55c7bb7
-0,   3200,   3200,0,   115200, 0x78d171e7
-0,   3266,   3266,0,   115200, 0x28715816
-0,   ,   ,0,   115200, 0x58740b8a
-0,   3400,   3400,0,   115200, 0x86c10f18
-0,   3466,   3466,0,   115200, 0x903918f9
-0,   3533,   3533,0,   115200, 0x7f742394
-0,   3600,   3600,0,   115200, 0xd3a91d44
-0,   3666,   3666,0,   115200, 0x24452563
-0,   3733,   3733,0,   115200, 0x1b0c320e
-0,   3800,   3800,0,   115200, 0x3a493c8e
-0,   3866,   3866,0,   115200, 0xebe445ec
-0,   3933,   3933,0,   115200, 0xd2c54c8c
-0,   4000,   4000,0,   115200, 0x4aa15593
-0,   4066,   4066,0,   115200, 0x19a35cc1
-0,   4133,   4133,0,   115200, 0x968c6ee7
-0,   4200,   4200,0,   115200, 0x9f7c7808
-0,   4266,   4266,0,   115200, 0xa23980ee
-0,   4333,   4333,0,   115200, 0xcf3089c3
-0,   4400,   4400,0,   115200, 0x43f78d5c
-0,   4466,   4466,0,   115200, 0x43caa1d4
-0,   4533,   4533,0,   115200, 0x025594c3
-0,   4600,   4600,0,   115200, 0x5ec8a11c
-0,   4666,   4666,0,   115200, 0x7f2a959b
-0,   4733,   4733,0,   115200, 0xc602852d
-0,   4800,   4800,0,   115200, 0x67737ef5
-0,   4866,   4866,0,   115200, 0x81e06efe
-0,   4933,   4933,0,   115200, 0xdb0a484f
-0,   5000,   5000,0,   115200, 0xf30e4418
-0,   5066,   5066,0,   115200, 0xbdd1310d
-0,   5133,   5133,0,   115200, 0x0d2a58ca
-0,   5200,   5200,0,   

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Davinder Singh]

changed default value of  `frames` to zero, if `frames` option is not set,
it ignore and check only direction, this way all picture types are
considered if we are drawing MVs for ME, since there are more frame types
available.

On Sun, May 8, 2016 at 3:02 AM Moritz Barsnick  wrote:

> On Sat, May 07, 2016 at 19:48:31 +, Davinder Singh wrote:
>
> > -{ "frames", "set frame types to display MVs of", OFFSET(frames),
> AV_OPT_TYPE_FLAGS, {.i64=3}, 0, INT_MAX, FLAGS, "frames" },
> > +{ "frames", "set frame types to display MVs of", OFFSET(frames),
> AV_OPT_TYPE_FLAGS, {.i64=7}, 0, INT_MAX, FLAGS, "frames" },
>
>  ^
> This could be written symbolically to make its value more obvious.
>
> > -forward predicted MVs of P-frames
> > +predicted frames (p-frames)
> >  @item bf
> > -forward predicted MVs of B-frames
> > -@item bb
> > -backward predicted MVs of B-frames
> > +bi-directionally predicted frames (b-frames)
>
> Didn't you just introduce capitalization of B and P in the 0002 patch,
> and now drop it here?
>
> > +CONST("pf", "p-frames", FRAME_TYPE_P, "frames"),
> > +CONST("bf", "b-frames", FRAME_TYPE_B, "frames"),
>
> Same here.
>

it was in docs only. all capital now. :)


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


0003-vf_codecview-ignore-frame-types-ifnset.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Moritz Barsnick]

On Sat, May 07, 2016 at 19:48:31 +, Davinder Singh wrote:

> -{ "frames", "set frame types to display MVs of", OFFSET(frames), 
> AV_OPT_TYPE_FLAGS, {.i64=3}, 0, INT_MAX, FLAGS, "frames" },
> +{ "frames", "set frame types to display MVs of", OFFSET(frames), 
> AV_OPT_TYPE_FLAGS, {.i64=7}, 0, INT_MAX, FLAGS, "frames" },

   ^
This could be written symbolically to make its value more obvious.

> -forward predicted MVs of P-frames
> +predicted frames (p-frames)
>  @item bf
> -forward predicted MVs of B-frames
> -@item bb
> -backward predicted MVs of B-frames
> +bi-directionally predicted frames (b-frames)

Didn't you just introduce capitalization of B and P in the 0002 patch,
and now drop it here?

> +CONST("pf", "p-frames", FRAME_TYPE_P, "frames"),
> +CONST("bf", "b-frames", FRAME_TYPE_B, "frames"),

Same here.

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

Re: [FFmpeg-devel] [PATCH 3/4] x86: lossless audio: SSE4 madd 32bits

[Michael Niedermayer]

On Sat, May 07, 2016 at 05:58:21PM +0200, Paul B Mahol wrote:
> On 5/1/16, Christophe Gisquet  wrote:
> > The unique user so far is wmalossless 24bits. The few samples tested show an
> > order of 8, so more unrolling or an avx2 version do not make sense.
> >
> > Timings: 68 -> 49 cycles
> > ---
> >  libavcodec/x86/lossless_audiodsp.asm| 33
> > +
> >  libavcodec/x86/lossless_audiodsp_init.c |  7 +++
> >  2 files changed, 40 insertions(+)
> >
> > diff --git a/libavcodec/x86/lossless_audiodsp.asm
> > b/libavcodec/x86/lossless_audiodsp.asm
> > index 5597dad..063d7b4 100644
> > --- a/libavcodec/x86/lossless_audiodsp.asm
> > +++ b/libavcodec/x86/lossless_audiodsp.asm
> > @@ -68,6 +68,39 @@ SCALARPRODUCT
> >  INIT_XMM sse2
> >  SCALARPRODUCT
> >
> > +INIT_XMM sse4
> > +; int ff_scalarproduct_and_madd_int32(int16_t *v1, int32_t *v2, int16_t
> > *v3,
> > +; int order, int mul)
> > +cglobal scalarproduct_and_madd_int32, 4,4,8, v1, v2, v3, order, mul
> > +shl orderq, 1
> > +movdm7, mulm
> > +SPLATW  m7, m7
> > +pxorm6, m6
> > +add v1q, orderq
> > +lea v2q, [v2q + 2*orderq]
> > +add v3q, orderq
> > +neg orderq
> > +.loop:
> > +movam3, [v1q + orderq]
> > +movum0, [v2q + 2*orderq]
> > +pmovsxwd m4, m3
> > +movum1, [v2q + 2*orderq + mmsize]
> > +movhlps m5, m3
> > +movum2, [v3q + orderq]
> > +pmovsxwd m5, m5
> > +pmullw  m2, m7
> > +pmulld  m0, m4
> > +pmulld  m1, m5
> > +paddw   m2, m3
> > +paddd   m6, m0
> > +paddd   m6, m1
> > +mova[v1q + orderq], m2
> > +add orderq, 16
> > +jl .loop
> > +HADDD   m6, m0
> > +movd   eax, m6
> > +RET
> > +
> >  %macro SCALARPRODUCT_LOOP 1
> >  align 16
> >  .loop%1:
> > diff --git a/libavcodec/x86/lossless_audiodsp_init.c
> > b/libavcodec/x86/lossless_audiodsp_init.c
> > index 197173c..10b6a65 100644
> > --- a/libavcodec/x86/lossless_audiodsp_init.c
> > +++ b/libavcodec/x86/lossless_audiodsp_init.c
> > @@ -31,6 +31,10 @@ int32_t ff_scalarproduct_and_madd_int16_ssse3(int16_t
> > *v1, const int16_t *v2,
> >const int16_t *v3,
> >int order, int mul);
> >
> > +int32_t ff_scalarproduct_and_madd_int32_sse4(int16_t *v1, const int32_t
> > *v2,
> > + const int16_t *v3,
> > + int order, int mul);
> > +
> >  av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
> >  {
> >  #if HAVE_YASM
> > @@ -45,5 +49,8 @@ av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
> >  if (EXTERNAL_SSSE3(cpu_flags) &&
> >  !(cpu_flags & (AV_CPU_FLAG_SSE42 | AV_CPU_FLAG_3DNOW))) //
> > cachesplit
> >  c->scalarproduct_and_madd_int16 =
> > ff_scalarproduct_and_madd_int16_ssse3;
> > +
> > +if (EXTERNAL_SSE4(cpu_flags))
> > +c->scalarproduct_and_madd_int32 =
> > ff_scalarproduct_and_madd_int32_sse4;
> >  #endif
> >  }
> > --
> > 2.8.1
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> lgtm

applied

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

[Rostislav Pehlivanov]

On 7 May 2016 at 18:55, Christophe Gisquet 
wrote:

> 2016-05-07 19:12 GMT+02:00 Rostislav Pehlivanov :


> > There is a slight performance drop associated with this change, making
> > the encoder slower by 1.15 times, however this is necessary in order to
> > avoid undefined behavior and overflows.
>
> This means no asm has been written yet. Is the performance drop mostly
> in transforms, or rather any coefficient manipulation (like rate
> evaluation etc), or memory bandwidth?
> In the former case, it might be less critical in the future.
>
>
 The costliest part of the encoder right now is encoding the coefficients
(~36%). Slightly less-costly is rate control (~31%), and after that is the
transform (~12%). There really isn't anything else, other than 3 copies
(input image converted to signed and copied to a buffer, then because the
transform is out of place there's a copy to another buffer and then back),
but they don't take that much time.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH][libavfilter] codecview: improved options

[Davinder Singh]

separated motion vector types (forward or backward) from frame picture
types as MVs are associated with picture types only in video coding.

option `mv` can have two values:
forward predicted or backward predicted.

option `frames` can have three values:
p-frames, i-frames and b-frames.

ex:
only forward predicted mvs of all frames:
-vf codecview=mv=fp

mvs (both forward or backward predicted) of P or B-frames:
-vf codecview=mv=fp+bp:frames=pf+bf

Regards,
DSM_


0002-vf_codecview-added-i-frame-support.patch
Description: Binary data


0001-vf_codecview-improved-filter-options.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

[Christophe Gisquet]

2016-05-07 19:12 GMT+02:00 Rostislav Pehlivanov :
> The problem is that with particularly complex images and especially at
> high bit depths and 5-level transforms the coefficients would overflow

I guess it also depends on the transform type, so that counts also for
the last comment.

> causing huge artifacts to appear. This was discovered thanks to the fate
> tests, which will have to be redone as this fixes a multitude of
> problems and increases PSNR.

I admit I saw strange numbers, but as they sometime include color
transform forth and back, I didn't really pay attention.
Was there a risk it produced incorrect output in "valid" decoders?

> There is a slight performance drop associated with this change, making
> the encoder slower by 1.15 times, however this is necessary in order to
> avoid undefined behavior and overflows.

This means no asm has been written yet. Is the performance drop mostly
in transforms, or rather any coefficient manipulation (like rate
evaluation etc), or memory bandwidth?
In the former case, it might be less critical in the future.

> It would be worth to template the transforms to keep the performance for
> 8 bit images as 32 bit coefficients are unnecessary for that case, but
> the primary use of the encoder is to encode video at 10 bits.

I don't know what that entails, but indeed, there are several
parameters affecting what's possible, and the current change is the
simplest/fastest/safest at the moment.

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

[FFmpeg-devel] [PATCH] vc2enc_dwt: use 32 bit coefficients by default

[Rostislav Pehlivanov]

The problem is that with particularly complex images and especially at
high bit depths and 5-level transforms the coefficients would overflow,
causing huge artifacts to appear. This was discovered thanks to the fate
tests, which will have to be redone as this fixes a multitude of
problems and increases PSNR.

There is a slight performance drop associated with this change, making
the encoder slower by 1.15 times, however this is necessary in order to
avoid undefined behavior and overflows.

It would be worth to template the transforms to keep the performance for
8 bit images as 32 bit coefficients are unnecessary for that case, but
the primary use of the encoder is to encode video at 10 bits.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc_dwt.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vc2enc_dwt.h b/libavcodec/vc2enc_dwt.h
index af6fe3e..7fbbfbe 100644
--- a/libavcodec/vc2enc_dwt.h
+++ b/libavcodec/vc2enc_dwt.h
@@ -25,7 +25,7 @@
 #include 
 #include 
 
-typedef int16_t dwtcoef;
+typedef int32_t dwtcoef;
 
 enum VC2TransformType {
 VC2_TRANSFORM_9_7= 0,   /* Deslauriers-Dubuc (9,7)  */
-- 
2.8.1.369.geae769a

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

Re: [FFmpeg-devel] [PATCH 3/4] x86: lossless audio: SSE4 madd 32bits

[Paul B Mahol]

On 5/1/16, Christophe Gisquet  wrote:
> The unique user so far is wmalossless 24bits. The few samples tested show an
> order of 8, so more unrolling or an avx2 version do not make sense.
>
> Timings: 68 -> 49 cycles
> ---
>  libavcodec/x86/lossless_audiodsp.asm| 33
> +
>  libavcodec/x86/lossless_audiodsp_init.c |  7 +++
>  2 files changed, 40 insertions(+)
>
> diff --git a/libavcodec/x86/lossless_audiodsp.asm
> b/libavcodec/x86/lossless_audiodsp.asm
> index 5597dad..063d7b4 100644
> --- a/libavcodec/x86/lossless_audiodsp.asm
> +++ b/libavcodec/x86/lossless_audiodsp.asm
> @@ -68,6 +68,39 @@ SCALARPRODUCT
>  INIT_XMM sse2
>  SCALARPRODUCT
>
> +INIT_XMM sse4
> +; int ff_scalarproduct_and_madd_int32(int16_t *v1, int32_t *v2, int16_t
> *v3,
> +; int order, int mul)
> +cglobal scalarproduct_and_madd_int32, 4,4,8, v1, v2, v3, order, mul
> +shl orderq, 1
> +movdm7, mulm
> +SPLATW  m7, m7
> +pxorm6, m6
> +add v1q, orderq
> +lea v2q, [v2q + 2*orderq]
> +add v3q, orderq
> +neg orderq
> +.loop:
> +movam3, [v1q + orderq]
> +movum0, [v2q + 2*orderq]
> +pmovsxwd m4, m3
> +movum1, [v2q + 2*orderq + mmsize]
> +movhlps m5, m3
> +movum2, [v3q + orderq]
> +pmovsxwd m5, m5
> +pmullw  m2, m7
> +pmulld  m0, m4
> +pmulld  m1, m5
> +paddw   m2, m3
> +paddd   m6, m0
> +paddd   m6, m1
> +mova[v1q + orderq], m2
> +add orderq, 16
> +jl .loop
> +HADDD   m6, m0
> +movd   eax, m6
> +RET
> +
>  %macro SCALARPRODUCT_LOOP 1
>  align 16
>  .loop%1:
> diff --git a/libavcodec/x86/lossless_audiodsp_init.c
> b/libavcodec/x86/lossless_audiodsp_init.c
> index 197173c..10b6a65 100644
> --- a/libavcodec/x86/lossless_audiodsp_init.c
> +++ b/libavcodec/x86/lossless_audiodsp_init.c
> @@ -31,6 +31,10 @@ int32_t ff_scalarproduct_and_madd_int16_ssse3(int16_t
> *v1, const int16_t *v2,
>const int16_t *v3,
>int order, int mul);
>
> +int32_t ff_scalarproduct_and_madd_int32_sse4(int16_t *v1, const int32_t
> *v2,
> + const int16_t *v3,
> + int order, int mul);
> +
>  av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
>  {
>  #if HAVE_YASM
> @@ -45,5 +49,8 @@ av_cold void ff_llauddsp_init_x86(LLAudDSPContext *c)
>  if (EXTERNAL_SSSE3(cpu_flags) &&
>  !(cpu_flags & (AV_CPU_FLAG_SSE42 | AV_CPU_FLAG_3DNOW))) //
> cachesplit
>  c->scalarproduct_and_madd_int16 =
> ff_scalarproduct_and_madd_int16_ssse3;
> +
> +if (EXTERNAL_SSE4(cpu_flags))
> +c->scalarproduct_and_madd_int32 =
> ff_scalarproduct_and_madd_int32_sse4;
>  #endif
>  }
> --
> 2.8.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH] ffplay: force setting alsa buffer size

[Marton Balint]

On Sun, 1 May 2016, Reimar Döffinger wrote:


On Sat, Apr 30, 2016 at 10:17:33PM +0200, Marton Balint wrote:

Signed-off-by: Marton Balint 
---
 ffplay.c | 7 +++
 1 file changed, 7 insertions(+)


I have a nagging feeling someone with better knowledge
of ALSA and how we handle it might find a better solution,
but since I doubt someone will spend time on it, this
seems like an acceptable workaround to me.


Ok, thanks. Applied.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/tee: Use ref instead copy in write_packet

[Marton Balint]

On Thu, 5 May 2016, Nicolas George wrote:


Le quartidi 14 floréal, an CCXXIV, sebechlebsky...@gmail.com a écrit :

From: Jan Sebechlebsky 

Replace av_copy_packet and deprecated av_dup_packet by
creating reference using av_packet_ref.

Signed-off-by: Jan Sebechlebsky 
---
 This should be effectively the same as calling av_packet_clone,
 but without dynamic memory allocation (reuses local AVPacket pkt).

 libavformat/tee.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)


Looks right, thanks.


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/tee: Fix TeeSlave.bsfs pointer array size

[Marton Balint]

On Thu, 5 May 2016, Nicolas George wrote:


Le quintidi 15 floréal, an CCXXIV, sebechlebsky...@gmail.com a écrit :

From: Jan Sebechlebsky 

TeeSlave.bsfs is array of pointers to AVBitStreamFilterContext,
so element size should be really size of a pointer, not size
of TeeSlave structure.

Signed-off-by: Jan Sebechlebsky 


Ok for me, of course.


Applied, thanks.

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

Re: [FFmpeg-devel] [PATCH] avformat/riff: assign g721 and g723codec tags to g726 decoder

[compn]

On Sun, 01 May 2016 00:09:46 +0200
Piotr Bandurski  wrote:

> > > On Wed, 27 Apr 2016 20:39:34 +0200
> > Piotr Bandurski  wrote:
> > 
> > > Subject: [PATCH] avformat/riff: assign g721 and g723 codec tags to
> > > g726 decoder
> > 
> > > + { AV_CODEC_ID_ADPCM_G726, 0x0014 },
> > > + { AV_CODEC_ID_ADPCM_G726, 0x0040 },
> > 
> > i wonder if we should make a comment that these are different
> > codecs, in the unlikely eventuality that we split 721 723 and 726
> > decoders from one another?
> > 
> > > + { AV_CODEC_ID_ADPCM_G726, 0x0014 }, /* g723 Antex */
> > > + { AV_CODEC_ID_ADPCM_G726, 0x0040 }, /* g721 Antex */
> > 
> > ?
> 
> I'm ok with this change.

merged,

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