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

[Reimar Döffinger]

On 07.11.2014, at 00:09, Kjetil Hvalstrand <kjetil.hvalstrand at gmail.com> wrote:
>> If you need to convert, direct rendering in the codec is pointless
> 
> No I simply feed it y, u, v data where u and v is at offset at
> (PictureWidth/2) basically.

Ok, I see now, I didn't know you can actually skip the conversion in the DR case.

>> if _codec_ support for direct rendering makes _any_ speed difference _whatsoever_ that means you implemented something incorrectly in the vo.
> 
> Of cause if there is a way to tell the mplayer or FFMPEG codec that my
> VO only supports padded interleaved yuv420p as video output, and that
> all draw_slice() should only give me interleaved yuv that is padded
> for DMA, then there should only be 3 memcpy's for etch plains.
> 
> And I would not need to convert from YUV420P to none interleaved to
> YUV420p interleaved.

Converting to this format however should only require a memcpy
for the U and V plane (into a buffer containing interleaved U and V), so it should be cheaper than a full copy.
Or if it needs to go into a special DMA buffer (but you said for DR you give it just a normal malloc'd buffer?) you also need to copy Y.
Either way it should only need 2 or 3 memcpy_pic.
Which can be significant if memory bandwidth is the bottleneck, though if you can copy only U and V to interleave them that would be less costly.
Also note that modifying vd_ffmpeg to set up interleaved buffers (but without full DR into vo-provided buffers) would be easier to implement, but if you need to copy anyway I don't think it should matter.

>> No, I mean B-trees. I.e. frames that are decoded in order 0 1 2 3 4 5 must be shown as e.g. 5 2 3 4 1 or similar.
> 
> Well right now the images are drawn when mplayer calls
> control(VOCTRL_DRAW_IMAGE,mpi)
> 
> I then call draw_image(mpi), and if the mpi -> flags is
> MP_IMGFLAG_DIRECT, then "mpi -> priv" gives me the image image buffer
> to draw.
> 
> On the next flip_page I really draw that buffer.
> 
> basically I'm doing it the same way as vo_xv.c is doing it, (I think),
> this seams to work correct.

What vo_xv does will definitely not work for DR with H.264.
It doesn't support the IMGTYPE_NUMBERED at all and thus can by design support no more than 3 frames in-flight.
That doesn't cause you to draw things in the wrong order, but it will end up giving the decoder the  wrong reference frames if DR was enabled, causing much stranger artefacts.