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

[burek]

[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 at 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