I have a file with audio in the format pcm_s16be. When I try to copy this audio
to another file using -c:a copy, it copies the audio but also transcodes it to
AAC.
If it's literally a copy, shouldn't the copy be pcm_s16be as well? How can I do
this and wind up with a pcm copy of the original aud
About a year ago I posted some concerns about color accuracy and received this
response:
> The specific code I'm referring to is at the end of colorspace.h
>
> #define RGB_TO_Y(r1, g1, b1, shift)
> #define RGB_TO_U(r1, g1, b1, shift)
> #define RGB_TO_V(r1, g1, b1, shift)
>A quick search over th
Hello -
I have found what I believe to be some questionable code in colorspace.h. I
have modified the code to what I believe is correct but am unable to compile
ffmpeg myself on Windows to test my modifications, despite spending many hours
trying to do so and reading several how-to's.
We can d
m: Michael Niedermayer
To: FFmpeg development discussions and patches
Sent: Wed, Jun 3, 2015 11:52 am
Subject: Re: [FFmpeg-devel] colorspace.h
On Tue, Jun 02, 2015 at 02:28:59AM -0400, Chris wrote:
> Hello -
>
> I have
found what I believe to be some questionable code in colorspace.h.
I don't know if we're talking about the same thing, but if ffmpeg is to support
BT.2020, some thought should be given to 12-bit samples.
-Original Message-
From: Kevin Wells
To: ffmpeg-devel
Sent: Wed, Jun 3, 2015 12:17 pm
Subject: [FFmpeg-devel] colormatrix high-bit-depth input suppor
gram will be written with both 601 and 709. It will be expandable to
other color spaces.
-Original Message-
From: Michael Niedermayer
To: FFmpeg development discussions and patches
Sent: Wed, Jun 3, 2015 11:52 am
Subject: Re: [FFmpeg-devel] colorspace.h
On Tue, Jun 02, 2015 at 02:28:59AM
ors
encode(255,128,0,709); //use 601 or 709 as last argument
}
==
-Original Message-
From: Michael Niedermayer
To: FFmpeg development discussions and patches
Sent: Wed, Jun 3, 2015 11:52 am
Subject: Re: [FFmpeg-devel] colorspace.h
On Tue, Jun 02, 2015 at 02:28:59AM -0400, Chris
Here is some interesting reading on the subject:
http://en.wikipedia.org/wiki/Rec._2020
https://www.itu.int/dms_pubrec/itu-r/rec/bt/R-REC-BT.2020-1-201406-I!!PDF-E.pdf
There are two bit depths in BT.2020: 10 bits and 12 bits. There are also two
screen resolutions, known informally as "4k" and "
rs
encode(255,128,0,601); //use 601 or 709 as last argument
}
-Original Message-
From: Michael Niedermayer
To: FFmpeg development discussions and patches
Sent: Wed, Jun 3, 2015 11:52 am
Subject: Re: [FFmpeg-devel] colorspace.h
On Tue, Jun 02, 2015 at 02:28:59AM -0400, Chris wrote:
>
Only "succeed" to read a header if the codec is valid. Otherwise
return AVERROR_INVALIDDATA.
---
libavformat/oggparseogm.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index a07453760b..e71298d39a 100644
---
ommit/81b743eb1026547270b88ac6a5cb451a3907ee94?diff=split#diff-efd47f302b213c4dc0e419c52a192819L384),
but this was a little out of my depth and not critical to address my
particular bug
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/ma
This behavior was added in 2010 to suport some old (and invalid) ogm
files.
https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94
But this makes it possible to change the codec in the later headers,
causing codec to be out of sync with internal avctx (eventually
trigger
mes Almer wrote:
>
> > On 6/14/2019 11:52 AM, Reimar Döffinger wrote:
> >>
> >>
> >> On 14.06.2019, at 03:15, Chris Cunningham
> wrote:
> >>
> >>> Only "succeed" to read a header if the codec is valid. Otherwise
> >>
+James
On Mon, Jun 17, 2019 at 6:31 PM Chris Cunningham
wrote:
> This behavior was added in 2010 to suport some old (and invalid) ogm
> files.
> https://github.com/FFmpeg/FFmpeg/commit/81b743eb1026547270b88ac6a5cb451a3907ee94
>
> But this makes it possible to change the cod
few headers followed by a data
packet (stream 0), followed by more headers for streams 1 - 3.
We knew this change would break such files. Can we live it? James, any
workaround? If not I'm still open to
setting st->internal->need_context_update as discussed in the earlier patch
(h
On Wed, Jun 19, 2019 at 7:11 PM Chris Cunningham
wrote:
> On Wed, Jun 19, 2019 at 11:25 AM Michael Niedermayer
> wrote:
>
>> breaks:
>> ./ffmpeg -i bgc.sub.dub.ogm -vframes 3 -y test.webm
>> sample: http://samples.mplayerhq.hu/ogg/bgc.sub.dub.ogm
>>
>&
On Thu, Feb 28, 2019 at 9:13 AM James Almer wrote:
> On 2/26/2019 10:18 PM, Chris Cunningham wrote:
> > On Thu, Feb 21, 2019 at 4:46 PM Chris Cunningham
> > mailto:chcunning...@chromium.org>> wrote:
> >
> > I'm fine to do either. James, do you still pr
Friendly ping.
On Thu, Jun 20, 2019 at 11:17 AM Chris Cunningham
wrote:
> On Thu, Feb 28, 2019 at 9:13 AM James Almer wrote:
>
>> On 2/26/2019 10:18 PM, Chris Cunningham wrote:
>> > On Thu, Feb 21, 2019 at 4:46 PM Chris Cunningham
>> > mailto:chc
On Tue, Oct 23, 2018 at 6:28 PM James Almer wrote:
> On 10/23/2018 10:16 PM, chcunningham wrote:
> > ---
> > libavcodec/vp9_parser.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> > index 9531f34a32..b6b621198b 100644
> > ---
On Wed, Oct 3, 2018 at 10:49 AM James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/vp9_parser.c | 82 -
> 1 file changed, 80 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/vp9_parser.c b/libavcodec/vp9_parser.c
> index 9531f34a3
facing codec private via extradata (reverting this change
<http://ffmpeg.org/pipermail/ffmpeg-devel/2018-February/225548.html>)?
On Thu, Oct 25, 2018 at 4:50 PM James Almer wrote:
> On 10/24/2018 3:12 PM, Chris Cunningham wrote:
> > On Wed, Oct 3, 2018 at 10:49 AM James Almer w
util.h#L31
YouTube isn't doing it yet for VP9. But I think its required with AV1
content, so maybe we'll see it with new VP9 encodes too down the road.
Parsing the frame is definitely our best bet.
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Fri, Nov 2, 2018 at 4:57 PM Chris Cunningham
wrote:
> > Also, when dealing with a super frame, to get other values like pixel
> > format and frame dimensions we'd have to make sure to parse the visible
> > frame, and if it's an inter frame also keep the referen
>
> Yet another problem that could have been caught by static analysis..
> Wouldn't it be better to always leave the array in a valid state?
>
Will add that in the next patch. It has the extra benefit of protecting the
isv34 branch.
Goto fail; skips a lot of lines that aren't needed if mimetype i
> I have at least 2 files which have a id of 0
> Iam not sure where they are from so iam not sure i can share them
This was my fear as well. Also, we currently default the ID for a new
stream to be the number of streams now in the list. I worried that some
files may lack a tkhd or could be structu
. I'll send a new patch
and we can see if Michael finds new breaks.
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
s reasonably high.
Still, I'll take a stab at the approach, if just for discussion/testing.
On Thu, Dec 13, 2018 at 12:39 PM Chris Cunningham
wrote:
> "st->id" is not necessary for demuxing AFAIK, please correct me if Im
>> wrong.
>> Would an init value to
>
> -char mimetype[64];
> +char mimetype[64] = {0};
>
> would be enough
>
Agree! Next patch.
I'd love to do similar for the isv34 branch, but I'm not sure how to detect
> the condition given the EOF behavior for avio_get_str:
> * @return number of bytes read (is always <= maxlen).
> * If readi
>
> from a quick look, i did not find a file this breaks
>
Woot. Baptiste, I'm happy with this last patch if you are.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Fix ticket: 8693
Based on implementation in hlsenc.c
Signed-off-by: Chris Ribble
---
libavformat/dashenc.c | 67 ++-
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 00a37b175d..a45d9bc7d0
On Tue, Jun 2, 2020 at 12:22 AM Siyuan Huang
wrote:
> Hello Chris Ribble
>
>
>
> Looks you are working for http patch ,
>
> Can you share a test script for it ?
>
>
Siyuan Huang,
There is a description of the problem in the Trac ticket along with an
example of how to
> Hello Chris Ribble
>
>
>
> Looks you are working for http patch ,
>
> Can you share a test script for it ?
>
There is a description of the problem in the Trac ticket along with an
example of how to reproduce the issue:
https://trac.ffmpeg.org/ticket/8693
Let m
On Sat, Oct 26, 2019 at 4:15 AM Carl Eugen Hoyos wrote:
>
> Am Sa., 26. Okt. 2019 um 06:45 Uhr schrieb :
>
> > +// convert from avframe to iplimage format
> > +static int fill_iplimage_from_frame(IplImage *img, const AVFrame *frame,
> > enum AVPixelFormat pixfmt)
> > +{
> > +IplImage *tmpimg;
On Sat, Oct 26, 2019 at 8:50 AM Jan Ekström wrote:
> Hi,
>
> On Sat, Oct 26, 2019 at 4:35 PM Christopher Kennedy
> wrote:
> > The C OpenCV API is not recommended so this does the OpenCV part
> > in C++ which allows it to be fully utilized and supported. So that seems
> > better to me than using
ADTS frames may contain up to 768 bytes per channel. With 16 channels,
this is 12k, which cannot fit into the maximum 8k buffer.
Signed-off-by: Chris Ribble
---
libavformat/adtsenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/adtsenc.c b/libavformat
Fix ticket: 8693
Based on implementation in hlsenc.c
Signed-off-by: Chris Ribble
---
libavformat/dashenc.c | 67 ++-
1 file changed, 53 insertions(+), 14 deletions(-)
diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index 81a5c2b452..593c416850
On Wed, Jan 30, 2019 at 1:40 PM James Almer wrote:
> Parsers can't return negative values, only the output packet size. For
> the purpose of errors, they usually return the entire untouched packet
> size.
>
Understood. Is this documented somewhere? I noted the comment in
av_paser_parse2(), "/* W
odec_id? It never is in this test.
- Should we reset st->parser whenever we reset st->codecpar->codec_id
(step 5 above)?
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> On 1/30/2019 10:20 PM, Chris Cunningham wrote:
> >>
> >>>> And this definitely means there's a bug elsewhere. This parser should
> >>>> have not been used for codecs ids other than GSM and GSM_MS
Some extra context: this remedies some bad math that otherwise triggers an
abort near the bottom of mov_seek_stream().
My first thought on seeing this was we should probably be
returning AVERROR_INVALIDDATA somewhere. The stsc and stco boxes aren't
agreeing (stco says no chunks, stsc.first points
crutiny
> when their type is changed
>
I really appreciate the scrutiny. Given I don't have a file that needs
this, happy to abandon this patch.
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
On Sat, Feb 2, 2019 at 3:55 AM Michael Niedermayer
wrote:
> > static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc,
> unsigned int index)
> > {
> > -int chunk_count;
> > +unsigned int chunk_count = 0;
> >
> > if (mov_stsc_index_valid(index, sc->stsc_count))
> >
>
> The underlined bit above seems like the root cause. Where should we be
> updating st->internal->avctx->codec_id?
>
Friendly ping for review
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
This is a follow up to feedback in
http://ffmpeg.org/pipermail/ffmpeg-devel/2019-February/239751.html
On Wed, Feb 6, 2019 at 5:13 PM chcunningham
wrote:
> Codec information may change while reading ogg packets. Update the
> stream's internal avctx to match.
> ---
> libavformat/oggparseogm.c | 3
Thanks, this works great. Stand by for patch.
On Wed, Feb 6, 2019 at 8:38 AM Hendrik Leppkes wrote:
> On Thu, Jan 31, 2019 at 11:29 PM Chris Cunningham
> wrote:
> >
> > On Wed, Jan 30, 2019 at 5:43 PM James Almer wrote:
> >
> > > On 1/30/2019
This will reject the file entirely. The testcase I have (can share once
chromium bug is fixed) was previously hitting an av_assert0 in
mov_read_trun, arguably also a total rejection ;). Recovery for this could
be pretty tricky since the dropped trun will break decode dependencies. I
would be surpri
Thanks! Looking at that file, I notice the stsc refers to some unknown
chunks (stsco has no chunk offsets), but this is a non-issue since stts has
no samples. Next patch will detect this condition and simply clear out stsc
structures since they're not needed and contradict stco.
On Wed, Feb 6, 201
On Wed, Feb 6, 2019 at 6:03 PM James Almer wrote:
> Can a valid ogm stream contain more than one header packet?
Looking at ogg_packet oggdec.c, we read headers until hitting the first
non-header (counted in ogg stream field nb_headers), so multiple headers
per stream is probably ok. But multipl
> developers dislike this:
> (and i cannot edit other authors names of course, that would be not right)
>
> (from IRC)
> Could you stop committing things like this?
> his name is "Chris Cunningham", not "chcunningham"
>
> [...]
> --
> Michael G
Codec information may change while reading ogg packets. Update the
stream's internal avctx to match.
---
libavformat/oggparseogm.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavformat/oggparseogm.c b/libavformat/oggparseogm.c
index a07453760b..b07a5d55ba 100644
--- a/libavformat/oggp
On Fri, Feb 8, 2019 at 2:37 PM Michael Niedermayer wrote:
> ogg allows chaining streams when they have differing serial numbers
> https://xiph.org/ogg/doc/oggstream.html
>
> i think ive seen actual files doing this
>
> ogg_replace_stream() might assign these into existing avstreams i think
>
If
On Mon, Feb 11, 2019 at 1:55 PM Chris Cunningham
wrote:
> On Fri, Feb 8, 2019 at 2:37 PM Michael Niedermayer
> wrote:
>
>> ogg allows chaining streams when they have differing serial numbers
>> https://xiph.org/ogg/doc/oggstream.html
>>
>> i think
I'm fine to do either. James, do you still prefer to skip the later headers
if this breaks some old ogm files?
On Sat, Feb 16, 2019 at 4:52 PM Michael Niedermayer
wrote:
> On Fri, Feb 15, 2019 at 02:56:18PM -0800, Chris Cunningham wrote:
> > On Mon, Feb 11, 2019 at 1:55 PM Ch
On Thu, Feb 21, 2019 at 4:46 PM Chris Cunningham
wrote:
> I'm fine to do either. James, do you still prefer to skip the later
> headers if this breaks some old ogm files?
>
James, friendly ping
___
ffmpeg-devel mailing list
ffmpeg-de
When seeking a file where codec delay is greater than 0, the timecode
can become negative after offsetting by the codec delay. Failing to cast
to a signed int64 will cause the check against skip_to_timecode to evaluate
true for these negative values. This breaks the "skip_to" seek mechanism.
---
l
find that the playback begins from the 2
second time.
On Thu, Jul 21, 2016 at 12:01 PM, Chris Cunningham <
chcunning...@chromium.org> wrote:
> When seeking a file where codec delay is greater than 0, the timecode
> can become negative after offsetting by the codec delay. Failing to
Happy to make a test. Stand by for patch.
On Sat, Jul 23, 2016 at 2:26 AM, Michael Niedermayer wrote:
> On Thu, Jul 21, 2016 at 12:01:45PM -0700, Chris Cunningham wrote:
> > When seeking a file where codec delay is greater than 0, the timecode
> > can become negative after of
:
> From: Chris Cunningham
>
> Also cleanup parens for the skip_to_timecode check.
> ---
> libavformat/matroskadec.c | 2 +-
> tests/fate/seek.mak| 3 +++
> tests/ref/seek/mkv-codec-delay | 48
> ++
> 3 files c
Thanks Michael. Do you mean to also apply the patch to add the test? Maybe
you're waiting for further review.
On Thu, Jul 28, 2016 at 9:48 AM, Michael Niedermayer wrote:
> On Wed, Jul 27, 2016 at 06:35:50PM -0700, Chris Cunningham wrote:
> > The file to upload to fate-suite can
Thanks Michael. Do you mean to also apply the patch to add the test? Maybe
you're waiting for further review.
On Thu, Jul 28, 2016 at 9:48 AM, Michael Niedermayer wrote:
> On Wed, Jul 27, 2016 at 06:35:50PM -0700, Chris Cunningham wrote:
> > The file to upload to fate-suite can
From: Chris Landry
When a video stream timebase is not 90k, the cc packet pts is relevant to the
timebase of the video stream, but later is assumed to be 90k. Adjust it here to
be 90k so timing is accurate in resulting subs.
Signed-off-by: Chris Landry
---
libavdevice/lavfi.c | 11
From: Chris Landry
Should have used av_rescale_q to do the timebase adjustment. Fixed compiler
warning for variable declaration.
Signed-off-by: Chris Landry
---
libavdevice/lavfi.c | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/libavdevice/lavfi.c b/libavdevice
Sorry, this was supposed to be submitted in response to my thread on this
one. New to sending email with git.
On Sat, Oct 1, 2016 at 2:04 PM, Chris Landry
wrote:
> From: Chris Landry
>
> Should have used av_rescale_q to do the timebase adjustment. Fixed
> compiler warning
From: Chris Landry
When a video stream timebase is not 90k, the cc packet pts is relevant to the
timebase of the video stream, but later is assumed to be 90k. Adjust it here to
be 90k so timing is accurate in resulting subs.
Signed-off-by: Chris Landry
---
libavdevice/lavfi.c | 11
27 AM, Michael Niedermayer
wrote:
> On Fri, Sep 30, 2016 at 11:02:32PM -0400, Chris Landry wrote:
> > From: Chris Landry
> >
> > When a video stream timebase is not 90k, the cc packet pts is relevant
> to the timebase of the video stream, but later is assumed to be 90k. Adjust
ormat/oggparsevorbis.c#L286
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
ed, Mar 23, 2016 at 1:56 PM, Reimar Döffinger
wrote:
> On Wed, Mar 23, 2016 at 03:31:38PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 22, 2016 at 11:43:50PM -0700, Chris Cunningham wrote:
> > > Hey Group,
> > >
> > > I'm seeing an interesting pattern [0][
Leaking this private structure opens up the possibility that it may
be re-used when parsing later packets in the stream. This is
problematic if the later packets are not the same codec type (e.g.
private allocated during Vorbis parsing, but later packets are Opus
and the private is assumed to be th
New patch drops the U. Hendrik, you'r right about the negative, but you're
also right about the 0. 0 is a case of undefined shift behavior (shift
becomes -1).
On Tue, May 17, 2016 at 11:28 AM, wrote:
> From: Chris Cunningham
>
> Fixes: undefined shift.
> ---
> libavf
just have a misunderstanding.
Chris.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Blocks are marked as key frames whenever the "reference" field is
zero. This is incorrect for non-keyframe Blocks that take a refernce
on a keyframe at time zero.
Now using -1 to denote "no reference".
Reported to chromium at http://crbug.com/497889 (contains sample)
---
libavformat/matroskadec.
On Tue, Jan 31, 2017 at 1:07 AM, wm4 wrote:
> On Tue, 31 Jan 2017 09:57:24 +0100
> wm4 wrote:
>
> > On Mon, 30 Jan 2017 17:05:49 -0800
> > Chris Cunningham wrote:
> >
> > > Blocks are marked as key frames whenever the "reference" field is
> &g
On Tue, Jan 31, 2017 at 10:18 PM, wm4 wrote:
> On Tue, 31 Jan 2017 12:02:01 -0800
> Chris Cunningham wrote:
>
> > Thanks for taking a look.
> >
> > Definitely missing a "break;" - will fix in subsequent patch.
> >
> > Agree timestamps should
Blocks are marked as key frames whenever the "reference" field is
zero. This breaks for non-keyframe Blocks with a reference timestamp
of zero.
The likelihood of reference timestamp being zero is increased by a
longstanding bug in muxing that encodes reference timestamp as the
absolute time of the
, which is mandatory.[1] This fixes a GPU crash when using RADV.
[1]
https://registry.khronos.org/vulkan/specs/1.3-extensions/man/html/VkImageCreateInfo.html#VUID-VkImageCreateInfo-usage-04815
Signed-off-by: Chris Spencer
---
libavutil/hwcontext_vulkan.c | 3 ++-
1 file changed, 2 insertions(+), 1
s from the community, have a great day.
Thanks,
Chris Miceli
___
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".
ailing
list or similar).
Thank you for this work, I think that it will help this ffmpeg community
thrive.
*Chris Miceli*
On Tue, Oct 6, 2020 at 8:12 AM Jean-Baptiste Kempf wrote:
> General Assembly + Main Elections
> ---
> doc/dev_community/community.md | 60 ++
As per ticket #8901 there is a compilation issue where there is
an undefined reference when compiled with a minimal set of filters.
This commit remedies that by ensuring decoders which have SEI parsers
import the relevent caption object and hence functionality.
---
libavcodec/Makefile | 6 +++---
The lack of AVIOContext means that ffmpeg was attempting to open
logfiles for two pass encoding with the "protocol" part of the url on
the first pass. This manifested mainly when a user needed to have a
colon in the filename as they would require a url style path (according
to #8898).
---
fftools/
es and the tip of git on a wide range of these will help
ensure that bugs are caught quickly and effectively.
Happy to help integrate whichever system we think would work best for this,
just want to ideally have a good means to know that origin/master is
constantly well tested!
Thanks,
*Chris Micel
ticket 8931 mentions some missing null pointer checks and so this is one
diff of a few which are for these fixes. There are previous code pieces
which return ENOMEM, so this should work as intended.
---
libavfilter/af_mcompand.c | 12
1 file changed, 12 insertions(+)
diff --git a/lib
A report on Trac came in about this failure scenario where there are
potential failures to allocate memory which are going unchecked in the
code. This should fix that error in the same way that other parts of the
codebase already handle similar situations
---
libavfilter/dnn/dnn_backend_native.c |
This commit fixes some unchecked memory allocations from #8931.
---
libavfilter/af_mcompand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/af_mcompand.c b/libavfilter/af_mcompand.c
index f142573bea..5309d884a5 100644
--- a/libavfilter/af_mcompand.c
+++ b/libavfilter/af_
A report on Trac came in about this failure scenario where there are
potential failures to allocate memory which are going unchecked in the
code. This should fix that error in the same way that other parts of the
codebase already handle similar situations
---
libavfilter/dnn/dnn_backend_native.c |
check that frame allocations return non-null.
---
libavfilter/dnn/dnn_backend_native.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index d45e211f0c..d1eb992335 100644
--- a/libavfilter/dnn/dnn_backend_nati
Please disregard this for the replacement titled:
libavfilter/dnn_backend_native: check mem allocation.
Thanks,
*Chris Miceli*
On Tue, Oct 13, 2020 at 1:34 PM Chris Miceli wrote:
> A report on Trac came in about this failure scenario where there are
> potential failures to allocate
Memory allocation for AVIOContext should be checked. In this code,
all error conditions are sent to the "goto error".
---
libavformat/avidec.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 9765e5e7b2..33e50e9878 100644
This commit fixes some unchecked memory allocations from #8931.
---
libavfilter/af_mcompand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/af_mcompand.c b/libavfilter/af_mcompand.c
index f142573bea..96293909de 100644
--- a/libavfilter/af_mcompand.c
+++ b/libavfilter/af_
This commit fixes some unchecked memory allocations from #8931.
---
libavfilter/af_mcompand.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/af_mcompand.c b/libavfilter/af_mcompand.c
index f142573bea..96293909de 100644
--- a/libavfilter/af_mcompand.c
+++ b/libavfilter/af_
check that frame allocations return non-null.
---
libavfilter/dnn/dnn_backend_native.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index d45e211f0c..cda857a9c5 100644
--- a/libavfilter/dnn/dnn_backend_nat
6f69f7a8bf6a0d013985578df2ef42ee6b1c7994 introduced this and it was part
of a very large merging of refactoring. Current behaviour is what is
reflected by this indenting change, however my understanding of timing
is such that this correct behaviour.
---
libavformat/utils.c | 3 +--
1 file changed,
check that frame allocations return non-null.
---
libavfilter/dnn/dnn_backend_native.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index d45e211f0c..7958ceb4f7 100644
--- a/libavfilte
new_init_section will return NULL under circumstances where the init
failed and this code needed to check for that. ret and goto fail are how
this is handled throughout the code.
---
libavformat/hls.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
ind
asier? In cases where
people have a large system using this, it just seems like it would be
easier to chase down issues.
Thanks,
Chris
On Tue, Oct 13, 2020, 7:19 PM Guo, Yejun wrote:
> TensorFlow C library accepts config for session options to
> set different parameters for the inference.
check that frame allocations return non-null.
---
libavfilter/dnn/dnn_backend_native.c | 17 -
1 file changed, 16 insertions(+), 1 deletion(-)
diff --git a/libavfilter/dnn/dnn_backend_native.c
b/libavfilter/dnn/dnn_backend_native.c
index d45e211f0c..4fc3ba2044 100644
--- a/libavf
These previously would not check that the return value was non-null
meaning it was susceptible to a sigsegv. This checks those values.
---
libavfilter/dnn/dnn_backend_openvino.c | 14 +-
libavfilter/dnn/dnn_backend_tf.c | 16 +++-
2 files changed, 28 insertions(+), 2
This reverts commit 03d81a044ad587ea83567f75dc36bc3d64278199.
This change broke the ability to read mp4 files which contain a trun
atom with a sample of size zero (FFmpeg exits while parsing the moof).
Signed-off-by: Chris Ribble
---
libavformat/mov.c | 2 --
1 file changed, 2 deletions
ut FFmpeg is that it can fix invalid
container metadata. I feel like losing that capability for this
scenario is a regression.
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To uns
DATA;
Sorry if I was supposed to provide this feedback on the patch series
itself; I'm happy to do so there as needed.
Thanks,
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsu
On Mon, Dec 5, 2022 at 12:04 PM Marton Balint wrote:
>
> Share the sample please. If the patch I proposed does not fix it, I am not
> sure what is the best approach here.
>
Sure, I will send you the URL to the file so that you can try it.
___
ffmpeg-dev
1 - 100 of 163 matches
Mail list logo
