[FFmpeg-devel] [PATCH] lavf/mpegtsdec: fix AVPacket.pos when FEC/DVHS/BDAV data is present

[Rodger Combs]

We previously set pos to several bytes before the actual packet sync byte,
which meant that seeking to pos relied on resync working, which can fail
if there are 0x47 bytes in the additional data.

The resync issue should probably also be fixed separately.
---
 libavformat/mpegts.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index a5cb17ac16..881708b42d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2581,10 +2581,9 @@ static int handle_packet(MpegTSContext *ts, const 
uint8_t *packet)
 
 } else {
 int ret;
-// Note: The position here points actually behind the current packet.
 if (tss->type == MPEGTS_PES) {
 if ((ret = tss->u.pes_filter.pes_cb(tss, p, p_end - p, is_start,
-pos - ts->raw_packet_size)) < 
0)
+pos - TS_PACKET_SIZE)) < 0)
 return ret;
 }
 }
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files

[Gyan Doshi]

On 31-08-2018 09:57 AM, Gyan Doshi wrote:

On 31-08-2018 04:28 AM, Marton Balint wrote:



Is there any real use case when same source and destination works, so 
the option can be used?


If not, then just make ffmpeg fail, like the cp command fails for same 
source and destination. I am against adding an option if it has no 
known use.


Via the file protocol, not that I know of. Will remove.

Gyan


Revised patch attached.
From 1422de3eecb921201727e90306edbe1ff6f26947 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Sun, 26 Aug 2018 11:22:50 +0530
Subject: [PATCH v2] ffmpeg: block output == input for files

Fixes #4655
---
 fftools/ffmpeg_opt.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 58ec13e5a8..c44ed63730 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -900,13 +900,14 @@ static void add_input_streams(OptionsContext *o, 
AVFormatContext *ic)
 
 static void assert_file_overwrite(const char *filename)
 {
+const char *proto_name = avio_find_protocol_name(filename);
+
 if (file_overwrite && no_file_overwrite) {
 fprintf(stderr, "Error, both -y and -n supplied. Exiting.\n");
 exit_program(1);
 }
 
 if (!file_overwrite) {
-const char *proto_name = avio_find_protocol_name(filename);
 if (proto_name && !strcmp(proto_name, "file") && avio_check(filename, 
0) == 0) {
 if (stdin_interaction && !no_file_overwrite) {
 fprintf(stderr,"File '%s' already exists. Overwrite ? [y/N] ", 
filename);
@@ -925,6 +926,19 @@ static void assert_file_overwrite(const char *filename)
 }
 }
 }
+
+if (proto_name && !strcmp(proto_name, "file")) {
+for (int i = 0; i < nb_input_files; i++) {
+ InputFile *file = input_files[i];
+ if (file->ctx->iformat->flags & AVFMT_NOFILE)
+ continue;
+ if (!strcmp(filename, file->ctx->url)) {
+ av_log(NULL, AV_LOG_FATAL, "Output %s same as Input #%d - 
exiting\n", filename, i);
+ av_log(NULL, AV_LOG_WARNING, "FFmpeg cannot edit existing 
files in-place.\n");
+ exit_program(1);
+ }
+}
+}
 }
 
 static void dump_attachment(AVStream *st, const char *filename)
-- 
2.18.0___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files

[Gyan Doshi]

On 31-08-2018 04:28 AM, Marton Balint wrote:



Is there any real use case when same source and destination works, so 
the option can be used?


If not, then just make ffmpeg fail, like the cp command fails for same 
source and destination. I am against adding an option if it has no known 
use.


Via the file protocol, not that I know of. Will remove.

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize h264_chroma_mc8_mmi v2.

[Shiyou Yin]

>-Original Message-
>From: ffmpeg-devel-boun...@ffmpeg.org [mailto:ffmpeg-devel-boun...@ffmpeg.org] 
>On Behalf Of
>Michael Niedermayer
>Sent: Friday, August 31, 2018 5:47 AM
>To: FFmpeg development discussions and patches
>Subject: Re: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize 
>h264_chroma_mc8_mmi v2.
>
>On Thu, Aug 30, 2018 at 02:24:04PM +0800, Shiyou Yin wrote:
>> Reoptimize function ff_put_h264_chroma_mc8_mmi and 
>> ff_avg_h264_chroma_mc8_mmi.
>> Performance of h264 decoding improved about 5%(from 69fps to 73fps, tested 
>> on loongson 3A3000).
>
>what do you mean by "Reoptimize"?
>does this port some optimizations from elsewhere ?
>does this take the same code as previous optimizations did and re implements
>(better/faster) MIPS code based on it ?
>
>what is the speed difference ?

Two functions have optimized with mmi yet.
This patch was based on the previous version, then optimized the branch 
condition and the code in
branch.
This patch will speed up about 5% for h264 decode on loongson platform.

>>
>> Change-Id: Iccd7f4e480b2d0bfc47e4d409874c4adb77416cc
>
>what is this ?

The original patch was made from loongson's local repository(we use gerrit to 
manage patch review
and merge), each commit has it's own Change-Id.
When I use git am to apply this patch to ffmpeg source, so the Change-Id was 
keeped with commit
message.
I will remove it in the next version.


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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_transpose adding NPP transpose filter

[Michael Niedermayer]

On Thu, Aug 30, 2018 at 10:13:28AM +, Roman Arzumanyan wrote:
> Hello,
> This patch adds NPP transpose filter.
> 
> Cmd example:
> ffmpeg.exe -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -vf 
> transpose_npp="t=3" -c:v h264_nvenc -y output_transpose_npp.mp4
> 
> Supported values:
> t=0 no transpose
> t=1 90 deg clockwise
> t=2 180 deg clockwise
> t=3 270 deg clockwise
> 
> --
> BR, Roman Arzumanyan
> 
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---

>  Makefile   |1 
>  allfilters.c   |1 
>  vf_transpose_npp.c |  515 
> +
>  3 files changed, 517 insertions(+)
> 3abd340cf177c125c57233d0085ab794e86fbf09  
> 0001-Adding-NPP-transpose-filter.patch
> From 72ce447ea2bf3c0fbf98a3324b56c1875d3dcb5f Mon Sep 17 00:00:00 2001
> From: Roman Arzumanyan 
> Date: Wed, 29 Aug 2018 12:53:02 +0300
> Subject: [PATCH] Adding NPP transpose filter

this breaks build:
make distclean ; ./configure && make -j12
CC  libavfilter/vf_transpose_npp.o
libavfilter/vf_transpose_npp.c:22:18: fatal error: nppi.h: No such file or 
directory
 #include 
  ^
compilation terminated.
make: *** [libavfilter/vf_transpose_npp.o] Error 1
make: Target `all' not remade because of errors.

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH] lavc/libaomenc: Add -tile-columns/-tile-rows

[James Almer]

On 8/20/2018 2:56 PM, Kagami Hiiragi wrote:
> These options are required for multithreaded encoding, because they set
> to zero by default in av1_cx_iface.c.
> 
> Signed-off-by: Kagami Hiiragi 
> 
> diff --git a/libavcodec/libaomenc.c b/libavcodec/libaomenc.c
> index 9431179886..55cb7ff72e 100644
> --- a/libavcodec/libaomenc.c
> +++ b/libavcodec/libaomenc.c
> @@ -68,6 +68,8 @@ typedef struct AOMEncoderContext {
>  int static_thresh;
>  int drop_threshold;
>  int noise_sensitivity;
> +int tile_columns;
> +int tile_rows;
>  } AOMContext;
>  
>  static const char *const ctlidstr[] = {
> @@ -75,6 +77,8 @@ static const char *const ctlidstr[] = {
>  [AOME_SET_CQ_LEVEL] = "AOME_SET_CQ_LEVEL",
>  [AOME_SET_ENABLEAUTOALTREF] = "AOME_SET_ENABLEAUTOALTREF",
>  [AOME_SET_STATIC_THRESHOLD] = "AOME_SET_STATIC_THRESHOLD",
> +[AV1E_SET_TILE_COLUMNS] = "AV1E_SET_TILE_COLUMNS",
> +[AV1E_SET_TILE_ROWS]= "AV1E_SET_TILE_ROWS",
>  [AV1E_SET_COLOR_RANGE]  = "AV1E_SET_COLOR_RANGE",
>  [AV1E_SET_COLOR_PRIMARIES]  = "AV1E_SET_COLOR_PRIMARIES",
>  [AV1E_SET_MATRIX_COEFFICIENTS] = "AV1E_SET_MATRIX_COEFFICIENTS",
> @@ -449,6 +453,11 @@ static av_cold int aom_init(AVCodecContext *avctx,
>  if (ctx->crf >= 0)
>  codecctl_int(avctx, AOME_SET_CQ_LEVEL,  ctx->crf);
>  
> +if (ctx->tile_columns >= 0)
> +codecctl_int(avctx, AV1E_SET_TILE_COLUMNS, ctx->tile_columns);
> +if (ctx->tile_rows >= 0)
> +codecctl_int(avctx, AV1E_SET_TILE_ROWS, ctx->tile_rows);
> +
>  codecctl_int(avctx, AV1E_SET_COLOR_PRIMARIES, avctx->color_primaries);
>  codecctl_int(avctx, AV1E_SET_MATRIX_COEFFICIENTS, avctx->colorspace);
>  codecctl_int(avctx, AV1E_SET_TRANSFER_CHARACTERISTICS, avctx->color_trc);
> @@ -746,6 +755,8 @@ static const AVOption options[] = {
>  { "static-thresh","A change threshold on blocks below which they 
> will be skipped by the encoder", OFFSET(static_thresh), AV_OPT_TYPE_INT, { 
> .i64 = 0 }, 0, INT_MAX, VE },
>  { "drop-threshold",   "Frame drop threshold", offsetof(AOMContext, 
> drop_threshold), AV_OPT_TYPE_INT, {.i64 = 0 }, INT_MIN, INT_MAX, VE },
>  { "noise-sensitivity", "Noise sensitivity", OFFSET(noise_sensitivity), 
> AV_OPT_TYPE_INT, {.i64 = 0 }, 0, 4, VE},
> +{ "tile-columns", "Number of tile columns to use, log2", 
> OFFSET(tile_columns), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},

Why 6? The libaom API doesn't mention a limit, just says the argument
should be in log2 unit, and that it will be capped based on the image size.

> +{ "tile-rows", "Number of tile rows to use, log2", OFFSET(tile_rows), 
> AV_OPT_TYPE_INT, {.i64 = -1}, -1, 6, VE},

And for this one it says the range is [0-2].

>  { NULL }
>  };
>  
> 

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

Re: [FFmpeg-devel] [PATCH] lavf/mov: Fix PCM audio w/ bit depth > 16

[Carl Eugen Hoyos]

2018-08-31 1:43 GMT+02:00, Michael Niedermayer :
> On Mon, Aug 27, 2018 at 12:59:28PM -0700, John Stebbins wrote:
>> This type of audio is defined by the QT spec, but can be found in
>> non-QT branded files in the wild.
>>
>> Fixes ticket #7376
>> ---
>>  libavformat/mov.c | 14 ++
>>  1 file changed, 14 insertions(+)
>
> So IIUC this is supporting a case that is slightly violating the spec ?
> Iam asking as i was wondering if it makes sense to check a few more
> things. For example the size could be checked if it actually is
> large enough to contain a version=1 header
>
> either way i think this patch should be ok

Maybe Baptiste finds testclip_wrong_version_1_audio_stsd.mp4
or has a comment.

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

Re: [FFmpeg-devel] [PATCH] configure: _deps: validate, reduce sensitivity

[Michael Niedermayer]

On Tue, Aug 28, 2018 at 10:27:31PM +, avih wrote:
> I analyzed the linkage failures at:
> http://ffmpeg.org/pipermail/ffmpeg-devel/2018-August/233674.html
> 
> After finding their immediate cause - expecting a specific output
> order from unique() - I realized that there might be a related issue
> where devs are expected to maintain _deps (e.g. avfilter_deps)
> in linking order. This can be awkward and bug-prone if the list is
> not empty. I noticed at least one such existing order bug.
> 
> This patch makes it easier to add to these lists, in any order,
> while also addressing few smaller issues and adding validation.
> 
> More details at the commit message of the attached patch.
> 
> Avi

>  configure |   46 --
>  1 file changed, 36 insertions(+), 10 deletions(-)
> 211c452a411b782b92743cc0df83746b4c89  
> 0001-configure-fflib-_deps-validate-reduce-sensitivity.patch
> From 4940963648cb431f1a8e827adefb58d318186b38 Mon Sep 17 00:00:00 2001
> From: "Avi Halachmi (:avih)" 
> Date: Tue, 28 Aug 2018 17:14:55 +0300
> Subject: [PATCH] configure: _deps: validate, reduce sensitivity

will apply

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] lavf/mov: Fix PCM audio w/ bit depth > 16

[Michael Niedermayer]

On Mon, Aug 27, 2018 at 12:59:28PM -0700, John Stebbins wrote:
> This type of audio is defined by the QT spec, but can be found in
> non-QT branded files in the wild.
> 
> Fixes ticket #7376
> ---
>  libavformat/mov.c | 14 ++
>  1 file changed, 14 insertions(+)

So IIUC this is supporting a case that is slightly violating the spec ?
Iam asking as i was wondering if it makes sense to check a few more
things. For example the size could be checked if it actually is
large enough to contain a version=1 header

either way i think this patch should be ok

[...]

thx
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH 1/4] lavf/mov: add AVCodecTag entry for GoPro metadata

[Michael Niedermayer]

On Mon, Aug 27, 2018 at 12:57:07PM -0700, John Stebbins wrote:
> This allows for validation of the track type
> ---
>  libavformat/isom.c | 5 +
>  libavformat/isom.h | 1 +
>  libavformat/mov.c  | 3 +++
>  3 files changed, 9 insertions(+)
> 
> diff --git a/libavformat/isom.c b/libavformat/isom.c
> index ce66d1bcd4..ca9d22e4f7 100644
> --- a/libavformat/isom.c
> +++ b/libavformat/isom.c
> @@ -374,6 +374,11 @@ const AVCodecTag ff_codec_movsubtitle_tags[] = {
>  { AV_CODEC_ID_NONE, 0 },
>  };
>  
> +const AVCodecTag ff_codec_movdata_tags[] = {
> +{ AV_CODEC_ID_BIN_DATA, MKTAG('g', 'p', 'm', 'd') },
> +{ AV_CODEC_ID_NONE, 0 },
> +};
> +
>  /* map numeric codes from mdhd atom to ISO 639 */
>  /* cf. QTFileFormat.pdf p253, qtff.pdf p205 */
>  /* http://developer.apple.com/documentation/mac/Text/Text-368.html */
> diff --git a/libavformat/isom.h b/libavformat/isom.h
> index 51abea52de..f3a7a8633d 100644
> --- a/libavformat/isom.h
> +++ b/libavformat/isom.h
> @@ -41,6 +41,7 @@ extern const AVCodecTag ff_mp4_obj_type[];
>  extern const AVCodecTag ff_codec_movvideo_tags[];
>  extern const AVCodecTag ff_codec_movaudio_tags[];
>  extern const AVCodecTag ff_codec_movsubtitle_tags[];
> +extern const AVCodecTag ff_codec_movdata_tags[];
>  
>  int ff_mov_iso639_to_lang(const char lang[4], int mp4);
>  int ff_mov_lang_to_iso639(unsigned code, char to[4]);
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index d66f4e338c..8915e3b9e0 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2034,6 +2034,8 @@ static int mov_codec_id(AVStream *st, uint32_t format)
>  id = ff_codec_get_id(ff_codec_movsubtitle_tags, format);
>  if (id > 0)
>  st->codecpar->codec_type = AVMEDIA_TYPE_SUBTITLE;
> +else
> +id = ff_codec_get_id(ff_codec_movdata_tags, format);

I think this should also set codec_type like the other cases


>  }
>  }
>  
> @@ -2507,6 +2509,7 @@ int ff_mov_read_stsd_entries(MOVContext *c, AVIOContext 
> *pb, int entries)
>  mov_parse_stsd_subtitle(c, pb, st, sc,
>  size - (avio_tell(pb) - start_pos));
>  } else {
> +st->codecpar->codec_id = id;

if this is done for all cases it should be factored out 
(maybe in a seperate patch)

thx

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files

[Marton Balint]

On Thu, 30 Aug 2018, Paul B Mahol wrote:


On 8/30/18, Gyan Doshi  wrote:

On 29-08-2018 09:48 AM, Gyan Doshi wrote:

On 29-08-2018 02:43 AM, Michael Niedermayer wrote:

On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:




Instead of this, maybe we should add support to write lock the files
when
opening them for reading. Then ffmpeg can request this. That would be an
useful option, and not just for unexperienced users.


depending on how this is done, it could interfere with reading a file
while
it is being written/appeneded to by another process


Yes, a user may use a growing MPEG-TS file as input.

Also, is there a universal & portable way to secure a write lock across
all platforms?

I think a 'soft' solution is preferable.


Any suggestions or objections?

If no, will push in a day.


Please do not push, until consensus is reached.

What about red log warning text?


Is there any real use case when same source and destination works, so the 
option can be used?


If not, then just make ffmpeg fail, like the cp command fails for same 
source and destination. I am against adding an option if it has no known 
use.


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]tests/ref/fate/pixelutils: Add a newline

[Carl Eugen Hoyos]

2018-08-30 2:31 GMT+02:00, myp...@gmail.com :
> On Thu, Aug 30, 2018 at 5:36 AM Carl Eugen Hoyos  wrote:

>> Attached patch fixes fate-pixelutils on aix.
>>
>> Please comment, Carl Eugen

> LGTM

Patch applied.

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings

[Carl Eugen Hoyos]

2018-08-30 23:12 GMT+02:00, Michael Niedermayer :
> On Tue, Aug 28, 2018 at 10:29:37PM +0100, Rostislav Pehlivanov wrote:
>> Turns out those ones make the decoder unable to accurately determine the
>> layout, hence making some API users' guess, and sometimes those are
>> correct
>> (ffmpeg.c), but most often (especially with side channels) they're wrong.
>> The removed ones need to be investigated into as to why the decoder
>> rejects
>> them.
>>
>> Signed-off-by: Rostislav Pehlivanov 
>> ---
>>  libavcodec/aacenc.h | 177 
>>  1 file changed, 177 deletions(-)
>
> breaks for example:
> ./ffmpeg -i ~/tickets/1065/Test1.wtv -acodec aac test.mov

The sample is in samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1065/

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

[FFmpeg-devel] [mov] Error on too large stsd entry counts.

[Dale Curtis]

Entries are always at least 8 bytes per the parsing code, so if we
see an impossible entry count avoid massive allocations. This is
similar to an existing check in mov_read_stsc().

Since ff_mov_read_stsd_entries() does eof checks, an alternative
approach could be to clamp the entry count to atom.size / 8.

Signed-off-by: Dale Curtis 
From 3e1663d84068ff7615f7e84fa1c1122729a531da Mon Sep 17 00:00:00 2001
From: Dale Curtis 
Date: Thu, 30 Aug 2018 15:18:25 -0700
Subject: [PATCH] Error on too large stsd entry counts.

Entries are always at least 8 bytes per the parsing code, so if we
see an impossible entry count avoid massive allocations. This is
similar to an existing check in mov_read_stsc().

Since ff_mov_read_stsd_entries() does eof checks, an alternative
approach could be to clamp the entry count to atom.size / 8.

Signed-off-by: Dale Curtis 
---
 libavformat/mov.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/mov.c b/libavformat/mov.c
index d66f4e338c..d922e0f173 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2558,7 +2558,8 @@ static int mov_read_stsd(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 avio_rb24(pb); /* flags */
 entries = avio_rb32(pb);
 
-if (entries <= 0) {
+/* Each entry contains a size (4 bytes) and format (4 bytes). */
+if (entries <= 0 || entries > atom.size / 8) {
 av_log(c->fc, AV_LOG_ERROR, "invalid STSD entries %d\n", entries);
 return AVERROR_INVALIDDATA;
 }
-- 
2.19.0.rc0.228.g281dcd1b4d0-goog

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize h264_chroma_mc8_mmi v2.

[Michael Niedermayer]

On Thu, Aug 30, 2018 at 02:24:04PM +0800, Shiyou Yin wrote:
> Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi.
> Performance of h264 decoding improved about 5%(from 69fps to 73fps, tested on 
> loongson 3A3000).

what do you mean by "Reoptimize"?
does this port some optimizations from elsewhere ?
does this take the same code as previous optimizations did and re implements
(better/faster) MIPS code based on it ?

what is the speed difference ?


> 
> Change-Id: Iccd7f4e480b2d0bfc47e4d409874c4adb77416cc

what is this ?


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

Observe your enemies, for they first find out your faults. -- Antisthenes


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

Re: [FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings

[Michael Niedermayer]

On Tue, Aug 28, 2018 at 10:29:37PM +0100, Rostislav Pehlivanov wrote:
> Turns out those ones make the decoder unable to accurately determine the
> layout, hence making some API users' guess, and sometimes those are correct
> (ffmpeg.c), but most often (especially with side channels) they're wrong.
> The removed ones need to be investigated into as to why the decoder rejects
> them.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aacenc.h | 177 
>  1 file changed, 177 deletions(-)

breaks for example:
./ffmpeg -i ~/tickets/1065/Test1.wtv -acodec aac test.mov

i assume the input is the same as this: 
​http://www.mediafire.com/?ojp54ym1mkaqkg4

thx

[...]
-- 
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
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/utvideodec: use cached bitstream reader everywhere except on x86_32

[James Almer]

> ffmpeg | branch: master | Paul B Mahol  > | Tue Apr  3 13:32:07 
> 2018 +0200| [562f00ed072080b34f351577818783a94ac9de62] | committer: Paul B 
> Mahol
>
> avcodec/utvideodec: use cached bitstream reader everywhere except on x86_32
>
> >/From 100x real-time decoding to 138x real-time decoding for 320x240
> video. /
> Signed-off-by: Paul B Mahol  >
>
> >/http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=562f00ed072080b34f351577818783a94ac9de62
> /---
>
>  libavcodec/utvideodec.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
> index 82cb038ccd..3891df3570 100644
> --- a/libavcodec/utvideodec.c
> +++ b/libavcodec/utvideodec.c
> @@ -27,6 +27,7 @@
>  #include 
>  #include 
>  
> +#define CACHED_BITSTREAM_READER !ARCH_X86_32

The checks in get_bits.h are #ifdef, so the value you're setting here is
going to be ignored.
You should instead do it the same way as UNCHECKED_BITSTREAM_READER:
Always defined
to 0 by default, then set to 1 by individual components.

>  #define UNCHECKED_BITSTREAM_READER 1
>  
>  #include "libavutil/intreadwrite.h"

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

Re: [FFmpeg-devel] wolfSSL - new TLS backend patch

[Paul B Mahol]

On 8/28/18, samsamsam  wrote:
> This patch was prepared and tested for version 3.4.2, but I think that it
> can be used as base to discuss to add wolfSSL support.  How do you think?

It can not be used as is.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files

[Paul B Mahol]

On 8/30/18, Gyan Doshi  wrote:
> On 29-08-2018 09:48 AM, Gyan Doshi wrote:
>> On 29-08-2018 02:43 AM, Michael Niedermayer wrote:
>>> On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:
>>

 Instead of this, maybe we should add support to write lock the files
 when
 opening them for reading. Then ffmpeg can request this. That would be an
 useful option, and not just for unexperienced users.
>>>
>>> depending on how this is done, it could interfere with reading a file
>>> while
>>> it is being written/appeneded to by another process
>>
>> Yes, a user may use a growing MPEG-TS file as input.
>>
>> Also, is there a universal & portable way to secure a write lock across
>> all platforms?
>>
>> I think a 'soft' solution is preferable.
>
> Any suggestions or objections?
>
> If no, will push in a day.

Please do not push, until consensus is reached.

What about red log warning text?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] ffmpeg: block output == input for files

[Gyan Doshi]

On 29-08-2018 09:48 AM, Gyan Doshi wrote:

On 29-08-2018 02:43 AM, Michael Niedermayer wrote:

On Tue, Aug 28, 2018 at 08:31:51AM +0200, Marton Balint wrote:




Instead of this, maybe we should add support to write lock the files 
when

opening them for reading. Then ffmpeg can request this. That would be an
useful option, and not just for unexperienced users.


depending on how this is done, it could interfere with reading a file 
while

it is being written/appeneded to by another process


Yes, a user may use a growing MPEG-TS file as input.

Also, is there a universal & portable way to secure a write lock across 
all platforms?


I think a 'soft' solution is preferable.


Any suggestions or objections?

If no, will push in a day.

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

[FFmpeg-devel] wolfSSL - new TLS backend patch

[samsamsam]

This patch was prepared and tested for version 3.4.2, but I think that it can 
be used as base to discuss to add wolfSSL support.  How do you think?   diff 
-Nur ffmpeg-3.4.2/configure ffmpeg-3.4.2_wolfssl_patch/con  --- 
ffmpeg-3.4.2/configure   2018-02 01:29:18.0 +0100  +++ 
ffmpeg-3.4.2_wolfssl_patch/con 17:38:46.0 +0200  @@ -215,7 +215,7 @@    
 --enable-gmp  enable gmp, needed for rtmp(t)e support      
if openssl or librtmp is not used [no]     --enable-gnutls   � enable 
gnutls, needed for https support  -  � if openssl is not used [no]  
+  � if openssl or wolfssl is not used [no]     --disable-iconv 
  � disable iconv [autodetect]     --disable-jack disable libjack 
support [autodetect]     --enable-jni  enable JNI support [no]  @@ 
-270,6 +270,8 @@     --enable-libvpx   � enable VP8 and VP9 de/encoding via 
libvpx [no]     --enable-libwavpack  enable wavpack encoding via libwavpack 
[no]     --enable-libwebp    enable WebP encoding via libwebp [no]  +  
--enable-wolfssl    enable WolfSSL), needed for https support  +
  � if openssl or gnutls is not used [no]     --enable-libx264    enable 
H.264 encoding via x264 [no]     --enable-libx265    enable HEVC encoding 
via x265 [no]     --enable-libxavs    enable AVS encoding via xavs [no]  @@ 
-292,7 +294,7 @@     --enable-opencl   � enable OpenCL code     
--enable-opengl   � enable OpenGL rendering [no]     --enable-openssl   
 enable openssl, needed for https support  -  � if gnutls is not 
used [no]  +  � if gnutls or wolfssl is not used [no]     
--disable-sndio   � disable sndio support [autodetect]     
--disable-schannel   disable SChannel SSP, needed for TLS support on    
  Windows if openssl and gnutls are not used [autodetect]  @@ -1563,6 
+1565,7 @@   libndi_newtek   libfdk_aac   openssl  +    wolfssl  
   EXTERNAL_LIBRARY_VERSION3_LIST  @@ -3164,14 +3167,17 @@  
tls_gnutls_protocol_conflict= tls_securetransport_protocol  
tls_gnutls_protocol_deps=gnut  tls_gnutls_protocol_select=tc  
-tls_openssl_protocol_conflict tls_securetransport_protocol 
tls_gnutls_protocol  +tls_openssl_protocol_conflict 
tls_securetransport_protocol tls_gnutls_protocol tls_wolfssl_protocol  
tls_openssl_protocol_deps=ope  tls_openssl_protocol_select=t  
+tls_wolfssl_protocol_conflict tls_securetransport_protocol 
tls_gnutls_protocol  +tls_wolfssl_protocol_deps=wo  
+tls_wolfssl_protocol_select=  tls_schannel_protocol_deps=sc  
tls_schannel_protocol_select=  tls_securetransport_protocol_d  
tls_securetransport_protocol_s  -tls_protocol_deps_any=tls_sc 
tls_securetransport_protocol tls_gnutls_protocol tls_openssl_protocol  
+tls_protocol_deps_any=tls_sc tls_securetransport_protocol 
tls_gnutls_protocol tls_openssl_protocol tls_wolfssl_protocol  
udp_protocol_select=network  udplite_protocol_select=netwo  
unix_protocol_deps=sys_un_h  @@ -5907,6 +5913,7 @@  enabled frei0r
     require_header frei0r.h  enabled gmp � 
 require gmp gmp.h mpz_export -lgmp  enabled gnutls    
 require_pkg_config gnutls gnutls gnutls/gnutls.h gnutls_global_init  
+enabled wolfssl    require_pkg_config wolfssl wolfssl 
wolfssl/ssl.h wolfSSL_library_init  enabled jni �  { [ 
$target_os = android ]  check_header jni.h  
enabled pthreads || die ERROR: jni not found; }  enabled ladspa   
  require_header ladspa.h  enabled libiec61883    
require libiec61883 libiec61883/iec61883.h iec61883_cmp_connect -lraw1394 
-lavc1394 -lrom1394 -liec61883  diff -Nur ffmpeg-3.4.2/libavformat/Makef 
ffmpeg-3.4.2_wolfssl_patch/lib  --- ffmpeg-3.4.2/libavformat/Makef 
01:29:06.0 +0100  +++ ffmpeg-3.4.2_wolfssl_patch/lib 17:38:47.0 
+0200  @@ -589,6 +589,7 @@  OBJS-$(CONFIG_TCP_PROTOCOL) � += tcp.o  
OBJS-$(CONFIG_TLS_GNUTLS_PROTO += tls_gnutls.o tls.o  
OBJS-$(CONFIG_TLS_OPENSSL_PROT += tls_openssl.o tls.o  
+OBJS-$(CONFIG_TLS_WOLFSSL_PRO += tls_wolfssl.o tls.o  
OBJS-$(CONFIG_TLS_SCHANNEL_PRO += tls_schannel.o tls.o  
OBJS-$(CONFIG_TLS_SECURETRANSP += tls_securetransport.o tls.o  
OBJS-$(CONFIG_UDP_PROTOCOL) � += udp.o  diff -Nur 
ffmpeg-3.4.2/libavformat/netwo ffmpeg-3.4.2_wolfssl_patch/lib  --- 
ffmpeg-3.4.2/libavformat/netwo 01:29:06.0 +0100  +++ 
ffmpeg-3.4.2_wolfssl_patch/lib 17:38:47.0 +0200  @@ -37,6 +37,9 @@  #if 
CONFIG_TLS_GNUTLS_PROTOCOL   ff_gnutls_init();  #endif  +#if 
CONFIG_TLS_WOLFSSL_PROTOCOL  +    ff_wolfssl_init();  +#endif   return 0;  
}   @@ -48,6 +51,9 @@  #if CONFIG_TLS_GNUTLS_PROTOCOL   ff_gnutls_deinit(); 
 #endif  +#if CONFIG_TLS_WOLFSSL_PROTOCOL  +    ff_wolfssl_deinit();  +#endif  
}   int ff_network_inited_globally;  diff -Nur ffmpeg-3.4.2/libavformat/proto 
ffmpeg-3.4.2_wolfssl_patch/lib  --- ffmpeg-3.4.2/libavformat/proto 
01:29:06.0 +0100  +++ ffmpeg-3.4.2_wolfssl_patch/lib 

[FFmpeg-devel] lavf//dashdec:fix calc_cur_seg_no with presentation_timeoffset

[jacek jendrzej]

Hi.
My try to fix Ticket #7382.
Patch for https://trac.ffmpeg.org/ticket/7382
From a22984201f05854c6ec6e86cf05f67c2419d Mon Sep 17 00:00:00 2001
From: Jacek Jendrzej 
Date: Wed, 29 Aug 2018 12:35:35 +0200
Subject: [PATCH] avformat/dashdec:try to fix calc_cur_seg_no with 
 presentation_timeoffset

---
 libavformat/dashdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0435f25412..81168efd82 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1294,7 +1294,7 @@ static int64_t calc_cur_seg_no(AVFormatContext *s, struct representation *pls)
 num += pls->first_seq_no;
 } else if (pls->fragment_duration){
 if (pls->presentation_timeoffset) {
-num = pls->presentation_timeoffset * pls->fragment_timescale / pls->fragment_duration;
+num = pls->first_seq_no + (((get_current_time_in_sec() * pls->fragment_timescale)-pls->presentation_timeoffset) / pls->fragment_duration) - 120;//FIXME waht is 120 ??? 
 } else if (c->publish_time > 0 && !c->availability_start_time) {
 num = pls->first_seq_no + (((c->publish_time - c->time_shift_buffer_depth + pls->fragment_duration) - c->suggested_presentation_delay) * pls->fragment_timescale) / pls->fragment_duration;
 } else {
-- 
2.18.0

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

[FFmpeg-devel] avformat/dashdec:try to fix calc_cur_seg_no with presentation_timeoffset

[jacek jendrzej]

Hi.
Patch for Ticket #7382.
From a22984201f05854c6ec6e86cf05f67c2419d Mon Sep 17 00:00:00 2001
From: Jacek Jendrzej 
Date: Wed, 29 Aug 2018 12:35:35 +0200
Subject: [PATCH] avformat/dashdec:try to fix calc_cur_seg_no with 
 presentation_timeoffset

---
 libavformat/dashdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 0435f25412..81168efd82 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1294,7 +1294,7 @@ static int64_t calc_cur_seg_no(AVFormatContext *s, struct representation *pls)
 num += pls->first_seq_no;
 } else if (pls->fragment_duration){
 if (pls->presentation_timeoffset) {
-num = pls->presentation_timeoffset * pls->fragment_timescale / pls->fragment_duration;
+num = pls->first_seq_no + (((get_current_time_in_sec() * pls->fragment_timescale)-pls->presentation_timeoffset) / pls->fragment_duration) - 120;//FIXME no idea waht is 120 , work ok with around 80 to 180
 } else if (c->publish_time > 0 && !c->availability_start_time) {
 num = pls->first_seq_no + (((c->publish_time - c->time_shift_buffer_depth + pls->fragment_duration) - c->suggested_presentation_delay) * pls->fragment_timescale) / pls->fragment_duration;
 } else {
-- 
2.18.0

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

[FFmpeg-devel] Can support h264 encoder by mediacodec on android?

[冯良怀]

Hello,

   Ffmpeg has supported H264 hardware decoding by mediacodec.But  it cannot 
support H264 encoder by mediacodec.
   Can you add H264 encoder by mediacodec in future?



Thank's for help.
Regards.


flhcd

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

[FFmpeg-devel] [PATCH] avcodec/scpr: add version 3 support

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/scpr.c | 1606 +++--
 1 file changed, 1568 insertions(+), 38 deletions(-)

diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
index 965a3ed22f..bef6d10130 100644
--- a/libavcodec/scpr.c
+++ b/libavcodec/scpr.c
@@ -24,47 +24,1562 @@
 #include 
 #include 
 
+#include "libavutil/qsort.h"
+
 #include "avcodec.h"
 #include "bytestream.h"
 #include "internal.h"
 
-#define TOP  0x0100
-#define BOT0x01
+#define TOP  0x0100
+#define BOT0x01
+
+typedef struct RangeCoder {
+unsigned   code;
+unsigned   range;
+unsigned   code1;
+} RangeCoder;
+
+typedef struct PixelModel {
+unsignedfreq[256];
+unsignedlookup[16];
+unsignedtotal_freq;
+} PixelModel;
+
+typedef struct PixelModel3 {
+uint8_ttype;
+uint8_tlength;
+uint8_tmaxpos;
+uint8_tfshift;
+uint16_t   size;
+uint32_t   cntsum;
+uint8_tsymbols[256];
+uint16_t   freqs[256];
+uint16_t   freqs1[256];
+uint16_t   cnts[256];
+uint8_tdectab[32];
+} PixelModel3;
+
+typedef struct FillModel3 {
+uint32_t   cntsum;
+uint16_t   freqs[2][5];
+uint16_t   cnts[5];
+uint8_tdectab[32];
+} FillModel3;
+
+typedef struct OpModel3 {
+uint32_t   cntsum;
+uint16_t   freqs[2][6];
+uint16_t   cnts[6];
+uint8_tdectab[32];
+} OpModel3;
+
+typedef struct RunModel3 {
+uint32_t   cntsum;
+uint16_t   freqs[2][256];
+uint16_t   cnts[256];
+uint8_tdectab[32];
+} RunModel3;
+
+typedef struct SxyModel3 {
+uint32_t   cntsum;
+uint16_t   freqs[2][16];
+uint16_t   cnts[16];
+uint8_tdectab[32];
+} SxyModel3;
+
+typedef struct MVModel3 {
+uint32_t   cntsum;
+uint16_t   freqs[2][512];
+uint16_t   cnts[512];
+uint8_tdectab[32];
+} MVModel3;
+
+typedef struct SCPRContext {
+int version;
+AVFrame*last_frame;
+AVFrame*current_frame;
+GetByteContext  gb;
+RangeCoder  rc;
+PixelModel  pixel_model[3][4096];
+unsignedop_model[6][7];
+unsignedrun_model[6][257];
+unsignedrange_model[257];
+unsignedcount_model[257];
+unsignedfill_model[6];
+unsignedsxy_model[4][17];
+unsignedmv_model[2][513];
+unsignednbx, nby;
+unsignednbcount;
+unsigned   *blocks;
+unsignedcbits;
+int cxshift;
+
+PixelModel3 pixel_model3[3][4096];
+RunModel3   run_model3[6];
+RunModel3   range_model3;
+RunModel3   count_model3;
+FillModel3  fill_model3;
+SxyModel3   sxy_model3[4];
+MVModel3mv_model3[2];
+OpModel3op_model3[6];
+
+int   (*get_freq)(RangeCoder *rc, unsigned total_freq, unsigned 
*freq);
+int   (*decode)(GetByteContext *gb, RangeCoder *rc, unsigned 
cumFreq, unsigned freq, unsigned total_freq);
+} SCPRContext;
+
+static void renew_table3(unsigned nsym, uint32_t *cntsum,
+ uint16_t *freqs, uint16_t *freqs1,
+ uint16_t *cnts, uint8_t *dectab)
+{
+unsigned a = 0, b = 4096 / nsym, c = b - (b >> 1);
+
+*cntsum = c * nsym;
+
+for (int d = 0; d < nsym; d++) {
+freqs[d] = b;
+freqs1[d] = a;
+cnts[d] = c;
+for (int q = a + 128 - 1 >> 7, f = (a + b - 1 >> 7) + 1; q < f; q++) {
+dectab[q] = d;
+}
+
+a += b;
+}
+}
+
+static void reinit_tables3(SCPRContext * s)
+{
+int i, j;
+
+for (i = 0; i < 3; i++) {
+for (j = 0; j < 4096; j++) {
+PixelModel3 *m = >pixel_model3[i][j];
+memset(m, 0, sizeof(*m));
+}
+}
+
+for (i = 0; i < 6; i++) {
+renew_table3(256, >run_model3[i].cntsum,
+ s->run_model3[i].freqs[0], s->run_model3[i].freqs[1],
+ s->run_model3[i].cnts, s->run_model3[i].dectab);
+}
+
+renew_table3(256, >range_model3.cntsum,
+ s->range_model3.freqs[0], s->range_model3.freqs[1],
+ s->range_model3.cnts, s->range_model3.dectab);
+
+renew_table3(5, >fill_model3.cntsum,
+ s->fill_model3.freqs[0], s->fill_model3.freqs[1],
+ s->fill_model3.cnts, s->fill_model3.dectab);
+
+renew_table3(256, >count_model3.cntsum,
+ s->count_model3.freqs[0], s->count_model3.freqs[1],
+ s->count_model3.cnts, s->count_model3.dectab);
+
+for (i = 0; i < 4; i++) {
+renew_table3(16, >sxy_model3[i].cntsum,
+ s->sxy_model3[i].freqs[0], s->sxy_model3[i].freqs[1],
+ s->sxy_model3[i].cnts, s->sxy_model3[i].dectab);
+}
+
+for (i = 0; i < 2; i++) {
+renew_table3(512, >mv_model3[i].cntsum,
+ s->mv_model3[i].freqs[0], s->mv_model3[i].freqs[1],
+ 

Re: [FFmpeg-devel] [PATCH] avformat/utils: Don't parse encrypted packets.

[Jacob Trimble]

On Wed, Aug 29, 2018 at 4:37 PM Michael Niedermayer
 wrote:
>
> On Wed, Aug 29, 2018 at 03:30:39PM -0700, Jacob Trimble wrote:
> > On Wed, Aug 29, 2018 at 3:20 PM James Almer  wrote:
> > >
> > > On 8/29/2018 7:07 PM, Michael Niedermayer wrote:
> > > > On Tue, Aug 28, 2018 at 10:58:43AM -0700, Jacob Trimble wrote:
> > > >> If a packet is full-sample encrypted, then packet data can't be parsed
> > > >> without decrypting it.  So this skips the packet parsing for those
> > > >> packets.  If the packet has sub-sample encryption, it is assumed that
> > > >> the headers are in the clear and the parser will only need that info.
> > > >>
> > > >> Signed-off-by: Jacob Trimble 
> > > >> ---
> > > >>  libavformat/utils.c | 21 -
> > > >>  1 file changed, 20 insertions(+), 1 deletion(-)
> > > >
> > > > Hmm, please correct me if iam wrong but IIUC
> > > > 1. The demuxer has set need_parsing, indicating that it _requires_ a 
> > > > parser
> >
> > There isn't a flag for "try parsing and ignore errors".  So my choice
> > (from an app) is to either require parsing or don't do parsing at all
> > (which can result in incorrect timestamps).
> >
> > > > 2. Parsing cannot be done before decrypting
> > > >
> > > > If all this and the set values are correct, logically, the fix would be
> > > > to decrypt the packet before the parser not to skip the parser.
> >
>
> > There are cases where the packet can't be decrypted before getting to
> > this point.
>
> Can you elaborate on these cases ? I dont think its obvious what these
> cases are, at least its not obvious to me what exactly you are thinking
> of here. And i think its not helpfull if i guess what you mean and then
> argue/comment on that because maybe you meant something entirely different ...

Fair warning, I am working on a DRM solution.  I know many of you may
not agree with DRM, but it is a requirement imposed by content
creators.  FFmpeg doesn't have to support DRM itself, but you should
still consider its usages.

At that point in the code, the packet can only be decrypted by the
demuxer.  For example, in MP4 this can be done by passing the
-decryption_key parameter.  But that requires that FFmpeg handle the
decryption.  In my case, we are passing the packet to a CDM (content
decryption module) to handle the decryption and that might be a
hardware-secure decryptor.  In most DRM situations, we can't get the
raw key at all, all we can do is say "decrypt this block of memory".
So the only way to have the packet decrypted before this point would
be to introduce a callback to the app to decrypt the packet.

This is why I have been working on exposing the encryption info.  My
app (or more correctly the CDM) needs to handle the decryption and we
can't just give the key to libavformat so the demuxer can decrypt the
packet.

>
>
> > This point is between the demuxer creating the packet and
> > giving to the app.  So the only way to decrypt the frame (as of now)
> > is for the demuxer to do this.  There is no way for the app to handle
> > the decryption before this point.
> >
>
> > From the app's perspective, I would expect the packet to remain
> > encrypted for as long as possible.
>
> why ?

Because the point of encryption is to ensure that nefarious parties
don't get access to the data.  Even though the packet data is stored
in memory, it could still be retrieved by a malicious user.  Usually
for protected media, the frames are only decrypted when needed and in
some cases are decrypted in a secure CPU and isn't even accessible to
the app.  There are platforms that support what is called "direct
render" where the app gives the platform the encrypted packets and a
discrete hardware unit will decrypt the packet, decode it, and render
it directly; this happens on some smart TVs.  There are also cases
which require decrypt-decode where we give the platform an encrypted
packet and it will decrypt and decode the packet, ensuring the
decrypted packet data is never in main memory.  So there are cases
where we can't even see the encoded packet and decoding is handled by
the platform.

>
>
> > My app will store the packet for a
> > while, then decrypt it right before passing it to the decoder and
> > drawing the frame.  So requiring the packet to be decrypted at this
> > point is not ideal.
> >
> > >
> > > And if that can't be done, then the demuxer could perhaps set
> > > st->need_parsing to 0 and skip parsing altogether?
> >
> > I would want to still have parsing if possible. For example, a lot of
> > content has a clear lead where the first few seconds are clear.  So
> > they could be used to adjust the starting timestamps (and whatever
> > parsing needs) and the encrypted content later can be deduced based on
> > that.
> >
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Modern terrorism, a quick summary: Need oil, start war with country that
> has oil, kill hundread thousand in war. Let country fall into chaos,
> be 

Re: [FFmpeg-devel] [PATCH] lavf/libsmbclient: return AVERROR_EOF for EOF.

[Nicolas George]

Nicolas George (2018-08-30):
> Fix trac ticket #7387.
> 
> Signed-off-by: Nicolas George 
> ---
>  libavformat/libsmbclient.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> 
> Untested, I do not have a SMB share at hand.

Confirmed to work on trac. Will push soon.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] lavf/libsmbclient: return AVERROR_EOF for EOF.

[Nicolas George]

Fix trac ticket #7387.

Signed-off-by: Nicolas George 
---
 libavformat/libsmbclient.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


Untested, I do not have a SMB share at hand.


diff --git a/libavformat/libsmbclient.c b/libavformat/libsmbclient.c
index b68cd8bd79..3285868957 100644
--- a/libavformat/libsmbclient.c
+++ b/libavformat/libsmbclient.c
@@ -166,7 +166,7 @@ static int libsmbc_read(URLContext *h, unsigned char *buf, 
int size)
 return ret;
 }
 
-return bytes_read;
+return bytes_read ? bytes_read : AVERROR_EOF;
 }
 
 static int libsmbc_write(URLContext *h, const unsigned char *buf, int size)
-- 
2.18.0

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

[FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] optimize memset in h264dsp.

[Shiyou Yin]

Optimized memset with mmi in following functions:
1. ff_h264_add_pixels4_8_mmi.
2. ff_h264_idct_add_8_mmi.
3. ff_h264_idct8_add_8_mmi.

This optimization improved h264 decoding performance about 1fps(tested on 
loongson 3A3000).

Change-Id: I4e8b75510e6a34b4c80f84ad784b00377570c4ec
---
 libavcodec/mips/h264dsp_mmi.c | 30 +-
 1 file changed, 21 insertions(+), 9 deletions(-)

diff --git a/libavcodec/mips/h264dsp_mmi.c b/libavcodec/mips/h264dsp_mmi.c
index ac6fa99..ac65a20 100644
--- a/libavcodec/mips/h264dsp_mmi.c
+++ b/libavcodec/mips/h264dsp_mmi.c
@@ -31,7 +31,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, 
int stride)
 {
 double ftmp[9];
 DECLARE_VAR_LOW32;
-DECLARE_VAR_ALL64;
 
 __asm__ volatile (
 "xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
@@ -59,12 +58,16 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, 
int stride)
 MMI_SWC1(%[ftmp2], %[dst1], 0x00)
 MMI_SWC1(%[ftmp3], %[dst2], 0x00)
 MMI_SWC1(%[ftmp4], %[dst3], 0x00)
+
+/* memset(src, 0, 32); */
+"xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x00(%[src])\n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x10(%[src])\n\t"
 : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]),
   [ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]),
   [ftmp4]"="(ftmp[4]),[ftmp5]"="(ftmp[5]),
   [ftmp6]"="(ftmp[6]),[ftmp7]"="(ftmp[7]),
   RESTRICT_ASM_LOW32
-  RESTRICT_ASM_ALL64
   [ftmp8]"="(ftmp[8])
 : [dst0]"r"(dst),   [dst1]"r"(dst+stride),
   [dst2]"r"(dst+2*stride),  [dst3]"r"(dst+3*stride),
@@ -72,7 +75,6 @@ void ff_h264_add_pixels4_8_mmi(uint8_t *dst, int16_t *src, 
int stride)
 : "memory"
 );
 
-memset(src, 0, 32);
 }
 
 void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int stride)
@@ -80,7 +82,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, int 
stride)
 double ftmp[12];
 uint64_t tmp[1];
 DECLARE_VAR_LOW32;
-DECLARE_VAR_ALL64;
 DECLARE_VAR_ADDRT;
 
 __asm__ volatile (
@@ -152,6 +153,11 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, 
int stride)
 MMI_SWC1(%[ftmp2], %[dst], 0x00)
 "packushb   %[ftmp0],   %[ftmp0],   %[ftmp7]\n\t"
 MMI_SWXC1(%[ftmp0], %[dst], %[stride], 0x00)
+
+/* memset(block, 0, 32) */
+"xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x00(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x10(%[block])  \n\t"
 : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]),
   [ftmp2]"="(ftmp[2]),[ftmp3]"="(ftmp[3]),
   [ftmp4]"="(ftmp[4]),[ftmp5]"="(ftmp[5]),
@@ -159,7 +165,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, 
int stride)
   [ftmp8]"="(ftmp[8]),[ftmp9]"="(ftmp[9]),
   [ftmp10]"="(ftmp[10]),  [ftmp11]"="(ftmp[11]),
   RESTRICT_ASM_LOW32
-  RESTRICT_ASM_ALL64
   RESTRICT_ASM_ADDRT
   [tmp0]"="(tmp[0])
 : [dst]"r"(dst),[block]"r"(block),
@@ -167,7 +172,6 @@ void ff_h264_idct_add_8_mmi(uint8_t *dst, int16_t *block, 
int stride)
 : "memory"
 );
 
-memset(block, 0, 32);
 }
 
 void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, int stride)
@@ -176,7 +180,6 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, 
int stride)
 uint64_t tmp[7];
 mips_reg addr[1];
 DECLARE_VAR_LOW32;
-DECLARE_VAR_ALL64;
 DECLARE_VAR_ADDRT;
 
 __asm__ volatile (
@@ -617,6 +620,17 @@ void ff_h264_idct8_add_8_mmi(uint8_t *dst, int16_t *block, 
int stride)
 MMI_SWC1(%[ftmp6], %[addr0], 0x00)
 MMI_SWXC1(%[ftmp7], %[addr0], %[stride], 0x00)
 PTR_ADDIU  "$29,$29,0x20\n\t"
+
+/* memset(block, 0, 128) */
+"xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x00(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x10(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x20(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x30(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x40(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x50(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x60(%[block])  \n\t"
+"gssqc1 %[ftmp0],   %[ftmp0],   0x70(%[block])  \n\t"
 : [ftmp0]"="(ftmp[0]),[ftmp1]"="(ftmp[1]),
   [ftmp2]"="(ftmp[2]),   

Re: [FFmpeg-devel] [PATCH] avfilter/vf_transpose adding NPP transpose filter

[Timo Rothenpieler]

Thanks!

I'm a bit short on time at the moment, but I'll try to have a look 
during the weekend.

If someone else also wants to give a review, please go ahead!



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter/vf_transpose adding NPP transpose filter

[Roman Arzumanyan]

Hello,
This patch adds NPP transpose filter.

Cmd example:
ffmpeg.exe -hwaccel cuvid -c:v h264_cuvid -i input.mp4 -vf transpose_npp="t=3" 
-c:v h264_nvenc -y output_transpose_npp.mp4

Supported values:
t=0 no transpose
t=1 90 deg clockwise
t=2 180 deg clockwise
t=3 270 deg clockwise

--
BR, Roman Arzumanyan


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---


0001-Adding-NPP-transpose-filter.patch
Description: 0001-Adding-NPP-transpose-filter.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/dnxhdenc: stop leaking memory when initalization fails

[Paul B Mahol]

Fixes #6593.

Signed-off-by: Paul B Mahol 
---
 libavcodec/dnxhdenc.c | 18 +-
 libavcodec/dnxhdenc.h |  2 ++
 2 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 01e22e7764..5135eedfd6 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -207,17 +207,17 @@ static av_cold int dnxhd_init_vlc(DNXHDEncContext *ctx)
 int i, j, level, run;
 int max_level = 1 << (ctx->bit_depth + 2);
 
-FF_ALLOCZ_ARRAY_OR_GOTO(ctx->m.avctx, ctx->vlc_codes,
-  max_level, 4 * sizeof(*ctx->vlc_codes), fail);
-FF_ALLOCZ_ARRAY_OR_GOTO(ctx->m.avctx, ctx->vlc_bits,
-  max_level, 4 * sizeof(*ctx->vlc_bits), fail);
+FF_ALLOCZ_ARRAY_OR_GOTO(ctx->m.avctx, ctx->orig_vlc_codes,
+  max_level, 4 * sizeof(*ctx->orig_vlc_codes), fail);
+FF_ALLOCZ_ARRAY_OR_GOTO(ctx->m.avctx, ctx->orig_vlc_bits,
+  max_level, 4 * sizeof(*ctx->orig_vlc_bits), fail);
 FF_ALLOCZ_OR_GOTO(ctx->m.avctx, ctx->run_codes,
   63 * 2, fail);
 FF_ALLOCZ_OR_GOTO(ctx->m.avctx, ctx->run_bits,
   63, fail);
 
-ctx->vlc_codes += max_level * 2;
-ctx->vlc_bits  += max_level * 2;
+ctx->vlc_codes = ctx->orig_vlc_codes + max_level * 2;
+ctx->vlc_bits  = ctx->orig_vlc_bits + max_level * 2;
 for (level = -max_level; level < max_level; level++) {
 for (run = 0; run < 2; run++) {
 int index = (level << 1) | run;
@@ -1348,11 +1348,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 static av_cold int dnxhd_encode_end(AVCodecContext *avctx)
 {
 DNXHDEncContext *ctx = avctx->priv_data;
-int max_level= 1 << (ctx->bit_depth + 2);
 int i;
 
-av_free(ctx->vlc_codes - max_level * 2);
-av_free(ctx->vlc_bits - max_level * 2);
+av_freep(>orig_vlc_codes);
+av_freep(>orig_vlc_bits);
 av_freep(>run_codes);
 av_freep(>run_bits);
 
@@ -1392,6 +1391,7 @@ AVCodec ff_dnxhd_encoder = {
 .encode2= dnxhd_encode_picture,
 .close  = dnxhd_encode_end,
 .capabilities   = AV_CODEC_CAP_SLICE_THREADS | AV_CODEC_CAP_FRAME_THREADS 
| AV_CODEC_CAP_INTRA_ONLY,
+.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
 .pix_fmts   = (const enum AVPixelFormat[]) {
 AV_PIX_FMT_YUV422P,
 AV_PIX_FMT_YUV422P10,
diff --git a/libavcodec/dnxhdenc.h b/libavcodec/dnxhdenc.h
index 963821ac81..7b0d862e28 100644
--- a/libavcodec/dnxhdenc.h
+++ b/libavcodec/dnxhdenc.h
@@ -86,6 +86,8 @@ typedef struct DNXHDEncContext {
 unsigned frame_bits;
 uint8_t *src[3];
 
+uint32_t *orig_vlc_codes;
+uint8_t  *orig_vlc_bits;
 uint32_t *vlc_codes;
 uint8_t  *vlc_bits;
 uint16_t *run_codes;
-- 
2.17.1

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_interlace: fix numerical options

[Thomas Mundt]

Am Mo., 27. Aug. 2018 um 20:40 Uhr schrieb Thomas Mundt :

> Am Mo., 27. Aug. 2018 um 19:40 Uhr schrieb Paul B Mahol  >:
>
>> On 8/27/18, Thomas Mundt  wrote:
>> > Am Fr., 24. Aug. 2018 um 15:05 Uhr schrieb Paul B Mahol <
>> one...@gmail.com>:
>> >
>> >> On 8/23/18, Thomas Mundt  wrote:
>> >> > Currently numerical option values are misinterpreted in vf_interlace
>> >> > filter.
>> >> > Patch attached.
>> >> >
>> >> > Regards,
>> >> > Thomas
>> >> >
>> >>
>> >> ok
>> >>
>> >
>> > Thanks. Can you please push it?
>>
>> Does this breaks tinterlace numerical options?
>>
>> Anyway numerical options are not supported, and is free to change.
>>
>
> Indeed the numerical usage of the tinterlace option "flags" is changed.
> But, as you say, numerical usage is not supported or even documented in
> this case.
> The "mode" option is unchanged and can be used numerical as documented.
>

Ping.
Do you still have concerns?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v2] fate: add 10-bit test for hue video filter

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak | 3 +++
 tests/ref/fate/filter-hue4  | 1 +
 2 files changed, 4 insertions(+)
 create mode 100644 tests/ref/fate/filter-hue4

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index edd51e1..8bbdc04 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -514,6 +514,9 @@ fate-filter-hue2: CMD = video_filter 
"perms=random,hue=h=18*n" -frames:v 20
 FATE_FILTER_VSYNTH-$(call ALLYES, PERMS_FILTER HUE_FILTER) += fate-filter-hue3
 fate-filter-hue3: CMD = video_filter "perms=random,hue=b=n-10" -frames:v 20
 
+FATE_FILTER_VSYNTH-$(call ALLYES, FORMAT_FILTER PERMS_FILTER HUE_FILTER) += 
fate-filter-hue4
+fate-filter-hue4: CMD = video_filter 
"format=yuv422p10,perms=random,hue=h=18*n:s=n/10" -frames:v 20 -pix_fmt 
yuv422p10le
+
 FATE_FILTER_VSYNTH-$(CONFIG_IDET_FILTER) += fate-filter-idet
 fate-filter-idet: CMD = framecrc -flags bitexact -idct simple -i $(SRC) -vf 
idet -frames:v 25 -flags +bitexact
 
diff --git a/tests/ref/fate/filter-hue4 b/tests/ref/fate/filter-hue4
new file mode 100644
index 000..2a08c33
--- /dev/null
+++ b/tests/ref/fate/filter-hue4
@@ -0,0 +1 @@
+hue46279ed43527e7b5be645819e08880107
-- 
2.7.4


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

Re: [FFmpeg-devel] [PATCH]lavc/cfhd: Drop an unused function

[Paul B Mahol]

On 8/23/18, Gagandeep Singh  wrote:
> On Thu, Aug 23, 2018 at 7:33 PM Paul B Mahol  wrote:
>
>> On 8/23/18, Carl Eugen Hoyos  wrote:
>> > Hi!
>> >
>> > Attached patch removes an unused function from cfhd.c.
>> >
>> > Please comment, Carl Eugen
>> >
>>
>> Not acceptable. Function is needed, but was dropped due programmer's
>> error.
>>
> I just noticed. Will add it back in the updated patch that i will work on
> saturday.

So, you worked out something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] examples: Fix use of AV_CODEC_FLAG_GLOBAL_HEADER

[Michael Bunk]

AV_CODEC_FLAG_GLOBAL_HEADER should be set before calling avcodec_open2() to 
have any effect.
---
 doc/examples/transcoding.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index a83fa3a..e48837c 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -172,6 +172,9 @@ static int open_output_file(const char *filename)
 enc_ctx->time_base = (AVRational){1, enc_ctx->sample_rate};
 }
 
+if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
+enc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
+
 /* Third parameter can be used to pass settings to encoder */
 ret = avcodec_open2(enc_ctx, encoder, NULL);
 if (ret < 0) {
@@ -183,8 +186,6 @@ static int open_output_file(const char *filename)
 av_log(NULL, AV_LOG_ERROR, "Failed to copy encoder parameters 
to output stream #%u\n", i);
 return ret;
 }
-if (ofmt_ctx->oformat->flags & AVFMT_GLOBALHEADER)
-enc_ctx->flags |= AV_CODEC_FLAG_GLOBAL_HEADER;
 
 out_stream->time_base = enc_ctx->time_base;
 stream_ctx[i].enc_ctx = enc_ctx;
-- 
2.7.4

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

[FFmpeg-devel] [PATCH 1/2] Fix typos

[Michael Bunk]

---
 libavcodec/qsvenc_h264.c | 2 +-
 libavutil/avassert.h | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 7aa65e9..dfa4666 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -1,5 +1,5 @@
 /*
- * Intel MediaSDK QSV based H.264 enccoder
+ * Intel MediaSDK QSV based H.264 encoder
  *
  * copyright (c) 2013 Yukinori Yamazoe
  *
diff --git a/libavutil/avassert.h b/libavutil/avassert.h
index 46f3fea..9abeade 100644
--- a/libavutil/avassert.h
+++ b/libavutil/avassert.h
@@ -66,7 +66,7 @@
 #endif
 
 /**
- * Assert that floating point opperations can be executed.
+ * Assert that floating point operations can be executed.
  *
  * This will av_assert0() that the cpu is not in MMX state on X86
  */
-- 
2.7.4

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

[FFmpeg-devel] [PATCH v2] avcodec/mips: [loongson] reoptimize h264_chroma_mc8_mmi v2.

[Shiyou Yin]

Reoptimize function ff_put_h264_chroma_mc8_mmi and ff_avg_h264_chroma_mc8_mmi.
Performance of h264 decoding improved about 5%(from 69fps to 73fps, tested on 
loongson 3A3000).

Change-Id: Iccd7f4e480b2d0bfc47e4d409874c4adb77416cc
---
 libavcodec/mips/h264chroma_mmi.c | 744 ---
 1 file changed, 455 insertions(+), 289 deletions(-)

diff --git a/libavcodec/mips/h264chroma_mmi.c b/libavcodec/mips/h264chroma_mmi.c
index bafe0f9..91b2cc4 100644
--- a/libavcodec/mips/h264chroma_mmi.c
+++ b/libavcodec/mips/h264chroma_mmi.c
@@ -29,326 +29,322 @@
 void ff_put_h264_chroma_mc8_mmi(uint8_t *dst, uint8_t *src, ptrdiff_t stride,
 int h, int x, int y)
 {
-const int A = (8 - x) * (8 - y);
-const int B = x * (8 - y);
-const int C = (8 - x) * y;
-const int D = x * y;
-const int E = B + C;
+int A = 64, B, C, D, E;
 double ftmp[10];
 uint64_t tmp[1];
-mips_reg addr[1];
-DECLARE_VAR_ALL64;
 
-if (D) {
+if (!(x || y)) {
+/* x=0, y=0, A=64 */
 __asm__ volatile (
-"xor%[ftmp0],   %[ftmp0],   %[ftmp0]\n\t"
-"dli%[tmp0],0x06\n\t"
-"pshufh %[A],   %[A],   %[ftmp0]\n\t"
-"pshufh %[B],   %[B],   %[ftmp0]\n\t"
-"mtc1   %[tmp0],%[ftmp9]\n\t"
-"pshufh %[C],   %[C],   %[ftmp0]\n\t"
-"pshufh %[D],   %[D],   %[ftmp0]\n\t"
+"xor%[ftmp0],   %[ftmp0],   %[ftmp0]   \n\t"
+"dli%[tmp0],0x06   \n\t"
+"mtc1   %[tmp0],%[ftmp4]   \n\t"
 
-"1: \n\t"
-PTR_ADDU   "%[addr0],   %[src], %[stride]   \n\t"
+"1:\n\t"
 MMI_ULDC1(%[ftmp1], %[src], 0x00)
-MMI_ULDC1(%[ftmp2], %[src], 0x01)
-MMI_ULDC1(%[ftmp3], %[addr0], 0x00)
-MMI_ULDC1(%[ftmp4], %[addr0], 0x01)
-
-"punpcklbh  %[ftmp5],   %[ftmp1],   %[ftmp0]\n\t"
-"punpckhbh  %[ftmp6],   %[ftmp1],   %[ftmp0]\n\t"
-"punpcklbh  %[ftmp7],   %[ftmp2],   %[ftmp0]\n\t"
-"punpckhbh  %[ftmp8],   %[ftmp2],   %[ftmp0]\n\t"
-"pmullh %[ftmp5],   %[ftmp5],   %[A]\n\t"
-"pmullh %[ftmp7],   %[ftmp7],   %[B]\n\t"
-"paddh  %[ftmp1],   %[ftmp5],   %[ftmp7]\n\t"
-"pmullh %[ftmp6],   %[ftmp6],   %[A]\n\t"
-"pmullh %[ftmp8],   %[ftmp8],   %[B]\n\t"
-"paddh  %[ftmp2],   %[ftmp6],   %[ftmp8]\n\t"
-
-"punpcklbh  %[ftmp5],   %[ftmp3],   %[ftmp0]\n\t"
-"punpckhbh  %[ftmp6],   %[ftmp3],   %[ftmp0]\n\t"
-"punpcklbh  %[ftmp7],   %[ftmp4],   %[ftmp0]\n\t"
-"punpckhbh  %[ftmp8],   %[ftmp4],   %[ftmp0]\n\t"
-"pmullh %[ftmp5],   %[ftmp5],   %[C]\n\t"
-"pmullh %[ftmp7],   %[ftmp7],   %[D]\n\t"
-"paddh  %[ftmp3],   %[ftmp5],   %[ftmp7]\n\t"
-"pmullh %[ftmp6],   %[ftmp6],   %[C]\n\t"
-"pmullh %[ftmp8],   %[ftmp8],   %[D]\n\t"
-"paddh  %[ftmp4],   %[ftmp6],   %[ftmp8]\n\t"
-
-"paddh  %[ftmp1],   %[ftmp1],   %[ftmp3]\n\t"
-"paddh  %[ftmp2],   %[ftmp2],   %[ftmp4]\n\t"
-"paddh  %[ftmp1],   %[ftmp1],   %[ff_pw_32] \n\t"
-"paddh  %[ftmp2],   %[ftmp2],   %[ff_pw_32] \n\t"
-"psrlh  %[ftmp1],   %[ftmp1],   %[ftmp9]\n\t"
-"psrlh  %[ftmp2],   %[ftmp2],   %[ftmp9]\n\t"
-"packushb   %[ftmp1],   %[ftmp1],   %[ftmp2]\n\t"
-"addi   %[h],   %[h],   -0x01   \n\t"
+"addi   %[h],   %[h],   -0x04  \n\t"
+PTR_ADDU   "%[src], %[src], %[stride]  \n\t"
+MMI_ULDC1(%[ftmp5], %[src], 0x00)
+PTR_ADDU   "%[src], %[src], %[stride]  \n\t"
+MMI_ULDC1(%[ftmp6], %[src], 0x00)
+PTR_ADDU   "%[src], %[src], %[stride]  \n\t"
+MMI_ULDC1(%[ftmp7], %[src], 0x00)
+
+"punpcklbh  %[ftmp2],   %[ftmp1],