Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr) on November 19, 2020 4:04 am wrote:
> Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 2:57 pm wrote:
> > Maynard Handley (name99.delete@this.name99.org) on November 18, 2020 12:03 pm wrote:
> > > Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 11:25 am wrote:
> > > > Maynard Handley (name99.delete@this.name99.org) on November 18, 2020 11:03 am wrote:
> > > > > Dummond D. Slow (mental.delete@this.protozoa.us) on November 18, 2020 9:21 am wrote:
> > > > > > Maynard Handley (name99.delete@this.name99.org) on November 18, 2020 9:13 am wrote:
> > > > > > >
> > > > > > > x264 in SPEC is not there to help you decide which PC to buy for ripping DVD content!
> > > > > > > It is there as an exemplar of certain styles of code: various generic compression techniques
> > > > > > > (so lots of bit by bit manipulation) and various image analysis techniques (so searches
> > > > > > > over images and image comparisons at various frequency granularities).
> > > > > > >
> > > > > >
> > > > > > You didn't read it? If x264 is example of a kind of code, it is an example of code
> > > > > > heavily optimised with multimedia (integer) SIMD. It's a greeat example or maybe
> > > > > > too great, other codebases like ffmpeg or x265 will be a bit less optimized.
> > > > > >
> > > > > > If you want to explore such code, run it with assembly. It has assembly for ARM too, and not that
> > > > > > little of it. Without SIMD, it is the opposite of example of multimedia compression code.
> > > > > >
> > > > > > "Various generic compression techniques", my butt. This is an area I
> > > > > > know, so please don't talk armchair nonsense like you did just now.
> > > > >
> > > > > Armchair nonsense? OK then. I guess you don't know my employment history...
> > > > >
> > > >
> > > > Funny you say that because I do know. Was it Quicktime or do I have
> > > > different person? I wondered if you'll bring it up, because...
> > > >
> > > > Quicktime in fact has been the laughingstock of AVC encoding pretty much during the
> > > > whole era H.264 mattered (by that I mean say 2007-2012, if Quicktime's software got
> > > > better after that, sorry). But hey, at least it was able to beat Theora in quality.
> > > > Or I think it was, but the encoding test results were not pretty to put it mildly.
> > > >
> > > > For that matter, even QT's AVC decoding was plain horrible (basic features not decoding properly,
> > > > performance was meh too, at least on x86/x64), lol. And decoder is the easy thing.
> > > >
> > > > The software might have been better in all the other things
> > > > it does and it's AAC encoder is very nice if not best.
> > > > But it's AVC encodeing was PoS without any hyperbole. So if you
> > > > want to raise it as a proof you know this stuff, then AHUM AHUM.
> > >
> > > I left Apple in 2002, so blame other people if you're upset about 2007 to 2012.
> > >
> > > But the time that I *WAS* at Apple was precisely the years when codec design (audio, video, stills)
> > > was in constant flux, with new ideas every year. What mattered for someone investigating new
> > > codec design was not "how well does this CPU implement something that should properly be stuck
> > > in an ASIC", it was exactly the SPEC result -- how well does this CPU handle quick and dirty
> > > encoder/decoder type code that we're constantly modifying as we consider new ideas.
> > >
> >
> > Okay, and that is completely relevant as to the question we had, that is whether
> > video encoders require hand written assembly to be practical, is it not?
> > It is also completely irrelevant to the question whether assembly-less x264 that is 10x
> > or more slower than it should be is representative of video encoding, to anybody.
> > It also doesn't prove you knew what you were talking about when you tried to downplay
> > my previous posts and invoking your linkedin authority instead of sticking to facts.
> >
> > Also, I don't think you are even correct in the scope of your tangent. Codec design (which I followed a bit
> > as a hobby for the last two generations) does take ASIC implementations into account strongly, but it does
> > take software SIMD decoding on CPUs into account too.
>
> Sorry irrelevant, just asking out of curiosity:
> Are those up-to-date ASICs used to encode audio/video/stills still based on a
> set of microprocessors (or Digital Signal Processors) doing work in parallel,
> or are those ASICs more based on logic elements and no more programmed in C?

I never looked into this. I'd assume there might be some custom logic too in addition (but probably going to rely on DSP elsewhere), at least some times.
I know that the last few generations of formats relied heavily on input from hardware makers and many decisions were made based on what was hardware-friendly.

But when I saw it discussed, it was not clear if they do it in DSP or in custom logic. Usually things that they protested/blocked was requiring too much memory buffer capacity for some steps, having to loop over data repeatedly. In AV1, that lead to removal of some features or tipped decision between alternative proposals, but they wouldn't mention it being DSP-friendly and like that. I was not eavesdropping on it that directly though. Maybe ask in #daala on Freenode, people who participated are there and might tell you more about the interaction with hardware people.