Re: [FFmpeg-devel] [PATCH] avformat/imf: s/++i/i++/g
Never apply this. Very sorry state of project. ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, February 4, 2022 6:34 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Soft
> > Works
> > Sent: Friday, February 4, 2022 2:58 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}:
> fix
> > handling of backslashes
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Oneric
> > > Sent: Friday, February 4, 2022 2:01 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 Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote:
> > > > I think when you inject that word-joiner as a workaround for ass
> > > > parsing, you'll also need to make sure that it gets removed
> > > > when encoding to other formats.
> > >
> > > There's no way of knowing whether the word-joiner comes from
> > > a conversion performed by ffmpeg in the past or already existed
> > > in the original source.
> >
> > That might be true, but I think it's valid to say that such
> characters
> > are very unusual "original" subtitle sources and that's why I don't
> > think it's a good idea for ffmpeg to start injecting them.
> >
> > Subtitle implementations are often rather minimal, especially in
> > hardware devices and might not always cover the full range of
> > UTF-8 specifics.
> >
> > > However, the wordjoiner does not alter the visually appearance and
> > > is unlikely to change line-breaking properties; that's why I chose
> > > a word-joiner. Therefore I don't think removing (only) the
> inserted
> > > word-joiners is possible,
> >
> > Why not? As it seems to be required for ASS encoding only, all other
> > output formats should remain unaffected.
> >
> > > but also not necessary.
> >
> > I'm not sure whether all ffmpeg text-sub encoders can handle
> > those chars - which could be verified of course.
> >
> > But what remains is the question about the effect on end devices
> > which are consuming that output.
> >
> > Finally, those chars are a pest. I'm using them myself for a
> > specific use case, but when you don't know they are there, it can
> > drive you totally mad, eventually even thinking your system or
> > software is faulty.
> >
> > Example:
> >
> > Open your patch file [2/2] and search for the string
> > "123456\NAscending". You can see the string in two lines, but search
> > will only find one of them.
> >
> > Or just look at the two lines directly. They are preceded by + and -
> > even though both appear identical.
> >
> >
> > So, this also needs consideration of the consequences, like how
> > many developers (inside and outside of ffmpeg) this would be driving
> > nuts over the years and make them start hating ffmpeg for doing so
> > once they've found out.
>
> As I really hate how many devs on this ML keep saying 'no' to
> submitted
> code without having a better suggestion, assuming that this is all
> that
> it takes, I don't want to assimilate in this regard.
>
> Hence I want to propose the following solution:
>
> First of all, the existing code in ff_ass_bprint_text_event() is
> totally
> wrong already. Not only with regard to the backslash escaping (as you
> have already pointed out), but also the curly brace escaping is
> invalid.
> There is no curly-brace escaping in ASS either.
>
> In fact it is impossible with ASS to display an opening curly brace
> followed
> by a closing curly brace at a subsequent position (each one alone may
> work
> depending on implementation).
>
> If it was about ASS alone, we might just drop those braces, so we
> could
> at least avoid the text in-between from being hidden (when outputting
> ASS), but ASS is also the internal ("uncompressed/raw") subtitle
> format
> in ffmpeg that is used for conversion (and subtitle filtering).
> So it would be hard-to-sell when curly braces would get lost when
> converting from one text-sub format to another with none of them
> even being ASS.
>
> What we need is to stop creating invalid ASS and at the same time
> ensure proper conversion of curly braces. How? We substitute them!
>
> And still, UTF-8 can come to the rescue. There are two suitable
> candidates for that:
>
> SMALL LEFT CURLY BRACKET (U+FE5B, Ps): ﹛
> SMALL RIGHT CURLY BRACKET (U+FE5C, Pe): ﹜
> FULLWIDTH LEFT CURLY BRACKET (U+FF5B, Ps): ｛
> FULLWIDTH RIGHT CURLY BRACKET (U+FF5D, Pe): ｝
>
> Substitution of curly braces with one of those will prevent ASS from
> treating
> any possible subtitle content as override code.
>
> What remains to be handled now is the backslash case. Now that we can
> be sure
> that we are never inside a
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, February 4, 2022 6:34 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> Soft
> > Works
> > Sent: Friday, February 4, 2022 2:58 AM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}:
> fix
> > handling of backslashes
> >
> >
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Oneric
> > > Sent: Friday, February 4, 2022 2:01 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 Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote:
[..]
> Needless to say that we will of course change the substituted curly
> braces
> back to the regular ones at the encoding side for all but ASS.
> Remains the question what to do when encoding to ASS: We can either
> keep the alternate brace characters or just remove them (or maybe
> replace
> with square brackets).
>
> I'm not sure about that last point
The reason why I'm saying this is because we can't be sure that the
font being used at the target would include glyphs for those alternate
curly braces, and when it doesn't it would typically cause ugly
replacement glyphs (usually a square outline) to be rendered.
But to set the record straight: we're not talking about a degradation
to current here. Right now this doesn't work at all (text inside
curly braces being invisible)
sw
___
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of Soft
> Works
> Sent: Friday, February 4, 2022 2:58 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix
> handling of backslashes
>
>
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Oneric
> > Sent: Friday, February 4, 2022 2:01 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 Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote:
> > > I think when you inject that word-joiner as a workaround for ass
> > > parsing, you'll also need to make sure that it gets removed
> > > when encoding to other formats.
> >
> > There's no way of knowing whether the word-joiner comes from
> > a conversion performed by ffmpeg in the past or already existed
> > in the original source.
>
> That might be true, but I think it's valid to say that such characters
> are very unusual "original" subtitle sources and that's why I don't
> think it's a good idea for ffmpeg to start injecting them.
>
> Subtitle implementations are often rather minimal, especially in
> hardware devices and might not always cover the full range of
> UTF-8 specifics.
>
> > However, the wordjoiner does not alter the visually appearance and
> > is unlikely to change line-breaking properties; that's why I chose
> > a word-joiner. Therefore I don't think removing (only) the inserted
> > word-joiners is possible,
>
> Why not? As it seems to be required for ASS encoding only, all other
> output formats should remain unaffected.
>
> > but also not necessary.
>
> I'm not sure whether all ffmpeg text-sub encoders can handle
> those chars - which could be verified of course.
>
> But what remains is the question about the effect on end devices
> which are consuming that output.
>
> Finally, those chars are a pest. I'm using them myself for a
> specific use case, but when you don't know they are there, it can
> drive you totally mad, eventually even thinking your system or
> software is faulty.
>
> Example:
>
> Open your patch file [2/2] and search for the string
> "123456\NAscending". You can see the string in two lines, but search
> will only find one of them.
>
> Or just look at the two lines directly. They are preceded by + and -
> even though both appear identical.
>
>
> So, this also needs consideration of the consequences, like how
> many developers (inside and outside of ffmpeg) this would be driving
> nuts over the years and make them start hating ffmpeg for doing so
> once they've found out.
As I really hate how many devs on this ML keep saying 'no' to submitted
code without having a better suggestion, assuming that this is all that
it takes, I don't want to assimilate in this regard.
Hence I want to propose the following solution:
First of all, the existing code in ff_ass_bprint_text_event() is totally
wrong already. Not only with regard to the backslash escaping (as you
have already pointed out), but also the curly brace escaping is invalid.
There is no curly-brace escaping in ASS either.
In fact it is impossible with ASS to display an opening curly brace followed
by a closing curly brace at a subsequent position (each one alone may work
depending on implementation).
If it was about ASS alone, we might just drop those braces, so we could
at least avoid the text in-between from being hidden (when outputting
ASS), but ASS is also the internal ("uncompressed/raw") subtitle format
in ffmpeg that is used for conversion (and subtitle filtering).
So it would be hard-to-sell when curly braces would get lost when
converting from one text-sub format to another with none of them
even being ASS.
What we need is to stop creating invalid ASS and at the same time
ensure proper conversion of curly braces. How? We substitute them!
And still, UTF-8 can come to the rescue. There are two suitable
candidates for that:
SMALL LEFT CURLY BRACKET (U+FE5B, Ps): ﹛
SMALL RIGHT CURLY BRACKET (U+FE5C, Pe): ﹜
FULLWIDTH LEFT CURLY BRACKET (U+FF5B, Ps): ｛
FULLWIDTH RIGHT CURLY BRACKET (U+FF5D, Pe): ｝
Substitution of curly braces with one of those will prevent ASS from treating
any possible subtitle content as override code.
What remains to be handled now is the backslash case. Now that we can be sure
that we are never inside a sequence that ASS would consider an override code,
only 3 cases are remaining where the backslash has a meaning in ASS dialog
text: '\n', '\N' and '\h'.
We can simply escape those sequences by inserting a (no-op) override code
between the backslash and the char. Suitable for this is: {\r}
This code resets inline styles, but since we are coming from plain text subs
in ff_ass_bprint_text_event(), we know that we don't have any inline styles
and it's a no-op to reset the style.
Needless to say that we will of course c
Re: [FFmpeg-devel] [PATCH 1/2] avformat/matroskadec: Fix infinite loop with bz decompression
Michael Niedermayer:
> Fixes: Infinite loop
> Fixes:
> 43932/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6175167573786624
>
> 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 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d165f6ab90..5a9acfb247 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1742,7 +1742,7 @@ static int matroska_decode_buffer(uint8_t **buf, int
> *buf_size,
> case MATROSKA_TRACK_ENCODING_COMP_BZLIB:
> {
> bz_stream bzstream = { 0 };
> -if (BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK)
> +if (!pkt_size || BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK)
> return -1;
> bzstream.next_in = data;
> bzstream.avail_in = isize;
I see nothing in the zlib-API manual that would preclude this from
happening with zlib, too, so it should be checked there, too.
LGTM apart from that.
- Andreas
___
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".
Re: [FFmpeg-devel] [PATCH 2/2] libavformat/mov: fix udta reading in trak box
Ping?
On Jan 28, 2022, 11:24 AM +0800, Wang Chuan , wrote:
> if we are reading udta in trak box, the data should go to metadata
> of current stream.
>
> Signed-off-by: Wang Chuan
> ---
> libavformat/mov.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 1437d160f8..cb983defb3 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -522,7 +522,10 @@ retry:
> str[str_size] = 0;
> }
> c->fc->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
> - av_dict_set(&c->fc->metadata, key, str, 0);
> + if (c->trak_index != -1)
> + av_dict_set(&c->fc->streams[c->trak_index]->metadata, key,
> str, 0);
> + else
> + av_dict_set(&c->fc->metadata, key, str, 0);
> if (*language && strcmp(language, "und")) {
> snprintf(key2, sizeof(key2), "%s-%s", key, language);
> av_dict_set(&c->fc->metadata, key2, str, 0);
> --
> 2.29.2
>
___
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".
Re: [FFmpeg-devel] [PATCH] avformat/rtpdec_rfc4175: fix interlace format
On Wed, Feb 02, 2022 at 03:45:10PM -0500, Patrick Keroulas wrote:
> In previous state, a new frame was allocated on each timestamp step,
> i.e. each frame/field transition. However, for interlace, a new frame
> should be allocated on 1st field, completed with the 2nd and finally
> freed.
>
> This commit fixes the frame allocation and the detection of missing RTP
> markers.
>
> Signed-off-by: Patrick Keroulas
> ---
> libavformat/rtpdec_rfc4175.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/rtpdec_rfc4175.c b/libavformat/rtpdec_rfc4175.c
> index 8e73c07838..83abe499f8 100644
> --- a/libavformat/rtpdec_rfc4175.c
> +++ b/libavformat/rtpdec_rfc4175.c
> @@ -234,20 +234,21 @@ static int rfc4175_handle_packet(AVFormatContext *ctx,
> PayloadContext *data,
> uint8_t *dest;
>
> if (*timestamp != data->timestamp) {
> -if (data->frame) {
> +if (data->frame && (!data->interlaced || data->field)) {
> /*
> - * if we're here, it means that two RTP packets didn't have the
> - * same timestamp, which is a sign that they were packets from
> two
> - * different frames, but we didn't get the flag RTP_FLAG_MARKER
> on
> - * the first one of these frames (last packet of a frame).
> - * Finalize the previous frame anyway by filling the AVPacket.
> + * if we're here, it means that we missed the cue to return
> + * the previous AVPacket, that cue being the RTP_FLAG_MARKER
> + * in the last packet of either the previous frame (progressive)
> + * or the previous second field (interlace). Let's finalize the
> + * previous frame (or pair of fields) anyway by filling the
> AVPacket.
> */
> av_log(ctx, AV_LOG_ERROR, "Missed previous RTP Marker\n");
> missed_last_packet = 1;
> rfc4175_finalize_packet(data, pkt, st->index);
> }
>
> -data->frame = av_malloc(data->frame_size);
> +if (!data->frame)
> +data->frame = av_malloc(data->frame_size);
>
> data->timestamp = *timestamp;
LGTM
>
> --
> 2.25.1
>
--
Thanks,
Limin Wang
___
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Oneric
> Sent: Friday, February 4, 2022 2:01 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 Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote:
> > I think when you inject that word-joiner as a workaround for ass
> > parsing, you'll also need to make sure that it gets removed
> > when encoding to other formats.
>
> There's no way of knowing whether the word-joiner comes from
> a conversion performed by ffmpeg in the past or already existed
> in the original source.
That might be true, but I think it's valid to say that such characters
are very unusual "original" subtitle sources and that's why I don't
think it's a good idea for ffmpeg to start injecting them.
Subtitle implementations are often rather minimal, especially in
hardware devices and might not always cover the full range of
UTF-8 specifics.
> However, the wordjoiner does not alter the visually appearance and
> is unlikely to change line-breaking properties; that's why I chose
> a word-joiner. Therefore I don't think removing (only) the inserted
> word-joiners is possible,
Why not? As it seems to be required for ASS encoding only, all other
output formats should remain unaffected.
> but also not necessary.
I'm not sure whether all ffmpeg text-sub encoders can handle
those chars - which could be verified of course.
But what remains is the question about the effect on end devices
which are consuming that output.
Finally, those chars are a pest. I'm using them myself for a
specific use case, but when you don't know they are there, it can
drive you totally mad, eventually even thinking your system or
software is faulty.
Example:
Open your patch file [2/2] and search for the string
"123456\NAscending". You can see the string in two lines, but search
will only find one of them.
Or just look at the two lines directly. They are preceded by + and -
even though both appear identical.
So, this also needs consideration of the consequences, like how
many developers (inside and outside of ffmpeg) this would be driving
nuts over the years and make them start hating ffmpeg for doing so
once they've found out.
softworkz
___
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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
Oneric: > On Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote: >> I think when you inject that word-joiner as a workaround for ass >> parsing, you'll also need to make sure that it gets removed >> when encoding to other formats. > > There's no way of knowing whether the word-joiner comes from > a conversion performed by ffmpeg in the past or already existed > in the original source. > However, the wordjoiner does not alter the visually appearance and > is unlikely to change line-breaking properties; that's why I chose > a word-joiner. Therefore I don't think removing (only) the inserted > word-joiners is possible, but also not necessary. > > Also, was the wrong \\ recollapsed into a single \ somehwere? If yes, > then this code can be dropped as well (but I don't know where it is). > > My biggest concern with this is the unconditional assumption of UTF-8 in > ff_ass_bprint_text_event? Is there a way to improve on this or does ffmpeg > convert all text to UTF-8 before it's passed to this function? All text-based subtitles are supposed to be UTF-8 when they reach the decoder; if it isn't, the user has to set the appropriate -sub_charenc and -sub_charenc_mode. - Andreas ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
On Thu, Feb 03, 2022 at 20:51:16 +, Soft Works wrote: > I think when you inject that word-joiner as a workaround for ass > parsing, you'll also need to make sure that it gets removed > when encoding to other formats. There's no way of knowing whether the word-joiner comes from a conversion performed by ffmpeg in the past or already existed in the original source. However, the wordjoiner does not alter the visually appearance and is unlikely to change line-breaking properties; that's why I chose a word-joiner. Therefore I don't think removing (only) the inserted word-joiners is possible, but also not necessary. Also, was the wrong \\ recollapsed into a single \ somehwere? If yes, then this code can be dropped as well (but I don't know where it is). My biggest concern with this is the unconditional assumption of UTF-8 in ff_ass_bprint_text_event? Is there a way to improve on this or does ffmpeg convert all text to UTF-8 before it's passed to this function? ___ 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".
[FFmpeg-devel] [PATCH 2/2] avformat/utils: Fix invalid NULL pointer operation in ff_parse_key_value()
Fixes: pointer index expression with base 0x overflowed to
0x
Fixes:
44012/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-5670607746891776
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/utils.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 940703e87d..cee86ae87b 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1244,7 +1244,7 @@ void ff_parse_key_value(const char *str,
ff_parse_key_val_cb callback_get_buf,
key_len = ptr - key;
callback_get_buf(context, key, key_len, &dest, &dest_len);
-dest_end = dest + dest_len - 1;
+dest_end = dest ? dest + dest_len - 1 : NULL;
if (*ptr == '\"') {
ptr++;
--
2.17.1
___
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".
[FFmpeg-devel] [PATCH 1/2] avformat/matroskadec: Fix infinite loop with bz decompression
Fixes: Infinite loop
Fixes:
43932/clusterfuzz-testcase-minimized-ffmpeg_dem_MATROSKA_fuzzer-6175167573786624
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 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index d165f6ab90..5a9acfb247 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -1742,7 +1742,7 @@ static int matroska_decode_buffer(uint8_t **buf, int
*buf_size,
case MATROSKA_TRACK_ENCODING_COMP_BZLIB:
{
bz_stream bzstream = { 0 };
-if (BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK)
+if (!pkt_size || BZ2_bzDecompressInit(&bzstream, 0, 0) != BZ_OK)
return -1;
bzstream.next_in = data;
bzstream.avail_in = isize;
--
2.17.1
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles
> -Original Message- > From: ffmpeg-devel On Behalf Of > Scott Theisen > Sent: Friday, February 4, 2022 12:15 AM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect > yellow appearance of dvd subtitles > > On 2/3/22 17:57, Soft Works wrote: > > My suspicion is that 0x00 was written assuming RGBA order > instead > > of ARGB. > > You are missing a byte for either RGBA or ARGB. RGBA would be cyan. > I think using yellow for debugging purposes is more likely, i.e. it Something made me think that it might have come from a byte ordering issue when I had debugged an example, but I don't remember exactly. Probably you are just right about it, but only Fabrice might be able to tell for sure.. > However, it shouldn't > have been committed like that, if that was the reason. No matter the reason, I don't think there's any doubt that it's wrong? softworkz ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles
On 2/3/22 17:57, Soft Works wrote: My suspicion is that 0x00 was written assuming RGBA order instead of ARGB. You are missing a byte for either RGBA or ARGB. RGBA would be cyan. I'm pretty sure that it's a mistake and it hasn't been an intentional choice, because even when you would consider a yellow color to for whatever reason, it wouldn't have been exactly this yellow (#ff0), because its lightness/saturation values are not in a range of what is suitable for colored subtitles. I think using yellow for debugging purposes is more likely, i.e. it is obvious if the pallet was missing/not detected. However, it shouldn't have been committed like that, if that was the reason. Regards, Scott ___ 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".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Scott Theisen
> Sent: Thursday, February 3, 2022 11:17 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect
> yellow appearance of dvd subtitles
>
> On 2/3/22 17:10, Soft Works wrote:
> >
> >> -Original Message-
> >> From: ffmpegagent
> >> Sent: Tuesday, January 4, 2022 3:19 AM
> >> To: ffmpeg-devel@ffmpeg.org
> >> Cc: softworkz ; softworkz
> >>
> >> Subject: [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance
> of
> >> dvd subtitles
> >>
> >> From: softworkz
> >>
> >> The guess_palette() implementation is questionable in itself
> >> as its results don't match those from other DVD subtitle decoders.
> >>
> >> This commit starts cleanup by fixing an obvious bug which has made
> >> certain DVD subs appear yellow instead of white or grey for more
> than
> >> 10 years..
> >>
> >> Signed-off-by: softworkz
> >> ---
> >> avcodec/dvdsubdec: fix incorrect yellow appearance of dvd
> >> subtitles
> >>
> >> Fixes an age-old bug in decoding DVD subtitles.
> >>
> >> Ever wondered why certain DVD subtitles are shown in yellow
> color
> >> when
> >> ffmpeg is involved...
> >>
> >> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> >> ffstaging-16%2Fsoftworkz%2Fpatch_dvdsubdec_fix-v1
> >> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> >> ffstaging-16/softworkz/patch_dvdsubdec_fix-v1
> >> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/16
> >>
> >> libavcodec/dvdsubdec.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
> >> index 52259f0730..a3fdb535a5 100644
> >> --- a/libavcodec/dvdsubdec.c
> >> +++ b/libavcodec/dvdsubdec.c
> >> @@ -400,7 +400,7 @@ static int decode_dvd_subtitles(DVDSubContext
> >> *ctx, AVSubtitle *sub_header,
> >> } else {
> >> sub_header->rects[0]->nb_colors = 4;
> >> guess_palette(ctx, (uint32_t*)sub_header-
> >>> rects[0]->data[1],
> >> - 0x00);
> >> + 0xff);
> >> }
> >> sub_header->rects[0]->x = x1;
> >> sub_header->rects[0]->y = y1;
> >>
> >> base-commit: 573b6b8a607398c5f34108efda9c29d41c5727ff
> >> --
> >> ffmpeg-codebot
> > Ping. (no maintainer seems to be registered for this)
>
> MythTV has used this fix since 2010-06-04. See
> https://github.com/ulmus-
> scott/FFmpeg/commit/e2b1a6ee63c01ac9c82d24e2e6cfffeb2bfc
>
> libavcodec/dvdsubdec.c: default to white instead of yellow
>
> from Improved display of DVD subtitles in containers other than the
> original.
> https://github.com/MythTV/mythtv/commit/2510a0821ea4453eb9b34dd96e68ff
> 0441459d0b
> references: https://code.mythtv.org/trac/ticket/8222
Thanks for the references. I have compared the ffmpeg output
with a range of (non-ffmpeg-based) players including VLC,
an example where I had a screen photo from a hardware player
and two subtitle editing tools.
None of those showed them yellow.
> For whatever strange reason, ffmpeg has always used yellow:
> https://github.com/FFmpeg/FFmpeg/commit/240c1657dcd45adc0e63ef947b9209
> 19071ec1f7
My suspicion is that 0x00 was written assuming RGBA order instead
of ARGB.
I'm pretty sure that it's a mistake and it hasn't been an intentional
choice, because even when you would consider a yellow color to for
whatever reason, it wouldn't have been exactly this yellow (#ff0),
because its lightness/saturation values are not in a range of what
is suitable for colored subtitles.
softworkz
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles
On 2/3/22 17:10, Soft Works wrote:
-Original Message-
From: ffmpegagent
Sent: Tuesday, January 4, 2022 3:19 AM
To: ffmpeg-devel@ffmpeg.org
Cc: softworkz ; softworkz
Subject: [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of
dvd subtitles
From: softworkz
The guess_palette() implementation is questionable in itself
as its results don't match those from other DVD subtitle decoders.
This commit starts cleanup by fixing an obvious bug which has made
certain DVD subs appear yellow instead of white or grey for more than
10 years..
Signed-off-by: softworkz
---
avcodec/dvdsubdec: fix incorrect yellow appearance of dvd
subtitles
Fixes an age-old bug in decoding DVD subtitles.
Ever wondered why certain DVD subtitles are shown in yellow color
when
ffmpeg is involved...
Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
ffstaging-16%2Fsoftworkz%2Fpatch_dvdsubdec_fix-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
ffstaging-16/softworkz/patch_dvdsubdec_fix-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/16
libavcodec/dvdsubdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 52259f0730..a3fdb535a5 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -400,7 +400,7 @@ static int decode_dvd_subtitles(DVDSubContext
*ctx, AVSubtitle *sub_header,
} else {
sub_header->rects[0]->nb_colors = 4;
guess_palette(ctx, (uint32_t*)sub_header-
rects[0]->data[1],
- 0x00);
+ 0xff);
}
sub_header->rects[0]->x = x1;
sub_header->rects[0]->y = y1;
base-commit: 573b6b8a607398c5f34108efda9c29d41c5727ff
--
ffmpeg-codebot
Ping. (no maintainer seems to be registered for this)
MythTV has used this fix since 2010-06-04. See
https://github.com/ulmus-scott/FFmpeg/commit/e2b1a6ee63c01ac9c82d24e2e6cfffeb2bfc
libavcodec/dvdsubdec.c: default to white instead of yellow
from Improved display of DVD subtitles in containers other than the
original.
https://github.com/MythTV/mythtv/commit/2510a0821ea4453eb9b34dd96e68ff0441459d0b
references: https://code.mythtv.org/trac/ticket/8222
For whatever strange reason, ffmpeg has always used yellow:
https://github.com/FFmpeg/FFmpeg/commit/240c1657dcd45adc0e63ef947b920919071ec1f7
___
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".
Re: [FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles
> -Original Message-
> From: ffmpegagent
> Sent: Tuesday, January 4, 2022 3:19 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softworkz ; softworkz
>
> Subject: [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of
> dvd subtitles
>
> From: softworkz
>
> The guess_palette() implementation is questionable in itself
> as its results don't match those from other DVD subtitle decoders.
>
> This commit starts cleanup by fixing an obvious bug which has made
> certain DVD subs appear yellow instead of white or grey for more than
> 10 years..
>
> Signed-off-by: softworkz
> ---
> avcodec/dvdsubdec: fix incorrect yellow appearance of dvd
> subtitles
>
> Fixes an age-old bug in decoding DVD subtitles.
>
> Ever wondered why certain DVD subtitles are shown in yellow color
> when
> ffmpeg is involved...
>
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-16%2Fsoftworkz%2Fpatch_dvdsubdec_fix-v1
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> ffstaging-16/softworkz/patch_dvdsubdec_fix-v1
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/16
>
> libavcodec/dvdsubdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
> index 52259f0730..a3fdb535a5 100644
> --- a/libavcodec/dvdsubdec.c
> +++ b/libavcodec/dvdsubdec.c
> @@ -400,7 +400,7 @@ static int decode_dvd_subtitles(DVDSubContext
> *ctx, AVSubtitle *sub_header,
> } else {
> sub_header->rects[0]->nb_colors = 4;
> guess_palette(ctx, (uint32_t*)sub_header-
> >rects[0]->data[1],
> - 0x00);
> + 0xff);
> }
> sub_header->rects[0]->x = x1;
> sub_header->rects[0]->y = y1;
>
> base-commit: 573b6b8a607398c5f34108efda9c29d41c5727ff
> --
> ffmpeg-codebot
Ping. (no maintainer seems to be registered for this)
___
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".
Re: [FFmpeg-devel] [PATCH v2 0/2] avcodec/dvbsubdec, dvdsubdec: don't dump images to disk based on DEBUG define
> -Original Message-
> From: ffmpegagent
> Sent: Monday, January 10, 2022 8:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Hendrik Leppkes ; Soft Works
> ; Marton Balint ; softworkz
>
> Subject: [PATCH v2 0/2] avcodec/dvbsubdec,dvdsubdec: don't dump images
> to disk based on DEBUG define
>
> It's annoying and unexpected, but still useful at times (as I've
> realized
> just recently).
>
> This is a follow-up to the earlier submission here:
> https://www.mail-archive.com/ffmpeg-devel@ffmpeg.org/msg128080.html
>
> There has been a comment from Anton, questioning whether the dump-
> feature is
> useful. Meanwhile I came to the conclusion that it can be useful in-
> fact. It
> just shouldn't happen automatically when DEBUG is defined. That's what
> these
> patches do.
>
> I also added fixes for the fopen() call.
>
> softworkz (2):
> avcodec/dvdsubdec,dvbsubdec: don't dump images to disk based on
> DEBUG
> define
> avcodec/dvdsubdec,dvbsubdec: fix writing ppm
>
> libavcodec/dvbsubdec.c | 20 +---
> libavcodec/dvdsubdec.c | 11 ---
> 2 files changed, 21 insertions(+), 10 deletions(-)
>
>
> base-commit: 6c4074e4234edacfb3f37184fd68771df3cb2b7f
> Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-17%2Fsoftworkz%2Fsubmit_dvb_subs-v2
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> ffstaging-17/softworkz/submit_dvb_subs-v2
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/17
>
> Range-diff vs v1:
>
> 1: 6ca8905c3d ! 1: 2f12ac7f1f avcodec/dvbsubdec: don't dump images
> to disk based on DEBUG define
> @@ Metadata
> Author: softworkz
>
>## Commit message ##
> -avcodec/dvbsubdec: don't dump images to disk based on DEBUG
> define
> +avcodec/dvdsubdec,dvbsubdec: don't dump images to disk based
> on DEBUG define
>
> It's been a regular annoyance.
> Introduce a debug-only parameter for this.
> @@ libavcodec/dvbsubdec.c: static const AVOption options[] = {
>{NULL}
>};
>static const AVClass dvbsubdec_class = {
> +
> + ## libavcodec/dvdsubdec.c ##
> +@@ libavcodec/dvdsubdec.c: typedef struct DVDSubContext
> + uint8_t used_color[256];
> + #ifdef DEBUG
> + int sub_id;
> ++ int dump_imgs;
> + #endif
> + } DVDSubContext;
> +
> +@@ libavcodec/dvdsubdec.c: static int
> dvdsub_decode(AVCodecContext *avctx,
> + ff_dlog(NULL, "start=%d ms end =%d ms\n",
> + sub->start_display_time,
> + sub->end_display_time);
> +-ppm_save(ppm_name, sub->rects[0]->data[0],
> +- sub->rects[0]->w, sub->rects[0]->h, (uint32_t*)
> sub->rects[0]->data[1]);
> ++if (ctx->dump_imgs)
> ++ppm_save(ppm_name, sub->rects[0]->data[0],
> ++ sub->rects[0]->w, sub->rects[0]->h,
> (uint32_t*) sub->rects[0]->data[1]);
> + }
> + #endif
> +
> +@@ libavcodec/dvdsubdec.c: static const AVOption options[] = {
> + { "palette", "set the global palette", OFFSET(palette_str),
> AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD },
> + { "ifo_palette", "obtain the global palette from .IFO
> file", OFFSET(ifo_str), AV_OPT_TYPE_STRING, { .str = NULL }, 0, 0, SD
> },
> + { "forced_subs_only", "Only show forced subtitles",
> OFFSET(forced_subs_only), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, SD},
> ++#ifdef DEBUG
> ++{ "dump_imgs", "Dump subtitle images to disk",
> OFFSET(dump_imgs), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, SD},
> ++#endif
> + { NULL }
> + };
> + static const AVClass dvdsub_class = {
> 2: 8da6e4ab17 ! 2: 0cd2c77f31 avcodec/dvbsubdec: fix writing ppm
> @@ Metadata
> Author: softworkz
>
>## Commit message ##
> -avcodec/dvbsubdec: fix writing ppm
> +avcodec/dvdsubdec,dvbsubdec: fix writing ppm
>
> fopen needs (b)inary mode
>
> @@ libavcodec/dvbsubdec.c: static void png_save(DVBSubContext
> *ctx, const char *fil
>if (!f) {
>perror(fname2);
>return;
> +
> + ## libavcodec/dvdsubdec.c ##
> +@@ libavcodec/dvdsubdec.c: static void ppm_save(const char
> *filename, uint8_t *bitmap, int w, int h,
> + int back[3] = {0, 255, 0}; /* green background */
> + FILE *f;
> +
> +-f = fopen(filename, "w");
> ++f = fopen(filename, "wb");
> + if (!f) {
> + perror(filename);
> + return;
> 3: 9186ff48ec < -: -- avcodec/dvdsubdec: don't dump images
> to disk based on DEBUG define
> 4: 341474e338 < -: -- avcodec/dvdsubdec: fix writing ppm
>
> --
> ffmpeg-codebot
Ping. (this v2 has squashed the commits as requested)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listin
Re: [FFmpeg-devel] [PATCH] libavutil/tests/md5: Avoid warnings
> -Original Message-
> From: ffmpeg-devel On Behalf Of Carl
> Eugen Hoyos
> Sent: Sunday, January 23, 2022 12:23 AM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH] libavutil/tests/md5: Avoid
> warnings
>
> Am Fr., 21. Jan. 2022 um 02:18 Uhr schrieb softworkz
> :
> >
> > From: softworkz
> >
> > Those are always showing up on Patchwork
> > when FATE tests are failing, covering
> > some possibly more useful information.
> >
> > Signed-off-by: softworkz
> > ---
> > libavutil/tests/md5: Avoid warnings
> >
> > Those are always showing up on Patchwork when FATE tests are
> failing,
> > covering some possibly more useful information.
> >
> > Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-
> ffstaging-20%2Fsoftworkz%2Fsubmit_md5-v1
> > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> ffstaging-20/softworkz/submit_md5-v1
> > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/20
> >
> > libavutil/tests/md5.c | 6 +-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavutil/tests/md5.c b/libavutil/tests/md5.c
> > index 42e4538e0a..1f27c40987 100644
> > --- a/libavutil/tests/md5.c
> > +++ b/libavutil/tests/md5.c
> > @@ -33,8 +33,12 @@ int main(void)
> > {
> > uint8_t md5val[16];
> > int i;
> > +
> > +#if defined(__clang__) && defined(__clang_major__) &&
> __clang_major__ < 4
> > volatile uint8_t in[1000]; // volatile to workaround
> http://llvm.org/bugs/show_bug.cgi?id=20849
> > -// FIXME remove volatile once it has been fixed and all fate
> clients are updated
>
> I wonder if the volatile shouldn't just be removed after eight years.
>
> Carl Eugen
So, shall I submit another version that simply removes 'volatile'?
softworkz
___
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".
[FFmpeg-devel] [PATCH] Update ReadMe.md for PR submission and reference Developer Documentation
From: softworkz Signed-off-by: softworkz --- Update ReadMe.md for PR submission and reference Developer Documentation . Published-As: https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-22%2Fsoftworkz%2Fpatch-2-v1 Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-22/softworkz/patch-2-v1 Pull-Request: https://github.com/ffstaging/FFmpeg/pull/22 README.md | 18 -- 1 file changed, 16 insertions(+), 2 deletions(-) diff --git a/README.md b/README.md index f8c23f2870..07f717a4f9 100644 --- a/README.md +++ b/README.md @@ -41,6 +41,20 @@ GPL. Please refer to the LICENSE file for detailed information. ## Contributing +### Mailing List + Patches should be submitted to the ffmpeg-devel mailing list using -`git format-patch` or `git send-email`. Github pull requests should be -avoided because they are not part of our review process and will be ignored. +`git format-patch` or `git send-email` as described in the +[Developer Documentation](https://www.ffmpeg.org/developer.html#Contributing). + +### Pull Requests + +There is a new experimental way that allows submitting Pull Requests +and having them forwarded to the ffmpeg Mailing List. + +Please submit your Pull Requests here: **https://github.com/ffstaging/FFmpeg**. + +Then, follow the instructions from the automatic CodeBot response. +Besides the submission procedure, the +[Developer Documentation](https://www.ffmpeg.org/developer.html#Contributing) +applies in the same way like when submitting to the ML directly. base-commit: e1a14479a81f5366b95df543992a7fe637cf2dde -- ffmpeg-codebot ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/{ass, webvttdec}: fix handling of backslashes
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Oneric
> Sent: Thursday, February 3, 2022 3:11 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 Wed, Feb 02, 2022 at 22:44:18 +, Soft Works wrote:
> > > Sent: Wednesday, February 2, 2022 11:19 PM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > >
> > > [claims about git and smtp: part 1]
> > >
> >
> > [claims about git and smtp: part 2]
> >
> I’ll ignore all further offtopic messages here.
Aha, suddenly it's off-topic, but ok.
> please actually discuss the content of the patches in this thread.
I think when you inject that word-joiner as a workaround for ass
parsing, you'll also need to make sure that it gets removed
when encoding to other formats.
softworkz
___
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".
[FFmpeg-devel] [PATCH 2/2] replace av_get_media_type_string() with av_media_type_get_string()
printf %s with a null pointer is undefined behavior.
---
doc/examples/demuxing_decoding.c | 10 +-
doc/examples/extract_mvs.c | 4 ++--
fftools/cmdutils.c | 7 +++
fftools/cmdutils.h | 2 --
fftools/ffmpeg.c | 14 +++---
fftools/ffmpeg_opt.c | 2 +-
fftools/ffplay.c | 4 ++--
fftools/ffprobe.c| 13 +++--
libavcodec/avcodec.c | 2 +-
libavcodec/tests/avcodec.c | 10 ++
libavdevice/dshow.c | 4 ++--
libavfilter/avfilter.c | 4 ++--
libavfilter/avfiltergraph.c | 4 ++--
libavfilter/src_movie.c | 6 +++---
libavformat/avienc.c | 2 +-
libavformat/flvenc.c | 2 +-
libavformat/framehash.c | 2 +-
libavformat/mov.c| 2 +-
libavformat/mpegenc.c| 2 +-
libavformat/mpegts.c | 2 +-
libavformat/mxfdec.c | 2 +-
libavformat/segment.c| 2 +-
libavformat/tee.c| 2 +-
libavformat/uncodedframecrcenc.c | 4 +---
24 files changed, 45 insertions(+), 63 deletions(-)
diff --git a/doc/examples/demuxing_decoding.c b/doc/examples/demuxing_decoding.c
index 8520d5b660..670f08779d 100644
--- a/doc/examples/demuxing_decoding.c
+++ b/doc/examples/demuxing_decoding.c
@@ -155,7 +155,7 @@ static int open_codec_context(int *stream_idx,
ret = av_find_best_stream(fmt_ctx, type, -1, -1, NULL, 0);
if (ret < 0) {
fprintf(stderr, "Could not find %s stream in input file '%s'\n",
-av_get_media_type_string(type), src_filename);
+av_media_type_get_string(type), src_filename);
return ret;
} else {
stream_index = ret;
@@ -165,7 +165,7 @@ static int open_codec_context(int *stream_idx,
dec = avcodec_find_decoder(st->codecpar->codec_id);
if (!dec) {
fprintf(stderr, "Failed to find %s codec\n",
-av_get_media_type_string(type));
+av_media_type_get_string(type));
return AVERROR(EINVAL);
}
@@ -173,21 +173,21 @@ static int open_codec_context(int *stream_idx,
*dec_ctx = avcodec_alloc_context3(dec);
if (!*dec_ctx) {
fprintf(stderr, "Failed to allocate the %s codec context\n",
-av_get_media_type_string(type));
+av_media_type_get_string(type));
return AVERROR(ENOMEM);
}
/* Copy codec parameters from input stream to output codec context */
if ((ret = avcodec_parameters_to_context(*dec_ctx, st->codecpar)) < 0)
{
fprintf(stderr, "Failed to copy %s codec parameters to decoder
context\n",
-av_get_media_type_string(type));
+av_media_type_get_string(type));
return ret;
}
/* Init the decoders */
if ((ret = avcodec_open2(*dec_ctx, dec, NULL)) < 0) {
fprintf(stderr, "Failed to open %s codec\n",
-av_get_media_type_string(type));
+av_media_type_get_string(type));
return ret;
}
*stream_idx = stream_index;
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
index cc1311da91..2fb5517708 100644
--- a/doc/examples/extract_mvs.c
+++ b/doc/examples/extract_mvs.c
@@ -85,7 +85,7 @@ static int open_codec_context(AVFormatContext *fmt_ctx, enum
AVMediaType type)
ret = av_find_best_stream(fmt_ctx, type, -1, -1, &dec, 0);
if (ret < 0) {
fprintf(stderr, "Could not find %s stream in input file '%s'\n",
-av_get_media_type_string(type), src_filename);
+av_media_type_get_string(type), src_filename);
return ret;
} else {
int stream_idx = ret;
@@ -109,7 +109,7 @@ static int open_codec_context(AVFormatContext *fmt_ctx,
enum AVMediaType type)
av_dict_free(&opts);
if (ret < 0) {
fprintf(stderr, "Failed to open %s codec\n",
-av_get_media_type_string(type));
+av_media_type_get_string(type));
return ret;
}
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 4b50e15eef..4504d2711c 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1961,7 +1961,7 @@ static void show_help_filter(const char *name)
count = avfilter_filter_pad_count(f, 0);
for (i = 0; i < count; i++) {
printf(" #%d: %s (%s)\n", i, avfilter_pad_get_name(f->inputs, i),
- media_type_string(avfilter_pad_get_type(f->inputs, i)));
+ av_media_type_get_string(avfilter_pad_get_type(f->inputs, i)));
}
if (f->flags & AVFILTER_FLAG_DYNAMIC_INPUTS)
printf("dynamic (depending on the options)\n");
@@ -1972,7 +1972,7 @@ static void show_help_filter(const char *name)
count = avfilter_filter_pad_count(f,
[FFmpeg-devel] [PATCH 1/2] libavutil: create av_media_type_get_string()
This deprecates av_get_media_type_string() which does return NULL.
printf %s with a null pointer is undefined behavior
This also matches behavior with avcodec_get_name() which never returns NULL,
instead it returns "unknown_codec".
---
doc/APIchanges | 3 +++
libavutil/avutil.h | 7 +++
libavutil/utils.c | 13 +
3 files changed, 23 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 315a04c952..5b2ef724be 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-02-03 - xxx - lavu 57.19.100 - avutil.h
+ Add av_media_type_get_string() which deprecates av_get_media_type_string().
+
2022-01-26 - af94ab7c7c0 - lavu 57.19.100 - tx.h
Add AV_TX_FLOAT_RDFT, AV_TX_DOUBLE_RDFT and AV_TX_INT32_RDFT.
diff --git a/libavutil/avutil.h b/libavutil/avutil.h
index 4d633156d1..6cabeb405a 100644
--- a/libavutil/avutil.h
+++ b/libavutil/avutil.h
@@ -209,9 +209,16 @@ enum AVMediaType {
/**
* Return a string describing the media_type enum, NULL if media_type
* is unknown.
+ *
+ * @deprecated Use av_media_type_get_string() instead.
*/
const char *av_get_media_type_string(enum AVMediaType media_type);
+/**
+ * Return a string describing the media_type enum, never NULL.
+ */
+const char *av_media_type_get_string(enum AVMediaType media_type);
+
/**
* @defgroup lavu_const Constants
* @{
diff --git a/libavutil/utils.c b/libavutil/utils.c
index ea9b5097b8..92d242f678 100644
--- a/libavutil/utils.c
+++ b/libavutil/utils.c
@@ -80,6 +80,19 @@ const char *av_get_media_type_string(enum AVMediaType
media_type)
}
}
+const char *av_media_type_get_string(enum AVMediaType media_type)
+{
+switch (media_type) {
+case AVMEDIA_TYPE_UNKNOWN:return "unknown";
+case AVMEDIA_TYPE_VIDEO: return "video";
+case AVMEDIA_TYPE_AUDIO: return "audio";
+case AVMEDIA_TYPE_DATA: return "data";
+case AVMEDIA_TYPE_SUBTITLE: return "subtitle";
+case AVMEDIA_TYPE_ATTACHMENT: return "attachment";
+default: return "invalid_media_type";
+}
+}
+
char av_get_picture_type_char(enum AVPictureType pict_type)
{
switch (pict_type) {
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2] create av_media_type_get_string()
Instead of making an API breaking change, create a new function instead, and deprecate the old one. Then replace all uses in FFmpeg of the old function with the new one. ___ 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".
[FFmpeg-devel] [PATCH v2 09/13] avpriv_find_start_code(): fix indent from previous commit
Whitespace change only. Separate so the previous diff is clearer.
---
libavcodec/utils.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index da057bad3e..255c133737 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -956,19 +956,19 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
p += 3; // offset for negative indices in while loop
}
else {
-if (p >= end)
-return end;
-
-// read up to the first three bytes in p to enable reading a start code
across
-// two (to four) buffers
-for (int i = 0; i < 3; i++) {
-*start_code <<= 8;
-*start_code += *p;
-p++;
-if (avpriv_start_code_is_valid(*start_code) || p == end)
-return p;
-}
-// p is now properly incremented for the negative indices in the while loop
+if (p >= end)
+return end;
+
+// read up to the first three bytes in p to enable reading a start
code across
+// two (to four) buffers
+for (int i = 0; i < 3; i++) {
+*start_code <<= 8;
+*start_code += *p;
+p++;
+if (avpriv_start_code_is_valid(*start_code) || p == end)
+return p;
+}
+// p is now properly incremented for the negative indices in the while
loop
}
/* with memory address increasing left to right, we are looking for (in
hexadecimal):
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 08/13] avpriv_find_start_code(): add parameter for ignoring history
If true, this skips the for loop at the beginning of avpriv_find_start_code().
If the state/start_code input is a local variable and only one buffer is used,
then no history is needed.
In loops and inline functions: if ignoring history, don't initialize start_code,
so it isn't reset twice each time.
cbs_mpeg2.c needs further changes to use output_only = true.
Use output_only = 0 for no functional change. For example, if the
state/start_code
is passed into the function calling avpriv_find_start_code().
---
libavcodec/cavsdec.c | 2 +-
libavcodec/cbs_mpeg2.c| 4 ++--
libavcodec/extract_extradata_bsf.c| 4 ++--
libavcodec/h264_parser.c | 2 +-
libavcodec/internal.h | 9 -
libavcodec/mpeg12.c | 2 +-
libavcodec/mpeg12dec.c| 9 -
libavcodec/mpeg4_unpack_bframes_bsf.c | 3 +--
libavcodec/mpegvideo_parser.c | 5 ++---
libavcodec/remove_extradata_bsf.c | 8
libavcodec/utils.c| 14 +-
libavcodec/vc1_common.h | 4 ++--
libavformat/avidec.c | 6 +++---
libavformat/avs2dec.c | 2 +-
libavformat/avs3dec.c | 2 +-
libavformat/cavsvideodec.c| 2 +-
libavformat/mpegtsenc.c | 4 ++--
libavformat/mpegvideodec.c| 2 +-
libavformat/mxfenc.c | 2 +-
libavformat/rtpenc_mpv.c | 4 ++--
20 files changed, 53 insertions(+), 37 deletions(-)
diff --git a/libavcodec/cavsdec.c b/libavcodec/cavsdec.c
index a62177d520..c4c78cd534 100644
--- a/libavcodec/cavsdec.c
+++ b/libavcodec/cavsdec.c
@@ -1248,7 +1248,7 @@ static int cavs_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
buf_ptr = buf;
buf_end = buf + buf_size;
for(;;) {
-buf_ptr = avpriv_find_start_code(buf_ptr, buf_end, &stc);
+buf_ptr = avpriv_find_start_code(buf_ptr, buf_end, &stc, 1);
if (!avpriv_start_code_is_valid(stc) || buf_ptr == buf_end) {
if (!h->stc)
av_log(h->avctx, AV_LOG_WARNING, "no frame decoded\n");
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index eb45929132..d41477620e 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -151,7 +151,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
int err, i, final = 0;
start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
- &start_code);
+ &start_code, 1);
if (!avpriv_start_code_is_valid(start_code)) {
// No start code found.
return AVERROR_INVALIDDATA;
@@ -169,7 +169,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
}
end = avpriv_find_start_code(start--, frag->data + frag->data_size,
- &start_code);
+ &start_code, 0);
// start points to the byte containing the start_code_identifier
// (may be the last byte of fragment->data); end points to the byte
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf.c
index 4df1c97139..1a3ddceff2 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -237,7 +237,7 @@ static int extract_extradata_vc1(AVBSFContext *ctx,
AVPacket *pkt,
int has_extradata = 0, extradata_size = 0;
while (ptr < end) {
-ptr = avpriv_find_start_code(ptr, end, &state);
+ptr = avpriv_find_start_code(ptr, end, &state, 1);
if (state == VC1_CODE_SEQHDR || state == VC1_CODE_ENTRYPOINT) {
has_extradata = 1;
} else if (has_extradata && avpriv_start_code_is_valid(state)) {
@@ -300,7 +300,7 @@ static int extract_extradata_mpeg4(AVBSFContext *ctx,
AVPacket *pkt,
uint32_t state = UINT32_MAX;
while (ptr < end) {
-ptr = avpriv_find_start_code(ptr, end, &state);
+ptr = avpriv_find_start_code(ptr, end, &state, 1);
if (state == 0x1B3 || state == 0x1B6) {
if (ptr - pkt->data > 4) {
*size = ptr - 4 - pkt->data;
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 4002bcad77..0ca411c592 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -72,7 +72,7 @@ static int find_start_code(const uint8_t *buf, int buf_size,
{
uint32_t state = -1;
-buf_index = avpriv_find_start_code(buf + buf_index, buf + next_avc + 1,
&state) - buf - 1;
+buf_index = avpriv_find_start_code(buf + buf_index, buf + next_avc + 1,
&state, 1) - buf - 1;
return FFMIN(buf_index, buf_size);
}
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index dadd8d4a10..57e2816a95 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -309,6 +309,9 @@ static av_always_inline int
avpriv_start_code_is_valid
[FFmpeg-devel] [PATCH v2 13/13] cbs_mpeg2.c: improve readability of start code search (part 3)
Separate from part 2 for a clearer diff.
Now the true loop condition has been revealed: start < buf_end
Clarify loop by moving the detection of sequence_end_codes out of the loop.
See also commit fd93d5efe64206d5f1bce8c702602353444c0c1a regarding
sequence_end_codes
---
libavcodec/cbs_mpeg2.c | 31 ++-
1 file changed, 18 insertions(+), 13 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index bf95fb7546..53aa0ed3f6 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -149,7 +149,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
CodedBitstreamUnitType unit_type;
uint32_t start_code = -1;
size_t unit_size;
-int err, final = 0;
+int err;
int i = -1; // offset for pre-increment
start = avpriv_find_start_code(start, buf_end, &start_code, 1);
@@ -161,16 +161,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
do {
unit_type = start_code & 0xff;
-if (start == buf_end) {
-// The last four bytes form a start code which constitutes
-// a unit of its own. In this situation avpriv_find_start_code
-// won't modify start_code at all so modify start_code so that
-// the next unit will be treated as the last unit.
-start_code = 0;
-}
-else {
-end = avpriv_find_start_code(start, buf_end, &start_code, 1);
-}
+end = avpriv_find_start_code(start, buf_end, &start_code, 1);
start--;
// decrement so start points to the byte containing the
start_code_identifier
// (may be the last byte of fragment->data); end points to the byte
@@ -182,8 +173,8 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
unit_size = (end - 4) - start;
} else {
// We didn't find a start code, so this is the final unit.
+ // There is no start code to remove from end, hence not (end - 4).
unit_size = end - start;
- final = 1;
}
err = ff_cbs_insert_unit_data(frag, ++i, unit_type,
@@ -193,7 +184,21 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
return err;
start = end;
-} while (!final);
+} while (start < buf_end);
+
+if (avpriv_start_code_is_valid(start_code)) {
+// The last four bytes form a start code which constitutes
+// a unit of its own, with size 1.
+
+start--; // since start == buf_end because of the loop condition,
+// decrement so start points to the byte containing the
start_code_identifier
+err = ff_cbs_insert_unit_data(frag, ++i, start_code & 0xFF,
+ (uint8_t*)start /* cast away the const
to match parameter type */,
+ 1, frag->data_ref);
+if (err < 0) {
+return err;
+}
+}
return 0;
}
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 07/13] avpriv_find_start_code(): constify pointer parameters
Have the compiler enforce not changing the addresses these parameters point to.
No functional change.
---
libavcodec/internal.h | 6 +++---
libavcodec/utils.c| 4 ++--
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 94c41aef0b..dadd8d4a10 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -313,7 +313,7 @@ static av_always_inline int
avpriv_start_code_is_valid(uint32_t start_code) {
* @param[in] end A pointer to the past-the-end memory address for the buffer
* given by @p p. @p p must be ≤ @p end.
*
- * @param[in,out] start_code A reference to a mutable @c uint32_t.
+ * @param[in,out] start_code A constant pointer (reference) to a mutable @c
uint32_t.
* As input: For no history preset to @c ~0 , otherwise preset
to the last
*returned start code to enable detecting start codes
across
*buffer boundaries.
@@ -325,8 +325,8 @@ static av_always_inline int
avpriv_start_code_is_valid(uint32_t start_code) {
* if no start code was found.
*/
const uint8_t *avpriv_find_start_code(const uint8_t *p,
- const uint8_t *end,
- uint32_t *start_code);
+ const uint8_t * const end,
+ uint32_t * const start_code);
int avpriv_codec_get_cap_skip_frame_fill_param(const AVCodec *codec);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 80ccde023f..cf92d29f67 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -941,8 +941,8 @@ void ff_thread_report_progress2(AVCodecContext *avctx, int
field, int thread, in
#endif
const uint8_t *avpriv_find_start_code(const uint8_t *av_restrict p,
- const uint8_t *end,
- uint32_t *av_restrict start_code)
+ const uint8_t * const end,
+ uint32_t * const av_restrict start_code)
{
av_assert0(p <= end);
if (p >= end)
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 12/13] cbs_mpeg2.c: improve readability of start code search (part 2)
If the last four bytes form a valid start code, the loop would run another time.
Since (start == buf_end), start_code is invalidated so the loop terminates.
However, calling avpriv_find_start_code() with p == end, it will immediately
return due to the zero size buffer. Thus the history is not needed.
---
libavcodec/cbs_mpeg2.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index f2efedde5d..bf95fb7546 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -168,8 +168,9 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
// the next unit will be treated as the last unit.
start_code = 0;
}
-
-end = avpriv_find_start_code(start, buf_end, &start_code, 0);
+else {
+end = avpriv_find_start_code(start, buf_end, &start_code, 1);
+}
start--;
// decrement so start points to the byte containing the
start_code_identifier
// (may be the last byte of fragment->data); end points to the byte
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 11/13] cbs_mpeg2.c: improve readability of start code search (part 1)
ff_cbs_insert_unit_data() does not modify the data or data_size fields of
the CodedBitstreamFragment. It also does not modify the value pointed to
by start. (We don't need that byte in this function anymore, anyway.)
---
libavcodec/cbs_mpeg2.c | 26 +-
1 file changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index afe78eef9a..f2efedde5d 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -144,23 +144,24 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
CodedBitstreamFragment *frag,
int header)
{
-const uint8_t *start, *end;
+const uint8_t *start = frag->data, *end;
+const uint8_t * const buf_end = frag->data + frag->data_size;
CodedBitstreamUnitType unit_type;
uint32_t start_code = -1;
size_t unit_size;
-int err, i = 0, final = 0;
+int err, final = 0;
+int i = -1; // offset for pre-increment
-start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
- &start_code, 1);
+start = avpriv_find_start_code(start, buf_end, &start_code, 1);
if (!avpriv_start_code_is_valid(start_code)) {
// No start code found.
return AVERROR_INVALIDDATA;
}
-while (!final) {
+do {
unit_type = start_code & 0xff;
-if (start == frag->data + frag->data_size) {
+if (start == buf_end) {
// The last four bytes form a start code which constitutes
// a unit of its own. In this situation avpriv_find_start_code
// won't modify start_code at all so modify start_code so that
@@ -168,10 +169,9 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
start_code = 0;
}
-end = avpriv_find_start_code(start--, frag->data + frag->data_size,
- &start_code, 0);
-
-// start points to the byte containing the start_code_identifier
+end = avpriv_find_start_code(start, buf_end, &start_code, 0);
+start--;
+// decrement so start points to the byte containing the
start_code_identifier
// (may be the last byte of fragment->data); end points to the byte
// following the byte containing the start code identifier (or to
// the end of fragment->data).
@@ -185,14 +185,14 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
final = 1;
}
-err = ff_cbs_insert_unit_data(frag, i, unit_type, (uint8_t*)start,
+err = ff_cbs_insert_unit_data(frag, ++i, unit_type,
+ (uint8_t*)start /* cast away the const
to match parameter type */,
unit_size, frag->data_ref);
if (err < 0)
return err;
start = end;
-i++;
-}
+} while (!final);
return 0;
}
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 06/13] avpriv_find_start_code(): correct type of start_code parameter
---
libavcodec/mpeg12dec.c | 2 +-
libavformat/rtpenc_mpv.c | 3 +--
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 65b66d11f8..6b0b84ae64 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -1770,7 +1770,7 @@ static int mpeg_decode_slice(MpegEncContext *s, int mb_y,
if (avctx->hwaccel && avctx->hwaccel->decode_slice) {
const uint8_t *buf_end, *buf_start = *buf - 4; /* include start_code */
-int start_code = -1;
+uint32_t start_code = ~0;
buf_end = avpriv_find_start_code(buf_start + 2, *buf + buf_size,
&start_code);
if (buf_end < *buf + buf_size)
buf_end -= 4;
diff --git a/libavformat/rtpenc_mpv.c b/libavformat/rtpenc_mpv.c
index 05a77fa11c..91c07574bb 100644
--- a/libavformat/rtpenc_mpv.c
+++ b/libavformat/rtpenc_mpv.c
@@ -51,11 +51,10 @@ void ff_rtp_send_mpegvideo(AVFormatContext *s1, const
uint8_t *buf1, int size)
end_of_slice = 1;
} else {
const uint8_t *r, *r1;
-int start_code;
r1 = buf1;
while (1) {
-start_code = -1;
+uint32_t start_code = ~0;
r = avpriv_find_start_code(r1, end, &start_code);
if (avpriv_start_code_is_valid(start_code)) {
/* New start code found */
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 05/13] avpriv_find_start_code(): add doxygen comment and rename a parameter
---
libavcodec/internal.h | 26 +-
libavcodec/utils.c| 10 +-
2 files changed, 30 insertions(+), 6 deletions(-)
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 005f308b70..94c41aef0b 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -300,9 +300,33 @@ static av_always_inline int
avpriv_start_code_is_valid(uint32_t start_code) {
return (start_code & 0xFF00) == 0x100;
}
+/**
+ * @brief Find the first start code in the buffer @p p.
+ *
+ * A start code is a sequence of 4 bytes with the hexadecimal value 00
00 01 XX ,
+ * where XX represents any value and memory address
increases left to right.
+ *
+ * By preserving the @p start_code value between subsequent calls, the
caller can
+ * detect start codes across buffer boundaries.
+ *
+ * @param[in] p A pointer to the start of the memory buffer to scan.
+ * @param[in] end A pointer to the past-the-end memory address for the buffer
+ * given by @p p. @p p must be ≤ @p end.
+ *
+ * @param[in,out] start_code A reference to a mutable @c uint32_t.
+ * As input: For no history preset to @c ~0 , otherwise preset
to the last
+ *returned start code to enable detecting start codes
across
+ *buffer boundaries.
+ * On output: Set to the found start code if it exists or an invalid
+ * start code (the 4 bytes prior to the returned value,
+ * using the input history if @f$ p - end < 4 @f$).
+ *
+ * @return A pointer to the memory address following the found start code, or
@p end
+ * if no start code was found.
+ */
const uint8_t *avpriv_find_start_code(const uint8_t *p,
const uint8_t *end,
- uint32_t *state);
+ uint32_t *start_code);
int avpriv_codec_get_cap_skip_frame_fill_param(const AVCodec *codec);
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 1a806b9fa8..80ccde023f 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -942,7 +942,7 @@ void ff_thread_report_progress2(AVCodecContext *avctx, int
field, int thread, in
const uint8_t *avpriv_find_start_code(const uint8_t *av_restrict p,
const uint8_t *end,
- uint32_t *av_restrict state)
+ uint32_t *av_restrict start_code)
{
av_assert0(p <= end);
if (p >= end)
@@ -951,10 +951,10 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
// read up to the first three bytes in p to enable reading a start code
across
// two (to four) buffers
for (int i = 0; i < 3; i++) {
-*state <<= 8;
-*state += *p;
+*start_code <<= 8;
+*start_code += *p;
p++;
-if (avpriv_start_code_is_valid(*state) || p == end)
+if (avpriv_start_code_is_valid(*start_code) || p == end)
return p;
}
// p is now properly incremented for the negative indices in the while loop
@@ -988,7 +988,7 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
// this will cause the last 4 bytes before end to be read,
// i.e. no out of bounds memory access occurs
-*state = AV_RB32(p - 4);
+*start_code = AV_RB32(p - 4);
// read the previous 4 bytes, i.e. bytes {p - 4, p - 3, p - 2, p - 1}
return p;
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 10/13] cbs_mpeg2.c: use a while loop with a loop condition instead of an infinite loop
This enhances the clarity of the code.
---
libavcodec/cbs_mpeg2.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index d41477620e..afe78eef9a 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -148,7 +148,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
CodedBitstreamUnitType unit_type;
uint32_t start_code = -1;
size_t unit_size;
-int err, i, final = 0;
+int err, i = 0, final = 0;
start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
&start_code, 1);
@@ -157,7 +157,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
return AVERROR_INVALIDDATA;
}
-for (i = 0;; i++) {
+while (!final) {
unit_type = start_code & 0xff;
if (start == frag->data + frag->data_size) {
@@ -190,10 +190,8 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
if (err < 0)
return err;
-if (final)
-break;
-
start = end;
+i++;
}
return 0;
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 04/13] avpriv_find_start_code(): rewrite for loop for clarity
---
libavcodec/utils.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 8f8cc820bd..1a806b9fa8 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -944,18 +944,20 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
const uint8_t *end,
uint32_t *av_restrict state)
{
-int i;
-
av_assert0(p <= end);
if (p >= end)
return end;
-for (i = 0; i < 3; i++) {
-uint32_t tmp = *state << 8;
-*state = tmp + *(p++);
-if (tmp == 0x100 || p == end)
+// read up to the first three bytes in p to enable reading a start code
across
+// two (to four) buffers
+for (int i = 0; i < 3; i++) {
+*state <<= 8;
+*state += *p;
+p++;
+if (avpriv_start_code_is_valid(*state) || p == end)
return p;
}
+// p is now properly incremented for the negative indices in the while loop
/* with memory address increasing left to right, we are looking for (in
hexadecimal):
* 00 00 01 XX
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 03/13] avpriv_find_start_code(): rewrite while loop and add comments for clarity
The expected number of iterations may increase by one for an input of
alternating
0 and 1 bytes. Instead of incrementing by 2 everytime, it now alternates
between
incrementing by 1 and by 3.
No functional change, but now much clearer.
For the check p[-2] != 0:
Also reduce the number of iterations by correctly starting with three new bytes
on the next iteration,
instead of keeping byte p[-3] which is invalid, i.e. known to be 01 when it
must be 00.
---
libavcodec/utils.c | 25 -
1 file changed, 20 insertions(+), 5 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index cb4437edc2..8f8cc820bd 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -957,12 +957,26 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
return p;
}
+/* with memory address increasing left to right, we are looking for (in
hexadecimal):
+ * 00 00 01 XX
+ * p points at the address which should have the value of XX
+ */
while (p < end) {
-if (p[-1] > 1 ) p += 3;
-else if (p[-2] ) p += 2;
-else if (p[-3]|(p[-1]-1)) p++;
+// UU UU UU
+if (p[-1] > 1) p += 3;// start check over with 3 new bytes
+else if (p[-1] == 0) p++; // could be in a start code, so check
next byte
+// this should be one comparison against 1 since p is unsigned,
+// i.e. p[-1] == 0 is equivalent to p[-1] < 1
+
+// UU UU 01
+else if (p[-2] != 0) p += 3;// we have UU YY 01, so increment by 3
+// to start check over with 3 new bytes
+// UU 00 01
+else if (p[-3] != 0) p += 3;// we have YY 00 01, so increment by 3
+// to start check over with 3 new bytes
+// 00 00 01
else {
-p++;
+p++; // p now points at the address following the start code value
XX
break;
}
}
@@ -972,7 +986,8 @@ const uint8_t *avpriv_find_start_code(const uint8_t
*av_restrict p,
// this will cause the last 4 bytes before end to be read,
// i.e. no out of bounds memory access occurs
-*state = AV_RB32(p - 4); // read the previous 4 bytes
+*state = AV_RB32(p - 4);
+// read the previous 4 bytes, i.e. bytes {p - 4, p - 3, p - 2, p - 1}
return p;
}
--
2.32.0
___
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".
[FFmpeg-devel] [PATCH v2 02/13] avpriv_find_start_code(): readability enhancement part 1
No functional change. --- libavcodec/utils.c | 10 +++--- 1 file changed, 7 insertions(+), 3 deletions(-) diff --git a/libavcodec/utils.c b/libavcodec/utils.c index b19befef21..cb4437edc2 100644 --- a/libavcodec/utils.c +++ b/libavcodec/utils.c @@ -967,10 +967,14 @@ const uint8_t *avpriv_find_start_code(const uint8_t *av_restrict p, } } -p = FFMIN(p, end) - 4; -*state = AV_RB32(p); +if (p > end) +p = end; +// this will cause the last 4 bytes before end to be read, +// i.e. no out of bounds memory access occurs -return p + 4; +*state = AV_RB32(p - 4); // read the previous 4 bytes + +return p; } AVCPBProperties *av_cpb_properties_alloc(size_t *size) -- 2.32.0 ___ 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".
[FFmpeg-devel] [PATCH v2 01/13] avcodec/internal.h: create avpriv_start_code_is_valid()
---
libavcodec/cavsdec.c | 2 +-
libavcodec/cbs_mpeg2.c | 4 ++--
libavcodec/extract_extradata_bsf.c | 2 +-
libavcodec/internal.h | 15 +++
libavcodec/mpeg12.c| 2 +-
libavcodec/mpeg12dec.c | 2 +-
libavcodec/mpegvideo_parser.c | 2 +-
libavcodec/remove_extradata_bsf.c | 8 +++-
libavcodec/vaapi_vc1.c | 2 +-
libavcodec/vc1_common.h| 4 +---
libavcodec/vc1dec.c| 2 +-
libavformat/avs2dec.c | 4 ++--
libavformat/avs3dec.c | 4 ++--
libavformat/cavsvideodec.c | 2 +-
libavformat/mpegvideodec.c | 2 +-
libavformat/rtpenc_mpv.c | 2 +-
16 files changed, 35 insertions(+), 24 deletions(-)
diff --git a/libavcodec/cavsdec.c b/libavcodec/cavsdec.c
index 692c77eb39..a62177d520 100644
--- a/libavcodec/cavsdec.c
+++ b/libavcodec/cavsdec.c
@@ -1249,7 +1249,7 @@ static int cavs_decode_frame(AVCodecContext *avctx, void
*data, int *got_frame,
buf_end = buf + buf_size;
for(;;) {
buf_ptr = avpriv_find_start_code(buf_ptr, buf_end, &stc);
-if ((stc & 0xFE00) || buf_ptr == buf_end) {
+if (!avpriv_start_code_is_valid(stc) || buf_ptr == buf_end) {
if (!h->stc)
av_log(h->avctx, AV_LOG_WARNING, "no frame decoded\n");
return FFMAX(0, buf_ptr - buf);
diff --git a/libavcodec/cbs_mpeg2.c b/libavcodec/cbs_mpeg2.c
index 26400f279f..eb45929132 100644
--- a/libavcodec/cbs_mpeg2.c
+++ b/libavcodec/cbs_mpeg2.c
@@ -152,7 +152,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
start = avpriv_find_start_code(frag->data, frag->data + frag->data_size,
&start_code);
-if (start_code >> 8 != 0x01) {
+if (!avpriv_start_code_is_valid(start_code)) {
// No start code found.
return AVERROR_INVALIDDATA;
}
@@ -175,7 +175,7 @@ static int cbs_mpeg2_split_fragment(CodedBitstreamContext
*ctx,
// (may be the last byte of fragment->data); end points to the byte
// following the byte containing the start code identifier (or to
// the end of fragment->data).
-if (start_code >> 8 == 0x01) {
+if (avpriv_start_code_is_valid(start_code)) {
// Unit runs from start to the beginning of the start code
// pointed to by end (including any padding zeroes).
unit_size = (end - 4) - start;
diff --git a/libavcodec/extract_extradata_bsf.c
b/libavcodec/extract_extradata_bsf.c
index dbcb8508b0..4df1c97139 100644
--- a/libavcodec/extract_extradata_bsf.c
+++ b/libavcodec/extract_extradata_bsf.c
@@ -240,7 +240,7 @@ static int extract_extradata_vc1(AVBSFContext *ctx,
AVPacket *pkt,
ptr = avpriv_find_start_code(ptr, end, &state);
if (state == VC1_CODE_SEQHDR || state == VC1_CODE_ENTRYPOINT) {
has_extradata = 1;
-} else if (has_extradata && IS_MARKER(state)) {
+} else if (has_extradata && avpriv_start_code_is_valid(state)) {
extradata_size = ptr - 4 - pkt->data;
break;
}
diff --git a/libavcodec/internal.h b/libavcodec/internal.h
index 72ca1553f6..005f308b70 100644
--- a/libavcodec/internal.h
+++ b/libavcodec/internal.h
@@ -285,6 +285,21 @@ int ff_thread_can_start_frame(AVCodecContext *avctx);
int avpriv_h264_has_num_reorder_frames(AVCodecContext *avctx);
+/**
+ * @brief Test whether a start code found by avpriv_find_start_code() is valid.
+ *
+ * Use this to test the validity of a start code especially if a start code can
+ * be at the end of the buffer, where testing the return value of
avpriv_find_start_code()
+ * would incorrectly imply that the start code is invalid (since the returned
value
+ * equals @c end ).
+ *
+ * @param[in] start_code The start code to test.
+ * @return A boolean that is true if and only if @p start_code is valid
+ */
+static av_always_inline int avpriv_start_code_is_valid(uint32_t start_code) {
+return (start_code & 0xFF00) == 0x100;
+}
+
const uint8_t *avpriv_find_start_code(const uint8_t *p,
const uint8_t *end,
uint32_t *state);
diff --git a/libavcodec/mpeg12.c b/libavcodec/mpeg12.c
index 58e03c05d4..e45bc74479 100644
--- a/libavcodec/mpeg12.c
+++ b/libavcodec/mpeg12.c
@@ -217,7 +217,7 @@ int ff_mpeg1_find_frame_end(ParseContext *pc, const uint8_t
*buf, int buf_size,
pc->frame_start_found = 0;
if (pc->frame_start_found < 4 && state == EXT_START_CODE)
pc->frame_start_found++;
-if (pc->frame_start_found == 4 && (state & 0xFF00) == 0x100) {
+if (pc->frame_start_found == 4 &&
avpriv_start_code_is_valid(state)) {
if (state < SLICE_MIN_START_CODE || state >
SLICE_MAX_START_CODE) {
pc->frame_start_found = 0;
[FFmpeg-devel] [PATCH v2 0/13] rewrite avpriv_find_start_code() for clarity
start_code is used as an [in,out] parameter only twice, once each in mpeg12.c and mpegvideo_parser.c. The input part of avpriv_find_start_code() has now been rewritten to still allow this. I did manage to run FATE this time and it completes without errors. Regards, Scott ___ 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".
[FFmpeg-devel] [PATCH v4 1/1] avformat: Add IPFS protocol support.
This patch adds support for:
- ffplay ipfs://
- ffplay ipns://
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser
---
configure | 2 +
doc/protocols.texi| 30
libavformat/Makefile | 2 +
libavformat/ipfsgateway.c | 329 ++
libavformat/protocols.c | 2 +
5 files changed, 365 insertions(+)
create mode 100644 libavformat/ipfsgateway.c
diff --git a/configure b/configure
index 5b19a35f59..6ff09e7974 100755
--- a/configure
+++ b/configure
@@ -3585,6 +3585,8 @@ udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
+ipfs_protocol_select="https_protocol"
+ipns_protocol_select="https_protocol"
# external library protocols
libamqp_protocol_deps="librabbitmq"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index d207df0b52..7c9c0a4808 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -2025,5 +2025,35 @@ decoding errors.
@end table
+@section ipfs
+
+InterPlanetary File System (IPFS) protocol support. One can access files
stored
+on the IPFS network through so called gateways. Those are http(s) endpoints.
+This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be send
+to such a gateway. Users can (and should) host their own node which means this
+protocol will use your local machine gateway to access files on the IPFS
network.
+
+If a user doesn't have a node of their own then the public gateway dweb.link
is
+used by default.
+
+You can use this protocol in 2 ways. Using IPFS:
+@example
+ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+@end example
+
+Or the IPNS protocol (IPNS is mutable IPFS):
+@example
+ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+@end example
+
+You can also change the gateway to be used:
+
+@table @option
+
+@item gateway
+Defines the gateway to use. When nothing is provided the protocol will first
try
+your local gateway. If that fails dweb.link will be used.
+
+@end table
@c man end PROTOCOLS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3dc6a479cc..4edce8420f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += srtpproto.o
srtp.o
OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o
OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o
OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o
+OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o
+OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o
TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
new file mode 100644
index 00..72d431eac3
--- /dev/null
+++ b/libavformat/ipfsgateway.c
@@ -0,0 +1,329 @@
+/*
+ * IPFS and IPNS protocol support through IPFS Gateway.
+ * Copyright (c) 2022 Mark Gaiser
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/tree.h"
+#include
+#if HAVE_IO_H
+#include
+#endif
+#if HAVE_UNISTD_H
+#include
+#endif
+#include "os_support.h"
+#include "url.h"
+#include
+#include
+
+typedef struct IPFSGatewayContext {
+AVClass *class;
+URLContext *inner;
+char *gateway;
+} IPFSGatewayC
[FFmpeg-devel] [PATCH v4 0/1] Add IPFS protocol support.
Hi, This patch series adds support for IPFS. V3 (V4): - V4: title issue from V3.. - A lot of style changes - Made url checks a lot more strict - av_asprintf leak fixes - So many changes that a diff to v2 is again not sensible. V2: - Squashed and changed so much that a diff to v1 was not sensible. The following is a short summary. In the IPFS ecosystem you access it's content by a "Content IDentifier" (CID). This CID is, in simplified terms, a hash of the content. IPFS itself is a distributed network where any user can run a node to be part of the network and access files by their CID. If any reachable node within that network has the CID, you can get it. IPFS (as a technology) has two protocols, ipfs and ipns. The ipfs protocol is the immutable way to access content. The ipns protocol is a mutable layer on top of it. It's essentially a new CID that points to a ipfs CID. This "pointer" if you will can be changed to point to something else. Much more information on how this technology works can be found here [1]. This patch series allows to interact natively with IPFS. That means being able to access files like: - ffplay ipfs:// - ffplay ipns:// There are multiple ways to access files on the IPFS network. This patch series uses the gateway driven way. An IPFS node - by default - exposes a local gateway (say http://localhost:8080) which is then used to get content from IPFS. The gateway functionality on the IPFS side contains optimizations to be as ideal to streaming data as it can be. Optimizations that the http protocol in ffmpeg also has and are thus reused for free in this approach. A note on other "more appropiate" ways, as I received some feedback on that. For ffmpeg purposes the gateway approach is ideal! There is a "libipfs" but that would spin up an ipfs node with the overhead of: - bootstrapping - connecting to nodes - finding other nodes to connect too - finally finding your file This alternative approach could take minutes before a file is played. The gateway approach immediately connects to an already running node thus gives the file the fastest. Much of the logic in this patch series is to find that gateway and essentially rewrite: "ipfs://" to: "http://localhost:8080/ipfs/" Once that's found it's forwared to the protocol handler where eventually the http protocol is going to handle it. Note that it could also be https. There's enough flexibility in the implementation to allow the user to provide a gateway. There are also public https gateways which can be used just as well. After this patch is accepted, I'll work on getting IPFS supported in: - mpv (requires this ffmpeg patch) - vlc (prefers this patch but can be made to work without this patch) - kodi (requires this ffmpeg patch) Best regards, Mark Gaiser [1] https://docs.ipfs.io/concepts/ Mark Gaiser (1): avformat: Add IPFS protocol support. configure | 2 + doc/protocols.texi| 30 libavformat/Makefile | 2 + libavformat/ipfsgateway.c | 329 ++ libavformat/protocols.c | 2 + 5 files changed, 365 insertions(+) create mode 100644 libavformat/ipfsgateway.c -- 2.35.1 ___ 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".
Re: [FFmpeg-devel] [PATCH v3 1/1] avformat: Add IPFS protocol support.
Ignore this one, the title went wrong. On Thu, Feb 3, 2022 at 6:26 PM Mark Gaiser wrote: > This patch adds support for: > - ffplay ipfs:// > - ffplay ipns:// > > IPFS data can be played from so called "ipfs gateways". > A gateway is essentially a webserver that gives access to the > distributed IPFS network. > > This protocol support (ipfs and ipns) therefore translates > ipfs:// and ipns:// to a http:// url. This resulting url is > then handled by the http protocol. It could also be https > depending on the gateway provided. > > To use this protocol, a gateway must be provided. > If you do nothing it will try to find it in your > $HOME/.ipfs/gateway file. The ways to set it manually are: > 1. Define a -gateway to the gateway. > 2. Define $IPFS_GATEWAY with the full http link to the gateway. > 3. Define $IPFS_PATH and point it to the IPFS data path. > 4. Have IPFS running in your local user folder (under $HOME/.ipfs). > > Signed-off-by: Mark Gaiser > --- > configure | 2 + > doc/protocols.texi| 30 > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 329 ++ > libavformat/protocols.c | 2 + > 5 files changed, 365 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > diff --git a/configure b/configure > index 5b19a35f59..6ff09e7974 100755 > --- a/configure > +++ b/configure > @@ -3585,6 +3585,8 @@ udp_protocol_select="network" > udplite_protocol_select="network" > unix_protocol_deps="sys_un_h" > unix_protocol_select="network" > +ipfs_protocol_select="https_protocol" > +ipns_protocol_select="https_protocol" > > # external library protocols > libamqp_protocol_deps="librabbitmq" > diff --git a/doc/protocols.texi b/doc/protocols.texi > index d207df0b52..7c9c0a4808 100644 > --- a/doc/protocols.texi > +++ b/doc/protocols.texi > @@ -2025,5 +2025,35 @@ decoding errors. > > @end table > > +@section ipfs > + > +InterPlanetary File System (IPFS) protocol support. One can access files > stored > +on the IPFS network through so called gateways. Those are http(s) > endpoints. > +This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be > send > +to such a gateway. Users can (and should) host their own node which means > this > +protocol will use your local machine gateway to access files on the IPFS > network. > + > +If a user doesn't have a node of their own then the public gateway > dweb.link is > +used by default. > + > +You can use this protocol in 2 ways. Using IPFS: > +@example > +ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +Or the IPNS protocol (IPNS is mutable IPFS): > +@example > +ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T > +@end example > + > +You can also change the gateway to be used: > + > +@table @option > + > +@item gateway > +Defines the gateway to use. When nothing is provided the protocol will > first try > +your local gateway. If that fails dweb.link will be used. > + > +@end table > > @c man end PROTOCOLS > diff --git a/libavformat/Makefile b/libavformat/Makefile > index 3dc6a479cc..4edce8420f 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += > srtpproto.o srtp.o > OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o > OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o > OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o > +OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o > +OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o > TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o > TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o > TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o > diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c > new file mode 100644 > index 00..72d431eac3 > --- /dev/null > +++ b/libavformat/ipfsgateway.c > @@ -0,0 +1,329 @@ > +/* > + * IPFS and IPNS protocol support through IPFS Gateway. > + * Copyright (c) 2022 Mark Gaiser > + * > + * This file is part of FFmpeg. > + * > + * FFmpeg is free software; you can redistribute it and/or > + * modify it under the terms of the GNU Lesser General Public > + * License as published by the Free Software Foundation; either > + * version 2.1 of the License, or (at your option) any later version. > + * > + * FFmpeg is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU > + * Lesser General Public License for more details. > + * > + * You should have received a copy of the GNU Lesser General Public > + * License along with FFmpeg; if not, write to the Free Software > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA > 02110-1301 USA > + */ > + > +#include "avformat.h" > +#include "libavutil/avassert.h" > +#include "libavutil/avstring.h" > +#include "lib
Re: [FFmpeg-devel] [PATCH v2 0/1] Add IPFS protocol support.
Ignore this one, the title went wrong. On Thu, Feb 3, 2022 at 6:26 PM Mark Gaiser wrote: > Hi, > > This patch series adds support for IPFS. > V3: > - A lot of style changes > - Made url checks a lot more strict > - av_asprintf leak fixes > - So many changes that a diff to v2 is again not sensible. > V2: > - Squashed and changed so much that a diff to v1 was not sensible. > > The following is a short summary. In the IPFS ecosystem you access it's > content > by a "Content IDentifier" (CID). This CID is, in simplified terms, a hash > of > the content. IPFS itself is a distributed network where any user can run a > node > to be part of the network and access files by their CID. If any reachable > node > within that network has the CID, you can get it. > > IPFS (as a technology) has two protocols, ipfs and ipns. > The ipfs protocol is the immutable way to access content. > The ipns protocol is a mutable layer on top of it. It's essentially a new > CID > that points to a ipfs CID. This "pointer" if you will can be changed to > point > to something else. > Much more information on how this technology works can be found here [1]. > > This patch series allows to interact natively with IPFS. That means being > able > to access files like: > - ffplay ipfs:// > - ffplay ipns:// > > There are multiple ways to access files on the IPFS network. This patch > series > uses the gateway driven way. An IPFS node - by default - exposes a local > gateway (say http://localhost:8080) which is then used to get content > from IPFS. > The gateway functionality on the IPFS side contains optimizations to > be as ideal to streaming data as it can be. Optimizations that the http > protocol > in ffmpeg also has and are thus reused for free in this approach. > > A note on other "more appropiate" ways, as I received some feedback on > that. > For ffmpeg purposes the gateway approach is ideal! There is a "libipfs" but > that would spin up an ipfs node with the overhead of: > - bootstrapping > - connecting to nodes > - finding other nodes to connect too > - finally finding your file > > This alternative approach could take minutes before a file is played. The > gateway approach immediately connects to an already running node thus gives > the file the fastest. > > Much of the logic in this patch series is to find that gateway and > essentially > rewrite: > > "ipfs://" > > to: > > "http://localhost:8080/ipfs/" > > Once that's found it's forwared to the protocol handler where eventually > the > http protocol is going to handle it. Note that it could also be https. > There's > enough flexibility in the implementation to allow the user to provide a > gateway. There are also public https gateways which can be used just as > well. > > After this patch is accepted, I'll work on getting IPFS supported in: > - mpv (requires this ffmpeg patch) > - vlc (prefers this patch but can be made to work without this patch) > - kodi (requires this ffmpeg patch) > > Best regards, > Mark Gaiser > > [1] https://docs.ipfs.io/concepts/ > > Mark Gaiser (1): > avformat: Add IPFS protocol support. > > configure | 2 + > doc/protocols.texi| 30 > libavformat/Makefile | 2 + > libavformat/ipfsgateway.c | 329 ++ > libavformat/protocols.c | 2 + > 5 files changed, 365 insertions(+) > create mode 100644 libavformat/ipfsgateway.c > > -- > 2.35.1 > > ___ 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".
[FFmpeg-devel] [PATCH v3 1/1] avformat: Add IPFS protocol support.
This patch adds support for:
- ffplay ipfs://
- ffplay ipns://
IPFS data can be played from so called "ipfs gateways".
A gateway is essentially a webserver that gives access to the
distributed IPFS network.
This protocol support (ipfs and ipns) therefore translates
ipfs:// and ipns:// to a http:// url. This resulting url is
then handled by the http protocol. It could also be https
depending on the gateway provided.
To use this protocol, a gateway must be provided.
If you do nothing it will try to find it in your
$HOME/.ipfs/gateway file. The ways to set it manually are:
1. Define a -gateway to the gateway.
2. Define $IPFS_GATEWAY with the full http link to the gateway.
3. Define $IPFS_PATH and point it to the IPFS data path.
4. Have IPFS running in your local user folder (under $HOME/.ipfs).
Signed-off-by: Mark Gaiser
---
configure | 2 +
doc/protocols.texi| 30
libavformat/Makefile | 2 +
libavformat/ipfsgateway.c | 329 ++
libavformat/protocols.c | 2 +
5 files changed, 365 insertions(+)
create mode 100644 libavformat/ipfsgateway.c
diff --git a/configure b/configure
index 5b19a35f59..6ff09e7974 100755
--- a/configure
+++ b/configure
@@ -3585,6 +3585,8 @@ udp_protocol_select="network"
udplite_protocol_select="network"
unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
+ipfs_protocol_select="https_protocol"
+ipns_protocol_select="https_protocol"
# external library protocols
libamqp_protocol_deps="librabbitmq"
diff --git a/doc/protocols.texi b/doc/protocols.texi
index d207df0b52..7c9c0a4808 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -2025,5 +2025,35 @@ decoding errors.
@end table
+@section ipfs
+
+InterPlanetary File System (IPFS) protocol support. One can access files
stored
+on the IPFS network through so called gateways. Those are http(s) endpoints.
+This protocol wraps the IPFS native protocols (ipfs:// and ipns://) to be send
+to such a gateway. Users can (and should) host their own node which means this
+protocol will use your local machine gateway to access files on the IPFS
network.
+
+If a user doesn't have a node of their own then the public gateway dweb.link
is
+used by default.
+
+You can use this protocol in 2 ways. Using IPFS:
+@example
+ffplay ipfs://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+@end example
+
+Or the IPNS protocol (IPNS is mutable IPFS):
+@example
+ffplay ipns://QmbGtJg23skhvFmu9mJiePVByhfzu5rwo74MEkVDYAmF5T
+@end example
+
+You can also change the gateway to be used:
+
+@table @option
+
+@item gateway
+Defines the gateway to use. When nothing is provided the protocol will first
try
+your local gateway. If that fails dweb.link will be used.
+
+@end table
@c man end PROTOCOLS
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 3dc6a479cc..4edce8420f 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -656,6 +656,8 @@ OBJS-$(CONFIG_SRTP_PROTOCOL) += srtpproto.o
srtp.o
OBJS-$(CONFIG_SUBFILE_PROTOCOL) += subfile.o
OBJS-$(CONFIG_TEE_PROTOCOL) += teeproto.o tee_common.o
OBJS-$(CONFIG_TCP_PROTOCOL) += tcp.o
+OBJS-$(CONFIG_IPFS_PROTOCOL) += ipfsgateway.o
+OBJS-$(CONFIG_IPNS_PROTOCOL) += ipfsgateway.o
TLS-OBJS-$(CONFIG_GNUTLS)+= tls_gnutls.o
TLS-OBJS-$(CONFIG_LIBTLS)+= tls_libtls.o
TLS-OBJS-$(CONFIG_MBEDTLS) += tls_mbedtls.o
diff --git a/libavformat/ipfsgateway.c b/libavformat/ipfsgateway.c
new file mode 100644
index 00..72d431eac3
--- /dev/null
+++ b/libavformat/ipfsgateway.c
@@ -0,0 +1,329 @@
+/*
+ * IPFS and IPNS protocol support through IPFS Gateway.
+ * Copyright (c) 2022 Mark Gaiser
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avformat.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/tree.h"
+#include
+#if HAVE_IO_H
+#include
+#endif
+#if HAVE_UNISTD_H
+#include
+#endif
+#include "os_support.h"
+#include "url.h"
+#include
+#include
+
+typedef struct IPFSGatewayContext {
+AVClass *class;
+URLContext *inner;
+char *gateway;
+} IPFSGatewayC
[FFmpeg-devel] [PATCH v2 0/1] Add IPFS protocol support.
Hi, This patch series adds support for IPFS. V3: - A lot of style changes - Made url checks a lot more strict - av_asprintf leak fixes - So many changes that a diff to v2 is again not sensible. V2: - Squashed and changed so much that a diff to v1 was not sensible. The following is a short summary. In the IPFS ecosystem you access it's content by a "Content IDentifier" (CID). This CID is, in simplified terms, a hash of the content. IPFS itself is a distributed network where any user can run a node to be part of the network and access files by their CID. If any reachable node within that network has the CID, you can get it. IPFS (as a technology) has two protocols, ipfs and ipns. The ipfs protocol is the immutable way to access content. The ipns protocol is a mutable layer on top of it. It's essentially a new CID that points to a ipfs CID. This "pointer" if you will can be changed to point to something else. Much more information on how this technology works can be found here [1]. This patch series allows to interact natively with IPFS. That means being able to access files like: - ffplay ipfs:// - ffplay ipns:// There are multiple ways to access files on the IPFS network. This patch series uses the gateway driven way. An IPFS node - by default - exposes a local gateway (say http://localhost:8080) which is then used to get content from IPFS. The gateway functionality on the IPFS side contains optimizations to be as ideal to streaming data as it can be. Optimizations that the http protocol in ffmpeg also has and are thus reused for free in this approach. A note on other "more appropiate" ways, as I received some feedback on that. For ffmpeg purposes the gateway approach is ideal! There is a "libipfs" but that would spin up an ipfs node with the overhead of: - bootstrapping - connecting to nodes - finding other nodes to connect too - finally finding your file This alternative approach could take minutes before a file is played. The gateway approach immediately connects to an already running node thus gives the file the fastest. Much of the logic in this patch series is to find that gateway and essentially rewrite: "ipfs://" to: "http://localhost:8080/ipfs/" Once that's found it's forwared to the protocol handler where eventually the http protocol is going to handle it. Note that it could also be https. There's enough flexibility in the implementation to allow the user to provide a gateway. There are also public https gateways which can be used just as well. After this patch is accepted, I'll work on getting IPFS supported in: - mpv (requires this ffmpeg patch) - vlc (prefers this patch but can be made to work without this patch) - kodi (requires this ffmpeg patch) Best regards, Mark Gaiser [1] https://docs.ipfs.io/concepts/ Mark Gaiser (1): avformat: Add IPFS protocol support. configure | 2 + doc/protocols.texi| 30 libavformat/Makefile | 2 + libavformat/ipfsgateway.c | 329 ++ libavformat/protocols.c | 2 + 5 files changed, 365 insertions(+) create mode 100644 libavformat/ipfsgateway.c -- 2.35.1 ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On 3 Feb 2022, at 13:47, Martin Storsjö wrote: On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 13:33, Martin Storsjö wrote: On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Sorry, need to correct myself. It is indeed localized I was just lacking the language pack… For example in german it is: Microsoft (R) C/C++-Optimierungscompiler Version 19.30.30709 für x64 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Oh, thanks for that! I presume that this also could break the other existing check for armasm too? If you run e.g. "vsdevcmd -host_arch=x64 -arch=arm64" and then "armasm64", what does that print? Interestingly that one does not seem localized: C:\Program Files\Microsoft Visual Studio\2022\Community>armasm64 Microsoft (R) ARM Macro Assembler Version 14.30.30709.0 for 64 bits Copyright (C) Microsoft Corporation. All rights reserved. That's interesting! I tried to have a look at what e.g. meson does for detection. It doesn't look that much at the output, but first detects clang-cl specifically, then plain clang, then moves on to MSVC itself (matching only 'Microsoft'). Meson does, however, check a longer regex for identifying and disambiguating the 'rc' tool from windres. Is 'rc' localized? That one is not localized either for me. At least for the /? option. // Martin ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCH v2 1/1] avformat: Add IPFS protocol support.
On Wed, Feb 02, 2022 at 03:23:34PM +0100, Mark Gaiser wrote: > On Wed, Feb 2, 2022 at 2:29 PM Michael Niedermayer > wrote: > > > On Tue, Feb 01, 2022 at 10:58:30PM +0100, Mark Gaiser wrote: [...] > > > > > > > +AVClass *class; > > > +URLContext *inner; > > > +char *gateway; > > > +} Context; > > > + > > > +// A best-effort way to find the IPFS gateway. > > > +// Only the most appropiate gateway is set. It's not actually requested > > (http call) to prevent > > > +// a potential slowdown in startup. A potential timeout is handled by > > the HTTP protocol. > > > +// > > > +// When done and the return value is 1, a potential IPFS Gateway is set > > in the gateway > > > +// variable in the inner URLContext. > > > > > +static int ff_populate_ipfs_gateway(URLContext *h) > > > > ff_ prefix seems not needed > > > > Done. Removed the prefix from both functions. > For the record, I thought it was mandatory to prefix internal functions > with "ff_"? only non static ones, these prefixes are to avoid conflicing with other things in the global namespace [...] > > > > > > > > > +} > > > + > > > > > +fscanf(gateway_file, "%[^\n]", gateway_file_data); > > > > how large is the array ? > > how large is the data written into the array ? > > what is the relation between the 2 ? > > > > Yeah... I'm going to need more information on that one. > What do you mean? > Is this wrong? the array is fixed length, the string written into it is from some external file IIRC. Maybe i missed a check but to me it seemed like the array end can be overwritten which is bad thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. signature.asc Description: PGP signature ___ 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".
Re: [FFmpeg-devel] [PATCH 1/2] http: Improve handling of Content-Range with Transfer-Encoding:chunked
On 2/3/2022 1:26 AM, Aman Karmani wrote: > The size part of the range header is optional, and can be '*' as well. > > See also > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20211005233244.37582-1-ffm...@tmm1.net/ Isn't this an orthogonal problem to what this patch is changing? - Derek ___ 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".
Re: [FFmpeg-devel] [PATCH 1/4] libswscale: Re-factor ff_shuffle_filter_coefficients.
On Mon, Jan 10, 2022 at 03:58:33PM +0100, Alan Kelly wrote:
> Make the code more readable, follow the style guide and propagate memory
> allocation errors.
Cosmetics and bugfixes should not be in the same patch
> ---
> libswscale/swscale_internal.h | 2 +-
> libswscale/utils.c| 68 ---
> 2 files changed, 40 insertions(+), 30 deletions(-)
>
> diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
> index 3a78d95ba6..26d28d42e6 100644
> --- a/libswscale/swscale_internal.h
> +++ b/libswscale/swscale_internal.h
> @@ -1144,5 +1144,5 @@ void ff_sws_slice_worker(void *priv, int jobnr, int
> threadnr,
> #define MAX_LINES_AHEAD 4
>
> //shuffle filter and filterPos for hyScale and hcScale filters in avx2
> -void ff_shuffle_filter_coefficients(SwsContext *c, int* filterPos, int
> filterSize, int16_t *filter, int dstW);
> +int ff_shuffle_filter_coefficients(SwsContext *c, int* filterPos, int
> filterSize, int16_t *filter, int dstW);
> #endif /* SWSCALE_SWSCALE_INTERNAL_H */
> diff --git a/libswscale/utils.c b/libswscale/utils.c
> index c5ea8853d5..52f07e1661 100644
> --- a/libswscale/utils.c
> +++ b/libswscale/utils.c
> @@ -278,39 +278,47 @@ static const FormatEntry format_entries[] = {
> [AV_PIX_FMT_P416LE] = { 1, 1 },
> };
>
> -void ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos, int
> filterSize, int16_t *filter, int dstW){
> +int ff_shuffle_filter_coefficients(SwsContext *c, int *filterPos,
> + int filterSize, int16_t *filter,
> + int dstW)
> +{
> #if ARCH_X86_64
> -int i, j, k, l;
> +int i = 0, j = 0, k = 0;
why?
they are set when used if iam not mistaken
> int cpu_flags = av_get_cpu_flags();
> +if (!filter || dstW % 16 != 0) return 0;
please add \n also a comment what the dstW & 16 case exactly does and why
[...]
> int sws_isSupportedInput(enum AVPixelFormat pix_fmt)
> @@ -1836,7 +1844,8 @@ av_cold int sws_init_context(SwsContext *c, SwsFilter
> *srcFilter,
> get_local_pos(c, 0, 0, 0),
> get_local_pos(c, 0, 0, 0))) < 0)
> goto fail;
> -ff_shuffle_filter_coefficients(c, c->hLumFilterPos,
> c->hLumFilterSize, c->hLumFilter, dstW);
> +if ((ret = ff_shuffle_filter_coefficients(c, c->hLumFilterPos,
> c->hLumFilterSize, c->hLumFilter, dstW)) != 0)
> +goto nomem;
This is confusing as ret is never used, also error codes are <0
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Those who are best at talking, realize last or never when they are wrong.
signature.asc
Description: PGP signature
___
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".
Re: [FFmpeg-devel] [PATCH v2] avfilter/adelay: Add command support
Is this being reviewed?
št 20. 1. 2022 o 12:38 David Lacko napísal(a):
> Adds command 'delays' to the adelay filter.
> This command accepts same values as the option with one difference, to
> apply
> delay to all channels prefix 'all:' to the argument is accepted.
>
> Signed-off-by: David Lacko
> ---
> libavfilter/af_adelay.c | 182 ++--
> 1 file changed, 156 insertions(+), 26 deletions(-)
>
> diff --git a/libavfilter/af_adelay.c b/libavfilter/af_adelay.c
> index ed8a8ae739..382be3dca2 100644
> --- a/libavfilter/af_adelay.c
> +++ b/libavfilter/af_adelay.c
> @@ -31,6 +31,7 @@ typedef struct ChanDelay {
> int64_t delay;
> size_t delay_index;
> size_t index;
> +unsigned int samples_size;
> uint8_t *samples;
> } ChanDelay;
>
> @@ -48,13 +49,14 @@ typedef struct AudioDelayContext {
>
> void (*delay_channel)(ChanDelay *d, int nb_samples,
>const uint8_t *src, uint8_t *dst);
> +int (*resize_channel_samples)(ChanDelay *d, int64_t new_delay);
> } AudioDelayContext;
>
> #define OFFSET(x) offsetof(AudioDelayContext, x)
> #define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>
> static const AVOption adelay_options[] = {
> -{ "delays", "set list of delays for each channel", OFFSET(delays),
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, A },
> +{ "delays", "set list of delays for each channel", OFFSET(delays),
> AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, A | AV_OPT_FLAG_RUNTIME_PARAM },
> { "all","use last available delay for remained channels",
> OFFSET(all), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, A },
> { NULL }
> };
> @@ -96,11 +98,93 @@ DELAY(s32, int32_t, 0)
> DELAY(flt, float, 0)
> DELAY(dbl, double, 0)
>
> +#define CHANGE_DELAY(name, type, fill)
> \
> +static int resize_samples_## name ##p(ChanDelay *d, int64_t new_delay)
> \
> +{
>\
> +type *samples;
> \
> +
> \
> +if (new_delay == d->delay) {
> \
> +return 0;
>\
> +}
>\
> +
> \
> +if (new_delay == 0) {
>\
> +av_freep(&d->samples);
> \
> +d->samples_size = 0;
> \
> +d->delay = 0;
>\
> +d->index = 0;
>\
> +d->delay_index = 0;
>\
> +return 0;
>\
> +}
>\
> +
> \
> +samples = (type *) av_fast_realloc(d->samples, &d->samples_size,
> new_delay * sizeof(type)); \
> +if (!samples) {
>\
> +return AVERROR(ENOMEM);
>\
> +}
>\
> +
> \
> +if (new_delay < d->delay) {
>\
> +if (d->index > new_delay) {
>\
> +d->index -= new_delay;
> \
> +memmove(samples, &samples[new_delay], d->index *
> sizeof(type)); \
> +d->delay_index = new_delay;
>\
> +} else if (d->delay_index > d->index) {
>\
> +memmove(&samples[d->index],
> &samples[d->index+(d->delay-new_delay)],\
> +(new_delay - d->index) * sizeof(type));
>\
> +d->delay_index -= d->delay - new_delay;
>\
> +}
>\
> +} else {
> \
> +size_t block_size;
> \
> +if (d->delay_index >= d->delay) {
>\
> +block_size = (d->delay - d->index) * sizeof(type);
> \
> +memmove(&samples[d->index+(new_delay - d->delay)],
> &samples[d->index], block_size); \
> +d->delay_index = new_delay;
>\
> +} else {
> \
> +d->delay_index += new_delay - d->delay;
>\
> +}
>\
> +block_size = (new_delay - d->delay) * sizeof(type);
>\
> +memset(&samples[d->index], fill, block_size);
>\
> +}
>\
> +d->delay = new_delay;
>\
> +d->samples = (void *) samples;
>
[FFmpeg-devel] [PATCH v2 2/2] lavc/aarch64: add hevc epel assembly
Thanks: Rafal Dabrowa
---
libavcodec/aarch64/Makefile |3 +-
libavcodec/aarch64/hevcdsp_epel_neon.S| 2501 +
libavcodec/aarch64/hevcdsp_init_aarch64.c | 52 +
3 files changed, 2555 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/aarch64/hevcdsp_epel_neon.S
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 8592692479..ebedc03bfa 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -61,7 +61,8 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) +=
aarch64/vp9itxfm_16bpp_neon.o \
aarch64/vp9lpf_neon.o
\
aarch64/vp9mc_16bpp_neon.o
\
aarch64/vp9mc_neon.o
-NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o
\
+NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_epel_neon.o
\
+ aarch64/hevcdsp_idct_neon.o
\
aarch64/hevcdsp_init_aarch64.o
\
aarch64/hevcdsp_qpel_neon.o
\
aarch64/hevcdsp_sao_neon.o
diff --git a/libavcodec/aarch64/hevcdsp_epel_neon.S
b/libavcodec/aarch64/hevcdsp_epel_neon.S
new file mode 100644
index 00..bbf93c3d6a
--- /dev/null
+++ b/libavcodec/aarch64/hevcdsp_epel_neon.S
@@ -0,0 +1,2501 @@
+/* -*-arm64-*-
+ * vim: syntax=arm64asm
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+#define MAX_PB_SIZE 64
+
+function ff_hevc_put_hevc_pel_pixels4_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2)
+1: ld1{v0.s}[0], [x1], x2
+ushll v4.8h, v0.8b, #6
+subsw3, w3, #1
+st1{v4.d}[0], [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels6_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2 - 8)
+1: ld1{v0.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+st1{v4.d}[0], [x0], #8
+subsw3, w3, #1
+st1{v4.s}[2], [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels8_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2)
+1: ld1{v0.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+subsw3, w3, #1
+st1{v4.8h}, [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels12_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2 - 16)
+1: ld1{v0.8b, v1.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+st1{v4.8h}, [x0], #16
+ushll v5.8h, v1.8b, #6
+subsw3, w3, #1
+st1{v5.d}[0], [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels16_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2)
+1: ld1{v0.8b, v1.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+ushll v5.8h, v1.8b, #6
+subsw3, w3, #1
+st1{v4.8h, v5.8h}, [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels24_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2)
+1: ld1{v0.8b-v2.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+ushll v5.8h, v1.8b, #6
+ushll v6.8h, v2.8b, #6
+subsw3, w3, #1
+st1{v4.8h-v6.8h}, [x0], x7
+b.ne1b
+ret
+endfunc
+
+function ff_hevc_put_hevc_pel_pixels32_8_neon, export=1
+mov x7, #(MAX_PB_SIZE * 2)
+1: ld1{v0.8b-v3.8b}, [x1], x2
+ushll v4.8h, v0.8b, #6
+ushll v5.8h, v1.8b, #6
+ushll v6.8h, v2.8b, #6
+ushll v7.8h, v3.8b, #6
+subsw3, w3, #1
+st
[FFmpeg-devel] [PATCH v2 1/2] lavc/aarch64: add hevc qpel assembly
Thanks: Rafal Dabrowa
---
libavcodec/aarch64/Makefile |1 +
libavcodec/aarch64/hevcdsp_init_aarch64.c | 67 +
libavcodec/aarch64/hevcdsp_qpel_neon.S| 2799 +
3 files changed, 2867 insertions(+)
create mode 100644 libavcodec/aarch64/hevcdsp_qpel_neon.S
Had trouble testing on a Linux machine as well, but have a workflow
setup for that now so should be easier in the future. Passes FATE on
both macOS and Linux.
diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 954461f81d..8592692479 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -63,4 +63,5 @@ NEON-OBJS-$(CONFIG_VP9_DECODER) +=
aarch64/vp9itxfm_16bpp_neon.o \
aarch64/vp9mc_neon.o
NEON-OBJS-$(CONFIG_HEVC_DECODER)+= aarch64/hevcdsp_idct_neon.o
\
aarch64/hevcdsp_init_aarch64.o
\
+ aarch64/hevcdsp_qpel_neon.o
\
aarch64/hevcdsp_sao_neon.o
diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 1e40be740c..3e5d85247e 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -58,7 +58,63 @@ void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst,
uint8_t *_src,
int16_t *sao_offset_val, int sao_left_class,
int width, int height);
+#define NEON8_FNPROTO(fn, args) \
+void ff_hevc_put_hevc_##fn##4_8_neon args; \
+void ff_hevc_put_hevc_##fn##6_8_neon args; \
+void ff_hevc_put_hevc_##fn##8_8_neon args; \
+void ff_hevc_put_hevc_##fn##12_8_neon args; \
+void ff_hevc_put_hevc_##fn##16_8_neon args; \
+void ff_hevc_put_hevc_##fn##24_8_neon args; \
+void ff_hevc_put_hevc_##fn##32_8_neon args; \
+void ff_hevc_put_hevc_##fn##48_8_neon args; \
+void ff_hevc_put_hevc_##fn##64_8_neon args; \
+NEON8_FNPROTO(qpel_h, (int16_t *dst,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_v, (int16_t *dst,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_hv, (int16_t *dst,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_uni_h, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_uni_v, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_uni_hv, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_bi_h, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride, int16_t *src2,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_bi_v, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride, int16_t *src2,
+int height, intptr_t mx, intptr_t my, int width));
+
+NEON8_FNPROTO(qpel_bi_hv, (uint8_t *dst, ptrdiff_t dststride,
+uint8_t *src, ptrdiff_t srcstride, int16_t *src2,
+int height, intptr_t mx, intptr_t my, int width));
+
+#define NEON8_FNASSIGN(member, v, h, fn) \
+member[1][v][h] = ff_hevc_put_hevc_##fn##4_8_neon; \
+member[2][v][h] = ff_hevc_put_hevc_##fn##6_8_neon; \
+member[3][v][h] = ff_hevc_put_hevc_##fn##8_8_neon; \
+member[4][v][h] = ff_hevc_put_hevc_##fn##12_8_neon; \
+member[5][v][h] = ff_hevc_put_hevc_##fn##16_8_neon; \
+member[6][v][h] = ff_hevc_put_hevc_##fn##24_8_neon; \
+member[7][v][h] = ff_hevc_put_hevc_##fn##32_8_neon; \
+member[8][v][h] = ff_hevc_put_hevc_##fn##48_8_neon; \
+member[9][v][h] = ff_hevc_put_hevc_##fn##64_8_neon;
av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
{
@@ -80,6 +136,17 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c,
const int bit_depth)
// for the current size, but if enabled for bigger sizes, the cases
// of non-multiple of 8 seem to arise.
//c->sao_band_filter[0] = ff_hevc_sao_band_filter_8x8_8_neon;
+
+NEON8_FNASSIGN(c->put_hevc_qpel, 0, 1, qpel_h);
+NEON8_FNASSIGN(c->put_hevc_qpel, 1, 0, qpel_v);
+NEON8_FNASSIGN(c->put_hevc_qpel, 1, 1, qpel_hv);
+NEON8_FNASSIGN(c->put_hevc_qpel_uni, 0, 1, qpel_uni_h);
+NEON8_FNASSIGN(c->put_hevc_qpel_uni, 1, 0, qpel_uni_v);
+NEON8_FNASSIGN(c->put_hevc_qpel_uni, 1, 1, qpel_uni_hv);
+NEON8_FNASSIGN(c->put_hevc_qpel_bi, 0, 1,
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 13:33, Martin Storsjö wrote: On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Sorry, need to correct myself. It is indeed localized I was just lacking the language pack… For example in german it is: Microsoft (R) C/C++-Optimierungscompiler Version 19.30.30709 für x64 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Oh, thanks for that! I presume that this also could break the other existing check for armasm too? If you run e.g. "vsdevcmd -host_arch=x64 -arch=arm64" and then "armasm64", what does that print? Interestingly that one does not seem localized: C:\Program Files\Microsoft Visual Studio\2022\Community>armasm64 Microsoft (R) ARM Macro Assembler Version 14.30.30709.0 for 64 bits Copyright (C) Microsoft Corporation. All rights reserved. That's interesting! I tried to have a look at what e.g. meson does for detection. It doesn't look that much at the output, but first detects clang-cl specifically, then plain clang, then moves on to MSVC itself (matching only 'Microsoft'). Meson does, however, check a longer regex for identifying and disambiguating the 'rc' tool from windres. Is 'rc' localized? // Martin ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On 3 Feb 2022, at 13:33, Martin Storsjö wrote: On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Sorry, need to correct myself. It is indeed localized I was just lacking the language pack… For example in german it is: Microsoft (R) C/C++-Optimierungscompiler Version 19.30.30709 für x64 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Oh, thanks for that! I presume that this also could break the other existing check for armasm too? If you run e.g. "vsdevcmd -host_arch=x64 -arch=arm64" and then "armasm64", what does that print? Interestingly that one does not seem localized: C:\Program Files\Microsoft Visual Studio\2022\Community>vsdevcmd -host_arch=x64 -arch=arm64 ** ** Visual Studio 2022 Developer Command Prompt v17.0.5 ** Copyright (c) 2021 Microsoft Corporation ** C:\Program Files\Microsoft Visual Studio\2022\Community>armasm64 Microsoft (R) ARM Macro Assembler Version 14.30.30709.0 for 64 bits Copyright (C) Microsoft Corporation. All rights reserved. error A2033: missing input source file Usage: armasm [] sourcefile objectfile armasm [] -o objectfile sourcefile armasm -h for help // Martin ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On Thu, 3 Feb 2022, Marvin Scholz wrote: On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Sorry, need to correct myself. It is indeed localized I was just lacking the language pack… For example in german it is: Microsoft (R) C/C++-Optimierungscompiler Version 19.30.30709 für x64 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. Oh, thanks for that! I presume that this also could break the other existing check for armasm too? If you run e.g. "vsdevcmd -host_arch=x64 -arch=arm64" and then "armasm64", what does that print? // Martin ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: On Thu, 3 Feb 2022, Kacper Michajlow wrote: On Wed, 26 Jan 2022 at 15:00, Martin Storsjö wrote: Hi, On Sat, 22 Jan 2022, Kacper Michajłow wrote: LLVM tools print installation path upon execution. If one uses LLVM tools bundled with Microsoft Visual Studio installation, they would be incorrectly detected as Microsoft's ones. Signed-off-by: Kacper Michajłow --- configure | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) While the patch description seems to make sense, I wanted to try it out to see the practical effect for myself, and I fail to observe any difference. Can you provide your exact configure command line you use, where it makes a difference? I tried with "--cc=clang-cl --ld=lld-link --toolchain=msvc" and that works just as fine before this patch. In particular, the commands that you adjust run "$_cc -nologo-" and grep for "Microsoft" in the output of that. When I run that with clang-cl, it doesn't print a string containing "Microsoft". // Martin Hi, Yes you are right. In case of CC it doesn't change anything. clang-cl prints installation dir only with `-v`. The main thing this patch fixes is `--ar=llvm-ar` where it is mistaken for lib.exe and used with wrong parameters. While fixing this I figured to make CC check also more strict, because at some point it could be a problem. Sync all of them to have same style as one that was already there Oh, ok, with the reference to llvm-ar, I see what it fixes. Thanks! The reference to llvm-ar absolutely needs to be in the patch description then. I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Sorry, need to correct myself. It is indeed localized I was just lacking the language pack… For example in german it is: Microsoft (R) C/C++-Optimierungscompiler Version 19.30.30709 für x64 Copyright (C) Microsoft Corporation. Alle Rechte vorbehalten. - Hendrik ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On 3 Feb 2022, at 12:55, Hendrik Leppkes wrote: On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: On Thu, 3 Feb 2022, Kacper Michajlow wrote: On Wed, 26 Jan 2022 at 15:00, Martin Storsjö wrote: Hi, On Sat, 22 Jan 2022, Kacper Michajłow wrote: LLVM tools print installation path upon execution. If one uses LLVM tools bundled with Microsoft Visual Studio installation, they would be incorrectly detected as Microsoft's ones. Signed-off-by: Kacper Michajłow --- configure | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) While the patch description seems to make sense, I wanted to try it out to see the practical effect for myself, and I fail to observe any difference. Can you provide your exact configure command line you use, where it makes a difference? I tried with "--cc=clang-cl --ld=lld-link --toolchain=msvc" and that works just as fine before this patch. In particular, the commands that you adjust run "$_cc -nologo-" and grep for "Microsoft" in the output of that. When I run that with clang-cl, it doesn't print a string containing "Microsoft". // Martin Hi, Yes you are right. In case of CC it doesn't change anything. clang-cl prints installation dir only with `-v`. The main thing this patch fixes is `--ar=llvm-ar` where it is mistaken for lib.exe and used with wrong parameters. While fixing this I figured to make CC check also more strict, because at some point it could be a problem. Sync all of them to have same style as one that was already there Oh, ok, with the reference to llvm-ar, I see what it fixes. Thanks! The reference to llvm-ar absolutely needs to be in the patch description then. I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. Just tested this and it does not seem to be translated for me, at least in the x86 Native Tools Command Prompt. - Hendrik ___ 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". ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On Thu, Feb 3, 2022 at 12:34 PM Martin Storsjö wrote: > > On Thu, 3 Feb 2022, Kacper Michajlow wrote: > > > On Wed, 26 Jan 2022 at 15:00, Martin Storsjö wrote: > >> > >> Hi, > >> > >> On Sat, 22 Jan 2022, Kacper Michajłow wrote: > >> > >>> LLVM tools print installation path upon execution. If one uses LLVM > >>> tools bundled with Microsoft Visual Studio installation, they would be > >>> incorrectly detected as Microsoft's ones. > >>> > >>> Signed-off-by: Kacper Michajłow > >>> --- > >>> configure | 6 +++--- > >>> 1 file changed, 3 insertions(+), 3 deletions(-) > >> > >> While the patch description seems to make sense, I wanted to try it out to > >> see the practical effect for myself, and I fail to observe any difference. > >> > >> Can you provide your exact configure command line you use, where it makes > >> a difference? I tried with "--cc=clang-cl --ld=lld-link --toolchain=msvc" > >> and that works just as fine before this patch. > >> > >> In particular, the commands that you adjust run "$_cc -nologo-" and grep > >> for "Microsoft" in the output of that. When I run that with clang-cl, it > >> doesn't print a string containing "Microsoft". > >> > >> // Martin > > > > Hi, > > > > Yes you are right. In case of CC it doesn't change anything. clang-cl > > prints installation dir only with `-v`. The main thing this patch > > fixes is `--ar=llvm-ar` where it is mistaken for lib.exe and used with > > wrong parameters. While fixing this I figured to make CC check also > > more strict, because at some point it could be a problem. Sync all of > > them to have same style as one that was already there > > Oh, ok, with the reference to llvm-ar, I see what it fixes. Thanks! The > reference to llvm-ar absolutely needs to be in the patch description then. > > I remember that there has been some variance throughout the versions for > exactly what MSVC prints as the identification thoughout the versions, but > I think 'Microsoft.*Optimizing.*Compiler' should be safe. > I was wondering if non-english locale would translate that string, but I can't easily test that, I don't think. - Hendrik ___ 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".
Re: [FFmpeg-devel] [PATCH 2/2] libfdk-aacdec: Flush delayed samples at the end
On Fri, 21 Jan 2022, Andreas Rheinhardt wrote: Interesting: There is indeed a delay at the start (720 samples in a quick test) compared to the native AAC decoder. Furthermore, the current code is buggy, as it believes that avcodec->time_base to be the time_base of the returned AVFrames (it is in reality avcodec->pkt_timebase; just test with AAC-in-Matroska for this). I haven't tested your patches, but I have now realized that there is indeed an issue. And your patch should also fix the wrong timebase issue. Based on discussion on irc with Andreas and James, I think the conclusion was that this patch should be fine, so I'll go ahead and push it soon if there's no further comments on it. // Martin ___ 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".
Re: [FFmpeg-devel] [PATCH] configure: Fix Microsoft tools detection
On Thu, 3 Feb 2022, Kacper Michajlow wrote: On Wed, 26 Jan 2022 at 15:00, Martin Storsjö wrote: Hi, On Sat, 22 Jan 2022, Kacper Michajłow wrote: LLVM tools print installation path upon execution. If one uses LLVM tools bundled with Microsoft Visual Studio installation, they would be incorrectly detected as Microsoft's ones. Signed-off-by: Kacper Michajłow --- configure | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) While the patch description seems to make sense, I wanted to try it out to see the practical effect for myself, and I fail to observe any difference. Can you provide your exact configure command line you use, where it makes a difference? I tried with "--cc=clang-cl --ld=lld-link --toolchain=msvc" and that works just as fine before this patch. In particular, the commands that you adjust run "$_cc -nologo-" and grep for "Microsoft" in the output of that. When I run that with clang-cl, it doesn't print a string containing "Microsoft". // Martin Hi, Yes you are right. In case of CC it doesn't change anything. clang-cl prints installation dir only with `-v`. The main thing this patch fixes is `--ar=llvm-ar` where it is mistaken for lib.exe and used with wrong parameters. While fixing this I figured to make CC check also more strict, because at some point it could be a problem. Sync all of them to have same style as one that was already there Oh, ok, with the reference to llvm-ar, I see what it fixes. Thanks! The reference to llvm-ar absolutely needs to be in the patch description then. I remember that there has been some variance throughout the versions for exactly what MSVC prints as the identification thoughout the versions, but I think 'Microsoft.*Optimizing.*Compiler' should be safe. So, the patch is ok if you equip it with a more detailed commit message. Relatedly, I figured that it would be even more consistent to use --ar=llvm-lib instead of --ar=llvm-ar, when working in an MSVC style configuration, but we don't identify llvm-lib as the right kind of tool. Would you be interested in fixing that too? :-) elif $_cc 2>&1 | grep -q 'Microsoft.*ARM.*Assembler'; then just for consistency... Also I noticed that latest MSVC (19.30.30709) complains about cl : Command line warning D9035 : option 'nologo-' has been deprecated and will be removed in a future release But it doesn't affect anything, even if it were to be removed. Since banner is shown always by default, unless `-nologo`. Just a side note :) Yep - I think this has been an attempt to make sure it does get printed, even if someone passes e.g. "--cc='cl -nologo'". As long as it doesn't break, I guess it's no rush to change this. // Martin ___ 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".
Re: [FFmpeg-devel] [PATCH] ffprobe: allow side-data selection by element
On 2022-02-02 10:55 am, Gyan Doshi wrote:
Plan to push tomorrow.
Pushed as e1a14479a81f5366b95df543992a7fe637cf2dde
Gyan
On 2022-01-31 11:11 am, Gyan Doshi wrote:
At present, side data printing forces display for all levels i.e.
stream, packets and frames. This can bloat output and also force
decode of all frames in selected streams.
Now, stream_side_data[=type], packet_side_data[=type] &
frame_side_data[=type] can be used with -show_entries to specify carrier
element.
---
fftools/ffprobe.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 20582ca7ac..8a8e3de540 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -223,7 +223,7 @@ static struct section sections[] = {
[SECTION_ID_FRAME] = { SECTION_ID_FRAME, "frame",
0, { SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST,
SECTION_ID_FRAME_LOGS, -1 } },
[SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS,
"tags", SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name =
"tag", .unique_name = "frame_tags" },
[SECTION_ID_FRAME_SIDE_DATA_LIST] ={
SECTION_ID_FRAME_SIDE_DATA_LIST, "side_data_list",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 },
.element_name = "side_data", .unique_name = "frame_side_data_list" },
- [SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST,
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, -1 } },
+ [SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA,
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST,
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, -1 }, .unique_name =
"frame_side_data" },
[SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, "timecodes",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = {
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
[SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST] = {
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, "components",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA_COMPONENT, -1 } },
@@ -239,7 +239,7 @@ static struct section sections[] = {
[SECTION_ID_PACKET] = { SECTION_ID_PACKET,
"packet", 0, { SECTION_ID_PACKET_TAGS,
SECTION_ID_PACKET_SIDE_DATA_LIST, -1 } },
[SECTION_ID_PACKET_TAGS] = { SECTION_ID_PACKET_TAGS,
"tags", SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name =
"tag", .unique_name = "packet_tags" },
[SECTION_ID_PACKET_SIDE_DATA_LIST] ={
SECTION_ID_PACKET_SIDE_DATA_LIST, "side_data_list",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_PACKET_SIDE_DATA, -1 },
.element_name = "side_data", .unique_name = "packet_side_data_list" },
- [SECTION_ID_PACKET_SIDE_DATA] = {
SECTION_ID_PACKET_SIDE_DATA, "side_data", 0, { -1 } },
+ [SECTION_ID_PACKET_SIDE_DATA] = {
SECTION_ID_PACKET_SIDE_DATA, "side_data", 0, { -1 }, .unique_name =
"packet_side_data" },
[SECTION_ID_PIXEL_FORMATS] = { SECTION_ID_PIXEL_FORMATS,
"pixel_formats", SECTION_FLAG_IS_ARRAY, { SECTION_ID_PIXEL_FORMAT, -1
} },
[SECTION_ID_PIXEL_FORMAT] = { SECTION_ID_PIXEL_FORMAT,
"pixel_format", 0, { SECTION_ID_PIXEL_FORMAT_FLAGS,
SECTION_ID_PIXEL_FORMAT_COMPONENTS, -1 } },
[SECTION_ID_PIXEL_FORMAT_FLAGS] = {
SECTION_ID_PIXEL_FORMAT_FLAGS, "flags", 0, { -1 }, .unique_name =
"pixel_format_flags" },
@@ -262,7 +262,7 @@ static struct section sections[] = {
[SECTION_ID_STREAM_DISPOSITION] = {
SECTION_ID_STREAM_DISPOSITION, "disposition", 0, { -1 }, .unique_name
= "stream_disposition" },
[SECTION_ID_STREAM_TAGS] = { SECTION_ID_STREAM_TAGS,
"tags", SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name =
"tag", .unique_name = "stream_tags" },
[SECTION_ID_STREAM_SIDE_DATA_LIST] ={
SECTION_ID_STREAM_SIDE_DATA_LIST, "side_data_list",
SECTION_FLAG_IS_ARRAY, { SECTION_ID_STREAM_SIDE_DATA, -1 },
.element_name = "side_data", .unique_name = "stream_side_data_list" },
- [SECTION_ID_STREAM_SIDE_DATA] = {
SECTION_ID_STREAM_SIDE_DATA, "side_data", 0, { -1 } },
+ [SECTION_ID_STREAM_SIDE_DATA] = {
SECTION_ID_STREAM_SIDE_DATA, "side_data", 0, { -1 }, .unique_name =
"stream_side_data" },
[SECTION_ID_SUBTITLE] = { SECTION_ID_SUBTITLE,
"subtitle", 0, { -1 } },
};
___
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".
___
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".
Re: [FFmpeg-devel] [PATCH v4] avformat/hls: Implement support for using AVSEEK_FLAG_BACKWARD when seeking
> 2022年1月29日 上午4:23，Gustav Grusell 写道：
>
> Before, seeking in hls streams would always seek to the next keyframe
> after the given timestamp. With this fix, if seeking in videostream and
> AVSEEK_FLAG_BACKWARD is set, seeking will be to the first keyframe of
> the segment containing the given timestamp. This fixes #7485.
>
> Signed-off-by: Gustav Grusell
> ---
> libavformat/hls.c | 24 +---
> 1 file changed, 17 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 4568e72cb2..44afdaab42 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -1653,7 +1653,8 @@ static void
> add_metadata_from_renditions(AVFormatContext *s, struct playlist *pl
> /* if timestamp was in valid range: returns 1 and sets seq_no
> * if not: returns 0 and sets seq_no to closest segment */
> static int find_timestamp_in_playlist(HLSContext *c, struct playlist *pls,
> - int64_t timestamp, int64_t *seq_no)
> + int64_t timestamp, int64_t *seq_no,
> + int64_t *seg_start_ts)
> {
> int i;
> int64_t pos = c->first_timestamp == AV_NOPTS_VALUE ?
> @@ -1668,6 +1669,9 @@ static int find_timestamp_in_playlist(HLSContext *c,
> struct playlist *pls,
> int64_t diff = pos + pls->segments[i]->duration - timestamp;
> if (diff > 0) {
> *seq_no = pls->start_seq_no + i;
> +if (seg_start_ts) {
> +*seg_start_ts = pos;
> +}
> return 1;
> }
> pos += pls->segments[i]->duration;
> @@ -1691,7 +1695,7 @@ static int64_t select_cur_seq_no(HLSContext *c, struct
> playlist *pls)
> * playlist) and this is a complete file, find the matching segment
> * by counting durations. */
> if (pls->finished && c->cur_timestamp != AV_NOPTS_VALUE) {
> -find_timestamp_in_playlist(c, pls, c->cur_timestamp, &seq_no);
> +find_timestamp_in_playlist(c, pls, c->cur_timestamp, &seq_no, NULL);
> return seq_no;
> }
>
> @@ -2362,7 +2366,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
> int i, j;
> int stream_subdemuxer_index;
> int64_t first_timestamp, seek_timestamp, duration;
> -int64_t seq_no;
> +int64_t seq_no, seg_start_ts;
>
> if ((flags & AVSEEK_FLAG_BYTE) || (c->ctx->ctx_flags &
> AVFMTCTX_UNSEEKABLE))
> return AVERROR(ENOSYS);
> @@ -2372,8 +2376,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
>
> seek_timestamp = av_rescale_rnd(timestamp, AV_TIME_BASE,
> s->streams[stream_index]->time_base.den,
> -flags & AVSEEK_FLAG_BACKWARD ?
> -AV_ROUND_DOWN : AV_ROUND_UP);
> +AV_ROUND_DOWN);
>
> duration = s->duration == AV_NOPTS_VALUE ?
>0 : s->duration;
> @@ -2394,9 +2397,16 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
> }
> /* check if the timestamp is valid for the playlist with the
> * specified stream index */
> -if (!seek_pls || !find_timestamp_in_playlist(c, seek_pls,
> seek_timestamp, &seq_no))
> +if (!seek_pls || !find_timestamp_in_playlist(c, seek_pls,
> seek_timestamp, &seq_no, &seg_start_ts))
> return AVERROR(EIO);
>
> +if (s->streams[stream_index]->codecpar->codec_type == AVMEDIA_TYPE_VIDEO
> &&
> +flags & AVSEEK_FLAG_BACKWARD && !(flags & AVSEEK_FLAG_ANY)) {
> +/* Seeking to start of segment ensures we seek to a keyframe located
> + * before the given timestamp. */
> +seek_timestamp = seg_start_ts;
> +}
> +
> /* set segment now so we do not need to search again below */
> seek_pls->cur_seq_no = seq_no;
> seek_pls->seek_stream_index = stream_subdemuxer_index;
> @@ -2423,7 +2433,7 @@ static int hls_read_seek(AVFormatContext *s, int
> stream_index,
>
> if (pls != seek_pls) {
> /* set closest segment seq_no for playlists not handled above */
> -find_timestamp_in_playlist(c, pls, seek_timestamp,
> &pls->cur_seq_no);
> +find_timestamp_in_playlist(c, pls, seek_timestamp,
> &pls->cur_seq_no, NULL);
> /* seek the playlist to the given position without taking
> * keyframes into account since this playlist does not have the
> * specified stream where we should look for the keyframes */
> --
> 2.25.1
>
> ___
> 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".
>
LGTM
Thanks
Steven Liu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/
