[VDPAU] ffmpeg and HEVC: Partial success, need help understanding problem
José Hiram Soltren
jsoltren at nvidia.com
Tue May 26 10:17:59 PDT 2015
Hello,
On 05/26/2015 10:30 AM, Christian König wrote:
>> H.265/HEVC is the first codec to define, at the Specification level, that
>> only progressive frames must exist.
> That's actually not correct, MPEG1 defined only support for progressive content
> as well.
Hmm. To my knowledge, then. I'll double check to see what it is the NVIDIA
implementation does with MPEG1 progressive content.
--José
> But as far as I can see the VDPAU specification of frame vs. field handling in
> the mixer is completely independent of the codec in use. As far as I understand
> it the memory layout on NVIDIA hardware is that you always get two independent
> fields, no matter what is actually encoded in the bitstream.
>
> If that is changed than you probably would not only break the video mixer, but
> OpenGL VDPAU interop as well.
>
> Regards,
> Christian.
>
> On 26.05.2015 16:51, Jose Soltren wrote:
>> Hi Rémi - please see inline below.
>>
>> On 2015/05/26, 9:24 , "Rémi Denis-Courmont" <remi at remlab.net> wrote:
>>
>>> Le 2015-05-26 17:19, Jose Soltren a écrit :
>>>> Inline below.
>>>>
>>>> On 2015/05/23, 22:49 , "Philip Langdale" <philipl at overt.org> wrote:
>>>>
>>>>> On Sat, 23 May 2015 12:52:08 -0700
>>>>> Philip Langdale <philipl at overt.org> wrote:
>>>>>
>>>>>> Ok, that's not right. I'd forgotten what the original sample looked
>>>>>> like. What I think it really looks like is that it's rendering
>>>>>> twice
>>>>>> as tall as it should, alternating black lines with the actual
>>>>>> picture
>>>>>> lines, and then that's wrapping around.
>>>>> Really, what it ends up looking like is what you'd see if someone
>>>>> took
>>>>> a progressive frame, and then said it was really an interlaced frame
>>>>> with the top half as one field and the bottom half as another. I can
>>>>> provide samples if it helps.
>>>> Yep, that's exactly what is happening. Unfortunately, the answer is:
>>>> you
>>>> need to lie to VDPAU about what is happening here. Use
>>>> VDP_VIDEO_MIXER_PICTURE_STRUCTURE_TOP_FIELD as the
>>>> current_picture_structure parameter to VdpVideoMixerRender().
>>> I must be missing something obvious here. Isn't non-interlaced content
>>> the whole point of VDP_VIDEO_MIXER_PICTURE_STRUCTURE_FRAME?
>> Yes.
>>
>> However: every single video codec prior to H.265/HEVC actually output a
>> progressive frame as two independent fields! The reason for this is that
>> all prior codecs were defined with television in mind. Progressive
>> pictures are typically two half-pictures that need to be blended together
>> and presented at the same time.
>>
>> H.265/HEVC is the first codec to define, at the Specification level, that
>> only progressive frames must exist. (There are provisions for interlaced
>> content but they are left to addenda or extensions, not part of the
>> Specification.)
>>
>> So, at least the NVIDIA implementation of a video mixer always assumes
>> that a VDP_VIDEO_MIXER_PICTURE_STRUCTURE_FRAME has two fields that need to
>> be interleaved. This leads to the issue that Philip correctly described.
>>
>> I agree that the hack is inelegant and I welcome suggestions to improve
>> this. The proposal on the table is a new enumeration value, perhaps:
>>
>> VDP_VIDEO_MIXER_PICTURE_STRUCTURE_PROGRESSIVE
>>
>>
>> Thanks,
>> --José
>>
>> nvpublic
>>
>>> --
>>> Rémi Denis-Courmont
>>> http://www.remlab.net/
>> _______________________________________________
>> VDPAU mailing list
>> VDPAU at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/vdpau
>
More information about the VDPAU
mailing list