On Fri, Mar 08, 2019 at 06:48:15PM +0100, Lynne wrote:
>
>
>
> 7 Mar 2019, 21:18 by mich...@niedermayer.cc:
>
> > On Wed, Mar 06, 2019 at 07:09:52PM +0100, Lynne wrote:
> >
> >> A lot of files have CRC included.
> >> The CRC only covers 34 bytes at most from the frame but it should still be
> >
Hi Mark,
Am Mi., 13. März 2019 um 02:00 Uhr schrieb Mark Thompson :
[..]
> >>> Date: Sat, 26 Jan 2019 19:48:35 +0100
> >>> Subject: [PATCH] avcodec/vaapi_h264: skip decode if pic has no slices
> >>
> >> Something along the lines of "avcodec/vaapi_h264: skip decoding if no
> >> slices were provided"
ons 2019-03-13 klockan 17:46 + skrev Matthew Fearnley:
> > > > On 12 Mar 2019, at 11:46, Tomas Härdin wrote:
> >
> > tis 2019-03-12 klockan 10:27 + skrev Matthew Fearnley:
> > > >
> > > It occurs to me that adding sub-8bpp has some implications:
> > >
> > > My current understanding (I c
Hi there,
we are developing a transcoder using ffmpeg based on the transcoding example
https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are
encountering some problem with memory usage transcoding files with large
resolutions.
When transcoding 4K files, the memory usage will
2019-03-14 11:28 GMT+01:00, Simone Donadini :
> Hi there,
> we are developing a transcoder using ffmpeg based on the transcoding example
> https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are
> encountering some problem with memory usage transcoding files with large
> resolutio
> From: Rogozhkin, Dmitry V
> Sent: Tuesday, March 12, 2019 7:37 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
>
> On Mon, 2019-03-11 at 17:23 +0800, Li, Zhong wrote:
> > > -Ori
> From: Rogozhkin, Dmitry V
> Sent: Tuesday, March 12, 2019 8:04 AM
> To: Li, Zhong ; ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v3 3/6] lavc/qsvdec: Replace current
> parser with MFXVideoDECODE_DecodeHeader()
>
> pix_fmts[1] is misleading. And I think it can be quite easily avoi
tor 2019-03-14 klockan 11:12 +0100 skrev Tomas Härdin:
> ons 2019-03-13 klockan 17:46 + skrev Matthew Fearnley:
> > > > >
> > By the way, I’m happy for this patch to be committed as-is (possibly
> > without the extra note on unsupported bit depths, if that causes any
> > issues). Any new addit
> 2019-03-14 11:28 GMT+01:00, Simone Donadini :
> > Hi there,
> > we are developing a transcoder using ffmpeg based on the transcoding example
> > https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html and we are
> > encountering some problem with memory usage transcoding files with large
>
On Tue, Mar 05, 2019 at 08:38:17PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout (17 sec -> 65 milli sec)
> Fixes:
> 13264/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_CDGRAPHICS_fuzzer-5711167941509120
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/
On Tue, Mar 05, 2019 at 01:05:46AM +0100, Michael Niedermayer wrote:
> Fixes: Division by 0
> Fixes: ffmpeg_zero_division.bin
>
> Found-by: Anatoly Trosinenko
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/gdv.c | 3 +++
> 1 file changed, 3 insertions(+)
will apply
[...]
--
Michael
Hi
Here is the patch for a new H.264 codec with Matrox m264 card.
Please review.
Thanks.
Yufei.
From b1f7779028378f3e0d5360766a8591d0cf5a0a71 Mon Sep 17 00:00:00 2001
From: yhe
Date: Thu, 14 Mar 2019 10:10:46 -0400
Subject: [PATCH] H.264 encoder and decoder support with Matrox M264.
---
Ch
Calculate bitrate based on fragment size, only applied when
bitrate is not set, for example rtsp source.
Signed-off-by: Jun Li
---
libavformat/smoothstreamingenc.c | 32 +++-
1 file changed, 27 insertions(+), 5 deletions(-)
diff --git a/libavformat/smoothstreamingenc
On Wed, Mar 13, 2019 at 6:07 PM Jun Li wrote:
> On Tue, Mar 12, 2019 at 6:24 PM Jun Li wrote:
>
>> Hi Carl,
>> Thanks for review, is there any more issue I need to take care ?
>> or any process I need to follow before applying the patch? I am new to
>> the community, don't know too much.
>>
>> T
On 3/4/2019 9:06 AM, Martin Vignali wrote:
> Pushed. Thanks
>
> Martin
This seems to have broken all qtrle tests on sparc64.
See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
others.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg
>
> This seems to have broken all qtrle tests on sparc64.
>
> See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
> others.
>
Thanks for reporting this.
Like i can't test on sparc64, doesn't know what line create the bus error.
Patch in attach (untested on sparc64), can probably
Hello, is there anything preventing from merging this patch?
On 2/14/19 10:01 PM, Michael Niedermayer wrote:
> On Wed, Feb 13, 2019 at 11:49:21PM +0100, Mathieu Duponchelle wrote:
>> So, should this go in? :)
> if someone checks it against some spec and or tests it against some
> decoders, probabl
On 3/14/2019 5:27 PM, Martin Vignali wrote:
>>
>> This seems to have broken all qtrle tests on sparc64.
>>
>> See http://fate.ffmpeg.org/history.cgi?slot=sparc64-linux-gcc-4.9 and
>> others.
>>
>
> Thanks for reporting this.
> Like i can't test on sparc64, doesn't know what line create the bus err
Hi!
Attached patch fixes the qtrle crash on sparc for me.
Please comment, Carl Eugen
From a94d32d63cff248d2eb633b162e9e4d4f7234ee5 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 15 Mar 2019 00:02:48 +0100
Subject: [PATCH] lavc/qtrle: Do not used aligned writes for odd addresses.
pix
On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos wrote:
>
> Hi!
>
> Attached patch fixes the qtrle crash on sparc for me.
>
It should be fine in cases where the pointer is being incremented by
an aligned amount, ie. writing 32 and incrementing by 4, or 64 and 8,
etc.
Are all of those required to
2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
> On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos
> wrote:
>>
>> Hi!
>>
>> Attached patch fixes the qtrle crash on sparc for me.
>>
>
> It should be fine in cases where the pointer is being incremented by
> an aligned amount, ie. writing 32 and increm
Hi!
Attached patch fixes fate here without zlib.
Please comment, Carl Eugen
From 209fff61a2a680a5adf5df82774f7dd48fc4701c Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 15 Mar 2019 00:27:33 +0100
Subject: [PATCH] tests/fate/ffmpeg: Check for apng codec for fate-copy-apng.
The file h
2019-03-14 12:51 GMT+01:00, Simone Donadini :
>> 2019-03-14 11:28 GMT+01:00, Simone Donadini
>> :
>> > we are developing a transcoder using ffmpeg based on the
>> > transcoding example
>> > https://www.ffmpeg.org/doxygen/4.1/transcoding_8c-example.html
>> > and we are encountering some problem wit
On 3/14/2019 8:29 PM, Carl Eugen Hoyos wrote:
> Hi!
>
> Attached patch fixes fate here without zlib.
>
> Please comment, Carl Eugen
>
>
> 0001-tests-fate-ffmpeg-Check-for-apng-codec-for-fate-copy.patch
>
> From 209fff61a2a680a5adf5df82774f7dd48fc4701c Mon Sep 17 00:00:00 2001
> From: Carl Euge
On Fri, Mar 15, 2019 at 12:26 AM Carl Eugen Hoyos wrote:
>
> 2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
> > On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos
> > wrote:
> >>
> >> Hi!
> >>
> >> Attached patch fixes the qtrle crash on sparc for me.
> >>
> >
> > It should be fine in cases where th
Hi!
Attached patch silences three warnings with clang and makes the
pointer type equal to what the function called with the pointer
expects.
Please comment, Carl Eugen
From cf06b8cc09acd676ac6fb713168c23342d26e1b8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 15 Mar 2019 00:52:50 +0
Am 11.03.19 um 23:29 schrieb Lou Logan:
> Commit message title prefix for filter patches are usually in the form
> of:
>
> avfilter/fillborders:
> or
> lavfi/fillborders:
>
> Trailing whitespace. This should always be avoided.
>
> Use av_malloc.
I now have separted the changes into 4 patches, an
2019-03-15 1:08 GMT+01:00, Ulf Zibis :
> Can you give a rating if a performance win could be expected compaired
> to the original code from your experienced knowledge without a benchmark?
Just post the numbers that your tests produced.
Carl Eugen
___
f
2019-03-15 0:41 GMT+01:00, Hendrik Leppkes :
> On Fri, Mar 15, 2019 at 12:26 AM Carl Eugen Hoyos
> wrote:
>>
>> 2019-03-15 0:13 GMT+01:00, Hendrik Leppkes :
>> > On Fri, Mar 15, 2019 at 12:05 AM Carl Eugen Hoyos
>> > wrote:
>> >>
>> >> Hi!
>> >>
>> >> Attached patch fixes the qtrle crash on sparc
Optimization found while looking at
13442/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SCPR_fuzzer-5758293933293568
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/scpr.c | 8
l
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fate.list | 64 ++
1 file changed, 64 insertions(+)
diff --git a/tools/target_dec_fate.list b/tools/target_dec_fate.list
index 5ad1e940c6..13b0721a5e 100644
--- a/tools/target_dec_fate.list
+++ b/tools/ta
2019-03-15 0:38 GMT+01:00, James Almer :
> On 3/14/2019 8:29 PM, Carl Eugen Hoyos wrote:
>> Hi!
>>
>> Attached patch fixes fate here without zlib.
>>
>> Please comment, Carl Eugen
>>
>>
>> 0001-tests-fate-ffmpeg-Check-for-apng-codec-for-fate-copy.patch
>>
>> From 209fff61a2a680a5adf5df82774f7dd48fc
When I decode rawvideo yuv444p in ffplay that was encoded in ffmpeg (using
the test source called "testsrc"), I notice there is blurring between
adjacent colors (both horizontally and vertically), which would typically
be present in yuv420p. I can avoid this by switching the decoder to use a
pixel
33 matches
Mail list logo
