On Sun, 2 Oct 2016 08:29:22 -0400
"Ronald S. Bultje" wrote:
> I also think we could contact musl developers and see what's going on
> there. We certainly shouldn't blindly fix this bug by adding an emms
> in a random place, to me that's like opening pandora's box.
on irc i pointed dalias to this
On Sun, 2 Oct 2016 23:16:02 +0200
u-h...@aetey.se wrote:
> > looking at the code? Seriously?)
>
> Yes, I am serious.
vp3 is a decoder written 10+ years ago by a dev who is no longer
active in ffmpeg.
we have many decoders and encoders (and other code) in ffmpeg that have
not been audited (to my
2016-10-03 2:57 GMT+02:00 wm4 :
>> +Do not compile FFmpeg with musl on x86_32, random
>> crashes have to be expected.
> You could mention that this is due to FFmpeg violating the
> ABI (apparently).
New patch attached.
Carl Eugen
From 008248a202e9eb6c1f946467a6fd45825a82a92a Mon Sep 17 00:00:00
On Mon, 3 Oct 2016 01:51:25 +0200
Carl Eugen Hoyos wrote:
> From 35bf44b909658864c9e8cca8dbc855dbde1e1ef5 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Mon, 3 Oct 2016 01:41:37 +0200
> Subject: [PATCH] doc/platform: Mention musl where x86_32 is not supported.
>
> ---
> doc/platform
On 03/10/2016 01:44, Ronald S. Bultje wrote:
Hi,
On Sun, Oct 2, 2016 at 8:42 PM, Carl Eugen Hoyos wrote:
2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :
Hi,
On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos
wrote:
Attached patch adds a musl section to doc/platform.
This is counter-prod
Hi,
On Sun, Oct 2, 2016 at 8:42 PM, Carl Eugen Hoyos wrote:
> 2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos
> wrote:
> >
> >> Attached patch adds a musl section to doc/platform.
> >
> > This is counter-productive...
>
> Sorry, I ju
2016-10-03 2:36 GMT+02:00 Ronald S. Bultje :
> Hi,
>
> On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos wrote:
>
>> Attached patch adds a musl section to doc/platform.
>
> This is counter-productive...
Sorry, I just wanted to be productive wrt a bug (actually
bugs) that we will not be able to fix
Hi,
On Sun, Oct 2, 2016 at 7:51 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch adds a musl section to doc/platform.
This is counter-productive... Let's work with the musl-devs and fix their
libc-alternative?
Ronald
___
ffmpeg-devel mailing lis
Hi!
Attached patch adds a musl section to doc/platform.
Please comment, Carl Eugen
From 35bf44b909658864c9e8cca8dbc855dbde1e1ef5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Mon, 3 Oct 2016 01:41:37 +0200
Subject: [PATCH] doc/platform: Mention musl where x86_32 is not supported.
---
d
On Sat, Oct 01, 2016 at 04:36:54PM -0300, James Almer wrote:
> On 10/1/2016 4:24 PM, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > tests/fate/ffmpeg.mak | 4 +
> > tests/ref/fate/psp| 287
> > ++
> > 2 files ch
will push aftet 24 hours
Steven Liu 于2016年9月26日 周一下午4:05写道：
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 03/10/2016 00:07, Timothy Gu wrote:
On Sun, Oct 02, 2016 at 02:53:22PM +0100, Josh de Kock wrote:
Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one
On 9/27/2016 3:03 PM, James Almer wrote:
> It's listed as supported in both https://www.webmproject.org/docs/container/
> and https://matroska.org/technical/specs/index.html
>
> Signed-off-by: James Almer
> ---
> libavformat/matroskaenc.c | 41 +
> 1 file
On 9/27/2016 8:49 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/matroskaenc.c | 53
> ++-
> 1 file changed, 34 insertions(+), 19 deletions(-)
Ping for patchset.
___
ffmpeg-devel ma
On Sun, Oct 02, 2016 at 02:53:22PM +0100, Josh de Kock wrote:
> Full width text is really difficult to read, this makes it more
> more legible on larger (widescreen) screens. It also means we aren't
> inventing our own container instead of using the bootstrap one.
>
> Signed-off-by: Josh de Kock
On Sun, Oct 02, 2016 at 11:16:49PM +0100, Josh de Kock wrote:
>
>
> On 02/10/2016 22:47, Michael Niedermayer wrote:
> >On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
> >>Explicitly state that FATE should pass, and code should work
> >>for all reviewers who tested.
[...]
> >>-@item
Hi,
On Sun, Oct 2, 2016 at 6:41 PM, Carl Eugen Hoyos wrote:
> 2016-10-02 14:29 GMT+02:00 Ronald S. Bultje :
> > I also think we could contact musl developers and see what's
> > going on there.
>
> I suspect I found the responsible code:
> http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc
2016-10-02 14:29 GMT+02:00 Ronald S. Bultje :
> I also think we could contact musl developers and see what's
> going on there.
I suspect I found the responsible code:
http://git.musl-libc.org/cgit/musl/tree/src/malloc/malloc.c#n114
Carl Eugen
___
ffmpeg
On 02/10/2016 22:47, Michael Niedermayer wrote:
On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
Explicitly state that FATE should pass, and code should work
for all reviewers who tested.
Signed-off-by: Josh de Kock
---
doc/developer.texi | 91 ++
Hi,
On Sun, Oct 2, 2016 at 4:24 PM, Carl Eugen Hoyos wrote:
> 2016-10-02 16:01 GMT+02:00 Carl Eugen Hoyos :
>
> > PS: There are several unrelated build issues.
>
> The build issues were just seen here because I
> had to add "-melf_i386" to the musl spec file.
> After adding it, building works pe
On Sun, Oct 02, 2016 at 01:51:41AM +0100, Josh de Kock wrote:
> Explicitly state that FATE should pass, and code should work
> for all reviewers who tested.
>
> Signed-off-by: Josh de Kock
> ---
> doc/developer.texi | 91
> ++
> 1 file changed
On 10/1/2016 9:51 PM, Josh de Kock wrote:
> Explicitly state that FATE should pass, and code should work
> for all reviewers who tested.
>
> Signed-off-by: Josh de Kock
> ---
> doc/developer.texi | 91
> ++
> 1 file changed, 44 insertions(+),
On Sun, Oct 2, 2016 at 11:08 PM, Timo Rothenpieler
wrote:
> ---
> libavcodec/cuvid.c | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
> index e9a1dd7..5ceb94e 100644
> --- a/libavcodec/cuvid.c
> +++ b/libavcodec/cuvi
Hello Carl Eugen,
On Sun, Oct 02, 2016 at 04:01:21PM +0200, Carl Eugen Hoyos wrote:
> > I do not expect that the ffmpeg developers take the trouble
> > to install an extra build environment with a different libc,
>
> (If I could just understand this sentence: Is it meant as
> an insult? How do yo
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1e487a..3570253 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ Other:
eval.c, eval.hMichael Niedermayer
float_dsp Loren Merri
---
libavcodec/cuvid.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/cuvid.c b/libavcodec/cuvid.c
index e9a1dd7..5ceb94e 100644
--- a/libavcodec/cuvid.c
+++ b/libavcodec/cuvid.c
@@ -451,25 +451,25 @@ static int cuvid_output_frame(AVCodecContext *av
---
libavutil/hwcontext_cuda.c | 35 ---
1 file changed, 20 insertions(+), 15 deletions(-)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 40d2971..e1dcab0 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@@ -25,6
On Sun, Oct 02, 2016 at 10:53:17PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> The functions in libavutil/x86/pixelutils.asm are exported
> to the library users if I understand the code correctly.
> I suspect it can be expected that the MMX state is reset
> after returning.
>
> Fixes the pixelutil
On Sun, Oct 2, 2016 at 10:53 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> The functions in libavutil/x86/pixelutils.asm are exported
> to the library users if I understand the code correctly.
> I suspect it can be expected that the MMX state is reset
> after returning.
>
> Fixes the pixelutils fate test
Hi!
The functions in libavutil/x86/pixelutils.asm are exported
to the library users if I understand the code correctly.
I suspect it can be expected that the MMX state is reset
after returning.
Fixes the pixelutils fate test with musl on x86-32.
Please comment, Carl Eugen
From f16831e6dc0f36c8
2016-10-02 16:01 GMT+02:00 Carl Eugen Hoyos :
> PS: There are several unrelated build issues.
The build issues were just seen here because I
had to add "-melf_i386" to the musl spec file.
After adding it, building works perfectly smooth.
I tested with --enable-debug for musl and still get
no bac
From ca69f377f019dc72e7f34020634b57e1e9c6a8d2 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino
Date: Sun, 2 Oct 2016 20:42:44 +0200
Subject: [PATCH] Fix warning due to misleading indendation in ivi_dsp.c line
592
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encodi
On Sun, Oct 02, 2016 at 05:58:30PM +0200, Adriano Pallavicino wrote:
>
> From 93fe2a96d71ac219915ade0a9247e1ae4b931a27 Mon Sep 17 00:00:00 2001
> From: Adriano Pallavicino
> Date: Sun, 2 Oct 2016 17:52:12 +0200
> Subject: [PATCH] =?UTF-8?q?Fix=20warning:=20this=20=E2=80=98if=E2=80=99=20?=
> =?U
Hi Adriano,
We appreciate the patches, but is it possible you could maybe collate
your cosmetic patches and send them as a larger set?
This patch LGTM though, will push tomorrow if no further comments.
--
Josh
___
ffmpeg-devel mailing list
ffmpeg-de
From 0a13315b4dd55ceb6da28fbbafa7d80b81d94794 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino
Date: Sun, 2 Oct 2016 20:27:23 +0200
Subject: [PATCH] Fix warning misleading indentation ivi_dsp.c line 552
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
l
On Sun, Oct 02, 2016 at 06:58:13PM +0200, Timo Rothenpieler wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Concerning the gods, I have no means of knowing whether they exist or not
or
On Sun, 2 Oct 2016 18:58:12 +0200
Timo Rothenpieler wrote:
> ---
> libavutil/hwcontext_cuda.c | 43
> --- 1 file changed, 28
> insertions(+), 15 deletions(-)
>
> diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
> index 40d2971..706d195
On Sun, 2 Oct 2016 18:58:13 +0200
Timo Rothenpieler wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index d1e487a..3570253 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -78,6 +78,7 @@ Other:
>eval.c, eval.h
---
Sorry but the first patch was improperly formatted.
According to this page
(http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/RIFF.html#Info) it is
possible
to add language information ("IAS1" (first language) to "IAS9" (ninth
language)) to RIFF tagged files (as RIFF Info Tags).
Progra
---
MAINTAINERS | 1 +
1 file changed, 1 insertion(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index d1e487a..3570253 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -78,6 +78,7 @@ Other:
eval.c, eval.hMichael Niedermayer
float_dsp Loren Merri
---
libavutil/hwcontext_cuda.c | 43 ---
1 file changed, 28 insertions(+), 15 deletions(-)
diff --git a/libavutil/hwcontext_cuda.c b/libavutil/hwcontext_cuda.c
index 40d2971..706d195 100644
--- a/libavutil/hwcontext_cuda.c
+++ b/libavutil/hwcontext_cuda.c
@
Some API users (in particular ffmpeg.c) check the best effort timestamp
only.
---
Still undecided if this is the right approach.
---
libavcodec/utils.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index ef3da65..1875a69 100644
--
On Sat, 1 Oct 2016 16:15:45 +0200
Hendrik Leppkes wrote:
> Decoders have previously not used AVFrame.pts, and with the upcoming
> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
> interpration of timestamps.
> ---
> ffmpeg.c | 7 +--
> 1 file changed, 1 insertion(
From 78821da34356c1700695f19923e4e8b130b96963 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino
Date: Sun, 2 Oct 2016 18:16:21 +0200
Subject: [PATCH] Fix warning: [-Wmisleading-indentation] bink.c
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
This is
On Sat, Oct 1, 2016 at 4:15 PM, Hendrik Leppkes wrote:
> Decoders have previously not used AVFrame.pts, and with the upcoming
> deprecation of pkt_pts (in favor of pts), this would lead to an errorneous
> interpration of timestamps.
> ---
> ffmpeg.c | 7 +--
> 1 file changed, 1 insertion(+),
You are welcome
2016-09-28 13:54 GMT+02:00 Josh de Kock :
> On 27/09/2016 23:11, Josh de Kock wrote:
>
>> On 27/09/2016 20:47, Adriano Pallavicino wrote:
>>
>>> Sure
>>>
>>> Adriano
>>>
>>>
>> This patch looks good to me, just going to give it a little time for
>> others to comment.
>>
>> Thanks,
On 09/29/2016 12:49 AM, sebechlebsky...@gmail.com wrote:
From: Jan Sebechlebsky
This commit also adds new diff option for fate tests allowing do compare
multiple tuples of files.
Signed-off-by: Jan Sebechlebsky
---
tests/Makefile| 1 +
tests/fate-run.sh
From 93fe2a96d71ac219915ade0a9247e1ae4b931a27 Mon Sep 17 00:00:00 2001
From: Adriano Pallavicino
Date: Sun, 2 Oct 2016 17:52:12 +0200
Subject: [PATCH] =?UTF-8?q?Fix=20warning:=20this=20=E2=80=98if=E2=80=99=20?=
=?UTF-8?q?clause=20does=20not=20guard...=20[-Wmisleading-indentation]?=
MIME-Version:
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
According to this page
(http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/RIFF.html#Info)
it is possible
to add language information ("IAS1" (first language) to "IAS9" (ninth
language)) to RIFF tagged files (as RIFF Info Tags).
Programs such as VLC media player or MediaInfo can properl
On Sat, 1 Oct 2016, Josh de Kock wrote:
On 01/10/2016 17:17, Marton Balint wrote:
Fixes ticket #5873.
Signed-off-by: Marton Balint
---
ffplay.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index e64909a..a7a6785 100644
--- a/ffplay.c
+++ b/ffp
2016-10-02 9:27 GMT+02:00 :
> I do not expect that the ffmpeg developers take the trouble
> to install an extra build environment with a different libc,
(If I could just understand this sentence: Is it meant as
an insult? How do you expect the issue to be fixed? By
looking at the code? Seriously
Full width text is really difficult to read, this makes it more
more legible on larger (widescreen) screens. It also means we aren't
inventing our own container instead of using the bootstrap one.
Signed-off-by: Josh de Kock
---
doc/t2h.init | 2 +-
doc/t2h.pm | 2 +-
2 files changed, 2 insert
Le primidi 11 vendémiaire, an CCXXV, Josh de Kock a écrit :
> Not really.
Absolutely.
> The containers should not change size depending on the font size.
The issue at hand is not about "containers" or whatever, it is about the
max-width property, in order, quoting yourself, to make things "more
On 02/10/2016 13:52, Nicolas George wrote:
Le primidi 11 vendémiaire, an CCXXV, Josh de Kock a écrit :
Using max-width: 960px is common practice,
Yet still bad practice.
Not really.
and since pixels are generally
not 1:1 but scaled with regard
Le primidi 11 vendémiaire, an CCXXV, Josh de Kock a écrit :
> Using max-width: 960px is common practice,
Yet still bad practice.
>and since pixels are generally
> not 1:1 but scaled with regards to DPI, rather than text-size it results in
> a more const
On 02/10/2016 08:24, Nicolas George wrote:
Le decadi 10 vendémiaire, an CCXXV, Josh de Kock a écrit :
Full width text is really difficult to read, this just makes it
slightly more legible on larger (widescreen) screens.
Signed-off-by: Josh de Kock
---
See http://screenshotcomparison.com/compar
Hi,
On Sun, Oct 2, 2016 at 2:17 AM, wrote:
> Hello Henrik,
>
> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> > Ensuring that emms is issued before every single libc function call is
> > likely problematic.
> >
> > What if we simply document the requirement that C standard lib
On Sun, 2 Oct 2016 02:25:30 +0200
Michael Niedermayer wrote:
> On Sun, Oct 02, 2016 at 01:18:29AM +0200, Henrik Gramner wrote:
> > Ensuring that emms is issued before every single libc function call is
> > likely problematic.
>
> maybe, maybe not, iam not sure but
> calling emms between init/d
On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> If all else fails we could add a emms call behind #if in
> av_malloc() and detect affected libcs but thats IMHO a ugly hack
> but better than declaring "non support"
Unfortunately I see an additional reason for avoiding such ki
Thanks Michael,
On Sun, Oct 02, 2016 at 02:25:30AM +0200, Michael Niedermayer wrote:
> beyond malloc() what else is there ?
>
> string functions ?
> these are in fact not unlikely to use SIMD of some sort
> same for memcpy/move()
>
> also there are callbacks like av_log() we should document any
As in this libhdcd commit: [0]
I don't have any legitimate 20 or 24-bit HDCD to test. It is known
that the PM Model Two would insert packets into 20 and 24-bit output,
but I have no idea what differences in behavior existed when decoding
20 or 24-bit. For now, as with 16-bit, PE (if enabled) will e
The buffer is already being copied anyway, so interlace the planar
format during the copy and remove one use of auto-convert.
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/a
According to the Users' Manual, the PM Model Two would encode
HDCD in any CD or DVD-Audio sampler rates, and at 16, 20, or
24-bit output. While HDCD was (afaik) only published on CD, and
therefor 16-bit@44100Hz, audio may exist in any other other formats
supported by the encoding equipment, so I'
New versions of hdcd_scan() and hdcd_integrate() that also do the
work of hdcd_scan_stereo() and hdcd_integrate_stereo().
Some code split into previously separate functions to remove
duplication is now merged back into each function in the single
place where it is used.
Signed-off-by: Burt P
---
The PM Model Two could output HDCD-encoded audio in CD and all
DVD-Audio sample rates. (44100, 48000, 88200, 96000, 176400, and
192000 Hz)
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavfilter/af_hdcd.c b/li
Signed-off-by: Burt P
---
libavfilter/af_hdcd.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavfilter/af_hdcd.c b/libavfilter/af_hdcd.c
index 90b6b64..6f35c09 100644
--- a/libavfilter/af_hdcd.c
+++ b/libavfilter/af_hdcd.c
@@ -1724,6 +1724,9 @@ static int query_format
Hello Carl Eugen,
On Sun, Oct 02, 2016 at 03:05:13AM +0200, Carl Eugen Hoyos wrote:
> 2016-10-01 19:48 GMT+02:00 :
> > I do not expect the ffmpeg developers to try to reproduce this.
>
> (Would you mind explaining this sentence to me? I
> do not understand it.)
I do not expect that the ffmpeg d
Le decadi 10 vendémiaire, an CCXXV, Josh de Kock a écrit :
> Full width text is really difficult to read, this just makes it
> slightly more legible on larger (widescreen) screens.
>
> Signed-off-by: Josh de Kock
> ---
> See http://screenshotcomparison.com/comparison/186256 for a comparison of
>
69 matches
Mail list logo
