[gst-devel] fractions and aspect ratios

[Ronald Bultje]

Hi,

On Tue, 13 Jul 2004, Thomas Vander Stichele wrote:
> one of the things I've been looking at is a decent way to handle aspect
> ratios and implement it correctly.  I've attached two
> patches-in-progress.
[..]

This stuff is cool. pixel_width/height is annoying. Can you please add it
to matroskademux as well?

> - for AVI, iirc the pixel aspect ratio is not described in the format;
> typically it is guessed given a list of "known" input and output sizes

AVI has no such thing in its base definition.

> - David is convinced that GstFraction is overkill, and floats are
> enough.  My argument is that going to a float loses the information of
> which two integers you came from, making it impossible to figure out
> what the intended target video size was supposed to be since you cannot
> figure out anymore what possible WxH combinations are correct scaled
> values of input WxH (ie, you cannot determine anymore which W-H values
> are integer results of scaling)

As long as deserialization is working, I think this rocks. The pad
template code in various MPEG-related elements is completely overkill
right now. Using fractions would finally solve that.

> - I also looked at creating a GST_TYPE_RANGE that would be implemented
> with a GArray with three members (lower, upper, increment).  A lot of
> code would be the same as for the LIST type, and we could convert over
> the GST_TYPE_INT_RANGE and GST_TYPE_DOUBLE_RANGE to it.  What do you
> think ?
>
> - A possible candidate for conversion to GstFraction would be framerate;
> e.g. for MPEG using floats/doubles has forced the use of some hacks,
> I've been told.

Yes to both, but 0.9 work.

Ronald