Re: [FFmpeg-devel] [Patch] Download dash content with byte range info

[Steven Liu]

2017-11-15 10:26 GMT+08:00 Colin NG :
> Please ignore the previous "patch" email.
>
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..68196e9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }

+static struct fragment * getFragment(char *range)
Camel-Case code style, please use name looks like : get_fragment

+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
check the seg , if av_mallocz is failed, it will error;
+
+memset(seg, 0, sizeof(struct fragment));
unnecessary memset, because av_mallocz is set seg to 0 already.

+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", &str_end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +546,13 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;

 if (!av_strcasecmp(fragmenturl_node->name, (const char
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = getFragment(range_val);// byte range on
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -550,11 +568,13 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 }
 rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  getFragment(range_val);// byte range on
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -571,12 +591,12 @@ static int
parse_manifest_segmenturlnode(AVFormatContext *s, struct representati
 seg->size = -1;
 dynarray_add(&rep->fragments, &rep->n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }

 return 0;
 }
-
 static int parse_manifest_segmenttimeline(AVFormatContext *s, struct
representation *rep,
   xmlNodePtr fragment_timeline_node)
 {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

[Umair Khan]

Hi,

On Wed, Nov 15, 2017 at 4:20 AM, Carl Eugen Hoyos  wrote:
> 2017-11-14 23:48 GMT+01:00 Carl Eugen Hoyos :
>> 2017-11-13 21:07 GMT+01:00 Thilo Borgmann :
>>> Am 13.11.17 um 21:06 schrieb Thilo Borgmann:
 Am 13.11.17 um 20:02 schrieb Umair Khan:
> Hi,
>
> On Mon, Nov 13, 2017 at 11:06 PM, Thilo Borgmann  
> wrote:
>> Hi,
>>
>>> On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  
>>> wrote:
 2017-11-12 20:30 GMT+01:00 Umair Khan :
> Hi,
>
> On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos 
>  wrote:
>> 2017-11-12 20:05 GMT+01:00 Umair Khan :
>>
>>> The attached patch fixes the address sanitizer issue.
>>
>> Breaks compilation here, how did you test?
>>
>> libavcodec/alsdec.c: In function ‘decode_var_block_data’:
>> libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’
>
> Sorry for the faulty patch. Here is the fixed one.

 The commit message of your patch is:
 libavcodec/als: fix address sanitization error in decoder

 Is there an error in current FFmpeg git head that asan
 shows? If not, the commit message makes no sense.

 I believe you should send two patches that are meant
 to be committed together, one of them fixing ticket #6297.
>>>
>>> This is the complete patchset.
>>
>> I need some days to find time to test this, earliest during the weekend 
>> I fear...
>>
>> What happens for
>> block_length < residual_index < opt_order?
>
> I didn't really understand this case. What's residual_index? Can you
> point to the source exactly?
>
> As far as the case where opt_order is more than block_length, my
> second patch handles that case only. The file which Michael sent was
> having asan issues because of the case when block_length < opt_order.
>
>> Another way of asking would be, where is the second loop from specs page 
>> 30 for that case?
>> (ISO/IEC 14496)
>
> The second loop is just converting parcor to lpc coefficients which is
> done here - 
> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L935
>
>> I think what puzzles CE is, that the problematic if() from the other 
>> patches is still untouched by your patch. So how could this be a valid 
>> solution even if your patch would actually improve the prediction part...
>> And I wonder the same ;)
>
> As said, it is valid to have opt_order greater than block_length.
> However, the decoder loop needs to be checked because we won't predict
> values more than the length of the block i.e., block_length. We use
> last K (prediction order, opt_order) values to predict the original K
> values of the current block.
>
>> Did you run FATE with your patch applied? I assume a big difference in 
>> output at the first glance (means FATE aks the conformance files should 
>> fail...)
>
> Yes. I did run FATE. It passes perfectly.
>
>> Thanks for driving this forward anyway :)
>
> I think the two patches fix the issues completely. I don't see any
> harm in applying this patchset. :)

 Which second patch exactly do you want to be applied along with this one?
>>>
>>> For convenience just send a patch that does both the changes you want to be 
>>> done...
>
> Sorry:
>
> Why do you want to merge two patches that are not necessarily related:
> Isn't one the revert that fixes a regression and one the new fix for the
> overread.

Just to reiterate, this thread contains all fo the emails with the patches.

One email has both of the patches.
And another email has one patch with both changes combined.

Feel free to apply which ever the one you want. I have run fate tests
and they work all fine. The logic also matches with what is written in
the spec.

I'm now moving to the ALS encoder tasks before we start with the next GSoC.

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

[FFmpeg-devel] [PATCH 08/11] avformat/replaygain: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/replaygain.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/replaygain.c b/libavformat/replaygain.c
index 707d3cd4f1..0d1fb7d11d 100644
--- a/libavformat/replaygain.c
+++ b/libavformat/replaygain.c
@@ -61,7 +61,7 @@ static int32_t parse_value(const char *value, int32_t min)
 }
 }
 
-if (abs(db) > (INT32_MAX - mb) / 10)
+if (FFABS(db) > (INT32_MAX - mb) / 10)
 return min;
 
 return db * 10 + sign * mb;
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 07/11] avformat/mxf: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/mxf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxf.c b/libavformat/mxf.c
index bfc3218b81..2e23b5d739 100644
--- a/libavformat/mxf.c
+++ b/libavformat/mxf.c
@@ -155,7 +155,7 @@ const MXFSamplesPerFrame 
*ff_mxf_get_samples_per_frame(AVFormatContext *s,
 int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
 AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
 
-diff.num = abs(diff.num);
+diff.num = FFABS(diff.num);
 
 if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
 return NULL;
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 09/11] avformat/swfenc: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/swfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/swfenc.c b/libavformat/swfenc.c
index cada45ef9a..f53db0fb2b 100644
--- a/libavformat/swfenc.c
+++ b/libavformat/swfenc.c
@@ -69,7 +69,7 @@ static inline void max_nbits(int *nbits_ptr, int val)
 
 if (val == 0)
 return;
-val = abs(val);
+val = FFABS(val);
 n = 1;
 while (val != 0) {
 n++;
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 10/11] avformat/utils: use FFABS to instead of fabs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/utils.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 87887063be..c2c9afbbfd 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3359,7 +3359,7 @@ void ff_rfps_calculate(AVFormatContext *ic)
 && st->r_frame_rate.num && st->info->rfps_duration_sum
 && st->info->codec_info_duration <= 0
 && st->info->duration_count > 2
-&& fabs(1.0 / (av_q2d(st->r_frame_rate) * av_q2d(st->time_base)) - 
st->info->rfps_duration_sum / (double)st->info->duration_count) <= 1.0
+&& FFABS(1.0 / (av_q2d(st->r_frame_rate) * av_q2d(st->time_base)) 
- st->info->rfps_duration_sum / (double)st->info->duration_count) <= 1.0
 ) {
 av_log(ic, AV_LOG_DEBUG, "Setting avg frame rate based on r frame 
rate\n");
 st->avg_frame_rate = st->r_frame_rate;
@@ -3921,7 +3921,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
  * within 1% of the original estimate. */
 for (j = 0; j < MAX_STD_TIMEBASES; j++) {
 AVRational std_fps = { get_std_framerate(j), 12 * 1001 };
-double error   = fabs(av_q2d(st->avg_frame_rate) /
+double error   = FFABS(av_q2d(st->avg_frame_rate) /
   av_q2d(std_fps) - 1);
 
 if (error < best_error) {
@@ -3930,7 +3930,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 
 if (ic->internal->prefer_codec_framerate && 
codec_frame_rate.num > 0 && codec_frame_rate.den > 0) {
-error   = fabs(av_q2d(codec_frame_rate) /
+error   = FFABS(av_q2d(codec_frame_rate) /
av_q2d(std_fps) - 1);
 if (error < best_error) {
 best_error = error;
@@ -4953,7 +4953,7 @@ AVRational av_guess_frame_rate(AVFormatContext *format, 
AVStream *st, AVFrame *f
 
 if (st->internal->avctx->ticks_per_frame > 1) {
 if (   codec_fr.num > 0 && codec_fr.den > 0 &&
-(fr.num == 0 || av_q2d(codec_fr) < av_q2d(fr)*0.7 && fabs(1.0 - 
av_q2d(av_div_q(avg_fr, fr))) > 0.1))
+(fr.num == 0 || av_q2d(codec_fr) < av_q2d(fr)*0.7 && FFABS(1.0 - 
av_q2d(av_div_q(avg_fr, fr))) > 0.1))
 fr = codec_fr;
 }
 
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 11/11] avformat/wavdecuse FFABS to instead of fabs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/wavdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/wavdec.c b/libavformat/wavdec.c
index b016185a1b..9f3e01e5b8 100644
--- a/libavformat/wavdec.c
+++ b/libavformat/wavdec.c
@@ -531,7 +531,7 @@ break_loop:
 && st->codecpar->sample_rate > 0
 && sample_count > 0 && st->codecpar->channels > 1
 && sample_count % st->codecpar->channels == 0) {
-if (fabs(8.0 * data_size * st->codecpar->channels * 
st->codecpar->sample_rate /
+if (FFABS(8.0 * data_size * st->codecpar->channels * 
st->codecpar->sample_rate /
 sample_count /st->codecpar->bit_rate - 1.0) < 0.3)
 sample_count /= st->codecpar->channels;
 }
-- 
2.11.0 (Apple Git-81)




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

[FFmpeg-devel] [PATCH 06/11] avformat/mux: use FFABS to instead of fabs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/mux.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index b1244c67f3..ec18c6d7b0 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -316,7 +316,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 goto fail;
 }
 if (av_cmp_q(st->sample_aspect_ratio, par->sample_aspect_ratio)
-&& fabs(av_q2d(st->sample_aspect_ratio) - 
av_q2d(par->sample_aspect_ratio)) > 0.004*av_q2d(st->sample_aspect_ratio)
+&& FFABS(av_q2d(st->sample_aspect_ratio) - 
av_q2d(par->sample_aspect_ratio)) > 0.004*av_q2d(st->sample_aspect_ratio)
 ) {
 if (st->sample_aspect_ratio.num != 0 &&
 st->sample_aspect_ratio.den != 0 &&
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 05/11] avformat/mp3dec: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/mp3dec.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index a5c4f2ea12..a76fe32e59 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -508,9 +508,9 @@ static int64_t mp3_sync(AVFormatContext *s, int64_t 
target_pos, int flags)
 return AVERROR(EINVAL);
 }
 }
-if ((target_pos - pos)*dir <= 0 && abs(MIN_VALID/2-j) < score) {
+if ((target_pos - pos)*dir <= 0 && FFABS(MIN_VALID/2-j) < score) {
 candidate = pos;
-score = abs(MIN_VALID/2-j);
+score = FFABS(MIN_VALID/2-j);
 }
 pos += ret;
 }
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 03/11] avformat/fitsdec: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/fitsdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/fitsdec.c b/libavformat/fitsdec.c
index 4b288b3903..b190118345 100644
--- a/libavformat/fitsdec.c
+++ b/libavformat/fitsdec.c
@@ -124,7 +124,7 @@ static int64_t is_image(AVFormatContext *s, FITSContext 
*fits, FITSHeader *heade
 return AVERROR_INVALIDDATA;
 size += header->pcount;
 
-t = (abs(header->bitpix) >> 3) * ((int64_t) header->gcount);
+t = (FFABS(header->bitpix) >> 3) * ((int64_t) header->gcount);
 if(size && t > UINT64_MAX / size)
 return AVERROR_INVALIDDATA;
 size *= t;
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 04/11] avformat/mov: use FFABS to instead of fabs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/mov.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index fd170baa57..e1a3e21e8d 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4332,7 +4332,7 @@ static int mov_read_tkhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 
 if (disp_transform[0] > 0   && disp_transform[1] > 0 &&
 disp_transform[0] < (1<<24) && disp_transform[1] < (1<<24) &&
-fabs((disp_transform[0] / disp_transform[1]) - 1.0) > 0.01)
+FFABS((disp_transform[0] / disp_transform[1]) - 1.0) > 0.01)
 st->sample_aspect_ratio = av_d2q(
 disp_transform[0] / disp_transform[1],
 INT_MAX);
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 01/11] avformat/hlsenc: use FFABS to instead of abs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/hlsenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index e0cef8b879..5af907b6f0 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -1113,7 +1113,7 @@ static int hls_window(AVFormatContext *s, int last)
 tm = gmtime_r(&tt, &tmpbuf);
 tm->tm_isdst = dst;
 wrongsecs = mktime(tm);
-tz_min = (abs(wrongsecs - tt) + 30) / 60;
+tz_min = (FFABS(wrongsecs - tt) + 30) / 60;
 snprintf(buf1, sizeof(buf1),
  "%c%02d%02d",
  wrongsecs <= tt ? '+' : '-',
-- 
2.11.0 (Apple Git-81)



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

[FFmpeg-devel] [PATCH 02/11] avformat/dump: use FFABS to instead of llabs

[Steven Liu]

Signed-off-by: Steven Liu 
---
 libavformat/dump.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/dump.c b/libavformat/dump.c
index 77043e3fdb..d414a6548f 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -586,8 +586,8 @@ void av_dump_format(AVFormatContext *ic, int index,
 if (ic->start_time != AV_NOPTS_VALUE) {
 int secs, us;
 av_log(NULL, AV_LOG_INFO, ", start: ");
-secs = llabs(ic->start_time / AV_TIME_BASE);
-us   = llabs(ic->start_time % AV_TIME_BASE);
+secs = FFABS(ic->start_time / AV_TIME_BASE);
+us   = FFABS(ic->start_time % AV_TIME_BASE);
 av_log(NULL, AV_LOG_INFO, "%s%d.%06d",
ic->start_time >= 0 ? "" : "-",
secs,
-- 
2.11.0 (Apple Git-81)



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

Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Aman Gupta]

On Tue, Nov 14, 2017 at 9:28 PM, Jeyapal, Karthick 
wrote:

>
> >On 11/15/17, 10:32 AM, "Aman Gupta"  wrote:
> >
> >From: Aman Gupta 
> >
> >Signed-off-by: Aman Gupta 
> >---
> > libavformat/http.c | 1 +
> > libavformat/tls.c  | 1 +
> > 2 files changed, 2 insertions(+)
>
> Again, do want to hardcode tcp_nodelay at http and tls level? Because
> there could be other muxers
> that send data in very small chunks where setting this option would
> actually increase the tcp overhead
> severely for such use-cases.
>
> I thought it would be better if the http plugin exposed this as an option
> and hls or dash muxers enable it,
> after we make sure that the relevant TS and MOV muxers used in hls and
> dash plugins writes data as
> big chunks(atleast one frame at a time or some kind of size limit). I
> think movenc already handles it with
> dynbuf avio and pushes it only at the end of the segment. But same can’t
> be said about the mpd file or
> m3u8 file posts. I think we need to examine the tcpdump logs(or wireshark)
> to make sure that the number
> of tcp packets doesn’t increase unexpectedly after this change.
>
> I am only saying this from muxer point of view. Similarly, we need think
> from demuxer point of view and
> make sure that enabling this doesn’t add any unnecessary tcp overhead
> there as well.
>
> My suggestion is to add tcp_nodelay as an option for http and tls and push
> this change.
> Later we can modify the hls and dash plugins separately to enable this
> optimization.
>

Hmm, I guess if we want this to propagate down we need to add the option to
the tls protocol as well, then pass it down when it instantiates the tcp
protocol. Then add the same option to hls/dash, and again propagate it down
to tls or tcp.

This is turning into a much bigger change than I anticipated, and I don't
really care enough about it to continue. If someone else wants to take over
this patchset, they are more than welcome to it.

Aman


>
> Thanks and regards,
> Karthick
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Jeyapal, Karthick]

>On 11/15/17, 10:32 AM, "Aman Gupta"  wrote:
>
>From: Aman Gupta 
>
>Signed-off-by: Aman Gupta 
>---
> libavformat/http.c | 1 +
> libavformat/tls.c  | 1 +
> 2 files changed, 2 insertions(+)

Again, do want to hardcode tcp_nodelay at http and tls level? Because there 
could be other muxers 
that send data in very small chunks where setting this option would actually 
increase the tcp overhead
severely for such use-cases.

I thought it would be better if the http plugin exposed this as an option and 
hls or dash muxers enable it, 
after we make sure that the relevant TS and MOV muxers used in hls and dash 
plugins writes data as 
big chunks(atleast one frame at a time or some kind of size limit). I think 
movenc already handles it with
dynbuf avio and pushes it only at the end of the segment. But same can’t be 
said about the mpd file or
m3u8 file posts. I think we need to examine the tcpdump logs(or wireshark) to 
make sure that the number
of tcp packets doesn’t increase unexpectedly after this change. 

I am only saying this from muxer point of view. Similarly, we need think from 
demuxer point of view and
make sure that enabling this doesn’t add any unnecessary tcp overhead there as 
well.

My suggestion is to add tcp_nodelay as an option for http and tls and push this 
change.
Later we can modify the hls and dash plugins separately to enable this 
optimization.

Thanks and regards,
Karthick

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

[FFmpeg-devel] [PATCH 1/2] lavu/qsv: fix the warning of unused variable

[Zhong Li]

variable 's' is declared but not used.

Signed-off-by: Zhong Li 
---
 libavutil/hwcontext_qsv.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
index 8e43420..9b6040b 100644
--- a/libavutil/hwcontext_qsv.c
+++ b/libavutil/hwcontext_qsv.c
@@ -989,7 +989,6 @@ static int qsv_device_derive_from_child(AVHWDeviceContext 
*ctx,
 int flags)
 {
 AVQSVDeviceContext *hwctx = ctx->hwctx;
-QSVDeviceContext   *s = ctx->internal->priv;
 
 mfxVersionver = { { 3, 1 } };
 mfxHDLhandle;
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH 2/2] lavf/qsv_overlay: fix compiling warning

[Zhong Li]

fix the compiling warning of "ignoring return value"

Signed-off-by: Zhong Li 
---
 libavfilter/vf_overlay_qsv.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
index 1f50d4b..001a1c3 100644
--- a/libavfilter/vf_overlay_qsv.c
+++ b/libavfilter/vf_overlay_qsv.c
@@ -415,6 +415,7 @@ static void overlay_qsv_uninit(AVFilterContext *ctx)
 static int overlay_qsv_query_formats(AVFilterContext *ctx)
 {
 int i;
+int ret;
 
 static const enum AVPixelFormat main_in_fmts[] = {
 AV_PIX_FMT_YUV420P,
@@ -431,9 +432,11 @@ static int overlay_qsv_query_formats(AVFilterContext *ctx)
 };
 
 for (i = 0; i < ctx->nb_inputs; i++)
-ff_formats_ref(ff_make_format_list(main_in_fmts), 
&ctx->inputs[i]->out_formats);
+if ((ret = ff_formats_ref(ff_make_format_list(main_in_fmts), 
&ctx->inputs[i]->out_formats)) < 0)
+return ret;
 
-ff_formats_ref(ff_make_format_list(out_pix_fmts), 
&ctx->outputs[0]->in_formats);
+if ((ret = ff_formats_ref(ff_make_format_list(out_pix_fmts), 
&ctx->outputs[0]->in_formats)) < 0)
+return ret;
 
 return 0;
 }
-- 
1.8.3.1

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

[FFmpeg-devel] [PATCH v3 1/2] avformat/tcp: add option to enable TCP_NODELAY

[Aman Gupta]

From: Aman Gupta 

This can reduce latency and increase throughput, particularly on high
latency networks.

Signed-off-by: Aman Gupta 
Reviewed-by: Jeyapal, Karthick 
---
 doc/protocols.texi| 3 +++
 libavformat/network.h | 1 +
 libavformat/tcp.c | 5 +
 3 files changed, 9 insertions(+)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index a7968ff56e..4d48f8a411 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1242,6 +1242,9 @@ Set receive buffer size, expressed bytes.
 
 @item send_buffer_size=@var{bytes}
 Set send buffer size, expressed bytes.
+
+@item tcp_nodelay=@var{1|0}
+Set TCP_NODELAY to disable Nagle's algorithm. Default value is 0.
 @end table
 
 The following example shows how to setup a listening TCP connection
diff --git a/libavformat/network.h b/libavformat/network.h
index f83c796a95..b78e3ad6ed 100644
--- a/libavformat/network.h
+++ b/libavformat/network.h
@@ -59,6 +59,7 @@ int ff_neterrno(void);
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #define ff_neterrno() AVERROR(errno)
diff --git a/libavformat/tcp.c b/libavformat/tcp.c
index 07b4ed9fa3..f3f9d4f431 100644
--- a/libavformat/tcp.c
+++ b/libavformat/tcp.c
@@ -41,6 +41,7 @@ typedef struct TCPContext {
 int listen_timeout;
 int recv_buffer_size;
 int send_buffer_size;
+int tcp_nodelay;
 } TCPContext;
 
 #define OFFSET(x) offsetof(TCPContext, x)
@@ -52,6 +53,7 @@ static const AVOption options[] = {
 { "listen_timeout",  "Connection awaiting timeout (in milliseconds)",  
OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
 { "send_buffer_size", "Socket send buffer size (in bytes)",
OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
 { "recv_buffer_size", "Socket receive buffer size (in bytes)", 
OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, 
.flags = D|E },
+{ "tcp_nodelay", "Use TCP_NODELAY to disable nagle's algorithm",   
OFFSET(tcp_nodelay), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, .flags = 
D|E },
 { NULL }
 };
 
@@ -148,6 +150,9 @@ static int tcp_open(URLContext *h, const char *uri, int 
flags)
 if (s->send_buffer_size > 0) {
 setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &s->send_buffer_size, sizeof 
(s->send_buffer_size));
 }
+if (s->tcp_nodelay > 0) {
+setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, &s->tcp_nodelay, sizeof 
(s->tcp_nodelay));
+}
 
 if (s->listen == 2) {
 // multi-client
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v3 2/2] avformat/{http, tls}: enable tcp_nodelay

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavformat/http.c | 1 +
 libavformat/tls.c  | 1 +
 2 files changed, 2 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 056d5f6583..f0a80b7add 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -468,6 +468,7 @@ static int http_listen(URLContext *h, const char *uri, int 
flags,
 NULL);
 if ((ret = av_dict_set_int(options, "listen", s->listen, 0)) < 0)
 goto fail;
+av_dict_set_int(options, "tcp_nodelay", 1, 0);
 if ((ret = ffurl_open_whitelist(&s->hd, lower_url, AVIO_FLAG_READ_WRITE,
 &h->interrupt_callback, options,
 h->protocol_whitelist, 
h->protocol_blacklist, h
diff --git a/libavformat/tls.c b/libavformat/tls.c
index 10e0792e29..a56f51f85b 100644
--- a/libavformat/tls.c
+++ b/libavformat/tls.c
@@ -104,6 +104,7 @@ int ff_tls_open_underlying(TLSShared *c, URLContext 
*parent, const char *uri, AV
 proxy_port, "/%s", dest);
 }
 
+av_dict_set_int(options, "tcp_nodelay", 1, 0);
 return ffurl_open_whitelist(&c->tcp, buf, AVIO_FLAG_READ_WRITE,
 &parent->interrupt_callback, options,
 parent->protocol_whitelist, 
parent->protocol_blacklist, parent);
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg12dec: avoid adding PANSCAN side data unless present

[Aman Gupta]

On Tue, Nov 14, 2017 at 4:01 PM Michael Niedermayer 
wrote:

> On Tue, Nov 14, 2017 at 10:04:02AM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  libavcodec/mpeg12dec.c | 20 ++--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> > index 82bb1286ff..2c96dfa638 100644
> > --- a/libavcodec/mpeg12dec.c
> > +++ b/libavcodec/mpeg12dec.c
> > @@ -54,6 +54,7 @@ typedef struct Mpeg1Context {
> >  int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
> >  int repeat_field;   /* true if we must repeat the field */
> >  AVPanScan pan_scan; /* some temporary storage for the
> panscan */
> > +int has_pan_scan;
> >  AVStereo3D stereo3d;
> >  int has_stereo3d;
> >  uint8_t *a53_caption;
> > @@ -1458,6 +1459,7 @@ static void 
> > mpeg_decode_sequence_display_extension(Mpeg1Context
> *s1)
> >
> >  s1->pan_scan.width  = 16 * w;
> >  s1->pan_scan.height = 16 * h;
> > +s1->has_pan_scan = 1;
> >
> >  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> >  av_log(s->avctx, AV_LOG_DEBUG, "sde w:%d, h:%d\n", w, h);
> > @@ -1489,6 +1491,8 @@ static void 
> > mpeg_decode_picture_display_extension(Mpeg1Context
> *s1)
> >  skip_bits(&s->gb, 1); // marker
> >  }
> >
> > +s1->has_pan_scan = 1;
> > +
> >  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
> >  av_log(s->avctx, AV_LOG_DEBUG,
> > "pde (%"PRId16",%"PRId16") (%"PRId16",%"PRId16")
> (%"PRId16",%"PRId16")\n",
> > @@ -1621,12 +1625,16 @@ static int mpeg_field_start(MpegEncContext *s,
> const uint8_t *buf, int buf_size)
> >  }
> >  }
> >
> > -pan_scan = av_frame_new_side_data(s->current_picture_ptr->f,
> > -  AV_FRAME_DATA_PANSCAN,
> > -  sizeof(s1->pan_scan));
> > -if (!pan_scan)
> > -return AVERROR(ENOMEM);
> > -memcpy(pan_scan->data, &s1->pan_scan, sizeof(s1->pan_scan));
> > +if (s1->has_pan_scan) {
> > +pan_scan = av_frame_new_side_data(s->
> current_picture_ptr->f,
> > +AV_FRAME_DATA_PANSCAN,
> > +sizeof(s1->pan_scan));
> > +if (!pan_scan)
> > +return AVERROR(ENOMEM);
> > +
> > +memcpy(pan_scan->data, &s1->pan_scan, sizeof(s1->pan_scan));
> > +s1->has_pan_scan = 0;
>
> the mpeg2 spec says:
> "In   the   casethatagivenpicturedoesnothave
>   a
>  picture_display_extension() then the  most  recently  decoded  frame
> centre
>  offset shall be used."
>
> "Following a sequence_header() the value zero shall be  used  for  all
> frame
>  centre offsets until a picture_display_extension() defines non-zero
> values."
>
> I dont think its a good idea to ommit the "most  recently  decoded
> frame  centre" on the subset of AVFrames which do not explicitly store
> it. That would make it hard for applications which want to access this,
> an application would have to keep track of the last one as well as
> where sequence headers occured


Sorry, my mistake.

Would the patch make sense if I removed the "has_pan_scan = 0" reset? Or is
it better just to always include PANSCAN side data to make it easier for
API consumers.

Aman


>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Old school: Use the lowest level language in which you can solve the
> problem
> conveniently.
> New school: Use the highest level language in which the latest
> supercomputer
> can solve the problem without the user falling asleep waiting.
> ___
> 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] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[刘歧]

> 在 2017年11月15日，07:14，Carl Eugen Hoyos  写道：
> 
> 2017-11-14 11:25 GMT+01:00 刘歧 :
> 
>> make fate failed:
>> 
>> ../configure --enable-gpl --enable-memory-poisoning --enable-avresample 
>> --cc='ccache arm-linux-gnueabi-gcc' --target-exec='qemu-arm -L 
>> /usr/arm-linux-gnueabi/' --arch=armv5te --cpu=armv5te --enable-cross-compile 
>> --target-os=linux --cross-prefix=/usr/arm-linux-gnueabi/bin/
>> 
>> root@localhost:~/ffmpeg/xxx# make fate-filter-hls-vs-with-master
>> GEN tests/data/hls-vs-with-master.m3u8
>> make: *** [tests/data/hls-vs-with-master.m3u8] Error 1
> 
> It seems to work here.
> 
> Could you run make V=1 fate-filter-hls-vs-with-master and
> test the resulting command manually so the error is shown?
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


all test info bellow:

1st, look at the ffmpeg.exe banner 
2nd, test with fate-filter-hls-append
3nd, test with filter-hls-vs-with-master

liuqi@localhost:~/ffmpeg/windows$ ./ffmpeg.exe
Application tried to create a window, but no driver could be loaded.
Make sure that your X server is running and that $DISPLAY is set correctly.
err:systray:initialize_systray Could not create tray window
ffmpeg version N-89040-g58cf31c Copyright (c) 2000-2017 the FFmpeg developers
  built with gcc 4.8 (GCC)
  configuration: --cc='ccache x86_64-w64-mingw32-gcc' --arch=x86_64 
--target-os=mingw32 --cross-prefix=x86_64-w64-mingw32- --disable-yasm 
--target_exec=wine
  libavutil  56.  0.100 / 56.  0.100
  libavcodec 58.  3.101 / 58.  3.101
  libavformat58.  2.102 / 58.  2.102
  libavdevice58.  0.100 / 58.  0.100
  libavfilter 7.  0.101 /  7.  0.101
  libswscale  5.  0.101 /  5.  0.101
  libswresample   3.  0.101 /  3.  0.101
Hyper fast Audio and Video encoder
usage: ffmpeg [options] [[infile options] -i infile]... {[outfile options] 
outfile}...

Use -h to get full help or, even better, run 'man ffmpeg'
liuqi@localhost:~/ffmpeg/windows$ make V=1 fate-filter-hls-append
TESTfilter-hls-append
/home/liuqi/ffmpeg/tests/fate-run.sh fate-filter-hls-append "" "wine " 
"/home/liuqi/ffmpeg/windows" 'framecrc -flags +bitexact -i 
/home/liuqi/ffmpeg/windows/tests/data/hls-list-append.m3u8 -af asetpts=RTCTIME' 
'' '' '' '1' '' '' '' '' '' '' '' '' ''
wine  /home/liuqi/ffmpeg/windows/ffmpeg -nostdin -nostats -cpuflags all -flags 
+bitexact -hwaccel none -threads 1 -thread_type frame+slice -i 
/home/liuqi/ffmpeg/windows/tests/data/hls-list-append.m3u8 -af asetpts=RTCTIME 
-flags +bitexact -fflags +bitexact -f framecrc -
liuqi@localhost:~/ffmpeg/windows$
liuqi@localhost:~/ffmpeg/windows$ make V=1 fate-filter-hls-vs-with-master
wine  /home/liuqi/ffmpeg/windows/ffmpeg.exe \
-f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -flags 
+bitexact -codec:a:0 mp2fixed -b:a:0 32k -codec:a:1 mp2fixed -b:a:1 128k -map 0 
-map 0 \
-f hls -var_stream_map "a:0 a:1" -hls_time 10 
-master_pl_name hls-master.m3u8 -hls_segment_filename 
/home/liuqi/ffmpeg/windows/tests/data/hls-vs-with-master-%03d.ts \
/home/liuqi/ffmpeg/windows/tests/data/hls-vs.m3u8 2>/dev/null
TESTfilter-hls-vs-with-master
/home/liuqi/ffmpeg/tests/fate-run.sh fate-filter-hls-vs-with-master "" "wine " 
"/home/liuqi/ffmpeg/windows" 'run ffmpeg.exe -nostdin -nostats -cpuflags all 
-flags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i 
/home/liuqi/ffmpeg/windows/tests/data/hls-vs_0.m3u8 -af asetpts=RTCTIME -flags 
+bitexact -fflags +bitexact -f framecrc - ; ffmpeg.exe -nostdin -nostats 
-cpuflags all \
  -flags +bitexact -hwaccel none -threads 1 -thread_type 
frame+slice \
  -i /home/liuqi/ffmpeg/windows/tests/data/hls-vs_1.m3u8 -af 
asetpts=RTCTIME -flags +bitexact -fflags +bitexact -f framecrc - ; cat 
/home/liuqi/ffmpeg/windows/tests/data/hls-master.m3u8' '' '' '' '1' '' '' '' '' 
'' '' '' '' ''
wine  /home/liuqi/ffmpeg/windows/ffmpeg.exe -nostdin -nostats -cpuflags all 
-flags +bitexact -hwaccel none -threads 1 -thread_type frame+slice -i 
/home/liuqi/ffmpeg/windows/tests/data/hls-vs_0.m3u8 -af asetpts=RTCTIME -flags 
+bitexact -fflags +bitexact -f framecrc -
--- /home/liuqi/ffmpeg/tests/ref/fate/filter-hls-vs-with-master 2017-11-14 
20:16:27.054005000 -0800
+++ tests/data/fate/filter-hls-vs-with-master   2017-11-14 20:24:07.358005000 
-0800
@@ -770,778 +770,6 @@
 0, 878976, 878976, 1152, 2304, 0xc52c95a6
 0, 880128, 880128, 1152, 2304, 0xde3f6929
 0, 881280, 881280, 1152, 2304, 0x5a798f16
-#tb 0: 1/44100
-#media_type 0: audio
-#codec_id 0: pcm_s16le
-#sample_rate 0: 44100
-#channel_layout 0: 4
-#channel_layout_name 0: mono
-0,  0,  0, 1152, 2304, 0x2396c945
-0,   1152,   1152, 1152, 2304, 0x7d9681b5
-0,   2304,   2304, 1152, 2304, 0x450973a6
-0,   3456,   3456, 1152, 

Re: [FFmpeg-devel] [PATCH] avcodec: deprecate getters and setters for AVCodecContext and AVCodec fields

[James Almer]

On 11/13/2017 12:16 AM, James Almer wrote:
> The fields can be accessed directly, so these are not needed anymore.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/avcodec.h | 20 
>  libavcodec/utils.c   |  2 ++
>  libavcodec/version.h |  3 +++
>  3 files changed, 25 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 8c76c9f908..9fda5dc270 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3235,22 +3235,39 @@ typedef struct AVCodecContext {
>  int apply_cropping;
>  } AVCodecContext;
>  
> +#if FF_API_CODEC_GET_SET
> +/**
> + * Accessors for some AVCodecContext fields. These used to be provided for 
> ABI
> + * compatibility, and do not need to be used anymore.
> + */
> +attribute_deprecated
>  AVRational av_codec_get_pkt_timebase (const AVCodecContext *avctx);
> +attribute_deprecated
>  void   av_codec_set_pkt_timebase (AVCodecContext *avctx, 
> AVRational val);
>  
> +attribute_deprecated
>  const AVCodecDescriptor *av_codec_get_codec_descriptor(const AVCodecContext 
> *avctx);
> +attribute_deprecated
>  void av_codec_set_codec_descriptor(AVCodecContext 
> *avctx, const AVCodecDescriptor *desc);
>  
> +attribute_deprecated
>  unsigned av_codec_get_codec_properties(const AVCodecContext *avctx);
>  
> +attribute_deprecated
>  int  av_codec_get_lowres(const AVCodecContext *avctx);
> +attribute_deprecated
>  void av_codec_set_lowres(AVCodecContext *avctx, int val);
>  
> +attribute_deprecated
>  int  av_codec_get_seek_preroll(const AVCodecContext *avctx);
> +attribute_deprecated
>  void av_codec_set_seek_preroll(AVCodecContext *avctx, int val);
>  
> +attribute_deprecated
>  uint16_t *av_codec_get_chroma_intra_matrix(const AVCodecContext *avctx);
> +attribute_deprecated
>  void av_codec_set_chroma_intra_matrix(AVCodecContext *avctx, uint16_t *val);
> +#endif
>  
>  /**
>   * AVProfile.
> @@ -3387,7 +3404,10 @@ typedef struct AVCodec {
>  const char *bsfs;
>  } AVCodec;
>  
> +#if FF_API_CODEC_GET_SET
> +attribute_deprecated
>  int av_codec_get_max_lowres(const AVCodec *codec);
> +#endif
>  
>  struct MpegEncContext;
>  
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index b3a578110b..e50de6e89b 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -552,6 +552,7 @@ enum AVPixelFormat avpriv_find_pix_fmt(const 
> PixelFormatTag *tags,
>  return AV_PIX_FMT_NONE;
>  }
>  
> +#if FF_API_CODEC_GET_SET
>  MAKE_ACCESSORS(AVCodecContext, codec, AVRational, pkt_timebase)
>  MAKE_ACCESSORS(AVCodecContext, codec, const AVCodecDescriptor *, 
> codec_descriptor)
>  MAKE_ACCESSORS(AVCodecContext, codec, int, lowres)
> @@ -567,6 +568,7 @@ int av_codec_get_max_lowres(const AVCodec *codec)
>  {
>  return codec->max_lowres;
>  }
> +#endif
>  
>  int avpriv_codec_get_cap_skip_frame_fill_param(const AVCodec *codec){
>  return !!(codec->caps_internal & FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM);
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 9c17e5716d..f4872267f1 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -120,6 +120,9 @@
>  #ifndef FF_API_GETCHROMA
>  #define FF_API_GETCHROMA (LIBAVCODEC_VERSION_MAJOR < 59)
>  #endif
> +#ifndef FF_API_CODEC_GET_SET
> +#define FF_API_CODEC_GET_SET (LIBAVCODEC_VERSION_MAJOR < 59)
> +#endif
>  
>  
>  #endif /* AVCODEC_VERSION_H */

Pushed alongside some patches removing their usage (i think i didn't
miss any).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/tcp: enable TCP_NODELAY by default

[Jeyapal, Karthick]

>On 11/14/17, 11:11 PM, "Aman Gupta" ffm...@tmm1.net> wrote:
>
>From: Aman Gupta 
>
>This can reduce latency and increase throughput, particularly on high
>latency networks.
>
>Signed-off-by: Aman Gupta 
>Reviewed-by: Jeyapal, Karthick 
---
I forgot to mention last time. You would also need to update the 
doc/protocols.texi
documentation explaining this new option.

Regards,
Karthick

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: Implement vc1 nvdec hwaccel

[Philip Langdale]

On Tue, 14 Nov 2017 21:14:58 +0100
Timo Rothenpieler  wrote:

> looks straight forward enough to me, struct naming matches up as well.
> 
> add a Changelog and bump lavc version, and it's good to go.
> 

Thanks. Pushed with Changelog and version bump.


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: Implement vc1 nvdec hwaccel

[Philip Langdale]

On Tue, 14 Nov 2017 21:07:45 +0100
Moritz Barsnick  wrote:

> On Tue, Nov 14, 2017 at 07:24:14 -0800, Philip Langdale wrote:
> > This hwaccel is interesting because it also works for wmv3/9
> > content, which is not supported by the nvidia parser used by
> > cuviddec.  
> 
> Nits:
> Changelog entry? Version bump?

Added in pushed change

> 
> > +case AV_CODEC_ID_VC1:  return cudaVideoCodec_VC1;
> >  case AV_CODEC_ID_VP9:  return cudaVideoCodec_VP9;
> > +case AV_CODEC_ID_WMV3:  return cudaVideoCodec_VC1;  
> 
> Alignment. ;-)

Gah, forgot. I'll fix when I add the next one :-)

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

[FFmpeg-devel] [PATCH] avcodec/mlpdsp: Fix undefined shift ff_mlp_pack_output()

[Michael Niedermayer]

Fixes: runtime error: left shift of negative value -7862264
Fixes: 4074/clusterfuzz-testcase-minimized-4516104123711488

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/mlpdsp.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mlpdsp.c b/libavcodec/mlpdsp.c
index fbafa92d72..4e3a16c781 100644
--- a/libavcodec/mlpdsp.c
+++ b/libavcodec/mlpdsp.c
@@ -117,7 +117,7 @@ int32_t ff_mlp_pack_output(int32_t lossless_check_data,
   (1U << output_shift[mat_ch]);
 lossless_check_data ^= (sample & 0xff) << mat_ch;
 if (is32)
-*data_32++ = sample << 8;
+*data_32++ = sample * 256;
 else
 *data_16++ = sample >> 8;
 }
-- 
2.15.0

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

[FFmpeg-devel] [Patch] Fix for ticket 6658 (Dash demuxer segfault)

[Colin NG]

- Add a function to handle the base URL Processing described in section 5.6.5 
of IEC_23009-1.

- Fix for downloading dash content with byte range info




diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..0be8a49 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -148,6 +148,10 @@ static uint64_t get_current_time_in_sec(void)
 return  av_gettime() / 100;
 }
 
+static int ishttp(char *url) {
+return (av_strstart(url, "http://";, NULL) || av_strstart(url, "https://";, 
NULL)) ;
+}
+
 static uint64_t get_utc_date_time_insec(AVFormatContext *s, const char 
*datetime)
 {
 struct tm timeinfo;
@@ -392,7 +396,10 @@ static int open_url(AVFormatContext *s, AVIOContext **pb, 
const char *url,
 else if (strcmp(proto_name, "file") || !strncmp(url, "file,", 5))
 return AVERROR_INVALIDDATA;
 
-ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
+if (pb) av_freep(pb);
+set_httpheader_options(c, &tmp);
+ret = avio_open2(pb, url, AVIO_FLAG_READ, c->interrupt_callback, &tmp);
+
 if (ret >= 0) {
 // update cookies on http response with setcookies.
 char *new_cookies = NULL;
@@ -522,6 +529,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * getFragment(char *range)
+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+memset(seg, 0, sizeof(struct fragment));
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", &str_end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +553,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;
 
 if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = getFragment(range_val);// byte range on
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -550,11 +575,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 }
 rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  getFragment(range_val);// byte range on
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -571,6 +598,7 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 seg->size = -1;
 dynarray_add(&rep->fragments, &rep->n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }
 
@@ -613,6 +641,86 @@ static int parse_manifest_segmenttimeline(AVFormatContext 
*s, struct representat
 return 0;
 }
 
+
+static int resolve_content_path(AVFormatContext *s, const char *url,  
xmlNodePtr *baseurl_nodes,  int n_baseurl_nodes) {
+
+int i;
+char *text;
+char tmp_str[MAX_URL_SIZE];
+char tmp_str_2[MAX_URL_SIZE];
+
+char *path = av_mallocz(MAX_URL_SIZE);
+int nameSize = 0;
+int updated = 0;
+
+av_strlcpy(tmp_str, url, strlen(url)+1);
+char *mpdName = strtok (tmp_str," /");
+
+while ((mpdName =strtok (NULL, "/")) != NULL)
+{
+nameSize = strlen(mpdName);
+}
+
+memset(path, 0, MAX_URL_SIZE* sizeof(char));
+av_strlcpy (path, url, strlen(url)-nameSize+1 );
+
+int rootId = 0;
+xmlNodePtr  *node = NULL;
+for (rootId = n_baseurl_nodes-1; rootId >0; rootId--)
+{
+if ((node = baseurl_nodes[rootId])== NULL) continue;
+
+if (ishttp(xmlNodeGetContent(node)) == TRUE)  {
+break;
+}
+}
+
+node = baseurl_nodes[rootId];
+char *baseurl = xmlNodeGetContent(node);
+char *root_url = (!av_strcasecmp(baseurl, ""))? path: baseurl;
+
+if (nod

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add tune-content option

[James Zern]

On Mon, Nov 13, 2017 at 6:05 PM, James Zern  wrote:
> On Mon, Nov 13, 2017 at 4:43 PM, James Almer  wrote:
>> On 11/13/2017 9:01 PM, James Zern wrote:
>>> Signed-off-by: James Zern 
>>> ---
>>>  doc/encoders.texi  |  2 ++
>>>  libavcodec/libvpxenc.c | 20 
>>>  2 files changed, 22 insertions(+)
>>>
>>> diff --git a/doc/encoders.texi b/doc/encoders.texi
>>> index 431777c457..23451b7b92 100644
>>> --- a/doc/encoders.texi
>>> +++ b/doc/encoders.texi
>>> @@ -1681,6 +1681,8 @@ colorspaces:
>>>  @end table
>>>  @item row-mt @var{boolean}
>>>  Enable row based multi-threading.
>>> +@item tune-content
>>
>> How about "tune" instead? That's what libx264 and libx265 use.
>>
>
> Unfortunately that exists too (psnr/ssim), this was forked for vp9 [1].
>

That one is mapped already too [2]. Recently we've been trying to
match the vpxenc options.

> [1] https://chromium.googlesource.com/webm/libvpx/+/v1.6.1/vpx/vp8cx.h#765
>

[2] 
https://github.com/FFmpeg/FFmpeg/blob/release/3.4/libavcodec/libvpxenc.c#L1096

>> Also, it may be a good time to resurrect your patch to bump the minimum
>> required version to 1.4.0, to clean some of the oldest ifdeffery. Debian
>> stable ships 1.6.1 now.
>>
>
> I can bring up the minimum in a followup if it's a good time.
>
>>> +Set content type: default (0), screen (1), film (2).
>>>  @end table
>>>
>>>  @end table
>>> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
>>> index d720301cd1..fbb842499b 100644
>>> --- a/libavcodec/libvpxenc.c
>>> +++ b/libavcodec/libvpxenc.c
>>> @@ -109,6 +109,7 @@ typedef struct VPxEncoderContext {
>>>  int vpx_cs;
>>>  float level;
>>>  int row_mt;
>>> +int tune_content;
>>>  } VPxContext;
>>>
>>>  /** String mappings for enum vp8e_enc_control_id */
>>> @@ -143,6 +144,9 @@ static const char *const ctlidstr[] = {
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  [VP9E_SET_ROW_MT]  = "VP9E_SET_ROW_MT",
>>>  #endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +[VP9E_SET_TUNE_CONTENT]= "VP9E_SET_TUNE_CONTENT",
>>> +#endif
>>>  #endif
>>>  };
>>>
>>> @@ -709,6 +713,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  if (ctx->row_mt >= 0)
>>>  codecctl_int(avctx, VP9E_SET_ROW_MT, ctx->row_mt);
>>> +#endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +if (ctx->tune_content >= 0)
>>> +codecctl_int(avctx, VP9E_SET_TUNE_CONTENT, ctx->tune_content);
>>>  #endif
>>>  }
>>>  #endif
>>> @@ -1139,6 +1147,18 @@ static const AVOption vp9_options[] = {
>>>  #endif
>>>  #ifdef VPX_CTRL_VP9E_SET_ROW_MT
>>>  {"row-mt", "Row based multi-threading", OFFSET(row_mt), 
>>> AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
>>> +#endif
>>> +#ifdef VPX_CTRL_VP9E_SET_TUNE_CONTENT
>>> +#if VPX_ENCODER_ABI_VERSION >= 14
>>> +{ "tune-content","Tune content type", OFFSET(tune_content), 
>>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, VE, "tune_content" },
>>> +#else
>>> +{ "tune-content","Tune content type", OFFSET(tune_content), 
>>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE, "tune_content" },
>>> +#endif
>>> +{ "default", "Regular video content",  0, 
>>> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, VE, "tune_content" },
>>> +{ "screen",  "Screen capture content", 0, 
>>> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE, "tune_content" },
>>> +#if VPX_ENCODER_ABI_VERSION >= 14
>>> +{ "film","Film content; improves grain retention", 0, 
>>> AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, VE, "tune_content" },
>>> +#endif
>>>  #endif
>>>  LEGACY_OPTIONS
>>>  { NULL }
>>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfoundation, unsupported framerate/activeVideoMinFrameDuration

[Roman Puttkammer]

Hi,

Attached patch fixes an issue with avfoundation; the code continues to
loop through
the list of
supported formats/framerates even after finding the chosen one, ending up
with a bad format/rate
combination. (Code breaks out of one loop only instead of two.)

rgds,
Roman

-
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index e2ddf47dbe..463ae60b63 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -312,6 +312,7 @@ static int configure_video_device(AVFormatContext *s,
AVCaptureDevice *video_dev
 }
 }
 }
+if (selected_range) break;
 }

 if (!selected_format) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [Patch] Download dash content with byte range info

[Colin NG]

Please ignore the previous "patch" email.



diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..68196e9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * getFragment(char *range)
+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+memset(seg, 0, sizeof(struct fragment));
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", &str_end_offset);
+seg->url_offset = strtoll(str_offset, NULL, 10);
+seg->size = strtoll(str_end_offset, NULL, 10) -seg->url_offset;
+}
+
+return seg;
+}
+
 static int parse_manifest_segmenturlnode(AVFormatContext *s, struct 
representation *rep,
  xmlNodePtr fragmenturl_node,
  xmlNodePtr *baseurl_nodes,
@@ -530,11 +546,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 {
 char *initialization_val = NULL;
 char *media_val = NULL;
+char *range_val = NULL;
 
 if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"Initialization")) {
 initialization_val = xmlGetProp(fragmenturl_node, "sourceURL");
-if (initialization_val) {
-rep->init_section = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "range");
+if (initialization_val || range_val) {
+rep->init_section = getFragment(range_val);// byte range on
 if (!rep->init_section) {
 xmlFree(initialization_val);
 return AVERROR(ENOMEM);
@@ -550,11 +568,13 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 }
 rep->init_section->size = -1;
 xmlFree(initialization_val);
+xmlFree(range_val);
 }
 } else if (!av_strcasecmp(fragmenturl_node->name, (const char 
*)"SegmentURL")) {
 media_val = xmlGetProp(fragmenturl_node, "media");
-if (media_val) {
-struct fragment *seg = av_mallocz(sizeof(struct fragment));
+range_val = xmlGetProp(fragmenturl_node, "mediaRange");
+if (media_val || range_val) {
+struct fragment *seg =  getFragment(range_val);// byte range on
 if (!seg) {
 xmlFree(media_val);
 return AVERROR(ENOMEM);
@@ -571,12 +591,12 @@ static int parse_manifest_segmenturlnode(AVFormatContext 
*s, struct representati
 seg->size = -1;
 dynarray_add(&rep->fragments, &rep->n_fragments, seg);
 xmlFree(media_val);
+xmlFree(range_val);
 }
 }
 
 return 0;
 }
-
 static int parse_manifest_segmenttimeline(AVFormatContext *s, struct 
representation *rep,
   xmlNodePtr fragment_timeline_node)
 {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [Patch] Download dash content with byte range info

[Colin NG]

diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 58afd71..bff4af6 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -1,3 +1,16 @@
+# use pkg-config for getting CFLAGS and LDLIBS
+FFMPEG_LIBS=libavdevice\
+libavformat\
+libavfilter\
+libavcodec \
+libswresample  \
+libswscale \
+libavutil  \
+
+CFLAGS += -Wall -g
+CFLAGS := $(shell pkg-config --cflags $(FFMPEG_LIBS)) $(CFLAGS)
+LDLIBS := $(shell pkg-config --libs $(FFMPEG_LIBS)) $(LDLIBS)
+
 EXAMPLES-$(CONFIG_AVIO_DIR_CMD_EXAMPLE)  += avio_dir_cmd
 EXAMPLES-$(CONFIG_AVIO_READING_EXAMPLE)  += avio_reading
 EXAMPLES-$(CONFIG_DECODE_AUDIO_EXAMPLE)  += decode_audio
@@ -19,6 +32,7 @@ EXAMPLES-$(CONFIG_RESAMPLING_AUDIO_EXAMPLE)  += 
resampling_audio
 EXAMPLES-$(CONFIG_SCALING_VIDEO_EXAMPLE) += scaling_video
 EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
 EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
+EXAMPLES-$(CONFIG_SAMPLE_EXAMPLE)   += sample
 
 EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
 EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/avio_reading.c b/doc/examples/avio_reading.c
index 7860fd5..c77b8f9 100644
--- a/doc/examples/avio_reading.c
+++ b/doc/examples/avio_reading.c
@@ -39,6 +39,15 @@ struct buffer_data {
 size_t size; ///< size left in the buffer
 };
 
+static int isLocal(char *url)
+{
+   if (av_strstart(url, "http://";, NULL) || av_strstart(url, "https://";, NULL))
+   {
+  return FALSE;
+   }
+   return TRUE;
+}
+
 static int read_packet(void *opaque, uint8_t *buf, int buf_size)
 {
 struct buffer_data *bd = (struct buffer_data *)opaque;
@@ -78,7 +87,28 @@ int main(int argc, char *argv[])
 av_register_all();
 
 /* slurp file content into buffer */
-ret = av_file_map(input_filename, &buffer, &buffer_size, 0, NULL);
+
+   if (isLocal(input_filename) == TRUE) 
+   {
+  ret = av_file_map(input_filename, &buffer, &buffer_size, 0, NULL);
+   }
+   else
+   {
+  AVIOContext *in = NULL;
+
+  ret = avio_open2(&in, input_filename, AVIO_FLAG_READ, NULL, NULL);
+
+  buffer_size = avio_size(in);
+
+  if (buffer_size <= 0) {
+ buffer_size = 8 * 1024;
+  }
+
+  if (buffer = av_mallocz(buffer_size) == NULL) {
+ return AVERROR(ENOMEM);
+  }
+  buffer_size = avio_read(in, buffer, buffer_size);
+   }
 if (ret < 0)
 goto end;
 
diff --git a/libavcodec/dsd.c b/libavcodec/dsd.c
index 9104f38..6742f53 100644
--- a/libavcodec/dsd.c
+++ b/libavcodec/dsd.c
@@ -21,7 +21,9 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+
 #include "libavcodec/internal.h"
+#include "libavutil/reverse.h"
 #include "libavcodec/mathops.h"
 #include "avcodec.h"
 #include "dsd_tablegen.h"
diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
index 1b332a7..2d77088 100644
--- a/libavcodec/tiff.c
+++ b/libavcodec/tiff.c
@@ -24,6 +24,8 @@
  * @author Konstantin Shishkov
  */
 
+#include "libavutil/reverse.h"
+
 #include "config.h"
 #if CONFIG_ZLIB
 #include 
diff --git a/libavcodec/xsubdec.c b/libavcodec/xsubdec.c
index 93fd0f4..2cfe24b 100644
--- a/libavcodec/xsubdec.c
+++ b/libavcodec/xsubdec.c
@@ -21,6 +21,8 @@
 
 #include "libavutil/mathematics.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/intmath.h"
+
 #include "avcodec.h"
 #include "get_bits.h"
 #include "bytestream.h"
diff --git a/libavdevice/v4l2-common.c b/libavdevice/v4l2-common.c
index 196c09b..80cd524 100644
--- a/libavdevice/v4l2-common.c
+++ b/libavdevice/v4l2-common.c
@@ -43,9 +43,9 @@ const struct fmt_map ff_fmt_conversion_table[] = {
 { AV_PIX_FMT_NV12,AV_CODEC_ID_RAWVIDEO, V4L2_PIX_FMT_NV12},
 { AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_MJPEG   },
 { AV_PIX_FMT_NONE,AV_CODEC_ID_MJPEG,V4L2_PIX_FMT_JPEG},
-#ifdef V4L2_PIX_FMT_H264
+//#ifdef V4L2_PIX_FMT_H264
 { AV_PIX_FMT_NONE,AV_CODEC_ID_H264, V4L2_PIX_FMT_H264},
-#endif
+//#endif
 #ifdef V4L2_PIX_FMT_MPEG4
 { AV_PIX_FMT_NONE,AV_CODEC_ID_MPEG4,V4L2_PIX_FMT_MPEG4   },
 #endif
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0e3afd2..68196e9 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -522,6 +522,22 @@ static enum AVMediaType get_content_type(xmlNodePtr node)
 return type;
 }
 
+static struct fragment * getFragment(char *range)
+{
+struct fragment * seg =  av_mallocz(sizeof(struct fragment));
+
+memset(seg, 0, sizeof(struct fragment));
+seg->size = -1;
+if (range)  {
+char *str_end_offset;
+char *str_offset = av_strtok(range, "-", &str_end_offset);
+seg->url_offset = strtoll(s

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/dvbsubdec: Avoid re-computing clut

[Michael Niedermayer]

On Sat, Nov 04, 2017 at 01:19:21AM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 3218/clusterfuzz-testcase-5390672154591232
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/dvbsubdec.c | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)

will apply

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

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


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/h264dec: Fix potential array overread

[Michael Niedermayer]

On Sun, Oct 22, 2017 at 01:41:56AM +0200, Michael Niedermayer wrote:
> add padding before scantable arrays
> 
> See: 522d850e68ec4b77d3477b3c8f55b1ba00a9d69a
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264dec.h | 1 +
>  1 file changed, 1 insertion(+)

will apply


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH v3 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 11:18:57AM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Signed-off-by: Aman Gupta 
> ---
>  libavcodec/mpeg12dec.c   | 39 +++
>  tests/fate/subtitles.mak |  3 +++
>  tests/ref/fate/sub-cc-scte20 | 15 +++
>  3 files changed, 57 insertions(+)
>  create mode 100644 tests/ref/fate/sub-cc-scte20

probably ok

thx

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] FATE on multiple platforms

[Ronald S. Bultje]

Hi,

On Tue, Nov 14, 2017 at 7:56 PM, Jim DeLaHunt 
wrote:

> On 2017-11-14 14:20, Carl Eugen Hoyos wrote:
>
>> 2017-11-14 18:28 GMT+01:00 Dixit, Vishwanath:
>>
>> One of my patches is in the review process. I am fairly new to
>>> the patch submission process and have a query regarding
>>> FATE testing on multiple platforms.
>>> The patch includes a new FATE test and I am expected to get
>>> it tested on ARM Linux, wine+MinGW, Ubuntu, MIPS Linux
>>> and OS X.
>>>
>> No?
>>
>> I believe you are expected to test it on those of these platforms
>> that you have access to.
>>
>> Carl Eugen
>>
> I interpret Carl Eugen as saying that a developer is expected to test
> their change on those platforms to which they have access, and so it's OK
> if a developer does not have access to all platforms, does not
> cross-compile, and does not test on all platforms.
>
> But recently another developer said something different:


What Carl Eugen says is indeed what we've always done. All of this assumes
we're working on generic code and we can reasonably predict there to not be
any platform-specific implications.

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

Re: [FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

[Carl Eugen Hoyos]

2017-11-15 1:56 GMT+01:00 Vittorio Giovara :

> @@ -2111,6 +2124,12 @@ static int mxf_parse_structural_metadata(MXFContext 
> *mxf)
>  st->codecpar->codec_id = container_ul->id;
>  st->codecpar->width = descriptor->width;
>  st->codecpar->height = descriptor->height; /* Field height, not 
> frame height */
> +
> +/*int coeffcients;
> +int primaries;
> +int transfer;
> +int range;
> +*/

I wanted to suggest to split the patch but I assume this wasn't intended.

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

Re: [FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

[Derek Buitenhuis]

On 11/15/2017 12:56 AM, Vittorio Giovara wrote:
> ---
>  libavfilter/vf_zscale.c | 26 --
>  libavformat/mxfdec.c| 20 
>  2 files changed, 44 insertions(+), 2 deletions(-)

Accidental inclusion of MXF code?

Also, Does the minimum zimg version need to be bumped in configure?

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

Re: [FFmpeg-devel] FATE on multiple platforms

[Jim DeLaHunt]

On 2017-11-14 14:20, Carl Eugen Hoyos wrote:

2017-11-14 18:28 GMT+01:00 Dixit, Vishwanath:


One of my patches is in the review process. I am fairly new to
the patch submission process and have a query regarding
FATE testing on multiple platforms.
The patch includes a new FATE test and I am expected to get
it tested on ARM Linux, wine+MinGW, Ubuntu, MIPS Linux
and OS X.

No?

I believe you are expected to test it on those of these platforms
that you have access to.

Carl Eugen
I interpret Carl Eugen as saying that a developer is expected to test 
their change on those platforms to which they have access, and so it's 
OK if a developer does not have access to all platforms, does not 
cross-compile, and does not test on all platforms.


But recently another developer said something different:

On 2017-11-14 04:08, 刘歧  wrote:

I have tested it on x86 64bit Ubuntu platform.   The fate test passes.

./configure --enable-gpl --enable-memory-poisoning --enable-avresample
sudo make -j4
make fate-filter-hls-vs-with-master
GEN tests/data/hls-vs-with-master.m3u8
TESTfilter-hls-vs-with-master

Currently, I do not have access to arm platform, so could you please help to 
resolve this issue? If I am not asking too much, can you please provide error 
file and report files generated, I will analyze them and find why the test is 
failing.

https://trac.ffmpeg.org/wiki/CompilationGuide

need test passed on ARM Linux、   wine+MinGW 、 Ubuntu 、 MIPS Linux 、 OS X；
I interpret 刘歧  as saying that a developer is 
expected to test their change on 5 platforms, namely "ARM Linux, 
wine+MinGW , Ubuntu, MIPS Linux, and OS X".  They are also saying that 
 either states this 
expectation or gives instructions for how to compile on those 5 
platforms.  But as I read the Compilation Guide, it does not state the 
expectation, and does not explain how to cross-compile or to test on 
platforms to which one does not have access.


I interpret the message from Dixit, Vishwanath  as 
trying to comply with the expectations I understood from the message of 
刘歧 .


So, what is the correct expectation for a developer testing their 
change?  Run FATE only on the platforms you have, or somehow target 5 
platforms regardless?


This would be another good piece of information to put in the 
instructions on submitting patches.


Thank you in advance for the clarification.
    —Jim DeLaHunt

--
--Jim DeLaHunt,j...@jdlh.com  http://blog.jdlh.com/  (http://jdlh.com/)
  multilingual websites consultant

  355-1027 Davie St, Vancouver BC V6E 4L2, Canada
 Canada mobile +1-604-376-8953

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

[FFmpeg-devel] [PATCH] vf_zscale: Add more supported input properties

[Vittorio Giovara]

---
 libavfilter/vf_zscale.c | 26 --
 libavformat/mxfdec.c| 20 
 2 files changed, 44 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 09fd842fe5..7d048da1ef 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -353,10 +353,10 @@ static int convert_matrix(enum AVColorSpace colorspace)
 return ZIMG_MATRIX_709;
 case AVCOL_SPC_UNSPECIFIED:
 return ZIMG_MATRIX_UNSPECIFIED;
-case AVCOL_SPC_BT470BG:
-return ZIMG_MATRIX_470BG;
 case AVCOL_SPC_SMPTE170M:
 return ZIMG_MATRIX_170M;
+case AVCOL_SPC_SMPTE240M:
+return ZIMG_MATRIX_240M;
 case AVCOL_SPC_YCGCO:
 return ZIMG_MATRIX_YCGCO;
 case AVCOL_SPC_BT2020_NCL:
@@ -374,10 +374,22 @@ static int convert_trc(enum AVColorTransferCharacteristic 
color_trc)
 return ZIMG_TRANSFER_UNSPECIFIED;
 case AVCOL_TRC_BT709:
 return ZIMG_TRANSFER_709;
+case AVCOL_TRC_GAMMA22:
+return ZIMG_TRANSFER_470_M;
+case AVCOL_TRC_GAMMA28:
+return ZIMG_TRANSFER_470_BG;
 case AVCOL_TRC_SMPTE170M:
 return ZIMG_TRANSFER_601;
+case AVCOL_TRC_SMPTE240M:
+return ZIMG_TRANSFER_240M;
 case AVCOL_TRC_LINEAR:
 return ZIMG_TRANSFER_LINEAR;
+case AVCOL_TRC_LOG:
+return ZIMG_TRANSFER_LOG_100;
+case AVCOL_TRC_LOG_SQRT:
+return ZIMG_TRANSFER_LOG_316;
+case AVCOL_TRC_IEC61966_2_4:
+return ZIMG_TRANSFER_IEC_61966_2_4;
 case AVCOL_TRC_BT2020_10:
 return ZIMG_TRANSFER_2020_10;
 case AVCOL_TRC_BT2020_12:
@@ -399,6 +411,10 @@ static int convert_primaries(enum AVColorPrimaries 
color_primaries)
 return ZIMG_PRIMARIES_UNSPECIFIED;
 case AVCOL_PRI_BT709:
 return ZIMG_PRIMARIES_709;
+case AVCOL_PRI_BT470M:
+return ZIMG_PRIMARIES_470_M;
+case AVCOL_PRI_BT470BG:
+return ZIMG_PRIMARIES_470_BG;
 case AVCOL_PRI_SMPTE170M:
 return ZIMG_PRIMARIES_170M;
 case AVCOL_PRI_SMPTE240M:
@@ -745,6 +761,8 @@ static const AVOption zscale_options[] = {
 { "2020", 0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS, "primaries" },
 { "bt709",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS, "primaries" },
+{ "bt470m",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_M},   0, 0, FLAGS, "primaries" },
+{ "bt470bg",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_470_BG},  0, 0, FLAGS, "primaries" },
 { "smpte170m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS, "primaries" },
 { "smpte240m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS, "primaries" },
 { "bt2020",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
@@ -756,9 +774,13 @@ static const AVOption zscale_options[] = {
 { "unspecified",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
 { "601",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS, "transfer" },
 { "linear",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LINEAR},  0, 0, FLAGS, "transfer" },
+{ "log100",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LOG_100},  0, 0, FLAGS, "transfer" },
+{ "log316",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_LOG_316},  0, 0, FLAGS, "transfer" },
 { "2020_10",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS, "transfer" },
 { "2020_12",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS, "transfer" },
 { "unknown",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
+{ "bt470m",   0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_470_M}, 0, 0, FLAGS, "transfer" },
+{ "bt470bg",  0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_470_BG}, 0, 0, FLAGS, "transfer" },
 { "smpte170m",0,   0, AV_OPT_TYPE_CONST, 
{.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS, "transfer" },
 { "bt709",0,   0, AV_OPT_TYPE_CONST, 
{.i6

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: Don't assume separate u and v planes in ff_alloc_picture

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 07:24:13AM -0800, Philip Langdale wrote:
> I'm confused at how none of the previous hwaccels hit this, but
> alloc_frame_buffer in ff_alloc_picture asserts that the linesize
> of planes 1 and 2 are the same. If the pixfmt has a single uv
> plane, like NV12, this won't be true.
> 
> So, let's only do this check if there are more than 2 planes.
> 
> I didn't bother investigating why, but vdpau avoids this by having
> all linesizes set to zero. Cute.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavcodec/mpegpicture.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)

LGTM

thx

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

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 03:36:49PM -0800, Thierry Foucu wrote:
> On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
> 
> > On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > > I don't know if the patch can be made more generic to work for all
> > > demuxers, because this patch requires that PTS of all packets be
> > available
> > > in the header.  The other route is to make it very specific to codecs
> > with
> > > B-frames.
> >
> > All PTS may not be available in MP4 either, in the live profile fragmented
> > MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> > code
> > say whether we seek to each fragment and make it available or not. I assume
> > you've tested such a case, or can (or know the fragment code)?
> >
> > It's feasible to restrict it to codecs, I suppose.
> >
> > >> You do not appear to be restricting this to one specific codec, or even
> > >> codecs
> > >> with B-frames.
> > >>
> > >> I can make it specific to only H264 / H265.
> >
> > The GOP structure should be applicable to most MPEG codecs, I think.
> >
> > > It is true that the patch will fail to compute the correct delay in lots
> > of
> > > cases. However the consequence of wrongly computing the has_b_frames is
> > > pretty benign. It only increases the buffer size held for PTS
> > reordering.
> > > I can put a max-value check on the computed video_delay here. So in my
> > > opinion, we won't see fatal regressions where a file is not able to be
> > > decoded / played.
> >
> > It's true it's likely benign, but it's not exactly a "fix" either...
> >
> > From a user perspective, it's kinda possible to work around it "properly"
> > (I use that term loosely here) by decoding enough frames to fill the max
> > DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> > (or in a user's code if they don't use that function), isn't it? Though,
> > I feel that particular fix won't be welcomed with open arms, due to a
> > ~16x 'slow down' in probing.
> >
> >
> One option i asked on IRC was to use the spec for max DPB when the bitstream
> restriction flag was not set.
> But people were worry about low latency usage.
> Normally, if the  bitstream restriction flag is not set, the DPB should be
> set based on the spec, even if there is no B frames.
> But in some case, it will be 16 frame and this could increase then the low
> latency.

it could also increase memory requirements substantially


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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Carl Eugen Hoyos]

2017-11-15 0:36 GMT+01:00 Thierry Foucu :
> On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
>
>> On 11/14/2017 10:11 PM, Sasi Inguva wrote:
>> > I don't know if the patch can be made more generic to work for all
>> > demuxers, because this patch requires that PTS of all packets be
>> available
>> > in the header.  The other route is to make it very specific to codecs
>> with
>> > B-frames.
>>
>> All PTS may not be available in MP4 either, in the live profile fragmented
>> MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
>> code
>> say whether we seek to each fragment and make it available or not. I assume
>> you've tested such a case, or can (or know the fragment code)?
>>
>> It's feasible to restrict it to codecs, I suppose.
>>
>> >> You do not appear to be restricting this to one specific codec, or even
>> >> codecs
>> >> with B-frames.
>> >>
>> >> I can make it specific to only H264 / H265.
>>
>> The GOP structure should be applicable to most MPEG codecs, I think.
>>
>> > It is true that the patch will fail to compute the correct delay in lots
>> of
>> > cases. However the consequence of wrongly computing the has_b_frames is
>> > pretty benign. It only increases the buffer size held for PTS
>> reordering.
>> > I can put a max-value check on the computed video_delay here. So in my
>> > opinion, we won't see fatal regressions where a file is not able to be
>> > decoded / played.
>>
>> It's true it's likely benign, but it's not exactly a "fix" either...
>>
>> From a user perspective, it's kinda possible to work around it "properly"
>> (I use that term loosely here) by decoding enough frames to fill the max
>> DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
>> (or in a user's code if they don't use that function), isn't it? Though,
>> I feel that particular fix won't be welcomed with open arms, due to a
>> ~16x 'slow down' in probing.
>>
> One option i asked on IRC was to use the spec for max DPB when the
> bitstream restriction flag was not set.

I believe this should be done if the user had set -strict 1

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mpeg12dec: avoid adding PANSCAN side data unless present

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 10:04:02AM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/mpeg12dec.c | 20 ++--
>  1 file changed, 14 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
> index 82bb1286ff..2c96dfa638 100644
> --- a/libavcodec/mpeg12dec.c
> +++ b/libavcodec/mpeg12dec.c
> @@ -54,6 +54,7 @@ typedef struct Mpeg1Context {
>  int mpeg_enc_ctx_allocated; /* true if decoding context allocated */
>  int repeat_field;   /* true if we must repeat the field */
>  AVPanScan pan_scan; /* some temporary storage for the panscan */
> +int has_pan_scan;
>  AVStereo3D stereo3d;
>  int has_stereo3d;
>  uint8_t *a53_caption;
> @@ -1458,6 +1459,7 @@ static void 
> mpeg_decode_sequence_display_extension(Mpeg1Context *s1)
>  
>  s1->pan_scan.width  = 16 * w;
>  s1->pan_scan.height = 16 * h;
> +s1->has_pan_scan = 1;
>  
>  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
>  av_log(s->avctx, AV_LOG_DEBUG, "sde w:%d, h:%d\n", w, h);
> @@ -1489,6 +1491,8 @@ static void 
> mpeg_decode_picture_display_extension(Mpeg1Context *s1)
>  skip_bits(&s->gb, 1); // marker
>  }
>  
> +s1->has_pan_scan = 1;
> +
>  if (s->avctx->debug & FF_DEBUG_PICT_INFO)
>  av_log(s->avctx, AV_LOG_DEBUG,
> "pde (%"PRId16",%"PRId16") (%"PRId16",%"PRId16") 
> (%"PRId16",%"PRId16")\n",
> @@ -1621,12 +1625,16 @@ static int mpeg_field_start(MpegEncContext *s, const 
> uint8_t *buf, int buf_size)
>  }
>  }
>  
> -pan_scan = av_frame_new_side_data(s->current_picture_ptr->f,
> -  AV_FRAME_DATA_PANSCAN,
> -  sizeof(s1->pan_scan));
> -if (!pan_scan)
> -return AVERROR(ENOMEM);
> -memcpy(pan_scan->data, &s1->pan_scan, sizeof(s1->pan_scan));
> +if (s1->has_pan_scan) {
> +pan_scan = av_frame_new_side_data(s->current_picture_ptr->f,
> +AV_FRAME_DATA_PANSCAN,
> +sizeof(s1->pan_scan));
> +if (!pan_scan)
> +return AVERROR(ENOMEM);
> +
> +memcpy(pan_scan->data, &s1->pan_scan, sizeof(s1->pan_scan));
> +s1->has_pan_scan = 0;

the mpeg2 spec says:
"In   the   casethatagivenpicturedoesnothavea
 picture_display_extension() then the  most  recently  decoded  frame  centre
 offset shall be used."

"Following a sequence_header() the value zero shall be  used  for  all  frame
 centre offsets until a picture_display_extension() defines non-zero values."

I dont think its a good idea to ommit the "most  recently  decoded
frame  centre" on the subset of AVFrames which do not explicitly store
it. That would make it hard for applications which want to access this,
an application would have to keep track of the last one as well as
where sequence headers occured


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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

On 11/14/2017 11:36 PM, Thierry Foucu wrote:
> One option i asked on IRC was to use the spec for max DPB when the bitstream
> restriction flag was not set.
> But people were worry about low latency usage.
> Normally, if the  bitstream restriction flag is not set, the DPB should be
> set based on the spec, even if there is no B frames.
> But in some case, it will be 16 frame and this could increase then the low
> latency.

I guess that's a problem inherent to a generic API that tries to satisfy all
use cases - you can't please everyone.

I don't really have a /good/ solution given the use-case constraints, as
per previous email. :/

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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: November 14, 2017 6:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On 14/11/17 22:10, Mironov, Mikhail wrote:
> >> On 14/11/17 17:14, Mironov, Mikhail wrote:
> > +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> > + &ctx-
> >>> context);
> > +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
>  AVERROR_UNKNOWN,
>  "CreateContext() failed with error %d\n", res);
> > +// try to reuse existing DX device
> > +if (avctx->hw_frames_ctx) {
> > +AVHWFramesContext *device_ctx =
> > + (AVHWFramesContext*)avctx-
> > hw_frames_ctx->data;
> > +if (device_ctx->device_ctx->type ==
> >> AV_HWDEVICE_TYPE_D3D11VA){
> > +if (amf_av_to_amf_format(device_ctx->sw_format)
> > + ==
> > + AMF_SURFACE_UNKNOWN) {
> 
>  This test is inverted.
> 
>  Have you actually tested this path?  Even with that test fixed,
>  I'm unable to pass the following initialisation test with an
>  AMD
>  D3D11
>  device.
> 
> >>>
> >>> Yes, the condition should be reverted. To test I had to add
> >>> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the
> command
>  line.
> >>
> >> Yeah.  I get:
> >>
> >> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
> >> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
> >> h264_amf
> >> out.mp4 ...
> >> [AVHWDeviceContext @ 0270e120] Created on device
> >> 1002:665f
> >> (AMD Radeon (TM) R7 360 Series).
> >> ...
> >> [h264_amf @ 004dcd80] amf_shared: avctx-
> >hw_frames_ctx
>  has
> >> non-AMD device, switching to default
> >>
> >> It's then comedically slow in this state (about 2fps), but works
> >> fine when the decode is in software.
> >
> > Is it possible that you also have iGPU not disabled and it is used
> > for
>  decoding as adapter 0?
> 
>  There is an integrated GPU, but it's currently completely disabled.
>  (I made
>    November/219795.html> to check that the device was definitely
>  right.)
> 
> > Can you provide a log from dxdiag.exe?
> 
>  
> 
> > If AMF created own DX device then submission logic an speed is the
> > same
>  as from SW decoder.
> > It would be interesting to see a short GPUVIEW log.
> 
>  My Windows knowledge is insufficient to get that immediately, but
>  if you think it's useful I can look into it?
> >>>
> >>> I think I know what is going on. You are on Win7. In Win7 D3D11VA
> >>> API is
> >> not available from MSFT.
> >>> AMF will fall into DX9 based encoding submission and this is why the
> >> message was produced.
> >>> The AMF performance should be the same on DX9 but I don’t know how
> >>> decoding is done without D3D11VA support.
> >>> GPUVIEW is not really needed if my assumptions are correct.
> >>
> >> Ah, that would make sense.  Maybe detect it and fail earlier with a
> >> helpful message - the current "not an AMD device" is wrong in this case.
> >>
> >> Decode via D3D11 does work for me on Windows 7 with both AMD and
> >> Intel; I don't know anything about how, though.  (I don't really care
> >> about Windows 7 - this was just a set of parts mashed together into a
> >> working machine for testing, the Windows 7 install is inherited from
> >> elsewhere.)
> >
> > I run this in Win7.  What I see is the decoding does go via D3D11VA.
> > The support comes with Platform Update. But AMF encoder works on Win7
> > via D3D9 only. That explains the performance hit: In D3D11 to copy video
> output HW accelerator copies frame via staging texture.
> > If I use for decoding DXVA2 it is faster because staging texture is not
> needed.
> > I am thinking to connect dxva2 acceleration with AMF encoder but
> > probably in the next phase.
> > I've added more precise logging.
> >
> >>
> > +{ "filler_data","Filler Data Enable",
> >> OFFSET(filler_data),
>  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "vbaq",   "Enable VBAQ",
>  OFFSET(enable_vbaq),
>  AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> > +{ "frame_skipping", "Rate Control Based Frame Skip",
>  OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE
> },
> > +
> > +/// QP Values
> > +{ "qp_i",   "Quantization Parameter for I-Frame",
>  OFFSET(qp_i),
>  AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> > +{ "qp_p",   "Quantization Parameter for P-Frame",
> 

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Thierry Foucu]

On Tue, Nov 14, 2017 at 3:23 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> > I don't know if the patch can be made more generic to work for all
> > demuxers, because this patch requires that PTS of all packets be
> available
> > in the header.  The other route is to make it very specific to codecs
> with
> > B-frames.
>
> All PTS may not be available in MP4 either, in the live profile fragmented
> MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing
> code
> say whether we seek to each fragment and make it available or not. I assume
> you've tested such a case, or can (or know the fragment code)?
>
> It's feasible to restrict it to codecs, I suppose.
>
> >> You do not appear to be restricting this to one specific codec, or even
> >> codecs
> >> with B-frames.
> >>
> >> I can make it specific to only H264 / H265.
>
> The GOP structure should be applicable to most MPEG codecs, I think.
>
> > It is true that the patch will fail to compute the correct delay in lots
> of
> > cases. However the consequence of wrongly computing the has_b_frames is
> > pretty benign. It only increases the buffer size held for PTS
> reordering.
> > I can put a max-value check on the computed video_delay here. So in my
> > opinion, we won't see fatal regressions where a file is not able to be
> > decoded / played.
>
> It's true it's likely benign, but it's not exactly a "fix" either...
>
> From a user perspective, it's kinda possible to work around it "properly"
> (I use that term loosely here) by decoding enough frames to fill the max
> DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
> (or in a user's code if they don't use that function), isn't it? Though,
> I feel that particular fix won't be welcomed with open arms, due to a
> ~16x 'slow down' in probing.
>
>
One option i asked on IRC was to use the spec for max DPB when the bitstream
restriction flag was not set.
But people were worry about low latency usage.
Normally, if the  bitstream restriction flag is not set, the DPB should be
set based on the spec, even if there is no B frames.
But in some case, it will be 16 frame and this could increase then the low
latency.



> Does anyone else have an opinion™ on this? I guess it's "OK enough" if
> restricted by codec...? :V
>
> - Derek
> ___
> 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] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

On 11/14/2017 10:11 PM, Sasi Inguva wrote:
> I don't know if the patch can be made more generic to work for all
> demuxers, because this patch requires that PTS of all packets be available
> in the header.  The other route is to make it very specific to codecs with
> B-frames.

All PTS may not be available in MP4 either, in the live profile fragmented
MP4 case, no? I am not familiar enough with the fragmented MP4 demuxing code
say whether we seek to each fragment and make it available or not. I assume
you've tested such a case, or can (or know the fragment code)?

It's feasible to restrict it to codecs, I suppose.

>> You do not appear to be restricting this to one specific codec, or even
>> codecs
>> with B-frames.
>>
>> I can make it specific to only H264 / H265.

The GOP structure should be applicable to most MPEG codecs, I think.

> It is true that the patch will fail to compute the correct delay in lots of
> cases. However the consequence of wrongly computing the has_b_frames is
> pretty benign. It only increases the buffer size held for PTS  reordering.
> I can put a max-value check on the computed video_delay here. So in my
> opinion, we won't see fatal regressions where a file is not able to be
> decoded / played.

It's true it's likely benign, but it's not exactly a "fix" either...

From a user perspective, it's kinda possible to work around it "properly"
(I use that term loosely here) by decoding enough frames to fill the max
DPB for a given codec (e.g. 16 for H.264) in avformat_find_stream_info
(or in a user's code if they don't use that function), isn't it? Though,
I feel that particular fix won't be welcomed with open arms, due to a
~16x 'slow down' in probing.

Does anyone else have an opinion™ on this? I guess it's "OK enough" if
restricted by codec...? :V

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Carl Eugen Hoyos]

2017-11-14 11:25 GMT+01:00 刘歧 :

> make fate failed:
>
> ../configure --enable-gpl --enable-memory-poisoning --enable-avresample 
> --cc='ccache arm-linux-gnueabi-gcc' --target-exec='qemu-arm -L 
> /usr/arm-linux-gnueabi/' --arch=armv5te --cpu=armv5te --enable-cross-compile 
> --target-os=linux --cross-prefix=/usr/arm-linux-gnueabi/bin/
>
> root@localhost:~/ffmpeg/xxx# make fate-filter-hls-vs-with-master
> GEN tests/data/hls-vs-with-master.m3u8
> make: *** [tests/data/hls-vs-with-master.m3u8] Error 1

It seems to work here.

Could you run make V=1 fate-filter-hls-vs-with-master and
test the resulting command manually so the error is shown?

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

Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: creation of hls variant streams with master playlist in a single hlsenc instance

[Carl Eugen Hoyos]

2017-11-14 7:42 GMT+01:00 Dixit, Vishwanath :
>
>
>>On 11/13/17, 3:28 PM, "刘歧"  wrote:
>>root@localhost:~/ffmpeg# patch -p1 < 
>>~/0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch
>>patching file doc/muxers.texi
>>patching file libavformat/hlsenc.c
>>Hunk #47 FAILED at 1622.
>>1 out of 58 hunks FAILED -- saving rejects to file 
>> libavformat/hlsenc.c.rej
>>patching file libavformat/version.h
>>Hunk #1 FAILED at 33.
>>1 out of 1 hunk FAILED -- saving rejects to file libavformat/version.h.rej
>>liuqideMBP:ffmpeg liuqi$ git reset --hard
>>HEAD is now at 43171a2a73 Fix missing used attribute for inline assembly 
>> variables
>>liuqideMBP:ffmpeg liuqi$ git am 
>> ~/0001-avformat-hlsenc-creation-of-hls-variant-streams-in-a.patch
>>fatal: previous rebase directory .git/rebase-apply still exists but mbox 
>> given.
>>liuqideMBP:ffmpeg liuqi$
>
>  I have re-based the patches. Please find the updated patches in the 
> attachment.

The first patch adds three warnings here (val has to be const),
the second adds an unused variable, please fix both issues.

(I wonder if the first patch could be simplified into "splitting
the struct" and "adding the new feature".)

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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mark Thompson]

On 14/11/17 22:10, Mironov, Mikhail wrote:
>> On 14/11/17 17:14, Mironov, Mikhail wrote:
> +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> + &ctx-
>>> context);
> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
 AVERROR_UNKNOWN,
 "CreateContext() failed with error %d\n", res);
> +// try to reuse existing DX device
> +if (avctx->hw_frames_ctx) {
> +AVHWFramesContext *device_ctx =
> + (AVHWFramesContext*)avctx-
> hw_frames_ctx->data;
> +if (device_ctx->device_ctx->type ==
>> AV_HWDEVICE_TYPE_D3D11VA){
> +if (amf_av_to_amf_format(device_ctx->sw_format) ==
> + AMF_SURFACE_UNKNOWN) {

 This test is inverted.

 Have you actually tested this path?  Even with that test fixed,
 I'm unable to pass the following initialisation test with an AMD
 D3D11
 device.

>>>
>>> Yes, the condition should be reverted. To test I had to add
>>> "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
 line.
>>
>> Yeah.  I get:
>>
>> $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
>> hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
>> h264_amf
>> out.mp4 ...
>> [AVHWDeviceContext @ 0270e120] Created on device
>> 1002:665f
>> (AMD Radeon (TM) R7 360 Series).
>> ...
>> [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
 has
>> non-AMD device, switching to default
>>
>> It's then comedically slow in this state (about 2fps), but works
>> fine when the decode is in software.
>
> Is it possible that you also have iGPU not disabled and it is used
> for
 decoding as adapter 0?

 There is an integrated GPU, but it's currently completely disabled.
 (I made
  to check that the device was definitely right.)

> Can you provide a log from dxdiag.exe?

 

> If AMF created own DX device then submission logic an speed is the
> same
 as from SW decoder.
> It would be interesting to see a short GPUVIEW log.

 My Windows knowledge is insufficient to get that immediately, but if
 you think it's useful I can look into it?
>>>
>>> I think I know what is going on. You are on Win7. In Win7 D3D11VA API is
>> not available from MSFT.
>>> AMF will fall into DX9 based encoding submission and this is why the
>> message was produced.
>>> The AMF performance should be the same on DX9 but I don’t know how
>>> decoding is done without D3D11VA support.
>>> GPUVIEW is not really needed if my assumptions are correct.
>>
>> Ah, that would make sense.  Maybe detect it and fail earlier with a helpful
>> message - the current "not an AMD device" is wrong in this case.
>>
>> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel;
>> I don't know anything about how, though.  (I don't really care about
>> Windows 7 - this was just a set of parts mashed together into a working
>> machine for testing, the Windows 7 install is inherited from elsewhere.)
> 
> I run this in Win7.  What I see is the decoding does go via D3D11VA. The 
> support comes 
> with Platform Update. But AMF encoder works on Win7 via D3D9 only. That 
> explains 
> the performance hit: In D3D11 to copy video output HW accelerator copies 
> frame via staging texture. 
> If I use for decoding DXVA2 it is faster because staging texture is not 
> needed.
> I am thinking to connect dxva2 acceleration with AMF encoder 
> but probably in the next phase.
> I've added more precise logging.
> 
>>
> +{ "filler_data","Filler Data Enable",
>> OFFSET(filler_data),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +{ "vbaq",   "Enable VBAQ",
 OFFSET(enable_vbaq),
 AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +{ "frame_skipping", "Rate Control Based Frame Skip",
 OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> +
> +/// QP Values
> +{ "qp_i",   "Quantization Parameter for I-Frame",
 OFFSET(qp_i),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +{ "qp_p",   "Quantization Parameter for P-Frame",
>> OFFSET(qp_p),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +{ "qp_b",   "Quantization Parameter for B-Frame",
>> OFFSET(qp_b),
 AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> +
> +/// Pre-Pass, Pre-Analysis, Two-Pass
> +{ "preanalysis","Pre-Analysis Mode",
>> OFFSET(preanalysis),
 AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
> +
> +/// Maximum Access Unit Size
> +{ "max_au_size","Maximum Acc

Re: [FFmpeg-devel] avcodec/qsvenc Question for Intel QSV low latency

[Carl Eugen Hoyos]

2017-11-14 17:02 GMT+01:00 Natsuki Kai :
> Hi Moritz,
>
> Thank you for explaining in details. It really helped me.
> It seems gmail or other mail tool shouldn't be used, but only "git
> send-email" is accepted.

Just send your patch - made with git format-patch - as
attachment. This should work with all mail clients.

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

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: November 14, 2017 5:32 PM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD
> GPUs based on AMF SDK
> 
> On Tue, Nov 14, 2017 at 6:45 PM, Mark Thompson  wrote:
> >
> > Decode via D3D11 does work for me on Windows 7 with both AMD and
> > Intel; I don't know anything about how, though.  (I don't really care
> > about Windows 7 - this was just a set of parts mashed together into a
> > working machine for testing, the Windows 7 install is inherited from
> > elsewhere.)
> 
> Even with the platform update, D3D11 on Windows 7 does not support
> NV12 textures. All you could potentially decode into is the opaque format,
> but thats not much fun at all.
> 

I thought the same way but today I debugged FFmpeg on Win7 and saw that 
CreateTexture2D() with DXGI_FORMAT_NV12 succeeded and 
video device and context acquired.. 
I think some optional update requeued, though. 

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

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

Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

[Carl Eugen Hoyos]

2017-11-14 23:48 GMT+01:00 Carl Eugen Hoyos :
> 2017-11-13 21:07 GMT+01:00 Thilo Borgmann :
>> Am 13.11.17 um 21:06 schrieb Thilo Borgmann:
>>> Am 13.11.17 um 20:02 schrieb Umair Khan:
 Hi,

 On Mon, Nov 13, 2017 at 11:06 PM, Thilo Borgmann  
 wrote:
> Hi,
>
>> On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  
>> wrote:
>>> 2017-11-12 20:30 GMT+01:00 Umair Khan :
 Hi,

 On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos 
  wrote:
> 2017-11-12 20:05 GMT+01:00 Umair Khan :
>
>> The attached patch fixes the address sanitizer issue.
>
> Breaks compilation here, how did you test?
>
> libavcodec/alsdec.c: In function ‘decode_var_block_data’:
> libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’

 Sorry for the faulty patch. Here is the fixed one.
>>>
>>> The commit message of your patch is:
>>> libavcodec/als: fix address sanitization error in decoder
>>>
>>> Is there an error in current FFmpeg git head that asan
>>> shows? If not, the commit message makes no sense.
>>>
>>> I believe you should send two patches that are meant
>>> to be committed together, one of them fixing ticket #6297.
>>
>> This is the complete patchset.
>
> I need some days to find time to test this, earliest during the weekend I 
> fear...
>
> What happens for
> block_length < residual_index < opt_order?

 I didn't really understand this case. What's residual_index? Can you
 point to the source exactly?

 As far as the case where opt_order is more than block_length, my
 second patch handles that case only. The file which Michael sent was
 having asan issues because of the case when block_length < opt_order.

> Another way of asking would be, where is the second loop from specs page 
> 30 for that case?
> (ISO/IEC 14496)

 The second loop is just converting parcor to lpc coefficients which is
 done here - 
 https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L935

> I think what puzzles CE is, that the problematic if() from the other 
> patches is still untouched by your patch. So how could this be a valid 
> solution even if your patch would actually improve the prediction part...
> And I wonder the same ;)

 As said, it is valid to have opt_order greater than block_length.
 However, the decoder loop needs to be checked because we won't predict
 values more than the length of the block i.e., block_length. We use
 last K (prediction order, opt_order) values to predict the original K
 values of the current block.

> Did you run FATE with your patch applied? I assume a big difference in 
> output at the first glance (means FATE aks the conformance files should 
> fail...)

 Yes. I did run FATE. It passes perfectly.

> Thanks for driving this forward anyway :)

 I think the two patches fix the issues completely. I don't see any
 harm in applying this patchset. :)
>>>
>>> Which second patch exactly do you want to be applied along with this one?
>>
>> For convenience just send a patch that does both the changes you want to be 
>> done...

Sorry:

Why do you want to merge two patches that are not necessarily related:
Isn't one the revert that fixes a regression and one the new fix for the
overread.

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

Re: [FFmpeg-devel] [DEVEL][PATCH v3] ffmpeg: fix channel_layout bug on non-default layout

[pkv.stream]

Le 14/11/2017 à 1:13 PM, Michael Niedermayer a écrit :

On Sun, Nov 12, 2017 at 06:26:18PM +0100, pkv.stream wrote:

Le 12/11/2017 à 5:38 PM, Michael Niedermayer a écrit :

On Sun, Nov 12, 2017 at 05:07:04PM +0100, Kv Pham wrote:

Le 12 nov. 2017 5:01 PM, "Michael Niedermayer"  a
écrit :

On Sat, Nov 11, 2017 at 02:15:25AM +0100, pkv.stream wrote:

Le 11/11/2017 à 1:07 AM, Michael Niedermayer a écrit :

On Fri, Nov 10, 2017 at 10:27:48PM +0100, pkv.stream wrote:

Le 10/11/2017 à 1:12 AM, Michael Niedermayer a écrit :

On Thu, Nov 09, 2017 at 09:37:33PM +0100, pkv.stream wrote:

Hi Michael,


  ffmpeg_opt.c |   11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)
2af07f4366efdfaf1018bb2ea29be672befe0823  0001-ffmpeg-fix-channel_

layout-bug-on-non-default-layout.patch

 From 4ec55dc88923108132307b41300a1abddf32e6f7 Mon Sep 17 00:00:00

2001

From: pkviet
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default

layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout

was not

a default one (ex: for 4 channels, quad was interpreted as 4.0

which is

the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical

channel

layouts.
The fix operates by directly calling the channel layout if defined

in

options. If the layout is undefined, the default layout is selected

as

before the fix.
---
  ffmpeg_opt.c | 11 ++-
  1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 100fa76..cf5a63c 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -1804,6 +1804,12 @@ static OutputStream *new_audio_stream(OptionsContext

*o, AVFormatContext *oc, in

  MATCH_PER_STREAM_OPT(audio_channels, i,

audio_enc->channels, oc, st);

+AVDictionaryEntry *output_layout =

av_dict_get(o->g->codec_opts,

+

  "channel_layout",

+   NULL,

AV_DICT_MATCH_CASE);

This doesnt look right

not an issue of the patch as such but
why is the channel_layout option per file and not per stream?

just my ignorance; do you mean this is not the right way to retrieve
the channel_layout option from an audio stream ?

I think there is more buggy with how the channel_layout is handled

try this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout 5 test.wav
and this:
./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg -channel_layout:a 5 test.wav

while it may appear that the are both working this is deceiving.
I think only the channel number gets actually used in the 2nd case

Look at what your code with av_dict_get() reads.
It does not obtain the 5 in the 2nd case

ok I fixed that by using the flag AV_DICT_IGNORE_SUFFIX ; now
-channel_layout:a works as expected.
I fixed also all the styling issues you spotted (mixed declarations,
{} for if etc).

Still not understanding your initial comment though :
'why is the channel_layout option per file and not per stream?'

do you mean o->g->codec_opts is not where I should retrieve the
channel_layout ? if not where from ?

Thanks


[...]


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

  ffmpeg_opt.c |   12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)
849898d28e989ffa5cc598c6fe4d43847b636132  0001-ffmpeg-fix-channel_

layout-bug-on-non-default-layout.patch

 From 6d4f1c14135f9473b77e1c649d0e7bbaeba00a50 Mon Sep 17 00:00:00 2001
From: pkviet
Date: Mon, 2 Oct 2017 11:14:31 +0200
Subject: [PATCH] ffmpeg: fix channel_layout bug on non-default layout

Fix for ticket 6706.
The -channel_layout option was not working when the channel layout was

not

a default one (ex: for 4 channels, quad was interpreted as 4.0 which is
the default layout for 4 channels; or octagonal interpreted as 7.1).
This led to the spurious auto-insertion of an auto-resampler filter
remapping the channels even if input and output had identical channel
layouts.
The fix operates by directly calling the channel layout if defined in
options. If the layout is undefined, the default layout is selected as
before the fix.
---
  fftools/ffmpeg_opt.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index ca6f10d..cb25d7b 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -1785,6 +1785,7 @@ static OutputStream *new_audio_stream(OptionsContext

*o, AVFormatContext *oc, in

  AVStream *st;
  OutputStream *ost;
  AVCodecContext *audio_enc;
+AVDictionaryEntry *output_layout;
  ost = new_output_stream(o, oc, AVMEDIA_TYPE_AUDIO, source_index);
  st  = ost->st;
@@ -1799,7 +1800,10 @@ static OutputStream *new_audio_stream(OptionsContext

*o, AVFormatContext *oc, in

  char *sample_fmt = NULL

Re: [FFmpeg-devel] libavcodec/als: remove check for predictor order of a block

[Carl Eugen Hoyos]

2017-11-13 21:07 GMT+01:00 Thilo Borgmann :
> Am 13.11.17 um 21:06 schrieb Thilo Borgmann:
>> Am 13.11.17 um 20:02 schrieb Umair Khan:
>>> Hi,
>>>
>>> On Mon, Nov 13, 2017 at 11:06 PM, Thilo Borgmann  
>>> wrote:
 Hi,

> On Mon, Nov 13, 2017 at 1:09 AM, Carl Eugen Hoyos  
> wrote:
>> 2017-11-12 20:30 GMT+01:00 Umair Khan :
>>> Hi,
>>>
>>> On Mon, Nov 13, 2017 at 12:45 AM, Carl Eugen Hoyos  
>>> wrote:
 2017-11-12 20:05 GMT+01:00 Umair Khan :

> The attached patch fixes the address sanitizer issue.

 Breaks compilation here, how did you test?

 libavcodec/alsdec.c: In function ‘decode_var_block_data’:
 libavcodec/alsdec.c:938:7: error: expected ‘}’ before ‘else’
>>>
>>> Sorry for the faulty patch. Here is the fixed one.
>>
>> The commit message of your patch is:
>> libavcodec/als: fix address sanitization error in decoder
>>
>> Is there an error in current FFmpeg git head that asan
>> shows? If not, the commit message makes no sense.
>>
>> I believe you should send two patches that are meant
>> to be committed together, one of them fixing ticket #6297.
>
> This is the complete patchset.

 I need some days to find time to test this, earliest during the weekend I 
 fear...

 What happens for
 block_length < residual_index < opt_order?
>>>
>>> I didn't really understand this case. What's residual_index? Can you
>>> point to the source exactly?
>>>
>>> As far as the case where opt_order is more than block_length, my
>>> second patch handles that case only. The file which Michael sent was
>>> having asan issues because of the case when block_length < opt_order.
>>>
 Another way of asking would be, where is the second loop from specs page 
 30 for that case?
 (ISO/IEC 14496)
>>>
>>> The second loop is just converting parcor to lpc coefficients which is
>>> done here - 
>>> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/alsdec.c#L935
>>>
 I think what puzzles CE is, that the problematic if() from the other 
 patches is still untouched by your patch. So how could this be a valid 
 solution even if your patch would actually improve the prediction part...
 And I wonder the same ;)
>>>
>>> As said, it is valid to have opt_order greater than block_length.
>>> However, the decoder loop needs to be checked because we won't predict
>>> values more than the length of the block i.e., block_length. We use
>>> last K (prediction order, opt_order) values to predict the original K
>>> values of the current block.
>>>
 Did you run FATE with your patch applied? I assume a big difference in 
 output at the first glance (means FATE aks the conformance files should 
 fail...)
>>>
>>> Yes. I did run FATE. It passes perfectly.
>>>
 Thanks for driving this forward anyway :)
>>>
>>> I think the two patches fix the issues completely. I don't see any
>>> harm in applying this patchset. :)
>>
>> Which second patch exactly do you want to be applied along with this one?
>
> For convenience just send a patch that does both the changes you want to be 
> done...

Wieso?

Das Revert und der neue Fix des ursprünglichen Issues sind doch
zwei verschiedene Dinge.

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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

[pkv.stream]

Le 14/11/2017 à 11:14 PM, Carl Eugen Hoyos a écrit :

2017-11-14 21:01 GMT+01:00 pkv.stream :

Le 14/11/2017 à 1:20 AM, Carl Eugen Hoyos a écrit :

2017-11-09 9:01 GMT+01:00 pkv.stream :


1) there are changes to make to the list of channel layouts not requiring
PCE

==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK
since the previous is
5.0(side) while the latter is 5.0 which is what is in spec (table 1.19
ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )

see patch in attachment (can't be applied directly due to rebasing issues
from your initial patch)

Did you test what effect this patch has on ffmpeg (the command line
interface)
when encoding five- or six-channel aac from back and side source?

yes I did check, this patch reverts aac encoder to previous behaviour with
5.0 and 5.1 (when there was no PCE)


more accurately: 5.0 5.1 back is reverted to previous behaviour  , but 
5.0 5.1 side is not because it uses now PCE, which agrees with spec (no 
weird channel rematrixing though); sorry for the inaccuracy.



Thank you for the explanation!

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] [PATCH] Add FAQs about running in background

[Carl Eugen Hoyos]

2017-11-14 12:38 GMT+01:00 Jim DeLaHunt :

> Those are good comments. Thank you. I can see how to improve the wording.

> I could add them to my current branch, and submit a new patch.

Yes, this is what is expected.

Please do not top-post here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Hendrik Leppkes]

On Tue, Nov 14, 2017 at 6:45 PM, Mark Thompson  wrote:
>
> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel; I 
> don't know anything about how, though.  (I don't really care about Windows 7 
> - this was just a set of parts mashed together into a working machine for 
> testing, the Windows 7 install is inherited from elsewhere.)

Even with the platform update, D3D11 on Windows 7 does not support
NV12 textures. All you could potentially decode into is the opaque
format, but thats not much fun at all.

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

Re: [FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

[Carl Eugen Hoyos]

2017-11-14 20:47 GMT+01:00 Mark Thompson :

> Silly example using everything (for i965 VAAPI + Beignet):
>
> ./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128
> -init_hw_device opencl=ocl@va -hwaccel vaapi
> -hwaccel_device va -hwaccel_output_format vaapi -i in.mp4
> -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl
> -filter_complex '[1:v]format=yuva420p,hwupload[x2];
> [0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1];
> [x1][x2]overlay_opencl=0:0,

> program_opencl=test.cl

Is this the equivalent of the vhook functionality?

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

Re: [FFmpeg-devel] avcodec/hapqa_extract_bsf : add bsf filter for haqqa (to hapq or hapalpha only) conversion (WIP)

[Carl Eugen Hoyos]

2017-11-14 10:55 GMT+01:00 Martin Vignali :
> 2017-11-14 1:26 GMT+01:00 Carl Eugen Hoyos :
>
>> 2017-11-13 22:43 GMT+01:00 Martin Vignali :
>>
>> > In attach patch to add a new bitstream filter
>> >
>> > The goal is to convert HAPQA file to HAPQ (removing alpha)
>> > or HAPAlphaOnly (remove rgb)
>>
>> Could you explain the usecase?
>
> Split HAPQA in two files can be useful when events player doesn't support
> the HAPQA version (two texture). So we need to split in two files
>
> Removing alpha, can be useful when graphic artist, output file with alpha,
> but alpha can be "replace" by blending mode (so we can reduce size, GPU
> bandwith need (specially when using several high resolution layer))
>
> Only keeping alpha :
> An use, can be to output an HAPQA using Quicktime official plugin (who
> doesn't support HAP Alpha Only), and keep only the Alpha part. In other
> words, it's a way to create HAP Alpha Only file

Thank you!

No more comments from me, please wait for others.

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

Re: [FFmpeg-devel] FATE on multiple platforms

[Carl Eugen Hoyos]

2017-11-14 18:28 GMT+01:00 Dixit, Vishwanath :

> One of my patches is in the review process. I am fairly new to
> the patch submission process and have a query regarding
> FATE testing on multiple platforms.

> The patch includes a new FATE test and I am expected to get
> it tested on ARM Linux, wine+MinGW, Ubuntu, MIPS Linux
> and OS X.

No?

I believe you are expected to test it on those of these platforms
that you have access to.

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

Re: [FFmpeg-devel] [PATCH]lavf/matroskaenc: Do not write 0 duration for subtitles

[Carl Eugen Hoyos]

2017-11-14 19:02 GMT+01:00 Jerome Martinez :
> On 12/11/2017 03:12, Carl Eugen Hoyos wrote:
>>
>> -put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration);
>> +if (duration > 0)
>> +put_ebml_uint(pb, MATROSKA_ID_BLOCKDURATION, duration);
>
>
> In that case, the duration of the block is DefaultDuration (if it exists),
> completely different.
> Is it intended to say that a duration of 0 at this place means that the
> block has the default block duration if it exists?
>
> What is the use case for a duration of 0?

Iirc, pgs subtitles send an empty "frame" to reset / remove the
subtitle.

> (Note: the meaning of the a block duration of 0 is unclear to me, I'll ask
> on CELLAR mailing list to clarify that)

So maybe the issue is with mkvalidate?

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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

[Carl Eugen Hoyos]

2017-11-14 21:01 GMT+01:00 pkv.stream :
> Le 14/11/2017 à 1:20 AM, Carl Eugen Hoyos a écrit :
>>
>> 2017-11-09 9:01 GMT+01:00 pkv.stream :
>>
>>> 1) there are changes to make to the list of channel layouts not requiring
>>> PCE
>>>
>>> ==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK
>>> since the previous is
>>> 5.0(side) while the latter is 5.0 which is what is in spec (table 1.19
>>> ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )
>>>
>>> see patch in attachment (can't be applied directly due to rebasing issues
>>> from your initial patch)
>>
>> Did you test what effect this patch has on ffmpeg (the command line
>> interface)
>> when encoding five- or six-channel aac from back and side source?
>
> yes I did check, this patch reverts aac encoder to previous behaviour with
> 5.0 and 5.1 (when there was no PCE)

Thank you for the explanation!

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Sasi Inguva]

I don't know if the patch can be made more generic to work for all
demuxers, because this patch requires that PTS of all packets be available
in the header.  The other route is to make it very specific to codecs with
B-frames.

On Tue, Nov 14, 2017 at 12:40 PM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 8:28 PM, Sasi Inguva wrote:
> > For H264 files with no bitstream restriction flag, we aren't able to
> guess
> > the delay correctly. Especially if it's MOV container, because for MOV
> > container we just probe the 1st frame and stop in
> avformat_find_streaminfo .
>
> You do not appear to be restricting this to one specific codec, or even
> codecs
> with B-frames.
>
> I can make it specific to only H264 / H265.


> > When we are decoding , we increase the has_b_frames value from zero to 1
> or
> > 2, when we eventually encounter B-frames in H264 decoder, but that is too
> > late and we have already dropped 1 or 2 frames. Lot of other fields in
> > codecpar are being set from the demuxer like channel_layout, sample_rate
> > etc.
>
> I am aware of the intend, however...
>
> The difference between filling those fields in and this patch, is that we
> can
> read those values directly, generally. This is a guess; a heuristic. A
> heuristic
> based on the GOP structure of a single codec. Where we guess where a GOP
> even
> starts. Nor does it seem to take into account non-friendly files, with
> oddly
> ordered and/or invalid timestamps (which it can't, based solely on PTS).
>
> I'm pretty tired of hitting insane edge cases in other types of files due
> to
> hacks added for some other specific set of file, but used for *everything*.
> This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep
> more out...
>
It is true that the patch will fail to compute the correct delay in lots of
cases. However the consequence of wrongly computing the has_b_frames is
pretty benign. It only increases the buffer size held for PTS  reordering.
I can put a max-value check on the computed video_delay here. So in my
opinion, we won't see fatal regressions where a file is not able to be
decoded / played.


>
> - Derek
> ___
> 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] Added HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

[Mironov, Mikhail]

> On 14/11/17 17:14, Mironov, Mikhail wrote:
> >>> +res = ctx->factory->pVtbl->CreateContext(ctx->factory,
> >>> + &ctx-
> > context);
> >>> +AMF_RETURN_IF_FALSE(ctx, res == AMF_OK,
> >> AVERROR_UNKNOWN,
> >> "CreateContext() failed with error %d\n", res);
> >>> +// try to reuse existing DX device
> >>> +if (avctx->hw_frames_ctx) {
> >>> +AVHWFramesContext *device_ctx =
> >>> + (AVHWFramesContext*)avctx-
> >>> hw_frames_ctx->data;
> >>> +if (device_ctx->device_ctx->type ==
>  AV_HWDEVICE_TYPE_D3D11VA){
> >>> +if (amf_av_to_amf_format(device_ctx->sw_format) ==
> >>> + AMF_SURFACE_UNKNOWN) {
> >>
> >> This test is inverted.
> >>
> >> Have you actually tested this path?  Even with that test fixed,
> >> I'm unable to pass the following initialisation test with an AMD
> >> D3D11
> >> device.
> >>
> >
> > Yes, the condition should be reverted. To test I had to add
> > "-hwaccel d3d11va -hwaccel_output_format d3d11" to the command
> >> line.
> 
>  Yeah.  I get:
> 
>  $ ./ffmpeg_g -y -hwaccel d3d11va -hwaccel_device 0 -
>  hwaccel_output_format d3d11 -i ~/bbb_1080_264.mp4 -an -c:v
> h264_amf
>  out.mp4 ...
>  [AVHWDeviceContext @ 0270e120] Created on device
> 1002:665f
>  (AMD Radeon (TM) R7 360 Series).
>  ...
>  [h264_amf @ 004dcd80] amf_shared: avctx->hw_frames_ctx
> >> has
>  non-AMD device, switching to default
> 
>  It's then comedically slow in this state (about 2fps), but works
>  fine when the decode is in software.
> >>>
> >>> Is it possible that you also have iGPU not disabled and it is used
> >>> for
> >> decoding as adapter 0?
> >>
> >> There is an integrated GPU, but it's currently completely disabled.
> >> (I made
> >>  >> November/219795.html> to check that the device was definitely right.)
> >>
> >>> Can you provide a log from dxdiag.exe?
> >>
> >> 
> >>
> >>> If AMF created own DX device then submission logic an speed is the
> >>> same
> >> as from SW decoder.
> >>> It would be interesting to see a short GPUVIEW log.
> >>
> >> My Windows knowledge is insufficient to get that immediately, but if
> >> you think it's useful I can look into it?
> >
> > I think I know what is going on. You are on Win7. In Win7 D3D11VA API is
> not available from MSFT.
> > AMF will fall into DX9 based encoding submission and this is why the
> message was produced.
> > The AMF performance should be the same on DX9 but I don’t know how
> > decoding is done without D3D11VA support.
> > GPUVIEW is not really needed if my assumptions are correct.
> 
> Ah, that would make sense.  Maybe detect it and fail earlier with a helpful
> message - the current "not an AMD device" is wrong in this case.
> 
> Decode via D3D11 does work for me on Windows 7 with both AMD and Intel;
> I don't know anything about how, though.  (I don't really care about
> Windows 7 - this was just a set of parts mashed together into a working
> machine for testing, the Windows 7 install is inherited from elsewhere.)

I run this in Win7.  What I see is the decoding does go via D3D11VA. The 
support comes 
with Platform Update. But AMF encoder works on Win7 via D3D9 only. That 
explains 
the performance hit: In D3D11 to copy video output HW accelerator copies frame 
via staging texture. 
If I use for decoding DXVA2 it is faster because staging texture is not needed.
I am thinking to connect dxva2 acceleration with AMF encoder 
but probably in the next phase.
I've added more precise logging.

> 
> >>> +{ "filler_data","Filler Data Enable",
> OFFSET(filler_data),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "vbaq",   "Enable VBAQ",
> >> OFFSET(enable_vbaq),
> >> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +{ "frame_skipping", "Rate Control Based Frame Skip",
> >> OFFSET(skip_frame), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
> >>> +
> >>> +/// QP Values
> >>> +{ "qp_i",   "Quantization Parameter for I-Frame",
> >> OFFSET(qp_i),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +{ "qp_p",   "Quantization Parameter for P-Frame",
>  OFFSET(qp_p),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +{ "qp_b",   "Quantization Parameter for B-Frame",
>  OFFSET(qp_b),
> >> AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 51, VE },
> >>> +
> >>> +/// Pre-Pass, Pre-Analysis, Two-Pass
> >>> +{ "preanalysis","Pre-Analysis Mode",
>  OFFSET(preanalysis),
> >> AV_OPT_TYPE_BOOL,{ .i64 = 0 }, 0, 1, VE, NULL },
> >>> +
> >>> +/// Maximum Access Unit Size
> >>> +{ "max_au_size","Maximum Access Unit Size for rate control
> (in
>  bits)",
> >> OFFSET(max_au_size), 

[FFmpeg-devel] [PATCH] Add DECLARE_ASM_ALIGNED macro for DJGPP architecture.

[Thomas Köppe]

The macro was added in 43171a2a738f5114768d34a7278e56e5fde714bc, but I forgot 
to add it to the DJGPP architecture in that change.
---
 libavutil/mem.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavutil/mem.h b/libavutil/mem.h
index 9e344bd2c3..7e0b12a8a7 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -106,6 +106,7 @@
 #define DECLARE_ASM_CONST(n,t,v)const t __attribute__ ((aligned (n))) v
 #elif defined(__DJGPP__)
 #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (FFMIN(n, 
16 v
+#define DECLARE_ASM_ALIGNED(n,t,v)  t av_used __attribute__ ((aligned 
(FFMIN(n, 16 v
 #define DECLARE_ASM_CONST(n,t,v)static const t av_used __attribute__ 
((aligned (FFMIN(n, 16 v
 #elif defined(__GNUC__) || defined(__clang__)
 #define DECLARE_ALIGNED(n,t,v)  t __attribute__ ((aligned (n))) v
-- 
2.15.0.448.gf294e3d99a-goog

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec/videotoolboxenc: add hevc_videotoolbox encoder

[Aman Gupta]

On Sun, Nov 12, 2017 at 10:22 AM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> ---
>  configure|   2 +
>  libavcodec/allcodecs.c   |   1 +
>  libavcodec/videotoolboxenc.c | 153 ++
> +
>  3 files changed, 143 insertions(+), 13 deletions(-)
>
> diff --git a/configure b/configure
> index 2cf18ecc12..39b9d4cb0c 100755
> --- a/configure
> +++ b/configure
> @@ -2928,6 +2928,8 @@ pcm_mulaw_at_encoder_select="audio_frame_queue"
>  chromaprint_muxer_deps="chromaprint"
>  h264_videotoolbox_encoder_deps="pthreads"
>  h264_videotoolbox_encoder_select="videotoolbox_encoder"
> +hevc_videotoolbox_encoder_deps="pthreads"
> +hevc_videotoolbox_encoder_select="videotoolbox_encoder"
>  libcelt_decoder_deps="libcelt"
>  libfdk_aac_decoder_deps="libfdk_aac"
>  libfdk_aac_encoder_deps="libfdk_aac"
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index c817003693..d8be53a52a 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -670,6 +670,7 @@ static void register_all(void)
>  REGISTER_ENCODER(HEVC_QSV,  hevc_qsv);
>  REGISTER_ENCODER(HEVC_V4L2M2M,  hevc_v4l2m2m);
>  REGISTER_ENCODER(HEVC_VAAPI,hevc_vaapi);
> +REGISTER_ENCODER(HEVC_VIDEOTOOLBOX, hevc_videotoolbox);
>  REGISTER_ENCODER(LIBKVAZAAR,libkvazaar);
>  REGISTER_DECODER(MJPEG_CUVID,   mjpeg_cuvid);
>  REGISTER_ENCODER(MJPEG_QSV, mjpeg_qsv);
> diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
> index eba6cc672f..5f6a382672 100644
> --- a/libavcodec/videotoolboxenc.c
> +++ b/libavcodec/videotoolboxenc.c
> @@ -35,6 +35,17 @@
>  #include "h264_sei.h"
>  #include 
>
> +#if !HAVE_KCMVIDEOCODECTYPE_HEVC
> +enum { kCMVideoCodecType_HEVC = 'hvc1' };
> +#endif
> +
> +typedef OSStatus (*getParameterSetAtIndex)(CMFormatDescriptionRef
> videoDesc,
> +   size_t parameterSetIndex,
> +   const uint8_t * _Nullable
> *parameterSetPointerOut,
> +   size_t *parameterSetSizeOut,
> +   size_t *parameterSetCountOut,
> +   int *NALUnitHeaderLengthOut);
> +
>  //These symbols may not be present
>  static struct{
>  CFStringRef kCVImageBufferColorPrimaries_ITU_R_2020;
> @@ -65,10 +76,15 @@ static struct{
>  CFStringRef kVTProfileLevel_H264_High_5_2;
>  CFStringRef kVTProfileLevel_H264_High_AutoLevel;
>
> +CFStringRef kVTProfileLevel_HEVC_Main_AutoLevel;
> +CFStringRef kVTProfileLevel_HEVC_Main10_AutoLevel;
> +
>  CFStringRef kVTCompressionPropertyKey_RealTime;
>
>  CFStringRef kVTVideoEncoderSpecification_
> EnableHardwareAcceleratedVideoEncoder;
>  CFStringRef kVTVideoEncoderSpecification_
> RequireHardwareAcceleratedVideoEncoder;
> +
> +getParameterSetAtIndex CMVideoFormatDescriptionGetHEV
> CParameterSetAtIndex;
>  } compat_keys;
>
>  #define GET_SYM(symbol, defaultVal) \
> @@ -83,6 +99,12 @@ do{
>  \
>  static pthread_once_t once_ctrl = PTHREAD_ONCE_INIT;
>
>  static void loadVTEncSymbols(){
> +compat_keys.CMVideoFormatDescriptionGetHEVCParameterSetAtIndex =
> +(getParameterSetAtIndex)dlsym(
> +RTLD_DEFAULT,
> +"CMVideoFormatDescriptionGetHEVCParameterSetAtIndex"
> +);
> +
>  GET_SYM(kCVImageBufferColorPrimaries_ITU_R_2020,   "ITU_R_2020");
>  GET_SYM(kCVImageBufferTransferFunction_ITU_R_2020, "ITU_R_2020");
>  GET_SYM(kCVImageBufferYCbCrMatrix_ITU_R_2020,  "ITU_R_2020");
> @@ -111,6 +133,9 @@ static void loadVTEncSymbols(){
>  GET_SYM(kVTProfileLevel_H264_High_5_2,   "H264_High_5_2");
>  GET_SYM(kVTProfileLevel_H264_High_AutoLevel,
>  "H264_High_AutoLevel");
>
> +GET_SYM(kVTProfileLevel_HEVC_Main_AutoLevel,
>  "HEVC_Main_AutoLevel");
> +GET_SYM(kVTProfileLevel_HEVC_Main10_AutoLevel,
>  "HEVC_Main10_AutoLevel");
> +
>  GET_SYM(kVTCompressionPropertyKey_RealTime, "RealTime");
>
>  GET_SYM(kVTVideoEncoderSpecification_EnableHardwareAcceleratedVideo
> Encoder,
> @@ -133,6 +158,13 @@ typedef enum VTH264Entropy{
>  VT_CABAC
>  } VTH264Entropy;
>
> +typedef enum VT_HEVCProfile {
> +HEVC_PROF_AUTO,
> +HEVC_PROF_MAIN,
> +HEVC_PROF_MAIN10,
> +HEVC_PROF_COUNT
> +} VT_HEVCProfile;
> +
>  static const uint8_t start_code[] = { 0, 0, 0, 1 };
>
>  typedef struct ExtraSEI {
> @@ -149,10 +181,12 @@ typedef struct BufNode {
>
>  typedef struct VTEncContext {
>  AVClass *class;
> +enum AVCodecID codec_id;
>  VTCompressionSessionRef session;
>  CFStringRef ycbcr_matrix;
>  CFStringRef color_primaries;
>  CFStringRef transfer_function;
> +getParameterSetAtIndex get_param_set_func;
>
>  pthread_mutex_t lock;
>  pthread_cond_t  cv_sample_sent;
> @@ -348,6 +382,7 @@ static CMVideoCodecType get_cm_codec

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/tcp: enable TCP_NODELAY by default

[Aman Gupta]

On Tue, Nov 14, 2017 at 9:40 AM, Aman Gupta  wrote:

> From: Aman Gupta 
>
> This can reduce latency and increase throughput, particularly on high
> latency networks.
>

Oops, I forgot to remove "enabled by default" from the commit message
subject. Fixed locally.


>
> Signed-off-by: Aman Gupta 
> Reviewed-by: Jeyapal, Karthick 
> ---
>  libavformat/network.h | 1 +
>  libavformat/tcp.c | 5 +
>  2 files changed, 6 insertions(+)
>
> diff --git a/libavformat/network.h b/libavformat/network.h
> index f83c796a95..b78e3ad6ed 100644
> --- a/libavformat/network.h
> +++ b/libavformat/network.h
> @@ -59,6 +59,7 @@ int ff_neterrno(void);
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>
>  #define ff_neterrno() AVERROR(errno)
> diff --git a/libavformat/tcp.c b/libavformat/tcp.c
> index 07b4ed9fa3..f3f9d4f431 100644
> --- a/libavformat/tcp.c
> +++ b/libavformat/tcp.c
> @@ -41,6 +41,7 @@ typedef struct TCPContext {
>  int listen_timeout;
>  int recv_buffer_size;
>  int send_buffer_size;
> +int tcp_nodelay;
>  } TCPContext;
>
>  #define OFFSET(x) offsetof(TCPContext, x)
> @@ -52,6 +53,7 @@ static const AVOption options[] = {
>  { "listen_timeout",  "Connection awaiting timeout (in
> milliseconds)",  OFFSET(listen_timeout), AV_OPT_TYPE_INT, { .i64 = -1
> }, -1, INT_MAX, .flags = D|E },
>  { "send_buffer_size", "Socket send buffer size (in bytes)",
>   OFFSET(send_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
>  { "recv_buffer_size", "Socket receive buffer size (in bytes)",
>  OFFSET(recv_buffer_size), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> INT_MAX, .flags = D|E },
> +{ "tcp_nodelay", "Use TCP_NODELAY to disable nagle's algorithm",
>  OFFSET(tcp_nodelay), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1,
> .flags = D|E },
>  { NULL }
>  };
>
> @@ -148,6 +150,9 @@ static int tcp_open(URLContext *h, const char *uri,
> int flags)
>  if (s->send_buffer_size > 0) {
>  setsockopt (fd, SOL_SOCKET, SO_SNDBUF, &s->send_buffer_size,
> sizeof (s->send_buffer_size));
>  }
> +if (s->tcp_nodelay > 0) {
> +setsockopt (fd, IPPROTO_TCP, TCP_NODELAY, &s->tcp_nodelay, sizeof
> (s->tcp_nodelay));
> +}
>
>  if (s->listen == 2) {
>  // multi-client
> --
> 2.14.2
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

On 11/14/2017 8:28 PM, Sasi Inguva wrote:
> For H264 files with no bitstream restriction flag, we aren't able to guess
> the delay correctly. Especially if it's MOV container, because for MOV
> container we just probe the 1st frame and stop in avformat_find_streaminfo .

You do not appear to be restricting this to one specific codec, or even codecs
with B-frames.

> When we are decoding , we increase the has_b_frames value from zero to 1 or
> 2, when we eventually encounter B-frames in H264 decoder, but that is too
> late and we have already dropped 1 or 2 frames. Lot of other fields in
> codecpar are being set from the demuxer like channel_layout, sample_rate
> etc.

I am aware of the intend, however...

The difference between filling those fields in and this patch, is that we can
read those values directly, generally. This is a guess; a heuristic. A heuristic
based on the GOP structure of a single codec. Where we guess where a GOP even
starts. Nor does it seem to take into account non-friendly files, with oddly
ordered and/or invalid timestamps (which it can't, based solely on PTS).

I'm pretty tired of hitting insane edge cases in other types of files due to
hacks added for some other specific set of file, but used for *everything*.
This is a recurring theme in FFmpeg, so I'm trying to fight hard to keep
more out...

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Hendrik Leppkes]

On Tue, Nov 14, 2017 at 9:28 PM, Sasi Inguva
 wrote:
> For H264 files with no bitstream restriction flag, we aren't able to guess
> the delay correctly. Especially if it's MOV container, because for MOV
> container we just probe the 1st frame and stop in avformat_find_streaminfo .
>
> When we are decoding , we increase the has_b_frames value from zero to 1 or
> 2, when we eventually encounter B-frames in H264 decoder, but that is too
> late and we have already dropped 1 or 2 frames. Lot of other fields in
> codecpar are being set from the demuxer like channel_layout, sample_rate
> etc.
>

It was not the usefulness that was questioned, but the implementation.
Maybe this should be more generic?

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Michael Niedermayer]

On Tue, Nov 14, 2017 at 09:39:33AM -0800, Sasi Inguva wrote:
> Sorry forgot to attach the fate samples. Pls find them attached.

uploaded

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Sasi Inguva]

For H264 files with no bitstream restriction flag, we aren't able to guess
the delay correctly. Especially if it's MOV container, because for MOV
container we just probe the 1st frame and stop in avformat_find_streaminfo .

When we are decoding , we increase the has_b_frames value from zero to 1 or
2, when we eventually encounter B-frames in H264 decoder, but that is too
late and we have already dropped 1 or 2 frames. Lot of other fields in
codecpar are being set from the demuxer like channel_layout, sample_rate
etc.

On Tue, Nov 14, 2017 at 10:06 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 11/14/2017 2:15 AM, Sasi Inguva wrote:
> > Signed-off-by: Sasi Inguva 
> > ---
> >  libavformat/mov.c| 48 ++
> ++
> >  tests/fate/mov.mak   |  5 +
> >  tests/ref/fate/mov-guess-delay-1 |  3 +++
> >  tests/ref/fate/mov-guess-delay-2 |  3 +++
> >  4 files changed, 59 insertions(+)
> >  create mode 100644 tests/ref/fate/mov-guess-delay-1
> >  create mode 100644 tests/ref/fate/mov-guess-delay-2
>
> Going to play the part of wm4 here.
>
> This seems like one giant hack to me (and potentially yet more slowness
> during init/index).
>
> Should we *really* be populating codecpar with a heuristic guess and
> should we *really* be putting this in one specific demuxer?
>
> Seems pretty gross to me.
>
> - Derek
> ___
> 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 2/2] avcodec: Implement vc1 nvdec hwaccel

[Timo Rothenpieler]

looks straight forward enough to me, struct naming matches up as well.

add a Changelog and bump lavc version, and it's good to go.



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/tcp: enable TCP_NODELAY by default

[Moritz Barsnick]

On Tue, Nov 14, 2017 at 09:40:58 -0800, Aman Gupta wrote:

> From: Aman Gupta 
> Subject: avformat/tcp: enable TCP_NODELAY by default

The commit message is no longer correct ->
avformat/tcp: allow setting TCP_NODELAY

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: Implement vc1 nvdec hwaccel

[Moritz Barsnick]

On Tue, Nov 14, 2017 at 07:24:14 -0800, Philip Langdale wrote:
> This hwaccel is interesting because it also works for wmv3/9 content,
> which is not supported by the nvidia parser used by cuviddec.

Nits:
Changelog entry? Version bump?

> +case AV_CODEC_ID_VC1:  return cudaVideoCodec_VC1;
>  case AV_CODEC_ID_VP9:  return cudaVideoCodec_VP9;
> +case AV_CODEC_ID_WMV3:  return cudaVideoCodec_VC1;

Alignment. ;-)

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Don't correct edit list start to zero, when we can't find a frame before edit list start. After c2a8f0fcbe57ea9ccaa864130f078af10516c3c1 this can happen on norma

[Michael Niedermayer]

On Mon, Nov 13, 2017 at 06:09:28PM -0800, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c|   4 +-
>  tests/fate/mov.mak   |   6 +
>  tests/ref/fate/mov-bbi-elst-starts-b | 391 
> +++
>  3 files changed, 398 insertions(+), 3 deletions(-)
>  create mode 100644 tests/ref/fate/mov-bbi-elst-starts-b

will apply
thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] aacenc: WIP support for PCEs

[pkv.stream]

Le 14/11/2017 à 1:20 AM, Carl Eugen Hoyos a écrit :

2017-11-09 9:01 GMT+01:00 pkv.stream :


1) there are changes to make to the list of channel layouts not requiring
PCE

==> AV_CH_LAYOUT_5POINT0 to AV_CH_LAYOUT_5POINT0_BACK since the previous is
5.0(side) while the latter is 5.0 which is what is in spec (table 1.19
ISO/IEC 14496-3:200X(E) or table 42 ISO/IEC 13818-7:2004(E) )

see patch in attachment (can't be applied directly due to rebasing issues
from your initial patch)

Did you test what effect this patch has on ffmpeg (the command line interface)
when encoding five- or six-channel aac from back and side source?
yes I did check, this patch reverts aac encoder to previous behaviour 
with 5.0 and 5.1 (when there was no PCE)



If something weird happens (like resampling), a Changelog entry may be a
good idea.




Thank you, 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] Avoid corrupting diagnostic state with _Pragma changes.

[Michael Niedermayer]

On Fri, Nov 03, 2017 at 05:13:58PM -0700, Dale Curtis wrote:
> The macros for ICC and MSVC correctly push and pop the diagnostic
> state of the compiler when disabling deprecation warnings. The
> ones for clang/gcc should do the same. Without this, if a blanket
> deprecation warning is applied to the code base it'll be flipped
> back on incorrectly with FF_ENABLE_DEPRECATION_WARNINGS.
> 
> Signed-off-by: Dale Curtis 

>  internal.h |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> ecc5e46d6354c52e1a6df9813d446e5f58a93321  fix_pragma.patch
> From 73a488e07a328d05aa2b507a551b0c1e4b8a81c8 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Fri, 3 Nov 2017 17:10:55 -0700
> Subject: [PATCH] Avoid corrupting diagnostic state with _Pragma changes.
> 
> The macros for ICC and MSVC correctly push and pop the diagnostic
> state of the compiler when disabling deprecation warnings. The
> ones for clang/gcc should do the same. Without this, if a blanket
> deprecation warning is applied to the code base it'll be flipped
> back on incorrectly with FF_ENABLE_DEPRECATION_WARNINGS.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavutil/internal.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] fate/mov: add test for overlapping fragments

[Michael Niedermayer]

On Mon, Nov 13, 2017 at 08:09:30AM -0800, John Stebbins wrote:
> ---
>  tests/fate/mov.mak  |   4 ++
>  tests/ref/fate/mov-frag-overlap | 105 
> 
>  2 files changed, 109 insertions(+)
>  create mode 100644 tests/ref/fate/mov-frag-overlap

will apply

thanks

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

What does censorship reveal? It reveals fear. -- Julian Assange


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

[FFmpeg-devel] [PATCH 09/15] lavfi: Add filter to run an arbitrary OpenCL program on frames

[Mark Thompson]

---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_program_opencl.c | 254 
 4 files changed, 257 insertions(+)
 create mode 100644 libavfilter/vf_program_opencl.c

diff --git a/configure b/configure
index cefe4205e5..9557e7e1ba 100755
--- a/configure
+++ b/configure
@@ -3233,6 +3233,7 @@ perspective_filter_deps="gpl"
 phase_filter_deps="gpl"
 pp7_filter_deps="gpl"
 pp_filter_deps="gpl postproc"
+program_opencl_filter_deps="opencl"
 pullup_filter_deps="gpl"
 removelogo_filter_deps="avcodec avformat swscale"
 repeatfields_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b7ddcd226d..6ebdc1f173 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -265,6 +265,7 @@ OBJS-$(CONFIG_PP_FILTER) += vf_pp.o
 OBJS-$(CONFIG_PP7_FILTER)+= vf_pp7.o
 OBJS-$(CONFIG_PREMULTIPLY_FILTER)+= vf_premultiply.o framesync.o
 OBJS-$(CONFIG_PREWITT_FILTER)+= vf_convolution.o
+OBJS-$(CONFIG_PROGRAM_OPENCL_FILTER) += vf_program_opencl.o opencl.o
 OBJS-$(CONFIG_PSEUDOCOLOR_FILTER)+= vf_pseudocolor.o
 OBJS-$(CONFIG_PSNR_FILTER)   += vf_psnr.o framesync.o
 OBJS-$(CONFIG_PULLUP_FILTER) += vf_pullup.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 3647a111ec..dfb92210a1 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -274,6 +274,7 @@ static void register_all(void)
 REGISTER_FILTER(PP7,pp7,vf);
 REGISTER_FILTER(PREMULTIPLY,premultiply,vf);
 REGISTER_FILTER(PREWITT,prewitt,vf);
+REGISTER_FILTER(PROGRAM_OPENCL, program_opencl, vf);
 REGISTER_FILTER(PSEUDOCOLOR,pseudocolor,vf);
 REGISTER_FILTER(PSNR,   psnr,   vf);
 REGISTER_FILTER(PULLUP, pullup, vf);
diff --git a/libavfilter/vf_program_opencl.c b/libavfilter/vf_program_opencl.c
new file mode 100644
index 00..ed99d827ae
--- /dev/null
+++ b/libavfilter/vf_program_opencl.c
@@ -0,0 +1,254 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/buffer.h"
+#include "libavutil/common.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_opencl.h"
+#include "libavutil/log.h"
+#include "libavutil/mem.h"
+#include "libavutil/pixdesc.h"
+#include "libavutil/opt.h"
+
+#include "avfilter.h"
+#include "internal.h"
+#include "opencl.h"
+#include "video.h"
+
+typedef struct ProgramOpenCLContext {
+OpenCLFilterContext ocf;
+
+int  initialised;
+cl_uint  index;
+cl_kernelkernel;
+cl_command_queue command_queue;
+
+const char  *source_file;
+const char  *kernel_name;
+} ProgramOpenCLContext;
+
+static int program_opencl_init(AVFilterContext *avctx)
+{
+ProgramOpenCLContext *ctx = avctx->priv;
+cl_int cle;
+int err;
+
+err = ff_opencl_filter_load_program_from_file(avctx, ctx->source_file);
+if (err < 0)
+goto fail;
+
+ctx->command_queue = clCreateCommandQueue(ctx->ocf.hwctx->context,
+  ctx->ocf.hwctx->device_id,
+  0, &cle);
+if (!ctx->command_queue) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create OpenCL "
+   "command queue: %d.\n", cle);
+err = AVERROR(EIO);
+goto fail;
+}
+
+ctx->kernel = clCreateKernel(ctx->ocf.program, ctx->kernel_name, &cle);
+if (!ctx->kernel) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create kernel: %d.\n", cle);
+err = AVERROR(EIO);
+goto fail;
+}
+
+ctx->initialised = 1;
+return 0;
+
+fail:
+if (ctx->command_queue)
+clReleaseCommandQueue(ctx->command_queue);
+if (ctx->kernel)
+clReleaseKernel(ctx->kernel);
+return err;
+}
+
+static int program_opencl_filter_frame(AVFilterLink *inlink, AVFrame *input)
+{
+AVFilterContext*avctx = inlink->dst;
+AVFilterLink *outlink = avctx->outputs[0];
+ProgramOpenCLContext *ctx = avctx->priv;
+AVFrame *output = NULL;
+cl_int 

[FFmpeg-devel] [PATCH 14/15] hwcontext: Perform usual uninitialisation on derived frames contexts

[Mark Thompson]

---
 libavutil/hwcontext.c | 17 +++--
 1 file changed, 7 insertions(+), 10 deletions(-)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index b26e68fe77..f47158f811 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -217,19 +217,16 @@ static void hwframe_ctx_free(void *opaque, uint8_t *data)
 {
 AVHWFramesContext *ctx = (AVHWFramesContext*)data;
 
-if (ctx->internal->source_frames) {
-av_buffer_unref(&ctx->internal->source_frames);
+if (ctx->internal->pool_internal)
+av_buffer_pool_uninit(&ctx->internal->pool_internal);
 
-} else {
-if (ctx->internal->pool_internal)
-av_buffer_pool_uninit(&ctx->internal->pool_internal);
+if (ctx->internal->hw_type->frames_uninit)
+ctx->internal->hw_type->frames_uninit(ctx);
 
-if (ctx->internal->hw_type->frames_uninit)
-ctx->internal->hw_type->frames_uninit(ctx);
+if (ctx->free)
+ctx->free(ctx);
 
-if (ctx->free)
-ctx->free(ctx);
-}
+av_buffer_unref(&ctx->internal->source_frames);
 
 av_buffer_unref(&ctx->device_ref);
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 13/15] vf_hwmap: Pass mapping mode when deriving frames context on an existing device

[Mark Thompson]

To match creation on a newly-derived device.  (This was missed earlier
because the mode is only used in some cases.)
---
 libavfilter/vf_hwmap.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_hwmap.c b/libavfilter/vf_hwmap.c
index 8277241dc4..d5fc3c46e6 100644
--- a/libavfilter/vf_hwmap.c
+++ b/libavfilter/vf_hwmap.c
@@ -114,7 +114,8 @@ static int hwmap_config_output(AVFilterLink *outlink)
 err = av_hwframe_ctx_create_derived(&ctx->hwframes_ref,
 outlink->format,
 device,
-inlink->hw_frames_ctx, 0);
+inlink->hw_frames_ctx,
+ctx->mode);
 if (err < 0) {
 av_log(avctx, AV_LOG_ERROR, "Failed to create derived "
"frames context: %d.\n", err);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 08/15] lavfi: Add some common code for OpenCL filtering

[Mark Thompson]

---
 libavfilter/opencl.c | 251 +++
 libavfilter/opencl.h |  87 ++
 2 files changed, 338 insertions(+)
 create mode 100644 libavfilter/opencl.c
 create mode 100644 libavfilter/opencl.h

diff --git a/libavfilter/opencl.c b/libavfilter/opencl.c
new file mode 100644
index 00..005ad089e2
--- /dev/null
+++ b/libavfilter/opencl.c
@@ -0,0 +1,251 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_opencl.h"
+#include "libavutil/mem.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "opencl.h"
+
+int ff_opencl_filter_query_formats(AVFilterContext *avctx)
+{
+const static enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_OPENCL,
+AV_PIX_FMT_NONE,
+};
+AVFilterFormats *formats;
+
+formats = ff_make_format_list(pix_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+
+return ff_set_common_formats(avctx, formats);
+}
+
+int ff_opencl_filter_config_input(AVFilterLink *inlink)
+{
+AVFilterContext   *avctx = inlink->dst;
+OpenCLFilterContext *ctx = avctx->priv;
+AVHWFramesContext *input_frames;
+
+if (!inlink->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "OpenCL filtering requires a "
+   "hardware frames context on the input.\n");
+return AVERROR(EINVAL);
+}
+
+// Extract the device and default output format from the first input.
+if (avctx->inputs[0] != inlink)
+return 0;
+
+input_frames = (AVHWFramesContext*)inlink->hw_frames_ctx->data;
+
+if (input_frames->format != AV_PIX_FMT_OPENCL)
+return AVERROR(EINVAL);
+
+ctx->device_ref = av_buffer_ref(input_frames->device_ref);
+if (!ctx->device_ref)
+return AVERROR(ENOMEM);
+ctx->device = input_frames->device_ctx;
+ctx->hwctx  = ctx->device->hwctx;
+
+// Default output parameters match input parameters.
+if (ctx->output_format == AV_PIX_FMT_NONE)
+ctx->output_format = input_frames->sw_format;
+if (!ctx->output_width)
+ctx->output_width  = inlink->w;
+if (!ctx->output_height)
+ctx->output_height = inlink->h;
+
+return 0;
+}
+
+int ff_opencl_filter_config_output(AVFilterLink *outlink)
+{
+AVFilterContext   *avctx = outlink->src;
+OpenCLFilterContext *ctx = avctx->priv;
+AVBufferRef   *output_frames_ref = NULL;
+AVHWFramesContext *output_frames;
+int err;
+
+av_buffer_unref(&outlink->hw_frames_ctx);
+
+output_frames_ref = av_hwframe_ctx_alloc(ctx->device_ref);
+if (!output_frames_ref) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+output_frames = (AVHWFramesContext*)output_frames_ref->data;
+
+output_frames->format= AV_PIX_FMT_OPENCL;
+output_frames->sw_format = ctx->output_format;
+output_frames->width = ctx->output_width;
+output_frames->height= ctx->output_height;
+
+err = av_hwframe_ctx_init(output_frames_ref);
+if (err < 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed to initialise output "
+   "frames: %d.\n", err);
+goto fail;
+}
+
+outlink->hw_frames_ctx = output_frames_ref;
+outlink->w = ctx->output_width;
+outlink->h = ctx->output_height;
+
+return 0;
+fail:
+av_buffer_unref(&output_frames_ref);
+return err;
+}
+
+int ff_opencl_filter_init(AVFilterContext *avctx)
+{
+OpenCLFilterContext *ctx = avctx->priv;
+
+ctx->output_format = AV_PIX_FMT_NONE;
+
+return 0;
+}
+
+void ff_opencl_filter_uninit(AVFilterContext *avctx)
+{
+OpenCLFilterContext *ctx = avctx->priv;
+cl_int cle;
+
+if (ctx->program) {
+cle = clReleaseProgram(ctx->program);
+if (cle != CL_SUCCESS)
+av_log(avctx, AV_LOG_ERROR, "Failed to release "
+   "program: %d.\n", cle);
+}
+
+av_buffer_unref(&ctx->device_ref);
+}
+
+int ff_opencl_filter_load_program(AVFilterContext *avctx,
+  const char **program_source_array,
+  int nb_strings)
+{
+OpenCLFilterContext *ctx = avctx->priv;
+cl_int cle;
+
+ctx->program = clCreateProgramWithSource(ctx->hwctx->contex

[FFmpeg-devel] [PATCH 12/15] lavfi: Add OpenCL unsharp mask filter

[Mark Thompson]

Intended to replace existing opencl mode of the unsharp filter.
Supports many more pixel formats and works without immediate upload
and download of frame data.  The options are compatible with the
existing filter.
---
The most obvious missing optimisation is to split the kernels into multiple 
versions for different pixel formats (float4 everywhere is quite wasteful), but 
that would make the code a lot bigger.


 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/unsharp.cl   |  99 +
 libavfilter/opencl_source.h |   1 +
 libavfilter/vf_unsharp_opencl.c | 482 
 6 files changed, 586 insertions(+)
 create mode 100644 libavfilter/opencl/unsharp.cl
 create mode 100644 libavfilter/vf_unsharp_opencl.c

diff --git a/configure b/configure
index d718cf9f4c..a38b2cc4dd 100755
--- a/configure
+++ b/configure
@@ -3270,6 +3270,7 @@ tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
+unsharp_opencl_filter_deps="opencl"
 uspp_filter_deps="gpl avcodec"
 unsharp_filter_suggest="opencl"
 vaguedenoiser_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 8f1c5ad22c..a17bcdd749 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -330,6 +330,8 @@ OBJS-$(CONFIG_TRANSPOSE_FILTER)  += 
vf_transpose.o
 OBJS-$(CONFIG_TRIM_FILTER)   += trim.o
 OBJS-$(CONFIG_UNPREMULTIPLY_FILTER)  += vf_premultiply.o framesync.o
 OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
+OBJS-$(CONFIG_UNSHARP_OPENCL_FILTER) += vf_unsharp_opencl.o opencl.o \
+opencl/unsharp.o
 OBJS-$(CONFIG_USPP_FILTER)   += vf_uspp.o
 OBJS-$(CONFIG_VAGUEDENOISER_FILTER)  += vf_vaguedenoiser.o
 OBJS-$(CONFIG_VECTORSCOPE_FILTER)+= vf_vectorscope.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 156ec019dd..1ae1681a45 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -338,6 +338,7 @@ static void register_all(void)
 REGISTER_FILTER(TRIM,   trim,   vf);
 REGISTER_FILTER(UNPREMULTIPLY,  unpremultiply,  vf);
 REGISTER_FILTER(UNSHARP,unsharp,vf);
+REGISTER_FILTER(UNSHARP_OPENCL, unsharp_opencl, vf);
 REGISTER_FILTER(USPP,   uspp,   vf);
 REGISTER_FILTER(VAGUEDENOISER,  vaguedenoiser,  vf);
 REGISTER_FILTER(VECTORSCOPE,vectorscope,vf);
diff --git a/libavfilter/opencl/unsharp.cl b/libavfilter/opencl/unsharp.cl
new file mode 100644
index 00..e629834e50
--- /dev/null
+++ b/libavfilter/opencl/unsharp.cl
@@ -0,0 +1,99 @@
+/*
+ * 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
+ */
+
+__kernel void unsharp_global(__write_only image2d_t dst,
+ __read_only  image2d_t src,
+ int size_x,
+ int size_y,
+ float amount,
+ __constant float *coef_matrix)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+int2 loc= (int2)(get_global_id(0), get_global_id(1));
+int2 centre = (int2)(size_x / 2, size_y / 2);
+
+float4 val = read_imagef(src, sampler, loc);
+float4 sum = 0.0f;
+int x, y;
+
+for (y = 0; y < size_y; y++) {
+for (x = 0; x < size_x; x++) {
+int2 pos = loc + (int2)(x, y) - centre;
+sum += coef_matrix[y * size_x + x] *
+read_imagef(src, sampler, pos);
+}
+}
+
+write_imagef(dst, loc, val + (val - sum) * amount);
+}
+
+__kernel void unsharp_local(__write_only image2d_t dst,
+__read_only  image2d_t src,
+int size_x,
+int size_y,
+float amount,
+__constant float *coef_x,
+__constant float *coef_y)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   

[FFmpeg-devel] [PATCH 11/15] lavfi: Add OpenCL overlay filter

[Mark Thompson]

Input and output formats must be the same, the overlay format must be
the same as the input except possibly with an additional alpha component.
---
 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/overlay.cl   | 104 
 libavfilter/opencl_source.h |   2 +
 libavfilter/vf_overlay_opencl.c | 360 
 6 files changed, 470 insertions(+)
 create mode 100644 libavfilter/opencl/overlay.cl
 create mode 100644 libavfilter/vf_overlay_opencl.c

diff --git a/configure b/configure
index 9557e7e1ba..d718cf9f4c 100755
--- a/configure
+++ b/configure
@@ -3225,6 +3225,7 @@ negate_filter_deps="lut_filter"
 nnedi_filter_deps="gpl"
 ocr_filter_deps="libtesseract"
 ocv_filter_deps="libopencv"
+overlay_opencl_filter_deps="opencl"
 overlay_qsv_filter_deps="libmfx"
 overlay_qsv_filter_select="qsvvpp"
 owdenoise_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 4150efe5ca..8f1c5ad22c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -251,6 +251,8 @@ OBJS-$(CONFIG_OCV_FILTER)+= 
vf_libopencv.o
 OBJS-$(CONFIG_OPENCL)+= deshake_opencl.o 
unsharp_opencl.o
 OBJS-$(CONFIG_OSCILLOSCOPE_FILTER)   += vf_datascope.o
 OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o framesync.o
+OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o opencl.o \
+opencl/overlay.o framesync.o
 OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o
 OBJS-$(CONFIG_OWDENOISE_FILTER)  += vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index dfb92210a1..156ec019dd 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -260,6 +260,7 @@ static void register_all(void)
 REGISTER_FILTER(OCV,ocv,vf);
 REGISTER_FILTER(OSCILLOSCOPE,   oscilloscope,   vf);
 REGISTER_FILTER(OVERLAY,overlay,vf);
+REGISTER_FILTER(OVERLAY_OPENCL, overlay_opencl, vf);
 REGISTER_FILTER(OVERLAY_QSV,overlay_qsv,vf);
 REGISTER_FILTER(OWDENOISE,  owdenoise,  vf);
 REGISTER_FILTER(PAD,pad,vf);
diff --git a/libavfilter/opencl/overlay.cl b/libavfilter/opencl/overlay.cl
new file mode 100644
index 00..8c783d0edc
--- /dev/null
+++ b/libavfilter/opencl/overlay.cl
@@ -0,0 +1,104 @@
+/*
+ * 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
+ */
+
+__kernel void overlay_no_alpha(__write_only image2d_t dst,
+   __read_only  image2d_t main,
+   __read_only  image2d_t overlay,
+   int x_position,
+   int y_position)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+
+int2 overlay_size = get_image_dim(overlay);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+
+if (loc.x <  x_position ||
+loc.y <  y_position ||
+loc.x >= overlay_size.x + x_position ||
+loc.y >= overlay_size.y + y_position) {
+float4 val = read_imagef(main, sampler, loc);
+write_imagef(dst, loc, val);
+} else {
+int2 loc_overlay = (int2)(x_position, y_position);
+float4 val   = read_imagef(overlay, sampler, loc - loc_overlay);
+write_imagef(dst, loc, val);
+}
+}
+
+__kernel void overlay_internal_alpha(__write_only image2d_t dst,
+ __read_only  image2d_t main,
+ __read_only  image2d_t overlay,
+ int x_position,
+ int y_position)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+
+int2 overlay_size = get_image_dim(overlay);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+
+if (loc.x <  x_position ||
+loc.y <  y_position ||
+loc.x >= overlay_size.x + x_position ||
+loc.y >= o

[FFmpeg-devel] [PATCH 07/15] hwcontext_opencl: DRM to OpenCL mapping for ARM

[Mark Thompson]

Using cl_arm_import_memory.  Unfortunately, despite this not being a
standard extension, the function clImportMemoryARM() is not accessible
via clGetExtensionFunctionAddressForPlatform().  This means that it has
to be linked directly to the ARM OpenCL binary, so making a portable
binary is not possible as it is with all other mapping extensions.
---
 configure|   6 +
 libavutil/hwcontext_opencl.c | 263 +++
 2 files changed, 269 insertions(+)

diff --git a/configure b/configure
index c75867c73f..cefe4205e5 100755
--- a/configure
+++ b/configure
@@ -2122,6 +2122,7 @@ HAVE_LIST="
 makeinfo
 makeinfo_html
 opencl_d3d11
+opencl_drm_arm
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
@@ -6173,6 +6174,11 @@ if enabled_all opencl d3d11va ; then
 enable opencl_d3d11
 fi
 
+if enabled_all opencl libdrm ; then
+check_func_headers "CL/cl_ext.h" clImportMemoryARM &&
+enable opencl_drm_arm
+fi
+
 enabled vdpau &&
 check_cpp_condition vdpau/vdpau.h "defined 
VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
 disable vdpau
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 08b3ea90f7..8754d73939 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -56,6 +56,12 @@
 #include "hwcontext_d3d11va.h"
 #endif
 
+#if HAVE_OPENCL_DRM_ARM
+#include 
+#include 
+#include "hwcontext_drm.h"
+#endif
+
 
 typedef struct OpenCLDeviceContext {
 // Default command queue to use for transfer/mapping operations on
@@ -104,6 +110,10 @@ typedef struct OpenCLDeviceContext {
 clEnqueueReleaseD3D11ObjectsKHR_fn
 clEnqueueReleaseD3D11ObjectsKHR;
 #endif
+
+#if HAVE_OPENCL_DRM_ARM
+int drm_arm_mapping_usable;
+#endif
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
@@ -826,6 +836,37 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 }
 #endif
 
+#if HAVE_OPENCL_DRM_ARM
+{
+const char *drm_arm_ext = "cl_arm_import_memory";
+const char *image_ext   = "cl_khr_image2d_from_buffer";
+int fail = 0;
+
+if (!opencl_check_extension(hwdev, drm_arm_ext)) {
+av_log(hwdev, AV_LOG_VERBOSE, "The %s extension is "
+   "required for DRM to OpenCL mapping on ARM.\n",
+   drm_arm_ext);
+fail = 1;
+}
+if (!opencl_check_extension(hwdev, image_ext)) {
+av_log(hwdev, AV_LOG_VERBOSE, "The %s extension is "
+   "required for DRM to OpenCL mapping on ARM.\n",
+   image_ext);
+fail = 1;
+}
+
+// clImportMemoryARM() is linked statically.
+
+if (fail) {
+av_log(hwdev, AV_LOG_WARNING, "DRM to OpenCL mapping on ARM "
+   "not usable.\n");
+priv->drm_arm_mapping_usable = 0;
+} else {
+priv->drm_arm_mapping_usable = 1;
+}
+}
+#endif
+
 #undef CL_FUNC
 
 return 0;
@@ -1104,6 +1145,40 @@ static int opencl_filter_gpu_device(AVHWDeviceContext 
*hwdev,
 }
 #endif
 
+#if HAVE_OPENCL_DRM_ARM
+static int opencl_filter_drm_arm_platform(AVHWDeviceContext *hwdev,
+  cl_platform_id platform_id,
+  const char *platform_name,
+  void *context)
+{
+const char *drm_arm_ext = "cl_arm_import_memory";
+
+if (opencl_check_platform_extension(platform_id, drm_arm_ext)) {
+return 0;
+} else {
+av_log(hwdev, AV_LOG_DEBUG, "Platform %s does not support the "
+   "%s extension.\n", platform_name, drm_arm_ext);
+return 1;
+}
+}
+
+static int opencl_filter_drm_arm_device(AVHWDeviceContext *hwdev,
+cl_device_id device_id,
+const char *device_name,
+void *context)
+{
+const char *drm_arm_ext = "cl_arm_import_memory";
+
+if (opencl_check_device_extension(device_id, drm_arm_ext)) {
+return 0;
+} else {
+av_log(hwdev, AV_LOG_DEBUG, "Device %s does not support the "
+   "%s extension.\n", device_name, drm_arm_ext);
+return 1;
+}
+}
+#endif
+
 static int opencl_device_derive(AVHWDeviceContext *hwdev,
 AVHWDeviceContext *src_ctx,
 int flags)
@@ -1250,6 +1325,24 @@ static int opencl_device_derive(AVHWDeviceContext *hwdev,
 break;
 #endif
 
+#if HAVE_OPENCL_DRM_ARM
+case AV_HWDEVICE_TYPE_DRM:
+{
+OpenCLDeviceSelector selector = {
+.platform_index  = -1,
+.device_index= -1,
+.context = NULL,
+.enumerate_platforms = &opencl_enumerate_platforms,
+.filter_platform = &opencl_filter_drm_arm_platform,
+

[FFmpeg-devel] [PATCH 06/15] hwcontext_opencl: D3D11 to OpenCL mapping

[Mark Thompson]

Using cl_khr_d3d11_sharing and cl_intel_d3d11_nv12_media_sharing.
---
 configure|   6 +
 libavutil/hwcontext_opencl.c | 321 ++-
 2 files changed, 325 insertions(+), 2 deletions(-)

diff --git a/configure b/configure
index dee44eff85..c75867c73f 100755
--- a/configure
+++ b/configure
@@ -2121,6 +2121,7 @@ HAVE_LIST="
 $TYPES_LIST
 makeinfo
 makeinfo_html
+opencl_d3d11
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
@@ -6167,6 +6168,11 @@ if enabled_all opencl dxva2 ; then
 enable opencl_dxva2
 fi
 
+if enabled_all opencl d3d11va ; then
+check_type "CL/cl_d3d11.h" clGetDeviceIDsFromD3D11KHR_fn &&
+enable opencl_d3d11
+fi
+
 enabled vdpau &&
 check_cpp_condition vdpau/vdpau.h "defined 
VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
 disable vdpau
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index cbee32b94c..08b3ea90f7 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -51,6 +51,11 @@
 #include "hwcontext_dxva2.h"
 #endif
 
+#if HAVE_OPENCL_D3D11
+#include 
+#include "hwcontext_d3d11va.h"
+#endif
+
 
 typedef struct OpenCLDeviceContext {
 // Default command queue to use for transfer/mapping operations on
@@ -89,6 +94,16 @@ typedef struct OpenCLDeviceContext {
 clEnqueueReleaseDX9MediaSurfacesKHR_fn
 clEnqueueReleaseDX9MediaSurfacesKHR;
 #endif
+
+#if HAVE_OPENCL_D3D11
+int d3d11_mapping_usable;
+clCreateFromD3D11Texture2DKHR_fn
+clCreateFromD3D11Texture2DKHR;
+clEnqueueAcquireD3D11ObjectsKHR_fn
+clEnqueueAcquireD3D11ObjectsKHR;
+clEnqueueReleaseD3D11ObjectsKHR_fn
+clEnqueueReleaseD3D11ObjectsKHR;
+#endif
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
@@ -98,7 +113,7 @@ typedef struct OpenCLFramesContext {
 // device.
 cl_command_queue command_queue;
 
-#if HAVE_OPENCL_DXVA2
+#if HAVE_OPENCL_DXVA2 || HAVE_OPENCL_D3D11
 // For mapping APIs which have separate creation and acquire/release
 // steps, this stores the OpenCL memory objects corresponding to each
 // frame.
@@ -778,6 +793,39 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 }
 #endif
 
+#if HAVE_OPENCL_D3D11
+{
+const char *d3d11_ext = "cl_khr_d3d11_sharing";
+const char *nv12_ext  = "cl_intel_d3d11_nv12_media_sharing";
+int fail = 0;
+
+if (!opencl_check_extension(hwdev, d3d11_ext)) {
+av_log(hwdev, AV_LOG_VERBOSE, "The %s extension is "
+   "required for D3D11 to OpenCL mapping.\n", d3d11_ext);
+fail = 1;
+} else if (!opencl_check_extension(hwdev, nv12_ext)) {
+av_log(hwdev, AV_LOG_VERBOSE, "The %s extension may be "
+   "required for D3D11 to OpenCL mapping.\n", nv12_ext);
+// Not fatal.
+}
+
+CL_FUNC(clCreateFromD3D11Texture2DKHR,
+"D3D11 to OpenCL mapping");
+CL_FUNC(clEnqueueAcquireD3D11ObjectsKHR,
+"D3D11 in OpenCL acquire");
+CL_FUNC(clEnqueueReleaseD3D11ObjectsKHR,
+"D3D11 in OpenCL release");
+
+if (fail) {
+av_log(hwdev, AV_LOG_WARNING, "D3D11 to OpenCL mapping "
+   "not usable.\n");
+priv->d3d11_mapping_usable = 0;
+} else {
+priv->d3d11_mapping_usable = 1;
+}
+}
+#endif
+
 #undef CL_FUNC
 
 return 0;
@@ -957,7 +1005,80 @@ static int 
opencl_enumerate_dxva2_devices(AVHWDeviceContext *hwdev,
 
 return 0;
 }
+#endif
+
+#if HAVE_OPENCL_D3D11
+static int opencl_filter_d3d11_platform(AVHWDeviceContext *hwdev,
+cl_platform_id platform_id,
+const char *platform_name,
+void *context)
+{
+const char *d3d11_ext = "cl_khr_d3d11_sharing";
+
+if (opencl_check_platform_extension(platform_id, d3d11_ext)) {
+return 0;
+} else {
+av_log(hwdev, AV_LOG_DEBUG, "Platform %s does not support the "
+   "%s extension.\n", platform_name, d3d11_ext);
+return 1;
+}
+}
+
+static int opencl_enumerate_d3d11_devices(AVHWDeviceContext *hwdev,
+  cl_platform_id platform_id,
+  const char *platform_name,
+  cl_uint *nb_devices,
+  cl_device_id **devices,
+  void *context)
+{
+ID3D11Device *device = context;
+clGetDeviceIDsFromD3D11KHR_fn clGetDeviceIDsFromD3D11KHR;
+cl_int cle;
+
+clGetDeviceIDsFromD3D11KHR =
+clGetExtensionFunctionAddressForPlatform(platform_id,
+"clGetDeviceIDsFromD3D11KHR");
+if (!clGetDeviceIDsFromD3D11KHR) {
+av_log(hwdev, AV_LOG_ERROR, "Failed to get address of "
+

[FFmpeg-devel] [PATCH 10/15] lavfi: Add infrastructure for building OpenCL source into libavfilter

[Mark Thompson]

---
 libavfilter/Makefile|  6 ++
 libavfilter/opencl_source.h | 22 ++
 tools/cl2c  | 20 
 3 files changed, 48 insertions(+)
 create mode 100644 libavfilter/opencl_source.h
 create mode 100755 tools/cl2c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6ebdc1f173..4150efe5ca 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -404,3 +404,9 @@ TOOLS-$(CONFIG_LIBZMQ) += zmqsend
 
 clean::
$(RM) $(CLEANSUFFIXES:%=libavfilter/libmpcodecs/%)
+
+OPENCL = $(subst $(SRC_PATH)/,,$(wildcard $(SRC_PATH)/libavfilter/opencl/*.cl))
+.SECONDARY: $(OPENCL:.cl=.c)
+libavfilter/opencl/%.c: TAG = OPENCL
+libavfilter/opencl/%.c: $(SRC_PATH)/libavfilter/opencl/%.cl
+   $(M)$(SRC_PATH)/tools/cl2c $< $@
diff --git a/libavfilter/opencl_source.h b/libavfilter/opencl_source.h
new file mode 100644
index 00..8674a03a94
--- /dev/null
+++ b/libavfilter/opencl_source.h
@@ -0,0 +1,22 @@
+/*
+ * 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 AVFILTER_OPENCL_SOURCE_H
+#define AVFILTER_OPENCL_SOURCE_H
+
+#endif /* AVFILTER_OPENCL_SOURCE_H */
diff --git a/tools/cl2c b/tools/cl2c
new file mode 100755
index 00..1ead940811
--- /dev/null
+++ b/tools/cl2c
@@ -0,0 +1,20 @@
+#!/bin/sh
+# Convert an OpenCL source file into a C source file containing the
+# OpenCL source as a C string.  Also adds a #line directive so that
+# compiler messages are useful.
+
+input="$1"
+output="$2"
+
+name=$(basename "$input" | sed 's/.cl$//')
+
+cat >$output <>$output
+
+echo ";" >>$output
-- 
2.11.0

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

[FFmpeg-devel] [PATCH 05/15] hwcontext_opencl: DXVA2 to OpenCL mapping

[Mark Thompson]

Using cl_khr_dx9_media_sharing.
---
 configure|   6 +
 libavutil/hwcontext_opencl.c | 397 +++
 2 files changed, 403 insertions(+)

diff --git a/configure b/configure
index 7649fe8de1..dee44eff85 100755
--- a/configure
+++ b/configure
@@ -2121,6 +2121,7 @@ HAVE_LIST="
 $TYPES_LIST
 makeinfo
 makeinfo_html
+opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
 perl
@@ -6161,6 +6162,11 @@ if enabled_all opencl vaapi ; then
 fi
 fi
 
+if enabled_all opencl dxva2 ; then
+check_type "CL/cl_dx9_media_sharing.h" cl_dx9_surface_info_khr &&
+enable opencl_dxva2
+fi
+
 enabled vdpau &&
 check_cpp_condition vdpau/vdpau.h "defined 
VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
 disable vdpau
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index ee6ebd18d1..cbee32b94c 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -44,6 +44,13 @@
 #include "hwcontext_vaapi.h"
 #endif
 
+#if HAVE_OPENCL_DXVA2
+#define COBJMACROS
+#include 
+#include 
+#include "hwcontext_dxva2.h"
+#endif
+
 
 typedef struct OpenCLDeviceContext {
 // Default command queue to use for transfer/mapping operations on
@@ -70,6 +77,18 @@ typedef struct OpenCLDeviceContext {
 clEnqueueReleaseVA_APIMediaSurfacesINTEL_fn
 clEnqueueReleaseVA_APIMediaSurfacesINTEL;
 #endif
+
+#if HAVE_OPENCL_DXVA2
+int dxva2_mapping_usable;
+cl_dx9_media_adapter_type_khr dx9_media_adapter_type;
+
+clCreateFromDX9MediaSurfaceKHR_fn
+clCreateFromDX9MediaSurfaceKHR;
+clEnqueueAcquireDX9MediaSurfacesKHR_fn
+clEnqueueAcquireDX9MediaSurfacesKHR;
+clEnqueueReleaseDX9MediaSurfacesKHR_fn
+clEnqueueReleaseDX9MediaSurfacesKHR;
+#endif
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
@@ -78,6 +97,14 @@ typedef struct OpenCLFramesContext {
 // Otherwise, it is a reference to the default command queue for the
 // device.
 cl_command_queue command_queue;
+
+#if HAVE_OPENCL_DXVA2
+// For mapping APIs which have separate creation and acquire/release
+// steps, this stores the OpenCL memory objects corresponding to each
+// frame.
+int   nb_mapped_frames;
+AVOpenCLFrameDescriptor *mapped_frames;
+#endif
 } OpenCLFramesContext;
 
 
@@ -729,6 +756,28 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 }
 #endif
 
+#if HAVE_OPENCL_DXVA2
+{
+int fail = 0;
+
+CL_FUNC(clCreateFromDX9MediaSurfaceKHR,
+"DXVA2 to OpenCL mapping");
+CL_FUNC(clEnqueueAcquireDX9MediaSurfacesKHR,
+"DXVA2 in OpenCL acquire");
+CL_FUNC(clEnqueueReleaseDX9MediaSurfacesKHR,
+"DXVA2 in OpenCL release");
+
+if (fail) {
+av_log(hwdev, AV_LOG_WARNING, "DXVA2 to OpenCL mapping "
+   "not usable.\n");
+priv->dxva2_mapping_usable = 0;
+} else {
+priv->dx9_media_adapter_type = CL_ADAPTER_D3D9EX_KHR;
+priv->dxva2_mapping_usable = 1;
+}
+}
+#endif
+
 #undef CL_FUNC
 
 return 0;
@@ -837,6 +886,103 @@ static int 
opencl_filter_intel_media_vaapi_device(AVHWDeviceContext *hwdev,
 }
 #endif
 
+#if HAVE_OPENCL_DXVA2
+static int opencl_filter_dxva2_platform(AVHWDeviceContext *hwdev,
+cl_platform_id platform_id,
+const char *platform_name,
+void *context)
+{
+const char *dx9_ext = "cl_khr_dx9_media_sharing";
+
+if (opencl_check_platform_extension(platform_id, dx9_ext)) {
+return 0;
+} else {
+av_log(hwdev, AV_LOG_DEBUG, "Platform %s does not support the "
+   "%s extension.\n", platform_name, dx9_ext);
+return 1;
+}
+}
+
+static int opencl_enumerate_dxva2_devices(AVHWDeviceContext *hwdev,
+  cl_platform_id platform_id,
+  const char *platform_name,
+  cl_uint *nb_devices,
+  cl_device_id **devices,
+  void *context)
+{
+IDirect3DDevice9 *device = context;
+clGetDeviceIDsFromDX9MediaAdapterKHR_fn
+clGetDeviceIDsFromDX9MediaAdapterKHR;
+cl_dx9_media_adapter_type_khr media_adapter_type = CL_ADAPTER_D3D9EX_KHR;
+cl_int cle;
+
+clGetDeviceIDsFromDX9MediaAdapterKHR =
+clGetExtensionFunctionAddressForPlatform(platform_id,
+"clGetDeviceIDsFromDX9MediaAdapterKHR");
+if (!clGetDeviceIDsFromDX9MediaAdapterKHR) {
+av_log(hwdev, AV_LOG_ERROR, "Failed to get address of "
+   "clGetDeviceIDsFromDX9MediaAdapterKHR().\n");
+return AVERROR_UNKNOWN;
+}
+
+cle = clGetDeviceIDsFromDX9MediaAdapterKHR(
+platform_id, 1, &media_adapter_typ

[FFmpeg-devel] [PATCH 03/15] hwcontext_opencl: VAAPI to OpenCL mapping for Intel i965+beignet

[Mark Thompson]

Supports all surface formats in common between the two.
---
 configure|   6 +
 libavutil/hwcontext_opencl.c | 298 +++
 2 files changed, 304 insertions(+)

diff --git a/configure b/configure
index 167db274f1..dcdb5fee1f 100755
--- a/configure
+++ b/configure
@@ -2121,6 +2121,7 @@ HAVE_LIST="
 $TYPES_LIST
 makeinfo
 makeinfo_html
+opencl_vaapi_beignet
 perl
 pod2man
 texi2html
@@ -6150,6 +6151,11 @@ enabled vaapi &&
 check_cpp_condition "va/va.h" "VA_CHECK_VERSION(1, 0, 0)" &&
 enable vaapi_1
 
+if enabled_all opencl vaapi ; then
+check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
+enable opencl_vaapi_beignet
+fi
+
 enabled vdpau &&
 check_cpp_condition vdpau/vdpau.h "defined 
VDP_DECODER_PROFILE_MPEG4_PART2_ASP" ||
 disable vdpau
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 0fe25d9500..7f99f5af3f 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -29,6 +29,14 @@
 #include "mem.h"
 #include "pixdesc.h"
 
+#if HAVE_OPENCL_VAAPI_BEIGNET
+#include 
+#include 
+#include 
+#include 
+#include "hwcontext_vaapi.h"
+#endif
+
 
 typedef struct OpenCLDeviceContext {
 // Default command queue to use for transfer/mapping operations on
@@ -41,6 +49,10 @@ typedef struct OpenCLDeviceContext {
 cl_platform_id platform_id;
 
 // Platform/device-specific functions.
+#if HAVE_OPENCL_VAAPI_BEIGNET
+int vaapi_mapping_usable;
+clCreateImageFromFdINTEL_fn  clCreateImageFromFdINTEL;
+#endif
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
@@ -589,6 +601,40 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 return AVERROR(EIO);
 }
 
+#define CL_FUNC(name, desc) do {\
+if (fail)   \
+break;  \
+priv->name = clGetExtensionFunctionAddressForPlatform(  \
+priv->platform_id, #name);  \
+if (!priv->name) {  \
+av_log(hwdev, AV_LOG_VERBOSE,   \
+   desc " function not found (%s).\n", #name);  \
+fail = 1;   \
+} else {\
+av_log(hwdev, AV_LOG_VERBOSE,   \
+   desc " function found (%s).\n", #name);  \
+}   \
+} while (0)
+
+#if HAVE_OPENCL_VAAPI_BEIGNET
+{
+int fail = 0;
+
+CL_FUNC(clCreateImageFromFdINTEL,
+"Intel DRM to OpenCL image mapping");
+
+if (fail) {
+av_log(hwdev, AV_LOG_WARNING, "VAAPI to OpenCL mapping "
+   "not usable.\n");
+priv->vaapi_mapping_usable = 0;
+} else {
+priv->vaapi_mapping_usable = 1;
+}
+}
+#endif
+
+#undef CL_FUNC
+
 return 0;
 }
 
@@ -606,6 +652,52 @@ static void opencl_device_uninit(AVHWDeviceContext *hwdev)
 }
 }
 
+static int opencl_device_derive(AVHWDeviceContext *hwdev,
+AVHWDeviceContext *src_ctx,
+int flags)
+{
+int err;
+switch (src_ctx->type) {
+
+#if HAVE_OPENCL_VAAPI_BEIGNET
+case AV_HWDEVICE_TYPE_VAAPI:
+{
+// Surface mapping works via DRM PRIME fds with no special
+// initialisation required in advance.  This just finds the
+// Beignet ICD by name.
+AVDictionary *opts = NULL;
+
+err = av_dict_set(&opts, "platform_vendor", "Intel", 0);
+if (err >= 0)
+err = av_dict_set(&opts, "platform_version", "beignet", 0);
+if (err >= 0) {
+OpenCLDeviceSelector selector = {
+.platform_index  = -1,
+.device_index= 0,
+.context = opts,
+.enumerate_platforms = &opencl_enumerate_platforms,
+.filter_platform = &opencl_filter_platform,
+.enumerate_devices   = &opencl_enumerate_devices,
+.filter_device   = NULL,
+};
+err = opencl_device_create_internal(hwdev, &selector, NULL);
+}
+av_dict_free(&opts);
+}
+break;
+#endif
+
+default:
+err = AVERROR(ENOSYS);
+break;
+}
+
+if (err < 0)
+return err;
+
+return opencl_device_init(hwdev);
+}
+
 static int opencl_get_plane_format(enum AVPixelFormat pixfmt,
int plane, int width, int height,
cl_image_format *image_format,
@@ -1263,6 +1355,177 @@ fail:
 return err;
 }
 
+#if HAV

[FFmpeg-devel] [PATCH 04/15] hwcontext_opencl: QSV to OpenCL mapping for Intel Media SDK

[Mark Thompson]

Uses the cl_intel_va_api_media_sharing extension, which supports only
NV12 surfaces and only mapping from QSV to OpenCL.
---
 configure|   5 +
 libavutil/hwcontext_opencl.c | 365 +++
 2 files changed, 370 insertions(+)

diff --git a/configure b/configure
index dcdb5fee1f..7649fe8de1 100755
--- a/configure
+++ b/configure
@@ -2122,6 +2122,7 @@ HAVE_LIST="
 makeinfo
 makeinfo_html
 opencl_vaapi_beignet
+opencl_vaapi_intel_media
 perl
 pod2man
 texi2html
@@ -6154,6 +6155,10 @@ enabled vaapi &&
 if enabled_all opencl vaapi ; then
 check_type "CL/cl_intel.h" "clCreateImageFromFdINTEL_fn" &&
 enable opencl_vaapi_beignet
+if enabled libmfx ; then
+check_type "CL/cl.h CL/va_ext.h" 
"clCreateFromVA_APIMediaSurfaceINTEL_fn" &&
+enable opencl_vaapi_intel_media
+fi
 fi
 
 enabled vdpau &&
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 7f99f5af3f..ee6ebd18d1 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -37,6 +37,13 @@
 #include "hwcontext_vaapi.h"
 #endif
 
+#if HAVE_OPENCL_VAAPI_INTEL_MEDIA
+#include 
+#include 
+#include 
+#include "hwcontext_vaapi.h"
+#endif
+
 
 typedef struct OpenCLDeviceContext {
 // Default command queue to use for transfer/mapping operations on
@@ -53,6 +60,16 @@ typedef struct OpenCLDeviceContext {
 int vaapi_mapping_usable;
 clCreateImageFromFdINTEL_fn  clCreateImageFromFdINTEL;
 #endif
+
+#if HAVE_OPENCL_VAAPI_INTEL_MEDIA
+int qsv_mapping_usable;
+clCreateFromVA_APIMediaSurfaceINTEL_fn
+clCreateFromVA_APIMediaSurfaceINTEL;
+clEnqueueAcquireVA_APIMediaSurfacesINTEL_fn
+clEnqueueAcquireVA_APIMediaSurfacesINTEL;
+clEnqueueReleaseVA_APIMediaSurfacesINTEL_fn
+clEnqueueReleaseVA_APIMediaSurfacesINTEL;
+#endif
 } OpenCLDeviceContext;
 
 typedef struct OpenCLFramesContext {
@@ -633,6 +650,85 @@ static int opencl_device_init(AVHWDeviceContext *hwdev)
 }
 #endif
 
+#if HAVE_OPENCL_VAAPI_INTEL_MEDIA
+{
+size_t props_size;
+cl_context_properties *props = NULL;
+VADisplay va_display;
+const char *va_ext = "cl_intel_va_api_media_sharing";
+int i, fail = 0;
+
+if (!opencl_check_extension(hwdev, va_ext)) {
+av_log(hwdev, AV_LOG_VERBOSE, "The %s extension is "
+   "required for QSV to OpenCL mapping.\n", va_ext);
+goto no_qsv;
+}
+
+cle = clGetContextInfo(hwctx->context, CL_CONTEXT_PROPERTIES,
+   0, NULL, &props_size);
+if (cle != CL_SUCCESS) {
+av_log(hwdev, AV_LOG_VERBOSE, "Failed to get context "
+   "properties: %d.\n", cle);
+goto no_qsv;
+}
+if (props_size == 0) {
+av_log(hwdev, AV_LOG_VERBOSE, "Media sharing must be "
+   "enabled on context creation to use QSV to "
+   "OpenCL mapping.\n");
+goto no_qsv;
+}
+
+props = av_malloc(props_size);
+if (!props)
+return AVERROR(ENOMEM);
+
+cle = clGetContextInfo(hwctx->context, CL_CONTEXT_PROPERTIES,
+   props_size, props, NULL);
+if (cle != CL_SUCCESS) {
+av_log(hwdev, AV_LOG_VERBOSE, "Failed to get context "
+   "properties: %d.\n", cle);
+goto no_qsv;
+}
+
+va_display = NULL;
+for (i = 0; i < (props_size / sizeof(*props) - 1); i++) {
+if (props[i] == CL_CONTEXT_VA_API_DISPLAY_INTEL) {
+va_display = (VADisplay)(intptr_t)props[i+1];
+break;
+}
+}
+if (!va_display) {
+av_log(hwdev, AV_LOG_VERBOSE, "Media sharing must be "
+   "enabled on context creation to use QSV to "
+   "OpenCL mapping.\n");
+goto no_qsv;
+}
+if (!vaDisplayIsValid(va_display)) {
+av_log(hwdev, AV_LOG_VERBOSE, "A valid VADisplay is "
+   "required on context creation to use QSV to "
+   "OpenCL mapping.\n");
+goto no_qsv;
+}
+
+CL_FUNC(clCreateFromVA_APIMediaSurfaceINTEL,
+"Intel QSV to OpenCL mapping");
+CL_FUNC(clEnqueueAcquireVA_APIMediaSurfacesINTEL,
+"Intel QSV in OpenCL acquire");
+CL_FUNC(clEnqueueReleaseVA_APIMediaSurfacesINTEL,
+"Intel QSV in OpenCL release");
+
+if (fail) {
+no_qsv:
+av_log(hwdev, AV_LOG_WARNING, "QSV to OpenCL mapping "
+   "not usable.\n");
+priv->qsv_mapping_usable = 0;
+} else {
+priv->qsv_mapping_usable = 1;
+}
+av_free(props);
+}
+#endif
+
 #undef CL_FUNC
 
 return 0;
@@ -652,6 +748,95 @@ static void opencl_device_uninit(AVHWDeviceContext *hwdev

[FFmpeg-devel] [PATCH 02/15] lavu: OpenCL hwcontext implementation

[Mark Thompson]

---
 configure  |4 +-
 doc/APIchanges |4 +
 libavutil/Makefile |2 +
 libavutil/hwcontext.c  |4 +
 libavutil/hwcontext.h  |1 +
 libavutil/hwcontext_internal.h |1 +
 libavutil/hwcontext_opencl.c   | 1303 
 libavutil/hwcontext_opencl.h   |   96 +++
 8 files changed, 1413 insertions(+), 2 deletions(-)
 create mode 100644 libavutil/hwcontext_opencl.c
 create mode 100644 libavutil/hwcontext_opencl.h

diff --git a/configure b/configure
index 3788f26956..167db274f1 100755
--- a/configure
+++ b/configure
@@ -289,7 +289,7 @@ External library support:
   --enable-mediacodec  enable Android MediaCodec support [no]
   --enable-libmysofa   enable libmysofa, needed for sofalizer filter [no]
   --enable-openal  enable OpenAL 1.1 capture support [no]
-  --enable-opencl  enable OpenCL code
+  --enable-opencl  enable OpenCL processing [no]
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls is not used [no]
@@ -1634,7 +1634,6 @@ EXTERNAL_LIBRARY_LIST="
 libzvbi
 mediacodec
 openal
-opencl
 opengl
 "
 
@@ -1670,6 +1669,7 @@ HWACCEL_LIBRARY_LIST="
 libmfx
 mmal
 omx
+opencl
 "
 
 DOCUMENT_LIST="
diff --git a/doc/APIchanges b/doc/APIchanges
index 3f68bcccd2..cf8b28d820 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavu 55.n+1.0 - hwcontext.h hwcontext_opencl.h
+  Add AV_HWDEVICE_TYPE_OPENCL and a new installed header with
+  OpenCL-specific hwcontext definitions.
+
 2017-xx-xx - xxx - lavu 55.n+1.0 - pixfmt.h
   Add AV_PIX_FMT_OPENCL.
 
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 65e285a701..cc70c4e29f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -165,6 +165,7 @@ OBJS-$(CONFIG_QSV)   += hwcontext_qsv.o
 OBJS-$(CONFIG_LIBDRM)   += hwcontext_drm.o
 OBJS-$(CONFIG_LZO)  += lzo.o
 OBJS-$(CONFIG_OPENCL)   += opencl.o opencl_internal.o
+OBJS-$(CONFIG_OPENCL)   += hwcontext_opencl.o
 OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
@@ -179,6 +180,7 @@ SKIPHEADERS-$(CONFIG_CUDA) += 
hwcontext_cuda_internal.h
 SKIPHEADERS-$(CONFIG_D3D11VA)  += hwcontext_d3d11va.h
 SKIPHEADERS-$(CONFIG_DXVA2)+= hwcontext_dxva2.h
 SKIPHEADERS-$(CONFIG_QSV)   += hwcontext_qsv.h
+SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 7f8e22736c..b26e68fe77 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -41,6 +41,9 @@ static const HWContextType * const hw_table[] = {
 #if CONFIG_DXVA2
 &ff_hwcontext_type_dxva2,
 #endif
+#if CONFIG_OPENCL
+&ff_hwcontext_type_opencl,
+#endif
 #if CONFIG_QSV
 &ff_hwcontext_type_qsv,
 #endif
@@ -61,6 +64,7 @@ static const char *const hw_type_names[] = {
 [AV_HWDEVICE_TYPE_DRM]= "drm",
 [AV_HWDEVICE_TYPE_DXVA2]  = "dxva2",
 [AV_HWDEVICE_TYPE_D3D11VA] = "d3d11va",
+[AV_HWDEVICE_TYPE_OPENCL] = "opencl",
 [AV_HWDEVICE_TYPE_QSV]= "qsv",
 [AV_HWDEVICE_TYPE_VAAPI]  = "vaapi",
 [AV_HWDEVICE_TYPE_VDPAU]  = "vdpau",
diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index d20810422c..8d27b987df 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -34,6 +34,7 @@ enum AVHWDeviceType {
 AV_HWDEVICE_TYPE_VIDEOTOOLBOX,
 AV_HWDEVICE_TYPE_D3D11VA,
 AV_HWDEVICE_TYPE_DRM,
+AV_HWDEVICE_TYPE_OPENCL,
 };
 
 typedef struct AVHWDeviceInternal AVHWDeviceInternal;
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index 2d75d3db08..28ff0f9ee6 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -161,6 +161,7 @@ extern const HWContextType ff_hwcontext_type_cuda;
 extern const HWContextType ff_hwcontext_type_d3d11va;
 extern const HWContextType ff_hwcontext_type_drm;
 extern const HWContextType ff_hwcontext_type_dxva2;
+extern const HWContextType ff_hwcontext_type_opencl;
 extern const HWContextType ff_hwcontext_type_qsv;
 extern const HWContextType ff_hwcontext_type_vaapi;
 extern const HWContextType ff_hwcontext_type_vdpau;
diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
new file mode 100644
index 00..0fe25d9500
--- /dev/null
+++ b/libavutil/hwcontext_opencl.c
@@ -0,0 +1,1303 @@
+/*
+ * This file is part 

[FFmpeg-devel] [PATCH 00/15] OpenCL infrastructure, filters

[Mark Thompson]

Changes since the last time this was posted:
* Add unsharp filter (to replace existing unsharp).
* Remove old experimental API.
* Miscellaneous fixes.

Now also tested with AMD OpenCL on Windows (DXVA2 mapping works nicely, D3D11 
does not because it wants the Intel extension for NV12 support).

Thanks,

- Mark


Silly example using everything (for i965 VAAPI + Beignet):

./ffmpeg_g -y -init_hw_device vaapi=va:/dev/dri/renderD128 -init_hw_device 
opencl=ocl@va -hwaccel vaapi -hwaccel_device va -hwaccel_output_format vaapi -i 
in.mp4 -f image2 -r 1 -i overlays/%d.png -an -filter_hw_device ocl 
-filter_complex '[1:v]format=yuva420p,hwupload[x2]; 
[0:v]scale_vaapi=1280:720:yuv420p,hwmap[x1]; 
[x1][x2]overlay_opencl=0:0,program_opencl=test.cl:rotate_image,unsharp_opencl=lx=17:ly=17:la=5,hwmap=derive_device=vaapi:reverse=1,scale_vaapi=1280:720:nv12'
 -c:v h264_vaapi -frames:v 1000 out.mp4

test.cl:

__kernel void rotate_image(__write_only image2d_t dst,
   __read_only  image2d_t src,
   unsigned int index)
{
  const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
 CLK_FILTER_LINEAR);

  float angle = (float)index / 100;

  float2 dst_dim = convert_float2(get_image_dim(dst));
  float2 src_dim = convert_float2(get_image_dim(src));

  float2 dst_cen = dst_dim / 2;
  float2 src_cen = src_dim / 2;

  int2   dst_loc = (int2)(get_global_id(0), get_global_id(1));

  float2 dst_pos = convert_float2(dst_loc) - dst_cen;
  float2 src_pos = {
cos(angle) * dst_pos.x - sin(angle) * dst_pos.y,
sin(angle) * dst_pos.x + cos(angle) * dst_pos.y
  };
  src_pos = src_pos * src_dim / dst_dim;

  float2 src_loc = src_pos + src_cen;

  if (src_loc.x < 0 || src_loc.y < 0 ||
  src_loc.x > src_dim.x || src_loc.y > src_dim.y)
write_imagef(dst, dst_loc, 0.5);
  else
write_imagef(dst, dst_loc, read_imagef(src, sampler, src_loc));
}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 01/15] lavu: Add OpenCL hardware pixfmt

[Mark Thompson]

---
 doc/APIchanges  | 3 +++
 libavutil/pixdesc.c | 4 
 libavutil/pixfmt.h  | 7 +++
 3 files changed, 14 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index d336f6ce22..3f68bcccd2 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2017-xx-xx - xxx - lavu 55.n+1.0 - pixfmt.h
+  Add AV_PIX_FMT_OPENCL.
+
 2017-xx-xx - xxx - lavc 58.3.100 - avcodec.h
   Add avcodec_get_hw_frames_parameters().
 
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 3d21e67a78..e77d5f44b9 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2181,6 +2181,10 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 .name = "drm_prime",
 .flags = AV_PIX_FMT_FLAG_HWACCEL,
 },
+[AV_PIX_FMT_OPENCL] = {
+.name  = "opencl",
+.flags = AV_PIX_FMT_FLAG_HWACCEL,
+},
 };
 #if FF_API_PLUS1_MINUS1
 FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index a520028962..4c530fead3 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -322,6 +322,13 @@ enum AVPixelFormat {
  * data[0] points to an AVDRMFrameDescriptor.
  */
 AV_PIX_FMT_DRM_PRIME,
+/**
+ * Hardware surfaces for OpenCL.
+ *
+ * data[i] contain 2D image objects (typed in C as cl_mem, used
+ * in OpenCL as image2d_t) for each plane of the surface.
+ */
+AV_PIX_FMT_OPENCL,
 
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
-- 
2.11.0

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

[FFmpeg-devel] [PATCH v3 1/2] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
---
 libavcodec/mpeg12dec.c   | 39 +++
 tests/fate/subtitles.mak |  3 +++
 tests/ref/fate/sub-cc-scte20 | 15 +++
 3 files changed, 57 insertions(+)
 create mode 100644 tests/ref/fate/sub-cc-scte20

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 82bb1286ff..e2a7c3f2e0 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2240,6 +2240,45 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 return 1;
+} else if (buf_size >= 2 &&
+   p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
+/* extract SCTE-20 CC data */
+GetBitContext gb;
+int cc_count = 0;
+int i;
+
+init_get_bits(&gb, p + 2, buf_size - 2);
+cc_count = get_bits(&gb, 5);
+if (cc_count > 0) {
+av_freep(&s1->a53_caption);
+s1->a53_caption_size = cc_count * 3;
+s1->a53_caption  = av_mallocz(s1->a53_caption_size);
+if (s1->a53_caption) {
+uint8_t field, cc1, cc2;
+uint8_t *cap = s1->a53_caption;
+for (i = 0; i < cc_count && get_bits_left(&gb) >= 26; i++) {
+skip_bits(&gb, 2); // priority
+field = get_bits(&gb, 2);
+skip_bits(&gb, 5); // line_offset
+cc1 = get_bits(&gb, 8);
+cc2 = get_bits(&gb, 8);
+skip_bits(&gb, 1); // marker
+
+if (!field) { // forbidden
+cap[0] = cap[1] = cap[2] = 0x00;
+} else {
+field = (field == 2 ? 1 : 0);
+if (!s1->mpeg_enc_ctx.top_field_first) field = !field;
+cap[0] = 0x04 | field;
+cap[1] = ff_reverse[cc1];
+cap[2] = ff_reverse[cc2];
+}
+cap += 3;
+}
+}
+avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
+}
+return 1;
 } else if (buf_size >= 11 &&
p[0] == 'C' && p[1] == 'C' && p[2] == 0x01 && p[3] == 0xf8) {
 /* extract DVD CC data
diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index 8c310adeff..0042902161 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -7,6 +7,9 @@ fate-sub-cc: CMD = fmtstdout ass -f lavfi -i 
"movie=$(TARGET_SAMPLES)/sub/Closed
 FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV CCAPTION_DECODER 
MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc-realtime
 fate-sub-cc-realtime: CMD = fmtstdout ass -real_time 1 -f lavfi -i 
"movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]"
 
+FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV CCAPTION_DECODER 
MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc-scte20
+fate-sub-cc-scte20: CMD = fmtstdout ass -f lavfi -i 
"movie=$(TARGET_SAMPLES)/sub/scte20.ts[out0+subcc]"
+
 FATE_SUBTITLES_ASS-$(call DEMDEC, ASS, ASS) += fate-sub-ass-to-ass-transcode
 fate-sub-ass-to-ass-transcode: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/1ededcbd7b.ass
 
diff --git a/tests/ref/fate/sub-cc-scte20 b/tests/ref/fate/sub-cc-scte20
new file mode 100644
index 00..bf581f226d
--- /dev/null
+++ b/tests/ref/fate/sub-cc-scte20
@@ -0,0 +1,15 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, 
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, 
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, 
MarginV, Encoding
+Style: 
Default,Monospace,16,&Hff,&Hff,&H0,&H0,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:00.00,0:00:01.44,Default,,0,0,0,,{\an7}{\pos(48,182)}BESIDES 
THE 
+Dialogue: 
0,0:00:01.43,0:00:03.93,Default,,0,0,0,,{\an7}{\pos(38,166)}\hBESIDES THE 
\N{\an7}{\pos(38,197)}SPENDING AND THIS, IS THAT CAR 
+Dialogue: 0,0:00:03.94,0:00:06.31,Default,,0,0,0,,{\an7}{\pos(38,182)}SPENDING 
AND THIS, IS THAT CAR \N{\an7}{\pos(38,197)}MANUFACTURERS ARE ABOUT AS 
-- 
2.14.2

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

[FFmpeg-devel] [PATCH v3 2/2] avcodec/mpeg12dec: ensure a53_caption_size is reset on malloc failures

[Aman Gupta]

From: Aman Gupta 

Signed-off-by: Aman Gupta 
Reviewed-by: Michael Niedermayer 
---
 libavcodec/mpeg12dec.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index e2a7c3f2e0..d5bc5f21b2 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2235,8 +2235,11 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 av_freep(&s1->a53_caption);
 s1->a53_caption_size = cc_count * 3;
 s1->a53_caption  = av_malloc(s1->a53_caption_size);
-if (s1->a53_caption)
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
 memcpy(s1->a53_caption, p + 7, s1->a53_caption_size);
+}
 avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 return 1;
@@ -2253,7 +2256,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 av_freep(&s1->a53_caption);
 s1->a53_caption_size = cc_count * 3;
 s1->a53_caption  = av_mallocz(s1->a53_caption_size);
-if (s1->a53_caption) {
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
 uint8_t field, cc1, cc2;
 uint8_t *cap = s1->a53_caption;
 for (i = 0; i < cc_count && get_bits_left(&gb) >= 26; i++) {
@@ -2317,7 +2322,9 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
 av_freep(&s1->a53_caption);
 s1->a53_caption_size = cc_count * 6;
 s1->a53_caption  = av_malloc(s1->a53_caption_size);
-if (s1->a53_caption) {
+if (!s1->a53_caption) {
+s1->a53_caption_size = 0;
+} else {
 uint8_t field1 = !!(p[4] & 0x80);
 uint8_t *cap = s1->a53_caption;
 p += 5;
-- 
2.14.2

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

Re: [FFmpeg-devel] [PATCH] configure: call flatten_extralibs in a subshell

[James Almer]

On 11/14/2017 11:35 AM, Timo Rothenpieler wrote:
> Am 14.11.2017 um 14:50 schrieb Timo Rothenpieler:
>> By putting the call in a subshell, the problem of it spilling
>> cleanup-decision from a previous library to other libraries is avoided.
>>
>> For example, it could have already cleaned up cuda_extralibs in a
>> previous library that depended on cuda. Then when it gets to avutil, it
>> will never pick up the dependency of avutil to cuda, which depends on
>> libdl, which in turn results in a missing -ldl extralib, resulting in
>> link failures in certain configurations.
>> ---
>>   configure | 15 +++
>>   1 file changed, 11 insertions(+), 4 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 3788f26956..1fc6821fe7 100755
>> --- a/configure
>> +++ b/configure
>> @@ -6501,6 +6501,16 @@ flatten_extralibs(){
>>   fi
>>   }
>>   +flatten_extralibs_wrapper(){
>> +    list_name=$1
>> +    flatten_extralibs $list_name
>> +    unique $list_name
>> +    resolve $list_name
>> +    unique $list_name
> 
> Scratch that second unique.
> While it does get rid of a bunch of duplicates like double -lX11 or
> -lvpx, it breaks MacOS builds, due to it getting rid of all but one
> -framework invocations.

Seems to work after removing the second unique. Thanks a lot!

> 
>> +    eval $list_name=\$\(\$ldflags_filter \$$list_name\)
>> +    eval printf \''%s'\' \""\$$list_name"\"
>> +}
>> +
>>   for linkunit in $LIBRARY_LIST; do
>>   unset current_extralibs
>>   eval components=\$$(toupper ${linkunit})_COMPONENTS_LIST
>> @@ -6513,10 +6523,7 @@ for linkunit in $LIBRARY_LIST; do
>>   done
>>     for linkunit in $LIBRARY_LIST $PROGRAM_LIST $EXTRALIBS_LIST; do
>> -    flatten_extralibs ${linkunit}_extralibs
>> -    unique  ${linkunit}_extralibs
>> -    resolve ${linkunit}_extralibs
>> -    eval ${linkunit}_extralibs=\$\(\$ldflags_filter
>> \$${linkunit}_extralibs\)
>> +    eval ${linkunit}_extralibs=\$\(flatten_extralibs_wrapper
>> ${linkunit}_extralibs\)
>>   done
>>     map 'enabled $v && intrinsics=${v#intrinsics_}' $INTRINSICS_LIST
>>
> 
> 
> 
> ___
> 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 1/2] avcodec: fix whitespace on AVPanScan struct definition

[Aman Gupta]

On Tue, Nov 14, 2017 at 10:23 AM, James Almer  wrote:

> On 11/14/2017 3:04 PM, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > ---
> >  libavcodec/avcodec.h | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index 74b097cdd8..0875ae3ba0 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -1049,7 +1049,7 @@ typedef struct RcOverride{
> >   * This specifies the area which should be displayed.
> >   * Note there may be multiple such areas for one frame.
> >   */
> > -typedef struct AVPanScan{
> > +typedef struct AVPanScan {
> >  /**
> >   * id
> >   * - encoding: Set by user.
> > @@ -1071,7 +1071,7 @@ typedef struct AVPanScan{
> >   * - decoding: Set by libavcodec.
> >   */
> >  int16_t position[3][2];
> > -}AVPanScan;
> > +} AVPanScan;
>
> LGTM, but minimal cosmetic changes like this don't need a patch if you
> have push rights.
>

Ah, I did not know that. Will push, thanks!

Aman


>
> >
> >  /**
> >   * This structure describes the bitrate properties of an encoded
> bitstream. It
> >
>
> ___
> 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 1/2] avcodec: fix whitespace on AVPanScan struct definition

[James Almer]

On 11/14/2017 3:04 PM, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/avcodec.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 74b097cdd8..0875ae3ba0 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -1049,7 +1049,7 @@ typedef struct RcOverride{
>   * This specifies the area which should be displayed.
>   * Note there may be multiple such areas for one frame.
>   */
> -typedef struct AVPanScan{
> +typedef struct AVPanScan {
>  /**
>   * id
>   * - encoding: Set by user.
> @@ -1071,7 +1071,7 @@ typedef struct AVPanScan{
>   * - decoding: Set by libavcodec.
>   */
>  int16_t position[3][2];
> -}AVPanScan;
> +} AVPanScan;

LGTM, but minimal cosmetic changes like this don't need a patch if you
have push rights.

>  
>  /**
>   * This structure describes the bitrate properties of an encoded bitstream. 
> It
> 

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

Re: [FFmpeg-devel] [PATCH] lavf/mov.c: Guess video codec delay based on PTS while parsing MOV header.

[Derek Buitenhuis]

On 11/14/2017 2:15 AM, Sasi Inguva wrote:
> Signed-off-by: Sasi Inguva 
> ---
>  libavformat/mov.c| 48 
> 
>  tests/fate/mov.mak   |  5 +
>  tests/ref/fate/mov-guess-delay-1 |  3 +++
>  tests/ref/fate/mov-guess-delay-2 |  3 +++
>  4 files changed, 59 insertions(+)
>  create mode 100644 tests/ref/fate/mov-guess-delay-1
>  create mode 100644 tests/ref/fate/mov-guess-delay-2

Going to play the part of wm4 here.

This seems like one giant hack to me (and potentially yet more slowness
during init/index).

Should we *really* be populating codecpar with a heuristic guess and
should we *really* be putting this in one specific demuxer?

Seems pretty gross to me.

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