Announcement

Collapse
No announcement yet.

FFmpeg Adds Support For Animated JPEG-XL

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

  • #11
    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.

    Comment


    • #12
      How these codecs are integrated and implemented in browsers and other applications??

      Comment


      • #13
        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?

        Comment


        • #14
          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.

          Comment


          • #15
            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.

            Comment


            • #16
              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.

              Comment


              • #17
                Great. A lossy format I now need to support loading, copying the first frame, and saving during the user upload process in order to work around browsers not having something like img { animate: none; }

                At least with APNG, it's an explicit violation of the PNG spec, which says that the PNG header indicates a file which contains one image and, optionally, alternatively-scaled copies of it.​ (That's why Mozilla has to maintain their own fork of libpng. Because libpng is the reference implementation and you can't upstream changes to the reference implementation which explicitly violate the spec it's a reference implementation for.)

                Comment


                • #18
                  While I'm not a Chrome user myself, I still believe it's essential that Google reconsiders its stance on JPEG-XL support. By doing so, Google would maintain consistency and compatibility across major browsers, benefiting users, developers, and the broader web community. Let's hope for positive change, in the spirit of progress and widespread adaptation of evolving web technologies.

                  Comment


                  • #19
                    Originally posted by skeevy420 View Post

                    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.
                    I thought a software patent is valid for 20 years?

                    Disclaimer: I'm against any software patents ever.

                    Comment


                    • #20
                      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?
                      MJPEG is used for security camera applications and was used ages ago for webcams. Ever see low-res herky-jerky security cam footage? That's MJPEG usage. H.264 is now used for webcams these days, because it provides an actual synced video stream and there are streaming encoders built into both cams and GPUs, for that specific application.

                      Apple wants to implement it because their corporate friends, particularly Adobe, want it to work with their software offerings. They will not use it for their phones any time soon, as they already have HEIF.
                      Last edited by TheLexMachine; 08 June 2023, 05:06 PM.

                      Comment

                      Working...
                      X