On Thu, 25 Feb 2016 15:48:17 +1100
Matt Oliver wrote:
> On 25 February 2016 at 13:20, Ganesh Ajjanagadde wrote:
>
> > From: Ganesh Ajjanagadde
> >
> > These use __builtin_expect, and may be useful for optimizing nearly
> > certain branches, to yield size and/or speed improvements.
> >
> > Note
On 25 February 2016 at 13:20, Ganesh Ajjanagadde wrote:
> From: Ganesh Ajjanagadde
>
> These use __builtin_expect, and may be useful for optimizing nearly
> certain branches, to yield size and/or speed improvements.
>
> Note that this is used in the Linux kernel for the same purpose. For
> some
On Thu, Feb 25, 2016 at 04:35:37AM +0100, Michael Niedermayer wrote:
> Hi Marina
>
> Thu, Feb 18, 2016 at 08:29:53PM -0500, Marina Zhurakhinskaya wrote:
> > - Original Message -
> > > From: "Michael Niedermayer"
> > > To: "FFmpeg development discussions and patches"
> > > Cc: "outreachy-
Hi Marina
Thu, Feb 18, 2016 at 08:29:53PM -0500, Marina Zhurakhinskaya wrote:
> - Original Message -
> > From: "Michael Niedermayer"
> > To: "FFmpeg development discussions and patches"
> > Cc: "outreachy-admins" , o...@ffmpeg.org
> > Sent: Wednesday, February 17, 2016 11:09:31 PM
> > Su
Add some more verbose info regarding why the imprecise and slow floor(x+0.5)
hack
is used; helpful for future maintenance.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/rational.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavutil/rational.c b/libavutil/rational.c
From: Ganesh Ajjanagadde
These use __builtin_expect, and may be useful for optimizing nearly
certain branches, to yield size and/or speed improvements.
Note that this is used in the Linux kernel for the same purpose. For
some idea as to potential benefits, see e.g
http://blog.man7.org/2012/10/ho
From: Ganesh Ajjanagadde
Merely a simple illustration of av_unlikely's utility; there are
certainly more interesting use cases.
Actual performance benefit is impossible to accurately quantify due to the
context-dependence of the branch predictor. Nonetheless, as a ballpark
estimate, it yields ~
Signed-off-by: Michael Niedermayer
---
tests/fate/demux.mak |3 +
tests/ref/fate/mov-mp3-demux | 289 ++
2 files changed, 292 insertions(+)
create mode 100644 tests/ref/fate/mov-mp3-demux
diff --git a/tests/fate/demux.mak b/tests/fate/demux.m
On 2/24/2016 11:05 PM, Matt Oliver wrote:
> This is a really simple patch as apparently when the cuda hwcontext filter
> was added a semicolon was forgotten.
>
> For such simple patches as this is it worth even posting to the mailing
> list or just directly applying it straight away?
Trivial patc
This is a really simple patch as apparently when the cuda hwcontext filter
was added a semicolon was forgotten.
For such simple patches as this is it worth even posting to the mailing
list or just directly applying it straight away?
---
libavfilter/vf_hwupload_cuda.c | 2 +-
1 file changed, 1 in
Signed-off-by: Marton Balint
---
libavformat/adtsenc.c | 2 +-
libavformat/aiffenc.c | 1 +
libavformat/cafenc.c| 1 +
libavformat/flvenc.c| 2 +-
libavformat/lrcenc.c| 3 ++-
libavformat/mp3enc.c| 2 +-
libavformat/nutenc.c| 3 ++-
libavformat/omaenc.c| 2 +-
libavfor
Every date parsing routine now uses av_parse_time which handles 'now' and
provides greater precision as well. This change also enables the segmenter
muxer to set the proper 'now' creation time at the beginning of each segment.
Signed-off-by: Marton Balint
---
ffmpeg_opt.c | 13 -
1 f
This can be used for formats which write all format metadata as string to
files, therefore non-standard creation times such as 'now' will be parsed.
The standardized creation time is UTC ISO 8601 with microsecond precision.
Signed-off-by: Marton Balint
---
libavformat/avformat.h | 1 +
libavfo
On Wed, Feb 24, 2016 at 03:37:53PM +0100, Clément Bœsch wrote:
> On Sun, Feb 21, 2016 at 06:34:43PM +0100, Michael Niedermayer wrote:
> > On Sun, Feb 21, 2016 at 01:08:29PM +0100, Clément Bœsch wrote:
> > [...]
> > > diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> > > index a
On Mon, Feb 22, 2016 at 02:53:06PM -0800, Neil Birkbeck wrote:
> Some containers, like webm/mkv, will contain this mastering metadata.
> This is analogous to the way 3D fpa data is handled (in frame and
> packet side data).
>
> Signed-off-by: Neil Birkbeck
> ---
> libavcodec/avcodec.h | 7
On Wed, Feb 24, 2016 at 06:52:13PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes ticket #5267 for me.
>
> Please comment, Carl Eugen
> mjpegdec.c |6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
> 1fc8e89404661529f72eac63b74ab7c2ae300b8f patchadobecm.diff
> diff
---
libavcodec/Makefile | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f78d27b..2c4ae76 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -761,6 +761,7 @@ OBJS-$(CONFIG_ISO_MEDIA) += mpeg4audio.o
mpegaudiodata.o
OBJ
On Wed, Feb 24, 2016 at 05:01:22PM -0300, James Almer wrote:
> On 2/24/2016 4:53 PM, Michael Niedermayer wrote:
> > This broke packed_maindata.mp3.mp4
> > Its unknown to me what this commit would have fixed
>
> Should have been a no-op i guess, seeing how right below there's code
> setting AVSTREA
On 2/24/2016 4:53 PM, Michael Niedermayer wrote:
> This broke packed_maindata.mp3.mp4
> Its unknown to me what this commit would have fixed
Should have been a no-op i guess, seeing how right below there's code
setting AVSTREAM_PARSE_FULL if some conditions are met.
>
> This reverts commit 79127d
This broke packed_maindata.mp3.mp4
Its unknown to me what this commit would have fixed
This reverts commit 79127dbbeffa87243c92af2befc09ad63bcbd1a1, reversing
changes made to 9fad1ce7c95adeec440f51af77f730340a6d27b8.
---
libavformat/mov.c |3 ---
1 file changed, 3 deletions(-)
diff --git a/l
On 02/24/2016 06:16 PM, Mats Peterson wrote:
The QuickTime palette was incorrectly stored in the MatroskaDemuxContext
instead of a MatroskaTrack.
Sample Matroska file with two 8 bpp QuickTime video tracks:
https://drive.google.com/open?id=0B3_pEBoLs0faY1JKQXBfRy1QYUk
___
Le sextidi 6 ventôse, an CCXXIV, James Almer a écrit :
> It may result in a slight speed boost, so it would be nice if someone with
> a ppc machine could test it.
I can access this:
gcc110 2TB 4x16x3.55 GHz IBM POWER7 / 64 GB RAM /
IBM Power 730 Express server / Fedora 18 ppc64
processor :
Hi!
Attached patch fixes ticket #5267 for me.
Please comment, Carl Eugen
diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 69c9cf3..87c1501 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1677,7 +1677,11 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
The QuickTime palette was incorrectly stored in the MatroskaDemuxContext
instead of a MatroskaTrack.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 079df7d5971a6ff0136597dfe1dbefc1e2c239f9 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 24 Feb 2016 18:14:05 +0100
Subject: [PATC
Hi jb, thresh
ive attached a simple patch which should make merges reviewable on
the maiing list
if you agree with the change, please apply
if you see a problem or if it misbehaves then dont hesitate to revert
i have locally tested it on a few commits and it added usefull
diffs to merges while le
On 2/24/2016 1:15 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Feb 24, 2016 at 10:47 AM, James Almer wrote:
>
>> On 2/24/2016 12:13 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Tue, Feb 23, 2016 at 8:40 PM, James Almer wrote:
>>>
Tested on x86 and benched with no apparent speed loss
>>>
I have used ffmpeg 2.6.3 to record audio and video from multiple IP camera
multicast over respective multicast IP but on same audio and video port on
a PC having RHEL 6.6 OS.
I found that for single camera it is working fine but when 2 or more camera
is used then the video is getting mixed. On fur
2016-02-24 14:36 GMT+01:00 Ronald S. Bultje :
> Please file a bug report on trac.ffmpeg.org for license violations. I'm
> not guaranteeing that anything will happen, but at least it's easier to
> keep track of than ML.
>
Hi Ronald,
thank you for your message. I did it here:
https://trac.ffmpeg.o
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 code which makes the build fail. Ifdefing the
offending code
Signed-off-by: Vicente Olivert Riera
---
Changes v6 -> v7:
- Do not pass -msoft-float. Leave the mipsfpu handling as it was
before, so nothing changes. This could be improbed in the future.
Changes v5 -> v6:
- Multiple changes:
- Use separate if blocks when detecting the MIPS ISA, this wa
We don't know which features are available when the user selects a
generic core, so don't disable anything by default and let the user
decide.
Signed-off-by: Vicente Olivert Riera
---
Changes v4 -> v7:
- Nothing.
Changes v3 -> v4:
- Minor change in the commit log: remove "let's".
Changes v2 -
On Wed, Feb 24, 2016 at 11:40:12AM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> configure | 1 +
> 1 file changed, 1 insertion(+)
probably ok
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
There will always be a question for which you do n
Hi,
On Wed, Feb 24, 2016 at 10:47 AM, James Almer wrote:
> On 2/24/2016 12:13 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Feb 23, 2016 at 8:40 PM, James Almer wrote:
> >
> >> Tested on x86 and benched with no apparent speed loss
> >
> >
> > That's because x86 supports unaligned loads.
>
On Wed, Feb 24, 2016 at 03:12:56PM +, Derek Buitenhuis wrote:
> On 2/24/2016 3:10 PM, Michael Niedermayer wrote:
> > This should fix leaving uninitialized pointers in priv which can confuse
> > user applications.
> > See: https://github.com/golang/go/issues/14426
> >
> > Signed-off-by: Michael
On 2/24/2016 12:13 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Tue, Feb 23, 2016 at 8:40 PM, James Almer wrote:
>
>> Tested on x86 and benched with no apparent speed loss
>
>
> That's because x86 supports unaligned loads.
>
> How come you get unaligned loads? Shouldn't this prevent it?
>
> -
Derek Buitenhuis gmail.com> writes:
> Improves probing, especially over http when there is a
> Content-Type header
(Do you have an example where the probing fails?)
The idea of these additional demuxers is that they probe
the content instead of relying on the file suffix.
File suffix provide
Hi,
On Tue, Feb 23, 2016 at 8:40 PM, James Almer wrote:
> Tested on x86 and benched with no apparent speed loss
That's because x86 supports unaligned loads.
How come you get unaligned loads? Shouldn't this prevent it?
-if (HAVE_BIGENDIAN || (!HAVE_FAST_UNALIGNED && ((intptr_t)src & 3)))
On 2/24/2016 3:10 PM, Michael Niedermayer wrote:
> This should fix leaving uninitialized pointers in priv which can confuse
> user applications.
> See: https://github.com/golang/go/issues/14426
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avpacket.c |1 +
> 1 file changed, 1 ins
This should fix leaving uninitialized pointers in priv which can confuse
user applications.
See: https://github.com/golang/go/issues/14426
Signed-off-by: Michael Niedermayer
---
libavcodec/avpacket.c |1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/avpacket.c b/libavcodec/avpack
On Sun, Feb 21, 2016 at 06:34:43PM +0100, Michael Niedermayer wrote:
> On Sun, Feb 21, 2016 at 01:08:29PM +0100, Clément Bœsch wrote:
> [...]
> > diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> > index aa8bfac..b493dd1 100644
> > --- a/libavcodec/options_table.h
> > +++ b/lib
On Sun, Feb 21, 2016 at 01:08:27PM +0100, Clément Bœsch wrote:
> [PATCH 1/6] Kill timed SSA
>
> This one is an old patch, which kills the usage of the old and unused
> AV_CODEC_ID_SSA
>
> [PATCH 2/6] lavc: allow subtitle text format to be ASS without timing
>
> The big commit. Text based decoder
From: Justin Ruggles
There can be multiple SOS markers, so do not return 0 in that case.
Signed-off-by: Derek Buitenhuis
---
libavformat/img2dec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index c353563..a755b6f 100644
---
Derek Buitenhuis gmail.com> writes:
> From: Justin Ruggles gmail.com>
>
> There can be multiple SOS markers, so do not return 0 in that case.
Looks good to me.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
Justin Ruggles (2):
img2dec: Support Progressive JPEG in jpeg_probe
img2dec: Add mime_type to image formats
libavformat/img2dec.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
--
2.7.0
___
ffmpeg-devel
From: Justin Ruggles
Improves probing, especially over http when there is a Content-Type header
Signed-off-by: Derek Buitenhuis
---
libavformat/img2dec.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/libavformat/img2dec.c b/libavformat/im
On Tue, Feb 23, 2016 at 8:44 PM, Andrea Lazzarotto <
andrea.lazzaro...@gmail.com> wrote:
> 2016-02-21 21:39 GMT+01:00 Andrea Lazzarotto >:
>
> > I recently discovered a proprietary software violating multiple licenses
> > of several open source projects, including Mplayer, FFmpeg and XviD.
> >
>
Small fix. Sorry for my spam-like patch posting, but that's the way I
work at the moment. I'll try to limit myself in the future.
Mats
>From 0cf62b279e2577655e3867e8b0287c191784eeaa Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 24 Feb 2016 12:49:50 +0100
Subject: [PATCH v26] lavf/move
On 02/24/2016 12:40 PM, Mats Peterson wrote:
On 02/24/2016 12:33 PM, Mats Peterson wrote:
Sorry, Moritz. Use the same logic as riffenc.c, treating pixel format as
AV_PIX_FMT_MONOWHITE if not set.
And the bit detph is 1 bpp, that is.
depth
___
ffmp
On 02/24/2016 12:33 PM, Mats Peterson wrote:
Sorry, Moritz. Use the same logic as riffenc.c, treating pixel format as
AV_PIX_FMT_MONOWHITE if not set.
And the bit detph is 1 bpp, that is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ff
Sorry, Moritz. Use the same logic as riffenc.c, treating pixel format as
AV_PIX_FMT_MONOWHITE if not set.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 00c5fe1e377d37c292417e41290c72039a55b899 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Wed, 24 Feb 2016 12:31:09 +0100
Subject:
wm4 skrev: (24 februari 2016 11:51:26 CET)
>On Wed, 24 Feb 2016 10:32:24 + (UTC)
>Carl Eugen Hoyos wrote:
>
>> Ronald S. Bultje gmail.com> writes:
>>
>> > > As requested on ffmpeg-user.
>> >
>> > I'm a little ambivalent to this. Let me explain. You can
>> > easily fix this with a shell
On Wed, 24 Feb 2016 10:32:24 + (UTC)
Carl Eugen Hoyos wrote:
> Ronald S. Bultje gmail.com> writes:
>
> > > As requested on ffmpeg-user.
> >
> > I'm a little ambivalent to this. Let me explain. You can
> > easily fix this with a shell script that creates links
> > from img-{1000...1}.jp
From: Matthieu Bouron
---
configure | 1 +
1 file changed, 1 insertion(+)
diff --git a/configure b/configure
index 3d1ee49..337a060 100755
--- a/configure
+++ b/configure
@@ -309,6 +309,7 @@ Toolchain options:
--nm=NM use nm tool NM [$nm_default]
--ar=AR
On 02/24/2016 11:32 AM, Carl Eugen Hoyos wrote:
(I find it striking that you use "shell syntax" and "exe"
in the same sentence...)
Me too :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Ronald S. Bultje gmail.com> writes:
> > As requested on ffmpeg-user.
>
> I'm a little ambivalent to this. Let me explain. You can
> easily fix this with a shell script that creates links
> from img-{1000...1}.jpg to img_2_{1...1000}.jpg and deletes
> them after the ffmpeg run. This is super-t
On Tue, Feb 23, 2016 at 10:40:08PM -0300, James Almer wrote:
[...]
> That aside, note that these runtime erros happen with every test using md5 and
> don't make ubsan register them as failed. In the link above something else
> made
> it fail. It makes me wonder how many other ubsan errors are hidd
56 matches
Mail list logo
