[01:13:52 CEST] <bofh_> atomnuker: pong [02:13:58 CEST] <kierank> JEEB: did you fix your h264 bug? [07:59:00 CEST] <JEEB> kierank: not yet [11:54:40 CEST] <January> Is there a special way to bisect ffmpeg? [11:56:08 CEST] <nevcairiel> use the bisect script in the tools folder [11:56:18 CEST] <thardin> you mean other than git bisect run make fate? [11:58:52 CEST] <January> thardin: doing that I end up at some nonsensical commits [11:59:06 CEST] <January> nevcairiel: thanks, will give it a shot [12:03:55 CEST] <thardin> seems that just does git bisect run but checks that ffmpeg.c etc exists? [12:06:11 CEST] <funman> yes rather than avconv.c [12:06:51 CEST] <nevcairiel> yeah it ensures to stay on the right side of the merges [12:07:34 CEST] <thardin> aha [12:18:51 CEST] <J_Darnley> Since we are all jumping on to that bug... [12:18:58 CEST] <J_Darnley> Is there a known good commit? [12:20:27 CEST] <J_Darnley> kierank, January? [12:21:01 CEST] <kierank> No [12:21:14 CEST] <January> I just went back 'far' [12:21:15 CEST] <kierank> HEAD~1500 or so iirc works [12:21:22 CEST] <J_Darnley> okay [12:23:57 CEST] <cone-013> ffmpeg 03Paul B Mahol 07master:3cbf37bf098a: avfilter/af_silenceremove: fix max for duration options [13:01:24 CEST] <J_Darnley> This bisect tool is a POS! It looks like it is skipping every commit. [13:05:05 CEST] <J_Darnley> And now it looks like it deleted the entire tree. [13:06:56 CEST] <J_Darnley> Is that because some genius decided to move ffmpeg.c to fftools/? [13:17:36 CEST] <durandal_1707> yes [13:17:40 CEST] <JEEB> yea, it was moved at one point [13:22:55 CEST] <akravchenko188> jkqxz: hi, it is reminder. hwcontext_amf and vf_scale_amf is pending to integrate for a long time. is there any reason? could I fix something or provide some help? [13:27:16 CEST] <J_Darnley> "cf57cb3ae4364ab8e70af37beea7a45a86de90e9 is the first bad commit" [13:27:23 CEST] <J_Darnley> "h264: add AVOption to set x264_build default" [13:27:30 CEST] <J_Darnley> great [13:38:31 CEST] <cone-013> ffmpeg 03Paul B Mahol 07master:e10fe34e7c60: avfilter/f_reverse: add packed sample format support to areverse [18:45:34 CEST] <drbuck> I am working on a toy dash live streaming setup. For debugging, I would like to have pts, dts based on wallclock. output_ts_offset in mux.c seems like a good fit, but it is not supported in movenc.c. I'm not an expert on isobmff/cmaf, does output_ts_offset plausibly make sense to support? [18:48:47 CEST] <JEEB> I think nonzero PTS should work if you just note that it's a thing that starts with a discontinuity [18:48:50 CEST] <JEEB> IIRC [18:49:04 CEST] <JEEB> also there's another flag that tells the muxer to not draw your PTS/DTS to zero in the muxer either [18:50:47 CEST] <JEEB> some value of avoid_negative_ts IIRC [18:53:55 CEST] <drbuck> @JEEB: looking into it, thx! [20:34:21 CEST] <llogan> What is the answer to this question? "Is this gcc inlining problem still relevant for FFmpeg"? https://twitter.com/Art1Pirat/status/1049357199343071232 [20:34:47 CEST] <llogan> He then links to https://nadav.amit.zone/blog/linux-inline [21:58:18 CEST] <tmm1> "Decomposition unimplemented for unit 4 (type 10)" what is this in h264? [21:59:12 CEST] <tmm1> ah "Coded slice data partition C" [21:59:25 CEST] <tmm1> err no, that's type 4 not type 10. type 10 is "End of sequence" [22:43:01 CEST] <BtbN> philipl, so the latest nvidia driver fixes the mapping weirdnes? [22:50:34 CEST] <philipl> BtbN: an unreleased future driver will. [22:51:51 CEST] <nevcairiel> probably one that officially claims support for a future nvdec revision that actually has those output formats listed =p [22:52:09 CEST] <philipl> This is the vulkan interop bug. Different. [22:52:20 CEST] <philipl> They claim that works in the current driver releases, except it doesn't work for VkImages. [22:52:33 CEST] <nevcairiel> oh that [22:54:03 CEST] <BtbN> oh right, Windows has different numbers [23:02:14 CEST] <durandal_1707> forget about multimedia [23:03:32 CEST] <durandal_1707> it is full of crap [00:00:00 CEST] --- Tue Oct 9 2018