mention page number of vgbbd

[libreriscv.git] / nlnet_2019_video.mdwn

diff --git a/nlnet_2019_video.mdwn b/nlnet_2019_video.mdwn
index 9643bb8ff872dd2ef7bfe4995d47e77f7efd7208..36886a9c3f0d64fedef64600375772f0da008d25 100644 (file)
--- a/nlnet_2019_video.mdwn
+++ b/nlnet_2019_video.mdwn
@@ -1,5 +1,10 @@
 # NL.net proposal
 
+* [[questions]]
+* NLNet Project Page <https://nlnet.nl/project/LibreSoC-Video/>
+* 2019-10-031
+* Top Level bugreport <http://bugs.libre-riscv.org/show_bug.cgi?id=137>
+
 ## Project name
 
 The Libre-RISCV SoC, Video Acceleration
@@ -27,7 +32,7 @@ One of the main "hardware accelerated blocks" of any processor intended for user
 
 In a privacy-respecting world neither of these are acceptable, therefore the goal is to develop - in an iterative fashion - not just the software but the actual hardware instructions (similar to ARM NEON) which, if fully integrated into libswscale, ffmpeg, gstreamer and other software, would make RISC-V a truly commercially competitive peer of ARM and x86 systems when it comes to video acceleration.
 
-With such capability freely available for any implementor, there would be no excuse for the inclusion of spying hardware blocks or coprocessors in modern RISC-V processors, and certsinly not in the Libre RISC-V SoC.
+With such capability freely available for any implementor, there would be no excuse for the inclusion of spying hardware blocks or coprocessors in modern RISC-V processors, and certainly not in the Libre RISC-V SoC.
 
 # Have you been involved with projects or organisations relevant to this project before? And if so, can you tell us a bit about your contributions?
 
@@ -71,7 +76,11 @@ So the answer is: this initiative is unique, and there are no peer projects: the
 
 ## What are significant technical challenges you expect to solve during the project, if any?
 
-The actual process is technically quite straightforward, and given that ffmpeg and so on are quite well established and platform independent, the hotspot areas are typically already identified and have NEON or SSE/AVX etc assembly routines.
+The actual process is technically quite straightforward, and given that
+ffmpeg and so on are quite well established and platform independent,
+the hotspot areas are typically already identified (CABAC, DCT,
+Motion-estimation, YUV2RGB) and have NEON or SSE/AVX etc assembly
+routines.
 
 The main challenges will be communications, particularly as this is a huge cross project initiative, covering patches and additions to at least seven separate independent software projects, as well as requiring hardware development and simulations.