[MPlayer-dev-eng] Some question regarding H264 and Direct Rendering.

[Kjetil Hvalstrand]

Hi

Thanks for replying.

>If the speed difference is major that usually hints that something went

Hans de Ruiter has been investigating H264 codec, and found that x86
version has better support for CPU vector extensions, then the PowerPC
version has. Well might have something with Apple switching to Intel
in 2004.

http://www.amigans.net/modules/xforum/viewtopic.php?topic_id=6723&forum=25

>wrong/is badly implemented. It can at best save you one memcpy.

It’s not that simple as using memcpy to copy buffer from A to B, the
buffer has to be reformatted for Bitmap format that video drivers
support.

This means I have to convert the video slice from none interleaved
yuv420p into interleaved yuv420p.

Also I’m afraid that buffer might not be aligned so, it that I might
not be able to use any form of DMA to move the memory from A to B.

On AmigaOS4.1 the CPU has to do all the work, there is no VDPAU / UVD,
so any extra work the CPU has to do effects the number of CPU cycles
it has left to decode video.

So the more the VO has to work, the less CPU timer for VC.

> “Reference frames are a problem for several reasons, though the one that
>makes them kind of useless for direct rendering is that with direct
>rendering they might be stored in uncached memory, completely breaking
>performance.”

You mean swappable memory.AmigaOS4 native AllocVecTags() does allow
the user to define what memory should be swappable or not, the
standard clib malloc() function under AmigaOS4.1 is always swappable
memory I think, and I’m not sure its aligned to prevent cache misses.

>“Plus, we need to make a copy when drawing the OSD. Also, newer codecs like H.264 are problematic >since they do reordering”

“reordering” you mean that graphic is moved around, yes that happens
with MPEG as well, but I’m not rendering the OSD on top of the DR
buffer, I render it on top of the completed rendering (window), yes I
know that OSD can flicker but I’m only interested in speed, so I do
not care.

>“Most VOs can provide at most 3 or so buffers for direct rendering.”

I can provide as many as it needs it’s not a problem for me, memory is cheap.

>“but it seems more reasonable to fix the system to support 64 bit off_t Yes I agree, I’m just having bit “

I'm having problem convincing Steven Solie of Hyperion (the current
owners of AmigaOS) that this should fix it,

>“(but if the system doesn't support 64 bit off_t seeking
> in files > 4 GB will not work anyway, so which use cases does such a change fix?)”

Well the OS has support for seek64() and off64_t and so on, but this
are not used in mplayer, instead your using the __USE_FILE_OFFSET64
precompile switch, this essentially the problem.


Best Regards
Kjetil




2014-11-05 19:56 GMT+01:00 Reimar Döffinger <Reimar.Doeffinger at gmx.de>:
> On Tue, Nov 04, 2014 at 03:49:13AM +0100, Kjetil Hvalstrand wrote:
>> I also have another question I have also recently implemented video
>> output that support Direct Rendering, and I have notices that some of
>> codecs do not support it, is there any chance that H264 codec will
>> support Direct Rendering, the speed difference its major, on older
>> MPEG and OGG video codecs. There was some indications that H264 has
>> support for direct rendering in VLC, so way not Mplayer?
>
> If the speed difference is major that usually hints that something went
> wrong/is badly implemented.
> It can at best save you one memcpy.
> In vd_ffmpeg.c there is nonref_dr related code that can be manually
> enabled (as it works badly in corner-cases).
> Reference frames are a problem for several reasons, though the one that
> makes them kind of useless for direct rendering is that with direct
> rendering they might be stored in uncached memory, completely breaking
> performance. Plus, we need to make a copy when drawing the OSD.
> Also, newer codecs like H.264 are problematic since they do reordering
> and can have a large number of reference frames that need to be kept
> around, which can easily exhaust the number of buffers.
> Most VOs can provide at most 3 or so buffers for direct rendering.
>
>> In my port of mplayer for AmigaOS4.1, I needed to replace "typedef
>> off_t" as AmigaOS4.1 did not support that type as 64bit type, I
>> replaced it with uint64, do you think it might be possible make the
>> same change in official mplayer repository?
>
> I don't think that kind of change is easily possible without breaking
> things in subtle ways.
> It is not necessarily unacceptable, but it seems more reasonable to
> fix the system to support 64 bit off_t (but if the system doesn't
> support 64 bit off_t seeking in files > 4 GB will not work anyway,
> so which use cases does such a change fix?)
> _______________________________________________
> MPlayer-dev-eng mailing list
> MPlayer-dev-eng at mplayerhq.hu
> https://lists.mplayerhq.hu/mailman/listinfo/mplayer-dev-eng