On Sun, 21 Jan 2018 03:33:08 +0100
Michael Niedermayer wrote:
> also a memcmp on the data might be worth looking into to avoid re-parsing of
> unchanged PS
> (theres already a memcmp in libavcodec/h264_ps.c)
That sounds like it'd help much more than a buffer pool.
Anyway, did anyone run benchma
On Sun, 21 Jan 2018 00:52:18 +
Mark Thompson wrote:
> ---
> struct timeval elements are not big enough in a 32-bit ABI.
>
>
> libavcodec/v4l2_buffers.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/v4l2_buffers.c b/libavcodec/v4l2_buffers.c
> index
On Sun, 21 Jan 2018 10:24:21 +0700
Muhammad Faiz wrote:
> > I don't trust the atomics use
> > either, I'm don't want to have to debug that ever.
>
> Of course, using atomics is more complicated that using mutex (with
> benefits that it will be faster wh
Hi,
fixes rejection of non-free libraries if "--enable-nonfree" is omitted for me.
Git blame says this line is older than 10 months... is it for some reason the
expected behaviour?
-Thilo
From 6fcb95d0094341149e865982b00cb763f99a92a3 Mon Sep 17 00:00:00 2001
From: Thilo Borgmann
Date: Sun, 21
On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer
wrote:
> Hi
Patch updated.
Some of the review comments I decided not to implement in order to keep
closer to the spec.
Regards,
Kieran Kunhya
0001-mpeg4video-Add-support-for-MPEG-4-Simple-Studio-Prof.patch
Description: Binary data
_
On 1/21/2018 6:01 PM, Thilo Borgmann wrote:
Hi,
fixes rejection of non-free libraries if "--enable-nonfree" is omitted for me.
Git blame says this line is older than 10 months... is it for some reason the
expected behaviour?
-Thilo
LICENSE.md says
"The Fraunhofer FDK AAC and OpenSSL libra
2018-01-21 13:31 GMT+01:00 Thilo Borgmann :
> fixes rejection of non-free libraries if "--enable-nonfree" is omitted for me.
The LGPL allows you to link against a non-compatible library and
distribute the resulting binary.
Carl Eugen
___
ffmpeg-devel m
2018-01-21 13:37 GMT+01:00 Kieran Kunhya :
> On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer wrote:
>
>> Hi
>
> Patch updated.
If you choose to ignore more than half of the comments made,
please at least answer the review to explain why you
believe the comments were not helpful.
> Some of the
Am 21.01.18 um 13:43 schrieb Carl Eugen Hoyos:
> 2018-01-21 13:31 GMT+01:00 Thilo Borgmann :
>
>> fixes rejection of non-free libraries if "--enable-nonfree" is omitted for
>> me.
>
> The LGPL allows you to link against a non-compatible library and
> distribute the resulting binary.
So if the c
On Sun, Jan 21, 2018 at 12:53 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 13:37 GMT+01:00 Kieran Kunhya :
> > On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer wrote:
> >
> >> Hi
> >
> > Patch updated.
>
> If you choose to ignore more than half of the comments made,
> please at least answer the re
2018-01-21 14:03 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 12:53 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 13:37 GMT+01:00 Kieran Kunhya :
>> > On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer wrote:
>> >
>> >> Hi
>> >
>> > Patch updated.
>>
>> If you choose to ignore more than ha
On Sun, Jan 21, 2018 at 1:08 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 14:03 GMT+01:00 Kieran Kunhya :
> > On Sun, Jan 21, 2018 at 12:53 PM, Carl Eugen Hoyos
> > wrote:
> >
> >> 2018-01-21 13:37 GMT+01:00 Kieran Kunhya :
> >> > On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer wrote:
> >> >
> >
2018-01-21 14:22 GMT+01:00 Kieran Kunhya :
> I will be committing this patch soon.
?
Can you reproduce the following issue that I see here?
When testing with ffplay, in ~50% of tries, videos look fine,
in other cases, I get a monochrome unchanging image
and the following repeated error message:
On Sun, Jan 21, 2018 at 1:30 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 14:22 GMT+01:00 Kieran Kunhya :
>
> Can you reproduce the following issue that I see here?
> When testing with ffplay, in ~50% of tries, videos look fine,
> in other cases, I get a monochrome unchanging image
> and the followin
2018-01-21 14:33 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 1:30 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 14:22 GMT+01:00 Kieran Kunhya :
>>
>> Can you reproduce the following issue that I see here?
>> When testing with ffplay, in ~50% of tries, videos look fine,
>> in other cases, I
On Sun, Jan 21, 2018 at 1:42 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 14:33 GMT+01:00 Kieran Kunhya :
> > On Sun, Jan 21, 2018 at 1:30 PM, Carl Eugen Hoyos
> > wrote:
> >
> >> 2018-01-21 14:22 GMT+01:00 Kieran Kunhya :
> >>
> >> Can you reproduce the following issue that I see here?
> >> When te
2018-01-21 14:57 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 1:42 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 14:33 GMT+01:00 Kieran Kunhya :
>> > On Sun, Jan 21, 2018 at 1:30 PM, Carl Eugen Hoyos
>> > wrote:
>> >
>> >> 2018-01-21 14:22 GMT+01:00 Kieran Kunhya :
>> >>
>> >> Can you repr
>
> Only that I can not reproduce without your patch (and that I have
> never seen this issue before).
>
> Carl Eugen
>
I cannot reproduce this issue with ffplay on Ubuntu Linux.
I would recommend running "make distclean" and recompiling.
Kieran
___
ffm
On 1/21/2018 9:12 AM, wm4 wrote:
> On Sun, 21 Jan 2018 03:33:08 +0100
> Michael Niedermayer wrote:
>
>> also a memcmp on the data might be worth looking into to avoid re-parsing of
>> unchanged PS
>> (theres already a memcmp in libavcodec/h264_ps.c)
>
> That sounds like it'd help much more than
2018-01-21 15:34 GMT+01:00 Kieran Kunhya :
>>
>> Only that I can not reproduce without your patch (and that I have
>> never seen this issue before).
>>
>> Carl Eugen
>>
> I cannot reproduce this issue with ffplay on Ubuntu Linux.
> I would recommend running "make distclean" and recompiling.
My las
fre 2018-01-19 klockan 19:19 +0100 skrev Carl Eugen Hoyos:
> 2018-01-19 16:54 GMT+01:00 Tomas Härdin :
> > On 2018-01-18 23:34, Carl Eugen Hoyos wrote:
> > >
> > > Hi!
> > >
> > > Attached patch fixes a warning, I suspect it makes the code more
> > > correct.
> > >
> > > Please comment, Carl Eug
Here is a rebased version of the patch series on top of the current git master,
if I get no further comments, I will apply this in a week.
The conversion was mostly straightforward, but there were some cases where it
needed additional work, so I'd really appriciate if someone could test at least
t
In preparation for the deprecation of AVFormatContext->filename.
Signed-off-by: Marton Balint
---
libavformat/hlsenc.c | 113 ++-
1 file changed, 58 insertions(+), 55 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 42e4
Signed-off-by: Marton Balint
---
doc/examples/transcode_aac.c | 7 +--
fftools/ffmpeg.c | 16
fftools/ffmpeg_opt.c | 8
fftools/ffplay.c | 6 +++---
fftools/ffprobe.c| 2 +-
tools/uncoded_frame.c| 2 +-
6 files
Signed-off-by: Marton Balint
---
libavdevice/alsa.c | 4 ++--
libavdevice/avfoundation.m | 2 +-
libavdevice/bktr.c | 2 +-
libavdevice/caca.c | 2 +-
libavdevice/decklink_common.cpp | 2 +-
libavdevice/decklink_dec.cpp| 4 ++--
libavdevice/de
This will replace the 1024 character limited filename field. Compatiblity for
output contexts are provided by copying filename field to URL if URL is unset
and by providing an internal function for muxers to set both url and filename
at once.
Signed-off-by: Marton Balint
---
doc/APIchanges
Signed-off-by: Marton Balint
---
libavformat/concatdec.c | 4 ++--
libavformat/dashenc.c| 16
libavformat/fifo.c | 8
libavformat/flvenc.c | 4 ++--
libavformat/gxfenc.c | 4 ++--
libavformat/hdsenc.c
Signed-off-by: Marton Balint
---
libavformat/hls.c| 4 +-
libavformat/hlsenc.c | 166 +--
2 files changed, 96 insertions(+), 74 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 950cc4c3bd..559b8c3391 100644
--- a/libavfor
Signed-off-by: Marton Balint
---
doc/APIchanges | 4
libavformat/avformat.h | 5 +
libavformat/mux.c | 10 ++
libavformat/utils.c| 8
libavformat/version.h | 3 +++
5 files changed, 30 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
inde
On Fri, Jan 19, 2018 at 05:52:32PM +0100, Jorge Ramirez-Ortiz wrote:
> ---
> MAINTAINERS | 1 +
> 1 file changed, 1 insertion(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Awnsering whenever a program halts or runs forever is
On a turing ma
On Sat, Jan 20, 2018 at 04:50:29AM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 1477974040 - -1877995504 cannot be
> represented in type 'int'
> Fixes: 4861/clusterfuzz-testcase-minimized-4570316383715328
>
> Found-by: continuous fuzzing process
> https://github.com/google
2018-01-21 16:10 GMT+01:00 Tomas Härdin :
> fre 2018-01-19 klockan 19:19 +0100 skrev Carl Eugen Hoyos:
>> 2018-01-19 16:54 GMT+01:00 Tomas Härdin :
>> > On 2018-01-18 23:34, Carl Eugen Hoyos wrote:
>> > >
>> > > Hi!
>> > >
>> > > Attached patch fixes a warning, I suspect it makes the code more
>> >
On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 15:34 GMT+01:00 Kieran Kunhya :
> >>
> >> Only that I can not reproduce without your patch (and that I have
> >> never seen this issue before).
> >>
> >> Carl Eugen
> >>
> > I cannot reproduce this issue with ffplay on Ubuntu L
On Sat, Jan 20, 2018 at 11:53:25PM -0300, James Almer wrote:
> On 1/20/2018 11:33 PM, Michael Niedermayer wrote:
> > On Sat, Jan 20, 2018 at 06:49:29PM -0300, James Almer wrote:
> >> Signed-off-by: James Almer
> >> ---
> >> Similar rationale as hevc. With up to 32 sps and 256 pps, this may
> >> co
2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 15:34 GMT+01:00 Kieran Kunhya :
>> >>
>> >> Only that I can not reproduce without your patch (and that I have
>> >> never seen this issue before).
>> >>
>> >> Carl Eugen
>> >>
>>
2018-01-21 23:06 GMT+01:00 Carl Eugen Hoyos :
> 2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
>> Does this happen in single threaded mode?
>
> Also happens with "ffplay -threads 1"
Also reproducible (sometimes) with --disable-pthreads.
Carl Eugen
___
ffmp
On 1/21/2018 7:06 PM, Michael Niedermayer wrote:
> On Sat, Jan 20, 2018 at 11:53:25PM -0300, James Almer wrote:
>> On 1/20/2018 11:33 PM, Michael Niedermayer wrote:
>>> On Sat, Jan 20, 2018 at 06:49:29PM -0300, James Almer wrote:
Signed-off-by: James Almer
---
Similar rationale as h
On Sun, Jan 21, 2018 at 10:06 PM, Carl Eugen Hoyos
wrote:
> 2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
> > On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos
> > wrote:
> >
> >> 2018-01-21 15:34 GMT+01:00 Kieran Kunhya :
> >> >>
> >> >> Only that I can not reproduce without your patch (and that I
On 20/01/18 12:47, Jun Zhao wrote:
> V4: - Fix the wrong ctx lead to scale_vaapi filter crash issue.
> - Follow Mark's suggestion use VAAPIVPPContext as the first field in
> FooVAAPICOntext.
> - Add "ff_" prefix to common VPP function.
> - Add range map to procamp_vaapi filter.
> -
On 19/01/18 16:40, Jorge Ramirez-Ortiz wrote:
> On 01/19/2018 12:30 AM, Michael Niedermayer wrote:
>> On Thu, Jan 18, 2018 at 09:24:20AM +0100, Jorge Ramirez-Ortiz wrote:
>>> On 01/09/2018 11:56 PM, Jorge Ramirez-Ortiz wrote:
From: Mark Thompson
Refcount all of the context informati
2018-01-21 23:48 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 10:06 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
>> > On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos
>> > wrote:
>> >
>> >> 2018-01-21 15:34 GMT+01:00 Kieran Kunhya :
>> >> >>
>> >> >> Only
On Sun, Jan 21, 2018 at 7:11 PM, wm4 wrote:
> On Sun, 21 Jan 2018 10:24:21 +0700
> Muhammad Faiz wrote:
>
>> > I don't trust the atomics use
>> > either, I'm don't want to have to debug that ever.
>>
>> Of course, using atomics is more complicated that usi
On 2018/1/22 7:14, Mark Thompson wrote:
> On 20/01/18 12:47, Jun Zhao wrote:
>> V4: - Fix the wrong ctx lead to scale_vaapi filter crash issue.
>> - Follow Mark's suggestion use VAAPIVPPContext as the first field in
>> FooVAAPICOntext.
>> - Add "ff_" prefix to common VPP function.
>>
>
> As mentioned in the thread for that patch already, writing new code using
> deprecated API should really be avoided.
>
> The way I see it, if someone really needs to know coded w/h (which is
> typically an internal technical detail of no relevance to users), they should
> decode a frame and g
On Sun, Jan 21, 2018 at 12:37:21PM +, Kieran Kunhya wrote:
> On Mon, Jan 1, 2018 at 7:01 PM, Michael Niedermayer
> wrote:
>
> > Hi
>
>
> Patch updated.
> Some of the review comments I decided not to implement in order to keep
> closer to the spec.
honestly, this reasoning makes no sense t
On Mon, 22 Jan 2018, Carl Eugen Hoyos wrote:
2018-01-21 23:48 GMT+01:00 Kieran Kunhya :
On Sun, Jan 21, 2018 at 10:06 PM, Carl Eugen Hoyos
wrote:
2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 2:42 PM, Carl Eugen Hoyos
> wrote:
>
>> 2018-01-21 15:34 GMT+01:00 Kieran
2018-01-22 3:35 GMT+01:00 Marton Balint :
>
>
> On Mon, 22 Jan 2018, Carl Eugen Hoyos wrote:
>
>> 2018-01-21 23:48 GMT+01:00 Kieran Kunhya :
>>>
>>> On Sun, Jan 21, 2018 at 10:06 PM, Carl Eugen Hoyos
>>> wrote:
>>>
2018-01-21 22:45 GMT+01:00 Kieran Kunhya :
> On Sun, Jan 21, 2018 at 2:42
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Hendrik Leppkes
> Sent: Friday, January 19, 2018 6:10 PM
> To: FFmpeg development discussions and patches
>
> Subject: Re: [FFmpeg-devel] [PATCH] ffprobe: Initialize coded_width/height
>
> On Fri, Jan 19, 2018 at 6:05 AM
48 matches
Mail list logo
