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

[burek]

[00:44:04 CET] <thardin> woop, FATE is happy
[00:47:19 CET] <atomnuker> jkqxz: is there something I need to do to the DRM fd in AVDRMDeviceContext? its a valid, open fd from what I can tell but all ioctl calls defined in libdrm fail
[00:47:39 CET] <atomnuker> (-1, I've got no idea what's that translated)
[00:50:42 CET] <jkqxz> Look at errno?
[00:50:52 CET] <jkqxz> (All DRM calls set it.)
[00:51:32 CET] <jkqxz> Though no, if it's valid it should work.
[00:53:05 CET] <atomnuker> "Unknown error -1" <- helpful
[00:54:44 CET] <jkqxz> strace output for your call?
[00:59:18 CET] <DHE> libc's system call wrappers just return -1 and set errno on errors
[00:59:48 CET] <atomnuker> "ioctl(3, DRM_IOCTL_AGP_INFO, 0x7ffc894e6a90) = -1 EINVAL (Invalid argument)", weird, I do exactly what libdrm does here: http://libdrm.sourcearchive.com/documentation/2.4.23/xf86drm_8c_source.html#l01844
[01:01:55 CET] <kierank> atomnuker: remember having this problem with ethtool
[01:02:18 CET] <jkqxz> Seems likely that fd isn't isn't actually a DRM fd.
[01:03:46 CET] <jkqxz> "echo 0xff >/sys/modules/drm/paramters/debug" gives you everything to the kernel log and will tell you why it failed (do it on a headless machine not running anything else, though, because it makes like 9001 lines of output for every page flip).
[01:03:49 CET] <atomnuker> yeah, I too thought that fd #3 is suspiciously low though it makes sense if its one of the very first ones to get opened
[01:04:14 CET] <jkqxz> Or you could just read the source to find out why DRM_IOCTL_AGP_INFO can return EINVAL.
[01:05:56 CET] <jkqxz> Maybe your device doesn't have agp or it is not acquired.  <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/drm_agpsupport.c#n57>
[01:07:34 CET] <cone-547> ffmpeg 03Xiaohan Wang 07master:71f39de2a57e: avcodec/h264_cavlc: Set valid qscale value in ff_h264_decode_mb_cavlc()
[01:07:37 CET] <jkqxz> (Whatever that means.)
[01:08:50 CET] <jkqxz> You could call drm_ioctl_agp_acquire before it, perhaps.
[01:14:47 CET] <atomnuker> yeah, seems like it, DRM_IOCTL_UNIQUE returns 0
[01:14:58 CET] <atomnuker> can't aquire agp, permission denied
[01:15:14 CET] <cone-547> ffmpeg 03Carl Eugen Hoyos 07master:dc77e64f2d41: lavf/rtpdec*: Constify all RTPDynamicProtocolHandler.
[01:15:26 CET] <atomnuker> do you happen to know any way of getting a pci device ID from a drm fd in some way?
[01:16:05 CET] <atomnuker> or maybe make hwcontext_drm put it in its public struct with the fd
[01:20:00 CET] <jkqxz> drmGetDevice().
[01:20:35 CET] <jkqxz> It's in drmDevice.deviceinfo.pci.
[01:23:08 CET] <atomnuker> I don't seem to have drmGetDevice in my libdrm
[01:24:51 CET] <atomnuker> oh wow its in xf86drm.h
[01:33:32 CET] <jkqxz> Such a silly name for it to have nowadays - hysterical raisins.
[01:38:03 CET] <atomnuker> works! https://pars.ee/temp/drm_vulkan_interop.mkv
[01:56:55 CET] <jamrial> good, now it needs to be fast :p
[01:57:19 CET] <jamrial> 20fps doesn't cut it for 60fps video
[02:00:16 CET] <atomnuker> yep, once I finish implementing the host mapped vulkan access it should be faster
[02:00:59 CET] <atomnuker> though I already have all I needed it for - access to the unmodified data
[02:01:27 CET] <atomnuker> since mapping it to vaapi will also convert it to nv12/yuv420p and the chroma's broken so everything looks blurry
[02:02:36 CET] <atomnuker> yep I totally did all this work to make a screenshot tool because kde 5.10's screenshooter was broken on wayland :)
[10:26:24 CET] <ldts> lrusak: do you plan to submit again the AVDRMFrameDescriptor changes for v4l2_m2m2 you posted a few weeks ago? 
[12:00:23 CET] <thardin> new release? don't see a website update
[14:26:50 CET] <JEEB> oh
[14:26:59 CET] <JEEB> was wondering why -show_frames only had pkt_pts|dts
[14:27:03 CET] <JEEB> buut
[14:27:05 CET] <JEEB> > print_ts  ("pkt_pts",               frame->pts);
[14:27:34 CET] <JEEB> so it was the AVFrame's pts, not the PTS of the packet it came from
[14:27:40 CET] <JEEB> on the other hand DTS is the pkt_dts
[14:27:51 CET] <JEEB> *pkt_dts is the actual pkt_dts
[14:54:06 CET] <nevcairiel> decoders dont produce a value for frame->pts
[14:54:14 CET] <nevcairiel> thats why it gets filled with pkt_pts these days
[14:59:16 CET] <JEEB> well pkt_pts isn't necessarily correct with b-frames etc, tho?
[14:59:40 CET] <nevcairiel> pkt pts is correct, otherwise its not pts
[15:00:25 CET] <JEEB> I seem to recall that with MPEG-TS for example the reordering and thus setting of correct PTS is left to the decoder with various formats. leading to remuxes dropping packets in the muxer etc
[15:00:34 CET] <JEEB> but I should look into that more :/
[15:00:48 CET] <nevcairiel> of course its left to the decoder
[15:00:56 CET] <nevcairiel> pts should be out of orderwhen it comes out of a demuxer
[15:01:01 CET] <nevcairiel> because frames are out of order
[15:01:26 CET] <JEEB> well yes. ok, I'm probably not making too much sense since my head is full of goo right now
[15:01:31 CET] <JEEB> might have been DTS then
[15:01:57 CET] <JEEB> just remember that remux MPEG-TS -> MPEG-TS could derp things up, while MPEG-TS->decode->encode->MPEG-TS would give nice timestamps
[15:02:36 CET] <JEEB> also will have to check if I actually have samples for this
[15:02:44 CET] <JEEB> so I could look more into the root cause
[16:25:13 CET] <lrusak> ldts: haven't really had time to work on it much
[18:13:50 CET] <cone-775> ffmpeg 03Niklas Haas 07master:7c82e0f61e36: avfilter/af_loudnorm: correctly initialize PTS
[21:47:37 CET] <kierank> omg carl
[22:09:23 CET] <wm4> did he read that post
[23:05:03 CET] <thardin> woo last mpeg-2 patent expired
[23:05:09 CET] <JEEB> oh wow
[23:05:47 CET] <BtbN> how long until h264 becomes free?
[23:06:12 CET] <thardin> party like it's 1996
[23:06:51 CET] <rcombs> AAC-LC is expiring in the US (but not elsewhere) next(?) month
[23:07:00 CET] <rcombs> (well, some other places, maybe, but not everywhere)
[23:07:12 CET] <rcombs> (MPEG-2 LC has been expired for ages but >MPEG-2 LC)
[23:07:17 CET] <thardin> 🥂
[23:07:50 CET] <JEEB> :D
[23:11:02 CET] <thardin> 🎉 works better
[23:11:19 CET] <thardin> petition to enclude at least on emoji in the next release name
[23:11:28 CET] <nevcairiel> denied
[23:11:47 CET] <thardin> 😔
[23:14:22 CET] <atomnuker> rcombs: a subset of aac anyway, pns is mpeg4
[23:14:43 CET] <rcombs> atomnuker: that's expiring in the US
[23:15:59 CET] <atomnuker> mpeg4?
[23:16:48 CET] <rcombs> yeah
[23:17:46 CET] <atomnuker> isn't that like 2000-something recent?
[23:45:21 CET] <wm4> BBB: which side data types would you want to be possible to appear multiple times?
[23:49:02 CET] <rcombs> >MPEG-4 AAC LC patents remain active at least through May 2023. Note, however that after March 3, 2018 the MPEG-4 AAC LC patent country coverage will be as follows: Australia, Canada, China, Hong Kong, India, Japan, Indonesia, Israel, Korea, Malaysia, Mexico, Poland, Singapore and Taiwan, and the following EP national states (AT, BE, CH, CZ, DE, DK, ES, FI, FR, GB, HU, IT, LI, NL, RO, SE, TR).
[23:50:56 CET] <BBB> I dont know
[23:51:11 CET] <JEEB> I think I saw someone's fork for that
[23:51:18 CET] <JEEB> it might have had something to do with caption packets
[23:52:00 CET] <nevcairiel> arent our apis designed around like "get side data of type X", which implies only one?
[23:52:40 CET] <BBB> I believe Ive used side-data for things like attaching slice headers to the image
[23:52:45 CET] <BBB> and one image can have multiple slices
[23:53:35 CET] <wm4> nevcairiel: yes, unless you loop over them manually, lol
[23:53:49 CET] <wm4> BBB: I'd argue then the side data type itself should support multiple items
[23:54:10 CET] <JEEB> I am trying to google whatever I was linked to
[23:54:23 CET] <JEEB> which had an iterative thing for each side data type
[23:54:30 CET] <peloverde> It's worth noting that by default just about everyone muxes MPEG-2 AAC mpeg-4 style in MP4, which uses a bunch of stupid mpeg-4 descriptors.
[23:55:03 CET] <jamrial> wm4, BBB: http://ffmpeg.org/pipermail/ffmpeg-devel-irc/2017-August/004459.html
[23:55:17 CET] <BBB> wm4: we can argue day and night about thigns like that
[23:55:18 CET] <jamrial> this was the dicussion where you asked me to keep the current behavior
[23:55:21 CET] <BBB> this is how I used it :)
[23:56:05 CET] <wm4> blergh
[23:56:35 CET] <wm4> I feel like allowing a single type multiple times makes everything much more complicated
[23:56:51 CET] <BBB> sorry, Im trying to be pragmatic, nobody cares if my encoder conforms to K&R, lots of people care if its 20% bdrate reduction compared to some important reference implementation
[23:57:09 CET] <BBB> likewise, noody cares how many side data elements of type x but not y are allowed
[23:57:22 CET] <BBB> people care if a stream analyzer works (yes) [] (no)
[23:57:52 CET] <wm4> the problems start when stuff begins to behave weird for certain files because there are multiple of one type and the code expects only 1, resulting in a giant hairball mess
[23:58:05 CET] <BBB> I dont see how its fundamentally against heaven and earth etc. to allow something relatively trivial like this that might actually help some people
[23:58:09 CET] <BBB> I just dont get it
[23:58:27 CET] <BBB> why take such a binary approach if users might sometimes use it *just because*?
[23:58:32 CET] <BBB> I dont get it
[23:58:50 CET] <JEEB> I think the thing this one guy did was that it let you have a single entry for a type, but that type then was iterable or something
[23:58:52 CET] <BBB> give users approaches that theyre happy with, that they expect
[23:59:00 CET] <BBB> thats fine also
[23:59:10 CET] <wm4> that results in the APIs we currently have
[23:59:13 CET] <wm4> well whatever
[23:59:22 CET] <BBB> you can do both, or either, but make it work, make it beautiful
[23:59:28 CET] <BBB> and make it simple
[23:59:37 CET] <BBB> Im giving you a use ase
[23:59:42 CET] <JEEB> also meh, I think I'll have to grep my IRC logs
[23:59:42 CET] <BBB> run with it, make it beautiful!
[23:59:49 CET] <JEEB> can't find the code
[23:59:52 CET] <BBB> :)
[00:00:00 CET] --- Thu Feb 15 2018