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

[burek]

[00:22:57 CET] <ramiro> I'm capturing from a live source, but I want to discard all frames unless I receive a trigger command (probably from an arduino connected to serial). I'm thinking about writing a simple filter that listens on the serial, drops frames while the trigger is not set, and keeps track of the pts offset that must be used to compensate for the dropped frames.
[00:23:03 CET] <ramiro> does anyone have a simpler idea?
[00:59:31 CET] <atomnuker> won't work if your input is variable fps (as most webcams are)
[01:00:38 CET] <atomnuker> also use the API, its what its there for, don't extend ffmpeg.c
[01:18:48 CET] <cone-097> ffmpeg 03Pan Bian 07master:5b4baf150627: libavformat/rtpenc_mpegts: check avformat_new_stream() return value
[01:18:49 CET] <cone-097> ffmpeg 03Pan Bian 07master:2ba6d7cb8278: ffmpeg: Check read_ffserver_streams() return value
[01:22:22 CET] <ramiro> atomnuker: why would it not work with variable fps? I save the pts from the first dropped frame, then use it to calculate the delta to the first non-dropped frame, and subtract that delta for the accepted frames.
[01:25:31 CET] <atomnuker> ah, yeah, that's okay then, I thought you were just going to take 1/fps an use that
[02:38:56 CET] <atomnuker> michaelni: does adding a space like "static _Atomic(AVCodecParser *)av_first_parser = NULL;" help?
[02:41:05 CET] <jamrial> why the brackets?
[02:41:26 CET] <atomnuker> wouldn't compile here otherwise
[02:42:32 CET] <jamrial> _Atomic is a type qualifier, that should be "static _Atomic AVCodecParser *av_first_parser" i think
[02:45:11 CET] <atomnuker> 01:48 <@atomnuker> any ideas why "static _Atomic AVCodecParser *av_first_parser = NULL;" isn't accepted as input to atomic_load()?
[02:45:13 CET] <atomnuker> 01:48 <@atomnuker> "error: address argument to atomic operation must be a pointer to _Atomic type ('_Atomic(AVCodecParser) ***' invalid)"
[02:45:15 CET] <atomnuker> 01:49 <SortaCore> no brackets and where the * is
[02:45:17 CET] <atomnuker> 01:51 <@atomnuker> that worked, tnx
[02:49:44 CET] <jkqxz> jamrial:  No, that would be a pointer to an _Atomic AVCodecParser.  You want AVCodecParser *_Atomic.
[02:50:35 CET] <jkqxz> Though I'm not sure that this approach is sane.  Can't we just replace the "clever" use of atomics with a mutex and be done with it?  There are no performance implications.
[02:51:14 CET] <jamrial> anything that gets rid of all the lavu atomic stuff
[02:52:30 CET] <atomnuker> jkqxz: no, I like clever atomics and dislike mutexes
[02:53:15 CET] <jkqxz> (Or delete the registration mechanism entirely and just have a big array.)
[02:53:50 CET] <iive> i thought that libav already did that and we had merged it
[02:53:51 CET] <atomnuker> maybe once we get rid of atomics
[02:54:26 CET] <iive> are you really going through all this trouble just for the register_all() ?
[02:54:47 CET] <atomnuker> no, we're going through all this trouble to remove avpriv_atomics
[02:55:10 CET] <jamrial> OMFG, someone overloaded ret in avformat_write_header() and it's never returning an error if header writing fails
[02:55:27 CET] <iive> how is adding atomics remove them?
[02:56:22 CET] <jamrial> iive: replacing lavu wrappers with c11
[02:56:27 CET] <jamrial> or removing them, both are fine
[02:57:18 CET] <iive> so instead of wrappers you are hardcoding c11 atomics?
[02:57:50 CET] <iive> aka, c11 support is now mandatory
[02:58:25 CET] <jamrial> no
[02:59:19 CET] <iive> go on...
[03:00:06 CET] <jamrial> there's an old internal lavu atomic api that's a wrapper for different kind of atomic functions depending on compiler/os. it's ugly and uses internal avpriv symbols
[03:01:36 CET] <jamrial> some time ago a new set of wrappers was added that emulates c11 style atomics, without avpriv symbols in an specific library
[03:02:14 CET] <jamrial> compilers that support c11 use their builtin support. those that don't, use said c11 wrappers in the compat folder
[03:03:54 CET] <jamrial> most uses of the old lavu api were ported. some haven't, and we're trying to deal with them so we can effectively nuke the old api now that we still can remove apriv symbols
[03:04:55 CET] <iive> the avpriv seems to be used in the case when there is no atomics support and they are emulated by explicity mutex
[03:05:03 CET] <iive> how the new code handles that case?
[03:07:08 CET] <jamrial> the same way
[03:08:02 CET] <iive> how do you get rid of avpriv then?
[03:08:10 CET] <atomnuker> iive: if c11 atomics aren't supported an stdatomic.h file is used instead which emulates them
[03:08:17 CET] <atomnuker> using whatever atomics are available
[03:10:01 CET] <jamrial> oh, i see what you mean
[03:12:00 CET] <jamrial> these also have two avpriv symbols. technically it's the same scenario with pthreads based emulation, yeah
[03:16:22 CET] <atomnuker> jamrial: which ones have avpriv_symbols?
[03:16:29 CET] <iive> yeh
[03:18:24 CET] <iive> cu, n8 ppl
[03:18:42 CET] <jamrial> atomnuker: the pthreads emulation
[03:19:28 CET] <atomnuker> what is it used for?
[03:20:00 CET] <jamrial> the mutexes
[03:22:30 CET] <atomnuker> ah, right
[03:25:31 CET] <cone-097> ffmpeg 03James Almer 07master:9924f1bc3424: avformat/matroskaenc: move some initialization checks to mkv_init
[05:25:07 CET] <cone-097> ffmpeg 03James Almer 07master:5f67073b4cb1: avformat/matroskaenc: add missing allocation failure checks for stream durations
[07:24:26 CET] <cone-097> ffmpeg 03Rodger Combs 07master:1204ce0b6371: lavu/hwcontext_opencl.h: fix build on macOS
[11:48:31 CET] <cone-097> ffmpeg 03Anssi Hannula 07master:1dff9adcb934: avformat/hls: Factor playlist need check to a common function
[11:48:32 CET] <cone-097> ffmpeg 03Anssi Hannula 07master:143552095dae: avformat/hls: Obey AVProgram discard flags
[13:04:27 CET] <cone-097> ffmpeg 03Karthick J 07master:d5d2632e3a0f: avformat/hlsenc: Fixed initial setting for end_pts
[14:01:21 CET] <atomnuker> jdarnley: why the hell did you release your vf_removegrain simd under the gpl?
[14:01:43 CET] <jdarnley> I think because it was based on the original which is gpl
[14:02:03 CET] <atomnuker> ah, ok
[14:02:13 CET] <jdarnley> Also why should I not use the GPL for stuff I do on my own time.
[14:02:50 CET] <jdarnley> Isn't the filter itself gpl?
[14:03:59 CET] <jdarnley> Aparently not.
[14:05:33 CET] <jdarnley> I hope durandal_1707 didn't look at the original source when writing it.
[15:01:14 CET] <durandal_1707> jdarnley: the implementation of removegrain in vs is lgpl
[15:01:39 CET] <durandal_1707> ot better than that
[15:02:41 CET] <atomnuker> jdarnley: I think the only reason to gpl some code in ffmpeg is if you're writing an encoder
[15:03:26 CET] <atomnuker> otherwise for general purpose filtering/muxing and decoding having gpl code just encourages people to mislicense when they compile because they need to
[16:38:58 CET] <jdarnley> I have another question related to the palignr one I asked yesterday.
[16:39:02 CET] <jdarnley> https://pastebin.com/mhcR8knE
[16:39:22 CET] <jdarnley> Can I do that operation in ymm registers?
[16:39:56 CET] <jdarnley> I'm guessing not because I need to move stuff over the lanes
[16:40:39 CET] <jdarnley> palignr did work very well when I got the order correct so thank you for that.
[16:41:45 CET] <jdarnley> Perhaps I should change the code below so I don't need to split like that.
[17:04:25 CET] <jdarnley> Gramner, jamrial, atomnuker, durandal_1707, iive: do you have any suggestions on the above?
[17:06:40 CET] <iive> jdarnley: usually ymm operationsa are like two separate xmm operations
[17:11:32 CET] <jdarnley> I know.  I usually write my avx2 code like I'm unrolling the loop and stick the next loop on to the high end of the registers.
[17:14:15 CET] <iive> the #else case looks fishy
[17:14:37 CET] <iive> e.g. m0 is changed, but not used (in this scope)
[17:27:33 CET] <jdarnley> Yeah, that has limited context
[17:27:50 CET] <jdarnley> m0 is used
[17:28:59 CET] <iive> what is the code supposed to do, unpack 12 bytes into 16 (and pad with zero) ?
[17:31:02 CET] <iive> float rgb -> float rgba ?
[17:31:10 CET] <jdarnley> no
[17:31:18 CET] <jdarnley> It is effectively the weld between two other pieces of code.  The whole function is supposed to turn one bitpacked format into another.
[17:31:41 CET] <jdarnley> It turns out the original was wrong plus it needs to clip word values to a given range.
[17:32:13 CET] <jdarnley> So I have now taken two similar functions and welded them together witht hat palignr
[17:51:18 CET] <cone-097> ffmpeg 03Aman Gupta 07master:b5d56d8ef1ef: avcodec/videotoolbox: fix SEGV when hwaccel decoding h264 with ffmpeg.c
[19:03:12 CET] <SortaCore> so uh, how do you tell if a HWAAccel frame is allocated on GPU or RAM?
[19:04:30 CET] <BtbN> You look at the pix_fmt.
[19:05:14 CET] <SortaCore> swscaler won't let me convert from QSV to anything tho
[19:05:48 CET] <BtbN> sounds correct, it's a sw scaler after all
[19:06:13 CET] <BtbN> you want to hwdownload the frame
[19:13:25 CET] <SortaCore> av_hwframe_transfer_data right?
[20:52:43 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:755207dc53d6: prores: Always assume limited range
[20:52:44 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:10db42f117ed: mov: Support mdcv and clli boxes for mastering display an color light level
[20:52:45 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:3e0560b054dd: vf_zscale: Relax color properties maximum bounds
[20:52:46 CET] <cone-097> ffmpeg 03Vittorio Giovara 07master:002db7d49ada: vf_zscale: Add more supported input properties
[21:02:02 CET] <Gramner> jdarnley: somewhat awkward permutations in avx2. 2x vpermd + 3x vpblendd should work, but it's kinda slow. in avx512 you can at least do it with 2x two-table permutations
[21:07:57 CET] <jdarnley> Gramner: thanks
[21:16:54 CET] <SortaCore> hmm, right now the convert from YUV420P to NV12 (for hwaaccel) is using the most CPU
[21:17:07 CET] <SortaCore> aren't they basically the same format but with U/V flipped?
[21:20:07 CET] <JEEB> no, NV12 has chroma packed
[21:20:13 CET] <JEEB> while luma is a separate plane
[21:44:37 CET] <cone-097> ffmpeg 03Gyan Doshi 07master:b3cb9bd43fa3: avfilter/drawbox: rename variable for maximum thickness
[21:44:38 CET] <cone-097> ffmpeg 03Dale Curtis 07master:96e340760824: Free extradata before reallocating.
[21:44:39 CET] <cone-097> ffmpeg 03Pan Bian 07master:89f9332fdf89: avcodec: set correct return value in ff_mpeg_ref_picture
[21:44:40 CET] <cone-097> ffmpeg 03Mark Reid 07master:62f7f40caa70: avformat/mxfenc: pass MXFPackage around instead of type
[21:44:41 CET] <cone-097> ffmpeg 03Pan Bian 07master:3f81259f337b: avformat/mov: set correct error code in mov_read_custom
[21:44:42 CET] <cone-097> ffmpeg 03Pan Bian 07master:f63450c8e4c9: avformat/mov: return correct value in mov_read_cmov
[22:58:11 CET] <kierank> how has this guy managed to send an email in december
[23:04:11 CET] <BtbN> Intel employees must have their clock 3 days in advance, so they don't miss deadlines
[23:16:59 CET] <cone-097> ffmpeg 03Mark Thompson 07master:c5f3e85792d5: Changelog: add VAAPI VP8 decoder
[23:17:00 CET] <cone-097> ffmpeg 03Jun Zhao 07master:23db3a1ae6d1: examples: Add a VA-API encode example.
[23:17:01 CET] <cone-097> ffmpeg 03Mikhail Mironov 07master:9ea6607d2945: Add HW H.264 and HEVC encoding for AMD GPUs based on AMF SDK
[00:00:00 CET] --- Wed Nov 29 2017