[FFmpeg-devel] [PATCH] Fix for H.264 configuration parsing

2016-04-12 Thread Ivan
Sometimes video fails to decode if H.264 configuration changes mid stream. The 
reason is that configuration parser assumes that nal_ref_idc is equal to 11b 
while actually some codecs but 01b there. The H.264 spec is somewhat vague 
about this but it looks like it allows any non-zero nal_ref_idc for sps/pps.

Signed-off-by: Ivan 
---
 libavcodec/h264.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index f1399b8..88768af 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
@@ -1781,7 +1781,7 @@ static int is_extra(const uint8_t *buf, int buf_size)
 const uint8_t *p= buf+6;
 while(cnt--){
 int nalsize= AV_RB16(p) + 2;
-if(nalsize > buf_size - (p-buf) || p[2]!=0x67)
+if(nalsize > buf_size - (p-buf) || (p[2] & 0x9F) != 7)
 return 0;
 p += nalsize;
 }
@@ -1790,7 +1790,7 @@ static int is_extra(const uint8_t *buf, int buf_size)
 return 0;
 while(cnt--){
 int nalsize= AV_RB16(p) + 2;
-if(nalsize > buf_size - (p-buf) || p[2]!=0x68)
+if(nalsize > buf_size - (p-buf) || (p[2] & 0x9F) != 8)
 return 0;
 p += nalsize;
 }
-- 
1.9.1

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


[FFmpeg-devel] [PATCH] avformat/flvenc: support codec config change mid stream

2016-06-09 Thread Ivan
Signed-off-by: Ivan 
---
 libavformat/flvenc.c | 130 ++-
 1 file changed, 78 insertions(+), 52 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index d62ff70..3536e9a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -343,12 +343,74 @@ static int unsupported_codec(AVFormatContext *s,
 return AVERROR(ENOSYS);
 }
 
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) 
{
+int64_t data_size;
+AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
+|| par->codec_id == AV_CODEC_ID_MPEG4) {
+int64_t pos;
+avio_w8(pb,
+par->codec_type == AVMEDIA_TYPE_VIDEO ?
+FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
+avio_wb24(pb, 0); // size patched later
+avio_wb24(pb, 0); // ts
+avio_w8(pb, 0);   // ts ext
+avio_wb24(pb, 0); // streamid
+pos = avio_tell(pb);
+if (par->codec_id == AV_CODEC_ID_AAC) {
+avio_w8(pb, get_audio_flags(s, par));
+avio_w8(pb, 0); // AAC sequence header
+
+if (!par->extradata_size && flv->flags & 1) {
+PutBitContext pbc;
+int samplerate_index;
+int channels = flv->audio_par->channels
+- (flv->audio_par->channels == 8 ? 1 : 0);
+uint8_t data[2];
+
+for (samplerate_index = 0; samplerate_index < 16;
+samplerate_index++)
+if (flv->audio_par->sample_rate
+== mpeg4audio_sample_rates[samplerate_index])
+break;
+
+init_put_bits(&pbc, data, sizeof(data));
+put_bits(&pbc, 5, flv->audio_par->profile + 1); //profile
+put_bits(&pbc, 4, samplerate_index); //sample rate index
+put_bits(&pbc, 4, channels);
+put_bits(&pbc, 1, 0); //frame length - 1024 samples
+put_bits(&pbc, 1, 0); //does not depend on core coder
+put_bits(&pbc, 1, 0); //is not extension
+flush_put_bits(&pbc);
+
+avio_w8(pb, data[0]);
+avio_w8(pb, data[1]);
+
+av_log(s, AV_LOG_WARNING, "AAC sequence header: %02x %02x.\n",
+data[0], data[1]);
+}
+avio_write(pb, par->extradata, par->extradata_size);
+} else {
+avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
+avio_w8(pb, 0); // AVC sequence header
+avio_wb24(pb, 0); // composition time
+ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
+}
+data_size = avio_tell(pb) - pos;
+avio_seek(pb, -data_size - 10, SEEK_CUR);
+avio_wb24(pb, data_size);
+avio_skip(pb, data_size + 10 - 3);
+avio_wb32(pb, data_size + 11); // previous tag size
+}
+}
+
 static int flv_write_header(AVFormatContext *s)
 {
 int i;
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
-int64_t data_size;
 
 for (i = 0; i < s->nb_streams; i++) {
 AVCodecParameters *par = s->streams[i]->codecpar;
@@ -446,57 +508,7 @@ static int flv_write_header(AVFormatContext *s)
 write_metadata(s, 0);
 
 for (i = 0; i < s->nb_streams; i++) {
-AVCodecParameters *par = s->streams[i]->codecpar;
-if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == 
AV_CODEC_ID_H264 || par->codec_id == AV_CODEC_ID_MPEG4) {
-int64_t pos;
-avio_w8(pb, par->codec_type == AVMEDIA_TYPE_VIDEO ?
-FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
-avio_wb24(pb, 0); // size patched later
-avio_wb24(pb, 0); // ts
-avio_w8(pb, 0);   // ts ext
-avio_wb24(pb, 0); // streamid
-pos = avio_tell(pb);
-if (par->codec_id == AV_CODEC_ID_AAC) {
-avio_w8(pb, get_audio_flags(s, par));
-avio_w8(pb, 0); // AAC sequence header
-
-if (!par->extradata_size && flv->flags & 1) {
-PutBitContext pbc;
-int samplerate_index;
-int channels = flv->audio_par->channels - 
(flv->audio_par->channels == 8 ? 1 : 0);
-uint8_t data[2];
-
-for (samplerate_index = 0; samplerate_index < 16; 
samplerate_index++)
-if (flv->audio_par->sample_rate == 
mpeg4audio_sample_rates[samplerate_index])
-break;
-
-init_put_bits(&pbc, data, sizeof(d

[FFmpeg-devel] [PATCH 1/2] libavformat/flvenc: refactoring: extracted method for writing codec headers

2016-06-10 Thread Ivan
---
 libavformat/flvenc.c | 116 ---
 1 file changed, 64 insertions(+), 52 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index d62ff70..cf8d221 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -343,12 +343,74 @@ static int unsupported_codec(AVFormatContext *s,
 return AVERROR(ENOSYS);
 }
 
+static void flv_write_codec_header(AVFormatContext* s, AVCodecParameters* par) 
{
+int64_t data_size;
+AVIOContext *pb = s->pb;
+FLVContext *flv = s->priv_data;
+
+if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
+|| par->codec_id == AV_CODEC_ID_MPEG4) {
+int64_t pos;
+avio_w8(pb,
+par->codec_type == AVMEDIA_TYPE_VIDEO ?
+FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
+avio_wb24(pb, 0); // size patched later
+avio_wb24(pb, 0); // ts
+avio_w8(pb, 0);   // ts ext
+avio_wb24(pb, 0); // streamid
+pos = avio_tell(pb);
+if (par->codec_id == AV_CODEC_ID_AAC) {
+avio_w8(pb, get_audio_flags(s, par));
+avio_w8(pb, 0); // AAC sequence header
+
+if (!par->extradata_size && flv->flags & 1) {
+PutBitContext pbc;
+int samplerate_index;
+int channels = flv->audio_par->channels
+- (flv->audio_par->channels == 8 ? 1 : 0);
+uint8_t data[2];
+
+for (samplerate_index = 0; samplerate_index < 16;
+samplerate_index++)
+if (flv->audio_par->sample_rate
+== mpeg4audio_sample_rates[samplerate_index])
+break;
+
+init_put_bits(&pbc, data, sizeof(data));
+put_bits(&pbc, 5, flv->audio_par->profile + 1); //profile
+put_bits(&pbc, 4, samplerate_index); //sample rate index
+put_bits(&pbc, 4, channels);
+put_bits(&pbc, 1, 0); //frame length - 1024 samples
+put_bits(&pbc, 1, 0); //does not depend on core coder
+put_bits(&pbc, 1, 0); //is not extension
+flush_put_bits(&pbc);
+
+avio_w8(pb, data[0]);
+avio_w8(pb, data[1]);
+
+av_log(s, AV_LOG_WARNING, "AAC sequence header: %02x %02x.\n",
+data[0], data[1]);
+}
+avio_write(pb, par->extradata, par->extradata_size);
+} else {
+avio_w8(pb, par->codec_tag | FLV_FRAME_KEY); // flags
+avio_w8(pb, 0); // AVC sequence header
+avio_wb24(pb, 0); // composition time
+ff_isom_write_avcc(pb, par->extradata, par->extradata_size);
+}
+data_size = avio_tell(pb) - pos;
+avio_seek(pb, -data_size - 10, SEEK_CUR);
+avio_wb24(pb, data_size);
+avio_skip(pb, data_size + 10 - 3);
+avio_wb32(pb, data_size + 11); // previous tag size
+}
+}
+
 static int flv_write_header(AVFormatContext *s)
 {
 int i;
 AVIOContext *pb = s->pb;
 FLVContext *flv = s->priv_data;
-int64_t data_size;
 
 for (i = 0; i < s->nb_streams; i++) {
 AVCodecParameters *par = s->streams[i]->codecpar;
@@ -446,57 +508,7 @@ static int flv_write_header(AVFormatContext *s)
 write_metadata(s, 0);
 
 for (i = 0; i < s->nb_streams; i++) {
-AVCodecParameters *par = s->streams[i]->codecpar;
-if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == 
AV_CODEC_ID_H264 || par->codec_id == AV_CODEC_ID_MPEG4) {
-int64_t pos;
-avio_w8(pb, par->codec_type == AVMEDIA_TYPE_VIDEO ?
-FLV_TAG_TYPE_VIDEO : FLV_TAG_TYPE_AUDIO);
-avio_wb24(pb, 0); // size patched later
-avio_wb24(pb, 0); // ts
-avio_w8(pb, 0);   // ts ext
-avio_wb24(pb, 0); // streamid
-pos = avio_tell(pb);
-if (par->codec_id == AV_CODEC_ID_AAC) {
-avio_w8(pb, get_audio_flags(s, par));
-avio_w8(pb, 0); // AAC sequence header
-
-if (!par->extradata_size && flv->flags & 1) {
-PutBitContext pbc;
-int samplerate_index;
-int channels = flv->audio_par->channels - 
(flv->audio_par->channels == 8 ? 1 : 0);
-uint8_t data[2];
-
-for (samplerate_index = 0; samplerate_index < 16; 
samplerate_index++)
-if (flv->audio_par->sample_rate == 
mpeg4audio_sample_rates[samplerate_index])
-break;
-
-init_put_bits(&pbc, data, sizeof(data));
-put_bits(&pbc, 5, flv->audio_par->profile + 1); //profile
-put_bits(&pbc, 4, samplerate_index); //sample rate index
-put_bits(&pbc, 4, channels);
-put_bits

[FFmpeg-devel] [PATCH 2/2] libavformat/flvenc: support for codec configuration change mid stream

2016-06-10 Thread Ivan
---
 libavformat/flvenc.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index cf8d221..6fd7792 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -566,6 +566,19 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 else
 flags_size = 1;
 
+if (par->codec_id == AV_CODEC_ID_AAC || par->codec_id == AV_CODEC_ID_H264
+|| par->codec_id == AV_CODEC_ID_MPEG4) {
+int side_size = 0;
+uint8_t *side = av_packet_get_side_data(pkt, 
AV_PKT_DATA_NEW_EXTRADATA, &side_size);
+if (side && side_size > 0 && (side_size != par->extradata_size || 
memcmp(side, par->extradata, side_size))) {
+av_free(par->extradata);
+par->extradata = av_mallocz(side_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
+memcpy(par->extradata, side, side_size);
+par->extradata_size = side_size;
+flv_write_codec_header(s, par);
+}
+}
+
 if (flv->delay == AV_NOPTS_VALUE)
 flv->delay = -pkt->dts;
 
-- 
1.9.1

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


[FFmpeg-devel] [PATCH] avformat/flvenc: copyts in FLV muxer

2016-01-25 Thread Ivan
The purpose of this patch is to preserve timestamps when using ffmpeg for 
publishing RTMP streams, e.g. ffmpeg -i rtmp://source/stream -f flv 
rtmp://target/stream.
There is a setting "copyts" for that purpose. Unfortunately it doesn't work 
with FLV muxer because it has its own timestamp correction which makes global 
setting "copyts" ineffective.

This patch removes timestamp correction in FLV muxer. This means FLV will rely 
on ffmpeg timestamp correction which makes it possible to use copyts.

---
 libavformat/flvenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 3925768..8fd5d29 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -562,7 +562,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 return AVERROR(EINVAL);
 }
 
-ts = pkt->dts + flv->delay; // add delay to force positive dts
+ts = pkt->dts;
 
 if (s->event_flags & AVSTREAM_EVENT_FLAG_METADATA_UPDATED) {
 write_metadata(s, ts);
-- 
1.9.1

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


Re: [FFmpeg-devel] [PATCH] avformat/gopher: Add support for Gopher over TLS.

2021-02-26 Thread Ivan J.
As for the test cases, curl has implemented their local test units[0]
that test gophers.

After applying the patch and compiling, the ffmpeg implementation can
be tested with the following:

1) No encryption:

$ ./ffplay gopher://parazyd.org/9/pub/dev/random/1593154977112.webm
$ ./ffplay gopher://adamsgaard.dk/9/npub/alien-love.mkv
$ ./ffplay gopher://codemadness.org/9/paste/warmelul.mkv

2) TLS with trusted certificate:

$ ./ffplay gophers://parazyd.org/9/pub/dev/random/1593154977112.webm
$ ./ffplay gophers://adamsgaard.dk/9/npub/alien-love.mkv
$ ./ffplay gophers://codemadness.org/9/paste/warmelul.mkv

[0] https://github.com/curl/curl/commit/48b85c46f16f04e803e00b0bad42a4fa0295f517

Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/gopher: Add support for Gopher over TLS.

2021-02-28 Thread Ivan J.
Pinging for review.

Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/gopher: Add support for Gopher over TLS.

2021-03-02 Thread Ivan J.
Ping for review. Thank you.

Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/gopher: Add support for Gopher over TLS.

2021-03-05 Thread Ivan J.
Bump for review. Test instructions:

https://ffmpeg.org/pipermail/ffmpeg-devel/2021-February/276913.html


Best regards,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/gopher: Add support for Gopher over TLS.

2021-03-08 Thread Ivan J.
Bump for review.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avfilter/pad: round output width/height up instead of down. Fixes bugs #1618 and #8475.

2020-01-26 Thread Ivan Middleton
The pad filter is currently broken for cases where all of the following hold:

(1) chroma subsampling exists (very common),

(2) an input dimension is odd (uncommon), and

(3) the corresponding output dimension is either the same as the input,
or an expression like "ow-iw" or "oh-ih" is used to place the image at
the right/bottom edge and the extra padding is even in size.

The cause of the breakage is essentially that the output width and
height are being rounded downward, causing the image to exceed the
padded area slightly.

It seems best to me to simply round the output width/height up instead 
of down, so I've attached a patch to do that. This fixes bugs #1618 and
#8475.

Commands to reproduce the bug:

# create 15x15 test jpeg with 4:2:0 subsampling
ffmpeg -f lavfi -i color=red:15x15,format=rgb24 -vframes 1 -vf format=yuvj420p 
red.jpg

# output size = input size. fails
ffmpeg -i red.jpg -vf pad=iw:ih:0:0 pad1.png

# input at bottom right of output. fails
ffmpeg -i red.jpg -vf pad=iw+16:ih+16:ow-iw:oh-ih pad2.png

Ivan
From 52030219e09b5f9611ca6232b1f24197363fc23b Mon Sep 17 00:00:00 2001
From: Ivan Middleton 
Date: Sun, 26 Jan 2020 20:25:59 -0700
Subject: [PATCH] avfilter/pad: round output width/height up instead of down.
 Fixes bugs #1618 and #8475.

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

diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
index e86292e..493e342 100644
--- a/libavfilter/vf_pad.c
+++ b/libavfilter/vf_pad.c
@@ -178,8 +178,8 @@ static int config_input(AVFilterLink *inlink)
 if (s->y < 0 || s->y + inlink->h > s->h)
 s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
 
-s->w= ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
-s->h= ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
+s->w= ff_draw_round_to_sub(&s->draw, 0, +1, s->w);
+s->h= ff_draw_round_to_sub(&s->draw, 1, +1, s->h);
 /* sanity check params */
 if (s->w < inlink->w || s->h < inlink->h) {
 av_log(ctx, AV_LOG_ERROR, "Padded dimensions cannot be smaller than input dimensions.\n");
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/pad: round output width/height up instead of down. Fixes bugs #1618 and #8475.

2020-02-05 Thread Ivan Middleton
Hoping someone can review this and apply it if it looks good.

> The pad filter is currently broken for cases where all of the following hold:
> 
> (1) chroma subsampling exists (very common),
> 
> (2) an input dimension is odd (uncommon), and
> 
> (3) the corresponding output dimension is either the same as the input,
> or an expression like "ow-iw" or "oh-ih" is used to place the image at
> the right/bottom edge and the extra padding is even in size.
> 
> The cause of the breakage is essentially that the output width and
> height are being rounded downward, causing the image to exceed the
> padded area slightly.
> 
> It seems best to me to simply round the output width/height up instead 
> of down, so I've attached a patch to do that. This fixes bugs #1618 and
> #8475.
> 
> Commands to reproduce the bug:
> 
> # create 15x15 test jpeg with 4:2:0 subsampling
> ffmpeg -f lavfi -i color=red:15x15,format=rgb24 -vframes 1 -vf 
> format=yuvj420p red.jpg
> 
> # output size = input size. fails
> ffmpeg -i red.jpg -vf pad=iw:ih:0:0 pad1.png
> 
> # input at bottom right of output. fails
> ffmpeg -i red.jpg -vf pad=iw+16:ih+16:ow-iw:oh-ih pad2.png
> 
> Ivan
> 
> ---
>  libavfilter/vf_pad.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavfilter/vf_pad.c b/libavfilter/vf_pad.c
> index e86292e..493e342 100644
> --- a/libavfilter/vf_pad.c
> +++ b/libavfilter/vf_pad.c
> @@ -178,8 +178,8 @@ static int config_input(AVFilterLink *inlink)
>  if (s->y < 0 || s->y + inlink->h > s->h)
>  s->y = var_values[VAR_Y] = (s->h - inlink->h) / 2;
>  
> -s->w= ff_draw_round_to_sub(&s->draw, 0, -1, s->w);
> -s->h= ff_draw_round_to_sub(&s->draw, 1, -1, s->h);
> +s->w= ff_draw_round_to_sub(&s->draw, 0, +1, s->w);
> +s->h= ff_draw_round_to_sub(&s->draw, 1, +1, s->h);
>  /* sanity check params */
>  if (s->w < inlink->w || s->h < inlink->h) {
>  av_log(ctx, AV_LOG_ERROR, "Padded dimensions cannot be smaller than 
> input dimensions.\n");
> -- 
> 2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Looking for AVfoundation developers

2021-07-27 Thread Ivan Čurić
I am currently working on a project that uses FFmpeg in a node native addon
(NAPI, C++) and we've hit a seemingly dead end concerning Mac
(AVfoundation) performance.

Specifically, consuming a 4k 30fps webcam stream suffers from a ~3s latency
on the Mac, and this happens on every application on the Mac, except
Chromium >V87 when (i believe) this patch
<https://chromium-review.googlesource.com/c/chromium/src/+/2412732> was
merged.

I am looking for a developer that would be able to help with this issue and
potentially finish up work with the rest of the addon.

-- 
Ivan Čurić
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


Re: [FFmpeg-devel] [PATCH 1/2] opus_pvq: add resynth support and band encoding cost function

2017-04-14 Thread Ivan Kalvachev
On 4/15/17, wm4  wrote:
> On Sat, 15 Apr 2017 00:28:19 +0200
> Carl Eugen Hoyos  wrote:
>
>> 2017-04-14 23:27 GMT+02:00 Clément Bœsch :
>> > On Fri, Apr 14, 2017 at 02:30:28PM +0200, Carl Eugen Hoyos wrote:
>> > [...]
>> >> We know that the avconv developers are violating the
>> >> copyright of many people, we fix that in the FFmpeg code as
>> >> soon as we are aware of it, there are many examples in gitlog.
>> >
>> > This is a serious accusation, what are you referring to?
>>
>> To the same (many) commits in the avconv repository that
>> violate the copyright of FFmpeg developers as many times
>> before - sorry, I don't understand: Are you implying you don't
>> remember such a commit?
>
> Of course you keep repeating your defamation without providing proof,
> ever.

http://git.videolan.org/?p=ffmpeg.git&a=search&h=HEAD&st=commit&s=attribution

I found the above link in the "Reintroducing FFmpeg to Debian" thread (2014).
It still works :D

I do remember that in 2014 Ronald was pressuring Libav (e.g. Vittorio)
about proper attribution to the changes done by multiple Libav developers when
merging ffvp9. (AKA who exactly changed what).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] New API usage example (encode_raw_audio_file_to_aac)

2017-05-06 Thread Ivan Kalvachev
On 3/31/17, Paolo Prete  wrote:
> ---
>  configure   |   2 +
>  doc/Makefile|  41 ++--
>  doc/examples/.gitignore |   1 +
>  doc/examples/Makefile   |   1 +
>  doc/examples/encode_raw_audio_file_to_aac.c | 338
> 
>  5 files changed, 363 insertions(+), 20 deletions(-)
>  create mode 100644 doc/examples/encode_raw_audio_file_to_aac.c

What is the status of this patch?
It's been quite a while and there have been no objections.

Maybe it should be committed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] fix GetBitContext index when SPS bitstream_restriction_flag=1 but can't be parsed, because index is out of bit-stream size. Need return index value continue H.264 parsing

2017-05-16 Thread Ivan Shmakov
---
 libavcodec/h264_ps.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 7858361..09e2290 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -136,6 +136,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 {
 int aspect_ratio_info_present_flag;
 unsigned int aspect_ratio_idc;
+int idx;
 
 aspect_ratio_info_present_flag = get_bits1(gb);
 
@@ -221,8 +222,10 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 sps->pic_struct_present_flag = get_bits1(gb);
 if (!get_bits_left(gb))
 return 0;
+
 sps->bitstream_restriction_flag = get_bits1(gb);
 if (sps->bitstream_restriction_flag) {
+idx = gb->index;
 get_bits1(gb); /* motion_vectors_over_pic_boundaries_flag */
 get_ue_golomb(gb); /* max_bytes_per_pic_denom */
 get_ue_golomb(gb); /* max_bits_per_mb_denom */
@@ -234,6 +237,7 @@ static inline int decode_vui_parameters(GetBitContext
*gb, AVCodecContext *avctx
 if (get_bits_left(gb) < 0) {
 sps->num_reorder_frames = 0;
 sps->bitstream_restriction_flag = 0;
+gb->index = idx;
 }
 
 if (sps->num_reorder_frames > 16U
-- 
2.10.2.windows.1


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


[FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

2017-06-08 Thread Ivan Kalvachev
1 reciprocal op that is a lot faster
than real division, but gives half precision.
"2" uses 1 multiplication and 1 reciprocal square root op, that is
literally 1 cycle, but again gives half precision.

PRESEARCH_ROUNDING
This control the rounding of the gain used for guess.
"0" means using truncf() that makes sure that the pulses would never
be more than K.
It gives results identical to the original celt_* functions
"1" means using lrintf(), this is basically the improvement of the
current C code over the celt_ one.


ALL_FLOAT_PRESEARCH
The presearch filling of outY[] could be done entirely with float ops
(using SSE4.2 'roundps' instead of two cvt*).  It is mostly useful if
you want to try YMM on AVX1 (AVX1 lacks 256 integer ops).
For some reason enabling this makes the whole function 4 times slower
on my CPU. ^_^

I've left some commented out code. I'll remove it for sure in the final version.

I just hope I haven't done some lame mistake in the last minute...
From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 1/3] SIMD opus pvq_search implementation.

---
 libavcodec/opus_pvq.c  |   9 +
 libavcodec/opus_pvq.h  |   5 +-
 libavcodec/x86/Makefile|   1 +
 libavcodec/x86/opus_dsp_init.c |  47 +++
 libavcodec/x86/opus_pvq_search.asm | 597 +
 5 files changed, 657 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/x86/opus_dsp_init.c
 create mode 100644 libavcodec/x86/opus_pvq_search.asm

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2ac66a0ede..172223e241 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -418,7 +418,13 @@ static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_
 int *y = pvq->qcoeff;
 
 celt_exp_rotation(X, N, blocks, K, spread, 1);
+
+{
+START_TIMER
 gain /= sqrtf(pvq->pvq_search(X, y, K, N));
+STOP_TIMER("pvq_search");
+}
+
 celt_encode_pulses(rc, y,  N, K);
 celt_normalize_residual(y, X, N, gain);
 celt_exp_rotation(X, N, blocks, K, spread, 0);
@@ -947,6 +953,9 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
+if (ARCH_X86)
+ff_opus_dsp_init_x86(s);
+
 *pvq = s;
 
 return 0;
diff --git a/libavcodec/opus_pvq.h b/libavcodec/opus_pvq.h
index 6691494838..9246337360 100644
--- a/libavcodec/opus_pvq.h
+++ b/libavcodec/opus_pvq.h
@@ -33,8 +33,8 @@
float *lowband_scratch, int fill)
 
 struct CeltPVQ {
-DECLARE_ALIGNED(32, int,   qcoeff  )[176];
-DECLARE_ALIGNED(32, float, hadamard_tmp)[176];
+DECLARE_ALIGNED(32, int,   qcoeff  )[256];
+DECLARE_ALIGNED(32, float, hadamard_tmp)[256];
 
 float (*pvq_search)(float *X, int *y, int K, int N);
 
@@ -45,6 +45,7 @@ struct CeltPVQ {
 };
 
 int  ff_celt_pvq_init  (struct CeltPVQ **pvq);
+void ff_opus_dsp_init_x86(struct CeltPVQ *s);
 void ff_celt_pvq_uninit(struct CeltPVQ **pvq);
 
 #endif /* AVCODEC_OPUS_PVQ_H */
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 710e48b15f..f50a48dc13 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -51,6 +51,7 @@ OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
 OBJS-$(CONFIG_CAVS_DECODER)+= x86/cavsdsp.o
 OBJS-$(CONFIG_DCA_DECODER) += x86/dcadsp_init.o x86/synth_filter_init.o
 OBJS-$(CONFIG_DNXHD_ENCODER)   += x86/dnxhdenc_init.o
+OBJS-$(CONFIG_OPUS_ENCODER)+= x86/opus_dsp_init.o x86/opus_pvq_search.o
 OBJS-$(CONFIG_HEVC_DECODER)+= x86/hevcdsp_init.o
 OBJS-$(CONFIG_JPEG2000_DECODER)+= x86/jpeg2000dsp_init.o
 OBJS-$(CONFIG_MLP_DECODER) += x86/mlpdsp_init.o
diff --git a/libavcodec/x86/opus_dsp_init.c b/libavcodec/x86/opus_dsp_init.c
new file mode 100644
index 00..ddccf6fe9e
--- /dev/null
+++ b/libavcodec/x86/opus_dsp_init.c
@@ -0,0 +1,47 @@
+/*
+ * Opus encoder assembly optimizations
+ * Copyright (C) 2017 Ivan Kalvachev 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA

Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, Michael Niedermayer  wrote:
> On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
>> 
>> wrote:
>>
>> > Signed value in
>> > Unsigned
>> > INTeger type
>>
>> [..]
>> > Both SUINT and unsigned should produce identical binaries
>>
>> This seems to go against the rule that code should be as simple as
>> possible.
>>
>> Unsigned is simpler than SUINT if the outcome is the same.
>
> You can simply add the part of my mail here as awnser that you snipped
> away:
>
> "But it makes the code hard to understand and maintain because these
>  values are not positive integers but signed integers. Which for
>  C standard compliance need to be stored in a unsigned type."
>
> A type that avoids the undefinedness of signed but is semantically
> signed is correct, unsigned is not.
>
> If understandable code and maintainable code has no value to you,
> you would favour using single letter variables exclusivly and would
> never use typedef.
> But you do not do that.
>
> I fail to understand why you insist on using unsigned in place of a
> more specific type, it is not the correct nor clean thing to do.


If I understand correctly, the root of the problem is the undefined behavior
of the compiler and the C standard.
Is there any chance that FFmpeg project could initiate a change in the
next C standard, so this thing would be defined?
(and I guess, also define a few other similar things, like signed
right shift, etc...)

It is a matter of fact, that a lot of compiler-defined-things have
been implemented in
certain ways on most compilers and that there are plenty of programs
depend on these
specific implementations and break when a new compiler does things differently
(clang had nice article about it).


About the typedef, is SUINT a standard defined type for workarounding
this specific problem?
I do suspect that some of our fellow developers simply find its name ugly.

Maybe they would be more welcoming if
"suint32_t" like typedef is used?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation

2017-06-09 Thread Ivan Kalvachev
On 6/8/17, Ilia Valiakhmetov  wrote:
> vp9_diag_downright_16x16_12bpp_c: 149.0
> vp9_diag_downright_16x16_12bpp_sse2: 67.8
> vp9_diag_downright_16x16_12bpp_ssse3: 45.6
> vp9_diag_downright_16x16_12bpp_avx: 36.6
> vp9_diag_downright_16x16_12bpp_avx2: 25.5
>
> ~30% faster than avx
>
> Signed-off-by: Ilia Valiakhmetov 
> ---
>  libavcodec/x86/vp9dsp_init_16bpp.c|  2 ++
>  libavcodec/x86/vp9intrapred_16bpp.asm | 56
> +++
>  2 files changed, 58 insertions(+)
>
> diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
> b/libavcodec/x86/vp9dsp_init_16bpp.c
> index d1b8fcd..8d1aa13 100644
> --- a/libavcodec/x86/vp9dsp_init_16bpp.c
> +++ b/libavcodec/x86/vp9dsp_init_16bpp.c
> @@ -52,6 +52,7 @@ decl_ipred_fns(dc,  16, mmxext, sse2);
>  decl_ipred_fns(dc_top,  16, mmxext, sse2);
>  decl_ipred_fns(dc_left, 16, mmxext, sse2);
>  decl_ipred_fn(dl,   16, 16, avx2);
> +decl_ipred_fn(dr,   16, 16, avx2);
>  decl_ipred_fn(dl,   32, 16, avx2);
>
>  #define decl_ipred_dir_funcs(type) \
> @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext
> *dsp)
>  init_fpel_func(1, 1,  64, avg, _16, avx2);
>  init_fpel_func(0, 1, 128, avg, _16, avx2);
>  init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2);
> +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2);
>  init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2);
>  }
>
> diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm
> b/libavcodec/x86/vp9intrapred_16bpp.asm
> index 92333bc..67b98b1 100644
> --- a/libavcodec/x86/vp9intrapred_16bpp.asm
> +++ b/libavcodec/x86/vp9intrapred_16bpp.asm
> @@ -1170,6 +1170,62 @@ DR_FUNCS 2
>  INIT_XMM avx
>  DR_FUNCS 2
>
> +%if HAVE_AVX2_EXTERNAL
> +INIT_YMM avx2
> +cglobal vp9_ipred_dr_16x16_16, 4, 6, 7, dst, stride, l, a
> +movam0, [lq]   ; klmnopqrstuvwxyz
> +movum1, [aq-2] ; *abcdefghijklmno
> +movam2, [aq]   ; abcdefghijklmnop

I know unaligned loads are not as slow as they used to be,
but could m1 be produced by m2 and palignr?

From the comment I assume you don't use the extra two bytes
that you get from the load, as you mark them as "*"
generic undefined values

> +vperm2i128  m4, m2, m2, q2001  ; ijklmnop
> +vpalignrm5, m4, m2, 2  ; bcdefghijklmnop.
> +vperm2i128  m3, m0, m1, q0201  ; stuvwxyz*abcdefg
> +LOWPASS  1,  2,  5 ; ABCDEFGHIJKLMNO.
> +vpalignrm4, m3, m0, 2  ; lmnopqrstuvwxyz*
> +vpalignrm5, m3, m0, 4  ; mnopqrstuvwxyz*a
> +LOWPASS  0,  4,  5 ; LMNOPQRSTUVWXYZ#
> +vperm2i128  m5, m0, m1, q0201  ; TUVWXYZ#ABCDEFGH
> +DEFINE_ARGS dst, stride, stride3, stride5, dst3, cnt

"cnt" doesn't seem to be used.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, Michael Niedermayer  wrote:
> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote:
>>  opus_pvq.c  |9
>>  opus_pvq.h  |5
>>  x86/Makefile|1
>>  x86/opus_dsp_init.c |   47 +++
>>  x86/opus_pvq_search.asm |  597
>> 
>>  5 files changed, 657 insertions(+), 2 deletions(-)
>> 3b9648bea3f01dad2cf159382f0ffc2d992c84b2
>> 0001-SIMD-opus-pvq_search-implementation.patch
>> From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001
>> From: Ivan Kalvachev 
>> Date: Thu, 8 Jun 2017 22:24:33 +0300
>> Subject: [PATCH 1/3] SIMD opus pvq_search implementation.
>
> seems this breaks build with mingw64, didnt investigate but it
> fails with these errors:
>
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
> collect2: error: ld returned 1 exit status
> collect2: error: ld returned 1 exit status
> make: *** [ffmpeg_g.exe] Error 1
> make: *** Waiting for unfinished jobs
> make: *** [ffprobe_g.exe] Error 1


const_*_edge is used on only one place is the code.
Would you check if this patch fixes the issue.

--- a/libavcodec/x86/opus_pvq_search.asm
+++ b/libavcodec/x86/opus_pvq_search.asm
@@ -419,7 +419,7 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
 add Nq,   r4q   ; Nq = align(Nq, mmsize)
 sub rsp,  Nq; allocate tmpX[Nq]

-movups  m3,   [const_align_abs_edge-mmsize+r4q] ; this is
the bit mask for the padded read at the end of the input
+movups  m3,   [const_align_abs_mask+32-mmsize+r4q] ; this
is the bit mask for the padded read at the end of the input

 lea r4q,  [Nq-mmsize]   ; Nq is rounded up (aligned
up) to mmsize, so r4q can't become negative here, unless N=0.
 movups  m2,   [inXq + r4q]
===
I expected that the addresses would be pre-calculated
by n/yasm as one value and indexed
relative to the section start.
Instead it seems that each entry is represented with
its own address and offset from it.
Since the offset is negative it uses all 64 bits and
it makes difference if it is truncated to 32 bits.

Same issue could happen with clang tools.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, Ivan Kalvachev  wrote:
> On 6/9/17, Michael Niedermayer  wrote:
>> On Fri, Jun 09, 2017 at 01:36:07AM +0300, Ivan Kalvachev wrote:
>>>  opus_pvq.c  |9
>>>  opus_pvq.h  |5
>>>  x86/Makefile|1
>>>  x86/opus_dsp_init.c |   47 +++
>>>  x86/opus_pvq_search.asm |  597
>>> 
>>>  5 files changed, 657 insertions(+), 2 deletions(-)
>>> 3b9648bea3f01dad2cf159382f0ffc2d992c84b2
>>> 0001-SIMD-opus-pvq_search-implementation.patch
>>> From 06dc798c302e90aa5b45bec5d8fbcd64ba4af076 Mon Sep 17 00:00:00 2001
>>> From: Ivan Kalvachev 
>>> Date: Thu, 8 Jun 2017 22:24:33 +0300
>>> Subject: [PATCH 1/3] SIMD opus pvq_search implementation.
>>
>> seems this breaks build with mingw64, didnt investigate but it
>> fails with these errors:
>>
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>> collect2: error: ld returned 1 exit status
>> collect2: error: ld returned 1 exit status
>> make: *** [ffmpeg_g.exe] Error 1
>> make: *** Waiting for unfinished jobs
>> make: *** [ffprobe_g.exe] Error 1
>
>
> const_*_edge is used on only one place is the code.
> Would you check if this patch fixes the issue.
>
Sorry, the patch was not tested and the variable name was not correct.
This one should be fine... I hope

--- a/libavcodec/x86/opus_pvq_search.asm
+++ b/libavcodec/x86/opus_pvq_search.asm
@@ -419,7 +419,7 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
 add Nq,   r4q   ; Nq = align(Nq, mmsize)
 sub rsp,  Nq; allocate tmpX[Nq]

-movups  m3,   [const_align_abs_edge-mmsize+r4q] ; this is
the bit mask for the padded read at the end of the input
+movups  m3,   [const_float_abs_mask+32-mmsize+r4q] ; this
is the bit mask for the padded read at the end of the input

 lea r4q,  [Nq-mmsize]   ; Nq is rounded up (aligned
up) to mmsize, so r4q can't become negative here, unless N=0.
 movups  m2,   [inXq + r4q]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [RFC] x86 external assembler requirements

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, Hendrik Leppkes  wrote:
> On Fri, Jun 9, 2017 at 2:51 PM, James Darnley  wrote:
>> I propose that we drop support for all assemblers older than NASM version
>> 2.11.
>> That was released on 2013-12-31 with several point releases over the
>> following
>> year with 2.11.08 being released on 2015-02-21.
>>
>> The following patch does just that.  Please do not be concerned about the
>> ZMM
>> register use.  This patch does not address the use of AVX-512
>> instructions.  In
>> a future patch I will add a different check for enabling/disabling
>> AVX-512.
>>
>> The NASM changelog can be found here:
>> http://www.nasm.us/doc/nasmdocc.html
>>
>> Releases and their dates can be seen here:
>> http://www.nasm.us/pub/nasm/releasebuilds/?C=M;O=D
>>
>> Other than the discussion about the oldest version to support we should
>> discuss
>> the command line options for configure and the internal variable names.
>> At
>> present they all use "yasm" somewhere.  If we are to drop support for that
>> then
>> we should change the option names to prevent confusion.
>>
>> We could just change them to "nasm" and be done.  We could provide
>> compatability
>> options.  We could adopt Libav's generic "x86asm".

It's better to use generic name.

I do not like "x86asm", as 'gnu as' also fits that description,
but it is better than changing the name every time some
compiler takes the lead. E.g. zasm might be the next
champion of AVX512 assembly. ;)



>> James Darnley (1):
>>   configure: require NASM version 2.11 or newer for external x86
>> assembly
>>
>>  configure | 17 -
>>  1 file changed, 4 insertions(+), 13 deletions(-)
>>
>> Brought to you by my inability to configure FFmpeg with NASM 2.13.
>>
>
> Maybe you should just pick the patches from Libav, that still
> implement an automatic fallback to YASM if NASM is not found or too
> old? We would eventually get to them in the merges anyway.
> Many people building FFmpeg for years with YASM may not have an
> appropriate NASM installed, and forcing a switch here may not be
> ideal.

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


Re: [FFmpeg-devel] [PATCH] avcodec/vp9: ipred_dr_16x16_16 avx2 implementation

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, Ilia Valiakhmetov  wrote:
> Signed-off-by: Ilia Valiakhmetov 
> ---
>  libavcodec/x86/vp9dsp_init_16bpp.c|  2 ++
>  libavcodec/x86/vp9intrapred_16bpp.asm | 56
> +++
>  2 files changed, 58 insertions(+)
>
> diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
> b/libavcodec/x86/vp9dsp_init_16bpp.c
> index d1b8fcd..8d1aa13 100644
> --- a/libavcodec/x86/vp9dsp_init_16bpp.c
> +++ b/libavcodec/x86/vp9dsp_init_16bpp.c
> @@ -52,6 +52,7 @@ decl_ipred_fns(dc,  16, mmxext, sse2);
>  decl_ipred_fns(dc_top,  16, mmxext, sse2);
>  decl_ipred_fns(dc_left, 16, mmxext, sse2);
>  decl_ipred_fn(dl,   16, 16, avx2);
> +decl_ipred_fn(dr,   16, 16, avx2);
>  decl_ipred_fn(dl,   32, 16, avx2);
>
>  #define decl_ipred_dir_funcs(type) \
> @@ -136,6 +137,7 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext
> *dsp)
>  init_fpel_func(1, 1,  64, avg, _16, avx2);
>  init_fpel_func(0, 1, 128, avg, _16, avx2);
>  init_ipred_func(dl, DIAG_DOWN_LEFT, 16, 16, avx2);
> +init_ipred_func(dr, DIAG_DOWN_RIGHT, 16, 16, avx2);
>  init_ipred_func(dl, DIAG_DOWN_LEFT, 32, 16, avx2);
>  }
>
> diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm
> b/libavcodec/x86/vp9intrapred_16bpp.asm
> index 92333bc..7230de2 100644
> --- a/libavcodec/x86/vp9intrapred_16bpp.asm
> +++ b/libavcodec/x86/vp9intrapred_16bpp.asm
> @@ -1170,6 +1170,62 @@ DR_FUNCS 2
>  INIT_XMM avx
>  DR_FUNCS 2
>
> +%if HAVE_AVX2_EXTERNAL
> +INIT_YMM avx2
> +cglobal vp9_ipred_dr_16x16_16, 4, 4, 6, dst, stride, l, a
[...]
> +DEFINE_ARGS dst, stride, stride3, stride5, dst3

You removed one variable, so now the number of
re-define-args gprs should be 5.
However the cglobal above have 4 reserved registers.

It used to be  4, 6, 6
Now it is 4, 4, 6
I think it should be 4, 5, 6

Do I miss something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'

2017-06-09 Thread Ivan Kalvachev
On 6/9/17, wm4  wrote:
> On Fri, 9 Jun 2017 00:10:49 +0200
> Michael Niedermayer  wrote:
>
>> On Sat, May 27, 2017 at 12:24:16PM +0200, wm4 wrote:
>> > On Sat, 27 May 2017 03:56:42 +0200
>> > Michael Niedermayer  wrote:
>> >
>> > > On Fri, May 26, 2017 at 07:06:44PM -0400, Ronald S. Bultje wrote:
>> > > > Hi,
>> > > >
>> > > > On Fri, May 26, 2017 at 6:34 PM, Michael Niedermayer
>> > > > > > > > > wrote:
>> > > >
>> > > > > On Fri, May 26, 2017 at 06:07:35PM -0400, Ronald S. Bultje wrote:
>> > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > On Fri, May 26, 2017 at 5:50 PM, Michael Niedermayer
>> > > > > > > > > > > > wrote:
>> > > > > >
>> > > > > > > On Fri, May 26, 2017 at 11:18:12PM +0200, Hendrik Leppkes
>> > > > > > > wrote:
>> > > > > > > > On Fri, May 26, 2017 at 11:11 PM, Michael Niedermayer
>> > > > > > > >  wrote:
>> > > > > > > > > On Fri, May 26, 2017 at 03:20:14PM +0100, Rostislav
>> > > > > > > > > Pehlivanov
>> > > > > wrote:
>> > > > > > > > >> On 26 May 2017 at 12:21, wm4 
>> > > > > > > > >> wrote:
>> > > > > > > > >>
>> > > > > > > > >> > On Thu, 25 May 2017 16:10:49 +0200
>> > > > > > > > >> > Michael Niedermayer  wrote:
>> > > > > > > > >> >
>> > > > > > > > >> > > Fixes:
>> > > > > > > > >> > > 1735/clusterfuzz-testcase-minimized-5350472347025408
>> > > > > > > > >> > >
>> > > > > > > > >> > > Found-by: continuous fuzzing process
>> > > > > > > https://github.com/google/oss-
>> > > > > > > > >> > fuzz/tree/master/projects/ffmpeg
>> > > > > > > > >> > > Signed-off-by: Michael Niedermayer
>> > > > > > > > >> > > 
>> > > > > > > > >> > > ---
>> > > > > > > > >> > >  libavcodec/fft_template.c | 50
>> > > > > > > > >> > > +++---
>> > > > > > > > >> > -
>> > > > > > > > >> > >  1 file changed, 25 insertions(+), 25 deletions(-)
>> > > > > > > > >> > >
>> > > > > > > > >> > > diff --git a/libavcodec/fft_template.c
>> > > > > b/libavcodec/fft_template.c
>> > > > > > > > >> > > index 480557f49f..e3a37e5d69 100644
>> > > > > > > > >> > > --- a/libavcodec/fft_template.c
>> > > > > > > > >> > > +++ b/libavcodec/fft_template.c
>> > > > > > > > >> > > @@ -249,7 +249,7 @@ static void fft_calc_c(FFTContext
>> > > > > > > > >> > > *s,
>> > > > > > > FFTComplex *z)
>> > > > > > > > >> > {
>> > > > > > > > >> > >
>> > > > > > > > >> > >  int nbits, i, n, num_transforms, offset, step;
>> > > > > > > > >> > >  int n4, n2, n34;
>> > > > > > > > >> > > -FFTSample tmp1, tmp2, tmp3, tmp4, tmp5, tmp6,
>> > > > > > > > >> > > tmp7, tmp8;
>> > > > > > > > >> > > +SUINT tmp1, tmp2, tmp3, tmp4, tmp5, tmp6, tmp7,
>> > > > > > > > >> > > tmp8;
>> > > > > > > > >> >
>> > > > > > > > >> > I want this SUINT thing gone, not have more of it.
>> > > > > > > > >> > ___
>> > > > > > > > >> > ffmpeg-devel mailing list
>> > > > > > > > >> > ffmpeg-devel@ffmpeg.org
>> > > > > > > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> > > > > > > > >> >
>> > > > > > > > >>
>> > > > > > > > >> I agree, especially here.
>> > > > > > > > >
>> > > > > > > > >> Overflows should be left to happen in transforms if the
>> > > > > > > > >> input is
>> > > > > > > corrupt.
>> > > > > > > > >
>> > > > > > > > > signed int overflow is not allowed in C, if that is what
>> > > > > > > > > you meant.
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > > Its "undefined", which means what the result will be is not
>> > > > > > > > defined -
>> > > > > > > > which in such a DSP function is irrelevant, if all it causes
>> > > > > > > > is
>> > > > > > > > corrupt output ... from corrupt input.
>> > > > > > >
>> > > > > > > no, this is not correct.
>> > > > > > > undefined behavior does not mean the effect will be limited to
>> > > > > > > the output.
>> > > > > > > It could cause the process to hard lockup, trigger an
>> > > > > > > exception or
>> > > > > > > set a flag causing errors in later unrelated code.
>> > > > > >
>> > > > > >
>> > > > >
>> > > > > > We've discussed this before, if you believe this to be
>> > > > > > exploitable, why
>> > > > > > allow it in our repository at all? I know of no other project
>> > > > > > that even
>> > > > > > remotely allows such ridiculous things. Please limit exploitable
>> > > > > > code to
>> > > > > > your personal tree, ffmpeg is not a rootkit.
>> > > > >
>> > > > > please calm down, you make all kinds of statments and implications
>> > > > > in
>> > > > > the text above which are not true.
>> > > > >
>> > > > > This specific code in git triggers undefined behavior, the patch
>> > > > > fixes
>> > > > > this undefined behavior.
>> > > > > If that is exploitable (which i neither claim it is nor that it
>> > > > > isnt)
>> > > > > its a issue that exists before the patch but not afterwards.
>> > > >
>> > > >
>> > >
>> > > > *unsigned* removes the exploit. SUINT keeps it, and is therefore
>> > > > part of a
>> > > > rootkit.
>> > >
>> > > SUINT is defined to unsigned, if unsigned re

Re: [FFmpeg-devel] [PATCH] avcodec/fft_template: Fix multiple runtime error: signed integer overflow: -1943918714 - 1935113003 cannot be represented in type 'int'

2017-06-10 Thread Ivan Kalvachev
On 6/10/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Thu, Jun 8, 2017 at 8:57 PM, Michael Niedermayer 
> wrote:
>
>> On Thu, Jun 08, 2017 at 06:35:07PM -0400, Ronald S. Bultje wrote:
>> > Hi,
>> >
>> > On Thu, Jun 8, 2017 at 6:10 PM, Michael Niedermayer
>> 
>> > wrote:
>> >
>> > > Signed value in
>> > > Unsigned
>> > > INTeger type
>> >
>> > [..]
>> > > Both SUINT and unsigned should produce identical binaries
>> >
>> > This seems to go against the rule that code should be as simple as
>> possible.
>> >
>> > Unsigned is simpler than SUINT if the outcome is the same.
>>
>> You can simply add the part of my mail here as awnser that you snipped
>> away:
>>
>> "But it makes the code hard to understand and maintain because these
>>  values are not positive integers but signed integers. Which for
>>  C standard compliance need to be stored in a unsigned type."
>>
>> A type that avoids the undefinedness of signed but is semantically
>> signed is correct, unsigned is not.
>>
>> If understandable code and maintainable code has no value to you,
>> you would favour using single letter variables exclusivly and would
>> never use typedef.
>> But you do not do that.
>>
>> I fail to understand why you insist on using unsigned in place of a
>> more specific type, it is not the correct nor clean thing to do.
>
>
> It's not just me, it appears to be most of us. Can't you just step back at
> some point and be like "ok, I'll let the majority have their way"?

There was actually a technical discussion undergoing,
until your regular "majority" group came with strong words,
opinions, and comments that clearly indicate that you don't
understand the issue at hand.

I'll try to explain the issue one more time.

---

You all know that singed overflow is undefined.
In gcc there are two options to define/control the behavior of it:
-fwrapv - defines signed overflow as wrapping around, just like unsigned.
-ftrapv - causes a trap exception, could lead to termination of the program.

Now, as the article
  http://blog.llvm.org/2011/05/what-every-c-programmer-should-know.html
explains in detail, undefined behavior allows certain
optimizations, like loop optimizations, pointer arithmetic etc..
Using -fwrapv globally might lead to a significant slow down.

On the other side, some of these optimization might lead to security
exploits e.g. if they optimize-out checks in the code, that are there to
prevent overflows.

So there is a possible scenario, where some entity that want to secure the
video playback of their browser, would like to enable a bunch of
runtime checking functionality, like -fstack-protector and -fwrapv.

Now, we get to the FFT.

As Rostislav (atomnuker) said, it is not big issue if
overflow happens in fft calculation and produces wrong result.

However if -ftrapv is enabled, it may crash the whole program (!!)
(instead of producing a short noise).

To prevent that Michael changes the code so a signed variable is
converted to unsigned for the operations that could overflow
and converted back to signed for operations that need sign extension.

He is using a new typedef,
so the developers(!) could know that this type contains signed value,
while the type for the compiler(!) is actually unsigned.

Now...
I would be happy if you all could think of a better way to get the same result,
that doesn't involve changing types back and forth.

All I can think of is:
1. Moving the functions to a special file and compiling it with
-fwrapv -fno-trapv.
In the fft case this might be extra hard, as the file is actually a template...
2. Asking gcc for attribute that defines the behavior, for a single
function or code block.
3. Asking gcc for attribute that defines the behavior, for a variable or type.
4. Defining that behavior by the standard committee in next C
standard. Maybe with new standard type. Or making "int32_t" wrap,
while keeping "int" undefined.


Michael solution may look ugly, make the code
harder to understand, but it:
1. Works Now.
2. Does work on all compilers.
3. Doesn't make the code slower.
4. Doesn't complicate the build system.


Of course, as FFmpeg developer, it is your right to initiate a vote
that would prevent Michael from trying to make FFmpeg more secure.
He has always complied with official decisions.

However this might turn into publicity nightmare,
as security community is known to overreact
on certain topics.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

2017-06-11 Thread Ivan Kalvachev
On 6/10/17, James Darnley  wrote:
> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>> On 6/9/17, Michael Niedermayer  wrote:
>>> seems this breaks build with mingw64, didnt investigate but it
>>> fails with these errors:
>>>
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>> collect2: error: ld returned 1 exit status
>>> collect2: error: ld returned 1 exit status
>>> make: *** [ffmpeg_g.exe] Error 1
>>> make: *** Waiting for unfinished jobs
>>> make: *** [ffprobe_g.exe] Error 1
>>
>>
>> const_*_edge is used on only one place is the code.
>> Would you check if this patch fixes the issue.
>>
>> I expected that the addresses would be pre-calculated
>> by n/yasm as one value and indexed
>> relative to the section start.
>> Instead it seems that each entry is represented with
>> its own address and offset from it.
>> Since the offset is negative it uses all 64 bits and
>> it makes difference if it is truncated to 32 bits.
>>
>> Same issue could happen with clang tools.
>
> The problem is with the relative addressing.  You need to load the real
> address first before you can offset with another register at runtime. So
> something like:
>
>> mov  reg1,  [read_only_const]
lea ?
>> mova mmreg, [reg1 + reg2]

.
OK, Getting mingw for my distro is problem
and compiling one myself would take a bit more effort/time.
So I'm posting a patch that "should" work.
==
--- a/libavcodec/x86/opus_pvq_search.asm
+++ b/libavcodec/x86/opus_pvq_search.asm
@@ -406,7 +406,7 @@ align 16
 ; uint32 N  - Number of vector elements. Must be 0 < N < 8192
 ;
 %macro PVQ_FAST_SEARCH 0
-cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
+cglobal pvq_search,4,6,8, mmsize, inX, outY, K, N
 %define tmpX rsp

 ;movsxdifnidn Nq,  Nd
@@ -419,7 +419,12 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
 add Nq,   r4q   ; Nq = align(Nq, mmsize)
 sub rsp,  Nq; allocate tmpX[Nq]

+%ifdef PIC
+lea r5q,  [const_align_abs_edge]; rip+const
+movups  m3,   [r5q+r4q-mmsize]  ; this is
the bit mask for the padded read at the end of the input
+%else
 movups  m3,   [const_align_abs_edge-mmsize+r4q] ; this is
the bit mask for the padded read at the end of the input
+%endif

 lea r4q,  [Nq-mmsize]   ; Nq is rounded up (aligned
up) to mmsize, so r4q can't become negative here, unless N=0.
 movups  m2,   [inXq + r4q]
==

What I find surprising is that PIC is enabled only on Windows and does not seem
to depend on CONFIG_PIC, so textrels are used all over assembly code.
Do I miss something?

Are there option(s) to signal/error when texrel is been used in code
that should be pic ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [WIP][PATCH] Opus Piramid Vector Quantization Search in x86 SIMD asm

2017-06-11 Thread Ivan Kalvachev
On 6/11/17, Hendrik Leppkes  wrote:
> On Sun, Jun 11, 2017 at 11:34 AM, Ivan Kalvachev 
> wrote:
>> On 6/10/17, James Darnley  wrote:
>>> On 2017-06-09 13:41, Ivan Kalvachev wrote:
>>>> On 6/9/17, Michael Niedermayer  wrote:
>>>>> seems this breaks build with mingw64, didnt investigate but it
>>>>> fails with these errors:
>>>>>
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x2d):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x3fd):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0x7a1):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> libavcodec/libavcodec.a(opus_pvq_search.o):src/libavcodec/x86/opus_pvq_search.asm:(.text+0xb48):
>>>>> relocation truncated to fit: R_X86_64_32 against `const_align_abs_edge'
>>>>> collect2: error: ld returned 1 exit status
>>>>> collect2: error: ld returned 1 exit status
>>>>> make: *** [ffmpeg_g.exe] Error 1
>>>>> make: *** Waiting for unfinished jobs
>>>>> make: *** [ffprobe_g.exe] Error 1
>>>>
>>>>
>>>> const_*_edge is used on only one place is the code.
>>>> Would you check if this patch fixes the issue.
>>>>
>>>> I expected that the addresses would be pre-calculated
>>>> by n/yasm as one value and indexed
>>>> relative to the section start.
>>>> Instead it seems that each entry is represented with
>>>> its own address and offset from it.
>>>> Since the offset is negative it uses all 64 bits and
>>>> it makes difference if it is truncated to 32 bits.
>>>>
>>>> Same issue could happen with clang tools.
>>>
>>> The problem is with the relative addressing.  You need to load the real
>>> address first before you can offset with another register at runtime. So
>>> something like:
>>>
>>>> mov  reg1,  [read_only_const]
>> lea ?
>>>> mova mmreg, [reg1 + reg2]
>>
>> .
>> OK, Getting mingw for my distro is problem
>> and compiling one myself would take a bit more effort/time.
>> So I'm posting a patch that "should" work.
>> ==
>> --- a/libavcodec/x86/opus_pvq_search.asm
>> +++ b/libavcodec/x86/opus_pvq_search.asm
>> @@ -406,7 +406,7 @@ align 16
>>  ; uint32 N  - Number of vector elements. Must be 0 < N < 8192
>>  ;
>>  %macro PVQ_FAST_SEARCH 0
>> -cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
>> +cglobal pvq_search,4,6,8, mmsize, inX, outY, K, N
>>  %define tmpX rsp
>>
>>  ;movsxdifnidn Nq,  Nd
>> @@ -419,7 +419,12 @@ cglobal pvq_search,4,5,8, mmsize, inX, outY, K, N
>>  add Nq,   r4q   ; Nq = align(Nq, mmsize)
>>  sub rsp,  Nq; allocate tmpX[Nq]
>>
>> +%ifdef PIC
>> +lea r5q,  [const_align_abs_edge]; rip+const
>> +movups  m3,   [r5q+r4q-mmsize]  ; this is
>> the bit mask for the padded read at the end of the input
>> +%else
>>  movups  m3,   [const_align_abs_edge-mmsize+r4q] ; this is
>> the bit mask for the padded read at the end of the input
>> +%endif
>>
>>  lea r4q,  [Nq-mmsize]   ; Nq is rounded up (aligned
>> up) to mmsize, so r4q can't become negative here, unless N=0.
>>  movups  m2,   [inXq + r4q]
>> ==
>>
>> What I find surprising is that PIC is enabled only on Windows and does not
>> seem
>> to depend on CONFIG_PIC, so textrels are used all over assembly code.
>> Do I miss something?
>>
>
> Win32 code is always PIC, independent of what ffmpeg configure thinks
> it should be. :)
> Using the PIC define seems to be the appropriate thing, thats what the
> other asm code does.
>

Yes, but my query is more about
why CONFIG_PIC does not enable asm PIC too?
After all gcc -fpic is supposed to generate code without texrel, isn't it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: Write Tags element for WebM

2017-09-07 Thread Ivan Janatra
This is already supported per https://www.webmproject.org/docs/container/#Tags 
and 
https://github.com/nbirkbeck/matroska-specification/commit/28a54f991f118fff31fe6bfe256c2dfab46d00e5
---
 libavformat/matroskaenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 9cc7be352e..5b70fead87 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1988,12 +1988,12 @@ static int mkv_write_header(AVFormatContext *s)
 ret = mkv_write_attachments(s);
 if (ret < 0)
 goto fail;
-
-ret = mkv_write_tags(s);
-if (ret < 0)
-goto fail;
 }
 
+ret = mkv_write_tags(s);
+if (ret < 0)
+goto fail;
+
 if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live)
 mkv_write_seekhead(pb, mkv);
 
-- 
2.14.1.581.gf28d330327-goog

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


[FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: Write Tags element for WebM

2017-09-08 Thread Ivan Janatra
This is already supported per https://www.webmproject.org/docs/container/#Tags 
and 
https://github.com/nbirkbeck/matroska-specification/commit/28a54f991f118fff31fe6bfe256c2dfab46d00e5

Signed-off-by: Ivan Janatra 
---
 libavformat/matroskaenc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 9cc7be352e..5b70fead87 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -1988,12 +1988,12 @@ static int mkv_write_header(AVFormatContext *s)
 ret = mkv_write_attachments(s);
 if (ret < 0)
 goto fail;
-
-ret = mkv_write_tags(s);
-if (ret < 0)
-goto fail;
 }
 
+ret = mkv_write_tags(s);
+if (ret < 0)
+goto fail;
+
 if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live)
 mkv_write_seekhead(pb, mkv);
 
-- 
2.14.1.581.gf28d330327-goog

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


Re: [FFmpeg-devel] [PATCH] libavformat/matroskaenc.c: Write Tags element for WebM

2017-09-08 Thread Ivan Janatra
SGTM, I'll just wait for your patch then.

On Fri, Sep 8, 2017 at 3:33 PM, James Almer  wrote:

> On 9/8/2017 12:59 PM, Ivan Janatra wrote:
> > This is already supported per https://www.webmproject.org/
> docs/container/#Tags and https://github.com/nbirkbeck/
> matroska-specification/commit/28a54f991f118fff31fe6bfe256c2dfab46d00e5
> >
> > Signed-off-by: Ivan Janatra 
> > ---
> >  libavformat/matroskaenc.c | 8 
> >  1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > index 9cc7be352e..5b70fead87 100644
> > --- a/libavformat/matroskaenc.c
> > +++ b/libavformat/matroskaenc.c
> > @@ -1988,12 +1988,12 @@ static int mkv_write_header(AVFormatContext *s)
> >  ret = mkv_write_attachments(s);
> >  if (ret < 0)
> >  goto fail;
> > -
> > -ret = mkv_write_tags(s);
> > -if (ret < 0)
> > -goto fail;
> >  }
> >
> > +ret = mkv_write_tags(s);
> > +if (ret < 0)
> > +goto fail;
> > +
> >  if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL) && !mkv->is_live)
> >  mkv_write_seekhead(pb, mkv);
>
> This is incomplete, as it's allowing attachment and chapter tags to be
> written to webm files, when TagChapterUID and TagAttachmentUID elements
> are not allowed according to the spec you linked.
>
> See https://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/211863.html
> I'll push that soon unless someone has comments.
> ___
> 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] Bump major versions of all libraries

2017-09-10 Thread Ivan Kalvachev
On 9/2/17, James Almer  wrote:
[...]
> Notes:
> I have no way to test what effect the removal of XVMC truly has.
> The decoders are removed but unlike libav we have hwaccels that are not
> removed by this. Similarly, the pixfmt is also not removed in our case.
> Commit dcc39ee10e82833ce24aa57926c00ffeb1948198 does a thorough removal
> of the remnants of this functionality, but given the above i don't know
> if that applies to us the same way.
> I assume the hwaccels are meant to stay and work after this, so someone
> that knows this code and functionality and has a system where it can be
> tested should ideally look at this.

I assume that the above commit is from libav?
If so yes, it is the wrong thing to do.

The code has been reworked so player
uses pix_fmt to select acceleration,
thus no special decoders are needed.
It's like other hwaccel formats.

If you want I can send a patch that removes the disabled
XvMC functionality and leaves the enabled one.
If you do it instead, be careful, there are both #ifdef and #ifdef !not's,
afair.

MPlayer has been changed to use the new API years ago,
so it should work (with recompilation, but that's given at API bump).

I cannot test it ATM, because of HW issues.
I'll try to do this shortly.

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


Re: [FFmpeg-devel] [PATCH] Bump major versions of all libraries

2017-10-08 Thread Ivan Kalvachev
On 9/10/17, James Almer  wrote:
> On 9/10/2017 2:55 PM, Ivan Kalvachev wrote:
>> On 9/2/17, James Almer  wrote:
>> [...]
>>> Notes:
>>> I have no way to test what effect the removal of XVMC truly has.
>>> The decoders are removed but unlike libav we have hwaccels that are not
>>> removed by this. Similarly, the pixfmt is also not removed in our case.
>>> Commit dcc39ee10e82833ce24aa57926c00ffeb1948198 does a thorough removal
>>> of the remnants of this functionality, but given the above i don't know
>>> if that applies to us the same way.
>>> I assume the hwaccels are meant to stay and work after this, so someone
>>> that knows this code and functionality and has a system where it can be
>>> tested should ideally look at this.
>>
>> I assume that the above commit is from libav?
>> If so yes, it is the wrong thing to do.
>>
>> The code has been reworked so player
>> uses pix_fmt to select acceleration,
>> thus no special decoders are needed.
>> It's like other hwaccel formats.
>>
>> If you want I can send a patch that removes the disabled
>> XvMC functionality and leaves the enabled one.
>> If you do it instead, be careful, there are both #ifdef and #ifdef !not's,
>> afair.
>
> I'd very much prefer if you can do it. Adapt the codebase in a way that
> simply flipping the FF_API_XVMC define from 1 to 0 disables the
> deprecated code (and potentially enables new code in necessary, like the
> stuff in pixfmt.h).
> I have no way to test this functionality so anything i could do would be
> just a wild guess.

I just built it with FF_API_XVMC 0 and it works just as well as before.

The hwaccel changes were done after libav deprecation merges,
so it has always been OK.

There is however unrelated bug that affects both new and old api.
It seems related to idct permutations. I'll try to find a fix asap.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] Fix visual glitch with XvMC, caused by wrong idct permutation.

2017-10-08 Thread Ivan Kalvachev
In the past XvMC forced simple_idct since
it was using FF_IDCT_PERM_NONE.
However now we have SIMD variants of simple_idct that
are using FF_IDCT_PERM_TRANSPOSE and if they are selected
XvMC would get coefficients in the wrong order.

The patch creates new FF_IDCT_NONE that
is used only for this kind of hardware decoding
and that fallbacks to the old C only simple idct.

BTW,
If you have idea for a better name, tell me, I might change it.
I thought of FF_IDCT_HWACCEL_PASSTHROUGHT but it is too huge and ugly.
For some reason mpeg12 vdpau also uses the same idct, so using XVMC in
the name doesn't seem right. (I'm not sure why vdpau needs it...)

I also was thinking of using "-1" number for the define, but ...
I didn't want to risk with it.

Best Regards
   Ivan Kalvachev.
From 88a5f15f8ea04a5fb4eb135e1e773f92bb56a6e0 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Mon, 9 Oct 2017 01:25:00 +0300
Subject: [PATCH] Fix visual glitch with XvMC, caused by wrong idct
 permutation.

In the past XvMC forced simple_idct since
it was using FF_IDCT_PERM_NONE.
However now we have SIMD variants of simple_idct that
are using FF_IDCT_PERM_TRANSPOSE and if they are selected
XvMC would get coefficients in the wrong order.

The patch creates new FF_IDCT_NONE that
is used only for this kind of hardware decoding
and that fallbacks to the old C only simple idct.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/avcodec.h   | 1 +
 libavcodec/idctdsp.c   | 1 +
 libavcodec/mpeg12dec.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0ca..ca0cac501 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3147,6 +3147,7 @@ typedef struct AVCodecContext {
 #define FF_IDCT_SIMPLEALPHA   23
 #endif
 #define FF_IDCT_SIMPLEAUTO128
+#define FF_IDCT_NONE  129 /* Used by XvMC to extract IDCT coefficients with FF_IDCT_PERM_NONE */
 
 /**
  * bits per sample/pixel from the demuxer (needed for huffyuv).
diff --git a/libavcodec/idctdsp.c b/libavcodec/idctdsp.c
index d596aed1a..45b29d6b7 100644
--- a/libavcodec/idctdsp.c
+++ b/libavcodec/idctdsp.c
@@ -279,6 +279,7 @@ av_cold void ff_idctdsp_init(IDCTDSPContext *c, AVCodecContext *avctx)
 c->perm_type = FF_IDCT_PERM_NONE;
 #endif /* CONFIG_FAANIDCT */
 } else { // accurate/default
+/* Be sure FF_IDCT_NONE will select this one, since it uses FF_IDCT_PERM_NONE */
 c->idct_put  = ff_simple_idct_put_8;
 c->idct_add  = ff_simple_idct_add_8;
 c->idct  = ff_simple_idct_8;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 22c29c150..4e68be27f 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1217,7 +1217,7 @@ static void setup_hwaccel_for_pixfmt(AVCodecContext *avctx)
 #endif
 )
 if (avctx->idct_algo == FF_IDCT_AUTO)
-avctx->idct_algo = FF_IDCT_SIMPLE;
+avctx->idct_algo = FF_IDCT_NONE;
 
 if (avctx->hwaccel && avctx->pix_fmt == AV_PIX_FMT_XVMC) {
 Mpeg1Context *s1 = avctx->priv_data;
-- 
2.14.1

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


[FFmpeg-devel] [PATCH] Fix crash if av_vdpau_bind_context() is not used.

2017-10-08 Thread Ivan Kalvachev
The public functions av_alloc_vdpaucontext() and
av_vdpau_alloc_context() are allocating AVVDPAUContext
structure that is supposed to be placed in avctx->hwaccel_context.

However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
as struct VDPAUHWContext, that is bigger and does contain
AVVDPAUContext as first member.

The usage includes write to the new variables in the bigger stuct,
without checking for block size.

Fix by always allocating the bigger structure.

BTW,
I have no idea why the new fields haven't simply been added to the
existing struct...
It seems that the programmer who wrote this has been aware of the problem,
because av_vdpau_bind_context reallocates the structure.

It might be good idea to check the other usages of this reallocation function.

Best Regards
   Ivan Kalvachev
From c9dafbf5402ebf8c68bf8648ecea7a74282113a8 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Mon, 9 Oct 2017 02:40:26 +0300
Subject: [PATCH] Fix crash if av_vdpau_bind_context() is not used.

The public functions av_alloc_vdpaucontext() and
av_vdpau_alloc_context() are allocating AVVDPAUContext
structure that is supposed to be placed in avctx->hwaccel_context.

However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
as struct VDPAUHWContext, that is bigger and does contain
AVVDPAUContext as first member.

The usage includes write to the new variables in the bigger stuct,
without checking for block size.

Fix by always allocating the bigger structure.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/vdpau.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/vdpau.c b/libavcodec/vdpau.c
index 42ebddbee..4cc51cb79 100644
--- a/libavcodec/vdpau.c
+++ b/libavcodec/vdpau.c
@@ -816,7 +816,7 @@ do {   \
 
 AVVDPAUContext *av_vdpau_alloc_context(void)
 {
-return av_mallocz(sizeof(AVVDPAUContext));
+return av_mallocz(sizeof(VDPAUHWContext));
 }
 
 int av_vdpau_bind_context(AVCodecContext *avctx, VdpDevice device,
-- 
2.14.1

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


Re: [FFmpeg-devel] [PATCH] Fix visual glitch with XvMC, caused by wrong idct permutation.

2017-10-09 Thread Ivan Kalvachev
On 10/9/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Oct 8, 2017 at 6:52 PM, Ivan Kalvachev  wrote:
> [..]
>
> Indentation is off in the second hunk, can you fix that?

You want it 4 spaces to the right
or to start from the first position?

BTW, I think it would be better to use "127" number.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v2] Fix visual glitch with XvMC, caused by wrong idct permutation.

2017-10-09 Thread Ivan Kalvachev
On 10/9/17, Michael Niedermayer  wrote:
> On Mon, Oct 09, 2017 at 09:02:38AM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Mon, Oct 9, 2017 at 6:46 AM, Ivan Kalvachev 
>> wrote:
>>
>> > On 10/9/17, Ronald S. Bultje  wrote:
>> > > On Sun, Oct 8, 2017 at 6:52 PM, Ivan Kalvachev 
>> > wrote:
>> > > [..]
>> > >
>> > > Indentation is off in the second hunk, can you fix that?
>> >
>> > You want it 4 spaces to the right

Done.

>>
>> Yes, please.
>>
>> BTW, I think it would be better to use "127" number.
>> >
>>
>> I don't really mind either way. The number 128 suggests it may have been
>> intended as a bitmask. Michael is probably better positioned to comment
>> on
>> this.
>
> I don't really remember but i think 128 was chosen for ABI
> compatibility with additions to it from libav. So it should no longer
> matter what values are used on additions

Then I'm using the next free number "24".

Please, commit when you think it is appropriate.

Best Regards
   Ivan Kalvachev
From 8842a69091b5eb5cf9b704b3ff504d21db4aad9b Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Mon, 9 Oct 2017 01:25:00 +0300
Subject: [PATCH] Fix visual glitch with XvMC, caused by wrong idct
 permutation.

In the past XvMC forced simple_idct since
it was using FF_IDCT_PERM_NONE.
However now we have SIMD variants of simple_idct that
are using FF_IDCT_PERM_TRANSPOSE and if they are selected
XvMC would get coefficients in the wrong order.

The patch creates new FF_IDCT_NONE that
is used only for this kind of hardware decoding
and that fallbacks to the old C only simple idct.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/avcodec.h   | 1 +
 libavcodec/idctdsp.c   | 1 +
 libavcodec/mpeg12dec.c | 2 +-
 3 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 52cc5b0ca..18c3e3ea1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3146,6 +3146,7 @@ typedef struct AVCodecContext {
 #if FF_API_ARCH_ALPHA
 #define FF_IDCT_SIMPLEALPHA   23
 #endif
+#define FF_IDCT_NONE  24 /* Used by XvMC to extract IDCT coefficients with FF_IDCT_PERM_NONE */
 #define FF_IDCT_SIMPLEAUTO128
 
 /**
diff --git a/libavcodec/idctdsp.c b/libavcodec/idctdsp.c
index d596aed1a..0122d29ef 100644
--- a/libavcodec/idctdsp.c
+++ b/libavcodec/idctdsp.c
@@ -279,6 +279,7 @@ av_cold void ff_idctdsp_init(IDCTDSPContext *c, AVCodecContext *avctx)
 c->perm_type = FF_IDCT_PERM_NONE;
 #endif /* CONFIG_FAANIDCT */
 } else { // accurate/default
+/* Be sure FF_IDCT_NONE will select this one, since it uses FF_IDCT_PERM_NONE */
 c->idct_put  = ff_simple_idct_put_8;
 c->idct_add  = ff_simple_idct_add_8;
 c->idct  = ff_simple_idct_8;
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 22c29c150..4e68be27f 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1217,7 +1217,7 @@ static void setup_hwaccel_for_pixfmt(AVCodecContext *avctx)
 #endif
 )
 if (avctx->idct_algo == FF_IDCT_AUTO)
-avctx->idct_algo = FF_IDCT_SIMPLE;
+avctx->idct_algo = FF_IDCT_NONE;
 
 if (avctx->hwaccel && avctx->pix_fmt == AV_PIX_FMT_XVMC) {
 Mpeg1Context *s1 = avctx->priv_data;
-- 
2.14.1

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


Re: [FFmpeg-devel] [PATCH] Fix crash if av_vdpau_bind_context() is not used.

2017-10-09 Thread Ivan Kalvachev
On 10/9/17, wm4  wrote:
> On Mon, 9 Oct 2017 03:04:53 +0300
> Ivan Kalvachev  wrote:
>
>> The public functions av_alloc_vdpaucontext() and
>> av_vdpau_alloc_context() are allocating AVVDPAUContext
>> structure that is supposed to be placed in avctx->hwaccel_context.
>>
>> However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
>> as struct VDPAUHWContext, that is bigger and does contain
>> AVVDPAUContext as first member.
>>
>> The usage includes write to the new variables in the bigger stuct,
>> without checking for block size.
>>
>> Fix by always allocating the bigger structure.
>>
>> BTW,
>> I have no idea why the new fields haven't simply been added to the
>> existing struct...
>> It seems that the programmer who wrote this has been aware of the problem,
>> because av_vdpau_bind_context reallocates the structure.
>>
>> It might be good idea to check the other usages of this reallocation
>> function.
>>
>> Best Regards
>>Ivan Kalvachev
>
> IMO not really worth fixing at this point, because this is the old-old
> vdpau API. Even av_vdpau_bind_context() (which does not require using
> av_alloc_vdpaucontext()) is deprecated. Or rather should be - I just
> haven't bothered deprecating it because the deprecation dance is too
> messy. In any case, you shouldn't use any of those APIs - use the
> generic hwaccel API instead (setting hw_frames_ctx or hw_device_ctx).

Every bug must be fixed, even if the code is going to be removed next.

Since you "didn't bother" to deprecate it, this code will remain even after
the API bump. And it is still (mis)used by at least one program that
crashed on me.

So it MUST be fixed.

Feel free at any time to mark it as deprecated
and set a deprecation target.


Best Regards
   Ivan Kalvachev
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] libavcodec/proresdec : add qmat dsp with SSE2, AVX2 simd

2017-10-09 Thread Ivan Kalvachev
On 10/9/17, Martin Vignali  wrote:
> 2017-10-07 18:16 GMT+02:00 Ronald S. Bultje :
>
>> Hi Martin,
>>
>> On Sat, Oct 7, 2017 at 11:49 AM, Martin Vignali 
>> wrote:
>>
>> > 2017-10-07 17:30 GMT+02:00 Ronald S. Bultje :
>> > > On Sat, Oct 7, 2017 at 10:22 AM, Martin Vignali <
>> > martin.vign...@gmail.com>
>> > > wrote:
>> > > > Patch in attach add a new dsp
>> > > > for manipulation of qmat
>> > > >
>> > > > for now, i move this code inside
>> > > >
>> > > > for (i = 0; i < 64; i++) {
>> > > > qmat_luma_scaled  [i] = ctx->qmat_luma  [i] * qscale;
>> > > > qmat_chroma_scaled[i] = ctx->qmat_chroma[i] * qscale;
>> > > > }
>> > > >
>> > > > i add a special case for qscale == 1
>> > > > and SSE2, AVX2 optimization
>> > >
>> > > This loop only executes once per slice. We typically do not
>> SIMD-optimize
>> > > at that level, because it won't give significant speed gains...
>> >
>> > Ok didn't know that.
>> > I mostly follow, what there are already done, like in
>> blockdsp.clear_block
>> >
>>
>> Right, so consider that blockdsp is done per block (16x16 pixels), not per
>> slice.
>>
> Ok on principle (only improve, a func which is called quite often)

It's more of:  We can't refuse code that makes a measurable improvement.

Also have in mind that compilers are getting smarter and this code is
good target for auto-vectorization. Of course FFmpeg disables is,
because of long history of compiler bugs related to it.

>> You could remove this entirely from the slice processing code by simply
>> pre-calculating the values in the init function once for the whole stream,
>> there's only 224 qscale values so it's 224*64*2 multiplications, which is
>> (in the context of prores) virtually negligible.
>>
>
> Not sure, we can do that for prores decoder
> the qmat seems to be set on the decode frame header func
> (based on the header of the frame).

You can at least check if the qscale has changed and avoid recalculation.
I think that the lgpl decoder does that.

Best Regards
   Ivan Kalvachev
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix crash if av_vdpau_bind_context() is not used.

2017-10-11 Thread Ivan Kalvachev
On 10/10/17, wm4  wrote:
> On Tue, 10 Oct 2017 03:24:56 +0300
> Ivan Kalvachev  wrote:
>
>> On 10/9/17, wm4  wrote:
>> > On Mon, 9 Oct 2017 03:04:53 +0300
>> > Ivan Kalvachev  wrote:
>> >
>> >> The public functions av_alloc_vdpaucontext() and
>> >> av_vdpau_alloc_context() are allocating AVVDPAUContext
>> >> structure that is supposed to be placed in avctx->hwaccel_context.
>> >>
>> >> However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
>> >> as struct VDPAUHWContext, that is bigger and does contain
>> >> AVVDPAUContext as first member.
>> >>
>> >> The usage includes write to the new variables in the bigger stuct,
>> >> without checking for block size.
>> >>
>> >> Fix by always allocating the bigger structure.
>> >>
>> >> BTW,
>> >> I have no idea why the new fields haven't simply been added to the
>> >> existing struct...
>> >> It seems that the programmer who wrote this has been aware of the
>> >> problem,
>> >> because av_vdpau_bind_context reallocates the structure.
>> >>
>> >> It might be good idea to check the other usages of this reallocation
>> >> function.
>> >>
>> >> Best Regards
>> >>Ivan Kalvachev
>> >
>> > IMO not really worth fixing at this point, because this is the old-old
>> > vdpau API. Even av_vdpau_bind_context() (which does not require using
>> > av_alloc_vdpaucontext()) is deprecated. Or rather should be - I just
>> > haven't bothered deprecating it because the deprecation dance is too
>> > messy. In any case, you shouldn't use any of those APIs - use the
>> > generic hwaccel API instead (setting hw_frames_ctx or hw_device_ctx).
>>
>> Every bug must be fixed, even if the code is going to be removed next.
>>
>> Since you "didn't bother" to deprecate it, this code will remain even
>> after
>> the API bump. And it is still (mis)used by at least one program that
>> crashed on me.
>>
>> So it MUST be fixed.
>
> Well, if you insist, feel free to attempt to maintain it, but I won't
> care, even if I make changes to the code under the newer API (about
> which I care). I tried to remove some vdpau code earlier which had
> been deprecated for years, but this was rejected, so why care about
> deprecation or whether an ancient API is actually broken? Not me.

You are not making any sense.

Anyway. Do you have any objection for this patch to be committed?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix crash if av_vdpau_bind_context() is not used.

2017-10-12 Thread Ivan Kalvachev
On 10/11/17, Ivan Kalvachev  wrote:
> On 10/10/17, wm4  wrote:
>> On Tue, 10 Oct 2017 03:24:56 +0300
>> Ivan Kalvachev  wrote:
>>
>>> On 10/9/17, wm4  wrote:
>>> > On Mon, 9 Oct 2017 03:04:53 +0300
>>> > Ivan Kalvachev  wrote:
>>> >
>>> >> The public functions av_alloc_vdpaucontext() and
>>> >> av_vdpau_alloc_context() are allocating AVVDPAUContext
>>> >> structure that is supposed to be placed in avctx->hwaccel_context.
>>> >>
>>> >> However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
>>> >> as struct VDPAUHWContext, that is bigger and does contain
>>> >> AVVDPAUContext as first member.
>>> >>
>>> >> The usage includes write to the new variables in the bigger stuct,
>>> >> without checking for block size.
>>> >>
>>> >> Fix by always allocating the bigger structure.
>>> >>
>>> >> BTW,
>>> >> I have no idea why the new fields haven't simply been added to the
>>> >> existing struct...
>>> >> It seems that the programmer who wrote this has been aware of the
>>> >> problem,
>>> >> because av_vdpau_bind_context reallocates the structure.
>>> >>
>>> >> It might be good idea to check the other usages of this reallocation
>>> >> function.
>>> >>
>>> >> Best Regards
>>> >>Ivan Kalvachev
>>> >
>>> > IMO not really worth fixing at this point, because this is the old-old
>>> > vdpau API. Even av_vdpau_bind_context() (which does not require using
>>> > av_alloc_vdpaucontext()) is deprecated. Or rather should be - I just
>>> > haven't bothered deprecating it because the deprecation dance is too
>>> > messy. In any case, you shouldn't use any of those APIs - use the
>>> > generic hwaccel API instead (setting hw_frames_ctx or hw_device_ctx).
>>>
>>> Every bug must be fixed, even if the code is going to be removed next.
>>>
>>> Since you "didn't bother" to deprecate it, this code will remain even
>>> after
>>> the API bump. And it is still (mis)used by at least one program that
>>> crashed on me.
>>>
>>> So it MUST be fixed.
>>
>> Well, if you insist, feel free to attempt to maintain it, but I won't
>> care, even if I make changes to the code under the newer API (about
>> which I care). I tried to remove some vdpau code earlier which had
>> been deprecated for years, but this was rejected, so why care about
>> deprecation or whether an ancient API is actually broken? Not me.
>
> You are not making any sense.
>
> Anyway. Do you have any objection for this patch to be committed?

I'd like this fix to be committed before the 3.4 release.
Anybody?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Fix crash if av_vdpau_bind_context() is not used.

2017-10-12 Thread Ivan Kalvachev
On 10/13/17, Carl Eugen Hoyos  wrote:
> 2017-10-09 2:04 GMT+02:00 Ivan Kalvachev :
>> The public functions av_alloc_vdpaucontext() and
>> av_vdpau_alloc_context() are allocating AVVDPAUContext
>> structure that is supposed to be placed in avctx->hwaccel_context.
>>
>> However the rest of libavcodec/vdpau.c uses avctx->hwaccel_context
>> as struct VDPAUHWContext, that is bigger and does contain
>> AVVDPAUContext as first member.
>>
>> The usage includes write to the new variables in the bigger stuct,
>> without checking for block size.
>>
>> Fix by always allocating the bigger structure.
>
> Patch applied and backported.
>
> Thank you, Carl Eugen

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


Re: [FFmpeg-devel] [PATCH] qsvenc: do not re-execute encoding on all positive status codes

2016-11-04 Thread Ivan Uskov
Hello Mark,

Thursday, November 3, 2016, 10:55:05 PM, you wrote:

> From: Anton Khirnov 

> It should only be done for DEVICE_BUSY/IN_EXECUTION

> (cherry picked from commit 0956fd460681e8ccbdae19f135f0d3970bf95c2f)
> Fixes ticket #5924.
> ---
>  libavcodec/qsvenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 7445d5b..ac443c1 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -982,7 +982,7 @@ static int encode_frame(AVCodecContext *avctx, 
> QSVEncContext *q,
>  ret = MFXVideoENCODE_EncodeFrameAsync(q->session, enc_ctrl, surf, 
> bs, sync);
>  if (ret == MFX_WRN_DEVICE_BUSY)
>  av_usleep(500);
-} while (ret >> 0);
> +} while (ret == MFX_WRN_DEVICE_BUSY || ret == MFX_WRN_IN_EXECUTION);

>  if (ret < 0) {
>  av_packet_unref(&new_pkt);

I'm agree, existing check is not correct.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

2016-07-23 Thread Ivan Uskov
Hello Mark,

Friday, July 15, 2016, 1:37:54 PM, you wrote:

MT> On 15/07/16 07:15, Chao Liu wrote:
>> Ivan Uskov  nablet.com> writes:
>> 
>>>
>>> Hello All,
>>>
>>> After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  
>> decoding
>>> aborts  with  crash,  there  are many incorrect places appeared. The 
>> attached
>>> patch fixes the issues but keeps new method of the 'sync' variable 
>> allocation
>>> introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.
>>>
>>> Please review.
>>>
>> 
>> I had the same crashes. After reading the code, you are certainly right.
>> Why nobody review this commit?

MT> Presumably noone was particularly interested at the time, and the submitter 
did
MT> not pursue it.

MT> Looking at it now, the change looks mostly ok to me.  The error paths could
MT> maybe be cleaned up a bit, but I think that's mostly a preexisting problem. 
 Can
MT> we loop without *sync being set?  If so, removing the av_freep(&sync); 
inside
MT> the loop makes it leak in that case.

MT> A slightly clearer commit message might help too.  Maybe something like:

MT> ---
MT> lavc/qsvdec: Fix decoding following incorrect merge

MT> Decoding was broken by d30cf57a7b2097b565db02ecfffbdc9c16423d0e - the
MT> merge didn't properly handle the sync pointers, so it always
MT> segfaulted after submitting a frame to libmfx.
MT> ---

If  you are use qsv, I would like to recommend to roll-back to version before
d30cf57a7b2097b565db02ecfffbdc9c16423d0e
Really  the  d30cf57a7b2097b565db02ecfffbdc9c16423d0e is useless and only
makes code complex and work slow, the sync variable is not mandatory to be
allocated  on  heap  at  all.  libav  guys  did a big mistake when have added
such "feature".



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] Questions about Video Memory in qsv decoders

2016-07-23 Thread Ivan Uskov
Hello 张玉晓,

Friday, July 22, 2016, 4:10:36 AM, you wrote:

张> I have a question when learning ffmpeg qsv decoder and Intel media sdk.

张> The intel media sdk suggest to use Video Memory while doing Hardware
张> decoding, use System Memory while doing Software decoding.

张> FFmpeg only used System Memory to decode with qsv (Intel msdk) in file
张> libavcodec/qsvdec.c. Is there any problem when use Video Memory? 

As qsv modules maintainer I can confirm, yes, there are problems.

First (objective) problem that in common case there are 3 qsv components
should be linked by a pipeline through GPU memory: 
*qsv video decoder
*qsv vpp filter
*qsv video encoder
But current ffmpeg architecture have restrictions to share one common qsv
session between libavcodec and libavfilter.

Second  (subjective) problem that nobody in ffmpeg community is interested to
advance  QSV  codecs. Most of  patches at this year provided by me or by my
colleagues (including tries to solve issue with GPU memory) were rejected or
ignored silently. Moreover, if you will try to clone a latest ffmpeg you found 
qsv
decoder broken, it crashes at any try of use. The patch to fix it was posted
by me at April 25 but was ignored.

If it is acceptable for your purposes I would like to recommend you to look
libav. The qsv-related modules in libav should be more advanced this time.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

2016-07-24 Thread Ivan Uskov
Hello Mark,

Saturday, July 23, 2016, 11:42:46 PM, you wrote:

MT> On 23/07/16 20:33, Ivan Uskov wrote:
>> If  you are use qsv, I would like to recommend to roll-back to version before
>> d30cf57a7b2097b565db02ecfffbdc9c16423d0e
>> Really  the  d30cf57a7b2097b565db02ecfffbdc9c16423d0e is useless and only
>> makes code complex and work slow, the sync variable is not mandatory to be
>> allocated  on  heap  at  all.  libav  guys  did a big mistake when have added
>> such "feature".

MT> Are you sure that works correctly with all streams, maybe one with some
MT> sort of delay?  It looks like you can add multiple things to the fifo in
MT> one call and but then only ever remove one, so using the stack to hold
MT> them across invocations is not appropriate (though failure may be very 
subtle).
Yes, I'm sure.
There are following arguments:
1. Intel's samples by itself use general variable for the 'sync' arg, not
heap allocated.
2. Intel documentation says nothing special for this arg.
3. I did several qsv-based transcoders for windows and linux no any issues
without this questionable trick.
4. A fifo object used previously to keep 'sync' handles already keeps data on
heap :-)

There only one known issue into initial implementation, the fifo size may be not
enough an there is no check for overflow. So at some cases wrapper may
overwrite sync entries in fifo and some decoded frames may be lost. But it is
not related with discussed problem.

MT> (Note that I'm not sufficiently familiar with Media SDK to confidently
MT> assert anything about how this code should behave, so please don't read too 
much into what I say.)

MT> In general I think if you are happy that the previous implementation in
MT> ffmpeg was correct then please do revert, because the code as it is now is 
completely broken.
Ok, will do.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] Questions about Video Memory in qsv decoders

2016-07-24 Thread Ivan Uskov
Hello Michael,

Sunday, July 24, 2016, 12:16:59 AM, you wrote:

MN> On Sat, Jul 23, 2016 at 11:19:59PM +0300, Ivan Uskov wrote:
>> Hello 张玉晓,
>> 
>> Friday, July 22, 2016, 4:10:36 AM, you wrote:
>> 
>> 张> I have a question when learning ffmpeg qsv decoder and Intel media sdk.
>> 
>> 张> The intel media sdk suggest to use Video Memory while doing Hardware
>> 张> decoding, use System Memory while doing Software decoding.
>> 
>> 张> FFmpeg only used System Memory to decode with qsv (Intel msdk) in file
>> 张> libavcodec/qsvdec.c. Is there any problem when use Video Memory? 
>> 
>> As qsv modules maintainer I can confirm, yes, there are problems.
>> 
>> First (objective) problem that in common case there are 3 qsv components
>> should be linked by a pipeline through GPU memory: 
>> *qsv video decoder
>> *qsv vpp filter
>> *qsv video encoder
>> But current ffmpeg architecture have restrictions to share one common qsv
>> session between libavcodec and libavfilter.
>> 
>> Second  (subjective) problem that nobody in ffmpeg community is interested to
>> advance  QSV  codecs. Most of  patches at this year provided by me or by my
>> colleagues (including tries to solve issue with GPU memory) were rejected or
>> ignored silently. Moreover, if you will try to clone a latest ffmpeg you 
>> found qsv
>> decoder broken, it crashes at any try of use. The patch to fix it was posted
>> by me at April 25 but was ignored.

MN> which patches should be applied to fix the issues ?
MN> can you repost them ?
Currently I believe that broken merge from libav should be not improved/fixed
by some way but just reverted because it provides nothing helpful, only
complexity. I will provide new patch soon.

MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


[FFmpeg-devel] [PATCH] qsvdec.c: Revert "Merge commit '3c53627ac17fc6bdea5029be57da1e03b32d265d'"

2016-07-24 Thread Ivan Uskov
Hello All,

This reverts commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e, reversing
changes made to acc155ac55baa95d1c16c0364b02244bc04d83a8.
The commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e provided irrelevant
code complexity and decoding slowdown. But main disadvantage of this commit is 
decoder crash.
So it should be reverted.
Please review.

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-Revert-Merge-commit-3c53627ac17fc6bdea5029be57da1e03.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/qsv: remove MFX_EXTBUFF_CODING_OPTION3

2016-07-24 Thread Ivan Uskov
Hello Zeranoe,

Saturday, June 18, 2016, 7:33:12 AM, you wrote:

zgc> From: Kyle Schwarz 

zgc> 4th generation Intel CPUs don't support MFX_EXTBUFF_CODING_OPTION3.

zgc> This patch fixes bug #5324.
zgc> ---
zgc>  libavcodec/qsvenc.c | 18 --
zgc>  1 file changed, 18 deletions(-)

zgc> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
zgc> index 132cf47..a561df8 100644
zgc> --- a/libavcodec/qsvenc.c
zgc> +++ b/libavcodec/qsvenc.c
zgc> @@ -132,9 +132,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc>  #if QSV_HAVE_CO2
zgc>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
zgc> print_profile(info->CodecProfile), info->CodecLevel);
zgc> @@ -186,12 +183,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc> info->ICQQuality, co2->LookAheadDepth);
zgc>  }
zgc>  #endif
zgc> -#if QSV_HAVE_QVBR
-else if (info->>RateControlMethod == MFX_RATECONTROL_QVBR) {
zgc> -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
zgc> -   co3->QVBRQuality);
zgc> -}
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame: 
%"PRIu16"\n",
zgc> info->NumSlice, info->NumRefFrame);
zgc> @@ -577,12 +568,6 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  .Header.BufferSz = sizeof(co2),
zgc>  };
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 co3 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
zgc> -.Header.BufferSz = sizeof(co3),
zgc> -};
zgc> -#endif
zgc>  
zgc>  mfxExtBuffer *ext_buffers[] = {
zgc>  (mfxExtBuffer*)&extradata,
zgc> @@ -590,9 +575,6 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  #if QSV_HAVE_CO2
zgc>  (mfxExtBuffer*)&co2,
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -(mfxExtBuffer*)&co3,
zgc> -#endif
zgc>  };
zgc>  
zgc>  int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
First, I'm not sure that "4th generation Intel CPUs don't support 
MFX_EXTBUFF_CODING_OPTION3".
Do you have any reference which says it? The documentation says:
"This structure is available since SDK API 1.11.", i.e. it depended by API
level but not by CPU generation.
For any case I believe it is wrong to remove code if some issues are appearing
on old CPUs. Especially if we already have got a pre-processor condition to 
disable
MFX_EXTBUFF_CODING_OPTION3 by correct way. If you have got some
constructive suggestions to improve disabling MFX_EXTBUFF_CODING_OPTION3 by
condition (possible in real-time code, not by preprocessor) please provide.
But stupid disabling of a feature is not the good solution.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


[FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

2016-07-24 Thread Ivan Uskov
Hello All,

I have discovered the following issue:
Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based h264 
decoder uses.
The crash does appear inside the

int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
{
H264Context *h = avctx->priv_data;
return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
}

It is obvious, that casting to H264Context cannot be used for qsv decoder
because there is QSVH2645Context. Similar issue will appear for CUVID
decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
(MediaCodecH264DecContext uses), possible another cases existing.

The caller function is

static int has_decode_delay_been_guessed(AVStream *st)
{
if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
if (!st->info) // if we have left find_stream_info then nb_decoded_frames 
won't increase anymore for stream copy
return 1;
#if CONFIG_H264_DECODER
if (st->internal->avctx->has_b_frames &&
   avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
st->internal->avctx->has_b_frames)
return 1;
#endif
if (st->internal->avctx->has_b_frames<3)
return st->nb_decoded_frames >= 7;
else if (st->internal->avctx->has_b_frames<4)
return st->nb_decoded_frames >= 18;
else
return st->nb_decoded_frames >= 20;
}
...which called by update_initial_timestamps()

Have anybody the idea how it can be correctly fixed?
Looks like has_decode_delay_been_guessed() should be corrected.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

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


[FFmpeg-devel] Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API

2016-07-24 Thread Ivan Uskov
Hello All,

This patch applies same changes as commit 
e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
filter uses to restore annex-B prefixes. 

Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h2645.c-switch-to-the-new-BSF-API.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

2016-07-24 Thread Ivan Uskov
Hello Michael,

Sunday, July 24, 2016, 11:11:32 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> I have discovered the following issue:
>> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> h264 decoder uses.
>> The crash does appear inside the
>> 
>> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> {
>> H264Context *h = avctx->priv_data;
>> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> }
>> 
>> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> because there is QSVH2645Context. Similar issue will appear for CUVID
>> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> (MediaCodecH264DecContext uses), possible another cases existing.
>> 
>> The caller function is
>> 
>> static int has_decode_delay_been_guessed(AVStream *st)
>> {
>> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> if (!st->info) // if we have left find_stream_info then 
>> nb_decoded_frames won't increase anymore for stream copy
>> return 1;
>> #if CONFIG_H264_DECODER
>> if (st->internal->avctx->has_b_frames &&
>>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> st->internal->avctx->has_b_frames)
>> return 1;
>> #endif
>> if (st->internal->avctx->has_b_frames<3)
>> return st->nb_decoded_frames >= 7;
>> else if (st->internal->avctx->has_b_frames<4)
>> return st->nb_decoded_frames >= 18;
>> else
>> return st->nb_decoded_frames >= 20;
>> }
>> ...which called by update_initial_timestamps()
>> 
>> Have anybody the idea how it can be correctly fixed?
>> Looks like has_decode_delay_been_guessed() should be corrected.

MN> this code is not new, this is in git since 4 years
MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
MN> Date:   Mon Jul 2 23:16:59 2012 +020

MN> why does it cause a problem now ?

MN> why does libavformat use hw h264 decoding ?
I do not know that is reason why I'm asking.
I just run ffmpeg like
ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv -vcodec 
h264_qsv -y ./result.mp4
..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
*avctx)

When I replace
#if CONFIG_H264_DECODER
to
#if 0
...all working fine.

I can not say when exactly the issue appeared, about several weeks ago all
worked correct. But current build is broken at this place.


MN> this seems like a bad idea to me, as libavcodec would use
MN> hw decoding too potentially resulting in multiple hw decoders
MN> running at the same time for no good reason.

MN> the one in libavformat is just used to parse a few header values
MN> ideally that should be done in the AVParser for h264 ...

MN> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

2016-07-24 Thread Ivan Uskov
Hello Michael,

Sunday, July 24, 2016, 11:25:29 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>> 
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> >> Hello All,
>> >> 
>> >> I have discovered the following issue:
>> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> >> h264 decoder uses.
>> >> The crash does appear inside the
>> >> 
>> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> >> {
>> >> H264Context *h = avctx->priv_data;
>> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> >> }
>> >> 
>> >> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> >> because there is QSVH2645Context. Similar issue will appear for CUVID
>> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> >> (MediaCodecH264DecContext uses), possible another cases existing.
>> >> 
>> >> The caller function is
>> >> 
>> >> static int has_decode_delay_been_guessed(AVStream *st)
>> >> {
>> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> >> if (!st->info) // if we have left find_stream_info then 
>> >> nb_decoded_frames won't increase anymore for stream copy
>> >> return 1;
>> >> #if CONFIG_H264_DECODER
>> >> if (st->internal->avctx->has_b_frames &&
>> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> >> st->internal->avctx->has_b_frames)
>> >> return 1;
>> >> #endif
>> >> if (st->internal->avctx->has_b_frames<3)
>> >> return st->nb_decoded_frames >= 7;
>> >> else if (st->internal->avctx->has_b_frames<4)
>> >> return st->nb_decoded_frames >= 18;
>> >> else
>> >> return st->nb_decoded_frames >= 20;
>> >> }
>> >> ...which called by update_initial_timestamps()
>> >> 
>> >> Have anybody the idea how it can be correctly fixed?
>> >> Looks like has_decode_delay_been_guessed() should be corrected.
>> 
>> MN> this code is not new, this is in git since 4 years
>> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
>> MN> Date:   Mon Jul 2 23:16:59 2012 +020
>> 
>> MN> why does it cause a problem now ?
>> 
>> MN> why does libavformat use hw h264 decoding ?
>> I do not know that is reason why I'm asking.
>> I just run ffmpeg like
>> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
>> -vcodec h264_qsv -y ./result.mp4
>> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
>> *avctx)
>> 
>> When I replace
>> #if CONFIG_H264_DECODER
>> to
>> #if 0
>> ...all working fine.
>> 
>> I can not say when exactly the issue appeared, about several weeks ago all
>> worked correct. But current build is broken at this place.

MN> can you use git bisect to figure out when this issue appeared?
Ok, I'll try, it will take some time.
MN> was the decoder used in libavformat previously also the hw instead of
MN> sw decoder ?
There are no appropriate methods in hw decoder to be called from libavformat.
So hw decoder exactly was never used.


MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] A question regarding dangerous call inside libavformat\utils.c::has_decode_delay_been_guessed()

2016-07-25 Thread Ivan Uskov
Hello Michael,

Sunday, July 24, 2016, 11:25:29 PM, you wrote:

MN> On Sun, Jul 24, 2016 at 11:18:38PM +0300, Ivan Uskov wrote:
>> Hello Michael,
>> 
>> Sunday, July 24, 2016, 11:11:32 PM, you wrote:
>> 
>> MN> On Sun, Jul 24, 2016 at 09:55:21PM +0300, Ivan Uskov wrote:
>> >> Hello All,
>> >> 
>> >> I have discovered the following issue:
>> >> Latest builds of ffmpeg crashes into the h264.c when *hardware* qsv-based 
>> >> h264 decoder uses.
>> >> The crash does appear inside the
>> >> 
>> >> int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
>> >> {
>> >> H264Context *h = avctx->priv_data;
>> >> return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
>> >> }
>> >> 
>> >> It is obvious, that casting to H264Context cannot be used for qsv decoder
>> >> because there is QSVH2645Context. Similar issue will appear for CUVID
>> >> decoder case (CuvidContext uses), Android MediaCodec H.264 decoder
>> >> (MediaCodecH264DecContext uses), possible another cases existing.
>> >> 
>> >> The caller function is
>> >> 
>> >> static int has_decode_delay_been_guessed(AVStream *st)
>> >> {
>> >> if (st->codecpar->codec_id != AV_CODEC_ID_H264) return 1;
>> >> if (!st->info) // if we have left find_stream_info then 
>> >> nb_decoded_frames won't increase anymore for stream copy
>> >> return 1;
>> >> #if CONFIG_H264_DECODER
>> >> if (st->internal->avctx->has_b_frames &&
>> >>avpriv_h264_has_num_reorder_frames(st->internal->avctx) == 
>> >> st->internal->avctx->has_b_frames)
>> >> return 1;
>> >> #endif
>> >> if (st->internal->avctx->has_b_frames<3)
>> >> return st->nb_decoded_frames >= 7;
>> >> else if (st->internal->avctx->has_b_frames<4)
>> >> return st->nb_decoded_frames >= 18;
>> >> else
>> >> return st->nb_decoded_frames >= 20;
>> >> }
>> >> ...which called by update_initial_timestamps()
>> >> 
>> >> Have anybody the idea how it can be correctly fixed?
>> >> Looks like has_decode_delay_been_guessed() should be corrected.
>> 
>> MN> this code is not new, this is in git since 4 years
>> MN> commit bafa1c7f383d6c1c0f3d207395fe6a574092b7ac
>> MN> Date:   Mon Jul 2 23:16:59 2012 +020
>> 
>> MN> why does it cause a problem now ?
>> 
>> MN> why does libavformat use hw h264 decoding ?
>> I do not know that is reason why I'm asking.
>> I just run ffmpeg like
>> ffmpeg -c:v h264_qsv -i ./Ducks.Take.Off.720p.QHD.CRF24.x264-CtrlHD.mkv 
>> -vcodec h264_qsv -y ./result.mp4
>> ..and it crashes inside avpriv_h264_has_num_reorder_frames(AVCodecContext 
>> *avctx)
>> 
>> When I replace
>> #if CONFIG_H264_DECODER
>> to
>> #if 0
>> ...all working fine.
>> 
>> I can not say when exactly the issue appeared, about several weeks ago all
>> worked correct. But current build is broken at this place.

MN> can you use git bisect to figure out when this issue appeared?
The problem commit is
Sun Jun 12 13:24:27 2016 +0200| [1534ef87c74cc66a117bf61c467641c2129bc964] | 
committer: Clément Bœsch

There are lot changes but this modification made the issue visible:
==
diff --git a/libavcodec/h264.c b/libavcodec/h264.c
index c011527..0de6d91 100644
--- a/libavcodec/h264.c
+++ b/libavcodec/h264.c
 -60,7 +60,7  const uint16_t ff_h264_mb_sizes[4] = { 
256, 384, 512, 768 };
 int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx)
 {
 H264Context *h = avctx->priv_data;
-return h ? h->sps.num_reorder_frames : 0;
+return h && h->ps.sps ? h->ps.sps->num_reorder_frames : 0;
 }
==
I.e. _before_it_worked_wrong_too_ but silently. After the H264Context was
modified and new construction h->ps.sps-> was added it has become critical.


MN> was the decoder used in libavformat previously also the hw instead of
MN> sw decoder ?


MN> [...]



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] ffmpeg stuck in transcoding H264 using QSV

2016-07-26 Thread Ivan Uskov

Hello Chao,

Tuesday, July 26, 2016, 9:04:49 AM, you wrote:

> I tried to debug it a bit by comparing ffmpeg code with intel media SDK.
> There is sth. I don't understand. Not sure whether it's related..
> In ffmpeg, we decode the frame in a loop
> <https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/qsvdec.c#L357>, it
> sleeps and retries as long as MFXVideoDECODE_DecodeFrameAsync returns busy.
> In intel media SDK sample_decode, it calls SyncOperation when
> MFXVideoDECODE_DecodeFrameAsync returns busy.

> Could this be the cause?
The documentation for MFXVideoDECODE_DecodeFrameAsync says:
=
MFX_WRN_DEVICE_BUSY
Hardware device is currently busy. Call this function again in a few 
milliseconds.
=
So if documented way does not work it looks like we have issue inside SDK.
But I will try to double check sample_decode code.

By the way, what is your platform? Linux? Do you use a patched kernel
recommended by Intel for specific sdk version?


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] Fix double free and null dereferences in the qsv decoder

2016-07-29 Thread Ivan Uskov

Hello Yuli,

Wednesday, July 27, 2016, 6:21:41 PM, you wrote:

> This patch fixes the h264_qsv decoder issues mentioned
> in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.

> The patch may be tested by specifying h264_qsv as the decoder to ffplay
> for an h264 encoded file.

> ffplay -vcodec h264_qsv foo.mts

> Signed-off-by: Yuli Khodorkovskiy 
> ---
>  libavcodec/qsvdec.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)

> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 9125700..b462887 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -408,7 +408,7 @@ static int do_qsv_decode(AVCodecContext *avctx, 
> QSVContext *q,
>  return ff_qsv_error(ret);
>  }
>  n_out_frames = av_fifo_size(q->async_fifo) / 
> (sizeof(out_frame)+sizeof(sync));
> -
> +av_freep(&sync);
I'm sorry but it is not actual more. There was the roll-back for
sync allocations on heap at July 24, now there is old good way uses again.

>  if (n_out_frames > q->async_depth || (flush && n_out_frames) ) {
>  AVFrame *src_frame;
>  
> @@ -555,16 +555,18 @@ void ff_qsv_decode_reset(AVCodecContext *avctx, 
> QSVContext *q)
>  }
>  
>  /* Reset output surfaces */
> -av_fifo_reset(q->async_fifo);
+if (q->>async_fifo)
> +av_fifo_reset(q->async_fifo);
>  
>  /* Reset input packets fifo */
> -while (av_fifo_size(q->pkt_fifo)) {
+while (q->>pkt_fifo && av_fifo_size(q->pkt_fifo)) {
>  av_fifo_generic_read(q->pkt_fifo, &pkt, sizeof(pkt), NULL);
>  av_packet_unref(&pkt);
>  }
>  
>  /* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
>  }
>  
>  int ff_qsv_decode_close(QSVContext *q)


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] Fix null dereferences in the qsv decoder

2016-08-07 Thread Ivan Uskov

Hello Yuli,

Friday, July 29, 2016, 6:00:44 PM, you wrote:

> This patch fixes the h264_qsv decoder issues mentioned
> in https://ffmpeg.zeranoe.com/forum/viewtopic.php?t=2962.

> The patch may be tested by specifying h264_qsv as the decoder to ffplay
> for an h264 encoded file.

> ffplay -vcodec h264_qsv foo.mts

> Signed-off-by: Yuli Khodorkovskiy 
> ---
>  libavcodec/qsvdec.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)

> diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
> index 9125700..98585e3 100644
> --- a/libavcodec/qsvdec.c
> +++ b/libavcodec/qsvdec.c
> @@ -555,16 +555,18 @@ void ff_qsv_decode_reset(AVCodecContext *avctx, 
> QSVContext *q)
>  }
>  
>  /* Reset output surfaces */
> -av_fifo_reset(q->async_fifo);
+if (q->>async_fifo)
> +av_fifo_reset(q->async_fifo);
>  
>  /* Reset input packets fifo */
> -while (av_fifo_size(q->pkt_fifo)) {
+while (q->>pkt_fifo && av_fifo_size(q->pkt_fifo)) {
>  av_fifo_generic_read(q->pkt_fifo, &pkt, sizeof(pkt), NULL);
>  av_packet_unref(&pkt);
>  }
>  
>  /* Reset input bitstream fifo */
> -av_fifo_reset(q->input_fifo);
+if (q->>input_fifo)
> +av_fifo_reset(q->input_fifo);
>  }
>  
>  int ff_qsv_decode_close(QSVContext *q)
Really, makes sense.
Looks good for me.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API

2016-08-14 Thread Ivan Uskov

Hello Michael,

Sunday, August 7, 2016, 8:18:54 PM, you wrote:

> On Sun, Jul 24, 2016 at 10:05:27PM +0300, Ivan Uskov wrote:
>> Hello All,
>> 
>> This patch applies same changes as commit 
>> e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
>> of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
>> filter uses to restore annex-B prefixes. 
>> 
>> Please review.
>>   
>> 
>> -- 
>> Best regards,
>>  Ivan  mailto:ivan.us...@nablet.com

>>  qsvdec_h2645.c |  138 
>> -
>>  1 file changed, 107 insertions(+), 31 deletions(-)
>> db4e17da2ddf056018cd049164c77f0073fde1bc  
>> 0001-libavcodec-qsvdec_h2645.c-switch-to-the-new-BSF-API.patch
>> From 70b9f600ffbdc67010aca757dd4cf401f3377078 Mon Sep 17 00:00:00 2001
>> From: Ivan Uskov 
>> Date: Sun, 24 Jul 2016 14:04:36 -0400
>> Subject: [PATCH] libavcodec/qsvdec_h2645.c: switch to the new BSF API This
>>  patch applies same changes as commit 
>> e3dfef8e3c85a64dbe6388117303f5819fa3c6a2
>>  of libav: instead obsolete AVBitStreamFilterContext now new AVBSFContext
>>  filter uses to restore annex-B prefixes.

> Is it correct to say that this commit is
> "Based-on: e3dfef8e3c85a64dbe6388117303f5819fa3c6a2 by Anton Khirnov" ?
Yes, in general it based on this commit, only minor adaptations (ffmpeg use
different function names into the qsvdec.c)


> [...]




-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop issue

2016-08-16 Thread Ivan Uskov

Hello Jun,

Thursday, August 11, 2016, 10:59:51 AM, you wrote:

> From cafa70e97ce48b65e2a4a99782f6ce3557fef755 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Thu, 11 Aug 2016 15:34:01 +0800
> Subject: [PATCH] ffmpeg/qsv: fix QSV-accelerated transcode performance drop
>  issue.

> the merge commit 1b04ea1 "avconv: create simple filtergraphs earlier"
> will init the filtergraphs earlier, then init the QSV transcode can't
> suppose the nb_filters's value, else lead to the QSV transcode performance
> drop.

> Signed-off-by: Jun Zhao 
> ---
>  ffmpeg_qsv.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)

> diff --git a/ffmpeg_qsv.c b/ffmpeg_qsv.c
> index 95a2351..acc54dd 100644
> --- a/ffmpeg_qsv.c
> +++ b/ffmpeg_qsv.c
> @@ -210,8 +210,7 @@ int qsv_transcode_init(OutputStream *ost)
>  
>  /* check if the decoder supports QSV and the output only goes to this 
> stream */
>  ist = input_streams[ost->source_index];
-if (ist->nb_filters || ist->hwaccel_id != HWACCEL_QSV ||
-!ist->dec || !ist->dec->pix_fmts)
+if (ist->hwaccel_id != HWACCEL_QSV || !ist->dec || !ist->dec->pix_fmts)
>  return 0;
>  for (pix_fmt = ist->dec->pix_fmts; *pix_fmt != AV_PIX_FMT_NONE; 
> pix_fmt++)
>  if (*pix_fmt == AV_PIX_FMT_QSV)
Thank, makes sense.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] hwcontext: add a QSV implementation

2016-09-19 Thread Ivan Uskov
if (!constraints->valid_hw_formats)
> +return AVERROR(ENOMEM);
> +
+constraints->>valid_hw_formats[0] = AV_PIX_FMT_QSV;
+constraints->>valid_hw_formats[1] = AV_PIX_FMT_NONE;
> +
> +return 0;
> +}
> +
> +static void qsv_device_free(AVHWDeviceContext *ctx)
> +{
> +AVQSVDeviceContext *hwctx = ctx->hwctx;
> +QSVDevicePriv   *priv = ctx->user_opaque;
> +
+if (hwctx->>session)
> +MFXClose(hwctx->session);
> +
> +av_buffer_unref(&priv->child_device_ctx);
> +av_freep(&priv);
> +}
> +
> +static mfxIMPL choose_implementation(const char *device)
> +{
> +static const struct {
> +const char *name;
> +mfxIMPL impl;
> +} impl_map[] = {
> +{ "auto", MFX_IMPL_AUTO },
> +{ "sw",   MFX_IMPL_SOFTWARE },
> +{ "hw",   MFX_IMPL_HARDWARE },
> +{ "auto_any", MFX_IMPL_AUTO_ANY },
> +{ "hw_any",   MFX_IMPL_HARDWARE_ANY },
> +{ "hw2",  MFX_IMPL_HARDWARE2},
> +{ "hw3",  MFX_IMPL_HARDWARE3},
> +{ "hw4",  MFX_IMPL_HARDWARE4},
> +};
> +
> +mfxIMPL impl = MFX_IMPL_AUTO_ANY;
> +int i;
> +
> +if (device) {
> +for (i = 0; i < FF_ARRAY_ELEMS(impl_map); i++)
> +if (!strcmp(device, impl_map[i].name)) {
> +impl = impl_map[i].impl;
> +break;
> +}
> +if (i == FF_ARRAY_ELEMS(impl_map))
> +impl = strtol(device, NULL, 0);
> +}
> +
> +return impl;
> +}
> +
> +static int qsv_device_create(AVHWDeviceContext *ctx, const char *device,
> + AVDictionary *opts, int flags)
> +{
> +AVQSVDeviceContext *hwctx = ctx->hwctx;
> +QSVDevicePriv *priv;
> +enum AVHWDeviceType child_device_type;
> +AVDictionaryEntry *e;
> +
> +mfxVersionver = { { 3, 1 } };
> +mfxIMPL   impl;
> +mfxHDLhandle;
> +mfxHandleType handle_type;
> +mfxStatus err;
> +int ret;
> +
> +priv = av_mallocz(sizeof(*priv));
> +if (!priv)
> +return AVERROR(ENOMEM);
> +
+ctx->>user_opaque = priv;
+ctx->>free= qsv_device_free;
> +
> +e = av_dict_get(opts, "child_device", NULL, 0);
> +
> +if (CONFIG_VAAPI)
> +child_device_type = AV_HWDEVICE_TYPE_VAAPI;
> +else if (CONFIG_DXVA2)
> +child_device_type = AV_HWDEVICE_TYPE_DXVA2;
> +else {
> +av_log(ctx, AV_LOG_ERROR, "No supported child device type is 
> enabled\n");
> +return AVERROR(ENOSYS);
> +}
> +
> +ret = av_hwdevice_ctx_create(&priv->child_device_ctx, child_device_type,
> + e ? e->value : NULL, NULL, 0);
> +if (ret < 0)
> +return ret;
> +
> +{
> +AVHWDeviceContext  *child_device_ctx =
> (AVHWDeviceContext*)priv->child_device_ctx->data;
> +#if CONFIG_VAAPI
> +AVVAAPIDeviceContext *child_device_hwctx = child_device_ctx->hwctx;
> +handle_type = MFX_HANDLE_VA_DISPLAY;
> +handle = (mfxHDL)child_device_hwctx->display;
> +#elif CONFIG_DXVA2
> +AVDXVA2DeviceContext *child_device_hwctx = child_device_ctx->hwctx;
> +handle_type = MFX_HANDLE_D3D9_DEVICE_MANAGER;
> +handle = (mfxHDL)child_device_hwctx->devmgr;
> +#endif
> +}
> +
> +impl = choose_implementation(device);
> +
> +err = MFXInit(impl, &ver, &hwctx->session);
> +if (err != MFX_ERR_NONE) {
> +av_log(ctx, AV_LOG_ERROR, "Error initializing an MFX session\n");
> +return AVERROR_UNKNOWN;
> +}
> +
> +err = MFXVideoCORE_SetHandle(hwctx->session, handle_type, handle);
> +if (err != MFX_ERR_NONE)
> +return AVERROR_UNKNOWN;
> +
> +return 0;
> +}
> +
> +const HWContextType ff_hwcontext_type_qsv = {
> +.type   = AV_HWDEVICE_TYPE_QSV,
> +.name   = "QSV",
> +
> +.device_hwctx_size  = sizeof(AVQSVDeviceContext),
> +.device_priv_size   = sizeof(QSVDeviceContext),
> +.frames_hwctx_size  = sizeof(AVQSVFramesContext),
> +.frames_priv_size   = sizeof(QSVFramesContext),
> +
> +.device_create  = qsv_device_create,
> +.device_init= qsv_device_init,
> +.frames_get_constraints = qsv_frames_get_constraints,
> +.frames_init= qsv_frames_init,
> +.frames_uninit  = qsv_frames_uninit,
> +.frames_get_buffer  = qsv_get_buffer,
> +.transfer_get_formats   = qsv_transfer_get_formats,
> +.transfer_data_to   = qsv_transfer_data_to,
> +.transfer_data_from = qsv_transfer_data_from,
> +
> +.pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_QSV, 
> AV_PIX_FMT_NONE },
> +};
> diff --git a/libavutil/hwcontext_qsv.h b/libavutil/hwcontext_qsv.h
> new file mode 100644
> index 000..0cd6285
> --- /dev/null
> +++ b/libavutil/hwcontext_qsv.h
> @@ -0,0 +1,52 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#ifndef AVUTIL_HWCONTEXT_QSV_H
> +#define AVUTIL_HWCONTEXT_QSV_H
> +
> +#include 
> +
> +/**
> + * @file
> + * An API-specific header for AV_HWDEVICE_TYPE_QSV.
> + *
> + * This API does not support dynamic frame pools. AVHWFramesContext.pool must
> + * return AVBufferRefs whose data pointer points to an mfxFrameSurface1 
> struct.
> + */
> +
> +/**
> + * This struct is allocated as AVHWDeviceContext.hwctx
> + */
> +typedef struct AVQSVDeviceContext {
> +mfxSession session;
> +} AVQSVDeviceContext;
> +
> +/**
> + * This struct is allocated as AVHWFramesContext.hwctx
> + */
> +typedef struct AVQSVFramesContext {
> +mfxFrameSurface1 *surfaces;
> +intnb_surfaces;
> +
> +/**
> + * A combination of MFX_MEMTYPE_* describing the frame pool.
> + */
> +int frame_type;
> +} AVQSVFramesContext;
> +
> +#endif /* AVUTIL_HWCONTEXT_QSV_H */
This should be a good step to make qsv branches of ffmpeg and libav
closer.
LGTM.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


[FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-15 Thread Ivan Kalvachev
Do not remove HWACCEL flag with FF_API_XVMC since the
flag is supposed to be used as generic one.

---
 libavcodec/avcodec.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d849765..d2a34d8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1027,7 +1027,6 @@ typedef struct RcOverride{
  */
 #define CODEC_CAP_DR1 AV_CODEC_CAP_DR1
 #define CODEC_CAP_TRUNCATED   AV_CODEC_CAP_TRUNCATED
-#if FF_API_XVMC
 /* Codec can export data for HW decoding. This flag indicates that
  * the codec would call get_format() with list that might contain HW
accelerated
  * pixel formats (XvMC, VDPAU, VAAPI, etc). The application can pick
any of them
@@ -1036,7 +1035,6 @@ typedef struct RcOverride{
  * chroma format, resolution etc.
  */
 #define CODEC_CAP_HWACCEL 0x0010
-#endif /* FF_API_XVMC */
 /**
  * Encoder or decoder requires flushing with NULL input at the end in order to
  * give the complete and correct output.
--
From 5d0973a6d1ec8b53d1335bed393bf3e67dc8223a Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Mon, 15 Feb 2016 13:16:52 +0200
Subject: [PATCH 1/2] Do not remove HWACCEL flag with FF_API_XVMC since the
 flag is supposed to be used as generic one.

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/avcodec.h | 2 --
 1 file changed, 2 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index d849765..d2a34d8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1027,7 +1027,6 @@ typedef struct RcOverride{
  */
 #define CODEC_CAP_DR1 AV_CODEC_CAP_DR1
 #define CODEC_CAP_TRUNCATED   AV_CODEC_CAP_TRUNCATED
-#if FF_API_XVMC
 /* Codec can export data for HW decoding. This flag indicates that
  * the codec would call get_format() with list that might contain HW accelerated
  * pixel formats (XvMC, VDPAU, VAAPI, etc). The application can pick any of them
@@ -1036,7 +1035,6 @@ typedef struct RcOverride{
  * chroma format, resolution etc.
  */
 #define CODEC_CAP_HWACCEL 0x0010
-#endif /* FF_API_XVMC */
 /**
  * Encoder or decoder requires flushing with NULL input at the end in order to
  * give the complete and correct output.
-- 
2.6.4

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


[FFmpeg-devel] [PATCH] Keep the new XVMC pixfmt at the old position.

2016-02-15 Thread Ivan Kalvachev
Keep the new XVMC pixfmt at the old position.
It was moved away to preserve ABI compatibility with the fork.

I'm not really sure this one is better,
so I'm ok with dropping it if somebody objects.

Have in mind, triggering FF_API_XVMC will change a lot of AV_PIX_FMT values,
with or without that patch.

---
 libavutil/pixfmt.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index c01c057..8cc2ad3 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -79,6 +79,8 @@ enum AVPixelFormat {
 AV_PIX_FMT_XVMC_MPEG2_MC,///< XVideo Motion Acceleration via
common packet passing
 AV_PIX_FMT_XVMC_MPEG2_IDCT,
 #define AV_PIX_FMT_XVMC AV_PIX_FMT_XVMC_MPEG2_IDCT
+#else /* FF_API_XVMC */
+AV_PIX_FMT_XVMC,  ///< XVideo Motion Acceleration via common
packet passing
 #endif /* FF_API_XVMC */
 AV_PIX_FMT_UYVY422,   ///< packed YUV 4:2:2, 16bpp, Cb Y0 Cr Y1
 AV_PIX_FMT_UYYVYY411, ///< packed YUV 4:1:1, 12bpp, Cb Y0 Y1 Cr Y2 Y3
@@ -277,9 +279,6 @@ enum AVPixelFormat {
 AV_PIX_FMT_BAYER_GBRG16BE, ///< bayer, GBGB..(odd line),
RGRG..(even line), 16-bit samples, big-endian */
 AV_PIX_FMT_BAYER_GRBG16LE, ///< bayer, GRGR..(odd line),
BGBG..(even line), 16-bit samples, little-endian */
 AV_PIX_FMT_BAYER_GRBG16BE, ///< bayer, GRGR..(odd line),
BGBG..(even line), 16-bit samples, big-endian */
-#if !FF_API_XVMC
-AV_PIX_FMT_XVMC,///< XVideo Motion Acceleration via common packet passing
-#endif /* !FF_API_XVMC */
 AV_PIX_FMT_YUV440P10LE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb
sample per 1x2 Y samples), little-endian
 AV_PIX_FMT_YUV440P10BE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb
sample per 1x2 Y samples), big-endian
 AV_PIX_FMT_YUV440P12LE, ///< planar YUV 4:4:0,24bpp, (1 Cr & Cb
sample per 1x2 Y samples), little-endian
-- 
2.6.4
From 0ef3403ea39045787d7f610130f1b62249f050d1 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Mon, 15 Feb 2016 13:38:15 +0200
Subject: [PATCH 2/2] Keep the new XVMC pixfmt at the old position. It was
 moved away to preserve ABI compatibility with the fork.

Signed-off-by: Ivan Kalvachev 
---
 libavutil/pixfmt.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index c01c057..8cc2ad3 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -79,6 +79,8 @@ enum AVPixelFormat {
 AV_PIX_FMT_XVMC_MPEG2_MC,///< XVideo Motion Acceleration via common packet passing
 AV_PIX_FMT_XVMC_MPEG2_IDCT,
 #define AV_PIX_FMT_XVMC AV_PIX_FMT_XVMC_MPEG2_IDCT
+#else /* FF_API_XVMC */
+AV_PIX_FMT_XVMC,  ///< XVideo Motion Acceleration via common packet passing
 #endif /* FF_API_XVMC */
 AV_PIX_FMT_UYVY422,   ///< packed YUV 4:2:2, 16bpp, Cb Y0 Cr Y1
 AV_PIX_FMT_UYYVYY411, ///< packed YUV 4:1:1, 12bpp, Cb Y0 Y1 Cr Y2 Y3
@@ -277,9 +279,6 @@ enum AVPixelFormat {
 AV_PIX_FMT_BAYER_GBRG16BE, ///< bayer, GBGB..(odd line), RGRG..(even line), 16-bit samples, big-endian */
 AV_PIX_FMT_BAYER_GRBG16LE, ///< bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, little-endian */
 AV_PIX_FMT_BAYER_GRBG16BE, ///< bayer, GRGR..(odd line), BGBG..(even line), 16-bit samples, big-endian */
-#if !FF_API_XVMC
-AV_PIX_FMT_XVMC,///< XVideo Motion Acceleration via common packet passing
-#endif /* !FF_API_XVMC */
 AV_PIX_FMT_YUV440P10LE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb sample per 1x2 Y samples), little-endian
 AV_PIX_FMT_YUV440P10BE, ///< planar YUV 4:4:0,20bpp, (1 Cr & Cb sample per 1x2 Y samples), big-endian
 AV_PIX_FMT_YUV440P12LE, ///< planar YUV 4:4:0,24bpp, (1 Cr & Cb sample per 1x2 Y samples), little-endian
-- 
2.6.4

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


Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-15 Thread Ivan Kalvachev
On 2/15/16, Hendrik Leppkes  wrote:
> On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev 
> wrote:
>> Do not remove HWACCEL flag with FF_API_XVMC since the
>> flag is supposed to be used as generic one.
>>
>
> The flag is unused except by the XVMC decoder, so removing it with it
> seems appropriate.

Should I add it to the other hwaccel decoders?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-15 Thread Ivan Kalvachev
On 2/15/16, Hendrik Leppkes  wrote:
> On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev 
> wrote:
>> Do not remove HWACCEL flag with FF_API_XVMC since the
>> flag is supposed to be used as generic one.
>>
>
> The flag is unused except by the XVMC decoder, so removing it with it
> seems appropriate.

Oh, I almost missed it.
Triggering FF_API_XVMC doesn't remove XVMC decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-15 Thread Ivan Kalvachev
On 2/15/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev 
> wrote:
>
>> On 2/15/16, Hendrik Leppkes  wrote:
>> > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev 
>> > wrote:
>> >> Do not remove HWACCEL flag with FF_API_XVMC since the
>> >> flag is supposed to be used as generic one.
>> >>
>> >
>> > The flag is unused except by the XVMC decoder, so removing it with it
>> > seems appropriate.
>>
>> Should I add it to the other hwaccel decoders?
>
>
> Would it have a real-world purpose?

Does any of the other Capability flags serve any real-world purpose?
e.g. CAP_DRAW_HORIZ_BAND or  CAP_DR1.

The *_BAND indicates usage of draw_horiz_band callback().
The * _DR1 indicates usage of get_buffer(),
The *_HWACCEL is supposed to indicate usage of get_format() and
availability of certain data, when it is called.

Since the trend is removing codecs that do only hwaccel,
I think it is useful for the application to know that the codec
can do more than software decoding.

Now I see I've missed that there have been a rename and
I actually have to move the name to AV_CODEC_CAP scheme.

I'd like to hear if you still have objections,
before doing v2 of this patch.

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


Re: [FFmpeg-devel] [PATCH] Keep the new XVMC pixfmt at the old position.

2016-02-15 Thread Ivan Kalvachev
On 2/15/16, Hendrik Leppkes  wrote:
> On Mon, Feb 15, 2016 at 2:23 PM, Ivan Kalvachev 
> wrote:
>> Keep the new XVMC pixfmt at the old position.
>> It was moved away to preserve ABI compatibility with the fork.
>>
>> I'm not really sure this one is better,
>> so I'm ok with dropping it if somebody objects.
>>
>> Have in mind, triggering FF_API_XVMC will change a lot of AV_PIX_FMT
>> values,
>> with or without that patch.
>>
>
> Seems like a pointless change. Personally I would prefer to move it to
> the bottom instead of having it within the first 10 formats in the
> enum.

I would prefer if all hwaccel formats are grouped together :)

Anyway, dropping it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Do not remove HWACCEL flag with FF_API_XVMC

2016-02-16 Thread Ivan Kalvachev
On 2/15/16, Hendrik Leppkes  wrote:
> On Mon, Feb 15, 2016 at 3:13 PM, Ivan Kalvachev 
> wrote:
>> On 2/15/16, Ronald S. Bultje  wrote:
>>> Hi,
>>>
>>> On Mon, Feb 15, 2016 at 8:26 AM, Ivan Kalvachev 
>>> wrote:
>>>
>>>> On 2/15/16, Hendrik Leppkes  wrote:
>>>> > On Mon, Feb 15, 2016 at 2:13 PM, Ivan Kalvachev 
>>>> > wrote:
>>>> >> Do not remove HWACCEL flag with FF_API_XVMC since the
>>>> >> flag is supposed to be used as generic one.
>>>> >>
>>>> >
>>>> > The flag is unused except by the XVMC decoder, so removing it with it
>>>> > seems appropriate.
>>>>
>>>> Should I add it to the other hwaccel decoders?
>>>
>>>
>>> Would it have a real-world purpose?
>>
>> Does any of the other Capability flags serve any real-world purpose?
>> e.g. CAP_DRAW_HORIZ_BAND or  CAP_DR1.
>>
>> The *_BAND indicates usage of draw_horiz_band callback().
>> The * _DR1 indicates usage of get_buffer(),
>
> DR1 could probably be removed as well, since practically every codec
> we have does it this way now.
> But removing existing things and adding new things are entirely
> different topics.

That's not correct - *_HWACCEL isn't new thing either.

You do understand that blocking this change means
removing existing thing, don't you?


>> The *_HWACCEL is supposed to indicate usage of get_format() and
>> availability of certain data, when it is called.
>>
>> Since the trend is removing codecs that do only hwaccel,
>> I think it is useful for the application to know that the codec
>> can do more than software decoding.
>>
>
> This is hardly useful, because hwaccels do not "just work", for proper
> hwaccel support you need to hardcode the available codecs in your
> application and appropriate conditions for them, so things like
> profile checks, hardware compatibility checks, etc can be implemented.
> A generic "this codec does hwaccel" flag is not very useful here.

Yes, it is not mandatory for decoding.

But that's true for all capabilities flag, including the threading ones.
If your application supports threading you can always use the thread
safe functions.

The capability flags are there to make things simpler.

Currently the only way an application could find that given codec
supports hwaccel
is to decode a frame, wait for get_format() callback and check the pixfmt list.

Ronald proposed to implement public function that would
query if given codec support given hwaccel pixfmt.
It's good, but it is not simple.
(Listing decoders is 400+ codecs * 10 hwaccel types,
traversing 40+ element table for each combination.)

It literally cannot be simpler than using the already existing flag.
The bit is already allocated for that, it is kept unused in the new
AV_CODEC_CAP*


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


Re: [FFmpeg-devel] [PATCH] Fix for H.264 configuration parsing

2016-04-13 Thread Ivan Grigoriev
On Tue, Apr 12, 2016 at 11:47 PM, Carl Eugen Hoyos  wrote:

>
> Could you provide such a stream?
>
>

This is a stream I encoded using Android MediaCodec API and it breaks when
I switch resolution. I have another stream that was encoded with a
different encoder and there the transition works perfectly.

breaks:
https://www.dropbox.com/s/z4r4hwexyf99mv8/video_breaks.flv?dl=0

works:
https://www.dropbox.com/s/rge7b6888stsyta/video_works.flv?dl=0

Thank you,
Ivan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] libavcodec/qsvdec.c: Restoring decoding functionality after unsuccessful merge from libav.

2016-04-25 Thread Ivan Uskov
Hello All,

After   commit  d30cf57a7b2097b565db02ecfffbdc9c16423d0e  qsv-based  decoding
aborts  with  crash,  there  are many incorrect places appeared. The attached
patch fixes the issues but keeps new method of the 'sync' variable allocation
introduced in commit d30cf57a7b2097b565db02ecfffbdc9c16423d0e.

Please review.


  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec.c-Restoring-decoding-functionality.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

2016-04-25 Thread Ivan Uskov
Hello All,

The   attached  patch  does  fixes  the  issue  of  frames  duplication when
elementary h.264 stream decodes by qsvdec.

Please review.
  

-- 
Best regards,
 Ivan  mailto:ivan.us...@nablet.com

0001-libavcodec-qsvdec_h2645.c-Bug-fixed-wrong-ticks_per_.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavcodec/qsvdec_h2645.c Bug fixed: wrong ticks_per_frame.

2016-04-25 Thread Ivan Uskov
Hello Derek,

Monday, April 25, 2016, 4:50:28 PM, you wrote:

DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>> The   attached  patch  does  fixes  the  issue  of  frames  duplication when
>> elementary h.264 stream decodes by qsvdec.

DB> Could you perhaps elaborate in the commit message, and a code comment, on
DB> why it must be 2? Where does that value come from, etc.
I do not see a necessity for additional comments because
AVCodecContext::ticks_per_frame is public API and already enough documented:
https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


[FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

2016-04-26 Thread Ivan Uskov
Hello All,

Monday, April 25, 2016, 6:50:18 PM, you wrote:

HL> On Mon, Apr 25, 2016 at 5:44 PM, Ivan Uskov  wrote:
>> Hello Derek,
>>
>> Monday, April 25, 2016, 4:50:28 PM, you wrote:
>>
>> DB> On 4/25/2016 2:14 PM, Ivan Uskov wrote:
>>>> The   attached  patch  does  fixes  the  issue  of  frames  duplication 
>>>> when
>>>> elementary h.264 stream decodes by qsvdec.
>>
>> DB> Could you perhaps elaborate in the commit message, and a code comment, on
>> DB> why it must be 2? Where does that value come from, etc.
>> I do not see a necessity for additional comments because
>> AVCodecContext::ticks_per_frame is public API and already enough documented:
>> https://ffmpeg.org/doxygen/2.8/structAVCodecContext.html#a5c62b9c1528a272923ea2a4b86dea31a
>>

HL> Its not about what the field does, but why this is needed here. So
HL> please explain why its set here, and only for this case.
A have added brief comment to patch and to code, please review the attached 
patch.


-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

0001-Bug-fixed-wrong-ticks_per_frame.-For-H.264-stream-ti.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Bug fixed: wrong ticks_per_frame. For H.264 stream ticks_per_frame should be 2

2016-04-27 Thread Ivan Uskov
Hello Derek,

Tuesday, April 26, 2016, 7:13:19 PM, you wrote:

DB> On 4/26/2016 4:45 PM, wm4 wrote:
>> I can see that this code is run only for h264, and I can see that you
>> set the field to 2. The added comment adds no new information and is
>> useless.

DB> The ticks_per_frame docu literally says "should be 2 for h.264" or 
something.

DB> I only thought it should be in the commit message instead of something akin
DB> to "fix bug".
Since it was added to commit message too, it is not the issue, right?
I  left  the "bug fixed" because it was really the bug which force decoder to
produce doubled frames output.

-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] Remove Derek Buitenhuis from MAINTAINERS

2016-05-20 Thread Ivan Kalvachev
On 5/20/16, Christophe Gisquet  wrote:
> Hi,
>
> 2016-05-20 1:55 GMT+02:00 Lukasz Marek :
>> Is Derek revoked to commit or what? Couldn't he just commit this patch and
>> leave? :P  I was a problem for some people, but I see they still have
>> problems. Let people with problems go away with they problems.
>
> Sorry if you felt ganged up on previously. Hopefully the new Code of
> Conduct will avoid that such situations raise to an unsufferable
> level.
>
> But whatever bad technical blood there have been between the two of
> you, and whoever I may agree technically with, this is uncalled for.
> You're just adding fuel to a tense situation, and causing distress to
> someone.
>
> This type of comment is exactly what should not be allowed by the Code
> of Conduct.

That's adding insult to the injury.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec/qsv: fix coding options

2016-05-30 Thread Ivan Uskov
Hello Kyle,

Saturday, May 28, 2016, 8:07:07 AM, you wrote:

zgc> From: Kyle Schwarz 

zgc> ---
zgc>  libavcodec/qsvenc.c | 34 ++
zgc>  1 file changed, 2 insertions(+), 32 deletions(-)

zgc> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
zgc> index 132cf47..b4821fc 100644
zgc> --- a/libavcodec/qsvenc.c
zgc> +++ b/libavcodec/qsvenc.c
zgc> @@ -132,9 +132,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc>  #if QSV_HAVE_CO2
zgc>  mfxExtCodingOption2 *co2 = (mfxExtCodingOption2*)coding_opts[1];
zgc>  #endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
zgc> -#endif
zgc>  
zgc>  av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
zgc> print_profile(info->CodecProfile), info->CodecLevel);
zgc> @@ -186,13 +183,6 @@ static void dump_video_param(AVCodecContext *avctx, 
QSVEncContext *q,
zgc> info->ICQQuality, co2->LookAheadDepth);
zgc>  }
zgc>  #endif
zgc> -#if QSV_HAVE_QVBR
-else if (info->>RateControlMethod == MFX_RATECONTROL_QVBR) {
zgc> -av_log(avctx, AV_LOG_VERBOSE, "QVBRQuality: %"PRIu16"\n",
zgc> -   co3->QVBRQuality);
zgc> -}
zgc> -#endif
zgc> -
zgc>  av_log(avctx, AV_LOG_VERBOSE, "NumSlice: %"PRIu16"; NumRefFrame: 
%"PRIu16"\n",
zgc> info->NumSlice, info->NumRefFrame);
zgc>  av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
zgc> @@ -567,31 +557,11 @@ static int qsv_retrieve_enc_params(AVCodecContext 
*avctx, QSVEncContext *q)
zgc>  .PPSBuffer = pps_buf, .PPSBufSize = sizeof(pps_buf)
zgc>  };
zgc>  
zgc> -mfxExtCodingOption co = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION,
zgc> -.Header.BufferSz = sizeof(co),
zgc> -};
zgc> -#if QSV_HAVE_CO2
zgc> -mfxExtCodingOption2 co2 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION2,
zgc> -.Header.BufferSz = sizeof(co2),
zgc> -};
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -mfxExtCodingOption3 co3 = {
zgc> -.Header.BufferId = MFX_EXTBUFF_CODING_OPTION3,
zgc> -.Header.BufferSz = sizeof(co3),
zgc> -};
zgc> -#endif
zgc> -
zgc>  mfxExtBuffer *ext_buffers[] = {
zgc>  (mfxExtBuffer*)&extradata,
zgc> -(mfxExtBuffer*)&co,
zgc> +(mfxExtBuffer*)&q->extco,
zgc>  #if QSV_HAVE_CO2
zgc> -(mfxExtBuffer*)&co2,
zgc> -#endif
zgc> -#if QSV_HAVE_CO3
zgc> -(mfxExtBuffer*)&co3,
zgc> +(mfxExtBuffer*)&q->extco2,
zgc>  #endif
zgc>  };
zgc>  
Could you please explain what exactly you are trying to fix by this patch?
I do not like this changes by two reasons:
1.   The   dump_video_param()   intended   to   dump   parameters  returned  by
MFXVideoENCODE_GetVideoParam();  You can  not use q->extco and q->extco2 here
because  are  can be differ that values really used by encoder, here internal
adjustments possible.
2. Disabling preprocessor conditions does break compatibility with different 
MSDK
versions.  For  example  MFX_EXTBUFF_CODING_OPTION2  existing since MSDK 1.6,
MFX_EXTBUFF_CODING_OPTION3 existing since MSDK 1.11



-- 
Best regards,
 Ivanmailto:ivan.us...@nablet.com

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


Re: [FFmpeg-devel] [PATCH] avformat/flvenc: support codec config change mid stream

2016-06-10 Thread Ivan Grigoriev
Resubmitted as two separate commits
http://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195162.html

Ivan Grigoriev

On Fri, Jun 10, 2016 at 1:39 PM, Carl Eugen Hoyos  wrote:

> Ivan  gmail.com> writes:
>
> > +flv_write_codec_header(s, s->streams[i]->codecpar);
>
> If you make facturing out this code a separate commit,
> it will make reviewing much easier.
>
> Carl Eugen
>
> ___
> 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] [VOTE] Ban Carl Eugen Hoyos

2016-06-12 Thread Ivan Kalvachev
On 6/12/16, Paul B Mahol  wrote:
> Hi,
>
> As requested in the IRC meeting I hereby request for the
> voting committee to begin voting on whatever to ban Carl
> Eugen Hoyos from mailing list, trac and IRC for 4 months,
> starting after the voting has finished.

I don't remember such thing to have been requested on the IRC meeting.
Would you kindly quote the relevant parts of the logs?

Also, I would like to know on what grounds and
on what charges you request that punishment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [VOTE] Ban Carl Eugen Hoyos

2016-06-12 Thread Ivan Kalvachev
On 6/13/16, Paul B Mahol  wrote:
> On 6/13/16, Ivan Kalvachev  wrote:
>> On 6/12/16, Paul B Mahol  wrote:
>>> Hi,
>>>
>>> As requested in the IRC meeting I hereby request for the
>>> voting committee to begin voting on whatever to ban Carl
>>> Eugen Hoyos from mailing list, trac and IRC for 4 months,
>>> starting after the voting has finished.
>>
>> I don't remember such thing to have been requested on the IRC meeting.
>> Would you kindly quote the relevant parts of the logs?
>
> It was requested to act because of Carl misbehaviour.
> Logs are available on net.

I was on the meeting and I checked the published logs
before sending my first mail.
That's why I requested that you QUOTE the relevant part.

Let me be blunt. Nobody have requested Carl to be banned,
and definitely not from ML, trac, IRC for 4 months.

Feel free to prove me wrong, by providing the quotes I requested.

>> Also, I would like to know on what grounds and
>> on what charges you request that punishment.
>
> On grounds that he was badmouthing others.

That's way too vague...

1. I'd like to see links and quotes of him doing the things you accuse him of.

2. I'd like to know why we have to ban him for 4 months exactly? Why
ban him from ML, IRC, Trac, but not git?
How did you determined that this punishment is the one that is most
fitting the crimes he has done?

I can give you a lot of repeated incidents where people have badmouthed Carl.
Should we ban them all in a similar way? Months and years after the fact?

Also, If we are going to punish somebody, there should be a due
process before that.
Witch hunts are nasty things.

> Many devs requested punishment.
Did they?

Many people wanted breaking CoC to have consequences.
But I do not remember anybody requesting Carl to be banned for 4 months.
Feel free to prove me wrong, with quotes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] bans

2016-06-15 Thread Ivan Kalvachev
On 6/15/16, Michael Niedermayer  wrote:
> Hi all
>
> As noone is doing anything about the situation and what is being
> done will not lead anywhere (the vote likely wont lead anywhere as
> likely few would ban a active developer 4 month and then if not
> some will feel injustice prevailed thus
>
> After writing this mail i will
>
> 1. ban carl for 24h from the ML due to
> causing  derek to leave the project. (24h was suggested in the IRC
> meeting)
> I suspect carl saw the merges done by derek as causing more bugs than
> good so he attacked until derek stoped doing the merges.
> The correct course of action would have been a vote about stoping the
> merges or a change to the procedure to reduce the amount of bugs.
> Like maybe a seperate branch where merges can be tested for ~24h before
> being pushed to master ...
> Or maybe more people working on fixing regressions
> As a sidenote, most of the regressions should be fixed by now.
>
> 2. ban derek for ~24h from the ML due to causing lukasz to leave the
> project last year, and due to personal insults on the ML and IRC
> to lukasz and carl.
> As derek is not subscribed to the list ATM, this will be implemented
> by moving him from the accept_these_nonmembers list to the
> reject_these_nonmembers list for ~24h
>
> 3. ban myself for ~24h from the ML because i wrote offensive mails too
> years ago and i doubt none was pivotal in causing someone to leave
>
> Thanks

I don't think that these bans would change anything.


The problem is that they would not address
any of the reasons for getting here.

There's been accumulation of a lot of mud,
and what we have seen so far is not even
the tip of the iceberg.

There are people who sincerely believe that
FFmpeg project would be better without Carl.
That Carl hates LibAV project and that hate is
obstruction to the consolidation between the
two projects.

The negativity turns into hostility and provocations.

When Carl complains that some merge breaks FFmpeg,
he is viewed as attacking LibAV and the merger,
even when he is actually only concerned about bugs in FFmpeg.
Then some people think they are in their right to counterattack.

Somebody described the result as:
"it's years of build up displeasure about
the general behavior of a person."

How do you resolve that?

I have no idea.

People don't remember facts, they remember emotions.
And people refuse to acknowledge making mistake,
rejecting any arguments, based on facts and logic.

This basically means that things would only get worse.
Derek's dramatic departure put quite a pain in hearths of
the people who consider him a friend.
They would not forgive Carl for that.



For these who are relatively new to the project,
the same crisis has happened before in FFmpeg,
but with different people.

It was Mans who left FFmpeg, because of Michael's
alleged violations of rules and savage behavior.
There was a vote to keep or kick Michael and the vote kept him.
Things then got silent for few months, until Mans returned by
takeover of FFmpeg project and servers, supported by
a big portion of developers and the other admins.

Takeover at the moment is not really plausible,
since the admins won't support it.

What is plausible is that hostility would remain.
There will be more incidents involving Carl,
some people would push for stricter punishments.

Likely outcomes are:
1. Carl leaves on his own.
2. Carl is banned permanently.
3. Derek friends leave FFmpeg one by one.
4. Derek friends fork FFmpeg.

The first two variants does look like they are
going to be best for FFmpeg, however things
are never this simple. Once Carl is gone,
hostility would be directed to anybody who
opposes in any way the friends circle.

What happened to lukasz, would happen
to a lot more developers and contributors.

This would inevitably lead to stagnation,
lack of manpower, lack of new features,
increase in bugs, long delays in handling security exploits.
All things that are quite common in LibAV project
and also some of main reasons for FFmpeg
replacing it in Debian.
After all, this is how LibAV came to be,
as a circle of friends who got rid of
undesirable developer(s).


So what do you really want?

Do you want to ruin FFmpeg? Because that's how you ruin a project.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] bans

2016-06-16 Thread Ivan Kalvachev
On 6/16/16, James Almer  wrote:
> On 6/15/2016 8:16 PM, Ivan Kalvachev wrote:
>>Loads of crap
>
> No one, and i mean no one reply to this email.
>
> You will not get a single answer to any question you make. All you'll get is
> counter questions. He will make questions he knows the answers for only to
> read the reply in your own words. And once you reply to said questions, your
> answer will be nitpicked expecting you to focus on said comments until the
> conversation is fully derailed.
> Insisting with your questions will be useless.
>
> This is the guy that in a reply to the vote thread said he wasn't aware the
> subject was mentioned in the IRC meeting [1] while in reality he knew well
> about everything and even acknowledged it, as pointed out by Ronald in a
> subsequent email [2].
> He will lie and he will pretend to be unaware of things, be it to not answer
> your questions or to get you to reply his, starting the cycle i mentioned
> above.
>
> This is is a guy that has since day 1 derailed every single conversation and
> tried to put the aggressor as the victim and the victim as the aggressor,
> installing the idea of secret unjustified feuds and invoking old bullshit
> like
> libav's debacle in a perfect godwin's law fashion.
>
> Not a single discussion in IRC where he was involved went anywhere, and
> neither
> will anything in this thread. You'll get inside a spiral of bullshit with no
> end until you decide to stop feeding the troll disguised as worried
> contributor.
>
> [1] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195306.html
> [2] https://ffmpeg.org/pipermail/ffmpeg-devel/2016-June/195344.html

Too late, you already replied and you have demonstrated practically
the things I've described in the mail.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] bans

2016-06-16 Thread Ivan Kalvachev
On 6/16/16, Michael Niedermayer  wrote:
> On Wed, Jun 15, 2016 at 10:50:51AM -0300, James Almer wrote:
>> On 6/15/2016 10:14 AM, Michael Niedermayer wrote:
>> > Hi all
>> >
>> > As noone is doing anything about the situation and what is being
>> > done will not lead anywhere (the vote likely wont lead anywhere as
>> > likely few would ban a active developer 4 month and then if not
>> > some will feel injustice prevailed thus
>> >
>> > After writing this mail i will
>> >
>> > 1. ban carl for 24h from the ML due to
>> > causing  derek to leave the project. (24h was suggested in the IRC
>> > meeting)
>>
>> This is useless IMO. While four months is too much, 24 hours is
>> insignificant.
>>
>
>> Let's not implement bans without a discussion and a vote first.
>
> I agree but if i do nothing people are unhappy that i did nothing,
> if i talk with people trying to resolve a conflict well, it did not
> work this time. and if i do something else people complain too.
> and its 4 weeks since the incident.
> Doing some symbolic action seemed to make sense until the people
> finish discussions and votes.
> I believe i do not have the authority to hand out real (week+) bans,
> nor would i want that authority. Also i will stay away
> from symbolic bans too, this was intended to improve the situation,
> and i believe it did not achieve that.

One way to resolve the matter as mature people would be
asking Carl to explain his words and actions in civilized manner,
then apologize for going over the board.

It is completely counterproductive to escalate the issue with
attempts for public humiliation and punishment,
without making attempts for addressing the bad behavior
they are supposed to stop.



>> The current vote will probably go nowhere, so a proper discussion thread
>> followed by a vote will have to be made.
>
> Yes,
> its up to the vote committee and the community to decide what should
> be done.
>
>
>>
>> > I suspect carl saw the merges done by derek as causing more bugs than
>> > good so he attacked until derek stoped doing the merges.
>>
>> Which is the shitty behavior that's being discussed about. When you find
>> problems you report them, or help fix them. You don't attack the person
>> working on them.
>>
>> > The correct course of action would have been a vote about stoping the
>> > merges or a change to the procedure to reduce the amount of bugs.
>> > Like maybe a seperate branch where merges can be tested for ~24h before
>> > being pushed to master ...
>> > Or maybe more people working on fixing regressions
>> > As a sidenote, most of the regressions should be fixed by now.
>> >
>> > 2. ban derek for ~24h from the ML due to causing lukasz to leave the
>> > project last year, and due to personal insults on the ML and IRC
>> > to lukasz and carl.
>> > As derek is not subscribed to the list ATM, this will be implemented
>> > by moving him from the accept_these_nonmembers list to the
>> > reject_these_nonmembers list for ~24h
>> >
>> > 3. ban myself for ~24h from the ML because i wrote offensive mails too
>> > years ago and i doubt none was pivotal in causing someone to leave
>>
>> And this is silly. It's old history and nobody requested such action in
>> any what whatsoever. It will only derail the discussion and again, bans
>> without discussion or vote are a big no.
>
> It may be unimportant but the "ban" would never have stopped derek from
> subscribing or subsequently posting a message.
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> I have often repented speaking, but never of holding my tongue.
> -- Xenocrates
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Sponsoring feature for H.264 decoding with scaling factor (1/2, 1/4...) (if possible)

2016-06-19 Thread Ivan Kalvachev
On 6/17/16, Eric Beuque  wrote:
> 2016-06-17 19:16 GMT+02:00 Michael Niedermayer :
>
>> On Fri, Jun 17, 2016 at 05:39:23PM +0200, Eric Beuque wrote:
>> > Hi,
>> >
>> > i'm posting here for a feature that is missing in ffmpeg (or may be i
>> > missed something), which consist of decoding H.264 frame with a scaling
>> > factor of 1/2, 1/4, 1/8...
>> >
>> > I found the parameter lowres, which works well with MJPEG stream but
>> > it's
>> > not working with the H.264 decoder.
>> >
>> > I don't know if it's something possible to implement in the decoder, but
>> if
>> > yes, my compagny agreed to sponsor the feature (depending on the cost of
>> > course), if a developer qualified is interested to do it.
>> >
>> > Is someone know if it is possible, and if it can exist someone
>> > interested
>> > to develop this feature?
>>
>> is it acceptable if the encoder enforces some restrictions on the used
>> features ?
>>
>> most general h264 likely cannot efficiently be decoded in lower
>> resolution with acceptable quality
>> Restricting the used intra modes may make it possible to do it though
>> i dont know what the quality would be but better than without
>> restrictions
>>
>> [...]
>>
>
>
> Actually, the main goal is for motion detection algorithm, so we need small
> resolution and best quality is not required. We just need good estimation
> for the moving pixel.
>
> For now, we decode in H.264, and scale it close 320x240, the then we
> perform motion detection on it. The goal is to speed up the process and
> reduce the memory usage since decoding a 2048x1536 picture lead around a 5
> MB for the decoded image in memory.

Have you tried to extract the motion vectors of the H.264 stream itself?

If the encoder supports more than I-frames, it should do some Motion Estimation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding

2016-07-02 Thread Ivan Kalvachev
On 7/2/16, Vignesh Venkatasubramanian  wrote:
> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje 
> wrote:
>> Hi,
>>
>> On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje 
>> wrote:
>>
>>> Hi,
>>>
>>> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
>>> vigneshv-at-google@ffmpeg.org> wrote:
>>>
 On Fri, Jul 1, 2016 at 11:06 AM, James Almer  wrote:
 > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote:
 >> Hi,
 >>
 >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
 jzern-at-google@ffmpeg.org>
 >> wrote:
 >>
 >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos 
 >>> wrote:
 > Do we have decoder support (for either vp8 or vp9) for these
 > files?
 
  No, only encoding and muxing.
 >>>
 >>> Seems like a feature request, but no reason to block this one if the
 >>> vp8 one is here.
 >>
 >>
 >> I'm not sure I have an opinion on this... But it feels strange to
 >> allow
 >> encoding of content we cannot decode. Being ffmpeg, how do we
 >> recommend
 >> people handle the files created with this feature, if not by using
 ffmpeg
 >> itself?

 One plausible reason is that Chrome can decode this. So it will be
 useful for people who already have ffmpeg in their pipelines and want
 to create such files. And like James Almer mentioned, this isn't a
 first. VP8 Alpha has been this way too.
>>>
>>>
>>> The fact that something is the way it is, does not prove that it is
>>> therefore right, or that we should therefore continue doing it that way
>>> in
>>> other cases.
>>>
>>> So you're suggesting that it is perfectly fine for people to use Chrome
>>> as
>>> decoder if FFmpeg is the encoder. What if people don't have Chrome
>>> installed? Or what if they want a way of UI-less batch-processing such
>>> files, e.g. what if a service like Youtube/Vimeo wants to allow upload of
>>> vp8a/vp9a files without invoking Chrome for decoding?
>>>
>>
>> Additional evidence in [1], [2].
>>
>> There absolutely seems to be interest in support for vp8a/vp9a decoding
>> outside Chrome. I'm not saying you should implement it in all multimedia
>> frameworks ever created in human history, but doing it in one of them
>> (e.g.
>> ffmpeg, since it already supports encoding) certainly sounds helpful?
>>
>
> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg.
> I'm just saying that it shouldn't be a reason to block this patch. :)
> Sorry if i wasn't clear before.

The libvpx is used for both encoding and decoding,
so it should be able to decode alpha planes and
provide them to ffmpeg.

Do you have idea how hard is adding decoding support this way?
Can you do it?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libvpx: Enable vp9 alpha encoding

2016-07-02 Thread Ivan Kalvachev
On 7/2/16, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jul 1, 2016 at 5:27 PM, Vignesh Venkatasubramanian <
> vigneshv-at-google@ffmpeg.org> wrote:
>
>> On Fri, Jul 1, 2016 at 12:48 PM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Fri, Jul 1, 2016 at 3:29 PM, Ronald S. Bultje 
>> wrote:
>> >
>> >> Hi,
>> >>
>> >> On Fri, Jul 1, 2016 at 3:12 PM, Vignesh Venkatasubramanian <
>> >> vigneshv-at-google@ffmpeg.org> wrote:
>> >>
>> >>> On Fri, Jul 1, 2016 at 11:06 AM, James Almer 
>> wrote:
>> >>> > On 7/1/2016 2:53 PM, Ronald S. Bultje wrote:
>> >>> >> Hi,
>> >>> >>
>> >>> >> On Fri, Jul 1, 2016 at 1:40 PM, James Zern <
>> >>> jzern-at-google@ffmpeg.org>
>> >>> >> wrote:
>> >>> >>
>> >>> >>> On Fri, Jul 1, 2016 at 10:07 AM, Carl Eugen Hoyos <
>> ceho...@ag.or.at>
>> >>> >>> wrote:
>> >>> > Do we have decoder support (for either vp8 or vp9) for these
>> files?
>> >>> 
>> >>>  No, only encoding and muxing.
>> >>> >>>
>> >>> >>> Seems like a feature request, but no reason to block this one if
>> the
>> >>> >>> vp8 one is here.
>> >>> >>
>> >>> >>
>> >>> >> I'm not sure I have an opinion on this... But it feels strange to
>> allow
>> >>> >> encoding of content we cannot decode. Being ffmpeg, how do we
>> recommend
>> >>> >> people handle the files created with this feature, if not by using
>> >>> ffmpeg
>> >>> >> itself?
>> >>>
>> >>> One plausible reason is that Chrome can decode this. So it will be
>> >>> useful for people who already have ffmpeg in their pipelines and want
>> >>> to create such files. And like James Almer mentioned, this isn't a
>> >>> first. VP8 Alpha has been this way too.
>> >>
>> >>
>> >> The fact that something is the way it is, does not prove that it is
>> >> therefore right, or that we should therefore continue doing it that way
>> in
>> >> other cases.
>> >>
>> >> So you're suggesting that it is perfectly fine for people to use Chrome
>> as
>> >> decoder if FFmpeg is the encoder. What if people don't have Chrome
>> >> installed? Or what if they want a way of UI-less batch-processing such
>> >> files, e.g. what if a service like Youtube/Vimeo wants to allow upload
>> of
>> >> vp8a/vp9a files without invoking Chrome for decoding?
>> >>
>> >
>> > Additional evidence in [1], [2].
>> >
>> > There absolutely seems to be interest in support for vp8a/vp9a decoding
>> > outside Chrome. I'm not saying you should implement it in all multimedia
>> > frameworks ever created in human history, but doing it in one of them
>> (e.g.
>> > ffmpeg, since it already supports encoding) certainly sounds helpful?
>> >
>>
>> I'm not saying alpha decoder shouldn't ever be implemented in ffmpeg.
>> I'm just saying that it shouldn't be a reason to block this patch. :)
>> Sorry if i wasn't clear before.
>
>
> I totally understand that you would think that, since it means you don't
> have to do anything :).
>
> But there's an issue with this thinking. We're essentially already the
> dumping ground for anything multimedia-related nowadays. After all, we
> maintain it and keep it working (assuming basic tests), things couldn't get
> much easier than that, right? But is it actually useful to anyone? I mean
> not just useful for you, but useful to a wider set of people, at least in
> theory.
>
> If there's no decoder, I would claim that the wider utility of this thing
> is essentially zero. And that's somewhat of a concern.
>
> So, how do we get a decoder? vp8a suggests that just waiting for one to
> spontaneously combust out of thin air just doesn't work. So I'm suggesting
> you provide us with one. It's ok if it uses libvpx instead of ffvp8/9.
> Since vp8a encoding is already in, I won't ask for a vp8a decoder either.
> I'm just asking for a vp9a decoder. It might even be OK if it's implemented
> on top of ffmpeg instead of inside libavcodec (I'm not sure how others feel
> about this), i.e. just something that invokes libavformat to parse a webm
> file, create two decoders to get the yuv and a planes, and then merge them
> together into a yuva420p picture. I'm just asking for something _small_ and
> _simple_ (i.e. not "Chrome") that we can point users to when they ask "how
> do I decode vp9a files".
>
> I asked on IRC (#ffmpeg-devel) and several people concurred:
>
>  jamrial: so … I’m looking for a second opinion here, like, an
> independent one… am I being too hard on these guys for saying “an encoder
> needs a decoder”?
>  BBB: I do tend to agree that in general it goes dec->enc, or both at
> the same time. be it a fully lavc decoder or just utilizing a decoder
> library
>  BBB: no, you're not being hard
>
> So it seems I'm not entirely alone in this opinion within the ffmpeg
> developer community.
>
> Ronald


Roland, aren't you one of the main developers of ffvp9?
I remember you have spent a lot of time making it faster.
You know that codec well, don't you?

Thus my question is:
Why are you wasting your time
blocking things that people want,
instead of implementing the alpha plane support

Re: [FFmpeg-devel] [PATCH] doc: clarify development rules

2017-02-25 Thread Ivan Kalvachev
On 2/25/17, wm4  wrote:
> I'm documenting existing practice.
>
> I'm pulling the "6 months" timeout out of my ass, but I think it's
> pretty suitable.
> ---
>  doc/developer.texi | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index dbe1f5421f..41551498ad 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -338,13 +338,21 @@ you applied the patch.
>  When applying patches that have been discussed (at length) on the mailing
>  list, reference the thread in the log message.
>
> -@subheading Always wait long enough before pushing changes
> +@subheading Always wait long enough before pushing changes to code actively
> maintained by others
>  Do NOT commit to code actively maintained by others without permission.
>  Send a patch to ffmpeg-devel. If no one answers within a reasonable
>  time-frame (12h for build failures and security fixes, 3 days small
> changes,
>  1 week for big patches) then commit your patch if you think it is OK.
>  Also note, the maintainer can simply ask for more time to review!
>
> +@subheading Pushing patches without sending them to the mailing list
> +If you're the maintainer of a file, or the file is not actively maintained
> by
> +anyone, or the file is not covered by the MAINTAINERS file, you can just
> push
> +them without asking for permission, and without sending them to
> ffmpeg-devel.
> +This right only applies to developers with git push access, of course.
> +A maintainer is considered not active if he hasn't posted a mail to
> ffmpeg-devel
> +for longer than 6 months, and hasn't pushed a patch in that time period
> himself.
> +
>  @subsection Code
>  @subheading API/ABI changes should be discussed before they are made.
>  Do not change behavior of the programs (renaming options etc) or public

I object on this.

I do prefer all the code to go though the maillist.
Even trivial changes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [WIP][PATCH]v2 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-06-24 Thread Ivan Kalvachev
This is the second version of my work.

Nobody posted any benchmarks, so
the old code remains for this round too.

The proper PIC handling code is included.

Small cosmetics, e.g. using tmpY,
to separate (semantically) from the output outY.

Now the tmpX buffer is fixed at 256*sizeof(float) size
and allocated by "cglobal" entry code.

The biggest changes are in the way distortion is computed.
The old code preferred rsqrt() approximation.
However I discovered that sometimes pulses are assigned
at positions where X[i]==0.0 . Padding is set to 0.0 in order
to avoid assigning pulses in it, and the code sometimes
assigned pulses there.

The new code solves this problem in 2 different ways:

1. checking for X[i]==0.0 and zeroing the numerator,
ensuring that it would never be bigger than p_max.
It's done by 3 more instructions in the "pulses add" inner loop.
(The "pulses sub" already have similar check that is sufficient).
This code is enabled for "USE_APPROXIMATION 2" case.

2. Improving precision.
Since input X[] is normalized,
the distortion is calculated by the formula:
   d=2*(1-Sxy/sqrt(Syy))
where Sxy = Sum X[i]*Y[i]
andSyy = Sum Y[i]*Y[i]

The old code (including C version from opus) calculate it
partially with p=Sxy/sqrt(Syy) or p^2=Sxy*Sxy/Syy .
(It does avoid division by replacing it with 2 multiplications
in a cross, aka a/b < c/d => a*d < c*b)
So p values are closing to 1, if we get p=1 we have perfect match.
The problem is that the more Sxy^2 is closer to Syy,
the less precision we get when (approximating) division.
To avoid that I tried to turn the formula into:
   (sqrt(Syy)-Sxy)/sqrt(Syy)
in order to bring the nominator toward zero.
(As floats are normalized, this improves precision).

After some manual experimentation,
I came with the hacked formula:
(Syy-Sxy*Sxy)*approx(1/Syy)
that gives best results.

The final code uses the sign inverted formula (Sxy*Sxy-Syy)/Syy,
in order to preserve the comparison direction of the code.
Since "USE_APPROXIMATION 1" already uses similar formula
the new hack consists of placing a single subtraction in the inner loop.
Also since the formula is inverted its range starts at -1 and goes up,
so the p_max should start with a big enough negative value.

Approximation method #1 was slower than #2 and used to give same results.
However the improved variant gives result that I thought to be binary
identical to
the C version. (Well I found at least a single case where it is not).

I'm inclined to pick "USE_APPROXIMATION 1" as the default method,
even if #2 might still be faster, just because it provides better trade-off
between precision and speed.

At my benchmarks the pvq_search_sse42 is about 2x the speed of
the current C implementation. The v1 was closer to 2.5x .

I'd be glad to see some benchmarks,
preferably with different defines enabled and disabled,
so I can tune the code for different CPU's.

Best Regards
From 7d875390bb81973b6e4d1fb8ad54594ea3f8d5da Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 1/3] SIMD opus pvq_search implementation v2

---
 libavcodec/opus_pvq.c  |   9 +
 libavcodec/opus_pvq.h  |   5 +-
 libavcodec/x86/Makefile|   1 +
 libavcodec/x86/opus_dsp_init.c |  47 +++
 libavcodec/x86/opus_pvq_search.asm | 628 +
 5 files changed, 688 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/x86/opus_dsp_init.c
 create mode 100644 libavcodec/x86/opus_pvq_search.asm

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2ac66a0ede..172223e241 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -418,7 +418,13 @@ static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_
 int *y = pvq->qcoeff;
 
 celt_exp_rotation(X, N, blocks, K, spread, 1);
+
+{
+START_TIMER
 gain /= sqrtf(pvq->pvq_search(X, y, K, N));
+STOP_TIMER("pvq_search");
+}
+
 celt_encode_pulses(rc, y,  N, K);
 celt_normalize_residual(y, X, N, gain);
 celt_exp_rotation(X, N, blocks, K, spread, 0);
@@ -947,6 +953,9 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
+if (ARCH_X86)
+ff_opus_dsp_init_x86(s);
+
 *pvq = s;
 
 return 0;
diff --git a/libavcodec/opus_pvq.h b/libavcodec/opus_pvq.h
index 6691494838..9246337360 100644
--- a/libavcodec/opus_pvq.h
+++ b/libavcodec/opus_pvq.h
@@ -33,8 +33,8 @@
float *lowband_scratch, int fill)
 
 struct CeltPVQ {
-DECLARE_ALIGNED(32, int,   qcoeff  )[176];
-DECLARE_ALIGNED(32, float, hadamard_tmp)[176];
+DECLARE_ALIGNED(32, int,   qcoeff  )[256];
+DECLARE_ALIGNED(32, float, hadamard_tmp)[256];
 
 float (*pvq_search)(float *X, int *y, 

Re: [FFmpeg-devel] [PATCH 1/2] x86/vf_blend: add sse and ssse3 extremity functions

2017-06-27 Thread Ivan Kalvachev
On 6/27/17, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/vf_blend.asm| 25 +
>  libavfilter/x86/vf_blend_init.c |  4 
>  tests/checkasm/vf_blend.c   |  1 +
>  3 files changed, 30 insertions(+)
>
> diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
> index 33b1ad1496..25f6f5affc 100644
> --- a/libavfilter/x86/vf_blend.asm
> +++ b/libavfilter/x86/vf_blend.asm
> @@ -286,6 +286,31 @@ BLEND_INIT difference, 3
>  jl .loop
>  BLEND_END
>
> +BLEND_INIT extremity, 8
> +pxor   m2, m2
> +mova   m4, [pw_255]
> +.nextrow:
> +movxq, widthq
> +
> +.loop:
> +movum0, [topq + xq]
> +movum1, [bottomq + xq]
> +punpckhbw   m5, m0, m2
> +punpcklbw   m0, m2
> +punpckhbw   m6, m1, m2
> +punpcklbw   m1, m2
> +psubw   m3, m4, m0
> +psubw   m7, m4, m5
> +psubw   m3, m1
> +psubw   m7, m6
> +ABS1m3, m1
> +ABS1m7, m6

Minor nitpick.

There exists ABS2 that takes 4 parameters and that does
two interleaved ABS1 , that are (hopefully) faster on sse2.
It should generate exactly the same code on ssse3.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [WIP][PATCH]v2 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-06-30 Thread Ivan Kalvachev
On 6/26/17, Henrik Gramner  wrote:
> On Sat, Jun 24, 2017 at 10:39 PM, Ivan Kalvachev 
> wrote:
>> +%define HADDPS_IS_FAST 0
>> +%define PHADDD_IS_FAST 0
> [...]
>> +haddps  %1,   %1
>> +haddps  %1,   %1
> [...]
>> +   phaddd   xmm%1,xmm%1
>> +   phaddd   xmm%1,xmm%1
>
> You can safely assume that those instructions are always slow and that
> this is virtually never the correct way to use them, so just use the
> shuffle + add method.

Well, there is always hope that they would do a direct implementation.
Or maybe AMD would?
Well, I guess I'll just remove it in the final version.

> You can unconditionally use non-destructive 3-arg instructions
> (without v-prefix) in non AVX-code to reduce ifdeffery. The x86inc
> abstraction layer will automatically insert register-register moves as
> needed.

I'm not sure what code do you have in mind for this comment.
If it is about the HSUMPS , I have to note that both variants
would generate different code (on sse).
The short avx form, would generate "movaps" and "shufps"
that have RW dependency. The sse form avoids that and
allows "movaps" and "shufps" to be executed in parallel.

I do use v prefix on non-destructive avx ops.
Should I prefer the non-prefixed version in such cases?
Should I v-prefix all, including vmovaps ?
(afair vmovaps and movaps differ in preserving/zeroing
of the high part of ymm register, when using xmm.)
I guess I should...

BTW, talking about overload macros.

"cmpps" is the only version of this opcode overloaded by x86asm.
Compilers also define "cmpleps" for "cmp less ps"
where the "less" part is been hardcoded as immediate operand.

Aka, "cmpleps m0, m1" is compiled as
"cmpps xmm0, xmm1, 1".

What complicates matter more is that for 256bit avx,
yasm refuses to accept the short form.
I have to use:
"cmpps m0, m0, m1, 1"
because
"cmpps m0, m1, 1" is turned into
"vcmpps ymm0, ymm1, 1" (line from *.dbg.asm)
and  YASM fails with:
"error: invalid combination of opcode and operands"
(nasm 2.13.1 seems ok).


> I'm a bit doubtful if it's worth the complexity to emulate 256-bit
> integer math using floating-point instruction hacks, especially since
> that's only relevant on two 5+ year old Intel µarchs (SNB & IVB). It's
> probably fine to simply require AVX2 if you need 256-bit integer SIMD.

Well, if 256bit code is 2x the speed of the 128bit one,
then it might make sense to try the emulation.
Unfortunately, even native avx2 seems slower.

> Be aware that most SSE SIMD instructions are actually implemented as
> x86inc macros and redefining them can have unexpected consequences and
> is therefore discouraged.

The manual says that redefinition is recursive
(aka expanded multiple times in the place of usage)
so the hacked integer code would use
the float overloaded macros (and it does).

Don't worry, I don't intend of leaving this in the final version.
But I'm interested to see how much faster/slower it is on real CPU.

Also, I've noticed that some kinds of int/float registry mixing
could have dramatic effect on speed, so trying the hacked
all float version is also a way to check if I have such bad mix.
(e.g. even pxor m0,m0 ; movaps m0,[const] might be problematic)

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


Re: [FFmpeg-devel] [WIP][PATCH]v3 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-06-30 Thread Ivan Kalvachev
First, I've removed the hacked formula.

While it seems to improve precision in the synthetic test,
it is not enough to avoid assigning pulses in padded area.
Worse, it also interferes with the special case with
subtraction of pulses from y[i]==0 output. Handling these cases
needs combining two masks and using "blendvps" instead the faster "maxps".
Most of these problems are related to the fact that
the hacked formula result is in the range -1.0 to 0.0
where 0.0 is the perfect match.

Second, fixed the all_float rounding mode,
I got it swapped in v2.

Third, reordered some code. Moved the branch
for exact match of the pre-search, to be first taken.
Load the constants needed in the pulse search
only when they will be used.

Use a macro for conditional loading/relabeling of the constants.
Use similar idea for loading and using PIC register.

Use "smartalign" on NASM, to avoid 15 consequitev 1 byte NOPs.
YASM is smart by default.

I attach a second patch, that is
slightly modified version of atomnuker's code.
It sums the distortions of C and SIMD implementations.

In my test approx#2 seems to be pretty close to the C version,
sometimes better, sometimes worse.
If you find a file with dramatic difference, I'm interested. :D

If there are no more issues, v4 would be cleaned up and ready for review.

Best Regards.
From 17cbb22f1f3a9021332f95e38003b8ac4d714aec Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 1/4] SIMD opus pvq_search implementation v3

---
 libavcodec/opus_pvq.c  |   9 +
 libavcodec/opus_pvq.h  |   5 +-
 libavcodec/x86/Makefile|   1 +
 libavcodec/x86/opus_dsp_init.c |  47 +++
 libavcodec/x86/opus_pvq_search.asm | 651 +
 5 files changed, 711 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/x86/opus_dsp_init.c
 create mode 100644 libavcodec/x86/opus_pvq_search.asm

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2ac66a0ede..6c7504296d 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -418,7 +418,13 @@ static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_
 int *y = pvq->qcoeff;
 
 celt_exp_rotation(X, N, blocks, K, spread, 1);
+
+{
+START_TIMER
 gain /= sqrtf(pvq->pvq_search(X, y, K, N));
+STOP_TIMER("pvq_search");
+}
+
 celt_encode_pulses(rc, y,  N, K);
 celt_normalize_residual(y, X, N, gain);
 celt_exp_rotation(X, N, blocks, K, spread, 0);
@@ -947,6 +953,9 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
+if (ARCH_X86 && CONFIG_OPUS_ENCODER)
+ff_opus_dsp_init_x86(s);
+
 *pvq = s;
 
 return 0;
diff --git a/libavcodec/opus_pvq.h b/libavcodec/opus_pvq.h
index 6691494838..9246337360 100644
--- a/libavcodec/opus_pvq.h
+++ b/libavcodec/opus_pvq.h
@@ -33,8 +33,8 @@
float *lowband_scratch, int fill)
 
 struct CeltPVQ {
-DECLARE_ALIGNED(32, int,   qcoeff  )[176];
-DECLARE_ALIGNED(32, float, hadamard_tmp)[176];
+DECLARE_ALIGNED(32, int,   qcoeff  )[256];
+DECLARE_ALIGNED(32, float, hadamard_tmp)[256];
 
 float (*pvq_search)(float *X, int *y, int K, int N);
 
@@ -45,6 +45,7 @@ struct CeltPVQ {
 };
 
 int  ff_celt_pvq_init  (struct CeltPVQ **pvq);
+void ff_opus_dsp_init_x86(struct CeltPVQ *s);
 void ff_celt_pvq_uninit(struct CeltPVQ **pvq);
 
 #endif /* AVCODEC_OPUS_PVQ_H */
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 0dbc46504e..6687fbcd72 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -52,6 +52,7 @@ OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
 OBJS-$(CONFIG_CAVS_DECODER)+= x86/cavsdsp.o
 OBJS-$(CONFIG_DCA_DECODER) += x86/dcadsp_init.o x86/synth_filter_init.o
 OBJS-$(CONFIG_DNXHD_ENCODER)   += x86/dnxhdenc_init.o
+OBJS-$(CONFIG_OPUS_ENCODER)+= x86/opus_dsp_init.o x86/opus_pvq_search.o
 OBJS-$(CONFIG_HEVC_DECODER)+= x86/hevcdsp_init.o
 OBJS-$(CONFIG_JPEG2000_DECODER)+= x86/jpeg2000dsp_init.o
 OBJS-$(CONFIG_MLP_DECODER) += x86/mlpdsp_init.o
diff --git a/libavcodec/x86/opus_dsp_init.c b/libavcodec/x86/opus_dsp_init.c
new file mode 100644
index 00..ddccf6fe9e
--- /dev/null
+++ b/libavcodec/x86/opus_dsp_init.c
@@ -0,0 +1,47 @@
+/*
+ * Opus encoder assembly optimizations
+ * Copyright (C) 2017 Ivan Kalvachev 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOU

[FFmpeg-devel] [WIP][PATCH]v4 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-08 Thread Ivan Kalvachev
This should be the final work-in-progress patch.

What's changed:

1. Removed macros conditional defines. The defaults seems to be
optimal on all machines that I got benchmarks from. HADDPS and PHADDD
are always slower, "BLEND"s are never slower than the emulation.

2. Remove SHORT_SYY_UPDATE. It is always slower.

3. Remove ALL_FLOAT_PRESEARCH, it is always slower. Remove the ugly
hack to use 256bit ymm with avx1 and integer operations.

4. Remove remaining disabled code.

5. Use HADDD macro from "x86util", I don't need the result in all lanes/elements

6. Use v-prefix for all avx code.

7. Small optimization: Move some of the HSUMPS in the K!=0 branch.

8. Small optimization: Instead of pre-calculation 2*Y[i] and then
correcting it on exit, It is possible to use Syy/2 instead in
distortion parameter calculations. It saves few multiplications in
pre-search and sign restore loop. It however gives different
approximation of sqrt(). It's not (consistently) better or worse than
the previous approximation.

9. Using movdqa to load "const_int32_offsets". Wrong type might
explain why directly using mem constants is sometimes faster.

10. Move some code around and do minor tweaks.
---

I do not intend of removing "PRESEARCH_ROUNDING" and
"USE_APPROXIMATION", (while for the latter I think I will remove
method#1, I've left it this time just for consistency").
These defines control the precision and the type of results that the
function generates.
E.g. This function can produce same results as opus functions with
"PRESEARCH_ROUNDING 0".
If you want same results as the ffmpeg improved function, then you
need "approx#0". It uses real division and is much slower on older
cpu's, but reasonably fast on anything recent.

I've left 2 other defines. "CONST_IN_X64_REG_IS_FASTER" and
"STALL_WRITE_FORWARDING".
On Sandy Bridge and laters, "const_in_x64" has always been faster. On
my cpu it is about the same.
On Ryzen the "const_in_x64" was consistently faster in all sse/avx
variants, with about 5%. But not if "stall_write" is enabled too.
Ryzen (allegedly) has no write stalling, but that method alone is just
a few cycles faster (about 0.5% ).

I'd like to see if the changes I've done this time, would affect the
above results.


The code is much cleaner and you are free to nitpick on it.

There is something that I'm not exactly sure if I need it.
The function gets 2 integer parameters, and I am not sure
if I have to sign extend them in 64 bit more, in order to clear
the high 32 bits. These parameters should never be negative, so the
sign is not needed.
All 32bit operands should also clear the high bits.
Still I'm not sure if there is guarantee that
the high bits won't contain garbage.


Best Regards
From 4591ad752d1d111615f320b17ad19d5fad0d91d4 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 1/5] SIMD opus pvq_search implementation v4

---
 libavcodec/opus_pvq.c  |   9 +
 libavcodec/opus_pvq.h  |   5 +-
 libavcodec/x86/Makefile|   1 +
 libavcodec/x86/opus_dsp_init.c |  47 
 libavcodec/x86/opus_pvq_search.asm | 524 +
 5 files changed, 584 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/x86/opus_dsp_init.c
 create mode 100644 libavcodec/x86/opus_pvq_search.asm

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2ac66a0ede..6c7504296d 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -418,7 +418,13 @@ static uint32_t celt_alg_quant(OpusRangeCoder *rc, float *X, uint32_t N, uint32_
 int *y = pvq->qcoeff;
 
 celt_exp_rotation(X, N, blocks, K, spread, 1);
+
+{
+START_TIMER
 gain /= sqrtf(pvq->pvq_search(X, y, K, N));
+STOP_TIMER("pvq_search");
+}
+
 celt_encode_pulses(rc, y,  N, K);
 celt_normalize_residual(y, X, N, gain);
 celt_exp_rotation(X, N, blocks, K, spread, 0);
@@ -947,6 +953,9 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
+if (ARCH_X86 && CONFIG_OPUS_ENCODER)
+ff_opus_dsp_init_x86(s);
+
 *pvq = s;
 
 return 0;
diff --git a/libavcodec/opus_pvq.h b/libavcodec/opus_pvq.h
index 6691494838..9246337360 100644
--- a/libavcodec/opus_pvq.h
+++ b/libavcodec/opus_pvq.h
@@ -33,8 +33,8 @@
float *lowband_scratch, int fill)
 
 struct CeltPVQ {
-DECLARE_ALIGNED(32, int,   qcoeff  )[176];
-DECLARE_ALIGNED(32, float, hadamard_tmp)[176];
+DECLARE_ALIGNED(32, int,   qcoeff  )[256];
+DECLARE_ALIGNED(32, float, hadamard_tmp)[256];
 
 float (*pvq_search)(float *X, int *y, int K, int N);
 
@@ -45,6 +45,7 @@ struct CeltPVQ {
 };
 
 int  ff_celt_pvq_ini

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/aacpsdsp_template: Fixes integer overflow in ps_add_squares_c()

2017-07-09 Thread Ivan Kalvachev
On 7/9/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer 
> wrote:
>
>> On Mon, Jul 03, 2017 at 01:37:09AM +0200, Michael Niedermayer wrote:
>> > On Sun, Jul 02, 2017 at 02:24:53PM +0100, Rostislav Pehlivanov wrote:
>> > > On 2 July 2017 at 03:28, Michael Niedermayer 
>> wrote:
>> > >
>> > > > Fixes: runtime error: signed integer overflow: 1965219850 +
>> > > > 995792909
>> > > > cannot be represented in type 'int'
>> > > > Fixes: part of 2096/clusterfuzz-testcase-minimized-4901566068817920
>> > > >
>> > > > Found-by: continuous fuzzing process https://github.com/google/oss-
>> > > > fuzz/tree/master/projects/ffmpeg
>> > > > Signed-off-by
>> > > > > ffmpeg%0ASigned-off-by>:
>> > > > Michael Niedermayer 
>> > > > ---
>> > > >  libavcodec/aacpsdsp_template.c | 3 ++-
>> > > >  1 file changed, 2 insertions(+), 1 deletion(-)
>> > > >
>> > > > diff --git a/libavcodec/aacpsdsp_template.c b/libavcodec/aacpsdsp_
>> > > > template.c
>> > > > index 9e1a95c1a1..2c0afd4512 100644
>> > > > --- a/libavcodec/aacpsdsp_template.c
>> > > > +++ b/libavcodec/aacpsdsp_template.c
>> > > > @@ -26,9 +26,10 @@
>> > > >  #include "libavutil/attributes.h"
>> > > >  #include "aacpsdsp.h"
>> > > >
>> > > > -static void ps_add_squares_c(INTFLOAT *dst, const INTFLOAT
>> (*src)[2], int
>> > > > n)
>> > > > +static void ps_add_squares_c(INTFLOAT *dst_param, const INTFLOAT
>> > > > (*src)[2], int n)
>> > > >  {
>> > > >  int i;
>> > > > +SUINTFLOAT *dst = dst_param;
>> > > >  for (i = 0; i < n; i++)
>> > > >  dst[i] += AAC_MADD28(src[i][0], src[i][0], src[i][1],
>> src[i][1]);
>> > > >  }
>> > > >
>> > > >
>> > > What's the issue with just _not_ fixing it here? It only occurs on
>> fuzzed
>> > > inputs, doesn't crash on any known platform ever, makes the code
>> uglier and
>> > > why? Because some fuzzer is super pedantic.
>> > > Why not fix the fuzzer? Why not just mark this as a false positive,
>> since
>> > > fixing it is pointless from the standpoint of security (you can't
>> exploit
>> > > overflows in transforms or functions like this), and all developers
>> hate it.
>> >
>> > Iam not sure you understand the problem.
>> > signed integer overflows are undefined behavior, undefined behavior
>> > is not allowed in C.
>> >
>> >
>> > Theres also no option to mark anything as false positive.
>> > If the tool makes a mistake, the issue needs to be reported to its
>> > authors and needs to be fixed.
>> > I belive the tool is correct, if someone thinks its not correct, the
>> > place to report this to is likely where the clang sanitizers are
>> > developed.
>> >
>> > I do understand that this is annoying but this is how C works.
>> >
>> > About "doesn't crash on any known platform ever",
>> > "you can't exploit  overflows in transforms or functions like this"
>> >
>> > undefined behavior has bitten people with unexpected results in the
>> > past. for example "if (a+b < a)" to test for overflow, but because the
>> condition
>> > can only be true in case of overflow and overflow isnt allowed in C
>> > the compiler didnt assemble this the way the human thought.
>> >
>> > In the case of ps_add_squares_c(), dst[i] has to increase if iam
>> > not mistaken. In case of overflow it can decrease but overflow is
>> > not allowed so a compiler can prune anything that implies dst[] to be
>> > negative.
>> > dst[] is used downstream in checks of greater / less and in FFMAX
>> > In this code the compiler can assume that the sign bit is clear,
>> > what happens when  the compilers optimizer has false assumtations
>> > i dont know but i know its not good.
>> >
>> > That said even if no such chain of conditions exist its still invalid
>> > code if theres undefined behavior in it
>>
>> Does anyone object to this patch ?
>> Or does anyone have a better idea on how to fix this ?
>> if not id like to apply it
>
>
> I think Rostislav's point is: why fix it, if it can only happen with
> corrupt input? The before and after situation is identical: garbage in,
> garbage out. If the compiler does funny things that makes the garbage
> slightly differently bad, is that really so devilishly bad? It's still
> garbage. Is anything improved by this?

As I have tried to explain before,
you can harden a program by compiling it
with `gcc -ftrapv` .

In such a program the overflow would trap
and in normal case would lead to termination.

Do you want your browser to die by a small bit error in a random clip?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 3/3] avcodec/aacpsdsp_template: Fixes integer overflow in ps_add_squares_c()

2017-07-09 Thread Ivan Kalvachev
On 7/9/17, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Jul 9, 2017 at 4:39 AM, Reimar Döffinger 
> wrote:
>
>> On 09.07.2017, at 02:52, "Ronald S. Bultje"  wrote:
>> > On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
>> 
>> > wrote:
>> >
>> >>
>> >> Does anyone object to this patch ?
>> >> Or does anyone have a better idea on how to fix this ?
>> >> if not id like to apply it
>> >
>> >
>> > I think Rostislav's point is: why fix it, if it can only happen with
>> > corrupt input? The before and after situation is identical: garbage in,
>> > garbage out. If the compiler does funny things that makes the garbage
>> > slightly differently bad, is that really so devilishly bad? It's still
>> > garbage. Is anything improved by this?
>>
>> The way C works, you MUST assume any undefined behaviour can at any point
>> [..] become exploitable.[..] If you don't like that, C is the wrong
>> language to use.
>
>
> I think I've read "the boy who cried wolf" a few too many times to my kids,
> but the form of this discussion is currently too polarizing/political for
> my taste.

So, you stir the pot and then run away.
You ignore technical explanations and you call discussion too political.
And you "imply" that developers are lairs.

Maybe you are not aware what you are going,
but I do assure you, it aint pretty.

I think you owe some people an apology.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_template: Fix undefined integer overflow in apply_tns()

2017-07-12 Thread Ivan Kalvachev
On 7/11/17, Michael Niedermayer  wrote:
> On Sun, Jul 02, 2017 at 01:33:16PM +0200, Michael Niedermayer wrote:
>> On Sun, Jul 02, 2017 at 01:14:31PM +0200, wm4 wrote:
>> > On Sun,  2 Jul 2017 04:28:54 +0200
>> > Michael Niedermayer  wrote:
>> >
>> > > Fixes: runtime error: signed integer overflow: -2147483648 -
>> > > 1202286525 cannot be represented in type 'int'
>> > > Fixes: 2071/clusterfuzz-testcase-minimized-6036414271586304
>> > >
>> > > Found-by: continuous fuzzing process
>> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> > > Signed-off-by: Michael Niedermayer 
>> > > ---
>> > >  libavcodec/aac_defines.h | 2 ++
>> > >  libavcodec/aacdec_template.c | 5 +++--
>> > >  2 files changed, 5 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/libavcodec/aac_defines.h b/libavcodec/aac_defines.h
>> > > index 3c79a8a4a1..ee4c73a87d 100644
>> > > --- a/libavcodec/aac_defines.h
>> > > +++ b/libavcodec/aac_defines.h
>> > > @@ -35,6 +35,7 @@
>> > >  #define AAC_RENAME(x)   x ## _fixed
>> > >  #define AAC_RENAME_32(x)x ## _fixed_32
>> > >  typedef int INTFLOAT;
>> > > +typedef unsignedSUINTFLOAT;
>> > >  typedef int64_t INT64FLOAT;
>> > >  typedef int16_t SHORTFLOAT;
>> > >  typedef SoftFloat   AAC_FLOAT;
>> > > @@ -83,6 +84,7 @@ typedef int AAC_SIGNE;
>> > >  #define AAC_RENAME(x)   x
>> > >  #define AAC_RENAME_32(x)x
>> > >  typedef float   INTFLOAT;
>> > > +typedef float   SUINTFLOAT;
>> >
>> > Not more of this damn shit.
>>
>> i dont think i understand your comment
>>
>> The code is templated and uses largely the INTFLOAT data type
>> which is either signed int or float depending on if the code is build
>> for the fixed point or floating point decoder
>>
>> to fix the undefined behavior in the fixed point decoder a type which
>> is unsigned int is the obvious choice.
>> Such type must be float in the floating point decoder.
>>
>> This patch adds such type.
>>
>> do you object to fixing the issue ?
>> do you want to suggest a different solution ?
>
> over a week passed, noone replied.
> Is everyone ok with patch 1/3 ?
> does someone object to it ?
> does anyone have a better solution ?
>
> If noone replies, i will apply this patch, i do not want to leave
> undefined behavior in the codebase.

I actually would request a short note explaining the SUINTFLOAT type usage.
Something like:
+typedef unsignedSUINTFLOAT; // Equivalent to INTFLOAT,
Used as temporal cast to avoid undefined sign overflow operations.

Maybe add such note to all "signed value in unsigned type" typedefs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]v5 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-22 Thread Ivan Kalvachev
This patch is ready for review and inclusion.

Explanation of what it does and how it works
could be found in the previous WIP threads:
[v1] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212146.html
[v2] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212816.html
[v3] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213030.html
[v4] http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213436.html

The changes compared to WIP v4 are small:
 - Using r4d ops to clear the high bits on int32 arguments.
 - Correctly map the cglobal registry usage.
 - Use SSE4 instead of SSE42, since blend is only SSE4.1.
 - Fix building with --disable-x86asm .

 - Remove testing defines.
Loading constants in registers is (now) always same or better speed.
Avoiding stall forwarding is faster on all CPU except Ryzen.
On Ryzen the alternative is about 7 cycles faster, that's why
I've left the code disabled, but without define.
I've also left the two other defines, as they are useful
for debugging and creating binary identical results
to other algorithms.

 - Disable the 256bit AVX2 variant usage.
I'm leaving the code in the assembly as disabled,
in case it is useful in future.

---

I'm including some of the benchmarks.
Some data is removed, since it was used to test different methods.
Benchmarks are done at default settings (96kbps),
but with different samples. All samples are above 1h long.

In summary, the function is about 2-3x faster
than the improved FFmpeg C version.

===
 K10  AMD Phenom(tm) II X4 945 Processor
//v4
  706   706   706   706   706// NULL
 4146  4161  4169  4184  4188  4328 4379 // SSE2
 4988  5015  5016  5030  5185// USE_APPROXIMATION  0
13860 13828 13846 13846 13831// C

===
 Pentium Dual Core E5800
//V4
3006 3012 3019 3023 3025 // SSE2
9066 9071 9074 9077 9081 // C

//===
 Ryzen 1800X
//v3
 357 // NULL
1999 2001 2004   // AVX1 GCC
2010 2029// SSE4 MSVC
2012 2026 2027   // AVX1 MSVC
2166 2170 2171   // AVX2 & STALL_WRITE_FORWARDING 1
2176 2179 2180 2180 2189 // AVX2
2226 2230 2234   // AVX2 & USE_APPROXIMATION 0
6216 6162 6162   // C only GCC
   61909 61545   // C only MSVC
//v4
1931 1933 1935   // v4 AVX1
2096 2097 2098   // v4 AVX2 & STALL_WRITE_FORWARDING 1
2103 2110 2112   // v4 AVX2

//===
 Intel(R) Core(TM) i7-3930K CPU
//v3
 272// NULL
1755 1756 1764  // AVX1
1847 1855 1866  // SSE4
2003 2009   // USE_APPROXIMATION  00
2103 2110 2112  // AVX2
4855 4856   // C only

//===
 SkyLake i7 6700HQ
//v2
 264// NULL
1764 1765 1772 1773 1780// SSE4
1782 1782 1787 1795 1796// AVX1
1805 1807 1807 1811 1815// AVX1 & USE_APPROXIMATION 0
1826 1827 1828 1833 1833// SSE2
1850 1853 1857 1857 1868// AVX2
6878 6934 6879 6921 6899// C

-b:a 48kbps, 96kbps, 510kbps
sse4:  2049,   1826, 955
sse2:  2065,   1874, 943
avx:   2106,   1868, 950
c: 9202,   7080,1392
From 522ed9d47db739c9c0559f4c040ef5262c685335 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 8 Jun 2017 22:24:33 +0300
Subject: [PATCH 1/5] SIMD opus pvq_search implementation

Explanation on the workings and methods used by the
Pyramid Vector Quantization Search function
could be found in the following Work-In-Progress mail threads:
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212146.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-June/212816.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213030.html
http://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213436.html

Signed-off-by: Ivan Kalvachev 
---
 libavcodec/opus_pvq.c  |   3 +
 libavcodec/opus_pvq.h  |   5 +-
 libavcodec/x86/Makefile|   2 +
 libavcodec/x86/opus_dsp_init.c |  43 +++
 libavcodec/x86/opus_pvq_search.asm | 554 +
 5 files changed, 605 insertions(+), 2 deletions(-)
 create mode 100644 libavcodec/x86/opus_dsp_init.c
 create mode 100644 libavcodec/x86/opus_pvq_search.asm

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 2ac66a0ede..3aa502929c 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -947,6 +947,9 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
+if (ARCH_X86 && CONFIG_OPUS_ENCODER)
+ff_opus_dsp_init_x86(s);
+
 *pvq = s;
 
 return 0;
diff --git a/libavcodec/opus_pvq

Re: [FFmpeg-devel] [PATCH]v5 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-24 Thread Ivan Kalvachev
On 7/23/17, Rostislav Pehlivanov  wrote:
> On 22 July 2017 at 12:18, Ivan Kalvachev  wrote:
>
>> This patch is ready for review and inclusion.
>>
>>
>>
>>+%macro emu_blendvps 3 ; dst/src_a, src_b, mask
>>+%macro lea_pic_base 2; reg, const_label
> Capitalize macro names.

Done for the later.
About the former...

I do not like to use capitalization for the emulated instructions:

1. In C macros are always in capital letters to separate them from the
functions.
In ASM functions cannot be mistaken for macros.

2. All instructions are lowercase, even the ones that are overloaded
by x86asm.h macros.

3. There are already about 30 macros with lower cases in
libavcodec/x86. The rule is not absolute.

4. There are some emulated instructions in x86util, that are all upper
case names and
I do find them very ugly when I see them in the code.
This is why I went with "emu_" route.
I actually want to encourage using the emu_ for them too (as
alternative names).

5. There is nothing guaranteeing that the assembler
should be case sensitive.
Actually nasm manual mentions that MASM (on which
it it is based on) is not case-sensitive (by default).
While nasm and yasm are case sensitive,
there are still %idefine and %imacro that
could create some confusion.

Anyway.

Would you accept a change where the emulation macros
are moved to a separate file and the macros are
renamed to EMU_ , aka EMU_blendvps ?
I'm thinking of "libavcodec/x86/x86emu.asm".

Or maybe they should be put in libavutil/x86/x86util.asm ,
however that could open a new can of worms.
AKA using the ugly uppercase only names.

>>+  %error sse41 blendvps uses xmm0 as default 3d operand, you used %3
> Remove this error

I'd like to keep that one.
It helps finding out why the code does not compile.

Sometimes it may not be obvious, since SWAP might
change the registers under the hood.

>
>>+%error "blendvps" emulation needs SSE
> Definitely remove this error too.

Done

>>+%error AVX1 does not support integer 256bit ymm operations
> And this one is particularly pointless...

On the contrary. AVX1 does support 256 bit ymm float point operations
but not integer ones. It is quite trivial mistake to use one with the other.

What is worse, without this the wrong code would compile
without any hint of error, because avx2 codes are
not overloaded by the current x86asm.h
so you won't get warning that you are using avx2 ops in avx1 section.

>>+  %error sse41 blendvps uses xmm0 as default 3 operand, you used %3
> Same...

Again, I'd like to keep that one.

>>+%error "broadcastss" emulation needs SSE
> Same...

Done

>>+%error "pbroadcastd" emulation needs SSE2
> Yep, the same...

Done

>
>>+%error pick HSUMPS implementation
> Again...

I thought I had taken care of that.
Done

> All of these are pointless and unnecessary. Always assume at least SSE2.

NEVER assume anything (that you can check).
Making wrong assumptions is the easiest way
to make a mistakes that are
very hard to notice, find and correct.

>>+
>>+; 256bit version seems slower than the 128bit AVX on all current CPU's
>>+; So disable it for now and keep the code in case something changes in
> future.
>>+%if HAVE_AVX2_EXTERNAL > 0 && 0
>>+INIT_YMM avx2
>>+PVQ_FAST_SEARCH
>>+%endif
>
> Remove this altogether.

I think this would be a mistake.

BTW, would you do a proper benchmarks with the current
code and post the results. There is a chance that the
code has improved.
(Please, use a real audio sample, not generated noise).

I also asked you to try something (changing "cmpless" to "cmpps" ),
that you totally forgot to do.
(IACA says there is no penalty in my code for using this SSE op in AVX2 block,
but as I said, never assume.)

>>+%if 1
>>+emu_pbroadcastd m1,   xmm1
> ...
>>+%else
>>+; Ryzen is the only CPU at the moment that doesn't have
>>+; write forwarding stall and where this code is faster
>>+; with about 7 cycles on avarage.
>>+%{1}ps  m5,   mm_const_float_1
>>+movss   [tmpY + r4q], xmm5  ; Y[max_idx] +-= 1.0;
>
> Remove the %else and always use the first bit of code.

I don't like removing code that is faster on a new CPU.
But since you insist.
Done.

>>+%if cpuflag(avx2) && 01
>>+%elif cpuflag(avx) && 01
>>+%if cpuflag(avx2) && 01
>
> Remove the && 01 in these 3 places.

Done


>>+;  vperm2f128   %1,   %1,   %1,   0 ; ymm, ymm, ymm ; 2-3c 1/1
>
> Remove this commented out code.

Done

>
>>+cglobal pvq_search, 4, 5+num_pic_regs, 11, 256*4, inX, outY, K, N
>>+%if ARCH_X86_64 == 0;sbrdsp
>

[FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-26 Thread Ivan Kalvachev
On 7/24/17, Ivan Kalvachev  wrote:
> On 7/23/17, Rostislav Pehlivanov  wrote:
>> On 22 July 2017 at 12:18, Ivan Kalvachev  wrote:
>>
>>> This patch is ready for review and inclusion.
>>>
>>>
>>>
>>>+%macro emu_blendvps 3 ; dst/src_a, src_b, mask
>>>+%macro lea_pic_base 2; reg, const_label
>> Capitalize macro names.
>
> Done for the later.
> About the former...
>
> I do not like to use capitalization for the emulated instructions:
>
> 1. In C macros are always in capital letters to separate them from the
> functions.
> In ASM functions cannot be mistaken for macros.
>
> 2. All instructions are lowercase, even the ones that are overloaded
> by x86asm.h macros.
>
> 3. There are already about 30 macros with lower cases in
> libavcodec/x86. The rule is not absolute.
>
> 4. There are some emulated instructions in x86util, that are all upper
> case names and
> I do find them very ugly when I see them in the code.
> This is why I went with "emu_" route.
> I actually want to encourage using the emu_ for them too (as
> alternative names).
>
> 5. There is nothing guaranteeing that the assembler
> should be case sensitive.
> Actually nasm manual mentions that MASM (on which
> it it is based on) is not case-sensitive (by default).
> While nasm and yasm are case sensitive,
> there are still %idefine and %imacro that
> could create some confusion.
>
> Anyway.
>
> Would you accept a change where the emulation macros
> are moved to a separate file and the macros are
> renamed to EMU_ , aka EMU_blendvps ?
> I'm thinking of "libavcodec/x86/x86emu.asm".
>
> Or maybe they should be put in libavutil/x86/x86util.asm ,
> however that could open a new can of worms.
> AKA using the ugly uppercase only names.
>
>>>+  %error sse41 blendvps uses xmm0 as default 3d operand, you used %3
>> Remove this error
>
> I'd like to keep that one.
> It helps finding out why the code does not compile.
>
> Sometimes it may not be obvious, since SWAP might
> change the registers under the hood.
>
>>
>>>+%error "blendvps" emulation needs SSE
>> Definitely remove this error too.
>
> Done
>
>>>+%error AVX1 does not support integer 256bit ymm operations
>> And this one is particularly pointless...
>
> On the contrary. AVX1 does support 256 bit ymm float point operations
> but not integer ones. It is quite trivial mistake to use one with the
> other.
>
> What is worse, without this the wrong code would compile
> without any hint of error, because avx2 codes are
> not overloaded by the current x86asm.h
> so you won't get warning that you are using avx2 ops in avx1 section.
>
>>>+  %error sse41 blendvps uses xmm0 as default 3 operand, you used %3
>> Same...
>
> Again, I'd like to keep that one.
>
>>>+%error "broadcastss" emulation needs SSE
>> Same...
>
> Done
>
>>>+%error "pbroadcastd" emulation needs SSE2
>> Yep, the same...
>
> Done
>
>>
>>>+%error pick HSUMPS implementation
>> Again...
>
> I thought I had taken care of that.
> Done
>
>> All of these are pointless and unnecessary. Always assume at least SSE2.
>
> NEVER assume anything (that you can check).
> Making wrong assumptions is the easiest way
> to make a mistakes that are
> very hard to notice, find and correct.
>
>>>+
>>>+; 256bit version seems slower than the 128bit AVX on all current CPU's
>>>+; So disable it for now and keep the code in case something changes in
>> future.
>>>+%if HAVE_AVX2_EXTERNAL > 0 && 0
>>>+INIT_YMM avx2
>>>+PVQ_FAST_SEARCH
>>>+%endif
>>
>> Remove this altogether.
>
> I think this would be a mistake.
>
> BTW, would you do a proper benchmarks with the current
> code and post the results. There is a chance that the
> code has improved.
> (Please, use a real audio sample, not generated noise).
>
> I also asked you to try something (changing "cmpless" to "cmpps" ),
> that you totally forgot to do.
> (IACA says there is no penalty in my code for using this SSE op in AVX2
> block,
> but as I said, never assume.)
>
>>>+%if 1
>>>+emu_pbroadcastd m1,   xmm1
>> ...
>>>+%else
>>>+; Ryzen is the only CPU at the moment that doesn't have
>>>+; write forwarding stall and where this code is faster
>>>+; with about 7 cycles on avarage.
>>>+%{1}ps  m5,   mm_const_float_1
>>>

Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-27 Thread Ivan Kalvachev
On 7/27/17, Rostislav Pehlivanov  wrote:
> On 26 July 2017 at 15:56, Ivan Kalvachev  wrote:
>
>> +if (ARCH_X86 && CONFIG_OPUS_ENCODER)
>> +ff_opus_dsp_init_x86(s);
>>
>
> Just change it to
> +if (ARCH_X86)
>
> The init function is named opus_dsp, so it'll get used to other opus
> things, not just the encoder.

But at the moment it does not.
I do prefer to leave that task for the one that
adds opus decoder functions.

Also this change alone would break compilation, since
it also requires changing the libavcodec/x86/Makefile
and adding the guard inside the opus_dsp_init.c

Another option is to have "opus_enc_dsp_init.c" and call
the function "ff_opus_enc_dsp_init_x86()".

Do tell me which option do you prefer
and do you insist on v7 just for that.

> The assembly code looks fine to me, but other people will have to take a
> look at it in case I'm missing something.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-07-27 Thread Ivan Kalvachev
On 7/27/17, Rostislav Pehlivanov  wrote:
> On 27 July 2017 at 09:38, Ivan Kalvachev  wrote:
>
>> On 7/27/17, Rostislav Pehlivanov  wrote:
>> > On 26 July 2017 at 15:56, Ivan Kalvachev  wrote:
>> >
>> >> +if (ARCH_X86 && CONFIG_OPUS_ENCODER)
>> >> +ff_opus_dsp_init_x86(s);
>> >>
>> >
>> > Just change it to
>> > +if (ARCH_X86)
>> >
>> > The init function is named opus_dsp, so it'll get used to other opus
>> > things, not just the encoder.
>>
>> But at the moment it does not.
>> I do prefer to leave that task for the one that
>> adds opus decoder functions.
>>
>> Also this change alone would break compilation, since
>> it also requires changing the libavcodec/x86/Makefile
>> and adding the guard inside the opus_dsp_init.c
>>
>> Another option is to have "opus_enc_dsp_init.c" and call
>> the function "ff_opus_enc_dsp_init_x86()".
>>
>> Do tell me which option do you prefer
>> and do you insist on v7 just for that.
>>
>> > The assembly code looks fine to me, but other people will have to take a
>> > look at it in case I'm missing something.
>
> The former, but that can be changed later after pushing

Here is the patch.
I'll merge it in v7, if there is one.

Please note that makefile needs to use two separate
config_opus_decoder/encoder, since there is no config_opus_codec . All
other dsp seem to use separate files for encoder and decoder dsp.

Best Regards.
From 1a6ee9b2880c67db25737a6317f09cbbac441c83 Mon Sep 17 00:00:00 2001
From: Ivan Kalvachev 
Date: Thu, 27 Jul 2017 14:21:33 +0300
Subject: [PATCH 2/6] Build opus dsp for encoder and decoder.

---
 libavcodec/opus_pvq.c  | 2 +-
 libavcodec/x86/Makefile| 1 +
 libavcodec/x86/opus_dsp_init.c | 2 ++
 3 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index 3aa502929c..2fb276099b 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -947,7 +947,7 @@ int av_cold ff_celt_pvq_init(CeltPVQ **pvq)
 s->encode_band= pvq_encode_band;
 s->band_cost  = pvq_band_cost;
 
-if (ARCH_X86 && CONFIG_OPUS_ENCODER)
+if (ARCH_X86)
 ff_opus_dsp_init_x86(s);
 
 *pvq = s;
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 9875f48797..e36644c72a 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -52,6 +52,7 @@ OBJS-$(CONFIG_APNG_DECODER)+= x86/pngdsp_init.o
 OBJS-$(CONFIG_CAVS_DECODER)+= x86/cavsdsp.o
 OBJS-$(CONFIG_DCA_DECODER) += x86/dcadsp_init.o x86/synth_filter_init.o
 OBJS-$(CONFIG_DNXHD_ENCODER)   += x86/dnxhdenc_init.o
+OBJS-$(CONFIG_OPUS_DECODER)+= x86/opus_dsp_init.o
 OBJS-$(CONFIG_OPUS_ENCODER)+= x86/opus_dsp_init.o
 OBJS-$(CONFIG_HEVC_DECODER)+= x86/hevcdsp_init.o
 OBJS-$(CONFIG_JPEG2000_DECODER)+= x86/jpeg2000dsp_init.o
diff --git a/libavcodec/x86/opus_dsp_init.c b/libavcodec/x86/opus_dsp_init.c
index f4c25822db..c51f786ee8 100644
--- a/libavcodec/x86/opus_dsp_init.c
+++ b/libavcodec/x86/opus_dsp_init.c
@@ -32,6 +32,7 @@ av_cold void ff_opus_dsp_init_x86(CeltPVQ *s)
 {
 int cpu_flags = av_get_cpu_flags();
 
+#if CONFIG_OPUS_ENCODER
 if (EXTERNAL_SSE2(cpu_flags))
 s->pvq_search = ff_pvq_search_sse2;
 
@@ -40,4 +41,5 @@ av_cold void ff_opus_dsp_init_x86(CeltPVQ *s)
 
 if (EXTERNAL_AVX(cpu_flags))
 s->pvq_search = ff_pvq_search_avx;
+#endif
 }
-- 
2.13.2

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


Re: [FFmpeg-devel] [PATCH] build: Allow libffmpeg to be built for Chromium-based browsers

2017-07-28 Thread Ivan Kalvachev
On 7/29/17, Dominik 'Rathann' Mierzejewski  wrote:
> On Saturday, 29 July 2017 at 00:20, Hendrik Leppkes wrote:
>> On Fri, Jul 28, 2017 at 12:07 PM, James Le Cuirot 
>> wrote:
> [...]
>> > This Makefile snippet allows libffmpeg to be created without the help
>> > of Chromium's build system. It uses the CONFIG_SHARED variable to
>> > decide whether to link the FFmpeg libraries statically or
>> > dynamically. In the latter case, libffmpeg is just a wrapper with no
>> > symbols of its own.
> [...]
>> I don't think ffmpeg is the right place to maintain special makefiles
>> for Chromium.
>
> I concur. Instead, Chromium should be fixed to link against individual
> FFmpeg libraries properly.

To be honest, I do not find the combined library such a bad idea.

Actually I think that going this way has been discussed before,
long before Chromium existed.

For example, if you have to dlopen ffmpeg libs, it takes a lot of care
to load all the interlinked libraries in the correct order.
And imagine the fun if you have multiple versions installed.

Having one front-end to load all correct libraries is
logical improvement and simplification.
This is why Chromium has done it on their own.
This is why FFmpeg should do it too.


Also, the changes are isolated to a separate file in the build system,
it should not interfere with normal build process or merges.

I do however object on hardcoding "chromium" codepaths in it.

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


Re: [FFmpeg-devel] [PATCH]v6 Opus Pyramid Vector Quantization Search in x86 SIMD asm

2017-08-01 Thread Ivan Kalvachev
On 7/31/17, Henrik Gramner  wrote:
> On Wed, Jul 26, 2017 at 4:56 PM, Ivan Kalvachev 
> wrote:
>> +++ b/libavcodec/x86/opus_pvq_search.asm
>
> Generic minor stuff:
>
> Use rN instead of rNq for numbered registers (q suffix is used for
> named args only due to preprocessor limitations).

Done.

Is this documented?

> Use the same "standard" vertical alignment rules as most existing
> code, e.g. instructions indented by 4 spaces and operands aligned on
> the first comma.

What do you mean operands aligned on the first comma?
The longest operand I had is "xmm0" , counting comma and space
I get 6 position alignment for operands.
Now, with "xm7" i can lower this to 5 position. Should I do that?
(I don't have "xm15" ).

Also, I've aligned the operand at 12 positions after their
instruction start, because this is the size of the longest
real instruction.

As for why i have instruction start at 8'th position.
It's because I've allocated the field at position 4-7
for instruction prefixes, and the "EMU_" is 4 positions.

Now I have:
1234567812345_12345_12345_
EMU_broadcastss ym13, xm10
EMU_blendvpsxm1,  xm2,  m3
   vblendvps
blendvps

I can ditch the prefix and shorten the operands. e.g. :
1234_1234_1234_1234_
VBROADCASTSS ym1, xm1
BLENDVPS m1,  m2,  m3

Is that acceptable? Or maybe you do mean:

1234_1234_1234_123
VBROADCASTSS ym1, xm1
BLENDVPS  m1, m2, m3

However I would prefer to use
1234_1234_1234_123
VBROADCASTSS ym1, xm1
BLENDVPS  m1,  m2,  m3
PBLENDVD xm1, xm2, xm3

(You do need fixed width font to see that correctly).

I'll wait for reply before doing that.

> Use xmN instead of xmmN (only really makes a difference when SWAP:s
> are used, but might as well do it "correctly").

Done.

> Use 32-bit operands, e.g. rNd, when 64-bit math isn't required.

Done

> Unless aligning every single loop entry helps a lot I'd avoid it since
> it does waste a bit of icache.

I'll redo my benchmarks, but I have placed these aligns for a reason.
At some point removed debug instructions started making my code
slower. So I've placed align to avoid random slowdowns.

> Explicitly using the carry flag as a branch condition is a bit weird.
> Generally using jg/jl/jge/jle tends to be clearer.

I use it to take advantage of the so called MacroFusion.
It allows the merge of cmp and jxx, as long as the branch
checks only one flag, so all signed branches are to be avoided
(as stated by intel manual).
The newer the cpu, the more opcodes (add/sub)
could be merged and less limitations.

>> +%ifdef __NASM_VER__
>> +%use "smartalign"
>> +ALIGNMODE p6
>> +%endif
>
> Assembler-specific ifdeffery should be avoided in individual files.
> Something equivalent already exists in x86inc actually but I don't
> remember if it was merged to FFmpeg from upstream (x264) yet.

Definitely not merged.

I hear a lot about the improved x86inc,
maybe it is time for you to merge it in FFmpeg?


>> +const_int32_offsets:
>> +%rep 8
>> +dd $-const_int32_offsets
>> +%endrep
>
> Isn't this just an overly complicated way of expressing "dd 0*4, 1*4,
> 2*4, 3*4, 4*4, 5*4, 6*4, 7*4"?

Yes.
Do you know a way that works with "times 8"?
I've done it this way to make it easy to change the size of the constant.

Do you request I change it?

>> +SECTION .text
>> +
>> +
>> +
>> +
>
> Reduce some of the excessive whitespace.

Will do with the other cosmetics.

>> +%macro HSUMPS 2 ; dst/src, tmp
>> +%if cpuflag(avx)
>> +  %if sizeof%1>=32  ; avx
>> +   vperm2f128   %2,   %1,   %1,   (0)*16+(1)   ;
>> %2=lo(%1)<<128+hi(%1)
>> +   vaddps   %1,   %2
>> +  %endif
>> +   vshufps  %2,   %1,   %1,   q1032
>> +   vaddps   %1,   %2
>> +   vshufps  %2,   %1,   %1,   q0321
>> +   vaddps   %1,   %2
>> +
>> +%else  ; this form is a bit faster than the short avx-like emulation.
>> +movaps  %2,   %1;[d,   c,   b,
>> a   ]
>> +shufps  %1,   %1,   q1032   ; %2=[b,   a,   d,
>> c   ]
>> +addps   %1,   %2; %1=[b+d, a+c, d+b,
>> c+a ]
>> +movaps  %2,   %1
>> +shufps  %1,   %1,   q0321   ; %2=[c+a, b+d, a+c,
>> d+b ]
>> +addps   %1,   %2; %1=[c+a+b+d, b+d+a+c, a+c+d+b,
>> d+b+c+a ]
>> +; all %1 members should be equal for as lon

Re: [FFmpeg-devel] [DISCUSSION] Motion Estimation API/Library

2017-08-01 Thread Ivan Kalvachev
On 8/1/17, Clément Bœsch  wrote:
> On Tue, Aug 01, 2017 at 09:18:33AM +, Davinder Singh wrote:
> [...]
>> > In particular, the main policy of FFmpeg is to not depend on external
>> > libraries for core features. Therefore, if your project is a separate
>> >
>>
>> Just to be clear, it won't be "external" library like OpenCV...
>>
>>
>> > library, it will definitely not be used by FFmpeg codecs like you wish
>> > in your first paragraph.
>> >
>> > If you want a fighting chance of a project that is not stillborn, I
>> > think you need to make it part of FFmpeg, and make sure important
>> >
>>
>> .. it will be part of FFmpeg like libavfilter, just a new module -
>> libmotion.
>>
>
> yeah, but not a good idea. Just make it an optional component of
> libavutil.

Why not keep the code in libavcodec?

I think that (I)DCT was also given standard API and it is still there.
Also some me_cmp_fn use (I)DCT.

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


  1   2   3   >