Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#12 YUV frames support

open
nobody
6
2005-07-05
2003-08-05
Artem Baguinski
No

Some applications would prefer to deal with YUV and
never convert it to RGB. The reason is speed - YUV->RGB
conversion eats precious time that you could spend
doing effects, also YUV is smaller then corresponding
RGB (because UV are downsampled).

Yes, processing various YUV formats is a hassle, but it
worths it.

Discussion

  • Logged In: YES
    user_id=644854

    mmm - I think this has kind of missed the boat for 1.0.

    We decided to limit the number of video standards for FF 1.0
    to encourage maximum intercompatability between hosts / plugins.

    I'll leave this open though incase anyone wants to comment.

    Are you thinking of a specific host app, or just in theory.
    Whose working in YUV? Max?

    R

     
  • Logged In: YES
    user_id=2832

    that was long ago ;-)

    well, many application do use YUV.
    with Max jitter does RGB, but SoftVNS does both RGB and YUV.
    dunno about Nato.
    with pd PDP and PiDiP use YUV.
    after piksel workshop [http://www.piksel.no/] Kentaro was
    gonna implement YUV in EffecTV and jaromil in FreeJ. I'm not
    sure they haven't done that already, i kind of lost track.
    VeeJay supports YUV [and RGB IIRC].
    The nice thing aboot YUV is that often lighter, MPEG and
    MJPEG use it and hardware can display it right away. so if
    you do realtime effects with MPEG/MJPEG movies [or firewire
    dc/dv cams for example] you save on converting YUV to RGB.
    There are of course some RGB-specific effects [e.g. in FreeJ
    you may use tree different layers displaying R plane of one,
    G plane of the other, B plane of the third] It's logical to
    use RGB for those. So i thought it could be useful to allow
    different formats. say in version 2.0 ;-)

    cheers,
    artm

     
  • Logged In: YES
    user_id=644854

    yeah - it seems like a reasonable request for 2.0

    if it was really important we could add it on as a new type,
    but I think most people might feel that the coherency and
    simplicity of 1.0 with its quite restricted formats has been
    the reason that freeframe 1.0 has taken so well and so fast.

    personally i'd most like to see more plugins developed on
    1.0, especially source (video synth) plugins, rather than
    new format developments before 2.0

    R

     
  • Logged In: YES
    user_id=564396

    btw, i have just implemented a freeframe host for pd/Gem and
    we seriously need YUV-support too, as it is "our" native
    colorspace on the osX-version.

    just to ensure, that there is still some need for this
    feature...

     
  • Logged In: YES
    user_id=644854

    Yes - YUV is pretty much top of the list for FreeFrame 2,
    although we must remember that not all plugin developers
    will choose to implement YUV even when it does come along
    in, and that some of them will probably use standard
    conversion routines in their plugins to convert into one
    colourspace rather than doing double maths.

     
    • priority: 5 --> 6