By: Etienne Lorrain (etienne_lorrain.delete@this.yahoo.fr), November 19, 2020 5:04 am
Room: Moderated Discussions
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?
> 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?
