Re: [FFmpeg-devel] [PATCH]lavf/mpjpegdec: Do not av_log() while probing

2016-01-13 Thread Carl Eugen Hoyos 
Michael Niedermayer  niedermayer.cc> writes:

> >  mpjpegdec.c |3 +++
> >  1 file changed, 3 insertions(+)
> > acd4f042b52c6400a6aaf613b89ecad9ca3405ac  patchmpjpeglog.diff
> 
> should be ok

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 v2 4/9] lavc/ccaption_dec: default rollup to row 10

2016-01-13 Thread Anshul 


On 13 January 2016 7:12:55 AM IST, Aman Gupta  wrote:
>From: Aman Gupta 
>
>This ensures that captions are written towards the bottom of the screen
>when tuning into mid-stream. The row will be reset on the receipt of
>the
>next PAC command. Row 10 was chosen as it corresponds to the value of
>"0" in a PAC (see row_map in handle_pac()).
>---
> libavcodec/ccaption_dec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
>diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>index 6bdd754..8c913fe 100644
>--- a/libavcodec/ccaption_dec.c
>+++ b/libavcodec/ccaption_dec.c
>@@ -148,6 +148,7 @@ static av_cold int init_decoder(AVCodecContext
>*avctx)
> /* taking by default roll up to 2 */
> ctx->mode = CCMODE_ROLLUP;
> ctx->rollup = 2;
>+ctx->cursor_row = 10;
> ret = ff_ass_subtitle_header(avctx, "Monospace",
>  ASS_DEFAULT_FONT_SIZE,
>  ASS_DEFAULT_COLOR,
>@@ -185,7 +186,7 @@ static void flush_decoder(AVCodecContext *avctx)
> ctx->prev_cmd[1] = 0;
> ctx->mode = CCMODE_ROLLUP;
> ctx->rollup = 2;
>-ctx->cursor_row = 0;
>+ctx->cursor_row = 10;
> ctx->cursor_column = 0;
> ctx->cursor_font = 0;
> ctx->cursor_color = 0;


How do you test that rows are captured correctly in ass format?
And subs are actually placed acc to row.


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

Re: [FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-13 Thread wm4 
On Tue, 12 Jan 2016 10:07:08 -0500
Ganesh Ajjanagadde  wrote:

> On Tue, Jan 12, 2016 at 9:43 AM, Ronald S. Bultje  wrote:
> > Hi,
> >
> > On Tue, Jan 12, 2016 at 7:52 AM, Ganesh Ajjanagadde 
> > wrote:
> >  
> >> On Tue, Jan 12, 2016 at 4:38 AM, wm4  wrote:  
> >> > This makes no sense. Even if fclose() should fail for
> >> > whatever obscure reasons there might be, reading already worked
> >> > without errors, and thus closing failure has no meaning to use.  
> >>
> >> Well, reading may not have worked, and the fclose may have been called
> >> in a failure path.  
> >
> >
> > Then the error should be in the code path of fread(), not fclose().
> > Displaying an error (in whatever way) related to close while the actual
> > problem was reading data is going to be confusing to the user.  
> 
> Read the rest of it; checking for every fread/fseek is not productive;
> there are at least 3 of fread/fseek in the example I gave. Printing at
> the time of closure is a natural means of doing things, again see:
> https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
> (particularly slide 7).
> 
> Again, this is more important for write than read. Or put in other

Indeed, the slides don't mention reading AT ALL.

A quick grep shows that we apparently do at least _something_ with the
return value of every single fread() call, and most if not all are in
test/example code.

> words: if the approach of checking at close is going to be nacked no
> matter what the contents of the message is; I will wash my hands off
> this issue wrt files opened read-only.
> 
> >  
> >> Just what is the point?
> >>
> >> Can you please stop trolling patches with such gratuitous statements at
> >> the end?  

Isn't my question justified? Yes, I might be missing something here,
but so far I couldn't yet think of a reason why you'd check fclose()
return values if the file is read-only and if all fread()s are checked
already. Wasting my time with reading a PDF that exclusively handling
_writing_ to _stdout_ (which you do not fclose()) did not help at all.
Maybe I'm just insane?

> >
> >
> > ... Can we not be defensive, please? ...  
> 
> There was nothing "defensive" here. Can you stop dismissing technical
> comments as "defensive"? This is not the first time you are doing
> this, and not the first time wm4 has added such useless, provocative
> statements...

Sorry for pointing out that some of your patches literally do nothing.
It's in the nature of the thing: if you flood the ML with many such
patches (with the threat included of applying them if nobody reviews
them), people _might_ be more quick to dismiss them, especially if they
find strangenesses like this one. Why are you surprised.

This is not so say that these patches are "useless" in general, but if
they're spiked with definitely useless ones (like the read-only fclose
so far appear to me to be), then I'll be critical of it. (And to be
honest, I'll just assume that the other supposedly more useful patches
were done with the same carelessness and equally superficial reasoning.)

Sorry for possibly causing drama, I'll go away now. I guess I'll
concentrate on doing actual work instead, who cares if non-sense gets
pushed to the FFmpeg repo.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2 3/9] fate: add test for realtime ccaption decoder

2016-01-13 Thread Anshul 


On 13 January 2016 7:12:54 AM IST, Aman Gupta  wrote:
>From: Aman Gupta 
>
>---
> tests/fate/subtitles.mak   |  3 +++
>tests/ref/fate/sub-cc-realtime | 42
>++
> 2 files changed, 45 insertions(+)
> create mode 100644 tests/ref/fate/sub-cc-realtime
>
>diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
>index d273f2e..8aa0279 100644
>--- a/tests/fate/subtitles.mak
>+++ b/tests/fate/subtitles.mak
>@@ -4,6 +4,9 @@ fate-sub-aqtitle: CMD = fmtstdout ass -sub_charenc
>windows-1250 -i $(TARGET_SAMP
>FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV CCAPTION_DECODER
>MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc
>fate-sub-cc: CMD = fmtstdout ass -f lavfi -i
>"movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]"
> 
>+FATE_SUBTITLES_ASS-$(call ALLYES, AVDEVICE LAVFI_INDEV
>CCAPTION_DECODER MOVIE_FILTER MPEGTS_DEMUXER) += fate-sub-cc-realtime
>+fate-sub-cc-realtime: CMD = fmtstdout ass -real_time 1 -f lavfi -i
>"movie=$(TARGET_SAMPLES)/sub/Closedcaption_rollup.m2v[out0+subcc]"
>+
>FATE_SUBTITLES_ASS-$(call DEMDEC, ASS, ASS) +=
>fate-sub-ass-to-ass-transcode
>fate-sub-ass-to-ass-transcode: CMD = fmtstdout ass -i
>$(TARGET_SAMPLES)/sub/1ededcbd7b.ass
> 
>diff --git a/tests/ref/fate/sub-cc-realtime
>b/tests/ref/fate/sub-cc-realtime
>new file mode 100644
>index 000..0b4037c
>--- /dev/null
>+++ b/tests/ref/fate/sub-cc-realtime
>@@ -0,0 +1,42 @@
>+[Script Info]
>+; Script generated by FFmpeg/Lavc
>+ScriptType: v4.00+
>+PlayResX: 384
>+PlayResY: 288
>+
>+[V4+ Styles]
>+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour,
>OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX,
>ScaleY, Spacing, Angle, BorderStyle, Outline, Shadow, Alignment,
>MarginL, MarginR, MarginV, Encoding
>+Style:
>Default,Monospace,16,0,0,0,0,100,100,0,0,3,1,0,2,10,10,10,0
>+
>+[Events]
>+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV,
>Effect, Text
>+Dialogue: 0,0:00:14.14,999:59:59.99,Default,,0,0,0,,(
>+Dialogue: 0,0:00:15.47,999:59:59.99,Default,,0,0,0,,({\i1} in
>+Dialogue: 0,0:00:15.92,999:59:59.99,Default,,0,0,0,,({\i1} inau
>+Dialogue: 0,0:00:16.36,999:59:59.99,Default,,0,0,0,,({\i1} inaudi
>+Dialogue: 0,0:00:16.81,999:59:59.99,Default,,0,0,0,,({\i1} inaudibl
>+Dialogue: 0,0:00:17.25,999:59:59.99,Default,,0,0,0,,({\i1} inaudible 
>+Dialogue: 0,0:00:17.70,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>ra
>+Dialogue: 0,0:00:18.14,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radi
>+Dialogue: 0,0:00:18.59,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio 
>+Dialogue: 0,0:00:19.03,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio ch
>+Dialogue: 0,0:00:19.48,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chat
>+Dialogue: 0,0:00:19.92,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatte
>+Dialogue: 0,0:00:20.36,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter
>+Dialogue: 0,0:00:21.70,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )
>+Dialogue: 0,0:00:42.61,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>>
>+Dialogue: 0,0:00:43.05,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> S
>+Dialogue: 0,0:00:43.50,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Saf
>+Dialogue: 0,0:00:43.94,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safet
>+Dialogue: 0,0:00:44.39,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety 
>+Dialogue: 0,0:00:44.83,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety re
>+Dialogue: 0,0:00:45.28,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety rema
>+Dialogue: 0,0:00:45.72,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remain
>+Dialogue: 0,0:00:46.17,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains 
>+Dialogue: 0,0:00:46.61,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains ou
>+Dialogue: 0,0:00:47.06,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our 
>+Dialogue: 0,0:00:47.50,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our nu
>+Dialogue: 0,0:00:47.95,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our numb
>+Dialogue: 0,0:00:48.39,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our number
>+Dialogue: 0,0:00:48.84,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our number o
>+Dialogue: 0,0:00:49.28,999:59:59.99,Default,,0,0,0,,({\i1} inaudible
>radio chatter{\i0} )\N>> Safety remains our number one


Pull request needed for this patch, can't be applied directly.

-Anshul
___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] MPlayer and QuickTime fourcc 'raw '

2016-01-13 Thread Mats Peterson 

On 01/13/2016 09:06 AM, Mats Peterson wrote:

slightly misleading, since it says that the 'raw ' fourcc stands for
"Uncompressed RGB". However, below are two files with the 'raw ' fourcc


I suppose what they mean by "uncompressed RGB" here is just a way to 
differentiate it from uncompressed YUV422, etc. A palettized file is 
"uncompressed RGB" as well, just that the RGB values are in the palette 
and not in the video samples themselves.


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

Re: [FFmpeg-devel] [PATCH v2 8/9] lavc/ccaption_dec: implement positioning for closed captions

2016-01-13 Thread wm4 
On Wed, 13 Jan 2016 08:57:30 +0100
Clément Bœsch  wrote:

> On Tue, Jan 12, 2016 at 05:42:59PM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> > 
> > Positioning math is based on the guidelines in
> > https://dvcs.w3.org/hg/text-tracks/raw-file/default/608toVTT/608toVTT.html#positioning-in-cea-608
> > ---
> >  libavcodec/ccaption_dec.c | 29 +
> >  1 file changed, 25 insertions(+), 4 deletions(-)
> > 
> > diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c  
> [...]
> > +x = ASS_DEFAULT_PLAYRESX * (0.1 + 0.0250 * j);
> > +y = ASS_DEFAULT_PLAYRESY * (0.1 + 0.0533 * i);
> > +av_bprintf(>buffer, "{\\an7}{\\pos(%d,%d)}", x, y);
> > +  
> 
> I'd be happier if the default alignment could be passed to
> ff_ass_subtitle_header() instead.
> 
> Also, how confident are you about the support of the position? Because if
> it's incorrect in some cases, the default positioning is probably much
> better.

That's just my position as a single API-user, but I think it would be
good if the ASS producers that the style can be completely overridden.
It doesn't make much sense to force applications to display the (in
other cases) completely arbitrary style libavcodec makes up.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] MPlayer and QuickTime fourcc 'raw '

2016-01-13 Thread Mats Peterson 
MPlayer seems to naively assume that a QuickTime file (or Matroska file 
with V_QUICKTIME, for that matter) with the video fourcc 'raw ' contains 
24-bit RGB video data. The QuickTime File Format Specification is 
slightly misleading, since it says that the 'raw ' fourcc stands for 
"Uncompressed RGB". However, below are two files with the 'raw ' fourcc 
from Apple's QuickTime Beta CD that are *not* 24-bit RGB, but 1-bit and 
8-bit files. FFplay handles this correctly, but MPlayer currently does 
not. When playing the 8-bit sample file below for example, it plays 
without video, and it constantly spits out "Frame too small! 
(19200<76800) Wrong format?" lines which is clearly an indication that 
it thinks the data is 24-bit RGB when it is in fact 8-bit. Now this is 
not exactly related to FFmpeg, but I know several of you guys are 
working on MPlayer as well, that's why I wanted to mention it.


1-bit sample:
https://drive.google.com/open?id=0B3_pEBoLs0fabm83dG5YLUsybDA

8-bit sample:
https://drive.google.com/open?id=0B3_pEBoLs0fadHF2U1JFZ3NSdjQ

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

Re: [FFmpeg-devel] [PATCH] lavc/mlpdec: report presence of Atmos substreams as a profile

2016-01-13 Thread wm4 
On Tue, 12 Jan 2016 20:51:46 -0600
Rodger Combs  wrote:

> ---
>  libavcodec/avcodec.h| 2 ++
>  libavcodec/mlp_parser.c | 5 +
>  libavcodec/mlpdec.c | 2 ++
>  libavcodec/profiles.c   | 6 ++
>  libavcodec/profiles.h   | 1 +
>  5 files changed, 16 insertions(+)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index f365775..81f1e9a 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3125,6 +3125,8 @@ typedef struct AVCodecContext {
>  #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
>  #define FF_PROFILE_HEVC_REXT4
>  
> +#define FF_PROFILE_TRUEHD   0
> +#define FF_PROFILE_TRUEHD_ATMOS 1
>  /**
>   * level
>   * - encoding: Set by user.
> diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
> index 23601c8..5edb27f 100644
> --- a/libavcodec/mlp_parser.c
> +++ b/libavcodec/mlp_parser.c
> @@ -31,6 +31,7 @@
>  #include "libavutil/internal.h"
>  #include "get_bits.h"
>  #include "parser.h"
> +#include "profiles.h"
>  #include "mlp_parser.h"
>  #include "mlp.h"
>  
> @@ -392,6 +393,10 @@ static int mlp_parse(AVCodecParserContext *s,
>  avctx->bit_rate = mh.peak_bitrate;
>  
>  mp->num_substreams = mh.num_substreams;
> +
> +if (avctx->codec_id == AV_CODEC_ID_TRUEHD)
> +avctx->profile = (mh.num_substreams > 3) ? 
> FF_PROFILE_TRUEHD_ATMOS :
> +   FF_PROFILE_TRUEHD;
>  }
>  
>  *poutbuf = buf;
> diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
> index c93b058..ccb59d2 100644
> --- a/libavcodec/mlpdec.c
> +++ b/libavcodec/mlpdec.c
> @@ -34,6 +34,7 @@
>  #include "internal.h"
>  #include "libavutil/crc.h"
>  #include "parser.h"
> +#include "profiles.h"
>  #include "mlp_parser.h"
>  #include "mlpdsp.h"
>  #include "mlp.h"
> @@ -1314,5 +1315,6 @@ AVCodec ff_truehd_decoder = {
>  .init   = mlp_decode_init,
>  .decode = read_access_unit,
>  .capabilities   = AV_CODEC_CAP_DR1,
> +.profiles   = NULL_IF_CONFIG_SMALL(ff_truehd_profiles),
>  };
>  #endif /* CONFIG_TRUEHD_DECODER */
> diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
> index 94069fd..ec33248 100644
> --- a/libavcodec/profiles.c
> +++ b/libavcodec/profiles.c
> @@ -129,4 +129,10 @@ const AVProfile ff_vp9_profiles[] = {
>  { FF_PROFILE_UNKNOWN },
>  };
>  
> +const AVProfile ff_truehd_profiles[] = {
> +{ FF_PROFILE_TRUEHD,   "TrueHD" },
> +{ FF_PROFILE_TRUEHD_ATMOS, "Atmos" },
> +{ FF_PROFILE_UNKNOWN },
> +};
> +
>  #endif /* !CONFIG_SMALL */
> diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
> index 7e1f74d..676a40e 100644
> --- a/libavcodec/profiles.h
> +++ b/libavcodec/profiles.h
> @@ -31,5 +31,6 @@ extern const AVProfile ff_mpeg2_video_profiles[];
>  extern const AVProfile ff_mpeg4_video_profiles[];
>  extern const AVProfile ff_vc1_profiles[];
>  extern const AVProfile ff_vp9_profiles[];
> +extern const AVProfile ff_truehd_profiles[];
>  
>  #endif

No idea about this patch, but it seems like new profiles should be
added to libavcodec/codec_desc.c as well.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavc/mjpeg2jpeg: Accept more mjpeg streams as input

2016-01-13 Thread Carl Eugen Hoyos 
Michael Niedermayer  niedermayer.cc> writes:

> > New patch attached that fixes ticket #5151.
> 
> 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 v2 2/9] lavc/ccaption_dec: implement real_time option

2016-01-13 Thread Anshul 


On 13 January 2016 7:12:53 AM IST, Aman Gupta  wrote:
>From: Aman Gupta 
>
>This new mode is useful for realtime decoding of closed captions so
>they
>can be display along with mpeg2 frames.
>
>Closed caption streams contain two major types of captions:
>
>- POPON captions, which are buffered off-screen and displayed
>  only after EOC (end of caption, aka display buffer)
>
>- PAINTON/ROLLUP captions, which are written to the display as soon as
>  they arrive.
>
>In a typical real-time eia608 decoder, commands like EOC (end of
>caption; display buffer), EDM (erase display memory) and EBM (erase
>buffered memory) perform their expected functions as soon as the
>commands are processed. This is implemented in the real_time branches
>added in this commit.
>
>Before this commit, and in the !real_time branches after this commit,
>the decoder cleverly implements its own version of the decoder which is
>specifically geared towards buffered decoding. It does so by actively
>ignoring commands like EBM (erase buffered memory), and then re-using
>the non-display buffer to hold the previous caption while the new one
>is
>received. This is the opposite of the real-time decoder, which uses the
>non-display buffer to hold the new caption while the display buffer is
>still showing the current caption.
>
>In addition to ignoring EBM, the buffered decoder also has custom
>implementations for EDM and EOC. An EDM (erase display memory) command
>flushes the existing contents before clearing the screen, and EOC
>similarly always flushes the active buffer (the previous subtitle)
>before flipping buffers.
>---
>libavcodec/ccaption_dec.c | 80
>++-
> 1 file changed, 72 insertions(+), 8 deletions(-)
>
>diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>index a9dfc94..6bdd754 100644
>--- a/libavcodec/ccaption_dec.c
>+++ b/libavcodec/ccaption_dec.c
>@@ -116,6 +116,7 @@ struct Screen {
> 
> typedef struct CCaptionSubContext {
> AVClass *class;
>+int real_time;
> struct Screen screen[2];
> int active_screen;
> uint8_t cursor_row;
>@@ -130,6 +131,8 @@ typedef struct CCaptionSubContext {
> /* visible screen time */
> int64_t startv_time;
> int64_t end_time;
>+int screen_touched;
>+int64_t last_real_time;
> char prev_cmd[2];
> /* buffer to store pkt data */
> AVBufferRef *pktbuf;
>@@ -428,15 +431,33 @@ static void handle_edm(CCaptionSubContext *ctx,
>int64_t pts)
> {
> struct Screen *screen = ctx->screen + ctx->active_screen;
> 
>-reap_screen(ctx, pts);
>+// In buffered mode, keep writing to screen until it is wiped.
>+// Before wiping the display, capture contents to emit subtitle.
>+if (!ctx->real_time)
>+reap_screen(ctx, pts);
>+
> screen->row_used = 0;
>+
>+// In realtime mode, emit an empty caption so the last one doesn't
>+// stay on the screen.
>+if (ctx->real_time)
>+reap_screen(ctx, pts);
> }
> 
> static void handle_eoc(CCaptionSubContext *ctx, int64_t pts)
> {
>-handle_edm(ctx,pts);
>+// In buffered mode, we wait til the *next* EOC and
>+// reap what was already on the screen since the last EOC.
>+if (!ctx->real_time)
>+handle_edm(ctx,pts);
>+
> ctx->active_screen = !ctx->active_screen;
> ctx->cursor_column = 0;
>+
>+// In realtime mode, we display the buffered contents (after
>+// flipping the buffer to active above) as soon as EOC arrives.
>+if (ctx->real_time)
>+reap_screen(ctx, pts);
> }
> 
>static void handle_delete_end_of_row(CCaptionSubContext *ctx, char hi,
>char lo)
>@@ -458,6 +479,9 @@ static void handle_char(CCaptionSubContext *ctx,
>char hi, char lo, int64_t pts)
> }
> write_char(ctx, screen, 0);
> 
>+if (ctx->mode != CCMODE_POPON)
>+ctx->screen_touched = 1;
>+
> /* reset prev command since character can repeat */
> ctx->prev_cmd[0] = 0;
> ctx->prev_cmd[1] = 0;
>@@ -507,10 +531,20 @@ static void process_cc608(CCaptionSubContext
>*ctx, int64_t pts, uint8_t hi, uint
> case 0x2d:
> /* carriage return */
> ff_dlog(ctx, "carriage return\n");
>-reap_screen(ctx, pts);
>+if (!ctx->real_time)
>+reap_screen(ctx, pts);
> roll_up(ctx);
> ctx->cursor_column = 0;
> break;
>+case 0x2e:
>+/* erase buffered (non displayed) memory */
>+// Only in realtime mode. In buffered mode, we re-use the
>inactive screen
>+// for our own buffering.
>+if (ctx->real_time) {
>+struct Screen *screen = ctx->screen +
>!ctx->active_screen;
>+screen->row_used = 0;
>+}
>+break;
> case 0x2f:
> /* end of caption */
> ff_dlog(ctx, "handle_eoc\n");
>@@ -562,24 +596,54 @@ static int decode(AVCodecContext *avctx, void
>*data, int

Re: [FFmpeg-devel] [PATCH v2 1/9] lavc/ccaption_dec: flush context on seek

2016-01-13 Thread Anshul 


On 13 January 2016 7:12:52 AM IST, Aman Gupta  wrote:
>From: Aman Gupta 
>
>---
> libavcodec/ccaption_dec.c | 21 +
> 1 file changed, 21 insertions(+)
>
>diff --git a/libavcodec/ccaption_dec.c b/libavcodec/ccaption_dec.c
>index ca497e5..a9dfc94 100644
>--- a/libavcodec/ccaption_dec.c
>+++ b/libavcodec/ccaption_dec.c
>@@ -173,6 +173,26 @@ static av_cold int close_decoder(AVCodecContext
>*avctx)
> return 0;
> }
> 
>+static void flush_decoder(AVCodecContext *avctx)
>+{
>+CCaptionSubContext *ctx = avctx->priv_data;
>+ctx->screen[0].row_used = 0;
>+ctx->screen[1].row_used = 0;
>+ctx->prev_cmd[0] = 0;
>+ctx->prev_cmd[1] = 0;
>+ctx->mode = CCMODE_ROLLUP;
>+ctx->rollup = 2;
>+ctx->cursor_row = 0;
>+ctx->cursor_column = 0;
>+ctx->cursor_font = 0;
>+ctx->cursor_color = 0;
>+ctx->active_screen = 0;
>+ctx->last_real_time = 0;
>+ctx->screen_touched = 0;
>+ctx->buffer_changed = 0;
>+av_bprint_clear(>buffer);
>+}
>+
> /**
>  * @param ctx closed caption context just to print log
>  */
>@@ -578,6 +598,7 @@ AVCodec ff_ccaption_decoder = {
> .priv_data_size = sizeof(CCaptionSubContext),
> .init   = init_decoder,
> .close  = close_decoder,
>+.flush  = flush_decoder,
> .decode = decode,
> .priv_class = _dec_class,
> };


LGTM

-Anshul
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw QuickTime video

2016-01-13 Thread Mats Peterson 

Match the use of AV_PIX_FMT_PAL8 for 1-bit QuickTime Animation in
lavc/qtrle. To reiterate, 1-bit video is not necessary black & white in
QuickTime, merely bi-level. The two colors can be any color. The palette,
either included in the sample description, or the default Macintosh
palette (black & white for 1-bit video) will be set in lavf/qtpalette.
See the QuickTime File Format Specification for details.

Mats
>From d1f62ac4a51329eff0c12fbab19ac8f22329d791 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Wed, 13 Jan 2016 13:29:13 +0100
Subject: [PATCH] lavc/rawdec: Use AV_PIX_FMT_PAL8 for 1-bit raw QuickTime video

Match the use of AV_PIX_FMT_PAL8 for 1-bit QuickTime Animation in
lavc/qtrle. To reiterate, 1-bit video is not necessary black & white in
QuickTime, merely bi-level. The two colors can be any color. The palette,
either included in the sample description, or the default Macintosh
palette (black & white for 1-bit video) will be set in lavf/qtpalette.
See the QuickTime File Format Specification for details.

---
 libavcodec/raw.c|4 ++--
 libavcodec/rawdec.c |   28 
 2 files changed, 22 insertions(+), 10 deletions(-)

diff --git a/libavcodec/raw.c b/libavcodec/raw.c
index 62ad338..fee56ee 100644
--- a/libavcodec/raw.c
+++ b/libavcodec/raw.c
@@ -254,13 +254,13 @@ const PixelFormatTag avpriv_pix_fmt_bps_avi[] = {
 };
 
 const PixelFormatTag avpriv_pix_fmt_bps_mov[] = {
-{ AV_PIX_FMT_MONOWHITE, 1 },
+{ AV_PIX_FMT_PAL8,  1 },
 { AV_PIX_FMT_PAL8,  2 },
 { AV_PIX_FMT_PAL8,  4 },
 { AV_PIX_FMT_PAL8,  8 },
 { AV_PIX_FMT_RGB555BE, 16 },
 { AV_PIX_FMT_RGB24,24 },
 { AV_PIX_FMT_ARGB, 32 },
-{ AV_PIX_FMT_MONOWHITE,33 },
+{ AV_PIX_FMT_PAL8, 33 },
 { AV_PIX_FMT_NONE,  0 },
 };
diff --git a/libavcodec/rawdec.c b/libavcodec/rawdec.c
index 50cee39..b509b65 100644
--- a/libavcodec/rawdec.c
+++ b/libavcodec/rawdec.c
@@ -41,7 +41,7 @@ typedef struct RawVideoContext {
 AVBufferRef *palette;
 int frame_size;  /* size of the frame in bytes */
 int flip;
-int is_2_4_bpp; // 2 or 4 bpp raw in avi/mov
+int is_1_2_4_bpp; // 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
 int is_yuv2;
 int is_lt_16bpp; // 16bpp pixfmt and bits_per_coded_sample < 16
 int tff;
@@ -159,10 +159,11 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 
 AVFrame   *frame   = data;
 
-if ((avctx->bits_per_coded_sample == 4 || avctx->bits_per_coded_sample == 2) &&
+if ((avctx->bits_per_coded_sample == 4 || avctx->bits_per_coded_sample == 2
+|| avctx->bits_per_coded_sample == 1) &&
 avctx->pix_fmt == AV_PIX_FMT_PAL8 &&
(!avctx->codec_tag || avctx->codec_tag == MKTAG('r','a','w',' '))) {
-context->is_2_4_bpp = 1;
+context->is_1_2_4_bpp = 1;
 context->frame_size = av_image_get_buffer_size(avctx->pix_fmt,
FFALIGN(avctx->width, 16),
avctx->height, 1);
@@ -174,7 +175,7 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (context->frame_size < 0)
 return context->frame_size;
 
-need_copy = !avpkt->buf || context->is_2_4_bpp || context->is_yuv2 || context->is_lt_16bpp;
+need_copy = !avpkt->buf || context->is_1_2_4_bpp || context->is_yuv2 || context->is_lt_16bpp;
 
 frame->pict_type= AV_PICTURE_TYPE_I;
 frame->key_frame= 1;
@@ -201,8 +202,8 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 if (!frame->buf[0])
 return AVERROR(ENOMEM);
 
-//2bpp and 4bpp raw in avi and mov (yes this is ugly ...)
-if (context->is_2_4_bpp) {
+// 1 bpp raw in mov, and 2 or 4 bpp raw in avi/mov
+if (context->is_1_2_4_bpp) {
 int i;
 uint8_t *dst = frame->buf[0]->data;
 buf_size = context->frame_size - AVPALETTE_SIZE;
@@ -212,8 +213,7 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 dst[2 * i + 1] = buf[i] & 15;
 }
 linesize_align = 8;
-} else {
-av_assert0(avctx->bits_per_coded_sample == 2);
+} else if (avctx->bits_per_coded_sample == 2) {
 for (i = 0; 4 * i + 3 < buf_size && isize; i++) {
 dst[4 * i + 0] = buf[i] >> 6;
 dst[4 * i + 1] = buf[i] >> 4 & 3;
@@ -221,6 +221,18 @@ static int raw_decode(AVCodecContext *avctx, void *data, int *got_frame,
 dst[4 * i + 3] = buf[i]  & 3;
 }
 linesize_align = 16;
+} else {
+av_assert0(avctx->bits_per_coded_sample == 1);
+for (i = 0; 8 * i + 7 < buf_size && isize; i++) {
+dst[8 * i + 0] = buf[i] >> 7 & 1;
+dst[8 * i + 1] = buf[i] >> 6 & 1;
+dst[8 * i + 2] = buf[i] >> 5 & 1;
+

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Kieran Kunhya 
On Wed, 13 Jan 2016 at 02:16 Andrey Turkin  wrote:

> Why not use libzvbi's slicer? It should be pretty robust with
> less-than-ideal signal.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Kieran Kunhya 
On Wed, 13 Jan 2016 at 02:16 Andrey Turkin  wrote:

> Why not use libzvbi's slicer? It should be pretty robust with
> less-than-ideal signal.
>

(now with a proper response).
IMO FFmpeg shouldn't be doing analogue signal processing. This should be
left to libzvbi.

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

Re: [FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-13 Thread wm4 
On Wed, 13 Jan 2016 10:48:01 -0500
Ganesh Ajjanagadde  wrote:

> On Wed, Jan 13, 2016 at 4:05 AM, wm4  wrote:
> > On Tue, 12 Jan 2016 10:07:08 -0500
> > Ganesh Ajjanagadde  wrote:
> >  
> >> On Tue, Jan 12, 2016 at 9:43 AM, Ronald S. Bultje  
> >> wrote:  
> >> > Hi,
> >> >
> >> > On Tue, Jan 12, 2016 at 7:52 AM, Ganesh Ajjanagadde 
> >> > wrote:
> >> >  
> >> >> On Tue, Jan 12, 2016 at 4:38 AM, wm4  wrote:  
> >> >> > This makes no sense. Even if fclose() should fail for
> >> >> > whatever obscure reasons there might be, reading already worked
> >> >> > without errors, and thus closing failure has no meaning to use.  
> >> >>
> >> >> Well, reading may not have worked, and the fclose may have been called
> >> >> in a failure path.  
> >> >
> >> >
> >> > Then the error should be in the code path of fread(), not fclose().
> >> > Displaying an error (in whatever way) related to close while the actual
> >> > problem was reading data is going to be confusing to the user.  
> >>
> >> Read the rest of it; checking for every fread/fseek is not productive;
> >> there are at least 3 of fread/fseek in the example I gave. Printing at
> >> the time of closure is a natural means of doing things, again see:
> >> https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
> >> (particularly slide 7).
> >>
> >> Again, this is more important for write than read. Or put in other  
> >
> > Indeed, the slides don't mention reading AT ALL.
> >
> > A quick grep shows that we apparently do at least _something_ with the
> > return value of every single fread() call, and most if not all are in
> > test/example code.
> >  
> >> words: if the approach of checking at close is going to be nacked no
> >> matter what the contents of the message is; I will wash my hands off
> >> this issue wrt files opened read-only.
> >>  
> >> >  
> >> >> Just what is the point?
> >> >>
> >> >> Can you please stop trolling patches with such gratuitous statements at
> >> >> the end?  
> >
> > Isn't my question justified?  
> 
> Your first point was not:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186973.html. It
> was simply gratuituous flame bait. Keep up the good work of
> selectively replying.

Both of these are perfectly valid points. To express the first in a
completely different way: should scripting/API users be forced to
parse FFmpeg log message to catch failures? Depending on the answer,
your patches are probably good enough, so don't mind me.

> > I guess I'll
> > concentrate on doing actual work instead,  
> 
> And you consider mpv "actual work". Not everyone may agree with such
> an assessment. I certainly do not. Minds infinitely greater than
> yours, mine, or anyone else's here do "actual work". Even on a
> relative scale, I don't care about a wastage of human effort on
> duplicating media playback, something VLC/mplayer/mplayer2/ffplay and
> goodness knows what does.

Oh no, I'm using FFmepg for something! I should be fucking ashamed. My
perspective might be somewhat locked-in to the software that I'm
maintaining and that happens to rely a lot on FFmpeg, but I don't think
it's as bad as you're trying to put all the time. Also I never implied
"mpv" when I wrote "actual work" above. Why are you focusing so much on
it?

Plus, I'm not the only one who works on software that uses FFmpeg.
There are many developers who use FFmpeg or its libraries selfishly for
their very own projects, and whose contributions or comments are
sometimes very specific to their own needs, yet they never get accused
of it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 1:14 PM, wm4  wrote:
> On Wed, 13 Jan 2016 10:48:01 -0500
> Ganesh Ajjanagadde  wrote:
>
>> On Wed, Jan 13, 2016 at 4:05 AM, wm4  wrote:
>> > On Tue, 12 Jan 2016 10:07:08 -0500
>> > Ganesh Ajjanagadde  wrote:
>> >
>> >> On Tue, Jan 12, 2016 at 9:43 AM, Ronald S. Bultje  
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > On Tue, Jan 12, 2016 at 7:52 AM, Ganesh Ajjanagadde 
>> >> > wrote:
>> >> >
>> >> >> On Tue, Jan 12, 2016 at 4:38 AM, wm4  wrote:
>> >> >> > This makes no sense. Even if fclose() should fail for
>> >> >> > whatever obscure reasons there might be, reading already worked
>> >> >> > without errors, and thus closing failure has no meaning to use.
>> >> >>
>> >> >> Well, reading may not have worked, and the fclose may have been called
>> >> >> in a failure path.
>> >> >
>> >> >
>> >> > Then the error should be in the code path of fread(), not fclose().
>> >> > Displaying an error (in whatever way) related to close while the actual
>> >> > problem was reading data is going to be confusing to the user.
>> >>
>> >> Read the rest of it; checking for every fread/fseek is not productive;
>> >> there are at least 3 of fread/fseek in the example I gave. Printing at
>> >> the time of closure is a natural means of doing things, again see:
>> >> https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
>> >> (particularly slide 7).
>> >>
>> >> Again, this is more important for write than read. Or put in other
>> >
>> > Indeed, the slides don't mention reading AT ALL.
>> >
>> > A quick grep shows that we apparently do at least _something_ with the
>> > return value of every single fread() call, and most if not all are in
>> > test/example code.
>> >
>> >> words: if the approach of checking at close is going to be nacked no
>> >> matter what the contents of the message is; I will wash my hands off
>> >> this issue wrt files opened read-only.
>> >>
>> >> >
>> >> >> Just what is the point?
>> >> >>
>> >> >> Can you please stop trolling patches with such gratuitous statements at
>> >> >> the end?
>> >
>> > Isn't my question justified?
>>
>> Your first point was not:
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186973.html. It
>> was simply gratuituous flame bait. Keep up the good work of
>> selectively replying.
>
> Both of these are perfectly valid points. To express the first in a
> completely different way: should scripting/API users be forced to
> parse FFmpeg log message to catch failures? Depending on the answer,
> your patches are probably good enough, so don't mind me.

You are spinning the point I made.

>
>> > I guess I'll
>> > concentrate on doing actual work instead,
>>
>> And you consider mpv "actual work". Not everyone may agree with such
>> an assessment. I certainly do not. Minds infinitely greater than
>> yours, mine, or anyone else's here do "actual work". Even on a
>> relative scale, I don't care about a wastage of human effort on
>> duplicating media playback, something VLC/mplayer/mplayer2/ffplay and
>> goodness knows what does.
>
> Oh no, I'm using FFmepg for something! I should be fucking ashamed. My
> perspective might be somewhat locked-in to the software that I'm
> maintaining and that happens to rely a lot on FFmpeg, but I don't think
> it's as bad as you're trying to put all the time.

> Also I never implied
> "mpv" when I wrote "actual work" above. Why are you focusing so much on
> it?

I gave it as an illustration, since that is where the bulk of your
activity is per github.

>
> Plus, I'm not the only one who works on software that uses FFmpeg.
> There are many developers who use FFmpeg or its libraries selfishly for
> their very own projects, and whose contributions or comments are
> sometimes very specific to their own needs, yet they never get accused
> of it.

Maybe. Does not matter to the question right here what other users do.
As this is mostly off-topic, please come to IRC, I am there right now.
I can answer all questions (this and/or anything else that annoys
you).

> ___
> 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] [RFC] avcodec: Add native DCA decoder based on libdcadec.

2016-01-13 Thread foo86 
On Tue, Jan 12, 2016 at 11:58:43PM +0100, Andreas Cadhalpun wrote:
> It's not completely fixed yet, because the check is only done if
> static_fields_present is 1.

You are right, placing the check there doesn't account for case when
static_fields_present becomes 0 later. I moved the check closer to
problematic get_bits() call for a more complete fix.

> I think the correct fix would be to set mix_metadata_enabled to 0 if
> static_fields_present is 0, e.g. in the else branch in ff_dca_exss_parse.

The spec doesn't give many details about this, but when
static_fields_present is 0, values parsed earlier are supposedly
retained for stream duration, so clearing mix_metadata_enabled doesn't
seem correct in this case. 

> Thanks to your hints I could increase the coverage above 90%.
> I found a few more issues along the way:
> 
> static void get_array(GetBitContext *s, int *array, int size, int n)
> {
> int i;
> 
> for (i = 0; i < size; i++)
> array[i] = get_sbits(s, n);
> 
> This should be get_sbits_long, because n can be larger than 25.

Added xbr_bit_allocation[][] range check to make sure get_sbits()
argument doesn't exceed 23.

> static int chs_assemble_freq_bands(DCAXllDecoder *s, DCAXllChSet *c)
> {
> int i, ch, nsamples = s->nframesamples, *ptr;
> 
> av_assert1(c->nfreqbands > 1);
> 
> This assert can be triggered.

There was supposed to be a check to ensure that all channel sets have
the same number of frequency bands, but apparently it got lost during
porting. Re-added it.

> static void combine_residual_frame(DCAXllDecoder *s, DCACoreDecoder *core, 
> DCAXllChSet *c)
> {
> int ch, nsamples = s->nframesamples;
> DCAXllChSet *o;
> 
> av_assert0(c->freq == core->output_rate);
> av_assert0(nsamples == core->npcmsamples);
> 
> These two, as well.
> Maybe they should be regular error checks instead?

Hmm, core sample rate and number of samples are already checked to be
compatible with XLL at this point. There must be some bug in upsampling
logic if these asserts are triggering, however it is not obvious for me
where the problem is... Can you provide a sample which triggers these?
It would be helpful.

> static void scale_down_mix(DCAXllDecoder *s, DCAXllChSet *o, int band)
> {
> int i, j, nchannels = 0, nsamples = s->nframesamples;
> DCAXllChSet *c;
> 
> for (i = 0, c = s->chset; i < s->nactivechsets; i++, c++) {
> if (!c->hier_chset)
> continue;
> for (j = 0; j < c->nchannels; j++) {
> int scale = o->dmix_scale[nchannels++];
> if (scale != (1 << 15)) {
> s->dcadsp->dmix_scale(c->bands[band].msb_sample_buffer[j],
>   scale, nsamples);
> 
> c->bands[band].msb_sample_buffer[j] can be NULL here, which causes a crash.

A check re-added earlier to ensure that all channels sets have the same
number of frequency bands should fix this as well, I think.

> Additionally there are some rarely happening overflows in dcadsp.c.
> (More precisely in filter0, filter1, dmix_sub_c and dmix_scale_c.)
> It would be nice to avoid those, if that's possible without significant
> speed loss.

I wouldn't worry much about overflows if they happen only with fuzzed
files... Though this is definitely a problem if normal streams trigger
these.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu: check for overflow in av_clip_intp2_c

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 12:52:21AM +0100, Andreas Cadhalpun wrote:
> ---
>  libavutil/common.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavutil/common.h b/libavutil/common.h
> index f3276a2..5ae2847 100644
> --- a/libavutil/common.h
> +++ b/libavutil/common.h
> @@ -211,7 +211,7 @@ static av_always_inline av_const int32_t 
> av_clipl_int32_c(int64_t a)
>   */
>  static av_always_inline av_const int av_clip_intp2_c(int a, int p)
>  {
> -if ((a + (1 << p)) & ~((2 << p) - 1))
> +if (a >= INT_MAX - (1 << p) || ((a + (1 << p)) & ~((2 << p) - 1)))

does this differ in any case from using unsigned for the addition?
if not then using unsigned avoids the additional operations

[...]
-- 
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] dca: fix misaligned access in avpriv_dca_convert_bitstream

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 12:56:39AM +0100, Andreas Cadhalpun wrote:
> src and dst are only 8-bit-aligned, so accessing them as uint16_t causes
> SIGBUS crashes on architectures like sparc.
> 
> This fixes ubsan runtime error: load of misaligned address for type
> 'const uint16_t', which requires 2 byte alignment
> 
> Signed-off-by: Andreas Cadhalpun 
> ---
>  libavcodec/dca.c | 9 +
>  1 file changed, 5 insertions(+), 4 deletions(-)

LGTM

thx

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

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


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

Re: [FFmpeg-devel] [PATCH v2] libi264: Add Hardware Accelerated H.264 Encoder based on libVA

2016-01-13 Thread Hamza Shahid 
Hi Will,

I think we addressed all the review comments in this patch. Which are as
follows:

1. Remove inline asm for color conversion and replace with swscale, which I
did.
2. Replace static variables with #defines, which I did.
3. Remove unnecessary stuff from configure script, which I did.
4. Use named constants instead string to constant conversion function,
which I did.
5. configure script was broke, which I fixed.

Can you please be a bit more specific about which comments did we not
address. I will be more than glad to fix everything and get this patch
through.

Thanks & Regards
Hamza Shahid

On Tue, Jan 12, 2016 at 9:44 PM, Will Kelleher 
wrote:

> On 01/09, ha...@mayartech.com wrote:
> > From: "ha...@mayartech.com" 
> >
> > This commit adds a hardware accelerated H.264 encoder which utilizes
> > libVA (open source implementation of VA-API). Information about libva
> > is available at: https://en.wikipedia.org/wiki/Video_Acceleration_API
> > This encoder is only availbale on linux and supported hardware which
> > can be viewed at:
> >
> https://en.wikipedia.org/wiki/Video_Acceleration_API#Supported_hardware_and_drivers
> >
>
> Hi,
>
> I tested this and I can confirm that it at least works from a functional
> perspective.  I'm very interested in seeing this cleaned up and merged,
> since it
> provides a better alternative to h264_qsv on platforms for which Intel has
> decided to drop support in recent versions of the MediaSDK.  For example,
> my
> IvyBridge hardware is no longer supported with the current MediaSDK and is
> limited to kernel 3.14.5 with an old MediaSDK release.  I can use this
> patch to
> encode through vaapi with kernel 4.3.0 and no MediaSDK dependency.  This
> makes
> me happy!
>
> That said, it doesn't look like any of the previous review comments (which
> I
> agree with) were addressed in this second version.  Let me know if there is
> anything I can do to help.
>
> Thanks,
>
> will
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 05:01:01AM +0300, Andrey Turkin wrote:
> Why not use libzvbi's slicer? It should be pretty robust with
> less-than-ideal signal.
> 
> Regarding your code - is there a need to calculate a frequency? I did
> something similar a while back with VBI from TV signal and in my experience:
> 
> a) this kind of frequency/phase estimation doesn't work that well on a
> noisy signal.

>  b) there's really no need to estimate frequency - it's a known constant
> (well it depends on a standard but in each standard it is a constant) and
> generators usually don't deviate from it; you just need to get a good phase
> estimation based on, say, local maxima/minima of run-in bits.

to calculate the phase

the area that has alternating 0/1 values can be correlated with a
sin() and a cos(), if you consider the 2 resulting values as x and y
coordinates the angle they form from the origin is the phase.
(this can be worded simpler using complex numbers)

when above is done its essential that a whole multiple of cycles is
used the important part is that the used sin(x) and cos(x) vectors are
orthogonal, that is sum sin(x) * cos(x) over the x values considered is
0 cutting them off randomls would break that
(its also possible to use windowing instead of a exact multiple of cycles)

consider that the phase is 0 so our signal input is exactly
cos(x) (if we define that as 0°), the dot product of that with cos(x)
is "1" and sin(x) is 0
now if our input is shifted by 90deg that is it matches sin(x)
then the dot product with a cos(x) vector is 0 and sin(x) is 1
...
(also i for simpliity normalized the values, sum of cos(x)*cos(x) for
x from 0 to n would of course be larger than 1 for a larger n)

PS: not complaining about calculating the phase by some other means
above is just a suggestion

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Carl Eugen Hoyos 
Andrey Turkin  gmail.com> writes:

> Why not use libzvbi's slicer? It should be pretty 
> robust with less-than-ideal signal.

It is not entirely available under LGPL afaict.

Carl Eugen

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

Re: [FFmpeg-devel] [libav-devel] [PATCH] dca: fix misaligned access in avpriv_dca_convert_bitstream

2016-01-13 Thread Andreas Cadhalpun 
On 13.01.2016 08:01, Luca Barbato wrote:
> On 13/01/16 00:56, Andreas Cadhalpun wrote:
>> src and dst are only 8-bit-aligned, so accessing them as uint16_t causes
>> SIGBUS crashes on architectures like sparc.
>>
>> This fixes ubsan runtime error: load of misaligned address for type
>> 'const uint16_t', which requires 2 byte alignment
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/dca.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> Why is not aligned?

These are uint8_t pointers (src, dst), so they are byte-aligned, but they
get cast into uint16_t pointers (ssrc, sdst), which need 2-byte-alignement.

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

[FFmpeg-devel] [PATCH] lavu/x86/lls: add fma3 optimizations for update_lls

2016-01-13 Thread Ganesh Ajjanagadde 
This improves accuracy (very slightly) and speed for processors having
fma3.

Sample benchmark (fate flac-16-lpc-cholesky, Haswell):
old:
5993610 decicycles in ff_lpc_calc_coefs,  64 runs,  0 skips
5951528 decicycles in ff_lpc_calc_coefs, 128 runs,  0 skips

new:
5252410 decicycles in ff_lpc_calc_coefs,  64 runs,  0 skips
5232869 decicycles in ff_lpc_calc_coefs, 128 runs,  0 skips

Tested with FATE and --disable-fma3, also examined contents of
lavu/lls-test.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavutil/x86/lls.asm| 61 ++--
 libavutil/x86/lls_init.c |  4 
 2 files changed, 63 insertions(+), 2 deletions(-)

diff --git a/libavutil/x86/lls.asm b/libavutil/x86/lls.asm
index 769befb..358603a 100644
--- a/libavutil/x86/lls.asm
+++ b/libavutil/x86/lls.asm
@@ -125,8 +125,7 @@ cglobal update_lls, 2,5,8, ctx, var, i, j, covar2
 .ret:
 REP_RET
 
-%if HAVE_AVX_EXTERNAL
-INIT_YMM avx
+%macro UPDATE_LLS 0
 cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 %define covarq ctxq
 mov  countd, [ctxq + LLSModel.indep_count]
@@ -140,6 +139,18 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 vbroadcastsd ymm6, [varq + iq*8 + 16]
 vbroadcastsd ymm7, [varq + iq*8 + 24]
 vextractf128 xmm3, ymm1, 1
+%if cpuflag(fma3)
+mova ymm0, COVAR(iq  ,0)
+mova xmm2, COVAR(iq+2,2)
+vfmadd231pd ymm0, ymm1, ymm4
+vfmadd231pd xmm2, xmm3, xmm6
+vfmadd213pd ymm1, ymm5, COVAR(iq  ,1)
+vfmadd213pd xmm3, xmm7, COVAR(iq+2,3)
+mova COVAR(iq  ,0), ymm0
+mova COVAR(iq  ,1), ymm1
+mova COVAR(iq+2,2), xmm2
+mova COVAR(iq+2,3), xmm3
+%else
 vmulpd  ymm0, ymm1, ymm4
 vmulpd  ymm1, ymm1, ymm5
 vmulpd  xmm2, xmm3, xmm6
@@ -148,12 +159,27 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 ADDPD_MEM COVAR(iq  ,1), ymm1
 ADDPD_MEM COVAR(iq+2,2), xmm2
 ADDPD_MEM COVAR(iq+2,3), xmm3
+%endif ; cpuflag(fma3)
 lea jd, [iq + 4]
 cmp jd, count2d
 jg .skip4x4
 .loop4x4:
 ; Compute all 16 pairwise products of a 4x4 block
 movaymm3, [varq + jq*8]
+%if cpuflag(fma3)
+mova ymm0, COVAR(jq, 0)
+mova ymm1, COVAR(jq, 1)
+mova ymm2, COVAR(jq, 2)
+mova ymm3, COVAR(jq, 3)
+vfmadd231pd ymm0, ymm3, ymm4
+vfmadd231pd ymm1, ymm3, ymm5
+vfmadd231pd ymm2, ymm3, ymm6
+vfmadd231pd ymm3, ymm3, ymm7
+mova COVAR(jq, 0), ymm0
+mova COVAR(jq, 1), ymm1
+mova COVAR(jq, 2), ymm2
+mova COVAR(jq, 3), ymm3
+%else
 vmulpd  ymm0, ymm3, ymm4
 vmulpd  ymm1, ymm3, ymm5
 vmulpd  ymm2, ymm3, ymm6
@@ -162,6 +188,7 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 ADDPD_MEM COVAR(jq,1), ymm1
 ADDPD_MEM COVAR(jq,2), ymm2
 ADDPD_MEM COVAR(jq,3), ymm3
+%endif ; cpuflag(fma3)
 add jd, 4
 cmp jd, count2d
 jle .loop4x4
@@ -169,6 +196,20 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 cmp jd, countd
 jg .skip2x4
 movaxmm3, [varq + jq*8]
+%if cpuflag(fma3)
+mova xmm0, COVAR(jq, 0)
+mova xmm1, COVAR(jq, 1)
+mova xmm2, COVAR(jq, 2)
+mova xmm3, COVAR(jq, 3)
+vfmadd231pd xmm0, xmm3, xmm4
+vfmadd231pd xmm1, xmm3, xmm5
+vfmadd231pd xmm2, xmm3, xmm6
+vfmadd231pd xmm3, xmm3, xmm7
+mova COVAR(jq, 0), xmm0
+mova COVAR(jq, 1), xmm1
+mova COVAR(jq, 2), xmm2
+mova COVAR(jq, 3), xmm3
+%else
 vmulpd  xmm0, xmm3, xmm4
 vmulpd  xmm1, xmm3, xmm5
 vmulpd  xmm2, xmm3, xmm6
@@ -177,6 +218,7 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 ADDPD_MEM COVAR(jq,1), xmm1
 ADDPD_MEM COVAR(jq,2), xmm2
 ADDPD_MEM COVAR(jq,3), xmm3
+%endif ; cpuflag(fma3)
 .skip2x4:
 add id, 4
 add covarq, 4*COVAR_STRIDE
@@ -187,14 +229,29 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
 mov jd, id
 .loop2x1:
 vmovddup xmm0, [varq + iq*8]
+%if cpuflag(fma3)
+mova xmm1, [varq + jq*8]
+vfmadd213pd xmm0, xmm1, COVAR(jq,0)
+mova COVAR(jq,0), xmm0
+%else
 vmulpd   xmm0, [varq + jq*8]
 ADDPD_MEM COVAR(jq,0), xmm0
+%endif ; cpuflag(fma3)
 inc id
 add covarq, COVAR_STRIDE
 cmp id, countd
 jle .loop2x1
 .ret:
 REP_RET
+%endmacro ; UPDATE_LLS
+
+%if HAVE_AVX_EXTERNAL
+INIT_YMM avx
+UPDATE_LLS
+%endif
+%if HAVE_FMA3_EXTERNAL
+INIT_YMM fma3
+UPDATE_LLS
 %endif
 
 INIT_XMM sse2
diff --git a/libavutil/x86/lls_init.c b/libavutil/x86/lls_init.c
index 81f141c..9f0d862 100644
--- a/libavutil/x86/lls_init.c
+++ b/libavutil/x86/lls_init.c
@@ -25,6 +25,7 @@
 
 void ff_update_lls_sse2(LLSModel *m, const double *var);
 void ff_update_lls_avx(LLSModel *m, const double *var);
+void ff_update_lls_fma3(LLSModel *m, const double *var);
 double ff_evaluate_lls_sse2(LLSModel *m, const double *var, int order);
 
 av_cold void ff_init_lls_x86(LLSModel *m)
@@ -38,4 +39,7 @@ av_cold void ff_init_lls_x86(LLSModel *m)
 if

Re: [FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

2016-01-13 Thread Christophe Gisquet 
> -#define YUVRGB_TABLE_HEADROOM 256
> +#define YUVRGB_TABLE_HEADROOM 512
[...]
> -const int yoffs = fullRange ? 384 : 326;
> +const int yoffs = fullRange ? 896 : 838;

I think it's time to use that macro everywhere it is actually used without
showing up.

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

Re: [FFmpeg-devel] [RFC] avcodec: Add native DCA decoder based on libdcadec.

2016-01-13 Thread Andreas Cadhalpun 
On 13.01.2016 19:18, foo86 wrote:
> On Tue, Jan 12, 2016 at 11:58:43PM +0100, Andreas Cadhalpun wrote:
>> It's not completely fixed yet, because the check is only done if
>> static_fields_present is 1.
> 
> You are right, placing the check there doesn't account for case when
> static_fields_present becomes 0 later. I moved the check closer to
> problematic get_bits() call for a more complete fix.

OK.

>> I think the correct fix would be to set mix_metadata_enabled to 0 if
>> static_fields_present is 0, e.g. in the else branch in ff_dca_exss_parse.
> 
> The spec doesn't give many details about this, but when
> static_fields_present is 0, values parsed earlier are supposedly
> retained for stream duration, so clearing mix_metadata_enabled doesn't
> seem correct in this case. 

I see.

>> Thanks to your hints I could increase the coverage above 90%.
>> I found a few more issues along the way:
>>
>> static void get_array(GetBitContext *s, int *array, int size, int n)
>> {
>> int i;
>>
>> for (i = 0; i < size; i++)
>> array[i] = get_sbits(s, n);
>>
>> This should be get_sbits_long, because n can be larger than 25.
> 
> Added xbr_bit_allocation[][] range check to make sure get_sbits()
> argument doesn't exceed 23.

Thanks.

>> static int chs_assemble_freq_bands(DCAXllDecoder *s, DCAXllChSet *c)
>> {
>> int i, ch, nsamples = s->nframesamples, *ptr;
>>
>> av_assert1(c->nfreqbands > 1);
>>
>> This assert can be triggered.
> 
> There was supposed to be a check to ensure that all channel sets have
> the same number of frequency bands, but apparently it got lost during
> porting. Re-added it.

That fixed it.

>> static void combine_residual_frame(DCAXllDecoder *s, DCACoreDecoder *core, 
>> DCAXllChSet *c)
>> {
>> int ch, nsamples = s->nframesamples;
>> DCAXllChSet *o;
>>
>> av_assert0(c->freq == core->output_rate);
>> av_assert0(nsamples == core->npcmsamples);
>>
>> These two, as well.
>> Maybe they should be regular error checks instead?
> 
> Hmm, core sample rate and number of samples are already checked to be
> compatible with XLL at this point. There must be some bug in upsampling
> logic if these asserts are triggering, however it is not obvious for me
> where the problem is... Can you provide a sample which triggers these?
> It would be helpful.

Sure, I'll send them to you privately.

>> static void scale_down_mix(DCAXllDecoder *s, DCAXllChSet *o, int band)
>> {
>> int i, j, nchannels = 0, nsamples = s->nframesamples;
>> DCAXllChSet *c;
>>
>> for (i = 0, c = s->chset; i < s->nactivechsets; i++, c++) {
>> if (!c->hier_chset)
>> continue;
>> for (j = 0; j < c->nchannels; j++) {
>> int scale = o->dmix_scale[nchannels++];
>> if (scale != (1 << 15)) {
>> s->dcadsp->dmix_scale(c->bands[band].msb_sample_buffer[j],
>>   scale, nsamples);
>>
>> c->bands[band].msb_sample_buffer[j] can be NULL here, which causes a crash.
> 
> A check re-added earlier to ensure that all channels sets have the same
> number of frequency bands should fix this as well, I think.

Yes, it does.

>> Additionally there are some rarely happening overflows in dcadsp.c.
>> (More precisely in filter0, filter1, dmix_sub_c and dmix_scale_c.)
>> It would be nice to avoid those, if that's possible without significant
>> speed loss.
> 
> I wouldn't worry much about overflows if they happen only with fuzzed
> files... Though this is definitely a problem if normal streams trigger
> these.

They only happen with fuzzed samples and quite rarely at that.
I just wanted to mention it for completeness.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/aacenc: Check for +-Inf too

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 5:53 PM, Michael Niedermayer  wrote:
> ffmpeg | branch: master | Michael Niedermayer  | Wed 
> Jan 13 22:33:59 2016 +0100| [92465a2347d959cbd9864b017a39b2a4ab9313ff] | 
> committer: Michael Niedermayer
>
> avcodec/aacenc: Check for +-Inf too
>
> Fixes out of array read
> Fixes: 
> 04442da73d935b776d2236282588d4f9/signal_sigsegv_2625a69_8790_ae85ffc889070663319b3417ede777b0.mov
>
> Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
> Signed-off-by: Michael Niedermayer 
>
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=92465a2347d959cbd9864b017a39b2a4ab9313ff
> ---
>
>  libavcodec/aacenc.c |   18 +-
>  1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> index 2a3fc6e..9a7d3a8 100644
> --- a/libavcodec/aacenc.c
> +++ b/libavcodec/aacenc.c
> @@ -606,16 +606,16 @@ static int aac_encode_frame(AVCodecContext *avctx, 
> AVPacket *avpkt,
>  s->mdct1024.mdct_calc(>mdct1024, sce->lcoeffs, 
> sce->ret_buf);
>  }
>
> -if (isnan(cpe->ch->coeffs[0]) ||
> -isnan(cpe->ch->coeffs[  128]) ||
> -isnan(cpe->ch->coeffs[2*128]) ||
> -isnan(cpe->ch->coeffs[3*128]) ||
> -isnan(cpe->ch->coeffs[4*128]) ||
> -isnan(cpe->ch->coeffs[5*128]) ||
> -isnan(cpe->ch->coeffs[6*128]) ||
> -isnan(cpe->ch->coeffs[7*128])
> +if (isnan(cpe->ch->coeffs[0]) || isinf(cpe->ch->coeffs[
> 0]) ||
> +isnan(cpe->ch->coeffs[  128]) || isinf(cpe->ch->coeffs[  
> 128]) ||
> +isnan(cpe->ch->coeffs[2*128]) || 
> isinf(cpe->ch->coeffs[2*128]) ||
> +isnan(cpe->ch->coeffs[3*128]) || 
> isinf(cpe->ch->coeffs[3*128]) ||
> +isnan(cpe->ch->coeffs[4*128]) || 
> isinf(cpe->ch->coeffs[4*128]) ||
> +isnan(cpe->ch->coeffs[5*128]) || 
> isinf(cpe->ch->coeffs[5*128]) ||
> +isnan(cpe->ch->coeffs[6*128]) || 
> isinf(cpe->ch->coeffs[6*128]) ||
> +isnan(cpe->ch->coeffs[7*128]) || 
> isinf(cpe->ch->coeffs[7*128])

A cleaner solution would be to do a !isfinite. As usual, msvc stops
the whole show, so someone can add a trivial fallback, e.g isfinite =
!(isnan || isinf).

>  ) {
> -av_log(avctx, AV_LOG_ERROR, "Input contains NaN\n");
> +av_log(avctx, AV_LOG_ERROR, "Input contains NaN/+-Inf\n");
>  return AVERROR(EINVAL);
>  }
>  avoid_clipping(s, sce);
>
> ___
> ffmpeg-cvslog mailing list
> ffmpeg-cvs...@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-cvslog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Michael Niedermayer 
On Thu, Jan 14, 2016 at 01:41:51AM +0300, Andrey Turkin wrote:
> 2016-01-13 22:32 GMT+03:00 Michael Niedermayer :
> 
> > to calculate the phase
> >
> > the area that has alternating 0/1 values can be correlated with a
> > sin() and a cos(), if you consider the 2 resulting values as x and y
> > coordinates the angle they form from the origin is the phase.
> > (this can be worded simpler using complex numbers)
> >
> > when above is done its essential that a whole multiple of cycles is
> > used the important part is that the used sin(x) and cos(x) vectors are
> > orthogonal, that is sum sin(x) * cos(x) over the x values considered is
> > 0 cutting them off randomls would break that
> > (its also possible to use windowing instead of a exact multiple of cycles)
> >
> > consider that the phase is 0 so our signal input is exactly
> > cos(x) (if we define that as 0°), the dot product of that with cos(x)
> > is "1" and sin(x) is 0
> > now if our input is shifted by 90deg that is it matches sin(x)
> > then the dot product with a cos(x) vector is 0 and sin(x) is 1
> > ...
> > (also i for simpliity normalized the values, sum of cos(x)*cos(x) for
> > x from 0 to n would of course be larger than 1 for a larger n)
> >
> 
> That should work; I wonder about runtime cost though. sin/cos for a given
> frequency can be precomputated; atan2 can be turned to table or something.
> Still there'd be about 32 multiplications to get a phase (over 4 periods).
> That's more than 25000 multiplications per second per teletext standard.

25000 operations per second is not much, copying the images takes
orders of magnitude more

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Andrey Turkin 
Slicer is a part of the library and as such is under LGPL; in fact FFmpeg
already uses the library to decode DVB teletext.



2016-01-14 1:27 GMT+03:00 Carl Eugen Hoyos :

> Andrey Turkin  gmail.com> writes:
>
> > Why not use libzvbi's slicer? It should be pretty
> > robust with less-than-ideal signal.
>
> It is not entirely available under LGPL afaict.
>
> 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] lavu/x86/lls: add fma3 optimizations for update_lls

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 6:59 PM, Ganesh Ajjanagadde
 wrote:
> This improves accuracy (very slightly) and speed for processors having
> fma3.
>
> Sample benchmark (fate flac-16-lpc-cholesky, Haswell):
> old:
> 5993610 decicycles in ff_lpc_calc_coefs,  64 runs,  0 skips
> 5951528 decicycles in ff_lpc_calc_coefs, 128 runs,  0 skips
>
> new:
> 5252410 decicycles in ff_lpc_calc_coefs,  64 runs,  0 skips
> 5232869 decicycles in ff_lpc_calc_coefs, 128 runs,  0 skips
>
> Tested with FATE and --disable-fma3, also examined contents of
> lavu/lls-test.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/x86/lls.asm| 61 
> ++--
>  libavutil/x86/lls_init.c |  4 
>  2 files changed, 63 insertions(+), 2 deletions(-)
>
> diff --git a/libavutil/x86/lls.asm b/libavutil/x86/lls.asm
> index 769befb..358603a 100644
> --- a/libavutil/x86/lls.asm
> +++ b/libavutil/x86/lls.asm
> @@ -125,8 +125,7 @@ cglobal update_lls, 2,5,8, ctx, var, i, j, covar2
>  .ret:
>  REP_RET
>
> -%if HAVE_AVX_EXTERNAL
> -INIT_YMM avx
> +%macro UPDATE_LLS 0
>  cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  %define covarq ctxq
>  mov  countd, [ctxq + LLSModel.indep_count]
> @@ -140,6 +139,18 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  vbroadcastsd ymm6, [varq + iq*8 + 16]
>  vbroadcastsd ymm7, [varq + iq*8 + 24]
>  vextractf128 xmm3, ymm1, 1
> +%if cpuflag(fma3)
> +mova ymm0, COVAR(iq  ,0)
> +mova xmm2, COVAR(iq+2,2)
> +vfmadd231pd ymm0, ymm1, ymm4
> +vfmadd231pd xmm2, xmm3, xmm6
> +vfmadd213pd ymm1, ymm5, COVAR(iq  ,1)
> +vfmadd213pd xmm3, xmm7, COVAR(iq+2,3)
> +mova COVAR(iq  ,0), ymm0
> +mova COVAR(iq  ,1), ymm1
> +mova COVAR(iq+2,2), xmm2
> +mova COVAR(iq+2,3), xmm3
> +%else
>  vmulpd  ymm0, ymm1, ymm4
>  vmulpd  ymm1, ymm1, ymm5
>  vmulpd  xmm2, xmm3, xmm6
> @@ -148,12 +159,27 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  ADDPD_MEM COVAR(iq  ,1), ymm1
>  ADDPD_MEM COVAR(iq+2,2), xmm2
>  ADDPD_MEM COVAR(iq+2,3), xmm3
> +%endif ; cpuflag(fma3)
>  lea jd, [iq + 4]
>  cmp jd, count2d
>  jg .skip4x4
>  .loop4x4:
>  ; Compute all 16 pairwise products of a 4x4 block
>  movaymm3, [varq + jq*8]
> +%if cpuflag(fma3)
> +mova ymm0, COVAR(jq, 0)
> +mova ymm1, COVAR(jq, 1)
> +mova ymm2, COVAR(jq, 2)
> +mova ymm3, COVAR(jq, 3)
> +vfmadd231pd ymm0, ymm3, ymm4
> +vfmadd231pd ymm1, ymm3, ymm5
> +vfmadd231pd ymm2, ymm3, ymm6
> +vfmadd231pd ymm3, ymm3, ymm7
> +mova COVAR(jq, 0), ymm0
> +mova COVAR(jq, 1), ymm1
> +mova COVAR(jq, 2), ymm2
> +mova COVAR(jq, 3), ymm3
> +%else
>  vmulpd  ymm0, ymm3, ymm4
>  vmulpd  ymm1, ymm3, ymm5
>  vmulpd  ymm2, ymm3, ymm6
> @@ -162,6 +188,7 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  ADDPD_MEM COVAR(jq,1), ymm1
>  ADDPD_MEM COVAR(jq,2), ymm2
>  ADDPD_MEM COVAR(jq,3), ymm3
> +%endif ; cpuflag(fma3)
>  add jd, 4
>  cmp jd, count2d
>  jle .loop4x4
> @@ -169,6 +196,20 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  cmp jd, countd
>  jg .skip2x4
>  movaxmm3, [varq + jq*8]
> +%if cpuflag(fma3)
> +mova xmm0, COVAR(jq, 0)
> +mova xmm1, COVAR(jq, 1)
> +mova xmm2, COVAR(jq, 2)
> +mova xmm3, COVAR(jq, 3)
> +vfmadd231pd xmm0, xmm3, xmm4
> +vfmadd231pd xmm1, xmm3, xmm5
> +vfmadd231pd xmm2, xmm3, xmm6
> +vfmadd231pd xmm3, xmm3, xmm7
> +mova COVAR(jq, 0), xmm0
> +mova COVAR(jq, 1), xmm1
> +mova COVAR(jq, 2), xmm2
> +mova COVAR(jq, 3), xmm3
> +%else
>  vmulpd  xmm0, xmm3, xmm4
>  vmulpd  xmm1, xmm3, xmm5
>  vmulpd  xmm2, xmm3, xmm6
> @@ -177,6 +218,7 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  ADDPD_MEM COVAR(jq,1), xmm1
>  ADDPD_MEM COVAR(jq,2), xmm2
>  ADDPD_MEM COVAR(jq,3), xmm3
> +%endif ; cpuflag(fma3)
>  .skip2x4:
>  add id, 4
>  add covarq, 4*COVAR_STRIDE
> @@ -187,14 +229,29 @@ cglobal update_lls, 3,6,8, ctx, var, count, i, j, count2
>  mov jd, id
>  .loop2x1:
>  vmovddup xmm0, [varq + iq*8]
> +%if cpuflag(fma3)
> +mova xmm1, [varq + jq*8]
> +vfmadd213pd xmm0, xmm1, COVAR(jq,0)
> +mova COVAR(jq,0), xmm0
> +%else
>  vmulpd   xmm0, [varq + jq*8]
>  ADDPD_MEM COVAR(jq,0), xmm0
> +%endif ; cpuflag(fma3)
>  inc id
>  add covarq, COVAR_STRIDE
>  cmp id, countd
>  jle .loop2x1
>  .ret:
>  REP_RET
> +%endmacro ; UPDATE_LLS
> +
> +%if HAVE_AVX_EXTERNAL
> +INIT_YMM avx
> +UPDATE_LLS
> +%endif
> +%if HAVE_FMA3_EXTERNAL
> +INIT_YMM fma3
> +UPDATE_LLS
>  %endif
>
>  INIT_XMM sse2
> diff --git a/libavutil/x86/lls_init.c b/libavutil/x86/lls_init.c
> index 81f141c..9f0d862 100644
> --- a/libavutil/x86/lls_init.c
> +++ b/libavutil/x86/lls_init.c
> @@ -25,6

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/aacenc: Check for +-Inf too

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 06:03:32PM -0500, Ganesh Ajjanagadde wrote:
> On Wed, Jan 13, 2016 at 5:53 PM, Michael Niedermayer  
> wrote:
> > ffmpeg | branch: master | Michael Niedermayer  | 
> > Wed Jan 13 22:33:59 2016 +0100| [92465a2347d959cbd9864b017a39b2a4ab9313ff] 
> > | committer: Michael Niedermayer
> >
> > avcodec/aacenc: Check for +-Inf too
> >
> > Fixes out of array read
> > Fixes: 
> > 04442da73d935b776d2236282588d4f9/signal_sigsegv_2625a69_8790_ae85ffc889070663319b3417ede777b0.mov
> >
> > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
> > Signed-off-by: Michael Niedermayer 
> >
> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=92465a2347d959cbd9864b017a39b2a4ab9313ff
> > ---
> >
> >  libavcodec/aacenc.c |   18 +-
> >  1 file changed, 9 insertions(+), 9 deletions(-)
> >
> > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
> > index 2a3fc6e..9a7d3a8 100644
> > --- a/libavcodec/aacenc.c
> > +++ b/libavcodec/aacenc.c
> > @@ -606,16 +606,16 @@ static int aac_encode_frame(AVCodecContext *avctx, 
> > AVPacket *avpkt,
> >  s->mdct1024.mdct_calc(>mdct1024, sce->lcoeffs, 
> > sce->ret_buf);
> >  }
> >
> > -if (isnan(cpe->ch->coeffs[0]) ||
> > -isnan(cpe->ch->coeffs[  128]) ||
> > -isnan(cpe->ch->coeffs[2*128]) ||
> > -isnan(cpe->ch->coeffs[3*128]) ||
> > -isnan(cpe->ch->coeffs[4*128]) ||
> > -isnan(cpe->ch->coeffs[5*128]) ||
> > -isnan(cpe->ch->coeffs[6*128]) ||
> > -isnan(cpe->ch->coeffs[7*128])
> > +if (isnan(cpe->ch->coeffs[0]) || isinf(cpe->ch->coeffs[
> > 0]) ||
> > +isnan(cpe->ch->coeffs[  128]) || isinf(cpe->ch->coeffs[  
> > 128]) ||
> > +isnan(cpe->ch->coeffs[2*128]) || 
> > isinf(cpe->ch->coeffs[2*128]) ||
> > +isnan(cpe->ch->coeffs[3*128]) || 
> > isinf(cpe->ch->coeffs[3*128]) ||
> > +isnan(cpe->ch->coeffs[4*128]) || 
> > isinf(cpe->ch->coeffs[4*128]) ||
> > +isnan(cpe->ch->coeffs[5*128]) || 
> > isinf(cpe->ch->coeffs[5*128]) ||
> > +isnan(cpe->ch->coeffs[6*128]) || 
> > isinf(cpe->ch->coeffs[6*128]) ||
> > +isnan(cpe->ch->coeffs[7*128]) || 
> > isinf(cpe->ch->coeffs[7*128])
> 
> A cleaner solution would be to do a !isfinite. As usual, msvc stops
> the whole show, so someone can add a trivial fallback, e.g isfinite =
> !(isnan || isinf).

yes, i didnt want to risk breakig build so went for the known to be
working function. Also i dont want to complicate security fixes
as they might always need backporting

Feel free to change this to isfinite in master if you prefer, its no
problem for master to have a more complex solution ...

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

In a rich man's house there is no place to spit but his face.
-- 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] [FFmpeg-cvslog] avcodec/aacenc: Check for +-Inf too

2016-01-13 Thread Hendrik Leppkes 
On Thu, Jan 14, 2016 at 12:24 AM, Ganesh Ajjanagadde  wrote:
> On Wed, Jan 13, 2016 at 6:16 PM, Michael Niedermayer
>  wrote:
>> On Wed, Jan 13, 2016 at 06:03:32PM -0500, Ganesh Ajjanagadde wrote:
>>> On Wed, Jan 13, 2016 at 5:53 PM, Michael Niedermayer  
>>> wrote:
>>> > ffmpeg | branch: master | Michael Niedermayer  | 
>>> > Wed Jan 13 22:33:59 2016 +0100| 
>>> > [92465a2347d959cbd9864b017a39b2a4ab9313ff] | committer: Michael 
>>> > Niedermayer
>>> >
>>> > avcodec/aacenc: Check for +-Inf too
>>> >
>>> > Fixes out of array read
>>> > Fixes: 
>>> > 04442da73d935b776d2236282588d4f9/signal_sigsegv_2625a69_8790_ae85ffc889070663319b3417ede777b0.mov
>>> >
>>> > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
>>> > Signed-off-by: Michael Niedermayer 
>>> >
>>> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=92465a2347d959cbd9864b017a39b2a4ab9313ff
>>> > ---
>>> >
>>> >  libavcodec/aacenc.c |   18 +-
>>> >  1 file changed, 9 insertions(+), 9 deletions(-)
>>> >
>>> > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
>>> > index 2a3fc6e..9a7d3a8 100644
>>> > --- a/libavcodec/aacenc.c
>>> > +++ b/libavcodec/aacenc.c
>>> > @@ -606,16 +606,16 @@ static int aac_encode_frame(AVCodecContext *avctx, 
>>> > AVPacket *avpkt,
>>> >  s->mdct1024.mdct_calc(>mdct1024, sce->lcoeffs, 
>>> > sce->ret_buf);
>>> >  }
>>> >
>>> > -if (isnan(cpe->ch->coeffs[0]) ||
>>> > -isnan(cpe->ch->coeffs[  128]) ||
>>> > -isnan(cpe->ch->coeffs[2*128]) ||
>>> > -isnan(cpe->ch->coeffs[3*128]) ||
>>> > -isnan(cpe->ch->coeffs[4*128]) ||
>>> > -isnan(cpe->ch->coeffs[5*128]) ||
>>> > -isnan(cpe->ch->coeffs[6*128]) ||
>>> > -isnan(cpe->ch->coeffs[7*128])
>>> > +if (isnan(cpe->ch->coeffs[0]) || isinf(cpe->ch->coeffs[  
>>> >   0]) ||
>>> > +isnan(cpe->ch->coeffs[  128]) || isinf(cpe->ch->coeffs[  
>>> > 128]) ||
>>> > +isnan(cpe->ch->coeffs[2*128]) || 
>>> > isinf(cpe->ch->coeffs[2*128]) ||
>>> > +isnan(cpe->ch->coeffs[3*128]) || 
>>> > isinf(cpe->ch->coeffs[3*128]) ||
>>> > +isnan(cpe->ch->coeffs[4*128]) || 
>>> > isinf(cpe->ch->coeffs[4*128]) ||
>>> > +isnan(cpe->ch->coeffs[5*128]) || 
>>> > isinf(cpe->ch->coeffs[5*128]) ||
>>> > +isnan(cpe->ch->coeffs[6*128]) || 
>>> > isinf(cpe->ch->coeffs[6*128]) ||
>>> > +isnan(cpe->ch->coeffs[7*128]) || 
>>> > isinf(cpe->ch->coeffs[7*128])
>>>
>>> A cleaner solution would be to do a !isfinite. As usual, msvc stops
>>> the whole show, so someone can add a trivial fallback, e.g isfinite =
>>> !(isnan || isinf).
>>
>> yes, i didnt want to risk breakig build so went for the known to be
>> working function. Also i dont want to complicate security fixes
>> as they might always need backporting
>
> good point
>
>>
>> Feel free to change this to isfinite in master if you prefer, its no
>> problem for master to have a more complex solution ...
>>
>
> I don't want to risk a direct commit either; it would be nice if
> Hendrik (or someone with missing isfinite) could test.

isfinite is only available in recent MSVC versions, older ones which
we still support do not have it, so a configure check and compat
wrapper in libm.h is needed.

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

Re: [FFmpeg-devel] [PATCH] lavu: check for overflow in av_clip_intp2_c

2016-01-13 Thread Andreas Cadhalpun 
On 13.01.2016 20:06, Michael Niedermayer wrote:
> On Wed, Jan 13, 2016 at 12:52:21AM +0100, Andreas Cadhalpun wrote:
>> ---
>>  libavutil/common.h | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavutil/common.h b/libavutil/common.h
>> index f3276a2..5ae2847 100644
>> --- a/libavutil/common.h
>> +++ b/libavutil/common.h
>> @@ -211,7 +211,7 @@ static av_always_inline av_const int32_t 
>> av_clipl_int32_c(int64_t a)
>>   */
>>  static av_always_inline av_const int av_clip_intp2_c(int a, int p)
>>  {
>> -if ((a + (1 << p)) & ~((2 << p) - 1))
>> +if (a >= INT_MAX - (1 << p) || ((a + (1 << p)) & ~((2 << p) - 1)))
> 
> does this differ in any case from using unsigned for the addition?

I don't think so.

> if not then using unsigned avoids the additional operations

OK, patch doing that attached.

Best regards,
Andreas

>From c517f77213d18625cba7ce6b6862a235c4a7c7d2 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun 
Date: Thu, 14 Jan 2016 01:15:22 +0100
Subject: [PATCH] lavu: prevent overflow in av_clip_intp2_c

This fixes ubsan runtime error: signed integer overflow: 8388608 +
2140274688 cannot be represented in type 'int'

Signed-off-by: Andreas Cadhalpun 
---
 libavutil/common.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/common.h b/libavutil/common.h
index f9766ad..7b7bcbe 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -211,7 +211,7 @@ static av_always_inline av_const int32_t av_clipl_int32_c(int64_t a)
  */
 static av_always_inline av_const int av_clip_intp2_c(int a, int p)
 {
-if ((a + (1 << p)) & ~((2 << p) - 1))
+if (((unsigned)a + (1 << p)) & ~((2 << p) - 1))
 return (a >> 31) ^ ((1 << p) - 1);
 else
 return a;
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH 2/3] lavd: add teletext quantizer

2016-01-13 Thread Andrey Turkin 
2016-01-13 22:32 GMT+03:00 Michael Niedermayer :

> to calculate the phase
>
> the area that has alternating 0/1 values can be correlated with a
> sin() and a cos(), if you consider the 2 resulting values as x and y
> coordinates the angle they form from the origin is the phase.
> (this can be worded simpler using complex numbers)
>
> when above is done its essential that a whole multiple of cycles is
> used the important part is that the used sin(x) and cos(x) vectors are
> orthogonal, that is sum sin(x) * cos(x) over the x values considered is
> 0 cutting them off randomls would break that
> (its also possible to use windowing instead of a exact multiple of cycles)
>
> consider that the phase is 0 so our signal input is exactly
> cos(x) (if we define that as 0°), the dot product of that with cos(x)
> is "1" and sin(x) is 0
> now if our input is shifted by 90deg that is it matches sin(x)
> then the dot product with a cos(x) vector is 0 and sin(x) is 1
> ...
> (also i for simpliity normalized the values, sum of cos(x)*cos(x) for
> x from 0 to n would of course be larger than 1 for a larger n)
>

That should work; I wonder about runtime cost though. sin/cos for a given
frequency can be precomputated; atan2 can be turned to table or something.
Still there'd be about 32 multiplications to get a phase (over 4 periods).
That's more than 25000 multiplications per second per teletext standard.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/diracdec: Fix qfactor/offset tables

2016-01-13 Thread Michael Niedermayer 
From: Michael Niedermayer 

It seems the previous tables where calculated with 32bit integers ignoring
overflows.
Also check for the max qindex, the value is choosen so that the qfactor/offset
fit in int32.

Fixes: 
070b7914fd5dfe8f93248bea71363410/asan_static-oob_c8d034_2764_258e20f4a3c79158aecddb61a833d756.drc
Fixes out of array reads

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer 
---
 libavcodec/diracdec.c |  108 -
 1 file changed, 63 insertions(+), 45 deletions(-)

diff --git a/libavcodec/diracdec.c b/libavcodec/diracdec.c
index 942376b..ee07ff8 100644
--- a/libavcodec/diracdec.c
+++ b/libavcodec/diracdec.c
@@ -253,53 +253,61 @@ static const uint8_t default_qmat[][4][4] = {
 { { 3,  1,  1,  0}, { 0,  4,  4,  2}, { 0,  6,  6,  5}, { 0,  9,  9,  7} },
 };
 
-static const int32_t qscale_tab[128] = {
-4, 5, 6, 7,  8,10,11,  
  13,
-   16,19,23,27, 32,38,45,  
  54,
-   64,76,91,   108,128,   152,   181,  
 215,
-  256,   304,   362,   431,512,   609,   724,  
 861,
- 1024,  1218,  1448,  1722,   2048,  2435,  2896,  
3444,
- 4096,  4871,  5793,  6889,   8192,  9742, 11585,  
   13777,
-16384, 19484,-13317, 27554,  32768, -1581,  9853,  
  -10518,
-65536, -3164,-16782,-21037, 131072, -6328,  2922,  
   23552,
-   262144,-12658,  5844,-18524, 524288, 15232, 11689,  
   28578,
-  1048576,-10085,-13110, -8471,2097152,-20170, 10267,  
  -16943,
-  4194304,   208,-15954, 31741,8388608,   416,  4579,  
   -2146,
- 16777216,   832,  9158, -4293,   33554432,  1663,-18172,  
   -8587,
- 67108864,  3326,   143,-17175,   134217728, 6653,   285,  
   31276,
-268435456, 13306,   570, -3075,   536870912,   -13938,  1140,  
   -6152,
-1073741824,12672,  2281,-12304, -2147483648,   -15205,  4561,  
  -24610,
- 0,10138,  9122, 16407,   0,   -20274,-18243,  
  -32813,
+static const int32_t qscale_tab[116] = {
+ 4, 5, 6, 7, 8,10,11,  
  13,
+16,19,23,27,32,38,45,  
  54,
+64,76,91,   108,   128,   152,   181,  
 215,
+   256,   304,   362,   431,   512,   609,   724,  
 861,
+  1024,  1218,  1448,  1722,  2048,  2435,  2896,  
3444,
+  4096,  4871,  5793,  6889,  8192,  9742, 11585,  
   13777,
+ 16384, 19484, 23170, 27554, 32768, 38968, 46341,  
   55109,
+ 65536, 77936, 92682,110218,131072,155872,185364,  
  220436,
+262144,311744,370728,440872,524288,623487,741455,  
  881744,
+   1048576,   1246974,   1482910,   1763488,   2097152,   2493948,   2965821,  
 3526975,
+   4194304,   4987896,   5931642,   7053950,   8388608,   9975792,  11863283,  
14107901,
+  16777216,  19951585,  23726566,  28215802,  33554432,  39903169,  47453133,  
56431603,
+  67108864,  79806339,  94906266, 112863206, 134217728, 159612677, 189812531, 
225726413,
+ 268435456, 319225354, 379625062, 451452825, 536870912, 638450708, 759250125, 
902905651,
+1073741824,1276901417,1518500250,1805811301,/*2147483648,2553802834,3037000500,3611622603,
+4294967296*/
 };
 
-static const int32_t qoffset_intra_tab[128] = {
+static const int32_t qoffset_intra_tab[120] = {
 1, 2, 3, 4, 4, 5, 6,   
  7,
-8,10,12,14,  16,19,23, 
   27,
-   32,38,46,54,  64,76,91, 
  108,
-  128,   152,   181,   216, 256,   305,   362, 
  431,
-  512,   609,   724,   861,1024,  1218,  1448, 
 1722,
- 2048,  2436,  2897,  3445,4096,  4871,  5793, 
 6889,
- 8192,  9742, -6658, 13777,   16384,  -790,  4927, 
-5258,
-32768, -1581, -8390,-10518,   65536, -3163,  1461, 
11776,
-   131072, -6328,  2922, -9261,  262144,  7616,  5845, 
14289,
-   524288, -5042, -6554, -4235, 1048576,-10084,  5134, 
-8471,
-  2097152,   104, -7976, 15871, 4194304,   208,  2290, 
-1072,
-  8388608,   416,  4579, -2146,

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/aacenc: Check for +-Inf too

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 6:16 PM, Michael Niedermayer
 wrote:
> On Wed, Jan 13, 2016 at 06:03:32PM -0500, Ganesh Ajjanagadde wrote:
>> On Wed, Jan 13, 2016 at 5:53 PM, Michael Niedermayer  
>> wrote:
>> > ffmpeg | branch: master | Michael Niedermayer  | 
>> > Wed Jan 13 22:33:59 2016 +0100| [92465a2347d959cbd9864b017a39b2a4ab9313ff] 
>> > | committer: Michael Niedermayer
>> >
>> > avcodec/aacenc: Check for +-Inf too
>> >
>> > Fixes out of array read
>> > Fixes: 
>> > 04442da73d935b776d2236282588d4f9/signal_sigsegv_2625a69_8790_ae85ffc889070663319b3417ede777b0.mov
>> >
>> > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
>> > Signed-off-by: Michael Niedermayer 
>> >
>> >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=92465a2347d959cbd9864b017a39b2a4ab9313ff
>> > ---
>> >
>> >  libavcodec/aacenc.c |   18 +-
>> >  1 file changed, 9 insertions(+), 9 deletions(-)
>> >
>> > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
>> > index 2a3fc6e..9a7d3a8 100644
>> > --- a/libavcodec/aacenc.c
>> > +++ b/libavcodec/aacenc.c
>> > @@ -606,16 +606,16 @@ static int aac_encode_frame(AVCodecContext *avctx, 
>> > AVPacket *avpkt,
>> >  s->mdct1024.mdct_calc(>mdct1024, sce->lcoeffs, 
>> > sce->ret_buf);
>> >  }
>> >
>> > -if (isnan(cpe->ch->coeffs[0]) ||
>> > -isnan(cpe->ch->coeffs[  128]) ||
>> > -isnan(cpe->ch->coeffs[2*128]) ||
>> > -isnan(cpe->ch->coeffs[3*128]) ||
>> > -isnan(cpe->ch->coeffs[4*128]) ||
>> > -isnan(cpe->ch->coeffs[5*128]) ||
>> > -isnan(cpe->ch->coeffs[6*128]) ||
>> > -isnan(cpe->ch->coeffs[7*128])
>> > +if (isnan(cpe->ch->coeffs[0]) || isinf(cpe->ch->coeffs[   
>> >  0]) ||
>> > +isnan(cpe->ch->coeffs[  128]) || isinf(cpe->ch->coeffs[  
>> > 128]) ||
>> > +isnan(cpe->ch->coeffs[2*128]) || 
>> > isinf(cpe->ch->coeffs[2*128]) ||
>> > +isnan(cpe->ch->coeffs[3*128]) || 
>> > isinf(cpe->ch->coeffs[3*128]) ||
>> > +isnan(cpe->ch->coeffs[4*128]) || 
>> > isinf(cpe->ch->coeffs[4*128]) ||
>> > +isnan(cpe->ch->coeffs[5*128]) || 
>> > isinf(cpe->ch->coeffs[5*128]) ||
>> > +isnan(cpe->ch->coeffs[6*128]) || 
>> > isinf(cpe->ch->coeffs[6*128]) ||
>> > +isnan(cpe->ch->coeffs[7*128]) || 
>> > isinf(cpe->ch->coeffs[7*128])
>>
>> A cleaner solution would be to do a !isfinite. As usual, msvc stops
>> the whole show, so someone can add a trivial fallback, e.g isfinite =
>> !(isnan || isinf).
>
> yes, i didnt want to risk breakig build so went for the known to be
> working function. Also i dont want to complicate security fixes
> as they might always need backporting

good point

>
> Feel free to change this to isfinite in master if you prefer, its no
> problem for master to have a more complex solution ...
>

I don't want to risk a direct commit either; it would be nice if
Hendrik (or someone with missing isfinite) could test.

> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> In a rich man's house there is no place to spit but his face.
> -- Diogenes of Sinope
>
> ___
> 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] [FFmpeg-cvslog] avcodec/aacenc: Check for +-Inf too

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 6:28 PM, Hendrik Leppkes  wrote:
> On Thu, Jan 14, 2016 at 12:24 AM, Ganesh Ajjanagadde  wrote:
>> On Wed, Jan 13, 2016 at 6:16 PM, Michael Niedermayer
>>  wrote:
>>> On Wed, Jan 13, 2016 at 06:03:32PM -0500, Ganesh Ajjanagadde wrote:
 On Wed, Jan 13, 2016 at 5:53 PM, Michael Niedermayer  
 wrote:
 > ffmpeg | branch: master | Michael Niedermayer  | 
 > Wed Jan 13 22:33:59 2016 +0100| 
 > [92465a2347d959cbd9864b017a39b2a4ab9313ff] | committer: Michael 
 > Niedermayer
 >
 > avcodec/aacenc: Check for +-Inf too
 >
 > Fixes out of array read
 > Fixes: 
 > 04442da73d935b776d2236282588d4f9/signal_sigsegv_2625a69_8790_ae85ffc889070663319b3417ede777b0.mov
 >
 > Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
 > Signed-off-by: Michael Niedermayer 
 >
 >> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=92465a2347d959cbd9864b017a39b2a4ab9313ff
 > ---
 >
 >  libavcodec/aacenc.c |   18 +-
 >  1 file changed, 9 insertions(+), 9 deletions(-)
 >
 > diff --git a/libavcodec/aacenc.c b/libavcodec/aacenc.c
 > index 2a3fc6e..9a7d3a8 100644
 > --- a/libavcodec/aacenc.c
 > +++ b/libavcodec/aacenc.c
 > @@ -606,16 +606,16 @@ static int aac_encode_frame(AVCodecContext *avctx, 
 > AVPacket *avpkt,
 >  s->mdct1024.mdct_calc(>mdct1024, sce->lcoeffs, 
 > sce->ret_buf);
 >  }
 >
 > -if (isnan(cpe->ch->coeffs[0]) ||
 > -isnan(cpe->ch->coeffs[  128]) ||
 > -isnan(cpe->ch->coeffs[2*128]) ||
 > -isnan(cpe->ch->coeffs[3*128]) ||
 > -isnan(cpe->ch->coeffs[4*128]) ||
 > -isnan(cpe->ch->coeffs[5*128]) ||
 > -isnan(cpe->ch->coeffs[6*128]) ||
 > -isnan(cpe->ch->coeffs[7*128])
 > +if (isnan(cpe->ch->coeffs[0]) || isinf(cpe->ch->coeffs[ 
 >0]) ||
 > +isnan(cpe->ch->coeffs[  128]) || isinf(cpe->ch->coeffs[ 
 >  128]) ||
 > +isnan(cpe->ch->coeffs[2*128]) || 
 > isinf(cpe->ch->coeffs[2*128]) ||
 > +isnan(cpe->ch->coeffs[3*128]) || 
 > isinf(cpe->ch->coeffs[3*128]) ||
 > +isnan(cpe->ch->coeffs[4*128]) || 
 > isinf(cpe->ch->coeffs[4*128]) ||
 > +isnan(cpe->ch->coeffs[5*128]) || 
 > isinf(cpe->ch->coeffs[5*128]) ||
 > +isnan(cpe->ch->coeffs[6*128]) || 
 > isinf(cpe->ch->coeffs[6*128]) ||
 > +isnan(cpe->ch->coeffs[7*128]) || 
 > isinf(cpe->ch->coeffs[7*128])

 A cleaner solution would be to do a !isfinite. As usual, msvc stops
 the whole show, so someone can add a trivial fallback, e.g isfinite =
 !(isnan || isinf).
>>>
>>> yes, i didnt want to risk breakig build so went for the known to be
>>> working function. Also i dont want to complicate security fixes
>>> as they might always need backporting
>>
>> good point
>>
>>>
>>> Feel free to change this to isfinite in master if you prefer, its no
>>> problem for master to have a more complex solution ...
>>>
>>
>> I don't want to risk a direct commit either; it would be nice if
>> Hendrik (or someone with missing isfinite) could test.
>
> isfinite is only available in recent MSVC versions, older ones which
> we still support do not have it, so a configure check and compat
> wrapper in libm.h is needed.

Thanks for clarifying the status. What I meant was that although I can
create such a patch, I would prefer at least a build test by you
before committing to master ideally.

Submitted patch just now to bring in isfinite support.

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

[FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ganesh Ajjanagadde 
Signed-off-by: Ganesh Ajjanagadde 
---
 configure| 1 +
 libavutil/libm.h | 4 
 2 files changed, 5 insertions(+)

diff --git a/configure b/configure
index 415d939..a3aaa25 100755
--- a/configure
+++ b/configure
@@ -1821,6 +1821,7 @@ MATH_FUNCS="
 exp2f
 expf
 hypot
+isfinite
 isinf
 isnan
 ldexpf
diff --git a/libavutil/libm.h b/libavutil/libm.h
index bc44dca..f01e5c6 100644
--- a/libavutil/libm.h
+++ b/libavutil/libm.h
@@ -343,6 +343,10 @@ static av_always_inline av_const int avpriv_isnan(double x)
 : avpriv_isnan(x))
 #endif /* HAVE_ISNAN */
 
+#if !HAVE_ISFINITE
+#define isfinite(x) (!(isinf(x) || isnan(x)))
+#endif /* HAVE_ISFINITE */
+
 #if !HAVE_HYPOT
 static inline av_const double hypot(double x, double y)
 {
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] dca: fix misaligned access in avpriv_dca_convert_bitstream

2016-01-13 Thread Andreas Cadhalpun 
On 13.01.2016 20:07, Michael Niedermayer wrote:
> On Wed, Jan 13, 2016 at 12:56:39AM +0100, Andreas Cadhalpun wrote:
>> src and dst are only 8-bit-aligned, so accessing them as uint16_t causes
>> SIGBUS crashes on architectures like sparc.
>>
>> This fixes ubsan runtime error: load of misaligned address for type
>> 'const uint16_t', which requires 2 byte alignment
>>
>> Signed-off-by: Andreas Cadhalpun 
>> ---
>>  libavcodec/dca.c | 9 +
>>  1 file changed, 5 insertions(+), 4 deletions(-)
> 
> LGTM

Pushed.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 8:07 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Jan 13, 2016 at 7:48 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje 
>> wrote:
>> > Hi,
>> >
>> > On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde
>> > 
>> > wrote:
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  configure| 1 +
>> >>  libavutil/libm.h | 4 
>> >>  2 files changed, 5 insertions(+)
>> >>
>> >> diff --git a/configure b/configure
>> >> index 415d939..a3aaa25 100755
>> >> --- a/configure
>> >> +++ b/configure
>> >> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
>> >>  exp2f
>> >>  expf
>> >>  hypot
>> >> +isfinite
>> >>  isinf
>> >>  isnan
>> >>  ldexpf
>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> >> index bc44dca..f01e5c6 100644
>> >> --- a/libavutil/libm.h
>> >> +++ b/libavutil/libm.h
>> >> @@ -343,6 +343,10 @@ static av_always_inline av_const int
>> >> avpriv_isnan(double x)
>> >>  : avpriv_isnan(x))
>> >>  #endif /* HAVE_ISNAN */
>> >>
>> >> +#if !HAVE_ISFINITE
>> >> +#define isfinite(x) (!(isinf(x) || isnan(x)))
>> >> +#endif /* HAVE_ISFINITE */
>> >
>> >
>> > This will break if you use isfinite(*ptr++) or something obscure like
>> > that.
>>
>> isfinite is a macro, not a function (man isfinite). Your point is
>> still valid though, really it should do a sizeof first (dbl/float),
>> then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.
>
>
> Does type matter much? Afaik, inf/nan will be maintained between
> float/double/long double.

It is important, see a commit I made earlier: 14ea4151d7c. In
particular, the main issue is that double to float conversion for dbl
outside float range is undefined behavior.

Anyway, it has been pushed. Thanks.

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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ronald S. Bultje 
Hi,

On Wed, Jan 13, 2016 at 8:09 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Jan 13, 2016 at 8:07 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Jan 13, 2016 at 7:48 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje 
> >> wrote:
> >> > Hi,
> >> >
> >> > On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde
> >> > 
> >> > wrote:
> >> >>
> >> >> Signed-off-by: Ganesh Ajjanagadde 
> >> >> ---
> >> >>  configure| 1 +
> >> >>  libavutil/libm.h | 4 
> >> >>  2 files changed, 5 insertions(+)
> >> >>
> >> >> diff --git a/configure b/configure
> >> >> index 415d939..a3aaa25 100755
> >> >> --- a/configure
> >> >> +++ b/configure
> >> >> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
> >> >>  exp2f
> >> >>  expf
> >> >>  hypot
> >> >> +isfinite
> >> >>  isinf
> >> >>  isnan
> >> >>  ldexpf
> >> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> >> index bc44dca..f01e5c6 100644
> >> >> --- a/libavutil/libm.h
> >> >> +++ b/libavutil/libm.h
> >> >> @@ -343,6 +343,10 @@ static av_always_inline av_const int
> >> >> avpriv_isnan(double x)
> >> >>  : avpriv_isnan(x))
> >> >>  #endif /* HAVE_ISNAN */
> >> >>
> >> >> +#if !HAVE_ISFINITE
> >> >> +#define isfinite(x) (!(isinf(x) || isnan(x)))
> >> >> +#endif /* HAVE_ISFINITE */
> >> >
> >> >
> >> > This will break if you use isfinite(*ptr++) or something obscure like
> >> > that.
> >>
> >> isfinite is a macro, not a function (man isfinite). Your point is
> >> still valid though, really it should do a sizeof first (dbl/float),
> >> then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.
> >
> >
> > Does type matter much? Afaik, inf/nan will be maintained between
> > float/double/long double.
>
> It is important, see a commit I made earlier: 14ea4151d7c. In
> particular, the main issue is that double to float conversion for dbl
> outside float range is undefined behavior.


Please revert.

I don't care much that double to float conversion is undefined; just make
it a double (or long double).

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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ronald S. Bultje 
Hi,

On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde 
wrote:

> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  configure| 1 +
>  libavutil/libm.h | 4 
>  2 files changed, 5 insertions(+)
>
> diff --git a/configure b/configure
> index 415d939..a3aaa25 100755
> --- a/configure
> +++ b/configure
> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
>  exp2f
>  expf
>  hypot
> +isfinite
>  isinf
>  isnan
>  ldexpf
> diff --git a/libavutil/libm.h b/libavutil/libm.h
> index bc44dca..f01e5c6 100644
> --- a/libavutil/libm.h
> +++ b/libavutil/libm.h
> @@ -343,6 +343,10 @@ static av_always_inline av_const int
> avpriv_isnan(double x)
>  : avpriv_isnan(x))
>  #endif /* HAVE_ISNAN */
>
> +#if !HAVE_ISFINITE
> +#define isfinite(x) (!(isinf(x) || isnan(x)))
> +#endif /* HAVE_ISFINITE */


This will break if you use isfinite(*ptr++) or something obscure like that.
I'd make it an inline function. Otherwise I think it's fine.

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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ronald S. Bultje 
Hi,

On Wed, Jan 13, 2016 at 7:48 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde <
> gajjanaga...@gmail.com>
> > wrote:
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  configure| 1 +
> >>  libavutil/libm.h | 4 
> >>  2 files changed, 5 insertions(+)
> >>
> >> diff --git a/configure b/configure
> >> index 415d939..a3aaa25 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
> >>  exp2f
> >>  expf
> >>  hypot
> >> +isfinite
> >>  isinf
> >>  isnan
> >>  ldexpf
> >> diff --git a/libavutil/libm.h b/libavutil/libm.h
> >> index bc44dca..f01e5c6 100644
> >> --- a/libavutil/libm.h
> >> +++ b/libavutil/libm.h
> >> @@ -343,6 +343,10 @@ static av_always_inline av_const int
> >> avpriv_isnan(double x)
> >>  : avpriv_isnan(x))
> >>  #endif /* HAVE_ISNAN */
> >>
> >> +#if !HAVE_ISFINITE
> >> +#define isfinite(x) (!(isinf(x) || isnan(x)))
> >> +#endif /* HAVE_ISFINITE */
> >
> >
> > This will break if you use isfinite(*ptr++) or something obscure like
> that.
>
> isfinite is a macro, not a function (man isfinite). Your point is
> still valid though, really it should do a sizeof first (dbl/float),
> then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.


Does type matter much? Afaik, inf/nan will be maintained between
float/double/long double.

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

Re: [FFmpeg-devel] Discussion related to the use of a global thread pool rather than the current threading model

2016-01-13 Thread Jean-Yves Avenard 
On 9 January 2016 at 01:37, Derek Buitenhuis  wrote:
> On 1/8/2016 2:19 PM, Jean-Yves Avenard wrote:
>> I will come on Monday if that's okay... could setup a time that works
>> for you. I'm based in Melbourne Australia
>
> Most of the channel is usually around during daytime GMT/CET hours.
>
Happy to discuss this on IRC.

My nickname is jya.

I also typically hang in the #media mozilla channel.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 8:11 PM, James Almer  wrote:
> On 1/13/2016 9:48 PM, Ganesh Ajjanagadde wrote:
>> On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje  wrote:
>>> Hi,
>>>
>>> On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde 
>>> wrote:

 Signed-off-by: Ganesh Ajjanagadde 
 ---
  configure| 1 +
  libavutil/libm.h | 4 
  2 files changed, 5 insertions(+)

 diff --git a/configure b/configure
 index 415d939..a3aaa25 100755
 --- a/configure
 +++ b/configure
 @@ -1821,6 +1821,7 @@ MATH_FUNCS="
  exp2f
  expf
  hypot
 +isfinite
  isinf
  isnan
  ldexpf
 diff --git a/libavutil/libm.h b/libavutil/libm.h
 index bc44dca..f01e5c6 100644
 --- a/libavutil/libm.h
 +++ b/libavutil/libm.h
 @@ -343,6 +343,10 @@ static av_always_inline av_const int
 avpriv_isnan(double x)
  : avpriv_isnan(x))
  #endif /* HAVE_ISNAN */

 +#if !HAVE_ISFINITE
 +#define isfinite(x) (!(isinf(x) || isnan(x)))
 +#endif /* HAVE_ISFINITE */
>>>
>>>
>>> This will break if you use isfinite(*ptr++) or something obscure like that.
>>
>> isfinite is a macro, not a function (man isfinite). Your point is
>> still valid though, really it should do a sizeof first (dbl/float),
>> then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.
>>
>>> I'd make it an inline function. Otherwise I think it's fine.
>>
>> Changed locally.
>
> Please, when you're going to rewrite the entire patch into something 
> completely
> different then send the new version to the ml. "Changed locally" is acceptable
> for small changes, not full rewrites.

Judged it to be simple enough, especially since it mirrors
isnan/isinf. Sorry, will be more cautious in the future.

>
> You pushed a patch Ronald didn't ever review, saying he reviewed it. That's 
> not
> a good practice.
> ___
> 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/aacenc_is: replace pow(x, 0.75) by x/sqrtf(sqrtf(x))

2016-01-13 Thread Claudio Freire 
On Mon, Jan 11, 2016 at 7:23 PM, Ganesh Ajjanagadde
 wrote:
> This is quite an accurate approximation; testing shows ~ 2ulp error in
> the floating point result. Tested with FATE.
>
> Alternatively, if one wants "full accuracy", one can use powf, or sqrt
> instead of sqrtf. With powf, one gets 1 ulp error (theoretically should be 0, 
> as
> 0.75 is exactly representable) on GNU libm, with sqrt, 0 ulp error.
>
> Signed-off-by: Ganesh Ajjanagadde 


Pushed.

Took the liberty of abstracting out the pow implementation we
discussed on IRC into a utility function and push that. It's more
readable, and next time we'll know clearly that's the way to go.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread James Almer 
On 1/13/2016 9:48 PM, Ganesh Ajjanagadde wrote:
> On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje  wrote:
>> Hi,
>>
>> On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde 
>> wrote:
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  configure| 1 +
>>>  libavutil/libm.h | 4 
>>>  2 files changed, 5 insertions(+)
>>>
>>> diff --git a/configure b/configure
>>> index 415d939..a3aaa25 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
>>>  exp2f
>>>  expf
>>>  hypot
>>> +isfinite
>>>  isinf
>>>  isnan
>>>  ldexpf
>>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>>> index bc44dca..f01e5c6 100644
>>> --- a/libavutil/libm.h
>>> +++ b/libavutil/libm.h
>>> @@ -343,6 +343,10 @@ static av_always_inline av_const int
>>> avpriv_isnan(double x)
>>>  : avpriv_isnan(x))
>>>  #endif /* HAVE_ISNAN */
>>>
>>> +#if !HAVE_ISFINITE
>>> +#define isfinite(x) (!(isinf(x) || isnan(x)))
>>> +#endif /* HAVE_ISFINITE */
>>
>>
>> This will break if you use isfinite(*ptr++) or something obscure like that.
> 
> isfinite is a macro, not a function (man isfinite). Your point is
> still valid though, really it should do a sizeof first (dbl/float),
> then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.
> 
>> I'd make it an inline function. Otherwise I think it's fine.
> 
> Changed locally.

Please, when you're going to rewrite the entire patch into something completely
different then send the new version to the ml. "Changed locally" is acceptable
for small changes, not full rewrites.

You pushed a patch Ronald didn't ever review, saying he reviewed it. That's not
a good practice.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] swscale/yuv2rgb: Increase YUV2RGB table headroom

2016-01-13 Thread Michael Niedermayer 
From: Michael Niedermayer 

This makes SWS more robust
Fixes: 
07650a772d98aa63b0fed6370dc89037/asan_heap-oob_27ddeaf_2657_2c81ff264dee5d9712cb3251fb9c3bbb.264
Fixes: out of array read

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer 
---
 libswscale/swscale_internal.h |2 +-
 libswscale/yuv2rgb.c  |   88 -
 2 files changed, 45 insertions(+), 45 deletions(-)

diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index a53fdc4..305db4a 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -39,7 +39,7 @@
 
 #define STR(s) AV_TOSTRING(s) // AV_STRINGIFY is too long
 
-#define YUVRGB_TABLE_HEADROOM 256
+#define YUVRGB_TABLE_HEADROOM 512
 
 #define MAX_FILTER_SIZE SWS_MAX_FILTER_SIZE
 
diff --git a/libswscale/yuv2rgb.c b/libswscale/yuv2rgb.c
index 1d682ba..723bec2 100644
--- a/libswscale/yuv2rgb.c
+++ b/libswscale/yuv2rgb.c
@@ -776,7 +776,7 @@ av_cold int ff_yuv2rgb_c_init_tables(SwsContext *c, const 
int inv_table[4],
 uint16_t *y_table16;
 uint32_t *y_table32;
 int i, base, rbase, gbase, bbase, av_uninit(abase), needAlpha;
-const int yoffs = fullRange ? 384 : 326;
+const int yoffs = fullRange ? 896 : 838;
 
 int64_t crv =  inv_table[0];
 int64_t cbu =  inv_table[1];
@@ -833,10 +833,10 @@ av_cold int ff_yuv2rgb_c_init_tables(SwsContext *c, const 
int inv_table[4],
 return AVERROR(ENOMEM);
 switch (bpp) {
 case 1:
-ALLOC_YUV_TABLE(1024);
+ALLOC_YUV_TABLE(2048);
 y_table = c->yuvTable;
-yb = -(384 << 16) - oy;
-for (i = 0; i < 1024 - 110; i++) {
+yb = -(384 << 16) - 512*cy - oy;
+for (i = 0; i < 2048 - 110; i++) {
 y_table[i + 110]  = av_clip_uint8((yb + 0x8000) >> 16) >> 7;
 yb   += cy;
 }
@@ -848,60 +848,60 @@ av_cold int ff_yuv2rgb_c_init_tables(SwsContext *c, const 
int inv_table[4],
 rbase   = isRgb ? 3 : 0;
 gbase   = 1;
 bbase   = isRgb ? 0 : 3;
-ALLOC_YUV_TABLE(1024 * 3);
+ALLOC_YUV_TABLE(2048 * 3);
 y_table = c->yuvTable;
-yb = -(384 << 16) - oy;
-for (i = 0; i < 1024 - 110; i++) {
+yb = -(384 << 16) - 512*cy - oy;
+for (i = 0; i < 2048 - 110; i++) {
 int yval= av_clip_uint8((yb + 0x8000) >> 16);
 y_table[i + 110]= (yval >> 7)<< rbase;
-y_table[i +  37 + 1024] = ((yval + 43) / 85) << gbase;
-y_table[i + 110 + 2048] = (yval >> 7)<< bbase;
+y_table[i +  37 + 2048] = ((yval + 43) / 85) << gbase;
+y_table[i + 110 + 4096] = (yval >> 7)<< bbase;
 yb += cy;
 }
 fill_table(c->table_rV, 1, crv, y_table + yoffs);
-fill_table(c->table_gU, 1, cgu, y_table + yoffs + 1024);
-fill_table(c->table_bU, 1, cbu, y_table + yoffs + 2048);
+fill_table(c->table_gU, 1, cgu, y_table + yoffs + 2048);
+fill_table(c->table_bU, 1, cbu, y_table + yoffs + 4096);
 fill_gv_table(c->table_gV, 1, cgv);
 break;
 case 8:
 rbase   = isRgb ? 5 : 0;
 gbase   = isRgb ? 2 : 3;
 bbase   = isRgb ? 0 : 6;
-ALLOC_YUV_TABLE(1024 * 3);
+ALLOC_YUV_TABLE(2048 * 3);
 y_table = c->yuvTable;
-yb = -(384 << 16) - oy;
-for (i = 0; i < 1024 - 38; i++) {
+yb = -(384 << 16) - 512*cy - oy;
+for (i = 0; i < 2048 - 38; i++) {
 int yval   = av_clip_uint8((yb + 0x8000) >> 16);
 y_table[i + 16]= ((yval + 18) / 36) << rbase;
-y_table[i + 16 + 1024] = ((yval + 18) / 36) << gbase;
-y_table[i + 37 + 2048] = ((yval + 43) / 85) << bbase;
+y_table[i + 16 + 2048] = ((yval + 18) / 36) << gbase;
+y_table[i + 37 + 4096] = ((yval + 43) / 85) << bbase;
 yb += cy;
 }
 fill_table(c->table_rV, 1, crv, y_table + yoffs);
-fill_table(c->table_gU, 1, cgu, y_table + yoffs + 1024);
-fill_table(c->table_bU, 1, cbu, y_table + yoffs + 2048);
+fill_table(c->table_gU, 1, cgu, y_table + yoffs + 2048);
+fill_table(c->table_bU, 1, cbu, y_table + yoffs + 4096);
 fill_gv_table(c->table_gV, 1, cgv);
 break;
 case 12:
 rbase   = isRgb ? 8 : 0;
 gbase   = 4;
 bbase   = isRgb ? 0 : 8;
-ALLOC_YUV_TABLE(1024 * 3 * 2);
+ALLOC_YUV_TABLE(2048 * 3 * 2);
 y_table16   = c->yuvTable;
-yb = -(384 << 16) - oy;
-for (i = 0; i < 1024; i++) {
+yb = -(384 << 16) - 512*cy - oy;
+for (i = 0; i < 2048; i++) {
 uint8_t yval= av_clip_uint8((yb + 0x8000) >> 16);
 y_table16[i]= (yval >> 4) << rbase;
-

[FFmpeg-devel] [PATCH] lavc/mlpdec: report presence of Atmos substreams as a profile

2016-01-13 Thread Rodger Combs 
---
 libavcodec/avcodec.h| 2 ++
 libavcodec/codec_desc.c | 1 +
 libavcodec/mlp_parser.c | 5 +
 libavcodec/mlpdec.c | 2 ++
 libavcodec/profiles.c   | 6 ++
 libavcodec/profiles.h   | 1 +
 6 files changed, 17 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index f365775..81f1e9a 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3125,6 +3125,8 @@ typedef struct AVCodecContext {
 #define FF_PROFILE_HEVC_MAIN_STILL_PICTURE  3
 #define FF_PROFILE_HEVC_REXT4
 
+#define FF_PROFILE_TRUEHD   0
+#define FF_PROFILE_TRUEHD_ATMOS 1
 /**
  * level
  * - encoding: Set by user.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 5fbe624..cdaf0cf 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2411,6 +2411,7 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .name  = "truehd",
 .long_name = NULL_IF_CONFIG_SMALL("TrueHD"),
 .props = AV_CODEC_PROP_LOSSLESS,
+.profiles  = NULL_IF_CONFIG_SMALL(ff_truehd_profiles),
 },
 {
 .id= AV_CODEC_ID_MP4ALS,
diff --git a/libavcodec/mlp_parser.c b/libavcodec/mlp_parser.c
index 23601c8..5edb27f 100644
--- a/libavcodec/mlp_parser.c
+++ b/libavcodec/mlp_parser.c
@@ -31,6 +31,7 @@
 #include "libavutil/internal.h"
 #include "get_bits.h"
 #include "parser.h"
+#include "profiles.h"
 #include "mlp_parser.h"
 #include "mlp.h"
 
@@ -392,6 +393,10 @@ static int mlp_parse(AVCodecParserContext *s,
 avctx->bit_rate = mh.peak_bitrate;
 
 mp->num_substreams = mh.num_substreams;
+
+if (avctx->codec_id == AV_CODEC_ID_TRUEHD)
+avctx->profile = (mh.num_substreams > 3) ? FF_PROFILE_TRUEHD_ATMOS 
:
+   FF_PROFILE_TRUEHD;
 }
 
 *poutbuf = buf;
diff --git a/libavcodec/mlpdec.c b/libavcodec/mlpdec.c
index c93b058..ccb59d2 100644
--- a/libavcodec/mlpdec.c
+++ b/libavcodec/mlpdec.c
@@ -34,6 +34,7 @@
 #include "internal.h"
 #include "libavutil/crc.h"
 #include "parser.h"
+#include "profiles.h"
 #include "mlp_parser.h"
 #include "mlpdsp.h"
 #include "mlp.h"
@@ -1314,5 +1315,6 @@ AVCodec ff_truehd_decoder = {
 .init   = mlp_decode_init,
 .decode = read_access_unit,
 .capabilities   = AV_CODEC_CAP_DR1,
+.profiles   = NULL_IF_CONFIG_SMALL(ff_truehd_profiles),
 };
 #endif /* CONFIG_TRUEHD_DECODER */
diff --git a/libavcodec/profiles.c b/libavcodec/profiles.c
index 94069fd..ec33248 100644
--- a/libavcodec/profiles.c
+++ b/libavcodec/profiles.c
@@ -129,4 +129,10 @@ const AVProfile ff_vp9_profiles[] = {
 { FF_PROFILE_UNKNOWN },
 };
 
+const AVProfile ff_truehd_profiles[] = {
+{ FF_PROFILE_TRUEHD,   "TrueHD" },
+{ FF_PROFILE_TRUEHD_ATMOS, "Atmos" },
+{ FF_PROFILE_UNKNOWN },
+};
+
 #endif /* !CONFIG_SMALL */
diff --git a/libavcodec/profiles.h b/libavcodec/profiles.h
index 7e1f74d..676a40e 100644
--- a/libavcodec/profiles.h
+++ b/libavcodec/profiles.h
@@ -31,5 +31,6 @@ extern const AVProfile ff_mpeg2_video_profiles[];
 extern const AVProfile ff_mpeg4_video_profiles[];
 extern const AVProfile ff_vc1_profiles[];
 extern const AVProfile ff_vp9_profiles[];
+extern const AVProfile ff_truehd_profiles[];
 
 #endif
-- 
2.6.4

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

Re: [FFmpeg-devel] [PATCH] lavu/libm: add isfinite fallback

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 7:39 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Jan 13, 2016 at 7:10 PM, Ganesh Ajjanagadde 
> wrote:
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  configure| 1 +
>>  libavutil/libm.h | 4 
>>  2 files changed, 5 insertions(+)
>>
>> diff --git a/configure b/configure
>> index 415d939..a3aaa25 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1821,6 +1821,7 @@ MATH_FUNCS="
>>  exp2f
>>  expf
>>  hypot
>> +isfinite
>>  isinf
>>  isnan
>>  ldexpf
>> diff --git a/libavutil/libm.h b/libavutil/libm.h
>> index bc44dca..f01e5c6 100644
>> --- a/libavutil/libm.h
>> +++ b/libavutil/libm.h
>> @@ -343,6 +343,10 @@ static av_always_inline av_const int
>> avpriv_isnan(double x)
>>  : avpriv_isnan(x))
>>  #endif /* HAVE_ISNAN */
>>
>> +#if !HAVE_ISFINITE
>> +#define isfinite(x) (!(isinf(x) || isnan(x)))
>> +#endif /* HAVE_ISFINITE */
>
>
> This will break if you use isfinite(*ptr++) or something obscure like that.

isfinite is a macro, not a function (man isfinite). Your point is
still valid though, really it should do a sizeof first (dbl/float),
then call a avpriv_isfinitef, avpriv_isfinite. I was being lazy.

> I'd make it an inline function. Otherwise I think it's fine.

Changed locally.

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

Re: [FFmpeg-devel] [PATCH 00/13] check all fclose usage

2016-01-13 Thread Ganesh Ajjanagadde 
On Wed, Jan 13, 2016 at 4:05 AM, wm4  wrote:
> On Tue, 12 Jan 2016 10:07:08 -0500
> Ganesh Ajjanagadde  wrote:
>
>> On Tue, Jan 12, 2016 at 9:43 AM, Ronald S. Bultje  wrote:
>> > Hi,
>> >
>> > On Tue, Jan 12, 2016 at 7:52 AM, Ganesh Ajjanagadde 
>> > wrote:
>> >
>> >> On Tue, Jan 12, 2016 at 4:38 AM, wm4  wrote:
>> >> > This makes no sense. Even if fclose() should fail for
>> >> > whatever obscure reasons there might be, reading already worked
>> >> > without errors, and thus closing failure has no meaning to use.
>> >>
>> >> Well, reading may not have worked, and the fclose may have been called
>> >> in a failure path.
>> >
>> >
>> > Then the error should be in the code path of fread(), not fclose().
>> > Displaying an error (in whatever way) related to close while the actual
>> > problem was reading data is going to be confusing to the user.
>>
>> Read the rest of it; checking for every fread/fseek is not productive;
>> there are at least 3 of fread/fseek in the example I gave. Printing at
>> the time of closure is a natural means of doing things, again see:
>> https://www.gnu.org/ghm/2011/paris/slides/jim-meyering-goodbye-world.pdf
>> (particularly slide 7).
>>
>> Again, this is more important for write than read. Or put in other
>
> Indeed, the slides don't mention reading AT ALL.
>
> A quick grep shows that we apparently do at least _something_ with the
> return value of every single fread() call, and most if not all are in
> test/example code.
>
>> words: if the approach of checking at close is going to be nacked no
>> matter what the contents of the message is; I will wash my hands off
>> this issue wrt files opened read-only.
>>
>> >
>> >> Just what is the point?
>> >>
>> >> Can you please stop trolling patches with such gratuitous statements at
>> >> the end?
>
> Isn't my question justified?

Your first point was not:
https://ffmpeg.org/pipermail/ffmpeg-devel/2016-January/186973.html. It
was simply gratuituous flame bait. Keep up the good work of
selectively replying.

> Yes, I might be missing something here,
> but so far I couldn't yet think of a reason why you'd check fclose()
> return values if the file is read-only and if all fread()s are checked
> already.

The freads are checked; but nothing is currently logged during failure modes.

> Wasting my time with reading a PDF that exclusively handling
> _writing_ to _stdout_ (which you do not fclose()) did not help at all.
> Maybe I'm just insane?

Perhaps you are, maybe you aren't. It is irrelevant to the patch. It
was given for justifying the first point, since apparently people like
you did not recognize that this issue affects even the libraries.

>
>> >
>> >
>> > ... Can we not be defensive, please? ...
>>
>> There was nothing "defensive" here. Can you stop dismissing technical
>> comments as "defensive"? This is not the first time you are doing
>> this, and not the first time wm4 has added such useless, provocative
>> statements...
>
> Sorry for pointing out that some of your patches literally do nothing.

They don't do "nothing". See the previous fclose ones, like the one
for ffmpeg.c, or the avfilter ones. No need to feel sorry for
something you are clearly not sorry about, because I or no one else
here cares.

> It's in the nature of the thing: if you flood the ML with many such
> patches (with the threat included of applying them if nobody reviews
> them),

I apply them only when I am convinced universally of their value, and
no one objects to it. Yes, even you wm4, even with all of your
trolling and garbage comments. I take your opinions seriously, whether
or not I agree with them:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-December/184899.html.
Same goes for the read only business here; I won't apply. As it was
prefaced with "maybe theoretical", even in the absence of review, I
won't apply.

What I am surprised is where these false impressions come from.

> people _might_ be more quick to dismiss them, especially if they
> find strangenesses like this one. Why are you surprised.

I am not surprised. It is well known that you have a habit of trolling
patches here, and I am not the only one who has encountered such
behavior.

>
> This is not so say that these patches are "useless" in general, but if
> they're spiked with definitely useless ones (like the read-only fclose
> so far appear to me to be), then I'll be critical of it.
> (And to be
> honest, I'll just assume that the other supposedly more useful patches
> were done with the same carelessness and equally superficial reasoning.)

They were not done with superficial reasoning. They were clearly
prefixed with statements in the patch notes; I thus acknowledged the
possiblity. It was done for completeness, and so that others with a
lack of knee jerk reactions can comment upon. Assume whatever you feel
like, I don't care:

Re: [FFmpeg-devel] [PATCH] diracdec: Add slice threading to HQ profile

2016-01-13 Thread Rostislav Pehlivanov 
On Tue, 2016-01-12 at 21:15 +0100, Michael Niedermayer wrote:
> On Tue, Jan 12, 2016 at 01:01:24AM +, Kieran Kunhya wrote:
> > 
> 
> >  diracdec.c |   38 ++
> >  1 file changed, 30 insertions(+), 8 deletions(-)
> > 73ce8405d52477db0faa2a2b76daca698a49bff2  0001-diracdec-Add-slice-
> > threading-to-HQ-profile.patch
> > From f01ac52d8f5bddeb4bb23f41e883776e25406597 Mon Sep 17 00:00:00
> > 2001
> > From: Kieran Kunhya 
> > Date: Tue, 12 Jan 2016 00:51:49 +
> > Subject: [PATCH] diracdec: Add slice threading to HQ profile
> 
> LGTM
> 
> the loop could be factored out though 
> 
> thanks

Pushed

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/diracdec: Handle the 0 vlc case at the top of coeff_unpack_golomb()

2016-01-13 Thread Rostislav Pehlivanov 
On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> encoding changes from 17 to 20 fps
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/diracdec.c |   18 --
>  1 file changed, 12 insertions(+), 6 deletions(-)
> 

LGTM,

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/diracdec: Inline svq3_get_ue_golomb() and merge the sign bit decoding into it

2016-01-13 Thread Rostislav Pehlivanov 
On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> This avoids closing and opening the bit reader
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/diracdec.c |   37 ++---
>  1 file changed, 34 insertions(+), 3 deletions(-)
>  

LGTM,

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

[FFmpeg-devel] [PATCH] avcodec/v210: add avx2 version of the line encoder

2016-01-13 Thread James Darnley 
Around 35% faster than the avx version.
---
 libavcodec/v210enc.c  |  5 ++--
 libavcodec/v210enc.h  |  1 +
 libavcodec/x86/v210enc.asm| 53 +++
 libavcodec/x86/v210enc_init.c |  7 ++
 4 files changed, 49 insertions(+), 17 deletions(-)

diff --git a/libavcodec/v210enc.c b/libavcodec/v210enc.c
index 0612248..ec63864 100644
--- a/libavcodec/v210enc.c
+++ b/libavcodec/v210enc.c
@@ -86,6 +86,7 @@ av_cold void ff_v210enc_init(V210EncContext *s)
 {
 s->pack_line_8  = v210_planar_pack_8_c;
 s->pack_line_10 = v210_planar_pack_10_c;
+s->sample_factor = 1;
 
 if (ARCH_X86)
 ff_v210enc_init_x86(s);
@@ -172,13 +173,13 @@ static int encode_frame(AVCodecContext *avctx, AVPacket 
*pkt,
 const uint8_t *v = pic->data[2];
 for (h = 0; h < avctx->height; h++) {
 uint32_t val;
-w = (avctx->width / 12) * 12;
+w = (avctx->width / (12 * s->sample_factor)) * 12 * 
s->sample_factor;
 s->pack_line_8(y, u, v, dst, w);
 
 y += w;
 u += w >> 1;
 v += w >> 1;
-dst += (w / 12) * 32;
+dst += (w / (12 * s->sample_factor)) * 32 * s->sample_factor;
 
 for (; w < avctx->width - 5; w += 6) {
 WRITE_PIXELS8(u, y, v);
diff --git a/libavcodec/v210enc.h b/libavcodec/v210enc.h
index a205427..85f84f1 100644
--- a/libavcodec/v210enc.h
+++ b/libavcodec/v210enc.h
@@ -28,6 +28,7 @@ typedef struct V210EncContext {
 const uint8_t *v, uint8_t *dst, ptrdiff_t width);
 void (*pack_line_10)(const uint16_t *y, const uint16_t *u,
  const uint16_t *v, uint8_t *dst, ptrdiff_t width);
+int sample_factor;
 } V210EncContext;
 
 void ff_v210enc_init(V210EncContext *s);
diff --git a/libavcodec/x86/v210enc.asm b/libavcodec/x86/v210enc.asm
index 859e2d9..a8f3d3c 100644
--- a/libavcodec/x86/v210enc.asm
+++ b/libavcodec/x86/v210enc.asm
@@ -21,30 +21,31 @@
 
 %include "libavutil/x86/x86util.asm"
 
-SECTION_RODATA
+SECTION_RODATA 32
 
 cextern pw_4
 %define v210_enc_min_10 pw_4
-v210_enc_max_10: times 8 dw 0x3fb
+v210_enc_max_10: times 16 dw 0x3fb
 
-v210_enc_luma_mult_10: dw 4,1,16,4,1,16,0,0
-v210_enc_luma_shuf_10: db -1,0,1,-1,2,3,4,5,-1,6,7,-1,8,9,10,11
+v210_enc_luma_mult_10: times 2 dw 4,1,16,4,1,16,0,0
+v210_enc_luma_shuf_10: times 2 db -1,0,1,-1,2,3,4,5,-1,6,7,-1,8,9,10,11
 
-v210_enc_chroma_mult_10: dw 1,4,16,0,16,1,4,0
-v210_enc_chroma_shuf_10: db 0,1,8,9,-1,2,3,-1,10,11,4,5,-1,12,13,-1
+v210_enc_chroma_mult_10: times 2 dw 1,4,16,0,16,1,4,0
+v210_enc_chroma_shuf_10: times 2 db 0,1,8,9,-1,2,3,-1,10,11,4,5,-1,12,13,-1
 
 cextern pb_1
 %define v210_enc_min_8 pb_1
-cextern pb_FE
-%define v210_enc_max_8 pb_FE
+;cextern pb_FE
+local_pb_FE: times 32 db 0xfe
+%define v210_enc_max_8 local_pb_FE
 
-v210_enc_luma_shuf_8: db 6,-1,7,-1,8,-1,9,-1,10,-1,11,-1,-1,-1,-1,-1
-v210_enc_luma_mult_8: dw 16,4,64,16,4,64,0,0
+v210_enc_luma_shuf_8: times 2 db 6,-1,7,-1,8,-1,9,-1,10,-1,11,-1,-1,-1,-1,-1
+v210_enc_luma_mult_8: times 2 dw 16,4,64,16,4,64,0,0
 
-v210_enc_chroma_shuf1_8: db 0,-1,1,-1,2,-1,3,-1,8,-1,9,-1,10,-1,11,-1
-v210_enc_chroma_shuf2_8: db 3,-1,4,-1,5,-1,7,-1,11,-1,12,-1,13,-1,15,-1
+v210_enc_chroma_shuf1_8: times 2 db 0,-1,1,-1,2,-1,3,-1,8,-1,9,-1,10,-1,11,-1
+v210_enc_chroma_shuf2_8: times 2 db 3,-1,4,-1,5,-1,7,-1,11,-1,12,-1,13,-1,15,-1
 
-v210_enc_chroma_mult_8: dw 4,16,64,0,64,4,16,0
+v210_enc_chroma_mult_8: times 2 dw 4,16,64,0,64,4,16,0
 
 SECTION .text
 
@@ -91,7 +92,7 @@ v210_planar_pack_10
 %macro v210_planar_pack_8 0
 
 ; v210_planar_pack_8(const uint8_t *y, const uint8_t *u, const uint8_t *v, 
uint8_t *dst, ptrdiff_t width)
-cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
+cglobal v210_planar_pack_8, 5, 5, 7+cpuflag(avx2), y, u, v, dst, width
 add yq, widthq
 shr widthq, 1
 add uq, widthq
@@ -103,7 +104,12 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 pxorm6, m6
 
 .loop:
+%if cpuflag(avx2)
+movuxm1, [yq+widthq*2]
+vinserti128 m1,   m1, [yq+widthq*2+12], 1
+%else
 movum1, [yq+2*widthq]
+%endif
 CLIPUB  m1, m4, m5
 
 punpcklbw m0, m1, m6
@@ -116,8 +122,16 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 pshufb  m0, [v210_enc_luma_shuf_10]
 pshufb  m1, [v210_enc_luma_shuf_10]
 
+%if cpuflag(avx2)
+movq xm3, [uq+widthq]
+movhps   xm3, [vq+widthq]
+movq xm7, [uq+widthq+6]
+movhps   xm7, [vq+widthq+6]
+vinserti128  m3,   m3, xm7, 1
+%else
 movqm3, [uq+widthq]
 movhps  m3, [vq+widthq]
+%endif
 CLIPUB  m3, m4, m5
 
 ; shuffle and multiply to get the same packing as in 10-bit
@@ -132,11 +146,18 @@ cglobal v210_planar_pack_8, 5, 5, 7, y, u, v, dst, width
 por m0, m2
 por m1, m3
 
+%if cpuflag(avx2)
+movu [dstq],xm0
+movu [dstq+16], xm1
+vextracti128 [dstq+32], m0,

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/diracdec: Factor +2 out of the inner loop

2016-01-13 Thread Rostislav Pehlivanov 
On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/diracdec.c |   10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 

LGTM,

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/diracdec: Factor +2 out of the inner loop

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 04:12:54PM +, Rostislav Pehlivanov wrote:
> On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/diracdec.c |   10 +-
> >  1 file changed, 5 insertions(+), 5 deletions(-)
> > 
> 
> LGTM,

applied

thx

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

I have never wished to cater to the crowd; for what I know they do not
approve, and what they approve I do not know. -- Epicurus


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/diracdec: Handle the 0 vlc case at the top of coeff_unpack_golomb()

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 04:12:17PM +, Rostislav Pehlivanov wrote:
> On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > encoding changes from 17 to 20 fps
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/diracdec.c |   18 --
> >  1 file changed, 12 insertions(+), 6 deletions(-)
> > 
> 
> LGTM,

applied

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/diracdec: Inline svq3_get_ue_golomb() and merge the sign bit decoding into it

2016-01-13 Thread Michael Niedermayer 
On Wed, Jan 13, 2016 at 04:11:40PM +, Rostislav Pehlivanov wrote:
> On Tue, 2016-01-12 at 23:32 +0100, Michael Niedermayer wrote:
> > From: Michael Niedermayer 
> > 
> > This avoids closing and opening the bit reader
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/diracdec.c |   37 ++---
> >  1 file changed, 34 insertions(+), 3 deletions(-)
> >  
> 
> LGTM,

applied

thx

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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