On 16.04.2016 23:25, Michael Niedermayer wrote:
> On Fri, Apr 15, 2016 at 09:49:46AM +0200, Tobias Rapp wrote:
>> Attached an updated patch, rebased onto current git master.
>>
>> The sample file for the FATE test can be found at:
>> https://cerebrum.noa-archive.com/noacloud/public.php?service=file
Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.
Signed-off-by: Isamu Mogi
---
libavutil/pixdesc.c | 2 +-
libavutil/pixfmt.h | 2 +-
tests/ref/fate/filter-pixdesc-yuv410p| 2 +-
tests/ref/fate/filter-pixfmts-copy | 2 +-
test
On Mon, Apr 18, 2016 at 09:49:40AM +, Isamu Mogi wrote:
> Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.
no
but why was the first thought i had "wikipedia" and why was i correct
"4:1:0 This ratio is possible, and some codecs support it, but it is not widely
used. This ratio
On Mon, Apr 18, 2016 at 12:07 PM, Michael Niedermayer
wrote:
> On Mon, Apr 18, 2016 at 09:49:40AM +, Isamu Mogi wrote:
>> Chroma height for yuv410p is luma/2. Same as yuv440p and yuv420p.
>
> no
> but why was the first thought i had "wikipedia" and why was i correct
> "4:1:0 This ratio is poss
Dmitriy Kuminov wrote:
> On 2016-04-17 05:21:31 +, KO Myung-Hun said:
>
>> Even if it's a bug of ramfs.ifs, its bug should be considered when using
>> ln -s.
>
> Yes, and in this particular case configure handles it safely. It results
> into a false fallback though because the symlink dir c
2016-04-14 7:56 GMT+02:00 Christophe Gisquet :
> As Hendrik said, please move it to LLAudDSPContext.
So this, and some of my other comments, are already addressed by the
final patch which was pushed before my review, making it somewhat
moot.
Could you please send a message next time indicating it
On Mon, Apr 18, 2016 at 09:38:13AM +0200, Tobias Rapp wrote:
> On 16.04.2016 23:25, Michael Niedermayer wrote:
> > On Fri, Apr 15, 2016 at 09:49:46AM +0200, Tobias Rapp wrote:
> >> Attached an updated patch, rebased onto current git master.
> >>
> >> The sample file for the FATE test can be found a
Hi,
I’ll try to clear some things up. Here it goes:
1. About the copyright thing, kierank didn’t say to add him to copyright
section and I’m not sure whether its his code, so I left it as it is.
2. I got instructions not to hook this up to build system just yet, I think one
of the reasons is th
On 2016-04-18 11:52:15 +, KO Myung-Hun said:
Strange conclusion. Anyway not important.
In Dave's case the symlink functionality check fails because it is
performed in TMPDIR which is located on ramfs.ifs (which fails to use
symlinks). But I believe his real build directory is not on ramf
I think only the 2 first patches are needed, but I prefer the code
from the 3rd+4th patches. Overall, it's still not the nicest code, and
valgrind-proofing the patchset is needed (not possible atm for me).
The SSE4 implementation is not worthwhile in my opinion.
Christophe Gisquet (6):
fate: wm
Cosmetics before macroing it and another function.
---
libavcodec/wmalosslessdec.c | 94 ++---
1 file changed, 47 insertions(+), 47 deletions(-)
diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 3885dc1..77017ff 100644
--- a/libav
This is done by actually handling the cascaded LMS data as if it
were int16_t, thus requiring switching at various locations the
computations.
---
libavcodec/wmalosslessdec.c | 61 +
1 file changed, 61 insertions(+)
diff --git a/libavcodec/wmalosslessde
The unique user so far is wmalossless 24bits. The few samples tested show an
order of 8, so more unrolling or an avx2 version do not make sense.
Timings: 72 -> 49 cycles
---
libavcodec/x86/lossless_audiodsp.asm| 38 +
libavcodec/x86/lossless_audiodsp_init.c |
---
tests/fate/lossless-audio.mak | 4 +++-
tests/ref/fate/lossless-wma24 | 1 +
2 files changed, 4 insertions(+), 1 deletion(-)
create mode 100644 tests/ref/fate/lossless-wma24
diff --git a/tests/fate/lossless-audio.mak b/tests/fate/lossless-audio.mak
index 58641ab..ccc4d00 100644
--- a/tests/f
Code size increase is minimal.
---
libavcodec/wmalosslessdec.c | 140 ++--
1 file changed, 57 insertions(+), 83 deletions(-)
diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 77017ff..27510d4 100644
--- a/libavcodec/wmalosslessdec
The loops are guaranteed to be at least multiples of 8, so this
unrolling is safe but allows exploiting execution ports.
For int32 version: 72 -> 57c.
---
libavcodec/lossless_audiodsp.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/libavcodec/lossless_audiodsp.c
Hi there,
Here I made a test for mss1 codec. The sample file for the FATE test can be
found at:
https://drive.google.com/file/d/0ByhGgswO8BQcRHJFU0VRWV9aSU0/view?usp=sharingFrom 652d52f6d52a38ef25fa6d4446afd3f96b2d0280 Mon Sep 17 00:00:00 2001
From: Petru Rares Sincraian
Date: Mon, 18 Apr 2016
On Samstag, 16. April 2016 05:16:04 CEST Michael Niedermayer wrote:
> On Sat, Apr 16, 2016 at 12:07:27AM +0200, Gerion Entrup wrote:
> > On Donnerstag, 14. April 2016 19:52:46 CEST Michael Niedermayer wrote:
> > > On Thu, Apr 14, 2016 at 07:06:29PM +0200, Gerion Entrup wrote:
> > > > On Montag, 11.
On Mon, Apr 18, 2016 at 03:11:45PM +, Petru Rares Sincraian wrote:
> Hi there,
>
> Here I made a test for mss1 codec. The sample file for the FATE test can be
> found at:
> https://drive.google.com/file/d/0ByhGgswO8BQcRHJFU0VRWV9aSU0/view?usp=sharing
> fate/microsoft.mak |6
> ref/fat
2016-04-18 15:07 GMT+02:00 Christophe Gisquet :
> +fate-lossless-wma24: CMD = md5 -i
> $(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames
> 209
Btw, this is the regular luckynight whose samples have been shifted
into 24 bits. Another type of bitdepth increase would be ni
Dana 18. 4. 2016. 18:17 osoba "Christophe Gisquet" <
christophe.gisq...@gmail.com> napisala je:
>
> 2016-04-18 15:07 GMT+02:00 Christophe Gisquet <
christophe.gisq...@gmail.com>:
> > +fate-lossless-wma24: CMD = md5 -i
$(TARGET_SAMPLES)/lossless-audio/luckynight-partial-24.wma -f s24le -frames
209
>
2016-04-18 18:39 GMT+02:00 Paul B Mahol :
> Better to have real 24bit content.
Yeah, my point, but I'm not sure we'll get one redistribuable in fate,
eg by pinging people from the various tickets.
And when would we decide this is better than nothing?
--
Christophe
__
Hi there,
Here is a patch for 012v codec. You can download the sample file here:
https://drive.google.com/open?id=0ByhGgswO8BQcSDc0S3RONHFuN0k
It is supposed to be in $(TARGET_SAMPLES)/012v/sample.avi.
md5: e07bb155180c0140960ea4deb6cdf6b6From 418b709c534628781f24f25055c4c0e9c36ad6d1 Mon Sep 17
On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
> The loops are guaranteed to be at least multiples of 8, so this
> unrolling is safe but allows exploiting execution ports.
>
> For int32 version: 72 -> 57c.
What compiler are you using, and what cpu at configure time?
We're currently enabling tr
Those instructions are not commutative since they only change the first
element in the vector and leave the rest unmodified.
---
libavutil/x86/x86inc.asm | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86i
From: Anton Mitrofanov
---
libavutil/x86/x86inc.asm | 44
1 file changed, 24 insertions(+), 20 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm
index 22608ea..a53477b 100644
--- a/libavutil/x86/x86inc.asm
+++ b/libavutil/
From: Anton Mitrofanov
The yasm/nasm preprocessor only checks the first token, which means that
parameters such as `dword [rax]` are treated as identifiers, which is
generally not what we want.
---
libavutil/x86/x86inc.asm | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/l
Anton Mitrofanov (3):
x86inc: Fix AVX emulation of some instructions
x86inc: Improve handling of %ifid with multi-token parameters
x86inc: Enable AVX emulation in additional cases
Henrik Gramner (1):
x86inc: Fix AVX emulation of scalar float instructions
libavutil/x86/x86inc.asm | 95 +++
From: Anton Mitrofanov
Allows emulation to work when dst is equal to src2 as long as the
instruction is commutative, e.g. `addps m0, m1, m0`.
---
libavutil/x86/x86inc.asm | 21 +
1 file changed, 13 insertions(+), 8 deletions(-)
diff --git a/libavutil/x86/x86inc.asm b/libavut
On 4/18/2016 1:48 PM, Christophe Gisquet wrote:
> 2016-04-18 18:39 GMT+02:00 Paul B Mahol :
>> Better to have real 24bit content.
>
> Yeah, my point, but I'm not sure we'll get one redistribuable in fate,
> eg by pinging people from the various tickets.
>
> And when would we decide this is better
2016-04-18 19:15 GMT+02:00 James Almer :
> On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
>> The loops are guaranteed to be at least multiples of 8, so this
>> unrolling is safe but allows exploiting execution ports.
>>
>> For int32 version: 72 -> 57c.
>
> What compiler are you using, and what cp
On Mon, Apr 18, 2016 at 03:07:27PM +0200, Christophe Gisquet wrote:
> This is done by actually handling the cascaded LMS data as if it
> were int16_t, thus requiring switching at various locations the
> computations.
> ---
> libavcodec/wmalosslessdec.c | 61
> +
Hi,
2016-04-18 20:09 GMT+02:00 Michael Niedermayer :
> On Mon, Apr 18, 2016 at 03:07:27PM +0200, Christophe Gisquet wrote:
>> This is done by actually handling the cascaded LMS data as if it
>> were int16_t, thus requiring switching at various locations the
>> computations.
>> ---
>> libavcodec/w
Hi all
On Sun, Feb 14, 2016 at 6:11 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> control codes in a cc stream can be repeated, and must be ignored.
> however, repeated characters must not be ignored. the code attempted to
> wipe prev_cmd in handle_char to allow repeated characters to be
> proce
On Mon, Apr 18, 2016 at 03:07:30PM +0200, Christophe Gisquet wrote:
> The unique user so far is wmalossless 24bits. The few samples tested show an
> order of 8, so more unrolling or an avx2 version do not make sense.
>
> Timings: 72 -> 49 cycles
> ---
> libavcodec/x86/lossless_audiodsp.asm| 3
Hi,
2016-04-18 19:11 GMT+02:00 James Almer :
> No way to create one using existing 24bit audio currently available in fate
> or any redistributable 24 audio out there?
> There are some dts-ma and truehd multichannel samples that are not sine waves.
You're right. Just did that, except the encoder
On Mon, Apr 18, 2016 at 05:05:01PM +, Petru Rares Sincraian wrote:
>
> Hi there,
>
> Here is a patch for 012v codec. You can download the sample file here:
> https://drive.google.com/open?id=0ByhGgswO8BQcSDc0S3RONHFuN0k
> It is supposed to be in $(TARGET_SAMPLES)/012v/sample.avi.
>
> md5: e
2016-04-18 22:22 GMT+02:00 Christophe Gisquet :
> 2016-04-18 19:11 GMT+02:00 James Almer :
>> No way to create one using existing 24bit audio currently available in fate
>> or any redistributable 24 audio out there?
>> There are some dts-ma and truehd multichannel samples that are not sine
>> wave
2016-04-18 21:18 GMT+02:00 Michael Niedermayer :
> this breaks (only noise)
> \[CCCP\]_Mega_Weird_Audio_Test.mkv track 23
Worthwhile sample.
I rewrote the patch to reduce code duplication, and I fixed the issue
(misread a shift).
--
Christophe
From a0d4a96c032d73bc0e34fec320497aefafba3c28 Mon S
On 4/18/2016 6:23 PM, Christophe Gisquet wrote:
> 2016-04-18 22:22 GMT+02:00 Christophe Gisquet :
>> 2016-04-18 19:11 GMT+02:00 James Almer :
>>> No way to create one using existing 24bit audio currently available in fate
>>> or any redistributable 24 audio out there?
>>> There are some dts-ma and
On 4/18/2016 2:52 PM, Christophe Gisquet wrote:
> 2016-04-18 19:15 GMT+02:00 James Almer :
>> On 4/18/2016 10:07 AM, Christophe Gisquet wrote:
>>> The loops are guaranteed to be at least multiples of 8, so this
>>> unrolling is safe but allows exploiting execution ports.
>>>
>>> For int32 version:
Please send me the sample and I will try to fix the issue.
Aman
On Mon, Apr 18, 2016 at 1:22 PM Thierry Foucu wrote:
> Hi all
>
> On Sun, Feb 14, 2016 at 6:11 PM, Aman Gupta wrote:
>
>> From: Aman Gupta
>>
>> control codes in a cc stream can be repeated, and must be ignored.
>> however, repeat
On Mon, Apr 18, 2016 at 07:03:40PM +0200, Henrik Gramner wrote:
> Anton Mitrofanov (3):
> x86inc: Fix AVX emulation of some instructions
> x86inc: Improve handling of %ifid with multi-token parameters
> x86inc: Enable AVX emulation in additional cases
>
> Henrik Gramner (1):
> x86inc: Fix
On 04/16/16 11:00 AM, Dmitriy Kuminov wrote:
On 2016-04-16 17:24:12 +, Dave Yeo said:
Actually I now get this at the beginning of the configure run, using a
ramfs.ifs volume for $TMPDIR,
[K:\usr\local\src\ffmpeg.obj]sh ../ffmpeg/configure --enable-gpl
--disable-doc --samples=/usr/local/sha
- Use the highest resolution available, rather than the first listed
- Use the first listed (often the only) frame rate, rather than forcing NTSC
- Use the first listed pixel format, rather than forcing yuv420p
- Don't log when automatically overriding the defaults
This allows the defaults to give
---
libavutil/opt.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/libavutil/opt.c b/libavutil/opt.c
index eae4f75..83093e0 100644
--- a/libavutil/opt.c
+++ b/libavutil/opt.c
@@ -275,11 +275,12 @@ static int set_string_image_size(void *obj, const
AVOption *o, const c
---
libavdevice/avfoundation.m | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavdevice/avfoundation.m b/libavdevice/avfoundation.m
index 763e675..8132278 100644
--- a/libavdevice/avfoundation.m
+++ b/libavdevice/avfoundation.m
@@ -560,11 +560,11
47 matches
Mail list logo
