Re: [FFmpeg-devel] [PATCH]lavf/subviewerdec: Support higher sub-second precision
Am Fr., 20. März 2020 um 01:49 Uhr schrieb Michael Niedermayer
:
>
> On Thu, Mar 19, 2020 at 10:18:33PM +0100, Carl Eugen Hoyos wrote:
> > Am Do., 19. März 2020 um 19:32 Uhr schrieb Michael Niedermayer
> > :
> > >
> > > On Wed, Mar 18, 2020 at 02:16:30AM +0100, Carl Eugen Hoyos wrote:
> > > > Hi!
> > > >
> > > > Attached patch fixes ticket #8575 for me, Google describes such files.
> > > >
> > > > Please comment, Carl Eugen
> > >
> > > > subviewerdec.c | 10 +++---
> > > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > > > 1a6133ed3dbb66945d6bf16e212c0e77e3fd0579
> > > > 0001-lavf-subviewerdec-Support-higher-sub-second-precisio.patch
> > > > From 39d0748782bb3e37fb2f92c679ffa58b239374c7 Mon Sep 17 00:00:00 2001
> > > > From: Carl Eugen Hoyos
> > > > Date: Wed, 18 Mar 2020 02:11:33 +0100
> > > > Subject: [PATCH] lavf/subviewerdec: Support higher sub-second precision.
> > > >
> > > > Fixes ticket #8575.
> > > > ---
> > > > libavformat/subviewerdec.c | 10 +++---
> > > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/libavformat/subviewerdec.c b/libavformat/subviewerdec.c
> > > > index 06b827b70f..ed48b3388d 100644
> > > > --- a/libavformat/subviewerdec.c
> > > > +++ b/libavformat/subviewerdec.c
> > > > @@ -56,11 +56,15 @@ static int read_ts(const char *s, int64_t *start,
> > > > int *duration)
> > > > int64_t end;
> > > > int hh1, mm1, ss1, ms1;
> > > > int hh2, mm2, ss2, ms2;
> > > > +int multiplier = 1;
> > > >
> > > > +if (sscanf(s, "%u:%u:%u.%2u,%u:%u:%u.%2u",
> > > > + &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8)
> > > > +multiplier = 10;
> > > > if (sscanf(s, "%u:%u:%u.%u,%u:%u:%u.%u",
> > > > &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
> > >
> > > which lengths can the ms1 / ms2 part have ?
> > > do all of the following work ?
> > > x.1
> > > x.19
> > > x.199
> > > x.1999
> > >
> > > or are some of these guranteed not to occur ?
> >
> > I have no idea but my suspicion is that whoever created the files
> > in question misunderstood the original format.
>
> then i would suggest that the code either supports all variants of this
> or checks if the input is one of the supported ones.
> basically checking how long the ms1/ms2 fields are IIUC
New patch attached.
Thank you, Carl Eugen
From 17574e5cb44dead6990051540ada103610ee1e5b Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 20 Mar 2020 09:02:59 +0100
Subject: [PATCH] lavf/subviewerdec: Support higher sub-second precision.
Fixes ticket #8575.
---
libavformat/subviewerdec.c | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/libavformat/subviewerdec.c b/libavformat/subviewerdec.c
index 06b827b70f..83378eab5f 100644
--- a/libavformat/subviewerdec.c
+++ b/libavformat/subviewerdec.c
@@ -56,11 +56,21 @@ static int read_ts(const char *s, int64_t *start, int *duration)
int64_t end;
int hh1, mm1, ss1, ms1;
int hh2, mm2, ss2, ms2;
+int multiplier = 1;
+if (sscanf(s, "%u:%u:%u.%2u,%u:%u:%u.%2u",
+ &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
+multiplier = 10;
+} else if (sscanf(s, "%u:%u:%u.%1u,%u:%u:%u.%1u",
+ &hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
+multiplier = 100;
+}
if (sscanf(s, "%u:%u:%u.%u,%u:%u:%u.%u",
&hh1, &mm1, &ss1, &ms1, &hh2, &mm2, &ss2, &ms2) == 8) {
-end= (hh2*3600LL + mm2*60LL + ss2) * 100LL + ms2;
-*start = (hh1*3600LL + mm1*60LL + ss1) * 100LL + ms1;
+ms1 = FFMIN(ms1, 999);
+ms2 = FFMIN(ms2, 999);
+end= (hh2*3600LL + mm2*60LL + ss2) * 1000LL + ms2 * multiplier;
+*start = (hh1*3600LL + mm1*60LL + ss1) * 1000LL + ms1 * multiplier;
*duration = end - *start;
return 0;
}
@@ -84,7 +94,7 @@ static int subviewer_read_header(AVFormatContext *s)
return res;
if (avio_rb24(s->pb) != 0xefbbbf)
avio_seek(s->pb, -3, SEEK_CUR);
-avpriv_set_pts_info(st, 64, 1, 100);
+avpriv_set_pts_info(st, 64, 1, 1000);
st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
st->codecpar->codec_id = AV_CODEC_ID_SUBVIEWER;
--
2.24.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] avcodec/bsf: Don't set defaults for AVClass without options
Quoting Andreas Rheinhardt (2020-03-18 17:10:37) > Anton Khirnov: > > Quoting Andreas Rheinhardt (2020-03-17 22:31:46) > >> This happened for AVBSFContext. > >> > >> Signed-off-by: Andreas Rheinhardt > >> --- > > Maybe ok. Not sure if it's better to drop it because it's unused or keep > > it in case someone adds options later. > > > My opinion is that whoever adds the first option should add the > av_opt_set_default()/av_opt_free(), hence this patch. Okay, go ahead then. -- Anton Khirnov ___ 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/dashdec: fix memleak for commit commit e134c203
Quoting Steven Liu (2020-03-19 00:30:52) > > Thanks > > Steven Liu > > > 2020年3月19日 上午12:48，Andreas Rheinhardt 写道： > > > > Hello, > > > > before the actual review I want to tell you that I actually agree with > > Nicholas. I don't see the point of already parsing stuff that is not > > used yet, especially if it involves allocations and checks. > > Yes, I agreed with all of you, but I think we should try to "full > support all the attributes parse" what writes in the sepcification, > And try to use all the attribute. Because those attribute in the > specification is not useless and have some reason, I’m not member of > the specification author, You seem to be contradicting yourself. Either you agree that it is pointless to parse attributes that do not get used, in which case you shouldn't send patches that do precisely that. Or you believe that we should in fact parse things that do not get used, then you do not agree with the other commenters. Both at once are not possible. FWIW I believe that the entire point of demuxers is to export useful data to the caller. Therefore any code that does not contribute towards that goal is useless and should not be present in the tree. -- Anton Khirnov ___ 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/wavpack: Prevent frame format from being wrong
lgtm On 3/20/20, Michael Niedermayer wrote: > Fixes: out of array access > Fixes: > 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c > index b27262b94e..e9c870e41e 100644 > --- a/libavcodec/wavpack.c > +++ b/libavcodec/wavpack.c > @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, > int block_no, > > /* get output buffer */ > wc->curr_frame.f->nb_samples = s->samples; > +wc->curr_frame.f->format = avctx->sample_fmt; > if ((ret = ff_thread_get_buffer(avctx, &wc->curr_frame, > AV_GET_BUFFER_FLAG_REF)) < 0) > return ret; > > -- > 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 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/wavpack: Prevent frame format from being wrong
Quoting Michael Niedermayer (2020-03-20 01:03:36) > Fixes: out of array access > Fixes: > 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/wavpack.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c > index b27262b94e..e9c870e41e 100644 > --- a/libavcodec/wavpack.c > +++ b/libavcodec/wavpack.c > @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, > int block_no, > > /* get output buffer */ > wc->curr_frame.f->nb_samples = s->samples; > +wc->curr_frame.f->format = avctx->sample_fmt; How does this have any effect? curr_frame.f should now be clean and get initialized from avctx->sample_fmt. -- Anton Khirnov ___ 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/hevc, h2645_parse: Fix HEVC NAL unit names and constants
Quoting Andreas Rheinhardt (2020-03-18 14:41:23) > This commit fixes the names and constants of the reserved NAL units > with nal_unit_type 22 resp. 23. They were "IRAP_IRAP_VLC2x", but are > actually "RSV_IRAP_VLC2x". > > This also required a change to cbs_h265_syntax_template.c. > > Signed-off-by: Andreas Rheinhardt > --- Looks ok. > Should I realign the enum? Sure -- Anton Khirnov ___ 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/asfdec_f: Fix overflow check in get_tag()
Quoting Michael Niedermayer (2020-03-17 01:09:51) > Fixes: signed integer overflow: 2 * 1210064928 cannot be represented in type > 'int' > Fixes: > 20873/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5761116909338624 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- I suppose ok. -- Anton Khirnov ___ 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/dashdec: fix memleak for commit commit e134c203
> 2020年3月20日 下午4:34，Anton Khirnov 写道： > > Quoting Steven Liu (2020-03-19 00:30:52) >> >> Thanks >> >> Steven Liu >> >>> 2020年3月19日 上午12:48，Andreas Rheinhardt 写道： >>> >>> Hello, >>> >>> before the actual review I want to tell you that I actually agree with >>> Nicholas. I don't see the point of already parsing stuff that is not >>> used yet, especially if it involves allocations and checks. >> >> Yes, I agreed with all of you, but I think we should try to "full >> support all the attributes parse" what writes in the sepcification, >> And try to use all the attribute. Because those attribute in the >> specification is not useless and have some reason, I’m not member of >> the specification author, > > You seem to be contradicting yourself. Either you agree that it is > pointless to parse attributes that do not get used, in which case you > shouldn't send patches that do precisely that. > Or you believe that we should in fact parse things that do not get used, > then you do not agree with the other commenters. Both at once are not > possible. > > FWIW I believe that the entire point of demuxers is to export useful > data to the caller. Therefore any code that does not contribute towards > that goal is useless and should not be present in the tree. Why the specification add these attributes into the documents if these attributes not useful, just kidding? I said I’m not the specification author. But I see the specification said: for example: @minFrameRate O specifies the minimum @framerate value in all Representations in this Adaptation Set. This value is encoded in the same format as the @frameRate attribute. If not present, the value is unknown. Then, I think demuxer should give user warning message if the result is not same as specification, because it maybe will get wrong result if continue. I agree all of you is the precondition, because I need friendly comments, but I think I need think what you guys said, and think about how to make the demuxer better, Not just say something and don’t care about it, I add these attributes is just want make dashdec more standard support, not just partial support. Review patch welcome. > > -- > Anton Khirnov > ___ > 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/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20): > Why the specification add these attributes into the documents if these > attributes not useful, just kidding? > I said I’m not the specification author. What Anton and I are trying to explain to you is that either your code handles the attributes according to the specification, with actual technical consequences, or your code is useless. Getting the attribute, parsing it, getting it into a variable, carrying this variable around, and doing nothing with that variable is a waste of effort. For example, adaptionset_lang reaches the metadata dictionary, and is therefore available for the application: it's useful. On the other hand, adaptionset_minwidth is just stored in a variable and does nothing: get rid of if. Maybe later you'll come to implement something that uses adaptionset_minwidth: since you already wrote the code, you can commit all of it together. In short: don't build half a bridge, either build the whole bridge or keep the materials for later. 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] avformat/dashdec: fix memleak for commit commit e134c203
> 2020年3月20日 下午6:51，Nicolas George 写道： > > Steven Liu (12020-03-20): >> Why the specification add these attributes into the documents if these >> attributes not useful, just kidding? >> I said I’m not the specification author. > > What Anton and I are trying to explain to you is that either your code > handles the attributes according to the specification, with actual > technical consequences, or your code is useless. > > Getting the attribute, parsing it, getting it into a variable, carrying > this variable around, and doing nothing with that variable is a waste of > effort. > > For example, adaptionset_lang reaches the metadata dictionary, and is > therefore available for the application: it's useful. > > On the other hand, adaptionset_minwidth is just stored in a variable and > does nothing: get rid of if. > > Maybe later you'll come to implement something that uses > adaptionset_minwidth: since you already wrote the code, you can commit > all of it together. > > In short: don't build half a bridge, either build the whole bridge or > keep the materials for later. Do you mean, 1. I should add all the code in this patch, not make it two or four step complete the code? If this is right, I think I should submit version 3 to make that, 2. I just think send this patch first step to fix memleak, If this patch is ok I will send the second patch to use the minbw maxbw minframerate maxframerate, If the 2nd step is unnecessary, I can merge all the step in one patch and submit here. :D > > Regards, > > -- > Nicolas George 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/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20): > Do you mean, I mean you should only propose code that actually does something. That should be easy to understand: if you store into a variable without using the value, remove it; then iterate. 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] avformat/dashdec: fix memleak for commit commit e134c203
> 2020年3月20日 下午7:05，Nicolas George 写道： > > Steven Liu (12020-03-20): >> Do you mean, > > I mean you should only propose code that actually does something. That > should be easy to understand: if you store into a variable without using > the value, remove it; then iterate. Ok, I get it, thanks all of your suggestions. > > Regards, > > -- > Nicolas George 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 v2] avformat/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20):
> These member will be used for get more correct information of the MPD
>
> Suggested-by: Andreas Rheinhardt
> Suggested-by: Nicolas George
> Signed-off-by: Steven Liu
> ---
> libavformat/dashdec.c | 180 +++---
> 1 file changed, 151 insertions(+), 29 deletions(-)
>
> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
> index 5bbe5d3985..df8f30dcb5 100644
> --- a/libavformat/dashdec.c
> +++ b/libavformat/dashdec.c
> @@ -108,6 +108,7 @@ struct representation {
> int64_t cur_seg_offset;
> int64_t cur_seg_size;
> struct fragment *cur_seg;
> +char *lang;
>
> /* Currently active Media Initialization Section */
> struct fragment *init_section;
> @@ -122,19 +123,17 @@ struct representation {
> typedef struct DASHContext {
> const AVClass *class;
> char *base_url;
> -char *adaptionset_contenttype_val;
> -char *adaptionset_par_val;
> -char *adaptionset_lang_val;
> -char *adaptionset_minbw_val;
> -char *adaptionset_maxbw_val;
> -char *adaptionset_minwidth_val;
> -char *adaptionset_maxwidth_val;
> -char *adaptionset_minheight_val;
> -char *adaptionset_maxheight_val;
> -char *adaptionset_minframerate_val;
> -char *adaptionset_maxframerate_val;
> -char *adaptionset_segmentalignment_val;
> -char *adaptionset_bitstreamswitching_val;
> +char *adaptionset_lang;
> +uint64_t adaptionset_minbw;
> +uint64_t adaptionset_maxbw;
> +uint64_t adaptionset_minwidth;
> +uint64_t adaptionset_maxwidth;
> +uint64_t adaptionset_minheight;
> +uint64_t adaptionset_maxheight;
Unused: remove. Add later if you have something to do with it.
> +AVRational adaptionset_minframerate;
> +AVRational adaptionset_maxframerate;
> +int adaptionset_segmentalignment;
> +int adaptionset_bitstreamswitching;
Unused: remove.
>
> int n_videos;
> struct representation **videos;
> @@ -169,6 +168,51 @@ typedef struct DASHContext {
>
> } DASHContext;
>
> +#define DASH_GET_PROP_INT64(node, member, key) \
No reason to make it a macro: make it a function.
> +{ \
> +char *val = NULL; \
Useless initialization.
> +char *end_ptr = NULL; \
> +val = xmlGetProp((node), (key)); \
> +(member) = 0; \
This overwrites previous initializations, like "c->adaptionset_maxbw =
INT64_MAX".
> +if (val) { \
> +(member) = strtoull(val, &end_ptr, 10); \
If the value is syntactically incorrect, the error return value of
strtoull() will be stored in member, this is not good: use a temp
variable.
> +if (errno == ERANGE) \
> +av_log((s), AV_LOG_WARNING, "overflow/underflow when get value
> of %s\n", (key) ); \
And do nothing?
> +if (end_ptr == val || end_ptr[0] != '\0') { \
> +av_log(s, AV_LOG_ERROR, "The %s field value is " \
> +"not a valid number: %s\n", (key), val); \
> +xmlFree(val); \
> +return AVERROR(EINVAL); \
This is not an invalid value from the user, it's from a file:
INVALIDDATA.
Also, sometimes you treat an invalid value as an error, sometimes as a
warning: inconsistent.
> +} \
> +xmlFree(val); \
> +} \
> +}
> +
> +#define DASH_GET_PROP_RATIO(node, member, key) \
No need to make it a macro.
> +{ \
> +char *val = NULL; \
> +val = xmlGetProp((node), (key)); \
> +(member) = av_make_q(0, 0); \
Redundant init.
> +if (val) { \
> +ret = get_ratio_from_string(&(member), val); \
> +if (ret < 0) \
> +av_log(s, AV_LOG_WARNING, "Ignoring invalid %s frame rate
> '%s'\n", (key), val); \
> +xmlFree(val); \
> +} \
Leak.
> +}
> +
> +#define DASH_GET_PROP_BOOL(node, member, key) \
No need to make it a macro.
> +{ \
> +char *val = NULL; \
> +val = xmlGetProp((node), (key)); \
> +(member) = 0; \
Redundant init.
> +if (val) { \
> +if (!av_strcasecmp(val, "true")) \
> +(member) = 1; \
> +xmlFree(val); \
> +} \
Leak.
> +}
> +
> static int ishttp(char *url)
> {
> const char *proto_name = avio_find_protocol_name(url);
> @@ -406,6 +450,32 @@ static void free_subtitle_list(DASHContext *c)
> c->n_subtitles = 0;
> }
>
> +#define CHECK_STRTOL_RESULT(keystr, dest) \
> +{ \
> +char *end_ptr = NULL; \
> +if ((keystr)) { \
> +(dest) = (int) strtol(keystr, &end_ptr, 10); \
> +if (errno == ERANGE) { \
> +return AVERROR(ERANGE); \
> +} \
> +if (end_ptr == keystr || end_ptr[0] != '\0') { \
> +return AVERROR(EINVAL); \
> +} \
> +} \
> +}
> +static int get_ratio_from_string(AVRational *dst, char *src)
> +{
> +char *start = NULL;
> +char *end = NULL;
> +
> +dst->den = 1;
> +start = av_strtok(src, "/", &end);
> +CHECK_STRTOL_RESULT(start, dst->num)
> +CHECK_STRTOL_RESULT(end, dst->den)
end can be NULL. Don't use av_
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter: add vf_overlay_cuda
On 20.03.20 00:47, Timo Rothenpieler wrote: I'm looking into adding hardware-frame support to make_writable, so modifications might not be needed. Yep it seems to be more consistent if av_frame_make_writable could support hardware frames. Please let me know if you are going to do it, or if I need to send modified patch. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 2/2] avfilter: add vf_overlay_cuda
On 20.03.2020 12:30, Yaroslav Pogrebnyak wrote: On 20.03.20 00:47, Timo Rothenpieler wrote: I'm looking into adding hardware-frame support to make_writable, so modifications might not be needed. Yep it seems to be more consistent if av_frame_make_writable could support hardware frames. Please let me know if you are going to do it, or if I need to send modified patch. Thanks! It is not as simple as I anticipated to do it in a generic way. The main issue at hand is how nvdec returns hardware frames, which I need to fix first to get rid of a lot of hackery that stems from it. But I do intend to go along with it. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avformat/dashdec: fix memleak for commit commit e134c203
> 2020年3月20日 下午7:19，Nicolas George 写道：
>
> Steven Liu (12020-03-20):
>> These member will be used for get more correct information of the MPD
>>
>> Suggested-by: Andreas Rheinhardt
>> Suggested-by: Nicolas George
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/dashdec.c | 180 +++---
>> 1 file changed, 151 insertions(+), 29 deletions(-)
>>
>> diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
>> index 5bbe5d3985..df8f30dcb5 100644
>> --- a/libavformat/dashdec.c
>> +++ b/libavformat/dashdec.c
>> @@ -108,6 +108,7 @@ struct representation {
>> int64_t cur_seg_offset;
>> int64_t cur_seg_size;
>> struct fragment *cur_seg;
>> +char *lang;
>>
>> /* Currently active Media Initialization Section */
>> struct fragment *init_section;
>> @@ -122,19 +123,17 @@ struct representation {
>> typedef struct DASHContext {
>> const AVClass *class;
>> char *base_url;
>> -char *adaptionset_contenttype_val;
>> -char *adaptionset_par_val;
>> -char *adaptionset_lang_val;
>> -char *adaptionset_minbw_val;
>> -char *adaptionset_maxbw_val;
>> -char *adaptionset_minwidth_val;
>> -char *adaptionset_maxwidth_val;
>> -char *adaptionset_minheight_val;
>> -char *adaptionset_maxheight_val;
>> -char *adaptionset_minframerate_val;
>> -char *adaptionset_maxframerate_val;
>> -char *adaptionset_segmentalignment_val;
>> -char *adaptionset_bitstreamswitching_val;
>> +char *adaptionset_lang;
>> +uint64_t adaptionset_minbw;
>> +uint64_t adaptionset_maxbw;
>
>> +uint64_t adaptionset_minwidth;
>> +uint64_t adaptionset_maxwidth;
>> +uint64_t adaptionset_minheight;
>> +uint64_t adaptionset_maxheight;
>
> Unused: remove. Add later if you have something to do with it.
>
>> +AVRational adaptionset_minframerate;
>> +AVRational adaptionset_maxframerate;
>
>> +int adaptionset_segmentalignment;
>> +int adaptionset_bitstreamswitching;
>
> Unused: remove.
>
>>
>> int n_videos;
>> struct representation **videos;
>> @@ -169,6 +168,51 @@ typedef struct DASHContext {
>>
>> } DASHContext;
>>
>
>> +#define DASH_GET_PROP_INT64(node, member, key) \
>
> No reason to make it a macro: make it a function.
>
>> +{ \
>
>> +char *val = NULL; \
>
> Useless initialization.
>
>> +char *end_ptr = NULL; \
>> +val = xmlGetProp((node), (key)); \
>
>> +(member) = 0; \
>
> This overwrites previous initializations, like "c->adaptionset_maxbw =
> INT64_MAX".
>
>> +if (val) { \
>
>> +(member) = strtoull(val, &end_ptr, 10); \
>
> If the value is syntactically incorrect, the error return value of
> strtoull() will be stored in member, this is not good: use a temp
> variable.
>
>> +if (errno == ERANGE) \
>> +av_log((s), AV_LOG_WARNING, "overflow/underflow when get value
>> of %s\n", (key) ); \
>
> And do nothing?
>
>> +if (end_ptr == val || end_ptr[0] != '\0') { \
>> +av_log(s, AV_LOG_ERROR, "The %s field value is " \
>> +"not a valid number: %s\n", (key), val); \
>> +xmlFree(val); \
>
>> +return AVERROR(EINVAL); \
>
> This is not an invalid value from the user, it's from a file:
> INVALIDDATA.
>
> Also, sometimes you treat an invalid value as an error, sometimes as a
> warning: inconsistent.
>
>> +} \
>> +xmlFree(val); \
>> +} \
>> +}
>> +
>
>> +#define DASH_GET_PROP_RATIO(node, member, key) \
>
> No need to make it a macro.
>
>> +{ \
>> +char *val = NULL; \
>> +val = xmlGetProp((node), (key)); \
>
>> +(member) = av_make_q(0, 0); \
>
> Redundant init.
>
>> +if (val) { \
>> +ret = get_ratio_from_string(&(member), val); \
>> +if (ret < 0) \
>> +av_log(s, AV_LOG_WARNING, "Ignoring invalid %s frame rate
>> '%s'\n", (key), val); \
>> +xmlFree(val); \
>> +} \
>
> Leak.
Which one leak? if xmlGetProp return null, val should null and dose not leak.
/**
* xmlGetProp:
* @node: the node
* @name: the attribute name
*
* Search and get the value of an attribute associated to a node
* This does the entity substitution.
* This function looks in DTD attribute declaration for #FIXED or
* default declaration values unless DTD use has been turned off.
* NOTE: this function acts independently of namespaces associated
* to the attribute. Use xmlGetNsProp() or xmlGetNoNsProp()
* for namespace aware processing.
*
* Returns the attribute value or NULL if not found.
* It's up to the caller to free the memory with xmlFree().
*/
xmlChar *
xmlGetProp(const xmlNode *node, const xmlChar *name) {
xmlAttrPtr prop;
prop = xmlHasProp(node, name);
if (prop == NULL)
return(NULL);
return(xmlGetPropNodeValueInternal(prop));
}
>
>> +}
>> +
>> +#define DASH_GET_PROP_BOOL(node, member, key) \
>
> No need to make it a macro.
>
>> +{ \
>> +char *val = NULL; \
>> +val =
Re: [FFmpeg-devel] [PATCH v2] avformat/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20): > Which one leak? if xmlGetProp return null, val should null and dose not leak. Yes, my mistake. > The end can be null, there can only maxFrameRate=25, or maxFrameRate=60/2. It is a value from the outside, you can't trust it on pail of security exploit. > Just tell the user this value is incorrect in mpd, the result maybe does not > accord with the expected result. > User should check the mpd file content is correct. Which user knows about the mpd? 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 v2] avformat/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20): > To: Nicolas George Please heed reply-to headers. 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 v2] avformat/dashdec: fix memleak for commit commit e134c203
> 2020年3月20日 下午8:25，Nicolas George 写道： > >> The end can be null, there can only maxFrameRate=25, or maxFrameRate=60/2. > > It is a value from the outside, you can't trust it on pail of security > exploit. Yes, av_strtok get the first part and the other part, And use the strtol get the first part to long, it check the string range, and get the endpoint of (not number part.) The end is same as the first part. I cannot sure if I misunderstand the usage, I think I need one example of the security exploit. > >> Just tell the user this value is incorrect in mpd, the result maybe does not >> accord with the expected result. >> User should check the mpd file content is correct. > > Which user knows about the mpd? I think you are right , let me think how to do it. 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 v2] avformat/dashdec: fix memleak for commit commit e134c203
Steven Liu (12020-03-20): > Yes, av_strtok get the first part and the other part, > And use the strtol get the first part to long, it check the string range, and > get the endpoint of (not number part.) > The end is same as the first part. My exact comment was wrong. The actual problem is that av_strtok() does not tell you the semantic of saveptr, you can therefore only use it as an argument to another call to av_strtok(). 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] avcodec: add bink2 video decoder
On 3/20/2020 10:31 AM, Paul B Mahol wrote:
> +static av_cold int bink2_decode_end(AVCodecContext *avctx)
> +{
> +Bink2Context * const c = avctx->priv_data;
> +
> +av_frame_free(&c->last);
> +av_freep(&c->current_q);
> +av_freep(&c->prev_q);
> +av_freep(&c->current_dc);
> +av_freep(&c->prev_dc);
> +av_freep(&c->current_idc);
> +av_freep(&c->prev_idc);
> +av_freep(&c->current_mv);
> +av_freep(&c->prev_mv);
> +av_freep(&c->col_cbp);
> +av_freep(&c->row_cbp);
> +
> +return 0;
> +}
> +
> +AVCodec ff_bink2_decoder = {
> +.name = "binkvideo2",
> +.long_name = NULL_IF_CONFIG_SMALL("Bink video 2"),
> +.type = AVMEDIA_TYPE_VIDEO,
> +.id = AV_CODEC_ID_BINKVIDEO2,
> +.priv_data_size = sizeof(Bink2Context),
> +.init = bink2_decode_init,
> +.close = bink2_decode_end,
> +.decode = bink2_decode_frame,
> +.capabilities = AV_CODEC_CAP_DR1,
> +};
Missing a flush() callback unreffing c->last, and probably also zeroing
some of the above arrays.
___
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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
From: Limin Wang
This fixes webvtt segment output.
Please testing with the following command and check the output:
./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment
-segment_time 10 \
-segment_list_size 0 -segment_list sub.m3u8 -segment_format webvtt -scodec
webvtt sub-%d.vtt
Signed-off-by: Limin Wang
---
fftools/ffmpeg.c | 1 +
tests/ref/fate/binsub-movtextenc | 2 +-
tests/ref/fate/sub2video | 86
3 files changed, 45 insertions(+), 44 deletions(-)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index aaaf241314..c5a2d0731d 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
else
pkt.pts += av_rescale_q(sub->end_display_time, (AVRational){
1, 1000 }, ost->mux_timebase);
}
+pkt.flags |= AV_PKT_FLAG_KEY;
pkt.dts = pkt.pts;
output_packet(of, &pkt, ost, 0);
}
diff --git a/tests/ref/fate/binsub-movtextenc b/tests/ref/fate/binsub-movtextenc
index 78c05f4376..a8f94b7227 100644
--- a/tests/ref/fate/binsub-movtextenc
+++ b/tests/ref/fate/binsub-movtextenc
@@ -1 +1 @@
-35adf776cd73e808186ae7124445f4b8
+fc6d07679ac1f718aa50de687924cd97
diff --git a/tests/ref/fate/sub2video b/tests/ref/fate/sub2video
index 4e034a5e91..80abe9c905 100644
--- a/tests/ref/fate/sub2video
+++ b/tests/ref/fate/sub2video
@@ -10,7 +10,7 @@
0, 0, 0,1, 518400, 0x83c27b82
0, 1, 1,1, 518400, 0x4051c7f9
0, 2, 2,1, 518400, 0xfb00e17e
-1, 499000, 499000, 496, 1015, 0x19e092d2, F=0x0
+1, 499000, 499000, 496, 1015, 0x19e092d2
0, 3, 3,1, 518400, 0x192abb74
0, 4, 4,1, 518400, 0x4669a88b
0, 5, 5,1, 518400, 0xaababe00
@@ -58,129 +58,129 @@
0, 47, 47,1, 518400, 0xde69683f
0, 48, 48,1, 518400, 0x7df08fba
0, 49, 49,1, 518400, 0xbab197ea
-1, 15355000, 15355000, 4733000, 2094, 0x3c171425, F=0x0
+1, 15355000, 15355000, 4733000, 2094, 0x3c171425
0, 77, 77,1, 518400, 0x902285d9
0,100,100,1, 518400, 0xbab197ea
-1, 48797000, 48797000, 256, 2480, 0x7c0edf21, F=0x0
+1, 48797000, 48797000, 256, 2480, 0x7c0edf21
0,244,244,1, 518400, 0x7a11c812
0,257,257,1, 518400, 0xbab197ea
-1, 51433000, 51433000, 2366000, 3059, 0xc95b8a05, F=0x0
+1, 51433000, 51433000, 2366000, 3059, 0xc95b8a05
0,258,258,1, 518400, 0x34cdddee
0,269,269,1, 518400, 0xbab197ea
-1, 5391, 5391, 2696000, 2095, 0x61bb15ed, F=0x0
+1, 5391, 5391, 2696000, 2095, 0x61bb15ed
0,270,270,1, 518400, 0x4db4ce51
0,283,283,1, 518400, 0xbab197ea
-1, 56663000, 56663000, 1262000, 1013, 0xc9ae89b7, F=0x0
+1, 56663000, 56663000, 1262000, 1013, 0xc9ae89b7
0,284,284,1, 518400, 0xe6bc0ea9
0,290,290,1, 518400, 0xbab197ea
-1, 58014000, 58014000, 1661000, 969, 0xe01878f0, F=0x0
+1, 58014000, 58014000, 1661000, 969, 0xe01878f0
0,291,291,1, 518400, 0xa8643af7
0,298,298,1, 518400, 0xbab197ea
-1, 67724000, 67724000, 1365000, 844, 0xe7db4fc1, F=0x0
+1, 67724000, 67724000, 1365000, 844, 0xe7db4fc1
0,339,339,1, 518400, 0xb1885c67
0,345,345,1, 518400, 0xbab197ea
-1, 69175000, 69175000, 1558000, 802, 0xf48531ba, F=0x0
+1, 69175000, 69175000, 1558000, 802, 0xf48531ba
0,346,346,1, 518400, 0x378e3fd0
0,354,354,1, 518400, 0xbab197ea
-1, 70819000, 70819000, 1865000, 1709, 0xb4d5a1bd, F=0x0
+1, 70819000, 70819000, 1865000, 1709, 0xb4d5a1bd
0,355,355,1, 518400, 0xa3782469
0,363,363,1, 518400, 0xbab197ea
-1, 72762000, 72762000, 1968000, 2438, 0x99d7bc82, F=0x0
+1, 72762000, 72762000, 1968000, 2438, 0x99d7bc82
0,364,364,1, 518400, 0xba23a0d5
0,374,374,1, 518400, 0xbab197ea
-1, 74806000, 74806000, 1831000, 2116, 0x96514097, F=0x0
+1, 74806000, 74806000, 1831000, 2116, 0x96514097
0,375,375,1, 518400, 0x129de2f8
0,383,383,1, 518400, 0xbab197ea
-1, 76716000, 76716000, 1262000, 1822, 0xefccc72e, F=0x0
+1, 76716000, 76716000, 1262000, 1822, 0xefccc72e
0,384,384,1, 518400, 0x19772f0f
0,
[FFmpeg-devel] [PATCH] avformat/argo_asf: add missing #include
Fixes the use of the implicit declaration
of avpriv_request_sample().
Signed-off-by: Zane van Iperen
---
libavformat/argo_asf.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/argo_asf.c b/libavformat/argo_asf.c
index 3339425244..cf1c7472c1 100644
--- a/libavformat/argo_asf.c
+++ b/libavformat/argo_asf.c
@@ -23,6 +23,7 @@
#include "internal.h"
#include "libavutil/intreadwrite.h"
#include "libavutil/avassert.h"
+#include "libavutil/internal.h"
#define ASF_TAG MKTAG('A', 'S', 'F', '\0')
#define ASF_FILE_HEADER_SIZE24
--
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 2/2] avcodec/wavpack: Prevent frame format from being wrong
On 3/20/20 1:54 AM, Paul B Mahol wrote: > lgtm Looks good to me too, sorry about that! > > On 3/20/20, Michael Niedermayer wrote: >> Fixes: out of array access >> Fixes: >> 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 >> >> Found-by: continuous fuzzing process >> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> Signed-off-by: Michael Niedermayer >> --- >> libavcodec/wavpack.c | 1 + >> 1 file changed, 1 insertion(+) >> >> diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c >> index b27262b94e..e9c870e41e 100644 >> --- a/libavcodec/wavpack.c >> +++ b/libavcodec/wavpack.c >> @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext *avctx, >> int block_no, >> >> /* get output buffer */ >> wc->curr_frame.f->nb_samples = s->samples; >> +wc->curr_frame.f->format = avctx->sample_fmt; >> if ((ret = ff_thread_get_buffer(avctx, &wc->curr_frame, >> AV_GET_BUFFER_FLAG_REF)) < 0) >> return ret; >> >> -- >> 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 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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Fri, Mar 20, 2020 at 5:45 PM wrote:
>
> From: Limin Wang
>
> This fixes webvtt segment output.
>
> Please testing with the following command and check the output:
> ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment
> -segment_time 10 \
> -segment_list_size 0 -segment_list sub.m3u8 -segment_format webvtt
> -scodec webvtt sub-%d.vtt
>
>
> Signed-off-by: Limin Wang
> ---
> fftools/ffmpeg.c | 1 +
> tests/ref/fate/binsub-movtextenc | 2 +-
> tests/ref/fate/sub2video | 86
> 3 files changed, 45 insertions(+), 44 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index aaaf241314..c5a2d0731d 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> else
> pkt.pts += av_rescale_q(sub->end_display_time, (AVRational){
> 1, 1000 }, ost->mux_timebase);
> }
> +pkt.flags |= AV_PKT_FLAG_KEY;
> pkt.dts = pkt.pts;
> output_packet(of, &pkt, ost, 0);
> }
I do wonder if this is just a case of people forgetting to set the
flag for the relevant packets in the relevant modules?
I'm not sure if all API users should be forced to handle this
separately. If the packets are decode'able by themselves, they should
be marked as such.
(Unfortunately, this probably means that all subtitle encoders and
text-based subtitle format demuxers would have to be updated where
this flag is not set)
Best regards,
Jan
___
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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
Jan Ekström (12020-03-20): > I do wonder if this is just a case of people forgetting to set the > flag for the relevant packets in the relevant modules? > > I'm not sure if all API users should be forced to handle this > separately. If the packets are decode'able by themselves, they should > be marked as such. I had the same idea, and I checked: the problem is that the subtitle encoding API returns just a buffer of data, not a packet. With that crappy API, this change is the best we can do. 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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Fri, Mar 20, 2020 at 6:12 PM Nicolas George wrote: > > Jan Ekström (12020-03-20): > > I do wonder if this is just a case of people forgetting to set the > > flag for the relevant packets in the relevant modules? > > > > I'm not sure if all API users should be forced to handle this > > separately. If the packets are decode'able by themselves, they should > > be marked as such. > > I had the same idea, and I checked: the problem is that the subtitle > encoding API returns just a buffer of data, not a packet. With that > crappy API, this change is the best we can do. > Just as I noticed that myself in ffmpeg.c :). In that case, yes... Until the encoding API pushes out AVPackets we can't help too much with this :/ . Consider my initial comment moot. Jan ___ 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] Re?? [PATCH v3] examples/extract_mvs.c: don't disply motionless vectors
> LGTM without comments. > > On 3/17/20, numberwolf 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". ping. Thanks ___ 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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
Jan Ekström:
> On Fri, Mar 20, 2020 at 5:45 PM wrote:
>>
>> From: Limin Wang
>>
>> This fixes webvtt segment output.
>>
>> Please testing with the following command and check the output:
>> ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment
>> -segment_time 10 \
>> -segment_list_size 0 -segment_list sub.m3u8 -segment_format webvtt
>> -scodec webvtt sub-%d.vtt
>>
>>
>> Signed-off-by: Limin Wang
>> ---
>> fftools/ffmpeg.c | 1 +
>> tests/ref/fate/binsub-movtextenc | 2 +-
>> tests/ref/fate/sub2video | 86
>> 3 files changed, 45 insertions(+), 44 deletions(-)
>>
>> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
>> index aaaf241314..c5a2d0731d 100644
>> --- a/fftools/ffmpeg.c
>> +++ b/fftools/ffmpeg.c
>> @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
>> else
>> pkt.pts += av_rescale_q(sub->end_display_time,
>> (AVRational){ 1, 1000 }, ost->mux_timebase);
>> }
>> +pkt.flags |= AV_PKT_FLAG_KEY;
>> pkt.dts = pkt.pts;
>> output_packet(of, &pkt, ost, 0);
>> }
>
> I do wonder if this is just a case of people forgetting to set the
> flag for the relevant packets in the relevant modules?
>
> I'm not sure if all API users should be forced to handle this
> separately. If the packets are decode'able by themselves, they should
> be marked as such.
>
> (Unfortunately, this probably means that all subtitle encoders and
> text-based subtitle format demuxers would have to be updated where
> this flag is not set)
>
av_read_frame() already sets the AV_PKT_FLAG_KEY-flag for all subtitle
packets (see is_intra_only() in libavformat/utils.c; the subtitle
demuxer based around FFDemuxSubtitlesQueues actually have the flag set
even before it reaches is_intra_only()). One could do something similar
in libavformat/mux.c.
But are we actually sure that all subtitle packets are decodable by
themselves? IIRC this is not true for all PGS subtitles.
- Andreas
PS: The semantics of the AV_CODEC_PROP_INTRA_ONLY-flag seem to be based
around the assumption that subtitle packets are always intra-only: It is
only for video and audio-codecs only.
___
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: add bink2 video decoder
On Fri, Mar 20, 2020 at 9:31 AM Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure |1 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c |1 +
> libavcodec/avcodec.h|1 +
> libavcodec/bink2.c | 869
> libavcodec/bink2f.c | 1125
> libavcodec/bink2g.c | 1197 +++
> libavcodec/codec_desc.c |7 +
> libavformat/bink.c |3 +-
> 9 files changed, 3203 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/bink2.c
> create mode 100644 libavcodec/bink2f.c
> create mode 100644 libavcodec/bink2g.c
>
> diff --git a/configure b/configure
> index 18f2841765..1d89d49b41 100755
> --- a/configure
> +++ b/configure
> @@ -2678,6 +2678,7 @@ atrac3pal_decoder_select="mdct sinewin"
> atrac9_decoder_select="mdct"
> avrn_decoder_select="exif jpegtables"
> bink_decoder_select="blockdsp hpeldsp"
> +bink2_decoder_select="blockdsp"
> binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
> binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs"
> cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index c1c9a44f2b..a79b4c6524 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -230,6 +230,7 @@ OBJS-$(CONFIG_AYUV_ENCODER)+= v408enc.o
> OBJS-$(CONFIG_BETHSOFTVID_DECODER) += bethsoftvideo.o
> OBJS-$(CONFIG_BFI_DECODER) += bfi.o
> OBJS-$(CONFIG_BINK_DECODER)+= bink.o binkdsp.o
> +OBJS-$(CONFIG_BINK2_DECODER) += bink2.o
> OBJS-$(CONFIG_BINKAUDIO_DCT_DECODER) += binkaudio.o
> OBJS-$(CONFIG_BINKAUDIO_RDFT_DECODER) += binkaudio.o
> OBJS-$(CONFIG_BINTEXT_DECODER) += bintext.o cga_data.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b3184af954..d032547a9d 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -60,6 +60,7 @@ extern AVCodec ff_ayuv_decoder;
> extern AVCodec ff_bethsoftvid_decoder;
> extern AVCodec ff_bfi_decoder;
> extern AVCodec ff_bink_decoder;
> +extern AVCodec ff_bink2_decoder;
> extern AVCodec ff_bitpacked_decoder;
> extern AVCodec ff_bmp_encoder;
> extern AVCodec ff_bmp_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 78c483c25c..e8b20fa527 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -463,6 +463,7 @@ enum AVCodecID {
> AV_CODEC_ID_MVDV,
> AV_CODEC_ID_MVHA,
> AV_CODEC_ID_CDTOONS,
> +AV_CODEC_ID_BINKVIDEO2,
>
> /* various PCM "codecs" */
> AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/bink2.c b/libavcodec/bink2.c
> new file mode 100644
> index 00..0ebce7feeb
> --- /dev/null
> +++ b/libavcodec/bink2.c
> @@ -0,0 +1,869 @@
> +/*
> + * Bink video 2 decoder
> + * Copyright (c) 2014 Konstantin Shishkov
> + * Copyright (c) 2019 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/attributes.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "avcodec.h"
> +#include "blockdsp.h"
> +#include "copy_block.h"
> +#include "idctdsp.h"
> +#include "internal.h"
> +#include "mathops.h"
> +
> +#define BITSTREAM_READER_LE
> +#include "get_bits.h"
> +#include "unary.h"
> +
> +#define BINK_FLAG_ALPHA 0x0010
> +#define DC_MPRED(A, B, C) FFMIN(FFMAX((C) + (B) - (A), FFMIN3(A, B, C)),
> FFMAX3(A, B, C))
> +#define DC_MPRED2(A, B) FFMIN(FFMAX((A), (B)), FFMAX(FFMIN((A), (B)), 2 *
> (A) - (B)))
> +
> +static VLC bink2f_quant_vlc;
> +static VLC bink2f_ac_val0_vlc;
> +static VLC bink2f_ac_val1_vlc;
> +static VLC bink2f_ac_skip0_vlc;
> +static VLC bink2f_ac_skip1_vlc;
> +static VLC bink2g_ac_skip0_vlc;
> +static VLC bink2g_ac_skip1_vlc;
> +static VLC bink2g_mv_vlc;
> +
> +static const uint8_t kb2h_num_slices[] = {
> +2, 3, 4, 8,
> +};
> +
> +static const uint8_t luma_repos[] = {
> +0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15,
> +};
> +
> +static const uint16_t bink2g_luma_intra_qmat[4][64]
Re: [FFmpeg-devel] [PATCH 1/3] lavformat: Prepare to make avio_enum_protocols const correct
On 21/08/2019 10:04, Andreas Rheinhardt wrote: > +#if FF_API_NONCONST_ENUM_PROTOCOLS > const char *avio_enum_protocols(void **opaque, int output) > +#else > +const char *avio_enum_protocols(const void **opaque, int output) > +#endif Do we actually allow breakage like this (even at major bumps)? That is, you are not using a new function name, but breaking an existing function signature. As far as I know, this is not somthing that we, or semver, allow. - 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 2/2] avcodec/wavpack: Prevent frame format from being wrong
On Fri, Mar 20, 2020 at 10:18:49AM +0100, Anton Khirnov wrote: > Quoting Michael Niedermayer (2020-03-20 01:03:36) > > Fixes: out of array access > > Fixes: > > 21193/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WAVPACK_fuzzer-5125168956702720 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/wavpack.c | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c > > index b27262b94e..e9c870e41e 100644 > > --- a/libavcodec/wavpack.c > > +++ b/libavcodec/wavpack.c > > @@ -1488,6 +1488,7 @@ static int wavpack_decode_block(AVCodecContext > > *avctx, int block_no, > > > > /* get output buffer */ > > wc->curr_frame.f->nb_samples = s->samples; > > +wc->curr_frame.f->format = avctx->sample_fmt; > > How does this have any effect? curr_frame.f should now be clean and get > initialized from avctx->sample_fmt. IIRC The format changes between frames, so the struct is still set to the one from the previous frame and that overrides the use of the avctx value setting it to NONE (here or somewhere else) should work too. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes 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/3] lavformat: Prepare to make avio_enum_protocols const correct
Am Fr., 20. März 2020 um 19:33 Uhr schrieb Derek Buitenhuis : > > On 21/08/2019 10:04, Andreas Rheinhardt wrote: > > +#if FF_API_NONCONST_ENUM_PROTOCOLS > > const char *avio_enum_protocols(void **opaque, int output) > > +#else > > +const char *avio_enum_protocols(const void **opaque, int output) > > +#endif > > Do we actually allow breakage like this (even at major bumps)? > > That is, you are not using a new function name, but breaking an existing > function signature. As far as I know, this is not somthing that we, or > semver, allow. We are only breaking it for C++ users, right? 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] avformat/argo_asf: add missing #include
Am Fr., 20. März 2020 um 16:53 Uhr schrieb Zane van Iperen : > > Fixes the use of the implicit declaration > of avpriv_request_sample(). I don't see such a warning... 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] Re： [PATCH v3] examples/extract_mvs.c: don't disply motionless vectors
Am Fr., 20. März 2020 um 17:59 Uhr schrieb porscheg...@foxmail.com : > > LGTM without comments. > > > ping. Please resend your patch without the comments (and the mail without the html codes). 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 1/3] lavformat: Prepare to make avio_enum_protocols const correct
Derek Buitenhuis: > On 21/08/2019 10:04, Andreas Rheinhardt wrote: >> +#if FF_API_NONCONST_ENUM_PROTOCOLS >> const char *avio_enum_protocols(void **opaque, int output) >> +#else >> +const char *avio_enum_protocols(const void **opaque, int output) >> +#endif > > Do we actually allow breakage like this (even at major bumps)? > > That is, you are not using a new function name, but breaking an existing > function signature. As far as I know, this is not somthing that we, or > semver, allow. There have been several such breakages in the past, at least in relation to const: Looking through some headers with git blame leads to the following commits which add const to the type of the pointed-to type: 9b07d34e, b90d7840, 53abe324, c4ba5198, 069cf86d, 0d34dbc2, 5bb3f882, adb0e941, 0a0f19b5, 2d3acbfe, 74aeb6b5, 7215fcf8, 77cc958f, 4a37d4b3, cc4c2420, 0020c54c. 2d3acbfe furthermore changed the return value of a public function from AVCodecDescriptor * to const AVCodecDescriptor *; f2c86705 and 5c439b41 did something similar. Except for f2c86705, none of these commits bumped any version. None added an APIchanges entry; 5c439b41 was the only one that waited until the next major version bump with its changes. Furthermore, several such changes are planned for libavformat. Just search for ff_const59 in avformat.h. 3aa6208d even changed AVInputFormat ** to const AVInputFormat **. (I pondered whether I should piggyback on this (and use ff_const59 myself), but in the end decided against it. I'd choose differently now.) Furthermore, I don't see where semver disallows changing the signature of a function. After all, breaking changes are explicitly allowed at major version bumps. But we should probably add an entry in APIchanges for this change and all the other ff_const59 changes. (Looking through APIchanges also leads to 2c031741 and 84c03869, but given that the latter of these only incremented minor despite breaking API/ABI and the former didn't increment the version at all despite breaking API/ABI makes them bad precedents. Lest I forget: av_malloc() and other memory-allocation functions did not start with size_t parameters.) - Andreas PS: Actually, there are a couple of functions that need const: av_find_best_stream() provides a way to get a pointer to a non-const AVCodec (it casts the const away internally); and av_input/output_audio/video_device_next() needs either be modified to work with const or be deprecated altogether (as the other _next-APIs have been). ___ 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/3] lavformat: Prepare to make avio_enum_protocols const correct
Am Fr., 20. März 2020 um 23:29 Uhr schrieb Andreas Rheinhardt : > PS: Actually, there are a couple of functions that need const: > av_find_best_stream() provides a way to get a pointer to a non-const > AVCodec (it casts the const away internally); and > av_input/output_audio/video_device_next() needs either be modified to > work with const or be deprecated altogether (as the other _next-APIs > have been). Will you work on constifying this functions? 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 1/3] lavformat: Prepare to make avio_enum_protocols const correct
Carl Eugen Hoyos: > Am Fr., 20. März 2020 um 23:29 Uhr schrieb Andreas Rheinhardt > : > >> PS: Actually, there are a couple of functions that need const: >> av_find_best_stream() provides a way to get a pointer to a non-const >> AVCodec (it casts the const away internally); and >> av_input/output_audio/video_device_next() needs either be modified to >> work with const or be deprecated altogether (as the other _next-APIs >> have been). > > Will you work on constifying this functions? > Feel free to do it if you like. - Andreas PS: AVCodecParser should probably be made const on the next bump, too; unfortunately 7e8eba2d forgot to deprecate the AVCodecParser.next field. ___ 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 v1] fftools/ffmpeg: set AV_PKT_FLAG_KEY for the subtitle packet
On Fri, Mar 20, 2020 at 06:03:53PM +0200, Jan Ekström wrote:
> On Fri, Mar 20, 2020 at 5:45 PM wrote:
> >
> > From: Limin Wang
> >
> > This fixes webvtt segment output.
> >
> > Please testing with the following command and check the output:
> > ./ffmpeg -i ../fate-suite/sub/MicroDVD_capability_tester.srt -f segment
> > -segment_time 10 \
> > -segment_list_size 0 -segment_list sub.m3u8 -segment_format webvtt
> > -scodec webvtt sub-%d.vtt
> >
> >
> > Signed-off-by: Limin Wang
> > ---
> > fftools/ffmpeg.c | 1 +
> > tests/ref/fate/binsub-movtextenc | 2 +-
> > tests/ref/fate/sub2video | 86
> > 3 files changed, 45 insertions(+), 44 deletions(-)
> >
> > diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> > index aaaf241314..c5a2d0731d 100644
> > --- a/fftools/ffmpeg.c
> > +++ b/fftools/ffmpeg.c
> > @@ -1054,6 +1054,7 @@ static void do_subtitle_out(OutputFile *of,
> > else
> > pkt.pts += av_rescale_q(sub->end_display_time,
> > (AVRational){ 1, 1000 }, ost->mux_timebase);
> > }
> > +pkt.flags |= AV_PKT_FLAG_KEY;
> > pkt.dts = pkt.pts;
> > output_packet(of, &pkt, ost, 0);
> > }
>
> I do wonder if this is just a case of people forgetting to set the
> flag for the relevant packets in the relevant modules?
>
> I'm not sure if all API users should be forced to handle this
> separately. If the packets are decode'able by themselves, they should
> be marked as such.
If we're using -c:s copy for the subtitle, the flag is set in
ff_subtitles_queue_insert() of libavformat/subtitles.c.
>
> (Unfortunately, this probably means that all subtitle encoders and
> text-based subtitle format demuxers would have to be updated where
> this flag is not set)
subtitle encoder haven no way to set the flag in the encoder api now.
>
> Best regards,
> Jan
> ___
> 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,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/argo_asf: add missing #include
On Fri, 20 Mar 2020 22:28:28 +0100 "Carl Eugen Hoyos" wrote: > Am Fr., 20. März 2020 um 16:53 Uhr schrieb Zane van Iperen > : > > > > Fixes the use of the implicit declaration > > of avpriv_request_sample(). > > I don't see such a warning... > Yeah sorry, was something screwy going on. Re-./configure'd and the warning's gone. Zane > 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 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]common.mak: Also clean Windows debug files
On Thu, Mar 19, 2020 at 12:39 AM Carl Eugen Hoyos wrote: > > Hi! > > Without this patch, make clean (and make distclean) do not delete > ffmpeg_g.ilk and ffmpeg_g.pdb (and friends). > LGTM ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/bethsoftvid: Avoid allocations and frees for palettes
by putting the palette in the demuxer's context. This also allows to
remove this demuxer's read_close-function.
Signed-off-by: Andreas Rheinhardt
---
libavformat/bethsoftvid.c | 24 ++--
1 file changed, 6 insertions(+), 18 deletions(-)
diff --git a/libavformat/bethsoftvid.c b/libavformat/bethsoftvid.c
index 4aefb04f14..e52b17433c 100644
--- a/libavformat/bethsoftvid.c
+++ b/libavformat/bethsoftvid.c
@@ -49,7 +49,8 @@ typedef struct BVID_DemuxContext
int bethsoft_global_delay;
int video_index;/**< video stream index */
int audio_index;/**< audio stream index */
-uint8_t *palette;
+int has_palette;
+uint8_t palette[BVID_PALETTE_SIZE];
int is_finished;
@@ -188,7 +189,7 @@ static int read_frame(BVID_DemuxContext *vid, AVIOContext
*pb, AVPacket *pkt,
pkt->flags |= AV_PKT_FLAG_KEY;
/* if there is a new palette available, add it to packet side data */
-if (vid->palette) {
+if (vid->has_palette) {
uint8_t *pdata = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE,
BVID_PALETTE_SIZE);
if (!pdata) {
@@ -197,8 +198,6 @@ static int read_frame(BVID_DemuxContext *vid, AVIOContext
*pb, AVPacket *pkt,
goto fail;
}
memcpy(pdata, vid->palette, BVID_PALETTE_SIZE);
-
-av_freep(&vid->palette);
}
vid->nframes--; // used to check if all the frames were read
@@ -222,17 +221,14 @@ static int vid_read_packet(AVFormatContext *s,
block_type = avio_r8(pb);
switch(block_type){
case PALETTE_BLOCK:
-if (vid->palette) {
+if (vid->has_palette) {
av_log(s, AV_LOG_WARNING, "discarding unused palette\n");
-av_freep(&vid->palette);
+vid->has_palette = 0;
}
-vid->palette = av_malloc(BVID_PALETTE_SIZE);
-if (!vid->palette)
-return AVERROR(ENOMEM);
if (avio_read(pb, vid->palette, BVID_PALETTE_SIZE) !=
BVID_PALETTE_SIZE) {
-av_freep(&vid->palette);
return AVERROR(EIO);
}
+vid->has_palette = 1;
return vid_read_packet(s, pkt);
case FIRST_AUDIO_BLOCK:
@@ -284,13 +280,6 @@ static int vid_read_packet(AVFormatContext *s,
}
}
-static int vid_read_close(AVFormatContext *s)
-{
-BVID_DemuxContext *vid = s->priv_data;
-av_freep(&vid->palette);
-return 0;
-}
-
AVInputFormat ff_bethsoftvid_demuxer = {
.name = "bethsoftvid",
.long_name = NULL_IF_CONFIG_SMALL("Bethesda Softworks VID"),
@@ -298,5 +287,4 @@ AVInputFormat ff_bethsoftvid_demuxer = {
.read_probe = vid_probe,
.read_header= vid_read_header,
.read_packet= vid_read_packet,
-.read_close = vid_read_close,
};
--
2.20.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] avformat/bethsoftvid: Fix potential memleak upon reallocation failure
The classical ptr = av_realloc(ptr, size), just with av_fast_realloc().
Signed-off-by: Andreas Rheinhardt
---
libavformat/bethsoftvid.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavformat/bethsoftvid.c b/libavformat/bethsoftvid.c
index e52b17433c..c54c54325a 100644
--- a/libavformat/bethsoftvid.c
+++ b/libavformat/bethsoftvid.c
@@ -147,9 +147,13 @@ static int read_frame(BVID_DemuxContext *vid, AVIOContext
*pb, AVPacket *pkt,
}
do{
-vidbuf_start = av_fast_realloc(vidbuf_start, &vidbuf_capacity,
vidbuf_nbytes + BUFFER_PADDING_SIZE);
-if(!vidbuf_start)
-return AVERROR(ENOMEM);
+uint8_t *tmp = av_fast_realloc(vidbuf_start, &vidbuf_capacity,
+ vidbuf_nbytes + BUFFER_PADDING_SIZE);
+if (!tmp) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+vidbuf_start = tmp;
code = avio_r8(pb);
vidbuf_start[vidbuf_nbytes++] = code;
--
2.20.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 v2] avformat/bethsoftvid: Avoid allocations and frees for palettes
by putting the palette in the demuxer's context. This also allows to
remove this demuxer's read_close-function.
Signed-off-by: Andreas Rheinhardt
---
libavformat/bethsoftvid.c | 25 +++--
1 file changed, 7 insertions(+), 18 deletions(-)
diff --git a/libavformat/bethsoftvid.c b/libavformat/bethsoftvid.c
index 4aefb04f14..2d5171a01c 100644
--- a/libavformat/bethsoftvid.c
+++ b/libavformat/bethsoftvid.c
@@ -49,7 +49,8 @@ typedef struct BVID_DemuxContext
int bethsoft_global_delay;
int video_index;/**< video stream index */
int audio_index;/**< audio stream index */
-uint8_t *palette;
+int has_palette;
+uint8_t palette[BVID_PALETTE_SIZE];
int is_finished;
@@ -188,7 +189,7 @@ static int read_frame(BVID_DemuxContext *vid, AVIOContext
*pb, AVPacket *pkt,
pkt->flags |= AV_PKT_FLAG_KEY;
/* if there is a new palette available, add it to packet side data */
-if (vid->palette) {
+if (vid->has_palette) {
uint8_t *pdata = av_packet_new_side_data(pkt, AV_PKT_DATA_PALETTE,
BVID_PALETTE_SIZE);
if (!pdata) {
@@ -197,8 +198,7 @@ static int read_frame(BVID_DemuxContext *vid, AVIOContext
*pb, AVPacket *pkt,
goto fail;
}
memcpy(pdata, vid->palette, BVID_PALETTE_SIZE);
-
-av_freep(&vid->palette);
+vid->has_palette = 0;
}
vid->nframes--; // used to check if all the frames were read
@@ -222,17 +222,14 @@ static int vid_read_packet(AVFormatContext *s,
block_type = avio_r8(pb);
switch(block_type){
case PALETTE_BLOCK:
-if (vid->palette) {
+if (vid->has_palette) {
av_log(s, AV_LOG_WARNING, "discarding unused palette\n");
-av_freep(&vid->palette);
+vid->has_palette = 0;
}
-vid->palette = av_malloc(BVID_PALETTE_SIZE);
-if (!vid->palette)
-return AVERROR(ENOMEM);
if (avio_read(pb, vid->palette, BVID_PALETTE_SIZE) !=
BVID_PALETTE_SIZE) {
-av_freep(&vid->palette);
return AVERROR(EIO);
}
+vid->has_palette = 1;
return vid_read_packet(s, pkt);
case FIRST_AUDIO_BLOCK:
@@ -284,13 +281,6 @@ static int vid_read_packet(AVFormatContext *s,
}
}
-static int vid_read_close(AVFormatContext *s)
-{
-BVID_DemuxContext *vid = s->priv_data;
-av_freep(&vid->palette);
-return 0;
-}
-
AVInputFormat ff_bethsoftvid_demuxer = {
.name = "bethsoftvid",
.long_name = NULL_IF_CONFIG_SMALL("Bethesda Softworks VID"),
@@ -298,5 +288,4 @@ AVInputFormat ff_bethsoftvid_demuxer = {
.read_probe = vid_probe,
.read_header= vid_read_header,
.read_packet= vid_read_packet,
-.read_close = vid_read_close,
};
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add bink2 video decoder
On Fri, Mar 20, 2020 at 02:31:05PM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure |1 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c |1 +
> libavcodec/avcodec.h|1 +
> libavcodec/bink2.c | 869
> libavcodec/bink2f.c | 1125
> libavcodec/bink2g.c | 1197 +++
> libavcodec/codec_desc.c |7 +
> libavformat/bink.c |3 +-
> 9 files changed, 3203 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/bink2.c
> create mode 100644 libavcodec/bink2f.c
> create mode 100644 libavcodec/bink2g.c
> --- /dev/null
> +++ b/libavcodec/bink2.c
> @@ -0,0 +1,869 @@
> +/*
> + * Bink video 2 decoder
> + * Copyright (c) 2014 Konstantin Shishkov
> + * Copyright (c) 2019 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
this is awesome guys!
> +static const uint8_t luma_repos[] = {
> +0, 1, 4, 5, 2, 3, 6, 7, 8, 9, 12, 13, 10, 11, 14, 15,
> +};
identical to libavcodec/msvideo1enc.c: remap[16]
> +static const int32_t bink2g_dc_pat[] = {
> +1024, 1218, 1448, 1722, 2048,
> +2435, 2896, 3444, 4096, 4871,
> +5793, 6889, 8192, 9742, 11585, 13777, 16384,
> +19484, 23170, 27555, 32768, 38968, 46341,
> +55109, 65536, 77936, 92682, 110218, 131072,
> +155872, 185364, 220436, 262144, 311744,
> +370728, 440872, 524288,
> +};
libavcodec/diractab.c: ff_dirac_qscale_tab[]
> +static const uint8_t dq_patterns[8] = { 8, 0, 1, 0, 2, 0, 1, 0 };
libavcodec/vble.c: LUT[256]
> +static const uint8_t bink2f_next_skips[] = {
> +0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0,
> +};
> +
> +static const uint8_t bink2_next_skips[] = {
> +0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 7, 0, 0,
>
bink2f_next_skips and bink2_next_skips are identical. can you double check?
> +static const uint8_t ones_count[16] = {
> +0, 1, 1, 2, 1, 2, 2, 3, 1, 2, 2, 3, 2, 3, 3, 4
> +};
libavcodec/vc1_mc.c: popcount4[16]
-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
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".
[FFmpeg-devel] [PATCH] avformat/subtitles: Don't increment packet counter prematurely
Do it only if the packet has been successfully allocated in av_new_packet() -- otherwise on error a completely uninitialized packet would be unreferenced later. Signed-off-by: Andreas Rheinhardt --- libavformat/subtitles.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavformat/subtitles.c b/libavformat/subtitles.c index 172da5de2b..ad7f68938e 100644 --- a/libavformat/subtitles.c +++ b/libavformat/subtitles.c @@ -132,9 +132,10 @@ AVPacket *ff_subtitles_queue_insert(FFDemuxSubtitlesQueue *q, if (!subs) return NULL; q->subs = subs; -sub = &subs[q->nb_subs++]; +sub = &subs[q->nb_subs]; if (av_new_packet(sub, len) < 0) return NULL; +q->nb_subs++; sub->flags |= AV_PKT_FLAG_KEY; sub->pts = sub->dts = 0; memcpy(sub->data, event, len); -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec: add bink2 video decoder
On 3/20/2020 10:31 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure |1 +
> libavcodec/Makefile |1 +
> libavcodec/allcodecs.c |1 +
> libavcodec/avcodec.h|1 +
> libavcodec/bink2.c | 869
> libavcodec/bink2f.c | 1125
> libavcodec/bink2g.c | 1197 +++
> libavcodec/codec_desc.c |7 +
> libavformat/bink.c |3 +-
> 9 files changed, 3203 insertions(+), 2 deletions(-)
> create mode 100644 libavcodec/bink2.c
> create mode 100644 libavcodec/bink2f.c
> create mode 100644 libavcodec/bink2g.c
>
> diff --git a/configure b/configure
> index 18f2841765..1d89d49b41 100755
> --- a/configure
> +++ b/configure
> @@ -2678,6 +2678,7 @@ atrac3pal_decoder_select="mdct sinewin"
> atrac9_decoder_select="mdct"
> avrn_decoder_select="exif jpegtables"
> bink_decoder_select="blockdsp hpeldsp"
> +bink2_decoder_select="blockdsp"
> binkaudio_dct_decoder_select="mdct rdft dct sinewin wma_freqs"
> binkaudio_rdft_decoder_select="mdct rdft sinewin wma_freqs"
> cavs_decoder_select="blockdsp golomb h264chroma idctdsp qpeldsp videodsp"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index c1c9a44f2b..a79b4c6524 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -230,6 +230,7 @@ OBJS-$(CONFIG_AYUV_ENCODER)+= v408enc.o
> OBJS-$(CONFIG_BETHSOFTVID_DECODER) += bethsoftvideo.o
> OBJS-$(CONFIG_BFI_DECODER) += bfi.o
> OBJS-$(CONFIG_BINK_DECODER)+= bink.o binkdsp.o
> +OBJS-$(CONFIG_BINK2_DECODER) += bink2.o
> OBJS-$(CONFIG_BINKAUDIO_DCT_DECODER) += binkaudio.o
> OBJS-$(CONFIG_BINKAUDIO_RDFT_DECODER) += binkaudio.o
> OBJS-$(CONFIG_BINTEXT_DECODER) += bintext.o cga_data.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b3184af954..d032547a9d 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -60,6 +60,7 @@ extern AVCodec ff_ayuv_decoder;
> extern AVCodec ff_bethsoftvid_decoder;
> extern AVCodec ff_bfi_decoder;
> extern AVCodec ff_bink_decoder;
> +extern AVCodec ff_bink2_decoder;
> extern AVCodec ff_bitpacked_decoder;
> extern AVCodec ff_bmp_encoder;
> extern AVCodec ff_bmp_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 78c483c25c..e8b20fa527 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -463,6 +463,7 @@ enum AVCodecID {
> AV_CODEC_ID_MVDV,
> AV_CODEC_ID_MVHA,
> AV_CODEC_ID_CDTOONS,
> +AV_CODEC_ID_BINKVIDEO2,
>
> /* various PCM "codecs" */
> AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
> start of audio codecs
> diff --git a/libavcodec/bink2.c b/libavcodec/bink2.c
> new file mode 100644
> index 00..0ebce7feeb
> --- /dev/null
> +++ b/libavcodec/bink2.c
> @@ -0,0 +1,869 @@
> +/*
> + * Bink video 2 decoder
> + * Copyright (c) 2014 Konstantin Shishkov
> + * Copyright (c) 2019 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/attributes.h"
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "avcodec.h"
> +#include "blockdsp.h"
> +#include "copy_block.h"
> +#include "idctdsp.h"
Seems unused.
> +#include "internal.h"
> +#include "mathops.h"
> +
> +#define BITSTREAM_READER_LE
> +#include "get_bits.h"
> +#include "unary.h"
[...]
> +#include "bink2f.c"
> +#include "bink2g.c"
You should compile these separately, and share the functions that are
directly called in bink2.c
Also, move the bink2f and bink2g tables to their corresponding files.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v4] examples/extract_mvs.c: dont disply motionless vectors
Reviewed-by: Paul B Mahol
Signed-off-by: numberwolf
---
Here, don't need show motionless vectors,because they're useless.
And remove comments.
doc/examples/extract_mvs.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/doc/examples/extract_mvs.c b/doc/examples/extract_mvs.c
index de31ccd..af62e02 100644
--- a/doc/examples/extract_mvs.c
+++ b/doc/examples/extract_mvs.c
@@ -60,6 +60,9 @@ static int decode_packet(const AVPacket *pkt)
const AVMotionVector *mvs = (const AVMotionVector *)sd->data;
for (i = 0; i < sd->size / sizeof(*mvs); i++) {
const AVMotionVector *mv = &mvs[i];
+if (mv->src_x == mv->dst_x && mv->src_y == mv->dst_y) {
+continue;
+}
printf("%d,%2d,%2d,%2d,%4d,%4d,%4d,%4d,0x%"PRIx64"\n",
video_frame_count, mv->source,
mv->w, mv->h, mv->src_x, mv->src_y,
--
2.17.2 (Apple Git-113)
Thanks
Numberwolf
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/hnm: Check for extradata allocation failure
and also add padding to it; moreover, don't use memcpy to write one byte to extradata. Signed-off-by: Andreas Rheinhardt --- libavformat/hnm.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/libavformat/hnm.c b/libavformat/hnm.c index 40ef5c06ee..31221553a4 100644 --- a/libavformat/hnm.c +++ b/libavformat/hnm.c @@ -70,6 +70,7 @@ static int hnm_read_header(AVFormatContext *s) Hnm4DemuxContext *hnm = s->priv_data; AVIOContext *pb = s->pb; AVStream *vst; +int ret; /* default context members */ hnm->pts = 0; @@ -113,10 +114,10 @@ static int hnm_read_header(AVFormatContext *s) vst->codecpar->codec_tag = 0; vst->codecpar->width = hnm->width; vst->codecpar->height = hnm->height; -vst->codecpar->extradata = av_mallocz(1); +if ((ret = ff_alloc_extradata(vst->codecpar, 1)) < 0) +return ret; -vst->codecpar->extradata_size = 1; -memcpy(vst->codecpar->extradata, &hnm->version, 1); +vst->codecpar->extradata[0] = hnm->version; vst->start_time = 0; -- 2.20.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] avformat/hnm: Only keep and parse what is needed later
The hnm demuxer's context struct contained lots of fields that are
write-only variables or that are not used outside of parsing the header
and that can therefore be replaced by local variables of hnm_read_header().
This commit removes all of these from the context; the second type has
been replaced by local variables.
An AVPacket (that was initialized when reading the header and for which
dead code to unreference it existed in hnm_read_close()) is among the
removed things. Removing it allowed to remove hnm_read_close()
altogether and also removes another instance of usage of sizeof(AVPacket).
Signed-off-by: Andreas Rheinhardt
---
libavformat/hnm.c | 63 +--
1 file changed, 12 insertions(+), 51 deletions(-)
diff --git a/libavformat/hnm.c b/libavformat/hnm.c
index 31221553a4..f06add5cf8 100644
--- a/libavformat/hnm.c
+++ b/libavformat/hnm.c
@@ -37,19 +37,9 @@
#define HNM4_CHUNK_ID_SD 17491
typedef struct Hnm4DemuxContext {
-uint8_t version;
-uint16_t width;
-uint16_t height;
-uint32_t filesize;
uint32_t frames;
-uint32_t taboffset;
-uint16_t bits;
-uint16_t channels;
-uint32_t framesize;
uint32_t currentframe;
-int64_t pts;
uint32_t superchunk_remaining;
-AVPacket vpkt;
} Hnm4DemuxContext;
static int hnm_probe(const AVProbeData *p)
@@ -69,55 +59,37 @@ static int hnm_read_header(AVFormatContext *s)
{
Hnm4DemuxContext *hnm = s->priv_data;
AVIOContext *pb = s->pb;
+unsigned width, height;
AVStream *vst;
int ret;
-/* default context members */
-hnm->pts = 0;
-av_init_packet(&hnm->vpkt);
-hnm->vpkt.data = NULL;
-hnm->vpkt.size = 0;
-
-hnm->superchunk_remaining = 0;
-
avio_skip(pb, 8);
-hnm->width = avio_rl16(pb);
-hnm->height= avio_rl16(pb);
-hnm->filesize = avio_rl32(pb);
+width = avio_rl16(pb);
+height = avio_rl16(pb);
+avio_rl32(pb); // filesize
hnm->frames= avio_rl32(pb);
-hnm->taboffset = avio_rl32(pb);
-hnm->bits = avio_rl16(pb);
-hnm->channels = avio_rl16(pb);
-hnm->framesize = avio_rl32(pb);
-avio_skip(pb, 32);
+avio_skip(pb, 44);
-hnm->currentframe = 0;
-
-if (hnm->width < 256 || hnm->width > 640 ||
-hnm->height < 150 || hnm->height > 480) {
+if (width < 256 || width > 640 ||
+height < 150 || height > 480) {
av_log(s, AV_LOG_ERROR,
- "invalid resolution: %ux%u\n", hnm->width, hnm->height);
+ "invalid resolution: %ux%u\n", width, height);
return AVERROR_INVALIDDATA;
}
-// TODO: find a better way to detect HNM4A
-if (hnm->width == 640)
-hnm->version = 0x4a;
-else
-hnm->version = 0x40;
-
if (!(vst = avformat_new_stream(s, NULL)))
return AVERROR(ENOMEM);
vst->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
vst->codecpar->codec_id = AV_CODEC_ID_HNM4_VIDEO;
vst->codecpar->codec_tag = 0;
-vst->codecpar->width = hnm->width;
-vst->codecpar->height = hnm->height;
+vst->codecpar->width = width;
+vst->codecpar->height = height;
if ((ret = ff_alloc_extradata(vst->codecpar, 1)) < 0)
return ret;
-vst->codecpar->extradata[0] = hnm->version;
+// TODO: find a better way to detect HNM4A
+vst->codecpar->extradata[0] = width == 640 ? 0x4a : 0x40;
vst->start_time = 0;
@@ -186,16 +158,6 @@ static int hnm_read_packet(AVFormatContext *s, AVPacket
*pkt)
return ret;
}
-static int hnm_read_close(AVFormatContext *s)
-{
-Hnm4DemuxContext *hnm = s->priv_data;
-
-if (hnm->vpkt.size > 0)
-av_packet_unref(&hnm->vpkt);
-
-return 0;
-}
-
AVInputFormat ff_hnm_demuxer = {
.name = "hnm",
.long_name = NULL_IF_CONFIG_SMALL("Cryo HNM v4"),
@@ -203,6 +165,5 @@ AVInputFormat ff_hnm_demuxer = {
.read_probe = hnm_probe,
.read_header= hnm_read_header,
.read_packet= hnm_read_packet,
-.read_close = hnm_read_close,
.flags = AVFMT_NO_BYTE_SEEK | AVFMT_NOGENSEARCH |
AVFMT_NOBINSEARCH
};
--
2.20.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".
