#304 Investigate if libVPX needs to still be built

Open
opened 3 years ago by mattatobin · 6 comments
mattatobin commented 3 years ago (Migrated from github.com)

There is some confusion over exactly what role libVPX plays in our code base with the stuff now compiled into mozavcodec. So we need to evaluate if libVPX is required for anything anymore.

At last word it may be that WebRTC needs it but that is not a concern for any current application except Basilisk.

It is possible that WebP support may need it.. It may also be true that only Windows needs it and Linux doesn’t. We just don’t know for sure.

At the very least full MOZ_VPX conditionals need to be reestablished around code that requires it.

There is some confusion over exactly what role libVPX plays in our code base with the stuff now compiled into `mozavcodec`. So we need to evaluate if libVPX is required for anything anymore. At last word it may be that WebRTC needs it but that is not a concern for any current application except `Basilisk`. It is possible that WebP support may need it.. It may also be true that only Windows needs it and Linux doesn't. We just don't know for sure. At the very least full MOZ_VPX conditionals need to be reestablished around code that requires it.
wolfbeast commented 3 years ago (Migrated from github.com)
Owner

WebP uses libwebp - which is standalone and has no dependency on libvpx even if the encoding technology is based on the same. So at least WebP should not need it.

WebRTC does need it for encoding. mozavcodec is only used for decoding afaik.

WebP uses libwebp - which is standalone and has no dependency on libvpx even if the encoding technology is based on the same. So at least WebP should not need it. WebRTC does need it for encoding. mozavcodec is only used for decoding afaik.
trav90 commented 3 years ago (Migrated from github.com)
Owner

Correct, mozavcodec is only used for decoding.

According to Mozilla they are keeping libvpx up to date for the benefit of WebRTC. As far as I know it is not used otherwise (unless ffvpx is disabled at build time).

Correct, mozavcodec is only used for decoding. According to Mozilla they are keeping libvpx up to date for the benefit of WebRTC. As far as I know it is not used otherwise (unless ffvpx is disabled at build time).
mattatobin commented 3 years ago (Migrated from github.com)
Owner

Well then at some point will test and see if Non-WebRTC clients can go without it then.

Well then at some point will test and see if Non-WebRTC clients can go without it then.
trav90 commented 2 years ago (Migrated from github.com)
Owner

Aside from being used by WebRTC, libVPX is also used as a last resort fallback if ffvpx is not built and no system installed FFmpeg packages are found.

Now that we are no longer building ffvpx on 32-bit *nix, it increases the likelihood that it will be needed (many distros do not install FFmpeg by default).

Aside from being used by WebRTC, libVPX is also used as a last resort fallback if ffvpx is not built and no system installed FFmpeg packages are found. Now that we are no longer building ffvpx on 32-bit *nix, it increases the likelihood that it will be needed (many distros do not install FFmpeg by default).
mattatobin commented 2 years ago (Migrated from github.com)
Owner

Is there no way to do MSE with libvpx or is that just a pipe dream.. One or the other I feel needs to go at some point in time and space. Personally, I would prefer to keep libvpx around since it is a hard dependency of webrtc..

But being realistic, webrtc will likely be one of those components that will age irreparably out of date and need culled anyway in the distant future. That is if it isn’t updated. So maybe prefer ffvpx?

What a mess Mozilla left us.

Is there no way to do MSE with `libvpx` or is that just a pipe dream.. One or the other I feel needs to go at some point in time and space. Personally, I would prefer to keep libvpx around since it is a hard dependency of webrtc.. But being realistic, webrtc will likely be one of those components that will age irreparably out of date and need culled anyway in the distant future. That is if it isn't updated. So maybe prefer ffvpx? What a mess Mozilla left us.
trav90 commented 2 years ago (Migrated from github.com)
Owner

When built (which is the default on all supported 64-bit platforms + 32-bit Windows), ffvpx is preferred and will be used. On 32-bit *nix or if ffvpx is disabled by the user, system installed FFmpeg packages will be used instead in a similar manner to what Tycho did (though I’m unsure how Windows handles this), with libvpx then being a fallback if FFmpeg can’t be found.

I can’t remember if libvpx can be used with MSE or not; I’ll have to look it up again. Mozilla switched to using ffvpx by default because they were already using FFmpeg anyway (GStreamer had already been kicked to the curb by this point), and ffvpx showed promising performance improvements over libvpx at the time.

When built (which is the default on all supported 64-bit platforms + 32-bit Windows), ffvpx is preferred and will be used. On 32-bit *nix or if ffvpx is disabled by the user, system installed FFmpeg packages will be used instead in a similar manner to what Tycho did (though I'm unsure how Windows handles this), with libvpx then being a fallback if FFmpeg can't be found. I can't remember if libvpx can be used with MSE or not; I'll have to look it up again. Mozilla switched to using ffvpx by default because they were already using FFmpeg anyway (GStreamer had already been kicked to the curb by this point), and ffvpx showed promising performance improvements over libvpx at the time.
Sign in to join this conversation.
No Milestone
No Assignees
1 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.