__sync built-ins are considered legacy and will be deprecated.
These new memory model aware built-ins have been available since GCC 4.7.0
Signed-off-by: James Almer
---
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/_005f_005fatomic-Builtins.html
This is an RFC for a couple reasons.
The first is t
On Sun, Oct 26, 2014 at 02:09:19AM +0200, wm4 wrote:
> On Sun, 26 Oct 2014 00:16:26 +0200
> Nicolas George wrote:
>
> > Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit :
> > > This fixes the issue that a not set or not forwarded whitelist
> > > would allow to bypass it.
> >
> > I
Sorry I am not posting to the same thread directly, I joined the list after
this discussion finished a few weeks ago.
I was reading Yusuke's explanation (pasted below) regarding the
relationship between PTS, CTS, and DTS in the context of fragments, and
there are some parts that I don't understand
On Sun, 26 Oct 2014 00:16:26 +0200
Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit :
> > This fixes the issue that a not set or not forwarded whitelist
> > would allow to bypass it.
>
> I am a bit worried by the sheer amount of extra code and API this simp
On Sun, Oct 26, 2014 at 12:16:26AM +0200, Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit :
> > This fixes the issue that a not set or not forwarded whitelist
> > would allow to bypass it.
>
> I am a bit worried by the sheer amount of extra code and API this
On Sat, Oct 25, 2014 at 11:32:43PM +0530, arwa arif wrote:
> Can you please specify what is meant by stand-alone changes? Do I need to
> add the non-default functions in different commit? I am not very sure if I
> understood it right. Apart from that, I have updated the patch.
>
> On Sat, Oct 25,
On Sat, Oct 25, 2014 at 1:42 PM, Tomas Härdin
wrote:
> On Fri, 2014-10-24 at 17:31 -0700, Mark Reid wrote:
> > ---
> > libavformat/mxf.h | 1 +
> > libavformat/mxfdec.c | 31 +--
> > tests/ref/lavf/mxf | 6 +++---
> > tests/ref/lavf/mxf_d10 | 2 +-
> > 4
Le quartidi 4 brumaire, an CCXXIII, Michael Niedermayer a écrit :
> This fixes the issue that a not set or not forwarded whitelist
> would allow to bypass it.
I am a bit worried by the sheer amount of extra code and API this simple
feature requires. Maybe it is a sign that it was not the best appr
On Sat, Oct 25, 2014 at 05:43:00PM -0300, James Almer wrote:
> On 25/10/14 4:51 PM, Michael Niedermayer wrote:
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index eac3fc7..1000c80 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -3118,6 +3118,8 @@ typed
On Sat, Oct 25, 2014 at 10:42:25PM +0200, Tomas Härdin wrote:
> On Fri, 2014-10-24 at 17:31 -0700, Mark Reid wrote:
> > ---
> > libavformat/mxf.h | 1 +
> > libavformat/mxfdec.c | 31 +--
> > tests/ref/lavf/mxf | 6 +++---
> > tests/ref/lavf/mxf_d10 | 2 +-
On Sat, Oct 25, 2014 at 05:07:02PM +0200, Thilo Borgmann wrote:
> Updated patch fixing off-by-one in device listing.
>
> -Thilo
> configure |2 -
> libavdevice/avfoundation.m | 70
> -
> 2 files changed, 57 insertions(+), 15 del
On 25/10/14 4:51 PM, Michael Niedermayer wrote:
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index eac3fc7..1000c80 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3118,6 +3118,8 @@ typedef struct AVCodecContext {
> * If NULL then all are allowed
>
On Fri, 2014-10-24 at 17:31 -0700, Mark Reid wrote:
> ---
> libavformat/mxf.h | 1 +
> libavformat/mxfdec.c | 31 +--
> tests/ref/lavf/mxf | 6 +++---
> tests/ref/lavf/mxf_d10 | 2 +-
> 4 files changed, 34 insertions(+), 6 deletions(-)
>
> diff --git a/li
On Sat, 25 Oct 2014 21:51:25 +0200
Michael Niedermayer wrote:
> This fixes the issue that a not set or not forwarded whitelist
> would allow to bypass it.
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.h | 17 +
> libavcodec/utils.c | 14 +++
This fixes the issue that a not set or not forwarded whitelist
would allow to bypass it.
Signed-off-by: Michael Niedermayer
---
libavcodec/avcodec.h | 17 +
libavcodec/utils.c | 14 +-
libavformat/avformat.h |4
libavformat/utils.c|6 --
On Fri, Oct 24, 2014 at 12:35:33AM +0200, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/rdt.c | 21 +++--
> 1 file changed, 15 insertions(+), 6 deletions(-)
reviewed by ronald
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B
Hi,
2014-10-25 18:25 GMT+02:00 Reimar Döffinger :
> On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote:
>> 2014-10-25 13:35 GMT+02:00 Reimar Döffinger :
>> > Could you maybe add e.g. a FATE test that clearly shows the before-after
>> > improvements?
>>
>> I've tried for a small whi
On 24.10.2014 23:13, Michael Niedermayer wrote:
+The returned list cannot be assumed to be always completed.
complete
+The returned list cannot be assumed to be always completed.
complete
Both changed
i wonder if some of the code can be factorized/simplifed but either
way it LGTM
I know
On 25.10.2014 11:56, Michael Niedermayer wrote:
On Fri, Oct 24, 2014 at 11:31:14PM +0200, Lukasz Marek wrote:
Signed-off-by: Lukasz Marek
---
doc/fftools-common-opts.texi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
LGTM
Pushed.
_
Le quartidi 4 brumaire, an CCXXIII, arwa arif a écrit :
> Can you please specify what is meant by stand-alone changes?
I believe it was already specified in my original message: "such as moving
code into a shared function", and pore importantly: "it does not seem to
apply here".
> Apart from that
Can you please specify what is meant by stand-alone changes? Do I need to
add the non-default functions in different commit? I am not very sure if I
understood it right. Apart from that, I have updated the patch.
On Sat, Oct 25, 2014 at 10:16 PM, Nicolas George wrote:
> Le quartidi 4 brumaire, a
On 24.10.2014 00:18, Reynaldo H. Verdejo Pinochet wrote:
Hi Lukasz
+static int ffserver_apply_stream_config(AVCodecContext *enc, const
AVDictionary *conf, AVDictionary **opts)
+{
+static const char *error_message = "Cannot parse '%s' as number for %s
parameter.\n";
+AVDictionaryEntry *
On Sat, Oct 25, 2014 at 11:19:22AM +, Christophe Gisquet wrote:
> It is derived from the actual equations of the specs. In
> particular, it is closer to the inverse of what the encoder uses.
>
> fate tests accordingly updated.
> ---
> libavcodec/dvdata.c | 16
> t
Le quartidi 4 brumaire, an CCXXIII, arwa arif a écrit :
> > please post a new patch instead of a patch on top of a previous
> > patch
> libavfilter/vf_xbr.c | 303
> ++
> 1 file changed, 303 insertions(+)
> create mode 100644 libavfilter/vf_xbr.c
On Sat, Oct 25, 2014 at 10:14 PM, arwa arif wrote:
> Please ignore the previous mail. I attached the wrong patch. New patch is
> attached with this mail.
>
> On Sat, Oct 25, 2014 at 10:06 PM, arwa arif
> wrote:
>
>>
>>
>> On Sat, Oct 25, 2014 at 1:01 AM, Michael Niedermayer
>> wrote:
>>
>>> On
Please ignore the previous mail. I attached the wrong patch. New patch is
attached with this mail.
On Sat, Oct 25, 2014 at 10:06 PM, arwa arif wrote:
>
>
> On Sat, Oct 25, 2014 at 1:01 AM, Michael Niedermayer
> wrote:
>
>> On Fri, Oct 24, 2014 at 10:34:32PM +0530, arwa arif wrote:
>> > I have t
On Sat, Oct 25, 2014 at 1:01 AM, Michael Niedermayer
wrote:
> On Fri, Oct 24, 2014 at 10:34:32PM +0530, arwa arif wrote:
> > I have taken care of aal the things mentioned except the floating point.
> I
> > will update the floating point part till tomorrow. For now, I have
> attached
> > the patch
On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote:
> 2014-10-25 13:35 GMT+02:00 Reimar Döffinger :
> > Could you maybe add e.g. a FATE test that clearly shows the before-after
> > improvements?
>
> I've tried for a small while, by swapping fields on lena and converting to
> yuv42[
2014-10-25 13:35 GMT+02:00 Reimar Döffinger :
> Could you maybe add e.g. a FATE test that clearly shows the before-after
> improvements?
I've tried for a small while, by swapping fields on lena and converting to
yuv42[02]p and feeding it to ffmpeg with:
-pix_fmt yuv422p -s 720x576 -i lena.yuv -fla
Updated patch fixing off-by-one in device listing.
-Thilo
>From d8dc49423dbcdadf739997c453204e137ed8c088 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sat, 25 Oct 2014 17:02:28 +0200
Subject: [PATCH] lavd/avfoundation: Add support for screen capturing.
Patch based on pull-request by Joseph
On Sat, Oct 25, 2014 at 01:34:22PM +0200, Reimar Döffinger wrote:
> On Sat, Oct 25, 2014 at 11:19:21AM +, Christophe Gisquet wrote:
> > ---
> > libavcodec/dv.c | 4 ++--
> > libavcodec/dvdata.c | 12 ++--
> > libavcodec/dvdata.h | 12 ++--
> > 3 files changed, 14 insertion
On Sat, Oct 25, 2014 at 11:19:20AM +, Christophe Gisquet wrote:
> This is a mostly cosmetical patch in preparation for the following.
> ---
> libavcodec/dv.c | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
applied
thx
[...]
--
Michael GnuPG fingerprint: 9FF2
On Fri, Oct 24, 2014 at 07:50:25PM +0400, Andrey Utkin wrote:
> ---
> libavdevice/v4l2.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index cf7a92c..ebc50bb 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c
> @@ -806,6 +806,
On Sat, Oct 25, 2014 at 03:08:10PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 14:43:39 +0200
> Nicolas George wrote:
> > That would not be heavy-weight, that would be outright irresponsible:
> > ioctl() opcodes are not globally unique. An opcode that maps to a harmless
> > probe on v4l devices can tr
Reimar Döffinger gmx.de> writes:
> I think this is a bit Linux/Unix/centric.
Of course, as it is quite difficult to compile
the demuxer on anything else...
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/li
Le quartidi 4 brumaire, an CCXXIII, Reimar Döffinger a écrit :
> Such a special protocol that doesn't need /dev/video magic would probably be
> a good idea.
We could agree on a global convention that states something like this:
Whenever it makes sense, demuxers that use the file name directly sho
Le quartidi 4 brumaire, an CCXXIII, wm4 a écrit :
> Then there's no sane way to handle this. Basically, you need to know:
> yes, this is a video device.
And that does not exist.
> Such a flag might probably work...
Actually, probably not without more changes, because the devices do not
remove th
On Sat, 25 Oct 2014 14:43:39 +0200
Nicolas George wrote:
> Le quartidi 4 brumaire, an CCXXIII, Reimar Döffinger a écrit :
> > That would end up trying a v4l ioctl on each and every file that
> > FFmpeg tries to open (unless you mean only after the /dev/video check,
> > but that would not solve th
On Sat, Oct 25, 2014 at 12:35:11PM +, Carl Eugen Hoyos wrote:
> Reimar Döffinger gmx.de> writes:
>
> > It should be possible to override the other way via
> > file:///dev/video/... I believe?
>
> Of course.
>
> Could the original patch please be applied?
I think I agree, however...
> If
On Sat, Oct 25, 2014 at 02:15:47PM +0200, wm4 wrote:
> > I admittedly just assumed that v4l2:///dev/video/... would work
> > currently. If not, that sounds like something that can and should
> > be fixed.
> > However as a convenience feature, I think it is good that /dev/video
> > just ends up pick
Le quartidi 4 brumaire, an CCXXIII, Reimar Döffinger a écrit :
> That would end up trying a v4l ioctl on each and every file that
> FFmpeg tries to open (unless you mean only after the /dev/video check,
> but that would not solve the issue you mention later).
> That feels a bit heavy-weight.
That
Reimar Döffinger gmx.de> writes:
> It should be possible to override the other way via
> file:///dev/video/... I believe?
Of course.
Could the original patch please be applied?
If really necessary with MAX - 1, we have
32bit probe functions that return MAX and
no user will ever want to read
Clément Bœsch pkh.me> writes:
> > +The filter only works for constant frame rate input. If your input
> > +has mixed telecined and progressive content with changing framerate,
> > +try the ref{pullup} filter.
>
> Well I don't mind much but then... how is pullup making
> any difference here ac
On Sat, 25 Oct 2014 13:50:58 +0200
Reimar Döffinger wrote:
> On Sat, Oct 25, 2014 at 01:40:11PM +0200, wm4 wrote:
> > On Sat, 25 Oct 2014 13:14:26 +0200
> > Reimar Döffinger wrote:
> > > wm4, if you have a simple way of doing this check, please explain it.
> > > Otherwise I think EXTENSION score
Hi!
Attached patch makes FFmpeg mp3 output more similar to lame's.
It appears to me that 5 is not the default if vbr is used.
Please comment, Carl Eugen
diff --git a/libavcodec/libmp3lame.c b/libavcodec/libmp3lame.c
index 661d1c0..d8a444d 100644
--- a/libavcodec/libmp3lame.c
+++ b/libavcodec/libm
On Sat, Oct 25, 2014 at 01:40:11PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 13:14:26 +0200
> Reimar Döffinger wrote:
> > wm4, if you have a simple way of doing this check, please explain it.
> > Otherwise I think EXTENSION score is good enough to signal "well, we
> > guess that's what it is".
>
>
On Sat, 25 Oct 2014 13:14:26 +0200
Reimar Döffinger wrote:
> On Sat, Oct 25, 2014 at 01:10:20PM +0200, wm4 wrote:
> > On Sat, 25 Oct 2014 11:43:12 +0200
> > Nicolas George wrote:
> >
> > > Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
> > > > Those URLs are very explicit, while `/dev/`
On Sat, Oct 25, 2014 at 11:19:23AM +, Christophe Gisquet wrote:
> The coefficients must be in the appropriate zigzag scan order.
> Also fix their values at the same time, as they were pretty wrong.
>
> Fixes ticket #2970.
Could you maybe add e.g. a FATE test that clearly shows the before-afte
On Sat, Oct 25, 2014 at 11:19:21AM +, Christophe Gisquet wrote:
> ---
> libavcodec/dv.c | 4 ++--
> libavcodec/dvdata.c | 12 ++--
> libavcodec/dvdata.h | 12 ++--
> 3 files changed, 14 insertions(+), 14 deletions(-)
Looks good to me.
I think in all places the uint16_t wi
On Sat, Oct 25, 2014 at 01:21:47PM +0200, Christophe Gisquet wrote:
> 2014-10-25 13:19 GMT+02:00 Christophe Gisquet :
> > Patch #3 uses mathematically more correct values, which happens to match
> > another dv implementation (cedocida). It does not seem to affect that
> > much the decoded output, a
2014-10-25 13:19 GMT+02:00 Christophe Gisquet :
> Patch #3 uses mathematically more correct values, which happens to match
> another dv implementation (cedocida). It does not seem to affect that
> much the decoded output, as there is PSNR variations on the 3rd decimal
> at most. The best I got was,
The encoder has its own tables and does not access the idct_factor
member of the DVVideoContext structure.
---
libavcodec/dv.c | 34
libavcodec/dv.h | 1 +
libavcodec/dvdata.c | 65 --
libavcodec/dvdata.h | 7
libavcodec/dvdec.c | 11
>From 356 to 348 cycles.
---
libavcodec/dv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dv.h b/libavcodec/dv.h
index 8a54cfe..3065806 100644
--- a/libavcodec/dv.h
+++ b/libavcodec/dv.h
@@ -90,7 +90,7 @@ enum dv_pack_type {
*/
#define DV_MAX_BPM 8
-#define T
It is derived from the actual equations of the specs. In
particular, it is closer to the inverse of what the encoder uses.
fate tests accordingly updated.
---
libavcodec/dvdata.c | 16
tests/ref/lavf/dv_fmt | 6 +++---
tests/ref/vsynth/vsynth1-dv | 2 +
The coefficients must be in the appropriate zigzag scan order.
Also fix their values at the same time, as they were pretty wrong.
Fixes ticket #2970.
---
libavcodec/dvdata.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/dvdata.c b/libavcodec/dvdat
---
libavcodec/dv.c | 4 ++--
libavcodec/dvdata.c | 12 ++--
libavcodec/dvdata.h | 12 ++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index e1e5dd9..1f04861 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -206,7 +2
While investigating ticket #2970, I noticed several things about these
tables. Patch #1 is kind of preparatory for #2.
Patch #3 uses mathematically more correct values, which happens to match
another dv implementation (cedocida). It does not seem to affect that
much the decoded output, as there is
This is a mostly cosmetical patch in preparation for the following.
---
libavcodec/dv.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/libavcodec/dv.c b/libavcodec/dv.c
index 4b23f2a..e1e5dd9 100644
--- a/libavcodec/dv.c
+++ b/libavcodec/dv.c
@@ -186,7 +186,
On Sat, Oct 25, 2014 at 01:10:20PM +0200, wm4 wrote:
> On Sat, 25 Oct 2014 11:43:12 +0200
> Nicolas George wrote:
>
> > Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
> > > Those URLs are very explicit, while `/dev/` can mean anything,
> > > including `/dev/stdin`.
> >
> > Andrey quoted t
Le quartidi 4 brumaire, an CCXXIII, wm4 a écrit :
> Don't present your extremely bad ideas as mine. Thanks.
Sorry, I had not realized you wanted him to "check whether it's really a
video device" by the application of careful handwaving and accurate magic.
Regards,
--
Nicolas George
signatur
On Sat, 25 Oct 2014 11:43:12 +0200
Nicolas George wrote:
> Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
> > Those URLs are very explicit, while `/dev/` can mean anything,
> > including `/dev/stdin`.
>
> Andrey quoted these bits of code to show that checking filename for NULL is
> not ne
On Fri, Oct 24, 2014 at 11:31:14PM +0200, Lukasz Marek wrote:
> Signed-off-by: Lukasz Marek
> ---
> doc/fftools-common-opts.texi | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
LGTM
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
During times of un
Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
> Those URLs are very explicit, while `/dev/` can mean anything,
> including `/dev/stdin`.
Andrey quoted these bits of code to show that checking filename for NULL is
not necessary. I believe his proof is conclusive for that point.
wm4 :
> IMH
On Fri, 24 Oct 2014 19:50:25 +0400
Andrey Utkin wrote:
> ---
> libavdevice/v4l2.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavdevice/v4l2.c b/libavdevice/v4l2.c
> index cf7a92c..ebc50bb 100644
> --- a/libavdevice/v4l2.c
> +++ b/libavdevice/v4l2.c
> @@ -806,6 +806,13 @@
2014-10-25 2:28 GMT+04:00 Timothy Gu :
> Those URLs are very explicit, while `/dev/` can mean anything,
> including `/dev/stdin`.
Could you elaborate what this practically means? BTW there's no "/dev"
in my patch, but "/dev/video".
--
Andrey Utkin
___
65 matches
Mail list logo
