Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc
On Sun, Mar 27, 2016 at 11:15 PM, Kirill Gavrilov
wrote:
> Hi,
>
Hi,
>
> on my device ("OMX.allwinner.video.decoder.avc") returned stride property
> is always 0.
> I have found that stride is overridden for "OMX.SEC.avc.dec" and prepared
> the similar patch.
> But probably it is better to change comparison at the line above to "value
> > 0"?
> >s->stride = value >= 0 ? value : s->width
>
I think it would be better to change the comparaison line. Can you send the
relevant patch ?
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
On Mon, 28 Mar 2016, Hendrik Leppkes wrote: People that don't speak up at all may approve silently (or at least not disapprove), someone that raised issues should give an explicit OK/Nevermind/whatever, agreeing with you or withdrawing his complaints, there is no "silent" option there. This seems unreasonable, beacuse this way a silent person can block a patch forever, which is not optimal. What I usually do is after a week of silence if I feel that I addressed the concerns, or there is no known way to improve the patch, I send one last ping explicitly stating that I will apply the patch soon. (whithin 1-2 days). And if the silence remains, I apply it. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
On Mon, Mar 28, 2016 at 12:05 PM, Marton Balint wrote: > > On Mon, 28 Mar 2016, Hendrik Leppkes wrote: > >> People that don't speak up at all may approve silently (or at least >> not disapprove), someone that raised issues should give an explicit >> OK/Nevermind/whatever, agreeing with you or withdrawing his >> complaints, there is no "silent" option there. > > > This seems unreasonable, beacuse this way a silent person can block a patch > forever, which is not optimal. > > What I usually do is after a week of silence if I feel that I addressed the > concerns, or there is no known way to improve the patch, I send one last > ping explicitly stating that I will apply the patch soon. (whithin 1-2 > days). And if the silence remains, I apply it. > If you send a mail explicitly stating that and the intention to move forward if no further feedback arrives, then its usually fine. Didn't happen here though. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
On Mon, Mar 28, 2016 at 02:18:32 +0200, Michael Niedermayer wrote: > +it is malice its rarely good to start with that as initial assumption. ^ , it's > +The goal of Software development is to create technical excellence, not for > any ^ s Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
This is consistent with other AVSubtitle timing adjustments.
---
libavcodec/utils.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..2c8fc9c 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
AVSubtitle *sub,
#if FF_API_ASS_TIMING
if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
-&& *got_sub_ptr && sub->num_rects)
-ret = convert_sub_to_old_ass_form(sub, avpkt,
avctx->time_base);
+&& *got_sub_ptr && sub->num_rects) {
+if (!avctx->pkt_timebase.num) {
+av_log(avctx, AV_LOG_ERROR, "packet time base not set\n");
+return AVERROR_BUG;
+}
+ret = convert_sub_to_old_ass_form(sub, avpkt,
avctx->pkt_timebase);
+}
#endif
if (sub->num_rects && !sub->end_display_time && avpkt->duration &&
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
before calling the decode callback. This prevents from rescaling again
into the decoder, and avoid the use of avctx->time_base which will
disappear in the incoming codecpar merge.
This commit also replaces the use of "20 centisecond" (ass time base)
with "200 ms".
---
libavcodec/ccaption_dec.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index d3f32dd..dfc17a1 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -30,7 +30,7 @@
#define UNSET_FLAG(var, val) ( (var) &= ~( 1 << (val)) )
#define CHECK_FLAG(var, val) ( (var) &( 1 << (val)) )
-static const AVRational ass_tb = {1, 100};
+static const AVRational ms_tb = {1, 1000};
/*
* TODO list
@@ -747,7 +747,7 @@ static int decode(AVCodecContext *avctx, void *data, int
*got_sub, AVPacket *avp
if(cc_type == 1)
continue;
else
-process_cc608(ctx, avpkt->pts, *(bptr + i + 1) & 0x7f, *(bptr + i
+ 2) & 0x7f);
+process_cc608(ctx, sub->pts, *(bptr + i + 1) & 0x7f, *(bptr + i +
2) & 0x7f);
if (!ctx->buffer_changed)
continue;
@@ -759,21 +759,21 @@ static int decode(AVCodecContext *avctx, void *data, int
*got_sub, AVPacket *avp
ret = ff_ass_add_rect(sub, ctx->buffer.str, ctx->readorder++, 0,
NULL, NULL);
if (ret < 0)
return ret;
-sub->pts = av_rescale_q(ctx->start_time, avctx->time_base,
AV_TIME_BASE_Q);
+sub->pts = ctx->start_time;
if (!ctx->real_time)
sub->end_display_time = av_rescale_q(ctx->end_time -
ctx->start_time,
- avctx->time_base,
av_make_q(1, 1000));
+ AV_TIME_BASE_Q, ms_tb);
else
sub->end_display_time = -1;
ctx->buffer_changed = 0;
-ctx->last_real_time = avpkt->pts;
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
}
}
if (ctx->real_time && ctx->screen_touched &&
-avpkt->pts > ctx->last_real_time + av_rescale_q(20, ass_tb,
avctx->time_base)) {
-ctx->last_real_time = avpkt->pts;
+sub->pts > ctx->last_real_time + av_rescale_q(200, ms_tb,
AV_TIME_BASE_Q)) {
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
capture_screen(ctx);
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
On Mon, 28 Mar 2016 at 11:58 Moritz Barsnick wrote: > On Mon, Mar 28, 2016 at 02:18:32 +0200, Michael Niedermayer wrote: > > +it is malice its rarely good to start with that as initial assumption. >^ >, it's > > > +The goal of Software development is to create technical excellence, not > for any >^ s > > Let's compare this to the VLC code of conduct: https://wiki.videolan.org/Code_of_Conduct/ Note how it has a list of specific violations, instead of vague things like "Be excellent" that the FFmpeg one has. Note how it has a huge section on disciplinary procedures. Note that this CoC should according to FFmpeg "rules" go through a vote, again more "rules" that aren't enforced. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
On Mon, Mar 28, 2016 at 12:34:05PM +, Kieran Kunhya wrote: > On Mon, 28 Mar 2016 at 11:58 Moritz Barsnick wrote: > > > On Mon, Mar 28, 2016 at 02:18:32 +0200, Michael Niedermayer wrote: > > > +it is malice its rarely good to start with that as initial assumption. > >^ > >, it's > > > > > +The goal of Software development is to create technical excellence, not > > for any > >^ s > > > > > Let's compare this to the VLC code of conduct: > https://wiki.videolan.org/Code_of_Conduct/ > > Note how it has a list of specific violations, instead of vague things like > "Be excellent" that the FFmpeg one has. > Note how it has a huge section on disciplinary procedures. i dont mind at all to be more specific, do people want a more specific list similar to vlc ? I thought it wasnt neccessary to write it as a strict "law" as if theres a nation of criminals that needs precissely worded laws. But rather a nation of good meaning people who all want to work together. the "Be excellent" text is identical to the linux kernel code of conflict. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodeOfConflict > Note that this CoC should according to FFmpeg "rules" go through a vote, If there is no unanimous agreement then we should vote, yes. If there is unanimous agreement and noone asks for a vote then iam not sure, it might be better to vote anyway so everyone has a chance to equally state if they approve or disapprove [] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
On Mon, 28 Mar 2016 12:05:10 +0200 (CEST) Marton Balint wrote: > On Mon, 28 Mar 2016, Hendrik Leppkes wrote: > > > People that don't speak up at all may approve silently (or at least > > not disapprove), someone that raised issues should give an explicit > > OK/Nevermind/whatever, agreeing with you or withdrawing his > > complaints, there is no "silent" option there. > > This seems unreasonable, beacuse this way a silent person can block a > patch forever, which is not optimal. > > What I usually do is after a week of silence if I feel that I addressed > the concerns, or there is no known way to improve the patch, I send > one last ping explicitly stating that I will apply the patch soon. > (whithin 1-2 days). And if the silence remains, I apply it. > In any case I agree that my behavior wasn't ideal. I was thinking more along the lines that I didn't really care, but someone really should have cared. I didn't want this issue to be overlooked at least. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
On Mon, Mar 28, 2016 at 02:10:51PM +0200, Clément Bœsch wrote: > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q > before calling the decode callback. This prevents from rescaling again > into the decoder, and avoid the use of avctx->time_base which will > disappear in the incoming codecpar merge. > > This commit also replaces the use of "20 centisecond" (ass time base) > with "200 ms". > --- > libavcodec/ccaption_dec.c | 14 +++--- > 1 file changed, 7 insertions(+), 7 deletions(-) with ./ffmpeg -f lavfi -i "movie=Starship_Troopers.vob[out0+subcc]" -vn -map s out.srt this causes a moderate change in the timings is that intended ? 6 -00:00:39,273 --> 00:00:41,783 +00:00:36,270 --> 00:00:41,776 AH. ASSISTANT INSTRUCTOR. 7 -00:00:41,775 --> 00:00:44,775 +00:00:36,270 --> 00:00:44,779 SHOULD I CALL YOU "SIR" ? 8 -00:00:44,778 --> 00:00:47,278 +00:00:36,270 --> 00:00:47,281 ONLY WHEN I GIVE YOU AN ORDER. 9 -00:00:47,281 --> 00:00:49,281 +00:00:36,270 --> 00:00:49,283 PREPARE FOR DEPARTURE. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No human being will ever know the Truth, for even if they happen to say it by chance, they would not even known they had done so. -- Xenophanes signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
On Mon, Mar 28, 2016 at 04:57:51PM +0200, Michael Niedermayer wrote:
> On Mon, Mar 28, 2016 at 02:10:51PM +0200, Clément Bœsch wrote:
> > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
> > before calling the decode callback. This prevents from rescaling again
> > into the decoder, and avoid the use of avctx->time_base which will
> > disappear in the incoming codecpar merge.
> >
> > This commit also replaces the use of "20 centisecond" (ass time base)
> > with "200 ms".
> > ---
> > libavcodec/ccaption_dec.c | 14 +++---
> > 1 file changed, 7 insertions(+), 7 deletions(-)
>
> with
> ./ffmpeg -f lavfi -i "movie=Starship_Troopers.vob[out0+subcc]" -vn -map s
> out.srt
>
> this causes a moderate change in the timings
> is that intended ?
>
Nope, that was a bug, thanks for noticing. It appears FATE isn't enough...
New patch attached.
[...]
--
Clément B.
From 1c79debbb09c0ed8f1d771cc4224248351f4cea2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Mon, 28 Mar 2016 14:10:08 +0200
Subject: [PATCH 1/2] lavc/ccaption_dec: remove usage of avctx->time_base
lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q
before calling the decode callback. This prevents from rescaling again
into the decoder, and avoid the use of avctx->time_base which will
disappear in the incoming codecpar merge.
This commit also replaces the use of "20 centisecond" (ass time base)
with "200 ms".
---
libavcodec/ccaption_dec.c | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index d3f32dd..3b15149 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -30,7 +30,7 @@
#define UNSET_FLAG(var, val) ( (var) &= ~( 1 << (val)) )
#define CHECK_FLAG(var, val) ( (var) &( 1 << (val)) )
-static const AVRational ass_tb = {1, 100};
+static const AVRational ms_tb = {1, 1000};
/*
* TODO list
@@ -723,6 +723,7 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
{
CCaptionSubContext *ctx = avctx->priv_data;
AVSubtitle *sub = data;
+const int64_t start_time = sub->pts;
uint8_t *bptr = NULL;
int len = avpkt->size;
int ret = 0;
@@ -747,7 +748,7 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
if(cc_type == 1)
continue;
else
-process_cc608(ctx, avpkt->pts, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 0x7f);
+process_cc608(ctx, start_time, *(bptr + i + 1) & 0x7f, *(bptr + i + 2) & 0x7f);
if (!ctx->buffer_changed)
continue;
@@ -759,21 +760,21 @@ static int decode(AVCodecContext *avctx, void *data, int *got_sub, AVPacket *avp
ret = ff_ass_add_rect(sub, ctx->buffer.str, ctx->readorder++, 0, NULL, NULL);
if (ret < 0)
return ret;
-sub->pts = av_rescale_q(ctx->start_time, avctx->time_base, AV_TIME_BASE_Q);
+sub->pts = ctx->start_time;
if (!ctx->real_time)
sub->end_display_time = av_rescale_q(ctx->end_time - ctx->start_time,
- avctx->time_base, av_make_q(1, 1000));
+ AV_TIME_BASE_Q, ms_tb);
else
sub->end_display_time = -1;
ctx->buffer_changed = 0;
-ctx->last_real_time = avpkt->pts;
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
}
}
if (ctx->real_time && ctx->screen_touched &&
-avpkt->pts > ctx->last_real_time + av_rescale_q(20, ass_tb, avctx->time_base)) {
-ctx->last_real_time = avpkt->pts;
+sub->pts > ctx->last_real_time + av_rescale_q(200, ms_tb, AV_TIME_BASE_Q)) {
+ctx->last_real_time = sub->pts;
ctx->screen_touched = 0;
capture_screen(ctx);
--
2.7.4
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/ccaption_dec: remove usage of avctx->time_base
On Mon, Mar 28, 2016 at 06:09:03PM +0200, Clément Bœsch wrote: > On Mon, Mar 28, 2016 at 04:57:51PM +0200, Michael Niedermayer wrote: > > On Mon, Mar 28, 2016 at 02:10:51PM +0200, Clément Bœsch wrote: > > > lavc/utils already rescales avpkt->pts to sub->pts in AV_TIME_BASE_Q > > > before calling the decode callback. This prevents from rescaling again > > > into the decoder, and avoid the use of avctx->time_base which will > > > disappear in the incoming codecpar merge. > > > > > > This commit also replaces the use of "20 centisecond" (ass time base) > > > with "200 ms". > > > --- > > > libavcodec/ccaption_dec.c | 14 +++--- > > > 1 file changed, 7 insertions(+), 7 deletions(-) > > > > with > > ./ffmpeg -f lavfi -i "movie=Starship_Troopers.vob[out0+subcc]" -vn -map s > > out.srt > > > > this causes a moderate change in the timings > > is that intended ? > > > > Nope, that was a bug, thanks for noticing. It appears FATE isn't enough... yes, a fate test should be added for this, the file used here is a bit big though, maybe someone can come up with a smaller testcase ... > New patch attached. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If a bugfix only changes things apparently unrelated to the bug with no further explanation, that is a good sign that the bugfix is wrong. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
On Mon, Mar 28, 2016 at 02:15:50PM +0200, Clément Bœsch wrote:
> This is consistent with other AVSubtitle timing adjustments.
> ---
> libavcodec/utils.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index c625bbc..2c8fc9c 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
> AVSubtitle *sub,
>
> #if FF_API_ASS_TIMING
> if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
> -&& *got_sub_ptr && sub->num_rects)
> -ret = convert_sub_to_old_ass_form(sub, avpkt,
> avctx->time_base);
> +&& *got_sub_ptr && sub->num_rects) {
> +if (!avctx->pkt_timebase.num) {
> +av_log(avctx, AV_LOG_ERROR, "packet time base not
> set\n");
> +return AVERROR_BUG;
> +}
> +ret = convert_sub_to_old_ass_form(sub, avpkt,
> avctx->pkt_timebase);
> +}
> #endif
this change does make sense
do all apps that get into this code set avctx->pkt_timebase so that
this works though or is it otherwise guranteed to be set ?
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
On Mon, 28 Mar 2016 18:44:33 +0200
Michael Niedermayer wrote:
> On Mon, Mar 28, 2016 at 02:15:50PM +0200, Clément Bœsch wrote:
> > This is consistent with other AVSubtitle timing adjustments.
> > ---
> > libavcodec/utils.c | 9 +++--
> > 1 file changed, 7 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index c625bbc..2c8fc9c 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx,
> > AVSubtitle *sub,
> >
> > #if FF_API_ASS_TIMING
> > if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
> > -&& *got_sub_ptr && sub->num_rects)
> > -ret = convert_sub_to_old_ass_form(sub, avpkt,
> > avctx->time_base);
> > +&& *got_sub_ptr && sub->num_rects) {
> > +if (!avctx->pkt_timebase.num) {
> > +av_log(avctx, AV_LOG_ERROR, "packet time base not
> > set\n");
> > +return AVERROR_BUG;
> > +}
> > +ret = convert_sub_to_old_ass_form(sub, avpkt,
> > avctx->pkt_timebase);
> > +}
> > #endif
>
> this change does make sense
>
> do all apps that get into this code set avctx->pkt_timebase so that
> this works though or is it otherwise guranteed to be set ?
>
> [...]
No they don't. It's an API change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc
---
libavcodec/mediacodecdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 5c1368f..c21ceba 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -247,7 +247,7 @@ static int mediacodec_dec_parse_format(AVCodecContext
*avctx, MediaCodecDecConte
av_freep(&format);
return AVERROR_EXTERNAL;
}
-s->stride = value >= 0 ? value : s->width;
+s->stride = value > 0 ? value : s->width;
if (!ff_AMediaFormat_getInt32(s->format, "slice-height", &value)) {
format = ff_AMediaFormat_toString(s->format);
--
2.6.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for
---
libavcodec/mediacodecdec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
index 5c1368f..c21ceba 100644
--- a/libavcodec/mediacodecdec.c
+++ b/libavcodec/mediacodecdec.c
@@ -247,7 +247,7 @@ static int mediacodec_dec_parse_format(AVCodecContext
*avctx, MediaCodecDecConte
av_freep(&format);
return AVERROR_EXTERNAL;
}
-s->stride = value >= 0 ? value : s->width;
+s->stride = value > 0 ? value : s->width;
if (!ff_AMediaFormat_getInt32(s->format, "slice-height", &value)) {
format = ff_AMediaFormat_toString(s->format);
--
2.6.1.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] swscale cleanup
Hi,
This patch removes the previous swscale code which where under the '#ifndef
NEW_FILTER'.
It also remove a few unused fields of SwsContext.
Seems it doesn't introduce any regression (passes all FATE tests) but it
would be better if someone could test it more.
From d52cb0e25332a0327acdac89256beac4701f675a Mon Sep 17 00:00:00 2001
From: Pedro Arthur
Date: Mon, 28 Mar 2016 13:25:18 -0300
Subject: [PATCH] swscale: cleanup unused code
Removed previous swscale code under '#ifndef NEW_FILTER'
and removed unused fields of SwsContext
---
libswscale/input.c| 2 +-
libswscale/output.c | 40 ++---
libswscale/ppc/swscale_altivec.c | 4 +-
libswscale/slice.c| 4 +-
libswscale/swscale.c | 336 +++---
libswscale/swscale_internal.h | 10 +-
libswscale/utils.c| 78 +
libswscale/vscale.c | 4 +-
libswscale/x86/swscale.c | 38 +
libswscale/x86/swscale_template.c | 12 +-
10 files changed, 65 insertions(+), 463 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 16314b6..eed0f49 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1482,7 +1482,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
c->lumToYV12 = p010BEToY_c;
break;
}
-if (c->alpPixBuf) {
+if (c->needAlpha) {
if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
if (HAVE_BIGENDIAN == !isBE(srcFormat))
c->alpToYV12 = bswap16Y_c;
diff --git a/libswscale/output.c b/libswscale/output.c
index 0c763c3..e9bbb3d 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1513,8 +1513,8 @@ static void name ## ext ## _1_c(SwsContext *c, const int16_t *buf0, \
}
#if CONFIG_SMALL
-YUV2RGBWRAPPER(yuv2rgb,, 32_1, AV_PIX_FMT_RGB32_1, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2rgb,, 32,AV_PIX_FMT_RGB32, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
+YUV2RGBWRAPPER(yuv2rgb,, 32_1, AV_PIX_FMT_RGB32_1, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2rgb,, 32,AV_PIX_FMT_RGB32, CONFIG_SWSCALE_ALPHA && c->needAlpha)
#else
#if CONFIG_SWSCALE_ALPHA
YUV2RGBWRAPPER(yuv2rgb,, a32_1, AV_PIX_FMT_RGB32_1, 1)
@@ -1823,10 +1823,10 @@ yuv2rgb_full_1_c_template(SwsContext *c, const int16_t *buf0,
}
#if CONFIG_SMALL
-YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, abgr32_full, AV_PIX_FMT_ABGR, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, rgba32_full, AV_PIX_FMT_RGBA, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, argb32_full, AV_PIX_FMT_ARGB, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
+YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, abgr32_full, AV_PIX_FMT_ABGR, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, rgba32_full, AV_PIX_FMT_RGBA, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, argb32_full, AV_PIX_FMT_ARGB, CONFIG_SWSCALE_ALPHA && c->needAlpha)
#else
#if CONFIG_SWSCALE_ALPHA
YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, 1)
@@ -2119,7 +2119,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed1 = yuv2rgba32_full_1_c;
#else
#if CONFIG_SWSCALE_ALPHA
-if (c->alpPixBuf) {
+if (c->needAlpha) {
*yuv2packedX = yuv2rgba32_full_X_c;
*yuv2packed2 = yuv2rgba32_full_2_c;
*yuv2packed1 = yuv2rgba32_full_1_c;
@@ -2139,7 +2139,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed1 = yuv2argb32_full_1_c;
#else
#if CONFIG_SWSCALE_ALPHA
-if (c->alpPixBuf) {
+if (c->needAlpha) {
*yuv2packedX = yuv2argb32_full_X_c;
*yuv2packed2 = yuv2argb32_full_2_c;
*yuv2packed1 = yuv2argb32_full_1_c;
@@ -2159,7 +2159,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed1 = yuv2bgra32_full_1_c;
#else
#if CONFIG_SWSCALE_ALPHA
-if (c->alpPixBuf) {
+if (c->needAlpha) {
*yuv2packedX = yuv2bgra32_full_X_c;
*yuv2packed2 = yuv2bgra32_full_2_c;
*yuv2packed1 = yuv2bgra32_full_1_c;
@@ -2179,7 +2179,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed1 = yuv2abgr32_full_1_c;
#else
#if CONFIG_SWSCALE_ALPHA
-if (c->alpPixBuf) {
+if (c->needAlpha) {
*yuv2packedX = yuv2abgr32_full_X_c;
*yuv2packed2 = yuv2abgr32_full_2_c;
*yuv2packed1 = yuv2abgr32_full_1_c;
@@ -2194,7 +2194,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
Re: [FFmpeg-devel] [PATCH] lavc/utils: use pkt_timebase for legacy subtitles timing code
On Mon, Mar 28, 2016 at 06:52:26PM +0200, wm4 wrote:
> On Mon, 28 Mar 2016 18:44:33 +0200
> Michael Niedermayer wrote:
>
> > On Mon, Mar 28, 2016 at 02:15:50PM +0200, Clément Bœsch wrote:
> > > This is consistent with other AVSubtitle timing adjustments.
> > > ---
> > > libavcodec/utils.c | 9 +++--
> > > 1 file changed, 7 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > index c625bbc..2c8fc9c 100644
> > > --- a/libavcodec/utils.c
> > > +++ b/libavcodec/utils.c
> > > @@ -2582,8 +2582,13 @@ int avcodec_decode_subtitle2(AVCodecContext
> > > *avctx, AVSubtitle *sub,
> > >
> > > #if FF_API_ASS_TIMING
> > > if (avctx->sub_text_format ==
> > > FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
> > > -&& *got_sub_ptr && sub->num_rects)
> > > -ret = convert_sub_to_old_ass_form(sub, avpkt,
> > > avctx->time_base);
> > > +&& *got_sub_ptr && sub->num_rects) {
> > > +if (!avctx->pkt_timebase.num) {
> > > +av_log(avctx, AV_LOG_ERROR, "packet time base not
> > > set\n");
> > > +return AVERROR_BUG;
> > > +}
> > > +ret = convert_sub_to_old_ass_form(sub, avpkt,
> > > avctx->pkt_timebase);
> > > +}
> > > #endif
> >
> > this change does make sense
> >
> > do all apps that get into this code set avctx->pkt_timebase so that
> > this works though or is it otherwise guranteed to be set ?
> >
> > [...]
>
> No they don't. It's an API change.
New patch attached.
--
Clément B.
From a885683c02fce7037e882e52216afa8a96aaf1e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Cl=C3=A9ment=20B=C5=93sch?=
Date: Mon, 28 Mar 2016 14:15:42 +0200
Subject: [PATCH 2/2] lavc/utils: use pkt_timebase for legacy subtitles timing
code
This is consistent with other AVSubtitle timing adjustments.
---
libavcodec/utils.c | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..793f589 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2582,8 +2582,11 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, AVSubtitle *sub,
#if FF_API_ASS_TIMING
if (avctx->sub_text_format == FF_SUB_TEXT_FMT_ASS_WITH_TIMINGS
-&& *got_sub_ptr && sub->num_rects)
-ret = convert_sub_to_old_ass_form(sub, avpkt, avctx->time_base);
+&& *got_sub_ptr && sub->num_rects) {
+const AVRational tb = avctx->pkt_timebase.num ? avctx->pkt_timebase
+ : avctx->time_base;
+ret = convert_sub_to_old_ass_form(sub, avpkt, tb);
+}
#endif
if (sub->num_rects && !sub->end_display_time && avpkt->duration &&
--
2.7.4
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec
Fix problems with multithread runs. -- Stanislav Dolganov 0001-simple-P-frame-support.patch Description: Binary data 0002-more-tests-and-residual-formula.patch Description: Binary data 0003-thread-bug-semi-fix.patch Description: Binary data 0004-ffv1-threads-bug-fix.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4videodec: Print low_delay value with -debug 1 in decode_vol_header()
Signed-off-by: Michael Niedermayer
---
libavcodec/mpeg4videodec.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index a74cdbd..1fef372 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -2060,11 +2060,12 @@ no_cplx_est:
}
if (s->avctx->debug&FF_DEBUG_PICT_INFO) {
-av_log(s->avctx, AV_LOG_DEBUG, "tb %d/%d, tincrbits:%d, qp_prec:%d,
ps:%d, %s%s%s%s\n",
+av_log(s->avctx, AV_LOG_DEBUG, "tb %d/%d, tincrbits:%d, qp_prec:%d,
ps:%d, low_delay:%d %s%s%s%s\n",
s->avctx->framerate.den, s->avctx->framerate.num,
ctx->time_increment_bits,
s->quant_precision,
s->progressive_sequence,
+ s->low_delay,
ctx->scalability ? "scalability " :"" , s->quarter_sample ?
"qpel " : "",
s->data_partitioning ? "partition " : "", ctx->rvlc ? "rvlc " :
""
);
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4videodec: Fix default low_delay flag value if not coded
Signed-off-by: Michael Niedermayer
---
libavcodec/mpeg4videodec.c | 12 ++-
tests/ref/fate/iv8-demux | 48 ++--
tests/ref/fate/nc-demux| 182 ++--
3 files changed, 125 insertions(+), 117 deletions(-)
diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index 527cbe9..a74cdbd 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -1754,8 +1754,16 @@ static int decode_vol_header(Mpeg4DecContext *ctx,
GetBitContext *gb)
} else {
/* is setting low delay flag only once the smartest thing to do?
* low delay detection won't be overridden. */
-if (s->picture_number == 0)
-s->low_delay = 0;
+if (s->picture_number == 0) {
+switch(s->vo_type) {
+case SIMPLE_VO_TYPE:
+case ADV_SIMPLE_VO_TYPE:
+s->low_delay = 1;
+break;
+default:
+s->low_delay = 0;
+}
+}
}
ctx->shape = get_bits(gb, 2); /* vol shape */
diff --git a/tests/ref/fate/iv8-demux b/tests/ref/fate/iv8-demux
index 02b6314..fe9f3b3 100644
--- a/tests/ref/fate/iv8-demux
+++ b/tests/ref/fate/iv8-demux
@@ -1,27 +1,27 @@
#extradata 0: 19, 0x1f2604b9
#tb 0: 1/9
0, 0, 0,0,20883, 0x347191e2
-0, 0, 3600,0,20882, 0xe1573905
-0, 3600, 7200,0,20894, 0xd54f516a
-0, 7200, 10800,0,20891, 0x1b5c5039
-0, 10800, 14400,0,20883, 0x8e785b4d
-0, 14400, 18000,0,20870, 0xd26ca1f6
-0, 18000, 21600,0,21448, 0x946f5b2b
-0, 21600, 25200,0,21433, 0xb18687c5
-0, 25200, 28800,0,20865, 0xc0eb3fce
-0, 28800, 32399,0,20842, 0x9d0728ba
-0, 32399, 35999,0,20878, 0xf60f5dee
-0, 35999, 39600,0,20866, 0x3bde568f
-0, 39600, 43200,0,20884, 0x22736993
-0, 43200, 46800,0,20860, 0xf56f2fca
-0, 46800, 50400,0,20872, 0xf39e3cb3
-0, 50400, 53999,0,20835, 0xa3c4363b
-0, 53999, 57600,0,20905, 0x552853d1
-0, 57600, 61200,0,20874, 0xed0b91ec
-0, 61200, 64799,0,20877, 0xe1623e01
-0, 64799, 68399,0,20933, 0x19906564
-0, 68399, 72000,0,20891, 0x3d064fd3
-0, 72000, 75600,0,20834, 0xcb774dbc
-0, 75600, 79200,0,20870, 0xbc536589
-0, 79200, 82800,0,21421, 0xc99a68e4
-0, 82800, 86400,0,12869, 0x5684e304
+0, 3600, 3600,0,20882, 0xe1573905
+0, 7200, 7200,0,20894, 0xd54f516a
+0, 10800, 10800,0,20891, 0x1b5c5039
+0, 14400, 14400,0,20883, 0x8e785b4d
+0, 18000, 18000,0,20870, 0xd26ca1f6
+0, 21600, 21600,0,21448, 0x946f5b2b
+0, 25200, 25200,0,21433, 0xb18687c5
+0, 28800, 28800,0,20865, 0xc0eb3fce
+0, 32399, 32399,0,20842, 0x9d0728ba
+0, 35999, 35999,0,20878, 0xf60f5dee
+0, 39600, 39600,0,20866, 0x3bde568f
+0, 43200, 43200,0,20884, 0x22736993
+0, 46800, 46800,0,20860, 0xf56f2fca
+0, 50400, 50400,0,20872, 0xf39e3cb3
+0, 53999, 53999,0,20835, 0xa3c4363b
+0, 57600, 57600,0,20905, 0x552853d1
+0, 61200, 61200,0,20874, 0xed0b91ec
+0, 64799, 64799,0,20877, 0xe1623e01
+0, 68399, 68399,0,20933, 0x19906564
+0, 72000, 72000,0,20891, 0x3d064fd3
+0, 75600, 75600,0,20834, 0xcb774dbc
+0, 79200, 79200,0,20870, 0xbc536589
+0, 82800, 82800,0,21421, 0xc99a68e4
+0, 86400, 86400,0,12869, 0x5684e304
diff --git a/tests/ref/fate/nc-demux b/tests/ref/fate/nc-demux
index 98318ac..e5ff05d 100644
--- a/tests/ref/fate/nc-demux
+++ b/tests/ref/fate/nc-demux
@@ -1,93 +1,93 @@
#extradata 0: 19, 0x1afd0446
#tb 0: 1/100
-0, 0, -9223372036854775808,1,19787, 0x75e463f3
-0, 1, -9223372036854775808,1,11913, 0x0f429c34, F=0x0
-0, 2, -9223372036854775808,1,14225, 0xbd3c704c, F=0x0
-0, 3, -9223372036854775808,1,10357, 0xbf232393, F=0x0
-0, 4, -9223372036854775808,1, 9595, 0xf565d39e, F=0x0
-0, 5, -9223372036854775808,1, 9262, 0x2afd6ce0, F=0x0
-0, 6, -9223372036854775808,1,12214, 0x6ae81d9b, F=0x0
-0, 7, -9223372036854775808,1,1392
Re: [FFmpeg-devel] [PATCH] swscale cleanup
On Mon, Mar 28, 2016 at 01:56:08PM -0300, Pedro Arthur wrote: > Hi, > > This patch removes the previous swscale code which where under the '#ifndef > NEW_FILTER'. > It also remove a few unused fields of SwsContext. > Seems it doesn't introduce any regression (passes all FATE tests) but it > would be better if someone could test it more. > input.c|2 > output.c | 40 ++--- > ppc/swscale_altivec.c |4 > slice.c|4 > swscale.c | 336 > +++-- > swscale_internal.h | 10 - > utils.c| 78 --- > vscale.c |4 > x86/swscale.c | 38 + > x86/swscale_template.c | 12 - > 10 files changed, 65 insertions(+), 463 deletions(-) > fbdf78f3edb890f485d5bcfc2b3edf55465db1f5 sws_cleanup.patch > From d52cb0e25332a0327acdac89256beac4701f675a Mon Sep 17 00:00:00 2001 > From: Pedro Arthur > Date: Mon, 28 Mar 2016 13:25:18 -0300 > Subject: [PATCH] swscale: cleanup unused code > > Removed previous swscale code under '#ifndef NEW_FILTER' > and removed unused fields of SwsContext fails to build on x86-32 here libswscale/x86/swscale.c: In function ‘ff_sws_init_swscale_x86’: libswscale/x86/swscale.c:460:18: error: ‘SwsContext’ has no member named ‘needApha’ [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The worst form of inequality is to try to make unequal things equal. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part
On Sun, Mar 27, 2016 at 5:58 PM, Matthieu Bouron wrote: > > > On Fri, Mar 25, 2016 at 11:45 PM, Matthieu Bouron < > matthieu.bou...@gmail.com> wrote: > >> The following patchset aims to make bitexact the yuv->rgba armv7 neon >> code path >> with the aarch64 one. It also aims to make the two code bases as close as >> possible. >> >> [PATCH 01/10] swscale/arm/yuv2rgb: remove 32bit code path >> >> The current 32bit code path which is unused is removed. >> >> [PATCH 06/10] swscale/arm/yuv2rgb: only process one line at a time >> >> The code process only one line at a time for the yuv420p,nv12 and nv21 >> formats >> with no regression in performance observed on a rpi2 (I've even observed a >> slight increase of performance for the nv12 and nv21 formats). >> >> [PATCH 10/10] swscale/arm/yuv2rgb: make the code bitexact with its >> >> The last patch of the serie makes the code bitexact with the aarch64 >> version. >> The increase of precision (which introduces a performance loss) is >> compensated >> by a refactor/optimisation that saves quite a few mov,vdup and vqdmulh. >> >> ./ffmpeg_g -nostats -f lavfi -i >> testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f >> null - >> >> without patchset : >> [bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399 min:0.020605 >> >> with patchset: >> [bench @ 0xe5f6a0] t:0.018924 avg:0.019075 max:0.037472 min:0.01884 > > > I've managed tu run the code on a beagle bone black board, here are the > results: > > nv12->bgra > without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743 max:0.032600 > min:0.011513 > with patches 01-06/10 applied: [bench @ 0x8052d0] t:0.013438 avg:0.013659 > max:0.034427 min:0.013411 > with patches 01-10/10 applied: [bench @ 0x1fbb2d0] t:0.012554 avg:0.012751 > max:0.034288 min:0.012523 > > yuv420p->bgra > without patchset: [bench @ 0x6d42d0] t:0.012954 avg:0.013159 max:0.033866 > min:0.012945 > with patches 01-06/10 applied: [bench @ 0x20172d0] t:0.015154 avg:0.015358 > max:0.036186 min:0.015134 > with patches 01-10/10 applied: [bench @ 0x1d162d0] t:0.014623 avg:0.014784 > max:0.035487 min:0.014568 > > So it looks like processing one line at a time as negative effect on > performance on this board (as opposed to the rpi2). I'll try to keep the > two line processing code and post some result (so we can decide, which > version to choose). > I've managed to update the patchset to keep processing two line at a time for the nv12,nv21 and yuv420p formats, here are the results: ./ffmpeg_g -nostats -f lavfi -i testsrc2=1920x1080:d=5,format=nv12,bench=start,format=bgra,bench=stop -f null - Beagle bone black: without patchset: [bench @ 0x1fc02d0] t:0.011618 avg:0.011743 max:0.032600 min:0.011513 with patchset v1: [bench @ 0x1fbb2d0] t:0.012554 avg:0.012751 max:0.034288 min:0.012523 with patchset v2: [bench @ 0x10f92d0] t:0.011239 avg:0.011408 max:0.032124 min:0.011202 Nexus5: without patchset: avg: ~2,869ms with patchset v1: avg: ~3,008ms with patchset v2: avg: ~2,702ms RPI2: without patchset: [bench @ 0x3eb6a0] t:0.020660 avg:0.020813 max:0.039399 min:0.020605 with patchset v1: [bench @ 0xe5f6a0] t:0.018924 avg:0.019075 max:0.037472 min:0.01884 with patchset v2: [bench @ 0xc1b6a0] t:0.020999 avg:0.021203 max:0.052184 min:0.020768 Given the following the results, i will drop the current patchset and submit another one (which keeps processing two lines at a time). Matthieu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 9/9] swscale/arm/yuv2rgb: make the code bitexact with its aarch64 counter part
---
libswscale/arm/swscale_unscaled.c | 18 +-
libswscale/arm/yuv2rgb_neon.S | 40 +--
2 files changed, 31 insertions(+), 27 deletions(-)
diff --git a/libswscale/arm/swscale_unscaled.c
b/libswscale/arm/swscale_unscaled.c
index 149208c..e1597ab 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -62,10 +62,10 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
*context, const uint8_t *src[
}
#define YUV_TO_RGB_TABLE
\
-c->yuv2rgb_v2r_coeff / (1 << 7),
\
-c->yuv2rgb_u2g_coeff / (1 << 7),
\
-c->yuv2rgb_v2g_coeff / (1 << 7),
\
-c->yuv2rgb_u2b_coeff / (1 << 7),
\
+c->yuv2rgb_v2r_coeff,
\
+c->yuv2rgb_u2g_coeff,
\
+c->yuv2rgb_v2g_coeff,
\
+c->yuv2rgb_u2b_coeff,
\
#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)
\
int ff_##ifmt##_to_##ofmt##_neon(int w, int h,
\
@@ -88,8 +88,8 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c,
const uint8_t *src[],
src[1], srcStride[1],
\
src[2], srcStride[2],
\
yuv2rgb_table,
\
- c->yuv2rgb_y_offset >> 9,
\
- c->yuv2rgb_y_coeff / (1 << 7));
\
+ c->yuv2rgb_y_offset >> 6,
\
+ c->yuv2rgb_y_coeff);
\
\
return 0;
\
}
\
@@ -117,12 +117,12 @@ static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c,
const uint8_t *src[],
uint8_t *dst[], int dstStride[]) {
\
const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE };
\
\
-ff_##ifmt##_to_##ofmt##_neon(c->srcW, srcSliceH,
\
+ff_##ifmt##_to_##ofmt##_neon(c->srcW, srcSliceH,
\
dst[0] + srcSliceY * dstStride[0],
dstStride[0], \
src[0], srcStride[0], src[1], srcStride[1],
\
yuv2rgb_table,
\
- c->yuv2rgb_y_offset >> 9,
\
- c->yuv2rgb_y_coeff / (1 << 7));
\
+ c->yuv2rgb_y_offset >> 6,
\
+ c->yuv2rgb_y_coeff);
\
\
return 0;
\
}
\
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index 6b911c8..741928d 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -23,17 +23,20 @@
.macro compute_premult
-vmul.s16q8, q15, d1[0] @ q8 =
V * v2r
-vmul.s16q9, q14, d1[1] @ q9 =
U * u2g
-vmla.s16q9, q15, d1[2] @ q9 =
U * u2g + V * v2g
-vmul.s16q10,q14, d1[3] @ q10 =
U * u2b
+vsub.u16q14,q11@ q14 =
U * (1 << 3) - 128 * (1 << 3)
+vsub.u16q15,q11@ q15 =
V * (1 << 3) - 128 * (1 << 3)
+vqdmulh.s16 q8, q15, d1[0]
[FFmpeg-devel] [PATCH v2 8/9] swscale/arm/yuv2rgb: save a few instructions by processing the luma line interleaved
--- libswscale/arm/yuv2rgb_neon.S | 88 +-- 1 file changed, 34 insertions(+), 54 deletions(-) diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S index 124d7d3..6b911c8 100644 --- a/libswscale/arm/yuv2rgb_neon.S +++ b/libswscale/arm/yuv2rgb_neon.S @@ -22,62 +22,35 @@ #include "libavutil/arm/asm.S" -.macro compute_premult half_u1, half_u2, half_v1, half_v2 -vmovd2, \half_u1 @ copy left q14 to left q1 -vmovd3, \half_u1 @ copy left q14 to right q1 -vmovd4, \half_u2 @ copy right q14 to left q2 -vmovd5, \half_u2 @ copy right q14 to right q2 - -vmovd6, \half_v1 @ copy left q15 to left q3 -vmovd7, \half_v1 @ copy left q15 to right q3 -vmovd8, \half_v2 @ copy right q15 to left q4 -vmovd9, \half_v2 @ copy right q15 to right q4 - -vzip.16 d2, d3 @ U1U1U2U2U3U3U4U4 -vzip.16 d4, d5 @ U5U5U6U6U7U7U8U8 - -vzip.16 d6, d7 @ V1V1V2V2V3V3V4V4 -vzip.16 d8, d9 @ V5V5V6V6V7V7V8V8 - -vmul.s16q8, q3, d1[0] @ V * v2r (left, red) -vmul.s16q9, q4, d1[0] @ V * v2r (right, red) -vmul.s16q10, q1, d1[1] @ U * u2g -vmul.s16q11, q2, d1[1] @ U * u2g -vmla.s16q10, q3, d1[2] @ U * u2g + V * v2g (left, green) -vmla.s16q11, q4, d1[2] @ U * u2g + V * v2g (right, green) -vmul.s16q12, q1, d1[3] @ U * u2b (left, blue) -vmul.s16q13, q2, d1[3] @ U * u2b (right, blue) +.macro compute_premult +vmul.s16q8, q15, d1[0] @ q8 = V * v2r +vmul.s16q9, q14, d1[1] @ q9 = U * u2g +vmla.s16q9, q15, d1[2] @ q9 = U * u2g + V * v2g +vmul.s16q10,q14, d1[3] @ q10 = U * u2b .endm -.macro compute_color dst_comp1 dst_comp2 pre1 pre2 -vadd.s16q1, q14, \pre1 -vadd.s16q2, q15, \pre2 +.macro compute_color dst_comp1 dst_comp2 pre +vadd.s16q1, q14, \pre +vadd.s16q2, q15, \pre vqrshrun.s16\dst_comp1, q1, #6 vqrshrun.s16\dst_comp2, q2, #6 .endm .macro compute_rgba r1 g1 b1 a1 r2 g2 b2 a2 -compute_color \r1, \r2, q8, q9 -compute_color \g1, \g2, q10, q11 -compute_color \b1, \b2, q12, q13 +compute_color \r1, \r2, q8 +compute_color \g1, \g2, q9 +compute_color \b1, \b2, q10 vmov.u8 \a1, #255 vmov.u8 \a2, #255 .endm -.macro compute dst y0 y1 ofmt -vmovl.u8q14, \y0 @ 8px of y -vmovl.u8q15, \y1 @ 8px of y - -vdup.16 q5, r9 @ q5 = y_offset -vmovd14, d0@ q7 = y_coeff -vmovd15, d0@ q7 = y_coeff - -vsub.s16q14, q5 -vsub.s16q15, q5 - -vmul.s16q14, q7@ q14 = (srcY - y_offset) * y_coeff (left) -vmul.s16q15, q7@ q15 = (srcY - y_offset) * y_coeff (right) - +.macro compute dst ofmt +vmovl.u8q14, d14 @ q14 = Y +vmovl.u8q15, d15 @ q15 = Y +vsub.s16q14, q12 @ q14 = (srcY - y_offset) +vsub.s16q15, q12 @ q15 = (srcY - y_offset) +vmul.s16q14, q13 @ q14 = (srcY - y_offset) * y_coeff (left) +vmul.s16q15, q13 @ q15 = (srcY - y_offset) * y_coeff (right) .ifc \ofmt,argb compute_rgba
Re: [FFmpeg-devel] [PATCH] swscale cleanup
It was a little typo, attached patch fixed.
2016-03-28 16:09 GMT-03:00 Michael Niedermayer :
> On Mon, Mar 28, 2016 at 01:56:08PM -0300, Pedro Arthur wrote:
> > Hi,
> >
> > This patch removes the previous swscale code which where under the
> '#ifndef
> > NEW_FILTER'.
> > It also remove a few unused fields of SwsContext.
> > Seems it doesn't introduce any regression (passes all FATE tests) but it
> > would be better if someone could test it more.
>
> > input.c|2
> > output.c | 40 ++---
> > ppc/swscale_altivec.c |4
> > slice.c|4
> > swscale.c | 336
> +++--
> > swscale_internal.h | 10 -
> > utils.c| 78 ---
> > vscale.c |4
> > x86/swscale.c | 38 +
> > x86/swscale_template.c | 12 -
> > 10 files changed, 65 insertions(+), 463 deletions(-)
> > fbdf78f3edb890f485d5bcfc2b3edf55465db1f5 sws_cleanup.patch
> > From d52cb0e25332a0327acdac89256beac4701f675a Mon Sep 17 00:00:00 2001
> > From: Pedro Arthur
> > Date: Mon, 28 Mar 2016 13:25:18 -0300
> > Subject: [PATCH] swscale: cleanup unused code
> >
> > Removed previous swscale code under '#ifndef NEW_FILTER'
> > and removed unused fields of SwsContext
>
> fails to build on x86-32 here
>
> libswscale/x86/swscale.c: In function ‘ff_sws_init_swscale_x86’:
> libswscale/x86/swscale.c:460:18: error: ‘SwsContext’ has no member named
> ‘needApha’
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The worst form of inequality is to try to make unequal things equal.
> -- Aristotle
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
From 93edb69e836bd1e1f7d0293a06cccee336ac8edc Mon Sep 17 00:00:00 2001
From: Pedro Arthur
Date: Mon, 28 Mar 2016 13:25:18 -0300
Subject: [PATCH] swscale: cleanup unused code
Removed previous swscale code under '#ifndef NEW_FILTER'
and removed unused fields of SwsContext
---
libswscale/input.c| 2 +-
libswscale/output.c | 40 ++---
libswscale/ppc/swscale_altivec.c | 4 +-
libswscale/slice.c| 4 +-
libswscale/swscale.c | 336 +++---
libswscale/swscale_internal.h | 10 +-
libswscale/utils.c| 78 +
libswscale/vscale.c | 4 +-
libswscale/x86/swscale.c | 38 +
libswscale/x86/swscale_template.c | 12 +-
10 files changed, 65 insertions(+), 463 deletions(-)
diff --git a/libswscale/input.c b/libswscale/input.c
index 16314b6..eed0f49 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1482,7 +1482,7 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
c->lumToYV12 = p010BEToY_c;
break;
}
-if (c->alpPixBuf) {
+if (c->needAlpha) {
if (is16BPS(srcFormat) || isNBPS(srcFormat)) {
if (HAVE_BIGENDIAN == !isBE(srcFormat))
c->alpToYV12 = bswap16Y_c;
diff --git a/libswscale/output.c b/libswscale/output.c
index 0c763c3..e9bbb3d 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -1513,8 +1513,8 @@ static void name ## ext ## _1_c(SwsContext *c, const int16_t *buf0, \
}
#if CONFIG_SMALL
-YUV2RGBWRAPPER(yuv2rgb,, 32_1, AV_PIX_FMT_RGB32_1, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2rgb,, 32,AV_PIX_FMT_RGB32, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
+YUV2RGBWRAPPER(yuv2rgb,, 32_1, AV_PIX_FMT_RGB32_1, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2rgb,, 32,AV_PIX_FMT_RGB32, CONFIG_SWSCALE_ALPHA && c->needAlpha)
#else
#if CONFIG_SWSCALE_ALPHA
YUV2RGBWRAPPER(yuv2rgb,, a32_1, AV_PIX_FMT_RGB32_1, 1)
@@ -1823,10 +1823,10 @@ yuv2rgb_full_1_c_template(SwsContext *c, const int16_t *buf0,
}
#if CONFIG_SMALL
-YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, abgr32_full, AV_PIX_FMT_ABGR, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, rgba32_full, AV_PIX_FMT_RGBA, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
-YUV2RGBWRAPPER(yuv2, rgb_full, argb32_full, AV_PIX_FMT_ARGB, CONFIG_SWSCALE_ALPHA && c->alpPixBuf)
+YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, abgr32_full, AV_PIX_FMT_ABGR, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, rgba32_full, AV_PIX_FMT_RGBA, CONFIG_SWSCALE_ALPHA && c->needAlpha)
+YUV2RGBWRAPPER(yuv2, rgb_full, argb32_full, AV_PIX_FMT_ARGB, CONFIG_SWSCALE_ALPHA && c->needAlpha)
#else
#if CONFIG_SWSCALE_ALPHA
YUV2RGBWRAPPER(yuv2, rgb_full, bgra32_full, AV_PIX_FMT_BGRA, 1)
@@ -2119,7 +2119,7 @@ av_cold void ff_sws_init_output_funcs(SwsContext *c,
*yuv2packed1 = yuv2rgba32_full_1_c;
#else
Re: [FFmpeg-devel] [PATCH] lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc
On Mon, Mar 28, 2016 at 07:51:24PM +0300, Kirill Gavrilov wrote:
> ---
> libavcodec/mediacodecdec.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 5c1368f..c21ceba 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -247,7 +247,7 @@ static int mediacodec_dec_parse_format(AVCodecContext
> *avctx, MediaCodecDecConte
> av_freep(&format);
> return AVERROR_EXTERNAL;
> }
> -s->stride = value >= 0 ? value : s->width;
> +s->stride = value > 0 ? value : s->width;
>
> if (!ff_AMediaFormat_getInt32(s->format, "slice-height", &value)) {
> format = ff_AMediaFormat_toString(s->format);
> --
> 2.6.1.windows.1
Applied, thanks.
Matthieu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 3/9] swscale/arm/yuv2rgb: remove unused store of dst + linesize in load_args_yuv422p
From: Matthieu Bouron
---
libswscale/arm/yuv2rgb_neon.S | 1 -
1 file changed, 1 deletion(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index aac0773..22864ec 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -171,7 +171,6 @@
ldr r10,[sp, #136] @ r10 =
y_coeff
vdup.16 d0, r10@ d0 =
y_coeff
vld1.16 {d1}, [r8] @ d1 =
*table
-add r11, r2, r3@ r11 =
dst + linesize (dst2)
sub r3, r3, r0, lsl #2 @ r3 =
linesize - width * 4 (padding)
sub r5, r5, r0 @ r5 =
linesizeY - width (paddingY)
sub r7, r7, r0, lsr #1 @ r7 =
linesizeU - width / 2 (paddingU)
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 1/9] swscale/arm/yuv2rgb: remove 32bit code path
From: Matthieu Bouron
---
libswscale/arm/swscale_unscaled.c | 72 --
libswscale/arm/yuv2rgb_neon.S | 156 --
2 files changed, 66 insertions(+), 162 deletions(-)
diff --git a/libswscale/arm/swscale_unscaled.c
b/libswscale/arm/swscale_unscaled.c
index 8aa933c..149208c 100644
--- a/libswscale/arm/swscale_unscaled.c
+++ b/libswscale/arm/swscale_unscaled.c
@@ -61,14 +61,14 @@ static int rgbx_to_nv12_neon_16_wrapper(SwsContext
*context, const uint8_t *src[
return 0;
}
-#define YUV_TO_RGB_TABLE(precision)
\
-c->yuv2rgb_v2r_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
-c->yuv2rgb_u2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
-c->yuv2rgb_v2g_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
-c->yuv2rgb_u2b_coeff / ((precision) == 16 ? 1 << 7 : 1),
\
-
-#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt, precision)
\
-int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
\
+#define YUV_TO_RGB_TABLE
\
+c->yuv2rgb_v2r_coeff / (1 << 7),
\
+c->yuv2rgb_u2g_coeff / (1 << 7),
\
+c->yuv2rgb_v2g_coeff / (1 << 7),
\
+c->yuv2rgb_u2b_coeff / (1 << 7),
\
+
+#define DECLARE_FF_YUVX_TO_RGBX_FUNCS(ifmt, ofmt)
\
+int ff_##ifmt##_to_##ofmt##_neon(int w, int h,
\
uint8_t *dst, int linesize,
\
const uint8_t *srcY, int linesizeY,
\
const uint8_t *srcU, int linesizeU,
\
@@ -77,37 +77,34 @@ int ff_##ifmt##_to_##ofmt##_neon_##precision(int w, int h,
int y_offset,
\
int y_coeff);
\
\
-static int ifmt##_to_##ofmt##_neon_wrapper_##precision(SwsContext *c, const
uint8_t *src[], \
+static int ifmt##_to_##ofmt##_neon_wrapper(SwsContext *c, const uint8_t
*src[], \
int srcStride[], int srcSliceY, int
srcSliceH, \
uint8_t *dst[], int dstStride[]) {
\
-const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE(precision) };
\
+const int16_t yuv2rgb_table[] = { YUV_TO_RGB_TABLE };
\
\
-ff_##ifmt##_to_##ofmt##_neon_##precision(c->srcW, srcSliceH,
\
+ff_##ifmt##_to_##ofmt##_neon(c->srcW, srcSliceH,
\
dst[0] + srcSliceY * dstStride[0],
dstStride[0], \
src[0], srcStride[0],
\
src[1], srcStride[1],
\
src[2], srcStride[2],
\
yuv2rgb_table,
\
c->yuv2rgb_y_offset >> 9,
\
- c->yuv2rgb_y_coeff / ((precision) == 16 ? 1
<< 7 : 1));\
+ c->yuv2rgb_y_coeff / (1 << 7));
\
\
return 0;
\
}
\
-#define DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS(yuvx, precision)
\
-DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, argb, precision)
\
-DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, rgba, precision)
\
-DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, abgr, precision)
\
-DECLARE_FF_YUVX_TO_RGBX_FUNCS(yuvx, bgra, precision)
\
+#define DECLARE_FF_YUVX_TO_ALL_RGBX_FUNCS(yuvx)
[FFmpeg-devel] [PATCH v2 5/9] swscale/arm/yuv2rgb: factorize lsl in load_args_nvx
From: Matthieu Bouron --- libswscale/arm/yuv2rgb_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S index 4601a79..ef7b0a6 100644 --- a/libswscale/arm/yuv2rgb_neon.S +++ b/libswscale/arm/yuv2rgb_neon.S @@ -131,8 +131,7 @@ add r12, r4, r5@ r12 = srcY + linesizeY (srcY2) lsl r3, r3, #1 lsl r5, r5, #1 -lsl r8, r0, #2 -sub r3, r3, r8 @ r3 = linesize * 2 - width * 4 (padding) +sub r3, r3, r0, lsl #2 @ r3 = linesize * 2 - width * 4 (padding) sub r5, r5, r0 @ r5 = linesizeY * 2 - width (paddingY) sub r7, r7, r0 @ r7 = linesizeC - width (paddingC) .endm -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 7/9] swscale/arm/yuv2rgb: re-order compute_rgba macro arguments
---
libswscale/arm/yuv2rgb_neon.S | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index e1b68c1..124d7d3 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -56,8 +56,8 @@
vqrshrun.s16\dst_comp2, q2, #6
.endm
-.macro compute_rgba r1 r2 g1 g2 b1 b2 a1 a2
-compute_color \r1, \r2, q8, q9
+.macro compute_rgba r1 g1 b1 a1 r2 g2 b2 a2
+compute_color \r1, \r2, q8, q9
compute_color \g1, \g2, q10, q11
compute_color \b1, \b2, q12, q13
vmov.u8 \a1, #255
@@ -80,19 +80,19 @@
.ifc \ofmt,argb
-compute_rgbad7, d11, d8, d12, d9, d13, d6, d10
+compute_rgbad7, d8, d9, d6, d11, d12, d13, d10
.endif
.ifc \ofmt,rgba
-compute_rgbad6, d10, d7, d11, d8, d12, d9, d13
+compute_rgbad6, d7, d8, d9, d10, d11, d12, d13
.endif
.ifc \ofmt,abgr
-compute_rgbad9, d13, d8, d12, d7, d11, d6, d10
+compute_rgbad9, d8, d7, d6, d13, d12, d11, d10
.endif
.ifc \ofmt,bgra
-compute_rgbad8, d12, d7, d11, d6, d10, d9, d13
+compute_rgbad8, d7, d6, d9, d12, d11, d10, d13
.endif
vst4.8 {q3, q4}, [\dst,:128]!
vst4.8 {q5, q6}, [\dst,:128]!
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 4/9] swscale/arm/yuv2rgb: factorize lsl in load_args_yuv420p
From: Matthieu Bouron --- libswscale/arm/yuv2rgb_neon.S | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S index 22864ec..4601a79 100644 --- a/libswscale/arm/yuv2rgb_neon.S +++ b/libswscale/arm/yuv2rgb_neon.S @@ -152,8 +152,7 @@ add r12, r4, r5@ r12 = srcY + linesizeY (srcY2) lsl r3, r3, #1 lsl r5, r5, #1 -lsl r8, r0, #2 -sub r3, r3, r8 @ r3 = linesize * 2 - width * 4 (padding) +sub r3, r3, r0, lsl #2 @ r3 = linesize * 2 - width * 4 (padding) sub r5, r5, r0 @ r5 = linesizeY * 2 - width (paddingY) ldr r10,[sp, #120] @ r10 = srcV .endm -- 2.7.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 2/9] swscale/arm/yuv2rgb: fix comments and factorize lsl in load_args_yuv422p
From: Matthieu Bouron
---
libswscale/arm/yuv2rgb_neon.S | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index f40327b..aac0773 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -172,11 +172,10 @@
vdup.16 d0, r10@ d0 =
y_coeff
vld1.16 {d1}, [r8] @ d1 =
*table
add r11, r2, r3@ r11 =
dst + linesize (dst2)
-lsl r8, r0, #2
-sub r3, r3, r8 @ r3 =
linesize * 2 - width * 4 (padding)
-sub r5, r5, r0 @ r5 =
linesizeY * 2 - width (paddingY)
-sub r7, r7, r0, lsr #1 @ r7 =
linesizeU - width / 2 (paddingU)
-sub r12,r12,r0, lsr #1 @ r12 =
linesizeV- width / 2 (paddingV)
+sub r3, r3, r0, lsl #2 @ r3 =
linesize - width * 4 (padding)
+sub r5, r5, r0 @ r5 =
linesizeY - width (paddingY)
+sub r7, r7, r0, lsr #1 @ r7 =
linesizeU - width / 2 (paddingU)
+sub r12,r12,r0, lsr #1 @ r12 =
linesizeV - width / 2 (paddingV)
ldr r10,[sp, #120] @ r10 =
srcV
.endm
--
2.7.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2 6/9] swscale/arm/yuv2rgb: macro-ify
---
libswscale/arm/yuv2rgb_neon.S | 137 ++
1 file changed, 60 insertions(+), 77 deletions(-)
diff --git a/libswscale/arm/yuv2rgb_neon.S b/libswscale/arm/yuv2rgb_neon.S
index ef7b0a6..e1b68c1 100644
--- a/libswscale/arm/yuv2rgb_neon.S
+++ b/libswscale/arm/yuv2rgb_neon.S
@@ -64,7 +64,7 @@
vmov.u8 \a2, #255
.endm
-.macro compute_16px dst y0 y1 ofmt
+.macro compute dst y0 y1 ofmt
vmovl.u8q14, \y0 @ 8px
of y
vmovl.u8q15, \y1 @ 8px
of y
@@ -99,23 +99,23 @@
.endm
-.macro process_1l_16px ofmt
+.macro process_1l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
.endm
-.macro process_2l_16px ofmt
+.macro process_2l ofmt
compute_premult d28, d29, d30, d31
vld1.8 {q7}, [r4]!@ first
line of luma
-compute_16pxr2, d14, d15, \ofmt
+compute r2, d14, d15, \ofmt
vld1.8 {q7}, [r12]! @
second line of luma
-compute_16pxr11, d14, d15, \ofmt
+compute r11, d14, d15, \ofmt
.endm
-.macro load_args_nvx
+.macro load_args_nv12
push{r4-r12, lr}
vpush {q4-q7}
ldr r4, [sp, #104] @ r4 =
srcY
@@ -136,6 +136,10 @@
sub r7, r7, r0 @ r7 =
linesizeC - width (paddingC)
.endm
+.macro load_args_nv21
+load_args_nv12
+.endm
+
.macro load_args_yuv420p
push{r4-r12, lr}
vpush {q4-q7}
@@ -176,55 +180,23 @@
ldr r10,[sp, #120] @ r10 =
srcV
.endm
-.macro declare_func ifmt ofmt
-function ff_\ifmt\()_to_\ofmt\()_neon, export=1
-
-.ifc \ifmt,nv12
-load_args_nvx
-.endif
-
-.ifc \ifmt,nv21
-load_args_nvx
-.endif
-
-.ifc \ifmt,yuv420p
-load_args_yuv420p
-.endif
-
-
-.ifc \ifmt,yuv422p
-load_args_yuv422p
-.endif
-
-1:
-mov r8, r0 @ r8 =
width
-2:
-pld [r6, #64*3]
-pld [r4, #64*3]
-
-vmov.i8 d10, #128
-
-.ifc \ifmt,nv12
+.macro load_chroma_nv12
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1:
interleaved chroma line
vsubl.u8q14, d2, d10 @ q14 =
U - 128
vsubl.u8q15, d3, d10 @ q15 =
V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,nv21
+.macro load_chroma_nv21
pld [r12, #64*3]
vld2.8 {d2, d3}, [r6]!@ q1:
interleaved chroma line
vsubl.u8q14, d3, d10 @ q14 =
U - 128
vsubl.u8q15, d2, d10 @ q15 =
V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv420p
+.macro load_chroma_yuv420p
pld [r10, #64*3]
pld [r12, #64*3]
@@ -232,68 +204,79 @@ function ff_\ifmt\()_to_\ofmt\()_neon, export=1
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14 =
U - 128
vsubl.u8q15, d3, d10 @ q15 =
V - 128
+.endm
-process_2l_16px \ofmt
-.endif
-
-.ifc \ifmt,yuv422p
+.macro load_chroma_yuv422p
pld [r10, #64*3]
vld1.8 d2, [r6]! @ d2:
chroma red line
vld1.8 d3, [r10]! @ d3:
chroma blue line
vsubl.u8q14, d2, d10 @ q14 =
U - 128
vsubl.u8q15, d3, d10 @ q15 =
V - 128
+.endm
-process_1l_16px \ofmt
-.endif
-
-subsr8, r8, #16@ width
-= 16
-bgt 2b
-
-add r2, r2, r3 @ dst
+= padding
-add r4, r4, r5 @ srcY
+= paddingY
-
-.ifc \ifmt,nv12
+.macro increment_nv12
add r11, r11, r3 @ dst2
+= padding
add r12, r12, r5 @ srcY2
+= paddingY
-
add r6, r6, r7 @ srcC
+= paddingC
-
subsr1, r1, #2 @
height -= 2
-.endif
-
-.ifc \ifmt,nv21
-add r11, r11, r3 @
Re: [FFmpeg-devel] [PATCH] lavd/dshow_crossbar: remove trailing whitespace
On 3/26/16, Lou Logan wrote:
> Signed-off-by: Lou Logan
> ---
> Probably don't need to send this for review, but I know nothing of dshow
> and can't test this trivial change since I don't use Windows.
> ---
> libavdevice/dshow_crossbar.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavdevice/dshow_crossbar.c b/libavdevice/dshow_crossbar.c
> index c0739da..95fb466 100644
> --- a/libavdevice/dshow_crossbar.c
> +++ b/libavdevice/dshow_crossbar.c
> @@ -167,7 +167,7 @@ dshow_try_setup_crossbar_options(ICaptureGraphBuilder2
> *graph_builder2,
> }
>
> if (devtype == VideoDevice && ctx->show_analog_tv_tuner_dialog) {
> -hr = ICaptureGraphBuilder2_FindInterface(graph_builder2,
> &LOOK_UPSTREAM_ONLY, NULL,
> +hr = ICaptureGraphBuilder2_FindInterface(graph_builder2,
> &LOOK_UPSTREAM_ONLY, NULL,
LGTM.
-roger-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavd/dshow_crossbar: remove trailing whitespace
On Mon, 28 Mar 2016 15:06:25 -0600, Roger Pack wrote: > > LGTM. > -roger- Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder
What is lpc ? Which lpc type (there are many in libavcodec/lpc.h)should be used for mlp ? Also, please tell lpc_passes and precision and max_order value to be specified for mlp. In correct order of parameters in old file is causing SIGABRT error in line 214 in lpc.h . :((( On Mon, Mar 28, 2016 at 4:49 AM, Michael Niedermayer wrote: > On Sun, Mar 27, 2016 at 11:01:11AM +0530, Disha Singh wrote: > > > testing this > > > ./ffmpeg -i in.m4a test.mlp > > > says it needs 'To use it anyways, you must set "-strict inofficial".' > > > thats ok if it would work: > > > > > > ./ffmpeg -i in.m4a -strict inofficial test.mlp > > > [mlp @ 0x2494740] Unable to parse option value "inofficial" > > > > > > Using :ffmpeg -i ~/input.mp3 -strict -unofficial -strict -2 -c:a mlp > > ~/output.mkv " gave me : > > > > [matroska @ 0x2bebe40] Timestamps are unset in a packet for stream 1. > This > > is deprecated and will stop working in the future. Fix your code to set > the > > timestamps properly > > [matroska @ 0x2bebe40] Encoder did not produce proper pts, making some > up. > > Segmentation fault (core dumped) > > > > I know why segfault comes but what is the timestamp error ? > > setting the AVPacket.pts should help, see how its done in other > encoders > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The bravest are surely those who have the clearest vision > of what is before them, glory and danger alike, and yet > notwithstanding go out to meet it. -- Thucydides > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder
To correct that : the error is in line 214 in lpc.c not lpc.h On Tue, Mar 29, 2016 at 3:13 AM, Disha Singh wrote: > What is lpc ? Which lpc type (there are many in libavcodec/lpc.h)should be > used for mlp ? Also, please tell lpc_passes and precision and max_order > value to be specified for mlp. > > In correct order of parameters in old file is causing SIGABRT error in > line 214 in lpc.h . :((( > > On Mon, Mar 28, 2016 at 4:49 AM, Michael Niedermayer < > mich...@niedermayer.cc> wrote: > >> On Sun, Mar 27, 2016 at 11:01:11AM +0530, Disha Singh wrote: >> > > testing this >> > > ./ffmpeg -i in.m4a test.mlp >> > > says it needs 'To use it anyways, you must set "-strict inofficial".' >> > > thats ok if it would work: >> > > >> > > ./ffmpeg -i in.m4a -strict inofficial test.mlp >> > > [mlp @ 0x2494740] Unable to parse option value "inofficial" >> > > >> > > Using :ffmpeg -i ~/input.mp3 -strict -unofficial -strict -2 -c:a mlp >> > ~/output.mkv " gave me : >> > >> > [matroska @ 0x2bebe40] Timestamps are unset in a packet for stream 1. >> This >> > is deprecated and will stop working in the future. Fix your code to set >> the >> > timestamps properly >> > [matroska @ 0x2bebe40] Encoder did not produce proper pts, making some >> up. >> > Segmentation fault (core dumped) >> > >> > I know why segfault comes but what is the timestamp error ? >> >> setting the AVPacket.pts should help, see how its done in other >> encoders >> >> [...] >> -- >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB >> >> The bravest are surely those who have the clearest vision >> of what is before them, glory and danger alike, and yet >> notwithstanding go out to meet it. -- Thucydides >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> >> > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/utils: fix packet duration of frames with discarded paddings
On Sun, 27 Mar 2016, Hendrik Leppkes wrote:
On Sun, Mar 27, 2016 at 6:09 PM, Marton Balint wrote:
Signed-off-by: Marton Balint
---
libavcodec/utils.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index c625bbc..073c6fa 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -2337,8 +2337,7 @@ int attribute_align_arg
avcodec_decode_audio4(AVCodecContext *avctx,
int64_t diff_ts = av_rescale_q(frame->nb_samples -
discard_padding,
(AVRational){1,
avctx->sample_rate},
avctx->pkt_timebase);
-if (av_frame_get_pkt_duration(frame) >= diff_ts)
-av_frame_set_pkt_duration(frame,
av_frame_get_pkt_duration(frame) - diff_ts);
+av_frame_set_pkt_duration(frame, diff_ts);
} else {
av_log(avctx, AV_LOG_WARNING, "Could not update timestamps for
discarded samples.\n");
}
--
2.6.2
Looks correct to me.
Thanks, pushed.
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [WIP] GSoC P frame support for FFV1 codec
Hi
On Mon, Mar 28, 2016 at 08:36:17PM +0300, Станислав Долганов wrote:
> Fix problems with multithread runs.
>
> --
> Stanislav Dolganov
> libavcodec/ffv1.c | 13
> libavcodec/ffv1.h |4 +
> libavcodec/ffv1dec.c | 76 +
> libavcodec/ffv1enc.c | 87
> +
> tests/ref/vsynth/vsynth1-ffv1 |4 -
> tests/ref/vsynth/vsynth1-ffv1-v0 |4 -
> tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 |4 -
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p |4 -
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 |4 -
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 |4 -
> tests/ref/vsynth/vsynth2-ffv1 |4 -
> tests/ref/vsynth/vsynth2-ffv1-v0 |4 -
> tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 |4 -
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p |4 -
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 |4 -
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 |4 -
> tests/ref/vsynth/vsynth3-ffv1 |4 -
> tests/ref/vsynth/vsynth3-ffv1-v0 |4 -
> tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 |4 -
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p |4 -
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 |4 -
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 |4 -
> 22 files changed, 214 insertions(+), 38 deletions(-)
> 5384aa4e0f22b0e53e986b31a4687ca19a7eb20c 0001-simple-P-frame-support.patch
> From 504dfc78085163d588b3f06d9e62c4d85ceebb17 Mon Sep 17 00:00:00 2001
> From: Stanislav Dolganov
> Date: Thu, 24 Mar 2016 13:53:43 +0300
> Subject: [PATCH 1/4] simple P frame support
>
> ---
> libavcodec/ffv1.c | 13 -
> libavcodec/ffv1.h | 4 +-
> libavcodec/ffv1dec.c | 76 ++
> libavcodec/ffv1enc.c | 87
> ++
> tests/ref/vsynth/vsynth1-ffv1 | 4 +-
> tests/ref/vsynth/vsynth1-ffv1-v0 | 4 +-
> tests/ref/vsynth/vsynth1-ffv1-v3-bgr0 | 4 +-
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv420p | 4 +-
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv422p10 | 4 +-
> tests/ref/vsynth/vsynth1-ffv1-v3-yuv444p16 | 4 +-
> tests/ref/vsynth/vsynth2-ffv1 | 4 +-
> tests/ref/vsynth/vsynth2-ffv1-v0 | 4 +-
> tests/ref/vsynth/vsynth2-ffv1-v3-bgr0 | 4 +-
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv420p | 4 +-
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv422p10 | 4 +-
> tests/ref/vsynth/vsynth2-ffv1-v3-yuv444p16 | 4 +-
> tests/ref/vsynth/vsynth3-ffv1 | 4 +-
> tests/ref/vsynth/vsynth3-ffv1-v0 | 4 +-
> tests/ref/vsynth/vsynth3-ffv1-v3-bgr0 | 4 +-
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv420p | 4 +-
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv422p10 | 4 +-
> tests/ref/vsynth/vsynth3-ffv1-v3-yuv444p16 | 4 +-
> 22 files changed, 214 insertions(+), 38 deletions(-)
>
> diff --git a/libavcodec/ffv1.c b/libavcodec/ffv1.c
> index 537409e..428bc8d 100644
> --- a/libavcodec/ffv1.c
> +++ b/libavcodec/ffv1.c
> @@ -51,12 +51,16 @@ av_cold int ff_ffv1_common_init(AVCodecContext *avctx)
>
> s->picture.f = av_frame_alloc();
> s->last_picture.f = av_frame_alloc();
> -if (!s->picture.f || !s->last_picture.f)
> +s->residual.f = av_frame_alloc();
> +if (!s->picture.f || !s->last_picture.f || !s->residual.f)
> return AVERROR(ENOMEM);
>
> s->width = avctx->width;
> s->height = avctx->height;
>
> +s->c_image_line_buf = av_mallocz_array(sizeof(*s->c_image_line_buf),
> s->width);
> +s->p_image_line_buf = av_mallocz_array(sizeof(*s->p_image_line_buf),
> s->width);
> +
> // defaults
> s->num_h_slices = 1;
> s->num_v_slices = 1;
> @@ -215,6 +219,10 @@ av_cold int ff_ffv1_close(AVCodecContext *avctx)
> ff_thread_release_buffer(avctx, &s->last_picture);
> av_frame_free(&s->last_picture.f);
>
> +if (s->residual.f)
> +ff_thread_release_buffer(avctx, &s->residual);
> +av_frame_free(&s->residual.f);
> +
> for (j = 0; j < s->max_slice_count; j++) {
> FFV1Context *fs = s->slice_context[j];
> for (i = 0; i < s->plane_count; i++) {
> @@ -226,6 +234,9 @@ av_cold int ff_ffv1_close(AVCodecContext *avctx)
> av_freep(&fs->sample_buffer);
> }
>
> +av_freep(&s->c_image_line_buf);
> +av_freep(&s->p_image_line_buf);
> +
> av_freep(&avctx->stats_out);
> for (j = 0; j < s->quant_table_count; j++) {
> av_freep(&s->initial_states[j]);
> diff --git a/libavcodec/ffv1.h b/libavcodec/ffv1.h
> index d9398e5..8d1f74a 100644
> --- a/libavcodec/ffv1.h
> +++ b/libavcodec/ffv1.h
> @@ -93,7 +93,7 @@ typedef struct FFV1Context {
> int flags;
> int picture_number;
> int key_frame;
> -ThreadFrame picture, last_picture;
> +ThreadFrame picture, last_pictu
Re: [FFmpeg-devel] [PATCH] mpegts: pcr period option for variable bitrate multiplexing
Inline answers and some questions/advice_sought are marked by "---" (start
and end)
Couple of NOTES and a bit more:
NOTE 1:
PCR is a different "animal" from PCR/PAT/PMT/SDT (PSI's): PSI have upper
bound
deadline with no consequences if inserted early while PCR value needs to
reflect
time at the "time" of insertion, and precisely so if system is to avoid
violating T-STD model.
- My guess is that the above was reasoning behind "original" logical
separation of
PCR and PAT/SDT handling
NOTE 2:
Given relatively minor "intended improvements" we tried to preserve current
structure
(architecture) despite its many flaws (PCR for VBR was plainly not
working).
NOTE 3:
CBR cases (for PCR/PAT/PMT/SDT) are very simple since muxrate provides time
measurement based on packet count. Its true that CBR is a special case of
VBR but
due significant difference in complexity between the two, special cases for
VBR are
"more efficient" way of handling requirements.
VBR mux-ing was not functional, and even with these additions, its not
really functioning
properly, To do that, code will need to compute "piece-wise" CBR segments
and base
insertion and PCR value on [n-1] + Rate[n]*bytes (piece-wise CBR). Add
separate PMT too.
This was paid effort for specific issue. I do plan to proceed with proper
design (I hope
paid effort but if not, once I get some time ... May onwards, after NAB
...).
I'll split patches per your suggestions and also include other recommended
changes
(see inline).
Regards
Predrag Filipovic
On Sun, Mar 27, 2016 at 8:09 AM, Michael Niedermayer wrote:
> On Fri, Mar 25, 2016 at 12:50:29PM -0400, Predrag Filipovic wrote:
> > Enable proper PCR insertion for VBR multiplexing (muxrate not specified).
> > Insertion timing is based on video frame keys and frame period,
> consequently
> > pcr period precision is limited to +/- one video frame period.
> >
> > Signed-off-by: Predrag Filipovic
> > ---
> > libavformat/mpegtsenc.c | 80
> +
> > 1 file changed, 61 insertions(+), 19 deletions(-)
> >
> > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> > index 7656720..7ed9076 100644
> > --- a/libavformat/mpegtsenc.c
> > +++ b/libavformat/mpegtsenc.c
> > @@ -105,6 +105,7 @@ typedef struct MpegTSWrite {
> > int tables_version;
> > double pat_period;
> > double sdt_period;
> > +int64_t last_pcr_ts;
> > int64_t last_pat_ts;
> > int64_t last_sdt_ts;
> >
> > @@ -903,6 +904,9 @@ static int mpegts_init(AVFormatContext *s)
> > ts_st = pcr_st->priv_data;
> >
> > if (ts->mux_rate > 1) {
> > +if (ts->pcr_period >= INT_MAX/2) {
> > +ts->pcr_period = PCR_RETRANS_TIME;
> > +}
>
> Currently pcr_period defaults are handled differently from
> pat_period and sdt_period
> after this patch its still different, why ?
>
> ts->sdt_packet_period and ts->pat_packet_period are initiaized to
> defaults, and disabled later in case of user provided parameters
>
> for pcr_period the user provided value is overridden (this is a bit
> ugly IMHO) and pcr_packet_period set to the user provided value if any
> and later only conditionally overriden in the VBR case
>
> why do you not change pcr_packet_period / pcr_period to work like
> pat_period & sdt_period ?
>
---
See NOTE 1, 3 at the start of Email
PCR override follows the same concept as overrides for pat and sdt, it was
just placed "hire up" where CBR and VBR cases are already split.
Yes, its ugly, should I move it down (same cluster as pat, sdt ?
---
>
> > service->pcr_packet_period = (int64_t)ts->mux_rate *
> ts->pcr_period /
> > (TS_PACKET_SIZE * 8 * 1000);
> > ts->sdt_packet_period = (int64_t)ts->mux_rate *
> SDT_RETRANS_TIME /
> > @@ -931,10 +935,19 @@ static int mpegts_init(AVFormatContext *s)
> > service->pcr_packet_period =
> > ts_st->user_tb.den / (10 * ts_st->user_tb.num);
> > }
> > -if (!service->pcr_packet_period)
> > +/* if pcr_period specified, mark pcr_packet_period as NA
> (=INT_MAX) */
> > +if (ts->pcr_period < INT_MAX/2) {
> > +service->pcr_packet_period = INT_MAX;
> > +} else {
> > +if (!service->pcr_packet_period) {
> > service->pcr_packet_period = 1;
> > +} else if (service->pcr_packet_period == INT_MAX) {
> > +service->pcr_packet_period--;
> > +}
> > +}
> > }
> >
>
> > +ts->last_pcr_ts = AV_NOPTS_VALUE;
>
> this looks wrong, i suspect this should be a loop over all services
> and service->last_pcr_ts = AV_NOPTS_VALUE;
>
> its ok to change this in a seperate patch of corse if thats cleaner
>
---
In current code, none of pcr_* varaibles should be a part of struct
MpegTSService
since these are used for muxing only (mpegtsenc.c only). These pcr_*
variables
should be moved (for current code) to struct MpegTSWrite like pat_* and
sdt_* vars.
"t
Re: [FFmpeg-devel] [PATCH]Addition of MLP encoder
On Tue, Mar 29, 2016 at 03:13:50AM +0530, Disha Singh wrote: > What is lpc ? linear predictive coding > Which lpc type (there are many in libavcodec/lpc.h)should be > used for mlp ? i would guess that doesnt matter and it should at some point become a user specified parameter you can also look at other encoders which use the lpc code > Also, please tell lpc_passes and precision and max_order > value to be specified for mlp. lpc_passes, is like type for the others check what the decoder or codec syntax can handle or what some MLP files use (ive no idea either without checking) > > In correct order of parameters in old file is causing SIGABRT error in line > 214 in lpc.h . :((( [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Everything should be made as simple as possible, but not simpler. -- Albert Einstein signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpegts: pcr period option for variable bitrate multiplexing
On Mon, Mar 28, 2016 at 07:58:29PM -0400, Predrag Filipovic wrote:
> Inline answers and some questions/advice_sought are marked by "---" (start
> and end)
>
> Couple of NOTES and a bit more:
>
> NOTE 1:
> PCR is a different "animal" from PCR/PAT/PMT/SDT (PSI's): PSI have upper
> bound
> deadline with no consequences if inserted early while PCR value needs to
> reflect
> time at the "time" of insertion, and precisely so if system is to avoid
> violating T-STD model.
please correct me if iam wrong but
pcr is different but when the value stored is correct for the
point where it is stored then its basically the same.
[...]
> This was paid effort for specific issue. I do plan to proceed with proper
> design (I hope
> paid effort but if not, once I get some time ... May onwards, after NAB
> ...).
that would be great
>
> I'll split patches per your suggestions and also include other recommended
> changes
> (see inline).
please do
more comments below inline
>
> Regards
>
> Predrag Filipovic
>
> On Sun, Mar 27, 2016 at 8:09 AM, Michael Niedermayer > wrote:
>
> > On Fri, Mar 25, 2016 at 12:50:29PM -0400, Predrag Filipovic wrote:
> > > Enable proper PCR insertion for VBR multiplexing (muxrate not specified).
> > > Insertion timing is based on video frame keys and frame period,
> > consequently
> > > pcr period precision is limited to +/- one video frame period.
> > >
> > > Signed-off-by: Predrag Filipovic
> > > ---
> > > libavformat/mpegtsenc.c | 80
> > +
> > > 1 file changed, 61 insertions(+), 19 deletions(-)
> > >
> > > diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
> > > index 7656720..7ed9076 100644
> > > --- a/libavformat/mpegtsenc.c
> > > +++ b/libavformat/mpegtsenc.c
> > > @@ -105,6 +105,7 @@ typedef struct MpegTSWrite {
> > > int tables_version;
> > > double pat_period;
> > > double sdt_period;
> > > +int64_t last_pcr_ts;
> > > int64_t last_pat_ts;
> > > int64_t last_sdt_ts;
> > >
> > > @@ -903,6 +904,9 @@ static int mpegts_init(AVFormatContext *s)
> > > ts_st = pcr_st->priv_data;
> > >
> > > if (ts->mux_rate > 1) {
> > > +if (ts->pcr_period >= INT_MAX/2) {
> > > +ts->pcr_period = PCR_RETRANS_TIME;
> > > +}
> >
> > Currently pcr_period defaults are handled differently from
> > pat_period and sdt_period
> > after this patch its still different, why ?
> >
> > ts->sdt_packet_period and ts->pat_packet_period are initiaized to
> > defaults, and disabled later in case of user provided parameters
> >
> > for pcr_period the user provided value is overridden (this is a bit
> > ugly IMHO) and pcr_packet_period set to the user provided value if any
> > and later only conditionally overriden in the VBR case
> >
> > why do you not change pcr_packet_period / pcr_period to work like
> > pat_period & sdt_period ?
> >
> ---
> See NOTE 1, 3 at the start of Email
> PCR override follows the same concept as overrides for pat and sdt, it was
> just placed "hire up" where CBR and VBR cases are already split.
> Yes, its ugly, should I move it down (same cluster as pat, sdt ?
> ---
if you can make it more similar to the pat/sdt case then please do
>
> >
> > > service->pcr_packet_period = (int64_t)ts->mux_rate *
> > ts->pcr_period /
> > > (TS_PACKET_SIZE * 8 * 1000);
> > > ts->sdt_packet_period = (int64_t)ts->mux_rate *
> > SDT_RETRANS_TIME /
> > > @@ -931,10 +935,19 @@ static int mpegts_init(AVFormatContext *s)
> > > service->pcr_packet_period =
> > > ts_st->user_tb.den / (10 * ts_st->user_tb.num);
> > > }
> > > -if (!service->pcr_packet_period)
> > > +/* if pcr_period specified, mark pcr_packet_period as NA
> > (=INT_MAX) */
> > > +if (ts->pcr_period < INT_MAX/2) {
> > > +service->pcr_packet_period = INT_MAX;
> > > +} else {
> > > +if (!service->pcr_packet_period) {
> > > service->pcr_packet_period = 1;
> > > +} else if (service->pcr_packet_period == INT_MAX) {
> > > +service->pcr_packet_period--;
> > > +}
> > > +}
> > > }
> > >
> >
> > > +ts->last_pcr_ts = AV_NOPTS_VALUE;
> >
> > this looks wrong, i suspect this should be a loop over all services
> > and service->last_pcr_ts = AV_NOPTS_VALUE;
> >
> > its ok to change this in a seperate patch of corse if thats cleaner
> >
> ---
> In current code, none of pcr_* varaibles should be a part of struct
> MpegTSService
> since these are used for muxing only (mpegtsenc.c only). These pcr_*
> variables
> should be moved (for current code) to struct MpegTSWrite like pat_* and
> sdt_* vars.
> "ts->last_pcr_ts = AV_NOPTS_VALUE;" here follows last_pat/sdt structure
> ---
>
> >
> >
> > > ts->last_pat_ts = AV_NOPTS_VALUE;
> > > ts->last_sdt_ts = AV_NOPTS_VALUE;
> > > // The user specified a period, use only it
> > > @@
Re: [FFmpeg-devel] FFmpeg code Attribution
On Sun, Mar 27, 2016 at 04:41:49PM -0400, Aaron Boxer wrote: > On Sun, Mar 27, 2016 at 4:10 PM, Michael Niedermayer > wrote: > > > On Thu, Mar 24, 2016 at 03:03:01PM +, Carl Eugen Hoyos wrote: > > > Aaron Boxer gmail.com> writes: > > > > > > > Anyways, the important thing here is to ensure that > > > > code from other projects gets proper attribution. > > > > > > Then please send a patch that adds the attribution, > > > remember that it is based on old libopenjpeg code, > > > Reimar already provided an appropriate line. > > > > can someone please post a patch to resolve this > > > > I can do that by the end of the week. For the patch, may I just stage the > changed files > and run > > git diff --cached ideally would be a proper "git format-patch" which in the commit message quotes some of the code that has been taken from openjpeg for each file changed "git diff --cached" doesnt have commit messages [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is dangerous to be right in matters on which the established authorities are wrong. -- Voltaire signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] lavu/dict: Add new flag to allow multiple equal keys.
Am 28.03.16 um 12:14 schrieb Hendrik Leppkes: > On Mon, Mar 28, 2016 at 12:05 PM, Marton Balint wrote: >> >> On Mon, 28 Mar 2016, Hendrik Leppkes wrote: >> >>> People that don't speak up at all may approve silently (or at least >>> not disapprove), someone that raised issues should give an explicit >>> OK/Nevermind/whatever, agreeing with you or withdrawing his >>> complaints, there is no "silent" option there. >> >> >> This seems unreasonable, beacuse this way a silent person can block a patch >> forever, which is not optimal. >> >> What I usually do is after a week of silence if I feel that I addressed the >> concerns, or there is no known way to improve the patch, I send one last >> ping explicitly stating that I will apply the patch soon. (whithin 1-2 >> days). And if the silence remains, I apply it. >> > > If you send a mail explicitly stating that and the intention to move > forward if no further feedback arrives, then its usually fine. Didn't > happen here though. "ping":http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211969 "don't like": http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211970 "what to do?": http://article.gmane.org/gmane.comp.video.ffmpeg.devel/211971 -silence- Ok, or not, whatever. My actions were not ideal either and I regret it. In the future I will be more sensible for pending people. And maybe wm4 might consider not to wait for others to squeeze his concerns out of him. I don't see any actions in bad faith. Let's go back to work everyone, please. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] doc/developer.texi: Add a code of conduct
Am 28.03.16 um 15:39 schrieb Michael Niedermayer: > On Mon, Mar 28, 2016 at 12:34:05PM +, Kieran Kunhya wrote: >> On Mon, 28 Mar 2016 at 11:58 Moritz Barsnick wrote: >> >>> [...] >>> >> Let's compare this to the VLC code of conduct: >> https://wiki.videolan.org/Code_of_Conduct/ >> >> Note how it has a list of specific violations, instead of vague things like >> "Be excellent" that the FFmpeg one has. >> Note how it has a huge section on disciplinary procedures. > > i dont mind at all to be more specific, do people want a more specific > list similar to vlc ? > I thought it wasnt neccessary to write it as a strict "law" as if > theres a nation of criminals that needs precissely worded laws. > But rather a nation of good meaning people who all want to work > together. I think a more precise law-like definition is not needed. However, listing disciplinary procedures will become very useful if we ever have to enforce anything. > the "Be excellent" text is identical to the linux kernel code of > conflict. > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/CodeOfConflict > > >> Note that this CoC should according to FFmpeg "rules" go through a vote, > > If there is no unanimous agreement then we should vote, yes. > If there is unanimous agreement and noone asks for a vote then iam > not sure, it might be better to vote anyway so everyone has a chance > to equally state if they approve or disapprove Let's do a vote. Otherwise this whole thing will become questionable if we ever have to act upon it. -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] configure: Force mingw's ld to keep the reloc section
On Sun, Mar 20, 2016 at 6:29 AM, Christophe Gisquet < christophe.gisq...@gmail.com> wrote: > > > I understand the sentiment, and there's probably little lost in > keeping it, but... is it not a hack? ie: > - When do you notice the added security is no longer there/it breaks > in even worse ways? > - Who is and would be available and able to prevent it from breaking? > Because it already has, and almost nobody dealt with it. > > The original author already did well in reporting the issue to > binutils, so I'm certainly not complaining about his efforts. > > -- > Christophe > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Sorry didn't see this until now. I think that making it dependent on enable/disable-debug is reasonable for an immediate fix. I'll see about taking another stab at binutils and seeing if this can't get fixed upstream. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] configure: Fix debugging on mingw-w64 with gdb
The relocation hack broke debugging on mingw-w64 when using gdb. This makes the reloc hack dependent on --disable-debug so it's still enabled for release builds. This is simply an immediate fix for the issue of broken debugging, we should probably still look at the possibility of reverting it outright if it proves to be more trouble than it's worth. For now keeping it enabled for release builds is a reasonable trade off. Signed-off-by: Alex Smith --- configure | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index e550547..e8c4a7b 100755 --- a/configure +++ b/configure @@ -4634,9 +4634,9 @@ case $target_os in # however ld then forgets what the entry point should be (oops) so we # have to manually (re)set it. if enabled x86_32; then -add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup +disabled debug && add_ldexeflags -Wl,--pic-executable,-e,_mainCRTStartup elif enabled x86_64; then -add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup +disabled debug && add_ldexeflags -Wl,--pic-executable,-e,mainCRTStartup check_ldflags -Wl,--high-entropy-va # binutils 2.25 # Set image base >4GB for extra entropy with HEASLR add_ldexeflags -Wl,--image-base,0x14000 -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] vf_coreimage.m build failure on ppc osx 10.5
I tried to get a fresh build of ffmpeg today and ran into this issue: OBJCC libavfilter/vf_coreimage.o src/libavfilter/vf_coreimage.m: In function ‘config_output’: src/libavfilter/vf_coreimage.m:75: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m: In function ‘list_filters’: src/libavfilter/vf_coreimage.m:103: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:109: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m: In function ‘apply_filter’: src/libavfilter/vf_coreimage.m:195: error: ‘__bridge’ undeclared (first use in this function) src/libavfilter/vf_coreimage.m:195: error: (Each undeclared identifier is reported only once src/libavfilter/vf_coreimage.m:195: error: for each function it appears in.) src/libavfilter/vf_coreimage.m:195: error: expected ‘)’ before ‘CIImage’ src/libavfilter/vf_coreimage.m:195: error: expected ‘]’ before ‘->’ token src/libavfilter/vf_coreimage.m:205: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:206: error: expected ‘)’ before ‘CIImage’ src/libavfilter/vf_coreimage.m:206: error: expected ‘,’ or ‘;’ before ‘ctx’ src/libavfilter/vf_coreimage.m:213: error: expected ‘)’ before ‘CIImage’ src/libavfilter/vf_coreimage.m:213: error: expected ‘]’ before ‘->’ token src/libavfilter/vf_coreimage.m:214: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:225: error: expected ‘)’ before ‘CIFilter’ src/libavfilter/vf_coreimage.m:225: error: expected ‘;’ before ‘ctx’ src/libavfilter/vf_coreimage.m:251: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:260: error: expected ‘)’ before ‘CIContext’ src/libavfilter/vf_coreimage.m:260: error: expected ‘]’ before ‘->’ token src/libavfilter/vf_coreimage.m:260: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:272: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:292: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:191: warning: unused variable ‘data’ src/libavfilter/vf_coreimage.m:186: warning: unused variable ‘frame_size’ src/libavfilter/vf_coreimage.m: In function ‘init’: src/libavfilter/vf_coreimage.m:526: warning: implicit declaration of function ‘CFBridgingRetain’ src/libavfilter/vf_coreimage.m:526: warning: assignment makes pointer from integer without a cast src/libavfilter/vf_coreimage.m:540: warning: ISO C90 forbids mixed declarations and code src/libavfilter/vf_coreimage.m:549: warning: implicit declaration of function ‘CGLGetCurrentContext’ src/libavfilter/vf_coreimage.m:552: warning: ‘CIContext’ may not respond to ‘+contextWithCGLContext:pixelFormat:colorSpace:options:’ src/libavfilter/vf_coreimage.m:552: warning: (Messages without a matching method signature src/libavfilter/vf_coreimage.m:552: warning: will be assumed to return ‘id’ and accept src/libavfilter/vf_coreimage.m:552: warning: ‘...’ as arguments.) src/libavfilter/vf_coreimage.m:552: warning: assignment makes pointer from integer without a cast src/libavfilter/vf_coreimage.m:560: warning: assignment makes pointer from integer without a cast make: *** [libavfilter/vf_coreimage.o] Error 1 [pavel@apple ffmpeg-git-build ] Sorry, I didn't have time to investigate yet, so I have no patch to offer... this is mostly to let others know about the problem. Pavel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] configure: Fix debugging on mingw-w64 with gdb
I think the logic is correct but I won't be able to test it with the changes until tomorrow. I wanted to get the patch on the ML as soon as possible since debugging is currently broken. As I mentioned in the original patch thread I'll see about taking another stab at binutils to see if this can't get fixed upstream. In the mean time keeping the reloc hack enabled for release builds seems reasonable. Sorry for the delay in addressing this. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] lavf: Add coreimage filter for GPU based image filtering on OSX.
>
> +enabled coreimage_filter && { check_header_objcc QuartzCore/CoreImage.h
> || disable coreimage_filter; }
> +enabled coreimagesrc_filter && { check_header_objcc
> QuartzCore/CoreImage.h || disable coreimagesrc_filter; }
>
Wouldnt it be simpler to just add an item to HEADERS_LIST for
QuartzCore_CoreImage_h then this check only needs to be done once as both
filters can then just depend on the header list entry.
e.g.
coreimage_filter_deps="QuartzCore_CoreImage_h"
...
check_header_objcc QuartzCore/CoreImage.h
This would also remove the need for the duplicate _extralibs= lines aswell.
VideoToolbox currently does something like this although much more
complicated as it was added as an external lib despite being in a similar
boat to coreimage.
FYI I noticed what looks like an error in check_header_objcc as the code
"enable_safe $headers" I believe should be "enable_safe $header" (no 's').
I dont have OSX to double check this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
