On 01/23/2016 08:49 AM, Mats Peterson wrote:
On 01/23/2016 07:43 AM, Ganesh Ajjanagadde wrote:
I was also not too happy with the message in the cvslog at a glance,
but let it slide as FATE still passed on my configs. The problem is
that it is very sensitive to libm differences, e.g the quality o
On 01/23/2016 07:43 AM, Ganesh Ajjanagadde wrote:
I was also not too happy with the message in the cvslog at a glance,
but let it slide as FATE still passed on my configs. The problem is
that it is very sensitive to libm differences, e.g the quality of the
sqrt. For example, I wanted to experimen
On Sat, Jan 23, 2016 at 11:55 AM, Mats Peterson
wrote:
> +++ tests/data/fate/ffmpeg-filter_colorkey 2016-01-23
> 07:22:58.904430959 +0100
> @@ -1,16 +0,0 @@
> -#tb 0: 1/25
> -#tb 1: 1/48000
> -0, 0, 0,1, 622080, 0x4e30accb
> -1, 0, 0, 1152,
+++ tests/data/fate/ffmpeg-filter_colorkey 2016-01-23 07:22:58.904430959
+0100
@@ -1,16 +0,0 @@
-#tb 0: 1/25
-#tb 1: 1/48000
-0, 0, 0,1, 622080, 0x4e30accb
-1, 0, 0, 1152, 4608, 0x
-1, 1152, 1152, 1152, 4608, 0xbca2
On Sat, Jan 23, 2016 at 8:51 AM, Michael Niedermayer
wrote:
> On Fri, Jan 22, 2016 at 11:24:19PM +0530, Ganesh Ajjanagadde wrote:
>> Mostly based off the help text; slightly modified in some cases for
>> better clarity and correctness (based off code inspection).
>>
>> Signed-off-by: Ganesh Ajjana
On 1/21/2016 8:33 PM, Andreas Cadhalpun wrote:
> On 16.01.2016 02:29, Michael Niedermayer wrote:
>> On Mon, Dec 28, 2015 at 10:12:56PM +0100, Andreas Cadhalpun wrote:
>>> Previously the full source path was embedded inconsistently in the debug
>>> information between in-tree/out-of-tree builds.
>>>
On 1/21/2016 11:39 PM, Michael Niedermayer wrote:
> On Thu, Jan 21, 2016 at 10:45:55AM +, John Cox wrote:
>> Hi
>>
>> v2 of my hevc residual patch
>>
>> I've fixed the fate regression
>> I've split it into more pieces
>> Now uses ff_clz
>> Some reformating of function headers
>>
>> The patches
On 1/22/2016 9:34 PM, Hendrik Leppkes wrote:
> On Fri, Jan 22, 2016 at 12:33 AM, Andreas Cadhalpun
> wrote:
>> On 16.01.2016 02:29, Michael Niedermayer wrote:
>>> On Mon, Dec 28, 2015 at 10:12:56PM +0100, Andreas Cadhalpun wrote:
Previously the full source path was embedded inconsistently in
On Fri, Jan 22, 2016 at 11:24:19PM +0530, Ganesh Ajjanagadde wrote:
> Mostly based off the help text; slightly modified in some cases for
> better clarity and correctness (based off code inspection).
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> doc/ffmpeg.texi | 41 +
+1 from me as well
On 23 January 2016 at 01:03, James Almer wrote:
> On 1/22/2016 9:46 PM, Kieran Kunhya wrote:
> > $subj
>
> Missing minor version bump, and move the "it's unmaintained, has security
> issues etc" part outside of first line of the commit message, touching it
> a bit and make it
On 1/22/2016 7:34 PM, Michael Niedermayer wrote:
> On Fri, Jan 22, 2016 at 06:43:15PM -0300, James Almer wrote:
>> On 1/22/2016 6:40 PM, Michael Niedermayer wrote:
>>> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
Updated version of the patch. I choose to split it into even smaller
>
Hi,
On Fri, Jan 22, 2016 at 8:03 PM, James Almer wrote:
> On 1/22/2016 9:46 PM, Kieran Kunhya wrote:
> > $subj
>
> Missing minor version bump, and move the "it's unmaintained, has security
> issues etc" part outside of first line of the commit message, touching it
> a bit and make it more verbos
On 1/22/2016 9:46 PM, Kieran Kunhya wrote:
> $subj
Missing minor version bump, and move the "it's unmaintained, has security
issues etc" part outside of first line of the commit message, touching it
a bit and make it more verbose if possible.
That aside, +1 from me.
__
Also, the mkv adjustments are here:
https://mailarchive.ietf.org/arch/search/?email_list=cellar&gbt=1&index=sZyfPTM-QY69P-0omfOIiTN622o
On Fri, Jan 22, 2016 at 2:54 PM, Neil Birkbeck
wrote:
> Hmm. I don't have a good idea of how likely it is for this conversion to
> float (by dividing a constan
$subj
0001-avformat-Remove-support-for-libquvi-it-s-unmaintaine.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Jan 22, 2016 at 12:33 AM, Andreas Cadhalpun
wrote:
> On 16.01.2016 02:29, Michael Niedermayer wrote:
>> On Mon, Dec 28, 2015 at 10:12:56PM +0100, Andreas Cadhalpun wrote:
>>> Previously the full source path was embedded inconsistently in the debug
>>> information between in-tree/out-of-tre
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavformat/avformat.h |9 +
1 file changed, 9 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 4964263..d3b3bf2 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -78,
Hmm. I don't have a good idea of how likely it is for this conversion to
float (by dividing a constant) to not be bit-exact on different
architectures (compilers?) when there should not be any other math
transforming the metadata (other than the conversion back to the integer
coding for cases like
On Wed, Jan 20, 2016 at 03:39:09PM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/libquvi.c | 14 ++
> 1 file changed, 14 insertions(+)
applied
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BAD
On Wed, Jan 20, 2016 at 03:04:06PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/pngdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Rewriting code that is poorl
On Thu, Jan 21, 2016 at 12:17:48AM +0100, Andreas Cadhalpun wrote:
> On 20.01.2016 11:10, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavformat/concat.c |5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
>
On Thu, Jan 21, 2016 at 12:20:56AM +0100, Andreas Cadhalpun wrote:
> On 20.01.2016 16:49, Michael Niedermayer wrote:
> > From: Michael Niedermayer
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/demuxers.texi | 17 +
> > 1 file changed, 17 insertions(+)
> >
> > dif
On Fri, Jan 22, 2016 at 06:43:15PM -0300, James Almer wrote:
> On 1/22/2016 6:40 PM, Michael Niedermayer wrote:
> > On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
> >> Updated version of the patch. I choose to split it into even smaller
> >> commits to
> >> make reviewing easier; you may p
On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
> Updated version of the patch. I choose to split it into even smaller commits
> to
> make reviewing easier; you may prefer to squash it as needed.
>
> Changes since the first version:
>
> * Removed checkasm test for dcadsp
> * Removed FATE
On 1/22/2016 6:40 PM, Michael Niedermayer wrote:
> On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
>> Updated version of the patch. I choose to split it into even smaller commits
>> to
>> make reviewing easier; you may prefer to squash it as needed.
>>
>> Changes since the first version:
>>
On Thu, Jan 21, 2016 at 09:44:06PM +0300, foo86 wrote:
> Updated version of the patch. I choose to split it into even smaller commits
> to
> make reviewing easier; you may prefer to squash it as needed.
>
> Changes since the first version:
>
> * Removed checkasm test for dcadsp
> * Removed FATE te
On Fri, Jan 22, 2016 at 2:02 PM, Hendrik Leppkes wrote:
> Fixes artifacts in interlaced decoding on old Intel GPUs.
> ---
> libavcodec/dxva2_h264.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
> index 2f03114..61cce3a 1
On 1/22/2016 6:43 AM, Carl Eugen Hoyos wrote:
> foo86 gmail.com> writes:
>
>> +{ "core_only", "Decode core only without extensions",
>
> I am really all for this patch, but it would be much nicer
> to all users if this were "disable_xch" and "disable_xll"
> instead (or in addition).
I'm
On Fri, 22 Jan 2016 18:52:23 +0100, you wrote:
>Hi,
>
>2016-01-21 11:45 GMT+01:00 John Cox :
>> Hi
>>
>> v2 of my hevc residual patch
>
>I'll review the bit not related to significant coeffs first, because I
>think it is the most performance-sensitive. Also there are bits that
>could be moved to o
This commit moves the quantization matricies and a single define to the
shared header between the encoder and decoder. This is in preparation
for the following commit which will introduce the encoder.
Signed-off-by: Rostislav Pehlivanov
---
libavcodec/dirac.h| 78
Changes from the first vesion:
- Support 100% of the specifications.
- Enable 5 level transforms and custom quantization matrices.
- Raise the max slice size limit to 1024x1024 (works & supported)
- Change default settings to 5 level transforms with 128x64 slices
- Share tables
Mostly based off the help text; slightly modified in some cases for
better clarity and correctness (based off code inspection).
Signed-off-by: Ganesh Ajjanagadde
---
doc/ffmpeg.texi | 41 +
1 file changed, 41 insertions(+)
diff --git a/doc/ffmpeg.texi b/d
Hi
>Hi,
>
>2016-01-22 14:29 GMT+01:00 John Cox :
>>>This is a big slowdown on Win64 and UHD-bluray like sequences, but
>>>that can be switched off in that case.
>>
>> I'm a bit surprised that it generated a big slowdown - some cache must
>> be running just on the edge, but yes if you normally have
Hi,
2016-01-21 11:45 GMT+01:00 John Cox :
> Hi
>
> v2 of my hevc residual patch
I'll review the bit not related to significant coeffs first, because I
think it is the most performance-sensitive. Also there are bits that
could be moved to other patches, at least some are related to the
later bypas
Hi,
2016-01-22 14:29 GMT+01:00 John Cox :
>>This is a big slowdown on Win64 and UHD-bluray like sequences, but
>>that can be switched off in that case.
>
> I'm a bit surprised that it generated a big slowdown - some cache must
> be running just on the edge, but yes if you normally have hi-bitrate
Hi,
updated version attached.
From 4a4d760c78f16e8ddeab65a0fc6532059bf13750 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Sun, 17 Jan 2016 20:14:55 +0100
Subject: [PATCH] avfilter/vf_crop: make it possible to use frame metadata when
cropping
Signed-off-by: Paul B Mahol
---
doc/filters.tex
On 01/22/2016 03:44 PM, Mats Peterson wrote:
You'll have to excuse me, Michael, but the changes I've made, including
the line alignment changes, are dependent on each other, and not easy or
very logical to split. Here's a new version that displays the Matrix
video correctly.
Mats
Just want to
You'll have to excuse me, Michael, but the changes I've made, including
the line alignment changes, are dependent on each other, and not easy or
very logical to split. Here's a new version that displays the Matrix
video correctly.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 0
On Tue, Jan 19, 2016 at 01:22:13PM -0500, Perette Barella wrote:
> > tabs aren’t allowed in ffmpeg git (except makefiles)
> fixed
>
> > SO_RCVBUF occurs twice, is that intended ?
> Not intended, fixed, thanks.
>
> > cleaning up the indention is welcome, but please in a seperate patch
> Removed fr
On Fri, Jan 22, 2016 at 4:45 PM, Paul B Mahol wrote:
> On 1/22/16, Ganesh Ajjanagadde wrote:
>> On Sat, Jan 16, 2016 at 12:31 AM, Ganesh Ajjanagadde
>> wrote:
>>> Further speedups possible by getting rid of exp2f...
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavcodec/wmadec.c | 5
On Fri, Jan 22, 2016 at 5:28 AM, Michael Niedermayer
wrote:
> On Thu, Jan 21, 2016 at 10:03:16AM +0530, Ganesh Ajjanagadde wrote:
>> May help to prevent incidents like 19e456d48c90a1e3ceeb9e6241383384cc73dfdf.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/wma.h | 2 ++
>> 1 file c
On Fri, 22 Jan 2016 14:42:27 +0100, you wrote:
> [snip]
>> >fate-hevc passes with patch 1-5, so the issue is likely in the last
>> >
>> >[...]
>>
>> Yup - bug in the arm update_rice (again - sorry). Now passes fate on
>> ARM too (now I've learnt how to run fate on my Pi in a finite time).
>>
>>
On Fri, Jan 22, 2016 at 03:53:10AM +0100, James Darnley wrote:
> Someone on IRC asked for a scale that would fit in a given box. This is the
> answer. I couldn't see it in the existing examples so I thought I would add
> it.
> ---
> doc/filters.texi | 6 ++
> 1 file changed, 6 insertions(+)
On Fri, Jan 22, 2016 at 12:32:00PM +, John Cox wrote:
> On Fri, 22 Jan 2016 01:57:58 +0100, you wrote:
>
> >On Fri, Jan 22, 2016 at 01:41:11AM +0100, Michael Niedermayer wrote:
> >> On Thu, Jan 21, 2016 at 10:45:55AM +, John Cox wrote:
> >> > Hi
> >> >
> >> > v2 of my hevc residual patch
On Fri, 22 Jan 2016 12:18:29 +0100, you wrote:
>Hi,
>
>2016-01-20 15:27 GMT+01:00 John Cox :
>> The by22 code gained me an overall factor of two in the abs level decode
>> - the gains do depend a lot on the quantity of residual - you gain a lot
>> more on I-frames than you do otherwise as they ten
Fixes artifacts in interlaced decoding on old Intel GPUs.
---
libavcodec/dxva2_h264.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dxva2_h264.c b/libavcodec/dxva2_h264.c
index 2f03114..61cce3a 100644
--- a/libavcodec/dxva2_h264.c
+++ b/libavcodec/dxva2_h264.c
@@ -
On 01/22/2016 12:45 PM, Michael Niedermayer wrote:
this patch breaks encoding 1bpp raw video
./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt monow -vframes 10 -vcodec rawvideo
testw.avi
./ffplay testw.avi
also the change to the line alignment belongs in a seperate
patch.
It doesn't break the enc
On 01/22/2016 01:26 PM, Mats Peterson wrote:
Yes, thank you for the reminder. If I'm not completely out in the blue,
it seems as if the lines in the file produced by the above command are
aligned on 2-byte boundaries, while in other cases they are aligned on
4-byte boundaries. Why this discrepanc
On Fri, 22 Jan 2016 01:57:58 +0100, you wrote:
>On Fri, Jan 22, 2016 at 01:41:11AM +0100, Michael Niedermayer wrote:
>> On Thu, Jan 21, 2016 at 10:45:55AM +, John Cox wrote:
>> > Hi
>> >
>> > v2 of my hevc residual patch
>> >
>> > I've fixed the fate regression
>> > I've split it into more p
On 01/22/2016 01:26 PM, Mats Peterson wrote:
Yes, thank you for the reminder. If I'm not completely out in the blue,
it seems as if the lines in the file produced by the above command are
aligned on 2-byte boundaries, while in other cases they are aligned on
4-byte boundaries. Why this discrepanc
On 01/22/2016 12:45 PM, Michael Niedermayer wrote:
this patch breaks encoding 1bpp raw video
./ffmpeg -i matrixbench_mpeg2.mpg -pix_fmt monow -vframes 10 -vcodec rawvideo
testw.avi
./ffplay testw.avi
also the change to the line alignment belongs in a seperate
patch.
Yes, thank you for the r
On Wed, Jan 20, 2016 at 12:41:22PM +0100, Mats Peterson wrote:
> I don't know about this one, since it adds some calculations inside
> the loop, but it limits the line alignment to 16 bytes instead of 32
> bytes as before. Less overhead.
this patch breaks encoding 1bpp raw video
./ffmpeg -i matri
On 1/22/16, Ganesh Ajjanagadde wrote:
> On Sat, Jan 16, 2016 at 12:31 AM, Ganesh Ajjanagadde
> wrote:
>> Further speedups possible by getting rid of exp2f...
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavcodec/wmadec.c | 5 +++--
>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>
>>
Hi,
2016-01-20 15:27 GMT+01:00 John Cox :
> The by22 code gained me an overall factor of two in the abs level decode
> - the gains do depend a lot on the quantity of residual - you gain a lot
> more on I-frames than you do otherwise as they tend to have much longer
> residuals. The higher the bit
>On Fri, Jan 22, 2016 at 01:41:11AM +0100, Michael Niedermayer wrote:
>> On Thu, Jan 21, 2016 at 10:45:55AM +, John Cox wrote:
>> > Hi
>> >
>> > v2 of my hevc residual patch
>> >
>> > I've fixed the fate regression
>> > I've split it into more pieces
>> > Now uses ff_clz
>> > Some reformating
foo86 gmail.com> writes:
> +{ "core_only", "Decode core only without extensions",
I am really all for this patch, but it would be much nicer
to all users if this were "disable_xch" and "disable_xll"
instead (or in addition).
Thank you, Carl Eugen
On Thu, 21 Jan 2016 15:57:38 -0800
Neil Birkbeck wrote:
> Thanks for the quick review, Michael.
>
> The display primaries are encoded as integers (rational with fixed
> denominator, I guess) in h265 and HDMI InfoFrames (but in mkv extensions,
> they will be floats). Float is sufficient to repres
On Fri, 22 Jan 2016 00:14:15 +0100
Andreas Cadhalpun wrote:
> On 21.01.2016 23:56, Hendrik Leppkes wrote:
> > On Thu, Jan 21, 2016 at 8:36 PM, Andreas Cadhalpun
> > wrote:
> >> On 21.01.2016 02:10, Hendrik Leppkes wrote:
> >>> Looks like they added extensive locking around everything to prev
58 matches
Mail list logo
