7 at 11:18:12PM +0200, Hendrik Leppkes wrote:
> > > > > > On Fri, May 26, 2017 at 11:11 PM, Michael Niedermayer
> > > > > > wrote:
> > > > > > > On Fri, May 26, 2017 at 03:20:14PM +0100, Rostislav Pehlivanov
> > > wrote:
> > > &g
On Thu, 25 May 2017 16:10:49 +0200
Michael Niedermayer wrote:
> Fixes: 1735/clusterfuzz-testcase-minimized-5350472347025408
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/fft_tem
On Thu, 25 May 2017 19:32:06 +0200
Michael Niedermayer wrote:
> This reduces the number of strstr() calls per byte
>
> Fixes timeout
> Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/
On Fri, 26 May 2017 13:08:10 +0200
Nicolas George wrote:
> Le septidi 7 prairial, an CCXXV, Paul B Mahol a écrit :
> > > This belongs in libswresample
> > No it does not.
>
> I think it does too.
There's plenty of precedent of not moving filters into libswresample or
libswscale, even if in
With the new decode API, you can't handle errors directly in the API
user - you only know that the hwaccel did not initialize at all.
Add some approximate logging.
---
libavcodec/videotoolbox.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videot
On Tue, 23 May 2017 13:36:51 +0200
wm4 wrote:
> Fixes detection of some TV sample as 24.5 FPS. With the patch applied,
> it's detected as 25 FPS.
> ---
> libavformat/utils.c | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/libavfo
Fixes detection of some TV sample as 24.5 FPS. With the patch applied,
it's detected as 25 FPS.
---
libavformat/utils.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index fbd8b58ac2..778a82aeee 100644
--- a/libavformat/utils.
On Mon, 22 May 2017 16:54:31 +0200
Clément Bœsch wrote:
> From: Clément Bœsch
>
> If the source is using a custom IO, setting this flag causes heavy leaks
> since the segments will not have their avio context closed.
>
> Regression since f5da453b068f55d335ca403d2e2b4dd2ac3d4331.
> ---
> libav
On Mon, 22 May 2017 12:06:19 +0200
Hendrik Leppkes wrote:
> Using AVOnce as a stack variable makes no sense as the state is lost
> when the function exists.
>
> This fixes repeated calls to av(filter/device)_register_all
> ---
> libavdevice/alldevices.c | 2 +-
> libavfilter/allfilters.c | 2 +-
On Sat, 20 May 2017 23:01:04 +0200
Michael Niedermayer wrote:
> This reorders the operations so as to avoid computations with the above
> arguments
> before they have been initialized.
> Fixes part of 1708/clusterfuzz-testcase-minimized-5035111957397504
>
> Found-by: continuous fuzzing process
On Sat, 20 May 2017 20:12:15 +0200
Nicolas George wrote:
> Le primidi 1er prairial, an CCXXV, Muhammad Faiz a écrit :
> > > I will push this soon.
> > Pushed and backported to 3.3 branch.
>
> Well, I was probably ok with this patch, but we will never know, will
> we?
>
> Can you explain the
On Sat, 6 May 2017 14:28:10 -0400
Micah Galizia wrote:
> On 2017-05-05 09:28 PM, wm4 wrote:
> > On Fri, 5 May 2017 20:55:05 -0400
> > Micah Galizia wrote:
> >
> >> Signed-off-by: Micah Galizia
> >> ---
> >> libavformat/hls.c | 12 +++
On Tue, 16 May 2017 05:04:36 -0700
Aaron Levinson wrote:
> Add dxva2_pool_release_dummy() and use it in call to
> av_buffer_create() in dxva2_pool_alloc().
>
> Prior to this change, av_buffer_create() was called with NULL for the
> third argument, which indicates that av_buffer_default_free() sh
On Tue, 16 May 2017 12:40:03 +0200
Carl Eugen Hoyos wrote:
> 2017-05-15 12:53 GMT+02:00 wm4 :
> > On Mon, 15 May 2017 12:40:23 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001
> >> From: St
On Mon, 15 May 2017 17:55:28 +
Rob Meyers wrote:
> Of course.
>
> We noticed when reading data from a named pipe the first 10 bytes would get
> dropped. I traced this to the affected code in fill_buffer(). The
> assignment of "dst" was always set to the beginning of the buffer, and if
> it h
On Mon, 15 May 2017 12:40:23 +0200
Carl Eugen Hoyos wrote:
> From 42766f345dbf398716c6fd9072f072f5fa91c940 Mon Sep 17 00:00:00 2001
> From: Steve Kondik
> Date: Tue, 16 Dec 2014 01:37:57 -0800
> Subject: [PATCH 2/2] avutil: Use _SC_NPROCESSORS_CONF
>
> * On most Android devices, CPUs can appea
On Sun, 7 May 2017 12:01:11 -0700
Aaron Levinson wrote:
> Are you also planning to change ffmpeg_videotoolbox.c? See below for
> more comments.
>
> Aaron Levinson
>
Pushed. Changed what I felt like I could change. Thanks for the review.
___
ffmpeg-
On Fri, 12 May 2017 20:55:13 +0200
Michael Niedermayer wrote:
> On Fri, May 12, 2017 at 03:29:52PM +0200, Paul B Mahol wrote:
> > On 5/12/17, Michael Niedermayer wrote:
> > > On Thu, May 11, 2017 at 11:17:33AM +0200, Michael Niedermayer wrote:
> > >> On Thu, May 11, 2017 at 09:01:57AM +0200,
On Fri, 12 May 2017 13:28:14 -0700
Aaron Levinson wrote:
> Purpose: Made execution of reap_filters() more deterministic with
> respect to when headers are written in relationship with the
> initialization of output streams and the processing of input audio
> and/or video frames. This change fixe
On Fri, 12 May 2017 20:01:54 +0200
Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, 12 May 2017 18:21:07 +0200
Nicolas George wrote:
> Le tridi 23 floréal, an CCXXV, Paul B Mahol a écrit :
> > I told you that its unacceptable.
>
> And I told you, before you pushed, that your cowboy-style parser was
> unacceptable. You chose to disregard it.
AFAIK all of our subtitle
On Fri, 12 May 2017 10:59:50 -0300
James Almer wrote:
> On 5/12/2017 9:20 AM, Michael Niedermayer wrote:
> > On Fri, May 12, 2017 at 06:16:38AM +0200, wm4 wrote:
> >> On Thu, 11 May 2017 23:27:37 +0200
> >> Michael Niedermayer wrote:
> >>
> >>&g
On Thu, 11 May 2017 23:27:37 +0200
Michael Niedermayer wrote:
> On Thu, May 11, 2017 at 06:54:16PM +0200, wm4 wrote:
> > On Thu, 11 May 2017 13:01:36 +0200
> > Michael Niedermayer wrote:
> >
> > > Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
>
On Thu, 11 May 2017 13:01:36 +0200
Michael Niedermayer wrote:
> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.
On Thu, 11 May 2017 12:53:33 +0200
Reino Wijnsma wrote:
> See https://trac.ffmpeg.org/ticket/6377.
> By prioritizing the 'sdl2-config'-check the librarylist that's needed to
> build FFPlay is setup automatically and one doesn't have to patch
> 'sdl2.pc' anymore.
Wouldn't it be more appropriate t
On Wed, 10 May 2017 15:39:45 +0200
Michael Niedermayer wrote:
> On Wed, May 10, 2017 at 08:10:23AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, May 9, 2017 at 9:24 PM, Michael Niedermayer
> > wrote:
> >
> > > On Tue, May 09, 2017 at 09:08:08PM -0400, Ronald S. Bultje wrote:
> > >
On Mon, 8 May 2017 16:25:43 -0400
Vadim Kalinsky wrote:
> Hey,
>
> Trying to fix a bug #6113, I stumbled upon some strange logic in
> libavformat/img2dec.c:jpeg_probe. It accepts first 2048 bytes of jpeg stream,
> and tries to read it with some state machine. If it doesn't look like jpeg
> st
On Mon, 8 May 2017 15:46:22 -0300
James Almer wrote:
> From: Anton Khirnov
>
> ---
> This merges commit a02ae1c6837a54ed9e7735da2b1f789b2f4b6e13 from libav
>
Any specific reason you're posting them to the list?
___
ffmpeg-devel mailing list
ffmpeg-
On Mon, 08 May 2017 11:24:19 -0400
"Daniel Richard G." wrote:
> From 477cbd18b630365d612da173201c2e4ee763d7d4 Mon Sep 17 00:00:00 2001
> From: Daniel Richard G
> Date: Sun, 16 Apr 2017 23:12:53 -0400
> Subject: [PATCH] avformat/rtsp: check return value of read in
> ff_rtsp_read_reply()
>
> Sig
On Wed, 3 May 2017 05:26:04 +0200
wm4 wrote:
> This adds tons of code for no other benefit than making VideoToolbox
> support conform with the new hwaccel API (using hw_device_ctx and
> hw_frames_ctx).
>
> Since VideoToolbox decoding does not actually require the user to
> al
On Sat, 6 May 2017 15:29:18 -0300
James Almer wrote:
> On 5/5/2017 2:23 PM, Nicolas George wrote:
> > Le sextidi 16 floréal, an CCXXV, James Almer a écrit :
> >> stuff you broke
> >
> > Please stop spreading wm4's lies. The b
On Sat, 6 May 2017 11:20:13 +0200
Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, Kieran Kunhya a écrit :
> > I sent a patch about this nearly three years ago, it wasn't applied for
> > whatever reason.
> > This is pretty common if you don't use av_malloc.
>
> Thanks for pointing it.
On Fri, 5 May 2017 20:55:05 -0400
Micah Galizia wrote:
> Signed-off-by: Micah Galizia
> ---
> libavformat/hls.c | 12 ++--
> 1 file changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4350..bda9abecfa 100644
> --- a/libavforma
On Fri, 5 May 2017 18:59:00 -0300
James Almer wrote:
> On 5/5/2017 6:23 PM, Kieran Kunhya wrote:
> >>
> >>
> >> +if (strlen(user_data + 16) > 0)
> >> +av_log(logctx, AV_LOG_DEBUG, "user data:\"%s\"\n", user_data +
> >> 16);
> >>
> >
> > Eugh, no, no, no.
> > Some encoders put rando
On Sat, 6 May 2017 04:06:03 +0800
Steven Liu wrote:
> Fixes Coverity CID: 1405453
>
> Signed-off-by: Steven Liu
> ---
> libavformat/matroskadec.c |1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 9e2c9b
On Fri, 5 May 2017 14:12:56 +0200
Michael Niedermayer wrote:
> On Fri, May 05, 2017 at 09:42:51AM +0200, Clément Bœsch wrote:
> > On Fri, May 05, 2017 at 12:11:27AM -0700, Aaron Levinson wrote:
> > > On 4/19/2017 10:43 AM, Aaron Levinson wrote:
> > > > On 4/14/2017 6:51 PM, Aaron Levinson wro
On Fri, 5 May 2017 13:59:26 +0200
Hendrik Leppkes wrote:
> On Fri, May 5, 2017 at 9:54 PM, Steven Liu wrote:
> > Fixes Coverity CID: 1405453
> >
> > Signed-off-by: Steven Liu
> > ---
> > libavformat/matroskadec.c |1 +
> > 1 files changed, 1 insertions(+), 0 deletions(-)
> >
> > diff --git
On Fri, 5 May 2017 12:00:02 +0200
Nicolas George wrote:
> Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit :
> > This should fix Ticket6349.
> > Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
> > generate unaligned frame data.
> >
> > Signed-off-by: Muhammad Faiz
> > ---
>
On Fri, 5 May 2017 01:11:17 -0700
Aaron Levinson wrote:
> > As I said on IRC, I'm skeptic against this, but I'm also not sure
> > whether I understand the situation.
> >
> > First, your change seems a bit fragile, and almost relies on
> > coincidences. This could easily break in the future. (And
On Thu, 4 May 2017 23:46:30 -0700
Aaron Levinson wrote:
> On 4/12/2017 6:08 PM, Aaron Levinson wrote:
> > On 3/26/2017 10:34 AM, Aaron Levinson wrote:
> >> On 3/26/2017 4:41 AM, Matthias Hunstock wrote:
> >>> Am 26.03.2017 um 11:50 schrieb Aaron Levinson:
> When using the following com
On Fri, 5 May 2017 09:42:51 +0200
Clément Bœsch wrote:
> On Fri, May 05, 2017 at 12:11:27AM -0700, Aaron Levinson wrote:
> > On 4/19/2017 10:43 AM, Aaron Levinson wrote:
> > > On 4/14/2017 6:51 PM, Aaron Levinson wrote:
> > >> From e0c73c054add0137901d0bf7a7893e42e7e566c8 Mon Sep 17 00:00:00
On Fri, 5 May 2017 00:05:35 +0200
Nicolas George wrote:
> Le quintidi 15 floréal, an CCXXV, Nicolas George a écrit :
> > Absolutely not, these change were there for a reason, that reason is
> > still valid.
>
> Also, the bug is not in libavfilter, so reverting changes in libavfilter
> makes no
On Wed, May 3, 2017 at 3:23 PM, Michael Niedermayer
> > >> wrote:
> > >>> On Wed, May 03, 2017 at 12:54:53PM +0200, Hendrik Leppkes wrote:
> > >>>> On Wed, May 3, 2017 at 11:50 AM, Michael Niedermayer
> > >>>> wrote:
> > >&g
On Thu, 4 May 2017 22:24:15 +0200
Nicolas George wrote:
> Le quintidi 15 floréal, an CCXXV, Kyle Swanson a écrit :
> > I believe this is still broken on git master and is present on release
>
> Well, nobody fixed it.
>
> > 3.3. If a proper fix is going to take time,
>
> There is no reason
:
> > >> On Wed, May 3, 2017 at 11:50 AM, Michael Niedermayer
> > >> wrote:
> > >> > On Wed, May 03, 2017 at 11:37:35AM +0200, wm4 wrote:
> > >> >> On Wed, 3 May 2017 11:29:04 +0200
> > >> >> Michael Niedermayer wrote:
> >> > On Wed, May 03, 2017 at 11:37:35AM +0200, wm4 wrote:
> >> >> On Wed, 3 May 2017 11:29:04 +0200
> >> >> Michael Niedermayer wrote:
> >> >>
> >> >> > On Wed, May 03, 2017 at 05:29:07AM
On Wed, 3 May 2017 15:16:27 +0200
Michael Niedermayer wrote:
> On Wed, May 03, 2017 at 12:07:46PM +0200, wm4 wrote:
> > On Wed, 3 May 2017 11:55:16 +0200
> > Michael Niedermayer wrote:
> >
> > > On Wed, May 03, 2017 at 11:50:41AM +0200, Michael Niedermayer w
On Wed, 3 May 2017 11:55:16 +0200
Michael Niedermayer wrote:
> On Wed, May 03, 2017 at 11:50:41AM +0200, Michael Niedermayer wrote:
> > On Wed, May 03, 2017 at 11:37:35AM +0200, wm4 wrote:
> > > On Wed, 3 May 2017 11:29:04 +0200
> > > Michael Niedermayer wrote:
>
On Wed, 3 May 2017 11:29:04 +0200
Michael Niedermayer wrote:
> On Wed, May 03, 2017 at 05:29:07AM +0200, wm4 wrote:
> > On Wed, 3 May 2017 05:21:50 +0200
> > Michael Niedermayer wrote:
> >
> > > Fixes timeout
> > > Fixes: 1293/clusterf
On Wed, 3 May 2017 05:21:50 +0200
Michael Niedermayer wrote:
> Fixes timeout
> Fixes: 1293/clusterfuzz-testcase-minimized-6054752074858496
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> lib
This adds tons of code for no other benefit than making VideoToolbox
support conform with the new hwaccel API (using hw_device_ctx and
hw_frames_ctx).
Since VideoToolbox decoding does not actually require the user to
allocate frames, the new code does mostly nothing.
One benefit is that ffmpeg_vi
On Tue, 2 May 2017 20:47:06 -0400
Micah Galizia wrote:
> Signed-off-by: Micah Galizia
> ---
> libavformat/hls.c | 12 +---
> 1 file changed, 9 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index bac53a4350..643d50e1da 100644
> --- a/libavformat
On Fri, 28 Apr 2017 21:27:56 -0300
James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavformat/concatdec.c | 94
> -
> 1 file changed, 30 insertions(+), 64 deletions(-)
>
> diff --git a/libavformat/concatdec.c b/libavformat/concatdec.c
>
This is a newer API that is intended for decoders like the cuvid
wrapper. Until now, the wrapper required to set an awkward
"incomplete" hw_frames_ctx to set the device. Now the device
can be set directly, and the user can get AV_PIX_FMT_CUDA output
for a specific device simply by setting hw_device
On Tue, 2 May 2017 18:01:37 -0400
Shawn Singh wrote:
> Hello,
>
> We are trying to understand two fields in AVCodecParameters:
> bits_per_coded_sample and bits_per_raw_sample.
>
> In the comments in libavcodec/avcodec.h, bits_per_coded_sample is described
> as "the bitrate per sample". This
Fixes e.g.:
ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex
"[0:v][1:v]psnr[out]" -f null none
---
ffmpeg.h| 1 +
ffmpeg_filter.c | 15 +++
ffmpeg_opt.c| 2 ++
3 files changed, 18 insertions(+)
diff --git a/ffmpeg.h b/ffmpeg.h
index 4d0456c1fb..d34561275
On Mon, 1 May 2017 15:29:22 -0300
James Almer wrote:
> On 5/1/2017 3:13 PM, Marton Balint wrote:
> >
> > On Mon, 24 Apr 2017, wm4 wrote:
> >
> >> On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
> >> Marton Balint wrote:
> >>
> >>> On M
On Tue, 2 May 2017 14:17:33 -0700
Aaron Levinson wrote:
> On 5/1/2017 11:06 PM, MFojtak wrote:
> > Currently this muxer does not work at all. I don't know if 000Z would make
> > it compatible with more player as I don't know any. However, adding Z makes
> > it compatible with most popular ones li
On Tue, 2 May 2017 14:50:32 -0300
James Almer wrote:
> On 5/2/2017 2:19 PM, wm4 wrote:
> > On Mon, 1 May 2017 20:52:14 -0300
> > James Almer wrote:
> >
> >> decode.c already sets it to the default value.
> >>
> >> Signed-off-by: James Alme
On Mon, 1 May 2017 15:29:22 -0300
James Almer wrote:
> On 5/1/2017 3:13 PM, Marton Balint wrote:
> >
> > On Mon, 24 Apr 2017, wm4 wrote:
> >
> >> On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
> >> Marton Balint wrote:
> >>
> >>> On M
On Mon, 1 May 2017 20:52:14 -0300
James Almer wrote:
> decode.c already sets it to the default value.
>
> Signed-off-by: James Almer
> ---
> libavcodec/vp9.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index 4d7310f6d4..3147ffa0db 100644
> --
On Tue, 2 May 2017 16:16:35 +0200
Nicolas George wrote:
> Le duodi 12 floréal, an CCXXV, Paul B Mahol a écrit :
> > This is all one big mess.
>
> It is, but I will not take responsibility when it is not mine.
>
> Libavfilter was in need of a serious overhaul. I do not see you denying
> it, an
On Mon, 1 May 2017 07:36:35 +0700
Muhammad Faiz wrote:
> Fix fate failures:
> make fate-mov THREADS=32
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/decode.c | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>
On Sun, 30 Apr 2017 23:55:02 +0700
Muhammad Faiz wrote:
> On Thu, Apr 27, 2017 at 3:51 PM, Nicolas George wrote:
> > L'octidi 8 floréal, an CCXXV, Michael Niedermayer a écrit :
> >> I agree
> >> in fact i added such a flag in 2011
> >> (4d34b6c1a1254850e39a36f08f4d2730092a54db)
> >> within th
On Sun, 30 Apr 2017 14:04:33 +0700
Muhammad Faiz wrote:
> Fix fate failures:
> make fate-mov THREADS=32
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/decode.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.
l frames and errors are correctly reported in order.
> >>> >> Also limit the numbers of error during draining to prevent infinite
> >>> >> loop.
> >>> >>
> >>> >> This fix fate failure with THREADS>=4:
> &g
EADS=4
> This also reverts a755b725ec1d657609c8bd726ce37e7cf193d03f.
>
> Suggested-by: wm4, Ronald S. Bultje, Marton Balint
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/decode.c| 21 +++--
> libavcodec/internal.h | 3 +++
> libavcodec/pthre
On Fri, 28 Apr 2017 02:50:42 +0200
Michael Niedermayer wrote:
> Suggested-by: "Ronald S. Bultje"
> Signed-off-by: Michael Niedermayer
> ---
> doc/developer.texi | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index dbe1f5421f..a948113792
On Thu, 27 Apr 2017 01:20:53 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 10:34 PM, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
> >
> >> On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
>
On Thu, 27 Apr 2017 01:41:04 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 8:53 PM, wm4 wrote:
> > On Wed, 26 Apr 2017 20:09:58 +0700
> > Muhammad Faiz wrote:
> >
> >> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
> >> > On Wed, 26 Apr 2017
On Wed, 26 Apr 2017 11:34:22 -0400
"Ronald S. Bultje" wrote:
> Hi,
>
> On Wed, Apr 26, 2017 at 1:21 AM, Muhammad Faiz wrote:
>
> > On Wed, Apr 26, 2017 at 4:09 AM, wm4 wrote:
> > > On Tue, 25 Apr 2017 23:52:04 +0700
> > > Muhammad Faiz wro
On Wed, 26 Apr 2017 20:09:58 +0700
Muhammad Faiz wrote:
> On Wed, Apr 26, 2017 at 5:34 PM, wm4 wrote:
> > On Wed, 26 Apr 2017 17:16:05 +0700
> > Muhammad Faiz wrote:
> >
> >> This should fix Ticket6349
> >>
> >> Since 383057f8e744efeaaa3648
On Wed, 26 Apr 2017 17:16:05 +0700
Muhammad Faiz wrote:
> This should fix Ticket6349
>
> Since 383057f8e744efeaaa3648a59bc577b25b055835, framequeue may
> generate unaligned frame data.
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/libmp3lame.c | 13 +
> 1 file changed, 9 ins
On Tue, 25 Apr 2017 23:52:04 +0700
Muhammad Faiz wrote:
> when frame is received, not from other threads.
>
> Should fix fate failure with THREADS>=4:
> make fate-h264-attachment-631 THREADS=4
>
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/pthread_frame.c | 4
> 1 file changed, 4
On Tue, 25 Apr 2017 17:29:10 +0700
Muhammad Faiz wrote:
> On Tue, Apr 25, 2017 at 4:09 PM, Hendrik Leppkes wrote:
> > On Tue, Apr 25, 2017 at 4:32 AM, Muhammad Faiz wrote:
> >> On Tue, Apr 25, 2017 at 1:57 AM, wm4 wrote:
> >>> This is needed to get compatib
On Mon, 24 Apr 2017 21:14:15 +0200 (CEST)
Marton Balint wrote:
> On Mon, 24 Apr 2017, Michael Niedermayer wrote:
> > On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
>
> >> We have recently been able to go through six hundred or so commits in a
> >> month or two this way after bein
On Mon, 24 Apr 2017 16:19:00 -0300
James Almer wrote:
> On 4/24/2017 4:08 PM, wm4 wrote:
> > On Mon, 24 Apr 2017 20:27:45 +0200
> > Michael Niedermayer wrote:
> >
> >> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> >>> On 4/2
On Mon, 24 Apr 2017 20:27:45 +0200
Michael Niedermayer wrote:
> On Mon, Apr 24, 2017 at 11:23:16AM -0300, James Almer wrote:
> > On 4/23/2017 11:07 PM, Michael Niedermayer wrote:
> > > Hi all
> > >
> > > Should changes ported from libav (what we call merges) be reviewed
> > > before being push
This is needed to get compatibility with the behavior before the
recent decode.c restructuring merge, and fixes fate failures with
this:
make fate-h264-attachment-631 THREADS=32
For every 4 threads, a frame is dropped at the point at which
draining is initialized. The problem starts at THREADS=
On Mon, 24 Apr 2017 16:00:41 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 15:38 GMT+02:00 wm4 :
> > On Mon, 24 Apr 2017 15:23:20 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> >> > Hi,
> >> &
On Sun, 23 Apr 2017 20:50:38 -0700
Aaron Levinson wrote:
> properly review some of the ported changes on ffmpeg-devel. For
> example, I submitted a patch to fix a bug with QuickSync interlaced
> video to ffmpeg-devel on 4/13/2017. The change mostly reverted some of
> the QSV code in ffmpeg b
On Mon, 24 Apr 2017 15:23:20 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 13:39 GMT+02:00 Ronald S. Bultje :
> > Hi,
> >
> > On Mon, Apr 24, 2017 at 5:57 AM, wm4 wrote:
> >
> >> On Mon, 24 Apr 2017 10:46:38 +0200
> >> Carl Eugen Hoyos wrote:
&g
On Mon, 24 Apr 2017 10:46:38 +0200
Carl Eugen Hoyos wrote:
> 2017-04-24 5:50 GMT+02:00 Aaron Levinson :
> > On 4/23/2017 7:07 PM, Michael Niedermayer wrote:
> >>
> >> Should changes ported from libav (what we call merges) be reviewed
> >> before being pushed?
> >
> > I've asked about this on
On Sun, 23 Apr 2017 14:08:18 +0100
Derek Buitenhuis wrote:
> On 4/21/2017 4:40 PM, Derek Buitenhuis wrote:
> > The WebM DASH spec states:
> > The Initialization Segment shall not contain Clusters or Cues.
> > The Segment Index corresponds to the Cues.
> >
> > Previously, it included the
On Fri, 21 Apr 2017 22:59:41 +0800
sharp...@gmail.com wrote:
> From: sharpbai
>
> Bug example:
>
> ffmpeg -i a.mp3 -c:a mp3 -ab 32k -ar 44100 -ac 1 b.mp3
>
> The duration of the generated file b.mp3 is wrong on ios safari browser from
> ios7 to ios10.
> ---
> libavformat/mp3enc.c | 7 ++-
On Sun, 23 Apr 2017 14:09:06 +0100
Derek Buitenhuis wrote:
> On 4/20/2017 3:02 PM, Derek Buitenhuis wrote:
> > ---
> > libavformat/matroskadec.c | 14 +++---
> > 1 file changed, 11 insertions(+), 3 deletions(-)
>
> Ping.
I don't think any active developer cares about it. Considering
On Fri, 21 Apr 2017 15:31:55 +0100
Amine kabab wrote:
> Normally, all the streams
>
Wouldn't it be better to only consider the selected streams for this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-
On Sat, 22 Apr 2017 16:04:22 +0700
Muhammad Faiz wrote:
> Signed-off-by: Muhammad Faiz
> ---
+1 to patches 1-7. As long as the accessors only trivially access
public fields, it's better (and less ugly) not to use accessors at all.
___
ffmpeg-devel mai
On Fri, 21 Apr 2017 11:34:39 +0100
Amine kabab wrote:
> Hi Ben, thanks for reviewing the patch,
>
>
> On 21/04/2017 08:13, Benoit Fouet wrote:
> > Hi,
> >
> >
> > On 20/04/2017 18:18, Amine kabab wrote:
> >> From 5079f9b7114589626a4c9fff0fbb8f6e0d2f4fd9 Mon Sep 17 00:00:00 2001
> >> From: ami
On Tue, 18 Apr 2017 22:19:45 -0300
Andres Manguel wrote:
> Hello,
> I am looking for a software development that allows me to stream
> synchronously multiple tracks of video and audio recorded in matroska format
> to ios and android devices.
>
> Please contact me at amang...@gmail.com.
Your f
On Tue, 18 Apr 2017 16:01:48 +0200
Michael Niedermayer wrote:
> On Tue, Apr 18, 2017 at 03:47:29PM +0200, Nicolas George wrote:
> > Le nonidi 29 germinal, an CCXXV, Michael Niedermayer a écrit :
> > > This contradicts the documentation: (and would be rather rigid design)
> >
> > Possible. Bu
On Tue, 18 Apr 2017 13:30:43 +0200
Michael Niedermayer wrote:
> On Tue, Apr 18, 2017 at 06:43:07AM -0400, Ronald S. Bultje wrote:
> > Hi,
> >
> > On Tue, Apr 18, 2017 at 6:31 AM, Michael Niedermayer
> > > > wrote:
> >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavcodec/a
On Tue, 18 Apr 2017 12:31:25 +0200
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/avcodec.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index ee133712b5..2ac1523a36 100644
> --- a/lib
On Mon, 17 Apr 2017 18:14:45 -0700
Aaron Levinson wrote:
> On 4/17/2017 8:28 AM, wm4 wrote:
> > On Mon, 17 Apr 2017 12:06:59 -0300
> > James Almer wrote:
> >
> >> On 4/17/2017 5:39 AM, Clément Bœsch wrote:
> >>> On Sun, Apr 16, 2017 at 05:20:02PM
On Mon, 17 Apr 2017 12:06:59 -0300
James Almer wrote:
> On 4/17/2017 5:39 AM, Clément Bœsch wrote:
> > On Sun, Apr 16, 2017 at 05:20:02PM -0700, Aaron Levinson wrote:
> >> From 9e6a9e2b8d58f17c661a3f455e03c95587ec7b18 Mon Sep 17 00:00:00 2001
> >> From: Aaron Levinson
> >> Date: Sun, 16 Apr 20
On Mon, 17 Apr 2017 12:22:00 +0200
Timo Rothenpieler wrote:
> Am 17.04.2017 um 08:59 schrieb Yogender Gupta:
> >>> Please find attached a CUDA based scale filter. This filter will be a
> >>> starting point to add other CUDA based filters. The filter supports
> >>> 420-8, 420-10, 444-8, 444-10 f
On Sun, 16 Apr 2017 15:23:15 -0300
James Almer wrote:
> On 4/16/2017 2:17 PM, Aaron Levinson wrote:
> > On 4/15/2017 9:32 PM, James Almer wrote:
> >> On 4/15/2017 7:41 AM, Marton Balint wrote:
> >>>
> >>> On Thu, 13 Apr 2017, Aaron Levinson wrote:
> >>>
> On 4/13/2017 3:40 PM, Marton B
On Sat, 15 Apr 2017 15:53:36 +0200
"Jean-Baptiste Kempf" wrote:
> > Recently, I contacted the same author about relicensing the
> > same MPlayer code (of which af_pan.c was a subset of) to LGPL, and he
> > explicitly denied relicensing. So if I had been cehoyos, I probably
> > wouldn't shut up ab
On Sat, 15 Apr 2017 16:33:41 +0200
Carl Eugen Hoyos wrote:
> 2017-04-15 15:06 GMT+02:00 wm4 :
> > On Sat, 15 Apr 2017 07:55:50 +0200
> > Carl Eugen Hoyos wrote:
> >
> >> 2017-04-15 2:35 GMT+02:00 wm4 :
> >>
> >> > Legally, all thes
On Sat, 15 Apr 2017 09:47:58 +0200
Zalewa PL wrote:
> Hello,
>
> > The plan is that if ffserver is not fixed before the next bump, it will
> > be removed.
>
> ffserver has been serving our purpose in a 24/7 fashion for about 7
> years now. It will probably be serving us for the foreseeable f
901 - 1000 of 3095 matches
Mail list logo
