[01:15:11 CEST] <cone-575> ffmpeg 03Michael Niedermayer 07master:a734ff4b0e7e: libavcodec/ffv1enc: minor cosmetic fix [01:15:11 CEST] <cone-575> ffmpeg 03Michael Niedermayer 07master:540e8c2d641b: avcodec/mjpegdec: Check for end of bitstream in ljpeg_decode_rgb_scan() [01:15:11 CEST] <cone-575> ffmpeg 03Hans Carlson 07master:a790813739a8: ffmpeg: Treat subtitles like audio and video for non-monotonic dts. [01:15:11 CEST] <cone-575> ffmpeg 03Jacob Trimble 07master:b86c5757a2bf: libavutil/encryption_info: Allow multiple init info. [01:21:22 CEST] <atomnuker> Shibe: yeah, I just wrote one [01:22:04 CEST] <atomnuker> https://github.com/swaywm/wlroots/blob/master/examples/dmabuf-capture.c#L295 [01:22:23 CEST] <atomnuker> maps an avframe with a dmabuf to vaapi, then either downloads it or encodes it [02:34:06 CEST] <atomnuker> why the hell does my hw_frames_ctx disappear after I put my frame in a fifo? [02:34:50 CEST] <atomnuker> the pointer to the frame is identical on both ends, its just that it gets zero somehow [02:35:44 CEST] <sploving> hello all, when I fuzzy the latest ffmpeg and have found a vulnerability. where should I report it? [02:37:58 CEST] <sploving> Some develop told me ffmpeg-security@ffmpeg.org will not be used. [02:50:28 CEST] <atomnuker> it will get used, send it there or make an issue on the issue tracker if its not that fatal [02:51:47 CEST] <sploving> thx [03:10:40 CEST] <Compn> i wonder if that was the same guy who just emailed me [03:12:49 CEST] <iive> did you tell him that ffmpeg-security will not be used? [03:12:56 CEST] <Compn> no [12:54:02 CEST] <Mtcno> hello , I want to ask a simple question. There is a line code " int64_t duration = ic->duration + (ic->duration <= INT64_MAX - 5000 ? 5000 : 0); " in the "av_dump_format" function. What did here? I dont understand here. [12:55:41 CEST] <JEEB> that seems like rather arbitrary [12:56:19 CEST] <JEEB> so it has some duration and then adds 5000 (on some time base?) if it is smaller or exactly 5000 less than INT64_MAX [13:03:13 CEST] <Mtcno> thx , After listening to you, I think i understood. [13:04:30 CEST] <JEEB> now without context I have no idea *why* it's doing that [13:42:39 CEST] <akravchenko188> jkqxz: Hello. it is just reminder to check comments in vf_scaler_amf filter thread. Thanks. [15:29:45 CEST] <haasn> /var/tmp/portage/media-video/ffmpeg-9999/work/ffmpeg-9999/tools/cl2c: 27: /var/tmp/portage/media-video/ffmpeg-9999/work/ffmpeg-9999/tools/cl2c: cannot create libavfilter/opencl/tonemap.c: Directory nonexistent [15:29:47 CEST] <haasn> wut [15:32:37 CEST] <JEEB> that sounds like some sort of wrapper around some C preprocessor or compiler [15:32:49 CEST] <JEEB> or wait, is that the opencl compiler? [15:33:49 CEST] <atomnuker> its the tool which converts .cl code to a byte array header [15:33:55 CEST] <JEEB> right [15:46:39 CEST] <haasn> Hmm [15:47:24 CEST] <haasn> I think the error has something to do with building on 32-bit platforms [15:47:43 CEST] <haasn> I tried reproducing it in-tree and I got other errors with the opencl stuff [15:47:49 CEST] <haasn> e.g. /usr/lib/gcc/x86_64-pc-linux-gnu/8.1.0/../../../../x86_64-pc-linux-gnu/bin/ld: i386:x86-64 architecture of input file `libavfilter/opencl/avgblur.o' is incompatible with i386 output [15:48:35 CEST] <haasn> Yeah building for 64-bit only works [15:48:36 CEST] Action: haasn runs multilib [15:50:06 CEST] <haasn> I suggest either making opencl work for 32-bit or disabling building opencl on 32-bit [15:51:11 CEST] <haasn> that said it's probably time for me to disable multilib now that it's the year 2018 :p [21:25:38 CEST] <atomnuker> grr, I hate audio timestamps [21:26:26 CEST] <atomnuker> video, no problem, but audio is pain, they're never right when you want them to be and when they're finally working they're fragile and prone to bugs [21:26:38 CEST] <nevcairiel> but audio timestamps are so easy [21:26:55 CEST] <nevcairiel> at least if you assume your audio has no gaps, because audio with gaps is broken anyway [21:27:59 CEST] <atomnuker> they would be easy if everything operated with proper timestamps and timebases [21:28:30 CEST] <atomnuker> pulseaudio gives you absolutely nothing so you're forced to get the current time, convert it from microseconds tb to 1/samplerate tb [21:28:44 CEST] <January> poettering software tho [21:29:02 CEST] <JEEB> pulse hasn't been under his domain for a long long time [21:29:15 CEST] <JEEB> I've worked together with a PA maintainer and he was not poettering [21:29:15 CEST] <atomnuker> its just misdesigned, it gives no relation to what you get to what the current delay status is [21:29:35 CEST] <atomnuker> and also its not zero-copy, you always need to copy samples [21:29:37 CEST] <January> JEEB: you got jebaited ( a° \– a°) [21:30:32 CEST] <atomnuker> OH I know why my audio timestamps are bad [21:30:37 CEST] <atomnuker> matroska [21:30:43 CEST] <JEEB> extra layer of fun [21:30:55 CEST] <atomnuker> I can't mux anything properly with a timebase with more than 1/1000 precision [21:31:13 CEST] <atomnuker> my video tb is 1/1000 but my audio tb is 1/48000 [21:31:26 CEST] <nevcairiel> clearly your audio frames need to be a more appropriate size [21:32:07 CEST] <atomnuker> welp, the pcm_f32le encoder accepts anything you give it :) [21:33:14 CEST] <atomnuker> they are normal-ish, ~1200 samples, because pulse understands nothing of fixed frame sizes through the incredibly complex async api, while the simple sync api will give you constant frame sizes [21:33:20 CEST] <BradleyS> iirc back in the day fiona was pretty critical of mkv for the relatively inaccurate timebase [21:33:47 CEST] <atomnuker> everyone who's ever worked with it has been incredibly critical of this [21:33:48 CEST] <nevcairiel> you can set the timebase [21:33:50 CEST] <BradleyS> if i need to make mkv and mp4 of something, i usually make mp4 and then remux to mkv due to the 1/1000 being hrm [21:33:56 CEST] <nevcairiel> the problem is of course that there is only one for all your streams [21:34:15 CEST] <BradleyS> .mk2 [21:34:17 CEST] <nevcairiel> but you could use nanosecond precision if thats your cup of tea [21:34:18 CEST] Action: BradleyS runs [21:35:08 CEST] <atomnuker> nevcairiel: no, that was my first idea, just use nanoseconds and call it a day, everything in my program is in nanoseconds [21:35:29 CEST] <atomnuker> but I kept getting invalid timestamps [21:38:10 CEST] <January> just use NUT and have different time base for each stream [21:39:10 CEST] <atomnuker> yeah, NUT was way ahead of its time [21:39:33 CEST] <JEEB> isobmff also has per-stream time bases [21:39:39 CEST] <JEEB> which bases on mov [21:39:42 CEST] <JEEB> which is from the 1990s [22:34:32 CEST] <January> how would you store colour information like range/primaries/colorspace/transfer function in NUT? In frame side data with something like a 'UserDataColourRange', etc? How are other people doing it? [22:37:05 CEST] <JEEB> basically you need something to keep the values specified by ITU-T I'd guess (since they took those values out of H.264/H.265 and made their own spec for them) [22:37:16 CEST] <JEEB> of course it's not perfect because you have to get the data to the decoder [22:37:25 CEST] <JEEB> (in case of raw video it's still kind of a necessity) [22:38:44 CEST] <January> I mean it's not like you'd be doing it any differently with another container (the side data still has to do to the 'decoder'). I guess UserData<whateveritscalledinanothercommonspec> would be a good idea [22:39:54 CEST] <JEEB> as far as I know the thing just goes to the AVCodecContext since we have values for that there, IIRC. exceptions are stuff like HDR metadata which is another separate block of data [22:40:08 CEST] <JEEB> with MaxFALL and MaxCLL [22:40:09 CEST] <JEEB> &34 [00:00:00 CEST] --- Sun Jun 24 2018