-
Notifications
You must be signed in to change notification settings - Fork 72
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support H.265/HEVC, VP8, VP9 #279
Conversation
Finished testing new 'unified' install_ffmpeg.sh from go-livepeer and added it to circle-ci job. We shouldn't need a separate one for lpms now. For dev/test install, add
I checked new codecs tests with this |
@leszko What is the reason for including |
@darkdarkdragon I added these. It makes sense to support MKV and WebM containers for VP8/9, and AAC is not supported for WebM - that's why Opus is added. DASH is a great alternative to HLS (especially for WebM), we might want to support it in the near future too. |
Any addition to the production build increases attack surface - so we shouldn't add anything that don't officially support. Also, shouldn't |
That's a good practice, but aren't we adding VP8/9 support at least for decoding with this PR? If so, common containers used with these are MKV and WEBM, and lpms now supports them. Or, since VP8/9 is an exotic choice for HLS+MPEG-TS, we should not enable these codecs at all until other streaming protocols are not implemented on go-livepeer side? |
I think
We're really not using HLS output of go-livepeer node nowdays - it is being handled by Mist (I think in the near future, when we will integrate Mist and go-livepeer better we'll remove RTMP and HLS support from go-livepeer node) |
Created a new issue for additional container formats, and moved these flags to debug build for now. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall LGTM!
As a separate matter, one thing I'm thinking of is to statically link x265 and libvpx like x264. Because if we link it dynamically, we need to set LD_LIBRARY_PATH or add related .so files to the distribution. WDYT?
and I wonder how this part will work on the VP8/VP9/H265.
Spent quite a bit of time and got Ffmpeg to build with new codecs as static libraries. However, libx265 is a C++ lib, and I couldn't get CGO to build lpms properly when it statically linked, and don't know if it's a good idea to switch to g++ in lpms. At this point, I believe it's not worth the effort to get it to build statically with libx265. If someone is willing to continue looking into that, my efforts stopped there (set proper PKG_CONFIG_PATH and use linked
Without
|
It doesn't, none of these parameters work for HEVC or VP8/9 to my knowledge, so they are ignored. |
@cyberj0g Does the node boot without libx265, only loading it dynamically when needed? I don't think we probably want to add an external libx265 dependency if not. |
I think we agreed to not include software versions of new codecs into production build for now, so it won't be an issue. In debug mode, |
@@ -232,7 +232,7 @@ int open_output(struct output_ctx *octx, struct input_ctx *ictx) | |||
if (octx->fps.den) vc->time_base = av_buffersink_get_time_base(octx->vf.sink_ctx); | |||
else if (ictx->vc->time_base.num && ictx->vc->time_base.den) vc->time_base = ictx->vc->time_base; | |||
else vc->time_base = ictx->ic->streams[ictx->vi]->time_base; | |||
if (octx->bitrate) vc->rc_min_rate = vc->rc_max_rate = vc->rc_buffer_size = octx->bitrate; | |||
if (octx->bitrate) vc->rc_min_rate = vc->bit_rate = vc->rc_max_rate = vc->rc_buffer_size = octx->bitrate; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Were there problems with the bitrate prior to this change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, IIRC hevc_nvenc didn't work with rc_max_rate
set without setting bit_rate
. I might be wrong, but for H.264 it was incorrect to not set bit_rate
, if requested, either, because otherwise it won't switch to average bitrate mode. And the idea behind setting bit_rate
equal to rc_max_rate
is to force constant bitrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Gotcha. Seems reasonable, but I'm curious if this has resulted in any issues for anyone.
cc @iameli - have we seen issues with bitrate before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for review @yondonfu, I addressed all comments.
@@ -232,7 +232,7 @@ int open_output(struct output_ctx *octx, struct input_ctx *ictx) | |||
if (octx->fps.den) vc->time_base = av_buffersink_get_time_base(octx->vf.sink_ctx); | |||
else if (ictx->vc->time_base.num && ictx->vc->time_base.den) vc->time_base = ictx->vc->time_base; | |||
else vc->time_base = ictx->ic->streams[ictx->vi]->time_base; | |||
if (octx->bitrate) vc->rc_min_rate = vc->rc_max_rate = vc->rc_buffer_size = octx->bitrate; | |||
if (octx->bitrate) vc->rc_min_rate = vc->bit_rate = vc->rc_max_rate = vc->rc_buffer_size = octx->bitrate; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, IIRC hevc_nvenc didn't work with rc_max_rate
set without setting bit_rate
. I might be wrong, but for H.264 it was incorrect to not set bit_rate
, if requested, either, because otherwise it won't switch to average bitrate mode. And the idea behind setting bit_rate
equal to rc_max_rate
is to force constant bitrate.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! I'd like to get an approval from another set of eyes that has familiarity with this codebase as well. cc @oscar-davids since you already left an initial review.
I left a minor comment about updating a comment - feel free to address prior to merging. Also, I recommend rebasing off master to pick up a fix that landed recently that should address the failing test in CI and to squash the commits to clean up the commit history before merging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
please rebase on master to fix CI errors before merging.
Issue link: livepeer/go-livepeer#2123
Details:
Testing:
They will output lines like below, and fail, if anything is not supported (on CI, only CPU test will run for now). SW test should work anywhere, Nvidia test should pass on GPUs starting from desktop GTX 1070 - it can't decode VP9 on my GTX 1070m, despite support matrix stating it should.