On 09/01/2016 08:01 PM, Michael Niedermayer wrote:
this causes a compiler warning:
libavcodec/metacodec.c: In function ‘meta_encode’:
libavcodec/metacodec.c:41:21: warning: assignment from incompatible pointer
type [enabled by default]
avpkt->buf = av_buffer_alloc(frame->nb_samples);
ffplay: fix memleak in audio_thread
Signed-off-by: LiuQi
---
ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index adbe9cb..d7f7200 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2127,7 +2127,7 @@ static int audio_thread(void *arg)
av_
>> +uint16_t *src[] = {
>> +(uint16_t*)(src8[0] + srcStride[0] * srcSliceY),
>> +(uint16_t*)(src8[1] + srcStride[1] * srcSliceY),
>> +(uint16_t*)(src8[2] + srcStride[2] * srcSliceY)
>
> this looks odd, why is this needed ?
>
Without it, every
dstY[x] = src[0][x] << 6
On Fri, Sep 02, 2016 at 10:38:39AM +0200, Timo Rothenpieler wrote:
> >> +uint16_t *src[] = {
> >> +(uint16_t*)(src8[0] + srcStride[0] * srcSliceY),
> >> +(uint16_t*)(src8[1] + srcStride[1] * srcSliceY),
> >> +(uint16_t*)(src8[2] + srcStride[2] * srcSliceY)
> >
> > this
Am 02.09.2016 um 11:02 schrieb Michael Niedermayer:
> On Fri, Sep 02, 2016 at 10:38:39AM +0200, Timo Rothenpieler wrote:
+uint16_t *src[] = {
+(uint16_t*)(src8[0] + srcStride[0] * srcSliceY),
+(uint16_t*)(src8[1] + srcStride[1] * srcSliceY),
+(uint16_
> Just sticking my head above the parapet, but shouldn’t things like...
>
>> +for (x = 0; x < c->srcW / 2; x++) {
>> +dstUV[x*2 ] = src[1][x] << 6;
>> +dstUV[x*2+1] = src[2][x] << 6;
>> +}
>
> …be more efficiently written as...
>
> uint16_
> On 2 Sep 2016, at 12:12, Timo Rothenpieler wrote:
>
>> Just sticking my head above the parapet, but shouldn’t things like...
>>
>>> +for (x = 0; x < c->srcW / 2; x++) {
>>> +dstUV[x*2 ] = src[1][x] << 6;
>>> +dstUV[x*2+1] = src[2][x] << 6;
>>> +
On 09/01/2016 11:30 PM, Michael Niedermayer wrote:
missing alloc failure check
Fixed.
missing checks
anything comming out of av_stream_get_side_data() could originate from
an attacker and have manually choosen evil values.
Oh, well it seems I have trusted it quite a bit more. I will harden
Hello Timo,
I tested your patch. It increases UHD HEVC 10 bits Main10 encoding
performance a lot while doing YUV420P10LE to P010LE (same level to Oliver's
original 10 bits HEVC encoding patch).
Your patch together with current FFmpeg git source, encoding performance
increase from 40-42 fps to 69-
>>>
>>> …or is that really old-school and a modern compiler does all that when
>>> optimising?
>>>
>>> Or is readability considered more important than marginal gains in
>>> performance?
>>>
>>> Oliver (time travelling from the 1980s)
>>
>> You would still have to add the remaining stride.
>> The
On Thu, Sep 01, 2016 at 06:17:11PM -0700, Brett Harrison wrote:
> Most recent patch. I was evaluating fontsize too early before when using
> the 'n' variable in equations.
>
> On Thu, Sep 1, 2016 at 3:44 PM, Brett Harrison
> wrote:
>
> > Any feedback on this newest patch?
> >
> > On Tue, Aug 30
On 8/30/16, Davinder Singh wrote:
> On Mon, Aug 29, 2016 at 8:59 PM Paul B Mahol wrote:
> [...]
>
> And using avcodec* stuff is in lavfi is not needed.
>
> uses AVPixFmtDesc now. should I also not use libavcodec/mathops.h? median
> of 3 function is shared. can it be moved?
>
> updated patch attac
On Thu, Sep 01, 2016 at 06:59:46PM -0700, Jonathan Campbell 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 dbd086586f0ad1591ea201
On Thu, Sep 01, 2016 at 18:17:11 -0700, Brett Harrison wrote:
> Most recent patch. I was evaluating fontsize too early before when using
> the 'n' variable in equations.
> +av_log(ctx, AV_LOG_ERROR, "Font not open\n");
I was wondering: Was does this message tell the user?
> +if ((re
On Fri, Sep 02, 2016 at 14:10:41 +0200, Moritz Barsnick wrote:
> > +if ((ret = update_fontsize(ctx))) {
> You were meaning to write
>if (ret = update_fontsize(ctx)) {
> or
>if ((ret = update_fontsize(ctx)) < 0) {
> ?? (Too many brackets the way you did it.)
Sorry, probably make
Le septidi 17 fructidor, an CCXXIV, Moritz Barsnick a écrit :
> Sorry, probably makes sense, equal to
> if ((ret = update_fontsize(ctx)) != 0) {
>
> I'm still not *really* sure whether the second set of brackets is
> required to have "if" check the assigned ret (I thought not). I'll let
>
> Just one note; encoding from YUV420P to P010LE is still slow. It will be
> nice a similar patch is done for YUV420P 8bits to P010LE 10 bits
> convertion. (For reason:
> http://x264.nl/x264/10bit_02-ateme-why_does_10bit_save_bandwidth.pdf)
>
Ali
I’m curious as whether you have managed to save
On Fri, Sep 02, 2016 at 14:20:37 +0200, Nicolas George wrote:
> You mean the parentheses? Well, if you are not sure, then the parentheses
> are necessary. We are not playing golf, we want code that is readable and
> robust.
>
> For reference, comparisons have precedence over assignments. That mean
On Fri, Sep 02, 2016 at 15:40:54 +0300, Oliver Collyer wrote:
> In my test, my sample file went from 80mb encoded down to 69mb with
> the same global quality setting. (using -constq -global_quality 21)
I also wonder whether the 10-bit algorithms have the same visual result
as the 8-bit algorithms,
Le septidi 17 fructidor, an CCXXIV, Moritz Barsnick a écrit :
> *Assuming* he means "assign update_fontsize()'s return value to ret,
> and check whether ret is != 0", which would correspond to the more
> verbose
> if ((ret = update_fontsize(ctx)) != 0) {
>
> is it sufficient to say:
> if (ret
Hi Oliver,
Yes, for same quality I also noticed a bandwidth usage drop like 4-6%. This
is my case.
But as you know it depends on the samples you work.
For CBR, you are right, it should bring a higher quality. I compared decode
of PSNR for CBR 8 bits and 10 bits HD NVENC HEVC encodded content with
Could you please make sure to properly reply to mails in the future?
Otherwise this causes quite a mess to anyone who's viewing the ML in a
threaded view, which includes the list archives.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
---
libswscale/swscale_unscaled.c| 83
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-
---
libswscale/swscale_unscaled.c | 44 +++
1 file changed, 44 insertions(+)
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index b231abe..f0b2fbf 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@
Hi!
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-detection.
Please comment, Carl Eugen
From 9ddca61b0feeae5ce682758fb12d8bb05cf72558 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Da
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 and little endian hardware?
Carl Eugen
___
ffmpeg-devel mailin
CRC computation isn't fast enough? What should I use then? A sum of byte
values?
Jonathan Campbell
CASTUS
On 09/02/2016 04:50 AM, Michael Niedermayer wrote:
On Thu, Sep 01, 2016 at 06:59:46PM -0700, Jonathan Campbell wrote:
I finished the consistent noise generation patch for AC-3 decoding.
On 09/02/2016 04:50 AM, Michael Niedermayer wrote:
On Thu, Sep 01, 2016 at 06:59:46PM -0700, Jonathan Campbell 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/FF
Greetings:
I found that ffmpeg configure crashes with the new openssl-1.1.0. 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 libcrypto.so. The symbol SSL_library_init no
longer exists in either library; it has been replaced by OPENS
On Aug 31, 2016 5:23 AM, "Michael Niedermayer"
wrote:
>
> On Tue, Aug 30, 2016 at 06:37:22PM -0700, Sasi Inguva wrote:
> > On Sun, Aug 28, 2016 at 3:10 AM, Michael Niedermayer
> > wrote:
> >
> > > On Sat, Aug 27, 2016 at 03:30:24PM -0700, Sasi Inguva wrote:
> > > > On Fri, Aug 26, 2016 at 5:55 PM
On Fri, Sep 02, 2016 at 10:19:23AM -0700, Jonathan Campbell wrote:
[...]
> CRC computation isn't fast enough? What should I use then? A sum of
> byte values?
av_lfg_init() calls av_md5_sum()
av_md5_sum() is too slow to be called per ac3 frame
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF
On 09/02/2016 01:01 PM, Michael Niedermayer wrote:
On Fri, Sep 02, 2016 at 10:19:23AM -0700, Jonathan Campbell wrote:
[...]
CRC computation isn't fast enough? What should I use then? A sum of
byte values?
av_lfg_init() calls av_md5_sum()
av_md5_sum() is too slow to be called per ac3 frame
[..
Signed-off-by: Paul B Mahol
---
libavfilter/vf_palettegen.c | 27 +++
1 file changed, 23 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
index fccc5ca..3018b06 100644
--- a/libavfilter/vf_palettegen.c
+++ b/libavfilter/
Signed-off-by: Paul B Mahol
---
libavfilter/vf_paletteuse.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
index dece05a..ed51cfe 100644
--- a/libavfilter/vf_paletteuse.c
+++ b/libavfilter/vf_paletteu
On Fri, 2 Sep 2016, Steven Liu wrote:
ffplay: fix memleak in audio_thread
Signed-off-by: LiuQi
---
ffplay.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffplay.c b/ffplay.c
index adbe9cb..d7f7200 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -2127,7 +2127,7 @@ static int audi
On Fri, Sep 02, 2016 at 05:14:10PM +0200, Carl Eugen Hoyos wrote:
> Hi!
>
> 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-detection.
they are valid
LGTM
thx
[...]
--
Michael
On Fri, Sep 02, 2016 at 01:13:33PM -0700, Jonathan Campbell wrote:
>
> On 09/02/2016 01:01 PM, Michael Niedermayer wrote:
> >On Fri, Sep 02, 2016 at 10:19:23AM -0700, Jonathan Campbell wrote:
> >[...]
> >>CRC computation isn't fast enough? What should I use then? A sum of
> >>byte values?
> >av_lf
On 8/26/2016 3:51 PM, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/utils.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 138125a..7e99c58 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.
On 9/1/2016 6:23 AM, Timo Rothenpieler wrote:
> For some reason, when compiling with gcc-asan and a recent enough gcc
> version(seen on 5.3+ so far), linking dlopen works without -ldl, but
> dlsym fails with:
>
> undefined reference to symbol 'dlsym@@GLIBC_2.2.5'
>
> So this patchs checks for bot
On Fri, Sep 02, 2016 at 04:36:34PM +0200, Timo Rothenpieler wrote:
> ---
> libswscale/swscale_unscaled.c | 44
> +++
> 1 file changed, 44 insertions(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No snowfla
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 and little endian hardware?
It does, but it's signi
Carlos Fernandez Sanz 于2016年9月3日 周六上午1:13写道：
> On Thu, Sep 1, 2016 at 3:40 PM, Steven Liu
> wrote:
> >
> > Maybe give a warning message and exit is a better way, if the basename is
>
> Checked with some users - none of them want ffmpeg to terminate due to
> invalid SCTE-35 data.
>
> Keep in mind
>
> LGTM
completely forgot about this
applied
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Addressed the following concerns.
===
>libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
>libavfilter/vf_drawtext.c:422:5: warning: ISO C90 forbids mixed declarations
>and code [->Wdeclaration-after-statement]
Fixed this.
>also patch breaks:
>./ffmpeg -i m.mpg -vf
>>drawtext=fontfile
On Fri, Sep 02, 2016 at 01:00:59PM -0700, Sasi Inguva wrote:
> On Aug 31, 2016 5:23 AM, "Michael Niedermayer"
> wrote:
> >
> > On Tue, Aug 30, 2016 at 06:37:22PM -0700, Sasi Inguva wrote:
> > > On Sun, Aug 28, 2016 at 3:10 AM, Michael Niedermayer
> > > > wrote:
[...]
> >
> >
> > > The timestamps
On 09/02/2016 01:56 PM, Michael Niedermayer wrote:
On Fri, Sep 02, 2016 at 01:13:33PM -0700, Jonathan Campbell wrote:
On 09/02/2016 01:01 PM, Michael Niedermayer wrote:
On Fri, Sep 02, 2016 at 10:19:23AM -0700, Jonathan Campbell wrote:
[...]
CRC computation isn't fast enough? What should I us
On Fri, Sep 02, 2016 at 01:00:59PM -0700, Sasi Inguva wrote:
> On Aug 31, 2016 5:23 AM, "Michael Niedermayer"
> wrote:
> >
> > On Tue, Aug 30, 2016 at 06:37:22PM -0700, Sasi Inguva wrote:
> > > On Sun, Aug 28, 2016 at 3:10 AM, Michael Niedermayer
> > > > wrote:
> > >
> > > > On Sat, Aug 27, 2016
Compiling ffmpeg 3.1.3 with OpenSSL 1.1.0 returns this:
CC libavformat/rtpdec_ac3.o
src/libavformat/rtmpdh.c: In function ‘ff_dh_init’:
src/libavformat/rtmpdh.c:277:14: error: dereferencing pointer to incomplete
type ‘FF_DH {aka struct dh_st}’
bn_new(dh->g);
^
src/
On Fri, Sep 02, 2016 at 04:05:44PM -0700, Jonathan Campbell wrote:
>
> On 09/02/2016 01:56 PM, Michael Niedermayer wrote:
> >On Fri, Sep 02, 2016 at 01:13:33PM -0700, Jonathan Campbell wrote:
> >>On 09/02/2016 01:01 PM, Michael Niedermayer wrote:
> >>>On Fri, Sep 02, 2016 at 10:19:23AM -0700, Jona
On 09/02/2016 04:37 PM, Michael Niedermayer wrote:
On Fri, Sep 02, 2016 at 04:05:44PM -0700, Jonathan Campbell wrote:
On 09/02/2016 01:56 PM, Michael Niedermayer wrote:
On Fri, Sep 02, 2016 at 01:13:33PM -0700, Jonathan Campbell wrote:
On 09/02/2016 01:01 PM, Michael Niedermayer wrote:
On Fr
This patch is a fix for the bug with ticket number 5812
(https://trac.ffmpeg.org/ticket/5812).
Basically, the bug is that the last segment and the "#EXT-X-ENDLIST"
tag are not being written to the subtitle playlist file when
converting a file with subtitles to the HLS format. The reason for
this s
On Fri, Sep 02, 2016 at 03:31:21PM -0700, Brett Harrison wrote:
> Addressed the following concerns.
>
> ===
>
> >libavfilter/vf_drawtext.c: In function ‘update_fontsize’:
> >libavfilter/vf_drawtext.c:422:5: warning: ISO C90 forbids mixed declarations
> >and code [->Wdeclaration-after-statement]
On Fri, Sep 02, 2016 at 04:49:54PM -0700, Jonathan Campbell wrote:
>
> On 09/02/2016 04:37 PM, Michael Niedermayer wrote:
> >On Fri, Sep 02, 2016 at 04:05:44PM -0700, Jonathan Campbell wrote:
> >>On 09/02/2016 01:56 PM, Michael Niedermayer wrote:
> >>>On Fri, Sep 02, 2016 at 01:13:33PM -0700, Jona
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 respective man pages
(otherwise they woul be lacking commit messages)
thx
[...]
___
ffmp
On 9/2/2016 8:49 PM, Jonathan Campbell wrote:
> diff --git a/libavcodec/ac3dec.c b/libavcodec/ac3dec.c
> index fac189b..18a674b 100644
> --- a/libavcodec/ac3dec.c
> +++ b/libavcodec/ac3dec.c
> @@ -1419,6 +1419,13 @@ static int ac3_decode_frame(AVCodecContext * avctx,
> void *data,
>
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 respective man pages
> >(otherwise they woul be lacking
On 9/2/2016 9:31 PM, 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 respective man pages
>> (otherwise they woul be lacking commit messages)
>>
>>
57 matches
Mail list logo
