On Thu, Sep 01, 2016 at 08:52:34PM -0600, Joseph Parmelee wrote:
>
> Greetings:
>
> I found that ffmpeg configure crashes with the new openssl-1.1.0.
what do you mean by crash ?
> This is
> due to changes made in openssl-1.1.0 to both the header file ssl.h and to
> the libraries libssl.so and
On Fri, Aug 05, 2016 at 11:24:35PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-08-04 16:01 GMT+02:00 James Almer :
> >> So the advantage is that compilation gets measurably faster
> >> with your patch?
> >
> > No, our headers are not the Boost package. i just want to reduce
> > dependencies so t
On 09/02/2016 05:35 PM, Michael Niedermayer wrote:
> On Fri, Sep 02, 2016 at 05:31:35PM -0700, Jonathan Campbell wrote:
>>> should be in a different patch
>>> also needs minor version bump and APIChanges update
>>>
>>> also please generate patches with git format-patch or git send-email
>>> see the
Hi!
2016-09-03 12:50 GMT+02:00 Jonathan Campbell :
> Here you go (as attachments).
The changes to lfg and the version bump must be one patch.
> +{ "cons_noisegen", "enable consistent noise generation",
> OFFSET(consistent_noise_generation), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, PAR
> },
I
2016-09-02 23:12 GMT+02:00 James Almer :
> Ping for set.
Both patches look very useful to me.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Hi!
2016-09-02 22:53 GMT+02:00 Michael Niedermayer :
> On Fri, Sep 02, 2016 at 05:14:10PM +0200, Carl Eugen Hoyos wrote:
>>
>> Attached patch fixes ticket #5819, I couldn't immediately find information
>> if such quantization tables are valid.
>> If ok, I'll also fix this in the jpeg auto-detectio
2016-09-03 0:06 GMT+02:00 Timo Rothenpieler :
> On 9/2/2016 7:16 PM, Carl Eugen Hoyos wrote:
>> 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler :
>>
>>> +#if AV_HAVE_BIGENDIAN
>>> +static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[],
>>
>> Why does this function not work on both big
Hi!
2016-09-02 16:36 GMT+02:00 Timo Rothenpieler :
> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0);
Why is "& 0xFFC0" necessary?
(Same below.)
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailma
2016-09-02 4:07 GMT+02:00 Michael Niedermayer :
>> Subject: [PATCH] lavf/httpauth: Do case-insensitive http header checks.
>>
>> Fixes ticket #5786.
>
> LGTM
Patch applied.
Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
htt
2016-08-31 17:35 GMT+02:00 Carl Eugen Hoyos :
>
> Attached patch fixes ticket #4990 concerning the output file.
> It is possible that there is nothing to fix though, the input
> file is "dirty" and "dupthresh" is not underbid by two visually
> identical frames.
Please ignore, the patch (that I had
2016-08-29 12:59 GMT+02:00 Michael Niedermayer :
> On Mon, Aug 29, 2016 at 12:12:34AM +0200, Carl Eugen Hoyos wrote:
>> Fixes ticket #5805.
>
> LGTM,
Patch applied.
> can you add a fate test for this ?
Please upload the sample to fate-suite/jpg/.
Thank you, Carl Eugen
_
2016-08-03 18:42 GMT+02:00 Carl Eugen Hoyos :
>
> Attached patch gives users (and testers) a chance to know why
> webm_chunk muxing fails.
Patch applied, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/
On 9/3/2016 1:47 PM, Carl Eugen Hoyos wrote:
> 2016-09-03 0:06 GMT+02:00 Timo Rothenpieler :
>> On 9/2/2016 7:16 PM, Carl Eugen Hoyos wrote:
>>> 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler :
>>>
+#if AV_HAVE_BIGENDIAN
+static int planar8ToP010leWrapper(SwsContext *c, const uint8_t *src[]
On 9/3/2016 1:46 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-02 16:36 GMT+02:00 Timo Rothenpieler :
>
>> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0);
>
> Why is "& 0xFFC0" necessary?
> (Same below.)
Because P010 expects the 10 bits in the 10 most significant bit.
I'm not
2016-09-03 14:54 GMT+02:00 Timo Rothenpieler :
>>> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0);
>>
>> Why is "& 0xFFC0" necessary?
>> (Same below.)
>
> Because P010 expects the 10 bits in the 10 most significant bit.
> I'm not 100% sure if the other 6 bits are undefined or 0,
On 9/3/2016 3:15 PM, Carl Eugen Hoyos wrote:
> 2016-09-03 14:54 GMT+02:00 Timo Rothenpieler :
>
+AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0);
>>>
>>> Why is "& 0xFFC0" necessary?
>>> (Same below.)
>>
>> Because P010 expects the 10 bits in the 10 most significant bit.
>> I'
2016-09-03 15:18 GMT+02:00 Timo Rothenpieler :
> On 9/3/2016 3:15 PM, Carl Eugen Hoyos wrote:
>> 2016-09-03 14:54 GMT+02:00 Timo Rothenpieler :
>>
> +AV_WL16(&dstUV[2*x ], (t | (t << 8)) & 0xFFC0);
Why is "& 0xFFC0" necessary?
(Same below.)
>>>
>>> Because P010 e
2016-08-16 17:53 GMT+02:00 Carl Eugen Hoyos :
> Attached patch fixes ticket #5774.
Patch applied.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
---
libswscale/swscale_unscaled.c| 57
tests/ref/fate/filter-pixdesc-p010le | 2 +-
tests/ref/fate/filter-pixfmts-copy | 2 +-
tests/ref/fate/filter-pixfmts-crop | 2 +-
tests/ref/fate/filter-pixfmts-field | 2 +-
tests/ref/fate/filter-pixfmts-
> @@ -236,6 +237,57 @@ static int planarToP010Wrapper(SwsContext *c, const
> uint8_t *src8[],
> return srcSliceH;
> }
>
> +#if AV_HAVE_BIGENDIAN || 1
Nevermind the || 1, left over from testing speed differences and forgot
to remove it.
___
ffmpe
The filter needs input frames with color properties filled out by
the decoder. Since this is not always possible, add input options to
the filter so that user may override color space, color primaries,
transfer characteristics, and color range, as well as a generic option
to set all properties at o
On 9/3/2016 8:09 AM, Carl Eugen Hoyos wrote:
> The changes to lfg and the version bump must be one patch.
They will be squashed. See
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198446.html
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-August/198448.html
https://ffmpeg.org/pipermail/ffm
On 9/3/2016 7:50 AM, Jonathan Campbell wrote:
> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
> length) {
> +unsigned int beg, end, segm;
> +const AVCRC *avcrc;
> +uint32_t crc = 1;
> +
> +c->index = 0;
The AVLFG struct should IMO remain untouched if init
On 9/3/2016 8:24 AM, Carl Eugen Hoyos wrote:
> 2016-09-02 23:12 GMT+02:00 James Almer :
>
>> Ping for set.
>
> Both patches look very useful to me.
>
> Carl Eugen
Pushed, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org
On 09/03/2016 04:09 AM, Carl Eugen Hoyos wrote:
> Hi!
>
> 2016-09-03 12:50 GMT+02:00 Jonathan Campbell :
>
>> Here you go (as attachments).
>
> The changes to lfg and the version bump must be one patch.
>
>> +{ "cons_noisegen", "enable consistent noise generation",
>> OFFSET(consistent_noi
On Sat, Sep 03, 2016 at 02:26:36PM +0200, Carl Eugen Hoyos wrote:
> 2016-08-29 12:59 GMT+02:00 Michael Niedermayer :
> > On Mon, Aug 29, 2016 at 12:12:34AM +0200, Carl Eugen Hoyos wrote:
>
> >> Fixes ticket #5805.
> >
> > LGTM,
>
> Patch applied.
>
> > can you add a fate test for this ?
>
> Ple
cuvid/nvdecode also supports mpeg1, mpeg2, h.263/mpeg4-asp and mjpeg.
It should, in theory, also support wmv3 via the vc1 support, given
that vdpau supports this. However, it failed to play wmv3 samples
which vdpau played correctly, so I'm not sure what to make of it.
Signed-off-by: Philip Langda
On 2 September 2016 at 02:59, Jonathan Campbell <
jonat...@impactstudiopro.com> wrote:
> I finished the consistent noise generation patch for AC-3 decoding.
>
> Set AVOption "cons_noisegen" to 1 (true) to enable it.
>
> Git repository:
> https://github.com/joncampbell123/FFmpeg.git
>
> commit dbd0
On 9/3/2016 11:07 AM, James Almer wrote:
>> > +
>> > +/* avoid integer overflow in the loop below. */
>> > +if (length > (UINT_MAX / 128U)) return AVERROR(EINVAL);
>> > +
>> > +/* across 64 segments of the incoming data,
>> > + * do a running crc of each segment and store the crc as
Hi!
2016-09-03 18:27 GMT+02:00 Jonathan Campbell :
> Do you understand now why this is useful for NLE software,
Of course.
> but should not be enabled by default?
Only if I completely underestimate the additional cpu usage.
Thank you, Carl Eugen
___
On 09/03/2016 01:32 PM, Rostislav Pehlivanov wrote:
> On 2 September 2016 at 02:59, Jonathan Campbell <
> jonat...@impactstudiopro.com> wrote:
>
>> I finished the consistent noise generation patch for AC-3 decoding.
>>
>> Set AVOption "cons_noisegen" to 1 (true) to enable it.
>>
>> Git repository:
Hi!
Attached is a patch to test ticket #5805.
Unrelated: There is an unused (never used) sample in fate/jpg, see
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181127.html
Please comment, Carl Eugen
From 7fa7dd607866ba8106e1964e794228c900847c8a Mon Sep 17 00:00:00 2001
From: Carl Eugen H
2016-09-03 19:58 GMT+02:00 Michael Niedermayer :
>> > can you add a fate test for this ?
>>
>> Please upload the sample to fate-suite/jpg/.
>
> uploaded
Patch sent.
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailm
On 09/03/2016 07:07 AM, James Almer wrote:
> On 9/3/2016 7:50 AM, Jonathan Campbell wrote:
>> +int av_lfg_init_from_data(AVLFG *c, const uint8_t *data, unsigned int
>> length) {
>> +unsigned int beg, end, segm;
>> +const AVCRC *avcrc;
>> +uint32_t crc = 1;
>> +
>> +c->index = 0;
>
On Sat, Sep 03, 2016 at 12:06:39PM -0700, Sasi Inguva wrote:
> Hi Michael,
>
> In fact from audacity I see that out-ingu.wav out-mp3.wav are almost
> equivalent,
They do not match. (and that is alot more vissible if you scale the
time axis up a bit)
You also dont use the existing API for handlin
On Sun, Sep 04, 2016 at 12:36:46AM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached is a patch to test ticket #5805.
> Unrelated: There is an unused (never used) sample in fate/jpg, see
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/181127.html
>
> Please comment, Carl Eugen
> fate/
While I'm finishing up the CNG patch, I'd like to start developing another
feature that I think FFMPEG should be able to at least expose through the API.
I'm aware that FFMPEG supports subtitle tracks, but as far as I know, doesn't
support caption data embedded in the video stream itself.
Some
AVFrame already has some support for embedded 608/708 subtitles in a form
of side data (AV_FRAME_DATA_A53_CC tag), and some decoders/encoders already
can handle that.
Main issue with this approach is that video frames can be modified, removed
or duplicated (mainly by video filters but also by ffmpe
On 09/03/2016 11:26 PM, Andrey Turkin wrote:
> AVFrame already has some support for embedded 608/708 subtitles in a form
> of side data (AV_FRAME_DATA_A53_CC tag), and some decoders/encoders already
> can handle that.
> Main issue with this approach is that video frames can be modified, removed
> o
39 matches
Mail list logo
