[VDPAU] ffmpeg and HEVC: NumLongTermPicturesSlcieHeaderBits

[José Hiram Soltren]

Hello phil,

On 05/27/2015 03:38 PM, Philip Langdale wrote:
> On 2015-05-27 12:50, José Hiram Soltren wrote:
> 
>>> I've attached the trace from playing this file:
>>>
>>> https://s3.amazonaws.com/x265.org/video/Tractor_500kbps_x265.mp4
>>
>> This was an MP4 stream that I was able to demux using tsMuxer. mplayer's
>> -dumpvideo was not helpful here.
>>
>> I was able to play this without any issues using our in house VDPAU HEVC test
>> player. For simplicity, the NVIDIA internal player only operates on elementary
>> streams, and presents video in decode versus display order. The internal player
>> is designed to address issues with the video hardware. Presentation queue
>> management is entirely in software and is the client's responsibility.
>>
>> I generated two trace files when playing this for convenience:
>>
>> tractor.txt.gz, with VDPAU_TRACE=1
>> tractor.full.txt.gz, with VDPAU_TRACE=2
>>
>> I'm looking for clues by comparing the two.
>>
>> The first thing I notice is that mplayer/ffmpeg does not appear to pas the "00
>> 00 01" start code at the beginning of bitstreams in vdp_decoder_render. I
>> wonder if this is an issue.
> 
> I definitely pass the start code. Because when I didn't, things got really bad
> really
> fast. :-)
> 
>> typedef VdpStatus VdpVideoMixerRender(
>>     VdpVideoMixer                 mixer,
>>     VdpOutputSurface              background_surface,
>>     VdpRect const *               background_source_rect,
>>     VdpVideoMixerPictureStructure current_picture_structure,
>>     uint32_t                      video_surface_past_count,
>>     VdpVideoSurface const *       video_surface_past,
>>     VdpVideoSurface               video_surface_current,
>>     uint32_t                      video_surface_future_count,
>>     VdpVideoSurface const *       video_surface_future,
>>     VdpRect const *               video_source_rect,
>>     VdpOutputSurface              destination_surface,
>>     VdpRect const *               destination_rect,
>>     VdpRect const *               destination_video_rect,
>>     uint32_t                      layer_count,
>>     VdpLayer const *              layers
>> );
>>
>> Yours:
>>
>> vdp_video_mixer_render(
>>     5,
>>     4294967295,
>>     NULL,
>>     0,
>>     2,
>>     {4294967295, 4294967295},
>>     10,
>>     1,
>>     {10},
>>     {0, 0, 1920, 1080},
>>     6,
>>     NULL,
>>     {0, 0, 1920, 1080},
>>     0,
>>     NULL)
>>
>> Mine:
>>
>> vdp_video_mixer_render(
>>     29,
>>     4294967295,
>>     NULL,
>>     0,
>>     0,
>>     NULL,
>>     5,
>>     0,
>>     NULL,
>>     NULL,
>>     21,
>>     {0, 0, 1920, 1080},
>>     {0, 0, 1920, 1080},
>>     0,
>>     NULL)
>>
>> So it looks to me like you are passing in handles to video_surface_past and
>> video_surface_future. This is not correct. VdpVideoMixerRender should just be
>> showing standalone frames, not trying to blend past, present, and future frames
>> as it does for interlaced video.
> 
> Hmm. I may have run the trace with de-int turned on in mplayer, but I also ran it
> with de-int turned off and it didn't help. Maybe mplayer sets the surfaces
> regardless,
> but I thought it didn't. I'll double check.

Possibly. I don't have an in depth understanding of mplayer's surface
management code. The calls to VdpVideoMixerRender you provided are different
from mine as noted above.

> Are you guys going to change how the ouput surface in constructed? I know we're
> discussing
> presentation hacks here, but even get_bits on the output surface returns the
> interlaced
> form - I tested the basic ffmpeg mode where it doesn't do any presentation at
> all and
> just reads the surface back.

Possibly. I'll communicate any such plans on this list. The hardware decodes a
single progressive frame and places it into a single location in memory. This
is what VdpDecoderRender does. VdpVideoMixerRender would be the process
responsible for any interlacing you would see.

Thanks,
--José

> --phil