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
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
