[Ffmpeg-devel] help on forcing rgb555 with 16bpp

Reynaldo H. Verdejo Pinochet reynaldo
Wed Oct 25 02:00:11 CEST 2006


On Tue, Oct 24, 2006 at 01:57:59PM +0200, Michael Niedermayer wrote:
> Hi

Hi, thanks for your answer.

> 
> On Tue, Oct 24, 2006 at 04:25:29AM -0300, Reynaldo H. Verdejo Pinochet wrote:
> > Hi folks
> > 
> > Im a little confused by the way raw.c chooses PIX_FMT using the
> > bits_per_sample value. Looking at the raw_init_decoder function, how
> > am I supossed to get my data interpreted as rgb555 by the raw
> > decoder if:
> > 
> > 1.- bits per sample is 16bpp.
> > 2.- I have no mapping for the packed PIX_FMT_RGB555 on pixelFormatTags[].
> 
> find a sechole in lavc and exploit it and change the pix_fmt ;)
> 

Guess it wouldnt be *that* hard ;)

> 
> > 
> > I'm thinking there is need to add RGB mappings to pixelFormatTags. If
> 
> yes or set bits per sample to 15
> 

Tryied with 15bpp even before I sent this mail, no success.

> 
> > that's true how do i choose a tag? Should I just invent some?  And last 
> > but not least, why does the raw decoder choose PIX_FMT using bpp if there 
> > are packed formats that share that bitcount (ie RGB565 RGB555) ?
> 
> because AVI uses the same codec_tag for all rgb variants
> the problem is the silly design of avi ...
> 

Why is it that every single problem seems to be caused by avi! :)

> setting the pix_fmt in avi alone doesnt help at all, as muxers generally dont
> use the pix_fmt and making all demuxers and muxers set/get the pix_fmt would
> likely be far too messy (and then the same would have to be done with audio)

Agree

> 
> setting a fake codec_tag in avidec.c would be an easy and simple solution ...
> 

not the way id like to do it, lets see.

> having a codec_id per pix_fmt would be another one but that too would
> likely become messy
> 

Sure.

Every single solution I make up is more hackier than the one before it,
so Im wondering: Why do we have to hack a way around the bad asumption
that raw.c makes by thinking it can guess correct pix_fmt by mere
bit counting?, that's plain wrong! why dont just bypass the detection
attempt _if_ the demuxer knows (and sets) the pixel format?

Something like this:


Index: libavcodec/raw.c
===================================================================
--- libavcodec/raw.c	(revision 6790)
+++ libavcodec/raw.c	(working copy)
@@ -87,6 +87,7 @@
 {
     RawVideoContext *context = avctx->priv_data;
 
+    if (!avctx->pix_fmt){
     if (avctx->codec_tag)
         avctx->pix_fmt = findPixelFormat(avctx->codec_tag);
     else if (avctx->bits_per_sample){
@@ -98,6 +99,7 @@
         case 32: avctx->pix_fmt= PIX_FMT_RGBA32; break;
         }
     }
+    }
 
     context->length = avpicture_get_size(avctx->pix_fmt, avctx->width, avctx->height);
     context->buffer = av_malloc(context->length);


Hope is not a *that* wrong.

> also look at the mailinglist archives this was disscussed already a few
> times but noone posted any acceptable patches to fix it

I looked around and got no results, hope you dont mind, i do plan
to end this thread with a commited solution, so please bear the
ignorance and flood.

Regards

	Reynaldo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20061024/5d311a60/attachment.pgp>



More information about the ffmpeg-devel mailing list