Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

[Marton Balint]

On Tue, 3 Mar 2020, Baptiste Coudurier wrote:


On Mar 3, 2020, at 11:37 AM, Tomas Härdin  wrote:

tis 2020-03-03 klockan 11:22 -0800 skrev Baptiste Coudurier:

Hey guys,



On Mar 3, 2020, at 10:54 AM, Tomas Härdin  wrote:

mån 2020-03-02 klockan 21:35 +0100 skrev Marton Balint:

On Mon, 2 Mar 2020, Tomas Härdin wrote:


fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:

Signed-off-by: Marton Balint 
---
libavformat/mxf.c| 44 
libavformat/mxf.h|  6 --
libavformat/mxfdec.c | 23 +++
libavformat/mxfenc.c | 24 ++--
4 files changed, 13 insertions(+), 84 deletions(-)
int ff_mxf_get_content_package_rate(AVRational time_base)
{
-int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
-AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
-
-diff.num = FFABS(diff.num);
-
-if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
-return -1;
-
-return mxf_content_package_rates[idx];
+for (int i = 0; mxf_time_base[i].num; i++)
+if (!av_cmp_q(time_base, mxf_time_base[i]))


I see this gets rid of the inexact check for an exact one. Approve!


@@ -3307,20 +3307,17 @@ static int mxf_get_next_track_edit_unit(MXFContext 
*mxf, MXFTrack *track, int64_
static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
   int64_t edit_unit)
{
-int i, total = 0, size = 0;
   MXFTrack *track = st->priv_data;
   AVRational time_base = av_inv_q(track->edit_rate);
   AVRational sample_rate = av_inv_q(st->time_base);
-const MXFSamplesPerFrame *spf = NULL;
-int64_t sample_count;

   // For non-audio sample_count equals current edit unit
   if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
   return edit_unit;

-if ((sample_rate.num / sample_rate.den) == 48000)
-spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
-if (!spf) {
+if ((sample_rate.num / sample_rate.den) == 48000) {
+return av_rescale_q(edit_unit, sample_rate, track->edit_rate);


Should be OK, per previous rounding argument


   }
   sc->index = INDEX_D10_AUDIO;
   sc->container_ul = 
((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
-sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 4;
+sc->frame_size = 4 + 8 * av_rescale_rnd(st-

codecpar->sample_rate, mxf->time_base.num, mxf->time_base.den,

AV_ROUND_UP) * 4;


I was going to say this is only used for CBR video, but closer
inspection reveals it's used to prevent 1/1.001 rate audio packets from
making their way into CBR files. This is a bit surprising to me, since
D-10 supports NTSC (without audio?)


I thought D10 can only be CBR and and it can only use a constant edit unit 
size, 1/1.001 audio packet size difference is handled using KLV 
padding. So what we compute here is a _maximum_ frame size.


Now I remember: D-10 is indeed CBR, but at the MXF/CP level. To make it
CBR you must pad the content packages with fill KLVs as necessary. This
filling was actually removed by Baptiste a while back, and we had a set
of patches attempting to fix support for NTSC but sadly the ratecontrol
in lavc is not up to snuff to support that for files longer than about
an hour. This also means the video essence needs to be coded at a
bitrate slightly lower than the D-10 rate, say 49.9 Mbps for 50 Mbps D-
10 (+-audio).


IIRC, and correct me if I’m wrong, the VBV delay in D-10 is actually fixed, 
so the essence needs to be CBR at the essence (mpeg-2) level.

Anything else is just broken IMHO.


For practical D-10 decoders probably, but I think the spec is a bit
more lax. You only need to set up the DeltaEntry array in the
IndexTableSegment correctly


I believe at some point there was code for padding the MPEG-2 essence
with zeroes to make CBR, but that obviously doesn't work with audio due
to 1601.6 samples per EditUnit


Yeah, the pattern of audio samples is very strict in MXF, and every 5 frames, 
Audio and video durations match perfectly.


Yep, which luckily this patchset does. For audio there definitely needs
to be KLV fill since the size of the audio packets will vary


Wait, is it what it does ? The pattern is very strict and ordered.
For 3/1001 and 6/1001, it seems to me that it would not be correct.


The patchset replaces the hard coded sample tables with mathematically 
computed values, because


samples_in_nth_frame = av_rescale_q(n+1, {48000,1}, frame_rate) -
   av_rescale_q(n,   {48000,1}, frame_rate);

And this is also true for 3/1001 and 6/1001 frame rates.

Regards,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] libavcodec/libaomenc.c: Add a libaom command-line opton 'tune'

[Moritz Barsnick]

Hi Wang,

On Wed, Mar 04, 2020 at 05:59:02 +0800, Wang Cao wrote:

> Subject: libavcodec/libaomenc.c: Add a libaom command-line opton 'tune'
 ^
typo -> option

>  doc/encoders.texi  | 11 +++
>  libavcodec/libaomenc.c |  7 +++

I suggest also bumping libavcodec MICRO version with each addition of
options.

> +@item tune (@emph{tune})
> +Set the distortion metric tuned with for encoder. Default is PSNR.

The grammar sound a bit confusing to me. Perhaps:
  Set the distortion metric the encoder is tuned with.

Also, perhaps reference the default value, not the default behavior:
  Default is @code{psnr}.

> +@table @samp
> +@item psnr (@emph{0})
> +PSNR as distortion metric
> +
> +@item ssim (@emph{1})
> +SSIM as distortion metric
> +@end table

Probably no need to document the numerical values, but I don't really
mind.

> +if (ctx->tune >= 0)
> +codecctl_int(avctx, AOME_SET_TUNING, ctx->tune);
[...]
> +{ "tune","The metric that encoder tunes for", OFFSET(tune), 
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 1, VE, "tune"},
> +{ "psnr","PSNR as distortion metric", 0, 
> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, VE, "tune"},
> +{ "ssim","SSIM as distortion metric", 0, 
> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE, "tune"},

If "-1^" is the default, it's the encoder (library) that decides what
is default, right? Is this guaranteed to be PSNR? Or should we just
document "automatically chosen"?

Also, for consts, I suggest enums. I will comment on the second patch
(as there are only two values here, but the point may be just as
valid).

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] libavcodec/libaomenc.c: Add super-resolution options to libaom wrapper

[Moritz Barsnick]

On Wed, Mar 04, 2020 at 05:59:03 +0800, Wang Cao wrote:
> Signed-off-by: Wang Cao 
> ---
>  doc/encoders.texi  | 39 +++
>  libavcodec/libaomenc.c | 38 ++

Again, I suggest bumping MICRO once more.

> +@item superres_denominator
> +The denominator for superres to use when @option{superres-mode} is 
> @option{fixed}. Valid value
> +ranges from 8 to 16.
> +
> +@item superres_kf_denominator
> +The denominator for superres to use on key frames is fixed when
> +@option{superres-mode} is @option{fixed}. Valid value ranges from 8 to 16.

I believe "is fixed " is not needed in this sentence, or even
confusing.

>  [AOME_SET_TUNING]   = "AOME_SET_TUNING",
> +[AV1E_SET_ENABLE_SUPERRES] = "AV1E_SET_ENABLE_SUPERRES",

The other '=' in this block are aligned.

> +if (ctx->superres_mode >= 0)
> +  enccfg.rc_superres_mode = ctx->superres_mode;
> +if (ctx->superres_qthresh > 0)
> +  enccfg.rc_superres_qthresh = ctx->superres_qthresh;
> +if (ctx->superres_kf_qthresh > 0)
> +  enccfg.rc_superres_kf_qthresh = ctx->superres_kf_qthresh;
> +if (ctx->superres_denominator >= 0)
> +  enccfg.rc_superres_denominator = ctx->superres_denominator;
> +if (ctx->superres_kf_denominator >= 0)
> +  enccfg.rc_superres_kf_denominator = ctx->superres_kf_denominator;

It looks like indentation is off - ffmpeg uses four spaces.

(Is this struct zero-initialized / memset()'d?)

>  { "ssim","SSIM as distortion metric", 0, 
> AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE, "tune"},
> +{ "enable-superres", "Enable super-resolution mode", 
> OFFSET(enable_superres), AV_OPT_TYPE_BOOL, {.i64 = -1}, -1, 1, VE},
> +{ "superres-mode",   "Select super-resultion mode", 
> OFFSET(superres_mode), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 4, VE, 
> "superres_mode"},
> +{ "none","No frame superres allowed", 0, 
> AV_OPT_TYPE_CONST, {.i64 = 0}, 0, 0, VE, "superres_mode"},
> +{ "fixed",   "All frames are coded at the specified scale and 
> super-resolved", 0, AV_OPT_TYPE_CONST, {.i64 = 1}, 0, 0, VE, "superres_mode"},
> +{ "random",  "All frames are coded at a random scale and 
> super-resolved.", 0, AV_OPT_TYPE_CONST, {.i64 = 2}, 0, 0, VE, 
> "superres_mode"},
> +{ "qthresh", "Superres scale for a frame is determined based on 
> q_index",  0, AV_OPT_TYPE_CONST, {.i64 = 3}, 0, 0, VE, "superres_mode"},
> +{ "auto","Automatically select superres for appropriate 
> frames",   0, AV_OPT_TYPE_CONST, {.i64 = 4}, 0, 0, VE, 
> "superres_mode"},

Several remarks:
- The "none" entry should also be aligned, just like the entry "fixed"
  and following... (starting at   "0, AV_OPT_TYPE_CONST", if you see
  what I mean).
- Is "auto" a value given by the library? I'm asking because
  we tend to use "-1" for our internal "auto", and use that as a
  default, if desired.
  (From looking at libaom, they indeed use 4 for "auto".)
- Can you directly use the enumerations provided as SUPERRES_MODE by
  libaom, or are they not public?
- If you cannot reuse said enum (and its resulting range
  [-1, SUPERRES_MODES - 1]), you should define your own as enum
  SuperresModes { AOM_SUPERRES_MODE_NONE, AOM_SUPERRES_MODE_FIXED, ,
  AOM_SUPERRES_MODE_NB }, use these in the options definition above,
  and set the allowed range to [-1, AOM_SUPERRES_MODE_NB - 1].

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 08/17] avformat/webm_chunk: Use appropriate initializer for AV_OPT_TYPE_STRING

[Moritz Barsnick]

On Mon, Mar 02, 2020 at 05:44:36 +0100, Andreas Rheinhardt wrote:
> -{ "header", "filename of the header where the initialization data will 
> be written", OFFSET(header_filename), AV_OPT_TYPE_STRING, { 0 }, 0, 0, 
> AV_OPT_FLAG_ENCODING_PARAM },
> +{ "header", "filename of the header where the initialization data will 
> be written", OFFSET(header_filename), AV_OPT_TYPE_STRING, {.str = NULL}, 0, 
> 0, AV_OPT_FLAG_ENCODING_PARAM },

I found some 19 or so further occurences of this pattern[*]. Are they
worth "fixing", or is it a purely cosmetic thing?

[*] $ find -name "*.[ch]" -print0 | xargs -0 grep -Pn 
'AV_OPT_TYPE_STRING,\s*{\s*0\s*}'

Cheers,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

[Carl Eugen Hoyos]

Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint :

> 2) support all frame rates and write 0 (undefined) as the package rate
> for frame rates which cannot be exactly represented

Why not?

Allow me to repeat: Professional archivists recommend using mxf. How
do they store digitized content from (old) low-fps film?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[Anton Khirnov]

Quoting Sebastian Hubbard (2020-02-20 22:43:53)
> Added id3v2_buf and id3v2_buf_size fields to AVProbeData. When an id3v2
> tag is found at the start of probed content, id3v2_buf is filled with
> a pointer to the start of the tag bytes, and id3v2_buf_size with the
> number of bytes in the tag.
> 
> ac3_eac3_probe checks the tag when present for a private frame with an
> owner identifier of com.apple.streaming.audioDescription, which
> signals that the file is encrypted with an Apple DRM scheme. The CRC
> checksums for such files are for the content post-decryption, and with
> this change they are skipped when Apple DRM is detected. This enables
> ffprobe to detect the stream type, even though it will not be playable.
> 
> Signed-off-by: Sebastian Hubbard 
> ---
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 9b9b634ec3..afd1b67b5c 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -448,6 +448,8 @@ typedef struct AVProbeData {
>  unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra 
> allocated bytes filled with zero. */
>  int buf_size;   /**< Size of buf except extra allocated bytes */
>  const char *mime_type; /**< mime_type, when known. */
> +unsigned char *id3v2_buf; /**< Bytes of id3v2 tag if one was found at 
> start of file. */
> +int id3v2_buf_size; /**< Size of id3v2_buf */

You can't just add fields here, it's an ABI break.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] 2 Alternative approaches for AVFrame QP Tables

[Anton Khirnov]

Quoting Michael Niedermayer (2020-02-29 13:21:52)
> 
> [PATCH 1/4] Remove all uses of AVFrame QP tables and related fields
> [PATCH 2/4] avutil/frame: Rename QP related fields so unintentional
> 
> These 2 are common in both options, they break API but not ABI so
> should not be applied before the next release
> 
> 
> [PATCH 3/4] avutil: frame Update the existing QP API
> 
> This is a rough sketch of how the existing API can cope with a much
> wider range of codecs.
> I did not check if this is enough to handle every codec that has QP
> values but a variant if this should be able to work with all.

IIUC your proposed function fills in all the values based purely on
type, assuming constant block size for given type. How would that work
for modern codecs with adaptive block sizes?

I suppose it could be extended to read this information from some extra
array appended to the data, but seems to me we'd quickly converge to
just another binary representation of what the other patch does more
explicitly. So I'd say we should go with Juan's patch.
> 
> 
> [PATCH 4/4] libavutil: AVEncodeInfo data structures
> 
> This is the alternative to 3/4, which is Juan De Leóns patch
> which was previously posted and discussed.
> IIUC there where no objections to this previously but it
> was not applied by anyone.
> So Maybe we can just use this. The disadvantage here that i
> can see is primarely that every codec has to convert its
> internal format to the one specified in the API.

That does not seem such a big problem to me, since there are in effect
only two codecs to convert - mjpeg and and mpegvideo.

> In effect this would need a switch to only export
> such data when needed. Because otherwise it would waste time.

I believe that switch would be a good idea in any case, otherwise we do
unnecessary copying of data that most users won't need.

There are some things I would prefer changed in the 4/4 patch API-wise,
but since the original submitter is no longer around I volunteer to do
those changes myself, if you have no objections.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] REMOTE JOB POST: FFMPEG EXPERT

[Josh de Kock]

On Tue, Mar 3, 2020, at 12:55 PM, sumaklos rembert wrote:
> We are hiring a remote FFMPEG engineer
>
> [...]

You already posted this a week ago, there is no need to spam the
list with the same job multiple times.

-- 
Josh
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] REMOTE JOB POST: FFMPEG EXPERT

[sumaklos rembert]

Good morning j...@itanimul.li,

I usually don't bother responding to unhappy or negative people.but.
Yep, I posted a week ago and still need to fill my job.  I hardly think 2
emails trying to help someone who may be in need of a need gig equals spam.

Skip over the post if you aren't interested.  Much appreciated.

All the best.

P.S. List moderators, if I'm out of order please remove me from your list
and I'll truly understand.  No harm done.  Best.




On Wed, Mar 4, 2020, 6:56 AM Josh de Kock  wrote:

> On Tue, Mar 3, 2020, at 12:55 PM, sumaklos rembert wrote:
> > We are hiring a remote FFMPEG engineer
> >
> > [...]
>
> You already posted this a week ago, there is no need to spam the
> list with the same job multiple times.
>
> --
> Josh
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Regarding GSoC 2020 project proposal

[YATENDRA SINGH]

Thank you for explaining the procedure.
I have posted my own project proposal on the page you had instructed me to.
Looking forward to the feedback.

Regards,
Yatendra Singh.

On Tue, Mar 3, 2020 at 10:19 PM Pedro Arthur  wrote:

> Hi
>
> Em ter., 3 de mar. de 2020 às 09:24, YATENDRA SINGH
>  escreveu:
> >
> > Hi,
> > I am a third year CSE student at the Indian Institute of Technology
> Bhilai,
> > and would like to contribute to ffmpeg this year. I have
> > relevant experience with Machine Learning and would like to work on
> > improving the video frame interpolation already implemented. With such a
> > plethora of great Machine Learning Algorithms being published every year
> at
> > prestigious conferences I would aim to read the relevant academic papers
> > and implement the best suited technique for the task. For example, Depth
> > Aware Video Frame Interpolation (DAIN CVPR-2019) is supposedly the state
> of
> > the art method on Vimeo90k and MiddleBury
> >  but at the
> same
> > time Frame Interpolation with Generative Adversarial Network(FIGAN), uses
> > not CNN but multi-scale synthesis( MS ) to get higher speeds.
> > Looking forward to hearing from you soon.
> >
> > Yatendra SIngh
> > Frame Interpolation with Multi-Scale Deep Loss Functions and Generative
> > Adversarial NetworksFrame Interpolation with Multi-Scale Deep Loss
> > Functions and Generative Adversarial NetworksFrame Interpolation with
> > Multi-Scale Deep Loss Functions and Generative Adversarial Networks
>
> I suppose this project is your own idea as it is not listed in the
> projects page, right?
>
> I think it would be good to add you idea under "Your Own Project Idea"
> section in [1] adding as much information as possible so that we can
> evaluate your idea and possible assign a mentor / backup mentor.
> A few things I think are important to evaluate your project are:
> *have a well defined "expected result", will it be a filter? or
> something else? we already have a dnn module and a dnn_processing
> filter, will your project be using it?
>
> *what is the amount of work that will be done during the project, more
> or less this is related to above "expected result"
>
> *define a qualification task, we can discuss it after the above is define
>
> *sell your idea (not strictly necessary but may help evaluating your
> project), why is it useful feature to have, what improvements it
> brings, etc
>
> [1] -
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020#YourOwnProjectIdea
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] Regarding GSoC 2020 project proposal

[Thilo Borgmann]

Hi,

Am 04.03.20 um 13:56 schrieb YATENDRA SINGH:
> Thank you for explaining the procedure.
> I have posted my own project proposal on the page you had instructed me to.
> Looking forward to the feedback.

I moved that to the "Your own project idea" section.
I also added a 'proposed by:' field to it, please update that with your contact 
information (mail & IRC nickname, if you have both). Make it easy for 
potentially interested mentors to contact you.

You should also not wait for anyone contacting you about that matter. You can 
search through the relevant code in the FFmpeg codebase looking for authors of 
code related to your project. You might consider getting in touch with them 
asking for mentoring you during the summer. You can also do a query for mentors 
on IRC. Don't get spam-like though ;)

-Thilo



> On Tue, Mar 3, 2020 at 10:19 PM Pedro Arthur  wrote:
> 
>> Hi
>>
>> Em ter., 3 de mar. de 2020 às 09:24, YATENDRA SINGH
>>  escreveu:
>>>
>>> Hi,
>>> I am a third year CSE student at the Indian Institute of Technology
>> Bhilai,
>>> and would like to contribute to ffmpeg this year. I have
>>> relevant experience with Machine Learning and would like to work on
>>> improving the video frame interpolation already implemented. With such a
>>> plethora of great Machine Learning Algorithms being published every year
>> at
>>> prestigious conferences I would aim to read the relevant academic papers
>>> and implement the best suited technique for the task. For example, Depth
>>> Aware Video Frame Interpolation (DAIN CVPR-2019) is supposedly the state
>> of
>>> the art method on Vimeo90k and MiddleBury
>>>  but at the
>> same
>>> time Frame Interpolation with Generative Adversarial Network(FIGAN), uses
>>> not CNN but multi-scale synthesis( MS ) to get higher speeds.
>>> Looking forward to hearing from you soon.
>>>
>>> Yatendra SIngh
>>> Frame Interpolation with Multi-Scale Deep Loss Functions and Generative
>>> Adversarial NetworksFrame Interpolation with Multi-Scale Deep Loss
>>> Functions and Generative Adversarial NetworksFrame Interpolation with
>>> Multi-Scale Deep Loss Functions and Generative Adversarial Networks
>>
>> I suppose this project is your own idea as it is not listed in the
>> projects page, right?
>>
>> I think it would be good to add you idea under "Your Own Project Idea"
>> section in [1] adding as much information as possible so that we can
>> evaluate your idea and possible assign a mentor / backup mentor.
>> A few things I think are important to evaluate your project are:
>> *have a well defined "expected result", will it be a filter? or
>> something else? we already have a dnn module and a dnn_processing
>> filter, will your project be using it?
>>
>> *what is the amount of work that will be done during the project, more
>> or less this is related to above "expected result"
>>
>> *define a qualification task, we can discuss it after the above is define
>>
>> *sell your idea (not strictly necessary but may help evaluating your
>> project), why is it useful feature to have, what improvements it
>> brings, etc
>>
>> [1] -
>> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2020#YourOwnProjectIdea
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>> To unsubscribe, visit link above, or email
>> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/1] Patch for adding Documentation of ff_http_match_no_proxy

[Sourabh Sharma]

On Tue, Mar 3, 2020 at 3:47 AM Michael Niedermayer  wrote:

> On Mon, Mar 02, 2020 at 08:32:10PM +0530, Sourabh Sharma wrote:
> > Patch for adding Documentation of ff_http_match_no_proxy
> > Function ff_http_match_no_proxy check for host of proxy address matches
> with
> >  the hostname or not.
> >
> > ---
> >  libavformat/network.h | 7 +++
> >  1 file changed, 7 insertions(+)
> >
> > diff --git a/libavformat/network.h b/libavformat/network.h
> > index 71347e815b..7c93375ae5 100644
> > --- a/libavformat/network.h
> > +++ b/libavformat/network.h
> > @@ -303,6 +303,13 @@ int ff_listen_connect(int fd, const struct sockaddr
> *addr,
> >socklen_t addrlen, int timeout,
> >URLContext *h, int will_try_next);
> >
> > +/**
> > + * It Checks for a host of proxy address matches with the hostname or
> not.
> > + *
> > + * @param no_proxy Server address of proxy server e.g.
> example.domain.com
> > + * @param hostname Server address of hostname e.g. domain.com
> > + * @return 0 if don't match, 1 for exactly match
> > +*/
> >  int ff_http_match_no_proxy(const char *no_proxy, const char *hostname);
>
> maybe looking at how this function is used makes it clearer what it does
>
> for example
> libavformat/http.c:use_proxy  =
> !ff_http_match_no_proxy(getenv("no_proxy"), hostname) &&
> libavformat/http.c- proxy_path && av_strstart(proxy_path,
> "http://";, NULL);
>
>
> but basically
> no_proxy, is a list of addresses for which not to use the proxy server,
> these may be local addresses
>

Thanks
I will correct it soon.

>
>
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> When you are offended at any man's fault, turn to yourself and study your
> own failings. Then you will forget your anger. -- Epictetus
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Remove bitrig support

[Brad Smith]

On Wed, Feb 26, 2020 at 02:18:30PM -0500, Brad Smith wrote:
> configure: Remove bitrig support
> 
> Bitrig was an OpenBSD derivative that has been dead for awhile now.
> 
> Signed-off-by: Brad Smith 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 06e3a7b2a8..9221621bd1 100755
> --- a/configure
> +++ b/configure
> @@ -5303,7 +5303,7 @@ case $target_os in
>  oss_outdev_extralibs="-lossaudio"
>  enabled gcc || check_ldflags -Wl,-zmuldefs
>  ;;
> -openbsd|bitrig)
> +openbsd)
>  disable symver
>  enable section_data_rel_ro
>  striptype=""
> -- 
> 2.25.0

ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/siren: Check several indexes

[Paul B Mahol]

lgtm

On 3/1/20, Michael Niedermayer  wrote:
> Fixes: Multiple out of array accesses
> Fixes:
> 20817/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SIREN_fuzzer-5754041227542528.fuzz
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/siren.c | 15 +++
>  1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/siren.c b/libavcodec/siren.c
> index 2577ff52dd..76dfe62843 100644
> --- a/libavcodec/siren.c
> +++ b/libavcodec/siren.c
> @@ -428,6 +428,7 @@ static int decode_envelope(SirenContext *s,
> GetBitContext *gb,
> int *absolute_region_power_index, int
> esf_adjustment)
>  {
>  absolute_region_power_index[0] = (int)get_bits(gb, 5) - esf_adjustment;
> +absolute_region_power_index[0] =
> av_clip(absolute_region_power_index[0], -24, 39);
>  decoder_standard_deviation[0] =
> s->standard_deviation[absolute_region_power_index[0] + 24];
>
>  for (int i = 1; i < number_of_regions; i++) {
> @@ -437,7 +438,7 @@ static int decode_envelope(SirenContext *s,
> GetBitContext *gb,
>  index = differential_decoder_tree[i - 1][index][get_bits1(gb)];
>  } while (index > 0);
>
> -absolute_region_power_index[i] = absolute_region_power_index[i - 1]
> - index - 12;
> +absolute_region_power_index[i] =
> av_clip(absolute_region_power_index[i - 1] - index - 12, -24, 39);
>  decoder_standard_deviation[i] =
> s->standard_deviation[absolute_region_power_index[i] + 24];
>  }
>
> @@ -500,6 +501,8 @@ static int categorize_regions(int number_of_regions, int
> number_of_available_bit
>  }
>  }
>  }
> +if (raw_value == -99)
> +return AVERROR_INVALIDDATA;
>  *min_rate_ptr++ = raw_min_idx;
>  min +=
>  expected_bits_table[min_rate_categories[raw_min_idx] + 1] -
> @@ -518,6 +521,8 @@ static int categorize_regions(int number_of_regions, int
> number_of_available_bit
>  }
>  }
>  }
> +if (raw_value == 99)
> +return AVERROR_INVALIDDATA;
>
>  *--max_rate_ptr = raw_max_idx;
>  max += expected_bits_table[max_rate_categories[raw_max_idx] -
> 1] -
> @@ -684,9 +689,11 @@ static int siren_decode(AVCodecContext *avctx, void
> *data,
>
>  rate_control = get_bits(gb, 4);
>
> -categorize_regions(s->number_of_regions, get_bits_left(gb),
> -   s->absolute_region_power_index, s->power_categories,
> -   s->category_balance);
> +ret = categorize_regions(s->number_of_regions, get_bits_left(gb),
> + s->absolute_region_power_index,
> s->power_categories,
> + s->category_balance);
> +if (ret < 0)
> +return ret;
>
>  for (int i = 0; i < rate_control; i++)
>  s->power_categories[s->category_balance[i]]++;
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

[Tomas Härdin]

ons 2020-03-04 klockan 11:31 +0100 skrev Carl Eugen Hoyos:
> Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint :
> 
> > 2) support all frame rates and write 0 (undefined) as the package rate
> > for frame rates which cannot be exactly represented
> 
> Why not?
> 
> Allow me to repeat: Professional archivists recommend using mxf. How
> do they store digitized content from (old) low-fps film?

We can worry about that when archivists open tickets on trac.

/Tomas

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] configure: Remove bitrig support

[Carl Eugen Hoyos]

Am Mi., 26. Feb. 2020 um 20:18 Uhr schrieb Brad Smith :

> configure: Remove bitrig support
>
> Bitrig was an OpenBSD derivative that has been dead for awhile now.

Why is the fact that it isn't actively developed a reason to remove the
entry from FFmpeg's configure?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 4/4] avformat/mxfenc: add some missing content package rates

[Carl Eugen Hoyos]

Am Mi., 4. März 2020 um 17:29 Uhr schrieb Tomas Härdin :
>
> ons 2020-03-04 klockan 11:31 +0100 skrev Carl Eugen Hoyos:
> > Am Di., 3. März 2020 um 02:18 Uhr schrieb Marton Balint :
> >
> > > 2) support all frame rates and write 0 (undefined) as the package rate
> > > for frame rates which cannot be exactly represented
> >
> > Why not?
> >
> > Allow me to repeat: Professional archivists recommend using mxf. How
> > do they store digitized content from (old) low-fps film?
>
> We can worry about that when archivists open tickets on trac.

A ticket was actually opened asking for more frame rates (just as
a ticket was opened earlier because of a limitation in aspect ratios),
I wonder why mxf is the only (?) libavformat muxer that tells the
user which frame rates (in the past: which aspect ratios) to use.
It is very hard to believe that the reason is that mxf does not allow
other frame rates (I have to listen once a year to a presentation
explaining how versatile mxf is compared to all other multimedia
containers).

Just print a warning when you feel that the chosen framerate will
not ensure maximum compatibility.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[Sebastian Hubbard]

I knew this was an ABI change and probably wasn't going to be
acceptable, but I decided to share it for consideration anyway.
There's special code in av_probe_input_format3 to skip over id3 tags
for the purposes of format detection, but Apple uses id3 tags to
signal information for HLS audio only tracks. Maybe this change
shouldn't be made, but if it could ever be helpful for another format
prober to know about leading id3 tags this is the only way I could
imagine it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[Carl Eugen Hoyos]

Am Mi., 4. März 2020 um 17:53 Uhr schrieb Sebastian Hubbard
:
>
> I knew this was an ABI change and probably wasn't going to be
> acceptable, but I decided to share it for consideration anyway.
> There's special code in av_probe_input_format3 to skip over id3 tags
> for the purposes of format detection, but Apple uses id3 tags to
> signal information for HLS audio only tracks. Maybe this change
> shouldn't be made, but if it could ever be helpful for another format
> prober to know about leading id3 tags this is the only way I could
> imagine it.

If the additional fields are necessary (I don't know), they could be
added to the end of the struct where they do not break abi.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[Hendrik Leppkes]

On Wed, Mar 4, 2020 at 5:57 PM Carl Eugen Hoyos  wrote:
>
> Am Mi., 4. März 2020 um 17:53 Uhr schrieb Sebastian Hubbard
> :
> >
> > I knew this was an ABI change and probably wasn't going to be
> > acceptable, but I decided to share it for consideration anyway.
> > There's special code in av_probe_input_format3 to skip over id3 tags
> > for the purposes of format detection, but Apple uses id3 tags to
> > signal information for HLS audio only tracks. Maybe this change
> > shouldn't be made, but if it could ever be helpful for another format
> > prober to know about leading id3 tags this is the only way I could
> > imagine it.
>
> If the additional fields are necessary (I don't know), they could be
> added to the end of the struct where they do not break abi.
>

Unfortunately, thats not true for every struct. In this case, for
example, they are being added at the end, but a caller could still
provide a smaller one  and we would try to read/write beyond the
provided struct.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[James Almer]

On 3/4/2020 1:56 PM, Carl Eugen Hoyos wrote:
> Am Mi., 4. März 2020 um 17:53 Uhr schrieb Sebastian Hubbard
> :
>>
>> I knew this was an ABI change and probably wasn't going to be
>> acceptable, but I decided to share it for consideration anyway.
>> There's special code in av_probe_input_format3 to skip over id3 tags
>> for the purposes of format detection, but Apple uses id3 tags to
>> signal information for HLS audio only tracks. Maybe this change
>> shouldn't be made, but if it could ever be helpful for another format
>> prober to know about leading id3 tags this is the only way I could
>> imagine it.
> 
> If the additional fields are necessary (I don't know), they could be
> added to the end of the struct where they do not break abi.
> 
> Carl Eugen

sizeof(AVProbeData) is part of the ABI because its doxy doesn't strictly
state otherwise. This means we can't add new fields to it, even at the
end, until a major bump. Else we'll be breaking ABI.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/ac3dec: detect fairplay encryption

[Carl Eugen Hoyos]

Am Mi., 4. März 2020 um 18:57 Uhr schrieb James Almer :
>
> On 3/4/2020 1:56 PM, Carl Eugen Hoyos wrote:
> > Am Mi., 4. März 2020 um 17:53 Uhr schrieb Sebastian Hubbard
> > :
> >>
> >> I knew this was an ABI change and probably wasn't going to be
> >> acceptable, but I decided to share it for consideration anyway.
> >> There's special code in av_probe_input_format3 to skip over id3 tags
> >> for the purposes of format detection, but Apple uses id3 tags to
> >> signal information for HLS audio only tracks. Maybe this change
> >> shouldn't be made, but if it could ever be helpful for another format
> >> prober to know about leading id3 tags this is the only way I could
> >> imagine it.
> >
> > If the additional fields are necessary (I don't know), they could be
> > added to the end of the struct where they do not break abi.
> >
> > Carl Eugen
>
> sizeof(AVProbeData) is part of the ABI because its doxy doesn't strictly
> state otherwise. This means we can't add new fields to it, even at the
> end, until a major bump. Else we'll be breaking ABI.

Thank you both for the explanation!

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxf: get rid of samples per frame array usage

[Michael Niedermayer]

On Tue, Mar 03, 2020 at 07:54:55PM +0100, Tomas Härdin wrote:
> mån 2020-03-02 klockan 21:35 +0100 skrev Marton Balint:
> > 
> > On Mon, 2 Mar 2020, Tomas Härdin wrote:
> > 
> > > fre 2020-02-28 klockan 01:37 +0100 skrev Marton Balint:
> > > > Signed-off-by: Marton Balint 
> > > > ---
> > > >  libavformat/mxf.c| 44 
> > > >  libavformat/mxf.h|  6 --
> > > >  libavformat/mxfdec.c | 23 +++
> > > >  libavformat/mxfenc.c | 24 ++--
> > > >  4 files changed, 13 insertions(+), 84 deletions(-)
> > > >  int ff_mxf_get_content_package_rate(AVRational time_base)
> > > >  {
> > > > -int idx = av_find_nearest_q_idx(time_base, mxf_time_base);
> > > > -AVRational diff = av_sub_q(time_base, mxf_time_base[idx]);
> > > > -
> > > > -diff.num = FFABS(diff.num);
> > > > -
> > > > -if (av_cmp_q(diff, (AVRational){1, 1000}) >= 0)
> > > > -return -1;
> > > > -
> > > > -return mxf_content_package_rates[idx];
> > > > +for (int i = 0; mxf_time_base[i].num; i++)
> > > > +if (!av_cmp_q(time_base, mxf_time_base[i]))
> > > 
> > > I see this gets rid of the inexact check for an exact one. Approve!
> > > 
> > > > @@ -3307,20 +3307,17 @@ static int 
> > > > mxf_get_next_track_edit_unit(MXFContext *mxf, MXFTrack *track, int64_
> > > >  static int64_t mxf_compute_sample_count(MXFContext *mxf, AVStream *st,
> > > >  int64_t edit_unit)
> > > >  {
> > > > -int i, total = 0, size = 0;
> > > >  MXFTrack *track = st->priv_data;
> > > >  AVRational time_base = av_inv_q(track->edit_rate);
> > > >  AVRational sample_rate = av_inv_q(st->time_base);
> > > > -const MXFSamplesPerFrame *spf = NULL;
> > > > -int64_t sample_count;
> > > > 
> > > >  // For non-audio sample_count equals current edit unit
> > > >  if (st->codecpar->codec_type != AVMEDIA_TYPE_AUDIO)
> > > >  return edit_unit;
> > > > 
> > > > -if ((sample_rate.num / sample_rate.den) == 48000)
> > > > -spf = ff_mxf_get_samples_per_frame(mxf->fc, time_base);
> > > > -if (!spf) {
> > > > +if ((sample_rate.num / sample_rate.den) == 48000) {
> > > > +return av_rescale_q(edit_unit, sample_rate, track->edit_rate);
> > > 
> > > Should be OK, per previous rounding argument
> > > 
> > > >  }
> > > >  sc->index = INDEX_D10_AUDIO;
> > > >  sc->container_ul = 
> > > > ((MXFStreamContext*)s->streams[0]->priv_data)->container_ul;
> > > > -sc->frame_size = 4 + 8 * spf[0].samples_per_frame[0] * 
> > > > 4;
> > > > +sc->frame_size = 4 + 8 * av_rescale_rnd(st-
> > > > >codecpar->sample_rate, mxf->time_base.num, mxf->time_base.den,
> > > > AV_ROUND_UP) * 4;
> > > 
> > > I was going to say this is only used for CBR video, but closer
> > > inspection reveals it's used to prevent 1/1.001 rate audio packets from
> > > making their way into CBR files. This is a bit surprising to me, since
> > > D-10 supports NTSC (without audio?)
> > 
> > I thought D10 can only be CBR and and it can only use a constant edit unit 
> > size, 1/1.001 audio packet size difference is handled using KLV 
> > padding. So what we compute here is a _maximum_ frame size.
> 
> Now I remember: D-10 is indeed CBR, but at the MXF/CP level. To make it
> CBR you must pad the content packages with fill KLVs as necessary. This
> filling was actually removed by Baptiste a while back, and we had a set

> of patches attempting to fix support for NTSC but sadly the ratecontrol
> in lavc is not up to snuff to support that for files longer than about
> an hour.

Do you have a testcase for this so the ratecontrol can be fixed by fixing
the testcase ?

Thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC] 2 Alternative approaches for AVFrame QP Tables

[Michael Niedermayer]

On Wed, Mar 04, 2020 at 12:55:31PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2020-02-29 13:21:52)
> > 
> > [PATCH 1/4] Remove all uses of AVFrame QP tables and related fields
> > [PATCH 2/4] avutil/frame: Rename QP related fields so unintentional
> > 
> > These 2 are common in both options, they break API but not ABI so
> > should not be applied before the next release
> > 
> > 
> > [PATCH 3/4] avutil: frame Update the existing QP API
> > 
> > This is a rough sketch of how the existing API can cope with a much
> > wider range of codecs.
> > I did not check if this is enough to handle every codec that has QP
> > values but a variant if this should be able to work with all.
> 
> IIUC your proposed function fills in all the values based purely on
> type, assuming constant block size for given type. How would that work
> for modern codecs with adaptive block sizes?

Yes
The array would use the smallest block size supported by the codec.
So no block shape information would be exported


> 
> I suppose it could be extended to read this information from some extra
> array appended to the data, but seems to me we'd quickly converge to
> just another binary representation of what the other patch does more
> explicitly. 

> So I'd say we should go with Juan's patch.

ok, ill wait a bit in case anyone else has comments though


> > 
> > 
> > [PATCH 4/4] libavutil: AVEncodeInfo data structures
> > 
> > This is the alternative to 3/4, which is Juan De Leóns patch
> > which was previously posted and discussed.
> > IIUC there where no objections to this previously but it
> > was not applied by anyone.
> > So Maybe we can just use this. The disadvantage here that i
> > can see is primarely that every codec has to convert its
> > internal format to the one specified in the API.
> 
> That does not seem such a big problem to me, since there are in effect
> only two codecs to convert - mjpeg and and mpegvideo.

what would be nice in an ideal world, would be to export the
internal format with a stable API thats the same for all codecs 
to the outside without copy.
I guess this is too constraining in reality


> 
> > In effect this would need a switch to only export
> > such data when needed. Because otherwise it would waste time.
> 
> I believe that switch would be a good idea in any case, otherwise we do
> unnecessary copying of data that most users won't need.
> 

> There are some things I would prefer changed in the 4/4 patch API-wise,
> but since the original submitter is no longer around I volunteer to do
> those changes myself, if you have no objections.

sure

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/4] tests/checkasm: add overflow test for hevc_add_res

[Michael Niedermayer]

On Wed, Mar 04, 2020 at 04:13:43AM +, Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Michael Niedermayer
> > Sent: Wednesday, March 4, 2020 02:41
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH 1/4] tests/checkasm: add overflow test
> > for hevc_add_res
> > 
> > On Wed, Dec 11, 2019 at 04:45:36PM +0800, Linjie Fu wrote:
> > > Add overflow test for hevc_add_res when int16_t coeff = -32768.
> > > The result of C is good, while ASM is not.
> > >
> > > To verify:
> > > make fate-checkasm-hevc_add_res
> > > ffmpeg/tests/checkasm/checkasm --test=hevc_add_res
> > >
> > > ./checkasm --test=hevc_add_res
> > > checkasm: using random seed 679391863
> > > MMXEXT:
> > > hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
> > >   - hevc_add_res.add_residual [FAILED]
> > > SSE2:
> > > hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
> > > hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
> > > hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
> > >   - hevc_add_res.add_residual [FAILED]
> > > AVX:
> > > hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
> > > hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
> > > hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
> > >   - hevc_add_res.add_residual [FAILED]
> > > AVX2:
> > > hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
> > >   - hevc_add_res.add_residual [FAILED]
> > > checkasm: 8 of 14 tests have failed
> > >
> > > Signed-off-by: Xu Guangxin 
> > > Signed-off-by: Linjie Fu 
> > > ---
> > >  tests/checkasm/hevc_add_res.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/tests/checkasm/hevc_add_res.c
> > b/tests/checkasm/hevc_add_res.c
> > > index e92c6b4..a6e3b8a 100644
> > > --- a/tests/checkasm/hevc_add_res.c
> > > +++ b/tests/checkasm/hevc_add_res.c
> > > @@ -58,6 +58,7 @@ static void check_add_res(HEVCDSPContext h, int
> > bit_depth)
> > >
> > >  randomize_buffers(res0, size);
> > >  randomize_buffers2(dst0, size);
> > > +res0[0] = 0x8000;// overflow test
> > >  memcpy(res1, res0, sizeof(*res0) * size);
> > >  memcpy(dst1, dst0, sizeof(int16_t) * size);
> > 
> > unconditionally and always seting this would reduce the space that can
> > be tested unless iam missing something
> 
> Thanks and Yes it could be a problem especially for 4x4 tests since it only
> has 16 residual tested in total (if we set 1 constant test for overflow)
> 
> To cover the overflow situation without reducing the testing space, one
> simple way is to add one more check for checkasm_hevc_add_res to test
> 2x cases (no too much cost introduced):
> 
> @@ -80,6 +81,7 @@ void checkasm_check_hevc_add_res(void)
> 
>  ff_hevc_dsp_init(&h, bit_depth);
>  check_add_res(h, bit_depth);
> +check_add_res(h, bit_depth);
> 
> If it's suitable, I'll update and resend the patch set.
> (also there may be another choice to only apply the fix in patch 2 ~ 4)
> 
> Looking forward to your further comments.

probably ok

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/siren: Check several indexes

[Michael Niedermayer]

On Wed, Mar 04, 2020 at 04:59:10PM +0100, Paul B Mahol wrote:
> lgtm

will apply

thx

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] mpegts hack

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/mpegts.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 7f56bacb2c..782f13fe4f 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -955,8 +955,8 @@ static int mpegts_set_stream_info(AVStream *st, PESContext 
*pes,
 (st->request_probe > 0 && st->request_probe < 
AVPROBE_SCORE_STREAM_RETRY / 5)) &&
 st->probe_packets > 0 &&
 stream_type == STREAM_TYPE_PRIVATE_DATA) {
-st->codecpar->codec_type = AVMEDIA_TYPE_DATA;
-st->codecpar->codec_id   = AV_CODEC_ID_BIN_DATA;
+st->codecpar->codec_type = pes->stream_type == 6 ? AVMEDIA_TYPE_AUDIO 
: AVMEDIA_TYPE_DATA;
+st->codecpar->codec_id   = pes->stream_type == 6 ? AV_CODEC_ID_AC4 : 
AV_CODEC_ID_BIN_DATA;
 st->request_probe = AVPROBE_SCORE_STREAM_RETRY / 5;
 }
 
@@ -2062,6 +2062,13 @@ int ff_parse_mpeg2_descriptor(AVFormatContext *fc, 
AVStream *st, int stream_type
 av_dict_set(&st->metadata, "language", language, 0);
 }
 }
+if (ext_desc_tag == 0x15) { /* AC-4 descriptor */
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id = AV_CODEC_ID_AC4;
+st->request_probe = 0;
+
+st->internal->need_context_update = 1;
+}
 break;
 case 0x6a: /* ac-3_descriptor */
 {
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/avformat: Make AVProbeData extendible with the next major bump

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavformat/avformat.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9b9b634ec3..bd99d4e4f2 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -448,6 +448,9 @@ typedef struct AVProbeData {
 unsigned char *buf; /**< Buffer must have AVPROBE_PADDING_SIZE of extra 
allocated bytes filled with zero. */
 int buf_size;   /**< Size of buf except extra allocated bytes */
 const char *mime_type; /**< mime_type, when known. */
+#if LIBAVFORMAT_VERSION_MAJOR > 58
+AVDictionary *dict; /**< Dictionary to allow the user to provide 
additional extendible fields */
+#endif
 } AVProbeData;
 
 #define AVPROBE_SCORE_RETRY (AVPROBE_SCORE_MAX/4)
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavformat/Makefile |   1 +
 libavformat/ac4dec.c | 104 +++
 libavformat/allformats.c |   1 +
 3 files changed, 106 insertions(+)
 create mode 100644 libavformat/ac4dec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e0681058a2..b4e8d20e65 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
 OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o rawdec.o
 OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
 OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
+OBJS-$(CONFIG_AC4_DEMUXER)   += ac4dec.o
 OBJS-$(CONFIG_ACM_DEMUXER)   += acm.o rawdec.o
 OBJS-$(CONFIG_ACT_DEMUXER)   += act.o
 OBJS-$(CONFIG_ADF_DEMUXER)   += bintext.o sauce.o
diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
new file mode 100644
index 00..8c6e539409
--- /dev/null
+++ b/libavformat/ac4dec.c
@@ -0,0 +1,104 @@
+/*
+ * RAW AC-4 demuxer
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/crc.h"
+#include "avformat.h"
+#include "rawdec.h"
+
+static int ac4_probe(const AVProbeData *p)
+{
+const uint8_t *buf = p->buf;
+int left = p->buf_size;
+int max_frames = 0;
+
+while (left > 7) {
+int size;
+
+if (buf[0] == 0xAC &&
+(buf[1] == 0x40 ||
+ buf[1] == 0x41)) {
+size = (buf[2] << 8) | buf[3];
+if (size == 0x)
+size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
+size += 4;
+if (buf[1] == 0x41)
+size += 2;
+max_frames++;
+left -= size;
+buf += size;
+} else {
+break;
+}
+}
+
+return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
+}
+
+static int ac4_read_header(AVFormatContext *s)
+{
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id   = AV_CODEC_ID_AC4;
+
+return 0;
+}
+
+static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AVIOContext *pb = s->pb;
+int64_t pos;
+uint16_t sync;
+int ret, size;
+
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
+pos   = avio_tell(s->pb);
+sync = avio_rb16(pb);
+size = avio_rb16(pb);
+if (size == 0x)
+size = avio_rb24(pb);
+
+ret = av_get_packet(pb, pkt, size);
+pkt->pos = pos;
+pkt->stream_index = 0;
+
+if (sync == 0xAC41)
+avio_skip(pb, 2);
+
+return ret;
+}
+
+AVInputFormat ff_ac4_demuxer = {
+.name   = "ac4",
+.long_name  = NULL_IF_CONFIG_SMALL("raw AC-4"),
+.read_probe = ac4_probe,
+.read_header= ac4_read_header,
+.read_packet= ac4_read_packet,
+.flags  = AVFMT_GENERIC_INDEX,
+.extensions = "ac4",
+};
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0209bf0e30..d2afcb2bdd 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -33,6 +33,7 @@ extern AVInputFormat  ff_aa_demuxer;
 extern AVInputFormat  ff_aac_demuxer;
 extern AVInputFormat  ff_ac3_demuxer;
 extern AVOutputFormat ff_ac3_muxer;
+extern AVInputFormat  ff_ac4_demuxer;
 extern AVInputFormat  ff_acm_demuxer;
 extern AVInputFormat  ff_act_demuxer;
 extern AVInputFormat  ff_adf_demuxer;
-- 
2.17.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer

[James Almer]

On 3/4/2020 7:26 PM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavformat/Makefile |   1 +
>  libavformat/ac4dec.c | 104 +++
>  libavformat/allformats.c |   1 +
>  3 files changed, 106 insertions(+)
>  create mode 100644 libavformat/ac4dec.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index e0681058a2..b4e8d20e65 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
>  OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o rawdec.o
>  OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
>  OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
> +OBJS-$(CONFIG_AC4_DEMUXER)   += ac4dec.o
>  OBJS-$(CONFIG_ACM_DEMUXER)   += acm.o rawdec.o
>  OBJS-$(CONFIG_ACT_DEMUXER)   += act.o
>  OBJS-$(CONFIG_ADF_DEMUXER)   += bintext.o sauce.o
> diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
> new file mode 100644
> index 00..8c6e539409
> --- /dev/null
> +++ b/libavformat/ac4dec.c
> @@ -0,0 +1,104 @@
> +/*
> + * RAW AC-4 demuxer
> + * Copyright (c) 2019 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +#include "libavutil/avassert.h"
> +#include "libavutil/crc.h"
> +#include "avformat.h"
> +#include "rawdec.h"
> +
> +static int ac4_probe(const AVProbeData *p)
> +{
> +const uint8_t *buf = p->buf;
> +int left = p->buf_size;
> +int max_frames = 0;
> +
> +while (left > 7) {
> +int size;
> +
> +if (buf[0] == 0xAC &&
> +(buf[1] == 0x40 ||
> + buf[1] == 0x41)) {
> +size = (buf[2] << 8) | buf[3];
> +if (size == 0x)
> +size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
> +size += 4;
> +if (buf[1] == 0x41)
> +size += 2;
> +max_frames++;
> +left -= size;
> +buf += size;
> +} else {
> +break;
> +}
> +}
> +
> +return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
> +}
> +
> +static int ac4_read_header(AVFormatContext *s)
> +{
> +AVStream *st;
> +
> +st = avformat_new_stream(s, NULL);
> +if (!st)
> +return AVERROR(ENOMEM);
> +
> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> +st->codecpar->codec_id   = AV_CODEC_ID_AC4;
> +
> +return 0;
> +}
> +
> +static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
> +{
> +AVIOContext *pb = s->pb;
> +int64_t pos;
> +uint16_t sync;
> +int ret, size;
> +
> +if (avio_feof(s->pb))
> +return AVERROR_EOF;
> +
> +pos   = avio_tell(s->pb);
> +sync = avio_rb16(pb);

If there are sync codes then it sounds like the proper thing to do is,
much like with AC3, writing a trivial parser to assemble frames and then
use ff_raw_audio_read_header() and ff_raw_read_partial_packet() here
instead of custom functions.

> +size = avio_rb16(pb);
> +if (size == 0x)
> +size = avio_rb24(pb);
> +
> +ret = av_get_packet(pb, pkt, size);
> +pkt->pos = pos;
> +pkt->stream_index = 0;
> +
> +if (sync == 0xAC41)
> +avio_skip(pb, 2);
> +
> +return ret;
> +}
> +
> +AVInputFormat ff_ac4_demuxer = {
> +.name   = "ac4",
> +.long_name  = NULL_IF_CONFIG_SMALL("raw AC-4"),
> +.read_probe = ac4_probe,
> +.read_header= ac4_read_header,
> +.read_packet= ac4_read_packet,
> +.flags  = AVFMT_GENERIC_INDEX,
> +.extensions = "ac4",
> +};
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0209bf0e30..d2afcb2bdd 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -33,6 +33,7 @@ extern AVInputFormat  ff_aa_demuxer;
>  extern AVInputFormat  ff_aac_demuxer;
>  extern AVInputFormat  ff_ac3_demuxer;
>  extern AVOutputFormat ff_ac3_muxer;
> +extern AVInputFormat  ff_ac4_demuxer;
>  extern AVInputFormat  ff_acm_demuxer;
>  extern AVInputFormat  ff_act_demuxer;
>  extern AVInputFormat  ff_adf_demuxer;
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer

[Paul B Mahol]

On 3/4/20, James Almer  wrote:
> On 3/4/2020 7:26 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol 
>> ---
>>  libavformat/Makefile |   1 +
>>  libavformat/ac4dec.c | 104 +++
>>  libavformat/allformats.c |   1 +
>>  3 files changed, 106 insertions(+)
>>  create mode 100644 libavformat/ac4dec.c
>>
>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>> index e0681058a2..b4e8d20e65 100644
>> --- a/libavformat/Makefile
>> +++ b/libavformat/Makefile
>> @@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
>>  OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o
>> rawdec.o
>>  OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
>>  OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
>> +OBJS-$(CONFIG_AC4_DEMUXER)   += ac4dec.o
>>  OBJS-$(CONFIG_ACM_DEMUXER)   += acm.o rawdec.o
>>  OBJS-$(CONFIG_ACT_DEMUXER)   += act.o
>>  OBJS-$(CONFIG_ADF_DEMUXER)   += bintext.o sauce.o
>> diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
>> new file mode 100644
>> index 00..8c6e539409
>> --- /dev/null
>> +++ b/libavformat/ac4dec.c
>> @@ -0,0 +1,104 @@
>> +/*
>> + * RAW AC-4 demuxer
>> + * Copyright (c) 2019 Paul B Mahol
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> + */
>> +
>> +#include "libavutil/avassert.h"
>> +#include "libavutil/crc.h"
>> +#include "avformat.h"
>> +#include "rawdec.h"
>> +
>> +static int ac4_probe(const AVProbeData *p)
>> +{
>> +const uint8_t *buf = p->buf;
>> +int left = p->buf_size;
>> +int max_frames = 0;
>> +
>> +while (left > 7) {
>> +int size;
>> +
>> +if (buf[0] == 0xAC &&
>> +(buf[1] == 0x40 ||
>> + buf[1] == 0x41)) {
>> +size = (buf[2] << 8) | buf[3];
>> +if (size == 0x)
>> +size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
>> +size += 4;
>> +if (buf[1] == 0x41)
>> +size += 2;
>> +max_frames++;
>> +left -= size;
>> +buf += size;
>> +} else {
>> +break;
>> +}
>> +}
>> +
>> +return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
>> +}
>> +
>> +static int ac4_read_header(AVFormatContext *s)
>> +{
>> +AVStream *st;
>> +
>> +st = avformat_new_stream(s, NULL);
>> +if (!st)
>> +return AVERROR(ENOMEM);
>> +
>> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>> +st->codecpar->codec_id   = AV_CODEC_ID_AC4;
>> +
>> +return 0;
>> +}
>> +
>> +static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
>> +{
>> +AVIOContext *pb = s->pb;
>> +int64_t pos;
>> +uint16_t sync;
>> +int ret, size;
>> +
>> +if (avio_feof(s->pb))
>> +return AVERROR_EOF;
>> +
>> +pos   = avio_tell(s->pb);
>> +sync = avio_rb16(pb);
>
> If there are sync codes then it sounds like the proper thing to do is,
> much like with AC3, writing a trivial parser to assemble frames and then
> use ff_raw_audio_read_header() and ff_raw_read_partial_packet() here
> instead of custom functions.

That is over complication for simple parsing like here.
Every raw packet have exact frame size set in bitstream.

>
>> +size = avio_rb16(pb);
>> +if (size == 0x)
>> +size = avio_rb24(pb);
>> +
>> +ret = av_get_packet(pb, pkt, size);
>> +pkt->pos = pos;
>> +pkt->stream_index = 0;
>> +
>> +if (sync == 0xAC41)
>> +avio_skip(pb, 2);
>> +
>> +return ret;
>> +}
>> +
>> +AVInputFormat ff_ac4_demuxer = {
>> +.name   = "ac4",
>> +.long_name  = NULL_IF_CONFIG_SMALL("raw AC-4"),
>> +.read_probe = ac4_probe,
>> +.read_header= ac4_read_header,
>> +.read_packet= ac4_read_packet,
>> +.flags  = AVFMT_GENERIC_INDEX,
>> +.extensions = "ac4",
>> +};
>> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
>> index 0209bf0e30..d2afcb2bdd 100644
>> --- a/libavformat/allformats.c
>> +++ b/libavformat/allformats.c
>> @@ -33,6 +33,7 @@ extern AVInputFormat  ff_aa_demuxer;
>>  extern AVInputFormat  ff_aac_demuxer;
>>  extern AVInputFormat  ff_ac3_demuxer;
>>  exte

Re: [FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer

[James Almer]

On 3/4/2020 7:51 PM, Paul B Mahol wrote:
> On 3/4/20, James Almer  wrote:
>> On 3/4/2020 7:26 PM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol 
>>> ---
>>>  libavformat/Makefile |   1 +
>>>  libavformat/ac4dec.c | 104 +++
>>>  libavformat/allformats.c |   1 +
>>>  3 files changed, 106 insertions(+)
>>>  create mode 100644 libavformat/ac4dec.c
>>>
>>> diff --git a/libavformat/Makefile b/libavformat/Makefile
>>> index e0681058a2..b4e8d20e65 100644
>>> --- a/libavformat/Makefile
>>> +++ b/libavformat/Makefile
>>> @@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
>>>  OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o
>>> rawdec.o
>>>  OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
>>>  OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
>>> +OBJS-$(CONFIG_AC4_DEMUXER)   += ac4dec.o
>>>  OBJS-$(CONFIG_ACM_DEMUXER)   += acm.o rawdec.o
>>>  OBJS-$(CONFIG_ACT_DEMUXER)   += act.o
>>>  OBJS-$(CONFIG_ADF_DEMUXER)   += bintext.o sauce.o
>>> diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
>>> new file mode 100644
>>> index 00..8c6e539409
>>> --- /dev/null
>>> +++ b/libavformat/ac4dec.c
>>> @@ -0,0 +1,104 @@
>>> +/*
>>> + * RAW AC-4 demuxer
>>> + * Copyright (c) 2019 Paul B Mahol
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> + */
>>> +
>>> +#include "libavutil/avassert.h"
>>> +#include "libavutil/crc.h"
>>> +#include "avformat.h"
>>> +#include "rawdec.h"
>>> +
>>> +static int ac4_probe(const AVProbeData *p)
>>> +{
>>> +const uint8_t *buf = p->buf;
>>> +int left = p->buf_size;
>>> +int max_frames = 0;
>>> +
>>> +while (left > 7) {
>>> +int size;
>>> +
>>> +if (buf[0] == 0xAC &&
>>> +(buf[1] == 0x40 ||
>>> + buf[1] == 0x41)) {
>>> +size = (buf[2] << 8) | buf[3];
>>> +if (size == 0x)
>>> +size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
>>> +size += 4;
>>> +if (buf[1] == 0x41)
>>> +size += 2;
>>> +max_frames++;
>>> +left -= size;
>>> +buf += size;
>>> +} else {
>>> +break;
>>> +}
>>> +}
>>> +
>>> +return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
>>> +}
>>> +
>>> +static int ac4_read_header(AVFormatContext *s)
>>> +{
>>> +AVStream *st;
>>> +
>>> +st = avformat_new_stream(s, NULL);
>>> +if (!st)
>>> +return AVERROR(ENOMEM);
>>> +
>>> +st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
>>> +st->codecpar->codec_id   = AV_CODEC_ID_AC4;
>>> +
>>> +return 0;
>>> +}
>>> +
>>> +static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
>>> +{
>>> +AVIOContext *pb = s->pb;
>>> +int64_t pos;
>>> +uint16_t sync;
>>> +int ret, size;
>>> +
>>> +if (avio_feof(s->pb))
>>> +return AVERROR_EOF;
>>> +
>>> +pos   = avio_tell(s->pb);
>>> +sync = avio_rb16(pb);
>>
>> If there are sync codes then it sounds like the proper thing to do is,
>> much like with AC3, writing a trivial parser to assemble frames and then
>> use ff_raw_audio_read_header() and ff_raw_read_partial_packet() here
>> instead of custom functions.
> 
> That is over complication for simple parsing like here.
> Every raw packet have exact frame size set in bitstream.

So does AC3, judging by how its parser assembles frames.

An AVParser will let you resync after a bad seek, read frames in non
seekable input like a pipe, read frames within badly muxed files,
simplify the demuxer, etc, and is a matter of just looking for that
16bit sync code and assembling a frame. Essentially just re-implementing
what you already did in ac4_probe().

> 
>>
>>> +size = avio_rb16(pb);
>>> +if (size == 0x)
>>> +size = avio_rb24(pb);
>>> +
>>> +ret = av_get_packet(pb, pkt, size);
>>> +pkt->pos = pos;
>>> +pkt->stream_index = 0;
>>> +
>>> +if (sync == 0xAC41)
>>> +avio_skip(pb, 2);
>>> +
>>> +return ret;
>>> +}
>>> +
>>> +AVInputFormat ff_ac4_demuxer = {
>>> +.name   = "ac4",
>>> +.long_name  = NULL_IF_CONF

Re: [FFmpeg-devel] [RFC][WIP][PATCH 1/3] avcodec: add AC-4 decoder

[Lou Logan]

On Wed, Mar 4, 2020, at 1:26 PM, Paul B Mahol wrote:
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> +OBJS-$(CONFIG_AC4_DECODER) += ac4dec.o

Missing kbdwin.o.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/3] avformat: add raw AC-4 demuxer

[Andreas Rheinhardt]

Am 05.03.2020 um 00:05 schrieb James Almer:

On 3/4/2020 7:51 PM, Paul B Mahol wrote:

On 3/4/20, James Almer  wrote:

On 3/4/2020 7:26 PM, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
  libavformat/Makefile |   1 +
  libavformat/ac4dec.c | 104 +++
  libavformat/allformats.c |   1 +
  3 files changed, 106 insertions(+)
  create mode 100644 libavformat/ac4dec.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e0681058a2..b4e8d20e65 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -70,6 +70,7 @@ OBJS-$(CONFIG_AA_DEMUXER)+= aadec.o
  OBJS-$(CONFIG_AAC_DEMUXER)   += aacdec.o apetag.o img2.o
rawdec.o
  OBJS-$(CONFIG_AC3_DEMUXER)   += ac3dec.o rawdec.o
  OBJS-$(CONFIG_AC3_MUXER) += rawenc.o
+OBJS-$(CONFIG_AC4_DEMUXER)   += ac4dec.o
  OBJS-$(CONFIG_ACM_DEMUXER)   += acm.o rawdec.o
  OBJS-$(CONFIG_ACT_DEMUXER)   += act.o
  OBJS-$(CONFIG_ADF_DEMUXER)   += bintext.o sauce.o
diff --git a/libavformat/ac4dec.c b/libavformat/ac4dec.c
new file mode 100644
index 00..8c6e539409
--- /dev/null
+++ b/libavformat/ac4dec.c
@@ -0,0 +1,104 @@
+/*
+ * RAW AC-4 demuxer
+ * Copyright (c) 2019 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
+ */
+
+#include "libavutil/avassert.h"
+#include "libavutil/crc.h"
+#include "avformat.h"
+#include "rawdec.h"
+
+static int ac4_probe(const AVProbeData *p)
+{
+const uint8_t *buf = p->buf;
+int left = p->buf_size;
+int max_frames = 0;
+
+while (left > 7) {
+int size;
+
+if (buf[0] == 0xAC &&
+(buf[1] == 0x40 ||
+ buf[1] == 0x41)) {
+size = (buf[2] << 8) | buf[3];
+if (size == 0x)
+size = 3 + (buf[4] << 16) | (buf[5] << 8) | buf[6];
+size += 4;
+if (buf[1] == 0x41)
+size += 2;
+max_frames++;
+left -= size;
+buf += size;
+} else {
+break;
+}
+}
+
+return FFMIN(AVPROBE_SCORE_MAX, max_frames * 7);
+}
+
+static int ac4_read_header(AVFormatContext *s)
+{
+AVStream *st;
+
+st = avformat_new_stream(s, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+
+st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
+st->codecpar->codec_id   = AV_CODEC_ID_AC4;
+
+return 0;
+}
+
+static int ac4_read_packet(AVFormatContext *s, AVPacket *pkt)
+{
+AVIOContext *pb = s->pb;
+int64_t pos;
+uint16_t sync;
+int ret, size;
+
+if (avio_feof(s->pb))
+return AVERROR_EOF;
+
+pos   = avio_tell(s->pb);
+sync = avio_rb16(pb);


If there are sync codes then it sounds like the proper thing to do is,
much like with AC3, writing a trivial parser to assemble frames and then
use ff_raw_audio_read_header() and ff_raw_read_partial_packet() here
instead of custom functions.


That is over complication for simple parsing like here.
Every raw packet have exact frame size set in bitstream.


So does AC3, judging by how its parser assembles frames.

An AVParser will let you resync after a bad seek, read frames in non
seekable input like a pipe, read frames within badly muxed files,
simplify the demuxer, etc, and is a matter of just looking for that
16bit sync code and assembling a frame. Essentially just re-implementing
what you already did in ac4_probe().



If it is intended that the actual AVPackets should not contain the 
sync code and the size field at all, then this should be dropped in 
the demuxer here (but then the demuxer actually needs to check for 
sync codes and needs to handle resyncing itself). This will also mean 
that memcpy of the data can be avoided; which is not so when relying 
on a parser as the packet size is not chosen adaptively for the content.


The decoder seems to allow both variants: With header and without 
header. Is there a packetization that strips this header away? (And 
what is actually contained in the last two bytes in case the sync code 
is 0xAC41?)


- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visi

[FFmpeg-devel] [PATCH] avformat/rtp: Pass sources and block filter addresses via sdp file for rtp

[phunkyfish]

---
 libavformat/rtsp.c | 48 ++
 1 file changed, 40 insertions(+), 8 deletions(-)

diff --git a/libavformat/rtsp.c b/libavformat/rtsp.c
index cd6fc32a29..f6d66526b0 100644
--- a/libavformat/rtsp.c
+++ b/libavformat/rtsp.c
@@ -2447,8 +2447,8 @@ static int rtp_probe(const AVProbeData *p)
 static int rtp_read_header(AVFormatContext *s)
 {
 uint8_t recvbuf[RTP_MAX_PACKET_LENGTH];
-char host[500], sdp[500];
-int ret, port;
+char host[500], sdp[1000], filters_buf[1000];
+int ret, port, sdp_length, nc;
 URLContext* in = NULL;
 int payload_type;
 AVCodecParameters *par = NULL;
@@ -2456,6 +2456,7 @@ static int rtp_read_header(AVFormatContext *s)
 AVIOContext pb;
 socklen_t addrlen = sizeof(addr);
 RTSPState *rt = s->priv_data;
+const char *p;
 
 if (!ff_network_init())
 return AVERROR(EIO);
@@ -2513,12 +2514,40 @@ static int rtp_read_header(AVFormatContext *s)
 av_url_split(NULL, 0, NULL, 0, host, sizeof(host), &port,
  NULL, 0, s->url);
 
-snprintf(sdp, sizeof(sdp),
- "v=0\r\nc=IN IP%d %s\r\nm=%s %d RTP/AVP %d\r\n",
- addr.ss_family == AF_INET ? 4 : 6, host,
- par->codec_type == AVMEDIA_TYPE_DATA  ? "application" :
- par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
- port, payload_type);
+sdp_length = snprintf(sdp, sizeof(sdp),
+  "v=0\r\nc=IN IP%d %s\r\n",
+  addr.ss_family == AF_INET ? 4 : 6, host);
+
+p = strchr(s->url, '?');
+if (p) {
+static const char *filters[][2] = {{"sources", "incl"}, {"block", 
"excl"}, {NULL, NULL}};
+int i;
+char *q;
+for (i = 0; filters[i][0]; i++) {
+if (av_find_info_tag(filters_buf, sizeof(filters_buf), 
filters[i][0], p)) {
+/* av_log(s, AV_LOG_VERBOSE, "rtp_read_header() found %s 
%s\n", filters[i][0], filters_buf); */
+q = filters_buf;
+while ((q = strchr(q, ',')) != NULL)
+*q = ' ';
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+  "a=source-filter:%s IN IP%d %s %s\r\n",
+  filters[i][1],
+  addr.ss_family == AF_INET ? 4 : 6, host,
+  filters_buf);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
+sdp_length += nc;
+}
+}
+}
+
+nc = snprintf(sdp + sdp_length, sizeof(sdp) - sdp_length,
+  "m=%s %d RTP/AVP %d\r\n",
+  par->codec_type == AVMEDIA_TYPE_DATA  ? "application" :
+  par->codec_type == AVMEDIA_TYPE_VIDEO ? "video" : "audio",
+  port, payload_type);
+if (nc < 0 || nc + sdp_length >= sizeof(sdp))
+goto fail_nobuf;
 av_log(s, AV_LOG_VERBOSE, "SDP:\n%s\n", sdp);
 avcodec_parameters_free(&par);
 
@@ -2534,6 +2563,9 @@ static int rtp_read_header(AVFormatContext *s)
 s->pb = NULL;
 return ret;
 
+fail_nobuf:
+ret = AVERROR(ENOBUFS);
+av_log(s, AV_LOG_ERROR, "rtp_read_header(): not enough buffer space for 
sdp-headers\n");
 fail:
 avcodec_parameters_free(&par);
 if (in)
-- 
2.20.1 (Apple Git-117)

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] vaapi_encode_h265: Query encoding block sizes and features

[Mark Thompson]

---
Requires .  That isn't upstream, so 
this will need to wait for that and then get at least a fix to the version 
numbering before applying.

 libavcodec/vaapi_encode_h265.c | 91 +++---
 1 file changed, 74 insertions(+), 17 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index dcc22eb610..59d150f503 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -56,6 +56,7 @@ typedef struct VAAPIEncodeH265Context {
 VAAPIEncodeContext common;
 
 // Encoder features.
+uint32_t va_features;
 uint32_t ctu_size;
 uint32_t min_cb_size;
 
@@ -440,23 +441,54 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 vps->vps_max_latency_increase_plus1[i];
 }
 
-// These have to come from the capabilities of the encoder.  We have no
-// way to query them, so just hardcode parameters which work on the Intel
-// driver.
-// CTB size from 8x8 to 32x32.
-sps->log2_min_luma_coding_block_size_minus3   = 0;
-sps->log2_diff_max_min_luma_coding_block_size = 2;
-// Transform size from 4x4 to 32x32.
-sps->log2_min_luma_transform_block_size_minus2   = 0;
-sps->log2_diff_max_min_luma_transform_block_size = 3;
-// Full transform hierarchy allowed (2-5).
-sps->max_transform_hierarchy_depth_inter = 3;
-sps->max_transform_hierarchy_depth_intra = 3;
-// AMP works.
-sps->amp_enabled_flag = 1;
-// SAO and temporal MVP do not work.
-sps->sample_adaptive_offset_enabled_flag = 0;
-sps->sps_temporal_mvp_enabled_flag   = 0;
+#if VA_CHECK_VERSION(1, 7, 0)
+if (priv->va_features) {
+VAConfigAttribValEncHEVCFeatures features = { .value = 
priv->va_features };
+
+sps->log2_min_luma_coding_block_size_minus3 =
+ff_ctz(priv->min_cb_size) - 3;
+sps->log2_diff_max_min_luma_coding_block_size =
+ff_ctz(priv->ctu_size) - ff_ctz(priv->min_cb_size);
+
+sps->log2_min_luma_transform_block_size_minus2 =
+features.bits.log2_min_luma_transform_block_size_minus2;
+sps->log2_diff_max_min_luma_transform_block_size =
+features.bits.log2_max_luma_transform_block_size_minus2 -
+features.bits.log2_min_luma_transform_block_size_minus2;
+
+sps->max_transform_hierarchy_depth_inter =
+features.bits.max_transform_hierarchy_depth_inter;
+sps->max_transform_hierarchy_depth_intra =
+features.bits.max_transform_hierarchy_depth_intra;
+
+sps->amp_enabled_flag =
+features.bits.amp_supported;
+sps->sample_adaptive_offset_enabled_flag =
+features.bits.sao_supported;
+sps->sps_temporal_mvp_enabled_flag =
+features.bits.temporal_mvp_supported;
+} else
+#endif
+{
+// These values come from the capabilities of the first encoder
+// implementation in the i965 driver on Intel Skylake.  They may
+// fail badly with other platforms or drivers.
+// CTB size from 8x8 to 32x32.
+sps->log2_min_luma_coding_block_size_minus3   = 0;
+sps->log2_diff_max_min_luma_coding_block_size = 2;
+// Transform size from 4x4 to 32x32.
+sps->log2_min_luma_transform_block_size_minus2   = 0;
+sps->log2_diff_max_min_luma_transform_block_size = 3;
+// Full transform hierarchy allowed (2-5).
+sps->max_transform_hierarchy_depth_inter = 3;
+sps->max_transform_hierarchy_depth_intra = 3;
+// AMP works.
+sps->amp_enabled_flag = 1;
+// SAO and temporal MVP do not work.
+sps->sample_adaptive_offset_enabled_flag = 0;
+sps->sps_temporal_mvp_enabled_flag   = 0;
+}
+
 
 sps->pcm_enabled_flag = 0;
 
@@ -1073,6 +1105,31 @@ static av_cold void 
vaapi_encode_h265_block_size(AVCodecContext *avctx)
 VAAPIEncodeContext  *ctx = avctx->priv_data;
 VAAPIEncodeH265Context *priv = avctx->priv_data;
 
+#if VA_CHECK_VERSION(1, 7, 0)
+{
+VAConfigAttrib attr = { VAConfigAttribEncHEVCFeatures };
+VAConfigAttribValEncHEVCFeatures features;
+VAStatus vas;
+
+vas = vaGetConfigAttributes(ctx->hwctx->display, ctx->va_profile,
+ctx->va_entrypoint, &attr, 1);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_WARNING, "Failed to query encoder "
+   "features, using guessed defaults.\n");
+} else if (attr.value == VA_ATTRIB_NOT_SUPPORTED) {
+av_log(avctx, AV_LOG_WARNING, "Driver does not advertise "
+   "encoder features, using guessed defaults.\n");
+} else {
+features.value = priv->va_features = attr.value;
+
+priv->ctu_size =
+1 << features.bits.log2_max_coding_tree_block_size_minus3 + 3;
+priv->min_cb_size =
+  

[FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2 support

[Mark Thompson]

---
With , intra-only 4:2:2 encode 
works on Ice Lake with something like:

 -vf 'format=yuyv422,hwupload' -c:v hevc_vaapi -g 1 out.mp4

There is still something wrong with inter frames.

 libavcodec/vaapi_encode_h265.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 59d150f503..79e3c70602 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1197,6 +1197,10 @@ static const VAAPIEncodeProfile 
vaapi_encode_h265_profiles[] = {
 #if VA_CHECK_VERSION(0, 37, 0)
 { FF_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1, VAProfileHEVCMain10 },
 { FF_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain10 },
+#endif
+#if VA_CHECK_VERSION(1, 2, 0)
+{ FF_PROFILE_HEVC_REXT, 8, 3, 1, 0, VAProfileHEVCMain422_10 },
+{ FF_PROFILE_HEVC_REXT,10, 3, 1, 0, VAProfileHEVCMain422_10 },
 #endif
 { FF_PROFILE_UNKNOWN }
 };
-- 
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] vaapi_encode: Move block size calculation after entrypoint selection

[Mark Thompson]

The block size can be dependent on the profile and entrypoint selected.
It defaults to 16x16, with codecs able to override this choice with their
own function.
---
 libavcodec/vaapi_encode.c   | 14 ++
 libavcodec/vaapi_encode.h   |  6 ++
 libavcodec/vaapi_encode_h265.c  | 32 ++--
 libavcodec/vaapi_encode_mjpeg.c | 16 +---
 libavcodec/vaapi_encode_mpeg2.c |  3 ---
 libavcodec/vaapi_encode_vp8.c   |  3 ---
 libavcodec/vaapi_encode_vp9.c   | 14 ++
 7 files changed, 69 insertions(+), 19 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8ff720e395..93bbed4539 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1840,6 +1840,8 @@ static av_cold int 
vaapi_encode_init_slice_structure(AVCodecContext *avctx)
 return 0;
 }
 
+av_assert0(ctx->slice_block_height > 0 && ctx->slice_block_width > 0);
+
 ctx->slice_block_rows = (avctx->height + ctx->slice_block_height - 1) /
  ctx->slice_block_height;
 ctx->slice_block_cols = (avctx->width  + ctx->slice_block_width  - 1) /
@@ -2237,6 +2239,18 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
 if (err < 0)
 goto fail;
 
+if (ctx->codec->block_size) {
+ctx->codec->block_size(avctx);
+} else {
+// Assume 16x16 blocks.
+ctx->surface_width  = FFALIGN(avctx->width,  16);
+ctx->surface_height = FFALIGN(avctx->height, 16);
+if (ctx->codec->flags & FLAG_SLICE_CONTROL) {
+ctx->slice_block_width  = 16;
+ctx->slice_block_height = 16;
+}
+}
+
 err = vaapi_encode_init_rate_control(avctx);
 if (err < 0)
 goto fail;
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index b9a3defd72..583be9c845 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -355,6 +355,12 @@ typedef struct VAAPIEncodeType {
 // factor depending on RC mode.
 int default_quality;
 
+// Determine block sizes for surface alignment and slices.  This may
+// need to query the profile and entrypoint, which will be available
+// when this function is called.  If not set, assume that all blocks
+// are 16x16 and that surfaces should be aligned to match this.
+void (*block_size)(AVCodecContext *avctx);
+
 // Perform any extra codec-specific configuration after the
 // codec context is initialised (set up the private data and
 // add any necessary global parameters).
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 538862a9d5..9a78dfb4f7 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -55,6 +55,10 @@ typedef struct VAAPIEncodeH265Picture {
 typedef struct VAAPIEncodeH265Context {
 VAAPIEncodeContext common;
 
+// Encoder features.
+uint32_t ctu_size;
+uint32_t min_cb_size;
+
 // User options.
 int qp;
 int aud;
@@ -1062,6 +1066,27 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 return 0;
 }
 
+static av_cold void vaapi_encode_h265_block_size(AVCodecContext *avctx)
+{
+VAAPIEncodeContext  *ctx = avctx->priv_data;
+VAAPIEncodeH265Context *priv = avctx->priv_data;
+
+if (!priv->ctu_size) {
+priv->ctu_size = 32;
+priv->min_cb_size  = 16;
+}
+av_log(avctx, AV_LOG_VERBOSE, "Using CTU size %dx%d, "
+   "min CB size %dx%d.\n", priv->ctu_size, priv->ctu_size,
+   priv->min_cb_size, priv->min_cb_size);
+
+ctx->surface_width  = FFALIGN(avctx->width,  priv->min_cb_size);
+ctx->surface_height = FFALIGN(avctx->height, priv->min_cb_size);
+
+ctx->slice_block_width = ctx->slice_block_height = priv->ctu_size;
+
+return;
+}
+
 static av_cold int vaapi_encode_h265_configure(AVCodecContext *avctx)
 {
 VAAPIEncodeContext  *ctx = avctx->priv_data;
@@ -1127,6 +1152,7 @@ static const VAAPIEncodeType vaapi_encode_type_h265 = {
 
 .default_quality   = 25,
 
+.block_size= &vaapi_encode_h265_block_size,
 .configure = &vaapi_encode_h265_configure,
 
 .picture_priv_data_size = sizeof(VAAPIEncodeH265Picture),
@@ -1172,12 +1198,6 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext 
*avctx)
 VA_ENC_PACKED_HEADER_SLICE| // Slice headers.
 VA_ENC_PACKED_HEADER_MISC;  // SEI
 
-ctx->surface_width  = FFALIGN(avctx->width,  16);
-ctx->surface_height = FFALIGN(avctx->height, 16);
-
-// CTU size is currently hard-coded to 32.
-ctx->slice_block_width = ctx->slice_block_height = 32;
-
 if (priv->qp > 0)
 ctx->explicit_qp = priv->qp;
 
diff --git a/libavcodec/vaapi_encode_mjpeg.c b/libavcodec/vaapi_encode_mjpeg.c
index bd029cc903..0d992d6f44 100644
--- a/libavcodec/vaapi_encode_mjpeg.c
+++ b/libavcodec/vaapi_encode_mjpeg.c
@@ -434,6 +434,18 @@ static int 
vaapi_encode_mjpeg_init_

[FFmpeg-devel] [PATCH 2/4] avformat: add demuxer for LEGO Racers' ALP format

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/alp.c| 135 +++
 libavformat/version.h|   4 +-
 4 files changed, 139 insertions(+), 2 deletions(-)
 create mode 100644 libavformat/alp.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index e0681058a2..fbb29505ff 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -85,6 +85,7 @@ OBJS-$(CONFIG_AIFF_DEMUXER)  += aiffdec.o pcm.o 
isom.o \
 mov_chan.o replaygain.o
 OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
 OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
+OBJS-$(CONFIG_ALP_DEMUXER)   += alp.o
 OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
 OBJS-$(CONFIG_AMR_MUXER) += amr.o
 OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0209bf0e30..08012ea208 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -46,6 +46,7 @@ extern AVInputFormat  ff_afc_demuxer;
 extern AVInputFormat  ff_aiff_demuxer;
 extern AVOutputFormat ff_aiff_muxer;
 extern AVInputFormat  ff_aix_demuxer;
+extern AVInputFormat  ff_alp_demuxer;
 extern AVInputFormat  ff_amr_demuxer;
 extern AVOutputFormat ff_amr_muxer;
 extern AVInputFormat  ff_amrnb_demuxer;
diff --git a/libavformat/alp.c b/libavformat/alp.c
new file mode 100644
index 00..76703e7ad1
--- /dev/null
+++ b/libavformat/alp.c
@@ -0,0 +1,135 @@
+/*
+ * LEGO Racers ALP (.tun & .pcm) demuxer
+ *
+ * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+#include "avformat.h"
+#include "internal.h"
+#include "libavutil/intreadwrite.h"
+
+#define ALP_TAGMKTAG('A', 'L', 'P', ' ')
+#define ALP_MAX_READ_SIZE  4096
+
+typedef struct ALPHeader {
+uint32_tmagic;  /*< Magic Number, {'A', 'L', 'P', ' '} */
+uint32_theader_size;/*< Header size (after this). */
+charadpcm[6];   /*< "ADPCM" */
+uint8_t unk1;   /*< Unknown */
+uint8_t num_channels;   /*< Channel Count. */
+uint32_tsample_rate;/*< Sample rate, only if header_size >= 12. */
+} ALPHeader;
+
+static int alp_probe(const AVProbeData *p)
+{
+if (AV_RL32(p->buf) != ALP_TAG)
+return 0;
+
+if (AV_RL32(p->buf) < 8)
+return 0;
+
+return AVPROBE_SCORE_EXTENSION + 1;
+}
+
+static int alp_read_header(AVFormatContext *s)
+{
+int ret;
+AVStream *st;
+ALPHeader hdr;
+AVCodecParameters *par;
+
+memset(&hdr, 0, sizeof(hdr));
+
+if (!(st = avformat_new_stream(s, NULL)))
+return AVERROR(ENOMEM);
+
+if ((hdr.magic = avio_rl32(s->pb)) != ALP_TAG)
+return AVERROR_INVALIDDATA;
+
+hdr.header_size = avio_rl32(s->pb);
+
+if (hdr.header_size != 8 && hdr.header_size != 12) {
+return AVERROR_INVALIDDATA;
+}
+
+if ((ret = avio_read(s->pb, hdr.adpcm, sizeof(hdr.adpcm))) < 0)
+return ret;
+else if (ret != sizeof(hdr.adpcm))
+return AVERROR(EIO);
+
+if (strncmp("ADPCM", hdr.adpcm, sizeof(hdr.adpcm)) != 0)
+return AVERROR_INVALIDDATA;
+
+hdr.unk1= avio_r8(s->pb);
+hdr.num_channels= avio_r8(s->pb);
+
+if (hdr.header_size == 8) {
+/* .TUN music file */
+hdr.sample_rate = 11025 * hdr.num_channels;
+} else {
+/* .PCM sound file */
+hdr.sample_rate = avio_rl32(s->pb);
+}
+
+par = st->codecpar;
+par->codec_type = AVMEDIA_TYPE_AUDIO;
+par->codec_id   = AV_CODEC_ID_ADPCM_IMA_ALP;
+par->format = AV_SAMPLE_FMT_S16;
+par->sample_rate= hdr.sample_rate;
+par->channels   = hdr.num_channels;
+
+if (hdr.num_channels == 1)
+par->channel_layout = AV_CH_LAYOUT_MONO;
+else if (hdr.num_channels == 2)
+par->channel_layout = AV_CH_LAYOUT_STEREO;
+else
+return AVERROR_INVALIDDATA;
+
+par->bits_per_coded_sample  = 4;
+par->bits_per_raw_sample= 16;
+par->b

[FFmpeg-devel] [PATCH 3/4] changelog: add adpcm_ima_alp decoder and alp demuxer

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 Changelog | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/Changelog b/Changelog
index cb310a3abc..0503069daa 100644
--- a/Changelog
+++ b/Changelog
@@ -43,7 +43,8 @@ version :
 - Rayman 2 ADPCM decoder
 - Rayman 2 APM demuxer
 - cas video filter
-
+- High Voltage Software ADPCM decoder
+- LEGO Racers ALP (.tun & .pcm) demuxer
 
 version 4.2:
 - tpad filter
-- 
2.17.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 4/4] doc: add adpcm_ima_alp

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 doc/general.texi | 1 +
 1 file changed, 1 insertion(+)

diff --git a/doc/general.texi b/doc/general.texi
index dbdc348598..87eaad7791 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -1100,6 +1100,7 @@ following image formats are supported:
 @item ADPCM IMA Electronic Arts EACS  @tab @tab  X
 @item ADPCM IMA Electronic Arts SEAD  @tab @tab  X
 @item ADPCM IMA Funcom   @tab @tab  X
+@item ADPCM IMA High Voltage Software ALP   @tab @tab  X
 @item ADPCM IMA QuickTime@tab  X  @tab  X
 @item ADPCM IMA Simon & Schuster Interactive   @tab  @tab  X
 @item ADPCM IMA Ubisoft APM  @tab @tab X
-- 
2.17.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] ClipGrab Function Request / Suggestion

[Tom Schmidt]

I use a satellite service, HighesNet, to access the Internet.  I can use
50GB from 2am to 8am for almost free (won't affect my data usage total).

It would really be nice if ClipGrab could download a video at a certain day
and time so that my data usage isn't negatively impacted thereby saving me
$$.

Yes, I would be willing to donate (again) for this capability.

Thanks for your consideration.   Tom Schmidt
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/4] High Voltage Software ALP demuxer + decoder.

[Zane van Iperen]

Adds support for the .TUN and .PCM files used by some
High Voltage Software games.

Zane van Iperen (4):
  avcodec: add decoder for High Voltage Software's ALP ADPCM
  avformat: add demuxer for LEGO Racers' ALP format
  changelog: add adpcm_ima_alp decoder and alp demuxer
  doc: add adpcm_ima_alp

 Changelog|   3 +-
 doc/general.texi |   1 +
 libavcodec/Makefile  |   1 +
 libavcodec/adpcm.c   |  36 +++
 libavcodec/allcodecs.c   |   1 +
 libavcodec/avcodec.h |   1 +
 libavcodec/codec_desc.c  |   7 ++
 libavcodec/version.h |   4 +-
 libavformat/Makefile |   1 +
 libavformat/allformats.c |   1 +
 libavformat/alp.c| 135 +++
 libavformat/version.h|   4 +-
 12 files changed, 190 insertions(+), 5 deletions(-)
 create mode 100644 libavformat/alp.c

-- 
2.17.1


___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] avcodec: add decoder for High Voltage Software's ALP ADPCM

[Zane van Iperen]

Signed-off-by: Zane van Iperen 
---
 libavcodec/Makefile |  1 +
 libavcodec/adpcm.c  | 36 
 libavcodec/allcodecs.c  |  1 +
 libavcodec/avcodec.h|  1 +
 libavcodec/codec_desc.c |  7 +++
 libavcodec/version.h|  4 ++--
 6 files changed, 48 insertions(+), 2 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index f1c032b456..0fd374ffed 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -834,6 +834,7 @@ OBJS-$(CONFIG_ADPCM_G726_ENCODER) += g726.o
 OBJS-$(CONFIG_ADPCM_G726LE_DECODER)   += g726.o
 OBJS-$(CONFIG_ADPCM_G726LE_ENCODER)   += g726.o
 OBJS-$(CONFIG_ADPCM_IMA_AMV_DECODER)  += adpcm.o adpcm_data.o
+OBJS-$(CONFIG_ADPCM_IMA_ALP_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_APC_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_APM_DECODER)  += adpcm.o adpcm_data.o
 OBJS-$(CONFIG_ADPCM_IMA_DAT4_DECODER) += adpcm.o adpcm_data.o
diff --git a/libavcodec/adpcm.c b/libavcodec/adpcm.c
index 5f152ee6ef..c69cac3379 100644
--- a/libavcodec/adpcm.c
+++ b/libavcodec/adpcm.c
@@ -15,6 +15,7 @@
  * Argonaut Games ADPCM decoder by Zane van Iperen (z...@zanevaniperen.com)
  * Simon & Schuster Interactive ADPCM decoder by Zane van Iperen 
(z...@zanevaniperen.com)
  * Ubisoft ADPCM decoder by Zane van Iperen (z...@zanevaniperen.com)
+ * High Voltage Software ALP decoder by Zane van Iperen 
(z...@zanevaniperen.com)
  *
  * This file is part of FFmpeg.
  *
@@ -280,6 +281,29 @@ static inline int16_t 
adpcm_ima_expand_nibble(ADPCMChannelStatus *c, int8_t nibb
 return (int16_t)c->predictor;
 }
 
+static inline int16_t adpcm_ima_alp_expand_nibble(ADPCMChannelStatus *c, 
int8_t nibble, int shift)
+{
+int step_index;
+int predictor;
+int sign, delta, diff, step;
+
+step = ff_adpcm_step_table[c->step_index];
+step_index = c->step_index + ff_adpcm_index_table[(unsigned)nibble];
+step_index = av_clip(step_index, 0, 88);
+
+sign = nibble & 8;
+delta = nibble & 7;
+diff = (delta * step) >> shift;
+predictor = c->predictor;
+if (sign) predictor -= diff;
+else predictor += diff;
+
+c->predictor = av_clip_int16(predictor);
+c->step_index = step_index;
+
+return (int16_t)c->predictor;
+}
+
 static inline int16_t adpcm_ima_wav_expand_nibble(ADPCMChannelStatus *c, 
GetBitContext *gb, int bps)
 {
 int nibble, step_index, predictor, sign, delta, diff, step, shift;
@@ -675,6 +699,7 @@ static int get_nb_samples(AVCodecContext *avctx, 
GetByteContext *gb,
 case AV_CODEC_ID_ADPCM_AICA:
 case AV_CODEC_ID_ADPCM_IMA_SSI:
 case AV_CODEC_ID_ADPCM_IMA_APM:
+case AV_CODEC_ID_ADPCM_IMA_ALP:
 nb_samples = buf_size * 2 / ch;
 break;
 }
@@ -1247,6 +1272,16 @@ static int adpcm_decode_frame(AVCodecContext *avctx, 
void *data,
 samples += avctx->channels;
 }
 break;
+case AV_CODEC_ID_ADPCM_IMA_ALP:
+for (n = nb_samples / 2; n > 0; n--) {
+for (channel = 0; channel < avctx->channels; channel++) {
+int v = bytestream2_get_byteu(&gb);
+*samples++  = adpcm_ima_alp_expand_nibble(&c->status[channel], 
v >> 4  , 2);
+samples[st] = adpcm_ima_alp_expand_nibble(&c->status[channel], 
v & 0x0F, 2);
+}
+samples += avctx->channels;
+}
+break;
 case AV_CODEC_ID_ADPCM_IMA_OKI:
 while (bytestream2_get_bytes_left(&gb) > 0) {
 int v = bytestream2_get_byteu(&gb);
@@ -1997,6 +2032,7 @@ ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_QT,  
sample_fmts_s16p, adpcm_ima_qt,
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_RAD, sample_fmts_s16,  adpcm_ima_rad,  
   "ADPCM IMA Radical");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_SSI, sample_fmts_s16,  adpcm_ima_ssi,  
   "ADPCM IMA Simon & Schuster Interactive");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_SMJPEG,  sample_fmts_s16,  
adpcm_ima_smjpeg,  "ADPCM IMA Loki SDL MJPEG");
+ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_ALP, sample_fmts_s16,  adpcm_ima_alp,  
   "ADPCM IMA High Voltage Software ALP");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WAV, sample_fmts_s16p, adpcm_ima_wav,  
   "ADPCM IMA WAV");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_IMA_WS,  sample_fmts_both, adpcm_ima_ws,   
   "ADPCM IMA Westwood");
 ADPCM_DECODER(AV_CODEC_ID_ADPCM_MS,  sample_fmts_both, adpcm_ms,   
   "ADPCM Microsoft");
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 674995df72..f4cf180716 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -599,6 +599,7 @@ extern AVCodec ff_adpcm_g726_decoder;
 extern AVCodec ff_adpcm_g726le_encoder;
 extern AVCodec ff_adpcm_g726le_decoder;
 extern AVCodec ff_adpcm_ima_amv_decoder;
+extern AVCodec ff_adpcm_ima_alp_decoder;
 extern AVCodec ff_adpcm_ima_apc_decoder;
 extern AVCodec ff_adpcm_ima_apm_decoder;
 extern AVCodec ff_adpcm_ima_dat4_decoder;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h

[FFmpeg-devel] [PATCH 2/4] vaapi_encode_h265: Explicitly set all profile constraint flags

[Mark Thompson]

max_14bit_constraint_flag should be set if the bit depth is not greater than
14 (currently always true).

one_picture_only_flag should not be set because we don't support the still
picture profiles.
---
 libavcodec/vaapi_encode_h265.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 9a78dfb4f7..dcc22eb610 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -330,6 +330,7 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 ptl->general_non_packed_constraint_flag = 1;
 ptl->general_frame_only_constraint_flag = 1;
 
+ptl->general_max_14bit_constraint_flag = bit_depth <= 14;
 ptl->general_max_12bit_constraint_flag = bit_depth <= 12;
 ptl->general_max_10bit_constraint_flag = bit_depth <= 10;
 ptl->general_max_8bit_constraint_flag  = bit_depth ==  8;
@@ -339,6 +340,7 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 ptl->general_max_monochrome_constraint_flag = chroma_format == 0;
 
 ptl->general_intra_constraint_flag = ctx->gop_size == 1;
+ptl->general_one_picture_only_constraint_flag = 0;
 
 ptl->general_lower_bit_rate_constraint_flag = 1;
 
-- 
2.25.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/4] avformat: add demuxer for LEGO Racers' ALP format

[Andreas Rheinhardt]

Am 05.03.2020 um 01:40 schrieb Zane van Iperen:
> Signed-off-by: Zane van Iperen 
> ---
>  libavformat/Makefile |   1 +
>  libavformat/allformats.c |   1 +
>  libavformat/alp.c| 135 +++
>  libavformat/version.h|   4 +-
>  4 files changed, 139 insertions(+), 2 deletions(-)
>  create mode 100644 libavformat/alp.c
> 
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index e0681058a2..fbb29505ff 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -85,6 +85,7 @@ OBJS-$(CONFIG_AIFF_DEMUXER)  += aiffdec.o pcm.o 
> isom.o \
>  mov_chan.o replaygain.o
>  OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
>  OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
> +OBJS-$(CONFIG_ALP_DEMUXER)   += alp.o
>  OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
>  OBJS-$(CONFIG_AMR_MUXER) += amr.o
>  OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
> diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> index 0209bf0e30..08012ea208 100644
> --- a/libavformat/allformats.c
> +++ b/libavformat/allformats.c
> @@ -46,6 +46,7 @@ extern AVInputFormat  ff_afc_demuxer;
>  extern AVInputFormat  ff_aiff_demuxer;
>  extern AVOutputFormat ff_aiff_muxer;
>  extern AVInputFormat  ff_aix_demuxer;
> +extern AVInputFormat  ff_alp_demuxer;
>  extern AVInputFormat  ff_amr_demuxer;
>  extern AVOutputFormat ff_amr_muxer;
>  extern AVInputFormat  ff_amrnb_demuxer;
> diff --git a/libavformat/alp.c b/libavformat/alp.c
> new file mode 100644
> index 00..76703e7ad1
> --- /dev/null
> +++ b/libavformat/alp.c
> @@ -0,0 +1,135 @@
> +/*
> + * LEGO Racers ALP (.tun & .pcm) demuxer
> + *
> + * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +#include "avformat.h"
> +#include "internal.h"
> +#include "libavutil/intreadwrite.h"
> +
> +#define ALP_TAGMKTAG('A', 'L', 'P', ' ')
> +#define ALP_MAX_READ_SIZE  4096
> +
> +typedef struct ALPHeader {
> +uint32_tmagic;  /*< Magic Number, {'A', 'L', 'P', ' '} */
> +uint32_theader_size;/*< Header size (after this). */
> +charadpcm[6];   /*< "ADPCM" */
> +uint8_t unk1;   /*< Unknown */
> +uint8_t num_channels;   /*< Channel Count. */
> +uint32_tsample_rate;/*< Sample rate, only if header_size >= 12. 
> */
> +} ALPHeader;
> +
> +static int alp_probe(const AVProbeData *p)
> +{
> +if (AV_RL32(p->buf) != ALP_TAG)
> +return 0;
> +
> +if (AV_RL32(p->buf) < 8)

This check must be wrong, because you already know that the left side
here is ALP_TAG. Did you mean AV_RL32(p->buf + 4)? If so, you should
explicitly check for it being 8 or 12 (because otherwise the demuxer
would just return AVERROR_INVALIDDATA).

And why haven't you added a check based upon the "ADPCM" magic word?

> +return 0;
> +
> +return AVPROBE_SCORE_EXTENSION + 1;
> +}
> +
> +static int alp_read_header(AVFormatContext *s)
> +{
> +int ret;
> +AVStream *st;
> +ALPHeader hdr;
> +AVCodecParameters *par;
> +
> +memset(&hdr, 0, sizeof(hdr));

You actually set every field you use before you use it, so this is
unnecessary.

> +
> +if (!(st = avformat_new_stream(s, NULL)))

This could be moved down below so that you avoid allocating an
AVStream if you error out later.

> +return AVERROR(ENOMEM);
> +
> +if ((hdr.magic = avio_rl32(s->pb)) != ALP_TAG)
> +return AVERROR_INVALIDDATA;
> +
> +hdr.header_size = avio_rl32(s->pb);
> +
> +if (hdr.header_size != 8 && hdr.header_size != 12) {
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if ((ret = avio_read(s->pb, hdr.adpcm, sizeof(hdr.adpcm))) < 0)
> +return ret;
> +else if (ret != sizeof(hdr.adpcm))
> +return AVERROR(EIO);
> +
> +if (strncmp("ADPCM", hdr.adpcm, sizeof(hdr.adpcm)) != 0)
> +return AVERROR_INVALIDDATA;
> +
> +hdr.unk1= avio_r8(s->pb);
> +hdr.num_channels= avio_r8(s->pb);
> +
> +if (hdr.header_size == 8) {
> +/* .TUN music file */
> +hd

Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2 support

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Thursday, March 5, 2020 08:25
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> support
> 
> ---
> With , intra-only 4:2:2
> encode works on Ice Lake with something like:
> 
>  -vf 'format=yuyv422,hwupload' -c:v hevc_vaapi -g 1 out.mp4
> 
> There is still something wrong with inter frames.

The possible reason is media-driver for gen11 (ice lake) lacks the capability
query support for VAProfileHEVCMain422_10. With [1] applied in driver,
the encoding for yuyv422 works well for me, for both intra and inter frames.

Ps.
In case you may be interested, I prepared several patches [2] for 4:2:2/4:4: 
8/10 bit encoding.

They works for me with correct outputs. And the reason for not upstreaming is:
1. 444 pixel format not ready;
2. recon surface of Y210 or 444 (AYUV and Y410 in media-driver) depends on the 
surface hint [3] in
libva and corresponding code in media-driver to resize the recon surface which 
is not upstreamed
yet.

[1] https://github.com/intel/media-driver/pull/855/files
[2] 
https://github.com/fulinjie/ffmpeg/commit/dfb153fa68029f2a4060bcfd8bf500fd8ee44254
[3] https://github.com/intel/libva/pull/344

- Linjie




___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/4] avformat: add demuxer for LEGO Racers' ALP format

[Zane van Iperen]

On Thu, 5 Mar 2020 02:26:38 +0100
"Andreas Rheinhardt"  wrote:

> Am 05.03.2020 um 01:40 schrieb Zane van Iperen:
> > Signed-off-by: Zane van Iperen 
> > ---
> >  libavformat/Makefile |   1 +
> >  libavformat/allformats.c |   1 +
> >  libavformat/alp.c| 135
> > +++ libavformat/version.h
> > |   4 +- 4 files changed, 139 insertions(+), 2 deletions(-)
> >  create mode 100644 libavformat/alp.c
> >
> > diff --git a/libavformat/Makefile b/libavformat/Makefile
> > index e0681058a2..fbb29505ff 100644
> > --- a/libavformat/Makefile
> > +++ b/libavformat/Makefile
> > @@ -85,6 +85,7 @@ OBJS-$(CONFIG_AIFF_DEMUXER)  +=
> > aiffdec.o pcm.o isom.o \ mov_chan.o replaygain.o
> >  OBJS-$(CONFIG_AIFF_MUXER)+= aiffenc.o id3v2enc.o
> >  OBJS-$(CONFIG_AIX_DEMUXER)   += aixdec.o
> > +OBJS-$(CONFIG_ALP_DEMUXER)   += alp.o
> >  OBJS-$(CONFIG_AMR_DEMUXER)   += amr.o
> >  OBJS-$(CONFIG_AMR_MUXER) += amr.o
> >  OBJS-$(CONFIG_AMRNB_DEMUXER) += amr.o
> > diff --git a/libavformat/allformats.c b/libavformat/allformats.c
> > index 0209bf0e30..08012ea208 100644
> > --- a/libavformat/allformats.c
> > +++ b/libavformat/allformats.c
> > @@ -46,6 +46,7 @@ extern AVInputFormat  ff_afc_demuxer;
> >  extern AVInputFormat  ff_aiff_demuxer;
> >  extern AVOutputFormat ff_aiff_muxer;
> >  extern AVInputFormat  ff_aix_demuxer;
> > +extern AVInputFormat  ff_alp_demuxer;
> >  extern AVInputFormat  ff_amr_demuxer;
> >  extern AVOutputFormat ff_amr_muxer;
> >  extern AVInputFormat  ff_amrnb_demuxer;
> > diff --git a/libavformat/alp.c b/libavformat/alp.c
> > new file mode 100644
> > index 00..76703e7ad1
> > --- /dev/null
> > +++ b/libavformat/alp.c
> > @@ -0,0 +1,135 @@
> > +/*
> > + * LEGO Racers ALP (.tun & .pcm) demuxer
> > + *
> > + * Copyright (C) 2020 Zane van Iperen (z...@zanevaniperen.com)
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later
> > version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > 02110-1301 USA
> > + */
> > +#include "avformat.h"
> > +#include "internal.h"
> > +#include "libavutil/intreadwrite.h"
> > +
> > +#define ALP_TAGMKTAG('A', 'L', 'P', ' ')
> > +#define ALP_MAX_READ_SIZE  4096
> > +
> > +typedef struct ALPHeader {
> > +uint32_tmagic;  /*< Magic Number, {'A', 'L', 'P',
> > ' '} */
> > +uint32_theader_size;/*< Header size (after this). */
> > +charadpcm[6];   /*< "ADPCM" */
> > +uint8_t unk1;   /*< Unknown */
> > +uint8_t num_channels;   /*< Channel Count. */
> > +uint32_tsample_rate;/*< Sample rate, only if
> > header_size >= 12. */ +} ALPHeader;
> > +
> > +static int alp_probe(const AVProbeData *p)
> > +{
> > +if (AV_RL32(p->buf) != ALP_TAG)
> > +return 0;
> > +
> > +if (AV_RL32(p->buf) < 8)  
> 
> This check must be wrong, because you already know that the left side
> here is ALP_TAG. Did you mean AV_RL32(p->buf + 4)? If so, you should
> explicitly check for it being 8 or 12 (because otherwise the demuxer
> would just return AVERROR_INVALIDDATA).

Yep, I meant +4. Fixed.

>
> And why haven't you added a check based upon the "ADPCM" magic word?
>

...That is a good question, my bad.

> > +return 0;
> > +
> > +return AVPROBE_SCORE_EXTENSION + 1;
> > +}
> > +
> > +static int alp_read_header(AVFormatContext *s)
> > +{
> > +int ret;
> > +AVStream *st;
> > +ALPHeader hdr;
> > +AVCodecParameters *par;
> > +
> > +memset(&hdr, 0, sizeof(hdr));  
> 
> You actually set every field you use before you use it, so this is
> unnecessary.
> 

Better safe then sorry. I've removed it.

> > +
> > +if (!(st = avformat_new_stream(s, NULL)))  
> 
> This could be moved down below so that you avoid allocating an
> AVStream if you error out later.
> 

Done.

> > +return AVERROR(ENOMEM);
> > +
> > +if ((hdr.magic = avio_rl32(s->pb)) != ALP_TAG)
> > +return AVERROR_INVALIDDATA;
> > +
> > +hdr.header_size = avio_rl32(s->pb);
> > +
> > +if (hdr.header_size != 8 && hdr.header_size != 12) {
> > +return AVERROR_INVALIDDATA;
> > +}
> > +
> > +if ((ret = avio_read(s->pb, hdr.adpcm, sizeof(hdr.adpcm))) < 0)
> > +   

[FFmpeg-devel] [PATCH] avcodec/avcodec: Fix typos

[Andriy Gelman]

From: Andriy Gelman 

Signed-off-by: Andriy Gelman 
---
 libavcodec/avcodec.h | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5a0fc3405c5..8cda2422efa 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -5037,7 +5037,7 @@ int avcodec_receive_frame(AVCodecContext *avctx, AVFrame 
*frame);
  *  AVERROR(EINVAL):   codec not opened, refcounted_frames not set, it is a
  * decoder, or requires flush
  *  AVERROR(ENOMEM):   failed to add packet to internal queue, or similar
- *  other errors: legitimate decoding errors
+ *  other errors: legitimate encoding errors
  */
 int avcodec_send_frame(AVCodecContext *avctx, const AVFrame *frame);
 
@@ -5053,8 +5053,8 @@ int avcodec_send_frame(AVCodecContext *avctx, const 
AVFrame *frame);
  * must try to send input
  *  AVERROR_EOF:   the encoder has been fully flushed, and there will 
be
  * no more output packets
- *  AVERROR(EINVAL):   codec not opened, or it is an encoder
- *  other errors: legitimate decoding errors
+ *  AVERROR(EINVAL):   codec not opened, or it is a decoder
+ *  other errors: legitimate encoding errors
  */
 int avcodec_receive_packet(AVCodecContext *avctx, AVPacket *avpkt);
 
-- 
2.25.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 3/4] vaapi_encode_h265: Query encoding block sizes and features

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Thursday, March 5, 2020 08:25
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH 3/4] vaapi_encode_h265: Query encoding
> block sizes and features
> 
> ---
> Requires .  That isn't upstream, so
> this will need to wait for that and then get at least a fix to the version
> numbering before applying.

The query looks good to me since I'm suffering from the differences of default
parameters allowed for VDENC and VMEPAK in media-driver while adding support
for low power encoding [1] for VAAPI. 

However got several questions:

1. Why not include PPS parameters as well? There are some differences in
cu_qp_delta_enabled_flag and diff_cu_qp_delta_depth supported for 
VAEntrypointEncSliceLP.

2. Would it be better to only involve the variable parameters for sps/pps... ? 
This is 
what PR 379 [2] (unfinished) intended to do.

3. The suggested value of SAO enable flag could also be 1 in corresponding code 
in
media-driver, which would provide 3% BD-Rate improvement with no fps penalty
based on previous experiment with FFmpeg VAAPI.

4. There is separate media_libva_caps for gen11 and gen12, maybe need further 
update
or centralization for the code in driver. (not tested yet, will do later)

[1] 
https://github.com/intel-media-ci/ffmpeg-cartwheel/blob/master/patchset/0008-lavc-vaapi_encode_h265-add-support-for-low-power-mod.patch
[2] https://github.com/intel/libva/pull/379

- Linjie

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH, v2 1/4] tests/checkasm: add overflow test for hevc_add_res

[Linjie Fu]

Add overflow test for hevc_add_res when int16_t coeff = -32768,
and doubled the test cases.

The result of C is good, while ASM is not.

To verify:
make fate-checkasm-hevc_add_res
ffmpeg/tests/checkasm/checkasm --test=hevc_add_res

./checkasm --test=hevc_add_res
checkasm: using random seed 679391863
MMXEXT:
hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
SSE2:
hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX:
hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX2:
hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
checkasm: 8 of 14 tests have failed

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
[v2]: test 2x cases to make sure the random residuals
could be testd.

 tests/checkasm/hevc_add_res.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/checkasm/hevc_add_res.c b/tests/checkasm/hevc_add_res.c
index e92c6b4..8c82ac1 100644
--- a/tests/checkasm/hevc_add_res.c
+++ b/tests/checkasm/hevc_add_res.c
@@ -58,6 +58,7 @@ static void check_add_res(HEVCDSPContext h, int bit_depth)
 
 randomize_buffers(res0, size);
 randomize_buffers2(dst0, size);
+res0[0] = 0x8000;// overflow test
 memcpy(res1, res0, sizeof(*res0) * size);
 memcpy(dst1, dst0, sizeof(int16_t) * size);
 
@@ -80,6 +81,7 @@ void checkasm_check_hevc_add_res(void)
 
 ff_hevc_dsp_init(&h, bit_depth);
 check_add_res(h, bit_depth);
+check_add_res(h, bit_depth);
 }
 report("add_residual");
 }
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_MMX_4_8

[Linjie Fu]

Fix overflow for coeff -32768 in function ADD_RES_MMX_4_8 with no
performance drop.

./checkasm --test=hevc_add_res --bench

Mainline:
  - hevc_add_res.add_residual [OK]
hevc_add_res_4x4_8_mmxext: 15.5

Add overflow test case:
  - hevc_add_res.add_residual [FAILED]

After:
  - hevc_add_res.add_residual [OK]
hevc_add_res_4x4_8_mmxext: 15.0

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
 libavcodec/x86/hevc_add_res.asm | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm
index 36d4d8e..249c607 100644
--- a/libavcodec/x86/hevc_add_res.asm
+++ b/libavcodec/x86/hevc_add_res.asm
@@ -30,27 +30,26 @@ cextern pw_1023
 %macro ADD_RES_MMX_4_8 0
 mova  m0, [r1]
 mova  m2, [r1+8]
-pxor  m1, m1
-pxor  m3, m3
-psubw m1, m0
-psubw m3, m2
-packuswb  m0, m2
-packuswb  m1, m3
 
-movd  m2, [r0]
+movd  m1, [r0]
 movd  m3, [r0+r2]
-punpckldq m2, m3
-paddusb   m0, m2
-psubusb   m0, m1
+punpcklbw m1, m4
+punpcklbw m3, m4
+
+paddswm0, m1
+paddswm2, m3
+packuswb  m0, m4
+packuswb  m2, m4
+
 movd[r0], m0
-psrlq m0, 32
-movd [r0+r2], m0
+movd [r0+r2], m2
 %endmacro
 
 
 INIT_MMX mmxext
 ; void ff_hevc_add_residual_4_8_mmxext(uint8_t *dst, int16_t *res, ptrdiff_t 
stride)
 cglobal hevc_add_residual_4_8, 3, 3, 6
+pxor  m4, m4
 ADD_RES_MMX_4_8
 add   r1, 16
 lea   r0, [r0+r2*2]
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_SSE_8_8

[Linjie Fu]

Fix overflow for coeff -32768 in function ADD_RES_SSE_8_8 with
no performance drop.

./checkasm --test=hevc_add_res --bench

Mainline:
  - hevc_add_res.add_residual [OK]
hevc_add_res_8x8_8_sse2: 15.5

Add overflow test case:
  - hevc_add_res.add_residual [FAILED]

After:
  - hevc_add_res.add_residual [OK]
hevc_add_res_8x8_8_sse2: 15.5

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
 libavcodec/x86/hevc_add_res.asm | 45 -
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm
index 249c607..e5e9f24 100644
--- a/libavcodec/x86/hevc_add_res.asm
+++ b/libavcodec/x86/hevc_add_res.asm
@@ -57,32 +57,30 @@ cglobal hevc_add_residual_4_8, 3, 3, 6
 RET
 
 %macro ADD_RES_SSE_8_8 0
-pxor  m3, m3
-mova  m4, [r1]
-mova  m6, [r1+16]
-mova  m0, [r1+32]
-mova  m2, [r1+48]
-psubw m5, m3, m4
-psubw m7, m3, m6
-psubw m1, m3, m0
-packuswb  m4, m0
-packuswb  m5, m1
-psubw m3, m2
-packuswb  m6, m2
-packuswb  m7, m3
-
 movq  m0, [r0]
 movq  m1, [r0+r2]
-movhpsm0, [r0+r2*2]
-movhpsm1, [r0+r3]
-paddusb   m0, m4
-paddusb   m1, m6
-psubusb   m0, m5
-psubusb   m1, m7
+punpcklbw m0, m4
+punpcklbw m1, m4
+mova  m2, [r1]
+mova  m3, [r1+16]
+paddswm0, m2
+paddswm1, m3
+packuswb  m0, m1
+
+movq  m2, [r0+r2*2]
+movq  m3, [r0+r3]
+punpcklbw m2, m4
+punpcklbw m3, m4
+mova  m6, [r1+32]
+mova  m7, [r1+48]
+paddswm2, m6
+paddswm3, m7
+packuswb  m2, m3
+
 movq[r0], m0
-movq [r0+r2], m1
-movhps [r0+2*r2], m0
-movhps   [r0+r3], m1
+movhps   [r0+r2], m0
+movq   [r0+r2*2], m2
+movhps   [r0+r3], m2
 %endmacro
 
 %macro ADD_RES_SSE_16_32_8 3
@@ -120,6 +118,7 @@ cglobal hevc_add_residual_4_8, 3, 3, 6
 %macro TRANSFORM_ADD_8 0
 ; void ff_hevc_add_residual_8_8_(uint8_t *dst, int16_t *res, ptrdiff_t 
stride)
 cglobal hevc_add_residual_8_8, 3, 4, 8
+pxor  m4, m4
 lea   r3, [r2*3]
 ADD_RES_SSE_8_8
 add   r1, 64
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH, v2 1/4] tests/checkasm: add overflow test for hevc_add_res

[Fu, Linjie]

> -Original Message-
> From: Fu, Linjie 
> Sent: Thursday, March 5, 2020 15:17
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie ; Xu, Guangxin 
> Subject: [PATCH,v2 1/4] tests/checkasm: add overflow test for hevc_add_res
> 
> Add overflow test for hevc_add_res when int16_t coeff = -32768,
> and doubled the test cases.
> 
> The result of C is good, while ASM is not.
> 
> To verify:
> make fate-checkasm-hevc_add_res
> ffmpeg/tests/checkasm/checkasm --test=hevc_add_res
> 
> ./checkasm --test=hevc_add_res
> checkasm: using random seed 679391863
> MMXEXT:
> hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
>   - hevc_add_res.add_residual [FAILED]
> SSE2:
> hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
> hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
> hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
>   - hevc_add_res.add_residual [FAILED]
> AVX:
> hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
> hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
> hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
>   - hevc_add_res.add_residual [FAILED]
> AVX2:
> hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
>   - hevc_add_res.add_residual [FAILED]
> checkasm: 8 of 14 tests have failed
> 
> Signed-off-by: Xu Guangxin 
> Signed-off-by: Linjie Fu 
> ---
> [v2]: test 2x cases to make sure the random residuals
> could be testd.
> 

This modification in fate should be put after the fix patch(2~4),
Otherwise it would break fate test in CI.

I'll resend the set, sorry for the noise.

- Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH, RFC] lavc/vaapi_encode_h265: add support for low power mode for HEVC encode

[Linjie Fu]

Enable hevc_vaapi vdenc:
- media-driver require CTU size must be set as 64x64 at low power mode
- cu_qp_delta_enabled_flag should be enabled for low power mode
- diff_cu_qp_delta_depth == log2_diff_max_min_luma_coding_block_size
- low delay B to replace P frame
- same ref_pic_list0/ref_pic_list1

Signed-off-by: Linjie Fu 
---
This should be rebased after the encoding query is supported in [1] and
low delay B support [2] for HEVC in media driver.

Sent out and request for comments.

[1] 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200305002528.11418-3...@jkqxz.net/
[2] 
https://github.com/intel/libva/commit/f094de317b4f498b57d47d8b0823a2a24cb125e1

 libavcodec/vaapi_encode_h265.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 538862a..12f0e6f 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -437,9 +437,12 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 // These have to come from the capabilities of the encoder.  We have no
 // way to query them, so just hardcode parameters which work on the Intel
 // driver.
-// CTB size from 8x8 to 32x32.
+// CTB size from 8x8 to 32x32. (64x64 when using low power mode for hw 
limitation)
 sps->log2_min_luma_coding_block_size_minus3   = 0;
-sps->log2_diff_max_min_luma_coding_block_size = 2;
+if (ctx->low_power)
+sps->log2_diff_max_min_luma_coding_block_size = 3;
+else
+sps->log2_diff_max_min_luma_coding_block_size = 2;
 // Transform size from 4x4 to 32x32.
 sps->log2_min_luma_transform_block_size_minus2   = 0;
 sps->log2_diff_max_min_luma_transform_block_size = 3;
@@ -553,8 +556,10 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 
 pps->init_qp_minus26 = priv->fixed_qp_idr - 26;
 
-pps->cu_qp_delta_enabled_flag = (ctx->va_rc_mode != VA_RC_CQP);
-pps->diff_cu_qp_delta_depth   = 0;
+// driver requires enablement of cu_qp_delta_enabled_flag for low power 
mode encoding
+pps->cu_qp_delta_enabled_flag = (ctx->va_rc_mode != VA_RC_CQP || 
ctx->low_power);
+pps->diff_cu_qp_delta_depth   = pps->cu_qp_delta_enabled_flag && 
ctx->low_power ?
+
sps->log2_diff_max_min_luma_coding_block_size : 0;
 
 pps->pps_loop_filter_across_slices_enabled_flag = 1;
 
@@ -873,6 +878,7 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
VAAPIEncodeSlice *slice)
 {
 VAAPIEncodeH265Context   *priv = avctx->priv_data;
+VAAPIEncodeContext*ctx = avctx->priv_data;
 VAAPIEncodeH265Picture   *hpic = pic->priv_data;
 const H265RawSPS  *sps = &priv->raw_sps;
 const H265RawPPS  *pps = &priv->raw_pps;
@@ -893,6 +899,9 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 sh->slice_segment_address   = slice->block_start;
 
 sh->slice_type = hpic->slice_type;
+// driver requires low delay B frame in low power mode
+if (sh->slice_type == HEVC_SLICE_P && ctx->low_power)
+sh->slice_type = HEVC_SLICE_B;
 
 sh->slice_pic_order_cnt_lsb = hpic->pic_order_cnt &
 (1 << (sps->log2_max_pic_order_cnt_lsb_minus4 + 4)) - 1;
@@ -1059,6 +1068,16 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 vslice->ref_pic_list1[0] = vpic->reference_frames[1];
 }
 
+// Driver requires low delay B frame and matched ref_pic_list0/1[]
+// for low power mode
+if (pic->type == PICTURE_TYPE_P && ctx->low_power) {
+vslice->slice_type = HEVC_SLICE_B;
+for (i = 0; i < FF_ARRAY_ELEMS(vslice->ref_pic_list0); i++) {
+vslice->ref_pic_list1[i].picture_id = 
vslice->ref_pic_list0[i].picture_id;
+vslice->ref_pic_list1[i].flags  = 
vslice->ref_pic_list0[i].flags;
+}
+}
+
 return 0;
 }
 
@@ -1175,8 +1194,11 @@ static av_cold int vaapi_encode_h265_init(AVCodecContext 
*avctx)
 ctx->surface_width  = FFALIGN(avctx->width,  16);
 ctx->surface_height = FFALIGN(avctx->height, 16);
 
-// CTU size is currently hard-coded to 32.
-ctx->slice_block_width = ctx->slice_block_height = 32;
+// CTU size is currently hard-coded to 32. (64 x 64 when using low power 
mode)
+if (ctx->low_power)
+ctx->slice_block_width = ctx->slice_block_height = 64;
+else
+ctx->slice_block_width = ctx->slice_block_height = 32;
 
 if (priv->qp > 0)
 ctx->explicit_qp = priv->qp;
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: fix conf_win_xxx_offset for 4:2:2/4:4:4 encoding

[Linjie Fu]

Based on Table 6-1, set SubWidth and SubHeightC depending on chroma format.

Based on D-28 and D-29, set the correct cropped width/height.

croppedWidth  = pic_width_in_luma_samples −
SubWidthC * ( conf_win_right_offset + conf_win_left_offset );

croppedHeight = pic_height_in_luma_samples −
SubHeightC * ( conf_win_bottom_offset + conf_win_top_offset );

Signed-off-by: Linjie Fu 
---
 libavcodec/vaapi_encode_h265.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 12f0e6f..db1bf24 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -268,6 +268,7 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 VAEncPictureParameterBufferHEVC  *vpic = ctx->codec_picture_params;
 const AVPixFmtDescriptor *desc;
 int chroma_format, bit_depth;
+int SubWidthC, SubHeightC;
 int i;
 
 memset(vps, 0, sizeof(*vps));
@@ -405,15 +406,19 @@ static int 
vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
 sps->pic_width_in_luma_samples  = ctx->surface_width;
 sps->pic_height_in_luma_samples = ctx->surface_height;
 
+// Table 6-1
+SubWidthC  = chroma_format == 1 || chroma_format == 2 ? 2 : 1;
+SubHeightC = chroma_format == 1 ? 2 : 1;
+
 if (avctx->width  != ctx->surface_width ||
 avctx->height != ctx->surface_height) {
 sps->conformance_window_flag = 1;
 sps->conf_win_left_offset   = 0;
 sps->conf_win_right_offset  =
-(ctx->surface_width - avctx->width) / 2;
+(ctx->surface_width - avctx->width) / SubWidthC;
 sps->conf_win_top_offset= 0;
 sps->conf_win_bottom_offset =
-(ctx->surface_height - avctx->height) / 2;
+(ctx->surface_height - avctx->height) / SubHeightC;
 } else {
 sps->conformance_window_flag = 0;
 }
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/vaapi_encode_h265: add encoding support for 4:2:2 10 bit

[Linjie Fu]

Enables VMEPAK encoding on ICL.

Signed-off-by: Linjie Fu 
---
Needs support [1] in media driver to get it work correctly.

With [2] supported in libva, setting VA_SURFACE_ATTRIB_USAGE_HINT_RECON to
the recon surface and resize them in driver would be more robust in ffmpeg
level.

[1] https://github.com/intel/media-driver/pull/855
[2] https://github.com/intel/libva/pull/344

 libavcodec/vaapi_encode.c  | 12 ++--
 libavcodec/vaapi_encode_h265.c |  3 +++
 2 files changed, 13 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8ff720e..ad0414f 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1191,6 +1191,9 @@ static const VAAPIEncodeRTFormat 
vaapi_encode_rt_formats[] = {
 #if VA_CHECK_VERSION(0, 38, 1)
 { "YUV420_10", VA_RT_FORMAT_YUV420_10BPP, 10, 3, 1, 1 },
 #endif
+#if VA_CHECK_VERSION(1, 2, 0)
+{ "YUV422_10", VA_RT_FORMAT_YUV422_10,10, 3, 1, 0 },
+#endif
 };
 
 static const VAEntrypoint vaapi_encode_entrypoints_normal[] = {
@@ -2185,8 +2188,13 @@ static av_cold int 
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
 
 ctx->recon_frames->format= AV_PIX_FMT_VAAPI;
 ctx->recon_frames->sw_format = recon_format;
-ctx->recon_frames->width = ctx->surface_width;
-ctx->recon_frames->height= ctx->surface_height;
+if (recon_format == AV_PIX_FMT_Y210) {
+ctx->recon_frames->width = ctx->surface_width / 2;
+ctx->recon_frames->height= ctx->surface_height * 2;
+} else {
+ctx->recon_frames->width = ctx->surface_width;
+ctx->recon_frames->height= ctx->surface_height;
+}
 
 err = av_hwframe_ctx_init(ctx->recon_frames_ref);
 if (err < 0) {
diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index db1bf24..4ba9fef 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -1138,6 +1138,9 @@ static const VAAPIEncodeProfile 
vaapi_encode_h265_profiles[] = {
 { FF_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1, VAProfileHEVCMain10 },
 { FF_PROFILE_HEVC_REXT,10, 3, 1, 1, VAProfileHEVCMain10 },
 #endif
+#if VA_CHECK_VERSION(1, 2, 0)
+{ FF_PROFILE_HEVC_REXT,10, 3, 1, 0, VAProfileHEVCMain422_10 },
+#endif
 { FF_PROFILE_UNKNOWN }
 };
 
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_MMX_4_8

[Linjie Fu]

Fix overflow for coeff -32768 in function ADD_RES_MMX_4_8 with no
performance drop.

./checkasm --test=hevc_add_res --bench

Mainline:
  - hevc_add_res.add_residual [OK]
hevc_add_res_4x4_8_mmxext: 15.5

Add overflow test case:
  - hevc_add_res.add_residual [FAILED]

After:
  - hevc_add_res.add_residual [OK]
hevc_add_res_4x4_8_mmxext: 15.0

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
 libavcodec/x86/hevc_add_res.asm | 23 +++
 1 file changed, 11 insertions(+), 12 deletions(-)

diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm
index 36d4d8e..249c607 100644
--- a/libavcodec/x86/hevc_add_res.asm
+++ b/libavcodec/x86/hevc_add_res.asm
@@ -30,27 +30,26 @@ cextern pw_1023
 %macro ADD_RES_MMX_4_8 0
 mova  m0, [r1]
 mova  m2, [r1+8]
-pxor  m1, m1
-pxor  m3, m3
-psubw m1, m0
-psubw m3, m2
-packuswb  m0, m2
-packuswb  m1, m3
 
-movd  m2, [r0]
+movd  m1, [r0]
 movd  m3, [r0+r2]
-punpckldq m2, m3
-paddusb   m0, m2
-psubusb   m0, m1
+punpcklbw m1, m4
+punpcklbw m3, m4
+
+paddswm0, m1
+paddswm2, m3
+packuswb  m0, m4
+packuswb  m2, m4
+
 movd[r0], m0
-psrlq m0, 32
-movd [r0+r2], m0
+movd [r0+r2], m2
 %endmacro
 
 
 INIT_MMX mmxext
 ; void ff_hevc_add_residual_4_8_mmxext(uint8_t *dst, int16_t *res, ptrdiff_t 
stride)
 cglobal hevc_add_residual_4_8, 3, 3, 6
+pxor  m4, m4
 ADD_RES_MMX_4_8
 add   r1, 16
 lea   r0, [r0+r2*2]
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/4] lavc/x86/hevc_add_res: Fix overflow in ADD_RES_SSE_8_8

[Linjie Fu]

Fix overflow for coeff -32768 in function ADD_RES_SSE_8_8 with
no performance drop.

./checkasm --test=hevc_add_res --bench

Mainline:
  - hevc_add_res.add_residual [OK]
hevc_add_res_8x8_8_sse2: 15.5

Add overflow test case:
  - hevc_add_res.add_residual [FAILED]

After:
  - hevc_add_res.add_residual [OK]
hevc_add_res_8x8_8_sse2: 15.5

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
 libavcodec/x86/hevc_add_res.asm | 45 -
 1 file changed, 22 insertions(+), 23 deletions(-)

diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm
index 249c607..e5e9f24 100644
--- a/libavcodec/x86/hevc_add_res.asm
+++ b/libavcodec/x86/hevc_add_res.asm
@@ -57,32 +57,30 @@ cglobal hevc_add_residual_4_8, 3, 3, 6
 RET
 
 %macro ADD_RES_SSE_8_8 0
-pxor  m3, m3
-mova  m4, [r1]
-mova  m6, [r1+16]
-mova  m0, [r1+32]
-mova  m2, [r1+48]
-psubw m5, m3, m4
-psubw m7, m3, m6
-psubw m1, m3, m0
-packuswb  m4, m0
-packuswb  m5, m1
-psubw m3, m2
-packuswb  m6, m2
-packuswb  m7, m3
-
 movq  m0, [r0]
 movq  m1, [r0+r2]
-movhpsm0, [r0+r2*2]
-movhpsm1, [r0+r3]
-paddusb   m0, m4
-paddusb   m1, m6
-psubusb   m0, m5
-psubusb   m1, m7
+punpcklbw m0, m4
+punpcklbw m1, m4
+mova  m2, [r1]
+mova  m3, [r1+16]
+paddswm0, m2
+paddswm1, m3
+packuswb  m0, m1
+
+movq  m2, [r0+r2*2]
+movq  m3, [r0+r3]
+punpcklbw m2, m4
+punpcklbw m3, m4
+mova  m6, [r1+32]
+mova  m7, [r1+48]
+paddswm2, m6
+paddswm3, m7
+packuswb  m2, m3
+
 movq[r0], m0
-movq [r0+r2], m1
-movhps [r0+2*r2], m0
-movhps   [r0+r3], m1
+movhps   [r0+r2], m0
+movq   [r0+r2*2], m2
+movhps   [r0+r3], m2
 %endmacro
 
 %macro ADD_RES_SSE_16_32_8 3
@@ -120,6 +118,7 @@ cglobal hevc_add_residual_4_8, 3, 3, 6
 %macro TRANSFORM_ADD_8 0
 ; void ff_hevc_add_residual_8_8_(uint8_t *dst, int16_t *res, ptrdiff_t 
stride)
 cglobal hevc_add_residual_8_8, 3, 4, 8
+pxor  m4, m4
 lea   r3, [r2*3]
 ADD_RES_SSE_8_8
 add   r1, 64
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH, v2 4/4] tests/checkasm: add overflow test for hevc_add_res

[Linjie Fu]

Add overflow test for hevc_add_res when int16_t coeff = -32768,
and doubled the test cases.

The result of C is good, while ASM is not.

To verify:
make fate-checkasm-hevc_add_res
ffmpeg/tests/checkasm/checkasm --test=hevc_add_res

./checkasm --test=hevc_add_res
checkasm: using random seed 679391863
MMXEXT:
hevc_add_res_4x4_8_mmxext (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
SSE2:
hevc_add_res_8x8_8_sse2 (hevc_add_res.c:69)
hevc_add_res_16x16_8_sse2 (hevc_add_res.c:69)
hevc_add_res_32x32_8_sse2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX:
hevc_add_res_8x8_8_avx (hevc_add_res.c:69)
hevc_add_res_16x16_8_avx (hevc_add_res.c:69)
hevc_add_res_32x32_8_avx (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
AVX2:
hevc_add_res_32x32_8_avx2 (hevc_add_res.c:69)
  - hevc_add_res.add_residual [FAILED]
checkasm: 8 of 14 tests have failed

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
[v2]: test 2x cases to make sure enough random residuals
are tested.

 tests/checkasm/hevc_add_res.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tests/checkasm/hevc_add_res.c b/tests/checkasm/hevc_add_res.c
index e92c6b4..8c82ac1 100644
--- a/tests/checkasm/hevc_add_res.c
+++ b/tests/checkasm/hevc_add_res.c
@@ -58,6 +58,7 @@ static void check_add_res(HEVCDSPContext h, int bit_depth)
 
 randomize_buffers(res0, size);
 randomize_buffers2(dst0, size);
+res0[0] = 0x8000;// overflow test
 memcpy(res1, res0, sizeof(*res0) * size);
 memcpy(dst1, dst0, sizeof(int16_t) * size);
 
@@ -80,6 +81,7 @@ void checkasm_check_hevc_add_res(void)
 
 ff_hevc_dsp_init(&h, bit_depth);
 check_add_res(h, bit_depth);
+check_add_res(h, bit_depth);
 }
 report("add_residual");
 }
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH, v2 3/4] lavc/x86/hevc_add_res: Fix coeff overflow in ADD_RES_SSE_16_32_8

[Linjie Fu]

Fix overflow for coeff -32768 in function ADD_RES_SSE_16_32_8 with no
performance drop.(SSE2/AVX/AVX2)

./checkasm --test=hevc_add_res --bench

Mainline:
  - hevc_add_res.add_residual [OK]
hevc_add_res_32x32_8_sse2: 127.5
hevc_add_res_32x32_8_avx: 127.0
hevc_add_res_32x32_8_avx2: 86.5

Add overflow test case:
  - hevc_add_res.add_residual [FAILED]

After:
  - hevc_add_res.add_residual [OK]
hevc_add_res_32x32_8_sse2: 126.8
hevc_add_res_32x32_8_avx: 128.3
hevc_add_res_32x32_8_avx2: 86.8

Signed-off-by: Xu Guangxin 
Signed-off-by: Linjie Fu 
---
[v2]: fix some indentations

 libavcodec/x86/hevc_add_res.asm | 40 +---
 1 file changed, 21 insertions(+), 19 deletions(-)

diff --git a/libavcodec/x86/hevc_add_res.asm b/libavcodec/x86/hevc_add_res.asm
index e5e9f24..c6c4007 100644
--- a/libavcodec/x86/hevc_add_res.asm
+++ b/libavcodec/x86/hevc_add_res.asm
@@ -84,34 +84,36 @@ cglobal hevc_add_residual_4_8, 3, 3, 6
 %endmacro
 
 %macro ADD_RES_SSE_16_32_8 3
-mova xm2, [r1+%1]
+mova  m1, [%2]
+mova  m2, m1
+punpcklbw m1, m0
+punpckhbw m2, m0
+mova xm5, [r1+%1]
 mova xm6, [r1+%1+16]
 %if cpuflag(avx2)
-vinserti128   m2, m2, [r1+%1+32], 1
+vinserti128   m5, m5, [r1+%1+32], 1
 vinserti128   m6, m6, [r1+%1+48], 1
 %endif
-psubw m1, m0, m2
-psubw m5, m0, m6
-packuswb  m2, m6
-packuswb  m1, m5
+paddswm1, m5
+paddswm2, m6
 
-mova xm4, [r1+%1+mmsize*2]
+mova  m3, [%3]
+mova  m4, m3
+punpcklbw m3, m0
+punpckhbw m4, m0
+mova xm5, [r1+%1+mmsize*2]
 mova xm6, [r1+%1+mmsize*2+16]
 %if cpuflag(avx2)
-vinserti128   m4, m4, [r1+%1+96 ], 1
+vinserti128   m5, m5, [r1+%1+96], 1
 vinserti128   m6, m6, [r1+%1+112], 1
 %endif
-psubw m3, m0, m4
-psubw m5, m0, m6
-packuswb  m4, m6
-packuswb  m3, m5
-
-paddusb   m2, [%2]
-paddusb   m4, [%3]
-psubusb   m2, m1
-psubusb   m4, m3
-mova[%2], m2
-mova[%3], m4
+paddswm3, m5
+paddswm4, m6
+
+packuswb  m1, m2
+packuswb  m3, m4
+mova[%2], m1
+mova[%3], m3
 %endmacro
 
 
-- 
2.7.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".