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

[Mats Peterson]

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

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

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

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

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

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

Mats



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

Mats




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


Mats

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

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

[Mats Peterson]

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

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

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

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

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

Mats



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


Mats


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

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

[Mats Peterson]

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

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

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

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

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

Mats



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


Mats

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

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

[Mats Peterson]

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

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

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

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

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

Mats



And convert with -vcodec rawvideo as well, to make sure it works on a 
big-endian machine.


Mats

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

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

[Mats Peterson]

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

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

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

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

Mats

--
Mats Peterson
http://matsp888.no-ip.org/~mats/
>From 899da4b2d6aba1095513a016bd4425221e257eb6 Mon Sep 17 00:00:00 2001
From: Mats Peterson 
Date: Thu, 3 Mar 2016 00:27:38 +0100
Subject: [PATCH v5 1/4] lavf/avienc: Add support for palette side data

---
 libavformat/avienc.c |   60 --
 1 file changed, 39 insertions(+), 21 deletions(-)

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