search

bluerobotics / cockpit

An intuitive and customizable cross-platform ground control station for remote vehicles of all types.
https://docs.bluerobotics.com/ardusub-zola/software/control-station/Cockpit-1.0/overview/
Other
42 stars 18 forks source link

Allow user to choose which video encode to use (or move to h264) #999

Closed patrickelectric closed 2 weeks ago

patrickelectric commented 3 weeks ago

At the moment we are enforcing VP9 https://github.com/bluerobotics/cockpit/blob/80decb76d437ad036b1d733939b912ca23819413/src/stores/video.ts#L304 Supported chrome codecs: https://www.chromium.org/audio-video/

rafaellehmkuhl commented 3 weeks ago

I think supporting the user to choose it is fine. Just changing to H264 does not seem to make sense to me.

VP9 is a newer codec, with a much better compression rate as well as a better final result, with less artifacts.

The only situation where I think it's an advantage to use H264 is when the user is having performance problems, which should not be common on standard devices.

rafaellehmkuhl commented 3 weeks ago

More info on that: https://developer.mozilla.org/en-US/docs/Web/Media/Formats/Video_codecs

patrickelectric commented 3 weeks ago

My point is that using a different codec will enforce a transcode of the video, resulting in a worst performance in some cases. It's more common to have VP9 decode, but not encode. As here: https://en.wikipedia.org/wiki/Intel_Quick_Sync_Video#Hardware_decoding_and_encoding Only Intel CPUs from 2019 provide VP9 encode (and we are not talking about real-time encode, only hardware support). It appears that Ryzen by default does not have VP9 encode: https://en.wikipedia.org/wiki/Video_Core_Next

This appears really weird but I could not find more information about it

Apple silicon appears to support encode/decode, but there is the real-time encode scenario.

two cents ? @Williangalvani @joaoantoniocardoso

patrickelectric commented 3 weeks ago

About VP9 in mac: BTW: https://github.com/iina/iina/issues/4554

joaoantoniocardoso commented 3 weeks ago

I think the default should be h264, just for the convenience. If we give the user the choice, the best would be if we could somehow check whether the browser has hardware encoding for each format, and then show a warning when it doesn't have hardware encoding.

rafaellehmkuhl commented 3 weeks ago

Investigating a little more I've discovered that no transcoding is done in the browser side, as can be seen in the image below, from a recording made with current master (which has container set to WEBM and codec set to VP9).

image

I will be closing #1001 and just opening a PR removing mentions to the content-type on the video pipeline.