Re: [FFmpeg-devel] [PATCH 7/7] x86: hevc: remove a parameter to WP internals
2015-02-05 20:20 GMT+01:00 Christophe Gisquet : > -cglobal hevc_put_hevc_bi_w%1_%2, 5, 7, 10, dst, dststride, src, srcstride, > src2, height, denom, wx0, wx1, ox0, ox1 > -mov r6d, denomm > +cglobal hevc_put_hevc_bi_w%1_%2, 4, 5, 10, dst, dststride, src, src2, > height, denom, wx0, wx1, ox0, ox1 > +mov r5d, denomm This is wrong, that should be "4, 6". Strange that it doesn't cause issues on win64 (linux x86_64 has the 6 first parameters through gprs anyway). Will send an updated patch with any additional modification request from the reviewers. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH]Only run the tta crc checks if requested
Hi!
I did not benchmark but attached should be both a little faster
and a little cleaner.
Please comment, Carl Eugen
From 8bf4e1c82e818483a5bbf55147bb818e5cfacc70 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos
Date: Fri, 6 Feb 2015 10:13:31 +0100
Subject: [PATCH] avformat/tta: only check for header and seek table crc if
requested
---
libavformat/tta.c | 20
1 file changed, 12 insertions(+), 8 deletions(-)
diff --git a/libavformat/tta.c b/libavformat/tta.c
index a782bd7..e839bc2 100644
--- a/libavformat/tta.c
+++ b/libavformat/tta.c
@@ -83,10 +83,12 @@ static int tta_read_header(AVFormatContext *s)
return AVERROR_INVALIDDATA;
}
-crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
-if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
-av_log(s, AV_LOG_ERROR, "Header CRC error\n");
-return AVERROR_INVALIDDATA;
+if (s->error_recognition & AV_EF_CRCCHECK) {
+crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
+if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
+av_log(s, AV_LOG_ERROR, "Header CRC error\n");
+return AVERROR_INVALIDDATA;
+}
}
c->frame_size = samplerate * 256 / 245;
@@ -129,10 +131,12 @@ static int tta_read_header(AVFormatContext *s)
return r;
framepos += size;
}
-crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
-if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
-av_log(s, AV_LOG_ERROR, "Seek table CRC error\n");
-return AVERROR_INVALIDDATA;
+if (s->error_recognition & AV_EF_CRCCHECK) {
+crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
+if (crc != avio_rl32(s->pb)) {
+av_log(s, AV_LOG_ERROR, "Seek table CRC error\n");
+return AVERROR_INVALIDDATA;
+}
}
st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
--
1.7.10.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] opt: Remove dead code
Timothy Gu gmail.com> writes: > if (!i || !*val) > return 0; > } > - > -return 0; > } I fear that some (broken) compilers will emit a warning when this gets applied that we request to be interpreted as an error. Same for 3, 4 and 5. I don't remember if an assert helps. The img2 patch is ok. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/rpl: check av_get_packet() for failure
On 2/5/15, Michael Niedermayer wrote:
> On Thu, Feb 05, 2015 at 03:08:17PM +, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> libavformat/rpl.c | 4
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/libavformat/rpl.c b/libavformat/rpl.c
>> index c1229e8..a05bff1 100644
>> --- a/libavformat/rpl.c
>> +++ b/libavformat/rpl.c
>> @@ -308,6 +308,8 @@ static int rpl_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> return AVERROR(EIO);
>>
>> ret = av_get_packet(pb, pkt, frame_size);
>> +if (ret < 0)
>> +return ret;
>> if (ret != frame_size) {
>> av_free_packet(pkt);
>> return AVERROR(EIO);
>> @@ -323,6 +325,8 @@ static int rpl_read_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> }
>> } else {
>> ret = av_get_packet(pb, pkt, index_entry->size);
>> +if (ret < 0)
>> +return ret;
>
> ret is unsigned, so this cannot be true
Should I then make ret signed?
>
> [...]
> --
> 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
Re: [FFmpeg-devel] Adding Force Style option in Subtitles Filter
On date Thursday 2015-02-05 22:12:08 +0530, Eejya Singh encoded:
[...]
> From ed526a03c939055e2b9f931a0cb4e0e22b7b5b04 Mon Sep 17 00:00:00 2001
> From: Eejya Singh
> Date: Wed, 28 Jan 2015 17:41:42 +0530
> Subject: [PATCH] lavfi/subtitles: add force_style option
>
> Signed-off-by: Eejya Singh
> ---
> doc/filters.texi | 14 ++
> libavfilter/version.h | 2 +-
> libavfilter/vf_subtitles.c | 23 +++
> 3 files changed, 38 insertions(+), 1 deletion(-)
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 261fd24..7f56f34 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -8470,6 +8470,10 @@ useful if not UTF-8.
>
> @item stream_index, si
> Set subtitles stream index. @code{subtitles} filter only.
> +
> +@item force_style
> +Override default style or script info parameters of the subtitles.It follows
> ASS style format.
Override default style or script info parameters of the subtitles. It
accepts a string containing ASS style format KEY=VALUE couples
separated by ",".
> +
drop this empty line
> @end table
>
[...]
LGTM otherwise (but maybe ubitux wants to have a look), thanks.
--
FFmpeg = Freak and Fundamentalist Mean Powerful EnGine
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
On Thu, Feb 5, 2015 at 7:07 PM, James Almer wrote: > > On 05/02/15 12:49 PM, Christophe Gisquet wrote: > > Hi, > > > > 2015-02-05 5:18 GMT+01:00 James Almer : > >> Original x86 intrinsics code and initial yasm port by Pierre-Edouard > >> Lepere. > >> Refactoring and optimizations by James Almer. > > > > No further comment from me. > > Pushed, thanks. > I looked into the MSVC 64bit failure from this patch, and from what I can tell doing this doesn't work: movsx a_strideq, byte [pb_eo+eoq*4+1] I'm not entirely sure on the specifics why it breaks however.. But all I could find suggests that you should load the table address into a reg first, and then use that reg for the address computation. For some reason, the non-WIN64 version does just this, but the WIN64 version does not. Any particular reason for this difference? - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] Use clew instead of cl.h for OpenCL
Attached is the follow on patch that switches to using clew instead of cl.h Regards, Maneesh Gupta 0002-Use-clew-instead-of-cl.h-for-OpenCL.patch Description: 0002-Use-clew-instead-of-cl.h-for-OpenCL.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] Update configure since OpenCL compilation does not need cl.h
Attached is the patch that updates the configure script since we no longer depend upon cl.h. One added advantage of using clew is that we can turn on OpenCL compilation by default. This patch additionally enables OpenCL compilation on Linux, Windows and Darwin target OS. Regards, Maneesh Gupta 0003-Update-configure-since-OpenCL-compilation-does-not-n.patch Description: 0003-Update-configure-since-OpenCL-compilation-does-not-n.patch ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh wrote: > Hi All, > > There are several issues with the way ffmpeg compilation works when OpenCL is > enabled using --enable-opencl. Chief among them are: > 1. One needs to also use --extra-cflags, --extra-ldflags & -extra-libs to > specify the path to the OpenCL header and library files. Otherwise configure > fails. > 2. ffmpeg currently requires OpenCL 1.2, but the build system may have > another version installed (such as the newer OpenCL 2.0 which has deprecated > some 1.2 APIs). > > There are a couple of ways to address this. > > * One way is the x264 approach which is to bundle cl.h, cl_platform.h and a > wrapper c file which relies on dynamically loading OpenCL rather than using > static linking. This requires modifications to the entire OpenCL based code > since we cannot use the OpenCL APIs directly. > * Another approach taken by LibreOffice and Blender for example is to use > clew (i.e. The OpenCL Extension Wrangler Library). This has the advantage of > letting us use the OpenCL APIs directly yet at the same time relying on > dynamically loading OpenCL. The clew project is hosted at > https://github.com/OpenCLWrangler/clew. This is maintained by two people > (Sergey and Martijn). > Usage of clew in Libreoffice can be seen @ > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in Blender > @ > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/clew. > > This patch is for adding clew to the ffmpeg tree. The subsequent patches > switch the OpenCL code in ffmpeg from using cl.h to using clew. > Using such a library is fine, if its deemed the best solution available, but flat-out importing its code into avutil is not. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] ffprobe: Change string_validation to int, its accessed via AVOption as int
On date Thursday 2015-02-05 23:03:56 +0100, Michael Niedermayer encoded: > On Thu, Feb 05, 2015 at 12:10:12PM +0100, Stefano Sabatini wrote: > > On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded: [...] > > > > the enum might be a different data type than int, it might have > > > > a different sizeof() than sizeof(int), av_opt accessing it could > > > > fail. > > > > Is it a theoretical difference or does it affect some > > platform/compiler? In that case, could be a defect in the > > platform/compiler? > > gcc on some embeded platforms seems to use types smaller than int > when it can by default. You can get the same behavior with > -fshort-enums on x86 if you like to try, > > gcc on linux x86 will also use int64_t if a enum constant is too > large for 32bit idependant of the short enum flag > > > > > > From my reading of the C spec, enums and int should be treated in the > > same way by the compiler, but I'm probably wrong. > > 6.7.2.2 Enumeration specifiers > ... > 4 Each enumerated type shall be compatible with char, a signed integer type, > or an > unsigned integer type. The choice of type is implementation-defined,110) > but shall be > capable of representing the values of all the members of the enumeration. > The > enumerated type is incomplete until after the } that terminates the list of > enumerator > declarations. Thanks for taking the time for elaborating this reply. I'm fine with the patch. Still better would be to extend av_opt() code as you suggested. Also documenting this shouldn't be bad (and I guess we have a lot of places where we use enums in options, right?). -- FFmpeg = Funny and Fundamental Mere Plastic Evil God ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avformat/thp: check av_get_packet() for failure
On 2/5/15, Michael Niedermayer wrote: > On Thu, Feb 05, 2015 at 03:08:16PM +, Paul B Mahol wrote: >> Signed-off-by: Paul B Mahol >> --- >> libavformat/thp.c | 2 ++ >> 1 file changed, 2 insertions(+) > > LGTM > applied > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > Republics decline into democracies and democracies degenerate into > despotisms. -- Aristotle > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Only run the tta crc checks if requested
On 2/6/15, Carl Eugen Hoyos wrote:
> Hi!
>
> I did not benchmark but attached should be both a little faster
> and a little cleaner.
>
> Please comment, Carl Eugen
>
> From 8bf4e1c82e818483a5bbf55147bb818e5cfacc70 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Fri, 6 Feb 2015 10:13:31 +0100
> Subject: [PATCH] avformat/tta: only check for header and seek table crc if
> requested
>
> ---
> libavformat/tta.c | 20
> 1 file changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/libavformat/tta.c b/libavformat/tta.c
> index a782bd7..e839bc2 100644
> --- a/libavformat/tta.c
> +++ b/libavformat/tta.c
> @@ -83,10 +83,12 @@ static int tta_read_header(AVFormatContext *s)
> return AVERROR_INVALIDDATA;
> }
>
> -crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> -if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
> -av_log(s, AV_LOG_ERROR, "Header CRC error\n");
> -return AVERROR_INVALIDDATA;
> +if (s->error_recognition & AV_EF_CRCCHECK) {
> +crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> +if (crc != avio_rl32(s->pb) && s->error_recognition &
> AV_EF_CRCCHECK) {
You are checking for AV_EF_CRCCHECK twice.
> +av_log(s, AV_LOG_ERROR, "Header CRC error\n");
> +return AVERROR_INVALIDDATA;
> +}
> }
>
> c->frame_size = samplerate * 256 / 245;
> @@ -129,10 +131,12 @@ static int tta_read_header(AVFormatContext *s)
> return r;
> framepos += size;
> }
> -crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> -if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
> -av_log(s, AV_LOG_ERROR, "Seek table CRC error\n");
> -return AVERROR_INVALIDDATA;
> +if (s->error_recognition & AV_EF_CRCCHECK) {
> +crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> +if (crc != avio_rl32(s->pb)) {
> +av_log(s, AV_LOG_ERROR, "Seek table CRC error\n");
> +return AVERROR_INVALIDDATA;
> +}
> }
>
> st->codec->codec_type = AVMEDIA_TYPE_AUDIO;
> --
> 1.7.10.4
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] flac: ignore duplicated ID3 tags if vorbis tags exist
On Thu, 5 Feb 2015 22:57:07 -0500
Ben Boeckel wrote:
> FLAC doesn't really support ID3 tags, so warn if they are found at all.
> If vorbis tags are found, toss out duplicate ID3 tags.
>
> Fixes #3799.
>
> Signed-off-by: Ben Boeckel
> ---
> libavformat/flacdec.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/libavformat/flacdec.c b/libavformat/flacdec.c
> index 1a8dc19..fdb8e46 100644
> --- a/libavformat/flacdec.c
> +++ b/libavformat/flacdec.c
> @@ -33,6 +33,7 @@ static int flac_read_header(AVFormatContext *s)
> int ret, metadata_last=0, metadata_type, metadata_size,
> found_streaminfo=0;
> uint8_t header[4];
> uint8_t *buffer=NULL;
> +int has_idv3 = 0;
> AVStream *st = avformat_new_stream(s, NULL);
> if (!st)
> return AVERROR(ENOMEM);
> @@ -47,6 +48,19 @@ static int flac_read_header(AVFormatContext *s)
> return 0;
> }
>
> +if (av_dict_count(s->metadata)) {
> +/* XXX: Is there a better way to parse this out? ID3 parsing is done
> + * all the way out in avformat_open_input. */
> +has_idv3 = 1;
Not that I know of... the way libavformat does this is a travesty
though.
> +}
> +
> +if (has_idv3) {
> +int level = AV_LOG_WARNING;
> +if (s->error_recognition & AV_EF_COMPLIANT)
> +level = AV_LOG_ERROR;
> +av_log(s, level, "Spec-compliant FLAC do not support ID3 tags.\n");
> +}
> +
> /* process metadata blocks */
> while (!avio_feof(s->pb) && !metadata_last) {
> avio_read(s->pb, header, 4);
> @@ -139,8 +153,16 @@ static int flac_read_header(AVFormatContext *s)
> }
> /* process supported blocks other than STREAMINFO */
> if (metadata_type == FLAC_METADATA_TYPE_VORBIS_COMMENT) {
> +AVDictionary *other_meta = NULL;
> AVDictionaryEntry *chmask;
>
> +if (has_idv3) {
> +av_log(s, AV_LOG_VERBOSE, "FLAC found with ID3 and
> vorbis tags; ignoring ID3 tags also provided by vorbis.\n");
> +
> +av_dict_copy(&other_meta, s->metadata, 0);
> +av_dict_free(&s->metadata);
Just swap these pointers?
> +}
> +
> ret = ff_vorbis_comment(s, &s->metadata, buffer,
> metadata_size, 1);
> if (ret < 0) {
> av_log(s, AV_LOG_WARNING, "error parsing VorbisComment
> metadata\n");
> @@ -148,6 +170,11 @@ static int flac_read_header(AVFormatContext *s)
> s->event_flags |= AVFMT_EVENT_FLAG_METADATA_UPDATED;
> }
>
> +if (other_meta) {
> +av_dict_copy(&s->metadata, other_meta,
> AV_DICT_DONT_OVERWRITE);
> +av_dict_free(&other_meta);
> +}
> +
> /* parse the channels mask if present */
> chmask = av_dict_get(s->metadata,
> "WAVEFORMATEXTENSIBLE_CHANNEL_MASK", NULL, 0);
> if (chmask) {
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] atrac3plus: Prevent array out-of-bounds
On Fri, 06 Feb 2015 07:32:56 +
Timothy Gu wrote:
> On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu wrote:
>
> > (num_quant_units - 1) is later used as an index to atrac3p_qu_to_subband,
> > which only has 32 elements (i.e. maximum of num_quant_units is 32).
> > ---
> > libavcodec/atrac3plus.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
>
> Note that this doesn't actually fix any problem else than a GCC warning.
>
>
> >
> > diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
> > index 575a493..b215b02 100644
> > --- a/libavcodec/atrac3plus.c
> > +++ b/libavcodec/atrac3plus.c
> > @@ -1768,7 +1768,7 @@ int ff_atrac3p_decode_channel_unit(GetBitContext
> > *gb, Atrac3pChanUnitCtx *ctx,
> >
> > /* parse sound header */
> > ctx->num_quant_units = get_bits(gb, 5) + 1;
> >
>
> num_quant_units can only be <= (2^5 - 1) + 1, which is <= 32.
>
> This just makes it easier for GCC to see that.
>
>
> > -if (ctx->num_quant_units > 28 && ctx->num_quant_units < 32) {
> > +if (ctx->num_quant_units > 28 && ctx->num_quant_units != 32) {
> > av_log(avctx, AV_LOG_ERROR,
> > "Invalid number of quantization units: %d!\n",
> > ctx->num_quant_units);
> >
>
Maybe I'm missing something, but how does that
justify != instead of <= ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
On Fri, 6 Feb 2015 11:14:21 +0100 Hendrik Leppkes wrote: > On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh wrote: > > Hi All, > > > > There are several issues with the way ffmpeg compilation works when OpenCL > > is enabled using --enable-opencl. Chief among them are: > > 1. One needs to also use --extra-cflags, --extra-ldflags & -extra-libs to > > specify the path to the OpenCL header and library files. Otherwise > > configure fails. > > 2. ffmpeg currently requires OpenCL 1.2, but the build system may have > > another version installed (such as the newer OpenCL 2.0 which has > > deprecated some 1.2 APIs). > > > > There are a couple of ways to address this. > > > > * One way is the x264 approach which is to bundle cl.h, cl_platform.h and a > > wrapper c file which relies on dynamically loading OpenCL rather than using > > static linking. This requires modifications to the entire OpenCL based code > > since we cannot use the OpenCL APIs directly. > > * Another approach taken by LibreOffice and Blender for example is to use > > clew (i.e. The OpenCL Extension Wrangler Library). This has the advantage > > of letting us use the OpenCL APIs directly yet at the same time relying on > > dynamically loading OpenCL. The clew project is hosted at > > https://github.com/OpenCLWrangler/clew. This is maintained by two people > > (Sergey and Martijn). > > Usage of clew in Libreoffice can be seen @ > > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in > > Blender @ > > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/clew. > > > > This patch is for adding clew to the ffmpeg tree. The subsequent patches > > switch the OpenCL code in ffmpeg from using cl.h to using clew. > > > > > Using such a library is fine, if its deemed the best solution > available, but flat-out importing its code into avutil is not. +1 Also look at all these awful "portability" hacks in the added code. It's not a good idea to agree to maintaining this terrible mess. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
> -Original Message- > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > boun...@ffmpeg.org] On Behalf Of wm4 > Sent: Friday, February 06, 2015 4:31 PM > To: ffmpeg-devel@ffmpeg.org > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil > > On Fri, 6 Feb 2015 11:14:21 +0100 > Hendrik Leppkes wrote: > > > On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh > wrote: > > > Hi All, > > > > > > There are several issues with the way ffmpeg compilation works when > OpenCL is enabled using --enable-opencl. Chief among them are: > > > 1. One needs to also use --extra-cflags, --extra-ldflags & -extra-libs to > specify the path to the OpenCL header and library files. Otherwise configure > fails. > > > 2. ffmpeg currently requires OpenCL 1.2, but the build system may have > another version installed (such as the newer OpenCL 2.0 which has > deprecated some 1.2 APIs). > > > > > > There are a couple of ways to address this. > > > > > > * One way is the x264 approach which is to bundle cl.h, cl_platform.h and > a wrapper c file which relies on dynamically loading OpenCL rather than using > static linking. This requires modifications to the entire OpenCL based code > since we cannot use the OpenCL APIs directly. > > > * Another approach taken by LibreOffice and Blender for example is to > use clew (i.e. The OpenCL Extension Wrangler Library). This has the > advantage of letting us use the OpenCL APIs directly yet at the same time > relying on dynamically loading OpenCL. The clew project is hosted at > https://github.com/OpenCLWrangler/clew. This is maintained by two people > (Sergey and Martijn). > > > Usage of clew in Libreoffice can be seen @ > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in > Blender @ > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/cl > ew. > > > > > > This patch is for adding clew to the ffmpeg tree. The subsequent patches > switch the OpenCL code in ffmpeg from using cl.h to using clew. > > > > > > > > > Using such a library is fine, if its deemed the best solution > > available, but flat-out importing its code into avutil is not. > > +1 > > Also look at all these awful "portability" hacks in the added code. > It's not a good idea to agree to maintaining this terrible mess. Alright. Can you suggest an alternate way of building ffmpeg using clew? Clew has lot of advantages and essentially consists of a single source and header file. I will modify and resubmit the patch accordingly. > ___ > 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] tests: add spp test
On date Thursday 2015-02-05 22:57:31 +0100, Clément Bœsch encoded: > On Thu, Feb 05, 2015 at 06:04:56PM +0100, Michael Niedermayer wrote: > > On Thu, Feb 05, 2015 at 12:49:20PM +0100, Stefano Sabatini wrote: > > > On date Wednesday 2015-02-04 16:18:32 +0100, Michael Niedermayer encoded: > > > > On Wed, Feb 04, 2015 at 12:26:15PM +0100, Stefano Sabatini wrote: > > > > > This requires the new sample file matrixbench_mpeg2.lq1.mpg. > > > > > --- > > > > > tests/fate/filter-video.mak | 3 +++ > > > > > tests/ref/fate/filter-spp | 26 ++ > > > > > 2 files changed, 29 insertions(+) > > > > > create mode 100644 tests/ref/fate/filter-spp > > > > > > > > > > > fails on mips and arm > > > > > > What kind of failure? (crash or output difference?) Could it be > > > related to bit-endianness? > > > > you can build with --disable-asm --disable-yasm > > to see the failure on x86 > > And not reproducible with make fate-filter-spp CPUFLAGS=none? Yeah, basically ASM and C code differ. ubitux: do you remember if it was the same with the original mp code? -- FFmpeg = Fast Formidable Majestic Perennial Exxagerate Gangster ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] Use clew instead of cl.h for OpenCL
Hello, Maneesh. On Friday, 06 February 2015 at 11:09, Gupta, Maneesh wrote: > Attached is the follow on patch that switches to using clew instead of cl.h What's the rationale to switch? cl.h is part of Khronos distribution while clew.h seems to be part of clcc with a couple of forks floating around the Internet. Is clew packaged in major distributions? It's definitely not in Fedora or Debian. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil
On Fri, 6 Feb 2015 11:06:28 + "Gupta, Maneesh" wrote: > > > > -Original Message- > > From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel- > > boun...@ffmpeg.org] On Behalf Of wm4 > > Sent: Friday, February 06, 2015 4:31 PM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] [PATCH 1/3] Add clew.c & clew.h to libavutil > > > > On Fri, 6 Feb 2015 11:14:21 +0100 > > Hendrik Leppkes wrote: > > > > > On Fri, Feb 6, 2015 at 11:09 AM, Gupta, Maneesh > > wrote: > > > > Hi All, > > > > > > > > There are several issues with the way ffmpeg compilation works when > > OpenCL is enabled using --enable-opencl. Chief among them are: > > > > 1. One needs to also use --extra-cflags, --extra-ldflags & -extra-libs > > > > to > > specify the path to the OpenCL header and library files. Otherwise configure > > fails. > > > > 2. ffmpeg currently requires OpenCL 1.2, but the build system may have > > another version installed (such as the newer OpenCL 2.0 which has > > deprecated some 1.2 APIs). > > > > > > > > There are a couple of ways to address this. > > > > > > > > * One way is the x264 approach which is to bundle cl.h, cl_platform.h > > > > and > > a wrapper c file which relies on dynamically loading OpenCL rather than > > using > > static linking. This requires modifications to the entire OpenCL based code > > since we cannot use the OpenCL APIs directly. > > > > * Another approach taken by LibreOffice and Blender for example is to > > use clew (i.e. The OpenCL Extension Wrangler Library). This has the > > advantage of letting us use the OpenCL APIs directly yet at the same time > > relying on dynamically loading OpenCL. The clew project is hosted at > > https://github.com/OpenCLWrangler/clew. This is maintained by two people > > (Sergey and Martijn). > > > > Usage of clew in Libreoffice can be seen @ > > http://cgit.freedesktop.org/libreoffice/core/tree/clew/source and in > > Blender @ > > https://git.blender.org/gitweb/gitweb.cgi/blender.git/tree/HEAD:/extern/cl > > ew. > > > > > > > > This patch is for adding clew to the ffmpeg tree. The subsequent patches > > switch the OpenCL code in ffmpeg from using cl.h to using clew. > > > > > > > > > > > > > Using such a library is fine, if its deemed the best solution > > > available, but flat-out importing its code into avutil is not. > > > > +1 > > > > Also look at all these awful "portability" hacks in the added code. > > It's not a good idea to agree to maintaining this terrible mess. > > Alright. Can you suggest an alternate way of building ffmpeg using clew? Clew > has lot of advantages and essentially consists of a single source and header > file. I will modify and resubmit the patch accordingly. Convince upstream to package it as real library. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
This is a proposal for an API extension.
Currently, some pixel formats support alpha, but whether the alpha
component contains something useful or just garbage is not part of the
pixel format definition. This applies at least to packed RGB formats,
where the 4th component is either alpha or garbage depending on the
context.
This means that if a decoder outputs such a packed RGB format, an API
user has no idea whether it has alpha or not. E.g. take PNG and
Camtasia (tscc.c). PNG with alpha outputs AV_PIX_FMT_RGBA, and Camtasia
can output AV_PIX_FMT_RGB32 (which is ARGB or BGRA depending on
endian). Camtasia supports no alpha, and the alpha component literally
contains garbage (AFAIK and judging by the single sample I've seen). An
application decoding both of these can't know whether the output frame
has alpha or not, unless every codec is special-cased.
One possible solution is duplicating all these pixel formats, so you'd
have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think we all agree
that we don't want more pixel formats.
The other solution, which I want to advocate here, is adding a field to
AVFrame that indicates the alpha mode. Something like:
typedef enum AVAlphaMode {
// if an alpha component is present, its function is unknown, and
// it may be garbage
AV_ALPHA_UNKNOWN,
// the alpha component contains premultiplied alpha
// (not sure if any file format actually uses this)
AV_ALPHA_PREMULTIPLIED,
// the alpha component contains straight alpha
// (e.g. PNG)
AV_ALPHA_STRAIGHT,
} AVAlphaMode;
typedef struct AVFrame {
...
AVAlphaMode alpha_mode;
} AVFrame;
Thoughts?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, Feb 06, 2015 at 12:32:14PM +0100, wm4 wrote:
> This is a proposal for an API extension.
>
> Currently, some pixel formats support alpha, but whether the alpha
> component contains something useful or just garbage is not part of the
> pixel format definition. This applies at least to packed RGB formats,
> where the 4th component is either alpha or garbage depending on the
> context.
>
> This means that if a decoder outputs such a packed RGB format, an API
> user has no idea whether it has alpha or not. E.g. take PNG and
> Camtasia (tscc.c). PNG with alpha outputs AV_PIX_FMT_RGBA, and Camtasia
> can output AV_PIX_FMT_RGB32 (which is ARGB or BGRA depending on
> endian). Camtasia supports no alpha, and the alpha component literally
> contains garbage (AFAIK and judging by the single sample I've seen). An
> application decoding both of these can't know whether the output frame
> has alpha or not, unless every codec is special-cased.
>
> One possible solution is duplicating all these pixel formats, so you'd
> have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think we all agree
> that we don't want more pixel formats.
>
> The other solution, which I want to advocate here, is adding a field to
> AVFrame that indicates the alpha mode. Something like:
>
> typedef enum AVAlphaMode {
> // if an alpha component is present, its function is unknown, and
> // it may be garbage
> AV_ALPHA_UNKNOWN,
> // the alpha component contains premultiplied alpha
> // (not sure if any file format actually uses this)
> AV_ALPHA_PREMULTIPLIED,
> // the alpha component contains straight alpha
> // (e.g. PNG)
> AV_ALPHA_STRAIGHT,
> } AVAlphaMode;
>
> typedef struct AVFrame {
> ...
> AVAlphaMode alpha_mode;
> } AVFrame;
>
> Thoughts?
What's your opinion on the existing RGB0?
Another pixel format is useful for at least... libavfilter: some filters
work with alpha, and some filters do not. RGB0 pixel format makes querying
such constraint simply and you can confirm the whole input will be
sanitized.
--
Clément B.
pgpZBT3F6mcv7.pgp
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, 6 Feb 2015 12:45:43 +0100
Clément Bœsch wrote:
> On Fri, Feb 06, 2015 at 12:32:14PM +0100, wm4 wrote:
> > This is a proposal for an API extension.
> >
> > Currently, some pixel formats support alpha, but whether the alpha
> > component contains something useful or just garbage is not part of the
> > pixel format definition. This applies at least to packed RGB formats,
> > where the 4th component is either alpha or garbage depending on the
> > context.
> >
> > This means that if a decoder outputs such a packed RGB format, an API
> > user has no idea whether it has alpha or not. E.g. take PNG and
> > Camtasia (tscc.c). PNG with alpha outputs AV_PIX_FMT_RGBA, and Camtasia
> > can output AV_PIX_FMT_RGB32 (which is ARGB or BGRA depending on
> > endian). Camtasia supports no alpha, and the alpha component literally
> > contains garbage (AFAIK and judging by the single sample I've seen). An
> > application decoding both of these can't know whether the output frame
> > has alpha or not, unless every codec is special-cased.
> >
> > One possible solution is duplicating all these pixel formats, so you'd
> > have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think we all agree
> > that we don't want more pixel formats.
> >
> > The other solution, which I want to advocate here, is adding a field to
> > AVFrame that indicates the alpha mode. Something like:
> >
> > typedef enum AVAlphaMode {
> > // if an alpha component is present, its function is unknown, and
> > // it may be garbage
> > AV_ALPHA_UNKNOWN,
> > // the alpha component contains premultiplied alpha
> > // (not sure if any file format actually uses this)
> > AV_ALPHA_PREMULTIPLIED,
> > // the alpha component contains straight alpha
> > // (e.g. PNG)
> > AV_ALPHA_STRAIGHT,
> > } AVAlphaMode;
> >
> > typedef struct AVFrame {
> > ...
> > AVAlphaMode alpha_mode;
> > } AVFrame;
> >
> > Thoughts?
>
> What's your opinion on the existing RGB0?
It's not consistently done, doesn't account for the garbage case (RGB0
means the alpha component is always 0, right?), and just contributes to
the combinatorial explosion of pixel formats.
>
> Another pixel format is useful for at least... libavfilter: some filters
> work with alpha, and some filters do not. RGB0 pixel format makes querying
> such constraint simply and you can confirm the whole input will be
> sanitized.
I consider this an internal problem with libavfilter's format
negotiation, which should have no influence on the cleanliness of the
overall ffmpeg API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
wm4 googlemail.com> writes: > Camtasia can output AV_PIX_FMT_RGB32 > (which is ARGB or BGRA depending on > endian). Camtasia supports no alpha It appears I missed Camtasia when I fixed this for many codecs years ago. I will fix this later if nobody beats me. Thank you, Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, 6 Feb 2015 12:00:00 + (UTC) Carl Eugen Hoyos wrote: > wm4 googlemail.com> writes: > > > Camtasia can output AV_PIX_FMT_RGB32 > > (which is ARGB or BGRA depending on > > endian). Camtasia supports no alpha > > It appears I missed Camtasia when I > fixed this for many codecs years ago. > > I will fix this later if nobody beats me. How do you intend to beat this? Explicitly writing the alpha component? (I was assuming this was a no-go.) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avformat/rpl: check av_get_packet() for failure
On Fri, Feb 06, 2015 at 09:28:03AM +, Paul B Mahol wrote:
> On 2/5/15, Michael Niedermayer wrote:
> > On Thu, Feb 05, 2015 at 03:08:17PM +, Paul B Mahol wrote:
> >> Signed-off-by: Paul B Mahol
> >> ---
> >> libavformat/rpl.c | 4
> >> 1 file changed, 4 insertions(+)
> >>
> >> diff --git a/libavformat/rpl.c b/libavformat/rpl.c
> >> index c1229e8..a05bff1 100644
> >> --- a/libavformat/rpl.c
> >> +++ b/libavformat/rpl.c
> >> @@ -308,6 +308,8 @@ static int rpl_read_packet(AVFormatContext *s,
> >> AVPacket *pkt)
> >> return AVERROR(EIO);
> >>
> >> ret = av_get_packet(pb, pkt, frame_size);
> >> +if (ret < 0)
> >> +return ret;
> >> if (ret != frame_size) {
> >> av_free_packet(pkt);
> >> return AVERROR(EIO);
> >> @@ -323,6 +325,8 @@ static int rpl_read_packet(AVFormatContext *s,
> >> AVPacket *pkt)
> >> }
> >> } else {
> >> ret = av_get_packet(pb, pkt, index_entry->size);
> >> +if (ret < 0)
> >> +return ret;
> >
> > ret is unsigned, so this cannot be true
>
> Should I then make ret signed?
if that doesnt introduce any bugs, i suggest yes
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
wm4 googlemail.com> writes: > > I will fix this later if nobody beats me. > > How do you intend to beat this? Setting it to 0RGB32 instead of RGB32. Unrelated to your API suggestion, this is a bug in FFmpeg that we should fix. > Explicitly writing the alpha component? > (I was assuming this was a no-go.) We do this in many cases but it is not necessary in this case. Concerning your API suggestion, the pix_fmt should always tell you if there is a useful transparency layer or not. If this is not done correctly in some cases, I would like to fix them. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
wm4 googlemail.com> writes: > It's not consistently done, I worked (hard) on doing it consistently, please point me to the missing codecs. A possible reason for missing Camtasia is that I did not find a 32 bit sample (so I could not decide if alpha is hidden in the encoded image or not). > doesn't account for the garbage case (RGB0 > means the alpha component is always 0, right?) No, I believe it means that you must ignore the alpha component. I always thought that this is never a disadvantage, am I missing something? Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, 6 Feb 2015 12:10:59 + (UTC) Carl Eugen Hoyos wrote: > wm4 googlemail.com> writes: > > > > I will fix this later if nobody beats me. > > > > How do you intend to beat this? > > Setting it to 0RGB32 instead of RGB32. > Unrelated to your API suggestion, this is a > bug in FFmpeg that we should fix. > > > Explicitly writing the alpha component? > > (I was assuming this was a no-go.) > > We do this in many cases but it is not > necessary in this case. > > Concerning your API suggestion, the pix_fmt > should always tell you if there is a useful > transparency layer or not. If this is not > done correctly in some cases, I would like > to fix them. The pixfmt docs seems to imply that the extra component must be set to 0 if a RGB0 format is used. Camtasia puts random stuff. What about AV_PIX_FMT_RGB555? It's documented as having 1 alpha bit, though it doesn't have the alpha pixfmt flag set. Fix the docs? Or introduce RGB05551? There is no AV_PIX_FMT_RGB064. Is it guaranteed that there is no 64 bit format with padding? If one ever exists, is it guaranteed that a 0 variant will be added? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
Hi, 2015-02-06 11:07 GMT+01:00 Hendrik Leppkes : > I looked into the MSVC 64bit failure from this patch, and from what I > can tell doing this doesn't work: > movsx a_strideq, byte [pb_eo+eoq*4+1] > > I'm not entirely sure on the specifics why it breaks however.. > But all I could find suggests that you should load the table address > into a reg first, and then use that reg for the address computation. > > For some reason, the non-WIN64 version does just this, but the WIN64 > version does not. > Any particular reason for this difference? So I infer from those last 2 sentences it is a link failure. Indeed, I did observe that issue of mingw64 (or whatever you call that) being fine with this RIP addressing not being respected, but MSVC not. So yes, an intermediate reg is needed, and we can't save that indirection. Could you test the attached patch? Beware, it's on a tree having the patch, but I'm not completely sure it will apply fine. -- Christophe From f0997ceac461add7dddbb1c0a75797bf462bf16e Mon Sep 17 00:00:00 2001 From: Christophe Gisquet Date: Fri, 6 Feb 2015 13:43:45 +0100 Subject: [PATCH] x86: hevc_sao: fix loading of RIP address pb_eo must be handled as a rip relative address for MSVC64, so an intermediate register is needed. Should fix link failures. --- libavcodec/x86/hevc_sao.asm | 24 ++-- 1 file changed, 14 insertions(+), 10 deletions(-) diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc_sao.asm index 5136121..8619716 100644 --- a/libavcodec/x86/hevc_sao.asm +++ b/libavcodec/x86/hevc_sao.asm @@ -296,14 +296,16 @@ HEVC_SAO_BAND_FILTER_16 12, 64, 2 %if WIN64 cglobal hevc_sao_edge_filter_%1_8, 4, 8, 8, dst, src, dststride, offset, a_stride, b_stride, height, tmp %define eoq heightq -movsxd eoq, dword r4m -movsx a_strideq, byte [pb_eo+eoq*4+1] -movsx b_strideq, byte [pb_eo+eoq*4+3] +movsxd b_strideq, dword r4m +lea tmpq, [pb_eo] +lea eoq, [tmpq+4*b_strideq] +movsx a_strideq, byte [eoq+1] +movsx b_strideq, byte [eoq+3] imul a_strideq, EDGE_SRCSTRIDE imul b_strideq, EDGE_SRCSTRIDE -movsx tmpq, byte [pb_eo+eoq*4] +movsx tmpq, byte [eoq] adda_strideq, tmpq -movsx tmpq, byte [pb_eo+eoq*4+2] +movsx tmpq, byte [eoq+2] addb_strideq, tmpq mov heightd, r6m @@ -442,14 +444,16 @@ INIT_YMM cpuname %if WIN64 cglobal hevc_sao_edge_filter_%2_%1, 4, 8, 16, dst, src, dststride, offset, a_stride, b_stride, height, tmp %define eoq heightq -movsxd eoq, dword r4m -movsx a_strideq, byte [pb_eo+eoq*4+1] -movsx b_strideq, byte [pb_eo+eoq*4+3] +movsxd b_strideq, dword r4m +lea tmpq, [pb_eo] +lea eoq, [tmpq+4*b_strideq] +movsx a_strideq, byte [eoq+1] +movsx b_strideq, byte [eoq+3] imul a_strideq, EDGE_SRCSTRIDE>>1 imul b_strideq, EDGE_SRCSTRIDE>>1 -movsx tmpq, byte [pb_eo+eoq*4] +movsx tmpq, byte [eoq] adda_strideq, tmpq -movsx tmpq, byte [pb_eo+eoq*4+2] +movsx tmpq, byte [eoq+2] addb_strideq, tmpq mov heightd, r6m adda_strideq, a_strideq -- 1.9.5.msysgit.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] new option for drawtext (boxborderw = set box border width)
Le septidi 17 pluviôse, an CCXXIII, Liviu Oniciuc a écrit : > it is not related with the inside padding, and yes it does try to follow the > css/ffmpeg vocabulary. 'boxborderw' refer to what css names: 'border-width', I think you are mistaken about either the effect of the drawtext options or the semantic of CSS properties. The "box" that drawtext draws around the text is filled, it corresponds to the "background" CSS property, and adding border in it corresponds to what CSS calls "padding". What CSS calls "border" is a frame, not filled. > but ffmpeg drawtext already has a 'borderw' option, that is actually > used for what css will call: font-weight. In this case again you are mistaken about CSS properties: the borderw option does not correspond to font-weight, it corresponds to the effect usually called outline, which does not exist in standard CSS. The equivalent of font-weight is achieved by selecting a font file with a bold face. > On 2/4/2015 1:13 PM, Clément Bœsch wrote: Please do not top-post on this mailing-list; if you do not know what it means, look it up. 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] tests: add spp test
On Fri, Feb 06, 2015 at 12:14:32PM +0100, Stefano Sabatini wrote: > On date Thursday 2015-02-05 22:57:31 +0100, Clément Bœsch encoded: > > On Thu, Feb 05, 2015 at 06:04:56PM +0100, Michael Niedermayer wrote: > > > On Thu, Feb 05, 2015 at 12:49:20PM +0100, Stefano Sabatini wrote: > > > > On date Wednesday 2015-02-04 16:18:32 +0100, Michael Niedermayer > > > > encoded: > > > > > On Wed, Feb 04, 2015 at 12:26:15PM +0100, Stefano Sabatini wrote: > > > > > > This requires the new sample file matrixbench_mpeg2.lq1.mpg. > > > > > > --- > > > > > > tests/fate/filter-video.mak | 3 +++ > > > > > > tests/ref/fate/filter-spp | 26 ++ > > > > > > 2 files changed, 29 insertions(+) > > > > > > create mode 100644 tests/ref/fate/filter-spp > > > > > > > > > > > > > > fails on mips and arm > > > > > > > > What kind of failure? (crash or output difference?) Could it be > > > > related to bit-endianness? > > > > > > you can build with --disable-asm --disable-yasm > > > to see the failure on x86 > > > > And not reproducible with make fate-filter-spp CPUFLAGS=none? > > Yeah, basically ASM and C code differ. > > ubitux: do you remember if it was the same with the original mp code? Sorry, I don't remember. -- Clément B. pgpfxcaLfxTuz.pgp Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Rollup support in Closed caption
On 01/30/2015 08:49 AM, Anshul wrote:
On January 30, 2015 4:23:08 AM IST, Michael Niedermayer
wrote:
@@ -426,10 +466,13 @@ static int process_cc608(CCaptionSubContext
*ctx, int64_t pts, uint8_t hi, uint8
handle_delete_end_of_row(ctx, hi, lo);
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x25 ) {
ctx->rollup = 2;
+ctx->mode = CCMODE_ROLLUP_2;
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x26 ) {
ctx->rollup = 3;
+ctx->mode = CCMODE_ROLLUP_3;
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x27 ) {
ctx->rollup = 4;
+ctx->mode = CCMODE_ROLLUP_3;
is this intended to be CCMODE_ROLLUP_3 instead of CCMODE_ROLLUP_4 ?
also do you have a file to test this and the other patches ?
thanks
[...]
I tested this on bmd live video, all the rollup values were not tested, I
implemented this feature when roll up 2 was coming.
I will check the database of ccextractor, if I get some video with different
rollup.
-Anshul
I have attached the patch which were not commited, In the rollup
functionality there was one more
bug other then typo, the first line was lost while converting the cc.
I have corrected that.
Here
is video with rollup in closed caption.
-Anshul
>From e8a36edbba5ea1db15d14413bad7db28eec67b5a Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari
Date: Fri, 6 Feb 2015 20:10:11 +0530
Subject: [PATCH 1/3] Added Roll up functionality
Signed-off-by: Anshul Maheshwari
---
libavcodec/ccaption_dec.c | 102 --
1 file changed, 72 insertions(+), 30 deletions(-)
diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
index 9e78ee5..45b932e 100644
--- a/libavcodec/ccaption_dec.c
+++ b/libavcodec/ccaption_dec.c
@@ -151,7 +151,6 @@ struct Screen {
typedef struct CCaptionSubContext {
AVClass *class;
-int row_cnt;
struct Screen screen[2];
int active_screen;
uint8_t cursor_row;
@@ -179,6 +178,7 @@ static av_cold int init_decoder(AVCodecContext *avctx)
av_bprint_init(&ctx->buffer, 0, AV_BPRINT_SIZE_UNLIMITED);
/* taking by default roll up to 2 */
+ctx->mode = CCMODE_ROLLUP_2;
ctx->rollup = 2;
ret = ff_ass_subtitle_header_default(avctx);
/* allocate pkt buffer */
@@ -187,7 +187,7 @@ static av_cold int init_decoder(AVCodecContext *avctx)
ret = AVERROR(ENOMEM);
}
-
+fail:
return ret;
}
@@ -280,6 +280,68 @@ static struct Screen *get_writing_screen(CCaptionSubContext *ctx)
return NULL;
}
+static void roll_up(CCaptionSubContext *ctx)
+{
+struct Screen *screen;
+int i, keep_lines;
+
+if(ctx->mode == CCMODE_TEXT)
+return;
+
+screen = get_writing_screen(ctx);
+
+/* +1 signify cursor_row starts from 0
+ * Can't keep lines less then row cursor pos
+ */
+keep_lines = FFMIN(ctx->cursor_row + 1, ctx->rollup);
+
+for( i = 0; i < ctx->cursor_row - keep_lines; i++ )
+UNSET_FLAG(screen->row_used, i);
+
+
+for( i = 0; i < keep_lines && screen->row_used; i++ ) {
+const int i_row = ctx->cursor_row - keep_lines + i + 1;
+
+memcpy( screen->characters[i_row], screen->characters[i_row+1], SCREEN_COLUMNS );
+memcpy( screen->colors[i_row], screen->colors[i_row+1], SCREEN_COLUMNS);
+memcpy( screen->fonts[i_row], screen->fonts[i_row+1], SCREEN_COLUMNS);
+if(CHECK_FLAG(screen->row_used, i_row + 1))
+SET_FLAG(screen->row_used, i_row);
+
+}
+UNSET_FLAG(screen->row_used, ctx->cursor_row);
+
+}
+
+static int reap_screen(CCaptionSubContext *ctx, int64_t pts)
+{
+int i;
+int ret = 0;
+struct Screen *screen = ctx->screen + ctx->active_screen;
+ctx->start_time = ctx->startv_time;
+
+for( i = 0; screen->row_used && i < SCREEN_ROWS; i++)
+{
+if(CHECK_FLAG(screen->row_used,i)) {
+char *str = screen->characters[i];
+/* skip space */
+while (*str == ' ')
+str++;
+
+av_bprintf(&ctx->buffer, "%s\\N", str);
+ret = av_bprint_is_complete(&ctx->buffer);
+if( ret == 0) {
+ret = AVERROR(ENOMEM);
+break;
+}
+}
+
+}
+ctx->startv_time = pts;
+ctx->end_time = pts;
+return ret;
+}
+
static void handle_textattr( CCaptionSubContext *ctx, uint8_t hi, uint8_t lo )
{
int i = lo - 0x20;
@@ -333,32 +395,12 @@ static void handle_pac( CCaptionSubContext *ctx, uint8_t hi, uint8_t lo )
*/
static int handle_edm(CCaptionSubContext *ctx,int64_t pts)
{
-int i;
int ret = 0;
struct Screen *screen = ctx->screen + ctx->active_screen;
-ctx->start_time = ctx->startv_time;
-for( i = 0; screen->row_used && i < SCREEN_ROWS; i++)
-{
-if(CHECK_FLAG(screen->row_used,i)) {
-char *str = screen->characters[i];
-/* skip s
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
On 06/02/15 7:07 AM, Hendrik Leppkes wrote: > For some reason, the non-WIN64 version does just this, but the WIN64 > version does not. > Any particular reason for this difference? We support PIC on WIN64 but not with others. Or at least x86inc.asm enables it that way. According to msvc documentation https://msdn.microsoft.com/en-us/library/daszf0sk.aspx the linking error is because "You are trying to build a 64-bit image with 32-bit addresses". Quickest "fix" is to just do the same as the UNIX64 path and load the effective address of the table on a register (like in Christophe's patch), but it may still be a good idea to know why msvc is failing whereas mingw-w64 is working as intended. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] x86: hevc: remove a parameter to WP internals
On 06/02/15 6:14 AM, Christophe Gisquet wrote: > 2015-02-05 20:20 GMT+01:00 Christophe Gisquet : >> > -cglobal hevc_put_hevc_bi_w%1_%2, 5, 7, 10, dst, dststride, src, >> > srcstride, src2, height, denom, wx0, wx1, ox0, ox1 >> > -mov r6d, denomm >> > +cglobal hevc_put_hevc_bi_w%1_%2, 4, 5, 10, dst, dststride, src, src2, >> > height, denom, wx0, wx1, ox0, ox1 >> > +mov r5d, denomm > This is wrong, that should be "4, 6". Strange that it doesn't cause > issues on win64 (linux x86_64 has the 6 first parameters through gprs > anyway). "mov r5d, denomm" is loading it on Win64. It's also a superfluous instruction on UNIX64, where it translates to "mov r5d, r5d". At least if i'm reading this right. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
On 06/02/15 9:49 AM, Christophe Gisquet wrote: > diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc_sao.asm > index 5136121..8619716 100644 > --- a/libavcodec/x86/hevc_sao.asm > +++ b/libavcodec/x86/hevc_sao.asm > @@ -296,14 +296,16 @@ HEVC_SAO_BAND_FILTER_16 12, 64, 2 > %if WIN64 > cglobal hevc_sao_edge_filter_%1_8, 4, 8, 8, dst, src, dststride, offset, > a_stride, b_stride, height, tmp > %define eoq heightq > -movsxd eoq, dword r4m > -movsx a_strideq, byte [pb_eo+eoq*4+1] > -movsx b_strideq, byte [pb_eo+eoq*4+3] > +movsxd b_strideq, dword r4m > +lea tmpq, [pb_eo] > +lea eoq, [tmpq+4*b_strideq] > +movsx a_strideq, byte [eoq+1] > +movsx b_strideq, byte [eoq+3] > imul a_strideq, EDGE_SRCSTRIDE > imul b_strideq, EDGE_SRCSTRIDE > -movsx tmpq, byte [pb_eo+eoq*4] > +movsx tmpq, byte [eoq] > adda_strideq, tmpq > -movsx tmpq, byte [pb_eo+eoq*4+2] > +movsx tmpq, byte [eoq+2] > addb_strideq, tmpq > mov heightd, r6m > > @@ -442,14 +444,16 @@ INIT_YMM cpuname > %if WIN64 > cglobal hevc_sao_edge_filter_%2_%1, 4, 8, 16, dst, src, dststride, offset, > a_stride, b_stride, height, tmp > %define eoq heightq > -movsxd eoq, dword r4m > -movsx a_strideq, byte [pb_eo+eoq*4+1] > -movsx b_strideq, byte [pb_eo+eoq*4+3] > +movsxd b_strideq, dword r4m > +lea tmpq, [pb_eo] > +lea eoq, [tmpq+4*b_strideq] > +movsx a_strideq, byte [eoq+1] > +movsx b_strideq, byte [eoq+3] > imul a_strideq, EDGE_SRCSTRIDE>>1 > imul b_strideq, EDGE_SRCSTRIDE>>1 > -movsx tmpq, byte [pb_eo+eoq*4] > +movsx tmpq, byte [eoq] > adda_strideq, tmpq > -movsx tmpq, byte [pb_eo+eoq*4+2] > +movsx tmpq, byte [eoq+2] > addb_strideq, tmpq > mov heightd, r6m > adda_strideq, a_strideq Wouldn't it be better to just use the same code as UNIX64 instead? Now that we're going to load the address of the table to a reg, there's not point in having a whole separate init path for WIN64. One for X86_64 and one for X86_32 (Where applicable) is much cleaner. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] atrac3plus: Prevent array out-of-bounds
On Fri Feb 06 2015 at 2:58:19 AM wm4 wrote:
> On Fri, 06 Feb 2015 07:32:56 +
> Timothy Gu wrote:
>
> > On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu
> wrote:
> >
> > > (num_quant_units - 1) is later used as an index to
> atrac3p_qu_to_subband,
> > > which only has 32 elements (i.e. maximum of num_quant_units is 32).
> > > ---
> > > libavcodec/atrac3plus.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> >
> > Note that this doesn't actually fix any problem else than a GCC warning.
> >
> >
> > >
> > > diff --git a/libavcodec/atrac3plus.c b/libavcodec/atrac3plus.c
> > > index 575a493..b215b02 100644
> > > --- a/libavcodec/atrac3plus.c
> > > +++ b/libavcodec/atrac3plus.c
> > > @@ -1768,7 +1768,7 @@ int ff_atrac3p_decode_channel_unit(GetBitContext
> > > *gb, Atrac3pChanUnitCtx *ctx,
> > >
> > > /* parse sound header */
> > > ctx->num_quant_units = get_bits(gb, 5) + 1;
> > >
> >
> > num_quant_units can only be <= (2^5 - 1) + 1, which is <= 32.
> >
> > This just makes it easier for GCC to see that.
> >
> >
> > > -if (ctx->num_quant_units > 28 && ctx->num_quant_units < 32) {
> > > +if (ctx->num_quant_units > 28 && ctx->num_quant_units != 32) {
> > > av_log(avctx, AV_LOG_ERROR,
> > > "Invalid number of quantization units: %d!\n",
> > > ctx->num_quant_units);
> > >
> >
>
> Maybe I'm missing something, but how does that
> justify != instead of <= ?
>
Before the compiler thinks:
"OK, the variable can be in the range [0, 28] U [32, INT_MAX]"
But because it is used as a array index, it can only be safely used < 32,
and hence the warning.
Now the compiler thinks:
"The variable can only be in the range [0, 28] U {32}."
<= won't work because it still makes 33 possible as far as the compiler is
concerned.
Timothy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
Hi, 2015-02-06 16:41 GMT+01:00 James Almer : > Wouldn't it be better to just use the same code as UNIX64 instead? Now that > we're going to load > the address of the table to a reg, there's not point in having a whole > separate init path for > WIN64. > One for X86_64 and one for X86_32 (Where applicable) is much cleaner. Sure. Hopefully, the difference in number of gpr-passed args between UNIX64 and WIN64 can be handled. -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Only run the tta crc checks if requested
On 06/02/15 6:15 AM, Carl Eugen Hoyos wrote:
> -crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> -if (crc != avio_rl32(s->pb) && s->error_recognition & AV_EF_CRCCHECK) {
> -av_log(s, AV_LOG_ERROR, "Header CRC error\n");
> -return AVERROR_INVALIDDATA;
> +if (s->error_recognition & AV_EF_CRCCHECK) {
> +crc = ffio_get_checksum(s->pb) ^ UINT32_MAX;
> +if (crc != avio_rl32(s->pb) && s->error_recognition &
> AV_EF_CRCCHECK) {
> +av_log(s, AV_LOG_ERROR, "Header CRC error\n");
> +return AVERROR_INVALIDDATA;
> +}
This is skipping avio_rl32() and not updating the pb pointer when crc is not
checked, which
is the same trap i feel into the first time.
Nonetheless, i didn't go with something like the above to keep it simple and
because this is
done when demuxing the header, which is extremely small and read only once
anyway.
This is certainly no bottleneck.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] x86/hevcdsp: add ff_hevc_sao_edge_filter_8_{ssse3, avx2}
On 06/02/15 1:02 PM, Christophe Gisquet wrote: > Sure. Hopefully, the difference in number of gpr-passed args between > UNIX64 and WIN64 can be handled. I'll send a patch in a moment. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] x86: hevc: remove a parameter to WP internals
2015-02-06 16:18 GMT+01:00 James Almer : > "mov r5d, denomm" is loading it on Win64. It's also a superfluous instruction > on > UNIX64, where it translates to "mov r5d, r5d". > At least if i'm reading this right. movifnidn then? -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] opt: Remove dead code
On Fri Feb 06 2015 at 1:28:09 AM Carl Eugen Hoyos wrote: > Timothy Gu gmail.com> writes: > > > if (!i || !*val) > > return 0; > > } > > - > > -return 0; > > } > > > I fear that some (broken) compilers will emit > a warning when this gets applied that we > request to be interpreted as an error. > Same for 3, 4 and 5. > Do you want to remove some warnings from some good compilers, or from some dumb compilers? I'd go with the first. > I don't remember if an assert helps. > Probably not. The assert will still be dead code, and the compiler still warns. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] x86: hevc_mc: add AVX2 optimizations
On Thu, Feb 05, 2015 at 09:15:28PM -0300, James Almer wrote: > On 05/02/15 4:20 PM, Christophe Gisquet wrote: > > From: plepere > > This should probably be changed to Pierre Edouard Lepere. changed [...] > > } > > > > c->transform_add[2] = ff_hevc_transform_add16_10_avx2; > > > > Should be ok if it passes fate works > and compiles with yasm <= 1.1.0 (there are C wrappers slow and works applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] x86/hevc_sao: fix loading of RIP address
pb_eo must be handled as a rip relative address for MSVC64, so an intermediate register is needed. Should fix link failures. Suggested by Hendrik Leppkes and Christophe Gisquet. Signed-off-by: James Almer --- libavcodec/x86/hevc_sao.asm | 42 +- 1 file changed, 9 insertions(+), 33 deletions(-) diff --git a/libavcodec/x86/hevc_sao.asm b/libavcodec/x86/hevc_sao.asm index 6058967..f4eca0c 100644 --- a/libavcodec/x86/hevc_sao.asm +++ b/libavcodec/x86/hevc_sao.asm @@ -293,24 +293,14 @@ HEVC_SAO_BAND_FILTER_16 12, 64, 2 ;void ff_hevc_sao_edge_filter__8_(uint8_t *_dst, uint8_t *_src, ptrdiff_t stride_dst, int16_t *sao_offset_val, ; int eo, int width, int height); %macro HEVC_SAO_EDGE_FILTER_8 2-3 +%if ARCH_X86_64 +cglobal hevc_sao_edge_filter_%1_8, 4, 9, 8, dst, src, dststride, offset, eo, a_stride, b_stride, height, tmp +%define tmp2q heightq %if WIN64 -cglobal hevc_sao_edge_filter_%1_8, 4, 8, 8, dst, src, dststride, offset, a_stride, b_stride, height, tmp -%define eoq heightq movsxd eoq, dword r4m -movsx a_strideq, byte [pb_eo+eoq*4+1] -movsx b_strideq, byte [pb_eo+eoq*4+3] -imul a_strideq, EDGE_SRCSTRIDE -imul b_strideq, EDGE_SRCSTRIDE -movsx tmpq, byte [pb_eo+eoq*4] -adda_strideq, tmpq -movsx tmpq, byte [pb_eo+eoq*4+2] -addb_strideq, tmpq -mov heightd, r6m - -%elif ARCH_X86_64 -cglobal hevc_sao_edge_filter_%1_8, 5, 9, 8, dst, src, dststride, offset, eo, a_stride, b_stride, height, tmp -%define tmp2q heightq +%else movsxd eoq, eod +%endif leatmp2q, [pb_eo] movsx a_strideq, byte [tmp2q+eoq*4+1] movsx b_strideq, byte [tmp2q+eoq*4+3] @@ -439,26 +429,13 @@ INIT_YMM cpuname ;void ff_hevc_sao_edge_filter___(uint8_t *_dst, uint8_t *_src, ptrdiff_t stride_dst, int16_t *sao_offset_val, ; int eo, int width, int height); %macro HEVC_SAO_EDGE_FILTER_16 3 +cglobal hevc_sao_edge_filter_%2_%1, 4, 9, 16, dst, src, dststride, offset, eo, a_stride, b_stride, height, tmp +%define tmp2q heightq %if WIN64 -cglobal hevc_sao_edge_filter_%2_%1, 4, 8, 16, dst, src, dststride, offset, a_stride, b_stride, height, tmp -%define eoq heightq movsxd eoq, dword r4m -movsx a_strideq, byte [pb_eo+eoq*4+1] -movsx b_strideq, byte [pb_eo+eoq*4+3] -imul a_strideq, EDGE_SRCSTRIDE>>1 -imul b_strideq, EDGE_SRCSTRIDE>>1 -movsx tmpq, byte [pb_eo+eoq*4] -adda_strideq, tmpq -movsx tmpq, byte [pb_eo+eoq*4+2] -addb_strideq, tmpq -mov heightd, r6m -adda_strideq, a_strideq -addb_strideq, b_strideq - -%else ; UNIX64 -cglobal hevc_sao_edge_filter_%2_%1, 5, 9, 16, dst, src, dststride, offset, eo, a_stride, b_stride, height, tmp -%define tmp2q heightq +%else movsxd eoq, eod +%endif leatmp2q, [pb_eo] movsx a_strideq, byte [tmp2q+eoq*4+1] movsx b_strideq, byte [tmp2q+eoq*4+3] @@ -471,7 +448,6 @@ cglobal hevc_sao_edge_filter_%2_%1, 5, 9, 16, dst, src, dststride, offset, eo, a mov heightd, r6m adda_strideq, a_strideq addb_strideq, b_strideq -%endif ; ARCH %if cpuflag(avx2) SPLATWm8, [offsetq+2] -- 2.2.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] x86: hevc_mc: use epel_hv 16-wide function
On Thu, Feb 05, 2015 at 07:20:40PM +, Christophe Gisquet wrote: > The epel_hv functions were still relying on only epel_hv 8-wide > being the maximum width instanciated. > --- > libavcodec/x86/hevcdsp_init.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) applied thanks [...] -- 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 3/7] x86/hevc: use CLIPW macro when possible
On Thu, Feb 05, 2015 at 09:28:41PM -0300, James Almer wrote: > On 05/02/15 4:20 PM, Christophe Gisquet wrote: > > From: Mickaël Raulet > > > > Conflicts: > > libavcodec/x86/hevc_mc.asm > > --- > > libavcodec/x86/hevc_mc.asm | 12 > > 1 file changed, 4 insertions(+), 8 deletions(-) > > > > diff --git a/libavcodec/x86/hevc_mc.asm b/libavcodec/x86/hevc_mc.asm > > index efb4d1f..e8a5032 100644 > > --- a/libavcodec/x86/hevc_mc.asm > > +++ b/libavcodec/x86/hevc_mc.asm > > @@ -665,11 +665,9 @@ QPEL_TABLE 10, 8, w, avx2 > > %if %2 == 8 > > packuswb %3, %4 > > %else > > -pminsw%3, [max_pixels_%2] > > -pmaxsw%3, [zero] > > +CLIPW %3, [zero], [max_pixels_%2] > > %if (%1 > 8 && notcpuflag(avx)) || %1 > 16 > > -pminsw%4, [max_pixels_%2] > > -pmaxsw%4, [zero] > > +CLIPW %4, [zero], [max_pixels_%2] > > Many (But not all) of the functions calling these macros have free regs where > max_pixels_%2 > and zero (or in that case a simple pxor m*, m*) could be stored. > It'll probably be faster than reloading these constants inside a loop. > > But again, that's for a different patch. > > > %endif > > %endif > > %endmacro > > @@ -1467,8 +1465,7 @@ cglobal hevc_put_hevc_uni_w%1_%2, 6, 6, 7, dst, > > dststride, src, srcstride, heigh > > %if %2 == 8 > > packuswb m0, m0 > > %else > > -pminswm0, [max_pixels_%2] > > -pmaxswm0, [zero] > > +CLIPW m0, [zero], [max_pixels_%2] > > %endif > > PEL_%2STORE%1 dstq, m0, m1 > > add dstq, dststrideq ; dst += dststride > > @@ -1539,8 +1536,7 @@ cglobal hevc_put_hevc_bi_w%1_%2, 5, 7, 10, dst, > > dststride, src, srcstride, src2, > > %if %2 == 8 > > packuswb m0, m0 > > %else > > -pminswm0, [max_pixels_%2] > > -pmaxswm0, [zero] > > + CLIPWm0, [zero], [max_pixels_%2] > > %endif > > PEL_%2STORE%1 dstq, m0, m1 > > add dstq, dststrideq ; dst += dststride > > > > lgtm otherwise. applied 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] x86/hevc_sao: fix loading of RIP address
Hi, 2015-02-06 17:54 GMT+01:00 James Almer : > pb_eo must be handled as a rip relative address for MSVC64, so an > intermediate register is needed. Should fix link failures. Seems ok on principle, passes fate on mingw64. I'm always wary of those ABI, so if anyone could verify for msvc64 and unix64 (in addition to yourself), that would be nice. > +%if ARCH_X86_64 > +cglobal hevc_sao_edge_filter_%1_8, 4, 9, 8, dst, src, dststride, offset, eo, > a_stride, b_stride, height, tmp > +%define tmp2q heightq > %if WIN64 > -cglobal hevc_sao_edge_filter_%1_8, 4, 8, 8, dst, src, dststride, offset, > a_stride, b_stride, height, tmp > -%define eoq heightq > movsxd eoq, dword r4m > -movsx a_strideq, byte [pb_eo+eoq*4+1] > -movsx b_strideq, byte [pb_eo+eoq*4+3] > -imul a_strideq, EDGE_SRCSTRIDE > -imul b_strideq, EDGE_SRCSTRIDE > -movsx tmpq, byte [pb_eo+eoq*4] > -adda_strideq, tmpq > -movsx tmpq, byte [pb_eo+eoq*4+2] > -addb_strideq, tmpq > -mov heightd, r6m > - > -%elif ARCH_X86_64 > -cglobal hevc_sao_edge_filter_%1_8, 5, 9, 8, dst, src, dststride, offset, eo, > a_stride, b_stride, height, tmp > -%define tmp2q heightq > +%else > movsxd eoq, eod > +%endif > leatmp2q, [pb_eo] > movsx a_strideq, byte [tmp2q+eoq*4+1] > movsx b_strideq, byte [tmp2q+eoq*4+3] The new common loading block could almost be abstracted in a single macro (with the stride as parameter). Something like: %macro LOAD_EO_ARGS 1 %define tmp2q heightq %if WIN64 movsxd eoq, dword r4m %else movsxd eoq, eod %endif leatmp2q, [pb_eo] movsx a_strideq, byte [tmp2q+eoq*4+1] movsx b_strideq, byte [tmp2q+eoq*4+3] imul a_strideq, %1 imul b_strideq, %1 movsx tmpq, byte [tmp2q+eoq*4] adda_strideq, tmpq movsx tmpq, byte [tmp2q+eoq*4+2] addb_strideq, tmpq mov heightd, r6m %endmacro (macro provided as example because it's probably clearer :D but not tested ) -- Christophe ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_sao: fix loading of RIP address
On Fri, Feb 6, 2015 at 6:10 PM, Christophe Gisquet wrote: > Hi, > > 2015-02-06 17:54 GMT+01:00 James Almer : >> pb_eo must be handled as a rip relative address for MSVC64, so an >> intermediate register is needed. Should fix link failures. > > Seems ok on principle, passes fate on mingw64. I'm always wary of > those ABI, so if anyone could verify for msvc64 and unix64 (in > addition to yourself), that would be nice. > >> +%if ARCH_X86_64 >> +cglobal hevc_sao_edge_filter_%1_8, 4, 9, 8, dst, src, dststride, offset, >> eo, a_stride, b_stride, height, tmp >> +%define tmp2q heightq Builds and passes fate using msvc64. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] x86: hevc: remove a parameter to WP internals
On 06/02/15 1:05 PM, Christophe Gisquet wrote: > 2015-02-06 16:18 GMT+01:00 James Almer : >> "mov r5d, denomm" is loading it on Win64. It's also a superfluous >> instruction on >> UNIX64, where it translates to "mov r5d, r5d". >> At least if i'm reading this right. > > movifnidn then? Yes, that should do it. And for that matter you were right, it should be "4, 6". I was reading it as regs loaded when the second argument is regs needed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] audioconvert: Add missing include for FF_API_AUDIO_CONVERT
On Thu, Feb 05, 2015 at 11:27:34PM -0800, Timothy Gu wrote: > Fixes warning in `make checkheaders`. > --- > libavcodec/audioconvert.h | 2 ++ > 1 file changed, 2 insertions(+) applied thanks -- 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] x86/hevc_sao: fix loading of RIP address
On 06/02/15 2:13 PM, Hendrik Leppkes wrote: > On Fri, Feb 6, 2015 at 6:10 PM, Christophe Gisquet > wrote: >> Hi, >> >> 2015-02-06 17:54 GMT+01:00 James Almer : >>> pb_eo must be handled as a rip relative address for MSVC64, so an >>> intermediate register is needed. Should fix link failures. >> >> Seems ok on principle, passes fate on mingw64. I'm always wary of >> those ABI, so if anyone could verify for msvc64 and unix64 (in >> addition to yourself), that would be nice. >> >>> +%if ARCH_X86_64 >>> +cglobal hevc_sao_edge_filter_%1_8, 4, 9, 8, dst, src, dststride, offset, >>> eo, a_stride, b_stride, height, tmp >>> +%define tmp2q heightq > > Builds and passes fate using msvc64. > > - Hendrik Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] generate_wave_table: Add include for AVSampleFormat
On Thu, Feb 05, 2015 at 11:27:35PM -0800, Timothy Gu wrote: > Fixes warning in `make checkheaders`. > --- > libavfilter/generate_wave_table.h | 2 ++ > 1 file changed, 2 insertions(+) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/hevc_sao: fix loading of RIP address
On 06/02/15 2:10 PM, Christophe Gisquet wrote: > The new common loading block could almost be abstracted in a single > macro (with the stride as parameter). > > Something like: > %macro LOAD_EO_ARGS 1 > %define tmp2q heightq > %if WIN64 > movsxd eoq, dword r4m > %else > movsxd eoq, eod > %endif > leatmp2q, [pb_eo] > movsx a_strideq, byte [tmp2q+eoq*4+1] > movsx b_strideq, byte [tmp2q+eoq*4+3] > imul a_strideq, %1 > imul b_strideq, %1 > movsx tmpq, byte [tmp2q+eoq*4] > adda_strideq, tmpq > movsx tmpq, byte [tmp2q+eoq*4+2] > addb_strideq, tmpq > mov heightd, r6m > %endmacro > > (macro provided as example because it's probably clearer :D but not tested ) I'll leave that for when i write the x86_32 version of sao_edge_filter_16, so the macro handles both arches. Patch applied, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/7] img2dec: Remove dead code
On Thu, Feb 05, 2015 at 11:06:40PM -0800, Timothy Gu wrote:
> ---
> libavformat/img2dec.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> index 1ab1309..8c5e9d5 100644
> --- a/libavformat/img2dec.c
> +++ b/libavformat/img2dec.c
> @@ -599,10 +599,8 @@ static int bmp_probe(AVProbeData *p)
>
> if (!AV_RN32(b + 6)) {
> return AVPROBE_SCORE_EXTENSION + 1;
> -} else {
> -return AVPROBE_SCORE_EXTENSION / 4;
> }
> -return 0;
> +return AVPROBE_SCORE_EXTENSION / 4;
Looks good to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] opt: Remove dead code
On Fri, Feb 06, 2015 at 04:07:36PM +, Timothy Gu wrote: > On Fri Feb 06 2015 at 1:28:09 AM Carl Eugen Hoyos wrote: > > > Timothy Gu gmail.com> writes: > > > > > if (!i || !*val) > > > return 0; > > > } > > > - > > > -return 0; > > > } > > > > > > > I fear that some (broken) compilers will emit > > a warning when this gets applied that we > > request to be interpreted as an error. > > Same for 3, 4 and 5. > > > > Do you want to remove some warnings from some good compilers, or from some > dumb compilers? I'd go with the first. Well, personally I don't like it when functions returning a value don't end with a return statement. Plus no matter how clever the compiler there's always going to be cases where it can't figure out that the end of the function is unreachable. In most cases it's also possible to reasonably avoid warnings with both. In the above case I guess you could replace the return 0 in the if by a break instead. In some cases risking a warning might be better than contorting the code... ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/lossless_audiodsp: fix compilation with --disable-yasm
On Fri, Feb 06, 2015 at 03:49:52AM -0300, James Almer wrote: > Signed-off-by: James Almer > --- > See > http://fate.ffmpeg.org/log.cgi?time=20150206062639&log=compile&slot=x86_64-darwin-gcc-4.6 > > libavcodec/x86/lossless_audiodsp_init.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) LGTM [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 2 "100% positive feedback" - "All either got their money back or didnt complain" "Best seller ever, very honest" - "Seller refunded buyer after failed scam" 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/7] img2dec: Remove dead code
On Fri, Feb 06, 2015 at 07:21:30PM +0100, Reimar Döffinger wrote:
> On Thu, Feb 05, 2015 at 11:06:40PM -0800, Timothy Gu wrote:
> > ---
> > libavformat/img2dec.c | 4 +---
> > 1 file changed, 1 insertion(+), 3 deletions(-)
> >
> > diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
> > index 1ab1309..8c5e9d5 100644
> > --- a/libavformat/img2dec.c
> > +++ b/libavformat/img2dec.c
> > @@ -599,10 +599,8 @@ static int bmp_probe(AVProbeData *p)
> >
> > if (!AV_RN32(b + 6)) {
> > return AVPROBE_SCORE_EXTENSION + 1;
> > -} else {
> > -return AVPROBE_SCORE_EXTENSION / 4;
> > }
> > -return 0;
> > +return AVPROBE_SCORE_EXTENSION / 4;
>
> Looks good to me.
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 6/7] nutdec: Remove unused variables
On Thu, Feb 05, 2015 at 11:06:44PM -0800, Timothy Gu wrote: > --- > libavformat/nutenc.c | 2 -- > 1 file changed, 2 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB It is what and why we do it that matters, not just one of them. 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] new option for drawtext (boxborderw = set box border width)
On 2/6/2015 5:11 AM, Nicolas George wrote: > The "box" that drawtext draws around the text is filled, it corresponds > to the "background" CSS property, and adding border in it corresponds > to what CSS calls "padding". Got confused by the borderw option, and based my name on what I expected borderw will actually do. I will rename boxborderw to padding and resubmit. ty for your patience. -- Liviu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [libav-devel] [RFC] Exporting the alpha mode from decoders
On Fri, Feb 6, 2015 at 11:32 AM, wm4 wrote:
> This is a proposal for an API extension.
>
> Currently, some pixel formats support alpha, but whether the alpha
> component contains something useful or just garbage is not part of the
> pixel format definition. This applies at least to packed RGB formats,
> where the 4th component is either alpha or garbage depending on the
> context.
>
> This means that if a decoder outputs such a packed RGB format, an API
> user has no idea whether it has alpha or not. E.g. take PNG and
> Camtasia (tscc.c). PNG with alpha outputs AV_PIX_FMT_RGBA, and Camtasia
> can output AV_PIX_FMT_RGB32 (which is ARGB or BGRA depending on
> endian). Camtasia supports no alpha, and the alpha component literally
> contains garbage (AFAIK and judging by the single sample I've seen). An
> application decoding both of these can't know whether the output frame
> has alpha or not, unless every codec is special-cased.
>
> One possible solution is duplicating all these pixel formats, so you'd
> have e.g. AV_PIX_FMT_RGBA and AV_PIX_FMT_RGBX. But I think we all agree
> that we don't want more pixel formats.
>
> The other solution, which I want to advocate here, is adding a field to
> AVFrame that indicates the alpha mode. Something like:
>
> typedef enum AVAlphaMode {
> // if an alpha component is present, its function is unknown, and
> // it may be garbage
> AV_ALPHA_UNKNOWN,
> // the alpha component contains premultiplied alpha
> // (not sure if any file format actually uses this)
> AV_ALPHA_PREMULTIPLIED,
> // the alpha component contains straight alpha
> // (e.g. PNG)
> AV_ALPHA_STRAIGHT,
> } AVAlphaMode;
>
> typedef struct AVFrame {
> ...
> AVAlphaMode alpha_mode;
> } AVFrame;
>
> Thoughts?
The problem looks interesting. I am not sure samples with
premultiplied alpha exist (or what swscale does in that case).
Another approach could be to expand avframe->flag, in order to signal
when alpha channel contains garbage, rather than introducing a new
field.
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] flac: ignore duplicated ID3 tags if vorbis tags exist
On Thu, 5 Feb 2015 22:57:07 -0500 Ben Boeckel wrote: > FLAC doesn't really support ID3 tags, so warn if they are found at all. > If vorbis tags are found, toss out duplicate ID3 tags. > > Fixes #3799. > Discussing this topic further, it seems id3v2 tags really can happen with literally almost any container format, including mp4 and ogg. Many of these formats will have the same problems. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] avutil/pixfmt: Clarify the meaning of the alpha byte in RGB0 and similar formats
Found-by: wm4
Signed-off-by: Michael Niedermayer
---
libavutil/pixfmt.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index ef1837f..9f4928e 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -255,10 +255,10 @@ enum AVPixelFormat {
AV_PIX_FMT_BGRA64BE, ///< packed RGBA 16:16:16:16, 64bpp, 16B, 16G, 16R,
16A, the 2-byte value for each R/G/B/A component is stored as big-endian
AV_PIX_FMT_BGRA64LE, ///< packed RGBA 16:16:16:16, 64bpp, 16B, 16G, 16R,
16A, the 2-byte value for each R/G/B/A component is stored as little-endian
#endif
-AV_PIX_FMT_0RGB=0x123+4, ///< packed RGB 8:8:8, 32bpp, 0RGB0RGB...
-AV_PIX_FMT_RGB0, ///< packed RGB 8:8:8, 32bpp, RGB0RGB0...
-AV_PIX_FMT_0BGR, ///< packed BGR 8:8:8, 32bpp, 0BGR0BGR...
-AV_PIX_FMT_BGR0, ///< packed BGR 8:8:8, 32bpp, BGR0BGR0...
+AV_PIX_FMT_0RGB=0x123+4,///< packed RGB 8:8:8, 32bpp, uRGBuRGB...
u=unused/undefined (often 0)
+AV_PIX_FMT_RGB0,///< packed RGB 8:8:8, 32bpp, RGBuRGBu...
u=unused/undefined (often 0)
+AV_PIX_FMT_0BGR,///< packed BGR 8:8:8, 32bpp, uBGRuBGR...
u=unused/undefined (often 0)
+AV_PIX_FMT_BGR0,///< packed BGR 8:8:8, 32bpp, BGRuBGRu...
u=unused/undefined (often 0)
AV_PIX_FMT_YUVA444P, ///< planar YUV 4:4:4 32bpp, (1 Cr & Cb sample per
1x1 Y & A samples)
AV_PIX_FMT_YUVA422P, ///< planar YUV 4:2:2 24bpp, (1 Cr & Cb sample per
2x1 Y & A samples)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] avutil/pixfmt: Clarify the meaning of the "alpha" bit in rgb555/bgr555
Found-by: wm4
Signed-off-by: Michael Niedermayer
---
libavutil/pixfmt.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 9f4928e..cbcccb2 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -118,13 +118,13 @@ enum AVPixelFormat {
AV_PIX_FMT_RGB565BE, ///< packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb),
big-endian
AV_PIX_FMT_RGB565LE, ///< packed RGB 5:6:5, 16bpp, (msb) 5R 6G 5B(lsb),
little-endian
-AV_PIX_FMT_RGB555BE, ///< packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb),
big-endian, most significant bit to 0
-AV_PIX_FMT_RGB555LE, ///< packed RGB 5:5:5, 16bpp, (msb)1A 5R 5G 5B(lsb),
little-endian, most significant bit to 0
+AV_PIX_FMT_RGB555BE, ///< packed RGB 5:5:5, 16bpp, (msb)1u 5R 5G 5B(lsb),
big-endian, most significant bit to 0
+AV_PIX_FMT_RGB555LE, ///< packed RGB 5:5:5, 16bpp, (msb)1u 5R 5G 5B(lsb),
little-endian, most significant bit to 0
AV_PIX_FMT_BGR565BE, ///< packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb),
big-endian
AV_PIX_FMT_BGR565LE, ///< packed BGR 5:6:5, 16bpp, (msb) 5B 6G 5R(lsb),
little-endian
-AV_PIX_FMT_BGR555BE, ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb),
big-endian, most significant bit to 1
-AV_PIX_FMT_BGR555LE, ///< packed BGR 5:5:5, 16bpp, (msb)1A 5B 5G 5R(lsb),
little-endian, most significant bit to 1
+AV_PIX_FMT_BGR555BE, ///< packed BGR 5:5:5, 16bpp, (msb)1u 5B 5G 5R(lsb),
big-endian, most significant bit to 1
+AV_PIX_FMT_BGR555LE, ///< packed BGR 5:5:5, 16bpp, (msb)1u 5B 5G 5R(lsb),
little-endian, most significant bit to 1
AV_PIX_FMT_VAAPI_MOCO, ///< HW acceleration through VA API at motion
compensation entry-point, Picture.data[3] contains a vaapi_render_state struct
which contains macroblocks as well as various fields extracted from headers
AV_PIX_FMT_VAAPI_IDCT, ///< HW acceleration through VA API at IDCT
entry-point, Picture.data[3] contains a vaapi_render_state struct which
contains fields extracted from headers
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats
Signed-off-by: Michael Niedermayer
---
libavutil/pixfmt.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index cbcccb2..cee5f2c 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -141,10 +141,10 @@ enum AVPixelFormat {
#endif
AV_PIX_FMT_DXVA2_VLD,///< HW decoding through DXVA2, Picture.data[3]
contains a LPDIRECT3DSURFACE9 pointer
-AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb),
little-endian, most significant bits to 0
-AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G 4B(lsb),
big-endian, most significant bits to 0
-AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb),
little-endian, most significant bits to 1
-AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G 4R(lsb),
big-endian, most significant bits to 1
+AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G 4B(lsb),
little-endian, most significant bits to 0
+AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G 4B(lsb),
big-endian, most significant bits to 0
+AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G 4R(lsb),
little-endian, most significant bits to 1
+AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G 4R(lsb),
big-endian, most significant bits to 1
AV_PIX_FMT_YA8, ///< 8bit gray, 8bit alpha
AV_PIX_FMT_Y400A = AV_PIX_FMT_YA8, ///< alias for AV_PIX_FMT_YA8
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, Feb 06, 2015 at 01:48:07PM +0100, wm4 wrote: > On Fri, 6 Feb 2015 12:10:59 + (UTC) > Carl Eugen Hoyos wrote: > > > wm4 googlemail.com> writes: > > > > > > I will fix this later if nobody beats me. > > > > > > How do you intend to beat this? > > > > Setting it to 0RGB32 instead of RGB32. > > Unrelated to your API suggestion, this is a > > bug in FFmpeg that we should fix. > > > > > Explicitly writing the alpha component? > > > (I was assuming this was a no-go.) > > > > We do this in many cases but it is not > > necessary in this case. > > > > Concerning your API suggestion, the pix_fmt > > should always tell you if there is a useful > > transparency layer or not. If this is not > > done correctly in some cases, I would like > > to fix them. > > The pixfmt docs seems to imply that the extra component must be set to > 0 if a RGB0 format is used. Camtasia puts random stuff. > > What about AV_PIX_FMT_RGB555? It's documented as having 1 alpha bit, > though it doesn't have the alpha pixfmt flag set. Fix the docs? Or > introduce RGB05551? > > There is no AV_PIX_FMT_RGB064. Is it guaranteed that there is no 64 bit > format with padding? If one ever exists, is it guaranteed that a 0 > variant will be added? if such pixfmt would be needed it should be added [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
wm4 googlemail.com> writes: > The pixfmt docs seems to imply that the extra > component must be set to 0 if a RGB0 format is > used. Camtasia puts random stuff. The documentation sounds wrong to me: The pix_fmt was needed because of hardware providing 32bit rgb, there is no guarantee what the X bits contain and it makes no sense for FFmpeg to require a specific content. It is good behaviour that libswscale writes a defined value though (as it does iirc). (This is unrelated but I don't think "random" is the right word in above sequence: The fact that I did not interpret the alpha value as random was apparently the reason I never changed the pix_fmt. But you are clearly right that RGB32 is wrong.) > What about AV_PIX_FMT_RGB555? It's documented > as having 1 alpha bit I believe this is a documentation issue, see rgb15to32_c() in libswscale. > though it doesn't have the alpha pixfmt flag set. > Fix the docs? Or introduce RGB05551? Atm, I cannot remember a sample that supports alpha in RGB555 (I do remember that it is defined in some specs though). > There is no AV_PIX_FMT_RGB064. > Is it guaranteed that there is no 64 bit > format with padding? FFmpeg "promises" that RGBA64 contains a valid alpha channel, just as FFmpeg "promises" bit- exact H.264 decoding. > If one ever exists, is it guaranteed that a 0 > variant will be added? I cannot imagine a screen driver that provides 64 bit rgb screen grabs but please prove me wrong! Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH]Only run the tta crc checks if requested
James Almer gmail.com> writes: > This is skipping avio_rl32() and not updating > the pb pointer when crc is not checked Sorry, please ignore. Carl Eugen ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/lossless_audiodsp: fix compilation with --disable-yasm
On 06/02/15 4:11 PM, Michael Niedermayer wrote: > On Fri, Feb 06, 2015 at 03:49:52AM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> See >> http://fate.ffmpeg.org/log.cgi?time=20150206062639&log=compile&slot=x86_64-darwin-gcc-4.6 >> >> libavcodec/x86/lossless_audiodsp_init.c | 8 >> 1 file changed, 4 insertions(+), 4 deletions(-) > > LGTM Pushed, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/7] x86/hevc_mc: use aligned loads
On Thu, Feb 05, 2015 at 07:20:42PM +, Christophe Gisquet wrote: > From: Mickaël Raulet > > --- > libavcodec/hevc.h | 2 +- > libavcodec/x86/hevc_mc.asm | 6 +++--- > 2 files changed, 4 insertions(+), 4 deletions(-) applied thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Awnsering whenever a program halts or runs forever is On a turing machine, in general impossible (turings halting problem). On any real computer, always possible as a real computer has a finite number of states N, and will either halt in less than N cycles or never halt. 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] avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats
On Fri, 6 Feb 2015 20:57:50 +0100
Michael Niedermayer wrote:
> Signed-off-by: Michael Niedermayer
> ---
> libavutil/pixfmt.h |8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> index cbcccb2..cee5f2c 100644
> --- a/libavutil/pixfmt.h
> +++ b/libavutil/pixfmt.h
> @@ -141,10 +141,10 @@ enum AVPixelFormat {
> #endif
> AV_PIX_FMT_DXVA2_VLD,///< HW decoding through DXVA2, Picture.data[3]
> contains a LPDIRECT3DSURFACE9 pointer
>
> -AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> 4B(lsb), little-endian, most significant bits to 0
> -AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> 4B(lsb), big-endian, most significant bits to 0
> -AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> 4R(lsb), little-endian, most significant bits to 1
> -AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> 4R(lsb), big-endian, most significant bits to 1
> +AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> 4B(lsb), little-endian, most significant bits to 0
> +AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> 4B(lsb), big-endian, most significant bits to 0
> +AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> 4R(lsb), little-endian, most significant bits to 1
> +AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> 4R(lsb), big-endian, most significant bits to 1
> AV_PIX_FMT_YA8, ///< 8bit gray, 8bit alpha
>
> AV_PIX_FMT_Y400A = AV_PIX_FMT_YA8, ///< alias for AV_PIX_FMT_YA8
Doesn't explain what "u" means. Also, what does it mean by "most
significant bits to 1"?
Rest of the patches look fine to me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats
On Fri, Feb 06, 2015 at 09:49:17PM +0100, wm4 wrote:
> On Fri, 6 Feb 2015 20:57:50 +0100
> Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavutil/pixfmt.h |8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > index cbcccb2..cee5f2c 100644
> > --- a/libavutil/pixfmt.h
> > +++ b/libavutil/pixfmt.h
> > @@ -141,10 +141,10 @@ enum AVPixelFormat {
> > #endif
> > AV_PIX_FMT_DXVA2_VLD,///< HW decoding through DXVA2,
> > Picture.data[3] contains a LPDIRECT3DSURFACE9 pointer
> >
> > -AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> > 4B(lsb), little-endian, most significant bits to 0
> > -AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> > 4B(lsb), big-endian, most significant bits to 0
> > -AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> > 4R(lsb), little-endian, most significant bits to 1
> > -AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> > 4R(lsb), big-endian, most significant bits to 1
> > +AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> > 4B(lsb), little-endian, most significant bits to 0
> > +AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> > 4B(lsb), big-endian, most significant bits to 0
> > +AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> > 4R(lsb), little-endian, most significant bits to 1
> > +AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> > 4R(lsb), big-endian, most significant bits to 1
> > AV_PIX_FMT_YA8, ///< 8bit gray, 8bit alpha
> >
> > AV_PIX_FMT_Y400A = AV_PIX_FMT_YA8, ///< alias for AV_PIX_FMT_YA8
>
> Doesn't explain what "u" means. Also, what does it mean by "most
> significant bits to 1"?
Minor comment: Other specifications (for example DirectX) use "X"
to mean unused.
I.e. DirectX has both RGBA and RGBX formats for example.
Or more commonly D24S8 vs. D24X8 for a depth texture with
and without stencil.
I don't mind much, but if you don't care I'm for being
consistent with conventions others are using already.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [RFC] Exporting the alpha mode from decoders
On Fri, 6 Feb 2015 20:16:50 + (UTC) Carl Eugen Hoyos wrote: > wm4 googlemail.com> writes: > > > The pixfmt docs seems to imply that the extra > > component must be set to 0 if a RGB0 format is > > used. Camtasia puts random stuff. > > The documentation sounds wrong to me: The pix_fmt > was needed because of hardware providing 32bit rgb, > there is no guarantee what the X bits contain and > it makes no sense for FFmpeg to require a specific > content. > It is good behaviour that libswscale writes a > defined value though (as it does iirc). > > (This is unrelated but I don't think "random" is > the right word in above sequence: The fact that > I did not interpret the alpha value as random > was apparently the reason I never changed the > pix_fmt. But you are clearly right that RGB32 is > wrong.) > > > What about AV_PIX_FMT_RGB555? It's documented > > as having 1 alpha bit > > I believe this is a documentation issue, see > rgb15to32_c() in libswscale. > > > though it doesn't have the alpha pixfmt flag set. > > Fix the docs? Or introduce RGB05551? > > Atm, I cannot remember a sample that supports > alpha in RGB555 (I do remember that it is > defined in some specs though). > > > There is no AV_PIX_FMT_RGB064. > > > Is it guaranteed that there is no 64 bit > > format with padding? > > FFmpeg "promises" that RGBA64 contains a valid > alpha channel, just as FFmpeg "promises" bit- > exact H.264 decoding. > > > If one ever exists, is it guaranteed that a 0 > > variant will be added? > > I cannot imagine a screen driver that provides > 64 bit rgb screen grabs but please prove me wrong! > If all these things are guaranteed, then I have no problems with the current solution. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] ffprobe: Change string_validation to int, its accessed via AVOption as int
On Fri, Feb 06, 2015 at 11:20:03AM +0100, Stefano Sabatini wrote: > On date Thursday 2015-02-05 23:03:56 +0100, Michael Niedermayer encoded: > > On Thu, Feb 05, 2015 at 12:10:12PM +0100, Stefano Sabatini wrote: > > > On date Wednesday 2015-02-04 16:10:03 +0100, Michael Niedermayer encoded: > [...] > > > > > the enum might be a different data type than int, it might have > > > > > a different sizeof() than sizeof(int), av_opt accessing it could > > > > > fail. > > > > > > Is it a theoretical difference or does it affect some > > > platform/compiler? In that case, could be a defect in the > > > platform/compiler? > > > > gcc on some embeded platforms seems to use types smaller than int > > when it can by default. You can get the same behavior with > > -fshort-enums on x86 if you like to try, > > > > gcc on linux x86 will also use int64_t if a enum constant is too > > large for 32bit idependant of the short enum flag > > > > > > > > > > From my reading of the C spec, enums and int should be treated in the > > > same way by the compiler, but I'm probably wrong. > > > > 6.7.2.2 Enumeration specifiers > > ... > > 4 Each enumerated type shall be compatible with char, a signed integer > > type, or an > > unsigned integer type. The choice of type is implementation-defined,110) > > but shall be > > capable of representing the values of all the members of the enumeration. > > The > > enumerated type is incomplete until after the } that terminates the list > > of enumerator > > declarations. > > Thanks for taking the time for elaborating this reply. I'm fine with > the patch. > > Still better would be to extend av_opt() code as you suggested. Also > documenting this shouldn't be bad actually we dont need any changes to av_opt, just a value would need to be added to each affected enum this would work because above quote says that enum must be compatible to a integer type and by adding a appropriately sized value we force this type to int (or larger) and comparible types may alias each other so accesing it via an int pointer is safe in that case 7 An object shall have its stored value accessed only by an lvalue expression that has one of the following types:76) # a type compatible with the effective type of the object, # a qualified version of a type compatible with the effective type of the object, # a type that is the signed or unsigned type corresponding to the effective type of the object, # a type that is the signed or unsigned type corresponding to a qualified version of the effective type of the object, # an aggregate or union type that includes one of the aforementioned types among its members (including, recursively, a member of a subaggregate or contained union), or # a character type. > (and I guess we have a lot of places > where we use enums in options, right?). yes, there are a few more [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The educated differ from the uneducated as much as the living from the dead. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avutil/pixfmt: Clarify the meaning of the alpha bits in rgb444 and similar formats
On Fri, 6 Feb 2015 21:55:49 +0100
Reimar Döffinger wrote:
> On Fri, Feb 06, 2015 at 09:49:17PM +0100, wm4 wrote:
> > On Fri, 6 Feb 2015 20:57:50 +0100
> > Michael Niedermayer wrote:
> >
> > > Signed-off-by: Michael Niedermayer
> > > ---
> > > libavutil/pixfmt.h |8
> > > 1 file changed, 4 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
> > > index cbcccb2..cee5f2c 100644
> > > --- a/libavutil/pixfmt.h
> > > +++ b/libavutil/pixfmt.h
> > > @@ -141,10 +141,10 @@ enum AVPixelFormat {
> > > #endif
> > > AV_PIX_FMT_DXVA2_VLD,///< HW decoding through DXVA2,
> > > Picture.data[3] contains a LPDIRECT3DSURFACE9 pointer
> > >
> > > -AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> > > 4B(lsb), little-endian, most significant bits to 0
> > > -AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4A 4R 4G
> > > 4B(lsb), big-endian, most significant bits to 0
> > > -AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> > > 4R(lsb), little-endian, most significant bits to 1
> > > -AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4A 4B 4G
> > > 4R(lsb), big-endian, most significant bits to 1
> > > +AV_PIX_FMT_RGB444LE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> > > 4B(lsb), little-endian, most significant bits to 0
> > > +AV_PIX_FMT_RGB444BE, ///< packed RGB 4:4:4, 16bpp, (msb)4u 4R 4G
> > > 4B(lsb), big-endian, most significant bits to 0
> > > +AV_PIX_FMT_BGR444LE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> > > 4R(lsb), little-endian, most significant bits to 1
> > > +AV_PIX_FMT_BGR444BE, ///< packed BGR 4:4:4, 16bpp, (msb)4u 4B 4G
> > > 4R(lsb), big-endian, most significant bits to 1
> > > AV_PIX_FMT_YA8, ///< 8bit gray, 8bit alpha
> > >
> > > AV_PIX_FMT_Y400A = AV_PIX_FMT_YA8, ///< alias for AV_PIX_FMT_YA8
> >
> > Doesn't explain what "u" means. Also, what does it mean by "most
> > significant bits to 1"?
>
> Minor comment: Other specifications (for example DirectX) use "X"
> to mean unused.
> I.e. DirectX has both RGBA and RGBX formats for example.
> Or more commonly D24S8 vs. D24X8 for a depth texture with
> and without stencil.
> I don't mind much, but if you don't care I'm for being
> consistent with conventions others are using already.
I agree; though fixing the name is probably a bit too late.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] ffprobe: Force string_validation to int type, its accessed via AVOption as int
Signed-off-by: Michael Niedermayer
---
ffprobe.c |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/ffprobe.c b/ffprobe.c
index d352bb6b..8617c96 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -294,7 +294,8 @@ typedef enum {
WRITER_STRING_VALIDATION_FAIL,
WRITER_STRING_VALIDATION_REPLACE,
WRITER_STRING_VALIDATION_IGNORE,
-WRITER_STRING_VALIDATION_NB
+WRITER_STRING_VALIDATION_NB,
+WRITER_STRING_VALIDATION_FORCE_ENUM_TO_INT_TYPE= 0x76543210,
} StringValidation;
typedef struct Writer {
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv4] flac: ignore duplicated ID3 tags if vorbis tags exist
On Fri, Feb 06, 2015 at 02:44:06AM -0300, James Almer wrote: > On 06/02/15 12:57 AM, Ben Boeckel wrote: > > +if (s->error_recognition & AV_EF_COMPLIANT) > > +level = AV_LOG_ERROR; > > +av_log(s, level, "Spec-compliant FLAC do not support ID3 tags.\n"); > > As i said back when i mentioned this flag to you (and Timothy just > confirmed), if > AV_EF_COMPLIANT is set then it should also return AVERROR_INVALIDDATA and not > just > show a warning/error. AV_EF_COMPLIANTs "consider all spec non compliancies as errors" was intended as means to detect bitstream errors to guide/trigger error concealment. That is in the sense of where to draw the line between which odities are bitstream errors and should trigger concealment and which are encoder odities and should be decoded as if they are intended by the encoder to be that way. Drawing this line at the wrong place can reduce the effectivity of error concealment of damaged files as well as break decoding of undamaged odd files at the other end. Using the option to abort on non mp3 files with id3 tags would make it difficult to use the option for its originally intended purpose as it would always break decoding affected files hard erroring out with no atempt to somehow recover should probably only happen when AV_EF_EXPLODE is set unless its near certain that continuing is not possible. (this may be the case for CRC errors in critical headers) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/7] x86: lavc: share more constants
On Thu, Feb 05, 2015 at 06:03:40PM -0500, Ronald S. Bultje wrote: > Hi, > > On Thu, Feb 5, 2015 at 2:20 PM, Christophe Gisquet < > christophe.gisq...@gmail.com> wrote: > > > diff --git a/libavcodec/x86/vp9intrapred.asm > > b/libavcodec/x86/vp9intrapred.asm > > index 169676f..08b3ae8 100644 > > --- a/libavcodec/x86/vp9intrapred.asm > > +++ b/libavcodec/x86/vp9intrapred.asm > > @@ -64,8 +64,7 @@ pb_6xm1_BDF_0to6: times 6 db -1 > >db 11, 13, 15, 0, 1, 2, 3, 4, 5, 6 > > pb_02468ACE_13579BDF: db 0, 2, 4, 6, 8, 10, 12, 14, 1, 3, 5, 7, 9, 11, > > 13, 15 > > > > -pb_2: times 32 db 2 > > -pb_15: times 16 db 15 > > +cextern pb_15 > > pb_15x0_1xm1: times 15 db 0 > >db -1 > > pb_0to2_5x3: db 0, 1, 2 > > @@ -76,6 +75,7 @@ pb_6x0_2xm1: times 6 db 0 > > times 2 db -1 > > > > cextern pb_1 > > +cextern pb_2 > > cextern pb_3 > > cextern pw_2 > > cextern pw_4 > > > Odd location for the cextern pb_15? changed > Otherwise OK. applied thanks [...] -- 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
[FFmpeg-devel] [PATCH] avutil/ppc: Add macro defination of vector types and vector
Hi, The attached patch add macro defination of vector types and vector base types. Add function printv for dev purpose. Our team is working on AltiVec functions for HEVC decoder. Best regards, Zhenan, ICST@PKU ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avutil/ppc: Add macro defination of vector types and vector
Hi, The attached patch add macro defination of vector types and vector base types. Add function printv for dev purpose. Our team is working on AltiVec functions for HEVC decoder. Best regards, Zhenan avutil-ppc-Add-macro-defination-of-vector-types.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] atrac3plus: Prevent array out-of-bounds
On Fri, Feb 06, 2015 at 07:32:56AM +, Timothy Gu wrote: > On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu wrote: > > > (num_quant_units - 1) is later used as an index to atrac3p_qu_to_subband, > > which only has 32 elements (i.e. maximum of num_quant_units is 32). > > --- > > libavcodec/atrac3plus.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > Note that this doesn't actually fix any problem else than a GCC warning. when i read the commit message it sounded like it fixes a serious bug ... also the exact warning which is fixed could be mentioned in the commit message [...] -- 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 7/7] atrac3plus: Prevent array out-of-bounds
On Fri Feb 06 2015 at 7:44:23 PM Michael Niedermayer wrote: > On Fri, Feb 06, 2015 at 07:32:56AM +, Timothy Gu wrote: > > On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu > wrote: > > > > > (num_quant_units - 1) is later used as an index to > atrac3p_qu_to_subband, > > > which only has 32 elements (i.e. maximum of num_quant_units is 32). > > > --- > > > libavcodec/atrac3plus.c | 2 +- > > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > > > > Note that this doesn't actually fix any problem else than a GCC warning. > > when i read the commit message it sounded like it fixes a serious > bug ... > also the exact warning which is fixed could be mentioned in the > commit message > Yeah I've been meant to add my second mail to the commit message, but haven't found the time to use Git yet. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] atrac3plus: Prevent array out-of-bounds
On Fri Feb 06 2015 at 7:55:31 PM Timothy Gu wrote: > On Fri Feb 06 2015 at 7:44:23 PM Michael Niedermayer > wrote: > >> On Fri, Feb 06, 2015 at 07:32:56AM +, Timothy Gu wrote: >> > On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu >> wrote: >> > >> > > (num_quant_units - 1) is later used as an index to >> atrac3p_qu_to_subband, >> > > which only has 32 elements (i.e. maximum of num_quant_units is 32). >> > > --- >> > > libavcodec/atrac3plus.c | 2 +- >> > > 1 file changed, 1 insertion(+), 1 deletion(-) >> > > >> > >> > Note that this doesn't actually fix any problem else than a GCC warning. >> >> when i read the commit message it sounded like it fixes a serious >> bug ... >> also the exact warning which is fixed could be mentioned in the >> commit message >> > > Yeah I've been meant to add my second mail to the commit message, but > haven't found the time to use Git yet. > Actually I misread the warning message (GCC is smarter than I thought). New patch incoming. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 7/7] atrac3plus: Prevent array out-of-bounds
Actually GCC is too dumb. There is literally no way to "fix" this in a clean way. Patch dropped. On Fri Feb 06 2015 at 7:57:33 PM Timothy Gu wrote: > On Fri Feb 06 2015 at 7:55:31 PM Timothy Gu wrote: > >> On Fri Feb 06 2015 at 7:44:23 PM Michael Niedermayer >> wrote: >> >>> On Fri, Feb 06, 2015 at 07:32:56AM +, Timothy Gu wrote: >>> > On Thu Feb 05 2015 at 11:07:01 PM Timothy Gu >>> wrote: >>> > >>> > > (num_quant_units - 1) is later used as an index to >>> atrac3p_qu_to_subband, >>> > > which only has 32 elements (i.e. maximum of num_quant_units is 32). >>> > > --- >>> > > libavcodec/atrac3plus.c | 2 +- >>> > > 1 file changed, 1 insertion(+), 1 deletion(-) >>> > > >>> > >>> > Note that this doesn't actually fix any problem else than a GCC >>> warning. >>> >>> when i read the commit message it sounded like it fixes a serious >>> bug ... >>> also the exact warning which is fixed could be mentioned in the >>> commit message >>> >> >> Yeah I've been meant to add my second mail to the commit message, but >> haven't found the time to use Git yet. >> > > Actually I misread the warning message (GCC is smarter than I thought). > New patch incoming. > > Timothy > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] pixdesc: Include more functions in FF_DISABLE_DEPRECATION_WARNINGS
---
libavutil/pixdesc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index 648d014..d52e9b6 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2049,7 +2049,6 @@ enum AVPixelFormat av_pix_fmt_desc_get_id(const
AVPixFmtDescriptor *desc)
return desc - av_pix_fmt_descriptors;
}
-FF_ENABLE_DEPRECATION_WARNINGS
int av_pix_fmt_get_chroma_sub_sample(enum AVPixelFormat pix_fmt,
int *h_shift, int *v_shift)
@@ -2118,6 +2117,7 @@ void ff_check_pixfmt_descriptors(void){
}
}
}
+FF_ENABLE_DEPRECATION_WARNINGS
enum AVPixelFormat av_pix_fmt_swap_endianness(enum AVPixelFormat pix_fmt)
--
1.9.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Rollup support in Closed caption
On Fri, Feb 06, 2015 at 08:22:40PM +0530, Anshul wrote:
>
> On 01/30/2015 08:49 AM, Anshul wrote:
> >On January 30, 2015 4:23:08 AM IST, Michael Niedermayer
> >wrote:
> >>@@ -426,10 +466,13 @@ static int process_cc608(CCaptionSubContext
> >>*ctx, int64_t pts, uint8_t hi, uint8
> >>> handle_delete_end_of_row(ctx, hi, lo);
> >>> } else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x25 ) {
> >>> ctx->rollup = 2;
> >>>+ctx->mode = CCMODE_ROLLUP_2;
> >>> } else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x26 ) {
> >>> ctx->rollup = 3;
> >>>+ctx->mode = CCMODE_ROLLUP_3;
> >>> } else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x27 ) {
> >>> ctx->rollup = 4;
> >>>+ctx->mode = CCMODE_ROLLUP_3;
> >>is this intended to be CCMODE_ROLLUP_3 instead of CCMODE_ROLLUP_4 ?
> >>
> >>also do you have a file to test this and the other patches ?
> >>
> >>thanks
> >>
> >>[...]
> >I tested this on bmd live video, all the rollup values were not tested, I
> >implemented this feature when roll up 2 was coming.
> >
> >I will check the database of ccextractor, if I get some video with different
> >rollup.
> >
> >
> >-Anshul
> >
> I have attached the patch which were not commited, In the rollup
> functionality there was one more
> bug other then typo, the first line was lost while converting the cc.
> I have corrected that.
>
> Here
>
> is video with rollup in closed caption.
how can this be used for testing ?
do you have a command line with that video that shows a difference
with the patches ?
the patches themselfs look good
[...]
> @@ -187,7 +187,7 @@ static av_cold int init_decoder(AVCodecContext *avctx)
> ret = AVERROR(ENOMEM);
> }
>
> -
> +fail:
> return ret;
> }
>
i moved this hunk to the 2nd patch and applied first and second
with also module "avcodec/..." prefixes in the commit messages
Thanks
[...]
--
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] hevc/sao: do in-place band filtering when possible
On 05/02/15 2:44 PM, Christophe Gisquet wrote: > On the other hand, the stride is known at compilation time, so the asm > could use that to reduce the number of gprs and therefore helps having > a x86_32 version. I already have the asm working on x86_32. I'll send a patch once this is committed. > From 55047bbb991c95f126d597bbe05e424406af4ec4 Mon Sep 17 00:00:00 2001 > From: Christophe Gisquet > Date: Tue, 3 Feb 2015 14:06:39 +0100 > Subject: [PATCH] hevc/sao: do in-place band filtering when possible > > The copies are only needed when data must be restored, so skip them > when it must not be. > --- > libavcodec/hevc_filter.c | 11 +-- > 1 file changed, 9 insertions(+), 2 deletions(-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] x86/swr: fix pack_8ch functions on compilers without aligned stack
On 11/01/15 10:48 AM, Michael Niedermayer wrote: > On Tue, Jan 06, 2015 at 02:04:12AM -0300, James Almer wrote: >> Signed-off-by: James Almer >> --- >> I don't have MSVC or ICL 10.x, so i only tested this with gcc after forcing >> HAVE_ALIGNED_STACK to 0 in config.asm > > can someone who has ICL/MSVC setup test this please > failing that, lets apply the patch Ping? If nobody can test it then I'll just apply it and wait for FATE to confirm it works or not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Adding Rollup support in Closed caption
On 02/07/2015 10:30 AM, Michael Niedermayer wrote:
On Fri, Feb 06, 2015 at 08:22:40PM +0530, Anshul wrote:
On 01/30/2015 08:49 AM, Anshul wrote:
On January 30, 2015 4:23:08 AM IST, Michael Niedermayer
wrote:
@@ -426,10 +466,13 @@ static int process_cc608(CCaptionSubContext
*ctx, int64_t pts, uint8_t hi, uint8
handle_delete_end_of_row(ctx, hi, lo);
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x25 ) {
ctx->rollup = 2;
+ctx->mode = CCMODE_ROLLUP_2;
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x26 ) {
ctx->rollup = 3;
+ctx->mode = CCMODE_ROLLUP_3;
} else if ( COR3(hi, 0x14, 0x15, 0x1C) && lo == 0x27 ) {
ctx->rollup = 4;
+ctx->mode = CCMODE_ROLLUP_3;
is this intended to be CCMODE_ROLLUP_3 instead of CCMODE_ROLLUP_4 ?
also do you have a file to test this and the other patches ?
thanks
[...]
I tested this on bmd live video, all the rollup values were not tested, I
implemented this feature when roll up 2 was coming.
I will check the database of ccextractor, if I get some video with different
rollup.
-Anshul
I have attached the patch which were not commited, In the rollup
functionality there was one more
bug other then typo, the first line was lost while converting the cc.
I have corrected that.
Here
is video with rollup in closed caption.
how can this be used for testing ?
do you have a command line with that video that shows a difference
with the patches ?
the patches themselfs look good
[...]
There is no different Command, its same as used to extract.
./ffmpeg_g -loglevel debug -f lavfi -i
movie=/home/anshul/test_video/Closedcaption_rollup.ts[out0+subcc] some.srt
The difference between the output is following
Without patch
some line 1
some line 2
some line 3
some line 4
with patch
some line 1
some line 2
some line 2
some line 3
some line 3
some line 4
And rollup functionality is specified in closed caption commands(inside
video).
So on same video rollup and without rollup is not possible.
@@ -187,7 +187,7 @@ static av_cold int init_decoder(AVCodecContext *avctx)
ret = AVERROR(ENOMEM);
}
-
+fail:
return ret;
}
i moved this hunk to the 2nd patch and applied first and second
with also module "avcodec/..." prefixes in the commit messages
Thanks
[...]
-Anshul
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
