Re: [FFmpeg-devel] [PATCH] avfilter/vf_tinterlace: add mergex2 mode
On 30/09/15 14:39, Paul B Mahol wrote: > Signed-off-by: Paul B Mahol > --- > doc/filters.texi| 24 > libavfilter/tinterlace.h| 1 + > libavfilter/vf_tinterlace.c | 13 ++--- > 3 files changed, 35 insertions(+), 3 deletions(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index a4d828e..0a8588d 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -10774,6 +10774,30 @@ Output: > 1 1 2 2 3 3 4 > @end example > > +@item mergex2, 7 > +Move odd frames into the upper field, even into the lower field, > +generating a double height frame at same frame rate. > +@example > + --> time > +Input: > +Frame 1 Frame 2 Frame 3 Frame 4 > + > +1 2 3 4 > +1 2 3 4 > +1 2 3 4 > +1 2 3 4 > + > +Output: > +1 2 3 4 > +2 3 4 5 > +1 2 3 4 > +2 3 4 5 > +1 2 3 4 > +2 3 4 5 > +1 2 3 4 > +2 3 4 5 > +@end example > + > I can see the usefulness of merging, but making any particular frame both the lower field in one merged frame, and upper in the next, sounds like a recipe for eye watering judder on the output. I think one would need to explain how would one then strip alternate frames to get a stream with a consistent field dominance(and how to select even or odd frames to get the right one). > @end table > > [..] -- Tim. Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavf/utils: avoid giving up probing early with long subtitle events
On Wed, Sep 30, 2015 at 09:29:57PM -0500, Rodger Combs wrote:
> This happens on files with many overlapping subtitle events before the first
> packet of another stream. The combined durations of the subtitle events can
> exceed the max_analyze_duration before reading any of the other streams (even
> if they also start at the same timestamp).
>
> I also considered simply skipping this check for subtitle streams; sound
> better?
hmm
maybe something like this would give a better and more robust value ?
if (pkt->pts != AV_NOPTS_VALUE && pkt->pts > st->start_time)
st->info->codec_info_duration = FFMIN(pkt->pts - st->start_time,
st->info->codec_info_duration + pkt->duration);
>
> > On Sep 30, 2015, at 21:09, Michael Niedermayer wrote:
> >
> > On Sun, Sep 20, 2015 at 12:29:33PM -0500, Rodger Combs wrote:
> >> ---
> >> libavformat/utils.c | 7 ++-
> >> 1 file changed, 6 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/libavformat/utils.c b/libavformat/utils.c
> >> index 199e80b..0256894 100644
> >> --- a/libavformat/utils.c
> >> +++ b/libavformat/utils.c
> >> @@ -3343,7 +3343,12 @@ int avformat_find_stream_info(AVFormatContext *ic,
> >> AVDictionary **options)
> >> break;
> >> }
> >> if (pkt->duration) {
> >> -st->info->codec_info_duration+= pkt->duration;
> >> +if (st->codec->codec_type == AVMEDIA_TYPE_SUBTITLE) {
> >> +if (pkt->pts != AV_NOPTS_VALUE)
> >> +st->info->codec_info_duration = pkt->pts -
> >> st->start_time;
> >
> > this is wrong when theres a timestamp discontinuity
> >
> > can you explain how to reproduce the problem this fixes ?
> >
> > [...]
> > --
> > 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
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The real ebay dictionary, page 3
"Rare item" - "Common item with rare defect or maybe just a lie"
"Professional" - "'Toy' made in china, not functional except as doorstop"
"Experts will know" - "The seller hopes you are not an expert"
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] lavf/utils: avoid giving up probing early with long subtitle events
This happens on files with many overlapping subtitle events before the first
packet of another stream. The combined durations of the subtitle events can
exceed the max_analyze_duration before reading any of the other streams (even
if they also start at the same timestamp).
I also considered simply skipping this check for subtitle streams; sound better?
> On Sep 30, 2015, at 21:09, Michael Niedermayer wrote:
>
> On Sun, Sep 20, 2015 at 12:29:33PM -0500, Rodger Combs wrote:
>> ---
>> libavformat/utils.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 199e80b..0256894 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -3343,7 +3343,12 @@ int avformat_find_stream_info(AVFormatContext *ic,
>> AVDictionary **options)
>> break;
>> }
>> if (pkt->duration) {
>> -st->info->codec_info_duration+= pkt->duration;
>> +if (st->codec->codec_type == AVMEDIA_TYPE_SUBTITLE) {
>> +if (pkt->pts != AV_NOPTS_VALUE)
>> +st->info->codec_info_duration = pkt->pts -
>> st->start_time;
>
> this is wrong when theres a timestamp discontinuity
>
> can you explain how to reproduce the problem this fixes ?
>
> [...]
> --
> 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 3/3] lavf/utils: avoid giving up probing early with long subtitle events
On Sun, Sep 20, 2015 at 12:29:33PM -0500, Rodger Combs wrote:
> ---
> libavformat/utils.c | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 199e80b..0256894 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -3343,7 +3343,12 @@ int avformat_find_stream_info(AVFormatContext *ic,
> AVDictionary **options)
> break;
> }
> if (pkt->duration) {
> -st->info->codec_info_duration+= pkt->duration;
> +if (st->codec->codec_type == AVMEDIA_TYPE_SUBTITLE) {
> +if (pkt->pts != AV_NOPTS_VALUE)
> +st->info->codec_info_duration = pkt->pts -
> st->start_time;
this is wrong when theres a timestamp discontinuity
can you explain how to reproduce the problem this fixes ?
[...]
--
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
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/movie: check for format change more carefully.
On Wed, 30 Sep 2015 17:35:55 +0200, Nicolas George wrote: > Fix the segfault in trac ticket #4884. > > Signed-off-by: Nicolas George > --- > doc/filters.texi| 8 > libavfilter/src_movie.c | 50 > + > 2 files changed, 50 insertions(+), 8 deletions(-) > > diff --git a/doc/filters.texi b/doc/filters.texi > index a4d828e..9ad5db9 100644 > --- a/doc/filters.texi > +++ b/doc/filters.texi > @@ -13953,6 +13953,14 @@ Default value is "1". > > Note that when the movie is looped the source timestamps are not > changed, so it will generate non monotonically increasing timestamps. > + > +@item allow_format_change > +Allow format change in the streams. Format changes are normally not > +supported in filters, but a few filters, scale for example unoficially typo: unoficially/unofficially Could use a comma before "unofficially". Docs LGTM, other than those small nits. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86inc: Make cpuflag() and notcpuflag() return 0 or 1
Hi, On Wed, Sep 30, 2015 at 5:27 PM, Henrik Gramner wrote: > Makes it possible to use them in arithmetic expressions. > --- > libavutil/x86/x86inc.asm | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm > index 6ad9785..929d0d2 100644 > --- a/libavutil/x86/x86inc.asm > +++ b/libavutil/x86/x86inc.asm > @@ -773,8 +773,8 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg, > jge, jng, jnge, ja, jae, > %assign cpuflags_bmi1 (1<<22)|cpuflags_lzcnt > %assign cpuflags_bmi2 (1<<23)|cpuflags_bmi1 > > -%definecpuflag(x) ((cpuflags & (cpuflags_ %+ x)) == (cpuflags_ %+ x)) > -%define notcpuflag(x) ((cpuflags & (cpuflags_ %+ x)) != (cpuflags_ %+ x)) > +%definecpuflag(x) (cpuflags & (cpuflags_ %+ x)) ^ (cpuflags_ %+ > x)) - 1) >> 31) & 1) > +%define notcpuflag(x) (cpuflag(x) ^ 1) > > ; Takes an arbitrary number of cpuflags from the above list. > ; All subsequent functions (up to the next INIT_CPUFLAGS) is built for > the specified cpu. > -- > 1.9.1 Wow, many operands. Looks OK, although I have to admit this isn't exactly world-readable anymore :) I guess for this type of code that's OK... Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] ffplay: add support for interactive volume control
On Tue, 29 Sep 2015, Ganesh Ajjanagadde wrote: On Sun, Sep 27, 2015 at 5:09 PM, Marton Balint wrote: On Sun, 27 Sep 2015, Ganesh Ajjanagadde wrote: This is a feature heavily inspired by the mpv player. At the moment, methods for adjusting volume in ffplay are rather clumsy: either one needs to set it system-wide, or one needs to set it via the volume filter. This patch adds key bindings identical to the mpv defaults for muting/unmuting and increasing/decreasing the volume interactively without any introduction of external dependencies. TODO: doc update, possible mouse button bindings (mpv has this). Signed-off-by: Ganesh Ajjanagadde --- ffplay.c | 36 +++- 1 file changed, 35 insertions(+), 1 deletion(-) Applied, thanks. BTW, just a heads up: I won't be writing code for mouse wheel bindings. The reason is that it is more annoying to support: https://wiki.libsdl.org/MigrationGuide - basically old SDL 1.2 (which is what many users use) treated it as a button, a mistake corrected in 2.0. I think the code will need to differ accordingly. Thus, configure will need to export the SDL version, some ifdefry will need to be done, and all that is gained is a feature which many users in fact find annoying and explicitly disable: https://forum.videolan.org/viewtopic.php?f=12&t=108470 (the very first link in a search for "vlc mouse volume control" :D ). However, I won't object to a patch as long as it handles both SDL versions correctly and by default disables mouse volume control. Actually I don't really like the idea of using the mouse wheel for volume control, so no hard feelings :). By the way, I guess SDL2 compatiblity is more like a far goal, because it needs severe rework of the video part as well. (SDL_YUV_Overlay is gone) I have some patches I made earlier, I will publish it in a branch sometime. Another side note on this business: VLC allows "boosting" volume to 125% (I recall even 400% in the past, not sure right now). I regard this as a misfeature; even their devs later regretted it - maybe that's why the 400 was toned down to 125. Note that ffplay still supports such "boosting", but that needs to be done by a -af volume=+xdB or something like that. I consider it a good thing: if someone wants something extreme (which can clip the audio), they need to explicitly enable it via a filter. Thus, I definitely did not implement this and will object to a modification to ffplay trying to do such a thing. Agreed. I will add a Changelog entry after a week, once bugs/issues with this (if any) are handled. Okay, i was wondering if it is big enough of a change for a changelog, but apparently it is, because you already got a phoronix article about it, so go ahead :) Regards Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffplay: more robust mutex, condition variable handling
On Tue, 29 Sep 2015, Ganesh Ajjanagadde wrote:
SDL_CreateMutex and SDL_CreateCond can fail:
https://wiki.libsdl.org/SDL_CreateMutex.
This patch makes handling more robust in one instance.
Signed-off-by: Ganesh Ajjanagadde
---
ffplay.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/ffplay.c b/ffplay.c
index 3c2407f..9466996 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -451,12 +451,21 @@ static int packet_queue_put_nullpacket(PacketQueue *q,
int stream_index)
}
/* packet queue handling */
-static void packet_queue_init(PacketQueue *q)
+static int packet_queue_init(PacketQueue *q)
{
memset(q, 0, sizeof(PacketQueue));
q->mutex = SDL_CreateMutex();
+if (!q->mutex) {
+av_log(q, AV_LOG_FATAL, "SDL_CreateMutex(): %s\n", SDL_GetError());
+return AVERROR(ENOMEM);
+}
q->cond = SDL_CreateCond();
+if (!q->cond) {
+av_log(q, AV_LOG_FATAL, "SDL_CreateCond(): %s\n", SDL_GetError());
+return AVERROR(ENOMEM);
+}
q->abort_request = 1;
+return 0;
}
static void packet_queue_flush(PacketQueue *q)
@@ -3136,9 +3145,9 @@ static VideoState *stream_open(const char *filename,
AVInputFormat *iformat)
if (frame_queue_init(&is->sampq, &is->audioq, SAMPLE_QUEUE_SIZE, 1) < 0)
goto fail;
-packet_queue_init(&is->videoq);
-packet_queue_init(&is->audioq);
-packet_queue_init(&is->subtitleq);
+if (packet_queue_init(&is->videoq) || packet_queue_init(&is->audioq)
+|| packet_queue_init(&is->subtitleq))
+goto fail;
Only cosmetics, but maybe you could use ffmpeg-api-like less-than-zero
error checking with common indentation:
if (packet_queue_init() < 0 ||
packet_queue_init() < 0 ||
packet_queue_init() < 0)
Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: mark previous_picture as done on end of decode_frame_common()
On Wed, Sep 30, 2015 at 08:14:10PM -0400, Ronald S. Bultje wrote: > Hi, > > On Sun, Sep 27, 2015 at 9:13 PM, Michael Niedermayer > wrote: > > > From: Michael Niedermayer > > > > Fixes deadlock with threads > > > > Found-by: Paul B Mahol > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/pngdec.c |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c > > index ee11f12..743144b 100644 > > --- a/libavcodec/pngdec.c > > +++ b/libavcodec/pngdec.c > > @@ -1217,6 +1217,7 @@ exit_loop: > > } > > } > > ff_thread_report_progress(&s->picture, INT_MAX, 0); > > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > > > av_frame_set_metadata(p, metadata); > > metadata = NULL; > > @@ -1225,6 +1226,7 @@ exit_loop: > > fail: > > av_dict_free(&metadata); > > ff_thread_report_progress(&s->picture, INT_MAX, 0); > > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > return ret; > > } > > > > -- > > 1.7.9.5 > > > So I directly admit I didn't look very deep, so I may be missing something > terribly obvious, but uhm. Shouldn't we mark previous_picture as done when > it's current? Why mark it as done in the frame after? previous_picture is directly allocated and copied into if you can&want to redesign this, i wouldnt mind [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In fact, the RIAA has been known to suggest that students drop out of college or go to community college in order to be able to afford settlements. -- The RIAA signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes
Fixes trac #3842
---
libavformat/isom.h | 1 +
libavformat/mov.c | 192 +
2 files changed, 179 insertions(+), 14 deletions(-)
diff --git a/libavformat/isom.h b/libavformat/isom.h
index aee9d6e..8f22ea5 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -103,6 +103,7 @@ typedef struct MOVSbgp {
typedef struct MOVFragmentIndexItem {
int64_t moof_offset;
int64_t time;
+int headers_read;
} MOVFragmentIndexItem;
typedef struct MOVFragmentIndex {
diff --git a/libavformat/mov.c b/libavformat/mov.c
index da170a6..7f3d3ac 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3596,7 +3596,96 @@ static int mov_read_trun(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
return AVERROR_EOF;
frag->implicit_offset = offset;
-st->duration = sc->track_end = dts + sc->time_offset;
+
+sc->track_end = dts + sc->time_offset;
+if (st->duration < sc->track_end)
+st->duration = sc->track_end;
+
+return 0;
+}
+
+static int mov_read_sidx(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int64_t offset = avio_tell(pb) + atom.size, pts;
+uint8_t version;
+int i, track_id;
+AVStream *st = NULL;
+MOVStreamContext *sc;
+MOVFragmentIndex *index;
+MOVFragmentIndex **tmp;
+AVRational timescale;
+
+version = avio_r8(pb);
+if (version > 1)
+return AVERROR_PATCHWELCOME;
+
+avio_rb24(pb); // flags
+
+track_id = avio_rb32(pb); // Reference ID
+for (i = 0; i < c->fc->nb_streams; i++) {
+if (c->fc->streams[i]->id == track_id) {
+st = c->fc->streams[i];
+break;
+}
+}
+if (!st) {
+av_log(c->fc, AV_LOG_ERROR, "could not find corresponding track id
%d\n", track_id);
+return AVERROR_INVALIDDATA;
+}
+
+sc = st->priv_data;
+
+timescale = av_make_q(1, avio_rb32(pb));
+
+if (version == 0) {
+pts = avio_rb32(pb);
+offset += avio_rb32(pb);
+} else {
+pts = avio_rb64(pb);
+offset += avio_rb64(pb);
+}
+
+avio_rb16(pb); // reserved
+
+index = av_mallocz(sizeof(MOVFragmentIndex));
+if (!index) {
+return AVERROR(ENOMEM);
+}
+
+index->track_id = track_id;
+
+index->item_count = avio_rb16(pb);
+index->items = av_mallocz_array(
+index->item_count, sizeof(MOVFragmentIndexItem));
+
+if (!index->items) {
+av_freep(&index);
+return AVERROR(ENOMEM);
+}
+
+tmp = av_realloc_array(c->fragment_index_data,
+ c->fragment_index_count + 1,
+ sizeof(MOVFragmentIndex*));
+if (!tmp) {
+av_freep(&index->items);
+av_freep(&index);
+return AVERROR(ENOMEM);
+}
+c->fragment_index_data = tmp;
+c->fragment_index_data[c->fragment_index_count++] = index;
+
+for (i = 0; i < index->item_count; i++) {
+uint32_t size = avio_rb32(pb) & 0x7FFF;
+uint32_t duration = avio_rb32(pb);
+avio_rb32(pb); // sap_flags
+index->items[i].moof_offset = offset;
+index->items[i].time = av_rescale_q(pts, st->time_base, timescale);
+offset += size;
+pts += duration;
+}
+
+st->duration = sc->track_end = pts;
+
return 0;
}
@@ -3854,6 +3943,7 @@ static const MOVParseTableEntry mov_default_parse_table[]
= {
{ MKTAG('a','l','a','c'), mov_read_alac }, /* alac specific atom */
{ MKTAG('a','v','c','C'), mov_read_glbl },
{ MKTAG('p','a','s','p'), mov_read_pasp },
+{ MKTAG('s','i','d','x'), mov_read_sidx },
{ MKTAG('s','t','b','l'), mov_read_default },
{ MKTAG('s','t','c','o'), mov_read_stco },
{ MKTAG('s','t','p','s'), mov_read_stps },
@@ -3978,9 +4068,9 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
return err;
}
if (c->found_moov && c->found_mdat &&
-((!pb->seekable || c->fc->flags & AVFMT_FLAG_IGNIDX) ||
+((!pb->seekable || c->fc->flags & AVFMT_FLAG_IGNIDX ||
c->fragment_index_data) ||
start_pos + a.size == avio_size(pb))) {
-if (!pb->seekable || c->fc->flags & AVFMT_FLAG_IGNIDX)
+if (!pb->seekable || c->fc->flags & AVFMT_FLAG_IGNIDX ||
c->fragment_index_data)
c->next_root_atom = start_pos + a.size;
c->atom_depth --;
return 0;
@@ -4585,6 +4675,49 @@ static int should_retry(AVIOContext *pb, int error_code)
{
return 1;
}
+static int mov_switch_root(AVFormatContext *s, int64_t target)
+{
+MOVContext *mov = s->priv_data;
+int i, j;
+int already_read = 0;
+int found = 0;
+
+if (avio_seek(s->pb, target, SEEK_SET) != target) {
+av_log(mov->fc, AV_LOG_ERROR, "root atom offset 0x%"PRIx64": partial
file\n", target);
+return AVERROR_INVALIDDATA;
+}
+
+for (i = 0; i < mov->fragment_index_count; i++) {
+MOVFra
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: mark previous_picture as done on end of decode_frame_common()
Hi, On Sun, Sep 27, 2015 at 9:13 PM, Michael Niedermayer wrote: > From: Michael Niedermayer > > Fixes deadlock with threads > > Found-by: Paul B Mahol > Signed-off-by: Michael Niedermayer > --- > libavcodec/pngdec.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c > index ee11f12..743144b 100644 > --- a/libavcodec/pngdec.c > +++ b/libavcodec/pngdec.c > @@ -1217,6 +1217,7 @@ exit_loop: > } > } > ff_thread_report_progress(&s->picture, INT_MAX, 0); > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > av_frame_set_metadata(p, metadata); > metadata = NULL; > @@ -1225,6 +1226,7 @@ exit_loop: > fail: > av_dict_free(&metadata); > ff_thread_report_progress(&s->picture, INT_MAX, 0); > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > return ret; > } > > -- > 1.7.9.5 So I directly admit I didn't look very deep, so I may be missing something terribly obvious, but uhm. Shouldn't we mark previous_picture as done when it's current? Why mark it as done in the frame after? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: mark previous_picture as done on end of decode_frame_common()
On Wed, Sep 30, 2015 at 04:38:40PM +0200, Paul B Mahol wrote: > On 9/28/15, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > Fixes deadlock with threads > > > > Found-by: Paul B Mahol > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/pngdec.c |2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c > > index ee11f12..743144b 100644 > > --- a/libavcodec/pngdec.c > > +++ b/libavcodec/pngdec.c > > @@ -1217,6 +1217,7 @@ exit_loop: > > } > > } > > ff_thread_report_progress(&s->picture, INT_MAX, 0); > > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > > > av_frame_set_metadata(p, metadata); > > metadata = NULL; > > @@ -1225,6 +1226,7 @@ exit_loop: > > fail: > > av_dict_free(&metadata); > > ff_thread_report_progress(&s->picture, INT_MAX, 0); > > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > return ret; > > } > > > > -- > > 1.7.9.5 > > lgtm applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Many that live deserve death. And some that die deserve life. Can you give it to them? Then do not be too eager to deal out death in judgement. For even the very wise cannot see all ends. -- Gandalf signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/af_rubberband: add process_command()
On Wed, Sep 30, 2015 at 09:41:35PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/af_rubberband.c | 34 ++
> 1 file changed, 34 insertions(+)
>
> diff --git a/libavfilter/af_rubberband.c b/libavfilter/af_rubberband.c
> index 0a15fdc..b958681 100644
> --- a/libavfilter/af_rubberband.c
> +++ b/libavfilter/af_rubberband.c
> @@ -207,6 +207,39 @@ static int request_frame(AVFilterLink *outlink)
> return ret;
> }
>
> +static int process_command(AVFilterContext *ctx, const char *cmd, const char
> *args,
> + char *res, int res_len, int flags)
> +{
> +RubberBandContext *s = ctx->priv;
> +int ret;
> +
> +if (!strcmp(cmd, "tempo")) {
> +double arg;
> +
> +sscanf(args, "%lf", &arg);
> +if (arg < 0.01 || arg > 100) {
> +av_log(ctx, AV_LOG_ERROR,
> + "Tempo scale factor '%lf' out of range\n", arg);
[...]
> + "Pitch scale factor '%lf' out of range\n", arg);
"l" is unneeded, %f is for double already
also af_rubberband seems to fail to build with 1.3-1.2 from ubuntu
libavfilter/af_rubberband.c:53:54: error: ‘RubberBandOptionDetectorCompound’
undeclared here (not in a function)
libavfilter/af_rubberband.c:54:56: error: ‘RubberBandOptionDetectorPercussive’
undeclared here (not in a function)
libavfilter/af_rubberband.c:55:50: error: ‘RubberBandOptionDetectorSoft’
undeclared here (not in a function)
libavfilter/af_rubberband.c:64:49: error: ‘RubberBandOptionSmoothingOff’
undeclared here (not in a function)
libavfilter/af_rubberband.c:65:48: error: ‘RubberBandOptionSmoothingOn’
undeclared here (not in a function)
libavfilter/af_rubberband.c:74:51: error: ‘RubberBandOptionChannelsApart’
undeclared here (not in a function)
libavfilter/af_rubberband.c:75:54: error: ‘RubberBandOptionChannelsTogether’
undeclared here (not in a function)
libavfilter/af_rubberband.c: In function ‘process_command’:
libavfilter/af_rubberband.c:214:9: warning: unused variable ‘ret’
[-Wunused-variable]
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: runtime cpu detection for mips
On Wed, Sep 30, 2015 at 02:23:43PM +, Shivraj Patil wrote:
>
> imgtec.com> writes:
>
> > +FILE *f = fopen("/proc/cpuinfo", "r");
>
> Is this what every other software for mips does?
> How does the kernel (or whatever sets cpuinfo) know?
>
> Shivraj:- We have used generic cpuinfo as it is unrestricted to access from
> user space compared to the kernel setting hwcaps (via low level mips control
> regs accessible) in kernel space for now.
>
I might be asking something stupid, but afaik /proc is linux exclusive;
does this mean it's going to disable all optimisations on every other
system?
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
On Wed, Sep 30, 2015 at 11:22 PM, Ronald S. Bultje wrote: > On Wed, Sep 30, 2015 at 5:01 PM, Henrik Gramner wrote: >> I just wanted to make sure that my patch fixes this first before >> posting it, but I'm unable to apply your patch. Is it based on top of >> another patch? > > Yes, see https://github.com/rbultje/ffmpeg/commits/vp9-16bpp-asm Ok, my patch fixes it so I posted it to the ML. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 2/8] configure: Add version check for libkvazaar
On Wed, Sep 30, 2015 at 05:01:15PM +0300, Arttu Ylä-Outinen wrote: > Signed-off-by: Arttu Ylä-Outinen > --- > v3: Use pkg-config for checking the version. > > v2: Add this patch. > --- > configure |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Rewriting code that is poorly written but fully understood is good. Rewriting code that one doesnt understand is a sign that one is less smart then the original author, trying to rewrite it will not make it better. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86inc: Make cpuflag() and notcpuflag() return 0 or 1
Makes it possible to use them in arithmetic expressions. --- libavutil/x86/x86inc.asm | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/x86/x86inc.asm b/libavutil/x86/x86inc.asm index 6ad9785..929d0d2 100644 --- a/libavutil/x86/x86inc.asm +++ b/libavutil/x86/x86inc.asm @@ -773,8 +773,8 @@ BRANCH_INSTR jz, je, jnz, jne, jl, jle, jnl, jnle, jg, jge, jng, jnge, ja, jae, %assign cpuflags_bmi1 (1<<22)|cpuflags_lzcnt %assign cpuflags_bmi2 (1<<23)|cpuflags_bmi1 -%definecpuflag(x) ((cpuflags & (cpuflags_ %+ x)) == (cpuflags_ %+ x)) -%define notcpuflag(x) ((cpuflags & (cpuflags_ %+ x)) != (cpuflags_ %+ x)) +%definecpuflag(x) (cpuflags & (cpuflags_ %+ x)) ^ (cpuflags_ %+ x)) - 1) >> 31) & 1) +%define notcpuflag(x) (cpuflag(x) ^ 1) ; Takes an arbitrary number of cpuflags from the above list. ; All subsequent functions (up to the next INIT_CPUFLAGS) is built for the specified cpu. -- 1.9.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
Hi, On Wed, Sep 30, 2015 at 5:01 PM, Henrik Gramner wrote: > On Wed, Sep 30, 2015 at 10:49 PM, Ronald S. Bultje > wrote: > On Wed, Sep 30, 2015 at 4:02 PM, Henrik Gramner > wrote: > >> I actually have a patch locally somewhere that makes that work. > > > > Oh that's great! I guess I'll just do nothing then...? > > I just wanted to make sure that my patch fixes this first before > posting it, but I'm unable to apply your patch. Is it based on top of > another patch? Yes, see https://github.com/rbultje/ffmpeg/commits/vp9-16bpp-asm Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
On Wed, Sep 30, 2015 at 10:49 PM, Ronald S. Bultje wrote: On Wed, Sep 30, 2015 at 4:02 PM, Henrik Gramner wrote: >> I actually have a patch locally somewhere that makes that work. > > Oh that's great! I guess I'll just do nothing then...? I just wanted to make sure that my patch fixes this first before posting it, but I'm unable to apply your patch. Is it based on top of another patch? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
Hi, On Wed, Sep 30, 2015 at 4:02 PM, Henrik Gramner wrote: > On Wed, Sep 30, 2015 at 9:45 PM, James Almer wrote: > > Guess notcpuflag(ssse3) does not work here like ARCH_ or HAVE_ defines > do. > I actually have a patch locally somewhere that makes that work. Oh that's great! I guess I'll just do nothing then...? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] qsvenc.c: use query function to catch all kind of setting issues
On Wed, Sep 30, 2015 at 04:19:15PM +0200, Sven Dueking wrote:
> From 86ddf1095bfd557324f6eeb24d94cbd0a6818c10 Mon Sep 17 00:00:00 2001
> From: Sven Dueking
> Date: Wed, 30 Sep 2015 16:06:02 +0200
> Subject: [FFmpeg-devel] [PATCH] qsvenc.c: use query function to catch all
> kind of setting issues
>
> ---
> libavcodec/qsvenc.c | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1013fe1..55140e1 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -264,6 +264,14 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
> QSVEncContext *q)
> if (ret < 0)
> return ret;
>
> +ret = MFXVideoENCODE_Query(q->session, &q->param,&q->param);
> +if (MFX_WRN_PARTIAL_ACCELERATION==ret) {
> +av_log(avctx, AV_LOG_WARNING, "Encoder will work with partial HW
> acceleration\n");
> +} else if (ret < 0) {
Applying: qsvenc.c: use query function to catch all kind of setting issues
fatal: corrupt patch at line 10
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] lavfi/movie: check for format change more carefully.
On Wed, Sep 30, 2015 at 05:35:55PM +0200, Nicolas George wrote: > Fix the segfault in trac ticket #4884. > > Signed-off-by: Nicolas George > --- > doc/filters.texi| 8 > libavfilter/src_movie.c | 50 > + > 2 files changed, 50 insertions(+), 8 deletions(-) LGTM thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 04:32:24PM +0200, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer wrote: > > On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: > >> On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer > >> wrote: > >> > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: > >> >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer > >> >> wrote: > >> >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: > >> >> >> The chroma format can be still unset in postinit when a badly cut > >> >> >> stream > >> >> >> starts with a slice instead of a sequence header. This is a common > >> >> >> occurance when feeding avcodec from a Live TV stream. > >> >> >> --- > >> >> >> libavcodec/mpeg12dec.c | 1 - > >> >> >> 1 file changed, 1 deletion(-) > >> >> >> > >> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > >> >> >> index 5d916d1..b3c2c45 100644 > >> >> >> --- a/libavcodec/mpeg12dec.c > >> >> >> +++ b/libavcodec/mpeg12dec.c > >> >> >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext > >> >> >> *avctx) > >> >> >> case 1: avctx->chroma_sample_location = > >> >> >> AVCHROMA_LOC_LEFT; break; > >> >> >> case 2: > >> >> >> case 3: avctx->chroma_sample_location = > >> >> >> AVCHROMA_LOC_TOPLEFT; break; > >> >> >> -default: av_assert0(0); > >> >> >> } > >> >> >> } // MPEG-2 > >> >> > > >> >> > This assert double checks that the context init which uses > >> >> > width/height/chroma format is done after the chroma format and w/h has > >> >> > been read from the headers > >> >> > if this is reached without the headers being read then the code is > >> >> > buggy and removing the assert will not fix that bug > >> >> > > >> >> > also if there is no sequence header how is width/height set ? > >> >> > theres a check for width/height before mpeg_decode_postinit is called > >> >> > > >> >> > >> >> The dimensions are set by the caller in the avctx before opening the > >> >> codec, which apparently inits the mpeg context as well. > >> >> > >> >> Feel free to fix it differently, error out or something, but I can > >> >> trip an assert with input data, which should never happen. > >> > > >> > how can this be reproduced ? > >> > > >> > >> I can only trigger it with API usage, not through the CLI tools, so I > >> cannot produce a test case. > > > > is this with a unmodified up to date ffmpeg ? > > i fixed this assert failing a while ago > > (b54e03c9dc2a05324c08b503bfe7535c49c0f281) > > > > > > Its up to date, but slightly modified - but nothing pertinent to the > mpeg2 decoder as far as I know. > I'll just add this to the list of modifications then. I can clearly > trigger this assert in a release build (which is hilarious on its own, > asserts are a debugging tool), which crashes the application, so thats > no good. having the context inconsistent and fields at invalid values is also not good. Ill try to fix it [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- 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] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
On Wed, Sep 30, 2015 at 9:45 PM, James Almer wrote: > Guess notcpuflag(ssse3) does not work here like ARCH_ or HAVE_ defines do. I actually have a patch locally somewhere that makes that work. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
On 9/30/2015 4:36 PM, Ronald S. Bultje wrote: > +cglobal vp9_ipred_dr_32x32_16, 4, 5, 10 + notcpuflag(ssse3), \ /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1141: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1143: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1145: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1922: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1922: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1924: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1924: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1926: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/libavcodec/x86/vp9intrapred_16bpp.asm:1926: error: (WIN64_SPILL_XMM:1) expecting `)' /ffmpeg/src/library.mak:30: recipe for target 'libavcodec/x86/vp9intrapred_16bpp.o' failed make: *** [libavcodec/x86/vp9intrapred_16bpp.o] Error 1 Guess notcpuflag(ssse3) does not work here like ARCH_ or HAVE_ defines do. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/af_rubberband: add process_command()
Signed-off-by: Paul B Mahol
---
libavfilter/af_rubberband.c | 34 ++
1 file changed, 34 insertions(+)
diff --git a/libavfilter/af_rubberband.c b/libavfilter/af_rubberband.c
index 0a15fdc..b958681 100644
--- a/libavfilter/af_rubberband.c
+++ b/libavfilter/af_rubberband.c
@@ -207,6 +207,39 @@ static int request_frame(AVFilterLink *outlink)
return ret;
}
+static int process_command(AVFilterContext *ctx, const char *cmd, const char
*args,
+ char *res, int res_len, int flags)
+{
+RubberBandContext *s = ctx->priv;
+int ret;
+
+if (!strcmp(cmd, "tempo")) {
+double arg;
+
+sscanf(args, "%lf", &arg);
+if (arg < 0.01 || arg > 100) {
+av_log(ctx, AV_LOG_ERROR,
+ "Tempo scale factor '%lf' out of range\n", arg);
+return AVERROR(EINVAL);
+}
+rubberband_set_time_ratio(s->rbs, 1. / arg);
+}
+
+if (!strcmp(cmd, "pitch")) {
+double arg;
+
+sscanf(args, "%lf", &arg);
+if (arg < 0.01 || arg > 100) {
+av_log(ctx, AV_LOG_ERROR,
+ "Pitch scale factor '%lf' out of range\n", arg);
+return AVERROR(EINVAL);
+}
+rubberband_set_pitch_scale(s->rbs, arg);
+}
+
+return 0;
+}
+
static const AVFilterPad rubberband_inputs[] = {
{
.name = "default",
@@ -235,4 +268,5 @@ AVFilter ff_af_rubberband = {
.uninit= uninit,
.inputs= rubberband_inputs,
.outputs = rubberband_outputs,
+.process_command = process_command,
};
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
---
libavcodec/x86/vp9dsp_init.h |4 +
libavcodec/x86/vp9dsp_init_16bpp.c| 33 +
libavcodec/x86/vp9intrapred_16bpp.asm | 1613 +
3 files changed, 1650 insertions(+)
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 47d2246..5842282 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -165,6 +165,10 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
init_ipred_func(type, enum, 16, bpp, opt); \
init_ipred_func(type, enum, 32, bpp, opt)
+#define init_ipred_funcs(type, enum, bpp, opt) \
+init_ipred_func(type, enum, 4, bpp, opt); \
+init_8_16_32_ipred_funcs(type, enum, bpp, opt)
+
void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp);
diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
b/libavcodec/x86/vp9dsp_init_16bpp.c
index f4a4a5d..4ceb4d4 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp.c
@@ -51,6 +51,18 @@ decl_ipred_fns(h, 16, mmxext, sse2);
decl_ipred_fns(dc, 16, mmxext, sse2);
decl_ipred_fns(dc_top, 16, mmxext, sse2);
decl_ipred_fns(dc_left, 16, mmxext, sse2);
+
+#define decl_ipred_dir_funcs(type) \
+decl_ipred_fns(type, 16, sse2, sse2); \
+decl_ipred_fns(type, 16, ssse3, ssse3); \
+decl_ipred_fns(type, 16, avx, avx)
+
+decl_ipred_dir_funcs(dl);
+decl_ipred_dir_funcs(dr);
+decl_ipred_dir_funcs(vl);
+decl_ipred_dir_funcs(vr);
+decl_ipred_dir_funcs(hu);
+decl_ipred_dir_funcs(hd);
#endif /* HAVE_YASM */
av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
@@ -88,12 +100,33 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
init_8_16_32_ipred_funcs(dc, DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_top, TOP_DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_left, LEFT_DC, 16, sse2);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, sse2);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, sse2);
+init_ipred_funcs(vl, VERT_LEFT, 16, sse2);
+init_ipred_funcs(vr, VERT_RIGHT, 16, sse2);
+init_ipred_funcs(hu, HOR_UP, 16, sse2);
+init_ipred_funcs(hd, HOR_DOWN, 16, sse2);
+}
+
+if (EXTERNAL_SSSE3(cpu_flags)) {
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, ssse3);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, ssse3);
+init_ipred_funcs(vl, VERT_LEFT, 16, ssse3);
+init_ipred_funcs(vr, VERT_RIGHT, 16, ssse3);
+init_ipred_funcs(hu, HOR_UP, 16, ssse3);
+init_ipred_funcs(hd, HOR_DOWN, 16, ssse3);
}
if (EXTERNAL_AVX_FAST(cpu_flags)) {
init_fpel_func(2, 0, 32, put, , avx);
init_fpel_func(1, 0, 64, put, , avx);
init_fpel_func(0, 0, 128, put, , avx);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, avx);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, avx);
+init_ipred_funcs(vl, VERT_LEFT, 16, avx);
+init_ipred_funcs(vr, VERT_RIGHT, 16, avx);
+init_ipred_funcs(hu, HOR_UP, 16, avx);
+init_ipred_funcs(hd, HOR_DOWN, 16, avx);
}
if (EXTERNAL_AVX2(cpu_flags)) {
diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 6da42cf..8abee89 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -27,6 +27,11 @@ SECTION_RODATA 32
pd_2: times 8 dd 2
pd_4: times 8 dd 4
pd_8: times 8 dd 8
+pd_65535: times 8 dd 0x
+
+pb_2to15_14_15: db 2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,15
+pb_4_5_8to13_8x0: db 4,5,8,9,10,11,12,13,0,0,0,0,0,0,0,0
+pb_0to7_67x4: db 0,1,2,3,4,5,6,7,6,7,6,7,6,7,6,7
cextern pw_1
cextern pw_1023
@@ -34,8 +39,48 @@ cextern pw_4095
cextern pd_16
cextern pd_32
+; FIXME most top-only functions (ddl, vl, v, dc_top) can be modified to take
+; only 3 registers on x86-32, which would make it one cycle faster, but that
+; would make the code quite a bit uglier...
+
SECTION .text
+%macro SCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%if %0 == 4
+%define reg_%4 m%2
+%endif
+%else
+mova [%3], m%1
+%if %0 == 4
+%define reg_%4 [%3]
+%endif
+%endif
+%endmacro
+
+%macro UNSCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%else
+mova m%1, [%3]
+%endif
+%if %0 == 4
+%undef reg_%4
+%endif
+%endmacro
+
+%macro PRELOAD 2-3
+%if ARCH_X86_64
+mova m%1, [%2]
+%if %0 == 3
+%define reg_%3 m%1
+%endif
+%elif %0 == 3
+%define reg_%3 [%2]
+%endif
+%endmacro
+
INIT_MMX mmx
cglobal vp9_ipred_v_4x4_16, 2, 4, 1, dst, stride, l, a
movifnidn aq, amp
@@ -669,3 +714,1571 @@ cglobal vp9_ipred_tm_32x32_10, 4, 5, 10, 32 *
ARCH_X86_32, dst, stride, l, a
cglobal vp9_ipred_tm_32x32_12, 4, 5, 10, 32 * ARCH_X86_32, dst, stride, l, a
movam0, [pw_4095]
jmp mangle(private_prefix %+ _ %+ vp9_ipred_tm_32x32_10 %+ SUFFIX).body
+
+; Directional intra predi
[FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
---
libavcodec/x86/vp9dsp_init.h |4 +
libavcodec/x86/vp9dsp_init_16bpp.c| 33 +
libavcodec/x86/vp9intrapred_16bpp.asm | 1613 +
3 files changed, 1650 insertions(+)
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 47d2246..5842282 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -165,6 +165,10 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
init_ipred_func(type, enum, 16, bpp, opt); \
init_ipred_func(type, enum, 32, bpp, opt)
+#define init_ipred_funcs(type, enum, bpp, opt) \
+init_ipred_func(type, enum, 4, bpp, opt); \
+init_8_16_32_ipred_funcs(type, enum, bpp, opt)
+
void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp);
diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
b/libavcodec/x86/vp9dsp_init_16bpp.c
index f4a4a5d..4ceb4d4 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp.c
@@ -51,6 +51,18 @@ decl_ipred_fns(h, 16, mmxext, sse2);
decl_ipred_fns(dc, 16, mmxext, sse2);
decl_ipred_fns(dc_top, 16, mmxext, sse2);
decl_ipred_fns(dc_left, 16, mmxext, sse2);
+
+#define decl_ipred_dir_funcs(type) \
+decl_ipred_fns(type, 16, sse2, sse2); \
+decl_ipred_fns(type, 16, ssse3, ssse3); \
+decl_ipred_fns(type, 16, avx, avx)
+
+decl_ipred_dir_funcs(dl);
+decl_ipred_dir_funcs(dr);
+decl_ipred_dir_funcs(vl);
+decl_ipred_dir_funcs(vr);
+decl_ipred_dir_funcs(hu);
+decl_ipred_dir_funcs(hd);
#endif /* HAVE_YASM */
av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
@@ -88,12 +100,33 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
init_8_16_32_ipred_funcs(dc, DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_top, TOP_DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_left, LEFT_DC, 16, sse2);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, sse2);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, sse2);
+init_ipred_funcs(vl, VERT_LEFT, 16, sse2);
+init_ipred_funcs(vr, VERT_RIGHT, 16, sse2);
+init_ipred_funcs(hu, HOR_UP, 16, sse2);
+init_ipred_funcs(hd, HOR_DOWN, 16, sse2);
+}
+
+if (EXTERNAL_SSSE3(cpu_flags)) {
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, ssse3);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, ssse3);
+init_ipred_funcs(vl, VERT_LEFT, 16, ssse3);
+init_ipred_funcs(vr, VERT_RIGHT, 16, ssse3);
+init_ipred_funcs(hu, HOR_UP, 16, ssse3);
+init_ipred_funcs(hd, HOR_DOWN, 16, ssse3);
}
if (EXTERNAL_AVX_FAST(cpu_flags)) {
init_fpel_func(2, 0, 32, put, , avx);
init_fpel_func(1, 0, 64, put, , avx);
init_fpel_func(0, 0, 128, put, , avx);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, avx);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, avx);
+init_ipred_funcs(vl, VERT_LEFT, 16, avx);
+init_ipred_funcs(vr, VERT_RIGHT, 16, avx);
+init_ipred_funcs(hu, HOR_UP, 16, avx);
+init_ipred_funcs(hd, HOR_DOWN, 16, avx);
}
if (EXTERNAL_AVX2(cpu_flags)) {
diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 6da42cf..807ba21 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -27,6 +27,11 @@ SECTION_RODATA 32
pd_2: times 8 dd 2
pd_4: times 8 dd 4
pd_8: times 8 dd 8
+pd_65535: times 8 dd 0x
+
+pb_2to15_14_15: db 2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,15
+pb_4_5_8to13_8x0: db 4,5,8,9,10,11,12,13,0,0,0,0,0,0,0,0
+pb_0to7_67x4: db 0,1,2,3,4,5,6,7,6,7,6,7,6,7,6,7
cextern pw_1
cextern pw_1023
@@ -34,8 +39,48 @@ cextern pw_4095
cextern pd_16
cextern pd_32
+; FIXME most top-only functions (ddl, vl, v, dc_top) can be modified to take
+; only 3 registers on x86-32, which would make it one cycle faster, but that
+; would make the code quite a bit uglier...
+
SECTION .text
+%macro SCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%if %0 == 4
+%define reg_%4 m%2
+%endif
+%else
+mova [%3], m%1
+%if %0 == 4
+%define reg_%4 [%3]
+%endif
+%endif
+%endmacro
+
+%macro UNSCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%else
+mova m%1, [%3]
+%endif
+%if %0 == 4
+%undef reg_%4
+%endif
+%endmacro
+
+%macro PRELOAD 2-3
+%if ARCH_X86_64
+mova m%1, [%2]
+%if %0 == 3
+%define reg_%3 m%1
+%endif
+%elif %0 == 3
+%define reg_%3 [%2]
+%endif
+%endmacro
+
INIT_MMX mmx
cglobal vp9_ipred_v_4x4_16, 2, 4, 1, dst, stride, l, a
movifnidn aq, amp
@@ -669,3 +714,1571 @@ cglobal vp9_ipred_tm_32x32_10, 4, 5, 10, 32 *
ARCH_X86_32, dst, stride, l, a
cglobal vp9_ipred_tm_32x32_12, 4, 5, 10, 32 * ARCH_X86_32, dst, stride, l, a
movam0, [pw_4095]
jmp mangle(private_prefix %+ _ %+ vp9_ipred_tm_32x32_10 %+ SUFFIX).body
+
+; Directional intra predi
[FFmpeg-devel] [PATCH] [WIP] avcodec/videotoolbox: add Annex B support
This adds support for decoding .ts files demuxed by libavformat and
such.
The problem is that the VideoToolbox API wants mp4-style data for input,
but the extradata used to initialize the decoder was still in Annex B
format. It has to be reformatted to mp4-style data.
Fortunately, libavformat already has code for doing this in
libavformat/avc.c (used for mp4 muxing). Unfortunately, this can't be
used directly from libavcodec, because libavcodec can't use libavformat
symbols at all. This patch copies part of avc.c into videotoolbox.c, and
replaces AVIOContext usage (used for getting an appendable memory
buffer). The required function is ff_isom_write_avcc().
Possible solutions:
a) move ff_isom_write_avcc() to libavcodec, and use it as avpriv_
from libavformat
b) somehow add it as public libavcodec API
c) keep it duplicated in videotoolbox.c
Further, this actually depends on libavformat extracting SPS/PPS into
extradata. It's probably not such a good idea to rely on this. It's
fragile and burdends API users which do their own demuxing.
Possible solutions:
a) reconstruct SPS/PPS from H264Context (this is probably extremely
complex, if possible at all)
b) add code to the h264 decoder to "collect" the currently needed
SPS/PPS NALs
c) just rely on the libavformat hack
Suggestions welcome. Also, is there no appendable byte stream thing in
lavc? This is pretty painful.
---
libavcodec/videotoolbox.c | 188 ++
1 file changed, 175 insertions(+), 13 deletions(-)
diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index ce939ca..eead217 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -77,28 +77,190 @@ int ff_videotoolbox_alloc_frame(AVCodecContext *avctx,
AVFrame *frame)
return 0;
}
-CFDataRef ff_videotoolbox_avcc_extradata_create(AVCodecContext *avctx)
+static const uint8_t *ff_avc_find_startcode_internal(const uint8_t *p, const
uint8_t *end)
{
-CFDataRef data = NULL;
+const uint8_t *a = p + 4 - ((intptr_t)p & 3);
-/* Each VCL NAL in the bitstream sent to the decoder
- * is preceded by a 4 bytes length header.
- * Change the avcC atom header if needed, to signal headers of 4 bytes. */
-if (avctx->extradata_size >= 4 && (avctx->extradata[4] & 0x03) != 0x03) {
-uint8_t *rw_extradata = av_memdup(avctx->extradata,
avctx->extradata_size);
+for (end -= 3; p < a && p < end; p++) {
+if (p[0] == 0 && p[1] == 0 && p[2] == 1)
+return p;
+}
-if (!rw_extradata)
-return NULL;
+for (end -= 3; p < end; p += 4) {
+uint32_t x = *(const uint32_t*)p;
+// if ((x - 0x01000100) & (~x) & 0x80008000) // little endian
+// if ((x - 0x00010001) & (~x) & 0x00800080) // big endian
+if ((x - 0x01010101) & (~x) & 0x80808080) { // generic
+if (p[1] == 0) {
+if (p[0] == 0 && p[2] == 1)
+return p;
+if (p[2] == 0 && p[3] == 1)
+return p+1;
+}
+if (p[3] == 0) {
+if (p[2] == 0 && p[4] == 1)
+return p+2;
+if (p[4] == 0 && p[5] == 1)
+return p+3;
+}
+}
+}
+
+for (end += 3; p < end; p++) {
+if (p[0] == 0 && p[1] == 0 && p[2] == 1)
+return p;
+}
+
+return end + 3;
+}
+
+static const uint8_t *ff_avc_find_startcode(const uint8_t *p, const uint8_t
*end){
+const uint8_t *out= ff_avc_find_startcode_internal(p, end);
+if(pextradata_size);
+AV_WB32(p, nal_end - nal_start);
+memcpy(p + 4, nal_start, nal_end - nal_start);
+*size += append_len;
+nal_start = nal_end;
+}
+
+return 0;
+}
+
+#define AV_W8(p, v) *(p) = (v)
+
+static int ff_isom_write_avcc(uint8_t **out, const uint8_t *data, int len)
+{
+int outlen = 0;
+*out = NULL;
+
+if (len > 6) {
+/* check for h264 start code */
+if (AV_RB32(data) == 0x0001 ||
+AV_RB24(data) == 0x01) {
+uint8_t *buf=NULL, *end, *start;
+uint32_t sps_size=0, pps_size=0;
+uint8_t *sps=0, *pps=0;
+int total_len;
+uint8_t *p;
+
+int ret = ff_avc_parse_nal_units_buf(data, &buf, &len);
+if (ret < 0)
+return ret;
+start = buf;
+end = buf + len;
+
+/* look for sps and pps */
+while (end - buf > 4) {
+uint32_t size;
+uint8_t nal_type;
+size = FFMIN(AV_RB32(buf), end - buf - 4);
+buf += 4;
+nal_type = buf[0] & 0x1f;
+
+if (nal_type == 7) { /* SPS */
+sps = buf;
+sps_size = size;
+} else if (nal_type == 8) { /* PPS */
+pps = buf;
+pps_size = size;
+
[FFmpeg-devel] [PATCH] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 2 +
libavcodec/x86/constants.h | 1 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 90 +++
libavcodec/x86/vp9lpf_16bpp.asm | 823
libavcodec/x86/vp9mc_16bpp.asm | 2 +-
6 files changed, 918 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/x86/vp9lpf_16bpp.asm
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index febaccd..01e5f18 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -160,6 +160,7 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
x86/vp9itxfm.o\
x86/vp9lpf.o \
+ x86/vp9lpf_16bpp.o\
x86/vp9mc.o \
x86/vp9mc_16bpp.o
YASM-OBJS-$(CONFIG_WEBP_DECODER) += x86/vp8dsp.o
diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 553dd49..9f3c8b4 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -55,6 +55,8 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1024) = {
0x0400040004000400ULL, 0x040
0x0400040004000400ULL,
0x0400040004000400ULL};
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_2048) = { 0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4095) = { 0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL,
+0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4096) = { 0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_8192) = { 0x2000200020002000ULL,
0x2000200020002000ULL,
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index 33dbb65..37a1869 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -47,6 +47,7 @@ extern const ymm_reg ff_pw_512;
extern const ymm_reg ff_pw_1023;
extern const ymm_reg ff_pw_1024;
extern const ymm_reg ff_pw_2048;
+extern const ymm_reg ff_pw_4095;
extern const ymm_reg ff_pw_4096;
extern const ymm_reg ff_pw_8192;
extern const ymm_reg ff_pw_m1;
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index f48225c..56cd79e 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -65,6 +65,62 @@ filters_8tap_1d_fn2(put, 16, BPC, avx2, 16bpp)
filters_8tap_1d_fn2(avg, 16, BPC, avx2, 16bpp)
#endif
+#define decl_lpf_func(dir, wd, bpp, opt) \
+void ff_vp9_loop_filter_##dir##_##wd##_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H)
+
+#define decl_lpf_funcs(dir, wd, bpp) \
+decl_lpf_func(dir, wd, bpp, sse2); \
+decl_lpf_func(dir, wd, bpp, ssse3); \
+decl_lpf_func(dir, wd, bpp, avx)
+
+#define decl_lpf_funcs_wd(dir) \
+decl_lpf_funcs(dir, 4, BPC); \
+decl_lpf_funcs(dir, 8, BPC); \
+decl_lpf_funcs(dir, 16, BPC)
+
+decl_lpf_funcs_wd(h);
+decl_lpf_funcs_wd(v);
+
+#define lpf_16_wrapper(dir, off, bpp, opt) \
+static void loop_filter_##dir##_16_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H) \
+{ \
+ff_vp9_loop_filter_##dir##_16_##bpp##_##opt(dst, stride, E, I, H); \
+ff_vp9_loop_filter_##dir##_16_##bpp##_##opt(dst + off, stride, E, I, H); \
+}
+
+#define lpf_16_wrappers(bpp, opt) \
+lpf_16_wrapper(h, 8 * stride, bpp, opt); \
+lpf_16_wrapper(v, 16, bpp, opt)
+
+lpf_16_wrappers(BPC, sse2);
+lpf_16_wrappers(BPC, ssse3);
+lpf_16_wrappers(BPC, avx);
+
+#define lpf_mix2_wrapper(dir, off, wd1, wd2, bpp, opt) \
+static void loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt(uint8_t *dst,
ptrdiff_t stride, \
+ int E, int I, int
H) \
+{ \
+ff_vp9_loop_filter_##dir##_##wd1##_##bpp##_##opt(dst, stride, \
+ E & 0xff, I & 0xff, H &
0xff); \
+ff_vp9_loop_filter_##dir##_##wd2##_##bpp##_##opt(dst + off, stride, \
+ E >> 8, I >> 8, H >>
8); \
+}
+
+#define lpf_mix2_wrappers(wd1, wd2, bpp, opt) \
+lpf_mix2_wrapper(h, 8 * stride, wd1, wd2, bpp, opt); \
+lpf_mix2_wrapper(v, 16, wd1, wd2, bpp, opt)
+
+#define lpf_mix2_wrappers_set(bpp, opt) \
+lpf_mix2_wrappers(4, 4, bpp,
Re: [FFmpeg-devel] [PATCH] avutil: runtime cpu detection for mips
On Wed, Sep 30, 2015 at 02:21:18PM +, Shivraj Patil wrote:
>
> On Wed, Sep 30, 2015 at 07:03:46PM +0530, shivraj.pa...@imgtec.com wrote:
> > From: Shivraj Patil
> [...]
>
> > +static int get_cpuinfo(uint32_t *hwcap) {
> > +FILE *f = fopen("/proc/cpuinfo", "r");
>
> under qemu i get this:
>
> cpu_flags(raw) = 0x
> cpu_flags_str(raw) =
> cpu_flags(effective) = 0x
> cpu_flags_str(effective) =
> threads = 1 (cpu_count = 12)
>
> IIUC this disables all cpu extensions
> is that intended ?
> (we currently only have loongson hardware to test so this would mean an end
> to testing imgtec specific mips optimizations)
>
> Shivraj:- cpu detection will not work for qemu, however we have tested it on
> mips hardware at our end.
iam not speaking about just this patch
but we have just qemu to test on imgtec - mips
i can apply this patch but it means that in the future FFmpeg
will then only be tested on loongson because you effectively disable
our only way to test code on imgtec mips
its very strange that you want this
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
You can kill me, but you cannot change the truth.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
On Wed, Sep 30, 2015 at 7:26 PM, Ronald S. Bultje wrote: > On Wed, Sep 30, 2015 at 11:54 AM, Henrik Gramner wrote: >> +%macro FILTER_STEP 6-10 "", "", "", 0 ; tmp, reg, mask, shift, dst, \ >> > + ; src/sub1, sub2, add1, add2, >> dont_store >> > +psrlw %1, %2, %4 >> > +%ifnidn %7, "" >> > +psubw %2, %6 >> > +%endif >> > +psubw %1, %6 ; abs->delta >> > +%ifnidn %7, "" >> > +psubw %2, %7 >> > +%endif >> > +pand%1, reg_%3 ; apply mask >> > +%ifnidn %7, "" >> > +paddw %2, %8 >> > +%endif >> > +%if %10 == 1 >> > +paddw %6, %1 ; delta->abs >> > +%else >> > +paddw %1, %6 ; delta->abs >> > +%endif >> > +%ifnidn %7, "" >> > +paddw %2, %9 >> > +%endif >> > +%if %10 != 1 >> > +mova [%5], %1 >> > +%endif >> > +%endmacro >> >> Is there a reason for not merging most of those %ifs to make it more >> readable? >> > > Pairing. I can remove if you don't like it. OOE on x86 pretty much always handles reordering of instructions in cases like this just fine so code readability is in my opinion preferable over trying to optimally order instructions manually. OOE is actually ridiculously efficient on modern x86 CPUs and will reorder instructions all over the place anyway. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
---
libavcodec/x86/Makefile | 1 +
libavcodec/x86/constants.c | 2 +
libavcodec/x86/constants.h | 1 +
libavcodec/x86/vp9dsp_init_16bpp_template.c | 90 +++
libavcodec/x86/vp9lpf_16bpp.asm | 832
libavcodec/x86/vp9mc_16bpp.asm | 2 +-
6 files changed, 927 insertions(+), 1 deletion(-)
create mode 100644 libavcodec/x86/vp9lpf_16bpp.asm
diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index febaccd..01e5f18 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -160,6 +160,7 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
x86/vp9itxfm.o\
x86/vp9lpf.o \
+ x86/vp9lpf_16bpp.o\
x86/vp9mc.o \
x86/vp9mc_16bpp.o
YASM-OBJS-$(CONFIG_WEBP_DECODER) += x86/vp8dsp.o
diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 553dd49..9f3c8b4 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -55,6 +55,8 @@ DECLARE_ALIGNED(32, const ymm_reg, ff_pw_1024) = {
0x0400040004000400ULL, 0x040
0x0400040004000400ULL,
0x0400040004000400ULL};
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_2048) = { 0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL,
0x0800080008000800ULL };
+DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4095) = { 0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL,
+0x0fff0fff0fff0fffULL,
0x0fff0fff0fff0fffULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_4096) = { 0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL,
0x1000100010001000ULL };
DECLARE_ALIGNED(32, const ymm_reg, ff_pw_8192) = { 0x2000200020002000ULL,
0x2000200020002000ULL,
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index 33dbb65..37a1869 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -47,6 +47,7 @@ extern const ymm_reg ff_pw_512;
extern const ymm_reg ff_pw_1023;
extern const ymm_reg ff_pw_1024;
extern const ymm_reg ff_pw_2048;
+extern const ymm_reg ff_pw_4095;
extern const ymm_reg ff_pw_4096;
extern const ymm_reg ff_pw_8192;
extern const ymm_reg ff_pw_m1;
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index f48225c..56cd79e 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -65,6 +65,62 @@ filters_8tap_1d_fn2(put, 16, BPC, avx2, 16bpp)
filters_8tap_1d_fn2(avg, 16, BPC, avx2, 16bpp)
#endif
+#define decl_lpf_func(dir, wd, bpp, opt) \
+void ff_vp9_loop_filter_##dir##_##wd##_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H)
+
+#define decl_lpf_funcs(dir, wd, bpp) \
+decl_lpf_func(dir, wd, bpp, sse2); \
+decl_lpf_func(dir, wd, bpp, ssse3); \
+decl_lpf_func(dir, wd, bpp, avx)
+
+#define decl_lpf_funcs_wd(dir) \
+decl_lpf_funcs(dir, 4, BPC); \
+decl_lpf_funcs(dir, 8, BPC); \
+decl_lpf_funcs(dir, 16, BPC)
+
+decl_lpf_funcs_wd(h);
+decl_lpf_funcs_wd(v);
+
+#define lpf_16_wrapper(dir, off, bpp, opt) \
+static void loop_filter_##dir##_16_##bpp##_##opt(uint8_t *dst, ptrdiff_t
stride, \
+ int E, int I, int H) \
+{ \
+ff_vp9_loop_filter_##dir##_16_##bpp##_##opt(dst, stride, E, I, H); \
+ff_vp9_loop_filter_##dir##_16_##bpp##_##opt(dst + off, stride, E, I, H); \
+}
+
+#define lpf_16_wrappers(bpp, opt) \
+lpf_16_wrapper(h, 8 * stride, bpp, opt); \
+lpf_16_wrapper(v, 16, bpp, opt)
+
+lpf_16_wrappers(BPC, sse2);
+lpf_16_wrappers(BPC, ssse3);
+lpf_16_wrappers(BPC, avx);
+
+#define lpf_mix2_wrapper(dir, off, wd1, wd2, bpp, opt) \
+static void loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt(uint8_t *dst,
ptrdiff_t stride, \
+ int E, int I, int
H) \
+{ \
+ff_vp9_loop_filter_##dir##_##wd1##_##bpp##_##opt(dst, stride, \
+ E & 0xff, I & 0xff, H &
0xff); \
+ff_vp9_loop_filter_##dir##_##wd2##_##bpp##_##opt(dst + off, stride, \
+ E >> 8, I >> 8, H >>
8); \
+}
+
+#define lpf_mix2_wrappers(wd1, wd2, bpp, opt) \
+lpf_mix2_wrapper(h, 8 * stride, wd1, wd2, bpp, opt); \
+lpf_mix2_wrapper(v, 16, wd1, wd2, bpp, opt)
+
+#define lpf_mix2_wrappers_set(bpp, opt) \
+lpf_mix2_wrappers(4, 4, bpp,
Re: [FFmpeg-devel] [PATCH 2/2] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
Hi, thanks for review! On Wed, Sep 30, 2015 at 11:54 AM, Henrik Gramner wrote: > On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje > wrote: > > diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c > b/libavcodec/x86/vp9dsp_init_16bpp_template.c > > > +#define init_lpf_8_func(idx1, idx2, dir, wd, bpp, opt) \ > > +dsp->loop_filter_8[idx1][idx2] = > ff_loop_filter_##dir##_##wd##_##bpp##_##opt > > +#define init_lpf_16_func(idx, dir, bpp, opt) \ > > +dsp->loop_filter_16[idx] = loop_filter_##dir##_16_##bpp##_##opt > > +#define init_lpf_mix2_func(idx1, idx2, idx3, dir, wd1, wd2, bpp, opt) \ > > +dsp->loop_filter_mix2[idx1][idx2][idx3] = > loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt > > Are those defines required for macro expansion? If so, ok, otherwise > I'd drop them since they don't really simplify anything. > We need double macros for expansion of "BPC", yes. :( > diff --git a/libavcodec/x86/vp9lpf_16bpp.asm > b/libavcodec/x86/vp9lpf_16bpp.asm > > > +pw_4095: times 16 dw 4095 > > This one already exists in vp9mc_16bpp.asm, merge them. Oh right that was in the wrong patch (next one), moved here instead, sorry. > +%macro FILTER_STEP 6-10 "", "", "", 0 ; tmp, reg, mask, shift, dst, \ > > + ; src/sub1, sub2, add1, add2, > dont_store > > +psrlw %1, %2, %4 > > +%ifnidn %7, "" > > +psubw %2, %6 > > +%endif > > +psubw %1, %6 ; abs->delta > > +%ifnidn %7, "" > > +psubw %2, %7 > > +%endif > > +pand%1, reg_%3 ; apply mask > > +%ifnidn %7, "" > > +paddw %2, %8 > > +%endif > > +%if %10 == 1 > > +paddw %6, %1 ; delta->abs > > +%else > > +paddw %1, %6 ; delta->abs > > +%endif > > +%ifnidn %7, "" > > +paddw %2, %9 > > +%endif > > +%if %10 != 1 > > +mova [%5], %1 > > +%endif > > +%endmacro > > Is there a reason for not merging most of those %ifs to make it more > readable? > Pairing. I can remove if you don't like it. > +psllw m5, 1 > [...] > > +psllw m5, m3, 1 > [...] > > +psllw m5, m1, 1 > > Use paddw instead of left-shifting by 1. > Done. Otherwise LGTM. Also seems like AVX2 would indeed be quite useful here > if you feel like doing that. Anyone want to donate me a machine? :D Seriously, I've tried to write it such that avx2 should be as simple as adding another macro invocation, I can't exactly guarantee that it works, but I'm hoping it does. I'll try it on Kieran's new machine, but that would be a separate patch. No promises yet, trying to finish ssse3 coverage first ;) Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 6:03 PM, Paul B Mahol wrote: > Dana 30. 9. 2015. 17:19 osoba "Hendrik Leppkes" > napisala je: >> >> On Wed, Sep 30, 2015 at 4:35 PM, Paul B Mahol wrote: >> > On 9/30/15, Hendrik Leppkes wrote: >> >> On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer >> >> wrote: >> >>> On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: >> On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer < > michae...@gmx.at> >> wrote: >> > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: >> >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer >> >> wrote: >> >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >> >> >> The chroma format can be still unset in postinit when a badly > cut >> >> >> stream >> >> >> starts with a slice instead of a sequence header. This is a > common >> >> >> occurance when feeding avcodec from a Live TV stream. >> >> >> --- >> >> >> libavcodec/mpeg12dec.c | 1 - >> >> >> 1 file changed, 1 deletion(-) >> >> >> >> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >> >> >> index 5d916d1..b3c2c45 100644 >> >> >> --- a/libavcodec/mpeg12dec.c >> >> >> +++ b/libavcodec/mpeg12dec.c >> >> >> @@ -1389,7 +1389,6 @@ static int >> >> >> mpeg_decode_postinit(AVCodecContext *avctx) >> >> >> case 1: avctx->chroma_sample_location = >> >> >> AVCHROMA_LOC_LEFT; break; >> >> >> case 2: >> >> >> case 3: avctx->chroma_sample_location = >> >> >> AVCHROMA_LOC_TOPLEFT; break; >> >> >> -default: av_assert0(0); >> >> >> } >> >> >> } // MPEG-2 >> >> > >> >> > This assert double checks that the context init which uses >> >> > width/height/chroma format is done after the chroma format and > w/h >> >> > has >> >> > been read from the headers >> >> > if this is reached without the headers being read then the code > is >> >> > buggy and removing the assert will not fix that bug >> >> > >> >> > also if there is no sequence header how is width/height set ? >> >> > theres a check for width/height before mpeg_decode_postinit is >> >> > called >> >> > >> >> >> >> The dimensions are set by the caller in the avctx before opening > the >> >> codec, which apparently inits the mpeg context as well. >> >> >> >> Feel free to fix it differently, error out or something, but I can >> >> trip an assert with input data, which should never happen. >> > >> > how can this be reproduced ? >> > >> >> I can only trigger it with API usage, not through the CLI tools, so I >> cannot produce a test case. >> >>> >> >>> is this with a unmodified up to date ffmpeg ? >> >>> i fixed this assert failing a while ago >> >>> (b54e03c9dc2a05324c08b503bfe7535c49c0f281) >> >>> >> >>> >> >> >> >> Its up to date, but slightly modified - but nothing pertinent to the >> >> mpeg2 decoder as far as I know. >> >> I'll just add this to the list of modifications then. I can clearly >> >> trigger this assert in a release build (which is hilarious on its own, >> >> asserts are a debugging tool), which crashes the application, so thats >> >> no good. >> > >> > WTF, can you just give sample/link something? >> >> Like I said earlier in the thread, it happens with API usage in a Live >> TV scenario. I cannot produce a sample of that. > > Not even backtrace? > postinit is only called from one place, the trace isn't very interesting. mpeg_decode_postinit decode_chunks mpeg_decode_frame avcodec_decode_video2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
Dana 30. 9. 2015. 17:19 osoba "Hendrik Leppkes" napisala je: > > On Wed, Sep 30, 2015 at 4:35 PM, Paul B Mahol wrote: > > On 9/30/15, Hendrik Leppkes wrote: > >> On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer > >> wrote: > >>> On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer < michae...@gmx.at> > wrote: > > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: > >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer > >> wrote: > >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: > >> >> The chroma format can be still unset in postinit when a badly cut > >> >> stream > >> >> starts with a slice instead of a sequence header. This is a common > >> >> occurance when feeding avcodec from a Live TV stream. > >> >> --- > >> >> libavcodec/mpeg12dec.c | 1 - > >> >> 1 file changed, 1 deletion(-) > >> >> > >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > >> >> index 5d916d1..b3c2c45 100644 > >> >> --- a/libavcodec/mpeg12dec.c > >> >> +++ b/libavcodec/mpeg12dec.c > >> >> @@ -1389,7 +1389,6 @@ static int > >> >> mpeg_decode_postinit(AVCodecContext *avctx) > >> >> case 1: avctx->chroma_sample_location = > >> >> AVCHROMA_LOC_LEFT; break; > >> >> case 2: > >> >> case 3: avctx->chroma_sample_location = > >> >> AVCHROMA_LOC_TOPLEFT; break; > >> >> -default: av_assert0(0); > >> >> } > >> >> } // MPEG-2 > >> > > >> > This assert double checks that the context init which uses > >> > width/height/chroma format is done after the chroma format and w/h > >> > has > >> > been read from the headers > >> > if this is reached without the headers being read then the code is > >> > buggy and removing the assert will not fix that bug > >> > > >> > also if there is no sequence header how is width/height set ? > >> > theres a check for width/height before mpeg_decode_postinit is > >> > called > >> > > >> > >> The dimensions are set by the caller in the avctx before opening the > >> codec, which apparently inits the mpeg context as well. > >> > >> Feel free to fix it differently, error out or something, but I can > >> trip an assert with input data, which should never happen. > > > > how can this be reproduced ? > > > > I can only trigger it with API usage, not through the CLI tools, so I > cannot produce a test case. > >>> > >>> is this with a unmodified up to date ffmpeg ? > >>> i fixed this assert failing a while ago > >>> (b54e03c9dc2a05324c08b503bfe7535c49c0f281) > >>> > >>> > >> > >> Its up to date, but slightly modified - but nothing pertinent to the > >> mpeg2 decoder as far as I know. > >> I'll just add this to the list of modifications then. I can clearly > >> trigger this assert in a release build (which is hilarious on its own, > >> asserts are a debugging tool), which crashes the application, so thats > >> no good. > > > > WTF, can you just give sample/link something? > > Like I said earlier in the thread, it happens with API usage in a Live > TV scenario. I cannot produce a sample of that. Not even backtrace? > > - Hendrik > ___ > 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 2/2] vp9: sse2/ssse3/avx 16bpp loopfilter x86 simd.
On Fri, Sep 25, 2015 at 5:25 PM, Ronald S. Bultje wrote: > diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c > b/libavcodec/x86/vp9dsp_init_16bpp_template.c > +#define init_lpf_8_func(idx1, idx2, dir, wd, bpp, opt) \ > +dsp->loop_filter_8[idx1][idx2] = > ff_loop_filter_##dir##_##wd##_##bpp##_##opt > +#define init_lpf_16_func(idx, dir, bpp, opt) \ > +dsp->loop_filter_16[idx] = loop_filter_##dir##_16_##bpp##_##opt > +#define init_lpf_mix2_func(idx1, idx2, idx3, dir, wd1, wd2, bpp, opt) \ > +dsp->loop_filter_mix2[idx1][idx2][idx3] = > loop_filter_##dir##_##wd1##wd2##_##bpp##_##opt Are those defines required for macro expansion? If so, ok, otherwise I'd drop them since they don't really simplify anything. > diff --git a/libavcodec/x86/vp9lpf_16bpp.asm b/libavcodec/x86/vp9lpf_16bpp.asm > +pw_4095: times 16 dw 4095 This one already exists in vp9mc_16bpp.asm, merge them. > +%macro FILTER_STEP 6-10 "", "", "", 0 ; tmp, reg, mask, shift, dst, \ > + ; src/sub1, sub2, add1, add2, > dont_store > +psrlw %1, %2, %4 > +%ifnidn %7, "" > +psubw %2, %6 > +%endif > +psubw %1, %6 ; abs->delta > +%ifnidn %7, "" > +psubw %2, %7 > +%endif > +pand%1, reg_%3 ; apply mask > +%ifnidn %7, "" > +paddw %2, %8 > +%endif > +%if %10 == 1 > +paddw %6, %1 ; delta->abs > +%else > +paddw %1, %6 ; delta->abs > +%endif > +%ifnidn %7, "" > +paddw %2, %9 > +%endif > +%if %10 != 1 > +mova [%5], %1 > +%endif > +%endmacro Is there a reason for not merging most of those %ifs to make it more readable? > +psllw m5, 1 [...] > +psllw m5, m3, 1 [...] > +psllw m5, m1, 1 Use paddw instead of left-shifting by 1. Otherwise LGTM. Also seems like AVX2 would indeed be quite useful here if you feel like doing that. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option
> OK. I will test & apply this week-end unless you're in a hurry. In the > meantime, maybe just drop the V flag in the options (these options are > related to the audio only). Sounds good. I've removed the `V' flag from those options, and emailed a new patch. Thanks! ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option
---
doc/filters.texi| 9 +
libavfilter/f_ebur128.c | 22 ++
2 files changed, 31 insertions(+)
diff --git a/doc/filters.texi b/doc/filters.texi
index a4d828e..0140550 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -12662,6 +12662,15 @@ stream for better peak accuracy. It logs a message for
true-peak.
This mode requires a build with @code{libswresample}.
@end table
+@item dualmono
+Treat mono input files as 'dual mono.' If a mono file is intended for playback
+on a stereo system, its EBU R128 measurement will be perceptually incorrect.
+If set to @code{true}, this option will compensate for this effect.
+Multi-channel input files are not effected by this option.
+
+@item panlaw
+Set a specific pan law to be used for the measurement of dual mono files.
+This parameter is optional, and has a default value of -3.01dB.
@end table
@subsection Examples
diff --git a/libavfilter/f_ebur128.c b/libavfilter/f_ebur128.c
index 1d5c8fd..c63356f 100644
--- a/libavfilter/f_ebur128.c
+++ b/libavfilter/f_ebur128.c
@@ -139,6 +139,8 @@ typedef struct {
/* misc */
int loglevel; ///< log level for frame logging
int metadata; ///< whether or not to inject loudness
results in frames
+int dual_mono; ///< whether or not to treat single
channel input files as dual-mono
+double pan_law; ///< pan law value used to calulate
dual-mono measurements
} EBUR128Context;
enum {
@@ -163,6 +165,8 @@ static const AVOption ebur128_options[] = {
{ "none", "disable any peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_NONE}, INT_MIN, INT_MAX, A|F, "mode" },
{ "sample", "enable peak-sample mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_SAMPLES_PEAKS}, INT_MIN, INT_MAX, A|F, "mode" },
{ "true", "enable true-peak mode", 0, AV_OPT_TYPE_CONST, {.i64 =
PEAK_MODE_TRUE_PEAKS},INT_MIN, INT_MAX, A|F, "mode" },
+{ "dualmono", "treat mono input files as dual-mono", OFFSET(dual_mono),
AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, A|F },
+{ "panlaw", "set a specific pan law for dual-mono files", OFFSET(pan_law),
AV_OPT_TYPE_DOUBLE, {.dbl = -3.01029995663978}, -10.0, 0.0, A|F },
{ NULL },
};
@@ -661,6 +665,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
}
if (nb_integrated)
ebur128->integrated_loudness = LOUDNESS(integrated_sum /
nb_integrated);
+/* dual-mono correction */
+if (nb_channels == 1 && ebur128->dual_mono) {
+ebur128->integrated_loudness -= ebur128->pan_law;
+}
}
/* LRA */
@@ -707,6 +715,12 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*insamples)
}
}
+/* dual-mono correction */
+if (nb_channels == 1 && ebur128->dual_mono) {
+loudness_400 -= ebur128->pan_law;
+loudness_3000 -= ebur128->pan_law;
+}
+
#define LOG_FMT "M:%6.1f S:%6.1f I:%6.1f LUFS LRA:%6.1f LU"
/* push one video frame */
@@ -855,6 +869,14 @@ static av_cold void uninit(AVFilterContext *ctx)
int i;
EBUR128Context *ebur128 = ctx->priv;
+/* dual-mono correction */
+if (ebur128->nb_channels == 1 && ebur128->dual_mono) {
+ebur128->i400.rel_threshold -= ebur128->pan_law;
+ebur128->i3000.rel_threshold -= ebur128->pan_law;
+ebur128->lra_low -= ebur128->pan_law;
+ebur128->lra_high -= ebur128->pan_law;
+}
+
av_log(ctx, AV_LOG_INFO, "Summary:\n\n"
" Integrated loudness:\n"
"I: %5.1f LUFS\n"
--
1.8.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] lavfi/movie: check for format change more carefully.
Fix the segfault in trac ticket #4884.
Signed-off-by: Nicolas George
---
doc/filters.texi| 8
libavfilter/src_movie.c | 50 +
2 files changed, 50 insertions(+), 8 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a4d828e..9ad5db9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13953,6 +13953,14 @@ Default value is "1".
Note that when the movie is looped the source timestamps are not
changed, so it will generate non monotonically increasing timestamps.
+
+@item allow_format_change
+Allow format change in the streams. Format changes are normally not
+supported in filters, but a few filters, scale for example unoficially
+support them. If this option is not enabled, changes in format will result
+in a filtering error; if it is enabled, the check is bypassed. If the next
+filter does not support format changes, the behaviour is undefined, a crash
+is possible; use with extreme care.
@end table
It allows overlaying a second video on top of the main input of
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index bbdcbc8..fc2e07d 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -59,6 +59,7 @@ typedef struct MovieContext {
char *stream_specs; /**< user-provided list of streams, separated by + */
int stream_index; /**< for compatibility */
int loop_count;
+int allow_format_change;
AVFormatContext *format_ctx;
int eof;
@@ -83,6 +84,7 @@ static const AVOption movie_options[]= {
{ "streams", "set streams", OFFSET(stream_specs),
AV_OPT_TYPE_STRING, {.str = 0}, CHAR_MAX, CHAR_MAX, FLAGS },
{ "s","set streams", OFFSET(stream_specs),
AV_OPT_TYPE_STRING, {.str = 0}, CHAR_MAX, CHAR_MAX, FLAGS },
{ "loop", "set loop count", OFFSET(loop_count),
AV_OPT_TYPE_INT,{.i64 = 1}, 0,INT_MAX, FLAGS },
+{ "allow_format_change", "allow format change",
OFFSET(allow_format_change), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, FLAGS },
{ NULL },
};
@@ -539,14 +541,46 @@ static int movie_push_frame(AVFilterContext *ctx,
unsigned out_id)
ff_dlog(ctx, "movie_push_frame(): file:'%s' %s\n", movie->file_name,
describe_frame_to_str((char[1024]){0}, 1024, frame, frame_type,
outlink));
-if (st->st->codec->codec_type == AVMEDIA_TYPE_VIDEO) {
-if (frame->format != outlink->format) {
-av_log(ctx, AV_LOG_ERROR, "Format changed %s -> %s, discarding
frame\n",
-av_get_pix_fmt_name(outlink->format),
-av_get_pix_fmt_name(frame->format)
-);
-av_frame_free(&frame);
-return 0;
+if (!movie->allow_format_change) {
+switch (st->st->codec->codec_type) {
+
+case AVMEDIA_TYPE_VIDEO:
+if (frame->width != outlink->w ||
+frame->height != outlink->h ||
+frame->format != outlink->format) {
+av_log(ctx, AV_LOG_ERROR,
+ "Format change: %dx%d/%s -> %dx%d/%s, not supported\n",
+ outlink->w, outlink->h,
+ av_get_pix_fmt_name(outlink->format),
+ frame->width, frame->height,
+ av_get_pix_fmt_name(frame->format));
+av_frame_free(&frame);
+return AVERROR_PATCHWELCOME;
+}
+break;
+
+case AVMEDIA_TYPE_AUDIO:
+if (frame->format!= outlink->format ||
+frame->sample_rate != outlink->sample_rate||
+frame->channel_layout!= outlink->channel_layout ||
+av_frame_get_channels(frame) != outlink->channels ) {
+char l1[128], l2[128];
+av_get_channel_layout_string(l1, sizeof(l1),
+ outlink->channels,
+ outlink->channel_layout);
+av_get_channel_layout_string(l2, sizeof(l2),
+ av_frame_get_channels(frame),
+ frame->channel_layout);
+av_log(ctx, AV_LOG_ERROR,
+ "Format change: %dHz/%s/%s -> %dHz/%s/%s, not
supported\n",
+ outlink->sample_rate, l1,
+ av_get_sample_fmt_name(outlink->format),
+ frame->sample_rate, l2,
+ av_get_sample_fmt_name(frame->format));
+av_frame_free(&frame);
+return AVERROR_PATCHWELCOME;
+}
+break;
}
}
ret = ff_filter_frame(outlink, frame);
--
2.5.3
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: Add parsing for DDTS atom for DTS audio
2015-09-30 12:05 GMT+09:00 Michael Niedermayer : > On Tue, Sep 29, 2015 at 02:44:38PM -0700, Shawn Singh wrote: > > The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E. > > This is useful for DTS-HD formats, some of which cannot be > > decoded by dcadec.c or libdcadec. > > > > Signed-off-by: Shawn Singh > > --- > > libavformat/mov.c | 56 > +++ > > 1 file changed, 56 insertions(+) > > applied > > btw do you have a sample that you can share ? > > DASH-IF's test vectors contain DTS-in-ISOBMFF samples. http://dashif.org/test-vectors/ You can get them from URLs in MPD files. > thanks > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > The real ebay dictionary, page 1 > "Used only once"- "Some unspecified defect prevented a second use" > "In good condition" - "Can be repaird by experienced expert" > "As is" - "You wouldnt want it even if you were payed for it, if you knew > ..." > > ___ > 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] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 4:35 PM, Paul B Mahol wrote: > On 9/30/15, Hendrik Leppkes wrote: >> On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer >> wrote: >>> On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer wrote: > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer >> wrote: >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >> >> The chroma format can be still unset in postinit when a badly cut >> >> stream >> >> starts with a slice instead of a sequence header. This is a common >> >> occurance when feeding avcodec from a Live TV stream. >> >> --- >> >> libavcodec/mpeg12dec.c | 1 - >> >> 1 file changed, 1 deletion(-) >> >> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >> >> index 5d916d1..b3c2c45 100644 >> >> --- a/libavcodec/mpeg12dec.c >> >> +++ b/libavcodec/mpeg12dec.c >> >> @@ -1389,7 +1389,6 @@ static int >> >> mpeg_decode_postinit(AVCodecContext *avctx) >> >> case 1: avctx->chroma_sample_location = >> >> AVCHROMA_LOC_LEFT; break; >> >> case 2: >> >> case 3: avctx->chroma_sample_location = >> >> AVCHROMA_LOC_TOPLEFT; break; >> >> -default: av_assert0(0); >> >> } >> >> } // MPEG-2 >> > >> > This assert double checks that the context init which uses >> > width/height/chroma format is done after the chroma format and w/h >> > has >> > been read from the headers >> > if this is reached without the headers being read then the code is >> > buggy and removing the assert will not fix that bug >> > >> > also if there is no sequence header how is width/height set ? >> > theres a check for width/height before mpeg_decode_postinit is >> > called >> > >> >> The dimensions are set by the caller in the avctx before opening the >> codec, which apparently inits the mpeg context as well. >> >> Feel free to fix it differently, error out or something, but I can >> trip an assert with input data, which should never happen. > > how can this be reproduced ? > I can only trigger it with API usage, not through the CLI tools, so I cannot produce a test case. >>> >>> is this with a unmodified up to date ffmpeg ? >>> i fixed this assert failing a while ago >>> (b54e03c9dc2a05324c08b503bfe7535c49c0f281) >>> >>> >> >> Its up to date, but slightly modified - but nothing pertinent to the >> mpeg2 decoder as far as I know. >> I'll just add this to the list of modifications then. I can clearly >> trigger this assert in a release build (which is hilarious on its own, >> asserts are a debugging tool), which crashes the application, so thats >> no good. > > WTF, can you just give sample/link something? Like I said earlier in the thread, it happens with API usage in a Live TV scenario. I cannot produce a sample of that. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: Add parsing for DDTS atom for DTS audio
On Wed, Sep 30, 2015 at 5:53 AM, Michael Niedermayer
wrote:
> On Wed, Sep 30, 2015 at 02:17:02PM +0900, Yusuke Nakamura wrote:
> > 2015-09-30 6:44 GMT+09:00 Shawn Singh :
> >
> > > The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E.
> > > This is useful for DTS-HD formats, some of which cannot be
> > > decoded by dcadec.c or libdcadec.
> > >
> >
> > How useful?
> > DTS audio has scalability, and 'ddts' box indicates only one of
> properties
> > of the stream.
> >
> >
> > >
> > > Signed-off-by: Shawn Singh
> > > ---
> > > libavformat/mov.c | 56
> > > +++
> > > 1 file changed, 56 insertions(+)
> > >
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index c57aaeb..da170a6 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -744,6 +744,61 @@ static int mov_read_dec3(MOVContext *c,
> AVIOContext
> > > *pb, MOVAtom atom)
> > > return 0;
> > > }
> > >
> > > +static int mov_read_ddts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > > +{
> > > +const uint32_t ddts_size = 20;
> > > +AVStream *st = NULL;
> > > +uint8_t *buf = NULL;
> > > +uint32_t frame_duration_code = 0;
> > > +uint32_t channel_layout_code = 0;
> > > +GetBitContext gb;
> > > +
> > > +buf = av_malloc(ddts_size + FF_INPUT_BUFFER_PADDING_SIZE);
> > > +if (!buf) {
> > > +return AVERROR(ENOMEM);
> > > +}
> > > +if (avio_read(pb, buf, ddts_size) < ddts_size) {
> > > +av_free(buf);
> > > +return AVERROR_INVALIDDATA;
> > > +}
> > > +
> > > +init_get_bits(&gb, buf, 8*ddts_size);
> > > +
> > > +if (c->fc->nb_streams < 1) {
> > > +return 0;
> > > +}
> > > +st = c->fc->streams[c->fc->nb_streams-1];
> > > +
> > > +st->codec->sample_rate = get_bits_long(&gb, 32);
> > > +skip_bits_long(&gb, 32); /* max bitrate */
> > > +st->codec->bit_rate = get_bits_long(&gb, 32);
> > > +st->codec->bits_per_coded_sample = get_bits(&gb, 8);
> > >
> >
> > This field is set to 0 as a reserved field if the file is compatible with
> > Ultra Violet's Common File Format (CFF).
> > I prefer that the reference about this is here.
> >
> >
> > > +frame_duration_code = get_bits(&gb, 2);
> > > +skip_bits(&gb, 30); /* various fields */
> > > +channel_layout_code = get_bits(&gb, 16);
> > > +
> > > +st->codec->frame_size =
> > > +(frame_duration_code == 0) ? 512 :
> > > +(frame_duration_code == 1) ? 1024 :
> > > +(frame_duration_code == 2) ? 2048 :
> > > +(frame_duration_code == 3) ? 4096 : 0;
> > >
> >
> > Wrong if LBRDurationMod is set to 1.
>
> if you think its better to revert this patch, just say so and ill
> revert
>
> [...]
> --
> 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
>
>
Michael and Yusuke, thanks for the feedback.
If you do revert, that's no problem. Otherwise, I can submit a
fix for the LBRDurationMod and for the CFF reserved field as Yusuke
suggested.
Also, unfortunately we do not have any samples that can be shared.
I will try to remux one of the existing fate tests, but we have
limited remuxing capability so it probably will not work.
Yusuke has a good point that the DDTS atom can reflect only one
configuration (e.g. core-substream only, or core + extension). The dcadec
or libdcadec decoders will override any AVStream fields that are set
here. Our use case was to facilitate probing DTS-HD files with
avformat_find_stream_info without requiring to decode. Doing so also
required disabling CODEC_CAP_CHANNEL_CONF capability in the decoder,
but obviously that is not appropriate to contribute back to ffmpeg. We
thought the atom parsing would be nice to contribute.
Best Regards,
~Shawn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: mark previous_picture as done on end of decode_frame_common()
On 9/28/15, Michael Niedermayer wrote: > From: Michael Niedermayer > > Fixes deadlock with threads > > Found-by: Paul B Mahol > Signed-off-by: Michael Niedermayer > --- > libavcodec/pngdec.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c > index ee11f12..743144b 100644 > --- a/libavcodec/pngdec.c > +++ b/libavcodec/pngdec.c > @@ -1217,6 +1217,7 @@ exit_loop: > } > } > ff_thread_report_progress(&s->picture, INT_MAX, 0); > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > > av_frame_set_metadata(p, metadata); > metadata = NULL; > @@ -1225,6 +1226,7 @@ exit_loop: > fail: > av_dict_free(&metadata); > ff_thread_report_progress(&s->picture, INT_MAX, 0); > +ff_thread_report_progress(&s->previous_picture, INT_MAX, 0); > return ret; > } > > -- > 1.7.9.5 lgtm ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On 9/30/15, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer > wrote: >> On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: >>> On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer >>> wrote: >>> > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: >>> >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer >>> >> wrote: >>> >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >>> >> >> The chroma format can be still unset in postinit when a badly cut >>> >> >> stream >>> >> >> starts with a slice instead of a sequence header. This is a common >>> >> >> occurance when feeding avcodec from a Live TV stream. >>> >> >> --- >>> >> >> libavcodec/mpeg12dec.c | 1 - >>> >> >> 1 file changed, 1 deletion(-) >>> >> >> >>> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >>> >> >> index 5d916d1..b3c2c45 100644 >>> >> >> --- a/libavcodec/mpeg12dec.c >>> >> >> +++ b/libavcodec/mpeg12dec.c >>> >> >> @@ -1389,7 +1389,6 @@ static int >>> >> >> mpeg_decode_postinit(AVCodecContext *avctx) >>> >> >> case 1: avctx->chroma_sample_location = >>> >> >> AVCHROMA_LOC_LEFT; break; >>> >> >> case 2: >>> >> >> case 3: avctx->chroma_sample_location = >>> >> >> AVCHROMA_LOC_TOPLEFT; break; >>> >> >> -default: av_assert0(0); >>> >> >> } >>> >> >> } // MPEG-2 >>> >> > >>> >> > This assert double checks that the context init which uses >>> >> > width/height/chroma format is done after the chroma format and w/h >>> >> > has >>> >> > been read from the headers >>> >> > if this is reached without the headers being read then the code is >>> >> > buggy and removing the assert will not fix that bug >>> >> > >>> >> > also if there is no sequence header how is width/height set ? >>> >> > theres a check for width/height before mpeg_decode_postinit is >>> >> > called >>> >> > >>> >> >>> >> The dimensions are set by the caller in the avctx before opening the >>> >> codec, which apparently inits the mpeg context as well. >>> >> >>> >> Feel free to fix it differently, error out or something, but I can >>> >> trip an assert with input data, which should never happen. >>> > >>> > how can this be reproduced ? >>> > >>> >>> I can only trigger it with API usage, not through the CLI tools, so I >>> cannot produce a test case. >> >> is this with a unmodified up to date ffmpeg ? >> i fixed this assert failing a while ago >> (b54e03c9dc2a05324c08b503bfe7535c49c0f281) >> >> > > Its up to date, but slightly modified - but nothing pertinent to the > mpeg2 decoder as far as I know. > I'll just add this to the list of modifications then. I can clearly > trigger this assert in a release build (which is hilarious on its own, > asserts are a debugging tool), which crashes the application, so thats > no good. WTF, can you just give sample/link something? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 2:51 PM, Michael Niedermayer wrote: > On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: >> On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer >> wrote: >> > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: >> >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer >> >> wrote: >> >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >> >> >> The chroma format can be still unset in postinit when a badly cut >> >> >> stream >> >> >> starts with a slice instead of a sequence header. This is a common >> >> >> occurance when feeding avcodec from a Live TV stream. >> >> >> --- >> >> >> libavcodec/mpeg12dec.c | 1 - >> >> >> 1 file changed, 1 deletion(-) >> >> >> >> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >> >> >> index 5d916d1..b3c2c45 100644 >> >> >> --- a/libavcodec/mpeg12dec.c >> >> >> +++ b/libavcodec/mpeg12dec.c >> >> >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext >> >> >> *avctx) >> >> >> case 1: avctx->chroma_sample_location = >> >> >> AVCHROMA_LOC_LEFT; break; >> >> >> case 2: >> >> >> case 3: avctx->chroma_sample_location = >> >> >> AVCHROMA_LOC_TOPLEFT; break; >> >> >> -default: av_assert0(0); >> >> >> } >> >> >> } // MPEG-2 >> >> > >> >> > This assert double checks that the context init which uses >> >> > width/height/chroma format is done after the chroma format and w/h has >> >> > been read from the headers >> >> > if this is reached without the headers being read then the code is >> >> > buggy and removing the assert will not fix that bug >> >> > >> >> > also if there is no sequence header how is width/height set ? >> >> > theres a check for width/height before mpeg_decode_postinit is called >> >> > >> >> >> >> The dimensions are set by the caller in the avctx before opening the >> >> codec, which apparently inits the mpeg context as well. >> >> >> >> Feel free to fix it differently, error out or something, but I can >> >> trip an assert with input data, which should never happen. >> > >> > how can this be reproduced ? >> > >> >> I can only trigger it with API usage, not through the CLI tools, so I >> cannot produce a test case. > > is this with a unmodified up to date ffmpeg ? > i fixed this assert failing a while ago > (b54e03c9dc2a05324c08b503bfe7535c49c0f281) > > Its up to date, but slightly modified - but nothing pertinent to the mpeg2 decoder as far as I know. I'll just add this to the list of modifications then. I can clearly trigger this assert in a release build (which is hilarious on its own, asserts are a debugging tool), which crashes the application, so thats no good. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: runtime cpu detection for mips
imgtec.com> writes:
> +FILE *f = fopen("/proc/cpuinfo", "r");
Is this what every other software for mips does?
How does the kernel (or whatever sets cpuinfo) know?
Shivraj:- We have used generic cpuinfo as it is unrestricted to access from
user space compared to the kernel setting hwcaps (via low level mips control
regs accessible) in kernel space for now.
Thanks,
Carl Eugen
___
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] avutil: runtime cpu detection for mips
On Wed, Sep 30, 2015 at 07:03:46PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
[...]
> +static int get_cpuinfo(uint32_t *hwcap) {
> +FILE *f = fopen("/proc/cpuinfo", "r");
under qemu i get this:
cpu_flags(raw) = 0x
cpu_flags_str(raw) =
cpu_flags(effective) = 0x
cpu_flags_str(effective) =
threads = 1 (cpu_count = 12)
IIUC this disables all cpu extensions
is that intended ?
(we currently only have loongson hardware to test so this would mean an end to
testing imgtec specific mips optimizations)
Shivraj:- cpu detection will not work for qemu, however we have tested it on
mips hardware at our end.
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Avoid a single point of failure, be that a person or equipment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] qsvenc.c: use query function to catch all kind of setting issues
From 86ddf1095bfd557324f6eeb24d94cbd0a6818c10 Mon Sep 17 00:00:00 2001
From: Sven Dueking
Date: Wed, 30 Sep 2015 16:06:02 +0200
Subject: [FFmpeg-devel] [PATCH] qsvenc.c: use query function to catch all
kind of setting issues
---
libavcodec/qsvenc.c | 8
1 file changed, 8 insertions(+)
diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1013fe1..55140e1 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -264,6 +264,14 @@ int ff_qsv_enc_init(AVCodecContext *avctx,
QSVEncContext *q)
if (ret < 0)
return ret;
+ret = MFXVideoENCODE_Query(q->session, &q->param,&q->param);
+if (MFX_WRN_PARTIAL_ACCELERATION==ret) {
+av_log(avctx, AV_LOG_WARNING, "Encoder will work with partial HW
acceleration\n");
+} else if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Error %d querying encoder params\n",
ret);
+return ff_qsv_error(ret);
+}
+
ret = MFXVideoENCODE_QueryIOSurf(q->session, &q->param, &q->req);
if (ret < 0) {
av_log(avctx, AV_LOG_ERROR, "Error querying the encoding
parameters\n");
--
1.9.5.msysgit.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add maskedmerge filter
On 9/30/15, Nicolas George wrote: > Le quintidi 5 vendemiaire, an CCXXIV, Paul B Mahol a ecrit : >> +Merge first input stream with second input stream using per pixel weights >> in >> +the third input stream. 0 means that pixel component from first stream >> is >> +returned unchanged while 255 for 8-bit videos means that pixel component >> from >> +second stream is returned unchanged. > > If I read this correctly, it would be equivalent to: > > [second] [third] alphamerge [ov] ; > [first] [ov] overlay > > Am I mistaken? A few words in the doc to explain what the difference is > exactly would be useful. You are mistaken, overlay filter uses alpha plane to do blending for all other planes while this filter uses each plane in 3rd input to blend same planes in 1st and 2nd input. This should be obvious from existing documentation. > > Regards, > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] winrt: multithreading support
On Wed, Sep 30, 2015 at 09:54:37PM +0800, Wang Bin wrote:
> >
> > with minng64:
> > compat/w32pthreads.h:40:55: error: missing binary operator before token "("
>
>
> Which toolchain? What host os? Usually I use the toolchain from
x86_64-w64-mingw32-gcc (GCC) 4.6.3 on ubuntu
IIRC its the mingw shiped with ubntu LTS 12.04
> https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
> I can try mingw about 24h later on windows. I tested on osx with
> i686-w64-mingw32-gcc 4.9 just now and no such error.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- 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] avutil: runtime cpu detection for mips
On Wed, Sep 30, 2015 at 07:03:46PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil
[...]
> +static int get_cpuinfo(uint32_t *hwcap)
> +{
> +FILE *f = fopen("/proc/cpuinfo", "r");
under qemu i get this:
cpu_flags(raw) = 0x
cpu_flags_str(raw) =
cpu_flags(effective) = 0x
cpu_flags_str(effective) =
threads = 1 (cpu_count = 12)
IIUC this disables all cpu extensions
is that intended ?
(we currently only have loongson hardware to test so this would mean
an end to testing imgtec specific mips optimizations)
[...]
--
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] avfilter: add maskedmerge filter
Le quintidi 5 vendémiaire, an CCXXIV, Paul B Mahol a écrit : > +Merge first input stream with second input stream using per pixel weights in > +the third input stream. 0 means that pixel component from first stream is > +returned unchanged while 255 for 8-bit videos means that pixel component from > +second stream is returned unchanged. If I read this correctly, it would be equivalent to: [second] [third] alphamerge [ov] ; [first] [ov] overlay Am I mistaken? A few words in the doc to explain what the difference is exactly would be useful. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v3 2/8] configure: Add version check for libkvazaar
Signed-off-by: Arttu Ylä-Outinen
---
v3: Use pkg-config for checking the version.
v2: Add this patch.
---
configure |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/configure b/configure
index 361c024..ad4d71c 100755
--- a/configure
+++ b/configure
@@ -5272,7 +5272,7 @@ enabled libgsm&& { for gsm_hdr in "gsm.h"
"gsm/gsm.h"; do
check_lib "${gsm_hdr}" gsm_create -lgsm &&
break;
done || die "ERROR: libgsm not found"; }
enabled libilbc && require libilbc ilbc.h WebRtcIlbcfix_InitDecode
-lilbc
-enabled libkvazaar&& require_pkg_config kvazaar kvazaar.h kvz_api_get
+enabled libkvazaar&& require_pkg_config "kvazaar >= 0.7.0" kvazaar.h
kvz_api_get
enabled libmfx&& require_pkg_config libmfx "mfx/mfxvideo.h" MFXInit
enabled libmodplug&& require_pkg_config libmodplug
libmodplug/modplug.h ModPlug_Load
enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h
lame_set_VBR_quality -lmp3lame
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mp3: fix skipping zeros
On Wed, 30 Sep 2015 15:41:04 +0200 Michael Niedermayer wrote: > On Wed, Sep 30, 2015 at 02:54:11PM +0200, wm4 wrote: > > Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3 > > packets. (There are no explanations, no samples.) > > > > This code forgot to report to the user that data was skipped at all. IT > > should do this by adding the skipped amount of bytes to the amount of > > consumed bytes returned by the decode call. > > > > Since audio codecs allow partial packet decoding, the user application > > has to rely on the return value. It will remove the data reported as > > consumed by the decoder, and feed it to the decoder again. This resulted > > in the mp3 frame after the zero region to be decoded over and over > > again, until the zero region was finally skipped by the application. > > > > Fixes trac ticket #4890. > > --- > > libavcodec/mpegaudiodec_template.c | 4 +++- > > 1 file changed, 3 insertions(+), 1 deletion(-) > > LGTM > > thanks > > [...] Pushed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] winrt: multithreading support
>
> with minng64:
> compat/w32pthreads.h:40:55: error: missing binary operator before token "("
Which toolchain? What host os? Usually I use the toolchain from
https://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/
I can try mingw about 24h later on windows. I tested on osx with
i686-w64-mingw32-gcc 4.9 just now and no such error.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]select attribute of tee pseudo demuxer may contain multiple stream specifiers
Sorry for the delay.
Bodecs Bela:
> currently, select option of tee pseudo muxer may contain only one stream
> specifier. Sometimes I need to use more than one stream specifier.
> So I made the following patch. It makes possible to put multiple stream
> specifier into select option separated by comma.
> eg. select=\'a:0,v\'
> (I choose the comma character as separator because it is similar to tee's
> bsf option separator. bsf option allows multiple value separated by comma)
Thanks for the patch, the feature looks useful indeed.
> Please consider that put this patch into the official ffmpeg source tree.
> p.s.:the documentation/web also should alter by this, but I do not know
> where to send this:
>
> select
>
>Select the streams that should be mapped to the slave output,
>specified by a stream specifier. If not specified, this defaults to
>all the input streams.
It would be best to update the documentation in the same patch. The current
documentation is in doc/muxers.texi (can be found with
`git grep "Select the streams that should be mapped"`).
> Patch description:
Please use git send-email or git format-patch, so that the patch includes
author information and commit message. Also, the patch has been mangled by
your mail user agent, it can not be applied as is.
>
> diff -u tee.c.orig tee.c
> --- tee.c.orig 2015-07-09 22:22:27.0 +0200
> +++ tee.c 2015-09-25 13:15:15.763273903 +0200
> @@ -47,6 +47,7 @@
> static const char *const slave_opt_close = "]";
> static const char *const slave_opt_delim = ":]"; /* must have the close too
> */
> static const char *const slave_bsfs_spec_sep = "/";
> +static const char *const slave_select_sep = ",";
>
> static const AVClass tee_muxer_class = {
> .class_name = "Tee muxer",
> @@ -142,7 +143,9 @@
> AVFormatContext *avf2 = NULL;
> AVStream *st, *st2;
> int stream_count;
> -
> +int fullret;
> +char *subselect = NULL, *next_subselect = NULL, *first_subselect;
> +
> if ((ret = parse_slave_options(avf, slave, &options, &filename)) < 0)
> return ret;
>
> @@ -172,15 +175,26 @@
> for (i = 0; i < avf->nb_streams; i++) {
> st = avf->streams[i];
> if (select) {
> -ret = avformat_match_stream_specifier(avf, avf->streams[i],
> select);
> -if (ret < 0) {
> -av_log(avf, AV_LOG_ERROR,
> - "Invalid stream specifier '%s' for output '%s'\n",
> - select, slave);
> -goto end;
> -}
> +fullret = 0;
> +first_subselect = select;
> +next_subselect = NULL;
> +while (subselect = strtok_r(first_subselect, slave_select_sep,
> &next_subselect)) {
strtok_r() is not portable enough, but libavutil provides av_strtok().
> +first_subselect = NULL;
> +
> +ret = avformat_match_stream_specifier(avf, avf->streams[i],
> subselect);
> +if (ret < 0) {
> +av_log(avf, AV_LOG_ERROR,
> +"Invalid stream specifier '%s' for output '%s'\n",
> +subselect, slave);
> +goto end;
> +}
> +if (ret != 0) {
> +fullret = 1; // match
> +break;
> +}
>
> -if (ret == 0) { /* no match */
> +}
> +if (fullret == 0) { /* no match */
> tee_slave->stream_map[i] = -1;
> continue;
> }
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/mp3: fix skipping zeros
On Wed, Sep 30, 2015 at 02:54:11PM +0200, wm4 wrote: > Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3 > packets. (There are no explanations, no samples.) > > This code forgot to report to the user that data was skipped at all. IT > should do this by adding the skipped amount of bytes to the amount of > consumed bytes returned by the decode call. > > Since audio codecs allow partial packet decoding, the user application > has to rely on the return value. It will remove the data reported as > consumed by the decoder, and feed it to the decoder again. This resulted > in the mp3 frame after the zero region to be decoded over and over > again, until the zero region was finally skipped by the application. > > Fixes trac ticket #4890. > --- > libavcodec/mpegaudiodec_template.c | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) LGTM thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avutil: runtime cpu detection for mips
imgtec.com> writes:
> +FILE *f = fopen("/proc/cpuinfo", "r");
Is this what every other software for mips does?
How does the kernel (or whatever sets cpuinfo) know?
Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter/vf_tinterlace: add mergex2 mode
Signed-off-by: Paul B Mahol
---
doc/filters.texi| 24
libavfilter/tinterlace.h| 1 +
libavfilter/vf_tinterlace.c | 13 ++---
3 files changed, 35 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index a4d828e..0a8588d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -10774,6 +10774,30 @@ Output:
1 1 2 2 3 3 4
@end example
+@item mergex2, 7
+Move odd frames into the upper field, even into the lower field,
+generating a double height frame at same frame rate.
+@example
+ --> time
+Input:
+Frame 1 Frame 2 Frame 3 Frame 4
+
+1 2 3 4
+1 2 3 4
+1 2 3 4
+1 2 3 4
+
+Output:
+1 2 3 4
+2 3 4 5
+1 2 3 4
+2 3 4 5
+1 2 3 4
+2 3 4 5
+1 2 3 4
+2 3 4 5
+@end example
+
@end table
diff --git a/libavfilter/tinterlace.h b/libavfilter/tinterlace.h
index d80a6e2..3b703e7 100644
--- a/libavfilter/tinterlace.h
+++ b/libavfilter/tinterlace.h
@@ -38,6 +38,7 @@ enum TInterlaceMode {
MODE_INTERLEAVE_TOP,
MODE_INTERLEAVE_BOTTOM,
MODE_INTERLACEX2,
+MODE_MERGEX2,
MODE_NB,
};
diff --git a/libavfilter/vf_tinterlace.c b/libavfilter/vf_tinterlace.c
index 4bdcd45..a86bf11 100644
--- a/libavfilter/vf_tinterlace.c
+++ b/libavfilter/vf_tinterlace.c
@@ -46,6 +46,7 @@ static const AVOption tinterlace_options[] = {
{"interleave_top","interleave top and bottom fields", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_TOP},INT_MIN, INT_MAX, FLAGS,
"mode"},
{"interleave_bottom", "interleave bottom and top fields", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLEAVE_BOTTOM}, INT_MIN, INT_MAX, FLAGS,
"mode"},
{"interlacex2", "interlace fields from two consecutive frames", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_INTERLACEX2}, INT_MIN, INT_MAX, FLAGS,
"mode"},
+{"mergex2", "merge fields keeping same frame rate", 0,
AV_OPT_TYPE_CONST, {.i64=MODE_MERGEX2}, INT_MIN, INT_MAX, FLAGS,
"mode"},
{"flags", "set flags", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64
= 0}, 0, INT_MAX, 0, "flags" },
{"low_pass_filter", "enable vertical low-pass filter", 0,
AV_OPT_TYPE_CONST, {.i64 = TINTERLACE_FLAG_VLPF}, INT_MIN, INT_MAX, FLAGS,
"flags" },
@@ -118,9 +119,9 @@ static int config_out_props(AVFilterLink *outlink)
tinterlace->vsub = desc->log2_chroma_h;
outlink->w = inlink->w;
-outlink->h = tinterlace->mode == MODE_MERGE || tinterlace->mode ==
MODE_PAD ?
+outlink->h = tinterlace->mode == MODE_MERGE || tinterlace->mode ==
MODE_PAD || tinterlace->mode == MODE_MERGEX2?
inlink->h*2 : inlink->h;
-if (tinterlace->mode == MODE_MERGE || tinterlace->mode == MODE_PAD)
+if (tinterlace->mode == MODE_MERGE || tinterlace->mode == MODE_PAD ||
tinterlace->mode == MODE_MERGEX2)
outlink->sample_aspect_ratio = av_mul_q(inlink->sample_aspect_ratio,
av_make_q(2, 1));
@@ -153,6 +154,9 @@ static int config_out_props(AVFilterLink *outlink)
tinterlace->preout_time_base.den *= 2;
outlink->frame_rate = av_mul_q(inlink->frame_rate, (AVRational){2,1});
outlink->time_base = av_mul_q(inlink->time_base , (AVRational){1,2});
+} else if (tinterlace->mode == MODE_MERGEX2) {
+outlink->frame_rate = inlink->frame_rate;
+outlink->time_base = inlink->time_base;
} else if (tinterlace->mode != MODE_PAD) {
outlink->frame_rate = av_mul_q(inlink->frame_rate, (AVRational){1,2});
outlink->time_base = av_mul_q(inlink->time_base , (AVRational){2,1});
@@ -259,6 +263,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
return 0;
switch (tinterlace->mode) {
+case MODE_MERGEX2: /* move the odd frame into the upper field of the new
image, even into
+* the lower field, generating a double-height video at
same framerate */
case MODE_MERGE: /* move the odd frame into the upper field of the new
image, even into
* the lower field, generating a double-height video at half
framerate */
out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
@@ -280,7 +286,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*picref)
(const uint8_t **)next->data, next->linesize,
[FFmpeg-devel] [PATCH] avutil: runtime cpu detection for mips
From: Shivraj Patil
Signed-off-by: Shivraj Patil
---
libavcodec/mips/hevcdsp_init_mips.c |6 +-
libavutil/cpu.c | 35 ++
libavutil/cpu.h |8 +++
libavutil/cpu_internal.h|1 +
libavutil/mips/Makefile |1 +
libavutil/mips/cpu.c| 124 +++
libavutil/mips/cpu.h| 36 ++
7 files changed, 210 insertions(+), 1 deletion(-)
create mode 100644 libavutil/mips/cpu.c
create mode 100644 libavutil/mips/cpu.h
diff --git a/libavcodec/mips/hevcdsp_init_mips.c
b/libavcodec/mips/hevcdsp_init_mips.c
index 3675b93..499d2e8 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -19,6 +19,7 @@
*/
#include "libavcodec/mips/hevcdsp_mips.h"
+#include "libavutil/mips/cpu.h"
#if HAVE_MSA
static av_cold void hevc_dsp_init_msa(HEVCDSPContext *c,
@@ -449,6 +450,9 @@ static av_cold void hevc_dsp_init_msa(HEVCDSPContext *c,
void ff_hevc_dsp_init_mips(HEVCDSPContext *c, const int bit_depth)
{
#if HAVE_MSA
-hevc_dsp_init_msa(c, bit_depth);
+int cpu_flags = av_get_cpu_flags();
+
+if (have_msa(cpu_flags))
+hevc_dsp_init_msa(c, bit_depth);
#endif // #if HAVE_MSA
}
diff --git a/libavutil/cpu.c b/libavutil/cpu.c
index 780368d..1e716c6 100644
--- a/libavutil/cpu.c
+++ b/libavutil/cpu.c
@@ -86,6 +86,8 @@ int av_get_cpu_flags(void)
flags = ff_get_cpu_flags_ppc();
if (ARCH_X86)
flags = ff_get_cpu_flags_x86();
+if (ARCH_MIPS)
+flags = ff_get_cpu_flags_mips();
checked = 1;
return flags;
@@ -156,6 +158,17 @@ int av_parse_cpu_flags(const char *s)
{ "armv8",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV8
},.unit = "flags" },
{ "neon", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_NEON
},.unit = "flags" },
{ "vfp", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_VFP
},.unit = "flags" },
+#elif ARCH_MIPS
+{ "mipsfpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MIPSFPU
}, .unit = "flags" },
+{ "mips32r2", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS32R2 }, .unit = "flags" },
+{ "mips32r5", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS32R5 }, .unit = "flags" },
+{ "dspr1",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPSDSPR1 }, .unit = "flags" },
+{ "dspr2",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPSDSPR2 }, .unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
}, .unit = "flags" },
+#elif ARCH_MIPS64
+{ "mipsfpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MIPSFPU
}, .unit = "flags" },
+{ "mips64r6", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS64R6 }, .unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
}, .unit = "flags" },
#endif
{ NULL },
};
@@ -234,6 +247,17 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
{ "armv8",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_ARMV8
},.unit = "flags" },
{ "neon", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_NEON
},.unit = "flags" },
{ "vfp", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_VFP
},.unit = "flags" },
+#elif ARCH_MIPS
+{ "mipsfpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MIPSFPU
}, .unit = "flags" },
+{ "mips32r2", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS32R2 }, .unit = "flags" },
+{ "mips32r5", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS32R5 }, .unit = "flags" },
+{ "dspr1",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPSDSPR1 }, .unit = "flags" },
+{ "dspr2",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPSDSPR2 }, .unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
}, .unit = "flags" },
+#elif ARCH_MIPS64
+{ "mipsfpu", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MIPSFPU
}, .unit = "flags" },
+{ "mips64r6", NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
AV_CPU_FLAG_MIPS64R6 }, .unit = "flags" },
+{ "msa", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = AV_CPU_FLAG_MSA
}, .unit = "flags" },
#endif
{ NULL },
};
@@ -334,6 +358,17 @@ static const struct {
{ AV_CPU_FLAG_AVX2, "avx2" },
{ AV_CPU_FLAG_BMI1, "bmi1" },
{ AV_CPU_FLAG_BMI2, "bmi2" },
+#elif ARCH_MIPS
+{ AV_CPU_FLAG_MIPSFPU, "mipsfpu"},
+{ AV_CPU_FLAG_MIPS32R2, "mips32r2" },
+{ AV_CPU_FLAG_MIPS32R5, "mips32r5" },
+{ AV_CPU_FLAG_MIPSDSPR1, "dspr1" },
+{ AV_CPU_FLAG_MIPSDSPR2, "dspr2" },
+{ AV_CPU_FLAG_MSA, "msa"},
+#elif ARCH_MIPS64
+{
Re: [FFmpeg-devel] [PATCH v2 2/8] configure: Add version check for libkvazaar
On 2015-09-29 22:42, Hendrik Leppkes wrote:
On Tue, Sep 29, 2015 at 9:39 PM, Carl Eugen Hoyos wrote:
Clément Bœsch pkh.me> writes:
+ { check_cpp_condition kvazaar.h "KVZ_API_VERSION >= 7" ||
+ die "ERROR: kvazaar API version must be at least 7."; }
Can you do something like require_pkg_config "kvazaar >= 1.2.3" instead?
Please don't!
This only adds an unneeded requirement (and a regression)
to the library
It already requires pkg-config, all Clement is asking to also use it
to check the version, which makes a lot of sense.
Its also much more visible for users. API versions aren't meaningful
to users, while actual library versions are.
I'll change the patch to use pkg-config for the version check then.
Thanks for the comments.
- Arttu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: 10/12bpp SIMD (sse2/ssse3/avx) for directional intra prediction.
---
libavcodec/x86/vp9dsp_init.h |4 +
libavcodec/x86/vp9dsp_init_16bpp.c| 33 +
libavcodec/x86/vp9intrapred_16bpp.asm | 1613 +
3 files changed, 1650 insertions(+)
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 47d2246..5842282 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -165,6 +165,10 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
init_ipred_func(type, enum, 16, bpp, opt); \
init_ipred_func(type, enum, 32, bpp, opt)
+#define init_ipred_funcs(type, enum, bpp, opt) \
+init_ipred_func(type, enum, 4, bpp, opt); \
+init_8_16_32_ipred_funcs(type, enum, bpp, opt)
+
void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp);
void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp);
diff --git a/libavcodec/x86/vp9dsp_init_16bpp.c
b/libavcodec/x86/vp9dsp_init_16bpp.c
index f4a4a5d..4ceb4d4 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp.c
@@ -51,6 +51,18 @@ decl_ipred_fns(h, 16, mmxext, sse2);
decl_ipred_fns(dc, 16, mmxext, sse2);
decl_ipred_fns(dc_top, 16, mmxext, sse2);
decl_ipred_fns(dc_left, 16, mmxext, sse2);
+
+#define decl_ipred_dir_funcs(type) \
+decl_ipred_fns(type, 16, sse2, sse2); \
+decl_ipred_fns(type, 16, ssse3, ssse3); \
+decl_ipred_fns(type, 16, avx, avx)
+
+decl_ipred_dir_funcs(dl);
+decl_ipred_dir_funcs(dr);
+decl_ipred_dir_funcs(vl);
+decl_ipred_dir_funcs(vr);
+decl_ipred_dir_funcs(hu);
+decl_ipred_dir_funcs(hd);
#endif /* HAVE_YASM */
av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
@@ -88,12 +100,33 @@ av_cold void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp)
init_8_16_32_ipred_funcs(dc, DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_top, TOP_DC, 16, sse2);
init_8_16_32_ipred_funcs(dc_left, LEFT_DC, 16, sse2);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, sse2);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, sse2);
+init_ipred_funcs(vl, VERT_LEFT, 16, sse2);
+init_ipred_funcs(vr, VERT_RIGHT, 16, sse2);
+init_ipred_funcs(hu, HOR_UP, 16, sse2);
+init_ipred_funcs(hd, HOR_DOWN, 16, sse2);
+}
+
+if (EXTERNAL_SSSE3(cpu_flags)) {
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, ssse3);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, ssse3);
+init_ipred_funcs(vl, VERT_LEFT, 16, ssse3);
+init_ipred_funcs(vr, VERT_RIGHT, 16, ssse3);
+init_ipred_funcs(hu, HOR_UP, 16, ssse3);
+init_ipred_funcs(hd, HOR_DOWN, 16, ssse3);
}
if (EXTERNAL_AVX_FAST(cpu_flags)) {
init_fpel_func(2, 0, 32, put, , avx);
init_fpel_func(1, 0, 64, put, , avx);
init_fpel_func(0, 0, 128, put, , avx);
+init_ipred_funcs(dl, DIAG_DOWN_LEFT, 16, avx);
+init_ipred_funcs(dr, DIAG_DOWN_RIGHT, 16, avx);
+init_ipred_funcs(vl, VERT_LEFT, 16, avx);
+init_ipred_funcs(vr, VERT_RIGHT, 16, avx);
+init_ipred_funcs(hu, HOR_UP, 16, avx);
+init_ipred_funcs(hd, HOR_DOWN, 16, avx);
}
if (EXTERNAL_AVX2(cpu_flags)) {
diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 6da42cf..d5d5ca0 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -27,6 +27,11 @@ SECTION_RODATA 32
pd_2: times 8 dd 2
pd_4: times 8 dd 4
pd_8: times 8 dd 8
+pd_65535: times 8 dd 0x
+
+pb_2to15_14_15: db 2,3,4,5,6,7,8,9,10,11,12,13,14,15,14,15
+pb_4_5_8to13_8x0: db 4,5,8,9,10,11,12,13,0,0,0,0,0,0,0,0
+pb_0to7_67x4: db 0,1,2,3,4,5,6,7,6,7,6,7,6,7,6,7
cextern pw_1
cextern pw_1023
@@ -34,8 +39,48 @@ cextern pw_4095
cextern pd_16
cextern pd_32
+; FIXME most top-only functions (ddl, vl, v, dc_top) can be modified to take
+; only 3 registers on x86-32, which would make it one cycle faster, but that
+; would make the code quite a bit uglier...
+
SECTION .text
+%macro SCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%if %0 == 4
+%define reg_%4 m%2
+%endif
+%else
+mova [%3], m%1
+%if %0 == 4
+%define reg_%4 [%3]
+%endif
+%endif
+%endmacro
+
+%macro UNSCRATCH 3-4
+%if ARCH_X86_64
+SWAP%1, %2
+%else
+mova m%1, [%3]
+%endif
+%if %0 == 4
+%undef reg_%4
+%endif
+%endmacro
+
+%macro PRELOAD 2-3
+%if ARCH_X86_64
+mova m%1, [%2]
+%if %0 == 3
+%define reg_%3 m%1
+%endif
+%elif %0 == 3
+%define reg_%3 [%2]
+%endif
+%endmacro
+
INIT_MMX mmx
cglobal vp9_ipred_v_4x4_16, 2, 4, 1, dst, stride, l, a
movifnidn aq, amp
@@ -669,3 +714,1571 @@ cglobal vp9_ipred_tm_32x32_10, 4, 5, 10, 32 *
ARCH_X86_32, dst, stride, l, a
cglobal vp9_ipred_tm_32x32_12, 4, 5, 10, 32 * ARCH_X86_32, dst, stride, l, a
movam0, [pw_4095]
jmp mangle(private_prefix %+ _ %+ vp9_ipred_tm_32x32_10 %+ SUFFIX).body
+
+; Directional intra predi
Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: Add parsing for DDTS atom for DTS audio
On Wed, Sep 30, 2015 at 02:17:02PM +0900, Yusuke Nakamura wrote:
> 2015-09-30 6:44 GMT+09:00 Shawn Singh :
>
> > The DDTS atom is defined in ETSI TS 102 114, v1.4.1, Annex E.
> > This is useful for DTS-HD formats, some of which cannot be
> > decoded by dcadec.c or libdcadec.
> >
>
> How useful?
> DTS audio has scalability, and 'ddts' box indicates only one of properties
> of the stream.
>
>
> >
> > Signed-off-by: Shawn Singh
> > ---
> > libavformat/mov.c | 56
> > +++
> > 1 file changed, 56 insertions(+)
> >
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index c57aaeb..da170a6 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -744,6 +744,61 @@ static int mov_read_dec3(MOVContext *c, AVIOContext
> > *pb, MOVAtom atom)
> > return 0;
> > }
> >
> > +static int mov_read_ddts(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> > +{
> > +const uint32_t ddts_size = 20;
> > +AVStream *st = NULL;
> > +uint8_t *buf = NULL;
> > +uint32_t frame_duration_code = 0;
> > +uint32_t channel_layout_code = 0;
> > +GetBitContext gb;
> > +
> > +buf = av_malloc(ddts_size + FF_INPUT_BUFFER_PADDING_SIZE);
> > +if (!buf) {
> > +return AVERROR(ENOMEM);
> > +}
> > +if (avio_read(pb, buf, ddts_size) < ddts_size) {
> > +av_free(buf);
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +init_get_bits(&gb, buf, 8*ddts_size);
> > +
> > +if (c->fc->nb_streams < 1) {
> > +return 0;
> > +}
> > +st = c->fc->streams[c->fc->nb_streams-1];
> > +
> > +st->codec->sample_rate = get_bits_long(&gb, 32);
> > +skip_bits_long(&gb, 32); /* max bitrate */
> > +st->codec->bit_rate = get_bits_long(&gb, 32);
> > +st->codec->bits_per_coded_sample = get_bits(&gb, 8);
> >
>
> This field is set to 0 as a reserved field if the file is compatible with
> Ultra Violet's Common File Format (CFF).
> I prefer that the reference about this is here.
>
>
> > +frame_duration_code = get_bits(&gb, 2);
> > +skip_bits(&gb, 30); /* various fields */
> > +channel_layout_code = get_bits(&gb, 16);
> > +
> > +st->codec->frame_size =
> > +(frame_duration_code == 0) ? 512 :
> > +(frame_duration_code == 1) ? 1024 :
> > +(frame_duration_code == 2) ? 2048 :
> > +(frame_duration_code == 3) ? 4096 : 0;
> >
>
> Wrong if LBRDurationMod is set to 1.
if you think its better to revert this patch, just say so and ill
revert
[...]
--
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
[FFmpeg-devel] [PATCH] avcodec/mp3: fix skipping zeros
Commits 43bc5cf9 and c5371f77 add code for skipping initial zeros in mp3
packets. (There are no explanations, no samples.)
This code forgot to report to the user that data was skipped at all. IT
should do this by adding the skipped amount of bytes to the amount of
consumed bytes returned by the decode call.
Since audio codecs allow partial packet decoding, the user application
has to rely on the return value. It will remove the data reported as
consumed by the decoder, and feed it to the decoder again. This resulted
in the mp3 frame after the zero region to be decoded over and over
again, until the zero region was finally skipped by the application.
Fixes trac ticket #4890.
---
libavcodec/mpegaudiodec_template.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpegaudiodec_template.c
b/libavcodec/mpegaudiodec_template.c
index b7b9dbd..0f32ac7 100644
--- a/libavcodec/mpegaudiodec_template.c
+++ b/libavcodec/mpegaudiodec_template.c
@@ -1657,9 +1657,11 @@ static int decode_frame(AVCodecContext * avctx, void
*data, int *got_frame_ptr,
uint32_t header;
int ret;
+int skipped = 0;
while(buf_size && !*buf){
buf++;
buf_size--;
+skipped++;
}
if (buf_size < HEADER_SIZE)
@@ -1714,7 +1716,7 @@ static int decode_frame(AVCodecContext * avctx, void
*data, int *got_frame_ptr,
return ret;
}
s->frame_size = 0;
-return buf_size;
+return buf_size + skipped;
}
static void mp_flush(MPADecodeContext *ctx)
--
2.5.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 02:39:21PM +0200, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer wrote: > > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: > >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer > >> wrote: > >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: > >> >> The chroma format can be still unset in postinit when a badly cut stream > >> >> starts with a slice instead of a sequence header. This is a common > >> >> occurance when feeding avcodec from a Live TV stream. > >> >> --- > >> >> libavcodec/mpeg12dec.c | 1 - > >> >> 1 file changed, 1 deletion(-) > >> >> > >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > >> >> index 5d916d1..b3c2c45 100644 > >> >> --- a/libavcodec/mpeg12dec.c > >> >> +++ b/libavcodec/mpeg12dec.c > >> >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext > >> >> *avctx) > >> >> case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; > >> >> break; > >> >> case 2: > >> >> case 3: avctx->chroma_sample_location = > >> >> AVCHROMA_LOC_TOPLEFT; break; > >> >> -default: av_assert0(0); > >> >> } > >> >> } // MPEG-2 > >> > > >> > This assert double checks that the context init which uses > >> > width/height/chroma format is done after the chroma format and w/h has > >> > been read from the headers > >> > if this is reached without the headers being read then the code is > >> > buggy and removing the assert will not fix that bug > >> > > >> > also if there is no sequence header how is width/height set ? > >> > theres a check for width/height before mpeg_decode_postinit is called > >> > > >> > >> The dimensions are set by the caller in the avctx before opening the > >> codec, which apparently inits the mpeg context as well. > >> > >> Feel free to fix it differently, error out or something, but I can > >> trip an assert with input data, which should never happen. > > > > how can this be reproduced ? > > > > I can only trigger it with API usage, not through the CLI tools, so I > cannot produce a test case. is this with a unmodified up to date ffmpeg ? i fixed this assert failing a while ago (b54e03c9dc2a05324c08b503bfe7535c49c0f281) > Just replace the assert with a error return, that should cover everything. > > - Hendrik > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Its not that you shouldnt use gotos but rather that you should write readable code and code with gotos often but not always is less readable signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] h264_parser: force fetching a new timestamp until a frame start was found
On Wed, Sep 30, 2015 at 01:04:15PM +0200, Hendrik Leppkes wrote: > This fixes broken timestamps on streams where the SPS/PPS is at the end of > the previous packet, instead of in front of the next packet, observed in > badly packetized MPEG-TS streams. > --- > libavcodec/h264_parser.c | 3 +++ > 1 file changed, 3 insertions(+) this breaks seekbug01min.ts https://trac.ffmpeg.org/raw-attachment/ticket/399/seekbug01min.ts ./ffmpeg -copyts -i seekbug01min.ts -vf showinfo -f null - after the patch: [Parsed_showinfo_0 @ 0x299f840] n: 3 pts: 141000 pts_time:1.56667 pos: 2068 fmt:yuv420p sar:1/1 s:320x180 i:P iskey:0 type:P checksum:23FCE60B plane_checksum:[C04510D2 B48EEA95 B48EEA95] mean:[16 127 127] stdev:[0.0 0.1 0.1] [Parsed_showinfo_0 @ 0x299f840] n: 4 pts: 141000 pts_time:1.56667 pos: 2068 fmt:yuv420p sar:1/1 s:320x180 i:P iskey:0 type:P checksum:132E017E plane_checksum:[39A04B6E AC0DD439 233EE1B9] mean:[16 127 127] stdev:[0.4 0.5 0.4] [null @ 0x299e0c0] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 38 >= 38 -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Opposition brings concord. Out of discord comes the fairest harmony. -- Heraclitus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
The chroma format can be still unset in postinit when a badly cut stream starts with a slice instead of a sequence header. This is a common occurance when feeding avcodec from a Live TV stream. --- libavcodec/mpeg12dec.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index 5d916d1..76bf60f 100644 --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -1389,7 +1389,7 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; break; case 2: case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; break; -default: av_assert0(0); +default: return AVERROR(EINVAL); } } // MPEG-2 -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 2:33 PM, Michael Niedermayer wrote: > On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: >> On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer >> wrote: >> > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >> >> The chroma format can be still unset in postinit when a badly cut stream >> >> starts with a slice instead of a sequence header. This is a common >> >> occurance when feeding avcodec from a Live TV stream. >> >> --- >> >> libavcodec/mpeg12dec.c | 1 - >> >> 1 file changed, 1 deletion(-) >> >> >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >> >> index 5d916d1..b3c2c45 100644 >> >> --- a/libavcodec/mpeg12dec.c >> >> +++ b/libavcodec/mpeg12dec.c >> >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext >> >> *avctx) >> >> case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; >> >> break; >> >> case 2: >> >> case 3: avctx->chroma_sample_location = >> >> AVCHROMA_LOC_TOPLEFT; break; >> >> -default: av_assert0(0); >> >> } >> >> } // MPEG-2 >> > >> > This assert double checks that the context init which uses >> > width/height/chroma format is done after the chroma format and w/h has >> > been read from the headers >> > if this is reached without the headers being read then the code is >> > buggy and removing the assert will not fix that bug >> > >> > also if there is no sequence header how is width/height set ? >> > theres a check for width/height before mpeg_decode_postinit is called >> > >> >> The dimensions are set by the caller in the avctx before opening the >> codec, which apparently inits the mpeg context as well. >> >> Feel free to fix it differently, error out or something, but I can >> trip an assert with input data, which should never happen. > > how can this be reproduced ? > I can only trigger it with API usage, not through the CLI tools, so I cannot produce a test case. Just replace the assert with a error return, that should cover everything. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct
On Wed, 30 Sep 2015 13:55:26 +0200
Hendrik Leppkes wrote:
> On Wed, Sep 30, 2015 at 1:16 PM, wm4 wrote:
> > On Wed, 30 Sep 2015 13:09:01 +0200
> > Hendrik Leppkes wrote:
> >
> >> The parser only reads the dca core sample rate, which is limited to a
> >> maximum of 48000 Hz, while X96 and HD extensions can increase the sample
> >> rate up to 192000 Hz.
> >>
> >> This change prevents the parser and decoder fighting over the sample rate,
> >> potentially confusing user applications. This also fixes sample rate
> >> display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.
> >> ---
> >> libavcodec/dca_parser.c | 1 -
> >> 1 file changed, 1 deletion(-)
> >>
> >> diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
> >> index 337a99d..70e64a8 100644
> >> --- a/libavcodec/dca_parser.c
> >> +++ b/libavcodec/dca_parser.c
> >> @@ -166,7 +166,6 @@ static int dca_parse(AVCodecParserContext *s,
> >> AVCodecContext *avctx,
> >> /* read the duration and sample rate from the frame header */
> >> if (!dca_parse_params(buf, buf_size, &duration, &sample_rate,
> >> &pc1->framesize)) {
> >> s->duration= duration;
> >> -avctx->sample_rate = sample_rate;
> >> } else
> >> s->duration = 0;
> >>
> >
> > So in which situations do decoder and parser share the AVCodecContext
> > at all? In libavformat?
>
> Yes, and it results in probing reporting the wrong sample rate right now.
That's scary (running the decoder in libavformat I mean), but I suppose
there's no better fix for now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 02:29:43PM +0200, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer wrote: > > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: > >> The chroma format can be still unset in postinit when a badly cut stream > >> starts with a slice instead of a sequence header. This is a common > >> occurance when feeding avcodec from a Live TV stream. > >> --- > >> libavcodec/mpeg12dec.c | 1 - > >> 1 file changed, 1 deletion(-) > >> > >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > >> index 5d916d1..b3c2c45 100644 > >> --- a/libavcodec/mpeg12dec.c > >> +++ b/libavcodec/mpeg12dec.c > >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext > >> *avctx) > >> case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; > >> break; > >> case 2: > >> case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; > >> break; > >> -default: av_assert0(0); > >> } > >> } // MPEG-2 > > > > This assert double checks that the context init which uses > > width/height/chroma format is done after the chroma format and w/h has > > been read from the headers > > if this is reached without the headers being read then the code is > > buggy and removing the assert will not fix that bug > > > > also if there is no sequence header how is width/height set ? > > theres a check for width/height before mpeg_decode_postinit is called > > > > The dimensions are set by the caller in the avctx before opening the > codec, which apparently inits the mpeg context as well. > > Feel free to fix it differently, error out or something, but I can > trip an assert with input data, which should never happen. how can this be reproduced ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 2:29 PM, Hendrik Leppkes wrote: > On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer wrote: >> On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >>> The chroma format can be still unset in postinit when a badly cut stream >>> starts with a slice instead of a sequence header. This is a common >>> occurance when feeding avcodec from a Live TV stream. >>> --- >>> libavcodec/mpeg12dec.c | 1 - >>> 1 file changed, 1 deletion(-) >>> >>> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >>> index 5d916d1..b3c2c45 100644 >>> --- a/libavcodec/mpeg12dec.c >>> +++ b/libavcodec/mpeg12dec.c >>> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) >>> case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; >>> break; >>> case 2: >>> case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; >>> break; >>> -default: av_assert0(0); >>> } >>> } // MPEG-2 >> >> This assert double checks that the context init which uses >> width/height/chroma format is done after the chroma format and w/h has >> been read from the headers >> if this is reached without the headers being read then the code is >> buggy and removing the assert will not fix that bug >> >> also if there is no sequence header how is width/height set ? >> theres a check for width/height before mpeg_decode_postinit is called >> > > The dimensions are set by the caller in the avctx before opening the > codec, which apparently inits the mpeg context as well. > > Feel free to fix it differently, error out or something, but I can > trip an assert with input data, which should never happen. Just to amend - after the fix it works perfectly fine again. It errors out on a bunch of frames of course later on, but then it fixes itself and decodes the Live TV stream like usual. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 2:10 PM, Michael Niedermayer wrote: > On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: >> The chroma format can be still unset in postinit when a badly cut stream >> starts with a slice instead of a sequence header. This is a common >> occurance when feeding avcodec from a Live TV stream. >> --- >> libavcodec/mpeg12dec.c | 1 - >> 1 file changed, 1 deletion(-) >> >> diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c >> index 5d916d1..b3c2c45 100644 >> --- a/libavcodec/mpeg12dec.c >> +++ b/libavcodec/mpeg12dec.c >> @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) >> case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; >> break; >> case 2: >> case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; >> break; >> -default: av_assert0(0); >> } >> } // MPEG-2 > > This assert double checks that the context init which uses > width/height/chroma format is done after the chroma format and w/h has > been read from the headers > if this is reached without the headers being read then the code is > buggy and removing the assert will not fix that bug > > also if there is no sequence header how is width/height set ? > theres a check for width/height before mpeg_decode_postinit is called > The dimensions are set by the caller in the avctx before opening the codec, which apparently inits the mpeg context as well. Feel free to fix it differently, error out or something, but I can trip an assert with input data, which should never happen. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/f_ebur128: add dualmono measurement option
On Mon, Sep 28, 2015 at 10:32:28AM -0500, Kyle Swanson wrote:
> > questions:
> >
> > - what happens if you resample the input (by prefixing ebur128 with
> > aformat=channel_layout=stereo)?
> > - if I'm reading the blog correctly ("Note that In my discussions with
> > leading experts in the space, it has come to my attention that this
> > approach may not be sustainable. Many pros feel it is the responsibility
> > of the playback device and/or delivery system to apply the necessary
> > compensation.") this is not a standard behaviour at all. Do you confirm
> > this?
>
> ffmpeg -nostats -i mono.wav -filter_complex
> "aformat=channel_layouts=stereo,ebur128" -f null -
> does not give the appropriate output. It looks like
> `channel_layouts=stereo` is intelligent enough to
> apply pan law gain to each channel before remapping, but this results
> in the same inaccurate loudness
> measurement. A `dualmono=true` flag is convenient way to use the same
> ffmpeg call to measure
> loudness for all files, including multichannel files beyond stereo.
>
> See also: a similar option is enabled by default in R128GAIN -
> http://r128gain.sourceforge.net/
>
OK. I will test & apply this week-end unless you're in a hurry. In the
meantime, maybe just drop the V flag in the options (these options are
related to the audio only).
Thanks, and sorry of the delay
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On Wed, Sep 30, 2015 at 12:42:59PM +0200, Hendrik Leppkes wrote: > The chroma format can be still unset in postinit when a badly cut stream > starts with a slice instead of a sequence header. This is a common > occurance when feeding avcodec from a Live TV stream. > --- > libavcodec/mpeg12dec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > index 5d916d1..b3c2c45 100644 > --- a/libavcodec/mpeg12dec.c > +++ b/libavcodec/mpeg12dec.c > @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) > case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; break; > case 2: > case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; > break; > -default: av_assert0(0); > } > } // MPEG-2 This assert double checks that the context init which uses width/height/chroma format is done after the chroma format and w/h has been read from the headers if this is reached without the headers being read then the code is buggy and removing the assert will not fix that bug also if there is no sequence header how is width/height set ? theres a check for width/height before mpeg_decode_postinit is called [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Complexity theory is the science of finding the exact solution to an approximation. Benchmarking OTOH is finding an approximation of the exact signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct
On Wed, Sep 30, 2015 at 1:16 PM, wm4 wrote:
> On Wed, 30 Sep 2015 13:09:01 +0200
> Hendrik Leppkes wrote:
>
>> The parser only reads the dca core sample rate, which is limited to a
>> maximum of 48000 Hz, while X96 and HD extensions can increase the sample
>> rate up to 192000 Hz.
>>
>> This change prevents the parser and decoder fighting over the sample rate,
>> potentially confusing user applications. This also fixes sample rate
>> display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.
>> ---
>> libavcodec/dca_parser.c | 1 -
>> 1 file changed, 1 deletion(-)
>>
>> diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
>> index 337a99d..70e64a8 100644
>> --- a/libavcodec/dca_parser.c
>> +++ b/libavcodec/dca_parser.c
>> @@ -166,7 +166,6 @@ static int dca_parse(AVCodecParserContext *s,
>> AVCodecContext *avctx,
>> /* read the duration and sample rate from the frame header */
>> if (!dca_parse_params(buf, buf_size, &duration, &sample_rate,
>> &pc1->framesize)) {
>> s->duration= duration;
>> -avctx->sample_rate = sample_rate;
>> } else
>> s->duration = 0;
>>
>
> So in which situations do decoder and parser share the AVCodecContext
> at all? In libavformat?
Yes, and it results in probing reporting the wrong sample rate right now.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter
Paul B Mahol gmail.com> writes: > +Scale (resize) the input video, using the z.lib library: > +https://github.com/sekrit-twc/zimg. Sorry for the nit: Please remove the dot at the end. The filter cannot work for gray (and alpha) formats? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration
> I'm not quite sure of what I think of this software/opencl hybrid > approach. On one hand, it's good that they share the "user interface" > (options etc.). On the other hand, the OpenCL part duplicates the > entire actual filter code. And unlike with asm, there's no good way to > test that they do the same thing. Also, the amount of OpenCL > boilerplate looks a bit high, considering that it already uses shared > OpenCL utility code. > > But since there are already 2 other filters which do this, there's not > much of a reason to reject this, assuming it works and it's reasonably > equivalent to software filtering. Yes, it's not exactly pretty. I thought about ways to add more abstraction, but most filters are way to different in how they work and what parameters they require. If more simple filters gain OpenCL support, it should be possible to add a basic "Run CL kernel on frame" abstraction which reduces the amount of boilerplate needed. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct
Hendrik Leppkes gmail.com> writes: > The parser only reads the dca core sample rate, which is > limited to a maximum of 48000 Hz, while X96 and HD > extensions can increase the sample rate up to 192000 Hz. > > This change prevents the parser and decoder fighting > over the sample rate, Please mention ticket #4397. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration
>> ping once again >> >> Hi > Could you describe how to verify it, and how can I test it? > > Thanks > Best regards > Using this sample: https://btbn.de/files/chromakey_sample.mp4 ffmpeg -f lavfi -i color=c=black:s=1280x720 -i chromakey_sample.mp4 -an -c:v libx264 -preset veryfast -crf 18 -shortest -filter_complex "[1:v]chromakey=0x70de77:0.1:0.2:0:1[ckout];[0:v][ckout]overlay[out]" -map "[out]" -y output.mkv The last parameter to the chromakey filter enables opencl acceleration. signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct
On Wed, 30 Sep 2015 13:09:01 +0200
Hendrik Leppkes wrote:
> The parser only reads the dca core sample rate, which is limited to a
> maximum of 48000 Hz, while X96 and HD extensions can increase the sample
> rate up to 192000 Hz.
>
> This change prevents the parser and decoder fighting over the sample rate,
> potentially confusing user applications. This also fixes sample rate
> display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.
> ---
> libavcodec/dca_parser.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
> index 337a99d..70e64a8 100644
> --- a/libavcodec/dca_parser.c
> +++ b/libavcodec/dca_parser.c
> @@ -166,7 +166,6 @@ static int dca_parse(AVCodecParserContext *s,
> AVCodecContext *avctx,
> /* read the duration and sample rate from the frame header */
> if (!dca_parse_params(buf, buf_size, &duration, &sample_rate,
> &pc1->framesize)) {
> s->duration= duration;
> -avctx->sample_rate = sample_rate;
> } else
> s->duration = 0;
>
So in which situations do decoder and parser share the AVCodecContext
at all? In libavformat?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] dca_parser: don't overwrite the sample rate, it may not be correct
The parser only reads the dca core sample rate, which is limited to a
maximum of 48000 Hz, while X96 and HD extensions can increase the sample
rate up to 192000 Hz.
This change prevents the parser and decoder fighting over the sample rate,
potentially confusing user applications. This also fixes sample rate
display of >48000Hz files with ffmpeg/ffprobe when using libdcadec.
---
libavcodec/dca_parser.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
index 337a99d..70e64a8 100644
--- a/libavcodec/dca_parser.c
+++ b/libavcodec/dca_parser.c
@@ -166,7 +166,6 @@ static int dca_parse(AVCodecParserContext *s,
AVCodecContext *avctx,
/* read the duration and sample rate from the frame header */
if (!dca_parse_params(buf, buf_size, &duration, &sample_rate,
&pc1->framesize)) {
s->duration= duration;
-avctx->sample_rate = sample_rate;
} else
s->duration = 0;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] h264_parser: force fetching a new timestamp until a frame start was found
This fixes broken timestamps on streams where the SPS/PPS is at the end of
the previous packet, instead of in front of the next packet, observed in
badly packetized MPEG-TS streams.
---
libavcodec/h264_parser.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index 19d1aa3..466008e 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -520,6 +520,9 @@ static int h264_parse(AVCodecParserContext *s,
} else {
next = h264_find_frame_end(p, buf, buf_size);
+if (next == END_NOT_FOUND && pc->frame_start_found == 0)
+s->fetch_timestamp = 1;
+
if (ff_combine_frame(pc, next, &buf, &buf_size) < 0) {
*poutbuf = NULL;
*poutbuf_size = 0;
--
2.5.3.windows.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
On 9/30/15, Hendrik Leppkes wrote: > The chroma format can be still unset in postinit when a badly cut stream > starts with a slice instead of a sequence header. This is a common > occurance when feeding avcodec from a Live TV stream. > --- > libavcodec/mpeg12dec.c | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c > index 5d916d1..b3c2c45 100644 > --- a/libavcodec/mpeg12dec.c > +++ b/libavcodec/mpeg12dec.c > @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) > case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; > break; > case 2: > case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; > break; > -default: av_assert0(0); > } > } // MPEG-2 > > -- > 2.5.3.windows.1 There could be warning of some sort, lgtm anyway. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter
On 9/30/15, wm4 wrote:
> On Wed, 30 Sep 2015 11:09:28 +0100
> Kevin Wheatley wrote:
>
>> On Wed, Sep 30, 2015 at 9:49 AM, Paul B Mahol wrote:
>> > +{ "range", "set color range", OFFSET(range),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
>> > +{ "r", "set color range", OFFSET(range),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
>> > +{ "input",0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS, "range" },
>> > +{ "limited", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_LIMITED}, 0, 0, FLAGS, "range" },
>> > +{ "full", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_FULL},0, 0, FLAGS, "range" },
>> > +{ "primaries", "set color primaries", OFFSET(primaries),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS,
>> > "primaries" },
>> > +{ "p", "set color primaries", OFFSET(primaries),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS,
>> > "primaries" },
>> > +{ "input",0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
>> > "primaries" },
>> > +{ "709", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS,
>> > "primaries" },
>> > +{ "unspecified", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS,
>> > "primaries" },
>> > +{ "170m", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS,
>> > "primaries" },
>> > +{ "240m", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS,
>> > "primaries" },
>> > +{ "2020", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS,
>> > "primaries" },
>> > +{ "transfer", "set transfer characteristic", OFFSET(trc),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS,
>> > "transfer" },
>> > +{ "t","set transfer characteristic", OFFSET(trc),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS,
>> > "transfer" },
>> > +{ "input",0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "709", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_709}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "unspecified", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "601", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "linear", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_LINEAR}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "2020_10", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "2020_12", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS,
>> > "transfer" },
>> > +{ "matrix", "set colorspace matrix", OFFSET(colorspace),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix"
>> > },
>> > +{ "m", "set colorspace matrix", OFFSET(colorspace),
>> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix"
>> > },
>> > +{ "input",0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
>> > "matrix" },
>> > +{ "709", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_709},0, 0, FLAGS,
>> > "matrix" },
>> > +{ "unspecified", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_UNSPECIFIED},0, 0, FLAGS,
>> > "matrix" },
>> > +{ "470bg",0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_470BG}, 0, 0, FLAGS,
>> > "matrix" },
>> > +{ "170m", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_170M}, 0, 0, FLAGS,
>> > "matrix" },
>> > +{ "2020_ncl", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_NCL}, 0, 0, FLAGS,
>> > "matrix" },
>> > +{ "2020_cl", 0, 0,
>> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_CL},0, 0, FLAGS,
>> > "matrix" },
>>
>>
>> As a casual developer/observer, I wonder about the consistency of the
>> options here with other parts of ffmpeg, in the general case it uses:
>>
>> -color_primaries
>> bt709
>> unspecified
>> bt470m
>> bt470bg
>> smpte170m
>> smpte240m
>> film
>> bt2020
>> -color_trc
>> bt709
>> unspecified
>> gamma22
>> gamma28
>> smpte170m
>> smpte240m
>> linear
>> log
>> log_sqrt
>> iec61966_2_4
>> bt1361
>>
Re: [FFmpeg-devel] [PATCH 3/3][RFC] avfilter/vf_chromakey: Add OpenCL acceleration
On Thu, 24 Sep 2015 17:12:25 +0200
Timo Rothenpieler wrote:
> Signed-off-by: Timo Rothenpieler
> ---
> doc/filters.texi | 5 +
> libavfilter/chromakey_opencl_kernel.h | 98 +++
> libavfilter/opencl_allkernels.c | 2 +
> libavfilter/vf_chromakey.c| 179
> +-
> 4 files changed, 283 insertions(+), 1 deletion(-)
> create mode 100644 libavfilter/chromakey_opencl_kernel.h
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 044876c..4faf4b9 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -3734,6 +3734,11 @@ Signals that the color passed is already in YUV
> instead of RGB.
>
> Litteral colors like "green" or "red" don't make sense with this enabled
> anymore.
> This can be used to pass exact YUV values as hexadecimal numbers.
> +
> +@item opencl
> +If set to 1, specify using OpenCL capabilities, only available if
> +FFmpeg was configured with @code{--enable-opencl}. Default value is 0.
> +
> @end table
>
> @subsection Examples
> diff --git a/libavfilter/chromakey_opencl_kernel.h
> b/libavfilter/chromakey_opencl_kernel.h
> new file mode 100644
> index 000..56bbc79
> --- /dev/null
> +++ b/libavfilter/chromakey_opencl_kernel.h
> @@ -0,0 +1,98 @@
> +/*
> + * Copyright (c) 2015 Timo Rothenpieler
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#ifndef AVFILTER_CHROMAKEY_OPENCL_KERNEL_H
> +#define AVFILTER_CHROMAKEY_OPENCL_KERNEL_H
> +
> +#include "libavutil/opencl.h"
> +
> +const char *ff_kernel_chromakey_opencl = AV_OPENCL_KERNEL(
> +
> +inline unsigned char get_pixel(global unsigned char *src,
> + int x,
> + int y,
> + int w,
> + int h,
> + int linesize,
> + int hsub_log2,
> + int vsub_log2,
> + unsigned char def)
> +{
> +if (x < 0 || x >= w || y < 0 || x >= w)
> +return def;
> +
> +x >>= hsub_log2;
> +y >>= vsub_log2;
> +
> +return src[linesize * y + x];
> +}
> +
> +kernel void chromakey(global unsigned char *src_u,
> + global unsigned char *src_v,
> + global unsigned char *dst,
> + int linesize_u,
> + int linesize_v,
> + int linesize_a,
> + int height,
> + int width,
> + int hsub_log2,
> + int vsub_log2,
> + unsigned char chromakey_u,
> + unsigned char chromakey_v,
> + float similarity,
> + float blend
> + )
> +{
> +int x = get_global_id(0);
> +int y = get_global_id(1);
> +unsigned char res;
> +
> +int xo, yo, du, dv;
> +double diff = 0.0;
> +
> +if (x >= width || y >= height)
> +return;
> +
> +for (yo = 0; yo < 3; yo++) {
> +for (xo = 0; xo < 3; xo++) {
> +du = get_pixel(src_u, x + xo - 1, y + yo - 1, width, height,
> linesize_u, hsub_log2, vsub_log2, chromakey_u);
> +dv = get_pixel(src_v, x + xo - 1, y + yo - 1, width, height,
> linesize_v, hsub_log2, vsub_log2, chromakey_v);
> +
> +du -= chromakey_u;
> +dv -= chromakey_v;
> +
> +diff += sqrt((du * du + dv * dv) / (double)(255.0 * 255.0));
> +}
> +}
> +
> +diff /= 9.0;
> +
> +if (blend > 0.0001) {
> +res = clamp((diff - similarity) / blend, 0.0, 1.0) * 255.0;
> +} else {
> +res = (diff > similarity) ? 255 : 0;
> +}
> +
> +dst[linesize_a * y + x] = res;
> +}
> +
> +);
> +
> +#endif /* AVFILTER_CHROMAKEY_OPENCL_KERNEL_H */
> diff --git a/libavfilter/opencl_allkernels.c b/libavfilter/opencl_allkernels.c
> index 6d80fa8..fc05e66 100644
> --- a/libavfilter/opencl_allkernels.c
> +++ b/libavfilter/opencl_allkernels.c
> @@ -23,6 +23,7 @@
> #include "libavutil/opencl.h"
> #include "deshake_opencl_kernel.h"
> #include "unsharp_opencl_kernel.h"
> +#include "chromakey_opencl_kern
[FFmpeg-devel] [PATCH] mpeg12dec: don't assert on unknown chroma format
The chroma format can be still unset in postinit when a badly cut stream starts with a slice instead of a sequence header. This is a common occurance when feeding avcodec from a Live TV stream. --- libavcodec/mpeg12dec.c | 1 - 1 file changed, 1 deletion(-) diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c index 5d916d1..b3c2c45 100644 --- a/libavcodec/mpeg12dec.c +++ b/libavcodec/mpeg12dec.c @@ -1389,7 +1389,6 @@ static int mpeg_decode_postinit(AVCodecContext *avctx) case 1: avctx->chroma_sample_location = AVCHROMA_LOC_LEFT; break; case 2: case 3: avctx->chroma_sample_location = AVCHROMA_LOC_TOPLEFT; break; -default: av_assert0(0); } } // MPEG-2 -- 2.5.3.windows.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter
On Wed, 30 Sep 2015 11:09:28 +0100
Kevin Wheatley wrote:
> On Wed, Sep 30, 2015 at 9:49 AM, Paul B Mahol wrote:
> > +{ "range", "set color range", OFFSET(range), AV_OPT_TYPE_INT,
> > {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
> > +{ "r", "set color range", OFFSET(range), AV_OPT_TYPE_INT,
> > {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
> > +{ "input",0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS, "range" },
> > +{ "limited", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_LIMITED}, 0, 0, FLAGS, "range" },
> > +{ "full", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_FULL},0, 0, FLAGS, "range" },
> > +{ "primaries", "set color primaries", OFFSET(primaries),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries" },
> > +{ "p", "set color primaries", OFFSET(primaries),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries" },
> > +{ "input",0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
> > "primaries" },
> > +{ "709", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS,
> > "primaries" },
> > +{ "unspecified", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS,
> > "primaries" },
> > +{ "170m", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS,
> > "primaries" },
> > +{ "240m", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS,
> > "primaries" },
> > +{ "2020", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS,
> > "primaries" },
> > +{ "transfer", "set transfer characteristic", OFFSET(trc),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer"
> > },
> > +{ "t","set transfer characteristic", OFFSET(trc),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer"
> > },
> > +{ "input",0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "709", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_709}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "unspecified", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "601", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "linear", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_LINEAR}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "2020_10", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "2020_12", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS,
> > "transfer" },
> > +{ "matrix", "set colorspace matrix", OFFSET(colorspace),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
> > +{ "m", "set colorspace matrix", OFFSET(colorspace),
> > AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
> > +{ "input",0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS, "matrix" },
> > +{ "709", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_709},0, 0, FLAGS, "matrix" },
> > +{ "unspecified", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_UNSPECIFIED},0, 0, FLAGS, "matrix" },
> > +{ "470bg",0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_470BG}, 0, 0, FLAGS, "matrix" },
> > +{ "170m", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_170M}, 0, 0, FLAGS, "matrix" },
> > +{ "2020_ncl", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_NCL}, 0, 0, FLAGS, "matrix" },
> > +{ "2020_cl", 0, 0,
> > AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_CL},0, 0, FLAGS, "matrix" },
>
>
> As a casual developer/observer, I wonder about the consistency of the
> options here with other parts of ffmpeg, in the general case it uses:
>
> -color_primaries
> bt709
> unspecified
> bt470m
> bt470bg
> smpte170m
Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter
On 9/30/15, Kevin Wheatley wrote:
> On Wed, Sep 30, 2015 at 9:49 AM, Paul B Mahol wrote:
>> +{ "range", "set color range", OFFSET(range),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
>> +{ "r", "set color range", OFFSET(range),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
>> +{ "input",0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS, "range" },
>> +{ "limited", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_LIMITED}, 0, 0, FLAGS, "range" },
>> +{ "full", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_RANGE_FULL},0, 0, FLAGS, "range" },
>> +{ "primaries", "set color primaries", OFFSET(primaries),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries"
>> },
>> +{ "p", "set color primaries", OFFSET(primaries),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries"
>> },
>> +{ "input",0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
>> "primaries" },
>> +{ "709", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS,
>> "primaries" },
>> +{ "unspecified", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS,
>> "primaries" },
>> +{ "170m", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS,
>> "primaries" },
>> +{ "240m", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS,
>> "primaries" },
>> +{ "2020", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS,
>> "primaries" },
>> +{ "transfer", "set transfer characteristic", OFFSET(trc),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer"
>> },
>> +{ "t","set transfer characteristic", OFFSET(trc),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer"
>> },
>> +{ "input",0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "709", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_709}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "unspecified", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "601", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "linear", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_LINEAR}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "2020_10", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "2020_12", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS,
>> "transfer" },
>> +{ "matrix", "set colorspace matrix", OFFSET(colorspace),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
>> +{ "m", "set colorspace matrix", OFFSET(colorspace),
>> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
>> +{ "input",0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = -1}, 0, 0, FLAGS, "matrix"
>> },
>> +{ "709", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_709},0, 0, FLAGS, "matrix"
>> },
>> +{ "unspecified", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_UNSPECIFIED},0, 0, FLAGS, "matrix"
>> },
>> +{ "470bg",0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_470BG}, 0, 0, FLAGS, "matrix"
>> },
>> +{ "170m", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_170M}, 0, 0, FLAGS, "matrix"
>> },
>> +{ "2020_ncl", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_NCL}, 0, 0, FLAGS, "matrix"
>> },
>> +{ "2020_cl", 0, 0,
>> AV_OPT_TYPE_CONST, {.i64 = ZIMG_MATRIX_2020_CL},0, 0, FLAGS, "matrix"
>> },
>
>
> As a casual developer/observer, I wonder about the consistency of the
> options here with other parts of ffmpeg, in the general case it uses:
>
> -color_primaries
> bt709
> unspecified
> bt470m
> bt470bg
> smpte170m
> smpte240m
> film
> bt2020
> -color_trc
> bt709
> unspecified
> gamma22
> gamma28
> smpte170m
> smpte240m
> linear
> log
> log_sqrt
> iec61966_2_4
> bt1361
> iec61966_2_1
> bt2020_10bit
> bt2020_12bit
> -colorspace
> rgb
> bt709
> unspecified
> fcc
> bt470bg
> smpte170m
> smpte240m
> ycocg
> bt2020_ncl
> bt2020_cl
>
> For the colour range it has
>
> -col
Re: [FFmpeg-devel] [PATCH] avfilter: add zscale filter
On Wed, Sep 30, 2015 at 9:49 AM, Paul B Mahol wrote:
> +{ "range", "set color range", OFFSET(range), AV_OPT_TYPE_INT,
> {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
> +{ "r", "set color range", OFFSET(range), AV_OPT_TYPE_INT,
> {.i64 = -1}, -1, ZIMG_RANGE_FULL, FLAGS, "range" },
> +{ "input",0, 0, AV_OPT_TYPE_CONST,
> {.i64 = -1}, 0, 0, FLAGS, "range" },
> +{ "limited", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_RANGE_LIMITED}, 0, 0, FLAGS, "range" },
> +{ "full", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_RANGE_FULL},0, 0, FLAGS, "range" },
> +{ "primaries", "set color primaries", OFFSET(primaries),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries" },
> +{ "p", "set color primaries", OFFSET(primaries),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_PRIMARIES_2020, FLAGS, "primaries" },
> +{ "input",0, 0, AV_OPT_TYPE_CONST,
> {.i64 = -1}, 0, 0, FLAGS, "primaries" },
> +{ "709", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_PRIMARIES_709}, 0, 0, FLAGS, "primaries" },
> +{ "unspecified", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_PRIMARIES_UNSPECIFIED}, 0, 0, FLAGS, "primaries" },
> +{ "170m", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_PRIMARIES_170M},0, 0, FLAGS, "primaries" },
> +{ "240m", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_PRIMARIES_240M},0, 0, FLAGS, "primaries" },
> +{ "2020", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_PRIMARIES_2020},0, 0, FLAGS, "primaries" },
> +{ "transfer", "set transfer characteristic", OFFSET(trc),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer" },
> +{ "t","set transfer characteristic", OFFSET(trc),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_TRANSFER_2020_12, FLAGS, "transfer" },
> +{ "input",0, 0, AV_OPT_TYPE_CONST,
> {.i64 = -1}, 0, 0, FLAGS, "transfer" },
> +{ "709", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_709}, 0, 0, FLAGS, "transfer" },
> +{ "unspecified", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_UNSPECIFIED}, 0, 0, FLAGS, "transfer" },
> +{ "601", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_601}, 0, 0, FLAGS, "transfer" },
> +{ "linear", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_LINEAR}, 0, 0, FLAGS, "transfer" },
> +{ "2020_10", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_2020_10}, 0, 0, FLAGS, "transfer" },
> +{ "2020_12", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_TRANSFER_2020_12}, 0, 0, FLAGS, "transfer" },
> +{ "matrix", "set colorspace matrix", OFFSET(colorspace),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
> +{ "m", "set colorspace matrix", OFFSET(colorspace),
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, ZIMG_MATRIX_2020_CL, FLAGS, "matrix" },
> +{ "input",0, 0, AV_OPT_TYPE_CONST,
> {.i64 = -1}, 0, 0, FLAGS, "matrix" },
> +{ "709", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_709},0, 0, FLAGS, "matrix" },
> +{ "unspecified", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_UNSPECIFIED},0, 0, FLAGS, "matrix" },
> +{ "470bg",0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_470BG}, 0, 0, FLAGS, "matrix" },
> +{ "170m", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_170M}, 0, 0, FLAGS, "matrix" },
> +{ "2020_ncl", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_2020_NCL}, 0, 0, FLAGS, "matrix" },
> +{ "2020_cl", 0, 0, AV_OPT_TYPE_CONST,
> {.i64 = ZIMG_MATRIX_2020_CL},0, 0, FLAGS, "matrix" },
As a casual developer/observer, I wonder about the consistency of the
options here with other parts of ffmpeg, in the general case it uses:
-color_primaries
bt709
unspecified
bt470m
bt470bg
smpte170m
smpte240m
film
bt2020
-color_trc
bt709
unspecified
gamma22
gamma28
smpte170m
smpte240m
linear
log
log_sqrt
iec61966_2_4
bt1361
iec61966_2_1
bt2020_10bit
bt2020_12bit
-colorspace
rgb
[FFmpeg-devel] [PATCH] avfilter: add zscale filter
Signed-off-by: Paul B Mahol
---
configure| 4 +
doc/filters.texi | 171
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_zscale.c | 678 +++
5 files changed, 855 insertions(+)
create mode 100644 libavfilter/vf_zscale.c
diff --git a/configure b/configure
index 361c024..2bcaff9 100755
--- a/configure
+++ b/configure
@@ -269,6 +269,7 @@ External library support:
--enable-libxcb-shapeenable X11 grabbing shape rendering [autodetect]
--enable-libxvid enable Xvid encoding via xvidcore,
native MPEG-4/Xvid encoder exists [no]
+ --enable-libzimg enable z.lib, needed for zscale filter [no]
--enable-libzmq enable message passing via libzmq [no]
--enable-libzvbi enable teletext support via libzvbi [no]
--disable-lzma disable lzma [autodetect]
@@ -1435,6 +1436,7 @@ EXTERNAL_LIBRARY_LIST="
libxcb_shape
libxcb_xfixes
libxvid
+libzimg
libzmq
libzvbi
lzma
@@ -2817,6 +2819,7 @@ tinterlace_pad_test_deps="tinterlace_filter"
uspp_filter_deps="gpl avcodec"
zmq_filter_deps="libzmq"
zoompan_filter_deps="swscale"
+zscale_filter_deps="libzimg"
# examples
avio_reading="avformat avcodec avutil"
@@ -5355,6 +5358,7 @@ enabled libx265 && require_pkg_config x265
x265.h x265_api_get &&
die "ERROR: libx265 version must be >= 57."; }
enabled libxavs && require libxavs xavs.h xavs_encoder_encode -lxavs
enabled libxvid && require libxvid xvid.h xvid_global -lxvidcore
+enabled libzimg && require_pkg_config zimg zimg3.h
zimg2_get_api_version
enabled libzmq&& require_pkg_config libzmq zmq.h zmq_ctx_new
enabled libzvbi && require libzvbi libzvbi.h vbi_decoder_new -lzvbi
enabled mmal && { check_lib interface/mmal/mmal.h
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host ||
diff --git a/doc/filters.texi b/doc/filters.texi
index a4d828e..68e21c7 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11773,6 +11773,177 @@
zoompan=z='min(zoom+0.0015,1.5)':d=700:x='iw/2-(iw/zoom/2)':y='ih/2-(ih/zoom/2)'
@end example
@end itemize
+@section zscale
+Scale (resize) the input video, using the z.lib library:
+https://github.com/sekrit-twc/zimg.
+
+The zscale filter forces the output display aspect ratio to be the same
+as the input, by changing the output sample aspect ratio.
+
+If the input image format is different from the format requested by
+the next filter, the zscale filter will convert the input to the
+requested format.
+
+@subsection Options
+The filter accepts the following options.
+
+@table @option
+@item width, w
+@item height, h
+Set the output video dimension expression. Default value is the input
+dimension.
+
+If the @var{width} or @var{w} is 0, the input width is used for the output.
+If the @var{height} or @var{h} is 0, the input height is used for the output.
+
+If one of the values is -1, the zscale filter will use a value that
+maintains the aspect ratio of the input image, calculated from the
+other specified dimension. If both of them are -1, the input size is
+used
+
+If one of the values is -n with n > 1, the zscale filter will also use a value
+that maintains the aspect ratio of the input image, calculated from the other
+specified dimension. After that it will, however, make sure that the calculated
+dimension is divisible by n and adjust the value if necessary.
+
+See below for the list of accepted constants for use in the dimension
+expression.
+
+@item size, s
+Set the video size. For the syntax of this option, check the
+@ref{video size syntax,,"Video size" section in the ffmpeg-utils
manual,ffmpeg-utils}.
+
+@item dither, d
+Set the dither type.
+
+Possible values are:
+@table @var
+@item none
+@item ordered
+@item random
+@item error_diffusion
+@end table
+
+Default is none.
+
+@item filter, f
+Set the resize filter type.
+
+Possible values are:
+@table @var
+@item point
+@item bilinear
+@item bicubic
+@item spline16
+@item spline36
+@item lanczos
+@end table
+
+Default is bilinear.
+
+@item range, r
+Set the color range.
+
+Possible values are:
+@table @var
+@item input
+@item limited
+@item full
+@end table
+
+Default is same as input.
+
+@item primaries, p
+Set the color primaries.
+
+Possible values are:
+@table @var
+@item input
+@item 709
+@item unspecified
+@item 170m
+@item 240m
+@item 2020
+@end table
+
+Default is same as input.
+
+@item transfer, t
+Set the transfer characteristics.
+
+Possible values are:
+@table @var
+@item input
+@item 709
+@item unspecified
+@item 601
+@item linear
+@item 2020_10
+@item 2020_12
+@end table
+
+Default is same as input.
+
+@item matrix, m
+Set the colorspace matrix.
+
+Possible value are:
+@table @var
+@item input
+@item 709
+@item unspecified
+@item 470bg
+@item 170m
+@item 2020_ncl
+@item
