Main.HardWareAccel History
Hide minor edits - Show changes to output
November 18, 2013, at 06:26 PM
by - revert bad merge
Deleted lines 0-2:
+webRTC+
=======
Changed lines 2-6 from:
<<<<<<<
-> ChromeOS and Android use hardware acceleration for webRTC
=======
to:
Changed lines 4-8 from:
<<<<<<<
-> peer 5 ships video p2p over RTC datachannels
=======
to:
Changed lines 6-10 from:
<<<<<<<
+Video Decoding+
=======
to:
Changed lines 9-26 from:
<<<<<<<
-> This coming year vp8 hardware decoding will be coming to android mobile through
-> nexus 5 has hardware encode and decode
-> many devices will follow (some Senzen devices already have decode)
-> mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in hardware
-> firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
-> internet archive needs to wait for announcements from large players
before they can begin encoding to vp8/9
=======
to:
Changed lines 11-16 from:
<<<<<<<
-> to get hardware accel into firefox = use about:support to see if gpu
compositing is turned on
=======
to:
Changed lines 13-29 from:
<<<<<<<
+Reason GPU cannot be used for encode/decode+
-> no big players are shipping with gpu accelerated encode/decode because super long pipelines are not compatible with parallelism used in gpu (gpu needs 1000 tasks at once). video decoding cannot be broken into that many parallel task
+What problems can the GPU solve?+
* hardware accel of post processing?
** low latency pipe and high latency corrector e.g. add noise back in post since noise is hard to compress
+More about hardware encode/decode+
-> the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
=======
to:
Changed lines 15-17 from:
->
to:
chrome has a gif redrawing bug that triggers redraw for all gifs on
page, even if not displayed https://code.google.com/p/chromium/issues/detail?id=285356
vp8 decoders are becoming stable enough that it is safe to say that if
Deleted lines 21-27:
-> standard testing resolution is 1080p @ 60fps (actualy measured in blocks per second)
+Software Codec Implementations+
-> libav on x86 and v4l2 on arm (chromebooks)
=======
Changed lines 23-29 from:
<<<<<<<
-> perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
=======
to:
Changed lines 25-29 from:
<<<<<<<
+Audio Codec Acceleration+
=======
to:
Changed lines 31-35 from:
<<<<<<<
-> video requires hardware more than audio (decoding)
=======
to:
Changed lines 33-38 from:
<<<<<<<
-> celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
=======
to:
Changed lines 36-41 from:
<<<<<<<
-> libav is doing an independent implementation of opus decoder, supported
by mozilla
=======
to:
Changed lines 38-42 from:
<<<<<<<
-> vbr opus should show substantial improvement in 1.1 over 1.0
=======
to:
Deleted line 39:
November 18, 2013, at 06:15 PM
by - formatting
Added lines 1-3:
<<<<<<<
+webRTC+
=======
+webRTC+
=======
Changed lines 5-9 from:
to:
>>>>>>>
<<<<<<<
-> ChromeOS and Android use hardware acceleration for webRTC
=======
<<<<<<<
-> ChromeOS and Android use hardware acceleration for webRTC
=======
Changed lines 11-15 from:
to:
>>>>>>>
<<<<<<<
-> peer 5 ships video p2p over RTC datachannels
=======
<<<<<<<
-> peer 5 ships video p2p over RTC datachannels
=======
Changed lines 17-21 from:
to:
>>>>>>>
<<<<<<<
+Video Decoding+
=======
<<<<<<<
+Video Decoding+
=======
Changed lines 24-41 from:
to:
>>>>>>>
<<<<<<<
-> This coming year vp8 hardware decoding will be coming to android mobile through
-> nexus 5 has hardware encode and decode
-> many devices will follow (some Senzen devices already have decode)
-> mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in hardware
-> firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
-> internet archive needs to wait for announcements from large players
before they can begin encoding to vp8/9
=======
<<<<<<<
-> This coming year vp8 hardware decoding will be coming to android mobile through
-> nexus 5 has hardware encode and decode
-> many devices will follow (some Senzen devices already have decode)
-> mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in hardware
-> firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
-> internet archive needs to wait for announcements from large players
before they can begin encoding to vp8/9
=======
Changed lines 43-48 from:
to:
>>>>>>>
<<<<<<<
-> to get hardware accel into firefox = use about:support to see if gpu
compositing is turned on
=======
<<<<<<<
-> to get hardware accel into firefox = use about:support to see if gpu
compositing is turned on
=======
Changed lines 50-66 from:
to:
>>>>>>>
<<<<<<<
+Reason GPU cannot be used for encode/decode+
-> no big players are shipping with gpu accelerated encode/decode because super long pipelines are not compatible with parallelism used in gpu (gpu needs 1000 tasks at once). video decoding cannot be broken into that many parallel task
+What problems can the GPU solve?+
* hardware accel of post processing?
** low latency pipe and high latency corrector e.g. add noise back in post since noise is hard to compress
+More about hardware encode/decode+
-> the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
=======
<<<<<<<
+Reason GPU cannot be used for encode/decode+
-> no big players are shipping with gpu accelerated encode/decode because super long pipelines are not compatible with parallelism used in gpu (gpu needs 1000 tasks at once). video decoding cannot be broken into that many parallel task
+What problems can the GPU solve?+
* hardware accel of post processing?
** low latency pipe and high latency corrector e.g. add noise back in post since noise is hard to compress
+More about hardware encode/decode+
-> the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
=======
Changed lines 68-72 from:
page, even if not displayed https://code.google.com/p/chromium/issues/detail?id=285356
vp8 decoders are becoming stable enough that it is safe to say that if
to:
>>>>>>>
-> vp8 decoders are becoming stable enough that it is safe to say that if
-> vp8 decoders are becoming stable enough that it is safe to say that if
Added lines 73-79:
<<<<<<<
-> standard testing resolution is 1080p @ 60fps (actualy measured in blocks per second)
+Software Codec Implementations+
-> libav on x86 and v4l2 on arm (chromebooks)
=======
-> standard testing resolution is 1080p @ 60fps (actualy measured in blocks per second)
+Software Codec Implementations+
-> libav on x86 and v4l2 on arm (chromebooks)
=======
Changed lines 81-87 from:
to:
>>>>>>>
<<<<<<<
-> perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
=======
<<<<<<<
-> perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
=======
Changed lines 89-93 from:
to:
>>>>>>>
<<<<<<<
+Audio Codec Acceleration+
=======
<<<<<<<
+Audio Codec Acceleration+
=======
Changed lines 99-103 from:
to:
>>>>>>>
<<<<<<<
-> video requires hardware more than audio (decoding)
=======
<<<<<<<
-> video requires hardware more than audio (decoding)
=======
Changed lines 105-110 from:
to:
>>>>>>>
<<<<<<<
-> celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
=======
<<<<<<<
-> celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
=======
Changed lines 113-118 from:
to:
>>>>>>>
<<<<<<<
-> libav is doing an independent implementation of opus decoder, supported
by mozilla
=======
<<<<<<<
-> libav is doing an independent implementation of opus decoder, supported
by mozilla
=======
Changed lines 120-124 from:
to:
>>>>>>>
<<<<<<<
-> vbr opus should show substantial improvement in 1.1 over 1.0
=======
<<<<<<<
-> vbr opus should show substantial improvement in 1.1 over 1.0
=======
Added line 126:
>>>>>>>
Changed lines 1-27 from:
This coming year vp8 hardware decoding will be coming to android mobile
nexus 5 has hardware encode and decode
many devices will follow
internet archive needs to wait for announcements from large players
before they can begin encoding
no big players are shipping with gpu
super long pipelines are not compatible with parallelism used in gpu
(gpu needs 1000 tasks at once)
video decoding cannot be broken into that many parallel task
gpu scaling for hardware accel of post processing?
low latency pipe and high latency corrector
e.g. add noise back in post since noise is hard to compress
the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
to:
WebRTC decode is HW-accelerated on ChromeOS (m31) & Chrome/Android (m32), with encode acceleration Coming Soon(tm).
VP8 HW is coming to most Android SoCs in 2014; Nexus5 is the first GED with VP8 HW encode & decode.
Internet Archive has been serving h264 to maximize power advantage of HW decode on mobile; would like some sort of announcements from large players before they can begin encoding to vp8/9 by default.
No big players are shipping with GPU acceleration of codec work. Super long pipelines are not compatible with parallelism used in gpu
(gpu needs 1000 tasks at once to saturate buses). Video decoding cannot be broken into that many parallel task.
Q: can gpu be used for hardware accel of post processing? Interesting; nobody doing it now.
Idea: use a fraction of the GPU to off-load some work, without paying the power cost of the GPU being utilized 100%. Unclear if the power architectures actually give a win here. (examples of where this could be used: remove noise before compression, add it back in post-proc on the client).
Q: are there products out there that take a video in and emit VP8 bitstream using HW? There are hobbyist projects out there based on ARM SoCs, and Big Player(tm) stuff, but not really a market in the middle.
VP8 HW is coming to most Android SoCs in 2014; Nexus5 is the first GED with VP8 HW encode & decode.
Internet Archive has been serving h264 to maximize power advantage of HW decode on mobile; would like some sort of announcements from large players before they can begin encoding to vp8/9 by default.
No big players are shipping with GPU acceleration of codec work. Super long pipelines are not compatible with parallelism used in gpu
(gpu needs 1000 tasks at once to saturate buses). Video decoding cannot be broken into that many parallel task.
Q: can gpu be used for hardware accel of post processing? Interesting; nobody doing it now.
Idea: use a fraction of the GPU to off-load some work, without paying the power cost of the GPU being utilized 100%. Unclear if the power architectures actually give a win here. (examples of where this could be used: remove noise before compression, add it back in post-proc on the client).
Q: are there products out there that take a video in and emit VP8 bitstream using HW? There are hobbyist projects out there based on ARM SoCs, and Big Player(tm) stuff, but not really a market in the middle.
Changed lines 22-49 from:
libav on x86 and v4l2 on arm (chromebooks)
how to get hardware accel into firefox = use about:support to see if gpu
compositing is turned
perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in
firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
peer 5 ships video p2p over RTC datachannels
video requires
celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
libav is doing an independent implementation of opus decoder, supported
by mozilla
vbr opus should show substantial
to:
Most codec HW ships by ticking a "1080p @ 60fps" check-box; in reality measured in macroblocks per second, sometimes can even split that budget across multiple streams!
ChromeOS uses VA-API on x86 and v4l2 on arm.
To see whether HW compositing is in effect in firefox: about:support
OpenMax-IL is the cross-vendor/cross-platform video API; unclear consensus on it among mfrs still (competition includes V4L2, VAAPI, and VDPAU)
Mozilla is looking at hardware decode, but firefox os hardware does not have vp8 decoders in hardware (qualcomm chips, not sure which; some do have the hardware). Unclear where the resources would come from.
Interesting examples of p2p video distribution over WebRTC DataChannels: peer5 & peercdn.
Celt OPUS encoder is substantially faster than vorbis encoder, but
decoder is slower.
libav is doing an independent implementation of opus decoder, supported by mozilla
vbr opus should show substantial performance improvement in 1.1 over 1.0
ChromeOS uses VA-API on x86 and v4l2 on arm.
To see whether HW compositing is in effect in firefox: about:support
OpenMax-IL is the cross-vendor/cross-platform video API; unclear consensus on it among mfrs still (competition includes V4L2, VAAPI, and VDPAU)
Mozilla is looking at hardware decode, but firefox os hardware does not have vp8 decoders in hardware (qualcomm chips, not sure which; some do have the hardware). Unclear where the resources would come from.
Interesting examples of p2p video distribution over WebRTC DataChannels: peer5 & peercdn.
Celt OPUS encoder is substantially faster than vorbis encoder, but
decoder is slower.
libav is doing an independent implementation of opus decoder, supported by mozilla
vbr opus should show substantial performance improvement in 1.1 over 1.0
November 18, 2013, at 01:54 AM
by - Initial copy from notes
Added lines 1-61:
chromeOS and android use hardware accel for webRTC
This coming year vp8 hardware decoding will be coming to android mobile
nexus 5 has hardware encode and decode
many devices will follow
internet archive needs to wait for announcements from large players
before they can begin encoding to vp8/9
no big players are shipping with gpu
super long pipelines are not compatible with parallelism used in gpu
(gpu needs 1000 tasks at once)
video decoding cannot be broken into that many parallel task
gpu scaling for hardware accel of post processing?
low latency pipe and high latency corrector
e.g. add noise back in post since noise is hard to compress
the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
chrome has a gif redrawing bug that triggers redraw for all gifs on
page, even if not displayed https://code.google.com/p/chromium/issues/detail?id=285356
vp8 decoders are becoming stable enough that it is safe to say that if
your video works in libvpx, it's likely to work in the hardware decoder
1080p @ 60fps (actualy measured in blocks per second)
libav on x86 and v4l2 on arm (chromebooks)
how to get hardware accel into firefox = use about:support to see if gpu
compositing is turned on
perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in hardware
firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
peer 5 ships video p2p over RTC datachannels
video requires hardware more than audio (decoding)
celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
libav is doing an independent implementation of opus decoder, supported
by mozilla
vbr opus should show substantial improvement in 1.1 over 1.0
This coming year vp8 hardware decoding will be coming to android mobile
nexus 5 has hardware encode and decode
many devices will follow
internet archive needs to wait for announcements from large players
before they can begin encoding to vp8/9
no big players are shipping with gpu
super long pipelines are not compatible with parallelism used in gpu
(gpu needs 1000 tasks at once)
video decoding cannot be broken into that many parallel task
gpu scaling for hardware accel of post processing?
low latency pipe and high latency corrector
e.g. add noise back in post since noise is hard to compress
the video capture/conversion via arm device for vp8 capture/streaming is
being pursued by hobbyists
chrome has a gif redrawing bug that triggers redraw for all gifs on
page, even if not displayed https://code.google.com/p/chromium/issues/detail?id=285356
vp8 decoders are becoming stable enough that it is safe to say that if
your video works in libvpx, it's likely to work in the hardware decoder
1080p @ 60fps (actualy measured in blocks per second)
libav on x86 and v4l2 on arm (chromebooks)
how to get hardware accel into firefox = use about:support to see if gpu
compositing is turned on
perhaps openmax will emerge as the arm-wide solution to consolidate
abstraction layers (lead by intel, this will depend on hardware
manufacturers)
mozilla is looking at hardware decode, but firefox os hardware does not
have vpx decoders in hardware
firefox uses qualcomm chips (8x74... in nexus 5 had vpx decoder), other
blocker is resources
peer 5 ships video p2p over RTC datachannels
video requires hardware more than audio (decoding)
celt layer opus encoder is substantially faster than vorbis encoder, but
decoder is slower
libav is doing an independent implementation of opus decoder, supported
by mozilla
vbr opus should show substantial improvement in 1.1 over 1.0
