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

2016-03-04 Thread Mats Peterson 

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

On 03/05/2016 01:08 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without


where can i find that file ?



Thought you had it already?
https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk




the avienc.c and riffenc.c patch. The destination file will only
contain xxpc chunks with my patch applied.


pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks


And what do you suggest in order to detect this? 1 kb more per frame
isn't that much. Nut uses it all the time.

You were the one who proposed to use a shared function, and the option
for a calling program to deliver the palette as side data. That's why I
wrote the function, to be shared by avienc, movenc and possibly more
muxers. It would be nice if you could apply these remaining patches now,
thank you.



Or rather, it was Reimar who was first complaining at the muxers lacking 
the ability to handle palette side data.


Mats

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

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

2016-03-04 Thread Mats Peterson 

On 03/05/2016 01:08 AM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without


where can i find that file ?



Thought you had it already?
https://drive.google.com/open?id=0B3_pEBoLs0faekxWUTdkVGNTTlk




the avienc.c and riffenc.c patch. The destination file will only
contain xxpc chunks with my patch applied.


pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks


And what do you suggest in order to detect this? 1 kb more per frame 
isn't that much. Nut uses it all the time.


You were the one who proposed to use a shared function, and the option 
for a calling program to deliver the palette as side data. That's why I 
wrote the function, to be shared by avienc, movenc and possibly more 
muxers. It would be nice if you could apply these remaining patches now, 
thank you.


Mats

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

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

2016-03-04 Thread Michael Niedermayer 
On Fri, Mar 04, 2016 at 10:12:41PM +0100, Mats Peterson wrote:
> On 03/04/2016 10:02 PM, Mats Peterson wrote:
> >On 03/04/2016 09:52 PM, Mats Peterson wrote:
> >>On 03/04/2016 08:44 PM, Michael Niedermayer wrote:
> >>>On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
> >Removed some unused variables in AVIStream.
> >
> 
> 
> I would like to remind you of the fact that this patch (and the one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.
> >>>
> >>>i tried CRAM and MSRLE, but these already work when streamcopied
> >>>before, do you have a testcase that does not work
> >>>
> >>
> >>It works, but only so much. On stream copy, it will only write the
> >>palette after BITMAPINFOHEADER to the destination file. It won't write
> >>any xxpc palette switching chunks to the file.
> >>
> >>Mats
> >>
> >The xxpc chunks come as palette side data.
> >
> >Mats
> 
> 
> Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without

where can i find that file ?


> the avienc.c and riffenc.c patch. The destination file will only
> contain xxpc chunks with my patch applied.

pc chunks are only needed when the palette changes, if its the same
for the whole file and after BITMAPINFOHEADER then theres no need
for pc chunks
a testcase with changing palette would be ideal for fate

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousands in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

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

2016-03-04 Thread Mats Peterson 
Mats Peterson  skrev: (4 mars 2016 22:12:41 
CET)
>On 03/04/2016 10:02 PM, Mats Peterson wrote:
>> On 03/04/2016 09:52 PM, Mats Peterson wrote:
>>> On 03/04/2016 08:44 PM, Michael Niedermayer wrote:
 On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
>> Removed some unused variables in AVIStream.
>>
>
>
> I would like to remind you of the fact that this patch (and the
>one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.

 i tried CRAM and MSRLE, but these already work when streamcopied
 before, do you have a testcase that does not work

>>>
>>> It works, but only so much. On stream copy, it will only write the
>>> palette after BITMAPINFOHEADER to the destination file. It won't
>write
>>> any xxpc palette switching chunks to the file.
>>>
>>> Mats
>>>
>> The xxpc chunks come as palette side data.
>>
>> Mats
>
>
>Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the 
>avienc.c and riffenc.c patch. The destination file will only contain 
>xxpc chunks with my patch applied.
>
>Mats
>
>
>___
>ffmpeg-devel mailing list
>ffmpeg-devel@ffmpeg.org
>http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

What's more, the whole idea with using a shared function for retrieval of the 
palette for a muxer was to enable a calling program to deliver it as side data, 
if desired.

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

2016-03-04 Thread Mats Peterson 

On 03/04/2016 10:02 PM, Mats Peterson wrote:

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats



Try ffmpeg -i 8bpp_129.avi -vcodec copy test.avi, with and without the 
avienc.c and riffenc.c patch. The destination file will only contain 
xxpc chunks with my patch applied.


Mats


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

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

2016-03-04 Thread Mats Peterson 

On 03/04/2016 09:52 PM, Mats Peterson wrote:

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the
palette after BITMAPINFOHEADER to the destination file. It won't write
any xxpc palette switching chunks to the file.

Mats


The xxpc chunks come as palette side data.

Mats

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

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

2016-03-04 Thread Mats Peterson 

On 03/04/2016 08:44 PM, Michael Niedermayer wrote:

On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one
for riffenc.c) is needed for stream copying of Microsoft Video 1
(CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
possibly more codecs using a palette, but these are the ones I can
come up with at the moment.


i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work



It works, but only so much. On stream copy, it will only write the 
palette after BITMAPINFOHEADER to the destination file. It won't write 
any xxpc palette switching chunks to the file.


Mats

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

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

2016-03-04 Thread Michael Niedermayer 
On Fri, Mar 04, 2016 at 11:59:11AM +0100, Mats Peterson wrote:
> On 03/04/2016 05:59 AM, Mats Peterson wrote:
> >Removed some unused variables in AVIStream.
> >
> 
> 
> I would like to remind you of the fact that this patch (and the one
> for riffenc.c) is needed for stream copying of Microsoft Video 1
> (CRAM) in 8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are
> possibly more codecs using a palette, but these are the ones I can
> come up with at the moment.

i tried CRAM and MSRLE, but these already work when streamcopied
before, do you have a testcase that does not work

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

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


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

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

2016-03-04 Thread Mats Peterson 

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

Removed some unused variables in AVIStream.




I would like to remind you of the fact that this patch (and the one for 
riffenc.c) is needed for stream copying of Microsoft Video 1 (CRAM) in 
8-bit mode, Microsoft RLE4 and Microsoft RLE8. There are possibly more 
codecs using a palette, but these are the ones I can come up with at the 
moment.


Mats

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

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

2016-03-03 Thread Mats Peterson 

Removed some unused variables in AVIStream.

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

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

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