[FFmpeg-devel] [PATCH] lavc/cuvid: fail early if GPU can't handle given video resolution

Pavel Koshevoy pkoshevoy at gmail.com
Tue Jan 3 02:24:31 EET 2017


On Mon, Jan 2, 2017 at 3:08 PM, Pavel Koshevoy <pkoshevoy at gmail.com> wrote:
> On Mon, Jan 2, 2017 at 2:00 PM, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
>> On Jan 3, 2017 07:52, "Pavel Koshevoy" <pkoshevoy at gmail.com> wrote:
>>
>> On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale <philipl at overt.org> wrote:
>
>>> It is documented as only supporting 420, even though it doesn't return
>>> an error, so it's not a bug per-se - it's just that they don't detect
>>> and return an error, so we do it ourselves.
>>>
>>> --phil
>>
>>
>> I don't recall seeing it mentioned that they do not support 422 and
>> 444 in nvidia docs, but I haven't looked very hard yet.  I find it odd
>> that they have enum values to represent these chroma formats, yet they
>> don't work...  I'll see if I can file a bug with nvidia about this,
>> tomorrow.  I'll send another patch in about an hour to address the
>> original problem that got me looking in cuvid.c.
>>
>>
>> It's a rather well known limitation of the hardware. Only 4:2:0 and nothing
>> else.
>>
>> Now what one has to keep in mind is that the parser is somewhat independent
>> of the hardware capabilities (and the decoder), so it can inform you about
>> stream properties even if the hardware doesn't support it, while the
>> decoder is of course more tightly coupled to the hardware and therefore
>> excludes it directly.
>>
>> Feel free to open a bug if you must, but I don't see what good that's going
>> to do. The parser tells you what is in the stream, not if the hardware can
>> process it.
>>
>> - Hendrik
>
>
> Actually, I have a 4:2:2 file that does decode "fine" with mjpeg_cuvid:
> Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '422.mov':
>   Metadata:
>     creation_time   : 2004-04-12T14:27:11.000000Z
>   Duration: 00:00:26.28, start: 0.000000, bitrate: 27683 kb/s
>     Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj422p(pc,
> bt470bg/unknown/unknown), 720x486 [SAR 72:72 DAR 40:27], 27538 kb/s,
> 29.97 fps, 29.97 tbr, 2997 tbn, 2997 tbc (default)
>     Metadata:
>       creation_time   : 2004-04-12T14:27:11.000000Z
>       handler_name    : Apple Alias Data Handler
>       encoder         : Photo - JPEG
>     Stream #0:1(eng): Audio: mp3 (ms[0]U / 0x5500736D), 44100 Hz,
> stereo, s16p, 128 kb/s (default)
>     Metadata:
>       creation_time   : 2004-04-12T14:27:11.000000Z
>       handler_name    : Apple Alias Data Handler
>
> It decodes "fine", except for one green line along the bottom edge of the frame.
>
>
> The other file I have that decodes with severe artifacts with mpeg2_cuvid is:
> Input #0, mxf, from '422.mxf':
>   Metadata:
>     uid             : 903476a1-f73c-11df-bbb6-001c23d05b47
>     generation_uid  : 903476a2-f73c-11df-b56d-001c23d05b47
>     company_name    : Telestream
>     product_name    : FlipFactory
>     product_version : 3.0
>     application_platform: win32
>     product_uid     : ffeeddcc-bbaa-9988-7766-554433221100
>     modification_date: 2010-11-23T20:02:13.000000Z
>     material_package_umid:
> 0x060A2B340101010501010D12134CFC7B94BB4C04235505834F1F001C23D05B47
>     timecode        : 00:00:00:00
>   Duration: 00:03:35.05, start: 0.000000, bitrate: 62607 kb/s
>     Stream #0:0: Video: mpeg2video (4:2:2), yuv422p(tv,
> bt470bg/bt470m/bt470m, top first), 720x512 [SAR 128:135 DAR 4:3],
> 50000 kb/s, 29.97 fps, 29.97 tbr, 29.97 tbn, 59.94 tbc
>     Metadata:
>       file_package_umid:
> 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47
>       file_package_name: Source Package
>       track_name      : Track 1
>     Stream #0:1: Audio: pcm_s24le, 48000 Hz, 4 channels, s32 (24 bit), 4608 kb/s
>     Metadata:
>       file_package_umid:
> 0x060A2B340101010501010D121360585A56BB4C0423550583575A001C23D05B47
>       file_package_name: Source Package
>       track_name      : Track 2
>
> Still feels like an NVIDIA bug,
>     Pavel


I've tested three 4:2:2 mjpeg samples so far that decode fine with
mjpeg_cuvid, and one 4:4:4 mjpeg sample that also decoded correctly
with mjpeg_cuvid ... so it seems at least MJPEG support is not limited
to 4:2:0 by CUVID

    Pavel.


More information about the ffmpeg-devel mailing list