> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Reimar Döffinger
> Sent: Friday, June 07, 2019 11:07 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v4] vaapi_encode_mjpeg: fix bad component
> id b
On 08.06.2019, at 03:08, Peter Ross wrote:
> ---
> comments against v4 patch addressed. thanks.
>
> +#if CONFIG_VP4_DECODER
> +static int vp4_get_mb_count(Vp3DecodeContext *s, GetBitContext *gb)
> +{
> +int v = 1;
> +int bits;
> +while ((bits = show_bits(gb, 9)) == 0x1ff && v <
>
On 07.06.2019, at 23:56, Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavformat/vividas.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/vividas.c b/libavformat/vividas.c
> index 5e303b9c52..72f2093d13 100644
> ---
On Fri, 7 Jun 2019 08:38:35 -0700
Adrian Tong wrote:
> Hi
>
> I have a workload which spends a significant amount of time (~10%) in
> the yuv420_bgr24_mmxext function in FFMEPG.
>
> I looked at the assembly and profile and see MMX (64 bit) registers are
> used. I wonder whether we can have a SSE2
On 07.06.2019, at 23:45, "U. Artie Eoff" wrote:
> The compound literals assigned to "components"
> only exist within the scope of the if/else
> block (thanks Mark Thompson for the better
> explanation).
>
> Thus, after this if/else block, "components"
> ends up pointing to an arbitrary/undefined
---
comments against v4 patch addressed. thanks.
Changelog |1 +
configure |1 +
doc/general.texi|2 +
libavcodec/allcodecs.c |1 +
libavcodec/avcodec.h|1 +
libavcodec/codec_desc.c |7 +
libavcodec/vp3.c| 728 +
these routines are shared by vp3 and vp4.
---
libavcodec/vp3.c | 39 ++-
1 file changed, 26 insertions(+), 13 deletions(-)
diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
index 63f60c9109..65aa0f353c 100644
--- a/libavcodec/vp3.c
+++ b/libavcodec/vp3.c
@@ -931
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_find_rect.c | 40 +++-
1 file changed, 27 insertions(+), 13 deletions(-)
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index d7e6579..6fe12fe 100644
--- a/libavfilter/vf_fin
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_cover_rect.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
index 41cd1a1..ac0f684 100644
--- a/libavfilter/vf_cover_rect.c
+++ b/libavfilter/vf_cover_rec
On Fri, Jun 7, 2019 at 11:52 PM Thilo Borgmann
wrote:
> Am 07.06.19 um 17:21 schrieb Lance Wang:
> > On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz wrote:
> >
> >> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
> >>
> >>> From: Limin Wang
> >>>
> >>> Signed-off-by: Limin Wang
> >>
> >> T
Fixes: left shift of 1 by 31 places cannot be represented in type 'int'
Fixes:
15118/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5740230004441088
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
Signed-off-by: Michael Niedermayer
---
libavformat/vividas.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index 5e303b9c52..72f2093d13 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -78,11 +78,11
Fixes: signed integer overflow: 4442 * 100 cannot be represented in type
'int'
Fixes:
15117/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5164660531134464
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Nieder
The compound literals assigned to "components"
only exist within the scope of the if/else
block (thanks Mark Thompson for the better
explanation).
Thus, after this if/else block, "components"
ends up pointing to an arbitrary/undefined
array. With some compilers and depending on
optimization setti
On Fri, Jun 7, 2019 at 11:54 AM Michael Niedermayer
wrote:
> On Thu, Jun 06, 2019 at 08:28:15PM -0700, Jun Li wrote:
> > Fix #6945
> > Rotate or/and flip frame according to frame's metadata orientation
> > ---
> > fftools/ffmpeg.c| 5 +++--
> > fftools/ffmpeg.h| 8
> >
> -Original Message-
> From: Eoff, Ullysses A
> Sent: Friday, June 07, 2019 2:42 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Eoff, Ullysses A
> Subject: [PATCH v3] vaapi_encode_mjpeg: fix bad component id bug
>
> The compound literals assigned to "components"
> only exist within the scope of t
The compound literals assigned to "components"
only exist within the scope of the if/else
block (thanks Mike Thompson for the better
explanation).
Thus, after this if/else block, "components"
ends up pointing to an arbitrary/undefined
array. With some compilers and depending on
optimization setti
> -Original Message-
> From: Eoff, Ullysses A
> Sent: Friday, June 07, 2019 2:11 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Eoff, Ullysses A
> Subject: [PATCH v2] vaapi_encode_mjpeg: fix bad component id bug
>
> When compile time optimizations are enabled and
> compiling with GNU GCC 9.x, the
Mark Thompson:
> On 07/06/2019 02:17, Andreas Rheinhardt wrote:
>> difference_of_pic_nums_minus1
>>
>> They are unsigned values.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Sorry for sending the first email prematurely.
>> libavcodec/cbs_h264.h | 4 ++--
>> 1 file changed, 2 insertions(+),
When compile time optimizations are enabled and
compiling with GNU GCC 9.x, the pointer assignment
to the inline brace-enclosed list initialized
array does not work and "component" ends up pointing
to an empty/undefined array. Thus, all of the
frame header component id's get assigned the
same valu
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark
> Thompson
> Sent: Friday, June 07, 2019 1:47 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] vaapi_encode_mjpeg: WA: fix bad component
> id bug
>
> On 07/06/2019 2
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> Reimar Döffinger
> Sent: Friday, June 07, 2019 1:41 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH] vaapi_encode_mjpeg: WA: fix bad component
> id b
On 07/06/2019 21:28, U. Artie Eoff wrote:
> When compile time optimizations are enabled and
> compiling with GNU GCC 9.x, the pointer assignment
> to the inline brace-enclosed list initialized
> array does not work and "component" ends up pointing
> to an empty array. This is probably a bug in GCC
On 07/06/2019 02:17, Andreas Rheinhardt wrote:
> difference_of_pic_nums_minus1
>
> They are unsigned values.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Sorry for sending the first email prematurely.
> libavcodec/cbs_h264.h | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff
On 07.06.2019, at 22:28, "U. Artie Eoff" wrote:
> When compile time optimizations are enabled and
> compiling with GNU GCC 9.x, the pointer assignment
> to the inline brace-enclosed list initialized
> array does not work and "component" ends up pointing
> to an empty array. This is probably a bu
>> -!ost->copy_initial_nonkeyframes)
>> +!ost->copy_initial_nonkeyframes) {
>> +av_log(NULL, AV_LOG_DEBUG, "skipping initial
>> non-keyframe\n"); return;
>
> Incorrect indentation.
It's actually the same indentation as in other places in the same file,
what would be the
On 07/06/2019 01:27, Andreas Rheinhardt wrote:
> READ has already been undefined at this point; it is obviously intended
> to undef WRITE.
> Furthermore, leb128 (in cbs_av1) was undefined too often and
> inconsistently.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavcodec/cbs_av1.c | 5 ++-
When compile time optimizations are enabled and
compiling with GNU GCC 9.x, the pointer assignment
to the inline brace-enclosed list initialized
array does not work and "component" ends up pointing
to an empty array. This is probably a bug in GCC
9.x.
This patch works around this issue by assigni
> please send a patch to docs/nut4cc.txt first.
> (https://git.ffmpeg.org/nut.git or svn://svn.mplayerhq.hu/nut)
sent the patch (mail is awaiting moderation)
pgpHCCCp43tLk.pgp
Description: OpenPGP digital signature
___
ffmpeg-devel mailing list
ffmpeg-
>> I have the file ready, how can I provide it?
>
> how big is it ?
1.2M, I did 10 frames to get some non-keyframes too.
> can it be used for a fate test ?
sure
> but generally upload it somewhere and provide a link
the nut file is now available from ipfs:
https://ipfs.io/ipfs/QmUcW1DRJokt
On Fri, May 17, 2019 at 12:29:47AM +0200, Andreas Rheinhardt wrote:
> Matroska EBML IDs can be only four bytes long maximally, so it is
> natural to use uint32_t for them. By doing this and rearranging the
> elements of the MatroskaLevel1Element structure, one can reduce the size
> of said structur
On Fri, May 17, 2019 at 12:29:45AM +0200, Andreas Rheinhardt wrote:
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 8 ++--
> 1 file changed, 2 insertions(+), 6 deletions(-)
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B
On Fri, May 17, 2019 at 12:29:46AM +0200, Andreas Rheinhardt wrote:
> This error message is outdated since d31fb1a9.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/matroskadec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
will apply
thx
[...]
--
Michael GnuPG finge
On Thu, Jun 06, 2019 at 08:28:15PM -0700, Jun Li wrote:
> Fix #6945
> Rotate or/and flip frame according to frame's metadata orientation
> ---
> fftools/ffmpeg.c| 5 +++--
> fftools/ffmpeg.h| 8
> fftools/ffmpeg_filter.c | 36 +++-
> 3 fil
On Wed, May 22, 2019 at 06:10:36PM +0200, Olivier Maignial wrote:
> === PROBLEM ===
>
> I was trying to record h264 + aac streams from an RTSP server to mp4 file.
> using this command line:
> ffmpeg -v verbose -y -i "rtsp:///my_resources" -codec copy -bsf:a
> aac_adtstoasc test.mp4
>
> FFmp
On Thu, Jun 06, 2019 at 10:33:57PM +0200, Stephan Hilb wrote:
> Michael Niedermayer wrote on 27.05.2019 at 00:22:
>
> > [...] maybe just add teh codec id to nut and try to store it in that
> > with stream copy if it works it should be possible to playback that
> > nit file
>
> I have the file rea
Andreas Rheinhardt:
> Hello,
>
> here is the patchset for the Matroska demuxer that I already announced
> last week [1]. It is an improvement upon an earlier patchset from March [2]
> which has been kindly reviewed by Steve Lhomme. Just as the earlier
> attempt, it is intended to get rid of a bog
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> The earlier version of the webm_chunk muxer had several bugs:
>>
>> 1. If the first packet of an audio stream didn't have a PTS of zero,
>> then no chunk will be started before a packet is delivered to the
>> underlying Matroska/WebM muxer, i.e. the AVFo
On Thu, Jun 06, 2019 at 22:31:45 +0200, Stephan Hilb wrote:
> If `AV_PKT_FLAG_KEY` stays unset on `pkt->flags`, the output stream
> stays empty with little information about what is going on.
> This change makes it easier to debug the situation for the user who
> could then choose to use the `-copy
On Fri, Jun 07, 2019 at 11:30:05PM +0800, Lance Wang wrote:
> On Fri, Jun 7, 2019 at 11:13 PM Michael Niedermayer
> wrote:
>
> > On Thu, Jun 06, 2019 at 04:30:56PM +0800, lance.lmw...@gmail.com wrote:
> > > From: Limin Wang
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavfilter/vf_c
Am 07.06.19 um 17:21 schrieb Lance Wang:
> On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz wrote:
>
>> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
>>
>>> From: Limin Wang
>>>
>>> Signed-off-by: Limin Wang
>>
>> This looks like a different approach to a similar patch sent before
>> by Th
On Thu, Jun 06, 2019 at 10:31:44PM +0200, Stephan Hilb wrote:
> ---
> libavformat/nut.c | 1 +
> 1 file changed, 1 insertion(+)
please send a patch to docs/nut4cc.txt first.
(https://git.ffmpeg.org/nut.git or svn://svn.mplayerhq.hu/nut)
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF
Hi
I have a workload which spends a significant amount of time (~10%) in
the yuv420_bgr24_mmxext function in FFMEPG.
I looked at the assembly and profile and see MMX (64 bit) registers are
used. I wonder whether we can have a SSE2 version which has a register bit
width of 128.
I am very interest
On Fri, Jun 7, 2019 at 11:13 PM Michael Niedermayer
wrote:
> On Thu, Jun 06, 2019 at 04:30:56PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_cover_rect.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
>
On Fri, Jun 7, 2019 at 8:36 PM Marvin Scholz wrote:
> On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
>
> This looks like a different approach to a similar patch sent before
> by Thilo.
>
> ---
> > libavcodec/videotoolboxenc.c | 4
On Thu, Jun 06, 2019 at 10:31:45PM +0200, Stephan Hilb wrote:
> If `AV_PKT_FLAG_KEY` stays unset on `pkt->flags`, the output stream
> stays empty with little information about what is going on.
> This change makes it easier to debug the situation for the user who
> could then choose to use the `-co
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/videotoolboxenc.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 3665581..f8ccdea 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@
On Thu, Jun 06, 2019 at 04:30:56PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_cover_rect.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_cover_rect.c b/libavfilter/vf_cover_rect.c
> i
This should improve coverage
Signed-off-by: Michael Niedermayer
---
tools/target_dec_fuzzer.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 4f51b70b65..f456db0e7b 100644
--- a/tools/target_dec_fuzz
On 7 Jun 2019, at 11:59, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
This looks like a different approach to a similar patch sent before
by Thilo.
---
libavcodec/videotoolboxenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/videotoolbox
On Sun, Jun 02, 2019 at 17:47:24 +0100, Mark Thompson wrote:
> >> Set the cropping fields in the AVFrame.
> > The patchset looks fine to me. But I am not quite sure if others are happy
> > with this crop patch.
> > If nobody against. I think you can go pushing the patchset when you make
> > sure
On Fri, Jun 7, 2019 at 6:56 AM Michael Niedermayer
wrote:
> On Thu, Jun 06, 2019 at 01:54:41PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavfilter/vf_find_rect.c | 37 ++---
> > 1 file changed, 26 i
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_find_rect.c | 40 +---
1 file changed, 29 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_find_rect.c b/libavfilter/vf_find_rect.c
index d7e6579..8c6e928 100644
--- a/libavfilter/vf_fin
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/videotoolboxenc.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index 3665581..e4f44e5 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@
Hello,
Just a reminder about this patch
If you need something else to validate it, please let me know
Olivier
On Wed, May 22, 2019 at 6:10 PM Olivier Maignial
wrote:
> === PROBLEM ===
>
> I was trying to record h264 + aac streams from an RTSP server to mp4 file.
> using this command line:
>
55 matches
Mail list logo
