[FFmpeg-devel] libavcodec decoder output PIX_FMT

SD sdv4l2
Tue Oct 19 09:01:28 CEST 2010


On Mon, Oct 18, 2010 at 10:40 PM, Tomas H?rdin <tomas.hardin at codemill.se>wrote:

> Please avoid top-posting on this list.
>
> On Mon, 2010-10-18 at 10:03 -0700, SD wrote:
> > On Mon, Oct 18, 2010 at 12:14 AM, Tomas H?rdin <tomas.hardin at codemill.se
> >wrote:
> >
> > > On Sat, 2010-10-16 at 12:40 -0700, Srinivasa Deevi wrote:
> > > > Hi
> > > >
> > > > I would like to know if there are any restrictions on libavcodec
> decoder
> > > > output to be anything other than YUV type. Can that be RGB24/32
> format as
> > > > well ?
> > >
> > > Yes. Almost all entries in the PixelFormat enum are ok (not sure about
> > > the hwaccel ones). You can check out AVCodec::pix_fmts if you like, but
> > > that's not always set. Also, the output pixel format will vary
> depending
> > > on the input, even if using the same codec. For instance, DV can be
> > > either 4:2:0, 4:1:1 or 4:2:2.
> > >
> > > > Also, if the decoder scales it down as well, how we inform the next
> level
> > > > like libvo . Is this possible with ffmpeg ?
> > >
> > > The decoder shouldn't do any scaling. At least I haven't come across it
> > > so far. It might request that the output should be cropped though, and
> > > the resolution may change, thus requiring scaling.
> > >
> > > The answer to both of these questions is probably to always inspect
> > > pix_fmt, width/height, coded_width/coded_height etc. and act
> > > accordingly.
> > >
> > > For specific codecs it might be possible to guarantee that for instance
> > > resolution doesn't change, but not in the general case.
> > >
> > > /Tomas
> > >
> > >
> > Tomas,
> >
> > Thank you for your reply.
> >
> > I have one more question. App -> parser -> decoder -> VO -> framebuffer
> >
> > Is the above possible ? Can we implement in above format ? How can we
> bypass
> > any in between decoder and VO if possible.
>
> I doubt you can bypass the decoder. Unless you have raw video of course.
>
> > or App -> parser -> decoder -> libswscale -> VO -> framebuffer
> > if the only way we should implement ?
>
> If you can write to the frame buffer directly and its pixel format and
> resolution matches that of the decoder then should be able to pass it to the
> decode function. Just set up the AVFrame struct properly.
>
> > >>The answer to both of these questions is probably to always inspect
> > pix_fmt, width/height, coded_width/coded_height etc. and act
> > accordingly
> >
> > Is not the above based on the decoder that we choose  ?
>
> That is correct. The lavc decoders will/should never output any pixel
> format or resolution that is not supported by that codec's specs. At least I
> haven't come across any that do yet.
>
> Also, if your video comes from some kind of device then that might also
> have certain guarantees regarding the frame format. Think of a camera that
> always outputs the same resolution for instance.
>
> /Tomas
>
> _______________________________________________
> ffmpeg-devel mailing list
> ffmpeg-devel at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/ffmpeg-devel
>


Tomas,

Thanks for the reply.

> App -> parser -> decoder -> VO -> framebuffer
>
> Is the above possible ? Can we implement in above format ? How can we
bypass
> any in between decoder and VO if possible.

>>I doubt you can bypass the decoder. Unless you have raw video of course.

I did not mean to bypass decoder. What if the decoder can decode to RGB
directly ? Also, it can do the scaling ?
Can we bypass any AVFilter inbetween and call libvo directly ?

Thanks
SD.



More information about the ffmpeg-devel mailing list