[libav-devel] [PATCH] alac: check for truncated packets

2012-07-19 Thread Justin Ruggles 
This will give a clearer error message when the error is caused by a
truncated packet.
---
 libavcodec/alac.c |   15 +++
 1 files changed, 11 insertions(+), 4 deletions(-)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 1756cdf..61d2e70 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -432,16 +432,19 @@ static int alac_decode_frame(AVCodecContext *avctx, void 
*data,
 ALACContext *alac = avctx->priv_data;
 enum RawDataBlockType element;
 int channels;
-int ch, ret;
+int ch, ret, got_end;
 
 init_get_bits(&alac->gb, avpkt->data, avpkt->size * 8);
 
+got_end = 0;
 alac->nb_samples = 0;
 ch = 0;
-while (get_bits_left(&alac->gb)) {
+while (get_bits_left(&alac->gb) >= 3) {
 element = get_bits(&alac->gb, 3);
-if (element == TYPE_END)
+if (element == TYPE_END) {
+got_end = 1;
 break;
+}
 if (element > TYPE_CPE && element != TYPE_LFE) {
 av_log(avctx, AV_LOG_ERROR, "syntax element unsupported: %d", 
element);
 return AVERROR_PATCHWELCOME;
@@ -456,11 +459,15 @@ static int alac_decode_frame(AVCodecContext *avctx, void 
*data,
 ret = decode_element(avctx, data,
  alac_channel_layout_offsets[alac->channels - 
1][ch],
  channels);
-if (ret < 0)
+if (ret < 0 && get_bits_left(&alac->gb))
 return ret;
 
 ch += channels;
 }
+if (!got_end) {
+av_log(avctx, AV_LOG_ERROR, "no end tag found. incomplete packet.\n");
+return AVERROR_INVALIDDATA;
+}
 
 if (avpkt->size * 8 - get_bits_count(&alac->gb) > 8) {
 av_log(avctx, AV_LOG_ERROR, "Error : %d bits left\n",
-- 
1.7.1

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

Re: [libav-devel] [PATCH 2/2] cafdec: allow larger ALAC magic cookie

2012-07-19 Thread Luca Barbato 
On 07/20/2012 01:49 AM, Justin Ruggles wrote:
> It already skips any extra bytes at the end, and apparently there are some
> samples in the wild with larger 'kuki' chunks.
> ---
>  libavformat/cafdec.c |2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)

Ok.


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

Re: [libav-devel] [PATCH 1/2] alac: fix channel pointer assignment for 24 and 32-bit

2012-07-19 Thread Luca Barbato 
On 07/20/2012 01:49 AM, Justin Ruggles wrote:
> Needs to be done separately for each element.
> ---
>  libavcodec/alac.c |8 
>  1 files changed, 4 insertions(+), 4 deletions(-)

Ok.


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

[libav-devel] [PATCH 2/2] cafdec: allow larger ALAC magic cookie

2012-07-19 Thread Justin Ruggles 
It already skips any extra bytes at the end, and apparently there are some
samples in the wild with larger 'kuki' chunks.
---
 libavformat/cafdec.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/cafdec.c b/libavformat/cafdec.c
index 6c40b1b..b2eccb9 100644
--- a/libavformat/cafdec.c
+++ b/libavformat/cafdec.c
@@ -124,7 +124,7 @@ static int read_kuki_chunk(AVFormatContext *s, int64_t size)
 #define ALAC_HEADER   36
 #define ALAC_NEW_KUKI 24
 uint8_t preamble[12];
-if (size < ALAC_NEW_KUKI || size > ALAC_PREAMBLE + ALAC_HEADER) {
+if (size < ALAC_NEW_KUKI) {
 av_log(s, AV_LOG_ERROR, "invalid ALAC magic cookie\n");
 avio_skip(pb, size);
 return AVERROR_INVALIDDATA;
-- 
1.7.1

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

[libav-devel] [PATCH 1/2] alac: fix channel pointer assignment for 24 and 32-bit

2012-07-19 Thread Justin Ruggles 
Needs to be done separately for each element.
---
 libavcodec/alac.c |8 
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index bb2e836..1756cdf 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -321,16 +321,16 @@ static int decode_element(AVCodecContext *avctx, void 
*data, int ch_index,
 av_log(avctx, AV_LOG_ERROR, "get_buffer() failed\n");
 return ret;
 }
-if (alac->sample_size > 16) {
-for (ch = 0; ch < channels; ch++)
-alac->output_samples_buffer[ch] = (int32_t 
*)alac->frame.extended_data[ch_index + ch];
-}
 } else if (output_samples != alac->nb_samples) {
 av_log(avctx, AV_LOG_ERROR, "sample count mismatch: %u != %d\n",
output_samples, alac->nb_samples);
 return AVERROR_INVALIDDATA;
 }
 alac->nb_samples = output_samples;
+if (alac->sample_size > 16) {
+for (ch = 0; ch < channels; ch++)
+alac->output_samples_buffer[ch] = (int32_t 
*)alac->frame.extended_data[ch_index + ch];
+}
 
 if (is_compressed) {
 int16_t lpc_coefs[2][32];
-- 
1.7.1

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

Re: [libav-devel] [PATCH] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Alex Converse 
On Thu, Jul 19, 2012 at 2:33 PM, Luca Barbato  wrote:
> On 07/19/2012 10:36 PM, Johan Andersson wrote:
>> On Thu, Jul 19, 2012 at 08:59:45PM +0200, Luca Barbato wrote:
>>> OpenJPEG can decode in lower resolution or decode only a number
>>> of enhancement layers.
>>
>> Didnt we remove lowres couple of month ago for some reason?
>
> It was a global option badly implemented on codec not really supporting it.
>
> Jpeg2k supports it and the result is decent.
>

I see no problem with this. The global lowres option was a maintenance
burden that didn't work well. This adds very little complexity to our
code and (has been claimed to) work well.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Luca Barbato 
On 07/19/2012 10:36 PM, Johan Andersson wrote:
> On Thu, Jul 19, 2012 at 08:59:45PM +0200, Luca Barbato wrote:
>> OpenJPEG can decode in lower resolution or decode only a number
>> of enhancement layers.
> 
> Didnt we remove lowres couple of month ago for some reason?

It was a global option badly implemented on codec not really supporting it.

Jpeg2k supports it and the result is decent.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

Re: [libav-devel] [PATCH] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Mashiat Sarker Shakkhar 

On 7/20/2012 2:36 AM, Johan Andersson wrote:

On Thu, Jul 19, 2012 at 08:59:45PM +0200, Luca Barbato wrote:

OpenJPEG can decode in lower resolution or decode only a number
of enhancement layers.


Didnt we remove lowres couple of month ago for some reason?


This one is a private option. The previous one was afaict global.

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

Re: [libav-devel] [PATCH] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Johan Andersson 
On Thu, Jul 19, 2012 at 08:59:45PM +0200, Luca Barbato wrote:
> OpenJPEG can decode in lower resolution or decode only a number
> of enhancement layers.

Didnt we remove lowres couple of month ago for some reason?

-- 
Johan Andersson
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH 3/3] libopenjpeg: support YUV and deep RGB pixel formats

2012-07-19 Thread Luca Barbato 
From: Michael Bradshaw 

Based on FFmpeg version from
commit 3275981207e30e140cffaea334ac390f1a04266a
---
 libavcodec/libopenjpegdec.c |  290 ---
 1 files changed, 242 insertions(+), 48 deletions(-)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index b540adc..251f107 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -29,6 +29,7 @@
 
 #include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/pixfmt.h"
 #include "libavutil/opt.h"
 #include "avcodec.h"
 #include "thread.h"
@@ -36,6 +37,32 @@
 #define JP2_SIG_TYPE0x6A502020
 #define JP2_SIG_VALUE   0x0D0A870A
 
+// pix_fmts with lower bpp have to be listed before
+// similar pix_fmts with higher bpp.
+#define RGB_PIXEL_FORMATS  PIX_FMT_RGB24, PIX_FMT_RGBA,  \
+   PIX_FMT_RGB48
+
+#define GRAY_PIXEL_FORMATS PIX_FMT_GRAY8, PIX_FMT_Y400A, \
+   PIX_FMT_GRAY16
+
+#define YUV_PIXEL_FORMATS  PIX_FMT_YUV410P,   PIX_FMT_YUV411P,   \
+   PIX_FMT_YUVA420P, \
+   PIX_FMT_YUV420P,   PIX_FMT_YUV422P,   \
+   PIX_FMT_YUV440P,   PIX_FMT_YUV444P,   \
+   PIX_FMT_YUV420P9,  PIX_FMT_YUV422P9,  \
+   PIX_FMT_YUV444P9, \
+   PIX_FMT_YUV420P10, PIX_FMT_YUV422P10, \
+   PIX_FMT_YUV444P10, \
+   PIX_FMT_YUV420P16, PIX_FMT_YUV422P16, \
+   PIX_FMT_YUV444P16
+
+static const enum PixelFormat rgb_pix_fmts[]  = {RGB_PIXEL_FORMATS};
+static const enum PixelFormat gray_pix_fmts[] = {GRAY_PIXEL_FORMATS};
+static const enum PixelFormat yuv_pix_fmts[]  = {YUV_PIXEL_FORMATS};
+static const enum PixelFormat any_pix_fmts[]  = {RGB_PIXEL_FORMATS,
+ GRAY_PIXEL_FORMATS,
+ YUV_PIXEL_FORMATS};
+
 typedef struct {
 AVClass *class;
 opj_dparameters_t dec_params;
@@ -44,14 +71,162 @@ typedef struct {
 int lowqual;
 } LibOpenJPEGContext;
 
-static int check_image_attributes(opj_image_t *image)
+static int libopenjpeg_matches_pix_fmt(const opj_image_t *img,
+   enum PixelFormat pix_fmt)
+{
+AVPixFmtDescriptor des = av_pix_fmt_descriptors[pix_fmt];
+int match = 1;
+
+if (des.nb_components != img->numcomps) {
+return 0;
+}
+
+switch (des.nb_components) {
+case 4:
+match = match &&
+des.comp[3].depth_minus1 + 1 >= img->comps[3].prec &&
+1 == img->comps[3].dx &&
+1 == img->comps[3].dy;
+case 3:
+match = match &&
+des.comp[2].depth_minus1 + 1 >= img->comps[2].prec &&
+1 << des.log2_chroma_w == img->comps[2].dx &&
+1 << des.log2_chroma_h == img->comps[2].dy;
+case 2:
+match = match &&
+des.comp[1].depth_minus1 + 1 >= img->comps[1].prec &&
+1 << des.log2_chroma_w == img->comps[1].dx &&
+1 << des.log2_chroma_h == img->comps[1].dy;
+case 1:
+match = match &&
+des.comp[0].depth_minus1 + 1 >= img->comps[0].prec &&
+1 == img->comps[0].dx &&
+1 == img->comps[0].dy;
+default:
+break;
+}
+
+return match;
+}
+
+static enum PixelFormat libopenjpeg_guess_pix_fmt(const opj_image_t *image)
+{
+int index;
+const enum PixelFormat *possible_fmts = NULL;
+int possible_fmts_nb = 0;
+
+switch (image->color_space) {
+case CLRSPC_SRGB:
+possible_fmts = rgb_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(rgb_pix_fmts);
+break;
+case CLRSPC_GRAY:
+possible_fmts = gray_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(gray_pix_fmts);
+break;
+case CLRSPC_SYCC:
+possible_fmts = yuv_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(yuv_pix_fmts);
+break;
+default:
+possible_fmts = any_pix_fmts;
+possible_fmts_nb = FF_ARRAY_ELEMS(any_pix_fmts);
+break;
+}
+
+for (index = 0; index < possible_fmts_nb; ++index) {
+if (libopenjpeg_matches_pix_fmt(image, possible_fmts[index])) {
+return possible_fmts[index];
+}
+}
+
+return PIX_FMT_NONE;
+}
+
+static inline int libopenjpeg_ispacked(enum PixelFormat pix_fmt)
+{
+int i, component_plane;
+
+if (pix_fmt == PIX_FMT_GRAY16)
+return 0;
+
+component_plane = av_pix_fmt_descriptors[pix_fmt].comp[0].plane;
+for (i = 1; i < av_pix_fmt_descriptors[pix_fmt].nb_components; i++) {
+if (component_plane != av_pix_fmt_descriptors[pix_fmt].comp[i].plane)
+return 0;
+}
+return 1;
+}
+
+static void libopenjpeg_copy_to_packed8(AVFrame *picture, opj_image_t *image)
+{
+uint8_t *img_ptr;
+int index, x, y, c;
+for (y = 0; y < picture->he

[libav-devel] [PATCH 2/3] libopenjpeg: cosmetics

2012-07-19 Thread Luca Barbato 
Reorder headers and usual K&R style update.
---
 libavcodec/libopenjpegdec.c |   85 +--
 1 files changed, 49 insertions(+), 36 deletions(-)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 53215a1..b540adc 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,13 +24,14 @@
 * JPEG 2000 decoder using libopenjpeg
 */
 
-#include "libavutil/opt.h"
+#define  OPJ_STATIC
+#include 
+
+#include "libavutil/intreadwrite.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
 #include "avcodec.h"
-#include "libavutil/intreadwrite.h"
 #include "thread.h"
-#define  OPJ_STATIC
-#include 
 
 #define JP2_SIG_TYPE0x6A502020
 #define JP2_SIG_VALUE   0x0D0A870A
@@ -89,7 +90,7 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 *data_size = 0;
 
 // Check if input is a raw jpeg2k codestream or in jp2 wrapping
-if((AV_RB32(buf) == 12) &&
+if ((AV_RB32(buf) == 12) &&
(AV_RB32(buf + 4) == JP2_SIG_TYPE) &&
(AV_RB32(buf + 8) == JP2_SIG_VALUE)) {
 dec = opj_create_decompress(CODEC_JP2);
@@ -101,7 +102,7 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 dec = opj_create_decompress(CODEC_J2K);
 }
 
-if(!dec) {
+if (!dec) {
 av_log(avctx, AV_LOG_ERROR, "Error initializing decoder.\n");
 return -1;
 }
@@ -113,8 +114,10 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 // Tie decoder with decoding parameters
 opj_setup_decoder(dec, &ctx->dec_params);
 stream = opj_cio_open((opj_common_ptr)dec, buf, buf_size);
-if(!stream) {
-av_log(avctx, AV_LOG_ERROR, "Codestream could not be opened for 
reading.\n");
+
+if (!stream) {
+av_log(avctx, AV_LOG_ERROR,
+   "Codestream could not be opened for reading.\n");
 opj_destroy_decompress(dec);
 return -1;
 }
@@ -122,11 +125,13 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 // Decode the header only
 image = opj_decode_with_info(dec, stream, NULL);
 opj_cio_close(stream);
-if(!image) {
+
+if (!image) {
 av_log(avctx, AV_LOG_ERROR, "Error decoding codestream.\n");
 opj_destroy_decompress(dec);
 return -1;
 }
+
 width  = image->x1 - image->x0;
 height = image->y1 - image->y0;
 
@@ -135,34 +140,41 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 height = (height + (1 << ctx->lowres) - 1) >> ctx->lowres;
 }
 
-if(av_image_check_size(width, height, 0, avctx) < 0) {
-av_log(avctx, AV_LOG_ERROR, "%dx%d dimension invalid.\n", width, 
height);
+if (av_image_check_size(width, height, 0, avctx) < 0) {
+av_log(avctx, AV_LOG_ERROR,
+   "%dx%d dimension invalid.\n", width, height);
 goto done;
 }
+
 avcodec_set_dimensions(avctx, width, height);
 
-switch(image->numcomps)
-{
-case 1:  avctx->pix_fmt = PIX_FMT_GRAY8;
- break;
-case 3:  if(check_image_attributes(image)) {
- avctx->pix_fmt = PIX_FMT_RGB24;
- } else {
- avctx->pix_fmt = PIX_FMT_GRAY8;
- av_log(avctx, AV_LOG_ERROR, "Only first component will be 
used.\n");
- }
- break;
-case 4:  has_alpha = 1;
- avctx->pix_fmt = PIX_FMT_RGBA;
- break;
-default: av_log(avctx, AV_LOG_ERROR, "%d components unsupported.\n", 
image->numcomps);
- goto done;
+switch (image->numcomps) {
+case 1:
+avctx->pix_fmt = PIX_FMT_GRAY8;
+break;
+case 3:
+if (check_image_attributes(image)) {
+avctx->pix_fmt = PIX_FMT_RGB24;
+} else {
+avctx->pix_fmt = PIX_FMT_GRAY8;
+av_log(avctx, AV_LOG_ERROR,
+   "Only first component will be used.\n");
+}
+break;
+case 4:
+has_alpha = 1;
+avctx->pix_fmt = PIX_FMT_RGBA;
+break;
+default:
+av_log(avctx, AV_LOG_ERROR, "%d components unsupported.\n",
+   image->numcomps);
+goto done;
 }
 
-if(picture->data[0])
+if (picture->data[0])
 ff_thread_release_buffer(avctx, picture);
 
-if(ff_thread_get_buffer(avctx, picture) < 0){
+if (ff_thread_get_buffer(avctx, picture) < 0) {
 av_log(avctx, AV_LOG_ERROR, "ff_thread_get_buffer() failed\n");
 return -1;
 }
@@ -173,8 +185,9 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 // Tie decoder with decoding parameters
 opj_setup_decoder(dec, &ctx->dec_params);
 stream = opj_cio_open((opj_common_ptr)dec, buf, buf_size);
-if(!stream) {
-av_log(avctx, AV_LOG_ERROR, "Codestream could not be opened for 
reading.\n");
+if (!stream) {
+av_log(avctx, AV_LOG_ERROR,
+   "Codestream could not be opened for rea

[libav-devel] [PATCH 1/3] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Luca Barbato 
OpenJPEG can decode in lower resolution or decode only a number
of enhancement layers.
---
 libavcodec/libopenjpegdec.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 799ccd7..53215a1 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,6 +24,7 @@
 * JPEG 2000 decoder using libopenjpeg
 */
 
+#include "libavutil/opt.h"
 #include "libavutil/imgutils.h"
 #include "avcodec.h"
 #include "libavutil/intreadwrite.h"
@@ -35,8 +36,11 @@
 #define JP2_SIG_VALUE   0x0D0A870A
 
 typedef struct {
+AVClass *class;
 opj_dparameters_t dec_params;
 AVFrame image;
+int lowres;
+int lowqual;
 } LibOpenJPEGContext;
 
 static int check_image_attributes(opj_image_t *image)
@@ -104,6 +108,8 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 opj_set_event_mgr((opj_common_ptr)dec, NULL, NULL);
 
 ctx->dec_params.cp_limit_decoding = LIMIT_TO_MAIN_HEADER;
+ctx->dec_params.cp_reduce = ctx->lowres;
+ctx->dec_params.cp_layer  = ctx->lowqual;
 // Tie decoder with decoding parameters
 opj_setup_decoder(dec, &ctx->dec_params);
 stream = opj_cio_open((opj_common_ptr)dec, buf, buf_size);
@@ -123,6 +129,12 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 }
 width  = image->x1 - image->x0;
 height = image->y1 - image->y0;
+
+if (ctx->lowres) {
+width  = (width + (1 << ctx->lowres) - 1) >> ctx->lowres;
+height = (height + (1 << ctx->lowres) - 1) >> ctx->lowres;
+}
+
 if(av_image_check_size(width, height, 0, avctx) < 0) {
 av_log(avctx, AV_LOG_ERROR, "%dx%d dimension invalid.\n", width, 
height);
 goto done;
@@ -208,6 +220,21 @@ static av_cold int libopenjpeg_decode_close(AVCodecContext 
*avctx)
 return 0 ;
 }
 
+#define OFFSET(x) offsetof(LibOpenJPEGContext, x)
+#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+
+static const AVOption options[] = {
+{ "lowqual",   "Low quality decoding", OFFSET(lowqual),
AV_OPT_TYPE_INT,   { 0 }, 0, INT_MAX, VD },
+{ "lowres","Low resolution decoding",  OFFSET(lowres), 
AV_OPT_TYPE_INT,   { 0 }, 0, INT_MAX, VD },
+{ NULL },
+};
+
+static const AVClass class = {
+.class_name = "libopenjpeg",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
 
 AVCodec ff_libopenjpeg_decoder = {
 .name = "libopenjpeg",
@@ -219,5 +246,6 @@ AVCodec ff_libopenjpeg_decoder = {
 .decode   = libopenjpeg_decode_frame,
 .capabilities = CODEC_CAP_DR1 | CODEC_CAP_FRAME_THREADS,
 .long_name= NULL_IF_CONFIG_SMALL("OpenJPEG based JPEG 2000 
decoder"),
+.priv_class   = &class,
 .init_thread_copy = 
ONLY_IF_THREADS_ENABLED(libopenjpeg_decode_init_thread_copy),
 };
-- 
1.7.8.rc1

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

[libav-devel] [PATCH] libopenjpeg: introduce lowres and lowqual private options

2012-07-19 Thread Luca Barbato 
OpenJPEG can decode in lower resolution or decode only a number
of enhancement layers.
---
 libavcodec/libopenjpegdec.c |   28 
 1 files changed, 28 insertions(+), 0 deletions(-)

diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index 799ccd7..53215a1 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -24,6 +24,7 @@
 * JPEG 2000 decoder using libopenjpeg
 */
 
+#include "libavutil/opt.h"
 #include "libavutil/imgutils.h"
 #include "avcodec.h"
 #include "libavutil/intreadwrite.h"
@@ -35,8 +36,11 @@
 #define JP2_SIG_VALUE   0x0D0A870A
 
 typedef struct {
+AVClass *class;
 opj_dparameters_t dec_params;
 AVFrame image;
+int lowres;
+int lowqual;
 } LibOpenJPEGContext;
 
 static int check_image_attributes(opj_image_t *image)
@@ -104,6 +108,8 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 opj_set_event_mgr((opj_common_ptr)dec, NULL, NULL);
 
 ctx->dec_params.cp_limit_decoding = LIMIT_TO_MAIN_HEADER;
+ctx->dec_params.cp_reduce = ctx->lowres;
+ctx->dec_params.cp_layer  = ctx->lowqual;
 // Tie decoder with decoding parameters
 opj_setup_decoder(dec, &ctx->dec_params);
 stream = opj_cio_open((opj_common_ptr)dec, buf, buf_size);
@@ -123,6 +129,12 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 }
 width  = image->x1 - image->x0;
 height = image->y1 - image->y0;
+
+if (ctx->lowres) {
+width  = (width + (1 << ctx->lowres) - 1) >> ctx->lowres;
+height = (height + (1 << ctx->lowres) - 1) >> ctx->lowres;
+}
+
 if(av_image_check_size(width, height, 0, avctx) < 0) {
 av_log(avctx, AV_LOG_ERROR, "%dx%d dimension invalid.\n", width, 
height);
 goto done;
@@ -208,6 +220,21 @@ static av_cold int libopenjpeg_decode_close(AVCodecContext 
*avctx)
 return 0 ;
 }
 
+#define OFFSET(x) offsetof(LibOpenJPEGContext, x)
+#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
+
+static const AVOption options[] = {
+{ "lowqual",   "Low quality decoding", OFFSET(lowqual),
AV_OPT_TYPE_INT,   { 0 }, 0, INT_MAX, VD },
+{ "lowres","Low resolution decoding",  OFFSET(lowres), 
AV_OPT_TYPE_INT,   { 0 }, 0, INT_MAX, VD },
+{ NULL },
+};
+
+static const AVClass class = {
+.class_name = "libopenjpeg",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
 
 AVCodec ff_libopenjpeg_decoder = {
 .name = "libopenjpeg",
@@ -219,5 +246,6 @@ AVCodec ff_libopenjpeg_decoder = {
 .decode   = libopenjpeg_decode_frame,
 .capabilities = CODEC_CAP_DR1 | CODEC_CAP_FRAME_THREADS,
 .long_name= NULL_IF_CONFIG_SMALL("OpenJPEG based JPEG 2000 
decoder"),
+.priv_class   = &class,
 .init_thread_copy = 
ONLY_IF_THREADS_ENABLED(libopenjpeg_decode_init_thread_copy),
 };
-- 
1.7.8.rc1

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

Re: [libav-devel] [PATCH] configure: set icc_version where it is needed

2012-07-19 Thread Måns Rullgård 
Diego Biurrun  writes:

> On Thu, Jul 19, 2012 at 11:43:32AM +0100, Mans Rullgard wrote:
>> This variable is only used once, so setting it there is clearer.
>> 
>> --- a/configure
>> +++ b/configure
>> @@ -1975,7 +1975,6 @@ elif $cc -v 2>&1 | grep -qi ^gcc; then
>>  elif $cc --version 2>/dev/null | grep -q Intel; then
>>  cc_type=icc
>>  cc_ident=$($cc --version | head -n1)
>> -icc_version=$($cc -dumpversion)
>>  CC_DEPFLAGS='-MMD'
>>  AS_DEPFLAGS='-MMD'
>> @@ -3149,6 +3148,7 @@ if enabled icc; then
>>  # icc 11.0 and 11.1 work with ebp_available, but don't pass the test
>>  enable ebp_available
>>  if enabled x86_32; then
>> +icc_version=$($cc -dumpversion)
>>  test ${icc_version%%.*} -ge 11 &&
>>  check_cflags -falign-stack=maintain-16-byte ||
>
> Well, it also makes sense to set this in the compiler section, but
> if you prefer it this way, I don't mind...

I have my reasons for this which will become clear in due course.

-- 
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] configure: set icc_version where it is needed

2012-07-19 Thread Diego Biurrun 
On Thu, Jul 19, 2012 at 11:43:32AM +0100, Mans Rullgard wrote:
> This variable is only used once, so setting it there is clearer.
> 
> --- a/configure
> +++ b/configure
> @@ -1975,7 +1975,6 @@ elif $cc -v 2>&1 | grep -qi ^gcc; then
>  elif $cc --version 2>/dev/null | grep -q Intel; then
>  cc_type=icc
>  cc_ident=$($cc --version | head -n1)
> -icc_version=$($cc -dumpversion)
>  CC_DEPFLAGS='-MMD'
>  AS_DEPFLAGS='-MMD'
> @@ -3149,6 +3148,7 @@ if enabled icc; then
>  # icc 11.0 and 11.1 work with ebp_available, but don't pass the test
>  enable ebp_available
>  if enabled x86_32; then
> +icc_version=$($cc -dumpversion)
>  test ${icc_version%%.*} -ge 11 &&
>  check_cflags -falign-stack=maintain-16-byte ||

Well, it also makes sense to set this in the compiler section, but
if you prefer it this way, I don't mind...

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] alac: reverse lpc coeff order, simplify filter

2012-07-19 Thread Justin Ruggles 
Reversing the lpc coefficient order simplifies indexing in the filter.
---
 libavcodec/alac.c |   25 -
 1 files changed, 12 insertions(+), 13 deletions(-)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 310a1f0..bb2e836 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -194,6 +194,7 @@ static void lpc_prediction(int32_t *error_buffer, int32_t 
*buffer_out,
int lpc_order, int lpc_quant)
 {
 int i;
+int32_t *pred = buffer_out;
 
 /* first sample always copies */
 *buffer_out = *error_buffer;
@@ -217,37 +218,35 @@ static void lpc_prediction(int32_t *error_buffer, int32_t 
*buffer_out,
 }
 
 /* read warm-up samples */
-for (i = 0; i < lpc_order; i++) {
-buffer_out[i + 1] = sign_extend(buffer_out[i] + error_buffer[i + 1],
-bps);
-}
+for (i = 1; i <= lpc_order; i++)
+buffer_out[i] = sign_extend(buffer_out[i - 1] + error_buffer[i], bps);
 
 /* NOTE: 4 and 8 are very common cases that could be optimized. */
 
-for (i = lpc_order; i < nb_samples - 1; i++) {
+for (; i < nb_samples; i++) {
 int j;
 int val = 0;
-int error_val = error_buffer[i + 1];
+int error_val = error_buffer[i];
 int error_sign;
-int d = buffer_out[i - lpc_order];
+int d = *pred++;
 
 /* LPC prediction */
 for (j = 0; j < lpc_order; j++)
-val += (buffer_out[i - j] - d) * lpc_coefs[j];
+val += (pred[j] - d) * lpc_coefs[j];
 val = (val + (1 << (lpc_quant - 1))) >> lpc_quant;
 val += d + error_val;
-buffer_out[i + 1] = sign_extend(val, bps);
+buffer_out[i] = sign_extend(val, bps);
 
 /* adapt LPC coefficients */
 error_sign = sign_only(error_val);
 if (error_sign) {
-for (j = lpc_order - 1; j >= 0 && error_val * error_sign > 0; j--) 
{
+for (j = 0; j < lpc_order && error_val * error_sign > 0; j++) {
 int sign;
-val  = d - buffer_out[i - j];
+val  = d - pred[j];
 sign = sign_only(val) * error_sign;
 lpc_coefs[j] -= sign;
 val *= sign;
-error_val -= (val >> lpc_quant) * (lpc_order - j);
+error_val -= (val >> lpc_quant) * (j + 1);
 }
 }
 }
@@ -350,7 +349,7 @@ static int decode_element(AVCodecContext *avctx, void 
*data, int ch_index,
 lpc_order[ch] = get_bits(&alac->gb, 5);
 
 /* read the predictor table */
-for (i = 0; i < lpc_order[ch]; i++)
+for (i = lpc_order[ch] - 1; i >= 0; i--)
 lpc_coefs[ch][i] = get_sbits(&alac->gb, 16);
 }
 
-- 
1.7.1

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

Re: [libav-devel] [PATCH 34/39] alac: split element parsing into a separate function

2012-07-19 Thread Alex Converse 
On Mon, Jul 9, 2012 at 2:24 PM, Justin Ruggles  wrote:
> This will make multi-channel implementation simpler.
> Based partially on a patch by Andrew D'Addesio .
> ---
>  libavcodec/alac.c |  121 +++-
>  1 files changed, 81 insertions(+), 40 deletions(-)
>

Looks ok
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 35/39] alac: multi-channel decoding support

2012-07-19 Thread Alex Converse 
On Thu, Jul 19, 2012 at 8:22 AM, Justin Ruggles
 wrote:
>
> On 07/09/2012 05:24 PM, Justin Ruggles wrote:
> > From: Andrew D'Addesio 
> >
> > Signed-off-by: Justin Ruggles 
> > ---
> >  libavcodec/alac.c |   61
> > +---
> >  1 files changed, 43 insertions(+), 18 deletions(-)
>
> ping.
>

Looks good
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] configure: mark libfdk-aac as nonfree

2012-07-19 Thread Kieran Kunhya 
On Thu, Jul 19, 2012 at 1:12 PM, Måns Rullgård  wrote:
> Luca Barbato  writes:
>
>> On 07/19/2012 10:19 AM, Jean-Baptiste Kempf wrote:
>>> On Wed, Jul 18, 2012 at 03:38:38PM +0200, Diego Biurrun wrote :
 The SFLC lawyer said the libfdk-aac license looked (l)gpl-incompatible
 to him.
>>>
>>> Well, I am sad, but not surprised.
>>>
>>
>> I'd like to have a better understanding
>>
>> fdk:
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted without
>> payment of copyright license fees provided that you satisfy the
>> following conditions:
>>
>> (A)
>> You must retain the complete text of this software license in
>> redistributions of the FDK AAC Codec or
>> your modifications thereto in source code form.
>
> This is normal and similar to BSD clause 1.
>
>> (B)
>> You must retain the complete text of this software license in the
>> documentation and/or other materials
>> provided with redistributions of the FDK AAC Codec or your modifications
>> thereto in binary form.
>
> This is similar to BSD clause 2.
>
>> You must make available free of charge copies of the complete source
>> code of the FDK AAC Codec and your modifications thereto to recipients
>> of copies in binary form.
>
> This could be seen to be an additional restriction compared to (L)GPL 1:
>
>   You may charge a fee for the physical act of transferring a copy, [...].
>
> It could also be argued that the "free of charge" requirement applies
> only to the source code as such and not to the transfer thereof.
>
>> (C)
>> The name of Fraunhofer may not be used to endorse or promote products
>> derived from this library without
>> prior written permission.
>
> This is the BSD non-endorsement clause with a few words removed.
>
>> (D)
>> You may not charge copyright license fees for anyone to use, copy or
>> distribute the FDK AAC Codec
>> software or your modifications thereto.
>
> This is LGPL 2c in part.  LGPL adds "under the terms of this License."
>
>> (E)
>> Your modified versions of the FDK AAC Codec must carry prominent notices
>> stating that you changed the software
>> and the date of any change.
>
> This is LGPL 2b.
>
>> For modified versions of the FDK AAC Codec, the term "Fraunhofer FDK
>> AAC Codec Library for Android" must be replaced by the term
>> "Third-Party Modified Version of the Fraunhofer FDK AAC Codec Library
>> for Android."
>
> This restriction is probably not compatible with (L)GPL.  Naming
> restrictions are cited as rendering the Apache-1.1 and PHP licences
> GPL-incompatible.
>
>> Currently the mismatch is (E) more than (D) in my eyes.
>>
>> D is a match for lgpl-2.1 2. c
>>
>> c) You must cause the whole of the work to be licensed at no
>> charge to all third parties under the terms of this License.
>
> Agreed.
>
>> The second part of E is a stronger version of the non-endorsement clause
>> from bsd (that is compatible) so I'm not sure it could be considered an
>> additional restriction.
>
> I'm afraid the FSF is stricter in its interpretation than you are.
>
>> Could we have a specific detail on which section clashes?
>
> +1

"You may use this FDK AAC Codec software or modifications thereto only
for purposes that are authorized
by appropriate patent licenses."

I think this part is GPL incompatible because it is an additional
restriction (or is it not considered part of the licence?).
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 37/39] alac: change some data types to plain int

2012-07-19 Thread Kostya Shishkov 
On Thu, Jul 19, 2012 at 11:22:44AM -0400, Justin Ruggles wrote:
> On 07/09/2012 05:24 PM, Justin Ruggles wrote:
> > ---
> >  libavcodec/alac.c |   10 +-
> >  1 files changed, 5 insertions(+), 5 deletions(-)
> > 
> > diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> > index db5633c..cf95959 100644
> > --- a/libavcodec/alac.c
> > +++ b/libavcodec/alac.c
> > @@ -262,8 +262,8 @@ static void lpc_prediction(int32_t *error_buffer, 
> > int32_t *buffer_out,
> >  }
> >  
> >  static void decorrelate_stereo(int32_t *buffer[2],
> > -   int nb_samples, uint8_t decorr_shift,
> > -   uint8_t decorr_left_weight)
> > +   int nb_samples, int decorr_shift,
> > +   int decorr_left_weight)
> >  {
> >  int i;
> >  
> > @@ -297,10 +297,10 @@ static int decode_element(AVCodecContext *avctx, void 
> > *data, int ch_index,
> >  {
> >  ALACContext *alac = avctx->priv_data;
> >  int has_size;
> > -unsigned int bps;
> > +int bps;
> >  int is_compressed;
> > -uint8_t decorr_shift;
> > -uint8_t decorr_left_weight;
> > +int decorr_shift;
> > +int decorr_left_weight;
> >  uint32_t output_samples;
> >  int i, ch, ret;
> >  
> 
> ping

LGTM
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] VideoLAN Dev Days 2012 registration

2012-07-19 Thread Jean-Baptiste Kempf 
Hello libav geeks,


We would like to invite you to join us at the VideoLAN Dev Days 2012.

This technical conference about open source multimedia, will see
developers from VLC, libav, FFmpeg, x264, Phonon, DVBlast, PulseAudio,
KDE, Gnome, Xiph and other projects gather to discuss about open source
development for multimedia projects.


It will be held in Paris, France, on September 1st (saturday) and
2nd (sunday) 2012.

The schedule includes technical talks and presentation, meetings
and dev/BoF rooms to discuss about multimedia.

The FOMS conference will take place, at the same location, on monday 3rd
and 4th.


We really need talks and sponsors.


More information can be found on:
http://www.videolan.org/videolan/events/vdd12/

Attendance is free, but registration is mandatory, for security
reasons. 

Registration can be done here: http://goo.gl/QRMsb


As usual, we will give sponsorship to active open source developers that
want or need it. Sponsorship should cover travel and hotel costs.


Hoping to see many of you,

-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 37/39] alac: change some data types to plain int

2012-07-19 Thread Justin Ruggles 
On 07/09/2012 05:24 PM, Justin Ruggles wrote:
> ---
>  libavcodec/alac.c |   10 +-
>  1 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> index db5633c..cf95959 100644
> --- a/libavcodec/alac.c
> +++ b/libavcodec/alac.c
> @@ -262,8 +262,8 @@ static void lpc_prediction(int32_t *error_buffer, int32_t 
> *buffer_out,
>  }
>  
>  static void decorrelate_stereo(int32_t *buffer[2],
> -   int nb_samples, uint8_t decorr_shift,
> -   uint8_t decorr_left_weight)
> +   int nb_samples, int decorr_shift,
> +   int decorr_left_weight)
>  {
>  int i;
>  
> @@ -297,10 +297,10 @@ static int decode_element(AVCodecContext *avctx, void 
> *data, int ch_index,
>  {
>  ALACContext *alac = avctx->priv_data;
>  int has_size;
> -unsigned int bps;
> +int bps;
>  int is_compressed;
> -uint8_t decorr_shift;
> -uint8_t decorr_left_weight;
> +int decorr_shift;
> +int decorr_left_weight;
>  uint32_t output_samples;
>  int i, ch, ret;
>  

ping

-Justin
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 35/39] alac: multi-channel decoding support

2012-07-19 Thread Justin Ruggles 
On 07/09/2012 05:24 PM, Justin Ruggles wrote:
> From: Andrew D'Addesio 
> 
> Signed-off-by: Justin Ruggles 
> ---
>  libavcodec/alac.c |   61 +---
>  1 files changed, 43 insertions(+), 18 deletions(-)

ping.

-Justin

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

Re: [libav-devel] [PATCH 34/39] alac: split element parsing into a separate function

2012-07-19 Thread Justin Ruggles 
On 07/09/2012 05:24 PM, Justin Ruggles wrote:
> This will make multi-channel implementation simpler.
> Based partially on a patch by Andrew D'Addesio .
> ---
>  libavcodec/alac.c |  121 +++-
>  1 files changed, 81 insertions(+), 40 deletions(-)

ping

-Justin

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

Re: [libav-devel] [PATCH] configure: Remove useless dependencies for RTMPT and RTMPTS

2012-07-19 Thread Måns Rullgård 
Samuel Pitoiset  writes:

> On Thu, Jul 19, 2012 at 2:17 PM, Måns Rullgård  wrote:
>> Samuel Pitoiset  writes:
>>
>>> ---
>>>  configure | 2 --
>>>  1 file changed, 2 deletions(-)
>>>
>>> diff --git a/configure b/configure
>>> index 6760c0e..fadc101 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -1548,9 +1548,7 @@ rtmp_protocol_deps="!librtmp_protocol"
>>>  rtmp_protocol_select="tcp_protocol"
>>>  rtmps_protocol_deps="!librtmp_protocol"
>>>  rtmps_protocol_select="tls_protocol"
>>> -rtmpt_protocol_deps="!librtmp_protocol"
>>>  rtmpt_protocol_select="ffrtmphttp_protocol"
>>> -rtmpts_protocol_deps="!librtmp_protocol"
>>>  rtmpts_protocol_select="ffrtmphttp_protocol"
>>>  rtp_protocol_select="udp_protocol"
>>>  sctp_protocol_deps="network netinet_sctp_h"
>>> --
>>
>> Why are these now "useless"?  They were added for a reason.
>
> It's useless because these two protocols uses ffrtmphttp_protocol
> which already have this dependency defined.

Thanks, that's the kind of explanation I was looking for.  Next time,
please include such things in the commit message.

Patch OK.

-- 
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] configure: Remove useless dependencies for RTMPT and RTMPTS

2012-07-19 Thread Samuel Pitoiset 
On Thu, Jul 19, 2012 at 2:17 PM, Måns Rullgård  wrote:
> Samuel Pitoiset  writes:
>
>> ---
>>  configure | 2 --
>>  1 file changed, 2 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 6760c0e..fadc101 100755
>> --- a/configure
>> +++ b/configure
>> @@ -1548,9 +1548,7 @@ rtmp_protocol_deps="!librtmp_protocol"
>>  rtmp_protocol_select="tcp_protocol"
>>  rtmps_protocol_deps="!librtmp_protocol"
>>  rtmps_protocol_select="tls_protocol"
>> -rtmpt_protocol_deps="!librtmp_protocol"
>>  rtmpt_protocol_select="ffrtmphttp_protocol"
>> -rtmpts_protocol_deps="!librtmp_protocol"
>>  rtmpts_protocol_select="ffrtmphttp_protocol"
>>  rtp_protocol_select="udp_protocol"
>>  sctp_protocol_deps="network netinet_sctp_h"
>> --
>
> Why are these now "useless"?  They were added for a reason.

It's useless because these two protocols uses ffrtmphttp_protocol
which already have this dependency defined.
I removed these two lines in order to be consistent related to the RTMPE patch.

-- 
Best regards,
Samuel Pitoiset.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] configure: Remove useless dependencies for RTMPT and RTMPTS

2012-07-19 Thread Måns Rullgård 
Samuel Pitoiset  writes:

> ---
>  configure | 2 --
>  1 file changed, 2 deletions(-)
>
> diff --git a/configure b/configure
> index 6760c0e..fadc101 100755
> --- a/configure
> +++ b/configure
> @@ -1548,9 +1548,7 @@ rtmp_protocol_deps="!librtmp_protocol"
>  rtmp_protocol_select="tcp_protocol"
>  rtmps_protocol_deps="!librtmp_protocol"
>  rtmps_protocol_select="tls_protocol"
> -rtmpt_protocol_deps="!librtmp_protocol"
>  rtmpt_protocol_select="ffrtmphttp_protocol"
> -rtmpts_protocol_deps="!librtmp_protocol"
>  rtmpts_protocol_select="ffrtmphttp_protocol"
>  rtp_protocol_select="udp_protocol"
>  sctp_protocol_deps="network netinet_sctp_h"
> -- 

Why are these now "useless"?  They were added for a reason.

-- 
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] configure: Remove useless dependencies for RTMPT and RTMPTS

2012-07-19 Thread Samuel Pitoiset 
---
 configure | 2 --
 1 file changed, 2 deletions(-)

diff --git a/configure b/configure
index 6760c0e..fadc101 100755
--- a/configure
+++ b/configure
@@ -1548,9 +1548,7 @@ rtmp_protocol_deps="!librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
 rtmps_protocol_deps="!librtmp_protocol"
 rtmps_protocol_select="tls_protocol"
-rtmpt_protocol_deps="!librtmp_protocol"
 rtmpt_protocol_select="ffrtmphttp_protocol"
-rtmpts_protocol_deps="!librtmp_protocol"
 rtmpts_protocol_select="ffrtmphttp_protocol"
 rtp_protocol_select="udp_protocol"
 sctp_protocol_deps="network netinet_sctp_h"
-- 
1.7.11.1

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

Re: [libav-devel] [PATCH 1/2] libopenjpeg: support YUV and deep RGB pixel formats

2012-07-19 Thread Luca Barbato 
On 07/19/2012 03:41 AM, Luca Barbato wrote:
> From: Michael Bradshaw 

>  static av_cold int libopenjpeg_decode_init(AVCodecContext *avctx)
> @@ -54,6 +225,7 @@ static av_cold int libopenjpeg_decode_init(AVCodecContext 
> *avctx)
>  LibOpenJPEGContext *ctx = avctx->priv_data;
>  
>  opj_set_default_decoder_parameters(&ctx->dec_params);
> +avcodec_get_frame_defaults(&ctx->image);
>  avctx->coded_frame = &ctx->image;
>  return 0;
>  }
> @@ -77,10 +249,10 @@ static int libopenjpeg_decode_frame(AVCodecContext 
> *avctx,
>  

This function is huge and is pretty much resetting the decoder all the
time, I wonder if we couldn't keep some of it out the way or reset it
only when dimensions or pixel format change.

I might try later. dropping the overinlining might be good though.

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

[libav-devel] [PATCH 3/3] RTMPE protocol support

2012-07-19 Thread Samuel Pitoiset 
This adds two protocols, but one of them is an internal implementation
detail just used as an abstraction layer/generalization in the code. The
RTMPE protocol implementation uses ffrtmpcrypt:// as an alternative to the
tcp:// protocol. This allows moving most of the lower level logic out
from the higher level generic rtmp code.
---
 configure|  11 ++
 doc/general.texi |   2 +-
 doc/protocols.texi   |   9 ++
 libavformat/Makefile |   2 +
 libavformat/allformats.c |   2 +
 libavformat/rtmpcrypt.c  | 309 
 libavformat/rtmpcrypt.h  |  69 ++
 libavformat/rtmpdh.c | 329 +++
 libavformat/rtmpdh.h | 102 +++
 libavformat/rtmpproto.c  | 106 ++-
 libavformat/version.h|   2 +-
 11 files changed, 934 insertions(+), 9 deletions(-)
 create mode 100644 libavformat/rtmpcrypt.c
 create mode 100644 libavformat/rtmpcrypt.h
 create mode 100644 libavformat/rtmpdh.c
 create mode 100644 libavformat/rtmpdh.h

diff --git a/configure b/configure
index 6760c0e..96c9622 100755
--- a/configure
+++ b/configure
@@ -936,6 +936,7 @@ CONFIG_LIST="
 fastdiv
 fft
 frei0r
+gcrypt
 gnutls
 gpl
 gray
@@ -968,6 +969,7 @@ CONFIG_LIST="
 mdct
 memalign_hack
 mpegaudiodsp
+nettle
 network
 nonfree
 openssl
@@ -1529,6 +1531,9 @@ vfwcap_indev_extralibs="-lavicap32"
 x11_grab_device_indev_deps="x11grab XShmCreateImage"
 
 # protocols
+ffrtmpcrypt_protocol_deps="!librtmp_protocol"
+ffrtmpcrypt_protocol_deps_any="gcrypt nettle openssl"
+ffrtmpcrypt_protocol_select="tcp_protocol"
 ffrtmphttp_protocol_deps="!librtmp_protocol"
 ffrtmphttp_protocol_select="http_protocol"
 gopher_protocol_deps="network"
@@ -1546,6 +1551,7 @@ mmsh_protocol_select="http_protocol"
 mmst_protocol_deps="network"
 rtmp_protocol_deps="!librtmp_protocol"
 rtmp_protocol_select="tcp_protocol"
+rtmpe_protocol_select="ffrtmpcrypt_protocol"
 rtmps_protocol_deps="!librtmp_protocol"
 rtmps_protocol_select="tls_protocol"
 rtmpt_protocol_deps="!librtmp_protocol"
@@ -2998,6 +3004,11 @@ enabled openssl&& { check_lib openssl/ssl.h 
SSL_library_init -lssl -lcrypto
 check_lib openssl/ssl.h SSL_library_init -lssl 
-lcrypto -lws2_32 -lgdi32 ||
 die "ERROR: openssl not found"; }
 
+if enabled gnutls; then
+{ check_lib nettle/bignum.h nettle_mpz_get_str_256 -lnettle -lhogweed 
-lgmp && enable nettle; } ||
+{ check_lib gcrypt.h gcry_mpi_new -lgcrypt && enable gcrypt; }
+fi
+
 # libdc1394 check
 if enabled libdc1394; then
 { check_lib dc1394/dc1394.h dc1394_new -ldc1394 -lraw1394 &&
diff --git a/doc/general.texi b/doc/general.texi
index 38916de..d6aacb1 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -843,7 +843,7 @@ performance on systems without hardware floating point 
support).
 @item MMST @tab X
 @item pipe @tab X
 @item RTMP @tab X
-@item RTMPE@tab E
+@item RTMPE@tab X
 @item RTMPS@tab X
 @item RTMPT@tab X
 @item RTMPTE   @tab E
diff --git a/doc/protocols.texi b/doc/protocols.texi
index aad7184..fcb4da8 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -247,6 +247,15 @@ For example to read with @command{avplay} a multimedia 
resource named
 avplay rtmp://myserver/vod/sample
 @end example
 
+@section rtmpe
+
+Encrypted Real-Time Messaging Protocol.
+
+The Encrypted Real-Time Messaging Protocol (RTMPE) is used for
+streaming multimedia content within standard cryptographic primitives,
+consisting of Diffie-Hellman key exchange and HMACSHA256, generating
+a pair of RC4 keys.
+
 @section rtmps
 
 Real-Time Messaging Protocol over a secure SSL connection.
diff --git a/libavformat/Makefile b/libavformat/Makefile
index af3ebac..e9d7b3c 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -340,6 +340,7 @@ OBJS-$(CONFIG_LIBRTMP)   += librtmp.o
 OBJS-$(CONFIG_APPLEHTTP_PROTOCOL)+= hlsproto.o
 OBJS-$(CONFIG_CONCAT_PROTOCOL)   += concat.o
 OBJS-$(CONFIG_CRYPTO_PROTOCOL)   += crypto.o
+OBJS-$(CONFIG_FFRTMPCRYPT_PROTOCOL)  += rtmpcrypt.o rtmpdh.o
 OBJS-$(CONFIG_FFRTMPHTTP_PROTOCOL)   += rtmphttp.o
 OBJS-$(CONFIG_FILE_PROTOCOL) += file.o
 OBJS-$(CONFIG_GOPHER_PROTOCOL)   += gopher.o
@@ -352,6 +353,7 @@ OBJS-$(CONFIG_MMST_PROTOCOL) += mmst.o mms.o 
asf.o
 OBJS-$(CONFIG_MD5_PROTOCOL)  += md5proto.o
 OBJS-$(CONFIG_PIPE_PROTOCOL) += file.o
 OBJS-$(CONFIG_RTMP_PROTOCOL) += rtmpproto.o rtmppkt.o
+OBJS-$(CONFIG_RTMPE_PROTOCOL)+= rtmpproto.o rtmppkt.o
 OBJS-$(CONFIG_RTMPS_PROTOCOL)+= rtmpproto.o rtmppkt.o
 OBJS-$(CONFIG_RTMPT_PROTOCOL)+= rtmpproto.o rtmppkt.o
 OBJS-$(CONFIG_RTMPTS_PROTOCOL)   += rtmpproto.o rtmppkt.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 46b3bc7..1

Re: [libav-devel] [PATCH 2/2] configure: mark libfdk-aac as nonfree

2012-07-19 Thread Måns Rullgård 
Luca Barbato  writes:

> On 07/19/2012 10:19 AM, Jean-Baptiste Kempf wrote:
>> On Wed, Jul 18, 2012 at 03:38:38PM +0200, Diego Biurrun wrote :
>>> The SFLC lawyer said the libfdk-aac license looked (l)gpl-incompatible
>>> to him.
>> 
>> Well, I am sad, but not surprised.
>> 
>
> I'd like to have a better understanding
>
> fdk:
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted without
> payment of copyright license fees provided that you satisfy the
> following conditions:
>
> (A)
> You must retain the complete text of this software license in
> redistributions of the FDK AAC Codec or
> your modifications thereto in source code form.

This is normal and similar to BSD clause 1.

> (B)
> You must retain the complete text of this software license in the
> documentation and/or other materials
> provided with redistributions of the FDK AAC Codec or your modifications
> thereto in binary form.

This is similar to BSD clause 2.

> You must make available free of charge copies of the complete source
> code of the FDK AAC Codec and your modifications thereto to recipients
> of copies in binary form.

This could be seen to be an additional restriction compared to (L)GPL 1:

  You may charge a fee for the physical act of transferring a copy, [...].

It could also be argued that the "free of charge" requirement applies
only to the source code as such and not to the transfer thereof.

> (C)
> The name of Fraunhofer may not be used to endorse or promote products
> derived from this library without
> prior written permission.

This is the BSD non-endorsement clause with a few words removed.

> (D)
> You may not charge copyright license fees for anyone to use, copy or
> distribute the FDK AAC Codec
> software or your modifications thereto.

This is LGPL 2c in part.  LGPL adds "under the terms of this License."

> (E)
> Your modified versions of the FDK AAC Codec must carry prominent notices
> stating that you changed the software
> and the date of any change.

This is LGPL 2b.

> For modified versions of the FDK AAC Codec, the term "Fraunhofer FDK
> AAC Codec Library for Android" must be replaced by the term
> "Third-Party Modified Version of the Fraunhofer FDK AAC Codec Library
> for Android."

This restriction is probably not compatible with (L)GPL.  Naming
restrictions are cited as rendering the Apache-1.1 and PHP licences
GPL-incompatible.

> Currently the mismatch is (E) more than (D) in my eyes.
>
> D is a match for lgpl-2.1 2. c
>
> c) You must cause the whole of the work to be licensed at no
> charge to all third parties under the terms of this License.

Agreed.

> The second part of E is a stronger version of the non-endorsement clause
> from bsd (that is compatible) so I'm not sure it could be considered an
> additional restriction.

I'm afraid the FSF is stricter in its interpretation than you are.

> Could we have a specific detail on which section clashes?

+1

-- 
Måns Rullgård
m...@mansr.com
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] libopenjpeg: support YUV and deep RGB pixel formats

2012-07-19 Thread Luca Barbato 
On 07/19/2012 10:15 AM, Anton Khirnov wrote:
> 
> On Thu, 19 Jul 2012 03:41:11 +0200, Luca Barbato  wrote:
>> From: Michael Bradshaw 
>>
>> Based on FFmpeg version from
>> commit 3275981207e30e140cffaea334ac390f1a04266a
>> ---
>>  libavcodec/libopenjpegdec.c |  305 
>> +++
>>  1 files changed, 250 insertions(+), 55 deletions(-)
>>
>> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
>> index 799ccd7..1c08f8a 100644
>> --- a/libavcodec/libopenjpegdec.c
>> +++ b/libavcodec/libopenjpegdec.c
>> @@ -24,29 +24,200 @@
>>  * JPEG 2000 decoder using libopenjpeg
>>  */
>>  
>> +#define  OPJ_STATIC
>> +#include 
>> +
>> +#include "libavutil/intreadwrite.h"
>>  #include "libavutil/imgutils.h"
>> +#include "libavutil/pixfmt.h"
>> +#include "libavutil/opt.h"
>>  #include "avcodec.h"
>> -#include "libavutil/intreadwrite.h"
>>  #include "thread.h"
>> -#define  OPJ_STATIC
>> -#include 
>>  
>>  #define JP2_SIG_TYPE0x6A502020
>>  #define JP2_SIG_VALUE   0x0D0A870A
>>  
>> +// pix_fmts with lower bpp have to be listed before
>> +// similar pix_fmts with higher bpp.
>> +#define RGB_PIXEL_FORMATS  PIX_FMT_RGB24, PIX_FMT_RGBA,  \
>> +   PIX_FMT_RGB48
>> +
>> +#define GRAY_PIXEL_FORMATS PIX_FMT_GRAY8, PIX_FMT_Y400A, \
>> +   PIX_FMT_GRAY16
>> +
>> +#define YUV_PIXEL_FORMATS  PIX_FMT_YUV410P,   PIX_FMT_YUV411P,   \
>> +   PIX_FMT_YUVA420P, \
>> +   PIX_FMT_YUV420P,   PIX_FMT_YUV422P,   \
>> +   PIX_FMT_YUV440P,   PIX_FMT_YUV444P,   \
>> +   PIX_FMT_YUV420P9,  PIX_FMT_YUV422P9,  \
>> +   PIX_FMT_YUV444P9, \
>> +   PIX_FMT_YUV420P10, PIX_FMT_YUV422P10, \
>> +   PIX_FMT_YUV444P10, \
>> +   PIX_FMT_YUV420P16, PIX_FMT_YUV422P16, \
>> +   PIX_FMT_YUV444P16
>> +
>> +static const enum PixelFormat rgb_pix_fmts[]  = {RGB_PIXEL_FORMATS};
>> +static const enum PixelFormat gray_pix_fmts[] = {GRAY_PIXEL_FORMATS};
>> +static const enum PixelFormat yuv_pix_fmts[]  = {YUV_PIXEL_FORMATS};
>> +static const enum PixelFormat any_pix_fmts[]  = {RGB_PIXEL_FORMATS,
>> + GRAY_PIXEL_FORMATS,
>> + YUV_PIXEL_FORMATS};
>> +
>>  typedef struct {
>>  opj_dparameters_t dec_params;
>>  AVFrame image;
>>  } LibOpenJPEGContext;
>>  
>> -static int check_image_attributes(opj_image_t *image)
>> +static inline int libopenjpeg_matches_pix_fmt(const opj_image_t *image,
>> +  enum PixelFormat pix_fmt)
> 
> What's with all the inlines? Does inlining them give any practical benefit?
> 

I doubt so, that decode function is huge and it is suppose to just pass
data to and get data back from openjpeg.

lu


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

Re: [libav-devel] [PATCH 3/3] RTMPE protocol support

2012-07-19 Thread Samuel Pitoiset 
On Wed, Jul 18, 2012 at 3:45 PM, Diego Biurrun  wrote:
> On Tue, Jul 17, 2012 at 07:10:44PM +0300, Martin Storsjö wrote:
>> On Mon, 16 Jul 2012, Samuel Pitoiset wrote:
>> >--- a/configure
>> >+++ b/configure
>> >@@ -1526,6 +1528,9 @@ vfwcap_indev_extralibs="-lavicap32"
>> >
>> ># protocols
>> >+ffrtmpenc_protocol_deps="!librtmp_protocol"
>> >+ffrtmpenc_protocol_deps_any="gcrypt nettle openssl"
>> >+ffrtmpenc_protocol_select="tcp_protocol"
>> >httpproxy_protocol_deps="network"
>> >@@ -1541,6 +1546,7 @@ mmsh_protocol_select="http_protocol"
>> >rtmp_protocol_deps="!librtmp_protocol"
>> >rtmp_protocol_select="tcp_protocol"
>> >+rtmpe_protocol_select="ffrtmpenc_protocol"
>> >rtmphttp_protocol_deps="!librtmp_protocol"
>> >rtmphttp_protocol_select="http_protocol"
>> >rtmpt_protocol_deps="!librtmp_protocol"
>>
>> Since the others (rtmp and rtmpt) both have the
>> _deps="!librtmp_protocol", this one should as well, I think. In
>> principle it's not needed since we get the same dep via ffrtmpenc
>> though, but it's perhaps better to keep it for consistency.
>
> I think there is no need to repeat it.  Rather, drop it from the
> other protocols instead of duplicating.

Okay, I'll remove that and submit an other patch in order to this
useless duplication.

-- 
Best regards,
Samuel Pitoiset.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] configure: mark libfdk-aac as nonfree

2012-07-19 Thread Luca Barbato 
On 07/19/2012 10:19 AM, Jean-Baptiste Kempf wrote:
> On Wed, Jul 18, 2012 at 03:38:38PM +0200, Diego Biurrun wrote :
>> The SFLC lawyer said the libfdk-aac license looked (l)gpl-incompatible
>> to him.
> 
> Well, I am sad, but not surprised.
> 

I'd like to have a better understanding

fdk:

Redistribution and use in source and binary forms, with or without
modification, are permitted without
payment of copyright license fees provided that you satisfy the
following conditions:

(A)
You must retain the complete text of this software license in
redistributions of the FDK AAC Codec or
your modifications thereto in source code form.

(B)
You must retain the complete text of this software license in the
documentation and/or other materials
provided with redistributions of the FDK AAC Codec or your modifications
thereto in binary form.
You must make available free of charge copies of the complete source
code of the FDK AAC Codec and your
modifications thereto to recipients of copies in binary form.

(C)
The name of Fraunhofer may not be used to endorse or promote products
derived from this library without
prior written permission.

(D)
You may not charge copyright license fees for anyone to use, copy or
distribute the FDK AAC Codec
software or your modifications thereto.

(E)
Your modified versions of the FDK AAC Codec must carry prominent notices
stating that you changed the software
and the date of any change. For modified versions of the FDK AAC Codec,
the term
"Fraunhofer FDK AAC Codec Library for Android" must be replaced by the term
"Third-Party Modified Version of the Fraunhofer FDK AAC Codec Library
for Android."

Currently the mismatch is (E) more than (D) in my eyes.

D is a match for lgpl-2.1 2. c

c) You must cause the whole of the work to be licensed at no
charge to all third parties under the terms of this License.

The second part of E is a stronger version of the non-endorsement clause
from bsd (that is compatible) so I'm not sure it could be considered an
additional restriction.


Could we have a specific detail on which section clashes?

lu

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

Re: [libav-devel] [PATCH 02/12] mpegenc: remove disabled code

2012-07-19 Thread Luca Barbato 
On 07/29/2011 01:02 PM, Diego Biurrun wrote:
> ---
>  libavformat/mpegenc.c |  116 
> -
>  1 files changed, 0 insertions(+), 116 deletions(-)
> 

Seems fine.


-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

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

Re: [libav-devel] [PATCH] configure: set icc_version where it is needed

2012-07-19 Thread Kostya Shishkov 
On Thu, Jul 19, 2012 at 11:43:32AM +0100, Mans Rullgard wrote:
> This variable is only used once, so setting it there is clearer.
> 
> Signed-off-by: Mans Rullgard 
> ---
>  configure | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index 09ae733..79d728e 100755
> --- a/configure
> +++ b/configure
> @@ -1975,7 +1975,6 @@ elif $cc -v 2>&1 | grep -qi ^gcc; then
>  elif $cc --version 2>/dev/null | grep -q Intel; then
>  cc_type=icc
>  cc_ident=$($cc --version | head -n1)
> -icc_version=$($cc -dumpversion)
>  CC_DEPFLAGS='-MMD'
>  AS_DEPFLAGS='-MMD'
>  speed_cflags='-O3'
> @@ -3149,6 +3148,7 @@ if enabled icc; then
>  # icc 11.0 and 11.1 work with ebp_available, but don't pass the test
>  enable ebp_available
>  if enabled x86_32; then
> +icc_version=$($cc -dumpversion)
>  test ${icc_version%%.*} -ge 11 &&
>  check_cflags -falign-stack=maintain-16-byte ||
>  disable aligned_stack
> -- 

looks fine
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

[libav-devel] [PATCH] configure: set icc_version where it is needed

2012-07-19 Thread Mans Rullgard 
This variable is only used once, so setting it there is clearer.

Signed-off-by: Mans Rullgard 
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 09ae733..79d728e 100755
--- a/configure
+++ b/configure
@@ -1975,7 +1975,6 @@ elif $cc -v 2>&1 | grep -qi ^gcc; then
 elif $cc --version 2>/dev/null | grep -q Intel; then
 cc_type=icc
 cc_ident=$($cc --version | head -n1)
-icc_version=$($cc -dumpversion)
 CC_DEPFLAGS='-MMD'
 AS_DEPFLAGS='-MMD'
 speed_cflags='-O3'
@@ -3149,6 +3148,7 @@ if enabled icc; then
 # icc 11.0 and 11.1 work with ebp_available, but don't pass the test
 enable ebp_available
 if enabled x86_32; then
+icc_version=$($cc -dumpversion)
 test ${icc_version%%.*} -ge 11 &&
 check_cflags -falign-stack=maintain-16-byte ||
 disable aligned_stack
-- 
1.7.11.1

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

Re: [libav-devel] [PATCH 02/12] mpegenc: remove disabled code

2012-07-19 Thread Diego Biurrun 
On Fri, Jul 29, 2011 at 01:02:36PM +0200, Diego Biurrun wrote:
> ---
>  libavformat/mpegenc.c |  116 
> -
>  1 files changed, 0 insertions(+), 116 deletions(-)

ping

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 2/2] configure: mark libfdk-aac as nonfree

2012-07-19 Thread Jean-Baptiste Kempf 
On Wed, Jul 18, 2012 at 03:38:38PM +0200, Diego Biurrun wrote :
> The SFLC lawyer said the libfdk-aac license looked (l)gpl-incompatible
> to him.

Well, I am sad, but not surprised.


-- 
Jean-Baptiste Kempf
http://www.jbkempf.com/ - +33 672 704 734
Sent from my Electronic Device
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1/2] libopenjpeg: support YUV and deep RGB pixel formats

2012-07-19 Thread Anton Khirnov 

On Thu, 19 Jul 2012 03:41:11 +0200, Luca Barbato  wrote:
> From: Michael Bradshaw 
> 
> Based on FFmpeg version from
> commit 3275981207e30e140cffaea334ac390f1a04266a
> ---
>  libavcodec/libopenjpegdec.c |  305 
> +++
>  1 files changed, 250 insertions(+), 55 deletions(-)
> 
> diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
> index 799ccd7..1c08f8a 100644
> --- a/libavcodec/libopenjpegdec.c
> +++ b/libavcodec/libopenjpegdec.c
> @@ -24,29 +24,200 @@
>  * JPEG 2000 decoder using libopenjpeg
>  */
>  
> +#define  OPJ_STATIC
> +#include 
> +
> +#include "libavutil/intreadwrite.h"
>  #include "libavutil/imgutils.h"
> +#include "libavutil/pixfmt.h"
> +#include "libavutil/opt.h"
>  #include "avcodec.h"
> -#include "libavutil/intreadwrite.h"
>  #include "thread.h"
> -#define  OPJ_STATIC
> -#include 
>  
>  #define JP2_SIG_TYPE0x6A502020
>  #define JP2_SIG_VALUE   0x0D0A870A
>  
> +// pix_fmts with lower bpp have to be listed before
> +// similar pix_fmts with higher bpp.
> +#define RGB_PIXEL_FORMATS  PIX_FMT_RGB24, PIX_FMT_RGBA,  \
> +   PIX_FMT_RGB48
> +
> +#define GRAY_PIXEL_FORMATS PIX_FMT_GRAY8, PIX_FMT_Y400A, \
> +   PIX_FMT_GRAY16
> +
> +#define YUV_PIXEL_FORMATS  PIX_FMT_YUV410P,   PIX_FMT_YUV411P,   \
> +   PIX_FMT_YUVA420P, \
> +   PIX_FMT_YUV420P,   PIX_FMT_YUV422P,   \
> +   PIX_FMT_YUV440P,   PIX_FMT_YUV444P,   \
> +   PIX_FMT_YUV420P9,  PIX_FMT_YUV422P9,  \
> +   PIX_FMT_YUV444P9, \
> +   PIX_FMT_YUV420P10, PIX_FMT_YUV422P10, \
> +   PIX_FMT_YUV444P10, \
> +   PIX_FMT_YUV420P16, PIX_FMT_YUV422P16, \
> +   PIX_FMT_YUV444P16
> +
> +static const enum PixelFormat rgb_pix_fmts[]  = {RGB_PIXEL_FORMATS};
> +static const enum PixelFormat gray_pix_fmts[] = {GRAY_PIXEL_FORMATS};
> +static const enum PixelFormat yuv_pix_fmts[]  = {YUV_PIXEL_FORMATS};
> +static const enum PixelFormat any_pix_fmts[]  = {RGB_PIXEL_FORMATS,
> + GRAY_PIXEL_FORMATS,
> + YUV_PIXEL_FORMATS};
> +
>  typedef struct {
>  opj_dparameters_t dec_params;
>  AVFrame image;
>  } LibOpenJPEGContext;
>  
> -static int check_image_attributes(opj_image_t *image)
> +static inline int libopenjpeg_matches_pix_fmt(const opj_image_t *image,
> +  enum PixelFormat pix_fmt)

What's with all the inlines? Does inlining them give any practical benefit?

> +{
> +AVPixFmtDescriptor descriptor = av_pix_fmt_descriptors[pix_fmt];
> +int match = 1;
> +
> +if (descriptor.nb_components != image->numcomps) {
> +return 0;
> +}
> +
> +switch (descriptor.nb_components) {
> +case 4: match = match && descriptor.comp[3].depth_minus1 + 1 >= 
> image->comps[3].prec &&
> + 1 == image->comps[3].dx &&
> + 1 == image->comps[3].dy;
> +case 3: match = match && descriptor.comp[2].depth_minus1 + 1 >= 
> image->comps[2].prec &&
> + 1 << descriptor.log2_chroma_w == 
> image->comps[2].dx &&
> + 1 << descriptor.log2_chroma_h == 
> image->comps[2].dy;
> +case 2: match = match && descriptor.comp[1].depth_minus1 + 1 >= 
> image->comps[1].prec &&
> + 1 << descriptor.log2_chroma_w == 
> image->comps[1].dx &&
> + 1 << descriptor.log2_chroma_h == 
> image->comps[1].dy;
> +case 1: match = match && descriptor.comp[0].depth_minus1 + 1 >= 
> image->comps[0].prec &&
> + 1 == image->comps[0].dx &&
> + 1 == image->comps[0].dy;
> +default:
> +break;
> +}
> +
> +return match;
> +}
> +
> +static inline enum PixelFormat libopenjpeg_guess_pix_fmt(const opj_image_t 
> *image)
> +{
> +int index;
> +const enum PixelFormat *possible_fmts = NULL;
> +int possible_fmts_nb = 0;
> +
> +switch (image->color_space) {
> +case CLRSPC_SRGB:
> +possible_fmts = rgb_pix_fmts;
> +possible_fmts_nb = FF_ARRAY_ELEMS(rgb_pix_fmts);
> +break;
> +case CLRSPC_GRAY:
> +possible_fmts = gray_pix_fmts;
> +possible_fmts_nb = FF_ARRAY_ELEMS(gray_pix_fmts);
> +break;
> +case CLRSPC_SYCC:
> +possible_fmts = yuv_pix_fmts;
> +possible_fmts_nb = FF_ARRAY_ELEMS(yuv_pix_fmts);
> +break;
> +default:
> +possible_fmts = any_pix_fmts;
> +possible_fmts_nb = FF_ARRAY_ELEMS(any_pix_fmts);
> +break;
> +}
> +
> +for (index = 0; index < possible_fmts_nb; ++index) {

It's named index and not i because?
also nit: ++ on the wrong side ;)

> +if (libopenjpeg_m

Re: [libav-devel] [PATCH 1.5/2] G.723.1 decoder data tables

2012-07-19 Thread Kostya Shishkov 
On Thu, Jul 19, 2012 at 10:09:52AM +0200, Diego Biurrun wrote:
> On Wed, Jul 18, 2012 at 08:16:22PM +0200, Kostya Shishkov wrote:
> > On Wed, Jul 18, 2012 at 08:08:43PM +0200, Diego Biurrun wrote:
> > > On Mon, Jul 16, 2012 at 08:35:57PM +0200, Kostya Shishkov wrote:
> > > > For clarity I'm sending g723_1_data.h for review separately (and it 
> > > > will be
> > > > cut out from decoder patch).
> > > > 
> > > > /**
> > > >  * Postfilter gain weighting factors scaled by 2^15
> > > >  */
> > > > static const int16_t ppf_gain_weight[2] = { 0x1800, 0x2000 };
> > > 
> > > Do all these comments need to be Doxygen?
> > 
> > It's up to you to decide, I don't care.
> 
> Make it non-Doxygen then.  It's visible at file-level only.

OK, I'll change it locally.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 1.5/2] G.723.1 decoder data tables

2012-07-19 Thread Diego Biurrun 
On Wed, Jul 18, 2012 at 08:16:22PM +0200, Kostya Shishkov wrote:
> On Wed, Jul 18, 2012 at 08:08:43PM +0200, Diego Biurrun wrote:
> > On Mon, Jul 16, 2012 at 08:35:57PM +0200, Kostya Shishkov wrote:
> > > For clarity I'm sending g723_1_data.h for review separately (and it will 
> > > be
> > > cut out from decoder patch).
> > > 
> > > /**
> > >  * Postfilter gain weighting factors scaled by 2^15
> > >  */
> > > static const int16_t ppf_gain_weight[2] = { 0x1800, 0x2000 };
> > 
> > Do all these comments need to be Doxygen?
> 
> It's up to you to decide, I don't care.

Make it non-Doxygen then.  It's visible at file-level only.

Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel