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 & 0xffffff);
- }
- 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 & 0xffffff);
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
