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

[Michael Niedermayer]

Hi

On Tue, Oct 24, 2006 at 09:00:11PM -0300, Reynaldo H. Verdejo Pinochet wrote:
> 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! 

yes, it is just think of BGR vs. RGB, packed vs planae and such, the point
is that every RGB format should have its own codec_tag ...


> why dont just bypass the detection
> attempt _if_ the demuxer knows (and sets) the pixel format?

1. avidec doesnt set pix_fmt neither before nor after your patch
2. will that work with stream copy of raw from avi->mov? avi->nut? or will
   it need changes to every muxer? mapping codec_tag->codec_tag is one
   thing, mapping pix_fmt/sound_fmt/codec_tag -> pix_fmt/sound_fmt/codec_tag
   is another

so i cant really comment on your suggestion as its not complete but what it
seems to be pointing at doesnt look clean and simple

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

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is