Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list

[wm4]

On Sun, 28 Feb 2016 02:14:20 +0100
Michael Niedermayer  wrote:

> On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote:
> > On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
> >  wrote:  
> > > This would require listing supported formats for rawvideo and 
> > > wrapped_avframe
> > >
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/utils.c |5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > > index 2690d0d..267c973 100644
> > > --- a/libavcodec/utils.c
> > > +++ b/libavcodec/utils.c
> > > @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec)
> > >
> > >  if (codec->init_static_data)
> > >  codec->init_static_data(codec);
> > > +
> > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO 
> > > && !codec->pix_fmts)
> > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts 
> > > field\n", codec->name);
> > > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO  
> > > && !codec->sample_fmts)
> > > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the 
> > > sample_fmts field\n", codec->name);
> > >  }  
> > 
> > It seems kinda silly to write code to check if other code is correct.  
> 
> i dont think i understand because what you say would mean that
> fate and all self tests are a bad idea if i dont misunderstand
> 
> 
> > Apparently all encoders today are correct, so lets just pay attention  
> 
> rawvideo and wrapped_avframe dont list pix_fmts, they would need to
> be fixed first if we apply this
> 

Really, for 2 encoders?

> 
> > in the future when adding new ones?  
> 
> a self test like this would detect that reliably without the need for
> (less reliable and limited) human resources.
> 

This can be done externally, no need to litter utils.c with more
effectively dead code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets

[Mats Peterson]

On 02/28/2016 05:38 AM, Mats Peterson wrote:

On 02/28/2016 05:27 AM, Mats Peterson wrote:

Use "palette side data" instead of "palette extradata" in error message.



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




Michael, I would like to add that ff_reshuffle_raw_rgb() that you wrote
has the benefit of taking care of the correct stride when using stream
copy as well. Thus, it won't be an "identical" stream copy, but it will
be a valid one for the output file format in question.

Mats



And Reimar, the AVI muxer libavformat/avienc.c uses *lots* of 
avio_seek() all over the place, so it won't work well on stdout 
regardless of my patch. I have checked for avio_seek() returning >= 0 in 
my part of the code in any case, but it won't make much of a difference.


Mats

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

Re: [FFmpeg-devel] [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets

[Mats Peterson]

On 02/28/2016 05:27 AM, Mats Peterson wrote:

Use "palette side data" instead of "palette extradata" in error message.



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




Michael, I would like to add that ff_reshuffle_raw_rgb() that you wrote 
has the benefit of taking care of the correct stride when using stream 
copy as well. Thus, it won't be an "identical" stream copy, but it will 
be a valid one for the output file format in question.


Mats

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

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

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

[Mats Peterson]

Use "palette side data" instead of "palette extradata" in error message.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 506fe35051a51e0a4a42579b0a5f3d974531c1ae Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 05:25:53 +0100
Subject: [PATCH v3 2/2] lavf/movenc: Add support for palette side data packets

---
 libavformat/movenc.c |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e0223b2..2ca445e 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4760,19 +4760,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (trk->is_unaligned_qt_rgb) {
+if (trk->is_unaligned_qt_rgb && pkt->size) {
 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;
+const uint8_t *pal = NULL;
+int pkt_pal_size;
 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++;
+if (!trk->pal_done) {
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE,
+ _pal_size);
+if (pal && pkt_pal_size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
 } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
 for (i = 0; i < pkt->size; i++)
-- 
1.7.10.4

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

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

[Mats Peterson]

Use "palette side data" instead of "palette extradata" in error message.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 962582ec4c265573a3230c089929854e1058c4af Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 05:25:36 +0100
Subject: [PATCH v3 1/2] lavf/avienc: Add support for palette side data packets

---
 libavformat/avienc.c |   54 ++
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..9ac190a 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -668,39 +668,49 @@ 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) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) {
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
+const uint8_t *pal = NULL;
+int pal_size = 1 << enc->bits_per_coded_sample;
+int pkt_pal_size, i;
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE,
+ _pal_size);
+if (pal && pkt_pal_size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette side data\n");
+return AVERROR_INVALIDDATA;
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+int pc_tag;
+if (!avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) {
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = AV_RL32(pal + 4*i);
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-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);
-avio_wb32(pb, v<<8);
 }
-ff_end_tag(pb, pc_tag);
+avist->hdr_pal_done++;
 }
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, pal_size & 0xFF);
+avio_wl16(pb, 0); // reserved
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);
+}
+ff_end_tag(pb, pc_tag);
+}
+if (ret) {
 ret = avi_write_packet_internal(s, pkt);
 av_packet_free();
 return ret;
-- 
1.7.10.4

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

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

[Mats Peterson]

Check for palette side data being AVPALETTE_SIZE bytes.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 1e6f27735442ddac19775fe5e03d8429fe6f3448 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 05:16:56 +0100
Subject: [PATCH v2 2/2] lavf/movenc: Add support for palette side data packets

---
 libavformat/movenc.c |   22 --
 1 file changed, 16 insertions(+), 6 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e0223b2..c20797c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4760,19 +4760,29 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (trk->is_unaligned_qt_rgb) {
+if (trk->is_unaligned_qt_rgb && pkt->size) {
 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;
+const uint8_t *pal = NULL;
+int pkt_pal_size;
 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++;
+if (!trk->pal_done) {
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE,
+ _pal_size);
+if (pal && pkt_pal_size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette extradata\n");
+return AVERROR_INVALIDDATA;
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
 } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
 for (i = 0; i < pkt->size; i++)
-- 
1.7.10.4

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

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

[Mats Peterson]

Check for palette side data being AVPALETTE_SIZE bytes.

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 8c72d4c41615dcc651913f83154e5df1d884af8d Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 05:16:38 +0100
Subject: [PATCH v2 1/2] lavf/avienc: Add support for palette side data packets

---
 libavformat/avienc.c |   54 ++
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..8d261c0 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -668,39 +668,49 @@ 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) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) {
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
+const uint8_t *pal = NULL;
+int pal_size = 1 << enc->bits_per_coded_sample;
+int pkt_pal_size, i;
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE,
+ _pal_size);
+if (pal && pkt_pal_size != AVPALETTE_SIZE) {
+av_log(s, AV_LOG_ERROR, "Invalid palette extradata\n");
+return AVERROR_INVALIDDATA;
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+int pc_tag;
+if (!avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) {
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = AV_RL32(pal + 4*i);
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-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);
-avio_wb32(pb, v<<8);
 }
-ff_end_tag(pb, pc_tag);
+avist->hdr_pal_done++;
 }
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, pal_size & 0xFF);
+avio_wl16(pb, 0); // reserved
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);
+}
+ff_end_tag(pb, pc_tag);
+}
+if (ret) {
 ret = avi_write_packet_internal(s, pkt);
 av_packet_free();
 return ret;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits

[James Almer]

On 2/28/2016 12:43 AM, Michael Niedermayer wrote:
> On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote:
>> ---
>>  libavcodec/x86/constants.c | 3 ++-
>>  libavcodec/x86/constants.h | 2 +-
>>  2 files changed, 3 insertions(+), 2 deletions(-)
> 
> LGTM if these are or will be used
> 
> thx

Not by this patchset. Nothing in avcodec needs it this wide for now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] x86/constants: extend pw_128 to 256 bits

[Michael Niedermayer]

On Mon, Feb 08, 2016 at 11:27:51AM -0800, Timothy Gu wrote:
> ---
>  libavcodec/x86/constants.c | 3 ++-
>  libavcodec/x86/constants.h | 2 +-
>  2 files changed, 3 insertions(+), 2 deletions(-)

LGTM if these are or will be used

thx

[...]
-- 
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] movenc: Enable timecode tracks in MP4

[Michael Niedermayer]

On Thu, Feb 04, 2016 at 04:45:09PM +, Carl Eugen Hoyos wrote:
> Syed Andaleeb Roomy  gmail.com> writes:
> 
> > I worked on the attached patch to enable timecode tracks in MP4 files
> > written by ffmpeg. Could someone please take a look to see if it is
> > acceptable?
> 
> Ping, see ticket #4704.

applied

thanks

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

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


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

Re: [FFmpeg-devel] [PATCH] configure: add direct detection of libopencv

[Michael Niedermayer]

On Mon, Feb 15, 2016 at 06:25:01PM -0300, James Almer wrote:
> On 2/7/2016 8:24 PM, wm4 wrote:
> > On Sun, 7 Feb 2016 23:25:53 +0100
> > Andreas Cadhalpun  wrote:
> > 
> >> The pkg-config file contains all opencv libraries, not only the
> >> neccessary ones.
> >>
> >> This change makes it possible to use the libopencv-imgproc-dev Debian
> >> package instead of libopencv-dev, saving about 200 MB of useless
> >> build-dependencies.
> >>
> >> In particular one doesn't need to install the parts of opencv that
> >> depend on ffmpeg libraries.
> >>
> >> Signed-off-by: Andreas Cadhalpun 
> >> ---
> >>  configure | 3 ++-
> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/configure b/configure
> >> index 1000cb1..36ab7e5 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -5488,7 +5488,8 @@ enabled libnut&& require libnut libnut.h 
> >> nut_demuxer_init -lnut
> >>  enabled libopencore_amrnb && require libopencore_amrnb 
> >> opencore-amrnb/interf_dec.h Decoder_Interface_init -lopencore-amrnb
> >>  enabled libopencore_amrwb && require libopencore_amrwb 
> >> opencore-amrwb/dec_if.h D_IF_init -lopencore-amrwb
> >>  enabled libopencv && { check_header opencv2/core/core_c.h &&
> >> -   require_pkg_config opencv 
> >> opencv2/core/core_c.h cvCreateImageHeader ||
> >> +   { use_pkg_config opencv 
> >> opencv2/core/core_c.h cvCreateImageHeader ||
> >> + require opencv opencv2/core/core_c.h 
> >> cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
> >> require_pkg_config opencv opencv/cxcore.h 
> >> cvCreateImageHeader; }
> >>  enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h 
> >> WelsGetCodecVersion
> >>  enabled libopenjpeg   && { check_lib openjpeg-2.1/openjpeg.h 
> >> opj_version -lopenjp2 -DOPJ_STATIC ||
> > 
> > Why not send a patch to opencv?
> 

> Doesn't hurt adding this in the meantime.

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 1/2] lavf/avienc: Add support for palette side data packets

[Mats Peterson]

On 02/28/2016 03:00 AM, Mats Peterson wrote:




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



Why is the packet data in AVI packets sometimes zero bytes when using 
stream copy, Michael? There certainly must be some reason for it?


Mats

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

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

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From ec165732b5677f412112c114b09760d26f1f96bd Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 02:58:57 +0100
Subject: [PATCH 2/2] lavf/movenc: Add support for palette side data packets

---
 libavformat/movenc.c |   16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e0223b2..b6b6a99 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -4760,19 +4760,23 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 }
 }
 
-if (trk->is_unaligned_qt_rgb) {
+if (trk->is_unaligned_qt_rgb && pkt->size) {
 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;
+const uint8_t *pal = NULL;
 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++;
+if (!trk->pal_done) {
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, NULL);
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+memcpy(trk->palette, pal, AVPALETTE_SIZE);
+trk->pal_done++;
+}
 } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
 for (i = 0; i < pkt->size; i++)
-- 
1.7.10.4

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

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

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 40adfd0b3be94dfaf88187ee9f71bd85ad858f9d Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sun, 28 Feb 2016 02:58:36 +0100
Subject: [PATCH 1/2] lavf/avienc: Add support for palette side data packets

---
 libavformat/avienc.c |   49 +++--
 1 file changed, 27 insertions(+), 22 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..10c4413 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -668,39 +668,44 @@ 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) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) {
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
-
+const uint8_t *pal = NULL;
+int pal_size = 1 << enc->bits_per_coded_sample;
+int i;
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_pal_done) {
-int64_t cur_offset = avio_tell(pb);
-avio_seek(pb, avist->pal_offset, SEEK_SET);
+pal = (uint8_t *)av_packet_get_side_data(pkt, AV_PKT_DATA_PALETTE, NULL);
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+if (pal) {
+int pc_tag;
+if (!avist->hdr_pal_done) {
+int64_t cur_offset = avio_tell(pb);
+if (avio_seek(pb, avist->pal_offset, SEEK_SET) >= 0) {
 for (i = 0; i < pal_size; i++) {
-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
+uint32_t v = AV_RL32(pal + 4*i);
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-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);
-avio_wb32(pb, v<<8);
 }
-ff_end_tag(pb, pc_tag);
+avist->hdr_pal_done++;
 }
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, pal_size & 0xFF);
+avio_wl16(pb, 0); // reserved
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);
+}
+ff_end_tag(pb, pc_tag);
+}
+if (ret) {
 ret = avi_write_packet_internal(s, pkt);
 av_packet_free();
 return ret;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavf: forward protocol_whitelist for the remaining cases

[Michael Niedermayer]

On Wed, Feb 03, 2016 at 11:20:05PM +0100, Andreas Cadhalpun wrote:
> On 03.02.2016 03:41, Michael Niedermayer wrote:
> > On Wed, Feb 03, 2016 at 01:51:55AM +0100, Andreas Cadhalpun wrote:
> >> @@ -274,4 +282,5 @@ URLProtocol ff_ffrtmphttp_protocol = {
> >>  .priv_data_size = sizeof(RTMP_HTTPContext),
> >>  .flags  = URL_PROTOCOL_FLAG_NETWORK,
> >>  .priv_data_class= _class,
> >> +.default_whitelist = "https,http,tcp",
> > 
> > if it needs https it might need tls too
> 
> Yes, updated patch attached.
> 
> Best regards,
> Andreas
> 

>  mmsh.c |9 +
>  rtmphttp.c |9 +
>  rtsp.c |8 
>  3 files changed, 26 insertions(+)
> ac9de87a225e549ae03722a3fc487cb22be5802a  
> 0001-lavf-forward-protocol_whitelist-for-the-remaining-ca.patch
> From 595133afad21a4e264642259e8c74708dd4a72ba Mon Sep 17 00:00:00 2001
> From: Andreas Cadhalpun 
> Date: Wed, 3 Feb 2016 01:01:34 +0100
> Subject: [PATCH] lavf: forward protocol_whitelist for the remaining cases
> 
> Also set a default_whitelist for mmsh and ffrtmphttp.
> 
> Signed-off-by: Andreas Cadhalpun 

LGTM

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- 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 v2] lavf/avienc: Use palette side data packet if available

[Mats Peterson]

On 02/28/2016 02:15 AM, Reimar Döffinger wrote:

+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}


av_frame_get_side_data


No frames available in a muxer (as far as I know). But thanks anyway...


av_packet_get_side_data then.


Yes, that's more elegant of course. I just "copied" a snippet from 
nutenc.c in the meantime...










-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);


You'll probably still need the if to use the one or the avio_w...
depending on format.
Unless it's possible to change the embedded format to match
the side data one.



Don't know what you mean by "Probably still need the if".


Forget this and the rest, I simply misread the patch diff.


No problem, Reimar.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list

[Michael Niedermayer]

On Sun, Feb 28, 2016 at 01:26:16AM +0100, Hendrik Leppkes wrote:
> On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
>  wrote:
> > This would require listing supported formats for rawvideo and 
> > wrapped_avframe
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/utils.c |5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index 2690d0d..267c973 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec)
> >
> >  if (codec->init_static_data)
> >  codec->init_static_data(codec);
> > +
> > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && 
> > !codec->pix_fmts)
> > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts 
> > field\n", codec->name);
> > +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO  
> > && !codec->sample_fmts)
> > +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the 
> > sample_fmts field\n", codec->name);
> >  }
> 
> It seems kinda silly to write code to check if other code is correct.

i dont think i understand because what you say would mean that
fate and all self tests are a bad idea if i dont misunderstand


> Apparently all encoders today are correct, so lets just pay attention

rawvideo and wrapped_avframe dont list pix_fmts, they would need to
be fixed first if we apply this


> in the future when adding new ones?

a self test like this would detect that reliably without the need for
(less reliable and limited) human resources.


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

If you drop bombs on a foreign country and kill hundred thousands of
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available

[Reimar Döffinger]

On 28.02.2016, at 01:13, Mats Peterson  wrote:

> On 02/28/2016 12:34 AM, Reimar Döffinger wrote:
> 
>> On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
>>> -if (!avist->hdr_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);
>>> -avio_wl32(pb, v & 0xff);
>>> -}
>>> -avio_seek(pb, cur_offset, SEEK_SET);
>>> -avist->hdr_pal_done++;
>>> -}
>> 
>> Hadn't seen this before.
>> In principle it is a bit unfortunate as it means that streaming via
>> stdout is not possible.
>> It should at least be suppressed when seeking the output stream
>> is not possible.
> 
> Right. Good point.
> 
>> 
>> 
>>> +for (i = 0; i < pkt->side_data_elems; i++) {
>>> +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
>>> +pal = pkt->side_data[i].data;
>>> +break;
>>> +}
>>> +}
>> 
>> av_frame_get_side_data
> 
> No frames available in a muxer (as far as I know). But thanks anyway...

av_packet_get_side_data then.

> 
>> 
>>> -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
>>> -avio_wb32(pb, v<<8);
>>> +uint32_t v = AV_RL32(pal + 4*i);
>>> +avio_wl32(pb, v & 0xff);
>> 
>> You'll probably still need the if to use the one or the avio_w...
>> depending on format.
>> Unless it's possible to change the embedded format to match
>> the side data one.
>> 
> 
> Don't know what you mean by "Probably still need the if".

Forget this and the rest, I simply misread the patch diff.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available

[Mats Peterson]

On 02/28/2016 01:13 AM, Mats Peterson wrote:

On 02/28/2016 12:34 AM, Reimar Döffinger wrote:


On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:

-if (!avist->hdr_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);
-avio_wl32(pb, v & 0xff);
-}
-avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}


Hadn't seen this before.
In principle it is a bit unfortunate as it means that streaming via
stdout is not possible.
It should at least be suppressed when seeking the output stream
is not possible.


Right. Good point.





+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}


av_frame_get_side_data


No frames available in a muxer (as far as I know). But thanks anyway...




-uint32_t v = AV_RL32(data + size - 4*pal_size +
4*i);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);


You'll probably still need the if to use the one or the avio_w...
depending on format.
Unless it's possible to change the embedded format to match
the side data one.



Don't know what you mean by "Probably still need the if".



+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);


Why is the header format different? That seems a bit weird.
___


The palette uses a RGBQUAD (BGRA) structure for the entries in the
palette after the BITMAPINFOHEADER, but it uses an AVIPALCHANGE
structure (RGBA) for those 'xxpc' chunks. It may seem a bit confusing,


Well, the AVIPALCHANGE structure uses a PALETTEENTRY structure, that's 
the core of it, and it uses RGB order, with a flag byte afterwards.


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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list

[Hendrik Leppkes]

On Sun, Feb 28, 2016 at 12:17 AM, Michael Niedermayer
 wrote:
> This would require listing supported formats for rawvideo and wrapped_avframe
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/utils.c |5 +
>  1 file changed, 5 insertions(+)
>
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 2690d0d..267c973 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec)
>
>  if (codec->init_static_data)
>  codec->init_static_data(codec);
> +
> +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && 
> !codec->pix_fmts)
> +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts 
> field\n", codec->name);
> +if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO  && 
> !codec->sample_fmts)
> +av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the sample_fmts 
> field\n", codec->name);
>  }

It seems kinda silly to write code to check if other code is correct.
Apparently all encoders today are correct, so lets just pay attention
in the future when adding new ones?

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/28/2016 12:22 AM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:

On 02/27/2016 09:21 PM, Mats Peterson wrote:

On 02/27/2016 08:42 PM, Reimar Döffinger wrote:

Well, then we know I can only blame Mats for "only" making it
better instead of perfect :)
___


Well, before my patches, there was no palette inclusion whatsoever in
AVI or QuickTime on muxing. Anyway, you're right about the stream
copying not working. Just tried it here. Another issue to take care
of... phew.



Solving the stream copying issues obviously requires using side data packets
in the muxers, correct me if I'm wrong.


Well, that is one option.



It's obviously the only option considering the current state of FFmpeg. 
Then again, I don't see the point with stream copying raw palettized 
data, since the strides are different between the file formats. Although 
I agree that the palette transfer should work. It's up to the user to 
determine if what he/she is doing is sensible when using stream copy for 
raw palettized data. It's already stated in the FFmpeg documentation 
that stream copy can be problematic.


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

Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available

[Mats Peterson]

On 02/28/2016 12:34 AM, Reimar Döffinger wrote:


On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:

-if (!avist->hdr_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);
-avio_wl32(pb, v & 0xff);
-}
-avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}


Hadn't seen this before.
In principle it is a bit unfortunate as it means that streaming via
stdout is not possible.
It should at least be suppressed when seeking the output stream
is not possible.


Right. Good point.





+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}


av_frame_get_side_data


No frames available in a muxer (as far as I know). But thanks anyway...




-uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);


You'll probably still need the if to use the one or the avio_w...
depending on format.
Unless it's possible to change the embedded format to match
the side data one.



Don't know what you mean by "Probably still need the if".



+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);


Why is the header format different? That seems a bit weird.
___


The palette uses a RGBQUAD (BGRA) structure for the entries in the 
palette after the BITMAPINFOHEADER, but it uses an AVIPALCHANGE 
structure (RGBA) for those 'xxpc' chunks. It may seem a bit confusing, 
but I'm doing everything by the book. It's all in the AVI specification.


I should probably never have said "I'm new at this". I know the specs 
alright.


I still got no answer to why the packet data is sometimes zero bytes 
when doing stream copy, but I suppose Michael knows.


Mats

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

Re: [FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 10:55:13PM +0100, Mats Peterson wrote:
> -if (!avist->hdr_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);
> -avio_wl32(pb, v & 0xff);
> -}
> -avio_seek(pb, cur_offset, SEEK_SET);
> -avist->hdr_pal_done++;
> -}

Hadn't seen this before.
In principle it is a bit unfortunate as it means that streaming via
stdout is not possible.
It should at least be suppressed when seeking the output stream
is not possible.


> +for (i = 0; i < pkt->side_data_elems; i++) {
> +if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
> +pal = pkt->side_data[i].data;
> +break;
> +}
> +}

av_frame_get_side_data

> -uint32_t v = AV_RL32(data + size - 4*pal_size + 4*i);
> -avio_wb32(pb, v<<8);
> +uint32_t v = AV_RL32(pal + 4*i);
> +avio_wl32(pb, v & 0xff);

You'll probably still need the if to use the one or the avio_w...
depending on format.
Unless it's possible to change the embedded format to match
the side data one.

> +for (i = 0; i < pal_size; i++) {
> +uint32_t v = AV_RL32(pal + 4*i);
> +avio_wb32(pb, v<<8);

Why is the header format different? That seems a bit weird.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 09:24:14PM +0100, Mats Peterson wrote:
> On 02/27/2016 09:21 PM, Mats Peterson wrote:
> >On 02/27/2016 08:42 PM, Reimar Döffinger wrote:
> >>Well, then we know I can only blame Mats for "only" making it
> >>better instead of perfect :)
> >>___
> >
> >Well, before my patches, there was no palette inclusion whatsoever in
> >AVI or QuickTime on muxing. Anyway, you're right about the stream
> >copying not working. Just tried it here. Another issue to take care
> >of... phew.
> >
> 
> Solving the stream copying issues obviously requires using side data packets
> in the muxers, correct me if I'm wrong.

Well, that is one option.
It is also possible for the demuxers to (possibly even just in
addition) append the palette - but I think that is problematic
when palette isn't provided for every frame.
Probably better would be for muxers to have a little magic
function.
const uint8_t *ff_update_get_palette(AVFormatContext *, AVFrame *, bool);
That function would then do something like (possibly a bit overkill
as I describe it):
1) Check if it's a paletted raw format and the palette is appended.
   If so extract it, possibly expand it, store it in the context
   and return the pointer.
2) Check if there is side data palette, and if so store it in the
   context too and return the pointer
3) If palette is not available in any way right now, return the
   one we previously stored in the palette if any.

The bool could then be used to configure whether the return value
should be NULL instead in case of 3) or when in 1) and 2) the
new palette is identical (that way it is selectable if the
palette gets stored with every frame or not, it could probably
even expanded to track actual changed entries).

As said, that is overkill, but it shouldn't hurt to at least
have possible future "nice to haves" in mind from the start.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/imgutils: Assert that the 2nd av_image_fill_linesizes() call in av_image_fill_linesizes() still succeeds

[Michael Niedermayer]

On Wed, Feb 03, 2016 at 05:07:26PM +0100, Michael Niedermayer wrote:
> Fixes CID1271742
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavutil/imgutils.c |5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

applied


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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

[FFmpeg-devel] [PATCH 2/2] avcodec/utils: Warn if a encoder is missing the pix_fmts or sample_fmts list

[Michael Niedermayer]

This would require listing supported formats for rawvideo and wrapped_avframe

Signed-off-by: Michael Niedermayer 
---
 libavcodec/utils.c |5 +
 1 file changed, 5 insertions(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 2690d0d..267c973 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -188,6 +188,11 @@ av_cold void avcodec_register(AVCodec *codec)
 
 if (codec->init_static_data)
 codec->init_static_data(codec);
+
+if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_VIDEO && 
!codec->pix_fmts)
+av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the pix_fmts 
field\n", codec->name);
+if (av_codec_is_encoder(codec) && codec->type == AVMEDIA_TYPE_AUDIO  && 
!codec->sample_fmts)
+av_log(NULL, AV_LOG_WARNING, "Encoder %s is missing the sample_fmts 
field\n", codec->name);
 }
 
 #if FF_API_EMU_EDGE
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH 1/2] doc/examples/transcoding: Use the decoders pixel format if the encoder does not list which are supported

[Michael Niedermayer]

This affects rawvideo and wraped_avframe, no others are affected atm

Signed-off-by: Michael Niedermayer 
---
 doc/examples/transcoding.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index d5d410b..8633362 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -128,7 +128,10 @@ static int open_output_file(const char *filename)
 enc_ctx->width = dec_ctx->width;
 enc_ctx->sample_aspect_ratio = dec_ctx->sample_aspect_ratio;
 /* take first format from list of supported formats */
-enc_ctx->pix_fmt = encoder->pix_fmts[0];
+if (encoder->pix_fmts)
+enc_ctx->pix_fmt = encoder->pix_fmts[0];
+else
+enc_ctx->pix_fmt = dec_ctx->pix_fmt;
 /* video time_base can be set to whatever is handy and 
supported by encoder */
 enc_ctx->time_base = dec_ctx->time_base;
 } else {
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH] Seperate x264rgb encoder and only enable when its actually supported

[Michael Niedermayer]

This avoids enabling and building the x264rgb encoder when its actually not 
supported and
thus would not work

Signed-off-by: Michael Niedermayer 
---
 configure|3 ++-
 libavcodec/libx264.c |   22 --
 2 files changed, 14 insertions(+), 11 deletions(-)

diff --git a/configure b/configure
index f4b821a..a5416a0 100755
--- a/configure
+++ b/configure
@@ -2661,7 +2661,7 @@ libwebp_encoder_deps="libwebp"
 libwebp_anim_encoder_deps="libwebp"
 libx262_encoder_deps="libx262"
 libx264_encoder_deps="libx264"
-libx264rgb_encoder_deps="libx264"
+libx264rgb_encoder_deps="libx264 x264_csp_bgr"
 libx264rgb_encoder_select="libx264_encoder"
 libx265_encoder_deps="libx265"
 libxavs_encoder_deps="libxavs"
@@ -5352,6 +5352,7 @@ check_builtin sem_timedwait semaphore.h "sem_t *s; 
sem_init(s,0,0); sem_timedwai
 check_builtin sync_val_compare_and_swap "" "int *ptr; int oldval, newval; 
__sync_val_compare_and_swap(ptr, oldval, newval)"
 check_builtin gmtime_r time.h "time_t *time; struct tm *tm; gmtime_r(time, tm)"
 check_builtin localtime_r time.h "time_t *time; struct tm *tm; 
localtime_r(time, tm)"
+check_builtin x264_csp_bgr "stdint.h x264.h" "X264_CSP_BGR"
 
 case "$custom_allocator" in
 jemalloc)
diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 5030d65..8a93fb1 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -430,7 +430,7 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
 case AV_PIX_FMT_YUVJ444P:
 case AV_PIX_FMT_YUV444P9:
 case AV_PIX_FMT_YUV444P10: return X264_CSP_I444;
-#ifdef X264_CSP_BGR
+#if CONFIG_LIBX264RGB_ENCODER
 case AV_PIX_FMT_BGR0:
 return X264_CSP_BGRA;
 case AV_PIX_FMT_BGR24:
@@ -884,14 +884,14 @@ static const enum AVPixelFormat pix_fmts_10bit[] = {
 AV_PIX_FMT_NV20,
 AV_PIX_FMT_NONE
 };
+#if CONFIG_LIBX264RGB_ENCODER
 static const enum AVPixelFormat pix_fmts_8bit_rgb[] = {
-#ifdef X264_CSP_BGR
 AV_PIX_FMT_BGR0,
 AV_PIX_FMT_BGR24,
 AV_PIX_FMT_RGB24,
-#endif
 AV_PIX_FMT_NONE
 };
+#endif
 
 static av_cold void X264_init_static(AVCodec *codec)
 {
@@ -1035,13 +1035,6 @@ static const AVClass x264_class = {
 .version= LIBAVUTIL_VERSION_INT,
 };
 
-static const AVClass rgbclass = {
-.class_name = "libx264rgb",
-.item_name  = av_default_item_name,
-.option = options,
-.version= LIBAVUTIL_VERSION_INT,
-};
-
 AVCodec ff_libx264_encoder = {
 .name = "libx264",
 .long_name= NULL_IF_CONFIG_SMALL("libx264 H.264 / AVC / MPEG-4 AVC 
/ MPEG-4 part 10"),
@@ -1058,6 +1051,15 @@ AVCodec ff_libx264_encoder = {
 .caps_internal= FF_CODEC_CAP_INIT_THREADSAFE |
 FF_CODEC_CAP_INIT_CLEANUP,
 };
+#endif
+
+#if CONFIG_LIBX264RGB_ENCODER
+static const AVClass rgbclass = {
+.class_name = "libx264rgb",
+.item_name  = av_default_item_name,
+.option = options,
+.version= LIBAVUTIL_VERSION_INT,
+};
 
 AVCodec ff_libx264rgb_encoder = {
 .name   = "libx264rgb",
-- 
1.7.9.5

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

[FFmpeg-devel] [PATCH v2] lavf/avienc: Use palette side data packet if available

[Mats Peterson]

Still as experimental as the first one. Seems that the packets are empty 
(zero bytes) now and then when doing stream copy. It would be 
interesting to know why, Michael. I'm new at this.


--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From a803d1d4995b371e357f3e280ee37019d77c254e Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 27 Feb 2016 22:53:37 +0100
Subject: [PATCH v2] lavf/avienc: Use palette side data packet if available

---
 libavformat/avienc.c |   61 ++
 1 file changed, 37 insertions(+), 24 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..1b76728 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -668,39 +668,52 @@ 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) {
+if (enc->codec_id == AV_CODEC_ID_RAWVIDEO && enc->codec_tag == 0 && size) {
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int expected_stride = ((enc->width * bpc + 31) >> 5)*4;
+const uint8_t *pal = NULL;
+int pal_size = 1 << enc->bits_per_coded_sample;
+int i;
 
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_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);
-avio_wl32(pb, v & 0xff);
-}
-avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-avio_w8(pb, pal_size & 0xFF);
-avio_wl16(pb, 0); // reserved
+
+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+
+if (pal) {
+int pc_tag, i;
+if (!avist->hdr_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);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);
 }
-ff_end_tag(pb, pc_tag);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->hdr_pal_done++;
+}
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, pal_size & 0xFF);
+avio_wl16(pb, 0); // reserved
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);
 }
+ff_end_tag(pb, pc_tag);
+}
+
+if (ret) {
 ret = avi_write_packet_internal(s, pkt);
 av_packet_free();
 return ret;
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH] lavf/avienc: Use palette side data packet if available

[Mats Peterson]

Just for fun, here is an experimental patch that makes use of palette 
side data packets if they exist. I suppose the packets (including side 
data packets) will be unaltered from demuxing to muxing when using 
stream copy, right? In any case, it produces flickering output for some 
reason.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 15dbacd20db011ebb3255aa2023e6132af56c0a6 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 27 Feb 2016 22:33:29 +0100
Subject: [PATCH] lavf/avienc: Use palette side data packet if available

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

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..c1d26c2 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -671,36 +671,49 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 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;
+const uint8_t *pal = NULL;
+int pal_size = 1 << enc->bits_per_coded_sample;
+int i;
 
 ret = ff_reshuffle_raw_rgb(s, , enc, expected_stride);
 if (ret < 0)
 return ret;
-if (ret) {
-if (ret == CONTAINS_PAL) {
-int pc_tag, i;
-int pal_size = 1 << enc->bits_per_coded_sample;
-if (!avist->hdr_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);
-avio_wl32(pb, v & 0xff);
-}
-avio_seek(pb, cur_offset, SEEK_SET);
-avist->hdr_pal_done++;
-}
-avi_stream2fourcc(tag, stream_index, enc->codec_type);
-tag[2] = 'p'; tag[3] = 'c';
-pc_tag = ff_start_tag(pb, tag);
-avio_w8(pb, 0);
-avio_w8(pb, pal_size & 0xFF);
-avio_wl16(pb, 0); // reserved
+
+for (i = 0; i < pkt->side_data_elems; i++) {
+if (pkt->side_data[i].type == AV_PKT_DATA_PALETTE) {
+pal = pkt->side_data[i].data;
+break;
+}
+}
+if (!pal && ret == CONTAINS_PAL)
+pal = data + size - AVPALETTE_SIZE;
+
+if (pal) {
+int pc_tag, i;
+if (!avist->hdr_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);
-avio_wb32(pb, v<<8);
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wl32(pb, v & 0xff);
 }
-ff_end_tag(pb, pc_tag);
+avio_seek(pb, cur_offset, SEEK_SET);
+avist->hdr_pal_done++;
+}
+avi_stream2fourcc(tag, stream_index, enc->codec_type);
+tag[2] = 'p'; tag[3] = 'c';
+pc_tag = ff_start_tag(pb, tag);
+avio_w8(pb, 0);
+avio_w8(pb, pal_size & 0xFF);
+avio_wl16(pb, 0); // reserved
+for (i = 0; i < pal_size; i++) {
+uint32_t v = AV_RL32(pal + 4*i);
+avio_wb32(pb, v<<8);
 }
+ff_end_tag(pb, pc_tag);
+}
+
+if (ret) {
 ret = avi_write_packet_internal(s, pkt);
 av_packet_free();
 return ret;
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH 4/7] vc2enc: clip and warn when user bitrate set too low

[Moritz Barsnick]

On Sat, Feb 27, 2016 at 19:29:05 +, Rostislav Pehlivanov wrote:
> +av_log(avctx, AV_LOG_WARNING,
> +   "Bitrate too low, clipping to minimum = %.2lf Mbps!\n",
> +   (double)avctx->bit_rate/100.0f);

"%lf" is undefined in C90, and otherwise identical to "%f".
libavutil/softfloat.c (and only that) does also use it though. ("%f" is
already double. There's no printf format specifier for float.)

And if you're going to make the division produce a double, you could
just as well use a double constant in it.

Too much nitpicking for a warning message, sorry,
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 09:33 PM, Michael Niedermayer wrote:

On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:

should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even supporting both, likely only adds 3-5 lines of code or so
its more a philosophical question


Not sure how much was in response to my complaints, but


i dont know either, i was just writing some kind of summary ...



if this parts was I think that misses my point, as I
agree that it doesn't matter which.
What matters though is:
The AVI demuxer creates AVPackets with palette in side data,
and the AVI muxer supports ONLY palette appended in the data.
How to fix it might be philosophical, but I think it's not
philosophical and fairly clear that that's just broken.


yes, though rawvideo stream copy is a bit tricky, especially when
its not the same container.
avi<->mov have different stride align requirements for example.


Yes, I mentioned that before, regarding the stride differences. One 
question: For stream copying, the packets will travel unaltered from the 
demuxer to the muxer including the side data, right? Sorry if it sounds 
idiotic.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Michael Niedermayer]

On Sat, Feb 27, 2016 at 08:42:25PM +0100, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
> > should rawvideo AVPackets palette use data[] or sidedata, honestly i
> > do not know, but i dont think it makes a big difference
> > even supporting both, likely only adds 3-5 lines of code or so
> > its more a philosophical question
> 
> Not sure how much was in response to my complaints, but

i dont know either, i was just writing some kind of summary ...


> if this parts was I think that misses my point, as I
> agree that it doesn't matter which.
> What matters though is:
> The AVI demuxer creates AVPackets with palette in side data,
> and the AVI muxer supports ONLY palette appended in the data.
> How to fix it might be philosophical, but I think it's not
> philosophical and fairly clear that that's just broken.

yes, though rawvideo stream copy is a bit tricky, especially when
its not the same container.
avi<->mov have different stride align requirements for example.
We currently correct that in the muxer
If we similarly also handle side data and extradata palettes in
the muxer (via shared code ideally) then any input would work
not sure this is the best solution

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 09:21 PM, Mats Peterson wrote:

On 02/27/2016 08:42 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:

should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even supporting both, likely only adds 3-5 lines of code or so
its more a philosophical question


Not sure how much was in response to my complaints, but
if this parts was I think that misses my point, as I
agree that it doesn't matter which.
What matters though is:
The AVI demuxer creates AVPackets with palette in side data,
and the AVI muxer supports ONLY palette appended in the data.
How to fix it might be philosophical, but I think it's not
philosophical and fairly clear that that's just broken.
Even remuxing from AVI to AVI simply won't work without a
"decoder" (which is not an issue performance-wise, but it
is usability wise, how should a FFmpeg user know that for
paletted video and only that a lossless stream copy requires
"decoding" and "encoding"?).


about existing API, i suspect there arent many applications that
use ffmpegs demuxers without the decoders  for raw pal8, i might
of course be wrong but this seems a rather uncommon case of a uncommon
case. And muxers side it was all broken before mats ...


Well, then we know I can only blame Mats for "only" making it
better instead of perfect :)
___


Well, before my patches, there was no palette inclusion whatsoever in
AVI or QuickTime on muxing. Anyway, you're right about the stream
copying not working. Just tried it here. Another issue to take care
of... phew.



Solving the stream copying issues obviously requires using side data 
packets in the muxers, correct me if I'm wrong.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 08:42 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:

should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even supporting both, likely only adds 3-5 lines of code or so
its more a philosophical question


Not sure how much was in response to my complaints, but
if this parts was I think that misses my point, as I
agree that it doesn't matter which.
What matters though is:
The AVI demuxer creates AVPackets with palette in side data,
and the AVI muxer supports ONLY palette appended in the data.
How to fix it might be philosophical, but I think it's not
philosophical and fairly clear that that's just broken.
Even remuxing from AVI to AVI simply won't work without a
"decoder" (which is not an issue performance-wise, but it
is usability wise, how should a FFmpeg user know that for
paletted video and only that a lossless stream copy requires
"decoding" and "encoding"?).


about existing API, i suspect there arent many applications that
use ffmpegs demuxers without the decoders  for raw pal8, i might
of course be wrong but this seems a rather uncommon case of a uncommon
case. And muxers side it was all broken before mats ...


Well, then we know I can only blame Mats for "only" making it
better instead of perfect :)
___


Well, before my patches, there was no palette inclusion whatsoever in 
AVI or QuickTime on muxing. Anyway, you're right about the stream 
copying not working. Just tried it here. Another issue to take care 
of... phew.


Mats

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

Re: [FFmpeg-devel] [PATCH] vf_copy: exclude hwaccel formats

[Paul B Mahol]

On 2/26/16, wm4  wrote:
> This does obviously not work.
>
> (Additions based on vf_crop.c.)
> ---
>  libavfilter/vf_copy.c | 18 ++
>  1 file changed, 18 insertions(+)
>
> diff --git a/libavfilter/vf_copy.c b/libavfilter/vf_copy.c
> index fb9a906..b0159cf 100644
> --- a/libavfilter/vf_copy.c
> +++ b/libavfilter/vf_copy.c
> @@ -27,6 +27,23 @@
>  #include "internal.h"
>  #include "video.h"
>
> +static int query_formats(AVFilterContext *ctx)
> +{
> +AVFilterFormats *formats = NULL;
> +int fmt;
> +
> +for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> +int ret;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL)
> +continue;
> +if ((ret = ff_add_format(, fmt)) < 0)
> +return ret;
> +}
> +
> +return ff_set_common_formats(ctx, formats);
> +}
> +
>  static int filter_frame(AVFilterLink *inlink, AVFrame *in)
>  {
>  AVFilterLink *outlink = inlink->dst->outputs[0];
> @@ -64,4 +81,5 @@ AVFilter ff_vf_copy = {
>  .description = NULL_IF_CONFIG_SMALL("Copy the input video unchanged to
> the output."),
>  .inputs  = avfilter_vf_copy_inputs,
>  .outputs = avfilter_vf_copy_outputs,
> +.query_formats = query_formats,
>  };

I guess this should be fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 08:44 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote:

On 02/27/2016 07:46 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:

On 02/27/2016 07:18 PM, Reimar Döffinger wrote:

That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.



Stream copying of raw palettized data seldom works well, due to different
strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut
(unnaligned).


"Seldom"? That's only an issue (for 8 bpp) if the width
is not a multiple of 4.


It's an issue for 1 bpp data as well.


Not the parsing I meant :)
For 8bpp it can only happen if the width is not a multiple of 4.
For 1bpp it can only happen if the width is not a multiple of 16
(which is quite a bit more likely and thus I didn't want to use that one
as example).
___


I know you wouldn't want to :) Never mind, it's a minor issue compared 
to the others, as you say yourself.


Mats

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

Re: [FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS

[Andrew Shulgin]

Some Hikvison RTSP cameras send wrong sprop-parameter-sets in SDP - it's
missing PPS.

Example of correct sprop-parameter-sets:
sprop-parameter-sets=Z0IAH5W4PASaEAAAcIAAFfkAQA==,aM48gA==
Example of wrong sprop-parameter-sets:
sprop-parameter-sets=Z0IAH5WoPASaEAAAcIAAFfkIQA==,

My patch adds a workaround that ignores invalid sprop-parameter-sets.

On Sat, Feb 27, 2016 at 9:35 PM, Andrew Shulgin 
wrote:

> Sorry, wrong From: header, sended again with correct
>
> On Sat, Feb 27, 2016 at 9:30 PM, Andrew Shulgin  wrote:
>
>> ---
>>  libavformat/rtpdec_h264.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
>> index b399be4..e707d03 100644
>> --- a/libavformat/rtpdec_h264.c
>> +++ b/libavformat/rtpdec_h264.c
>> @@ -166,6 +166,10 @@ static int
>> sdp_parse_fmtp_config_h264(AVFormatContext *s,
>>  parse_profile_level_id(s, h264_data, value);
>>  } else if (!strcmp(attr, "sprop-parameter-sets")) {
>>  int ret;
>> +if (value[strlen(value) - 1] == ',') {
>> +av_log(s, AV_LOG_WARNING, "Missing PPS in
>> sprop-parameter-sets, ignoring\n");
>> +return 0;
>> +}
>>  codec->extradata_size = 0;
>>  av_freep(>extradata);
>>  ret = ff_h264_parse_sprop_parameter_sets(s, >extradata,
>> --
>> 2.4.10
>>
>
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 07:52:52PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:46 PM, Reimar Döffinger wrote:
> >On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> >>On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >>>That's not what e.g. the matroska demuxer produces, so stream
> >>>copying with some generic remuxing example I am really sure that is
> >>>NOT how the packets come in.
> >>>
> >>
> >>Stream copying of raw palettized data seldom works well, due to different
> >>strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut
> >>(unnaligned).
> >
> >"Seldom"? That's only an issue (for 8 bpp) if the width
> >is not a multiple of 4.
> 
> It's an issue for 1 bpp data as well.

Not the parsing I meant :)
For 8bpp it can only happen if the width is not a multiple of 4.
For 1bpp it can only happen if the width is not a multiple of 16
(which is quite a bit more likely and thus I didn't want to use that one
as example).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/7] vc2enc: carry over quantization index across frames as a starting point

[Rostislav Pehlivanov]

Previously a global average was used. Using the previous quantizer
resulted in a fairly significant speedup as slice size selection settled
down quicker.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index b39..5e11aa1 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -132,7 +132,7 @@ typedef struct VC2EncContext {
 int slice_max_bytes;
 int slice_min_bytes;
 int q_ceil;
-int q_start;
+int q_avg;
 
 /* Options */
 double tolerance;
@@ -675,7 +675,7 @@ static int rate_control(AVCodecContext *avctx, void *arg)
 const int sx = slice_dat->x;
 const int sy = slice_dat->y;
 int bits_last = INT_MAX, quant_buf[2] = {-1, -1};
-int quant = s->q_start, range = s->q_start/3;
+int quant = slice_dat->quant_idx, range = quant/5;
 const int top = slice_dat->bits_ceil;
 const int bottom = slice_dat->bits_floor;
 int bits = count_hq_slice(s, slice_dat->cache, _dat->cached_results,
@@ -791,7 +791,7 @@ static int encode_slices(VC2EncContext *s)
 for (slice_x = 0; slice_x < s->num_x; slice_x++) {
 SliceArgs *args = _args[s->num_x*slice_y + slice_x];
 init_put_bits(>pb, buf + skip, args->bytes);
-s->q_start = (s->q_start + args->quant_idx)/2;
+s->q_avg = (s->q_avg + args->quant_idx)/2;
 skip += args->bytes;
 }
 }
@@ -839,8 +839,6 @@ static int encode_slices(VC2EncContext *s)
  * of levels. The rest of the areas can be thought as the details needed
  * to restore the image perfectly to its original size.
  */
-
-
 static int dwt_plane(AVCodecContext *avctx, void *arg)
 {
 TransformArgs *transform_dat = arg;
@@ -996,7 +994,7 @@ static av_cold int vc2_encode_end(AVCodecContext *avctx)
 int i;
 VC2EncContext *s = avctx->priv_data;
 
-av_log(avctx, AV_LOG_INFO, "Qavg: %i\n", s->q_start);
+av_log(avctx, AV_LOG_INFO, "Qavg: %i\n", s->q_avg);
 
 for (i = 0; i < 3; i++) {
 ff_vc2enc_free_transforms(>transform_args[i].t);
@@ -1031,6 +1029,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
 s->base_vf   = -1;
 s->strict_compliance = 1;
 
+s->q_avg = 0;
+
 /* Mark unknown as progressive */
 s->interlaced = !((avctx->field_order == AV_FIELD_UNKNOWN) ||
   (avctx->field_order == AV_FIELD_PROGRESSIVE));
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 4/7] vc2enc: clip and warn when user bitrate set too low

[Rostislav Pehlivanov]

The encoder crashed on verly low bitrates since there wasn't enough
space allocated.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 5e11aa1..27db6c0 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1008,12 +1008,24 @@ static av_cold int vc2_encode_end(AVCodecContext *avctx)
 return 0;
 }
 
+static int minimum_frame_bits(VC2EncContext *s)
+{
+int slice_x, slice_y, bits = 0;
+s->size_scaler = 64;
+for (slice_y = 0; slice_y < s->num_y; slice_y++) {
+for (slice_x = 0; slice_x < s->num_x; slice_x++) {
+bits += count_hq_slice(s, NULL, NULL, slice_x, slice_y, s->q_ceil);
+}
+}
+return bits;
+}
 
 static av_cold int vc2_encode_init(AVCodecContext *avctx)
 {
 Plane *p;
 SubBand *b;
 int i, j, level, o, shift;
+int64_t bits_per_frame, min_bits_per_frame;
 VC2EncContext *s = avctx->priv_data;
 
 s->picture_number = 0;
@@ -1161,6 +1173,17 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
 }
 }
 
+bits_per_frame = av_rescale(avctx->bit_rate, avctx->time_base.num,
+ avctx->time_base.den);
+min_bits_per_frame = minimum_frame_bits(s) + 8*sizeof(LIBAVCODEC_IDENT) + 
8*40 + 8*2;
+if (bits_per_frame < min_bits_per_frame) {
+avctx->bit_rate = av_rescale(min_bits_per_frame, avctx->time_base.den,
+ avctx->time_base.num);
+av_log(avctx, AV_LOG_WARNING,
+   "Bitrate too low, clipping to minimum = %.2lf Mbps!\n",
+   (double)avctx->bit_rate/100.0f);
+}
+
 return 0;
 
 alloc_fail:
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 07:51:41PM +0100, Michael Niedermayer wrote:
> should rawvideo AVPackets palette use data[] or sidedata, honestly i
> do not know, but i dont think it makes a big difference
> even supporting both, likely only adds 3-5 lines of code or so
> its more a philosophical question

Not sure how much was in response to my complaints, but
if this parts was I think that misses my point, as I
agree that it doesn't matter which.
What matters though is:
The AVI demuxer creates AVPackets with palette in side data,
and the AVI muxer supports ONLY palette appended in the data.
How to fix it might be philosophical, but I think it's not
philosophical and fairly clear that that's just broken.
Even remuxing from AVI to AVI simply won't work without a
"decoder" (which is not an issue performance-wise, but it
is usability wise, how should a FFmpeg user know that for
paletted video and only that a lossless stream copy requires
"decoding" and "encoding"?).

> about existing API, i suspect there arent many applications that
> use ffmpegs demuxers without the decoders  for raw pal8, i might
> of course be wrong but this seems a rather uncommon case of a uncommon
> case. And muxers side it was all broken before mats ...

Well, then we know I can only blame Mats for "only" making it
better instead of perfect :)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 7/7] vc2enc: update default settings

[Rostislav Pehlivanov]

4 level transforms seem to work better for "real world content" although
testing on images still results in 5 level transforms needing less bits.

Slice sizes can now be reduced as they work better. The bits which would
have been wasted are now used.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index df71953..023e02b 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1244,10 +1244,10 @@ alloc_fail:
 
 #define VC2ENC_FLAGS (AV_OPT_FLAG_ENCODING_PARAM | AV_OPT_FLAG_VIDEO_PARAM)
 static const AVOption vc2enc_options[] = {
-{"tolerance", "Max undershoot in percent", offsetof(VC2EncContext, 
tolerance), AV_OPT_TYPE_DOUBLE, {.dbl = 10.0f}, 0.0f, 45.0f, VC2ENC_FLAGS, 
"tolerance"},
-{"slice_width",   "Slice width",  offsetof(VC2EncContext, slice_width), 
AV_OPT_TYPE_INT, {.i64 = 128}, 32, 1024, VC2ENC_FLAGS, "slice_width"},
-{"slice_height",  "Slice height", offsetof(VC2EncContext, slice_height), 
AV_OPT_TYPE_INT, {.i64 = 64}, 8, 1024, VC2ENC_FLAGS, "slice_height"},
-{"wavelet_depth", "Transform depth", offsetof(VC2EncContext, 
wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 5}, 1, 5, VC2ENC_FLAGS, 
"wavelet_depth"},
+{"tolerance", "Max undershoot in percent", offsetof(VC2EncContext, 
tolerance), AV_OPT_TYPE_DOUBLE, {.dbl = 5.0f}, 0.0f, 45.0f, VC2ENC_FLAGS, 
"tolerance"},
+{"slice_width",   "Slice width",  offsetof(VC2EncContext, slice_width), 
AV_OPT_TYPE_INT, {.i64 = 64}, 32, 1024, VC2ENC_FLAGS, "slice_width"},
+{"slice_height",  "Slice height", offsetof(VC2EncContext, slice_height), 
AV_OPT_TYPE_INT, {.i64 = 32}, 8, 1024, VC2ENC_FLAGS, "slice_height"},
+{"wavelet_depth", "Transform depth", offsetof(VC2EncContext, 
wavelet_depth), AV_OPT_TYPE_INT, {.i64 = 4}, 1, 5, VC2ENC_FLAGS, 
"wavelet_depth"},
 {"wavelet_type",  "Transform type",  offsetof(VC2EncContext, wavelet_idx), 
AV_OPT_TYPE_INT, {.i64 = VC2_TRANSFORM_9_7}, 0, VC2_TRANSFORMS_NB, 
VC2ENC_FLAGS, "wavelet_idx"},
 {"9_7",  "Deslauriers-Dubuc (9,7)", 0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_9_7},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
 {"5_3",  "LeGall (5,3)",0, AV_OPT_TYPE_CONST, 
{.i64 = VC2_TRANSFORM_5_3},INT_MIN, INT_MAX, VC2ENC_FLAGS, "wavelet_idx"},
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 1/7] vc2enc: cache bits per quantizer, calculate wasted bits

[Rostislav Pehlivanov]

Needed for following commits, also a speed increase.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 37 -
 1 file changed, 32 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index fd2abd5..1d74cd5 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -36,6 +36,9 @@
  * (COEF_LUT_TAB*MAX_QUANT_INDEX) since the sign is appended during encoding */
 #define COEF_LUT_TAB 2048
 
+/* Per slice quantization bit cost cache */
+#define SLICE_CACHED_QUANTIZERS 30
+
 enum VC2_QM {
 VC2_QM_DEF = 0,
 VC2_QM_COL,
@@ -61,14 +64,22 @@ typedef struct Plane {
 ptrdiff_t coef_stride;
 } Plane;
 
+typedef struct BitCostCache {
+int bits;
+int quantizer;
+} BitCostCache;
+
 typedef struct SliceArgs {
 PutBitContext pb;
+BitCostCache cache[SLICE_CACHED_QUANTIZERS];
+int cached_results;
 void *ctx;
 int x;
 int y;
 int quant_idx;
 int bits_ceil;
 int bits_floor;
+int bytes_left;
 int bytes;
 } SliceArgs;
 
@@ -583,13 +594,19 @@ static void encode_subband(VC2EncContext *s, 
PutBitContext *pb, int sx, int sy,
 }
 }
 
-static int count_hq_slice(VC2EncContext *s, int slice_x,
-  int slice_y, int quant_idx)
+static int count_hq_slice(VC2EncContext *s, BitCostCache *cache,
+  int *cached_results, int slice_x, int slice_y,
+  int quant_idx)
 {
-int x, y;
+int i, x, y;
 uint8_t quants[MAX_DWT_LEVELS][4];
 int bits = 0, p, level, orientation;
 
+if (cache && *cached_results)
+for (i = 0; i < *cached_results; i++)
+if (cache[i].quantizer == quant_idx)
+return cache[i].bits;
+
 bits += 8*s->prefix_bytes;
 bits += 8; /* quant_idx */
 
@@ -639,6 +656,12 @@ static int count_hq_slice(VC2EncContext *s, int slice_x,
 bits += pad_c*8;
 }
 
+if (cache) {
+cache[*cached_results].quantizer = quant_idx;
+cache[*cached_results].bits = bits;
+*cached_results = FFMIN(*cached_results + 1, SLICE_CACHED_QUANTIZERS);
+}
+
 return bits;
 }
 
@@ -655,12 +678,14 @@ static int rate_control(AVCodecContext *avctx, void *arg)
 int quant = s->q_start, range = s->q_start/3;
 const int top = slice_dat->bits_ceil;
 const int bottom = slice_dat->bits_floor;
-int bits = count_hq_slice(s, sx, sy, quant);
+int bits = count_hq_slice(s, slice_dat->cache, _dat->cached_results,
+  sx, sy, quant);
 range -= range & 1; /* Make it an even number */
 while ((bits > top) || (bits < bottom)) {
 range *= bits > top ? +1 : -1;
 quant = av_clip(quant + range, 0, s->q_ceil);
-bits = count_hq_slice(s, sx, sy, quant);
+bits = count_hq_slice(s, slice_dat->cache, _dat->cached_results,
+  sx, sy, quant);
 range = av_clip(range/2, 1, s->q_ceil);
 if (quant_buf[1] == quant) {
 quant = bits_last < bits ? quant_buf[0] : quant;
@@ -673,6 +698,7 @@ static int rate_control(AVCodecContext *avctx, void *arg)
 }
 slice_dat->quant_idx = av_clip(quant, 0, s->q_ceil);
 slice_dat->bytes = FFALIGN((bits >> 3), s->size_scaler) + 4 + 
s->prefix_bytes;
+slice_dat->bytes_left = s->slice_max_bytes - slice_dat->bytes;
 
 return 0;
 }
@@ -688,6 +714,7 @@ static void calc_slice_sizes(VC2EncContext *s)
 args->ctx = s;
 args->x = slice_x;
 args->y = slice_y;
+args->cached_results = 0;
 args->bits_ceil = s->slice_max_bytes << 3;
 args->bits_floor = s->slice_min_bytes << 3;
 }
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 6/7] vc2enc: redistribute leftover bytes

[Rostislav Pehlivanov]

This commit redistributes the leftover bytes amongst the top 150 slices
in terms of size (in the hopes that they'll be the ones bitrate starved).

A more perceptual method would probably need to cut bits off from slices
which don't need much, but that'll be implemented later.

The cached quantizer bit cost helped to keep this search from barely
taking CPU time.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 52 +++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 600a8ac..df71953 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -39,6 +39,9 @@
 /* Per slice quantization bit cost cache */
 #define SLICE_CACHED_QUANTIZERS 30
 
+/* Decides the cutoff point in # of slices to distribute the leftover bytes */
+#define SLICE_REDIST_TOTAL 150
+
 enum VC2_QM {
 VC2_QM_DEF = 0,
 VC2_QM_COL,
@@ -780,9 +783,13 @@ static int encode_hq_slice(AVCodecContext *avctx, void 
*arg)
 static int encode_slices(VC2EncContext *s)
 {
 uint8_t *buf;
-int slice_x, slice_y, skip = 0;
+int i, slice_x, slice_y, skip = 0;
+int bytes_left = 0;
 SliceArgs *enc_args = s->slice_args;
 
+int bytes_top[SLICE_REDIST_TOTAL] = {0};
+SliceArgs *top_loc[SLICE_REDIST_TOTAL] = {NULL};
+
 avpriv_align_put_bits(>pb);
 flush_put_bits(>pb);
 buf = put_bits_ptr(>pb);
@@ -790,6 +797,47 @@ static int encode_slices(VC2EncContext *s)
 for (slice_y = 0; slice_y < s->num_y; slice_y++) {
 for (slice_x = 0; slice_x < s->num_x; slice_x++) {
 SliceArgs *args = _args[s->num_x*slice_y + slice_x];
+bytes_left += args->bytes_left;
+for (i = 0; i < FFMIN(SLICE_REDIST_TOTAL, s->num_x*s->num_y); i++) 
{
+if (args->bytes > bytes_top[i]) {
+bytes_top[i] = args->bytes;
+top_loc[i] = args;
+break;
+}
+}
+}
+}
+
+while (1) {
+int distributed = 0;
+for (i = 0; i < FFMIN(SLICE_REDIST_TOTAL, s->num_x*s->num_y); i++) {
+SliceArgs *args;
+int bits, bytes, diff, prev_bytes, new_idx;
+if (bytes_left <= 0)
+break;
+if (!top_loc[i] || !top_loc[i]->quant_idx)
+break;
+args = top_loc[i];
+prev_bytes = args->bytes;
+new_idx = av_clip(args->quant_idx - 1, 0, s->q_ceil);
+bits = count_hq_slice(s, args->cache, >cached_results,
+  args->x, args->y, new_idx);
+bytes = FFALIGN((bits >> 3), s->size_scaler) + 4 + s->prefix_bytes;
+diff = bytes - prev_bytes;
+if ((bytes_left - diff) >= 0) {
+args->quant_idx = new_idx;
+args->bytes = bytes;
+bytes_left -= diff;
+distributed++;
+}
+}
+if (!distributed)
+break;
+}
+
+for (slice_y = 0; slice_y < s->num_y; slice_y++) {
+for (slice_x = 0; slice_x < s->num_x; slice_x++) {
+SliceArgs *args = _args[s->num_x*slice_y + slice_x];
 init_put_bits(>pb, buf + skip, args->bytes);
 s->q_avg = (s->q_avg + args->quant_idx)/2;
 skip += args->bytes;
@@ -1042,6 +1090,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
 s->strict_compliance = 1;
 
 s->q_avg = 0;
+s->slice_max_bytes = 0;
+s->slice_min_bytes = 0;
 
 /* Mark unknown as progressive */
 s->interlaced = !((avctx->field_order == AV_FIELD_UNKNOWN) ||
-- 
2.7.0

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

[FFmpeg-devel] [PATCH 5/7] vc2enc: allocate the DWT context with the current plane size

[Rostislav Pehlivanov]

Previously used the luma size only.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 27db6c0..600a8ac 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1142,8 +1142,8 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
 
 /* DWT init */
 if (ff_vc2enc_init_transforms(>transform_args[i].t,
-s->plane[0].coef_stride,
-s->plane[0].dwt_height))
+  s->plane[i].coef_stride,
+  s->plane[i].dwt_height))
 goto alloc_fail;
 }
 
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS

[Andrew Shulgin]

Sorry, wrong From: header, sended again with correct

On Sat, Feb 27, 2016 at 9:30 PM, Andrew Shulgin  wrote:

> ---
>  libavformat/rtpdec_h264.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
> index b399be4..e707d03 100644
> --- a/libavformat/rtpdec_h264.c
> +++ b/libavformat/rtpdec_h264.c
> @@ -166,6 +166,10 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext
> *s,
>  parse_profile_level_id(s, h264_data, value);
>  } else if (!strcmp(attr, "sprop-parameter-sets")) {
>  int ret;
> +if (value[strlen(value) - 1] == ',') {
> +av_log(s, AV_LOG_WARNING, "Missing PPS in
> sprop-parameter-sets, ignoring\n");
> +return 0;
> +}
>  codec->extradata_size = 0;
>  av_freep(>extradata);
>  ret = ff_h264_parse_sprop_parameter_sets(s, >extradata,
> --
> 2.4.10
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Ignore invalid sprop-parameter-sets missing PPS

[Andrew Shulgin]

---
 libavformat/rtpdec_h264.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index b399be4..e707d03 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -166,6 +166,10 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext *s,
 parse_profile_level_id(s, h264_data, value);
 } else if (!strcmp(attr, "sprop-parameter-sets")) {
 int ret;
+if (value[strlen(value) - 1] == ',') {
+av_log(s, AV_LOG_WARNING, "Missing PPS in sprop-parameter-sets, 
ignoring\n");
+return 0;
+}
 codec->extradata_size = 0;
 av_freep(>extradata);
 ret = ff_h264_parse_sprop_parameter_sets(s, >extradata,
-- 
2.4.10
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/7] vc2enc: use 32 bits for quantized coefficients LUT

[Rostislav Pehlivanov]

16 bits were definitely not enough and caused artifacts to appear on
images even on high bitrates.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 1d74cd5..b39 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -118,7 +118,7 @@ typedef struct VC2EncContext {
 uint8_t quant[MAX_DWT_LEVELS][4];
 
 /* Coefficient LUT */
-uint16_t *coef_lut_val;
+uint32_t *coef_lut_val;
 uint8_t  *coef_lut_len;
 
 int num_x; /* #slices horizontally */
@@ -162,7 +162,7 @@ static av_always_inline void put_padding(PutBitContext *pb, 
int bytes)
 put_bits(pb, bits, 0);
 }
 
-static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint16_t val)
+static av_always_inline void put_vc2_ue_uint(PutBitContext *pb, uint32_t val)
 {
 int i;
 int pbits = 0, bits = 0, topbit = 1, maxval = 1;
@@ -190,7 +190,7 @@ static av_always_inline void put_vc2_ue_uint(PutBitContext 
*pb, uint16_t val)
 put_bits(pb, bits*2 + 1, (pbits << 1) | 1);
 }
 
-static av_always_inline int count_vc2_ue_uint(uint16_t val)
+static av_always_inline int count_vc2_ue_uint(uint32_t val)
 {
 int topbit = 1, maxval = 1;
 
@@ -206,8 +206,8 @@ static av_always_inline int count_vc2_ue_uint(uint16_t val)
 return ff_log2(topbit)*2 + 1;
 }
 
-static av_always_inline void get_vc2_ue_uint(uint16_t val, uint8_t *nbits,
- uint16_t *eval)
+static av_always_inline void get_vc2_ue_uint(int val, uint8_t *nbits,
+ uint32_t *eval)
 {
 int i;
 int pbits = 0, bits = 0, topbit = 1, maxval = 1;
@@ -569,14 +569,14 @@ static void encode_subband(VC2EncContext *s, 
PutBitContext *pb, int sx, int sy,
 
 const int qfactor = ff_dirac_qscale_tab[quant];
 const uint8_t  *len_lut = >coef_lut_len[quant*COEF_LUT_TAB];
-const uint16_t *val_lut = >coef_lut_val[quant*COEF_LUT_TAB];
+const uint32_t *val_lut = >coef_lut_val[quant*COEF_LUT_TAB];
 
 dwtcoef *coeff = b->buf + top * b->stride;
 
 for (y = top; y < bottom; y++) {
 for (x = left; x < right; x++) {
 const int neg = coeff[x] < 0;
-uint16_t c_abs = FFABS(coeff[x]);
+uint32_t c_abs = FFABS(coeff[x]);
 if (c_abs < COEF_LUT_TAB) {
 const uint8_t len  = len_lut[c_abs];
 if (len == 1)
@@ -635,7 +635,7 @@ static int count_hq_slice(VC2EncContext *s, BitCostCache 
*cache,
 
 for (y = top; y < bottom; y++) {
 for (x = left; x < right; x++) {
-uint16_t c_abs = FFABS(buf[x]);
+uint32_t c_abs = FFABS(buf[x]);
 if (c_abs < COEF_LUT_TAB) {
 const int len = len_lut[c_abs];
 bits += len + (len != 1);
@@ -1155,7 +1155,7 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
 for (i = 0; i < s->q_ceil; i++) {
 for (j = 0; j < COEF_LUT_TAB; j++) {
 uint8_t  *len_lut = >coef_lut_len[i*COEF_LUT_TAB];
-uint16_t *val_lut = >coef_lut_val[i*COEF_LUT_TAB];
+uint32_t *val_lut = >coef_lut_val[i*COEF_LUT_TAB];
 get_vc2_ue_uint(QUANT(j, ff_dirac_qscale_tab[i]),
 _lut[j], _lut[j]);
 }
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 07:51 PM, Michael Niedermayer wrote:

On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:

On 02/27/2016 04:13 PM, Mats Peterson wrote:

On 02/27/2016 04:08 PM, Mats Peterson wrote:

On 02/27/2016 04:07 PM, Mats Peterson wrote:

On 02/27/2016 04:00 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a
packet
contains one at the end of the video data, as being AVPALETTE_SIZE
bytes
exclusively.


Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.

Mats



The nut format stores the PALETTE after the video data in the packets,
nothing else :)



In any case, on muxing, the packets will have the palette after the
video data in the packets, whether it's AVI or QuickTime. Neither
avienc.c or movenc.c uses any side data packets for the palette.

Michael's intention has been to enable palette switching in the middle
of the stream, hence storage of the palette in each packet, and AVI
supports it by using the 'xxpc' chunks in the video data. It is also
implemented by now.

Mats



Not that it couldn't be done with side data packets, though.


If it doesn't support side data then the muxers are plain broken.
If the nut muxer stores palette by appending it to the frames,
then the demuxer should split it out into side data.
Note that I am absolutely not a fan of this side data stuff,
but since we already decided to do it like that then that's
the way we need to go, not randomly doing one way in one
place and differently in another, that just makes for unusable
API.
The only reasons to support "palette appended to data" are
1) There are some existing users of the FFmpeg API that rely on it.
Ideally we should then change it so it works for all muxers, or
the other way round warn that this is a deprecated way of doing
things.
2) There are file formats that store it that way and we cannot easily
split it into side data. Not sure that can really happen.


palettes are a bit annoying, there are quite a few things

the chain generally is
demuxer -> decoder -> encoder -> muxer
OR
demuxer ---> muxer

Thus there are 2 interfaces, the demuxer -> muxer and the
decoder -> encoder interface
For the decoder -> encoder interface, the palette is in AVFrame.data[1]
the 8bit indexes as a width(stride) x height array in AVFrame.data[0]
that part is still easy

the demuxer -> muxer interface is more complex
in case of non raw, that is compressed codecs the palette can be in
a codec specific and inseprable format in AVPacket.data with the
rest of the compressed image.
but its also possible that there is no palette in AVPacket.data and
instead its stored in AVPackets side data which would be filled from
container specific chunks like avis PCxx or in  the global extradata

So even without rawvideo there already exist both sidedata and non
sidedata cases

additionally key frame AVPackets must together with the global
extradata contain a full palette to be decodeable.

some containers support storing "partial palettes", for example
avis PCxx chunks can do that, so one should at keyframes store a
full one but subequent non keyframes should only store the part that
differs from the previous.

The container specific compression like PCxx would semantically
best fit into the muxer

should rawvideo AVPackets palette use data[] or sidedata, honestly i
do not know, but i dont think it makes a big difference
even supporting both, likely only adds 3-5 lines of code or so
its more a philosophical question
is the palette like chroma or 

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 07:46 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:

On 02/27/2016 07:18 PM, Reimar Döffinger wrote:

That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.



Stream copying of raw palettized data seldom works well, due to different
strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut
(unnaligned).


"Seldom"? That's only an issue (for 8 bpp) if the width
is not a multiple of 4.


It's an issue for 1 bpp data as well.


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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Michael Niedermayer]

On Sat, Feb 27, 2016 at 05:45:57PM +0100, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
> > On 02/27/2016 04:13 PM, Mats Peterson wrote:
> > >On 02/27/2016 04:08 PM, Mats Peterson wrote:
> > >>On 02/27/2016 04:07 PM, Mats Peterson wrote:
> > >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
> > On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
> > >On 02/27/2016 03:37 PM, Mats Peterson wrote:
> > >>
> > >>
> > >>
> > >>___
> > >>ffmpeg-devel mailing list
> > >>ffmpeg-devel@ffmpeg.org
> > >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >>
> > >
> > >I suppose this is what you mean, Reimar. Treating the palette, if a
> > >packet
> > >contains one at the end of the video data, as being AVPALETTE_SIZE
> > >bytes
> > >exclusively.
> > 
> > Well, actually not really.
> > If the palette is part of input frame it should be sent as side
> > data.
> > I am not sure where this variant comes from.
> > It might be that it should just be written as is.
> > Or even if the palette needs to be split it might be
> > necessary to auto-detect the palette size via
> > packet size - (width*height*bits per pixel)/8.
> > But as said, I am fairly unclear on what case that
> > code is supposed to handle.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > >>>
> > >>>I agree that it should be stored in a side data packet myself normally,
> > >>>and that this is a somewhat weird construction. It probably has to do
> > >>>with the nut format originally, which stores raw palettized data after
> > >>>the video data in the packets. Anyway, I have accepted the facts. For
> > >>>the record, the new ff_reshuffle_raw_rgb() function written by Michael
> > >>>in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
> > >>>will set a CONTAINS_PAL flag if the packet size is larger than the
> > >>>actual video data. He has hardcoded the palette size to 1024 bytes in
> > >>>that file.
> > >>>
> > >>>Mats
> > >>>
> > >>
> > >>The nut format stores the PALETTE after the video data in the packets,
> > >>nothing else :)
> > >>
> > >
> > >In any case, on muxing, the packets will have the palette after the
> > >video data in the packets, whether it's AVI or QuickTime. Neither
> > >avienc.c or movenc.c uses any side data packets for the palette.
> > >
> > >Michael's intention has been to enable palette switching in the middle
> > >of the stream, hence storage of the palette in each packet, and AVI
> > >supports it by using the 'xxpc' chunks in the video data. It is also
> > >implemented by now.
> > >
> > >Mats
> > >
> > 
> > Not that it couldn't be done with side data packets, though.
> 
> If it doesn't support side data then the muxers are plain broken.
> If the nut muxer stores palette by appending it to the frames,
> then the demuxer should split it out into side data.
> Note that I am absolutely not a fan of this side data stuff,
> but since we already decided to do it like that then that's
> the way we need to go, not randomly doing one way in one
> place and differently in another, that just makes for unusable
> API.
> The only reasons to support "palette appended to data" are
> 1) There are some existing users of the FFmpeg API that rely on it.
>Ideally we should then change it so it works for all muxers, or
>the other way round warn that this is a deprecated way of doing
>things.
> 2) There are file formats that store it that way and we cannot easily
>split it into side data. Not sure that can really happen.

palettes are a bit annoying, there are quite a few things

the chain generally is
demuxer -> decoder -> encoder -> muxer
OR
demuxer ---> muxer

Thus there are 2 interfaces, the demuxer -> muxer and the
decoder -> encoder interface
For the decoder -> encoder interface, the palette is in AVFrame.data[1]
the 8bit indexes as a width(stride) x height array in AVFrame.data[0]
that part is still easy

the demuxer -> muxer interface is more complex
in case of non raw, that is compressed codecs the palette can be in
a codec specific and inseprable format in AVPacket.data with the
rest of the compressed image.
but its also possible that there is no palette in AVPacket.data and
instead its stored in AVPackets side data which would be filled from
container specific chunks like avis PCxx or in  the global extradata

So even without rawvideo there already exist both sidedata and non
sidedata cases

additionally key frame AVPackets must together with the global
extradata contain a full palette to be decodeable.

some containers support storing "partial palettes", for example
avis PCxx chunks can do that, so one should at keyframes 

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 07:40:44PM +0100, Mats Peterson wrote:
> On 02/27/2016 07:18 PM, Reimar Döffinger wrote:
> >That's not what e.g. the matroska demuxer produces, so stream
> >copying with some generic remuxing example I am really sure that is
> >NOT how the packets come in.
> >
> 
> Stream copying of raw palettized data seldom works well, due to different
> strides of AVI (4-byte aligned), QuickTime (2-byte aligned) and nut
> (unnaligned).

"Seldom"? That's only an issue (for 8 bpp) if the width
is not a multiple of 4.
To me that sounds like a minor issue compared to
"we designed our demuxers to use a format completely
different from our muxers".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 07:40 PM, Mats Peterson wrote:

On 02/27/2016 07:18 PM, Reimar Döffinger wrote:

That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.



Stream copying of raw palettized data seldom works well, due to
different strides of AVI (4-byte aligned), QuickTime (2-byte aligned)
and nut (unnaligned).



unaligned, not unnaligned.

--
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 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 07:18 PM, Reimar Döffinger wrote:

That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.



Stream copying of raw palettized data seldom works well, due to 
different strides of AVI (4-byte aligned), QuickTime (2-byte aligned) 
and nut (unnaligned).


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 07:18 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote:

On 02/27/2016 05:45 PM, Reimar Döffinger wrote:

Not that it couldn't be done with side data packets, though.


If it doesn't support side data then the muxers are plain broken.


The muxers should support side data, I agree on that. The thing is the
packets come in to the AVI, QuickTime and nut muxers with the palette data
appended to the video data in the packets.


You never answered that actually...
How do the come in that way?!?
That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.



That's apparently how things work in FFmpeg at the moment. There is 
currently no palette side data used by the *FFmpeg* muxers. The palette 
is appended to the packets. Ask Michael for further details, he can 
probably explain this better than me.




I can't see HOW they even COULD work right now?!
Otherwise I wouldn't really care, but as far as I can
tell I don't see how it could work at all but for
some lucky exceptions.
What cases have we actually tested to work?
___


In spite of the mixed use of side data and palette in packets, things 
work just fine. FFplay currently plays all palettized files correctly, 
and FFmpeg produces palettized files correctly, after my recent patches.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 06:05:20PM +0100, Mats Peterson wrote:
> On 02/27/2016 05:45 PM, Reimar Döffinger wrote:
> >>Not that it couldn't be done with side data packets, though.
> >
> >If it doesn't support side data then the muxers are plain broken.
> 
> The muxers should support side data, I agree on that. The thing is the
> packets come in to the AVI, QuickTime and nut muxers with the palette data
> appended to the video data in the packets.

You never answered that actually...
How do the come in that way?!?
That's not what e.g. the matroska demuxer produces, so stream
copying with some generic remuxing example I am really sure that is
NOT how the packets come in.

> That's a choice Michael have
> made, I think. Possibly someone else, I don't know. Anyway, Michael once
> told me that he would like to view palettized frames as "self-contained",
> where the palette is part of the video data in an atomic way.

I'd be fine with that.
Except that is simply not the way it is currently as far as I can tell.

> Anyway, things work OK right now, and even if the situation is slightly
> confusing, it's probably not a good idea to start messing around with things
> until a clearly defined way of storing the palette for the muxers and
> demuxers has been presented.

I can't see HOW they even COULD work right now?!
Otherwise I wouldn't really care, but as far as I can
tell I don't see how it could work at all but for
some lucky exceptions.
What cases have we actually tested to work?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Regarding palettes in FFmpeg (again)

[Mats Peterson]

My observation of the current state of palette storage in FFmpeg is as 
follows:


On the demuxer side, side data packets are usually used for the palette, 
except for nut, where the palette is appended to the video data in each 
packet, in the same way as on the muxer side.


On the muxer side, the palette is appended to the video data in each 
packet. No side data is currently used.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 05:45 PM, Reimar Döffinger wrote:

I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.

Mats



The nut format stores the PALETTE after the video data in the packets,
nothing else :)



In any case, on muxing, the packets will have the palette after the
video data in the packets, whether it's AVI or QuickTime. Neither
avienc.c or movenc.c uses any side data packets for the palette.

Michael's intention has been to enable palette switching in the middle
of the stream, hence storage of the palette in each packet, and AVI
supports it by using the 'xxpc' chunks in the video data. It is also
implemented by now.

Mats



Not that it couldn't be done with side data packets, though.


If it doesn't support side data then the muxers are plain broken.


The muxers should support side data, I agree on that. The thing is the 
packets come in to the AVI, QuickTime and nut muxers with the palette 
data appended to the video data in the packets. That's a choice Michael 
have made, I think. Possibly someone else, I don't know. Anyway, Michael 
once told me that he would like to view palettized frames as 
"self-contained", where the palette is part of the video data in an 
atomic way.



If the nut muxer stores palette by appending it to the frames,
then the demuxer should split it out into side data.
Note that I am absolutely not a fan of this side data stuff,
but since we already decided to do it like that then that's
the way we need to go, not randomly doing one way in one
place and differently in another, that just makes for unusable
API.


I agree on that. I'm a bit confused myself about the differing ways of 
storing the palette...



2) There are file formats that store it that way and we cannot easily
split it into side data. Not sure that can really happen.


nut stores the palette in every frame in the file, in its current shape.

Anyway, things work OK right now, and even if the situation is slightly 
confusing, it's probably not a good idea to start messing around with 
things until a clearly defined way of storing the palette for the muxers 
and demuxers has been presented.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 04:15:10PM +0100, Mats Peterson wrote:
> On 02/27/2016 04:13 PM, Mats Peterson wrote:
> >On 02/27/2016 04:08 PM, Mats Peterson wrote:
> >>On 02/27/2016 04:07 PM, Mats Peterson wrote:
> >>>On 02/27/2016 04:00 PM, Reimar Döffinger wrote:
> On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
> >On 02/27/2016 03:37 PM, Mats Peterson wrote:
> >>
> >>
> >>
> >>___
> >>ffmpeg-devel mailing list
> >>ffmpeg-devel@ffmpeg.org
> >>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> >I suppose this is what you mean, Reimar. Treating the palette, if a
> >packet
> >contains one at the end of the video data, as being AVPALETTE_SIZE
> >bytes
> >exclusively.
> 
> Well, actually not really.
> If the palette is part of input frame it should be sent as side
> data.
> I am not sure where this variant comes from.
> It might be that it should just be written as is.
> Or even if the palette needs to be split it might be
> necessary to auto-detect the palette size via
> packet size - (width*height*bits per pixel)/8.
> But as said, I am fairly unclear on what case that
> code is supposed to handle.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> >>>
> >>>I agree that it should be stored in a side data packet myself normally,
> >>>and that this is a somewhat weird construction. It probably has to do
> >>>with the nut format originally, which stores raw palettized data after
> >>>the video data in the packets. Anyway, I have accepted the facts. For
> >>>the record, the new ff_reshuffle_raw_rgb() function written by Michael
> >>>in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
> >>>will set a CONTAINS_PAL flag if the packet size is larger than the
> >>>actual video data. He has hardcoded the palette size to 1024 bytes in
> >>>that file.
> >>>
> >>>Mats
> >>>
> >>
> >>The nut format stores the PALETTE after the video data in the packets,
> >>nothing else :)
> >>
> >
> >In any case, on muxing, the packets will have the palette after the
> >video data in the packets, whether it's AVI or QuickTime. Neither
> >avienc.c or movenc.c uses any side data packets for the palette.
> >
> >Michael's intention has been to enable palette switching in the middle
> >of the stream, hence storage of the palette in each packet, and AVI
> >supports it by using the 'xxpc' chunks in the video data. It is also
> >implemented by now.
> >
> >Mats
> >
> 
> Not that it couldn't be done with side data packets, though.

If it doesn't support side data then the muxers are plain broken.
If the nut muxer stores palette by appending it to the frames,
then the demuxer should split it out into side data.
Note that I am absolutely not a fan of this side data stuff,
but since we already decided to do it like that then that's
the way we need to go, not randomly doing one way in one
place and differently in another, that just makes for unusable
API.
The only reasons to support "palette appended to data" are
1) There are some existing users of the FFmpeg API that rely on it.
   Ideally we should then change it so it works for all muxers, or
   the other way round warn that this is a deprecated way of doing
   things.
2) There are file formats that store it that way and we cannot easily
   split it into side data. Not sure that can really happen.

___
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

[Michael Niedermayer]

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 805c7b95433f1bfbbc5d47fd59a1bbb755edb112 Mon Sep 17 00:00:00 2001
> From: Matthieu Bouron 
> Date: Thu, 21 Jan 2016 09:29:39 +0100
> Subject: [PATCH 2/2] lavc: add h264 mediacodec decoder

breaks fate
swr-resample_lin-fltp-48000-44100
TESTswr-resample_lin-dblp-8000-44100
TESTswr-resample_lin-dblp-8000-48000
--- ./tests/ref/fate/source 2016-02-24 22:42:26.379879152 +0100
+++ tests/data/fate/source  2016-02-27 14:44:09.176735216 +0100
@@ -27,3 +27,4 @@
 compat/avisynth/windowsPorts/windows2linux.h
 compat/float/float.h
 compat/float/limits.h
+libavcodec/mediacodec_sw_buffer.h
Test source failed. Look at tests/data/fate/source.err for details.
make: *** [fate-source] Error 1
make: *** Waiting for unfinished jobs


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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


signature.asc
Description: Digital signature

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 04:13 PM, Mats Peterson wrote:

On 02/27/2016 04:08 PM, Mats Peterson wrote:

On 02/27/2016 04:07 PM, Mats Peterson wrote:

On 02/27/2016 04:00 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a
packet
contains one at the end of the video data, as being AVPALETTE_SIZE
bytes
exclusively.


Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.

Mats



The nut format stores the PALETTE after the video data in the packets,
nothing else :)



In any case, on muxing, the packets will have the palette after the
video data in the packets, whether it's AVI or QuickTime. Neither
avienc.c or movenc.c uses any side data packets for the palette.

Michael's intention has been to enable palette switching in the middle
of the stream, hence storage of the palette in each packet, and AVI
supports it by using the 'xxpc' chunks in the video data. It is also
implemented by now.

Mats



Not that it couldn't be done with side data packets, though.

--
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 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 04:08 PM, Mats Peterson wrote:

On 02/27/2016 04:07 PM, Mats Peterson wrote:

On 02/27/2016 04:00 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a
packet
contains one at the end of the video data, as being AVPALETTE_SIZE
bytes
exclusively.


Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.

Mats



The nut format stores the PALETTE after the video data in the packets,
nothing else :)



In any case, on muxing, the packets will have the palette after the 
video data in the packets, whether it's AVI or QuickTime. Neither 
avienc.c or movenc.c uses any side data packets for the palette.


Michael's intention has been to enable palette switching in the middle 
of the stream, hence storage of the palette in each packet, and AVI 
supports it by using the 'xxpc' chunks in the video data. It is also 
implemented by now.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 04:07 PM, Mats Peterson wrote:

On 02/27/2016 04:00 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a
packet
contains one at the end of the video data, as being AVPALETTE_SIZE bytes
exclusively.


Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I agree that it should be stored in a side data packet myself normally,
and that this is a somewhat weird construction. It probably has to do
with the nut format originally, which stores raw palettized data after
the video data in the packets. Anyway, I have accepted the facts. For
the record, the new ff_reshuffle_raw_rgb() function written by Michael
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime,
will set a CONTAINS_PAL flag if the packet size is larger than the
actual video data. He has hardcoded the palette size to 1024 bytes in
that file.

Mats



The nut format stores the PALETTE after the video data in the packets, 
nothing else :)


--
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 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 04:00 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a packet
contains one at the end of the video data, as being AVPALETTE_SIZE bytes
exclusively.


Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I agree that it should be stored in a side data packet myself normally, 
and that this is a somewhat weird construction. It probably has to do 
with the nut format originally, which stores raw palettized data after 
the video data in the packets. Anyway, I have accepted the facts. For 
the record, the new ff_reshuffle_raw_rgb() function written by Michael 
in lavf/rawutils.c that aligns strides properly for AVI and QuickTime, 
will set a CONTAINS_PAL flag if the packet size is larger than the 
actual video data. He has hardcoded the palette size to 1024 bytes in 
that file.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 03:57:06PM +0100, Mats Peterson wrote:
> On 02/27/2016 03:37 PM, Mats Peterson wrote:
> >
> >
> >
> >___
> >ffmpeg-devel mailing list
> >ffmpeg-devel@ffmpeg.org
> >http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> 
> I suppose this is what you mean, Reimar. Treating the palette, if a packet
> contains one at the end of the video data, as being AVPALETTE_SIZE bytes
> exclusively.

Well, actually not really.
If the palette is part of input frame it should be sent as side
data.
I am not sure where this variant comes from.
It might be that it should just be written as is.
Or even if the palette needs to be split it might be
necessary to auto-detect the palette size via
packet size - (width*height*bits per pixel)/8.
But as said, I am fairly unclear on what case that
code is supposed to handle.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

On 02/27/2016 03:37 PM, Mats Peterson wrote:




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



I suppose this is what you mean, Reimar. Treating the palette, if a 
packet contains one at the end of the video data, as being 
AVPALETTE_SIZE bytes exclusively.


Mats

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

[FFmpeg-devel] [PATCH 2/2] lavf/movenc: Simplify palette handling

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From eec3d4bb49d0ac4b73a10f8436d517a130999892 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 27 Feb 2016 15:31:35 +0100
Subject: [PATCH 2/2] lavf/movenc: Simplify palette handling

---
 libavformat/movenc.c |9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index e0223b2..bf9e1e0 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1718,11 +1718,12 @@ static int mov_write_video_tag(AVIOContext *pb, MOVMuxContext *mov, MOVTrack *tr
 
 if (track->is_unaligned_qt_rgb && track->enc->pix_fmt == AV_PIX_FMT_PAL8) {
 int i;
+int pal_size = 1 << track->enc->bits_per_coded_sample;
 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++) {
+avio_wb16(pb, pal_size - 1);  /* Color table size (zero-relative) */
+for (i = 0; i < pal_size; i++) {
 uint32_t rgb = AV_RL32(>palette[i]);
 uint16_t r = (rgb >> 16) & 0xff;
 uint16_t g = (rgb >> 8)  & 0xff;
@@ -4769,9 +4770,7 @@ static int mov_write_packet(AVFormatContext *s, AVPacket *pkt)
 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);
+memcpy(trk->palette, data + size - AVPALETTE_SIZE, AVPALETTE_SIZE);
 trk->pal_done++;
 } else if (trk->enc->pix_fmt == AV_PIX_FMT_GRAY8 ||
trk->enc->pix_fmt == AV_PIX_FMT_MONOBLACK) {
-- 
1.7.10.4

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

[FFmpeg-devel] [PATCH 1/2] lavf/avienc: Simplify palette handling

[Mats Peterson]

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 309ee0932eda48b340f2da9f2bc9ac3ea667edf9 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 27 Feb 2016 15:31:08 +0100
Subject: [PATCH 1/2] lavf/avienc: Simplify palette handling

---
 libavformat/avienc.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avienc.c b/libavformat/avienc.c
index ca505f4..b133bee 100644
--- a/libavformat/avienc.c
+++ b/libavformat/avienc.c
@@ -683,7 +683,7 @@ static int avi_write_packet(AVFormatContext *s, AVPacket *pkt)
 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 = AV_RL32(data + size - AVPALETTE_SIZE + 4*i);
 avio_wl32(pb, v & 0xff);
 }
 avio_seek(pb, cur_offset, SEEK_SET);
@@ -696,7 +696,7 @@ 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 = AV_RL32(data + size - AVPALETTE_SIZE + 4*i);
 avio_wb32(pb, v<<8);
 }
 ff_end_tag(pb, pc_tag);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

On 02/27/2016 03:11 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote:

And yes, QuickTime has a "default palette" for each bit depth that it can
use, and no palette will be stored in the video sample description in that
case. But that's only sensible to use for 1 bpp black & white or 8 bpp
grayscale (and that's what I'm doing in movenc.c), since in other cases
comparing each color of the current palette with the default Macintosh
palette is a bit of overkill in my book.


It's 256 comparisons to save 1 kB.
It's not a big deal, but it seems like fairly cheap optimization to do.
___


Perhaps so. But it's no big deal to include the palette either, I think. 
1 kb isn't a humonguous amount nowadays. To each his own, of course :) 
Most of the time the palette won't be the default Macintosh palette 
either, when converting from AVI or from other sources and pixel formats.


Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 02:58:39PM +0100, Mats Peterson wrote:
> And yes, QuickTime has a "default palette" for each bit depth that it can
> use, and no palette will be stored in the video sample description in that
> case. But that's only sensible to use for 1 bpp black & white or 8 bpp
> grayscale (and that's what I'm doing in movenc.c), since in other cases
> comparing each color of the current palette with the default Macintosh
> palette is a bit of overkill in my book.

It's 256 comparisons to save 1 kB.
It's not a big deal, but it seems like fairly cheap optimization to do.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

On 02/27/2016 02:55 PM, Mats Peterson wrote:

On 02/27/2016 02:44 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:

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

Currently the only palettized pixel format in FFmpeg is
AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of palette entries in packets
containing a palette at the end, rather than just assuming 256 entries.

If we can agree on using this 1 << bits_per_coded_sample logic overall
for packets containing a palette, in the same way as it is done in AVI
and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it
somewhat more future-proof.


On the other hand, perhaps we should leave the palette in the packets
fixed
at 256 entries (1024 bytes), since it's somewhat irrelevant whether this
"internal" palette contains 256 or less entries. It's when writing
the files
that the number of palette entries becomes important.


That is the intention. How many palette entries are saved in the format
is up to the format (many QT formats for example don't save one at all
but instead refer to standard ones if possible).
Also there would be a (minor) advantage if shorter palettes were required
to be repeated in those 256 byte entries.
It would save on bit masking when expanding to a non-paletted format.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



Yes, Reimar. I suppose that's the intent, and we agree on the file
format determining the number of entries that will be written to the
file for each bit depth.

Mats



And yes, QuickTime has a "default palette" for each bit depth that it 
can use, and no palette will be stored in the video sample description 
in that case. But that's only sensible to use for 1 bpp black & white or 
8 bpp grayscale (and that's what I'm doing in movenc.c), since in other 
cases comparing each color of the current palette with the default 
Macintosh palette is a bit of overkill in my book.


Mats

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

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

On 02/27/2016 02:44 PM, Reimar Döffinger wrote:

On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:

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

Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of palette entries in packets
containing a palette at the end, rather than just assuming 256 entries.

If we can agree on using this 1 << bits_per_coded_sample logic overall
for packets containing a palette, in the same way as it is done in AVI
and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it
somewhat more future-proof.


On the other hand, perhaps we should leave the palette in the packets fixed
at 256 entries (1024 bytes), since it's somewhat irrelevant whether this
"internal" palette contains 256 or less entries. It's when writing the files
that the number of palette entries becomes important.


That is the intention. How many palette entries are saved in the format
is up to the format (many QT formats for example don't save one at all
but instead refer to standard ones if possible).
Also there would be a (minor) advantage if shorter palettes were required
to be repeated in those 256 byte entries.
It would save on bit masking when expanding to a non-paletted format.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



Yes, Reimar. I suppose that's the intent, and we agree on the file 
format determining the number of entries that will be written to the 
file for each bit depth.


Mats

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

Re: [FFmpeg-devel] [PATCH 1/3] lavu/attributes: introduce av_likely, av_unlikely

[Ronald S. Bultje]

Hi,

On Sat, Feb 27, 2016 at 8:11 AM, Ganesh Ajjanagadde 
wrote:

> On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes 
> wrote:
> > On Thu, Feb 25, 2016 at 8:27 AM, wm4  wrote:
> >> On Thu, 25 Feb 2016 15:48:17 +1100
> >> Matt Oliver  wrote:
> >>
> >>> On 25 February 2016 at 13:20, Ganesh Ajjanagadde 
> wrote:
> >>>
> >>> > From: Ganesh Ajjanagadde 
> >>> >
> >>> > These use __builtin_expect, and may be useful for optimizing nearly
> >>> > certain branches, to yield size and/or speed improvements.
> >>> >
> >>> > Note that this is used in the Linux kernel for the same purpose. For
> >>> > some idea as to potential benefits, see e.g
> >>> >
> http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html.
> >>> >
> >>> > Signed-off-by: Ganesh Ajjanagadde 
> >>> > ---
> >>> >  libavutil/attributes.h | 8 
> >>> >  1 file changed, 8 insertions(+)
> >>> >
> >>> > diff --git a/libavutil/attributes.h b/libavutil/attributes.h
> >>> > index 5c6b9de..1547033 100644
> >>> > --- a/libavutil/attributes.h
> >>> > +++ b/libavutil/attributes.h
> >>> > @@ -58,6 +58,14 @@
> >>> >  #define av_warn_unused_result
> >>> >  #endif
> >>> >
> >>> > +#if AV_GCC_VERSION_AT_LEAST(3,0)
> >>> > +#define av_likely(x) __builtin_expect(!!(x), 1)
> >>> > +#define av_unlikely(x) __builtin_expect(!!(x), 0)
> >>> > +#else
> >>> > +#define av_likely(x) (x)
> >>> > +#define av_unlikely(x) (x)
> >>> > +#endif
> >>> > +
> >>> >  #if AV_GCC_VERSION_AT_LEAST(3,1)
> >>> >  #define av_noinline __attribute__((noinline))
> >>> >  #elif defined(_MSC_VER)
> >>> >
> >>>
> >>> Ive used these builtins before and can confirm that they are useful
> >>> (although requires devs to use them obviously). I will also point out
> that
> >>> these are also supported by ICC/ICL as well.
> >>
> >> They also make code ugly as fuck, and are more cargo-cult than anything
> >> else. They might possibly be ok in some very critical parts of the
> >> code, but otherwise not at all.
> >>
> >
> > I agree with wm4 on the ugly aspect, I always hate reading code from
> > projects that use it, its terrible on readability.
> > If its used at all, it should be proven that (a) the function is
> > performance relevant, and (b) that the improvement is actually
> > tangible in the grand scheme.
>
> I mostly agree with the sentiments. Patchset shelved until a
> non-trivial, critical use case can be found.


I can think of a few. E.g. buffer overflow protection in bitstream reader
(get_bits.h), maybe the arith readers (vp56.h, cabac.h) could also use
these. These codepaths are actually quite performance sensitive and I'm not
sure they're all running hand-coded assembly.

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

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 02:35:36PM +0100, Mats Peterson wrote:
> On 02/27/2016 02:03 PM, Mats Peterson wrote:
> >Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
> >In case there will be other palettized formats in the future, I have
> >"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
> >movenc.c for calculating the number of palette entries in packets
> >containing a palette at the end, rather than just assuming 256 entries.
> >
> >If we can agree on using this 1 << bits_per_coded_sample logic overall
> >for packets containing a palette, in the same way as it is done in AVI
> >and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it
> >somewhat more future-proof.
> 
> On the other hand, perhaps we should leave the palette in the packets fixed
> at 256 entries (1024 bytes), since it's somewhat irrelevant whether this
> "internal" palette contains 256 or less entries. It's when writing the files
> that the number of palette entries becomes important.

That is the intention. How many palette entries are saved in the format
is up to the format (many QT formats for example don't save one at all
but instead refer to standard ones if possible).
Also there would be a (minor) advantage if shorter palettes were required
to be repeated in those 256 byte entries.
It would save on bit masking when expanding to a non-paletted format.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

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

Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8.
In case there will be other palettized formats in the future, I have
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and
movenc.c for calculating the number of palette entries in packets
containing a palette at the end, rather than just assuming 256 entries.

If we can agree on using this 1 << bits_per_coded_sample logic overall
for packets containing a palette, in the same way as it is done in AVI
and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it
somewhat more future-proof.

Mats



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



On the other hand, perhaps we should leave the palette in the packets 
fixed at 256 entries (1024 bytes), since it's somewhat irrelevant 
whether this "internal" palette contains 256 or less entries. It's when 
writing the files that the number of palette entries becomes important.


Mats

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

Re: [FFmpeg-devel] [PATCH 2/3] lavu/rational: use av_unlikely in av_d2q

[Ganesh Ajjanagadde]

On Thu, Feb 25, 2016 at 7:25 AM, Nicolas George  wrote:
> Le sextidi 6 ventôse, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Actual performance benefit is impossible to accurately quantify due to the
>> context-dependence of the branch predictor. Nonetheless, as a ballpark
>> estimate, it yields ~ 5% improvements in testing via FATE on x86-64, 
>> Haswell+GCC.
>
> Five percent is huge, if it is five percent of something relevant. Can you
> give a few more details?

Ok, here are the benches I obtained, make fate lavf-ffm, START/STOP
around body of av_d2q. Platform: Haswell+GCC under -march=native.
Naive stream_loop does not increase the iteration count unfortunately.
As for av_d2q's relevance, max call count on any FATE test is 16 or 32
IIRC.

old:
  74040 decicycles in av_d2q,   1 runs,  0 skips
  39480 decicycles in av_d2q,   2 runs,  0 skips
  21385 decicycles in av_d2q,   4 runs,  0 skips
[...]
  13235 decicycles in av_d2q,   8 runs,  0 skips
[...]
   7571 decicycles in av_d2q,  16 runs,  0 skips

new:
  68660 decicycles in av_d2q,   1 runs,  0 skips
  36410 decicycles in av_d2q,   2 runs,  0 skips
  19815 decicycles in av_d2q,   4 runs,  0 skips
[...]
  12355 decicycles in av_d2q,   8 runs,  0 skips
[...]
   7080 decicycles in av_d2q,  16 runs,  0 skips

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> 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 1/3] lavu/attributes: introduce av_likely, av_unlikely

[Ganesh Ajjanagadde]

On Thu, Feb 25, 2016 at 8:55 AM, Hendrik Leppkes  wrote:
> On Thu, Feb 25, 2016 at 8:27 AM, wm4  wrote:
>> On Thu, 25 Feb 2016 15:48:17 +1100
>> Matt Oliver  wrote:
>>
>>> On 25 February 2016 at 13:20, Ganesh Ajjanagadde  wrote:
>>>
>>> > From: Ganesh Ajjanagadde 
>>> >
>>> > These use __builtin_expect, and may be useful for optimizing nearly
>>> > certain branches, to yield size and/or speed improvements.
>>> >
>>> > Note that this is used in the Linux kernel for the same purpose. For
>>> > some idea as to potential benefits, see e.g
>>> > http://blog.man7.org/2012/10/how-much-do-builtinexpect-likely-and.html.
>>> >
>>> > Signed-off-by: Ganesh Ajjanagadde 
>>> > ---
>>> >  libavutil/attributes.h | 8 
>>> >  1 file changed, 8 insertions(+)
>>> >
>>> > diff --git a/libavutil/attributes.h b/libavutil/attributes.h
>>> > index 5c6b9de..1547033 100644
>>> > --- a/libavutil/attributes.h
>>> > +++ b/libavutil/attributes.h
>>> > @@ -58,6 +58,14 @@
>>> >  #define av_warn_unused_result
>>> >  #endif
>>> >
>>> > +#if AV_GCC_VERSION_AT_LEAST(3,0)
>>> > +#define av_likely(x) __builtin_expect(!!(x), 1)
>>> > +#define av_unlikely(x) __builtin_expect(!!(x), 0)
>>> > +#else
>>> > +#define av_likely(x) (x)
>>> > +#define av_unlikely(x) (x)
>>> > +#endif
>>> > +
>>> >  #if AV_GCC_VERSION_AT_LEAST(3,1)
>>> >  #define av_noinline __attribute__((noinline))
>>> >  #elif defined(_MSC_VER)
>>> >
>>>
>>> Ive used these builtins before and can confirm that they are useful
>>> (although requires devs to use them obviously). I will also point out that
>>> these are also supported by ICC/ICL as well.
>>
>> They also make code ugly as fuck, and are more cargo-cult than anything
>> else. They might possibly be ok in some very critical parts of the
>> code, but otherwise not at all.
>>
>
> I agree with wm4 on the ugly aspect, I always hate reading code from
> projects that use it, its terrible on readability.
> If its used at all, it should be proven that (a) the function is
> performance relevant, and (b) that the improvement is actually
> tangible in the grand scheme.

I mostly agree with the sentiments. Patchset shelved until a
non-trivial, critical use case can be found.

@Matt: feel free to extend to ICC if/when this happens; I lack it and
can't test.

Thanks all.

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

[FFmpeg-devel] [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

[Mats Peterson]

Currently the only palettized pixel format in FFmpeg is AV_PIX_FMT_PAL8. 
In case there will be other palettized formats in the future, I have 
"guarded" myself by using 1 << bits_per_coded_sample in avienc.c and 
movenc.c for calculating the number of palette entries in packets 
containing a palette at the end, rather than just assuming 256 entries.


If we can agree on using this 1 << bits_per_coded_sample logic overall 
for packets containing a palette, in the same way as it is done in AVI 
and QuickTime, here's a patch of ff_reshuffle_raw_rgb() that makes it 
somewhat more future-proof.


Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 4d755a3167450f161a13fe4c6a9f74eacf5f1180 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Sat, 27 Feb 2016 14:02:34 +0100
Subject: [PATCH] lavf/rawutils: Make ff_reshuffle_raw_rgb() somewhat more future-proof

---
 libavformat/rawutils.c |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/rawutils.c b/libavformat/rawutils.c
index 26ebbb5..1424152 100644
--- a/libavformat/rawutils.c
+++ b/libavformat/rawutils.c
@@ -28,8 +28,8 @@ int ff_reshuffle_raw_rgb(AVFormatContext *s, AVPacket **ppkt, AVCodecContext *en
 AVPacket *pkt = *ppkt;
 int64_t bpc = enc->bits_per_coded_sample != 15 ? enc->bits_per_coded_sample : 16;
 int min_stride = (enc->width * bpc + 7) >> 3;
-int with_pal_size = min_stride * enc->height + 1024;
-int contains_pal = bpc == 8 && pkt->size == with_pal_size;
+int with_pal_size = min_stride * enc->height + (1 << bpc) * 4;
+int contains_pal = bpc >= 1 && bpc <= 8 && pkt->size == with_pal_size;
 int size = contains_pal ? min_stride * enc->height : pkt->size;
 int stride = size / enc->height;
 int padding = expected_stride - FFMIN(expected_stride, stride);
-- 
1.7.10.4

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

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[wm4]

On Sat, 27 Feb 2016 13:01:40 +0100
Reimar Döffinger  wrote:

> Check that the required plane pointers and only
> those are set up.
> Currently does not enforce anything for the palette
> pointer of pseudopal formats as I am unsure about the
> requirements.
> 
> Signed-off-by: Reimar Döffinger 
> ---
>  doc/APIchanges   |  6 ++
>  libavcodec/utils.c   | 27 +++
>  libavcodec/version.h |  2 +-
>  libavutil/frame.h|  3 +++
>  4 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4e952a8..ee407da 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,12 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2016-02-xx - xxx - lavc 57.25.101
> +  Validate AVFrame returned by get_buffer2 to have required
> +  planes not NULL and unused planes set to NULL as crashes
> +  and buffer overflow are possible with certain streams if
> +  that is not the case.
> +
>  2016-xx-xx - lavc 57.25.0 - avcodec.h
>Add AVCodecContext.hw_frames_ctx.
>  
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index af21cdd..1967f03 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
> *frame)
>  return ff_init_buffer_info(avctx, frame);
>  }
>  
> +static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame 
> *frame)
> +{
> +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
> +int i;
> +int num_planes = av_pix_fmt_count_planes(frame->format);
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
> +int flags = desc ? desc->flags : 0;
> +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL))
> +num_planes = 2;
> +for (i = 0; i < num_planes; i++) {
> +av_assert0(frame->data[i]);
> +}
> +// TODO: what are the exact requirements on pseudopal formats for 
> get_buffer2?
> +if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL))
> +num_planes = 2;

This should be correct. Not allocating a palette for unpaletted but
"pseudopal" formats can cause random crashes, as all code within FFmpeg
seems to assume that the palette has been allocated. (An utter
abomination, if you ask me.) At the same time, pixdesc will indicate
that paletted formats have only 1 plane, but 2 data pointers.

> +// for formats without data like hwaccel allow
> +// pointers to be non-NULL.
> +for (i = num_planes; num_planes > 0 && i < 
> FF_ARRAY_ELEMS(frame->data); i++) {
> +if (frame->data[i])
> +av_log(avctx, AV_LOG_ERROR, "Buffer returned by 
> get_buffer2() did not zero unused plane pointers\n");
> +frame->data[i] = NULL;
> +}
> +}
> +}
> +
>  static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int 
> flags)
>  {
>  const AVHWAccel *hwaccel = avctx->hwaccel;
> @@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, 
> AVFrame *frame, int flags)
>  avctx->sw_pix_fmt = avctx->pix_fmt;
>  
>  ret = avctx->get_buffer2(avctx, frame, flags);
> +if (ret >= 0)
> +validate_avframe_allocation(avctx, frame);
>  
>  end:
>  if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) {
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index 0856b19..c937eaf 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>  
>  #define LIBAVCODEC_VERSION_MAJOR  57
>  #define LIBAVCODEC_VERSION_MINOR  25
> -#define LIBAVCODEC_VERSION_MICRO 101
> +#define LIBAVCODEC_VERSION_MICRO 102
>  
>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
> LIBAVCODEC_VERSION_MINOR, \
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 56001a8..76a8123 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -187,6 +187,9 @@ typedef struct AVFrame {
>   * see avcodec_align_dimensions2(). Some filters and swscale can read
>   * up to 16 bytes beyond the planes, if these filters are to be used,
>   * then 16 extra bytes must be allocated.
> + *
> + * NOTE: Except for hwaccel formats, pointers not needed by the format
> + * MUST be set to NULL.
>   */
>  uint8_t *data[AV_NUM_DATA_POINTERS];
>  

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/utils: Check that the video data[] arrays are NULL on the input to get_buffer_internal()

[Michael Niedermayer]

On Fri, Feb 26, 2016 at 01:07:54PM +0100, Reimar Döffinger wrote:
> On Fri, Feb 26, 2016 at 12:59:08PM +0100, Michael Niedermayer wrote:
> > This should return an error to the decoder if the struct it tried to 
> > getbuffer is dirty
> 
> It seems like a good idea, however it likely won't help
> for programs providing their own getbuffer2 as they will
> probably fill the data[] fields from their own shadow
> structures, which this check will not discover.

applied patchset

thanks

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

If you drop bombs on a foreign country and kill hundred thousands of
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH] lavc/Makefile: dnxhd demuxer depends on dnxhddata.o

[Michael Niedermayer]

On Wed, Feb 24, 2016 at 04:59:51PM -0600, Rodger Combs wrote:
> ---
>  libavcodec/Makefile | 1 +
>  1 file changed, 1 insertion(+)

LGTM

thx

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

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [Consulting] Converting an Audio Visualization application to CLI using FFMpeg

[James Darnley]

On 2016-02-27 04:09, Ryan Schott wrote:
> Hello,
> 
> I am not sure if this is the right page to post this, but your consulting
> page recommended I use this list. I recent built an audio visualization app
> using html5. I'm currently using that app with xsplit to stream music to an
> RTMP endpoint on either twitch.tv or YouTube.
> 
> For an example check out: https://youtu.be/Zmb_fy528Uo
> 
> I would like to be able to mimic this functionality on a server without
> using window capture and a live browser window. I'm a fan of the
> flexibility that my html5 solution gives me, but there's no way to spawn
> streams from a CLI. I know I will most likely have to throw out my HTML5
> solution to get the data to something that can run on a command line
> without a full browser.
> 
> My dream is that I can somehow stream the audio and video that would be
> coming from the browser normally to an input in ffmpeg and then output it
> to an RTMP endpoint. If I could get to that point, I could easily build a
> controller application with my skillset to allow any number of users to
> arbitrarily stream music with visualization from our central server to
> their twitch and youtube channels.
> 
> Another use case I have is mass creating visualized mp4's from mp3's. I
> currently have  a static image script working using ffmpeg to batch create
> videos from mp3's, but we'd rather have visualized videos than static image
> videos.
> 
> Overall, I'm looking to see if it's feasible to pipe the html5 video and
> audio output to an rtmp endpoint without a browser, and if it's not what my
> options are to construct visualizations in code without a desktop.

If you want exactly what was shown then it can't be done right now.

In the mean time you can have a look at some of FFmpeg's existing vis
filters here
> https://trac.ffmpeg.org/wiki/FancyFilteringExamples#Audio

And you can checkout my work-in-progress vis library here
> https://gitlab.com/J_Darnley/Advanced-Visualization-Studio
Although this library can't t do it either, it does have a very similar
spectrograph display, all it needs is a small gap between the bands.
Unfortunately I need to update the libavfilter wrapper for recent
changes I made.

When you have the video you want you can pad the edges and draw the
text, both of which can be done right now with ffmpeg.

If you want to render the video using your existing HTML5 code then I
find it hard to believe that nobody has yet written a headless browser
which can write to some sort of output stream, stdout at the very least.




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

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[wm4]

On Sat, 27 Feb 2016 12:54:50 +0100
Reimar Döffinger  wrote:

> On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote:
> > On Fri, 26 Feb 2016 22:59:17 +0100
> > Reimar Döffinger  wrote:  
> > > > Can you move it to a separate function? Say, ff_verify_frame(). This
> > > > could get much more complicated too when checking AVBufferRef usage or
> > > > audio.
> > > 
> > > Why ff_? If we've decided on it and use it in other places it
> > > might become a av_* function in libavutil.
> > > But until then I guess it should be a static function in that file?  
> > 
> > For now it also might be used in the encoding functions. Don't know how
> > far it could go.  
> 
> They are in the same file though, so static would still be fine.
> However as for encoding those are const AVFrames I think it
> is much less of an issue (should only cause overreads, not
> writes) and I'm more inclined to not change things that
> after all might break someone's (probably quite crappy) code.

If you look at avcodec_encode_audio2(), it already contains a huge
chunk of code that somehow checks aspects of the AVFrame from the user.
Could be unified one day.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 01:01:40PM +0100, Reimar Döffinger wrote:
> Check that the required plane pointers and only
> those are set up.
> Currently does not enforce anything for the palette
> pointer of pseudopal formats as I am unsure about the
> requirements.
> 
> Signed-off-by: Reimar Döffinger 
> ---
>  doc/APIchanges   |  6 ++
>  libavcodec/utils.c   | 27 +++
>  libavcodec/version.h |  2 +-
>  libavutil/frame.h|  3 +++
>  4 files changed, 37 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 4e952a8..ee407da 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,12 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2016-02-xx - xxx - lavc 57.25.101

Fixed locally to say 57.25.102
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Reimar Döffinger]

Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.

Signed-off-by: Reimar Döffinger 
---
 doc/APIchanges   |  6 ++
 libavcodec/utils.c   | 27 +++
 libavcodec/version.h |  2 +-
 libavutil/frame.h|  3 +++
 4 files changed, 37 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 4e952a8..ee407da 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,12 @@ libavutil: 2015-08-28
 
 API changes, most recent first:
 
+2016-02-xx - xxx - lavc 57.25.101
+  Validate AVFrame returned by get_buffer2 to have required
+  planes not NULL and unused planes set to NULL as crashes
+  and buffer overflow are possible with certain streams if
+  that is not the case.
+
 2016-xx-xx - lavc 57.25.0 - avcodec.h
   Add AVCodecContext.hw_frames_ctx.
 
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..1967f03 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 return ff_init_buffer_info(avctx, frame);
 }
 
+static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame)
+{
+if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
+int i;
+int num_planes = av_pix_fmt_count_planes(frame->format);
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+int flags = desc ? desc->flags : 0;
+if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL))
+num_planes = 2;
+for (i = 0; i < num_planes; i++) {
+av_assert0(frame->data[i]);
+}
+// TODO: what are the exact requirements on pseudopal formats for 
get_buffer2?
+if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL))
+num_planes = 2;
+// for formats without data like hwaccel allow
+// pointers to be non-NULL.
+for (i = num_planes; num_planes > 0 && i < 
FF_ARRAY_ELEMS(frame->data); i++) {
+if (frame->data[i])
+av_log(avctx, AV_LOG_ERROR, "Buffer returned by get_buffer2() 
did not zero unused plane pointers\n");
+frame->data[i] = NULL;
+}
+}
+}
+
 static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int 
flags)
 {
 const AVHWAccel *hwaccel = avctx->hwaccel;
@@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame, int flags)
 avctx->sw_pix_fmt = avctx->pix_fmt;
 
 ret = avctx->get_buffer2(avctx, frame, flags);
+if (ret >= 0)
+validate_avframe_allocation(avctx, frame);
 
 end:
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 0856b19..c937eaf 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  57
 #define LIBAVCODEC_VERSION_MINOR  25
-#define LIBAVCODEC_VERSION_MICRO 101
+#define LIBAVCODEC_VERSION_MICRO 102
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 56001a8..76a8123 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -187,6 +187,9 @@ typedef struct AVFrame {
  * see avcodec_align_dimensions2(). Some filters and swscale can read
  * up to 16 bytes beyond the planes, if these filters are to be used,
  * then 16 extra bytes must be allocated.
+ *
+ * NOTE: Except for hwaccel formats, pointers not needed by the format
+ * MUST be set to NULL.
  */
 uint8_t *data[AV_NUM_DATA_POINTERS];
 
-- 
2.7.0

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

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Reimar Döffinger]

On Fri, Feb 26, 2016 at 11:41:41PM +0100, wm4 wrote:
> On Fri, 26 Feb 2016 22:59:17 +0100
> Reimar Döffinger  wrote:
> > > Can you move it to a separate function? Say, ff_verify_frame(). This
> > > could get much more complicated too when checking AVBufferRef usage or
> > > audio.  
> > 
> > Why ff_? If we've decided on it and use it in other places it
> > might become a av_* function in libavutil.
> > But until then I guess it should be a static function in that file?
> 
> For now it also might be used in the encoding functions. Don't know how
> far it could go.

They are in the same file though, so static would still be fine.
However as for encoding those are const AVFrames I think it
is much less of an issue (should only cause overreads, not
writes) and I'm more inclined to not change things that
after all might break someone's (probably quite crappy) code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Reimar Döffinger]

On Sat, Feb 27, 2016 at 02:21:18AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 11:06:22PM +0100, Reimar Döffinger wrote:
> > +static void validate_avframe_allocation(const AVCodecContext *avctx, 
> > AVFrame *frame)
> > +{
> > +if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
> > +int i;
> > +int num_planes = av_pix_fmt_count_planes(frame->format);
> > +for (i = 0; i < num_planes; i++) {
> > +av_assert0(frame->data[i]);
> > +}
> > +// for formats without data like hwaccel allow
> > +// pointers to be non-NULL.
> 
> > +for (i = num_planes; num_planes > 0 && i < num_planes; i++) {
> 
> are both of i = num_planes and i < num_planes intended ?

That uncovered a few more issues.

> some note in APIChanges or release notes or something might make sense
> too

Hm. Forgot about that in latest version.
Also, why can't I pass a "const AVCodecContext *" to av_log?
That is kind of inconvenient.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Document and validate AVFrame plane pointers.

[Reimar Döffinger]

Check that the required plane pointers and only
those are set up.
Currently does not enforce anything for the palette
pointer of pseudopal formats as I am unsure about the
requirements.

Signed-off-by: Reimar Döffinger 
---
 libavcodec/utils.c | 27 +++
 libavutil/frame.h  |  3 +++
 2 files changed, 30 insertions(+)

diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index af21cdd..1967f03 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -853,6 +853,31 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 return ff_init_buffer_info(avctx, frame);
 }
 
+static void validate_avframe_allocation(AVCodecContext *avctx, AVFrame *frame)
+{
+if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
+int i;
+int num_planes = av_pix_fmt_count_planes(frame->format);
+const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(frame->format);
+int flags = desc ? desc->flags : 0;
+if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PAL))
+num_planes = 2;
+for (i = 0; i < num_planes; i++) {
+av_assert0(frame->data[i]);
+}
+// TODO: what are the exact requirements on pseudopal formats for 
get_buffer2?
+if (num_planes == 1 && (flags & AV_PIX_FMT_FLAG_PSEUDOPAL))
+num_planes = 2;
+// for formats without data like hwaccel allow
+// pointers to be non-NULL.
+for (i = num_planes; num_planes > 0 && i < 
FF_ARRAY_ELEMS(frame->data); i++) {
+if (frame->data[i])
+av_log(avctx, AV_LOG_ERROR, "Buffer returned by get_buffer2() 
did not zero unused plane pointers\n");
+frame->data[i] = NULL;
+}
+}
+}
+
 static int get_buffer_internal(AVCodecContext *avctx, AVFrame *frame, int 
flags)
 {
 const AVHWAccel *hwaccel = avctx->hwaccel;
@@ -885,6 +910,8 @@ static int get_buffer_internal(AVCodecContext *avctx, 
AVFrame *frame, int flags)
 avctx->sw_pix_fmt = avctx->pix_fmt;
 
 ret = avctx->get_buffer2(avctx, frame, flags);
+if (ret >= 0)
+validate_avframe_allocation(avctx, frame);
 
 end:
 if (avctx->codec_type == AVMEDIA_TYPE_VIDEO && !override_dimensions) {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 56001a8..76a8123 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -187,6 +187,9 @@ typedef struct AVFrame {
  * see avcodec_align_dimensions2(). Some filters and swscale can read
  * up to 16 bytes beyond the planes, if these filters are to be used,
  * then 16 extra bytes must be allocated.
+ *
+ * NOTE: Except for hwaccel formats, pointers not needed by the format
+ * MUST be set to NULL.
  */
 uint8_t *data[AV_NUM_DATA_POINTERS];
 
-- 
2.7.0

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

Re: [FFmpeg-devel] Question about palette size in packets

[Mats Peterson]

On 02/27/2016 12:02 PM, Mats Peterson wrote:

On 02/27/2016 11:51 AM, Mats Peterson wrote:

On 02/27/2016 11:44 AM, Mats Peterson wrote:

Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't


Should of course be "the size of the palette".

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

Re: [FFmpeg-devel] Question about palette size in packets

[Mats Peterson]

On 02/27/2016 11:51 AM, Mats Peterson wrote:

On 02/27/2016 11:44 AM, Mats Peterson wrote:

Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't
fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes
exclusively. Will this possibly change in the future? If so, is the "1
<< bits per sample" for the palette size that is already assumed decent
enough to use as a future "standard"?

Mats



Instead of having to subtract the video data from the packet size every
time, which I'm currently *not* doing, but which of course would be more
fool-proof.



This is mostly related to the muxer side, when calculating the palette 
size after returning from ff_reshuffle_raw_rgb(), by the way.


Mats

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

Re: [FFmpeg-devel] Question about palette size in packets

[Mats Peterson]

On 02/27/2016 11:44 AM, Mats Peterson wrote:

Michael, I am currently "assuming" that the size of the palette in a
packet, if included at the end of the video data, will be 1 <<
bits_per_coded_sample. You're saying that the size of the packet isn't
fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes
exclusively. Will this possibly change in the future? If so, is the "1
<< bits per sample" for the palette size that is already assumed decent
enough to use as a future "standard"?

Mats



Instead of having to subtract the video data from the packet size every 
time, which I'm currently *not* doing, but which of course would be more 
fool-proof.


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

[FFmpeg-devel] Question about palette size in packets

[Mats Peterson]

Michael, I am currently "assuming" that the size of the palette in a 
packet, if included at the end of the video data, will be 1 << 
bits_per_coded_sample. You're saying that the size of the packet isn't 
fixed to 1024 bytes, but currently it seems to be 1024 (256 * 4) bytes 
exclusively. Will this possibly change in the future? If so, is the "1 
<< bits per sample" for the palette size that is already assumed decent 
enough to use as a future "standard"?


Mats

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

Re: [FFmpeg-devel] [PATCH 2/2] sws/yuv2rgb: clarify precision of coeff and offset for mmx code

[Clément Bœsch]

On Sat, Feb 27, 2016 at 01:06:08AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 10:34:46PM +0100, Clément Bœsch wrote:
> > It makes easier looking at the difference with the generic code just
> > below.
> > ---
> >  libswscale/yuv2rgb.c | 12 ++--
> >  1 file changed, 6 insertions(+), 6 deletions(-)
> 
> LGTM
> 
> thx
> 

pushed

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH 1/2] sws/yuv2rgb: avoid a few ub on signed left shifts

[Clément Bœsch]

On Sat, Feb 27, 2016 at 01:05:35AM +0100, Michael Niedermayer wrote:
> On Fri, Feb 26, 2016 at 10:34:45PM +0100, Clément Bœsch wrote:
> > ---
> >  libswscale/yuv2rgb.c | 20 ++--
> >  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> LGTM
> 
> thanks
> 

applied

-- 
Clément B.


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