Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[wm4]

On Fri, 4 Mar 2016 08:47:14 +0100
Thilo Borgmann  wrote:

> Am 04.03.16 um 08:23 schrieb wm4:
> > On Fri, 4 Mar 2016 00:55:35 + (UTC)
> > Carl Eugen Hoyos  wrote:
> >   
> >> Timothy Gu  gmail.com> writes:
> >>  
> >>> Of course, this argument operates on the premise that 
> >>> making things easier for users is of utmost concern 
> >>> for us. Please inspire me if this is not the case.
> >>
> >> On the contrary, I believe while the current versioing 
> >> scheme is simple and understandable, the suggested one 
> >> is misleading, both for users and when reading user 
> >> questions.  
> > 
> > Well, duh, everyone disagrees with you.  
> 
> Not true. For what I've read, I can't see the benefit of the change.
> However, changing it should require a real reason and I don't see it.
> 
> So, what exactly is the benefit of the proposed versioning? Can anyone
> please elaborate what the current state is and what exactly would make
> the user's life happier with the new one?

Being able to see the, well, version in the version output (instead of
random numbers) sounds like a pretty convincing argument.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Fix H264 and HEVC vui info update

[Agatha Hu]

---
 libavcodec/nvenc.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..5694f17 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -867,15 +867,22 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)
 }
 
 switch (avctx->codec->id) {
-case AV_CODEC_ID_H264:
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 = 1;
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 = 1;
-
+case AV_CODEC_ID_H264: 
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix 
= avctx->colorspace;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries
 = avctx->color_primaries;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = 
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ420P || 
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat = 
5; // 5=unspecified
 
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = avctx->color_range == AVCOL_RANGE_JPEG;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 =
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
+
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 =
+   
(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 != 0);
 
 ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
@@ -944,6 +951,22 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 
 break;
 case AV_CODEC_ID_H265:
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix 
= avctx->colorspace;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries
 = avctx->color_primaries;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 =
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ420P || 
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat = 
5; // 5=unspecified
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
 =
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag
 =
+   
(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 != 0);
+
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
 
-- 
1.9.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Thilo Borgmann]

Am 04.03.16 um 08:23 schrieb wm4:
> On Fri, 4 Mar 2016 00:55:35 + (UTC)
> Carl Eugen Hoyos  wrote:
> 
>> Timothy Gu  gmail.com> writes:
>>
>>> Of course, this argument operates on the premise that 
>>> making things easier for users is of utmost concern 
>>> for us. Please inspire me if this is not the case.  
>>
>> On the contrary, I believe while the current versioing 
>> scheme is simple and understandable, the suggested one 
>> is misleading, both for users and when reading user 
>> questions.
> 
> Well, duh, everyone disagrees with you.

Not true. For what I've read, I can't see the benefit of the change.
However, changing it should require a real reason and I don't see it.

So, what exactly is the benefit of the proposed versioning? Can anyone
please elaborate what the current state is and what exactly would make
the user's life happier with the new one?

-Thilo


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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Add early support for colour elements

[Neil Birkbeck]

And yet another revision, where the syntax lists are actually terminated...

On Thu, Mar 3, 2016 at 12:09 PM, Neil Birkbeck  wrote:
> I've attached a slightly cleaner (more isolated) patch that moves the
> parsing into a helper function.
>
> On Mon, Feb 29, 2016 at 5:15 PM, Neil Birkbeck  
> wrote:
>> Adding early support for a subset of the proposed colour elements
>> according to the latest version of spec:
>> https://mailarchive.ietf.org/arch/search/?email_list=cellar=1=hIKLhMdgTMTEwUTeA4ct38h0tmE
>>
>> I've left out elements for pix_fmt related things as there still
>> seems to be some discussion around these, and the max_cll/max_fall
>> are currently not propagated as there is not yet side data for them.
>>
>> The new elements are exposed under strict experimental mode.
>>
>> Signed-off-by: Neil Birkbeck 
>> ---
>>  libavformat/matroska.h|  28 ++
>>  libavformat/matroskadec.c | 136 
>> ++
>>  2 files changed, 164 insertions(+)
>>
>> diff --git a/libavformat/matroska.h b/libavformat/matroska.h
>> index a654e0c..e97fe6b 100644
>> --- a/libavformat/matroska.h
>> +++ b/libavformat/matroska.h
>> @@ -123,6 +123,34 @@
>>  #define MATROSKA_ID_VIDEOALPHAMODE 0x53C0
>>  #define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3
>>  #define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524
>> +#define MATROSKA_ID_VIDEOCOLOR 0x55B0
>> +
>> +#define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1
>> +#define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2
>> +#define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3
>> +#define MATROSKA_ID_VIDEOCOLORCHROMASUBVERT 0x55B4
>> +#define MATROSKA_ID_VIDEOCOLORCBSUBHORZ 0x55B5
>> +#define MATROSKA_ID_VIDEOCOLORCBSUBVERT 0x55B6
>> +#define MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ 0x55B7
>> +#define MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT 0x55B8
>> +#define MATROSKA_ID_VIDEOCOLORRANGE 0x55B9
>> +#define MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS 0x55BA
>> +
>> +#define MATROSKA_ID_VIDEOCOLORPRIMARIES 0x55BB
>> +#define MATROSKA_ID_VIDEOCOLORMAXCLL 0x55BC
>> +#define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD
>> +
>> +#define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0
>> +#define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1
>> +#define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2
>> +#define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3
>> +#define MATROSKA_ID_VIDEOCOLOR_GY 0x55D4
>> +#define MATROSKA_ID_VIDEOCOLOR_BX 0x55D5
>> +#define MATROSKA_ID_VIDEOCOLOR_BY 0x55D6
>> +#define MATROSKA_ID_VIDEOCOLOR_WHITEX 0x55D7
>> +#define MATROSKA_ID_VIDEOCOLOR_WHITEY 0x55D8
>> +#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX 0x55D9
>> +#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN 0x55DA
>>
>>  /* IDs in the trackaudio master */
>>  #define MATROSKA_ID_AUDIOSAMPLINGFREQ 0xB5
>> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
>> index d20568c..4510e8e 100644
>> --- a/libavformat/matroskadec.c
>> +++ b/libavformat/matroskadec.c
>> @@ -39,6 +39,7 @@
>>  #include "libavutil/intfloat.h"
>>  #include "libavutil/intreadwrite.h"
>>  #include "libavutil/lzo.h"
>> +#include "libavutil/mastering_display_metadata.h"
>>  #include "libavutil/mathematics.h"
>>  #include "libavutil/opt.h"
>>  #include "libavutil/time_internal.h"
>> @@ -130,6 +131,36 @@ typedef struct MatroskaTrackEncoding {
>>  MatroskaTrackEncryption encryption;
>>  } MatroskaTrackEncoding;
>>
>> +typedef struct MatroskaMasteringMeta {
>> +double r_x;
>> +double r_y;
>> +double g_x;
>> +double g_y;
>> +double b_x;
>> +double b_y;
>> +double white_x;
>> +double white_y;
>> +double max_luminance;
>> +double min_luminance;
>> +} MatroskaMasteringMeta;
>> +
>> +typedef struct MatroskaTrackVideoColor {
>> +uint64_t matrix_coefficients;
>> +uint64_t bits_per_channel;
>> +uint64_t chroma_sub_horz;
>> +uint64_t chroma_sub_vert;
>> +uint64_t cb_sub_horz;
>> +uint64_t cb_sub_vert;
>> +uint64_t chroma_siting_horz;
>> +uint64_t chroma_siting_vert;
>> +uint64_t range;
>> +uint64_t transfer_characteristics;
>> +uint64_t primaries;
>> +uint64_t max_cll;
>> +uint64_t max_fall;
>> +MatroskaMasteringMeta mastering_meta;
>> +} MatroskaTrackVideoColor;
>> +
>>  typedef struct MatroskaTrackVideo {
>>  double   frame_rate;
>>  uint64_t display_width;
>> @@ -139,6 +170,7 @@ typedef struct MatroskaTrackVideo {
>>  EbmlBin color_space;
>>  uint64_t stereo_mode;
>>  uint64_t alpha_mode;
>> +MatroskaTrackVideoColor color;
>>  } MatroskaTrackVideo;
>>
>>  typedef struct MatroskaTrackAudio {
>> @@ -356,6 +388,36 @@ static const EbmlSyntax matroska_info[] = {
>>  { 0 }
>>  };
>>
>> +static const EbmlSyntax matroska_mastering_meta[] = {
>> +{ MATROSKA_ID_VIDEOCOLOR_RX, EBML_FLOAT, 0, 
>> offsetof(MatroskaMasteringMeta, r_x), { .f=-1 } },
>> +{ MATROSKA_ID_VIDEOCOLOR_RY, EBML_FLOAT, 0, 
>> offsetof(MatroskaMasteringMeta, r_y), { .f=-1 } },
>> +{ 

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[wm4]

On Fri, 4 Mar 2016 00:55:35 + (UTC)
Carl Eugen Hoyos  wrote:

> Timothy Gu  gmail.com> writes:
> 
> > Of course, this argument operates on the premise that 
> > making things easier for users is of utmost concern 
> > for us. Please inspire me if this is not the case.  
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

Well, duh, everyone disagrees with you.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] nvenc.c Fix H264 and HEVC vui info update

[Agatha Hu]

Yes. That's stange, let me try again
On 2016/3/4 14:50, Timothy Gu wrote:

On Fri, Mar 04, 2016 at 12:45:47PM +0800, Agatha Hu wrote:

---
  libavcodec/nvenc.c | 33 -
  1 file changed, 28 insertions(+), 5 deletions(-)


This patched is corrupted by your mail client. What's wrong with the first
patch you sent (with git-send-email)?

Timothy
___
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] nvenc.c Fix H264 and HEVC vui info update

[Timothy Gu]

On Fri, Mar 04, 2016 at 12:45:47PM +0800, Agatha Hu wrote:
> ---
>  libavcodec/nvenc.c | 33 -
>  1 file changed, 28 insertions(+), 5 deletions(-)

This patched is corrupted by your mail client. What's wrong with the first
patch you sent (with git-send-email)?

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

Re: [FFmpeg-devel] [PATCH] web/contact: Fix link.

[Lou Logan]

On Thu, Mar 3, 2016, at 09:32 AM, Simon Thelen wrote:
>
> Probably, but I don't know how to get in contact with someone who can do
> that.

I forwarded the issue to Burek. burek021 at gmail

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

Re: [FFmpeg-devel] What is the problem with my transcoding?

[Lou Logan]

On Thu, Mar 3, 2016, at 06:31 PM, fangzhen wrote:
> Hi guys,
> 
> Recently, I am doing some transcoding using ffmpeg.
[...]

Wrong mailing list. ffmpeg-devel is for submitting patches and for
discussions related to the development of FFmpeg.

User help is at ffmpeg-user mailing list and #ffmpeg IRC channel.

Make sure you show the complete console output from your command and
avoid using -hide_banner when asking for help.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

[Mats Peterson]

Removed some unused variables in AVIStream.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 9713e3890edccb379b3962ffcda6ee6068d9c38d Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 05:52:58 +0100
Subject: [PATCH v5 1/4 v3] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   56 --
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..fab2e40 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,13 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+uint32_t palette[AVPALETTE_COUNT];
+int64_t pal_offset;
+int pal_done;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +363,8 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,11 +654,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,26 +670,38 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && !avist->pal_done) {
 int64_t cur_offset = avio_tell(pb);
 avio_seek(pb, avist->pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
+avist->pal_done++;
 }
 avi_stream2fourcc(tag, stream_index, enc->codec_type);
 tag[2] = 'p'; tag[3] = 'c';
@@ -696,11 +710,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 avio_w8(pb, pal_size & 0xFF);
 avio_wl16(pb, 0); // reserved
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 

[FFmpeg-devel] [PATCH] nvenc.c Fix H264 and HEVC vui info update

[Agatha Hu]

---
 libavcodec/nvenc.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..5694f17 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -867,15 +867,22 @@ static av_cold int 
nvenc_encode_init(AVCodecContext *avctx)

 }

 switch (avctx->codec->id) {
-case AV_CODEC_ID_H264:
- 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag 
= 1;
- 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag 
= 1;

-
+case AV_CODEC_ID_H264:

ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix 
= avctx->colorspace;


ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries 
= avctx->color_primaries;


ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics 
= avctx->color_trc;
+ 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag 
=
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt 
== AV_PIX_FMT_YUVJ420P ||
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+ 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat 
= 5; // 5=unspecified


- 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag 
= avctx->color_range == AVCOL_RANGE_JPEG;
+ 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag 
=
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);

+
+ 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag 
=
+ 
(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag 
!= 0);


 ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
@@ -944,6 +951,22 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)


 break;
 case AV_CODEC_ID_H265:
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix 
= avctx->colorspace;
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries 
= avctx->color_primaries;
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics 
= avctx->color_trc;
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag 
=
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt 
== AV_PIX_FMT_YUVJ420P ||
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat 
= 5; // 5=unspecified

+
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag 
=
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);

+
+ 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag 
=
+ 
(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag 
!= 0);

+
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;

--
1.9.1



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

[FFmpeg-devel] [PATCH v5 1/4 v2] lavf/avienc: Add support for palette side data

[Mats Peterson]

Indentation fix.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 48d52b0d6ff6c64bc9f4afbf01893f8780ba97e4 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 05:18:15 +0100
Subject: [PATCH v5 1/4 v2] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   58 +-
 1 file changed, 38 insertions(+), 20 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..de40a82 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,15 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+uint32_t palette[AVPALETTE_COUNT];
+int pal_done;
+
+int64_t hdr_pal_offset;
+int hdr_pal_done;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +365,8 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->hdr_pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,11 +656,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,22 +672,34 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+int ret2 = ff_get_packet_palette(s, opkt, ret, avist->palette);
+if (ret2 < 0)
+return ret2;
+if (ret2) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && !avist->hdr_pal_done) {
 int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+avio_seek(pb, avist->hdr_pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
@@ -696,11 +712,13 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 avio_w8(pb, pal_size & 0xFF);
 avio_wl16(pb, 0); // reserved
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = avist->palette[i];
 avio_wb32(pb, v<<8);
 }
 ff_end_tag(pb, pc_tag);
 }
+}
+if (ret) {
 ret = 

Re: [FFmpeg-devel] [PATCH v5 1/4 v2] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 05:13 AM, Mats Peterson wrote:

Indentation fix.



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



Sorry, this is riffenc.c and not avienc.c. Forget this one.

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

Re: [FFmpeg-devel] [PATCH]lavf/mpeg: Identify sub-stream ID 0xa1 as mlp

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 11:26:20AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch (still) fixes ticket #4786 for me.
> Autodetection seems impossible to me and the following 
> page suggests that this patch is likely correct:
> http://dvd-audio.sourceforge.net/spec/aob.shtml
> 
> Please comment, Carl Eugen

>  mpeg.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 441c00cda76c5f59b560517115ad1677ab8061bd  patchmpegmlp.diff
> diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
> index 787d5f0..2f48459 100644

if that works and no better way is known then it should be ok

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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

[FFmpeg-devel] [PATCH v5 1/4 v2] lavf/avienc: Add support for palette side data

[Mats Peterson]

Indentation fix.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 6259934554b87490b3af969e330af6e52acd98e3 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 05:12:40 +0100
Subject: [PATCH v5 1/4 v2] lavf/avienc: Add support for palette side data

---
 libavformat/riffenc.c |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 1dd7971..195a58e 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -209,12 +209,17 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 int keep_height = enc->extradata_size >= 9 &&
   !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
 int extradata_size = enc->extradata_size - 9*keep_height;
-int raw_pal_avi;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
+int pal_avi;
 
-raw_pal_avi = !for_asf && enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
-  !enc->codec_tag &&
-enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8;
-if (!enc->extradata_size && raw_pal_avi)
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+pal_avi = !for_asf &&
+  (pix_fmt == AV_PIX_FMT_PAL8 ||
+   pix_fmt == AV_PIX_FMT_MONOWHITE ||
+   pix_fmt == AV_PIX_FMT_MONOBLACK);
+
+if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
 /* size */
@@ -239,11 +244,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_write(pb, enc->extradata, extradata_size);
 if (!for_asf && extradata_size & 1)
 avio_w8(pb, 0);
-} else if (raw_pal_avi) {
+} else if (pal_avi) {
 int i;
-enum AVPixelFormat pix_fmt = enc->pix_fmt;
-if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
-pix_fmt = AV_PIX_FMT_MONOWHITE;
 for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
 /* Initialize 1 bpp palette to black & white */
 if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 05:07 AM, Mats Peterson wrote:

On 03/04/2016 05:04 AM, Mats Peterson wrote:

On 03/04/2016 04:57 AM, Mats Peterson wrote:

On 03/04/2016 04:42 AM, Michael Niedermayer wrote:

On Thu, Mar 03, 2016 at 12:35:00AM +0100, Mats Peterson wrote:


--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  movenc.c |   44 +---
  1 file changed, 25 insertions(+), 19 deletions(-)
6fb0f0f43c38403c80a2861334a04019288c0c96
0002-lavf-movenc-Add-support-for-palette-side-data.patch
 From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00
2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 00:27:53 +0100
Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data


applied

thanks



Danke. avienc/riffenc still left. Are there any problems there? It's
needed for Microsoft Video 1 (CRAM) and RLE in 8-bit mode.


RLE in 4-bit mode as well, I suppose :)



Yep, both RLE4 and RLE8.

Mats

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

Re: [FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 05:04 AM, Mats Peterson wrote:

On 03/04/2016 04:57 AM, Mats Peterson wrote:

On 03/04/2016 04:42 AM, Michael Niedermayer wrote:

On Thu, Mar 03, 2016 at 12:35:00AM +0100, Mats Peterson wrote:


--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  movenc.c |   44 +---
  1 file changed, 25 insertions(+), 19 deletions(-)
6fb0f0f43c38403c80a2861334a04019288c0c96
0002-lavf-movenc-Add-support-for-palette-side-data.patch
 From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 00:27:53 +0100
Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data


applied

thanks



Danke. avienc/riffenc still left. Are there any problems there? It's
needed for Microsoft Video 1 (CRAM) and RLE in 8-bit mode.


RLE in 4-bit mode as well, I suppose :)

Mats

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

Re: [FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 04:57 AM, Mats Peterson wrote:

On 03/04/2016 04:42 AM, Michael Niedermayer wrote:

On Thu, Mar 03, 2016 at 12:35:00AM +0100, Mats Peterson wrote:


--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  movenc.c |   44 +---
  1 file changed, 25 insertions(+), 19 deletions(-)
6fb0f0f43c38403c80a2861334a04019288c0c96
0002-lavf-movenc-Add-support-for-palette-side-data.patch
 From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 00:27:53 +0100
Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data


applied

thanks



Danke. avienc/riffenc still left. Are there any problems there? It's
needed for Microsoft Video 1 (CRAM) and RLE in 8-bit mode.

Mats

___


I suppose you're in the process of writing some accompanying FATE tests, 
and that's why you're waiting...


Mats

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

Re: [FFmpeg-devel] [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()

[Mats Peterson]

On 03/04/2016 04:41 AM, Michael Niedermayer wrote:

On Thu, Mar 03, 2016 at 08:29:20AM +0100, Mats Peterson wrote:

Due to Morton Balint's recent addition of
ff_standardize_creation_time(), the previous patch would fail.
Please add this one before any more changes occur.

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  internal.h |7 +--
  utils.c|   23 ---
  2 files changed, 21 insertions(+), 9 deletions(-)
ac3e78aa6b8d067e75004b99d52c5a5f1a2a831e  
0004-lavf-utils-Normalize-AVPacket.data-to-native-endian-.patch
 From 08b75292ed7ede8de32bdecf5ec72fedc18b1aa9 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 08:25:58 +0100
Subject: [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian 
in ff_get_packet_palette()


applied

thanks

[...]



Thanks.

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

Re: [FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data

[Mats Peterson]

On 03/04/2016 04:42 AM, Michael Niedermayer wrote:

On Thu, Mar 03, 2016 at 12:35:00AM +0100, Mats Peterson wrote:


--
Mats Peterson
http://matsp888.no-ip.org/~mats/



  movenc.c |   44 +---
  1 file changed, 25 insertions(+), 19 deletions(-)
6fb0f0f43c38403c80a2861334a04019288c0c96  
0002-lavf-movenc-Add-support-for-palette-side-data.patch
 From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 00:27:53 +0100
Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data


applied

thanks



Danke. avienc/riffenc still left. Are there any problems there? It's 
needed for Microsoft Video 1 (CRAM) and RLE in 8-bit mode.


Mats

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

[FFmpeg-devel] [PATCH] Fix H264 and HEVC vui info update

[Agatha Hu]

---
 libavcodec/nvenc.c | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)

diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
index a3b02fa..5694f17 100644
--- a/libavcodec/nvenc.c
+++ b/libavcodec/nvenc.c
@@ -867,15 +867,22 @@ static av_cold int nvenc_encode_init(AVCodecContext 
*avctx)
 }
 
 switch (avctx->codec->id) {
-case AV_CODEC_ID_H264:
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 = 1;
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 = 1;
-
+case AV_CODEC_ID_H264: 
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourMatrix 
= avctx->colorspace;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourPrimaries
 = avctx->color_primaries;
 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = 
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ420P || 
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat = 
5; // 5=unspecified
 
-
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 = avctx->color_range == AVCOL_RANGE_JPEG;
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
 =
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
+
+
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoSignalTypePresentFlag
 =
+   
(ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.h264Config.h264VUIParameters.videoFullRangeFlag
 != 0);
 
 ctx->encode_config.encodeCodecConfig.h264Config.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.h264Config.sliceModeData = 1;
@@ -944,6 +951,22 @@ static av_cold int nvenc_encode_init(AVCodecContext *avctx)
 
 break;
 case AV_CODEC_ID_H265:
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourMatrix 
= avctx->colorspace;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourPrimaries
 = avctx->color_primaries;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.transferCharacteristics
 = avctx->color_trc;
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 =
+(avctx->color_range == AVCOL_RANGE_JPEG || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ420P || 
+avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == 
AV_PIX_FMT_YUVJ444P);
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat = 
5; // 5=unspecified
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
 =
+   (avctx->colorspace != 2 || avctx->color_primaries != 2 || 
avctx->color_trc != 2);
+
+
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoSignalTypePresentFlag
 =
+   
(ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.colourDescriptionPresentFlag
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFormat 
!= 5
+   || 
ctx->encode_config.encodeCodecConfig.hevcConfig.hevcVUIParameters.videoFullRangeFlag
 != 0);
+
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceMode = 3;
 ctx->encode_config.encodeCodecConfig.hevcConfig.sliceModeData = 1;
 
-- 
1.9.1


---
This email message is for the sole use of the intended recipient(s) and may 
contain
confidential information.  Any unauthorized review, use, disclosure or 
distribution
is prohibited.  If you are not the intended recipient, please contact the 
sender by
reply email and destroy all copies of the original message.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] What is the problem with my transcoding?

[fangzhen]

Hi guys,

Recently, I am doing some transcoding using ffmpeg. The input protocol is udp 
and output is HLS.
The command line is the following:
ffmpeg -hide_banner -threads auto -y -xerror -itsoffset 0.5 -async 1 -i 
udp://127.0.0.1:48882?overrun_nonfatal=1_size=1_size=1
 -map p:3801 -vf movie='/home/u
buntu/codec/logo/zb_67.tga',scale=279.0:69.0[logo];[in][logo]overlay=main_w-overlay_w-96.0:54.0[out]
 -c:v libx264 -preset superfast -level:v 5.1 -s 1280x720 -r 25 -x264-params 
keyint=50:scenecut=0 -b:v 1072k -c:a libfdk_aac -profile:a aac_low -b:a 
128k -ac 2 -ar 44100 -hls_wrap 0 -hls_time 10 -hls_list_size 15 -hls_flags 
round_durations -hls_segment_filename /home/ubu
ntu/codec/release/hlstemp/20160304104101-01-%d.ts -start_number 1457059261 
/home/ubuntu/codec/release/hlstemp/01.m3u8·

However, when the transcoder runs some time later, the ouput frames are 
abnormal, a lot of mosaic appears and sometimes the picture stalls for about 5 
seconds.
There are some logs of transcoder:
[Parsed_overlay_2 @ 0x1e16100] [framesync @ 0x1e161e8] Buffer queue overflow, 
dropping.
[Parsed_overlay_2 @ 0x1ea9720] [framesync @ 0x1ea9868] Buffer queue overflow, 
dropping.
[Parsed_overlay_2 @ 0x1e16100] [framesync @ 0x1e161e8] Buffer queue overflow, 
dropping.
[Parsed_overlay_2 @ 0x1ea9720] [framesync @ 0x1ea9868] Buffer queue overflow, 
dropping.
[Parsed_overlay_2 @ 0x1e16100] [framesync @ 0x1e161e8] Buffer queue overflow, 
dropping.
[Parsed_overlay_2 @ 0x1ea9720] [framesync @ 0x1ea9868] Buffer queue overflow, 
dropping.
.
[h264 @ 0x9b1f7e40] left block unavailable for requested intra4x4 mode -1 at 0 6
[h264 @ 0x9b1f7e40] error while decoding MB 0 6, bytestream 47923
[h264 @ 0x9b1f7e40] concealing 7489 DC, 7489 AC, 7489 MV errors in I frame
[h264 @ 0x9adf6260] Reference 3 >= 2
[h264 @ 0x9adf6260] error while decoding MB 10 8, bytestream 65855
[h264 @ 0x9adf6260] concealing 7239 DC, 7239 AC, 7239 MV errors in P frame
[mpegts @ 0x3ad0880] PES packet size mismatch
[ac3 @ 0x3face00] exponent out-of-range
[ac3 @ 0x3face00] error decoding the audio block
[ac3 @ 0x3face00] frame sync error

Can anyone help me to find out why?

Thinks in advance
Felix Hu



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

Re: [FFmpeg-devel] [PATCH v5 2/4] lavf/movenc: Add support for palette side data

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:35:00AM +0100, Mats Peterson wrote:
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  movenc.c |   44 +---
>  1 file changed, 25 insertions(+), 19 deletions(-)
> 6fb0f0f43c38403c80a2861334a04019288c0c96  
> 0002-lavf-movenc-Add-support-for-palette-side-data.patch
> From 99e1f56c242cfa3d20a0987a7e766fa358ed35c2 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Thu, 3 Mar 2016 00:27:53 +0100
> Subject: [PATCH v5 2/4] lavf/movenc: Add support for palette side data

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 08:29:20AM +0100, Mats Peterson wrote:
> Due to Morton Balint's recent addition of
> ff_standardize_creation_time(), the previous patch would fail.
> Please add this one before any more changes occur.
> 
> Mats
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  internal.h |7 +--
>  utils.c|   23 ---
>  2 files changed, 21 insertions(+), 9 deletions(-)
> ac3e78aa6b8d067e75004b99d52c5a5f1a2a831e  
> 0004-lavf-utils-Normalize-AVPacket.data-to-native-endian-.patch
> From 08b75292ed7ede8de32bdecf5ec72fedc18b1aa9 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Thu, 3 Mar 2016 08:25:58 +0100
> Subject: [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native 
> endian in ff_get_packet_palette()

applied

thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Fri, Mar 04, 2016 at 12:55:35AM +, Carl Eugen Hoyos wrote:
> Timothy Gu  gmail.com> writes:
> 
> > Of course, this argument operates on the premise that 
> > making things easier for users is of utmost concern 
> > for us. Please inspire me if this is not the case.
> 
> On the contrary, I believe while the current versioing 
> scheme is simple and understandable, the suggested one 
> is misleading, both for users and when reading user 
> questions.

English is not my first language, so I might well have misunderstood. But by
using the phrase "on the contrary" are you claiming that we should not regard
users' opinions as our most important concern?

You have not provided any solid proof of your belief, which itself direct
contradicts the opinion of at least three people, one of which is ironically a
non-FFmpeg developer "user" who you claim to represent and whose opinion you
claim to value.

Therefore, without further elaboration, I propose to regard your argument as
null and void for the purpose of this discussion.

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

[FFmpeg-devel] [PATCH] lavc/psymodel: check for av_malloc failure

[Ganesh Ajjanagadde]

No idea why in commit 01ecb7172b684f1c4b3e748f95c5a9a494ca36ec the
checks were removed; this can lead to NULL pointer dereferences. This
effectively reverts that portion of the commit.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/psymodel.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavcodec/psymodel.c b/libavcodec/psymodel.c
index 6274a49..edc5ac8 100644
--- a/libavcodec/psymodel.c
+++ b/libavcodec/psymodel.c
@@ -120,7 +120,11 @@ av_cold struct FFPsyPreprocessContext* 
ff_psy_preprocess_init(AVCodecContext *av
  FF_FILTER_MODE_LOWPASS, 
FILT_ORDER,
  cutoff_coeff, 0.0, 0.0);
 if (ctx->fcoeffs) {
-ctx->fstate = av_mallocz(sizeof(ctx->fstate[0]) * avctx->channels);
+ctx->fstate = av_mallocz_array(sizeof(ctx->fstate[0]), 
avctx->channels);
+if (!ctx->fstate) {
+av_free(ctx);
+return NULL;
+}
 for (i = 0; i < avctx->channels; i++)
 ctx->fstate[i] = ff_iir_filter_init_state(FILT_ORDER);
 }
-- 
2.7.2

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

On 03/04/2016 03:51 AM, Mats Peterson wrote:

On 03/04/2016 03:49 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 03:41:23AM +0100, Mats Peterson wrote:

On 03/04/2016 03:30 AM, Michael Niedermayer wrote:


-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;



+uint32_t *p32 = (uint32_t *)p8;


undefined behavior, violating alignment requirements, and possibly
aliassing violation



Really? It works just fine, so please elaborate.


you cant cast arbitrary pointers to uint32_t

uint32_t can have platform specific alignment requirements that are
stricter than what a random 4 uint8_t have.
pkt->size does not need to be a multiple of 4 so even if pkt->data
would be aligned enough p8 doesnt have to be




Whatever. Forget this version 6 of the patch set and use version 5, with
version 2 of patch 4/4 in it (the one I posted in PM as well). And I
would be grateful if you could apply it soon. It's extensively tested here.

Mats



I get what you mean with the alignment issues, though.

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

On 03/04/2016 03:49 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 03:41:23AM +0100, Mats Peterson wrote:

On 03/04/2016 03:30 AM, Michael Niedermayer wrote:


-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;



+uint32_t *p32 = (uint32_t *)p8;


undefined behavior, violating alignment requirements, and possibly
aliassing violation



Really? It works just fine, so please elaborate.


you cant cast arbitrary pointers to uint32_t

uint32_t can have platform specific alignment requirements that are
stricter than what a random 4 uint8_t have.
pkt->size does not need to be a multiple of 4 so even if pkt->data
would be aligned enough p8 doesnt have to be




Whatever. Forget this version 6 of the patch set and use version 5, with 
version 2 of patch 4/4 in it (the one I posted in PM as well). And I 
would be grateful if you could apply it soon. It's extensively tested here.


Mats

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

On 03/04/2016 03:45 AM, Mats Peterson wrote:

On 03/04/2016 03:41 AM, Mats Peterson wrote:

On 03/04/2016 03:30 AM, Michael Niedermayer wrote:


-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;



+uint32_t *p32 = (uint32_t *)p8;


undefined behavior, violating alignment requirements, and possibly
aliassing violation



Really? It works just fine, so please elaborate.




+*p32 = AV_RL32(p8);


corrupting potenially shared or read only input packet

[...]


That one I do understand.

___


Forget this version then, and use version 5. Just as long as it gets
applied in a foreseeable future.

Mats


-

Use version 5 with v2 of patch 4/4.

Mats

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 03:41:23AM +0100, Mats Peterson wrote:
> On 03/04/2016 03:30 AM, Michael Niedermayer wrote:
> >>
> >>-if (!*palette && ret == CONTAINS_PAL)
> >>-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
> >>+if (!*palette && ret == CONTAINS_PAL) {
> >>+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
> >>+int i;
> >>+for (i = 0; i < AVPALETTE_COUNT; i++) {
> >>+uint8_t *p8 = pkt_pal + 4*i;
> >
> >>+uint32_t *p32 = (uint32_t *)p8;
> >
> >undefined behavior, violating alignment requirements, and possibly
> >aliassing violation
> >
> 
> Really? It works just fine, so please elaborate.

you cant cast arbitrary pointers to uint32_t

uint32_t can have platform specific alignment requirements that are
stricter than what a random 4 uint8_t have.
pkt->size does not need to be a multiple of 4 so even if pkt->data
would be aligned enough p8 doesnt have to be


> 
> >
> >>+*p32 = AV_RL32(p8);
> >
> >corrupting potenially shared or read only input packet
> >
> >[...]
> 
> That one I do understand.
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
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 v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

On 03/04/2016 03:41 AM, Mats Peterson wrote:

On 03/04/2016 03:30 AM, Michael Niedermayer wrote:


-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;



+uint32_t *p32 = (uint32_t *)p8;


undefined behavior, violating alignment requirements, and possibly
aliassing violation



Really? It works just fine, so please elaborate.




+*p32 = AV_RL32(p8);


corrupting potenially shared or read only input packet

[...]


That one I do understand.

___


Forget this version then, and use version 5. Just as long as it gets 
applied in a foreseeable future.


Mats

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

On 03/04/2016 03:30 AM, Michael Niedermayer wrote:


-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;



+uint32_t *p32 = (uint32_t *)p8;


undefined behavior, violating alignment requirements, and possibly
aliassing violation



Really? It works just fine, so please elaborate.




+*p32 = AV_RL32(p8);


corrupting potenially shared or read only input packet

[...]


That one I do understand.

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

Re: [FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Michael Niedermayer]

On Fri, Mar 04, 2016 at 03:08:48AM +0100, Mats Peterson wrote:
> 
> -- 
> Mats Peterson
> http://matsp888.no-ip.org/~mats/

>  internal.h |5 +++--
>  utils.c|   16 
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 10668c891a2fe1b1d311e6c48870ed3ef2967edc  
> 0004-lavf-utils-Normalize-AVPacket.data-to-native-endian.patch
> From 47d09853998e30e486b0069223a90d80e7742499 Mon Sep 17 00:00:00 2001
> From: Mats Peterson 
> Date: Fri, 4 Mar 2016 02:57:59 +0100
> Subject: [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian
> 
> ---
>  libavformat/internal.h |5 +++--
>  libavformat/utils.c|   16 
>  2 files changed, 15 insertions(+), 6 deletions(-)
> 
> diff --git a/libavformat/internal.h b/libavformat/internal.h
> index 63e0632..fe95009 100644
> --- a/libavformat/internal.h
> +++ b/libavformat/internal.h
> @@ -588,9 +588,10 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket 
> **ppkt, AVCodecContext *en
>   *
>   * Use 0 for the ret parameter to check for side data only.
>   *
> - * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
> + * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
>   * @param ret return value from ff_reshuffle_raw_rgb(), or 0
> + * @param palette pointer to pointer, which will be NULL if no palette found
>   */
> -int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const 
> uint8_t **palette);
> +int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, 
> uint32_t **palette);
>  
>  #endif /* AVFORMAT_INTERNAL_H */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 85702dd..e66abcc 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4782,18 +4782,26 @@ int ff_standardize_creation_time(AVFormatContext *s)
>  return ret;
>  }
>  
> -int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const 
> uint8_t **palette)
> +int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, 
> uint32_t **palette)
>  {
>  int size;
>  
> -*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, );
> +*palette = (uint32_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, 
> );
>  if (*palette && size != AVPALETTE_SIZE) {
>  av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
>  return AVERROR_INVALIDDATA;
>  }
>  
> -if (!*palette && ret == CONTAINS_PAL)
> -*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
> +if (!*palette && ret == CONTAINS_PAL) {
> +uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
> +int i;
> +for (i = 0; i < AVPALETTE_COUNT; i++) {
> +uint8_t *p8 = pkt_pal + 4*i;

> +uint32_t *p32 = (uint32_t *)p8;

undefined behavior, violating alignment requirements, and possibly
aliassing violation


> +*p32 = AV_RL32(p8);

corrupting potenially shared or read only input packet

[...]


-- 
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

[FFmpeg-devel] [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 47d09853998e30e486b0069223a90d80e7742499 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 02:57:59 +0100
Subject: [PATCH v6 4/4] lavf/utils: Normalize AVPacket.data to native endian

---
 libavformat/internal.h |5 +++--
 libavformat/utils.c|   16 
 2 files changed, 15 insertions(+), 6 deletions(-)

diff --git a/libavformat/internal.h b/libavformat/internal.h
index 63e0632..fe95009 100644
--- a/libavformat/internal.h
+++ b/libavformat/internal.h
@@ -588,9 +588,10 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *en
  *
  * Use 0 for the ret parameter to check for side data only.
  *
- * @param pkt pointer to the packet before calling ff_reshuffle_raw_rgb()
+ * @param pkt pointer to packet before calling ff_reshuffle_raw_rgb()
  * @param ret return value from ff_reshuffle_raw_rgb(), or 0
+ * @param palette pointer to pointer, which will be NULL if no palette found
  */
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette);
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t **palette);
 
 #endif /* AVFORMAT_INTERNAL_H */
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 85702dd..e66abcc 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4782,18 +4782,26 @@ int ff_standardize_creation_time(AVFormatContext *s)
 return ret;
 }
 
-int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, const uint8_t **palette)
+int ff_get_packet_palette(AVFormatContext *s, AVPacket *pkt, int ret, uint32_t **palette)
 {
 int size;
 
-*palette = av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, );
+*palette = (uint32_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, );
 if (*palette && size != AVPALETTE_SIZE) {
 av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
 return AVERROR_INVALIDDATA;
 }
 
-if (!*palette && ret == CONTAINS_PAL)
-*palette = pkt->data + pkt->size - AVPALETTE_SIZE;
+if (!*palette && ret == CONTAINS_PAL) {
+uint8_t *pkt_pal = pkt->data + pkt->size - AVPALETTE_SIZE;
+int i;
+for (i = 0; i < AVPALETTE_COUNT; i++) {
+uint8_t *p8 = pkt_pal + 4*i;
+uint32_t *p32 = (uint32_t *)p8;
+*p32 = AV_RL32(p8);
+}
+*palette = (uint32_t *)pkt_pal;
+}
 
 return 0;
 }
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v6 2/4] lavf/movenc: Add support for palette side data

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 74f08a740f1afd402aef8c460d696f16f209c8f8 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 02:56:41 +0100
Subject: [PATCH v6 2/4] lavf/movenc: Add support for palette side data

---
 libavformat/movenc.c |   47 ---
 1 file changed, 28 insertions(+), 19 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 3295266..c80a150 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1716,14 +1716,15 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
 else
 avio_wb16(pb, 0x18); /* Reserved */
 
-if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+if (track->mode == MODE_MOV && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
+int pal_size = 1 << track->enc->bits_per_coded_sample;
 int i;
 avio_wb16(pb, 0); /* Color table ID */
 avio_wb32(pb, 0); /* Color table seed */
 avio_wb16(pb, 0x8000);/* Color table flags */
-avio_wb16(pb, 255);   /* Color table size (zero-relative) */
-for (i = 0; i < 256; i++) {
-uint32_t rgb = AV_RL32(>palette[i]);
+avio_wb16(pb, pal_size - 1);  /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
+uint32_t rgb = track->palette[i];
 uint16_t r = (rgb >> 16) & 0xff;
 uint16_t g = (rgb >> 8)  & 0xff;
 uint16_t b = rgb & 0xff;
@@ -4763,21 +4764,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (trk->is_unaligned_qt_rgb) {
-const uint8_t *data = pkt->data;
-int size = pkt->size;
-int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
-int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
-int ret = ff_reshuffle_raw_rgb(s, , trk->enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret == CONTAINS_PAL && !trk->pal_done) {
-int pal_size = 1 << trk->enc->bits_per_coded_sample;
-memset(trk->palette, 0, AVPALETTE_SIZE);
-memcpy(trk->palette, data + size - 4*pal_size, 4*pal_size);
-trk->pal_done++;
-} else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
-   trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
+if (trk->mode == MODE_MOV && trk->enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+AVPacket *opkt = pkt;
+int ret;
+if (trk->is_unaligned_qt_rgb) {
+int64_t bpc = trk->enc->bits_per_coded_sample != 15 ? trk->enc->bits_per_coded_sample : 16;
+int expected_stride = ((trk->enc->width * bpc + 15) >> 4)*2;
+ret = ff_reshuffle_raw_rgb(s, , trk->enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (trk->enc->pix_fmt == AV_PIX_FMT_PAL8 && !trk->pal_done) {
+uint32_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, );
+if (ret2 < 0)
+return ret2;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
+} else if (trk->enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
+   (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
+   trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK)) {
 for (i = 0; i < pkt->size; i++)
 pkt->data[i] = ~pkt->data[i];
 }
-- 
1.7.10.4

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

[FFmpeg-devel] PATCH v6 3/4] lavf/riffenc: Handle palette for non-raw codecs

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From d27c865e1bf7969339e7ce9f442faebfdb8fa700 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 02:57:11 +0100
Subject: [PATCH v6 3/4] lavf/riffenc: Handle palette for non-raw codecs

---
 libavformat/riffenc.c |   20 +++-
 1 file changed, 11 insertions(+), 9 deletions(-)

diff --git a/libavformat/riffenc.c b/libavformat/riffenc.c
index 1dd7971..195a58e 100644
--- a/libavformat/riffenc.c
+++ b/libavformat/riffenc.c
@@ -209,12 +209,17 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 int keep_height = enc->extradata_size >= 9 &&
   !memcmp(enc->extradata + enc->extradata_size - 9, "BottomUp", 9);
 int extradata_size = enc->extradata_size - 9*keep_height;
-int raw_pal_avi;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
+int pal_avi;
 
-raw_pal_avi = !for_asf && enc->codec_id == AV_CODEC_ID_RAWVIDEO &&
-  !enc->codec_tag &&
-enc->bits_per_coded_sample >= 1 && enc->bits_per_coded_sample <= 8;
-if (!enc->extradata_size && raw_pal_avi)
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+pal_avi = !for_asf &&
+  (pix_fmt == AV_PIX_FMT_PAL8 ||
+   pix_fmt == AV_PIX_FMT_MONOWHITE ||
+   pix_fmt == AV_PIX_FMT_MONOBLACK);
+
+if (!enc->extradata_size && pal_avi)
 extradata_size = 4 * (1 << enc->bits_per_coded_sample);
 
 /* size */
@@ -239,11 +244,8 @@ void ff_put_bmp_header(AVIOContext *pb, AVCodecContext *enc,
 avio_write(pb, enc->extradata, extradata_size);
 if (!for_asf && extradata_size & 1)
 avio_w8(pb, 0);
-} else if (raw_pal_avi) {
+} else if (pal_avi) {
 int i;
-enum AVPixelFormat pix_fmt = enc->pix_fmt;
-if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
-pix_fmt = AV_PIX_FMT_MONOWHITE;
 for (i = 0; i < 1 << enc->bits_per_coded_sample; i++) {
 /* Initialize 1 bpp palette to black & white */
 if (i == 0 && pix_fmt == AV_PIX_FMT_MONOWHITE)
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH v6 1/4] lavf/avienc: Add support for palette side data

[Mats Peterson]

This version of the patch set returns to using a pointer to a pointer to 
the palette in ff_get_packet_palette(), rather than the slightly more 
expensive behaviour of using memcpy().


As before, it normalizes the palette in AVPacket.data to native endian, 
since that's the most logical and natural way of handling the palette in 
a muxer in my book, and we need a common denominator.


Please try stream copy to and from avi/mov with the files below. Also 
try -vcodec rawvideo.


QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0

QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc

Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From f4a25fbe82ec9fe44f001a39f4eef6a20fc91555 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Fri, 4 Mar 2016 02:56:26 +0100
Subject: [PATCH v6 1/4] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   56 --
 1 file changed, 36 insertions(+), 20 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..ad90537 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -74,12 +74,12 @@ typedef struct AVIStream {
 int max_size;
 int sample_requested;
 
-int64_t pal_offset;
-int hdr_pal_done;
-
 int64_t last_dts;
 
 AVIIndex indexes;
+
+int64_t hdr_pal_offset;
+int hdr_pal_done;
 } AVIStream;
 
 static int avi_write_packet_internal(AVFormatContext *s, AVPacket *pkt);
@@ -362,7 +362,8 @@ static int avi_write_header(AVFormatContext *s)
 && enc->pix_fmt == AV_PIX_FMT_RGB555LE
 && enc->bits_per_coded_sample == 15)
 enc->bits_per_coded_sample = 16;
-avist->pal_offset = avio_tell(pb) + 40;
+if (pb->seekable)
+avist->hdr_pal_offset = avio_tell(pb) + 40;
 ff_put_bmp_header(pb, enc, ff_codec_bmp_tags, 0, 0);
 pix_fmt = avpriv_find_pix_fmt(avpriv_pix_fmt_bps_avi,
   enc->bits_per_coded_sample);
@@ -652,11 +653,11 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 {
 unsigned char tag[5];
 const int stream_index = pkt->stream_index;
-const uint8_t *data= pkt->data;
-int size   = pkt->size;
 AVIOContext *pb = s->pb;
 AVCodecContext *enc = s->streams[stream_index]->codec;
 AVIStream *avist= s->streams[stream_index]->priv_data;
+AVPacket *opkt = pkt;
+enum AVPixelFormat pix_fmt = enc->pix_fmt;
 int ret;
 
 if (enc->codec_id == AV_CODEC_ID_H264 && enc->codec_tag == MKTAG('H','2','6','4') && pkt->size) {
@@ -668,22 +669,35 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 if ((ret = write_skip_frames(s, stream_index, pkt->dts)) < 0)
 return ret;
 
-if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
-int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
-int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
-ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
-if (ret < 0)
-return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
+if (!pkt->size)
+return avi_write_packet_internal(s, pkt); /* Passthrough */
+
+if (enc->codec_type == AVMEDIA_TYPE_VIDEO) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0) {
+int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
+int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
+if (ret < 0)
+return ret;
+} else
+ret = 0;
+if (pix_fmt == AV_PIX_FMT_NONE && enc->bits_per_coded_sample == 1)
+pix_fmt = AV_PIX_FMT_MONOWHITE;
+if (pix_fmt == AV_PIX_FMT_PAL8 ||
+pix_fmt == AV_PIX_FMT_MONOWHITE ||
+pix_fmt == AV_PIX_FMT_MONOBLACK) {
+uint32_t *pal;
+int ret2 = ff_get_packet_palette(s, opkt, ret, );
+if (ret2 < 0)
+return ret2;
+if (pal) {
 int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
+int pc_tag, i;
+if (pb->seekable && !avist->hdr_pal_done) {
 int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+avio_seek(pb, avist->hdr_pal_offset, SEEK_SET);
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = 

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timothy Gu  gmail.com> writes:

> Of course, this argument operates on the premise that 
> making things easier for users is of utmost concern 
> for us. Please inspire me if this is not the case.

On the contrary, I believe while the current versioing 
scheme is simple and understandable, the suggested one 
is misleading, both for users and when reading user 
questions.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timothy Gu]

On Thu, Mar 03, 2016 at 11:04:09PM +, Carl Eugen Hoyos wrote:
> Timo Rothenpieler  rothenpieler.org> writes:
> 
> > So instead of
> > 
> > N-78885-g966eade
> 
> The continuous numbering scheme is very convenient when 
> answering user questions and it reflects very well the 
> (past and current) development model of FFmpeg that is 
> not release-driven ...

Do I understand correctly that FFmpeg in the future will not version releases
backwards? If that is the case, then the "continuous" bit is a nonissue.

The argument on development model is unrelated to discussion.

> 
> > 
> > One now gets
> > 
> > n3.1-dev-422-g966eade
> 
> ... while I personally find this slightly ugly.

Users seem to disagree. One example of such a complaint is
http://willus.com/author/ffmpegbmark.shtml:

**I continue to be frustrated** with the nightly-build ffmpeg version
numbering. . . . It would be nice if the nightly builds gave some
indication of what major and minor version release they are related to,
even if it's a snapshot build. A version number like N-46936-g8b6aeb1 is
**meaningless to me (and to most other users, I imagine)**. Why is this so
hard? This is where avconv.exe does much better, giving a more
intelligible version number like v9_beta2-255-gb9629ac.

(some emphasis is mine)

Using the version also comes with other advantages. It is now a lot easier to
check if a certain feature is available in a build by looking at the Changelog
(which records release versions, not N-based revision numbers).

Of course, this argument operates on the premise that making things easier for
users is of utmost concern for us. Please inspire me if this is not the case.

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

[FFmpeg-devel] [PATCH] avcodec: Extend fft to size 2^17

[Michael Niedermayer]

Hi

patch to extend fft is attached (my git-send email atm doesnt work
thanks to my ISP)

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates
From 8a60f2587e2a57be475fc2afc01fa2ade178eda5 Mon Sep 17 00:00:00 2001
From: Michael Niedermayer 
Date: Fri, 4 Mar 2016 00:31:45 +0100
Subject: [PATCH] avcodec: Extend fft to size 2^17

Asked-for-by: durandal_1707

Signed-off-by: Michael Niedermayer 
---
 libavcodec/fft.h|3 +-
 libavcodec/fft_init_table.c |  386 ---
 libavcodec/fft_table.h  |2 +-
 libavcodec/fft_template.c   |9 +-
 libavcodec/mips/fft_mips.c  |2 +-
 5 files changed, 267 insertions(+), 135 deletions(-)

diff --git a/libavcodec/fft.h b/libavcodec/fft.h
index 64f0f63..60df239 100644
--- a/libavcodec/fft.h
+++ b/libavcodec/fft.h
@@ -134,7 +134,8 @@ extern COSTABLE(8192);
 extern COSTABLE(16384);
 extern COSTABLE(32768);
 extern COSTABLE(65536);
-extern COSTABLE_CONST FFTSample* const FFT_NAME(ff_cos_tabs)[17];
+extern COSTABLE(131072);
+extern COSTABLE_CONST FFTSample* const FFT_NAME(ff_cos_tabs)[18];
 
 #define ff_init_ff_cos_tabs FFT_NAME(ff_init_ff_cos_tabs)
 
diff --git a/libavcodec/fft_init_table.c b/libavcodec/fft_init_table.c
index 4d74f8a..c488018 100644
--- a/libavcodec/fft_init_table.c
+++ b/libavcodec/fft_init_table.c
@@ -54,137 +54,265 @@
 #include "libavcodec/fft_table.h"
 
 const int32_t ff_w_tab_sr[MAX_FFT_SIZE/(4*16)] = {
-2147483647, 2147481121, 2147473542, 2147460908, 2147443222, 2147420483, 2147392690, 2147359845,
-2147321946, 2147278995, 2147230991, 2147177934, 2147119825, 2147056664, 2146988450, 2146915184,
-2146836866, 2146753497, 2146665076, 2146571603, 2146473080, 2146369505, 2146260881, 2146147205,
-2146028480, 2145904705, 2145775880, 2145642006, 2145503083, 2145359112, 2145210092, 2145056025,
-2144896910, 2144732748, 2144563539, 2144389283, 2144209982, 2144025635, 2143836244, 2143641807,
-2143442326, 2143237802, 2143028234, 2142813624, 2142593971, 2142369276, 2142139541, 2141904764,
-2141664948, 2141420092, 2141170197, 2140915264, 2140655293, 2140390284, 2140120240, 2139845159,
-2139565043, 2139279892, 2138989708, 2138694490, 2138394240, 2138088958, 2137778644, 2137463301,
-2137142927, 2136817525, 2136487095, 2136151637, 2135811153, 2135465642, 2135115107, 2134759548,
-2134398966, 2134033361, 2133662734, 2133287087, 2132906420, 2132520734, 2132130030, 2131734309,
-2131333572, 2130927819, 2130517052, 2130101272, 2129680480, 2129254676, 2128823862, 2128388038,
-2127947206, 2127501367, 2127050522, 2126594672, 2126133817, 2125667960, 2125197100, 2124721240,
-2124240380, 2123754522, 2123263666, 2122767814, 2122266967, 2121761126, 2121250292, 2120734467,
-2120213651, 2119687847, 2119157054, 2118621275, 2118080511, 2117534762, 2116984031, 2116428319,
-2115867626, 2115301954, 2114731305, 2114155680, 2113575080, 2112989506, 2112398960, 2111803444,
-2111202959, 2110597505, 2109987085, 2109371700, 2108751352, 2108126041, 2107495770, 2106860540,
-2106220352, 2105575208, 2104925109, 2104270057, 2103610054, 2102945101, 2102275199, 2101600350,
-2100920556, 2100235819, 2099546139, 2098851519, 2098151960, 2097447464, 2096738032, 2096023667,
-2095304370, 2094580142, 2093850985, 2093116901, 2092377892, 2091633960, 2090885105, 2090131331,
-2089372638, 2088609029, 2087840505, 2087067068, 2086288720, 2085505463, 2084717298, 2083924228,
-2083126254, 2082323379, 2081515603, 2080702930, 2079885360, 2079062896, 2078235540, 2077403294,
-2076566160, 2075724139, 2074877233, 2074025446, 2073168777, 2072307231, 2071440808, 2070569511,
-2069693342, 2068812302, 2067926394, 2067035621, 2066139983, 2065239484, 2064334124, 2063423908,
-2062508835, 2061588910, 2060664133, 2059734508, 2058800036, 2057860719, 2056916560, 2055967560,
-2055013723, 2054055050, 2053091544, 2052123207, 2051150040, 2050172048, 2049189231, 2048201592,
-2047209133, 2046211857, 2045209767, 2044202863, 2043191150, 2042174628, 2041153301, 2040127172,
-2039096241, 2038060512, 2037019988, 2035974670, 2034924562, 2033869665, 2032809982, 2031745516,
-2030676269, 2029602243, 2028523442, 2027439867, 2026351522, 2025258408, 2024160529, 2023057887,
-2021950484, 2020838323, 2019721407, 2018599739, 2017473321, 2016342155, 2015206245, 2014065592,
-2012920201, 2011770073, 2010615210, 2009455617, 2008291295, 2007122248, 2005948478, 2004769987,
-2003586779, 2002398857, 2001206222, 208879, 1998806829, 1997600076, 1996388622, 1995172471,
-1993951625, 1992726087, 1991495860, 1990260946, 1989021350, 198073, 1986528118, 1985274489,
-1984016189, 1982753220, 1981485585, 1980213288, 1978936331, 1977654717, 1976368450, 1975077532,
-1973781967, 1972481757, 1971176906, 

Re: [FFmpeg-devel] Libavcodec consulting

[compn]

On Thu, 3 Mar 2016 12:11:25 +
Jonathan Girven  wrote:

> Hi all,

Hi , i'm not a consultant , but i maybe can help clarify a thing.

> The requirements are:
> 
> - The file is hosted on a remote http server.
> 
> - The original file is in mp4 format.
>
> - The code cannot read in the entire remote video file to get a
> segment at the end of the file.

the mp4 format can either have an index at the start of the file or
at the end of the file. you cannot read (easily) an mp4 file without its
index.

http://wiki.multimedia.cx/index.php?title=MP4

http servers can be made to support "request range" and thus allow
seeking to the start or end of the mp4 file. existing mp4 files can be
edited to have the index at the start or end.

otherwise, mp4 cannot be streamed. by anyone, in any situation (well,
without serious hacks). the current way mp4 is "streamed" is to
split up mp4 files into a thousand smaller mp4 files and sent to a
player using a playlist.

mp4 cannot be streamed. it sucks.
changing the http server would be easier than changing mp4 indexing.
or using an intermediate format would be easier (mkv perhaps).

hope this helps

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

On Thu, Mar 3, 2016 at 11:20 PM, Timo Rothenpieler
 wrote:
>> Accessing a remote URL in the version script seems like a bad idea to me.
>
> I aggree, but I'm unsure how to propperly address the issue.
> The problem is that a plain "git pull" does not update tags,
> so if you have an older clone you allways updated via git pull, you end
> up with a version number based on an older tag.
>

I don't know what your Git is doing, but fetch and pull automatically
grab the appropriate tags for me.

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

Re: [FFmpeg-devel] Regression maybe

[Hendrik Leppkes]

On Thu, Mar 3, 2016 at 11:23 PM, JULIAN GARDNER  wrote:
> But regressions are development problems, things like "how do i scale a 
> video" is for users.
> Im going tobe bisecting and fixing code if needed, so surely this is 
> development!
>  Joolz

Then open an issue on trac, thats what an issue tracker is for. Once
someone comes up with a potential fix, we can discuss it here.

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Carl Eugen Hoyos]

Timo Rothenpieler  rothenpieler.org> writes:

> So instead of
> 
> N-78885-g966eade

The continuous numbering scheme is very convenient when 
answering user questions and it reflects very well the 
(past and current) development model of FFmpeg that is 
not release-driven ...

> 
> One now gets
> 
> n3.1-dev-422-g966eade

... while I personally find this slightly ugly.

Please don't change the versioning system, Carl Eugen

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

Re: [FFmpeg-devel] How to specify AV_OPT_TYPE_DICT type options on command line

[Thilo Borgmann]

> I'm trying to pass an option into a new filter of type AV_OPT_TYPE_DICT.

Just found out it is not (yet) allowed in lavu/opt.c.

Sticking with STRING argument for now initializing a local AVDictionary.

Maybe this is of interest for someone else, too.

-Thilo

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

Re: [FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

> Accessing a remote URL in the version script seems like a bad idea to me.

I aggree, but I'm unsure how to propperly address the issue.
The problem is that a plain "git pull" does not update tags,
so if you have an older clone you allways updated via git pull, you end
up with a version number based on an older tag.

The idea behind that fetch command is to fail silently after taking a
maximum of 10 seconds to download the latest tags.

libav (and a lot of other project aswell) just ignores that issue and
uses a plain git describe --tags --always.

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



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

Re: [FFmpeg-devel] Regression maybe

[JULIAN GARDNER]

But regressions are development problems, things like "how do i scale a video" 
is for users.
Im going tobe bisecting and fixing code if needed, so surely this is 
development!
 Joolz 

On Thursday, 3 March 2016, 23:05, Moritz Barsnick  wrote:
 
 

 Hi Julian,

On Thu, Mar 03, 2016 at 18:43:11 +, JULIAN GARDNER wrote:
> I was going to bisect it and see if i can find a commit which breaks the 
> mpegts output?, but what commit do I start on for 63057
[...]
> ffmpeg version N-78734-g666e2ed Copyright (c) 2000-2016 the FFmpeg developers
                          ^^^
This is the (short) commit hash for the version used. Do you not see
that in the output of "63057"? Let me "guess" 63504d8. I can't actually
find that on github, but it's from around Aug 14 2014, which can also
be specified for "git bisect" (I think).

BTW, this sort if discussion is a topic for the ffmpeg-user mailing
list. ffmpeg-devel is related to the actual development of ffmpeg.

Cheer,
Moritz
___
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] version.sh: Always use latest tag for generated version number

[Hendrik Leppkes]

Am 03.03.2016 22:46 schrieb "Timo Rothenpieler" :
>
> The version numbers based on the 15 years old N tag are confusing and
> don't offer a lot of information about what release the version is close
> to.
>
> This patch stops using the N tag and always bases it on the most recent
> dev tag instead. So instead of
>
> N-78885-g966eade
>
> One now gets
>
> n3.1-dev-422-g966eade
>
> Which offers a lot more informational value to users and developers.
> ---
>  version.sh | 9 -
>  1 file changed, 4 insertions(+), 5 deletions(-)
>
> diff --git a/version.sh b/version.sh
> index a9d7e39..1c3faf1 100755
> --- a/version.sh
> +++ b/version.sh
> @@ -4,11 +4,10 @@
>
>  # check for git short hash
>  if ! test "$revision"; then
> -if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
> -revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
> -else
> -revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
> -fi
> +# Optional fetch to make sure latest tags are present
> +(cd "$1" && timeout 10 git fetch --quiet "
https://git.videolan.org/git/ffmpeg.git; "refs/tags/*:refs/tags/*" >
/dev/null 2>&1)
> +
> +revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
>  fi
>
>  # Shallow Git clones (--depth) do not have the N tag:
> --

Accessing a remote URL in the version script seems like a bad idea to me.

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

Re: [FFmpeg-devel] Regression maybe

[Moritz Barsnick]

Hi Julian,

On Thu, Mar 03, 2016 at 18:43:11 +, JULIAN GARDNER wrote:
> I was going to bisect it and see if i can find a commit which breaks the 
> mpegts output?, but what commit do I start on for 63057
[...]
> ffmpeg version N-78734-g666e2ed Copyright (c) 2000-2016 the FFmpeg developers
  ^^^
This is the (short) commit hash for the version used. Do you not see
that in the output of "63057"? Let me "guess" 63504d8. I can't actually
find that on github, but it's from around Aug 14 2014, which can also
be specified for "git bisect" (I think).

BTW, this sort if discussion is a topic for the ffmpeg-user mailing
list. ffmpeg-devel is related to the actual development of ffmpeg.

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

[FFmpeg-devel] [PATCH] version.sh: Always use latest tag for generated version number

[Timo Rothenpieler]

The version numbers based on the 15 years old N tag are confusing and
don't offer a lot of information about what release the version is close
to.

This patch stops using the N tag and always bases it on the most recent
dev tag instead. So instead of

N-78885-g966eade

One now gets

n3.1-dev-422-g966eade

Which offers a lot more informational value to users and developers.
---
 version.sh | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/version.sh b/version.sh
index a9d7e39..1c3faf1 100755
--- a/version.sh
+++ b/version.sh
@@ -4,11 +4,10 @@
 
 # check for git short hash
 if ! test "$revision"; then
-if (cd "$1" && grep git RELEASE 2> /dev/null >/dev/null) ; then
-revision=$(cd "$1" && git describe --tags --match N 2> /dev/null)
-else
-revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
-fi
+# Optional fetch to make sure latest tags are present
+(cd "$1" && timeout 10 git fetch --quiet 
"https://git.videolan.org/git/ffmpeg.git; "refs/tags/*:refs/tags/*" > /dev/null 
2>&1)
+
+revision=$(cd "$1" && git describe --tags --always 2> /dev/null)
 fi
 
 # Shallow Git clones (--depth) do not have the N tag:
-- 
2.7.1

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

[FFmpeg-devel] How to specify AV_OPT_TYPE_DICT type options on command line

[Thilo Borgmann]

Hi,

I'm trying to pass an option into a new filter of type AV_OPT_TYPE_DICT.

After compilation I wonder how to specify this dictionary via the
command line...

ffmpeg -i in.avi -vf filter=opt_of_type_dict=??? out.avi

Grep reveals no other filter using the dict type for an input option.
Anyone knows or at least can point me to where it is handled in the code?

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

Re: [FFmpeg-devel] [PATCH] web/contact: Fix link.

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 07:32:39PM +0100, Simon Thelen wrote:
> On 16-03-03 at 14:09, Michael Niedermayer wrote:
> > On Thu, Mar 03, 2016 at 12:57:45PM +0100, Simon Thelen wrote:
> > > Signed-off-by: Simon Thelen 
> > > ---
> > >  src/contact | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/src/contact b/src/contact
> > > index 077f9ca..22c1e11 100644
> > > --- a/src/contact
> > > +++ b/src/contact
> > > @@ -154,6 +154,6 @@
> > >
> > >   > > href="http://ffmpeg.zeranoe.com/forum/;>FFmpeg on Windows
> > >   
> > > - > > href="http://ffmpeg.gusari.org/;>FFmpeg Support Forum
> > > + > > href="http://ffmpeg.gusari.org/index.php;>FFmpeg Support Forum
> > 
> > i can apply this but shouldnt ffmpeg.gusari.org/ be fixed to redirect
> > to that ?
> Probably, but I don't know how to get in contact with someone who can do
> that. There's already a post on the forum about it [1]. Plus linking
> directly to index.php isn't wrong, and it's better than having the link
> semi-404.
> 
> [1]: http://ffmpeg.gusari.org/viewtopic.php?f=3=2706

applied

thx

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

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH] lavf/matroskadec: Add early support for colour elements

[Neil Birkbeck]

I've attached a slightly cleaner (more isolated) patch that moves the
parsing into a helper function.

On Mon, Feb 29, 2016 at 5:15 PM, Neil Birkbeck  wrote:
> Adding early support for a subset of the proposed colour elements
> according to the latest version of spec:
> https://mailarchive.ietf.org/arch/search/?email_list=cellar=1=hIKLhMdgTMTEwUTeA4ct38h0tmE
>
> I've left out elements for pix_fmt related things as there still
> seems to be some discussion around these, and the max_cll/max_fall
> are currently not propagated as there is not yet side data for them.
>
> The new elements are exposed under strict experimental mode.
>
> Signed-off-by: Neil Birkbeck 
> ---
>  libavformat/matroska.h|  28 ++
>  libavformat/matroskadec.c | 136 
> ++
>  2 files changed, 164 insertions(+)
>
> diff --git a/libavformat/matroska.h b/libavformat/matroska.h
> index a654e0c..e97fe6b 100644
> --- a/libavformat/matroska.h
> +++ b/libavformat/matroska.h
> @@ -123,6 +123,34 @@
>  #define MATROSKA_ID_VIDEOALPHAMODE 0x53C0
>  #define MATROSKA_ID_VIDEOASPECTRATIO 0x54B3
>  #define MATROSKA_ID_VIDEOCOLORSPACE 0x2EB524
> +#define MATROSKA_ID_VIDEOCOLOR 0x55B0
> +
> +#define MATROSKA_ID_VIDEOCOLORMATRIXCOEFF 0x55B1
> +#define MATROSKA_ID_VIDEOCOLORBITSPERCHANNEL 0x55B2
> +#define MATROSKA_ID_VIDEOCOLORCHROMASUBHORZ 0x55B3
> +#define MATROSKA_ID_VIDEOCOLORCHROMASUBVERT 0x55B4
> +#define MATROSKA_ID_VIDEOCOLORCBSUBHORZ 0x55B5
> +#define MATROSKA_ID_VIDEOCOLORCBSUBVERT 0x55B6
> +#define MATROSKA_ID_VIDEOCOLORCHROMASITINGHORZ 0x55B7
> +#define MATROSKA_ID_VIDEOCOLORCHROMASITINGVERT 0x55B8
> +#define MATROSKA_ID_VIDEOCOLORRANGE 0x55B9
> +#define MATROSKA_ID_VIDEOCOLORTRANSFERCHARACTERISTICS 0x55BA
> +
> +#define MATROSKA_ID_VIDEOCOLORPRIMARIES 0x55BB
> +#define MATROSKA_ID_VIDEOCOLORMAXCLL 0x55BC
> +#define MATROSKA_ID_VIDEOCOLORMAXFALL 0x55BD
> +
> +#define MATROSKA_ID_VIDEOCOLORMASTERINGMETA 0x55D0
> +#define MATROSKA_ID_VIDEOCOLOR_RX 0x55D1
> +#define MATROSKA_ID_VIDEOCOLOR_RY 0x55D2
> +#define MATROSKA_ID_VIDEOCOLOR_GX 0x55D3
> +#define MATROSKA_ID_VIDEOCOLOR_GY 0x55D4
> +#define MATROSKA_ID_VIDEOCOLOR_BX 0x55D5
> +#define MATROSKA_ID_VIDEOCOLOR_BY 0x55D6
> +#define MATROSKA_ID_VIDEOCOLOR_WHITEX 0x55D7
> +#define MATROSKA_ID_VIDEOCOLOR_WHITEY 0x55D8
> +#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMAX 0x55D9
> +#define MATROSKA_ID_VIDEOCOLOR_LUMINANCEMIN 0x55DA
>
>  /* IDs in the trackaudio master */
>  #define MATROSKA_ID_AUDIOSAMPLINGFREQ 0xB5
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d20568c..4510e8e 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -39,6 +39,7 @@
>  #include "libavutil/intfloat.h"
>  #include "libavutil/intreadwrite.h"
>  #include "libavutil/lzo.h"
> +#include "libavutil/mastering_display_metadata.h"
>  #include "libavutil/mathematics.h"
>  #include "libavutil/opt.h"
>  #include "libavutil/time_internal.h"
> @@ -130,6 +131,36 @@ typedef struct MatroskaTrackEncoding {
>  MatroskaTrackEncryption encryption;
>  } MatroskaTrackEncoding;
>
> +typedef struct MatroskaMasteringMeta {
> +double r_x;
> +double r_y;
> +double g_x;
> +double g_y;
> +double b_x;
> +double b_y;
> +double white_x;
> +double white_y;
> +double max_luminance;
> +double min_luminance;
> +} MatroskaMasteringMeta;
> +
> +typedef struct MatroskaTrackVideoColor {
> +uint64_t matrix_coefficients;
> +uint64_t bits_per_channel;
> +uint64_t chroma_sub_horz;
> +uint64_t chroma_sub_vert;
> +uint64_t cb_sub_horz;
> +uint64_t cb_sub_vert;
> +uint64_t chroma_siting_horz;
> +uint64_t chroma_siting_vert;
> +uint64_t range;
> +uint64_t transfer_characteristics;
> +uint64_t primaries;
> +uint64_t max_cll;
> +uint64_t max_fall;
> +MatroskaMasteringMeta mastering_meta;
> +} MatroskaTrackVideoColor;
> +
>  typedef struct MatroskaTrackVideo {
>  double   frame_rate;
>  uint64_t display_width;
> @@ -139,6 +170,7 @@ typedef struct MatroskaTrackVideo {
>  EbmlBin color_space;
>  uint64_t stereo_mode;
>  uint64_t alpha_mode;
> +MatroskaTrackVideoColor color;
>  } MatroskaTrackVideo;
>
>  typedef struct MatroskaTrackAudio {
> @@ -356,6 +388,36 @@ static const EbmlSyntax matroska_info[] = {
>  { 0 }
>  };
>
> +static const EbmlSyntax matroska_mastering_meta[] = {
> +{ MATROSKA_ID_VIDEOCOLOR_RX, EBML_FLOAT, 0, 
> offsetof(MatroskaMasteringMeta, r_x), { .f=-1 } },
> +{ MATROSKA_ID_VIDEOCOLOR_RY, EBML_FLOAT, 0, 
> offsetof(MatroskaMasteringMeta, r_y), { .f=-1 } },
> +{ MATROSKA_ID_VIDEOCOLOR_GX, EBML_FLOAT, 0, 
> offsetof(MatroskaMasteringMeta, g_x), { .f=-1 } },
> +{ MATROSKA_ID_VIDEOCOLOR_GY, EBML_FLOAT, 0, 
> offsetof(MatroskaMasteringMeta, g_y), { .f=-1 } },
> +{ MATROSKA_ID_VIDEOCOLOR_BX, EBML_FLOAT, 0, 
> offsetof(MatroskaMasteringMeta, b_x), { .f=-1 } },
> +{ 

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 10:01:28AM -0800, NagaChaitanya Vellanki wrote:
> ---
>  libavutil/Makefile |   1 +
>  libavutil/color_utils.c|  29 +
>  tests/fate/libavutil.mak   |   4 +
>  tests/ref/fate/color_utils | 285 
> +
>  4 files changed, 319 insertions(+)
>  create mode 100644 tests/ref/fate/color_utils
> 
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index a4d79cd..934564f 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -176,6 +176,7 @@ TESTPROGS = adler32   
>   \
>  bprint  \
>  cast5   \
>  camellia\
> +color_utils \
>  cpu \
>  crc \
>  des \
> diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
> index b68b402..0bb7e3d 100644
> --- a/libavutil/color_utils.c
> +++ b/libavutil/color_utils.c
> @@ -21,6 +21,7 @@
>  #include 
>  #include 
>  
> +#include "common.h"
>  #include "libavutil/color_utils.h"
>  #include "libavutil/pixfmt.h"
>  
> @@ -216,3 +217,31 @@ avpriv_trc_function 
> avpriv_get_trc_function_from_trc(enum AVColorTransferCharact
>  }
>  return func;
>  }
> +
> +#ifdef TEST
> +// LCOV_EXCL_START
> +
> +int main(int argc, char *argv[])
> +{
> +  int i, j;
> +  double test_data[] = {

should have been static const
but ill change that


> +  -0.1, -0.018053968510807, -0.01, -0.00449, 0.0, 0.00316227760, 0.005,
> +  0.009, 0.015, 0.1, 1.0, 52.37, 125.098765, 1999.11123, 6945.443,
> +  15123.4567, 19845.88923, 98678.4231, 9.88
> +  };
> +
> +  for(i = 0; i < AVCOL_TRC_NB; i++) {
> +  avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
> +  for(j = 0; j < FF_ARRAY_ELEMS(test_data); j++) {
> +  if(func != NULL) {
> +  double result = func(test_data[j]);
> +  printf("AVColorTransferCharacteristic=%d calling func(%f) 
> expected=%f\n",
> + i, test_data[j], result);
> +  }
> +  }
> +  }

tested on mips and arm qemu as well as mingw, seems working everywhere
ill apply it
if it is later found to fail somewhere (like msvc) reducing the
number of digits printed likely should fix it
we have thousands of float compares like this in fate already ...

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] avformat/udp: Add a delay between packets for streaming to clients with short buffer

[Nicolas George]

Le primidi 11 ventôse, an CCXXIV, Pavel Nikiforov a écrit :
> Hello !
> 
> This patch enables background sending of UDP packets with specified delay.
> When sending packets without a delay some devices with small RX buffer
> ( MAG200 STB, for example) will drop tail packets in burst causing
> decoding errors.
> 
> It needs to specify "fifo_size" with "packet_gap" .
> 
> The output url will looks like udp://xxx:yyy?fifo_size= size>_gap=
> 
> Patch attached.

Thanks for the patch. Comments below.

>  libavformat/udp.c | 133 
> --
>  1 file changed, 129 insertions(+), 4 deletions(-)

Missing documentation update.

> 
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index ea80e52..ff676f4 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -92,6 +92,7 @@ typedef struct UDPContext {
>  int circular_buffer_size;
>  AVFifoBuffer *fifo;
>  int circular_buffer_error;
> +int packet_gap; /* delay between transmitted packets */
>  #if HAVE_PTHREAD_CANCEL
>  pthread_t circular_buffer_thread;
>  pthread_mutex_t mutex;
> @@ -112,6 +113,7 @@ typedef struct UDPContext {
>  #define E AV_OPT_FLAG_ENCODING_PARAM
>  static const AVOption options[] = {
>  { "buffer_size","System data size (in bytes)", 
> OFFSET(buffer_size),AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> .flags = D|E },

> +{ "packet_gap", "Delay between packets, in usec",  
> OFFSET(packet_gap), AV_OPT_TYPE_INT,{ .i64 = 0  }, 0, INT_MAX, 
> .flags = E },

As pointed by Michael, this should use AV_OPT_TYPE_DURATION.

>  { "localport",  "Local port",  
> OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> D|E },
>  { "local_port", "Local port",  
> OFFSET(local_port), AV_OPT_TYPE_INT,{ .i64 = -1 },-1, INT_MAX, 
> .flags = D|E },
>  { "localaddr",  "Local address",   
> OFFSET(localaddr),  AV_OPT_TYPE_STRING, { .str = NULL },   
> .flags = D|E },
> @@ -486,7 +488,7 @@ static int udp_get_file_handle(URLContext *h)
>  }
>  
>  #if HAVE_PTHREAD_CANCEL
> -static void *circular_buffer_task( void *_URLContext)
> +static void *circular_buffer_task_rx( void *_URLContext)
>  {
>  URLContext *h = _URLContext;
>  UDPContext *s = h->priv_data;
> @@ -499,7 +501,7 @@ static void *circular_buffer_task( void *_URLContext)
>  s->circular_buffer_error = AVERROR(EIO);
>  goto end;
>  }

> -while(1) {
> +for(;;) {

Stray change.

>  int len;
>  
>  pthread_mutex_unlock(>mutex);
> @@ -542,6 +544,81 @@ end:
>  pthread_mutex_unlock(>mutex);
>  return NULL;
>  }
> +
> +static void do_udp_write(void *arg, void *buf, int size) {
> +URLContext *h = arg;
> +UDPContext *s = h->priv_data;
> +
> +int ret;
> +

> +if (!(h->flags & AVIO_FLAG_NONBLOCK)) {

This looks suspicious: blocking/nonblocking is a property of the protocol as
seen by the calling application, it should not apply in a thread used
internally. See below.

> +ret = ff_network_wait_fd(s->udp_fd, 1);
> +if (ret < 0) {

> +s->circular_buffer_error=ret;

Please keep in line with surrounding coding style. In this instance: spaces
around operators.

> +return;
> +}
> +}
> +
> +if (!s->is_connected) {

> +ret = sendto (s->udp_fd, buf, size, 0,
> +  (struct sockaddr *) >dest_addr,

Style: no spaces after function names and casts.

> +  s->dest_addr_len);
> +} else
> +ret = send(s->udp_fd, buf, size, 0);
> +
> +s->circular_buffer_error=ret;
> +}
> +
> +static void *circular_buffer_task_tx( void *_URLContext)
> +{
> +URLContext *h = _URLContext;
> +UDPContext *s = h->priv_data;
> +int old_cancelstate;
> +
> +pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
> +
> +for(;;) {
> +int len;
> +uint8_t tmp[4];
> +
> +pthread_setcancelstate(PTHREAD_CANCEL_ENABLE, _cancelstate);
> +

> +av_usleep(s->packet_gap);

Not very reliable: if the task gets unscheduled for some time, it will be
added to the gap and never catch, possibly causing playback hiccups. A
system with a kind of rate control would probably be better.

> +
> +pthread_setcancelstate(PTHREAD_CANCEL_DISABLE, _cancelstate);
> +
> +pthread_mutex_lock(>mutex);
> +
> +len=av_fifo_size(s->fifo);
> +
> +while (len<4) {
> +if (pthread_cond_wait(>cond, >mutex) < 0) {
> +goto end;
> +}
> +len=av_fifo_size(s->fifo);
> +}
> +
> +av_fifo_generic_peek(s->fifo, tmp, 4, NULL);
> +len=AV_RL32(tmp);
> +

> +if (len>0 && av_fifo_size(s->fifo)>=len) {

len + 4

> +

Re: [FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 05:18:03PM +, Derek Buitenhuis wrote:
> Signed-off-by: Derek Buitenhuis 
> ---
> This matches API with Libav, in a forthcoming merge, using our
> exisiting infastructure code.
> 
> CC'd Michael, since he wrote the whitelisting code.
> 
> This has been tested with FATE.
> ---
>  Changelog |  1 +
>  doc/APIchanges|  3 +++
>  libavformat/async.c   |  2 +-
>  libavformat/avformat.h|  7 +++
>  libavformat/avidec.c  |  2 +-
>  libavformat/avio.c| 22 --
>  libavformat/avio.h|  5 +
>  libavformat/avio_internal.h   |  2 +-
>  libavformat/aviobuf.c | 13 +
>  libavformat/cache.c   |  2 +-
>  libavformat/concat.c  |  2 +-
>  libavformat/concatdec.c   |  2 +-
>  libavformat/crypto.c  |  2 +-
>  libavformat/ftp.c |  4 ++--
>  libavformat/gopher.c  |  2 +-
>  libavformat/hls.c |  2 +-
>  libavformat/hlsproto.c|  4 ++--
>  libavformat/http.c|  6 +++---
>  libavformat/icecast.c |  2 +-
>  libavformat/internal.h|  2 +-
>  libavformat/md5proto.c|  2 +-
>  libavformat/mmst.c|  2 +-
>  libavformat/mpeg.c|  2 +-
>  libavformat/options.c |  2 +-
>  libavformat/options_table.h   |  1 +
>  libavformat/rdt.c |  2 +-
>  libavformat/rtmpcrypt.c   |  2 +-
>  libavformat/rtmpproto.c   |  4 ++--
>  libavformat/rtpdec_asf.c  |  2 +-
>  libavformat/rtpproto.c|  6 +++---
>  libavformat/rtsp.c| 10 +-
>  libavformat/rtspdec.c |  4 ++--
>  libavformat/sapdec.c  |  4 ++--
>  libavformat/sapenc.c  |  4 ++--
>  libavformat/smoothstreamingenc.c  |  8 
>  libavformat/srtpproto.c   |  2 +-
>  libavformat/subfile.c |  2 +-
>  libavformat/tls.c |  2 +-
>  libavformat/tls_securetransport.c |  2 +-
>  libavformat/url.h |  3 ++-
>  libavformat/utils.c   | 19 +++
>  libavformat/version.h |  4 ++--
>  42 files changed, 114 insertions(+), 62 deletions(-)
> 
> diff --git a/Changelog b/Changelog
> index d6459a8..0e70724 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -10,6 +10,7 @@ version :
>  - datascope filter
>  - bench and abench filters
>  - ciescope filter
> +- protocol blacklisting API
>  
>  
>  version 3.0:
> diff --git a/doc/APIchanges b/doc/APIchanges
> index a75f346..2fc6a71 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2016-XX-XX - xxx - lavf 57.28.100
> +  Add protocol blacklisting API
> +
>  2016-02-28 - xxx - lavc 57.27.101
>Validate AVFrame returned by get_buffer2 to have required
>planes not NULL and unused planes set to NULL as crashes
> diff --git a/libavformat/async.c b/libavformat/async.c
> index a835292..0cc6fb0 100644
> --- a/libavformat/async.c
> +++ b/libavformat/async.c
> @@ -251,7 +251,7 @@ static int async_open(URLContext *h, const char *arg, int 
> flags, AVDictionary **
>  
>  /* wrap interrupt callback */
>  c->interrupt_callback = h->interrupt_callback;
> -ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
> options, h->protocol_whitelist);
> +ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
> options, h->protocol_whitelist, h->protocol_blacklist);
>  if (ret != 0) {
>  av_log(h, AV_LOG_ERROR, "ffurl_open failed : %s, %s\n", 
> av_err2str(ret), arg);
>  goto url_fail;

> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index b843a4b..b133575 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -1838,6 +1838,13 @@ typedef struct AVFormatContext {
>   */
>  char *protocol_whitelist;
>  
> +/**
> + * ',' separated list of disallowed protocols.
> + * - encoding: unused
> + * - decoding: set by user through AVOptions (NO direct access)
> + */
> +char *protocol_blacklist;
> +
>  /*
>   * A callback for opening new IO streams.
>   *

The io_open/close callbacks afterwards seem direct access IIUC
so its not possible to remove or add any fields prior

though maybe they have been added so recently that its ok to move
them above all "no direct access" fields
or maybe iam missing something

otherwise no objections from me



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

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


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

Derek,
I agree with you, checked this on ubuntu, mac os both x86_32, x86_64.

On Thu, Mar 3, 2016 at 10:11 AM, Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote:
> > +  printf("AVColorTransferCharacteristic=%d calling func(%f)
> expected=%f\n",
> > + i, test_data[j], result);
>
> Comparing floats exactly probably isn't a great idea, since
> floating point implementations differ between architectures.
>
> - Derek
> ___
> 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] Add test for avpriv_get_trc_function_from_trc function

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 06:11:19PM +, Derek Buitenhuis wrote:
> On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote:
> > +  printf("AVColorTransferCharacteristic=%d calling func(%f) 
> > expected=%f\n",
> > + i, test_data[j], result);
> 
> Comparing floats exactly probably isn't a great idea, since
> floating point implementations differ between architectures.

it should be ok if the number of digits printed after the decimal
point are not too many

ill try to test if this works on what i have easy access to

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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

[FFmpeg-devel] Regression maybe

[JULIAN GARDNER]

OK I upgraded a server today from 63057 to 78734 as we had a problem with 
dvbsubtitles not working. 

Now the machines, 2 of them one on 63057 and the new one, dont transcode and 
they have the same command lines like this.
ffmpeg -i http://1.1.1.1:1/Stream1.ts -c:v copy -c:a copy -f mpegts 
udp://225.1.1.1:1?pkt_size=1316
These pull in streams from a remote server and push the data into a 
professional playout server, Edgeware WTV-2X
Now the streams pulled and sent out to the Edgeware with software 63067 are OK, 
the streams sent out from 78734 are not accepted and made available by the 
Edgeware.
Anyone have any ideas or seen this behaviour in later versions as the 
transcoder is remote and has NOT been updated.

I was going to bisect it and see if i can find a commit which breaks the mpegts 
output?, but what commit do I start on for 63057
Joolz
ffmpeg version N-78734-g666e2ed Copyright (c) 2000-2016 the FFmpeg developers
  built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.1)
  configuration: --bindir=/home/encoder/bin --enable-gpl --enable-version3 
--enable-nonfree --disable-ffserver --disable-dxva2 --disable-vaapi 
--disable-vda --disable-vdpau --disable-libxcb --enable-libmp3lame 
--enable-postproc --enable-libfaac --enable-libzvbi --enable-libx264 
--enable-libx265 --cc='ccache cc'
  libavutil  55. 19.100 / 55. 19.100
  libavcodec 57. 25.101 / 57. 25.101
  libavformat    57. 26.100 / 57. 26.100
  libavdevice    57.  0.101 / 57.  0.101
  libavfilter 6. 36.100 /  6. 36.100
  libswscale  4.  0.100 /  4.  0.100
  libswresample   2.  0.101 /  2.  0.101
  libpostproc    54.  0.100 / 54.  0.100
Input #0, mpegts, from 'http://1.1.1.1:1/stream1.ts':
  Duration: N/A, start: 28.109333, bitrate: N/A
  Program 1
    Metadata:
  service_name    : Stream 1
  service_provider: v-play
    Stream #0:0[0x100]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p, 
544x576 [SAR 32:17 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
    Stream #0:1[0x101](eng): Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 
48000 Hz, stereo, fltp, 52 kb/s
Output #0, mpegts, to 
'udp://225.170.111.224:1234?pkt_size=1316_size=1048576':
  Metadata:
    encoder : Lavf57.26.100
    Stream #0:0: Video: h264 ([27][0][0][0] / 0x001B), yuv420p, 544x576 [SAR 
32:17 DAR 16:9], q=2-31, 25 fps, 25 tbr, 90k tbn, 90k tbc
    Stream #0:1(eng): Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 48000 Hz, 
stereo, 52 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (copy)
  Stream #0:1 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame=  323 fps= 69 q=-1.0 Lsize=    1299kB time=00:00:15.37 bitrate= 
692.4kbits/s speed=3.28x
video:1082kB audio:88kB subtitle:0kB other streams:0kB global headers:0kB 
muxing overhead: 11.022727%
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/contact: Fix link.

[Simon Thelen]

On 16-03-03 at 14:09, Michael Niedermayer wrote:
> On Thu, Mar 03, 2016 at 12:57:45PM +0100, Simon Thelen wrote:
> > Signed-off-by: Simon Thelen 
> > ---
> >  src/contact | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/src/contact b/src/contact
> > index 077f9ca..22c1e11 100644
> > --- a/src/contact
> > +++ b/src/contact
> > @@ -154,6 +154,6 @@
> >
> >   > href="http://ffmpeg.zeranoe.com/forum/;>FFmpeg on Windows
> >   
> > - > href="http://ffmpeg.gusari.org/;>FFmpeg Support Forum
> > + > href="http://ffmpeg.gusari.org/index.php;>FFmpeg Support Forum
> 
> i can apply this but shouldnt ffmpeg.gusari.org/ be fixed to redirect
> to that ?
Probably, but I don't know how to get in contact with someone who can do
that. There's already a post on the forum about it [1]. Plus linking
directly to index.php isn't wrong, and it's better than having the link
semi-404.

[1]: http://ffmpeg.gusari.org/viewtopic.php?f=3=2706

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

Re: [FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[Derek Buitenhuis]

On 3/3/2016 6:01 PM, NagaChaitanya Vellanki wrote:
> +  printf("AVColorTransferCharacteristic=%d calling func(%f) 
> expected=%f\n",
> + i, test_data[j], result);

Comparing floats exactly probably isn't a great idea, since
floating point implementations differ between architectures.

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

[FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

---
 libavutil/Makefile |   1 +
 libavutil/color_utils.c|  29 +
 tests/fate/libavutil.mak   |   4 +
 tests/ref/fate/color_utils | 285 +
 4 files changed, 319 insertions(+)
 create mode 100644 tests/ref/fate/color_utils

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32 
\
 bprint  \
 cast5   \
 camellia\
+color_utils \
 cpu \
 crc \
 des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..0bb7e3d 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "common.h"
 #include "libavutil/color_utils.h"
 #include "libavutil/pixfmt.h"
 
@@ -216,3 +217,31 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 }
 return func;
 }
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+  int i, j;
+  double test_data[] = {
+  -0.1, -0.018053968510807, -0.01, -0.00449, 0.0, 0.00316227760, 0.005,
+  0.009, 0.015, 0.1, 1.0, 52.37, 125.098765, 1999.11123, 6945.443,
+  15123.4567, 19845.88923, 98678.4231, 9.88
+  };
+
+  for(i = 0; i < AVCOL_TRC_NB; i++) {
+  avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
+  for(j = 0; j < FF_ARRAY_ELEMS(test_data); j++) {
+  if(func != NULL) {
+  double result = func(test_data[j]);
+  printf("AVColorTransferCharacteristic=%d calling func(%f) 
expected=%f\n",
+ i, test_data[j], result);
+  }
+  }
+  }
+
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 022ae6a..a89bc1d 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -48,6 +48,10 @@ FATE_LIBAVUTIL += fate-crc
 fate-crc: libavutil/crc-test$(EXESUF)
 fate-crc: CMD = run libavutil/crc-test
 
+FATE_LIBAVUTIL += fate-color_utils
+fate-color_utils: libavutil/color_utils-test$(EXESUF)
+fate-color_utils: CMD = run libavutil/color_utils-test
+
 FATE_LIBAVUTIL += fate-des
 fate-des: libavutil/des-test$(EXESUF)
 fate-des: CMD = run libavutil/des-test
diff --git a/tests/ref/fate/color_utils b/tests/ref/fate/color_utils
new file mode 100644
index 000..6e80ebd
--- /dev/null
+++ b/tests/ref/fate/color_utils
@@ -0,0 +1,285 @@
+AVColorTransferCharacteristic=1 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.003162) expected=0.014230
+AVColorTransferCharacteristic=1 calling func(0.005000) expected=0.022500
+AVColorTransferCharacteristic=1 calling func(0.009000) expected=0.040500
+AVColorTransferCharacteristic=1 calling func(0.015000) expected=0.067500
+AVColorTransferCharacteristic=1 calling func(0.10) expected=0.290748
+AVColorTransferCharacteristic=1 calling func(1.00) expected=1.00
+AVColorTransferCharacteristic=1 calling func(52.37) expected=6.427531
+AVColorTransferCharacteristic=1 calling func(125.098765) expected=9.558517
+AVColorTransferCharacteristic=1 calling func(1999.111230) expected=33.512490
+AVColorTransferCharacteristic=1 calling func(6945.443000) expected=58.768794
+AVColorTransferCharacteristic=1 calling func(15123.456700) expected=83.452916
+AVColorTransferCharacteristic=1 calling func(19845.889230) expected=94.321297
+AVColorTransferCharacteristic=1 calling func(98678.423100) expected=194.219568
+AVColorTransferCharacteristic=1 calling func(9.88) expected=195.386306
+AVColorTransferCharacteristic=4 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.003162) expected=0.073053
+AVColorTransferCharacteristic=4 calling func(0.005000) expected=0.089966
+AVColorTransferCharacteristic=4 calling func(0.009000) expected=0.117520

[FFmpeg-devel] [PATCH] Add test for avpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

Please ignore my previous patches. 
The commit message was incorrectly formatted. Please consider this patch.

NagaChaitanya Vellanki (1):
  Add test for avpriv_get_trc_function_from_trc function

 libavutil/Makefile |   1 +
 libavutil/color_utils.c|  29 +
 tests/fate/libavutil.mak   |   4 +
 tests/ref/fate/color_utils | 285 +
 4 files changed, 319 insertions(+)
 create mode 100644 tests/ref/fate/color_utils

-- 
2.5.0

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

[FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

From: NagaChaitanya Vellanki 

---
 libavutil/Makefile |   1 +
 libavutil/color_utils.c|  29 +
 tests/fate/libavutil.mak   |   4 +
 tests/ref/fate/color_utils | 285 +
 4 files changed, 319 insertions(+)
 create mode 100644 tests/ref/fate/color_utils

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32 
\
 bprint  \
 cast5   \
 camellia\
+color_utils \
 cpu \
 crc \
 des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..0bb7e3d 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "common.h"
 #include "libavutil/color_utils.h"
 #include "libavutil/pixfmt.h"
 
@@ -216,3 +217,31 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 }
 return func;
 }
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+  int i, j;
+  double test_data[] = {
+  -0.1, -0.018053968510807, -0.01, -0.00449, 0.0, 0.00316227760, 0.005,
+  0.009, 0.015, 0.1, 1.0, 52.37, 125.098765, 1999.11123, 6945.443,
+  15123.4567, 19845.88923, 98678.4231, 9.88
+  };
+
+  for(i = 0; i < AVCOL_TRC_NB; i++) {
+  avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
+  for(j = 0; j < FF_ARRAY_ELEMS(test_data); j++) {
+  if(func != NULL) {
+  double result = func(test_data[j]);
+  printf("AVColorTransferCharacteristic=%d calling func(%f) 
expected=%f\n",
+ i, test_data[j], result);
+  }
+  }
+  }
+
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 022ae6a..a89bc1d 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -48,6 +48,10 @@ FATE_LIBAVUTIL += fate-crc
 fate-crc: libavutil/crc-test$(EXESUF)
 fate-crc: CMD = run libavutil/crc-test
 
+FATE_LIBAVUTIL += fate-color_utils
+fate-color_utils: libavutil/color_utils-test$(EXESUF)
+fate-color_utils: CMD = run libavutil/color_utils-test
+
 FATE_LIBAVUTIL += fate-des
 fate-des: libavutil/des-test$(EXESUF)
 fate-des: CMD = run libavutil/des-test
diff --git a/tests/ref/fate/color_utils b/tests/ref/fate/color_utils
new file mode 100644
index 000..6e80ebd
--- /dev/null
+++ b/tests/ref/fate/color_utils
@@ -0,0 +1,285 @@
+AVColorTransferCharacteristic=1 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.003162) expected=0.014230
+AVColorTransferCharacteristic=1 calling func(0.005000) expected=0.022500
+AVColorTransferCharacteristic=1 calling func(0.009000) expected=0.040500
+AVColorTransferCharacteristic=1 calling func(0.015000) expected=0.067500
+AVColorTransferCharacteristic=1 calling func(0.10) expected=0.290748
+AVColorTransferCharacteristic=1 calling func(1.00) expected=1.00
+AVColorTransferCharacteristic=1 calling func(52.37) expected=6.427531
+AVColorTransferCharacteristic=1 calling func(125.098765) expected=9.558517
+AVColorTransferCharacteristic=1 calling func(1999.111230) expected=33.512490
+AVColorTransferCharacteristic=1 calling func(6945.443000) expected=58.768794
+AVColorTransferCharacteristic=1 calling func(15123.456700) expected=83.452916
+AVColorTransferCharacteristic=1 calling func(19845.889230) expected=94.321297
+AVColorTransferCharacteristic=1 calling func(98678.423100) expected=194.219568
+AVColorTransferCharacteristic=1 calling func(9.88) expected=195.386306
+AVColorTransferCharacteristic=4 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.003162) expected=0.073053
+AVColorTransferCharacteristic=4 calling func(0.005000) expected=0.089966
+AVColorTransferCharacteristic=4 

[FFmpeg-devel] [PATCH] Add test foravpriv_get_trc_function_from_trc function

[NagaChaitanya Vellanki]

---
 libavutil/Makefile |   1 +
 libavutil/color_utils.c|  29 +
 tests/fate/libavutil.mak   |   4 +
 tests/ref/fate/color_utils | 285 +
 4 files changed, 319 insertions(+)
 create mode 100644 tests/ref/fate/color_utils

diff --git a/libavutil/Makefile b/libavutil/Makefile
index a4d79cd..934564f 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -176,6 +176,7 @@ TESTPROGS = adler32 
\
 bprint  \
 cast5   \
 camellia\
+color_utils \
 cpu \
 crc \
 des \
diff --git a/libavutil/color_utils.c b/libavutil/color_utils.c
index b68b402..0bb7e3d 100644
--- a/libavutil/color_utils.c
+++ b/libavutil/color_utils.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "common.h"
 #include "libavutil/color_utils.h"
 #include "libavutil/pixfmt.h"
 
@@ -216,3 +217,31 @@ avpriv_trc_function avpriv_get_trc_function_from_trc(enum 
AVColorTransferCharact
 }
 return func;
 }
+
+#ifdef TEST
+// LCOV_EXCL_START
+
+int main(int argc, char *argv[])
+{
+  int i, j;
+  double test_data[] = {
+  -0.1, -0.018053968510807, -0.01, -0.00449, 0.0, 0.00316227760, 0.005,
+  0.009, 0.015, 0.1, 1.0, 52.37, 125.098765, 1999.11123, 6945.443,
+  15123.4567, 19845.88923, 98678.4231, 9.88
+  };
+
+  for(i = 0; i < AVCOL_TRC_NB; i++) {
+  avpriv_trc_function func = avpriv_get_trc_function_from_trc(i);
+  for(j = 0; j < FF_ARRAY_ELEMS(test_data); j++) {
+  if(func != NULL) {
+  double result = func(test_data[j]);
+  printf("AVColorTransferCharacteristic=%d calling func(%f) 
expected=%f\n",
+ i, test_data[j], result);
+  }
+  }
+  }
+
+}
+
+// LCOV_EXCL_STOP
+#endif
diff --git a/tests/fate/libavutil.mak b/tests/fate/libavutil.mak
index 022ae6a..a89bc1d 100644
--- a/tests/fate/libavutil.mak
+++ b/tests/fate/libavutil.mak
@@ -48,6 +48,10 @@ FATE_LIBAVUTIL += fate-crc
 fate-crc: libavutil/crc-test$(EXESUF)
 fate-crc: CMD = run libavutil/crc-test
 
+FATE_LIBAVUTIL += fate-color_utils
+fate-color_utils: libavutil/color_utils-test$(EXESUF)
+fate-color_utils: CMD = run libavutil/color_utils-test
+
 FATE_LIBAVUTIL += fate-des
 fate-des: libavutil/des-test$(EXESUF)
 fate-des: CMD = run libavutil/des-test
diff --git a/tests/ref/fate/color_utils b/tests/ref/fate/color_utils
new file mode 100644
index 000..6e80ebd
--- /dev/null
+++ b/tests/ref/fate/color_utils
@@ -0,0 +1,285 @@
+AVColorTransferCharacteristic=1 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=1 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=1 calling func(0.003162) expected=0.014230
+AVColorTransferCharacteristic=1 calling func(0.005000) expected=0.022500
+AVColorTransferCharacteristic=1 calling func(0.009000) expected=0.040500
+AVColorTransferCharacteristic=1 calling func(0.015000) expected=0.067500
+AVColorTransferCharacteristic=1 calling func(0.10) expected=0.290748
+AVColorTransferCharacteristic=1 calling func(1.00) expected=1.00
+AVColorTransferCharacteristic=1 calling func(52.37) expected=6.427531
+AVColorTransferCharacteristic=1 calling func(125.098765) expected=9.558517
+AVColorTransferCharacteristic=1 calling func(1999.111230) expected=33.512490
+AVColorTransferCharacteristic=1 calling func(6945.443000) expected=58.768794
+AVColorTransferCharacteristic=1 calling func(15123.456700) expected=83.452916
+AVColorTransferCharacteristic=1 calling func(19845.889230) expected=94.321297
+AVColorTransferCharacteristic=1 calling func(98678.423100) expected=194.219568
+AVColorTransferCharacteristic=1 calling func(9.88) expected=195.386306
+AVColorTransferCharacteristic=4 calling func(-0.10) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.018054) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.01) expected=0.00
+AVColorTransferCharacteristic=4 calling func(-0.004490) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.00) expected=0.00
+AVColorTransferCharacteristic=4 calling func(0.003162) expected=0.073053
+AVColorTransferCharacteristic=4 calling func(0.005000) expected=0.089966
+AVColorTransferCharacteristic=4 calling func(0.009000) expected=0.117520

Re: [FFmpeg-devel] [PATCH 1/2] configure: build fix for mips cpu p5600

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 07:26:56PM +0530, shivraj.pa...@imgtec.com wrote:
> From: Shivraj Patil 
> 
> Signed-off-by: Shivraj Patil 
> ---
>  configure |  217 
> -
>  1 file changed, 101 insertions(+), 116 deletions(-)

[...]

> +if [ "$cpu" == "generic" ]; then

../configure: 4188: [: generic: unexpected operator


> +# the unwanted features.
> +echo 'generic CPU selected'
> +else
> +disable mipsfpu
> +disable mips32r2
> +disable mips32r5
> +disable mips64r2
> +disable mips32r6
> +disable mips64r6
> +disable mipsdsp
> +disable mipsdspr2
> +disable msa
> +disable loongson2
> +disable loongson3
> +disable mmi
> +
> +case $cpu in
> +24kc)
> +enable mips32r2
> +;;
> +24kf*)
> +enable mips32r2
> +enable mipsfpu
> +;;
> +24kec|34kc|1004kc)
> +enable mips32r2
> +enable mipsdsp
> +;;
> +24kef*|34kf*|1004kf*)
> +enable mips32r2
> +enable mipsfpu
> +enable mipsdsp
> +;;
> +74kc)
> +enable mips32r2
> +enable mipsdsp
> +enable mipsdspr2
> +;;
> +74kf)
> +enable mips32r2
> +enable mipsfpu
> +enable mipsdsp
> +enable mipsdspr2

breaks --cpu=74kf --disable-mipsfpu

also is this (from configure) correct?

mipsfpu_deps="mips"
mipsdsp_deps="mips"
mipsdspr2_deps="mips"
mips32r2_deps="mips"
mips32r6_deps="mips"
mips64r2_deps="mips"
mips64r6_deps="mips"
msa_deps="mips"
mmi_deps="mips"

there is no dependancy betwen features ?
so a cpu can have mips32r6 without mips32r2 ?
if that is not possible then the dependancies should be corrected

if mips32r6 would depend on mips32r2 then only disabling the later
would be sufficient

That assumes no code uses mips32r6 and has sideefects before the
dependancy solver is run (thats quite plausibly not true atm)

also the feature checks look hackish
for example:
if enabled msa; then
check_ldflags "-mfp64 -mmsa" &&
add_cflags "-mfp64 -mmsa" &&
add_asflags "-mfp64 -mmsa" &&
check_inline_asm msa '"addvi.b $w0, $w1, 1"' &&
check_header msa.h ||
disable msa
fi
else

this adds all kinds of flags and _AFTER_ that tests the instruction
if it isnt supported msa is disabled but all the flags are left in
there

the outcome should either be msa on and needed flags in OR
msa off and no flags added IIUC
the same issue exists with other mips features too 

if check_inline_asm doesnt work for mips then maybe a
check_inline_asm_flags or something could be added that tests
asm with flags and does the whole on / off atomically without
poluting the various flags in the failure case
quite possibly there are other solutions/options ...

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

[FFmpeg-devel] [PATCH] avformat: Add a protocol blacklisting API

[Derek Buitenhuis]

Signed-off-by: Derek Buitenhuis 
---
This matches API with Libav, in a forthcoming merge, using our
exisiting infastructure code.

CC'd Michael, since he wrote the whitelisting code.

This has been tested with FATE.
---
 Changelog |  1 +
 doc/APIchanges|  3 +++
 libavformat/async.c   |  2 +-
 libavformat/avformat.h|  7 +++
 libavformat/avidec.c  |  2 +-
 libavformat/avio.c| 22 --
 libavformat/avio.h|  5 +
 libavformat/avio_internal.h   |  2 +-
 libavformat/aviobuf.c | 13 +
 libavformat/cache.c   |  2 +-
 libavformat/concat.c  |  2 +-
 libavformat/concatdec.c   |  2 +-
 libavformat/crypto.c  |  2 +-
 libavformat/ftp.c |  4 ++--
 libavformat/gopher.c  |  2 +-
 libavformat/hls.c |  2 +-
 libavformat/hlsproto.c|  4 ++--
 libavformat/http.c|  6 +++---
 libavformat/icecast.c |  2 +-
 libavformat/internal.h|  2 +-
 libavformat/md5proto.c|  2 +-
 libavformat/mmst.c|  2 +-
 libavformat/mpeg.c|  2 +-
 libavformat/options.c |  2 +-
 libavformat/options_table.h   |  1 +
 libavformat/rdt.c |  2 +-
 libavformat/rtmpcrypt.c   |  2 +-
 libavformat/rtmpproto.c   |  4 ++--
 libavformat/rtpdec_asf.c  |  2 +-
 libavformat/rtpproto.c|  6 +++---
 libavformat/rtsp.c| 10 +-
 libavformat/rtspdec.c |  4 ++--
 libavformat/sapdec.c  |  4 ++--
 libavformat/sapenc.c  |  4 ++--
 libavformat/smoothstreamingenc.c  |  8 
 libavformat/srtpproto.c   |  2 +-
 libavformat/subfile.c |  2 +-
 libavformat/tls.c |  2 +-
 libavformat/tls_securetransport.c |  2 +-
 libavformat/url.h |  3 ++-
 libavformat/utils.c   | 19 +++
 libavformat/version.h |  4 ++--
 42 files changed, 114 insertions(+), 62 deletions(-)

diff --git a/Changelog b/Changelog
index d6459a8..0e70724 100644
--- a/Changelog
+++ b/Changelog
@@ -10,6 +10,7 @@ version :
 - datascope filter
 - bench and abench filters
 - ciescope filter
+- protocol blacklisting API
 
 
 version 3.0:
diff --git a/doc/APIchanges b/doc/APIchanges
index a75f346..2fc6a71 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-XX-XX - xxx - lavf 57.28.100
+  Add protocol blacklisting API
+
 2016-02-28 - xxx - lavc 57.27.101
   Validate AVFrame returned by get_buffer2 to have required
   planes not NULL and unused planes set to NULL as crashes
diff --git a/libavformat/async.c b/libavformat/async.c
index a835292..0cc6fb0 100644
--- a/libavformat/async.c
+++ b/libavformat/async.c
@@ -251,7 +251,7 @@ static int async_open(URLContext *h, const char *arg, int 
flags, AVDictionary **
 
 /* wrap interrupt callback */
 c->interrupt_callback = h->interrupt_callback;
-ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
options, h->protocol_whitelist);
+ret = ffurl_open_whitelist(>inner, arg, flags, _callback, 
options, h->protocol_whitelist, h->protocol_blacklist);
 if (ret != 0) {
 av_log(h, AV_LOG_ERROR, "ffurl_open failed : %s, %s\n", 
av_err2str(ret), arg);
 goto url_fail;
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index b843a4b..b133575 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1838,6 +1838,13 @@ typedef struct AVFormatContext {
  */
 char *protocol_whitelist;
 
+/**
+ * ',' separated list of disallowed protocols.
+ * - encoding: unused
+ * - decoding: set by user through AVOptions (NO direct access)
+ */
+char *protocol_blacklist;
+
 /*
  * A callback for opening new IO streams.
  *
diff --git a/libavformat/avidec.c b/libavformat/avidec.c
index 3859810..eaf8421 100644
--- a/libavformat/avidec.c
+++ b/libavformat/avidec.c
@@ -1089,7 +1089,7 @@ static int read_gab2_sub(AVFormatContext *s, AVStream 
*st, AVPacket *pkt)
 
 ast->sub_ctx->pb = pb;
 
-if (ff_copy_whitelists(ast->sub_ctx, s) < 0)
+if (ff_copy_whiteblacklists(ast->sub_ctx, s) < 0)
 goto error;
 
 if (!avformat_open_input(>sub_ctx, "", sub_demuxer, NULL)) {
diff --git a/libavformat/avio.c b/libavformat/avio.c
index 69b6eaa..0be820b 100644
--- a/libavformat/avio.c
+++ b/libavformat/avio.c
@@ -55,6 +55,7 @@ static void *urlcontext_child_next(void *obj, void *prev)
 #define D AV_OPT_FLAG_DECODING_PARAM
 static const AVOption options[] = {
 {"protocol_whitelist", "List of protocols that are allowed to be used", 
OFFSET(protocol_whitelist), AV_OPT_TYPE_STRING, { .str = NULL },  CHAR_MIN, 
CHAR_MAX, D },

Re: [FFmpeg-devel] [PATCH] Check av_dup_packet() return code

[Michael Niedermayer]

On Wed, Feb 03, 2016 at 11:27:00PM +0100, Andreas Cadhalpun wrote:
> On 03.02.2016 19:05, Michael Niedermayer wrote:
> > Fixes: CID1338320
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/frame_thread_encoder.c |4 +++-
> >  1 file changed, 3 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/frame_thread_encoder.c 
> > b/libavcodec/frame_thread_encoder.c
> > index 04c9a0e..27ae356 100644
> > --- a/libavcodec/frame_thread_encoder.c
> > +++ b/libavcodec/frame_thread_encoder.c
> > @@ -89,7 +89,9 @@ static void * attribute_align_arg worker(void *v){
> >  pthread_mutex_unlock(>buffer_mutex);
> >  av_frame_free();
> >  if(got_packet) {
> > -av_dup_packet(pkt);
> > +int ret2 = av_dup_packet(pkt);
> > +if (ret >= 0 && ret2 < 0)
> > +ret = ret2;
> >  } else {
> >  pkt->data = NULL;
> >  pkt->size = 0;
> > 
> 
> Checking the return code this way is probably OK, but maybe you can also 
> replace the
> deprecated av_dup_packet with av_packet_ref while at it?

ill apply this patch in a few days if there are no objections
as noone suggested another solution

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH]configure: Check for msghdr struct

[Carl Eugen Hoyos]

Carl Eugen Hoyos  ag.or.at> writes:

> A user claims that not all (Solaris) systems have a sufficiently 
> new msghdr struct. Attached patch adds an additional check.

Ping.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH] fate: fix filter-hls tests dependencies

[James Almer]

On 3/3/2016 7:43 AM, Michael Niedermayer wrote:
> On Thu, Mar 03, 2016 at 12:55:55AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  tests/fate/filter-audio.mak| 15 +--
>>  tests/ref/fate/{filter-hls2 => filter-hls} |  0
>>  2 files changed, 9 insertions(+), 6 deletions(-)
>>  rename tests/ref/fate/{filter-hls2 => filter-hls} (100%)
> 
> LGTM
> 
> thx

Pushed

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

Re: [FFmpeg-devel] [PATCH 4/4] avcodec/dca: make reading past end of buffer safe

[foo86]

On Thu, Mar 03, 2016 at 12:56:42AM +0100, Hendrik Leppkes wrote:
> On Thu, Mar 3, 2016 at 12:37 AM, Ronald S. Bultje  wrote:
> > Completely random comment, but isn't it easier to just enable the safe
> > bitstream reader?
> >
> 
> This is actually enabled by default, so it probably should never have
> overread anywhere, but if the code can be made a bit safer in itself
> it probably does no harm either way.

Interesting. I assumed it was the opposite (safe bitstream reader
disabled by default). In this case the issue this patch addresses
doesn't seem to have as much impact as I initially thought.

But still I think it is a nice change to have since it makes code more
robust overall while not introducing significant performance penalty.
More importantly, it also gets rid of artificial limit on the length of
unary part of Rice codes, which may improve correctness of the decoder.

I'll change the commit message accordingly and resend the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 4/4] avcodec/dca: improve band data parsing robustness

[foo86]

Limit the maximum length of unary part of Rice code by the number of
available bits instead of using an arbitrary constant that happens to be
just large enough to work.

This effectively limits amount of data that can be overread per segment
by maximum length of binary code per sample multiplied by maximum
segment size.

Increase size of padding area after the end of input buffer according to
this limit and add some extra overread checks to make reading past end
of buffer safe even when internal overread checks are disabled in
bitstream reader code.
---
 libavcodec/dca_xll.c | 25 +++--
 libavcodec/dcadec.h  |  2 +-
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
index 5e6cf35..46bef3d 100644
--- a/libavcodec/dca_xll.c
+++ b/libavcodec/dca_xll.c
@@ -32,7 +32,7 @@ static int get_linear(GetBitContext *gb, int n)
 
 static int get_rice_un(GetBitContext *gb, int k)
 {
-unsigned int v = get_unary(gb, 1, 128);
+unsigned int v = get_unary(gb, 1, get_bits_left(gb));
 return (v << k) | get_bits_long(gb, k);
 }
 
@@ -512,7 +512,7 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
DCAXllChSet *c, int band, int s
 nsamples_part_b = s->nsegsamples - c->nsamples_part_a[k];
 
 if (get_bits_left(>gb) < 0)
-return AVERROR_INVALIDDATA;
+goto overread;
 
 if (!c->rice_code_flag[k]) {
 // Linear codes
@@ -534,6 +534,9 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
DCAXllChSet *c, int band, int s
 // Unpack the number of isolated samples
 int nisosamples = get_bits(>gb, s->nsegsamples_log2);
 
+if (get_bits_left(>gb) < nisosamples * s->nsegsamples_log2)
+goto overread;
+
 // Set all locations to 0
 memset(part_b, 0, sizeof(*part_b) * nsamples_part_b);
 
@@ -573,14 +576,14 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
DCAXllChSet *c, int band, int s
 // Start unpacking LSB portion of the segment
 if (b->lsb_section_size) {
 // Skip to the start of LSB portion
-if (ff_dca_seek_bits(>gb, band_data_end - b->lsb_section_size * 8)) 
{
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
-return AVERROR_INVALIDDATA;
-}
+if (ff_dca_seek_bits(>gb, band_data_end - b->lsb_section_size * 8))
+goto overread;
 
 // Unpack all LSB parts of residuals of this segment
 for (i = 0; i < c->nchannels; i++) {
 if (b->nscalablelsbs[i]) {
+if (get_bits_left(>gb) < 0)
+goto overread;
 get_array(>gb,
   b->lsb_sample_buffer[i] + seg * s->nsegsamples,
   s->nsegsamples, b->nscalablelsbs[i]);
@@ -589,12 +592,14 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
DCAXllChSet *c, int band, int s
 }
 
 // Skip to the end of band data
-if (ff_dca_seek_bits(>gb, band_data_end)) {
-av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
-return AVERROR_INVALIDDATA;
-}
+if (ff_dca_seek_bits(>gb, band_data_end))
+goto overread;
 
 return 0;
+
+overread:
+av_log(s->avctx, AV_LOG_ERROR, "Read past end of XLL band data\n");
+return AVERROR_INVALIDDATA;
 }
 
 static av_cold void chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, int 
band, int seg)
diff --git a/libavcodec/dcadec.h b/libavcodec/dcadec.h
index 6726121..2805a0e 100644
--- a/libavcodec/dcadec.h
+++ b/libavcodec/dcadec.h
@@ -32,7 +32,7 @@
 #include "dca_exss.h"
 #include "dca_xll.h"
 
-#define DCA_BUFFER_PADDING_SIZE 1024
+#define DCA_BUFFER_PADDING_SIZE 2048
 
 #define DCA_PACKET_CORE 0x01
 #define DCA_PACKET_EXSS 0x02
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCH v5 1/4] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/03/2016 02:13 PM, Mats Peterson wrote:

On 03/03/2016 12:34 AM, Mats Peterson wrote:

Hopefully this patch set will work on big-endian machines as well.
Please try stream copy to and from avi/mov with the files below:

QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0

QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc

Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE

Mats



I should add that there aren't many muxers (except nut, that simply
stores the whole packet, including palette, as a frame, as far as I
understand), that can use the little-endian format of AVPacket.data
directly for storage in the files. Not even AVI. The alpha byte has to
be zero, for example. And QuickTime uses 16-bit components. That's why
using native endian palette handling for the muxers is clearly the best
option.

Mats




That way of storing the palette as little endian in AVPacket.data is 
mostly done with nut in mind, I guess. In any case, that's not the 
natural way to handle the palette in a palette array in a muxer.


Mats

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

[FFmpeg-devel] [PATCH 2/2] configure: removed redundant condition check

[shivraj.patil]

From: Shivraj Patil 

Signed-off-by: Shivraj Patil 
---
 configure |   15 +--
 1 file changed, 5 insertions(+), 10 deletions(-)

diff --git a/configure b/configure
index 45d527a..3de6dcf 100755
--- a/configure
+++ b/configure
@@ -5091,15 +5091,13 @@ elif enabled mips; then
 add_asflags "-mips64r6" &&
 check_inline_asm mips64r6 '"dlsa $0, $0, $0, 1"' ||
 disable mips64r6
-fi
-if disabled mips64r6 && enabled mips64r2; then
+elif enabled mips64r2; then
 check_ldflags "-mips64r2" &&
 add_cflags "-mips64r2" &&
 add_asflags "-mips64r2" &&
 check_inline_asm mips64r2 '"dext $0, $0, 0, 1"' ||
 disable mips64r2
-fi
-if disabled mips64r6 && disabled mips64r2; then
+else
 check_ldflags "-mips64" &&
 add_cflags "-mips64" &&
 add_asflags "-mips64" &&
@@ -5113,22 +5111,19 @@ elif enabled mips; then
 add_asflags "-mips32r6" &&
 check_inline_asm mips32r6 '"aui $0, $0, 0"' ||
 disable mips32r6
-fi
-if disabled mips32r6 && enabled mips32r5; then
+elif enabled mips32r5; then
 check_ldflags "-mips32r5" &&
 add_cflags "-mips32r5" &&
 add_asflags "-mips32r5" &&
 check_inline_asm mips32r5 '"eretnc"' ||
 disable mips32r5
-fi
-if disabled mips32r6 && disabled mips32r5 && enabled mips32r2; then
+elif enabled mips32r2; then
 check_ldflags "-mips32r2" &&
 add_cflags "-mips32r2" &&
 add_asflags "-mips32r2" &&
 check_inline_asm mips32r2 '"ext $0, $0, 0, 1"' ||
 disable mips32r2
-fi
-if disabled mips32r6 && disabled mips32r5 && disabled mips32r2; then
+else
 check_ldflags "-mips32" &&
 add_cflags "-mips32" &&
 add_asflags "-mips32" &&
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] configure: build fix for mips cpu p5600

[shivraj.patil]

From: Shivraj Patil 

Signed-off-by: Shivraj Patil 
---
 configure |  217 -
 1 file changed, 101 insertions(+), 116 deletions(-)

diff --git a/configure b/configure
index 81769ee..45d527a 100755
--- a/configure
+++ b/configure
@@ -1662,6 +1662,7 @@ ARCH_EXT_LIST_ARM="
 ARCH_EXT_LIST_MIPS="
 mipsfpu
 mips32r2
+mips32r5
 mips64r2
 mips32r6
 mips64r6
@@ -2160,6 +2161,7 @@ mipsfpu_deps="mips"
 mipsdsp_deps="mips"
 mipsdspr2_deps="mips"
 mips32r2_deps="mips"
+mips32r5_deps="mips"
 mips32r6_deps="mips"
 mips64r2_deps="mips"
 mips64r6_deps="mips"
@@ -4183,119 +4185,95 @@ elif enabled mips; then
 
 cpuflags="-march=$cpu"
 
-case $cpu in
-24kc)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsfpu
-disable mipsdsp
-disable mipsdspr2
-disable msa
-;;
-24kf*)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsdsp
-disable mipsdspr2
-disable msa
-;;
-24kec|34kc|1004kc)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsfpu
-disable mipsdspr2
-disable msa
-;;
-24kef*|34kf*|1004kf*)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsdspr2
-disable msa
-;;
-74kc)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsfpu
-disable msa
-;;
-74kf)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable msa
-;;
-p5600)
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsdsp
-disable mipsdspr2
-check_cflags "-mtune=p5600" &&
-check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
-add_asflags "-mfp64"
-;;
-i6400)
-disable mips32r2
-disable mips32r6
-disable mips64r2
-disable mipsdsp
-disable mipsdspr2
-check_cflags "-mtune=i6400 -mabi=64" &&
-check_cflags "-mfp64 -msched-weight -mload-store-pairs 
-funroll-loops" &&
-check_ldflags "-mabi=64" &&
-add_asflags "-mfp64"
-;;
-loongson*)
-disable mips32r2
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsfpu
-disable mipsdsp
-disable mipsdspr2
-disable msa
-enable local_aligned_8 local_aligned_16 local_aligned_32
-enable simd_align_16
-enable fast_64bit
-enable fast_clz
-enable fast_cmov
-enable fast_unaligned
-disable aligned_stack
-case $cpu in
-loongson3*)
-cpuflags="-march=loongson3a -mhard-float 
-fno-expensive-optimizations"
-;;
-loongson2e)
-cpuflags="-march=loongson2e -mhard-float 
-fno-expensive-optimizations"
-;;
-loongson2f)
-cpuflags="-march=loongson2f -mhard-float 
-fno-expensive-optimizations"
-;;
-esac
-;;
-generic)
-# We do not disable anything. Is up to the user to disable
-# the unwanted features.
-;;
-*)
-# Unknown CPU. Disable everything.
-warn "unknown CPU. Disabling all MIPS optimizations."
-disable mipsfpu
-disable mips32r2
-disable mips32r6
-disable mips64r2
-disable mips64r6
-disable mipsdsp
-disable mipsdspr2
-disable msa
-;;
-esac
-
+if [ "$cpu" == "generic" ]; then
+# We do not disable anything. Is up to the user to disable
+# the unwanted features.
+echo 'generic CPU selected'
+else
+disable mipsfpu
+disable mips32r2
+disable mips32r5
+disable mips64r2
+disable mips32r6
+disable mips64r6
+disable mipsdsp
+disable mipsdspr2
+disable msa
+disable loongson2
+disable loongson3
+disable mmi
+
+case $cpu in
+24kc)
+enable mips32r2
+;;
+24kf*)
+enable mips32r2
+enable mipsfpu
+;;
+24kec|34kc|1004kc)
+enable mips32r2
+enable mipsdsp
+;;
+   

Re: [FFmpeg-devel] [PATCH v5 1/4] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/03/2016 12:34 AM, Mats Peterson wrote:

Hopefully this patch set will work on big-endian machines as well.
Please try stream copy to and from avi/mov with the files below:

QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0

QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc

Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE

Mats



I should add that there aren't many muxers (except nut, that simply 
stores the whole packet, including palette, as a frame, as far as I 
understand), that can use the little-endian format of AVPacket.data 
directly for storage in the files. Not even AVI. The alpha byte has to 
be zero, for example. And QuickTime uses 16-bit components. That's why 
using native endian palette handling for the muxers is clearly the best 
option.


Mats


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

Re: [FFmpeg-devel] [PATCH] web/contact: Fix link.

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:57:45PM +0100, Simon Thelen wrote:
> Signed-off-by: Simon Thelen 
> ---
>  src/contact | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/contact b/src/contact
> index 077f9ca..22c1e11 100644
> --- a/src/contact
> +++ b/src/contact
> @@ -154,6 +154,6 @@
>
>   href="http://ffmpeg.zeranoe.com/forum/;>FFmpeg on Windows
>   
> - href="http://ffmpeg.gusari.org/;>FFmpeg Support Forum
> + href="http://ffmpeg.gusari.org/index.php;>FFmpeg Support Forum

i can apply this but shouldnt ffmpeg.gusari.org/ be fixed to redirect
to that ?

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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/2] lavc: add h264 mediacodec decoder

[Matthieu Bouron]

On Wed, Mar 02, 2016 at 03:34:09PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 11:26:45PM +0100, Michael Niedermayer wrote:
> > On Tue, Mar 01, 2016 at 08:01:45PM +0100, Matthieu Bouron wrote:
> > > On Sat, Feb 27, 2016 at 04:28:43PM +0100, Michael Niedermayer wrote:
> > > > On Fri, Feb 26, 2016 at 04:54:47PM +0100, Matthieu Bouron wrote:
> > > > > On Tue, Feb 23, 2016 at 11:28:01AM +0100, wm4 wrote:
> > > > > > On Tue, 23 Feb 2016 09:53:43 +0100
> > > > > > Matthieu Bouron  wrote:
> > > > > > 
> > > > > > > On Mon, Feb 22, 2016 at 01:08:49PM +0100, Michael Niedermayer 
> > > > > > > wrote:
> > > > > > > > On Mon, Feb 22, 2016 at 12:20:36PM +0100, Matthieu Bouron 
> > > > > > > > wrote:  
> > > > > > > > > From: Matthieu Bouron   
> > > > > > > > [...]  
> > > > > > > > > +codec = (*env)->NewObject(env, 
> > > > > > > > > jfields.mediacodec_list_class, jfields.init_id, 0);
> > > > > > > > > +if (!codec) {
> > > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not create 
> > > > > > > > > media codec list\n");
> > > > > > > > > +goto done;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +tmp = (*env)->CallObjectMethod(env, codec, 
> > > > > > > > > jfields.find_decoder_for_format_id, format);
> > > > > > > > > +if (!tmp) {
> > > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not find 
> > > > > > > > > decoder in media codec list\n");
> > > > > > > > > +goto done;
> > > > > > > > > +}
> > > > > > > > > +
> > > > > > > > > +name = ff_jni_jstring_to_utf_chars(env, tmp, NULL);
> > > > > > > > > +if (!name) {  
> > > > > > > >   
> > > > > > > > > +av_log(NULL, AV_LOG_ERROR, "Could not convert 
> > > > > > > > > jstring to utf chars\n");  
> > > > > > > > 
> > > > > > > > some non NULL context would be better, if possible, so the user 
> > > > > > > > knows
> > > > > > > > where an error came from  
> > > > > > > 
> > > > > > > It would require to pass the log_ctx (avctx) as an argument of
> > > > > > > ff_AMediaCodecList_getCodecByName.
> > > > > > > 
> > > > > > > All the functions of this wrapper does not take a log_ctx as 
> > > > > > > argument
> > > > > > > to be as close as possible to the original NDK MediaCodec API. The
> > > > > > > NDK MediaCodec API does not provide any wrapper around 
> > > > > > > MediaCodecList.
> > > > > > > 
> > > > > > > I would like the whole wrapper API to be consistent but also as 
> > > > > > > close as
> > > > > > > possible to original one.
> > > > > > > If you think it's mandatory I can add a log_ctx argument to every
> > > > > > > functions of the wrapper API (so it will be used directly by 
> > > > > > > av_log and
> > > > > > > ff_jni_exception_check).
> > > > > > > 
> > > > > > > On another note, I fixed locally this part of the code by adding 
> > > > > > > missing calls
> > > > > > > to ff_jni_exception_check.
> > > > > > > 
> > > > > > > [...]
> > > > > > 
> > > > > > Is it possible to store the log_ctx somewhere in the JNI?
> > > > > > 
> > > > > > We might at some point in the future forbid av_log(NULL, ...) 
> > > > > > calls, and
> > > > > > then it'd get complicated.
> > > > > 
> > > > > Patch updated with the following differences:
> > > > >   * All logging arguments in mediacodec_wrapper functions are now non
> > > > >   NULL
> > > > >   * The mediacodec buffer copy functions has been moved to a separate 
> > > > > file
> > > > >   * The Mediacodec enum codec flags are properly retrieved from JNI
> > > > > 
> > > > > The codec extradata conversion to annex b simplification has not been
> > > > > addressed in this update. The bitstream filter api does not seem to
> > > > > provide a way to do the extradata conversion without feeding an actual
> > > > > packet to the api (av_bitstream_filter_filter) and i would like to 
> > > > > keep
> > > > > the codec initialization in the init function.
> > > > > 
> > > > > The patchset has been pushed to a new branch:
> > > > > https://github.com/mbouron/FFmpeg/tree/feature/mediacodec-support-v3
> > > > > 
> > > > > Matthieu
> > > > 
> > > > >  configure |5 
> > > > >  libavcodec/Makefile   |3 
> > > > >  libavcodec/allcodecs.c|1 
> > > > >  libavcodec/mediacodec_sw_buffer.c |  339 +++
> > > > >  libavcodec/mediacodec_sw_buffer.h |   62 +
> > > > >  libavcodec/mediacodec_wrapper.c   | 1674 
> > > > > ++
> > > > >  libavcodec/mediacodec_wrapper.h   |  122 ++
> > > > >  libavcodec/mediacodecdec.c|  563 
> > > > >  libavcodec/mediacodecdec.h|   82 +
> > > > >  libavcodec/mediacodecdec_h264.c   |  356 
> > > > >  10 files changed, 3207 insertions(+)
> > > > > f545068afece74d27cc04a365d9de7dcf5586a7d  
> > > > > 0002-lavc-add-h264-mediacodec-decoder.patch
> > > > > From 

Re: [FFmpeg-devel] [PATCH 1/2] lavc: add JNI support

[Matthieu Bouron]

On Wed, Mar 02, 2016 at 03:24:06PM +0100, Matthieu Bouron wrote:
> On Tue, Mar 01, 2016 at 09:06:35PM +0100, wm4 wrote:
> > On Tue, 1 Mar 2016 20:57:12 +0100
> > Matthieu Bouron  wrote:
> > 
> > > On Tue, Mar 01, 2016 at 08:55:23PM +0100, Matthieu Bouron wrote:
> > > > On Tue, Mar 01, 2016 at 08:38:04PM +0100, wm4 wrote:  
> > > > > On Tue, 1 Mar 2016 20:33:14 +0100
> > > > > Matthieu Bouron  wrote:
> > > > >   
> > > > > > On Tue, Mar 01, 2016 at 08:24:27PM +0100, Matthieu Bouron wrote:  
> > > > > > > On Tue, Mar 01, 2016 at 08:13:48PM +0100, wm4 wrote:
> > > > > > > > On Tue, 1 Mar 2016 20:10:50 +0100
> > > > > > > > Matthieu Bouron  wrote:
> > > > > > > > 
> > > > > > > > > On Tue, Mar 01, 2016 at 07:56:30PM +0100, wm4 wrote:
> > > > > > > > > > On Tue, 1 Mar 2016 19:52:08 +0100
> > > > > > > > > > Matthieu Bouron  wrote:
> > > > > > > > > >   
> > > > > > > > > > > On Fri, Feb 26, 2016 at 05:36:40PM +0100, Matthieu Bouron 
> > > > > > > > > > > wrote:  
> > > > > > > > > > > > On Fri, Feb 26, 2016 at 4:41 PM, Matthieu Bouron 
> > > > > > > > > > > > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > 
> > > > > > > > > > > > > On Mon, Feb 22, 2016 at 12:20:35PM +0100, Matthieu 
> > > > > > > > > > > > > Bouron wrote:
> > > > > > > > > > > > > > From: Matthieu Bouron 
> > > > > > > > > > > > > > 
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > 
> > > > > > > > > > > > [...]
> > > > > > > > > > > > 
> > > > > > > > > > > > 
> > > > > > > > > > > > >
> > > > > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > > > > >   * fix of switch/case code style
> > > > > > > > > > > > >   * removal of a miss declaration of FFJNIField enum 
> > > > > > > > > > > > > as a global variable
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > > > >   * fixes a few typo in comments
> > > > > > > > > > > >   * fixes a if statement in ff_jni_init_jfields
> > > > > > > > > > > 
> > > > > > > > > > > Patch updated with the following differences:
> > > > > > > > > > >   * fixes a few typo in comments and message logs
> > > > > > > > > > >   * add missing .so at end of library names when trying 
> > > > > > > > > > > to find
> > > > > > > > > > >   JNI_GetCreatedVMs symbol (also add libart.so)
> > > > > > > > > > >   * reintroduce public functions that allow the user to 
> > > > > > > > > > > set the Java
> > > > > > > > > > >   virtual machine (av_jni_(set,get)_java_vm) as the 
> > > > > > > > > > > private C++
> > > > > > > > > > >   JniInvocation wrapper is not available on all devices 
> > > > > > > > > > > (android >= 4.4)  
> > > > > > > > > > 
> > > > > > > > > > I'm wondering if the VM should be stored per 
> > > > > > > > > > AVCodecContext. (Since it
> > > > > > > > > > has to be set explicitly again by the user.)  
> > > > > > > > > 
> > > > > > > > > I think it is fine to store one VM for all the AVCodecContext 
> > > > > > > > > as it will
> > > > > > > > > be the same during all the lifetime of the application. I 
> > > > > > > > > should also
> > > > > > > > > enforce that the VM cannot be changed afterwards.
> > > > > > > > > 
> > > > > > > > > av_jni_set_java_vm stores the Java VM pointer locally in 
> > > > > > > > > jni.c and not in
> > > > > > > > > ffjni.c and it is retrieved in jni.c using 
> > > > > > > > > av_jni_get_java_vm. I've done
> > > > > > > > > it that way because if at some point we are to include 
> > > > > > > > > ffjni.c from
> > > > > > > > > libavformat it won't work (it will only set the java vm in 
> > > > > > > > > the libavcodec
> > > > > > > > > memory space).
> > > > > > > > 
> > > > > > > > The problem is that this is not library-safe. What if two libs 
> > > > > > > > within
> > > > > > > > the process (which both are using libavcodec) are setting a 
> > > > > > > > different
> > > > > > > > VM?
> > > > > > > 
> > > > > > > In the Android application context, you only have, AFAIK, one VM 
> > > > > > > running
> > > > > > > during the lifetime of the application. The code does handle the 
> > > > > > > general
> > > > > > 
> > > > > > does *not* (sorry)
> > > > > >   
> > > > > > > JNI case (even outside Android) but do we really want to do that 
> > > > > > > anyway ?
> > > > > 
> > > > > If there's guaranteed to be exactly one, I don't get why we can't get
> > > > > it into existence ourselves?
> > > > >
> > > > > Where exactly would an application get the VM handle from?  
> > > > 
> > > > You get the Java VM pointer when JNI_onLoad(JavaVM *vm, void *reserved) 
> > > > is
> > > > executed at library load. This is where you can pass the pointer to 
> > > > lavc.
> > > 

[FFmpeg-devel] Libavcodec consulting

[Jonathan Girven]

Hi all,



We are interested in getting a consultant in to help with libav usage in
our
iOS video editing app and I was directed to post to this list. Our app
needs
to download a small section of a large video file hosted on a remote http

server. We have found that AVFoundation is not suitable for our purposes.
We
instead want to use libav. The requirements are:



- The file is hosted on a remote http server.

- We want to specify an input file, start time to seek to, duration to
download
  and an output file.

- The original file is in mp4 format.

- The saved file should also be in mp4 format.

- All other video data should be copied.

- The function should provide an interface to get a download progress

  percentage.

- The code cannot read in the entire remote video file to get a segment at
the
  end of the file.

- We will be calling the function from an iOS application, so should be

  compatible.

- The code can make use of libraries such as FFmpegWrapper for iOS.



An equivalent ffmpeg command would be:



$ ffmpeg -i http://www.example.com/input.mp4 -ss start_time -t duration

  output.mp4



This first project could lead to future opportunities in the future. Would

anyone be interested in taking this on? If so, could you provide a rough
quote
and time estimation, so we can discuss futher.



Many thanks,

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

[FFmpeg-devel] [PATCH] web/contact: Fix link.

[Simon Thelen]

Signed-off-by: Simon Thelen 
---
 src/contact | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/contact b/src/contact
index 077f9ca..22c1e11 100644
--- a/src/contact
+++ b/src/contact
@@ -154,6 +154,6 @@
   
 http://ffmpeg.zeranoe.com/forum/;>FFmpeg on Windows
  
-http://ffmpeg.gusari.org/;>FFmpeg 
Support Forum
+http://ffmpeg.gusari.org/index.php;>FFmpeg Support Forum
   
  
-- 
2.7.1

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

Re: [FFmpeg-devel] [PATCH 2/4] avcodec/dca: fix av_cold placement in declarations

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:57:36AM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 2, 2016 at 8:31 PM, foo86  wrote:
> > ---
> >  libavcodec/dca_xll.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> > index cd1af81..ffe8ef3 100644
> > --- a/libavcodec/dca_xll.c
> > +++ b/libavcodec/dca_xll.c
> > @@ -602,7 +602,7 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
> > DCAXllChSet *c, int band, int s
> >  return 0;
> >  }
> >
> > -static void av_cold chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, 
> > int band, int seg)
> > +static av_cold void chs_clear_band_data(DCAXllDecoder *s, DCAXllChSet *c, 
> > int band, int seg)
> >  {
> >  DCAXllBand *b = >bands[band];
> >  int i, offset, nsamples;
> > @@ -1242,7 +1242,7 @@ static void scale_down_mix(DCAXllDecoder *s, 
> > DCAXllChSet *o, int band)
> >
> >  // Clear all band data and replace non-residual encoded channels with lossy
> >  // counterparts
> > -static void av_cold force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
> > +static av_cold void force_lossy_output(DCAXllDecoder *s, DCAXllChSet *c)
> >  {
> >  DCAContext *dca = s->avctx->priv_data;
> >  int band, ch;
> > --
> > 2.1.4
> 
> LGTM, thanks.

applied

thanks

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

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 


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/4] avcodec/dca: simplify condition

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:59:19AM +0100, Hendrik Leppkes wrote:
> On Wed, Mar 2, 2016 at 8:32 PM, foo86  wrote:
> > ---
> >  libavcodec/dca_xll.c | 17 ++---
> >  1 file changed, 6 insertions(+), 11 deletions(-)
> >
> > diff --git a/libavcodec/dca_xll.c b/libavcodec/dca_xll.c
> > index ffe8ef3..5e6cf35 100644
> > --- a/libavcodec/dca_xll.c
> > +++ b/libavcodec/dca_xll.c
> > @@ -460,19 +460,14 @@ static int chs_parse_band_data(DCAXllDecoder *s, 
> > DCAXllChSet *c, int band, int s
> >  // Unpack Rice coding flag
> >  // 0 - linear code, 1 - Rice code
> >  c->rice_code_flag[i] = get_bits1(>gb);
> > -if (!c->seg_common && c->rice_code_flag[i]) {
> > -// Unpack Hybrid Rice coding flag
> > -// 0 - Rice code, 1 - Hybrid Rice code
> > -if (get_bits1(>gb))
> > -// Unpack binary code length for isolated samples
> > -c->bitalloc_hybrid_linear[i] = get_bits(>gb, 
> > c->nabits) + 1;
> > -else
> > -// 0 indicates no Hybrid Rice coding
> > -c->bitalloc_hybrid_linear[i] = 0;
> > -} else {
> > +// Unpack Hybrid Rice coding flag
> > +// 0 - Rice code, 1 - Hybrid Rice code
> > +if (!c->seg_common && c->rice_code_flag[i] && 
> > get_bits1(>gb))
> > +// Unpack binary code length for isolated samples
> > +c->bitalloc_hybrid_linear[i] = get_bits(>gb, c->nabits) 
> > + 1;
> > +else
> >  // 0 indicates no Hybrid Rice coding
> >  c->bitalloc_hybrid_linear[i] = 0;
> > -}
> >  }
> >
> >  // Unpack coding parameters
> > --
> > 2.1.4
> 
> LGTM, logic appears unchanged afterall.

applied

thanks

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] fate: fix filter-hls tests dependencies

[Michael Niedermayer]

On Thu, Mar 03, 2016 at 12:55:55AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  tests/fate/filter-audio.mak| 15 +--
>  tests/ref/fate/{filter-hls2 => filter-hls} |  0
>  2 files changed, 9 insertions(+), 6 deletions(-)
>  rename tests/ref/fate/{filter-hls2 => filter-hls} (100%)

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH]lavf/mpeg: Identify sub-stream ID 0xa1 as mlp

[Carl Eugen Hoyos]

Hi!

Attached patch (still) fixes ticket #4786 for me.
Autodetection seems impossible to me and the following 
page suggests that this patch is likely correct:
http://dvd-audio.sourceforge.net/spec/aob.shtml

Please comment, Carl Eugen
diff --git a/libavformat/mpeg.c b/libavformat/mpeg.c
index 787d5f0..2f48459 100644
--- a/libavformat/mpeg.c
+++ b/libavformat/mpeg.c
@@ -568,7 +568,7 @@ redo:
 codec_id = AV_CODEC_ID_DTS;
 } else if (startcode >= 0xa0 && startcode <= 0xaf) {
 type = AVMEDIA_TYPE_AUDIO;
-if (lpcm_header_len == 6) {
+if (lpcm_header_len == 6 || startcode == 0xa1) {
 codec_id = AV_CODEC_ID_MLP;
 } else {
 codec_id = AV_CODEC_ID_PCM_DVD;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH]lavfi/drawutils: Add some missing GBR pix_fmts

[Carl Eugen Hoyos]

Paul B Mahol  gmail.com> writes:

> > Attached patch fixes extractplanes for gbrap16.
> >
> > Please comment, Carl Eugen
> >
> 
> 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] Use matroska TrackNumber for populating AVStream::id

[Carl Eugen Hoyos]

wm4  googlemail.com> writes:

> > +st->id = (int) track->num;

> Might be better after all not to set the id if it's out of range?

Yes, please.

While there, the id field could be changed to 64bit with the 
next version bump.

Carl Eugen

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

Re: [FFmpeg-devel] [PATCH]lavfi/drawutils: Add some missing GBR pix_fmts

[Paul B Mahol]

On 3/3/16, Carl Eugen Hoyos  wrote:
> Hi!
>
> Attached patch fixes extractplanes for gbrap16.
>
> Please comment, Carl Eugen
>

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

[FFmpeg-devel] [PATCH]lavfi/drawutils: Add some missing GBR pix_fmts

[Carl Eugen Hoyos]

Hi!

Attached patch fixes extractplanes for gbrap16.

Please comment, Carl Eugen
diff --git a/libavfilter/drawutils.c b/libavfilter/drawutils.c
index 1ce0366..d37c83e 100644
--- a/libavfilter/drawutils.c
+++ b/libavfilter/drawutils.c
@@ -54,10 +54,20 @@ int ff_fill_rgba_map(uint8_t *rgba_map, enum AVPixelFormat 
pix_fmt)
 case AV_PIX_FMT_BGR0:
 case AV_PIX_FMT_BGR24: rgba_map[BLUE ] = 0; rgba_map[GREEN] = 1; 
rgba_map[RED  ] = 2; rgba_map[ALPHA] = 3; break;
 case AV_PIX_FMT_GBRP9LE:
+case AV_PIX_FMT_GBRP9BE:
 case AV_PIX_FMT_GBRP10LE:
+case AV_PIX_FMT_GBRP10BE:
 case AV_PIX_FMT_GBRP12LE:
+case AV_PIX_FMT_GBRP12BE:
 case AV_PIX_FMT_GBRP14LE:
+case AV_PIX_FMT_GBRP14BE:
+case AV_PIX_FMT_GBRP16LE:
+case AV_PIX_FMT_GBRP16BE:
 case AV_PIX_FMT_GBRAP:
+case AV_PIX_FMT_GBRAP12LE:
+case AV_PIX_FMT_GBRAP12BE:
+case AV_PIX_FMT_GBRAP16LE:
+case AV_PIX_FMT_GBRAP16BE:
 case AV_PIX_FMT_GBRP:  rgba_map[GREEN] = 0; rgba_map[BLUE ] = 1; 
rgba_map[RED  ] = 2; rgba_map[ALPHA] = 3; break;
 default:/* unsupported */
 return AVERROR(EINVAL);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v5 1/4] lavf/avienc: Add support for palette side data

[Mats Peterson]

On 03/03/2016 12:34 AM, Mats Peterson wrote:

Hopefully this patch set will work on big-endian machines as well.
Please try stream copy to and from avi/mov with the files below:

QuickTime Animation (RLE):
https://drive.google.com/open?id=0B3_pEBoLs0faREo1SlRydmV1LU0

QuickTime Graphics (SMC):
https://drive.google.com/open?id=0B3_pEBoLs0faODd5RVBldkdvVGc

Microsoft Video 1 (CRAM)
https://drive.google.com/open?id=0B3_pEBoLs0faT2ZZZVNpVUM0blE

Mats



Please add this patch set now. I have tested it extensively for two 
days, and it would be nice to have it applied before any more changes 
occur to avienc.c, moven.c, or riffenc.c.


Mats

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

Re: [FFmpeg-devel] [PATCH v5 4/4 v2] lavf/utils: Normalize AVPacket.data to native endian in ff_get_packet_palette()

[Mats Peterson]

On 03/03/2016 08:49 AM, Mats Peterson wrote:

On 03/03/2016 08:29 AM, Mats Peterson wrote:

Due to Morton Balint's recent addition of
ff_standardize_creation_time(), the previous patch would fail. Please
add this one before any more changes occur.



In my book, using native uint32_t when dealing with the palette on
muxing is clearly the most logical and cleanest way.



The most obvious reason for normalizing AVPacket.data to native endian 
is that we can't easily determine the endianness of the palette side 
data (as far as I know) due to its being stored in native endian. 
AVPacket.data will always be little endian.


Mats

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

Re: [FFmpeg-devel] [PATCH] Use matroska TrackNumber for populating AVStream::id

[wm4]

On Wed, 2 Mar 2016 15:29:21 -0800
Sergey Volk  wrote:

> As far as I can see FFmpeg currently doesn't set AVStream::id for
> matroska/webm streams. I think we could use either MatroskaTrack::num
> (TrackNumber) or MatroskaTrack::uid (TrackUID) for that.
> I have found a few discussions claiming that TrackUID could be missing,
> even though TrackUID is marked as mandatory field in matroska spec, for
> example see
> https://github.com/mbunkus/mkvtoolnix/issues/1050
> https://lists.w3.org/Archives/Public/public-inbandtracks/2014May/0003.html
> So I guess it's safer to use TrackNumber for now.
> ---
>  libavformat/matroskadec.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index d20568c..8b80df1 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -1856,6 +1856,8 @@ static int matroska_parse_tracks(AVFormatContext *s)
>  return AVERROR(ENOMEM);
>  }
> 
> +st->id = (int) track->num;
> +
>  if (key_id_base64) {
>  /* export encryption key id as base64 metadata tag */
>  av_dict_set(>metadata, "enc_key_id", key_id_base64, 0);

The int cast makes me suspicious. It might be ok to discard the
additional bits for pathological files, but I don't quite remember
whether or not this can trigger UB.

Might be better after all not to set the id if it's out of range?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel