[FFmpeg-devel] [PATCH, v4] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE

[Linjie Fu]

Given that leading_zero_8bits can be included many times at the beginning
of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
in last frame.

When startcode is found, go back to find all leading_zero_8bits in
current buffer and pc->buffer to cut correctly.

Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
{ 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }

To verify the output of FATE:
ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags \
+bitexact hevc-mp4.mov
ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out

Signed-off-by: Linjie Fu 
---
[v2]: Update FATE checksum.
[v3]: Cope with more leading_zero_8bits cases.
[v4]: find leading_zero_8bits in pc->buffer to cut correctly.

 libavcodec/hevc_parser.c | 12 
 tests/fate/hevc.mak  |  2 +-
 2 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index 369d1338d0..f6df43a067 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -267,8 +267,7 @@ static int hevc_find_frame_end(AVCodecParserContext *s, 
const uint8_t *buf,
 if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut == 
HEVC_NAL_SEI_PREFIX ||
 (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
 if (pc->frame_start_found) {
-pc->frame_start_found = 0;
-return i - 5;
+goto found;
 }
 } else if (nut <= HEVC_NAL_RASL_R ||
(nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT)) {
@@ -277,14 +276,19 @@ static int hevc_find_frame_end(AVCodecParserContext *s, 
const uint8_t *buf,
 if (!pc->frame_start_found) {
 pc->frame_start_found = 1;
 } else { // First slice of next frame found
-pc->frame_start_found = 0;
-return i - 5;
+goto found;
 }
 }
 }
 }
 
 return END_NOT_FOUND;
+
+found:
+pc->frame_start_found = 0;
+while (i - 6 >= 0 ? !buf[i - 6] : !pc->buffer[pc->index + i - 6])
+i--;
+return i - 5;
 }
 
 static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index db3ea19340..ab8da53535 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER MOV_DEMUXER 
HEVC_MP4TOANNEXB_BSF MOV_MUXER
 fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
 fate-hevc-bsf-mp4toannexb: CMD = md5 -i $(TARGET_PATH)/tests/data/hevc-mp4.mov 
-c:v copy -fflags +bitexact -f hevc
 fate-hevc-bsf-mp4toannexb: CMP = oneline
-fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
+fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
 
 fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i 
$(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -sws_flags bitexact
 FATE_HEVC += fate-hevc-skiploopfilter
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images

[Peter Ross]

On Fri, Jan 11, 2019 at 03:23:49AM +0100, Carl Eugen Hoyos wrote:
> 2019-01-11 2:55 GMT+01:00, Carl Eugen Hoyos :
> > Hi!
> >
> > Attached patch fixes ticket #6797, please comment.
> 
> New patch with 16bit support attached.
> 
> Please comment, Carl Eugen

> From 5f879539ee7fecd57bd3de9f7c6363d9b7779b5b Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Fri, 11 Jan 2019 03:20:38 +0100
> Subject: [PATCH] lavc/psd: Support CMYK images.
> 
> Based on a05635e by Michael Niedermayer.
> 
> Fixes ticket #6797.
> ---
>  libavcodec/psd.c |   84 
> ++
>  1 file changed, 84 insertions(+)
> 
> diff --git a/libavcodec/psd.c b/libavcodec/psd.c

> +if (s->channel_depth == 8) {
> +for (y = 0; y < s->height; y++) {
> +for (x = 0; x < s->width; x++) {
> +int k = src[3][x];
> +int r = src[0][x] * k;
> +int g = src[1][x] * k;
> +int b = src[2][x] * k;
> +dst[0][x] = g * 257 >> 16;
> +dst[1][x] = b * 257 >> 16;
> +dst[2][x] = r * 257 >> 16;
> +}

the same algorithm exists in libavcodec/mjpegdec.c, with alpha channel support.
i guess it is trivial enough to be duplicated here.

otherwise looks good.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Li, Zhong]

> Which libx264 option is / can be hidden?
This one:
#if X264_BUILD >= 144
{ "autovariance-biased", "Auto-variance AQ with bias to dark scenes", 0, 
AV_OPT_TYPE_CONST, {.i64 = X264_AQ_AUTOVARIANCE_BIASED}, INT_MIN, INT_MAX, VE, 
"aq_mode" },
#endif

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Carl Eugen Hoyos]

2019-01-11 4:42 GMT+01:00, Li, Zhong :

>> >> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
>> >>
>> >> > +#if QSV_HAVE_VDENC
>> >> > +{ "low_power", "enable low power mode(experimental: many
>> >> > +limitations by
>> >> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
>> >> > AV_OPT_TYPE_BOOL, {
>> >> > .i64 =  0 }, 0, 1, VE},
>> >> > +#endif
>> >>
>> >> This seems wrong to me: The visibility of an option should probably
>> >> not depend on configuration details (the effect can of course depend
>> >> on many details).
>> >
>> > That's is just a remind that this feature has some limitations. The
>> > configures are just to make driver to support this feature.
>> > In ffmpeg level, the only thing we should do IMHO is to query
>> > MSDK/Driver capability and report an error message if not supported.
>> > And it was done:
>> >
>> https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b
>> 0dbc
>> > 93998a90/libavcodec/qsvenc.c#L376
>>
>> That is probably helpful, but the issue I try to explain is unrelated to
>> the brokenness of the option:
>> Now, in some cases FFmpeg shows the option and in other cases
>> it does not.
>> I believe that instead, the option should always be shown, even
>> if it does not work.
>
> That is a big topic since I see many components are doing this. E.g;
> we can find some options of libx264 and nvenc are hided too.

Which libx264 option is / can be hidden?

> Personally speaking I like current way: if the implementation of an
> option is not built-in, it is not necessary to show the option, else it
> is really confusing that this option can't work at any case.

Isn't it more confusing for a user who reads about a documented
option and wants to use if it isn't there instead of a message shown?

(You don't have to fix every existing issue, avoiding to add new
ones is a plus though.)

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

[FFmpeg-devel] [PATCH v2] avformat/dashdec: control download speed when in live stream mode

[Steven Liu]

fix ticket: 7369
check the duration is less than the fragment duration,
retry when the condition is true.
don't control the download speed when reading header

Signed-off-by: Steven Liu 
---
 libavformat/dashdec.c | 29 +
 1 file changed, 29 insertions(+)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index f4f4e935de..473adb9bfb 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -108,6 +108,7 @@ struct representation {
 int64_t cur_seg_offset;
 int64_t cur_seg_size;
 struct fragment *cur_seg;
+int64_t last_load_time;
 
 /* Currently active Media Initialization Section */
 struct fragment *init_section;
@@ -121,6 +122,9 @@ struct representation {
 
 typedef struct DASHContext {
 const AVClass *class;
+
+int read_init_sections;
+
 char *base_url;
 char *adaptionset_contenttype_val;
 char *adaptionset_par_val;
@@ -1084,6 +1088,8 @@ static int parse_manifest_representation(AVFormatContext 
*s, const char *url,
 }
 }
 
+if (rep)
+rep->last_load_time = get_current_time_in_sec();
 video_rep_idx += type == AVMEDIA_TYPE_VIDEO;
 audio_rep_idx += type == AVMEDIA_TYPE_AUDIO;
 subtitle_rep_idx += type == AVMEDIA_TYPE_SUBTITLE;
@@ -1382,6 +1388,9 @@ static int64_t calc_cur_seg_no(AVFormatContext *s, struct 
representation *pls)
 } else {
 num = pls->first_seq_no;
 }
+
+if (pls)
+pls->last_load_time = get_current_time_in_sec();
 return num;
 }
 
@@ -1461,6 +1470,7 @@ static int refresh_manifest(AVFormatContext *s)
 {
 
 int ret = 0, i;
+int64_t cur_time = get_current_time_in_sec();
 DASHContext *c = s->priv_data;
 
 // save current context
@@ -1505,6 +1515,11 @@ static int refresh_manifest(AVFormatContext *s)
 for (i = 0; i < n_videos; i++) {
 struct representation *cur_video = videos[i];
 struct representation *ccur_video = c->videos[i];
+if (cur_video)
+cur_video->last_load_time = cur_time;
+if (ccur_video)
+ccur_video->last_load_time = cur_time;
+
 if (cur_video->timelines) {
 // calc current time
 int64_t currentTime = 
get_segment_start_time_based_on_timeline(cur_video, cur_video->cur_seq_no) / 
cur_video->fragment_timescale;
@@ -1521,6 +1536,11 @@ static int refresh_manifest(AVFormatContext *s)
 for (i = 0; i < n_audios; i++) {
 struct representation *cur_audio = audios[i];
 struct representation *ccur_audio = c->audios[i];
+if (cur_audio)
+cur_audio->last_load_time = cur_time;
+if (ccur_audio)
+ccur_audio->last_load_time = cur_time;
+
 if (cur_audio->timelines) {
 // calc current time
 int64_t currentTime = 
get_segment_start_time_based_on_timeline(cur_audio, cur_audio->cur_seq_no) / 
cur_audio->fragment_timescale;
@@ -1629,6 +1649,8 @@ static struct fragment *get_current_fragment(struct 
representation *pls)
 av_free(tmpfilename);
 seg->size = -1;
 }
+if (pls)
+pls->last_load_time = get_current_time_in_sec();
 
 return seg;
 }
@@ -1747,6 +1769,11 @@ static int read_data(void *opaque, uint8_t *buf, int 
buf_size)
 DASHContext *c = v->parent->priv_data;
 
 restart:
+if (!c->read_init_sections && c->is_live && v->fragment_duration != 0 && 
v->fragment_timescale != 0)
+if (get_current_time_in_sec() - v->last_load_time < 
(v->fragment_duration / v->fragment_timescale)) {
+av_usleep(100*1000);
+goto restart;
+}
 if (!v->input) {
 free_fragment(>cur_seg);
 v->cur_seg = get_current_fragment(v);
@@ -2002,6 +2029,7 @@ static int dash_read_header(AVFormatContext *s)
 
 av_dict_set(>avio_opts, "seekable", "0", 0);
 
+c->read_init_sections = 1;
 if ((ret = parse_manifest(s, s->url, s->pb)) < 0)
 goto fail;
 
@@ -2146,6 +2174,7 @@ static int dash_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 recheck_discard_flags(s, c->audios, c->n_audios);
 recheck_discard_flags(s, c->subtitles, c->n_subtitles);
 
+c->read_init_sections = 0;
 for (i = 0; i < c->n_videos; i++) {
 struct representation *pls = c->videos[i];
 if (!pls->ctx)
-- 
2.15.2 (Apple Git-101.1)



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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 10:39 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
> 
> 2019-01-11 3:28 GMT+01:00, Li, Zhong :
> >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> >> Of Carl Eugen Hoyos
> >> Sent: Friday, January 11, 2019 1:06 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> >> support for H264
> >>
> >> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
> >>
> >> > +#if QSV_HAVE_VDENC
> >> > +{ "low_power", "enable low power mode(experimental: many
> >> > +limitations by
> >> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> >> > AV_OPT_TYPE_BOOL, {
> >> > .i64 =  0 }, 0, 1, VE},
> >> > +#endif
> >>
> >> This seems wrong to me: The visibility of an option should probably
> >> not depend on configuration details (the effect can of course depend
> >> on many details).
> >>
> >> Carl Eugen
> >
> > That's is just a remind that this feature has some limitations. The
> > configures are just to make driver to support this feature.
> > In ffmpeg level, the only thing we should do IMHO is to query
> > MSDK/Driver capability and report an error message if not supported.
> > And it was done:
> >
> https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b
> 0dbc
> > 93998a90/libavcodec/qsvenc.c#L376
> 
> That is probably helpful, but the issue I try to explain is unrelated to the
> brokenness of the option:
> Now, in some cases FFmpeg shows the option and in other cases it does not.
> I believe that instead, the option should always be shown, even if it does not
> work.

That is a big topic since I see many components are doing this. E.g; we can 
find some options of libx264 and nvenc are hided too.
Personally speaking I like current way: if the implementation of an option is 
not built-in, it is not necessary to show the option, else it is really 
confusing that this option can't work at any case.
But I am open to your suggestion, and looking forward more comments from you 
and others. (If we get alignment, we need to clear up many options, not only 
this one).

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Carl Eugen Hoyos]

2019-01-11 3:39 GMT+01:00, Li, Zhong :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Li, Zhong
>> Sent: Friday, January 11, 2019 10:29 AM
>> To: FFmpeg development discussions and patches
>> 
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
>> support for H264
>>
>> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>> > Of Carl Eugen Hoyos
>> > Sent: Friday, January 11, 2019 1:06 AM
>> > To: ffmpeg-devel@ffmpeg.org
>> > Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
>> > support for H264
>> >
>> > 2019-01-10 14:51 GMT+01:00, Linjie Fu :
>> >
>> > > +#if QSV_HAVE_VDENC
>> > > +{ "low_power", "enable low power mode(experimental: many
>> > > +limitations by
>> > > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
>> > > AV_OPT_TYPE_BOOL, {
>> > > .i64 =  0 }, 0, 1, VE},
>> > > +#endif
>> >
>> > This seems wrong to me: The visibility of an option should probably
>> > not depend on configuration details (the effect can of course depend
>> > on many details).
>> >
>> > Carl Eugen
>>
>> That's is just a remind that this feature has some limitations. The
>> configures
>> are just to make driver to support this feature.
>> In ffmpeg level, the only thing we should do IMHO is to query MSDK/Driver
>> capability and report an error message if not supported.
>> And it was done:
>> https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b
>> 0dbc93998a90/libavcodec/qsvenc.c#L376
>
> I may misunderstand the "configuration" you mentioned.
> Do you mean checking " QSV_HAVE_VDENC "?

Yes.

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Li, Zhong
> Sent: Friday, January 11, 2019 10:29 AM
> To: FFmpeg development discussions and patches
> 
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
> 
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Carl Eugen Hoyos
> > Sent: Friday, January 11, 2019 1:06 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> > support for H264
> >
> > 2019-01-10 14:51 GMT+01:00, Linjie Fu :
> >
> > > +#if QSV_HAVE_VDENC
> > > +{ "low_power", "enable low power mode(experimental: many
> > > +limitations by
> > > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> > > AV_OPT_TYPE_BOOL, {
> > > .i64 =  0 }, 0, 1, VE},
> > > +#endif
> >
> > This seems wrong to me: The visibility of an option should probably
> > not depend on configuration details (the effect can of course depend
> > on many details).
> >
> > Carl Eugen
> 
> That's is just a remind that this feature has some limitations. The configures
> are just to make driver to support this feature.
> In ffmpeg level, the only thing we should do IMHO is to query MSDK/Driver
> capability and report an error message if not supported.
> And it was done:
> https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b
> 0dbc93998a90/libavcodec/qsvenc.c#L376

I may misunderstand the "configuration" you mentioned. Do you mean checking " 
QSV_HAVE_VDENC "? 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Carl Eugen Hoyos]

2019-01-11 3:28 GMT+01:00, Li, Zhong :
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Carl Eugen Hoyos
>> Sent: Friday, January 11, 2019 1:06 AM
>> To: ffmpeg-devel@ffmpeg.org
>> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
>> support for H264
>>
>> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
>>
>> > +#if QSV_HAVE_VDENC
>> > +{ "low_power", "enable low power mode(experimental: many
>> > +limitations by
>> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
>> > AV_OPT_TYPE_BOOL, {
>> > .i64 =  0 }, 0, 1, VE},
>> > +#endif
>>
>> This seems wrong to me: The visibility of an option should probably not
>> depend on configuration details (the effect can of course depend on many
>> details).
>>
>> Carl Eugen
>
> That's is just a remind that this feature has some limitations. The
> configures are just to make driver to support this feature.
> In ffmpeg level, the only thing we should do IMHO is to query MSDK/Driver
> capability and report an error message if not supported.
> And it was done:
> https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b0dbc93998a90/libavcodec/qsvenc.c#L376

That is probably helpful, but the issue I try to explain is unrelated
to the brokenness of the option:
Now, in some cases FFmpeg shows the option and in other cases
it does not. I believe that instead, the option should always be
shown, even if it does not work.

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add photocd decoder

[Carl Eugen Hoyos]

2018-12-22 21:32 GMT+01:00, Paul B Mahol :
> On 12/22/18, Steinar H. Gunderson  wrote:
>> On Sat, Dec 22, 2018 at 09:18:11PM +0100, Paul B Mahol wrote:
>>> Unacceptable, I'm not adding another yuv420p variant.
>>
>> Well, if returning YCC as YCC is unacceptable, and converting YCC to RGB
>> is
>> unacceptable, I believe your only choices are:
>>
>>   1. Try to convert YCC to Y'CbCr ignoring the gamma curve, which will
>> return
>>  images that look wrong and cannot be repaired by reasonable means.
>>   2. Return YCC mislabeled as something else, which will look even more
>> wrong.
>>   3. Don't include PhotoCD support in FFmpeg.
>>
>
> 4. Leave user to do conversion as he wish.

Could you commit something with "-strict experimental"?

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:06 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [FFmpeg-cvslog] lavc/qsvenc: add VDENC
> support for H264
> 
> 2019-01-10 14:51 GMT+01:00, Linjie Fu :
> 
> > +#if QSV_HAVE_VDENC
> > +{ "low_power", "enable low power mode(experimental: many
> > +limitations by
> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> > AV_OPT_TYPE_BOOL, {
> > .i64 =  0 }, 0, 1, VE},
> > +#endif
> 
> This seems wrong to me: The visibility of an option should probably not
> depend on configuration details (the effect can of course depend on many
> details).
> 
> Carl Eugen

That's is just a remind that this feature has some limitations. The configures 
are just to make driver to support this feature.
In ffmpeg level, the only thing we should do IMHO is to query MSDK/Driver 
capability and report an error message if not supported.
And it was done: 
https://github.com/FFmpeg/FFmpeg/blob/395e8a53fa0266f26581f3e9752b0dbc93998a90/libavcodec/qsvenc.c#L376
 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images

[Carl Eugen Hoyos]

2019-01-11 2:55 GMT+01:00, Carl Eugen Hoyos :
> Hi!
>
> Attached patch fixes ticket #6797, please comment.

New patch with 16bit support attached.

Please comment, Carl Eugen
From 5f879539ee7fecd57bd3de9f7c6363d9b7779b5b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 11 Jan 2019 03:20:38 +0100
Subject: [PATCH] lavc/psd: Support CMYK images.

Based on a05635e by Michael Niedermayer.

Fixes ticket #6797.
---
 libavcodec/psd.c |   84 ++
 1 file changed, 84 insertions(+)

diff --git a/libavcodec/psd.c b/libavcodec/psd.c
index 4381447..a31f738 100644
--- a/libavcodec/psd.c
+++ b/libavcodec/psd.c
@@ -337,6 +337,30 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 }
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
 break;
+case PSD_CMYK:
+if (s->channel_count == 4) {
+if (s->channel_depth == 8) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP;
+} else if (s->channel_depth == 16) {
+avctx->pix_fmt = AV_PIX_FMT_GBRP16BE;
+} else {
+avpriv_report_missing_feature(avctx, "channel depth %d for cmyk", s->channel_depth);
+return AVERROR_PATCHWELCOME;
+}
+} else if (s->channel_count == 5) {
+if (s->channel_depth == 8) {
+avctx->pix_fmt = AV_PIX_FMT_GBRAP;
+} else if (s->channel_depth == 16) {
+avctx->pix_fmt = AV_PIX_FMT_GBRAP16BE;
+} else {
+avpriv_report_missing_feature(avctx, "channel depth %d for cmyk", s->channel_depth);
+return AVERROR_PATCHWELCOME;
+}
+} else {
+avpriv_report_missing_feature(avctx, "channel count %d for cmyk", s->channel_count);
+return AVERROR_PATCHWELCOME;
+}
+break;
 case PSD_RGB:
 if (s->channel_count == 3) {
 if (s->channel_depth == 8) {
@@ -435,6 +459,66 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 }
 }
 }
+} else if (s->color_mode == PSD_CMYK) {
+uint8_t *dst[4] = { picture->data[0], picture->data[1], picture->data[2], picture->data[3] };
+const uint8_t *src[5] = { ptr_data };
+src[1] = src[0] + s->line_size * s->height;
+src[2] = src[1] + s->line_size * s->height;
+src[3] = src[2] + s->line_size * s->height;
+src[4] = src[3] + s->line_size * s->height;
+if (s->channel_depth == 8) {
+for (y = 0; y < s->height; y++) {
+for (x = 0; x < s->width; x++) {
+int k = src[3][x];
+int r = src[0][x] * k;
+int g = src[1][x] * k;
+int b = src[2][x] * k;
+dst[0][x] = g * 257 >> 16;
+dst[1][x] = b * 257 >> 16;
+dst[2][x] = r * 257 >> 16;
+}
+dst[0] += picture->linesize[0];
+dst[1] += picture->linesize[1];
+dst[2] += picture->linesize[2];
+src[0] += s->line_size;
+src[1] += s->line_size;
+src[2] += s->line_size;
+src[3] += s->line_size;
+}
+if (avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
+for (y = 0; y < s->height; y++) {
+memcpy(dst[3], src[4], s->line_size);
+src[4] += s->line_size;
+dst[3] += picture->linesize[3];
+}
+}
+} else {
+for (y = 0; y < s->height; y++) {
+for (x = 0; x < s->width; x++) {
+int64_t k = AV_RB16([3][x * 2]);
+int64_t r = AV_RB16([0][x * 2]) * k;
+int64_t g = AV_RB16([1][x * 2]) * k;
+int64_t b = AV_RB16([2][x * 2]) * k;
+AV_WB16([0][x * 2], g * 65537 >> 32);
+AV_WB16([1][x * 2], b * 65537 >> 32);
+AV_WB16([2][x * 2], r * 65537 >> 32);
+}
+dst[0] += picture->linesize[0];
+dst[1] += picture->linesize[1];
+dst[2] += picture->linesize[2];
+src[0] += s->line_size;
+src[1] += s->line_size;
+src[2] += s->line_size;
+src[3] += s->line_size;
+}
+if (avctx->pix_fmt == AV_PIX_FMT_GBRAP16BE) {
+for (y = 0; y < s->height; y++) {
+memcpy(dst[3], src[4], s->line_size);
+src[4] += s->line_size;
+dst[3] += picture->linesize[3];
+}
+}
+}
 } else {/* Planar */
 if (s->channel_count == 1)/* gray 8 or gray 16be */
 eq_channel[0] = 0;/* assign first channel, to first plane */
-- 
1.7.10.4

___

[FFmpeg-devel] [PATCH]lavc/psd: Support CMYK images

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #6797, please comment.

Carl Eugen
From f0d1c43a791f44eee5ae3174baf367a73e59283e Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Fri, 11 Jan 2019 02:53:06 +0100
Subject: [PATCH] lavc/psd: Support CMYK images.

Fixes ticket #6797.
---
 libavcodec/psd.c |   43 +++
 1 file changed, 43 insertions(+)

diff --git a/libavcodec/psd.c b/libavcodec/psd.c
index 4381447..200e3ad 100644
--- a/libavcodec/psd.c
+++ b/libavcodec/psd.c
@@ -337,6 +337,19 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 }
 avctx->pix_fmt = AV_PIX_FMT_PAL8;
 break;
+case PSD_CMYK:
+if (s->channel_count == 5) {
+if (s->channel_depth == 8) {
+avctx->pix_fmt = AV_PIX_FMT_GBRAP;
+} else {
+avpriv_report_missing_feature(avctx, "channel depth %d for cmyk", s->channel_depth);
+return AVERROR_PATCHWELCOME;
+}
+} else {
+avpriv_report_missing_feature(avctx, "channel count %d for cmyk", s->channel_count);
+return AVERROR_PATCHWELCOME;
+}
+break;
 case PSD_RGB:
 if (s->channel_count == 3) {
 if (s->channel_depth == 8) {
@@ -435,6 +448,36 @@ static int decode_frame(AVCodecContext *avctx, void *data,
 }
 }
 }
+} else if (s->color_mode == PSD_CMYK && avctx->pix_fmt == AV_PIX_FMT_GBRAP) {
+uint8_t *dst[4] = { picture->data[0], picture->data[1], picture->data[2], picture->data[3] };
+const uint8_t *src[5] = { ptr_data };
+src[1] = src[0] + s->line_size * s->height;
+src[2] = src[1] + s->line_size * s->height;
+src[3] = src[2] + s->line_size * s->height;
+src[4] = src[3] + s->line_size * s->height;
+for (y = 0; y < s->height; y++) {
+for (x = 0; x < s->width; x++) {
+int k = src[3][x];
+int r = src[0][x] * k;
+int g = src[1][x] * k;
+int b = src[2][x] * k;
+dst[0][x] = g * 257 >> 16;
+dst[1][x] = b * 257 >> 16;
+dst[2][x] = r * 257 >> 16;
+}
+dst[0] += picture->linesize[0];
+dst[1] += picture->linesize[1];
+dst[2] += picture->linesize[2];
+src[0] += s->line_size;
+src[1] += s->line_size;
+src[2] += s->line_size;
+src[3] += s->line_size;
+}
+for (y = 0; y < s->height; y++) {
+memcpy(dst[3], src[4], s->line_size);
+src[4] += s->line_size;
+dst[3] += picture->linesize[3];
+}
 } else {/* Planar */
 if (s->channel_count == 1)/* gray 8 or gray 16be */
 eq_channel[0] = 0;/* assign first channel, to first plane */
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 8:54 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support
> for ROI-based encoding
> 
> 2019-01-11 1:37 GMT+01:00, Guo, Yejun :
> 
> >> 2019-01-10 9:54 GMT+01:00, Guo, Yejun :
> >>
> >> > +roi = (AVRegionOfInterest*)((char*)roi +
> >> > roi->self_size);
> >>
> >> Isn't this roi++?
> >> If yes, please change this.
> >
> > no, it's not roi++, the reason is that struct AVRegionOfInterest might
> > be extended, so to keep ABI compatible, we add the 'self_size'.  It is
> > discussed in V4 comments.
> 
> So after AVRegionOfInterest was extended, you as a user who had compiled
> his application against old libavcodec will use new libavcodec (with the
> extension) and it will be guaranteed that libx264 will still get the correct
> information although only the part of the struct before the extension was
> filled?
> Does this guarantee really help?

yes, I think it helps. otherwise, it becomes a possible ABI issue.

> 
> >> I also wonder if the wording (elsewhere) of "returns EINVAL if size
> >> is zero" is correct: Shouldn't it be "size must be >0"
> >
> > self_size is uint32_t, it is > 0 if not zero.
> 
> The comment I saw is in another file (probably another patch), sorry if this 
> is
> confusing (I also find it confusing).
> I will hopefully not be affected by the documentation, I just wanted to point
> out that the wording is misleading imo, because structs do not return errors.

I see, it is in frame.h of patch 1/2.

imho, current wording is not misleading, the wording exactly matches the code, 
while the code is acceptable.
There is also an explicit note (very close these wording) that the correct 
value should be sizeof(AVRegionOfInterest).

Regarding "structs do not return errors": 

> or similar? A struct can hardly return an error, no?
it is caller's responsibility to set the value to be sizeof(AVRegionOfInterest).
There will be an error returned if the caller does not set it explicitly.

> 
> 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

[FFmpeg-devel] [PATCH] avcodec/nuv: add FF_CODEC_CAP_INIT_CLEANUP

[Michael Niedermayer]

Fixes: memleak
Fixes: 
12244/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_NUV_fuzzer-5099447273390080

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
---
 libavcodec/nuv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavcodec/nuv.c b/libavcodec/nuv.c
index 32ed65899b..75b14bce5b 100644
--- a/libavcodec/nuv.c
+++ b/libavcodec/nuv.c
@@ -365,4 +365,5 @@ AVCodec ff_nuv_decoder = {
 .close  = decode_end,
 .decode = decode_frame,
 .capabilities   = AV_CODEC_CAP_DR1,
+.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 };
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

[Carl Eugen Hoyos]

2019-01-11 1:37 GMT+01:00, Guo, Yejun :

>> 2019-01-10 9:54 GMT+01:00, Guo, Yejun :
>>
>> > +roi = (AVRegionOfInterest*)((char*)roi +
>> > roi->self_size);
>>
>> Isn't this roi++?
>> If yes, please change this.
>
> no, it's not roi++, the reason is that struct AVRegionOfInterest might be
> extended,
> so to keep ABI compatible, we add the 'self_size'.  It is discussed in V4
> comments.

So after AVRegionOfInterest was extended, you as a user who had
compiled his application against old libavcodec will use new libavcodec
(with the extension) and it will be guaranteed that libx264 will still get
the correct information although only the part of the struct before the
extension was filled?
Does this guarantee really help?

>> I also wonder if the wording (elsewhere) of "returns EINVAL if
>> size is zero" is correct: Shouldn't it be "size must be >0"
>
> self_size is uint32_t, it is > 0 if not zero.

The comment I saw is in another file (probably another patch),
sorry if this is confusing (I also find it confusing).
I will hopefully not be affected by the documentation, I just wanted
to point out that the wording is misleading imo, because structs
do not return errors.

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

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

[Guo, Yejun]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Friday, January 11, 2019 1:19 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support
> for ROI-based encoding
> 
> 2019-01-10 9:54 GMT+01:00, Guo, Yejun :
> 
> > +roi = (AVRegionOfInterest*)((char*)roi +
> > roi->self_size);
> 
> Isn't this roi++?
> If yes, please change this.

no, it's not roi++, the reason is that struct AVRegionOfInterest might be 
extended,
so to keep ABI compatible, we add the 'self_size'.  It is discussed in V4 
comments.

> 
> I also wonder if the wording (elsewhere) of "returns EINVAL if size is zero" 
> is
> correct: Shouldn't it be "size must be >0"

self_size is uint32_t, it is > 0 if not zero.  


> or similar? A struct can hardly return an error, no?

it is caller's responsibility to set the value to be sizeof(AVRegionOfInterest).
There will be an error if the caller does not set it explicitly.

> 
> Sorry for the late comment, 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]lavc: Allow very high bitrates in AVCPBProperties after next version bump

[James Almer]

On 1/10/2019 6:27 PM, Carl Eugen Hoyos wrote:
> Hi!
> 
> I don't know how urgent this is and how easily this can be triggered
> with AVCPBProperties but we had issues with bitrates > INT32MAX in the
> past, so looking at this code before realizing the qsv bitrate issue
> is Intel-related I thought this patch cannot hurt.
> 
> Please comment, Carl Eugen

Probalby correct. bitrate fields in AVCodecContext are all int64_t, and
AVCPBProperties fields are usually set to those.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] checkasm/af_afir: relax the max allowed absolute difference

[James Almer]

Should fix failures on x86_32.

Signed-off-by: James Almer 
---
 tests/checkasm/af_afir.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/af_afir.c b/tests/checkasm/af_afir.c
index 54e2f68d6c..e3fb76e8e0 100644
--- a/tests/checkasm/af_afir.c
+++ b/tests/checkasm/af_afir.c
@@ -53,7 +53,7 @@ static void test_fcmul_add(const float *src0, const float 
*src1, const float *sr
 call_ref(cdst, src1, src2, LEN);
 call_new(odst, src1, src2, LEN);
 for (i = 0; i <= LEN*2; i++) {
-if (!float_near_abs_eps(cdst[i], odst[i], FLT_EPSILON)) {
+if (!float_near_abs_eps(cdst[i], odst[i], 6.2e-05)) {
 fprintf(stderr, "%d: %- .12f - %- .12f = % .12g\n",
 i, cdst[i], odst[i], cdst[i] - odst[i]);
 fail();
-- 
2.20.1

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

Re: [FFmpeg-devel] [PATCH]lavc/libaomenc: Support lossless encoding

[Carl Eugen Hoyos]

2019-01-10 23:35 GMT+01:00, Rostislav Pehlivanov :
> On Thu, 10 Jan 2019 at 20:59, Carl Eugen Hoyos  wrote:
>
>> Hi!
>>
>> Attached patch fixes ticket #7600.

> You can already do that via -b:v 0 -crf 0, same as with libvpx, can't you?

Then why does libvpx have an undeprecated option "lossless"?

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

Re: [FFmpeg-devel] [PATCH]lavc/libaomenc: Support lossless encoding

[Rostislav Pehlivanov]

On Thu, 10 Jan 2019 at 20:59, Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch fixes ticket #7600.
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


You can already do that via -b:v 0 -crf 0, same as with libvpx, can't you?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k

[Carl Eugen Hoyos]

2019-01-10 22:32 GMT+01:00, Eoff, Ullysses A :
> We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate.

Sadly, the rules here forbid an answer.
;-)

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

Re: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k

[Eoff, Ullysses A]

We should use mfxInfoMFX::BRCParamMultiplier to handle high bitrate.  See my 
new comment in #7663

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
> Eugen Hoyos
> Sent: Thursday, January 10, 2019 12:53 PM
> To: FFmpeg development discussions and patches 
> Subject: [FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it 
> to 65535k
> 
> Hi!
> 
> Attached untested patch tries to limit the effects of setting a high
> bitrate for qsv.
> Works around ticket #7663.
> 
> Please comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH]lavc: Allow very high bitrates in AVCPBProperties after next version bump

[Carl Eugen Hoyos]

Hi!

I don't know how urgent this is and how easily this can be triggered
with AVCPBProperties but we had issues with bitrates > INT32MAX in the
past, so looking at this code before realizing the qsv bitrate issue
is Intel-related I thought this patch cannot hurt.

Please comment, Carl Eugen
From 64af64cd883c7f6957ced8f24c50b5c5c4821f61 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 10 Jan 2019 22:23:39 +0100
Subject: [PATCH] lavc: Allow very high bitrates in AVCPBProperties after next
 version bump.

---
 libavcodec/avcodec.h |   12 
 libavcodec/version.h |3 +++
 2 files changed, 15 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 92567ec..4414853 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1118,17 +1118,29 @@ typedef struct AVCPBProperties {
  * Maximum bitrate of the stream, in bits per second.
  * Zero if unknown or unspecified.
  */
+#if FF_API_UNSANITIZED_BITRATES
 int max_bitrate;
+#else
+int64_t max_bitrate;
+#endif
 /**
  * Minimum bitrate of the stream, in bits per second.
  * Zero if unknown or unspecified.
  */
+#if FF_API_UNSANITIZED_BITRATES
 int min_bitrate;
+#else
+int64_t min_bitrate;
+#endif
 /**
  * Average bitrate of the stream, in bits per second.
  * Zero if unknown or unspecified.
  */
+#if FF_API_UNSANITIZED_BITRATES
 int avg_bitrate;
+#else
+int64_t avg_bitrate;
+#endif
 
 /**
  * The size of the buffer to which the ratecontrol is applied, in bits.
diff --git a/libavcodec/version.h b/libavcodec/version.h
index ed56a1e..d2c0b31 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -132,6 +132,9 @@
 #ifndef FF_API_NEXT
 #define FF_API_NEXT  (LIBAVCODEC_VERSION_MAJOR < 59)
 #endif
+#ifndef FF_API_UNSANITIZED_BITRATES
+#define FF_API_UNSANITIZED_BITRATES (LIBAVCODEC_VERSION_MAJOR < 59)
+#endif
 
 
 #endif /* AVCODEC_VERSION_H */
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavc/libaomenc: Support lossless encoding

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #7600.

Please comment, Carl Eugen
From 90492e635c461f328a18cb6a55a71206f9cd5aeb Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 10 Jan 2019 21:56:28 +0100
Subject: [PATCH] lavc/libaomenc: Support lossless encoding.

Tested-by: Ewout ter Hoeven
---
 libavcodec/libaomenc.c |4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
index faec61c..244c71a 100644
--- a/libavcodec/libaomenc.c
+++ b/libavcodec/libaomenc.c
@@ -79,6 +79,7 @@ typedef struct AOMEncoderContext {
 aom_superblock_size_t superblock_size;
 int uniform_tiles;
 int row_mt;
+int lossless;
 } AOMContext;
 
 static const char *const ctlidstr[] = {
@@ -96,6 +97,7 @@ static const char *const ctlidstr[] = {
 #ifdef AOM_CTRL_AV1E_SET_ROW_MT
 [AV1E_SET_ROW_MT]   = "AV1E_SET_ROW_MT",
 #endif
+[AV1E_SET_LOSSLESS] = "AV1E_SET_LOSSLESS",
 };
 
 static av_cold void log_encoder_error(AVCodecContext *avctx, const char *desc)
@@ -662,6 +664,7 @@ static av_cold int aom_init(AVCodecContext *avctx,
 #ifdef AOM_CTRL_AV1E_SET_ROW_MT
 codecctl_int(avctx, AV1E_SET_ROW_MT, ctx->row_mt);
 #endif
+codecctl_int(avctx, AV1E_SET_LOSSLESS, ctx->lossless);
 
 // provide dummy value to initialize wrapper, values will be updated each _encode()
 aom_img_wrap(>rawimg, img_fmt, avctx->width, avctx->height, 1,
@@ -997,6 +1000,7 @@ static const AVOption options[] = {
 { "tile-columns", "Log2 of number of tile columns to use", OFFSET(tile_cols_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
 { "tile-rows","Log2 of number of tile rows to use",OFFSET(tile_rows_log2), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},
 { "row-mt",   "Enable row based multi-threading",  OFFSET(row_mt), AV_OPT_TYPE_BOOL, {.i64 = 0},  0, 1, VE},
+{ "lossless", "Lossless mode", OFFSET(lossless),   AV_OPT_TYPE_BOOL, {.i64 = 0},  0, 1, VE},
 { NULL }
 };
 
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH]lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k

[Carl Eugen Hoyos]

Hi!

Attached untested patch tries to limit the effects of setting a high
bitrate for qsv.
Works around ticket #7663.

Please comment, Carl Eugen
From 9c51b260a0c65fe7fbf18ac5235f3336be66502c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Thu, 10 Jan 2019 21:50:04 +0100
Subject: [PATCH] lavc/qsvenc: Clip the bitrate, Intel limits it to 65535k.

Work-around for ticket #7663.
---
 libavcodec/qsvenc.c |8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e3b5a72..e7083eb 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -558,10 +558,10 @@ static int init_video_param(AVCodecContext *avctx, QSVEncContext *q)
 #if QSV_HAVE_VCM
 case MFX_RATECONTROL_VCM:
 #endif
-q->param.mfx.BufferSizeInKB   = avctx->rc_buffer_size / 8000;
-q->param.mfx.InitialDelayInKB = avctx->rc_initial_buffer_occupancy / 1000;
-q->param.mfx.TargetKbps   = avctx->bit_rate / 1000;
-q->param.mfx.MaxKbps  = avctx->rc_max_rate / 1000;
+q->param.mfx.BufferSizeInKB   = FFMIN(UINT16_MAX, avctx->rc_buffer_size / 8000);
+q->param.mfx.InitialDelayInKB = FFMIN(UINT16_MAX, avctx->rc_initial_buffer_occupancy / 1000);
+q->param.mfx.TargetKbps   = FFMIN(UINT16_MAX, avctx->bit_rate / 1000);
+q->param.mfx.MaxKbps  = FFMIN(UINT16_MAX, avctx->rc_max_rate / 1000);
 break;
 case MFX_RATECONTROL_CQP:
 quant = avctx->global_quality / FF_QP2LAMBDA;
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH] Mark .rodata section as read only in COFF object file

[Tom Tan]

.rodata directive from GAS assembly produces .rodata as read/write for COFF
object file by default (object file format for Windows), but read only for
ELF. This change marks it as read only explicitly for COFF.

The issue happens when building Chromium for Windows ARM64, with FFmpeg.

---
 libavutil/aarch64/asm.S | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavutil/aarch64/asm.S b/libavutil/aarch64/asm.S
index fd32bf784e..abc2f69f43 100644
--- a/libavutil/aarch64/asm.S
+++ b/libavutil/aarch64/asm.S
@@ -63,6 +63,8 @@ ELF .size   \name, . - \name
 .else
 .section.rodata
 .endif
+#elif defined(_WIN32)
+.section.rodata, "r"
 #elif !defined(__MACH__)
 .section.rodata
 #else
-- 
2.15.1.gvfs.2.39.g03d366a


0001-Mark-.rodata-section-as-read-only-in-COFF-object-fil.patch
Description: 0001-Mark-.rodata-section-as-read-only-in-COFF-object-fil.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] delogo filter: new "uglarm" interpolation mode added

[Uwe Freese]

Hello,

just a kind reminder. - What is the next step, is there anything more I 
should improve, check, modify,...?


For me, the filter works as intended.

@Nicolas: Can you answer my remaining three questions below, please?

Regards,
Uwe

Am 02.01.19 um 23:34 schrieb Uwe Freese:

Hello,

Here's a new version of the patch. Changes:


- My last version didn't compile because of moving code to config_input. 
Don't know why I didn't see this, sorry.
   I moved the code back to filter_frame because of two reasons. First, 
I need the "sar" to init my tables and it seems I need the "AVFrame *in" 
parameter for that. Secondly, I also need *desc, hsub0, vsub0, plane, 
logo_w, logo_h which means much duplicated code or creation of functions.


- Corrected use of sizeof in av_malloc_array

- changed calculation of the distance regarding exponent, avoid sqrt, 
use "aspect2" variable


- use double *uglarmtable[MAX_SUB + 1][MAX_SUB + 1], 
*uglarmweightsum[MAX_SUB + 1][MAX_SUB + 1]; (instead per 1-dimensional 
array for the planes)


- unconditional av_freep in uninit

- used the alternative loops as suggested by Nicolas (thanks)


Remaining points / answers / questions:

Am 02.01.19 um 16:25 schrieb Nicolas George:

+    interp = (uint64_t)(interpd /
+    uglarmweightsum[(x - logo_x1) - 1 + (y - 
logo_y1 - 1) * (logo_w - 2)]);

The cast to uint64_t seems suspicious. Can you explain?

Every pixel value of the inner logo area is an integer. Only for the
calculation of the weighted average, all values use floats. At the 
end, it

is rounded (truncated) to an int.

int and uint64_t are not the same thing. Why uint64_t?


"interp" was defined as uint64_t in the original code.

Do you see a problem here? Then let us know.


pow(x * x * aspect2 + y * y, exponent / 2);
Hm. Again, I'm unsure if this "optimization" is worth it. I wouldn't 
do this

normally.

In this particular instance, definitely yes. Compilers have very little
latitude to optimize floating point operations, and they will certainly
not optimize mathematical functions based on subtle arithmetic
properties. This is a C compiler, not a TI-89.


We have obviously distinct opinions here. I would leave the code because 
it's easier to understand (as written), and it runs once, taking maybe 
some microseconds more for a usual conversion of video taking seconds to 
hours.


But I have no problem changing it. - Done.


Question to "aspect2": is ^2 not good (slow) or something, or why not 
directly use


double aspect2 = ((double)sar.num / sar.den) ^ 2;



[...]
 av_assert2(table_t == uglarmtable + (logo_w - x) + table_stride * 
y);
 av_assert2(table_b == uglarmtable + (logo_w - x) + table_stride * 
(logo_h - y - 1));
 av_assert2(table_l == uglarmtable + table_stride * (logo_h - y - 
1) + x);
 av_assert2(table_r == uglarmtable + table_stride * (logo_h - y - 
1) + logo_w - x - 1;


That makes more lines, but the lines are way simpler: no tricky
arithmetic, all blocks almost identical, with the changes easy to see
and understand.


I took over these alternative loops for the calculations.

Question to the assert: Is this useful (compared to the running time)? I 
mean, basically it is the same expression as over the loops, only x and 
y are different by the amount the loops are counting them up. I wouldn't 
say that it is probable that one makes an error coding the loop counter 
or that it doesn't somehow function.


Is there another thing which this assert checks that I didn't see?

Regards,
Uwe


___
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] Video codec design for very low-end decoder

[Carl Eugen Hoyos]

2019-01-07 18:37 GMT+01:00, Ronald S. Bultje :
> Hi,
>
> On Mon, Jan 7, 2019 at 12:22 PM Lauri Kasanen  wrote:
>
>> On Mon, 7 Jan 2019 12:02:58 -0500
>> "Ronald S. Bultje"  wrote:
>>
>> > Have you considered vp8? It may sound weird but this is basically what
>> vp8
>> > was great at: being really simple to decode.
>>
>> VP8 has a reputation of being slow, so I didn't consider it. Benchmarks
>> show it as decoding slower than h264.
>>
>
> It is faster than h264 when comparing ffh264 vs. ffvp8:
>
> https://blogs.gnome.org/rbultje/files/2014/02/sintel_decspeed.png

Are the relations identical without asm optimizations?

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

Re: [FFmpeg-devel] [PATCH] lavc: vt_hevc: fix crash if vps_list[0] or sps_list[0] are null

[Aman Gupta]

On Wed, Jan 9, 2019 at 6:32 PM Rodger Combs  wrote:

> Instead of assuming id 0 is used, use the same logic as used for PPS,
> where all available entries in the list are emitted.
>

Patch LGTM. Apart from the SEGV fix, this probably helps VideoToolbox
decode certain types of samples with multiple VPS/SPS correctly.

I think I started a similar patch at once point but it turned into a mess.
The use of macros here helps maintain some sanity.

Will commit in a few days if no one objects.

Aman


> ---
>  libavcodec/videotoolbox.c | 86 ++-
>  1 file changed, 40 insertions(+), 46 deletions(-)
>
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index da7236f100..fb3501f413 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -176,26 +176,31 @@ CFDataRef
> ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
>  CFDataRef ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  {
>  HEVCContext *h = avctx->priv_data;
> -const HEVCVPS *vps = (const HEVCVPS *)h->ps.vps_list[0]->data;
> -const HEVCSPS *sps = (const HEVCSPS *)h->ps.sps_list[0]->data;
> -int i, num_pps = 0;
> +int i, num_vps = 0, num_sps = 0, num_pps = 0;
> +const HEVCVPS *vps = h->ps.vps;
> +const HEVCSPS *sps = h->ps.sps;
>  const HEVCPPS *pps = h->ps.pps;
>  PTLCommon ptlc = vps->ptl.general_ptl;
>  VUI vui = sps->vui;
>  uint8_t parallelismType;
>  CFDataRef data = NULL;
>  uint8_t *p;
> -int vt_extradata_size = 23 + 5 + vps->data_size + 5 + sps->data_size
> + 3;
> +int vt_extradata_size = 23 + 3 + 3 + 3;
>  uint8_t *vt_extradata;
>
> -for (i = 0; i < HEVC_MAX_PPS_COUNT; i++) {
> -if (h->ps.pps_list[i]) {
> -const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
> -vt_extradata_size += 2 + pps->data_size;
> -num_pps++;
> -}
> +#define COUNT_SIZE_PS(T, t) \
> +for (i = 0; i < HEVC_MAX_##T##PS_COUNT; i++) { \
> +if (h->ps.t##ps_list[i]) { \
> +const HEVC##T##PS *lps = (const HEVC##T##PS
> *)h->ps.t##ps_list[i]->data; \
> +vt_extradata_size += 2 + lps->data_size; \
> +num_##t##ps++; \
> +} \
>  }
>
> +COUNT_SIZE_PS(V, v)
> +COUNT_SIZE_PS(S, s)
> +COUNT_SIZE_PS(P, p)
> +
>  vt_extradata = av_malloc(vt_extradata_size);
>  if (!vt_extradata)
>  return NULL;
> @@ -286,44 +291,33 @@ CFDataRef
> ff_videotoolbox_hvcc_extradata_create(AVCodecContext *avctx)
>  AV_W8(p + 22, 3);
>
>  p += 23;
> -/* vps */
> -/*
> - * bit(1) array_completeness;
> - * unsigned int(1) reserved = 0;
> - * unsigned int(6) NAL_unit_type;
> - */
> -AV_W8(p, 1 << 7 |
> - HEVC_NAL_VPS & 0x3f);
> -/* unsigned int(16) numNalus; */
> -AV_WB16(p + 1, 1);
> -/* unsigned int(16) nalUnitLength; */
> -AV_WB16(p + 3, vps->data_size);
> -/* bit(8*nalUnitLength) nalUnit; */
> -memcpy(p + 5, vps->data, vps->data_size);
> -p += 5 + vps->data_size;
> -
> -/* sps */
> -AV_W8(p, 1 << 7 |
> - HEVC_NAL_SPS & 0x3f);
> -AV_WB16(p + 1, 1);
> -AV_WB16(p + 3, sps->data_size);
> -memcpy(p + 5, sps->data, sps->data_size);
> -p += 5 + sps->data_size;
> -
> -/* pps */
> -AV_W8(p, 1 << 7 |
> - HEVC_NAL_PPS & 0x3f);
> -AV_WB16(p + 1, num_pps);
> -p += 3;
> -for (i = 0; i < HEVC_MAX_PPS_COUNT; i++) {
> -if (h->ps.pps_list[i]) {
> -const HEVCPPS *pps = (const HEVCPPS *)h->ps.pps_list[i]->data;
> -AV_WB16(p, pps->data_size);
> -memcpy(p + 2, pps->data, pps->data_size);
> -p += 2 + pps->data_size;
> -}
> +
> +#define APPEND_PS(T, t) \
> +/* \
> + * bit(1) array_completeness; \
> + * unsigned int(1) reserved = 0; \
> + * unsigned int(6) NAL_unit_type; \
> + */ \
> +AV_W8(p, 1 << 7 | \
> + HEVC_NAL_##T##PS & 0x3f); \
> +/* unsigned int(16) numNalus; */ \
> +AV_WB16(p + 1, num_##t##ps); \
> +p += 3; \
> +for (i = 0; i < HEVC_MAX_##T##PS_COUNT; i++) { \
> +if (h->ps.t##ps_list[i]) { \
> +const HEVC##T##PS *lps = (const HEVC##T##PS
> *)h->ps.t##ps_list[i]->data; \
> +/* unsigned int(16) nalUnitLength; */ \
> +AV_WB16(p, lps->data_size); \
> +/* bit(8*nalUnitLength) nalUnit; */ \
> +memcpy(p + 2, lps->data, lps->data_size); \
> +p += 2 + lps->data_size; \
> +} \
>  }
>
> +APPEND_PS(V, v)
> +APPEND_PS(S, s)
> +APPEND_PS(P, p)
> +
>  av_assert0(p - vt_extradata == vt_extradata_size);
>
>  data = CFDataCreate(kCFAllocatorDefault, vt_extradata,
> vt_extradata_size);
> --
> 2.19.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection

[Carl Eugen Hoyos]

2019-01-10 18:21 GMT+01:00, Lauri Kasanen :
> On Thu, 10 Jan 2019 18:09:21 +0100
> Carl Eugen Hoyos  wrote:
>
>> >> > -goto out;
>> >>
>> >> This seems like an unrelated change.
>> >
>> > It's necessary. HWCAP appears before HWCAP2 in the array, so if the
>> > code jumps out in HWCAP, it never gets to checking the CAP2 bits like
>> > power8.
>>
>> The next line (that I unfortunately cut) is:
>> } else if (buf[i] == AT_HWCAP2) {
>> indicating afaict that it is only reached if buf[i] is not equal
>> to HWCAP.
>> What do I miss?
>
> The surrounding context is a loop over all bytes:
> for (i = 0; i < count / sizeof(*buf); i += 2) {
>
> While the out: label is after the loop.

Thank you!

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

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

[Carl Eugen Hoyos]

2019-01-10 9:54 GMT+01:00, Guo, Yejun :

> +roi = (AVRegionOfInterest*)((char*)roi +
> roi->self_size);

Isn't this roi++?
If yes, please change this.

I also wonder if the wording (elsewhere) of "returns EINVAL
if size is zero" is correct: Shouldn't it be "size must be >0"
or similar? A struct can hardly return an error, no?

Sorry for the late comment, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection

[Lauri Kasanen]

On Thu, 10 Jan 2019 18:09:21 +0100
Carl Eugen Hoyos  wrote:

> >> > -goto out;
> >>
> >> This seems like an unrelated change.
> >
> > It's necessary. HWCAP appears before HWCAP2 in the array, so if the
> > code jumps out in HWCAP, it never gets to checking the CAP2 bits like
> > power8.
> 
> The next line (that I unfortunately cut) is:
> } else if (buf[i] == AT_HWCAP2) {
> indicating afaict that it is only reached if buf[i] is not equal
> to HWCAP.
> What do I miss?

The surrounding context is a loop over all bytes:
for (i = 0; i < count / sizeof(*buf); i += 2) {

While the out: label is after the loop.

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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Carl Eugen Hoyos]

2019-01-10 9:18 GMT+01:00, Wang, Shaofei :

> Please ignore those commented lines which will be removed in
> the v2 patch, they were referred from previous reap_filters() code.
>
> "if (HAVE_THREADS && !abr_pipeline)" looks better.

> Could you add more about "not work with thread emulation"?

My question is simply "why do you need this condition? If
you disable threads, FFmpeg should still work fine, it simulates
threads using one thread."

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] [FFmpeg-cvslog] lavc/qsvenc: add VDENC support for H264

[Carl Eugen Hoyos]

2019-01-10 14:51 GMT+01:00, Linjie Fu :

> +#if QSV_HAVE_VDENC
> +{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 =  0 }, 0, 1, VE},
> +#endif

This seems wrong to me: The visibility of an option should
probably not depend on configuration details (the effect can
of course depend on many details).

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

Re: [FFmpeg-devel] [PATCH] avformat/http: ignore the string after char '#'

[Carl Eugen Hoyos]

2019-01-10 10:14 GMT+01:00, Liu Steven :
>
>
>> 在 2019年1月10日，下午5:09，Nicolas George  写道：
>>
>> Liu Steven (12019-01-10):
>>> Ok, I get that mean, let me think how to fix that.
>>
>> Do you know why the fragment was there in the first place and what its
>> role was?
>
> I guess that is used for them web browser or player, i will ask that
> infomation from the ticket.

This may not necessarily help, maybe somebody here knows the answer?

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

Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection

[Carl Eugen Hoyos]

2019-01-10 10:45 GMT+01:00, Lauri Kasanen :
> On Wed, 9 Jan 2019 21:55:30 +0100
> Carl Eugen Hoyos  wrote:
>
>> 2019-01-08 10:08 GMT+01:00, Lauri Kasanen :
>> > The existing code was in no released kernel that I can see. The
>> > corrected
>> > code
>> > was added in 3.9.
>> >
>> > Signed-off-by: Lauri Kasanen 
>> > ---
>> >  libavutil/ppc/cpu.c | 10 +-
>> >  1 file changed, 5 insertions(+), 5 deletions(-)
>> >
>> > diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
>> > index 7bb7cd8..b022149 100644
>> > --- a/libavutil/ppc/cpu.c
>> > +++ b/libavutil/ppc/cpu.c
>> > @@ -93,13 +93,13 @@ int ff_get_cpu_flags_ppc(void)
>> >  if (buf[i + 1] & PPC_FEATURE_HAS_VSX)
>> >  ret |= AV_CPU_FLAG_VSX;
>> >  #endif
>> > -#ifdef PPC_FEATURE_ARCH_2_07
>> > -if (buf[i + 1] & PPC_FEATURE_HAS_POWER8)
>> > -ret |= AV_CPU_FLAG_POWER8;
>> > -#endif
>> >  if (ret & AV_CPU_FLAG_VSX)
>> >  av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
>>
>> > -goto out;
>>
>> This seems like an unrelated change.
>
> It's necessary. HWCAP appears before HWCAP2 in the array, so if the
> code jumps out in HWCAP, it never gets to checking the CAP2 bits like
> power8.

The next line (that I unfortunately cut) is:
} else if (buf[i] == AT_HWCAP2) {
indicating afaict that it is only reached if buf[i] is not equal
to HWCAP.
What do I miss?

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

Re: [FFmpeg-devel] [PATCH v3] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

[Carl Eugen Hoyos]

2019-01-10 10:48 GMT+01:00, Lauri Kasanen :
> On Wed, 9 Jan 2019 22:26:25 +0100
> Carl Eugen Hoyos  wrote:
>
>> > +#ifdef __GNUC__
>> > +// GCC does not support vmuluwm yet. Bug open.
>> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32l),
>> > "v"(vfilter[j]));
>> > +vleft = vec_add(vleft, vtmp);
>> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32r),
>> > "v"(vfilter[j]));
>> > +vright = vec_add(vright, vtmp);
>> > +#else
>> > +// No idea which compilers this works in, untested. Copied
>> > from
>> > libsimdpp
>> > +vtmp = vec_vmuluwm(vin32l, vfilter[j]);
>> > +vleft = vec_add(vleft, vtmp);
>> > +vtmp = vec_vmuluwm(vin32r, vfilter[j]);
>> > +vright = vec_add(vright, vtmp);
>> > +#endif
>>
>> Is there no xlc installed on your test system?
>> I suspect an earlier patch from you already
>> broke xlc compilation...
>
> No, I don't really care about proprietary compilers.

Ok, just wondering which other compilers your comment
above meant...

> You reported previously that xlc created invalid code anyway?

True, I forgot.

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

Re: [FFmpeg-devel] [PATCH] api-h264-slice-test: fix arguments and help

[Moritz Barsnick]

Rafaël Carré wrote:

> I can't use git send-email with google so I had to copy paste the patch
> into thunderbird.

You can use "git format-patch" and attach the created patch file in Thunderbird.

$ git format-patch HEAD^
or
$ git format-patch 
556d7d9e3b09157555310466a47e25a9ebfd8f4e^..556d7d9e3b09157555310466a47e25a9ebfd8f4e

https://www.ffmpeg.org/developer.html#toc-Submitting-patches-1

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

Re: [FFmpeg-devel] [PATCH, v5] lavc/qsvenc: add VDENC support for H264

[Li, Zhong]

> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Linjie Fu
> Sent: Thursday, November 29, 2018 2:14 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie 
> Subject: [FFmpeg-devel] [PATCH,v5] lavc/qsvenc: add VDENC support for
> H264
> 
> Add VDENC(lowpower mode) support for QSV H264
> 
> It's an experimental function(like lowpower in vaapi) with some limitations:
> - CBR/VBR require HuC which should be explicitly loaded via i915 module
> parameter(i915.enable_guc=2 for linux kernel version >= 4.16)
> 
> Use option "-low_power 1" to enable VDENC.
> Add in dump_video_param() to show the status of VDENC in runtime log.
> 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: Modify the commit message and option comments, use
> AV_OPT_TYPE_BOOL to replace AV_OPT_TYPE_INT.
> [v3]: Enable H264 VDENC separately.
> [v4]: Add in dump_video_param to show the status of VDENC in runtime log.
> [v5]: Use print_threestate.
> 
>  libavcodec/qsvenc.c  | 7 +++
>  libavcodec/qsvenc.h  | 2 ++
>  libavcodec/qsvenc_h264.c | 3 +++
>  3 files changed, 12 insertions(+)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c index
> 948751daf4..b1ec90c6c6 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -226,6 +226,10 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
>  av_log(avctx, AV_LOG_VERBOSE, "\n");  #endif
> 
> +#if QSV_HAVE_VDENC
> +av_log(avctx, AV_LOG_VERBOSE, "VDENC: %s\n",
> +print_threestate(info->LowPower));
> +#endif
> +
>  #if QSV_VERSION_ATLEAST(1, 8)
>  av_log(avctx, AV_LOG_VERBOSE,
> "RepeatPPS: %s; NumMbPerSlice: %"PRIu16"; LookAheadDS: ",
> @@ -464,6 +468,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
> 
> +#if QSV_HAVE_VDENC
> +q->param.mfx.LowPower   = q->low_power ?
> MFX_CODINGOPTION_ON : MFX_CODINGOPTION_OFF;
> +#endif
>  q->param.mfx.CodecProfile   = q->profile;
>  q->param.mfx.TargetUsage= avctx->compression_level;
>  q->param.mfx.GopPicSize = FFMAX(0, avctx->gop_size);
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h index
> 50cc4267e7..a396aa7d3f 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -44,6 +44,7 @@
>  #define QSV_HAVE_LA QSV_VERSION_ATLEAST(1, 7)
>  #define QSV_HAVE_LA_DS  QSV_VERSION_ATLEAST(1, 8)  #define
> QSV_HAVE_LA_HRD QSV_VERSION_ATLEAST(1, 11)
> +#define QSV_HAVE_VDENC  QSV_VERSION_ATLEAST(1, 15)
> 
>  #if defined(_WIN32) || defined(__CYGWIN__)
>  #define QSV_HAVE_AVBR   QSV_VERSION_ATLEAST(1, 3)
> @@ -162,6 +163,7 @@ typedef struct QSVEncContext {
>  int recovery_point_sei;
> 
>  int a53_cc;
> +int low_power;
> 
>  #if QSV_HAVE_MF
>  int mfmode;
> diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c index
> 07c9d64e6b..40071d805a 100644
> --- a/libavcodec/qsvenc_h264.c
> +++ b/libavcodec/qsvenc_h264.c
> @@ -153,6 +153,9 @@ static const AVOption options[] = {
>  { "off", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_MF_DISABLED }, INT_MIN, INT_MAX, VE, "mfmode" },
>  { "auto"   , NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
> MFX_MF_AUTO }, INT_MIN, INT_MAX, VE, "mfmode" },
>  #endif
> +#if QSV_HAVE_VDENC
> +{ "low_power", "enable low power mode(experimental: many
> +limitations by mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> +AV_OPT_TYPE_BOOL, { .i64 =  0 }, 0, 1, VE}, #endif
> 
>  { NULL },
>  };
> --
> 2.17.1

CQP mode tested, and patch applied since 
https://github.com/Intel-Media-SDK/MediaSDK/issues/1010 has been fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: add support for configuring dlltool

[Andoni Morales]

El mar., 8 ene. 2019 a las 18:49, Derek Buitenhuis (<
derek.buitenh...@gmail.com>) escribió:

> On 08/01/2019 16:35, Andoni Morales wrote:
> > In a multilib toolchain dlltool has to be configured with the correct
> > architecture options.
> > This option allows configuring dlltool this way:
> > --dlltool="x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386"
>
> Unsure why this is needed... we already set -m ($LIBTARGET) for
> dlltool, and dlltool is already properly detected and run when
> you set both --arch, --target-os, and --cross-prefix, even in
> multilib setups as far as I can tell. e.g.:
>
> --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --arch=x86
>

You are correct, that works correctly and there is no need for that patch.

Thanks.

>
> See lines 5206 to 5260, specifically lines 5208 and 5233.
>
> Cheers,
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>


-- 
Andoni Morales Alastruey

LongoMatch:The Digital Coach
http://www.longomatch.com 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] api-h264-slice-test: fix arguments and help

[Rafaël Carré]

On 1/10/19 12:12 PM, Rafaël Carré wrote:

> -fprintf(stderr, "Usage: %sfile>\n", argv[0]);

I can't use git send-email with google so I had to copy paste the patch
into thunderbird.

The 2 lines above probably needs concatenating to apply the patch

> +if (argc < 3) {
> +fprintf(stderr, "Usage: %s  \n", argv[0]);
>  return -1;
>  }
> 

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

[FFmpeg-devel] [PATCH] api-h264-slice-test: fix arguments and help

[Rafaël Carré]

This program only takes 2 arguments
Remove comment that was never right
---
 tests/api/api-h264-slice-test.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/tests/api/api-h264-slice-test.c
b/tests/api/api-h264-slice-test.c
index b893737bca..dee93b8349 100644
--- a/tests/api/api-h264-slice-test.c
+++ b/tests/api/api-h264-slice-test.c
@@ -22,8 +22,6 @@

 #define MAX_SLICES 8

-// ./fate 2 ./crew_cif out.y4m
-
 #include "config.h"

 #include 
@@ -121,8 +119,8 @@ int main(int argc, char **argv)
 int nals = 0, ret = 0;
 char *p;

-if (argc < 4) {
-fprintf(stderr, "Usage: %s   \n", argv[0]);
+if (argc < 3) {
+fprintf(stderr, "Usage: %s  \n", argv[0]);
 return -1;
 }

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

Re: [FFmpeg-devel] Video codec design for very low-end decoder

[Tomas Härdin]

mån 2019-01-07 klockan 15:38 +0200 skrev Lauri Kasanen:
> On Mon, 7 Jan 2019 13:44:56 +0100
> Michael Niedermayer  wrote:
> 
> > > The modern approaches, DCT, FFT, wavelets and such transforms,
> > > are all
> > > likely too slow to decode.
> > 
> > you said it can do mpeg1 and xvid, these are DCT based
> > have you tried H.264 ? (i imagine that might with asm optimizations
> > and avoidance of more complex features like CABAC and the loop
> > filter
> > work maybe, maybe not)
> > also if h.264 with everything disabled works maybe some features
> > can
> > be turned on sometimes like the loop filter for key frames, that 
> > might then help compression ...
> > 
> > and beating an existing codec, while certainly possible might be
> > hard
> 
> According to a 2010 comparison
> https://keyj.emphy.de/video-encoder-comparison/
> x264 constrained baseline (everything off) takes something like 30%
> longer to decode vs xvid at the same rate. Probably more because that
> site used xvid's full features, while I used it "everything off".
> 
> The issue with xvid simple and mpeg1 were that they were slightly too
> slow, and looked too bad. The platform does not have any SIMD, so I
> doubt asm optimizations will help much.
> 
> Cinepak is almost 30 years old, surely it should be possible to match
> the decoding & quality, but at a 5x lower bitrate :P

You could always work yourself up from cinepak, svq*, h261 and all the
other ancient codecs, assuming you've got an ffmpeg build going on your
platform

There might be one or two wavelet based codecs out there worth looking
at. Anything based on the Haar wavelet should decode cheaply, plus you
get dat blocky aesthetic (sentence sponsored by the cinepak gang)

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

[FFmpeg-devel] [PATCH v4] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

[Lauri Kasanen]

./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt 
yuv420p16be \
-s 1920x1728 -f null -vframes 100 -v error -nostats -

9-14 bit funcs get about 6x speedup, 16-bit gets about 15x.
Fate passes, each format tested with an image to video conversion.

Only POWER8 includes 32-bit vector multiplies, so POWER7 is locked out
of the 16-bit function. This includes the vec_mulo/mule functions too,
not just vmuluwm.

yuv420p9le
  12341 UNITS in planarX,  130976 runs, 96 skips
  73752 UNITS in planarX,  131066 runs,  6 skips
yuv420p9be
  12364 UNITS in planarX,  131025 runs, 47 skips
  73001 UNITS in planarX,  131055 runs, 17 skips
yuv420p10le
  12386 UNITS in planarX,  131042 runs, 30 skips
  72735 UNITS in planarX,  131062 runs, 10 skips
yuv420p10be
  12337 UNITS in planarX,  131045 runs, 27 skips
  72734 UNITS in planarX,  131057 runs, 15 skips
yuv420p12le
  12236 UNITS in planarX,  131058 runs, 14 skips
  73029 UNITS in planarX,  131062 runs, 10 skips
yuv420p12be
  12218 UNITS in planarX,  130973 runs, 99 skips
  72402 UNITS in planarX,  131069 runs,  3 skips
yuv420p14le
  12168 UNITS in planarX,  131067 runs,  5 skips
  72480 UNITS in planarX,  131069 runs,  3 skips
yuv420p14be
  12358 UNITS in planarX,  130948 runs,124 skips
  73772 UNITS in planarX,  131063 runs,  9 skips
yuv420p16le
  10439 UNITS in planarX,  130911 runs,161 skips
 157923 UNITS in planarX,  131068 runs,  4 skips
yuv420p16be
  10463 UNITS in planarX,  130874 runs,198 skips
 154405 UNITS in planarX,  131061 runs, 11 skips

Signed-off-by: Lauri Kasanen 
---

v2: Separate macros so that yuv2plane1_16_vsx remains available for power7
v3: Remove accidental tabs, switch to HAVE_POWER8 from configure + runtime check
v4: #if HAVE_POWER8

 libswscale/ppc/swscale_ppc_template.c |   4 +-
 libswscale/ppc/swscale_vsx.c  | 195 +-
 2 files changed, 193 insertions(+), 6 deletions(-)

diff --git a/libswscale/ppc/swscale_ppc_template.c 
b/libswscale/ppc/swscale_ppc_template.c
index 00e4b99..11decab 100644
--- a/libswscale/ppc/swscale_ppc_template.c
+++ b/libswscale/ppc/swscale_ppc_template.c
@@ -21,7 +21,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-static void FUNC(yuv2planeX_16)(const int16_t *filter, int filterSize,
+static void FUNC(yuv2planeX_8_16)(const int16_t *filter, int filterSize,
   const int16_t **src, uint8_t *dest,
   const uint8_t *dither, int offset, int x)
 {
@@ -88,7 +88,7 @@ static void FUNC(yuv2planeX)(const int16_t *filter, int 
filterSize,
 yuv2planeX_u(filter, filterSize, src, dest, dst_u, dither, offset, 0);
 
 for (i = dst_u; i < dstW - 15; i += 16)
-FUNC(yuv2planeX_16)(filter, filterSize, src, dest + i, dither,
+FUNC(yuv2planeX_8_16)(filter, filterSize, src, dest + i, dither,
   offset, i);
 
 yuv2planeX_u(filter, filterSize, src, dest, dstW, dither, offset, i);
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index 70da6ae..12effe2 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -83,6 +83,8 @@
 #include "swscale_ppc_template.c"
 #undef FUNC
 
+#undef vzero
+
 #endif /* !HAVE_BIGENDIAN */
 
 static void yuv2plane1_8_u(const int16_t *src, uint8_t *dest, int dstW,
@@ -180,6 +182,76 @@ static void yuv2plane1_nbps_vsx(const int16_t *src, 
uint16_t *dest, int dstW,
 yuv2plane1_nbps_u(src, dest, dstW, big_endian, output_bits, i);
 }
 
+static void yuv2planeX_nbps_u(const int16_t *filter, int filterSize,
+  const int16_t **src, uint16_t *dest, int dstW,
+  int big_endian, int output_bits, int start)
+{
+int i;
+int shift = 11 + 16 - output_bits;
+
+for (i = start; i < dstW; i++) {
+int val = 1 << (shift - 1);
+int j;
+
+for (j = 0; j < filterSize; j++)
+val += src[j][i] * filter[j];
+
+output_pixel([i], val);
+}
+}
+
+static void yuv2planeX_nbps_vsx(const int16_t *filter, int filterSize,
+const int16_t **src, uint16_t *dest, int dstW,
+int big_endian, int output_bits)
+{
+const int dst_u = -(uintptr_t)dest & 7;
+const int shift = 11 + 16 - output_bits;
+const int add = (1 << (shift - 1));
+const int clip = (1 << output_bits) - 1;
+const uint16_t swap = big_endian ? 8 : 0;
+const vector uint32_t vadd = (vector uint32_t) {add, add, add, add};
+const vector uint32_t vshift = (vector uint32_t) {shift, shift, shift, 
shift};
+const vector uint16_t vswap = (vector uint16_t) {swap, swap, swap, swap, 
swap, swap, swap, swap};
+const vector uint16_t vlargest = (vector uint16_t) {clip, clip, clip, 
clip, clip, clip, clip, clip};
+const vector int16_t vzero = vec_splat_s16(0);

Re: [FFmpeg-devel] [PATCH v3] libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX

[Lauri Kasanen]

On Wed, 9 Jan 2019 22:26:25 +0100
Carl Eugen Hoyos  wrote:

> > +#ifdef __GNUC__
> > +// GCC does not support vmuluwm yet. Bug open.
> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32l),
> > "v"(vfilter[j]));
> > +vleft = vec_add(vleft, vtmp);
> > +__asm__("vmuluwm %0, %1, %2" : "=v"(vtmp) : "v"(vin32r),
> > "v"(vfilter[j]));
> > +vright = vec_add(vright, vtmp);
> > +#else
> > +// No idea which compilers this works in, untested. Copied from
> > libsimdpp
> > +vtmp = vec_vmuluwm(vin32l, vfilter[j]);
> > +vleft = vec_add(vleft, vtmp);
> > +vtmp = vec_vmuluwm(vin32r, vfilter[j]);
> > +vright = vec_add(vright, vtmp);
> > +#endif
> 
> Is there no xlc installed on your test system?
> I suspect an earlier patch from you already
> broke xlc compilation...

No, I don't really care about proprietary compilers. You reported
previously that xlc created invalid code anyway?

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

Re: [FFmpeg-devel] [PATCH] avutil/ppc/cpu: Fix power8 linux detection

[Lauri Kasanen]

On Wed, 9 Jan 2019 21:55:30 +0100
Carl Eugen Hoyos  wrote:

> 2019-01-08 10:08 GMT+01:00, Lauri Kasanen :
> > The existing code was in no released kernel that I can see. The corrected
> > code
> > was added in 3.9.
> >
> > Signed-off-by: Lauri Kasanen 
> > ---
> >  libavutil/ppc/cpu.c | 10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/libavutil/ppc/cpu.c b/libavutil/ppc/cpu.c
> > index 7bb7cd8..b022149 100644
> > --- a/libavutil/ppc/cpu.c
> > +++ b/libavutil/ppc/cpu.c
> > @@ -93,13 +93,13 @@ int ff_get_cpu_flags_ppc(void)
> >  if (buf[i + 1] & PPC_FEATURE_HAS_VSX)
> >  ret |= AV_CPU_FLAG_VSX;
> >  #endif
> > -#ifdef PPC_FEATURE_ARCH_2_07
> > -if (buf[i + 1] & PPC_FEATURE_HAS_POWER8)
> > -ret |= AV_CPU_FLAG_POWER8;
> > -#endif
> >  if (ret & AV_CPU_FLAG_VSX)
> >  av_assert0(ret & AV_CPU_FLAG_ALTIVEC);
> 
> > -goto out;
> 
> This seems like an unrelated change.

It's necessary. HWCAP appears before HWCAP2 in the array, so if the
code jumps out in HWCAP, it never gets to checking the CAP2 bits like
power8.

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

Re: [FFmpeg-devel] [PATCH] avformat/http: ignore the string after char '#'

[Liu Steven]

> 在 2019年1月10日，下午5:09，Nicolas George  写道：
> 
> Liu Steven (12019-01-10):
>> Ok, I get that mean, let me think how to fix that.
> 
> Do you know why the fragment was there in the first place and what its
> role was?
I guess that is used for them web browser or player, i will ask that infomation 
from the ticket.


Thanks

Steven
> 
> Regards,
> 
> -- 
>  Nicolas George



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

Re: [FFmpeg-devel] [PATCH] avformat/http: ignore the string after char '#'

[Nicolas George]

Liu Steven (12019-01-10):
> Ok, I get that mean, let me think how to fix that.

Do you know why the fragment was there in the first place and what its
role was?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] avformat/http: ignore the string after char '#'

[Liu Steven]

> 在 2019年1月10日，下午4:54，Nicolas George  写道：
> 
> Liu Steven (12019-01-10):
>>How should i understand the mean “the fragment part should not have 
>> arrived there in the first place.” ?
>> 
>>When i use wget to get http://ffmpeg.org/helloworld/test#hello=24
>>wget -dS http://ffmpeg.org/helloworld/test#hello=24
>>the request is GET /helloworld/test
>> 
>>But ffmpeg is use full URI “/helloworld/test#hello=24”
>>That will forbidden by the http server in ticket: 7660.
>> 
>>or just fix it in hls.c?
> 
> I think the fragment part should be removed earlier. When the URL comes
> directly from the user, I believe it should be the responsibility of the
> user. When it comes from the application, the responsibility of the
> application. And when it comes from a protocol, by the code handling
> that protocol.
> 
> Your code just ignores the fragment, but the fragment information was
> there for a reason in the first place, was it not?

Ok, I get that mean, let me think how to fix that.

Thanks Nicolas, 

Steven
> 
> Regards,
> 
> -- 
>  Nicolas George



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

Re: [FFmpeg-devel] [PATCH] avformat/http: ignore the string after char '#'

[Nicolas George]

Liu Steven (12019-01-10):
> How should i understand the mean “the fragment part should not have 
> arrived there in the first place.” ?
> 
> When i use wget to get http://ffmpeg.org/helloworld/test#hello=24
> wget -dS http://ffmpeg.org/helloworld/test#hello=24
> the request is GET /helloworld/test
> 
> But ffmpeg is use full URI “/helloworld/test#hello=24”
> That will forbidden by the http server in ticket: 7660.
>  
> or just fix it in hls.c?

I think the fragment part should be removed earlier. When the URL comes
directly from the user, I believe it should be the responsibility of the
user. When it comes from the application, the responsibility of the
application. And when it comes from a protocol, by the code handling
that protocol.

Your code just ignores the fragment, but the fragment information was
there for a reason in the first place, was it not?

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Wang, Shaofei]

Also caused by some old mingw64 toolchain? Will try to avoid the error in v2 
patch. Thanks

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of 
Michael Niedermayer
Sent: Thursday, January 10, 2019 7:36 AM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N 
filter graphs and adaptive bitrate.

On Wed, Jan 09, 2019 at 03:50:03PM -0500, Shaofei Wang wrote:
> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obove about 
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
> 
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)
> 
> For 1:N transcode by GPU acceleration with vaapi:
> ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
> -hwaccel_output_format vaapi \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
> -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null \
> -abr_pipeline
> 
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved   6.1%6.9%   5.5%
> 
> For 1:N transcode by GPU acceleration with QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
> -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null 
> /dev/null
> 
> test results:
> 2 encoders  5 encoders 10 encoders
> Improved   6%   4% 15%
> 
> For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null 
> /dev/null \
> -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f 
> null /dev/null
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   12% 21%21%
> 
> For CPU only 1 decode to N scaling:
> ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
> -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null \
> -abr_pipeline
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   25%107%   148%
> 
> Signed-off-by: Wang, Shaofei 
> Reviewed-by: Zhao, Jun 
> ---
>  fftools/ffmpeg.c| 239 
> +---
>  fftools/ffmpeg.h|  14 +++
>  fftools/ffmpeg_filter.c |   6 ++
>  fftools/ffmpeg_opt.c|   6 +-
>  4 files changed, 251 insertions(+), 14 deletions(-)

fails to build on mingw64

CC  fftools/ffmpeg_filter.o
src/fftools/ffmpeg_filter.c: In function ‘init_simple_filtergraph’:
src/fftools/ffmpeg_filter.c:231:39: error: incompatible types when assigning to 
type ‘pthread_t’ from type ‘int’
 ist->filters[i]->f_thread = 0;
   ^
make: *** [fftools/ffmpeg_filter.o] Error 1
CC  fftools/ffmpeg.o
src/fftools/ffmpeg.c: In function ‘pipeline_reap_filters’:
src/fftools/ffmpeg.c:1534:5: warning: ISO C90 forbids mixed declarations and 
code [-Wdeclaration-after-statement]
 OutputStream *ost = output_streams[i];
 ^
src/fftools/ffmpeg.c: In function ‘do_streamcopy’:
src/fftools/ffmpeg.c:2179:5: warning: ‘av_copy_packet_side_data’ is deprecated 
(declared at src/libavcodec/avcodec.h:4424) [-Wdeprecated-declarations]
 av_copy_packet_side_data(, pkt);
 ^
src/fftools/ffmpeg.c: In function ‘filter_pipeline’:
src/fftools/ffmpeg.c:2412:5: warning: ‘return’ with no value, in function 
returning non-void [enabled by default]
 return;
 ^
src/fftools/ffmpeg.c: In function ‘send_frame_to_filters’:
src/fftools/ffmpeg.c:2451:17: error: wrong type argument to unary exclamation 
mark
 if (!ist->filters[i]->f_thread) {
 ^
src/fftools/ffmpeg.c: In function ‘init_output_stream’:
src/fftools/ffmpeg.c:3754:9: warning: ‘avcodec_copy_context’ is deprecated 
(declared at src/libavcodec/avcodec.h:4196) [-Wdeprecated-declarations]
 ret = avcodec_copy_context(ost->st->codec, ost->enc_ctx);
 ^
src/fftools/ffmpeg.c:3754:9: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
src/fftools/ffmpeg.c:3800:9: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
 ost->st->codec->codec= ost->enc_ctx->codec;
 ^
src/fftools/ffmpeg.c: In function ‘check_keyboard_interaction’:
src/fftools/ffmpeg.c:4181:13: warning: ‘codec’ is deprecated (declared at 
src/libavformat/avformat.h:878) [-Wdeprecated-declarations]
 debug = input_streams[0]->st->codec->debug<<1;
  

Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Wang, Shaofei]

Please ignore those commented lines which will be removed in the v2 patch, they 
were referred from previous reap_filters() code.

"if (HAVE_THREADS && !abr_pipeline)" looks better.

Could you add more about "not work with thread emulation"? Thx.

-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Carl 
Eugen Hoyos
Sent: Thursday, January 10, 2019 4:51 AM
To: FFmpeg development discussions and patches 
Subject: Re: [FFmpeg-devel] [PATCH] Improved the performance of 1 decode + N 
filter graphs and adaptive bitrate.

2019-01-09 21:50 GMT+01:00, Shaofei Wang :

> +//if (ost->source_index >= 0)
> +//*filtered_frame=
> *input_streams[ost->source_index]->decoded_frame; //for me_threshold

Is there a reason why this is commented?

> @@ -2179,7 +2285,15 @@ static int ifilter_send_frame(InputFilter 
> *ifilter, AVFrame *frame)
>  }
>  }
>
> +#if HAVE_THREADS
> +if (!abr_pipeline) {

The following is less ugly:
if (HAVE_THREADS && !abr_pipeline)
Same below, you can define the new variables unconditionally.

But why does your code not work with FFmpeg's  thread emulation?

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