[01:27:02 CEST] <cone-200> ffmpeg 03Andreas Cadhalpun 07master:faf9fe2c224e: alsdec: validate time diff index [02:38:42 CEST] <cone-200> ffmpeg 03Lou Logan 07master:d1a892209803: cmdutils: indent protocols listing [03:19:55 CEST] <cone-200> ffmpeg 03James Almer 07master:a40cee03a3be: avutil: remove pointless bmi1 define [04:33:45 CEST] <cone-200> ffmpeg 03Andreas Cadhalpun 07release/2.5:96c1421627aa: alsdec: ensure channel reordering is reversible [04:33:46 CEST] <cone-200> ffmpeg 03Michael Niedermayer 07release/2.5:5be683d687b6: avcodec/alsdec: Use av_mallocz_array() for chan_data to ensure the arrays never contain random data [04:33:47 CEST] <cone-200> ffmpeg 03Andreas Cadhalpun 07release/2.5:faac8e43315d: alsdec: validate time diff index [08:51:48 CEST] <jamrial> rcombs: wanna be among the first to know when the ticket reaches 400? :p [08:55:14 CEST] <rcombs> jamrial: that or when something actually happens [10:37:02 CEST] <enigma> is this the right channel if i have trouble using libav ? or is this strictly for ffmpeg development itself [10:38:04 CEST] <enigma> I am having trouble muxing H264 bitstream and ADTS AAC streams together into FLV. If i pack H264 bitstream (source is hardware encoder) into FLV , it plays fine with proper duration and bitrate. But when I mux audio along , the bitrate and duration go all wrong and on the playback, I only hear the audio. The video gets stuck on first frame. here is my muxing code : http://pastebin.com/C6bYqtsA [10:38:56 CEST] <enigma> ok sorry, just read the description. i [10:39:03 CEST] <enigma> li'll stick to #ffmpeg [12:57:57 CEST] <cone-149> ffmpeg 03James Almer 07n2.5.6:HEAD: avutil: remove pointless bmi1 define [13:36:25 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:3668701f9600: avformat/http: Return an error in case of prematurely ending data [14:49:36 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:22c0585a00d4: avformat/http: Fix 2 typos [15:41:32 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:9a0f60a0f89a: avcodec/mpeg4videodec: Use check_marker() [16:45:18 CEST] <cone-149> ffmpeg 03Thomas Guillem 07release/2.4:3e1c9da38b84: matroskadec: fix crash when parsing invalid mkv [16:45:19 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07release/2.4:0b71cedfe844: Merge commit '3e1c9da38b849ce2982b516004370081fdd89ed0' into release/2.4 [17:00:54 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:0cab0931dcf2: avformat/matroskadec: remove now duplicate doctype check [17:02:29 CEST] <BtbN> It's quite hard to find documentation on chroma keying. No idea if i'm missing something extremely obvious about it, or if all algorithms are proprietary and hidden. [17:06:57 CEST] <iive> what is chroma keying? [17:14:42 CEST] <ubitux> wm4: i don't remember what test i asked for... [17:15:20 CEST] <ubitux> wm4: about the mpv/gif (wtf are your users doing), you can trim with... trim filter in the filtergraph, i suppose [17:15:52 CEST] <ubitux> (it will send an EOF when it reaches the end bound) [17:16:28 CEST] <ubitux> for the starting point, you can use it but it will unfortunately not "seek" (just drop frames until it reaches the timestamp) [17:17:06 CEST] <ubitux> for the --start we indeed have a -ss for input, and one for output [17:17:13 CEST] <ubitux> so unless you have something equivalent.. [17:18:32 CEST] <wm4> nothing like this was ever necessary (until now= [17:18:44 CEST] <wm4> and that user is developing a mpv frontend [17:18:58 CEST] <wm4> so I suppose using mpv for this was an obvious thought [17:19:03 CEST] <ubitux> i don't understand why your seek isn't exclusively on the input actually [17:20:17 CEST] <wm4> so you accurately seek on the output [17:20:27 CEST] <wm4> think about frame doubling deinterlacing and such [17:21:09 CEST] <BtbN> iive, basicaly, the thing that does greenscreens. [17:42:21 CEST] <Compn> isnt the vf framestep for that [17:42:32 CEST] <Compn> skip 1500 frames, then start output [17:42:40 CEST] <Compn> it would be nice if it had that feature [17:42:47 CEST] <Compn> instead of outputting 1 frame every 1500 frames. [17:44:32 CEST] <rcombs> Compn: use the select filter [18:13:04 CEST] <lglinskih> fate-md5: libavutil/md5-test$(EXESUF) [18:13:09 CEST] <lglinskih> fate-md5: CMD = run libavutil/md5-test [18:13:30 CEST] <lglinskih> we don't need EXESUF in the second string? [18:23:07 CEST] <jamrial> no, you can run windows executables without it [18:23:41 CEST] <jamrial> but you need to specify it to Make when building them [18:24:35 CEST] <wm4> yeah, on windows $(EXESUF) would expand to .exe [18:25:00 CEST] <lglinskih> and what about other OS? [18:25:10 CEST] <wm4> other systems don't have one [18:25:19 CEST] <wm4> it'll expand to an empty string, so it'd do nothing [18:26:17 CEST] <kirelagin> I bet there is an OS that has special extension for executables and wont execute them without extension ;) [18:27:33 CEST] <kirelagin> But what matters is that ffmpeg probably isnt aiming to support them [18:31:03 CEST] <lglinskih> is it fine if I just add $(EXESUF)?=) [18:33:00 CEST] <iive> if binaries are not installed, you can make it to .elf :) [18:34:44 CEST] <jamrial> lglinskih: there's no need to add it for any "CMD =" line [20:00:03 CEST] <BtbN> RGB to YUV conversion is confusing, there are multiple formular on the net, which all claim to be exact by definition oO [20:04:12 CEST] <BBB> BtbN: it depends on what type of yuv [20:04:29 CEST] <BBB> BtbN: 601/709/smpte240 all have slightly different conversion formulae [20:04:33 CEST] <BtbN> Whatever ffmpeg has in AV_PIX_FMT_YUV(A)420P [20:04:33 CEST] <JEEBsv> in general the algo is the same, but then you have coefficients [20:04:48 CEST] <BBB> BtbN: that depends on other descriptors in avcodeccontext [20:05:00 CEST] <BBB> BtbN: plus the rgb it is converted into is not identical [20:05:23 CEST] <BBB> BtbN: this is a really hairy area, you may not care enough to want to know, its like chasing your own tail for a year [20:05:24 CEST] <BtbN> I'm in a filter, and i get an input color as user parameter, which i need as yuv [20:05:36 CEST] <wm4> it's in AVFrame now too [20:05:48 CEST] <wm4> AVFrame.colorspace etc. [20:06:08 CEST] <BBB> look at AVColorSpace and related enums in libavutil/pixfmt.h [20:06:09 CEST] <wm4> but in general, if you don't work with YUV but RGB, just make the input RGB? [20:06:13 CEST] <BBB> they are used in AVCodecContext [20:06:28 CEST] <BtbN> chromakey is yuv [20:06:28 CEST] <BBB> wm4: oh cool [20:06:58 CEST] <BtbN> The only place where i get in touch with RGB is the user parameter [20:07:05 CEST] <BtbN> AV_OPT_TYPE_COLOR gives me rgba [20:07:20 CEST] <wm4> maybe it would be nice if there were some utility code to return the correct matrix for a given conversion, instead of making it secret knowledge of libswscale and various standards [20:07:24 CEST] <wm4> ah [20:07:36 CEST] <wm4> for chomakey, wouldn't a YUV parameter make more sense? [20:07:43 CEST] <BBB> Id just call it yuv then, yes [20:07:44 CEST] <wm4> even if you take user convenience into account [20:07:52 CEST] <BBB> opengl calls its buffers rgba, but its undefined what is in each channel [20:07:56 CEST] <BBB> so people happily put yuv in it [20:08:06 CEST] <BBB> (r=y,g=u,b=v) [20:08:15 CEST] <BtbN> The problem with that is, that AV_OPT_TYPE_COLOR accepts strings like "green" as input [20:08:20 CEST] <BBB> (or r=each per plane) [20:08:21 CEST] <BtbN> which would end up as everything but green [20:08:43 CEST] <BBB> if you want to convert in your filter, youll need the user to specify the colorspace [20:08:48 CEST] <BBB> (AVColorspace) [20:08:58 CEST] <BBB> and then do the conversion according to the correct coefficients [20:09:03 CEST] <BBB> (or take it from the input yuv stream) [20:10:29 CEST] <BtbN> Oh, there are RGB_TO_Y/U/V defines in libavutil/colorspace.h [20:10:58 CEST] <wm4> last time I tried to use them I ended up using something else [20:11:11 CEST] <wm4> because trying to understand these weird macros took way more effort than NIHing it [20:11:24 CEST] <wm4> (they are absolutely horrible) [20:12:11 CEST] <wm4> actually maybe the TO macros are ok [20:12:24 CEST] <wm4> I tried the macros above that [20:12:43 CEST] <wm4> which implicitly reference variables you have to declare before the macros etc. [20:12:46 CEST] <BtbN> That filter will be horrible slow though... No way this will work in realtime. [20:12:51 CEST] <BBB> I dont actually know which standard these macros follow [20:13:07 CEST] <BBB> why, you need the conversion more than once per frame? [20:13:16 CEST] <BtbN> No, the entire filter. [20:13:18 CEST] <BBB> I mean, if the user input is rgb and you need that in yuv, its just one variable right? [20:13:22 CEST] <BBB> so you convert it in init [20:13:25 CEST] <BtbN> The conversion is only needed once at init [20:13:31 CEST] <BBB> and use the converted value in your speed critical code [20:13:33 CEST] <BBB> right [20:13:38 CEST] <BBB> so why is it slow? [20:13:39 CEST] <BtbN> But the entire chromakey algorithm [20:13:45 CEST] <BBB> well thats your problem :-p [20:13:53 CEST] <BBB> and easily simd'ed [20:14:22 CEST] <BtbN> The algorithm i found uses floats. [20:14:24 CEST] <BBB> (I foresee a combination of pcmpgtb) [20:14:29 CEST] <BBB> so write it in its [20:14:39 CEST] <BBB> ints* [20:14:47 CEST] <BtbN> I don't think that'd work out propperly. [20:14:50 CEST] <kierank> why not [20:14:53 CEST] <BBB> why [20:14:58 CEST] <kierank> the coefficients are fixed point [20:15:05 CEST] <BBB> float is just int with an autoshifter [20:15:16 CEST] <BBB> (sort of) [20:21:43 CEST] <BtbN> yep, it's doing 4 fps... [20:22:25 CEST] <BtbN> Converting these algorithms to integer math is absolutely neccesary, but i have no idea how the color distance calculation would work then. [20:24:06 CEST] <Daemon404> why are you manually doing this [20:24:21 CEST] <BtbN> hm? [20:24:28 CEST] <Daemon404> swscale is a thing [20:24:38 CEST] <BBB> Daemon404: chromakey distance != swscale [20:24:38 CEST] <BtbN> swscale to convert an algorithm? [20:24:53 CEST] <Daemon404> ffs i misread [20:25:10 CEST] <Daemon404> re: chroma key, do you have places for proper blending around edges [20:25:13 CEST] <BBB> I assume distance is expressed as 1.2*(ypicture - ykey) + 3.7*(upicture - ukey) + 0.2*(vpicture - vkey)? [20:25:13 CEST] <Daemon404> i.e. feathering [20:25:24 CEST] <BBB> (where I made up the coeficients) [20:25:25 CEST] <BBB> ? [20:25:35 CEST] <BBB> and then some abs in there [20:25:47 CEST] <BBB> and if distance < threshold alpha=0 else alpha=1? [20:25:58 CEST] <BBB> (or something roughly along these lines) [20:26:41 CEST] <BtbN> It's basicaly just sqrt(diff_u² + diff_v²), with diff_u=u-key_u [20:26:56 CEST] <BtbN> y is ignored [20:26:59 CEST] <BtbN> for the keying [20:26:59 CEST] <BBB> diff_u is int [20:27:01 CEST] <BBB> ok [20:27:04 CEST] <BBB> diff_v is also int [20:27:06 CEST] <BBB> sqrt is int [20:27:11 CEST] <BBB> (or can be int) [20:27:22 CEST] <BBB> sq is obv int [20:27:32 CEST] <BBB> so I dont see the issue [20:27:42 CEST] <BBB> theres a lot of sqrt int algos out there [20:28:07 CEST] <BBB> theyre not necessarily faster than float in scalar, but since theyre easier to vectorize and their precision is tunable, they tend to be faster in practice [20:28:08 CEST] <BtbN> The values are in the range from 0-255, so with an integer sqrt it wouldn't be precise enough. [20:28:19 CEST] <BBB> why [20:28:33 CEST] <BBB> you can express the result as a fixed-point value [20:28:38 CEST] <BBB> 0x100 = 1.0 [20:28:40 CEST] <BBB> 0x200 = 2.0 [20:28:43 CEST] <BBB> 0x180 = 1.5 [20:28:44 CEST] <BBB> etc. [20:28:49 CEST] <BtbN> So basicaly just multiple up everything... [20:28:50 CEST] <BBB> it can be as precise as you like [20:28:56 CEST] <BBB> thats fixed point integer math, yes [20:29:08 CEST] <BtbN> Very annoying. I want this to work with floats first. [20:29:16 CEST] <BBB> lol ok:) [20:29:39 CEST] <BtbN> Cause at the moment it's keying everything, so something is still wrong. [20:29:45 CEST] <BBB> right [20:29:46 CEST] <BBB> ok [20:30:03 CEST] <BBB> debug it first, when youre ready for integer feel free to ask any questions here [20:30:09 CEST] <BBB> a lot of us have experience in that area :) [20:30:42 CEST] <BtbN> I have also no idea if the algorithm itself is ideal. There isn't much about that topic, except how to do it in various commercial softwares. [21:24:06 CEST] <nalply> I am new here. AVInputFormat.get_device_list() is not implemented for dshow and avfoundation. I would like to rewrite avdevice so that I can list devices programmatically (i.e. not by executing `ffmpeg -list_devices true -f dshow`). What do you think? Please also see https://trac.ffmpeg.org/ticket/4486. [21:37:48 CEST] <nevcairiel> if ffmpeg.c can list the devices, then there must be a API to do it programmatically [21:54:50 CEST] <nalply> Sorry, no. Please read line 685 of libavdevice/avfoundation.m: https://ffmpeg.org/doxygen/trunk/avfoundation_8m_source.html#l00685 [21:56:15 CEST] <nalply> It's in the function avf_read_header(). It's invoked when the input format starts reading from the device. [21:57:22 CEST] <nalply> It checks whether the option list_device is set then it does not invoke avdevice_list_devices() but immediately queries AVFoundation and puts the information to av_log() calls. [22:00:48 CEST] <nalply> Similarly for dshow: https://ffmpeg.org/doxygen/trunk/dshow_8c_source.html#l01013 [22:14:42 CEST] <BtbN> Hm, it does _something_, but it keys the wrong color. [22:17:48 CEST] <nalply> Huh? [22:30:46 CEST] <BBB> nalply: Im fine with that being an explicit api [22:30:59 CEST] <BBB> BtbN: well thats a bug in your code :-p [22:33:50 CEST] <nalply> Ah, thanks. Did you write about ffvp9 last year? [23:45:25 CEST] <cone-149> ffmpeg 03Michael Niedermayer 07master:93db2708d3b0: ffmpeg: Fix null pointer dereference in do_video_out() [00:00:00 CEST] --- Mon Apr 20 2015