2015-02-06 1:15 GMT+01:00 James Almer :
> On 05/02/15 4:20 PM, Christophe Gisquet wrote:
>> From: plepere
>
> This should probably be changed to Pierre Edouard Lepere.
Yeah, I amended with --author=lepere and that's what I got: it's what
appears in 9ba6b17add2, 942e22c651, 92cccb7bcd and in fact
On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu wrote:
> (num_quant_units - 1) is later used as an index to atrac3p_qu_to_subband,
> which only has 32 elements (i.e. maximum of num_quant_units is 32).
> ---
> libavcodec/atrac3plus.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Note th
Fixes warning in `make checkheaders`.
---
libavfilter/generate_wave_table.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavfilter/generate_wave_table.h
b/libavfilter/generate_wave_table.h
index 37ea2aa..5fe297e 100644
--- a/libavfilter/generate_wave_table.h
+++ b/libavfilter/generate_
Fixes warning in `make checkheaders`.
---
libavcodec/audioconvert.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/audioconvert.h b/libavcodec/audioconvert.h
index 556ab31..996c3f3 100644
--- a/libavcodec/audioconvert.h
+++ b/libavcodec/audioconvert.h
@@ -23,6 +23,8 @@
#ifndef A
Hi,
2015-02-06 1:28 GMT+01:00 James Almer :
> Many (But not all) of the functions calling these macros have free regs where
> max_pixels_%2
> and zero (or in that case a simple pxor m*, m*) could be stored.
> It'll probably be faster than reloading these constants inside a loop.
That often needs
---
libavformat/rtspdec.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/rtspdec.c b/libavformat/rtspdec.c
index c899498..5474577 100644
--- a/libavformat/rtspdec.c
+++ b/libavformat/rtspdec.c
@@ -677,7 +677,6 @@ static int rtsp_listen(AVFormatContext *s)
return AVERRO
---
libavformat/rtpproto.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/rtpproto.c b/libavformat/rtpproto.c
index b6b8924..59311be 100644
--- a/libavformat/rtpproto.c
+++ b/libavformat/rtpproto.c
@@ -425,7 +425,6 @@ static int rtp_read(URLContext *h, uint8_t *buf, int size)
---
libavcodec/bmvvideo.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/bmvvideo.c b/libavcodec/bmvvideo.c
index 5143b2a..12bb281 100644
--- a/libavcodec/bmvvideo.c
+++ b/libavcodec/bmvvideo.c
@@ -193,7 +193,6 @@ static int decode_bmv_frame(const uint8_t *source, int
src_len, uint
---
libavformat/nutenc.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavformat/nutenc.c b/libavformat/nutenc.c
index 3146f89..c335e64 100644
--- a/libavformat/nutenc.c
+++ b/libavformat/nutenc.c
@@ -168,7 +168,6 @@ static void build_frame_code(AVFormatContext *s)
int start2 = s
(num_quant_units - 1) is later used as an index to atrac3p_qu_to_subband,
which only has 32 elements (i.e. maximum of num_quant_units is 32).
---
libavcodec/atrac3plus.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
index 575a
---
libavformat/img2dec.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 1ab1309..8c5e9d5 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -599,10 +599,8 @@ static int bmp_probe(AVProbeData *p)
if (
---
libavutil/opt.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index c68dacc..45fcf95 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -256,8 +256,6 @@ static int set_string_number(void *obj, void *target_obj,
const AVOp
Signed-off-by: James Almer
---
See
http://fate.ffmpeg.org/log.cgi?time=20150206062639&log=compile&slot=x86_64-darwin-gcc-4.6
libavcodec/x86/lossless_audiodsp_init.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/x86/lossless_audiodsp_init.c
b/libavcodec/
On 06/02/15 12:57 AM, Ben Boeckel wrote:
> +if (s->error_recognition & AV_EF_COMPLIANT)
> +level = AV_LOG_ERROR;
> +av_log(s, level, "Spec-compliant FLAC do not support ID3 tags.\n");
As i said back when i mentioned this flag to you (and Timothy just confirmed),
if
AV
On Thu Feb 05 2015 at 7:57:21 PM Ben Boeckel wrote:
> FLAC doesn't really support ID3 tags, so warn if they are found at all.
> If vorbis tags are found, toss out duplicate ID3 tags.
>
> Fixes #3799.
>
> Signed-off-by: Ben Boeckel
> ---
> libavformat/flacdec.c | 27 +++
>
FLAC doesn't really support ID3 tags, so warn if they are found at all.
If vorbis tags are found, toss out duplicate ID3 tags.
Fixes #3799.
Signed-off-by: Ben Boeckel
---
libavformat/flacdec.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavformat/flacdec.c
On 05/02/15 5:38 PM, Michael Niedermayer wrote:
> On Thu, Feb 05, 2015 at 02:25:27PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavformat/tta.c | 34 ++
>> 1 file changed, 22 insertions(+), 12 deletions(-)
>
> can probably be simplified by
Otherwise we may not flush a decoder when a new stream is opened during an
already eof condition.
Signed-off-by: Marton Balint
---
ffplay.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 210bae5..51c3c54 100644
--- a/ffplay.c
+++ b/ffpl
Signed-off-by: Marton Balint
---
ffplay.c | 54 ++
1 file changed, 22 insertions(+), 32 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 51c3c54..8c62f9c 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -191,12 +191,11 @@ typedef struct Decoder {
It is better than using simply video clock, because video clock may be NAN.
Signed-off-by: Marton Balint
---
ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index c112ead..210bae5 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1494,7 +1494,7 @@ static v
On 05/02/15 4:20 PM, Christophe Gisquet wrote:
> From: Mickaël Raulet
>
> Conflicts:
> libavcodec/x86/hevc_mc.asm
> ---
> libavcodec/x86/hevc_mc.asm | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.as
On 05/02/15 4:20 PM, Christophe Gisquet wrote:
> From: plepere
This should probably be changed to Pierre Edouard Lepere.
> +%if cpuflag(avx2) && (%0 == 3)
> +
> +vextracti128 xm10, m0, 1
> +vinserti128 m10, m1, xm10, 0
> +vinserti128 m0, m0, xm1, 1
> +mova m1, m10
> +
> +vext
On Fri, Feb 06, 2015 at 12:18:01AM +0100, Michael Niedermayer wrote:
> This is needed as the mmx code is used as fallback from the ssse3 code
>
> Suggested-by: jamrial
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/x86/lossless_audiodsp.asm |2 +-
> 1 file changed, 1 insertion(+), 1
This is needed as the mmx code is used as fallback from the ssse3 code
Suggested-by: jamrial
Signed-off-by: Michael Niedermayer
---
libavcodec/x86/lossless_audiodsp.asm |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/x86/lossless_audiodsp.asm
b/libavcodec/x86/l
it is not related with the inside padding, and yes it does try to follow the
css/ffmpeg vocabulary. 'boxborderw' refer to what css names: 'border-width',
but ffmpeg drawtext already has a 'borderw' option, that is actually
used for what
css will call: font-weight. to be close to css, but not brak
Hi,
On Thu, Feb 5, 2015 at 2:20 PM, Christophe Gisquet <
christophe.gisq...@gmail.com> wrote:
> diff --git a/libavcodec/x86/vp9intrapred.asm
> b/libavcodec/x86/vp9intrapred.asm
> index 169676f..08b3ae8 100644
> --- a/libavcodec/x86/vp9intrapred.asm
> +++ b/libavcodec/x86/vp9intrapred.asm
> @@ -64
On Thu, Feb 05, 2015 at 12:10:12PM +0100, Stefano Sabatini wrote:
> On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded:
> > On Wed, Feb 04, 2015 at 03:23:59PM +0100, Michael Niedermayer wrote:
> > > On Wed, Feb 04, 2015 at 12:34:53PM +0100, Stefano Sabatini wrote:
> > > > On d
On Thu, Feb 05, 2015 at 06:04:56PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 05, 2015 at 12:49:20PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2015-02-04 16:18:32 +0100, Michael Niedermayer encoded:
> > > On Wed, Feb 04, 2015 at 12:26:15PM +0100, Stefano Sabatini wrote:
> > > > This
On Thu, Feb 05, 2015 at 10:40:47PM +0100, Nicolas George wrote:
> Le septidi 17 pluviôse, an CCXXIII, Clement Boesch a écrit :
> > So after each release, packagers need to check the configure and make sure
> > there aren't new libraries that will randomly be linked to, and add new
> > flag to make
On Wed, Feb 04, 2015 at 09:11:34PM +0100, Clément Bœsch wrote:
> This reverts commit 23ec8db8a07467a1fbef0c79f16b33040ca63c24.
>
> There is no reason to enable libxcb by default. This is inconsistent
> with all the other libs (we don't do it for x11, opengl, ...) and drag
> many unwanted dependenc
Le septidi 17 pluviôse, an CCXXIII, Clement Boesch a écrit :
> So after each release, packagers need to check the configure and make sure
> there aren't new libraries that will randomly be linked to, and add new
> flag to make sure it's disabled?
Well, yes, duh. That is exactly their job descripti
On Thu, Feb 05, 2015 at 10:24:49PM +0100, Clément Bœsch wrote:
> On Thu, Feb 05, 2015 at 10:00:19PM +0100, Christophe Gisquet wrote:
> > ffmpeg | branch: master | Christophe Gisquet
> > | Thu Feb 5 19:51:22 2015 +0100|
> > [9a2f5d825a257cc72d569a91746219c7974da6e4] | committer: Michael Niederma
On Thu, Feb 05, 2015 at 10:33:38PM +0100, wm4 wrote:
> On Thu, 5 Feb 2015 22:11:22 +0100
> Clément Bœsch wrote:
>
> > On Thu, Feb 05, 2015 at 04:55:37PM +0100, Nicolas George wrote:
> > > Le sextidi 16 pluviôse, an CCXXIII, Clement Boesch a écrit :
> > > > Linux is not only used by desktop. Debia
On Thu, 5 Feb 2015 22:11:22 +0100
Clément Bœsch wrote:
> On Thu, Feb 05, 2015 at 04:55:37PM +0100, Nicolas George wrote:
> > Le sextidi 16 pluviôse, an CCXXIII, Clement Boesch a écrit :
> > > Linux is not only used by desktop. Debian (for example) might want to
> > > provide a ffmpeg-nox11 (just
On Thu, Feb 05, 2015 at 10:00:19PM +0100, Christophe Gisquet wrote:
> ffmpeg | branch: master | Christophe Gisquet |
> Thu Feb 5 19:51:22 2015 +0100| [9a2f5d825a257cc72d569a91746219c7974da6e4] |
> committer: Michael Niedermayer
>
> hevc: free sao buffers when receiving a new SPS
>
> The buffe
On Thu, Feb 05, 2015 at 02:22:28PM +0100, Mickaël Raulet wrote:
> Michael,
>
> Please find some commits that can be cherry picked from
> https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch
>
> Optimized deblocking filter (8bits only)
> 1b9ee47d2f43b0a029a9468233626102eb1473b8
tested
applied
On Thu, Feb 05, 2015 at 04:55:37PM +0100, Nicolas George wrote:
> Le sextidi 16 pluviôse, an CCXXIII, Clement Boesch a écrit :
> > Linux is not only used by desktop. Debian (for example) might want to
> > provide a ffmpeg-nox11 (just like vim-nox11),
>
> Well, that means they have to put --disable
On Thu, Feb 05, 2015 at 02:25:27PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/tta.c | 34 ++
> 1 file changed, 22 insertions(+), 12 deletions(-)
can probably be simplified by always calculatig the crc and only
making the final check
On Thu, Feb 05, 2015 at 01:22:09PM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Thu, Feb 5, 2015 at 10:43 AM, wm4 wrote:
>
> > All the webm/vp9 files I have seen so far can have packets that contain
> > 1 invisible and 1 visible frame. The vp9 parser separates them. Since
> > the invisible frame
---
libavcodec/x86/ac3dsp.asm | 2 +-
libavcodec/x86/constants.c | 9 -
libavcodec/x86/constants.h | 4
libavcodec/x86/h264_qpel_10bit.asm | 2 +-
libavcodec/x86/hevc_mc.asm | 14 +++---
libavcodec/x86/hevc_sao.asm| 2 +-
libavcode
The second stride is always the internal buffer one, MAX_PB_SIZE (times 2 to
get the value in bytes).
---
libavcodec/x86/hevc_mc.asm| 30 +++---
libavcodec/x86/hevcdsp.h | 4 ++--
libavcodec/x86/hevcdsp_init.c | 16
3 files changed, 25 insertions(
---
libavcodec/x86/constants.c | 22 --
libavcodec/x86/constants.h | 16 +---
libavcodec/x86/h264_deblock_10bit.asm | 6 ++
libavcodec/x86/h264_idct_10bit.asm | 4 +++-
libavcodec/x86/h264_intrapred_10bit.asm | 3 ++-
libavcod
The patches should be applied in order.
First patch "ports" OpenHEVC AVX2 code, mostly consisting in fixing
conflicts and whitespaces in the original commit.
Patch 2 uses a missed opportunity to use the newly possible chroma MC
function for 8 bits on a width of 16.
Patches 3 and 4 are other Open
The epel_hv functions were still relying on only epel_hv 8-wide
being the maximum width instanciated.
---
libavcodec/x86/hevcdsp_init.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/x86/hevcdsp_init.c b/libavcodec/x86/hevcdsp_init.c
index b1533d8..f7b3d0f 100
From: Mickaël Raulet
---
libavcodec/hevc.h | 2 +-
libavcodec/x86/hevc_mc.asm | 6 +++---
2 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/hevc.h b/libavcodec/hevc.h
index ae9a32a..e0af6f1 100644
--- a/libavcodec/hevc.h
+++ b/libavcodec/hevc.h
@@ -771,7 +771,7 @
From: plepere
before
33304 decicycles in luma_bi_1, 523066 runs, 1222 skips
38138 decicycles in luma_bi_2, 523427 runs, 861 skips
13490 decicycles in luma_uni, 516138 runs, 8150 skips
after
20185 decicycles in luma_bi_1, 519970 runs, 4318 skips
24620 decicycles in luma_bi_2, 521024 runs, 3264 ski
From: Mickaël Raulet
Conflicts:
libavcodec/x86/hevc_mc.asm
---
libavcodec/x86/hevc_mc.asm | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm
index efb4d1f..e8a5032 100644
--- a/libavcodec/x86/hevc_mc.as
Hi,
2015-02-05 19:19 GMT+01:00 Michael Niedermayer :
>> +frame->width = FFALIGN(4 * sps->width, FF_INPUT_BUFFER_PADDING_SIZE);
>
> FF_INPUT_BUFFER_PADDING_SIZE is not guranteed to be a power of 2 but
> FFALIGN needs a power of 2
I don't think the padding is actually needed because it's just
On Thu Feb 05 2015 at 7:55:43 AM Nicolas George wrote:
> Le sextidi 16 pluviôse, an CCXXIII, Clement Boesch a écrit :
> > Linux is not only used by desktop. Debian (for example) might want to
> > provide a ffmpeg-nox11 (just like vim-nox11),
>
> Well, that means they have to put --disable-libxcb
Hi,
On Thu, Feb 5, 2015 at 10:43 AM, wm4 wrote:
> All the webm/vp9 files I have seen so far can have packets that contain
> 1 invisible and 1 visible frame. The vp9 parser separates them. Since
> the invisible frame is always (?) the first sub-packet, the new packet
> is assigned the PTS of the
On Thu, Feb 05, 2015 at 08:17:25AM +0100, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-05 7:29 GMT+01:00 Christophe Gisquet :
> > We were previously reference-counting the sao-buffer. Should we do
> > that for sao_pixel_buffer_[hv], then?
>
> Something like the attached patch.
>
> Note: I'm proba
On 05/02/15 2:39 PM, Christophe Gisquet wrote:
> 2015-02-05 5:18 GMT+01:00 James Almer :
>> The stride_src parameter is always 2*MAX_PB_SIZE +
>> FF_INPUT_BUFFER_PADDING_SIZE.
>
> OK. That's the change the SAO implementations should be aware of.
>
> Good to commit.
Pushed, thanks.
On 05/02/15 12:49 PM, Christophe Gisquet wrote:
> 2015-02-05 5:18 GMT+01:00 James Almer :
>> Original x86 intrinsics code by Pierre-Edouard Lepere.
>> Yasm port, refactoring and optimizations by James Almer.
>
> OK.
Pushed, thanks.
___
ffmpeg-devel mai
On 05/02/15 12:49 PM, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-05 5:18 GMT+01:00 James Almer :
>> Original x86 intrinsics code and initial yasm port by Pierre-Edouard Lepere.
>> Refactoring and optimizations by James Almer.
>
> No further comment from me.
Pushed, thanks.
On Thu, Feb 05, 2015 at 06:47:08PM +0100, Michael Niedermayer wrote:
> On Thu, Feb 05, 2015 at 01:57:48PM +0100, Mickaël Raulet wrote:
> > PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
> >
> > Patch LGTM otherwise, it does not change the behaviour of the previous
> > implemen
That's why we are delaying SAO.
Le jeudi 5 février 2015, James Almer a écrit :
> On 05/02/15 2:34 PM, Christophe Gisquet wrote:
> > 2015-02-05 18:28 GMT+01:00 James Almer
> >:
> >> On 05/02/15 10:22 AM, Mickaël Raulet wrote:
> >>> More coming soon for epel and SAO!
> >>
> >> The SAO prototypes
On Thu, Feb 05, 2015 at 01:57:48PM +0100, Mickaël Raulet wrote:
> PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
>
> Patch LGTM otherwise, it does not change the behaviour of the previous
> implementation.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147E
On the other hand, the stride is known at compilation time, so the asm
could use that to reduce the number of gprs and therefore helps having
a x86_32 version.
--
Christophe
From 55047bbb991c95f126d597bbe05e424406af4ec4 Mon Sep 17 00:00:00 2001
From: Christophe Gisquet
Date: Tue, 3 Feb 2015 14:0
On 05/02/15 2:34 PM, Christophe Gisquet wrote:
> 2015-02-05 18:28 GMT+01:00 James Almer :
>> On 05/02/15 10:22 AM, Mickaël Raulet wrote:
>>> More coming soon for epel and SAO!
>>
>> The SAO prototypes got some slight changes with my patches. The author of
>> this
>> ARM code (or someone else) will
2015-02-05 5:18 GMT+01:00 James Almer :
> The stride_src parameter is always 2*MAX_PB_SIZE +
> FF_INPUT_BUFFER_PADDING_SIZE.
OK. That's the change the SAO implementations should be aware of.
Good to commit.
--
Christophe
___
ffmpeg-devel mailing list
2015-02-05 18:28 GMT+01:00 James Almer :
> On 05/02/15 10:22 AM, Mickaël Raulet wrote:
>> More coming soon for epel and SAO!
>
> The SAO prototypes got some slight changes with my patches. The author of this
> ARM code (or someone else) will have to revise it before it can be merged.
As a first st
On 05/02/15 10:22 AM, Mickaël Raulet wrote:
> More coming soon for epel and SAO!
The SAO prototypes got some slight changes with my patches. The author of this
ARM code (or someone else) will have to revise it before it can be merged.
___
ffmpeg-devel m
Signed-off-by: James Almer
---
libavformat/tta.c | 34 ++
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/libavformat/tta.c b/libavformat/tta.c
index 5789e5b..0c01b7b 100644
--- a/libavformat/tta.c
+++ b/libavformat/tta.c
@@ -64,7 +64,8 @@ static in
On Thu, Feb 05, 2015 at 03:08:17PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/rpl.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/rpl.c b/libavformat/rpl.c
> index c1229e8..a05bff1 100644
> --- a/libavformat/rpl.c
> +++ b/libavformat/r
On Thu, Feb 05, 2015 at 03:08:16PM +, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/thp.c | 2 ++
> 1 file changed, 2 insertions(+)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Republics decline into democracies and democrac
On Thu, Feb 05, 2015 at 12:49:20PM +0100, Stefano Sabatini wrote:
> On date Wednesday 2015-02-04 16:18:32 +0100, Michael Niedermayer encoded:
> > On Wed, Feb 04, 2015 at 12:26:15PM +0100, Stefano Sabatini wrote:
> > > This requires the new sample file matrixbench_mpeg2.lq1.mpg.
> > > ---
> > > tes
On Thu, Feb 05, 2015 at 02:22:28PM +0100, Mickaël Raulet wrote:
> Michael,
>
> Please find some commits that can be cherry picked from
> https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch
>
> Optimized deblocking filter (8bits only)
> 1b9ee47d2f43b0a029a9468233626102eb1473b8
>
> Optimzed tr
On Thu, Feb 5, 2015 at 4:24 PM, Carl Eugen Hoyos wrote:
> Kevin Wheatley gmail.com> writes:
>
>> +int ret = mov_read_avid(c, pb, atom);
>> // should we do this or read the atom directly
>> using avio_*() and not store it in extradata?
>
> Not storing the atom in extradata would break
> remuxi
Hi,
Kindly find the updated patch attached.
Thanks,
Eejya
On Thu, Feb 5, 2015 at 4:34 PM, Stefano Sabatini wrote:
> On date Thursday 2015-02-05 16:16:15 +0530, Eejya Singh encoded:
> [...]
> > From c0d6197f1936445a23b9eb726de24ed54551c675 Mon Sep 17 00:00:00 2001
> > From: Eejya Singh
> > Date:
Kevin Wheatley gmail.com> writes:
> +int ret = mov_read_avid(c, pb, atom);
> // should we do this or read the atom directly
> using avio_*() and not store it in extradata?
Not storing the atom in extradata would break
remuxing.
Did you test your patch? If it works, what
advantage would
On Thu, Feb 5, 2015 at 3:55 PM, wm4 wrote:
> Seeing how the patch actually turned out, I'd say it should be in the
> decoder. It's not necessarily mp4 specific, or is it?
In this case I'm exporting the QuickTimes from an Avid Media Composer
so they are DNxHD in .mov, and in .mp4 with both 'RGB' a
On Thu, 5 Feb 2015 15:20:41 +
Kevin Wheatley wrote:
> Hi,
>
> so I had a quick go at this but I'm still not sure on the preferred
> way of reading this, should I read the atom directly and not put the
> data in extradata?
>
> Obviously this doesn't include fixing up the fate data
Seeing ho
Le sextidi 16 pluviôse, an CCXXIII, Clement Boesch a écrit :
> Linux is not only used by desktop. Debian (for example) might want to
> provide a ffmpeg-nox11 (just like vim-nox11),
Well, that means they have to put --disable-libxcb when building ffmpeg-nox
instead of having to out --enable-libxcb
Hi,
when running fate-hevc under valgrind + memory poisoning, I ran into
this issue when running with THREAD_TYPE=slice and THREADS>1.
pthread is not my forte at all, and I'm not sure I'm handling the
thread/... signalling correctly before freeing the leaking variables.
--
Christophe
From 1c400
2015-02-05 5:18 GMT+01:00 James Almer :
> Original x86 intrinsics code by Pierre-Edouard Lepere.
> Yasm port, refactoring and optimizations by James Almer.
OK.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
Hi,
2015-02-05 5:18 GMT+01:00 James Almer :
> Original x86 intrinsics code and initial yasm port by Pierre-Edouard Lepere.
> Refactoring and optimizations by James Almer.
No further comment from me.
--
Christophe
___
ffmpeg-devel mailing list
ffmpeg-d
On Wed, 4 Feb 2015 20:39:21 + (UTC)
Carl Eugen Hoyos wrote:
> Clément Bœsch pkh.me> writes:
>
> > This reverts commit 23ec8db8a07467a1fbef0c79f16b33040ca63c24.
> >
> > There is no reason to enable libxcb by
> > default. This is inconsistent with all the
> > other libs (we don't do it for
All the webm/vp9 files I have seen so far can have packets that contain
1 invisible and 1 visible frame. The vp9 parser separates them. Since
the invisible frame is always (?) the first sub-packet, the new packet
is assigned the PTS of the original packet, while the packet containing
the visible fr
Hi,
so I had a quick go at this but I'm still not sure on the preferred
way of reading this, should I read the atom directly and not put the
data in extradata?
Obviously this doesn't include fixing up the fate data
Thanks
Kevin
On Wed, Feb 4, 2015 at 11:51 AM, Kevin Wheatley
wrote:
> Hi,
>
>
Signed-off-by: Paul B Mahol
---
libavformat/rpl.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/rpl.c b/libavformat/rpl.c
index c1229e8..a05bff1 100644
--- a/libavformat/rpl.c
+++ b/libavformat/rpl.c
@@ -308,6 +308,8 @@ static int rpl_read_packet(AVFormatContext *s, AVPacket
Signed-off-by: Paul B Mahol
---
libavformat/thp.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/thp.c b/libavformat/thp.c
index 91fa90f..727fb50 100644
--- a/libavformat/thp.c
+++ b/libavformat/thp.c
@@ -176,6 +176,8 @@ static int thp_read_packet(AVFormatContext *s,
Hi,
2015-02-05 14:22 GMT+01:00 Mickaël Raulet :
> Michael,
>
> Please find some commits that can be cherry picked from
> https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch
>
> Optimized deblocking filter (8bits only)
> 1b9ee47d2f43b0a029a9468233626102eb1473b8
>
> Optimzed transform functions
As we can consider, we won't have 4k interlaced content, copying a field
into a frame should be ok. This is what has been done in this
implementation.
Commit hash from ffmpeg/openhevc:
6b93a7a175fb500d1f5d4d671b2fab73798ca7b6
Comments welcome!
Mickaël
___
Hi,
2015-02-05 11:13 GMT+01:00 Christophe Gisquet :
> 2015-02-05 10:13 GMT+01:00 Christophe Gisquet :
>> The patch breaks make fate-hevc THREADS=3, so needs more thought.
>
> Compilation issue, running make clean first passes "fate-hevc
> THREADS=3" and "fate-hevc THREADS=3 THREAD_TYPE=slice"
Ran
Michael,
Please find some commits that can be cherry picked from
https://github.com/OpenHEVC/FFmpeg/commits/ffmpeg_patch
Optimized deblocking filter (8bits only)
1b9ee47d2f43b0a029a9468233626102eb1473b8
Optimzed transform functions (4x4, 8x8, transform add 8bits only)
b153f55935969c794de4640f8d3
PPS_A_qualcomm_7, yes I have sometimes an issue with this sequence.
Patch LGTM otherwise, it does not change the behaviour of the previous
implementation.
Mickaël
2015-02-05 13:36 GMT+01:00 Christophe Gisquet
:
> Hi,
>
> 2015-02-05 13:17 GMT+01:00 Mickaël Raulet :
> > on one sequence? PPS7_xxx
Hi,
2015-02-05 13:17 GMT+01:00 Mickaël Raulet :
> on one sequence? PPS7_xxx ? Right?
I think we're not speaking about the same thing, maybe. I had an
issue, starting right from the first fate-hevc-conformance sequence,
where ffmpeg wouldn't even parse correctly the SPS.
Rebuilding from scratch f
on one sequence? PPS7_xxx ? Right?
Mickaël
2015-02-05 11:13 GMT+01:00 Christophe Gisquet
:
> 2015-02-05 10:13 GMT+01:00 Christophe Gisquet <
> christophe.gisq...@gmail.com>:
> > The patch breaks make fate-hevc THREADS=3, so needs more thought.
>
> Compilation issue, running make clean first pa
On date Wednesday 2015-02-04 16:18:32 +0100, Michael Niedermayer encoded:
> On Wed, Feb 04, 2015 at 12:26:15PM +0100, Stefano Sabatini wrote:
> > This requires the new sample file matrixbench_mpeg2.lq1.mpg.
> > ---
> > tests/fate/filter-video.mak | 3 +++
> > tests/ref/fate/filter-spp | 26
On date Wednesday 2015-02-04 16:22:02 +0100, Michael Niedermayer encoded:
> On Wed, Feb 04, 2015 at 12:52:05PM +0100, Stefano Sabatini wrote:
> > On date Wednesday 2015-02-04 12:26:15 +0100, Stefano Sabatini encoded:
> > > This requires the new sample file matrixbench_mpeg2.lq1.mpg.
> > > ---
> > >
On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded:
> On Wed, Feb 04, 2015 at 03:23:59PM +0100, Michael Niedermayer wrote:
> > On Wed, Feb 04, 2015 at 12:34:53PM +0100, Stefano Sabatini wrote:
> > > On date Monday 2015-02-02 23:22:09 +0100, Michael Niedermayer encoded:
> > > >
On date Thursday 2015-02-05 16:16:15 +0530, Eejya Singh encoded:
[...]
> From c0d6197f1936445a23b9eb726de24ed54551c675 Mon Sep 17 00:00:00 2001
> From: Eejya Singh
> Date: Wed, 28 Jan 2015 17:41:42 +0530
> Subject: [PATCH] Adding Force Style option in Subtitles Filter
Change the name of the patc
Hi,
I've updated the patch. Regarding the question, if the key=value has ","
then the token would contain only the value till the special character. The
code doesn't break but it won't work either.
On Wed, Feb 4, 2015 at 7:29 PM, Stefano Sabatini wrote:
> On date Wednesday 2015-02-04 01:30:09 +0
2015-02-05 10:13 GMT+01:00 Christophe Gisquet :
> The patch breaks make fate-hevc THREADS=3, so needs more thought.
Compilation issue, running make clean first passes "fate-hevc
THREADS=3" and "fate-hevc THREADS=3 THREAD_TYPE=slice"
--
Christophe
___
f
On 2/4/15, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes the crash from ticket #4296 for me.
>
> Please review, Carl Eugen
>
what is link to file?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-d
Hi,
2015-02-05 9:48 GMT+01:00 Mickaël Raulet :
> WPP try it out with thread_type=slice.
Does it mean these buffer should rather be per thread? If having 2 ctb
lines of buffer fixes this, does this mean having 2 instances of a
single line/column, one per ctb line number parity, would equally fix
t
2015-02-05 8:17 GMT+01:00 Christophe Gisquet :
> Hi,
>
> 2015-02-05 7:29 GMT+01:00 Christophe Gisquet >:
> > We were previously reference-counting the sao-buffer. Should we do
> > that for sao_pixel_buffer_[hv], then?
>
> Something like the attached patch.
>
> Note: I'm probably overallocating co
97 matches
Mail list logo
