Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On 12/13/2015 12:01 PM, Paul B Mahol wrote:

On 12/13/15, Mats Peterson  wrote:

On 12/13/2015 11:06 AM, Paul B Mahol wrote:

On 12/13/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Paul B Mahol wrote:


On 12/12/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Michael Niedermayer wrote:


On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:

Obviously that private data is cropped in some way then, since the
minimum size of a video sample description in QuickTime video is 86
bytes.


FFmpeg tries to support all kind of odd and broken files, so even if
the file is invalid, continuing to support it would be better



Personally I don't see why it should support broken files, but your
mileage may vary, of course. So just keep the value 21 then.


Have you provided file that doesn't work?





I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME
video and with a private data of only 21 bytes, when it should be at
least
86 bytes, which is the minimum size for a video sample description in
QuickTime.



What about non-broken files?


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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



I'm sorry, I don't understand what you're after. Of course I have tried
this patch with several test files.



Have you provided such several test filest to others?



In this directory are three sample Matroska files with QuickTime video 
that will display with the wrong palette (none at all, really) without 
the patch: http://matsp888.no-ip.org/~mats/qtpalette-test/


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On 12/13/2015 12:10 PM, Mats Peterson wrote:

On 12/13/2015 12:01 PM, Paul B Mahol wrote:




Have you provided such several test filest to others?



In this directory are three sample Matroska files with QuickTime video
that will display with the wrong palette (none at all, really) without
the patch: http://matsp888.no-ip.org/~mats/qtpalette-test/



This is of course not top priority, since using Matroska for storing 
palettized video is not that common (except for me, who likes to use a 
unified container format for everything, including audio). But it's nice 
when everything works as expected.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Paul B Mahol]

On 12/13/15, Mats Peterson  wrote:
> On 12/13/2015 11:06 AM, Paul B Mahol wrote:
>> On 12/13/15, Mats Peterson  wrote:
>>> On Sat, 12 Dec 2015, Paul B Mahol wrote:
>>>
 On 12/12/15, Mats Peterson  wrote:
> On Sat, 12 Dec 2015, Michael Niedermayer wrote:
>
>> On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
>>> Obviously that private data is cropped in some way then, since the
>>> minimum size of a video sample description in QuickTime video is 86
>>> bytes.
>>
>> FFmpeg tries to support all kind of odd and broken files, so even if
>> the file is invalid, continuing to support it would be better
>>
>
> Personally I don't see why it should support broken files, but your
> mileage may vary, of course. So just keep the value 21 then.

 Have you provided file that doesn't work?

>
>>>
>>> I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME
>>> video and with a private data of only 21 bytes, when it should be at
>>> least
>>> 86 bytes, which is the minimum size for a video sample description in
>>> QuickTime.
>>>
>>
>> What about non-broken files?
>>
>>> Mats
>>>
>>> --
>>> Mats Peterson
>>> http://matsp888.no-ip.org/~mats/
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> I'm sorry, I don't understand what you're after. Of course I have tried
> this patch with several test files.
>

Have you provided such several test filest to others?

> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/tee: fix side data double free.

[Michael Niedermayer]

On Sat, Oct 10, 2015 at 07:13:04PM +0200, Nicolas George wrote:
> Le nonidi 19 vendémiaire, an CCXXIV, wm4 a écrit :
> > This looks suspicious. Like some code above this does unclean tricks
> > with keeping side-data somehow referenced, instead of using proper
> > methods like creating a new AVPacket reference.
> 
> It is the same code than in ffmpeg.c, but I must admit I did not take time
> to really understand how side data ownership is handled.
> 
> I suspect the best course of action would be to wait for Roger's patch to be
> applied, it should fix this very issue at the same time, and applying this
> patch or Bela's latest version would only annoy him with rebase conflicts.

2 months have passed it hasnt happened, thus applied this
also this affects a release and rogers patch wont help the release

and i think serious bugs should not be left open when rather simple
fixes are known.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] lavf: add automatic bitstream filtering; bump version

[Michael Niedermayer]

On Fri, Dec 04, 2015 at 09:03:05PM -0600, Rodger Combs wrote:
> This solves the problem discussed in 
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have been
> run through required bitstream filters in order to generate global extradata.
> 
> It also provides a mechanism by which a muxer can add a bitstream filter to a
> stream automatically, rather than prompting the user to do so.
> ---
>  Changelog  |  1 +
>  doc/APIchanges |  3 +++
>  libavformat/avformat.h | 23 +++
>  libavformat/internal.h | 17 +
>  libavformat/mux.c  | 49 ++---
>  libavformat/version.h  |  2 +-
>  6 files changed, 91 insertions(+), 4 deletions(-)

works fine and i can confirm it fixes the bug
why has this patchset not been applied ?

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On 12/13/2015 11:06 AM, Paul B Mahol wrote:

On 12/13/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Paul B Mahol wrote:


On 12/12/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Michael Niedermayer wrote:


On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:

Obviously that private data is cropped in some way then, since the
minimum size of a video sample description in QuickTime video is 86
bytes.


FFmpeg tries to support all kind of odd and broken files, so even if
the file is invalid, continuing to support it would be better



Personally I don't see why it should support broken files, but your
mileage may vary, of course. So just keep the value 21 then.


Have you provided file that doesn't work?





I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME
video and with a private data of only 21 bytes, when it should be at least
86 bytes, which is the minimum size for a video sample description in
QuickTime.



What about non-broken files?


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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



I'm sorry, I don't understand what you're after. Of course I have tried 
this patch with several test files.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Paul B Mahol]

On 12/13/15, Mats Peterson  wrote:
> On Sat, 12 Dec 2015, Paul B Mahol wrote:
>
>> On 12/12/15, Mats Peterson  wrote:
>>> On Sat, 12 Dec 2015, Michael Niedermayer wrote:
>>>
 On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:
> Obviously that private data is cropped in some way then, since the
> minimum size of a video sample description in QuickTime video is 86
> bytes.

 FFmpeg tries to support all kind of odd and broken files, so even if
 the file is invalid, continuing to support it would be better

>>>
>>> Personally I don't see why it should support broken files, but your
>>> mileage may vary, of course. So just keep the value 21 then.
>>
>> Have you provided file that doesn't work?
>>
>>>
>
> I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME
> video and with a private data of only 21 bytes, when it should be at least
> 86 bytes, which is the minimum size for a video sample description in
> QuickTime.
>

What about non-broken files?

> Mats
>
> --
> Mats Peterson
> http://matsp888.no-ip.org/~mats/
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/mpegtsenc: add flag to embed an AC-3/E-AC-3 ES the DVB way

[Stefan Pöschel]

So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
To fix this inconsistency, this commit changes the default E-AC-3 behaviour to
use the ATSC way, too. Furthermore a new flag is added to optionally select the
DVB way (regarding both codecs and possible further differences in the future).
---
 libavformat/mpegts.h|  1 +
 libavformat/mpegtsenc.c | 20 ++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/libavformat/mpegts.h b/libavformat/mpegts.h
index 84f3098..0cdbc76 100644
--- a/libavformat/mpegts.h
+++ b/libavformat/mpegts.h
@@ -60,6 +60,7 @@
 #define STREAM_TYPE_AUDIO_AC3   0x81
 #define STREAM_TYPE_AUDIO_DTS   0x82
 #define STREAM_TYPE_AUDIO_TRUEHD0x83
+#define STREAM_TYPE_AUDIO_EAC3  0x87

 typedef struct MpegTSContext MpegTSContext;

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 19032f3..cb11c31 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -99,6 +99,7 @@ typedef struct MpegTSWrite {
 #define MPEGTS_FLAG_REEMIT_PAT_PMT  0x01
 #define MPEGTS_FLAG_AAC_LATM0x02
 #define MPEGTS_FLAG_PAT_PMT_AT_FRAMES   0x04
+#define MPEGTS_FLAG_SYSTEM_B0x08
 int flags;
 int copyts;
 int tables_version;
@@ -319,7 +320,14 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 stream_type = STREAM_TYPE_AUDIO_AAC_LATM;
 break;
 case AV_CODEC_ID_AC3:
-stream_type = STREAM_TYPE_AUDIO_AC3;
+stream_type = (ts->flags & MPEGTS_FLAG_SYSTEM_B)
+  ? STREAM_TYPE_PRIVATE_DATA
+  : STREAM_TYPE_AUDIO_AC3;
+break;
+case AV_CODEC_ID_EAC3:
+stream_type = (ts->flags & MPEGTS_FLAG_SYSTEM_B)
+  ? STREAM_TYPE_PRIVATE_DATA
+  : STREAM_TYPE_AUDIO_EAC3;
 break;
 case AV_CODEC_ID_DTS:
 stream_type = STREAM_TYPE_AUDIO_DTS;
@@ -343,7 +351,12 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 /* write optional descriptors here */
 switch (st->codec->codec_type) {
 case AVMEDIA_TYPE_AUDIO:
-if (st->codec->codec_id==AV_CODEC_ID_EAC3) {
+if (st->codec->codec_id==AV_CODEC_ID_AC3 && (ts->flags & 
MPEGTS_FLAG_SYSTEM_B)) {
+*q++=0x6a; // AC3 descriptor see A038 DVB SI
+*q++=1; // 1 byte, all flags sets to 0
+*q++=0; // omit all fields...
+}
+if (st->codec->codec_id==AV_CODEC_ID_EAC3 && (ts->flags & 
MPEGTS_FLAG_SYSTEM_B)) {
 *q++=0x7a; // EAC3 descriptor see A038 DVB SI
 *q++=1; // 1 byte, all flags sets to 0
 *q++=0; // omit all fields...
@@ -1790,6 +1803,9 @@ static const AVOption options[] = {
 { "pat_pmt_at_frames", "Reemit PAT and PMT at each video frame",
   0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_FLAG_PAT_PMT_AT_FRAMES}, 0, 
INT_MAX,
   AV_OPT_FLAG_ENCODING_PARAM, "mpegts_flags" },
+{ "system_b", "Conform to System B (DVB) instead of System A (ATSC)",
+  0, AV_OPT_TYPE_CONST, { .i64 = MPEGTS_FLAG_SYSTEM_B }, 0, INT_MAX,
+  AV_OPT_FLAG_ENCODING_PARAM, "mpegts_flags" },
 // backward compatibility
 { "resend_headers", "Reemit PAT/PMT before writing the next packet",
   offsetof(MpegTSWrite, reemit_pat_pmt), AV_OPT_TYPE_INT,
-- 
2.6.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ronald S. Bultje]

Hi,

On Sun, Dec 13, 2015 at 7:29 PM, Ganesh Ajjanagadde 
wrote:

> The worst part is that it is a bad idea to do runtime dispatch on the
> fma() itself, as the function call overhead will be nonneglible, and
> so one can't create a helper API in avutil or elsewhere. Thus, it can
> only be used when a function is in a critical hotspot, where the
> duplication of code and maintainence burden can be justified for the
> performance benefits. I might be missing something here though.


You would DSP'ize the loop, not the single fma instruction, right?
Depending on the size of the array (i.e. the size variable), it may be ok.

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

[FFmpeg-devel] HLS webVtt in unfavorable conditions

[Anshul]

Hello,

Its regarding ticket #5067(avformat:open): crash on Mapping Multicast TV 
Stream to HLS with "Exactly one WebVTT stream is needed" as message


I have attached patch for hls not failing in condition where subtitles 
streams are of bitmap type and ts containing data streams mapped to output.


But this patch have side effect, that user is not warned that stream 
that are shown as mapped in logs are actually ignored by hls segmeter.


I have not added errors/warning about ignoring streams, since I was 
unable to decide whether they should be warning or error.


Thanks
Anshul Maheshwari

>From e266babd729f1ed90c8956090f9e9658c85e13a9 Mon Sep 17 00:00:00 2001
From: Anshul Maheshwari 
Date: Sun, 13 Dec 2015 20:45:02 +0530
Subject: [PATCH] hls supports only webVTT as subtitles

Signed-off-by: Anshul Maheshwari 
---
 libavformat/hlsenc.c | 26 +-
 1 file changed, 17 insertions(+), 9 deletions(-)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index adcf7df..0bbea39 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -285,10 +285,13 @@ static int hls_mux_init(AVFormatContext *s)
 for (i = 0; i < s->nb_streams; i++) {
 AVStream *st;
 AVFormatContext *loc;
-if (s->streams[i]->codec->codec_type == AVMEDIA_TYPE_SUBTITLE)
+if (s->streams[i]->codec->codec_id == AV_CODEC_ID_WEBVTT)
 loc = vtt_oc;
-else
+else if (s->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO ||
+s->streams[i]->codec->codec_type == AVMEDIA_TYPE_AUDIO)
 loc = oc;
+else
+continue;
 
 if (!(st = avformat_new_stream(loc, NULL)))
 return AVERROR(ENOMEM);
@@ -612,7 +615,7 @@ static int hls_write_header(AVFormatContext *s)
 hls->has_video +=
 s->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO;
 hls->has_subtitle +=
-s->streams[i]->codec->codec_type == AVMEDIA_TYPE_SUBTITLE;
+s->streams[i]->codec->codec_id == AV_CODEC_ID_WEBVTT;
 }
 
 if (hls->has_video > 1)
@@ -714,10 +717,11 @@ static int hls_write_header(AVFormatContext *s)
 for (i = 0; i < s->nb_streams; i++) {
 AVStream *inner_st;
 AVStream *outer_st = s->streams[i];
-if (outer_st->codec->codec_type != AVMEDIA_TYPE_SUBTITLE)
-inner_st = hls->avf->streams[i];
-else if (hls->vtt_avf)
+if (hls->vtt_avf && outer_st->codec->codec_id == AV_CODEC_ID_WEBVTT)
 inner_st = hls->vtt_avf->streams[0];
+else if(outer_st->codec->codec_type == AVMEDIA_TYPE_VIDEO ||
+   outer_st->codec->codec_type == AVMEDIA_TYPE_AUDIO)
+inner_st = hls->avf->streams[i];
 else {
 /* We have a subtitle stream, when the user does not want one */
 inner_st = NULL;
@@ -750,13 +754,17 @@ static int hls_write_packet(AVFormatContext *s, AVPacket *pkt)
 int ret, can_split = 1;
 int stream_index = 0;
 
-if( st->codec->codec_type == AVMEDIA_TYPE_SUBTITLE ) {
+if (st->codec->codec_type == AVMEDIA_TYPE_VIDEO ||
+   st->codec->codec_type == AVMEDIA_TYPE_AUDIO ) {
+oc = hls->avf;
+stream_index = pkt->stream_index;
+} else if( hls->vtt_avf && st->codec->codec_id == AV_CODEC_ID_WEBVTT) {
 oc = hls->vtt_avf;
 stream_index = 0;
 } else {
-oc = hls->avf;
-stream_index = pkt->stream_index;
+	return 0;
 }
+
 if (hls->start_pts == AV_NOPTS_VALUE) {
 hls->start_pts = pkt->pts;
 hls->end_pts   = pkt->pts;
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: add flag to embed an AC-3/E-AC-3 ES the DVB way

[Moritz Barsnick]

On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
> So far an AC-3 elementary stream is refered to in the PMT according to
> System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.

Interesting, that's apparently the reason why my (DVB-)PVR didn't ever
recognize AC-3 in MPEG-TS. See
https://ffmpeg.org/pipermail/ffmpeg-user/2015-October/028812.html
E-AC-3 in MPEG-TS seems to have worked (I just tried it - successfully
- for the first time), I didn't realize that.

With your patch, I can now successfully play AC-3 and E-AC-3 with that
player, when using the "-mpegts_flags system_b" (and kill this
capability when not using it).

> To fix this inconsistency, this commit changes the default E-AC-3 behaviour to
> use the ATSC way, too. Furthermore a new flag is added to optionally select 
> the
> DVB way (regarding both codecs and possible further differences in the 
> future).

I never found the patch mentioned in the thread, and don't know enough
about the differences myself.

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: add flag to embed an AC-3/E-AC-3 ES the DVB way

[Stefan Pöschel]

Am 13.12.2015 um 14:18 schrieb Moritz Barsnick:
> On Sun, Dec 13, 2015 at 11:54:32 +0100, Stefan Pöschel wrote:
>> So far an AC-3 elementary stream is refered to in the PMT according to
>> System A (ATSC). An E-AC-3 ES in contrast is embedded the System B (DVB) way.
> 
> Interesting, that's apparently the reason why my (DVB-)PVR didn't ever
> recognize AC-3 in MPEG-TS. See
> https://ffmpeg.org/pipermail/ffmpeg-user/2015-October/028812.html
> E-AC-3 in MPEG-TS seems to have worked (I just tried it - successfully
> - for the first time), I didn't realize that.
> 
> With your patch, I can now successfully play AC-3 and E-AC-3 with that
> player, when using the "-mpegts_flags system_b" (and kill this
> capability when not using it).

I've had the same problem which was the motivation to take a look into it.

>> To fix this inconsistency, this commit changes the default E-AC-3 behaviour 
>> to
>> use the ATSC way, too. Furthermore a new flag is added to optionally select 
>> the
>> DVB way (regarding both codecs and possible further differences in the 
>> future).
> 
> I never found the patch mentioned in the thread, and don't know enough
> about the differences myself.

There is a bug report of libav regarding this problem, together with a
patch from 2011 which just changes the AC-3 signalling from ATSC to DVB:
https://bugzilla.libav.org/show_bug.cgi?id=73

Yesterday I therefore posted a patch to libav-devel (similar to this one
for FFmpeg-devel) for switching between ATSC and DVB:
https://lists.libav.org/pipermail/libav-devel/2015-December/073574.html

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: Handle palettized QuickTime video properly

[Mats Peterson]

On 12/13/2015 12:10 PM, Mats Peterson wrote:

On 12/13/2015 12:01 PM, Paul B Mahol wrote:

On 12/13/15, Mats Peterson  wrote:

On 12/13/2015 11:06 AM, Paul B Mahol wrote:

On 12/13/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Paul B Mahol wrote:


On 12/12/15, Mats Peterson  wrote:

On Sat, 12 Dec 2015, Michael Niedermayer wrote:


On Sat, Dec 12, 2015 at 11:17:00AM +, Mats Peterson wrote:

Obviously that private data is cropped in some way then, since the
minimum size of a video sample description in QuickTime video
is 86
bytes.


FFmpeg tries to support all kind of odd and broken files, so
even if
the file is invalid, continuing to support it would be better



Personally I don't see why it should support broken files, but your
mileage may vary, of course. So just keep the value 21 then.


Have you provided file that doesn't work?





I got a sample Matroska file from Michael Niedermayer with V_QUICKTIME
video and with a private data of only 21 bytes, when it should be at
least
86 bytes, which is the minimum size for a video sample description in
QuickTime.



What about non-broken files?


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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



I'm sorry, I don't understand what you're after. Of course I have tried
this patch with several test files.



Have you provided such several test filest to others?



In this directory are three sample Matroska files with QuickTime video
that will display with the wrong palette (none at all, really) without
the patch: http://matsp888.no-ip.org/~mats/qtpalette-test/



Here is a directory at Google Drive in case my local server should be 
down: http://bit.ly/1I1Bw2I


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: New patch for palettized QuickTime video (old one broken)

[Mats Peterson]

On 12/13/2015 09:02 PM, Mats Peterson wrote:

On 12/13/2015 08:48 PM, Mats Peterson wrote:

I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't discover it until I tried one with
audio as well (all the samples so far are video only).

Mats



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



I forgot to restore the lower limit of A_QUICKTIME private data to 21
like Michael Niedermayer proposed. Sorry (it doesn't make much sense to
me, but at least that broken file will pass.)

Mats



V_QUICKTIME (video) of course, not A_QUICKTIME.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] golomb: always check for invalid UE golomb codes in get_ue_golomb

[Andreas Cadhalpun]

Also correct the check to reject log < 7, because UPDATE_CACHE only
guarantees 25 meaningful bits.

This fixes undefined behavior:
runtime error: shift exponent is negative

Testing with START/STOP timers in get_ue_golomb, one for the first
branch (A) and one for the second (B), shows that there is practically no
slowdown, e.g. for the cavs decoder:

With the check in the B branch:
629 decicycles in get_ue_golomb B, 4194260 runs, 44 skips
433 decicycles in get_ue_golomb A,268434102 runs,   1354 skips

Without the check:
624 decicycles in get_ue_golomb B, 4194273 runs, 31 skips
433 decicycles in get_ue_golomb A,268434203 runs,   1253 skips

Since the B branch is executed far less often than the A branch, this
change is negligible, even more so for the h264 decoder, where the ratio
B/A is a lot smaller.

Fixes: mozilla bug 1229208
Fixes: 
fbeb8b2c7c996e9b91c6b1af319d7ebc/asan_heap-oob_195450f_2743_e8856ece4579ea486670be2b236099a0.bit

Found-by: Tyson Smith
Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Andreas Cadhalpun 
---

Note that I just copied the "Fixes:" lines from Michael's patch, but actually
I don't know what mozilla bug 1229208 is about, as it seems not to be public.
Also I don't have the mentioned sample, but the patch fixes more than 1000
of my fuzzed samples that triggered this ubsan error, so I'm confident the
mentioned one is also fixed.

---
 libavcodec/golomb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index d30bb6b..5136a04 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -68,7 +68,7 @@ static inline int get_ue_golomb(GetBitContext *gb)
 int log = 2 * av_log2(buf) - 31;
 LAST_SKIP_BITS(re, gb, 32 - log);
 CLOSE_READER(re, gb);
-if (CONFIG_FTRAPV && log < 0) {
+if (log < 7) {
 av_log(NULL, AV_LOG_ERROR, "Invalid UE golomb code\n");
 return AVERROR_INVALIDDATA;
 }
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] fate: increase FUZZ by 1 for aac-tns-encode

[Andreas Cadhalpun]

This should fix this test failing on kfreebsd, a regression since
6e5dbe7, which decreased the CMP_TARGET by 1.

Signed-off-by: Andreas Cadhalpun 
---

I haven't tested this on kfreebsd, but it seems obvious [1]:
stddev:  823.32 PSNR: 38.02 MAXDIFF:15809 bytes:  1675800/  1679360
stddev: |823.32 - 817| >= 6

1: 
http://fatebeta.ffmpeg.org/report/x86_32-debian-kfreebsd-gcc-4.4-cpuflags-mmx2/20151213180818#failed_tests

---
 tests/fate/aac.mak | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/fate/aac.mak b/tests/fate/aac.mak
index 4e55b76..ae7ebfa 100644
--- a/tests/fate/aac.mak
+++ b/tests/fate/aac.mak
@@ -183,7 +183,7 @@ fate-aac-tns-encode: CMP = stddev
 fate-aac-tns-encode: REF = 
$(SAMPLES)/audio-reference/luckynight_2ch_44kHz_s16.wav
 fate-aac-tns-encode: CMP_SHIFT = -4096
 fate-aac-tns-encode: CMP_TARGET = 817
-fate-aac-tns-encode: FUZZ = 6
+fate-aac-tns-encode: FUZZ = 7
 fate-aac-tns-encode: SIZE_TOLERANCE = 3560
 
 FATE_AAC_ENCODE += fate-aac-is-encode
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] [RFC] get_bits: Support max_depth > 2 in GET_RL_VLC_INTERNAL

[Kieran Kunhya]

---
 libavcodec/get_bits.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index 0d3db1f..0a61c80 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -539,6 +539,17 @@ void ff_free_vlc(VLC *vlc);
 index = SHOW_UBITS(name, gb, nb_bits) + level;  \
 level = table[index].level; \
 n = table[index].len;   \
+if (max_depth > 2 && n < 0) {   \
+LAST_SKIP_BITS(name, gb, nb_bits);  \
+if (need_update) {  \
+UPDATE_CACHE(name, gb); \
+}   \
+nb_bits = -n;   \
+\
+index = SHOW_UBITS(name, gb, nb_bits) + level;  \
+level = table[index].level; \
+n = table[index].len;   \
+}   \
 }   \
 run = table[index].run; \
 SKIP_BITS(name, gb, n); \
-- 
1.9.1

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: New patch for palettized QuickTime video (old one broken)

[Mats Peterson]

On 12/13/2015 08:48 PM, Mats Peterson wrote:

I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't discover it until I tried one with
audio as well (all the samples so far are video only).

Mats



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



I forgot to restore the lower limit of A_QUICKTIME private data to 21 
like Michael Niedermayer proposed. Sorry (it doesn't make much sense to 
me, but at least that broken file will pass.)


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] matroskadec.c: New patch for palettized QuickTime video (old one broken)

[Mats Peterson]

On 12/13/2015 09:16 PM, Mats Peterson wrote:

On 12/13/2015 09:05 PM, Mats Peterson wrote:

On 12/13/2015 09:02 PM, Mats Peterson wrote:

On 12/13/2015 08:48 PM, Mats Peterson wrote:

I just discovered that I've been incorrectly using the "i" loop
variable
in my patch, which is actually used by a track element loop at line
1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't discover it until I tried one with
audio as well (all the samples so far are video only).

Mats



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



I forgot to restore the lower limit of A_QUICKTIME private data to 21
like Michael Niedermayer proposed. Sorry (it doesn't make much sense to
me, but at least that broken file will pass.)

Mats



V_QUICKTIME (video) of course, not A_QUICKTIME.

Mats



Well, probably it will NOT pass, since I'm looking for the bit depth at
offset 82 of the private data, which will of course be a totally bogus
value with a private data size of 21. Oh well...

Mats



In any case, I've uploaded a sample file with both palettized video 
(Apple Graphics/SMC) and PCM audio called "montage.mkv" to both 
http://matsp888.no-ip.org/~mats/qtpalette-test and http://bit.ly/1I1Bw2I .


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ganesh Ajjanagadde]

fma is a faster function on architectures supporting a native CPU instruction 
for it.
This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
in the x86 lineup this came fairly late
(from Haswell onwards, and hence is absent unless appropriate -march is passed),
numerous other architectures support it: 
https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation.

Concretely, one can expect ~ 15-25% speedup that is of course heavily
architecture dependent.

This patch also ensures that as people migrate to newer CPU's, the
benefit will slowly trickle in.

I doubt this will cause build failures on broken libm's since I can't
imagine a platform where FP_FAST_FMA is defined but the function fma is
absent.

Sample benchmark (x86-64, Haswell, GNU/Linux under -march=native)

old:
515828458 decicycles in build_filter (loop 1000),1024 runs,  0 skips

new (fma):
435866377 decicycles in build_filter (loop 1000),1024 runs,  0 skips

Tested with FATE.

Signed-off-by: Ganesh Ajjanagadde 
---
 libswresample/resample.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libswresample/resample.c b/libswresample/resample.c
index 34eb4c0..e61d4c5 100644
--- a/libswresample/resample.c
+++ b/libswresample/resample.c
@@ -33,8 +33,12 @@ static inline double eval_poly(const double *coeff, int 
size, double x) {
 double sum = coeff[size-1];
 int i;
 for (i = size-2; i >= 0; --i) {
+#ifdef FP_FAST_FMA
+sum = fma(sum, x, coeff[i]);
+#else
 sum *= x;
 sum += coeff[i];
+#endif
 }
 return sum;
 }
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] matroskadec.c: New patch for palettized QuickTime video (old one broken)

[Mats Peterson]

On 12/13/2015 09:05 PM, Mats Peterson wrote:

On 12/13/2015 09:02 PM, Mats Peterson wrote:

On 12/13/2015 08:48 PM, Mats Peterson wrote:

I just discovered that I've been incorrectly using the "i" loop variable
in my patch, which is actually used by a track element loop at line 1718
in matroskadec.c. This will works as long as there is only video in the
Matroska file, that's why I didn't discover it until I tried one with
audio as well (all the samples so far are video only).

Mats



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



I forgot to restore the lower limit of A_QUICKTIME private data to 21
like Michael Niedermayer proposed. Sorry (it doesn't make much sense to
me, but at least that broken file will pass.)

Mats



V_QUICKTIME (video) of course, not A_QUICKTIME.

Mats



Well, probably it will NOT pass, since I'm looking for the bit depth at 
offset 82 of the private data, which will of course be a totally bogus 
value with a private data size of 21. Oh well...


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] exr: fix out of bounds read in get_code

[Andreas Cadhalpun]

This macro unconditionally used out[-1], which causes an out of bounds
read, if out is the very beginning of the buffer.

Signed-off-by: Andreas Cadhalpun 
---
 libavcodec/exr.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 86a9908..cf28374 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -461,7 +461,7 @@ static int huf_build_dec_table(const uint64_t *hcode, int 
im,
 lc += 8;  \
 }
 
-#define get_code(po, rlc, c, lc, gb, out, oe) \
+#define get_code(po, rlc, c, lc, gb, out, oe, outb)   \
 { \
 if (po == rlc) {  \
 if (lc < 8)   \
@@ -470,7 +470,7 @@ static int huf_build_dec_table(const uint64_t *hcode, int 
im,
   \
 cs = c >> lc; \
   \
-if (out + cs > oe)\
+if (out + cs > oe || out == outb) \
 return AVERROR_INVALIDDATA;   \
   \
 s = out[-1];  \
@@ -503,7 +503,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
*hdecod,
 
 if (pl.len) {
 lc -= pl.len;
-get_code(pl.lit, rlc, c, lc, gb, out, oe);
+get_code(pl.lit, rlc, c, lc, gb, out, oe, outb);
 } else {
 int j;
 
@@ -520,7 +520,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
*hdecod,
 if ((hcode[pl.p[j]] >> 6) ==
 ((c >> (lc - l)) & ((1LL << l) - 1))) {
 lc -= l;
-get_code(pl.p[j], rlc, c, lc, gb, out, oe);
+get_code(pl.p[j], rlc, c, lc, gb, out, oe, outb);
 break;
 }
 }
@@ -541,7 +541,7 @@ static int huf_decode(const uint64_t *hcode, const HufDec 
*hdecod,
 
 if (pl.len) {
 lc -= pl.len;
-get_code(pl.lit, rlc, c, lc, gb, out, oe);
+get_code(pl.lit, rlc, c, lc, gb, out, oe, outb);
 } else {
 return AVERROR_INVALIDDATA;
 }
-- 
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] golomb: always check for invalid UE golomb codes in get_ue_golomb

[Michael Niedermayer]

On Sun, Dec 13, 2015 at 09:56:06PM +0100, Andreas Cadhalpun wrote:
> Also correct the check to reject log < 7, because UPDATE_CACHE only
> guarantees 25 meaningful bits.
> 
> This fixes undefined behavior:
> runtime error: shift exponent is negative
> 
> Testing with START/STOP timers in get_ue_golomb, one for the first
> branch (A) and one for the second (B), shows that there is practically no
> slowdown, e.g. for the cavs decoder:
> 
> With the check in the B branch:
> 629 decicycles in get_ue_golomb B, 4194260 runs, 44 skips
> 433 decicycles in get_ue_golomb A,268434102 runs,   1354 skips
> 
> Without the check:
> 624 decicycles in get_ue_golomb B, 4194273 runs, 31 skips
> 433 decicycles in get_ue_golomb A,268434203 runs,   1253 skips
> 
> Since the B branch is executed far less often than the A branch, this
> change is negligible, even more so for the h264 decoder, where the ratio
> B/A is a lot smaller.
> 
> Fixes: mozilla bug 1229208
> Fixes: 
> fbeb8b2c7c996e9b91c6b1af319d7ebc/asan_heap-oob_195450f_2743_e8856ece4579ea486670be2b236099a0.bit
> 
> Found-by: Tyson Smith
> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
> Signed-off-by: Andreas Cadhalpun 
> ---
> 
> Note that I just copied the "Fixes:" lines from Michael's patch, but actually
> I don't know what mozilla bug 1229208 is about, as it seems not to be public.
> Also I don't have the mentioned sample, but the patch fixes more than 1000
> of my fuzzed samples that triggered this ubsan error, so I'm confident the
> mentioned one is also fixed.

actually i think the bug number is
"Bug 1230239 - FFMPEG: shift exponent is negative in [@get_ue_golomb] "

patch should be ok

and iam also not happy about the bugs being non public
i tried unchecking "Security-Sensitive Media Bug" but i seem not to
have the power to do that but its quite possibly iam doing something
wrong

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

I am the wisest man alive, for I know one thing, and that is that I know
nothing. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] opus_silk: fix out of array read in silk_lsf2lpc

[Michael Niedermayer]

On Sun, Dec 13, 2015 at 10:51:31PM +0100, Andreas Cadhalpun wrote:
> nlsf can be negative, but a negative index for silk_cosine doesn't work.
> ---
>  libavcodec/opus_silk.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/opus_silk.c b/libavcodec/opus_silk.c
> index 841d1ed..3ac83b8 100644
> --- a/libavcodec/opus_silk.c
> +++ b/libavcodec/opus_silk.c
> @@ -941,7 +941,7 @@ static void silk_lsf2lpc(const int16_t nlsf[16], float 
> lpcf[16], int order)
>  
>  /* convert the LSFs to LSPs, i.e. 2*cos(LSF) */
>  for (k = 0; k < order; k++) {
> -int index = nlsf[k] >> 8;
> +int index = FFABS(nlsf[k]) >> 8;
>  int offset = nlsf[k] & 255;

this looks a bit strange

if nlsf[] is allowed to be negative then i would have expected that
both nlsf[] would use the absolute value or if its nt allowed to be
negative then why is it ?

does the spec explain what should be done in this case ?
if not, its authors may want to amend it to clarify if this is
invalid or undefined or something specific should be done

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

There will always be a question for which you do not know the correct answer.


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

Re: [FFmpeg-devel] HLS webVtt in unfavorable conditions

[Michael Niedermayer]

On Sun, Dec 13, 2015 at 08:52:54PM +0530, Anshul wrote:
> Hello,
> 
> Its regarding ticket #5067(avformat:open): crash on Mapping
> Multicast TV Stream to HLS with "Exactly one WebVTT stream is
> needed" as message
> 
> I have attached patch for hls not failing in condition where
> subtitles streams are of bitmap type and ts containing data streams
> mapped to output.
> 
> But this patch have side effect, that user is not warned that stream
> that are shown as mapped in logs are actually ignored by hls
> segmeter.
> 

> I have not added errors/warning about ignoring streams, since I was
> unable to decide whether they should be warning or error.

i think muxers should error out when the users tries to mux a stream
that they cannot support

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ronald S. Bultje]

Hi,

On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde 
wrote:

> fma is a faster function on architectures supporting a native CPU
> instruction for it.
> This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
> in the x86 lineup this came fairly late
> (from Haswell onwards, and hence is absent unless appropriate -march is
> passed),
> numerous other architectures support it:
> https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation.
>
> Concretely, one can expect ~ 15-25% speedup that is of course heavily
> architecture dependent.
>
> This patch also ensures that as people migrate to newer CPU's, the
> benefit will slowly trickle in.
>
> I doubt this will cause build failures on broken libm's since I can't
> imagine a platform where FP_FAST_FMA is defined but the function fma is
> absent.
>
> Sample benchmark (x86-64, Haswell, GNU/Linux under -march=native)
>
> old:
> 515828458 decicycles in build_filter (loop 1000),1024 runs,  0
> skips
>
> new (fma):
> 435866377 decicycles in build_filter (loop 1000),1024 runs,  0
> skips
>
> Tested with FATE.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libswresample/resample.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libswresample/resample.c b/libswresample/resample.c
> index 34eb4c0..e61d4c5 100644
> --- a/libswresample/resample.c
> +++ b/libswresample/resample.c
> @@ -33,8 +33,12 @@ static inline double eval_poly(const double *coeff, int
> size, double x) {
>  double sum = coeff[size-1];
>  int i;
>  for (i = size-2; i >= 0; --i) {
> +#ifdef FP_FAST_FMA
> +sum = fma(sum, x, coeff[i]);
> +#else
>  sum *= x;
>  sum += coeff[i];
> +#endif
>  }
>  return sum;
>  }
> --
> 2.6.4


Nope, this is not how we do CPU-specific optimizations. Check example
implementations in libswresample/x86/*.asm and the related init functions
plus macros to check for runtime cpu support in libswresample/x86/*_init.c.
You want to follow that pattern.

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

Re: [FFmpeg-devel] [PATCH] fate: increase FUZZ by 1 for aac-tns-encode

[Rostislav Pehlivanov]

On Sun, 2015-12-13 at 22:24 +0100, Andreas Cadhalpun wrote:
> This should fix this test failing on kfreebsd, a regression since
> 6e5dbe7, which decreased the CMP_TARGET by 1.
> 
> Signed-off-by: Andreas Cadhalpun 

LGTM,

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

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[James Almer]

On 12/13/2015 8:08 PM, Ganesh Ajjanagadde wrote:
> On Sun, Dec 13, 2015 at 5:55 PM, Ganesh Ajjanagadde
>  wrote:
>> On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje  wrote:
>>> Hi,
>>>
>>> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde 
>>> wrote:

 fma is a faster function on architectures supporting a native CPU
 instruction for it.
 This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
 in the x86 lineup this came fairly late
 (from Haswell onwards, and hence is absent unless appropriate -march is
 passed),
 numerous other architectures support it:
 https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation.

 Concretely, one can expect ~ 15-25% speedup that is of course heavily
 architecture dependent.

 This patch also ensures that as people migrate to newer CPU's, the
 benefit will slowly trickle in.

 I doubt this will cause build failures on broken libm's since I can't
 imagine a platform where FP_FAST_FMA is defined but the function fma is
 absent.

 Sample benchmark (x86-64, Haswell, GNU/Linux under -march=native)

 old:
 515828458 decicycles in build_filter (loop 1000),1024 runs,  0
 skips

 new (fma):
 435866377 decicycles in build_filter (loop 1000),1024 runs,  0
 skips

 Tested with FATE.

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  libswresample/resample.c | 4 
  1 file changed, 4 insertions(+)

 diff --git a/libswresample/resample.c b/libswresample/resample.c
 index 34eb4c0..e61d4c5 100644
 --- a/libswresample/resample.c
 +++ b/libswresample/resample.c
 @@ -33,8 +33,12 @@ static inline double eval_poly(const double *coeff, int
 size, double x) {
  double sum = coeff[size-1];
  int i;
  for (i = size-2; i >= 0; --i) {
 +#ifdef FP_FAST_FMA
 +sum = fma(sum, x, coeff[i]);
 +#else
  sum *= x;
  sum += coeff[i];
 +#endif
  }
  return sum;
  }
 --
 2.6.4
>>>
>>>
>>> Nope, this is not how we do CPU-specific optimizations. Check example
>>> implementations in libswresample/x86/*.asm and the related init functions
>>> plus macros to check for runtime cpu support in libswresample/x86/*_init.c.
>>> You want to follow that pattern.
>>
>> No, this is not x86 specific. This is generic code. If I did such a
>> maneouver, benefits would apply only to x86, an inferior outcome.
> 
> To clarify: yes, in theory one could dump such things into
> swresample/x86, swresample/aarch64, and a ton of other architectures
> (for which some arches are actually lacking). Such a diff is far
> larger and more brittle - I can't even test things like mips and the
> like, and looking up the manuals for each and every one of these to
> find out when/what is the fma equivalent is a pain in the neck.
> 
> ISO C provides a mechanism, albeit build-time and not runtime detection.
> 
> This patch is thus something that gives benefits at minimal scope for
> regressions. Unless others show where/how fma detection can be done
> for all arches (aarch64, arm, mips, powerpc, itanium, etc in addition
> to x86-64), I view your idea as future work.

FP_FAST_FMA is apparently not defined on mingw-w64 even though it supports
fma() and generates FMA3/4 instructions when targeting relevant CPUs.

I also noticed that GCC will on x86_32 generate a call to an external fma
function instead of inlining the relevant FMA3/4 instructions, same as it
does when the target lacks fast fma instructions, so simply checking the
target CPU is not enough. On said builds this patch will probably mean a
slowdown. No idea what GCC does with other arches.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: increase FUZZ by 1 for aac-tns-encode

[Andreas Cadhalpun]

On 13.12.2015 23:20, Rostislav Pehlivanov wrote:
> On Sun, 2015-12-13 at 22:24 +0100, Andreas Cadhalpun wrote:
>> This should fix this test failing on kfreebsd, a regression since
>> 6e5dbe7, which decreased the CMP_TARGET by 1.
>>
>> Signed-off-by: Andreas Cadhalpun 
> 
> LGTM,

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ganesh Ajjanagadde]

On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> fma is a faster function on architectures supporting a native CPU
>> instruction for it.
>> This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
>> in the x86 lineup this came fairly late
>> (from Haswell onwards, and hence is absent unless appropriate -march is
>> passed),
>> numerous other architectures support it:
>> https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation.
>>
>> Concretely, one can expect ~ 15-25% speedup that is of course heavily
>> architecture dependent.
>>
>> This patch also ensures that as people migrate to newer CPU's, the
>> benefit will slowly trickle in.
>>
>> I doubt this will cause build failures on broken libm's since I can't
>> imagine a platform where FP_FAST_FMA is defined but the function fma is
>> absent.
>>
>> Sample benchmark (x86-64, Haswell, GNU/Linux under -march=native)
>>
>> old:
>> 515828458 decicycles in build_filter (loop 1000),1024 runs,  0
>> skips
>>
>> new (fma):
>> 435866377 decicycles in build_filter (loop 1000),1024 runs,  0
>> skips
>>
>> Tested with FATE.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libswresample/resample.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libswresample/resample.c b/libswresample/resample.c
>> index 34eb4c0..e61d4c5 100644
>> --- a/libswresample/resample.c
>> +++ b/libswresample/resample.c
>> @@ -33,8 +33,12 @@ static inline double eval_poly(const double *coeff, int
>> size, double x) {
>>  double sum = coeff[size-1];
>>  int i;
>>  for (i = size-2; i >= 0; --i) {
>> +#ifdef FP_FAST_FMA
>> +sum = fma(sum, x, coeff[i]);
>> +#else
>>  sum *= x;
>>  sum += coeff[i];
>> +#endif
>>  }
>>  return sum;
>>  }
>> --
>> 2.6.4
>
>
> Nope, this is not how we do CPU-specific optimizations. Check example
> implementations in libswresample/x86/*.asm and the related init functions
> plus macros to check for runtime cpu support in libswresample/x86/*_init.c.
> You want to follow that pattern.

No, this is not x86 specific. This is generic code. If I did such a
maneouver, benefits would apply only to x86, an inferior outcome.

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

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ganesh Ajjanagadde]

On Sun, Dec 13, 2015 at 5:55 PM, Ganesh Ajjanagadde
 wrote:
> On Sun, Dec 13, 2015 at 5:47 PM, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Sun, Dec 13, 2015 at 4:59 PM, Ganesh Ajjanagadde 
>> wrote:
>>>
>>> fma is a faster function on architectures supporting a native CPU
>>> instruction for it.
>>> This may be tested by the ISO C optionally defined FP_FAST_FMA. Although
>>> in the x86 lineup this came fairly late
>>> (from Haswell onwards, and hence is absent unless appropriate -march is
>>> passed),
>>> numerous other architectures support it:
>>> https://en.wikipedia.org/wiki/Multiply%E2%80%93accumulate_operation.
>>>
>>> Concretely, one can expect ~ 15-25% speedup that is of course heavily
>>> architecture dependent.
>>>
>>> This patch also ensures that as people migrate to newer CPU's, the
>>> benefit will slowly trickle in.
>>>
>>> I doubt this will cause build failures on broken libm's since I can't
>>> imagine a platform where FP_FAST_FMA is defined but the function fma is
>>> absent.
>>>
>>> Sample benchmark (x86-64, Haswell, GNU/Linux under -march=native)
>>>
>>> old:
>>> 515828458 decicycles in build_filter (loop 1000),1024 runs,  0
>>> skips
>>>
>>> new (fma):
>>> 435866377 decicycles in build_filter (loop 1000),1024 runs,  0
>>> skips
>>>
>>> Tested with FATE.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libswresample/resample.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libswresample/resample.c b/libswresample/resample.c
>>> index 34eb4c0..e61d4c5 100644
>>> --- a/libswresample/resample.c
>>> +++ b/libswresample/resample.c
>>> @@ -33,8 +33,12 @@ static inline double eval_poly(const double *coeff, int
>>> size, double x) {
>>>  double sum = coeff[size-1];
>>>  int i;
>>>  for (i = size-2; i >= 0; --i) {
>>> +#ifdef FP_FAST_FMA
>>> +sum = fma(sum, x, coeff[i]);
>>> +#else
>>>  sum *= x;
>>>  sum += coeff[i];
>>> +#endif
>>>  }
>>>  return sum;
>>>  }
>>> --
>>> 2.6.4
>>
>>
>> Nope, this is not how we do CPU-specific optimizations. Check example
>> implementations in libswresample/x86/*.asm and the related init functions
>> plus macros to check for runtime cpu support in libswresample/x86/*_init.c.
>> You want to follow that pattern.
>
> No, this is not x86 specific. This is generic code. If I did such a
> maneouver, benefits would apply only to x86, an inferior outcome.

To clarify: yes, in theory one could dump such things into
swresample/x86, swresample/aarch64, and a ton of other architectures
(for which some arches are actually lacking). Such a diff is far
larger and more brittle - I can't even test things like mips and the
like, and looking up the manuals for each and every one of these to
find out when/what is the fma equivalent is a pain in the neck.

ISO C provides a mechanism, albeit build-time and not runtime detection.

This patch is thus something that gives benefits at minimal scope for
regressions. Unless others show where/how fma detection can be done
for all arches (aarch64, arm, mips, powerpc, itanium, etc in addition
to x86-64), I view your idea as future work.

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

Re: [FFmpeg-devel] [PATCH] swr/resample: use fma when it is faster

[Ganesh Ajjanagadde]

On Sun, Dec 13, 2015 at 6:55 PM, James Almer  wrote:
[...]
>
> FP_FAST_FMA is apparently not defined on mingw-w64 even though it supports
> fma() and generates FMA3/4 instructions when targeting relevant CPUs.

Guess some implementer took the "optional" literally and decided not to bother.

>
> I also noticed that GCC will on x86_32 generate a call to an external fma
> function instead of inlining the relevant FMA3/4 instructions, same as it
> does when the target lacks fast fma instructions, so simply checking the
> target CPU is not enough. On said builds this patch will probably mean a
> slowdown. No idea what GCC does with other arches.

I have tested the slowdown myself by avoiding the -march; it gives
numbers around 60 as opposed to the current 50 (or 40 with a proper
fma). Thus, an ~ 20% slowdown.

This is yet more broken stuff, and it really should be fixed upstream.
But until then, we need to work around it or not bother at all.

The trouble of runtime cpu detection is that if we want fma support,
we will have to write assembly here as far as I can tell: a generic
fma() call will be compiled into a slow libm call that emulates the
fma using some combination of instructions on default compiler
settings.

The worst part is that it is a bad idea to do runtime dispatch on the
fma() itself, as the function call overhead will be nonneglible, and
so one can't create a helper API in avutil or elsewhere. Thus, it can
only be used when a function is in a critical hotspot, where the
duplication of code and maintainence burden can be justified for the
performance benefits. I might be missing something here though.

In summary: fma's are very useful for obtaining performance even at
the level of C code across FFmpeg. Unfortunately, due to other issues,
it seems like their application can only be targeted at very specific,
high-profile instances.

Patch dropped; a clean solution for getting fma into various regions
of the C codebase is beyond my understanding.

Thanks all.
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Parse stsd atom in mkv with the appropriate mov function

[Mats Peterson]

On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:

Hi!

Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071 for me.
I can't see how duplicating the code from mov.c could be acceptable.

Please comment, Carl Eugen



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



If you look at the patch I've made, it's not DUPLICATING the code, it 
BORROWS some of code for the loops, but they are modified as well, if 
you look closely, and it uses the PRIVATE DATA instead of calling some 
superfluous stsd atom parsing function that reads from the file. I hope 
Michael Niedermayer understands this better than you do, at least.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Parse stsd atom in mkv with the appropriate mov function

[Mats Peterson]

On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:

Hi!

Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071 for me.
I can't see how duplicating the code from mov.c could be acceptable.

Please comment, Carl Eugen



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



You can't? Then why did Hendryk tell me that calling code in another 
demuxer was a bad idea? That's why I changed the whole thing. And it IS 
a bad idea, since that code in mov.c is reading from the FILE, which is 
totally overkill when you already have the private data to work with. 
It's not up to you to decide this, please leave it to someone who knows 
the issue better than you.


Mats
--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc set slice number to 1 to improve encoding quality and clamp initial qp value to [1, 51]

[Agatha Hu]

On 2015/12/11 17:20, Timo Rothenpieler wrote:

* PGP Signed by an unknown key


Hi all, before switching to the new released nvenc6.0 header, can you
take a look at this fix?


I'm fine with making it the default, the only concern i have is weather
it has any side-effects, like reduced performance that impacts some
higher resolutions which can't be encoded in realtime anymore.

If that's not the case, this LGTM.

No, it won't affect performance, we did lots of internal tests, mainly 
focused on quality improvement. But if it makes performance worse we 
won't apply it anyway.


Agatha Hu

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

Re: [FFmpeg-devel] [PATCH]lavf/matroskadec: Parse stsd atom in mkv with the appropriate mov function

[Mats Peterson]

On 12/14/2015 06:32 AM, Mats Peterson wrote:

On 12/14/2015 03:40 AM, Carl Eugen Hoyos wrote:

Hi!

Attached patch based on 3ece3e4c by Martin Storsjö fixes ticket #5071
for me.
I can't see how duplicating the code from mov.c could be acceptable.

Please comment, Carl Eugen



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



If you look at the patch I've made, it's not DUPLICATING the code, it
BORROWS some of code for the loops, but they are modified as well, if
you look closely, and it uses the PRIVATE DATA instead of calling some
superfluous stsd atom parsing function that reads from the file. I hope
Michael Niedermayer understands this better than you do, at least.

Mats



And even if your patch will be the one to use (against all odds), it is 
still lacking the code that puts the palette in extradata, a la 
V_MS/VFW/FOURCC. Without it, MPlayer won't see the palette.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel