Re: [libav-devel] What is the status of this project?

Hello, It is dead, please consider contributing to FFmpeg. Kieran Sent from my mobile device On Thu, 16 Apr 2020, 03:58 Mark Filipak, < markfilipak.windows+li...@gmail.com> wrote: > Hello, > > I'm new. What is the status of this project? > > Regards, > Mark Filipak. >

[libav-devel] Fwd: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers participation

-- Forwarded message - From: Zohar Babin Date: Fri, 12 Oct 2018 at 12:50 Subject: [OpenMedia] FOSDEM 2019 Open Media room - Call for speakers participation To: FOSDEM , Open Media devroom < open-media-devr...@lists.fosdem.org> Hi all, Join us on February 2, 2019 in Brussels for

[libav-devel] PATCH] h2645: Allocate a single buffer per packet. Drastically reduces memory usage on pathological streams.

This patch fixes very high memory usage on pathological streams. 0001-h2645-Allocate-a-single-buffer-per-packet.-Drastical.patch Description: Binary data ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH] dirac: Make a full demuxer

On Mon, 27 Mar 2017 at 11:36 Luca Barbato <lu_z...@gentoo.org> wrote: > On 27/03/2017 12:28, Kieran Kunhya wrote: > > These offsets are optional so you need to search for BBCD > > Is there something to know that we are in a situation or the other > beside check if the tw

Re: [libav-devel] [PATCH] dirac: Make a full demuxer

On Sun, 26 Mar 2017 at 18:12 Luca Barbato wrote: > The dirac raw bitstream contains enough framing information to make a > full demuxer out of it. > +parse_code = avio_r8(s->pb); > +next_off = avio_rb32(s->pb); > +prev_off = avio_rb32(s->pb); > These offsets

Re: [libav-devel] [PATCH 1/4] h264_slice: Drop pointless assert

On Wed, 23 Nov 2016 at 07:15 Diego Biurrun wrote: > --- > libavcodec/h264_slice.c | 10 +- > 1 file changed, 1 insertion(+), 9 deletions(-) > > Why is this pointless? Kieran ___ libav-devel mailing list libav-devel@libav.org

[libav-devel] Fwd: [devroom-managers] Open Media devroom FOSDEM 2017 - Call For Participation

Hi all, Following a successful Open Media room at FOSDEM 2015 and 2016, we are organizing another Open Media room at FOSDEM 2017, and we are looking for propositions of talks and panels. FOSDEM is one of the largest (5,000+ hackers!) gatherings of Free Software contributors in the world and

Re: [libav-devel] [PATCH 00/38] Convert to the new bitstream reader, set 3

On Wed, 25 May 2016 at 19:37 Vittorio Giovara wrote: > On Wed, May 25, 2016 at 10:49 AM, Ronald S. Bultje > wrote: > > Hi, > > > > On Wed, May 25, 2016 at 9:54 AM, Luca Barbato > wrote: > > > >> On 25/05/16 15:32, Ronald S.

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Thu, 5 May 2016 at 04:30 Luca Barbato <lu_z...@gentoo.org> wrote: > On 05/05/16 07:54, Kieran Kunhya wrote: > > On Wed, 4 May 2016 at 18:10 Alexandra Hájková < > alexandra.khirn...@gmail.com> > > wrote: > > > >>>> That said, if you (Hen

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Wed, 4 May 2016 at 18:10 Alexandra Hájková wrote: > >> That said, if you (Hendrik, Vittorio, Kieran) _really_ cannot stand _32 > >> for the function returning unsigned, that could be dropped, for the 63 > >> bits one I'd rather keep _63 instead of having "_long"

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Wed, 4 May 2016 at 13:30 Luca Barbato wrote: > On 04/05/16 16:37, Hendrik Leppkes wrote: > > If the long function returns (u)int64 and can read up to 64-bits > > without any trouble, then its equally clear to me. The only problem > > get_bits had that it was only reliable

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Tue, 3 May 2016 at 12:26 Anton Khirnov <an...@khirnov.net> wrote: > Quoting Kieran Kunhya (2016-05-03 11:33:42) > > On Tue, 3 May 2016 at 07:43 Luca Barbato <lu_z...@gentoo.org> wrote: > > > > > On 03/05/16 15:34, Kieran Kunhya wrote: > > > >

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Tue, 3 May 2016 at 07:43 Luca Barbato <lu_z...@gentoo.org> wrote: > On 03/05/16 15:34, Kieran Kunhya wrote: > > I disagree, the old names are relatively clear. Whilst I think the speed > > improvements in this patch are great, the function names like > bitstrea

Re: [libav-devel] [RFC PATCH 04/12] add the new bitstream reader

On Wed, 27 Apr 2016 at 14:04 Anton Khirnov wrote: > Quoting Ronald S. Bultje (2016-04-27 14:37:20) > > Hi, > > > > On Wed, Apr 27, 2016 at 7:37 AM, Alexandra Hájková < > > alexandra.khirn...@gmail.com> wrote: > > > > > --- > > > libavcodec/bitstream.h | 475 > > >

Re: [libav-devel] [RFC] [PATCH] Cineform HD Decoder

On Sat, 16 Apr 2016, 05:57 Diego Biurrun, <di...@biurrun.de> wrote: > From: Kieran Kunhya <kie...@kunhya.com> > > Decodes YUV 4:2:2 10-bit and RGB 12-bit files. > Older files with more subbands, skips, Bayer, alpha not supported. > Alpha requires addit

[libav-devel] libavfilter API design in a realtime environment

Hello, I want to try and use the libavfilter API to overlay bitmap subtitles on video from a realtime source. This seems difficult/impossible to do with the current API hence asking on the main devel list. Some questions: 1: How do I know the end to end latency of the pipeline? Is it fixed,

[libav-devel] [PATCH] avcodec/cfhd: Fixes cfhd_odd.mov which has a resolution of 496x241

In this case container width/height is better however. Thanks to koda for the sample --- libavcodec/cfhd.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index e37bef0..98f16d3 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -467,6 +467,9 @@

[libav-devel] [PATCH] avcodec/cfhd: Add support for 12-bit RGBA.

Plays all known samples --- libavcodec/cfhd.c | 20 1 file changed, 12 insertions(+), 8 deletions(-) diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c index 2436aae..0773ffa 100644 --- a/libavcodec/cfhd.c +++ b/libavcodec/cfhd.c @@ -152,14 +152,15 @@ static void

[libav-devel] [PATCH v2] Add GBRAP12 pixel format

--- libavcodec/utils.c| 2 ++ libavutil/pixdesc.c | 28 libavutil/pixfmt.h| 4 libavutil/version.h | 2 +- libswscale/input.c| 4 libswscale/swscale_unscaled.c | 3 +++ libswscale/utils.c

[libav-devel] [PATCH v2] Add GBRAP12 pixel format

Output still looks a bit odd though --- libavutil/pixdesc.c | 28 libavutil/pixfmt.h| 4 libswscale/input.c| 4 libswscale/swscale_unscaled.c | 3 +++ libswscale/utils.c| 6 ++ 5 files changed, 45

[libav-devel] [PATCH] Add GBRAP12 pixel format.

In preparation for Cineform Alpha channel support --- libavutil/pixdesc.c | 28 libavutil/pixfmt.h| 3 +++ libswscale/input.c| 4 libswscale/swscale_unscaled.c | 3 +++ libswscale/utils.c| 6 ++ 5 files

[libav-devel] [PATCH v4] avcodec: Cineform HD Decoder

@ -0,0 +1,746 @@ +/* + * Copyright (c) 2015-2016 Kieran Kunhya <kie...@kunhya.com> + * + * 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; eit

Re: [libav-devel] [PATCH] h264: Print user data only from well known sources

On Thu, 28 Jan 2016 at 17:33 Luca Barbato wrote: > On 20/01/16 20:49, Vittorio Giovara wrote: > > Right now only x264 info is printed at verbose level, anything else > > is printed at trace level. > > --- > > libavcodec/h264_sei.c | 13 +++-- > > 1 file changed, 11

Re: [libav-devel] [PATCH 3/3] v210: Use separate sample_factors

On Thu, Jan 28, 2016 at 12:02 AM, Luca Barbato wrote: > And while at it simplify a little the code. > --- > libavcodec/v210enc.c | 17 - > libavcodec/v210enc.h | 3 ++- > libavcodec/x86/v210enc_init.c | 7 --- > 3 files changed, 18

Re: [libav-devel] [PATCHv3] avcodec: Cineform HD Decoder

On Mon, Jan 25, 2016 at 4:51 PM, Vittorio Giovara <vittorio.giov...@gmail.com> wrote: > On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya <kie...@kunhya.com> wrote: >> Decodes YUV 4:2:2 10-bit and RGB 12-bit files. >> Older files with more subbands, skips, Bayer, al

Re: [libav-devel] [FFmpeg-devel] [PATCHv3] avcodec: Cineform HD Decoder

On Mon, Jan 25, 2016 at 2:42 PM, Ronald S. Bultje <rsbul...@gmail.com> wrote: > Hi, > > On Sun, Jan 24, 2016 at 7:34 PM, Kieran Kunhya <kie...@kunhya.com> wrote: > >> +static inline void filter(int16_t *output, ptrdiff_t out_stride, int16_t

[libav-devel] [PATCHv3] avcodec: Cineform HD Decoder

@ -0,0 +1,744 @@ +/* + * Copyright (c) 2015-2016 Kieran Kunhya <kie...@kunhya.com> + * + * 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; eit

Re: [libav-devel] [PATCH 1/2] h264: Print user data SEI under normal debug verbosity

On Wed, 28 Oct 2015 at 13:29 Vittorio Giovara wrote: > On Mon, Oct 26, 2015 at 2:33 PM, Luca Barbato wrote: > > On 22/10/15 14:13, Vittorio Giovara wrote: > >> Drop the need of setting -debug bugs since it's not a bug, and the > >> message is

Re: [libav-devel] [PATCH] yuv2rgb: Document the color space coefficients

On Tue, 19 Jan 2016 at 22:11 Vittorio Giovara wrote: > Based on the original documentation found in mpeg2dec (1995). > > Signed-off-by: Vittorio Giovara > --- > Based off an archeological expedition with Derek. > Vittorio > >

[libav-devel] [PATCH] avcodec/v210: add avx2 version of the line encoder

-- Forwarded message - From: James Darnley Date: Wed, 13 Jan 2016 at 15:55 Subject: [FFmpeg-devel] [PATCH] avcodec/v210: add avx2 version of the line encoder To: FFmpeg development discussions and patches Around 35% faster than

[libav-devel] Fwd: [FFmpeg-devel] [PATCH] avcodec: add a native BBC Dirac VC-2 HQ encoder

-- Forwarded message - From: Rostislav Pehlivanov Date: Thu, 14 Jan 2016 at 19:00 Subject: [FFmpeg-devel] [PATCH] avcodec: add a native BBC Dirac VC-2 HQ encoder To: Cc: Rostislav Pehlivanov This commit adds a

Re: [libav-devel] [PATCH] Cineform HD Decoder:

> Unchecked mallocs cause global warming, please think of the planet. > >> +l_h[i][0] = tmp[i]; >> +l_h[i][1] = tmp[i] + 2 * w8 * h8; >> +//l_h[i][2] = ll2; >> +l_h[i][3] = tmp[i]; >> +l_h[i][4] = tmp[i] + 2 * w4 * h4; >> +//l_h[i][5] = ll1; >> +

[libav-devel] [PATCH 2/2] avformat: Add Cineform HD demuxing

--- libavformat/riff.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/riff.c b/libavformat/riff.c index f297dd4..faf0f86 100644 --- a/libavformat/riff.c +++ b/libavformat/riff.c @@ -377,6 +377,7 @@ const AVCodecTag ff_codec_bmp_tags[] = { { AV_CODEC_ID_SCREENPRESSO,

[libav-devel] [PATCH 1/2] avcodec: Add Cineform HD Decoder

odec/cfhd.c b/libavcodec/cfhd.c new file mode 100644 index 000..dc36889 --- /dev/null +++ b/libavcodec/cfhd.c @@ -0,0 +1,565 @@ +/* + * Copyright (c) 2015 Kieran Kunhya + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the ter

[libav-devel] [PATCH] Cineform HD Decoder:

odecs" */ AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c new file mode 100644 index 000..0f1bcd3 --- /dev/null +++ b/libavcodec/cfhd.c @@ -0,0 +1,567 @@ +/* + * Copyright (c) 2015

Re: [libav-devel] [RFC] Cineform HD questions

On 31 December 2015 at 06:17, Kostya Shishkov <kostya.shish...@gmail.com> wrote: > On Thu, Dec 31, 2015 at 04:13:50AM +0000, Kieran Kunhya wrote: >> >> This patch is the first attempt at getting a working Cineform HD decoder >> into avcodec >> It supports YUV42

Re: [libav-devel] [RFC] Cineform HD questions

On 31 December 2015 at 04:28, Ganesh Ajjanagadde <gajja...@mit.edu> wrote: > On Wed, Dec 30, 2015 at 8:13 PM, Kieran Kunhya <kier...@obe.tv> wrote: >> >> This patch is the first attempt at getting a working Cineform HD decoder >> into avcodec >> It supports

[libav-devel] [RFC] Cineform HD questions

This patch is the first attempt at getting a working Cineform HD decoder into avcodec It supports YUV422P10 files which are the majority of files in the wild There are some files not supported such as those from film scanners and some older files which do something unusual with chroma and the

[libav-devel] [RFC][PATCH] avcodec: First hacky attempt at supporting CFHD

odec/cfhd.c b/libavcodec/cfhd.c new file mode 100644 index 000..6b15f70 --- /dev/null +++ b/libavcodec/cfhd.c @@ -0,0 +1,707 @@ +/* + * Copyright (c) 2015 Kieran Kunhya + * + * This file is part of FFmpeg. + * + * FFmpeg is free software; you can redistribute it and/or + * modify it under the ter

Re: [libav-devel] [PATCH] [RFC] get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL

On 15 December 2015 at 07:48, Diego Biurrun <di...@biurrun.de> wrote: > On Sun, Dec 13, 2015 at 09:26:17PM +0000, Kieran Kunhya wrote: >> On 13 December 2015 at 19:21, Luca Barbato <lu_z...@gentoo.org> wrote: >> > >> > Where do you need it? >> &g

[libav-devel] [PATCH] [RFC] get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL

--- libavcodec/get_bits.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h index 0d3db1f..0a61c80 100644 --- a/libavcodec/get_bits.h +++ b/libavcodec/get_bits.h @@ -539,6 +539,17 @@ void ff_free_vlc(VLC *vlc); index =

Re: [libav-devel] [PATCH] [RFC] get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL

On 13 December 2015 at 19:21, Luca Barbato <lu_z...@gentoo.org> wrote: > On 13/12/15 19:02, Kieran Kunhya wrote: >> --- >> libavcodec/get_bits.h | 11 +++ >> 1 file changed, 11 insertions(+) >> >> diff --git a/libavcodec/get_bits.h b/libavcodec/get_

[libav-devel] [PATCH] diracdec: Move strides to bytes, and pointer types to uint8_t.

Start templating functions for move to support 10-bit Parts of this patch were written by Rostislav Pehlivanov --- libavcodec/dirac.c | 10 +- libavcodec/dirac.h | 3 +- libavcodec/diracdec.c | 227 ++--

Re: [libav-devel] [PATCH 001/264] avpacket: add a function for wrapping existing data as side data

> pkt->side_data = av_realloc(pkt->side_data, > (elems + 1) * sizeof(*pkt->side_data)); Would a linked list be better? (I'm not sure) Kieran ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 016/264] mxfenc: always assume long gop

On 8 November 2015 at 20:31, Derek Buitenhuis wrote: > On 11/8/2015 7:57 PM, Anton Khirnov wrote: >> Checking the codec context parameters to find out this information is >> far too unreliable to be useful, so it is safer to assume B-frames are >> always present. >>

Re: [libav-devel] [PATCH] lavu: add AESNI CPU flag

On 6 November 2015 at 23:40, Vittorio Giovara wrote: > From: Rodger Combs > > Signed-off-by: Vittorio Giovara What's the point of adding the flag if you're not going to use it for anything.

Re: [libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

> I can only repeat the point I made before - ASM is not about safety, > its about speed. > If you can re-write it to not be a single cycle slower and not have > this particular behavior, great. > > In the meantime, can we apply this patch and get the crash done with? > > FWIW, all other callers

Re: [libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

On 26 October 2015 at 22:48, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Mon, Oct 26, 2015 at 11:29 PM, Kieran Kunhya <kier...@obe.tv> wrote: >> From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001 >> From: Kieran Kunhya <kier...@obe.tv> &

[libav-devel] [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays

>From a1314d5c9774d555718bbc0a8612144c890bbc59 Mon Sep 17 00:00:00 2001 From: Kieran Kunhya <kier...@obe.tv> Date: Mon, 26 Oct 2015 22:26:35 + Subject: [PATCH] opusdec: Don't run vector_fmul_scalar on zero length arrays Fixes crashes on fuzzed files --- libavcodec/opusdec.c |

Re: [libav-devel] [PATCH] h264: Change default field order for interlaced frames with missing sei

>> It is an heuristic but better that than breaking existing files for no >> reason IMHO. > > breaking how? also no heuristic please Yes, don't use a heuristic. Also it should be reasonably rare to have interlaced files without poc - x264 used to do it many years ago. Kieran

Re: [libav-devel] [PATCH] checkasm: v210: Fix array overwrite

On 16 September 2015 at 14:03, Henrik Gramner wrote: > --- > tests/checkasm/v210enc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/checkasm/v210enc.c b/tests/checkasm/v210enc.c > index cdb8e76..4f5f6ba 100644 > --- a/tests/checkasm/v210enc.c

Re: [libav-devel] [PATCH] parseutil: Add more resolution aliases

+{ uhd, 3840,2160 }, should be uhd1 and uhd2 imho. If you want map uhd to uhd1. Kieran ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCHv4] avcodec: Add support for Closed Caption export in h264

--- libavcodec/h264.c | 9 + libavcodec/h264.h | 2 ++ libavcodec/h264_sei.c | 39 +-- 3 files changed, 48 insertions(+), 2 deletions(-) diff --git a/libavcodec/h264.c b/libavcodec/h264.c index baedcf4..f62ad6a 100644 --- a/libavcodec/h264.c

Re: [libav-devel] [PATCH] on2avc: Use the integer abs() version

On 12 June 2015 at 12:33, Vittorio Giovara vittorio.giov...@gmail.com wrote: Fixes clang warning floating point absolute value function 'fabsf' when argument is of integer type [-Wabsolute-value]. LGTM ___ libav-devel mailing list

Re: [libav-devel] [PATCH] pixfmt: remove misleading and broken documentation

AV_PIX_FMT_NV20LE is wrong. It has the value 113, but as little-endian format it should be even. This must have been quite obvious when these formats were added (because of the AV_PIX_FMT_XYZ12BE entry), but nobody cared or knew about this. I introduced these pixfmts and iirc I patched

Re: [libav-devel] Internal Snappy

On 24 May 2015 at 15:20, Luca Barbato lu_z...@gentoo.org wrote: Should work on top of the hap set. I'll try to get a not-completely-horrible encoder later. What does this snappy decoder actually do? It's not really clear. Kieran ___ libav-devel

Re: [libav-devel] Internal Snappy

Hap uses snappy, so Vittorio added the dependency on it, then Tom asked if snappy support could be automagic. Can you provide a link to some info about snappy in the file. Kieran ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 1/3] log: Introduce a more verbose debug level

On 28 March 2015 at 20:51, Anton Khirnov an...@khirnov.net wrote: This seemed to be the general consensus on IRC. Up for discussion. For someone who didn't follow any IRC discussion, what does this patch(set) do? Kieran ___ libav-devel mailing list

Re: [libav-devel] [PATCH 4/5] lavc: add an Intel libmfx-based H.264 decoder

On 13 February 2015 at 03:43, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Thu, Feb 12, 2015 at 4:54 AM, Anton Khirnov an...@khirnov.net wrote: Based on the code by Luca Barbato lu_z...@gentoo.org and Yukinori Yamazoe droco...@gmail.com. Isn't mfx nonfree?

Re: [libav-devel] [PATCH 4/5] lavc: add an Intel libmfx-based H.264 decoder

On 13 February 2015 at 13:40, Luca Barbato lu_z...@gentoo.org wrote: On 13/02/15 14:16, Kieran Kunhya wrote: On 13 February 2015 at 03:43, Vittorio Giovara vittorio.giov...@gmail.com wrote: On Thu, Feb 12, 2015 at 4:54 AM, Anton Khirnov an...@khirnov.net wrote: Based on the code by Luca

Re: [libav-devel] [PATCH] opus: Factor out imdct15 into a standalone component

-av_cold void ff_celt_imdct_uninit(CeltIMDCTContext **ps) +av_cold void ff_imdct15_uninit(Imdct15Context **ps) { -CeltIMDCTContext *s = *ps; +Imdct15Context *s = *ps; IMDCT, no? Kieran ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 3/3] Generate proper PTS for the muxer and set the container time base to get rid of the newly introduced warning when only the container's codec time base is set

+/** Set an artificial timestamp for the container later */ The timestamp isn't artificial. Kieran ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] Regarding Reserved AAC SBR Extensions

Just wanted to check with you all if there is a mistake that i'm doing at my end or this feature is still under development. I would check if the same thing happens with avconv first. Kieran ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] How to get frame time stamp / PTS to synchronize between two h264 RTP streams?

On 16 January 2015 at 19:03, Bernd Pfrommer bernd.pfrom...@gmail.com wrote: I'm trying to build a stereo camera streamer that uses two individual cameras, each producing a h264 rtp stream using libav. A client application then receives the two streams, and synchronously displays the two

[libav-devel] Frame threaded encoders

Hi, Does the CODEC_CAP_FRAME_THREADS API support frame threaded encoding? Regards, Kieran Kunhya ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCHv3] v210enc: Directly encode YUV422P to v210. About 6 times faster than existing (broken) swscale based path

--- libavcodec/v210enc.c | 151 +++--- libavcodec/v210enc.h | 4 +- libavcodec/x86/v210enc.asm| 102 +++- libavcodec/x86/v210enc_init.c | 13 +++- libavutil/x86/x86util.asm | 5 ++ 5 files changed, 217

[libav-devel] [PATCH] vf_interlace: get rid of useless loads

--- libavfilter/x86/vf_interlace.asm |2 -- 1 file changed, 2 deletions(-) diff --git a/libavfilter/x86/vf_interlace.asm b/libavfilter/x86/vf_interlace.asm index b8d8616..85811da 100644 --- a/libavfilter/x86/vf_interlace.asm +++ b/libavfilter/x86/vf_interlace.asm @@ -42,8 +42,6 @@ cglobal

Re: [libav-devel] [PATCH] v210enc: Directly encode YUV422P to v210. About 6 times faster than existing (broken) swscale based path

A small mistake in this part but the other part is fine. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] v210enc: Add x86 SIMD

On 23 November 2014 at 11:23, Luca Barbato lu_z...@gentoo.org wrote: On 22/11/14 21:58, Kieran Kunhya wrote: --- libavcodec/v210enc.c | 78 ++- libavcodec/v210enc.h | 31 + libavcodec/x86/Makefile | 2

[libav-devel] [PATCHv2] v210enc: Directly encode YUV422P to v210. About 6 times faster than existing (broken) swscale based path

--- libavcodec/v210enc.c | 151 +++--- libavcodec/v210enc.h | 4 +- libavcodec/x86/v210enc.asm| 102 +++- libavcodec/x86/v210enc_init.c | 13 +++- libavutil/x86/x86util.asm | 5 ++ 5 files changed, 217

[libav-devel] [PATCH] v210enc: Directly encode YUV422P to v210. About 6 times faster than existing (broken) swscale based path

--- libavcodec/v210enc.c | 151 +++--- libavcodec/v210enc.h | 4 +- libavcodec/x86/v210enc.asm| 104 - libavcodec/x86/v210enc_init.c | 13 +++- libavutil/x86/x86util.asm | 5 ++ 5 files changed, 218

[libav-devel] [PATCH] v210enc: Add x86 SIMD

--- libavcodec/v210enc.c| 78 ++--- libavcodec/v210enc.h| 31 libavcodec/x86/Makefile | 2 ++ 3 files changed, 88 insertions(+), 23 deletions(-) create mode 100644 libavcodec/v210enc.h diff --git a/libavcodec/v210enc.c

[libav-devel] [PATCH] v210enc: Add x86 SIMD

@@ +;** +;* V210 SIMD pack +;* Copyright (c) 2014 Kieran Kunhya kier...@obe.tv +;* +;* This file is part of Libav. +;* +;* Libav 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

Re: [libav-devel] ff_combine_frame usage fixes

I added ff_combine_packet since it reduces the number of lines and makes the code slightly less verbose. This is very confusing since ff_combine_packet suggests an AVPacket is involved. Kieran ___ libav-devel mailing list libav-devel@libav.org

[libav-devel] [PATCHv2] vf_interlace: Add SIMD for lowpass filter

@@ +;* +;* x86-optimized functions for interlace filter +;* +;* Copyright (C) 2014 Kieran Kunhya kier...@obe.tv +;* +;* This file is part of Libav. +;* +;* Libav is free software; you can redistribute it and/or modify +;* it under the terms of the GNU General Public License as published

[libav-devel] [PATCH] vf_interlace: Add SIMD for lowpass filter

..455bcd1 --- /dev/null +++ b/libavfilter/x86/vf_interlace_init.c @@ -0,0 +1,42 @@ +/* + * Copyright (C) 2014 Kieran Kunhya kier...@obe.tv + * + * This file is part of Libav. + * + * Libav is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License

[libav-devel] [PATCH] Add support for Opus in MPEG-TS

--- libavcodec/opus.c| 11 +--- libavcodec/opus.h|9 +++ libavcodec/opus_parser.c | 139 +- libavformat/mpegts.c | 54 +- 4 files changed, 191 insertions(+), 22 deletions(-) diff --git a/libavcodec/opus.c

Re: [libav-devel] MPEG-DASH libav?

Do you know what the toughts in the Gpac team are; do they want to continue doing their own thing? From an non-commercial end user perspective, I guess MPEG-DASH will not fly until we see content creation support for it in libav/FFmpeg/GStreamer, but that's just my 5 (€) cents on the matter.

Re: [libav-devel] [PATCH] Fix a bunch of broken links

WTH? I could swear those links did not work earlier today ... Is it possible for me to use part of this patch for the FFmpeg website? *sigh* - once more this feels like FFmpeg takes, takes, takes, and gives nothing in return (let's not even delve into the whole negativity thing).

Re: [libav-devel] [PATCH] [0.8] ffmpeg: Clarify wording of ffmpeg -- avconv deprecation message

On 1 September 2014 18:50, Diego Biurrun di...@biurrun.de wrote: + avconv (see Changelog for details). The old ffmpeg program has been deprecated\n On 25 August 2014 00:58, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 8/24/2014 10:37 PM, Kieran Kunhya wrote: deprecated

Re: [libav-devel] [PATCH] [0.8] ffmpeg: Clarifiy wording of ffmpeg -- avconv deprecation message

On 25 August 2014 00:58, Derek Buitenhuis derek.buitenh...@gmail.com wrote: On 8/24/2014 10:37 PM, Kieran Kunhya wrote: deprecated in the Libav project +1 to not pretending I will just repeat this... ___ libav-devel mailing list libav-devel

Re: [libav-devel] Common mailing-list for API evolutions

The remark you mention there was not a review, but rather a complaint that the submitted patch was not easy enough to diff against the FFmpeg version. Cleanup by other contributors from libav was squashed in order to have a clean version in the history and for review on the ml. I and others

Re: [libav-devel] Common mailing-list for API evolutions

You're throwing a blob at me without individual author's contribution, I don't think that's appropriate. You've decided to selectively ignore the second part of the message. As I read that it says he is not happy with those changes being attributed to him. Speaking of incorrect attribution, you

Re: [libav-devel] [PATCH] mpegts: Allow custom max resync size

On 25 August 2014 11:33, Luca Barbato lu_z...@gentoo.org wrote: +#define MPEGTS_OPTIONS \ +{ resync_size, Size limit for looking up a new sincronization., offsetof(MpegTSContext, resync_size), AV_OPT_TYPE_INT, { .i64 = MAX_RESYNC_SIZE}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM }

Re: [libav-devel] [PATCH] [0.8] ffmpeg: Clarifiy wording of ffmpeg -- avconv deprecation message

+ This ffmpeg program has been deprecated in favor of the avconv program due to\n deprecated in the Libav project ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] lavc: use a separate field for exporting audio encoder padding

On 23 August 2014 14:13, Anton Khirnov an...@khirnov.net wrote: Currently, the amount of padding inserted at the beginning by some audio encoders, is exported through AVCodecContext.delay. However - the term 'delay' is heavily overloaded and can have multiple different meanings even in the

Re: [libav-devel] [PATCH] pulse: Add a wallclock option to be compatible with other other captures

+if (pd-wallclock) +pd-pts += av_gettime(); Any reason for av_gettime instead of the monotonic clock? Kieran ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] avcodec: Instruct users to align buffers to 32-byte.

On 10 August 2014 11:25, Janne Grunau janne-li...@jannau.net wrote: On 2014-08-10 04:17:09 +0100, Kieran Kunhya wrote: The Opus decoder in particular uses optimised float_dsp functions that expect 32-byte alignment --- libavcodec/avcodec.h |2 +- 1 file changed, 1 insertion(+), 1

[libav-devel] [PATCH] avcodec: Instruct users to align buffers to 32-byte.

The Opus decoder in particular uses optimised float_dsp functions that expect 32-byte alignment --- libavcodec/avcodec.h |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h index 93aad35..5cbc175 100644 --- a/libavcodec/avcodec.h +++

Re: [libav-devel] [PATCH 4/5] msmpeg$: Drop inline assembly from ff_msmpeg4_pred_dc

This is a silly microoptimization and thus not worth benchmarking IMO... Scratch that, what was I smoking ... Why are you not benchmarking using the timer functions like we would normally? ___ libav-devel mailing list libav-devel@libav.org

Re: [libav-devel] [PATCH 4/5] msmpeg$: Drop inline assembly from ff_msmpeg4_pred_dc

Perf doesn't require hack the code and is incredibly simple to use. It doesn't give you a per function measurement as far as I know. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] avcodec: Undeprecate reordered_opaque

IIRC you need it if you want to attach any private data that should follow along with the frame through the decoder frame reordering and all that - normally this only is done for the pkt_pts field (and this is what most people need), but in case you need to track more data than just the pts,

[libav-devel] [PATCHv3] Deprecate AFD field and add AFD as side-data

--- doc/APIchanges|4 libavcodec/avcodec.h |5 - libavcodec/mpeg12dec.c| 20 +++- libavcodec/version.h |5 - libavfilter/vf_showinfo.c |3 +++ libavutil/frame.h | 16 libavutil/version.h |

Re: [libav-devel] [PATCH] Deprecate AFD field and add AFD as side-data

+sd-data= s1-afd; probably the crash is here. ___ libav-devel mailing list libav-devel@libav.org https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] avformat/mpegtsenc: Check data array size in mpegts_write_pmt()

Indeed, now the question pending is how we can overflow it and how to notify the user when it happens. Not looked at it deeply but it appears to be possible if the user specifies too many languages. ___ libav-devel mailing list libav-devel@libav.org

[libav-devel] [PATCH] Add support for Opus in MPEG-TS

--- libavcodec/opus.c| 11 +--- libavcodec/opus.h|9 +++ libavcodec/opus_parser.c | 138 +- libavcodec/opusdec.c |1 + libavformat/mpegts.c | 54 ++ 5 files changed, 192 insertions(+), 21 deletions(-)

[libav-devel] [PATCH] Deprecate AFD field and add AFD as side-data

--- doc/APIchanges|4 libavcodec/avcodec.h |5 - libavcodec/mpeg12dec.c| 21 - libavcodec/version.h |5 - libavfilter/vf_showinfo.c |3 +++ libavutil/frame.h | 12 libavutil/version.h |2

[libav-devel] [PATCH] Add support for Opus in MPEG-TS

--- libavcodec/opus.c| 41 +++ libavcodec/opus.h| 11 + libavcodec/opus_parser.c | 101 -- libavcodec/opusdec.c |4 +- libavformat/mpegts.c | 52 +++- 5 files changed, 186

[libav-devel] [PATCHv2] Add support for Opus in MPEG-TS

--- libavcodec/opus.c| 11 +--- libavcodec/opus.h|9 +++ libavcodec/opus_parser.c | 139 +- libavcodec/opusdec.c |1 + libavformat/mpegts.c | 54 +- 5 files changed, 192 insertions(+), 22 deletions(-)

[libav-devel] Fwd: [WIP] Opus in TS support

This patch aims to show some of the changes that will be needed to support the new Opus in TS spec. It is similar to AAC in LATM. Design comments welcome. --- libavcodec/allcodecs.c |2 ++ libavcodec/avcodec.h |1 + libavcodec/codec_desc.c |7 libavcodec/opus_parser.c |

  1   2   3   >