Re: [FFmpeg-devel] [PATCH] Add android_capture indev

Am 22.11.2017 00:20, schrieb Michael Niedermayer: On Tue, Nov 21, 2017 at 08:16:08AM +0100, Felix Matouschek wrote: No more interest? If you hear no more comments for another week, then please ping this with CC to me and ill take a look and apply unless i spot some major issue also you probab

Re: [FFmpeg-devel] AMD external header

On 27.11.2017 17:14, Pavel Koshevoy wrote: On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George wrote: Mironov, Mikhail (2017-11-27): #1 policy: do not include external headers goal: minimize maintenance efforts and increase stability of the project action: remove NVidia headers Add t

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On 2017-11-27 15:00, Carl Eugen Hoyos wrote: 2017-11-26 22:44 GMT+01:00 Jim DeLaHunt : So, how realistic is this concern about non-subscribers sending patches to ffmpeg-devel? Does it actually happen? This is very realistic afair. OK, and Lou Logan corroborates Carl Eugen: On 2017-11-27 15:1

[FFmpeg-devel] [PATCH] vaapi_h265: general_level_idc should times 3.

Signed-off-by: Ruiling Song --- libavcodec/vaapi_encode_h265.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c index 3ae92a7..32b8bc6 100644 --- a/libavcodec/vaapi_encode_h265.c +++ b/libavcodec/vaapi_encode_h265.

[FFmpeg-devel] [PATCH] lavc/qsvenc: set HRD buffer size

Hypothetical Reference Decoding (HRD) model assumes that data flows into a buffer of the fixed size BufferSizeInKB with a constant bitrate. BufferSizeInKB represents the maximum possible size of any compressed frames. Signed-off-by: Zhong Li --- libavcodec/qsvenc.c | 2 +- 1 file changed, 1 inse

Re: [FFmpeg-devel] [PATCH] lavu/hwcontext_opencl.h: fix build on macOS

On 2017/11/28 13:38, Rodger Combs wrote: > --- > libavutil/hwcontext_opencl.h | 4 > 1 file changed, 4 insertions(+) > > diff --git a/libavutil/hwcontext_opencl.h b/libavutil/hwcontext_opencl.h > index 8e34df44cd..ef54486c95 100644 > --- a/libavutil/hwcontext_opencl.h > +++ b/libavutil/hwco

[FFmpeg-devel] [PATCH] lavu/hwcontext_opencl.h: fix build on macOS

--- libavutil/hwcontext_opencl.h | 4 1 file changed, 4 insertions(+) diff --git a/libavutil/hwcontext_opencl.h b/libavutil/hwcontext_opencl.h index 8e34df44cd..ef54486c95 100644 --- a/libavutil/hwcontext_opencl.h +++ b/libavutil/hwcontext_opencl.h @@ -19,7 +19,11 @@ #ifndef AVUTIL_HWCONTEX

[FFmpeg-devel] [PATCH] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change.

From 94d511d93fdb83103fdafbd9ca0d02abfbd2e305 Mon Sep 17 00:00:00 2001 From: Jun Zhao Date: Tue, 28 Nov 2017 21:05:18 +0800 Subject: [PATCH] lavc/vp8: Fix HWAccel VP8 decoder can't support resolution change. Use the following command to reproduce this issue: make fate-vp8-size-change HWACCEL="v

[FFmpeg-devel] [PATCH 0/2] avcodec: metadata for hardware backed decoders

We have a number of hardware backed implementations in the codebase that are done as full decoders instead of HWAccels for various reasons. These decoders cannot be discovered today, and clients which care end up needing to hardcode their names. It would be helpful to provide a discovery mechanism.

[FFmpeg-devel] [PATCH 1/2] avcodec: Add metadata to identify hardware backed codecs

If hardware acceleration is implemented through an HWAccel, then it's easy to recognise, but some hardware implementations are best suited to implementation as full decoders, and these are not easy to identify. Clients typically need hardcoded lists of codecs, and usually need to rely on related co

[FFmpeg-devel] [PATCH 2/2] avcodec: Add hardware metadata to hardware backed decoders

Now that we have a way to identify hardware backed decoders, let us do so. I may have missed some. Signed-off-by: Philip Langdale --- libavcodec/crystalhd.c | 4 +++- libavcodec/cuviddec.c | 4 +++- libavcodec/mediacodecdec.c | 24 ++-- libavcodec/mmaldec.c |

Re: [FFmpeg-devel] [PATCH 3/4] avformat/mxfenc: write reel_name if metadata key is present

On Mon, Nov 27, 2017 at 2:40 AM, Tomas Härdin wrote: > On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote: > > @@ -1396,13 +1410,17 @@ static int mxf_write_package(AVFormatContext > > *s, MXFPackage *package) > > } > > > > // write multiple descriptor reference > > -if (package->typ

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfenc: use track count to generate component instance uuid

On Mon, Nov 27, 2017 at 2:14 AM, Tomas Härdin wrote: > On Sun, 2017-11-26 at 21:42 -0800, Mark Reid wrote: > > --- > > libavformat/mxf.h | 1 - > > libavformat/mxfenc.c| 45 + > > > > tests/ref/fate/copy-trac4914| 2 +- > >

[FFmpeg-devel] [PATCH 2/3 v2] avformat/mux: stop delaying writing the header

Every bitstream filter behaves as intended now, so there's no need to wait for the first packet of every stream. Signed-off-by: James Almer --- Now without overloading ret in avformat_write_header. libavformat/avformat.h | 2 +- libavformat/internal.h | 6 - libavformat/mu

Re: [FFmpeg-devel] [PATCH] [dnxhddec] Do not overwrite colorspace if the container has set it.

It's... less wrong. The VC-3 DNxHR update added a 'clv' field to an existing byte in the frame header to allow for the carriage of a limited set of color info (0 = 709/709, 1=2020/2020NCL, 2=2020/2020CL, 3=container specifies), but because that field is new-ish and assigns a meaning other than 'un

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: move some initialization checks to mkv_init

On 11/27/2017 7:44 PM, Carl Eugen Hoyos wrote: > 2017-11-27 18:17 GMT+01:00 James Almer : >> It's the correct place for them. >> >> Signed-off-by: James Almer >> --- >> libavformat/matroskaenc.c | 39 +-- >> 1 file changed, 21 insertions(+), 18 deletions(-) >>

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

> Ok; done, plus some trivial testing to make sure it works. If you're happy > with this and noone else says anything then I'll push it tomorrow. OK. > Relatedly: your name on patches does not match your full name - I've > preserved the patch one here, but was that intended? No, it was how

Re: [FFmpeg-devel] [PATCH] Fix for ticket 6658 (Dash demuxer segfault)

2017-11-28 8:46 GMT+08:00 Colin NG : > --- > libavformat/dashdec.c | 95 > --- > 1 file changed, 82 insertions(+), 13 deletions(-) > > diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c > index 3798649..5d5970e 100644 > --- a/libavformat/das

Re: [FFmpeg-devel] [PATCH] lavc/utils: simplify lockmgr

On Mon, Nov 27, 2017 at 04:44:19AM +, Rostislav Pehlivanov wrote: > Again, totally unneded use of the atomic function to set/NULL a local > variable. > > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/utils.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) this cras

Re: [FFmpeg-devel] [PATCH 1/4] lavc/parser: use C11 atomics

On Mon, Nov 27, 2017 at 04:30:18AM +, Rostislav Pehlivanov wrote: > Signed-off-by: Rostislav Pehlivanov > --- > libavcodec/parser.c | 14 -- > 1 file changed, 8 insertions(+), 6 deletions(-) > > diff --git a/libavcodec/parser.c b/libavcodec/parser.c > index 670680ea7c..baf1de4d88

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

On 11/27/2017 8:52 PM, James Almer wrote: > On 11/27/2017 8:18 PM, Michael Niedermayer wrote: >> On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote: >>> Every bitstream filter behaves as intended now, so there's no need to >>> wait for the first packet of every stream. >>> >>> Signed-off-b

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

On 11/27/2017 9:00 PM, Carl Eugen Hoyos wrote: > 2017-11-28 0:52 GMT+01:00 James Almer : >> On 11/27/2017 8:18 PM, Michael Niedermayer wrote: > >>> this changes slightly: >>> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv >>> >>> not saying this is a issue in the patch or anything

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

--- libavformat/dashdec.c | 95 --- 1 file changed, 82 insertions(+), 13 deletions(-) diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c index 3798649..5d5970e 100644 --- a/libavformat/dashdec.c +++ b/libavformat/dashdec.c @@ -148,6 +148,11

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

On Tue, Nov 28, 2017 at 12:03:38AM +, Derek Buitenhuis wrote: > On 11/21/2017 11:12 PM, Dale Curtis wrote: > > Otherwise ff_alloc_extradata() just leaks any existing allocated > > memory. > > Should be OK. will apply i had tested this one already a bit a few days ago ... thx [...] -- Micha

[FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

From: mmironov Requires AMF headers for at least version 1.4.4.1. --- On 27/11/17 23:45, Mironov, Mikhail wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Mark Thompson >> Sent: November 27, 2017 6:39 PM >> To: ffmpeg-devel@ffmpeg

Re: [FFmpeg-devel] [PATCH] [dnxhddec] Do not overwrite colorspace if the container has set it.

On Mon, Nov 27, 2017 at 12:36:48AM -0800, Steven Robertson wrote: > Signed-off-by: Steven Robertson > --- > libavcodec/dnxhddec.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c > index f46e41a456..6f8c716412 100644 > ---

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On Mon, Nov 27, 2017, at 03:20 PM, Mark Thompson wrote: > > If the intent is that -devel should always be used for replies, can you > set a reply-to header on -cvslog pointing to -devel? Done, thanks. Should have done that years ago. Didn't really think about the cvslog situation much until this d

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On 28/11/17 00:12, Lou Logan wrote: > On Sun, Nov 26, 2017, at 12:57 PM, Jim DeLaHunt wrote: >> I'll observe that we have already heard other opinions: >> >> * Paul[2]: "Not at all. To be a contributor, it is not needed to >> subscribe to [ffmpeg-cvslog] list." >> * Timo[3]: "Usually if a d

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-11-28 1:12 GMT+01:00 Bjorn Roche : > On Mon, Nov 27, 2017 at 5:35 PM, Carl Eugen Hoyos > wrote: > >> 2017-11-27 19:30 GMT+01:00 Bjorn Roche : >> > >> >> > The only way I can see is to move some functionality between the mixer >> and >> > the encoder. It's not a clear line between the codec an

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On Sun, Nov 26, 2017, at 12:57 PM, Jim DeLaHunt wrote: > I'll observe that we have already heard other opinions: > > * Paul[2]: "Not at all. To be a contributor, it is not needed to > subscribe to [ffmpeg-cvslog] list." > * Timo[3]: "Usually if a discussion comes up the mail from cvslog is

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

On Mon, Nov 27, 2017 at 5:35 PM, Carl Eugen Hoyos wrote: > 2017-11-27 19:30 GMT+01:00 Bjorn Roche : > > > > > The only way I can see is to move some functionality between the mixer > and > > the encoder. It's not a clear line between the codec and the container in > > GIF, so I wouldn't object to

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

2017-11-28 1:07 GMT+01:00 Bjorn Roche : > On Mon, Nov 27, 2017 at 5:41 PM, Carl Eugen Hoyos > wrote: >> >> Does remuxing animated gif with transparency work with your patch? >> > >> > A command like this: >> > >> > ffmpeg -i in.gif out.gif >> > >> > seems to produce the same output as before:

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

On 11/21/2017 11:12 PM, Dale Curtis wrote: > Otherwise ff_alloc_extradata() just leaks any existing allocated > memory. Should be OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

On Mon, Nov 27, 2017 at 5:41 PM, Carl Eugen Hoyos wrote: > 2017-11-27 18:50 GMT+01:00 Bjorn Roche : > > Sorry for the very delayed response, Carl: > > > > On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos > > wrote: > > > >> 2017-11-21 18:53 GMT+01:00 Bjorn Roche : > >> > Support for transparenc

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

2017-11-28 0:52 GMT+01:00 James Almer : > On 11/27/2017 8:18 PM, Michael Niedermayer wrote: >> this changes slightly: >> ./ffmpeg -i ~/tickets/2263/2263-slow-ss.mkv -vframes 3 file.mkv >> >> not saying this is a issue in the patch or anything (i am in favor of >> the simplification in fact), just

Re: [FFmpeg-devel] [mov] Remove concept of ctts entries with count > 1.

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

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

On 11/27/2017 8:18 PM, Michael Niedermayer wrote: > On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote: >> Every bitstream filter behaves as intended now, so there's no need to >> wait for the first packet of every stream. >> >> Signed-off-by: James Almer >> --- >> libavformat/avformat.h

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

> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: November 27, 2017 6:39 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for > AMD GPUs based on AMF SDK > > On 27/11/

Re: [FFmpeg-devel] ffmpeg: Check read_ffserver_streams() return value

On Mon, Nov 27, 2017 at 01:23:24AM +, Rostislav Pehlivanov wrote: > On 27 November 2017 at 01:12, Pan Bian wrote: > > > The function avformat_alloc_context() will return a NULL pointer on > > failure. However, in function read_ffserver_streams(), its return value > > is not validated and the

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

On 27/11/17 23:34, Mironov, Mikhail wrote: >> -Original Message- >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >> Of Mark Thompson >> Sent: November 27, 2017 6:25 PM >> To: ffmpeg-devel@ffmpeg.org >> Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encodi

Re: [FFmpeg-devel] libavformat/rtpenc_mpegts: check avformat_new_stream() return value

On Mon, Nov 27, 2017 at 09:30:53AM +0800, Pan Bian wrote: > The function avformat_new_stream() returns a NULL pointer on failure. > However, in function rtp_mpegts_write_header(), its return value is not > validated before it is dereferenced. Check the return value against NULL > to avoid potential

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

> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: November 27, 2017 6:25 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for > AMD GPUs based on AMF SDK > > On 27/11/

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On Mon, Nov 27, 2017, at 02:22 PM, Lou Logan wrote: > > To clarify, in this case it was a reply, not a message. Should have typed "patch" there, not message. Actually reading message before sending this time. ___ ffmpeg-devel mailing list ffmpeg-devel@f

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

On 27/11/17 22:35, Mironov, Mikhail wrote: >>> -Original Message- >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf >>> Of Mark Thompson >>> Sent: November 27, 2017 3:11 PM >>> To: FFmpeg development discussions and patches >> de...@ffmpeg.org> >>> Subject: [FFmpeg-d

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On Mon, Nov 27, 2017, at 02:19 PM, Lou Logan wrote: > A very rough guess is that there are usually at least several > patches from unsubscribed users a week (in fact there was one in the > queue minutes ago). To clarify, in this case it was a reply, not a message. _

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On Mon, Nov 27, 2017, at 02:00 PM, Carl Eugen Hoyos wrote: > No, the mail admins could (or explain that I am wrong.) I would have to check each sender manually to see if they are in the membership database. It would be possible to do this, but not very practical. It would be easier for me to keep

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

On 27 November 2017 at 23:05, Ronald S. Bultje wrote: > Hi, > > On Mon, Nov 27, 2017 at 6:03 PM, Carl Eugen Hoyos > wrote: > > > 2017-11-26 22:57 GMT+01:00 Jim DeLaHunt : > > > On 2017-11-26 03:42, Carl Eugen Hoyos wrote: > > > > > >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt : > > >> [...] > > >>>

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

On Sun, Nov 26, 2017 at 05:51:03PM -0300, James Almer wrote: > Every bitstream filter behaves as intended now, so there's no need to > wait for the first packet of every stream. > > Signed-off-by: James Almer > --- > libavformat/avformat.h | 2 +- > libavformat/internal.h | 6 -

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

2017-11-27 22:53 GMT+01:00 Anssi Hannula : > Hi, > > Rainer Hochecker kirjoitti 2017-11-26 12:46: >> >> fixed mem leak poined out by Steven >> >> --- >> doc/demuxers.texi | 5 + >> libavformat/hls.c | 304 >> -- >> 2 files changed, 209 insertio

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

Hi, On Mon, Nov 27, 2017 at 6:03 PM, Carl Eugen Hoyos wrote: > 2017-11-26 22:57 GMT+01:00 Jim DeLaHunt : > > On 2017-11-26 03:42, Carl Eugen Hoyos wrote: > > > >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt : > >> [...] > >>> > >>> + > >>> @subheading Subscribe to the ffmpeg-cvslog mailing list. >

[FFmpeg-devel] [PATCH]ffmpeg_opt: Silence a const warning

Hi! Attached patch fixes a warning: fftools/ffmpeg_opt.c: In function ‘add_input_streams’: fftools/ffmpeg_opt.c:804:29: warning: assignment discards ‘const’ qualifier from pointer target type Please comment, Carl Eugen From 5e1be030521a4253dc8385567ef359ef794f0820 Mon Sep 17 00:00:00 2001 From: C

Re: [FFmpeg-devel] Accurately describing ffmpeg-cvslog list [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

2017-11-26 22:57 GMT+01:00 Jim DeLaHunt : > On 2017-11-26 03:42, Carl Eugen Hoyos wrote: > >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt : >> [...] >>> >>> + >>> @subheading Subscribe to the ffmpeg-cvslog mailing list. >>> -It is important to do this as the diffs of all commits are sent there >>> and

Re: [FFmpeg-devel] Policy on ffmpeg-devel list and contributions [was: Re: [PATCH] Refactor Developer Docs, update dev list section (v2)]

2017-11-26 22:44 GMT+01:00 Jim DeLaHunt : > On 2017-11-26 03:42, Carl Eugen Hoyos wrote: >> >> 2017-11-26 9:31 GMT+01:00 Jim DeLaHunt : >>> >>> -@subsection Documentation/Other >>> +@section Documentation/Other >>> +@subheading Subscribe to the ffmpeg-devel mailing list. >>> +It is important to be

Re: [FFmpeg-devel] [mov] Remove concept of ctts entries with count > 1.

Any discussion on this one? Would make the oom fix John put together simpler I think. - dale On Mon, Aug 28, 2017 at 4:09 PM, Dale Curtis wrote: > Previous ctts patches have all changed the system to always using > count=1 since we expect ctts data to be 1:1 with samples. This deletes > the con

Re: [FFmpeg-devel] [ogm] Free extradata before reallocating.

Ping? On Tue, Nov 21, 2017 at 3:12 PM, Dale Curtis wrote: > Otherwise ff_alloc_extradata() just leaks any existing allocated > memory. > > Signed-off-by: Dale Curtis > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/l

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavd/alsa: Double maximum alsa buffer size.

2017-11-27 16:29 GMT+01:00 Nicolas George : > Carl Eugen Hoyos (2017-11-27): >> ffmpeg | branch: master | Carl Eugen Hoyos | Mon Nov 27 >> 14:05:28 2017 +0100| [b7324950c0fc84a93d4e7abdfd2b75ea647ec3fc] | committer: >> Carl Eugen Hoyos >> >> lavd/alsa: Double maximum alsa buffer size. >> >> Fixe

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

On Thu, Nov 23, 2017 at 3:54 PM, Carl Eugen Hoyos wrote: > > @Dale: > Could you do that? > Thanks to John for putting out a patch for this. - dale ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: move some initialization checks to mkv_init

2017-11-27 18:17 GMT+01:00 James Almer : > It's the correct place for them. > > Signed-off-by: James Almer > --- > libavformat/matroskaenc.c | 39 +-- > 1 file changed, 21 insertions(+), 18 deletions(-) > > diff --git a/libavformat/matroskaenc.c b/libavformat/m

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

2017-11-27 18:50 GMT+01:00 Bjorn Roche : > Sorry for the very delayed response, Carl: > > On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos > wrote: > >> 2017-11-21 18:53 GMT+01:00 Bjorn Roche : >> > Support for transparencies in animated gifs requires modifying both >> > libavcodec/gif.c and liba

Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

On 11/27/2017 7:33 PM, James Darnley wrote: > On 2017-11-27 20:19, Martin Vignali wrote: >> +%macro VBROADCASTI128 2 ; dst xmm/ymm, src : 128bits val >> +%if mmsize == 32 >> +vbroadcasti128 %1, %2 >> +%else >> +mova %1, %2 >> +%endif >> +%endmacro > > If the condition was made "m

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

> > -Original Message- > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > > Of Mark Thompson > > Sent: November 27, 2017 3:11 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encodin

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

2017-11-27 19:30 GMT+01:00 Bjorn Roche : > > On Fri, Nov 3, 2017 at 8:11 PM, Carl Eugen Hoyos wrote: > >> 2017-10-24 18:40 GMT+02:00 Bjorn Roche : >> >> > - I don’t know if/how to update the FATE tests. >> >> A quick way (that needs some double-checking) is: >> $ make GEN=1 SAMPLES=fate-suite fate

Re: [FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

On 2017-11-27 20:19, Martin Vignali wrote: > +%macro VBROADCASTI128 2 ; dst xmm/ymm, src : 128bits val > +%if mmsize == 32 > +vbroadcasti128 %1, %2 > +%else > +mova %1, %2 > +%endif > +%endmacro If the condition was made "mmsize > 16" would this work correctly for zmm registers?

Re: [FFmpeg-devel] Codec of Audio G.722.1

> [cook @ 0x7fac22815200] Cook version 1297043023 is not implemented. Update > your FFmpeg version to the newest one from Git. Did you do this? > [cook @ 0x7fac22815200] If you want to help, upload a sample of this file to > ftp://upload.ffmpeg.org/incoming/ Did you do this? > can you please gi

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

> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Mark Thompson > Sent: November 27, 2017 3:11 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: [FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD > GP

Re: [FFmpeg-devel] [PATCH] hls demuxer: add option to defer parsing of variants

Hi, Rainer Hochecker kirjoitti 2017-11-26 12:46: fixed mem leak poined out by Steven --- doc/demuxers.texi | 5 + libavformat/hls.c | 304 -- 2 files changed, 209 insertions(+), 100 deletions(-) [...] + +@item load_all_variants +If 0,

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: use avformat_init_output to initialize output files

On 11/27/2017 6:25 PM, Michael Niedermayer wrote: > On Sun, Nov 26, 2017 at 05:51:02PM -0300, James Almer wrote: >> Postpone writing the header until the first output packet is ready to be >> written. >> This makes sure any stream parameter change that could take place while >> processing an input

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

>* On 11/27/2017 5:20 PM, James Almer wrote:*> Pointless duplicate atoms :/ At >least these don't use fixed point > values, so they are nicer. indeed > I assume no file will have both smdm and mdcv, or coll and clli, so > reusing the MOVStreamContext fields should be ok, but maybe free the > poi

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: use avformat_init_output to initialize output files

On Sun, Nov 26, 2017 at 05:51:02PM -0300, James Almer wrote: > Postpone writing the header until the first output packet is ready to be > written. > This makes sure any stream parameter change that could take place while > processing an input frame will be taken into account when writing the > outp

Re: [FFmpeg-devel] [PATCH 2/2] decklink: Add support for output of Active Format Description (AFD)

On Thu, 16 Nov 2017, Devin Heitmueller wrote: Implement support for including AFD in decklink output. This includes making sure the AFD data is preserved when going from an AVFrame to a V210 packet (needed for 10-bit support). Signed-off-by: Devin Heitmueller --- libavcodec/avcodec.h

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

On 11/27/2017 5:54 PM, Vittorio Giovara wrote: >> On 11/27/2017 5:20 PM, James Almer wrote: >> Where are these two defined? Because >> https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md >> describes coll and smdm, and those are already supported. > > these are

Re: [FFmpeg-devel] [PATCH 1/2] libavdevice/decklink: Add support for EIA-708 output over SDI

On Thu, 16 Nov 2017, Devin Heitmueller wrote: Hook in libklvanc and use it for output of EIA-708 captions over SDI. The bulk of this patch is just general support for ancillary data for the Decklink SDI module - the real work for construction of the EIA-708 CDP and VANC line construction is do

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

> On 11/27/2017 5:20 PM, James Almer wrote: > Where are these two defined? Because > https://github.com/webmproject/vp9-dash/blob/master/VPCodecISOMediaFileFormatBinding.md > describes coll and smdm, and those are already supported. these are unrelated to vp9 (or mp4), they are the mov-only atoms

Re: [FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

On 11/27/2017 5:20 PM, Vittorio Giovara wrote: > Signed-off-by: Vittorio Giovara > --- > libavformat/mov.c | 71 > +++ > 1 file changed, 71 insertions(+) > > diff --git a/libavformat/mov.c b/libavformat/mov.c > index 79023ef369..bb463017a3 100

[FFmpeg-devel] [PATCH] mov: Support mdcv and clli boxes for mastering display an color light level

Signed-off-by: Vittorio Giovara --- libavformat/mov.c | 71 +++ 1 file changed, 71 insertions(+) diff --git a/libavformat/mov.c b/libavformat/mov.c index 79023ef369..bb463017a3 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -5072,6 +

[FFmpeg-devel] [PATCH] Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK

From: mmironov Requires AMF headers for at least version 1.4.2 (older versions do not support building with C). --- Uses upstream headers from . I couldn't find an official install method so I've assumed that the A

[FFmpeg-devel] avutil/x86util : add macro for 128 bits constant load

Hello Following suggestion by Henrik Gramner in attach a patch to add a macro in x86_utils.asm in order to load a 128 bits constantes in an XMM register or in each part of a ZMM register Not sure about the name of this macro, and the position in the x86utils file Patch 002 : Use this new macro,

Re: [FFmpeg-devel] [PATCH] libvpxenc, vp9: add corpus-complexity option

On Mon, Nov 20, 2017 at 5:36 PM, James Zern wrote: > Corpus VBR mode is a variant of standard VBR where the complexity > distribution midpoint is passed in rather than calculated for a specific > clip or chunk. > > The valid range is [0, 1]. 0 (default) uses standard VBR. > > Signed-off-by: Ja

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs (requires feedback)

Thanks Moritz and Carl for your help with fate. This email was stuck in my drafts :( Comments below: On Fri, Nov 3, 2017 at 8:11 PM, Carl Eugen Hoyos wrote: > 2017-10-24 18:40 GMT+02:00 Bjorn Roche : > > > - I don’t know if/how to update the FATE tests. > > A quick way (that needs some double-c

[FFmpeg-devel] Codec of Audio G.722.1

Hello, I am working for codec of G.722.1 audio on the iOS, the version that I use is the latest version 3.4, but it always failed, the detail info is as following: [cook @ 0x7fac22815200] Cook version 1297043023 is not implemented. Update your FFmpeg version to the newest one from Git. If th

[FFmpeg-devel] avfilter/avf_ahistogram: return correct error code

In function query_formats(), it incorrectly returns 0 when the function ff_all_channel_counts() returns a NULL pointer (the check of variable ret before the NULL check guarantees that the return value is not negative). Signed-off-by: Pan Bian --- libavfilter/avf_ahistogram.c | 8 +--- 1 file

Re: [FFmpeg-devel] [PATCH] fix for transparencies in animated gifs

Sorry for the very delayed response, Carl: On Tue, Nov 21, 2017 at 6:55 PM, Carl Eugen Hoyos wrote: > 2017-11-21 18:53 GMT+01:00 Bjorn Roche : > > Support for transparencies in animated gifs requires modifying both > > libavcodec/gif.c and libavformat/gif.c because both the graphics > > control

Re: [FFmpeg-devel] AMD external header

Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail: Hi, I would like to summarize thoughts on several threads on this forum related to the issue of including AMD/AMF header file into FFmpeg source tree. It looks like they reflect some policies formal or informal. Mark tried to create some policy reg

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

On 11/27/2017 2:17 PM, Martin Vignali wrote: > 2017-11-27 17:59 GMT+01:00 Henrik Gramner : > >> On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali >> wrote: >>> Hello, >>> >>> In attach patch to convert pb_bswap32 to ymm constant >>> and remove the vbroadcasti128 part >>> >>> Speed seems to be simil

Re: [FFmpeg-devel] AMD external header

Personally, I would prefer if the bundled external headers were installed together with ffmpeg public headers (so nvenc/cuda/etc... weren't simply private headers within ffmpeg). There are some nvenc APIs I need to query hardware capabilities to avoid setting nvenc codec parameters that would cau

[FFmpeg-devel] [PATCH] avformat/matroskaenc: move some initialization checks to mkv_init

It's the correct place for them. Signed-off-by: James Almer --- libavformat/matroskaenc.c | 39 +-- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 06126781f8..35857bb02e 100644 --- a/

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

2017-11-27 17:59 GMT+01:00 Henrik Gramner : > On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali > wrote: > > Hello, > > > > In attach patch to convert pb_bswap32 to ymm constant > > and remove the vbroadcasti128 part > > > > Speed seems to be similar to me > > This just wastes cache for no reason.

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

>> Using 128-bit broadcasts is preferable over duplicating the constants >> to 256-bit unless there's a good reason for doing so since it wastes >> less cache and is faster on AMD CPU:s. > > What would that reason be? Afaik broadcasts are expensive, since they > both load from memory then splat dat

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

On 11/27/2017 1:50 PM, Henrik Gramner wrote: > On Sun, Nov 26, 2017 at 11:51 PM, James Darnley > wrote: >> -pd_0_int_min: times 2 dd 0, -2147483648 >> -pq_int_min: times 2 dq -2147483648 >> -pq_int_max: times 2 dq 2147483647 >> +pd_0_int_min: times 4 dd 0, -2147483648 >> +pq_int_min: t

Re: [FFmpeg-devel] avcodec/x86/bswapdsp : convert pb_bswap32 to ymm constant in order to simplify code

On Sat, Nov 25, 2017 at 9:53 PM, Martin Vignali wrote: > Hello, > > In attach patch to convert pb_bswap32 to ymm constant > and remove the vbroadcasti128 part > > Speed seems to be similar to me This just wastes cache for no reason. A tiny amount, sure, but minor things tends to add up eventually

Re: [FFmpeg-devel] [PATCH 7/8] lavc/flacenc: add AVX2 version of the 32-bit LPC encoder

On Sun, Nov 26, 2017 at 11:51 PM, James Darnley wrote: > -pd_0_int_min: times 2 dd 0, -2147483648 > -pq_int_min: times 2 dq -2147483648 > -pq_int_max: times 2 dq 2147483647 > +pd_0_int_min: times 4 dd 0, -2147483648 > +pq_int_min: times 4 dq -2147483648 > +pq_int_max: times 4 dq 21

Re: [FFmpeg-devel] AMD external header

On Mon, Nov 27, 2017 at 8:25 AM, Nicolas George wrote: > Mironov, Mikhail (2017-11-27): >> #1 >>policy: do not include external headers >>goal: minimize maintenance efforts and increase stability of the project >>action: remove NVidia headers > > Add to the goal: avoid being complicit

Re: [FFmpeg-devel] [FFmpeg-cvslog] lavd/alsa: Double maximum alsa buffer size.

Carl Eugen Hoyos (2017-11-27): > ffmpeg | branch: master | Carl Eugen Hoyos | Mon Nov 27 > 14:05:28 2017 +0100| [b7324950c0fc84a93d4e7abdfd2b75ea647ec3fc] | committer: > Carl Eugen Hoyos > > lavd/alsa: Double maximum alsa buffer size. > > Fixes recording from ATI Wonder 600 USB adapter, regres

Re: [FFmpeg-devel] AMD external header

Mironov, Mikhail (2017-11-27): > #1 >policy: do not include external headers >goal: minimize maintenance efforts and increase stability of the project >action: remove NVidia headers Add to the goal: avoid being complicit of free-riders on the Libre software bandwagon. Regards, --

Re: [FFmpeg-devel] AMD external header

> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Timo Rothenpieler > Sent: November 27, 2017 5:08 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] AMD external header > > Am 27.11.2017 um 03:15 schrieb Mironov, Mikhail: > > Hi,

Re: [FFmpeg-devel] AMD external header

> > > > I also noticed that recently there is a lot of activity to add full Nvidia > decoders to FFmpeg (VC1, MPEG4, VP8, VP9 etc.). > > I am guessing this is to overcome DXVA or VAAPI shortcoming. What about > AMD? We also have them. > > > > > > DXVA2/D3D11VA work perfectly fine, on Windows i se

Re: [FFmpeg-devel] [PATCH 2/3] avformat/mux: stop delaying writing the header

On 11/27/2017 6:00 AM, Tobias Rapp wrote: > On 26.11.2017 21:51, James Almer wrote: >> Every bitstream filter behaves as intended now, so there's no need to >> wait for the first packet of every stream. >> >> Signed-off-by: James Almer >> --- >>   libavformat/avformat.h |  2 +- >>   libavf

Re: [FFmpeg-devel] avcodec/samidec: check av_strdup() return value

On Mon, Nov 27, 2017 at 08:53:22 +0800, Pan Bian wrote: > + if (!dupsrc) > + return AVERROR(ENOMEM); > + Tabs are not allowed, please check your indentation. You can use tools/patcheck to find these kinds of issues. Moritz ___ ffmpeg-dev

[FFmpeg-devel] [PATCH] avcodec: set correct return value in ff_mpeg_ref_picture

In function ff_mpeg_ref_picture(), it returns 0 on the error path that the return value of av_buffer_ref() is NULL. 0 indicates success, which seems to deviate from the fact. Set ret to AVERROR(ENOMEM) to propagate the error status to the callers. Signed-off-by: Pan Bian --- libavcodec/mpegpictu

Re: [FFmpeg-devel] [PATCH]lavc/gifdec: Do not error out on resolution bigger than screen size

On Mon, Nov 27, 2017 at 03:05:27AM +0100, Carl Eugen Hoyos wrote: > Hi! > > Attached patch fixes ticket #6874 for me. > I don't think it makes much sense to discuss what the specification > means with "logical screen size" and "raster screen size" and > "physical display": Not only do other decode

  1   2   >