On Wed, 15 Mar 2017 03:47:56 +0100
Marton Balint wrote:
> Signed-off-by: Marton Balint
> ---
> libavcodec/avcodec.h | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index e32f579..8d3d06e 100644
> --- a/libavcodec/avcod
Fixes: 857/clusterfuzz-testcase-5319093760557056
Benchmark changes from 335->333 (so if its not a random fluctuation then it
would be faster)
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h2
Fixes timeout with 847/clusterfuzz-testcase-5291877358108672
Fixes timeout with 850/clusterfuzz-testcase-5721296509861888
This likely will need to be tweaked
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
Fixes: 858/clusterfuzz-testcase-5168477042114560
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/h264_cabac.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h264_
Since subtitles are not yet supported with the new API, CODEC_CAP_DELAY
subtitle codecs (only libzvbi so far) may loose the last few buffered frames in
the end of the stream.
The impact of this is so limited, it seemded better to accept it than losing
the simplification benefits of the new API.
S
Signed-off-by: Marton Balint
---
ffplay.c | 72
1 file changed, 36 insertions(+), 36 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 06d1d22..fd7d9cb 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -558,44 +558,44 @@ static int decoder
Signed-off-by: Marton Balint
---
libavcodec/avcodec.h | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index e32f579..8d3d06e 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -142,8 +142,9 @@
*
* Not all codecs
2017-03-13 17:12 GMT+08:00 Steven Liu :
> when cannot get pkt duration, hlsenc segments duration will
> be set to 0, this patch can fix it.
>
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hlsenc
Am 14.03.17 um 23:11 schrieb Lou Logan:
> On Tue, 14 Mar 2017 22:39:02 +0100
> Thilo Borgmann wrote:
>
>> I made a mistake and included EUR 6.20 in the first place that were
>> not fuel costs.
>
> Was that a pint or a 6-pack?
I wish it were but it actually were cigarettes I promised to bring al
On Fri, 10 Mar 2017 15:45:43 +0100
wm4 wrote:
> On Fri, 10 Mar 2017 15:29:17 +0100
> Michael Niedermayer wrote:
>
> > Hi
> >
> > On Thu, Mar 09, 2017 at 03:45:19PM +0100, wm4 wrote:
> > > Preparation for potentially disabling merged side data by default in the
> > > libs. Do this in particul
On Tue, 14 Mar 2017 22:44:10 +0100 (CET)
Marton Balint wrote:
> On Mon, 13 Mar 2017, Philip Langdale wrote:
>
> > On Mon, 13 Mar 2017 19:39:35 -0700
> > Philip Langdale wrote:
> >
> >> On Tue, 14 Mar 2017 02:49:27 +0100 (CET)
> >> wal...@free.fr wrote:
> >>
> >> > Indeed 7447ec91b5a692121b
On 2017-03-11 18:54 +0100, Alexander Strasser wrote:
> while investigating this issue filed at Debian:
>
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=857369
>
> I found that the error messages can easily be misunderstood.
>
> Though in that particular case the first problem is the place
On Sat, 2017-03-11 at 14:28 +0100, Michael Niedermayer wrote:
> On Thu, Mar 09, 2017 at 03:27:16PM -0500, Calvin Walton wrote:
> > ---
> > libavfilter/avf_concat.c | 15 ++-
> > tests/fate/filter-video.mak | 4 +-
> > tests/ref/fate/filter-concat-vfr | 224
> > +
On Tue, 14 Mar 2017 22:39:02 +0100
Thilo Borgmann wrote:
> I made a mistake and included EUR 6.20 in the first place that were
> not fuel costs.
Was that a pint or a 6-pack?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
These types better reflect the ones described in the specification and
avoid any platform-specific implementation issues.
Signed-off-by: Vittorio Giovara
---
libavformat/dump.c| 2 +-
libavutil/spherical.h | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libav
On Tue, Mar 14, 2017 at 5:27 PM, James Almer wrote:
> On 3/14/2017 6:16 PM, Vittorio Giovara wrote:
>> On Tue, Mar 14, 2017 at 4:41 PM, James Almer wrote:
>>> On 3/14/2017 4:46 PM, Vittorio Giovara wrote:
On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
> On 3/14/2017 12:37 PM, Vitt
On Wed, 15 Mar 2017 09:15:31 +1300
Katherine Frances Nagels wrote:
> From 0dba536e2f98597d9928541517583363bbf9ad00 Mon Sep 17 00:00:00 2001
> From: Katherine Nagels
> Date: Mon, 13 Mar 2017 11:57:11 +1300
> Subject: [PATCH] doc/filters: Add colourspace values for colormatrix filter
>
> ---
> d
On Mon, 13 Mar 2017, Philip Langdale wrote:
On Mon, 13 Mar 2017 19:39:35 -0700
Philip Langdale wrote:
On Tue, 14 Mar 2017 02:49:27 +0100 (CET)
wal...@free.fr wrote:
> Indeed 7447ec91b5a692121b81a04c6501a5811d867775 is working; But I
> have the following errors with the last ffmpeg git stat
On Tue, Mar 14, 2017 at 5:27 PM, James Almer wrote:
> On 3/14/2017 6:16 PM, Vittorio Giovara wrote:
>> On Tue, Mar 14, 2017 at 4:41 PM, James Almer wrote:
>>> On 3/14/2017 4:46 PM, Vittorio Giovara wrote:
On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
> On 3/14/2017 12:37 PM, Vitt
Am 14.03.17 um 22:15 schrieb Thilo Borgmann:
> Hi,
>
>> Alexander Strasser, Thilo Borgmann, Thomas Volkert and myself
>> represented FFmpeg at the Chemnitzer Linuxtage 2017. We showed
>> different filters in action on video screens, talked to guests and
>> other projects and as usual answered m
On 3/14/2017 6:16 PM, Vittorio Giovara wrote:
> On Tue, Mar 14, 2017 at 4:41 PM, James Almer wrote:
>> On 3/14/2017 4:46 PM, Vittorio Giovara wrote:
>>> On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
On 3/14/2017 12:37 PM, Vittorio Giovara wrote:
> On Sun, Mar 12, 2017 at 11:21 PM,
On Mon, Mar 13, 2017 at 12:53:27PM +0100, Michael Niedermayer wrote:
> On Mon, Mar 13, 2017 at 09:51:40AM +0100, Paul B Mahol wrote:
> > On 3/13/17, Michael Niedermayer wrote:
> > > Benchmarks with START_TIMER indicate that the code is faster with
> > > unsigned,
> > > (that is
> > > with the pat
On Mon, Mar 13, 2017 at 08:45:07PM +0100, Michael Niedermayer wrote:
> Fixes: 823/clusterfuzz-testcase-6727060074528768
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pictordec.c |
On Tue, Mar 14, 2017 at 4:41 PM, James Almer wrote:
> On 3/14/2017 4:46 PM, Vittorio Giovara wrote:
>> On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
>>> On 3/14/2017 12:37 PM, Vittorio Giovara wrote:
On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
wrote:
> On Sun, Mar
Hi,
> Alexander Strasser, Thilo Borgmann, Thomas Volkert and myself
> represented FFmpeg at the Chemnitzer Linuxtage 2017. We showed
> different filters in action on video screens, talked to guests and
> other projects and as usual answered many user questions.
we also took some pictures to updat
On Tue, 14 Mar 2017 21:53:31 +0100 (CET)
wal...@free.fr wrote:
> I've a first patch, working with the software decoder. But it fails
> with the crystalhd decoder. If you know how to fix it.
>
> Wallak.
It will take more than that. You need to decouple send and receive -
that's the whole point of
I've a first patch, working with the software decoder. But it fails with the
crystalhd decoder. If you know how to fix it.
Wallak.
- Mail original -
De: "Philip Langdale"
À: "Marton Balint"
Cc: "FFmpeg development discussions and patches"
Envoyé: Mardi 14 Mars 2017 04:40:34
Objet: Re
On 3/14/2017 4:46 PM, Vittorio Giovara wrote:
> On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
>> On 3/14/2017 12:37 PM, Vittorio Giovara wrote:
>>> On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
>>> wrote:
On Sun, Mar 12, 2017 at 08:54:07PM -0400, Ronald S. Bultje wrote:
>
On Wed, Mar 15, 2017 at 9:00 AM, Michael Niedermayer wrote:
>
> Thats not a name, i assume you want the authors (your?) name in there
> it cannot be changed after pushing so please correct this unless
> you want it to be kfrn
>
Now changed - see attached. Thank you Michael, and apologies that I m
On Mon, Mar 13, 2017 at 12:00:39PM +1300, Katherine Frances Nagels wrote:
> Apologies - now with more useful commit message.
> I actually remade the commit since I realized I wasn't connected to my
> usual git login. I hope you can kill the other commit. Sorry for this. :(
>
> Contents as before:
On Tue, Mar 14, 2017 at 12:12 PM, James Almer wrote:
> On 3/14/2017 12:37 PM, Vittorio Giovara wrote:
>> On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
>> wrote:
>>> On Sun, Mar 12, 2017 at 08:54:07PM -0400, Ronald S. Bultje wrote:
Hi,
On Sun, Mar 12, 2017 at 7:32 PM, James
Hi All,
SSIMWave provides the media and entertainment industry the capability to
perform end-to-end video quality measurement and optimization. Our team is
renowned world-wide for its academic contributions and has recently won a
Primetime Engineering Emmy award. We are interested in contributing
The EXR decoder cannot handle the image files included in NVidia's HDR SDK.
After debugging, I found that the line offset table in the image files
contained 0's. Other EXR decoders, including the official OpenEXR decoder, can
detect and reconstruct missing line offset tables, so I added some cod
I use the commad line below:
ffplay -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1
-reconnect_delay_max 4000 http://movie_url.mp4
I find that if network source down, ffplay keep reconnect only a few seconds
even if I set -reconnect_delay_max 4000. So I reopen http connection cyclically
u
On 3/14/2017 2:09 PM, wm4 wrote:
> On Tue, 14 Mar 2017 13:50:53 -0300
> James Almer wrote:
>
>> On 3/14/2017 1:33 PM, wm4 wrote:
>>> On Tue, 14 Mar 2017 17:02:34 +0100
>>> Hendrik Leppkes wrote:
>>>
On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> On Tue, 14 Mar 2017 14:19:24 +
>
On Tue, Mar 14, 2017 at 6:18 PM, wm4 wrote:
>
>> Now back to the current issue.
>>
>> Do you agree with the fact that uint32_t is a better technical choice?
>> (I think the main argument is that it's a pain to have proper FATE
>> coverage if you don't?)
>
> We've already established that the curre
On Tue, 14 Mar 2017 17:59:38 +0100
Clément Bœsch wrote:
> On Tue, Mar 14, 2017 at 05:33:41PM +0100, wm4 wrote:
> > On Tue, 14 Mar 2017 17:02:34 +0100
> > Hendrik Leppkes wrote:
> >
> > > On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> > > > On Tue, 14 Mar 2017 14:19:24 +
> > > > Rostisla
On Tue, 14 Mar 2017 13:50:53 -0300
James Almer wrote:
> On 3/14/2017 1:33 PM, wm4 wrote:
> > On Tue, 14 Mar 2017 17:02:34 +0100
> > Hendrik Leppkes wrote:
> >
> >> On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> >>> On Tue, 14 Mar 2017 14:19:24 +
> >>> Rostislav Pehlivanov wrote:
> >>>
On Tue, Mar 14, 2017 at 05:33:41PM +0100, wm4 wrote:
> On Tue, 14 Mar 2017 17:02:34 +0100
> Hendrik Leppkes wrote:
>
> > On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> > > On Tue, 14 Mar 2017 14:19:24 +
> > > Rostislav Pehlivanov wrote:
> > >
> > >> On 14 March 2017 at 13:38, wm4 wrote:
>
On 3/14/2017 1:33 PM, wm4 wrote:
> On Tue, 14 Mar 2017 17:02:34 +0100
> Hendrik Leppkes wrote:
>
>> On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
>>> On Tue, 14 Mar 2017 14:19:24 +
>>> Rostislav Pehlivanov wrote:
>>>
On 14 March 2017 at 13:38, wm4 wrote:
> On Tue, 14 Mar 20
On Tue, 14 Mar 2017 17:02:34 +0100
Hendrik Leppkes wrote:
> On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> > On Tue, 14 Mar 2017 14:19:24 +
> > Rostislav Pehlivanov wrote:
> >
> >> On 14 March 2017 at 13:38, wm4 wrote:
> >>
> >> > On Tue, 14 Mar 2017 10:24:10 -0300
> >> > James Almer w
On 3/14/2017 12:37 PM, Vittorio Giovara wrote:
> On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
> wrote:
>> On Sun, Mar 12, 2017 at 08:54:07PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Mar 12, 2017 at 7:32 PM, James Almer wrote:
>>>
On 3/12/2017 6:16 PM, Michael Niedermay
On Tue, Mar 14, 2017 at 4:49 PM, wm4 wrote:
> On Tue, 14 Mar 2017 14:19:24 +
> Rostislav Pehlivanov wrote:
>
>> On 14 March 2017 at 13:38, wm4 wrote:
>>
>> > On Tue, 14 Mar 2017 10:24:10 -0300
>> > James Almer wrote:
>> >
>> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
>> > > > On
On Tue, Mar 14, 2017 at 4:37 PM, Vittorio Giovara
wrote:
> On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
> wrote:
>> On Sun, Mar 12, 2017 at 08:54:07PM -0400, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Sun, Mar 12, 2017 at 7:32 PM, James Almer wrote:
>>>
>>> > On 3/12/2017 6:16 PM, Micha
On Tue, 14 Mar 2017 14:19:24 +
Rostislav Pehlivanov wrote:
> On 14 March 2017 at 13:38, wm4 wrote:
>
> > On Tue, 14 Mar 2017 10:24:10 -0300
> > James Almer wrote:
> >
> > > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > > > On 14 March 2017 at 11:29, Michael Niedermayer > >
>
On Sun, Mar 12, 2017 at 11:21 PM, Michael Niedermayer
wrote:
> On Sun, Mar 12, 2017 at 08:54:07PM -0400, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sun, Mar 12, 2017 at 7:32 PM, James Almer wrote:
>>
>> > On 3/12/2017 6:16 PM, Michael Niedermayer wrote:
>> > > Using the same type across platforms is
Hello,
Doesn't have time yet to take a look.
Can you send a clean patch :
https://ffmpeg.org/developer.html#Submitting-patches-1
Martin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On 3/14/17, Dzung Hoang wrote:
> What is the next step to get this issue resolved?
Posting correct patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
add kVTCompressionPropertyKey_DataRateLimits support by rc_max_bitrate
Reviewed-by: Rick Kern
Signed-off-by: Steven Liu
---
libavcodec/videotoolboxenc.c | 47
1 file changed, 47 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/vi
What is the next step to get this issue resolved?
Dzung Hoang
From: Carl Eugen Hoyos
To: FFmpeg development discussions and patches
Sent: Tuesday, March 7, 2017 2:02 AM
Subject: Re: [FFmpeg-devel] [PATCH] avcodec/exr
2017-03-06 18:24 GMT+01:00 Paul B Mahol :
> On 3/6/17, Dzung Hoan
On 14 March 2017 at 13:38, wm4 wrote:
> On Tue, 14 Mar 2017 10:24:10 -0300
> James Almer wrote:
>
> > On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > > On 14 March 2017 at 11:29, Michael Niedermayer >
> > > wrote:
> > >
> > >>
> > >> What about the spherical API size_t / uint32_t issue ?
On March 12, 2017 at 11:55:55 PM, Steven Liu (l...@chinaffmpeg.org) wrote:
add kVTCompressionPropertyKey_DataRateLimits support by rc_max_bitrate
Signed-off-by: Steven Liu
---
libavcodec/videotoolboxenc.c | 27 +++
1 file changed, 27 insertions(+)
diff --git a/libavcodec/
On Tue, 14 Mar 2017 10:24:10 -0300
James Almer wrote:
> On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> > On 14 March 2017 at 11:29, Michael Niedermayer
> > wrote:
> >
> >>
> >> What about the spherical API size_t / uint32_t issue ?
> >> we can change it before the release but not after i
On 3/14/2017 9:31 AM, Rostislav Pehlivanov wrote:
> On 14 March 2017 at 11:29, Michael Niedermayer
> wrote:
>
>>
>> What about the spherical API size_t / uint32_t issue ?
>> we can change it before the release but not after it
>>
>>
> IMO its better to have the same type on all platforms. It also
On 11.03.2017 16:29, Michael Niedermayer wrote:
On Tue, Mar 07, 2017 at 03:39:19PM +0100, Tobias Rapp wrote:
Allows to get a more realistic total bitrate (and estimated file size)
in avi_write_header. Previously a static default value of 200k was
assumed.
Signed-off-by: Tobias Rapp
---
libavc
On 11.03.2017 16:07, Michael Niedermayer wrote:
On Tue, Mar 07, 2017 at 03:39:17PM +0100, Tobias Rapp wrote:
From: Anton Khirnov
(cherry picked from Libav commit d10102d23c9467d4eb84f58e0cd12be284b982f6)
Signed-off-by: Tobias Rapp
---
ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
maybe
On 14 March 2017 at 11:29, Michael Niedermayer
wrote:
>
> What about the spherical API size_t / uint32_t issue ?
> we can change it before the release but not after it
>
>
IMO its better to have the same type on all platforms. It also doesn't make
sense to use size_t for something describing a po
Hi all
are there any issues/tickets that block making 3.3 ?
What about the spherical API size_t / uint32_t issue ?
we can change it before the release but not after it
Thanks
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I am the wisest man alive, for I know one t
58 matches
Mail list logo
