| Summary: | Re-enable VDPAU HEVC decoding support | ||
|---|---|---|---|
| Product: | Fedora | Reporter: | Ilja Sekler <bugzilla.i.sekler> |
| Component: | ffmpeg | Assignee: | Dominik 'Rathann' Mierzejewski <dominik> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | belegdol, kwizart, leigh123linux |
| Priority: | P3 | ||
| Version: | f29 | ||
| Hardware: | x86_64 | ||
| OS: | GNU/Linux | ||
| namespace: | |||
|
Description
Ilja Sekler
2019-01-27 15:59:54 CET
Oops, wrong link, the first patch to apply downstream is https://github.com/FFmpeg/FFmpeg/commit/4a6d5f3cadaabefe6c3548e575bb7e713997762f The second one is https://github.com/FFmpeg/FFmpeg/commit/4a976200d7853588336005a394dd31d905f5caf6 Thx for pointing at theses patches. Any idea if FFmpeg would pick them in their tree instead ? (for 4.0x ) This would be the best outcome by far. Unfortunately, no idea. There war no mention of the issue on the ffmpeg-devel ML since 4.0.3. FFmpeg maintainers are about to release 4.1.1, so an update for the 4.0 branch might follow soon. Could you please request inclusion of these commits into 4.0.4? The proper way is to ask upstream for a backport. I'll request that. I am against carrying any downstream patches in FFmpeg. Oh, and thank you for giving specific commit IDs to backport, that saves a lot of time! (In reply to Ilja Sekler from comment #0) > which landed on the 4.1 relbranch but didn't make it into the 4.0 one. > Please add these patches to FFmpeg packages provided by RPM Fusion. This > would allow Fedora users with old or weak CPUs and up-to-date NVIDIA > graphics cards to play HEVC encoded videos in real time. Why would you need vdpau for a nvidia card that uses nvidia-410.xx or greater? If you install xorg-x11-drv-nvidia-cuda-libs or xorg-x11-drv-nvidia-390.xx-cuda-libs it will enable nvdec. Run mpv with this command to enable it or edit mpv conf. mpv --hwdec=auto Playing: Venom (2018) (2160p BluRay x265 10bit HDR Tigole).mkv
(+) Video --vid=1 (*) (hevc 3840x1600 23.976fps)
(+) Audio --aid=1 --alang=eng (*) (aac 8ch 48000Hz)
Subs --sid=1 --slang=eng (dvd_subtitle)
Subs --sid=2 --slang=fre (dvd_subtitle)
Subs --sid=3 --slang=spa (dvd_subtitle)
File tags:
Title: Venom
Using hardware decoding (nvdec).
AO: [pulse] 48000Hz 7.1 8ch float
VO: [gpu] 3840x1600 cuda[p010]
AV: 00:01:03 / 01:52:08 (0%) A-V: 0.000
(In reply to leigh scott from comment #6) > Why would you need vdpau for a nvidia card that uses nvidia-410.xx or > greater? > If you install xorg-x11-drv-nvidia-cuda-libs or > xorg-x11-drv-nvidia-390.xx-cuda-libs it will enable nvdec. > Run mpv with this command to enable it or edit mpv conf. > > mpv --hwdec=auto Thank you for pointing this out, I was completely unaware of nvdec. It works fine for HEVC and H.264 (albeit with consistently slightly higher CPU load than with --hwdec=vdpau) in conjunction with --vo=gpu. nvdec is not a universally viable solution ATM because with nvdec, mpv is unable to use hardware accelerated deinterlacing for venerable mpeg2video, but it should be possible to replace mpv with some wrapper to specify --hwdec=vdpau for H.264 and MPEG. With regard to the suggestion of FFmpeg developers to switch to 4.1.x, I'd like to note that this is exactly what I was doing for a few private Fedora 29 installations I provided suppport for in order to solve the problem with HEVC decoding in HW. While no issues from this step surfaced so far (apart from compulsory rebuild of mpv), this experience doesn't pretend to replace exhaustive testing with all dependent packages. This is true that nvdec (and mpv if you want me to say it) are superior wrt hwdec, specially as this support nvdec/nvenc. But more players or video apps support the VDPAU API only and this bug was previously pending on the nvidia side that did not fixed their vdpau backend(/api). VDPAU mailing list is currently more active theses days with nvidia going to add HEVC 444 support with VDPAU Feature set J. So I really think these commits should be backported in FFmpeg branches as they do fix an interaction issue (with vdpau backend driver at least) and do not break interfaces (understand API/ABI is preserved), which should fit in the definition of "maintained branches". Hopefully this should be backportable down to FFmpeg 3.4.x (which we have in EL7). (In reply to Dominik 'Rathann' Mierzejewski from comment #4) > The proper way is to ask upstream for a backport. I'll request that. I am > against carrying any downstream patches in FFmpeg. +1 Ok, so upstream says we should update to 4.1.x as it's ABI/API compatible. We did know this might happen as FFmpeg release cycle is 3 months vs. Fedora's 6 months. I guess this is safe to patch for now and I'll be looking at updating to 4.1.x in F29 at some point. (In reply to Dominik 'Rathann' Mierzejewski from comment #11) > Ok, so upstream says we should update to 4.1.x as it's ABI/API compatible. > We did know this might happen as FFmpeg release cycle is 3 months vs. > Fedora's 6 months. I guess this is safe to patch for now and I'll be looking > at updating to 4.1.x in F29 at some point. Yet again on that point... And I'm still reluctant to update. (not saying I'm totally against). Kodi still use an hardcoded shared ffmpeg 4.0X, same for mythtv (still bundled) and what else ? Does that will make it easier/harder to unbundle libs ? I really want to focus on more packages in RPM Fusion than packaging monkey of the latest ffmpeg bits. Upstream pushing for the latest releases is a "no end" task. There is always a newer release than what's available on instant T. Now ffmpeg upstream has grown to have branches support why not use it to fix trivial interaction issue with various software releases ? (In reply to Dominik 'Rathann' Mierzejewski from comment #11) > We did know this might happen as FFmpeg release cycle is 3 months vs. > Fedora's 6 months. FYI ffmpeg is also a 6 month release cycle, looks like 4.2 will be too late for F30 3 months ago n4.2-dev 9 months ago n4.1-dev 15 months ago n3.5-dev 22 months ago n3.4-dev I'm indifferent to F29 getting 4.1 as long as no one expects me to help :-) (In reply to Nicolas Chauvet from comment #12) > And I'm still reluctant to update. (not saying I'm totally against). > Kodi still use an hardcoded shared ffmpeg 4.0X, same for mythtv (still > bundled) and what else ? We should be able to patch Kodi if necessary. MythTV has its own FFmpeg fork, modified, so it's not affected. HandBrake seems to support 4.1, even in latest release which we have in F28+: https://github.com/HandBrake/HandBrake/blob/1.2.0/contrib/ffmpeg/module.defs Looking at 4.1 API changes: https://git.videolan.org/?p=ffmpeg.git;a=blob_plain;f=doc/APIchanges;hb=HEAD I can see only additions, so we should really be safe to just update the FFmpeg package itself because anything that works with 4.0.x should just work with 4.1.x. In total, I counted 55 packages requiring ffmpeg-devel to build: $ dnf --disablerepo=\* --enablerepo=rpmfusion\*source repoquery --qf='%{name}' --arch=src --latest-limit=1 --whatrequires ffmpeg-devel | sort | wc -l 55 > Does that will make it easier/harder to unbundle libs ? Not sure what you mean here. > I really want to focus on more packages in RPM Fusion than packaging monkey > of the latest ffmpeg bits. > Upstream pushing for the latest releases is a "no end" task. There is always > a newer release than what's available on instant T. That's life. If all packages had testsuites which we could run automatically after rebuilding against newer FFmpeg (or even after just updating FFmpeg itself), that'd be ideal. But we don't live in an ideal world. [...] > Now ffmpeg upstream has grown to have branches support why not use it to fix > trivial interaction issue with various software releases ? As far as I understand, their support for old branches is limited to security fix backports and fixes for major bugs. (In reply to leigh scott from comment #13) > (In reply to Dominik 'Rathann' Mierzejewski from comment #11) > > We did know this might happen as FFmpeg release cycle is 3 months vs. > > Fedora's 6 months. > > FYI ffmpeg is also a 6 month release cycle, looks like 4.2 will be too late > for F30 > > 3 months ago n4.2-dev > 9 months ago n4.1-dev > 15 months ago n3.5-dev > 22 months ago n3.4-dev You're right. I think I meant to say that Fedora has 13 months between release and EOL while FFmpeg makes new releases every half a year more or less. Never mind. > I'm indifferent to F29 getting 4.1 as long as no one expects me to help :-) :) As the upstream has clearly expressed that they don't care, and Fedora 29 remains fully supported for over a half of a year while a move to FFmpeg 4.1.x is deemed too risky or too cumbersome, please reconsider applying the patches reinstating HEVC VDPAU decoding support downstream. (In reply to Ilja Sekler from comment #16) > As the upstream has clearly expressed that they don't care, and Fedora 29 > remains fully supported for over a half of a year. That means it will get the occasional update only and probably zero testing from me. > while a move to FFmpeg4.1.x is deemed too risky or too cumbersome, please > reconsider applying the patches reinstating HEVC VDPAU decoding support > downstream. I wont be backporting new features to a release I consider EOL. (In reply to leigh scott from comment #17) ... > I wont be backporting new features to a release I consider EOL. Fedora 29 clearly isn't EOL even if you don't use it. The patches are thins and if upstream don't care to fix interaction issue and some interested party report the backport to be functional with only theses two patches, then I would agree to have them in f28+ (where we have ffmpeg-4.0.x). (In reply to Nicolas Chauvet from comment #18) > (In reply to leigh scott from comment #17) > ... > > I wont be backporting new features to a release I consider EOL. > Fedora 29 clearly isn't EOL even if you don't use it. > Ok, that was poorly worded. I'm indifferent to the vdpau patching as long as no one expects me to do it :-) Is that better? > The patches are thins and if upstream don't care to fix interaction issue > and some interested party report the backport to be functional with only > theses two patches, then I would agree to have them in f28+ (where we have > ffmpeg-4.0.x). |