Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

2017-01-31 Thread Jerry Jiang
Fixed patch issue.

> It seems that "mjpeg-trell-qprd-huffman" is missing here.

Removed the test instead since it's supposed to error.

---
 Changelog|   1 +
 doc/encoders.texi|  21 ++
 libavcodec/Makefile  |   8 +-
 libavcodec/mjpegenc.c| 241 +--
 libavcodec/mjpegenc.h|  68 ++-
 libavcodec/mjpegenc_common.c | 166 ++--
 libavcodec/mjpegenc_common.h |   2 +
 libavcodec/mjpegenc_huffman.c| 195 ++
 libavcodec/mjpegenc_huffman.h|  74 +++
 libavcodec/mpegvideo.h   |   1 +
 libavcodec/mpegvideo_enc.c   |  17 +-
 libavcodec/tests/.gitignore  |   1 +
 libavcodec/tests/mjpegenc_huffman.c  | 163 +++
 tests/fate/libavcodec.mak|   6 +
 tests/fate/vcodec.mak|  12 +-
 tests/ref/vsynth/vsynth1-mjpeg-444   |   8 +-
 tests/ref/vsynth/vsynth1-mjpeg-huffman   |   4 +
 tests/ref/vsynth/vsynth1-mjpeg-trell-huffman |   4 +
 tests/ref/vsynth/vsynth2-mjpeg-huffman   |   4 +
 tests/ref/vsynth/vsynth2-mjpeg-trell-huffman |   4 +
 tests/ref/vsynth/vsynth3-mjpeg-huffman   |   4 +
 tests/ref/vsynth/vsynth3-mjpeg-trell-huffman |   4 +
 tests/ref/vsynth/vsynth_lena-mjpeg-huffman   |   4 +
 tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman |   4 +
 24 files changed, 916 insertions(+), 100 deletions(-)
 create mode 100644 libavcodec/mjpegenc_huffman.c
 create mode 100644 libavcodec/mjpegenc_huffman.h
 create mode 100644 libavcodec/tests/mjpegenc_huffman.c
 create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-huffman
 create mode 100644 tests/ref/vsynth/vsynth1-mjpeg-trell-huffman
 create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-huffman
 create mode 100644 tests/ref/vsynth/vsynth2-mjpeg-trell-huffman
 create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-huffman
 create mode 100644 tests/ref/vsynth/vsynth3-mjpeg-trell-huffman
 create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-huffman
 create mode 100644 tests/ref/vsynth/vsynth_lena-mjpeg-trell-huffman

diff --git a/Changelog b/Changelog
index c256121..4d5daca 100644
--- a/Changelog
+++ b/Changelog
@@ -18,6 +18,7 @@ version :
 - readeia608 filter
 - Sample Dump eXchange demuxer
 - abitscope multimedia filter
+- Optimal Huffman tables for (M)JPEG encoding
 
 version 3.2:
 - libopenmpt demuxer
diff --git a/doc/encoders.texi b/doc/encoders.texi
index 8137465..2026a9f 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1200,6 +1200,27 @@ Same as @samp{3}, but with extra processing enabled.
 @end table
 @end table
 
+@anchor{mjpegenc}
+@section mjpeg
+
+Motion JPEG encoder.
+
+@subsection Options
+
+@table @option
+@item huffman
+Set the huffman encoding strategy. Possible values:
+
+@table @samp
+@item default
+Use the default huffman tables. This is the default strategy.
+
+@item optimal
+Compute and use optimal huffman tables.
+
+@end table
+@end table
+
 @anchor{wavpackenc}
 @section wavpack
 
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..4765e9c 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -39,6 +39,7 @@ OBJS = allcodecs.o
  \
mediacodec.o \
mpeg12framerate.o\
options.o\
+   mjpegenc_huffman.o   \
parser.o \
profiles.o   \
qsv_api.o\
@@ -175,7 +176,8 @@ OBJS-$(CONFIG_AMRWB_DECODER)   += amrwbdec.o 
celp_filters.o   \
   celp_math.o acelp_filters.o \
   acelp_vectors.o \
   acelp_pitch_delay.o
-OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o mjpegenc_common.o
+OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o mjpegenc_common.o \
+  mjpegenc_huffman.o
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
@@ -377,7 +379,8 @@ OBJS-$(CONFIG_METASOUND_DECODER)   += metasound.o 
metasound_data.o \
 OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
 OBJS-$(CONFIG_MIMIC_DECODER)   += mimic.o
 OBJS-$(CONFIG_MJPEG_DECODER)   += mjpegdec.o
-OBJS-$(CONFIG_MJPEG_ENCODER)   += mjpegenc.o 

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-01-31 Thread Chrome Cunningham
On Tuesday, January 31, 2017, Chris Cunningham 
wrote:

>
> On Tue, Jan 31, 2017 at 1:07 AM, wm4  > wrote:
>
>> On Tue, 31 Jan 2017 09:57:24 +0100
>> wm4 > > wrote:
>>
>> > On Mon, 30 Jan 2017 17:05:49 -0800
>> > Chris Cunningham > > wrote:
>> >
>> > > Blocks are marked as key frames whenever the "reference" field is
>> > > zero. This is incorrect for non-keyframe Blocks that take a refernce
>> > > on a keyframe at time zero.
>> > >
>> > > Now using -1 to denote "no reference".
>> > >
>> > > Reported to chromium at http://crbug.com/497889 (contains sample)
>> > > ---
>> > >  libavformat/matroskadec.c | 9 ++---
>> > >  1 file changed, 6 insertions(+), 3 deletions(-)
>> > >
>> > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> > > index e6737a70b2..0d033b574c 100644
>> > > --- a/libavformat/matroskadec.c
>> > > +++ b/libavformat/matroskadec.c
>> > > @@ -89,6 +89,7 @@ typedef const struct EbmlSyntax {
>> > >  int list_elem_size;
>> > >  int data_offset;
>> > >  union {
>> > > +int64_t i;
>> > >  uint64_tu;
>> > >  double  f;
>> > >  const char *s;
>> > > @@ -696,7 +697,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
>> > >  { MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0,
>> offsetof(MatroskaBlock, bin) },
>> > >  { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0,
>> offsetof(MatroskaBlock, duration) },
>> > >  { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0,
>> offsetof(MatroskaBlock, discard_padding) },
>> > > -{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0,
>> offsetof(MatroskaBlock, reference) },
>> > > +{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0,
>> offsetof(MatroskaBlock, reference), { .i = -1 } },
>> > >  { MATROSKA_ID_CODECSTATE, EBML_NONE },
>> > >  {  1, EBML_UINT, 0,
>> offsetof(MatroskaBlock, non_simple), { .u = 1 } },
>> > >  { 0 }
>> > > @@ -1071,6 +1072,8 @@ static int ebml_parse_nest(MatroskaDemuxContext
>> *matroska, EbmlSyntax *syntax,
>> > >
>> > >  for (i = 0; syntax[i].id; i++)
>> > >  switch (syntax[i].type) {
>> > > +case EBML_SINT:
>> > > +*(int64_t *) ((char *) data + syntax[i].data_offset) =
>> syntax[i].def.i;
>> > >  case EBML_UINT:
>> >
>> > Isn't there a break missing?
>> >
>> > >  *(uint64_t *) ((char *) data + syntax[i].data_offset) =
>> syntax[i].def.u;
>> > >  break;
>> > > @@ -3361,7 +3364,7 @@ static int 
>> > > matroska_parse_cluster_incremental(MatroskaDemuxContext
>> *matroska)
>> > >  matroska->current_cluster_num_blocks = blocks_list->nb_elem;
>> > >  i= blocks_list->nb_elem
>> - 1;
>> > >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
>> > > -int is_keyframe = blocks[i].non_simple ?
>> !blocks[i].reference : -1;
>> > > +int is_keyframe = blocks[i].non_simple ?
>> blocks[i].reference == -1 : -1;
>> > >  uint8_t* additional = blocks[i].additional.size > 0 ?
>> > >  blocks[i].additional.data : NULL;
>> > >  if (!blocks[i].non_simple)
>> > > @@ -3399,7 +3402,7 @@ static int 
>> > > matroska_parse_cluster(MatroskaDemuxContext
>> *matroska)
>> > >  blocks  = blocks_list->elem;
>> > >  for (i = 0; i < blocks_list->nb_elem; i++)
>> > >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
>> > > -int is_keyframe = blocks[i].non_simple ?
>> !blocks[i].reference : -1;
>> > > +int is_keyframe = blocks[i].non_simple ?
>> blocks[i].reference == -1 : -1;
>> > >  res = matroska_parse_block(matroska, blocks[i].bin.data,
>> > > blocks[i].bin.size,
>> blocks[i].bin.pos,
>> > > cluster.timecode,
>> blocks[i].duration,
>> >
>> > I don't quite trust this. The file has negative block references too
>> > (what do they even mean?). E.g. one block uses "-123". This doesn't
>> > make much sense to me, and at the very least it means -1 is not a safe
>> > dummy value (because negative values don't mean non-keyframe according
>> > to your patch, while -1 as exception does).
>> >
>> > The oldest/most used (until recently at least) mkv demuxer, Haali
>> > actually does every block reference element as a non-keyframe:
>> >
>> > http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/
>> MatroskaParser.c;h=173c2e1c20da59d4cf0b501639c470331cd4515f;hb=HEAD#l2354
>> >
>> > This seems much safer.
>> >
>> > Do you have any insight why the file contains such erratic seeming
>> > reference values? I'm sure I'm missing something. Or is it a broken
>> > muxer/broken 

Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Jean-Baptiste Kempf
Hello,

On Wed, 1 Feb 2017, at 05:14, compn wrote:
> videolan has been having trouble with it for a while. you can see posts
> on the internet complaining about the automatic vlc bug reporter also
> being down because of this.

Not at all. Those are 2 complete different services and streams is
working fine since quite a bit of time.


-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] [rfc] web/index request incoming ftp server

2017-01-31 Thread wm4
On Wed, 1 Feb 2017 00:09:41 -0500
compn  wrote:

> not sure if this is the right way to do it, maybe its easier to ask for
> someone on twitter?
> 
> it would be nice to have a backup just in case videolan has problems.
> then we dont have to ask users to use datafilehost heh.
> 
> i dont want to burden ffmpeg admins to maintain some ftp either.
> 
> carl, what do you think?
> ideas welcome.
> 
> -compn

Who maintains this piece of infrastructure at all?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 22:12:24 +0100
Timo Rothenpieler  wrote:

> > IIRC, past conversations on this have concluded that the 'avconv'
> > rewrite will allow this by
> > avoiding the current problem that the encoder is fully initialised up
> > front before the cuvid
> > parser can run. Presumably, at some point in the future, we'll get
> > through the merge backlog
> > and eventually get that in.
> > 
> > In the meantime, I'm ok with this change. In the cases where the format
> > is set correctly it
> > will help, and in the cases where it is not set, it will degrade to the
> > current behaviour.
> > As such it's strictly an improvement.
> >   
> 
> It will also not be an issue anymore once the new hw_device_ctx api
> lands, at which point I'll move the creation and handling of
> hw_frames_ctx entirely into cuvid.c.
> 
> Until that happens, this patch is fine with me as well.

Sure then. Although "temporary" hacks have a tendency not to remain
temporary, it's quite likely this will work out.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 12:02:01 -0800
Chris Cunningham  wrote:

> Thanks for taking a look.
> 
> Definitely missing a "break;" - will fix in subsequent patch.
> 
> Agree timestamps should be relative (didn't realize this). Vignesh points
> out that "0" in the test file is due to a bug in ffmpeg (and probably other
> muxers) where this value is not written as a relative timestamp, but
> instead as the timestamp of the previous frame. https://github.com/FFmp
> eg/FFmpeg/blob/master/libavformat/matroskaenc.c#L2053
> 

Just a few lines below this reads

   mkv->last_track_timestamp[track_number - 1] = ts - mkv->cluster_pts;

which looks like it intends to write a relative value. Though "ts" can
be a DTS, while the other value is always a PTS.

> Anyway, I'm all for following Haali. Its not obvious how best to do this. I
> don't think there's any great default value to indicate "not-set" and the
> generic embl parsing code that reads the reference timestamp doesn't really
> lend itself to setting an additional field like
> MatroskaBlock.has_reference. I can sort this out, but I'll pause in case
> you have a recommendation in-mind.

I don't know a nice way either. Here are 3 potential ways I came up
with:

1. Use a better dummy value, like INT64_MIN, which is almost 100%
   unlikely to appear in a valid file. (This is probably equivalent to
   your intention in original patch.)
2. Add a new "presence_flag_offset" field to EbmlSyntax - the EBML
   reader will write a 1 to it if the element was found. (This is a bit
   annoying, because 0 is a valid offset, and you surely wouldn't want
   to change all the other element definitions.)
3. Add a new type like EBML_PRESENCE, which writes whether the element
   was present or not to data_offset, instead of the element's content
   or its default value. (There are some other special "types" like
   EBML_STOP, so maybe this idea isn't all too hacky.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] [rfc] web/index request incoming ftp server

2017-01-31 Thread compn
not sure if this is the right way to do it, maybe its easier to ask for
someone on twitter?

it would be nice to have a backup just in case videolan has problems.
then we dont have to ask users to use datafilehost heh.

i dont want to burden ffmpeg admins to maintain some ftp either.

carl, what do you think?
ideas welcome.

-compndiff --git a/src/index b/src/index
index c203676..cf45f4f 100644
--- a/src/index
+++ b/src/index
@@ -37,6 +37,15 @@
 News
   
 
+  February 01, 2017, Backup ftp server needed.
+  
+We are in need of a ftp backup for users to upload sample files to us.
+Our current ftp, hosted by videolan, is still being worked on, with no ETA 
for a fix.
+  
+  
+What we need: public ftp with anonymous upload only, and authenticated 
read/downloads for developers.
+space a few TB, speed 1mb/s+. Nothing fancy. Please send mail to 
proje...@ffmpeg.org if you want to help.
+  
   October 30th, 2016, Results: Summer Of Code 
2016.
   
 This has been a long time coming but we wanted to give a proper closure to 
our participation in this run of the program and it takes time. Sometimes it's 
just to get the final report for each project trimmed down, others, is 
finalizing whatever was still in progress when the program finished: final 
patches need to be merged, TODO lists stabilized, future plans agreed; you name 
it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread compn
On Tue, 31 Jan 2017 13:09:07 +0100
Thilo Borgmann  wrote:

> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it
> is not the place to upload things then these messages should be
> changed accordingly and the preferred way to upload samples need to
> be documented.

currently upload.ffmpeg.org points to streams.videolan.org , videolan
is currently hosting our incoming ftp server access.

videolan has been having trouble with it for a while. you can see posts
on the internet complaining about the automatic vlc bug reporter also
being down because of this.

what we need is someone to run a small ftp drop for large files, i
guess i'll post a patch for the ffmpeg.org page requesting such hosting
temporarily.

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


[FFmpeg-devel] aac_latm: SSR is not implemented

2017-01-31 Thread Aman Gupta
I have a mpegts file with a HE-AAC audio track that cannot be decoded by
ffmpeg. I have uploaded a sample at the link below, as requested by the
decoder.

Happy to help with a patch to fix this issue, if someone can point me in
the right direction. FWIW, VLC is able to decode the audio without issue.

https://s3.amazonaws.com/tmm1/VasHD.mpg

Input #0, mpegts, from 'VasHD.mpg':
  Duration: 00:01:00.08, start: 39229.160467, bitrate: 9240 kb/s
  Program 5
Stream #0:0[0x208]: Video: h264 (High) ([27][0][0][0] / 0x001B),
yuv420p(tv, bt709, top first), 1920x1080 [SAR 1:1 DAR 16:9], 25 fps, 50
tbr, 90k tbn, 50 tbc
Stream #0:1[0x212](tam): Audio: aac_latm (HE-AAC) ([17][0][0][0] /
0x0011), 48000 Hz, 5.1, fltp
Stream #0:2[0x213]: Audio: aac_latm (HE-AAC) ([17][0][0][0] / 0x0011),
48000 Hz, stereo, fltp
Stream #0:3[0x21c](eng): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:4[0x21f](tam): Subtitle: dvb_subtitle ([6][0][0][0] / 0x0006)
Stream #0:5[0x244]: Unknown: none ([5][0][0][0] / 0x0005)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

2017-01-31 Thread Thomas Turner
The Chen-Shapiro(CS) test was used to test normality for
Lagged Fibonacci PRNG.

Normality Hypothesis Test:

The null hypothesis formally tests if the population
the sample represents is normally-distributed. For
CS, when the normality hypothesis is True, the
distribution of QH will have a mean close to 1.

Information on CS can be found here:

http://www.stata-journal.com/sjpdf.html?articlenum=st0264
http://www.originlab.com/doc/Origin-Help/NormalityTest-Algorithm

Signed-off-by: Thomas Turner 
---
 libavutil/tests/lfg.c| 125 +--
 tests/fate/libavutil.mak |   5 ++
 2 files changed, 104 insertions(+), 26 deletions(-)

diff --git a/libavutil/tests/lfg.c b/libavutil/tests/lfg.c
index 1425e02..645d39d 100644
--- a/libavutil/tests/lfg.c
+++ b/libavutil/tests/lfg.c
@@ -20,6 +20,59 @@
 #include "libavutil/timer.h"
 #include "libavutil/lfg.h"
 
+#define TEST1
+
+// Inverse cumulative distribution function
+static double inv_cdf(double u)
+{
+const double a[4] = { 2.50662823884,
+ -18.61500062529,
+  41.39119773534,
+ -25.44106049637};
+
+const double b[4] = {-8.47351093090,
+  23.08336743743,
+ -21.06224101826,
+   3.13082909833};
+
+const double c[9] = {0.3374754822726147,
+  0.9761690190917186,
+  0.1607979714918209,
+  0.0276438810333863,
+  0.0038405729373609,
+  0.0003951896511919,
+  0.321767881768,
+  0.002888167364,
+  0.003960315187};
+
+double r;
+double x = u - 0.5;
+
+// Beasley-Springer
+#if TEST == 0
+if (fabs(x) < 0.42) {
+#endif
+#if TEST == 1
+if (u > 0.08 && u < 0.92) {
+#endif
+double y = x * x;
+r= x * (((a[3]*y+a[2])*y+a[1])*y+a[0]) /
+b[3]*y+b[2])*y+b[1])*y+b[0])*y+1.0);
+}
+else {// Moro
+r = u;
+if (x > 0.0)
+r = 1.0 - u;
+r = log(-log(r));
+r = c[0] + r*(c[1]+r*(c[2]+r*(c[3]+r*(c[4]+r*(c[5]+r*(c[6]+
+r*(c[7]+r*c[8])));
+if (x < 0.0)
+r = -r;
+}
+
+return r;
+}
+
 int main(void)
 {
 int x = 0;
@@ -37,38 +90,58 @@ int main(void)
 }
 av_log(NULL, AV_LOG_ERROR, "final value:%X\n", x);
 
-/* BMG usage example */
+/*  Chen-Shapiro Normality Test */
 {
-double mean   = 1000;
-double stddev = 53;
-double samp_mean = 0.0, samp_stddev = 0.0;
-double samp0, samp1;
+double QH   = 0.0;
+const double stddev = 53.0;
+double samp_stddev  = 0.0;
+const double mean   = 1000;
+double samp_mean= 0.0;
+const int tot_samp  = 2000;
+double *PRN_arr = av_malloc_array(tot_samp, sizeof(double));
 
-av_lfg_init(, 42);
+av_lfg_init(, 0x7a69);
+if (!PRN_arr) {
+fprintf(stderr, "failed to allocate memory!\n");
+return 1;
+}
 
-for (i = 0; i < 1000; i += 2) {
+for (i = 0; i < tot_samp; i += 2) {
 double bmg_out[2];
 av_bmg_get(, bmg_out);
-samp0 = bmg_out[0] * stddev + mean;
-samp1 = bmg_out[1] * stddev + mean;
-samp_mean += samp0 + samp1;
-samp_stddev += samp0 * samp0 + samp1 * samp1;
-av_log(NULL, AV_LOG_INFO,
-   "%f\n%f\n",
-   samp0,
-   samp1);
+PRN_arr[i  ] = bmg_out[0] * stddev + mean;
+PRN_arr[i+1] = bmg_out[1] * stddev + mean;
+samp_mean   += PRN_arr[i] + PRN_arr[i+1];
+av_log(NULL, AV_LOG_INFO, "PRN%d : %f\n"
+  "PRN%d : %f\n",
+   i, PRN_arr[i], i+1, PRN_arr[i+1]);
 }
-/* TODO: add proper normality test */
-samp_mean /= 1000;
-samp_stddev /= 999;
-samp_stddev -= (1000.0/999.0)*samp_mean*samp_mean;
-samp_stddev = sqrt(samp_stddev);
-av_log(NULL, AV_LOG_INFO, "sample mean  : %f\n"
-  "true mean: %f\n"
-  "sample stddev: %f\n"
-  "true stddev  : %f\n",
-   samp_mean, mean, samp_stddev, stddev);
-}
+samp_mean /= tot_samp;
+
+for (i = 0; i < tot_samp; ++i) {
+double temp;
+temp = PRN_arr[i] - samp_mean;
+temp*= temp;
+samp_stddev += temp;
 
+if ( i < (tot_samp - 1)) {
+double H_diff;
+H_diff  = inv_cdf((i + 2.0 - 

Re: [FFmpeg-devel] [PATCH] swscale: add P016 input support

2017-01-31 Thread Philip Langdale
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Tue, 31 Jan 2017 14:43:24 +0100
Michael Niedermayer  wrote:

> On Sun, Jan 29, 2017 at 01:11:51PM -0800, Philip Langdale wrote:
> > Signed-off-by: Philip Langdale 
> > ---
> >  libswscale/input.c| 32 
> >  libswscale/swscale_unscaled.c |  4 +++-
> >  libswscale/utils.c|  2 ++
> >  3 files changed, 37 insertions(+), 1 deletion(-)  
> 
> i assume this is tested and works
> LGTM
> 
> thanks
> 
> [...]

Yes. Thanks.

- --phil
-BEGIN PGP SIGNATURE-

iEYEARECAAYFAliRWuAACgkQ+NaxlGp1aC6d5gCgp8pIgWnWRVMMTkmG87TYsl3s
nHwAmwcM/RFCshlSLfsjqtzqJTd8rDg2
=yaGC
-END PGP SIGNATURE-
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH 5/6] opus_celt: rename structures to better names and reorganize them

2017-01-31 Thread Rostislav Pehlivanov
This is meant to be applied on top of my previous patch which
split PVQ into celt_pvq.c and made opus_celt.h

Essentially nothing has been changed other than renaming CeltFrame
to CeltBlock (CeltFrame had absolutely nothing at all to do with
a frame) and CeltContext to CeltFrame.
3 variables have been put in CeltFrame as they make more sense
there rather than being passed around as arguments.
The coefficients have been moved to the CeltBlock structure
(why the hell were they in CeltContext and not in CeltFrame??).

Now the encoder would be able to use the exact context the decoder
uses (plus a couple of extra fields in there).

FATE passes, no slowdowns, etc.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus.h  |  22 +-
 libavcodec/opus_celt.c | 722 -
 libavcodec/opus_celt.h |  91 ---
 libavcodec/opus_pvq.c  |  50 ++--
 libavcodec/opus_pvq.h  |   2 +-
 libavcodec/opusdec.c   |   7 +-
 libavcodec/opustab.c   |   4 +
 libavcodec/opustab.h   |   4 +
 8 files changed, 459 insertions(+), 443 deletions(-)

diff --git a/libavcodec/opus.h b/libavcodec/opus.h
index be042497ea..c3cbaec35d 100644
--- a/libavcodec/opus.h
+++ b/libavcodec/opus.h
@@ -62,7 +62,9 @@ static const uint8_t opus_default_extradata[30] = {
 enum OpusMode {
 OPUS_MODE_SILK,
 OPUS_MODE_HYBRID,
-OPUS_MODE_CELT
+OPUS_MODE_CELT,
+
+OPUS_MODE_NB
 };
 
 enum OpusBandwidth {
@@ -70,12 +72,14 @@ enum OpusBandwidth {
 OPUS_BANDWIDTH_MEDIUMBAND,
 OPUS_BANDWIDTH_WIDEBAND,
 OPUS_BANDWIDTH_SUPERWIDEBAND,
-OPUS_BANDWIDTH_FULLBAND
+OPUS_BANDWIDTH_FULLBAND,
+
+OPUS_BANDWITH_NB
 };
 
 typedef struct SilkContext SilkContext;
 
-typedef struct CeltContext CeltContext;
+typedef struct CeltFrame CeltFrame;
 
 typedef struct OpusPacket {
 int packet_size;/**< packet size */
@@ -100,7 +104,7 @@ typedef struct OpusStreamContext {
 OpusRangeCoder rc;
 OpusRangeCoder redundancy_rc;
 SilkContext *silk;
-CeltContext *celt;
+CeltFrame *celt;
 AVFloatDSPContext *fdsp;
 
 float silk_buf[2][960];
@@ -185,14 +189,4 @@ int ff_silk_decode_superframe(SilkContext *s, 
OpusRangeCoder *rc,
   enum OpusBandwidth bandwidth, int coded_channels,
   int duration_ms);
 
-int ff_celt_init(AVCodecContext *avctx, CeltContext **s, int output_channels);
-
-void ff_celt_free(CeltContext **s);
-
-void ff_celt_flush(CeltContext *s);
-
-int ff_celt_decode_frame(CeltContext *s, OpusRangeCoder *rc,
- float **output, int coded_channels, int frame_size,
- int startband,  int endband);
-
 #endif /* AVCODEC_OPUS_H */
diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index 71ef8965e2..af3c100e6e 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -1,6 +1,7 @@
 /*
  * Copyright (c) 2012 Andrew D'Addesio
  * Copyright (c) 2013-2014 Mozilla Corporation
+ * Copyright (c) 2016 Rostislav Pehlivanov 
  *
  * This file is part of FFmpeg.
  *
@@ -28,7 +29,7 @@
 #include "opustab.h"
 #include "opus_pvq.h"
 
-static void celt_decode_coarse_energy(CeltContext *s, OpusRangeCoder *rc)
+static void celt_decode_coarse_energy(CeltFrame *f, OpusRangeCoder *rc)
 {
 int i, j;
 float prev[2] = {0};
@@ -38,29 +39,29 @@ static void celt_decode_coarse_energy(CeltContext *s, 
OpusRangeCoder *rc)
 /* use the 2D z-transform to apply prediction in both */
 /* the time domain (alpha) and the frequency domain (beta) */
 
-if (opus_rc_tell(rc)+3 <= s->framebits && ff_opus_rc_dec_log(rc, 3)) {
+if (opus_rc_tell(rc)+3 <= f->framebits && ff_opus_rc_dec_log(rc, 3)) {
 /* intra frame */
 alpha = 0;
 beta  = 1.0f - 4915.0f/32768.0f;
-model = ff_celt_coarse_energy_dist[s->duration][1];
+model = ff_celt_coarse_energy_dist[f->size][1];
 } else {
-alpha = ff_celt_alpha_coef[s->duration];
-beta  = 1.0f - ff_celt_beta_coef[s->duration];
-model = ff_celt_coarse_energy_dist[s->duration][0];
+alpha = ff_celt_alpha_coef[f->size];
+beta  = 1.0f - ff_celt_beta_coef[f->size];
+model = ff_celt_coarse_energy_dist[f->size][0];
 }
 
 for (i = 0; i < CELT_MAX_BANDS; i++) {
-for (j = 0; j < s->coded_channels; j++) {
-CeltFrame *frame = >frame[j];
+for (j = 0; j < f->channels; j++) {
+CeltBlock *block = >block[j];
 float value;
 int available;
 
-if (i < s->startband || i >= s->endband) {
-frame->energy[i] = 0.0;
+if (i < f->start_band || i >= f->end_band) {
+block->energy[i] = 0.0;
 continue;
 }
 
-available = s->framebits - opus_rc_tell(rc);
+available = f->framebits - opus_rc_tell(rc);
 if (available >= 15) {
 /* 

[FFmpeg-devel] [PATCH 0/6] Native Opus Encoder

2017-01-31 Thread Rostislav Pehlivanov
First (and probably last) Opus encoder not to use anything from libopus, woot.
Need help with striding the MDCT so I can do in place transient MDCTs.
Need help/ideas for a faster PVQ search algorithm.

Sounds good though.

Rostislav Pehlivanov (6):
  opus_rc: rename total_bits_used to total_bits and #define some
constants
  opus_rc: add entropy encoding functions
  imdct15: rename to mdct15 and add a forward transform
  opus_celt: move quantization and band decoding to opus_pvq.c
  opus_celt: rename structures to better names and reorganize them
  opus: [RFC] add a native Opus encoder

 configure|6 +-
 libavcodec/Makefile  |5 +-
 libavcodec/aac.h |4 +-
 libavcodec/aacdec.c  |2 +-
 libavcodec/aacdec_template.c |4 +-
 libavcodec/allcodecs.c   |2 +-
 libavcodec/mdct15.c  |  351 ++
 libavcodec/mdct15.h  |   70 ++
 libavcodec/opus.h|   32 +-
 libavcodec/opus_celt.c   | 1540 ++
 libavcodec/opus_celt.h   |  164 +
 libavcodec/opus_pvq.c| 1168 
 libavcodec/opus_pvq.h|   41 ++
 libavcodec/opus_rc.c |  201 +-
 libavcodec/opus_rc.h |   41 +-
 libavcodec/opusdec.c |7 +-
 libavcodec/opusenc.c | 1132 +++
 libavcodec/opustab.c |4 +
 libavcodec/opustab.h |4 +
 19 files changed, 3552 insertions(+), 1226 deletions(-)
 create mode 100644 libavcodec/mdct15.c
 create mode 100644 libavcodec/mdct15.h
 create mode 100644 libavcodec/opus_celt.h
 create mode 100644 libavcodec/opus_pvq.c
 create mode 100644 libavcodec/opus_pvq.h
 create mode 100644 libavcodec/opusenc.c

-- 
2.11.0.483.g087da7b7c

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


[FFmpeg-devel] [PATCH 1/6] opus_rc: rename total_bits_used to total_bits and #define some constants

2017-01-31 Thread Rostislav Pehlivanov
Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus_celt.c |  2 +-
 libavcodec/opus_rc.c   | 19 +--
 libavcodec/opus_rc.h   |  6 +++---
 3 files changed, 17 insertions(+), 10 deletions(-)

diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index c115ee7ad3..96fedb7a49 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -1641,7 +1641,7 @@ int ff_celt_decode_frame(CeltContext *s, OpusRangeCoder 
*rc,
 
 if (silence) {
 consumed = s->framebits;
-rc->total_read_bits += s->framebits - opus_rc_tell(rc);
+rc->total_bits += s->framebits - opus_rc_tell(rc);
 }
 
 /* obtain post-filter options */
diff --git a/libavcodec/opus_rc.c b/libavcodec/opus_rc.c
index 1f9af041aa..b0e72f6ffe 100644
--- a/libavcodec/opus_rc.c
+++ b/libavcodec/opus_rc.c
@@ -22,12 +22,19 @@
 
 #include "opus_rc.h"
 
+#define OPUS_RC_BITS 32
+#define OPUS_RC_SYM  8
+#define OPUS_RC_CEIL ((1 << OPUS_RC_SYM) - 1)
+#define OPUS_RC_TOP (1u << 31)
+#define OPUS_RC_BOT (OPUS_RC_TOP >> OPUS_RC_SYM)
+#define OPUS_RC_SHIFT (OPUS_RC_BITS - OPUS_RC_SYM - 1)
+
 static av_always_inline void opus_rc_dec_normalize(OpusRangeCoder *rc)
 {
-while (rc->range <= 1<<23) {
-rc->value = ((rc->value << 8) | (get_bits(>gb, 8) ^ 0xFF)) & ((1u 
<< 31) - 1);
-rc->range  <<= 8;
-rc->total_read_bits += 8;
+while (rc->range <= OPUS_RC_BOT) {
+rc->value = ((rc->value << OPUS_RC_SYM) | (get_bits(>gb, 
OPUS_RC_SYM) ^ OPUS_RC_CEIL)) & (OPUS_RC_TOP - 1);
+rc->range <<= OPUS_RC_SYM;
+rc->total_bits += OPUS_RC_SYM;
 }
 }
 
@@ -93,7 +100,7 @@ uint32_t ff_opus_rc_get_raw(OpusRangeCoder *rc, uint32_t 
count)
 value = av_mod_uintp2(rc->rb.cacheval, count);
 rc->rb.cacheval>>= count;
 rc->rb.cachelen -= count;
-rc->total_read_bits += count;
+rc->total_bits  += count;
 
 return value;
 }
@@ -206,7 +213,7 @@ int ff_opus_rc_dec_init(OpusRangeCoder *rc, const uint8_t 
*data, int size)
 
 rc->range = 128;
 rc->value = 127 - get_bits(>gb, 7);
-rc->total_read_bits = 9;
+rc->total_bits = 9;
 opus_rc_dec_normalize(rc);
 
 return 0;
diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
index 68ebc05af6..9f5253b51d 100644
--- a/libavcodec/opus_rc.h
+++ b/libavcodec/opus_rc.h
@@ -40,7 +40,7 @@ typedef struct OpusRangeCoder {
 RawBitsContext rb;
 uint32_t range;
 uint32_t value;
-uint32_t total_read_bits;
+uint32_t total_bits;
 } OpusRangeCoder;
 
 /**
@@ -49,14 +49,14 @@ typedef struct OpusRangeCoder {
  */
 static av_always_inline uint32_t opus_rc_tell(const OpusRangeCoder *rc)
 {
-return rc->total_read_bits - av_log2(rc->range) - 1;
+return rc->total_bits - av_log2(rc->range) - 1;
 }
 
 static av_always_inline uint32_t opus_rc_tell_frac(const OpusRangeCoder *rc)
 {
 uint32_t i, total_bits, rcbuffer, range;
 
-total_bits = rc->total_read_bits << 3;
+total_bits = rc->total_bits << 3;
 rcbuffer   = av_log2(rc->range) + 1;
 range  = rc->range >> (rcbuffer-16);
 
-- 
2.11.0.483.g087da7b7c

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


[FFmpeg-devel] [PATCH 4/6] opus_celt: move quantization and band decoding to opus_pvq.c

2017-01-31 Thread Rostislav Pehlivanov
A huge amount can be reused by the encoder, as the only thing
which needs to be done would be to add a 10 line celt_icwrsi,
a wrapper around it (celt_alg_quant) and templating the
ff_celt_decode_band to replace entropy decoding functions
with entropy encoding.

There is no performance loss but in fact a performance gain of
nearly 6% which is caused by the compiler being able to optimize
the decoding more efficiently.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/Makefile|   2 +-
 libavcodec/opus.h  |  10 -
 libavcodec/opus_celt.c | 828 +
 libavcodec/opus_celt.h | 133 
 libavcodec/opus_pvq.c  | 729 +++
 libavcodec/opus_pvq.h  |  35 +++
 6 files changed, 909 insertions(+), 828 deletions(-)
 create mode 100644 libavcodec/opus_celt.h
 create mode 100644 libavcodec/opus_pvq.c
 create mode 100644 libavcodec/opus_pvq.h

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 6c37ca513b..8080e9127d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -435,7 +435,7 @@ OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o 
nellymoser.o
 OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
 OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
 OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o 
opus_rc.o \
-  opus_silk.o opustab.o vorbis_data.o
+  opus_pvq.o opus_silk.o opustab.o 
vorbis_data.o
 OBJS-$(CONFIG_PAF_AUDIO_DECODER)   += pafaudio.o
 OBJS-$(CONFIG_PAF_VIDEO_DECODER)   += pafvideo.o
 OBJS-$(CONFIG_PAM_DECODER) += pnmdec.o pnm.o
diff --git a/libavcodec/opus.h b/libavcodec/opus.h
index 2c3d63a7a2..be042497ea 100644
--- a/libavcodec/opus.h
+++ b/libavcodec/opus.h
@@ -43,16 +43,6 @@
 #define CELT_MAX_LOG_BLOCKS  3
 #define CELT_MAX_FRAME_SIZE  (CELT_SHORT_BLOCKSIZE * (1 << 
CELT_MAX_LOG_BLOCKS))
 #define CELT_MAX_BANDS   21
-#define CELT_VECTORS 11
-#define CELT_ALLOC_STEPS 6
-#define CELT_FINE_OFFSET 21
-#define CELT_MAX_FINE_BITS   8
-#define CELT_NORM_SCALE  16384
-#define CELT_QTHETA_OFFSET   4
-#define CELT_QTHETA_OFFSET_TWOPHASE  16
-#define CELT_DEEMPH_COEFF0.85000610f
-#define CELT_POSTFILTER_MINPERIOD15
-#define CELT_ENERGY_SILENCE  (-28.0f)
 
 #define SILK_HISTORY 322
 #define SILK_MAX_LPC 16
diff --git a/libavcodec/opus_celt.c b/libavcodec/opus_celt.c
index a0f018e664..71ef8965e2 100644
--- a/libavcodec/opus_celt.c
+++ b/libavcodec/opus_celt.c
@@ -24,109 +24,9 @@
  * Opus CELT decoder
  */
 
-#include 
-
-#include "libavutil/float_dsp.h"
-#include "libavutil/libm.h"
-
-#include "mdct15.h"
-#include "opus.h"
+#include "opus_celt.h"
 #include "opustab.h"
-
-enum CeltSpread {
-CELT_SPREAD_NONE,
-CELT_SPREAD_LIGHT,
-CELT_SPREAD_NORMAL,
-CELT_SPREAD_AGGRESSIVE
-};
-
-typedef struct CeltFrame {
-float energy[CELT_MAX_BANDS];
-float prev_energy[2][CELT_MAX_BANDS];
-
-uint8_t collapse_masks[CELT_MAX_BANDS];
-
-/* buffer for mdct output + postfilter */
-DECLARE_ALIGNED(32, float, buf)[2048];
-
-/* postfilter parameters */
-int pf_period_new;
-float pf_gains_new[3];
-int pf_period;
-float pf_gains[3];
-int pf_period_old;
-float pf_gains_old[3];
-
-float deemph_coeff;
-} CeltFrame;
-
-struct CeltContext {
-// constant values that do not change during context lifetime
-AVCodecContext*avctx;
-MDCT15Context *imdct[4];
-AVFloatDSPContext  *dsp;
-int output_channels;
-
-// values that have inter-frame effect and must be reset on flush
-CeltFrame frame[2];
-uint32_t seed;
-int flushed;
-
-// values that only affect a single frame
-int coded_channels;
-int framebits;
-int duration;
-
-/* number of iMDCT blocks in the frame */
-int blocks;
-/* size of each block */
-int blocksize;
-
-int startband;
-int endband;
-int codedbands;
-
-int anticollapse_bit;
-
-int intensitystereo;
-int dualstereo;
-enum CeltSpread spread;
-
-int remaining;
-int remaining2;
-int fine_bits[CELT_MAX_BANDS];
-int fine_priority[CELT_MAX_BANDS];
-int pulses   [CELT_MAX_BANDS];
-int tf_change[CELT_MAX_BANDS];
-
-DECLARE_ALIGNED(32, float, coeffs)[2][CELT_MAX_FRAME_SIZE];
-DECLARE_ALIGNED(32, float, scratch)[22 * 8]; // MAX(ff_celt_freq_range) * 
1<> 13;
-x = (32767-x) + ROUND_MUL16(x, (-7651 + ROUND_MUL16(x, (8277 + 
ROUND_MUL16(-626, x);
-return 1+x;
-}
-
-static inline int celt_log2tan(int isin, int icos)
-{
-int lc, ls;
-lc = opus_ilog(icos);
-ls = opus_ilog(isin);
-icos <<= 15 - lc;
-isin <<= 15 - ls;
-return (ls << 11) - (lc << 11) +
-   ROUND_MUL16(isin, 

[FFmpeg-devel] [PATCH 2/6] opus_rc: add entropy encoding functions

2017-01-31 Thread Rostislav Pehlivanov
Mostly used the RFC document, the decoding functions and
the reference encoder's implmenentation as a reference.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus_rc.c | 182 ++-
 libavcodec/opus_rc.h |  35 --
 2 files changed, 212 insertions(+), 5 deletions(-)

diff --git a/libavcodec/opus_rc.c b/libavcodec/opus_rc.c
index b0e72f6ffe..85268bd284 100644
--- a/libavcodec/opus_rc.c
+++ b/libavcodec/opus_rc.c
@@ -1,7 +1,7 @@
 /*
  * Copyright (c) 2012 Andrew D'Addesio
  * Copyright (c) 2013-2014 Mozilla Corporation
- * Copyright (c) 2016 Rostislav Pehlivanov 
+ * Copyright (c) 2017 Rostislav Pehlivanov 
  *
  * This file is part of FFmpeg.
  *
@@ -29,6 +29,21 @@
 #define OPUS_RC_BOT (OPUS_RC_TOP >> OPUS_RC_SYM)
 #define OPUS_RC_SHIFT (OPUS_RC_BITS - OPUS_RC_SYM - 1)
 
+static av_always_inline void opus_rc_enc_carryout(OpusRangeCoder *rc, int cbuf)
+{
+const int cb = cbuf >> OPUS_RC_SYM, mb = (OPUS_RC_CEIL + cb) & 
OPUS_RC_CEIL;
+if (cbuf == OPUS_RC_CEIL) {
+rc->ext++;
+return;
+}
+rc->rng_cur[0] = rc->rem + cb;
+rc->rng_cur += (rc->rem >= 0);
+for (; rc->ext > 0; rc->ext--)
+*rc->rng_cur++ = mb;
+av_assert0(rc->rng_cur < rc->rb.position);
+rc->rem = cbuf & OPUS_RC_CEIL; /* Propagate */
+}
+
 static av_always_inline void opus_rc_dec_normalize(OpusRangeCoder *rc)
 {
 while (rc->range <= OPUS_RC_BOT) {
@@ -38,6 +53,16 @@ static av_always_inline void 
opus_rc_dec_normalize(OpusRangeCoder *rc)
 }
 }
 
+static av_always_inline void opus_rc_enc_normalize(OpusRangeCoder *rc)
+{
+while (rc->range <= OPUS_RC_BOT) {
+opus_rc_enc_carryout(rc, rc->value >> OPUS_RC_SHIFT);
+rc->value = (rc->value << OPUS_RC_SYM) & (OPUS_RC_TOP - 1);
+rc->range <<= OPUS_RC_SYM;
+rc->total_bits += OPUS_RC_SYM;
+}
+}
+
 static av_always_inline void opus_rc_dec_update(OpusRangeCoder *rc, uint32_t 
scale,
 uint32_t low, uint32_t high,
 uint32_t total)
@@ -48,6 +73,20 @@ static av_always_inline void 
opus_rc_dec_update(OpusRangeCoder *rc, uint32_t sca
 opus_rc_dec_normalize(rc);
 }
 
+/* Main encoding function, this needs to go fast */
+static av_always_inline void opus_rc_enc_update(OpusRangeCoder *rc, uint32_t 
b, uint32_t p,
+uint32_t p_tot, const int ptwo)
+{
+uint32_t rscaled, cnd = !!b;
+if (ptwo) /* Whole function is inlined so hopefully branch is optimized 
out */
+rscaled = rc->range >> ff_log2(p_tot);
+else
+rscaled = rc->range/p_tot;
+rc->value +=cnd*(rc->range - rscaled*(p_tot - b));
+rc->range  = (!cnd)*(rc->range - rscaled*(p_tot - p)) + cnd*rscaled*(p - 
b);
+opus_rc_enc_normalize(rc);
+}
+
 uint32_t ff_opus_rc_dec_cdf(OpusRangeCoder *rc, const uint16_t *cdf)
 {
 unsigned int k, scale, total, symbol, low, high;
@@ -67,6 +106,11 @@ uint32_t ff_opus_rc_dec_cdf(OpusRangeCoder *rc, const 
uint16_t *cdf)
 return k;
 }
 
+void ff_opus_rc_enc_cdf(OpusRangeCoder *rc, int val, const uint16_t *cdf)
+{
+opus_rc_enc_update(rc, cdf[val], cdf[val + 1], cdf[0], 1);
+}
+
 uint32_t ff_opus_rc_dec_log(OpusRangeCoder *rc, uint32_t bits)
 {
 uint32_t k, scale;
@@ -84,6 +128,12 @@ uint32_t ff_opus_rc_dec_log(OpusRangeCoder *rc, uint32_t 
bits)
 return k;
 }
 
+void ff_opus_rc_enc_log(OpusRangeCoder *rc, int val, uint32_t bits)
+{
+bits = (1 << bits) - 1;
+opus_rc_enc_update(rc, (!!val)*bits, bits + !!val, bits + 1, 1);
+}
+
 /**
  * CELT: read 1-25 raw bits at the end of the frame, backwards byte-wise
  */
@@ -106,6 +156,27 @@ uint32_t ff_opus_rc_get_raw(OpusRangeCoder *rc, uint32_t 
count)
 }
 
 /**
+ * CELT: write 0 - 31 bits to the rawbits buffer
+ */
+void ff_opus_rc_put_raw(OpusRangeCoder *rc, uint32_t val, uint32_t count)
+{
+const int to_write = FFMIN(32 - rc->rb.cachelen, count);
+
+rc->total_bits += count;
+rc->rb.cacheval |= av_mod_uintp2(val, to_write) << rc->rb.cachelen;
+rc->rb.cachelen = (rc->rb.cachelen + to_write) % 32;
+
+if (!rc->rb.cachelen && count) {
+AV_WB32(rc->rb.position, rc->rb.cacheval);
+rc->rb.bytes+= 4;
+rc->rb.position -= 4;
+rc->rb.cachelen = count - to_write;
+rc->rb.cacheval = av_mod_uintp2(val >> to_write, rc->rb.cachelen);
+av_assert0(rc->rng_cur < rc->rb.position);
+}
+}
+
+/**
  * CELT: read a uniform distribution
  */
 uint32_t ff_opus_rc_dec_uint(OpusRangeCoder *rc, uint32_t size)
@@ -127,6 +198,16 @@ uint32_t ff_opus_rc_dec_uint(OpusRangeCoder *rc, uint32_t 
size)
 return k;
 }
 
+/**
+ * CELT: write a uniformly distributed integer
+ */
+void ff_opus_rc_enc_uint(OpusRangeCoder *rc, uint32_t val, uint32_t size)
+{
+const int ps = FFMAX(opus_ilog(size - 1) - 8, 0);
+

[FFmpeg-devel] [PATCH 3/6] imdct15: rename to mdct15 and add a forward transform

2017-01-31 Thread Rostislav Pehlivanov
The stride parameter does not currently do anything.
I can't figure out how to stride since the damn post-rotation
happens from the middle and goes both up and down at the same time.

Signed-off-by: Rostislav Pehlivanov 
---
 configure|   6 +-
 libavcodec/Makefile  |   2 +-
 libavcodec/aac.h |   4 +-
 libavcodec/aacdec.c  |   2 +-
 libavcodec/aacdec_template.c |   4 +-
 libavcodec/mdct15.c  | 351 +++
 libavcodec/mdct15.h  |  70 +
 libavcodec/opus_celt.c   |  10 +-
 8 files changed, 435 insertions(+), 14 deletions(-)
 create mode 100644 libavcodec/mdct15.c
 create mode 100644 libavcodec/mdct15.h

diff --git a/configure b/configure
index 7154142006..76caeb8277 100755
--- a/configure
+++ b/configure
@@ -2106,7 +2106,7 @@ CONFIG_EXTRA="
 huffyuvencdsp
 idctdsp
 iirfilter
-imdct15
+mdct15
 intrax8
 iso_media
 ividsp
@@ -2348,7 +2348,7 @@ vc1dsp_select="h264chroma qpeldsp startcode"
 rdft_select="fft"
 
 # decoders / encoders
-aac_decoder_select="imdct15 mdct sinewin"
+aac_decoder_select="mdct15 mdct sinewin"
 aac_fixed_decoder_select="mdct sinewin"
 aac_encoder_select="audio_frame_queue iirfilter lpc mdct sinewin"
 aac_latm_decoder_select="aac_decoder aac_latm_parser"
@@ -2490,7 +2490,7 @@ nellymoser_encoder_select="audio_frame_queue mdct sinewin"
 nuv_decoder_select="idctdsp lzo"
 on2avc_decoder_select="mdct"
 opus_decoder_deps="swresample"
-opus_decoder_select="imdct15"
+opus_decoder_select="mdct15"
 png_decoder_select="zlib"
 png_encoder_select="llvidencdsp zlib"
 prores_decoder_select="blockdsp idctdsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add317..6c37ca513b 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -83,7 +83,7 @@ OBJS-$(CONFIG_HUFFYUVDSP)  += huffyuvdsp.o
 OBJS-$(CONFIG_HUFFYUVENCDSP)   += huffyuvencdsp.o
 OBJS-$(CONFIG_IDCTDSP) += idctdsp.o simple_idct.o jrevdct.o
 OBJS-$(CONFIG_IIRFILTER)   += iirfilter.o
-OBJS-$(CONFIG_IMDCT15) += imdct15.o
+OBJS-$(CONFIG_MDCT15)  += mdct15.o
 OBJS-$(CONFIG_INTRAX8) += intrax8.o intrax8dsp.o
 OBJS-$(CONFIG_IVIDSP)  += ivi_dsp.o
 OBJS-$(CONFIG_JNI) += ffjni.o jni.o
diff --git a/libavcodec/aac.h b/libavcodec/aac.h
index b1f4aa74f0..97a2df6b86 100644
--- a/libavcodec/aac.h
+++ b/libavcodec/aac.h
@@ -36,7 +36,7 @@
 #include "libavutil/fixed_dsp.h"
 #include "avcodec.h"
 #if !USE_FIXED
-#include "imdct15.h"
+#include "mdct15.h"
 #endif
 #include "fft.h"
 #include "mpeg4audio.h"
@@ -327,7 +327,7 @@ struct AACContext {
 #if USE_FIXED
 AVFixedDSPContext *fdsp;
 #else
-IMDCT15Context *mdct480;
+MDCT15Context *mdct480;
 AVFloatDSPContext *fdsp;
 #endif /* USE_FIXED */
 int random_state;
diff --git a/libavcodec/aacdec.c b/libavcodec/aacdec.c
index ee9b4eb45f..1a10c121b9 100644
--- a/libavcodec/aacdec.c
+++ b/libavcodec/aacdec.c
@@ -42,7 +42,7 @@
 #include "internal.h"
 #include "get_bits.h"
 #include "fft.h"
-#include "imdct15.h"
+#include "mdct15.h"
 #include "lpc.h"
 #include "kbdwin.h"
 #include "sinewin.h"
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 83e9fb55ba..0bfd66 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -1185,7 +1185,7 @@ static av_cold int aac_decode_init(AVCodecContext *avctx)
 AAC_RENAME_32(ff_mdct_init)(>mdct_small,  8, 1, 1.0 / RANGE15(128.0));
 AAC_RENAME_32(ff_mdct_init)(>mdct_ltp,   11, 0, RANGE15(-2.0));
 #if !USE_FIXED
-ret = ff_imdct15_init(>mdct480, 5);
+ret = ff_mdct15_init(>mdct480, 1, 5, -1.0f);
 if (ret < 0)
 return ret;
 #endif
@@ -3192,7 +3192,7 @@ static av_cold int aac_decode_close(AVCodecContext *avctx)
 ff_mdct_end(>mdct_ld);
 ff_mdct_end(>mdct_ltp);
 #if !USE_FIXED
-ff_imdct15_uninit(>mdct480);
+ff_mdct15_uninit(>mdct480);
 #endif
 av_freep(>fdsp);
 return 0;
diff --git a/libavcodec/mdct15.c b/libavcodec/mdct15.c
new file mode 100644
index 00..4edbc69dbe
--- /dev/null
+++ b/libavcodec/mdct15.c
@@ -0,0 +1,351 @@
+/*
+ * Copyright (c) 2013-2014 Mozilla Corporation
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * 

[FFmpeg-devel] [PATCH 6/6] opus: [RFC] add a native Opus encoder

2017-01-31 Thread Rostislav Pehlivanov
This marks the first time anyone has written an Opus encoder without
using any libopus code. The aim of the encoder is to prove how far
the format can go by writing the craziest encoder for it.

The encoder's pretty basic, it supports nearly all the features
that CELT has (except the pitch prefiltering) however there is
no psychoacoustic or rate control system to enable or disable
features. So only simple CBR is supported.

The unique side of the encoder is that its able to use a lookahead
of any value which is a multiple of 2.5 milliseconds, up to a maximum
of 320ms. Unfortunately its up to the psychoacoustic syatem to use
it for lookahead but there's no such written yet, though I'll start
writing one once I get this damn patch message written.

Even though its a pretty basic encoder its already outperforming
any other native encoder FFmpeg has by a huge amount.

The encoder still has a few minor bugs, like desyncs at ultra low
bitrates (below 9kbps with 20ms frames).

The transient-only part of the MDCT can be performed in place
so I invite those willing to use their brains for a little bit to
figure out how to modify mdct15.c to use the stride for the forward
transform.

The PVQ search is very slow and I HATE IT, if anyone wants to help
me write the craziest pvq search algorithm take a look at the comment
above celt_pvq_search() in opus_pvq.c

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/Makefile|1 +
 libavcodec/allcodecs.c |2 +-
 libavcodec/opus_celt.h |   16 +
 libavcodec/opus_pvq.c  |  459 +++-
 libavcodec/opus_pvq.h  |6 +
 libavcodec/opusenc.c   | 1132 
 6 files changed, 1605 insertions(+), 11 deletions(-)
 create mode 100644 libavcodec/opusenc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 8080e9127d..b8c05773d5 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -436,6 +436,7 @@ OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
 OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
 OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o 
opus_rc.o \
   opus_pvq.o opus_silk.o opustab.o 
vorbis_data.o
+OBJS-$(CONFIG_OPUS_ENCODER)+= opusenc.o opustab.o opus_pvq.o
 OBJS-$(CONFIG_PAF_AUDIO_DECODER)   += pafaudio.o
 OBJS-$(CONFIG_PAF_VIDEO_DECODER)   += pafvideo.o
 OBJS-$(CONFIG_PAM_DECODER) += pnmdec.o pnm.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f92b2b7496..bea32f8072 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -446,7 +446,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(MPC8,  mpc8);
 REGISTER_ENCDEC (NELLYMOSER,nellymoser);
 REGISTER_DECODER(ON2AVC,on2avc);
-REGISTER_DECODER(OPUS,  opus);
+REGISTER_ENCDEC (OPUS,  opus);
 REGISTER_DECODER(PAF_AUDIO, paf_audio);
 REGISTER_DECODER(QCELP, qcelp);
 REGISTER_DECODER(QDM2,  qdm2);
diff --git a/libavcodec/opus_celt.h b/libavcodec/opus_celt.h
index 1378d85df3..a54cab68c6 100644
--- a/libavcodec/opus_celt.h
+++ b/libavcodec/opus_celt.h
@@ -61,14 +61,23 @@ enum CeltBlockSize {
 
 typedef struct CeltBlock {
 float energy[CELT_MAX_BANDS];
+float lin_energy[CELT_MAX_BANDS];
+float error_energy[CELT_MAX_BANDS];
 float prev_energy[2][CELT_MAX_BANDS];
 
 uint8_t collapse_masks[CELT_MAX_BANDS];
 
+int band_bins[CELT_MAX_BANDS]; /* MDCT bins per band */
+float *band_coeffs[CELT_MAX_BANDS];
+
 /* buffer for mdct output + postfilter */
 DECLARE_ALIGNED(32, float, buf)[2048];
 DECLARE_ALIGNED(32, float, coeffs)[CELT_MAX_FRAME_SIZE];
 
+/* Used by the encoder */
+DECLARE_ALIGNED(32, float, overlap)[120];
+DECLARE_ALIGNED(32, float, samples)[CELT_MAX_FRAME_SIZE];
+
 /* postfilter parameters */
 int   pf_period_new;
 float pf_gains_new[3];
@@ -94,6 +103,12 @@ typedef struct CeltFrame {
 int end_band;
 int coded_bands;
 int transient;
+int intra;
+int pfilter;
+int skip_band_floor;
+int tf_select;
+int alloc_trim;
+int alloc_boost[CELT_MAX_BANDS];
 int blocks;/* number of iMDCT blocks in the frame, depends on 
transient */
 int blocksize; /* size of each block */
 int silence;   /* Frame is filled with silence */
@@ -109,6 +124,7 @@ typedef struct CeltFrame {
 int framebits;
 int remaining;
 int remaining2;
+int caps [CELT_MAX_BANDS];
 int fine_bits[CELT_MAX_BANDS];
 int fine_priority[CELT_MAX_BANDS];
 int pulses   [CELT_MAX_BANDS];
diff --git a/libavcodec/opus_pvq.c b/libavcodec/opus_pvq.c
index a39330b7e4..adf6f44c8d 100644
--- a/libavcodec/opus_pvq.c
+++ b/libavcodec/opus_pvq.c
@@ -1,7 +1,7 @@
 /*
  * Copyright (c) 2012 Andrew D'Addesio
  * Copyright (c) 2013-2014 Mozilla Corporation
- * 

Re: [FFmpeg-devel] [PATCH] Allow borderless playback windows

2017-01-31 Thread Lucas Sandery

On 2017-02-01 12:34, Marton Balint wrote:
No, your code is not yet committed to the ffmpeg master repository, I 
am not sure which github repo you are referring to. So you might still 
change your mind. Also I plan to squash your two patches into one.

I managed to stuff up (and misuse) my local repo. Attached an updated patch.

Sorry for the noise, everyone.
From a4b32dbb6715d42eff4b57cf2cbe8f2db2294baa Mon Sep 17 00:00:00 2001
From: Lucas Sandery 
Date: Wed, 1 Feb 2017 13:11:29 +1030
Subject: [PATCH] Allow borderless playback windows

For a pure video tile effect, and enabling better integration of playback windows
into other programs. It would improve the looks in many situations and avoid ugly
hacks like this: http://stackoverflow.com/q/31465630/315024

Signed-off-by: Lucas Sandery 
---
 doc/ffplay.texi | 2 ++
 ffplay.c| 4 
 2 files changed, 6 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index 378a229d67..a76bed4663 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -62,6 +62,8 @@ see @ref{time duration syntax,,the Time duration section in the ffmpeg-utils(1)
 Seek by bytes.
 @item -nodisp
 Disable graphical display.
+@item -noborder
+Borderless window.
 @item -volume
 Set the startup volume. 0 means silence, 100 means no volume reduction or
 amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/ffplay.c b/ffplay.c
index 7ea172f8da..6325e6f999 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -321,6 +321,7 @@ static int subtitle_disable;
 static const char* wanted_stream_spec[AVMEDIA_TYPE_NB] = {0};
 static int seek_by_bytes = -1;
 static int display_disable;
+static int borderless;
 static int startup_volume = 100;
 static int show_status = 1;
 static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -1265,6 +1266,8 @@ static int video_open(VideoState *is)
 window_title = input_filename;
 if (is_full_screen)
 flags |= SDL_WINDOW_FULLSCREEN_DESKTOP;
+if (borderless)
+flags |= SDL_WINDOW_BORDERLESS;
 window = SDL_CreateWindow(window_title, SDL_WINDOWPOS_UNDEFINED, SDL_WINDOWPOS_UNDEFINED, w, h, flags);
 SDL_SetHint(SDL_HINT_RENDER_SCALE_QUALITY, "linear");
 if (window) {
@@ -3513,6 +3516,7 @@ static const OptionDef options[] = {
 { "t", HAS_ARG, { .func_arg = opt_duration }, "play  \"duration\" seconds of audio/video", "duration" },
 { "bytes", OPT_INT | HAS_ARG, { _by_bytes }, "seek by bytes 0=off 1=on -1=auto", "val" },
 { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" },
+{ "noborder", OPT_BOOL, {  }, "borderless window" },
 { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 0=min 100=max", "volume" },
 { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
 { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = opt_frame_pix_fmt }, "set pixel format", "format" },
-- 
2.11.0.windows.3

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


Re: [FFmpeg-devel] [PATCH 9/9] boadec: prevent overflow during block alignment calculation

2017-01-31 Thread Andreas Cadhalpun
On 31.01.2017 13:45, Ronald S. Bultje wrote:
> I don't want this patch. I also don't want to discuss it further. Please
> remove the log message. Thank you.

For the sake of ending this, I've removed them.
Please avoid complaining about log messages for my future patches. Thank you.

Best regards,
Andreas 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Allow borderless playback windows

2017-01-31 Thread Marton Balint



On Wed, 1 Feb 2017, Lucas Sandery wrote:


On 2017-02-01 08:47, Marton Balint wrote:

On Tue, 31 Jan 2017, Lucas Sandery wrote:

On 2017-01-31 11:28, Marton Balint wrote:

On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of 
playback windows into other programs. It would improve the looks in 
many situations and avoid ugly hacks like this:

http://stackoverflow.com/q/31465630/315024



Could you please add some documentation for the new option to 
doc/ffplay.texi as well?


The main patch has already been committed to master from my attempt 
via GitHub.


I've attached another patch for documentation.



Do you want your authorship to be
Lucas Sandery 
as in the patch, or simply
Lucas Sandery 
?


Use the GitHub one, I've already lost authorship of the main patch, anyway.


No, your code is not yet committed to the ffmpeg master repository, I am 
not sure which github repo you are referring to. So you might still change 
your mind. Also I plan to squash your two patches into one.



Also, why put un-obfuscated email addresses in a public list?


Sorry. On the other hand I question the usefulness of such obfuscations.

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


Re: [FFmpeg-devel] [PATCH] pgssubdec: reset rle_data_len/rle_remaining_len on allocation error

2017-01-31 Thread Andreas Cadhalpun
On 31.01.2017 15:13, Michael Niedermayer wrote:
> On Tue, Jan 31, 2017 at 01:59:38AM +0100, Andreas Cadhalpun wrote:
>> The code relies on their validity and otherwise can try to access a NULL
>> object->rle pointer, causing segmentation faults.
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/pgssubdec.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> LGTM

Pushed.

> please also backport this to the releases

Will do.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

2017-01-31 Thread Andreas Cadhalpun
On 31.01.2017 09:43, Steinar H. Gunderson wrote:
> On Tue, Jan 31, 2017 at 01:57:31AM +0100, Andreas Cadhalpun wrote:
>>> This sounds like a strangeness in constructing the table, which shouldn't be
>>> papered over in the inner loop of the decoder.
>> Maybe, I don't know what the contents of the table should be, but the 
>> following
>> are {-1, 0}: 32, 33, 64, 96, 128
> 
> Seemingly they are, indeed.
> 
>>> Do you have an actual input where your code makes a difference?
>> Yes, without this patch ubsan reports:
>> src/libavcodec/speedhq.c:206:13: runtime error: index -1 out of bounds for 
>> type 'uint8_t [128]'
> 
> Would you mind sharing an input where this actually triggers? None of the
> samples I have seem to trigger this, so I suppose it's some sort of fuzzed
> input.

Indeed it is. I've sent you a sample.

Best regards,
Andreas

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


Re: [FFmpeg-devel] [PATCH] avformat/http: allow content range to set filesize

2017-01-31 Thread Philip de Nier
On 09/12/2016 11:54, PHILIP DE NIER wrote:
> Hi,
> Attached patch fixes issue #6007 for me.
> I think it could improved / extended because the "if (s->seekable ==
> -1 && (!s->is_akamai || s->content_range_len != 2147483647))" is
> probably better placed http_read_header along with the similar
> is_mediagateway workaround. I wasn't sure whether the is_akamai should
> only be triggered if the filesize was read from the Content-Range header.
> Philip
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Ping?

A summary of issue #6007:
A quicktime file is being served using chunked transfer and byte range
requests enabled. FFmpeg opens the file in libavformat, mov.c
mov_read_default and it fails to complete because the (seekable) file
returns an error (ENOSYS) for avio_size. avio_size is returning an error
because the code in libavformat/http.c is ignoring the resource length
provided by the Content-Range response header.

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


Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 08:27:41PM -0300, James Almer wrote:
> On 1/31/2017 7:12 PM, Michael Niedermayer wrote:
> > On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
> >> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> >>> The assumtation this is based on is wrong, the code is not always run 
> >>> with bitexact flags
> 
> Assumption not assumtation. Missed it the first time.

corrected

> 
> >>>
> >>> This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
> >>> changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
> >>> ---
> >>>  libavcodec/x86/hpeldsp.h  |  2 +-
> >>>  libavcodec/x86/hpeldsp_init.c |  2 +-
> >>>  libavcodec/x86/hpeldsp_vp3_init.c | 14 +-
> >>>  3 files changed, 11 insertions(+), 7 deletions(-)
> >>>
> >>> diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
> >>> index 0ecc97a83a..bf97029b57 100644
> >>> --- a/libavcodec/x86/hpeldsp.h
> >>> +++ b/libavcodec/x86/hpeldsp.h
> >>> @@ -52,6 +52,6 @@ void ff_put_pixels16_xy2_sse2(uint8_t *block, const 
> >>> uint8_t *pixels,
> >>>  void ff_put_pixels16_xy2_ssse3(uint8_t *block, const uint8_t *pixels,
> >>> ptrdiff_t line_size, int h);
> >>>  
> >>> -void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags);
> >>> +void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int 
> >>> flags);
> >>>  
> >>>  #endif /* AVCODEC_X86_HPELDSP_H */
> >>> diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
> >>> index e583bd9ffe..58e27e3542 100644
> >>> --- a/libavcodec/x86/hpeldsp_init.c
> >>> +++ b/libavcodec/x86/hpeldsp_init.c
> >>> @@ -309,5 +309,5 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c, 
> >>> int flags)
> >>>  hpeldsp_init_ssse3(c, flags);
> >>>  
> >>>  if (CONFIG_VP3_DECODER)
> >>
> >> How about checking for AV_CODEC_FLAG_BITEXACT here instead of reverting the
> >> function signature? Keeps differences as minimal as possible while having
> >> the same effect.
> > 
> > technically yes thats possible it makes the code confusing though and
> > may cause bugs in the future, for example then the whole set of
> > vp3 optimizations here would depend on AV_CODEC_FLAG_BITEXACT being set
> > and thats unexpected. Unexpected things / surprises can be bad for code
> > quality.
> > 
> > Anyway i can change it to that test it and resubmit if preferred ?
> 
> No, it was mostly a nit. The patch is ok as is. The differences with libav
> with this change will be minimal in any case.

applied

thanks

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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


[FFmpeg-devel] [PATCH] avfilter/scale: refactor common code for scaling height/width expressions

2017-01-31 Thread Aman Gupta
From: Aman Gupta 

Implements support for height/width expressions in vf_scale_vaapi,
by refactoring common code into a new libavfilter/scale.c
---
 libavfilter/Makefile |   8 +--
 libavfilter/scale.c  | 143 +++
 libavfilter/scale.h  |  31 ++
 libavfilter/vf_scale.c   | 109 +++--
 libavfilter/vf_scale_npp.c   |  87 +++---
 libavfilter/vf_scale_vaapi.c |  18 +-
 6 files changed, 208 insertions(+), 188 deletions(-)
 create mode 100644 libavfilter/scale.c
 create mode 100644 libavfilter/scale.h

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 68a94be..3231f08 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -257,10 +257,10 @@ OBJS-$(CONFIG_REPEATFIELDS_FILTER)   += 
vf_repeatfields.o
 OBJS-$(CONFIG_REVERSE_FILTER)+= f_reverse.o
 OBJS-$(CONFIG_ROTATE_FILTER) += vf_rotate.o
 OBJS-$(CONFIG_SAB_FILTER)+= vf_sab.o
-OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
-OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o
-OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
-OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o
+OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o scale.o
+OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
+OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o
+OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
 OBJS-$(CONFIG_SENDCMD_FILTER)+= f_sendcmd.o
diff --git a/libavfilter/scale.c b/libavfilter/scale.c
new file mode 100644
index 000..b0f4be2
--- /dev/null
+++ b/libavfilter/scale.c
@@ -0,0 +1,143 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "scale.h"
+
+static const char *const var_names[] = {
+"PI",
+"PHI",
+"E",
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow",
+"out_h",  "oh",
+"a",
+"sar",
+"dar",
+"hsub",
+"vsub",
+"ohsub",
+"ovsub",
+NULL
+};
+
+enum var_name {
+VAR_PI,
+VAR_PHI,
+VAR_E,
+VAR_IN_W,   VAR_IW,
+VAR_IN_H,   VAR_IH,
+VAR_OUT_W,  VAR_OW,
+VAR_OUT_H,  VAR_OH,
+VAR_A,
+VAR_SAR,
+VAR_DAR,
+VAR_HSUB,
+VAR_VSUB,
+VAR_OHSUB,
+VAR_OVSUB,
+VARS_NB
+};
+
+int ff_scale_eval_dimensions(void *ctx,
+const char *w_expr, const char *h_expr,
+AVFilterLink *inlink, AVFilterLink *outlink,
+int *ret_w, int *ret_h)
+{
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
+const AVPixFmtDescriptor *out_desc = av_pix_fmt_desc_get(outlink->format);
+const char *expr;
+int w, h;
+int factor_w, factor_h;
+int eval_w, eval_h;
+int ret;
+double var_values[VARS_NB], res;
+
+var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
+var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
+var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
+var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
+var_values[VAR_A] = (double) inlink->w / inlink->h;
+var_values[VAR_SAR]   = inlink->sample_aspect_ratio.num ?
+(double) inlink->sample_aspect_ratio.num / 
inlink->sample_aspect_ratio.den : 1;
+var_values[VAR_DAR]   = var_values[VAR_A] * var_values[VAR_SAR];
+var_values[VAR_HSUB]  = 1 << desc->log2_chroma_w;
+var_values[VAR_VSUB]  = 1 << desc->log2_chroma_h;
+var_values[VAR_OHSUB] = 1 << out_desc->log2_chroma_w;
+var_values[VAR_OVSUB] = 1 << out_desc->log2_chroma_h;
+
+/* evaluate width and height */
+av_expr_parse_and_eval(, (expr = w_expr),
+   var_names, var_values,
+   NULL, NULL, NULL, NULL, NULL, 0, ctx);
+eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
+
+if ((ret = av_expr_parse_and_eval(, (expr = h_expr),
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 
0)
+goto fail;
+eval_h = 

Re: [FFmpeg-devel] [PATCH] Allow borderless playback windows

2017-01-31 Thread Lucas Sandery

On 2017-02-01 08:47, Marton Balint wrote:

On Tue, 31 Jan 2017, Lucas Sandery wrote:

On 2017-01-31 11:28, Marton Balint wrote:

On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of 
playback windows into other programs. It would improve the looks in 
many situations and avoid ugly hacks like this:

http://stackoverflow.com/q/31465630/315024



Could you please add some documentation for the new option to 
doc/ffplay.texi as well?


The main patch has already been committed to master from my attempt 
via GitHub.


I've attached another patch for documentation.



Do you want your authorship to be
Lucas Sandery 
as in the patch, or simply
Lucas Sandery 
?


Use the GitHub one, I've already lost authorship of the main patch, anyway.
Also, why put un-obfuscated email addresses in a public list?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"

2017-01-31 Thread James Almer
On 1/31/2017 7:12 PM, Michael Niedermayer wrote:
> On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
>> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
>>> The assumtation this is based on is wrong, the code is not always run with 
>>> bitexact flags

Assumption not assumtation. Missed it the first time.

>>>
>>> This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
>>> changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
>>> ---
>>>  libavcodec/x86/hpeldsp.h  |  2 +-
>>>  libavcodec/x86/hpeldsp_init.c |  2 +-
>>>  libavcodec/x86/hpeldsp_vp3_init.c | 14 +-
>>>  3 files changed, 11 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
>>> index 0ecc97a83a..bf97029b57 100644
>>> --- a/libavcodec/x86/hpeldsp.h
>>> +++ b/libavcodec/x86/hpeldsp.h
>>> @@ -52,6 +52,6 @@ void ff_put_pixels16_xy2_sse2(uint8_t *block, const 
>>> uint8_t *pixels,
>>>  void ff_put_pixels16_xy2_ssse3(uint8_t *block, const uint8_t *pixels,
>>> ptrdiff_t line_size, int h);
>>>  
>>> -void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags);
>>> +void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int flags);
>>>  
>>>  #endif /* AVCODEC_X86_HPELDSP_H */
>>> diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
>>> index e583bd9ffe..58e27e3542 100644
>>> --- a/libavcodec/x86/hpeldsp_init.c
>>> +++ b/libavcodec/x86/hpeldsp_init.c
>>> @@ -309,5 +309,5 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c, int 
>>> flags)
>>>  hpeldsp_init_ssse3(c, flags);
>>>  
>>>  if (CONFIG_VP3_DECODER)
>>
>> How about checking for AV_CODEC_FLAG_BITEXACT here instead of reverting the
>> function signature? Keeps differences as minimal as possible while having
>> the same effect.
> 
> technically yes thats possible it makes the code confusing though and
> may cause bugs in the future, for example then the whole set of
> vp3 optimizations here would depend on AV_CODEC_FLAG_BITEXACT being set
> and thats unexpected. Unexpected things / surprises can be bad for code
> quality.
> 
> Anyway i can change it to that test it and resubmit if preferred ?

No, it was mostly a nit. The patch is ok as is. The differences with libav
with this change will be minimal in any case.

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


Re: [FFmpeg-devel] [PATCH] Allow borderless playback windows

2017-01-31 Thread Marton Balint


On Tue, 31 Jan 2017, Lucas Sandery wrote:


On 2017-01-31 11:28, Marton Balint wrote:

On Tue, 31 Jan 2017, Lucas Sandery wrote:
For a pure video tile effect, and enabling better integration of playback 
windows into other programs. It would improve the looks in many situations 
and avoid ugly hacks like this:

http://stackoverflow.com/q/31465630/315024



Could you please add some documentation for the new option to 
doc/ffplay.texi as well?


The main patch has already been committed to master from my attempt via 
GitHub.


I've attached another patch for documentation.



Do you want your authorship to be
Lucas Sandery 
as in the patch, or simply
Lucas Sandery 
?

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


Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 05:39:56PM -0300, James Almer wrote:
> On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> > The assumtation this is based on is wrong, the code is not always run with 
> > bitexact flags
> > 
> > This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
> > changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
> > ---
> >  libavcodec/x86/hpeldsp.h  |  2 +-
> >  libavcodec/x86/hpeldsp_init.c |  2 +-
> >  libavcodec/x86/hpeldsp_vp3_init.c | 14 +-
> >  3 files changed, 11 insertions(+), 7 deletions(-)
> > 
> > diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
> > index 0ecc97a83a..bf97029b57 100644
> > --- a/libavcodec/x86/hpeldsp.h
> > +++ b/libavcodec/x86/hpeldsp.h
> > @@ -52,6 +52,6 @@ void ff_put_pixels16_xy2_sse2(uint8_t *block, const 
> > uint8_t *pixels,
> >  void ff_put_pixels16_xy2_ssse3(uint8_t *block, const uint8_t *pixels,
> > ptrdiff_t line_size, int h);
> >  
> > -void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags);
> > +void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int flags);
> >  
> >  #endif /* AVCODEC_X86_HPELDSP_H */
> > diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
> > index e583bd9ffe..58e27e3542 100644
> > --- a/libavcodec/x86/hpeldsp_init.c
> > +++ b/libavcodec/x86/hpeldsp_init.c
> > @@ -309,5 +309,5 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c, int 
> > flags)
> >  hpeldsp_init_ssse3(c, flags);
> >  
> >  if (CONFIG_VP3_DECODER)
> 
> How about checking for AV_CODEC_FLAG_BITEXACT here instead of reverting the
> function signature? Keeps differences as minimal as possible while having
> the same effect.

technically yes thats possible it makes the code confusing though and
may cause bugs in the future, for example then the whole set of
vp3 optimizations here would depend on AV_CODEC_FLAG_BITEXACT being set
and thats unexpected. Unexpected things / surprises can be bad for code
quality.

Anyway i can change it to that test it and resubmit if preferred ?


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

No snowflake in an avalanche ever feels responsible. -- Voltaire


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


Re: [FFmpeg-devel] [PATCH] avfilter/scale_vaapi: add support for basic height/width expressions

2017-01-31 Thread Mark Thompson
On 31/01/17 21:00, Aman Gupta wrote:
> On Tue, Jan 31, 2017 at 12:26 PM, Mark Thompson  wrote:
> 
>> On 31/01/17 19:14, Aman Gupta wrote:
>>> From: Aman Gupta 
>>>
>>> Copied directly from vf_scale.c.
>>>
>>> Implements the same expression logic, however not all the variables were
>> copied over.
>>> This patch was sufficient for my particular use-case
>> `scale_vaapi=-2:min(ih\,720)`,
>>> but perhaps it makes sense to add support for the remaining variables
>>> and pull out shared code into a new vf_scale_common.c?
>>
>> I would prefer the code fragment not to be copied again, yes.
>>
>> (Implementing this and removing the duplication between scale, scale_npp,
>> scale_qsv and scale_vaapi has been on my to-maybe-do-at-some-point list for
>> quite a while, but I've never actually had a use-case for it to push me
>> into actually doing it :)
>>
> 
> Ok, I'll see if I can refactor things to avoid duplication.

Great, thank you :)

> You mentioned scale_qsv, and I see the git commit in the history that added
> it. But vf_scale_qsv.c is no where to be found on master. Do you know what
> happened to it? I'd like to implement the same logic there too if I'm
> refactoring things..

Right, yes, it's not merged yet - it's present in the libav tree and branch 
here but skipped from ffmpeg master.

Currently that merge is loosely blocked behind the ffmpeg.c filter setup being 
unsuitable for hardware transcode (the same issue that forces the 
'format=vaapi|nv12,hwupload' hack for VAAPI transcode) - the patches were 
skipped at the time due to merging issues and it has not been revisited fully 
yet.  Now, the filter does not actually depend on that because it can work 
standalone in lavfi, so I would be happy to just merge it without it being 
usable in ffmpeg.c so that this could continue.  Alternatively, since all of 
the hardware filters were merged from libav, you could work there instead.

(Or feel free to ignore that and just deal with the code you care about 
directly.  If you only do some of them then hopefully I or someone else would 
be able to sort out the others at some point.)

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


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Timo Rothenpieler
> IIRC, past conversations on this have concluded that the 'avconv'
> rewrite will allow this by
> avoiding the current problem that the encoder is fully initialised up
> front before the cuvid
> parser can run. Presumably, at some point in the future, we'll get
> through the merge backlog
> and eventually get that in.
> 
> In the meantime, I'm ok with this change. In the cases where the format
> is set correctly it
> will help, and in the cases where it is not set, it will degrade to the
> current behaviour.
> As such it's strictly an improvement.
> 

It will also not be an issue anymore once the new hw_device_ctx api
lands, at which point I'll move the creation and handling of
hw_frames_ctx entirely into cuvid.c.

Until that happens, this patch is fine with me as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avfilter/scale_vaapi: add support for basic height/width expressions

2017-01-31 Thread Aman Gupta
On Tue, Jan 31, 2017 at 12:26 PM, Mark Thompson  wrote:

> On 31/01/17 19:14, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > Copied directly from vf_scale.c.
> >
> > Implements the same expression logic, however not all the variables were
> copied over.
> > This patch was sufficient for my particular use-case
> `scale_vaapi=-2:min(ih\,720)`,
> > but perhaps it makes sense to add support for the remaining variables
> > and pull out shared code into a new vf_scale_common.c?
>
> I would prefer the code fragment not to be copied again, yes.
>
> (Implementing this and removing the duplication between scale, scale_npp,
> scale_qsv and scale_vaapi has been on my to-maybe-do-at-some-point list for
> quite a while, but I've never actually had a use-case for it to push me
> into actually doing it :)
>

Ok, I'll see if I can refactor things to avoid duplication.

You mentioned scale_qsv, and I see the git commit in the history that added
it. But vf_scale_qsv.c is no where to be found on master. Do you know what
happened to it? I'd like to implement the same logic there too if I'm
refactoring things..


>
> If you can't be bothered, then the patch looks mostly sensible to me (some
> issues below, I think mainly coming from it being copied).
>
> > ---
> >  libavfilter/vf_scale_vaapi.c | 98 ++
> --
> >  1 file changed, 95 insertions(+), 3 deletions(-)
> >
> > diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> > index d1cb246..0d1e1b3 100644
> > --- a/libavfilter/vf_scale_vaapi.c
> > +++ b/libavfilter/vf_scale_vaapi.c
> > @@ -22,6 +22,7 @@
> >  #include 
> >
> >  #include "libavutil/avassert.h"
> > +#include "libavutil/eval.h"
> >  #include "libavutil/hwcontext.h"
> >  #include "libavutil/hwcontext_vaapi.h"
> >  #include "libavutil/mem.h"
> > @@ -32,6 +33,22 @@
> >  #include "formats.h"
> >  #include "internal.h"
> >
> > +static const char *const var_names[] = {
> > +"in_w",   "iw",
> > +"in_h",   "ih",
> > +"out_w",  "ow",
> > +"out_h",  "oh",
> > +NULL
> > +};
> > +
> > +enum var_name {
> > +VAR_IN_W,   VAR_IW,
> > +VAR_IN_H,   VAR_IH,
> > +VAR_OUT_W,  VAR_OW,
> > +VAR_OUT_H,  VAR_OH,
> > +VARS_NB
> > +};
> > +
> >  typedef struct ScaleVAAPIContext {
> >  const AVClass *class;
> >
> > @@ -50,9 +67,21 @@ typedef struct ScaleVAAPIContext {
> >
> >  char *output_format_string;
> >  enum AVPixelFormat output_format;
> > +
> > +/**
> > + * New dimensions. Special values are:
> > + *   0 = original width/height
> > + *  -1 = keep original aspect
> > + *  -N = try to keep aspect but make sure it is divisible by N
> > + */
> > +int w, h;
>
> Why do these exist in addition to output_width and output_height?  They
> only seem to be used as temporaries duplicating w and h in
> scale_vaapi_config_output().
>
> > +
> > +char *w_expr;   ///< width  expression string
> > +char *h_expr;   ///< height expression string
> > +
> > +/* computed width/height */
> >  int output_width;
> >  int output_height;
> > -
> >  } ScaleVAAPIContext;
> >
> >
> > @@ -118,6 +147,14 @@ static int scale_vaapi_config_output(AVFilterLink
> *outlink)
> >  VAStatus vas;
> >  int err, i;
> >
> > +AVFilterLink *inlink = outlink->src->inputs[0];
> > +ScaleVAAPIContext *scale = ctx;
>
> Just use the ctx variable?
>
> > +int64_t w, h;
> > +double var_values[VARS_NB], res;
> > +char *expr;
>
> This variable is write-only.
>
> > +int ret;
>
> Just use err (because of the difference you aren't setting the correct
> error return if one of the evaluation operations fails).
>
> > +int factor_w, factor_h;
> > +
> >  scale_vaapi_pipeline_uninit(ctx);
> >
> >  ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
> > @@ -162,6 +199,61 @@ static int scale_vaapi_config_output(AVFilterLink
> *outlink)
> >  }
> >  }
> >
> > +var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
> > +var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
> > +var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
> > +var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
> > +
> > +/* evaluate width and height */
> > +av_expr_parse_and_eval(, (expr = scale->w_expr),
> > +   var_names, var_values,
> > +   NULL, NULL, NULL, NULL, NULL, 0, ctx);
> > +scale->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
> > +if ((ret = av_expr_parse_and_eval(, (expr = scale->h_expr),
> > +  var_names, var_values,
> > +  NULL, NULL, NULL, NULL, NULL, 0,
> ctx)) < 0)
> > +goto fail;
> > +scale->h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
> > +/* evaluate again the width, as it may depend on the output height
> */
> > +if ((ret = av_expr_parse_and_eval(, 

Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '1dfc3cf89d0eb026af28be46294b85d79499ffb5'"

2017-01-31 Thread James Almer
On 1/31/2017 5:09 PM, Michael Niedermayer wrote:
> The code is not just used by VP3, the optimizations have primarly an effect 
> on VP3
> but are used by other codecs too when available.
> 
> This reverts commit ca8a3978e57c7c8f6abab8547f47483e407469b7, reversing
> changes made to 481884080977f15854fe06e1c742a7741e49555c.

Why? The code like this can still be used by other decoders if needed.
Reverting this will only make future merges more complex.

If what you want is having these functions available even if vp3 decoder
isn't compiled, then just remove the CONFIG_VP3_DECODER check from
hpeldsp_init.c and make the new files depend on CONFIG_HPELDSP in
Makefile.

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


Re: [FFmpeg-devel] [PATCH] Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"

2017-01-31 Thread James Almer
On 1/31/2017 4:34 PM, Michael Niedermayer wrote:
> The assumtation this is based on is wrong, the code is not always run with 
> bitexact flags
> 
> This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
> changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
> ---
>  libavcodec/x86/hpeldsp.h  |  2 +-
>  libavcodec/x86/hpeldsp_init.c |  2 +-
>  libavcodec/x86/hpeldsp_vp3_init.c | 14 +-
>  3 files changed, 11 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
> index 0ecc97a83a..bf97029b57 100644
> --- a/libavcodec/x86/hpeldsp.h
> +++ b/libavcodec/x86/hpeldsp.h
> @@ -52,6 +52,6 @@ void ff_put_pixels16_xy2_sse2(uint8_t *block, const uint8_t 
> *pixels,
>  void ff_put_pixels16_xy2_ssse3(uint8_t *block, const uint8_t *pixels,
> ptrdiff_t line_size, int h);
>  
> -void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags);
> +void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int flags);
>  
>  #endif /* AVCODEC_X86_HPELDSP_H */
> diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
> index e583bd9ffe..58e27e3542 100644
> --- a/libavcodec/x86/hpeldsp_init.c
> +++ b/libavcodec/x86/hpeldsp_init.c
> @@ -309,5 +309,5 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c, int 
> flags)
>  hpeldsp_init_ssse3(c, flags);
>  
>  if (CONFIG_VP3_DECODER)

How about checking for AV_CODEC_FLAG_BITEXACT here instead of reverting the
function signature? Keeps differences as minimal as possible while having
the same effect.

> -ff_hpeldsp_vp3_init_x86(c, cpu_flags);
> +ff_hpeldsp_vp3_init_x86(c, cpu_flags, flags);
>  }
> diff --git a/libavcodec/x86/hpeldsp_vp3_init.c 
> b/libavcodec/x86/hpeldsp_vp3_init.c
> index 17fdd081f3..5979f4123c 100644
> --- a/libavcodec/x86/hpeldsp_vp3_init.c
> +++ b/libavcodec/x86/hpeldsp_vp3_init.c
> @@ -38,15 +38,19 @@ void ff_put_no_rnd_pixels8_y2_exact_3dnow(uint8_t *block,
>const uint8_t *pixels,
>ptrdiff_t line_size, int h);
>  
> -av_cold void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags)
> +av_cold void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int 
> flags)
>  {
>  if (EXTERNAL_AMD3DNOW(cpu_flags)) {
> -c->put_no_rnd_pixels_tab[1][1] = 
> ff_put_no_rnd_pixels8_x2_exact_3dnow;
> -c->put_no_rnd_pixels_tab[1][2] = 
> ff_put_no_rnd_pixels8_y2_exact_3dnow;
> +if (flags & AV_CODEC_FLAG_BITEXACT) {
> +c->put_no_rnd_pixels_tab[1][1] = 
> ff_put_no_rnd_pixels8_x2_exact_3dnow;
> +c->put_no_rnd_pixels_tab[1][2] = 
> ff_put_no_rnd_pixels8_y2_exact_3dnow;
> +}
>  }
>  
>  if (EXTERNAL_MMXEXT(cpu_flags)) {
> -c->put_no_rnd_pixels_tab[1][1] = 
> ff_put_no_rnd_pixels8_x2_exact_mmxext;
> -c->put_no_rnd_pixels_tab[1][2] = 
> ff_put_no_rnd_pixels8_y2_exact_mmxext;
> +if (flags & AV_CODEC_FLAG_BITEXACT) {
> +c->put_no_rnd_pixels_tab[1][1] = 
> ff_put_no_rnd_pixels8_x2_exact_mmxext;
> +c->put_no_rnd_pixels_tab[1][2] = 
> ff_put_no_rnd_pixels8_y2_exact_mmxext;
> +}
>  }
>  }
> 

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


Re: [FFmpeg-devel] [PATCH] avfilter/scale_vaapi: add support for basic height/width expressions

2017-01-31 Thread Mark Thompson
On 31/01/17 19:14, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Copied directly from vf_scale.c.
> 
> Implements the same expression logic, however not all the variables were 
> copied over.
> This patch was sufficient for my particular use-case 
> `scale_vaapi=-2:min(ih\,720)`,
> but perhaps it makes sense to add support for the remaining variables
> and pull out shared code into a new vf_scale_common.c?

I would prefer the code fragment not to be copied again, yes.

(Implementing this and removing the duplication between scale, scale_npp, 
scale_qsv and scale_vaapi has been on my to-maybe-do-at-some-point list for 
quite a while, but I've never actually had a use-case for it to push me into 
actually doing it :)

If you can't be bothered, then the patch looks mostly sensible to me (some 
issues below, I think mainly coming from it being copied).

> ---
>  libavfilter/vf_scale_vaapi.c | 98 
> ++--
>  1 file changed, 95 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
> index d1cb246..0d1e1b3 100644
> --- a/libavfilter/vf_scale_vaapi.c
> +++ b/libavfilter/vf_scale_vaapi.c
> @@ -22,6 +22,7 @@
>  #include 
>  
>  #include "libavutil/avassert.h"
> +#include "libavutil/eval.h"
>  #include "libavutil/hwcontext.h"
>  #include "libavutil/hwcontext_vaapi.h"
>  #include "libavutil/mem.h"
> @@ -32,6 +33,22 @@
>  #include "formats.h"
>  #include "internal.h"
>  
> +static const char *const var_names[] = {
> +"in_w",   "iw",
> +"in_h",   "ih",
> +"out_w",  "ow",
> +"out_h",  "oh",
> +NULL
> +};
> +
> +enum var_name {
> +VAR_IN_W,   VAR_IW,
> +VAR_IN_H,   VAR_IH,
> +VAR_OUT_W,  VAR_OW,
> +VAR_OUT_H,  VAR_OH,
> +VARS_NB
> +};
> +
>  typedef struct ScaleVAAPIContext {
>  const AVClass *class;
>  
> @@ -50,9 +67,21 @@ typedef struct ScaleVAAPIContext {
>  
>  char *output_format_string;
>  enum AVPixelFormat output_format;
> +
> +/**
> + * New dimensions. Special values are:
> + *   0 = original width/height
> + *  -1 = keep original aspect
> + *  -N = try to keep aspect but make sure it is divisible by N
> + */
> +int w, h;

Why do these exist in addition to output_width and output_height?  They only 
seem to be used as temporaries duplicating w and h in 
scale_vaapi_config_output().

> +
> +char *w_expr;   ///< width  expression string
> +char *h_expr;   ///< height expression string
> +
> +/* computed width/height */
>  int output_width;
>  int output_height;
> -
>  } ScaleVAAPIContext;
>  
>  
> @@ -118,6 +147,14 @@ static int scale_vaapi_config_output(AVFilterLink 
> *outlink)
>  VAStatus vas;
>  int err, i;
>  
> +AVFilterLink *inlink = outlink->src->inputs[0];
> +ScaleVAAPIContext *scale = ctx;

Just use the ctx variable?

> +int64_t w, h;
> +double var_values[VARS_NB], res;
> +char *expr;

This variable is write-only.

> +int ret;

Just use err (because of the difference you aren't setting the correct error 
return if one of the evaluation operations fails).

> +int factor_w, factor_h;
> +
>  scale_vaapi_pipeline_uninit(ctx);
>  
>  ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
> @@ -162,6 +199,61 @@ static int scale_vaapi_config_output(AVFilterLink 
> *outlink)
>  }
>  }
>  
> +var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
> +var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
> +var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
> +var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
> +
> +/* evaluate width and height */
> +av_expr_parse_and_eval(, (expr = scale->w_expr),
> +   var_names, var_values,
> +   NULL, NULL, NULL, NULL, NULL, 0, ctx);
> +scale->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
> +if ((ret = av_expr_parse_and_eval(, (expr = scale->h_expr),
> +  var_names, var_values,
> +  NULL, NULL, NULL, NULL, NULL, 0, ctx)) 
> < 0)
> +goto fail;
> +scale->h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
> +/* evaluate again the width, as it may depend on the output height */
> +if ((ret = av_expr_parse_and_eval(, (expr = scale->w_expr),
> +  var_names, var_values,
> +  NULL, NULL, NULL, NULL, NULL, 0, ctx)) 
> < 0)
> +goto fail;
> +scale->w = res;
> +
> +w = scale->w;
> +h = scale->h;
> +
> +/* Check if it is requested that the result has to be divisible by a some
> + * factor (w or h = -n with n being the factor). */
> +factor_w = 1;
> +factor_h = 1;
> +if (w < -1) {
> +factor_w = -w;
> +}
> +if (h < -1) {
> +factor_h = -h;
> +}
> +
> +if (w < 0 && h < 0)
> +   

[FFmpeg-devel] [PATCH] avformat/hlsenc: add hls_flag option to create segments atomically

2017-01-31 Thread Aman Gupta
From: Aman Gupta 

Adds a `-hls_flags +temp_file` which will write segment data to
filename.tmp, and then rename to filename when the segment is complete
and before the file is added to the m3u8 playlist.

This patch is similar in spirit to one used in Plex's ffmpeg fork, and
allows a transcoding webserver to ensure incomplete segment files are
never served up accidentally.
---
 libavformat/hlsenc.c | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index bd1e684..23b9011 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -76,6 +76,7 @@ typedef enum HLSFlags {
 HLS_SECOND_LEVEL_SEGMENT_INDEX = (1 << 8), // include segment index in 
segment filenames when use_localtime  e.g.: %%03d
 HLS_SECOND_LEVEL_SEGMENT_DURATION = (1 << 9), // include segment duration 
(microsec) in segment filenames when use_localtime  e.g.: %%09t
 HLS_SECOND_LEVEL_SEGMENT_SIZE = (1 << 10), // include segment size (bytes) 
in segment filenames when use_localtime  e.g.: %%014s
+HLS_TEMP_FILE = (1 << 11),
 } HLSFlags;
 
 typedef enum {
@@ -915,6 +916,10 @@ static int hls_start(AVFormatContext *s)
 
 set_http_options(, c);
 
+if (c->flags & HLS_TEMP_FILE) {
+av_strlcat(oc->filename, ".tmp", sizeof(oc->filename));
+}
+
 if (c->key_info_file) {
 if ((err = hls_encryption_start(s)) < 0)
 goto fail;
@@ -1276,6 +1281,15 @@ static int hls_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 
 av_write_frame(oc, NULL); /* Flush any buffered data */
 
+if (hls->flags & HLS_TEMP_FILE) {
+size_t len = strlen(oc->filename);
+char final_filename[sizeof(oc->filename)];
+av_strlcpy(final_filename, oc->filename, len);
+final_filename[len-4] = '\0';
+ff_rename(oc->filename, final_filename, s);
+oc->filename[len-4] = '\0';
+}
+
 new_start_pos = avio_tell(hls->avf->pb);
 hls->size = new_start_pos - hls->start_pos;
 ret = hls_append_segment(s, hls, hls->duration, hls->start_pos, 
hls->size);
@@ -1406,6 +1420,7 @@ static const AVOption options[] = {
 {"hls_subtitle_path", "set path of hls subtitles", 
OFFSET(subtitle_filename), AV_OPT_TYPE_STRING, {.str = NULL},  0, 0,E},
 {"hls_flags", "set flags affecting HLS playlist and media file 
generation", OFFSET(flags), AV_OPT_TYPE_FLAGS, {.i64 = 0 }, 0, UINT_MAX, E, 
"flags"},
 {"single_file",   "generate a single media file indexed with byte ranges", 
0, AV_OPT_TYPE_CONST, {.i64 = HLS_SINGLE_FILE }, 0, UINT_MAX,   E, "flags"},
+{"temp_file", "write segment to temporary file and rename when complete", 
0, AV_OPT_TYPE_CONST, {.i64 = HLS_TEMP_FILE }, 0, UINT_MAX,   E, "flags"},
 {"delete_segments", "delete segment files that are no longer part of the 
playlist", 0, AV_OPT_TYPE_CONST, {.i64 = HLS_DELETE_SEGMENTS }, 0, UINT_MAX,   
E, "flags"},
 {"round_durations", "round durations in m3u8 to whole numbers", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_ROUND_DURATIONS }, 0, UINT_MAX,   E, "flags"},
 {"discont_start", "start the playlist with a discontinuity tag", 0, 
AV_OPT_TYPE_CONST, {.i64 = HLS_DISCONT_START }, 0, UINT_MAX,   E, "flags"},
-- 
2.10.1 (Apple Git-78)

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


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Philip Langdale

On 2017-01-31 07:45, wm4 wrote:

On Tue, 31 Jan 2017 15:38:33 +
Sumit Agarwal  wrote:


From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
From: sumit 
Date: Tue, 31 Jan 2017 21:00:50 +0530
Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid

---
 ffmpeg_cuvid.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ffmpeg_cuvid.c b/ffmpeg_cuvid.c
index 766878f..baf6eee 100644
--- a/ffmpeg_cuvid.c
+++ b/ffmpeg_cuvid.c
@@ -135,7 +135,7 @@ int cuvid_transcode_init(OutputStream *ost)
  */
 hwframe_ctx = (AVHWFramesContext*)ctx->hw_frames_ctx->data;
 hwframe_ctx->format = AV_PIX_FMT_CUDA;
-hwframe_ctx->sw_format = AV_PIX_FMT_NV12;
+hwframe_ctx->sw_format = ist->st->codecpar->format == 
AV_PIX_FMT_YUV420P10 ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;

 }

 return 0;


This relies on the format reported by the demuxer, which may or may not
work, depending on what the parser or decoder ran by libavformat does.
It might work on most cases, but it's still a bad idea.

The right way to implement this is letting cuvid parse the codec data
(e.g. SPS), and then use the values reported by it.


IIRC, past conversations on this have concluded that the 'avconv' 
rewrite will allow this by
avoiding the current problem that the encoder is fully initialised up 
front before the cuvid
parser can run. Presumably, at some point in the future, we'll get 
through the merge backlog

and eventually get that in.

In the meantime, I'm ok with this change. In the cases where the format 
is set correctly it
will help, and in the cases where it is not set, it will degrade to the 
current behaviour.

As such it's strictly an improvement.

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


[FFmpeg-devel] [PATCH] Revert "Merge commit '1dfc3cf89d0eb026af28be46294b85d79499ffb5'"

2017-01-31 Thread Michael Niedermayer
The code is not just used by VP3, the optimizations have primarly an effect on 
VP3
but are used by other codecs too when available.

This reverts commit ca8a3978e57c7c8f6abab8547f47483e407469b7, reversing
changes made to 481884080977f15854fe06e1c742a7741e49555c.
---
 libavcodec/x86/Makefile   |   2 -
 libavcodec/x86/hpeldsp.asm|  89 ++
 libavcodec/x86/hpeldsp.h  |   4 --
 libavcodec/x86/hpeldsp_init.c |  25 +++--
 libavcodec/x86/hpeldsp_vp3.asm| 111 --
 libavcodec/x86/hpeldsp_vp3_init.c |  56 ---
 6 files changed, 111 insertions(+), 176 deletions(-)
 delete mode 100644 libavcodec/x86/hpeldsp_vp3.asm
 delete mode 100644 libavcodec/x86/hpeldsp_vp3_init.c

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 28649522ff..2f0354a2c8 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -67,7 +67,6 @@ OBJS-$(CONFIG_TTA_ENCODER) += x86/ttaencdsp_init.o
 OBJS-$(CONFIG_V210_DECODER)+= x86/v210-init.o
 OBJS-$(CONFIG_V210_ENCODER)+= x86/v210enc_init.o
 OBJS-$(CONFIG_VORBIS_DECODER)  += x86/vorbisdsp_init.o
-OBJS-$(CONFIG_VP3_DECODER) += x86/hpeldsp_vp3_init.o
 OBJS-$(CONFIG_VP6_DECODER) += x86/vp6dsp_init.o
 OBJS-$(CONFIG_VP9_DECODER) += x86/vp9dsp_init.o\
   x86/vp9dsp_init_10bpp.o  \
@@ -170,7 +169,6 @@ YASM-OBJS-$(CONFIG_TTA_ENCODER)+= x86/ttaencdsp.o
 YASM-OBJS-$(CONFIG_V210_ENCODER)   += x86/v210enc.o
 YASM-OBJS-$(CONFIG_V210_DECODER)   += x86/v210.o
 YASM-OBJS-$(CONFIG_VORBIS_DECODER) += x86/vorbisdsp.o
-YASM-OBJS-$(CONFIG_VP3_DECODER)+= x86/hpeldsp_vp3.o
 YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
 YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
   x86/vp9intrapred_16bpp.o  \
diff --git a/libavcodec/x86/hpeldsp.asm b/libavcodec/x86/hpeldsp.asm
index ce5d7a4e28..82fb8934af 100644
--- a/libavcodec/x86/hpeldsp.asm
+++ b/libavcodec/x86/hpeldsp.asm
@@ -175,6 +175,53 @@ INIT_MMX 3dnow
 PUT_NO_RND_PIXELS8_X2
 
 
+; void ff_put_no_rnd_pixels8_x2_exact(uint8_t *block, const uint8_t *pixels, 
ptrdiff_t line_size, int h)
+%macro PUT_NO_RND_PIXELS8_X2_EXACT 0
+cglobal put_no_rnd_pixels8_x2_exact, 4,5
+lea  r4, [r2*3]
+pcmpeqb  m6, m6
+.loop:
+mova m0, [r1]
+mova m2, [r1+r2]
+mova m1, [r1+1]
+mova m3, [r1+r2+1]
+pxor m0, m6
+pxor m2, m6
+pxor m1, m6
+pxor m3, m6
+PAVGBm0, m1
+PAVGBm2, m3
+pxor m0, m6
+pxor m2, m6
+mova   [r0], m0
+mova[r0+r2], m2
+mova m0, [r1+r2*2]
+mova m1, [r1+r2*2+1]
+mova m2, [r1+r4]
+mova m3, [r1+r4+1]
+pxor m0, m6
+pxor m1, m6
+pxor m2, m6
+pxor m3, m6
+PAVGBm0, m1
+PAVGBm2, m3
+pxor m0, m6
+pxor m2, m6
+mova  [r0+r2*2], m0
+mova[r0+r4], m2
+lea  r1, [r1+r2*4]
+lea  r0, [r0+r2*4]
+sub r3d, 4
+jg .loop
+REP_RET
+%endmacro
+
+INIT_MMX mmxext
+PUT_NO_RND_PIXELS8_X2_EXACT
+INIT_MMX 3dnow
+PUT_NO_RND_PIXELS8_X2_EXACT
+
+
 ; void ff_put_pixels8_y2(uint8_t *block, const uint8_t *pixels, ptrdiff_t 
line_size, int h)
 %macro PUT_PIXELS8_Y2 0
 %if cpuflag(sse2)
@@ -253,6 +300,48 @@ INIT_MMX 3dnow
 PUT_NO_RND_PIXELS8_Y2
 
 
+; void ff_put_no_rnd_pixels8_y2_exact(uint8_t *block, const uint8_t *pixels, 
ptrdiff_t line_size, int h)
+%macro PUT_NO_RND_PIXELS8_Y2_EXACT 0
+cglobal put_no_rnd_pixels8_y2_exact, 4,5
+lea  r4, [r2*3]
+mova m0, [r1]
+pcmpeqb  m6, m6
+add  r1, r2
+pxor m0, m6
+.loop:
+mova m1, [r1]
+mova m2, [r1+r2]
+pxor m1, m6
+pxor m2, m6
+PAVGBm0, m1
+PAVGBm1, m2
+pxor m0, m6
+pxor m1, m6
+mova   [r0], m0
+mova[r0+r2], m1
+mova m1, [r1+r2*2]
+mova m0, [r1+r4]
+pxor m1, m6
+pxor m0, m6
+PAVGBm2, m1
+PAVGBm1, m0
+pxor m2, m6
+pxor m1, m6
+mova  [r0+r2*2], m2
+mova[r0+r4], m1
+lea  r1, [r1+r2*4]
+lea  r0, [r0+r2*4]
+sub r3d, 4
+jg .loop
+REP_RET
+%endmacro
+
+INIT_MMX mmxext
+PUT_NO_RND_PIXELS8_Y2_EXACT
+INIT_MMX 3dnow
+PUT_NO_RND_PIXELS8_Y2_EXACT
+
+
 ; void ff_avg_pixels8(uint8_t *block, const uint8_t *pixels, ptrdiff_t 
line_size, int h)
 %macro AVG_PIXELS8 0
 cglobal avg_pixels8, 4,5
diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
index bf97029b57..5fae990a4f 100644
--- a/libavcodec/x86/hpeldsp.h
+++ 

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-01-31 Thread Chris Cunningham
On Tue, Jan 31, 2017 at 1:07 AM, wm4  wrote:

> On Tue, 31 Jan 2017 09:57:24 +0100
> wm4  wrote:
>
> > On Mon, 30 Jan 2017 17:05:49 -0800
> > Chris Cunningham  wrote:
> >
> > > Blocks are marked as key frames whenever the "reference" field is
> > > zero. This is incorrect for non-keyframe Blocks that take a refernce
> > > on a keyframe at time zero.
> > >
> > > Now using -1 to denote "no reference".
> > >
> > > Reported to chromium at http://crbug.com/497889 (contains sample)
> > > ---
> > >  libavformat/matroskadec.c | 9 ++---
> > >  1 file changed, 6 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > > index e6737a70b2..0d033b574c 100644
> > > --- a/libavformat/matroskadec.c
> > > +++ b/libavformat/matroskadec.c
> > > @@ -89,6 +89,7 @@ typedef const struct EbmlSyntax {
> > >  int list_elem_size;
> > >  int data_offset;
> > >  union {
> > > +int64_t i;
> > >  uint64_tu;
> > >  double  f;
> > >  const char *s;
> > > @@ -696,7 +697,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
> > >  { MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0,
> offsetof(MatroskaBlock, bin) },
> > >  { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0,
> offsetof(MatroskaBlock, duration) },
> > >  { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0,
> offsetof(MatroskaBlock, discard_padding) },
> > > -{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0,
> offsetof(MatroskaBlock, reference) },
> > > +{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0,
> offsetof(MatroskaBlock, reference), { .i = -1 } },
> > >  { MATROSKA_ID_CODECSTATE, EBML_NONE },
> > >  {  1, EBML_UINT, 0,
> offsetof(MatroskaBlock, non_simple), { .u = 1 } },
> > >  { 0 }
> > > @@ -1071,6 +1072,8 @@ static int ebml_parse_nest(MatroskaDemuxContext
> *matroska, EbmlSyntax *syntax,
> > >
> > >  for (i = 0; syntax[i].id; i++)
> > >  switch (syntax[i].type) {
> > > +case EBML_SINT:
> > > +*(int64_t *) ((char *) data + syntax[i].data_offset) =
> syntax[i].def.i;
> > >  case EBML_UINT:
> >
> > Isn't there a break missing?
> >
> > >  *(uint64_t *) ((char *) data + syntax[i].data_offset) =
> syntax[i].def.u;
> > >  break;
> > > @@ -3361,7 +3364,7 @@ static int 
> > > matroska_parse_cluster_incremental(MatroskaDemuxContext
> *matroska)
> > >  matroska->current_cluster_num_blocks = blocks_list->nb_elem;
> > >  i= blocks_list->nb_elem -
> 1;
> > >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> > > -int is_keyframe = blocks[i].non_simple ?
> !blocks[i].reference : -1;
> > > +int is_keyframe = blocks[i].non_simple ?
> blocks[i].reference == -1 : -1;
> > >  uint8_t* additional = blocks[i].additional.size > 0 ?
> > >  blocks[i].additional.data : NULL;
> > >  if (!blocks[i].non_simple)
> > > @@ -3399,7 +3402,7 @@ static int 
> > > matroska_parse_cluster(MatroskaDemuxContext
> *matroska)
> > >  blocks  = blocks_list->elem;
> > >  for (i = 0; i < blocks_list->nb_elem; i++)
> > >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> > > -int is_keyframe = blocks[i].non_simple ?
> !blocks[i].reference : -1;
> > > +int is_keyframe = blocks[i].non_simple ?
> blocks[i].reference == -1 : -1;
> > >  res = matroska_parse_block(matroska, blocks[i].bin.data,
> > > blocks[i].bin.size,
> blocks[i].bin.pos,
> > > cluster.timecode,
> blocks[i].duration,
> >
> > I don't quite trust this. The file has negative block references too
> > (what do they even mean?). E.g. one block uses "-123". This doesn't
> > make much sense to me, and at the very least it means -1 is not a safe
> > dummy value (because negative values don't mean non-keyframe according
> > to your patch, while -1 as exception does).
> >
> > The oldest/most used (until recently at least) mkv demuxer, Haali
> > actually does every block reference element as a non-keyframe:
> >
> > http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=
> libavformat/MatroskaParser.c;h=173c2e1c20da59d4cf0b501639c470
> 331cd4515f;hb=HEAD#l2354
> >
> > This seems much safer.
> >
> > Do you have any insight why the file contains such erratic seeming
> > reference values? I'm sure I'm missing something. Or is it a broken
> > muxer/broken file?
>
> Oh, nevermind. The values in the reference elements are
> supposed to be _relative_ timestamps. This means -1 is still not a safe
> dummy value. But then, what is a value of "0" supposed to mean?
>
> Going after Haali seems the safest fix, as it most likely won't break
> anything.
> ___
> ffmpeg-devel mailing list
> 

[FFmpeg-devel] [PATCH] Revert "Merge commit '0a39c9ac0bfd7345fe676b4e2707d9cec3cbb553'"

2017-01-31 Thread Michael Niedermayer
The assumtation this is based on is wrong, the code is not always run with 
bitexact flags

This reverts commit a956164e1eb3418922cae949f02ad4035f013213, reversing
changes made to f6005907fdeb9e4de37568ed5c1a8e7b869126f6.
---
 libavcodec/x86/hpeldsp.h  |  2 +-
 libavcodec/x86/hpeldsp_init.c |  2 +-
 libavcodec/x86/hpeldsp_vp3_init.c | 14 +-
 3 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/libavcodec/x86/hpeldsp.h b/libavcodec/x86/hpeldsp.h
index 0ecc97a83a..bf97029b57 100644
--- a/libavcodec/x86/hpeldsp.h
+++ b/libavcodec/x86/hpeldsp.h
@@ -52,6 +52,6 @@ void ff_put_pixels16_xy2_sse2(uint8_t *block, const uint8_t 
*pixels,
 void ff_put_pixels16_xy2_ssse3(uint8_t *block, const uint8_t *pixels,
ptrdiff_t line_size, int h);
 
-void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags);
+void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int flags);
 
 #endif /* AVCODEC_X86_HPELDSP_H */
diff --git a/libavcodec/x86/hpeldsp_init.c b/libavcodec/x86/hpeldsp_init.c
index e583bd9ffe..58e27e3542 100644
--- a/libavcodec/x86/hpeldsp_init.c
+++ b/libavcodec/x86/hpeldsp_init.c
@@ -309,5 +309,5 @@ av_cold void ff_hpeldsp_init_x86(HpelDSPContext *c, int 
flags)
 hpeldsp_init_ssse3(c, flags);
 
 if (CONFIG_VP3_DECODER)
-ff_hpeldsp_vp3_init_x86(c, cpu_flags);
+ff_hpeldsp_vp3_init_x86(c, cpu_flags, flags);
 }
diff --git a/libavcodec/x86/hpeldsp_vp3_init.c 
b/libavcodec/x86/hpeldsp_vp3_init.c
index 17fdd081f3..5979f4123c 100644
--- a/libavcodec/x86/hpeldsp_vp3_init.c
+++ b/libavcodec/x86/hpeldsp_vp3_init.c
@@ -38,15 +38,19 @@ void ff_put_no_rnd_pixels8_y2_exact_3dnow(uint8_t *block,
   const uint8_t *pixels,
   ptrdiff_t line_size, int h);
 
-av_cold void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags)
+av_cold void ff_hpeldsp_vp3_init_x86(HpelDSPContext *c, int cpu_flags, int 
flags)
 {
 if (EXTERNAL_AMD3DNOW(cpu_flags)) {
-c->put_no_rnd_pixels_tab[1][1] = ff_put_no_rnd_pixels8_x2_exact_3dnow;
-c->put_no_rnd_pixels_tab[1][2] = ff_put_no_rnd_pixels8_y2_exact_3dnow;
+if (flags & AV_CODEC_FLAG_BITEXACT) {
+c->put_no_rnd_pixels_tab[1][1] = 
ff_put_no_rnd_pixels8_x2_exact_3dnow;
+c->put_no_rnd_pixels_tab[1][2] = 
ff_put_no_rnd_pixels8_y2_exact_3dnow;
+}
 }
 
 if (EXTERNAL_MMXEXT(cpu_flags)) {
-c->put_no_rnd_pixels_tab[1][1] = ff_put_no_rnd_pixels8_x2_exact_mmxext;
-c->put_no_rnd_pixels_tab[1][2] = ff_put_no_rnd_pixels8_y2_exact_mmxext;
+if (flags & AV_CODEC_FLAG_BITEXACT) {
+c->put_no_rnd_pixels_tab[1][1] = 
ff_put_no_rnd_pixels8_x2_exact_mmxext;
+c->put_no_rnd_pixels_tab[1][2] = 
ff_put_no_rnd_pixels8_y2_exact_mmxext;
+}
 }
 }
-- 
2.11.0

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


[FFmpeg-devel] [PATCH] avfilter/scale_vaapi: add support for basic height/width expressions

2017-01-31 Thread Aman Gupta
From: Aman Gupta 

Copied directly from vf_scale.c.

Implements the same expression logic, however not all the variables were copied 
over.
This patch was sufficient for my particular use-case 
`scale_vaapi=-2:min(ih\,720)`,
but perhaps it makes sense to add support for the remaining variables
and pull out shared code into a new vf_scale_common.c?
---
 libavfilter/vf_scale_vaapi.c | 98 ++--
 1 file changed, 95 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index d1cb246..0d1e1b3 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -22,6 +22,7 @@
 #include 
 
 #include "libavutil/avassert.h"
+#include "libavutil/eval.h"
 #include "libavutil/hwcontext.h"
 #include "libavutil/hwcontext_vaapi.h"
 #include "libavutil/mem.h"
@@ -32,6 +33,22 @@
 #include "formats.h"
 #include "internal.h"
 
+static const char *const var_names[] = {
+"in_w",   "iw",
+"in_h",   "ih",
+"out_w",  "ow",
+"out_h",  "oh",
+NULL
+};
+
+enum var_name {
+VAR_IN_W,   VAR_IW,
+VAR_IN_H,   VAR_IH,
+VAR_OUT_W,  VAR_OW,
+VAR_OUT_H,  VAR_OH,
+VARS_NB
+};
+
 typedef struct ScaleVAAPIContext {
 const AVClass *class;
 
@@ -50,9 +67,21 @@ typedef struct ScaleVAAPIContext {
 
 char *output_format_string;
 enum AVPixelFormat output_format;
+
+/**
+ * New dimensions. Special values are:
+ *   0 = original width/height
+ *  -1 = keep original aspect
+ *  -N = try to keep aspect but make sure it is divisible by N
+ */
+int w, h;
+
+char *w_expr;   ///< width  expression string
+char *h_expr;   ///< height expression string
+
+/* computed width/height */
 int output_width;
 int output_height;
-
 } ScaleVAAPIContext;
 
 
@@ -118,6 +147,14 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 VAStatus vas;
 int err, i;
 
+AVFilterLink *inlink = outlink->src->inputs[0];
+ScaleVAAPIContext *scale = ctx;
+int64_t w, h;
+double var_values[VARS_NB], res;
+char *expr;
+int ret;
+int factor_w, factor_h;
+
 scale_vaapi_pipeline_uninit(ctx);
 
 ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
@@ -162,6 +199,61 @@ static int scale_vaapi_config_output(AVFilterLink *outlink)
 }
 }
 
+var_values[VAR_IN_W]  = var_values[VAR_IW] = inlink->w;
+var_values[VAR_IN_H]  = var_values[VAR_IH] = inlink->h;
+var_values[VAR_OUT_W] = var_values[VAR_OW] = NAN;
+var_values[VAR_OUT_H] = var_values[VAR_OH] = NAN;
+
+/* evaluate width and height */
+av_expr_parse_and_eval(, (expr = scale->w_expr),
+   var_names, var_values,
+   NULL, NULL, NULL, NULL, NULL, 0, ctx);
+scale->w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
+if ((ret = av_expr_parse_and_eval(, (expr = scale->h_expr),
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 
0)
+goto fail;
+scale->h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
+/* evaluate again the width, as it may depend on the output height */
+if ((ret = av_expr_parse_and_eval(, (expr = scale->w_expr),
+  var_names, var_values,
+  NULL, NULL, NULL, NULL, NULL, 0, ctx)) < 
0)
+goto fail;
+scale->w = res;
+
+w = scale->w;
+h = scale->h;
+
+/* Check if it is requested that the result has to be divisible by a some
+ * factor (w or h = -n with n being the factor). */
+factor_w = 1;
+factor_h = 1;
+if (w < -1) {
+factor_w = -w;
+}
+if (h < -1) {
+factor_h = -h;
+}
+
+if (w < 0 && h < 0)
+scale->w = scale->h = 0;
+
+if (!(w = scale->w))
+w = inlink->w;
+if (!(h = scale->h))
+h = inlink->h;
+
+/* Make sure that the result is divisible by the factor we determined
+ * earlier. If no factor was set, it is nothing will happen as the default
+ * factor is 1 */
+if (w < 0)
+w = av_rescale(h, inlink->w, inlink->h * factor_w) * factor_w;
+if (h < 0)
+h = av_rescale(w, inlink->h, inlink->w * factor_h) * factor_h;
+
+ctx->output_width = w;
+ctx->output_height = h;
+
 if (ctx->output_width  < constraints->min_width  ||
 ctx->output_height < constraints->min_height ||
 ctx->output_width  > constraints->max_width  ||
@@ -414,9 +506,9 @@ static av_cold void scale_vaapi_uninit(AVFilterContext 
*avctx)
 #define FLAGS (AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM)
 static const AVOption scale_vaapi_options[] = {
 { "w", "Output video width",
-  OFFSET(output_width),  AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, .flags 
= FLAGS },
+  OFFSET(w_expr), AV_OPT_TYPE_STRING, .flags = FLAGS },
 { 

Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 17:00 GMT+01:00 Petri Hintukainen :

> I think I posted HDMV text subtitle decoder patch year+ ago. But I
> can't find it from list archives (?).

I suspect because you didn't sent it =-(
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/178194.html

Thank for for providing it now!

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Andy Furniss

DogFilm wrote:

I am still waitinng for an upload facility. Please send me an email so I
can follow this.


You have a gmail address so I guess you have google drive.

Assuming you have the free version then upload size limit is too small
for 1.6 gig.

You could upload in two parts and post the 2 links.

To split the file without ffmpeg use dd eg.

dd if=FFMPEG-DESTROY_20170103.mp4 of=part-one bs=1M count=800

and

dd if=FFMPEG-DESTROY_20170103.mp4 of=part-two bs=1M skip=800

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


Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

2017-01-31 Thread Eran Kornblau
> On Tue, Jan 31, 2017 at 06:28:16PM +0100, Michael Niedermayer wrote:
> > On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> > > patch looks good to me.
> > 
> > applied
> 
> maybe i asked already but it seems the Author field of your commits is 
> inconsistet in git
> 
> some say:
> Author: erankor 
> 
> some say:
> Author: Eran Kornblau 
> 
> Is the way the patches are intended ?
> Just double checking as it cannot be changed later 
> 

Thanks Michael & Sasi!

My GitHub user is erankor, that's the user that should be used.
I've just checked this patch and it says 'erankor', where did you see 'Eran 
Kornblau'?

And thanks again for noticing :)

Eran

> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> When you are offended at any man's fault, turn to yourself and study your own 
> failings. Then you will forget your anger. -- Epictetus
> 

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


Re: [FFmpeg-devel] [PATCH] avcodec: add ATRAC Advanced Lossless decoders

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 06:29:03PM +0100, Paul B Mahol wrote:
> On 1/31/17, Michael Niedermayer  wrote:
> > On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
> >> On 1/31/17, Michael Niedermayer  wrote:
> >> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> >> >> Only lossy part is decoded for now.
> >> >>
> >> >> Signed-off-by: Paul B Mahol 
> >> >> ---
> >> > [...]
> >> >>  static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
> >> >>  {
> >> >>  OMAContext *oc  = s->priv_data;
> >> >> -AVStream *st= s->streams[0];
> >> >> -int packet_size = st->codecpar->block_align;
> >> >> -int byte_rate   = st->codecpar->bit_rate >> 3;
> >> >> -int64_t pos = avio_tell(s->pb);
> >> >> -int ret = av_get_packet(s->pb, pkt, packet_size);
> >> >> -
> >> >> -if (ret < packet_size)
> >> >> -pkt->flags |= AV_PKT_FLAG_CORRUPT;
> >> >> -
> >> >> -if (ret < 0)
> >> >> -return ret;
> >> >> -if (!ret)
> >> >> -return AVERROR_EOF;
> >> >> -
> >> >> -pkt->stream_index = 0;
> >> >> -
> >> >> -if (pos >= oc->content_start && byte_rate > 0) {
> >> >> -pkt->pts =
> >> >> -pkt->dts = av_rescale(pos - oc->content_start,
> >> >> st->time_base.den,
> >> >> -  byte_rate *
> >> >> (int64_t)st->time_base.num);
> >> >> -}
> >> >> -
> >> >> -if (oc->encrypted) {
> >> >> -/* previous unencrypted block saved in IV for
> >> >> - * the next packet (CBC mode) */
> >> >> -if (ret == packet_size)
> >> >> -av_des_crypt(oc->av_des, pkt->data, pkt->data,
> >> >> - (packet_size >> 3), oc->iv, 1);
> >> >> -else
> >> >> -memset(oc->iv, 0, 8);
> >> >> -}
> >> >> -
> >> >> -return ret;
> >> >> +return oc->read_packet(s, pkt);
> >> >>  }
> >> >
> >> > moving this into read_packet() could be done in a seperate patch
> >> >
> >> >
> >> >>
> >> >>  static int oma_read_probe(AVProbeData *p)
> >> >> @@ -491,8 +571,14 @@ static int oma_read_seek(struct AVFormatContext
> >> >> *s,
> >> >>   int stream_index, int64_t timestamp, int
> >> >> flags)
> >> >>  {
> >> >>  OMAContext *oc = s->priv_data;
> >> >> -int64_t err = ff_pcm_read_seek(s, stream_index, timestamp,
> >> >> flags);
> >> >> +AVStream *st = s->streams[0];
> >> >> +int64_t err;
> >> >> +
> >> >> +if (st->codecpar->codec_id == AV_CODEC_ID_ATRAC3PAL ||
> >> >> +st->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL)
> >> >
> >> >> +return -1;
> >> >
> >> > should be a AVERROR code
> >>
> >> This is not error, it makes seeking possible, using other error codes
> >> is bad idea.
> >
> > It would be better to use a named identifier than a litteral number
> > normally we use AVERROR_*, i would argue that oma_read_seek() did not
> > seek so it didnt succeed but if you prefer this to be called something
> > else than AVERROR_* sure iam perfectly fine with what you prefer.
> >
> > It was the use of a litteral number (which is also undocumented for
> > read_seek() except by code returning -1) that i wanted to comment on
> 
> -1 means use generice seeking.

I think any negative return results in that unless disabled but its
long ago that i worked on this code.

-1 is kind of bad because it is not descriptive, a reader doesnt know
what that does also -1 == AVERROR(EPERM) here
so it cannot be distinguished from that error

i think we should add and use soemthing like
return AVERROR_USE_GENERIC_SEEK;
return FF_USE_GENERIC_SEEK;
return FALLBACK_TO_GENERIC_SEEK;
return WHATEVER_ELSE_ONE_LIKES_TO_CALL_IT;



[...]
-- 
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


[FFmpeg-devel] [PATCH] avutil/eval: Add av_expr_freep()

2017-01-31 Thread Michael Niedermayer
In many uses of av_expr_free() the pointer is NULLed afterwards, this should
allow simplifying such code

TODO: add bump& APIChanges

Signed-off-by: Michael Niedermayer 
---
 libavutil/eval.c | 7 +++
 libavutil/eval.h | 6 ++
 2 files changed, 13 insertions(+)

diff --git a/libavutil/eval.c b/libavutil/eval.c
index 7e866155db..b926ddb8bf 100644
--- a/libavutil/eval.c
+++ b/libavutil/eval.c
@@ -327,6 +327,13 @@ void av_expr_free(AVExpr *e)
 av_freep();
 }
 
+void av_expr_freep(AVExpr **e)
+{
+if(!e) return;
+av_expr_free(*e);
+*e = NULL;
+}
+
 static int parse_primary(AVExpr **e, Parser *p)
 {
 AVExpr *d = av_mallocz(sizeof(AVExpr));
diff --git a/libavutil/eval.h b/libavutil/eval.h
index dacd22b96e..8653b74a55 100644
--- a/libavutil/eval.h
+++ b/libavutil/eval.h
@@ -92,6 +92,12 @@ double av_expr_eval(AVExpr *e, const double *const_values, 
void *opaque);
 void av_expr_free(AVExpr *e);
 
 /**
+ * Free a parsed expression previously created with av_expr_parse() and NULL 
its
+ * pointer.
+ */
+void av_expr_freep(AVExpr **e);
+
+/**
  * Parse the string in numstr and return its value as a double. If
  * the string is empty, contains only whitespaces, or does not contain
  * an initial substring that has the expected syntax for a
-- 
2.11.0

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


Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 06:28:16PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> > patch looks good to me.
> 
> applied

maybe i asked already but it seems the Author field of your commits
is inconsistet in git

some say:
Author: erankor 

some say:
Author: Eran Kornblau 

Is the way the patches are intended ?
Just double checking as it cannot be changed later 

[...]

-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] mov: support for multiple edits and cenc decryption

2017-01-31 Thread Michael Niedermayer
On Mon, Jan 30, 2017 at 10:51:00AM -0800, Sasi Inguva wrote:
> patch looks good to me.

applied

thanks

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- 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] avcodec: add ATRAC Advanced Lossless decoders

2017-01-31 Thread Paul B Mahol
On 1/31/17, Michael Niedermayer  wrote:
> On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
>> On 1/31/17, Michael Niedermayer  wrote:
>> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
>> >> Only lossy part is decoded for now.
>> >>
>> >> Signed-off-by: Paul B Mahol 
>> >> ---
>> > [...]
>> >>  static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
>> >>  {
>> >>  OMAContext *oc  = s->priv_data;
>> >> -AVStream *st= s->streams[0];
>> >> -int packet_size = st->codecpar->block_align;
>> >> -int byte_rate   = st->codecpar->bit_rate >> 3;
>> >> -int64_t pos = avio_tell(s->pb);
>> >> -int ret = av_get_packet(s->pb, pkt, packet_size);
>> >> -
>> >> -if (ret < packet_size)
>> >> -pkt->flags |= AV_PKT_FLAG_CORRUPT;
>> >> -
>> >> -if (ret < 0)
>> >> -return ret;
>> >> -if (!ret)
>> >> -return AVERROR_EOF;
>> >> -
>> >> -pkt->stream_index = 0;
>> >> -
>> >> -if (pos >= oc->content_start && byte_rate > 0) {
>> >> -pkt->pts =
>> >> -pkt->dts = av_rescale(pos - oc->content_start,
>> >> st->time_base.den,
>> >> -  byte_rate *
>> >> (int64_t)st->time_base.num);
>> >> -}
>> >> -
>> >> -if (oc->encrypted) {
>> >> -/* previous unencrypted block saved in IV for
>> >> - * the next packet (CBC mode) */
>> >> -if (ret == packet_size)
>> >> -av_des_crypt(oc->av_des, pkt->data, pkt->data,
>> >> - (packet_size >> 3), oc->iv, 1);
>> >> -else
>> >> -memset(oc->iv, 0, 8);
>> >> -}
>> >> -
>> >> -return ret;
>> >> +return oc->read_packet(s, pkt);
>> >>  }
>> >
>> > moving this into read_packet() could be done in a seperate patch
>> >
>> >
>> >>
>> >>  static int oma_read_probe(AVProbeData *p)
>> >> @@ -491,8 +571,14 @@ static int oma_read_seek(struct AVFormatContext
>> >> *s,
>> >>   int stream_index, int64_t timestamp, int
>> >> flags)
>> >>  {
>> >>  OMAContext *oc = s->priv_data;
>> >> -int64_t err = ff_pcm_read_seek(s, stream_index, timestamp,
>> >> flags);
>> >> +AVStream *st = s->streams[0];
>> >> +int64_t err;
>> >> +
>> >> +if (st->codecpar->codec_id == AV_CODEC_ID_ATRAC3PAL ||
>> >> +st->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL)
>> >
>> >> +return -1;
>> >
>> > should be a AVERROR code
>>
>> This is not error, it makes seeking possible, using other error codes
>> is bad idea.
>
> It would be better to use a named identifier than a litteral number
> normally we use AVERROR_*, i would argue that oma_read_seek() did not
> seek so it didnt succeed but if you prefer this to be called something
> else than AVERROR_* sure iam perfectly fine with what you prefer.
>
> It was the use of a litteral number (which is also undocumented for
> read_seek() except by code returning -1) that i wanted to comment on

-1 means use generice seeking.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add ATRAC Advanced Lossless decoders

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 04:17:19PM +0100, Paul B Mahol wrote:
> On 1/31/17, Michael Niedermayer  wrote:
> > On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> >> Only lossy part is decoded for now.
> >>
> >> Signed-off-by: Paul B Mahol 
> >> ---
> > [...]
> >>  static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
> >>  {
> >>  OMAContext *oc  = s->priv_data;
> >> -AVStream *st= s->streams[0];
> >> -int packet_size = st->codecpar->block_align;
> >> -int byte_rate   = st->codecpar->bit_rate >> 3;
> >> -int64_t pos = avio_tell(s->pb);
> >> -int ret = av_get_packet(s->pb, pkt, packet_size);
> >> -
> >> -if (ret < packet_size)
> >> -pkt->flags |= AV_PKT_FLAG_CORRUPT;
> >> -
> >> -if (ret < 0)
> >> -return ret;
> >> -if (!ret)
> >> -return AVERROR_EOF;
> >> -
> >> -pkt->stream_index = 0;
> >> -
> >> -if (pos >= oc->content_start && byte_rate > 0) {
> >> -pkt->pts =
> >> -pkt->dts = av_rescale(pos - oc->content_start,
> >> st->time_base.den,
> >> -  byte_rate * (int64_t)st->time_base.num);
> >> -}
> >> -
> >> -if (oc->encrypted) {
> >> -/* previous unencrypted block saved in IV for
> >> - * the next packet (CBC mode) */
> >> -if (ret == packet_size)
> >> -av_des_crypt(oc->av_des, pkt->data, pkt->data,
> >> - (packet_size >> 3), oc->iv, 1);
> >> -else
> >> -memset(oc->iv, 0, 8);
> >> -}
> >> -
> >> -return ret;
> >> +return oc->read_packet(s, pkt);
> >>  }
> >
> > moving this into read_packet() could be done in a seperate patch
> >
> >
> >>
> >>  static int oma_read_probe(AVProbeData *p)
> >> @@ -491,8 +571,14 @@ static int oma_read_seek(struct AVFormatContext *s,
> >>   int stream_index, int64_t timestamp, int flags)
> >>  {
> >>  OMAContext *oc = s->priv_data;
> >> -int64_t err = ff_pcm_read_seek(s, stream_index, timestamp, flags);
> >> +AVStream *st = s->streams[0];
> >> +int64_t err;
> >> +
> >> +if (st->codecpar->codec_id == AV_CODEC_ID_ATRAC3PAL ||
> >> +st->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL)
> >
> >> +return -1;
> >
> > should be a AVERROR code
> 
> This is not error, it makes seeking possible, using other error codes
> is bad idea.

It would be better to use a named identifier than a litteral number
normally we use AVERROR_*, i would argue that oma_read_seek() did not
seek so it didnt succeed but if you prefer this to be called something
else than AVERROR_* sure iam perfectly fine with what you prefer.

It was the use of a litteral number (which is also undocumented for
read_seek() except by code returning -1) that i wanted to comment on

[...]
-- 
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] MAINTAINERS: Add myself for boadec.c

2017-01-31 Thread Michael Niedermayer
On Mon, Jan 30, 2017 at 01:49:00AM +0100, Michael Niedermayer wrote:
> It seems ive written this thing though i cannot really remember
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  MAINTAINERS | 1 +
>  1 file changed, 1 insertion(+)

applied


[...]
-- 
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: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread Petri Hintukainen
Hello,

I think I posted HDMV text subtitle decoder patch year+ ago. But I
can't find it from list archives (?).

I'll attach the original patch for reference / documentation of the
format.
There's also more complete implementation (text styles, positioning,
...) in libbluray: http://git.videolan.org/?p=libbluray.git;a=blob;f=sr
c/libbluray/decoders/textst_decode.c .

ti, 2017-01-31 kello 15:22 +0100, Paul B Mahol kirjoitti:
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile|   2 +
>  libavcodec/allcodecs.c |   2 +
>  libavcodec/textst_parser.c |  49 
>  libavcodec/textstdec.c | 108
> +
>  libavformat/utils.c|   1 +
>  5 files changed, 162 insertions(+)
>  create mode 100644 libavcodec/textst_parser.c
>  create mode 100644 libavcodec/textstdec.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 43a6add..edadb0f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+=
> svq1enc.o svq1.o  h263data.o  \
>  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o
> h264data.o
>  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
>  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
>  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
>  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
>  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) +=
> rv34_parser.o
>  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
>  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
>  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
>  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o
> vc1data.o  \
>    simple_idct.o wmv2data.o
>  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f92b2b7..9a90533 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -581,6 +581,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(SUBVIEWER, subviewer);
>  REGISTER_DECODER(SUBVIEWER1,subviewer1);
>  REGISTER_ENCDEC (TEXT,  text);
> +REGISTER_DECODER(TEXTST,textst);
>  REGISTER_DECODER(VPLAYER,   vplayer);
>  REGISTER_ENCDEC (WEBVTT,webvtt);
>  REGISTER_ENCDEC (XSUB,  xsub);
> @@ -704,6 +705,7 @@ void avcodec_register_all(void)
>  REGISTER_PARSER(RV40,   rv40);
>  REGISTER_PARSER(SIPR,   sipr);
>  REGISTER_PARSER(TAK,tak);
> +REGISTER_PARSER(TEXTST, textst);
>  REGISTER_PARSER(VC1,vc1);
>  REGISTER_PARSER(VORBIS, vorbis);
>  REGISTER_PARSER(VP3,vp3);
> diff --git a/libavcodec/textst_parser.c b/libavcodec/textst_parser.c
> new file mode 100644
> index 000..5079a96
> --- /dev/null
> +++ b/libavcodec/textst_parser.c
> @@ -0,0 +1,49 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later
> version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +/**
> + * @file
> + * HDMV TextST subtitle parser
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +#include "parser.h"
> +
> +static int textst_parse(AVCodecParserContext *s1, AVCodecContext
> *avctx,
> +const uint8_t **poutbuf, int *poutbuf_size,
> +const uint8_t *buf, int buf_size)
> +{
> +if (buf_size > 13) {
> +int64_t end;
> +
> +s1->pts = ((int64_t)(buf[3] & 1) << 32) | AV_RB32([4]);

I think there's no pts in dialog style segment.

I don't know if style segment is present when subtitles are muxed to
matroska, but it is present in the original .m2ts file.

> +end = ((int64_t)(buf[8] & 1) << 32) | AV_RB32([9]);
> +s1->duration = (end - s1->pts);
> +}
> +
> +/* always return the full packet. this parser isn't doing any
> splitting or
> +   combining, only packet analysis */
> +   

Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 15:38:33 +
Sumit Agarwal  wrote:

> From 0d6be9eebacc4403ecd7677e89c3205892b8809b Mon Sep 17 00:00:00 2001
> From: sumit 
> Date: Tue, 31 Jan 2017 21:00:50 +0530
> Subject: [PATCH] Add 420 10-bit transcode support for hwaccel cuvid
> 
> ---
>  ffmpeg_cuvid.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/ffmpeg_cuvid.c b/ffmpeg_cuvid.c
> index 766878f..baf6eee 100644
> --- a/ffmpeg_cuvid.c
> +++ b/ffmpeg_cuvid.c
> @@ -135,7 +135,7 @@ int cuvid_transcode_init(OutputStream *ost)
>   */
>  hwframe_ctx = (AVHWFramesContext*)ctx->hw_frames_ctx->data;
>  hwframe_ctx->format = AV_PIX_FMT_CUDA;
> -hwframe_ctx->sw_format = AV_PIX_FMT_NV12;
> +hwframe_ctx->sw_format = ist->st->codecpar->format == 
> AV_PIX_FMT_YUV420P10 ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
>  }
>  
>  return 0;

This relies on the format reported by the demuxer, which may or may not
work, depending on what the parser or decoder ran by libavformat does.
It might work on most cases, but it's still a bad idea.

The right way to implement this is letting cuvid parse the codec data
(e.g. SPS), and then use the values reported by it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] matroskaenc: Add support for writing video projection.

2017-01-31 Thread Aaron Colwell
On Tue, Jan 31, 2017 at 2:12 AM Vittorio Giovara 
wrote:

> On Sat, Jan 28, 2017 at 4:13 AM, James Almer  wrote:
> > On 1/27/2017 11:21 PM, Aaron Colwell wrote:
> >> On Fri, Jan 27, 2017 at 5:46 PM James Almer  wrote:
> >>
> >> yeah. I'm a little confused why the demuxing code didn't implement this
> to
> >> begin with.
> >
> > Vittorio (The one that implemented AVSphericalMapping) tried to add this
> at
> > first, but then removed it because he wasn't sure if he was doing it
> right.
>
> Hi,
> yes this was included initially but then we found out what those
> fields were really for, and I didn't want to make the users get as
> confused as we were. As a matter of fact Aaron I mentioned this to you
> when I proposed that we probably should have separated the classic
> equi projection from the tiled one in the specification, in order to
> simplify the implementation.
>

Like I said before, it is not a different projection. It is still
equirectangular and those parameters just crops the projection. It is very
simple to just verify that the fields are zero if you don't want to support
the cropped version.


>
> >>> I know you're the one behind the spec in question, but wouldn't it be a
> >>> better idea to wait until AVSphericalMapping gets a way to propagate
> this
> >>> kind of information before adding support for muxing video projection
> >>> elements? Or maybe try to implement it right now...
> >>>
> >>
> >> I'm happy to implement support for the projection specific info. What
> would
> >> be the best way to proceed. It seems like I could just place a union
> with
> >> projection specific structs in AVSphericalMapping. I'd also like some
> >
> > I'm CCing Vittorio so he can chim in. I personally have no real
> preference.
>
> The best way in my opinion is to add a third type, such as
> AV_SPHERICAL_TILED_EQUI, and add the relevant fields in
> AVSphericalMapping, with a clear description about the actual use case
> for them, mentioning that they are used only in format. By the way,
> why do you mention adding a union? I think four plain fields should
> do.
>

I don't think it is worth having the extra enum value for this. All the
cropped fields do is control how you generate the spherical mesh or control
the shader used to render the projection. If players don't want to support
it they can just check to see that all the fields are zero and error out if
not.

I was suggesting using a union because the projection bounds fields are for
equirect, and there are different fields for the cubemap & mesh
projections. I figured that the enum + union of structs might be a
reasonable way to organize the projection specific fields.



>
> Please keep me in CC.
>

Will do.

Aaron


> --
> Vittorio
> ___
> 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] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 15:22:17 +0100
Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile|   2 +
>  libavcodec/allcodecs.c |   2 +
>  libavcodec/textst_parser.c |  49 
>  libavcodec/textstdec.c | 108 
> +
>  libavformat/utils.c|   1 +
>  5 files changed, 162 insertions(+)
>  create mode 100644 libavcodec/textst_parser.c
>  create mode 100644 libavcodec/textstdec.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 43a6add..edadb0f 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o 
> svq1.o  h263data.o  \
>  OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o 
> h264data.o
>  OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
>  OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
> +OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
>  OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
>  OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
>  OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
> @@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
>  OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
>  OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
>  OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
> +OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
>  OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
>simple_idct.o wmv2data.o
>  OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index f92b2b7..9a90533 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -581,6 +581,7 @@ void avcodec_register_all(void)
>  REGISTER_DECODER(SUBVIEWER, subviewer);
>  REGISTER_DECODER(SUBVIEWER1,subviewer1);
>  REGISTER_ENCDEC (TEXT,  text);
> +REGISTER_DECODER(TEXTST,textst);
>  REGISTER_DECODER(VPLAYER,   vplayer);
>  REGISTER_ENCDEC (WEBVTT,webvtt);
>  REGISTER_ENCDEC (XSUB,  xsub);
> @@ -704,6 +705,7 @@ void avcodec_register_all(void)
>  REGISTER_PARSER(RV40,   rv40);
>  REGISTER_PARSER(SIPR,   sipr);
>  REGISTER_PARSER(TAK,tak);
> +REGISTER_PARSER(TEXTST, textst);
>  REGISTER_PARSER(VC1,vc1);
>  REGISTER_PARSER(VORBIS, vorbis);
>  REGISTER_PARSER(VP3,vp3);
> diff --git a/libavcodec/textst_parser.c b/libavcodec/textst_parser.c
> new file mode 100644
> index 000..5079a96
> --- /dev/null
> +++ b/libavcodec/textst_parser.c
> @@ -0,0 +1,49 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * HDMV TextST subtitle parser
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +#include "parser.h"
> +
> +static int textst_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
> +const uint8_t **poutbuf, int *poutbuf_size,
> +const uint8_t *buf, int buf_size)
> +{
> +if (buf_size > 13) {
> +int64_t end;
> +
> +s1->pts = ((int64_t)(buf[3] & 1) << 32) | AV_RB32([4]);
> +end = ((int64_t)(buf[8] & 1) << 32) | AV_RB32([9]);
> +s1->duration = (end - s1->pts);
> +}
> +
> +/* always return the full packet. this parser isn't doing any splitting 
> or
> +   combining, only packet analysis */
> +*poutbuf  = buf;
> +*poutbuf_size = buf_size;
> +return buf_size;
> +}
> +
> +AVCodecParser ff_textst_parser = {
> +.codec_ids  = { AV_CODEC_ID_HDMV_TEXT_SUBTITLE },
> +.parser_parse   = textst_parse,
> +};

Why does it need to be in a parser, instead of the demuxer? It seems
like this codec exists only in .ts anyway, and the way PTS/duration is
extracted seems very closely tied to the format.

> diff --git a/libavcodec/textstdec.c b/libavcodec/textstdec.c
> new file mode 100644
> index 

Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Sumit Agarwal
Sorry, by mistake attached the wrong patch earlier. Please find attached the 
correct patch now. 

Regards,
Sumit
-Original Message-
From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Timo 
Rothenpieler
Sent: Tuesday, January 31, 2017 8:30 PM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

> Hi,
> 
> Please review the attached patch which adds 420 10-bit transcode support for 
> hwaccel cuvid.
> 
> Sample Command:
> ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc 
> output.265
> 
> Thanks,
> Sumit

Are you sure the attached patch is complete?
All it does is replace AV_PIX_FMT_YUV420P10LE with AV_PIX_FMT_YUV420P10, which 
should be the same thing on little endian platforms, so it doesn't really 
change anything, or am I missing something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

---
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-Add-420-10-bit-transcode-support-for-hwaccel-cuvid.patch
Description: 0001-Add-420-10-bit-transcode-support-for-hwaccel-cuvid.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread Paul B Mahol
On 1/31/17, Carl Eugen Hoyos  wrote:
> 2017-01-31 15:22 GMT+01:00 Paul B Mahol :
>
>> +AVCodec ff_textst_decoder = {
>> +.name   = "textst",
>> +.long_name  = NULL_IF_CONFIG_SMALL("HDMV TextST subtitle"),
>
> Is this patch related to ticket #4481?

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


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 15:56 GMT+01:00 Sumit Agarwal :
> -hwframe_ctx->sw_format = ist->st->codecpar->format == 
> AV_PIX_FMT_YUV420P10LE ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;
> +hwframe_ctx->sw_format = ist->st->codecpar->format == 
> AV_PIX_FMT_YUV420P10 ? AV_PIX_FMT_P010 : AV_PIX_FMT_NV12;

I am curious: Is there a documentation that states the pixel formats
should be interpreted as being native endian?
(Is there a big-endian driver or the possibility that there will be one?)

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


Re: [FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 15:22 GMT+01:00 Paul B Mahol :

> +AVCodec ff_textst_decoder = {
> +.name   = "textst",
> +.long_name  = NULL_IF_CONFIG_SMALL("HDMV TextST subtitle"),

Is this patch related to ticket #4481?

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


Re: [FFmpeg-devel] [PATCH] avcodec: add ATRAC Advanced Lossless decoders

2017-01-31 Thread Paul B Mahol
On 1/31/17, Michael Niedermayer  wrote:
> On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
>> Only lossy part is decoded for now.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
> [...]
>>  static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
>>  {
>>  OMAContext *oc  = s->priv_data;
>> -AVStream *st= s->streams[0];
>> -int packet_size = st->codecpar->block_align;
>> -int byte_rate   = st->codecpar->bit_rate >> 3;
>> -int64_t pos = avio_tell(s->pb);
>> -int ret = av_get_packet(s->pb, pkt, packet_size);
>> -
>> -if (ret < packet_size)
>> -pkt->flags |= AV_PKT_FLAG_CORRUPT;
>> -
>> -if (ret < 0)
>> -return ret;
>> -if (!ret)
>> -return AVERROR_EOF;
>> -
>> -pkt->stream_index = 0;
>> -
>> -if (pos >= oc->content_start && byte_rate > 0) {
>> -pkt->pts =
>> -pkt->dts = av_rescale(pos - oc->content_start,
>> st->time_base.den,
>> -  byte_rate * (int64_t)st->time_base.num);
>> -}
>> -
>> -if (oc->encrypted) {
>> -/* previous unencrypted block saved in IV for
>> - * the next packet (CBC mode) */
>> -if (ret == packet_size)
>> -av_des_crypt(oc->av_des, pkt->data, pkt->data,
>> - (packet_size >> 3), oc->iv, 1);
>> -else
>> -memset(oc->iv, 0, 8);
>> -}
>> -
>> -return ret;
>> +return oc->read_packet(s, pkt);
>>  }
>
> moving this into read_packet() could be done in a seperate patch
>
>
>>
>>  static int oma_read_probe(AVProbeData *p)
>> @@ -491,8 +571,14 @@ static int oma_read_seek(struct AVFormatContext *s,
>>   int stream_index, int64_t timestamp, int flags)
>>  {
>>  OMAContext *oc = s->priv_data;
>> -int64_t err = ff_pcm_read_seek(s, stream_index, timestamp, flags);
>> +AVStream *st = s->streams[0];
>> +int64_t err;
>> +
>> +if (st->codecpar->codec_id == AV_CODEC_ID_ATRAC3PAL ||
>> +st->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL)
>
>> +return -1;
>
> should be a AVERROR code

This is not error, it makes seeking possible, using other error codes
is bad idea.

>
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who would give up essential Liberty, to purchase a little
> temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add ATRAC Advanced Lossless decoders

2017-01-31 Thread Michael Niedermayer
On Sun, Jan 29, 2017 at 06:39:21PM +0100, Paul B Mahol wrote:
> Only lossy part is decoded for now.
> 
> Signed-off-by: Paul B Mahol 
> ---
[...]
>  static int oma_read_packet(AVFormatContext *s, AVPacket *pkt)
>  {
>  OMAContext *oc  = s->priv_data;
> -AVStream *st= s->streams[0];
> -int packet_size = st->codecpar->block_align;
> -int byte_rate   = st->codecpar->bit_rate >> 3;
> -int64_t pos = avio_tell(s->pb);
> -int ret = av_get_packet(s->pb, pkt, packet_size);
> -
> -if (ret < packet_size)
> -pkt->flags |= AV_PKT_FLAG_CORRUPT;
> -
> -if (ret < 0)
> -return ret;
> -if (!ret)
> -return AVERROR_EOF;
> -
> -pkt->stream_index = 0;
> -
> -if (pos >= oc->content_start && byte_rate > 0) {
> -pkt->pts =
> -pkt->dts = av_rescale(pos - oc->content_start, st->time_base.den,
> -  byte_rate * (int64_t)st->time_base.num);
> -}
> -
> -if (oc->encrypted) {
> -/* previous unencrypted block saved in IV for
> - * the next packet (CBC mode) */
> -if (ret == packet_size)
> -av_des_crypt(oc->av_des, pkt->data, pkt->data,
> - (packet_size >> 3), oc->iv, 1);
> -else
> -memset(oc->iv, 0, 8);
> -}
> -
> -return ret;
> +return oc->read_packet(s, pkt);
>  }

moving this into read_packet() could be done in a seperate patch


>  
>  static int oma_read_probe(AVProbeData *p)
> @@ -491,8 +571,14 @@ static int oma_read_seek(struct AVFormatContext *s,
>   int stream_index, int64_t timestamp, int flags)
>  {
>  OMAContext *oc = s->priv_data;
> -int64_t err = ff_pcm_read_seek(s, stream_index, timestamp, flags);
> +AVStream *st = s->streams[0];
> +int64_t err;
> +
> +if (st->codecpar->codec_id == AV_CODEC_ID_ATRAC3PAL ||
> +st->codecpar->codec_id == AV_CODEC_ID_ATRAC3AL)

> +return -1;

should be a AVERROR code


thanks

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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


Re: [FFmpeg-devel] [PATCH] Implement optimal huffman encoding for (M)JPEG.

2017-01-31 Thread Tobias Rapp

On 30.01.2017 04:54, Jerry Jiang wrote:

[...]
diff --git a/tests/fate/vcodec.mak b/tests/fate/vcodec.mak
index a51f16c..a325da9 100644
--- a/tests/fate/vcodec.mak
+++ b/tests/fate/vcodec.mak
@@ -213,11 +213,15 @@ fate-vsynth%-jpeg2000-97: DECINOPTS = -vcodec 
jpeg2000
 FATE_VCODEC-$(call ENCDEC, LJPEG MJPEG, AVI) += ljpeg
 fate-vsynth%-ljpeg:  ENCOPTS = -strict -1

-FATE_VCODEC-$(call ENCDEC, MJPEG, AVI)  += mjpeg mjpeg-422 mjpeg-444 
mjpeg-trell
-fate-vsynth%-mjpeg:  ENCOPTS = -qscale 9 -pix_fmt yuvj420p
-fate-vsynth%-mjpeg-422:  ENCOPTS = -qscale 9 -pix_fmt yuvj422p
-fate-vsynth%-mjpeg-444:  ENCOPTS = -qscale 9 -pix_fmt yuvj444p
-fate-vsynth%-mjpeg-trell:ENCOPTS = -qscale 9 -pix_fmt yuvj420p 
-trellis 1
+FATE_VCODEC-$(call ENCDEC, MJPEG, AVI)  += mjpeg mjpeg-422 mjpeg-444 
mjpeg-trell mjpeg-huffman mjpeg-trell-huffman


It seems that "mjpeg-trell-qprd-huffman" is missing here.


+fate-vsynth%-mjpeg:   ENCOPTS = -qscale 9 -pix_fmt yuvj420p
+fate-vsynth%-mjpeg-422:   ENCOPTS = -qscale 9 -pix_fmt yuvj422p
+fate-vsynth%-mjpeg-444:   ENCOPTS = -qscale 9 -pix_fmt yuvj444p
+fate-vsynth%-mjpeg-trell: ENCOPTS = -qscale 9 -pix_fmt yuvj420p 
-trellis 1
+fate-vsynth%-mjpeg-huffman:   ENCOPTS = -qscale 9 -pix_fmt yuvj420p 
-huffman optimal
+fate-vsynth%-mjpeg-trell-huffman: ENCOPTS = -qscale 9 -pix_fmt yuvj420p 
-trellis 1 -huffman optimal
+fate-vsynth%-mjpeg-trell-qprd-huffman:ENCOPTS = -qscale 9 -pix_fmt yuvj420p 
-trellis 1 -huffman optimal \
+-mpv_flags +qp_rd -mbd 2

[...]



Regards,
Tobias

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


Re: [FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Timo Rothenpieler
> Hi,
> 
> Please review the attached patch which adds 420 10-bit transcode support for 
> hwaccel cuvid.
> 
> Sample Command:
> ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc output.265
> 
> Thanks,
> Sumit

Are you sure the attached patch is complete?
All it does is replace AV_PIX_FMT_YUV420P10LE with AV_PIX_FMT_YUV420P10,
which should be the same thing on little endian platforms, so it doesn't
really change anything, or am I missing something?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] Add 10-bit transcode support for hwaccel cuvid

2017-01-31 Thread Sumit Agarwal
Hi,

Please review the attached patch which adds 420 10-bit transcode support for 
hwaccel cuvid.

Sample Command:
ffmpeg -hwaccel cuvid -c:v hevc_cuvid -i input.265 -c:v hevc_nvenc output.265

Thanks,
Sumit



---
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-Add-420-10-bit-transcode-support-for-hwaccel-cuvid.patch
Description: 0001-Add-420-10-bit-transcode-support-for-hwaccel-cuvid.patch
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec: add HDMV Text Subtitle decoder

2017-01-31 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile|   2 +
 libavcodec/allcodecs.c |   2 +
 libavcodec/textst_parser.c |  49 
 libavcodec/textstdec.c | 108 +
 libavformat/utils.c|   1 +
 5 files changed, 162 insertions(+)
 create mode 100644 libavcodec/textst_parser.c
 create mode 100644 libavcodec/textstdec.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 43a6add..edadb0f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -539,6 +539,7 @@ OBJS-$(CONFIG_SVQ1_ENCODER)+= svq1enc.o svq1.o  
h263data.o  \
 OBJS-$(CONFIG_SVQ3_DECODER)+= svq3.o svq13.o mpegutils.o h264data.o
 OBJS-$(CONFIG_TEXT_DECODER)+= textdec.o ass.o
 OBJS-$(CONFIG_TEXT_ENCODER)+= srtenc.o ass_split.o
+OBJS-$(CONFIG_TEXTST_DECODER)  += textstdec.o ass.o
 OBJS-$(CONFIG_TAK_DECODER) += takdec.o tak.o takdsp.o
 OBJS-$(CONFIG_TARGA_DECODER)   += targa.o
 OBJS-$(CONFIG_TARGA_ENCODER)   += targaenc.o rle.o
@@ -945,6 +946,7 @@ OBJS-$(CONFIG_RV30_PARSER) += rv34_parser.o
 OBJS-$(CONFIG_RV40_PARSER) += rv34_parser.o
 OBJS-$(CONFIG_SIPR_PARSER) += sipr_parser.o
 OBJS-$(CONFIG_TAK_PARSER)  += tak_parser.o tak.o
+OBJS-$(CONFIG_TEXTST_PARSER)   += textst_parser.o
 OBJS-$(CONFIG_VC1_PARSER)  += vc1_parser.o vc1.o vc1data.o  \
   simple_idct.o wmv2data.o
 OBJS-$(CONFIG_VP3_PARSER)  += vp3_parser.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index f92b2b7..9a90533 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -581,6 +581,7 @@ void avcodec_register_all(void)
 REGISTER_DECODER(SUBVIEWER, subviewer);
 REGISTER_DECODER(SUBVIEWER1,subviewer1);
 REGISTER_ENCDEC (TEXT,  text);
+REGISTER_DECODER(TEXTST,textst);
 REGISTER_DECODER(VPLAYER,   vplayer);
 REGISTER_ENCDEC (WEBVTT,webvtt);
 REGISTER_ENCDEC (XSUB,  xsub);
@@ -704,6 +705,7 @@ void avcodec_register_all(void)
 REGISTER_PARSER(RV40,   rv40);
 REGISTER_PARSER(SIPR,   sipr);
 REGISTER_PARSER(TAK,tak);
+REGISTER_PARSER(TEXTST, textst);
 REGISTER_PARSER(VC1,vc1);
 REGISTER_PARSER(VORBIS, vorbis);
 REGISTER_PARSER(VP3,vp3);
diff --git a/libavcodec/textst_parser.c b/libavcodec/textst_parser.c
new file mode 100644
index 000..5079a96
--- /dev/null
+++ b/libavcodec/textst_parser.c
@@ -0,0 +1,49 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * HDMV TextST subtitle parser
+ */
+
+#include "libavutil/intreadwrite.h"
+#include "parser.h"
+
+static int textst_parse(AVCodecParserContext *s1, AVCodecContext *avctx,
+const uint8_t **poutbuf, int *poutbuf_size,
+const uint8_t *buf, int buf_size)
+{
+if (buf_size > 13) {
+int64_t end;
+
+s1->pts = ((int64_t)(buf[3] & 1) << 32) | AV_RB32([4]);
+end = ((int64_t)(buf[8] & 1) << 32) | AV_RB32([9]);
+s1->duration = (end - s1->pts);
+}
+
+/* always return the full packet. this parser isn't doing any splitting or
+   combining, only packet analysis */
+*poutbuf  = buf;
+*poutbuf_size = buf_size;
+return buf_size;
+}
+
+AVCodecParser ff_textst_parser = {
+.codec_ids  = { AV_CODEC_ID_HDMV_TEXT_SUBTITLE },
+.parser_parse   = textst_parse,
+};
diff --git a/libavcodec/textstdec.c b/libavcodec/textstdec.c
new file mode 100644
index 000..a259d2d
--- /dev/null
+++ b/libavcodec/textstdec.c
@@ -0,0 +1,108 @@
+/*
+ * HDMV TextST decoder
+ * Copyright (c) 2017 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * 

Re: [FFmpeg-devel] [PATCH 3/3] doc/muxers: add AVI muxer documentation

2017-01-31 Thread Tobias Rapp

On 31.01.2017 12:54, Michael Niedermayer wrote:

On Wed, Jan 18, 2017 at 10:27:03AM +0100, Tobias Rapp wrote:

Signed-off-by: Tobias Rapp 
---
 doc/muxers.texi | 33 +
 1 file changed, 33 insertions(+)


LGTM


Pushed, thanks for the review.

Regards,
Tobias


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


Re: [FFmpeg-devel] [PATCH] pgssubdec: reset rle_data_len/rle_remaining_len on allocation error

2017-01-31 Thread Michael Niedermayer
On Tue, Jan 31, 2017 at 01:59:38AM +0100, Andreas Cadhalpun wrote:
> The code relies on their validity and otherwise can try to access a NULL
> object->rle pointer, causing segmentation faults.
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/pgssubdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

LGTM

please also backport this to the releases

thx

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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


Re: [FFmpeg-devel] [PATCH 9/9] boadec: prevent overflow during block alignment calculation

2017-01-31 Thread Clément Bœsch
On Tue, Jan 31, 2017 at 07:45:56AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Jan 30, 2017 at 8:52 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
> 
> > Marton proposed a way to mitigate this [1], but you haven't commented
> > on it so far.
> 
> 
> It doesn't mitigate it. Source code is still an issue, as is binary size if
> CONFIG_SMALL is off, which is the default for release builds.
> 
> Even if you change CONFIG_SMALL to NDEBUG, the source code issue is still
> there.
> 
> I don't want this patch. I also don't want to discuss it further. Please
> remove the log message. Thank you.
> 

I stayed silent on the issue so far, but I'm with Ronald on this one and
don't want to pollute functional code with elaborated error code paths
unlikely to happen.

I understand every con and pro from both sides and don't plan to comment
again on the topic.

Regards,

-- 
Clément B.


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


Re: [FFmpeg-devel] [PATCH] swscale: add P016 input support

2017-01-31 Thread Michael Niedermayer
On Sun, Jan 29, 2017 at 01:11:51PM -0800, Philip Langdale wrote:
> Signed-off-by: Philip Langdale 
> ---
>  libswscale/input.c| 32 
>  libswscale/swscale_unscaled.c |  4 +++-
>  libswscale/utils.c|  2 ++
>  3 files changed, 37 insertions(+), 1 deletion(-)

i assume this is tested and works
LGTM

thanks

[...]
-- 
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] Implement optimal huffman encoding for (M)JPEG.

2017-01-31 Thread Rostislav Pehlivanov
On 30 January 2017 at 03:54, Jerry Jiang  wrote:
>Hey everyone,
>
>Sorry for the long wait, here's a new patch addressing the feedback. In
>addition, we discovered that this current implementation of optimal huffman
>encoding is not compatible with QP RD, so we chose to disable QP RD for
>mjpeg or amv encoding. (Wondering if that's acceptable, since it appears
>like QP RD is an underused feature.)

Hi,

Thanks, code-wise the patch looks good to me now.
Like Michael said can you re-submit a patch which applies correctly using
git am?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 14:06 GMT+01:00 Matteo Naccari :

> Re: On removal of malloc, free, etc. I think this v4 takes care of this as 
> the commit messages says.

I don't think so.

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Andy Furniss

DogFilm wrote:

OK, please tell me a place where I can upload 1.6 GB video file and i will
do it, thanks!


"It is quite a normal
video downloaded from a public media library"

Link?

Maybe you can reproduce with a cut down by dd version?

free google drive IIRC has 1 gig upload limit, if you really need to 
upload the whole thing you could chop it in two.




On Tue, Jan 31, 2017 at 1:00 PM, Paul B Mahol  wrote:


On 1/31/17, DogFilm  wrote:

Hi,

I have a video here that will make ffmpeg hang and eat all CPU without
doing any actual work and produces a lot of errors. It is quite a normal
video downloaded from a public media library, nothing special.

The error message asks me to upload the file to
ftp://upload.ffmpeg.org/incoming/ and report here about that error.
Unfortunately that ftp server does not seem to exist.

Where should I upload that ffmpeg-killer-video?


Anywhere from where it can be easily downloadable.



Also should I file the missing ftp server as a bug?


Nope.



Thanks for your attention,
have a nice day,
John
___
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 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 v3] Added Turing codec interface for ffmpeg

2017-01-31 Thread Matteo Naccari
> That's pretty old by now. Can you send a v4 patch set?

Sorry my bad, I've already sent a v4 on the 14/12. Do you want me to rebase the 
patch to the latest commit on the branch master?

Re: On removal of malloc, free, etc. I think this v4 takes care of this as the 
commit messages says.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 13:47 GMT+01:00 DogFilm :
> The file is not available anymore, it was in the arte.tv online vod service
> but is not available anymore due to the legal requirement to remove content
> after seven days.

Please provide the command line that you tested and the complete, uncut
console output you see.

And please avoid top-posting here, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 13:09 GMT+01:00 Thilo Borgmann :

> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it is not 
> the place to
> upload things then these messages should be changed accordingly and the 
> preferred
> way to upload samples need to be documented.

We have been promised repeatedly in the last six months that the path
will be working "soon".

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread DogFilm
> Or whatever necessary but in the end the message we show should actually
be a valid way for the user to proceed.

for me the experience felt like I would very much like if it ended in a
succesful way. it did not.

The link showing a dead ftp site btw destroyed my breakfast time as I was
trying to understand what is wrong - only as a last resort I understood
that the site simply does not exist and that it was a mis-information (aka
fake-news!) - should be at least removed, if not corrected, to save this
experience to others.

No, I am not complaining - I really like ffmpeg very much and I have big
adoration for you, the beloved devs! (Just to avoid misunderstanding.) But
of course ffmpeg with not exploding on decoding random arte video would be
even greater, that is why I would like to send you that video for analysis!

Thanks!

On Tue, Jan 31, 2017 at 1:47 PM, DogFilm  wrote:

> The file is not available anymore, it was in the arte.tv online vod
> service but is not available anymore due to the legal requirement to remove
> content after seven days.
>
> On Tue, Jan 31, 2017 at 1:18 PM, Carl Eugen Hoyos 
> wrote:
>
>> 2017-01-31 12:43 GMT+01:00 DogFilm :
>>
>> > I have a video here that will make ffmpeg hang and eat all CPU without
>> > doing any actual work and produces a lot of errors. It is quite a normal
>> > video downloaded from a public media library
>>
>> Where did you download the file from?
>>
>> Carl Eugen
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 13:42 GMT+01:00 Matteo Naccari :
> Hello everyone,
>
> Any news on the integration of the patch identified in the subject line?

So far, you haven't removed the calls to malloc().
Please use av_freep() (instead of av_free) to free the memory.

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


Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 12:42:54 +
Matteo Naccari  wrote:

> Hello everyone,
> 
> Any news on the integration of the patch identified in the subject line?
> 
> Best regards,
> Matteo

That's pretty old by now. Can you send a v4 patch set?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread DogFilm
The file is not available anymore, it was in the arte.tv online vod service
but is not available anymore due to the legal requirement to remove content
after seven days.

On Tue, Jan 31, 2017 at 1:18 PM, Carl Eugen Hoyos 
wrote:

> 2017-01-31 12:43 GMT+01:00 DogFilm :
>
> > I have a video here that will make ffmpeg hang and eat all CPU without
> > doing any actual work and produces a lot of errors. It is quite a normal
> > video downloaded from a public media library
>
> Where did you download the file from?
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 9/9] boadec: prevent overflow during block alignment calculation

2017-01-31 Thread Ronald S. Bultje
Hi,

On Mon, Jan 30, 2017 at 8:52 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Marton proposed a way to mitigate this [1], but you haven't commented
> on it so far.


It doesn't mitigate it. Source code is still an issue, as is binary size if
CONFIG_SMALL is off, which is the default for release builds.

Even if you change CONFIG_SMALL to NDEBUG, the source code issue is still
there.

I don't want this patch. I also don't want to discuss it further. Please
remove the log message. Thank you.

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


Re: [FFmpeg-devel] [PATCH v3] Added Turing codec interface for ffmpeg

2017-01-31 Thread Matteo Naccari
Hello everyone,

Any news on the integration of the patch identified in the subject line?

Best regards,
Matteo

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Thilo Borgmann
Am 31.01.17 um 13:17 schrieb wm4:
> On Tue, 31 Jan 2017 13:09:07 +0100
> Thilo Borgmann  wrote:
> 
>> Am 31.01.17 um 13:00 schrieb Paul B Mahol:
>>> On 1/31/17, DogFilm  wrote:  
 Hi,

 I have a video here that will make ffmpeg hang and eat all CPU without
 doing any actual work and produces a lot of errors. It is quite a normal
 video downloaded from a public media library, nothing special.

 The error message asks me to upload the file to
 ftp://upload.ffmpeg.org/incoming/ and report here about that error.
 Unfortunately that ftp server does not seem to exist.  
>>
>> Thanks for reporting back to us.
>>
>>
 Where should I upload that ffmpeg-killer-video?  
>>>
>>> Anywhere from where it can be easily downloadable.
>>>   

 Also should I file the missing ftp server as a bug?  
>>>
>>> Nope.  
>>
>> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it is not 
>> the place to upload things then these messages should be changed accordingly 
>> and the preferred way to upload samples need to be documented.
> 
> Or just add that place back, and/or put a redirect?

Or whatever necessary but in the end the message we show should actually be a 
valid way for the user to proceed. 

-Thilo

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Carl Eugen Hoyos
2017-01-31 12:43 GMT+01:00 DogFilm :

> I have a video here that will make ffmpeg hang and eat all CPU without
> doing any actual work and produces a lot of errors. It is quite a normal
> video downloaded from a public media library

Where did you download the file from?

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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 13:09:07 +0100
Thilo Borgmann  wrote:

> Am 31.01.17 um 13:00 schrieb Paul B Mahol:
> > On 1/31/17, DogFilm  wrote:  
> >> Hi,
> >>
> >> I have a video here that will make ffmpeg hang and eat all CPU without
> >> doing any actual work and produces a lot of errors. It is quite a normal
> >> video downloaded from a public media library, nothing special.
> >>
> >> The error message asks me to upload the file to
> >> ftp://upload.ffmpeg.org/incoming/ and report here about that error.
> >> Unfortunately that ftp server does not seem to exist.  
> 
> Thanks for reporting back to us.
> 
> 
> >> Where should I upload that ffmpeg-killer-video?  
> > 
> > Anywhere from where it can be easily downloadable.
> >   
> >>
> >> Also should I file the missing ftp server as a bug?  
> > 
> > Nope.  
> 
> We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it is not 
> the place to upload things then these messages should be changed accordingly 
> and the preferred way to upload samples need to be documented.

Or just add that place back, and/or put a redirect?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread DogFilm
OK, please tell me a place where I can upload 1.6 GB video file and i will
do it, thanks!

On Tue, Jan 31, 2017 at 1:00 PM, Paul B Mahol  wrote:

> On 1/31/17, DogFilm  wrote:
> > Hi,
> >
> > I have a video here that will make ffmpeg hang and eat all CPU without
> > doing any actual work and produces a lot of errors. It is quite a normal
> > video downloaded from a public media library, nothing special.
> >
> > The error message asks me to upload the file to
> > ftp://upload.ffmpeg.org/incoming/ and report here about that error.
> > Unfortunately that ftp server does not seem to exist.
> >
> > Where should I upload that ffmpeg-killer-video?
>
> Anywhere from where it can be easily downloadable.
>
> >
> > Also should I file the missing ftp server as a bug?
>
> Nope.
>
> >
> > Thanks for your attention,
> > have a nice day,
> > John
> > ___
> > 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 mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Thilo Borgmann
Am 31.01.17 um 13:00 schrieb Paul B Mahol:
> On 1/31/17, DogFilm  wrote:
>> Hi,
>>
>> I have a video here that will make ffmpeg hang and eat all CPU without
>> doing any actual work and produces a lot of errors. It is quite a normal
>> video downloaded from a public media library, nothing special.
>>
>> The error message asks me to upload the file to
>> ftp://upload.ffmpeg.org/incoming/ and report here about that error.
>> Unfortunately that ftp server does not seem to exist.

Thanks for reporting back to us.


>> Where should I upload that ffmpeg-killer-video?
> 
> Anywhere from where it can be easily downloadable.
> 
>>
>> Also should I file the missing ftp server as a bug?
> 
> Nope.

We mention ftp://upload.ffmpeg.org/incoming/ in several places. If it is not 
the place to upload things then these messages should be changed accordingly 
and the preferred way to upload samples need to be documented.

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


Re: [FFmpeg-devel] [PATCH 3/3] doc/muxers: add AVI muxer documentation

2017-01-31 Thread Michael Niedermayer
On Wed, Jan 18, 2017 at 10:27:03AM +0100, Tobias Rapp wrote:
> Signed-off-by: Tobias Rapp 
> ---
>  doc/muxers.texi | 33 +
>  1 file changed, 33 insertions(+)

LGTM

thx

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

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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


Re: [FFmpeg-devel] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread Paul B Mahol
On 1/31/17, DogFilm  wrote:
> Hi,
>
> I have a video here that will make ffmpeg hang and eat all CPU without
> doing any actual work and produces a lot of errors. It is quite a normal
> video downloaded from a public media library, nothing special.
>
> The error message asks me to upload the file to
> ftp://upload.ffmpeg.org/incoming/ and report here about that error.
> Unfortunately that ftp server does not seem to exist.
>
> Where should I upload that ffmpeg-killer-video?

Anywhere from where it can be easily downloadable.

>
> Also should I file the missing ftp server as a bug?

Nope.

>
> Thanks for your attention,
> have a nice day,
> John
> ___
> 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] Video decoding error asks me to upload video to non-existing site ftp://upload.ffmpeg.org/incoming/

2017-01-31 Thread DogFilm
Hi,

I have a video here that will make ffmpeg hang and eat all CPU without
doing any actual work and produces a lot of errors. It is quite a normal
video downloaded from a public media library, nothing special.

The error message asks me to upload the file to
ftp://upload.ffmpeg.org/incoming/ and report here about that error.
Unfortunately that ftp server does not seem to exist.

Where should I upload that ffmpeg-killer-video?

Also should I file the missing ftp server as a bug?

Thanks for your attention,
have a nice day,
John
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] matroskaenc: Add support for writing video projection.

2017-01-31 Thread Vittorio Giovara
On Sat, Jan 28, 2017 at 4:13 AM, James Almer  wrote:
> On 1/27/2017 11:21 PM, Aaron Colwell wrote:
>> On Fri, Jan 27, 2017 at 5:46 PM James Almer  wrote:
>>
>> yeah. I'm a little confused why the demuxing code didn't implement this to
>> begin with.
>
> Vittorio (The one that implemented AVSphericalMapping) tried to add this at
> first, but then removed it because he wasn't sure if he was doing it right.

Hi,
yes this was included initially but then we found out what those
fields were really for, and I didn't want to make the users get as
confused as we were. As a matter of fact Aaron I mentioned this to you
when I proposed that we probably should have separated the classic
equi projection from the tiled one in the specification, in order to
simplify the implementation.

>>> I know you're the one behind the spec in question, but wouldn't it be a
>>> better idea to wait until AVSphericalMapping gets a way to propagate this
>>> kind of information before adding support for muxing video projection
>>> elements? Or maybe try to implement it right now...
>>>
>>
>> I'm happy to implement support for the projection specific info. What would
>> be the best way to proceed. It seems like I could just place a union with
>> projection specific structs in AVSphericalMapping. I'd also like some
>
> I'm CCing Vittorio so he can chim in. I personally have no real preference.

The best way in my opinion is to add a third type, such as
AV_SPHERICAL_TILED_EQUI, and add the relevant fields in
AVSphericalMapping, with a clear description about the actual use case
for them, mentioning that they are used only in format. By the way,
why do you mention adding a union? I think four plain fields should
do.

Please keep me in CC.
-- 
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH]lavc/alac: Export samplerate

2017-01-31 Thread Carl Eugen Hoyos
2017-01-30 11:28 GMT+01:00 Paul B Mahol :
> On 1/30/17, Carl Eugen Hoyos  wrote:
>> Hi!
>>
>> I suspect attached patch makes using the alac decoder easier with
>> non-FFmpeg demuxers.
>>
>> 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] lavf/xwma: fix incorrect format specifier

2017-01-31 Thread Paul B Mahol
On 1/30/17, Moritz Barsnick  wrote:
> Signed-off-by: Moritz Barsnick 
> ---
>  libavformat/xwma.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>

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


Re: [FFmpeg-devel] GSoC 2017

2017-01-31 Thread Umair Khan
On Mon, Jan 30, 2017 at 11:44 PM, Thilo Borgmann  wrote:
> Am 30.01.17 um 18:41 schrieb Umair Khan:
>> On Wed, Jan 25, 2017 at 5:45 PM, Thilo Borgmann  
>> wrote:
>>> Am 25.01.17 um 06:14 schrieb Umair Khan:
 On Wed, Jan 25, 2017 at 7:45 AM, Michael Niedermayer  
 wrote:
>
> On Mon, Jan 23, 2017 at 03:39:09PM +0100, Michael Niedermayer wrote:
>> Hi all
>>
>> GSoC 2017 mentor org registration has opened a few days ago
>>
>> Our current ideas page lists just a single mentor and single sugestion
>> http://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017
>>
>> About the Suggested project
>> It is a hard design task which few students would be
>> capable to do. I dont know if someone already knows a student who is
>> qualified for this and who would be available in FFmpeg GSoC but if not
>> I think finding a qualified student will be hard or require some luck
>> and success with a less than qualified student unlikely.
>> At least thats what my gut feeling says based on past years
>>
>> About the number of ideas
>> one is not enough, and i think its a waste of time if we apply with
>> such short list, i doubt we would be accepted with one idea and one
>> mentor
>>
>> About the number of mentors
>> one is not enough
>
> ok so our page now contains
> 4 project ideas and 3 mentors
> big thanks to the people volunteering and adding them
>
> Can we get a few more ?
> Ideal would be numbers similar to previous years
> We wont have a student for each idea we list most likely.
> If we list just 4 we might have just 1 or 2 students, having a
> wider range of ideas to select from would increase the number of
> contributions and number of potential new developers joining.

 One idea would be to finish rest of the ALS codec tasks.
 What's remaining is :-
>>>
 1. Implement RLS LMS mode in the decoder.
>>>
>>> See 3.
>>>
>>>
 2. Get the encoder merged into the main repository.
>>>
>>> This was part of last years (yours) project... I admit that this has not 
>>> yet happened is due to my lack of time for working on it with you (which 
>>> will most likely change soon :) )
>>> However I would not like to have this iterated but being finished by the 
>>> start of the next GSoC round (which basically means by yesterday...).
>>>
>>>
 3. Encoder featureset still lacks support for floating point sample
 data encoding.
>>>
>>> 1. & 3. could be part of a "complete feature set for ALS"-project. Both are 
>>> too little for separated projects and too much for a qualification task. 
>>> But I like the idea of a comprehensive feature set project. You came up 
>>> with this idea first so if you're up to mentor it, go ahead and add it to 
>>> the wiki. Otherwise I'll do it during the weekend.
>>
>> The floating point decoding test fails on qemu arm. May be we can put
>> fixing this issue as the qualification task, and rest all as the main
>> project.
>
> Just added a project to the wiki.
> https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2017#MPEG-4ALScodecimprovements
>
> I included fate coverage. Feel free to add/modify it.
> Would you prefer to be mentor?
> would you like to be backup mentor?

I'll add myself as the backup mentor.

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


Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-01-31 Thread wm4
On Tue, 31 Jan 2017 09:57:24 +0100
wm4  wrote:

> On Mon, 30 Jan 2017 17:05:49 -0800
> Chris Cunningham  wrote:
> 
> > Blocks are marked as key frames whenever the "reference" field is
> > zero. This is incorrect for non-keyframe Blocks that take a refernce
> > on a keyframe at time zero.
> > 
> > Now using -1 to denote "no reference".
> > 
> > Reported to chromium at http://crbug.com/497889 (contains sample)
> > ---
> >  libavformat/matroskadec.c | 9 ++---
> >  1 file changed, 6 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> > index e6737a70b2..0d033b574c 100644
> > --- a/libavformat/matroskadec.c
> > +++ b/libavformat/matroskadec.c
> > @@ -89,6 +89,7 @@ typedef const struct EbmlSyntax {
> >  int list_elem_size;
> >  int data_offset;
> >  union {
> > +int64_t i;
> >  uint64_tu;
> >  double  f;
> >  const char *s;
> > @@ -696,7 +697,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
> >  { MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0, offsetof(MatroskaBlock, 
> > bin) },
> >  { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0, offsetof(MatroskaBlock, 
> > duration) },
> >  { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0, offsetof(MatroskaBlock, 
> > discard_padding) },
> > -{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> > reference) },
> > +{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> > reference), { .i = -1 } },
> >  { MATROSKA_ID_CODECSTATE, EBML_NONE },
> >  {  1, EBML_UINT, 0, offsetof(MatroskaBlock, 
> > non_simple), { .u = 1 } },
> >  { 0 }
> > @@ -1071,6 +1072,8 @@ static int ebml_parse_nest(MatroskaDemuxContext 
> > *matroska, EbmlSyntax *syntax,
> >  
> >  for (i = 0; syntax[i].id; i++)
> >  switch (syntax[i].type) {
> > +case EBML_SINT:
> > +*(int64_t *) ((char *) data + syntax[i].data_offset) = 
> > syntax[i].def.i;
> >  case EBML_UINT:  
> 
> Isn't there a break missing?
> 
> >  *(uint64_t *) ((char *) data + syntax[i].data_offset) = 
> > syntax[i].def.u;
> >  break;
> > @@ -3361,7 +3364,7 @@ static int 
> > matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
> >  matroska->current_cluster_num_blocks = blocks_list->nb_elem;
> >  i= blocks_list->nb_elem - 1;
> >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> > -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference 
> > : -1;
> > +int is_keyframe = blocks[i].non_simple ? blocks[i].reference 
> > == -1 : -1;
> >  uint8_t* additional = blocks[i].additional.size > 0 ?
> >  blocks[i].additional.data : NULL;
> >  if (!blocks[i].non_simple)
> > @@ -3399,7 +3402,7 @@ static int 
> > matroska_parse_cluster(MatroskaDemuxContext *matroska)
> >  blocks  = blocks_list->elem;
> >  for (i = 0; i < blocks_list->nb_elem; i++)
> >  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> > -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference 
> > : -1;
> > +int is_keyframe = blocks[i].non_simple ? blocks[i].reference 
> > == -1 : -1;
> >  res = matroska_parse_block(matroska, blocks[i].bin.data,
> > blocks[i].bin.size, 
> > blocks[i].bin.pos,
> > cluster.timecode, 
> > blocks[i].duration,  
> 
> I don't quite trust this. The file has negative block references too
> (what do they even mean?). E.g. one block uses "-123". This doesn't
> make much sense to me, and at the very least it means -1 is not a safe
> dummy value (because negative values don't mean non-keyframe according
> to your patch, while -1 as exception does).
> 
> The oldest/most used (until recently at least) mkv demuxer, Haali
> actually does every block reference element as a non-keyframe:
> 
> http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/MatroskaParser.c;h=173c2e1c20da59d4cf0b501639c470331cd4515f;hb=HEAD#l2354
> 
> This seems much safer.
> 
> Do you have any insight why the file contains such erratic seeming
> reference values? I'm sure I'm missing something. Or is it a broken
> muxer/broken file?

Oh, nevermind. The values in the reference elements are
supposed to be _relative_ timestamps. This means -1 is still not a safe
dummy value. But then, what is a value of "0" supposed to mean?

Going after Haali seems the safest fix, as it most likely won't break
anything.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: fix is_keyframe for early Blocks

2017-01-31 Thread wm4
On Mon, 30 Jan 2017 17:05:49 -0800
Chris Cunningham  wrote:

> Blocks are marked as key frames whenever the "reference" field is
> zero. This is incorrect for non-keyframe Blocks that take a refernce
> on a keyframe at time zero.
> 
> Now using -1 to denote "no reference".
> 
> Reported to chromium at http://crbug.com/497889 (contains sample)
> ---
>  libavformat/matroskadec.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index e6737a70b2..0d033b574c 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -89,6 +89,7 @@ typedef const struct EbmlSyntax {
>  int list_elem_size;
>  int data_offset;
>  union {
> +int64_t i;
>  uint64_tu;
>  double  f;
>  const char *s;
> @@ -696,7 +697,7 @@ static const EbmlSyntax matroska_blockgroup[] = {
>  { MATROSKA_ID_SIMPLEBLOCK,EBML_BIN,  0, offsetof(MatroskaBlock, bin) 
> },
>  { MATROSKA_ID_BLOCKDURATION,  EBML_UINT, 0, offsetof(MatroskaBlock, 
> duration) },
>  { MATROSKA_ID_DISCARDPADDING, EBML_SINT, 0, offsetof(MatroskaBlock, 
> discard_padding) },
> -{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> reference) },
> +{ MATROSKA_ID_BLOCKREFERENCE, EBML_SINT, 0, offsetof(MatroskaBlock, 
> reference), { .i = -1 } },
>  { MATROSKA_ID_CODECSTATE, EBML_NONE },
>  {  1, EBML_UINT, 0, offsetof(MatroskaBlock, 
> non_simple), { .u = 1 } },
>  { 0 }
> @@ -1071,6 +1072,8 @@ static int ebml_parse_nest(MatroskaDemuxContext 
> *matroska, EbmlSyntax *syntax,
>  
>  for (i = 0; syntax[i].id; i++)
>  switch (syntax[i].type) {
> +case EBML_SINT:
> +*(int64_t *) ((char *) data + syntax[i].data_offset) = 
> syntax[i].def.i;
>  case EBML_UINT:

Isn't there a break missing?

>  *(uint64_t *) ((char *) data + syntax[i].data_offset) = 
> syntax[i].def.u;
>  break;
> @@ -3361,7 +3364,7 @@ static int 
> matroska_parse_cluster_incremental(MatroskaDemuxContext *matroska)
>  matroska->current_cluster_num_blocks = blocks_list->nb_elem;
>  i= blocks_list->nb_elem - 1;
>  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference : 
> -1;
> +int is_keyframe = blocks[i].non_simple ? blocks[i].reference == 
> -1 : -1;
>  uint8_t* additional = blocks[i].additional.size > 0 ?
>  blocks[i].additional.data : NULL;
>  if (!blocks[i].non_simple)
> @@ -3399,7 +3402,7 @@ static int matroska_parse_cluster(MatroskaDemuxContext 
> *matroska)
>  blocks  = blocks_list->elem;
>  for (i = 0; i < blocks_list->nb_elem; i++)
>  if (blocks[i].bin.size > 0 && blocks[i].bin.data) {
> -int is_keyframe = blocks[i].non_simple ? !blocks[i].reference : 
> -1;
> +int is_keyframe = blocks[i].non_simple ? blocks[i].reference == 
> -1 : -1;
>  res = matroska_parse_block(matroska, blocks[i].bin.data,
> blocks[i].bin.size, blocks[i].bin.pos,
> cluster.timecode, blocks[i].duration,

I don't quite trust this. The file has negative block references too
(what do they even mean?). E.g. one block uses "-123". This doesn't
make much sense to me, and at the very least it means -1 is not a safe
dummy value (because negative values don't mean non-keyframe according
to your patch, while -1 as exception does).

The oldest/most used (until recently at least) mkv demuxer, Haali
actually does every block reference element as a non-keyframe:

http://git.1f0.de/gitweb?p=ffmpeg.git;a=blob;f=libavformat/MatroskaParser.c;h=173c2e1c20da59d4cf0b501639c470331cd4515f;hb=HEAD#l2354

This seems much safer.

Do you have any insight why the file contains such erratic seeming
reference values? I'm sure I'm missing something. Or is it a broken
muxer/broken file?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] speedhq: make sure the block index is not negative

2017-01-31 Thread Steinar H. Gunderson
On Tue, Jan 31, 2017 at 01:57:31AM +0100, Andreas Cadhalpun wrote:
>> This sounds like a strangeness in constructing the table, which shouldn't be
>> papered over in the inner loop of the decoder.
> Maybe, I don't know what the contents of the table should be, but the 
> following
> are {-1, 0}: 32, 33, 64, 96, 128

Seemingly they are, indeed.

>> Do you have an actual input where your code makes a difference?
> Yes, without this patch ubsan reports:
> src/libavcodec/speedhq.c:206:13: runtime error: index -1 out of bounds for 
> type 'uint8_t [128]'

Would you mind sharing an input where this actually triggers? None of the
samples I have seem to trigger this, so I suppose it's some sort of fuzzed
input.

/* Steinar */
-- 
Homepage: https://www.sesse.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 2/3] avformat/avienc: add reserve_index_space option

2017-01-31 Thread Tobias Rapp

On 31.01.2017 04:33, Michael Niedermayer wrote:

On Mon, Jan 30, 2017 at 04:40:17PM +0100, Tobias Rapp wrote:

On 25.01.2017 22:49, Michael Niedermayer wrote:

On Mon, Jan 23, 2017 at 11:12:13AM +0100, Tobias Rapp wrote:
[...]

libavformat/avi.h   |1
libavformat/avienc.c|   77 +---
libavformat/version.h   |2
tests/ref/fate/mpeg4-bsf-unpack-bframes |2
tests/ref/lavf-fate/avi_cram|2
5 files changed, 74 insertions(+), 10 deletions(-)
8dfa5b4ff26ee67c6772bb257a772672bb91aa34  
0002-avformat-avienc-add-reserve_index_space-option.patch

>From 4cc70ffdeb7eeb60e7bbb725bd5885dcacf968d2 Mon Sep 17 00:00:00 2001

From: Tobias Rapp 
Date: Wed, 4 Jan 2017 15:31:29 +0100
Subject: [PATCH 2/3] avformat/avienc: add reserve_index_space option

Allows the user to reserve space for the ODML master index. A sufficient
sized master index in the AVI header avoids storing follow-up master
indexes within the 'movi' data later.

If the option is omitted or zero the index size is estimated from output
duration and bitrate. A worst-case bitrate for video streams is assumed
in case it is not available.




Note: fate reference files changed because the video stream had zero
bitrate before and is guessed now.


I dont think this is good
if the user app says bitrate is 0 the muxer should not replace that by
the bitrate for a rawvideo stream (when its not rawvideo)

This could be ok for the reserved space calculation but for the file
bitrate, especially with lossy compressed streams this will likely
give values that are less correct than before





My assumption was that bitrate=0 corresponds to "unknown" and that a
large value for MaxBytesPerSec would do less harm than a small/zero
value.


That can be argued about but that should not be in this patch, changing
some bitrates in the header and changing the index space are 2
differnt thigs


I agree. And it would be even better if no guessing would be needed on 
muxer level at all because even loss-less encoders would signal the 
estimated stream bitrate.



Find attached an updated version of the patch with "worst-case
bitrate guessing" removed.


patch LGTM


Pushed, thanks for the review.

Regards,
Tobias

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