On Mon, Jan 2, 2017 at 3:08 PM, Pavel Koshevoy <pkoshe...@gmail.com> wrote:
> On Mon, Jan 2, 2017 at 2:00 PM, Hendrik Leppkes <h.lepp...@gmail.com> wrote:
>> On Jan 3, 2017 07:52, "Pavel Koshevoy" <pkoshe...@gmail.com> wrote:
>>
>> On Mon, Jan 2, 2017 at 9:37 AM, Philip Langdale <phil...@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.
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
