[FFmpeg-devel] [PATCH v4] avfilter: add OpenCL scale filter

[Gabriel Machado]

From: Gabriel Machado 

Implemented the scaling filters using discrete convolution and ported most
of the filters from libswscale.

---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/opencl/scale.cl   |  67 ++
 libavfilter/opencl_source.h   |   1 +
 libavfilter/vf_scale_opencl.c | 531 ++
 6 files changed, 602 insertions(+)
 create mode 100644 libavfilter/opencl/scale.cl
 create mode 100644 libavfilter/vf_scale_opencl.c

diff --git a/configure b/configure
index 99570a1..abd9e3a 100755
--- a/configure
+++ b/configure
@@ -2876,6 +2876,7 @@ v4l2_m2m_deps_any="linux_videodev2_h"
 
 hwupload_cuda_filter_deps="ffnvcodec"
 scale_npp_filter_deps="ffnvcodec libnpp"
+scale_opencl_filter_deps="opencl"
 scale_cuda_filter_deps="cuda_sdk"
 thumbnail_cuda_filter_deps="cuda_sdk"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index a90ca30..6303cbd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -302,6 +302,7 @@ OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
 OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SCALE_CUDA_FILTER) += vf_scale_cuda.o 
vf_scale_cuda.ptx.o
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_OPENCL_FILTER)   += vf_scale_opencl.o opencl.o 
opencl/scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 1cf1340..3185b17 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -309,6 +309,7 @@ static void register_all(void)
 REGISTER_FILTER(SCALE,  scale,  vf);
 REGISTER_FILTER(SCALE_CUDA, scale_cuda, vf);
 REGISTER_FILTER(SCALE_NPP,  scale_npp,  vf);
+REGISTER_FILTER(SCALE_OPENCL,   scale_opencl,   vf);
 REGISTER_FILTER(SCALE_QSV,  scale_qsv,  vf);
 REGISTER_FILTER(SCALE_VAAPI,scale_vaapi,vf);
 REGISTER_FILTER(SCALE2REF,  scale2ref,  vf);
diff --git a/libavfilter/opencl/scale.cl b/libavfilter/opencl/scale.cl
new file mode 100644
index 000..68f7431
--- /dev/null
+++ b/libavfilter/opencl/scale.cl
@@ -0,0 +1,67 @@
+/*
+ * Copyright (c) 2018 Gabriel Machado
+ *
+ * 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 neighbor(__write_only image2d_t dst,
+   __read_only  image2d_t src)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_TRUE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+int2 dst_pos = {get_global_id(0), get_global_id(1)};
+float2 dst_size = {get_global_size(0), get_global_size(1)};
+
+float2 src_coord = (convert_float2(dst_pos) + 0.5) / dst_size;
+
+float4 c = read_imagef(src, sampler, src_coord);
+write_imagef(dst, dst_pos, c);
+}
+
+__kernel void scale(__write_only image2d_t dst,
+__read_only  image2d_t src,
+__constant   float*cx,
+__constant   float*cy,
+ int2  flt_size)
+{
+const sampler_t s_img = (CLK_NORMALIZED_COORDS_FALSE |
+ CLK_ADDRESS_CLAMP_TO_EDGE |
+ CLK_FILTER_NEAREST);
+
+int2 dst_pos = {get_global_id(0), get_global_id(1)};
+
+float2 dst_size = {get_global_size(0), get_global_size(1)};
+float2 src_size = convert_float2(get_image_dim(src));
+
+float2 src_coord = (convert_float2(dst_pos) + 0.5) * src_size / dst_size;
+
+int2 src_pos = convert_int2(floor(src_coord - 0.5));
+
+float4 col = 0;
+for (int i = 0; i < flt_size.y; ++i) {
+float4 s = 0;
+for (int j = 0; j < flt_size.x; ++j) {
+float4 c = read_imagef(src, s_img, src_pos + (int2){flt_size.x/2 - 
j, flt_size.y/2 - i});
+s += c * cx[dst_pos.x * flt_size.x + j];
+}
+col += s * cy[dst_pos.y * flt_size.y + i];
+}
+
+

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Derek Buitenhuis]

On 3/30/2018 11:20 AM, Michael Niedermayer wrote:
> I mean derek (who wrote the patch) has not even had time to reply to my
> comment. 
> I am very interrested in what his oppinion is, does he agree? does he
> think its impossible or too hard or irrelevant ? Or does he see something
> i didnt think of at all.
> 
> Lets wait for derek before arguing over it.

Been on planes the last 1.5 days - will respond properly tomorrow.

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

[FFmpeg-devel] [PATCH] avcodec/utvideodec: Set pro flag based on fourcc

[Michael Niedermayer]

This avoids mixing 8bit variants with pro and 10bit with non pro mode.
Fixes: out of array read
Fixes: poc_03_30.avi

Found-by: GwanYeong Kim 
Signed-off-by: Michael Niedermayer 
---
 libavcodec/utvideodec.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index 086129d094..82cb038ccd 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -949,14 +949,17 @@ static av_cold int decode_init(AVCodecContext *avctx)
 break;
 case MKTAG('U', 'Q', 'Y', '2'):
 c->planes  = 3;
+c->pro = 1;
 avctx->pix_fmt = AV_PIX_FMT_YUV422P10;
 break;
 case MKTAG('U', 'Q', 'R', 'G'):
 c->planes  = 3;
+c->pro = 1;
 avctx->pix_fmt = AV_PIX_FMT_GBRP10;
 break;
 case MKTAG('U', 'Q', 'R', 'A'):
 c->planes  = 4;
+c->pro = 1;
 avctx->pix_fmt = AV_PIX_FMT_GBRAP10;
 break;
 case MKTAG('U', 'L', 'H', '0'):
@@ -1031,7 +1034,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
 if (c->compression != 2)
 avpriv_request_sample(avctx, "Unknown compression type");
 c->slices  = avctx->extradata[9] + 1;
-} else if (avctx->extradata_size >= 16) {
+} else if (!c->pro && avctx->extradata_size >= 16) {
 av_log(avctx, AV_LOG_DEBUG, "Encoder version %d.%d.%d.%d\n",
avctx->extradata[3], avctx->extradata[2],
avctx->extradata[1], avctx->extradata[0]);
@@ -1046,14 +1049,13 @@ static av_cold int decode_init(AVCodecContext *avctx)
 c->slices  = (c->flags >> 24) + 1;
 c->compression = c->flags & 1;
 c->interlaced  = c->flags & 0x800;
-} else if (avctx->extradata_size == 8) {
+} else if (c->pro && avctx->extradata_size == 8) {
 av_log(avctx, AV_LOG_DEBUG, "Encoder version %d.%d.%d.%d\n",
avctx->extradata[3], avctx->extradata[2],
avctx->extradata[1], avctx->extradata[0]);
 av_log(avctx, AV_LOG_DEBUG, "Original format %"PRIX32"\n",
AV_RB32(avctx->extradata + 4));
 c->interlaced  = 0;
-c->pro = 1;
 c->frame_info_size = 4;
 } else {
 av_log(avctx, AV_LOG_ERROR,
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[James Almer]

On 3/30/2018 9:55 PM, wm4 wrote:
> On Sat, 31 Mar 2018 01:55:52 +0200
> Michael Niedermayer  wrote:
> 
>> On Fri, Mar 30, 2018 at 01:31:35PM +0200, Paul B Mahol wrote:
>> [...]
>>> Why you and some other 'old' developers have urge to block every single 
>>> patch
>>> that comes from some developers?  
>>
>> Thats a pretty serious accusation, you should not throw this around
>> lightly unless its true.
>>
>> Also i would generally prefer not to talk about people in relation to
>> who did what as its alienating and this is bad for us as a team.
>> But being accused of something i did not do, how could i defend myself
>> without refering to what was actually said and by whom. And these
>> accusations keep comming up ...
> 
> Maybe they're true at least to some extent? Have you ever thought about
> that. Others complained too. Could also list Libav as argument.
> 
> I won't claim I'm 100% innocent (just like I don't claim you're 100%
> evil). But there is definitely something wrong here with how you
> present things.
> 
>> Whos patches are being blocked ?
>> I assume by "some developers" you mean wm4 ? If so lets look at this
>> case
> 
> Oh, so you're singling me out as the evil one? That's of course a
> direct attack against me. Also since bystanders will trust your word
> more than mine (since you're universally known as "the" FFmpeg guy),
> this is pretty a pretty serious attack against me.
> 
> Anyway, my patches have been blocked or bikeshedded in the past as well
> by certain people (including yourself). Blocking/rejecting patches is
> part of the normal development process. (What matters is _how_ it
> happens and the social aspects around it.)
> 
>> wm4 blocked tobias av log patch yesterday (Re: [FFmpeg-devel] [PATCH v3 2/3] 
>> avutil/log: add av_log_set_opts function)
>> "I'd like to block it, because I don't see it as a good thing that more
>>  fftools specific stuff is leaking into the generic libs. Sorry."
> 
> I'd rather say: you blocked Tobias' initial patch, even though the patch
> was completely fine. I was not even aware you objected to me blocking
> the second version of the patch. You didn't reply to my arguments, or
> reply at all.
> 
>> and in the "[FFmpeg-devel] [RFC] avpriv cleanup" thread 3 days before 
>> the debate went in circles until i gave up as it just got too much
>> effort for the small gain of the change i wanted to do.
>> Not technically blocked no
> 
> Well, I also spend a lot of time going in circles with you, instead of
> making progress. Like in this thread right now.
> 
> Can you explain how I "blocked" this? I explicitly encouraged you to
> post concrete proposals (though you never did that), and my only gripe
> with this was that the discussion was overly broad, with some danger
> that you'd just make all avpriv functions public or so.
> 
> I'm actually not sure what you're complaining about wrt. to that
> avpriv thread. This is how an overly broad discussion will go. So why
> did you start one. What was your desired or expected outcome of this
> thread? Everyone agrees and then does nothing, because there couldn't
> really be any actionable result?
> 
> Actually, my patch makes it unnecessary to make one of those avpriv_
> functions public, so you could say I contributed to this in a
> productive way.
> 
>> and in this thread here with the roles flipped around his comment was
>> "I don't intend to make such strange changes. If you don't have anything
>>  actual to contribute, I will push this patch on monday."
>>  
>> He also made similar comments to nicolas. but lets stay with this here
> 
> Nicolas George? That guy who aggressively calls me a troll etc. and
> even refuses to discuss anything directly with me?
> 
>> The "strange changes" here are a request to split out renaming an identifer
>> that is required by our development policy, and everyone else splits their
>> renamings out too and i do not remember any other developer questioning that
>> such changes improve the git log readability
>>
>> you can check https://ffmpeg.org/developer.html
>> "Cosmetic changes should be kept in separate patches."
> 
> These changes are inherent, functional parts of the patch. It would
> make little sense to split them out. It'd just obfuscate the
> consequences of the change. I explained this, but you didn't really
> respond to it and just repeated your original request.
> 
> The policy is NOT to split changes in nonsense ways just to reduce
> commit sizes. Asking to split patches just for the hell of it is pretty
> strange.
> 
>> And which patch do you belive iam blocking ? I was not intending of blocking 
>> any
>> patch. 
> 
> You JUST complained that I wanted to push this patch as is.
> 
> So what is it:
> a) my patch is not blocked, you're content with my reply that I don't
>want to split out those changes we talked about to a separate commit
> b) my patch is blocked until I send a new split version of the patch

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[wm4]

On Sat, 31 Mar 2018 01:55:52 +0200
Michael Niedermayer  wrote:

> On Fri, Mar 30, 2018 at 01:31:35PM +0200, Paul B Mahol wrote:
> [...]
> > Why you and some other 'old' developers have urge to block every single 
> > patch
> > that comes from some developers?  
> 
> Thats a pretty serious accusation, you should not throw this around
> lightly unless its true.
> 
> Also i would generally prefer not to talk about people in relation to
> who did what as its alienating and this is bad for us as a team.
> But being accused of something i did not do, how could i defend myself
> without refering to what was actually said and by whom. And these
> accusations keep comming up ...

Maybe they're true at least to some extent? Have you ever thought about
that. Others complained too. Could also list Libav as argument.

I won't claim I'm 100% innocent (just like I don't claim you're 100%
evil). But there is definitely something wrong here with how you
present things.

> Whos patches are being blocked ?
> I assume by "some developers" you mean wm4 ? If so lets look at this
> case

Oh, so you're singling me out as the evil one? That's of course a
direct attack against me. Also since bystanders will trust your word
more than mine (since you're universally known as "the" FFmpeg guy),
this is pretty a pretty serious attack against me.

Anyway, my patches have been blocked or bikeshedded in the past as well
by certain people (including yourself). Blocking/rejecting patches is
part of the normal development process. (What matters is _how_ it
happens and the social aspects around it.)

> wm4 blocked tobias av log patch yesterday (Re: [FFmpeg-devel] [PATCH v3 2/3] 
> avutil/log: add av_log_set_opts function)
> "I'd like to block it, because I don't see it as a good thing that more
>  fftools specific stuff is leaking into the generic libs. Sorry."

I'd rather say: you blocked Tobias' initial patch, even though the patch
was completely fine. I was not even aware you objected to me blocking
the second version of the patch. You didn't reply to my arguments, or
reply at all.

> and in the "[FFmpeg-devel] [RFC] avpriv cleanup" thread 3 days before 
> the debate went in circles until i gave up as it just got too much
> effort for the small gain of the change i wanted to do.
> Not technically blocked no

Well, I also spend a lot of time going in circles with you, instead of
making progress. Like in this thread right now.

Can you explain how I "blocked" this? I explicitly encouraged you to
post concrete proposals (though you never did that), and my only gripe
with this was that the discussion was overly broad, with some danger
that you'd just make all avpriv functions public or so.

I'm actually not sure what you're complaining about wrt. to that
avpriv thread. This is how an overly broad discussion will go. So why
did you start one. What was your desired or expected outcome of this
thread? Everyone agrees and then does nothing, because there couldn't
really be any actionable result?

Actually, my patch makes it unnecessary to make one of those avpriv_
functions public, so you could say I contributed to this in a
productive way.

> and in this thread here with the roles flipped around his comment was
> "I don't intend to make such strange changes. If you don't have anything
>  actual to contribute, I will push this patch on monday."
>  
> He also made similar comments to nicolas. but lets stay with this here

Nicolas George? That guy who aggressively calls me a troll etc. and
even refuses to discuss anything directly with me?

> The "strange changes" here are a request to split out renaming an identifer
> that is required by our development policy, and everyone else splits their
> renamings out too and i do not remember any other developer questioning that
> such changes improve the git log readability
> 
> you can check https://ffmpeg.org/developer.html
> "Cosmetic changes should be kept in separate patches."

These changes are inherent, functional parts of the patch. It would
make little sense to split them out. It'd just obfuscate the
consequences of the change. I explained this, but you didn't really
respond to it and just repeated your original request.

The policy is NOT to split changes in nonsense ways just to reduce
commit sizes. Asking to split patches just for the hell of it is pretty
strange.

> And which patch do you belive iam blocking ? I was not intending of blocking 
> any
> patch. 

You JUST complained that I wanted to push this patch as is.

So what is it:
a) my patch is not blocked, you're content with my reply that I don't
   want to split out those changes we talked about to a separate commit
b) my patch is blocked until I send a new split version of the patch
c) something else which you haven't said yet or something equally vague
   that you intend to complain about after I push the patch

I suspect it's actually c).

> Its really odd, if i look at just the 

Re: [FFmpeg-devel] [PATCH] [RFC] avformat/movenc: support writing iTunes cover image

[Michael Niedermayer]

On Thu, Mar 29, 2018 at 09:45:13AM +0300, Timo Teräs wrote:
> Fixes https://trac.ffmpeg.org/ticket/2798
> 
> This makes movenc handle AV_DISPOSITION_ATTACHED_PIC and write
> the associated pictures in iTunes cover atom. This corresponds
> to how 'mov' demuxer parses and exposes the cover images when
> reading.
> 
> Tested to produce valid stream with:
>  ffmpeg -i movie.mp4 -i thumb.jpg -disposition:v:1 attached_pic
> -map 0 -map 1 -c copy out.mp4
> 
> The cover image is also copied corretly with:
>  ffmpeg -i movie.mp4 -map 0 -c copy out.mp4
> 
> AtomicParseley says that the attached_pic stream is properly
> not visible in the main tracks of the file. Though, I am not
> sure if there's any side-effects of having internal stream
> without any packets. We may need to arm the mov muxer with
> additional checks for streams without any packets.
> 
> It may make sense to move the code in mov_write_packet() that
> grabs the attached picture to generic code in mux.c. Seems there's
> currently no other muxer supporting cover images than mp3 and
> it seems to use special code to handle them.
> 
> Signed-off-by: Timo Teräs 
> Cc: Matthieu Bouron 
> ---
>  fftools/ffmpeg.c |  1 +
>  libavformat/movenc.c | 67 
> 
>  2 files changed, 68 insertions(+)
[...]

> @@ -3451,6 +3499,7 @@ static int mov_write_ilst_tag(AVIOContext *pb, 
> MOVMuxContext *mov,
>  mov_write_int8_metadata  (s, pb, "hdvd","hd_video",  1);
>  mov_write_int8_metadata  (s, pb, "pgap","gapless_playback",1);
>  mov_write_int8_metadata  (s, pb, "cpil","compilation", 1);
> +mov_write_covr(pb, s);
>  mov_write_trkn_tag(pb, mov, s, 0); // track number
>  mov_write_trkn_tag(pb, mov, s, 1); // disc number
>  mov_write_tmpo_tag(pb, s);
> @@ -5480,6 +5529,24 @@ static int mov_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  if (!pkt) {
>  mov_flush_fragment(s, 1);
>  return 1;
> +} if (s->streams[pkt->stream_index]->disposition & 
> AV_DISPOSITION_ATTACHED_PIC) {

The if() should be in the next line or it should be a else if
it looks like someone forgot a "else" even though it makes no
difference here.

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[Michael Niedermayer]

On Fri, Mar 30, 2018 at 01:31:35PM +0200, Paul B Mahol wrote:
[...]
> Why you and some other 'old' developers have urge to block every single patch
> that comes from some developers?

Thats a pretty serious accusation, you should not throw this around
lightly unless its true.

Also i would generally prefer not to talk about people in relation to
who did what as its alienating and this is bad for us as a team.
But being accused of something i did not do, how could i defend myself
without refering to what was actually said and by whom. And these
accusations keep comming up ...

Whos patches are being blocked ?
I assume by "some developers" you mean wm4 ? If so lets look at this
case

wm4 blocked tobias av log patch yesterday (Re: [FFmpeg-devel] [PATCH v3 2/3] 
avutil/log: add av_log_set_opts function)
"I'd like to block it, because I don't see it as a good thing that more
 fftools specific stuff is leaking into the generic libs. Sorry."
 
and in the "[FFmpeg-devel] [RFC] avpriv cleanup" thread 3 days before 
the debate went in circles until i gave up as it just got too much
effort for the small gain of the change i wanted to do.
Not technically blocked no

and in this thread here with the roles flipped around his comment was
"I don't intend to make such strange changes. If you don't have anything
 actual to contribute, I will push this patch on monday."
 
He also made similar comments to nicolas. but lets stay with this here

The "strange changes" here are a request to split out renaming an identifer
that is required by our development policy, and everyone else splits their
renamings out too and i do not remember any other developer questioning that
such changes improve the git log readability

you can check https://ffmpeg.org/developer.html
"Cosmetic changes should be kept in separate patches."

And which patch do you belive iam blocking ? I was not intending of blocking any
patch. 

Its really odd, if i look at just the last few days, who blocked patches
and who got accused of it. It just makes no sense. There is not much overlap
between who blocked patches and who got accused of blocking patches.

Either way these hostilities we have here are not good, please calm down, iam
not blocking any patches. If some other developer, wm4, nicolas or whoever 
does, iam sure he has a reason for it, even if someone disagrees. 
The best for such a case would be
to calmly and respectfully discuss. Escalation will likely not achive anything
except Escalation.

Also lets stop accusing people, of things. This just leads to a back and forth
that is harmfull to the team. 
If you think iam doing something bad or wrong, talk with me about it please
theres private mail there is IRC. Hasnt it always been a misunderstanding of
some form in the past?
I dont block patches generally ... If a patch is really bad many people will
object to it, it doesnt require me beyond maybe pointing to the issue to make
sure others are aware of it ...

Peace

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 3/3] arm: hevcdsp: Avoid using macro expansion counters

[Hendrik Leppkes]

On Fri, Mar 30, 2018 at 9:14 PM, Martin Storsjö  wrote:
> Clang supports the macro expansion counter (used for making unique
> labels within macro expansions), but not when targeting darwin.
>
> Convert uses of the counter into normal local labels, as used
> elsewhere.
>
> Since Xcode 9.3, the bundled clang supports altmacro and doesn't
> require using gas-preprocessor any longer.

Could it be that you mixed up the commit message and the contents of
commits 2/3?

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

Re: [FFmpeg-devel] [PATCH] doc/encoders - list missing options for x265

[Lou Logan]

On Fri, 30 Mar 2018 19:22:29 +0530
Gyan Doshi  wrote:

> From dafcf437cf6ef407b95b63ac21589137c0e78c9b Mon Sep 17 00:00:00 2001
> From: Gyan Doshi 
> Date: Fri, 30 Mar 2018 19:19:09 +0530
> Subject: [PATCH] doc/encoders - list missing options for x265
> 
> Add entries for crf and profile in libx265 section
> ---
>  doc/encoders.texi | 6 ++
>  1 file changed, 6 insertions(+)

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

[FFmpeg-devel] avfilter/showvolume : various "fix"

[Martin Vignali]

Hello,

After discussion in user mailing list,
several patchs, trying to fix various "issue" with showvolume filter

A wav example can be found here (1000 hz with -12 db, then -18 db then 0
db) :
https://we.tl/X6L69kEWAN

Command line to test (vertical)
./ffmpeg -i inputFile.wav -filter_complex
"[0:a]showvolume=w=340:h=5:o=v:f=1.:p=1.:t=0:m=p:v=0[v]"
-map "[v]" -c:v qtrle resAudioMeter004.mov

Command line to test (horizontal)
./ffmpeg -i inputFile.wav -filter_complex
"[0:a]showvolume=w=340:h=5:o=h:f=1.:p=1.:t=0:m=p:v=0[v]"
-map "[v]" -c:v qtrle resAudioMeter004.mov



001 : add comments to help to remember the orientation value inside func

002 : calculate fade only if fade option is not set to 1.
003 : indent

004 : clear buffer at each frame (not sure it's the best way to fix)
with this patch the wav sample at the start of this email, show a correct
audio meter
(the -18 db part of the wav, is correctly display)
005 : indent

006 : use another scale for display (some kind of log scale), more close to
a classic audio meter display. IMHO, it's better, but if need, i will add
and option, for choosing the scale display.

007 : Fix doc, for orientation parameter (possible value are h or v, not
horizontal or vertical)


I think the result of rms mode is still not right, but need more work.

Comments welcome

Martin


0001-avfilter-showvolume-add-comment-for-orientation-cond.patch
Description: Binary data


0002-avfilter-showvolume-calculate-fade-only-if-fade-1.patch
Description: Binary data


0003-avfilter-showvolume-indent-after-prev-commit.patch
Description: Binary data


0004-avfilter-showvolume-clear-buffer-at-each-frame.patch
Description: Binary data


0005-avfilter-showvolume-indent-after-prev-commit.patch
Description: Binary data


0006-avfilter-showvolume-use-some-kind-of-log-scale-for-d.patch
Description: Binary data


0007-doc-avfilter-showvolume-fix-doc-for-orientation-para.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] arm: swscale: Only compile the rgb2yuv asm if .dn aliases are supported

[Martin Storsjö]

Vanilla clang supports altmacro since clang 5.0, and thus doesn't
require gas-preprocessor for building the arm assembly any longer.

However, the built-in assembler doesn't support .dn directives.

This readds checks that were removed in d7320ca3ed10f0d, when
the last usage of .dn directives within libav were removed.

Alternatively, the assembly could be rewritten to not use the
.dn directive, making it available to clang users.
---
 configure | 2 ++
 libswscale/arm/rgb2yuv_neon_16.S  | 3 +++
 libswscale/arm/rgb2yuv_neon_32.S  | 3 +++
 libswscale/arm/swscale_unscaled.c | 6 ++
 4 files changed, 14 insertions(+)

diff --git a/configure b/configure
index 99570a1415..81fb3fbf75 100755
--- a/configure
+++ b/configure
@@ -2149,6 +2149,7 @@ SYSTEM_LIBRARIES="
 
 TOOLCHAIN_FEATURES="
 as_arch_directive
+as_dn_directive
 as_fpu_directive
 as_func
 as_object_arch
@@ -5530,6 +5531,7 @@ EOF
 check_inline_asm asm_mod_q '"add r0, %Q0, %R0" :: "r"((long long)0)'
 
 check_as as_arch_directive ".arch armv7-a"
+check_as as_dn_directive   "ra .dn d0.i16"
 check_as as_fpu_directive  ".fpu neon"
 
 # llvm's integrated assembler supports .object_arch from llvm 3.5
diff --git a/libswscale/arm/rgb2yuv_neon_16.S b/libswscale/arm/rgb2yuv_neon_16.S
index 601bc9a9b7..ad7e679ca9 100644
--- a/libswscale/arm/rgb2yuv_neon_16.S
+++ b/libswscale/arm/rgb2yuv_neon_16.S
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "config.h"
+#if HAVE_AS_DN_DIRECTIVE
 #include "rgb2yuv_neon_common.S"
 
 /* downsampled R16G16B16 x8 */
@@ -78,3 +80,4 @@ alias_qwc8x8x2, q10
 .endm
 
 loop_420sp  rgbx, nv12, init, kernel_420_16x2, 16
+#endif
diff --git a/libswscale/arm/rgb2yuv_neon_32.S b/libswscale/arm/rgb2yuv_neon_32.S
index f51a5f149f..4fd0f64a09 100644
--- a/libswscale/arm/rgb2yuv_neon_32.S
+++ b/libswscale/arm/rgb2yuv_neon_32.S
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include "config.h"
+#if HAVE_AS_DN_DIRECTIVE
 #include "rgb2yuv_neon_common.S"
 
 /* downsampled R16G16B16 x8 */
@@ -117,3 +119,4 @@ alias_qwc8x8x2, q10
 
 
 loop_420sp  rgbx, nv12, init, kernel_420_16x2, 32
+#endif
diff --git a/libswscale/arm/swscale_unscaled.c 
b/libswscale/arm/swscale_unscaled.c
index e1597ab42d..e41f294eac 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -23,6 +23,7 @@
 #include "libswscale/swscale_internal.h"
 #include "libavutil/arm/cpu.h"
 
+#if HAVE_AS_DN_DIRECTIVE
 extern void rgbx_to_nv12_neon_32(const uint8_t *src, uint8_t *y, uint8_t 
*chroma,
 int width, int height,
 int y_stride, int c_stride, int src_stride,
@@ -178,3 +179,8 @@ void ff_get_unscaled_swscale_arm(SwsContext *c)
 if (have_neon(cpu_flags))
 get_unscaled_swscale_neon(c);
 }
+#else
+void ff_get_unscaled_swscale_arm(SwsContext *c)
+{
+}
+#endif
-- 
2.15.1 (Apple Git-101)

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

[FFmpeg-devel] [PATCH 2/3] arm: hevcdsp_deblock: Add commas between macro arguments

[Martin Storsjö]

When targeting darwin, clang requires commas between arguments,
while the no-comma form is allowed for other targets.

Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
---
 libavcodec/arm/hevcdsp_deblock_neon.S | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/arm/hevcdsp_deblock_neon.S 
b/libavcodec/arm/hevcdsp_deblock_neon.S
index 166bddb104..7cb7487ef6 100644
--- a/libavcodec/arm/hevcdsp_deblock_neon.S
+++ b/libavcodec/arm/hevcdsp_deblock_neon.S
@@ -152,7 +152,7 @@
 
 andr9, r8, r7
 cmpr9, #0
-beqweakfilter_\@
+beq1f
 
 vadd.i16  q2, q11, q12
 vadd.i16  q4, q9, q8
@@ -210,11 +210,11 @@
 vbit  q13, q3, q5
 vbit  q14, q2, q5
 
-weakfilter_\@:
+1:
 mvn   r8, r8
 and   r9, r8, r7
 cmp   r9, #0
-beq   ready_\@
+beq   2f
 
 vdup.16q4, r2
 
@@ -275,7 +275,7 @@ weakfilter_\@:
 vbit  q11, q0, q5
 vbit  q12, q4, q5
 
-ready_\@:
+2:
 vqmovun.s16 d16, q8
 vqmovun.s16 d18, q9
 vqmovun.s16 d20, q10
-- 
2.15.1 (Apple Git-101)

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

[FFmpeg-devel] [PATCH 3/3] arm: hevcdsp: Avoid using macro expansion counters

[Martin Storsjö]

Clang supports the macro expansion counter (used for making unique
labels within macro expansions), but not when targeting darwin.

Convert uses of the counter into normal local labels, as used
elsewhere.

Since Xcode 9.3, the bundled clang supports altmacro and doesn't
require using gas-preprocessor any longer.
---
 libavcodec/arm/hevcdsp_qpel_neon.S | 36 ++--
 1 file changed, 18 insertions(+), 18 deletions(-)

diff --git a/libavcodec/arm/hevcdsp_qpel_neon.S 
b/libavcodec/arm/hevcdsp_qpel_neon.S
index 86f92cf75a..caa6efa766 100644
--- a/libavcodec/arm/hevcdsp_qpel_neon.S
+++ b/libavcodec/arm/hevcdsp_qpel_neon.S
@@ -667,76 +667,76 @@ endfunc
 
 
 function ff_hevc_put_qpel_h1v1_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_1 qpel_filter_1_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_1, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_h2v1_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_2 qpel_filter_1_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_2, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_h3v1_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_3 qpel_filter_1_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_3, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_h1v2_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_1 qpel_filter_2_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_1, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_h2v2_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_2 qpel_filter_2_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_2, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_h3v2_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_3 qpel_filter_2_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_3, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_h1v3_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_1 qpel_filter_3_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_1, qpel_filter_3_32b
 endfunc
 
 function ff_hevc_put_qpel_h2v3_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_2 qpel_filter_3_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_2, qpel_filter_3_32b
 endfunc
 
 function ff_hevc_put_qpel_h3v3_neon_8, export=1
-hevc_put_qpel_hXvY_neon_8 qpel_filter_3 qpel_filter_3_32b
+hevc_put_qpel_hXvY_neon_8 qpel_filter_3, qpel_filter_3_32b
 endfunc
 
 
 function ff_hevc_put_qpel_uw_h1v1_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1 qpel_filter_1_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h2v1_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2 qpel_filter_1_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h3v1_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3 qpel_filter_1_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3, qpel_filter_1_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h1v2_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1 qpel_filter_2_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h2v2_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2 qpel_filter_2_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h3v2_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3 qpel_filter_2_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3, qpel_filter_2_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h1v3_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1 qpel_filter_3_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_1, qpel_filter_3_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h2v3_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2 qpel_filter_3_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_2, qpel_filter_3_32b
 endfunc
 
 function ff_hevc_put_qpel_uw_h3v3_neon_8, export=1
-hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3 qpel_filter_3_32b
+hevc_put_qpel_uw_hXvY_neon_8 qpel_filter_3, qpel_filter_3_32b
 endfunc
 
 .macro init_put_pixels
-- 
2.15.1 (Apple Git-101)

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

[FFmpeg-devel] [PATCH] avcodec/aic: fix decoding of videos which height is not multiple of 16

[Paul B Mahol]

Fate output changes and under close inspection looks more correctly.
Fixes #6187.

Signed-off-by: Paul B Mahol 
---
 libavcodec/aic.c   |  14 +-
 tests/ref/fate/aic |  30 ++--
 tests/ref/fate/aic-oddsize | 114 ++---
 3 files changed, 84 insertions(+), 74 deletions(-)

diff --git a/libavcodec/aic.c b/libavcodec/aic.c
index 67d78c5ddd..9c6f806655 100644
--- a/libavcodec/aic.c
+++ b/libavcodec/aic.c
@@ -308,6 +308,8 @@ static int aic_decode_slice(AICContext *ctx, int mb_x, int 
mb_y,
 GetBitContext gb;
 int ret, i, mb, blk;
 int slice_width = FFMIN(ctx->slice_width, ctx->mb_width - mb_x);
+int last_row = mb_y && mb_y == ctx->mb_height - 1;
+int y_pos, c_pos;
 uint8_t *Y, *C[2];
 uint8_t *dst;
 int16_t *base_y = ctx->data_ptr[COEFF_LUMA];
@@ -316,10 +318,18 @@ static int aic_decode_slice(AICContext *ctx, int mb_x, 
int mb_y,
 int16_t *ext_c  = ctx->data_ptr[COEFF_CHROMA_EXT];
 const int ystride = ctx->frame->linesize[0];
 
-Y = ctx->frame->data[0] + mb_x * 16 + mb_y * 16 * ystride;
+if (last_row) {
+y_pos = (ctx->avctx->height - 16);
+c_pos = ((ctx->avctx->height+1)/2 - 8);
+} else {
+y_pos = mb_y * 16;
+c_pos = mb_y * 8;
+}
+
+Y = ctx->frame->data[0] + mb_x * 16 + y_pos * ystride;
 for (i = 0; i < 2; i++)
 C[i] = ctx->frame->data[i + 1] + mb_x * 8
-   + mb_y * 8 * ctx->frame->linesize[i + 1];
+   + c_pos * ctx->frame->linesize[i + 1];
 init_get_bits(, src, src_size * 8);
 
 memset(ctx->slice_data, 0,
diff --git a/tests/ref/fate/aic b/tests/ref/fate/aic
index 1f50350b96..244ea25967 100644
--- a/tests/ref/fate/aic
+++ b/tests/ref/fate/aic
@@ -3,18 +3,18 @@
 #codec_id 0: rawvideo
 #dimensions 0: 1440x1080
 #sar 0: 4/3
-0,  0,  0,1,  2332800, 0xd941b42f
-0,  1,  1,1,  2332800, 0xd941b42f
-0,  2,  2,1,  2332800, 0xae0f5983
-0,  3,  3,1,  2332800, 0x51cfc127
-0,  4,  4,1,  2332800, 0x24d40447
-0,  5,  5,1,  2332800, 0x858a9f51
-0,  6,  6,1,  2332800, 0x533b48e8
-0,  7,  7,1,  2332800, 0x2fd73267
-0,  8,  8,1,  2332800, 0x153566c7
-0,  9,  9,1,  2332800, 0xa1c49c45
-0, 10, 10,1,  2332800, 0xb966e25a
-0, 11, 11,1,  2332800, 0xd0ce5985
-0, 12, 12,1,  2332800, 0x0029a52e
-0, 13, 13,1,  2332800, 0x893116c5
-0, 14, 14,1,  2332800, 0x073d2491
+0,  0,  0,1,  2332800, 0xc22b8485
+0,  1,  1,1,  2332800, 0xc22b8485
+0,  2,  2,1,  2332800, 0xe0c21bd8
+0,  3,  3,1,  2332800, 0x3e1a8fa0
+0,  4,  4,1,  2332800, 0xbcb3f235
+0,  5,  5,1,  2332800, 0x1a7cabd6
+0,  6,  6,1,  2332800, 0xc0136ba8
+0,  7,  7,1,  2332800, 0x295e59a6
+0,  8,  8,1,  2332800, 0xf9c09288
+0,  9,  9,1,  2332800, 0x0518cc8f
+0, 10, 10,1,  2332800, 0x9ad3068e
+0, 11, 11,1,  2332800, 0x5a8b7af1
+0, 12, 12,1,  2332800, 0x7b35a8fa
+0, 13, 13,1,  2332800, 0xbe5801eb
+0, 14, 14,1,  2332800, 0x31ca019f
diff --git a/tests/ref/fate/aic-oddsize b/tests/ref/fate/aic-oddsize
index 3763e32b2c..be4346a204 100644
--- a/tests/ref/fate/aic-oddsize
+++ b/tests/ref/fate/aic-oddsize
@@ -3,60 +3,60 @@
 #codec_id 0: rawvideo
 #dimensions 0: 481x241
 #sar 0: 0/1
-0,  0,  0,1,   174243, 0xa40491e1
-0,  1,  1,1,   174243, 0xa12cbb56
-0,  2,  2,1,   174243, 0xa12cbb56
-0,  3,  3,1,   174243, 0xa12cbb56
-0,  4,  4,1,   174243, 0xa12cbb56
-0,  5,  5,1,   174243, 0xa12cbb56
-0,  6,  6,1,   174243, 0xa12cbb56
-0,  7,  7,1,   174243, 0xa12cbb56
-0,  8,  8,1,   174243, 0xa12cbb56
-0,  9,  9,1,   174243, 0x4e7b7299
-0, 10, 10,1,   174243, 0x31573b99
-0, 11, 11,1,   174243, 0x013397b6
-0, 12, 12,1,   174243, 0xdd988ab8
-0, 13, 13,1,   174243, 0xd6d96b1e
-0, 14, 14,1,   174243, 0xd6d96b1e
-0, 15, 15,1,   174243, 0xd6d96b1e
-0, 16, 16,1,   174243, 0x111627d3
-0, 17, 17,1,   174243, 0x284d9ab7
-0, 18, 18,1,   174243, 

Re: [FFmpeg-devel] [PATCH 1/5 v2] avformat/utils: make AVPacketList helper functions shared

[James Almer]

On 3/27/2018 7:48 PM, James Almer wrote:
> Based on a patch by Luca Barbato.
> 
> Signed-off-by: James Almer 
> ---
>  libavformat/internal.h | 38 +
>  libavformat/utils.c| 57 
> +-
>  2 files changed, 71 insertions(+), 24 deletions(-)

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

[FFmpeg-devel] [PATCH 1/6] avcodec/avpacket: add av_packet_make_refcounted()

[James Almer]

It works as a drop in replacement for the deprecated av_dup_packet(),
to ensure a packet is reference counted.

Signed-off-by: James Almer 
---
 libavcodec/avcodec.h  | 18 +-
 libavcodec/avpacket.c | 18 ++
 2 files changed, 35 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 3306910dd2..c046f300ef 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -4365,7 +4365,7 @@ int av_packet_from_data(AVPacket *pkt, uint8_t *data, int 
size);
  * @warning This is a hack - the packet memory allocation stuff is broken. The
  * packet is allocated if it was not really allocated.
  *
- * @deprecated Use av_packet_ref
+ * @deprecated Use av_packet_ref or av_packet_make_refcounted
  */
 attribute_deprecated
 int av_dup_packet(AVPacket *pkt);
@@ -4536,6 +4536,22 @@ void av_packet_move_ref(AVPacket *dst, AVPacket *src);
  */
 int av_packet_copy_props(AVPacket *dst, const AVPacket *src);
 
+/**
+ * Ensure the data described by a given packet is reference counted.
+ *
+ * @note This function does no ensure that the reference will be writable.
+ *   Use av_packet_make_writable instead for that purpose.
+ *
+ * @see av_packet_ref
+ * @see av_packet_make_writable
+ *
+ * @param pkt packet whose data should be made reference counted.
+ *
+ * @return 0 on success, a negative AVERROR on error. On failure, the
+ * packet is unchanged.
+ */
+int av_packet_make_refcounted(AVPacket *pkt);
+
 /**
  * Create a writable reference for the data described by a given packet,
  * avoiding data copy if possible.
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index 0993481961..99a0c1383b 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -652,6 +652,24 @@ void av_packet_move_ref(AVPacket *dst, AVPacket *src)
 src->size = 0;
 }
 
+int av_packet_make_refcounted(AVPacket *pkt)
+{
+int ret;
+
+if (pkt->buf)
+return 0;
+
+ret = packet_alloc(>buf, pkt->size);
+if (ret < 0)
+return ret;
+if (pkt->size)
+memcpy(pkt->buf->data, pkt->data, pkt->size);
+
+pkt->data = pkt->buf->data;
+
+return 0;
+}
+
 int av_packet_make_writable(AVPacket *pkt)
 {
 AVBufferRef *buf = NULL;
-- 
2.16.2

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

[FFmpeg-devel] [PATCH] avformat/mpeg: fix detection and demuxing of raw AC3 in mpegps

[Paul B Mahol]

Fixes #4889.

Signed-off-by: Paul B Mahol 
---
 libavformat/mpeg.c | 27 +++
 1 file changed, 19 insertions(+), 8 deletions(-)

diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 69d4a9d8ac..f6e3439e68 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -128,6 +128,7 @@ typedef struct MpegDemuxContext {
 int sofdec;
 int dvd;
 int imkh_cctv;
+int raw_ac3;
 #if CONFIG_VOBSUB_DEMUXER
 AVFormatContext *sub_ctx;
 FFDemuxSubtitlesQueue q[32];
@@ -443,7 +444,15 @@ redo:
 
 if (startcode == PRIVATE_STREAM_1) {
 startcode = avio_r8(s->pb);
-len--;
+if (avio_r8(s->pb) == 0x77 && startcode == 0x0b) {
+startcode = 0x80;
+m->raw_ac3 = 1;
+avio_skip(s->pb, -2);
+} else {
+m->raw_ac3 = 0;
+avio_skip(s->pb, -1);
+len--;
+}
 }
 if (len < 0)
 goto error_redo;
@@ -486,14 +495,16 @@ redo:
 if (len < 4)
 goto skip;
 
-/* audio: skip header */
-avio_r8(s->pb);
-lpcm_header_len = avio_rb16(s->pb);
-len -= 3;
-if (startcode >= 0xb0 && startcode <= 0xbf) {
-/* MLP/TrueHD audio has a 4-byte header */
+if (!m->raw_ac3) {
+/* audio: skip header */
 avio_r8(s->pb);
-len--;
+lpcm_header_len = avio_rb16(s->pb);
+len -= 3;
+if (startcode >= 0xb0 && startcode <= 0xbf) {
+/* MLP/TrueHD audio has a 4-byte header */
+avio_r8(s->pb);
+len--;
+}
 }
 }
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: prevent premature EOF in sub2video with nullptr AVSubtitles

[Jan Ekström]

On Thu, Mar 29, 2018 at 5:25 PM, Jan Ekström  wrote:
> On Thu, Mar 29, 2018 at 1:14 PM, Michael Niedermayer
>  wrote:
>>
>> this breaks fate-sub2video
>>
>> TESTsub2video
>> --- ./tests/ref/fate/sub2video  2018-03-29 02:30:48.095578219 +0200
>> +++ tests/data/fate/sub2video   2018-03-29 12:13:25.191428538 +0200
>> @@ -68,7 +68,8 @@
>>  0,258,258,1,   518400, 0x34cdddee
>>  0,269,269,1,   518400, 0xbab197ea
>>  1,   5391,   5391,  2696000, 2095, 0x61bb15ed, F=0x0
>> -0,270,270,1,   518400, 0x4db4ce51
>> +0,270,270,1,   518400, 0xbab197ea
>> +0,271,271,1,   518400, 0x4db4ce51
>>  0,283,283,1,   518400, 0xbab197ea
>>  1,   56663000,   56663000,  1262000, 1013, 0xc9ae89b7, F=0x0
>>  0,284,284,1,   518400, 0xe6bc0ea9
>> @@ -137,7 +138,7 @@
>>  1,  168049000,  168049000,  190, 1312, 0x0bf20e8d, F=0x0
>>  0,850,850,1,   518400, 0xbab197ea
>>  1,  170035000,  170035000,  1524000, 1279, 0xb6c2dafe, F=0x0
>> -0,851,851,1,   518400, 0x8780239e
>> +0,851,851,1,   518400, 0xbab197ea
>>  0,858,858,1,   518400, 0xbab197ea
>>  0,861,861,1,   518400, 0x6eb72347
>>  1,  172203000,  172203000,  1695000, 1826, 0x9a1ac769, F=0x0
>> @@ -161,7 +162,8 @@
>>  0,976,976,1,   518400, 0x923d1ce7
>>  0,981,981,1,   518400, 0xbab197ea
>>  1,  196361000,  196361000,  1524000, 1715, 0x695ca41e, F=0x0
>> -0,982,982,1,   518400, 0x6e652cd2
>> +0,982,982,1,   518400, 0xbab197ea
>> +0,983,983,1,   518400, 0x6e652cd2
>>  0,989,989,1,   518400, 0xbab197ea
>>  1,  197946000,  197946000,  116,  789, 0xc63a189e, F=0x0
>>  0,990,990,1,   518400, 0x25113966
>> Test sub2video failed. Look at tests/data/fate/sub2video.err for details.
>> make: *** [fate-sub2video] Error 1
>
> Thanks. I tried running this last night but it required some of the
> samples in FATE so I decided to re-run it today. Will check if the
> change is correct. For the reference, this change has now been running
> in a testing setup for at least 24h with the subtitles still being
> overlayed correctly, so the change seems alright by the general
> metrics (that I can gather).
>
> Jan

OK, I have run this test at 25fps and 30/1.001fps in addition to the
5fps it runs at by default. I find it very interesting at how the
output of the filter gets all VFR in some cases, while you'd think
that taking in a rawvideo clip with a static fps set would lead to
constant output of frames?

In any case, the diff with 5fps is what has been posted and the three diffs are:
1. subtitle with timestamp 5391 (53.91 -> 56.606)
  * Frame that ends up being shown 54.0 -> 56.6 (although original
duration is just 1/5 seconds) gets replaced with one frame that is
shown 54.0 -> 54.2 (no subtitle shown) and another that is 54.2 ->
56.6 (subtitle shown, this as well seems to originally only have a
duration of 1/5s)
2. subtitle with timestamp 170035000 (170.035 -> 171.559)
  * Frame that ends up being shown 170.2 -> 171.6 (although original
duration is just 1/5 seconds) gets replaced with a frame without a
subtitle.
3. subtitle with timestamp 196361000 (196.361 -> 197.885)
  * Similar to nr1, one frame in a VFR spot replaced with two of which
the first one has no subtitle.

With higher frame rates the output of the filter chain stayed VFR, but
you only had frames added in some spots but none replaced. I recall
all of those frames not being directly relevant to subtitles in that
case, but I will double-check as I was getting tired at that point.

Another alternative would of course to be not to send the nullptr
AVSubtitle with what would be INT64_MAX further into the filter chain
at all (this change doesn't change that at all, the "heartbeat" thing
gets pushed into the filter chain). I'm just not 100% clear which is
the correct place to control this.
a) in `sub2video_update`, in the else case you could add `if
(ist->sub2video.end_pts == INT64_MAX) return;` to make sure that value
wouldn't get propagated into an EOF.
b)  in `sub2video_heartbeat`, changing the check from just checking
that data[0] is falsie to also checking if `sub2video.end_pts !=
INT64_MAX`, since I think this is the spot that sends out those
nullptr AVSubtitles to `sub2video_update`.
c) somewhere else which causes this to happen when the filter chain
gets re-initialized/configured because of a seemingly unrelated
stream?

Additionally, I just noticed as an unrelated issue that the subtitles'
scaling seems to get forgotten with the re-init/configuration as well.
So you can end up with SD dvb subtitles being 

[FFmpeg-devel] [PATCH] lavfi: add a Vulkan Chromatic Aberration filter

[Rostislav Pehlivanov]

This implements a simple chromatic aberration filter. The curve could
use a little bit of tweaking, right now its not as curvy as it should
be but nevertheless it models the imperfections of lenses.

Meant to be applied on top of my previous patches. RFC quality again.

Signed-off-by: Rostislav Pehlivanov 
---

You want something more interesting, you get something more interesting!

 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_avgblur_vulkan.c |   3 -
 libavfilter/vf_chromaticaberration_vulkan.c | 334 
 libavfilter/vulkan.c|   7 +-
 libavfilter/vulkan.h|   2 +-
 7 files changed, 342 insertions(+), 7 deletions(-)
 create mode 100644 libavfilter/vf_chromaticaberration_vulkan.c

diff --git a/configure b/configure
index 388e45fed1..577c8e0aba 100755
--- a/configure
+++ b/configure
@@ -3298,6 +3298,7 @@ azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
 bs2b_filter_deps="libbs2b"
+chromaticabberation_vulkan_filter_deps="vulkan libshaderc"
 colormatrix_filter_deps="gpl"
 convolution_opencl_filter_deps="opencl"
 convolve_filter_deps="avcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f0a47320c8..4798f002a8 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -151,6 +151,7 @@ OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o 
framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o
 OBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMATICABERRATION_VULKAN_FILTER) += 
vf_chromaticaberration_vulkan.o vulkan.o
 OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
 OBJS-$(CONFIG_CODECVIEW_FILTER)  += vf_codecview.o
 OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 3cbaecd726..3baf32ae7a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -160,6 +160,7 @@ static void register_all(void)
 REGISTER_FILTER(BOXBLUR,boxblur,vf);
 REGISTER_FILTER(BWDIF,  bwdif,  vf);
 REGISTER_FILTER(CHROMAKEY,  chromakey,  vf);
+REGISTER_FILTER(CHROMATICABERRATION_VULKAN, chromaticaberration_vulkan, 
vf);
 REGISTER_FILTER(CIESCOPE,   ciescope,   vf);
 REGISTER_FILTER(CODECVIEW,  codecview,  vf);
 REGISTER_FILTER(COLORBALANCE,   colorbalance,   vf);
diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
index a2c0fddd98..cef855d891 100644
--- a/libavfilter/vf_avgblur_vulkan.c
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -79,9 +79,6 @@ static av_cold int init_filter(AVFilterContext *ctx, AVFrame 
*in)
 int err;
 AvgBlurVulkanContext *s = ctx->priv;
 
-/* Create sampler */
-ff_vk_init_sampler(ctx, NULL);
-
 { /* Create the shader */
 const int planes = av_pix_fmt_count_planes(s->vkctx.output_format);
 
diff --git a/libavfilter/vf_chromaticaberration_vulkan.c 
b/libavfilter/vf_chromaticaberration_vulkan.c
new file mode 100644
index 00..e7497e7384
--- /dev/null
+++ b/libavfilter/vf_chromaticaberration_vulkan.c
@@ -0,0 +1,334 @@
+/*
+ * 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/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct ChromaticAberrationVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+AVVkExecContext exec;
+AVVkBuffer shader_buf;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+float dist_x;
+float dist_y;
+} ChromaticAberrationVulkanContext;
+
+#define RET(x) \
+do { \
+if ((err = (x)) < 0) \
+goto fail; \
+} while (0)
+
+static const char distort_chroma_kernel[] = {
+C(0, void distort_chroma(int idx, ivec2 size, ivec2 pos)   
)
+C(0, { 
)

[FFmpeg-devel] [PATCH] doc/encoders - list missing options for x265

[Gyan Doshi]

From dafcf437cf6ef407b95b63ac21589137c0e78c9b Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Fri, 30 Mar 2018 19:19:09 +0530
Subject: [PATCH] doc/encoders - list missing options for x265

Add entries for crf and profile in libx265 section
---
 doc/encoders.texi | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index f25d47e272..7b095754d1 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -2159,6 +2159,12 @@ Set the x265 preset.
 @item tune
 Set the x265 tune parameter.
 
+@item profile
+Set profile restrictions.
+
+@item crf
+Set the quality for constant quality mode.
+
 @item forced-idr
 Normally, when forcing a I-frame type, the encoder can select any type
 of I-frame. This option forces it to choose an IDR-frame.
-- 
2.12.2.windows.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mpeg: fix PCM-DVD mis-detection as MLP

[Paul B Mahol]

Fixes #6563.

Signed-off-by: Paul B Mahol 
---
 libavformat/mpeg.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index abdc6a937c..69d4a9d8ac 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -568,7 +568,7 @@ redo:
 codec_id = AV_CODEC_ID_DTS;
 } else if (startcode >= 0xa0 && startcode <= 0xaf) {
 type = AVMEDIA_TYPE_AUDIO;
-if (lpcm_header_len == 6 || startcode == 0xa1) {
+if (lpcm_header_len >= 6 && startcode == 0xa1) {
 codec_id = AV_CODEC_ID_MLP;
 } else {
 codec_id = AV_CODEC_ID_PCM_DVD;
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 4/8] avformat/utils: function to check and ignore non fatal network errors

[wm4]

On Fri, 30 Mar 2018 10:38:34 +0530
vdi...@akamai.com wrote:

> From: Vishwanath Dixit 
> 
> For live HLS/DASH output usecases, currently ffmpeg application exits
> for any network error during muxing. However, some of the errors like
> EPIPE, ECONNREFUSED and ECONNRESET are non-fatal. They might cause
> temporary disruption. However, muxer can recover and continue further
> processing.
> ---
>  libavformat/internal.h | 11 +++
>  libavformat/utils.c| 10 ++
>  2 files changed, 21 insertions(+)
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index a020b1b..e56f867 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -731,6 +731,17 @@ int ff_unlock_avformat(void);
>   */
>  void ff_format_set_url(AVFormatContext *s, char *url);
>  
> +/**
> + * Handle error.
> + * Ignores network errors EPIPE, ECONNREFUSED and ECONNRESET
> + *
> + * @param s AVFormatContext
> + * @param err error code
> + * @param ignore_nw_err flag to ignore network errors
> + * @return 0 if error is ignored, else err
> + */
> +int av_handle_error(AVFormatContext *s, int err, int ignore_nw_err);

av_ is for public API only.

> +
>  #if FF_API_NEXT
>  /**
>* Register devices in deprecated format linked list.
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index f13c820..a942ad0 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -5658,3 +5658,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  FF_ENABLE_DEPRECATION_WARNINGS
>  #endif
>  }
> +
> +int av_handle_error(AVFormatContext *s, int err, int ignore_nw_err) {
> +if (err && ff_is_http_proto(s->url) && ignore_nw_err &&

It's absurd and not really acceptable to check for the HTTP protocol in
such a function. Instead, and if it really makes sense, these kind of
error checks should be done in the HTTP implementation.

> +(err == AVERROR(EPIPE) || err == AVERROR(ECONNREFUSED) ||
> + err == AVERROR(ECONNRESET))) {
> +av_log(s, AV_LOG_WARNING, "Ignored network error %d\n", err);
> +return 0;
> +}
> +return err;
> +}

(Not sure if I'm sending this mail twice. My shitty mail client froze
over yet again.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] lavf/tcp.c: Free allocated client URLContext in case of error.

[Stephan Holljes]

On Fri, Jan 12, 2018 at 8:47 PM, Michael Niedermayer
 wrote:
> On Fri, Jan 12, 2018 at 07:16:30PM +0100, Stephan Holljes wrote:
>> Signed-off-by: Stephan Holljes 
>> ---
>>  libavformat/tcp.c | 4 +++-
>>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> patchset is probably ok
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> It is what and why we do it that matters, not just one of them.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 1/8] avformat/avio: check for null context to avoid uninitialized pointer access

[wm4]

On Fri, 30 Mar 2018 10:38:09 +0530
vdi...@akamai.com wrote:

> From: Vishwanath Dixit 
> 
> ---
>  libavformat/avio.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/avio.c b/libavformat/avio.c
> index 63e8287..18e58ae 100644
> --- a/libavformat/avio.c
> +++ b/libavformat/avio.c
> @@ -420,7 +420,7 @@ int ffurl_read_complete(URLContext *h, unsigned char 
> *buf, int size)
>  
>  int ffurl_write(URLContext *h, const unsigned char *buf, int size)
>  {
> -if (!(h->flags & AVIO_FLAG_WRITE))
> +if (!h || !(h->flags & AVIO_FLAG_WRITE))
>  return AVERROR(EIO);
>  /* avoid sending too big packets */
>  if (h->max_packet_size && size > h->max_packet_size)

You shouldn't write to a NULL context, nor should you be able to.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[wm4]

On Fri, 30 Mar 2018 12:20:38 +0200
Michael Niedermayer  wrote:

> On Thu, Mar 29, 2018 at 09:08:52PM +0200, wm4 wrote:
> > On Thu, 29 Mar 2018 20:55:52 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Thu, Mar 29, 2018 at 08:49:21PM +0200, Michael Niedermayer wrote:  
> > > > On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:
> > > > > On 3/29/2018 2:13 AM, Michael Niedermayer wrote:
> > > > > > Well, no unless we want a single unified API that represents 
> > > > > > information
> > > > > > about timespans.
> > > > > > We can use completely unrelated systems to handle the virtual 
> > > > > > timeline,
> > > > > > the codec and related changes, chapters, ...
> > > > > 
> > > > > Personal opinion time: From design and use perspective, an single 
> > > > > unified
> > > > > API to handle all of those things an their edge cases sounds like a
> > > > > nightmare to use and write.
> > > > 
> > > > That is not what i meant
> > > > 
> > > > what i meant is to align the APIs that handle timespan related 
> > > > information
> > > > and not have totally different interfaces for each.
> > > > For example they might share the same struct in some cases to deliver 
> > > > data
> > > > They do have in common that they all in/export data for a sequence of 
> > > > timespans
> > > > 
> > > > Also the function interfaces could be aligned to each other
> > > > 
> > > > They also may have in common that some formats store the data 
> > > > interleaved
> > > > at the time and some store it in a main header.
> > > > If this is so the case of collecting all this info from the whole
> > > > duration of a file to store it in the output file header at the start
> > > > may be a situation common to multiple of these.
> > > > A similar API may allow simplifying whichever way we handle this
> > > > 
> > > > Iam sure there are more advantages of having APIs which deal with
> > > > similar types of data to be similar ...
> > > 
> > > an example of an API that serves a similar kind of information but is
> > > differnt is AVChapter
> > > I think we should minimize the amount of different public structs that 
> > > describe timespans when that is easily and cleanly possible  
> >   
> 
> > Like how?  
> 
> Wait, you cannot think of a single way on how to store timespan data
> except by using a completely seperate and different API for each case where
> we need to store timespan data? Like not even similarity in the order of
> arguments of functions.
> because thats ultimatly the only thing i suggested we should not do.

I can think of thousand things. I could bikeshed proposals all day,
believe me.

But making very vague suggestions that can't be acted upon and that are
out of this world anyway is not a good way to make progress. You're
just lengthening the discussion by forcing Derek to pull concrete ideas
out of your nose.

If you have an idea that you think is much better, just make a concrete
proposal.

> 
> > 
> > This sounds like a bikeshed smoke bomb to stop all progress again.  
> 
> Why do you try to incite hostilities and discord ?

Well, why do you seemingly put brakes on this patch, with nothing
real to say, just vague proposals about generalizing everything to a
generic thing?

> I mean derek (who wrote the patch) has not even had time to reply to my
> comment. 
> I am very interrested in what his oppinion is, does he agree? does he
> think its impossible or too hard or irrelevant ? Or does he see something
> i didnt think of at all.
> 
> Lets wait for derek before arguing over it.

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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[wm4]

On Fri, 30 Mar 2018 13:22:25 +0200
Michael Niedermayer  wrote:

> On Fri, Mar 30, 2018 at 03:23:25AM +0200, wm4 wrote:
> > On Fri, 30 Mar 2018 03:13:07 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:  
> > > > PSEUDOPAL pixel formats are not paletted, but carried a palette with the
> > > > intention of allowing code to treat unpaletted formats as paletted. The
> > > > palette simply mapped the byte values to the resulting RGB values,
> > > > making it some sort of LUT for RGB conversion.
> > > > 
> > > > It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
> > > > GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
> > > > formats. The last one, GRAY8, is more common, but its treatment is
> > > > grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
> > > > from typical Y video planes was not mapped to the correct RGB values.
> > > > Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
> > > > All other code had to treat it as a special case, just to ignore or
> > > > propagate palette data.
> > > > 
> > > > In conclusion, this was just a very strange old hack that has no real
> > > > justification to exist. It's negatively useful, because API users who
> > > > allocate their own pixel data have to be aware that they need to
> > > > allocate the palette, or FFmpeg will crash on them in _some_ situations.
> > > > On top of this, there was no API to allocate the pseuo palette outside
> > > > of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
> > > > which is good, because GRAY8 treatment is broken.)
> > > > 
> > > > This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
> > > > the pseudo palette optional. Nothing accesses it anymore, though if it's
> > > > set, it's propagated. It's still allocated and initialized for
> > > > compatibility with API users that rely on this feature. But new API
> > > > users do not need to allocate it. This was an explicit goal of this
> > > > patch.
> > > > 
> > > > Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
> > > > first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
> > > > macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
> > > > 
> > > > Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
> > > > FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
> > > > functions manually changed to not allocating a palette.
> > > > ---
> > > 
> > > iam not sure if your rants / political views belong in a commit message.
> > > I think they should be removed.   
> > 
> > There are no "political" views. Please point out which parts you think
> > are political, and why they supposedly are political.
> > 
> > There are no rants either. In fact, calling them rants is disrespectful
> > and implies there is no logic behind whatever parts you think are rants.  
> 
> you made disrespectful comments in the commit message above.
> That is implying code others have written is
> "this was just a very strange old hack that has no real justification to 
> exist"
> "It's negatively useful"

This is because you take this personally for some reason.

This thing might have had a justification in the old days, when these 1
byte formats made up a significant part of all pixfmts, and handling
some as simply paletted could possibly have simplified code.

You have to admit that carrying a static colorspace conversion LUT
(just to RGB) as a palette as additional AVFrame data pointer is a bit
strange, and could also be called a hack. Let me know if you disagree.

My point is that this mechanism hasn't well aged, and any
expectations the original author might have had from this weren't
fulfilled (or at least not anymore in recent times). Indeed, there was
no code in FFmpeg that even relied on this, except xwdenc (which in
itself has a questionable usefulness, because it's an encoder for the
mostly-raw format of a certain X11 screenshot utility that probably
nobody uses anymore - reading is already a stretch, but encoding is
likely not to be used by anyone).

In the newest time, API users are surprised by this pseudopal
mechanism, and ran into it only because _some_ FFmpeg code crashed in
AVFrame with pseudopal formats that didn't have a palette (source: it
happened to me). As such, it doesn't really help anyone (see above),
but actually causes more work to some (see this paragraph). So I think
"negatively useful" is a justified expression and is not disrespectful
to anyone. (Who would I even address? I don't even know who the
original author was. I just looked and it's actually hard to determine.
I only see a commit by a Libav developer in 2012, which added the flag
to complement the already existing mechanism. As far as disrespect
goes, there is/has been plenty of _actual_ disrespect against Libav

[FFmpeg-devel] [PATCH] [RFC]doc/examples: alternative input handler

[Bodecs Bela]

Hi All,

regularly, on different forums and mailing lists a requirement popups 
for a feature to automatically failover switching between main input and a

secondary input in case of main input unavailability.

The base motivation: let's say you have a unreliable live stream source 
and you

want to transcode its video and audio streams in realtime but you
want to survive the ocasions when the source is unavailable. So use a
secondary live source but the transition should occur seamlessly without
breaking/re-starting the transcoding processs.

Some days ago there was a discussion on devel-irc about this topic and 
we concluded that this feature is not feasible inside ffmpeg without 
"hacking", but a separate client app could do this.


So I created this example app to handle two separate input sources and 
switching realtime between them. I am not sure wheter it should be 
inside the tools subdir.


The detailed description is available in the header section of the 
source file.


I will appretiate your suggestions about it.

Thank you in advance.

best,

Bela Bodecs


>From aa7ed4cdaa3411f7481d6ffa00a5d366a0386525 Mon Sep 17 00:00:00 2001
From: Bela Bodecs 
Date: Fri, 30 Mar 2018 14:30:25 +0200
Subject: [PATCH] [RFC]doc/examples: alternative input handler

API utility for automatic failover switching between main input and
secondary input in case of input unavailability.
Motivation: let's say you have a unreliable live stream source and you
want totranscode its first video and audio stream in realtime but you
want to survive the ocasions when the source is unavailable. So use a
secondary live source but the transition should occur seamlessly without
breaking/re-starting the transcoding processs.
See the source file header section for detailed description.


Signed-off-by: Bela Bodecs 
---
 configure|2 +
 doc/examples/Makefile|1 +
 doc/examples/Makefile.example|1 +
 doc/examples/alternative_input.c | 1233 ++
 4 files changed, 1237 insertions(+)
 create mode 100644 doc/examples/alternative_input.c

diff --git a/configure b/configure
index 0c5ed07..5585c60 100755
--- a/configure
+++ b/configure
@@ -1529,6 +1529,7 @@ EXAMPLE_LIST="
 transcoding_example
 vaapi_encode_example
 vaapi_transcode_example
+alternative_input_example
 "
 
 EXTERNAL_AUTODETECT_LIBRARY_LIST="
@@ -3337,6 +3338,7 @@ transcode_aac_example_deps="avcodec avformat swresample"
 transcoding_example_deps="avfilter avcodec avformat avutil"
 vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
 vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
+alternative_input_example_deps="avfilter avcodec avformat avutil"
 
 # EXTRALIBS_LIST
 cpu_init_extralibs="pthreads_extralibs"
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 928ff30..3c50eca 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -21,6 +21,7 @@ EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
 EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE)   += transcoding
 EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE)  += vaapi_encode
 EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE)   += vaapi_transcode
+EXAMPLES-$(CONFIG_ALTERNATIVE_INPUT_EXAMPLE) += alternative_input
 
 EXAMPLES   := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
 EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/Makefile.example b/doc/examples/Makefile.example
index 6428154..937d266 100644
--- a/doc/examples/Makefile.example
+++ b/doc/examples/Makefile.example
@@ -30,6 +30,7 @@ EXAMPLES=   avio_dir_cmd   \
 scaling_video  \
 transcode_aac  \
 transcoding\
+alternative_input  \ 
 
 OBJS=$(addsuffix .o,$(EXAMPLES))
 
diff --git a/doc/examples/alternative_input.c b/doc/examples/alternative_input.c
new file mode 100644
index 000..3d1e534
--- /dev/null
+++ b/doc/examples/alternative_input.c
@@ -0,0 +1,1233 @@
+/*
+ * Copyright (c) 2018 Bodecs Bela
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR 

[FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

[Steve Lhomme]

Remove the wincrypt API calls since we don't support XP anymore and bcrypt is
available since Vista, even on Windows Store builds.
---
 configure   |  6 +++---
 libavutil/random_seed.c | 20 ++--
 2 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/configure b/configure
index 99570a1415..dae52d8f3b 100755
--- a/configure
+++ b/configure
@@ -2141,10 +2141,10 @@ SYSTEM_FUNCS="
 "
 
 SYSTEM_LIBRARIES="
+bcrypt
 vaapi_drm
 vaapi_x11
 vdpau_x11
-wincrypt
 "
 
 TOOLCHAIN_FEATURES="
@@ -3442,7 +3442,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -5823,9 +5823,9 @@ check_header asm/types.h
 check_builtin stdatomic stdatomic.h "atomic_int foo, bar = 
ATOMIC_VAR_INIT(-1); atomic_store(, 0)"
 
 check_lib advapi32 "windows.h"RegCloseKey  -ladvapi32
+check_lib bcrypt   "windows.h bcrypt.h"   BCryptGenRandom  -lbcrypt
 check_lib ole32"windows.h"CoTaskMemFree-lole32
 check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
-check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
 
 check_lib android android/native_window.h ANativeWindow_acquire -landroid
diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
index 881c23c8c8..ae13a27b8a 100644
--- a/libavutil/random_seed.c
+++ b/libavutil/random_seed.c
@@ -26,9 +26,8 @@
 #if HAVE_IO_H
 #include 
 #endif
-#if HAVE_WINCRYPT
-#include 
-#include 
+#if HAVE_BCRYPT
+#include 
 #endif
 #include 
 #include 
@@ -121,13 +120,14 @@ uint32_t av_get_random_seed(void)
 {
 uint32_t seed;
 
-#if HAVE_WINCRYPT
-HCRYPTPROV provider;
-if (CryptAcquireContext(, NULL, NULL, PROV_RSA_FULL,
-CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
-BOOL ret = CryptGenRandom(provider, sizeof(seed), (PBYTE) );
-CryptReleaseContext(provider, 0);
-if (ret)
+#if HAVE_BCRYPT
+BCRYPT_ALG_HANDLE algo_handle;
+NTSTATUS ret = BCryptOpenAlgorithmProvider(_handle, 
BCRYPT_RNG_ALGORITHM,
+   MS_PRIMITIVE_PROVIDER, 0);
+if (BCRYPT_SUCCESS(ret)) {
+NTSTATUS ret = BCryptGenRandom(algo_handle, , sizeof(seed), 0);
+BCryptCloseAlgorithmProvider(algo_handle, 0);
+if (BCRYPT_SUCCESS(ret))
 return seed;
 }
 #endif
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[Paul B Mahol]

On 3/30/18, Michael Niedermayer  wrote:
> On Fri, Mar 30, 2018 at 03:23:25AM +0200, wm4 wrote:
>> On Fri, 30 Mar 2018 03:13:07 +0200
>> Michael Niedermayer  wrote:
>>
>> > On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
>> > > PSEUDOPAL pixel formats are not paletted, but carried a palette with
>> > > the
>> > > intention of allowing code to treat unpaletted formats as paletted.
>> > > The
>> > > palette simply mapped the byte values to the resulting RGB values,
>> > > making it some sort of LUT for RGB conversion.
>> > >
>> > > It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8,
>> > > BGR8,
>> > > GRAY8. The first 4 are awfully obscure, used only by some ancient
>> > > bitmap
>> > > formats. The last one, GRAY8, is more common, but its treatment is
>> > > grossly incorrect. It considers full range GRAY8 only, so GRAY8
>> > > coming
>> > > from typical Y video planes was not mapped to the correct RGB values.
>> > > Also, nothing actually used the PSEUDOPAL palette data, except
>> > > xwdenc.
>> > > All other code had to treat it as a special case, just to ignore or
>> > > propagate palette data.
>> > >
>> > > In conclusion, this was just a very strange old hack that has no real
>> > > justification to exist. It's negatively useful, because API users who
>> > > allocate their own pixel data have to be aware that they need to
>> > > allocate the palette, or FFmpeg will crash on them in _some_
>> > > situations.
>> > > On top of this, there was no API to allocate the pseuo palette
>> > > outside
>> > > of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not
>> > > public,
>> > > which is good, because GRAY8 treatment is broken.)
>> > >
>> > > This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also
>> > > makes
>> > > the pseudo palette optional. Nothing accesses it anymore, though if
>> > > it's
>> > > set, it's propagated. It's still allocated and initialized for
>> > > compatibility with API users that rely on this feature. But new API
>> > > users do not need to allocate it. This was an explicit goal of this
>> > > patch.
>> > >
>> > > Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
>> > > first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
>> > > macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to
>> > > 0.
>> > >
>> > > Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
>> > > FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
>> > > functions manually changed to not allocating a palette.
>> > > ---
>> >
>> > iam not sure if your rants / political views belong in a commit
>> > message.
>> > I think they should be removed.
>>
>> There are no "political" views. Please point out which parts you think
>> are political, and why they supposedly are political.
>>
>> There are no rants either. In fact, calling them rants is disrespectful
>> and implies there is no logic behind whatever parts you think are rants.
>
> you made disrespectful comments in the commit message above.
> That is implying code others have written is
> "this was just a very strange old hack that has no real justification to
> exist"
> "It's negatively useful"
>
> iam not sure if you are trying to pick a fight or what the point of these
> is
> but
>
> These are clearly not technical comments nor are they correct.
> The code had sense, was usefull, and allowed other code to be simplified.
>
> I called them political rants, maybe they are something else but either way
> i do not belive this belongs in a commit message.
>
>
>
>>
>> > about the patch, ive not tested it yet or looked deeper but
>> > please seperate the identifer renaming out into its own patch, that way
>> > it will be much more readable.
>>
>> There's nothing being renamed.
>
> Of course there is, the whole patch is full of changes like this:
>
> @@ -423,7 +425,7 @@ static int raw_decode(AVCodecContext *avctx, void *data,
> int *got_frame,
>  }
>
>  if ((avctx->pix_fmt == AV_PIX_FMT_PAL8 && buf_size <
> context->frame_size) ||
> -(desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)) {
> +(desc->flags & FF_PSEUDOPAL)) {
>  frame->buf[1]  = av_buffer_ref(context->palette);
>  if (!frame->buf[1]) {
>  av_buffer_unref(>buf[0]);
>
> Here above its clearly vissible but in many hunks its intermixed with other
> changes making the patch hard to read
>
>
>> This is the deprecation. Do you prefer if
>> I litter the code with ifdefs instead? Did you read the commit message?
>
> I did read the commit message, otherwise how could i complain about it?
>
>
>>
>> >
>> > thx
>>
>> If you meant it you'd do a proper review.
>
> Please stop with these disrespectful snide comments.
> I intended to review it once the renaming is split out.
>
> thank you

Why you and some other 'old' developers have urge to block every single patch
that comes from some developers?

Re: [FFmpeg-devel] [PATCH 2/2] pixdesc: deprecate AV_PIX_FMT_FLAG_PSEUDOPAL

[Michael Niedermayer]

On Fri, Mar 30, 2018 at 03:23:25AM +0200, wm4 wrote:
> On Fri, 30 Mar 2018 03:13:07 +0200
> Michael Niedermayer  wrote:
> 
> > On Thu, Mar 29, 2018 at 03:30:43PM +0200, wm4 wrote:
> > > PSEUDOPAL pixel formats are not paletted, but carried a palette with the
> > > intention of allowing code to treat unpaletted formats as paletted. The
> > > palette simply mapped the byte values to the resulting RGB values,
> > > making it some sort of LUT for RGB conversion.
> > > 
> > > It was used for 1 byte formats only: RGB4_BYTE, BGR4_BYTE, RGB8, BGR8,
> > > GRAY8. The first 4 are awfully obscure, used only by some ancient bitmap
> > > formats. The last one, GRAY8, is more common, but its treatment is
> > > grossly incorrect. It considers full range GRAY8 only, so GRAY8 coming
> > > from typical Y video planes was not mapped to the correct RGB values.
> > > Also, nothing actually used the PSEUDOPAL palette data, except xwdenc.
> > > All other code had to treat it as a special case, just to ignore or
> > > propagate palette data.
> > > 
> > > In conclusion, this was just a very strange old hack that has no real
> > > justification to exist. It's negatively useful, because API users who
> > > allocate their own pixel data have to be aware that they need to
> > > allocate the palette, or FFmpeg will crash on them in _some_ situations.
> > > On top of this, there was no API to allocate the pseuo palette outside
> > > of av_frame_get_buffer(). (avpriv_set_systematic_pal2() was not public,
> > > which is good, because GRAY8 treatment is broken.)
> > > 
> > > This patch not only deprecates AV_PIX_FMT_FLAG_PSEUDOPAL, but also makes
> > > the pseudo palette optional. Nothing accesses it anymore, though if it's
> > > set, it's propagated. It's still allocated and initialized for
> > > compatibility with API users that rely on this feature. But new API
> > > users do not need to allocate it. This was an explicit goal of this
> > > patch.
> > > 
> > > Most changes replace AV_PIX_FMT_FLAG_PSEUDOPAL with FF_PSEUDOPAL. I
> > > first tried #ifdefing all code, but it was a mess. The FF_PSEUDOPAL
> > > macro reduces the mess, and still allows defining FF_API_PSEUDOPAL to 0.
> > > 
> > > Passes FATE with FF_API_PSEUDOPAL enabled and disabled. In addition,
> > > FATE passes with FF_API_PSEUDOPAL set to 1, but with allocation
> > > functions manually changed to not allocating a palette.
> > > ---  
> > 
> > iam not sure if your rants / political views belong in a commit message.
> > I think they should be removed. 
> 
> There are no "political" views. Please point out which parts you think
> are political, and why they supposedly are political.
> 
> There are no rants either. In fact, calling them rants is disrespectful
> and implies there is no logic behind whatever parts you think are rants.

you made disrespectful comments in the commit message above.
That is implying code others have written is
"this was just a very strange old hack that has no real justification to exist"
"It's negatively useful"

iam not sure if you are trying to pick a fight or what the point of these is
but

These are clearly not technical comments nor are they correct.
The code had sense, was usefull, and allowed other code to be simplified.

I called them political rants, maybe they are something else but either way
i do not belive this belongs in a commit message.



> 
> > about the patch, ive not tested it yet or looked deeper but
> > please seperate the identifer renaming out into its own patch, that way
> > it will be much more readable.
> 
> There's nothing being renamed. 

Of course there is, the whole patch is full of changes like this:

@@ -423,7 +425,7 @@ static int raw_decode(AVCodecContext *avctx, void *data, 
int *got_frame,
 }

 if ((avctx->pix_fmt == AV_PIX_FMT_PAL8 && buf_size < context->frame_size) 
||
-(desc->flags & AV_PIX_FMT_FLAG_PSEUDOPAL)) {
+(desc->flags & FF_PSEUDOPAL)) {
 frame->buf[1]  = av_buffer_ref(context->palette);
 if (!frame->buf[1]) {
 av_buffer_unref(>buf[0]);

Here above its clearly vissible but in many hunks its intermixed with other
changes making the patch hard to read

 
> This is the deprecation. Do you prefer if
> I litter the code with ifdefs instead? Did you read the commit message?

I did read the commit message, otherwise how could i complain about it?


> 
> > 
> > thx
> 
> If you meant it you'd do a proper review.

Please stop with these disrespectful snide comments.
I intended to review it once the renaming is split out.

thank you

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

Those who are best at talking, realize last or never when they are wrong.


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

Re: [FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

[Hendrik Leppkes]

On Fri, Mar 30, 2018 at 9:23 AM, Steve Lhomme  wrote:
> When targeting Windows Vista and above
> The wincrypt API is deprecated and not allowed for Windows Store apps.
> ---
>  configure   |  4 +++-
>  libavutil/random_seed.c | 16 ++--
>  2 files changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/configure b/configure
> index 99570a1415..6d34728b83 100755
> --- a/configure
> +++ b/configure
> @@ -2144,6 +2144,7 @@ SYSTEM_LIBRARIES="
>  vaapi_drm
>  vaapi_x11
>  vdpau_x11
> +bcrypt
>  wincrypt
>  "
>
> @@ -3442,7 +3443,7 @@ avformat_deps="avcodec avutil"
>  avformat_suggest="libm network zlib"
>  avresample_deps="avutil"
>  avresample_suggest="libm"
> -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 
> vaapi videotoolbox corefoundation corevideo coremedia wincrypt"
> +avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 
> vaapi videotoolbox corefoundation corevideo coremedia bcrypt wincrypt"
>  postproc_deps="avutil gpl"
>  postproc_suggest="libm"
>  swresample_deps="avutil"
> @@ -5827,6 +5828,7 @@ check_lib ole32"windows.h"CoTaskMemFree 
>-lole32
>  check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
>  check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
>  check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
> +check_cpp_condition windows.h "_WIN32_WINNT >= 0x0600" && check_lib bcrypt 
> "windows.h bcrypt.h" BCryptGenRandom  -lbcrypt
>

FFmpeg does not support building for XP anymore, so you can skip that condition.

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

Re: [FFmpeg-devel] [PATCH][RFC] avcodec/avutil: Add timeline side data

[Michael Niedermayer]

On Thu, Mar 29, 2018 at 09:08:52PM +0200, wm4 wrote:
> On Thu, 29 Mar 2018 20:55:52 +0200
> Michael Niedermayer  wrote:
> 
> > On Thu, Mar 29, 2018 at 08:49:21PM +0200, Michael Niedermayer wrote:
> > > On Thu, Mar 29, 2018 at 02:53:52PM +0100, Derek Buitenhuis wrote:  
> > > > On 3/29/2018 2:13 AM, Michael Niedermayer wrote:  
> > > > > Well, no unless we want a single unified API that represents 
> > > > > information
> > > > > about timespans.
> > > > > We can use completely unrelated systems to handle the virtual 
> > > > > timeline,
> > > > > the codec and related changes, chapters, ...  
> > > > 
> > > > Personal opinion time: From design and use perspective, an single 
> > > > unified
> > > > API to handle all of those things an their edge cases sounds like a
> > > > nightmare to use and write.  
> > > 
> > > That is not what i meant
> > > 
> > > what i meant is to align the APIs that handle timespan related information
> > > and not have totally different interfaces for each.
> > > For example they might share the same struct in some cases to deliver data
> > > They do have in common that they all in/export data for a sequence of 
> > > timespans
> > > 
> > > Also the function interfaces could be aligned to each other
> > > 
> > > They also may have in common that some formats store the data interleaved
> > > at the time and some store it in a main header.
> > > If this is so the case of collecting all this info from the whole
> > > duration of a file to store it in the output file header at the start
> > > may be a situation common to multiple of these.
> > > A similar API may allow simplifying whichever way we handle this
> > > 
> > > Iam sure there are more advantages of having APIs which deal with
> > > similar types of data to be similar ...  
> > 
> > an example of an API that serves a similar kind of information but is
> > differnt is AVChapter
> > I think we should minimize the amount of different public structs that 
> > describe timespans when that is easily and cleanly possible
> 

> Like how?

Wait, you cannot think of a single way on how to store timespan data
except by using a completely seperate and different API for each case where
we need to store timespan data? Like not even similarity in the order of
arguments of functions.
because thats ultimatly the only thing i suggested we should not do.


> 
> This sounds like a bikeshed smoke bomb to stop all progress again.

Why do you try to incite hostilities and discord ?
I mean derek (who wrote the patch) has not even had time to reply to my
comment. 
I am very interrested in what his oppinion is, does he agree? does he
think its impossible or too hard or irrelevant ? Or does he see something
i didnt think of at all.

Lets wait for derek before arguing over it.

thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH 3/3] lavfi: add a Vulkan avgblur filter

[Paul B Mahol]

On 3/30/18, Rostislav Pehlivanov  wrote:
> This commit adds an average blur Vulkan filter which functions
> exactly the same as avgblur but on Vulkan surfaces.
>
> Currently contains a workaround that will be removed for the actual,
> non-RFC version.
>
> It implements a clever way of minimizing texel fetches by storing
> all texels needed to filter and entire wavefront's worth of
> workgroups in a shared cache, and then averaging over the area needed.
>
> Currently, it lacks the ability to avoid edges of images and will mix
> 0s around the edges of planes. This will be fixed for the non-RFC
> version.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_avgblur_vulkan.c | 353
> 
>  4 files changed, 356 insertions(+)
>  create mode 100644 libavfilter/vf_avgblur_vulkan.c
>

Why, why, why this filter again?

Why not gblur filter?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] use bcrypt instead of the old wincrypt API

[Steve Lhomme]

When targeting Windows Vista and above
The wincrypt API is deprecated and not allowed for Windows Store apps.
---
 configure   |  4 +++-
 libavutil/random_seed.c | 16 ++--
 2 files changed, 17 insertions(+), 3 deletions(-)

diff --git a/configure b/configure
index 99570a1415..6d34728b83 100755
--- a/configure
+++ b/configure
@@ -2144,6 +2144,7 @@ SYSTEM_LIBRARIES="
 vaapi_drm
 vaapi_x11
 vdpau_x11
+bcrypt
 wincrypt
 "
 
@@ -3442,7 +3443,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia wincrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt wincrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -5827,6 +5828,7 @@ check_lib ole32"windows.h"CoTaskMemFree   
 -lole32
 check_lib shell32  "windows.h shellapi.h" CommandLineToArgvW   -lshell32
 check_lib wincrypt "windows.h wincrypt.h" CryptGenRandom   -ladvapi32
 check_lib psapi"windows.h psapi.h"GetProcessMemoryInfo -lpsapi
+check_cpp_condition windows.h "_WIN32_WINNT >= 0x0600" && check_lib bcrypt 
"windows.h bcrypt.h" BCryptGenRandom  -lbcrypt
 
 check_lib android android/native_window.h ANativeWindow_acquire -landroid
 check_lib mediandk "stdint.h media/NdkImage.h" AImage_delete -lmediandk
diff --git a/libavutil/random_seed.c b/libavutil/random_seed.c
index 881c23c8c8..d7186146d9 100644
--- a/libavutil/random_seed.c
+++ b/libavutil/random_seed.c
@@ -26,7 +26,9 @@
 #if HAVE_IO_H
 #include 
 #endif
-#if HAVE_WINCRYPT
+#if HAVE_BCRYPT
+#include 
+#elif HAVE_WINCRYPT
 #include 
 #include 
 #endif
@@ -121,7 +123,17 @@ uint32_t av_get_random_seed(void)
 {
 uint32_t seed;
 
-#if HAVE_WINCRYPT
+#if HAVE_BCRYPT
+BCRYPT_ALG_HANDLE algo_handle;
+NTSTATUS ret = BCryptOpenAlgorithmProvider(_handle, 
BCRYPT_RNG_ALGORITHM,
+   MS_PRIMITIVE_PROVIDER, 0);
+if (BCRYPT_SUCCESS(ret)) {
+NTSTATUS ret = BCryptGenRandom(algo_handle, , sizeof(seed), 0);
+BCryptCloseAlgorithmProvider(algo_handle, 0);
+if (BCRYPT_SUCCESS(ret))
+return seed;
+}
+#elif HAVE_WINCRYPT
 HCRYPTPROV provider;
 if (CryptAcquireContext(, NULL, NULL, PROV_RSA_FULL,
 CRYPT_VERIFYCONTEXT | CRYPT_SILENT)) {
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH 8/8] avformat/hlsenc: usage of error handling utility function

[Steven Liu]

> On 30 Mar 2018, at 13:09, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> ---
> doc/muxers.texi  |  9 +
> libavformat/hlsenc.c | 16 +---
> 2 files changed, 18 insertions(+), 7 deletions(-)
> 
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 0d9ecef..a651a49 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -977,6 +977,15 @@ Use persistent HTTP connections. Applicable only for 
> HTTP output.
> @item timeout
> Set timeout for socket I/O operations. Applicable only for HTTP output.
> 
> +@item -ignore_nw_error @var{ignore_nw_error}
> +Enable (1) or disable (0) ignoring the following non-fatal network errors 
> during
> +muxing. Applicable only for HTTP output.
> +@example
> +EPIPE- Broken pipe
> +ECONNREFUSED - Connection refused
> +ECONNRESET   - Connection reset by peer
> +@end example
> +
> @end table
> 
> @anchor{ico}
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 334720f..f6de326 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -225,6 +225,7 @@ typedef struct HLSContext {
> AVIOContext *m3u8_out;
> AVIOContext *sub_m3u8_out;
> int64_t timeout;
> +int ignore_nw_err;
> } HLSContext;
> 
> static int mkdir_p(const char *path) {
> @@ -2247,7 +2248,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> ret = flush_dynbuf(vs, _length);
> if (ret < 0) {
> av_free(old_filename);
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> vs->size = range_length;
> } else {
> @@ -2255,12 +2256,12 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> if (ret < 0) {
> av_log(s, AV_LOG_ERROR, "Failed to open file '%s'\n",
>vs->avf->url);
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> write_styp(vs->out);
> ret = flush_dynbuf(vs, _length);
> if (ret < 0) {
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> ff_format_io_close(s, >out);
> }
> @@ -2277,7 +2278,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> vs->duration = 0;
> if (ret < 0) {
> av_free(old_filename);
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> }
> 
> @@ -2308,12 +2309,12 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> av_free(old_filename);
> 
> if (ret < 0) {
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> 
> if (!vs->fmp4_init_mode || byterange_mode)
> if ((ret = hls_window(s, 0, vs)) < 0) {
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> }
> 
> @@ -2321,7 +2322,7 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> if (oc->pb)
> ret = ff_write_chained(oc, stream_index, pkt, s, 0);
> 
> -return ret;
> +return av_handle_error(s, ret, hls->ignore_nw_err);
> }
> 
> static int hls_write_trailer(struct AVFormatContext *s)
> @@ -2835,6 +2836,7 @@ static const AVOption options[] = {
> {"master_pl_publish_rate", "Publish master play list every after this 
> many segment intervals", OFFSET(master_publish_rate), AV_OPT_TYPE_INT, {.i64 
> = 0}, 0, UINT_MAX, E},
> {"http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> {"timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
> AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
> +{ "ignore_nw_error", "Ignores any non-fatal network errors during 
> muxing", OFFSET(ignore_nw_err), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
> { NULL },
> };
> 
> -- 
> 1.9.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM
Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH 7/8] avformat/hlsenc: check for null context to avoid uninitialized pointer access

[Steven Liu]

> On 30 Mar 2018, at 13:09, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> Under error conditions, when the context is null, the application crashes
> without this check.
> ---
> libavformat/hlsenc.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 1dd196f..334720f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2318,7 +2318,8 @@ static int hls_write_packet(AVFormatContext *s, 
> AVPacket *pkt)
> }
> 
> vs->packets_written++;
> -ret = ff_write_chained(oc, stream_index, pkt, s, 0);
> +if (oc->pb)
> +ret = ff_write_chained(oc, stream_index, pkt, s, 0);
> 
> return ret;
> }
> -- 
> 1.9.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
LGTM

Thanks
Steven





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

Re: [FFmpeg-devel] [PATCH 6/8] avformat/hlsenc: handling errors in hlsenc_io_open and hlsenc_io_close

[Steven Liu]

> On 30 Mar 2018, at 13:08, vdi...@akamai.com wrote:
> 
> From: Vishwanath Dixit 
> 
> ---
> libavformat/hlsenc.c | 4 
> 1 file changed, 4 insertions(+)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2a54b43..1dd196f 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -272,6 +272,8 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
> **pb, char *filename,
> URLContext *http_url_context = ffio_geturlcontext(*pb);
> av_assert0(http_url_context);
> err = ff_http_do_new_request(http_url_context, filename);
> +if (err < 0)
> +ff_format_io_close(s, pb);
> #endif
> }
> return err;
> @@ -280,6 +282,8 @@ static int hlsenc_io_open(AVFormatContext *s, AVIOContext 
> **pb, char *filename,
> static void hlsenc_io_close(AVFormatContext *s, AVIOContext **pb, char 
> *filename) {
> HLSContext *hls = s->priv_data;
> int http_base_proto = filename ? ff_is_http_proto(filename) : 0;
> +if (!*pb)
> +return;
> if (!http_base_proto || !hls->http_persistent || hls->key_info_file || 
> hls->encrypt) {
> ff_format_io_close(s, pb);
> #if CONFIG_HTTP_PROTOCOL
> -- 
> 1.9.1
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

LGTM

Thanks
Steven





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