Announcement

Collapse
No announcement yet.

FFmpeg Adds Support For Animated JPEG-XL

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • skeevy420
    replied
    Originally posted by andyprough View Post

    Jpeg-xl uptake is inevitable due to its apparent freedom from patent encumbrance, both present and future. Apple probably isn't reacting to Google's decision as much as it is simply being herded in the direction of the non-patent encumbered image format, as all the big companies eventually will be.
    Yep. From the practical standpoint these days it makes sense to either do it in-house or to go with an open-source/non-patent encumbered format since the other option is licensing and the licensor having you by the balls for perpetuity.

    Leave a comment:


  • andyprough
    replied
    Originally posted by schmidtbag View Post
    Odd how Apple adds support shortly after Google removes it.
    Jpeg-xl uptake is inevitable due to its apparent freedom from patent encumbrance, both present and future. Apple probably isn't reacting to Google's decision as much as it is simply being herded in the direction of the non-patent encumbered image format, as all the big companies eventually will be.

    Leave a comment:


  • avis
    replied
    Originally posted by schmidtbag View Post
    Odd how Apple adds support shortly after Google removes it.

    Also gets me to realize:
    A lot of webcams use MJPEG - I figure that format isn't particularly optimized for 4K+ cameras, so what do they use? Or, is the lack of optimization why there are so few of such cameras?
    Lots of 4K web cameras continue to use MJPEG, some use H.264 as well. I've not seen any other codecs being used.

    I don't know why but web cameras are seemingly stuck in 2005 or something. Horrible optics, horrible audio, horrible everything.

    Leave a comment:


  • schmidtbag
    replied
    Odd how Apple adds support shortly after Google removes it.

    Also gets me to realize:
    A lot of webcams use MJPEG - I figure that format isn't particularly optimized for 4K+ cameras, so what do they use? Or, is the lack of optimization why there are so few of such cameras?

    Leave a comment:


  • MorrisS.
    replied
    How these codecs are integrated and implemented in browsers and other applications??

    Leave a comment:


  • Sethox
    replied
    Originally posted by avis View Post
    Are you sure 1) FFMpeg supports all the missing features 2) FFMpeg's implementation is even suitable for Firefox?

    So far Firefox has used FFMpeg only to demux MP4 and decode VP9 (not sure about that) and H.264.
    From an altruistic perspective, taking advantage of FFmpeg's resources (their implementation) sounds alright to me, from an intrinsic perspective I feel like Mozilla has JPEG-XL as a low priority, they just worked on it longer.

    But I am not on either developing teams, so my argument are based on speculation and wishful thinking in regards for the JPEG-XL to function.

    Leave a comment:


  • quikee
    replied
    Originally posted by pkese View Post
    I think the authors of JPEG-XL shoud add full fallback JPEG decoding as to their library (JPEG-XL is mostly a superset of JPEG anyway).
    They are doing that, and not only that - they are working on a highly capable JPEG encoder too.

    Leave a comment:


  • avis
    replied
    Originally posted by Sethox View Post

    Any support so that the end-user can use the feature/format. End-users do not tend to use beta versions for their daily workflow (Nightly). Even so if Nightly does support JPEG-XL it's Mozillas own implementation, while now there is an available path for Mozilla skip their own implementation and use FFmpeg solution instead (thus support via FFmpeg).
    Are you sure 1) FFMpeg supports all the missing features 2) FFMpeg's implementation is even suitable/feasible for Firefox?

    AFAIK Firefox has used FFMpeg only to demux MP4 and decode VP9 (not sure about that) and H.264.

    Leave a comment:


  • avis
    replied
    Originally posted by pkese View Post
    I think the authors of JPEG-XL shoud add full fallback JPEG decoding as to their library (JPEG-XL is mostly a superset of JPEG anyway).

    That would help to alleviate the political backpressure of folks saying that browser vendors are reluctant to add new libraries, because then there's more dependencies to support.

    With JPEG-XL taking care of JPEG as well, they could then simply drop their JPEG software and rely on JPEG-XL to decode both formats.
    Let's just say this is not an issue. Browsers already support JPEG, GIF, PNG, SVG, BMP and Web Fonts (which are often used to paint web site controls) via different libraries - just adding a new library is not something anyone cares about.

    Leave a comment:


  • Sethox
    replied
    Originally posted by avis View Post



    Define "support".

    Currently Firefox (nightly) kinda supports JPEG-XL except:
    • No color profiles support
    • No progressive decoding support
    • No alpha-channel support (that's very important)
    • No animation support (though I doubt anyone wants it - you've got video codecs for that)
    • No HDR support (that's a deal breaker at least for me)
    And it doesn't look like Firefox developers are too keen to add these features considering near complete silence in the respectful bug reports.

    Apple's support is not complete either but they have a ton of cash to burn, so it's just a matter of their will. Firefox with its slowly dissipating market share doesn't have too much leeway.
    Any support so that the end-user can use the feature/format. End-users do not tend to use beta versions for their daily workflow (Nightly). Even so if Nightly does support JPEG-XL it's Mozillas own implementation, while now there is an available path for Mozilla skip their own implementation and use FFmpeg solution instead (thus support via FFmpeg).

    Leave a comment:

Working...
X