expectation.
Good find! I didn't have sources that kept the OBU size field (just curious,
what did you use to generate these RTP streams?), and your fix looks good
to me (although I didn't verify it).
--
Best regards,
Chris
___
ffmpeg-devel ma
Fixed warning about OBU count being wrong, which can only be
determined when the number of OBUs in the header is non-zero,
not the other way round.
Signed-off-by: Chris Hodges
---
libavformat/rtpdec_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat
on the list and address problems and feedback with the new
code, if there is any.
--
Best regards
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
enabled the extra scan for the sequence
header OBU.
--
Best regards
Chris
--- Begin Message ---
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP
the point of corruption), I didn't see any stream corruption anymore.
Best regards,
Chris
PS: Will be unavailable over xmas. God jul!
--
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To un
(although the RTP packet was not fragmented and the output could be
considered "complete" in the term of data acquired).
--
Best regards, Chris--- Begin Message ---
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via
fragmented OBUs
with "unlucky" growths regarding the number of LEB bytes, when the
fragmented OBU wasn't the last one in the temporal unit.
--
Best regards, Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org
bination therein.
I haven't been working with such complex frame hierarchies, but I will
try to get the Chimera working.
--
Best regards, Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-deve
Nuo Mi wrote:
> This will introduce two writes for all blocks, even if there is no CC ALF.
How about checking the sps_ccalf_enabled_flag in ff_vvc_alf_filter?
That makes sense too, but I'd think you'd need to check both
sps_ccalf_enabled_flag and the slice header
sh_alf_cc_cb_enabled_flag/sh_alf
e AVPacket during demuxing that was
missing before.
New patch attached.
--
Best regards, Chris--- Begin Message ---
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been teste
When a stream has ALF filtering enabled but not CC-ALF, the CC-ALF set indexes
alf->ctb_cc_idc are being read uninitialized during ALF filtering.
This change initializes alf->ctb_cc_idc whenever ALF is enabled.
Ref. https://trac.ffmpeg.org/ticket/11325
---
libavcodec/vvc/ctu.c | 2 +-
1 file c
urrently missing
in the RTP state.
I would therefore look into the latter and see if I can pin-point and
fix that.
Thanks for your feedback, it is appreciated. I hope to collect more
reviews in the upcoming weeks and will come up with an updated patch.
--
Chris
Hi Anton (sorry for the PM),
Your mailer mangled the newlines in the patch. Consider a different
mailer or sending it as an attachment.
Thanks for the info, had sent it with Thunderbird. Resending it as
attachment.
--
Chris--- Begin Message ---
Add RTP packetizer and depacketizer according
Add RTP packetizer and depacketizer according to (most)
of the official AV1 RTP specification. This enables
streaming via RTSP between ffmpeg and ffmpeg and has
also been tested to work with AV1 RTSP streams via
GStreamer.
It also adds the required SDP additions.
Signed-off-by: Chris Hodges
pen for all review requests regarding the implementation, this is
also my first dive into the ffmpeg code base, so if I missed something,
I will be glad to fix it.
Thank you. Patch follows.
--
Chris
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.
, 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
Hello,
I am writing this mail for request consider use codec id "sowt" instead
of "ipcm" for AV_CODEC_ID_PCM_S16LE in mp4 muxer, and
AV_CODEC_ID_PCM_S16BE accordingly. This only needs a minor change on code:
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a9c8e104f0..2b984789f5
On Sun, Dec 11, 2022 at 2:34 PM Chris Ribble wrote:
>
> This looks great and I've confirmed it fixes the issue. I see the
> warning on STDERR about ignoring the trun box: "Ignoring trun box with
> zero sized samples", which is great.
>
Actually, this introd
eturn AVERROR_INVALIDDATA;
> dts += sample_duration;
> offset += sample_size;
> sc->data_size += sample_size;
> --
> 2.35.3
Marton,
This looks great and I've confirmed it fixes the issue. I see the
warning on STDERR about ignoring th
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
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
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
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
g so I can reproduce
and fix?
- Chris
On Wed, Jul 20, 2022 at 6:17 AM Michael Niedermayer
wrote:
> On Tue, Jul 19, 2022 at 09:41:17PM -0700, Chris Phlipot wrote:
> > Add a new version of yadif_filter_line performed using packed bytes
> > instead of the packed words used by the current
limited ROI, as most AVX
users are likely on 64-bit OS at this point and 32-bit users would
lose out on most of the performance benefit.
Signed-off-by: Chris Phlipot
---
libavfilter/x86/Makefile | 2 +-
libavfilter/x86/vf_yadif_init.c | 11 +
libavfilter/x86/vf_yadif_x64.asm | 492
call to filter_edge.
In addtion we avoid running filter_line if it would read or write
pixels outside the current slice.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_yadi
Reformat some of the code to improve readability and reduce code
duplication. This change is intended to be purely cosmentic and
shouldn't result in any functional changes.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 11 +--
libavfilter/yadif.h| 3 +--
2 files ch
of an AVX2 implementation
could potentially hurt the performance of the SSE implementation,
so we allow yadif to use the smallest needed alignment instead to
maintain existing performance if implementations with wider vectors
are added.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c
If alignment is set to less than 4 filter_edges will produce incorrect
output and not filter the entire edge. To fix this, make sure that
the edge size is at least 3.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
limited ROI, as most AVX
users are likely on 64-bit OS at this point and 32-bit users would
lose out on most of the performance benefit.
Signed-off-by: Chris Phlipot
---
libavfilter/x86/Makefile | 2 +-
libavfilter/x86/vf_yadif_init.c | 9 +
libavfilter/x86/vf_yadif_x64.asm | 489
call to filter_edge.
In addtion we avoid running filter_line if it would read or write
pixels outside the current slice.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 23 +--
1 file changed, 21 insertions(+), 2 deletions(-)
diff --git a/libavfilter/vf_yadi
Reformat some of the code to improve readability and reduce code
duplication. This change is intended to be purely cosmentic and
shouldn't result in any functional changes.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 11 +--
libavfilter/yadif.h| 3 +--
2 files ch
of an AVX2 implementation
could potentially hurt the performance of the SSE implementation,
so we allow yadif to use the smallest needed alignment instead to
maintain existing performance if implementations with wider vectors
are added.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c
If alignment is set to less than 4 filter_edges will produce incorrect
output and not filter the entire edge. To fix this, make sure that
the edge size is at least 3.
Signed-off-by: Chris Phlipot
---
libavfilter/vf_yadif.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a
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
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
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
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
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.
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
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
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 | 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
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_
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
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
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
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 |
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
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
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/
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 +++---
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 ++
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".
In ticket #8754 there is discourse surrounding the error
message which is printed upon a mismatched aspect ratio in
derived encodings. This should make it clearer to the user
as to the issues which they are experiencing.
---
libavformat/dashenc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
ed to spend unnecessary time
maintaining the documentation system, concentrating instead on the
code itself.
Another benefit being that if there are other fixes you wish to make,
the entire doxygen community can benefit as well.
*Chris Miceli*
On Sun, Aug 23, 2020 at 8:39 PM Jim DeLaHunt
> 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 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
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
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
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
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;
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 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
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
>>
>&
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
+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
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
> >>
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
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
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
---
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
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 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
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
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
> 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
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
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
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, 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 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
>
> 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
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))
> >
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
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
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
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 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
>
> 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
>
> -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
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
. 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
> 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
>
> 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
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
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
1 - 100 of 163 matches
Mail list logo
