[FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

From: Matthieu Bouron --- Hi, This commit is likely to break fate on arm since the current C code path seems to use less precision. How should I proceed to fix it ? Matthieu --- libswscale/arm/swscale_unscaled.c | 53 ---

[FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call

From: Matthieu Bouron --- libswscale/arm/yuv2rgb_neon.S | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S index 01d8536..9f9dd2a 100644 --- a/libswscale/arm/yuv2rgb_neon.S +++

Re: [FFmpeg-devel] [PATCH 2/2] swscale/arm/yuv2rgb: add ff_yuv420p_to_{argb, rgba, abgr, bgra}_neon_{16, 32}

On Tue, Dec 15, 2015 at 05:46:09PM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > > Hi, > > This commit is likely to break fate on arm since the current C code path > seems to use less precision. > > How should I proceed to fix it ? hmm can the

Re: [FFmpeg-devel] Patch question

On 12/15/2015 05:49 PM, Moritz Barsnick wrote: Hi Mats, On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote: Sorry if this may sound idiotic, but if I provide a unified patch for a file that is newer/different from the one I have here, it won't work, right? "It depends." ;-) By the

[FFmpeg-devel] [PATCH] fix http chunk encoding parsing

--- ffserver.c | 77 -- 1 file changed, 50 insertions(+), 27 deletions(-) diff --git a/ffserver.c b/ffserver.c index 029771c..b7f9616 100644 --- a/ffserver.c +++ b/ffserver.c @@ -138,7 +138,7 @@ typedef struct HTTPContext { int

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On 12/15/2015 10:44 AM, Jean Delvare wrote: > Originally I proposed this patch for performance reasons and also > because I think it makes the code more readable. But seeing how the > same cast is already present everywhere in the ffmpeg code, I would now > also invoke consistency. There's no

Re: [FFmpeg-devel] Patch question

Hi Mats, On Tue, Dec 15, 2015 at 16:58:41 +0100, Mats Peterson wrote: > Sorry if this may sound idiotic, but if I provide a unified patch for a > file that is newer/different from the one I have here, it won't work, right? "It depends." ;-) By the way, git handles this kind of stuff nicely.

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On 12/15/2015 5:23 PM, Jean Delvare wrote: > Looks like something different from what we were discussing here. In which way? That patch fixes pointer aliasing in the same way yours breaks it, AFAICT? - Derek ___ ffmpeg-devel mailing list

[FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska

Here is a *suggestion* for how to end the QuickTime palette in Matroska saga. I have created a new file 'qtpalette.c' with a function get_qtpalette(), that will be called from both matroskadec.c and mov.c. So, no more calling into another demuxer to get the palette, and no duplicated code,

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On Tue, 15 Dec 2015 16:56:02 +, Derek Buitenhuis wrote: > On 12/15/2015 10:44 AM, Jean Delvare wrote: > > Originally I proposed this patch for performance reasons and also > > because I think it makes the code more readable. But seeing how the > > same cast is already present everywhere in the

Re: [FFmpeg-devel] [PATCH] Several, actually, regarding the QuickTime palette issue in Matroska

On 12/15/2015 06:51 PM, Mats Peterson wrote: Here is a *suggestion* for how to end the QuickTime palette in Matroska saga. I have created a new file 'qtpalette.c' with a function get_qtpalette(), that will be called from both matroskadec.c and mov.c. So, no more calling into another demuxer to

[FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

I found that the ffmpeg H.265 decoder can't run on the iOS platform when I enable the neon assembly code, it crashed when playing the H.265 clip. When disable the neon assembly code it works fine. What's the problem with the H.265 neon assembly code? Best regards, Zhuhb

Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph

On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote: > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron > wrote: > > > From: Matthieu Bouron > > > > --- > > libavfilter/avfilter.c | 1 + > > libavfilter/avfilter.h | 5

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

> > using a random IV value would break any regression tests > see AVFMT_FLAG_BITEXACT > Fixed, only generating a random IV when bitexact is not enabled. Updated patch files attached. > > is this filling in a random IV that later is overridden ? > random_seed() can be slow so it would be

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

> are these encrypted mp4 files some kind of standard encryption? > Yes, these files conform to the common encryption specification ISO/IEC 23001-7 > rephrased... will encrypted files created by ffmpeg be able to be > decrypted/decoded and played by quicktime? or any other player? > (assuming

Re: [FFmpeg-devel] [PATCH] lavc/utils: use AVPixFmtDescriptor to probe palette formats

On Mon, Dec 14, 2015 at 6:18 PM, Michael Niedermayer wrote: > On Mon, Dec 14, 2015 at 05:49:48PM +0100, Matthieu Bouron wrote: > > From: Matthieu Bouron > > > > Also use the input frame format instead of the AVCodecContext one > according > > to

Re: [FFmpeg-devel] [PATCH 2/2] lavf: use a video frame pool for each link of the filtergraph

On Tue, Dec 15, 2015 at 10:00 AM, Michael Niedermayer wrote: > On Mon, Dec 14, 2015 at 02:26:38PM +0100, Matthieu Bouron wrote: > > On Fri, Dec 11, 2015 at 1:32 PM, Matthieu Bouron < > matthieu.bou...@gmail.com> > > wrote: > > > > > From: Matthieu Bouron

Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote: > I found that the ffmpeg H.265 decoder can't run on the iOS platform > when I enable the neon assembly code, it crashed when playing the > H.265 clip. When disable the neon assembly code it works fine. What's > the problem with the H.265

Re: [FFmpeg-devel] Bug #3823 (yuvj422p jpeg rtp enc) request for help

On Fri, Dec 11, 2015 at 3:02 PM, Andrey Utkin wrote: > On Wed, Dec 9, 2015 at 2:07 AM, Andrey Utkin > wrote: >> Hi! Could please anybody look at MJPEG RTP encoder issue with yuvj422p >>

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote: > Hallo Michael, > > On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote: > > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote: > > > As I understand it, the temporary stack buffer "src_data" was > > > introduced

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On Tue, 15 Dec 2015 11:20:40 +0100, Michael Niedermayer wrote: > yes, I have no real oppinion on this except that C is insane or I am C is insane, who would dare to argue otherwise? ;-) More than the language itself, the fact that the compilers think they can reorder instructions the way they

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

> > > > +struct AVAESCTR; > > Is this needed? > Indeed compiles for me without it, I matched the existing code in aes.h, and in general I prefer to define the structs in advance. If you prefer that I will remove it, please let me know > > +subsample_count =

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer wrote: > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote: >> Hallo Michael, >> >> On Mon, 14 Dec 2015 23:18:39 +0100, Michael Niedermayer wrote: >> > On Mon, Dec 14, 2015 at 07:36:51PM +0100, Jean Delvare wrote:

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

Hi Hendrik, On Tue, 15 Dec 2015 11:31:57 +0100, Hendrik Leppkes wrote: > On Tue, Dec 15, 2015 at 11:20 AM, Michael Niedermayer > wrote: > > On Tue, Dec 15, 2015 at 08:58:01AM +0100, Jean Delvare wrote: > >> Also I can see 12 occurrences of the same cast for this parameter of >

Re: [FFmpeg-devel] about the ffmpeg H.265 decoder iOS compatibility

On Tuesday 15 December 2015 11:29:58 am Moritz Barsnick wrote: > On Tue, Dec 15, 2015 at 10:07:23 +, Zhu Hongbo wrote: > > I found that the ffmpeg H.265 decoder can't run on the iOS platform > > when I enable the neon assembly code, it crashed when playing the > > H.265 clip. When disable the

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

On 15.12.2015 14:42, Timo Rothenpieler wrote: > So, to get somewhere with this, would everybody be ok if I change this > to remove the non-free marking, but keep it disabled by default for now? That would be OK for me. > Or is putting that exception-text in nvenc.c enough to make enabling it >

Re: [FFmpeg-devel] [PATCH] lavu/frame: Optimize frame_copy_video

Hi Derek, On Tue, 15 Dec 2015 17:39:23 +, Derek Buitenhuis wrote: > On 12/15/2015 5:23 PM, Jean Delvare wrote: > > Looks like something different from what we were discussing here. > > In which way? > > That patch fixes pointer aliasing in the same way yours breaks it, AFAICT? I see two

Re: [FFmpeg-devel] [PATCH] ffm: reject a negative codec_id

On 15.12.2015 03:15, Michael Niedermayer wrote: > On Tue, Dec 15, 2015 at 01:19:01AM +0100, Andreas Cadhalpun wrote: >> On 15.12.2015 00:43, Michael Niedermayer wrote: >> ffmdec.c | 28 >> 1 file changed, 28 insertions(+) >> 5a300bbcfb78b1f24b8b7c572d420577b2a1b1f3

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote: > On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote: >> exp2 suffices here. Some trivial (~ 4x) speedup is done in addition here by >> reusing results. >> > >> This is bit-identical to the old values. >

Re: [FFmpeg-devel] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc

On 15.12.2015 08:17, Anton Khirnov wrote: > Can you share the sample that shows the problem? I could, but it's of no use for comparing with libopus, because their decoder errors out in an unrelated check. > From what I can see, libopus does not do any clipping at that point, so > something else

Re: [FFmpeg-devel] [PATCH 1/2] swscale/arm/yuv2rgb: simplify process_16px_* macro call

On Tue, Dec 15, 2015 at 05:46:08PM +0100, Matthieu Bouron wrote: > From: Matthieu Bouron > > --- > libswscale/arm/yuv2rgb_neon.S | 8 +--- > 1 file changed, 1 insertion(+), 7 deletions(-) should be ok [...] -- Michael GnuPG fingerprint:

[FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size

If that is the case, the loop setting predictor_state in sonic_decode_frame causes out of bounds reads of int_samples, which has only frame_size number of elements. Signed-off-by: Andreas Cadhalpun --- libavcodec/sonic.c | 7 +++ 1 file changed, 7

Re: [FFmpeg-devel] [libav-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc

On Tue, Dec 15, 2015 at 10:41:15PM +0100, Andreas Cadhalpun wrote: > On 15.12.2015 08:17, Anton Khirnov wrote: > > Can you share the sample that shows the problem? > > I could, but it's of no use for comparing with libopus, because their > decoder errors out in an unrelated check. > > > From

[FFmpeg-devel] [PATCH] ffmpeg: Allow specifying the program number for created programs

From: Michael Niedermayer Signed-off-by: Michael Niedermayer --- doc/ffmpeg.texi |4 ++-- ffmpeg_opt.c| 22 +- 2 files changed, 23 insertions(+), 3 deletions(-) diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi index

[FFmpeg-devel] Patch question

Sorry if this may sound idiotic, but if I provide a unified patch for a file that is newer/different from the one I have here, it won't work, right? Mats -- Mats Peterson http://matsp888.no-ip.org/~mats/ ___ ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] avcodec/nellymoserenc: avoid wasteful pow

On Tue, Dec 15, 2015 at 5:25 PM, Ganesh Ajjanagadde wrote: > On Tue, Dec 15, 2015 at 2:23 AM, Michael Niedermayer wrote: >> On Wed, Dec 09, 2015 at 06:55:25PM -0500, Ganesh Ajjanagadde wrote: [...] >>> >>> diff --git a/libavcodec/nellymoserenc.c

[FFmpeg-devel] [PATCH 2/2] lavc/aacsbr: sbr_dequant optimization

This uses ff_exp2fi to get a speedup (~ 6x). sample benchmark (Haswell, GNU/Linux): old: 19102 decicycles in sbr_dequant,1023 runs, 1 skips 19002 decicycles in sbr_dequant,2045 runs, 3 skips 17638 decicycles in sbr_dequant,4093 runs, 3 skips 15825 decicycles in

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

So, to get somewhere with this, would everybody be ok if I change this to remove the non-free marking, but keep it disabled by default for now? Or is putting that exception-text in nvenc.c enough to make enabling it by default viable? signature.asc Description: OpenPGP digital signature

Re: [FFmpeg-devel] [PATCH v2] avcodec/nvenc: Include NVENC SDK header

On 15 Dec, Timo Rothenpieler wrote : > So, to get somewhere with this, would everybody be ok if I change this > to remove the non-free marking, but keep it disabled by default for now? I still don't understand why you want to fork this header into the FFmpeg tree. -- Jean-Baptiste Kempf

[FFmpeg-devel] [PATCH] avcodec/qsv: export session management functionality (variant #3)

Hello All, There is updated patch version initially introduced by Sven Dueking This patch expose 3 QSV functions as public. This is needed because the VPP needs access to these functions too. Please review. -- Best regards, Ivan

[FFmpeg-devel] Regarding the QuickTime palette issue in matroskadec.c

I don't really know which is worse, calling a function in mov.c, or "duplicating" (because I'll have to admit that it's a form of duplication in a technical sense) code in it. Because *if*, against all odds, there would have to be a change in the QuickTime color table handling, it's easy to

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/nvenc: Include NVENC SDK header

On 10 Dec, Philip Langdale wrote : > >Are we really talking about including a huge 3rd party header because > >distros are so lazy? What's next, do we add Windows headers to the > >FFmpeg tree, because MinGW lags severely behind the newest definitions > >like HEVC DXVA support? > > Admittedly, we

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote: [...] > @@ -4007,6 +4008,147 @@ static int mov_read_free(MOVContext *c, AVIOContext > *pb, MOVAtom atom) > return 0; > } > > +static int mov_read_frma(MOVContext *c, AVIOContext *pb, MOVAtom atom) > +{ > +uint32_t format

[FFmpeg-devel] [PATCH] lavu/eval: remove pow and exp2 for postfixes

These postfixes can be computed statically, and there is no need to waste runtime resources. Tested with FATE. Signed-off-by: Ganesh Ajjanagadde --- libavutil/eval.c | 52 1 file changed, 28 insertions(+), 24

Re: [FFmpeg-devel] [PATCH] sonic: make sure num_taps is not larger than frame_size

On Tue, Dec 15, 2015 at 11:50:21PM +0100, Andreas Cadhalpun wrote: > If that is the case, the loop setting predictor_state in > sonic_decode_frame causes out of bounds reads of int_samples, which has > only frame_size number of elements. > > Signed-off-by: Andreas Cadhalpun

[FFmpeg-devel] [PATCH] Add support for HLS PLAYLIST types EVENT and VOD

Adds HLS flags to emit the X-PLAYLIST-TYPE tag to the top of generated M3U8 files. See the spec: https://tools.ietf.org/html/draft-pantos-http-live-streaming-18#section-4.3.3.5 There was also an FFMPEG trac ticket #4571 that had this as a wishlist item: https://trac.ffmpeg.org/ticket/4571 ---

Re: [FFmpeg-devel] [PATCH 1/3] x86/hevc_sao: simplify sao_band_filter 10/12bit

On 12/10/2015 8:02 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavcodec/x86/hevc_sao_10bit.asm | 142 > +++--- > 1 file changed, 57 insertions(+), 85 deletions(-) Ping for patchset.

Re: [FFmpeg-devel] support for reading / writing encrypted MP4 files

On Tue, Dec 15, 2015 at 09:16:11AM +, Eran Kornblau wrote: > > > > using a random IV value would break any regression tests > > see AVFMT_FLAG_BITEXACT > > > Fixed, only generating a random IV when bitexact is not enabled. > Updated patch files attached. > > > > > is this filling in a