2014-10-25 2:28 GMT+04:00 Timothy Gu timothyg...@gmail.com:
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
On Fri, 24 Oct 2014 19:50:25 +0400
Andrey Utkin andrey.krieger.ut...@gmail.com 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
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 :
IMHO
On Fri, Oct 24, 2014 at 11:31:14PM +0200, Lukasz Marek wrote:
Signed-off-by: Lukasz Marek lukasz.m.lu...@gmail.com
---
doc/fftools-common-opts.texi | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
LGTM
[...]
--
Michael GnuPG fingerprint:
On Sat, 25 Oct 2014 11:43:12 +0200
Nicolas George geo...@nsup.org 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
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
On Sat, Oct 25, 2014 at 01:10:20PM +0200, wm4 wrote:
On Sat, 25 Oct 2014 11:43:12 +0200
Nicolas George geo...@nsup.org 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
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
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
---
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
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
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
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 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 |
2014-10-25 13:19 GMT+02:00 Christophe Gisquet christophe.gisq...@gmail.com:
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
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 will
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-after
On Sat, 25 Oct 2014 13:14:26 +0200
Reimar Döffinger reimar.doeffin...@gmx.de wrote:
On Sat, Oct 25, 2014 at 01:10:20PM +0200, wm4 wrote:
On Sat, 25 Oct 2014 11:43:12 +0200
Nicolas George geo...@nsup.org wrote:
Le tridi 3 brumaire, an CCXXIII, Timothy Gu a écrit :
Those URLs are
On Sat, Oct 25, 2014 at 01:40:11PM +0200, wm4 wrote:
On Sat, 25 Oct 2014 13:14:26 +0200
Reimar Döffinger reimar.doeffin...@gmx.de 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
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
+++
On Sat, 25 Oct 2014 13:50:58 +0200
Reimar Döffinger reimar.doeffin...@gmx.de 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 reimar.doeffin...@gmx.de wrote:
wm4, if you have a simple way of doing this check, please explain
Clément Bœsch u at 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 at ref{pullup} filter.
Well I don't mind much but then... how is pullup making
any difference here
Reimar Döffinger Reimar.Doeffinger at 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
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
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 picking the
On Sat, Oct 25, 2014 at 12:35:11PM +, Carl Eugen Hoyos wrote:
Reimar Döffinger Reimar.Doeffinger at 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,
On Sat, 25 Oct 2014 14:43:39 +0200
Nicolas George geo...@nsup.org 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
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 the
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
On Sat, Oct 25, 2014 at 03:08:10PM +0200, wm4 wrote:
On Sat, 25 Oct 2014 14:43:39 +0200
Nicolas George geo...@nsup.org 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
Reimar Döffinger Reimar.Doeffinger at 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
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,13 @@
Updated patch fixing off-by-one in device listing.
-Thilo
From d8dc49423dbcdadf739997c453204e137ed8c088 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann thilo.borgm...@mail.de
Date: Sat, 25 Oct 2014 17:02:28 +0200
Subject: [PATCH] lavd/avfoundation: Add support for screen capturing.
Patch based on
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 insertions(+), 14
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:
2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
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
On Sat, Oct 25, 2014 at 1:01 AM, Michael Niedermayer michae...@gmx.at
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
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 arwaarif1...@gmail.com wrote:
On Sat, Oct 25, 2014 at 1:01 AM, Michael Niedermayer michae...@gmx.at
wrote:
On Fri, Oct 24, 2014 at 10:34:32PM
On Sat, Oct 25, 2014 at 10:14 PM, arwa arif arwaarif1...@gmail.com 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 arwaarif1...@gmail.com
wrote:
On Sat, Oct 25, 2014 at 1:01 AM, Michael
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
This
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
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
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 geo...@nsup.org wrote:
Le
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, I
Hi,
2014-10-25 18:25 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
On Sat, Oct 25, 2014 at 05:35:37PM +0200, Christophe Gisquet wrote:
2014-10-25 13:35 GMT+02:00 Reimar Döffinger reimar.doeffin...@gmx.de:
Could you maybe add e.g. a FATE test that clearly shows the before-after
On Fri, Oct 24, 2014 at 12:35:33AM +0200, Michael Niedermayer wrote:
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavformat/rdt.c | 21 +++--
1 file changed, 15 insertions(+), 6 deletions(-)
reviewed by ronald
applied
thx
[...]
--
Michael GnuPG
This fixes the issue that a not set or not forwarded whitelist
would allow to bypass it.
Signed-off-by: Michael Niedermayer michae...@gmx.at
---
libavcodec/avcodec.h | 17 +
libavcodec/utils.c | 14 +-
libavformat/avformat.h |4
libavformat/utils.c
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 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
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 +-
4
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 @@ typedef struct
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
On Sat, Oct 25, 2014 at 1:42 PM, Tomas Härdin tomas.har...@codemill.se
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
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 Sun, Oct 26, 2014 at 02:09:19AM +0200, wm4 wrote:
On Sun, 26 Oct 2014 00:16:26 +0200
Nicolas George geo...@nsup.org 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.
__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 jamr...@gmail.com
---
https://gcc.gnu.org/onlinedocs/gcc-4.9.0/gcc/_005f_005fatomic-Builtins.html
This is an RFC for a couple
56 matches
Mail list logo