Re: [FFmpeg-devel] [PATCH] avcodec: Add AV_CODEC_FLAG2_DONT_SPLIT_SIDE_DATA

On Wed, 8 Mar 2017 02:57:50 +0100 Michael Niedermayer wrote: > This allows to test or use the code without av_packet_split_side_data() or > allows applications to separate the side data handling out not > running it automatically. > > It also makes it easier to change the default behavior > >

Re: [FFmpeg-devel] [PATCH] lavf/dashenc: update bitrates on dash_write_trailer

On Fri, Mar 3, 2017 at 9:38 AM, Przemysław Sobala < przemyslaw.sob...@gmail.com> wrote: > From: Przemysław Sobala > > Provides a way to change bandwidth parameter inside DASH manifest after a > non-CBR H.264 encoding. > Caller now is able to compute the bitrate by itself, after all packets > have

Re: [FFmpeg-devel] [PATCH] avcodec: Add AV_CODEC_FLAG2_DONT_SPLIT_SIDE_DATA

On Wed, Mar 08, 2017 at 09:32:54AM +0100, wm4 wrote: [...] > Is there even any subtitle side data? Yes, stuff like subrip coordinates or misc vtt stuff. -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

On 08/03/17 01:25, Jun Zhao wrote: > ping ? > > On 2017/3/3 9:35, Jun Zhao wrote: >> V2: Fix the potential memory leak.2 >> >> From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001 >> From: Jun Zhao >> Date: Fri, 3 Mar 2017 09:25:53 +0800 >> Subject: [PATCH] vf_hwupload: Add miss

Re: [FFmpeg-devel] [PATCH V2] vf_hwupload: Add missing return value check

On 08/03/17 01:25, Jun Zhao wrote: > ping ? > > On 2017/3/3 9:35, Jun Zhao wrote: >> V2: Fix the potential memory leak.2 >> >> From eb283d277679b5dac9c43e8d3c98bcc9367b592f Mon Sep 17 00:00:00 2001 >> From: Jun Zhao >> Date: Fri, 3 Mar 2017 09:25:53 +0800 >> Subject: [PATCH] vf_hwupload: Add miss

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

On Tue, Mar 7, 2017 at 4:04 PM, Muhammad Faiz wrote: > On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote: >> On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote: >>> On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz wrote: this gives better frequency response update swresample fat

[FFmpeg-devel] [PATCH 01/34] arm: vp9itxfm: Avoid .irp when it doesn't save any lines

This makes it more readable. This is cherrypicked from libav commit 3bc5b28d5a191864c54bba60646933a63da31656. --- libavcodec/arm/vp9itxfm_neon.S | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_

[FFmpeg-devel] [PATCH 02/34] aarch64: vp9itxfm: Restructure the idct32 store macros

This avoids concatenation, which can't be used if the whole macro is wrapped within another macro. This is also arguably more readable. This is cherrypicked from libav commit 58d87e0f49bcbbc6f426328f53b657bae7430cd2. --- libavcodec/aarch64/vp9itxfm_neon.S | 80 +++

[FFmpeg-devel] [PATCH 14/34] aarch64: vp9itxfm: Fix incorrect vertical alignment

This is cherrypicked from libav commit 0c0b87f12d48d4e7f0d3d13f9345e828a3a5ea32. --- libavcodec/aarch64/vp9itxfm_neon.S | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index 5219d6e..6bb097b 100644 -

[FFmpeg-devel] [PATCH 04/34] aarch64: vp9itxfm: Make the larger core transforms standalone functions

This work is sponsored by, and copyright, Google. This reduces the code size of libavcodec/aarch64/vp9itxfm_neon.o from 19496 to 14740 bytes. This gives a small slowdown of a couple of tens of cycles, but makes it more feasible to add more optimized versions of these transforms. Before: vp9_inv_

[FFmpeg-devel] [PATCH 08/34] aarch64: vp9itxfm: Do separate functions for half/quarter idct16 and idct32

This work is sponsored by, and copyright, Google. This avoids loading and calculating coefficients that we know will be zero, and avoids filling the temp buffer with zeros in places where we know the second pass won't read. This gives a pretty substantial speedup for the smaller subpartitions. T

[FFmpeg-devel] [PATCH 07/34] arm: vp9itxfm: Do a simpler half/quarter idct16/idct32 when possible

This work is sponsored by, and copyright, Google. This avoids loading and calculating coefficients that we know will be zero, and avoids filling the temp buffer with zeros in places where we know the second pass won't read. This gives a pretty substantial speedup for the smaller subpartitions. T

[FFmpeg-devel] [PATCH 17/34] aarch64: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter

No measured speedup on a Cortex A53, but other cores might benefit. This is cherrypicked from libav commit 388e0d2515bc6bbc9d0c9af1d230bd16cf945fe7. --- libavcodec/aarch64/vp9mc_neon.S | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9mc_ne

[FFmpeg-devel] [PATCH 16/34] arm: vp9mc: Calculate less unused data in the 4 pixel wide horizontal filter

Before:Cortex A7 A8 A9 A53 vp9_put_8tap_smooth_4h_neon: 378.1 273.2 340.7 229.5 After: vp9_put_8tap_smooth_4h_neon: 352.1 222.2 290.5 229.5 This is cherrypicked from libav commit fea92a4b57d1c328b1de226a5f213a629ee63754. --- libavcodec/arm/vp9mc_neon

[FFmpeg-devel] [PATCH 15/34] aarch64: vp9mc: Simplify the extmla macro parameters

Fold the field lengths into the macro. This makes the macro invocations much more readable, when the lines are shorter. This also makes it easier to use only half the registers within the macro. This is cherrypicked from libav commit 5e0c2158fbc774f87d3ce4b7b950ba4d42c4a7b8. --- libavcodec/aarc

[FFmpeg-devel] [PATCH 23/34] aarch64: vp9lpf: Interleave the start of flat8in into the calculation above

This adds lots of extra .ifs, but speeds it up by a couple cycles, by avoiding stalls. This is cherrypicked from libav commit b0806088d3b27044145b20421da8d39089ae0c6a. --- libavcodec/aarch64/vp9lpf_neon.S | 14 +++--- 1 file changed, 11 insertions(+), 3 deletions(-) diff --git a/libavcod

[FFmpeg-devel] [PATCH 26/34] arm/aarch64: vp9lpf: Keep the comparison to E within 8 bit

The theoretical maximum value of E is 193, so we can just saturate the addition to 255. Before: Cortex A7 A8 A9 A53 A53/AArch64 vp9_loop_filter_v_4_8_neon: 143.0 127.7 114.888.0 87.7 vp9_loop_filter_v_8_8_neon: 241.0 197.2 173.7 140.

[FFmpeg-devel] [PATCH 25/34] aarch64: Add parentheses around the offset parameter in movrel

This fixes building with clang for linux with PIC enabled. This is cherrypicked from libav commit 8847eeaa14189885038140fb2b8a7adc7100. --- libavutil/aarch64/asm.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/aarch64/asm.S b/libavutil/aarch64/asm.S index 5

[FFmpeg-devel] [PATCH 24/34] aarch64: vp9lpf: Fix broken indentation/vertical alignment

This is cherrypicked from libav commit 07b5136c481d394992c7e951967df0cfbb346c0b. --- libavcodec/aarch64/vp9lpf_neon.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9lpf_neon.S b/libavcodec/aarch64/vp9lpf_neon.S index cd3e26c..ebfd9be 100644 --- a/liba

[FFmpeg-devel] [PATCH 29/34] arm: vp9itxfm: Avoid reloading the idct32 coefficients

The idct32x32 function actually pushed q4-q7 onto the stack even though it didn't clobber them; there are plenty of registers that can be used to allow keeping all the idct coefficients in registers without having to reload different subsets of them at different stages in the transform. Since the

[FFmpeg-devel] [PATCH 31/34] arm: vp9itxfm: Reorder the idct coefficients for better pairing

All elements are used pairwise, except for the first one. Previously, the 16th element was unused. Move the unused element to the second slot, to make the later element pairs not split across registers. This simplifies loading only parts of the coefficients, reducing the difference to the 16 bpp v

[FFmpeg-devel] [PATCH 32/34] aarch64: vp9itxfm: Reorder the idct coefficients for better pairing

All elements are used pairwise, except for the first one. Previously, the 16th element was unused. Move the unused element to the second slot, to make the later element pairs not split across registers. This simplifies loading only parts of the coefficients, reducing the difference to the 16 bpp v

[FFmpeg-devel] [PATCH 30/34] aarch64: vp9itxfm: Avoid reloading the idct32 coefficients

The idct32x32 function actually pushed d8-d15 onto the stack even though it didn't clobber them; there are plenty of registers that can be used to allow keeping all the idct coefficients in registers without having to reload different subsets of them at different stages in the transform. After thi

[FFmpeg-devel] [PATCH 27/34] aarch64: vp9lpf: Use dup+rev16+uzp1 instead of dup+lsr+dup+trn1

This is one cycle faster in total, and three instructions fewer. Before: vp9_loop_filter_mix2_v_44_16_neon: 123.2 After: vp9_loop_filter_mix2_v_44_16_neon: 122.2 This is cherrypicked from libav commit 3bf9c48320f25f3d5557485b0202f22ae60748b0. --- libavcodec/aarch64/vp9lpf_neon.S | 21 +--

[FFmpeg-devel] [PATCH 28/34] arm: vp9lpf: Implement the mix2_44 function with one single filter pass

For this case, with 8 inputs but only changing 4 of them, we can fit all 16 input pixels into a q register, and still have enough temporary registers for doing the loop filter. The wd=8 filters would require too many temporary registers for processing all 16 pixels at once though. Before:

[FFmpeg-devel] [PATCH 33/34] arm: vp9itxfm: Reorder iadst16 coeffs

This matches the order they are in the 16 bpp version. There they are in this order, to make sure we access them in the same order they are declared, easing loading only half of the coefficients at a time. This makes the 8 bpp version match the 16 bpp version better. This is cherrypicked from li

[FFmpeg-devel] [PATCH 34/34] aarch64: vp9itxfm: Reorder iadst16 coeffs

This matches the order they are in the 16 bpp version. There they are in this order, to make sure we access them in the same order they are declared, easing loading only half of the coefficients at a time. This makes the 8 bpp version match the 16 bpp version better. This is cherrypicked from li

[FFmpeg-devel] [PATCH 03/34] arm: vp9itxfm: Make the larger core transforms standalone functions

This work is sponsored by, and copyright, Google. This reduces the code size of libavcodec/arm/vp9itxfm_neon.o from 15324 to 12388 bytes. This gives a small slowdown of a couple tens of cycles, up to around 150 cycles for the full case of the largest transform, but makes it more feasible to add m

[FFmpeg-devel] [PATCH 22/34] arm: vp9lpf: Interleave the start of flat8in into the calculation above

This adds lots of extra .ifs, but speeds it up by a couple cycles, by avoiding stalls. This is cherrypicked from libav commit e18c39005ad1dbb178b336f691da1de91afd434e. --- libavcodec/arm/vp9lpf_neon.S | 8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/libavcodec/arm/vp9lp

[FFmpeg-devel] [PATCH 06/34] aarch64: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function

This allows reusing the macro for a separate implementation of the pass2 function. This is cherrypicked from libav commit 79d332ebbde8c0a3e9da094dcfd10abd33ba7378. --- libavcodec/aarch64/vp9itxfm_neon.S | 90 +++--- 1 file changed, 45 insertions(+), 45 deletions(-)

[FFmpeg-devel] [PATCH 21/34] arm: vp9lpf: Use orrs instead of orr+cmp

This is cherrypicked from libav commit 435cd7bc99671bf561193421a50ac6e9d63c4266. --- libavcodec/arm/vp9lpf_neon.S | 12 1 file changed, 4 insertions(+), 8 deletions(-) diff --git a/libavcodec/arm/vp9lpf_neon.S b/libavcodec/arm/vp9lpf_neon.S index 2761956..3d289e5 100644 --- a/libavco

[FFmpeg-devel] [PATCH 05/34] arm: vp9itxfm: Move the load_add_store macro out from the itxfm16 pass2 function

This allows reusing the macro for a separate implementation of the pass2 function. This is cherrypicked from libav commit 47b3c2c18d1897f3c753ba0cec4b2d7aa24526af. --- libavcodec/arm/vp9itxfm_neon.S | 72 +- 1 file changed, 36 insertions(+), 36 deletions(-)

[FFmpeg-devel] [PATCH 18/34] arm: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling

This work is sponsored by, and copyright, Google. Before:Cortex A7 A8 A9 A53 vp9_inv_dct_dct_16x16_sub1_add_neon: 273.0 189.5 211.7 235.8 vp9_inv_dct_dct_32x32_sub1_add_neon: 752.0 459.2 862.2 553.9 After: vp9_inv_dct_dct_16x16_sub1_add_neo

[FFmpeg-devel] [PATCH 13/34] aarch64: vp9itxfm: Update a comment to refer to a register with a different name

This is cherrypicked from libav commit 8476eb0d3ab1f7a52317b23346646389c08fb57a. --- libavcodec/aarch64/vp9itxfm_neon.S | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index 3b34749..5219d6e 100644 ---

[FFmpeg-devel] [PATCH 19/34] aarch64: vp9itxfm: Optimize 16x16 and 32x32 idct dc by unrolling

This work is sponsored by, and copyright, Google. Before: Cortex A53 vp9_inv_dct_dct_16x16_sub1_add_neon: 235.3 vp9_inv_dct_dct_32x32_sub1_add_neon: 555.1 After: vp9_inv_dct_dct_16x16_sub1_add_neon: 180.2 vp9_inv_dct_dct_32x32_sub1_add_neon: 475.3 This is cherryp

[FFmpeg-devel] [PATCH 10/34] aarch64: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function

This is cherrypicked from libav commit 4da4b2b87f08a1331650c7e36eb7d4029a160776. --- libavcodec/aarch64/vp9itxfm_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index 3eb999a..df178d2 100644 --- a

[FFmpeg-devel] [PATCH 11/34] aarch64: vp9itxfm: Use a single lane ld1 instead of ld1r where possible

The ld1r is a leftover from the arm version, where this trick is beneficial on some cores. Use a single-lane load where we don't need the semantics of ld1r. This is cherrypicked from libav commit ed8d293306e12c9b79022d37d39f48825ce7f2fa. --- libavcodec/aarch64/vp9itxfm_neon.S | 16 --

[FFmpeg-devel] [PATCH 09/34] arm: vp9itxfm: Share instructions for loading idct coeffs in the 8x8 function

This is cherrypicked from libav commit 3933b86bb93aca47f29fbd493075b0f110c1e3f5. --- libavcodec/arm/vp9itxfm_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libavcodec/arm/vp9itxfm_neon.S b/libavcodec/arm/vp9itxfm_neon.S index 33a7af1..78fdae6 100644 --- a/libavcodec/a

[FFmpeg-devel] [PATCH 12/34] aarch64: vp9itxfm: Use the right lane sizes in 8x8 for improved readability

This is cherrypicked from libav commit 3dd7827258ddaa2e51085d0c677d6f3b1be3572f. --- libavcodec/aarch64/vp9itxfm_neon.S | 16 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/libavcodec/aarch64/vp9itxfm_neon.S b/libavcodec/aarch64/vp9itxfm_neon.S index e42cc2d..3b347

[FFmpeg-devel] [PATCH 20/34] arm/aarch64: vp9lpf: Calculate !hev directly

Previously we first calculated hev, and then negated it. Since we were able to schedule the negation in the middle of another calculation, we don't see any gain in all cases. Before: Cortex A7 A8 A9 A53 A53/AArch64 vp9_loop_filter_v_4_8_neon: 147.0 129.0

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara wrote: > This should address the mismatch between different archs Removing the side_data_size from output should be fine, as its a implementation detail and as seen here can even vary between architecture or possibly even compiler. Maybe someone th

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > wrote: > > This should address the mismatch between different archs iam not in favor of this solution > > Removing the side_data_size from output should be fine, as its a > imp

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 12:51:06 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > > wrote: > > > This should address the mismatch between different archs > > iam not in favor of this solutio

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 12:51:06 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > > On Wed, Mar 8, 2017 at 1:17 AM, Vittorio Giovara > > > wrote: > > > > This should address the misma

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 13:04:11 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 12:51:06 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 12:28:17PM +0100, Hendrik Leppkes wrote: > > > > On Wed, Mar 8, 2017 at

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

On Wed, Mar 8, 2017 at 10:16 AM, Muhammad Faiz wrote: > On Tue, Mar 7, 2017 at 4:04 PM, Muhammad Faiz wrote: >> On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote: >>> On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote: On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz wrote: > this gi

[FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

It looks like this could lead to security issues, as side data readers will for example rely on side data allocation sizes to be as large as needed for correct operation. If such files exist at all, they also should be brought out of circulation, so fully reject them. Under normal circumstances, no

[FFmpeg-devel] [PATCH 1/3] aacdec: do not mutate input packet metadata

Apparently the demuxer outputs the wrong padding for HE-AAC (based on the raw sample rate, or so). aacdec contains a hack to adjust the muxer padding accordingly before it's used to trim the decoder output. This modified the packet side data, which in combination with the old decoding API would cha

[FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

Side data are separate AVPacket fields for a reason. Merging side data requires reallocating all packets, is complex, potentially clashes with "actual" packet data (you could probably come up with PCM data that looks like merged side data, or such), and could for example cause trouble to people try

[FFmpeg-devel] [PATCH] avfilter/allfilters: Prefer s32 format over float

Because float actually int24 in the range [-1, 1] Signed-off-by: Aleksey Vasenev --- libavfilter/avfiltergraph.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/avfiltergraph.c b/libavfilter/avfiltergraph.c index 534c6701a8..61c10eeecd 100644 --- a/libavfilter

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 13:04:11 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 12:51:06 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 12:28

[FFmpeg-devel] [PATCH] libavcodec/libopenjpegenc.c

Final version of simple patch to : limit encoder to single layer add lossless option set better defaults for a few encoding parameters. Cheers, Aaron 0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch Description: Binary data ___ ffmpeg-d

Re: [FFmpeg-devel] [PATCH 1/3] aacdec: do not mutate input packet metadata

On Wed, Mar 08, 2017 at 01:40:10PM +0100, wm4 wrote: > Apparently the demuxer outputs the wrong padding for HE-AAC (based on > the raw sample rate, or so). aacdec contains a hack to adjust the muxer > padding accordingly before it's used to trim the decoder output. This > modified the packet side d

Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

On Tue, Mar 07, 2017 at 04:36:15PM -0800, Thomas Turner wrote: > The Chen-Shapiro(CS) test was used to test normality for > Lagged Fibonacci PRNG. > > Normality Hypothesis Test: > > The null hypothesis formally tests if the population > the sample represents is normally-distributed. For > CS, whe

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, 8 Mar 2017 14:09:53 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:12:04PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 13:04:11 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 12:56:31PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 12:51:06 +0100 >

Re: [FFmpeg-devel] fate: Do not report side data size

Hi, On Wed, Mar 8, 2017 at 9:31 AM, wm4 wrote: > On Wed, 8 Mar 2017 14:09:53 +0100 > Michael Niedermayer wrote: > > If the size printing is removed then other code should be added > > to test for the size to match the correct value > > Then it would be more reasonable to make av_packet_add_side

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > It looks like this could lead to security issues, as side data readers anything could, but side data wasnt excluded from fuzzing, in fact ive seen fuzzers find and trigger the split code also a demuxer and user app could always set side data t

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote: > Side data are separate AVPacket fields for a reason. Merging side data > requires reallocating all packets, is complex, potentially clashes with > "actual" packet data (you could probably come up with PCM data that > looks like merged side dat

Re: [FFmpeg-devel] [PATCH 01/34] arm: vp9itxfm: Avoid .irp when it doesn't save any lines

On Wed, Mar 08, 2017 at 12:00:41PM +0200, Martin Storsjö wrote: > This makes it more readable. > > This is cherrypicked from libav commit > 3bc5b28d5a191864c54bba60646933a63da31656. > --- > libavcodec/arm/vp9itxfm_neon.S | 24 > 1 file changed, 12 insertions(+), 12 deleti

Re: [FFmpeg-devel] fate: Do not report side data size

On Wed, Mar 8, 2017 at 6:51 AM, Michael Niedermayer wrote: >> Removing the side_data_size from output should be fine, as its a >> implementation detail and as seen here can even vary between >> architecture or possibly even compiler. >> Maybe someone that uses that ffprobe output more often can co

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

On Wed, Mar 8, 2017 at 7:15 PM, Hendrik Leppkes wrote: > On Wed, Mar 8, 2017 at 10:16 AM, Muhammad Faiz wrote: >> On Tue, Mar 7, 2017 at 4:04 PM, Muhammad Faiz wrote: >>> On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote: On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote: > On Wed

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 15:36:25 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > It looks like this could lead to security issues, as side data readers > > anything could, but side data wasnt excluded from fuzzing, in fact > ive seen fuzzers find and trig

Re: [FFmpeg-devel] [PATCH 3/3] avformat: don't "merge" side data into packet data by default

On Wed, 8 Mar 2017 15:44:36 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 01:40:12PM +0100, wm4 wrote: > > Side data are separate AVPacket fields for a reason. Merging side data > > requires reallocating all packets, is complex, potentially clashes with > > "actual" packet data (you

[FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

except filter_length == 1 odd filter_length gives worse frequency response, even when compared with shorter filter_length also makes build_filter simpler Signed-off-by: Muhammad Faiz --- libswresample/resample.c | 56 +++- tests/fate/libswresample.mak | 76 +

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 15:36:25 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > > It looks like this could lead to security issues, as side data readers [...] > > also size checks are needed for

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 17:11:12 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 15:36:25 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 01:40:11PM +0100, wm4 wrote: > > > > It looks like this could lead to se

Re: [FFmpeg-devel] fate: Do not report side data size

L'octidi 18 ventôse, an CCXXV, Vittorio Giovara a écrit : > I'm just going to say that for the case at hand > sizeof(AVSphericalMapping) is not part of the ABI, and so it is > allowed to have different sizes on different architectures. I am not sure exactly what you are asserting here, but just fo

[FFmpeg-devel] [PATCH] avfilter/vf_interlace: add complex vertcal lowpassfilter

Hi, attached patch adds a complex (-1 2 6 2 -1) vertcal lowpassfilter to vf_interlace. This will better retain detail and reduce blurring compared to the existing (1 2 1) filter. Please comment. 0001-avfilter-vf_interlace-add-complex-vertcal-lowpassfil.patch Description: Binary data __

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/pictordec: Fix runtime error: left shift of 64 by 25 places cannot be represented in type 'int'

On Tue, Mar 07, 2017 at 02:41:40AM +0100, Michael Niedermayer wrote: > Fixes: 724/clusterfuzz-testcase-6738249571631104 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pictordec.c |

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/wavpack: Fix runtime error: left shift of negative value -5

On Tue, Mar 07, 2017 at 02:41:41AM +0100, Michael Niedermayer wrote: > Fixes: 729/clusterfuzz-testcase-5154831595470848 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 2

[FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

Right now, the concat filter does not set the frame_rate value on any of the out links. As a result, the default ffmpeg behaviour kicks in - to copy the framerate from the first input to the outputs. If a later input is higher framerate, this results in dropped frames; if a later input is lower fr

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 17:11:12 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 15:36:25 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 01:40

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 17:11:12 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 15:36:25 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 01:40

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > Right now, the concat filter does not set the frame_rate value on any of > the out links. As a result, the default ffmpeg behaviour kicks in - to > copy the framerate from the first input to the outputs. > > If a later input is higher framer

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:03:21 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:20:15 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: > except filter_length == 1 > > odd filter_length gives worse frequency response, > even when compared with shorter filter_length > > also makes build_filter simpler > > Signed-off-by: Muhammad Faiz > --- > libswresample/resample.c

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:20:15 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 17:11:12 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 15:36:25 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On 3/8/2017 3:35 PM, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > >> On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: >>> On Wed, 8 Mar 2017 17:11:12 +0100 >>> Michael Niedermayer wrote: >>> On Wed, Mar 08, 2017 at 04:06:20PM +0100, wm4 wrote: >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:31:27PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:03:21 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

Re: [FFmpeg-devel] [PATCH] avfiltergraph: add -sample_rate_fallback

Le septidi 17 ventôse, an CCXXV, Takayuki 'January June' Suwa a écrit : > dedicated to all audiophiles :) > > examples: > -sample_rate_fallback closest -i 48ksps_source -af > "aformat=sample_rates=44100|88200|176400|352800" > => 44.1ksps (default behavior) > -sample_rate_fallback higher >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

Re: [FFmpeg-devel] [PATCH] swresample/resample: do not allow odd filter_length

On Thu, Mar 9, 2017 at 1:32 AM, Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 10:25:42PM +0700, Muhammad Faiz wrote: >> except filter_length == 1 >> >> odd filter_length gives worse frequency response, >> even when compared with shorter filter_length >> >> also makes build_filter simpler >>

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 19:56:42 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:31:27PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:03:21 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > > > If a later input is higher framerate, this results in dropped frames; if > > a later input is lower framerate it might cause judder. > > > > The simplest fix is to just set th

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:15:24 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:20:15 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 08 Mar 2017 14:14:25 -0500 Calvin Walton wrote: > On Wed, 2017-03-08 at 19:27 +0100, Nicolas George wrote: > > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > > > > > If a later input is higher framerate, this results in dropped frames; if > > > a later input is lower framer

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > Hmm. Setting it to the same as the input value if all inputs match > shouldn't be too hard, I think. > > In the actual case of inputs with different frame rates, would it be > better to use the '1/0' value, or should it attempt to calculate

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 08:23:26PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 20:15:24 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 19:20:15 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 05:26

Re: [FFmpeg-devel] [PATCH] Allow 'concat' filter to support inputs with different frame rates

On Wed, 2017-03-08 at 20:35 +0100, Nicolas George wrote: > L'octidi 18 ventôse, an CCXXV, Calvin Walton a écrit : > > Hmm. Setting it to the same as the input value if all inputs match > > shouldn't be too hard, I think. > > > > In the actual case of inputs with different frame rates, would it be

[FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

Signed-off-by: James Almer --- libavformat/matroskaenc.c | 69 +++ 1 file changed, 69 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 1605f0cafe..0ee927d63e 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > On Wed, 8 Mar 2017 19:20:15 +0100 > Michael Niedermayer wrote: > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > On Wed, 8 Mar 2017 17:11:12 +0100 > > > Michael Niedermayer wrote: > > > > > > > On Wed, Mar 08, 2017 at 04:06

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:42:17 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 08:23:26PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 20:15:24 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 07:35:50PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 19:20:15 +0100 >

Re: [FFmpeg-devel] [PATCH 2/3] avformat: reject FFmpeg-style merged side data in raw packets

On Wed, 8 Mar 2017 20:54:43 +0100 Michael Niedermayer wrote: > On Wed, Mar 08, 2017 at 07:32:26PM +0100, wm4 wrote: > > On Wed, 8 Mar 2017 19:20:15 +0100 > > Michael Niedermayer wrote: > > > > > On Wed, Mar 08, 2017 at 05:26:57PM +0100, wm4 wrote: > > > > On Wed, 8 Mar 2017 17:11:12 +0100 >

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: > Signed-off-by: James Almer > --- > libavformat/matroskaenc.c | 69 > +++ > 1 file changed, 69 insertions(+) > > diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c > index 1605f0cafe.

[FFmpeg-devel] Point Cloud Compression

Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not does FFMPEG support this? http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression Thanks, Randall Toepfer scandy.co ___ ffmpeg-devel mailing list ffmpeg-deve

Re: [FFmpeg-devel] Point Cloud Compression

On Wed, Mar 8, 2017 at 10:23 PM, Toepfer, Randall wrote: > Has anyone used FFMPEG for point cloud mpeg encoding and streaming? If not > does FFMPEG support this? > > http://mpeg.chiariglione.org/standards/exploration/point-cloud-compression > From the document "Call for Proposals for Point Cloud

[FFmpeg-devel] problem with block level audio decoding on a that is not streaming

I've tried to update my code from avcodec_decode_audio4 to the new avcodec_send_packet. I've got a block of data to decode, so this is not a streaming design. 1. When I pass a big block of data to the interface, the time required to process the buffer goes from 1.5s to 30s. 2. When I try and pa

Re: [FFmpeg-devel] [PATCH] avformat/matroskaenc: add support for Spherical Video elements

On 3/8/2017 5:08 PM, Vittorio Giovara wrote: > On Wed, Mar 8, 2017 at 2:46 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >> libavformat/matroskaenc.c | 69 >> +++ >> 1 file changed, 69 insertions(+) >> >> diff --git a/libavformat/matrosk

[FFmpeg-devel] [PATCH v2] avformat/matroskaenc: add support for Spherical Video elements

Signed-off-by: James Almer --- libavformat/matroskaenc.c | 75 +++ 1 file changed, 75 insertions(+) diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c index 1605f0cafe..70b0ced226 100644 --- a/libavformat/matroskaenc.c +++ b/libavformat

  1   2   >