---
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
---
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
- 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
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
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
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 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:
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
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
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
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
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 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 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
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
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
> +
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 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
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
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
---
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/
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
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
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
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
__
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 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
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
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.
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
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
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
---
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
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 |
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
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
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
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 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
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
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
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
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
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 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
47 matches
Mail list logo
