Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2016

1 participants
58 discussions

ffmpeg-devel.log.20160208
by burek 09 Feb '16

09 Feb '16

[00:09:43 CET] <durandal_1707> hmm looks like framepool issue [00:13:40 CET] <jkqxz> Timothy_Gu: Unclear. [00:15:09 CET] <jkqxz> Pretty much all of what I've written is required there too, it would just gain the extra layer on top to fit into that framework. [00:15:45 CET] <rcombs> seems it'll make the filtering stuff a little simpler, at least [00:18:07 CET] <ubitux> > We're experiencing an issue where ffmpeg seg faults for very large "-filter_complex_script" input files (roughly 3MB). [00:18:11 CET] <ubitux> meh [00:18:22 CET] <durandal_1707> so how should I name filter that reads each line of file as new filtergraph? [00:18:54 CET] <durandal_1707> ubitux: you are evil, responsible for enable hack [00:19:43 CET] <ubitux> enable \o/ [00:19:46 CET] <ubitux> anyway, afk [00:25:11 CET] <jkqxz> Should I be expecting that libav patch to land any time soon? The discussion on the libav-devel list looked rather ambivalent. [00:29:59 CET] <wm4> not sure [00:54:10 CET] <Timothy_Gu> bob weaver lol [01:01:05 CET] <kierank> atomnuker: a ptrdiff change isn't worth a v3 [01:01:58 CET] <atomnuker> kierank: I _know_ [01:02:28 CET] <atomnuker> but stuff gets buried in the ML so quickly [01:02:59 CET] <kierank> just push it [01:03:04 CET] <kierank> clearly nobody's going to review it [01:04:23 CET] <atomnuker> it's a huge feature, comparitively, and I'm personally not okay with merging it until at least someone say it's okay (a small 'but' is acceptable) [01:04:31 CET] <kierank> it's not a huge feature [01:04:48 CET] <atomnuker> it is compared to say, a random bugfix somewhere [01:55:43 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:05924e1440fd: avfilter/af_anequalizer: Fix memleak of args [02:13:18 CET] <Timothy_Gu> ubitux: your x86_64-archlinux-gcc-tsan fate station is broken [02:13:39 CET] <Timothy_Gu> "ccache cc is unable to create an executable file." [02:14:16 CET] <Timothy_Gu> seems like its been broken since 2015-12-06: http://fatebeta.ffmpeg.org/history/x86_64-archlinux-gcc-tsan?begin=150 [02:18:26 CET] <jamrial> why is it not showing in the index? [02:20:07 CET] <Timothy_Gu> because it's too broken [02:21:02 CET] <Timothy_Gu> jamrial: i.e. not even arch and config information is recorded to the fate record before the configure failed [02:21:15 CET] <Timothy_Gu> old fate behaves the same way [06:06:14 CET] <Timothy_Gu> solution: use lua!!! [06:15:43 CET] <Compn> json everywhere [06:54:44 CET] <satinder> Hi , When I am compiling dranger tutorial 1 , I got an error : PIX_FMT_RGB24 undeclared [06:54:57 CET] <satinder> anyopen can please help me [06:55:00 CET] <satinder> thanks [08:10:43 CET] <wm4> satinder: you got an ancient version of it [08:16:52 CET] <satinder> wm4 : what is ancient version ?? [08:17:01 CET] <satinder> I don't know about that [08:17:05 CET] <satinder> please help [08:34:12 CET] <ubitux> Timothy_Gu: it's having this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308 [08:34:17 CET] <ubitux> apparently. [09:03:36 CET] <Timothy_Gu> ubitux: that's one nasty bug& [09:04:13 CET] <Timothy_Gu> satinder: what "ancient" means is that the tutorial is written for a very old version of FFmpeg and does not work anymore [09:10:33 CET] <satinder> ok [09:11:03 CET] <satinder> Timothy_Gu : Can you help me how I can capture a rtsp stream [09:11:09 CET] <satinder> with ffmpeg api [09:11:46 CET] <durandal_1707> Timothy_Gu: what bug? [09:37:45 CET] <Timothy_Gu> durandal_1707: 23:34 <@ubitux> Timothy_Gu: it's having this issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67308 [10:08:00 CET] <Timothy_Gu> is there an easy way to divide each word by 255 in SSE2? [10:11:47 CET] <rcombs> you'd need to convert that into adds, multiplies, and shifts [10:11:52 CET] <nevcairiel> sse2 doesnt have integer divison, so you could try to emulate it by using a "fast div255" hack, but that only works if you can guarantee a limited value range or use 32-bit intermediates [10:14:18 CET] <nevcairiel> in general, x*257>>16, or (x+1+((x+1)>>8))>>8 [10:14:37 CET] <nevcairiel> first should be (x+1)*257 [10:15:47 CET] <rcombs> (x + 255) >> 8 may be suitable for your application [14:00:28 CET] <BtbN> looks like someone has connection issues [14:01:03 CET] <nevcairiel> its been quiet for over 10 minutes now, lets hope it stopped =p [14:34:43 CET] <durandal_1707> any more comments for metadata filter? [14:53:51 CET] <durandal_1707> who is responsible for ffmpeg youtube channel? [14:54:37 CET] <BtbN> There is a ffmpeg youtube channel? An official one? [14:55:24 CET] <Daemon404> ... why on earth would we need one [14:56:02 CET] <nevcairiel> show off all the fancy avfilter effects [14:56:03 CET] <BtbN> demos of filter effects or something, no idea. But i never heard of one [14:57:15 CET] <wm4> "ffmpeg youtube channel" lol what [15:03:48 CET] <Loriker> ..under which url is it? [15:34:21 CET] <durandal_1707> Loriker: https://www.youtube.com/channel/UCSJ7ur8rS4Mg_72S0ZmIDaA [15:36:45 CET] <Daemon404> g 42 [15:40:58 CET] <atomnuker> why does it only have fishes? [15:41:36 CET] <RiCON> fishes aren't copyrighted? [15:42:25 CET] <durandal_1707> it doesnt use hstack/vstack :( [15:43:59 CET] <RiCON> pip example uses libvo_aacenc [15:50:52 CET] <cone-484> ffmpeg 03Paul B Mahol 07master:35d9441f7b96: avfilter/vf_swaprect: add timeline support [15:58:21 CET] <cone-484> ffmpeg 03Michael Niedermayer 07master:a25c5dbb5ee0: ffmpeg_opt: Fix memleaks in "manually set programs" loop [15:58:29 CET] <roxlu> hey! Someone around who knows about mpeg-ts? I'm wondering what the logic behind calculating the PTS / PCR values is when muxing different streams ? (e.g. combining 4 ts streams) [16:01:23 CET] <BtbN> voodoo magic. [16:02:18 CET] <roxlu> Lol so it seems :) [16:02:26 CET] <roxlu> nah, the code is quite clear I think. [16:02:41 CET] <roxlu> I just don't know where to look yet [16:03:45 CET] <roxlu> When I look at line 1222 here https://www.ffmpeg.org/doxygen/2.5/mpegtsenc_8c_source.html it seems that the PTS/DTS from the source packets is simply used and increased with a "delay" offset [16:04:46 CET] <roxlu> I'm only now sure what max_delay means here [16:37:20 CET] <Timothy_Gu> nevcairiel, rcombs: thanks [16:44:27 CET] <BBB> nevcairiel: ping [17:00:06 CET] <BBB> nevcairiel: pokey poke [17:00:22 CET] <durandal_1707> ping me [17:01:31 CET] <BBB> durandal_1707: ping [17:02:55 CET] <BBB> nevcairiel: so, explain to me how the fallback between hw and sw decoding works in vp9 (or maybe in general), because I dont get it [17:03:16 CET] <BBB> nevcairiel: my understanding was that per-frame, wed call hwaccel->start_frame(), and it returns whether it supports this frame type or not [17:03:28 CET] <durandal_1707> nice gsoc/outreachy project is writing A & V filter source to test multichannel setups [17:03:45 CET] <BBB> nevcairiel: but there is no fallback between start_frame fail and sw dec fallback, at least none that I can see in vp9 on a per-frame (adaptive) basis [17:04:02 CET] <wm4> durandal_1707: why would something like this be hardcoded [17:04:56 CET] <durandal_1707> wm4: its hardcoded as video i have from dolby, and even files you generated are hardcoded [17:05:26 CET] <wm4> yes but I generated them with a fancy filter graph... so why hardcode such a source [17:06:11 CET] <durandal_1707> so it can be used by average joe, no need for fancy graphs [17:07:16 CET] <wm4> average joe can you preproduced test files [17:07:22 CET] <wm4> s/you/use/ [17:08:19 CET] <nevcairiel> BBB: thats not how it works, every time the frame format changes the decoder is supposed to call ff_get_format (or the thread variant with a similar name), which will then internally enable or disable hwaccel [17:08:44 CET] <BBB> how? [17:08:44 CET] <wm4> durandal_1707: that said, mechanisms to make it _easier_ to write such graphs would be good [17:08:50 CET] <BBB> how do I know its enabled or disabled [17:09:11 CET] <wm4> durandal_1707: for example, intuitively I'd just want to concatenate multiple sources (each playing for a while), for both video and audio [17:09:16 CET] <nevcairiel> BBB: if avctx->hwaccel is set [17:09:25 CET] <BBB> but what sets it? [17:09:31 CET] <nevcairiel> ff_get_format [17:09:40 CET] <BBB> aahhhaa [17:09:45 CET] <BBB> ok Im learning so much here [17:09:46 CET] <BBB> ty [17:09:57 CET] <wm4> durandal_1707: in my script I had to do this very awkwardly by creating multiple temp files and concatenating them [17:10:00 CET] <iive> if the returned format is hwaccelerated, you've gotten acceleration. [17:10:11 CET] <durandal_1707> ubitux: hom much fast is enable approach for 3mb scripts [17:10:34 CET] <ubitux> it's dumb and slow, but it shouldn't crash [17:11:20 CET] <durandal_1707> it segv here too, i dont hat backtrace, just last line where it happens [17:11:29 CET] <durandal_1707> s/hat/have [17:12:39 CET] <durandal_1707> ubitux: edit file and duplicate all lines, repeat until crash happens [17:14:17 CET] <durandal_1707> wm4: iirc there is script you used... [17:14:31 CET] <Daemon404> s [17:22:03 CET] <ubitux> durandal_1707: and where does it happen? [17:25:51 CET] <durandal_1707> ubitux: i haven't saved output, sorry [17:33:11 CET] <durandal_1707> wm4: what was not possible to do? you can call several aevalsrc,fade in and out them and after that amerge them [17:44:42 CET] <j-b> Is Kyle around? [17:46:14 CET] <kierank> seems not [17:47:09 CET] <durandal_1707> j-b: you need something? [17:49:48 CET] <j-b> durandal_1707: porn :) [17:49:51 CET] <j-b> kierank: :) [17:50:10 CET] <j-b> kierank: since you are now an expert, can you explain to me American Football? [17:50:26 CET] <kierank> I don't watch the sport, I watch the picture [17:50:52 CET] <kierank> the w9 feed came from moi last night [17:57:04 CET] <durandal_1707> j-b: I'm watching you 0-0 [18:36:15 CET] <durandal_1707> wm4: ./ffmpeg -f lavfi -i anoisesrc=c=pink -lavfi [0:a]afade,afade=out:d=1:st=5[a],[0:a]afade=in:st=6,afade=out:st=11[b],[a][b]amerge [19:05:43 CET] <BBB> nevcairiel: it would be useful, I believe, if there was a dummy hwaccel impl for relevant codecs that provides a sw implementation (possibly by looping back to the decoder itself) for hwaccel infrastructure testing [19:05:47 CET] <BBB> nevcairiel: does that make sense? [19:07:33 CET] <nevcairiel> sure, but it would likely be very complex [19:08:03 CET] <nevcairiel> for vp9 it would actually be the easiest since the hwaccel gets access to the entire bitstream [19:08:08 CET] <nevcairiel> for h264 however, the hwaccel only gets slices [19:08:16 CET] <nevcairiel> so you need to rebuild the entire state of the decoder from metadata [19:09:52 CET] <BBB> hm& [19:10:00 CET] <BBB> I guess vp9 only should be ok for my purposes [19:10:10 CET] <BBB> testing hwaccel right now is kind of tricky for me [19:10:56 CET] <BtbN> Doesn't ffmpeg have a root server from Hetzner somewhere? Those usualy have a vaapi capable GPU. [19:15:31 CET] <Timothy_Gu> BtbN: yeah that's ffmpeg.org [19:15:45 CET] <Timothy_Gu> not really good to do testing on there i suppose [19:25:17 CET] <BBB> nevcairiel: can you test patches for me on your system? [19:25:36 CET] <BBB> like, testing being see if allowing hwaccel+vp9+mt does not fail [19:25:49 CET] <BBB> (assuming it currently sometimes does fail) [19:25:56 CET] <durandal_1707> anyone needs new machine? [19:25:57 CET] <nevcairiel> right now it massively fails [19:26:23 CET] <nevcairiel> but i can test [19:27:34 CET] <BBB> nevcairiel: http://pastebin.com/DfMGhrmb [19:27:54 CET] <BBB> nevcairiel: if my understanding of everything is correct (highly doubtful), this should fix the fails [19:28:23 CET] <nevcairiel> will this not just end in nothing ever getting executed [19:28:34 CET] <BBB> nevcairiel: and then all related work to remove the disabling of mt if hwaccel is enabled or whatever (or vice versa, I dont know what the state of that is) [19:29:39 CET] <nevcairiel> besides there are already hacks in place to simply skip calling finish_setup when hwaccel is enabled .. not for vp9 mind you because that didnt solve its problems [19:29:41 CET] <BBB> nevcairiel: I think it should execute just fine, but it will do so entirely serially [19:30:03 CET] <BBB> nevcairiel: it basically forces hwaccel to follow the single threaded codepath for everything [19:30:20 CET] <BBB> I can explain further but you might not want to know [19:31:10 CET] <nevcairiel> thats not vp9s problem though, i tried something like this [19:31:30 CET] <nevcairiel> like I said, other codecs simply have a if (!hwaccel) branch before calling ff_thread_finish_setup to achieve the same goal [19:31:49 CET] <BBB> I really want hw so I can test this normally [19:32:02 CET] <nevcairiel> when you do this, you still have worker threads [19:32:06 CET] <BBB> yes [19:32:10 CET] <nevcairiel> and the way vp9 is written it inits every worker thread separately [19:32:13 CET] <BBB> but they are synced in update_thread_context [19:32:19 CET] <nevcairiel> not entirely, no [19:32:29 CET] <nevcairiel> some of their data is updated independently [19:32:29 CET] <BBB> what do you mean not entirely? [19:32:54 CET] <BBB> wihch part would you like to be synced? [19:32:56 CET] <nevcairiel> update_size allocates data when a worker thread runs for the first time [19:33:06 CET] <BBB> yes [19:33:24 CET] <nevcairiel> and similarly, update_size calls ff_thread_get_format again on every worker thread [19:33:26 CET] <BBB> in the ff_get_format call? [19:33:35 CET] <nevcairiel> potentially resetting the hwaccel on every thread [19:33:39 CET] <nevcairiel> causing lots of problems [19:34:06 CET] <BBB> so why dont other hwaccels dont have that issue? [19:34:14 CET] <nevcairiel> because their init is smarter [19:34:19 CET] <nevcairiel> they dont do that =p [19:34:21 CET] <BBB> can we make vp9s init smarter? [19:34:26 CET] <nevcairiel> probably [19:34:36 CET] <nevcairiel> but i didnt bother because hwaccel-mt has zero advantages [19:35:32 CET] <wm4> shouldn't it be pretty simple to feed only 1 worker thread with work and leave the others idle? [19:36:22 CET] <nevcairiel> anyway the ff_thread_finish_setup thing isnt even called by vp9 in hwaccel mode, i made it skip all that :D [19:36:42 CET] <BBB> hm... [19:36:43 CET] <BBB> ok [19:36:43 CET] <BBB> so [19:36:56 CET] <BBB> wm4: its a lot of code that Id like to avoid [19:37:06 CET] <BBB> wm4: Im thinking of shared codepaths being simpler to maintain, this code is already fairly hairy [19:37:15 CET] <nevcairiel> the thing is, just fixing vp9 hwaccel to work in mt mode doesnt fix any of the underlying key problems [19:37:19 CET] <BBB> nevcairiel: I dont see vdpau doing anything complex [19:38:17 CET] <nevcairiel> i have no idea what vdpau has to do with anything we're talking about [19:38:49 CET] <BBB> youre saying their init does complicated things to not init double [19:38:58 CET] <BBB> or do you mean the decoder itself instead of the hwaccel? [19:39:17 CET] <nevcairiel> the decoder [19:39:38 CET] <nevcairiel> for codecs like h264 it really falls back to how the codec works itself [19:39:48 CET] <nevcairiel> it inits this stuff when it loads a particular sps [19:39:54 CET] <nevcairiel> and it only does that once, not on every thread [19:40:05 CET] <BBB> so heres what I dont get then - we sync hwaccel and hwaccel_context between each thread [19:40:15 CET] <BBB> so why does the second threads hwaccel thing its uninitialized? [19:40:35 CET] <nevcairiel> because ff_thread_get_format is called again which destroys and re-creates it [19:40:53 CET] <nevcairiel> one shall not call that function too often, only when things really change [19:42:03 CET] <nevcairiel> but vp9 also uses the "things changed!" function to init its stuff [19:42:14 CET] <BBB> so& you want me to split vp9.cs internal buffer allocation in two things: allocate buffers, and signal actual size change [19:42:18 CET] <BBB> thats not hard at all [19:42:22 CET] <BBB> right? [19:42:44 CET] <nevcairiel> that would probably help [19:42:52 CET] <nevcairiel> i never got past that problem, so no clue if it fixes all of it [19:45:02 CET] <BBB> I dont need to call it on size change, right? [19:45:08 CET] <BBB> (since vp9 supports scalable) [19:45:11 CET] <nevcairiel> you do [19:45:14 CET] <nevcairiel> screw scalable [19:45:17 CET] <nevcairiel> dont support that crap [19:45:18 CET] <nevcairiel> :P [19:46:02 CET] <BBB> ... [19:46:16 CET] <nevcairiel> it needs to be called on pixfmt or size changes, but ideally on nothing else [19:46:36 CET] <BBB> so for vp9, only on pixfmt change [19:46:38 CET] <BBB> in theory [19:46:49 CET] <BBB> given that size change is allowed and should not cause a reinit [19:46:50 CET] <BBB> :-p [19:47:21 CET] <nevcairiel> if the all mighty vp9 gods would have included information what the maximum size in a given bitstream was, that might be true [19:47:25 CET] <nevcairiel> but oh no, they forgot! [19:47:58 CET] <nevcairiel> so you need to call that function and the user app can decide if it wants to re-init to create bigger surfaces [19:49:27 CET] <BBB> hahaha [19:49:28 CET] <BBB> ok [19:49:28 CET] <BBB> fine [19:49:53 CET] <nevcairiel> a smart app would only re-init if something actually changes [19:49:57 CET] <nevcairiel> but alas not everything is smart [19:50:01 CET] <nevcairiel> including ffmpeg.c [19:50:03 CET] <nevcairiel> =p [19:50:26 CET] <nevcairiel> but it helps finding excessive init spam, i guess [19:53:06 CET] <nevcairiel> when i originally tried to split update_size a bit, my main problem was that I couldn't really differentiate between the very first init on the very first thread (ie. need to clal get_format), and just secondary inits on worker threads [19:53:20 CET] <nevcairiel> i didnt want to add some weird tracking variable for that, so.. [19:56:15 CET] <BBB> nevcairiel: http://pastebin.com/xePKgVxJ [19:56:18 CET] <BBB> nevcairiel: how about that? [19:57:29 CET] <nevcairiel> that still reinits every thread because last_fmt isnt synced [19:57:33 CET] <nevcairiel> although maybe it could be [19:57:53 CET] <nevcairiel> oh you added that [19:57:56 CET] <nevcairiel> i should finish reading [19:58:04 CET] <BBB> :-p [19:58:27 CET] <BBB> and then related stuff to remove the hwaccel/thread block in lavc/utils.c etc. [20:03:45 CET] <nevcairiel> BBB: not worky [20:03:54 CET] <BBB> not surprised [20:03:57 CET] <BBB> anything in particular? [20:04:05 CET] <BBB> like, does it still call get_format per thread? [20:04:08 CET] <BBB> or something else? [20:04:09 CET] <nevcairiel> did you test it at all? [20:04:13 CET] <nevcairiel> sw decoding is broke too [20:04:18 CET] <BBB> sw works for me [20:04:25 CET] <BBB> so yes I did test that [20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] video_get_buffer: image parameters invalid [20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] get_buffer() failed [20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] thread_get_buffer() failed [20:04:30 CET] <nevcairiel> [vp9 @ 006E67E0] Not all references are available [20:04:30 CET] <nevcairiel> Last message repeated 97 times [20:04:51 CET] <BBB> ok lemmecheck [20:05:10 CET] <BBB> probably depends on the file... [20:05:27 CET] <nevcairiel> works if i revert the patch [20:05:29 CET] <nevcairiel> so.. :) [20:08:28 CET] <BBB> I meant webm vs. ivf [20:08:31 CET] <BBB> testing [20:08:54 CET] <nevcairiel> this is a mkv [20:09:04 CET] <nevcairiel> actually a webm [20:09:08 CET] <nevcairiel> just named weirdly [20:13:29 CET] <nevcairiel> its actually my tos encode from our old benchmark =p [20:13:33 CET] <nevcairiel> (i dont have many vp9 files) [20:13:43 CET] <BBB> fate? [20:13:52 CET] <BBB> anyway Im testing more, sorry [20:20:02 CET] <Timothy_Gu> durandal_1707: for filter slice threading, is the slice width always guaranteed to be multiple of 16? [20:24:35 CET] <Timothy_Gu> writing asm is fun [20:27:23 CET] <durandal_1707> Timothy_Gu: you are spliting widht or height? [20:34:08 CET] <durandal_1707> if spliting height, it is multiple of 16 [20:44:48 CET] <BBB> nevcairiel: http://pastebin.com/a0VCykS8 [20:44:55 CET] <BBB> nevcairiel: that passes fate-vp9 with 1 and 2 threads here [20:45:33 CET] <BBB> nevcairiel: it changes the meaning of last_fmt, the value of interest for hw now becomes gf_fmt (in case youre wondering) [20:47:55 CET] <jkqxz> wm4: Could you specify precisely a VAAPI memory map/unmap interface that you would like? [20:49:46 CET] <Timothy_Gu> durandal_1707: im talking about the blend filter [20:50:01 CET] <BBB> Timothy_Gu: the constants.c patches are fine [20:50:14 CET] <Timothy_Gu> ok [20:50:44 CET] <Timothy_Gu> what do you think about the cross-lib constants sharing problem though? [20:50:54 CET] <Timothy_Gu> jamrial: ^^ [20:51:24 CET] <Timothy_Gu> should i duplicate the constants like log2tab? [20:51:29 CET] <BBB> I dont have a good solution to it ATM [20:51:40 CET] <BBB> its not a big problem, I mean were talking a few bytes at best, so I wouldnt bother solving it [20:51:52 CET] <BBB> but it comes up every few months so if someone feels like fixing it, go for it [20:52:06 CET] <jamrial> either make a constants.c specific for libavfilter, or just keep things as they are because yeah, it's a bunch of bytes max [20:52:08 CET] <BBB> x86inc.asm has macros for visibile macros [20:52:17 CET] <BBB> er, visible arrays [20:52:24 CET] <BBB> and these ca be shared cross-lib with avpriv prefix [20:52:28 CET] <BBB> that should be enough [20:52:34 CET] <BBB> but again, low priority, few bytes not worth it [20:53:44 CET] <Timothy_Gu> yeah [20:54:34 CET] <wm4> jkqxz: maybe something like map(AVFrame *dest, AVFrame *vaapi_frame)? [20:54:59 CET] <wm4> I just think it's unclean to overwrite the vaapi frame itself for this [20:59:38 CET] <jkqxz> I want to make clear that the map/unmap is a raw operation and you should understand what is going on before using it. The user should only be using the copy to/from surface functions unless they're doing something very tricky. [21:00:29 CET] <jkqxz> Your dest frame is allocated by the user? What does unmap look like, exactly the same? [21:01:38 CET] <wm4> why provide these functions at all if they're so tricky? [21:01:48 CET] <wm4> the user can implement them manually too [21:02:00 CET] <wm4> and yes [21:02:57 CET] <jkqxz> They are needed for write-on-frame type things which would go in lavf. Though, I guess they could be static for now and only global when there is a real user. [21:04:40 CET] <durandal_1707> huh there is atrac9 [21:19:03 CET] <BBB> nevcairiel: let me know if you have time to test and whether it works for the hwaccel case if you get to it, thnx [21:26:34 CET] <llogan> who gets messages to opw(a)ffmpeg.org? [21:27:03 CET] <nevcairiel> BBB: i have been toying with your old patch, and simply initializing s->last_fmt to say -1 fixes its problems too, at least on a first glance, and seems far less invasive than your new one [21:27:32 CET] <BBB> I think the new one is cleaner in that it clearly splits the per-thread from the per-stream variables [21:27:44 CET] <BBB> Im a little concerned about security issues with the old patch on corrupt stuff [21:31:32 CET] <nevcairiel> seems to work on the first try [21:32:04 CET] <nevcairiel> lets try with fate [21:33:13 CET] <nevcairiel> fate isnt happy [21:33:20 CET] <nevcairiel> different results for threads and no threads [21:35:17 CET] <nevcairiel> doesnt seem quite deterministic [21:36:52 CET] <BBB> with hwaccel? [21:36:56 CET] <BBB> or w/o hwaccel also? [21:36:57 CET] <nevcairiel> yes [21:37:26 CET] <nevcairiel> with hwaccel only i think [21:37:53 CET] <nevcairiel> but i can run it without a couple times to make sure [21:37:58 CET] <BBB> is it possible sw_pix_fmt is not synced between threads? [21:38:04 CET] <BBB> (avctx->sw_pix_fmt) [21:38:12 CET] <nevcairiel> should be [21:38:12 CET] <BBB> since thats not synced in updatE_thread_context in pthread_frame.c [21:38:59 CET] <BBB> I wonder what else could be desynced [21:39:10 CET] <BBB> is it only the second frame, or first also, for the 2-frame seqs? [21:39:30 CET] <nevcairiel> its always the second failing on some of the fate tests [21:39:39 CET] <nevcairiel> but if it wasnt synced at all, i would think it would fail everytime [21:40:46 CET] <BBB> true [21:40:52 CET] <BBB> but its quick to try I guess [21:41:34 CET] <BBB> send me a laptop or so with vp9/dxva2 support? [21:43:58 CET] <nevcairiel> syncing sw_pix_fmt didnt help [21:44:09 CET] <durandal_1707> BBB: we have enough money to sponsor devs [21:44:21 CET] <BBB> canihaveanewmacbookprowithhaswell? [21:44:29 CET] <BBB> nevcairiel: hm& let me see [21:44:36 CET] <nevcairiel> that doesnt even have vp9 =p [21:44:59 CET] <BtbN> there is no (intel) hardware with native vp9 support yet [21:45:03 CET] <BBB> nevcairiel: so & setup_finished is never called right? [21:45:37 CET] <nevcairiel> all the blocks where vp9.c would call it should be skipped in hwaccel mode [21:46:12 CET] <BBB> and it only breaks sometimes? [21:46:13 CET] <BBB> so strange [21:46:33 CET] <nevcairiel> i should hook up my debug dxva2 hook and see if it sends different commands [21:46:48 CET] <nevcairiel> i've always wanted to make a fate test out of that to ensure noone breaks that [21:47:28 CET] <BBB> sounds good [21:49:15 CET] <nevcairiel> building this hook has certainly been time well spent =p [21:50:06 CET] <BBB> agreed [21:50:28 CET] <BBB> I dont directly have any indications what would be different w/ and w/o threads, lets see wha tthe hook says [21:51:03 CET] <nevcairiel> now i cant get it to break gah [21:51:15 CET] <nevcairiel> the hook writes a lot of log so its slow, wonder if it breaks the breakage =p [21:54:30 CET] <BBB> well ok so it makes sense that its a race then [21:54:32 CET] <BBB> but of that... [21:54:55 CET] <BBB> can you get it to break w/o hwaccel? [21:55:03 CET] <BBB> and if not, could that help us break down what breaks? [21:55:30 CET] <BBB> I wonder if its possible multiple threads enter decode at the same time anyway even though they shouldnt if you remove the call to setup_finished [21:55:40 CET] <BBB> is there some way to check that there is no concurrency? [21:58:31 CET] <nevcairiel> i wonder if its maybe the good old problem of uncontrolled concurrency between the decoder and the user code [21:58:58 CET] <nevcairiel> like i keep saying, hwaccel+mt is a flawed concept =p [21:59:18 CET] <BBB> well but no amount of shit can prevent that [21:59:19 CET] <BBB> I mean [21:59:39 CET] <BBB> not in a sane way at least [21:59:43 CET] <BBB> Id like to, but its tons of code [21:59:53 CET] <BBB> and Im affraid itll break more than it fixes [22:00:09 CET] <nevcairiel> this is why i send the patch to just disallow it in the first place [22:00:23 CET] <BBB> I know, but people complain [22:00:31 CET] <BBB> and if that was an issue, it should break for all codecs [22:00:33 CET] <BBB> which it doesn'yt [22:00:37 CET] <BBB> youre saying this is vp9 specific [22:00:40 CET] <nevcairiel> maybe it does break [22:00:44 CET] <BBB> can you test? [22:00:54 CET] <nevcairiel> i dont bother to regularly test threaded hwaccel [22:02:25 CET] <nevcairiel> BBB: just did, it breaks a lot of h264 tests randomly as well [22:02:30 CET] <Timothy_Gu> durandal_1707: yes, it's bit-exact for all the cases I tested [22:02:35 CET] <BBB> hm... [22:02:45 CET] <BBB> so you think its randomized access betw. threads? [22:02:56 CET] <durandal_1707> Timothy_Gu: real world ones, not just synthetic? [22:02:57 CET] <BBB> user/player and codec [22:04:30 CET] <nevcairiel> BBB: i have no proof to what *exactly* is happening, but my hunch is that the problem is that the user code has a frame locked for readback on the "main" thread, while the worker threads try to use it as a reference for decoding, which results in breakage, and there is no straight forward way for the user code to properly sync with those worker threads [22:04:51 CET] <BBB> even though its only reading and not writing? [22:05:10 CET] <nevcairiel> well when its locked, even readonly, the GPU may not get full access anymore [22:05:12 CET] <nevcairiel> idk [22:05:28 CET] <BBB> ic [22:05:35 CET] <nevcairiel> you can apparently hack around the problem by using a big lock around the entire frame buffer pool [22:06:12 CET] <nevcairiel> ie. just not return a new frame from get_buffer while we have a locked frame, that then stalls the worker thread until you are done [22:06:14 CET] <nevcairiel> but its kinda ugly [22:06:20 CET] <wm4> how to deal with threading problems: have a single big lock around everything [22:07:07 CET] <nevcairiel> BBB: anyway i think your patch is fine, it mostly works, and the breakage is probably related to this problem, so lets just leave it and make the warning when someone tries to use it even noisier [22:07:47 CET] <BBB> but then its still broken :( [22:07:58 CET] <BBB> so people wanting a good fallback will be screwed [22:08:07 CET] <nevcairiel> i mean, just running "make fate-h264 HWACCEL=dxva2 THREADS=4" is also broken, so what can you do [22:08:31 CET] <nevcairiel> BBB: thats why i wanted to get rid of that crap [22:08:39 CET] <nevcairiel> but alas, we have annoying people around =p [22:08:52 CET] <BBB> no no thats not my point [22:08:57 CET] <BBB> this patch doesnt fix anything [22:09:04 CET] <BBB> it may make the breakage slightly more obscure [22:09:06 CET] <BBB> but its still broken [22:09:20 CET] <BBB> is vdpau or vaapi or whatever also broken in this way? [22:09:24 CET] <BBB> or is it dxva2 only? [22:09:40 CET] <nevcairiel> at least vp9 wont be broken anymore, now its just the systematic design flaw in the system that remains =p [22:09:43 CET] <nevcairiel> i dunno [22:10:02 CET] <nevcairiel> i would wager they are equally affected, but i have no proof [22:10:17 CET] <llogan> feel free to add ideas to https://trac.ffmpeg.org/wiki/SponsoringPrograms/ProjectIdeas . i don't want to simply copy old, ancient, crusty ones from the old GSoC and OPW/Outreachy pages. [22:11:32 CET] <nevcairiel> BBB: poke wm4 to run it a couple times ;) [22:11:36 CET] <BBB> wm4: poke [22:12:07 CET] <nevcairiel> "make fate-h264 HWACCEL=vdpau THREADS=4 -k" or something [22:12:08 CET] <jkqxz> I can do that for VAAPI. What do you want? [22:12:17 CET] <nevcairiel> we dont have a ffmpeg vaapi module [22:12:28 CET] <jkqxz> We have a patch which adds one. [22:12:39 CET] <nevcairiel> some of the tests will always fail, like cropping, which hwaccel doesnt do [22:12:43 CET] <nevcairiel> but the majority should pass [22:12:51 CET] <nevcairiel> well then replace vdpau with vaapi and give it a go =p [22:12:52 CET] <jkqxz> Most of FATE passes. I've never thught of trying threads. [22:12:55 CET] <wm4> BBB: run what? [22:13:11 CET] <BBB> make fate-h264 HWACCEL=vdpau THREADS=4 -k (and the equivalent for vp9) [22:13:14 CET] <llogan> durandal_1707: are the "==" supposed to be there? showspectrum== [22:13:22 CET] <BBB> wm4: make fate-h264 HWACCEL=vdpau THREADS=4 -k (and the equivalent for vp9) [22:13:23 CET] <nevcairiel> BBB: no vp9 in vdpau [22:13:31 CET] <nevcairiel> (yet) [22:13:36 CET] <Timothy_Gu> durandal_1707: mandelbrot and testsrc [22:13:43 CET] <wm4> hm stupidly need to compile ffmpeg first [22:13:53 CET] <BBB> oh shit thats vaapi [22:13:58 CET] <BBB> anyone have vaapi? [22:14:22 CET] <nevcairiel> also, before you can try that, you need to remove the block of hwaccel+mt from avcodec/utils.c [22:14:25 CET] <nevcairiel> i forgot that part :D [22:15:10 CET] <nevcairiel> wm4: jkqxz: ^ its in libavcodec/utils.c setup_hwaccel (around line 1018) [22:15:24 CET] <llogan> durandal_1707: trailing ' in showspectrumpic zample: out.jpg' [22:17:28 CET] <wm4> h264-conformance-cvfc1_sony_c fails [22:17:36 CET] <nevcairiel> that one always fails, that is cropping [22:17:58 CET] <Timothy_Gu> durandal_1707: is there any good samples i can use to test it? [22:18:10 CET] <BBB> interesting [22:18:14 CET] <BBB> so it works fine for vdpau [22:18:22 CET] <wm4> h264-reinit-small_420_9-to-small_420_8 also failed (a many more) [22:18:31 CET] <BBB> nevcairiel: I think we need to fix this then [22:18:41 CET] <BBB> its not ok for dxva2 only failing [22:18:54 CET] <nevcairiel> BBB: git master is fine [22:19:03 CET] <BBB> not w/ threading [22:19:05 CET] Action: nevcairiel leaves before anyone can bring any more arguments [22:19:16 CET] <BBB> as in, it doesnt provide the expected ideal end user experience [22:19:30 CET] <BBB> ok fine leave, let me break everything and never notice :-p [22:20:14 CET] <jkqxz> Everything which I expected to pass still passes. I lose some of the baseline streams, and cvfc1_sony_c fails as always. [22:20:36 CET] <durandal_1707> Timothy_Gu: http://samples.ffmpeg.org/benchmark/ [22:20:43 CET] <Timothy_Gu> ok [22:21:03 CET] <BBB> jkqxz: the threading is interesting for fallbck purposes [22:21:05 CET] <nevcairiel> BBB: suggestions welcome, but i wont volunteer much of my time to fix a mode i consider broken by design, sorry [22:21:23 CET] <BBB> so if I want threading in the fallback, what would you suggest I try? [22:21:29 CET] <llogan> i keep forgetting about testsrc2 [22:21:43 CET] <nevcairiel> BBB: re-open the decoder like everyone does, except vlc [22:21:43 CET] <wm4> keep in mind that vlc won't solve its problem, because vp9 won't work [22:21:57 CET] <wm4> (if we were to allow threads again) [22:22:10 CET] <BBB> vp9 wont work"? [22:22:26 CET] <nevcairiel> wm4: they ship some binaries with libav, they are used to vp9 not working [22:22:29 CET] <wm4> hwaccel with vp9 [22:22:31 CET] <wm4> lol [22:22:51 CET] <wm4> so there needs to be a fundamental solution to the problem, either in lavc or vlc [22:23:27 CET] <wm4> we can't just sweep problems under the rug like the debian guy wants to [22:23:33 CET] <nevcairiel> maybe whatever API vaapi and vdpau use is more thread-friendly and doesnt lock the surface while downloading the image [22:23:54 CET] <nevcairiel> on the other hand, both vdpau and vaapi probably have a bunch of alternative APIs to do that, who knows if one of those wouldnt break [22:24:02 CET] <wm4> well, vdpau has a readback function [22:24:11 CET] <wm4> and vaapi... has multiple ways to do it [22:24:17 CET] <nevcairiel> not being able to sync the user thread with the decode worker thread can be an issue in various ways [22:24:19 CET] <wm4> one of them might be essentially atomic [22:25:25 CET] <BBB> so you really want to sync them [22:25:27 CET] <BBB> ... [22:25:31 CET] <BBB> omg so much stuff [22:26:04 CET] <nevcairiel> personally i'm happy with the situation as it is right now [22:26:09 CET] <nevcairiel> i wouldnt use a fallback if there was one [22:26:10 CET] <BBB> Im not against that, and I agree its fundamentally probably the right solution [22:26:17 CET] <BBB> huh? [22:26:18 CET] <BBB> why not [22:26:22 CET] <BBB> ffvp9 is sooooooo cute [22:26:23 CET] <BBB> anyway [22:26:32 CET] <nevcairiel> because my "fallback" can also fallback to entirely different decoders [22:26:33 CET] <Timothy_Gu> durandal_1707: yeah it works fine [22:26:50 CET] <nevcairiel> so if hwaccel fails, i start over and select the appropriate software decoder [22:26:53 CET] <nevcairiel> which might be avcodec [22:26:57 CET] <nevcairiel> but it might also be something else [22:27:33 CET] <nevcairiel> ... which right now is only either avcodec or microsofts wmv/vc1 decoder, but its not impossible to consider more additions in the future [22:27:34 CET] <wm4> I use only libavcodec, but I also have this situation [22:27:57 CET] <wm4> there are enough hw decoders which are not implemented as hwaccel [22:28:35 CET] <jkqxz> VAAPI is backed by DRM so you can access it through all sorts of silly ways. The official way disallows read while mapped, but I'm not sure that we ever count as mapped in this case. [22:29:10 CET] <jkqxz> Hmm. Though I can hack it to map directly, which it doesn't currently do (back to the uncached memcpy() problem), and I expect it to then fail. [22:30:04 CET] <durandal_1707> Timothy_Gu: than its ok to push it i guess [22:30:48 CET] <jkqxz> Except now I'm stuck because FATE doesn't auto-convert the output frame for hashing and it's NV12 or nothing if I map directly. Blah. [22:34:59 CET] <Timothy_Gu> durandal_1707: cool [22:35:31 CET] <cone-484> ffmpeg 03Timothy Gu 07master:253209ac4449: vf_blend: Add SSE2 optimization for multiply [22:35:35 CET] <kierank> do I need a bump for pixel format addition? [22:35:39 CET] <Daemon404> yes [22:36:02 CET] <kierank> of avutil? [22:37:26 CET] <nevcairiel> yes [22:37:41 CET] <BBB> nevcairiel: allright, sent patch to ML, prpare for more flametrollfests [22:38:05 CET] <nevcairiel> jkqxz: fate seems to deal with nv12 frames for me just fine, it converts to yuv420 and gives bitexact output to the sw decoder [22:40:19 CET] <jkqxz> Your hwaccel helper outputs NV12 frames? [22:40:42 CET] <nevcairiel> of course [22:41:40 CET] <jkqxz> Odd. That doesn't work for me, every hash is wrong if I do that. I admit I didn't pursue exactly why, but outputting YUV420P from the hwaccel helper does work. [22:42:10 CET] <wm4> is the output visually fine? [22:43:38 CET] <jkqxz> Yes. NV12 output is the normal mode, except when hacked to do FATE. [22:43:58 CET] <Daemon404> cmp [22:44:06 CET] <Daemon404> easiest way to tell... [22:44:22 CET] <nevcairiel> I dunno, but the ffmpeg_dxva2.c hwaccel outputs NV12 frames, and fate passes with those [22:44:36 CET] <nevcairiel> because its processing pipeline makes yuv420p out of that [22:50:32 CET] <jkqxz> Right, I hacked it to output YUV420P from the hwaccel (quick C code to rearrange the bytes). Now I get exactly the expected failures (cvfc1_sony_c, the two greyscale ones, lossess). [22:50:52 CET] <omerjerk> hey I was looking at this code - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L1785 [22:51:06 CET] <nevcairiel> its really kind of unfortunate that lossless fails just because the profile checks refuse [22:51:08 CET] <omerjerk> As far as I understand, it only seeks to the nearest I-frame, right ? [22:51:15 CET] <nevcairiel> should probably use HWACCEL=auto to avoid the failure there [22:51:37 CET] <omerjerk> sorry, returns the nearest I-frame, right ? [22:52:05 CET] <llogan> is there anything that libdcadec can do that the new native decoder can't? [22:52:24 CET] <nevcairiel> llogan: no, its based on libdcadec afterall [22:52:59 CET] <llogan> i knew that it was based on it, but i was just curious [22:53:16 CET] <cone-484> ffmpeg 03Michael Niedermayer 07master:8e46c7c1e7f5: avfilter/af_agate: fix memleak of out frame [22:53:28 CET] <nevcairiel> native one should even be quite a bunch faster [22:53:34 CET] <nevcairiel> due to SIMD [22:54:03 CET] <jkqxz> And now I have some "Assertion src->f->buf[0] failed at libavcodec/h264_picture.c:73" when running with threads. Is that the prize I wanted? [22:54:06 CET] <wm4> omerjerk: depends on the format [22:54:17 CET] <omerjerk> I'm looking matroska [22:54:21 CET] <omerjerk> *looking at [22:54:24 CET] <llogan> nevcairiel: ok. thanks [22:54:30 CET] <nevcairiel> jkqxz: not really, that shouldnt happen i dont think :D [22:54:41 CET] <nevcairiel> unless your hwaccel forgot to set buf[0] [22:54:46 CET] <wm4> for matroska it usually uses the file index and the matroska "keyframe" markers [22:55:01 CET] <jkqxz> It fails with threads and not without! [22:55:11 CET] <omerjerk> ohkay. I understand it thanks. [22:57:52 CET] <jkqxz> Oh, it needs more than 20 surfaces simultaneously [22:58:27 CET] <nevcairiel> every thread needs one extra surface [22:58:31 CET] <jkqxz> Push that up further and it passes. [22:58:35 CET] <nevcairiel> which is another reason i dislike that [22:59:33 CET] <wm4> heh [22:59:53 CET] <wm4> jkqxz: I hope it didn't assert because it failed to alloc a surface [22:59:53 CET] <jkqxz> Ok, that's useful to know. I will copy "if (s->active_thread_type & FF_THREAD_FRAME) ctx->num_surfaces += s->thread_count;" from ffmpeg_dxva2.c... [23:00:22 CET] <nevcairiel> your buffer allocation function should probably return an error instead of silentlly not returning a surface =p [23:01:03 CET] <jkqxz> Yeah. (It see the error and then returns zero from the function. How helpful.) [23:01:28 CET] <kierank> llogan: shall I do the outreachy stuff? [23:01:55 CET] <llogan> kierank: sure, if you have the time. if you need help I can lend a hand now and then. [23:06:23 CET] <jkqxz> Are you sure about that thread constraint? mr3_tandberg_b seems to require at least 46 surfaces with THREADS=4. [23:07:19 CET] <wm4> that sounds very wrong [23:07:38 CET] <nevcairiel> so every thread needs like 10 extra surfaces? where would those all go? :;D [23:07:45 CET] <jkqxz> Yeah. [23:08:13 CET] <jkqxz> 45 usually fails. 46 just passed 100 times. [23:10:29 CET] <omerjerk> hey so there is no read_seek2 implementation for matroska. [23:10:42 CET] <omerjerk> so I wanted to ask, how difficult it would be if plan to work on it? [23:10:49 CET] <omerjerk> also, will it be useful ? [23:10:58 CET] <nevcairiel> you should ask yourself if it will be useful [23:10:59 CET] <omerjerk> And how is it different from just read_seek ? [23:11:00 CET] <wm4> omerjerk: there's no need for it? [23:11:19 CET] <nevcairiel> why would you suggest working on it if you dont know if its useful :D [23:11:49 CET] <wm4> maybe he's using that "new" seek function that causes random trouble or so [23:11:55 CET] <omerjerk> I think it should be useful because everywhere in the code we first check if that implementation is available or not. [23:12:05 CET] <nevcairiel> it only causes trouble if you use it wrong, since its signature is different to the old one [23:12:13 CET] <wm4> omerjerk: there are dozens of such formats [23:12:17 CET] <nevcairiel> otherwise it just falls back to the old one [23:12:24 CET] <jkqxz> Something strange happens with mr[345]_tandberg_[bc]. Everything else passes with 20 + thread count surfaces available, they run out. [23:12:25 CET] <wm4> and why would more code be better than less code? [23:12:38 CET] <nevcairiel> and one if check in the seek function isnt overhead we worry about [23:12:47 CET] <wm4> jkqxz: mayba a leak? [23:12:48 CET] <nevcairiel> seeking is not something that happens every few milliseconds [23:12:58 CET] <omerjerk> okay. [23:14:46 CET] <jkqxz> Maybe this is baseline profile messing with me somehow. [23:16:57 CET] <jkqxz> Blah, they're all foreman. These people need more originality in test videos. [23:17:03 CET] <nevcairiel> hehe [23:17:28 CET] <nevcairiel> some of the hevc videos are random colored noise [23:17:40 CET] <nevcairiel> one of those had a checksum difference [23:17:50 CET] <nevcairiel> try to spot a difference in the image in random colored noise [23:26:09 CET] <jkqxz> Ah. The hwaccel decoder allocates surfaces to fill frame_num gaps. [23:26:44 CET] <jkqxz> These streams have big gaps in them. [23:27:03 CET] <nevcairiel> wouldnt that also happen with single threaded then [23:29:04 CET] <jkqxz> Yes, but it works because it never tries to allocate a frame which it actually wants to use before freeing the redundant ones in single-threaded. [23:31:19 CET] <jkqxz> (The log is full of "wtf disaster!" errors, but the output is correct.) [23:48:06 CET] <omerjerk> wm4: I actually started with the problem when I use the -se flag in ffmpeg. [23:48:20 CET] <omerjerk> I tested with a mkv file. [23:48:50 CET] <omerjerk> Even if I pass it 10 seconds, it only seeks to ~7.2 seconds. [23:49:06 CET] <omerjerk> I'm assuming, it is seeking to the nearest keyframe. [23:49:23 CET] <omerjerk> am I right ? [23:49:57 CET] <omerjerk> that's what the code looks to me at least. [23:50:44 CET] <nevcairiel> of course it does, it cant seek to anything else [23:50:52 CET] <nevcairiel> you wouldnt be able to start decoding at anything but a keyframe [23:52:23 CET] <omerjerk> okay [23:58:54 CET] <kierank> Timothy_Gu: you should write cfhd asm :) [23:59:06 CET] <kierank> you'd get huge speed boosts [00:00:00 CET] --- Tue Feb 9 2016

1 0

ffmpeg.log.20160208
by burek 09 Feb '16

09 Feb '16

[01:33:52 CET] <jleclanche> OT: does anyone know an audio-only container format that can have subtitles? [01:53:15 CET] <J_Darnley> mp3 and some karaoke hack [01:53:28 CET] <furq> depends what you mean by audio-only [01:53:38 CET] <furq> m4a can contain subtitles but it can also contain video [01:54:08 CET] <J_Darnley> furq: how is it that we always turn up in unison? [01:54:20 CET] <furq> i'm stalking you [01:56:18 CET] <furq> do you remember the other day when you received that package full of headless barbie dolls covered in dried blood and wrapped in barbed wire [01:56:23 CET] <furq> that was from me <3 [01:56:34 CET] <J_Darnley> ah [01:56:37 CET] <J_Darnley> that was fun [01:56:50 CET] <furq> it wasn't my blood though. i'm not stupid [02:01:00 CET] <TD-Linux> furq, oops! thanks for the protip for next time [03:15:00 CET] <votz> How can seek (-ss) come before piped input? 'cat foo.mp4 | ffmpeg -ss 0 -i - -c:copy out.mp4' fails, while both 'ffmpeg -ss 0 -i foo.mp4 -c:copy out.mp4' (seek from file) and 'cat foo.mp4 | ffmpeg -i - -c:copy out.mp4' (pipe no seek) succeed. foo.mp4's moov atom is at the head of the file. [03:15:33 CET] <votz> JEEB: ping (re: acvonv 11.4 vs ffmpeg keyframe behavior) [11:45:29 CET] <tp_> ofcourse it will fail, or be very slow seeking atleast [11:46:51 CET] <tp_> try using -ss after '-i -' [12:20:31 CET] <markvandenborre> pzich: thx for you reply to my webm live stream encoding [12:20:39 CET] <markvandenborre> I did google before [13:13:23 CET] <Ccdc_DuckZ> hello, I have single frames saved as jpg or png in a directory and I have to create an animated gif out of those - I followed the video_encode_example() function and I think I have most of the code up [13:15:16 CET] <Ccdc_DuckZ> I'm still missing the part where I fill the frame->data part, and I'm wondering if I can avoid doing the jpg/png decoding myself, any ideas? can ffmpeg do that itself? I found this http://stackoverflow.com/questions/3527584/ffmpeg-jpeg-file-to-avframe but maybe it's outdated? because I can't find av_open_input_file in the docs [13:39:37 CET] <Ccdc_DuckZ> this guy https://ffmpeg.org/pipermail/libav-user/2011-July/000428.html also uses the same function... what am I missing? [13:41:34 CET] <Mavrik> Ccdc_DuckZ, yes, just initialize a JPEG/PNG decoder like you would any other [13:41:43 CET] <Mavrik> see decode_example. [13:44:32 CET] <Ccdc_DuckZ> Mavrik: ok, thanks [13:45:13 CET] <Ccdc_DuckZ> Mavrik: and I'm guessing I also have to build with enable-decoder=png and enable-decoder=??? [13:45:45 CET] <Ccdc_DuckZ> jpeg2000? mjpeg? libopenjpeg? [13:47:02 CET] <Mavrik> iirc mjpeg handles all jpeg decoding [13:47:07 CET] <Mavrik> jpeg2000 is a different format. [13:49:54 CET] <Ccdc_DuckZ> great, I'll try to implement all that, thanks! :) [14:32:55 CET] <DHE> I have a video being processed (live source) and some kind of error has caused the AC3 decoder to just go haywire and stop processing audio. It just produces some kind of tone now. Is there a way to reset the decoder on-the-fly? (code modifications are okay) [15:44:33 CET] <mk1> hello there. I'm trying to get the exact time of an intra frame (h264) using ffprobe -read_intervals 119%#1. This usually worked but one video returns an empty array instead of the I-frame [15:44:51 CET] <mk1> ffprobe -print_format json -select_streams v:0 -show_frames -read_intervals 119%+#1 test.avi [15:44:56 CET] <mk1> any ideas/pointers? [16:27:07 CET] <termos> is there a way to extract the encoding level in the C API? I keep getting -99 value from AVCodecContext::level for some reason, even after the codec is opened [16:27:30 CET] <JEEB> that's probably an encoding-only value [16:27:47 CET] <JEEB> I don't think such format-specific information is stored in the generic avcodec stuff [16:29:59 CET] <termos> yes I want the x264 level of the profile I'm using [16:30:27 CET] <termos> I see it being printed in the FFmpeg output as "profile Main, level 3.1" but I don't know how to get that 3.1 value in code [16:30:48 CET] <JEEB> see what ffmpeg.c is doing? [16:30:53 CET] <JEEB> or whatever part is printing that stuff :) [16:31:04 CET] <JEEB> and it's not x264, but AVC or H.264 [16:31:08 CET] <JEEB> x264 is the encoder [16:32:07 CET] <termos> yes but this is the encoder output, I'm setting main profile and no level so it seems to default to 3.1 in this case [16:32:41 CET] <termos> the input is in High profile, also h264 [16:33:04 CET] <JEEB> libx264 sets the profile and level to the lowest one your settings and content match [16:38:33 CET] <termos> do you know how I can read out the level that libx264 set? [16:44:34 CET] <DHE> levels are about decoder capabilities. you'd need to analyze the video in terms of number of reference frames (at least) to measure what a video's level is [16:45:14 CET] <DHE> you're supposed to specify the level capability of your decoder and x264 will adjust your encoder settings to meet the requirements [16:52:55 CET] <termos> ah I see [16:55:02 CET] <DHE> same thing for the profiles. "baseline" means a number of things like "no b-frame support". x264 will tweak your settings if you're in violation if you specify "-profile:v baseline" but if you just happen to input baseline-compatible settings, all is fine [16:55:13 CET] <termos> I still can not figure out how FFmpeg arrives at some level value or how to get it out of the C API. I guess I need to read the source to see how it's printed [16:55:59 CET] <termos> or I'm guessing it's libx264 that arrives at some level value [16:57:31 CET] <DHE> there is a table of levels in the x264 source, sorted by decoder capability. x264 goes through the list looking for the first match that meets the encoder settings [16:57:59 CET] <DHE> the reverse is used when you specify a level parameter - the table is consulted to see the limits, then your reference frames are lowered to meet the calculated limit [16:58:46 CET] <DHE> https://en.wikipedia.org/wiki/H.264/MPEG-4_AVC#Levels Human-readable table [17:03:16 CET] <termos> okey I see, thanks. I found out where the level string is generated, it's generated like this: snprintf( level, sizeof(level), "%d.%d", h->sps->i_level_idc/10, h->sps->i_level_idc%10 ); [17:03:50 CET] <termos> seems to be based on some index in the table you are talking about [17:04:33 CET] <Bluez_> hi guys [17:05:04 CET] <Bluez_> does anyone know of a concise example on how to put raw h264 and raw AAC frames in to a container without re-encoding etc? [17:06:23 CET] <termos> the thing I want to do is to generate the CODECS attribute for my HLS playlists as explained in the table under #11 here: https://developer.apple.com/library/ios/documentation/NetworkingInternet/Co… [17:07:27 CET] <kepstin> termos: easiest way? pick a profile that's the highest your encoder will ever output, then statically put that in the CODECS attribute [17:07:59 CET] <kepstin> profile/level [17:08:39 CET] <termos> I have some constrained baseline level 1.2 encodings as well, I guess that will make those unplayable on most of it's intended devices [17:09:20 CET] <DHE> what devices? even modern iphones will do a lot better than that. baseline at such a low level shouldn't be a big deal these days [17:11:32 CET] <termos> we've had complaints from customers from africa as well as eastern europe with some really shitty cell phones [17:16:23 CET] <kepstin> well, if you're encoding to a specific level, then you're passing options to x264 to set that level, so you already know what it is and don't really need to pull it out afterwards... [17:17:07 CET] <DHE> agreed. if you have known limits, tell x264 what they are and it will conform to it [17:17:10 CET] <kepstin> I guess the only case where you might need to find it out is if you have some old pre-encoded files that you don't know what profile/level they fit in. [17:18:15 CET] <DHE> if it's encoded with x264 then you can usually use 'strings' on the file and find the encoding settings out of the video fairly easily [17:18:21 CET] <termos> hm that's a good point, we don't set the level now it's just calculated by x264 based on I guess resolution and bitrate etc. [17:21:37 CET] <termos> would still be nice to know what level it's setting as it's the minimal the stream fits in [17:23:20 CET] <DHE> just try the strings thing [17:45:49 CET] <Che-Anarc> Are stdout references to 'Audio:' omitted from 'Metadata' output with files / content that do not have an audio stream? [17:54:36 CET] <Che-Anarc> It would seem so ... just tried it with a couple of files. [18:40:44 CET] <andrey_utkin> why ffmpeg-created MPEG TS files always have start_time ~1.46s, which is not possible to shift to 0 even with "-avoid_negative_ts make_zero" ? [18:53:44 CET] <ac_slater> hey all. When I mux h264 to mpegts and stream over udp, the video briefly freezes *every second* when playing with any ffmpeg based decoder (mpv, ffplay) and VLC. The log on the player says that H.264 does not have RBSP. Would this be doing it? [18:54:23 CET] <ac_slater> my command line is `ffmpeg -i test.h264 -f mpegts udp://127.0.0.1:9999` ... when test.h264 was encoded with libx264 some time ago [18:54:53 CET] <BtbN> don't use raw h264 if you can avoid it. [18:55:49 CET] <ac_slater> BtbN: what if my source is the output of an h264 encoder? Should I still mux the input to a container? [18:56:58 CET] <BtbN> What h264 encoder is there that's not part of ffmpeg which outputs raw h264? [18:57:45 CET] <ac_slater> BtbN: I'm creating out. The issue I mentioned regarding the mpegts streaming skipping happens with all of the h264 encoders I can find (vdpau, libx264, and my own) [18:57:50 CET] <ac_slater> I'm creating one * [18:58:33 CET] <ac_slater> my issues, I believe, are either with the mpegts muxer, or ffmpeg's udp output [18:58:42 CET] <BtbN> could be almost everything. Package loss, missing extradata, .. [18:59:02 CET] <ac_slater> BtbN: this is localhost, which on linux promises no loss [18:59:30 CET] <BtbN> so that also happens if you encode or stream copy with ffmpeg itself? [18:59:41 CET] <DHE> still not promised. the UDP buffer could potentially still overflow [18:59:42 CET] <andrey_utkin> ac_slater: is RTP packetization an option? [18:59:57 CET] <ac_slater> BtbN: yes [19:00:17 CET] <ac_slater> DHE: I'm forcing packet size smaller than loopback's MTU [19:00:28 CET] <ac_slater> andrey_utkin: the freeze/skip even happens with RTP [19:00:38 CET] <BtbN> try tcp, if that works, your UDP setup is the issue [19:01:29 CET] <andrey_utkin> ac_slater: how do you catch the stream? with ffmpeg/ffplay? [19:01:41 CET] <DHE> ac_slater: got nothing to do with it. if the receiver process doesn't recv() packets fast enough then your udp socket will drop packets. the advantage is these are counted [19:01:47 CET] <andrey_utkin> you should try increasing receiving buffer [19:02:05 CET] <andrey_utkin> there are two options about that for udp [19:02:07 CET] <ac_slater> DHE: that is true [19:02:18 CET] <ac_slater> DHE: the video bitrate is 500kbit/s [19:02:49 CET] <ac_slater> actually I've made an important observation [19:03:08 CET] <ac_slater> with ffplay, either streaming or local file, I get the skipping every one second on the dot [19:03:28 CET] <ac_slater> with mpv, it prints out "Invalid video Timestamp" every second on the dot but plays smoothly [19:03:50 CET] <ac_slater> do I need +genpts? [19:07:05 CET] <andrey_utkin> ac_slater: i'd looked at http://ffmpeg.org/ffmpeg-protocols.html#udp and added this to receiving side before -i: -buffer_size 10000000 -fifo_size 100000 [19:07:18 CET] <DHE> raw h264 has no timestamps [19:07:19 CET] <ac_slater> andrey_utkin: I'll try it, thanks mate [19:07:30 CET] <ac_slater> DHE: but mpegts does [19:29:56 CET] <ac_slater> So, I guess I'm not generating correct timestamps for the mpegts muxer [19:30:07 CET] <ac_slater> not sure how, but the mpegts demuxer is the thing that's freezing/pausing [19:31:11 CET] <andrey_utkin> ac_slater: drop us a pair of ffmpeg commands which reproduce your issue, if you can [19:31:57 CET] <andrey_utkin> sorry, gotta go offline for few minutes [19:32:34 CET] <ac_slater> andrey_utkin: will do, and a test file [19:32:36 CET] <ac_slater> thanks all [19:37:00 CET] <andrey_utkin> ac_slater: best if you achieve generation of test media file/stream with ffmpeg itself :) [19:37:20 CET] <ac_slater> exactly, lavfi testsrc is what I try to replicate with [19:43:09 CET] <kbarry> Is it possitle to produce the visualization thats seen in ffplay, but faster than real-time [19:44:40 CET] <kbarry> IE, i have a 10 second clip, would like to produce what the waveform/visual would look like had I played it in real-time [19:44:52 CET] <andrey_utkin> so does anybody have an idea why MPEG TSes always have start_time 1.46s? [19:47:16 CET] <andrey_utkin> kbarry: http://ffmpeg.org/ffmpeg-filters.html#showwaves ? [19:51:24 CET] <ac_slater> audrey_utkin: it looks like my encoder is causing it. Doing `ffmpeg -f lavfi -i testsrc ... -c:v libx264 .... -f mpegts udp://....` works wonderfully. when `-c:v myh264encoder` ... things get hairy [20:16:23 CET] <ac_slater> Dan, [20:16:25 CET] <ac_slater> ooops [20:41:55 CET] <andrey_utkin> answering myself. "-mpegts_copyts 1" avoids delay. Still unclear why is it here by default - no comments in code or doc [21:31:58 CET] <kbarry> andrey_utkin Thanks for the link. I tried that but didnt get what i expected. When I use "ffplay" the default visual (i don't know what its called) that is what i want to produce. [21:33:03 CET] <durandal_1707> kbarry: showspectrum? [21:33:16 CET] <durandal_1707> i mean filter of that name [21:36:45 CET] <kbarry> So, in ffplay, i ca generate what i am experiencing as the "default output" using "ffplay -i input.mp3 -showmode 2" [21:38:26 CET] <andrey_utkin> 2, rdft -- show audio frequency band using RDFT ((Inverse) Real Discrete Fourier Transform) [21:39:40 CET] <kbarry> right, [21:39:49 CET] <kbarry> just trying to figure out how to do that with ffmpeg [21:39:51 CET] <andrey_utkin> looks that's not a filter [21:40:00 CET] <andrey_utkin> it's coded right in ffplay.c [21:42:50 CET] <kbarry> https://trac.ffmpeg.org/wiki/FancyFilteringExamples [21:43:33 CET] <C0nundrum> WHats the best way to capture an m3u8 stream ? [21:44:00 CET] <kbarry> C)nundrum its HLS, You are trying to record it? [21:44:50 CET] <C0nundrum> I'm recording to a browser playable format what i use is ffmpeg -i "http://sourcemedia.com:1935/live-origin/67b88_aac/playlist.m3u8" -vcodec copy -acodec copy -bsf:a aac_adtstoasc -f mp4 "E:\capture 2-8-2016 3.25 PM.mp4" [21:45:59 CET] <C0nundrum> the problem that i have is 1.ffmpeg doesn't seem to try to reconnect and i end up with alot of 30sec-1min recordings 2. if it is iterrupted, the whole file is useless. 3.when playing in browser there are parts where the time keep moving but the image is still. [21:46:21 CET] <C0nundrum> I tried recording using flv to avoid the broken vidoes if iterruped but i end up with video and no sound [21:47:00 CET] <DHE> why not use hls.js ? [21:47:33 CET] <C0nundrum> also btw i'm not live streaming just save a stream to disk [21:49:12 CET] <C0nundrum> ffprobe shows the input as http://i.imgur.com/H8Yvk2s.png [21:49:25 CET] <C0nundrum> any ideas for solve any of these problems ? [21:49:30 CET] <C0nundrum> solving* [21:53:55 CET] <durandal_1707> kbarry: its showspectrum filter [21:54:47 CET] <kbarry> durandal_1707: I'm getting an error (lemme paste) [21:55:23 CET] <C0nundrum> kbarry ? [21:55:40 CET] <C0nundrum> are there any connection settings for ffmpeg [21:55:47 CET] <C0nundrum> like for reconnects [21:56:07 CET] <kbarry> C0nundrum: I'm kinda new to ffmpeg myself [21:56:22 CET] <kbarry> IF yo play it in ffplay, do you end up with disconnectivity? [21:56:35 CET] <kbarry> durandal_1707 http://pastebin.com/ZCLPRHBq [21:56:58 CET] <kbarry> I am probably using bad syntax, [21:57:03 CET] <kbarry> And just don't know it [21:57:48 CET] <durandal_1707> kbarry: showspectrum returns video [21:58:05 CET] <durandal_1707> kbarry: if you want picture use showspectrumpic, but you need recent ffmpeg [21:58:46 CET] <durandal_1707> by default showspectrumpic use different options, it shows axes and such [21:59:16 CET] <kbarry> Hmmm. [21:59:47 CET] <kbarry> I'm getting [21:59:50 CET] <kbarry> "no such filter" [22:00:01 CET] <durandal_1707> kbarry: you need newer ffmpeg [22:00:18 CET] <kbarry> Lemme change subjects for a moment, [22:00:29 CET] <kbarry> I don't seem to understand the outpuit from ffmpeg -version [22:01:14 CET] <durandal_1707> kbarry: showspectrumpic was added in last day of 2015 year [22:02:40 CET] <kbarry> ok, updating [22:19:58 CET] <explodes> Any tips as to why repeatedly seeking (5 times per second) would lag? It's either my code, or something with av_seek_frame... [22:31:47 CET] <Rnuomer> hey~ I've looked all over the first page of a google search results and I can't find out if there's a way to capture just one x11 window even if it goes behind another window or moves? [23:28:45 CET] <derekprestegard> hello, if I want to convert a sequence of standard full range (0-255) sRGB JPEGs into a video using full range bt709, how can I do this? sRGB is very similar to bt709 except the gamma is a bit different. Is there a filter that can do this conversion? [23:31:10 CET] <andrey_utkin> derekprestegard: maybe try -filter:v filter=pix_fmts=bt709 [23:31:21 CET] <andrey_utkin> oops [23:31:31 CET] <andrey_utkin> -filter:v format=pix_fmts=bt709 [23:32:23 CET] <derekprestegard> pretty sure bt709 isnt a pixel format? [23:32:29 CET] <kepstin> derekprestegard: as far as I know, the ffmpeg command line tool should be automatically adding filters to perform any needed color space conversions. [23:32:30 CET] <derekprestegard> the pixel format in the output video would be yuv420p [23:32:54 CET] <c_14> derekprestegard: use the zscale filter [23:32:56 CET] <derekprestegard> okay [23:33:47 CET] <derekprestegard> c_14: whats the benefit of this? [23:36:17 CET] <c_14> zscale/z.img was built to correctly scale/transform whereas swscale was built to do it quickly [23:38:38 CET] <derekprestegard> c_14: interesting, I take it this is an ffmpeg patch and not included in official builds. Any word on where I can get a precompiled build so I can mess around without building a windows or mac binary? [23:41:11 CET] <derekprestegard> nm looks like the zeranoe builds have this included :D [00:00:00 CET] --- Tue Feb 9 2016

1 0

ffmpeg-devel.log.20160207
by burek 08 Feb '16

08 Feb '16

[00:18:54 CET] <kierank> michaelni: why is GBRAP16 not mentioned in libavcodec/utils.c? [00:32:38 CET] <michaelni> likely forgotten [00:36:27 CET] <kierank> ... [00:37:55 CET] <kierank> michaelni: same question as to why there's no to_a function for gbrap16 in swscale? [00:42:28 CET] <BBB> I belive in general we dont have 16bpp output, just input, in swscale [00:43:29 CET] <kierank> BBB: should have said in libswscale/input.c [00:43:52 CET] <BBB> oh ok [00:47:34 CET] <wm4> BBB: uh, there's 16 bit yuv output [00:48:07 CET] <BBB> really? oh, ok, I stand corrected then [01:02:09 CET] <andrey_utkin> i have posted a kind of survey about email tools to LKML, I'd like to know opinion of FFmpeg developers, too: http://marc.info/?l=linux-kernel&m=145480282311605&w=2 [01:02:35 CET] <andrey_utkin> how do you look at posting this on ffmpeg-devel, while it is 100% offtopic? [01:04:32 CET] <andrey_utkin> and where else I could ask to get replies relevant to my personal issues with email? [01:04:54 CET] <J_Darnley> I am satisfied with my combination of gmail and thunderbird [01:05:13 CET] <J_Darnley> but then ffmpeg-devel is the busiest list I'm on [01:06:03 CET] <Gramner> I'm not subscribed to the lkml but I can imagine the volume there being _slightly_ larger than ffmpeg-devel [01:06:07 CET] <J_Darnley> If you are not already using gmail's filters, you should use them to filter mail by list [01:06:32 CET] <andrey_utkin> yep I love how gmail got maillists filtering [01:06:39 CET] <J_Darnley> In Gmail's terms: apply label and skip inbox [01:06:48 CET] <andrey_utkin> but see about git-send-email in my posting [01:07:08 CET] <J_Darnley> I'm afraid I abuse my ISP's smtp server for that [01:08:50 CET] <andrey_utkin> and you never had issues as you read email on gmail and sending patches NOT from gmail? well, i guess it's possible, just may confuse your peers, they'd need to recognize that your two email addresses belong to same identity [01:08:50 CET] <J_Darnley> Sorry I wasn't very helpful [01:08:54 CET] <Gramner> I'm using gmail with a custom domain, works decently enough [01:10:46 CET] <J_Darnley> Well I don't send email with a "From:" address of telenet.be. I just lie and say gmail.com. I duid use the verb "abuse" [01:10:57 CET] <J_Darnley> *did [01:11:29 CET] Action: J_Darnley wonder what his gitconfig says [01:12:11 CET] <J_Darnley> No authentication at all [01:13:18 CET] <andrey_utkin> haha [01:13:46 CET] <Gramner> sounds legit [01:14:05 CET] <cone-678> ffmpeg 03Michael Niedermayer 07master:2272ab0e84de: avformat/mp3enc: Assert that the header we assembled is valid [01:14:06 CET] <cone-678> ffmpeg 03Michael Niedermayer 07master:9ee4c89348c5: avcodec/utils: Add AV_PIX_FMT_GBRAP16?E to avcodec_align_dimensions2() [01:14:18 CET] <andrey_utkin> but at some moment some maillist servers could begin to require DKIM and such. Or your provider could fix that hole (god forbid) [01:15:03 CET] <J_Darnley> Sure. I don't know what I would do when that happens. [01:15:53 CET] <Gramner> doesn't dkim/spf fail hard with mailing lists? [01:16:07 CET] <BBB> andrey_utkin: I use gmail, and git send-email works for me [01:16:28 CET] <Gramner> since the mailing list will resend the message from a different server while sitll claiming to be from the original sender [01:16:29 CET] <BBB> andrey_utkin: I wouldnt say its great, but at least it can split basic threads [01:19:38 CET] <Gramner> I guess you could add the ML mailserver to the SPF list of approved hosts if you have your own domain, but that would be very annoying to keep up to date with several MLs [01:25:46 CET] <ubitux> Gramner: it's about 10 times larger iirc [01:26:06 CET] <Gramner> only 10? [01:26:13 CET] <andrey_utkin> Gramner: i believe DKIM signature will be added on SMTP server where sender's mailbox resides. DKIM signature is done over just selected headers, so relaying and adding more headers doesn't invalidate the signature [01:26:50 CET] <ubitux> Gramner: 5 to 10 last time i checked, but ff dev is like 1k to 2k mails per month, so& [01:27:52 CET] <Gramner> andrey_utkin: last time i tried enabling dkim/spf on my domain my ML posts got spam flagged (normal direct emails worked correctly) [01:29:30 CET] <ubitux> Gramner: last five months, ff:2310,1927,1660,2698,1699 - lklm:7225,5112,6899,4533,2203 [01:29:36 CET] <Gramner> apparently there's some X-Original-Authentication-Results header related to that [01:33:00 CET] <Gramner> ubitux: oh, not that overwhelming then [01:33:12 CET] <andrey_utkin> ... and lkml is just one of many maillists related to kernel. there are more - linux-media, linux-arm-kernel, netdev, driverdev.linuxdriverproject.org... [01:38:01 CET] <andrey_utkin> J_Darnley: regarding filtering maillists out of inbox, do you have threads that mention you in recipients in your inbox? I don't and it's a problem for me :( Any advise? [01:39:07 CET] <J_Darnley> No. They get "labeled and skip inbox". In thunderbird they appear in a different folder [01:39:55 CET] <J_Darnley> Unless someone emails me directly and then the email doesn't get a List-Id header [01:40:09 CET] <J_Darnley> Cc can do that [01:40:27 CET] <J_Darnley> so I don't usually Cc myself [01:41:20 CET] <andrey_utkin> it's a problem because I occasionally there are threads which are sent to maillist + CC to me (at once) because I am maintainer of something. So my reaction is expected, but I miss that completely because the letter skips inbox [01:41:48 CET] <andrey_utkin> CC to maintainers at once with posting to maillists is common on LKML [01:41:56 CET] <J_Darnley> Ah. I can't say what happens in that regard. [01:42:24 CET] <andrey_utkin> I can - it still skips inbox :) [01:43:00 CET] <andrey_utkin> maybe some additional filtering rule may fix that [01:43:23 CET] <J_Darnley> Do you want me to login and check exactly what my rules are? [01:43:26 CET] <andrey_utkin> but may break everything else if applied in generic way [01:43:31 CET] <andrey_utkin> no [01:44:01 CET] <andrey_utkin> just was curious to know if you know this issue and have solved it in a good way [01:44:35 CET] <J_Darnley> Sorry, I don't. [01:44:35 CET] <andrey_utkin> i guess your rules are what gmail itself suggests - it suggests to filter basing on List-Id [01:44:51 CET] <andrey_utkin> np, thanks to all of you for your keen feedback [02:04:32 CET] <kierank> hmm i need some premiere pro cineform samples [02:34:40 CET] <andrey_utkin> so far, I've got two replies from mutt-ers, one of them being Greg KH, who recommended "to take a week or two to learn mutt". [08:59:40 CET] <nevcairiel> andrey_utkin: i have no problems with gmail and send-email, no delays whatsoever, so maybe its on your end : D [09:26:13 CET] <andrey_utkin> nevcairiel: i have evidence that I'm not the only one experiencing it [09:26:26 CET] <andrey_utkin> https://lkml.org/lkml/2016/1/3/148 [09:26:59 CET] <nevcairiel> might be some other common component, like sendmail which I think git uses? [11:39:49 CET] <durandal11707> Daemon404: are you using fieldhint? [12:52:52 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:f5c3f85eb25c: avfilter: add swaprect filter [13:08:57 CET] <Daemon404> durandal_1707, ? [13:10:09 CET] <durandal_1707> Daemon404: the avs/vs filter [13:12:05 CET] <Daemon404> i used the avs one quite heavily, but i have not had to perform ivtc in quite some time [13:12:13 CET] <Daemon404> years even [13:14:11 CET] <durandal_1707> i'm wondering about this ovr file which is used by fieldhint, in reality are fields really so far way, even by 42 frames in past of future? [13:17:24 CET] <Daemon404> that sounds a bit funny, but the ovr file is useful for when it gets the pattern wrong [13:17:37 CET] <Daemon404> i always used it for manually adjusting field match errors [13:17:48 CET] <Daemon404> it's a heuristic after all. [13:18:44 CET] <durandal_1707> lavfi doesn't really have support for picking random frame from stream [13:19:55 CET] <Daemon404> it can keep a count im sure... [13:19:59 CET] <Daemon404> in order to consume such a file [13:20:14 CET] <Daemon404> but yes lavfi is not very good at anything but streaming. [13:21:00 CET] <Daemon404> im not sure an ovr file could work at all without some sort of frame number info [15:52:06 CET] <cone-761> ffmpeg 03Clément BSsch 07master:6c0318c4ba8e: lavfi/fieldmatch: fix fields copy when plane height is odd [16:28:55 CET] <ubitux> wm4: it makes me wonder, should i actually reset the readorder on flush at all? [16:29:32 CET] <ubitux> like, you don't need it, but in most cases, assuming the user flushes the ass context, does it even need to have a reset counter to zero? [16:29:34 CET] <wm4> ubitux: that's a good question, I don't know in what other scenarios it could be needed [16:30:09 CET] <wm4> actually, _if_ the user flushes the ass_track, then resetting to zero would be better [16:30:19 CET] <wm4> because libass uses a bitmap to check for readorder duplicates [16:30:24 CET] <wm4> it's all fucked up [16:30:39 CET] <ubitux> a bitmap? [16:30:58 CET] <ubitux> it's doing a crc on the rendered sub and compare them? :D [16:31:46 CET] <wm4> no, the ReadOrder value is used as index into a bitmap [16:32:29 CET] <wm4> since ReadOrder values normally start at 0 or 1 and don't skip numbers, it's the most efficient way to do it [16:34:52 CET] <ubitux> ok so we don't want that readorder to grow too much [16:35:16 CET] <ubitux> and there is no notion of "first readorder occured [post seek]" [16:35:35 CET] <wm4> I guess I don't mind much if your change will pick either behavior and makes it not configurable [16:35:59 CET] <wm4> I've also added an API function to libass that completely disables the ReadOrder check [16:36:18 CET] <ubitux> i'm just wondering about what solution to follow [16:37:17 CET] <wm4> for my own purposes, not resetting ReadOrder would be most useful for now, but I'm not sure at all about the general API user [16:37:23 CET] <ubitux> one solution would be to add a packet side data, and let the demuxer set that readorder [16:37:31 CET] <wm4> (or what I'll do in future in mpv too) [16:37:47 CET] <ubitux> so the decoder could read it back and use it in the dialogue [16:38:02 CET] <ubitux> that could would work with at least all standalone subtitles demuxers [16:38:43 CET] <ubitux> as well as any demuxer supporting ass (where we can simply read the readorder and flag the packet with that info) [16:39:13 CET] <ubitux> ...but it won't work with many other, like, what's happening for text subtitles from ogg or whatever [16:39:33 CET] <wm4> what about ogg? [16:39:36 CET] <ubitux> so i actually need to something about the case where the readorder really is unknown [16:39:42 CET] <wm4> oh [16:39:43 CET] <ubitux> i picked ogg but could be any [16:42:00 CET] <wm4> maybe you could provide API to set ReadOrder explicitly (and the "decoder" would increment it after every packet) [16:42:40 CET] <wm4> and then make keeping ReadOrder after flush the default (not sure if sane?) [16:42:54 CET] <ubitux> a start_readorder avoption in the decoder? [16:43:53 CET] <ubitux> (and avcodec_flush_buffers would av_opt_set_int(d,"start_readorder",0,0) which you can override yourself after calling it?) [16:44:23 CET] <ubitux> (or simply a flag to not call it yeah) [16:45:24 CET] <wm4> can avoptions be set after a decoder was opened? [16:45:55 CET] <ubitux> i guess so [16:46:52 CET] <kierank> I believe yes [17:02:15 CET] <wm4> you could argue that if someone encodes multiple segments from a source file, that seeking should not reset the readorder, but let it increment normally [17:02:25 CET] <wm4> (OTOH that doesn't work for codec copy anyway) [17:14:06 CET] <kierank> any ideas where I can find premiere pro cineform rgba 444 12-bit samples? [17:26:06 CET] <durandal_1707> kierank: buy it [17:26:23 CET] <kierank> lol no [17:27:29 CET] <kierank> durandal_1707: it's not a bug for mpeg2video to produce samples out of rage [17:27:32 CET] <kierank> range [17:27:39 CET] <kierank> this is the entire point of having limited range [17:27:44 CET] <kierank> to allow for things to go over and under a bit [17:27:48 CET] <kierank> instead of clipping [17:28:15 CET] <durandal_1707> but than its not broadcast safe [17:28:29 CET] <durandal_1707> rage even [17:28:30 CET] <kierank> yes so you clip at your output device [17:28:32 CET] <kierank> or whatever [17:28:41 CET] <kierank> but actually a little bit of overshoot is allowed [17:28:46 CET] <kierank> since it's not analogue any more [17:29:16 CET] <durandal_1707> its not overshot, there are pixels with 255 values and nothing inbetween [17:32:28 CET] <kierank> ? [17:37:00 CET] <durandal_1707> what's not clear? [17:52:14 CET] <wm4> everything [18:11:03 CET] <cone-761> ffmpeg 03Timothy Gu 07master:6cdde20beb98: dirac_dwt: Don't pass information in context as arguments [18:11:04 CET] <cone-761> ffmpeg 03Timothy Gu 07master:58ded09bd14e: dirac_dwt: Rename init2 to init [18:11:05 CET] <cone-761> ffmpeg 03Timothy Gu 07master:e04912c0b673: diracdec: Split DWTPlane struct from Plane [18:11:06 CET] <cone-761> ffmpeg 03Timothy Gu 07master:671761d71367: diracdec: Pass DWTPlane to dwt init [18:15:14 CET] <cone-761> ffmpeg 03Timothy Gu 07master:32fed702b8a4: libvpxenc: Allow setting tune parameter [18:19:59 CET] <cone-761> ffmpeg 03Timothy Gu 07master:59ebf32bca7e: huffyuvencdsp: Undefine "i" macro after each use [18:26:29 CET] <cone-761> ffmpeg 03Timothy Gu 07master:0bcffc792424: diractab: Fix header guard name [18:45:45 CET] <durandal_1707> ubitux: i dont think 8bit videos have enough dynamic so that this eurealian magnification can work [18:46:13 CET] <ubitux> afaik it does [18:47:17 CET] <durandal_1707> i dont see single difference with tblend in changes of color [18:47:48 CET] <durandal_1707> but i dont have static videos of someone's part of body [18:50:26 CET] <Daemon404> do you have a phone? and a face? [18:50:51 CET] <ubitux> durandal_1707: i remember a demo where a guy implemented it live with its webcam [18:52:51 CET] <durandal_1707> Daemon404: too much noise [18:53:35 CET] <ubitux> durandal_1707: https://www.youtube.com/watch?v=lZSTceTXjP4 with video source linked [18:56:23 CET] <ubitux> durandal_1707: actually, http://people.csail.mit.edu/mrub/evm/#code look for "data" below [18:56:28 CET] <ubitux> "source" [18:56:55 CET] <ubitux> many video sources here [19:21:09 CET] <durandal_1707> ubitux: only with this hand source sample its obvious when neckless move together with hand [19:50:35 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:ba618bde7f13: avfilter/vf_blend: add multiply128 mode [19:55:48 CET] <durandal_1707> ubitux: how much far away fields may be from one another with telecine material? [19:56:53 CET] <ubitux> just 1? [19:57:49 CET] <kierank> hahahah with ffmpeg you can't actually demux an mpegts determinisitcally [19:57:59 CET] <kierank> because it does probing and orders the streams as it sees them [19:59:05 CET] <durandal_1707> kierank: fix it [19:59:16 CET] <kierank> not possible because I'm sure it will break broken samples [19:59:19 CET] <JEEB> lol [19:59:35 CET] <wm4> kierank: what do you mean by this [19:59:36 CET] <kierank> the ffmpeg(tm) way is to have broken samples work ahead of 99% of usual things [19:59:41 CET] <JEEB> yeah, i thimk I've seen the results of that [19:59:46 CET] <kierank> wm4: if you have a video track with say 3 audio tracks [19:59:49 CET] <JEEB> @ mpegts [19:59:55 CET] <kierank> it'll order them by stream-id as it finds data [19:59:55 CET] <ubitux> honor a strict compliance flag [19:59:58 CET] <durandal_1707> kierank: ignore broken samples, I will back up you, I have body guards [19:59:59 CET] <kierank> not as how they are ordered [20:00:10 CET] <JEEB> ye [20:00:26 CET] <wm4> even if you order them as they come, wouldn't it depend when you start grabbing the infinite source stream? [20:00:45 CET] <kierank> no because it's listed in the PMT how you should order tehm [20:00:53 CET] <JEEB> yup [20:00:54 CET] <wm4> ok [20:01:04 CET] <kierank> but I guess ffmpeg wants to play files without PMT so it breaks everything to get those things to work [20:01:12 CET] <wm4> I don't understand how the sorting influences determinism though [20:01:42 CET] <kierank> -c:a:0 refers to a different track [20:01:55 CET] <kierank> depending on the packet which happens to arrive [20:02:03 CET] <kierank> so most likely it's the highest bitrate audio [20:02:12 CET] <kierank> so if it's eng, fra, ger [20:02:18 CET] <kierank> sometimes you get 0:fra, eng, ger [20:02:23 CET] <kierank> or sometimes 1:eng, fra, ger [20:02:25 CET] <kierank> or whatever [20:02:28 CET] <BtbN> maybe a second syntax, so you can explicitly specify you want pmt index 0? [20:02:30 CET] <wm4> that's why you should select them by their id, not index [20:04:05 CET] <JEEB> i think there also was a syntax for languagew [20:07:55 CET] <kierank> how do you select ffmpeg stream by pid [20:09:21 CET] <kierank> looks like on rtp streams you can't :( [20:40:33 CET] <cone-761> ffmpeg 03James Almer 07master:be22bd32fe43: x86/cpu: set avxslow cpuflag on btver2 CPUs [21:37:35 CET] <durandal_1707> michaelni: are you swscale maintainer? [21:55:20 CET] <durandal_1707> few MB script of only null filters [22:28:54 CET] <michaelni> durandal_1707, i try to review and test patches to swscale [22:30:02 CET] <durandal_1707> michaelni: the color range stuff is incorrectly exposed, so getting rid of J formats is impossible [22:35:04 CET] <michaelni> can you elaborate abut the problem ? [22:35:46 CET] <durandal_1707> michaelni: the color_range/matrix/colorspace etc are not handled by lavfi [22:36:21 CET] <durandal_1707> so even if frame have it set they are ignored by everything [22:38:15 CET] <michaelni> lavfi uses pix_fmts for choosing where to insert convert not range, IIRC yes [22:38:21 CET] <durandal_1707> this is good candidate for gsoc, stuff nobody wants to work on [22:38:34 CET] <michaelni> i wont mentor this [22:38:51 CET] <Daemon404> "stuff nobody wants to work on" is a great candidate for gsoc? [22:38:55 CET] <Daemon404> no wonder the studenst all leave after. [22:39:05 CET] <kierank> yes that's the problem [22:39:08 CET] <durandal_1707> i already know you are not gointg to mentor anything IIRC [22:39:12 CET] <kierank> the gsoc page needs an rm -rf [22:39:16 CET] <kierank> and a restart with fresh new ideas [22:39:20 CET] <michaelni> i am happy to mentor clear, self contained well deliniated work not fix & redesign apis [22:39:54 CET] <Daemon404> +1 [22:40:15 CET] <durandal_1707> than swscale will bitrot [22:40:40 CET] <kierank> good [22:41:03 CET] <Daemon404> stuff that requires a lot of thought into design is a bad choice for a student [22:41:14 CET] <Daemon404> thats how we ended up with some bad apis before [22:43:30 CET] <nevcairiel> yeah one should have a bit of experience to tackle core problems like API design [22:49:35 CET] <durandal_1707> if I add color range/color space negotiation to lavfi, will it be rejected because libav is missing it? [22:49:53 CET] <Daemon404> ask wm4, he is basically the only user [22:49:59 CET] <Daemon404> that uses both [22:50:15 CET] <Daemon404> libav / ffmpeg's lavfi that is [22:50:20 CET] <cone-761> ffmpeg 03Paul B Mahol 07master:6bdeac24e07e: avfilter/af_aformat: remove deprecated syntax from options description [22:51:21 CET] <jamrial|2> kierank: a bunch of the gsoc 2015 projects are already done and commited, so it's not like the 2016 one would end up being the same [22:51:44 CET] <Daemon404> jamrial|2, and look how many of the students stuck around [22:51:55 CET] <nevcairiel> still a majority of those listed there have been listed for 5+ years and are just annoying things noone else wants to do [22:52:09 CET] <jamrial> true [22:52:09 CET] <durandal_1707> Daemon404: there is user that have 3MB script, no it is not vapoursynth [22:52:24 CET] <Daemon404> durandal_1707, it must be generated [22:52:32 CET] <Daemon404> writing 3mb by hand is insane [22:53:22 CET] <durandal_1707> its some drawbox usage, wonder what exactly [22:55:54 CET] <jamrial> Daemon404: atomnuker stuck around. one out of three or four isn't that bad [22:56:41 CET] <Daemon404> i think it's a record ;) [23:01:02 CET] <durandal_1707> whats about daala and dirac, why they are still not comitted? [23:07:45 CET] <atomnuker> no one's fully okayed the dirac encoder [23:08:28 CET] <durandal_1707> atomnuker: isn't patch missing file? [23:08:55 CET] <atomnuker> one of the patches to split the tables from the decoder, yes [23:09:07 CET] <atomnuker> but I did send a V2 which fixed that patch [23:12:49 CET] <durandal_1707> atomnuker: i dont see it, link? [23:15:57 CET] <atomnuker> durandal_1707: actually I forgot I pushed the V2 of that patch after michael LGTM'd it [23:16:12 CET] <atomnuker> so all that's left is the patch to add the encoder itself [23:17:04 CET] <atomnuker> which J_Darnley pointed out was find except that it was best to use ptrdiff_t for the strides, which I did change [23:22:42 CET] <atomnuker> speaking of which, J_Darnley, durandal_1707, I've sent a v3 of that patch to the ML [23:24:49 CET] <atomnuker> as for the Daala stuff, that might just into an effort to make an overengineered image format by me and whoever else's up to it [23:25:04 CET] <durandal_1707> you always shall vertically align AVCodec entries [23:25:24 CET] <jamrial> atomnuker: why are you calling it vc2 when the decoder is already called dirac? [23:25:48 CET] <atomnuker> VC-2 is a subset of Dirac [23:26:56 CET] <atomnuker> unless someone feels like extending the encoder with dirac only features (well, the only thing missing from VC-2 that's in dirac are P and B frames), then VC-2 seems more appropriate [23:27:36 CET] <atomnuker> (believe me, if anyone saw what the decoder does with P and B frames he'd probably run away screaming) [23:29:09 CET] <atomnuker> durandal_1707: what did you mean by that? AVCodec ff_vc2_encoder isn't aligned, but I can fix it when I'm merging it [23:30:47 CET] <omerjerk> hey I was looking at this code - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/utils.c#L2216 [23:31:19 CET] <omerjerk> Where would I find the implementation of read_seek for a particular format ? [23:33:02 CET] <durandal_1707> omerjerk: in the format source code [23:33:33 CET] <durandal_1707> atomnuker: bunch of whitespaces to make it look nice [23:34:13 CET] <omerjerk> I did have a look here - https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/matroska.c [23:35:03 CET] <omerjerk> but couldn't find it. [23:36:08 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:e7786959cc34: avfilter/vaf_spectrumsynth: Move "break" up [23:36:42 CET] <durandal_1707> omerjerk: matroskadec.c [23:37:22 CET] <omerjerk> oh. okay. makes sense. I should have thought of it. [23:37:43 CET] <omerjerk> thanks. [23:39:07 CET] <durandal_1707> Daemon404: lol, you must see this script, 'enable' spam [23:43:34 CET] <durandal_1707> this issue would be solved with luascript filter, only single filter would be in graph [23:45:03 CET] <durandal_1707> but better fix is to provide file for single filter to read params for each frame [23:46:04 CET] <durandal_1707> or more general filtergraph for each frame as single line in file [23:46:18 CET] <durandal_1707> for script filter idea [23:49:41 CET] <Timothy_Gu> jkqxz: what're your plans for VAAPI after the libav patches get merged? [23:50:53 CET] <Timothy_Gu> btw, FATE contains a grand total of 656245 runs for ~1000 different slots [23:53:00 CET] <Daemon404> durandal_1707, sounds a bit insane, yes... [00:00:00 CET] --- Mon Feb 8 2016

1 0

ffmpeg.log.20160207
by burek 08 Feb '16

08 Feb '16

[01:14:25 CET] <spidersgeorg> what are the parameters to adjust mpegts stream? I have specified anything yet the stream I'm seeing from using simply -f mpegts udp://127.0.0.1:1234 looks very low quality [01:20:31 CET] <spidersgeorg> I'm looking for a lossless way to stream over localhost to another application [01:21:44 CET] <tp_> -c copy [01:21:45 CET] <J_Darnley> If you *really* want lossless then you'd better ask for it. [01:24:47 CET] <spidersgeorg> @J_Darnley I'm afraid I don't understand [01:25:11 CET] <spidersgeorg> @tp_ does -c copy require outputting to a file? [01:26:45 CET] <spidersgeorg> I'm getting an error 'filtering and streamcopy cannot be used together' [01:27:08 CET] <tp_> then dont use filtering at the same time if you want lossless :) [01:27:39 CET] <spidersgeorg> makes sense haha [01:27:55 CET] <spidersgeorg> basically I'm opening my capture device deinterlacing and trying to send it to another application [01:29:06 CET] <spidersgeorg> is there a way to filter and stream without losing too much quality [01:29:26 CET] <J_Darnley> Encode at high quality, obviously [01:29:38 CET] <J_Darnley> Be more precise! [01:29:55 CET] <J_Darnley> What format are you trying out output? h264? [01:30:12 CET] <spidersgeorg> this is what I have right now [01:30:21 CET] <spidersgeorg> ffmpeg -f dshow -framerate 29.97 -i video="GV-USB2, Analog Capture" -top 1 -vf "separatefields, crop=644:224:40:8, scale=600:224:flags=bicubic, scale=600:448:flags=neighbor" -f mpegts udp://127.0.0.1:1234 [01:30:41 CET] <spidersgeorg> I'm trying to add it as a media source in open broadcaster [01:30:55 CET] <J_Darnley> OMFG! If you want to deinterlace the use a deinterlacer! [01:31:06 CET] <spidersgeorg> this does work but the quality loss is terrrible and I haven't even specified a bitrate or anything [01:31:21 CET] <J_Darnley> I'm not surprised it's shit [01:31:23 CET] <spidersgeorg> I'm also resizing it as well [01:31:37 CET] <J_Darnley> yadif is a deinterlacer [01:31:44 CET] <spidersgeorg> it looks perfect using ffplay [01:31:44 CET] <J_Darnley> deinterlace then scale [01:32:01 CET] <spidersgeorg> yadif doesn't work well I'm deinterlacing snes output [01:32:07 CET] <spidersgeorg> looks washy [01:32:33 CET] <J_Darnley> Now you say that! [01:32:44 CET] <J_Darnley> Then specify some encoding options [01:32:59 CET] <J_Darnley> I assume libx264 is used so: -crf 18 [01:34:51 CET] <spidersgeorg> getting 'past duration 0.xxxxxx is too large' spam [01:40:06 CET] <spidersgeorg> http://pastebin.com/X82w8WjP [01:41:11 CET] <spidersgeorg> I can let it run for a bit longer and copy the output if you'd like [01:43:59 CET] <DHE> if you don't specify defaults you get ~1 megabit mpeg2 video. and that looks like crap [01:44:39 CET] <spidersgeorg> ah ok [01:44:45 CET] <spidersgeorg> this sent my cpu through the roof [01:44:49 CET] <spidersgeorg> -codec:v libx264 -crf 0 -preset veryslow [01:45:09 CET] <spidersgeorg> which makes sense [01:45:32 CET] <spidersgeorg> how does a program normally output video to other applications [01:45:43 CET] <spidersgeorg> surely this is the worst way to go about doing it [01:45:44 CET] <tp_> try veryfast [01:45:47 CET] <spidersgeorg> but I don't know any other way [01:46:07 CET] <J_Darnley> oh lord mpeg2 [01:46:17 CET] <J_Darnley> -qscale 2 [01:46:40 CET] <DHE> try -crf 10 for nearly lossless but presentable bitrate [01:46:59 CET] <J_Darnley> Only if he was usinglibx264 [01:48:19 CET] <J_Darnley> I wouldn't try to "output to other applications" [01:48:48 CET] <spidersgeorg> what would you suggest [01:49:00 CET] <J_Darnley> What else are you trying to do? [01:49:12 CET] <spidersgeorg> amarectv is a popular solution that most people use to capture their older consoles but it sucks imo [01:49:30 CET] <J_Darnley> You've just captured with ffmpeg. [01:49:40 CET] <spidersgeorg> I'm trying to add my console as a source in obs [01:49:51 CET] <spidersgeorg> yes but I can't pipe ffmpeg to obs [01:50:23 CET] <J_Darnley> Isn't obs just ffmpeg with some more fancy features? Can't that capture from dshow? [01:51:22 CET] <spidersgeorg> you can add a media source by specifying a source like I'm trying to do udp://127.0.0.1 [01:51:50 CET] <spidersgeorg> or add a capture device but it doesn't support deinterlacing atm [01:51:57 CET] <spidersgeorg> and it's very limited [01:52:11 CET] <spidersgeorg> doesn't support the use of external filters [01:52:23 CET] <spidersgeorg> maybe if there was a way for ffmpeg to output to a virtual device [01:53:21 CET] <spidersgeorg> I guess I could just stream with ffmpeg by itself but how would I add window capture sources? [01:53:55 CET] <spidersgeorg> alongside my console capture I also capture my webcam and a few application windows [01:54:07 CET] <spidersgeorg> obs provides a gui for resizing and arranging everything [01:54:23 CET] <spidersgeorg> could all of this be done through ffmpeg? [01:56:00 CET] <J_Darnley> ffmpeg can do all of that. The fancy arranging will be hard though. [01:57:23 CET] <J_Darnley> capturing specific windows is hard on Windows I think [01:57:57 CET] <spidersgeorg> looks like you can capture the desktop but then I would need to somehow shift the source over to hide everything else I wouldn't want to show... [01:58:20 CET] <J_Darnley> input devices can be found here: http://ffmpeg.org/ffmpeg-devices.html [01:59:32 CET] <spidersgeorg> I could also just keep using obs and capture an ffplay window but it's playback is horrible [01:59:48 CET] <spidersgeorg> it drops a ton of frames I'm not sure if that's because I'm configuring something wrong [02:00:06 CET] <J_Darnley> it's probably just too slow [02:00:30 CET] <J_Darnley> continue with obs if it works for you [02:00:33 CET] <spidersgeorg> if obs uses ffmpeg to display my capture device how can it keep up? [02:01:21 CET] <spidersgeorg> can I allocate more priority to ffplay when capturing + filtering? [02:01:43 CET] <spidersgeorg> hardly uses any cpu when running atm [02:02:45 CET] <spidersgeorg> ffplay -f dshow -framerate 29.97 -i video="GV-USB2, Analog Capture" -top 1 -vf "separatefields, crop=644:224:40:8, scale=600:224:flags=bicubic, scale=600:448:flags=neighbor" [02:03:03 CET] <spidersgeorg> this displays everything nicely minus the dropping frames [02:03:24 CET] <spidersgeorg> I do get a warning that the data is not aligned and can lead to speedloss [02:09:01 CET] <caveat-> I'm trying to record audio from an application, following this https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplicationwhile… but when I do: mpv out.wav I get http://sprunge.us/TShH [02:09:47 CET] <J_Darnley> Blame mpv? [02:12:43 CET] <caveat-> J_Darnley: same thing using whatever player [02:13:05 CET] <J_Darnley> The blame your system? [02:13:18 CET] <J_Darnley> What does ffmpeg say aboutthe file? [02:14:18 CET] <jarainf> It's not the file [02:14:27 CET] <jarainf> mpv can't initialize the audio output [02:15:01 CET] <jarainf> You need to have jack installed and if I recall you also have to load the loopback module [02:15:23 CET] <jarainf> Did you do "modprobe snd-aloop pcm_substreams=1"? [02:15:45 CET] <caveat-> jarainf: yes [02:15:52 CET] <caveat-> and jack is installed [02:16:18 CET] <caveat-> jarainf: you mean ffprobe file.wav? http://sprunge.us/XbZO [02:16:30 CET] <caveat-> sorry, for J_Darnley [02:17:11 CET] <J_Darnley> Yeah. So what's wrong with the file? [02:17:15 CET] <J_Darnley> Nothing. [02:17:25 CET] <jarainf> ^this [02:17:33 CET] <jarainf> It's the .asoundrc [02:17:35 CET] <J_Darnley> You can't play it because your system seems to lack any audio outout. [02:17:51 CET] <caveat-> also, if I remove the .asoundrc file created for the recording using the loopback, I don't get that message anymore, the player starts, but it's mute [02:18:31 CET] <jarainf> did you overwrite an .asoundrc? [02:18:46 CET] <caveat-> no, no, with other audio files I have sound [02:19:04 CET] <jarainf> I still think you didn't execute the modprobe command [02:19:22 CET] <caveat-> just for the ones with sound recorded from applications using the loopback alsa device [02:19:30 CET] <jarainf> Well yes [02:19:36 CET] <jarainf> because your loopback isn't working [02:19:42 CET] <jarainf> probably [02:20:13 CET] <caveat-> lsmod | grep aloop http://sprunge.us/FRHE [02:20:49 CET] <jarainf> aplay -L output pls [02:21:13 CET] <caveat-> http://sprunge.us/GTZB [02:21:32 CET] <jarainf> and your .asoundrc/ [02:21:33 CET] <jarainf> ? [02:22:09 CET] <caveat-> jarainf: I have copy pasted from https://trac.ffmpeg.org/wiki/Capture/ALSA#Recordaudiofromanapplicationwhile… [02:22:22 CET] <caveat-> http://sprunge.us/MbER [02:22:27 CET] <jarainf> well [02:22:47 CET] <jarainf> you need to insert your audio device in pcm.output { } [02:23:15 CET] <jarainf> It may be "card Intel" [02:23:49 CET] <caveat-> jarainf: I get it from alsamixer? [02:23:51 CET] <debianuser> caveat-: You can collect and paste them all at once using alsa-info script: https://wiki.ubuntu.com/Audio/AlsaInfo (that dumps `aplay -l`, `aplay -L`, `cat /proc/asound/cards`, your mixer settings, etc.) Run it as a regular user, it doesn't need root. [02:24:04 CET] <jarainf> caveat-, that should work too [02:26:46 CET] <debianuser> (caveat-: also I'd suggested you a bit different dmix-based config: http://pastebin.com/B7iEKBwH, just replace "RealCardName" in lines 5 and 25 with the name of your card, you can see card names with `cat /proc/asound/cards`, the "Loopback" card should be there too) [02:29:14 CET] <caveat-> http://www.alsa-project.org/db/?f=605b2dd1f2dc5cf33d1649820e5a9a33e8a1dd48 [02:29:20 CET] <jarainf> I'd suggest not using Loopback at all :33333333333 [02:30:40 CET] <debianuser> caveat-: jarainf was right, your card is named "Intel". So you need to replace "card Headset" with "card Intel" in your config. [02:31:06 CET] <caveat-> jack is not running, if that matters [02:31:28 CET] <jarainf> debianuser, that's the first time I've ever seen anyone using the Intel Sound [02:31:39 CET] <jarainf> I'm genuinely surprised right now [02:32:36 CET] <debianuser> caveat-: Optionally you can use my config (they're based on the same idea, but mine uses dmix/dsnoop and allows multiple apps to play sound at the same time), where you'd need to replace "RealCardName" in lines 5 and 25 with the name "Intel". [02:33:05 CET] <debianuser> caveat-: Also, my config doesn't have "loopout" pcm, you need to append it: pcm.loopout { type plug; slave.pcm "dsnoop:Loopback,1" } Then your command should finally work. I hope! [02:35:13 CET] <debianuser> caveat-: If it still doesn't work - feel free to ask, we'll fix that! [02:37:07 CET] <caveat-> ok, thanks, I have to metabolize your suggestions [03:49:15 CET] <solrize> any idea what would cause "Unrecognized option 'headers'"? i found some slightly similar messages with web search that were related to missing modules [03:49:22 CET] <solrize> but this was just about an mp4 file [03:56:19 CET] <c_14> solrize: there is no such option? [03:56:44 CET] <solrize> i think it may be because i had networking turned off because of that bug a while ago [03:56:54 CET] <solrize> that's fixed now right? i'm recompiling with networking back on [03:57:41 CET] <solrize> the compile will take a couple more minutes [03:59:19 CET] <c_14> The HLS one? [04:00:20 CET] <solrize> c_14, not sure what HLS is, there was a security announcement a month or so ago that said recompile with --disable-network because of some vulnerability [04:01:18 CET] <solrize> hmm now it says https not found, recompile with openssl, but i used --enable-openssl. pastebin coming, sec [04:01:55 CET] <solrize> here's my current config command: http://lpaste.net/9190805150980112384 [04:02:36 CET] <c_14> Can you pastebin the config.log? [04:04:32 CET] <solrize> sec [04:05:25 CET] <solrize> um it's 300kb [04:05:32 CET] <solrize> 11000 lines [04:06:08 CET] <c_14> The first and last 50 lines should be enough [04:06:17 CET] <solrize> oh ok. or i can upload it to a web server [04:06:44 CET] <c_14> Might be better in case the openssl check is somewhere in the middle [04:08:17 CET] <solrize> http://lpaste.net/3470756646626525184 [04:08:28 CET] <solrize> oh hmm yeah i can search it [04:09:26 CET] <solrize> ok will try to upload it. i see several messages indicating openssl is there and no obvious errors [04:09:28 CET] <solrize> sec [04:10:26 CET] <c_14> Are you sure you're running the correct binary then? Check the version and compilation flags [04:14:56 CET] <solrize> hmm [04:15:42 CET] <solrize> i run ffmpeg --help and it doesn't show openssl [04:16:18 CET] <solrize> ffmpeg version N-78335-g9ee4c89 Copyright (c) 2000-2016 the FFmpeg developers [04:16:28 CET] <solrize> that's supposed to be from master as of about 20 minutes ago [04:17:34 CET] <c_14> That is the latest commit, yes [04:18:32 CET] <c_14> Can you upload the whole config.log? [04:22:31 CET] <solrize> yeah just a sec it's taking some messing around to do that but it's almost there [04:22:46 CET] <solrize> http://configlog.phr.fastmail.fm/config.log [04:24:35 CET] <c_14> It should definitely be there... make distclean and try again? [04:26:10 CET] <solrize> will try though i've done that several times... about 3 minutes to recompile, brb [04:30:00 CET] <solrize> hmm now openssl shows up in the help message [04:30:24 CET] <solrize> whoa it's working now, wonder what was wrong before... thanks! [04:31:46 CET] <solrize> might have gotten compiles and configs out of sync [04:37:00 CET] <solrize> hmm now i'm trying to transcode the mp4 to something smaller and i get a pile of messages like "Past duration 0.643990 too large" is there a way to get rid of that? i remember encountering that before and spending a while looking into it and not getting anywhere definite [04:37:59 CET] <solrize> oh i see a bunch of web hits, that say to ignore it. ok [10:17:30 CET] <dorp> When it comes to transcoding duration time, x264 with preset=ultrafast and qp=0, is supposed to be much more efficient than x265? [12:29:32 CET] <markvandenborre> hi! [12:30:10 CET] <markvandenborre> I have a pile of somewhat older quad socket hexacore servers with oozes of ram (512 Gb) [12:30:48 CET] <markvandenborre> I wonder if there would be a way to do live webm vp9 streaming from those [12:31:26 CET] <markvandenborre> in other words, is there a way to do multithreaded vp9 encoding for live streams using ffmpeg? [12:31:35 CET] <markvandenborre> any hints appreciated! [12:36:59 CET] <pzich> https://www.google.com/search?q=multithreaded+vp9+ffmpeg [12:37:03 CET] <pzich> looks like yes? maybe? [12:52:21 CET] <kolo> ffmpeg -i input.mp4 -vf subtitles=input.srt out.mp4 [12:54:13 CET] <kolo> https://up1.ca/#0JqnVoi7Bsf_-IAx-Fqc5g --> Is it possible to burn subtitles in the ~ middle of screen? [12:56:31 CET] <kolo> not possible?! [13:21:54 CET] <kolo> Is it possible to burn subtitles in the ~ middle of screen? [13:21:59 CET] <kolo> https://www.filepicker.io/api/file/BiG9VCYNThymE1OA6DlZ [13:38:05 CET] <kolo> I want to burn a transparent picture file (.png) at a given timecode on video, is it possible? [13:38:29 CET] <kolo> I do it for subtitles in this way: : ffmpeg -i input.mp4 -vf subtitles=input.srt out.mp4 [13:38:47 CET] <kolo> Can I do that for PNGs? [13:39:31 CET] <Mavrik> overlay filter I guess. [13:39:35 CET] <Mavrik> There's a guide in the wiki. [13:41:02 CET] <kolo> I this methode the best way to write sth on the video? [13:42:50 CET] <kolo> Mavrik: www.ffmpeg.org/ffmpeg-filters.html#overlay-1 --> It's saying video on video; Is it the same for image on video? [14:17:47 CET] <PowerKiller> Is it possible to reencode NTSC into a MP4 [14:17:53 CET] <PowerKiller> so it's playable on computer? [14:28:32 CET] <PowerKiller> OK got it [14:28:50 CET] <PowerKiller> Gotta use WinXDVD in a VM and then reencode the mp4 into webm [14:28:57 CET] <PowerKiller> shd. work [15:06:57 CET] <MarkusDB1> I'm looking for a good tutorial to stream mpeg-dash or webm. I've been doing lots of googling, but all this seems like very new tech, is it? Is there a good guide out there? [16:04:46 CET] <NicCo> HI [16:05:10 CET] <NicCo> I would like to use -report on Windows [16:05:53 CET] <NicCo> I would like to report a log for each file converted, is it possible to specify a path for log file or I must use environment variable ? [16:09:49 CET] <J_Darnley> Are you starting many commands at the exact same second? [16:10:50 CET] <NicCo> No I'm launching only one conversion at the same time [16:11:03 CET] <J_Darnley> Then what's wrong with the default filename? [16:11:35 CET] <NicCo> I would like to convert files on different folder and I would like to put each log on each folder [16:12:11 CET] <J_Darnley> When why not cd to the right folder? [16:12:59 CET] <J_Darnley> To answer your first question: no, the env var is the only way. [16:13:50 CET] <NicCo> Ok thank you so 1) I use env var 2) log is allways into ffmpeg.exe folder ? [16:14:06 CET] <J_Darnley> No. RTFM [16:14:19 CET] <J_Darnley> -report [16:14:19 CET] <J_Darnley> Dump full command line and console output to a file named program-YYYYMMDD-HHMMSS.log in the current directory. [16:14:27 CET] <J_Darnley> *the current directory* [16:15:10 CET] <NicCo> oh osrry [16:15:13 CET] <NicCo> sorry [16:16:00 CET] <NicCo> so I understand why you said to use cd [16:18:58 CET] <NicCo> thank you ;) [17:14:06 CET] <thebombzen> what happened to libquvi support? [17:17:02 CET] <chungy> removed [17:17:25 CET] <chungy> libquvi hasn't been updated for a long time. Both security issues and usability issues (doesn't work on many sites anymore) [17:18:30 CET] <thebombzen> I see. I guess I'll have to use quvi's frontend and pipe it [17:18:32 CET] <JEEB> youtube-dl should in general be used instead for similar functionality [17:18:41 CET] <JEEB> (not limited to youtube) [17:18:49 CET] <thebombzen> is that a CLI program? [17:18:51 CET] <JEEB> yes [17:19:06 CET] <JEEB> the mpv video player has integration for it, for example [17:19:52 CET] <thebombzen> does FFmpeg support that, or is that the kind of thing I would have to pipe &/| save to a file first? [17:20:53 CET] <JEEB> ffmpeg doesn't have any integration as far as I know, so piping would be it [17:21:43 CET] <bencoh> youtube-dl as --exec [17:21:52 CET] <bencoh> has* [17:21:58 CET] <bencoh> (just like quvi) [17:23:01 CET] <thebombzen> it appears youtube-dl has the same problem that TeX has. that it's a program rather than a library [18:50:17 CET] <valdikss> Hello guys! I have the following video: http://b.1339.cf/abpdfut.webm [18:50:50 CET] <valdikss> The first part of it (before opening) is 23.98 fps and opening is 29.97. How can I re-encode it with ffmpeg without framedrop or stuttering? [18:54:30 CET] <ChocolateArmpits> valdikss: probably -vf fps=30000/1001 [18:57:08 CET] <valdikss> ChocolateArmpits: this will produce file with constant fps. I need to save vfr. [18:57:49 CET] <valdikss> ChocolateArmpits: I tried vsync 0, copyts, copytb and it's variations. [18:58:45 CET] <ChocolateArmpits> uh then sorry, I'm not familiar with vfr encoding [18:58:46 CET] <valdikss> ChocolateArmpits: I have either stuttering in opening or non-strictly-monotonic PTS notices. [18:59:35 CET] <ChocolateArmpits> are you sure the opening is actually at 29.97 rather than just playing at that framerate ? [18:59:46 CET] <valdikss> ChocolateArmpits: it seems ffmpeg ignores containers' pkt_duration [19:00:15 CET] <valdikss> ChocolateArmpits: yes i'm sure, I've encoded episode and opening and joined it with mkvmerge. [19:00:34 CET] <ChocolateArmpits> what I mean the opening doesn't have duplicated frames [19:00:57 CET] <valdikss> ChocolateArmpits: &ignores pkt_duration and sets pkt_duration=41 in both episode and op, while it should be set to 33 in op [19:01:07 CET] <valdikss> ChocolateArmpits: yes, all frames in opening are unique. [21:31:42 CET] <spookypeanut> has anybody tried using audio & video filters on a .vob (ripped with vobcopy, in case it matters)? [21:32:01 CET] <spookypeanut> i'm getting my video and audio out of sync, trying to troubleshoot [21:33:46 CET] <Zitter> Hi, I have a video file with audio. Now I would like to add another audio to that video (I have in a .mp3 file). any hint on how to do that? [21:34:16 CET] <Zitter> I mean I don't want to lose the original audio, only adding the new one [21:35:18 CET] <Mavrik> Pass original file and the mp3 file as input, use "-map" parameters to map all three streams and use "-codec copy" so things won't get encoded. [21:38:24 CET] <Mavrik> ask which parts are unclear ;) [21:46:57 CET] <Zitter> I've tried: ffmpeg -i second_part_volume05.mp4 -i 20160128-144446.mp4 -map 0:0 -map 0:1 -map 1:0 -codec copy output.mp4 and I hear only audio from first source (second_part_volume05) [21:47:28 CET] <Mavrik> hmm [21:47:41 CET] <Mavrik> are timestamps on the tracks synced? [21:47:58 CET] <Mavrik> also pastebin command and output of ffmpeg [21:48:49 CET] <Zitter> If I do -map 0:0 -map 1:0 I can hear output from second file but not from the first one [21:53:36 CET] <Zitter> ah, I undestand. It add a "track" audio so it means that I can switch from an audio source to another one [21:53:50 CET] <Zitter> but it isn't what I need [21:54:01 CET] <Mavrik> well, you said that's what you need [21:54:05 CET] <Mavrik> :) [21:54:44 CET] <Zitter> mmm [21:55:04 CET] <Zitter> sorry I'm not so good to explain my needs in english [21:55:06 CET] <Zitter> :D [21:55:33 CET] <Zitter> I need to mixing two audio (one with a lower volume, of course) [21:55:34 CET] <Mavrik> ^^ [21:55:36 CET] <Mavrik> Ah. [21:55:50 CET] <Mavrik> So you want to hear both audios at once and you want them to be a single stream in the output? [21:56:26 CET] <Zitter> yes [21:58:24 CET] <Mavrik> hmm, you'll have to reencode the audio then [21:58:31 CET] <Mavrik> try something like [21:59:13 CET] <Zitter> maybe amix filter? I'm looking on docs [21:59:35 CET] <Mavrik> ffmpeg -i <video> -i <audio> -codec:v copy -codec:a aac -filter_complex "[0:1][1:0] amix=inputs=2" -b:a <audio_bitrate> output.mp4 [21:59:43 CET] <Mavrik> yeah, amix seems the one you need :) [22:01:00 CET] <Zitter> which value for <audio_bitrate>? sorry, I'm really new to these things [22:03:28 CET] <Mavrik> well [22:03:34 CET] <Mavrik> which ever you want [22:03:44 CET] <Mavrik> if you want to keep quality the same, use the same one as the input has [22:03:56 CET] <Mavrik> but I can't tell you the number because you didn't show the ffmpeg output that shows those values :P [22:06:50 CET] <Zitter> bitrate 1394 kb/s [22:07:15 CET] <Zitter> I've tried with first 2 minutes to see if it works... and it works :) [22:07:29 CET] <Zitter> Only problem is that audio of first stream is too high [22:10:33 CET] <Mavrik> huh [22:10:38 CET] <Mavrik> 1394 is like 10x too much [22:10:44 CET] <Mavrik> Are you mixing 5.1 AC3 or something? [22:12:39 CET] <Zitter> maybe :) [22:17:07 CET] <Mavrik> Well.. [22:17:13 CET] <Zitter> *cough* [22:17:26 CET] <Mavrik> if you won't tell what you're dealing with I can't help you anymore. [22:18:01 CET] <Zitter> listen, where can I learn basics from audio stuff? I mean: what codec is, bitrate and so on? Is there a nice guide on the web? [22:18:18 CET] <Zitter> audio/video I mean [22:45:40 CET] <slimyman> hi [22:46:03 CET] <slimyman> fu [22:46:04 CET] <slimyman> jk [00:00:00 CET] --- Mon Feb 8 2016

1 0

ffmpeg-devel.log.20160206
by burek 07 Feb '16

07 Feb '16

[00:03:57 CET] <J_Darnley> Gramner and others: after forcing yasm to assume an unaligned stack I see the difference now [00:08:56 CET] <wm4> Gramner: what does the old protocol do? [00:09:14 CET] <wm4> surely it was bitmap based, and it was comprssed in some way, like using a screen codec? [00:10:13 CET] <Gramner> not really sure about the details, but it was quite complex and tried to use different compression schemes for different content [00:10:39 CET] <Gramner> and utterly horribly to use over anything other than a local >=100Mbit network [00:14:45 CET] <jkqxz> Lync? It ran a whole RDP session, sending bitmap fragments losslessly. [00:16:20 CET] <Gramner> it handles (or at least tries to handle) text separately from graphics [00:18:12 CET] <Gramner> and input is somehow tied to the rendering, so if you happen to get some flash animation or whatever on the remote screen it can take like half a minute to close that window [00:21:29 CET] <jkqxz> I don't think text was text, but it certainly had all of the windowing hooks. So standard movement of things worked well (scrolling text or moving windows - both very hard in a video codec if you don't have the exact vectors in advance). [00:21:57 CET] <JEEB> hmm [00:22:07 CET] <JEEB> did avutil have any time-related stuff? [00:22:50 CET] <Gramner> even scrolling a simple text window is incredibly laggy in rdp if you're doing it over a DSL line [00:23:17 CET] <Gramner> rdp is kind-of okay:ish if you're on a LAN, but it toally breaks down if bandwidth is limited [00:25:33 CET] <Gramner> and encoding the screen shouldn't cause that much latency compared to the RTT anyway, as long as you render the cursor locally [00:28:17 CET] <TD-Linux> well there's multiple versions of the protocol that do very different things [00:28:24 CET] <TD-Linux> like earlier ones are basically GDI over network [00:29:29 CET] <Gramner> I mean, with gaikai you could even play first person shooters remotely over the internet, and that's a lot more sensetive to lag than a windows desktop is [00:35:01 CET] <JEEB> ok, av_gettime is what I want, most probably [01:15:09 CET] <cone-122> ffmpeg 03Michael Bradshaw 07master:1c40bccc0949: lavc/dirac_dwt: fix building without asm [01:56:53 CET] <J_Darnley> atomnuker, kierank: where can I find a repo for the dirac encoder? [01:57:13 CET] <J_Darnley> if there's not a public one I can just use the patch on the ML. [01:57:29 CET] <kierank> Good q [02:15:06 CET] <Timothy_Gu> Daemon404: any comments on "configure: Enable GCC vectorization on e4.9" [02:15:16 CET] <Timothy_Gu> i changed it to x86-only BTW [02:16:20 CET] <Timothy_Gu> jamrial: ok to push "[PATCH] diracdsp: Make x86 files/functions names consistent"? [02:42:11 CET] <jamrial> Timothy_Gu: yeah, seems ok. you'll have to rebase the dwt patch, though [02:42:25 CET] <Timothy_Gu> jamrial: yeah. will push in a moment [04:32:15 CET] <cone-492> ffmpeg 03Timothy Gu 07master:17ab8f7e6852: diracdsp: Make x86 files/functions names consistent [04:32:15 CET] <cone-492> ffmpeg 03Timothy Gu 07master:9fd6ea933fa1: dirac_dwt: Make x86 files/functions names consistent [05:40:44 CET] <cone-492> ffmpeg 03James Almer 07master:3e9b8ffc9bfe: avcodec/dcadsp: rename lfe_fir_float functions [05:40:45 CET] <cone-492> ffmpeg 03James Almer 07master:8ae744794101: x86/dcadec: add ff_lfe_fir0_float_{sse,sse2,avx,fma3} [09:14:31 CET] <rcombs> nevcairiel: apparently mingw is missing a few schannel macros; maybe steal the #ifdefs from http://boinc.berkeley.edu/android-boinc/curl-7.22.0/lib/curl_sspi.h? [09:18:03 CET] <nevcairiel> i have no interest nor a way to test old mingw32, feel free to send a patch, but I would rather ignore it entirely [09:18:08 CET] <nevcairiel> you should migrate to mingw-w64 already [09:18:36 CET] <rcombs> this is 64 [09:18:44 CET] <rcombs> well, 32-bit mingw-w64 [09:18:46 CET] <nevcairiel> builds perfectly fine for me =p [09:18:48 CET] <rcombs> (fuck these names) [09:19:02 CET] <nevcairiel> on 4.0, not even trunk [09:27:01 CET] <rcombs> ah, never mind, CI oddity [09:28:14 CET] <nevcairiel> i think we even have mingw32 fate systems still, so the configure check either disables it, or it builds, so shrug :) [11:31:17 CET] <atomnuker> okay, the encoder's been on the ML for like 5 days now [11:31:39 CET] <atomnuker> if there are no objections I'll probably merge it in like 6 or so hours [11:32:27 CET] <atomnuker> so yeah, go an review the code (this is the Dirac/SMPTE VC-2/Dirac Pro encoder I'm talkinb about) [12:49:18 CET] <cone-981> ffmpeg 03Paul B Mahol 07master:956fed377b4c: cmdutils: realign for some additional filters with very long name [14:48:22 CET] <durandal_1707> if I use maskedmerge and h264 decoder I get strange decoding errors [14:49:47 CET] <nevcairiel> maybe maskedmarge forgot to request writable buffers [14:50:04 CET] <nevcairiel> merge* [15:32:30 CET] <wm4> kierank: what's the exact vale range for gbrpa10? [15:32:49 CET] <wm4> for g/b/r and a components [15:33:01 CET] <kierank> Full range I guess [15:33:16 CET] <wm4> so [0,2^10-1]? [16:06:30 CET] <kierank> wm4: yes, that's what I clip to at least [16:06:33 CET] <kierank> the alpha I have no idea [16:06:37 CET] <kierank> I've never used alpha in my life [16:14:17 CET] <wm4> it would be sane if alpha had the same range as the color components [16:14:32 CET] <wm4> it's also like that with yuv, I think (so the alpha isn't full range there) [16:15:44 CET] <BBB> really? thats retarded [16:15:56 CET] <BBB> I mean, I understand the color meaning of blacker than black" [16:16:03 CET] <BBB> but more transparent than transparent makes no sense whatsoever [16:17:31 CET] <JEEB> durandal_1707: the lua thing you posted seems perversely interesting [16:20:18 CET] <durandal_1707> its just that, I cant do more, but its certainly better way of writing filtergraphs [16:20:52 CET] <JEEB> how much stuff do you have access there? [16:20:58 CET] <JEEB> stream lists? [16:21:56 CET] <wm4> BBB: out of range values are not supposed to happen in yuv [16:22:01 CET] <JEEB> so you could in theory do stuff like "if input contains a vobsub/dvbsub track, add the subtitle rendering filter chain [16:22:04 CET] <wm4> so they don't need to make sense [16:22:57 CET] <BBB> they absolutely do happen [16:23:00 CET] <BBB> they even have meaning [16:23:03 CET] <BBB> its very clearly defined [16:23:13 CET] <BBB> you can clip them out if you dont want, but thats implementation defined [16:23:37 CET] <BBB> search for blacker than black [16:23:47 CET] <BBB> itll bring you back to antiquated mpeg documents explaining it all [16:23:49 CET] <nevcairiel> Out of range values happen often enough, as wtw and btb, even if I find them nonsensical personally, any good display shouldn't be able to display them [16:24:22 CET] <BBB> theyre nonsense with more modern color spaces such as bt2020 [16:24:25 CET] <BBB> or smpte240 [16:25:02 CET] <BBB> not nonsense as in having no meaning, but nonsense as in rpobably not adding very much [16:25:11 CET] <wm4> this isn't about out of range values for limited range yuv, but our of range of the defined full range value range [16:25:12 CET] <kierank> out of range values happen a lot in the real world [16:25:25 CET] <kierank> filter overshoots etc [16:25:32 CET] <kierank> not to mention out of gamut issues [16:26:03 CET] <BBB> oh I see [16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:e740c3fb90c0: configure: fall back to using full path if src is a directory [16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:bb7522ce67e5: build: fix lcov with src link [16:26:06 CET] <cone-492> ffmpeg 03Andreas Cadhalpun 07master:14bf59c1d5b5: build: use intermediate lcov coverage file [16:26:10 CET] <BBB> you mean out of [0,2^10-1] range [16:26:26 CET] <BBB> I Guess wed call that bit width [16:26:32 CET] <BBB> sorry about that [16:26:53 CET] <BBB> doesnt h264 allow separate bit widths for luma and chroma? [16:26:57 CET] <BBB> its hilarious in a way [16:27:03 CET] <nevcairiel> It does [16:27:09 CET] <nevcairiel> But we don't support it :D [16:27:23 CET] <BBB> thank goodness [16:27:37 CET] <kierank> we should, j-b would go nuts [16:27:46 CET] <BBB> if we ever see such a file, we should display a warning to the user to use a special commandline option for fuzzing, and else well format c: [16:28:16 CET] <BBB> I think we already made jb go nuts [16:28:19 CET] <BBB> poor guy [16:59:07 CET] <atomnuker> so yeah, if someone can look at my VC-2/Dirac encoder that'd be nice [16:59:28 CET] <atomnuker> it's been like a month now and other than a few style issues no one has said a word [17:09:02 CET] <J_Darnley> atomnuker: is the code available in a public git somewhere? [17:11:13 CET] <atomnuker> J_Darnley: give me 5 mins [17:12:26 CET] <J_Darnley> That sounds like "no" to me so thank you if you're pushing it somewhere. [17:16:37 CET] <atomnuker> J_Darnley: git am this patch: https://0x0.st/X9z.patch [17:16:54 CET] <atomnuker> (to git master) [17:17:25 CET] <atomnuker> the transforms are in libavcodec/vc2_dwt.c [17:17:47 CET] <atomnuker> they're the main source of overhead [17:19:29 CET] <atomnuker> but if you can take a look to see I'm not doing something insane so I could merge it that'd be nice too [17:20:05 CET] <atomnuker> or say if you want a real repository on like github [17:20:33 CET] <J_Darnley> Nah. an up-to-date patch is fine [17:29:28 CET] <j-b> BBB: I am not nuts, I'm very well, tbh. [17:55:54 CET] <J_Darnley> atomnuker: I think you need to check for overflows when you allocate memory in the init_transforms function. [17:56:48 CET] <J_Darnley> brb [17:56:54 CET] <BBB> j-b: thats what all crazies say Im not crazy, Im an airplane! [18:00:58 CET] <J_Darnley> Another suggestion would be to have int strides start as ptrdiff_t types in the transformssothey don't get changed later. [18:02:13 CET] <atomnuker> J_Darnley: fair enough, I'll call avcodec_check_dimensions() in the main encoder init function [18:02:14 CET] <J_Darnley> s/transformssothey/transforms so they/ [18:46:32 CET] <durandal_1707> this mats is getting on my nerves [18:52:46 CET] <Loriker> ...mail flood [18:53:14 CET] <ac_slater> hey guys. Anyone have a clue as to why MPEGTS + AVC (baseline) would cause a pause every second for about 30ms? [18:53:30 CET] <ac_slater> I've been having this issue since 2.1 :( [18:53:55 CET] <Compn> playback? encoding? command line ? [18:54:04 CET] <ac_slater> Compn: yup getting a paste setup [18:54:04 CET] <Compn> whats your source? filters? [18:54:06 CET] <Compn> heh [18:54:15 CET] <Compn> also ask in #ffmpeg , this channel is for developers [18:56:18 CET] <ac_slater> true, figured it was a bug since it happens with both mpeg2 and x264 encoders. My test sources are lavfi testsrc, v4l2, or even a rawvideo in yuv420p to avoid the auto scaling. Heh indeed. I'll file a bug report [18:56:57 CET] <ac_slater> and, since 2.1. Haven't tried earlier versions [18:58:40 CET] <ac_slater> bug in the mpegts muxer * [19:27:40 CET] <wm4> nevcairiel: well I'm leaving the debian guy to you [19:31:36 CET] <Daemon404> the worst part about these sorts of people is that they have infintie energy to argue their side [19:31:44 CET] <Daemon404> eventually everyone else gets tired / gives up [19:31:48 CET] <Daemon404> -> shit is pushed [19:32:06 CET] <JEEB> :/ [19:32:43 CET] <Gramner> so the Ubuntu 16.04 LTS feature freeze is set at february 17, I think it would be beneficial to aim for a 2.9 or 3.0 release before that [19:33:34 CET] Action: Daemon404 should finish merging then [19:40:45 CET] <wm4> now it's apparently either apply that patch and add exceptions (vp9) as they come, or wait for BBB to do magic [19:41:11 CET] <wm4> and all because courmisch trolled the debian guy into reverting the patch in ffmpeg [19:41:12 CET] <wm4> bleh [19:42:06 CET] <durandal_1707> How evil [20:28:00 CET] <Gramner> http://www.econotimes.com/TECHNICOLOR-TECHNICOLOR-WITHDRAWS-FROM-THE-HEVC-A… oh great, now you need to license patents from 3 parties (MPEG-LA + HEVC Advance + Technicolor) if you want to use HEVC. as if the terms didn't suck enough as it was [20:29:13 CET] <nevcairiel> I doubt all relevant patents were included in the two pools before [20:31:07 CET] <JEEB> Gramner: kind of makes me feel sorry for the format in some weird way [20:31:27 CET] <Gramner> that statement holds true for pretty much every modern compression technology though. you never know when/if some patent trolls turns up from nowhere [20:31:53 CET] <JEEB> yeah [20:39:07 CET] <jkqxz> They have decided to license separately "to accelerate adoption of the standard". Yes, that totally makes sense. [20:39:39 CET] <Gramner> yeah, it's totally not to make some short term cash grab [20:40:00 CET] <Gramner> would probably have sounded more sincere to not write any reason at all [20:48:03 CET] <BBB> the ML is so much fun these days [20:48:11 CET] <jkqxz> I suppose it could kindof make sense if they had some internal argument about how the media licence part of it is killing the standard. They do say they only want to license devices. [20:48:39 CET] <Daemon404> whici is a ridiuculous stance to take [20:50:20 CET] <BBB> huh? [20:50:28 CET] <BBB> I was talking about the hwaccel/threading trollfest [20:50:37 CET] <BBB> no idea what you guys are talking about [20:51:55 CET] <Daemon404> [19:28] < Gramner> http://www.econotimes.com/TECHNICOLOR-TECHNICOLOR-WITHDRAWS-FROM-THE-HEVC-A… oh great, now you need to license patents from 3 parties (MPEG-LA + HEVC Advance + Technicolor) if you want to use HEVC. as if the terms didn't suck enough as it was [20:52:00 CET] <Daemon404> this [20:52:07 CET] <Daemon404> feel free to die laughing [20:52:21 CET] <BBB> omg Im so pleased [20:52:32 CET] <BBB> this shit gets better every day [20:52:49 CET] <Daemon404> i just dont get how these entities make such decisions [20:52:53 CET] <BBB> plus dont forget that some parties werent part of either mpegla or hevc advance already [20:53:09 CET] <Gramner> if they only cared about devices they should've joined MPEG-LA instead. MPEG-LA has pretty reaosnable terms [20:53:12 CET] <BBB> well, theres a troll with a big boat [20:53:24 CET] <BBB> and his wife complains one day, why do our friends from across the lake have two boats and we only one [20:53:32 CET] <BBB> plus, they have a private 747, we only have a private 767 [20:53:32 CET] <Daemon404> it sounds like everyone thought they could have made more money on the great success of h264 [20:53:36 CET] <BBB> and hes like [20:53:38 CET] <BBB> ok [20:53:38 CET] <Daemon404> so they want $$$ from hevc [20:53:44 CET] <Daemon404> but are murdering it before its taken off [20:53:46 CET] <BBB> let me whip my lawyers and get more money out of our technology [20:54:09 CET] <Daemon404> [19:53] <@BBB> plus, they have a private 747, we only have a private 767 [20:54:13 CET] <Daemon404> bullcrap [20:54:15 CET] <BBB> I Think companies are happy to pay for technologies if the value is obvious [20:54:17 CET] <Daemon404> they' want a private A380! [20:54:23 CET] <BBB> true, true, sorry [20:54:23 CET] <Gramner> while forgetting that a large part of the reason that H.264 was so successful is that the licensing terms was very reasonable [20:54:26 CET] <BBB> one A380? [20:54:30 CET] <BBB> one for each member of the family [20:54:38 CET] <BBB> I Dont want to sit in the same A380 as my little baby sister [20:54:38 CET] <Daemon404> Gramner, exactly [20:54:39 CET] <BBB> come on [20:54:52 CET] <BBB> whats my relationship to hevc again? [20:55:08 CET] <BBB> oooooo right I got one troll patent in about a bit that codes some obscure thing nobody gives a shit about [20:55:15 CET] <BBB> actually, I didn't [20:55:18 CET] <BBB> my lawyer did [20:55:24 CET] <BBB> BUT I WANT MY A380!!!1223one [20:55:41 CET] <BBB> s/A380/A380s/ [20:55:58 CET] <Gramner> "a bit that codes some obscure thing nobody gives a shit about" <- doesn't that description cover the vast majority of software patents [20:55:59 CET] <BBB> and they wonder why companies are dying to move over to hevc very quickly [20:56:08 CET] <BBB> Gramner: yup, exactly my point [20:56:17 CET] <wm4> it sure is funny when those who want to make money out of patents get into trouble with patent trolls [20:56:23 CET] <BBB> this might be a good reason to create a hevc basic" [20:56:25 CET] <Daemon404> Gramner, you forgot the other type [20:56:28 CET] <BBB> which covers most improvements over h264 [20:56:31 CET] <BBB> but has no troll patents [20:56:42 CET] <Daemon404> "loops over a value and increments" [20:56:42 CET] <Daemon404> BA< [20:56:44 CET] <Daemon404> vage patent [20:56:48 CET] <Daemon404> vague* BAM* [20:57:14 CET] <Daemon404> BBB, hevc basis *kind of* exists with Thor... but it's too basic [20:57:27 CET] <BBB> nah, that doesnt aven have cabac [20:57:34 CET] <BBB> I didnt mean broken hevc basic" [20:57:41 CET] <BBB> I meant correctly functional hevc basic" [20:57:48 CET] <Daemon404> i was petty sure cabac had some troll patent [20:57:58 CET] <BBB> so use the h264 cabac [20:58:01 CET] <BBB> its not that bad [20:58:04 CET] <BBB> the basic thing is the same [20:58:09 CET] <BBB> the contexts are different [20:58:14 CET] <BBB> so code elements differently and youre ok [20:58:21 CET] <BBB> and then license h264 through mpegla [20:58:22 CET] <BBB> done [20:58:30 CET] <JEEB> uhh, aren't HEVC and AVC CABACs the same? [20:58:38 CET] <JEEB> HEVC just removed CAVLC [20:58:48 CET] <BBB> the contexts are different [20:58:52 CET] <JEEB> oh [20:58:52 CET] <BBB> the basic algo is the same, yes [20:58:56 CET] <JEEB> ok [20:59:01 CET] <BBB> you could probably patent the contexts right? [20:59:12 CET] <BBB> I mean, you could patent the shape of the edges of an iphone [20:59:20 CET] <BBB> you can probably patent contexts [20:59:41 CET] <BBB> anyway, I couldnt be happier [21:01:17 CET] <JEEB> HEVC has gone so bad licensing-wise I'm almost thinking that someone at googleplex is constantly holding a glass of red wine and having his face darkened off while laughing in an evil way [21:04:22 CET] <Gramner> i wonder how many of the same companies are waiting for VP9 to gain traction so they can start the patent trolling there as well [21:04:24 CET] <jkqxz> And you think that if H.265 dies and VP9 wins then all of the trolls won't try to apply the same things to VP9? It's not that different, a lot of the patents will be sufficiently vague to apply to it too. [21:05:02 CET] <JEEB> yeah, it will totally go that way [21:05:08 CET] <BBB> this is awesome [21:05:12 CET] <BBB> so they will all sue google [21:05:22 CET] <JEEB> nah, they will sue the users [21:05:29 CET] <BBB> thats google [21:05:29 CET] <JEEB> I mean, the bigger ones [21:05:32 CET] <BBB> google is shipping the video [21:05:35 CET] <BBB> its called youtube [21:05:46 CET] <JEEB> no, I mean the (inexistant) hw decoders [21:05:53 CET] <JEEB> and binary distribution [21:05:57 CET] <JEEB> etc [21:06:05 CET] <JEEB> video they just can't do jack shit about really [21:06:06 CET] <BBB> what was on2s hw division called again? [21:06:10 CET] <BBB> and binary=chrome [21:06:11 CET] <JEEB> the one in oulu? [21:06:14 CET] <BBB> yes [21:06:20 CET] <JEEB> don't remember [21:06:26 CET] <Gramner> you don't start by sueing the largest company with the most lawyers. you start by going for an easier target so you can gain a precedent [21:06:28 CET] <BBB> and yes its still part of google [21:06:54 CET] <JEEB> Gramner: exactly [21:07:01 CET] <BBB> google will step in to any lawsuit as an interested party, because it shapes a precedent [21:07:11 CET] <JEEB> well, hopefully that happens :P [21:07:15 CET] <BBB> and so it will indirectly always be google (unless the user stops using vp9 as a result of the lawsuit) [21:07:18 CET] <BBB> it will always be google [21:07:24 CET] <BBB> this is so awesome [21:07:36 CET] <BBB> its like assured mutual destruction [21:08:05 CET] <BBB> (its not that I want google to go down, its just that this is exactly the worst-case scenario described for years, and now its playing out right there; so much popcorn) [21:08:20 CET] <JEEB> yeah [21:08:31 CET] <JEEB> the stuff of "they can't be as dumb to do that" [21:08:59 CET] <BBB> oh crap they did it anyway [21:10:07 CET] <JEEB> the only thing I dislike about this is the fact that VP9 is getting light on it even though it's just born out of the same kind of closed-doors bullshit that makes JCT-VC development process look like open doors [21:10:59 CET] <JEEB> (I was dumb enough to have hope that after G bought On2 they'd make the process better after VP8 was out of the door) [21:11:37 CET] <JEEB> but yeah, generally pop corn hour [21:12:44 CET] <Daemon404> i wish you had said popcorn time [21:12:55 CET] <BBB> aomedia has an irc channel [21:13:17 CET] <JEEB> Daemon404: didn't they get sued to hell? [21:13:54 CET] <Daemon404> thejoke.jpg [21:14:04 CET] <JEEB> lol [21:14:21 CET] <BBB> we need a popcorn smiley [21:14:30 CET] <BBB> life is not compelte without it [21:14:57 CET] <JEEB> meh, my desktop IME doesn't know the emoji :< [21:15:16 CET] <Daemon404> we do BBB [21:15:18 CET] <Daemon404> 🍿🍿🍿 [21:15:22 CET] <Daemon404> (if you client can show it) [21:15:27 CET] <BBB> I see 3 squares :( [21:15:41 CET] <Daemon404> it's unicode 8.0 [21:15:44 CET] <Daemon404> so... new [21:17:18 CET] <BBB> http://www.unicode.org/emoji/charts/emoji-released.html [21:17:25 CET] <BBB> sweet [21:18:00 CET] <BBB> theres also a unicorn [21:18:05 CET] <JEEB> yup [21:18:30 CET] <Daemon404> unicode is covering only the important things [21:18:37 CET] <Daemon404> aka emoji [21:18:50 CET] <wm4> yet there's no official klingon [21:19:01 CET] <BBB> maybe next release [21:19:03 CET] <wm4> (which shows the unicode consortium is full of shit) [21:19:23 CET] <BBB> lets do a contest, whos more full of shit, hevc or unicode [21:19:44 CET] <wm4> patents win [21:33:59 CET] <ubitux> 24+ hours without internet, sadness :( [21:34:07 CET] <ubitux> BBB: the amphora looks like a bomb.. [21:36:03 CET] Action: Daemon404 calls interpol on ubitux [21:58:08 CET] <durandal_1707> ubitux: ping on streamselect and nlmeans [21:59:19 CET] <ubitux> didn't have try again streamselect but feel free to push if the issue from last time are fixed, no progress on nlmeans [22:24:24 CET] <Daemon404> i really enjoy the cargo culting with ffmpeg config options [22:24:29 CET] <Daemon404> that guy has avisynth enabled on max. [22:24:31 CET] <Daemon404> mac* [22:27:12 CET] <durandal_1707> ubitux: still working on it? [22:27:41 CET] <J_Darnley> Daemon404: That's partly why I would like configure to return more errors. [22:27:43 CET] <ubitux> i still really want to, but got busy lately [22:27:47 CET] <J_Darnley> atomnuker: sorry I disappeared to make dinner, eat it, and watch a film [22:27:56 CET] <ubitux> durandal_1707: why are you so obsessed with it, you ask me like every weeek [22:28:01 CET] <J_Darnley> I didn't have any more obvious comments about dirac/vc2 [22:29:15 CET] <durandal_1707> ubitux: because I'm filter freak [22:29:40 CET] <jamrial> Daemon404: i've seen recent windows builds still using the memalign hack config option [22:29:53 CET] <Daemon404> ... i think chrome's build does [22:29:59 CET] <Daemon404> :/ [22:30:01 CET] <ubitux> durandal_1707: don't want to do the magnification one? [22:30:07 CET] <ubitux> eulerian magnification [22:30:44 CET] <jamrial> seriously? Chrome is using it on the one platform that has an aligned realloc function? [22:35:23 CET] <Daemon404> jamrial, it was... dunno if it still is [22:37:12 CET] <Daemon404> jamrial, nope im wrong [22:37:15 CET] <Daemon404> it no longer does [22:37:28 CET] <jamrial> good :p [22:37:44 CET] <atomnuker> J_Darnley: thanks, I'll send you a patch in a bit with the fixed ptrdiff_t's [22:37:48 CET] <JEEB> J_Darnley: it probably didn't error out because that person had installed the deadbeat piece of software called avxsynth [22:38:01 CET] <JEEB> which is a fork of avisynth not really used by anyone that is buildable on *nix [22:38:59 CET] <atomnuker> J_Darnley: also what did you mean by checking for overflows in the image dimensions in the transforms? FFmpeg limits the image dimensions to like 16384x16384 AFAIK [22:39:38 CET] <atomnuker> and I doubt the encoder would ever get a negative size in cast something screws up in the chain [22:39:39 CET] <wm4> something like this, but who knows for how long [22:39:39 CET] <J_Darnley> Well, it it gets limited to that elsewhere then it should be fine [22:39:46 CET] <wm4> (hopefully not forever) [22:41:37 CET] <J_Darnley> I was concerned that maybe if width and height were great enough then they could overflow INT_MAX and result in too little memory being allocated. [22:44:05 CET] <J_Darnley> what did I actually say earlier? [22:44:45 CET] <J_Darnley> oh yes, I did say alloc and init. [22:50:41 CET] <durandal_1707> ubitux: its patent pending, can I do it? [22:51:07 CET] <ubitux> there are patents? didn't know that [22:51:11 CET] <ubitux> matlab code is open though [22:53:16 CET] <durandal_1707> but its atadenoise in reverse, kind of [22:53:35 CET] <durandal_1707> Measuring pulse from video [23:50:04 CET] <nevcairiel> jamrial: the sad part is that the option hasnt been required for years and years, even before the native align functions, configure just enabled the hack when needed, no clue how long it must have been before the option was even needed [23:52:52 CET] <cone-678> ffmpeg 03Paul B Mahol 07master:d12d48d0a8e1: avfilter: add streamselect and astreamselect filter [00:00:00 CET] --- Sun Feb 7 2016

1 0

ffmpeg.log.20160206
by burek 07 Feb '16

07 Feb '16

[04:33:45 CET] <ac_slater> hey guys. I'm streaming some real-time video over UDP via ffmpeg. I have two machines connected via ethernet (no switch). `ffmpeg` on A, and `ffplay` on B. On B, I see an initial network latency of ~1second. Within about 5 minutes, this grows to ~20 seconds. My encoder (x264) is reporting over 1x encoding speed. Any clue? [04:34:00 CET] <ac_slater> I get that there should be some network+encoding latency, I just didnt think it would grow [04:34:18 CET] <ac_slater> (the video bitrate is only 500Kbit/s ... very low) [05:48:53 CET] <votz> Because ffprobe doesn't support seeking, ffmpeg is used to stream copy a subtrack of the video with -copyts -vsync 0. Then ffprobe is used on that stream copied subsection. Unfortunately the keyframe pts values do not match exactly -- they're slightly different, despite -copyts and -vsync 0. What causes this? [09:04:15 CET] <votz> How can IDR frames be differentiated from non-IDR I-frames with ffprobe? [09:38:39 CET] <klaxa> votz: with ffprobe -show_frames [09:38:50 CET] <klaxa> IDR frames will be keyframes (afaik) [09:39:03 CET] <klaxa> most of the time they are i think [17:47:43 CET] <MarkusDB1> ffplay seems really fast, but is there an "easier" to install option on mac os x? [17:50:25 CET] <JEEB> if you need a player I really recommend you go for mpv rather than ffplay, as ffplay is just supposed to be a simple player implementation on top of the libraries + SDL [17:51:51 CET] <MarkusDB1> yeah I guess that's why it's so superfast =) [17:52:19 CET] <MarkusDB1> JEEB: You know the best mpv alternative for mac? [17:52:32 CET] <JEEB> mpv works just fine on OS X as well [17:53:08 CET] <MarkusDB1> mpv.io? [17:53:17 CET] <JEEB> yes, it has homebrew formulas and all that [17:53:39 CET] <MarkusDB1> cool. I try it out. My goal is really low latency streaming. And vlc is not user friendly for that [17:53:53 CET] <MarkusDB1> ffplay worked great.. but my target audience will not want to mess with that [17:54:03 CET] <JEEB> the latency really depends on the demuxer etc buffering [17:54:12 CET] <MarkusDB1> yeah I know [17:54:21 CET] <MarkusDB1> but vlc's defaults is kinda bad [17:54:33 CET] <chungy> Why wouldn't mpv be "superfast" [17:54:40 CET] <JEEB> mpv will also use the same libraries as ffplay on the background [17:54:45 CET] <MarkusDB1> great [17:54:54 CET] <JEEB> but yes, parameters can differ although they can also be tweaked [17:55:02 CET] <MarkusDB1> chungy: dunno, I'm noobing around this currently [17:55:07 CET] <MarkusDB1> chungy: bare with me [17:55:20 CET] <JEEB> read the fine manual and ask questions on the related IRC channel when the time comes, basically [17:55:27 CET] <MarkusDB1> great [17:55:34 CET] <MarkusDB1> thanks! [18:06:08 CET] <votz> klaxa: both IDR frames and non-IDR frames are marked with key_frame=1 [18:06:26 CET] <votz> As far as I can tell, there's no way to differentiate them. [18:14:55 CET] <JEEB> votz: yeah - I don't think you can differentiate the picture types too easily... the decoder of course itself knows, but yeah [18:15:25 CET] <JEEB> there should be a flag that should only be 1 with sync samples (IRAPs), but it can of course be that it isn't exactly correct [18:30:23 CET] <votz> JEEB: How else can ffmpeg or ffprobe be used to enumerate the pts values of IDR frames in a video? [18:31:04 CET] <JEEB> you can't. the closest is the "this picture is a seekable one" which is not always correct, but often is [18:31:26 CET] <JEEB> but if your thing shows that flag for all pictures then you're hitting one of those things to "fix" broken samples [18:31:30 CET] <JEEB> or just a bug [18:31:51 CET] <votz> What do you mean by 'one of those things to "fix" broken samples'? [18:32:44 CET] <JEEB> something that supposedly enabled seeking in a file that a user was complaining wouldn't seek but should be according to him seekable... but that's just a guess :P [18:32:53 CET] <JEEB> it could just be a honest incorrect usage of the flag [18:33:14 CET] <JEEB> but as I said, there IIRC is no API to get the AVC/HEVC specific picture types currently [18:33:47 CET] <JEEB> the best you can get is the one flag (don't remember its name but it was badly named anyways) which is supposed to tell if you can seek to it or not [18:34:03 CET] <JEEB> it could have been that exact one you've poked [18:37:53 CET] <votz> If you're curious, here's the default output for an IDR I-frame and a non-IDR I-frame. http://paste.ubuntu.com/14924042/ [18:39:49 CET] <votz> Looking for that flag you speak of to see if that helps. Otherwise, what options are there? Is the IDR information stored in the SPS or PPS NALU? [18:40:38 CET] <JEEB> aren't those just parameter sets? the actual picture containing (was it VCL?) NAL units would have that info as they come by [18:41:19 CET] <votz> I believe so, but I'm not 100% positive. I'm just digging at the bottom of the barrel for some solution. [18:41:35 CET] <JEEB> the HEVC parser did actually output what it finds if you enable debug logging, but that isn't an API in any way or form :D [18:41:43 CET] <votz> The fundamental problem to solve is this: find the nearest IDR frame before and after some timestamp [18:41:49 CET] <JEEB> which was useful when I was hacking up HEVC-in-matroska [18:42:32 CET] <JEEB> is that AVC or HEVC btw? [18:42:48 CET] <votz> so you say, what's the nearest IDR frame before and after 10.38s? And then [run stuff] to find that the nearest IDR frame before 10.38s is 10s and nearest after is 15s. [18:42:58 CET] <votz> AVC [18:43:00 CET] <ac_slater> Hey all. Has anyone got a clue why MPEGTS with (only) AVC would pause for ~30ms every seconds? [18:43:33 CET] <JEEB> ok, so there's only IDR + the weird-ass open gop / intra refresh cases [18:43:56 CET] <JEEB> HEVC really made that simpler to parse because they added more picture types that are seekable [18:44:25 CET] <JEEB> (IRAP being the umbrella term, which then contains IDR and the rest) [18:44:40 CET] <votz> Unfortunately re-encoding to HEVC isn't an option [18:44:49 CET] <JEEB> yeah, I'm not saying that :P [18:45:17 CET] <JEEB> just saying that finding random access pictures in AVC can be "fun", since you can have non-IDR pictures which are still supposed to be seekable [18:45:36 CET] <votz> Can you think of a clever solution? Like use ffmpeg's seeking twice to seek to those IDR frames at 10s and 15s (as an example)? [18:46:08 CET] <votz> What denotes seekable keyframe or not? Whether frames after the keyframe reference frames before the keyframe or not? [18:46:28 CET] <JEEB> IDR is the most clear one [18:46:35 CET] <JEEB> since it kills off all references [18:46:52 CET] <JEEB> then there's I pictures with recovery points [18:47:14 CET] <JEEB> which is what is used with open gop [18:47:59 CET] <JEEB> right, so recovery point is a SEI message [18:48:20 CET] <JEEB> i wonder if lavf/lavc takes that stuff into mention at all [18:49:14 CET] <votz> Are frames that ffprobe marks as key_frames 'seekable' in that sense? That is, no frame after a key_frame will reference a frame before that key frame? [18:49:31 CET] <votz> In other words, is it safe to stream copy a slice of the video starting at that seekable key_frame, even if it's not an IDR frame? [18:49:59 CET] <foonix> i think you have good chance to find 'seekable' key_frame when there's P frame before [18:54:02 CET] <JEEB> votz: no, that is not necessarily seekable. which leads to stuff working like this https://ffmpeg.org/pipermail/libav-user/2012-July/002509.html [18:57:08 CET] <JEEB> votz: you could make a question-type issue on the tracker I guess? although we basically currently lack any APIs to get those format-specific picture types :) [18:58:58 CET] <votz> JEEB: I've been using an old version of avprobe that, strangely/luckily, only reports IDR frames as key frames. This is libav 11.4. [18:59:27 CET] <JEEB> uhh, that doesn't sound good [18:59:34 CET] <votz> But that version is too old to support seeking: avprobe v11.4 doesn't have -read_intervals [18:59:55 CET] <JEEB> can you post a sample of an affected clip? [18:59:56 CET] <votz> Thus, I devised a hack: stream copy a section around the desired point with -copyts and then run avprobe 11.4 on that subsection [19:00:20 CET] <votz> But I then bumped into another problem: for whatever reason, the pts values are not *exactly* the same [19:01:45 CET] <votz> Example: http://paste.ubuntu.com/14926732/ [19:02:20 CET] <votz> you'll notice the difference between the IDR frames is identical, but their absolute pts values is not. [19:03:04 CET] <votz> So, a different potential solution: why wouldn't a subtrack stream copied with -copyts have *exactly* the same pts values? [19:03:32 CET] <JEEB> what container is it? [19:04:10 CET] <JEEB> also there of course can be a difference in how the pts gets calculated between Libav and FFmpeg >_> [19:04:14 CET] <votz> The original video is h264 in MP4, the stream copied subtrack with -copyts is mpegts [19:04:28 CET] <JEEB> if possible, keep the same container [19:04:34 CET] <JEEB> mpeg-ts's time base is different [19:04:58 CET] <JEEB> close, but it can have some differences depending on the picture rate [19:05:08 CET] <JEEB> or well, not close but a pretty large timebase [19:05:12 CET] <JEEB> I think it was 90000 ticks or something [19:06:15 CET] <votz> And it's an ancient libav, too. I lucked out and had an old static build on hand. And -- for whatever reason -- avprobe 11.4 only prints IDR frames as key frames. [19:06:51 CET] <JEEB> considering that Libav still hasn't released 12 IIRC it's not really "ancient" :P [19:07:04 CET] <votz> Fair point [19:07:20 CET] <votz> Perhaps an old ffprobe behaves the same way. I didn't test. [19:07:55 CET] <JEEB> quite possible. it would be interesting to see where the change would end up bisected [19:08:44 CET] <votz> Do any other h264/mp4 tools come to mind that can both seek and print IDR frames? [19:08:45 CET] <JEEB> but yeah, that sounds like something you could make an issue about if you know that only IDR pictures are supposed to be seekable in that file [19:09:12 CET] <JEEB> not IDR, but l-smash's boxdumper can print mov-style container's contents out [19:09:23 CET] <JEEB> that includes seekable points [19:09:38 CET] <JEEB> sync samples they were called, I think [19:10:37 CET] <votz> Wait. Backing up. Maybe I misunderstood you before. Are non-IDR, seekable keyframes safe to stream copy from? Safe in the sense that P-frames that come after the seekable, non-IDR keyframe will *not* reference frames before said seekable, non-IDR keyframe? [19:11:10 CET] <votz> Because, thinking about it, if that was the case -- and a frame after a seekable keyframe can reference frames before the seekable keyframe -- that frame would be broken after seeking [19:11:43 CET] <JEEB> non-IDR intra pictures only mean that you have an intra picture. if you have a recovery point SEI there as well then it's an open gop stream and you can seek to it [19:12:36 CET] <JEEB> personally if your input is in mp4 I would take a look at how it looks in boxdumper [19:12:57 CET] <JEEB> what pictures are noted as sync samples [19:14:53 CET] <votz> Right. but ffprobe differentiates between I-frames and key_frames [19:15:19 CET] <votz> When ffprobe reports a key_frame, is it safe to stream copy from that frame? Or can frames stream copied after that key_frame be corrupted b/c they reference a frame before the key_frame? [19:15:41 CET] <JEEB> that depends on completely how that flag is used [19:16:25 CET] <JEEB> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c#L1543 [19:16:51 CET] <JEEB> also https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/h264.c#L1722 [19:18:12 CET] <votz> So that answers it. Every key_frame (as reported by ffprobe) should be safe to stream copy from. [19:18:58 CET] <JEEB> according to those points, yes. but if you think you have too many points marked like that? [19:19:23 CET] <votz> Not sure. But it's strange that ffprobe and avconv 11.4 report different IDR frames. [19:19:57 CET] <votz> One explanation is that ffprobe reports SEI related key_frames, while avprobe does not (only reporting true IDR frames). [19:20:01 CET] <votz> That would explain the difference [19:20:04 CET] <JEEB> sure [19:20:18 CET] <votz> s/avconv 11.4/avprobe 11.4/ [19:20:22 CET] <JEEB> I would be surprised if you would see such in normal mp4 files tho [19:20:31 CET] <JEEB> you don't usually see open gop content [19:20:44 CET] <JEEB> not to mention a mix of IDR and open gop random access points [19:20:58 CET] <JEEB> are the samples something you can share? [19:21:53 CET] <votz> Yes, but later. I have to run in 5 minutes. [19:22:01 CET] <JEEB> ok [19:22:38 CET] <votz> I'll try to catch you later in here or #libav. [19:23:48 CET] <votz> For now, thank you for your time, help and input. [19:24:38 CET] <votz> I'm going to play around with subtrack copying to mp4 instead of mpegts and seeking with avprobe. [19:24:48 CET] <votz> The former might solve the -copyts problem. [19:25:28 CET] <votz> And/or all keyframes marked as such by ffprobe may indeed be safe to be stream copied, even if avprobe 11.4 only reports a subset of the ones ffprobe reports as key frames. [19:25:52 CET] <votz> Anyhow, thank you again for your time and help. I'll catch you here or in #libav later. [19:43:38 CET] <ac_slater> Hey all. Has anyone got a clue why MPEGTS with (only) AVC would pause for ~30ms every second? I'm permuting some mpegts options like muxrate, etc, but I havent been able to fix it. Clues? I've tried a bunch of input sources, v4l2, lavfi testsrc, rawvideo, etc. My encoder is x264 baseline. [19:56:23 CET] <ac_slater> players include vlc, mpv, and ffplay [22:33:53 CET] <___dewey> Hi all, I want to save a AVSubtitleType SUBTITLE_BITMAP to disk but I cant find out how to properly do that with the AVSubtitleRects that Im receiving. [22:34:28 CET] <___dewey> does any of you know of a good tutorial/example which I could learn from? [22:57:19 CET] <nathdwek> Hi there I have a small question regarding versioning [22:58:51 CET] <nathdwek> I get libav*56 on F23; but to build another tool, I need libav*54. This isn't too big of an issue, the only thing is I can't figure how git tags/branches are linked to the shared objects numbering. [22:59:02 CET] <JEEB> they aren't :) [22:59:35 CET] <JEEB> I recommend you take a look at the history of the file defining the API version [22:59:49 CET] <JEEB> and take the last revision with the API version you require [22:59:50 CET] <nathdwek> Ok so if I compile from source, how can I make sure I build the 54 ones and not the 56 ones? [23:00:09 CET] <nathdwek> Ok thanks (sorry didn't read your first answer) [23:00:39 CET] <JEEB> also a lot of the libraries don't actually share the version [23:00:47 CET] <nathdwek> It would be awesome if you had a quick link for me [23:02:41 CET] <Mavrik> I think JEEB is friendly enough to just do the compile for you ;) [23:02:58 CET] <nathdwek> O I got it it's pretty well documented in doc/apichanges [23:03:32 CET] <nathdwek> great, thanks. By curiosity, any reason for this weird way of doing things? Why not semver? [23:03:43 CET] <JEEB> it is semver [23:03:57 CET] <JEEB> there's a major, minor and micro version for each library [23:04:24 CET] <JEEB> and major is used in the file name [23:04:29 CET] <nathdwek> yeah I meant for the tagging [23:04:45 CET] <JEEB> because every library has its own versioning? [23:04:57 CET] <JEEB> which aren't matched because a change in X doesn't mean Y has changed [23:04:58 CET] <nathdwek> I'll see myself out [23:05:13 CET] <nathdwek> Thanks a lot [23:05:17 CET] <JEEB> basically releases just mean a branched out version [23:05:21 CET] <JEEB> at point X [23:06:13 CET] <JEEB> if it was a single library it'd probably have a single versioning :P [23:06:56 CET] <nathdwek> Yeah actually if you see it as a suite of stuff it kinda make sense [23:07:31 CET] <nathdwek> We should just ticket git to enable...let's call it submodule-tree-tagging.js [23:11:33 CET] <JEEB> and yeah, it's a collection of eight things right now as far as I can see. some really young (libswresample, libavresample) and some older like libavcodec/-format [23:23:11 CET] <Phr33d0m> hi, is there any current work (or experimental patch) on nvresize? I've found a patch provided by nvidia but it's obsolete by now and it's huge for me to adapt it... [00:00:00 CET] --- Sun Feb 7 2016

1 0

ffmpeg-devel.log.20160205
by burek 06 Feb '16

06 Feb '16

[00:42:02 CET] <kierank> J_Darnley: I guess if BBB or Gramner don't object to your h264 patch you should push it [01:24:16 CET] <kierank> one for the cosmetic lawyers, does GBRAP12 go with GBRP12 in swscale or GBRAP16? [01:25:42 CET] <cone-089> ffmpeg 03Michael Niedermayer 07master:1693336aed39: avfilter/af_apulsator: assert that pathes leaving uninitialized variables do not occur [01:25:42 CET] <cone-089> ffmpeg 03Eran Kornblau 07master:1bbfaba196b3: avformat/mov: dont print frma warning when format is the same [01:25:42 CET] <cone-089> ffmpeg 03Trevor \\\\ Higgins 07master:6632802aa00c: x11grab: fixed next frame capture time calculation [01:28:37 CET] <atomnuker> kierank: the latter [01:28:58 CET] <kierank> bugger [01:30:04 CET] <atomnuker> then again I'm not an !%34%4()#3 expert, but makes more sense to bundle formats with the same #planes together [01:50:05 CET] <Timothy_Gu> I'm beginning to suspect that reindl guy has some problems... [01:52:56 CET] <kierank> llogan: can we stop that discussion [01:54:00 CET] <llogan> kierank: i don't think any got passed the regex filter since i added it [01:54:06 CET] <kierank> ok thanks [01:54:15 CET] <llogan> should have done it earlier... [01:55:20 CET] <llogan> Timothy_Gu: yeah. anger. he makes the list a bad experience. [02:14:22 CET] <Timothy_Gu> alright. proposal to remove the old fate & request for root sent. [08:35:51 CET] <kierank> michaelni: so, how do I make fate pass? [08:49:28 CET] <nevcairiel> you hammer it until succcess falls out [08:53:02 CET] <nevcairiel> kierank: looks like you should only flag input support for the time being in swscale, its probably trying to convert to gbrap12 which isnt implemented [12:45:50 CET] <durandal_170> can I get comments? [12:50:16 CET] <wm4> on what [12:56:07 CET] <durandal_170> wm4: on luascript [13:33:58 CET] Action: J_Darnley curses his ISP [13:34:22 CET] <J_Darnley> durandal_170: I'm reading your luafilter right now. [14:03:26 CET] <J_Darnley> durandal_170: can you explain how to use the filter? [14:08:56 CET] <J_Darnley> I'm going to email. [15:08:06 CET] <rcombs> jkqxz: your VAAPI patches don't build if X11 isn't present [15:08:51 CET] <rcombs> you've got a `Display*` declared without a `HAVE_VAAPI_X11` guard, and also include va/va_x11.h unconditionally [15:12:12 CET] <BtbN> I wouldn't even bother with X11 for VAAPI. It works just fine via DRM [15:18:18 CET] <wm4> BtbN: in theory you can use some other vaapi drivers than intel's with x11 [15:18:29 CET] <wm4> but it's probably not worth the trouble [15:18:51 CET] <BtbN> I think the native mesa ones also work with drm [15:19:00 CET] <BtbN> and the vdpau wrapper is dead anyway [15:19:07 CET] <cone-122> ffmpeg 03James Almer 07master:16af350ac5b1: avcodec/dcadsp: replace intptr_t with ptrdiff_t [15:24:15 CET] <J_Darnley> durandal_170: were you able to successfully encode the output of your script? [15:24:41 CET] <J_Darnley> libx264 complains that the width (640) is greater than the stride (0) [15:25:21 CET] <J_Darnley> And other encoders just segfault [15:26:20 CET] <Daemon404> well... 0 stride is not exactly vaid [15:26:21 CET] <Daemon404> valid [15:26:41 CET] <J_Darnley> I did wonder(!) [15:26:47 CET] <J_Darnley> Also, I'm going to send you a diff to get the AV_LOG constants in the environment. (I'm sick of the fatal colors) [15:44:48 CET] <cone-122> ffmpeg 03Mats Peterson 07master:9556446623d6: lavc/rawdec: Use 16-byte line alignment for B1W0 and B0W1 video in nut [15:55:20 CET] <durandal_170> J_Darnley: query_formats is wrong, you need to use format filter after lua one, ... [16:03:03 CET] <J_Darnley> Ah. Sure [16:24:16 CET] <J_Darnley> Good job avfilter! A fiter can return an error and you will just blindly continue and let ffmpeg say everything was successful! [16:24:58 CET] <wm4> trollol [16:25:15 CET] <wm4> but maybe ffmpeg.c is ignoring one of the many return values? [16:26:02 CET] <J_Darnley> Perhaps to ffmpeg it isn't an error. It managed to connect one testsrc input to format which did run sicessfully. [16:26:14 CET] <J_Darnley> *sucessfully [16:27:52 CET] <jkqxz> You want VAAPI/X11 if you're thinking of magic around picking DRM surfaces out of the X server. [16:29:49 CET] <jkqxz> rcombs: Thanks for noticing that; I will fix it. [16:30:10 CET] <Gramner> kierank: assuming if it works, yeah I guess. [16:30:14 CET] <rcombs> cool [16:30:38 CET] <kierank> J_Darnley: ping [16:31:24 CET] <J_Darnley> pong [16:33:30 CET] <J_Darnley> kierank: pong [16:37:01 CET] <J_Darnley> If it is about the h264 assembly then I'll ping my message on the ML. [16:38:14 CET] <kierank> Gramner says you can push it [16:38:26 CET] <J_Darnley> ah okay [16:38:58 CET] <J_Darnley> Tell him thanks. [16:39:05 CET] <Gramner> I'm here you know [16:39:16 CET] <J_Darnley> Then thank you. [16:39:22 CET] <Gramner> and yes, go ahead and push assuming that it works [16:39:36 CET] <J_Darnley> (Did I not say that it does pass fate?) [16:40:20 CET] <Gramner> no, I don't think you did. at least not in the most recent version [16:51:58 CET] <J_Darnley> durandal_170: yay! successful output! [17:12:52 CET] <wm4> durandal_170: so why can't there be something like sub-graphs, instead of shuffling the data manually between 2 graphs? [17:14:40 CET] <durandal_170> wm4: what filter? [17:16:52 CET] <wm4> lua and conditional [17:24:49 CET] <durandal_170> wm4: subgraphs? how would it work? [17:34:40 CET] <cone-122> ffmpeg 03James Darnley 07master:7042a55c55d7: avcodec/h264: mmxext 4:2:2 chroma deblock/loop filter [17:36:02 CET] <wm4> durandal_170: don't know, it'd somehow directly access the filters, instead of going over buffersink/src, but I don't know if this is possible at all [17:39:50 CET] <atomnuker> J_Darnley: mmxext? isn't that pretty much ancient at this point? [17:40:09 CET] <J_Darnley> Yes but the 420 one is still only mmxext [17:40:18 CET] <nevcairiel> atomnuker: some data is just too small to realistically use more than 64-bit at a time [17:42:16 CET] <atomnuker> nice to know mmx still has its place [17:42:36 CET] <drv> emms will live forever [17:43:28 CET] <J_Darnley> I'm sure many of these older DSP functions could be updated to use sse2 and avx but I doubt they will get much faster. [17:43:43 CET] <J_Darnley> You just need to check how much data they're writing. [17:45:23 CET] <Gramner> starting with skylake mmx is actually slower than sse for certain instructions though [17:45:26 CET] <J_Darnley> I guess you also need to check what loads are being done to prevent tracking down assembler errors later. [17:46:31 CET] <Gramner> i'm not sure if they're intentionally making mmx worse just to get people away from it or it there's a legit reason for it being slower [17:47:42 CET] <J_Darnley> There are a few macros hiding places where 3-op instructions could be used. [17:47:51 CET] <wm4> they're probably moving it from hardcoded logic to microcode or something to free up space for useless avx512? [17:48:21 CET] <Gramner> it's not microcode. microcode is really slow - it's not that slow [17:50:28 CET] <Gramner> asl avx-512 isn't useless. it's just that there's diminishing returns for increasing vector sizes [17:51:14 CET] <J_Darnley> Just wait for the fabled 64x64 blocks I heard about at FOSDEM. [17:54:01 CET] <Gramner> need to go above and beyond! at least 4096x4096 px blocks because larger numbers are better [17:54:21 CET] <kierank> J_Darnley: you were there for that? [17:54:35 CET] <kierank> ninja [17:54:45 CET] <J_Darnley> Yes. I was hiding in many of the open media talks [17:54:58 CET] <J_Darnley> I missed your camera one though. [17:55:06 CET] <J_Darnley> The room was full when I got back to it [17:58:52 CET] <jamrial> and avx512 with the VL extension will make it interesting to rewrite some 16/32 byte wide functions thanks to the new instructions [17:59:05 CET] <jamrial> like that pshufb on steroids one [18:00:04 CET] <nevcairiel> will only be interesting if those migrate into mainstream hardware [18:01:11 CET] <jamrial> well, VL and a couple other extensions are going to be introduced with the first avx512skylake xeon [18:01:16 CET] <nevcairiel> you can also use 32 xmm registers using those instructions, so... maybe some very complex things can benefit =p [18:01:27 CET] <Gramner> vpermi2b is avx512vbmi [18:01:30 CET] <jamrial> hopefully kabylake/cannonlake introduces avx512 on desktop [18:01:34 CET] <jamrial> oh [18:01:36 CET] <Gramner> which is not part of skx [18:01:46 CET] <Gramner> it's cl afaik [18:01:49 CET] <Gramner> cnl* [18:01:51 CET] <nevcairiel> thats cannonlake, yes [18:01:52 CET] <jamrial> i thought it was BW [18:01:55 CET] <jamrial> ah well [18:02:03 CET] <atomnuker> considering how long avx2 took I wouldn't bet on avx512 in kabylake [18:02:13 CET] <Gramner> kbl wont have avx-512, no [18:02:21 CET] <nevcairiel> kabylake sounds more like a minor refresh, no big feature changes [18:02:28 CET] <jamrial> so no avx512 on desktop until cannonlake? [18:02:39 CET] <Gramner> on desktop cnl is the first µarch with avx-512 [18:02:57 CET] <nevcairiel> and that is still hoping, or did they confirm that officially? [18:03:16 CET] <Gramner> it's as confirmed it's going to get [18:03:39 CET] <jrosser> cineform and dirac would benefit from wider instructions, probably [18:04:07 CET] <Gramner> I'm going by what intel's SDE supports when emulating various µarchs, and that's usually accurate so [18:04:07 CET] <jrosser> where the transform size is not the same as the bitstream slice size [18:04:09 CET] <nevcairiel> i hope their mainstream line also gets more than 4 cores then, waiting for the -E line would be another year at least [18:04:43 CET] <nevcairiel> or they give Skylake-E avx512 [18:04:44 CET] <Gramner> skylake-E is like Q3'17 or something like that [18:05:18 CET] <Gramner> skylake-e should have avx-512, yes, considering the -E series are basically rebranded xeons [18:05:47 CET] <nevcairiel> intels timeline has shifted quite a bit over the last year, if skylake-E is only going to come out in Q3'17, then its two generations behind the mainstream at that point [18:05:51 CET] <Gramner> but CNL should also be out at around the same time as Skylake-E [18:06:57 CET] <nevcairiel> hence h oping that CNL gets at least a 6 core option [18:07:51 CET] <Gramner> it's possible at least. considering that they're running out of things to improve aside from the iGPU increasing core count would be a good way of getting people to upgrade [18:07:52 CET] <nevcairiel> I dont need the other "advantages" of the -E platform, I mostly wanted more cores [18:08:29 CET] <kierank> jrosser: tried the Xeon-D platform? [18:08:43 CET] <kierank> quite a lot of cores for 45W [18:09:10 CET] <jrosser> i was looking today actually [18:09:16 CET] <Gramner> i should get a dual socket xeon just to compile stuff faster [18:09:20 CET] <jrosser> you have the supermicro stuff? [18:09:27 CET] <nevcairiel> personally while I like more cores, for my desktop usage I also like some remnant of single-threaded performance =p [18:09:35 CET] <kierank> jrosser: not yet, plan to get one soon [18:09:46 CET] <wm4> nevcairiel: you still don't want to push your main 10 patch? [18:09:57 CET] <jrosser> there was an amazing mini itx board with 2x 10gig [18:10:13 CET] <kierank> yeah [18:11:04 CET] <rcombs> jkqxz: also, you should probably do something to autodetect when `-ldrm` and/or `-ldrm_intel` are required [18:11:05 CET] <nevcairiel> wm4: maybe on the weekend [18:12:01 CET] <kierank> jrosser: http://www.supermicro.nl/products/system/1U/5018/SYS-5018D-FN4T.cfm [18:12:05 CET] <kierank> not clear what chipset on the 10gig [18:12:31 CET] <jrosser> its on the cpu isnt it? [18:12:39 CET] <jrosser> but isw [18:12:42 CET] <jrosser> ym [18:17:28 CET] <jamrial> wow, dcadec's lfe_fir_float_c compiled on x86_32 is two times slower when gcc uses x87 fp math compared to -mfpmath=sse [18:18:10 CET] <kierank> yeah x87 sucks [18:19:57 CET] <Gramner> good thing there's literally no reason to x87 nowadays aside from some argument passing stuff in 32-bit x86 as required by the ABI [18:21:54 CET] <jamrial> default x86_32 builds use x87. not even choosing an specific cpu during configure changes that it seems. you need to pass -mfpmath=sse to extra-cflags [18:21:58 CET] <Gramner> -mfpath=sse -msse -msse2 ought to be the default in gcc [18:22:11 CET] <Daemon404> it is in clang iirc [18:22:25 CET] <Gramner> it is in msvc and icl at least [18:22:37 CET] <Gramner> or well, the corresponding options [18:24:32 CET] <jamrial> two years ago there was an user that was still rocking an Athlon thunderbird to play one of those dvd resolution bdrips with dts audio and reported a crash that ended up being a misplaced sse2 instruction [18:25:14 CET] <jamrial> or was it an Athlon xp, not sure. still, no sse2 and of course x86_32 [18:25:57 CET] <Gramner> I mean, SSE has been available since -99 and SSE2 since -00? if someone's still using a such an ancient CPU I feel that "go buy a new computer" is a perfectly justifiable answer [18:26:09 CET] <jamrial> heh [18:26:23 CET] <wm4> <Gramner> good thing there's literally no reason to x87 nowadays aside from some argument passing stuff in 32-bit x86 as required by the ABI <- what about 80 bit floats [18:26:52 CET] <Gramner> we don't pretend that those exists [18:33:25 CET] <jkqxz> rcombs: Are those only relevant for static linking? (libva wants to depend on them?) I haven't run into that at all. [18:33:57 CET] <rcombs> probably, yeah [18:34:49 CET] <rcombs> jkqxz: also usually you could rely on pkgconfig for this but I checked and the relevant pkgconfig scripts are extremely lacking [18:35:24 CET] <rcombs> (they don't declare those dependencies like they should) [18:47:00 CET] <durandal_170> michaelni: is FFmpeg going to candidate for this year GSoC? [18:49:01 CET] <jkqxz> The whole thing isn't really amenable to static linking anyway given that different parts have to dlopen() each other. Tempting to just ignore this problem for ffmpeg, and users can sort it themselves for lav*. [18:53:16 CET] <wm4> since libva is just a dlopen wrapper, static linking really won't work? [18:55:24 CET] <jkqxz> Well, it can "work" (that is, link and run). But it will still have runtime dependencies on shared libraries, which is probably exactly what the user didn't want. [19:02:02 CET] <durandal_170> I'm paying to port mvtools... [19:07:37 CET] <durandal_170> michaelni: there are open tickets requesting for sponsor's, can't ffmpeg spend money on such tickets? [19:26:16 CET] <Timothy_Gu> J_Darnley: seems like your h264 patch broke something: http://fatebeta.ffmpeg.org/report/x86_32-msvc14-dll-windows-native/20160205… [19:26:53 CET] <J_Darnley> Oh no [19:32:22 CET] <J_Darnley> hm x86_32 msvc [19:35:49 CET] <J_Darnley> I should have pushed a few minutes earlier then other ones would have tested it too. [19:56:59 CET] <Gramner> hmm, the H.264 deblock strides are int, not ptrdiff_t. but that shouldn't break on 32-bit [19:57:26 CET] <Gramner> should be changed before something breaks on 64-bit though [20:08:59 CET] <BBB> jamrial: I really dont like the define m8 m0 etc. in that patch [20:09:12 CET] <BBB> jamrial: since it only seems to be used in one block and thus will be confusing for people following register data flow [20:09:36 CET] <BBB> jamrial: can you just make that one block use if 64 { if fma3 .. else .. } else .. ? [20:16:32 CET] <durandal_170> fine to push streamselect? [20:16:50 CET] <durandal_170> ^ubitux [20:17:19 CET] <jamrial> BBB: sure, but it will be even uglier than it already is :p [20:17:43 CET] <durandal_170> ubitux: also nlmeans [20:19:10 CET] <BBB> jamrial: ugly but easier to understand, or uglier and more difficult to understand? [20:22:29 CET] <BBB> J_Darnley: on x86-32, the stack alignment is different, youre probably movaing from/to buf0/1 [20:22:33 CET] <BBB> J_Darnley: you cant do that on x86-32 [20:24:22 CET] <BBB> ah its even better [20:24:37 CET] <BBB> J_Darnley: the problem is that youre assigning r0m/r2m and using them in the actual assembly code [20:24:46 CET] <BBB> J_Darnley: that cant be done if youre omitting the stack pointer (negative stack size) [20:25:01 CET] <BBB> J_Darnley: negative stack size means no stack pointer means you cannot, repeat, CAN NOT, use r0m/r2m anywhere in your code [20:25:34 CET] <BBB> Id use a positive stack size and just deal with the fact that it needs a stack pointer on x86-32, that should be ok [20:25:48 CET] <BBB> its only x86-32 msvc that suffers anyway :) [20:26:09 CET] <BBB> cglobal deblock_h_chroma422_8, 5, 6, 0, 0-(1+ARCH_X86_64*2)*mmsize -> cglobal deblock_h_chroma422_8, 5, 6, 0, 0+(1+ARCH_X86_64*2)*mmsize [20:27:04 CET] <Gramner> ah yes, the wonders of having an unaligned stack. having buf0/1 unaligned is fine though (except for some performance hit, but whatever) since this is mmx [20:28:18 CET] <Gramner> don't think the 0+ is required though, the reason for using 0- is because yasm doesn't consider negative numbers to be numbers. [20:28:27 CET] <kierank> J_Darnley: just make it an x86-64 function =p [20:29:16 CET] <Gramner> I fixed that yasm problem in https://github.com/yasm/yasm/commit/32ad9c46cebd5bf07af9c05383d3c16e6cb1f17d btw, but the fix is not in any released version [20:32:07 CET] <jamrial> BBB: found a way to make it less ugly and easier to understand, so neither [20:32:21 CET] Action: J_Darnley can never focus on anything in this place in the evening [20:32:59 CET] <BBB> Gramner: nah, the isnumber is not the issue, it has to be positive, not negative [20:33:12 CET] <BBB> Gramner: if you use the stack arguments (r%dm), you need a stack pointer [20:33:18 CET] <BBB> Gramner: i.e. positive stack size [20:33:28 CET] <BBB> Gramner: negative stack size is only ok if you dont use stack arguments (r%dm) [20:34:11 CET] <Gramner> yes, I knows. I referred to the fact that you need to write negative numbers as 0-x in yasm instead of -x [20:34:32 CET] <J_Darnley> How can you not have a stack pointer? [20:35:03 CET] Action: J_Darnley has too many windows open again [20:35:39 CET] <BBB> imagine that your rsp is A, and you want N bytes of 16-byte aligned memory, and we dont have aligned stack [20:36:00 CET] <Gramner> rNm is an alias for [rsp+<some_value], so it doesn't work if you modify rsp in a way that isn't known at compile-time [20:36:12 CET] <BBB> save rsp to [rsp+sz] [20:36:21 CET] <BBB> then you can restore the pre-aligned stack by mov rsp, [rsp+sz] [20:36:29 CET] <BBB> but you cant have r%dm [20:36:34 CET] <J_Darnley> FUCK CYGWIN! STOP FAILING TO FORK! [20:36:44 CET] <BBB> if you want r%dm, simple save rsp pre-align to a register and call that the stack pointer [20:36:47 CET] <BBB> now r%dm works [20:37:02 CET] <BBB> and Im sorry that youre forced to use cygwin :D [20:37:29 CET] <J_Darnley> I don't need or want to align. [20:37:42 CET] <J_Darnley> I thought that was the whole point of overloading the value with negative numbers. [20:38:08 CET] <Gramner> using negative numbers mean that you store the original stack pointer on the stack instead of in a register [20:38:39 CET] <BBB> if you dont want to align, just sub rsp manually [20:38:41 CET] <J_Darnley> Revert if you want. I'm going off to reboot. [20:38:49 CET] <BBB> :D [20:39:04 CET] <BBB> Id just sub manually in his cse [20:39:07 CET] <BBB> he doesnt need alignment [20:39:30 CET] <BBB> SUB and ADD, right? [20:39:33 CET] <jamrial> other similar functions in that same file do that, yeah [20:39:48 CET] <BBB> yeah so lets use SUB/ADD then [20:39:56 CET] <BBB> instead of the complex stuff he doesnt want [20:43:26 CET] <Gramner> will you send a patch or should I? [21:00:35 CET] <BBB> can you? [21:00:37 CET] <BBB> Im lazy :-p [21:00:44 CET] <Gramner> sure [21:01:30 CET] <Gramner> I ok:ed the patch so it's kind of my fault [21:04:14 CET] <BBB> jamrial: lfe patch is ok like this, ty [21:14:26 CET] <cone-122> ffmpeg 03Paul B Mahol 07master:b1fe794033c8: avfilter/split: support any channel count for asplit filter [21:18:55 CET] <J_Darnley> Now where was I? Oh yes. My bad code. [21:19:12 CET] <Gramner> J_Darnley: I'll send a patch in a few seconds [21:21:20 CET] <Gramner> sent [21:22:27 CET] <JEEB> J_Darnley: btw in cygwin I fixed forking failures by switching to 64bit cygwin on win8+. not sure why exactly it's working better for me, though :D [21:22:35 CET] <J_Darnley> I am on 64 bit [21:22:41 CET] <JEEB> oh well [21:22:44 CET] Action: JEEB pats J_Darnley [21:23:01 CET] <J_Darnley> I must remain calm. [21:23:28 CET] <drv> i think the cygwin fork failures are usually because some DLL gets loaded in the way of some existing address space [21:23:42 CET] <J_Darnley> I already know about the BLODA [21:23:51 CET] <J_Darnley> I don't think I have any instaled [21:24:23 CET] <J_Darnley> The fork failure is intermittent [21:25:33 CET] <J_Darnley> It only occurs, or occurs more often, if I have a lot of windows open and/or a lot of cygwin programs running or suspended. [21:27:12 CET] <J_Darnley> Unfortunately that is usually when I am in the middle of doing things. [21:27:31 CET] <Gramner> somewhat related, my steelseries mouse driver crashes every time I do something that results in heavy cpu usage in msys. [21:28:02 CET] <Gramner> I have absolutely no idea how those two things are related. high cpu usage outside of msys is perfectly fine [21:28:23 CET] <J_Darnley> :D [21:39:37 CET] <cone-122> ffmpeg 03Marton Balint 07master:7e6b788f7c4d: lavf/asfenc: add AVClass to context [21:39:37 CET] <cone-122> ffmpeg 03Marton Balint 07master:046476730102: lavf/asfenc: check the number of streams in header [21:39:38 CET] <cone-122> ffmpeg 03Marton Balint 07master:79e42936137a: lavf/asfenc: add support for storing languages [21:39:40 CET] <cone-122> ffmpeg 03Marton Balint 07master:22bbd6e8b754: lavf/asfenc: add support for storing creation time [21:39:40 CET] <cone-122> ffmpeg 03Marton Balint 07master:6d14e32555ef: lavf/asfenc: add support for setting packet size [21:40:22 CET] <J_Darnley> kierank: before I ragequit earlier you mentioned writing simd for another codec. which one was what? cineform? c-something. [21:41:20 CET] <kierank> Dirac Encoder? [21:41:37 CET] <J_Darnley> Oh d-something then. [22:00:53 CET] <BBB> Gramner: ty for the patch [22:02:42 CET] <cone-122> ffmpeg 03Henrik Gramner 07master:aa751573fef5: avcodec/h264: Fix segfault in 4:2:2 chroma deblock with 32-bit msvc [23:07:35 CET] <kierank> could someone test this on fate [23:07:36 CET] <kierank> http://paste.ubuntu.com/14897412/ [23:07:41 CET] <kierank> I lack the ability to do that currently [23:10:29 CET] <durandal_170> you need to update fate refs also you nowhere extract alpha IIRC [23:12:13 CET] <kierank> but gbrap16 doesn't either? [23:18:36 CET] <michaelni> durandal_170, ffmpeg will candidate for GSoC if someone submits it to google fills out the forms and volunteers as admin, i think someone should do this. I do voluneer as backup admin if there are 1-2 other admins who are wiling to do a significant part of the work [23:19:52 CET] <durandal_170> michaelni: what's all needed? [23:20:24 CET] <michaelni> also if someone does the submit thing then ask me/saste/reynaldo for the list of awnsers used previously, it likely can be reused to a large extend [23:21:38 CET] <michaelni> i dont know whats needed for this year, last time it was filling out some forms, making sure the wiki page is in shape before the deadline as google checks it, find people to volunteer for mentoring [23:22:56 CET] <Gramner> https://msdn.microsoft.com/en-us/library/mt240585.aspx why microsoft? their way of doing 4:4:4 H.264 is apparently to split a 4:4:4 stream into two 4:2:0 streams and then recombining them again in the decoder [23:23:36 CET] <michaelni> also about the previous awnsers iam not sure where i put them maybe reynaldo or saste remember/have them [23:23:58 CET] <Gramner> why use standardized 4:4:4 mode of H.264 when you can do some crazy hacks instead? [23:26:55 CET] <wm4> Gramner: lol [23:32:25 CET] <durandal_170> michaelni: do I need prove me is me, sign up forms, etc... [23:32:30 CET] <Gramner> at least they finally realized that encoding the screen as a video stream is way superior to the existing remote desktop protocol. might be able to get more than 0.5 fps over slow connections with the new rdp version [00:00:00 CET] --- Sat Feb 6 2016

1 0

ffmpeg.log.20160205
by burek 06 Feb '16

06 Feb '16

[05:57:37 CET] <Elronnd> Not sure if this is the right place to ask, but [05:57:57 CET] <Elronnd> converting an mkv to an mp4 only shaved off 0.3 GB, is there a way to take off more? [05:58:31 CET] <chungy> I'm surprised you got such a saving, was that with "-c copy"? [05:58:45 CET] <chungy> But in general, not really. Metadata from the containers aren't typically very large. [05:59:20 CET] <Elronnd> ah, okay then [05:59:23 CET] <Elronnd> thanks anyway [06:22:25 CET] <satinder> Hi anyone here [07:20:20 CET] <satinder> ?? [07:34:01 CET] <relaxed> ask a ffmpeg related question [07:55:06 CET] <chungy> Please state the nature of your media emergency [10:37:06 CET] <canhtak> Hi guys, Ive a little problem while using ffmpeg and I cannot figure out how to solve it. [10:38:09 CET] <canhtak> Im trying to call ffmpeg using std::system from a C++ program. The call to std::system is made from a child created using fork() which is then detached from the parent process. [10:39:03 CET] <canhtak> ffmpeg is launched properly from this process, but stop just after the print of the version + the configuration. [10:40:01 CET] <canhtak> Any one knows if ffmpeg do something special internally which do not allow my to start it inside a child process with its own group ? [10:43:33 CET] <furq> canhtak: it should work fine [10:45:14 CET] <canhtak> furk: it does not for me, we can build a ten line C code if I share it for test ? [10:45:31 CET] <furq> i just tested it with system(3) on freebsd [10:45:42 CET] <furq> http://www.lua.org/source/5.2/loslib.c.html#os_execute [10:45:46 CET] <furq> or with that, which is close enough [10:45:46 CET] <canhtak> you changed the group of the child process ? [10:45:56 CET] <furq> oh [10:46:05 CET] <furq> no, but i can't imagine that would affect it [10:46:16 CET] <canhtak> nope me to in the first time. [10:46:31 CET] <canhtak> everything work if I dont change the child process group [10:46:54 CET] <canhtak> but I need to change it to be sure to handle signals from the parent and allow my child to terminate their work with ffmpeg [11:33:26 CET] <Triage> Hi. What's a good way to repair a mp4 that plays back fine but doesn't seek correctly? [11:38:53 CET] <relaxed> Triage: seeks in what? Try, ffmpeg -i input.mp4 -c copy -movflags +faststart output.mp4 [11:41:08 CET] <Triage> well I use MPC-HM as my play back software... which I believe uses the same backend as ffmpeg [11:41:19 CET] <Triage> will try that command in a couple minutes... thanks :-) [11:48:32 CET] <Triage> yep worked a jiff [11:48:53 CET] <Triage> so -c is copy codec right? what do the others do? [11:49:22 CET] <furq> -movflags +faststart puts the moov atom at the start so that web players don't have to download the whole file to start playing it [11:49:31 CET] <furq> i doubt that had any effect if you were playing it locally [11:51:37 CET] <Triage> so ffmpeg just kinda repairs it automatically? [11:52:59 CET] <furq> that command copies the streams into a new container [11:53:04 CET] <furq> so if the old container was somehow broken then that will fix it [11:53:38 CET] <Triage> ah [11:53:53 CET] <Triage> & if it had been the streams in the container that were broken? [11:54:21 CET] <furq> then your job gets a lot harder [11:56:40 CET] <furq> canhtak: it seems that it should work with -nostdin [11:57:13 CET] <canhtak> furq: I tried to with -nostdin but do not work too & [11:58:13 CET] <canhtak> it seems that -nostdin specify that we dont want ffmpeg to use the commandling because he is running in background, bug not specialy becaus we want it to run inside another group... [11:59:54 CET] <furq> shrug [12:00:08 CET] <furq> i tried it with posix_spawn and POSIX_SPAWN_SETPGROUP and it doesn't work without -nostdin [12:01:49 CET] <furq> hopefully someone who actually knows their way around the internals will know why [12:05:44 CET] <canhtak> furq: I have to go, I really thank you for the time you spent on my problem, Ill try to figure it out by myself. [12:05:45 CET] <canhtak> see ya [12:10:30 CET] <hawke_> good morning [12:12:15 CET] <hawke_> can i get someone to take a look at this and tell me what i am doing wrong http://pastebin.com/iGCmc1PA [12:14:00 CET] <Zitter> Hi, I have "Error setting option pix_fmt to value -1" and "Error applying options to the filter" errors doing this: http://pastie.org/10709829 any hint? I'm new to ffmpeg [12:25:14 CET] <hawke_> zitter what os are you using [12:27:10 CET] <Ccdc_DuckZ> good morning [12:28:11 CET] <Ccdc_DuckZ> I'm trying to create an animated gif, and I'm following the example here: http://ffmpeg.org/doxygen/2.8/decoding_encoding_8c-example.html but it's not specifically about gifs, so I'm wondering if there are better resources around? [12:28:51 CET] <Ccdc_DuckZ> like in video_encode_example(), I don't think I need to set gop_size or max_b_frames, that doesn't sound like it would make sense in the gif world [12:29:43 CET] <Zitter> hawke_, debian 8 [12:29:59 CET] <hawke_> are you streaming zittler [12:32:33 CET] <Zitter> what do you mean? [12:33:14 CET] <Zitter> I have a .mp4 movie (duration 2 minutes) that I would like to fade-to-black to last 10 seconds [12:35:44 CET] <hawke_> ok sorry i dont know how your using the ffmpeg encoder, but couldnt you use editing software to achieve what you want.....i dont know [12:37:51 CET] <hawke_> sounds like your using it for html.....but i am new also....trying to use the ffmpeg encoder for a script call ampache [12:52:56 CET] <Ccdc_DuckZ> how cool, I never realized they had accepted my wtf :D http://thedailywtf.com/articles/a-hardware-switch [13:24:18 CET] <FilipeMaia> Hi. Could anyone point me to an example of using the API for h264 decoding? [13:24:44 CET] <JEEB> should be similar to any other decoding, see the exmaples under doc [13:26:02 CET] <FilipeMaia> JEEB: I tried the decoding_encoding.c example (ffmpeg/doc/examples/decoding_encoding.c), and while it encodes and decodes and for other formats, for h264 it only encodes [13:26:23 CET] <FilipeMaia> JEEB: I tried to change the code the also do decoding but it did not work [16:23:21 CET] <FilipeMaia> Hi. Could anyone point me to an example of using the API for h264 decoding? [16:25:57 CET] <Ccdc_DuckZ> if I include libavcodec/avcodec.h in my c++ code I get linking errors, and after a lot of time spent looking at the output of objdump and nm I figured out my code was trying to find mangled symbols in libavcodec and failed because that's c code [16:26:14 CET] <Mavrik> Ccdc_DuckZ, doh. [16:26:24 CET] <Mavrik> There's a reason extern "C" exists. [16:26:26 CET] <FilipeMaia> Ccdc_DuckZ: live and learn [16:26:34 CET] <Mavrik> But yeah, that one is fun. [16:26:35 CET] <Mavrik> :) [16:26:46 CET] <Ccdc_DuckZ> I assumed headers just had if defined(__cplusplus) extern "C" {} in them [16:26:59 CET] <J_Darnley> Don't ask C programmers and C library to do your mangling for you! [16:27:12 CET] <Ccdc_DuckZ> am I supposed to wrap the include in extern "C" myself with avcodec? [16:27:17 CET] <J_Darnley> Yes! [16:27:21 CET] <Ccdc_DuckZ> -_- [16:27:36 CET] <furq> you could ask a friend to do it for you [16:28:06 CET] <J_Darnley> FilipeMaia: wnat about the examples in the source? [16:28:13 CET] <J_Darnley> in doc/examples I think [16:28:19 CET] <FilipeMaia> J_Darnley: no h264 decoding [16:28:23 CET] <Ccdc_DuckZ> I think this just overwelmed my tolerance for ugliness for this month... [16:28:41 CET] <Ccdc_DuckZ> luckily it's february [16:28:44 CET] <Mavrik> FilipeMaia, that example works just fine for h264 decoding. [16:28:46 CET] <J_Darnley> What do you mean? I think they show how to use the API [16:28:48 CET] <FilipeMaia> J_Darnley: the decoding_encoding.c example doesnt have h264 decoding, even though it has encoding [16:28:49 CET] <Mavrik> It's not format specific. [16:29:09 CET] <FilipeMaia> I added the following line to the example video_decode_example("test%02d.pgm", "test.h264"); [16:29:14 CET] <Mavrik> There aren't example for every of 100+ formats ffmpeg supports. [16:29:23 CET] <FilipeMaia> but didnt get any output [16:29:40 CET] <J_Darnley> "no output" is not an error message! [16:29:41 CET] <FilipeMaia> But for mpg and mp2 theres both decode and encode [16:29:48 CET] <FilipeMaia> J_Darnley: I mean no pgm files [16:30:01 CET] <Mavrik> What are you talking about -_- [16:30:11 CET] <J_Darnley> Still not an error message! [16:30:33 CET] <FilipeMaia> J_Darnley: no one said anything about error messages [16:30:53 CET] <J_Darnley> As a side note: we can't possibly have a colossal 2D matrix of every possible input and every possible output. [16:31:18 CET] Action: J_Darnley goes back to programmin. [16:31:35 CET] <FilipeMaia> Im talking about https://www.ffmpeg.org/doxygen/2.1/doc_2examples_2decoding_encoding_8c-exam… [16:32:17 CET] <FilipeMaia> It does encode and decode for mp2 and mpg, but only encoding for h264 [16:32:44 CET] <FilipeMaia> I tried to add an equivalent line for h264 decoding but I didnt get any output [16:32:57 CET] <FilipeMaia> and was just asking if theres any example available of h264 decoding [16:34:24 CET] <drv> video_decode_example() in that program is hardcoded to look up the MPEG-1 video decoder [16:34:29 CET] <drv> you would at least need to change this line: codec = avcodec_find_decoder(AV_CODEC_ID_MPEG1VIDEO); [16:35:16 CET] <FilipeMaia> drv: many thanks [16:50:12 CET] <kbarry> I'm pretty new to streaming media (which has included a lot of playing/reading about ffmpeg), [16:50:23 CET] <kbarry> I've been trying to find books, or other sources of information for Getting a much better understanding of streamable media, streaming , etc. [16:51:19 CET] <kbarry> I have read a book on ffmpeg usage, which has been helpful, but am still looking to learn more. It seems a lot of this information may be organizational. [16:51:38 CET] <kbarry> I'd like some recommended rendings, if that is appropriate to ask here. [16:52:33 CET] <kbarry> Also, are there sites/blogs that someone who is getting into the digital/streaming media world should frequent, or atleast know about? [16:53:02 CET] <Ccdc_DuckZ> I'm also following the example code, but for me avcodec_find_encoder(CODEC_ID_GIF) just returns null, should I initialize the library before that call or do anything else? I built my ffmpeg with [16:53:06 CET] <Ccdc_DuckZ> --disable-gpl --disable-nonfree --disable-version3 --disable-all --disable-everything --disable-static --enable-shared --disable-small --enable-runtime-cpudetect --disable-gray --enable-avutil --enable-avcodec --enable-pthreads --enable-avformat --enable-muxer=gif --enable-encoder=gif --enable-filter=color --prefix=$HOME/apps/ffmpeg [17:02:33 CET] <drv> i think you need to do avcodec_register_all(); first [17:04:05 CET] <Ccdc_DuckZ> drv: thanks, that might be it [17:04:24 CET] <Ccdc_DuckZ> drv: do you think it's safe to call it multiple times? ie: put it in my class' constructor? [17:05:04 CET] <Ccdc_DuckZ> I can't see anything on that in the docs [17:05:57 CET] <drv> I think that may have been removed actually, my knowledge is out of date [17:06:39 CET] <drv> never mind, it's still there, see libavcodec/avcodec.h [17:07:38 CET] <drv> it looks like it has a check internally to prevent initializing twice, but the docs don't say anything about it [17:39:06 CET] <kbarry> What is the word for different packaging systems for content [17:39:23 CET] <kbarry> ie, HLS/ RTMP / MPEG-DASH [17:41:30 CET] <Mavrik> I guess streaming protocol? :) [17:42:16 CET] <cortexman> what's the best video player for hosting a 5GB video on my own website [17:42:30 CET] <cortexman> i need good support for changing the playback speed [17:54:24 CET] <maslen1> I'm trying to strip the rotational metadata from an image without re-encoding. How can I? I tried using: ffmpeg -i "file_flipped_2.mp4" -c:a copy -c:v copy -metadata:s:v:0 "file_flipped_2.mp4" , but I got an error that "at least one output file must be specified" [17:55:02 CET] <maslen1> (typo on the input file, it was initially "file_flipped.mp4", so it did have a different filename) [17:56:33 CET] <maslen1> oh, got it. I had to specify rotate=0 [21:24:51 CET] <DHE> I have a video being processed (live source) and some kind of error has caused the AC3 decoder to just go haywire and stop processing audio. It just produces some kind of tone now. Is there a way to reset the decoder on-the-fly? (code modifications are okay) [21:44:52 CET] <dc786> How do I set the source to Composite1 for old Hauppauge on ffmpeg, using v4l2? [21:46:26 CET] <dc786> Seems to default to Television (analog). [21:55:35 CET] <triquad> Howdy yall! I'm compiling the CLI for Android and am having trouble getting hw acceleration to work -- has anybody done this successfully? CLI output and build configuration: http://pastebin.com/rSvHigrV [21:56:31 CET] <JEEB> none of those you tried to enable should work on ARM or linux [21:57:03 CET] <JEEB> does it actually succeed at configuring :P [21:57:07 CET] <JEEB> I'd be surprised [21:57:49 CET] <triquad> Yes, it's compiling and can transcode videos, albeit verrrrry slowly [21:58:44 CET] <JEEB> confirm what the configure script outputs [21:59:05 CET] <JEEB> it's not supposed to actually not fail if you try to enable things that aren't supposed to work [21:59:33 CET] <JEEB> unless the fact that you're running ARM just ignores those since all except for DXVA2 are intel arch only [21:59:37 CET] <JEEB> and DXVA2 is windows only [21:59:54 CET] <JEEB> and you are running ARM _and_ linux [22:00:08 CET] <JEEB> that said, it should still fail [22:00:38 CET] <JEEB> "no, you dumdum, those don't work a" is what you should be getting from the configur escript [22:01:26 CET] <JEEB> also [22:01:50 CET] <JEEB> also that ffmpeg command line output shows a completely different configure line? unless it's cut [22:04:42 CET] <jkqxz> The name suggests it's an Atom x5 (i.e. Cherry Trail x86-64, not ARM). Does libva work on Android? [22:05:28 CET] <JEEB> yeah, I did notice that, but he was building for ARM [22:05:38 CET] <JEEB> arm-linux-androideabi-4.9 [22:05:48 CET] <JEEB> and intel based devices have a surprisingly good arm emluation [22:06:02 CET] <JEEB> granted, it would most probably be much faster to just build for IA32/x86_64 :P [22:06:15 CET] <JEEB> because there's *plenty* of intel arch optimizations in FFmpeg [22:06:41 CET] <JEEB> although I remember that recent changes in Android and how it requires some stuff broke intel arch builds [22:07:08 CET] <JEEB> and my guess would be that it's completely different APIs that power the Android HWDEC [22:07:33 CET] <JEEB> that said, if you would have va-api there you could in theory use it if you had the headers and libs to link against [22:07:40 CET] <JEEB> (will most probably not come with NDK) [22:07:52 CET] <jkqxz> Right, yes. Some clarity over what the target actually is would probably help. [22:07:54 CET] <triquad> you're right, configure isn't working (ERROR: libx264 not found) -- it was just making from the last time configure did work [22:08:20 CET] <triquad> it's Cherry Trail ARMv7 [22:09:08 CET] <jkqxz> Those two things are contradictory. [22:10:14 CET] <JEEB> I mean, the android builds will have intel's arm emu [22:10:24 CET] <JEEB> so arm binaries will work [22:10:35 CET] <JEEB> but afaik that stuff isn't arm [22:11:43 CET] <JEEB> I think on android your best bet is mediacodec [22:11:44 CET] <triquad> $ cat /proc/cpuinfo => Processor : ARMv7 processor rev 1 (v71), BogoMIPS: 1500.0, Features: neon vfp swp half thumb fastmult edsp vfpv3 vfpv4 idiva idivt [22:13:31 CET] <jkqxz> Ok, so actually you are cross-compiling from a different machine, which happens to have an x86-64 tablet chip in it. Apologies for the noise there, then. [22:14:24 CET] <triquad> yeah exactly, should have clarified, cross-compiling from a Mac [22:16:39 CET] <JEEB> anyways, your best bet under android is mediacodec, but you will not be able to use it from ffmpeg cli [22:16:51 CET] <JEEB> not that you'd want to use it from the cli in your app [22:20:49 CET] <triquad> this is for a media server running on an embedded device -- will be headless Android -- so it's been nice having the CLI for prototyping (have been using it with an Odroid device to good effect) [22:22:33 CET] <JEEB> basically very few (albeit nowadays more than before) hwaccels have been implemented in the ffmpeg cli app [22:22:56 CET] <JEEB> as hwaccels require more handiwork from you than decoders [22:37:35 CET] <triquad> If I'm I go the MediaCodec route, I guess the purpose of integrating ffmpeg would be to extend video format support beyond those built-in to MediaCodec? Found this article: http://intel.ly/1TJryGl -- does it seem like a sane approach? [00:00:00 CET] --- Sat Feb 6 2016

1 0

ffmpeg-devel.log.20160204
by burek 05 Feb '16

05 Feb '16

[00:00:30 CET] Action: TD-Linux 's habit of collecting retro hardware means he will never fully escape the touch of sjis [00:00:35 CET] <RiCON> i'm not a programmer so I don't know whether it'd be easier to add support to the native decoder or updating the wrapper, so opinion on dropping the wrapper [00:00:49 CET] <RiCON> no opinion* [00:02:09 CET] <JEEB> I know it's not as optimized as the VFW version at least. it's not slow but there's a whole whoop-ass-load of asm in the VFW build of official ut video [00:02:43 CET] <JEEB> the original implementation is GPL so you couldn't just take the asm from there [00:04:17 CET] <JEEB> threading should be better on our side since the VFW version at least is limited to sliced threading - which at least in the short experiments we did was slower than image-based threading [00:04:39 CET] <JEEB> also I think the encoder lacks support for the interlacing-specific coding mode [00:05:24 CET] <JEEB> and then 10bit, yes [00:06:18 CET] <Daemon404> i dont think throughput is your goal on utvideo [00:06:29 CET] <Daemon404> it used sliced threads specifically for low delay NLE support [00:06:33 CET] <JEEB> yeah [00:07:14 CET] <JEEB> anyways, most of those things come from the VFW version only, so they're most probably unrelated to the hackjob of libutvideo [00:07:56 CET] <JEEB> and yeah, as I thought [00:07:59 CET] <JEEB> from qyot's e-mail [00:07:59 CET] <JEEB> libutvideoenc is locked to only one prediction type, and the speed [00:07:59 CET] <JEEB> issues in either the encoder or decoder wrapper could (probably are) [00:08:00 CET] <JEEB> the side-effect of libutvideo not enabling the asm by default [00:08:31 CET] <Daemon404> the asm crashes on x86_64 btw. from what i remember. [00:09:05 CET] <JEEB> so, uh, 10bit is the only real reason except for mini's reasoning of "it makes it simpler to test against official", which isn't really true because it's not really official... [00:09:50 CET] <Daemon404> nor is it simple [00:10:05 CET] <Daemon404> like i said. tomorrow. [00:10:08 CET] <JEEB> ye [00:10:15 CET] Action: JEEB hits the sack [00:27:30 CET] <J_Darnley> Good job sorting those files Windows! You really know your alphabet! [00:50:28 CET] <jya> BBB: with libvpx, you can feed pretty much any vp9 stream and if there's a change iin resolution or whatever, t happily chum along and output a different image size [00:51:25 CET] <jya> does ffvp9 handle it as nicely (we're looking at how we can play webrtc recordings, which are just plain raw vp9 streams appended in series) [00:55:02 CET] <Daemon404> i think youll probably get avframes with a different res [00:55:06 CET] <Daemon404> but dont quote me [00:59:32 CET] <iive> wm4: still wondering about the has_b_frame thing? [00:59:55 CET] <iive> I think you are confusing few things. [01:16:35 CET] <BBB> jya: yes [01:16:53 CET] <BBB> jya: we have been tested with a wide variety of streams, like compiler-generated ones that trigger every branch in libvpx [01:17:06 CET] <BBB> jya: and the output for every single one of these streams is bitexact between libvpx and ffvp9 [01:17:27 CET] <jya> BBB: so the ffvp9/8 will simply output a picture with a different size ? [01:17:39 CET] <BBB> jya: yes (as Daemon404 said, check AVFrame->width/height) [01:17:51 CET] <BBB> it will change between frames if the resolution changed from one frame to the next [01:17:54 CET] <jya> excellent. thank you [01:18:05 CET] <BBB> AVCodecContext->width/height is the output of the last decoded frame [01:18:18 CET] <BBB> which may be entirely different than AVFrame->width/height, although its usually the same [01:18:38 CET] <BBB> jya: our test suite also includes a few sequences that change size [01:18:56 CET] <BBB> jya: chrome also has a few of these, you can pick whichever of them you prefer for your unit tests if you want them [01:19:11 CET] <jya> ok [01:29:04 CET] <jya> BBB: so looking at the AVPicture, it's a simple matter of reading width/height. What about aspect ratio ? is this something it will adjust too (checking our code we use the A/R as defined in the container and so doesn't change over time) [01:36:41 CET] <BBB> jya: I believe AVFrame also has a sample_aspect_ratio or so [01:37:02 CET] <BBB> https://ffmpeg.org/doxygen/trunk/structAVFrame.html#a62f9c20541a83d37db7072… [01:37:07 CET] <BBB> AVRational AVFrame::sample_aspect_ratio [01:37:34 CET] <jya> thank you for that [01:37:42 CET] <BBB> thats the one defined in the bitstream [01:37:55 CET] <jya> what about the offset ? [01:38:09 CET] <BBB> what is offset? [01:38:30 CET] <jya> let me find you sample from our regression test [01:38:43 CET] <jya> this is something neither VLC nor Chrome display properly [01:39:50 CET] <BBB> well thats not good [01:39:53 CET] <jya> it's a video that defines clipping [01:40:05 CET] <jya> it's ignored by VLC/Chrome [01:41:17 CET] <BBB> Ive never heard of this [01:42:55 CET] <Timothy_Gu> michaelni: ok [01:45:19 CET] <jya> BBB: ah found it [01:45:23 CET] <jya> this regression test: https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-vi… [01:45:37 CET] <jya> this should display a small black square [01:45:57 CET] <jya> chrome displays a green one with the black square in it [01:48:09 CET] <jya> ffplay does it wrong too; https://hg.mozilla.org/mozilla-central/raw-file/tip/layout/reftests/webm-vi… [01:48:24 CET] <jya> it's vp8 though [01:49:35 CET] <jya> mkvinfo shows that the picture is 64x64, with display is 29x29 with a crop of (29, 4, 6, 31) [01:50:10 CET] <Compn> what displays it correctly ? [01:50:19 CET] <jya> firefox of course :) [01:50:49 CET] <Compn> fair enough [01:51:06 CET] <Compn> does ffmpeg support autocrop ? hmm [01:51:11 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:61ea7f15094d: swscale/swscale-test: Check av_image_fill_linesizes() for failure [01:51:28 CET] <Compn> container crop i should say. or is it vp8 cropping like h264 cropping mhmmm [01:51:50 CET] <jya> this is why in our FFmpeg decoder, we use what we read in the demuxer to determine the display size (and AR and cropping info) [01:52:17 CET] <jya> now to support change of resolution mid-stream, I have to rely on FFmpeg to report the right info [02:01:29 CET] <BBB> Ive never heard of this offset thing TBH [02:02:00 CET] <Daemon404> sounds liek container cropping... i thought webm would have not included that in its subset [02:02:42 CET] Action: Daemon404 sleeps [02:03:56 CET] <jya> BBB: yeah, I'm stuck between a rock and a hard place. Because if I want to pass our reftest and display that silly box properly, I have to use the dimension+offset+cropping from the container [02:04:06 CET] <BBB> I dont see any cropping elements in the metadata when I run ffprobe [02:04:14 CET] <BBB> I also dont see any offset elements in the vp8 header [02:04:24 CET] <BBB> ok so its container [02:04:27 CET] <BBB> I dont know how that works [02:04:28 CET] <BBB> :) [02:04:34 CET] <jya> but if I want to be able to handle the change of resolution in the VP stream, I have to use the FFmpeg dimensions which don't tell me anything about it [02:05:02 CET] <BBB> MATROSKA_ID_VIDEOPIXELCROPB [02:05:10 CET] <BBB> right [02:05:14 CET] <jya> I guess I could craft a work around, such as for the first stream we use the dimensions found in the container. [02:05:16 CET] <BBB> so I dont know how to handle it TBH :) [02:05:23 CET] <jya> and if we detect a change, we only use FFmpeg ones [02:05:27 CET] <BBB> the container defines it per-stream obviously [02:05:44 CET] <BBB> but the codec/bitstream may change size per stream, hypothetically [02:05:48 CET] <BBB> this is obviously not intended [02:05:49 CET] <BBB> just saying [02:05:51 CET] <jya> BBB: sure, but since it can only defines it for a single stream [02:05:58 CET] <BBB> ? [02:06:00 CET] <BBB> rly? [02:06:17 CET] <BBB> it looks like matroska can do it for each video stream? [02:06:21 CET] <BBB> in the video stream header [02:06:21 CET] <jya> I mean, the webm has a single "element information" cluster, [02:06:28 CET] <BBB> (track) [02:06:54 CET] <BBB> video cropping info is in the video track element, not information element [02:07:07 CET] <jya> yeah, via the via PrevUID/NextUID in mkv [02:07:11 CET] <jya> but that's not allowed in webm [02:07:16 CET] <BBB> oh [02:07:18 CET] <BBB> well [02:07:22 CET] <BBB> then I dont know :D [02:12:54 CET] <Compn> why have res changes mid stream [02:12:55 CET] <Compn> whyyyyyyy [02:12:59 CET] <Compn> :P [02:14:53 CET] <atomnuker> to make life difficult and render all init allocations useless [02:16:50 CET] <atomnuker> well, not entirely useless, in the Daala decoder I do all the allocs in the init function but realloc my buffers if the dimensions change [02:19:21 CET] <jya> Compn: it's used for stuff like recording a video-call stream [02:19:38 CET] <jya> resolution changes often there depending on the network quality [02:19:52 CET] <Compn> you dont just axe bitrate but res too ? haha [02:20:11 CET] <jya> make seeking into those files interesting too [02:20:32 CET] <jya> Compn: that's a fair point actually [02:21:32 CET] <BBB> seeking doesnt change [02:21:36 CET] <BBB> go to nearest keyframe and go from there [02:21:44 CET] <BBB> res change does not change that [02:21:57 CET] <cone-465> ffmpeg 03Michael Niedermayer 07master:37db3e8931f6: avcodec/libutvideoenc: Add NULL termintor to options [02:23:01 CET] <Timothy_Gu> who handles the SSL certs for ffmpeg.org? [02:23:40 CET] <Compn> some root [02:23:46 CET] <Compn> either michael ? alex ? [02:23:59 CET] <TD-Linux> Compn, modern video codecs are not scale independent, so at some point switching resolution is better [02:24:13 CET] <Compn> of course, i'm just curious. i'm not saying anything is bad [02:24:15 CET] <TD-Linux> and VP9 lets you switch resolution without inserting an I frame, which works quite well for videoconferencing [02:24:18 CET] <michaelni> reimar handles the certs [02:24:25 CET] <Timothy_Gu> ok [02:24:30 CET] <BBB> TD-Linux: hows the files coming along? do you have an invoice for me already? [02:25:03 CET] <TD-Linux> BBB, it's actually copying as I speak, should ship tomorrow (you'll get a tracking #) [02:25:05 CET] <jya> BBB: finding the nearest keyframe is the tricky bit, those webm do not have cues in them [02:25:36 CET] <llogan> Timothy_Gu: is there something wrong with them? [02:27:17 CET] <TD-Linux> note that for cropping vp9 via RTP header extensions, this problem was solved and the crop is defined in 0-1 units [02:27:52 CET] <TD-Linux> this might be something to bring up with CELLAR so that mkv can be fixed [02:43:36 CET] <BBB> TD-Linux: oh, cool! [02:44:09 CET] <BBB> jya: my stream analyzer simply scan the whole file frame-by-frame if theres no idnex [02:45:53 CET] <BBB> TD-Linux: ty! Ill paypal you as soon as you email me the amount to transfer [05:50:46 CET] <cone-847> ffmpeg 03James Almer 07master:b3b0ecee1550: x86/emms: empty the mmx state unconditionally on supported targets [12:06:10 CET] <michaelni> all my fate clients are offline till 16 utc due to elektricans in the house and unpredictable power outages [12:08:31 CET] <J_Darnley> :( [12:08:55 CET] <J_Darnley> Those poor computersbeing deprived of precious electricity [12:14:09 CET] <wm4> yeah, I don't understand this, I mean they don't remove all oxygen from the air when e.g. changing windows, do they? [12:19:28 CET] <cone-481> ffmpeg 03Hendrik Leppkes 07master:a969a914f558: dca_parser: ensure frame duration matches the actual sample rate [13:27:44 CET] <wm4> iive: I'm still confused about it, but I also made a dumb mistake in my thinking somewhere [13:53:06 CET] <wm4> lovely cryptic error messages [13:53:23 CET] <nevcairiel> openssl errors are fun [13:53:52 CET] <iive> wm4: i figured. [13:54:00 CET] <nevcairiel> speaking of ssl, i'm somewehat amazed that my schannel support didnt crash and burn in some way [13:55:37 CET] <wm4> nevcairiel: why would it catch fire? [13:55:43 CET] <iive> wm4: think of it this way. B frames need past and future reference. You have to decode the future frame out-of-order and keep it. [13:56:24 CET] <nevcairiel> wm4: dunno, its hard to get something like this right the first try [13:56:37 CET] <iive> wm4: so if you have decoded order of: [13:56:42 CET] <iive> I1 B B B I2 [13:56:52 CET] <iive> you get bitstream of [13:57:03 CET] <iive> I1 I2 B B [13:57:09 CET] <iive> you could decode it as: [13:57:32 CET] <iive> I1 __ B B (I2) [13:57:53 CET] <iive> if you delay by one frame you get: [13:58:05 CET] <iive> __ I1 B B I2 [13:58:14 CET] <wm4> yeah, I understand that much [13:58:36 CET] <iive> ok, what is that you don't understand? [13:58:44 CET] <wm4> what I'm confused about is the relationship between has_b_frames, num_reordered_frames, and delay vs. maximum reorder [13:59:10 CET] <nevcairiel> has_b_frames is set to num_reorder_frames if its present, but its generally not since it requires a constrained bitstream [14:00:19 CET] <wm4> so if I understand this right, in the worst case lavc/lavf "probes" has_b_frames by trying to output 1 frame? [14:01:14 CET] <nevcairiel> yes but its not reliable to probe it, since this value may not be constant throughout the entire stream, ie. the first gop could use less references and therefor re-ordering because the scene was simple and more didnt make sense for the encoder [14:01:26 CET] <nevcairiel> so it could always change a bit later [14:01:55 CET] <wm4> increasing the delay is not so bad, lavc can just not return a frame [14:01:56 CET] <nevcairiel> the only way to have a reliable result is to use -strict 1 which assumes the maximum reordering for the allowed level [14:02:40 CET] <nevcairiel> (of course level could also change in weird bitstreams, so there is that) [14:04:32 CET] <iive> isn't the output of 1 frame, because the needed info is not stored in extradata, but muxed in the video stream? [14:38:53 CET] <Daemon404> [12:56] <@nevcairiel> wm4: dunno, its hard to get something like this right the first try <-- im sure curl had many tries ;) [15:07:30 CET] <nevcairiel> well sure, but still plenty that could go wrong porting something like that [15:15:08 CET] <cone-481> ffmpeg 03Michael Niedermayer 07master:f89bc661b429: avfilter/af_afftfilt: Set last_expr to the default [15:25:48 CET] <JEEB> which audio filter is the one used by -ac ? [15:25:52 CET] <JEEB> or do I just set -ac [15:26:02 CET] <nevcairiel> -ac uses swresample of course [15:26:14 CET] <JEEB> yes, I know that [15:26:16 CET] <nevcairiel> but just set -ac if you want to change number of audio samples [15:26:23 CET] <JEEB> channels, but yes [15:26:29 CET] <nevcairiel> ah yeah [15:26:30 CET] <nevcairiel> typo =p [15:26:44 CET] <JEEB> ok, I will do that then. I just had an audio filtering thing in filter_complex already [15:26:55 CET] <JEEB> so I thought I'd just make it downmix to stereo and then do what I'm doing after that [15:27:04 CET] <JEEB> but I guess I'll just deal with -ac 2 [15:27:54 CET] <nevcairiel> not sure if it passes the audio through lavfi for -ac or just calls swr manually [15:29:16 CET] <nevcairiel> looks like it uses the aresample filter for all that [15:46:22 CET] <ubitux> JEEB: you insert an aformat filter [15:46:30 CET] <ubitux> just like you would use a format [15:46:41 CET] <ubitux> it creates constraints, and auto scaler/resampler are inserted [15:47:08 CET] <ubitux> aformat=channel_layouts=stereo for instance [16:00:12 CET] <JEEB> oh right [16:00:15 CET] <JEEB> ubitux: thanks [16:22:07 CET] <ubitux> ffmpeg user ml is on fire [16:23:38 CET] <wm4> how so [16:23:53 CET] <ubitux> top posting "debate" [16:30:32 CET] <fritsch> i just read it [16:30:37 CET] <fritsch> i want my time back [16:30:46 CET] <fritsch> one troll but 5 other troll feeders [16:44:49 CET] <rcombs> I'm for team "who gives a shit" [16:45:06 CET] <rcombs> as I am in most internet debates [16:49:48 CET] <atomnuker> I just lit a fire and sent it off to the ML [16:50:08 CET] <atomnuker> I suggest people to grab some popcorn and salt [16:50:25 CET] <Daemon404> i disagree [16:50:35 CET] <wm4> popcorn with salt? [16:50:40 CET] <Daemon404> i think mixed code and decls is a bad coding practice. [16:50:59 CET] <Daemon404> along with VLAs. [16:51:22 CET] <Daemon404> (for loops, i dont mind) [16:51:25 CET] <wm4> I'm for declaring variables where you need them, instead of letting them accumulate on the top [16:51:38 CET] <Daemon404> block scope != top [16:51:57 CET] <Daemon404> if you have a buttload of vars declared at the top, i argue you have other problems [16:53:14 CET] <J_Darnley> I've seen some code which evades that by just opening a new block. No conditional and sometimes wrong indentation. [16:53:55 CET] <atomnuker> yep, and that's ugly IMO [16:54:41 CET] <atomnuker> I could probably shorten the AAC encoder by at least 150 lines if I could insert variables when I needed them and avoiding int i type declarations [16:56:26 CET] <kierank> yes my code does that [16:56:27 CET] <kierank> it's horrid [16:56:34 CET] <kierank> but for the VLC reader you have no choice [17:09:47 CET] <nevcairiel> its really not such a bad rule if you keep close attention to declare variables in the blocks that use them and not shove them all at the function start [17:10:03 CET] <nevcairiel> the only thing thats really somewhat annoying is loop counters, as others have already mentioned [17:14:04 CET] <BtbN> Just declare all single-letter vars as global static thread-local vars, problem solved! [17:15:13 CET] <jamrial> ubitux: did you try andreas' patch for the lcov issue? [17:15:25 CET] <ubitux> didn't have time yet [17:15:34 CET] <ubitux> maybe i'm going to do it now [17:15:51 CET] <ubitux> but i'm in the middle of sth so probably later [17:24:30 CET] <jamrial> alright [17:40:32 CET] <cone-481> ffmpeg 03Carl Eugen Hoyos 07master:a36c737490d9: lavf/isom: Add more code points for H264. [18:03:37 CET] <cone-481> ffmpeg 03Paul B Mahol 07master:f862ff750b48: avfilter/vf_stack: free input pads name on uninit [18:19:23 CET] <Timothy_Gu> llogan: wanted to ask if fate[beta].ffmpeg.org could use SSL as well [18:19:46 CET] <nevcairiel> fatebeta should be called fatebetter [18:19:54 CET] <Timothy_Gu> also wondering when we can start using SHA-256 certs [18:20:00 CET] <Timothy_Gu> nevcairiel: sure [18:21:17 CET] <nevcairiel> or you know, just replace fate already [18:21:28 CET] <nevcairiel> i've been using it exclusively lately, anything wrong with it? :) [18:21:41 CET] <Daemon404> i keep forgetting it exists [18:22:02 CET] <nevcairiel> the main reason i use it is the version branch separation, release branches clutter the view on the main one so much [18:22:11 CET] <jamrial> fatebeta is nice but it would be nicer if it also had the same top bar as the original fate [18:22:32 CET] <jamrial> it makes spotting obvious failures easier [18:22:34 CET] <Timothy_Gu> jamrial: i really want to migrate to a proper DB which makes querying a lot easier [18:22:42 CET] <Timothy_Gu> and color bars etc. [18:23:00 CET] <Timothy_Gu> but we have 654408 entries in the entire file-based "DB" so it's gonna take some time [18:23:37 CET] <Daemon404> my main issue with both fate pages is still the dang sidebar [18:23:44 CET] <Daemon404> it just wastes so much space and makes it hardet to read [18:24:09 CET] <Daemon404> also it feels liek 1996 [18:24:10 CET] <Daemon404> with frames [18:24:13 CET] <Daemon404> /minirant [18:24:14 CET] <nevcairiel> you need a bigger screen [18:24:14 CET] <jamrial> on a smartphone, maybe. on any decent display it's not an issue [18:24:33 CET] <Daemon404> nevcairiel, im on a nearly-4k screen [18:24:48 CET] <nevcairiel> then you need a lower scale =p [18:24:57 CET] <nevcairiel> its such a small part of the entire screen [18:25:20 CET] <Daemon404> i dont mean physically hard to read [18:25:25 CET] <Daemon404> i mean it looks awful and cluttered [18:26:03 CET] <Daemon404> and [18:26:05 CET] <Daemon404> http://fatebeta.ffmpeg.org/v2.2 [18:26:11 CET] <Daemon404> clicking branches -> side bar is *gone* [18:26:16 CET] <Daemon404> and its a big blank space [18:26:25 CET] <Daemon404> it just looks bad. [18:26:31 CET] <nevcairiel> its just gone in general now [18:26:37 CET] <nevcairiel> i bet Timothy_Gu removed it :p [18:26:44 CET] <Daemon404> lol [18:27:50 CET] <Timothy_Gu> nevcairiel: ya working on it [18:27:50 CET] <atomnuker> but the whole page is off-center right now [18:27:57 CET] <Timothy_Gu> broke something instead [18:28:06 CET] <nevcairiel> the page hasnt moved, it just blanked out the side bar [18:30:04 CET] <Timothy_Gu> nevcairiel, Daemon404: better now? [18:30:21 CET] <Daemon404> i like it better, of course ;p [18:30:24 CET] <Daemon404> given my minirant above [18:32:39 CET] <nevcairiel> i dont mind either way [18:44:37 CET] <atomnuker> jamrial: what did the bitexact flag do? [18:47:27 CET] <atomnuker> oh yeah, I forgot, it excluded from printing lavc's version to the bitstream [18:54:19 CET] <cone-481> ffmpeg 03James Almer 07master:4c573f8ce961: fate: fix fate-aac-pns-encode failures on non-sse x86_32 targets [19:13:49 CET] <Timothy_Gu> jamrial: colorful bar added [19:13:55 CET] <Timothy_Gu> "top bar" [19:19:07 CET] <llogan> another Thursday, another hangover. drinking is bad, kids. [19:19:23 CET] <llogan> i should stop going to pub trivia [19:31:18 CET] <BBB> so& stop going? :D [19:33:39 CET] <atomnuker> humans have cosumed alcohol for over 4700 years [19:34:02 CET] <atomnuker> can you abandon an old friend? [19:34:53 CET] Action: atomnuker says after never having been pissed enough to blackout [19:53:57 CET] <J_Darnley> Useless ISP! [20:07:12 CET] <jamrial> Timothy_Gu: nice, thank you [20:28:25 CET] <jamrial> nevcairiel: can you check/review "avcodec/dcadsp: replace intptr_t with ptrdiff_t"? [20:39:15 CET] <nevcairiel> jamrial: i'll look at it later [20:39:28 CET] <jamrial> ok, thanks [20:39:55 CET] <nevcairiel> although intptr_t is likely always the wrong type when used as a function argument =p [21:28:01 CET] <Daemon404> ;/g 54 [21:44:41 CET] <wm4> was there a decision yet whether we want to be compatible to Libav ABI [21:44:53 CET] <nevcairiel> we dropped ABI a long time ago [21:45:48 CET] <wm4> there's still some AV_HAVE_INCOMPATIBLE_LIBAV_ABI [21:45:59 CET] <wm4> and useless accessors all over the place [21:46:59 CET] <nevcairiel> feel free to send patches to remove the incompatible abi things, but the accessors are API and here to stay for a while =p [21:47:06 CET] <wm4> in this case I want to access qp_table_buf, but YOU CAN'T [21:47:22 CET] <nevcairiel> you are not meant to [21:47:23 CET] <wm4> it says "Not to be accessed directly from outside libavutil", but you can't access the bufferref at all [21:47:51 CET] <nevcairiel> its deprecated anyway [21:48:01 CET] <nevcairiel> use the sidedata [21:48:46 CET] <wm4> hm you're right it's inside of deprecation guards [21:49:27 CET] <wm4> can't find the not-deprecated version though [21:50:49 CET] <wm4> and the code setting the qp table in mpegvideo is not unside of deprecation guards [21:50:50 CET] <wm4> such quality [21:51:05 CET] <ubitux> av_frame_get_qp_table() [21:51:16 CET] <wm4> ubitux: it's not refcounted [21:51:17 CET] <ubitux> but that qp code is kinda ugly [21:51:22 CET] <ubitux> yeah [21:51:32 CET] <wm4> ok this is a good reason to tell the user that it's not possible to implement [21:51:44 CET] <nevcairiel> why do you need some kind of metadata table to be refcounted [21:52:04 CET] <ubitux> could be a side data, though relatively huge [21:52:17 CET] <wm4> nevcairiel: because it'll cost always [21:54:59 CET] <nevcairiel> anyway the plan is of course to move all this rather specific stuff out of generic structs, not sure someone actually finished writing the replacement for qp, but its not quite gone yet either [22:37:17 CET] <llogan> they're still bickering in -user. maybe i'll put an end to it because i'm tired of it [22:44:38 CET] <nevcairiel> what are they on about today [22:45:43 CET] <BtbN> Someone has decided that top posting is way better. [22:46:25 CET] <nevcairiel> so, a pointless thing even [22:51:25 CET] <llogan> i put in a regex to hopefully dump it to my mod queue [23:16:45 CET] <Daemon404> g 42 [23:27:27 CET] <gnafu> Daemon404: You're not having the best day with that, it seems. [23:33:11 CET] <Daemon404> indeed. [00:00:00 CET] --- Fri Feb 5 2016

1 0

ffmpeg.log.20160204
by burek 05 Feb '16

05 Feb '16

[05:01:46 CET] <explodes> What are the negative consequences of seeking with AVSEEK_FLAG_ANY? (seeks to non-keyframes) Can video or audio become scrambled? [05:04:40 CET] <explodes> My experience so far is yes, you can get scrambled frames. [05:06:15 CET] <explodes> I guess a keyframe is a frame where audio and video are fully rendered? [05:06:22 CET] <explodes> Whereas a non-keyframe is more of a delta [05:06:34 CET] <explodes> [[ obviously I don't know too much :) ]] [07:48:28 CET] <squ> where are vp9 presets [10:38:30 CET] <atomnuker> 2 [10:38:47 CET] <spaam_> 3 [10:40:26 CET] <waressearcher2> vier [15:33:42 CET] <d-fens_> hi, what would be the best filter to create a "rumble/shake/quake" effect in ffmpeg? can i somehow use a fake video stabilisation input and invert the stabilizer this way? [15:33:55 CET] <waressearcher2> d-fens_: hallo und herzlich willkommen [15:34:36 CET] <d-fens_> or semi randomly move position, scale and rotation? [16:00:54 CET] <J_Darnley> Randomly move scale and/or crop is probably how I would do it. [16:01:07 CET] <J_Darnley> (and that is exactly how I did do it in Avisynth) [16:01:56 CET] <J_Darnley> d-fens_ ^ [16:02:27 CET] <d-fens_> but what filter does allow moving the image ? [16:02:36 CET] <d-fens_> i just found crop and so on [16:03:27 CET] <J_Darnley> Yeah, crop some off some random amount then scale back to the size you want. [16:04:16 CET] <d-fens_> like https://youtu.be/A74a_yZU9sU?t=2s [16:05:08 CET] <J_Darnley> I'm not watching a video but I think I know what you mean. [16:05:19 CET] <J_Darnley> Ad you do that by cropping. [16:07:50 CET] <d-fens_> but then the image gets a little bigger/smaller? [16:08:14 CET] <d-fens_> it be more like camera shake [16:08:20 CET] <J_Darnley> Is ffmpeg supposed to create content to the left and right out of thin air? [16:10:02 CET] <d-fens_> like the video stabilizer expand the image part nearby [16:11:12 CET] <d-fens_> so cropping is the only way to move the image (apart from using the overlayfilter) [17:07:49 CET] <Ccdc_DuckZ> hi, I'm configuring ffmpeg with these switches: --disable-gpl --disable-nonfree --disable-version3 --disable-all --disable-everything --disable-static --enable-shared --disable-small --enable-runtime-cpudetect --disable-gray --enable-avcodec --enable-pthreads --enable-avformat --enable-muxer=gif --enable-encoder=gif --enable-filter=color --prefix=$HOME/apps/ffmpeg [17:08:59 CET] <Ccdc_DuckZ> but like this only libavutil is being built - I only need to create an animated gif from my code, can you help me figuring out the correct command line please? [17:10:51 CET] <c_14> --enable-avformat --enable-avcodec [17:11:02 CET] <c_14> Those should get enabled automatically though [17:11:07 CET] <c_14> afaik [17:12:05 CET] <Ccdc_DuckZ> they are in my command already [17:15:00 CET] <c_14> derp, can't read apparently [17:16:26 CET] <furq> Ccdc_DuckZ: do you have some reason to not just use giflib [17:17:53 CET] <Ccdc_DuckZ> furq: that would be my second choice if I fail with ffmpeg, but I thought it might come in handy if in the future we decide to add exporting to mpg or something [17:19:03 CET] <c_14> Ccdc_DuckZ: it builds them here [17:19:06 CET] <c_14> With your exact commandline [17:19:58 CET] <Ccdc_DuckZ> c_14: you just did make && make install? [17:20:05 CET] <c_14> yep [17:20:37 CET] <c_14> https://pb.c-14.de/t/kng.shfnwF [17:20:46 CET] <Ccdc_DuckZ> hmm I just retried and noticed this from make install: "make: *** No rule to make target `libavutil/libavutil.pc', needed by `install-libavutil-pkgconfig'. Stop." [17:21:08 CET] <c_14> make distclean and try again [17:21:51 CET] <Ccdc_DuckZ> does it make any difference if I'm building out of source? [17:22:22 CET] <c_14> You mean an out-of-tree build? [17:22:29 CET] <Ccdc_DuckZ> yes [17:23:03 CET] <c_14> They should be identical to in-tree builds, but there've been some problems with it in the past. If you can try an in-tree build. [17:29:49 CET] <Ccdc_DuckZ> nope :/ http://pastebin.com/0zrw8brz [17:30:01 CET] <Ccdc_DuckZ> I tried twice as you can see [17:30:42 CET] <cortexman> any tips for targetting the maximum file size youtube supports? which is 128GB [17:33:33 CET] <c_14> Set the bitrate to 128GB/length [17:33:52 CET] <c_14> Ccdc_DuckZ: if you make distclean you have to run configure again [17:34:46 CET] <Ccdc_DuckZ> c_14: yes I did, although I had already tried with rm -rf before asking here [17:35:06 CET] <Ccdc_DuckZ> I'm re-downloading the source, maybe something's wrong with it [17:35:13 CET] <Ccdc_DuckZ> is release-2.8 ok? [17:35:32 CET] <c_14> Should be fine [17:37:24 CET] <cortexman> c_14 i am converting a whack of images (~500k) into a video [17:37:55 CET] <cortexman> i essentially want the framerate to be as fast as possible and plan to rely on youtube functionality to slow it down during playback if needed [17:38:26 CET] <cortexman> c_14 are you suggesting i can force ffmpeg to use a particular bitrate [17:38:32 CET] <c_14> yes [17:39:09 CET] <cortexman> ffmpeg will compress each image so as to try to fit overall? [17:39:15 CET] <cortexman> without skipping frames.. [17:39:16 CET] <Ccdc_DuckZ> still nothing... maybe I should try to fix this? "make: *** No rule to make target `libavutil/libavutil.pc', needed by `install-libavutil-pkgconfig'. Stop." [17:40:03 CET] <furq> cortexman: i don't think youtube will slow it down to make it hit 60fps, it'll just drop frames [17:40:10 CET] <furq> unless there's some fancy new feature i'm not aware of [17:41:11 CET] <cortexman> i was just talking about the .25x feature [17:41:16 CET] <cortexman> but you're right, i shouldn't do faster than 60fps [17:41:23 CET] <furq> yeah that'll just run at 15fps [17:42:34 CET] <furq> you shouldn't hit the duration limit with 500k frames at 60fps anyway [17:43:11 CET] <Ccdc_DuckZ> uhm known problem? https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2013-November/150941.html [17:44:53 CET] <furq> cortexman: if you target 128GB then the bitrate will be about 122mbps, which seems a touch excessive [17:44:55 CET] <J_Darnley> cortexman: What the heck are you doing? You should be encoding the video as you want the end users to see it. [17:45:12 CET] <cortexman> i am, but they may want to slow it down to see each frame for longer [17:45:12 CET] <furq> yeah what he said [17:45:50 CET] <furq> just encode it as you would any other video [17:45:54 CET] <J_Darnley> That sounds like it is the responsibility of the player. [17:46:05 CET] <furq> there's nothing you can do to help people view frames for longer short of dropping the framerate or duplicating frames [17:46:09 CET] <cortexman> it looks cool at different speeds [17:46:27 CET] <cortexman> i thought the youtube .25x feature would show frames for longer.... [17:46:42 CET] <furq> well yeah but it'll do the same thing regardless of how you encode the video [17:46:53 CET] <J_Darnley> It sounds like it should but that also sounds like a feature of the *player*. [17:48:41 CET] <cortexman> i also want to hit the maximum size youtube supports [17:48:46 CET] <furq> why [17:48:58 CET] <furq> youtube is going to reencode it to 5mbit at most [17:49:01 CET] <cortexman> so it looks good on ginormous monitors [17:49:10 CET] <cortexman> oh? [17:49:23 CET] <cortexman> that's a good constraint to know. is there documentation of that that you know of? [17:49:34 CET] <furq> no but you can see for yourself with youtube-dl [17:49:48 CET] <cortexman> i see [17:49:52 CET] <furq> idk if they target particular bitrates but 1080p videos are usually about 3.5mbps [17:50:00 CET] <Ccdc_DuckZ> cortexman: shouldn't you be uploading to some fileserver, or maybe vimeo, if you're so concerned about quality? [17:50:10 CET] <Ccdc_DuckZ> youtube is alwayg going to recompress [17:50:16 CET] <furq> there's no way they'll stream 120mbps video [17:50:25 CET] <furq> and nor should anyone ever do that [17:51:31 CET] <bencoh> who knows, in a few years ... [17:51:42 CET] <bencoh> (640k should be more than enough ;) [17:51:49 CET] <furq> most of the world will still have <100mbit in a few years [17:52:18 CET] <furq> only one major isp in britain offers >100mbit down [17:52:35 CET] <bencoh> oh btw, 1080p(a)3.5mbps is mostly crap (but quite common, agreed) [17:52:42 CET] <Ccdc_DuckZ> cortexman: this is your friend: http://superuser.com/questions/652935/which-codec-to-avoid-recompression-in… [17:52:44 CET] <furq> it sure is [17:52:58 CET] <furq> youtube's hd stuff is generally pretty bad [17:53:06 CET] <bencoh> bad is an understatement :) [17:53:20 CET] <furq> maybe the vp9 stuff is better, it always picks h264 here for some reason [17:53:37 CET] <furq> at least the audio quality is acceptable these days [17:54:04 CET] <drv> the h.264 that youtube provides seems to be intentionally lower quality, the vp9 is pretty good [17:56:09 CET] <furq> cortexman: http://sprunge.us/bfIT [17:56:23 CET] <furq> that's a tv broadcast of a motor race [17:56:34 CET] <furq> less than 3.5mbit for 1080p60 [17:57:07 CET] <furq> oh nvm that's 720p [17:57:20 CET] <furq> i'm sure i already downloaded this video in 1080p. where's that format gone [17:58:29 CET] <cortexman> i am also reading this page https://trac.ffmpeg.org/wiki/Encode/YouTube [17:59:17 CET] <furq> "the best practice is to provide the highest quality video that is practical for you to upload." [17:59:23 CET] <furq> you can stop reading after that [17:59:41 CET] <cortexman> basically [17:59:50 CET] <Ccdc_DuckZ> c_14: btw adding --enable-avutil fixed my problem, I guess the script is not picking up dependencies by itself and it won't warn you either [17:59:56 CET] <furq> but since it's going to be reencoded, there's not much point going nuts and uploading a 128GB file [18:00:00 CET] <Ccdc_DuckZ> I just guessed the right one [18:00:05 CET] <furq> unless you have 1G fibre and don't care [18:00:35 CET] <cortexman> i am working with this so far ffmpeg -framerate 60 -pattern_type glob -i '*.jpg' -c:v libx264 -b:v 5m -preset slow -tune stillimage -movflags +faststart out.mp4 [18:00:43 CET] <furq> don't use -b:v [18:00:48 CET] <furq> use -crf [18:01:03 CET] <cortexman> the -b:v option seems to allow me to estimate the file size [18:01:06 CET] <furq> also you don't need to use -movflags +faststart [18:01:16 CET] <furq> yeah it does, but do you need to? [18:01:28 CET] <furq> you're not going to get anywhere near 128GB [18:01:29 CET] <cortexman> there are ~500k images at 60 fps, with a bitrate of 5mbps [18:01:38 CET] <cortexman> yeah.. easily. [18:01:41 CET] <J_Darnley> I hope they are tiny images [18:01:50 CET] <cortexman> they are big, like 2k x 3k [18:01:56 CET] <J_Darnley> Because I wouldn't want to se HD at 5M ABR [18:02:05 CET] <furq> -crf 18 is not going to spit out 120mbps video [18:02:07 CET] <furq> not even for 4k [18:02:21 CET] <J_Darnley> furq: that sounds like a challenge! [18:02:38 CET] <furq> shrug [18:02:44 CET] <furq> maybe every single frame of this video is completely different [18:02:48 CET] <furq> in which case maybe it'll get close [18:02:58 CET] <furq> it'll also look like absolute shit at 5mbps [18:03:31 CET] <cortexman> i am getting 30mbps with crf 18 [18:03:44 CET] <furq> also if 2k*3k means 3000px vertical resolution then you might as well scale it now [18:04:08 CET] <cortexman> yeah i had it at .5x earlier [18:04:16 CET] <furq> i doubt youtube will display it with more than 2160px vertical [18:05:49 CET] <cortexman> k this is getting me about 7mbps ffmpeg -framerate 60 -pattern_type glob -i '*.jpg' -vf scale=iw*.5:ih*.5 -c:v libx264 -crf 18 -preset slow -tune stillimage -movflags +faststart out.mp4 [18:06:04 CET] <cortexman> unfortunately i can't predict duration or filesize... [18:06:08 CET] <furq> cortexman: -vf scale=-1:2160 [18:06:14 CET] <furq> if you want 4k on youtube [18:06:39 CET] <furq> also how can you not predict duration [18:07:29 CET] <furq> 500000 images / 60 fps / 60 seconds = 138 minutes [18:07:45 CET] <cortexman> oh, the output is just how fast ffmpeg is encoding it. that was confusing me [18:08:04 CET] Action: Ccdc_DuckZ still doesn't understand why youtube, since it will resize and recompress for sure [18:08:14 CET] <cortexman> right.. vimeo seems good [18:08:16 CET] <cortexman> or aws. [18:08:22 CET] <furq> it won't resize if you're at the right size already [18:08:37 CET] <furq> s/size/vertical resolution/ [18:09:17 CET] <furq> or rather there will be one format available which isn't resized [18:09:17 CET] <Ccdc_DuckZ> you could upload your stuff as 16k x 9k uncompressed .bmp (if youtube supported that) and you'd still end up with the same video [18:09:32 CET] <cortexman> vimeo only supports up to 25gb [18:09:39 CET] <furq> 25GB should be fine [18:09:50 CET] <Ccdc_DuckZ> furq: yes, I meant if you're out of the allowed limits [18:11:10 CET] <furq> cortexman: 25GB would be 24mbps [18:12:58 CET] <cortexman> at 30fps i'm getting ~50mbps [18:15:17 CET] <cortexman> at 60fps i'm getting ~70mbps [18:17:38 CET] <cortexman> frame= 707 fps=4.8 q=26.0 size= 100633kB time=00:00:10.65 bitrate=77407.1kbits/s [18:17:49 CET] <kepstin> cortexman: why are you using -tune stillimage? that's designed for use if you're encoding a single standalone frame (i.e. a "still image") rather than a video. [18:17:59 CET] <cortexman> oh yeah, i forgot to look deeper into that [18:18:07 CET] <cortexman> they are still frames [18:18:23 CET] <cortexman> and somewhat discontinguous, although manually aligned. [18:18:30 CET] <kepstin> right, are you encoding 700 separate individual videos with only a single frame? [18:18:46 CET] <cortexman> no hah. [18:18:49 CET] <kepstin> if so you want, stillimage, if not, something else might be more appropriate :) [18:18:58 CET] <kepstin> or it might be ok, it's unclear [18:21:09 CET] <kepstin> I suppose if your video is actually a slideshow (i.e. the same frame is shown for a while before switching), it might be ok, but if there's motion between frames it might reduce quality. [18:22:19 CET] <Ccdc_DuckZ> shouldn't I have this function somewhere? http://ffmpeg.org/doxygen/0.6/avcodec_8h.html#ee15a4e6f199e1ac855e07f72ff15… [18:22:52 CET] <Ccdc_DuckZ> I grepped in my prefix path, there is a 3 variant but not exactly that one [18:23:19 CET] <cortexman> -preset ultrafast seems to be working well [18:23:19 CET] <furq> are youusing ffmpeg 0.6 [18:23:41 CET] <furq> cortexman: don't use ultrafast if you're trying to save bitrate [18:23:48 CET] <furq> or ever, really [18:23:53 CET] <Ccdc_DuckZ> furq: I got it from here https://codeload.github.com/FFmpeg/FFmpeg/zip/release/2.8 [18:24:01 CET] <furq> Ccdc_DuckZ: those are the docs for 0.6 [18:24:17 CET] Action: Ccdc_DuckZ facepalms [18:24:43 CET] <Ccdc_DuckZ> furq: thanks for pointing that out [18:25:30 CET] <Ccdc_DuckZ> I guess I'll go on tomorrow then... do you know of any example I could look at to encode as animated gif? [18:26:32 CET] <cousin_luigi> bbl [18:27:16 CET] <Ccdc_DuckZ> I guess I'll ask again tomorrow... bye! [18:43:32 CET] <crot> Hello all, does anyone have any knowledge of GVSP (Gige Vision Streaming Protocol)? [19:43:51 CET] <cortexman> can i pass a list of file names in to ffmpeg in the order i want them read or do i need to rename them [19:47:04 CET] <kuroro> is it accurate to say that when encoding multiple videos, the number of parallel ffmpeg processes shouldnt be greater than number of cores available on CPU, otherwise, there wont be any benefits in throughput [19:48:20 CET] <dv_> difficult to say [19:48:39 CET] <dv_> if I/O has a significant impact in a few jobs then more threads could help [19:49:00 CET] <llogan> cortexman: can you explain in more detail? [19:50:17 CET] <cortexman> i went ahead and put indices into the images [19:54:12 CET] <llogan> i had a feeling you were referring to images, but was not sure [19:55:22 CET] <cortexman> i am. i renamed them like this: 0_55d7a708ffaf5abf26397e88.jpg to 456743_55c6517008298d8be221a647.jpg [19:55:33 CET] <cortexman> not sure what kind of pattern to use to capture that range in order [19:55:54 CET] <rektimus> lol i saw jpg and tried to click it [19:55:59 CET] <kuroro> dv_: i see [19:56:27 CET] <cortexman> this kind of pattern doesn't seem to work: img%03d.png [19:57:55 CET] <llogan> you could try the glob pattern [19:58:00 CET] <cortexman> i need them in order [19:58:08 CET] <cortexman> https://en.wikibooks.org/wiki/FFMPEG_An_Intermediate_Guide/image_sequence#F… [19:58:14 CET] <cortexman> can i use %d-image.png ? [19:58:29 CET] <cortexman> i can't tell whether 'image' refers to something actually in the filename, or something arbitrary like my hashes [20:00:07 CET] <cortexman> what i need is '%d_*.jpg' [20:00:08 CET] <kuroro> dv_: actually, i just noticed in that ffmpeg automatically uses multicores when encoding (it jumps to about 270% CPU in top). [20:00:11 CET] <rektimus> all ffmpeg guides are intermediate [20:00:17 CET] <rektimus> no one will ever understand its power [20:02:31 CET] <llogan> glob pattern probably won't do what you expect because your number sequence is not zero padded. [20:02:51 CET] <cortexman> %d does not require padding [20:02:58 CET] <cortexman> the problem is the unique hash for every image in its filename [20:03:11 CET] <cortexman> ffmpeg seems to expect retarded filenames like image_0.jpg only [20:03:22 CET] <llogan> i'm not referring to sequence pattern type [20:03:35 CET] <cortexman> yeah globbing won't work [20:03:42 CET] <cortexman> os won't return the files in the right order [20:04:08 CET] <llogan> then add zero padding to the number sequence in the file name then you can probably use glob [20:04:29 CET] <cortexman> i'm thinking of using symlinks [20:12:36 CET] <kbarry> I would like to take 2 separate audio streams, combine them into a single output, with input0 in the left ear, and input1 in the right ear [20:12:47 CET] <kbarry> (if I cna get that working, i really hope to have more than 2) [20:13:53 CET] <furq> kbarry: https://ffmpeg.org/ffmpeg-filters.html#amix [20:14:34 CET] <furq> er [20:14:41 CET] <furq> https://ffmpeg.org/ffmpeg-filters.html#amerge-1 [20:14:51 CET] <furq> i was only one away [20:16:40 CET] <furq> https://trac.ffmpeg.org/wiki/AudioChannelManipulation#a2monostereo [20:18:23 CET] <kbarry> furq: I found that last page, [20:18:30 CET] <kbarry> And I tried this syntax: ffmpeg -i input1.wav -i input2.wav -filter_complex "[0:a][1:a]amerge=inputs=2,pan=stereo|c0<c0+c1|c1<c2+c3[aout]" -map "[aout]" output.mp3 [20:18:49 CET] <kbarry> My inputs are stereo hls streams [20:19:05 CET] <kbarry> (getting a pastebin) [20:27:09 CET] <fikse> i have a recording of an app on my phone. i removed the audio, and now the file size is 4.1M. the total length of the recording is 15 seconds [20:27:34 CET] <fikse> is there a way to reduce the file size dramatically without reducing the quality even further? [20:36:04 CET] <kbarry> furq: mind taking a look http://pastebin.com/YYLHF2UG [20:36:19 CET] <kbarry> I tried expanding from 2 to 4, but I don't have a firm grasp on the syntax yet. [20:36:53 CET] <kbarry> I'm trying to put input0 to BL, input1 to FL, input2 to FR, and input3 to BR. [20:37:25 CET] <llogan> you have amerge=inputs=4, but only gave it two inputs [20:38:20 CET] <kbarry> i see 4 inputs [20:38:33 CET] <kbarry> tiger, horse, christopherrobin, and mexico [20:38:55 CET] <llogan> so do i. but you only provided two inputs to amerge [20:39:51 CET] <kbarry> lemme try that again [20:41:35 CET] <kbarry> OK, i think I have it going, [20:42:02 CET] <kbarry> In my syntax currently, I have -filter_complex "[0:a][1:a][2:a][3:a]amerge=inputs=4,pan=4c|c0<c0+c1|c1<c2+c3|c2<c4+c5|c3<c6+c7[aout]" [20:42:28 CET] <kbarry> Is it possible for me to deplace the cn< with specific chanel layouts [20:42:30 CET] <kbarry> ie, FL [20:42:31 CET] <kbarry> FR [20:42:33 CET] <kbarry> BL [20:42:44 CET] <llogan> "[0:a][1:a][2:a][3:a]amerge=inputs=4,pan=quad|FL<c0+c1|FR<c2+c3|BL<c4+c5|BR<c6+c7" [20:42:59 CET] <llogan> also see "ffmpeg -layouts" which can help with this stuff [20:49:59 CET] <kbarry> llogan, I just understood why you used quad [20:50:14 CET] <kbarry> can i just state how many i want to use, then use whichever I want? [20:57:27 CET] <llogan> kbarry: probably [20:58:15 CET] <llogan> i've encountered a limit to the number of channels in some filter(s) but i can't remember which [21:03:11 CET] <derekprestegard> question - when processing a jpeg image sequence is it safe to assume that its full range bt709? [21:20:14 CET] <kepstin> derekprestegard: yeah, I think so. jpeg images are normally based on sRGB, which uses bt709 primaries, and use PC (full range) [21:21:25 CET] <kepstin> hmm. gamma might be wrong tho [21:22:06 CET] <kepstin> bt709 is gamma 2.4, but sRGB is (close to) 2.2ish [21:28:19 CET] <derekprestegard> kepstin: is there a way to account for that when converting to yuv420p in ffmpeg? [21:32:12 CET] <kepstin> not sure. Are you having any specific issues with the automatic conversions that ffmpeg is doing? [22:04:43 CET] <cortexman> how do i suppress "deprecated pixel format used, make sure you did set range correctly" errors? [22:05:01 CET] <cortexman> also interested in suppressing "Input stream #0:0 frame changed from size:* fmt:* to size* fmt:* [22:05:12 CET] <cortexman> i managed to suppress all errors, but it comes at the expense of not getting any status updates [22:16:01 CET] <kepstin> cortexman: the deprecated pixel format warning is either due to a code issue inside ffmpeg or the app using it (or maybe a command-line parameter), so it should probably be fixed - but in the mean time doesn't hurt anything. [22:16:19 CET] <cortexman> it makes it hard to see the actual status updates [22:16:52 CET] <kepstin> it should only be printed once unless you're doing something really strange... [22:24:47 CET] <cortexman> i am converting many images to a video [00:00:00 CET] --- Fri Feb 5 2016

1 0