Live data from Hacker News

AV1 video codec gains broader hardware support

fullystacked.net

81–90 of 210 posts

Re: AV1 video codec gains broader hardware support

#81

Is it really _that_ hard to create a generic video decoding DSP whose firmware could be updated? Most codecs are very similar to each other. IIRC Texas Instruments used multicore DSP to decode MPEG back in the 90s. Or maybe we should have written codecs to be amenable towards GPU shader implementation...

I wonder if encode could run on the iGPU?

I think, at least, that one of the biggest use-cases for encode is game streamers (is this right?), they should have decent dGPUs anyway, so their iGPU is just sitting there.

Re: AV1 video codec gains broader hardware support

#82

Earlier quoted context omitted.

That looks like a pure marketing slide to me. I don't think it would make sense to actually have separate dedicated silicon for these.

How would you do it in hardware otherwise?

You can either have a fully dedicated core for codecs, or you can just put certain codec related operations (like DCT-related SIMD) in your main cores. Cryptographic acceleration tends to use the latter approach.

Re: AV1 video codec gains broader hardware support

#83
I love AV1 for compressing my movies to 720p. I also convert any audio to Opus. I get to archive a ton of content on peanuts. The videos look great on my PC monitor or my phone and they come in at around 452MB (1hr 24m video).

Here's my script if you're interested in trying it out on your content.

    param (
      [Parameter(Mandatory=$true)]
      [string]$sourceDir,
    
      [string]$destDir = $sourceDir
    )

    $ffmpegPath = 'C:\Users\sergi\Downloads\ffmpeg.exe' 

    Write-Output "Starting conversion..."

    Get-ChildItem $sourceDir -Include *.mp4,*.avi,*.mov,*.wmv,*.flv,*.webm,*.mkv -Recurse | ForEach-Object {

      $newFileName = $_.BaseName + '-av1-720p' + $_.Extension
      $destPath = Join-Path $_.Directory.FullName $newFileName

      Write-Output "Converting $($_.FullName) to 720p AV1..."

      & $ffmpegPath -i $_.FullName -vf scale=1280:720 -c:v libsvtav1 -crf 30 -preset 7 -c:a libopus -b:a 96k -ac 2 $destPath
  
    }  

    Write-Output "Conversion complete."
And I just invoke it against a folder to recursively convert stuff.

    .\av1-convert.ps1 -sourceDir 'D:\Movies to convert\'
As soon as there's something that can decode AV1 that's like an nvidia shield I will replace both of my shields. So far nothing like that exists to my knowledge. Even Roku 4k Pro's say "AV1" support in their spec but they still trigger transcoding on plex when doing a playback.

Re: AV1 video codec gains broader hardware support

#84
post #64
post #60

Earlier quoted context omitted.

Very insightful, but is x265 really that bad? If you’re willing to wait, does slower presets help? I tested NVENC, X265, and DaVinci Resolve Studio’s H265 encoder. x265 was best by far. What more am I missing on?

Yes x265 is not in the conversation for even top 5 HEVC encoders, regardless of presets. [1] It can be especially surprising because x264 is easily the best AVC encoder. For whatever reason (patents, lack of browser support etc) there just hasn't been as much engineering effort put into x265. Now things like NVENC are even worse in terms of compression. Any GPU accelerated encoder trades compression efficiency for sp…

Are there any CPU+GPU pipelines that improve the speed without decreasing quality to the level of current GPU-only algorithms?

Seems strange that we have so much compute power in GPU, but no algorithms to use it well for encodes

Re: AV1 video codec gains broader hardware support

#85
post #5

Perhaps this might seem like a basic question, but why has it taken so long for processors to support AV1, given that it has been out for years?

Chicken & egg problem. No AV1 videos -> no pressure to add hardware support -> difficult to justify encoding videos in AV1

Netflix (and Youtube? I forget) will push an AV1 stream if you have the support. This was even mentioned in Apple's show yesterday. So the egg is already there and the chicken is slowly coming, thankfully.

Re: AV1 video codec gains broader hardware support

#86
post #48

According to the article, it's supported by every browser except Edge. It will be interesting to see who ultimately ends up making a better IE, Safari or Microsoft. So far, it seems Safari is winning, given the ever growing set of standards they don't support, but maybe this is Edge trying to catch up?

[flagged]

What is a "real" web browser? One would assume its an application that takes web content and parses it for user display so they can use it to browse the web...so Edge and Safari would surely be real, right?

Re: AV1 video codec gains broader hardware support

#87

How much silicon does it take to add an AV1 decoder to a chip? The areas Apple highlighted in their A17 release looked pretty substantial, but I wasnt sure if it was to scale. https://b3148424.smushcdn.com/3148424/wp-content/uploads/202...

That looks like a pure marketing slide to me. I don't think it would make sense to actually have separate dedicated silicon for these.

It is a pure marketing slide. The M3 variants floorplans don't look anything like that, as can be seen on other pictures of the dies.

That being said, it's pretty common to have dedicated silicon for video codecs. It normally takes the form of a little DSP with custom instructions to accelerate operations specific to the codec.

Re: AV1 video codec gains broader hardware support

#88
post #82

Earlier quoted context omitted.

How would you do it in hardware otherwise?

You can either have a fully dedicated core for codecs, or you can just put certain codec related operations (like DCT-related SIMD) in your main cores. Cryptographic acceleration tends to use the latter approach.

Video codecs usually come with GPUs, not CPUs. It is only on SoCs where this distinction is a more fuzzy.

On a GPU, you didn't have an option to interleave normal program stream with specialized partial-decoding instruction. You put encoded frame in and you get decoded frame back, the media engine was separate block from compute.

Though this is also changing; see Intel GuC firmware, which has (optionally) some decoding, encoding and processing based on compute.

Re: AV1 video codec gains broader hardware support

#89
post #12

I would add that broader AV1 support is also a good news for low latency application like Cloud gaming or streaming to VR headsets. HW accelerated encoding/decoding improve upon HEVC on every metrics so you can get near real-time streaming with higher quality and lower bandwidth requirements.

This doesn’t match up to my experience playing on Quest 3. Certainly I see better quality for lower bandwidth, but the client side decoding actually adds more latency at the point it actually looks better the HEVC.

Interesting... Then choosing the best codecs might depends on the specific use case and the amount of motion in particular.

I have a 3080 so I hadn't the chance to test AV1 yet. Is the latency difference significant as reported by VD ?

Re: AV1 video codec gains broader hardware support

#90
post #24

Earlier quoted context omitted.

Keep in mind that standards are moving slow, CODEC standards more so. The golden standard is still h264/AVC, which dates back to the nineties. This is primarily due to many appliances (set top boxes, cameras, phones, TVs) using the absolute cheapest hardware stack they can get their hands on.

+1 Indeed. Compared to other standards in streaming media, I'd say that AOMedia has found adoption a lot quicker. h265 (HEVC) was all but DoA until years after it's introduction Apple finally decided to embrace it. It is still by no means ubiquitous, mostly due to patent licensing, which significantly drives up the price of hardware in single digit dollars price range. Anecdotally, consider that Apple's HTTP Live Str…

>Anecdotally, consider that Apple's HTTP Live Streaming protocol (till version 6) relied on MPEG2TS

This sounds like you might be confusing that MPEG2TS might have something to do with the video encoding instead of it solely being the way the video/audio elementary streams are wrapped together into a single contained format. The transport stream was designed specifically for an unreliable streaming type of delivery vs a steady consistent type of source like reading from a dis[c|k]. There is nothing wrong with using a TS stream for HLS that makes it inferior.

Post reply on HN