implant
11th August 2014, 20:31
Hello.
Currently, I work on a h.264 video decoder, which should be implemented in plain html 5. It should not rely on plugins to gain real browser- & device-independence.
The Broadway decoder shows that this is at least possible. Although the framerate of 10 fps for 1080p on an average system is not good. The other point is that it requires webGL for yuv -> rgb conversion.
For my use case, I have a NVIDIA GRID graphics card, which does the h.264 encoding. The video stream is then sent to a browser via streaming AJAX. I need to reduce the CPU load on the client below 50% while improving the framerate to at least 20 fps.
I can not use the html 5 <video> tag, because of no guaranteed support for mp4, but more important because the lack of video streaming support.
Solution 1 "tune": I use low compression (= high bandwith) and low framerate settings with the h.264 encoder. Then I hardcode the parameter sets in the decoder and optimize the source code. I use approximations instead of accuracy in the decoding process. I convert yuv -> rgb on macroblock update.
Solution 2 "rgb space": On the server, I encode the video stream normally with the NVIDIA GRID graphics card. Then, I decode the stream on the server again and extract the p-frame transformations. After this, I convert yuv -> rgb color space and encode a second time in software using the existing transformations. This will at least save the time for yuv -> rgb conversion on the client.
Solution 3 "jpeg intra": On the server, I encode the video stream normally with the NVIDIA GRID graphics card. Then, I decode the stream on the server again and extract the p-frame transformations, which are sent to the client in a custom format. The intra frame itself is captured seperately on the server and encoded as jpeg. The client loads and decodes it via <img> tag and applies the p-frame transformations. I suppose the quality is not as good but the performance is improved.
The only option for built-in acceleration I found is the jpeg/decoder of the browser.
I would like to hear what you think.
Currently, I work on a h.264 video decoder, which should be implemented in plain html 5. It should not rely on plugins to gain real browser- & device-independence.
The Broadway decoder shows that this is at least possible. Although the framerate of 10 fps for 1080p on an average system is not good. The other point is that it requires webGL for yuv -> rgb conversion.
For my use case, I have a NVIDIA GRID graphics card, which does the h.264 encoding. The video stream is then sent to a browser via streaming AJAX. I need to reduce the CPU load on the client below 50% while improving the framerate to at least 20 fps.
I can not use the html 5 <video> tag, because of no guaranteed support for mp4, but more important because the lack of video streaming support.
Solution 1 "tune": I use low compression (= high bandwith) and low framerate settings with the h.264 encoder. Then I hardcode the parameter sets in the decoder and optimize the source code. I use approximations instead of accuracy in the decoding process. I convert yuv -> rgb on macroblock update.
Solution 2 "rgb space": On the server, I encode the video stream normally with the NVIDIA GRID graphics card. Then, I decode the stream on the server again and extract the p-frame transformations. After this, I convert yuv -> rgb color space and encode a second time in software using the existing transformations. This will at least save the time for yuv -> rgb conversion on the client.
Solution 3 "jpeg intra": On the server, I encode the video stream normally with the NVIDIA GRID graphics card. Then, I decode the stream on the server again and extract the p-frame transformations, which are sent to the client in a custom format. The intra frame itself is captured seperately on the server and encoded as jpeg. The client loads and decodes it via <img> tag and applies the p-frame transformations. I suppose the quality is not as good but the performance is improved.
The only option for built-in acceleration I found is the jpeg/decoder of the browser.
I would like to hear what you think.