[gst-devel] fractions

[Thomas Vander Stichele]

Hi,

Nice skid around the previous example for framerate :)  I must admit it
threw me off as well when I checked what the original fraction was.

> On Wed, Jul 14, 2004 at 11:44:54PM +0200, Thomas Vander Stichele wrote:
> > What would it represent, what practical use would it have, and how would
> > it deal with trying to display 13.2948 by 48.345891 pixels ?  Seems like
> > a non-issue to me.
> 
> You're going to have to deal with that issue anyway.  So far, it
> appears you've been pretending that issue doesn't exist.  How do
> you resize a 256x256 video for a 5/4 pixel display?
(I'm assuming the video is in 1:1 PAR here, because you didn't specify
that).

How about just scale the video to 256x320 ?

Anyway, yes, there are cases where you are constrained to cropping the
non-integer pixels (suppose the user scales ximagesink to a height of
137 and it tries to match the width), but:
- ximagesink could make a reasonable attempt at only allowing scaling to
"correct" scalings
- some element could do the cropping because it notices it can't be done
exactly (say, videoscale)

But for all practical purposes, I don't see where you would ever need
pixels as non-integer *in caps*.  Internally to an element, maybe.  But
then it's the job of the element to deal with it.  But in caps ? Don't
think so.

> In any case, at this point, I think it's wiser to just have a
> "Number" type, which can be represented by an integer, double,
> or fraction of integers.  This also neatly gets rid of having
> multiple range types.

Not sure how you would want to implement that, and not sure it's a good
thing to do right now.  Maybe it makes sense for a 0.9 project, but it
seems to invasive for this series, and I don't yet see the gain in it. 
But it sounds to me like this means you have agreed on having a
"fraction" concept in GStreamer ?

So, to recap:

- you're the only one who currently has expressed objections to
GstFraction
- I've given examples that you got wrong for stuff you said could be
done correctly
- You've given an example of something that I'd get wrong which afaict I
got correct
- Based on the examples, I don't see how we can feed encoders correct
frame rate fractions without rounding errors
- Every codec project out there seems to think fractions are the right
way to handle both aspect ratio and framerate - what makes you think all
of them conbined are wrong ?
- Your main reason for not wanting GstValue seems to be that it adds
extra code that needs maintaining, even though you've said yourself that
doing it in other ways also forces you to write fancy code to go from
floats to fractions

I don't think I need to produce any more factual evidence for the
usefulness of GstFraction than I already have.  I haven't seen
compelling evidence of any kind that says floats are good enough. And I
can't stand having a GStreamer that doesn't handle aspect ratio
correctly, because it's stupid, and because totem needs it handled
correctly.

I just managed to get videoscale to do the right thing on its own as
well.  Now just need to figure out why ffmpegcolorspace in the pipeline
screws up negotation again.  And then I have a complete set of patches
that handles aspect ratio correctly in GStreamer. (Even better than in
MPlayer for some files, I might add - some of the test clips are scaled
incorrectly there).

Do you really feel that fractions are the wrong way to handle this, and
therefore this patch should not go in tomorrow ?
It's obvious I put time into figuring this out and implementing this as
best as I can.  So one can assume I care enough to fix issues with it. 
And of course I will volunteer to maintain the concept of fractions in
GStreamer, and work out any bugs that would come up for new cases.

Is there any point in refusing a set of patches that solves a problem
correctly, in a nicely abstracted way, when the alternative is that it
will just stay broken instead, on the doubtful assumption that floats
are good enough ?

Let me know, I'd at least like to know if I should bother to keep
working on it.

Thanks for discussing,
Thomas



Dave/Dina : future TV today ! - http://www.davedina.org/
<-*- thomas (dot) apestaart (dot) org -*->
Lover fair
We'll be looking sharp I swear
I want them all to stop and stare
When we take'em down
<-*- thomas (at) apestaart (dot) org -*->
URGent, best radio on the net - 24/7 ! - http://urgent.fm/