[RFC][PATCH] Replace deprecated get_buffer, buffer_hints, and others
Hi, Just joking, I'm not really replacing them. This is my proposed solution to the problem, that just drops dr for lavc codecs (except hwaccel). Why this? - modern codecs (eg. h264) are not compatible with the direct rendering structure of mplayer (IPB frames, 2 IP 1 B). It may be possible to do direct rendering for non-reference frames, but that also was already non functional (disabled because of some bugs) - dr is already failing today with most codecs, because of missing buffer_hints and reference flag. It fails also for things like mpeg2. Nobody complained. - dr is functional today for old simple codecs (eg. rpza), but performance is not relevant for someting written to run on a 386. - without buffer hints, I have no idea how to map the lavc frames to our frames, even when this could be possible (eg. mpeg2) - Wrapping our data structures in AVBuffers is a mess I have a patch that can replicate the behaviour of today (try dr and fail usually at the 2nd frame) with the new get_buffer2, if anybody is interested (I just need to clean it up). But I don't suggest to take this route. What about hwaccel? The hwaccel portion of the code is there, and may work. But I never used hwaccel, and I don't even know if my gpu (integrated into i7 Sandybridge) is supported by MPlayer hw acceleration. So somebody who has a clue about hwaccel should review and test it. This patch is just for comments; there is still a lot of code that is now useless but not removed yet, but it's late and I want to see what other MPlayer devels think about it. As usual it works for me, but I just did limited testing. If there is agreement on this solution I will clean it up and submit a proper patch. Ciao, Roberto
Hi, On Tuesday, 18 August 2015 at 01:42, Roberto Togni wrote:
Hi, Just joking, I'm not really replacing them.
This is my proposed solution to the problem, that just drops dr for lavc codecs (except hwaccel). [...] What about hwaccel?
The hwaccel portion of the code is there, and may work. But I never used hwaccel, and I don't even know if my gpu (integrated into i7 Sandybridge) is supported by MPlayer hw acceleration.
It kind is, though indirectly. You can use MPlayer's vdpau vo with libvdpau-va-gl backend (https://github.com/i-rinat/libvdpau-va-gl). I'm using the following on my F22 laptop: libva-intel-driver-1.5.1-1.fc22.x86_64 libva-1.5.1-1.fc22.x86_64 libvdpau-va-gl-0.3.4-6.fc22.x86_64 libvdpau-1.1-1.fc22.x86_64 The combination seems to support only H.264 baseline, main and high level 5.1 @1080p, but it works.
So somebody who has a clue about hwaccel should review and test it.
I can test it when I get some free time. Regards, Dominik -- MPlayer http://mplayerhq.hu | RPM Fusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan
On Tue, 18 Aug 2015 15:03:06 +0200 Dominik 'Rathann' Mierzejewski <dominik@greysector.net> wrote:
Hi,
On Tuesday, 18 August 2015 at 01:42, Roberto Togni wrote:
Hi, Just joking, I'm not really replacing them.
This is my proposed solution to the problem, that just drops dr for lavc codecs (except hwaccel). [...] What about hwaccel?
The hwaccel portion of the code is there, and may work. But I never used hwaccel, and I don't even know if my gpu (integrated into i7 Sandybridge) is supported by MPlayer hw acceleration.
It kind is, though indirectly. You can use MPlayer's vdpau vo with libvdpau-va-gl backend (https://github.com/i-rinat/libvdpau-va-gl).
I'm using the following on my F22 laptop: libva-intel-driver-1.5.1-1.fc22.x86_64 libva-1.5.1-1.fc22.x86_64 libvdpau-va-gl-0.3.4-6.fc22.x86_64 libvdpau-1.1-1.fc22.x86_64
The combination seems to support only H.264 baseline, main and high level 5.1 @1080p, but it works.
So somebody who has a clue about hwaccel should review and test it.
I can test it when I get some free time.
Thanks for the info, I was able to make it work with svn MPlayer. But vdpau is broken with my patch, don't waste your time testing it. I will submit a new patch soon. Ciao, Roberto
Hi, this patch removes the use of deprecated get_buffer() function, and the usage of deprecated fields in AVFrame. Differently from the previous patch, this one keeps our dr1 structure; if we then decide to drop it a lot of wrapper code can go out. Since my code was getting too complex to account for all the corner cases I decided to just copy the compatibility code from ffmpeg, and adapt it to out use. As usual the code can be further cleaned up, but this should be enough to allow compilation and functionality when the deprecated symbols are removed. It's tested with some codecs on the default vo (gl) and with -vo x11; H264 is tested also with vdpau acceleration. Please test it. Ciao, Roberto
On Sat, 22 Aug 2015 01:29:47 +0200 Roberto Togni <rxt@rtogni.it> wrote:
Hi, this patch removes the use of deprecated get_buffer() function, and the usage of deprecated fields in AVFrame.
Differently from the previous patch, this one keeps our dr1 structure; if we then decide to drop it a lot of wrapper code can go out.
Since my code was getting too complex to account for all the corner cases I decided to just copy the compatibility code from ffmpeg, and adapt it to out use.
As usual the code can be further cleaned up, but this should be enough to allow compilation and functionality when the deprecated symbols are removed.
It's tested with some codecs on the default vo (gl) and with -vo x11; H264 is tested also with vdpau acceleration.
Please test it.
Applied, it's needed with current FFmpeg git master. Ciao, Roberto
participants (2)
-
Dominik 'Rathann' Mierzejewski -
Roberto Togni