[FFmpeg-user] Raw video format
Mattias Andrée
maandree at kth.se
Wed Jan 18 18:02:06 EET 2017
Since I'm not getting the answer, I'm unsubscribing,
but if you have the answer feel free to e-mail me.
On Tue, 10 Jan 2017 19:36:08 +0100
Mattias Andrée <maandree at kth.se> wrote:
> On Tue, 10 Jan 2017 17:47:38 +0100
> Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
>
> > 2017-01-10 17:26 GMT+01:00 Mattias Andrée
> > <maandree at kth.se>:
> > > On Tue, 10 Jan 2017 12:05:24 +0100
> > > Carl Eugen Hoyos <ceffmpeg at gmail.com> wrote:
> > >
> > >> 2017-01-09 23:11 GMT+01:00 Mattias Andrée
> > >> <maandree at kth.se>:
> > >> > I have a stream of YUV colours (with alpha), stored
> > >> > with raw `double`s.
> > >>
> > >> FFmpeg does not support float pix_fmt and at least
> > >> some developers believe that this wouldn't help
> > >> anyway for expected input.
> > >>
> > >> > I want to use ffmpeg -f rawvideo -pix_fmt ayuv64le
> > >> > to convert this into a normal video format.
> > >>
> > >> This is the point:
> > >> "Normal" video format is integer, so why would it
> > >> help if you input float?
> > >>
> > >> > How should I encode each pixel so that ffmpeg can
> > >> > decode them?
> > >>
> > >> RGBA64 comes to mind if your input is rgb.
> > >>
> > >> If you want to input float into FFmpeg, you have to
> > >> write exr frames but note that they are converted to
> > >> int before any further processing.
> >
> > > I'm pretty sure I prefer YUV over RGB.
> >
> > I realize that my comment above concerning RGBA64
> > may not make sense to you, please ignore.
> > (My first guess was that your input is exr or related.)
> >
> > > Values in YUV are floats
> >
> > I don't understand:
> > Do you mean that in your application (or the application
> > that you want to use) yuv are floats? This is of course
> > possible and it is a problem for you, because yuv float
> > is not only not supported by FFmpeg but not supported
> > by any related application.
> > Or do you mean that all "YUV" values are always float?
> > In the world of codecs (that's where FFmpeg is used)
> > yuv is always integer, there is no video codec that
> > outputs floats and I believe it makes little sense to
> > write an encoder that accepts floats.
> > (tiff and a few others do support floats but as said
> > FFmpeg does not support it.)
>
> I mean the former.
>
> I have figured out that if I convert an sRGB colour,
> with 8-bits per channel with the transfer function
> applied, to YUV without unapplying the transfer function,
> and then let
>
> Y := Y ⋅ 256 + 16 ⋅ 256
> U := U ⋅ 256 + 128 ⋅ 256
> V := V ⋅ 256 + 128 ⋅ 256
>
> I get values pretty close to those from ffmpeg get.
>
> I have tries both the conversion matrix
>
> ⎛ 0.299 0.587 0.114 ⎞
> ⎜−0.450/3.069 −0.883/3.069 1.333/3.069⎟
> ⎝ 1.333/2.169 -1.116/2.169 -0.217/2.169⎠
>
> and the conversion matrix
>
> ⎛ 0.299 0.587 0.114 ⎞
> ⎜−0.14713 −0.28886 0.436 ⎟
> ⎝ 0.615 −0.51499 −0.10001⎠
>
> The produce very similar results, but both are a bit
> off from what ffmpeg produce.
>
> What adjustments should be done so the conversion
> from sRGB to YUV matches that done by ffmpeg?
>
> >
> > > that can be negative or large, it does not have
> > > the simple bounds of [0, 1], with the exception of
> > > the Y value, like you normally have with RGB.
> >
> > (Suspecting now that you are thinking of analog video)
> > Please understand that this is simply not true for
> > FFmpeg: On this mailing list, when we talk about
> > "yuv", we mean 8bit or 16bit integer values (full
> > scale or mpeg scale).
>
> No, I'm just talking about raw encoded colours.
>
> >
> > > So my question is how should a YUV value be
> > > encoded as an integer?
> >
> > You will have to find a linear representation for the
> > values that you call "YUV" as everybody else does.
> >
> > > Floats are useful for rendering
> >
> > Given that no hardware (?) and no real-world video
> > codec support floats, I wonder what you mean here.
>
> Perhaps composing is more accurate word. Floats are
> useful for the mathematics. For example if you have
> two images with alpha you want to put on top of each
> other, normalised floats and no transfer function
> applied makes the maths simpler.
>
> >
> > > so I think it would be
> > > preferable for ffmpeg to support it as it would speed
> > > up rending as it would eliminate some conversion.
> >
> > This sounds very unlikely.
> >
> > My new guess is that you should simply convert to
> > yuv420p (as defined by FFmpeg) to get "normal video
> > format" as output (and no additional conversion needed).
> >
> > Carl Eugen
> > _______________________________________________
> > ffmpeg-user mailing list
> > ffmpeg-user at ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-user
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-user-request at ffmpeg.org with subject
> > "unsubscribe".
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-user/attachments/20170118/2921b5c4/attachment.sig>
More information about the ffmpeg-user
mailing list