Announcement

Collapse
No announcement yet.

RAV1E: The "Fastest & Safest" AV1 Encoder

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

  • #21
    Gusar - maybe it was true once upon a time........not necessarily anymore. Compilers have been improving all the time.

    Comment


    • #22
      Decoding speed seems to be good, at least the test video works great in Firefox https://demo.bitmovin.com/public/firefox/av1. Sure, it would be great if AV1 can convert videos on demand for streaming from normal hardware very fast, but for now I'm more interested in the compression efficiency of the videos itself. If I can safe a reasonable amount of disk space then I can safe network bandwidth as well with AV1.

      Comment


      • #23
        Originally posted by sandy8925 View Post
        Gusar - maybe it was true once upon a time........not necessarily anymore. Compilers have been improving all the time.
        Compilers would need to actually understand what the software should be doing to get anywhere near what a decent assembly programmer can do.

        Compiler optimization focuses on lower level stuff as that's the most of what the compiler "intelligence" can deal with, but if you actually understand the logic, the goals of the software, you can do much more.

        Compilers will have to become specialist AI software for this gap to lessen significantly.

        For example, some assembler optimizations in a recent software here gave a x2.5 speed improvement over what the compiler can do https://www.phoronix.com/scan.php?pa...-Optimizations

        Or hand-written functions for the Glibc giving around 50% performance improvement on hardware supporting newer instructions (instead of assuming that the compiler will do it right if compiled with -march=native for newer hardware, as it won't) https://www.phoronix.com/scan.php?pa...ath-Glibc-2.27

        Comment


        • #24
          starshipeleven - But, software for distributions is generally not compiled with march=native (leaving aside Gentoo, and Clear Linux). So, that's why they add such code in glibc, x264, x265 so that the optimized versions can be used where needed, but portability is maintained.

          Comment


          • #25
            Originally posted by sandy8925 View Post
            starshipeleven - But, software for distributions is generally not compiled with march=native (leaving aside Gentoo, and Clear Linux). So, that's why they add such code in glibc, x264, x265 so that the optimized versions can be used where needed, but portability is maintained.
            No it's not. march=native does not make the compiler optimize better, it only tells the compiler that it can use instructions offered by the actual hardware. This of course improves performance as the compiler can use better instructions, but it's not the point of hand-optimized assembler, and why such optimizations are still better.

            Assembler optimizations aren't about using instructions the compiler does not know about, but about optimizing the code beyond what the compiler can do.

            Comment


            • #26
              Originally posted by sandy8925 View Post
              It seems stupid to depend on hand written assembly for faster encoding/decoding. Wouldn't compiling with march=native and mtune=native take you atleast part of the way there? (If not all the way)
              Compilers generally write pretty poor code, it's just that most people don't care.

              Anyone who says a compiler will "outsmart" a human when optimizing has absolutely *no* idea what he is talking about (yes, this is one of those myths I truly despise because they're flung around by morons who don't want to learn assembly and use it as an excuse as to why they don't -- they want it to be true, but it doesn't mean it is).

              It's not the compiler's fault, necessarily though. It's also the programmer's and (usually) the project manager.

              For some reason, a lot of idiots won't accept "hacky" HLL solutions or trying to coerce a compiler into generating optimal code. It takes a lot of "nasty" and "unclear" hand-holding to make the compiler generate proper code (because it just cannot guess what you want to do, no matter how "smart" it is, it has to follow reproducible rules and not guess, compilers are NOT magic).

              But you see, those managers accept assembly where it matters, but won't accept "ugly" C code despite the fact it's probably more readable than asm (in some cases). Because they want to keep HLL code "stupidly easy to understand for monkeys". Yuck.

              It's rare to see gems like the algos from Hacker's Delight still used. When I see that, I respect that project a lot.

              Comment


              • #27
                Originally posted by sandy8925 View Post
                Gusar - maybe it was true once upon a time........not necessarily anymore. Compilers have been improving all the time.
                Nope. Some things are just not possible because the compiler would have to guess. Yes you can coerce it with "ugly" code to generate optimal code, but then most people won't classify it as "clear HLL code" anymore so...

                Also note that some GCC devs flat-out refuse patches that would improve optimizations if they take a significant amount of compilation time. So half the reason compilers won't match a human is because they won't give an option for people who want to use all optimizations and expensive compilation for the best possible code. Thinking that compilers "always improve" in terms of code generation is a myth. In some cases they even regress, to "simplify" the compiler internally. Yes, I find it appalling, but w/e.

                I'm not bashing GCC, it's still the best compiler, just wish they had a more open attitude for people who don't mind spending hours to compile a small project with maximum optimizations. Meh. LLVM is even worse and clearly optimizations are not their priorities. Sigh.
                Last edited by Weasel; 16 July 2018, 07:43 AM.

                Comment


                • #28
                  Originally posted by starshipeleven View Post
                  No it's not. march=native does not make the compiler optimize better, it only tells the compiler that it can use instructions offered by the actual hardware. This of course improves performance as the compiler can use better instructions, but it's not the point of hand-optimized assembler, and why such optimizations are still better.
                  march implies mtune, so technically, it should generate better code, as far as the compiler is taught how the CPU works obviously.

                  This is mostly about low level stuff like the peculiarities of a particular CPU (i.e. pipelining, fusing, branch prediction and whatever). Just instruction scheduling, usually.

                  Comment


                  • #29
                    Because somebody has to make the Spongebob reference: "Rav1e-oli, Rav1e-oli, give me the sourcecode-oli."

                    Originally posted by Grinch View Post
                    I recall reading that Google split up the videos in chunks and encode them in single thread modes across huge clusters, and I would imagine the same holds true for Netflix/Amazon, meaning there's no pressing need for them to improve multi-threaded encoding.
                    I recently ran across a 2016 article saying the same: http://www.streamingmedia.com/Articl...ne-111550.aspx

                    Originally posted by Weasel View Post
                    Wah VP9 doesn't cover my niche use cases, must be useless garbage.

                    All mainstream OSes don't handle some critical but extremely niche use cases. They must be useless garbage also.
                    When your "niche use case" is "ripping DVDs I own to my computer that I own for my personal viewing", and it takes hours on a 3+GHz quad-core to encode a 480p episode at higher quality, yes, it is useless garbage.

                    Which is why I've stuck to VP8 for that.
                    Last edited by mulenmar; 16 July 2018, 02:13 PM.

                    Comment


                    • #30
                      This thread reminds me of doing mp3 encoding overnight for cds in 1995, clearly mp3 is so unusably slow.

                      At least part of the reason h264/h265 encoding is currently fast is that the hardware has specific accelerated encoding features for them that the encoding software uses.

                      Comment

                      Working...
                      X