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

[burek]

[01:47:56 CEST] <atomnuker> jkqxz: can I ignore drm layers and just put each plane in a single layer?
[01:48:15 CEST] <atomnuker> suppose I'm getting dmabufs from something that doesn't have a concept of layers
[05:30:38 CEST] <atomnuker> why do my timestamps get messed up if I encode to matroska with a time base that isn't exactly 1 ms?
[05:30:46 CEST] <atomnuker> I thought rounding timestamps was optional
[06:49:46 CEST] <hanna> atomnuker: I'll follow up on it when I manage to get shaderc compiled again
[06:50:10 CEST] <hanna> which is something I'll be attempting over the course of the next X days
[06:53:50 CEST] <hanna> lol
[06:53:59 CEST] <hanna> apparently in RADV, the storage format you specify in your GLSL shader doesn't matter at all
[06:54:03 CEST] <hanna> RADV just completely ignores it altogether
[07:06:14 CEST] <atomnuker> I always thought it was kinda pointless considering if you wanted to interpret memory differently you'd just bind the same memory to 2 images
[07:07:32 CEST] <hanna> atomnuker: well most typically you'd make a different VkImageView
[07:07:45 CEST] <hanna> but actually aliasing the same memory to different VkImages is not something I've investigated very well
[07:08:00 CEST] <hanna> I think the synchronization issues present there may make it non-trivial to do some things that you can do with VkImageViews more easily
[07:09:12 CEST] <hanna> atomnuker: also the point about storage formats is not so much about being _able_ to reinterpret the image contents
[07:09:25 CEST] <hanna> rather, the fundamental point here is that the shader compiler may be _unable_ to know what the format is
[07:09:33 CEST] <hanna> but it may need to know that during shader compilation stage
[07:20:29 CEST] <atomnuker> I know that memory aliasing on anv works very well on intel, one of the devs there swears by it to the point of doing that instead of other more correct and less hacky ways
[08:30:08 CEST] <hanna> Actually I don't really see any indication in the spec for why using aliased memory would be more difficult than using e.g. an imageview
[08:30:14 CEST] <hanna> both just require regular memory synchronization
[08:30:18 CEST] <hanna> which you need to be doing anyway
[08:30:21 CEST] <hanna> oh actually I think there's one issue
[08:30:31 CEST] <hanna> memory aliasing with images in optimal tiling is undefined?
[08:30:41 CEST] <hanna> so you need to use linear tiling in order to guarantee that the memory layout is actually the same
[08:30:51 CEST] <hanna> you can make a VkImageView of an image in optimal tiling
[08:31:26 CEST] <hanna> Note: Doing that with memory aliasing _would_ work in the same circumstances that using a VkImageView is possible, but it would be undefined behavior
[09:01:53 CEST] <atomnuker> yeah, guy suggesting using memory aliasing was insane enough to suggest using disjoint multiplane images
[09:02:25 CEST] <atomnuker> where the planes are guaranteed to be individually accesible even if tiled
[09:03:36 CEST] <atomnuker> disjoing images are kinda slower on intel though, 43 vs 51 fps for a simple vaapi->vulkan->chromaticaberration filterchain (without download, 4k images)
[11:21:55 CEST] <hanna> tiled vs linear isn't just about multiplan
[11:22:02 CEST] <hanna> it's also about the organization of pixels within the image
[11:22:13 CEST] <hanna> in an optimal image you subdivide the actual image into tiles
[11:22:26 CEST] <hanna> (note that linear images are also interleaved)
[16:15:21 CEST] <kierank> how do I download a patch from the ml
[16:17:54 CEST] <JEEB> I've used patchwork for that generally
[16:18:26 CEST] <JEEB> like `curl -L 'https://patchwork.ffmpeg.org/patch/8980/mbox/' | git am`
[16:18:41 CEST] <JEEB> of course switch the patch ID depending on what you want to poke
[16:19:38 CEST] <kierank> did that
[16:19:40 CEST] <kierank> thanks
[16:21:15 CEST] <JEEB> yw
[16:25:14 CEST] <cone-220> ffmpeg 03Gagandeep Singh 07master:9cefb9e7ec50: lavc/cfhd: interlaced frame decoding added
[17:02:08 CEST] <kierank> I've probably been blocked
[17:02:56 CEST] <JEEB> sounds weird
[17:03:18 CEST] <kierank> happened before
[17:03:28 CEST] <kierank> atlassian sourcetree likes polling git.videolan.org every 10 seconds
[17:03:44 CEST] <JEEB> ah
[17:53:12 CEST] <durandal_1707> kierank: they want encoder, so i dont get why you closed that bug
[17:58:52 CEST] <kierank> durandal_1707: encoder is x86 intrinsics only 
[17:59:22 CEST] <durandal_1707> kierank: lavc encoder....
[18:10:31 CEST] <kierank> That's not what the ticket says, it says integrate GoPro encoder
[18:16:52 CEST] <durandal_1707> kierank: just integrate it for once as said in that ticket and be done
[18:17:19 CEST] <kierank> Won't work on most platforms
[19:16:27 CEST] <jkqxz> Urgh, that took three hours.  I don't think I'll do the rest today.
[19:30:21 CEST] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=fftools/ffmpeg.c;h=5a19a09d9a63ccfcb4967c0eba85d1e47203b531;hb=HEAD#l1101
[19:30:28 CEST] <ubitux> why are we running this code at every frame?
[19:31:25 CEST] <JEEB> ah, the vsync stuff \o/
[19:31:51 CEST] <JEEB> I really like that we have that in addition to the fps filter that you'd think we'd use for frame rate conversions or whatever
[19:31:54 CEST] <ubitux> also, i still havent figured out why x11grab + nut output vomit the "Past duration" warning
[19:32:22 CEST] <JEEB> anyways, it seems like -vsync passthrough -copyts is probably one of the better ways of trying to make sure ffmpeg.c doesn't touch your timestamps (although it still might in some places)
[19:32:28 CEST] <ubitux> typically `ffmpeg -f x11grab -video_size 1920x1080 -framerate 60 -i :0.0 -c:v huffyuv -y /tmp/test.nut`
[19:33:02 CEST] <JEEB> also -debug_ts I think might be useful, albeit spammy
[19:33:55 CEST] <ubitux> -vsync passthrough -copyts just converts to a different warning 
[19:34:03 CEST] <jkqxz> Yeah, I always use -vsync 0 with screen captures to stop it doing anything funny.
[19:35:02 CEST] <jkqxz> There is also some case triggerable with grabbers where it decides that you don't deserve to get any frames at all, which I never tracked down.
[19:47:05 CEST] <gagandeep> kierank: do you have any idea why vlc code is giving my memory leak error for reading subband data from stream
[19:47:31 CEST] <gagandeep> i don't understand why it cant read subband 10 properly
[19:48:13 CEST] <gagandeep> i have allocated memory for subbands worth 2 frames
[19:58:31 CEST] <gagandeep> i think the code is unable to break the vlc look
[19:58:37 CEST] <gagandeep> *loop
[20:15:08 CEST] <cone-372> ffmpeg 03Marton Balint 07master:2b059813127c: avformat/mxf: fix NTSC 59.94 samples per frame layout
[21:20:42 CEST] <cone-372> ffmpeg 03Reino Wijnsma 07master:0263c52f4d4e: configure: fix check for mbedtls
[21:39:27 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:1386a199f9fe: configure: Omit fsanitize flags if they are already specified by the user
[21:39:28 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:df3d962d2e73: libavformat/mxfenc: Add some () to attempt to workaround build issue on osx
[21:42:28 CEST] <atomnuker> jkqxz: wow, thanks, I can see why this took you 3 hours
[21:42:55 CEST] <atomnuker> btw yeah, I had a map_from function for vulkan->vaapi but I removed it (it was even present in an earlier version of the pr)
[21:43:20 CEST] <atomnuker> but I realized it was wrong and I got frustrated trying to fix it
[21:43:48 CEST] <atomnuker> once you export FDs from a vulkan image the ownership is transferred and freeing the original image does nothing, you need to close the fds
[21:44:40 CEST] <atomnuker> I wrote code which destroyed the image and memory and then reimported the fds using the map_to code but it kept crashing
[21:45:59 CEST] <atomnuker> can a frame be mapped multiple times? I think what I might to would be to make some priv array in the avvkframe struct and put exported FDs there, which would get closed when the frame gets freed
[22:00:52 CEST] <jkqxz> Other things close the fds if necessary in the free function from the bufferref.
[22:01:43 CEST] <jkqxz> (And it has to be the source which handles whether to do that - the Rockchip decoder gives you it's internal shared fds, so if you close them it explodes.)
[22:07:29 CEST] <atomnuker> the vulkan spec states that ownership is transferred to the driver once you submit them for importing, so its up to it to close them
[22:11:01 CEST] <jkqxz> That might mean we need to dup() somewhere.
[22:13:25 CEST] <jkqxz> Aha:  <https://0x0.st/s2e5.txt>.
[22:13:30 CEST] <jkqxz> Looks like we do need the dup().
[22:13:40 CEST] <jkqxz> (That would be totally fatal in a multithreaded application.)
[22:23:08 CEST] <atomnuker> jkqxz: the dump would be needed only on rockchip, right?
[22:23:35 CEST] <atomnuker> I didn't know rockchip had vulkan drivers, or in fact any arm device
[22:25:56 CEST] <JEEB> I think some modern ones might have it, I should check if my new adreno 640 has vulkan support
[22:27:01 CEST] <JEEB> "The Adreno 6xx parts have Vulkan 1.0 capabilities similar to the A5xx series..."
[22:27:09 CEST] <JEEB> according to phoronix
[22:30:37 CEST] <jkqxz> No, you need to dup everywhere because of how we've defined the API everywhere else.
[22:30:50 CEST] <jkqxz> (That fds are closed by the source.)
[22:32:11 CEST] <atomnuker> didn't know we defined anything about fds, will do that once I fix the rest of the issues you said
[22:32:13 CEST] <jkqxz> I haven't actually seen Vulkan on Rockchip yet, but in theory it should work since they use recent Mali cores.
[22:51:45 CEST] <cone-372> ffmpeg 03Carl Eugen Hoyos 07master:fbb283cfefb1: lavc/hevcdec: Treat clean random access nals as keyframes for -skip_frame.
[23:19:52 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:e1182fac1afb: avcodec/mpeg4videoenc: Use 64 bit for times in mpeg4_encode_gop_header()
[23:19:53 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:53f241218d9e: avcodec/g723_1dec: Clip bits2 in both directions
[23:19:54 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:62cb6fadf33d: oavcodec/aacpsdsp_template: Use unsigned for hs0X to prevent undefined behavior
[23:19:55 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:90475db97e2e: avcodec/aacdec_fixed: use 64bit to avoid overflow in rounding in apply_dependent_coupling_fixed()
[23:19:56 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:e3f656f2dea6: avcodec/ac3dec: Fix null pointer dereference in ac3_decode_frame()
[23:19:57 CEST] <cone-372> ffmpeg 03Michael Niedermayer 07master:e3275f937dc3: avcodec/ac3dec: Check that the number of channels with dependant streams is valid
[23:25:44 CEST] <atomnuker> jkqxz: "E.g. mapping from VAAPI/NV12 works on Intel, but on AMD I get (with the above plane-count bug fixed):"
[23:26:05 CEST] <atomnuker> how does image creation even succeed when the yuv extension isn't supported on amd yet?
[23:27:03 CEST] <jamrial> rcombs: https://pastebin.com/raw/aG92JV7a tidy up and push your aes-ni patch already :p
[23:28:57 CEST] <atomnuker> last time you had to do that for the flac coverart patches :)
[23:31:00 CEST] <durandal_1707> strange thing i found, filter leaks phanom audio to other frequencies, when using aderivative + filter + aintegral gives big positive dc offset after each speak sequence
[23:33:58 CEST] <jkqxz> Well, it doesn't, since it segfaults inside vkCreateImage().
[23:34:41 CEST] <atomnuker> sounds like a driver bug, it ought to fail if the format isn't supported
[23:35:46 CEST] <atomnuker> durandal_1707: what's the dc amplitude? if its low it might be a rounding issue
[23:38:00 CEST] <durandal_1707> atomnuker: after second speak sequence it goes >1 and disappears from showwaves output, happens with float sample format
[00:00:00 CEST] --- Mon May 28 2018