Re: [FFmpeg-devel] [PATCH] decode: don't treat hwaccel->alloc_frame as always failing
On 5/16/2020 8:41 PM, comex wrote:
> Fixes regression caused by a1133db30ef07896afd96f067e5c51531a4e85ab.
>
> On my Mac, the bug seems to make `mpv --hwdec=auto` always fail with:
>
> [ffmpeg/video] h264: get_buffer() failed
> [ffmpeg] Assertion src->f->buf[0] failed at src/libavcodec/h264_picture.c:70
>
> Signed-off-by: comex
> ---
> libavcodec/decode.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 48a61d5419..3fdfb551e3 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -1889,7 +1889,8 @@ int ff_get_buffer(AVCodecContext *avctx, AVFrame
> *frame, int flags)
> if (hwaccel) {
> if (hwaccel->alloc_frame) {
> ret = hwaccel->alloc_frame(avctx, frame);
> -goto fail;
> +if (ret < 0)
> +goto fail;
This is meant to skip the get_buffer2() call. The old goto end removed
in the commit you quoted ensured that was the case, but it was mistaken
for a failure path.
Either an end label is re-added immediately after the
ff_attach_decode_data() call and used here, or the videotoolbox hwaccel
is changed to not require an AVHWAccel.alloc_frame() implementation to
being with.
> }
> } else
> avctx->sw_pix_fmt = avctx->pix_fmt;
>
___
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/url: check the result of the strrchr
> 2020年5月15日 下午6:26，Steven Liu 写道： > > > >> 2020年5月15日 下午6:01，Steven Liu 写道： >> >> because it need be check for success, is should not >> change the old way if it failure. > Change the comments: > because it need be checked for success status, it should not > change the old way if it failure. >> >> Signed-off-by: Steven Liu >> --- >> libavformat/url.c | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libavformat/url.c b/libavformat/url.c >> index 7cd9e0c705..6956f6dc10 100644 >> --- a/libavformat/url.c >> +++ b/libavformat/url.c >> @@ -182,7 +182,7 @@ void ff_make_absolute_url(char *buf, int size, const >> char *base, >> >> /* Remove the file name from the base url */ >> sep = strrchr(buf, '/'); >> -if (sep <= root) >> +if (sep && sep <= root) >> sep = root; >> >> if (sep) >> -- >> 2.25.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". > > Thanks > > Steven Liu Ping Thanks Steven Liu ___ 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] decode: don't treat hwaccel->alloc_frame as always failing
Fixes regression caused by a1133db30ef07896afd96f067e5c51531a4e85ab.
On my Mac, the bug seems to make `mpv --hwdec=auto` always fail with:
[ffmpeg/video] h264: get_buffer() failed
[ffmpeg] Assertion src->f->buf[0] failed at src/libavcodec/h264_picture.c:70
Signed-off-by: comex
---
libavcodec/decode.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 48a61d5419..3fdfb551e3 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -1889,7 +1889,8 @@ int ff_get_buffer(AVCodecContext *avctx, AVFrame *frame,
int flags)
if (hwaccel) {
if (hwaccel->alloc_frame) {
ret = hwaccel->alloc_frame(avctx, frame);
-goto fail;
+if (ret < 0)
+goto fail;
}
} else
avctx->sw_pix_fmt = avctx->pix_fmt;
--
2.26.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 1/2] avcodec/jpeg2000dec: Free packed_headers
On Sat, May 16, 2020 at 06:55:44PM +0530, Gautam Ramakrishnan wrote: > On Thu, May 14, 2020 at 2:19 AM Michael Niedermayer > wrote: > > > > Fixes: memleak > > Fixes: > > 21784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-565256551058636 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/jpeg2000dec.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c > > index 460a4ad95c8..6424ed5 100644 > > --- a/libavcodec/jpeg2000dec.c > > +++ b/libavcodec/jpeg2000dec.c > > @@ -2014,6 +2014,8 @@ static void > > jpeg2000_dec_cleanup(Jpeg2000DecoderContext *s) > > ff_jpeg2000_cleanup(comp, codsty); > > } > > av_freep(&s->tile[tileno].comp); > > +av_freep(&s->tile[tileno].packed_headers); > > +s->tile[tileno].packed_headers_size = 0; > > } > > } > > av_freep(&s->tile); > > -- > > 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". > > Seems to deallocate all data related to the packed_headers. > Looks good to me. will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope 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 2/2] avcodec/binkaudio: Check sample_rate to avoid integer overflow
On Sat, May 16, 2020 at 07:12:28PM +0200, Paul B Mahol wrote: > On 5/16/20, Michael Niedermayer wrote: > > On Mon, Apr 20, 2020 at 01:03:34AM +0200, Michael Niedermayer wrote: > >> On Sun, Apr 19, 2020 at 05:52:01PM +0200, Lynne wrote: > >> > Apr 19, 2020, 16:05 by mich...@niedermayer.cc: > >> > > >> > > Fixes: signed integer overflow: 2147483647 + 1 cannot be represented > >> > > in type 'int' > >> > > Fixes: > >> > > 19950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-5765514337189888 > >> > > > >> > > Found-by: continuous fuzzing process > >> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > >> > > Signed-off-by: Michael Niedermayer > >> > > --- > >> > > libavcodec/binkaudio.c | 3 +++ > >> > > 1 file changed, 3 insertions(+) > >> > > > >> > > diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c > >> > > index 64a08b8608..2df3dc645a 100644 > >> > > --- a/libavcodec/binkaudio.c > >> > > +++ b/libavcodec/binkaudio.c > >> > > @@ -106,6 +106,9 @@ static av_cold int decode_init(AVCodecContext > >> > > *avctx) > >> > > avctx->sample_fmt = AV_SAMPLE_FMT_FLTP; > >> > > } > >> > > > >> > > +if (sample_rate >= INT_MAX) > >> > > +return AVERROR_INVALIDDATA; > >> > > + > >> > > s->frame_len = 1 << frame_len_bits; > >> > > s->overlap_len = s->frame_len / 16; > >> > > s->block_size= (s->frame_len - s->overlap_len) * s->channels; > >> > > > >> > > >> > Did you even bother to look at the checks you added in this decoder > >> > previously? > >> > Specifically 11 lines above? > >> > > >> > > if (sample_rate > INT_MAX / avctx->channels) > >> > > return AVERROR_INVALIDDATA; > >> > > sample_rate *= avctx->channels; > >> > > >> > To start with the sample rate of the avctx is already checked in > >> > utils.c, and you > >> > still haven't cleaned up any decoders from the checks made unnecessary > >> > by you, > >> > >> The new check is needed, it overflows without: > >> libavcodec/binkaudio.c:116:37: runtime error: signed integer overflow: > >> 2147483647 + 1 cannot be represented in type 'int' > >> > >> The other check is also needed, if i remove it it still overflows > >> libavcodec/binkaudio.c:100:22: runtime error: signed integer overflow: > >> 1092624416 * 2 cannot be represented in type 'int' > >> > >> > >> > so am reminding you again to clean up the codebase by getting rid of > >> > them. > >> > At least you might get to clean the codebase for once rather than adding > >> > crap like this. > >> > > >> > So there's only the branch which I quoted that's needed to be fixed, and > >> > since there's a > >> > check there already, there's no reason to have a check here as well. > >> > >> I posted exactly this same patch in january, there was a objection, and i > >> asked > >> what was preferred instead, and pinged it multiple times over the > >> following > >> months, in february and april: > >> > >> 189192 N F 0114 15:36 To FFmpeg devel (1,6K) [FFmpeg-devel] [PATCH] > >> avcodec/binkaudio: Check sample_rate to avoid integer overflow > >> 189193 r 0114 16:04 Paul B Mahol(2,1K) └─> > >> 189194 sF 0201 16:14 To FFmpeg devel (1,7K) └─> > >> 189195 r 0201 16:17 Paul B Mahol(1,3K) └─> > >> 189196 rsF 0201 23:48 To FFmpeg devel (2,6K) └─> > >> 189197 rs 0209 21:28 Michael Niederm (2,9K) └─> > >> 189198 rsF 0404 23:38 To FFmpeg devel (2,8K) └─> > >> 189199 sF 0407 23:17 To FFmpeg devel (3,1K) └─> > >> > >> but i failed to get a reply, so i tried reposting it > >> > >> So, if the patch is still not liked, can you explain what do you > >> prefer ? > >> > >> i can put the sample_rate >= INT_MAX check in generic code but it > >> is specific to this decoder it wont help anything else > >> > >> i can put a more aggressive check like sample_rate * channels > > >> MAX_CHANNEL_SAMPLES > >> in generic code, that will of course block some otherwise supported cases > >> > >> or we can have checks just for what is not supported > >> > >> or we can extend the code to support a wider range where it is possible > >> > > > >> Just say what you prefer, i dont mind at all what it is, i just want the > >> issue fixed its already so many months open ... > > > > ping > > id like to fix ossfuzz issue 19950 > > Use (sample_rate + 1LL) / 2 ? will apply an adjusted patch Thanks! [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Concerning the gods, I have no means of knowing whether they exist or not or of what sort they may be, because of the obscurity of the subject, and the brevity of human life -- Protagoras 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] swscale: fix NEON hscale init
On 16/05/2020 11:50, Carl Eugen Hoyos wrote:
Am Fr., 15. Mai 2020 um 12:27 Uhr schrieb Josh de Kock :
On 08/05/2020 12:25, Michael Niedermayer wrote:
On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:
The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used.
Signed-off-by: Josh de Kock
---
libswscale/aarch64/swscale.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index 54a3beabe8..eecbea88ca 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
int cpu_flags = av_get_cpu_flags();
if (have_neon(cpu_flags)) {
-if (c->srcBpc == 8 && c->dstBpc <= 14) {
+if (c->srcBpc == 8 && c->dstBpc <= 14 &&
+(c->hLumFilterSize % 8) == 0 &&
+(c->hChrFilterSize % 8) == 0)
+{
c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
}
isnt filterAlign set to 8 when neon is available ?
Discussed on IRC. Pushed with set.
Could you give a very short explanation on why the comment
was not relevant?
At the moment filterAlign is set to 8 but in the future when extra NEON
assembly for specific sizes is added they will need to have checks here too.
The immediate use-case for this change is making the hscale checkasm
test easier and without NEON specific edge-cases (x86 already has these
guards).
Michael then said the extra check was fine here. The checkasm test
breaks on altivec (I was unable to test this) but I'm discussing with
Martin if there's a better way to do this, these checks are likely to be
reverted with a different solution implemented.
--
Josh
___
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] libavformat/flacdec: Workaround for truncated metadata picture size
Mattias Wadman:
> lavf flacenc could previously write truncated metadata picture size if
> the picture data did not fit in 24 bits. Detect this by truncting the
> size found inside the picture block and if it matches the block size
> use it and read rest of picture data.
>
> Also only enable this workaround flac files and not ogg files with flac
> METADATA_BLOCK_PICTURE comment.
>
> flacenc was fixed in e447a4d112bcfee10126c54eb4481fa8712957c8
> before the fix a broken flac for reproduction could be generated with:
> ffmpeg -f lavfi -i sine -f lavfi -i color=red:size=2400x2400 -map 0:0 -map
> 1:0 -c:v:0 bmp -disposition:1 attached_pic -t 1 test.flac
>
> Fixes ticket 6333
> ---
> libavformat/flac_picture.c | 35 +++
> libavformat/flac_picture.h | 2 +-
> libavformat/flacdec.c| 2 +-
> libavformat/oggparsevorbis.c | 2 +-
> 4 files changed, 30 insertions(+), 11 deletions(-)
>
> diff --git a/libavformat/flac_picture.c b/libavformat/flac_picture.c
> index 81ddf80465..61277e9dee 100644
> --- a/libavformat/flac_picture.c
> +++ b/libavformat/flac_picture.c
> @@ -27,7 +27,7 @@
> #include "id3v2.h"
> #include "internal.h"
>
> -int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size)
> +int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size,
> int truncate_workaround)
> {
> const CodecMime *mime = ff_id3v2_mime_tags;
> enum AVCodecID id = AV_CODEC_ID_NONE;
> @@ -36,7 +36,8 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf,
> int buf_size)
> GetByteContext g;
> AVStream *st;
> int width, height, ret = 0;
> -unsigned int len, type;
> +unsigned int type;
> +uint32_t len, left, trunclen = 0;
>
> if (buf_size < 34) {
> av_log(s, AV_LOG_ERROR, "Attached picture metadata block too
> short\n");
> @@ -114,16 +115,34 @@ int ff_flac_parse_picture(AVFormatContext *s, uint8_t
> *buf, int buf_size)
>
> /* picture data */
> len = bytestream2_get_be32u(&g);
> -if (len <= 0 || len > bytestream2_get_bytes_left(&g)) {
> -av_log(s, AV_LOG_ERROR, "Attached picture metadata block too
> short\n");
> -if (s->error_recognition & AV_EF_EXPLODE)
> -ret = AVERROR_INVALIDDATA;
> -goto fail;
> +
> +left = bytestream2_get_bytes_left(&g);
> +if (len <= 0 || len > left) {
> +// Workaround lavf flacenc bug that allowed writing truncated
> metadata picture block size if
I have not found the typical lavf metadata in the file from #6333, so it
seems we are not the only tool that created such out-of-spec files. This
should be reflected in the comment.
> +// picture size did not fit in 24 bits
> +if (truncate_workaround && len > left && (len & 0xff) == left) {
There should be a way to disable this workaround; after all, there'd be
no remedy if the 32bit len field is bogus. Maybe check
strict_std_compliance for being >= FF_COMPLIANCE_STRICT.
> +av_log(s, AV_LOG_INFO, "Correcting truncated metadata picture
> size from %d to %d\n", left, len);
> +trunclen = len - left;
> +} else {
> +av_log(s, AV_LOG_ERROR, "Attached picture metadata block too
> short\n");
> +if (s->error_recognition & AV_EF_EXPLODE)
> +ret = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> }
> if (!(data = av_buffer_alloc(len + AV_INPUT_BUFFER_PADDING_SIZE))) {
av_buffer_alloc() takes an int as its size argument. len +
AV_INPUT_BUFFER_PADDING_SIZE can be anything here; it can be positive or
negative. It can even be wrapped around. You need to check len for being
< INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE. I wonder whether it should not
be restricted even more (otherwise it would be easy to force an
allocation of close to 2GiB).
> RETURN_ERROR(AVERROR(ENOMEM));
> }
> -bytestream2_get_bufferu(&g, data->data, len);
> +
> +if (trunclen == 0) {
> +bytestream2_get_bufferu(&g, data->data, len);
> +} else {
> +// If truncation was detect copy all data from block and read
> missing bytes
was detected
> +// not included in the block size
> +bytestream2_get_bufferu(&g, data->data, left);
> +if (avio_read(s->pb, data->data + len - trunclen, trunclen) <
> trunclen)
> +RETURN_ERROR(AVERROR_INVALIDDATA);
> +}
> memset(data->data + len, 0, AV_INPUT_BUFFER_PADDING_SIZE);
>
> if (AV_RB64(data->data) == PNGSIG)
> diff --git a/libavformat/flac_picture.h b/libavformat/flac_picture.h
> index 4374b6f4f6..61fd0c8806 100644
> --- a/libavformat/flac_picture.h
> +++ b/libavformat/flac_picture.h
> @@ -26,6 +26,6 @@
>
> #define RETURN_ERROR(code) do { ret = (code); goto fail; } while (0)
>
> -int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size);
> +int ff_flac_parse_picture(AVFormatContext *s, uint8_t *buf, int buf_size,
> int truncate_workaround);
[FFmpeg-devel] [PATCH] fftools/ffmpeg: add new abort_on flag which aborts if there is a stream which received no packets
Signed-off-by: Marton Balint
---
doc/ffmpeg.texi | 2 ++
fftools/ffmpeg.c | 4
fftools/ffmpeg.h | 3 ++-
fftools/ffmpeg_opt.c | 5 +++--
4 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index ed437bb16f..76fafdcf7e 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1721,6 +1721,8 @@ Stop and abort on various conditions. The following flags
are available:
@table @option
@item empty_output
No packets were passed to the muxer, the output is empty.
+@item empty_output_stream
+No packets were passed to the muxer in some of the output streams.
@end table
@item -xerror (@emph{global})
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index f697460a30..cccf12e376 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4713,6 +4713,10 @@ static int transcode(void)
av_freep(&ost->enc_ctx->stats_in);
}
total_packets_written += ost->packets_written;
+if (!ost->packets_written && (abort_on_flags &
ABORT_ON_FLAG_EMPTY_OUTPUT_STREAM)) {
+av_log(NULL, AV_LOG_FATAL, "Empty output on stream %d.\n", i);
+exit_program(1);
+}
}
if (!total_packets_written && (abort_on_flags &
ABORT_ON_FLAG_EMPTY_OUTPUT)) {
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index 38205a1a13..828cb2a4ff 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -430,7 +430,8 @@ enum forced_keyframes_const {
FKF_NB
};
-#define ABORT_ON_FLAG_EMPTY_OUTPUT (1 << 0)
+#define ABORT_ON_FLAG_EMPTY_OUTPUT(1 << 0)
+#define ABORT_ON_FLAG_EMPTY_OUTPUT_STREAM (1 << 1)
extern const char *const forced_keyframes_const_names[];
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 60bb437ea7..2eb4e1c973 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -262,8 +262,9 @@ static AVDictionary *strip_specifiers(AVDictionary *dict)
static int opt_abort_on(void *optctx, const char *opt, const char *arg)
{
static const AVOption opts[] = {
-{ "abort_on", NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 },
INT64_MIN, INT64_MAX, .unit = "flags" },
-{ "empty_output", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
ABORT_ON_FLAG_EMPTY_OUTPUT },.unit = "flags" },
+{ "abort_on" , NULL, 0, AV_OPT_TYPE_FLAGS, { .i64 = 0 },
INT64_MIN, INT64_MAX, .unit = "flags" },
+{ "empty_output" , NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
ABORT_ON_FLAG_EMPTY_OUTPUT}, .unit = "flags" },
+{ "empty_output_stream", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
ABORT_ON_FLAG_EMPTY_OUTPUT_STREAM }, .unit = "flags" },
{ NULL },
};
static const AVClass class = {
--
2.16.4
___
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: Add Dynacolor MVC Demuxer
Tom Needham: > Please ignore my previous email as it was sent in error. > > This demuxer adds support for demuxing files in the Dynacolor format > such as the sample located at: > > http://samples.ffmpeg.org/camera-dvr/dynacolor/dynacolor-camera-sample > > However some decode errors are showing on the resulting MPEG4 stream. > I don't know whether this is a bug with the demuxer or the file as there is > only one sample > but the output results in a 8 second mp4 file that is playable in VLC media > player. > > I believe that i have addressed the comments that I recieved in the previous > review. > Also i have managed to improve the efficiency of the demuxer and also made > the probe function more useful. > > Thanks > Tom > > Signed-off-by: Tom Needham <06needh...@gmail.com> > --- > Changelog| 1 + > doc/general.texi | 1 + > libavformat/Makefile | 1 + > libavformat/allformats.c | 1 + > libavformat/dynacolor.c | 411 +++ > libavformat/dynacolor.h | 209 > libavformat/version.h| 2 +- > 7 files changed, 625 insertions(+), 1 deletion(-) > create mode 100644 libavformat/dynacolor.c > create mode 100644 libavformat/dynacolor.h > > diff --git a/Changelog b/Changelog > index 711861bda9..79d39494c9 100644 > --- a/Changelog > +++ b/Changelog > @@ -54,6 +54,7 @@ version : > - DERF demuxer > - CRI HCA decoder > - CRI HCA demuxer > +- Dynacolor MVC Demuxer > > > version 4.2: > diff --git a/doc/general.texi b/doc/general.texi > index 752618a00b..4eb4716d87 100644 > --- a/doc/general.texi > +++ b/doc/general.texi > @@ -452,6 +452,7 @@ library: > @item DXA @tab @tab X > @tab This format is used in the non-Windows version of the Feeble Files > game and different game cutscenes repacked for use with ScummVM. > +@item Dynacolor MVC @tab @tab X > @item Electronic Arts cdata @tab@tab X > @item Electronic Arts Multimedia @tab@tab X > @tab Used in various EA games; files have extensions like WVE and UV2. > diff --git a/libavformat/Makefile b/libavformat/Makefile > index 8fd0d43721..4d1ca8b7ed 100644 > --- a/libavformat/Makefile > +++ b/libavformat/Makefile > @@ -169,6 +169,7 @@ OBJS-$(CONFIG_DV_MUXER) += dvenc.o > OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o > OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o > OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o > +OBJS-$(CONFIG_DYNACOLOR_DEMUXER) += dynacolor.o > OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o > OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o > OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o > diff --git a/libavformat/allformats.c b/libavformat/allformats.c > index 39d2c352f5..50f3926b05 100644 > --- a/libavformat/allformats.c > +++ b/libavformat/allformats.c > @@ -131,6 +131,7 @@ extern AVOutputFormat ff_dv_muxer; > extern AVInputFormat ff_dvbsub_demuxer; > extern AVInputFormat ff_dvbtxt_demuxer; > extern AVInputFormat ff_dxa_demuxer; > +extern AVInputFormat ff_dynacolor_demuxer; > extern AVInputFormat ff_ea_demuxer; > extern AVInputFormat ff_ea_cdata_demuxer; > extern AVInputFormat ff_eac3_demuxer; > diff --git a/libavformat/dynacolor.c b/libavformat/dynacolor.c > new file mode 100644 > index 00..05a32b5299 > --- /dev/null > +++ b/libavformat/dynacolor.c > @@ -0,0 +1,411 @@ > +/* > + * Dynacolor MVC Demuxer > + * Copyright (c) 2020 Tom Needham > + * > + * 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 > +#include "avformat.h" > +#include "internal.h" > +#include "dynacolor.h" > +#include "libavutil/channel_layout.h" > +#include "libavutil/intreadwrite.h" > +#include "libavutil/mathematics.h" > +#include "libavutil/timecode.h" > +#include "libavutil/avassert.h" There is no assert in your patch. > + > +int ff_dyna_read_packet_header(AVFormatContext *ctx, AVIOContext *pb, > unsigned char *pes_data, DynacolorPesHeader *pes, > + unsigned int *size, time_t *time, DynacolorHeader > *header, unsigned int *basicIdx_H, unsigned int *basicIdx_L, > + unsigned cha
[FFmpeg-devel] [PATCH 1/2] avfilter/vf_colorkey: fix formula for calculation of difference
Also fixes colorhold filtering.
Signed-off-by: Paul B Mahol
---
libavfilter/vf_colorkey.c | 2 +-
tests/ref/fate/ffmpeg-filter_colorkey | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 7af426a61e..0ac847c633 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -45,7 +45,7 @@ static uint8_t do_colorkey_pixel(ColorkeyContext *ctx,
uint8_t r, uint8_t g, uin
int dg = (int)g - ctx->colorkey_rgba[1];
int db = (int)b - ctx->colorkey_rgba[2];
-double diff = sqrt((dr * dr + dg * dg + db * db) / (255.0 * 255.0));
+double diff = sqrt((dr * dr + dg * dg + db * db) / (255.0 * 255.0 * 3.0));
if (ctx->blend > 0.0001) {
return av_clipd((diff - ctx->similarity) / ctx->blend, 0.0, 1.0) *
255.0;
diff --git a/tests/ref/fate/ffmpeg-filter_colorkey
b/tests/ref/fate/ffmpeg-filter_colorkey
index 490a0f9aa6..25c3fc0912 100644
--- a/tests/ref/fate/ffmpeg-filter_colorkey
+++ b/tests/ref/fate/ffmpeg-filter_colorkey
@@ -3,13 +3,13 @@
#codec_id 0: rawvideo
#dimensions 0: 720x576
#sar 0: 0/1
-0, 0, 0,1, 622080, 0x78efb628
-0, 1, 1,1, 622080, 0x641f2564
-0, 2, 2,1, 622080, 0x348f25c3
-0, 3, 3,1, 622080, 0x6afc485a
-0, 4, 4,1, 622080, 0xe949107f
-0, 5, 5,1, 622080, 0x171716e5
-0, 6, 6,1, 622080, 0x2985a01f
-0, 7, 7,1, 622080, 0xc5ddabd7
-0, 8, 8,1, 622080, 0xb4dd2b7f
-0, 9, 9,1, 622080, 0x6e75ba82
+0, 0, 0,1, 622080, 0x5775bb12
+0, 1, 1,1, 622080, 0x84d8395a
+0, 2, 2,1, 622080, 0x599d3a6b
+0, 3, 3,1, 622080, 0x1df1e9dc
+0, 4, 4,1, 622080, 0xf3255836
+0, 5, 5,1, 622080, 0xf46bc26e
+0, 6, 6,1, 622080, 0x76d491da
+0, 7, 7,1, 622080, 0x2c9f3ca6
+0, 8, 8,1, 622080, 0x5713e203
+0, 9, 9,1, 622080, 0x47776493
--
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 2/2] avfilter/vf_chromakey: fix formula for calculation of difference
Signed-off-by: Paul B Mahol --- libavfilter/vf_chromakey.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavfilter/vf_chromakey.c b/libavfilter/vf_chromakey.c index ce8003657c..4b1669d084 100644 --- a/libavfilter/vf_chromakey.c +++ b/libavfilter/vf_chromakey.c @@ -56,7 +56,7 @@ static uint8_t do_chromakey_pixel(ChromakeyContext *ctx, uint8_t u[9], uint8_t v du = (int)u[i] - ctx->chromakey_uv[0]; dv = (int)v[i] - ctx->chromakey_uv[1]; -diff += sqrt((du * du + dv * dv) / (255.0 * 255.0)); +diff += sqrt((du * du + dv * dv) / (255.0 * 255.0 * 2)); } diff /= 9.0; @@ -78,7 +78,7 @@ static uint16_t do_chromakey_pixel16(ChromakeyContext *ctx, uint16_t u[9], uint1 du = (int)u[i] - ctx->chromakey_uv[0]; dv = (int)v[i] - ctx->chromakey_uv[1]; -diff += sqrt((du * du + dv * dv) / (max * max)); +diff += sqrt((du * du + dv * dv) / (max * max * 2)); } diff /= 9.0; -- 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] [RFC] encoder profile validation
On Sat, 16 May 2020, Fu, Linjie wrote: From: ffmpeg-devel On Behalf Of Marton Balint Sent: Saturday, May 16, 2020 21:52 To: ffmpeg-devel@ffmpeg.org Subject: [FFmpeg-devel] [RFC] encoder profile validation Hi, As you may know, a recent patchset enabled AVCodecContext->profile constants to reside in encoders. In order to make a full transition to avctx->profile even in existing encoders which might use a private profile setting, we have to make sure only supported avctx->profile values are passed to encoders. The fact that avctx->profile is not validated is already an issue, and assertions/segmentation faults can already happen in existing encoders (e.g.: aac, mpeg) if unsupported values are passed. AVCodec have a .profiles attribute which supposed to contain the list of supported profiles. However this is problematic because - AVCodecContext->profile is not validated against this list - not all encoders define the list - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL - some encoders support more or less than its currently defined list - AVCodec->profiles contains AVProfiles which supposed to have a textual representation of each profile, which can cause profile name duplications/inconsistencies against libavcodec/profiles.c if the list is different to the one in codecs profile list. So I'd rather not user AVCodec->profiles for this validation. I am The validation would help from my perspective. Meanwhile got some questions: IIRC, AVCodec->profiles probably didn't cover the HW specific profiles for encoders Like nvenc/qsv/amfenc. Are you intending to add them in this profile list and keep Them in common or did the map/verify internally in specific hw encoder? No, I'd leave AVCodec->profiles alone, because for the reasons I described above I plan to NOT use it for validation. thinking about two possible solutions: 1) Add a new AVCodec->supported_profiles attribute which is a simple integer list and validate against this list or 2) Introdce a new OPT type, AV_OPT_TYPE_ENUM which validates against the values of its named constants. This has the benefit that the supported profiles only appear once in the AVClass option list, but it also means that encoders might not share the supported profiles list via a #define in libavcodec/profile.h, because they might support different profiles. I like the second approach better, but let me know what you think. Regardless of the validation itself, as to " make a full transition to avctx->profile", do we still need to add a prefix like "-profile:v h264_main " in your designs? (I'd prefer a more natural usage) No, my previous patchset makes it possible for encoders to define their own profile names and those names do not have to be unique. https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=1193 Regards, Marton ___ 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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size
On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:
On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
> On Fri, May 15, 2020 at 06:52:55PM +0200, Marton Balint wrote:
> >
> >
> > On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
> >
> > > On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> > > > On Fri, May 15, 2020 at 6:23 PM wrote:
> > > > >
> > > > > From: Limin Wang
> > > > >
> > > > > reanalyze() may misdetect the new packet size as 204, but it's 188
still actualy,
> > > > > it'll cause many cc errors report and cannot be recovered. So it's
better to check
> > > > > the next sync byte before skip the extra unused bytes.
> > > > >
> > > > > Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the
input stream has
> > > > > a master/slave switch serveral times, the raw size can be easily
detected by mistake.
> > > > >
> > > > > Signed-off-by: Limin Wang
> > > > > ---
> > > > > libavformat/mpegts.c | 13 +++--
> > > > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > > index 0833d62..049555c 100644
> > > > > --- a/libavformat/mpegts.c
> > > > > +++ b/libavformat/mpegts.c
> > > > > @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s,
uint8_t *buf, int raw_packet_size,
> > > > > return 0;
> > > > > }
> > > > >
> > > > > -static void finished_reading_packet(AVFormatContext *s, int
raw_packet_size)
> > > > > +static void finished_reading_packet(AVFormatContext *s, const
uint8_t *data, int raw_packet_size)
> > > > > {
> > > > > AVIOContext *pb = s->pb;
> > > > > int skip = raw_packet_size - TS_PACKET_SIZE;
> > > > > -if (skip > 0)
> > > > > +/* Check the next sync byte to avoid incorrectt detected raw
packet size */
> > > > > +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
> > > > > avio_skip(pb, skip);
> > > > > }
> > > > >
> > > > > @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts,
int64_t nb_packets)
> > > > > if (ret != 0)
> > > > > break;
> > > > > ret = handle_packet(ts, data, avio_tell(s->pb));
> > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > > > if (ret != 0)
> > > > > break;
> > > > > }
> > > > > @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext
*s)
> > > > > pid = AV_RB16(data + 1) & 0x1fff;
> > > > > if ((pcr_pid == -1 || pcr_pid == pid) &&
> > > > > parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > +finished_reading_packet(s, data,
ts->raw_packet_size);
> > > > > pcr_pid = pid;
> > > > > packet_count[nb_pcrs] = nb_packets;
> > > > > pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> > > > > @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext
*s)
> > > > > }
> > > > > }
> > > > > } else {
> > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > +finished_reading_packet(s, data,
ts->raw_packet_size);
> > > > > }
> > > > > nb_packets++;
> > > > > }
> > > > > @@ -3194,7 +3195,7 @@ static int
mpegts_raw_read_packet(AVFormatContext *s, AVPacket *pkt)
> > > > > }
> > > > > if (data != pkt->data)
> > > > > memcpy(pkt->data, data, ts->raw_packet_size);
> > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > > > if (ts->mpeg2ts_compute_pcr) {
> > > > > /* compute exact PCR for each packet */
> > > > > if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> > > > > --
> > > > > 1.8.3.1
> > > > >
> > > > Do you have a case to reproduce the cc errors report?
> > > > Yes, it's real case which can be reproduced in lab.
> >
> > Can you share the sample?
>
> No, tested with master and slave udp ts stream which switch between the master and slave stream
> more than five times, it'll cause tons of cc error report and can't be
recovered.
I suggest you capture the input, so this issue can be properly reproduced
and share it. It may even make sense to create a fate test from it.
Have tried, the issue can't be reproduced by capture offset file. I guess it's
caused by live stream seek isn't same as off line file.
If that is the case then you can override the seekability of files by
using -seekable 0 option. Alternatively you might find some other means to
replay the recorded ts, anyhow this should be reproduced, because I have a
feeling we don't have the whole picture of what is going on.
Anyway, your patch does not s
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/binkaudio: Check sample_rate to avoid integer overflow
On 5/16/20, Michael Niedermayer wrote: > On Mon, Apr 20, 2020 at 01:03:34AM +0200, Michael Niedermayer wrote: >> On Sun, Apr 19, 2020 at 05:52:01PM +0200, Lynne wrote: >> > Apr 19, 2020, 16:05 by mich...@niedermayer.cc: >> > >> > > Fixes: signed integer overflow: 2147483647 + 1 cannot be represented >> > > in type 'int' >> > > Fixes: >> > > 19950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-5765514337189888 >> > > >> > > Found-by: continuous fuzzing process >> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > > Signed-off-by: Michael Niedermayer >> > > --- >> > > libavcodec/binkaudio.c | 3 +++ >> > > 1 file changed, 3 insertions(+) >> > > >> > > diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c >> > > index 64a08b8608..2df3dc645a 100644 >> > > --- a/libavcodec/binkaudio.c >> > > +++ b/libavcodec/binkaudio.c >> > > @@ -106,6 +106,9 @@ static av_cold int decode_init(AVCodecContext >> > > *avctx) >> > > avctx->sample_fmt = AV_SAMPLE_FMT_FLTP; >> > > } >> > > >> > > +if (sample_rate >= INT_MAX) >> > > +return AVERROR_INVALIDDATA; >> > > + >> > > s->frame_len = 1 << frame_len_bits; >> > > s->overlap_len = s->frame_len / 16; >> > > s->block_size= (s->frame_len - s->overlap_len) * s->channels; >> > > >> > >> > Did you even bother to look at the checks you added in this decoder >> > previously? >> > Specifically 11 lines above? >> > >> > > if (sample_rate > INT_MAX / avctx->channels) >> > > return AVERROR_INVALIDDATA; >> > > sample_rate *= avctx->channels; >> > >> > To start with the sample rate of the avctx is already checked in >> > utils.c, and you >> > still haven't cleaned up any decoders from the checks made unnecessary >> > by you, >> >> The new check is needed, it overflows without: >> libavcodec/binkaudio.c:116:37: runtime error: signed integer overflow: >> 2147483647 + 1 cannot be represented in type 'int' >> >> The other check is also needed, if i remove it it still overflows >> libavcodec/binkaudio.c:100:22: runtime error: signed integer overflow: >> 1092624416 * 2 cannot be represented in type 'int' >> >> >> > so am reminding you again to clean up the codebase by getting rid of >> > them. >> > At least you might get to clean the codebase for once rather than adding >> > crap like this. >> > >> > So there's only the branch which I quoted that's needed to be fixed, and >> > since there's a >> > check there already, there's no reason to have a check here as well. >> >> I posted exactly this same patch in january, there was a objection, and i >> asked >> what was preferred instead, and pinged it multiple times over the >> following >> months, in february and april: >> >> 189192 N F 0114 15:36 To FFmpeg devel (1,6K) [FFmpeg-devel] [PATCH] >> avcodec/binkaudio: Check sample_rate to avoid integer overflow >> 189193 r 0114 16:04 Paul B Mahol(2,1K) └─> >> 189194 sF 0201 16:14 To FFmpeg devel (1,7K) └─> >> 189195 r 0201 16:17 Paul B Mahol(1,3K) └─> >> 189196 rsF 0201 23:48 To FFmpeg devel (2,6K) └─> >> 189197 rs 0209 21:28 Michael Niederm (2,9K) └─> >> 189198 rsF 0404 23:38 To FFmpeg devel (2,8K) └─> >> 189199 sF 0407 23:17 To FFmpeg devel (3,1K) └─> >> >> but i failed to get a reply, so i tried reposting it >> >> So, if the patch is still not liked, can you explain what do you >> prefer ? >> >> i can put the sample_rate >= INT_MAX check in generic code but it >> is specific to this decoder it wont help anything else >> >> i can put a more aggressive check like sample_rate * channels > >> MAX_CHANNEL_SAMPLES >> in generic code, that will of course block some otherwise supported cases >> >> or we can have checks just for what is not supported >> >> or we can extend the code to support a wider range where it is possible >> > >> Just say what you prefer, i dont mind at all what it is, i just want the >> issue fixed its already so many months open ... > > ping > id like to fix ossfuzz issue 19950 Use (sample_rate + 1LL) / 2 ? > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > What does censorship reveal? It reveals fear. -- Julian Assange > ___ 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] avcodec/binkaudio: Check sample_rate to avoid integer overflow
On Mon, Apr 20, 2020 at 01:03:34AM +0200, Michael Niedermayer wrote: > On Sun, Apr 19, 2020 at 05:52:01PM +0200, Lynne wrote: > > Apr 19, 2020, 16:05 by mich...@niedermayer.cc: > > > > > Fixes: signed integer overflow: 2147483647 + 1 cannot be represented in > > > type 'int' > > > Fixes: > > > 19950/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_BINKAUDIO_DCT_fuzzer-5765514337189888 > > > > > > Found-by: continuous fuzzing process > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > > Signed-off-by: Michael Niedermayer > > > --- > > > libavcodec/binkaudio.c | 3 +++ > > > 1 file changed, 3 insertions(+) > > > > > > diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c > > > index 64a08b8608..2df3dc645a 100644 > > > --- a/libavcodec/binkaudio.c > > > +++ b/libavcodec/binkaudio.c > > > @@ -106,6 +106,9 @@ static av_cold int decode_init(AVCodecContext *avctx) > > > avctx->sample_fmt = AV_SAMPLE_FMT_FLTP; > > > } > > > > > > +if (sample_rate >= INT_MAX) > > > +return AVERROR_INVALIDDATA; > > > + > > > s->frame_len = 1 << frame_len_bits; > > > s->overlap_len = s->frame_len / 16; > > > s->block_size= (s->frame_len - s->overlap_len) * s->channels; > > > > > > > Did you even bother to look at the checks you added in this decoder > > previously? > > Specifically 11 lines above? > > > > > if (sample_rate > INT_MAX / avctx->channels) > > > return AVERROR_INVALIDDATA; > > > sample_rate *= avctx->channels; > > > > To start with the sample rate of the avctx is already checked in utils.c, > > and you > > still haven't cleaned up any decoders from the checks made unnecessary by > > you, > > The new check is needed, it overflows without: > libavcodec/binkaudio.c:116:37: runtime error: signed integer overflow: > 2147483647 + 1 cannot be represented in type 'int' > > The other check is also needed, if i remove it it still overflows > libavcodec/binkaudio.c:100:22: runtime error: signed integer overflow: > 1092624416 * 2 cannot be represented in type 'int' > > > > so am reminding you again to clean up the codebase by getting rid of them. > > At least you might get to clean the codebase for once rather than adding > > crap like this. > > > > So there's only the branch which I quoted that's needed to be fixed, and > > since there's a > > check there already, there's no reason to have a check here as well. > > I posted exactly this same patch in january, there was a objection, and i > asked > what was preferred instead, and pinged it multiple times over the following > months, in february and april: > > 189192 N F 0114 15:36 To FFmpeg devel (1,6K) [FFmpeg-devel] [PATCH] > avcodec/binkaudio: Check sample_rate to avoid integer overflow > 189193 r 0114 16:04 Paul B Mahol(2,1K) └─> > 189194 sF 0201 16:14 To FFmpeg devel (1,7K) └─> > 189195 r 0201 16:17 Paul B Mahol(1,3K) └─> > 189196 rsF 0201 23:48 To FFmpeg devel (2,6K) └─> > 189197 rs 0209 21:28 Michael Niederm (2,9K) └─> > 189198 rsF 0404 23:38 To FFmpeg devel (2,8K) └─> > 189199 sF 0407 23:17 To FFmpeg devel (3,1K) └─> > > but i failed to get a reply, so i tried reposting it > > So, if the patch is still not liked, can you explain what do you > prefer ? > > i can put the sample_rate >= INT_MAX check in generic code but it > is specific to this decoder it wont help anything else > > i can put a more aggressive check like sample_rate * channels > > MAX_CHANNEL_SAMPLES > in generic code, that will of course block some otherwise supported cases > > or we can have checks just for what is not supported > > or we can extend the code to support a wider range where it is possible > > Just say what you prefer, i dont mind at all what it is, i just want the > issue fixed its already so many months open ... ping id like to fix ossfuzz issue 19950 thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB What does censorship reveal? It reveals fear. -- Julian Assange 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 v5 1/4] avcodec/adpcmenc: add capabilities argument to ADPCM_ENCODER()
On 5/16/20, Zane van Iperen wrote: > On Sat, 16 May 2020 15:03:22 +0200 > "Paul B Mahol" wrote: > >> >> Why sending this kind of patches? >> >> I see no point in this patch? >> > > Michael suggested it here > https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262730.html > > > Ah, one of them use small last frame capability. Everything is ok then. ___ 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] avcodec/pnmdec: Use unsigned for maxval rescaling
Fixes: signed integer overflow: 65535 * 55335 cannot be represented in type
'int'
Fixes:
21955/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGMYUV_fuzzer-5669206981083136
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pnmdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pnmdec.c b/libavcodec/pnmdec.c
index dbcaef38848..e03e52297f7 100644
--- a/libavcodec/pnmdec.c
+++ b/libavcodec/pnmdec.c
@@ -132,7 +132,7 @@ static int pnm_decode_frame(AVCodecContext *avctx, void
*data,
init_put_bits(&pb, ptr, linesize);
for(j=0; jwidth * components; j++){
unsigned int c=0;
-int v=0;
+unsigned v=0;
if(s->type < 4)
while(s->bytestream < s->bytestream_end && (*s->bytestream
< '0' || *s->bytestream > '9' ))
s->bytestream++;
--
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 v3] avcodec/v4l2_m2m_dec: Remove redundant packet and fix double free
On Sat, 09. May 13:35, Andriy Gelman wrote:
> From: Andriy Gelman
>
> v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
> cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
> the next call. Currently the ownership transfer between the two packets
> is not properly handled. A double free occurs if
> ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
> returns EINVAL.
>
> In fact, having two AVPackets is not needed and everything can be
> handled by s->buf_pkt.
>
> This commit removes the local avpkt from v4l2_receive_frame(), meaning
> that the ownership transfer doesn't need to be handled and the double
> free is fixed.
>
> Signed-off-by: Andriy Gelman
> ---
>
> Sorry, forgot to squash the commit from v1 so v2 didn't apply. This is
> correct version.
>
> Supersedes:
> https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505055454.28683-1-andriy.gel...@gmail.com/
>
>
> libavcodec/v4l2_m2m_dec.c | 37 +++--
> 1 file changed, 15 insertions(+), 22 deletions(-)
>
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 3e17e0fcac..b038efed9c 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -138,14 +138,10 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
> V4L2Context *const capture = &s->capture;
> V4L2Context *const output = &s->output;
> -AVPacket avpkt = {0};
> int ret;
>
> -if (s->buf_pkt.size) {
> -avpkt = s->buf_pkt;
> -memset(&s->buf_pkt, 0, sizeof(AVPacket));
> -} else {
> -ret = ff_decode_get_packet(avctx, &avpkt);
> +if (!s->buf_pkt.size) {
> +ret = ff_decode_get_packet(avctx, &s->buf_pkt);
> if (ret < 0 && ret != AVERROR_EOF)
> return ret;
> }
> @@ -153,32 +149,29 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
> if (s->draining)
> goto dequeue;
>
> -ret = ff_v4l2_context_enqueue_packet(output, &avpkt);
> -if (ret < 0) {
> -if (ret != AVERROR(EAGAIN))
> - return ret;
> +ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt);
> +if (ret < 0 && ret != AVERROR(EAGAIN))
> +goto fail;
>
> -s->buf_pkt = avpkt;
> -/* no input buffers available, continue dequeing */
> -}
> +/* if EAGAIN don't unref packet and try to enqueue in the next iteration
> */
> +if (ret != AVERROR(EAGAIN))
> +av_packet_unref(&s->buf_pkt);
>
> -if (avpkt.size) {
> +if (!s->draining) {
> ret = v4l2_try_start(avctx);
> if (ret) {
> -av_packet_unref(&avpkt);
> -
> /* cant recover */
> -if (ret == AVERROR(ENOMEM))
> -return ret;
> -
> -return 0;
> +if (ret != AVERROR(ENOMEM))
> +ret = 0;
> +goto fail;
> }
> }
>
> dequeue:
> -if (!s->buf_pkt.size)
> -av_packet_unref(&avpkt);
> return ff_v4l2_context_dequeue_frame(capture, frame, -1);
> +fail:
> +av_packet_unref(&s->buf_pkt);
> +return ret;
> }
>
> static av_cold int v4l2_decode_init(AVCodecContext *avctx)
> --
> 2.25.1
>
ping
--
Andriy
___
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/dump: Use int64_t for intermediate time values
On 16/05/2020 16:23, Carl Eugen Hoyos wrote: > I believe there is a ticket that this patch fixes, but I won't find it > quickly;-( A quick search of trac didn't reveal anything to me, either... - 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] avformat/dump: Use int64_t for intermediate time values
Am Sa., 16. Mai 2020 um 16:21 Uhr schrieb Derek Buitenhuis : > > Prevents wrap-around to negative values while calculating the duration string. > > Before: > > Duration: -411422:-59:-42.17, start: 0.00, bitrate: 0 kb/s > > After: > > Duration: 781623:28:34.17, start: 0.00, bitrate: 0 kb/s > > Signed-off-by: Derek Buitenhuis > --- > Minimal example file: http://chromashift.org/s/long3.mp4` I believe there is a ticket that this patch fixes, but I won't find it quickly;-( Carl Eugen ___ 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] [RFC] encoder profile validation
> From: ffmpeg-devel On Behalf Of > Marton Balint > Sent: Saturday, May 16, 2020 21:52 > To: ffmpeg-devel@ffmpeg.org > Subject: [FFmpeg-devel] [RFC] encoder profile validation > > Hi, > > As you may know, a recent patchset enabled AVCodecContext->profile > constants to reside in encoders. > > In order to make a full transition to avctx->profile even in existing > encoders which might use a private profile setting, we have to make sure > only supported avctx->profile values are passed to encoders. > > The fact that avctx->profile is not validated is already an issue, and > assertions/segmentation faults can already happen in existing encoders > (e.g.: aac, mpeg) if unsupported values are passed. > > AVCodec have a .profiles attribute which supposed to contain the list of > supported profiles. However this is problematic because > - AVCodecContext->profile is not validated against this list > - not all encoders define the list > - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL > - some encoders support more or less than its currently defined list > - AVCodec->profiles contains AVProfiles which supposed to have a textual >representation of each profile, which can cause profile name >duplications/inconsistencies against libavcodec/profiles.c if the list >is different to the one in codecs profile list. > > So I'd rather not user AVCodec->profiles for this validation. I am The validation would help from my perspective. Meanwhile got some questions: IIRC, AVCodec->profiles probably didn't cover the HW specific profiles for encoders Like nvenc/qsv/amfenc. Are you intending to add them in this profile list and keep Them in common or did the map/verify internally in specific hw encoder? > thinking about two possible solutions: > > 1) Add a new AVCodec->supported_profiles attribute which is a simple > integer list and validate against this list > > or > > 2) Introdce a new OPT type, AV_OPT_TYPE_ENUM which validates against > the > values of its named constants. This has the benefit that the supported > profiles only appear once in the AVClass option list, but it also > means that encoders might not share the supported profiles list via a > #define in libavcodec/profile.h, because they might support different > profiles. > > I like the second approach better, but let me know what you think. > Regardless of the validation itself, as to " make a full transition to avctx->profile", do we still need to add a prefix like "-profile:v h264_main " in your designs? (I'd prefer a more natural usage) - Linjie ___ 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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size
On Sat, May 16, 2020 at 11:44:01AM +0200, Marton Balint wrote:
>
>
> On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
>
> > On Fri, May 15, 2020 at 06:52:55PM +0200, Marton Balint wrote:
> > >
> > >
> > > On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
> > >
> > > > On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> > > > > On Fri, May 15, 2020 at 6:23 PM wrote:
> > > > > >
> > > > > > From: Limin Wang
> > > > > >
> > > > > > reanalyze() may misdetect the new packet size as 204, but it's 188
> > > > > > still actualy,
> > > > > > it'll cause many cc errors report and cannot be recovered. So it's
> > > > > > better to check
> > > > > > the next sync byte before skip the extra unused bytes.
> > > > > >
> > > > > > Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If
> > > > > > the input stream has
> > > > > > a master/slave switch serveral times, the raw size can be easily
> > > > > > detected by mistake.
> > > > > >
> > > > > > Signed-off-by: Limin Wang
> > > > > > ---
> > > > > > libavformat/mpegts.c | 13 +++--
> > > > > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > > > index 0833d62..049555c 100644
> > > > > > --- a/libavformat/mpegts.c
> > > > > > +++ b/libavformat/mpegts.c
> > > > > > @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s,
> > > > > > uint8_t *buf, int raw_packet_size,
> > > > > > return 0;
> > > > > > }
> > > > > >
> > > > > > -static void finished_reading_packet(AVFormatContext *s, int
> > > > > > raw_packet_size)
> > > > > > +static void finished_reading_packet(AVFormatContext *s, const
> > > > > > uint8_t *data, int raw_packet_size)
> > > > > > {
> > > > > > AVIOContext *pb = s->pb;
> > > > > > int skip = raw_packet_size - TS_PACKET_SIZE;
> > > > > > -if (skip > 0)
> > > > > > +/* Check the next sync byte to avoid incorrectt detected raw
> > > > > > packet size */
> > > > > > +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
> > > > > > avio_skip(pb, skip);
> > > > > > }
> > > > > >
> > > > > > @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts,
> > > > > > int64_t nb_packets)
> > > > > > if (ret != 0)
> > > > > > break;
> > > > > > ret = handle_packet(ts, data, avio_tell(s->pb));
> > > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > > > > if (ret != 0)
> > > > > > break;
> > > > > > }
> > > > > > @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext
> > > > > > *s)
> > > > > > pid = AV_RB16(data + 1) & 0x1fff;
> > > > > > if ((pcr_pid == -1 || pcr_pid == pid) &&
> > > > > > parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> > > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > > +finished_reading_packet(s, data,
> > > > > > ts->raw_packet_size);
> > > > > > pcr_pid = pid;
> > > > > > packet_count[nb_pcrs] = nb_packets;
> > > > > > pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> > > > > > @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext
> > > > > > *s)
> > > > > > }
> > > > > > }
> > > > > > } else {
> > > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > > +finished_reading_packet(s, data,
> > > > > > ts->raw_packet_size);
> > > > > > }
> > > > > > nb_packets++;
> > > > > > }
> > > > > > @@ -3194,7 +3195,7 @@ static int
> > > > > > mpegts_raw_read_packet(AVFormatContext *s, AVPacket *pkt)
> > > > > > }
> > > > > > if (data != pkt->data)
> > > > > > memcpy(pkt->data, data, ts->raw_packet_size);
> > > > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > > > > if (ts->mpeg2ts_compute_pcr) {
> > > > > > /* compute exact PCR for each packet */
> > > > > > if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> > > > > > --
> > > > > > 1.8.3.1
> > > > > >
> > > > > Do you have a case to reproduce the cc errors report?
> > > > > Yes, it's real case which can be reproduced in lab.
> > >
> > > Can you share the sample?
> >
> > No, tested with master and slave udp ts stream which switch between the
> > master and slave stream
> > more than five times, it'll cause tons of cc error report and can't be
> > recovered.
>
> I suggest you capture the input, so this issue can be properly reproduced
> and share it. It may even make sense to create a fate test from it.
Have tried, the issue can't be reproduced by capture offset file. I guess it's
caused by live stream seek isn't same as off line file.
>
> Anyway, you
[FFmpeg-devel] [PATCH V4] avformat: Add Dynacolor MVC Demuxer
Please ignore my previous email as it was sent in error.
This demuxer adds support for demuxing files in the Dynacolor format
such as the sample located at:
http://samples.ffmpeg.org/camera-dvr/dynacolor/dynacolor-camera-sample
However some decode errors are showing on the resulting MPEG4 stream.
I don't know whether this is a bug with the demuxer or the file as there is
only one sample
but the output results in a 8 second mp4 file that is playable in VLC media
player.
I believe that i have addressed the comments that I recieved in the previous
review.
Also i have managed to improve the efficiency of the demuxer and also made the
probe function more useful.
Thanks
Tom
Signed-off-by: Tom Needham <06needh...@gmail.com>
---
Changelog| 1 +
doc/general.texi | 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/dynacolor.c | 411 +++
libavformat/dynacolor.h | 209
libavformat/version.h| 2 +-
7 files changed, 625 insertions(+), 1 deletion(-)
create mode 100644 libavformat/dynacolor.c
create mode 100644 libavformat/dynacolor.h
diff --git a/Changelog b/Changelog
index 711861bda9..79d39494c9 100644
--- a/Changelog
+++ b/Changelog
@@ -54,6 +54,7 @@ version :
- DERF demuxer
- CRI HCA decoder
- CRI HCA demuxer
+- Dynacolor MVC Demuxer
version 4.2:
diff --git a/doc/general.texi b/doc/general.texi
index 752618a00b..4eb4716d87 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -452,6 +452,7 @@ library:
@item DXA @tab @tab X
@tab This format is used in the non-Windows version of the Feeble Files
game and different game cutscenes repacked for use with ScummVM.
+@item Dynacolor MVC @tab @tab X
@item Electronic Arts cdata @tab@tab X
@item Electronic Arts Multimedia @tab@tab X
@tab Used in various EA games; files have extensions like WVE and UV2.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8fd0d43721..4d1ca8b7ed 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -169,6 +169,7 @@ OBJS-$(CONFIG_DV_MUXER) += dvenc.o
OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
+OBJS-$(CONFIG_DYNACOLOR_DEMUXER) += dynacolor.o
OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 39d2c352f5..50f3926b05 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -131,6 +131,7 @@ extern AVOutputFormat ff_dv_muxer;
extern AVInputFormat ff_dvbsub_demuxer;
extern AVInputFormat ff_dvbtxt_demuxer;
extern AVInputFormat ff_dxa_demuxer;
+extern AVInputFormat ff_dynacolor_demuxer;
extern AVInputFormat ff_ea_demuxer;
extern AVInputFormat ff_ea_cdata_demuxer;
extern AVInputFormat ff_eac3_demuxer;
diff --git a/libavformat/dynacolor.c b/libavformat/dynacolor.c
new file mode 100644
index 00..05a32b5299
--- /dev/null
+++ b/libavformat/dynacolor.c
@@ -0,0 +1,411 @@
+/*
+ * Dynacolor MVC Demuxer
+ * Copyright (c) 2020 Tom Needham
+ *
+ * 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
+#include "avformat.h"
+#include "internal.h"
+#include "dynacolor.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/timecode.h"
+#include "libavutil/avassert.h"
+
+int ff_dyna_read_packet_header(AVFormatContext *ctx, AVIOContext *pb, unsigned
char *pes_data, DynacolorPesHeader *pes,
+ unsigned int *size, time_t *time, DynacolorHeader
*header, unsigned int *basicIdx_H, unsigned int *basicIdx_L,
+ unsigned char first)
+{
+int ret = 0;
+unsigned int stream_format;
+
+*(basicIdx_H) = avio_rl32(pb);
+
+header->Basic.Header1= *(basicIdx_H)&0xFF;
+header->Basic.Header2= *(basicIdx_H) >> 8 & 0xFF;
+header->Basic.reserved = *(basicIdx_H) >> 16 & 0x0F;
+header->Basic.Source
[FFmpeg-devel] [PATCH] avformat: Add Dynacolor MVC Demuxer
This demuxer adds support for demuxing files in the Dynacolor format
such as the sample located at:
http://samples.ffmpeg.org/camera-dvr/dynacolor/dynacolor-camera-sample
However some decode errors are showing on the resulting MPEG4 stream.
I don't know whether this is a bug with the demuxer or the file as there is
only one sample
but the output results in a 1 second mp4 file that is playable in VLC media
player.
Signed-off-by: Tom Needham <06needh...@gmail.com>
---
Changelog| 1 +
doc/general.texi | 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/dynacolor.c | 411 +++
libavformat/dynacolor.h | 209
libavformat/version.h| 2 +-
7 files changed, 625 insertions(+), 1 deletion(-)
create mode 100644 libavformat/dynacolor.c
create mode 100644 libavformat/dynacolor.h
diff --git a/Changelog b/Changelog
index 711861bda9..79d39494c9 100644
--- a/Changelog
+++ b/Changelog
@@ -54,6 +54,7 @@ version :
- DERF demuxer
- CRI HCA decoder
- CRI HCA demuxer
+- Dynacolor MVC Demuxer
version 4.2:
diff --git a/doc/general.texi b/doc/general.texi
index 752618a00b..4eb4716d87 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -452,6 +452,7 @@ library:
@item DXA @tab @tab X
@tab This format is used in the non-Windows version of the Feeble Files
game and different game cutscenes repacked for use with ScummVM.
+@item Dynacolor MVC @tab @tab X
@item Electronic Arts cdata @tab@tab X
@item Electronic Arts Multimedia @tab@tab X
@tab Used in various EA games; files have extensions like WVE and UV2.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 8fd0d43721..4d1ca8b7ed 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -169,6 +169,7 @@ OBJS-$(CONFIG_DV_MUXER) += dvenc.o
OBJS-$(CONFIG_DVBSUB_DEMUXER)+= dvbsub.o rawdec.o
OBJS-$(CONFIG_DVBTXT_DEMUXER)+= dvbtxt.o rawdec.o
OBJS-$(CONFIG_DXA_DEMUXER) += dxa.o
+OBJS-$(CONFIG_DYNACOLOR_DEMUXER) += dynacolor.o
OBJS-$(CONFIG_EA_CDATA_DEMUXER) += eacdata.o
OBJS-$(CONFIG_EA_DEMUXER)+= electronicarts.o
OBJS-$(CONFIG_EAC3_DEMUXER) += ac3dec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 39d2c352f5..50f3926b05 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -131,6 +131,7 @@ extern AVOutputFormat ff_dv_muxer;
extern AVInputFormat ff_dvbsub_demuxer;
extern AVInputFormat ff_dvbtxt_demuxer;
extern AVInputFormat ff_dxa_demuxer;
+extern AVInputFormat ff_dynacolor_demuxer;
extern AVInputFormat ff_ea_demuxer;
extern AVInputFormat ff_ea_cdata_demuxer;
extern AVInputFormat ff_eac3_demuxer;
diff --git a/libavformat/dynacolor.c b/libavformat/dynacolor.c
new file mode 100644
index 00..05a32b5299
--- /dev/null
+++ b/libavformat/dynacolor.c
@@ -0,0 +1,411 @@
+/*
+ * Dynacolor MVC Demuxer
+ * Copyright (c) 2020 Tom Needham
+ *
+ * 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
+#include "avformat.h"
+#include "internal.h"
+#include "dynacolor.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/mathematics.h"
+#include "libavutil/timecode.h"
+#include "libavutil/avassert.h"
+
+int ff_dyna_read_packet_header(AVFormatContext *ctx, AVIOContext *pb, unsigned
char *pes_data, DynacolorPesHeader *pes,
+ unsigned int *size, time_t *time, DynacolorHeader
*header, unsigned int *basicIdx_H, unsigned int *basicIdx_L,
+ unsigned char first)
+{
+int ret = 0;
+unsigned int stream_format;
+
+*(basicIdx_H) = avio_rl32(pb);
+
+header->Basic.Header1= *(basicIdx_H)&0xFF;
+header->Basic.Header2= *(basicIdx_H) >> 8 & 0xFF;
+header->Basic.reserved = *(basicIdx_H) >> 16 & 0x0F;
+header->Basic.Source = *(basicIdx_H) >> 20 & 0x01;
+header->Basic.WidthBase = *(basicIdx_H) >> 21 & 0x03;
+header->Basic.Reserved0 = *(basicIdx_H) >> 23 & 0x01;
+header->Basic.Channel= *(basicIdx_H) >> 24 & 0x02;
+header->Basic.StreamType = *(basicIdx_H) >> 26
[FFmpeg-devel] [PATCH] avformat/dump: Use int64_t for intermediate time values
Prevents wrap-around to negative values while calculating the duration string.
Before:
Duration: -411422:-59:-42.17, start: 0.00, bitrate: 0 kb/s
After:
Duration: 781623:28:34.17, start: 0.00, bitrate: 0 kb/s
Signed-off-by: Derek Buitenhuis
---
Minimal example file: http://chromashift.org/s/long3.mp4`
---
libavformat/dump.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 5e9a03185f..06bafc272d 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -615,7 +615,7 @@ void av_dump_format(AVFormatContext *ic, int index,
if (!is_output) {
av_log(NULL, AV_LOG_INFO, " Duration: ");
if (ic->duration != AV_NOPTS_VALUE) {
-int hours, mins, secs, us;
+int64_t hours, mins, secs, us;
int64_t duration = ic->duration + (ic->duration <= INT64_MAX -
5000 ? 5000 : 0);
secs = duration / AV_TIME_BASE;
us= duration % AV_TIME_BASE;
@@ -623,7 +623,7 @@ void av_dump_format(AVFormatContext *ic, int index,
secs %= 60;
hours = mins / 60;
mins %= 60;
-av_log(NULL, AV_LOG_INFO, "%02d:%02d:%02d.%02d", hours, mins, secs,
+av_log(NULL, AV_LOG_INFO,
"%02"PRId64":%02"PRId64":%02"PRId64".%02"PRId64"", hours, mins, secs,
(100 * us) / AV_TIME_BASE);
} else {
av_log(NULL, AV_LOG_INFO, "N/A");
--
2.26.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 v5 3/4] avcodec/adpcmenc: fix formatting
On Sat, 16 May 2020 15:04:04 +0200 "Paul B Mahol" wrote: > > Why? > > No point in this. > Because of the "Cosmetic changes should be kept in separate patches." section at https://www.ffmpeg.org/developer.html I mentioned in the cover letter that if this patch is too little to be standalone, then it can be squashed in the previous one. I chose to err on the side of caution. ___ 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 v5 1/4] avcodec/adpcmenc: add capabilities argument to ADPCM_ENCODER()
On Sat, 16 May 2020 15:03:22 +0200 "Paul B Mahol" wrote: > > Why sending this kind of patches? > > I see no point in this patch? > Michael suggested it here https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262730.html ___ 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] [RFC] encoder profile validation
Hi, As you may know, a recent patchset enabled AVCodecContext->profile constants to reside in encoders. In order to make a full transition to avctx->profile even in existing encoders which might use a private profile setting, we have to make sure only supported avctx->profile values are passed to encoders. The fact that avctx->profile is not validated is already an issue, and assertions/segmentation faults can already happen in existing encoders (e.g.: aac, mpeg) if unsupported values are passed. AVCodec have a .profiles attribute which supposed to contain the list of supported profiles. However this is problematic because - AVCodecContext->profile is not validated against this list - not all encoders define the list - even if there is a list it might be defined as NULL_IF_CONFIG_SMALL - some encoders support more or less than its currently defined list - AVCodec->profiles contains AVProfiles which supposed to have a textual representation of each profile, which can cause profile name duplications/inconsistencies against libavcodec/profiles.c if the list is different to the one in codecs profile list. So I'd rather not user AVCodec->profiles for this validation. I am thinking about two possible solutions: 1) Add a new AVCodec->supported_profiles attribute which is a simple integer list and validate against this list or 2) Introdce a new OPT type, AV_OPT_TYPE_ENUM which validates against the values of its named constants. This has the benefit that the supported profiles only appear once in the AVClass option list, but it also means that encoders might not share the supported profiles list via a #define in libavcodec/profile.h, because they might support different profiles. I like the second approach better, but let me know what you think. Thanks, Marton ___ 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/jpeg2000dec: Free packed_headers
On Thu, May 14, 2020 at 2:19 AM Michael Niedermayer wrote: > > Fixes: memleak > Fixes: > 21784/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_JPEG2000_fuzzer-565256551058636 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/jpeg2000dec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/jpeg2000dec.c b/libavcodec/jpeg2000dec.c > index 460a4ad95c8..6424ed5 100644 > --- a/libavcodec/jpeg2000dec.c > +++ b/libavcodec/jpeg2000dec.c > @@ -2014,6 +2014,8 @@ static void jpeg2000_dec_cleanup(Jpeg2000DecoderContext > *s) > ff_jpeg2000_cleanup(comp, codsty); > } > av_freep(&s->tile[tileno].comp); > +av_freep(&s->tile[tileno].packed_headers); > +s->tile[tileno].packed_headers_size = 0; > } > } > av_freep(&s->tile); > -- > 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". Seems to deallocate all data related to the packed_headers. Looks good to me. -- - Gautam | ___ 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] lavfi: add untile filter.
On 5/16/20, Nicolas George wrote: > Paul B Mahol (12020-05-15): >> When to apply? > > When I have time to check the few things I noted I had to check. Is it > important? Do you have a need for this? I see nowhere notes for things that need checking... Except maybe that query_formats thing. It is important feature to some FFmpeg users. > > Regards, > > -- > Nicolas George > ___ 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] lavfi: add untile filter.
Paul B Mahol (12020-05-15): > When to apply? When I have time to check the few things I noted I had to check. Is it important? Do you have a need for this? Regards, -- Nicolas George 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 v5 3/4] avcodec/adpcmenc: fix formatting
Why?
No point in this.
On 5/16/20, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> libavcodec/adpcmenc.c | 10 +-
> 1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
> index fbddbd085b..940279274e 100644
> --- a/libavcodec/adpcmenc.c
> +++ b/libavcodec/adpcmenc.c
> @@ -751,9 +751,9 @@ AVCodec ff_ ## name_ ## _encoder = {
> \
> .capabilities = capabilities_,
> \
> }
>
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
> "ADPCM IMA QuickTime");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
> "ADPCM IMA QuickTime");
> ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,
> AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactive");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
> "ADPCM IMA WAV");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
> "ADPCM Microsoft");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
> "ADPCM Shockwave Flash");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
> "ADPCM Yamaha");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
> "ADPCM IMA WAV");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
> "ADPCM Microsoft");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
> "ADPCM Shockwave Flash");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
> "ADPCM Yamaha");
> --
> 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".
___
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 v5 1/4] avcodec/adpcmenc: add capabilities argument to ADPCM_ENCODER()
Why sending this kind of patches?
I see no point in this patch?
On 5/16/20, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen
> ---
> libavcodec/adpcmenc.c | 33 +
> 1 file changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
> index 668939c778..d3098a8f9c 100644
> --- a/libavcodec/adpcmenc.c
> +++ b/libavcodec/adpcmenc.c
> @@ -706,21 +706,22 @@ static const enum AVSampleFormat sample_fmts_p[] = {
> AV_SAMPLE_FMT_S16P, AV_SAMPLE_FMT_NONE
> };
>
> -#define ADPCM_ENCODER(id_, name_, sample_fmts_, long_name_) \
> -AVCodec ff_ ## name_ ## _encoder = {\
> -.name = #name_, \
> -.long_name = NULL_IF_CONFIG_SMALL(long_name_), \
> -.type = AVMEDIA_TYPE_AUDIO, \
> -.id = id_, \
> -.priv_data_size = sizeof(ADPCMEncodeContext), \
> -.init = adpcm_encode_init,\
> -.encode2= adpcm_encode_frame, \
> -.close = adpcm_encode_close, \
> -.sample_fmts= sample_fmts_, \
> +#define ADPCM_ENCODER(id_, name_, sample_fmts_, capabilities_, long_name_)
> \
> +AVCodec ff_ ## name_ ## _encoder = {
> \
> +.name = #name_,
> \
> +.long_name = NULL_IF_CONFIG_SMALL(long_name_),
> \
> +.type = AVMEDIA_TYPE_AUDIO,
> \
> +.id = id_,
> \
> +.priv_data_size = sizeof(ADPCMEncodeContext),
> \
> +.init = adpcm_encode_init,
> \
> +.encode2= adpcm_encode_frame,
> \
> +.close = adpcm_encode_close,
> \
> +.sample_fmts= sample_fmts_,
> \
> +.capabilities = capabilities_,
> \
> }
>
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p,
> "ADPCM IMA QuickTime");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p,
> "ADPCM IMA WAV");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts,
> "ADPCM Microsoft");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts,
> "ADPCM Shockwave Flash");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts,
> "ADPCM Yamaha");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
> "ADPCM IMA QuickTime");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
> "ADPCM IMA WAV");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
> "ADPCM Microsoft");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
> "ADPCM Shockwave Flash");
> +ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
> "ADPCM Yamaha");
> --
> 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".
___
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/hls: check target duration in the playlist
2020年5月16日 下午8:21，Carl Eugen Hoyos 写道： Am Sa., 16. Mai 2020 um 14:12 Uhr schrieb Steven Liu : fix ticket: 8673 reference rfc8216 4.3.3.1 said: The EXT-X-TARGETDURATION tag is REQUIRED. in ticket 8673, the EXT-X-TARGETDURATION is incorrect, so hls should return error. Can't an invalid target duration be ignored? Or is the stream unplayable without target duration? Ah, you are right, it’s not EXT-X-TARGETDURATION problem. Need continue analyse :( Carl Eugen ___ 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". Thanks Steven Liu ___ 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/hls: check target duration in the playlist
> 2020年5月16日 下午8:21，Carl Eugen Hoyos 写道： > > Am Sa., 16. Mai 2020 um 14:12 Uhr schrieb Steven Liu : >> >> fix ticket: 8673 >> reference rfc8216 4.3.3.1 said: >> The EXT-X-TARGETDURATION tag is REQUIRED. > >> in ticket 8673, the EXT-X-TARGETDURATION is incorrect, so hls >> should return error. > > Can't an invalid target duration be ignored? > Or is the stream unplayable without target duration? Ah, I’m wrong, it’s not EXT-X-TARGETDURATION problem. Need continue analyse :( > > Carl Eugen > ___ > 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". Thanks Steven Liu ___ 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/hls: check target duration in the playlist
Am Sa., 16. Mai 2020 um 14:12 Uhr schrieb Steven Liu : > > fix ticket: 8673 > reference rfc8216 4.3.3.1 said: > The EXT-X-TARGETDURATION tag is REQUIRED. > in ticket 8673, the EXT-X-TARGETDURATION is incorrect, so hls > should return error. Can't an invalid target duration be ignored? Or is the stream unplayable without target duration? Carl Eugen ___ 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] avformat/hls: check target duration in the playlist
fix ticket: 8673
reference rfc8216 4.3.3.1 said:
The EXT-X-TARGETDURATION tag is REQUIRED.
in ticket 8673, the EXT-X-TARGETDURATION is incorrect, so hls should
return error.
Signed-off-by: Steven Liu
---
libavformat/hls.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index fc45719d1c..962ab78dd7 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -725,6 +725,7 @@ static int parse_playlist(HLSContext *c, const char *url,
struct segment **prev_segments = NULL;
int prev_n_segments = 0;
int prev_start_seq_no = -1;
+int have_target_duration = 0;
if (is_http && !in && c->http_persistent && c->playlist_pb) {
in = c->playlist_pb;
@@ -809,6 +810,7 @@ static int parse_playlist(HLSContext *c, const char *url,
if (ret < 0)
goto fail;
pls->target_duration = strtoll(ptr, NULL, 10) * AV_TIME_BASE;
+have_target_duration = 1;
} else if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
ret = ensure_playlist(c, &pls, url);
if (ret < 0)
@@ -875,6 +877,11 @@ static int parse_playlist(HLSContext *c, const char *url,
}
if (is_segment) {
struct segment *seg;
+if (!have_target_duration) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
+
ret = ensure_playlist(c, &pls, url);
if (ret < 0)
goto fail;
--
2.25.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 v5 3/4] avcodec/adpcmenc: fix formatting
Signed-off-by: Zane van Iperen
---
libavcodec/adpcmenc.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index fbddbd085b..940279274e 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -751,9 +751,9 @@ AVCodec ff_ ## name_ ## _encoder = {
\
.capabilities = capabilities_, \
}
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactive");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
"ADPCM IMA WAV");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
"ADPCM Microsoft");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
"ADPCM Shockwave Flash");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
"ADPCM Yamaha");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
"ADPCM IMA WAV");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
"ADPCM Microsoft");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
"ADPCM Shockwave Flash");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
"ADPCM Yamaha");
--
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".
[FFmpeg-devel] [PATCH v5 0/4] adpcm_ima_ssi encoder + kvag muxer
Add support for encoding adpcm_ima_ssi and muxing to kvag.
v5: [1]
- change AVERROR(EINVAL) to AVERROR_PATCHWELCOME
- Split "capabilities" argument and formatting out into new commits
- If too verbose, patch 3 may be squashed into patch 2
v{4,3,2,1}:
- ancient history
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262730.html
Zane van Iperen (4):
avcodec/adpcmenc: add capabilities argument to ADPCM_ENCODER()
avcodec: add adpcm_ima_ssi encoder
avcodec/adpcmenc: fix formatting
avformat: add kvag muxer
Changelog| 2 +
doc/general.texi | 2 +-
libavcodec/Makefile | 1 +
libavcodec/adpcmenc.c| 65 +++
libavcodec/allcodecs.c | 1 +
libavcodec/utils.c | 1 +
libavcodec/version.h | 2 +-
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/kvag.c | 84 +++-
libavformat/version.h| 2 +-
11 files changed, 142 insertions(+), 20 deletions(-)
--
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".
[FFmpeg-devel] [PATCH v5 2/4] avcodec: add adpcm_ima_ssi encoder
Signed-off-by: Zane van Iperen
---
Changelog | 1 +
doc/general.texi | 2 +-
libavcodec/Makefile| 1 +
libavcodec/adpcmenc.c | 32
libavcodec/allcodecs.c | 1 +
libavcodec/utils.c | 1 +
libavcodec/version.h | 2 +-
7 files changed, 38 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index f56674ffec..1f2cf7692d 100644
--- a/Changelog
+++ b/Changelog
@@ -67,6 +67,7 @@ version :
- Pro Pinball Series Soundbank demuxer
- pcm_rechunk bitstream filter
- scdet filter
+- Simon & Schuster Interactive ADPCM encoder
version 4.2:
diff --git a/doc/general.texi b/doc/general.texi
index 4aaf506e56..9b0ee96752 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1108,7 +1108,7 @@ following image formats are supported:
@item ADPCM IMA Funcom @tab @tab X
@item ADPCM IMA High Voltage Software ALP @tab @tab X
@item ADPCM IMA QuickTime@tab X @tab X
-@item ADPCM IMA Simon & Schuster Interactive @tab @tab X
+@item ADPCM IMA Simon & Schuster Interactive @tab X @tab X
@item ADPCM IMA Ubisoft APM @tab @tab X
@item ADPCM IMA Loki SDL MJPEG @tab @tab X
@item ADPCM IMA WAV @tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 38f6f07680..2fab8dc40b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -856,6 +856,7 @@ OBJS-$(CONFIG_ADPCM_IMA_QT_DECODER) += adpcm.o
adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_QT_ENCODER) += adpcmenc.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_RAD_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_SSI_DECODER) += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_SSI_ENCODER) += adpcmenc.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_SMJPEG_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_WAV_DECODER) += adpcm.o adpcm_data.o
OBJS-$(CONFIG_ADPCM_IMA_WAV_ENCODER) += adpcmenc.o adpcm_data.o
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index d3098a8f9c..fbddbd085b 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -77,6 +77,15 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
return AVERROR(EINVAL);
}
+if (avctx->trellis && avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI) {
+/*
+ * The current trellis implementation doesn't work for extended
+ * runs of samples without periodic resets. Disallow it.
+ */
+av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");
+return AVERROR_PATCHWELCOME;
+}
+
if (avctx->trellis) {
int frontier = 1 << avctx->trellis;
int max_paths = frontier * FREEZE_INTERVAL;
@@ -139,6 +148,10 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
}
avctx->frame_size = 512 * (avctx->sample_rate / 11025);
break;
+case AV_CODEC_ID_ADPCM_IMA_SSI:
+avctx->frame_size = BLKSIZE * 2 / avctx->channels;
+avctx->block_align = BLKSIZE;
+break;
default:
ret = AVERROR(EINVAL);
goto error;
@@ -484,6 +497,8 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
if (avctx->codec_id == AV_CODEC_ID_ADPCM_SWF)
pkt_size = (2 + avctx->channels * (22 + 4 * (frame->nb_samples - 1)) +
7) / 8;
+else if (avctx->codec_id == AV_CODEC_ID_ADPCM_IMA_SSI)
+pkt_size = (frame->nb_samples * avctx->channels) / 2;
else
pkt_size = avctx->block_align;
if ((ret = ff_alloc_packet2(avctx, avpkt, pkt_size, 0)) < 0)
@@ -568,6 +583,22 @@ static int adpcm_encode_frame(AVCodecContext *avctx,
AVPacket *avpkt,
flush_put_bits(&pb);
break;
}
+case AV_CODEC_ID_ADPCM_IMA_SSI:
+{
+PutBitContext pb;
+init_put_bits(&pb, dst, pkt_size);
+
+av_assert0(avctx->trellis == 0);
+
+for (i = 0; i < frame->nb_samples; i++) {
+for (ch = 0; ch < avctx->channels; ch++) {
+put_bits(&pb, 4, adpcm_ima_qt_compress_sample(c->status + ch,
*samples++));
+}
+}
+
+flush_put_bits(&pb);
+break;
+}
case AV_CODEC_ID_ADPCM_SWF:
{
PutBitContext pb;
@@ -721,6 +752,7 @@ AVCodec ff_ ## name_ ## _encoder = {
\
}
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_SSI, adpcm_ima_ssi, sample_fmts,
AV_CODEC_CAP_SMALL_LAST_FRAME, "ADPCM IMA Simon & Schuster Interactive");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
"ADPCM IMA WAV");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
"ADPCM Microsoft");
ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
"ADPCM Shockwave Flash");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 54d40ebdbc..a14bdf6a5d 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcod
[FFmpeg-devel] [PATCH v5 4/4] avformat: add kvag muxer
Signed-off-by: Zane van Iperen
---
Changelog| 1 +
libavformat/Makefile | 1 +
libavformat/allformats.c | 1 +
libavformat/kvag.c | 84 +++-
libavformat/version.h| 2 +-
5 files changed, 87 insertions(+), 2 deletions(-)
diff --git a/Changelog b/Changelog
index 1f2cf7692d..6aacf6e819 100644
--- a/Changelog
+++ b/Changelog
@@ -68,6 +68,7 @@ version :
- pcm_rechunk bitstream filter
- scdet filter
- Simon & Schuster Interactive ADPCM encoder
+- Real War KVAG muxer
version 4.2:
diff --git a/libavformat/Makefile b/libavformat/Makefile
index 5fa24cef16..c342c7f245 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -285,6 +285,7 @@ OBJS-$(CONFIG_JACOSUB_MUXER) += jacosubenc.o
rawenc.o
OBJS-$(CONFIG_JV_DEMUXER)+= jvdec.o
OBJS-$(CONFIG_KUX_DEMUXER) += flvdec.o
OBJS-$(CONFIG_KVAG_DEMUXER) += kvag.o
+OBJS-$(CONFIG_KVAG_MUXER)+= kvag.o rawenc.o
OBJS-$(CONFIG_LATM_MUXER)+= latmenc.o rawenc.o
OBJS-$(CONFIG_LMLM4_DEMUXER) += lmlm4.o
OBJS-$(CONFIG_LOAS_DEMUXER) += loasdec.o rawdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 3919c9e4c1..a7c5c9db89 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -220,6 +220,7 @@ extern AVOutputFormat ff_jacosub_muxer;
extern AVInputFormat ff_jv_demuxer;
extern AVInputFormat ff_kux_demuxer;
extern AVInputFormat ff_kvag_demuxer;
+extern AVOutputFormat ff_kvag_muxer;
extern AVOutputFormat ff_latm_muxer;
extern AVInputFormat ff_lmlm4_demuxer;
extern AVInputFormat ff_loas_demuxer;
diff --git a/libavformat/kvag.c b/libavformat/kvag.c
index 71b0eb4118..8be820a3c8 100644
--- a/libavformat/kvag.c
+++ b/libavformat/kvag.c
@@ -1,5 +1,5 @@
/*
- * Simon & Schuster Interactive VAG demuxer
+ * Simon & Schuster Interactive VAG (de)muxer
*
* Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
*
@@ -21,6 +21,7 @@
*/
#include "avformat.h"
#include "internal.h"
+#include "rawenc.h"
#include "libavutil/intreadwrite.h"
#define KVAG_TAGMKTAG('K', 'V', 'A', 'G')
@@ -34,6 +35,7 @@ typedef struct KVAGHeader {
uint16_tstereo;
} KVAGHeader;
+#if CONFIG_KVAG_DEMUXER
static int kvag_probe(const AVProbeData *p)
{
if (AV_RL32(p->buf) != KVAG_TAG)
@@ -115,3 +117,83 @@ AVInputFormat ff_kvag_demuxer = {
.read_header= kvag_read_header,
.read_packet= kvag_read_packet
};
+#endif
+
+#if CONFIG_KVAG_MUXER
+static int kvag_write_init(AVFormatContext *s)
+{
+AVCodecParameters *par;
+
+if (s->nb_streams != 1) {
+av_log(s, AV_LOG_ERROR, "KVAG files have exactly one stream\n");
+return AVERROR(EINVAL);
+}
+
+par = s->streams[0]->codecpar;
+
+if (par->codec_id != AV_CODEC_ID_ADPCM_IMA_SSI) {
+av_log(s, AV_LOG_ERROR, "%s codec not supported\n",
+ avcodec_get_name(par->codec_id));
+return AVERROR(EINVAL);
+}
+
+if (par->channels > 2) {
+av_log(s, AV_LOG_ERROR, "KVAG files only support up to 2 channels\n");
+return AVERROR(EINVAL);
+}
+
+return 0;
+}
+
+static int kvag_write_header(AVFormatContext *s)
+{
+uint8_t buf[KVAG_HEADER_SIZE];
+AVCodecParameters *par = s->streams[0]->codecpar;
+
+AV_WL32(buf + 0, KVAG_TAG);
+AV_WL32(buf + 4, 0); /* Data size, we fix this up later. */
+AV_WL32(buf + 8, par->sample_rate);
+AV_WL16(buf + 12, par->channels == 2);
+
+avio_write(s->pb, buf, sizeof(buf));
+return 0;
+}
+
+static int kvag_write_trailer(AVFormatContext *s)
+{
+int64_t file_size, data_size;
+
+if (!(s->pb->seekable & AVIO_SEEKABLE_NORMAL)) {
+av_log(s, AV_LOG_WARNING,
+ "Stream not seekable, unable to write data size. "
+ "Output file will be broken\n");
+return 0;
+}
+
+file_size = avio_tell(s->pb);
+data_size = file_size - KVAG_HEADER_SIZE;
+if (data_size < UINT32_MAX) {
+avio_seek(s->pb, 4, SEEK_SET);
+avio_wl32(s->pb, (uint32_t)data_size);
+avio_seek(s->pb, file_size, SEEK_SET);
+} else {
+av_log(s, AV_LOG_WARNING,
+ "Filesize %"PRId64" invalid for KVAG, output file will be
broken\n",
+ file_size);
+}
+
+return 0;
+}
+
+AVOutputFormat ff_kvag_muxer = {
+.name = "kvag",
+.long_name = NULL_IF_CONFIG_SMALL("Simon & Schuster Interactive VAG"),
+.extensions = "vag",
+.audio_codec= AV_CODEC_ID_ADPCM_IMA_SSI,
+.video_codec= AV_CODEC_ID_NONE,
+.init = kvag_write_init,
+.write_header = kvag_write_header,
+.write_packet = ff_raw_write_packet,
+.write_trailer = kvag_write_trailer
+};
+#endif
diff --git a/libavformat/version.h b/libavformat/version.h
index 493a0b337f..e0135fc7d3 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
[FFmpeg-devel] [PATCH v5 1/4] avcodec/adpcmenc: add capabilities argument to ADPCM_ENCODER()
Signed-off-by: Zane van Iperen
---
libavcodec/adpcmenc.c | 33 +
1 file changed, 17 insertions(+), 16 deletions(-)
diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
index 668939c778..d3098a8f9c 100644
--- a/libavcodec/adpcmenc.c
+++ b/libavcodec/adpcmenc.c
@@ -706,21 +706,22 @@ static const enum AVSampleFormat sample_fmts_p[] = {
AV_SAMPLE_FMT_S16P, AV_SAMPLE_FMT_NONE
};
-#define ADPCM_ENCODER(id_, name_, sample_fmts_, long_name_) \
-AVCodec ff_ ## name_ ## _encoder = {\
-.name = #name_, \
-.long_name = NULL_IF_CONFIG_SMALL(long_name_), \
-.type = AVMEDIA_TYPE_AUDIO, \
-.id = id_, \
-.priv_data_size = sizeof(ADPCMEncodeContext), \
-.init = adpcm_encode_init,\
-.encode2= adpcm_encode_frame, \
-.close = adpcm_encode_close, \
-.sample_fmts= sample_fmts_, \
+#define ADPCM_ENCODER(id_, name_, sample_fmts_, capabilities_, long_name_) \
+AVCodec ff_ ## name_ ## _encoder = { \
+.name = #name_, \
+.long_name = NULL_IF_CONFIG_SMALL(long_name_),\
+.type = AVMEDIA_TYPE_AUDIO, \
+.id = id_, \
+.priv_data_size = sizeof(ADPCMEncodeContext), \
+.init = adpcm_encode_init, \
+.encode2= adpcm_encode_frame, \
+.close = adpcm_encode_close, \
+.sample_fmts= sample_fmts_,\
+.capabilities = capabilities_, \
}
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, "ADPCM
IMA QuickTime");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, "ADPCM
IMA WAV");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, "ADPCM
Microsoft");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, "ADPCM
Shockwave Flash");
-ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, "ADPCM
Yamaha");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT, adpcm_ima_qt, sample_fmts_p, 0,
"ADPCM IMA QuickTime");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 0,
"ADPCM IMA WAV");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS, adpcm_ms, sample_fmts, 0,
"ADPCM Microsoft");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts, 0,
"ADPCM Shockwave Flash");
+ADPCM_ENCODER(AV_CODEC_ID_ADPCM_YAMAHA, adpcm_yamaha, sample_fmts, 0,
"ADPCM Yamaha");
--
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".
Re: [FFmpeg-devel] [PATCH 1/2] swscale: fix NEON hscale init
Am Fr., 15. Mai 2020 um 12:27 Uhr schrieb Josh de Kock :
>
> On 08/05/2020 12:25, Michael Niedermayer wrote:
> > On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:
> >> The NEON hscale function only supports X8 filter sizes and should only
> >> be selected when these are being used.
> >>
> >> Signed-off-by: Josh de Kock
> >> ---
> >> libswscale/aarch64/swscale.c | 5 -
> >> 1 file changed, 4 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
> >> index 54a3beabe8..eecbea88ca 100644
> >> --- a/libswscale/aarch64/swscale.c
> >> +++ b/libswscale/aarch64/swscale.c
> >> @@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
> >> int cpu_flags = av_get_cpu_flags();
> >>
> >> if (have_neon(cpu_flags)) {
> >> -if (c->srcBpc == 8 && c->dstBpc <= 14) {
> >> +if (c->srcBpc == 8 && c->dstBpc <= 14 &&
> >> +(c->hLumFilterSize % 8) == 0 &&
> >> +(c->hChrFilterSize % 8) == 0)
> >> +{
> >> c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
> >> }
> >
> > isnt filterAlign set to 8 when neon is available ?
>
> Discussed on IRC. Pushed with set.
Could you give a very short explanation on why the comment
was not relevant?
Thank you, Carl Eugen
___
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/ass: explicitly set ScaledBorderAndShadow
On Fri, Apr 17, 2020 at 03:35:44 +0200, one...@oneric.de wrote: > On Fri, Apr 17, 2020 at 02:15:17 +0200, Oneric wrote: > > ffmpeg does not set the 'ScaledBorderAndShadow' header for ASS > > subtitles. This currently leads to inconsistent behaviour depending on the > > renderer > > Attached is the revised patch also updating affected FATE samples. > > From 74d3f6bd0189b0f4922404fccbefe95e1f01093d Mon Sep 17 00:00:00 2001 > From: Oneric > Date: Fri, 17 Apr 2020 00:38:53 +0200 > Subject: [PATCH] avcodec/ass: explicitly set ScaledBorderAndShadow > [...] > 25 files changed, 25 insertions(+) ping 3 ___ 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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size
On Sat, 16 May 2020, lance.lmw...@gmail.com wrote:
On Fri, May 15, 2020 at 06:52:55PM +0200, Marton Balint wrote:
On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
> On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> > On Fri, May 15, 2020 at 6:23 PM wrote:
> > >
> > > From: Limin Wang
> > >
> > > reanalyze() may misdetect the new packet size as 204, but it's 188 still
actualy,
> > > it'll cause many cc errors report and cannot be recovered. So it's better
to check
> > > the next sync byte before skip the extra unused bytes.
> > >
> > > Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the
input stream has
> > > a master/slave switch serveral times, the raw size can be easily detected
by mistake.
> > >
> > > Signed-off-by: Limin Wang
> > > ---
> > > libavformat/mpegts.c | 13 +++--
> > > 1 file changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > index 0833d62..049555c 100644
> > > --- a/libavformat/mpegts.c
> > > +++ b/libavformat/mpegts.c
> > > @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s,
uint8_t *buf, int raw_packet_size,
> > > return 0;
> > > }
> > >
> > > -static void finished_reading_packet(AVFormatContext *s, int
raw_packet_size)
> > > +static void finished_reading_packet(AVFormatContext *s, const uint8_t
*data, int raw_packet_size)
> > > {
> > > AVIOContext *pb = s->pb;
> > > int skip = raw_packet_size - TS_PACKET_SIZE;
> > > -if (skip > 0)
> > > +/* Check the next sync byte to avoid incorrectt detected raw packet
size */
> > > +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
> > > avio_skip(pb, skip);
> > > }
> > >
> > > @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts,
int64_t nb_packets)
> > > if (ret != 0)
> > > break;
> > > ret = handle_packet(ts, data, avio_tell(s->pb));
> > > -finished_reading_packet(s, ts->raw_packet_size);
> > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > if (ret != 0)
> > > break;
> > > }
> > > @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
> > > pid = AV_RB16(data + 1) & 0x1fff;
> > > if ((pcr_pid == -1 || pcr_pid == pid) &&
> > > parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> > > -finished_reading_packet(s, ts->raw_packet_size);
> > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > pcr_pid = pid;
> > > packet_count[nb_pcrs] = nb_packets;
> > > pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> > > @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
> > > }
> > > }
> > > } else {
> > > -finished_reading_packet(s, ts->raw_packet_size);
> > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > }
> > > nb_packets++;
> > > }
> > > @@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext
*s, AVPacket *pkt)
> > > }
> > > if (data != pkt->data)
> > > memcpy(pkt->data, data, ts->raw_packet_size);
> > > -finished_reading_packet(s, ts->raw_packet_size);
> > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > if (ts->mpeg2ts_compute_pcr) {
> > > /* compute exact PCR for each packet */
> > > if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> > > --
> > > 1.8.3.1
> > >
> > Do you have a case to reproduce the cc errors report?
>
> Yes, it's real case which can be reproduced in lab.
Can you share the sample?
No, tested with master and slave udp ts stream which switch between the master
and slave stream
more than five times, it'll cause tons of cc error report and can't be
recovered.
I suggest you capture the input, so this issue can be properly reproduced
and share it. It may even make sense to create a fate test from it.
Anyway, your patch does not seem right, because it seems to revert back
the packet size as soon as the first byte to be skipped is 0x47. That will
surely cause issues for normal streams having a packet size > 188.
Regards,
Marton
___
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".
