[FFmpeg-devel] [PATCH v2] avcodec/h2645_parse: refine the code for better readiablity
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/h2645_parse.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 307e8643e6..f077900617 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -453,16 +453,15 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
}
}
-if (pkt->nals_allocated < pkt->nb_nals + 1) {
-int new_size = pkt->nals_allocated + 1;
-void *tmp = av_realloc_array(pkt->nals, new_size,
sizeof(*pkt->nals));
+if (pkt->nb_nals >= pkt->nals_allocated) {
+void *tmp = av_realloc_array(pkt->nals, pkt->nals_allocated + 1,
sizeof(*pkt->nals));
if (!tmp)
return AVERROR(ENOMEM);
pkt->nals = tmp;
-memset(pkt->nals + pkt->nals_allocated, 0,
- (new_size - pkt->nals_allocated) * sizeof(*pkt->nals));
+memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals));
+pkt->nals_allocated++;
nal = &pkt->nals[pkt->nb_nals];
nal->skipped_bytes_pos_size = 1024; // initial buffer size
@@ -470,7 +469,6 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
if (!nal->skipped_bytes_pos)
return AVERROR(ENOMEM);
-pkt->nals_allocated = new_size;
}
nal = &pkt->nals[pkt->nb_nals];
--
2.21.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".
Re: [FFmpeg-devel] [PATCH v1] avcodec/h2645_parse: fix for the realloc size
On Tue, Sep 10, 2019 at 12:03:14AM -0300, James Almer wrote:
> On 9/9/2019 11:51 PM, Limin Wang wrote:
> > On Mon, Sep 09, 2019 at 10:53:53PM -0300, James Almer wrote:
> >> On 9/9/2019 10:18 PM, lance.lmw...@gmail.com wrote:
> >>> From: Limin Wang
> >>>
> >>> Signed-off-by: Limin Wang
> >>> ---
> >>> libavcodec/h2645_parse.c | 2 +-
> >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> >>> index 307e8643e6..403acd2ee1 100644
> >>> --- a/libavcodec/h2645_parse.c
> >>> +++ b/libavcodec/h2645_parse.c
> >>> @@ -454,7 +454,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
> >>> uint8_t *buf, int length,
> >>> }
> >>>
> >>> if (pkt->nals_allocated < pkt->nb_nals + 1) {
> >>> -int new_size = pkt->nals_allocated + 1;
> >>> +int new_size = pkt->nb_nals + 1;
> >>
> >> No. nals_allocated and nb_nals are two purposely separate values in
> >> order to reuse the H2645Packet struct. One keeps track of the allocated
> >> size of the NAL buffer, whereas the other keeps track of the amount of
> >> NALs used by the current packet. That's why the check immediately above
> >> this line makes sure the amount of NALs in the current packet fit in the
> >> current size of the NAL buffer, and grows/reallocates it otherwise.
> >
> > Thanks for the detail information about the two field. Below is my
> > assumation
> > as I haven't such sample to test such case.
> > Assuming nals_allocated is 1, nb_nals is 3
>
> That can't happen. nb_nals is always set to zero at the start of
> ff_h2645_packet_split(), and is increased by one every time a NAL is
> finished parsing. It's guaranteed to always be less or equal than
> nals_allocated by the above check.
>
> , then the current code will reallocate
Thanks, it's clear now. I have small change to get better code
readiablity(which I think)
> > new_size with 2, But the following code will use the nb_nals to access
> > pkt->nals,
> > I'm not sure nals memory is allocated or not?
> > nal = &pkt->nals[pkt->nb_nals];
> >
> >
> >>
> >>> void *tmp = av_realloc_array(pkt->nals, new_size,
> >>> sizeof(*pkt->nals));
> >>>
> >>> if (!tmp)
> >>>
> >>
> >> ___
> >> 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".
___
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] avcodec/h2645_parse: fix for the realloc size
On 9/9/2019 11:51 PM, Limin Wang wrote:
> On Mon, Sep 09, 2019 at 10:53:53PM -0300, James Almer wrote:
>> On 9/9/2019 10:18 PM, lance.lmw...@gmail.com wrote:
>>> From: Limin Wang
>>>
>>> Signed-off-by: Limin Wang
>>> ---
>>> libavcodec/h2645_parse.c | 2 +-
>>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>>> index 307e8643e6..403acd2ee1 100644
>>> --- a/libavcodec/h2645_parse.c
>>> +++ b/libavcodec/h2645_parse.c
>>> @@ -454,7 +454,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
>>> uint8_t *buf, int length,
>>> }
>>>
>>> if (pkt->nals_allocated < pkt->nb_nals + 1) {
>>> -int new_size = pkt->nals_allocated + 1;
>>> +int new_size = pkt->nb_nals + 1;
>>
>> No. nals_allocated and nb_nals are two purposely separate values in
>> order to reuse the H2645Packet struct. One keeps track of the allocated
>> size of the NAL buffer, whereas the other keeps track of the amount of
>> NALs used by the current packet. That's why the check immediately above
>> this line makes sure the amount of NALs in the current packet fit in the
>> current size of the NAL buffer, and grows/reallocates it otherwise.
>
> Thanks for the detail information about the two field. Below is my assumation
> as I haven't such sample to test such case.
> Assuming nals_allocated is 1, nb_nals is 3
That can't happen. nb_nals is always set to zero at the start of
ff_h2645_packet_split(), and is increased by one every time a NAL is
finished parsing. It's guaranteed to always be less or equal than
nals_allocated by the above check.
, then the current code will reallocate
> new_size with 2, But the following code will use the nb_nals to access
> pkt->nals,
> I'm not sure nals memory is allocated or not?
> nal = &pkt->nals[pkt->nb_nals];
>
>
>>
>>> void *tmp = av_realloc_array(pkt->nals, new_size,
>>> sizeof(*pkt->nals));
>>>
>>> if (!tmp)
>>>
>>
>> ___
>> 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] avcodec/h2645_parse: fix for the realloc size
On Mon, Sep 09, 2019 at 10:53:53PM -0300, James Almer wrote:
> On 9/9/2019 10:18 PM, lance.lmw...@gmail.com wrote:
> > From: Limin Wang
> >
> > Signed-off-by: Limin Wang
> > ---
> > libavcodec/h2645_parse.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> > index 307e8643e6..403acd2ee1 100644
> > --- a/libavcodec/h2645_parse.c
> > +++ b/libavcodec/h2645_parse.c
> > @@ -454,7 +454,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const
> > uint8_t *buf, int length,
> > }
> >
> > if (pkt->nals_allocated < pkt->nb_nals + 1) {
> > -int new_size = pkt->nals_allocated + 1;
> > +int new_size = pkt->nb_nals + 1;
>
> No. nals_allocated and nb_nals are two purposely separate values in
> order to reuse the H2645Packet struct. One keeps track of the allocated
> size of the NAL buffer, whereas the other keeps track of the amount of
> NALs used by the current packet. That's why the check immediately above
> this line makes sure the amount of NALs in the current packet fit in the
> current size of the NAL buffer, and grows/reallocates it otherwise.
Thanks for the detail information about the two field. Below is my assumation
as I haven't such sample to test such case.
Assuming nals_allocated is 1, nb_nals is 3, then the current code will
reallocate
new_size with 2, But the following code will use the nb_nals to access
pkt->nals,
I'm not sure nals memory is allocated or not?
nal = &pkt->nals[pkt->nb_nals];
>
> > void *tmp = av_realloc_array(pkt->nals, new_size,
> > sizeof(*pkt->nals));
> >
> > if (!tmp)
> >
>
> ___
> 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] [PATCH] avformat/dashdec: add startNumber parser for segmentlist
and get start_number for compute current segment number.
fix ticket: 7976
Signed-off-by: Steven Liu
---
libavformat/dashdec.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index a6f75514f6..4f725ba09a 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -886,6 +886,7 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
ret = AVERROR(ENOMEM);
goto end;
}
+rep->parent = s;
representation_segmenttemplate_node =
find_child_node_by_name(representation_node, "SegmentTemplate");
representation_baseurl_node =
find_child_node_by_name(representation_node, "BaseURL");
representation_segmentlist_node =
find_child_node_by_name(representation_node, "SegmentList");
@@ -958,7 +959,7 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
xmlFree(timescale_val);
}
if (startnumber_val) {
-rep->first_seq_no = (int64_t) strtoll(startnumber_val, NULL,
10);
+rep->start_number = rep->first_seq_no = (int64_t)
strtoll(startnumber_val, NULL, 10);
av_log(s, AV_LOG_TRACE, "rep->first_seq_no = [%"PRId64"]\n",
rep->first_seq_no);
xmlFree(startnumber_val);
}
@@ -1016,6 +1017,7 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
duration_val = get_val_from_nodes_tab(segmentlists_tab, 3,
"duration");
timescale_val = get_val_from_nodes_tab(segmentlists_tab, 3,
"timescale");
+startnumber_val = get_val_from_nodes_tab(segmentlists_tab, 4,
"startNumber");
if (duration_val) {
rep->fragment_duration = (int64_t) strtoll(duration_val, NULL,
10);
av_log(s, AV_LOG_TRACE, "rep->fragment_duration =
[%"PRId64"]\n", rep->fragment_duration);
@@ -1026,6 +1028,12 @@ static int parse_manifest_representation(AVFormatContext
*s, const char *url,
av_log(s, AV_LOG_TRACE, "rep->fragment_timescale =
[%"PRId64"]\n", rep->fragment_timescale);
xmlFree(timescale_val);
}
+if (startnumber_val) {
+rep->start_number = rep->first_seq_no = (int64_t)
strtoll(startnumber_val, NULL, 10);
+av_log(s, AV_LOG_TRACE, "rep->first_seq_no = [%"PRId64"]\n",
rep->first_seq_no);
+xmlFree(startnumber_val);
+}
+
fragmenturl_node =
xmlFirstElementChild(representation_segmentlist_node);
while (fragmenturl_node) {
ret = parse_manifest_segmenturlnode(s, rep, fragmenturl_node,
--
2.17.2 (Apple Git-113)
___
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] avcodec/h2645_parse: fix for the realloc size
On 9/9/2019 10:18 PM, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavcodec/h2645_parse.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 307e8643e6..403acd2ee1 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -454,7 +454,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
> *buf, int length,
> }
>
> if (pkt->nals_allocated < pkt->nb_nals + 1) {
> -int new_size = pkt->nals_allocated + 1;
> +int new_size = pkt->nb_nals + 1;
No. nals_allocated and nb_nals are two purposely separate values in
order to reuse the H2645Packet struct. One keeps track of the allocated
size of the NAL buffer, whereas the other keeps track of the amount of
NALs used by the current packet. That's why the check immediately above
this line makes sure the amount of NALs in the current packet fit in the
current size of the NAL buffer, and grows/reallocates it otherwise.
> void *tmp = av_realloc_array(pkt->nals, new_size,
> sizeof(*pkt->nals));
>
> if (!tmp)
>
___
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] avcodec/h2645_parse: fix for the realloc size
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/h2645_parse.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 307e8643e6..403acd2ee1 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -454,7 +454,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t
*buf, int length,
}
if (pkt->nals_allocated < pkt->nb_nals + 1) {
-int new_size = pkt->nals_allocated + 1;
+int new_size = pkt->nb_nals + 1;
void *tmp = av_realloc_array(pkt->nals, new_size,
sizeof(*pkt->nals));
if (!tmp)
--
2.21.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".
Re: [FFmpeg-devel] [PATCH] avcodec/h2645_parse: simplify memset call
On Sat, Sep 07, 2019 at 03:55:51PM -0400, Andriy Gelman wrote: > From: Andriy Gelman > > Removed (new_size - pkt->nals_allocated) because this value is always 1 > during the call. > --- > libavcodec/h2645_parse.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c > index 307e8643e6..ef6a6b4b4f 100644 > --- a/libavcodec/h2645_parse.c > +++ b/libavcodec/h2645_parse.c > @@ -461,8 +461,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t > *buf, int length, > return AVERROR(ENOMEM); > > pkt->nals = tmp; > -memset(pkt->nals + pkt->nals_allocated, 0, > - (new_size - pkt->nals_allocated) * sizeof(*pkt->nals)); > +memset(pkt->nals + pkt->nals_allocated, 0, sizeof(*pkt->nals)); instead, I think the new_size isn't set properly please refer to my patch in the thread. > > nal = &pkt->nals[pkt->nb_nals]; > nal->skipped_bytes_pos_size = 1024; // initial buffer size > -- > 2.23.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 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] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
On 09/09/2019 16:40, Fu, Linjie wrote:
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
>> Of Fu, Linjie
>> Sent: Friday, August 30, 2019 16:05
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
>> hw_frames_ctx for vp9 without destroy va_context
>>
>>> -Original Message-
>>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>> Behalf
>>> Of Fu, Linjie
>>> Sent: Friday, August 9, 2019 19:47
>>> To: FFmpeg development discussions and patches >> de...@ffmpeg.org>
>>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
>>> hw_frames_ctx for vp9 without destroy va_context
>>>
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
>>> Behalf
Of Hendrik Leppkes
Sent: Friday, August 9, 2019 17:40
To: FFmpeg development discussions and patches >>> de...@ffmpeg.org>
Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
>> recreate
hw_frames_ctx for vp9 without destroy va_context
On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie wrote:
>
>> -Original Message-
>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
Behalf
>> Of Hendrik Leppkes
>> Sent: Tuesday, August 6, 2019 16:27
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
recreate
>> hw_frames_ctx for vp9 without destroy va_context
>>
>> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu wrote:
>>>
>>> VP9 allows resolution changes per frame. Currently in VAAPI,
>>> resolution
>>> changes leads to va context destroy and reinit. This will cause
>>> reference frame surface lost and produce garbage.
>>>
>>> Though refs surface id could be passed to media driver and found in
>>> RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus the
>>> new created VaContext could only got an empty RefList.
>>>
>>> As libva allows re-create surface separately without changing the
>>> context, this issue could be handled by only recreating
>>> hw_frames_ctx.
>>>
>>> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
>>> hw_frame_ctx when dynamic resolution changing happens.
>>>
>>> Could be verified by:
>>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
>>> ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
>> vaapi.yuv
>>>
>>> Signed-off-by: Linjie Fu
>>> ---
>>> libavcodec/decode.c| 10 +-
>>> libavcodec/internal.h | 1 +
>>> libavcodec/pthread_frame.c | 2 ++
>>> libavcodec/vaapi_decode.c | 40 ++---
>> --
>>> --
-
>> --
>>> libavcodec/vaapi_vp9.c | 4
>>> 5 files changed, 34 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 0863b82..7b15fa5 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -1254,7 +1254,6 @@ int
>> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
>>>
>>> frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
data;
>>>
>>> -
>>> if (frames_ctx->initial_pool_size) {
>>> // We guarantee 4 base work surfaces. The function above
guarantees
>> 1
>>> // (the absolute minimum), so add the missing count.
>>
>> Unrelated whitespace change
>
> There is a redundant whitespace here, so I removed it within this patch.
>
>>> @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext
*avctx,
>>> return AVERROR_PATCHWELCOME;
>>> }
>>>
>>> -if (hwaccel->priv_data_size) {
>>> +if (hwaccel->priv_data_size && !avctx->internal-
> hwaccel_priv_data) {
>>> avctx->internal->hwaccel_priv_data =
>>> av_mallocz(hwaccel->priv_data_size);
>>> if (!avctx->internal->hwaccel_priv_data)
>>> @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext
>> *avctx,
>> const enum AVPixelFormat *fmt)
>>> memcpy(choices, fmt, (n + 1) * sizeof(*choices));
>>>
>>> for (;;) {
>>> -// Remove the previous hwaccel, if there was one.
>>> -hwaccel_uninit(avctx);
>>> -
>>> +// Remove the previous hwaccel, if there was one,
>>> +// and no need for keeping.
>>> +if (!avctx->internal->hwaccel_priv_data_keeping)
>>> +hwaccel_uninit(avctx);
>>> user_choice = avctx->get_format(avctx, choices);
>>> if (user_choice == AV_PIX_FMT_NONE) {
>>> // Explicitly chose nothing, give up.
>>
>> There could be a dozen special cases how st
Re: [FFmpeg-devel] [PATCH] libavfilter/vf_drawtext: Avoid undefined behavior from GET_UTF8
I'm open to suggestions of alternatives.
I want sure if I could do a goto if there was no code at that location so I
chose to add a log statement figuring that would be helpful if you had
problems.
I chose debug because previously the character was completely ignored, so
didn't want to go from no notification to an error log.
I could also just put a continue call there, or do more research to figure
out if I can go to without having any content on the line.
Suggestions for what I should do differently with that context?
Aaron
On Mon, Sep 9, 2019, 9:13 AM Michael Niedermayer
wrote:
> On Sat, Jul 27, 2019 at 07:58:48AM -0700, Aaron Boushley wrote:
> > The vf_drawtext filter uses the GET_UTF8 macro in multiple locations.
> > Each of these use `continue;` as the error handler. However the
> > documentation for the GET_UTF8 macro states "ERROR should not contain
> > a loop control statement which could interact with the internal while
> > loop, and should force an exit from the macro code (e.g. through a
> > goto or a return) in order to prevent undefined results."
> >
> > This patch adjusts vf_drawtext to use goto error handlers similar to
> > other locations in ffmpeg.
> >
> > Aaron
> >
> > PS Sorry for having to send again, sent from the wrong address last
> > time, so patchwork didn't pick it up.
> >
>
> > vf_drawtext.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> > 04550ed40f98ec78c2719de31da889e92ff42f45
> libavfilter-drawtext-avoid-undefined-behavior.patch
> > From efdc96ace59d676e76434499a399d1d7df7fa093 Mon Sep 17 00:00:00 2001
> > From: Aaron Boushley
> > Date: Fri, 26 Jul 2019 15:49:36 -0700
> > Subject: [PATCH] libavfilter/drawtext: avoid undefined behavior with
> GET_UTF8
> >
> > Currently the GET_UTF8 usage in drawtext use a continue to skip invalid
> > characters in a string. The macro definition states that using a loop
> > control statement results in undefined behavior since the macro itself
> > uses a loop.
> >
> > This switches drawtext to use a goto statement similar to other usages
> > of GET_UTF8 in other parts of ffmpeg.
> >
> > Signed-off-by: Aaron Boushley
> > ---
> > libavfilter/vf_drawtext.c | 17 ++---
> > 1 file changed, 14 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> > index 8f4badbdb5..fd2ba84d12 100644
> > --- a/libavfilter/vf_drawtext.c
> > +++ b/libavfilter/vf_drawtext.c
> > @@ -1223,7 +1223,7 @@ static int draw_glyphs(DrawTextContext *s, AVFrame
> *frame,
> > for (i = 0, p = text; *p; i++) {
> > FT_Bitmap bitmap;
> > Glyph dummy = { 0 };
> > -GET_UTF8(code, *p++, continue;);
> > +GET_UTF8(code, *p++, goto invalid_drawing;);
> >
> > /* skip new line chars, just go to new line */
> > if (code == '\n' || code == '\r' || code == '\t')
> > @@ -1248,6 +1248,9 @@ static int draw_glyphs(DrawTextContext *s, AVFrame
> *frame,
> >bitmap.width, bitmap.rows,
> >bitmap.pixel_mode == FT_PIXEL_MODE_MONO ? 0 : 3,
> >0, x1, y1);
> > +continue;
> > +invalid_drawing:
> > +av_log(s, AV_LOG_DEBUG, "Invalid UTF8 character while drawing
> glyphs\n");
> > }
>
> Why does this add av_log() calls ?
> This seems unrelated to the bug fix. Also why are they debug level ?
> if a user draws a string she provided that could be argued to be an error
> the user wants to know about. But maybe iam missing something
> Also they probably should provide more information about where the
> invalid character is. It may be hard to find in a long text for some users
>
> Thanks
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The educated differ from the uneducated as much as the living from the
> dead. -- Aristotle
> ___
> 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] [PATCH 3/3] avcodec/vc1: Check for excessive resolution
Fixes: overflow in aspect ratio calculation
Fixes: signed integer overflow: 393215 * 14594 cannot be represented in type
'int'
Fixes:
15728/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_WMV3IMAGE_fuzzer-5661588893204480
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vc1.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/libavcodec/vc1.c b/libavcodec/vc1.c
index e102b931d8..a7875ddf97 100644
--- a/libavcodec/vc1.c
+++ b/libavcodec/vc1.c
@@ -451,7 +451,11 @@ static int decode_sequence_header_adv(VC1Context *v,
GetBitContext *gb)
h = get_bits(gb, 8) + 1;
v->s.avctx->sample_aspect_ratio = (AVRational){w, h};
} else {
-av_reduce(&v->s.avctx->sample_aspect_ratio.num,
+if (v->s.avctx->width > v->max_coded_width ||
+v->s.avctx->height > v->max_coded_height) {
+avpriv_request_sample(v->s.avctx, "Huge resolution");
+} else
+av_reduce(&v->s.avctx->sample_aspect_ratio.num,
&v->s.avctx->sample_aspect_ratio.den,
v->s.avctx->height * w,
v->s.avctx->width * h,
--
2.23.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 1/3] avcodec/hevc_cabac: Tighten the limit on k in ff_hevc_cu_qp_delta_abs()
Values larger would fail subsequent tests.
Fixes: signed integer overflow: 5 + 2147483646 cannot be represented in type
'int'
Fixes:
16966/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5695709549953024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/hevc_cabac.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/hevc_cabac.c b/libavcodec/hevc_cabac.c
index faa36d5459..8abb780dd7 100644
--- a/libavcodec/hevc_cabac.c
+++ b/libavcodec/hevc_cabac.c
@@ -642,11 +642,11 @@ int ff_hevc_cu_qp_delta_abs(HEVCContext *s)
}
if (prefix_val >= 5) {
int k = 0;
-while (k < CABAC_MAX_BIN && get_cabac_bypass(&s->HEVClc->cc)) {
+while (k < 7 && get_cabac_bypass(&s->HEVClc->cc)) {
suffix_val += 1 << k;
k++;
}
-if (k == CABAC_MAX_BIN) {
+if (k == 7) {
av_log(s->avctx, AV_LOG_ERROR, "CABAC_MAX_BIN : %d\n", k);
return AVERROR_INVALIDDATA;
}
--
2.23.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 2/3] avcodec/pnm_parser: Use memchr() in pnm_parse()
Fixes: Timeout (45sec -> 0.5sec)
Fixes:
16942/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PPM_fuzzer-5085393073995776
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pnm_parser.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/pnm_parser.c b/libavcodec/pnm_parser.c
index 94777d2cca..d19dbfe98c 100644
--- a/libavcodec/pnm_parser.c
+++ b/libavcodec/pnm_parser.c
@@ -95,8 +95,11 @@ retry:
sync = bs;
c = *bs++;
if (c == '#') {
-while (c != '\n' && bs < end)
-c = *bs++;
+uint8_t *match = memchr(bs, '\n', end-bs);
+if (match)
+bs = match + 1;
+else
+break;
} else if (c == 'P') {
next = bs - pnmctx.bytestream_start + skip - 1;
pnmpc->ascii_scan = 0;
--
2.23.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".
Re: [FFmpeg-devel] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
On Mon, Sep 9, 2019 at 3:19 PM Hendrik Leppkes wrote: > On Tue, Sep 10, 2019 at 12:00 AM Aman Gupta wrote: > > > > On Mon, Sep 9, 2019 at 2:47 PM Carl Eugen Hoyos > wrote: > > > > > Am Mo., 9. Sept. 2019 um 22:19 Uhr schrieb Aman Gupta >: > > > > > > > > From: Aman Gupta > > > > > > > > These are simple algorithms which can be run efficiently > > > > on low powered devices to produce deinteraced images. > > > > > > Please provide some numbers about the performance > > > (and subjective visual quality) of the new C code in > > > comparison to existing deinterlacers in FFmpeg. > > > > > > > Comparison of visual quality can be seen on VLC's website: > > https://wiki.videolan.org/Deinterlacing > > > > Regarding performance- none of the filters currently available in ffmpeg > > are fast enough to deinterlace video in real time on ARM chips used by > > popular Android or iOS devices. They're all very computationally > expensive, > > and do not have any ARM SIMD implementations. The deinterlacers from VLC > > use simple mathematical averages optimized by SIMD, and have been used by > > VLC on such devices for many years. I don't have any hard numbers to > share, > > but in my experience I can decode+deinterlace video for real time > playback > > in VLC on any cheap Android phone, whereas other ffmpeg-based players > > cannot. > > > > None of those algorithms are really worth using, none are actual > "deinterlacers". Blend and Mean are just plain out terrible, and the > other options are just dumb bob'ers which you can do with avfilter > as-is today with a combination of the separatefields filter (which is > zero-copy based on frame metadata only) and optional scaling > afterwards. > I don't disagree that many of them are overly simplistic. I only copied them all for completeness sake. However, as terrible as they may be they're not as bad as displaying interlaced frames directly. Blend and Linear produce acceptable image quality imho. Linear averages lines from both fields to generate a new image. Is something like this possible with any existing filter combined with separatefields? Aman > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 7/8] avformat/utils: Remove unnecessary packet copies
Up until now, read_frame_internal in avformat/utils.c uses a spare
packet on the stack that serves no real purpose: At no point in this
function is there a need for another packet besides the packet destined
for output:
1. If the packet doesn't need a parser, but is output as is, the content
of the spare packet (that at this point contains a freshly read packet)
is simply copied into the output packet (via simple assignment, not
av_packet_move_ref, thereby confusing ownership).
2. If the packet needs parsing, the spare packet will be reset after
parsing and any packets resulting from the packet read will be put into
a packet list; the output packet is not used here at all.
3. If the stream should be discarded, the spare packet will be
unreferenced; the output packet is not used here at all.
Therefore the spare packet and the copies can be removed in principle.
In practice, one more thing needs to be taken care of: If ff_read_packet
failed, this did not affect the output packet, now it does. This
potential problem is solved by making sure that ff_read_packet always
resets the output packet in case of errors.
Signed-off-by: Andreas Rheinhardt
---
Resending to fix a typo mentioned by Andriy. It's also intended to ping
the whole patchset.
libavformat/utils.c | 51 ++---
1 file changed, 25 insertions(+), 26 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 66b33df165..5f558d8791 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -830,6 +830,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
int ret, i, err;
AVStream *st;
+pkt->data = NULL;
+pkt->size = 0;
+av_init_packet(pkt);
+
for (;;) {
AVPacketList *pktl = s->internal->raw_packet_buffer;
const AVPacket *pkt1;
@@ -847,11 +851,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
}
}
-pkt->data = NULL;
-pkt->size = 0;
-av_init_packet(pkt);
ret = s->iformat->read_packet(s, pkt);
if (ret < 0) {
+pkt->data = NULL;
+pkt->size = 0;
+av_init_packet(pkt);
/* Some demuxers return FFERROR_REDO when they consume
data and discard it (ignored streams, junk, extradata).
We must re-call the demuxer to get the real packet. */
@@ -1579,10 +1583,9 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
while (!got_packet && !s->internal->parse_queue) {
AVStream *st;
-AVPacket cur_pkt;
/* read next packet */
-ret = ff_read_packet(s, &cur_pkt);
+ret = ff_read_packet(s, pkt);
if (ret < 0) {
if (ret == AVERROR(EAGAIN))
return ret;
@@ -1597,7 +1600,7 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
break;
}
ret = 0;
-st = s->streams[cur_pkt.stream_index];
+st = s->streams[pkt->stream_index];
/* update context if required */
if (st->internal->need_context_update) {
@@ -1615,7 +1618,7 @@ static int read_frame_internal(AVFormatContext *s,
AVPacket *pkt)
ret = avcodec_parameters_to_context(st->internal->avctx,
st->codecpar);
if (ret < 0) {
-av_packet_unref(&cur_pkt);
+av_packet_unref(pkt);
return ret;
}
@@ -1624,7 +1627,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
/* update deprecated public codec context */
ret = avcodec_parameters_to_context(st->codec, st->codecpar);
if (ret < 0) {
-av_packet_unref(&cur_pkt);
+av_packet_unref(pkt);
return ret;
}
FF_ENABLE_DEPRECATION_WARNINGS
@@ -1633,23 +1636,23 @@ FF_ENABLE_DEPRECATION_WARNINGS
st->internal->need_context_update = 0;
}
-if (cur_pkt.pts != AV_NOPTS_VALUE &&
-cur_pkt.dts != AV_NOPTS_VALUE &&
-cur_pkt.pts < cur_pkt.dts) {
+if (pkt->pts != AV_NOPTS_VALUE &&
+pkt->dts != AV_NOPTS_VALUE &&
+pkt->pts < pkt->dts) {
av_log(s, AV_LOG_WARNING,
"Invalid timestamps stream=%d, pts=%s, dts=%s, size=%d\n",
- cur_pkt.stream_index,
- av_ts2str(cur_pkt.pts),
- av_ts2str(cur_pkt.dts),
- cur_pkt.size);
+ pkt->stream_index,
+ av_ts2str(pkt->pts),
+ av_ts2str(pkt->dts),
+ pkt->size);
}
if (s->debug & FF_FDEBUG_TS)
av_log(s, AV_LOG_DEBUG,
"ff_read_packet stream=%d, pts=%s, dts=%s, size=%d,
duration=%"PRId64", flags=%d\n",
- cur_pkt.stream_index,
- av_ts2str(cur_pkt.pts),
- av_ts2str(cur_pkt.dts),
- cur_pkt.size, cu
Re: [FFmpeg-devel] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
Am Di., 10. Sept. 2019 um 00:00 Uhr schrieb Aman Gupta : > > On Mon, Sep 9, 2019 at 2:47 PM Carl Eugen Hoyos wrote: > > > Am Mo., 9. Sept. 2019 um 22:19 Uhr schrieb Aman Gupta : > > > > > > From: Aman Gupta > > > > > > These are simple algorithms which can be run efficiently > > > on low powered devices to produce deinteraced images. > > > > Please provide some numbers about the performance > > (and subjective visual quality) of the new C code in > > comparison to existing deinterlacers in FFmpeg. > > > > Comparison of visual quality can be seen on VLC's website: > https://wiki.videolan.org/Deinterlacing > > Regarding performance- none of the filters currently available in ffmpeg > are fast enough to deinterlace video in real time on ARM chips used by > popular Android or iOS devices. That was not my question and I believe the commit message absolutely needs some hints about the performance and the quality. 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 v2 7/8] avformat/utils: Remove unnecessary packet copies
Andriy Gelman:
> On Mon, 19. Aug 23:56, Andreas Rheinhardt wrote:
>> Up until now, read_frame_internal in avformat/utils.c uses a spare
>> packet on the stack that serves no real purpose: At no point in this
>> function is there a need for another packet besides the packet destined
>> for output:
>> 1. If the packet doesn't need a parser, but is output as is, the content
>> of the spare packet (that at this point contains a freshly read packet)
>> is simply copied into the output packet (via simple assignment, not
>> av_packet_move_ref, thereby confusing ownership).
>> 2. If the packet needs parsing, the spare packet will be reset after
>> parsing and any packets resulting from the packet read will be put into
>> a packet list; the output packet is not used here at all.
>> 3. If the stream should be discarded, the spare packet will be
>> unreferenced; the output packet is not used here at all.
>>
>> Therefore the spare packet and the copies can be removed in priniple.
>
> typo: principle
Thanks. New patch coming in a minute.
>
>> In practice, one more thing needs to be taken care of: If ff_read_packet
>> failed, this did not affect the output packet, now it does. This
>> potential problem is solved by making sure that ff_read_packet always
>> resets the output packet in case of errors.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>
>> Side note: This skip_to_keyframe stuff which is touched in this commit
>> has been introduced in 4a95876f to be able to drop non-keyframes after
>> the parser in case the keyframes are wrongly marked in the file. But the
>> parser returns packets by putting them in the packet queue and not by
>> returning them via its pkt parameter, so that st->skip_to_keyframe will
>> never be unset and no packet will be dropped because of it for a stream
>> that gets parsed. It actually only works ("works" means that an error
>> message will be displayed for a broken file where the keyframes are not
>> correctly marked) for the file for which it was intended (the one from
>> issue 1003) by accident. Maybe it should be removed altogether?
>
> I agree, when the parser is called, the skip_to_keyframe code is currently
> skipped.
> Would it make sense for the skip_to_keyframe code to also be added after pkt
> is retrieved from ff_packet_list_get ?
>
No. The correct place would be in parse_packet before the packet is
added to the list of parsed packets (otherwise, if all packets on said
list are skipped, one would have to goto to the loop again so that
further packets are read and checked.
>>
>> libavformat/utils.c | 51 ++---
>> 1 file changed, 25 insertions(+), 26 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index db0f53869f..d6d615b690 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -830,6 +830,10 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>> int ret, i, err;
>> AVStream *st;
>>
>> +pkt->data = NULL;
>> +pkt->size = 0;
>> +av_init_packet(pkt);
>> +
>> for (;;) {
>> AVPacketList *pktl = s->internal->raw_packet_buffer;
>> const AVPacket *pkt1;
>> @@ -847,11 +851,11 @@ int ff_read_packet(AVFormatContext *s, AVPacket *pkt)
>> }
>> }
>>
>> -pkt->data = NULL;
>> -pkt->size = 0;
>> -av_init_packet(pkt);
>> ret = s->iformat->read_packet(s, pkt);
>> if (ret < 0) {
>> +pkt->data = NULL;
>> +pkt->size = 0;
>> +av_init_packet(pkt);
>> /* Some demuxers return FFERROR_REDO when they consume
>> data and discard it (ignored streams, junk, extradata).
>> We must re-call the demuxer to get the real packet. */
>> @@ -1579,10 +1583,9 @@ static int read_frame_internal(AVFormatContext *s,
>> AVPacket *pkt)
>>
>> while (!got_packet && !s->internal->parse_queue) {
>> AVStream *st;
>> -AVPacket cur_pkt;
>>
>> /* read next packet */
>> -ret = ff_read_packet(s, &cur_pkt);
>> +ret = ff_read_packet(s, pkt);
>> if (ret < 0) {
>> if (ret == AVERROR(EAGAIN))
>> return ret;
>> @@ -1597,7 +1600,7 @@ static int read_frame_internal(AVFormatContext *s,
>> AVPacket *pkt)
>> break;
>> }
>> ret = 0;
>> -st = s->streams[cur_pkt.stream_index];
>> +st = s->streams[pkt->stream_index];
>>
>> /* update context if required */
>> if (st->internal->need_context_update) {
>> @@ -1615,7 +1618,7 @@ static int read_frame_internal(AVFormatContext *s,
>> AVPacket *pkt)
>>
>> ret = avcodec_parameters_to_context(st->internal->avctx,
>> st->codecpar);
>> if (ret < 0) {
>> -av_packet_unref(&cur_pkt);
>> +av_packet_unref(pkt);
>> return ret;
>> }
>>
>> @@ -1624,7 +1627,7 @@ FF_DISABLE_DEPRE
Re: [FFmpeg-devel] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
On Tue, Sep 10, 2019 at 12:00 AM Aman Gupta wrote: > > On Mon, Sep 9, 2019 at 2:47 PM Carl Eugen Hoyos wrote: > > > Am Mo., 9. Sept. 2019 um 22:19 Uhr schrieb Aman Gupta : > > > > > > From: Aman Gupta > > > > > > These are simple algorithms which can be run efficiently > > > on low powered devices to produce deinteraced images. > > > > Please provide some numbers about the performance > > (and subjective visual quality) of the new C code in > > comparison to existing deinterlacers in FFmpeg. > > > > Comparison of visual quality can be seen on VLC's website: > https://wiki.videolan.org/Deinterlacing > > Regarding performance- none of the filters currently available in ffmpeg > are fast enough to deinterlace video in real time on ARM chips used by > popular Android or iOS devices. They're all very computationally expensive, > and do not have any ARM SIMD implementations. The deinterlacers from VLC > use simple mathematical averages optimized by SIMD, and have been used by > VLC on such devices for many years. I don't have any hard numbers to share, > but in my experience I can decode+deinterlace video for real time playback > in VLC on any cheap Android phone, whereas other ffmpeg-based players > cannot. > None of those algorithms are really worth using, none are actual "deinterlacers". Blend and Mean are just plain out terrible, and the other options are just dumb bob'ers which you can do with avfilter as-is today with a combination of the separatefields filter (which is zero-copy based on frame metadata only) and optional scaling afterwards. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 5/8] avformat/utils: Fix memleaks II
Andriy Gelman:
> Andreas,
>
> On Mon, 19. Aug 23:56, Andreas Rheinhardt wrote:
>> Up until now, avformat_find_stream_info had a potential for memleaks:
>> When everything is fine, it read packets and (depending upon whether
>> AVFMT_FLAG_NOBUFFER was set) put them in a packet list or unreferenced
>> them when they were no longer needed. But upon failure, said packets
>> would leak if they were not already on the packet list. This patch fixes
>> this.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/utils.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index bae2f9e0db..96c02bb7fc 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3801,7 +3801,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> &ic->internal->packet_buffer_end,
>> &pkt1, 0);
>> if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>>
>> pkt = &ic->internal->packet_buffer_end->pkt;
>> } else {
>> @@ -3816,7 +3816,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> if (!st->internal->avctx_inited) {
>> ret = avcodec_parameters_to_context(avctx, st->codecpar);
>> if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>> st->internal->avctx_inited = 1;
>> }
>>
>> @@ -3904,7 +3904,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>> if (!st->internal->avctx->extradata) {
>> ret = extract_extradata(st, pkt);
>> if (ret < 0)
>> -goto find_stream_info_err;
>> +goto unref_then_goto_end;
>> }
>>
>> /* If still no information, we try to open the codec and to
>> @@ -4180,6 +4180,10 @@ find_stream_info_err:
>> av_log(ic, AV_LOG_DEBUG, "After avformat_find_stream_info() pos:
>> %"PRId64" bytes read:%"PRId64" seeks:%d frames:%d\n",
>> avio_tell(ic->pb), ic->pb->bytes_read, ic->pb->seek_count,
>> count);
>> return ret;
>> +
>> +unref_then_goto_end:
>> +av_packet_unref(&pkt1);
>> +goto find_stream_info_err;
>
> I wonder if you can get rid of this extra label by adding
> the following in find_stream_info_err
>
> if (pkt1.data)
> av_packet_unref(&pkt1)
>
No. There is a goto find_stream_info_err in line 3661 and at this
point pkt1 is still uninitialized. (Besides, a packet needs to be
unreferenced if it has side data or if it is refcounted, so the check
would be wrong. Did I already mention that av_init_packet doesn't even
set the data and size fields?)
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
On Mon, Sep 9, 2019 at 2:47 PM Carl Eugen Hoyos wrote: > Am Mo., 9. Sept. 2019 um 22:19 Uhr schrieb Aman Gupta : > > > > From: Aman Gupta > > > > These are simple algorithms which can be run efficiently > > on low powered devices to produce deinteraced images. > > Please provide some numbers about the performance > (and subjective visual quality) of the new C code in > comparison to existing deinterlacers in FFmpeg. > Comparison of visual quality can be seen on VLC's website: https://wiki.videolan.org/Deinterlacing Regarding performance- none of the filters currently available in ffmpeg are fast enough to deinterlace video in real time on ARM chips used by popular Android or iOS devices. They're all very computationally expensive, and do not have any ARM SIMD implementations. The deinterlacers from VLC use simple mathematical averages optimized by SIMD, and have been used by VLC on such devices for many years. I don't have any hard numbers to share, but in my experience I can decode+deinterlace video for real time playback in VLC on any cheap Android phone, whereas other ffmpeg-based players cannot. Aman > 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] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
Am Mo., 9. Sept. 2019 um 22:19 Uhr schrieb Aman Gupta : > > From: Aman Gupta > > These are simple algorithms which can be run efficiently > on low powered devices to produce deinteraced images. Please provide some numbers about the performance (and subjective visual quality) of the new C code in comparison to existing deinterlacers in FFmpeg. 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 2/2] avcodec/g2meet: Check for end of input in jpg_decode_block()
mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer: > Fixes: Timeout (100sec -> 0.7sec) > Fixes: > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/g2meet.c | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c > index 19e1c130ce..731d29a5d4 100644 > --- a/libavcodec/g2meet.c > +++ b/libavcodec/g2meet.c > @@ -244,6 +244,9 @@ static int jpg_decode_block(JPGContext *c, GetBitContext > *gb, > const int is_chroma = !!plane; > const uint8_t *qmat = is_chroma ? chroma_quant : luma_quant; > > +if (get_bits_left(gb) < 1) > +return AVERROR_INVALIDDATA; > + > c->bdsp.clear_block(block); > dc = get_vlc2(gb, c->dc_vlc[is_chroma].table, 9, 3); Why doesn't the VLC stuff have EOF handling? There's bound to be a metric bajillion of cases like this strewn across the codebase.. /Tomas ___ 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/g2meet: Check if adjusted pixel was on the stack
mån 2019-09-09 klockan 22:16 +0200 skrev Michael Niedermayer: > This basically checks if a pixel that was coded with prediction > and residual could have been stored using a previous case. > This avoids basically a string of 0 symbols stored in less than > 50 bytes to hit a O(n²) codepath. > > Fixes: Timeout (too slow to wait -> immedeatly) > Fixes: > 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4895946310680576 go2unpleasantplaces indeed Something tells me there are more ways than this to hit that codepath, and I've made my feelings about hacks like this known already. /Tomas ___ 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 3/6] tools/target_dec_fuzzer: Adjust threshold for LSCR
On Sun, Aug 25, 2019 at 08:41:55PM +0200, Michael Niedermayer wrote: > Fixes: Timeout (12sec -> 3sec) > Fixes: > 15327/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LSCR_fuzzer-5702887719567360 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > tools/target_dec_fuzzer.c | 1 + > 1 file changed, 1 insertion(+) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable 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/4] avcodec/hevcdec: Fix memleak of a53_caption
On Mon, Jul 01, 2019 at 07:11:50PM -0300, James Almer wrote: > On 7/1/2019 11:24 AM, Michael Niedermayer wrote: > > On Sun, Jun 30, 2019 at 11:18:55PM -0300, James Almer wrote: > >> On 6/30/2019 10:43 PM, James Almer wrote: > >>> On 6/30/2019 7:16 PM, Michael Niedermayer wrote: > Fixes: > 15295/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HEVC_fuzzer-5675655187922944 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hevcdec.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c > index 515b346535..b5d918d07d 100644 > --- a/libavcodec/hevcdec.c > +++ b/libavcodec/hevcdec.c > @@ -3331,6 +3331,8 @@ static av_cold int hevc_decode_free(AVCodecContext > *avctx) > > ff_h2645_packet_uninit(&s->pkt); > > +ff_hevc_reset_sei(&s->sei); > + > return 0; > } > >>> > >>> LGTM. > >> > >> You could also add it to hevc_decode_flush() while at it. > > > > will post a patch once i (lightly) tested it > > Do you have hevc samples with closed captions? I'm not sure if there's a no, i did not find one on my disk > case where one such caption would not be attached to the frame (And thus > removed from the decoder context) before a call to > avcodec_flush_buffers() takes place. Maybe some sample where slices are > in different packets. > > For that matter, h264 seems to handle closed captions a lot better than > hevc. It uses AVBufferRefs to keep them in sync between frame thread > contexts, and it also makes sure to reset frame-specific SEI state on > all frames and on flushing, all things hevc currently doesn't. > Implementing the former should be trivial, but the latter isn't as slice > handling is different. for a bugfix that we should backport as it may have some leak->OOM potential redesigning the handling is problematic. As backporting that would likely not happen ... So i suggest to go with a simpler solution like the original patch or one with the call also in hevc_decode_flush() Are you ok with this ? if so do you prefer the call also be done in flush ? also this issue is approaching the deadline ... Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you fake or manipulate statistics in a paper in physics you will never get a job again. If you fake or manipulate statistics in a paper in medicin you will get a job for life at the pharma industry. 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] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
On 9/9/19, Aman Gupta wrote:
> From: Aman Gupta
>
> These are simple algorithms which can be run efficiently
> on low powered devices to produce deinteraced images.
>
> Signed-off-by: Aman Gupta
> ---
> doc/filters.texi | 27 ++
> libavfilter/Makefile | 1 +
> libavfilter/aarch64/Makefile | 1 +
> libavfilter/aarch64/merge_neon.S | 98 ++
> libavfilter/allfilters.c | 1 +
> libavfilter/arm/Makefile | 3 +
> libavfilter/arm/merge_armv6.S| 70
> libavfilter/arm/merge_neon.S | 109 ++
> libavfilter/vf_fastdeint.c | 588 +++
> 9 files changed, 898 insertions(+)
> create mode 100644 libavfilter/aarch64/merge_neon.S
> create mode 100644 libavfilter/arm/Makefile
> create mode 100644 libavfilter/arm/merge_armv6.S
> create mode 100644 libavfilter/arm/merge_neon.S
> create mode 100644 libavfilter/vf_fastdeint.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 6c81e1da40..55d9adeb81 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9796,6 +9796,33 @@ fade=t=in:st=5.5:d=0.5
>
> @end itemize
>
> +@section fastdeint
> +Fast deinterlacing algorithms.
> +
> +@table @option
> +@item mode
> +Deinterlacing algorithm to use.
> +
> +It accepts the following values:
> +@table @samp
> +@item discard
> +Discard bottom frame.
> +
> +@item mean
> +Half resolution blender.
> +
> +@item blend
> +Full resolution blender.
> +
> +@item bob
> +Bob doubler.
> +
> +@item linear
> +Bob doubler with linear interpolation.
> +@end table
> +
> +@end table
> +
> @section fftdnoiz
> Denoise frames using 3D FFT (frequency domain filtering).
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3ef4191d9a..a2b3566ec0 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -234,6 +234,7 @@ OBJS-$(CONFIG_EROSION_OPENCL_FILTER) +=
> vf_neighbor_opencl.o opencl.o \
> opencl/neighbor.o
> OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
> OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
> +OBJS-$(CONFIG_FASTDEINT_FILTER) += vf_fastdeint.o
> OBJS-$(CONFIG_FFTDNOIZ_FILTER) += vf_fftdnoiz.o
> OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
> OBJS-$(CONFIG_FIELD_FILTER) += vf_field.o
> diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
> index b58daa3a3f..2b0ad92893 100644
> --- a/libavfilter/aarch64/Makefile
> +++ b/libavfilter/aarch64/Makefile
> @@ -1,3 +1,4 @@
> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
>
> +NEON-OBJS-$(CONFIG_FASTDEINT_FILTER) += aarch64/merge_neon.o
> NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/vf_nlmeans_neon.o
> diff --git a/libavfilter/aarch64/merge_neon.S
> b/libavfilter/aarch64/merge_neon.S
> new file mode 100644
> index 00..62377331a4
> --- /dev/null
> +++ b/libavfilter/aarch64/merge_neon.S
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2009-2016 Rémi Denis-Courmont, Janne Grunau, VLC authors
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/aarch64/asm.S"
> +
> +#define dest x0
> +#define src1 x1
> +#define src2 x2
> +#define size x3
> +
> +.align 2
> +// NOTE: Offset and pitch must be multiple of 16-bytes.
> +function ff_merge8_neon, export=1
> +andsx5, size, #~63
> +b.eq2f
> +mov x10, #64
> +add x11, src1, #32
> +add x12, src2, #32
> +1:
> +ld1 {v0.16b,v1.16b}, [src1], x10
> +ld1 {v4.16b,v5.16b}, [src2], x10
> +ld1 {v2.16b,v3.16b}, [x11], x10
> +uhadd v0.16b, v0.16b, v4.16b
> +ld1 {v6.16b,v7.16b}, [x12], x10
> +subsx5, x5, #64
> +uhadd v1.16b, v1.16b, v5.16b
> +uhadd v2.16b, v2.16b, v6.16b
> +uhadd v3.16b, v3.16b, v7.16b
> +st1 {v0.16b,v1.16b}, [dest], #32
> +st1 {v2.16b,v3.16b}, [dest], #32
> +b.gt1b
> +2:
>
Re: [FFmpeg-devel] [RFC PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
On 9/9/2019 5:12 PM, Aman Gupta wrote:
> From: Aman Gupta
>
> These are simple algorithms which can be run efficiently
> on low powered devices to produce deinteraced images.
>
> Signed-off-by: Aman Gupta
> ---
> doc/filters.texi | 27 ++
> libavfilter/Makefile | 1 +
> libavfilter/aarch64/Makefile | 1 +
> libavfilter/aarch64/merge_neon.S | 98 ++
> libavfilter/allfilters.c | 1 +
> libavfilter/arm/Makefile | 3 +
> libavfilter/arm/merge_armv6.S| 70
> libavfilter/arm/merge_neon.S | 109 ++
> libavfilter/vf_fastdeint.c | 588 +++
> 9 files changed, 898 insertions(+)
> create mode 100644 libavfilter/aarch64/merge_neon.S
> create mode 100644 libavfilter/arm/Makefile
> create mode 100644 libavfilter/arm/merge_armv6.S
> create mode 100644 libavfilter/arm/merge_neon.S
> create mode 100644 libavfilter/vf_fastdeint.c
Asm stuff should be in a separate entry.
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 6c81e1da40..55d9adeb81 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -9796,6 +9796,33 @@ fade=t=in:st=5.5:d=0.5
>
> @end itemize
>
> +@section fastdeint
> +Fast deinterlacing algorithms.
> +
> +@table @option
> +@item mode
> +Deinterlacing algorithm to use.
> +
> +It accepts the following values:
> +@table @samp
> +@item discard
> +Discard bottom frame.
> +
> +@item mean
> +Half resolution blender.
> +
> +@item blend
> +Full resolution blender.
> +
> +@item bob
> +Bob doubler.
> +
> +@item linear
> +Bob doubler with linear interpolation.
> +@end table
> +
> +@end table
> +
> @section fftdnoiz
> Denoise frames using 3D FFT (frequency domain filtering).
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 3ef4191d9a..a2b3566ec0 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -234,6 +234,7 @@ OBJS-$(CONFIG_EROSION_OPENCL_FILTER) +=
> vf_neighbor_opencl.o opencl.o \
> opencl/neighbor.o
> OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
> OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
> +OBJS-$(CONFIG_FASTDEINT_FILTER) += vf_fastdeint.o
> OBJS-$(CONFIG_FFTDNOIZ_FILTER) += vf_fftdnoiz.o
> OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
> OBJS-$(CONFIG_FIELD_FILTER) += vf_field.o
> diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
> index b58daa3a3f..2b0ad92893 100644
> --- a/libavfilter/aarch64/Makefile
> +++ b/libavfilter/aarch64/Makefile
> @@ -1,3 +1,4 @@
> OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
>
> +NEON-OBJS-$(CONFIG_FASTDEINT_FILTER) += aarch64/merge_neon.o
> NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/vf_nlmeans_neon.o
> diff --git a/libavfilter/aarch64/merge_neon.S
> b/libavfilter/aarch64/merge_neon.S
> new file mode 100644
> index 00..62377331a4
> --- /dev/null
> +++ b/libavfilter/aarch64/merge_neon.S
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2009-2016 Rémi Denis-Courmont, Janne Grunau, VLC authors
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/aarch64/asm.S"
> +
> +#define dest x0
> +#define src1 x1
> +#define src2 x2
> +#define size x3
> +
> +.align 2
> +// NOTE: Offset and pitch must be multiple of 16-bytes.
> +function ff_merge8_neon, export=1
> +andsx5, size, #~63
> +b.eq2f
> +mov x10, #64
> +add x11, src1, #32
> +add x12, src2, #32
> +1:
> +ld1 {v0.16b,v1.16b}, [src1], x10
> +ld1 {v4.16b,v5.16b}, [src2], x10
> +ld1 {v2.16b,v3.16b}, [x11], x10
> +uhadd v0.16b, v0.16b, v4.16b
> +ld1 {v6.16b,v7.16b}, [x12], x10
> +subsx5, x5, #64
> +uhadd v1.16b, v1.16b, v5.16b
> +uhadd v2.16b, v2.16b, v6.16b
> +uhadd v3.16b, v3.16b, v7.16b
> +st1 {v0.16b,v1.16b}, [dest], #32
> +st1
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/dxv: Check op_offset in both directions
On 9/9/19, Michael Niedermayer wrote: > On Fri, Jul 19, 2019 at 09:53:34PM +0200, Michael Niedermayer wrote: >> On Fri, Jul 19, 2019 at 03:36:43PM +0200, Paul B Mahol wrote: >> > On 7/19/19, Michael Niedermayer wrote: >> > > On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote: >> > >> On 6/27/19, Michael Niedermayer wrote: >> > >> > Fixes: signed integer overflow: 61 + 2147483647 cannot be >> > >> > represented >> > >> > in >> > >> > type 'int' >> > >> > Fixes: >> > >> > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504 >> > >> > >> > >> > Found-by: continuous fuzzing process >> > >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >> > >> > Signed-off-by: Michael Niedermayer >> > >> > --- >> > >> > libavcodec/dxv.c | 2 +- >> > >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > >> > >> > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c >> > >> > index 5fd1844094..3506775560 100644 >> > >> > --- a/libavcodec/dxv.c >> > >> > +++ b/libavcodec/dxv.c >> > >> > @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext >> > >> > *ctx, >> > >> > GetByteContext *gb, >> > >> > int skip0, skip1, oi0 = 0, oi1 = 0; >> > >> > int ret, state0 = 0, state1 = 0; >> > >> > >> > >> > -if (op_offset < 12) >> > >> > +if (op_offset < 12 || op_offset - 12 > >> > >> > bytestream2_get_bytes_left(gb)) >> > >> > return AVERROR_INVALIDDATA; >> > >> > >> > >> > dst = tex_data; >> > >> > -- >> > >> > 2.22.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". >> > >> >> > >> Make sure this does not break any files. >> > > >> > > Do you have any specific files i should test ? >> > > >> > > I of course cannot test every file on earth ... >> > >> > I'm on vacation, so when I get back I will give you some files. >> >> ok, ill wait, no hurry, enjoy your vacation! > > ping, this issue is reaching its deadline, so i would like to > fix it What deadline? Is this some kind of fancy corporation? > > Thanks > > [...] > > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When you are offended at any man's fault, turn to yourself and study your > own failings. Then you will forget your anger. -- Epictetus > ___ 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 PATCH] avfilter/fastdeint: import simple cpu-optimized deinterlacing algorithms from VLC
From: Aman Gupta
These are simple algorithms which can be run efficiently
on low powered devices to produce deinteraced images.
Signed-off-by: Aman Gupta
---
doc/filters.texi | 27 ++
libavfilter/Makefile | 1 +
libavfilter/aarch64/Makefile | 1 +
libavfilter/aarch64/merge_neon.S | 98 ++
libavfilter/allfilters.c | 1 +
libavfilter/arm/Makefile | 3 +
libavfilter/arm/merge_armv6.S| 70
libavfilter/arm/merge_neon.S | 109 ++
libavfilter/vf_fastdeint.c | 588 +++
9 files changed, 898 insertions(+)
create mode 100644 libavfilter/aarch64/merge_neon.S
create mode 100644 libavfilter/arm/Makefile
create mode 100644 libavfilter/arm/merge_armv6.S
create mode 100644 libavfilter/arm/merge_neon.S
create mode 100644 libavfilter/vf_fastdeint.c
diff --git a/doc/filters.texi b/doc/filters.texi
index 6c81e1da40..55d9adeb81 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -9796,6 +9796,33 @@ fade=t=in:st=5.5:d=0.5
@end itemize
+@section fastdeint
+Fast deinterlacing algorithms.
+
+@table @option
+@item mode
+Deinterlacing algorithm to use.
+
+It accepts the following values:
+@table @samp
+@item discard
+Discard bottom frame.
+
+@item mean
+Half resolution blender.
+
+@item blend
+Full resolution blender.
+
+@item bob
+Bob doubler.
+
+@item linear
+Bob doubler with linear interpolation.
+@end table
+
+@end table
+
@section fftdnoiz
Denoise frames using 3D FFT (frequency domain filtering).
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 3ef4191d9a..a2b3566ec0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -234,6 +234,7 @@ OBJS-$(CONFIG_EROSION_OPENCL_FILTER) +=
vf_neighbor_opencl.o opencl.o \
opencl/neighbor.o
OBJS-$(CONFIG_EXTRACTPLANES_FILTER) += vf_extractplanes.o
OBJS-$(CONFIG_FADE_FILTER) += vf_fade.o
+OBJS-$(CONFIG_FASTDEINT_FILTER) += vf_fastdeint.o
OBJS-$(CONFIG_FFTDNOIZ_FILTER) += vf_fftdnoiz.o
OBJS-$(CONFIG_FFTFILT_FILTER)+= vf_fftfilt.o
OBJS-$(CONFIG_FIELD_FILTER) += vf_field.o
diff --git a/libavfilter/aarch64/Makefile b/libavfilter/aarch64/Makefile
index b58daa3a3f..2b0ad92893 100644
--- a/libavfilter/aarch64/Makefile
+++ b/libavfilter/aarch64/Makefile
@@ -1,3 +1,4 @@
OBJS-$(CONFIG_NLMEANS_FILTER)+= aarch64/vf_nlmeans_init.o
+NEON-OBJS-$(CONFIG_FASTDEINT_FILTER) += aarch64/merge_neon.o
NEON-OBJS-$(CONFIG_NLMEANS_FILTER) += aarch64/vf_nlmeans_neon.o
diff --git a/libavfilter/aarch64/merge_neon.S b/libavfilter/aarch64/merge_neon.S
new file mode 100644
index 00..62377331a4
--- /dev/null
+++ b/libavfilter/aarch64/merge_neon.S
@@ -0,0 +1,98 @@
+/*
+ * Copyright (c) 2009-2016 Rémi Denis-Courmont, Janne Grunau, VLC authors
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+#define dest x0
+#define src1 x1
+#define src2 x2
+#define size x3
+
+.align 2
+// NOTE: Offset and pitch must be multiple of 16-bytes.
+function ff_merge8_neon, export=1
+andsx5, size, #~63
+b.eq2f
+mov x10, #64
+add x11, src1, #32
+add x12, src2, #32
+1:
+ld1 {v0.16b,v1.16b}, [src1], x10
+ld1 {v4.16b,v5.16b}, [src2], x10
+ld1 {v2.16b,v3.16b}, [x11], x10
+uhadd v0.16b, v0.16b, v4.16b
+ld1 {v6.16b,v7.16b}, [x12], x10
+subsx5, x5, #64
+uhadd v1.16b, v1.16b, v5.16b
+uhadd v2.16b, v2.16b, v6.16b
+uhadd v3.16b, v3.16b, v7.16b
+st1 {v0.16b,v1.16b}, [dest], #32
+st1 {v2.16b,v3.16b}, [dest], #32
+b.gt1b
+2:
+tbz size, #5, 3f
+ld1 {v0.16b,v1.16b}, [src1], #32
+ld1 {v4.16b,v5.16b}, [src2], #32
+uhadd v0.16b, v0.16b, v4.16b
+uhadd v1.16b, v1.16b, v5.16b
+st1 {v0.16b,v1.16b}, [dest], #32
+3
[FFmpeg-devel] [PATCH 1/2] avcodec/g2meet: Check if adjusted pixel was on the stack
This basically checks if a pixel that was coded with prediction
and residual could have been stored using a previous case.
This avoids basically a string of 0 symbols stored in less than
50 bytes to hit a O(n²) codepath.
Fixes: Timeout (too slow to wait -> immedeatly)
Fixes:
8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-4895946310680576
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/g2meet.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c
index a1dec8d823..19e1c130ce 100644
--- a/libavcodec/g2meet.c
+++ b/libavcodec/g2meet.c
@@ -854,6 +854,9 @@ static int epic_decode_tile(ePICContext *dc, uint8_t *out,
int tile_height,
uint32_t ref_pix = curr_row[x - 1];
if (!x || !epic_decode_from_cache(dc, ref_pix, &pix)) {
pix = epic_decode_pixel_pred(dc, x, y, curr_row,
above_row);
+if (is_pixel_on_stack(dc, pix))
+return AVERROR_INVALIDDATA;
+
if (x) {
int ret = epic_add_pixel_to_cache(&dc->hash,
ref_pix,
--
2.23.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 2/2] avcodec/g2meet: Check for end of input in jpg_decode_block()
Fixes: Timeout (100sec -> 0.7sec) Fixes: 8668/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_G2M_fuzzer-5174143888130048 Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer --- libavcodec/g2meet.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/libavcodec/g2meet.c b/libavcodec/g2meet.c index 19e1c130ce..731d29a5d4 100644 --- a/libavcodec/g2meet.c +++ b/libavcodec/g2meet.c @@ -244,6 +244,9 @@ static int jpg_decode_block(JPGContext *c, GetBitContext *gb, const int is_chroma = !!plane; const uint8_t *qmat = is_chroma ? chroma_quant : luma_quant; +if (get_bits_left(gb) < 1) +return AVERROR_INVALIDDATA; + c->bdsp.clear_block(block); dc = get_vlc2(gb, c->dc_vlc[is_chroma].table, 9, 3); if (dc < 0) -- 2.23.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".
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/dxv: Check op_offset in both directions
On Fri, Jul 19, 2019 at 09:53:34PM +0200, Michael Niedermayer wrote: > On Fri, Jul 19, 2019 at 03:36:43PM +0200, Paul B Mahol wrote: > > On 7/19/19, Michael Niedermayer wrote: > > > On Thu, Jun 27, 2019 at 09:32:44AM +0200, Paul B Mahol wrote: > > >> On 6/27/19, Michael Niedermayer wrote: > > >> > Fixes: signed integer overflow: 61 + 2147483647 cannot be represented > > >> > in > > >> > type 'int' > > >> > Fixes: > > >> > 15311/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DXV_fuzzer-5742552826773504 > > >> > > > >> > Found-by: continuous fuzzing process > > >> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > >> > Signed-off-by: Michael Niedermayer > > >> > --- > > >> > libavcodec/dxv.c | 2 +- > > >> > 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > > >> > diff --git a/libavcodec/dxv.c b/libavcodec/dxv.c > > >> > index 5fd1844094..3506775560 100644 > > >> > --- a/libavcodec/dxv.c > > >> > +++ b/libavcodec/dxv.c > > >> > @@ -745,7 +745,7 @@ static int dxv_decompress_cocg(DXVContext *ctx, > > >> > GetByteContext *gb, > > >> > int skip0, skip1, oi0 = 0, oi1 = 0; > > >> > int ret, state0 = 0, state1 = 0; > > >> > > > >> > -if (op_offset < 12) > > >> > +if (op_offset < 12 || op_offset - 12 > > > >> > bytestream2_get_bytes_left(gb)) > > >> > return AVERROR_INVALIDDATA; > > >> > > > >> > dst = tex_data; > > >> > -- > > >> > 2.22.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". > > >> > > >> Make sure this does not break any files. > > > > > > Do you have any specific files i should test ? > > > > > > I of course cannot test every file on earth ... > > > > I'm on vacation, so when I get back I will give you some files. > > ok, ill wait, no hurry, enjoy your vacation! ping, this issue is reaching its deadline, so i would like to fix it Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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] cmdutils: promote report level if loglevel is higher
From 9581ee61d2eaeac1cf2a0262d010e95d316228db Mon Sep 17 00:00:00 2001
From: Gyan Doshi
Date: Mon, 9 Sep 2019 23:37:08 +0530
Subject: [PATCH] cmdutils: promote report level if loglevel is higher
---
fftools/cmdutils.c | 11 +--
1 file changed, 9 insertions(+), 2 deletions(-)
diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index fdcd376b76..5705fcf4c5 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -980,6 +980,7 @@ static int init_report(const char *env)
char *filename_template = NULL;
char *key, *val;
int ret, count = 0;
+int prog_loglevel, envlevel = 0;
time_t now;
struct tm *tm;
AVBPrint filename;
@@ -1011,6 +1012,7 @@ static int init_report(const char *env)
av_log(NULL, AV_LOG_FATAL, "Invalid report file level\n");
exit_program(1);
}
+envlevel = 1;
} else {
av_log(NULL, AV_LOG_ERROR, "Unknown key '%s' in FFREPORT\n", key);
}
@@ -1027,6 +1029,10 @@ static int init_report(const char *env)
return AVERROR(ENOMEM);
}
+prog_loglevel = av_log_get_level();
+if (!envlevel)
+report_file_level = FFMAX(report_file_level, prog_loglevel);
+
report_file = fopen(filename.str, "w");
if (!report_file) {
int ret = AVERROR(errno);
@@ -1037,11 +1043,12 @@ static int init_report(const char *env)
av_log_set_callback(log_callback_report);
av_log(NULL, AV_LOG_INFO,
"%s started on %04d-%02d-%02d at %02d:%02d:%02d\n"
- "Report written to \"%s\"\n",
+ "Report written to \"%s\"\n"
+ "Log level: %d \n",
program_name,
tm->tm_year + 1900, tm->tm_mon + 1, tm->tm_mday,
tm->tm_hour, tm->tm_min, tm->tm_sec,
- filename.str);
+ filename.str, report_file_level);
av_bprint_finalize(&filename, NULL);
return 0;
}
--
2.22.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".
Re: [FFmpeg-devel] [PATCH] tests: Fix bash errors in lavf_container tests.
On Sun, Sep 08, 2019 at 06:45:30PM +0800, Limin Wang wrote: > On Sun, Sep 08, 2019 at 12:46:25AM +0300, Andrey Semashev wrote: > > On 2019-09-07 18:32, Limin Wang wrote: > > >On Sat, Sep 07, 2019 at 05:19:55PM +0200, Michael Niedermayer wrote: > > >>On Wed, Aug 28, 2019 at 06:32:37PM +0300, Andrey Semashev wrote: > > >>>Because lavf_container is sometimes called with only 2 arguments, > > >>>fate tests produce bash errors like this: > > >>> > > >>> tests/fate-run.sh: 299: test: =: unexpected operator > > >>> > > >>>This commit fixes this. > > >>>--- > > >>> tests/fate-run.sh | 2 +- > > >>> 1 file changed, 1 insertion(+), 1 deletion(-) > > >> > > >>I think this change is correct but shell is not my area ... > > >If the $2 is two arguments between with space, the patch is needed. > > > > $2 is a single argument that may contain spaces. It is interpreted > > as a single argument as long as it is enclosed in quotes in > > lavf_container invokation. > > > > The problem is caused not by $2 but by the fact there is no $3. See > > lavf_container_attach, lavf_container_timecode_nodrop, > > lavf_container_timecode_drop and lavf_container_timecode functions, > > as well as a few tests in tests/fate/lavf-container.mak. > > > > >Why I haven't got such errors when I'm running fate? > > > > I noticed the errors when the tests failed (due to my local changes > > not relevant to this patch). I don't know the details about how > > tests are run, but maybe the output is suppressed when the tests > > pass? > The patch looks good to me, but I don't have push access. Please ask for > other developer to push it. will apply 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 v3 1/2] swscale/swscale: delete unwanted assignments
On Sun, Sep 08, 2019 at 09:12:14PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libswscale/swscale.c | 2 -- > 1 file changed, 2 deletions(-) will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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] libavfilter/vf_drawtext: Avoid undefined behavior from GET_UTF8
On Sat, Jul 27, 2019 at 07:58:48AM -0700, Aaron Boushley wrote:
> The vf_drawtext filter uses the GET_UTF8 macro in multiple locations.
> Each of these use `continue;` as the error handler. However the
> documentation for the GET_UTF8 macro states "ERROR should not contain
> a loop control statement which could interact with the internal while
> loop, and should force an exit from the macro code (e.g. through a
> goto or a return) in order to prevent undefined results."
>
> This patch adjusts vf_drawtext to use goto error handlers similar to
> other locations in ffmpeg.
>
> Aaron
>
> PS Sorry for having to send again, sent from the wrong address last
> time, so patchwork didn't pick it up.
>
> vf_drawtext.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
> 04550ed40f98ec78c2719de31da889e92ff42f45
> libavfilter-drawtext-avoid-undefined-behavior.patch
> From efdc96ace59d676e76434499a399d1d7df7fa093 Mon Sep 17 00:00:00 2001
> From: Aaron Boushley
> Date: Fri, 26 Jul 2019 15:49:36 -0700
> Subject: [PATCH] libavfilter/drawtext: avoid undefined behavior with GET_UTF8
>
> Currently the GET_UTF8 usage in drawtext use a continue to skip invalid
> characters in a string. The macro definition states that using a loop
> control statement results in undefined behavior since the macro itself
> uses a loop.
>
> This switches drawtext to use a goto statement similar to other usages
> of GET_UTF8 in other parts of ffmpeg.
>
> Signed-off-by: Aaron Boushley
> ---
> libavfilter/vf_drawtext.c | 17 ++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
> diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
> index 8f4badbdb5..fd2ba84d12 100644
> --- a/libavfilter/vf_drawtext.c
> +++ b/libavfilter/vf_drawtext.c
> @@ -1223,7 +1223,7 @@ static int draw_glyphs(DrawTextContext *s, AVFrame
> *frame,
> for (i = 0, p = text; *p; i++) {
> FT_Bitmap bitmap;
> Glyph dummy = { 0 };
> -GET_UTF8(code, *p++, continue;);
> +GET_UTF8(code, *p++, goto invalid_drawing;);
>
> /* skip new line chars, just go to new line */
> if (code == '\n' || code == '\r' || code == '\t')
> @@ -1248,6 +1248,9 @@ static int draw_glyphs(DrawTextContext *s, AVFrame
> *frame,
>bitmap.width, bitmap.rows,
>bitmap.pixel_mode == FT_PIXEL_MODE_MONO ? 0 : 3,
>0, x1, y1);
> +continue;
> +invalid_drawing:
> +av_log(s, AV_LOG_DEBUG, "Invalid UTF8 character while drawing
> glyphs\n");
> }
Why does this add av_log() calls ?
This seems unrelated to the bug fix. Also why are they debug level ?
if a user draws a string she provided that could be argued to be an error
the user wants to know about. But maybe iam missing something
Also they probably should provide more information about where the
invalid character is. It may be hard to find in a long text for some users
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The educated differ from the uneducated as much as the living from the
dead. -- Aristotle
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] libsrt: add password ACL support using new streamID specification
Hello!
SRT has added a new stream ID specification allowing extraction of various
fields from the user password. This patch adds support for using an ACL to
check user credentials - base on this Haivision sample code:
https://github.com/Haivision/srt/blob/master/testing/srt-test-live.cpp
Thanks,
Aaron
From 8a11e0d673872049b8260cb08f3c7cb40f9a1297 Mon Sep 17 00:00:00 2001
From: Aaron Boxer
Date: Wed, 14 Aug 2019 08:26:17 -0400
Subject: [PATCH] libsrt: support streamid spec
---
libavformat/libsrt.c | 135 +++
1 file changed, 135 insertions(+)
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index b5568089fa..d597e5fce4 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -34,6 +34,9 @@
#include "os_support.h"
#include "url.h"
+
+static srt_listen_callback_fn libsrt_listen_callback;
+
/* This is for MPEG-TS and it's a default SRTO_PAYLOADSIZE for SRTT_LIVE (8 TS packets) */
#ifndef SRT_LIVE_DEFAULT_PAYLOAD_SIZE
#define SRT_LIVE_DEFAULT_PAYLOAD_SIZE 1316
@@ -62,6 +65,7 @@ typedef struct SRTContext {
int64_t maxbw;
int pbkeylen;
char *passphrase;
+char* user_passphrase_list;
int mss;
int ffs;
int ipttl;
@@ -101,6 +105,7 @@ static const AVOption libsrt_options[] = {
{ "maxbw", "Maximum bandwidth (bytes per second) that the connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{ .i64 = -1 }, -1, INT64_MAX, .flags = D|E },
{ "pbkeylen", "Crypto key len in bytes {16,24,32} Default: 16 (128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 32,.flags = D|E },
{ "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable crypto", OFFSET(passphrase), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = D|E },
+{ "user_passphrase_list", "Comma separated list users and passphrases, of form usrr1=pass1,usr2=pass2,...", OFFSET(user_passphrase_list), AV_OPT_TYPE_STRING, { .str = NULL }, .flags = D|E },
{ "mss","The Maximum Segment Size", OFFSET(mss), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 1500, .flags = D|E },
{ "ffs","Flight flag size (window size) (in bytes)",OFFSET(ffs), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, INT_MAX, .flags = D|E },
{ "ipttl", "IP Time To Live", OFFSET(ipttl),AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 255, .flags = D|E },
@@ -196,10 +201,134 @@ static int libsrt_network_wait_fd_timeout(URLContext *h, int eid, int fd, int wr
}
}
+typedef struct _libsrt_parsed_param {
+char *key;
+char *val;
+} libsrt_parsed_param;
+
+
+/**
+ * Parse a key-value string into an array of key/value structs.
+ *
+ * The key-value string should be a null terminated string of parameters separated
+ * by a delimiter. Each parameter are checked for the equal sign character.
+ * If the equal sign character appears in the parameter, it will be used as a null terminator
+ * and the part that comes after it will be the value of the parameter.
+ *
+ *
+ * param: keyvalue: the key-value string to parse. The string will be modified.
+ * param: delimiter:the character that separates the key/value pairs
+ * from each other.
+ * param: params: an array of parsed_param structs to hold the result.
+ * param: max_params: maximum number of parameters to parse.
+ *
+ * Return:the number of parsed items. -1 if there was an error.
+ */
+static int libsrt_parse_key_value(char *keyvalue, const char* delimiter,
+libsrt_parsed_param *params, int max_params)
+{
+int i = 0;
+char *token = NULL;
+
+if (!keyvalue || *keyvalue == '\0')
+return -1;
+if (!params || max_params == 0)
+return 0;
+
+token = strtok( keyvalue, delimiter );
+while (token != NULL && i < max_params) {
+params[i].key = token;
+params[i].val = NULL;
+if ((params[i].val = strchr( params[i].key, '=' )) != NULL) {
+size_t val_len = strlen( params[i].val );
+/* make key into a zero-delimited string */
+*(params[i].val) = '\0';
+/* make sure val is not empty */
+if (val_len > 1) {
+params[i].val++;
+/* make sure key is not empty */
+if (params[i].key[0])
+i++;
+};
+}
+token = strtok( NULL, delimiter );
+}
+
+return i;
+}
+
+/* callback to parse streamid */
+static int libsrt_listen_callback(void* opaq, SRTSOCKET ns, int hsversion, const struct sockaddr* peeraddr, const char* streamid)
+{
+const char* username = NULL;
+const char* expected_passphrase = NULL;
+static const char stdhdr [] = "#!::";
+u
Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Friday, August 30, 2019 16:05
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> hw_frames_ctx for vp9 without destroy va_context
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> Behalf
> > Of Fu, Linjie
> > Sent: Friday, August 9, 2019 19:47
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx for vp9 without destroy va_context
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Hendrik Leppkes
> > > Sent: Friday, August 9, 2019 17:40
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie wrote:
> > > >
> > > > > -Original Message-
> > > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > > > Of Hendrik Leppkes
> > > > > Sent: Tuesday, August 6, 2019 16:27
> > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org>
> > > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > recreate
> > > > > hw_frames_ctx for vp9 without destroy va_context
> > > > >
> > > > > On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu
> > > > > wrote:
> > > > > >
> > > > > > VP9 allows resolution changes per frame. Currently in VAAPI,
> > resolution
> > > > > > changes leads to va context destroy and reinit. This will cause
> > > > > > reference frame surface lost and produce garbage.
> > > > > >
> > > > > > Though refs surface id could be passed to media driver and found in
> > > > > > RTtbl, vp9RefList[] in hal layer has already been destroyed. Thus
> > > > > > the
> > > > > > new created VaContext could only got an empty RefList.
> > > > > >
> > > > > > As libva allows re-create surface separately without changing the
> > > > > > context, this issue could be handled by only recreating
> > hw_frames_ctx.
> > > > > >
> > > > > > Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > > > > > hw_frame_ctx when dynamic resolution changing happens.
> > > > > >
> > > > > > Could be verified by:
> > > > > > ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > > > > ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
> vaapi.yuv
> > > > > >
> > > > > > Signed-off-by: Linjie Fu
> > > > > > ---
> > > > > > libavcodec/decode.c| 10 +-
> > > > > > libavcodec/internal.h | 1 +
> > > > > > libavcodec/pthread_frame.c | 2 ++
> > > > > > libavcodec/vaapi_decode.c | 40 ++---
> --
> > --
> > > -
> > > > > --
> > > > > > libavcodec/vaapi_vp9.c | 4
> > > > > > 5 files changed, 34 insertions(+), 23 deletions(-)
> > > > > >
> > > > > > diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > > > > index 0863b82..7b15fa5 100644
> > > > > > --- a/libavcodec/decode.c
> > > > > > +++ b/libavcodec/decode.c
> > > > > > @@ -1254,7 +1254,6 @@ int
> > > > > ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > > > > >
> > > > > > frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
> > >data;
> > > > > >
> > > > > > -
> > > > > > if (frames_ctx->initial_pool_size) {
> > > > > > // We guarantee 4 base work surfaces. The function above
> > > guarantees
> > > > > 1
> > > > > > // (the absolute minimum), so add the missing count.
> > > > >
> > > > > Unrelated whitespace change
> > > >
> > > > There is a redundant whitespace here, so I removed it within this
> > > > patch.
> > > >
> > > > > > @@ -1333,7 +1332,7 @@ static int hwaccel_init(AVCodecContext
> > > *avctx,
> > > > > > return AVERROR_PATCHWELCOME;
> > > > > > }
> > > > > >
> > > > > > -if (hwaccel->priv_data_size) {
> > > > > > +if (hwaccel->priv_data_size && !avctx->internal-
> > > >hwaccel_priv_data) {
> > > > > > avctx->internal->hwaccel_priv_data =
> > > > > > av_mallocz(hwaccel->priv_data_size);
> > > > > > if (!avctx->internal->hwaccel_priv_data)
> > > > > > @@ -1396,9 +1395,10 @@ int ff_get_format(AVCodecContext
> *avctx,
> > > > > const enum AVPixelFormat *fmt)
> > > > > > memcpy(choices, fmt, (n + 1) * sizeof(*choices));
> > > > > >
> > > > > > for (;;) {
> > > > > > -// Remove the previous hwaccel, if there was one.
> > > > > > -hwaccel_uninit(avctx);
> > > > > > -
> > > > > > +// Remove the previous hwaccel, if there was one,
> > > > > > +// and no need for keeping.
> > > > > > +if (!avctx->internal->hwaccel_priv_data_k
Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format
> -Original Message- > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf > Of Carl Eugen Hoyos > Sent: Sunday, September 1, 2019 01:57 > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel format > > Am Sa., 31. Aug. 2019 um 19:25 Uhr schrieb Fu, Linjie : > > > > > -Original Message- > > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > Behalf > > > Of Mark Thompson > > > Sent: Saturday, August 31, 2019 23:10 > > > To: ffmpeg-devel@ffmpeg.org > > > Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > format > > > > > > On 31/08/2019 05:22, Fu, Linjie wrote: > > > >> -Original Message- > > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On > > > Behalf > > > >> Of Carl Eugen Hoyos > > > >> Sent: Friday, August 30, 2019 00:12 > > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org> > > > >> Subject: Re: [FFmpeg-devel] [PATCH 1/2] lavu/pixfmt: add AYUV pixel > > > format > > > >> > > > >> Am Do., 29. Aug. 2019 um 16:16 Uhr schrieb Fu, Linjie > > > : > > > >> > > > >>> Thus AYUV will make more sense. > > > >> > > > >> If your hardware decoding does not produce valid alpha data (0xFF > > > >> for opaque, 0x00 for completely transparent), you cannot use an > > > >> FFmpeg pix_fmt that defines alpha for decoding. > > > >> If you define a pix_fmt that does not contain alpha information (as > > > >> needed for your hardware decoder), please do not use "A" in its > > > >> name. > > > > > > > > The hardware decode output is in packed 4:4:4:4 8 bit(32 bits in total). > Apart> > > > from Y/U/V channel, there is an additional need for a channel to store the > > > > zero byte in surfaces(nb_components = 4). And it is designed in > > > hardware/driver > > > > for VA_FourCC_AYUV and AYUV format. > > > > > > > > It's not quite proper to use something like "0YUV" directly which > indicates > > > that > > > > there is no Alpha channel data like"RGB0" or "0RGB"(nb_components = > 3). > > > > > > > > "0YUV": YUV0/YUV0/... > > > > "RGB0":RGB/RGB/... > > > > > > I think you've misread what RGB0 is. The component step is 4, not 3 (see > > > libavutil/pixdesc.c) - the format with a step of 3 is RGB24. > > > > > > RGBA: R G B A R G B A ... > > > RGB0: R G B 0 R G B 0 ... > > > RGB24: R G B R G B R G ... > > > > Thanks for pointing out this. > > Just took the nb_components into account and misread the step info at > first. > > > > > Following the same pattern we would have: > > > > > > AYUV: A Y U V A Y U V ... > > > 0YUV: 0 Y U V 0 Y U V ... > > > > > > To me it looks like 0YUV is exactly what you want here. > > > > Will update the patch if 0YUV is more acceptable. > > Could you double-check if there is no bug in the decoder? > I ask because transparency is possible with hevc and the > relevant Windows format does support transparency from > how I read the specification. > Hi, Rethink about this, hardware decoder should support a valid alpha data. Default 0x00 or 0xFF for alpha channel doesn't make sense in HEVC Rext decoding. Filed an issue in media driver: https://github.com/intel/media-driver/issues/719 Will rebase and resend the patch set for QSV HEVC REXT decoding, basing on AYUV,Y410, Y210. Thanks, 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 V1] lavfi/concat: fix logic error in framerate check
Jun Zhao (12019-09-09): > From: Jun Zhao > > fix logic error in framerate check, it's introduced by commit > 3ad5d4df9ce794d3eeb0f526c5f3e446bf97c616 > > Signed-off-by: Jun Zhao > --- > libavfilter/avf_concat.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) Of course, thanks. Sorry for missing it. 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/webp: avoid trying to decode trailing junk in bitstreams
Michael, On Fri, Sep 6, 2019 at 6:21 PM Michael Niedermayer wrote: > On Fri, Sep 06, 2019 at 01:11:50PM +0200, Pascal Massimino wrote: > > Michael, > > > > On Thu, Sep 5, 2019 at 6:20 PM Michael Niedermayer > > > wrote: > > > > > On Wed, Sep 04, 2019 at 07:43:15AM +0200, Pascal Massimino wrote: > [...] > > > > > > > i would guess its not a known chunk but rather hits the default > > > is that just a bunch of 0 or 0xFF bytes ? > > > detecting before we read into the end feels more robust if > > > we can simply detect the "junk" > > > > > > > As i mentioned in the description, a possibly more robust solution would > be > > just stopping the loop as soon as 'chunk_size' bytes have been consumed > > (leading to *got_frame = 1) and no more. This current patch is > minimalist, > > though. > > well, which solution do you prefer ? > the one in the patch is fine. skal/ > > thx > > [...] > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The educated differ from the uneducated as much as the living from the > dead. -- Aristotle > ___ > 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] Please allow specific starting frame to be selected.
I have an MP4 video, and I'm trying to extract 100 frames starting from frame number 271. As of right now I can select duration by time using -t or by frame count by using -frames. And I can also select starting point by time by using -ss. However, I believe that as of now there is no command line switch to select the starting point by frame number. PLEASE add a feature such as a command line switch like "-sf" for "starting frame". I need to be able to select a range of video frames based entirely on frame numbers (not time stamps). ___ 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] lavfi/concat: fix logic error in framerate check
On Mon, Sep 9, 2019 at 3:21 PM Paul B Mahol wrote:
>
> lgtm
>
Will apply, Thanks
> On 9/9/19, Jun Zhao wrote:
> > From: Jun Zhao
> >
> > fix logic error in framerate check, it's introduced by commit
> > 3ad5d4df9ce794d3eeb0f526c5f3e446bf97c616
> >
> > Signed-off-by: Jun Zhao
> > ---
> > libavfilter/avf_concat.c |2 +-
> > 1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
> > index 2791859..28bd540 100644
> > --- a/libavfilter/avf_concat.c
> > +++ b/libavfilter/avf_concat.c
> > @@ -136,7 +136,7 @@ static int config_output(AVFilterLink *outlink)
> > for (seg = 1; seg < cat->nb_segments; seg++) {
> > inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
> > if (outlink->frame_rate.num != inlink->frame_rate.num ||
> > -outlink->frame_rate.den != outlink->frame_rate.den) {
> > +outlink->frame_rate.den != inlink->frame_rate.den) {
> > av_log(ctx, AV_LOG_VERBOSE,
> > "Video inputs have different frame rates, output will
> > be VFR\n");
> > outlink->frame_rate = av_make_q(1, 0);
> > --
> > 1.7.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] configure: check for a sufficiently recent enough AMF version
On Mon, Sep 9, 2019 at 4:30 AM James Almer wrote: > > On 9/8/2019 7:51 PM, Hendrik Leppkes wrote: > > Due to the recent addition of Vulkan support to AMF, we require more > > recent headers that include the new structures, which have been > > available since AMF 1.4.9 released in September 2018. > > --- > > configure | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/configure b/configure > > index 4141c1e8f4..8413826f9e 100755 > > --- a/configure > > +++ b/configure > > @@ -6617,7 +6617,7 @@ EOF > > > > enabled amf && > > check_cpp_condition amf "AMF/core/Version.h" \ > > -"(AMF_VERSION_MAJOR << 48 | AMF_VERSION_MINOR << 32 | > > AMF_VERSION_RELEASE << 16 | AMF_VERSION_BUILD_NUM) >= 0x0001000400040001" > > +"(AMF_VERSION_MAJOR << 48 | AMF_VERSION_MINOR << 32 | > > AMF_VERSION_RELEASE << 16 | AMF_VERSION_BUILD_NUM) >= 0x000100040009" > > > > # Funny iconv installations are not unusual, so check it after all flags > > have been set > > if enabled libc_iconv; then > > LGTM. Applied with a reference to the trac issue ___ 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] avfilter/vf_fps: Avoid inlink fifo build up.
lgtm On 8/29/19, Nikolas Bowe wrote: > When duplicating frames we need to schedule for activation again, otherwise > frames can build up in the inlink fifo. > --- > libavfilter/vf_fps.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/vf_fps.c b/libavfilter/vf_fps.c > index 6b99f20d2b..cf1e36726a 100644 > --- a/libavfilter/vf_fps.c > +++ b/libavfilter/vf_fps.c > @@ -256,7 +256,7 @@ static int write_frame(AVFilterContext *ctx, FPSContext > *s, AVFilterLink *outlin > av_log(ctx, AV_LOG_DEBUG, "Writing frame with pts %"PRId64" to pts > %"PRId64"\n", > s->frames[0]->pts, frame->pts); > s->cur_frame_out++; > - > +*again = 1; > return ff_filter_frame(outlink, frame); > } > } > -- > 2.23.0.187.g17f5b7556c-goog > > ___ > 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] lavfi/concat: fix logic error in framerate check
lgtm
On 9/9/19, Jun Zhao wrote:
> From: Jun Zhao
>
> fix logic error in framerate check, it's introduced by commit
> 3ad5d4df9ce794d3eeb0f526c5f3e446bf97c616
>
> Signed-off-by: Jun Zhao
> ---
> libavfilter/avf_concat.c |2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
> index 2791859..28bd540 100644
> --- a/libavfilter/avf_concat.c
> +++ b/libavfilter/avf_concat.c
> @@ -136,7 +136,7 @@ static int config_output(AVFilterLink *outlink)
> for (seg = 1; seg < cat->nb_segments; seg++) {
> inlink = ctx->inputs[in_no + seg * ctx->nb_outputs];
> if (outlink->frame_rate.num != inlink->frame_rate.num ||
> -outlink->frame_rate.den != outlink->frame_rate.den) {
> +outlink->frame_rate.den != inlink->frame_rate.den) {
> av_log(ctx, AV_LOG_VERBOSE,
> "Video inputs have different frame rates, output will
> be VFR\n");
> outlink->frame_rate = av_make_q(1, 0);
> --
> 1.7.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".
