On Thu, Feb 25, 2016 at 09:41:11PM +0100, Matthieu Bouron wrote:
> 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--t
Michael Niedermayer niedermayer.cc> writes:
> > case 0xC1:
> > case 0xC2:
> > case 0xC3:
> > +i += AV_RB16(&b[i + 2]) + 1;
> > case 0xC5:
> > case 0xC6:
> > case 0xC7:
>
> shouldnt this also be done for these 3?
Done, I used the
On date Friday 2016-02-26 01:52:47 +0100, Michael Niedermayer encoded:
> On Thu, Feb 25, 2016 at 07:02:31PM +0100, Stefano Sabatini wrote:
[...]
> > From 0996189555f4a2402b396801da318b4ffcfb1a13 Mon Sep 17 00:00:00 2001
> > From: Stefano Sabatini
> > Date: Thu, 17 Dec 2015 20:51:42 +0100
> > Subje
On Thu, 25 Feb 2016 22:39:51 +0100
Reimar Döffinger wrote:
> 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 FFmpe
On Fri, 26 Feb 2016 02:38:13 +0100
Michael Niedermayer wrote:
> 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
On 26.02.2016, at 02:38, Michael Niedermayer wrote:
> 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
On Fri, 26 Feb 2016 05:14:47 +0100
Michael Niedermayer wrote:
> 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
On Fri, Feb 26, 2016 at 11:35 AM, Reimar Döffinger
wrote:
> On 26.02.2016, at 02:38, Michael Niedermayer wrote:
>
>> 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
>>
On 26.02.2016, at 11:42, Hendrik Leppkes wrote:
> On Fri, Feb 26, 2016 at 11:35 AM, Reimar Döffinger
> wrote:
>> On 26.02.2016, at 02:38, Michael Niedermayer wrote:
>>
>>> On Fri, Feb 26, 2016 at 12:15:19AM +0100, Reimar Döffinger wrote:
We do neither document nor check such a requirement
Hi,
> > And check also this:
> >
> > http://www.randelshofer.ch/animapplet/
> >
> > public class ANIMDeltaFrame
> > extends ANIMFrame {
> >
> > private int leftBound, topBound, rightBound, bottomBound;
> > private final static int //
> > ENCODING_BYTE_VERTICAL = 5,
> > ENCODING_VERTICAL_7_SHORT =
On Fri, Feb 26, 2016 at 11:29:05AM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 02:38:13 +0100
> Michael Niedermayer wrote:
>
> > 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 t
Am 25.02.16 um 22:24 schrieb F.Sluiter:
> 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
On 2/26/16, Thilo Borgmann wrote:
> Am 25.02.16 um 22:24 schrieb F.Sluiter:
>> 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:
>>
>
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..f8dee50 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -656,8 +656,8 @@ static int video_get_buf
This should return an error to the decoder if the struct it tried to getbuffer
is dirty
Signed-off-by: Michael Niedermayer
---
libavcodec/utils.c |5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index f8dee50..c7798e6 100644
--- a/libavcodec/ut
On Fri, 26 Feb 2016 12:19:18 +0100
Reimar Döffinger wrote:
> On 26.02.2016, at 11:42, Hendrik Leppkes wrote:
>
> > On Fri, Feb 26, 2016 at 11:35 AM, Reimar Döffinger
> > wrote:
> >> On 26.02.2016, at 02:38, Michael Niedermayer
> >> wrote:
> >>
> >>> On Fri, Feb 26, 2016 at 12:15:19AM +0
On Fri, Feb 26, 2016 at 12:40:19PM +0100, Clément Bœsch wrote:
> On Fri, Feb 26, 2016 at 11:29:05AM +0100, wm4 wrote:
> > Unfortunately I have to agree. I got some crashes in libavfilter when I
> > didn't set some "unused" plane pointers to NULL. Some code is just lazy
> > and checks plane pointers
On Fri, Feb 26, 2016 at 12:59:08PM +0100, Michael Niedermayer wrote:
> This should return an error to the decoder if the struct it tried to
> getbuffer is dirty
It seems like a good idea, however it likely won't help
for programs providing their own getbuffer2 as they will
probably fill the data[
On 02/26/2016 08:34 AM, Mats Peterson wrote:
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.or
Well, there I go, doing my own idle discussions
I just complained about ;)
On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 12:19:18 +0100
> Reimar Döffinger wrote:
> > I am not exactly sure what their opinion is to be honest.
> > However this attitude of "it's of course
On 26.02.2016, at 11:26, wm4 wrote:
> On Thu, 25 Feb 2016 22:39:51 +0100
> Reimar Döffinger wrote:
>
>> 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
>
On 02/26/2016 01:16 PM, Mats Peterson wrote:
On 02/26/2016 08:34 AM, Mats Peterson wrote:
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
On Fri, Feb 26, 2016 at 01:17:29PM +0100, Reimar Döffinger wrote:
> Well, there I go, doing my own idle discussions
> I just complained about ;)
>
> On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
> > On Fri, 26 Feb 2016 12:19:18 +0100
> > Reimar Döffinger wrote:
> > > I am not exactly sure
On 26.02.2016, at 14:01, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 01:17:29PM +0100, Reimar Döffinger wrote:
>> Well, there I go, doing my own idle discussions
>> I just complained about ;)
>>
>> On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
>>> On Fri, 26 Feb 2016 12:19:18 +01
On Thu, Feb 25, 2016 at 04:35:37AM +0100, Michael Niedermayer wrote:
[...]
> can you change the link for FFmpeg on
> https://wiki.gnome.org/action/login/Outreachy/2016/MayAugust
> to point to our outreachy page
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/Outreachy/2016-05
> currently it point
On Fri, Feb 26, 2016 at 02:20:33PM +0100, Reimar Döffinger wrote:
> On 26.02.2016, at 14:01, Michael Niedermayer wrote:
>
> > On Fri, Feb 26, 2016 at 01:17:29PM +0100, Reimar Döffinger wrote:
> >> Well, there I go, doing my own idle discussions
> >> I just complained about ;)
> >>
> >> On Fri, F
On 02/26/2016 01:46 PM, Mats Peterson wrote:
On 02/26/2016 01:16 PM, Mats Peterson wrote:
On 02/26/2016 08:34 AM, Mats Peterson wrote:
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.
__
On Fri, 26 Feb 2016 13:17:29 +0100
Reimar Döffinger wrote:
> Well, there I go, doing my own idle discussions
> I just complained about ;)
>
> On Fri, Feb 26, 2016 at 01:00:23PM +0100, wm4 wrote:
> > On Fri, 26 Feb 2016 12:19:18 +0100
> > Reimar Döffinger wrote:
> > > I am not exactly sure wha
On 02/24/2016 06:16 PM, Mats Peterson wrote:
The QuickTime palette was incorrectly stored in the MatroskaDemuxContext
instead of a MatroskaTrack.
ping
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpe
Derek Buitenhuis gmail.com> writes:
> On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> >> 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 wh
On 2/26/2016 2:44 PM, Carl Eugen Hoyos wrote:
> Derek Buitenhuis gmail.com> writes:
>
>> On 2/25/2016 4:30 PM, Carl Eugen Hoyos wrote:
> You misunderstand:
> Most "imageauto" demuxers return a score of 51. In all cases
> when 51 is returned, the detection is nearly certain. Your
> patch disable
Derek Buitenhuis gmail.com> writes:
> I'm saying scoring should be as such:
>
> 1) Probing the file file itself: Highest score.
> 2) Mime-type: Medium score.
There is no format except jpeg where this ever
can fix an issue.
Or in other words: Except for jpeg, there is no
probe function that r
I should be on the twitter chat (@kierank_) on the Monday.
Kieran
From: Marina Zhurakhinskaya
To: Michael Niedermayer
Cc: FFmpeg development discussions and patches ;
outreachy-admins ; o...@ffmpeg.org
Sent: Friday, 26 February 2016, 14:05
Subject: Re: [FFmpeg-devel] FFmpeg in Outreach
On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> configure | 5 +
> libavcodec/Makefile | 2 +
> libavcodec/ffjni.c | 480
>
> libavcodec/ffjni.h | 147
> 4 fi
On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> On Tue, 23 Feb 2016 09:53:43 +0100
> Matthieu Bouron wrote:
>
> > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer wrote:
> > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron wrote:
> > > > From: Matthieu Bouron
>
Matthieu Bouron gmail.com> writes:
> Patch updated
> + --enable-mediacodec enable Android MediaCodec support [no]
> +enabled mediacodec&& { enabled jni || die
Sorry if you have already explained:
Why are two separate enable-options necessary?
How is jni useful without mediacodec?
Dana 26. 2. 2016. 12:29 osoba "Piotr Bandurski" napisala
je:
>
> Hi,
>
> > > And check also this:
> > >
> > > http://www.randelshofer.ch/animapplet/
> > >
> > > public class ANIMDeltaFrame
> > > extends ANIMFrame {
> > >
> > > private int leftBound, topBound, rightBound, bottomBound;
> > > private
On Fri, Feb 26, 2016 at 5:02 PM, Carl Eugen Hoyos wrote:
> Matthieu Bouron gmail.com> writes:
>
> > Patch updated
>
> > + --enable-mediacodec enable Android MediaCodec support [no]
>
> > +enabled mediacodec&& { enabled jni || die
>
> Sorry if you have already explained:
> Why are t
On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron
wrote:
> On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
>
[...]
>
> Patch updated with the following differences:
> * fix of switch/case code style
> * removal of a miss declaration of FFJNIFi
- Original Message -
> From: "Michael Niedermayer"
> To: "FFmpeg development discussions and patches"
> Cc: "outreachy-admins" , o...@ffmpeg.org
> Sent: Friday, February 26, 2016 8:29:19 AM
> Subject: Re: [FFmpeg-devel] FFmpeg in Outreachy Round 12
>
> On Thu, Feb 25, 2016 at 04:35:37AM
Fixes large amounts of seeking past EOF, which could be extremely
slow over a network.
Signed-off-by: Derek Buitenhuis
---
Example of the problem:
ffmpeg -f mp3 -i http://chromashift.org/skyfire.ico
This problem was exacerbated even more by the fact that libavformat
tends to identify EVERYTH
On 2/26/2016 5:14 PM, Derek Buitenhuis wrote:
> +ret = avio_read(pb, &header_buf[0], 4);
> +if (ret <= 0)
> +return CHECK_SEEK_FAILED;
This check should be <, not <=.
Changed locally.
- Derek
___
ffmpeg-devel mailing list
ffmpeg-devel@f
On Fri, 26 Feb 2016 17:14:24 +
Derek Buitenhuis wrote:
> Fixes large amounts of seeking past EOF, which could be extremely
> slow over a network.
>
> Signed-off-by: Derek Buitenhuis
> ---
> Example of the problem:
> ffmpeg -f mp3 -i http://chromashift.org/skyfire.ico
>
> This problem w
On 2/26/2016 5:30 PM, wm4 wrote:
> The ffio_ensure_seekback() checks are probably unnecessary.
I can remove them if you prefer. Should I?
> Seems a bit verbose, but ok.
I added the av_log stuff because otherwise you just get "Invalid Argument"
from the ffmpeg cli, with no other explanation.
- D
On 2/26/2016 3:05 PM, Carl Eugen Hoyos wrote:
> Or in other words: Except for jpeg, there is no
> probe function that returns 0 although the decoder
> can decode the image.
I'll take your word for it on this part.
> So please provide your failing jpeg cases to
> improve the probing.
> I will p
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 15 +++
libavutil/frame.h | 3 +++
2 files changed, 18 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..56c8d7c 100644
--- a/
On Fri, 26 Feb 2016 17:32:36 +
Derek Buitenhuis wrote:
> On 2/26/2016 5:30 PM, wm4 wrote:
> > The ffio_ensure_seekback() checks are probably unnecessary.
>
> I can remove them if you prefer. Should I?
I'd vote yet, but that's just my personal opinion.
> > Seems a bit verbose, but ok.
>
On 2/26/2016 5:42 PM, Reimar Döffinger wrote:
> +av_assert0(frame->format == avctx->pix_fmt);
Is this valid? Mid-stream colorspace changes are fairly common.
- erek
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/
On Thu, Feb 25, 2016 at 03:13:07AM +0100, Michael Niedermayer wrote:
> 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
Hi,
On Tue, Feb 23, 2016 at 7:55 AM, Ronald S. Bultje
wrote:
> Fixes ticket 4313.
> ---
> ffmpeg.c| 3 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/vp9_superframe_bsf.c | 189
>
Hi,
On Thu, Feb 25, 2016 at 8:26 PM, Wan-Teh Chang wrote:
> On Thu, Feb 25, 2016 at 12:00 PM, Ronald S. Bultje
> wrote:
> If anything, you can use atomic ints instead of regular ints if we don't
>
> already [1].
> >
> [...]
> > [1] https://ffmpeg.org/doxygen/trunk/atomic_8h_source.html
>
> Tha
Hi,
On Thu, Feb 25, 2016 at 9:18 PM, Wan-Teh Chang wrote:
> 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
Hi,
On Thu, Feb 25, 2016 at 9: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
> acqu
Hi,
On Fri, Feb 26, 2016 at 3:26 PM, Ronald S. Bultje
wrote:
> Hi,
>
> On Thu, Feb 25, 2016 at 9:32 PM, Wan-Teh Chang <
> wtc-at-google@ffmpeg.org> 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 r
On Sun, Feb 21, 2016 at 01:08:28PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/Makefile | 4 ++--
> libavcodec/assdec.c | 60
> +++-
> libavcodec/assenc.c | 14 ++--
> libavformat/assenc.c | 14
> libavformat/nut.c|
On Thu, Feb 25, 2016 at 02:10:15AM +0100, Michael Niedermayer wrote:
> 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:
> > > [...]
> > > > dif
On Sun, Feb 21, 2016 at 01:08:30PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/ass.c | 3 ++-
> libavcodec/avcodec.h | 4
> libavcodec/ccaption_dec.c| 3 ++-
> libavcodec/libzvbi-teletextdec.c | 3 ++-
> libavcodec/movtextdec.c | 3 ++-
> libavc
On Sun, Feb 21, 2016 at 01:08:32PM +0100, Clément Bœsch wrote:
> ---
> libavfilter/vf_subtitles.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index 63b22c3..9e55002 100644
> --- a/libavfilter/vf_subti
On Sun, Feb 21, 2016 at 01:08:31PM +0100, Clément Bœsch wrote:
> ---
> ffmpeg.c | 2 ++
> tests/ref/fate/sub-charenc | 2 +-
> tests/ref/fate/sub-textenc | 66
> ++--
> tests/ref/fate/sub-webvttenc | 66
> ++---
On Sun, Feb 21, 2016 at 01:08:33PM +0100, Clément Bœsch wrote:
> ---
> libavcodec/assenc.c| 2 ++
> libavcodec/avcodec.h | 2 ++
> libavcodec/movtextenc.c| 7 ++-
> libavcodec/options_table.h | 6 ++
> libavcodec/srtenc.c| 7 ++-
> libavcodec/utils.c |
On Tue, Feb 23, 2016 at 07:55:37AM -0500, Ronald S. Bultje wrote:
> Fixes ticket 4313.
> ---
> ffmpeg.c| 3 +
> libavcodec/Makefile | 1 +
> libavcodec/allcodecs.c | 1 +
> libavcodec/vp9_superframe_bsf.c | 189
> +
On Thu, Feb 25, 2016 at 08:59:39PM -0800, Wan-Teh Chang wrote:
> 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
> ru
On Fri, Feb 26, 2016 at 12:44 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Fri, Feb 26, 2016 at 3:26 PM, Ronald S. Bultje
> wrote:
>
>>
>> So doesn't this patch remove all concurrency by making the decode() of
>> thread N-1 finish before decode() of thread N can start? More practically,
>> what is th
Hi,
On Fri, Feb 26, 2016 at 4:12 PM, Wan-Teh Chang wrote:
> On Fri, Feb 26, 2016 at 12:44 PM, Ronald S. Bultje
> wrote:
> > Hi,
> >
> > On Fri, Feb 26, 2016 at 3:26 PM, Ronald S. Bultje
> > wrote:
> >
> >>
> >> So doesn't this patch remove all concurrency by making the decode() of
> >> thread
Hi,
On Fri, Feb 26, 2016 at 5:30 AM, wm4 wrote:
> I don't know about this case, but the frame threading code uses
> improper double-checked logging. Basically it doesn't use proper
> barrier or atomics, assumes x86 semantics, and hopes the compiler won't
> get into the way.
In that case, it sh
On Fri, Feb 26, 2016 at 06:13:04PM +, Derek Buitenhuis wrote:
> On 2/26/2016 5:42 PM, Reimar Döffinger wrote:
> > +av_assert0(frame->format == avctx->pix_fmt);
>
> Is this valid? Mid-stream colorspace changes are fairly common.
I believed we enforce a sequence point (i.e. we make sure
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 14 ++
libavutil/frame.h | 3 +++
2 files changed, 17 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..af5ff93 100644
--- a/l
It makes easier looking at the difference with the generic code just
below.
---
libswscale/yuv2rgb.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index 9d79d79..62abb7d 100644
--- a/libswscale/yuv2rgb.c
+++ b/libswscal
---
libswscale/yuv2rgb.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index 3671fe3..9d79d79 100644
--- a/libswscale/yuv2rgb.c
+++ b/libswscale/yuv2rgb.c
@@ -824,18 +824,18 @@ av_cold int ff_yuv2rgb_c_init_ta
On Fri, 26 Feb 2016 22:25:21 +0100
Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavcodec/utils.c | 14 ++
> libavutil/frame.h | 3 +++
> 2 files changed, 17 insertions(+)
>
> diff --gi
On Wed, Feb 24, 2016 at 09:20:11AM +0100, Clément Bœsch wrote:
> 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 els
On Fri, Feb 26, 2016 at 06:24:17AM +0100, 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" or
On Fri, Feb 26, 2016 at 08:00:58AM +0100, Mats Peterson wrote:
> 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 wa
On Fri, Feb 26, 2016 at 10:39:41PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 22:25:21 +0100
> Reimar Döffinger wrote:
>
> > Check that the required plane pointers and only
> > those are set up.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavcodec/utils.c | 14 ++
> > libavu
Check that the required plane pointers and only
those are set up.
Signed-off-by: Reimar Döffinger
---
libavcodec/utils.c | 20
libavutil/frame.h | 3 +++
2 files changed, 23 insertions(+)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..1b6397c 100644
-
Michael Niedermayer skrev: (26 februari 2016 22:53:00
CET)
>On Fri, Feb 26, 2016 at 06:24:17AM +0100, 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 und
Hi all,
this is my first message ever to the ffmpeg mailing list, so please forgive me
any noob
mistakes.
I’m currently working on a little project which uses ffmpeg to live transcode
video files for
streaming to a web browser.
Basically it’s like Plex just at a very early stage. For streaming
Michael Niedermayer skrev: (26 februari 2016 22:56:42
CET)
>On Fri, Feb 26, 2016 at 08:00:58AM +0100, Mats Peterson wrote:
>> 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):
>> >>
>> >>p
Mats Peterson skrev: (26 februari 2016
23:21:19 CET)
>Michael Niedermayer skrev: (26 februari 2016
>22:53:00 CET)
>>On Fri, Feb 26, 2016 at 06:24:17AM +0100, Mats Peterson wrote:
>>> On 02/26/2016 05:26 AM, Mats Peterson wrote:
>>> >On 02/26/2016 05:08 AM, Mats Peterson wrote:
>>> >>Should hopef
On Fri, Feb 26, 2016 at 11:21:19PM +0100, Mats Peterson wrote:
> Michael Niedermayer skrev: (26 februari 2016
> 22:53:00 CET)
> >On Fri, Feb 26, 2016 at 06:24:17AM +0100, Mats Peterson wrote:
> >> On 02/26/2016 05:26 AM, Mats Peterson wrote:
> >> >On 02/26/2016 05:08 AM, Mats Peterson wrote:
> >>
On Fri, Feb 26, 2016 at 1:17 PM, Ronald S. Bultje wrote:
>
> I'm happy to help out if you tell me which field/member tsan is complaining
> about.
Hi Ronald,
I am using an old version of ffmpeg. Here is the ThreadSanitizer
warning on the data race and the relevant source code from that ffmpeg
sou
On 02/26/2016 11:31 PM, Michael Niedermayer wrote:
On Fri, Feb 26, 2016 at 11:21:19PM +0100, Mats Peterson wrote:
Michael Niedermayer skrev: (26 februari 2016 22:53:00
CET)
On Fri, Feb 26, 2016 at 06:24:17AM +0100, Mats Peterson wrote:
On 02/26/2016 05:26 AM, Mats Peterson wrote:
On 02/26/2
This does obviously not work.
(Additions based on vf_crop.c.)
---
libavfilter/vf_copy.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavfilter/vf_copy.c b/libavfilter/vf_copy.c
index fb9a906..b0159cf 100644
--- a/libavfilter/vf_copy.c
+++ b/libavfilter/vf_copy.c
@@ -2
On 02/26/2016 11:36 PM, Mats Peterson wrote:
i use qemu-mips myself
mips is not fast, building on mips is really slow if one did that
also cross building to mips should be the same speed as building to
x86 would be
qemu-mips would only run for a few seconds to do whatever you want
to test.
I ass
On Fri, 26 Feb 2016 22:59:17 +0100
Reimar Döffinger wrote:
> On Fri, Feb 26, 2016 at 10:39:41PM +0100, wm4 wrote:
> > On Fri, 26 Feb 2016 22:25:21 +0100
> > Reimar Döffinger wrote:
> >
> > > Check that the required plane pointers and only
> > > those are set up.
> > >
> > > Signed-off-by: Re
Hi,
On Fri, Feb 26, 2016 at 5:35 PM, Wan-Teh Chang wrote:
> The data race is reported on the |qscale| member of MpegEncContext.
sl->qscale is unconditionally assigned in ff_h264_decode_slice_header(),
which run at the start of each frame. Therefore, qscale is (B), not (A) (it
may be copied, bu
On 02/26/2016 11:37 PM, Mats Peterson wrote:
On 02/26/2016 11:36 PM, Mats Peterson wrote:
i use qemu-mips myself
mips is not fast, building on mips is really slow if one did that
also cross building to mips should be the same speed as building to
x86 would be
qemu-mips would only run for a few
On Fri, Feb 26, 2016 at 10:34:45PM +0100, Clément Bœsch wrote:
> ---
> libswscale/yuv2rgb.c | 20 ++--
> 1 file changed, 10 insertions(+), 10 deletions(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you
On Fri, Feb 26, 2016 at 10:34:46PM +0100, Clément Bœsch wrote:
> It makes easier looking at the difference with the generic code just
> below.
> ---
> libswscale/yuv2rgb.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2
On Fri, Feb 26, 2016 at 06:24:17AM +0100, 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" or
Michael Niedermayer skrev: (27 februari 2016 01:30:52
CET)
>On Fri, Feb 26, 2016 at 06:24:17AM +0100, 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 und
Hi,
On Fri, Feb 26, 2016 at 5:49 PM, Ronald S. Bultje
wrote:
> Now, one could argue that maybe we shouldn't copy the value *at all* if we
> don't use it anyway, which would incidentally also make tools like tsan
> happy about this particular thingy. I'm not against that, if it doesn't
> make the
On Fri, Feb 26, 2016 at 11:06:22PM +0100, Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavcodec/utils.c | 20
> libavutil/frame.h | 3 +++
> 2 files changed, 23 insertions(+)
>
On Wed, Feb 24, 2016 at 06:16:25PM +0100, Mats Peterson wrote:
> The QuickTime palette was incorrectly stored in the
> MatroskaDemuxContext instead of a MatroskaTrack.
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> matroskadec.c | 19 +++
> 1 file changed, 11 inse
Hello,
I am not sure if this is the right page to post this, but your consulting
page recommended I use this list. I recent built an audio visualization app
using html5. I'm currently using that app with xsplit to stream music to an
RTMP endpoint on either twitch.tv or YouTube.
For an example che
On Wed, Feb 24, 2016 at 04:38:20PM +, Vicente Olivert Riera wrote:
> 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:
On Wed, Feb 24, 2016 at 04:38:21PM +, Vicente Olivert Riera wrote:
> 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:
> - Nothi
On 02/27/2016 03:05 AM, Michael Niedermayer wrote:
On Wed, Feb 24, 2016 at 06:16:25PM +0100, Mats Peterson wrote:
The QuickTime palette was incorrectly stored in the
MatroskaDemuxContext instead of a MatroskaTrack.
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
matroskadec.c | 19
On 02/27/2016 04:24 AM, Mats Peterson wrote:
On 02/27/2016 03:05 AM, Michael Niedermayer wrote:
On Wed, Feb 24, 2016 at 06:16:25PM +0100, Mats Peterson wrote:
The QuickTime palette was incorrectly stored in the
MatroskaDemuxContext instead of a MatroskaTrack.
--
Mats Peterson
http://matsp888.n
On 02/27/2016 04:25 AM, Mats Peterson wrote:
On 02/27/2016 04:24 AM, Mats Peterson wrote:
On 02/27/2016 03:05 AM, Michael Niedermayer wrote:
On Wed, Feb 24, 2016 at 06:16:25PM +0100, Mats Peterson wrote:
The QuickTime palette was incorrectly stored in the
MatroskaDemuxContext instead of a Matr
100 matches
Mail list logo
