[Ffmpeg-devel-irc] ffmpeg-devel.log.20191027

[burek]

[12:23:06 CET] <cone-404> ffmpeg 03Paul B Mahol 07master:ebff4bbd82c3: avcodec/vmdvideo: fix log error message
[15:04:08 CET] <durandal_1707> pross: is there ansi/xbin/bin codes specification?
[15:56:13 CET] <Lynne> BtbN, philipl, jkqxz: made a final version of the vulkan patches here https://github.com/cyanreg/FFmpeg/pull/1/commits
[15:57:02 CET] <Lynne> decided to squash the hwcontext_cuda changes for transfers into the base hwcontext commit (since it already modified hwcontext_cuda for cuda->vulkan device deriving)
[15:58:09 CET] <Lynne> don't really want to push a megabyte of N patches to the ML multiple times for multiple revisions, so not sure what to do
[15:59:35 CET] <durandal_1707> Lynne: the patches are so big?
[16:25:30 CET] <philipl> Lynne: squashing is fine.
[16:25:47 CET] <philipl> I'm happy to review on github, until we've got a final revision to send to the list.
[16:56:13 CET] <Lynne> philipl: btw is yuv420p used internally on nvidia by default instead of nv12?
[17:05:15 CET] <philipl> no. it's nv12
[17:05:27 CET] <JEEB> yea, hardware generally seems to be optimized for NV12
[17:05:29 CET] <philipl> for the actual hardware decoding.
[17:05:56 CET] <philipl> the hwcontext_cuda can handle most normal formats. We'v got generic pixdesc based code in there.
[17:06:10 CET] <JEEB> could of course be the other way and MS more or less spec'ifying NV12 is what lead to it
[17:06:15 CET] <JEEB> *led to it
[17:06:47 CET] <Lynne> philipl: because for a default pipeline I need to hwdownload yuv420p from vulkan to get frames to system ram
[17:07:19 CET] <philipl> Hmm. It should depend on what you've got next after the download right?
[17:07:27 CET] <philipl> hwdownload to nv12 should work too
[17:09:34 CET] <Lynne> ./ffmpeg_g -init_hw_device "cuda=cu:0" -hwaccel_output_format cuda -i sample.mkv -filter_hw_device cu -vf hwupload=derive_device=vulkan,avgblur_vulkan=planes=0xF:sizeX=5:sizeY=5,hwdownload,format=yuv420p -f null -
[17:09:49 CET] <Lynne> trying to download nv12 gives the usual error
[17:10:03 CET] <philipl> [hwdownload @ 0x55f1bf25e7c0] Invalid output format nv12 for hwframe download.
[17:10:06 CET] <philipl> hmm
[17:10:17 CET] <philipl> I don't remember that being the case.
[17:13:04 CET] <philipl> Lynne: so
[17:13:53 CET] <philipl> it's because we (everyone, not just you and me) write transfer_get_formats to return the internal sw format being used by the hwframe and nothing else.
[17:14:15 CET] <philipl> and I guess you end up using yuv420p as the internal format for 8bit content.
[17:14:27 CET] <philipl> if you'd used nv12, then only format=nv12 would work, etc.
[17:15:27 CET] <philipl> you'd need to run it through a scale filter to convert it before downloading
[17:16:06 CET] <philipl> (assuming scale_vulkan does format conversion. I didn't look at that yet)
[17:17:40 CET] <Lynne> no, it doesn't do format conversion, there used to be code to allow you to download a mono format from yuv but I deleted it since it wasn't really useful
[17:18:25 CET] <Lynne> I didn't get why yuv420p is used internally however
[17:18:41 CET] <Lynne> does something happen during the transfer or did the driver decide it?
[17:18:54 CET] <Lynne> on vaapi/drm nv12 is the default
[17:20:41 CET] <philipl> hmm.
[17:20:48 CET] <philipl> something has changed here recently
[17:22:38 CET] <philipl> Lynne: it's because you, and I independently, forgot to put '-hwaccel nvdec' in there.
[17:22:45 CET] <philipl> so it's not hardware decoding.
[17:23:59 CET] <philipl> Ok, now it works as expected.
[17:33:18 CET] <Lynne> oh, right, I actually found that out later when looking at the CPU and put it there when testing again but only tried using h264_nvenc rather than downloading
[17:34:30 CET] <Lynne> maybe hwupload shouldn't require a device reference for derive_device? or have a separate device_create option
[17:35:02 CET] <Lynne> so you wouldn't need to specify and initialize filter_hw_device for uploading from software
[17:51:36 CET] <philipl> Lynne: I had that. jkqxz didn't like it. :-)
[17:52:06 CET] <philipl> I do think it would be nice if it could implicitly use the decoder's device in the case of cuda hw decode and then derive from that device.
[17:52:16 CET] <philipl> Right now you need to init a separate device for the filter chain.
[18:11:33 CET] <Lynne> btw I noticed I can also init a vulkan hw device and specify it as the filter_hw_device
[18:12:06 CET] <Lynne> and nothing changes? shouldn't hwupload check the specified filter_hw_device is valid?
[18:13:25 CET] <Lynne> I guess its checking something, if I specify an opencl its returning function not implemented
[18:13:53 CET] <Lynne> but for some reason a vulkan device works too, even though you're uploading from cuda to vulkan
[18:25:13 CET] <philipl> Lynne: it's because the devices match and so the transfer succeeds when it happens
[18:26:21 CET] <philipl> basically it bypasses validation, but everything is still going to work, so it works.
[18:36:37 CET] <Lynne> I don't mind that
[21:41:51 CET] <philipl> Lynne: I tried a transcode of 10bit hevc and the output was garbled. 12bit was fine.
[21:42:30 CET] <philipl> ffmpeg -hwaccel nvdec -hwaccel_output_format cuda -i video-x265-12bit-420.mp4 -init_hw_device vulkan=vulkan:0 -filter_hw_device vulkan -vf hwupload,hwupload=derive_device=cuda -map 0:0 -c:v hevc_nvenc -y /tmp/out.mp4
[22:10:13 CET] <Lynne> the p010 nvidia uses has padding in the LSBs, right?
[22:10:27 CET] <JEEB> P010 should be generally spec'd as MS notes
[22:10:41 CET] <Lynne> wait, 12 bits shouldn't work
[22:10:58 CET] <Lynne> vulkan doesn't specify 12 bit components with padding
[22:11:37 CET] <nevcairiel> P010 is defined as exactly P016 with 6 bits zero (ie. so you can treat it like P016 if you want, and the result comes out fine), which means yes, padding is in LSB
[22:12:41 CET] <nevcairiel> nvdec/nvenc also dont specify 12-bit, they use P016 for that
[22:12:48 CET] <Lynne> oh, ok
[22:13:02 CET] <Lynne> maybe its a driver issue then, since the definition matches vulkan
[22:13:19 CET] <Lynne> and 10 bit works on intel (upload+download only, toaster hwdec chip)
[22:13:49 CET] <Lynne> I'm pretty sure upload+download 10bit works on nvidia too last I tested
[22:48:47 CET] <Lynne> philipl: tried p010 upload+download here, it works
[22:58:51 CET] <Lynne> it seems something else is going wrong here
[22:59:21 CET] <Lynne> hwdownload,format=p010 -c:v rawvideo out.nut gives junk
[22:59:38 CET] <Lynne> but hwdownload,format=p010,format=yuv420p10le doesn't
[23:00:16 CET] <Lynne> (libswscale fixed something, lol)
[23:11:37 CET] <cehoyos> nut does not support p010
[00:00:00 CET] --- Mon Oct 28 2019