On 02/26/2016 08:28 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Forget this
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Forget this one as well. Using AV_RL32() shouldn't be nee
Some demuxers can't handle Matroska compression, so this lets API users
check if a file uses it and determine whether those players will fail.
---
libavcodec/avcodec.h | 35 ++-
libavcodec/avpacket.c | 1 +
libavcodec/version.h | 2 +-
libavformat/ma
On 02/26/2016 07:09 AM, Mats Peterson wrote:
Michael, since before I started messing with the QuickTime palette, the
palette has usually been used in conjunction with AVI, which uses little
endian order of the entries (BGRA), here is a proposed patch that forces
little-endian order when storing t
On 02/26/2016 07:41 AM, Mats Peterson wrote:
Look at this snippet from libavformat/qtpalette.c that stores a palette
entry (palette[] is uint32_t):
palette[i] = (a << 24 ) | (r << 16) | (g << 8) | (b);
The way it is stored in memory is obviously dependent on the endianness
of the machine. For l
On 02/26/2016 06:40 AM, Mats Peterson wrote:
On 02/26/2016 06:24 AM, Mats Peterson wrote:
On 02/26/2016 05:26 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
Not that I understand why. I thought the palette was already in
"big
Michael, since before I started messing with the QuickTime palette, the
palette has usually been used in conjunction with AVI, which uses little
endian order of the entries (BGRA), here is a proposed patch that forces
little-endian order when storing the QuickTime palette, in case the
movenc.c
On 02/26/2016 06:24 AM, Mats Peterson wrote:
On 02/26/2016 05:26 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
Not that I understand why. I thought the palette was already in
"big-endian" order, with the A, R, G, B bytes in t
On 02/26/2016 05:26 AM, Mats Peterson wrote:
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
Not that I understand why. I thought the palette was already in
"big-endian" order, with the A, R, G, B bytes in that order, and that
the previous patch would r
On Thu, Feb 25, 2016 at 8:14 PM, Michael Niedermayer
wrote:
>
> also considering this is performance relevant code, please provide
> a benchmark
I'll be happy to provide a benchmark. I don't see the instructions for
running benchmarks in the patch submission checklist:
https://ffmpeg.org/develope
On 02/26/2016 05:08 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
Not that I understand why. I thought the palette was already in
"big-endian" order, with the A, R, G, B bytes in that order, and that
the previous patch would rather fail instead, so to say. But alright.
On Thu, Feb 25, 2016 at 04:42:22PM -0800, Wan-Teh Chang wrote:
> On Thu, Feb 25, 2016 at 4:15 PM, Hendrik Leppkes wrote:
> >
> > Similar to the other patch, please explain what this actually fixes,
> > those sanitizer tools produce a lot of false positives and nonsensical
> > warnings.
>
> Yes, c
Should hopefully fix the big-endian issue.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 750f7e27518aa7cc9fb37240ba33a024deaead34 Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Fri, 26 Feb 2016 05:07:28 +0100
Subject: [PATCH v28] lavf/movenc: Add palette to video sample description
On 02/26/2016 05:03 AM, Mats Peterson wrote:
Should hopefully fix the big-endian issue.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I'll do it in a somewhat more elegant way.
--
Mats Pet
Should hopefully fix the big-endian issue.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 534cf88e5e7540bcd3d93b57f559dfa82aaa5f7c Mon Sep 17 00:00:00 2001
From: Mats Peterson
Date: Fri, 26 Feb 2016 05:02:02 +0100
Subject: [PATCH v27] lavf/movenc: Add palette to video sample description
On Wed, Feb 24, 2016 at 12:51:45PM +0100, Mats Peterson wrote:
> 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
> movenc.c | 63
> +--
> mo
On 2/25/2016 11:32 PM, Wan-Teh Chang wrote:
> This is because the codec->decode() call in frame_worker_thread may be
> modifying that avctx at the same time. This data race is reported by
> ThreadSanitizer.
>
> Although submit_thread holds two locks simultaneously, it always
> acquires them in the
This is because the codec->decode() call in frame_worker_thread may be
modifying that avctx at the same time. This data race is reported by
ThreadSanitizer.
Although submit_thread holds two locks simultaneously, it always
acquires them in the same order because |prev_thread| is always the
array el
Although not documented, |state| is guarded by either |mutex| or
|progress_mutex|. In several places |state| is read without mutex
protection, often as a double-checked locking style performance
optimization. Fix the data races by reading |state| under mutex
protection.
---
libavcodec/pthread_fram
On Fri, Feb 26, 2016 at 12:15:19AM +0100, Reimar Döffinger wrote:
> We do neither document nor check such a requirement
> and for application-provided get_buffer2 they could
> contain the result of a malloc(0) or whatever value
> they had previously.
> This fixes a use-after-free in e.g. MPlayer:
>
Hi Ronald,
On Thu, Feb 25, 2016 at 12:00 PM, Ronald S. Bultje wrote:
>
> But does it fix an actual bug? (Is there a sample this fixes?)
I assume you agree that reading and writing the non-atomic int |die|
flag without mutex protection is a data race. Code inspection verifies
libavcodec/pthread_f
On Thu, Feb 25, 2016 at 07:02:31PM +0100, Stefano Sabatini wrote:
> On date Thursday 2016-02-25 13:41:02 +0100, Michael Niedermayer encoded:
> > On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
> [...]
> > > So, while the check makes sense for audio and video, in the case of
> > >
On Thu, Feb 25, 2016 at 4:15 PM, Hendrik Leppkes wrote:
>
> Similar to the other patch, please explain what this actually fixes,
> those sanitizer tools produce a lot of false positives and nonsensical
> warnings.
Yes, certainly.
In libavcodec/pthread_frame.c, we have:
46 /**
47 * Context us
On Fri, Feb 26, 2016 at 1:06 AM, Wan-Teh Chang
wrote:
> This fixes data race warnings by ThreadSanitizer.
> ff_thread_report_progress and ff_thread_await_progress should read
> progress[field] only when holding progress_mutex because progress_mutex
> guards frame progress values.
Similar to the o
This fixes data race warnings by ThreadSanitizer.
ff_thread_report_progress and ff_thread_await_progress should read
progress[field] only when holding progress_mutex because progress_mutex
guards frame progress values.
---
libavcodec/pthread_frame.c | 10 ++
1 file changed, 6 insertions(+)
We do neither document nor check such a requirement
and for application-provided get_buffer2 they could
contain the result of a malloc(0) or whatever value
they had previously.
This fixes a use-after-free in e.g. MPlayer:
https://trac.mplayerhq.hu/ticket/2262
We might want to consider changing the
On Thu, Feb 25, 2016 at 11:27:21PM +0100, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes the sample Clément kindly provided:
> http://lucy.pkh.me/samples/img.jpg?foo=bar
>
> Please comment, Carl Eugen
> img2dec.c |1 +
> 1 file changed, 1 insertion(+)
> 52bcdf49dd6f17c381cf1210bb70e
Give me a few weeks, I have a day job and a son in the weekends, but would
be happy to work together on it!
2016-02-26 0:11 GMT+01:00 Paul B Mahol :
> Dana 25. 2. 2016. 23:43 osoba "F.Sluiter" napisala
> je:
> >
> > I am not considering a format change (yet), maybe I wasn't clear enough
> on
> >
Dana 25. 2. 2016. 23:43 osoba "F.Sluiter" napisala je:
>
> I am not considering a format change (yet), maybe I wasn't clear enough on
> how this filter would work.
> Displace works now with a image stream and two in puts, x_displacement,
> y_dispacement. x and y are relative so they are added to t
So not color mapping (that would be another awesome filter indeed) but
location mapping
2016-02-25 23:42 GMT+01:00 F.Sluiter :
> I am not considering a format change (yet), maybe I wasn't clear enough on
> how this filter would work.
> Displace works now with a image stream and two in puts, x
I am not considering a format change (yet), maybe I wasn't clear enough on
how this filter would work.
Displace works now with a image stream and two in puts, x_displacement,
y_dispacement. x and y are relative so they are added to the x,y location
of the source pixel. the pixel x,y currently bein
On Thu, 25 Feb 2016, wm4 wrote:
On Thu, 25 Feb 2016 02:11:00 +0100
Marton Balint wrote:
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 m
Clément Bœsch pkh.me> writes:
> http://lucy.pkh.me/samples/img.jpg?foo=bar
Patch sent.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi!
Attached patch fixes the sample Clément kindly provided:
http://lucy.pkh.me/samples/img.jpg?foo=bar
Please comment, Carl Eugen
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index a755b6f..ce40aa5 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -706,6 +706,7 @@ s
On 2/25/16, F.Sluiter wrote:
> Could you actually be more specific, what would be needed for 16bit
> support? I was naively thinking to just a binary copy from source pixel to
> target for starters.
For example, first input is 8bit depth and 2nd and 3rd are 16bit depth
so remap works for > 256 di
Could you actually be more specific, what would be needed for 16bit
support? I was naively thinking to just a binary copy from source pixel to
target for starters.
2016-02-25 22:40 GMT+01:00 F.Sluiter :
> It would also be relatively easy to implement anti-aliasing (probably in
> version 2).
>
>
On Thu, Feb 25, 2016 at 09:25:08PM +0100, wm4 wrote:
> On Thu, 25 Feb 2016 21:06:46 +0100
> Reimar Döffinger wrote:
>
> > Reported as https://trac.mplayerhq.hu/ticket/2264 but have
> > not been able to reproduce with FFmpeg-only.
> > I have no idea what coded_height is used for here exactly,
> >
It would also be relatively easy to implement anti-aliasing (probably in
version 2).
2016-02-25 22:38 GMT+01:00 Paul B Mahol :
> On 2/25/16, F.Sluiter wrote:
> > If it doesn exist I would like to develop a new filter and would like to
> > check if nobody is already working on it or that it exist
On Thu, Feb 25, 2016 at 10:37:40PM +0100, Clément Bœsch wrote:
> On Thu, Feb 25, 2016 at 10:35:39PM +0100, Clément Bœsch wrote:
> > On Thu, Feb 25, 2016 at 04:30:13PM +, Carl Eugen Hoyos wrote:
> > > Justin Ruggles writes:
> > >
> > > > In terms of how the score for a MIME type match compares
On 2/25/16, F.Sluiter wrote:
> If it doesn exist I would like to develop a new filter and would like to
> check if nobody is already working on it or that it exists under a
> different name.
>
> I have been researching the following usecase:
>
> Similar tot the displace filter, I would need a filt
On Thu, Feb 25, 2016 at 10:35:39PM +0100, Clément Bœsch wrote:
> On Thu, Feb 25, 2016 at 04:30:13PM +, Carl Eugen Hoyos wrote:
> > Justin Ruggles writes:
> >
> > > In terms of how the score for a MIME type match compares with
> > > those of the individual content matching probe functions, I'd
On Thu, Feb 25, 2016 at 04:30:13PM +, Carl Eugen Hoyos wrote:
> Justin Ruggles writes:
>
> > In terms of how the score for a MIME type match compares with
> > those of the individual content matching probe functions, I'd
> > say it makes sense. The stronger probing functions have a
> > scor
If it doesn exist I would like to develop a new filter and would like to
check if nobody is already working on it or that it exists under a
different name.
I have been researching the following usecase:
Similar tot the displace filter, I would need a filter to remap pixels (the
difference being t
On Thu, Feb 25, 2016 at 04:09:34PM +, Josh de Kock wrote:
> On 25/02/2016 15:53, Nicolas George wrote:
> >Le septidi 7 ventôse, an CCXXIV, Josh de Kock a écrit :
> >>Just thought it wouldn't hurt to fix the real problem--that libdispatch
> >>isn't being checked for correctly, rather than a quic
On Wed, Feb 24, 2016 at 05:26:57PM +0100, Michael Niedermayer wrote:
> 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
Pushed. Thanks.
[...]
_
On Thu, 25 Feb 2016 21:06:46 +0100
Reimar Döffinger wrote:
> Reported as https://trac.mplayerhq.hu/ticket/2264 but have
> not been able to reproduce with FFmpeg-only.
> I have no idea what coded_height is used for here exactly,
> so this might not be the best fix.
> Fixes the following chain of e
Reported as https://trac.mplayerhq.hu/ticket/2264 but have
not been able to reproduce with FFmpeg-only.
I have no idea what coded_height is used for here exactly,
so this might not be the best fix.
Fixes the following chain of events:
ff_mss12_decode_init sets coded_height while not setting height.
Hi,
On Thu, Feb 25, 2016 at 2:51 PM, Wan-Teh Chang wrote:
> This fixes a data race warning by ThreadSanitizer.
But does it fix an actual bug? (Is there a sample this fixes?)
If anything, you can use atomic ints instead of regular ints if we don't
already [1].
Ronald
[1] https://ffmpeg.org/d
This fixes a data race warning by ThreadSanitizer.
FrameThreadContext.die is read by all the worker threads but is not
protected by any mutex. Move it to PerThreadContext so that each worker
thread reads its own copy of |die|, which can then be protected with
PerThreadContext.mutex.
---
libavcodec
Signed-off-by: Michael Niedermayer
---
libavformat/format.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/format.c b/libavformat/format.c
index 15fe167..7fa06a6 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -223,8 +223,12 @@ AVInputFo
On Wed, Feb 24, 2016 at 09:20:11PM -0500, Ganesh Ajjanagadde wrote:
> 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 in
On date Thursday 2016-02-25 13:41:02 +0100, Michael Niedermayer encoded:
> On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
[...]
> > So, while the check makes sense for audio and video, in the case of
> > subtitles and data we are in the fuzzy area. In principle, I agree
> > with
On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> If this cannot be fixed differently, we should either increase
> the score for the existing 32bit probe functions or reduce the
> score for mime types before this gets applied. Several probe
> functions (outside of img2dec.c) return MAX for 32 bits
On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
Replies are mine.
>> In terms of how the score for a MIME type match compares with
>> those of the individual content matching probe functions, I'd
>> say it makes sense. The stronger probing functions have a
>> score which reflects their reliabili
Carl Eugen Hoyos ag.or.at> writes:
> 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.
The patch was merged by Derek.
Carl Eugen
__
Justin Ruggles writes:
> In terms of how the score for a MIME type match compares with
> those of the individual content matching probe functions, I'd
> say it makes sense. The stronger probing functions have a
> score which reflects their reliability.
But even _EXTENSION + 1 is correct in pra
On 25/02/2016 15:53, Nicolas George wrote:
Le septidi 7 ventôse, an CCXXIV, Josh de Kock a écrit :
Just thought it wouldn't hurt to fix the real problem--that libdispatch
isn't being checked for correctly, rather than a quick fix. Either is fine,
I guess, although the quick fix would just requir
On 2/24/2016 3:19 PM, Carl Eugen Hoyos wrote:
> (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 provides a score of _EXTENSION (50), so if probing
> is possible and
Le septidi 7 ventôse, an CCXXIV, Josh de Kock a écrit :
> Just thought it wouldn't hurt to fix the real problem--that libdispatch
> isn't being checked for correctly, rather than a quick fix. Either is fine,
> I guess, although the quick fix would just require another patch, as I
> previously state
On 25/02/2016 15:44, Clément Bœsch wrote:
On Thu, Feb 25, 2016 at 03:34:37PM +, Josh de Kock wrote:
On 25/02/2016 14:00, Matthieu Bouron wrote:
From: Matthieu Bouron
Fixes build of lavd/jack on linux if dispatch happens to be available on
this platform. dispatch, as well as its dependenci
On Thu, Feb 25, 2016 at 03:34:37PM +, Josh de Kock wrote:
> On 25/02/2016 14:00, Matthieu Bouron wrote:
> >From: Matthieu Bouron
> >
> >Fixes build of lavd/jack on linux if dispatch happens to be available on
> >this platform. dispatch, as well as its dependencies kqueue and pwq are
> >general
On 25/02/2016 14:00, Matthieu Bouron wrote:
From: Matthieu Bouron
Fixes build of lavd/jack on linux if dispatch happens to be available on
this platform. dispatch, as well as its dependencies kqueue and pwq are
generally not installed / distribued on linux systems. If it happens to
be the case,
From: Matthieu Bouron
Fixes build of lavd/jack on linux if dispatch happens to be available on
this platform. dispatch, as well as its dependencies kqueue and pwq are
generally not installed / distribued on linux systems. If it happens to
be the case, you want to explicitely link against the libr
On Thu, Feb 25, 2016 at 02:47:45PM +0100, Hendrik Leppkes wrote:
> On Thu, Feb 25, 2016 at 2:35 PM, Clément Bœsch wrote:
> > From: Clément Bœsch
> >
> > This option is typically useful when cross-compiling dynamic libraries
> > for iOS, with something such as --install_name_dir=@rpath
>
> I don'
On 2/25/2016 2:20 AM, Ganesh Ajjanagadde wrote:
> -// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64
> +// (int64_t)rint() and llrint() do not work with gcc on ia64 and sparc64,
> +// see Ticket2713 for affected gcc/glibc versions
I've never seen this comment bef
On Thu, Feb 25, 2016 at 8:27 AM, wm4 wrote:
> 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
On Thu, Feb 25, 2016 at 2:35 PM, Clément Bœsch wrote:
> From: Clément Bœsch
>
> This option is typically useful when cross-compiling dynamic libraries
> for iOS, with something such as --install_name_dir=@rpath
I don't know about any other things and their options for iOS
building, but that opti
On 2/25/2016 7:27 AM, wm4 wrote:
> They also make code ugly as fuck, and are more cargo-cult than anything
> else. They might possibly be ok in some very critical parts of the
> code, but otherwise not at all.
+1 to this.
I will absolutely *not* ACK any patch sets that start littering likely/unli
From: Clément Bœsch
This option is typically useful when cross-compiling dynamic libraries
for iOS, with something such as --install_name_dir=@rpath
---
configure | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 8436b09..64750e4 100755
--- a/co
On Thu, Feb 25, 2016 at 01:11:36PM +0100, Stefano Sabatini wrote:
> On date Tuesday 2016-02-23 20:32:23 +0100, Michael Niedermayer encoded:
> > On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote:
> [...]
> > > > I have an use case with data packets that have the same PTS (which
> > >
Michael Niedermayer niedermayer.cc> writes:
> On Wed, Feb 24, 2016 at 06:52:13PM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #5267 for me.
> LGTM
Pushed with show_bits_long() to show the content more
clearly.
Carl Eugen
Le sextidi 6 ventôse, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Actual performance benefit is impossible to accurately quantify due to the
> context-dependence of the branch predictor. Nonetheless, as a ballpark
> estimate, it yields ~ 5% improvements in testing via FATE on x86-64,
> Haswell+GCC.
Le septidi 7 ventôse, an CCXXIV, Stefano Sabatini a écrit :
> As for subtitles, I'm not sure we should accept that as well, but at
> least in theory I can imagine an use case with multiple packets (and
> thus frames) conveying text information pertaining to the same time
> and stream.
Simultaneous
On date Tuesday 2016-02-23 20:32:23 +0100, Michael Niedermayer encoded:
> On Tue, Feb 23, 2016 at 07:34:16PM +0100, Stefano Sabatini wrote:
[...]
> > > I have an use case with data packets that have the same PTS (which
> > > makes sense in that specific case). Since I want to fix this issue,
> > >
Hi,
patch attached.
From 79bae07c716341eb4215c3b61b02c93ff7a9f6ec Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 23 Feb 2016 22:41:07 +0100
Subject: [PATCH] avfilter: add datascope filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 37 +
libavfilter/Makefile
On Thu, 25 Feb 2016 02:11:00 +0100
Marton Balint wrote:
> 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.
>
> Sig
76 matches
Mail list logo
