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

[burek]

[02:31:53 CEST] <atomnuker> jkqxz: could you test again with my branch?
[12:40:09 CEST] <jdarnley> Dammit!  You were working before.
[12:41:21 CEST] <jdarnley> Why do you fail when I changes another part of the code?
[12:41:43 CEST] <jdarnley> And how do you in avio_close?
[12:41:51 CEST] <jdarnley> *fail in
[12:48:25 CEST] <kierank> gagandeep: can you send me screenshot of mountain frame
[12:48:28 CEST] <gagandeep> kierank: how do i check whether the 2nd frame is working, you have any ideas
[12:48:40 CEST] <kierank> does it look bad?
[12:48:45 CEST] <gagandeep> yeah, sure, didnt see your message
[12:48:58 CEST] <atomnuker> jkqxz: replied to your email with a new patch to fix stuff
[12:49:14 CEST] <atomnuker> and also add vulkan->vaapi mapping support (tested, it works!)
[12:50:12 CEST] <gagandeep> kierank:https://imgur.com/a/zk5iRU1
[12:50:13 CEST] <atomnuker> yep, shader based gpu filtering without any copying is here
[12:50:32 CEST] <kierank> gagandeep: cool, second frame bad I guess?
[12:50:38 CEST] <gagandeep> i can't make it out, as testcfhd is problematic with these samples
[12:50:47 CEST] <gagandeep> i don't know if i am seeing second frame
[12:51:08 CEST] <gagandeep> like some metric built in ffmpeg to check
[12:51:36 CEST] <gagandeep> i allocated an av_frame and referenced it's data pointers to decoded data
[12:52:06 CEST] <gagandeep> then when p frame is required as sample type = 1, i av_frame_ref(pic, my saved frame)
[12:52:31 CEST] <gagandeep> pic is the frame you had defined to store final output
[12:54:06 CEST] <gagandeep> kierank: you see the screens, if you want i can upload video file for mountain
[12:54:18 CEST] <gagandeep> transcoded ofcourse
[12:57:18 CEST] <BtbN> I wonder if the MX150 has nvenc capabilities
[12:57:23 CEST] <BtbN> and nvdec
[13:02:46 CEST] <gagandeep> kierank: ?
[13:03:00 CEST] <kierank> gagandeep: sorry on phone
[13:03:06 CEST] <gagandeep> ok
[13:04:30 CEST] <durandal_1707> kierank is on vacations all the time
[13:06:40 CEST] <kierank> durandal_1707: lies
[13:06:43 CEST] <kierank> gagandeep: ok back
[13:07:00 CEST] <kierank> gagandeep: looks ok, no?
[13:07:09 CEST] <kierank> there is cineform plugin for vlc
[13:07:14 CEST] <kierank> which I used before and it worked
[13:07:24 CEST] <gagandeep> ah, ok, will see with that
[13:08:03 CEST] <gagandeep> i will send the patch and you can then comment on how better the things can be done, right
[13:08:35 CEST] <kierank> ok
[13:09:01 CEST] <gagandeep> k, working on cleaning up the code now
[13:13:35 CEST] <kierank> gagandeep: btw you can get matrix
[13:14:01 CEST] <kierank> seems to be what a lot of people use
[13:14:02 CEST] <durandal_1707> ubitux: why you wrote ebur128 and not itur one? what is different?
[13:14:04 CEST] <kierank> for irc bridging
[13:14:09 CEST] <kierank> durandal_1707: international politics
[13:14:35 CEST] Action: jdarnley is dumb and makes his own obvious bugs.
[13:18:21 CEST] <gagandeep> ok
[13:37:39 CEST] <ubitux> durandal_1707: ebur128 was kinda trending when i wrote it
[13:38:12 CEST] <JEEB> also it seems to work?
[13:39:43 CEST] <nevcairiel> arent both based on the same calculation anyway
[14:08:28 CEST] <durandal_1707> nevcairiel: they are very similar
[15:01:01 CEST] <ubitux> ah you're actually refering to the ITU paper that EBU-R128 is based on?
[15:01:17 CEST] <nevcairiel> personally i dont even know any other
[15:01:34 CEST] <ubitux> yeah well, i used that paper then
[15:01:36 CEST] <nevcairiel> R128 was based on BS.1770, BS.1770-2 backported some changes  R128 made
[15:01:40 CEST] <ubitux> yep, that
[15:01:43 CEST] <nevcairiel> so its really quite similar
[16:00:00 CEST] <nevcairiel> wbs: in case you're interested i reported the last miscompilation i've been seeing https://developercommunity.visualstudio.com/content/problem/264519/miscompilation-of-ffmpeg-rmdecc-module-in-x86-32-b.html
[16:08:20 CEST] <nevcairiel> all the other issues went away with 15.7 already
[16:33:05 CEST] <cone-115> ffmpeg 03John Cox 07master:8d4fc2ea06a7: avfilter: use av_clip_uintp2_c where clip is variable
[21:54:51 CEST] <cone-115> ffmpeg 03Gyan Doshi 07master:04b570817b2b: doc/ffmpeg: remove non-existent vdt option
[22:00:44 CEST] <philipl> BtbN: wouldn't be surprised if one or the other was missing
[22:16:15 CEST] <kierank> durandal_1707: do you know about bayer?
[22:17:41 CEST] <durandal_1707> kierank: yes, he is nice guy, he is my first neighbour
[22:18:04 CEST] <kierank> durandal_1707: on a serious point, would you be able to help gagandeep with bayer
[22:18:10 CEST] <kierank> because I don't know anything about it
[22:19:08 CEST] <durandal_1707> bayer is solo red/blue/green "pixel"?
[22:19:26 CEST] <JEEB> some overlap thing I think?
[22:19:47 CEST] <JEEB> https://en.wikipedia.org/wiki/Bayer_filter
[22:20:41 CEST] <durandal_1707> i know even less, i never played with it, i only have i think some raw image files, i downloaded, which are very big and i think are bayer...
[22:20:54 CEST] <JEEB> but yea, basically mosaic/demosaic
[22:21:09 CEST] <JEEB> (not that I have poked it either, I only read about it on camera firmware forums)
[22:21:35 CEST] <durandal_1707> sws supports what kind of bayer?
[22:21:46 CEST] <kierank> who is bayer expert in ffmpeg?
[22:21:47 CEST] <kierank> carl?
[22:23:53 CEST] <durandal_1707> lol, sws supports lot of bayer, you can look at its code
[22:24:16 CEST] <atomnuker> https://github.com/mpv-player/mpv/blob/master/video/img_format.c#L434
[22:24:21 CEST] <durandal_1707> do you know what kind of bayer is stored in cfhd?
[22:25:13 CEST] <durandal_1707> atomnuker: lol
[22:25:47 CEST] <jkqxz> atomnuker:  Now radv fails a bit later: <https://0x0.st/s20-.txt>.
[22:26:39 CEST] <JEEB> atomnuker: thank you for those short laughs
[22:30:06 CEST] <jkqxz> (Currently waiting patiently for configure on Windows so I can investigate YUV planar formats there further.)
[22:30:09 CEST] <kierank> durandal_1707: dunno
[22:30:23 CEST] <kierank> durandal_1707: but i guess prores raw will have same problem
[22:45:34 CEST] <atomnuker> jkqxz: hmm, seems like its using the host memory extension, hence why alloc mem has an extension
[22:45:48 CEST] <atomnuker> I think if you disable it it should run
[22:46:46 CEST] <atomnuker> to do that, change VK_EXT_EXTERNAL_MEMORY_HOST_EXTENSION_NAME to some string like "blah"
[22:52:54 CEST] <atomnuker> I'll get an AMD card as soon as they release a new one, which will be after I move in a few months
[22:53:17 CEST] <durandal_1707> atomnuker: where you gonna move?
[22:53:38 CEST] <jkqxz> Right, that seems to work (output looks ok).
[22:53:54 CEST] <jkqxz> Segfaults on close, though:  <https://0x0.st/s20A.txt>.
[23:04:11 CEST] <atomnuker> fixed, missing NULL check in the lavfi common deinit code
[23:04:42 CEST] <atomnuker> (pushed to my github)
[23:05:50 CEST] <atomnuker> could you try to run avgblur_vulkan on AMD?
[23:08:44 CEST] <jkqxz> Looks pretty blurry to me.  (And painfully slow because of the YUV->RGB, upload, blur, download, RGB->YUV.)
[23:09:43 CEST] <jkqxz> Oh, the bottom edge of a 1080p video is broken.
[23:18:40 CEST] <atomnuker> jkqxz: try https://pars.ee/temp/fix_exporting.diff, it should fix the host mapped extensioin
[23:18:46 CEST] <atomnuker> *extension
[23:24:02 CEST] <jkqxz> Same stacktrace as above.
[23:32:15 CEST] <jkqxz> Intel/Windows on Skylake really doesn't have the planar YUV formats.
[23:33:33 CEST] <atomnuker> https://vulkan.gpuinfo.org/ lists all of them as supporting it
[23:33:52 CEST] <jkqxz> There are so many version numbers in this driver.  I'm currently using the most recent released one from the Intel website, which is probably called either 15.45.23.4860 or maybe 21.20.16.4860.
[23:35:42 CEST] <jkqxz> The other Windows machine I can easily check is a Haswell, so not useful because Intel decided that Windows users can't have Vulkan there.
[23:37:16 CEST] <jkqxz> The version numbers on that website do not match either of the ones I gave above.  Let me see if I can find a 0.xxx.yyyy version number somewhere...
[23:44:24 CEST] <jkqxz> Can't find anything.  Is there a driver version string available in the API that I could print somewhere?
[23:52:54 CEST] <jamrial> jkqxz: vkGetPhysicalDeviceProperties() maybe? for VkPhysicalDeviceProperties->driverVersion
[00:00:00 CEST] --- Fri Jun  1 2018