On Thu, Mar 10, 2016 at 12:49 AM, Ganesh Ajjanagadde wrote:
> There is no reason for computing cbrtf at runtime; we have a table for
> this.
>
> Cruft needed due to the build system, the people who still like using
> hardcoded tables and need for single cbrt_tab across the code.
>
The build-syste
On 10.03.2016, at 03:06, Ganesh Ajjanagadde wrote:
> On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
> wrote:
>> On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
>>
>>> +nzl += expf(logf(s / ethresh) * nzslope);
>>
>> Shouldn't log2f/exp2f be faster?
>> log2f at least h
Respect "ignore_extradata", for what it's worth.
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 8bdcc615499872b034c9b17a38d296aa74e31d09 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Thu, 10 Mar 2016 08:31:24 +0100
Subject: [PATCH 2/3 v3] lavf/riffenc: Improve spec compliance
HuffYUV uses its own weird variant of the BITMAPINFOHEADER that *does*
include the Huffman table size in biSize. That's the only exception as
far as I know.
http://wiki.multimedia.cx/index.php?title=HuffYUV
Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d6cb26096e08e43a686ea67fd
On 03/09/2016 11:39 PM, Mats Peterson wrote:
Try playing the resulting test.avi file from the command line below with
Windows Media Player, with and without patch 2/3 and 3/3 (you'll need
patch 1/3 in order to get the xxpc chunks properly in the demuxer).
ffmpeg -i TOON.AVI -c:v copy -c:a copy t
On Wed, Jan 20, 2016 at 05:02:15PM +0100, Nicolas George wrote:
> Le decadi 30 nivôse, an CCXXIV, Michael Niedermayer a écrit :
> > This is safer, as a selected demuxer could still mean that it was
> > auto-detected
> > by a user application
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> >
On Wed, Mar 9, 2016 at 2:16 AM, Reimar Döffinger
wrote:
> On 08.03.2016, at 04:48, Ganesh Ajjanagadde wrote:
>
>> +nzl += expf(logf(s / ethresh) * nzslope);
>
> Shouldn't log2f/exp2f be faster?
> log2f at least has CPU support on x86 AFAICT.
I had tested this, and no, though
On Wed, Mar 9, 2016 at 1:32 PM, Reimar Döffinger
wrote:
> On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
>> On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
>> > Yields 2x improvement in function performance, and boosts aac encoding
>> > speed by ~ 4% overa
On Wed, Mar 9, 2016 at 5:09 PM, Moritz Barsnick wrote:
> On Tue, Mar 08, 2016 at 22:16:50 -0500, Ganesh Ajjanagadde wrote:
>> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system 105%
>> cpu 4.970 total
>
> Just wondering: Is this the sin.flac from
> ffmpeg -f lavfi -i aevalsrc=
From: Sergey Volk
Date: Wed, 9 Mar 2016 14:34:19 -0800
Subject: [PATCH] Change AVStream::id to int64_t in the next version bump
I have also bumped the major version to 58 locally in version.h, and
re-ran make with the stream id being int64_t and fixed all new
warnings that showed up (only saw new
There is no reason for computing cbrtf at runtime; we have a table for
this.
Cruft needed due to the build system, the people who still like using
hardcoded tables and need for single cbrt_tab across the code.
Yields non-negligible speedup (Haswell+GCC, -march=native)
before:
ffmpeg -i sin.flac -
Ok, so then I guess we'll need to update AVStream::id to be 64-bit
first, and then I'll make the necessary changes in matroskadec.
I've prepared a patch to bump AVStream::id to be int64_t in the next
major version, I'll send it out shortly. After I rebuilt ffmpeg
with AVStream::id being int64_t I g
On Wed, Mar 09, 2016 at 11:27:27PM +0100, Mats Peterson wrote:
> Interim fix of the parsing of idx1 indexes with 'xxpc' (palette
> change) entries.
>
> Implementation of 'xxpc' index entry storage for seeking will come
> in the future (provided I can manage it).
>
> Test file TOON.AVI from King's
Here's an interesting one. Windows Media Player won't make any palette
changes without the xxpc chunks beeing indexed.
Fixing the logic for reading and seeking with xxpc chunks in the demuxer
is a future task. Now the muxing of video with xxpc chunks works
properly at least.
Try playing the
From the Microsoft documentation for BITMAPINFOHEADER at
https://msdn.microsoft.com/en-us/library/windows/desktop/dd318229%28v=vs.85%29.aspx:
"biSize: Specifies the number of bytes required by the structure. This
value does not include the size of the color table or the size of the
color masks,
On 03/09/2016 11:26 PM, Mats Peterson wrote:
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc'
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "strea
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "strea
On Tue, Mar 08, 2016 at 22:16:50 -0500, Ganesh Ajjanagadde wrote:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system 105%
> cpu 4.970 total
Just wondering: Is this the sin.flac from
ffmpeg -f lavfi -i aevalsrc="sin(440*2*PI*t):s=48000" -t 300 -y sin.flac
??
Is a sinusoidal
On Wed, 9 Mar 2016, wm4 wrote:
On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
Marton Balint wrote:
On Tue, 8 Mar 2016, Hendrik Leppkes wrote:
> On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint wrote:
>>
>> On Tue, 8 Mar 2016, wm4 wrote:
>>
>>> On Tue, 8 Mar 2016 21:29:52 +0100
>>> Marton Balint
On Wed, Mar 09, 2016 at 09:56:00PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> > On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > > On Tue, M
On Wed, Mar 09, 2016 at 09:04:29PM +0100, Michael Niedermayer wrote:
> On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> > On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > > Yields
On Wed, Mar 09, 2016 at 07:32:29PM +0100, Reimar Döffinger wrote:
> On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > > Yields 2x improvement in function performance, and boosts aac encoding
> > > speed b
On Wed, Mar 9, 2016 at 3:52 PM, Reimar Döffinger
wrote:
> On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
>> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde
>> wrote:
>> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
>> > wrote:
>> > No idea about this. However, here is s
On Wed, 9 Mar 2016 17:48:41 +, Martín Capón Borrego wrote:
> Hi all:
>
> I have a video .mp4 in my local pc with Windows 7. When I upload it
> via FTP and go to see it, I reliaze this suffers of loss of quality.
> Is it normal? How to do to see the uploaded video to local?
> TIA
There ar
On Wed, 2016-03-09 at 15:21 +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5316 here.
> I unfortunately have no idea what the hunk in mxf_read_header()
> does, decoding works fine without it.
Strange. Why was mxf_canopus_essence_element_key added then? Pushing
without it i
On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> On Tue, Mar 8, 2016 at 5:33 PM, James Almer wrote:
>
> > On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote:
> > > ---
> > > libavutil/Makefile | 1 +
> > > libavutil/hash.c | 42 +
On Wed, Feb 24, 2016 at 04:38:22PM +, Vicente Olivert Riera wrote:
> Understanding the mips32r6 and mips64r6 ISAs in the configure script is
> not enough. In order to have full support for MIPS R6 in FFmpeg we need
> to be able to build it, and for that we need to make sure we don't use
> incom
On Wed, Mar 09, 2016 at 10:27:29AM -0800, NagaChaitanya Vellanki wrote:
> Ping Michael to review to patch.
patch applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things microsoft did are stupid, but not doing something just because
microsoft
On Wed, Mar 09, 2016 at 02:20:35PM -0300, Claudio Freire wrote:
> On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde
> wrote:
> > On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
> > wrote:
> > No idea about this. However, here is some info.
> > The regression in speed dates to: 01ecb7172b684f1c
On Wed, Mar 09, 2016 at 08:52:29AM +0800, Peng Poney wrote:
> Hi
>
>
>
> We need to use FFMpeg in Chromium and we do compile
> option:”proprietary_codecs=1”. According to the license term, we didn’t
> use GPL and NON_Free option when we compile our software. Does it mean we
> can use our softw
On Wed, Mar 09, 2016 at 01:13:58PM +0100, Michael Niedermayer wrote:
> On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> > Yields 2x improvement in function performance, and boosts aac encoding
> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> > af
Nicolas George george at nsup.org wrote:
>> libavformat/udp.c | 133
>> --
>> 1 file changed, 129 insertions(+), 4 deletions(-)
>Missing documentation update.
fixed.
>> -while(1) {
>> +for(;;) {
>Stray change.
Portability. You don't
Hi
We need to use FFMpeg in Chromium and we do compile
option:”proprietary_codecs=1”. According to the license term, we didn’t
use GPL and NON_Free option when we compile our software. Does it mean we
can use our software fro commercial purpose?
Thanks,
Poney
__
Ping Michael to review to patch.
Thank you,
Naga
On Tue, Mar 8, 2016 at 5:33 PM, James Almer wrote:
> On 3/8/2016 2:21 AM, NagaChaitanya Vellanki wrote:
> > ---
> > libavutil/Makefile | 1 +
> > libavutil/hash.c | 42 ++
> > tests/fate/li
Hi all:
I have a video .mp4 in my local pc with Windows 7. When I upload it via FTP
and go to see it, I reliaze this suffers of loss of quality. Is
it normal? How to do to see the uploaded video to local?
TIA
___
Hi:
I use ffmpeg in my asp.net pages
I do
Dim strfichero As String
Dim mh As New MediaHandler
strfichero = Mid(fichero, InStrRev(fichero, "\") + 1)
mh.FFMPEGPath = Server.MapPath("Comun/Ffmpeg/ffmpeg.exe")
mh.InputPath = Left(fichero, Len(fich
On Mon, Feb 29, 2016 at 11:30 PM, Ganesh Ajjanagadde wrote:
> On Mon, Feb 22, 2016 at 11:34 PM, Andrey Utkin
> wrote:
>> Hi!
>> I am aware of news that AAC encoder got stable status recently.
>>
>> But you could find this interesting. We've got an ffmpeg build from
>> October 2014, and it perform
On Wed, Mar 9, 2016 at 4:35 PM, Michael Niedermayer
wrote:
> On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
>> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
>> wrote:
>> > document the issue with av_tempfile()
>> >
>> > Signed-off-by: Michael Niedermayer
>> > ---
>> > li
On Wed, Mar 09, 2016 at 04:27:12PM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
> wrote:
> > document the issue with av_tempfile()
> >
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/libxvid.h |2 --
> > libavutil/file.c | 48 ++---
On Wed, Mar 9, 2016 at 3:37 PM, Michael Niedermayer
wrote:
> document the issue with av_tempfile()
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/libxvid.h |2 --
> libavutil/file.c | 48 ++--
> libavutil/file.h |1 +
> libavuti
On Wed, Mar 09, 2016 at 02:43:22PM +, Carl Eugen Hoyos wrote:
> Michael Niedermayer niedermayer.cc> writes:
>
> > Should fix xvid/cache on windows with --enable-shared
>
> Is this related to ticket #4780?
> --enabled-shared is not mentioned there.
i dont know
[...]
--
Michael GnuPG fi
I wont qualify for GSoC because i am full time employed and a part time
student.
Thank you,
Naga
On Sun, Mar 6, 2016 at 3:26 PM, Michael Niedermayer
wrote:
> On Sun, Mar 06, 2016 at 11:27:59AM -0800, NagaChaitanya Vellanki wrote:
> > Please review the patch.
> >
> > NagaChaitanya Vellanki (1):
Signed-off-by: Michael Niedermayer
---
Makefile |1 +
file_open.c |1 +
tests/ref/fate/source |1 +
3 files changed, 3 insertions(+)
create mode 100644 file_open.c
diff --git a/Makefile b/Makefile
index 87a9869..0193960 100644
--- a/Makefile
+++ b/Makefile
@@
Michael Niedermayer niedermayer.cc> writes:
> Should fix xvid/cache on windows with --enable-shared
Is this related to ticket #4780?
--enabled-shared is not mentioned there.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmp
Should fix xvid/cache on windows with --enable-shared
Signed-off-by: Michael Niedermayer
---
libavcodec/libxvid.c|2 +-
libavcodec/libxvid_rc.c |4 ++--
libavformat/cache.c |4 ++--
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/libxvid.c b/libavcod
document the issue with av_tempfile()
Signed-off-by: Michael Niedermayer
---
libavcodec/libxvid.h |2 --
libavutil/file.c | 48 ++--
libavutil/file.h |1 +
libavutil/file_open.c | 59 +
lib
Hi!
Attached patch fixes ticket #5316 here.
I unfortunately have no idea what the hunk in mxf_read_header()
does, decoding works fine without it.
Please comment, Carl Eugen
diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index f4222fc..3c43968 100644
--- a/libavformat/mxfdec.c
+++ b/lib
Michael Niedermayer niedermayer.cc> writes:
> > mpeg.c |2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 441c00cda76c5f59b560517115ad1677ab8061bd patchmpegmlp.diff
> > diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
> > index 787d5f0..2f48459 100644
>
> if that works and no
Michael Niedermayer niedermayer.cc> writes:
> > mjpegdec.c |4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> > 88ce4aaf4530ae0442cb76b6659bec1332c9e5a8 patchmultiscopesar.diff
> > diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
>
> probably ok
Patch applied.
Thank
Ronald S. Bultje gmail.com> writes:
> > > That fixes 444, but not 422. For 422 (idc_fmt=2), horiz_mult (for l/r)
> > > should be 2, but vert_mult (for t/b) should be 1.
> >
> > New patch attached.
>
> lgtm (I think).
Patch applied.
Thank you for your help, Carl Eugen
_
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc' chunks which
would previously cause "strea
On 03/09/2016 01:43 PM, Michael Niedermayer wrote:
On Wed, Mar 09, 2016 at 01:20:13PM +0100, Mats Peterson wrote:
On 03/09/2016 02:54 AM, Mats Peterson wrote:
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeki
On Wed, Mar 09, 2016 at 01:20:13PM +0100, Mats Peterson wrote:
> On 03/09/2016 02:54 AM, Mats Peterson wrote:
> >Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
> >entries.
> >
> >Implementation of 'xxpc' index entry storage for seeking will come in
> >the future (provided I
On 03/09/2016 02:54 AM, Mats Peterson wrote:
Interim fix of the parsing of idx1 indexes with 'xxpc' (palette change)
entries.
Implementation of 'xxpc' index entry storage for seeking will come in
the future (provided I can manage it).
Test file TOON.AVI from King's Quest VI with indexed 'xxpc'
On Tue, Mar 08, 2016 at 10:16:50PM -0500, Ganesh Ajjanagadde wrote:
> Yields 2x improvement in function performance, and boosts aac encoding
> speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system
Le decadi 20 ventôse, an CCXXIV, Michael Niedermayer a écrit :
> wm4 posted a patch to document the undefied-ness of this
> 0301 19:21 wm4 (2.4K) ├─>[FFmpeg-devel] [PATCH 1/6] lavu: improve
> documentation of some AVFrame functions
>
> is that sufficient, or should further documentati
On Wed, Mar 09, 2016 at 10:27:50AM +0100, Clément Bœsch wrote:
> On Tue, Mar 08, 2016 at 09:14:58PM +0100, Michael Niedermayer wrote:
> > This should detect caes where these functions are called in unclean
> > destinations
> > ---
> > libavutil/frame.c |6 ++
> > 1 file changed, 6 inserti
On Wed, Mar 09, 2016 at 10:39:36AM +0100, Nicolas George wrote:
> Le decadi 20 ventôse, an CCXXIV, Clement Boesch a écrit :
> > That's a good idea but downstream developers might prefer their users to
> > experience a memleak that random violent aborts. I would probably make it
> > at assert level
Le nonidi 19 ventôse, an CCXXIV, Clement Boesch a écrit :
> I added this task for previous OPW (and maybe GSoC, can't remember). I'm
> unfortunately not available for mentoring (too much time, energy and
> responsibility). Though, I can provide standard help as a developer.
Same goes for me.
> So
On Tue, 8 Mar 2016 23:44:13 +0100 (CET)
Marton Balint wrote:
> On Tue, 8 Mar 2016, Hendrik Leppkes wrote:
>
> > On Tue, Mar 8, 2016 at 10:54 PM, Marton Balint wrote:
> >>
> >> On Tue, 8 Mar 2016, wm4 wrote:
> >>
> >>> On Tue, 8 Mar 2016 21:29:52 +0100
> >>> Marton Balint wrote:
> >>>
>
On 9 March 2016 at 03:16, Ganesh Ajjanagadde wrote:
> Yields 2x improvement in function performance, and boosts aac encoding
> speed by ~ 4% overall. Sample benchmark (Haswell+GCC under -march=native):
> after:
> ffmpeg -i sin.flac -acodec aac -y sin_new.aac 5.22s user 0.03s system
> 105% cpu 4.
On 9 March 2016 at 07:22, Reimar Döffinger wrote:
> On 09.03.2016, at 04:16, Ganesh Ajjanagadde wrote:
>
> > Yields 2x improvement in function performance, and boosts aac encoding
> > speed by ~ 4% overall. Sample benchmark (Haswell+GCC under
> -march=native):
> > after:
> > ffmpeg -i sin.flac -
Le decadi 20 ventôse, an CCXXIV, Clement Boesch a écrit :
> That's a good idea but downstream developers might prefer their users to
> experience a memleak that random violent aborts. I would probably make it
> at assert level 1.
Assert level 0 and 1 are equivalent from an API point of view: they
On Tue, Mar 08, 2016 at 09:14:58PM +0100, Michael Niedermayer wrote:
> This should detect caes where these functions are called in unclean
> destinations
> ---
> libavutil/frame.c |6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 5607
ping
On 24/02/16 16:38, Vicente Olivert Riera wrote:
> Understanding the mips32r6 and mips64r6 ISAs in the configure script is
> not enough. In order to have full support for MIPS R6 in FFmpeg we need
> to be able to build it, and for that we need to make sure we don't use
> incompatible assembler
66 matches
Mail list logo
