On Wed, 8 Mar 2017 02:57:50 +0100
Michael Niedermayer wrote:
> This allows to test or use the code without av_packet_split_side_data() or
> allows applications to separate the side data handling out not
> running it automatically.
>
> It also makes it easier to change the default behavior
>
>
On Tue, 7 Mar 2017 21:38:52 +0100
Hendrik Leppkes wrote:
> On Tue, Mar 7, 2017 at 7:26 PM, wm4 wrote:
> > On Tue, 21 Feb 2017 17:35:53 -0500
> > Vittorio Giovara wrote:
> >
> >> ---
> >> libavformat/matroskadec.c | 64
> >> --
> >> tests/ref/fate
On 3/7/2017 3:47 AM, wm4 wrote:
> On Tue, 7 Mar 2017 00:29:53 -0300
> James Almer wrote:
>
>> This reverts commit faa9d2982969c999ab0e443a226eff116f7f8e4b.
>>
>> This change became superfluous when support for C11 atomics was introduced.
>> Reverting it will make the removal of this implementati
On Wed, Mar 08, 2017 at 01:41:38AM +0200, Jan Ekstrom wrote:
> On Wed, Mar 8, 2017 at 1:01 AM, Michael Niedermayer
> wrote:
> > the fast pskip i mentioned yesterday
> >
> > ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params
> > fast-pskip -vframes 15 -an ref-p.nut
> > ./ff
This allows to test or use the code without av_packet_split_side_data() or
allows applications to separate the side data handling out not
running it automatically.
It also makes it easier to change the default behavior
Signed-off-by: Michael Niedermayer
---
libavcodec/avcodec.h | 5 +
lib
The 3GPP Timed Text (TTXT / tx3g / mov_text) specification counts multibyte
UTF-8 characters as one single character, ffmpeg currently counts bytes. This
patch inserts an if test such that:
1. continuation bytes are not counted during decoding
2. style boxes will not split these characters
Fixes
The 3GPP Timed Text (TTXT / tx3g / mov_text) specification counts multibyte
UTF-8 characters as one single character, ffmpeg currently counts bytes. This
produces files where style boxes have incorrect offsets. This patch introduces:
1. a separate variable that keeps track of the byte count
2. a
ping ?
On 2017/3/3 9:35, Jun Zhao wrote:
> V2: Fix the potential memory leak.2
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
I implemented a 32-bit float GBRAP/GBRP pixel format and used it in vf_zscale.c
and vf_overlay.c. I also implemented an EXR encoder using miniexr that uses the
new float pixel format. I can contribute this if there is interest.
I used the above mods to do HDR video processing that includes overla
The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.
Normality Hypothesis Test:
The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean clo
This should address the mismatch between different archs
Please CC.
--
Vittorio
0001-fate-Do-not-report-side-data-size.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Mar 8, 2017 at 1:01 AM, Michael Niedermayer
wrote:
> the fast pskip i mentioned yesterday
>
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params
> fast-pskip -vframes 15 -an ref-p.nut
> ./ffmpeg -y -i ~/videos/matrixbench_mpeg2.mpg -vcodec libx264 -x264-params
> n
On 3/7/2017 7:35 PM, Vittorio Giovara wrote:
> ---
> ... and this chunk for matroska too.
> Vittorio
>
> libavformat/matroskadec.c | 21 +
> 1 file changed, 9 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index fdc3f26
On 3/7/2017 7:31 PM, Vittorio Giovara wrote:
> ---
> I missed this chunk of review in this version of the set,
> sorry, here is the proper patch.
> Vittorio
>
> libavformat/mov.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
On Tue, Mar 07, 2017 at 07:09:38PM +0100, Michael Niedermayer wrote:
> Fixes: timeout in 730/clusterfuzz-testcase-5265113739165696 (part 1 of 2)
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
>
On Tue, Mar 07, 2017 at 10:08:59AM -0900, Lou Logan wrote:
> On Tue, 7 Mar 2017 04:24:23 +0100, Michael Niedermayer wrote:
>
> > its a long time ago but i faintly remember that the option you are
> > about to remove worked while the one remaining had bugs
>
> Can you provide a reproducible case?
---
I missed this chunk of review in this version of the set,
sorry, here is the proper patch.
Vittorio
libavformat/mov.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index cc098cd977..d5c3949050 100644
--- a/libavformat/mov.c
++
---
... and this chunk for matroska too.
Vittorio
libavformat/matroskadec.c | 21 +
1 file changed, 9 insertions(+), 12 deletions(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index fdc3f268aa..fdb23ab05e 100644
--- a/libavformat/matroskadec.c
+++ b/li
Hello
@Carl :
I make some tests in order to avoid temp buffer, but i have some strange
result, when i not use a temp buffer.
> Time to think about a float pixfmt? I find it weird that we support
> excessively obscure pixfmts like AV_PIX_FMT_BGR4_BYTE, but then have
> hacks like this one if the c
Hello,
In attach patch for decoding uint32 channels in exr files.
Following previous comments, i doesn't use float/color transformation for
this kind of pixel data
in this new version.
Comments welcome
Martin Vignali
Jokyo Images
0001-libavcodec-exr-add-support-for-uint32.patch
Description: B
On 2/28/2017 3:06 PM, Vittorio Giovara wrote:
> On Tue, Feb 28, 2017 at 12:46 PM, Vittorio Giovara
> wrote:
>>>
>>> I think this'll look better as
>>>
>>>
>>> case MATROSKA_VIDEO_PROJECTION_TYPE_EQUIRECTANGULAR:
>>> projection = AV_SPHERICAL_EQUIRECTANGULAR;
>>>
>>> if (tr
On 2/28/2017 1:24 PM, Vittorio Giovara wrote:
> On Tue, Feb 28, 2017 at 10:58 AM, James Almer wrote:
>> On 2/21/2017 8:07 PM, James Almer wrote:
>>> On 2/21/2017 7:35 PM, Vittorio Giovara wrote:
Update the fate test as needed.
---
libavformat/mov.c | 28
On 3/7/2017 5:38 PM, Hendrik Leppkes wrote:
> On Tue, Mar 7, 2017 at 7:26 PM, wm4 wrote:
>> On Tue, 21 Feb 2017 17:35:53 -0500
>> Vittorio Giovara wrote:
>>
>>> ---
>>> libavformat/matroskadec.c | 64
>>> --
>>> tests/ref/fate/matroska-spherical-mono
On Tue, Mar 7, 2017 at 7:26 PM, wm4 wrote:
> On Tue, 21 Feb 2017 17:35:53 -0500
> Vittorio Giovara wrote:
>
>> ---
>> libavformat/matroskadec.c | 64
>> --
>> tests/ref/fate/matroska-spherical-mono | 6 +++-
>> 2 files changed, 66 insertions(+), 4 d
On Tue, Mar 7, 2017 at 5:24 AM, Michael Niedermayer
wrote:
> On Tue, Mar 07, 2017 at 12:20:20AM +0200, Jan Ekström wrote:
>> x264-params does the same thing and this leaves us with a single
>> option that is name-matched with x265-params available in the
>> libx265 wrapper.
>> ---
>> libavcodec/l
On Tue, 7 Mar 2017 04:24:23 +0100, Michael Niedermayer wrote:
> its a long time ago but i faintly remember that the option you are
> about to remove worked while the one remaining had bugs
Can you provide a reproducible case? I will try as well.
> also this would break scripts
I've never liked
On Tue, 21 Feb 2017 17:35:53 -0500
Vittorio Giovara wrote:
> ---
> libavformat/matroskadec.c | 64
> --
> tests/ref/fate/matroska-spherical-mono | 6 +++-
> 2 files changed, 66 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/matroskadec.
Fixes: timeout in 730/clusterfuzz-testcase-5265113739165696 (part 2 of 2)
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/v
Fixes: timeout in 730/clusterfuzz-testcase-5265113739165696 (part 1 of 2)
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp5.c | 5 -
libavcodec/vp56.h| 2 +-
libavcodec/vp56rac.c
Am 01.03.2017 um 13:28 schrieb Timo Rothenpieler:
---
configure | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/configure b/configure
index 0199fec..398d530 100755
--- a/configure
+++ b/configure
@@ -4095,7 +4095,11 @@ probe_cc(){
disable stripping
elif $_c
On Tue, Mar 07, 2017 at 09:20:09AM +0100, Paul B Mahol wrote:
> On 3/7/17, Michael Niedermayer wrote:
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/vp8.c | 2 --
> > 1 file changed, 2 deletions(-)
> >
> > diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> > index 8039e7817e..a3d0
On Tue, Mar 07, 2017 at 08:35:33AM -0500, Ronald S. Bultje wrote:
> Hi,
>
> On Mon, Mar 6, 2017 at 8:41 PM, Michael Niedermayer
> wrote:
>
> > -void ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf,
> > int buf_size)
> > +int ff_vp56_init_range_decoder(VP56RangeCoder *c, const ui
On Tue, Mar 07, 2017 at 03:04:14PM +0100, wm4 wrote:
> On Tue, 7 Mar 2017 14:37:27 +0100
> Michael Niedermayer wrote:
>
> > On Tue, Mar 07, 2017 at 07:44:43AM +0100, wm4 wrote:
[...]
> > The real problem behind all this is of course more complex and a
> > combination of many of our developers b
I uploaded rle_grayscale_noffset.exr using the videolan file uploader.
The rle_grayscale_nooffset.exr image was modified from
https://trac.ffmpeg.org/raw-attachment/ticket/5621/rle_grayscale.exr by zeroing
out the line offset table. The modified file is viewable with Adobe Photoshop
but results
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
---
libavcodec/ffv1enc.c | 3 +++
libavcodec/huffyuvenc.c| 3 +++
tests/
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.
Adds an internal helper function for bitrate guessing.
Signed-off-by: Tobias Rapp
---
libavcodec/internal.h| 6 ++
libavcodec/r
From: Anton Khirnov
(cherry picked from Libav commit d10102d23c9467d4eb84f58e0cd12be284b982f6)
Signed-off-by: Tobias Rapp
---
ffmpeg.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/ffmpeg.c b/ffmpeg.c
index 79c91ff..4117b64 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -3309,6 +3309,8 @@ sta
This patch-set tries to implement observations/suggestions from the discussions
in
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/205902.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-January/206428.html
Changes since version 2:
- replaced own patch with Libav commit for setting en
On 03.03.2017 16:14, Michael Niedermayer wrote:
On Mon, Feb 06, 2017 at 01:33: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
---
[...]
On Tue, 7 Mar 2017 11:09:19 -0300
James Almer wrote:
> On 3/7/2017 11:05 AM, wm4 wrote:
> > On Tue, 7 Mar 2017 20:48:13 +0700
> > Muhammad Faiz wrote:
> >
> >> On Tue, Mar 7, 2017 at 4:17 PM, wm4 wrote:
> >>> On Tue, 7 Mar 2017 16:01:58 +0700
> >>> Muhammad Faiz wrote:
> >>>
> u
On 3/7/2017 11:05 AM, wm4 wrote:
> On Tue, 7 Mar 2017 20:48:13 +0700
> Muhammad Faiz wrote:
>
>> On Tue, Mar 7, 2017 at 4:17 PM, wm4 wrote:
>>> On Tue, 7 Mar 2017 16:01:58 +0700
>>> Muhammad Faiz wrote:
>>>
use ff_thread_once
Suggested-by: wm4
Signed-off-by: Muhammad Fai
On Tue, 7 Mar 2017 20:48:13 +0700
Muhammad Faiz wrote:
> On Tue, Mar 7, 2017 at 4:17 PM, wm4 wrote:
> > On Tue, 7 Mar 2017 16:01:58 +0700
> > Muhammad Faiz wrote:
> >
> >> use ff_thread_once
> >>
> >> Suggested-by: wm4
> >> Signed-off-by: Muhammad Faiz
> >> ---
> >> libavcodec/allcodecs.c
On Tue, 7 Mar 2017 14:37:27 +0100
Michael Niedermayer wrote:
> On Tue, Mar 07, 2017 at 07:44:43AM +0100, wm4 wrote:
> > On Tue, 7 Mar 2017 02:47:36 +0700
> > Muhammad Faiz wrote:
> >
> > > Signed-off-by: Muhammad Faiz
> > > ---
> > > libavcodec/allcodecs.c | 13 ++---
> > > 1 file
On Tue, Mar 7, 2017 at 4:17 PM, wm4 wrote:
> On Tue, 7 Mar 2017 16:01:58 +0700
> Muhammad Faiz wrote:
>
>> use ff_thread_once
>>
>> Suggested-by: wm4
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavcodec/allcodecs.c | 16 +---
>> 1 file changed, 9 insertions(+), 7 deletions(-)
>>
>
On 3/7/17, Michael Niedermayer wrote:
> On Tue, Mar 07, 2017 at 07:44:43AM +0100, wm4 wrote:
>> On Tue, 7 Mar 2017 02:47:36 +0700
>> Muhammad Faiz wrote:
>>
>> > Signed-off-by: Muhammad Faiz
>> > ---
>> > libavcodec/allcodecs.c | 13 ++---
>> > 1 file changed, 10 insertions(+), 3 delet
Hi,
On Mon, Mar 6, 2017 at 8:41 PM, Michael Niedermayer
wrote:
> -void ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf,
> int buf_size)
> +int ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf,
> int buf_size)
> {
> c->high = 255;
> c->bits = -16;
>
On Tue, Mar 07, 2017 at 07:44:43AM +0100, wm4 wrote:
> On Tue, 7 Mar 2017 02:47:36 +0700
> Muhammad Faiz wrote:
>
> > Signed-off-by: Muhammad Faiz
> > ---
> > libavcodec/allcodecs.c | 13 ++---
> > 1 file changed, 10 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavcodec/allcod
2017-03-07 12:30 GMT+01:00 Michał Krasowski :
>>> There are few things that are still not clear to me:
>>> * Why is the 32 bit padding used when the doc says that
>>> 64 bit offset may also be needed?
>>
>>I don't understand your question but you may want to
>>send an update for this sentence.
>
On Tue, Mar 07, 2017 at 11:55:23AM +0100, Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed bec
>> This email may contain Opera confidential information
>
>Please remove this, Carl Eugen
Ah, yes, default footer, sorry.
>> There are few things that are still not clear to me:
>> * Why is the 32 bit padding used when the doc says that
>> 64 bit offset may also be needed?
>
>I don't understand
On Thu, 2 Mar 2017 09:58:28 -0800
Aman Gupta wrote:
> On Thu, Mar 2, 2017 at 1:34 AM, wm4 wrote:
>
> > On Tue, 21 Feb 2017 13:40:08 -0800
> > Aman Gupta wrote:
> >
> > > On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje
> > > wrote:
> > >
> > > > Hi,
> > > >
> > > > On Tue, Feb 21, 2017 a
2017-03-07 11:55 GMT+01:00 Michał Krasowski :
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because some optimized b
On Tue, 7 Mar 2017 11:55:23 +0100
Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because s
On Tue, Mar 7, 2017 at 11:55 AM, Michał Krasowski wrote:
> @Michael Niedermayer
> I have read the documentation, namely
>
> /**
> * @ingroup lavc_decoding
> * Required number of additionally allocated bytes at the end of the input
> bitstream for decoding.
> * This is mainly needed because some
@Michael Niedermayer
I have read the documentation, namely
/**
* @ingroup lavc_decoding
* Required number of additionally allocated bytes at the end of the input
bitstream for decoding.
* This is mainly needed because some optimized bitstream readers read
* 32 or 64 bit at once and could read
Now it has been more than a month since the initial submission
of the Cinepak decoder speedup patch (not counting the proof of concept
posted two months ago).
Since then, more and more of the oftentimes ignorant discussion was
dedicated to the perceived design/development policy conformance (still
On Tue, 7 Mar 2017 16:01:58 +0700
Muhammad Faiz wrote:
> use ff_thread_once
>
> Suggested-by: wm4
> Signed-off-by: Muhammad Faiz
> ---
> libavcodec/allcodecs.c | 16 +---
> 1 file changed, 9 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allco
On Mon, Mar 6, 2017 at 5:06 PM, Muhammad Faiz wrote:
> On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz wrote:
>> On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz wrote:
>>> this gives better frequency response
>>>
>>> update swresample fate and other fates
>>> that depend on resampling
>>>
>>> Signe
use ff_thread_once
Suggested-by: wm4
Signed-off-by: Muhammad Faiz
---
libavformat/allformats.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 35869e3..132e58b 100644
--- a/libavformat/allformats.c
+++
use ff_thread_once
Suggested-by: wm4
Signed-off-by: Muhammad Faiz
---
libavdevice/alldevices.c | 16 +---
libavdevice/avdevice.h | 1 -
2 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index a761be4..75f4ae0 100644
use ff_thread_once
Suggested-by: wm4
Signed-off-by: Muhammad Faiz
---
libavfilter/allfilters.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 15a74c4..df1af8d 100644
--- a/libavfilter/allfilters.c
++
use ff_thread_once
Suggested-by: wm4
Signed-off-by: Muhammad Faiz
---
libavcodec/allcodecs.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index eee322b..6ec7e79 100644
--- a/libavcodec/allcodecs.c
+++ b/liba
2017-02-26 11:07 GMT+01:00 Carl Eugen Hoyos :
> I believe attached patch does not change the logic of the conditions
> but silences a (9 times shown, long-time) gcc warning.
Ping.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://
2017-02-26 12:04 GMT+01:00 Carl Eugen Hoyos :
> 2017-02-26 11:51 GMT+01:00 Nicolas George :
>>> -uint8_t* av_packet_get_side_data(AVPacket *pkt, enum AVPacketSideDataType
>>> type,
>>
>>> +uint8_t* av_packet_get_side_data(
>>> +#if FF_API_CONST_GET_SIDE_DATA
>>> +const
>>> +#endif
>>> +
2017-03-07 9:28 GMT+01:00 Thomas Turner :
> On Mar 6, 2017 11:47 PM, "Carl Eugen Hoyos" wrote:
>
> 2017-03-07 6:36 GMT+01:00 Thomas Turner :
>> ./configure command worked without ccache:
>>
>> ./configure --enable-debug=3 --arch=x86_32 --target-os=linux
>> --extra-cflags=-m32 --extra-ldflags=-m32
This cna happen if the user tries to call the new decode API for
subtitles.
Fixes CID 1402071.
---
libavcodec/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index db3adb18d4..31586d51c5 100644
--- a/libavcodec/utils.c
+++ b/liba
On 3/7/17, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes a few warnings when compiling with newer gcc.
>
> Please comment, Carl Eugen
>
lgtm
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
2017-03-03 0:31 GMT+01:00 Michael Niedermayer :
> On Wed, Mar 01, 2017 at 11:43:15PM +0100, Carl Eugen Hoyos wrote:
>> Subject: [PATCH] lavf/matroska: Support codec ID V_FFV1 for demuxing.
>>
>> Fixes ticket #6206.
>> ---
>> libavformat/matroska.c|1 +
>> libavformat/matroskaenc.c |2
On Mar 6, 2017 11:47 PM, "Carl Eugen Hoyos" wrote:
2017-03-07 6:36 GMT+01:00 Thomas Turner :
> ./configure command worked without ccache:
>
> ./configure --enable-debug=3 --arch=x86_32 --target-os=linux
> --extra-cflags=-m32 --extra-ldflags=-m32 --enable-cross-compile
>
> but after installing th
Hi!
Attached patch fixes a few warnings when compiling with newer gcc.
Please comment, Carl Eugen
From 733cd7d7c02a36779681b43305a75b6639506f97 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Tue, 7 Mar 2017 09:28:00 +0100
Subject: [PATCH] lsws/input: Do not define unused functions.
MIME-V
On 3/7/17, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/vp8.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index 8039e7817e..a3d057d62e 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -2504,8 +
On Tue, Mar 7, 2017 at 1:44 PM, wm4 wrote:
> On Tue, 7 Mar 2017 02:47:36 +0700
> Muhammad Faiz wrote:
>
>> Signed-off-by: Muhammad Faiz
>> ---
>> libavcodec/allcodecs.c | 13 ++---
>> 1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavcodec/allcodecs.c b/libavcode
2017-03-06 18:24 GMT+01:00 Paul B Mahol :
> On 3/6/17, Dzung Hoang wrote:
>> 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 de
73 matches
Mail list logo
