[VDPAU] ffmpeg and HEVC: NumLongTermPicturesSlcieHeaderBits
José Hiram Soltren
jsoltren at nvidia.com
Wed May 27 13:54:10 PDT 2015
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
More information about the VDPAU
mailing list