[VDPAU] ffmpeg and HEVC: NumLongTermPicturesSlcieHeaderBits

[Philip Langdale]

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.

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.

--phil