Scott Theisen:
> On 2/4/22 10:16, Andreas Rheinhardt wrote:
>> This is by definition the appropriate place for it.
>> Remove all the now unnecessary libavcodec/internal.h inclusions;
>> also remove other unnecessary headers from the affected files.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>
On 2/4/22 14:01, Scott Theisen wrote:
I assume this is inspired by my patch series. Did you see v2 of my
patch series where I made similar and more extensive clarifications?
The check for sequence_end_codes should not be in the loop. It harms
readability, although you also eliminated the b
On 2/5/22 01:10, Andreas Rheinhardt wrote:
1. This patch is absolutely unacceptable: It breaks ABI.
2. I am surprised that there is apparently only one user that actually
wants this feature of state being an input parameter, namely
(ff_)mpeg1_find_frame_end(). This means that this loop done befor
On Sat, 5 Feb 2022, lance.lmw...@gmail.com wrote:
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/udp.c | 31 ---
1 file changed, 20 insertions(+), 11 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 83c042d..3dc79eb 100644
--- a/
On Sat, 5 Feb 2022, lance.lmw...@gmail.com wrote:
From: Limin Wang
Suggested by zhilizhao, vlc project has solved the compatibility by
the same way, so I borrowed the comments from vlc project.
Fix #ticket9449
Signed-off-by: Limin Wang
---
libavformat/udp.c | 15 +--
1 file ch
On Sat, Feb 05, 2022 at 10:59:55AM +0100, Marton Balint wrote:
>
>
> On Sat, 5 Feb 2022, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Suggested by zhilizhao, vlc project has solved the compatibility by
> > the same way, so I borrowed the comments from vlc project.
> >
> > Fix
On Sat, Feb 05, 2022 at 10:58:08AM +0100, Marton Balint wrote:
>
>
> On Sat, 5 Feb 2022, lance.lmw...@gmail.com wrote:
>
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavformat/udp.c | 31 ---
> > 1 file changed, 20 insertions(+), 11 deletions
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/udp.c | 32
1 file changed, 20 insertions(+), 12 deletions(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 83c042d..8178d0e 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -162,22
From: Limin Wang
Suggested by zhilizhao, vlc project has solved the compatibility by
the same way, so I borrowed the comments from vlc project.
Fix #ticket9449
Signed-off-by: Limin Wang
---
libavformat/udp.c | 15 +--
1 file changed, 13 insertions(+), 2 deletions(-)
diff --git a/
From: Limin Wang
Signed-off-by: Limin Wang
---
libavformat/udp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/udp.c b/libavformat/udp.c
index 1871acf..9f6ab1b 100644
--- a/libavformat/udp.c
+++ b/libavformat/udp.c
@@ -175,7 +175,7 @@ static int udp_set_multica
the top_field_first bit is only used to indicate the field order
when the picture is a frame picture (which consists of two fields)
but not when it is a field picture (which consists of one single
top or bottom field).
Signed-off-by: Tom Yan
---
libavcodec/mpegvideo_parser.c | 7 +--
1 file
Signed-off-by: Zane van Iperen
---
libavformat/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3dc6a479cc..6566e40cac 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -374,7 +374,7 @@ OBJS-$(CONFIG_MTV_D
It can probably be simplified to this:
...
if (progressive_frame)
s->field_order = AV_FIELD_PROGRESSIVE;
/* top_field_first is mandated to be 0 when
picture_structure is not 3 (i.e. not a frame picture) */
else if (top_field_first || picture_structure == 1)
s->field_order = AV_FIELD_TT;
bca30570d2 added a user option to set max_packet_size replacing
a hardcoded value. This had a side-effect of leaving the field
set to 0 when packet demuxing is carried out from another demuxer
using avpriv functions, which could lead to demux failure.
Hardcoded max_packet_size inside avpriv_mpegts
On 2022-02-02 10:54 am, Gyan Doshi wrote:
On 2022-02-02 12:42 am, James Almer wrote:
On 2/1/2022 3:47 PM, Michael Niedermayer wrote:
On Sun, Jan 16, 2022 at 05:19:15AM +, Gyan Doshi wrote:
ffmpeg | branch: master | Gyan Doshi | Wed Jan
12 20:57:59 2022 +0530| [bca30570d28bbaa07badad
On 2/5/2022 9:51 AM, Tom Yan wrote:
the top_field_first bit is only used to indicate the field order
when the picture is a frame picture (which consists of two fields)
but not when it is a field picture (which consists of one single
top or bottom field).
Signed-off-by: Tom Yan
---
libavcodec/
Signed-off-by: Paul B Mahol
---
libavfilter/Makefile | 1 +
libavfilter/af_dialogenhance.c | 420 +
libavfilter/allfilters.c | 1 +
3 files changed, 422 insertions(+)
create mode 100644 libavfilter/af_dialogenhance.c
diff --git a/libavfilter/M
Have this been tested?
For example changing delays multiple times per invocation?
___
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...@ffmp
Hi, I'm implementing a pipeline where I receive inbound RTP packets in
memory but I'm having trouble figuring out how to set up libavformat to
handle/unwrap the RTP packets.
I have all relevant information about the underlying codec necessary but
since it's h264 I cannot simply strip the RTP heade
Fixes: left shift of 32768 by 16 places cannot be represented in type 'int'
Fixes: Timeout
Fixes:
44219/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4679455379947520
Fixes:
44088/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SMVJPEG_fuzzer-4885976600674304
Found-by: conti
Fixes: Division by 0
Fixes:
44035/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4826721386364928
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/matroskadec.c | 2 ++
1
Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL
field is only 8-bits), it should always be capped at 255 (for consistency) or
return an invalid value error (the one I would suggest).
Despite VLC's reversed comment, using an int seems to be the exception to the
rule
Zane van Iperen:
> Signed-off-by: Zane van Iperen
> ---
> libavformat/Makefile | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 3dc6a479cc..6566e40cac 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@
Michael Niedermayer:
> Fixes: Division by 0
> Fixes:
> 44035/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4826721386364928
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer
> ---
Andreas Rheinhardt:
> Michael Niedermayer:
>> Fixes: Division by 0
>> Fixes:
>> 44035/clusterfuzz-testcase-minimized-ffmpeg_dem_WEBM_DASH_MANIFEST_fuzzer-4826721386364928
>>
>> Found-by: continuous fuzzing process
>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
>> Signed-off-by:
On Sat, Feb 05, 2022 at 02:08:48 +, Soft Works wrote:
> Let's try to approach this from a different side. Which case is
> your [1/2] commit actually supposed to fix?
Escape backslashes when converting from WebVTT to not accidentally
introduce active ASS sequences and replace the wrong backslas
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Oneric
> Sent: Saturday, February 5, 2022 11:00 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
> On Sat, F
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Sunday, February 6, 2022 2:09 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
>
>
> >
On Sat, Feb 05, 2022 at 01:26:18PM -0800, Chad Fraleigh wrote:
> Since any [valid] value over 255 is impossible in the IPv4 protocol (the TTL
> field is only 8-bits), it should always be capped at 255 (for consistency) or
> return an invalid value error (the one I would suggest).
>
zhilizhao ha
the top_field_first bit is only used to indicate the field order
when the picture is a frame picture (which consists of two fields)
but not when it is a field picture (which consists of one single
top or bottom field).
also removing the unnecessary progressive_sequence check (the bit
is mandated t
Tom Yan:
> the top_field_first bit is only used to indicate the field order
> when the picture is a frame picture (which consists of two fields)
> but not when it is a field picture (which consists of one single
> top or bottom field).
>
> also removing the unnecessary progressive_sequence check (
31 matches
Mail list logo
