Generate random legato tones using fluidsynth api.
diff --git a/Changelog b/Changelog
index d1572553a5..5ddd2484b0 100644
--- a/Changelog
+++ b/Changelog
@@ -48,6 +48,7 @@ version :
- AMQP 0-9-1 protocol (RabbitMQ)
- Vulkan support
- avgblur_vulkan, overlay_vulkan, scale_vulkan and chromaber_vu
This is a constant codec property, so a capability flag is more appropriate.
---
Updated for wavpack changes
---
doc/multithreading.txt | 5 +++--
libavcodec/ffv1dec.c | 4 +---
libavcodec/h264dec.c | 5 ++---
libavcodec/hevcdec.c | 5 ++---
libavcodec/internal.h | 2
The current design, where
- proper init is called for the first per-thread context
- first thread's private data is copied into private data for all the
other threads
- a "fixup" function is called for all the other threads to e.g.
allocate dynamically allocated data
is very fragile and hard to
ping
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
This is extremely fragile against reordering and hides what is actually
being copied. Copy all the fields manually instead.
---
Like this?
---
libavcodec/mpeg4videodec.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg4videodec.c b/li
Am 12.03.20 um 11:26 schrieb Thilo Borgmann:
> Hi,
>
>> fixes infinite loop waiting for input using e.g. tape devices that suport
>> transport control.
>
> will apply soon.
Applied.
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https:/
Quoting Daniel Playfair Cal (2020-03-16 02:20:46)
> This matches the inclusion of the other hwcontext_.h headers.
> The skipping of the header depending on build flags is already present.
>
> Signed-off-by: Daniel Playfair Cal:
> ---
Looks ok, though I wonder how no one noticed until now.
--
A
Michael Niedermayer (12020-03-15):
> Fixes: signed integer overflow: 1302123111085380114 - -8319005078741256972
> cannot be represented in type 'long'
> Fixes:
> 20991/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_FFWAVESYNTH_fuzzer-5148554161291264
>
> Found-by: continuous fuzzing process
Quoting Michael Niedermayer (2020-03-15 22:20:55)
> Fixes: signed integer overflow: 2 * 1210064928 cannot be represented in type
> 'int'
> Fixes:
> 20873/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5761116909338624
>
> Found-by: continuous fuzzing process
> https://github.com/google/os
Jan Ekström (12020-03-12):
> Each time the sub2video structure is initialized, the sub2video
> subpicture is initialized together with the first received heartbeat.
> The heartbeat's PTS is utilized as the subpicture start time.
>
> Additionally, add some documentation on the stages.
> ---
> ffto
Quoting Anamitra Ghorui (2020-03-15 13:40:58)
> Hello,
>
> I am dealing dealing with a video (gif-like) file format in which there
> are compressed (entropy coded) segments of unknown length. However, the
> length
> of the uncompressed segment of the file is already known. Please check the
> p
Quoting Andreas Rheinhardt (2020-03-14 18:08:45)
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/avienc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/avienc.c b/libavformat/avienc.c
> index 07e1c3319e..297d5b8964 100644
> --- a/libavformat/avi
Anton Khirnov (12020-03-16):
> I'd think any decent compiler will already make that transformation.
Profile, don't speculate. gcc doesn't make that optimization for
printf().
And no compiler could do it for av_log() anyway.
Regards,
--
Nicolas George
signature.asc
Description: PGP signatur
>Subject: Re: [FFmpeg-devel] [PATCH] Encapsulation func to get width and height
>most of mb's checked oper are defined in mpegutils' marcos, so mb's
>checked oper about width/height should be put it together with others.
This is not the right way to write commit messages. See git-howto.
Hi Marshall,
On Sat, Mar 14, 2020 at 15:58:32 +0530, Marshall Murmu wrote:
> +{"soundfont", "location of soundfont",
> OFFSET(soundfont), AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN,
> CHAR_MAX, FLAGS},
I don't think we define ranges for AV_OPT_TYPE_STRING.
>
Quoting Nicolas George (2020-03-16 11:03:41)
> Anton Khirnov (12020-03-16):
> > I'd think any decent compiler will already make that transformation.
>
> Profile, don't speculate. gcc doesn't make that optimization for
> printf().
>
> And no compiler could do it for av_log() anyway.
Okay, seems i
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/adpcm.c | 33 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
5 files changed, 43 insertions(+)
diff --git a/libavcodec/Makefile
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/fwse.c | 88
3 files changed, 90 insertions(+)
create mode 100644 libavformat/fwse.c
diff --git a/libavformat/Makefile b/libavformat/Makef
Anton Khirnov (12020-03-16):
> Okay, seems it doesn't. I wonder why.
Probably something to do with locales. Or just the benefit/costs is not
interesting.
> But in any case, optimizing error messages for performance rather than
> readability seems rather backwards.
That's a reasonable stance by i
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/hca.c| 148 +++
3 files changed, 150 insertions(+)
create mode 100644 libavformat/hca.c
diff --git a/libavformat/Makefile b/libavformat/Mak
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +++
libavcodec/dpcm.c | 32
libavcodec/utils.c | 1 +
6 files changed, 43 insertions(+)
d
Signed-off-by: Paul B Mahol
---
libavcodec/allcodecs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 6046b15164..71e14c73e3 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -275,7 +275,6 @@ extern AVCod
Signed-off-by: Paul B Mahol
---
libavcodec/Makefile | 1 +
libavcodec/allcodecs.c | 1 +
libavcodec/avcodec.h| 1 +
libavcodec/codec_desc.c | 7 +
libavcodec/hca_data.h | 129 +++
libavcodec/hcadec.c | 349
6 files change
Signed-off-by: Paul B Mahol
---
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/derf.c | 79
3 files changed, 81 insertions(+)
create mode 100644 libavformat/derf.c
diff --git a/libavformat/Makefile b/libavformat/Makef
Quoting Andreas Rheinhardt (2020-03-13 20:14:16)
> Since commit e134c203 strdups of several elements of a manifest are kept
> in the DASHContext; but said commit completely forgot to free these
> strings again (with xmlFree()). Given that these strings are never used
> at all, this commit closes th
HLS input streams ignored CLI parameters which control the probing
process. Each stream was initialized with fresh context and used
the default values for probing.
---
libavformat/hls.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745
On Mon, Mar 16, 2020 at 10:45:21AM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-03-15 22:20:55)
> > Fixes: signed integer overflow: 2 * 1210064928 cannot be represented in
> > type 'int'
> > Fixes:
> > 20873/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5761116909338624
On Mon, Mar 16, 2020 at 3:40 PM Moritz Barsnick wrote:
> Hi Marshall,
>
> On Sat, Mar 14, 2020 at 15:58:32 +0530, Marshall Murmu wrote:
>
> > +{"soundfont", "location of soundfont",
> OFFSET(soundfont), AV_OPT_TYPE_STRING, {.str=NULL}, CHAR_MIN,
> CHAR_MAX, FLAGS},
>
> I don't thi
On Sun, Mar 15, 2020 at 06:02:04PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-03-13 23:29:12)
> > On Fri, Mar 13, 2020 at 11:28:50AM +0100, Anton Khirnov wrote:
> > > Makes sure it is only used for logging and nothing else.
> > > ---
> > > libavcodec/h264_ps.c | 18 +--
HLS input streams ignored CLI parameters which control the probing
process. Each stream was initialized with fresh context and used
the default values for probing.
---
libavformat/hls.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index 1f58e745
Quoting Michael Niedermayer (2020-03-16 12:11:28)
> On Mon, Mar 16, 2020 at 10:45:21AM +0100, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2020-03-15 22:20:55)
> > > Fixes: signed integer overflow: 2 * 1210064928 cannot be represented in
> > > type 'int'
> > > Fixes:
> > > 20873/clusterf
March 16, 2020 3:25 PM, "Anton Khirnov" wrote:
> Quoting Anamitra Ghorui (2020-03-15 13:40:58)
>
>> Hello,
>>
>> I am dealing dealing with a video (gif-like) file format in which there
>> are compressed (entropy coded) segments of unknown length. However, the
>> length
>> of the uncompressed s
> 2020年3月14日 上午3:14，Andreas Rheinhardt 写道：
>
> Since commit e134c203 strdups of several elements of a manifest are kept
> in the DASHContext; but said commit completely forgot to free these
> strings again (with xmlFree()). Given that these strings are never used
> at all, this commit closes th
Steven Liu (12020-03-16):
> No this is used for fix some problem about full specification support,
> you can fix the memleak but I don’t think remove them is a good way.
How can they fix a problem if they are unused?
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
__
> 2020年3月16日 下午9:19，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>> No this is used for fix some problem about full specification support,
>> you can fix the memleak but I don’t think remove them is a good way.
>
> How can they fix a problem if they are unused?
As Andreas said, just xmlFre
On Sat, Mar 7, 2020 at 10:32 AM David Michael wrote:
> Using a compiler with a different host triplet is considered
> cross-compiling, even when it is for the same architecture as the
> build system. With such a cross-compiler, it is still valid to
> optimize builds with --cpu=host. Drop the con
Steven Liu (12020-03-16):
> > How can they fix a problem if they are unused?
> As Andreas said, just xmlFree them at the end of the parse method is ok,
> I think i will use them for full support do that if you guys don’t know how
> to do that.
This commit e134c203 was clearly not fully baked. Le
> 2020年3月16日 下午9:26，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>>> How can they fix a problem if they are unused?
>> As Andreas said, just xmlFree them at the end of the parse method is ok,
>> I think i will use them for full support do that if you guys don’t know how
>> to do that.
>
Steven Liu (12020-03-16):
> Let me do it now, don’t remove the code, ok?
> Keep the code now or add xmlFree them.
There is a leak right now, and adding the xmlFree() is more work than
reverting.
Also, most of these attributes do not belong as string in the context,
they belong in local variable t
> 2020年3月16日 下午9:32，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>> Let me do it now, don’t remove the code, ok?
>> Keep the code now or add xmlFree them.
>
> There is a leak right now, and adding the xmlFree() is more work than
> reverting.
>
> Also, most of these attributes do not belon
Steven Liu (12020-03-16):
> I think you can rewrite a dashdec if you have interested in it, there
> have lots of bug in it, ok?
> I don’t think just remove some code for it is a good idea, if you want
> to do some thing for it, you can make it complete, not just remove
> some code.
This code is ba
> 2020年3月16日 下午9:42，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>> I think you can rewrite a dashdec if you have interested in it, there
>> have lots of bug in it, ok?
>> I don’t think just remove some code for it is a good idea, if you want
>> to do some thing for it, you can make it comp
Steven Liu (12020-03-16):
> Patch welcome for rewrite dashdec.
Irrelevant. This particular commit is bad in and by itself. That's what
happens when you push without review.
Regards,
--
Nicolas George
signature.asc
Description: PGP signature
___
ff
> 2020年3月16日 下午9:48，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>> Patch welcome for rewrite dashdec.
>
> Irrelevant. This particular commit is bad in and by itself. That's what
> happens when you push without review.
That is not without review, that is all of you have no interested in it
Steven Liu (12020-03-16):
> That is not without review, that is all of you have no interested in
> it, and I’m the maintainer of it.
> So I know what I want to do.
This commit was bad. Take your responsibilities. Maintaining a piece of
code is not a license to produce poor code.
Regards,
--
N
> 2020年3月16日 下午9:54，Nicolas George 写道：
>
> Steven Liu (12020-03-16):
>> That is not without review, that is all of you have no interested in
>> it, and I’m the maintainer of it.
>> So I know what I want to do.
>
> This commit was bad. Take your responsibilities. Maintaining a piece of
> code i
Quoting Anamitra Ghorui (2020-03-16 13:31:53)
> March 16, 2020 3:25 PM, "Anton Khirnov" wrote:
>
> > Quoting Anamitra Ghorui (2020-03-15 13:40:58)
> >
> >> Hello,
> >>
> >> I am dealing dealing with a video (gif-like) file format in which there
> >> are compressed (entropy coded) segments of un
Anton Khirnov (12020-03-16):
> Impressively overcomplicated.
I suppose it is meant to enhance the compression ratio, with the
assumption that images change less in the time direction than in the y
direction.
> So yeah, either the decoder takes in the entire bitstream and then spits
> out frames o
Quoting James Almer (2020-03-13 16:56:12)
> On 3/13/2020 7:28 AM, Anton Khirnov wrote:
> > Those SEIs refer to the currently active SPS. However, since the SEI
> > NALUs precede the coded picture data in the bitstream, the active SPS is
> > in general not known when we are decoding the SEI.
> >
>
Quoting Marshall Murmu (2020-03-16 12:19:55)
> On Mon, Mar 16, 2020 at 3:40 PM Moritz Barsnick wrote:
>
> > Hi Marshall,
> >
> > On Sat, Mar 14, 2020 at 15:58:32 +0530, Marshall Murmu wrote:
> >
> > > +{"soundfont", "location of soundfont",
> > OFFSET(soundfont), AV_OPT_TYPE_STRING, {.
On 3/16/2020 11:59 AM, Anton Khirnov wrote:
> Quoting James Almer (2020-03-13 16:56:12)
>> On 3/13/2020 7:28 AM, Anton Khirnov wrote:
>>> Those SEIs refer to the currently active SPS. However, since the SEI
>>> NALUs precede the coded picture data in the bitstream, the active SPS is
>>> in general
Sorry for the delay, got a bit busy here and forgot to reply.
Quoting James Almer (2020-03-11 14:27:54)
> On 3/11/2020 7:18 AM, Anton Khirnov wrote:
> > Quoting James Almer (2020-02-27 19:02:00)
> >> This commit follows the same logic as 061a0c14bb, but for the encode API:
> >> The
> >> new public
On Mon, Mar 16, 2020 at 11:52 AM Nicolas George wrote:
>
> Jan Ekström (12020-03-12):
> > Each time the sub2video structure is initialized, the sub2video
> > subpicture is initialized together with the first received heartbeat.
> > The heartbeat's PTS is utilized as the subpicture start time.
> >
modify: using the IS_* macros
most of mb's checked oper are defined in mpegutils' marcos, so mb's checked
oper about width/height should be put it together with others
Signed-off-by: numberwolf
---
libavcodec/mpegutils.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/li
These member will be used for get more correct information of the MPD
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 134 +-
1 file changed, 107 insertions(+), 27 deletions(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 5bbe5d3
Am Mo., 16. März 2020 um 17:21 Uhr schrieb numberwolf :
>
> modify: using the IS_* macros
> most of mb's checked oper are defined in mpegutils' marcos, so mb's checked
> oper about width/height should be put it together with others
>
> Signed-off-by: numberwolf
> ---
> libavcodec/mpegutils.h | 4
dont need show motionless vectors
because they're useless
Signed-off-by: numberwolf
---
doc/examples/extract_mvs.c | 8
1 file changed, 8 insertions(+)
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
index de31ccd..eaf7816 100644
--- a/doc/examples/extract_mvs.c
++
Here, dont need show motionless vectors,because they're useless.
(Sorry about I forget to remove the 'printf' on previous version.)
Signed-off-by: numberwolf
---
doc/examples/extract_mvs.c | 8
1 file changed, 8 insertions(+)
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extra
On Fri, Mar 13, 2020 at 11:28:45AM +0100, Anton Khirnov wrote:
> Those SEIs refer to the currently active SPS. However, since the SEI
> NALUs precede the coded picture data in the bitstream, the active SPS is
> in general not known when we are decoding the SEI.
>
> Therefore, store the content of
Hi,
Em qua., 4 de mar. de 2020 às 09:57, YATENDRA SINGH
escreveu:
>
> Thank you for explaining the procedure.
> I have posted my own project proposal on the page you had instructed me to.
> Looking forward to the feedback.
Have you contacted any possible mentor? If not, I would suggest you to
m
lör 2020-03-14 klockan 17:59 +0100 skrev Marton Balint:
>
> On Sat, 14 Mar 2020, Tomas Härdin wrote:
>
> > fre 2020-03-13 klockan 02:31 +0100 skrev Marton Balint:
> > > The packet durations might not be set properly which can cause the MXF
> > > muxer
> > > to write more than one packet of a str
On 3/16/2020 3:51 PM, Michael Niedermayer wrote:
> On Fri, Mar 13, 2020 at 11:28:45AM +0100, Anton Khirnov wrote:
>> Those SEIs refer to the currently active SPS. However, since the SEI
>> NALUs precede the coded picture data in the bitstream, the active SPS is
>> in general not known when we are d
Quoting James Almer (2020-03-16 20:42:31)
> On 3/16/2020 3:51 PM, Michael Niedermayer wrote:
> > On Fri, Mar 13, 2020 at 11:28:45AM +0100, Anton Khirnov wrote:
> >> Those SEIs refer to the currently active SPS. However, since the SEI
> >> NALUs precede the coded picture data in the bitstream, the a
On Wed, Jan 29, 2020 at 06:00:16PM +0100, Anton Khirnov wrote:
> Decoders are supposed to export stream properties in AVCodecContext, the
> AVFrame properties are set from those in ff_get_buffer().
> ---
> libavcodec/sbcdec.c | 7 ---
> 1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff
On Fri, Mar 13, 2020 at 11:28:48AM +0100, Anton Khirnov wrote:
> This SPS is not necessarily the one that will be used. Export the chroma
> location along with all the other SPS properties.
> ---
> libavcodec/h264_ps.c| 5 +++--
> libavcodec/h264_ps.h| 2 ++
> libavcodec/h264_slice.c | 1 +
This commit follows the same logic as 061a0c14bb, but for the encode API: The
new public encoding API will no longer be a wrapper around the old deprecated
one, and the internal API used by the encoders now consists of a single
receive_packet() callback that pulls frames as required.
Signed-off-by
This set follows the same logic as 061a0c14bb, but for the encode API: The
new public API will no longer be a wrapper around the old deprecated one, and
the internal API used by the encoders now consists of a single receive_packet()
callback that pulls frames as required.
Because of the above, PAT
Following the same logic as 061a0c14bb, this commit turns the old encode API
into a wrapper for the new one.
Signed-off-by: James Almer
---
This could be squashed with the previous commit, like it was done in 061a0c14bb,
but i figured it would be easier to review this way.
libavcodec/encode.c
Signed-off-by: James Almer
---
libavcodec/librav1e.c | 51 ---
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/libavcodec/librav1e.c b/libavcodec/librav1e.c
index b8b1b4f8f1..ba8c2a56f9 100644
--- a/libavcodec/librav1e.c
+++ b/libavcodec/lib
On Sun, Mar 15, 2020, at 10:22 AM, Paul B Mahol wrote:
>
> +++ b/libavformat/Makefile
> +OBJS-$(CONFIG_FWSE_DEMUXER) += fwse.o
Missing pcm.o. Same with derf demuxer in patch 4/7.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://
On Mon, Mar 16, 2020, at 2:30 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavformat/Makefile | 1 +
> libavformat/allformats.c | 1 +
> libavformat/hca.c| 148 +++
> 3 files changed, 150 insertions(+)
> create mode 100644 li
On Mon, Mar 16, 2020, at 2:30 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavcodec/allcodecs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 6046b15164..71e14c73e3 100644
> --- a/libavcodec/all
On Mon, 16. Mar 10:00, Ming Qian wrote:
> v4l2 set the frame rate through frame intervals,
> not set frame rate directly.
> the frame rate and frame intervals are reciprocal.
> so in libavdevice/v4l2.c we can see the following code:
> tpf->numerator = framerate_q.den;
> tpf->denominat
On Sat, Mar 14, 2020, at 3:25 AM, Steven Liu wrote:
> Suggested-by: Carl Eugen Hoyos Reviewed-by: Lou
> Logan Signed-off-by: Steven Liu
> ---
> generate-doc.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/generate-doc.sh b/generate-doc.sh index d8d01d3..45a9901
> 100755
On 3/16/2020 6:30 PM, James Almer wrote:
> +static int encode_send_packet_internal(AVCodecContext *avctx, const AVFrame
> *src)
> +{
> +AVCodecInternal *avci = avctx->internal;
> +AVFrame *dst = avci->buffer_frame;
> +int ret;
> +
> +if (avctx->codec->type == AVMEDIA_TYPE_AUDIO) {
On Mon, Mar 16, 2020 at 12:32:09PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-03-16 12:11:28)
> > On Mon, Mar 16, 2020 at 10:45:21AM +0100, Anton Khirnov wrote:
> > > Quoting Michael Niedermayer (2020-03-15 22:20:55)
> > > > Fixes: signed integer overflow: 2 * 1210064928 cannot
Fixes: signed integer overflow: 2 * 1210064928 cannot be represented in type
'int'
Fixes:
20873/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5761116909338624
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Nieder
On Mon, Mar 16, 2020 at 04:42:31PM -0300, James Almer wrote:
> On 3/16/2020 3:51 PM, Michael Niedermayer wrote:
> > On Fri, Mar 13, 2020 at 11:28:45AM +0100, Anton Khirnov wrote:
> >> Those SEIs refer to the currently active SPS. However, since the SEI
> >> NALUs precede the coded picture data in t
Hello,
I have a vulnerability about FFmpage to report.
Regarding the sws_scale function in the swscale.c file, when the parameter
SwsContext is 0, the program access address is abnormal, causing the
program to crash.
___
ffmpeg-devel mailing list
ffmpeg
On Mon, 16. Mar 10:02, Ming Qian wrote:
> the draining is set when the output port is finished,
> but it doesn't mean the capture port is finished.
> especially for decoder, there may be a stream buffer to store several
> frames.
> so the decoder still need capture buffer even if the draining is se
When digging the application, I found this vulnerability in the program,
because when the sws_scale function was called, the application did not
check the validity of the parameters, resulting in an address access
exception vulnerability. So I want to know if this is a problem in FFmpage,
so I sent
On Mon, 16. Mar 10:03, Ming Qian wrote:
> when the last frame of capture is dequeueed,
> driver may send this V4L2_EVENT_EOS event,
> if this event is received, then we can set the capture port done
Please add to your commit message (or something similar depending on what you
tested):
"Without th
You're welcome. Can this bug help me apply for a CVE?
On Tue, Mar 17, 2020 at 12:20 PM Andriy Gelman
wrote:
> On Mon, 16. Mar 10:03, Ming Qian wrote:
> > when the last frame of capture is dequeueed,
> > driver may send this V4L2_EVENT_EOS event,
> > if this event is received, then we can set the
83 matches
Mail list logo
