Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

June 2017

1 participants
60 discussions

ffmpeg-devel.log.20170624
by burek 25 Jun '17

25 Jun '17

[00:01:40 CEST] <durandal_1707> the overlay filter needs some love: >8 bit support and asm [00:04:51 CEST] <atomnuker> durandal_1707: funman had some interest in this as well, I think [00:05:00 CEST] <atomnuker> I can't remember if he wrote something optimized [00:10:55 CEST] <durandal_1707> atomnuker: wasnt it kierank ? [00:11:30 CEST] <atomnuker> well, yeah, but it was funman who had to write something [00:11:58 CEST] <durandal_1707> according to google he already did [00:16:08 CEST] <jamrial> durandal_1707: did you check the two tests failures i mentioned above? [00:16:14 CEST] <BBB> atomnuker: derf can be & confusing [00:16:31 CEST] <jamrial> fate.ffmpeg.org is slowly turning very yellow [00:16:48 CEST] <atomnuker> BBB: there's still peloverde [00:17:16 CEST] <atomnuker> (if no one is available I'll do both) [00:17:22 CEST] <durandal_1707> jamrial: just update checksums [00:17:26 CEST] <BBB> atomnuker: k [00:17:40 CEST] <BBB> why is fate so yellow [00:17:47 CEST] <Compn> durandal_1707 : complex and daunting yes, but you can educate and maybe even trick some people into RE'ing things :) [00:17:49 CEST] <jamrial> durandal_1707: but why did they change at all? the commit you reverted didn't affect them [00:18:04 CEST] <jamrial> why does reverting it affect these tests? [00:18:15 CEST] <jamrial> i don't think updating the checksum without knowing what changed is a good idea [00:19:05 CEST] <jamrial> BBB: a recent commit broke two tests [00:19:32 CEST] <durandal_1707> jamrial: the lavfi core is in weird state after removal of recursive code [00:20:43 CEST] <durandal_1707> Compn: i will just wait for software source code leaks instead [00:25:16 CEST] <durandal_1707> jamrial: and i failed to contact nicolas [00:45:52 CEST] <atomnuker> ubitux: are you going to push your asm patches soon? [00:54:48 CEST] <cone-545> ffmpeg 03Rostislav Pehlivanov 07master:e1120b1c5446: mdct15: add assembly optimizations for the 15-point FFT [00:56:19 CEST] <iive> \o/ [01:04:38 CEST] <jamrial> durandal_1707: if you think it's ok then please update the checksums [01:06:44 CEST] <durandal_1707> jamrial: the change is that older ones would get progressive flag set and new one doesnt [01:08:22 CEST] <jamrial> alright [01:11:50 CEST] <atomnuker> that haddps isn't getting hot at all and I have no explanation for this [01:12:58 CEST] <iive> modern cpu are out-of-order [01:13:08 CEST] <atomnuker> yep, that's what I thought, got lucky [01:13:25 CEST] <iive> if it is hot, it probably is waiting for something above it. [01:32:19 CEST] <iive> atomnuker: you are on skylake, right? addps has latency=4 invthru=1/2 ; haddps has latency=6 invthru=2 [01:33:30 CEST] <atomnuker> yep [01:34:01 CEST] <Gramner> all the hadd instructions are essentially 2 shuffle µops and one ALU µop on intel cpus [01:36:15 CEST] <iive> Gramner: then why on my cpu doing the shifts and adds manually is faster?! [01:36:24 CEST] <iive> why intel, why..... [01:38:37 CEST] <Gramner> it's literally the same speed as doing two shuffles and one add. if you use shifts instead of shuffles that will use p01 instead of p5 which may be faster or slower depending on the port utilization [01:39:30 CEST] <iive> shuffles... sorry. [01:41:02 CEST] <Gramner> and they could've made those instructions fast if they wanted to. they just didn't want to spend transistors on it [01:41:46 CEST] <Gramner> kind of a catch 22. people avoided using them because they were slow. and no point in making them fast because nobody used them [01:41:50 CEST] <Gramner> I guess? [01:42:14 CEST] <Gramner> and with EVEX they are gone completely so that's your long-term solution [01:43:27 CEST] <iive> catch-22 exactly [02:05:07 CEST] <iive> Gramner: oh, i see. I've been using hadd for horizontal sum, aka sum all elements. So I used 2 hadds this makes 4 shuffles and 2 sums in micro op. [02:05:44 CEST] <Gramner> yes, that's bad. don't do that [02:05:45 CEST] <iive> the sum macro used 2 shuffles and 2 sums, so it is faster. [02:06:08 CEST] <durandal_1707> your own code? [02:06:39 CEST] <iive> yes [02:12:39 CEST] <iive> i wrote my own macro. it differs from x86util by that it leaves the sum already broadcasted in all elements. [02:13:00 CEST] <durandal_1707> for ffmpeg? [02:13:05 CEST] <rcombs> wait, so it's faster to do horizontal add using shuffles and vertical adds than to use the actual horizontal add instructions? [02:13:13 CEST] <iive> yes, patch is on the maillist. [02:13:28 CEST] <iive> rcombs: bingo [02:13:38 CEST] Action: rcombs boggles [02:13:44 CEST] <rcombs> is hadd completely useless then [02:13:49 CEST] <iive> haddps doesn't do a full horizontal add, it does 2 by 2 add [02:14:31 CEST] <rcombs> yeah, and you do 2 to sum the whole register [02:15:02 CEST] <iive> yes [02:16:12 CEST] <Gramner> the hadd instructions horizontally adds two registers, not one [02:16:30 CEST] <Gramner> using them on a single src is kind of useless [02:17:04 CEST] <Gramner> they're basically only worth using if they happen to do exactly what you want [02:19:10 CEST] <iive> yep [02:20:39 CEST] <iive> and I do wonder where intel thought it would be useful... [02:20:56 CEST] <iive> i mean, somebody must have beened that instruction badly... [02:21:21 CEST] <iive> needed... [02:33:10 CEST] <jamrial> iive: there are some places where it's perfect, like aacps's add_squares [02:34:11 CEST] <jamrial> also aacsbr's autocorrelate [02:35:00 CEST] <jamrial> but aside from those, as Gramner said, unless the kind of horizontal add it does is exactly the kind you need, you're bettter not using it [02:35:22 CEST] <jamrial> amd's xop has some good and fast single reg horizontal add. integer only, though [02:39:27 CEST] <iive> so complex number math... [02:39:41 CEST] <iive> that makes more sense. [02:39:47 CEST] <iive> n8 ppl. [03:40:09 CEST] <atomnuker> so if avx doesn't have any integer instructions how come lots of our video codec functions are marked as avx? [03:40:15 CEST] <atomnuker> like the vp9 loopfilter [03:41:48 CEST] <jamrial> atomnuker: what avx doesn't support is integer instructions with ymm regs [03:42:01 CEST] <jamrial> that started with avx2 as i said the other day [03:44:56 CEST] <atomnuker> yes, then what's the point in marking those functions as avx if they don't use ymm regs and they don't use floats at all? [03:45:49 CEST] <jamrial> non destructive, three operand version of xmm instructions [03:46:13 CEST] <atomnuker> ah, ok, I knew there had to be a reason [03:46:27 CEST] <jamrial> in some cases, like with the transpose macros, you save a bunch of movas that way [04:39:43 CEST] <cone-014> ffmpeg 03James Almer 07master:a579dbb4f7de: checkasm: add missing checks to float_dsp's butterflies_float test [05:32:37 CEST] <cone-014> ffmpeg 03Reino17 07master:078322f33ced: Add support for LibOpenJPEG v2.2/git [06:18:47 CEST] <jamrial> atomnuker: https://trac.ffmpeg.org/ticket/6484 [06:47:10 CEST] <cone-014> ffmpeg 03James Almer 07master:349446e36f17: x86/mdct15: use three operand form for some instructions [06:54:21 CEST] <cone-014> ffmpeg 03James Almer 07master:e5bce8b4ce7b: fate: update checksums for fate-lavf-ffm and fate-lavf-mxf [07:53:08 CEST] <ubitux> atomnuker: maybe later today i guess [08:35:01 CEST] <ubitux> wtf is wrong with libopenjpeg? [08:35:18 CEST] <ubitux> is our version check going to grow after every minor release? [08:35:41 CEST] <ubitux> how stupid is this [08:37:20 CEST] <ubitux> they do have a pc file, we should use it [08:38:08 CEST] <ubitux> current state is braindead [09:06:23 CEST] <ubitux> michaelni: here is a sample https://0x0.st/Uma.mkv [09:06:35 CEST] <ubitux> wm4: don't you get ton of report for that kind of stuff btw? ^ [09:09:07 CEST] <ubitux> maybe that's just because the 720p stream is broken... [09:12:28 CEST] <ubitux> the 1080p stream seems to be working out [09:18:24 CEST] <wm4> ubitux: about what? [09:18:39 CEST] <ubitux> broken pgs sub [09:18:46 CEST] <durandal_1707> what codecs use new mdct asm? [09:19:04 CEST] <ubitux> wm4: but that might be because the file is broken, since the 1080p looks ok [09:19:08 CEST] <ubitux> still, looks weird [09:19:40 CEST] <ubitux> the 720p is basically broken any time you have multiple subs [09:20:06 CEST] <wm4> ubitux: at which point is the sample broken how? [09:20:22 CEST] <wm4> oh timing? [09:20:37 CEST] <ubitux> it's missing subtitles [09:20:47 CEST] <ubitux> compare with the 2nd stream [09:21:05 CEST] <ubitux> as soon as you have "okonomiyaki" displays, the dialogues don't show up anymore [09:21:39 CEST] <wm4> is it a libavcodec issue? [09:22:35 CEST] <ubitux> no idea, didn't really investigate [09:23:12 CEST] <ubitux> i mean, it happens with ffplay as well, it's not mpv [09:23:26 CEST] <ubitux> (assuming your question was about ffmpeg vs the world, and not lavc vs lavf) [10:20:33 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:565dc0e283a8: avfilter/vf_overlay: add auto format mode [12:23:02 CEST] <michaelni> ubitux, about Uma.mkv, should i upload this to fate ? if so which directory ? or did you mean something else ? [12:23:31 CEST] <ubitux> it's probably a bit large, it could be reduced [12:23:41 CEST] <ubitux> i have no plan wrt that sample [12:24:00 CEST] <ubitux> it's just broken pgs sub i was refering to, and you seemed "interested" :) [13:35:01 CEST] <atomnuker> durandal_1707: aac and opus [13:35:10 CEST] <atomnuker> ubitux: so should I revert? [13:35:49 CEST] <durandal_1707> revert what? [13:36:05 CEST] <atomnuker> if the error happens only with windows and msvc couldn't we tweak the configure flag? [13:36:27 CEST] <atomnuker> durandal_1707: that patch which did strip -wN @ -> strip -x to strip assembly [13:53:48 CEST] <cone-014> ffmpeg 03Ronald S. Bultje 07master:97f7f831691f: vf_spp: only assign function pointers if permutation matches expectations. [13:56:12 CEST] <jkqxz> michaelni: What phrase would you prefer to describe an empty packet? Other documentation doesn't suggest a common answer. [14:12:45 CEST] <michaelni> jkqxz, iam not sure but something thats uambigous about what empty means, like dts/pts being uninitialized vs NOPTS, data being NULL vs not. only size=0 is really clear from "empty" [14:14:13 CEST] <michaelni> empty packet as returned by av_init_packet() with data=NULL for example [14:14:42 CEST] <michaelni> or empty packet, (size=0 other fields dont matter) [14:15:01 CEST] <durandal_1707> i see why undefined shifts are bad but fixing them just to silence error might not be always correct solution [14:16:44 CEST] <michaelni> durandal_1707, yes of course, is there a commit where you know/have a better solution? [14:17:18 CEST] <durandal_1707> michaelni: no, this quite complex issue [14:19:07 CEST] <durandal_1707> can we ditch older prores encoder its in any aspect worse than kostya one [14:25:51 CEST] <atomnuker> put a patch up on the ML and I'll take a look at it [14:26:09 CEST] <atomnuker> dericed had some comments about which encoder he preferred [14:48:44 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:4976a3411f71: avcodec/mpeg4videodec: Fix GMC with videos of dimension 1 [15:02:15 CEST] <ubitux> atomnuker: do you ask me about the strip thing? [15:03:16 CEST] <atomnuker> yep [15:06:33 CEST] <ubitux> atomnuker: why me? i don't remember being involved in it [15:13:04 CEST] <atomnuker> oh, sorry, by "maybe later today i guess" I thought you meant you'd look at the failure since it was right after jamrial posted it (and I didn't notice it was jamrial) [15:13:23 CEST] <atomnuker> nvm then [15:19:17 CEST] <ubitux> 00:45 <@atomnuker> ubitux: are you going to push your asm patches soon? [15:19:21 CEST] <ubitux> i was replying to this ^ [15:21:27 CEST] <atomnuker> yep, I know [15:53:56 CEST] <kierank> BBB: is it finally all done? [15:54:11 CEST] <BBB> kierank: no [15:54:15 CEST] <kierank> :( [15:54:18 CEST] <BBB> kierank: still need a final approval for the idct patches [15:54:36 CEST] <BBB> theres no outstanding issues ATM [15:54:40 CEST] <BBB> but it isnt approved yet either [15:54:44 CEST] <BBB> you know how this works [15:56:16 CEST] <jkqxz> michaelni: How about "The supplied packet is consumed and will be blank (as if just allocated) when this function returns.", then? [16:07:01 CEST] <kierank> BBB: maybe just push it and let michaelni complain later [16:07:49 CEST] <BBB> lets stay nice [16:11:00 CEST] <durandal_1707> paying debts [16:11:32 CEST] <michaelni> jkqxz, sounds good to me, thx [16:12:50 CEST] <michaelni> BBB, which idct patches are left and need a review ? [16:12:59 CEST] <BBB> 9/11, 10/11 and 11/11 [16:13:35 CEST] <BBB> 9/11 is approved by me [16:13:37 CEST] <BBB> so thats fine [16:13:44 CEST] <BBB> [PATCH 10/11] avcodec/x86: add an 8-bit simple IDCT function based on the x86-64 high depth functions [16:13:49 CEST] <BBB> that one is outstanding [16:14:04 CEST] <BBB> and then [PATCH 11/11] avcodec/x86: use new x86-64 functions for -idct simple, which is fairly trivial [16:14:08 CEST] <BBB> 10/11 is the main outstanding one [16:14:24 CEST] <BBB> Im fine with it but you have had concerns in the past so Im waiting for you to sign off also [16:15:00 CEST] <BBB> Ill lgtm 11/11 [16:15:08 CEST] <BBB> so we can focus on 10/11 [16:32:34 CEST] <durandal_1707> atomnuker: where is your noisereduce code? [18:18:30 CEST] <atomnuker> durandal_1707: https://github.com/atomnuker/FFmpeg/tree/noisereduct_filterhttps://github.c… [18:43:55 CEST] <cone-014> ffmpeg 03Mark Thompson 07master:bc4e33ce0f0e: ffmpeg: Flush output BSFs when encode reaches EOF [18:43:56 CEST] <cone-014> ffmpeg 03Mark Thompson 07master:49419925d333: vp9: Add bsf to fix reordering in raw streams [18:43:57 CEST] <cone-014> ffmpeg 03Mark Thompson 07master:bde04604065d: vaapi_encode: Add VP9 support [18:43:58 CEST] <cone-014> ffmpeg 03Mark Thompson 07master:dc81f1a2cef1: doc: Add VAAPI encoders [19:13:13 CEST] <cone-014> ffmpeg 03Marton Balint 07master:c14fa7a330f6: avformat/aviobuf: fix flushing write buffers after seeking backward or forward [19:13:14 CEST] <cone-014> ffmpeg 03Marton Balint 07master:09891c539162: avformat/aviobuf: add support for specifying minimum packet size and marking flush points [19:13:15 CEST] <cone-014> ffmpeg 03Marton Balint 07master:eeeb595c7f1c: avformat: make flush_packets a tri-state and set it to -1 (auto) by default [19:13:16 CEST] <cone-014> ffmpeg 03Marton Balint 07master:db9e87dd8c1c: avformat/file: increase min/max packet size to 256k for written files [19:18:04 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:c90b88090c26: avfilter: do not leak AVFrame on failed buffer allocation [19:18:05 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:f483949188dc: avfilter/af_headphone: do not free frame that's gonna be reused later [19:26:26 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:c1b43e8452e7: avfilter/vf_overlay: remove rgb option [20:03:01 CEST] <BBB> Gramner: I think we should do micro-optimizations on the simd separately [20:03:14 CEST] <BBB> Gramner: its been near-hell to get this patch-set algorithmically ready for inclusion [20:03:24 CEST] <BBB> Gramner: I think j_darnley has already given up [20:07:10 CEST] <Gramner> sure, do as you wish [20:07:17 CEST] <BtbN> why the hell is Ubuntu still on freetype 2.6.3, even on 17.04 [20:07:29 CEST] <JEEB> huh [20:07:38 CEST] <JEEB> when did 2.7 release? and now there's 2.8 [20:07:43 CEST] <BtbN> yep [20:07:47 CEST] <BtbN> that's what I'm thinking [20:07:56 CEST] <BtbN> 2.7 massively improved the rendering quality [20:08:21 CEST] <BtbN> https://packages.ubuntu.com/artful/libfreetype6 17.10, still 2.6.3 [20:08:42 CEST] <durandal_170> have pics? [20:08:49 CEST] <BtbN> kind of [20:09:20 CEST] <BtbN> https://github.com/OGGM/oggm-sample-data/tree/master/baseline_images everything in 2.0.x is rendered with 2.6.3, everything in alt with 2.8.0 [20:09:26 CEST] <BtbN> it's breaking our test suite... [20:11:00 CEST] <BtbN> https://github.com/OGGM/oggm-sample-data/commit/a9888f52fc3396ed7a8effa2f48… gives you compare-tools [20:11:40 CEST] <atomnuker> the debian maintainer for freetype was a hardcore ubuntu spy who held it back [20:11:52 CEST] <atomnuker> though he gave up quite some time ago and now debian has 2.8 [20:12:06 CEST] <BtbN> but why [20:12:15 CEST] <atomnuker> they have their own freetype patches [20:12:26 CEST] <BtbN> I don't want them [20:12:33 CEST] <atomnuker> use debian :) [20:13:47 CEST] <Gramner> debian expermiental has 2.8, stretch and sid has 2.6 [20:14:45 CEST] <BBB> J_Darnley: will you push? kierank << [20:15:03 CEST] <kierank> yes i will let him do the hnour [20:15:16 CEST] <kierank> honour [20:16:00 CEST] <BBB> woohoo [20:16:07 CEST] <BtbN> Can't even properly detect it, as there is no useful version information in that package without -dev: https://packages.ubuntu.com/zesty/amd64/libfreetype6/filelist [21:08:25 CEST] <J_Darnley> BBB: I've just seen the new emails. Thank you. [21:09:25 CEST] <J_Darnley> I haven't quite given up. My frustrations have moved onto network drivers. [21:10:59 CEST] <J_Darnley> I'll test out Gramner's suggestion [21:11:17 CEST] <J_Darnley> then I will rebase and I guess push [21:45:42 CEST] <durandal_170> can wavpack decoding be simdable? i havent found good candidates [21:49:08 CEST] <RiCON> durandal_170: they have bsd-licensed asm in libwavpack at least [21:51:47 CEST] <durandal_170> yea but i dont see how that can be improved much [21:53:06 CEST] <durandal_170> or wavpack does it all work in simd in one go [22:12:04 CEST] <JEEB> hmm, getting this with the latest master and I wonder if it's valid. not like I'm using ADPCM but it seemed awfully specific http://up-cat.net/p/05599869 [22:19:01 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:933aa91e31d5: avcodec/hevcdec: check ff_init_cabac_decoder() for failure [22:19:02 CEST] <cone-014> ffmpeg 03Michael Niedermayer 07master:247606768033: avcodec/hevcdec: Use error path if init_get_bits8() fails [22:19:03 CEST] <cone-014> ffmpeg 03Jun Zhao 07master:2b7d9a1f3fa7: lavc/put_bits: Add put_bits64() to support up to 64 bits. [22:19:04 CEST] <cone-014> ffmpeg 03Jun Zhao 07master:e61abe2d7329: lavc/golobm: Add set_ue_golomb_long to support up to 2^32 -2. [22:19:05 CEST] <cone-014> ffmpeg 03Jun Zhao 07master:32deea87c1d6: lavc/tests/golomb: Add unit test for set_ue_golomb_long. [22:33:09 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:10542491113d: avcodec/adpcm_data: use uint16_t to handle all values [22:52:18 CEST] <cone-014> ffmpeg 03Paul B Mahol 07master:5c1f4330d4c3: avfilter/vf_lut2: add support for gray10 and gray12 pixel formats [23:38:38 CEST] <atomnuker> iive: dude, holy shit this thing is fast [23:38:44 CEST] <atomnuker> avx2 works as well [23:39:21 CEST] <durandal_170> how much fast? [23:40:14 CEST] <atomnuker> 3.52 times on the default 96kbps [23:40:40 CEST] <durandal_170> than pure C ? [23:41:33 CEST] <atomnuker> yep [23:51:55 CEST] <kierank> J_Darnley: can you push? [23:52:58 CEST] <durandal_170> why? what you get? [00:00:00 CEST] --- Sun Jun 25 2017

1 0

ffmpeg.log.20170624
by burek 25 Jun '17

25 Jun '17

[01:34:49 CEST] <h0par> hello [01:36:37 CEST] <durandal_1707> hello [01:38:01 CEST] <h0par> I try to use ffmpeg to stream mjpeg to youtube rtmp [01:38:23 CEST] <h0par> command I try is ffmpeg -f mjpeg -i http://localhost:8081 -f flv rtmp://a.rtmp.youtube.com/live2/KEY [01:39:46 CEST] <h0par> here is output I get https://pastebin.com/UxmZ2Wke [01:40:03 CEST] <h0par> seems like it's ok, but doesn't appear on youtube [01:40:35 CEST] <h0par> haha, my key shows up there [01:41:27 CEST] <durandal_1707> see docs about flv muxer if it have streaming options [01:44:15 CEST] <clearcut> i want to extract part of mkv video, from 10m:00s to 12m:00s - how? [01:45:15 CEST] <durandal_1707> read docs [01:45:18 CEST] <atomnuker> -ss 00:10:00.000 -i <file> -t 00:02:00.000 [01:45:21 CEST] <basisbit> use google [02:07:24 CEST] <clearcut> atomnuker: thanks - it worked, however audio is missing - im doing something wrong [02:08:35 CEST] <durandal_1707> clearcut: pastebin full command output [02:10:07 CEST] <clearcut> durandal_1707: https://pastebin.com/imE4kE8g [02:11:31 CEST] <durandal_1707> try adding -c:a copy [02:14:18 CEST] <clearcut> durandal_1707: thanks ir worked - thank you guys, you are friendly crowd, may all your wished come true :D [02:14:25 CEST] <clearcut> wishes* [03:00:39 CEST] <MachinaeWolf> How would I record audio that is playing on my computer. I have pulse but no ~/.asoundrc [07:49:24 CEST] <jimgray> Hi guys. My ffmpeg is built with libssh support. When `ffplay sftp://bobme/~/test.mp4', it reports [libssh @ 0x7f90100012c0] Authentication failed [07:49:28 CEST] <jimgray> permission denied. [07:49:45 CEST] <jimgray> `bobme' is from ~/.ssh/config host [08:05:38 CEST] <tdr> if auth failed, the rsa/dsa pub key is prob bad [08:06:12 CEST] <jimgray> tdr: But I can `ssh bobme' into remote host [08:07:21 CEST] <tdr> that or the host/path is the wrong syntax [08:08:23 CEST] <Aprel> have you checked the perms on test.mp4 to confirm it's accessible by the client? [08:08:48 CEST] <tdr> that would say permission denied, not an auth error [08:08:58 CEST] <jimgray> Aprel: the perms is 644 [08:09:35 CEST] <Aprel> well he says he gets both an auth failed and perm denied messages [08:10:03 CEST] <obito> hello hay alguien? [08:10:06 CEST] <tdr> the permission denied would come back if auth failed anyway [08:10:13 CEST] <obito> hello hay alguien? [08:10:28 CEST] <jimgray> tdr: I think so. The auth failure cause permission issue. [08:10:46 CEST] <obito> is posible concatenate stream from socket in ffmpeg? [08:11:08 CEST] <tdr> jimgray, check your server ssh log, see why it failed [08:12:01 CEST] <jimgray> yep, let me see [08:12:22 CEST] <obito> @tdr is posible concatenate stream from socket please helpme and thanks [08:15:10 CEST] <tdr> obito, not an expert on this, but if you're outputing to a socket a series of streams and reading input from it, it would make sense you can treat them as one continuous stream sure. [08:15:40 CEST] <jimgray> tdr: I found a line `localhost sshd[3603]: Received disconnect from my-pc-ip: 11: Bye Bye [preauth]' [08:16:21 CEST] <tdr> jimgray, thats the system you're connecting from? [08:16:36 CEST] <jimgray> tdr: this is the log on remote [08:16:56 CEST] <jimgray> `my-pc-ip' is the system I am connecting from [08:17:03 CEST] <tdr> thats what i meant, yeah [08:17:58 CEST] <jimgray> It seems each time I execute ffplay sftp://, it report that line [08:18:57 CEST] <obito> The server what it does is, read several files and send them to ffmpeg the first file is read well but the second pull some errors Non-Monotunus I have researched but I do not find the solution because: C [08:21:20 CEST] <jimgray> tdr: by the way, I can use `sftp bobme:test.mp4' to fectch the file locally. Dunnno why ffplay not. [08:21:29 CEST] <tdr> jimgray, so on your client, ssh bobme works without a password? [08:22:03 CEST] <jimgray> tdr: yes. pretty sure. I use ssh key to login [08:22:21 CEST] <tdr> (checking that its not silently asking you for a password input and not getting one so failing) [08:22:33 CEST] <tdr> yeah if keys work, thats answering [08:23:33 CEST] <tdr> jimgray, does ssh bobme 'cat filename' | ffplay work? ... your ~ may not be expanding or something [08:24:01 CEST] <jimgray> let me test [08:24:27 CEST] <tdr> try full path [08:25:33 CEST] <jimgray> tdr: An input file must be specified. ffplay exit directly [08:26:19 CEST] <tdr> jimgray, ssh bobme 'cat /path/to/file' | ffplay <--- thats what you did? [08:26:48 CEST] <jimgray> tdr: my exact command is `ssh jimgray 'cat ~/joke.mp4' | ffplay` [08:27:17 CEST] <jimgray> ignore jimgray or bobme string diff [08:27:45 CEST] <tdr> it may want - after the ffplay to get stdin [08:28:01 CEST] <tdr> er stdout .. whatever, to make it "catch it" [08:28:48 CEST] <jimgray> tdr: ha, `-' works now [08:29:01 CEST] <tdr> yeah some commands are picky like that [08:29:18 CEST] <tdr> so its not a connection thing, try full path with your sftp thing [08:29:51 CEST] <tdr> i dont know the syntax you should be using, but it has to be off since it plays if we pipe it back over ssh [08:31:03 CEST] <jimgray> ffplay sftp://bobme/~/joke.mp4 failed [08:31:31 CEST] <tdr> stop using the ~, give it a full path [08:31:35 CEST] <tdr> 'to test :) [08:32:17 CEST] <tdr> sftp is usually username@host:/path .. the first / after bobme maybe should be a : [08:34:29 CEST] <jimgray> tdr: all failed. Let me google first [09:16:38 CEST] <thomedy> what i understand about audio codec isn't adding up [09:16:48 CEST] <thomedy> is someone here who can help me make sense of it [09:16:51 CEST] <thomedy> if i have 44100 [09:17:11 CEST] <thebombzen> 44100 is the sample rate, not the audio codec [09:17:13 CEST] <thomedy> samples per second with 16 bits per samples that woudl be s/s * bd [09:17:30 CEST] <thomedy> okay im not sure wht to call it im just trying to find out how many bits per second [09:18:13 CEST] <thomedy> and my ogg isn't lining up with what makes sense to me and also neither is my .raw so tht meanse im wrong because im assuming ffmpeg -i will be accurate making me not so much [09:18:20 CEST] <thomedy> so here is what makes sense.... [09:18:27 CEST] <thomedy> to me at least and im missing somethign i know it [09:18:37 CEST] <thomedy> 44100 cd quality sampels per second at 16 bits per sample [09:18:43 CEST] <thomedy> divide that by the chnanels [09:18:45 CEST] <thomedy> 2 for exmple [09:19:05 CEST] <thomedy> 352800 [09:19:39 CEST] <thomedy> but tht isnt right [09:20:04 CEST] <thomedy> 8484377 is my ls -al on my file.ogg [09:20:08 CEST] <thomedy> gives me file size [09:20:30 CEST] <thebombzen> the bitrate of uncompressed audio is just a bunch of multiplication, as you have figured out [09:20:51 CEST] <thomedy> the file is 4.13 [09:21:19 CEST] <thebombzen> 44100 samples per second * 16 bits per sample * 2 channels (stereo audio) is 1.411 kilobits per second. But that's uncompressed audio [09:21:28 CEST] <thebombzen> ogg audio is comprssed, so the bitrate will bit considerably lower than that [09:21:43 CEST] <thebombzen> (cause that's kind of, like, the whole point of compression) [09:21:47 CEST] <thomedy> wouldnt ffmpeg tell me what i need to complete the equation [09:22:18 CEST] <thomedy> for example when i ffmpeg the .ogg i get 8 bits 44100 and im not seeing channels but [09:23:17 CEST] <thomedy> well then actually i still have a question... i run command line to pcm raw audio... and it gives me 44734464 [09:23:37 CEST] <thomedy> as in im pretty sure that decompresses the content [09:23:43 CEST] <thomedy> im honestly not sure yet [09:28:07 CEST] <thebombzen> back up, do you know what compression is? [09:29:08 CEST] <thomedy> yeah im pretty sure i understand a fair amount about compression i dont know exactly what algorithm ogg vorbis for example uses but i am reading bout it now [09:29:35 CEST] <thomedy> for exmple lossless aaabbcccccccdde 3a2b8c2de [09:29:39 CEST] <thomedy> i get that [09:30:07 CEST] <thomedy> as an example but i guess i was assuming that ffmpeg -i would give me enough info to make my equation post compression [09:30:08 CEST] <thebombzen> vorbis uses the vorbis algorithm [09:30:14 CEST] <thebombzen> that's literally what an audio codec does [09:30:21 CEST] <thebombzen> it's a compresion algorithm for audio [09:30:28 CEST] <thomedy> right i think i knew that [09:30:41 CEST] <thomedy> general concepts im prob good on [09:30:47 CEST] <thebombzen> but it's lossy, so the original isn't perfectly reconstructable from the compressed file [09:30:54 CEST] <thomedy> details and pragmatic applications are what im after now [09:31:02 CEST] <thebombzen> then do you have an actual quesiton [09:31:05 CEST] <thomedy> right because its lossy i know [09:31:17 CEST] <thebombzen> or are you going to mess up arithmetic and mention how your bad arithmetic isnt' right [09:31:26 CEST] <thebombzen> because right now you're just kind of mumbling about things [09:31:45 CEST] <thomedy> you know im learning right... and reading and asking genuine questions im not an idiot.. [09:32:18 CEST] <thebombzen> you have yet to ask a direct question [09:32:20 CEST] <thomedy> i was operating under the assumption that ffmpeg -i would give me enough info but i m learning now that it is not [09:32:42 CEST] <thomedy> so i will probably have to read the vorbis algorithm [09:32:50 CEST] <thebombzen> no you don't [09:33:00 CEST] <thebombzen> you haven't actually asked what you want to know [09:33:24 CEST] <thomedy> yes i did im trying to determine how many kb/s from file size and duration i have [09:33:34 CEST] <thebombzen> do you want to know the bitrate of an OGG file? ffmpeg should tell you that if you run "ffmpeg -i file.ogg" unless it's not in the ogg header [09:33:37 CEST] <thomedy> i.e. this song is 4:13 [09:33:38 CEST] <thebombzen> but it should be in the header [09:34:06 CEST] <thomedy> here ill give you ane xample of wht confuses me [09:34:15 CEST] <thomedy> and i saw the kb/s in ffmpeg -i [09:34:16 CEST] <thomedy> one sec [09:34:43 CEST] <thomedy> sound.ogg is 267 kb/s [09:34:53 CEST] <thomedy> the song is 253.6 seconds [09:35:13 CEST] <thebombzen> why is that confusing? [09:35:35 CEST] <thomedy> the file size is 8484377 bits [09:35:46 CEST] <thomedy> 267000 * 253.6 is not 8484377 [09:35:50 CEST] <thomedy> its 64--------- [09:36:13 CEST] <thomedy> so im missing something [09:36:20 CEST] <thebombzen> it sounds like the file is 8 megabytes in size, not 8 megabits [09:36:31 CEST] <thebombzen> remember there's 8 bits in a byte, and the filesize will be listed in bytes. [09:36:35 CEST] <thomedy> right [09:36:45 CEST] <thebombzen> you're off by a factor of 8, so that sounds about right. [09:37:27 CEST] <thomedy> jesus it isn't me its that im assuming something about ls -al [09:37:29 CEST] <thomedy> thank you [09:37:35 CEST] <thomedy> i hadn't noticed precision on that [09:37:46 CEST] <thomedy> i was right and also resoundingly wrong [09:37:50 CEST] <thomedy> thank you again [09:37:53 CEST] <thomedy> oh my god... [09:37:56 CEST] <thebombzen> 267000 * 253.6 divied by 8 is 8463900, which is close enough to 8484377 that it's right, because 267 kbps is an approximation [09:37:56 CEST] <thomedy> okay let me test th [09:39:29 CEST] <thomedy> what im going to assume until i read it [09:39:39 CEST] <thomedy> is that ls -al is listing the file size in BYTES not bits [09:39:49 CEST] <thomedy> which is the opposite of what i was assuming [09:40:56 CEST] <thomedy> i just ran a test on sound.mp3 same thing [09:40:57 CEST] <thomedy> roughly [09:41:05 CEST] <thomedy> hmmm... good news [09:41:11 CEST] <thebombzen> it should not surprise you that bitrate means bits per second [09:41:20 CEST] <thebombzen> that is exactly what bitrate menas [09:41:31 CEST] <thomedy> ha thats funny i forget sometimes what the internet is like.... no thata is not what is surprising me [09:41:33 CEST] <thomedy> bu tthank you [12:03:26 CEST] <kerio> itunes aac is the best encoder right [12:03:35 CEST] <kerio> at 128kbps stereo [12:06:40 CEST] <BtbN> Probably fdk [12:06:48 CEST] <BtbN> But ffmpeg aac is just fine for lc as well [16:05:37 CEST] <AnonBaiter> h [16:05:51 CEST] <AnonBaiter> so [16:06:40 CEST] <algun_> Is it possible to extract audio from an online mp4 file downloading just the chunks necessary? [16:11:25 CEST] <AnonBaiter> anyway I`m just here to post a sample [16:11:26 CEST] <AnonBaiter> https://www.sendspace.com/file/mcbfg4 [16:12:48 CEST] <AnonBaiter> these DUK+FRM+HDR+TBL pairs came from a 3DO game called "Slam 'N Jam '95" [16:13:14 CEST] <AnonBaiter> that same format was used for the 3DO game called "The Horde" [16:15:09 CEST] <durandal_1707> AnonBaiter: if its audio only, try vgmstream [16:16:22 CEST] <AnonBaiter> I don't think it stores just audio however [16:17:15 CEST] <AnonBaiter> I tried to get .aif files from The Horde to work on foobar2000 with the vgmstream component installed(which is the latest version) and it didn't recognize it [16:17:30 CEST] <AnonBaiter> ffmpeg recognized that .aif format [16:23:10 CEST] <algun_> Guys? [16:23:44 CEST] <JEEB> not sure if the demuxer just skips instead of going through all packets :P [16:24:34 CEST] <JEEB> with enough logging you could check what lavf does there to test [16:29:05 CEST] <AnonBaiter> heh [18:06:37 CEST] <thebombzen> so, if I play an audio file using ffplay without the display, i.e, "ffplay -nodisp audio_file.ogg" then the CLI interface ignores Q [18:06:48 CEST] <thebombzen> the usual keyboard shortcut to tell it to exit [18:07:36 CEST] <thebombzen> as usual, ffplay doesn't exit when the audio file ends, but it also doesn't respond to q either with -nodisp, so I have to press ^C after the file is done [18:07:38 CEST] <thebombzen> this sounds like a bug [19:19:34 CEST] <lesshaste> I am trying to make ffmpeg in cygwin following http://www.mediaentertainmentinfo.com/2014/01/1-technical-series-how-to-com… [19:19:57 CEST] <lesshaste> I got to "make distclean" but I get Makefile:210: /tests/Makefile: No such file or directory [19:19:57 CEST] <lesshaste> make: *** No rule to make target '/tests/Makefile'. Stop. [19:20:50 CEST] <lesshaste> what am I doing wrong? [19:22:09 CEST] <Fenrirthviti> lesshaste: you don't really need to do a distclean for a new build [19:22:38 CEST] <lesshaste> Fenrirthviti, so should it just be "make"? [19:22:51 CEST] <Fenrirthviti> no, just ignore that command. but looks like you're not in the right directory [19:23:02 CEST] <Fenrirthviti> did you cd to ffmpeg first after cloning the repo? [19:23:34 CEST] <lesshaste> yes.... I just ran ./configure and am trying that [19:23:43 CEST] <lesshaste> I mean configure then make [19:24:40 CEST] <lesshaste> I assume I need to run "make" to compile it? [19:24:48 CEST] <Fenrirthviti> yes [19:26:24 CEST] <lesshaste> it's doing something :) [19:43:37 CEST] <lesshaste> how would you cut out minute 1 to minute 2 of a video? Something like ffmpeg -ss 01:00 movie.mp4 -vcopy -acopy -o cut.mp4 ? [19:44:47 CEST] <lesshaste> ffmpeg -i movie.mp4 -ss 00:00:03 -t 00:00:08 cut.mp4 cuts out 8 seconds I think [19:44:59 CEST] <lesshaste> I would just like to specify an end time [19:45:11 CEST] <dystopia_> -t before -ss [19:45:54 CEST] <lesshaste> ffmpeg -i movie.mp4 -acodec copy -vcodec copy -t 00:00:08 -ss 00:00:03 [19:45:57 CEST] <lesshaste> ? [19:45:57 CEST] <dystopia_> ffmpeg -t 60 -i input.mp4 -ss 00:01:00 -vcodec copy -acodec copy out.mp4 [19:46:12 CEST] <dystopia_> -t xx is how long you want, so 60s is 1m [19:46:26 CEST] <dystopia_> -ss is your start time so 00:01:00 is start at 1m in [19:46:32 CEST] <lesshaste> right but I can I say why I actually want it to en instead of having to say how long?? [19:46:37 CEST] <dystopia_> so that would cut 1m of content from 1m to 2m [19:46:51 CEST] <dystopia_> i don't think so [19:46:51 CEST] <lesshaste> s/why/when [19:46:54 CEST] <lesshaste> ok thanks [19:53:42 CEST] <lesshaste> https://bpaste.net/show/79ab10e618d0 essentially failed [19:53:46 CEST] <lesshaste> it gives a 262 byte output [19:53:51 CEST] <lesshaste> any idea why? [19:54:15 CEST] <lesshaste> are the h264 messages telling me there is a serious problem? [20:05:04 CEST] <lesshaste> ffmpeg -t 240 -i Skt.\ Hans\ med\ Søren\ Ryge-skt-hans-med-soeren-ryge.mp4 -ss 00:05:00 -vcodec copy -acodec copy out.mp4 fails [20:05:20 CEST] <lesshaste> but ffmpeg -t 240 -i Skt.\ Hans\ med\ Søren\ Ryge-skt-hans-med-soeren-ryge.mp4 -ss 00:00:00 -vcodec copy -acodec copy out.mp4 works [20:05:22 CEST] <lesshaste> any ideas why? [20:07:44 CEST] <dystopia_> how long is the video [20:08:24 CEST] <dystopia_> your asking it to cut 4 mins of video, starting from 5mins into the source video, so 5m to 9m [20:08:49 CEST] <dystopia_> but if that video doesn't exist there it will probably fail [20:09:13 CEST] <lesshaste> 48 minutes long [20:10:20 CEST] <lesshaste> dystopia_, https://bpaste.net/show/910b2f1b02be is the result of ffmpeg -i [20:11:30 CEST] <lesshaste> this is very frustrating [20:11:42 CEST] <lesshaste> what can I do? [20:12:56 CEST] <dystopia_> https://trac.ffmpeg.org/wiki/Seeking [20:12:58 CEST] <dystopia_> hmm [20:13:14 CEST] <dystopia_> "-ss 60 -to 70" seems useful [20:13:35 CEST] <dystopia_> ffmpeg -i Skt.\ Hans\ med\ Søren\ Ryge-skt-hans-med-soeren-ryge.mp4 -ss 00:05:00 -t 00:09:00 -vcodec copy -acodec copy out.mp4 [20:13:39 CEST] <dystopia_> give that a try [20:14:09 CEST] <dystopia_> or try [20:14:22 CEST] <lesshaste> that works! [20:14:23 CEST] <dystopia_> ffmpeg -i Skt.\ Hans\ med\ Søren\ Ryge-skt-hans-med-soeren-ryge.mp4 -ss 300 -t 540 -vcodec copy -acodec copy out.mp4 [20:14:26 CEST] <dystopia_> nice :) [20:14:39 CEST] <lesshaste> so the problem is where -t was? [20:14:41 CEST] <dystopia_> -t was meant to be -to [20:14:42 CEST] <dystopia_> heh [20:14:59 CEST] <lesshaste> or -t was before -ss !! [20:15:14 CEST] <lesshaste> something seems broken here :) [20:17:04 CEST] <lesshaste> thanks dystopia_ [20:17:51 CEST] <dystopia_> np [23:48:34 CEST] <ArsenArsen> I'm trying to compile my program which uses libav* stuff on Ubuntu 16.04 but the build fails, I get https://hastebin.com/viranuwuti.cs in the output, but it works perfectly fine on my local Arch machine [23:49:16 CEST] <BtbN> 16.04 has an ancient version of libav, not even ffmpeg. [23:49:23 CEST] <ArsenArsen> Oh shit [23:49:57 CEST] <ArsenArsen> What about 16.10 or some other? [23:51:43 CEST] <BtbN> https://packages.ubuntu.com/zesty/libavformat-dev [23:51:45 CEST] <ArsenArsen> apt-cache search tells me otherwise though, libavcodec-dev - FFmpeg library with de/encoders for audio/video codecs - development files [23:51:47 CEST] <ArsenArsen> yeah [23:51:54 CEST] <ArsenArsen> That is what I used [23:52:06 CEST] <BtbN> xenial switches from libav to ffmpeg [23:52:11 CEST] <BtbN> trusty is still using libav [23:52:26 CEST] <ArsenArsen> Oh I see [23:52:32 CEST] <ArsenArsen> I'll do a release upgrade and pray [23:52:38 CEST] <ArsenArsen> Thanks for letting me know! [23:52:46 CEST] <BtbN> isn't 16.04 xenial? [23:53:18 CEST] <BtbN> That is ffmpeg, just an old version, 2.8 [23:53:39 CEST] <BtbN> The send/recv packet API did not exist back then [23:53:53 CEST] <ArsenArsen> Still, upgrade won't hurt [23:54:05 CEST] <ArsenArsen> Actually, what version was the send/receive API introduced in? [23:54:46 CEST] <BtbN> no idea, ask git [23:54:55 CEST] <ArsenArsen> Ok, thanks [00:00:00 CEST] --- Sun Jun 25 2017

1 0

ffmpeg-devel.log.20170623
by burek 24 Jun '17

24 Jun '17

[00:13:40 CEST] <atomnuker> jamrial: what alignment should I use? 16 [00:14:02 CEST] <jamrial> 16 is default and impled, so just don't write any number [00:14:39 CEST] <atomnuker> also, isn't the function avx2? [00:14:46 CEST] <atomnuker> rather than avx? [00:15:26 CEST] <atomnuker> I'm confused on the whole avx2 and avx matter [00:15:35 CEST] <atomnuker> which one does 256bit registers? [00:15:36 CEST] <nevcairiel> you wrote float code, so hopefully avx? x86inc should yell at you if you use instructions that are not in that instruction set [00:15:37 CEST] <iive> atomnuker: it's like sse1 vs sse2 [00:15:45 CEST] <nevcairiel> atomnuker: both, avx is fl oat, avx2 is integer [00:15:50 CEST] <iive> avx1 have only float point 256 registers [00:15:51 CEST] <nevcairiel> (in broad general terms) [00:16:54 CEST] <iive> nevcairiel: if x86inc doesn't overload avx2, then it won't tell you if you use it improperly [00:18:12 CEST] <nevcairiel> maybe it only does that for sse thingys [00:20:02 CEST] <jamrial> atomnuker: avx added ymm regs that can be used for float instructions. avx2 added the possibility to use the ymm regs on integer instructions [00:20:28 CEST] <jamrial> you're only using float instructions, so they work on any avx cpu [00:21:33 CEST] <jamrial> fma3 adds the fused multiply add instructions, and is available on less CPUs than avx [00:22:05 CEST] <atomnuker> confusing, I thought avx2 to be a superset of avx [00:22:17 CEST] <iive> it is [00:22:26 CEST] <jamrial> it is. it adds stuff on top of avx [00:22:34 CEST] <atomnuker> and I thought avx added 256bit regs but without any instructions which actually did 256bit regs [00:22:42 CEST] <nevcairiel> what would be the point of that :D [00:22:45 CEST] <jamrial> why would it do that? :P [00:22:47 CEST] <iive> btw, sse1 also lacked integer ops for 128 registers [00:23:54 CEST] <nevcairiel> at least with avx512 they did float and int on the same cpu right away - even though its technically split into different feature sets, no cpu (so far) only implements one of them and not the other [00:44:54 CEST] <atomnuker> jamrial: ok, patch v3 sent, all should be good now [01:22:16 CEST] <rcombs> nevcairiel: never mind how the avx512 feature sets are a mess [01:24:07 CEST] <rcombs> wm4: someone with the relevant access should lock that PR's thread; there's no productive discussion to be had in there [01:24:52 CEST] <wm4> maybe jamrial [01:37:24 CEST] <jamrial> wm4: i have no control over the github mirror [01:38:12 CEST] <wm4> oh [01:38:43 CEST] <nevcairiel> rcombs: the only thing that really matters is what cpus they actually make (also, just ignore the knights landing stuff) [01:39:08 CEST] <wm4> michaelni, BtbN have [01:48:27 CEST] <Gramner> well, xeon phi only support 32 and 64 bit int math in it's avx-512 subset, but nobody outside of HPX cares about that so whatever. [01:48:33 CEST] <Gramner> HPC* [01:49:16 CEST] <Gramner> all "normal cpus" will have a sensible avx-512 feature subset [01:55:45 CEST] <atomnuker> unless there are any more issues I'll be pushing the fft15 asm soon [01:56:21 CEST] <iive> atomnuker: the commens once again doesn't mirror the code :P i'm talking about the movsd section... [01:57:25 CEST] <iive> the start of fft5, [01:57:28 CEST] <atomnuker> oh ffs I'll drop the bloody comment [01:57:54 CEST] <iive> maybe it is not the comment that is wrong [01:58:25 CEST] <atomnuker> it doesn't help anyway, I need to stare at that code for an hour until I know what 2 instructions do [01:59:08 CEST] <iive> and... [01:59:53 CEST] <jamrial> atomnuker: chill [02:01:16 CEST] <atomnuker> rcombs: got some aac-eld/ld samples? [02:01:39 CEST] <atomnuker> I'd also like some aac960 samples [02:01:51 CEST] <iive> atomnuker: i found this quite useful https://software.intel.com/sites/landingpage/IntrinsicsGuide/# [02:02:03 CEST] <rcombs> my laptop and phone generate that for bluetooth headphones, but I don't have anything to capture it [02:04:32 CEST] <atomnuker> huh, fdk_aac apparently supports them [02:05:03 CEST] <iive> atomnuker: once again, are you sure that "movsd xm2,...." should not be simple "movups" ? [02:05:09 CEST] <iive> same for following xm3 [02:05:50 CEST] <kierank> atomnuker: ask mathias for aac960 samples [02:07:13 CEST] <jamrial> iive: he changed it from movups to movsd at my request [02:07:24 CEST] <iive> jamrial: but that's wrong [02:07:27 CEST] <jamrial> why do you say it should be movups? [02:07:48 CEST] <iive> movsd loads only 64 bits and zeroes the high 64 [02:07:52 CEST] <jamrial> yes [02:08:06 CEST] <iive> he needs to load 4 floats, 128 bits [02:08:12 CEST] <jamrial> no [02:08:24 CEST] <jamrial> he needs 64 at that offset, 64 at the offset xm1 loads from [02:08:28 CEST] <iive> in[5].re/in and in[6].re/in [02:08:30 CEST] <jamrial> then shufps puts them together [02:09:01 CEST] <jamrial> if you're basing this on the comments, then i guess they are wrong [02:09:38 CEST] <Gramner> could use movsd+movhps instead of 2x movsd+shufps [02:09:50 CEST] <jamrial> that's probably slower [02:10:02 CEST] <iive> well, i do hope it is the comments that are wrong [02:10:09 CEST] <jamrial> movhps with reg as dst is pretty slow [02:10:17 CEST] <jamrial> iive: fate-opus would fail if it was wrong [02:10:31 CEST] <Gramner> why? both are 2 loads + one shuffle µop [02:10:32 CEST] <iive> maybe.... [02:10:48 CEST] <Gramner> but one is shorter code size [02:11:29 CEST] <iive> avx have huge prefixes... it bloats the code out of proportion [02:11:36 CEST] <Gramner> also vbroadcastsd instead of movddup + vinsertf128 [02:12:12 CEST] <Gramner> vex (avx) has the same instruction length as legacy sse for the vast majority of instructions [02:12:21 CEST] <Gramner> some are one byte longer [02:12:39 CEST] <Gramner> evex instructions are long as fuck though [02:16:12 CEST] <iive> ok, minor nitpic 2*16+16 -> 3*16 [02:18:29 CEST] <iive> I just cannot remember if there is any pentaly for loading register as double and then using it as float. [02:18:46 CEST] <Gramner> there isn't [02:19:29 CEST] <Gramner> there's only a difference between integer and floating-point, not between single- and double-eprecision floating-point [02:20:23 CEST] <Gramner> so there's no reason to ever use movapd over movaps for example [02:21:43 CEST] <iive> i'm sure i've read something about these... in the intel documentation [02:21:48 CEST] <iive> but can't find it atm [02:22:03 CEST] <Gramner> it says "use movaps" [02:22:30 CEST] <Gramner> iirc [02:23:24 CEST] <jamrial> movapd/unpck[lh]pd are superfluous, yeah, and i think they are also one byte longer than the alternatives [02:24:45 CEST] <Gramner> vmovaps in avx-512 (evex) has a use can when using opmasks since they are size-specific, but it's irrelevant in legacy sse and avx (vex) [02:24:48 CEST] <iive> "because movaps is one byte shorted than movapd " [02:24:49 CEST] <Gramner> vmovapd* [02:35:07 CEST] <RiCON> just sent a patch to:ffmpege-devel@ffmpeg.org ... [02:37:25 CEST] <jamrial> oh boy, i predit bikeshedding for it [02:37:41 CEST] <jamrial> predict* [02:38:29 CEST] <RiCON> the libvorbis one? [02:38:46 CEST] <jamrial> the libgme one [02:38:58 CEST] <RiCON> hm, 2013 too soon? [02:44:38 CEST] <iive> atomnuker: i think somebody said that it is better to use 2 "movaps xmm" instead of "movaps ymm + vextractf128" [02:44:50 CEST] <iive> vexractf128 have 3 cycles latency [02:45:09 CEST] <Gramner> I replied to the ML instead [02:45:30 CEST] <iive> Gramner: oh, i didn't see your email yet. [02:45:47 CEST] <Gramner> yeah, cross-lane shuffles are slow. memory loads are pretty fast on the other hand (can do 2 per cycle on most modern cpus) [02:46:19 CEST] <jamrial> i didn't get anything yet. guess the ml is slow today [02:46:29 CEST] <Gramner> just sent it [02:52:27 CEST] <atomnuker> iive: yes, it was slower [02:52:49 CEST] <iive> it's still in your code. [02:53:28 CEST] <atomnuker> yes, it was slower to do 2 movaps [02:54:05 CEST] <atomnuker> I'll test it again though [02:54:06 CEST] <RiCON> jamrial: there, sent the use_pkg_config for libgme too [02:54:13 CEST] <RiCON> should be easier to accept [03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:27f80ab0160d: avcodec/tiff: Update pointer only when the result is used [03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:0c2ef4f6b4d5: avcodec/takdec: Fix integer overflow [03:04:03 CEST] <cone-136> ffmpeg 03Michael Niedermayer 07master:24e95f9d4de0: avcodec/wavpack: Fix integer overflow [03:07:49 CEST] <atomnuker> Gramner: holy crap, removing the 2 shuffles at the start gave around 80 decicycles [03:08:03 CEST] <atomnuker> "Adding m1 and m3 before shuffling" <- do you mean the addps m0, m1? [03:08:20 CEST] <iive> no [03:08:38 CEST] <iive> you do m0+m1, then m0+m3 , or something like that [03:09:54 CEST] <atomnuker> hold on, I could just adjust my twiddles and remove both, I think [03:10:17 CEST] <iive> are twiddles constants? [03:10:38 CEST] <atomnuker> I already permute them in the init function [03:11:09 CEST] <atomnuker> q2301 -> this exchanged real and imaginary, didn't it? [03:11:47 CEST] <iive> why are you asking me, and yes :) [03:12:21 CEST] <atomnuker> because I already forgot and I'm not used to the q<stuff> notation [03:12:36 CEST] <atomnuker> (the q<stuff> notation is awesome though) [03:21:22 CEST] <atomnuker> crap, didn't notice those were mulps, not movs [03:28:03 CEST] <atomnuker> nevermind, I saw what he meant [03:30:46 CEST] <iive> sorry, I thought i typed the longer explanation... [03:52:09 CEST] <atomnuker> iive: sent a v4 to the ML, this time I can absolutely say the comments are correct [03:52:24 CEST] <iive> :) [03:52:46 CEST] <iive> i'll check it tomorrow :) [04:06:18 CEST] <jamrial> michaelni: you run all the netbsd fate slots. could you post the output of for example "make libavfilter/x86/af_afir.o V=1" somewhere? [04:06:27 CEST] <jamrial> also the contents of the "X86ASMDEP=" line in config.mak [04:07:07 CEST] <jamrial> or even see if you can find what's wrong since you can actually test it... [04:07:57 CEST] <jamrial> i'm guessing it could be either bash or make in your netbsd environment. no other system seems to have this problem [04:25:24 CEST] <michaelni> jamrial, https://pastebin.com/fnaja4U8 [04:25:53 CEST] <jamrial> wtf, why is it failing then [04:33:23 CEST] <jamrial> michaelni: does yasm -v succeed? [04:38:06 CEST] <jamrial> the "-MD file.d" part shouldn't be in the second call to yasm, that's what making it fail [04:38:09 CEST] <jamrial> but configure is supposed to make sure it's only added to nasm... [04:38:45 CEST] <jamrial> michaelni: can you do a "grep X86ASM" to config.mak as well? [04:40:34 CEST] <michaelni> yasm: warning: unrecognized option `-v' [04:41:22 CEST] <jamrial> why the hell is it adding flags from the configure section that requires -v to succeed then... [04:41:51 CEST] <michaelni> https://pastebin.com/iamypCvh [04:43:00 CEST] <jamrial> yeah, X86ASM_DEPFLAGS should be blank [04:43:14 CEST] <jamrial> i have no idea how this is happening [04:43:16 CEST] Action: michaelni falls asleep ... ping me tomorrow if theres more i shoud test [04:43:50 CEST] <jamrial> sure, thanks [07:04:28 CEST] <LokerPoker> Does ffmpeg offer space for beginners who want to contribute ? [07:05:08 CEST] <LokerPoker> Space as in - Is there any scope for beginners wishing to contribute ? [07:16:08 CEST] <DHE> if you can write a patch that's worthwhile and meeting the guidelines, it can be accepted. [07:16:23 CEST] <DHE> I submitted my first patch as a nobody and it was accepted [07:21:06 CEST] <LokerPoker> DHE: I am a bit naive to all this. But I have used ffmpeg and ffserver before too. A little more direction on what to learn, what to focus on, can be a great help for me. [07:21:51 CEST] <DHE> well, in general I would ask, what is ffmpeg missing or what bugs are you running into? then fix them. [07:22:17 CEST] <DHE> a bit of "necessity is the mother of invention", but usually more rewarding than just crawling the issue tracker and picking something [09:35:58 CEST] <jya> is it common in a H264 stream, to have a SPS before every I-frame, that are almost identical to the previous one but with changing num_units_in_tick? [09:40:21 CEST] <rcombs> jya: it's pretty common to repeat SPS periodically (usually before keyframes [either IDRs or Is with recovery SEI]); not sure about the num_units_in_tick changing [09:40:44 CEST] <jya> rcombs: well, this is in a MP4 [09:41:10 CEST] <jya> so far I had only ever seen repeating SPS/PPS in front for each keyframe [09:41:11 CEST] <wm4> mp4s don't normally have sps in stream [09:41:16 CEST] <rcombs> it's less common but not exactly rare in MP4 [09:41:17 CEST] <jya> but they were identical [09:41:20 CEST] <wm4> (not sure if they're allowed or forbidden) [09:41:29 CEST] <rcombs> wm4: they're allowed afaik [09:41:46 CEST] <wm4> rcombs: even if they're not in the avcc data? [09:41:58 CEST] <jya> wm4: I think it's just a quick and dirty conversion from mpeg-ts to mp4... they dont bother changing the streams (other than converting from annexb to avcc) [09:42:05 CEST] <rcombs> generally if you remux from MPEGTS to MP4, the first SPS and PPS get copied to the avcc, but they're often not actually removed from the packets [09:42:07 CEST] <wm4> (not sure if they are in this case, but if they subtly change every time...) [09:42:22 CEST] <rcombs> yeah, not sure if that's legal, but it's definitely possible [09:42:30 CEST] <rcombs> and players handle it fine in my experience [09:42:51 CEST] <wm4> did I mention yet that I hate how the h264 extradata is defined [09:43:00 CEST] <jya> in this video they keep changing, absolute pain... https://people-mozilla.org/~jyavenard/mediatest/Firefox%20%f0%9f%a6%8a%f0%9…'s%20multi-process%20Firefox-1.mp4 [09:43:02 CEST] <wm4> it seems to cause so many issues and problems [09:43:04 CEST] <rcombs> I don't think so but yeah it's bad [09:43:15 CEST] <jya> wm4: you have AVC3 [09:43:19 CEST] <wm4> jya: so, what's the actual problem? [09:43:32 CEST] <jya> it's like avcc but no extradata in the demuxer [09:44:02 CEST] <wm4> does apple's VT API support that? (that's when this stuff gets real horrible) [09:44:02 CEST] <jya> well, i have to detect change of contents mid-stream (as we've had videos not playing once a change occurred) [09:44:13 CEST] <jya> apple VT doesn't support that exactly [09:44:15 CEST] <wm4> the ffmpeg decoder handles this transparently [09:44:19 CEST] <jya> that's why it's such a pain [09:44:27 CEST] <jya> and I have to use Apple VT [09:44:37 CEST] <rcombs> oh man [09:44:39 CEST] <rcombs> I'm so sorry [09:44:42 CEST] <wm4> me too [09:44:53 CEST] <wm4> ffmpeg's VT wrapper is also not working too well too [09:45:04 CEST] <rcombs> VT's a clusterfuck [09:45:07 CEST] <jya> so I added some code that look for SPS, and if they change I must drain the decoder, destroy it, create a new one and continue my merry way [09:45:22 CEST] <jya> but with that video, as it looks like we have a new and different SPS [09:45:30 CEST] <wm4> I think there was a patch on ffmpeg-devel that solves soemthing with sps changes and VT [09:45:39 CEST] <jya> i end up draining + destroying + create a new decoder every i-frame [09:45:54 CEST] <wm4> drain what? [09:45:57 CEST] <rcombs> this actually sounds a lot like an issue I've seen on Apple TV [09:46:07 CEST] <wm4> the VT API has no concept of that because you need to reorder frames yourself [09:46:26 CEST] <rcombs> wm4: it can still be async [09:46:31 CEST] <jya> drain the decoder, which is from our re-order queue (still have to wait for the async VT task to complete if any pending [09:46:47 CEST] <wm4> rcombs: true [09:46:49 CEST] <rcombs> a lot of commercial blu-ray streams have superfluous SPS changes like that [09:46:55 CEST] <rcombs> and Apple TV shits itself on those [09:46:56 CEST] <jya> we use the VT decoder in full async mode, (ffmpeg doesn't) [09:47:10 CEST] <wm4> ffmpeg can't because of its design [09:47:14 CEST] <wm4> although we'd like it to [09:47:38 CEST] <wm4> (we've been thinking of making VT a full decoder instead of hwaccel in ffmpeg) [09:47:53 CEST] <rcombs> I've got a patch for that laying around, it just falls apart on reorder [09:48:04 CEST] <wm4> ffmpeg does do partial SPS change detection, so that reminded me of it [09:48:13 CEST] <wm4> (but it also seems to cause issues sometimes, hurr) [09:48:26 CEST] <jya> well, I'm going to do a dirty hack, decode the SPS into my structure, and compare every fields but num_units_in_tick that will do for now [09:48:36 CEST] <ubitux> rcombs: honestly, i'd rather have basic reordering based on packet pts data and be done with that [09:48:48 CEST] <wm4> SIN [09:49:01 CEST] <ubitux> than waiting forever for an architectural change that will never happen [09:49:01 CEST] <rcombs> ubitux: yeah, I've got that, but it's not reliable in all containers, so it'd regress in some cases [09:49:30 CEST] <wm4> I'm more worried about decoder delay, but could always force 16 I guess [09:49:43 CEST] <jya> rcombs: we only use the pts as marked in the container for reorderning the frames. [09:49:47 CEST] <jya> it's never caused us issue [09:49:57 CEST] <rcombs> jya: your use-case is much narrower, though [09:50:23 CEST] <rcombs> you don't have to support broken AVIs, for instance [09:50:31 CEST] <rcombs> or raw .264 files [09:50:42 CEST] <ubitux> wasn't the main use case raised mpeg ts? [09:51:12 CEST] <rcombs> or certain mpegts streams, yeah [09:51:13 CEST] <jya> rcombs: that's true [09:51:15 CEST] <ubitux> is anyone able to identify where that code even lie currently? [09:51:27 CEST] <rcombs> sure, it's right here [09:51:30 CEST] <ubitux> "lavf/utils.c"? [09:51:36 CEST] <ubitux> no i mean, the reordering thing [09:51:41 CEST] <rcombs> https://gist.github.com/93f7e4ab4f97ead9f8ce87c3a6bc7039 [09:51:46 CEST] <rcombs> oh that, uh [09:51:49 CEST] <rcombs> ¯\_(Ä)_/¯ [09:52:29 CEST] <jya> actually just had a video, where the SPS change in the middle in such a way that the Microsoft H264 MFT crash big time [09:52:29 CEST] <rcombs> I think I suggested to jkqxz that he might make a bsf to automatically generate missing timestamps in h264 streams based on the internal reordering data [09:52:35 CEST] <rcombs> jya: nice [09:52:47 CEST] <jya> so detected change of SPS on windows too is useful [09:52:49 CEST] <rcombs> ~closed-source implementations~ [09:53:01 CEST] <jya> but I don't want too many false positive. [09:53:22 CEST] <rcombs> jya: is the teardown+reconfigure particularly expensive, then? [09:54:18 CEST] <wm4> I wrote a MF wrapper too and it could do h264, but it wasn't too useful after all [09:54:18 CEST] <ubitux> libavformat/avc.c:static const uint8_t *ff_avc_find_startcode_internal(const uint8_t *p, const uint8_t *end) [09:54:23 CEST] <jya> well, it's kind of a pain becaus on windows the H264 MFT has a super high latency [09:54:27 CEST] <ubitux> why is this currently in the codebase with ff + static [09:54:27 CEST] <jya> it buffers 30+ frames [09:54:32 CEST] <ubitux> and duplicated in rcombs patch :3 [09:54:55 CEST] <jya> so when you drain , you get a big memory usage spike ... [09:54:57 CEST] <ubitux> ah, lavf, lavc. [09:55:22 CEST] <jya> not sure if it's expensive or not, but the handling of failure is pain as we now run the decoding process in another process in its own jail [09:56:13 CEST] <ubitux> rcombs: did you try hevc with that decoder? [09:56:24 CEST] <rcombs> haven't installed 10.13 yet [09:56:36 CEST] <jya> rcombs: that video https://bug1313398.bmoattachments.org/attachment.cgi?id=8805171 [09:56:59 CEST] <jya> if you seek, you end up on a frame with a different SPS than what was found in the extradata [09:57:16 CEST] <jya> for some reason, if you play continuously, the H264 MFT handles it properly [09:57:25 CEST] <jya> but feed it data from a random keyframe, and boom [09:58:28 CEST] Action: jya sad about Apple decision on hevc [10:00:38 CEST] <wm4> jya: so, why not stop input until the decoder is drained naturally?you'd still need to buffer input (or have a "spike" of requested packets the demuxer), but presumably overall memory won't grow? [10:00:56 CEST] <wm4> also what apple decision on hevc? [10:01:34 CEST] <rcombs> supporting it as opposed to VP9, presumably? [10:02:01 CEST] <rcombs> ETA on a decent encoder? [10:02:03 CEST] <jya> as opposed to AV1 :) [10:02:16 CEST] <nevcairiel> AV1 is still years away from real-world use =p [10:02:19 CEST] <rcombs> well AV1's mostly vaporware atm, so& [10:02:36 CEST] <jya> oh we're getting some demo going [10:02:49 CEST] <wm4> anyway, hevc has the same avcc nonsense [10:02:53 CEST] Action: wm4 groans [10:03:00 CEST] <rcombs> "demo" is a long way from "suitable for use right now" [10:03:09 CEST] <nevcairiel> the bitstream isnt even done yet, so you can demo all you want, its just not close to real-world use [10:03:11 CEST] <jya> in partnership with bitmovin. [10:03:20 CEST] <rcombs> what are the odds that AV1 ends up with an encoder that actually competes with x264 [10:03:31 CEST] <rcombs> in all seriousness, that's good to hear [10:03:52 CEST] <jya> just yet another codec, with an even more silly licensing model [10:04:11 CEST] <rcombs> but the only remotely sane alternative to HEVC right now is VP9, and the encoder situation there is even worse [10:07:57 CEST] <jya> anyone in SFO next week? [10:08:15 CEST] <jya> There's a Video Tech meetup on Thursday evening [11:05:51 CEST] <BtbN> wm4, you mean lock the "No PRs on this repo PR", or some other one? [11:06:45 CEST] <thebombzen> don't forget that google is trying to patent the entropy encoding in av1, even though they didn't invent it [11:06:57 CEST] <thebombzen> which is kind of contrary to the whole fking point of av1 [11:07:58 CEST] <nevcairiel> in todays world, someone will patent it, so getting a defensive patent first is the only way to defend against that [11:08:31 CEST] <thebombzen> That doesn't change the fact that you cannot patent something you didn't invent [11:08:48 CEST] <BtbN> how can you patent something that someone else made and decided not to patent? If that's possible, the whole system is flawed. [11:08:50 CEST] <thebombzen> or rather, shouldn't. You should not be awarded patents for things you didn't invent, and you shouldn't try anyway [11:09:17 CEST] <nevcairiel> BtbN: it occurs to you only now that the patent system is flawed? :p [11:09:33 CEST] <BtbN> I'm pretty sure it's not possible to do that in europe [11:09:38 CEST] <BtbN> No idea how fucked up it is in the US [11:09:43 CEST] <BtbN> but that would be pretty messed up [11:09:44 CEST] <thebombzen> BtbN: and yes, really. Google is trying to patent Asymmetric Numeral Systems entropy coding, in the US Patent Office [11:09:47 CEST] <thebombzen> https://encode.ru/threads/2648-Published-rANS-patent-by-Storeleap/page3 [11:10:28 CEST] <thebombzen> Here's the patent (which is, ironically, on google patents): https://www.google.com/patents/US20160248440 [11:11:10 CEST] <thebombzen> Someone on Reddit did the hard work of aggregating some articles, if you want to see their list: https://www.reddit.com/r/programming/comments/6h08z5/google_is_currently_tr… [11:12:49 CEST] <nevcairiel> the internet sure is slow, the patent was filled over a year ago =p [11:12:59 CEST] <thebombzen> didn't become public over a year ago [11:13:54 CEST] <thebombzen> I think the big deal is that Jarek Duda found out like a week ago about this. He is the one who invented it and was never informed [11:19:02 CEST] <wm4> <BtbN> wm4, you mean lock the "No PRs on this repo PR", or some other one? <- yes [11:19:14 CEST] <BtbN> I can do that. Anyone objects? [13:43:24 CEST] <cone-943> ffmpeg 03Jun Zhao 07master:ea1d07aed96a: lavc/golomb: add value range comment for set_ue_golomb(). [14:08:38 CEST] <atomnuker> RiCON: can you check if http://trac.ffmpeg.org/ticket/6484 breaks minigw builds? [14:08:48 CEST] <atomnuker> (we have fate instances of that, right?) [14:10:30 CEST] <RiCON> at least nevcairiel's [14:12:06 CEST] <RiCON> and there's no issue with msys2 mingw GCC, 32 or 64-bit, at least [14:14:44 CEST] <nevcairiel> my mingw-w64 builds with a very recent binutils and gcc still work at least [14:15:29 CEST] <JEEB> that bug report has no further information on it so it's almost as good as useless [14:15:38 CEST] <RiCON> was this with yasm or nasm, or does it even matter? [14:15:52 CEST] <nevcairiel> mine probably build with nasm now that the default was changed [14:16:07 CEST] <nevcairiel> but it also passed before that change [14:16:10 CEST] <nevcairiel> where yasm was still used [14:16:29 CEST] <nevcairiel> more annoyingly however, msvc shared builds are broken with nasm [14:16:57 CEST] <nevcairiel> nasm must somehow produce odd object files [14:16:57 CEST] <RiCON> i compiled yesterday before going to bed, which used nasm [14:20:14 CEST] <RiCON> objdump -t on .o files from .asm tells me the same formats (pe-i386 and pe-x86-64) as with .o from C [14:20:18 CEST] <RiCON> is that it? [14:46:27 CEST] <iive> and Daemon404 is back. [14:47:04 CEST] <Daemon404> well i had planned to lurk, but i see the very first line after rejoining is iive being an asshole, so. [14:48:37 CEST] <atomnuker> iive: he promised to buy everyone a beer at VDD if your PVQ simd gets merged [14:48:57 CEST] <atomnuker> so no wonder he's pissed [14:49:08 CEST] <iive> well, I'd like some benchmarks :P [14:49:21 CEST] <iive> i'll send updated patch later today. [14:49:34 CEST] <atomnuker> k, should I wait for those? [14:49:48 CEST] <iive> yes [14:50:17 CEST] <iive> but if you can give me some info about the problem you have with avx2, it'd be useful. [14:51:00 CEST] <atomnuker> are you actually using avx2? [14:51:11 CEST] <atomnuker> like, 256bit integer instructions? [14:52:30 CEST] <iive> yes [14:54:03 CEST] <kierank> derek should just ignore iive [14:54:09 CEST] <kierank> iive on ignore is a great decision [14:54:56 CEST] <Compn> just to be clear [14:54:57 CEST] <Compn> [08:46] <iive> and Daemon404 is back. [14:54:57 CEST] <Compn> [08:47] <Daemon404> well i had planned to lurk, but i see the very first line after rejoining is iive being an asshole, so. [14:55:10 CEST] <Compn> saying "and Daemon404 is back." is not "being an asshole" [14:55:20 CEST] <Compn> saying "being an asshole" is "being an asshole" [14:56:21 CEST] <Compn> the maturity level of some people is quite low around here. [14:56:42 CEST] <nevcairiel> if you knew the hsitory, you would realize that it kinda was being an asshole [14:57:06 CEST] <Compn> its not wise to fan the flames either [14:57:21 CEST] <Compn> as you cannot assume iive's intent with that message [14:58:50 CEST] <iive> nevcairiel: would you explain to me, how this is so? [14:58:53 CEST] <Compn> if people would stop assuming there is some hidden insult in every sentence, there would be less fights [14:59:09 CEST] <BBB> guys, guys [14:59:10 CEST] <BBB> enough [14:59:14 CEST] <BBB> please stop this discussion [14:59:17 CEST] <Compn> iive : from now on, greet english speakers as "hello ____, nice to see you again" [14:59:29 CEST] <Compn> iive : otherwise they will assume the worst intent from any other greeting [15:00:00 CEST] <iive> they are free to assume whatever they want. In only reflects what they are. [15:00:16 CEST] <Compn> yes, but also its nice to be nicer than they [15:00:48 CEST] <Compn> because usually it makes them twice as angry... [15:00:49 CEST] <Compn> ;) [15:01:00 CEST] <BBB> Compn: lets not make assumptions about peoples maturity level, lets just accept that some people cant get along and accept that silence is better than fights :( [15:01:10 CEST] <nevcairiel> [14:57:06] <Compn> its not wise to fan the flames either <-- and wtf are you doing now? :D [15:01:12 CEST] <BBB> some things cannot be fixed :( [15:01:42 CEST] <BBB> brb [15:01:46 CEST] <Compn> nevcairiel : explaining to iive what has happened. asking him to use nicer greetings. and asking you to not assume intent based on 4 words... [15:02:01 CEST] <nevcairiel> if that helps you sleep at night :) [15:02:02 CEST] <Compn> as well as kierank, but i think he will not change [15:02:43 CEST] <Compn> BBB : you're saying not to ask people to be nicer? ok then [15:04:44 CEST] <Compn> BBB : one idea i had was to do away with all discussions and only communicate via patches and patch reviews :D [15:04:53 CEST] <Compn> with all developers [15:05:10 CEST] <Compn> run it all through a moderating team that destroys any mail with non technical / code replies [15:05:38 CEST] <Compn> j-b might be interested in that :D [15:05:57 CEST] <iive> As Cardinal Richelieu has said "If you give me six lines written by the hand of the most honest of men, I will find something in them which will hang him." [15:06:14 CEST] <iive> Compn: calm down. it's over. let's talk about code. [15:08:39 CEST] <Compn> fair enough [15:08:50 CEST] <TMM> Cardinals finding reasons to hang honest people is also not particularly noteworthy :P [15:12:27 CEST] <Compn> i actually agree with kierank though, devs ignoring non technical discussions would be good idea [15:12:38 CEST] Action: Compn runs [15:38:23 CEST] <cone-943> ffmpeg 03jerett 07master:82a8724df2a5: lavc/videotoolboxenc: fix loadVTEncSymbols crash when symbol not found [15:38:24 CEST] <cone-943> ffmpeg 03jerett 07master:9f26d670e447: lavc/videotoolboxenc: fix open videotoolbox bug on iOS8.4 [16:16:46 CEST] <jamrial> michaelni: i think i foud what's wrong. the "graceful" fallback when nasm is too old is faulty [16:18:26 CEST] <jamrial> your netbsd environment must have a nasm < 2.03 and a recent enough yasm [16:20:12 CEST] <cone-943> ffmpeg 03Paul B Mahol 07master:04aa09c4bcf2: Revert "lavfi/buffersrc: push the frame deeper if requested." [16:24:15 CEST] <durandal_1707> anybody can lend me hand in REing atrac9? [16:28:13 CEST] <atomnuker> durandal_1707: need help with the transforms? [16:32:31 CEST] <durandal_1707> atomnuker: i need general help, i found bitstream stuff reading, but cant recognize stuff and what does it use for compression [16:32:48 CEST] <durandal_1707> it uses mdct for sure [16:32:55 CEST] <durandal_1707> up to 2 bands [16:33:08 CEST] <durandal_1707> and with bunch of subbands [16:33:35 CEST] <atomnuker> ah, that crap, it uses QMF to feed into ffts like mp3, right? [16:36:20 CEST] <mateo`> jamrial: hello, would http://sprunge.us/egGQ fix the sum_square test on x86 ? (i'm not familiar with x86 at all, and i was not able to reproduce the issue on my side) [16:37:54 CEST] <jamrial> mateo`: yes, but you can prevent adding that instruction if you instead replace the mov r2, r1 into mov r2d, r1d [16:38:47 CEST] <jamrial> r2 will have the higher 32 bits cleared that way [16:39:16 CEST] <jamrial> r1 gets and'd later in the function, so no need to do anything else to it [16:43:59 CEST] <mateo`> jamrial: updated version http://sprunge.us/jJYR [17:01:44 CEST] <durandal_1707> atomnuker: dunno, it calls mdct twice for each 1024 samples that are in block align [17:06:33 CEST] <durandal_1707> complexity is much lower than other atrac decoders afaik [17:07:06 CEST] <atomnuker> do you know what coding it uses? huffman? [17:14:51 CEST] <jamrial> mateo`: yeah, that should do it [17:15:14 CEST] <jamrial> make sure your checkasm test passes on x86_64 before pushing, of course [17:26:35 CEST] <jamrial> michaelni: patch on the ml for the netbsd failure [17:27:28 CEST] <durandal_1707> atomnuker: no i dont know [17:28:37 CEST] <atomnuker> well, send me what you have on the bitstream and I'll see what I can figure out [17:32:23 CEST] <durandal_1707> atomnuker: i dont have anything worth posting, i only have .idb file if you interested in whats decompiled and i named few functions because i know what are they doing [17:34:25 CEST] <atomnuker> yep, that'll be alright [17:40:16 CEST] <durandal_1707> atomnuker: for example this doesnt call bitstream functions: https://pastebin.com/Mc3WTsuz [17:41:47 CEST] <durandal_1707> til it uses superframes of 4x256 samples [18:03:03 CEST] <kierank> atomnuker: bulgaria's first communication satellite launches today [18:21:32 CEST] <jamrial> durandal_1707: 04aa09c4bc broke fate-lavf-ffm and fate-lavf-mxf [18:22:25 CEST] <durandal_1707> how so? [18:25:23 CEST] <jamrial> durandal_1707: http://fate.ffmpeg.org/report.cgi?time=20170623145756&slot=x86_64-mingw-w64… [18:25:24 CEST] <jamrial> durandal_1707: https://pastebin.com/qZM8XPbH [18:25:31 CEST] <jamrial> one byte changes [18:27:15 CEST] <atomnuker> kierank: oh yeah, forgot about that, they delayed it a bunch of times last week [18:27:17 CEST] <jamrial> at least in the mxf test. didn't check what changed in the ffm one [18:38:20 CEST] <iive> spacex launch? [19:01:40 CEST] <aasif> Hello, everyone. I'd like to learn about FFmpeg and its documentation. I tried diving in the huge codebase first. But it's too technical. I would highly appreciate any advice. Thanks. :) [19:04:54 CEST] <durandal_1707> aasif: what you know? [19:06:29 CEST] <aasif> durandal_1707: Actually to be honest, I don't know anything. I studied the FFmpeg command line's basic uses. I studied the portion about filtergraphs. That's mostly all. [19:07:23 CEST] <atomnuker> what would you like to know about? [19:12:11 CEST] <aasif> atomnuker: I'd like to learn about the documentation. The basic code flow. which modules affect while modules. I'm new to open source development. Me being a noob, would apprecite some help on where to get started in understanding the codebase for the whole software. Should I try learning the whole functionality of the software first, and the theory behind it and then look into code? And if so, what's the place to learn theory about FFmpeg? (By theor [19:12:11 CEST] <aasif> y, I mean basic structure of it all.) [19:12:39 CEST] <aasif> *which modules affect which modules. [19:18:46 CEST] <durandal_1707> aasif: i you want to do programming you need to learnt it first. and also read ffmpeg manuals [19:21:04 CEST] <aasif> durandal_1707: thanks. I'll try to learn the functioning of ffmpeg from the manuals first and then move on to the codebase i guess. [19:36:12 CEST] <Compn> aasif : the code flow is basically the 4 main libraries [19:36:46 CEST] <Compn> er more than 4 now [19:39:29 CEST] <aasif> Compn: libavutil, libavformat, libswresample, libavcodec, libavfilter, libavdevice, libavswscale? [19:40:38 CEST] <Compn> yea [19:40:44 CEST] <Compn> format, util and codec are the main ones [19:40:46 CEST] <Compn> swscale too [19:42:08 CEST] <Compn> those are what enable people to decode/encode video [19:42:17 CEST] <Compn> well video files [19:42:45 CEST] <Compn> then ffmpeg.c is what uses those libs to encode, thread, filter, display, stream, etc [19:46:22 CEST] <aasif> Compn: okay. thanks. how should i proceed on learning more about these files? like what methods do they use to encode and decode? also, a quick question, how does any program run as a command line utility? which function or specifically which file handles the input that goes into the command line as the user puts it? (this is a very basic question. but i'm a noob. i couldn't figure it out myself.) [19:48:42 CEST] <aasif> Compn: in case of ffmpeg, which file has the responsibility to take in the input "ffmpeg -i ... " [19:49:09 CEST] <atomnuker> ubitux: a zombie just appeared on the ML! [19:49:27 CEST] <Compn> right [19:50:32 CEST] <Compn> aasif : there is some developer documentation on the site that explains the various api calls [19:51:02 CEST] <Compn> aasif : http://ffmpeg.org/documentation.html [19:51:18 CEST] <ubitux> atomnuker: oh [19:51:45 CEST] <Compn> aasif : e.g. how to decode a file, http://ffmpeg.org/doxygen/trunk/group__lavc__decoding.html [19:52:00 CEST] <Compn> aasif : its quite complicated process haha :) [19:52:41 CEST] <aasif> Compn: thanks. :D okay. i'll try to learn it somehow. :) [19:52:42 CEST] <ubitux> atomnuker: i'm not it's a good idea to define _GNU_SOURCE globally [19:53:09 CEST] <ubitux> (as it impacts various functions) [19:53:24 CEST] <ubitux> you generally want it locally to the function usage [19:53:35 CEST] <atomnuker> I tried to do it there, but the damn thing doesn't work [19:53:46 CEST] <atomnuker> even when I do it right at the top [19:53:58 CEST] <ubitux> i'd say you have to move ff_thread_setname() in a dedicated .c [19:54:04 CEST] <ubitux> where you define _GNU_SOURCE on top [20:01:10 CEST] <wm4> in certain situations using _GNU_SOURCE will break ffmpeg's code [20:01:24 CEST] <wm4> at least in libavutil/error.c [20:04:03 CEST] <atomnuker> we define it there actually [20:04:10 CEST] <atomnuker> as well as in libavutil/cpu.c [20:04:39 CEST] <wm4> #undef _GNU_SOURCE [20:04:43 CEST] <wm4> are you sure about that [20:04:50 CEST] <wm4> this is the first non-whitespace line in error.c [20:04:53 CEST] <atomnuker> hm, maybe it would work if the functions themselves were compiled and exposed rather than inlined [20:05:05 CEST] <atomnuker> oh, I didn't notice it was undef [20:05:31 CEST] <wm4> you should put this ff_... thing into its own source file, where it calls the pthread function [20:05:59 CEST] <wm4> either that, or configure checks that it's somehow available by default and that's it [20:07:06 CEST] <atomnuker> yep, I'll make thread.c and put stuff there, thread.h can serve as a header file interface for those [20:55:37 CEST] <iive> SpaceX 14 minutes to launch. [20:56:23 CEST] <durandal_1707> iive: since when you care about that ? [20:56:50 CEST] <iive> durandal_1707: I always have, I just had no idea people here do. [20:58:39 CEST] <BBB> atomnuker: s/ff/avpriv/? [20:58:44 CEST] <BBB> atomnuker: since its shared between libraries [21:36:09 CEST] <atomnuker> "implicit declaration of function 'pthread_setname_np' is invalid in C99" [21:36:15 CEST] <atomnuker> how is it implicit [21:36:43 CEST] <atomnuker> the program literaly defines _GNU_SOURCE, includes pthreads and has a wrapper function to call the damn thing [21:36:52 CEST] <atomnuker> nothing else, nothing else included or anything [21:37:18 CEST] <atomnuker> probably some evil cflags [21:37:28 CEST] <atomnuker> can't do anthing about that [21:38:06 CEST] <atomnuker> except try to undef them [21:38:53 CEST] <atomnuker> haha, it works [21:40:43 CEST] <atomnuker> actually nevermind, does clang really not define __GLIBC__ [21:41:19 CEST] <iive> does it compile using glibc? [21:41:48 CEST] <atomnuker> why wouldn't it? [21:46:50 CEST] <iive> because it is gnu? does bsd/osx use glibc? [21:47:00 CEST] <durandal_1707> no [21:51:24 CEST] <rcombs> atomnuker: __GLIBC__ is defined by glibc itself, not by the compiler [21:51:56 CEST] <iive> btw, satelite successfully deployed. first stage also landed safely. [21:52:09 CEST] <rcombs> spent most of the crush core, apparently came in pretty hot [21:54:34 CEST] <atomnuker> screw it, I'm using prctl [22:00:16 CEST] <atomnuker> k, posted a new version of the patch [22:00:57 CEST] <BBB> lavu: add ff_pthread_setname() <- title still says ff [22:01:01 CEST] <BBB> (I know patch does avpriv now) [22:02:05 CEST] <ubitux> atomnuker: why is ptrctl code under HAVE_PTHREAD_SETNAME_NP? [22:02:35 CEST] <atomnuker> granted, technically on linux that will always be defined [22:02:52 CEST] <atomnuker> but its there also to serve as a comment since its only needed for pthread name setting [22:02:54 CEST] <ubitux> always "since Linux 2.6.9" [22:03:08 CEST] <atomnuker> that's like, 30 year old linux version, right? [22:03:22 CEST] <ubitux> i'd say more like 7-8? [22:03:32 CEST] <ubitux> but sure, that should be fine :) [22:13:24 CEST] <atomnuker> someone pl0x lgtm my fft15 asm patch, its been reviewed by 2 elder gods already [22:13:43 CEST] <durandal_1707> just push [22:25:41 CEST] <atomnuker> michaelni: what does make DBG=1 say? [22:26:21 CEST] <Gramner> atomnuker: use 4-arg vinsertf128. should hopefully fix it [22:28:24 CEST] <iive> michaelni: DBG=1 is make variable, it compiles the assembler manually in 2 stages, the first one runs just pre-processor to expand the macros (and strip debug info). [22:29:18 CEST] <Gramner> having dst implicitly being equal to src1 in vex instructions is an assembler feature. it has bugs with older nasm versions with some instructions [22:29:35 CEST] <Gramner> maybe yasm is affected too, I don't remember [22:30:31 CEST] <iive> so increase the minimum required nasm version? [22:31:05 CEST] <Compn> did we drop yasm then? [22:31:12 CEST] <Compn> we might want to make a news release on this ... [22:31:22 CEST] <Compn> news entry and maybe twitter/facebook [22:31:25 CEST] <Gramner> no, both should be supported afaik [22:31:26 CEST] <Compn> if lou is around [22:31:36 CEST] <Gramner> default was changed to nasm [22:32:19 CEST] <Compn> right, but iirc yasm died as well ? [22:32:30 CEST] <Compn> i mean the yasm project itself haha [22:32:35 CEST] <Compn> nevermind [22:32:36 CEST] Action: Compn runs [22:33:00 CEST] <Gramner> yeah, it doesn't get new features so it lacks support for things like avx-512 [22:33:45 CEST] <michaelni> atomnuker, make V=1 says: nasm -f elf64 -g -F dwarf -I./ -I.// -Ilibavcodec/x86/ -Pconfig.asm -MD libavcodec/x86/mdct15.d -o libavcodec/x86/mdct15.o libavcodec/x86/mdct15.asm [22:33:45 CEST] <michaelni> libavcodec/x86/mdct15.asm:116: error: invalid combination of opcode and operands [22:34:36 CEST] <iive> DBG is specific for yasm/nasm compilation. [22:35:04 CEST] <michaelni> DBG=1 does nothing, make DBG=1 shows nothing diferent from no DBG=1 [22:35:07 CEST] <ubitux> damn, wasn't the multiple pgs subtitles issue fixed long ago? [22:35:17 CEST] <ubitux> it looks all broken with several files i have here [22:35:20 CEST] <ubitux> it's really annoying :( [22:35:44 CEST] <Gramner> related nasm commit http://repo.or.cz/nasm.git/commit/ae707bace4406788714597ec5b4f1a427c9ad9c7 so contracted 3-arg vinsertf128 breaks in nasm versions older than 2.13 [22:36:06 CEST] <michaelni> ubitux, i dont remember but add fate tests, more tests make regressions less likely [22:36:49 CEST] <ubitux> dunno if it's a regression [22:38:00 CEST] <atomnuker> michaelni: does changing line 66 in libavcodec/x86/mdct15.asm to "vinsertf128 m%3, m%3, xm3, 1" fix this? [22:49:37 CEST] <iive> michaelni: the code for DBG handling is the first few lines in ffmpeg/ffbuild/common.mak [22:50:10 CEST] <iive> there's been a merge that touches it, but I can't see anything wrong with the new version. [22:52:44 CEST] <jamrial> that is meant for .dbg.asm targets, not .o targets [22:53:21 CEST] <jamrial> it creates pre processed .asm files that can then be assembled to get more readable errors [22:55:51 CEST] <cone-545> ffmpeg 03James Almer 07master:f66086adac5e: configure: fix assignment of assembler specific flags [23:00:19 CEST] <michaelni> atomnuker, yes but it fails on x86-32: src/libavcodec/x86/mdct15.asm:116: error: symbol `xmmm8' undefined [23:01:19 CEST] <durandal_1707> we should drop x86-32 support [23:02:56 CEST] <atomnuker> jamrial: what's the best way of ifdeffing the asm code for 32 bit systems? [23:03:06 CEST] <jamrial> atomnuker: just wrap the whole asm function in a %if ARCH_X86_64 check [23:03:08 CEST] <michaelni> libavcodec/x86/mdct15.dbg.asm:27: error: symbol `xmmm8' undefined [23:03:31 CEST] <atomnuker> jamrial: wouldn't that result in a compilation error, or do you mean inside the cglobal declaration? [23:04:37 CEST] <jamrial> atomnuker: wrapping everything below the include line should be good [23:08:24 CEST] <Compn> durandal_1707 : still a few billion computers running that :P [23:08:30 CEST] <Compn> maybe [23:08:55 CEST] <durandal_1707> Compn: yes, spam farms [23:09:45 CEST] <DHE> or just stop offering updated asm for 32 bit mode? [23:09:55 CEST] <atomnuker> jamrial: ah, because of DCE in the init function, got it [23:11:32 CEST] <jamrial> atomnuker: yeah, the init is DCE'd away in the .c file, and the .asm file doesn't assemble anything after you wrap things in a check for x86_64 [23:12:35 CEST] <Compn> DHE : split 32bit and 64bit asm ? i dont think too much x86 asm is being written now anyway [23:12:43 CEST] <Compn> unless thats what atomnuker was doing :D [23:13:46 CEST] <durandal_1707> Compn: never reveal your weakness [23:14:34 CEST] Action: Compn runs [23:14:45 CEST] <atomnuker> michaelni: sent a new patch to fix this [23:14:49 CEST] <DHE> Compn: on a personal note dropping 32 bit support seems a bit much, but I also agree that no half-modern system should be running 32 bit hardware or operating systems anymore... [23:14:58 CEST] <durandal_1707> Compn: why you have supreme powers at all... [23:16:15 CEST] <atomnuker> if we drop 32 bit support we'd never see the work and lengths people went to make do with barely 7 usable registers [23:16:32 CEST] Action: Compn stuffs durandal_1707 into 7 regs [23:17:07 CEST] <durandal_1707> that reminds me, when will be next irc supreme meeting? [23:17:07 CEST] <DHE> even Atom CPUs have been available in 64 bit variants since 2011 (I have one) [23:17:23 CEST] <atomnuker> (though yeah, the majority of 32 bit users are all on non-x86 platforms) [23:17:51 CEST] <iive> you mean arm phones? [23:18:33 CEST] <Compn> durandal_1707 : i cant remember who calls those to order. maybe ubitux ? [23:19:09 CEST] <durandal_1707> Compn: i call for it! [23:19:25 CEST] <Compn> post to -devel with a proposed date/time ? [23:20:01 CEST] <jamrial> why would there be one right now? [23:20:24 CEST] <Compn> e.g. what topic would durandal_1707 want to discuss ? [23:20:26 CEST] <durandal_1707> first need to find out if anybody will come [23:20:37 CEST] <Compn> durandal_1707 : are you coming to VDD this year ? [23:21:07 CEST] <jamrial> unless there are several subjects to discuss about, please don't try to call a meeting [23:21:24 CEST] <durandal_1707> Compn: proposig new security officers and new irc admins [23:21:58 CEST] <jamrial> that sounds more like a vote, and we added new people to sec a few months ago [23:22:13 CEST] <Compn> oh you mean why am i founder of this channel ehhe [23:23:28 CEST] <Compn> possibly because i dont mess with the channel at all [23:23:33 CEST] <durandal_1707> 32tb of win code leaked [23:23:45 CEST] <Compn> durandal_1707 : who are you proposing to be irc admin? [23:23:50 CEST] <Compn> if you have any suggestions [23:25:17 CEST] <Compn> durandal_1707 : VDD dates for paris,france this year > 22-24 Sept. [23:25:17 CEST] <durandal_1707> Compn: only me, ubitux and michaelni [23:26:00 CEST] <Compn> i have no objection... [23:26:02 CEST] <durandal_1707> VDD is irrelevant [23:26:13 CEST] <Compn> yes is unrelated, just letting you know [23:27:14 CEST] <Compn> durandal_1707 : if you think i've done something wrong in irc, you can tell me. [23:27:26 CEST] <atomnuker> durandal_1707: holy shit [23:27:27 CEST] <Compn> or even ban me, i wont ban evade... [23:27:52 CEST] <Compn> atomnuker : are you coming to vdd ? [23:28:19 CEST] <durandal_1707> Compn: nooo, you are only remaining legacy left [23:28:28 CEST] <Compn> oh its windows 10 : [23:28:53 CEST] <atomnuker> Compn: I'm giving another talk there, so yeah [23:29:21 CEST] <durandal_1707> about what? [23:31:53 CEST] <atomnuker> opus [23:34:37 CEST] <BBB> not av1? [23:34:42 CEST] <BBB> then who will talk about av1? [23:34:50 CEST] <atomnuker> oh crap [23:35:08 CEST] <BBB> :D [23:35:34 CEST] <atomnuker> erm, derf's hopefully going there, he needs like an hour to write slides and prepare [23:35:55 CEST] <durandal_1707> i will talk about lavfi filters, decoders, encoders, reing ... [23:36:05 CEST] <atomnuker> (though it'll be recycled and somewhat cynical) [23:36:13 CEST] <atomnuker> durandal_1707: do it, I'd listen [23:37:02 CEST] <durandal_1707> and nobody else... [23:37:49 CEST] <durandal_1707> seriously, devs just do wxwidgets stuff [23:38:45 CEST] <atomnuker> durandal_1707: not at VDD [23:40:10 CEST] <Compn> durandal_1707 : i'd listen to re stuff for sure :) [23:40:57 CEST] <BBB> atomnuker: & h& m & m &. m. &.. .. .. I dont know [23:40:59 CEST] <durandal_1707> why? its complex and daunting [23:41:24 CEST] <BBB> atomnuker: can monty make his slides and add some graphics/schematics/etc.? like the daala blogs [23:42:34 CEST] <atomnuker> BBB: AFAIK xiphmont hates going anywhere, though who knows, go ahead and ask him [23:46:53 CEST] <durandal_1707> we should organize FFDD [23:50:50 CEST] <atomnuker> michaelni: does the latest patch fix x86_32 builds? [00:00:00 CEST] --- Sat Jun 24 2017

1 0

ffmpeg.log.20170623
by burek 24 Jun '17

24 Jun '17

[00:00:08 CEST] <bitmod> anyone here? [00:00:11 CEST] <c_14> no [00:00:54 CEST] <bitmod> sweet, i'm just wondering if it's possible to create gif frames (also in GIF format) using ffmpeg? [00:01:04 CEST] <bitmod> with text [00:01:04 CEST] <c_14> just use gif as output? [00:01:22 CEST] <bitmod> c_14: er what do you mean? [00:01:30 CEST] <c_14> ffmpeg <blah> out.gif [00:02:20 CEST] <bitmod> c_14: i need to create the gif frames first, e.g. https://paste.ubuntu.com/24927705/ [00:02:41 CEST] <bitmod> so i need to run that command 100 times (varying the text input) [00:04:36 CEST] <furq> why not just make a subtitle file and use -vf subtitle [00:04:41 CEST] <furq> or subtitles [00:04:48 CEST] <c_14> ^ [00:05:05 CEST] <c_14> or output all the frames individually to something lossless (png) and then use image2 input to make the gif [00:05:13 CEST] <furq> yeah [00:06:02 CEST] <bitmod> c_14: oh that sounds like it could work, what's the image2 command to take a bunch of PNGs and convert to a gif? [00:06:04 CEST] <c_14> I can also think of a really terrible way if you like race conditions [00:06:20 CEST] <c_14> ffmpeg -f image2 -i img%04d.png [00:07:26 CEST] <c_14> the name is obviously to your discretion, it accepts scanf sequences or with -pattern_type glob '*' globs (and maybe '?'?) [00:07:57 CEST] <bitmod> c_14: hmm should "ffmpeg image2 -i ./frames/*.png" work? [00:08:06 CEST] <c_14> with -pattern_type glob yes [00:08:24 CEST] <c_14> as long as you make sure your shell doesn't expand the * [00:10:18 CEST] <bitmod> c_14: that converts all pngs to out.gif? [00:10:51 CEST] <c_14> yeah [00:11:01 CEST] <c_14> you might need to fiddle with the -framerate input option [00:11:21 CEST] <bitmod> c_14: i get this error when i run that command "ffmpeg -f image2 -i frames/*.png -pattern_type glob" -> http://sprunge.us/PPeL [00:11:31 CEST] <zerodefect> Question about progressive scan to interlaced conversion. I've been looking at the source for the 'interlace' filter. Admittedly, I don't really understand the code, but one thing I found interesting is that the pixel samples look to be run through a low-pass filter during the conversion process. Is somebody able to explain why the filter is needed? [00:11:32 CEST] <c_14> pattern_type goes before -i [00:11:51 CEST] <c_14> and it looks like your shell is expanding the * [00:11:54 CEST] <c_14> surround the filename with '' [00:14:00 CEST] <bitmod> c_14: damn that's fast xP [00:14:11 CEST] <bitmod> awesome man, that's helped me so much, you've got no idea [00:14:41 CEST] <bitmod> i've spent the whole day trying to optimize this process, and ffmpeg makes it easy [00:15:36 CEST] <bitmod> c_14: is there an automatic overwrite too? [00:15:42 CEST] <c_14> -y [00:15:48 CEST] <bitmod> thanks! [00:22:49 CEST] <bitmod> c_14: hmm, is there anyway to retain the quality of bit more? [00:22:57 CEST] <c_14> from png to gif? [00:23:02 CEST] <bitmod> c_14: yeah [00:23:16 CEST] <c_14> you can use the palettegen/paletteuse filters [00:23:53 CEST] <bitmod> i shoul've been a little clearer about my usecase, my images only have 2 colors, the background, and the text color, but they need to be rgb [00:23:59 CEST] <bitmod> is that doable? [00:24:46 CEST] <c_14> palettegen/paletteuse might help. Though the default palette should have both black and white so I don't really see how [00:25:41 CEST] <bitmod> c_14: sorry, i meant to say they only need 2 colors (i.e. they can be customized with at most two colors) [00:27:45 CEST] <c_14> yeah, I mean normally you'd use gray8 or monochrome for that but since you need rgb there's not much you can do [00:28:42 CEST] <c_14> the quality for that shouldn't be terrible though? [00:28:55 CEST] <c_14> since the main quality problems with gif are the limited palette [00:29:06 CEST] <c_14> what do you mean retain the quality? [00:30:34 CEST] <bitmod> c_14: https://imgur.com/a/MGMZd [00:31:19 CEST] <c_14> you mean the blur around the characters? [00:31:29 CEST] <bitmod> c_14: yup [00:31:34 CEST] <furq> you'll want to use paletteuse/palettegen and probably play around with the dithering options [00:31:36 CEST] <c_14> those aren't present in the gif? [00:31:49 CEST] <c_14> yeah [00:31:53 CEST] <iive> it' better to remove dither [00:31:56 CEST] <c_14> since there are transitions between colors there [00:32:15 CEST] <iive> because it makes compression worse [00:32:25 CEST] <furq> paletteuse will use dither by default [00:32:40 CEST] <iive> it shouldn't [00:32:47 CEST] <furq> !filter paletteuse [00:32:48 CEST] <nfobot> furq: http://ffmpeg.org/ffmpeg-filters.html#paletteuse [00:32:55 CEST] <furq> looks like it does to me [00:33:10 CEST] <bitmod> that's a single frame: https://imgur.com/a/LlxyX [00:33:18 CEST] <bitmod> if i could retain that quality that would be ideal [00:34:03 CEST] <furq> as we both said, use palettegen [00:34:14 CEST] <furq> it'll use the default 256-colour palette otherwise [00:34:25 CEST] <furq> which is obviously no good if you only have a bunch of similar shades of blue [00:35:18 CEST] <bitmod> what is the .mkv file? [00:35:41 CEST] <furq> that's whatever your input is [00:35:59 CEST] <furq> you create a palette from your input with palettegen, then use your input and the generated palette with paletteuse [00:37:51 CEST] <bitmod> ah ok, nice [00:38:14 CEST] <bitmod> how would i incorporate the paletteuse into my current ffmpeg command -> " 1 ffmpeg -f image2 -pattern_type glob -y -i 'frames/*.png' movie.gif"? [00:38:47 CEST] <bitmod> would i just add "-i palette.png -lavfi paletteuse output.gif" to the end? [00:38:56 CEST] <furq> you need to run two commands [00:39:58 CEST] <bitmod> my one first, then the paletteuse command? [00:40:12 CEST] <furq> http://vpaste.net/rYpGx [00:40:13 CEST] <furq> like that [00:40:27 CEST] <furq> with filter options to taste [00:43:33 CEST] <bitmod> furq: damn, too slow i think [00:43:45 CEST] <bitmod> 0.87s [00:47:47 CEST] <furq> oh i'm dumb [00:48:08 CEST] <furq> http://vpaste.net/zn7gs [00:50:02 CEST] <bitmod> furq: ah much quicker, awesome [00:50:09 CEST] <bitmod> really appreciate the help btw [00:50:17 CEST] <bitmod> you too c_14 [00:53:04 CEST] <bitmod> guys also another question, would this process be faster if i had a better cpu? [00:53:25 CEST] <c_14> I'd guess you're probably io-bound [00:53:28 CEST] <c_14> check top/htop or something [00:53:52 CEST] <c_14> I don't think it'd benefit from multi-threading though [00:54:05 CEST] <c_14> the gif encoder is single-threaded [00:54:23 CEST] <bitmod> c_14: ah right [00:54:46 CEST] <bitmod> are there any hardware-side upgrades i could do to make the process faster? [00:55:28 CEST] <c_14> if it really is io-bound, just shoving the images into a ramfs (tmpfs) will help [00:55:52 CEST] <c_14> other than that [00:55:58 CEST] <c_14> write raw bmp or something instead of png [00:57:47 CEST] <bitmod> c_14: wow i just realized my file is only 3kB [00:57:52 CEST] <c_14> or raw tiff I guess [00:58:43 CEST] <bitmod> not sure if i'm a good enough programmer for that (writing raw tiffs) [00:58:56 CEST] <c_14> ffmpeg can output that instead of png [00:59:26 CEST] <c_14> ffmpeg <args> -compression_algo raw out.tiff [00:59:38 CEST] <bitmod> would it be faster to generate than my current c++ code? (0.27s) [01:00:08 CEST] <c_14> hmm? [01:00:42 CEST] <c_14> didn't you generate the png's for the input to the gif generation with ffmpeg? [01:00:53 CEST] <bitmod> c_14: at the moment i'm using cairo to generate the 120 PNGs, and it takes 0.27s [01:01:08 CEST] <bitmod> c_14: yeah exactly, i thought you meant use ffmpeg to generate tiffs instead of pngs [01:02:24 CEST] <c_14> I have no idea if it'd be faster or not, I've never benchmarked it [01:02:28 CEST] <c_14> but zlib is pretty slow [01:03:22 CEST] <bitmod> c_14: what uses zlib? [01:03:26 CEST] <furq> png [01:03:34 CEST] <bitmod> ah ok [01:03:43 CEST] <c_14> though I believe you can write uncompressed png [01:03:58 CEST] <c_14> not sure what cairo does [01:04:15 CEST] <furq> pretty sure cairo will output bmp [01:04:44 CEST] <furq> i assume you could just have your code write frames to stdout and pipe them into ffmpeg [01:04:47 CEST] <furq> that should save some time [01:04:58 CEST] <bitmod> the thing is, i wanted to use this library (https://www.lcdf.org/gifsicle/) to create my gifs, as it is extremely fast, but in order to use it i need my frames to be .gifs, which cairo can't do. If i could output .gif frames and then use gifsicle, i think i could reduce total time < 0.5s [01:05:28 CEST] <bitmod> furq: oh is that a possiblity? [01:05:28 CEST] <bitmod> didn't think about that [01:05:46 CEST] <c_14> yeah, just use -f image2pipe -i pipe:0 [01:06:24 CEST] <thebombzen> bitmod: you can also just write GIFs in the gif format (rather than as frames) with FFmpeg, and then batch optimize them. Say, with gifsicle you could do gifsicle --batch --unoptimize --optimize=3 file.gif [01:06:36 CEST] <thebombzen> or gifsicle -U -O3 -b file.gif, or as a pipe, gifsicle -U -O3 [01:06:39 CEST] <furq> that seems like it'd be much slower [01:06:57 CEST] <furq> and also probably lower quality [01:07:18 CEST] <thebombzen> if you output invidivdual GIF frames and put them together the file size will be enormous and it will also probably be slower [01:07:20 CEST] <furq> you'd need to palettegen each gif frame you write with ffmpeg anyway [01:07:30 CEST] <furq> or paletteuse rather [01:07:37 CEST] <furq> since they'll all use the same palette [01:07:53 CEST] <thebombzen> it seems better to just write the GIF images inside the GIF format as an animation, and optimize with gifsicle [01:08:09 CEST] <durandal_1707> there is option to change palletes [01:08:34 CEST] <furq> thebombzen: better than what [01:08:41 CEST] <furq> i feel like you're comparing this with something that isn't happening [01:09:02 CEST] <thebombzen> individual frames [01:09:12 CEST] <thebombzen> better than individual frames [01:09:21 CEST] <furq> could you be less specific [01:09:28 CEST] <thebombzen> ? [01:09:43 CEST] <bitmod> honestly i don't know how they do it, but converting 120 .gif frames (non-animated) into an animated gif takes a total of 0.06s using gifsicle [01:10:04 CEST] <bitmod> and good quality too [01:10:23 CEST] <c_14> I'm pretty sure you can just concat gifs pretty easily [01:10:37 CEST] <c_14> as long as they're not recoding the stream it'll be as fast as io [01:10:45 CEST] <furq> gifsicle is good but you have no good method of outputting the source frames for it to use [01:11:15 CEST] <durandal_1707> bitmod: post comparasion [01:13:38 CEST] <bitmod> c_14, furq: yeah the issue is generating the .gifs in the first place [01:13:43 CEST] <thebombzen> bitmod: but the gif file you produce is probably enormous [01:13:57 CEST] <bitmod> durandal_1707: ah ok, i'll have to look that up [01:14:03 CEST] <thebombzen> if you optimize it, it's probably significantly less fast [01:14:48 CEST] <bitmod> thebombzen: yup fair point, it's 400kb (200 or 300kb too big) [01:14:56 CEST] <furq> bitmod: like i said, pipe bmp frames to stdout and into ffmpeg [01:15:00 CEST] <furq> if that's still too slow then shrug [01:15:01 CEST] <bitmod> this is what i'm going for btw https://imgur.com/a/QQkzH [01:15:28 CEST] <bitmod> furq: ok, i'll give that a shot [01:15:42 CEST] <furq> you might also want to consider generating the frames with ffmpeg [01:15:47 CEST] <furq> not sure if that'll be quick or easy though [01:16:11 CEST] <c_14> I doubt it'd be faster since you'd have to go through process initialization for every frame [01:16:13 CEST] <bitmod> that gif above is 120kB, and loads (including the whole generation process) in about 600 milliseconds [01:16:39 CEST] <furq> well you could presumably just generate subtitles [01:16:43 CEST] <bitmod> is there no way to create 100 gifs in parallel? [01:16:58 CEST] <c_14> fork 100 processes/threads [01:17:59 CEST] <c_14> probably won't be faster since you'll just blow up your load though [01:18:06 CEST] <c_14> a thread-pool would be more effective [01:18:17 CEST] <bitmod> hmm what about with a language like elixir? i know it's not the fastest, but maybe that would work [01:18:23 CEST] <furq> huh [01:20:34 CEST] <jasonfloyd> Hi there! I'm trying a very simple mp4 to mxf conversion, and receiving errors. Command line: "ffmpeg -i ${input_file} -c:v copy -an -f mxf output.mxf", error: "[mxf @ 0x284ba40] AVC Intra 50/100 supported only [mxf @ 0x284ba40] could not get h264 profile av_interleaved_write_frame(): Operation not permitted" - any idea? [01:22:16 CEST] <c_14> you probably need to reencode the video [01:22:41 CEST] <jasonfloyd> I've tried using -c:v libx264 instead of copy, same issue. [01:23:11 CEST] <jasonfloyd> Multiple mp4 inputs, all give the same error. [01:23:40 CEST] <c_14> you probably need 10-bit x264 [01:23:54 CEST] <c_14> though I'm not sure why it wants avc-intra [01:24:29 CEST] <jasonfloyd> Any pointers to 10-bit x264 info? [01:24:58 CEST] <c_14> either download https://www.johnvansickle.com/ffmpeg/ or build it yourself [01:25:13 CEST] <c_14> though according to the code it should take AVC Baseline as well and AVC High 422 Intra [01:25:18 CEST] <c_14> maybe try setting -profile:v high ? [01:25:31 CEST] <jasonfloyd> I'm building x264 and ffmpeg myself, is it just a config option for x264? [01:25:35 CEST] <c_14> yeah [01:25:38 CEST] <c_14> --enable-10bit [01:25:40 CEST] <c_14> afaik [01:25:52 CEST] <c_14> eh [01:25:55 CEST] <c_14> --bit-depth=10 [01:25:56 CEST] <bitmod> c_14: what about using graphicsmagick convert? could that be fast? [01:26:01 CEST] <c_14> couldn't have been more wrong [01:26:13 CEST] <c_14> bitmod: maybe, never really used it [01:26:35 CEST] <furq> it's pretty rare that imagemagick is the right answer [01:26:35 CEST] <bitmod> c_14: i put this code into a loop of n=120 (gm convert -size 380x100 xc:white -font Noto-Serif -pointsize 64 -fill blue -draw "text 25,65 [01:26:38 CEST] <jasonfloyd> -profile: v high - same issue. [01:26:46 CEST] <bitmod> '03:12:47:5$i'" ./frames/frame$i.gif) [01:26:54 CEST] <bitmod> woops that's a bit long [01:26:56 CEST] <bitmod> one sec [01:27:05 CEST] <c_14> jasonfloyd: what about baseline? [01:27:40 CEST] <bitmod> here we go: https://paste.ubuntu.com/24928681/ [01:27:49 CEST] <jasonfloyd> also same with baseline. [01:27:58 CEST] <bitmod> but it takes 1.6s to generate those, which is slower than my python code (0.7s) [01:28:08 CEST] <jasonfloyd> trying to rebuild with 10bit x264 [01:28:27 CEST] <furq> bitmod: try generating an srt and using the subtitles filter [01:28:42 CEST] <furq> that'll do it without spawning 120 processes [01:29:06 CEST] <c_14> furq: don't think srt will cut it with that styling [01:29:08 CEST] <c_14> he'll need ass [01:29:27 CEST] <bitmod> furq: generate the srt with ffmpeg? [01:29:38 CEST] <furq> it's the same format for every frame so i don't see why not [01:29:50 CEST] <furq> you can use ass styling on srt with the subtitles filter [01:29:57 CEST] <furq> bitmod: with a shell script or python or whatever [01:30:28 CEST] <c_14> hmm, I guess you could use font size tags and 2 lines of text [01:30:33 CEST] <c_14> might even work [01:30:54 CEST] <furq> there's only one line of text in that command he just pasted [01:31:02 CEST] <furq> and one size [01:31:13 CEST] <c_14> he showed this https://imgur.com/a/QQkzH earlier [01:31:15 CEST] <furq> if he wants a copy of that gif from earlier then yeah [01:31:17 CEST] <furq> that's more complicated [01:33:01 CEST] <bitmod> can ffmpeg convert srt to gif? [01:33:16 CEST] <c_14> it can overlay srt onto an input and output as gif [01:33:25 CEST] <c_14> in your case the input would be the color pseudo demuxer [01:33:30 CEST] <furq> yeah you can do this in one command after you generate the srt [01:33:39 CEST] <furq> and it should be very fast [01:33:43 CEST] <c_14> (the color filter in the lavfi pseudo-muxer) [01:34:24 CEST] <furq> -f lavfi -i color=white -vf subtitles=foo.srt,force_style=xxx out.gif [01:34:27 CEST] <furq> something like that [01:34:55 CEST] <furq> !source color @bitmod [01:34:55 CEST] <nfobot> bitmod: http://ffmpeg.org/ffmpeg-filters.html#allrgb_002c-allyuv_002c-color_002c-ha… [01:35:00 CEST] <furq> !filter subtitles @bitmod [01:35:00 CEST] <nfobot> bitmod: http://ffmpeg.org/ffmpeg-filters.html#subtitles-1 [01:36:19 CEST] <bitmod> furq: well, i can generate 120 .srt files in 0.01s, so that's a good start xP [01:36:29 CEST] <c_14> well, you only need 1 [01:36:34 CEST] <furq> you mean one 120-entry srt file, right [01:37:09 CEST] <bitmod> furq: oh, should each unit of text be an a newline? [01:37:42 CEST] <bitmod> thinking about it now that makes more sense [01:38:06 CEST] <c_14> nonce\ntimestamp\ntext [01:38:22 CEST] <c_14> timestamp range even [01:39:03 CEST] <bitmod> c_14: like this right? https://matroska.org/technical/specs/subtitles/srt.html [01:39:14 CEST] <c_14> yeah [01:39:15 CEST] <furq> yeah [01:40:09 CEST] <bitmod> what does 440 represent in "00:02:17,440 --> 00:02:20,375"? (and 375) [01:40:16 CEST] <c_14> milliseconds [01:40:40 CEST] <bitmod> ah ok [01:46:57 CEST] <bitmod> almost there [01:48:26 CEST] <jasonfloyd> 10-bit x264 didn't make any difference when trying to convert to mxf. "[mxf @ 0x284da40] AVC Intra 50/100 supported only [mxf @ 0x284da40] could not get h264 profile av_interleaved_write_frame(): Operation not permitted Error writing trailer of foo.mxf: Unknown error occurred" [01:48:56 CEST] <jasonfloyd> it seems like a pretty straightforward command: ./ffmpeg -i ${input_file} -c:v copy -an -f mxf ${input_file%.*}.mxf [01:49:05 CEST] <jasonfloyd> ffmpeg v3.1.9 [01:56:12 CEST] <bitmod> c_14, furq: ok, i've got my .srt file generator [02:00:23 CEST] <c_14> jasonfloyd: ffmpeg -f lavfi -i testsrc=s=1920x1080 -c:v libx264 -profile:v high10 -pix_fmt yuv420p10le -f mxf out.mxf <- works for me [02:01:29 CEST] <kierenj> hi - I have a complex filter which is 1) taking 5 different-duration input videos, 2) taking segments of each, 3) concatenating some of those segments and 4) overlaying them into a grid... I get a 0 byte output file, lots of CPU, and lots of "Buffer queue overflow, dropping" messages. could anyone take a peek please? - https://pastebin.com/UyMEJhf4 [02:01:34 CEST] <c_14> -profile:v high222 -pix_fmt yuv422p10le works as well [02:02:10 CEST] <c_14> this is one of _those_ filter_complexes isn't it [02:02:28 CEST] <kierenj> might be .. sorry, I'm new to ffmpeg and trying to build a cool timelapse grid array for YT :) [02:05:41 CEST] <bitmod> c_14, how can i convert my srt to a gif? [02:05:42 CEST] <c_14> you might want to use hstack/vstack [02:05:59 CEST] <furq> 00:34:24 ( furq) -f lavfi -i color=white -vf subtitles=foo.srt,force_style=xxx out.gif [02:06:02 CEST] <furq> 00:34:27 ( furq) something like that [02:06:42 CEST] <furq> except that , should be a : [02:06:51 CEST] <c_14> kierenj: and maybe add an explicit output pad and map that? [02:08:11 CEST] <kierenj> humm, same result but htanks c_14. pushed my laptop battery over the edge so I'll be timing out shortly.. eek [02:08:23 CEST] <kierenj> (still spins CPU, lots of messages, no output) [02:08:33 CEST] <c_14> Also, I'd try with a simpler command [02:08:35 CEST] <c_14> to test [02:08:40 CEST] <c_14> it might just be too much at once [02:08:54 CEST] <c_14> like maybe only do the upper left corner of the output you want [02:08:58 CEST] <c_14> and then expand on that [02:09:04 CEST] <kierenj> ok cool, it's configurable, one sec.. if my battery lasts [02:09:47 CEST] <bitmod> furq: wopoos, i think i'm doing something wrong, that command is taking a very long time [02:10:20 CEST] <kierenj> no luck... does "Buffer queue overflow, dropping." indicate an actual problem or just long runtime? [02:11:10 CEST] <bitmod> furq: is this command right? " 1 ffmpeg -f lavfi -i color=white -vf subtitles=frame.srt:force_style=PrimaryColour=255 movie.gif" [02:11:19 CEST] <c_14> I think it means it's dropping frames <- kierenj [02:11:28 CEST] <furq> i don't think that's a valid primarycolour [02:11:31 CEST] <c_14> check the bottom line of the ffmpeg output, there should be dropped= [02:11:32 CEST] <furq> and you probably need to set a font [02:11:57 CEST] <kierenj> it never finishes or outputs a byte, I just have to terminate it [02:12:13 CEST] <c_14> with how many overlays/splits was that? [02:12:19 CEST] <furq> pastebin the srt [02:13:04 CEST] <bitmod> furq: http://sprunge.us/OaNA [02:13:10 CEST] <kierenj> 8 overlays (2x4), down from 49 [02:13:19 CEST] <kierenj> I'll do 2.. [02:13:28 CEST] <c_14> 8 should be fine [02:13:33 CEST] <c_14> do you have a script that generates this? [02:14:10 CEST] <kierenj> little program, yes. no luck with 2 [02:14:18 CEST] <bitmod> c_14: still workin on it, i've never really used shell scripts before so i'm still tweaking it [02:14:38 CEST] <bitmod> c_14: ah wrong person [02:14:55 CEST] <kierenj> revised: https://pastebin.com/JCZaixq3 [02:15:21 CEST] <kierenj> not sure I'm trim/concat/setpts in the right order [02:18:03 CEST] <c_14> it should be fine [02:22:42 CEST] <c_14> and he's gone [02:22:55 CEST] <c_14> and I was just about to tell him that it appears to maybe work here [02:28:06 CEST] <c_14> the other script also works [02:28:17 CEST] <c_14> if by "works" you mean spews errors for ~30s and then triggers an OOM-kill [02:28:35 CEST] <c_14> 47.5 actually [02:30:06 CEST] <c_14> and they're only warnings [02:30:08 CEST] <c_14> harmless, really [05:31:17 CEST] <antiPoP> hi, I want to make a video preview or a video by taking 10 1-second parts and putting them together. Is there any tutorial for that? [06:11:36 CEST] <greatdex> hi [07:02:55 CEST] <LokerPoker> Does ffmpeg offer space for beginners who want to contribute ? [08:55:28 CEST] <Orochimarufan> Is there some way of extracting attachments (fonts) other than -dump_attachment? [09:19:28 CEST] <c_14> with ffmpeg, probably not [10:25:16 CEST] <Diego_> I've used ffmpeg -i 1.webm -i 2.webm -filter_complex "nullsrc=size=640x480 [base]; [0:v] setpts=PTS-STARTPTS, scale=320x240 [upperleft]; [1:v] setpts=PTS-STARTPTS, scale=320x240 [upperright]; [2:v] setpts=PTS-STARTPTS, scale=320x240 [lowerleft]; [base][upperleft] overlay=shortest=1 [tmp1]; [tmp1][upperright] overlay=shortest=1:x=320 [tmp2]; [tmp2][lowerleft] overlay=shortest=1:y=240" -c:a libfdk_aac -c:v libx264 -crf 20 -threads 2 -f m [10:25:57 CEST] <Diego_> to compile 2 webm videos into a mosaic with mp4 re-coding. Both videos have audio and they are working, but after compiling into mosaic I only hear the audio from the first one. Why? [10:27:36 CEST] <Diego_> Sorry, I've used this line, not the one I sent before: ffmpeg -i 1.webm -i 2.webm -filter_complex "nullsrc=size=640x480 [base]; [0:v] setpts=PTS-STARTPTS, scale=320x240 [upperleft]; [1:v] setpts=PTS-STARTPTS, scale=320x240 [upperright]; [base][upperleft] overlay=shortest=1 [tmp1]; [tmp1][upperright] overlay=shortest=1:x=320" -c:a libfdk_aac -c:v libx264 -crf 20 -threads 2 -f mp4 -preset ultrafast output.mp4 [10:43:10 CEST] <durandal_1707> Diego_: because you said so in graph [10:43:46 CEST] <durandal_1707> you need amix to mix audio [11:04:53 CEST] <thebombzen> Diego_: consider using hstack and vstack rather than overlay/pad [11:05:21 CEST] <thebombzen> these stack videos horizontally and vertically, but are much faster with less overhead than overlay/pad [11:17:08 CEST] <Diego_> Are there any tutorial about how using hstack or vstack for a similar purpose? [11:18:17 CEST] <Diego_> thebombzen: And audio + video will be mixed with that or should I need amix as durandal_1707 suggested? [11:18:42 CEST] <thebombzen> hstack and vstack are easy to use, just read the documentation [11:19:00 CEST] <thebombzen> and durandal's advice was to use the amix audio filter [11:19:21 CEST] <thebombzen> you need to use the amix audio filter if you want to mix the audio together [11:20:14 CEST] <Diego_> Okay. I will give it a try. Thanks to both of you :D [13:10:13 CEST] <thebombzen> should we even be getting this error? [null @ 0x55b785680720] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 5 >= 5 [13:10:44 CEST] <thebombzen> I feel like vf_null should not spit out error messages about invalid dts [13:10:59 CEST] <thebombzen> er, not vf_null, I mean the null muxer [13:14:39 CEST] <jkqxz> It's coming from the generic lavf muxer code. If you really wanted it not to appear for the null muxer then you'd need specific hacks there. [13:15:13 CEST] <thebombzen> I guess that makes sense, it just feels awkward that the null muxer is complaining about muxing info [13:15:22 CEST] <thebombzen> for reference: http://sprunge.us/PAEd [13:17:07 CEST] <BtbN> it's not [13:21:31 CEST] <thebombzen> it's not what? [13:28:28 CEST] <Diego_> Hey! I've been testing hstack and vstack for a while. Its working like a charm for my mosaic outputs and you were right thebombzen , its kinda fast. Btw, I must keep "-preset ultrafast" or I will lose too much speed compilation. Now I'm facing 2 new "errors" and I don't know how to handle them properly [13:30:56 CEST] <Diego_> First of all, I'm compiling 2 videos and 2 audios in the same mosaic using "amix", so I don't have to compile both audio and video into a single video before creating the mosaic. Secondly, one of my videos has like 3 secs without a image (probably due to a bug with the recording software), but audio its perfect. If I mix that video and its corresponding audio, I have audio from sec 0 to sec 3, but no video. Thats right, because the vid [13:32:23 CEST] <Diego_> the problem is that when I mount the mosaic that video does not start showing empty screen for 3 secs, instead starts at 0:00 with the first available frame and it creates a delay between image and audio. I've been looking for "setpts" options, but I can't find a solution with that filter to make it work properly [13:32:26 CEST] <Diego_> any suggestion? [13:35:02 CEST] <Diego_> I don't know if it was clear enough :/ [13:39:21 CEST] <thebombzen> Diego_: try adding setpts=PTS+3/TB [13:39:41 CEST] <thebombzen> it's a video filter that increases the timestamps by 3 seconds [13:53:18 CEST] <Diego_> thebombzen: When I compile both videos, I get this error spammed like hell: https://pastebin.com/SmnZSWsj I suspect that its because those empty frames. There is no option to allow inserting videos even with empty frames instead to get first frame? [13:53:34 CEST] <Diego_> thebombzen: aw! sorry. Didnt see your filter option, I will test it now [13:59:41 CEST] <Diego_> thebombzen: Nope, its not working :( with that option I get both videos freezed, but audio still out of sync. Without setting the PTS filter, I get both videos freezed for those seconds, then they start to play and audio is sync, but I don't want videos to get freezed. I want them sync and if they have empty frames, to keep empty frames [14:00:10 CEST] <thebombzen> You could also try using a source and the concat filter [14:02:07 CEST] <thebombzen> for example, in your complex filter, you can use color=c=black:s=1280x720:d=3:r=24 to generate 3 seconds of all black 1280x720 video at 24 fps [14:02:23 CEST] <thebombzen> then you could concat that with the video stream that's 3 seconds off with the concat filter [14:05:06 CEST] <Diego_> Okay. I will give it a try. I was thinking about that, but didn't knew how to implement :P I'm still pretty new with this. Furthermore, I have to make this as automatic process in PHP no matter how many videos should be compiled. Funny times are comming... [14:05:26 CEST] <thebombzen> PHP? :( [14:05:32 CEST] <thebombzen> I recommend something else [14:05:45 CEST] <Diego_> I'm working with laravel (Symfony) [14:05:57 CEST] <thebombzen> you should avoid PHP [14:06:16 CEST] <Diego_> Why should I? [14:06:16 CEST] <thebombzen> if something wants to you use it, then don't use that either [14:06:32 CEST] <thebombzen> PHP is a terrible stain upon this earth whose blight rots good software everywhere [14:07:44 CEST] <Diego_> I used to be a Java dev... but Java, lacks in hardware efectiveness and usage for web, even with new versions [14:07:59 CEST] <Diego_> It consumes like hell [14:08:15 CEST] <JEEB> I'd rather focus on the issue than the implementation [14:08:21 CEST] <JEEB> or well, the language [14:08:53 CEST] <Diego_> And I also hated PHP, but well... I need to focus on something and when I started to work in this company, they were working in Symfony, so... I had to adapt [14:08:56 CEST] <thebombzen> Java is not designed to be used for the web or as a server langauge. It's the wrong tool for that (even though you can) [14:09:08 CEST] <JEEB> what [14:09:17 CEST] <JEEB> at this point JVM is one of the best VMs around [14:09:28 CEST] <JEEB> but OK, I'm not going to go there [14:09:45 CEST] <Diego_> but its hardware usage still being huge for a production server if you just need a simple APP [14:09:46 CEST] <thebombzen> yea, Java is the wrong tool for many things and that's its biggest problem, people don't know when not to use it [14:10:15 CEST] <thebombzen> I am quite familiar with Java's language and it's really not amazing. But it's not PHP-bad [14:10:44 CEST] <Diego_> well, I will give a try to black screen [14:10:48 CEST] <Diego_> and lets see what happens [14:13:28 CEST] <Diego_> Before doing something... I'm thinking what if I get empty frames from 00:00:30 to 00:00:35? [14:13:57 CEST] <Diego_> I can't concat that (in an easy way) [14:14:12 CEST] <Diego_> there should be another soultion to compile the video with empty frames :/ [14:14:34 CEST] <JEEB> if you need to stitch together various things dynamically you've left the realm of ffmpeg.c [14:14:41 CEST] <JEEB> and need to make your own code using the APIs [14:18:26 CEST] <thebombzen> Well to be honest this is getting so incredibly complex it's probaby easier to do the temporal chunks of video separately with the different commands [14:18:59 CEST] <thebombzen> and then concatenate them together [14:19:40 CEST] <Diego_> Okay, thank you anyway for all the information :) have a nice day ^^ [16:09:20 CEST] <sgermain> Hi, I'm trying to find some information about an error that's spamming my console: Invalid UI golomb code. Can anyone explain to me why this starts happening after ffmpeg has been up and running for about 5 hours? Thanks. [16:11:30 CEST] <harold> hey guys [16:11:59 CEST] <harold> i have a camcorder which is providing a live stream... and i have a stream of text coming in with x,y coordinate [16:12:23 CEST] <harold> i want to play a blurred small circle on the live feed, as such: https://gyazo.com/c220fb28c6f4f33e3a261dad5e4ec022 [16:12:28 CEST] <harold> what's the simplest way to do that? [16:12:32 CEST] <harold> s/play/place [16:26:14 CEST] <RandomCouch> I'm trying to build ffmpeg for android on Ubuntu [16:26:35 CEST] <RandomCouch> I know I've asked this before but it was for Windows and I wasn't successful [16:26:52 CEST] <RandomCouch> but now I'm on ubuntu, and I'm looking for a good guide to use most recent versions of NDK and ffmpeg [16:26:59 CEST] <RandomCouch> so I can get a .so binary file for android [16:27:24 CEST] <JEEB> 1) get NDK 2) create a standalone toolchain 3) add standalone toolchain to PATH 4) if using GCC, that's pretty much it. if using clang, you also have to put https://git.libav.org/?p=gas-preprocessor.git;a=summary into PATH [16:27:39 CEST] <JEEB> after that it's standard cross-compilation [16:29:16 CEST] <JEEB> in FFmpeg's source dir `mkdir -p android_build && cd android_build && ../configure --prefix=/your/prefix --arch=armv7 --cpu=armv7-a --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi- --enable-shared` [16:29:21 CEST] <RandomCouch> so I got NDK, I've extracted it [16:29:39 CEST] <JEEB> that should give you a very basic ARMv7 config [16:29:50 CEST] <RandomCouch> ok I'm trying that out [16:30:04 CEST] <JEEB> RandomCouch: you need to create the standalone toolchain and add it to PATH [16:30:09 CEST] <JEEB> have you done that?> [16:30:15 CEST] <RandomCouch> No [16:30:18 CEST] <RandomCouch> I'm not sure how to do that heh [16:30:23 CEST] <JEEB> the NDK dir contains [16:30:39 CEST] <JEEB> build/tools/make_standalone_toolchain.py --install-dir /where/you/want/your/standalone/toolchain --arch arm --api 21 [16:30:40 CEST] <RandomCouch> the toolchains folder [16:30:50 CEST] <RandomCouch> ah ok [16:30:58 CEST] <JEEB> that creates a stand-alone ARM toolchain with the API level 21 [16:31:03 CEST] <JEEB> (which is what I'm using) [16:31:12 CEST] <JEEB> you can set it lower if you need to [16:31:18 CEST] <JEEB> https://source.android.com/source/build-numbers [16:31:22 CEST] <JEEB> what the API levels map to :P [16:31:24 CEST] <RandomCouch> nice, 21 is exactly what I need [16:31:41 CEST] <JEEB> usually I have something like /home/my_username/ownapps [16:31:46 CEST] <JEEB> and I put my toolchains there [16:31:56 CEST] <JEEB> in subdirectories [16:33:02 CEST] <JEEB> also since you don't set --cc in the FFmpeg configure that uses GCC 4.9 which google no longer really supports [16:33:32 CEST] <RandomCouch> the make standalone toolchain tool gave me an error [16:33:39 CEST] <RandomCouch> couldn't find AndroidVersion.txt in the target folder [16:33:50 CEST] <JEEB> huh [16:34:08 CEST] <JEEB> it should actually error if it /has/ the directory already :P [16:34:42 CEST] <RandomCouch> lol yeah I just messed up, it deleted a whole directory now for some reason.. [16:35:17 CEST] <RandomCouch> Trying again [16:37:55 CEST] <JEEB> but yea, the only android specific thing is getting the toolchain, really [16:37:59 CEST] <JEEB> after that it's business as usual [16:38:14 CEST] <JEEB> cross compilation and in this case for android [16:38:16 CEST] <RandomCouch> I never really built ffmpeg for any platform [16:38:24 CEST] <RandomCouch> always just downloaded the bin for windows [16:40:11 CEST] <RandomCouch> Alright I just ran the make standalone toolchain command [16:40:15 CEST] <RandomCouch> and everything went well I believe [16:40:35 CEST] <JEEB> ok [16:40:50 CEST] <JEEB> now I recommend you make a script that adds that to your PATH [16:40:50 CEST] <RandomCouch> so let [16:40:56 CEST] <RandomCouch> ok [16:41:01 CEST] <RandomCouch> an .sh script? [16:41:13 CEST] <JEEB> you'd be sourcing it so while yes but not exactly [16:41:20 CEST] <JEEB> let me post mine [16:42:10 CEST] <guther> Is there a way to tell ffmpeg to take the best available stream from a playlist? [16:42:38 CEST] <JEEB> guther: I'd think it does that by default [16:42:54 CEST] <JEEB> since it tries to select the "best" video and audio tracks (one of each) by default [16:43:06 CEST] <JEEB> in quotation marks because what is "best" is 100% up to the code that decides it [16:43:07 CEST] <guther> it takes always low-lowext res in my tests [16:45:01 CEST] <guther> With vlc foo.m3u i get hi-res, with ffmpeg -i foo.m3u i get lowres [16:45:01 CEST] <JEEB> RandomCouch: ok it was literally just a single export line :P [16:45:23 CEST] <JEEB> export PATH=${PATH}:${HOME}/ownapps/ndk-toolchain/armv7/bin:${HOME}/ownapps/android-ndk [16:45:35 CEST] <__deivid__> Hi! Is there a way to tell ffmpeg to read in big buffers/chunks from the files? I'm transcoding LOTS of files with a cluster over NFS [16:45:47 CEST] <JEEB> the first one is the standalone toolchain you made, and the second is the actual NDK dir [16:48:13 CEST] <JEEB> RandomCouch: after you modify the paths you can try running `source thatfile.sh` [16:48:27 CEST] <JEEB> and then check it with `echo "${PATH}"` [16:48:52 CEST] <JEEB> and then try writing arm-linux-<tab><tab><tab> if it looks OK [16:48:59 CEST] <JEEB> it should bring out the NDK toolchain [16:49:55 CEST] <ac_slater> hey guys, If I have a data stream and a video stream in an MPEGTS container, do the PTS and/or DTS of both streams have to relate? [16:50:20 CEST] <ac_slater> ie - use a global PTS/DTS or can the streams truly be independent ? [16:55:47 CEST] <guther> __deivid__ https://www.ffmpeg.org/ffmpeg-protocols.html#cache [16:56:56 CEST] <__deivid__> guther: that's not what I meant. I have like 7TB of video on a NFS server and I'm converting them with multiple workers [16:57:19 CEST] <__deivid__> I **think** ffmpeg is doing lots of small read() instead of fewer, bigger reads [16:57:39 CEST] <__deivid__> gstreamer has this configurable with 'blocksize' [16:57:54 CEST] <JEEB> yea, I think someone recently added some stuff for that although I wouldn't be surprised if there already was some general parameter for it [16:58:24 CEST] <JEEB> yea, "avformat/aviobuf: add support for specifying minimum packet size and marking flush points" [16:58:28 CEST] <JEEB> got merged [16:58:47 CEST] <JEEB> although I think that might be for writing [16:59:11 CEST] <JEEB> there's a lot of parameters for IO [16:59:31 CEST] <JEEB> and if you're doing your own API usage you can make your own IO thing even (I've done that for MS's IStream API) [16:59:47 CEST] <RandomCouch> JEEB: I accidentally entered wrong paths into my PATH [16:59:51 CEST] <RandomCouch> how can I remove them lol [16:59:55 CEST] <JEEB> just close the terminal [17:00:01 CEST] <JEEB> and re-open [17:00:03 CEST] <RandomCouch> I'm connected via ssh [17:00:06 CEST] <RandomCouch> alright [17:00:27 CEST] <JEEB> then just `echo "${PATH}"` to check that you're back to business [17:00:36 CEST] <JEEB> also if you're doing things through ssh I recommend byobu/tmux [17:00:44 CEST] <JEEB> for multi-tabbing goodness [17:00:50 CEST] <RandomCouch> ooh [17:00:53 CEST] <RandomCouch> using putty right now haha [17:01:15 CEST] <JEEB> yea, that's the ssh client, but then on the server you have a thing handling multiple buffers etc [17:01:24 CEST] <JEEB> but that's a discussion for another channel :P [17:02:14 CEST] <RandomCouch> JEEB: in the extracted toolchains dir, I can't find any armv7 folder but I do find arm-linux-androideabi [17:02:18 CEST] <RandomCouch> should I use that instead for my path? [17:03:31 CEST] <JEEB> RandomCouch: I just make two subdirs myself. one for arm(v7) and another for arm64 [17:03:39 CEST] <JEEB> so it's just the /bin directory under the toolchain [17:03:40 CEST] <JEEB> :) [17:04:13 CEST] <RandomCouch> hmm but what do you put inside those dirs? [17:04:52 CEST] <RandomCouch> export PATH=${PATH}:/home/dev/toolchains/NDK/arm-linux/androideabi/bin:/home/dev/NDK/android-ndk-r15 [17:04:56 CEST] <RandomCouch> this is my command right now [17:05:01 CEST] <RandomCouch> is this ok? [17:05:22 CEST] <RandomCouch> woops I meant arm-linux-androideabi * [17:05:25 CEST] <RandomCouch> no slash there [17:05:55 CEST] <JEEB> uhh, I think under <the path you used for the standalone toolchain>/bin exists? [17:05:59 CEST] <JEEB> that's the first one [17:06:18 CEST] <RandomCouch> oh ok [17:09:17 CEST] <JEEB> the NDK's base directory isn't required for FFmpeg itself, but it's a common thing to add to PATH [17:09:26 CEST] <JEEB> since many apps that then use NDK use the tools there [17:11:44 CEST] <ac_slater> RandomCouch: Just use this https://github.com/Bilibili/ijkplayer [17:12:16 CEST] <JEEB> he's not looking for a player, I mean I'm developing a player for android as well (Ž4@) [17:12:34 CEST] <JEEB> or well, mostly lurk nowadays [17:12:40 CEST] <JEEB> others do features now :D [17:12:58 CEST] <ac_slater> ah ok my bad. I found this the other day and they do the android integration well enough [17:13:04 CEST] <ac_slater> ie - mediacodec, etc [17:13:29 CEST] <JEEB> well mediacodec is simple enough [17:13:33 CEST] <ac_slater> and ijkplayer can be used as a library [17:13:35 CEST] <JEEB> enable jni and mediacodec [17:14:01 CEST] <ac_slater> hmm JEEB you mean there is an official ffmpeg mediacodec interop? [17:14:05 CEST] <JEEB> yes [17:14:12 CEST] <JEEB> there's two modes [17:14:22 CEST] <JEEB> output to surface or output to just a buffer [17:14:29 CEST] <RandomCouch> I'm using android's MediaRecorder class to record videos of the gameplay of the Unity game I'm developing [17:14:33 CEST] <JEEB> libmpv uses the latter, and then we build on top of that [17:14:36 CEST] <RandomCouch> it records the screen and microphone input [17:14:47 CEST] <RandomCouch> I want to then append another video to the recorded video [17:14:50 CEST] <RandomCouch> something like an outro [17:15:04 CEST] <ac_slater> JEEB: awesome! [17:15:06 CEST] <ac_slater> thanks [17:15:13 CEST] <RandomCouch> but that outro is not recorded within the app, and the videos recorded in the app do not have a stable frame rate and bitrate [17:15:22 CEST] <RandomCouch> so appending is challenging [17:15:30 CEST] <RandomCouch> because the outro vid has a fixed frame rate and bitrate [17:15:43 CEST] <JEEB> most modern containers are just OK with VFR [17:15:54 CEST] <RandomCouch> I was using mp4parser library for android to append but since it's not working I'm going with ffmpeg for android [17:15:59 CEST] <JEEB> since the whole assumption of "frame rate" goes to the dirt bin with anything modern [17:16:13 CEST] <JEEB> (you have timestamps and durations usually) [17:16:14 CEST] <RandomCouch> VFR = variable frame rate? [17:16:18 CEST] <JEEB> yes [17:16:20 CEST] <RandomCouch> gotcha [17:16:38 CEST] <RandomCouch> when I combine my videos using mp4parser, the audio is combined but there is no image [17:16:46 CEST] <JEEB> and heck, there are containers like FLV or MPEG-TS or Matroska where most common frame rates are actually not save'able with 100% precision [17:16:46 CEST] <ChocolateArmpits> broadcast doesn't suffer vfr ills [17:17:31 CEST] <RandomCouch> JEEB: so I added the paths to my PATH [17:17:37 CEST] <RandomCouch> not sure what to do next to build android binary [17:17:45 CEST] <RandomCouch> and then use it in my android studio project [17:18:20 CEST] <JEEB> have you checked that you have arm-linux-<tab><tab> giving you stuff in the terminal? [17:18:45 CEST] <JEEB> stuff like gcc and clang etc [17:19:33 CEST] <RandomCouch> not getting anything [17:20:06 CEST] <JEEB> did you source that script and check that the directories are really in PATH? [17:20:07 CEST] <RandomCouch> wait nevermind [17:20:13 CEST] <RandomCouch> I'm getting arm-linux-androideabi- [17:20:17 CEST] <JEEB> yup [17:20:19 CEST] <RandomCouch> when I hit tab after arm-linux- [17:20:22 CEST] <JEEB> yup [17:20:36 CEST] <JEEB> alright [17:20:47 CEST] <JEEB> let's add one more thing to just start using clang from the get-go [17:20:48 CEST] <RandomCouch> there are many options, clang and gcc are there [17:21:18 CEST] <JEEB> move to the bin directory of the standalone toolchain that you added to the PATH [17:21:43 CEST] <JEEB> and do what these three lines do https://github.com/mpv-android/buildscripts/blob/master/download.sh#L61..L63 [17:21:54 CEST] <JEEB> that adds gas-preprocessor [17:22:00 CEST] <JEEB> and makes it executable [17:22:23 CEST] <JEEB> clang can't do the ARM assembly that's in FFmpeg without that tool in the PATH [17:24:23 CEST] <JEEB> after that git clone FFmpeg (`git clone https://git.videolan.org/git/ffmpeg.git`) move to its directory and scroll quite a bit up in this chat :) [17:24:36 CEST] <JEEB> because I posted an example buildroot mkdir + configure line [17:24:54 CEST] <RandomCouch> JEEB: hm when I run the wget command I get [17:24:56 CEST] <RandomCouch> Saving to: index.html?p=gas-preprocessor.git;a=blob_plain;f=gas-preprocessor.pl;hb=HEAD.3 [17:25:07 CEST] <RandomCouch> and then when I try the chmod it can't find the gas-preprocessor.pl [17:25:30 CEST] <JEEB> RandomCouch: then you forgot the \ at the end [17:25:36 CEST] <JEEB> it's two-line separated single command [17:25:53 CEST] <RandomCouch> wget "https://git.libav.org/?p=gas-preprocessor.git;a=blob_plain;f=gas-preprocess…" \ -O gas-preprocessor.pl [17:25:56 CEST] <RandomCouch> like this correct? [17:26:03 CEST] <JEEB> if it's a single line you don't need the \ [17:26:09 CEST] <RandomCouch> oh [17:26:31 CEST] <RandomCouch> ok that worked [17:26:35 CEST] <JEEB> nice [17:27:12 CEST] <RandomCouch> do I clone that git repo inside the bin folder too [17:27:16 CEST] <RandomCouch> or it doesn't matter? [17:27:29 CEST] <JEEB> no [17:27:37 CEST] <JEEB> don't do anything else in the bin dir [17:27:42 CEST] <RandomCouch> alright [17:28:00 CEST] <JEEB> the main thing is now that you can call gas-preprocessor from the command line from PATH [17:29:34 CEST] <JEEB> now clone FFmpeg and create a build root (you generally don't build things in their source tree as-is unless you absolutely need to) [17:29:48 CEST] <JEEB> also it enables quick clean-up :) [17:30:00 CEST] <RandomCouch> so after cloning ffmpeg, I create another directory somewhere for the build? [17:30:11 CEST] <JEEB> or within the ffmpeg dir, which is what the lazy me usually does [17:30:19 CEST] <JEEB> main thing is that you don't build right there in the source directory itself [17:30:26 CEST] <RandomCouch> haha gotcha [17:30:42 CEST] <RandomCouch> i got ffmpeg cloned in /home/dev/toolchains/ffmpeg [17:30:50 CEST] <RandomCouch> and created a dir for build in /home/dev/toolchains/ffmpeg_build [17:31:00 CEST] <JEEB> ok [17:31:28 CEST] <JEEB> then your path towards the configure from the ffmpeg_build dir would be ../ffmpeg/configure . to which you then add parameters [17:32:27 CEST] <thomedy> okay... i am trying to decompress audio..i can do it with sox and thats awesome...but im trying to figure out how manysamples per second i havebecausesi tried 44100, 16 bits signed interger encode with 2 channels and the bits dont add up [17:32:41 CEST] <JEEB> --prefix=/your/ffmpeg_prefix --arch=armv7 --cpu=armv7-a --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi- --enable-shared --disable-static --cc=arm-linux-androideabi-clang [17:32:52 CEST] <thomedy> so im trying to figure out whats going on can someone show me how to query ffmpeg -i with raw audio to know my info [17:32:54 CEST] <JEEB> ^ RandomCouch this should build with clang for ARMv7 [17:33:03 CEST] <thomedy> im missing something [17:33:06 CEST] <RandomCouch> sweet, what should my prefix be ? [17:33:16 CEST] <RandomCouch> Is it an important detail or I can put in whatever? [17:33:30 CEST] <thomedy> the song is 253.6 seconds... and based on the m ath i should have a little under 400000000 bits but i have a little over so im missing something when i run to raw [17:33:37 CEST] <JEEB> it's the directory where the binaries will be installed to together with the pkg-config files that help you to build against it [17:33:48 CEST] <JEEB> so you will get a bin/ and lib/ and include/ [17:33:49 CEST] <JEEB> etc [17:33:50 CEST] <JEEB> there [17:33:52 CEST] <JEEB> under that prefix [17:33:56 CEST] <RandomCouch> ah ok [17:34:40 CEST] <JEEB> that should then output the configuration (or an error) [17:34:52 CEST] <JEEB> and if there's an error there's a config.log that you can read [17:35:55 CEST] <RandomCouch> awesome, thanks JEEB ! the command just executed and only gave me a warning [17:35:57 CEST] <RandomCouch> WARNING: arm-linux-androideabi-pkg-config not found, library detection may fail. [17:36:16 CEST] <Diego_> Yo. Can I resize an input video without maintaining aspect ratio? [17:36:18 CEST] <JEEB> yea, that only matters if you are building the FFmpeg against things that have pkg-config files [17:36:33 CEST] <RandomCouch> ah ok, so it doesn't matter in my case if building for android? [17:36:46 CEST] <JEEB> well it matters if you first build X,Y,Z for android and those have pkg-config files [17:36:54 CEST] <JEEB> and then want to build FFmpeg with those [17:37:01 CEST] <JEEB> with just base FFmpeg, no it doesn't matter [17:37:20 CEST] <JEEB> RandomCouch: after that you can just make -jX where X is the amount of cores you have + 1 [17:37:23 CEST] <RandomCouch> ah, ok, have you used ffmpeg with android java ? [17:37:29 CEST] <JEEB> yes [17:37:52 CEST] <RandomCouch> do you know of a good guide on how to package the binary with your java app and use it ? [17:38:00 CEST] <JEEB> and if the build process finishes with make, then `make install` to install the completed thing into the prefix [17:38:47 CEST] <thomedy> i just noticed when i ffmpeg -i input.raw i m getting raw video even though its an audio file that might have something to do with it [17:39:00 CEST] <RandomCouch> make command is running [17:40:25 CEST] <JEEB> RandomCouch: basically you have to copy the required libraries into the correct directory and then use standard JNI within your app to load those libraries [17:41:02 CEST] <JEEB> also usually you might need your own wrapper on top of FFmpeg which you then call from the JNI side [17:41:22 CEST] <JEEB> we have that in mpv-android but unfortunately the NDK integration we have is crude on that side (doesn't use pkg-config) [17:41:44 CEST] <JEEB> it just grabs certain libraries from your build prefix and builds against them :) [17:41:50 CEST] <thomedy> maybe not becuase when i run ffmpeg -i input -f s16le -acodec pcm_s16le output.raw which which forces the rw codec nd bit depth... (ive done enough research to see whats going on here) it still reads as rawsvideo when i run ffmpeg -i [17:43:17 CEST] <RandomCouch> JEEB: I gotta say I am not completely understanding all of this haha, a bit overwhelming but I really appreciate your help [17:43:56 CEST] <RandomCouch> make command is still running [17:44:00 CEST] <RandomCouch> I didn't expect it would take this long [17:44:18 CEST] <JEEB> usually after you get things running you start limiting your configuration [17:44:24 CEST] <JEEB> since FFmpeg contains a metric truckload of stuff [17:44:30 CEST] <JEEB> but only after you get it working ;) [17:44:41 CEST] <RandomCouch> ah [17:44:44 CEST] <JEEB> we've had enough cases where people start with --disable-everything --enable-some-things [17:44:48 CEST] <RandomCouch> all I really need is the concat functionality [17:45:12 CEST] <RandomCouch> for mp4 videos h264 encoded [17:45:19 CEST] <RandomCouch> and aac audio [17:45:23 CEST] <JEEB> well you'll see after you get the API code done [17:45:33 CEST] <RandomCouch> alright :) [17:45:39 CEST] <JEEB> what APIs and components you'd be using etc [17:46:56 CEST] <RandomCouch> I've seen some other links on ffmpeg page for building for android, like this for example http://bambuser.com/opensource [17:47:18 CEST] <RandomCouch> are these easier ways of building ffmpeg for android [17:47:38 CEST] <RandomCouch> assuming all I need is the concat functionality, I probably don't need the latest ffmpeg version [17:47:54 CEST] <JEEB> no [17:48:01 CEST] <JEEB> it's the same exact way of building FFmpeg [17:48:05 CEST] <JEEB> which you've already done :D [17:48:14 CEST] <RandomCouch> ahh I see [17:50:20 CEST] <RandomCouch> awesome, thanks again JEEB, make command is still running, I will run `make install` after that and then I should find the .so binary files in the prefix folder correct? [17:50:32 CEST] <JEEB> yes, and headers under <prefix>/include [17:50:55 CEST] <RandomCouch> what will I use the headers for? [17:51:11 CEST] <JEEB> true, for nothing really unless you write your wrapper in C/C++ in your app [17:51:14 CEST] <JEEB> :) [17:51:23 CEST] <JEEB> and pkg-config .pc files are created under <prefix>/lib/pkgconfig [17:51:48 CEST] <JEEB> which enable you to get the various linking etc flags, although those also are unrelated if you do not make a wrapper in C/C++ and just do everything in JNI [17:52:34 CEST] <JEEB> but yea, 'grats on your first FFmpeg build :) [17:56:38 CEST] <RandomCouch> haha thank you :) [17:56:44 CEST] <RandomCouch> I will just do it all in JNI [17:57:32 CEST] <RandomCouch> will try to follow this repo https://github.com/WritingMinds/ffmpeg-android-java in how they integrated ffmpeg in java [17:58:07 CEST] <JEEB> lol [17:58:30 CEST] <JEEB> that looks like just running the command line or so [17:58:31 CEST] <RandomCouch> is that bad? [17:58:40 CEST] <JEEB> not necessarily [17:58:42 CEST] <RandomCouch> yeah kinda [17:58:51 CEST] <JEEB> if it works for you, sure [17:58:51 CEST] <RandomCouch> it's all I really need, just need to run a concat cmd [17:59:04 CEST] <RandomCouch> also getting a few errors at the end of make command [17:59:06 CEST] <RandomCouch> src/cmdutils.c:100: error: undefined reference to 'stdout' src/ffmpeg_opt.c:897: error: undefined reference to 'stderr' src/ffmpeg.c:2774: error: undefined reference to 'stdout' src/ffmpeg.c:1718: error: undefined reference to 'stderr' src/ffmpeg.c:3864: error: undefined reference to 'stderr' src/ffmpeg.c:4793: error: undefined reference to 'stderr' [17:59:18 CEST] <JEEB> huh [17:59:30 CEST] <JEEB> oh [17:59:31 CEST] <JEEB> right [17:59:38 CEST] <JEEB> you were building the tools as well [17:59:46 CEST] <JEEB> I have those disabled so I wouldn't have noticed that [17:59:50 CEST] <JEEB> even if it was broken [17:59:50 CEST] <RandomCouch> ahh [17:59:59 CEST] <RandomCouch> so I can still run make install? [18:00:02 CEST] <JEEB> no [18:00:04 CEST] <RandomCouch> or do I have to disable the tools first [18:00:05 CEST] <RandomCouch> ok [18:00:12 CEST] <JEEB> well you just said you want to use the tools [18:00:21 CEST] <JEEB> but you might want to remove and recreate the build dir [18:00:26 CEST] <RandomCouch> alright [18:00:34 CEST] <JEEB> and re-configure with without the disable-static/enable-shared [18:00:36 CEST] <RandomCouch> I gotta go on lunch break, thanks a lot JEEB I will continue this in a bit [18:00:39 CEST] <JEEB> as ffmpeg by default builds static [18:00:53 CEST] <JEEB> try with that, and if it still fails then on that NDK you can't build ffmpeg.c [18:01:00 CEST] <JEEB> which you may put in as a bug report if ye want [18:01:04 CEST] <alphabitcity> I'm using ffmpeg to transcode an RTP stream to RTMP. Is it possible to, at the same time, encode ID3 tags at arbitrary stream positions (e.g. timed metadata)? Thank you! [18:05:56 CEST] <Diego_> Hi there. I have a video with 240x240 (in codec information says that real size is 240x256), but when I compile using "scale=1280x480" filter, the video gets resized keeping the aspect ratio. How can I scale without the aspect ratio? I've tried --video_size before the -i option, but it throws an error "Option video_size does not found" [18:06:31 CEST] <JEEB> Diego_: just use setdar or setsar filters after the scale [18:06:48 CEST] <harold> Hey guys, so I have some arbitrary compressed video stream and another text stream at the same time with a single x,y value. I want to output a video stream pretty much on the fly which is basically the video stream I had coming but with some blurring in a 10px radius circle at the x,y point that was given. Is ffmpeg the tool to do this? [18:07:03 CEST] <JEEB> there might have even been an option in the scale filter [18:07:58 CEST] <JEEB> Diego_: I recommend you pass through the manual and start with the scale filter's manual after which you can move to the rest https://www.ffmpeg.org/ffmpeg-all.html#scale-1 [18:10:49 CEST] <Diego_> Thank you JEEB [18:26:25 CEST] <ac_slater> JEEB: I think I asked you this before, but in an mpegts container, do the streams have to have related timestamps [18:29:30 CEST] <alphabitcity> Anyone know if ffmpeg has a notion of timed metadata? I've Googled around -- many have asked, but can't find an answer. [18:29:47 CEST] <ac_slater> ie - inserting metadata at a specific time? [18:30:06 CEST] <alphabitcity> yea, ideally while transcoding .. e.g. every 5 seconds insert a timestamp [18:30:36 CEST] <ac_slater> hmm I don't think that exists but someone else here might know [18:30:41 CEST] <BtbN> I don't think containers even support that [18:30:52 CEST] <ac_slater> I currently carry arbitrary data along with video streams in mpegts [18:31:04 CEST] <BtbN> metadata is global [18:31:06 CEST] <ac_slater> and since it's a program stream, it has timestamps [18:31:32 CEST] <BtbN> every frame has a timestamp [18:31:37 CEST] <BtbN> don't need a seperate stream for that [18:31:57 CEST] <alphabitcity> interesting [18:32:27 CEST] <alphabitcity> how would i access a frame's timestamp? [18:32:46 CEST] <BtbN> "access"? [18:32:58 CEST] <alphabitcity> read [18:33:08 CEST] <BtbN> are you using the C api? [18:33:27 CEST] <alphabitcity> no, I am not [18:33:48 CEST] <alphabitcity> sorry..i'll google around [18:33:53 CEST] <BtbN> I'm not sure what you are asking for then. ffprobe can dump you a list with all frames, including their timestamps [18:34:07 CEST] <BtbN> But what exactly are you even trying to achieve? [18:34:45 CEST] <alphabitcity> trying to insert the current timestamp every ~5 seconds into a video and then transcode and forward via RTMP [18:35:02 CEST] <BtbN> you mean insert visually? [18:35:25 CEST] <BtbN> And by timestamp you mean wall clock time? [18:35:26 CEST] <alphabitcity> no, in some sort of data channel .. to then be read via HLS playback https://developer.apple.com/library/content/documentation/AudioVideo/Concep… [18:35:29 CEST] <alphabitcity> yes [18:35:56 CEST] <BtbN> The video timestamps are arbitrary, only means to ensure steady playback [18:36:23 CEST] <alphabitcity> i see, then it wouldn't work for us [18:37:11 CEST] <BtbN> doesn't each hls segment carry its creation time anyway? [18:37:21 CEST] <BtbN> like, its file creation time [18:37:28 CEST] <BtbN> usually http servers send that along [18:38:50 CEST] <alphabitcity> we want the time to be before it's transcoded to hls [18:39:05 CEST] <alphabitcity> https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2013-December/072450.html [18:39:12 CEST] <alphabitcity> is a discussion that i believe is related [18:39:26 CEST] <alphabitcity> although hard for me to tell if support for timed id3 metadata made it in [18:41:06 CEST] <BtbN> what do you mean, before it's transcoded to hls? [18:41:20 CEST] <BtbN> So the creation time of the original video? [18:41:37 CEST] <alphabitcity> sorry, we're using ffmpeg to transcode an rtp stream to rtmp. right now we have a system that injects AMF data. hoping to replace that with ffmpeg, but I don't think ffmpeg supports AMF [18:41:53 CEST] <BtbN> if it's just a static video, it's not too impossible [18:42:03 CEST] <BtbN> but for a live stream, I don't think there is any supported format [18:42:45 CEST] <alphabitcity> it's a live stream .. i guess rtmp only supports timed metadata via AMF (action message format), but that seems to be an old spec and I don't believe ffmpeg can encode AMF [19:13:10 CEST] <RandomCouch> Hey JEEB I'm back, so when I execute the make -j2 command, I get a lot of warnings for deprecated code [19:13:26 CEST] <RandomCouch> for example src/ffserver.c:3686:17: warning: 'codec' is deprecated (declared at src/libavformat/avformat.h:89 [19:16:25 CEST] <BtbN> feel free to fix them [19:16:51 CEST] <RandomCouch> I feel very free to do so, but I don't feel experienced enough to do it lol [19:17:04 CEST] <aasif> Hello, everyone. I'd like to learn about FFmpeg and its documentation. I tried diving in the huge codebase first. But it's too technical. I would highly appreciate any advice. Thanks. [19:17:41 CEST] <RandomCouch> aasif: I guess your first step would be figuring out what you want to use ffmpeg for [19:40:39 CEST] <JEEB> RandomCouch: deprecation warnings in internal things (as in, not coming from your code) are OK. [20:15:30 CEST] <kerio> furq this album weighs 2GB [20:15:35 CEST] <kerio> feels good man [20:33:56 CEST] <RandomCouch> JEEB is there a way or a place where I can get precompiled ffmpeg binaries for android [20:34:21 CEST] <RandomCouch> everything I try doesn't seem to be working, and every git repo of an ffmpeg android project is outdated [20:34:43 CEST] <JEEB> if you can't compile the command line app(s) then nobody else can most likely either [20:34:48 CEST] <ac_slater> does anyone know the proper way to mux data with b-frames? As in, I'm trying to do av_interleaved_write_packet to mux h264 data into a mpegts container. Do I have to explain to the muxer that there is going to be B-frames ? [20:34:49 CEST] <RandomCouch> my builds don't seem to work [20:35:00 CEST] <RandomCouch> hmm [20:35:44 CEST] <JEEB> well, I build the libraries (shared in my case) just fine with the same way [20:35:45 CEST] <ac_slater> RandomCouch: I think you need to practice compiling things for android before you get FFMPEG working. It's not going to be much different, but testing out the native (NDK) stuff with a smaller library might be easier [20:36:00 CEST] <RandomCouch> when I clone and run this project on my device [20:36:02 CEST] <RandomCouch> https://github.com/WritingMinds/ffmpeg-android-java [20:36:07 CEST] <RandomCouch> it works with ffmpeg [20:36:38 CEST] <RandomCouch> I guess I'll just add my own code to it [20:37:24 CEST] <JEEB> so your binary works with taht thing or what? [20:37:32 CEST] <RandomCouch> well it's not my binary [20:37:41 CEST] <RandomCouch> it's been packaged in that repo [20:37:49 CEST] <JEEB> right [20:37:52 CEST] <RandomCouch> so when I run the app ffmpeg binary gets injected [20:38:02 CEST] <JEEB> also do check its license [20:38:03 CEST] <DHE> ac_slater: you need to submit the AVPackets in ascending DTS order, which should be the order they come out of the encoder [20:38:05 CEST] <JEEB> it's GPLv3 [20:38:18 CEST] <DHE> also use a container that supports b-frames. AVI most famously does not and any attempt to use them is a hack [20:38:19 CEST] <RandomCouch> hm, does that mean I cannot use this for a product? [20:38:53 CEST] <ac_slater> DHE: Interesting. I'm trying to demux then remux. So I'm not getting packets from an encoder [20:38:59 CEST] <JEEB> GPLv3 is basically "if you use this thing you're making your own thing GPLv3 as well. plus you cannot add licensing to it that stops modified versions of it from running on devices" [20:39:03 CEST] <ac_slater> DHE: which is probably my issue [20:39:31 CEST] <DHE> ac_slater: still, the reverse basically applies. you should be getting the AVPackets in ascending DTS order and submit them to the decoder in that same order, what comes out will be AVFrames in regular chronological order [20:39:45 CEST] <JEEB> RandomCouch: anyways I didn't see where that thing builds FFmpeg or with which NDK, but for normal API usage things work for me just fine with the binaries you built [20:40:08 CEST] <DHE> the kicker is that, like encoding, the decoder will buffer some frames and you can't rely on getting 1 in, 1 out all the time. [20:40:29 CEST] <ac_slater> DHE: yea I noticed that. Though, I'm not doing any decoding. Just demux + remux [20:40:35 CEST] <RandomCouch> JEEB: the .so files are in these folders https://github.com/WritingMinds/ffmpeg-android-java/tree/master/FFmpegAndro… [20:40:51 CEST] <JEEB> the actual build stuff is @ https://github.com/WritingMinds/ffmpeg-android [20:40:56 CEST] <RandomCouch> yeah [20:41:02 CEST] <JEEB> seems like some older version of FFmpeg with random dependencies added [20:41:09 CEST] <JEEB> most definitely not what you want [20:41:17 CEST] <RandomCouch> hmm [20:41:26 CEST] <DHE> ac_slater: did you copy the codecpar between the two AVStreams ? [20:41:33 CEST] <ac_slater> hmm yea. [20:41:39 CEST] <RandomCouch> I only have today to get this done, and if I can't we have to go with another solution which will compromise some functionality in the application I'm working on [20:42:14 CEST] <JEEB> then you started way too late and the binaries that project gives you are not OK for any closed source usage on any level :P [20:42:18 CEST] <RandomCouch> You'd think concatenating two videos files together on android would be simple :( [20:42:36 CEST] <JEEB> btw, did building ffmpeg fail with your build [20:42:46 CEST] <JEEB> or only ffprobe/ffserver? [20:42:47 CEST] <RandomCouch> yeah I couldn't fix those errors [20:42:55 CEST] <JEEB> the stderr one? [20:42:56 CEST] <ac_slater> DHE: sorry, I'm talk to you directly, but yea I did copy codecpar [20:42:59 CEST] <RandomCouch> even though I reconfigured ffmpeg and removed enable_shared [20:43:01 CEST] <RandomCouch> yeah [20:43:07 CEST] <RandomCouch> I was using NDK r15 [20:43:12 CEST] <JEEB> ok, that might have been something that changed in some NDK version then [20:43:16 CEST] <RandomCouch> maybe I could try earlier version [20:43:21 CEST] <JEEB> lessee what this thing uses :P [20:43:49 CEST] <JEEB> unless they just forked FFmpeg and patch it [20:44:09 CEST] <JEEB> oh, at least it seems to point towards the main repo [20:45:16 CEST] <RandomCouch> uses a lot of thigns I'm not familiar with lol, like the ButterKnife injecting thing [20:45:22 CEST] <RandomCouch> makes me realize how little I know [20:48:52 CEST] <ac_slater> DHE: for some reason, after I copy codecpar between the inputstream and the muxer, I set codec_tag to 0 as one of the examples did [20:52:13 CEST] <JEEB> RandomCouch: I'm on r14b and I just built it just fine [20:52:36 CEST] <JEEB> exact FFmpeg revision is feb13aed794a7f1a1f8395159e9b077351348a34 [20:52:45 CEST] <JEEB> but I would be surprised if something happened since [20:53:13 CEST] <JEEB> other than the prefix I just set `--arch=armv7 --cpu=armv7-a --enable-cross-compile --target-os=android --cross-prefix=arm-linux-androideabi- --disable-debug --disable-doc --disable-ffprobe --disable-ffserver --cc=arm-linux-androideabi-clang` [20:53:23 CEST] <JEEB> the debug ones really don't matter [20:54:34 CEST] <JEEB> RandomCouch: I had other issues with hardware decoding on R15 which is why I didn't use it, but I'll laugh out loud if this change was also between R14b and R15 :P [20:56:28 CEST] <shincodex> so uh tcp over rtsp [20:56:33 CEST] <shincodex> + a shit router [20:56:38 CEST] <c_14> eeeh [20:56:43 CEST] <shincodex> why would h264 give me half assed frames [20:56:43 CEST] <c_14> I'm not sure tcp over rtsp is supported [20:56:49 CEST] <c_14> unless you mean rtsp over tcp [20:56:51 CEST] <shincodex> pixelated blotched broken [20:57:00 CEST] <shincodex> Yes what you said [20:57:13 CEST] <c_14> encoder issues? [20:57:23 CEST] <c_14> not enough bitrate? [20:57:23 CEST] <shincodex> Negative [20:57:28 CEST] <shincodex> VLC fixes all these problems [20:57:41 CEST] <c_14> vlc as source or sink? [20:57:43 CEST] <shincodex> Unless theere just duplicating non corrupt frames fooling the user [20:58:04 CEST] <shincodex> VLC player is used to test same stream and its not experiencing corruption [20:58:18 CEST] <JEEB> RandomCouch: latest git (04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8) works too [20:58:27 CEST] <JEEB> I can switch to R15 as well and see if that fails [20:58:30 CEST] <shincodex> i mean this: av_dict_set(&options, "rtsp_transport", "tcp", 0); [20:58:38 CEST] <shincodex> and i am going to test latest source but.... [20:58:42 CEST] <shincodex> but uh [20:58:59 CEST] <shincodex> #define LIBAVFORMAT_VERSION_MAJOR 57 #define LIBAVFORMAT_VERSION_MINOR 66 #define LIBAVFORMAT_VERSION_MICRO 104 [20:59:07 CEST] <shincodex> im pretty certain thats only a few months old [20:59:23 CEST] <JEEB> you can get a nicer version for humans out of one of the avutil functions [20:59:34 CEST] <shincodex> oh yeah [20:59:35 CEST] <JEEB> av_version_info() [20:59:36 CEST] <c_14> I meant using vlc as a a player vs. using vlc as a streaming server [21:00:02 CEST] <shincodex> We use vlc player to test if similar network streams have issues [21:00:12 CEST] <shincodex> than lib av code we use [21:00:45 CEST] <c_14> so on one hand a vlc playing the stream on the other some custon libav* demuxer/decoder/renderer? [21:01:26 CEST] <shincodex> vlc merely for testing for issue [21:01:37 CEST] <shincodex> i wouldn't say that we have much custom going on [21:01:45 CEST] <shincodex> its literally a for loop with [21:01:50 CEST] <RandomCouch> Thanks JEEB, I'm going to give it another try with NDK r14b [21:02:09 CEST] <shincodex> avformat_open_input , formatContext->streams[i]->codec->codec_type == AVMEDIA_TYPE_VIDEO, avcodec_find_decoder, avcodec_open2, etc [21:02:39 CEST] <JEEB> &35 [21:02:47 CEST] <shincodex> av_read_frame, avcodec_decode_video2 [21:04:00 CEST] <JEEB> RandomCouch: R15 did work for me, though... [21:04:04 CEST] <JEEB> for ARMv7 [21:04:07 CEST] <RandomCouch> hmm [21:04:13 CEST] <RandomCouch> I must be doing something wrong then [21:04:15 CEST] <JEEB> I just switched the toolchain symlinks [21:04:24 CEST] <RandomCouch> I found this though https://github.com/IljaKosynkin/FFmpeg-Development-Kit [21:04:37 CEST] <RandomCouch> claims to be an easy building process for android [21:04:40 CEST] <JEEB> uhh [21:04:45 CEST] <JEEB> the building really isn't hard [21:04:53 CEST] <JEEB> it's not magic [21:04:58 CEST] <JEEB> I'm definitely not a magician [21:05:15 CEST] <RandomCouch> I'm a bit of a noob with UNIX, so I'm downloading the sources then transfering them to my ubuntu droplet with ssh then working with the CLI [21:07:00 CEST] <c_14> shincodex: tried a different player besides vlc? can't really think of much that should go wrong there [21:07:12 CEST] <JEEB> anyways, you may try r14b in case google silently switched the binaries for r15 to something else [21:07:40 CEST] <shincodex> Vlc is removing the corruption [21:07:49 CEST] <JEEB> but in general it's just 1) get NDK tarball and extract it 2) make the stand-alone toolchain(s) 2) use the stand-alone toolchain after adding its bin/ into PATH [21:11:45 CEST] <JEEB> RandomCouch: like - this stuff works for multiple people in the mpv-android team https://github.com/mpv-android/buildscripts/blob/master/download.sh#L44..L64 [21:21:02 CEST] <c_14> shincodex: still not sure what could be causing the corruption, tried anything besides rtsp? [21:28:07 CEST] <shincodex> Im purposely setting up a crap throttled network [21:28:22 CEST] <shincodex> and its gotta be rtsp [21:34:01 CEST] <Guest27311> how do i use filter complex properly? .\ffmpeg.exe -i .\in.gif -i .\palette.png -map 0:0 -filter_complex "[1]palet teuse;[0]scale=-1:150" -r 10 -y out.gif [21:35:40 CEST] <c_14> shincodex: I just want to check if the problem is rtsp or maybe unrelated [21:36:35 CEST] <shincodex> [rtsp @ 000001F5BA95E620] CSeq 15 expected, 14 received. [21:36:51 CEST] <shincodex> me wonders if i get too many of those [21:36:56 CEST] <shincodex> i will get corruption [21:37:08 CEST] <shincodex> and me guesses that is packet reodering or frame reordering for timing [21:37:23 CEST] <c_14> Guest27311: [0][1]paletteuse,scale [21:38:02 CEST] <Guest27311> "Cannot find a matching stream for unlabeled input pad 0 on filter Parsed_scale_1" [21:38:07 CEST] <Guest27311> @c_14 [21:38:51 CEST] <c_14> does it work without the scale? [21:38:59 CEST] <Guest27311> c_14: yes [21:40:49 CEST] <c_14> shincodex: you're getting duplicate RTSP commands [21:41:27 CEST] <Guest27311> found an example and got it working with this but I don't understand the syntax. .\ffmpeg.exe -i .\in.gif -i .\palette.png -filter_complex "scale=-1:150 [x]; [x][1:v] paletteuse" -r 1 0 -y out.gif [21:42:05 CEST] <c_14> you're scaling the input video first, storing the output in [x] and then using that along with the palette ([1:v]) as inputs to paletteuse [21:46:01 CEST] <RandomCouch> I just ran the make command like 15 minutes ago [21:46:05 CEST] <RandomCouch> and it's still running xD [21:47:01 CEST] <RandomCouch> JEEB, can you um, show me you use the .so files with JNI? :D [21:47:06 CEST] <Guest27311> you can specify how many threads you want for compiling with -j8 [21:47:16 CEST] <RandomCouch> ahh interesting [21:47:16 CEST] <Guest27311> -j4 [21:47:30 CEST] <RandomCouch> I don't want to cancel it now though because I feel like it should be done soon [21:47:31 CEST] <Guest27311> not sure if make has that implemented or what [21:47:37 CEST] <RandomCouch> yeah [21:47:39 CEST] <RandomCouch> it does [21:48:28 CEST] <guther> How can i cut out a sequence from a video? I thought of something like: 'ffmpeg -ss 00:10:00.00 -i INPUT.ts -t 00:10:00.00 -ss 00:30:00.00 -i INPUT.ts -t 00:10:00.00 -c copy OUT-10-20+30-40.ts' [21:51:12 CEST] <ChocolateArmpits> guther your command line implies you want the video to oly be 10 minutes long while the inputs are 30 minutes long [21:51:52 CEST] <ChocolateArmpits> also this won't work without use of filters and transcoding [21:52:22 CEST] <ChocolateArmpits> unless you use a concat file where the times are specified there, ffmpeg will then interpret all streams as continuous [22:04:28 CEST] <guther> Could it be done with -vf trim? [22:06:57 CEST] <RandomCouch> my make command is STILL running o.O [22:07:02 CEST] <RandomCouch> this is unbelievable [22:07:10 CEST] <RandomCouch> I'm just gonna leave my work PC on and check it again on monday [22:07:26 CEST] <furq> you can just abort it and run make -j8 [22:07:29 CEST] <furq> it'll pick up where it left off [22:07:55 CEST] <RandomCouch> I'm not sure how many cores my droplet has though :/ [22:08:00 CEST] <DHE> or if you have a good CPU, -j 16. specify number of available threads [22:08:02 CEST] <furq> cat /proc/cpuinfo [22:08:04 CEST] <DHE> got `lscpu` available? [22:08:07 CEST] <RandomCouch> oh nice [22:08:09 CEST] <RandomCouch> thanks furq [22:08:11 CEST] <RandomCouch> trying now [22:08:29 CEST] <kerio> furq: https://i.imgur.com/gdlecpZ.png are you upset [22:08:41 CEST] <furq> lol it's alac [22:08:49 CEST] <RandomCouch> cpu family : 6 model : 63 model name : Intel(R) Xeon(R) CPU E5-2650L v3 @ 1.80GHz stepping : 2 [22:08:54 CEST] <RandomCouch> am I looking for stepping? [22:09:01 CEST] <furq> no you're looking for how many of those show up [22:09:09 CEST] <RandomCouch> oh ok only one did [22:09:16 CEST] <furq> bad luck then [22:09:20 CEST] <RandomCouch> myea [22:09:23 CEST] <RandomCouch> digitalocean droplet [22:09:30 CEST] <RandomCouch> lowest price one lol [22:09:48 CEST] <DHE> if you have the entire CPU to yourself, that's good for -j 24 [22:09:51 CEST] <JEEB> RandomCouch: literally System.loadLibrary() :P that's how you do JNI anywhere [22:09:51 CEST] <furq> kerio: i am now really laughing at the idea of an italian radiohead fan [22:09:56 CEST] <kerio> why :< [22:10:04 CEST] <RandomCouch> awesome thanks JEEB [22:10:15 CEST] <RandomCouch> I'm gonna prob do some work on this over the weekend and see if I can make any progress [22:10:22 CEST] <RandomCouch> You've been a great help JEEB [22:10:29 CEST] <iive> RandomCouch: 16 threads, use -j16 [22:10:37 CEST] <RandomCouch> oh sweet thanks I'll try that [22:10:42 CEST] <kerio> o fug [22:10:50 CEST] <kerio> alac is 30kbps bigger than flac [22:10:58 CEST] <DHE> I have 12 cores + hyperthreaded for -j 24 (assuming you have a dedicated server and not sharing the CPU) [22:10:59 CEST] <kerio> 34, rather [22:11:25 CEST] <iive> RandomCouch: the total numbers of cpu's is a few lines bellow. [22:11:27 CEST] <kerio> does the flac encoder have a compression speed parameter [22:11:28 CEST] <furq> pablo 'anney [22:11:35 CEST] <furq> bellissimo [22:11:59 CEST] <furq> if you mean the cli encoder then -8 [22:12:06 CEST] <kerio> can i get that from within ffmpeg [22:12:10 CEST] <furq> -q:A [22:12:12 CEST] <furq> a [22:12:34 CEST] <kerio> it doesnt change a fucking thing [22:13:05 CEST] <furq> the ffmpeg flac encoder is builtin [22:13:23 CEST] <furq> you should probably use libflac if it's something you care about [22:13:28 CEST] <furq> although i can't imagine you do [22:14:08 CEST] <JEEB> RandomCouch: if you've never looked at the APIs I don't give you a high chance of success. but sure, it's /possible/ [22:14:29 CEST] <durandal_1707> furq is again promoting nonffmpeg software [22:14:47 CEST] <kerio> furq: -8 shaved 3 kbps :o [22:14:54 CEST] <furq> https://www.youtube.com/watch?v=_F-Cy2YqAW4 [22:15:05 CEST] <kerio> so thats 3267kbps versus 3304 [22:15:15 CEST] <furq> also yeah -8 isn't really worth it most of the time but some people get extremely angry about it [22:15:21 CEST] <RandomCouch> JEEB: I'll give it a shot with what I know and of course if I have to I will take a look at the APIs and see how to use them, I have developed native android stuff before so I have no issues working with Java, gradle and android studio [22:15:40 CEST] <kerio> furq: i guess it only makes sense to do -0 and -8 [22:15:46 CEST] <furq> well -5 is the default [22:15:50 CEST] <kerio> D: [22:15:52 CEST] <RandomCouch> I never loaded binaries into my android project though so that's gonna be something new to me [22:15:53 CEST] <furq> above that you get massively dimishing returns [22:16:03 CEST] <furq> and diminishing ones too [22:16:31 CEST] <kerio> furq: anyway, i decided that this version of ok computer is ok computer [22:16:33 CEST] <durandal_1707> ffmpeg encoder have some alien options for fast hardware encoding with high ratios of compression [22:16:33 CEST] <kerio> released in 1997 [22:16:46 CEST] <furq> durandal_1707: you mean like flaccl [22:17:08 CEST] <durandal_1707> furq: like it but gmfor cpu only [22:20:15 CEST] <furq> i take it the builtin flac encoder is much better relative to libflac than the vorbis and opus encoders [22:20:40 CEST] <furq> and also reversible if it turns out not to be [22:57:08 CEST] <guther> Do i really have to ffmpeg ... OUT.1st & ffmpeg ... OUT.2nd & ffmpeg -i OUT.1st -i OUT.2nd FINAL.suf ?? [22:58:25 CEST] <DHE> wut? [22:58:55 CEST] <DHE> ffmpeg is a bit complicated to use for advanced processing, but chances are what you want can be done in a single shot [22:59:29 CEST] <durandal_1707> guther: what are you doing? [23:00:01 CEST] <guther> i wanna cut out and drop some part in the middle [23:00:37 CEST] <guther> Like from min5 till min30, and then from min 40-60 [23:01:14 CEST] <guther> ^^ that would be the parts to keep [23:02:04 CEST] <DHE> https://ffmpeg.org/ffmpeg-filters.html#concat read examples [23:03:24 CEST] <ChocolateArmpits> guther, either use -ss -to specifiers and concat filter to connect ^ or use a concat file by specifying inpoint and outpoint for each part as per https://www.ffmpeg.org/ffmpeg-formats.html#concat-1 [23:04:07 CEST] <ChocolateArmpits> concat file of course requires an additional file to process, a single command line will be simpler [23:04:17 CEST] <ChocolateArmpits> with concat filter [23:05:00 CEST] <DHE> this method can be done in a single shot, but has the disadvantage that the start points for seeking may be inaccurate due to keyframe locations [23:05:50 CEST] <DHE> more precision could be done with the select filter but now we're getting out of the traditional area of expertise [23:07:11 CEST] <guther> Note that it is done globally and may cause gaps if all streams do not have exactly the same length. [23:07:45 CEST] <guther> Does that mean that all chunks need to be the same size??? [23:08:01 CEST] <furq> you can use trim,setpts;concat [23:08:06 CEST] <furq> idk how fast that is though [23:08:10 CEST] <DHE> no, it means if you have varying framerates, audio sample durations, and so on. [23:08:27 CEST] <ChocolateArmpits> DHE, input -ss can also be innacurate. I think a bigger disadvantage of inpoint/outpoint is that the initial time offset has to be accounted for too [23:08:55 CEST] <DHE> ChocolateArmpits: I said that. the start points may be inaccurate [23:09:56 CEST] <furq> http://vpaste.net/SfdkV [23:09:57 CEST] <guther> How about -crf ? Does it influence concat? [23:09:58 CEST] <furq> like that [23:10:34 CEST] <DHE> guther: the pipeline is input file, filter, encoding, outputfile. crf is a parameter for the encoder. [23:10:49 CEST] <DHE> well, insert decoder between input file and filter [23:12:48 CEST] <guther> DHE, so - input file, encoding, filter, outputfile ? [23:13:09 CEST] <DHE> no. the encoder produces compressed content and you can't filter that. [23:14:29 CEST] <guther> furq, thx. That really looks complex. :( [23:15:50 CEST] <DHE> guther: we warned you it could be done, but was complex [23:16:11 CEST] <furq> i don't know if that will be faster [23:16:13 CEST] <furq> i suspect it won't be [23:16:57 CEST] <guther> mplayer has -edl , not quiet sure though if it works with mencoder, but i hoped for something like that [23:17:29 CEST] <DHE> mencoder does have a feature like that, but mencoder is old and clunky now. [23:18:20 CEST] <guther> It probably is, but -edl would be a nice feature to ffmpeg [23:18:42 CEST] <durandal_1707> whats edl? [23:18:47 CEST] <DHE> edit list [23:18:58 CEST] <DHE> a text file of the form (starttime, endtime, action) where action might be Mute or Skip [23:19:13 CEST] <guther> right [23:19:13 CEST] <DHE> at least in mplayer/mencoder lingo [23:32:35 CEST] <alexpigment> does anyone know what the simplest/quickest deinterlace method is in FFMPEG? [23:32:49 CEST] <alexpigment> I just need a simple Bob for previewing [23:33:19 CEST] <durandal_1707> what simple bob does? [23:34:08 CEST] <durandal_1707> fastest deinterlacer in lavfi is w3fdif and its not bob [23:36:17 CEST] <alexpigment> it's not bob = ? [23:36:50 CEST] <alexpigment> does it have a bob mode? [23:37:18 CEST] <durandal_1707> nope [23:38:01 CEST] <alexpigment> ok, so yadif it is, then? [23:38:26 CEST] <durandal_1707> yadif is not bob [23:38:46 CEST] <alexpigment> i feel like there's a difference of terminology here [23:38:48 CEST] <BtbN> why do you care for the method, if you just want it to be fast? [23:39:06 CEST] <alexpigment> when I say "bob", i mean field doubling with the result of 2xFPS [23:39:27 CEST] <BtbN> you said you want a simple and fast deinterlacer [23:39:32 CEST] <alexpigment> BtbN: because it doesn't need to be good quality. but it needs to have the correct temporal resolution [23:39:33 CEST] <furq> separatefields,scale [23:39:41 CEST] <furq> is as close as you'll get afaik [23:39:45 CEST] <alexpigment> furq: awesome, thank you [23:40:14 CEST] <durandal_1707> doubleweave [23:41:01 CEST] <BtbN> isn't weave deinterlacing just "do nothing"? [23:41:06 CEST] <BtbN> and remove the interlaced flag [23:41:13 CEST] <alexpigment> durandal_1707: i'll try that too. I presume it should be quicker than yadif? [23:42:04 CEST] <alexpigment> hmm, I guess doubleweave requires that you manually specify tff or bff... [23:42:32 CEST] <durandal_1707> separatefields,doubleweave [23:42:50 CEST] <alexpigment> hmmm, that seems redundant, right? [23:43:05 CEST] <furq> doesn't that give interlaced output [23:43:26 CEST] <alexpigment> i'm going to test separatefields+scale and see how that works [23:43:41 CEST] <furq> not very well [23:43:48 CEST] <furq> but it meets all the criteria you said you have [23:44:11 CEST] <durandal_1707> separatefields,setsar... [23:44:12 CEST] <alexpigment> not very well isn't too big of a deal (I don't think) [23:44:28 CEST] <alexpigment> is there any advantage to setsar vs scale? [23:44:33 CEST] <furq> setsar will be much quicker [23:44:40 CEST] <alexpigment> k [23:44:56 CEST] <alexpigment> and if i remember my sar vs dar correctly, sar would be like 16x9 right? [23:45:02 CEST] <furq> but the correct sar would be harder to work out [23:45:02 CEST] <alexpigment> nm, that's dar [23:45:04 CEST] <alexpigment> i'll figure it out ;) [23:46:51 CEST] <furq> actually nvm you can just do setsar=sar*2 [23:47:07 CEST] <alexpigment> true [23:47:14 CEST] <alexpigment> that makes this easier [23:47:18 CEST] <alexpigment> thanks [23:47:33 CEST] <furq> that'll look even uglier than scale but i'm guessing that's not a problem [23:49:32 CEST] <alexpigment> i'll do some visual analysis in a bit, but quality isn't terribly important for this particular process. if the speed difference isn't huge though, i'll probably just go back to yadif [23:50:07 CEST] <furq> i'd have thought separatefields,setsar would be basically instant [23:50:22 CEST] <furq> so i guess the question is how slow yadif is [23:50:46 CEST] <alexpigment> yeah, i'm setting up my tests right now. hopefully it should be instant [00:00:00 CEST] --- Sat Jun 24 2017

1 0

ffmpeg-devel.log.20170622
by burek 23 Jun '17

23 Jun '17

[00:00:24 CEST] <atomnuker> durandal_170: seems I dirty my output somewhere [00:01:10 CEST] <atomnuker> OH, NEVERMIND [00:01:41 CEST] <atomnuker> I gave the function the original twiddles [00:01:46 CEST] <atomnuker> fate passes [00:04:10 CEST] <BBB> jamrial: thats hilarious :D [00:05:08 CEST] <jamrial> BBB: what, msvc and nasm not being nice to each other? [00:05:34 CEST] <BBB> that netbsd error [00:05:38 CEST] <jamrial> oh [00:05:54 CEST] <jamrial> more like annoying, though :p [00:07:10 CEST] <BBB> kind of, yes [00:07:33 CEST] <jamrial> guess it's some bash problem in netbsd. it's printing the contents meant for the .d file to strerr [00:08:03 CEST] <jamrial> or something like that. i can't really test... [00:35:27 CEST] <atomnuker> patch for fft15 asm sent to the ML [00:36:45 CEST] <atomnuker> this was quite fun to write, not nearly as impossible as I thought it would be [00:38:53 CEST] <iive> hum [00:40:51 CEST] <atomnuker> the reason why I shuffle the twiddles is because I went one way first, rewrote the C code to use it and realized it wasn't good at all [00:41:12 CEST] <atomnuker> and now its too complicated to untangle and go directly to what they have to be [00:42:00 CEST] <iive> movddup that the asm starts with, doesn't do what the commends say, and you do use xmm register. [00:42:21 CEST] <iive> it loads a single double into both parts of the register. [00:43:11 CEST] <atomnuker> its not a double, its 2 floats [00:43:43 CEST] <atomnuker> saves a shuffle [00:44:23 CEST] <iive> some cpu track the float double status... [00:44:44 CEST] <iive> even so, it still doesn't do what the comment says [00:45:37 CEST] <iive> it would load in[0].rq/im in high and low [00:50:45 CEST] <atomnuker> okay, the comment is wrong [00:51:36 CEST] <iive> next comment is also wrong [00:52:10 CEST] <iive> you load only the low part of the register and store 0 in the high, don't you? [00:52:57 CEST] <atomnuker> yes [00:53:08 CEST] <atomnuker> the comments were made back when all loads there were movups [00:53:31 CEST] <atomnuker> in hindsight only movddup makes a difference [00:54:00 CEST] <atomnuker> movups and movsd have the same performance on my cpu [00:55:07 CEST] <iive> there is severe penatly on older cpu if you cross cache line (64 byte) [00:55:57 CEST] <iive> also, shuffle is mostly 1 cycle on anything newer than p4... [00:56:25 CEST] <atomnuker> well, this is avx2 only (since anything that does fma3 will support avx2) [00:56:36 CEST] <atomnuker> no reason not to save a shuffle though [00:57:38 CEST] <atomnuker> its possible to do the butterflies with 128bit regs but you'll need all 16 regs [00:59:45 CEST] <iive> i haven't looked into fma stuff closely, but I think this function could easily be done with sse2 only :P [01:00:13 CEST] <atomnuker> patches accepted after it gets merged [01:00:37 CEST] <iive> :D [01:02:20 CEST] <iive> random nitpick, imul r4q,2 ; maybe use shift to left. or lea [01:05:32 CEST] <iive> another minor nitpick, could you number the macro arguments (in the comment) with 7 of them it is fairly easy to lost count :D [01:07:03 CEST] <atomnuker> yeah, I'll just move the description at the line above [01:07:37 CEST] <atomnuker> (by that I mean I'll add a new line above with numbers) [01:08:15 CEST] <atomnuker> it is easy to lose count especially since macros are 1-indexed rather than 0 indexed [01:08:30 CEST] <atomnuker> its annoying, who thought to do that? [01:10:37 CEST] <iive> masm? [01:12:24 CEST] <iive> btw, fma3 does not imply avx2, x86inc does the opposite (I think) [01:12:56 CEST] <iive> your code specifies fma3 [01:14:21 CEST] <jamrial> avx2 implies fma3, but fma3 does not imply avx2, yeah [01:16:47 CEST] <iive> avx2 is mostly integer ops, and gather [01:18:18 CEST] <iive> perm and broadcast [01:34:11 CEST] <atomnuker> so what do I do? [01:34:16 CEST] <atomnuker> is it correct or not? [01:36:04 CEST] <jamrial> atomnuker: yes, you're not using any avx2 instructions [01:37:21 CEST] <J_Darnley> I don't know about newer instructions but x264asm will warn you if you use an sse4 instruction when you only specify sse2, for example. [01:37:55 CEST] <iive> unfortunately it doesn't overload avx2 instructions [01:38:06 CEST] <iive> so you won't get warning for them. [01:38:29 CEST] <iive> it might complain that you are not using the v* prefix... but [01:38:50 CEST] <iive> that's only if the legacy form is forbidden for new avx2 ops [01:39:56 CEST] <J_Darnley> Well I guess you can ignore me [01:43:58 CEST] <jamrial> J_Darnley: that's what iive said, it doesn't work on avx+ instructions [01:44:40 CEST] <iive> J_Darnley: no worries :) [01:45:37 CEST] <iive> i think it works on avx1 [01:53:18 CEST] <iive> atomnuker: final nitpick (for today). if you expect your register size to be 256bit, then it might be better idea to use the ym0 form, instead of m0 [01:53:35 CEST] <iive> the idea is that m0 is sued when the code could handle any size. [01:53:56 CEST] <iive> sued/used [01:59:54 CEST] <jamrial> iive: no need to do that, he initialized the function with INIT_YMM and is not changing it in the middle of it [02:00:21 CEST] <iive> it's just semantics. [02:00:33 CEST] <iive> that's why i said it is a nitpick, nothing major. [02:48:04 CEST] <atomnuker> jamrial: nope, seems like doing 2 loads instead of a single load + vextractf128 is just slightly slower [02:48:22 CEST] <jamrial> i see. alright then [03:05:14 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:5a950f4e32a9: avcodec/cfhd: Fix undefined shift [03:05:14 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07master:6f1d2355a7e4: avcodec/cfhd: Check bpc before setting bpc in context [03:37:55 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:8ead0d380674: avcodec/h264_cabac: Fix CABAC+8x8dct in 4:4:4 [03:37:56 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:ac86dc7716bf: avcodec/h264_mb: Fix 8x8dct in lossless for new versions of x264 [03:37:57 CEST] <cone-971> ffmpeg 03Anton Mitrofanov 07release/3.1:70b714792649: avcodec/h264: Fix mix of lossless and lossy MBs decoding [03:37:58 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:5cd693fd426b: avcodec/htmlsubtitles: Replace very slow redundant sscanf() calls by cleaner and faster code [03:37:59 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:1124df46393b: avcodec/aacdec_fixed: Check s for being too small [03:38:00 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:48b0e94a6cb5: avcodec/wavpack: Fix undefined integer negation [03:38:01 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:feefeb4df1c1: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed) [03:38:02 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:af1f0f815b9a: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation [03:38:03 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:fc30465bcb35: avcodec/hevc_filter: Fix invalid shift [03:38:04 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:46842f6de995: avcodec/cfhd: Fix undefined shift [03:38:05 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:9c52cf95ee35: avcodec/cfhd: Check bpc before setting bpc in context [03:38:06 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07release/3.1:a2d9595a4b4e: Changelog: update [04:04:09 CEST] <cone-971> ffmpeg 03Michael Niedermayer 07n3.1.9:HEAD: avcodec/cfhd: Check bpc before setting bpc in context [10:31:43 CEST] <cone-632> ffmpeg 03Matthieu Bouron 07master:067e42b851a7: checkasm/aarch64: fix tests returning a float [11:20:17 CEST] <wm4> does anyone have an idea why DBL_EPSILON seems to be missing there? https://github.com/mirror/mingw-w64/blob/master/mingw-w64-headers/crt/float… [11:20:24 CEST] <wm4> some filters require this [11:20:33 CEST] <wm4> though it seems C99 should provide it anyway [15:20:47 CEST] <BBB> j-b: what are the plans for vdd17? [16:04:32 CEST] <j-b> BBB 3rd weekend of September, paris. [16:05:26 CEST] <BBB> 16-17? [16:05:40 CEST] <BBB> ok very good [16:06:19 CEST] <BBB> I guess I should look into av1 at this point [16:06:24 CEST] <BBB> but its sooooo slow [16:07:11 CEST] <j-b> no [16:07:17 CEST] <j-b> 23-24 [16:07:39 CEST] <j-b> IBC is 14-19 [16:07:41 CEST] <JEEB> BBB: yea I've been meaning to run some tests :V [16:07:52 CEST] <JEEB> but the speed and not yet specified format [16:08:02 CEST] <JEEB> unless they froze the bit stream while I wasn't looking :D [16:08:21 CEST] <nevcairiel> no they postponed the freeze [16:08:29 CEST] <JEEB> ah [16:08:45 CEST] <JEEB> I only noticed the new MPEG format when I found a dude talking about it @ NHK [16:09:04 CEST] <BBB> ah they have an annexb style format now? [16:09:25 CEST] <BBB> so sad, I like ivf [16:09:36 CEST] <BBB> now we have to do escaping :( [16:09:56 CEST] <BBB> will they at least not require escaping when you use a real container? [16:10:06 CEST] <BBB> i.e. move escaping into the annexb instead of into the codec [16:10:10 CEST] <JEEB> I'd be surprised if that wasn't the case [16:10:21 CEST] <JEEB> we have containers to keep things sane [16:10:35 CEST] <BBB> dude, they messed up so often with h26x that its not even funny anymore [16:10:41 CEST] <JEEB> true [16:10:47 CEST] <nevcairiel> being able to find startcodes in arbitrary streams is an advantage if you want your format to see widespread usage [16:10:47 CEST] <BBB> every time Im like theyll get it right this time and every time its as bad as before [16:11:21 CEST] <JEEB> well, isn't 14496-15's AVCc format pretty much the one where you remove the start code insanity? [16:11:26 CEST] <JEEB> unless it's some other insanity [16:15:01 CEST] <BBB> from what I recall, the escaping is still there [16:15:04 CEST] <BBB> I dont mind the startcode [16:15:08 CEST] <BBB> I mind the escaping :) [16:16:25 CEST] <nevcairiel> well the one exists because of the other [16:16:55 CEST] <nevcairiel> but yeah even mp4 format requires escaping [16:17:43 CEST] <DHE> regarding that QSV ticket just there, I want to reply with "You have it backwards. The -level parameter is to constrain the parameters to meet a maximum, not to raise the parameters to meet a minimum." [16:17:54 CEST] <DHE> That's how it works, right? It's what libx264 does [16:31:55 CEST] <jamrial> ubitux: nasm in djgpp doesn't like section rodata aligned to anything but the default, so unless someone cares enough to find out how to fix x86inc for it, I'd say make that fate client force the usage of yasm [16:35:03 CEST] <BBB> nevcairiel: were going in circles ;) [16:35:29 CEST] <BBB> nevcairiel: I understand all that, but in reasonable containers and/or delivery systems, we dont need escaping (or start codes) [16:35:35 CEST] <BBB> I dont care about start codes [16:35:39 CEST] <BBB> keep them, remove them, whatever [16:35:44 CEST] <BBB> I care about escaping, because its stupid [16:36:16 CEST] <BBB> (in that scenario) [16:36:45 CEST] <BBB> I also understand theres scenarios where escaping is useful, so allow it at the annexb level only for those circumstances, and allow unescaped content in other scenarios :) [17:40:38 CEST] <ubitux> jamrial: mmh okay [18:08:37 CEST] <atomnuker> jamrial: I don't think it would be worth replacing the haddps in BUTTERFLIES_DC [18:09:01 CEST] <iive> atomnuker: don't assume, test it. [18:09:24 CEST] <atomnuker> 2 adds and a few shuffles can't be less performant than an haddps [18:09:31 CEST] <jamrial> atomnuker: two are worth removing, one can probably stay [18:10:06 CEST] <atomnuker> grr, I'll redo the DC twiddles and try to do it like the AC butterflies [18:10:17 CEST] <iive> atomnuker: on my cpu 2 haddps are slower than 2 shifts and 2 addps [18:10:51 CEST] <atomnuker> what CPU do you have? [18:11:36 CEST] <iive> i've complained before, from intel making nice new ops that work slower than equivalent code :D [18:11:41 CEST] <iive> atomnuker: just test it. [18:12:21 CEST] <jamrial> atomnuker: try https://pastebin.com/k4adeh3e [18:12:47 CEST] <jamrial> that's one that can be removed and is going to be faster [18:12:57 CEST] <iive> also, the xor idea is quite good. xor are very fast and your cpu could probably do 4 in a single cycle. [18:13:25 CEST] <atomnuker> oh yeah, that too [18:13:44 CEST] <atomnuker> how does an xor invert the sign? [18:14:09 CEST] <atomnuker> doesn't it just remove the sign bit? I need to invert the sign too [18:14:32 CEST] <iive> "and" would remove the sign, "or" would add it. [18:14:44 CEST] <iive> xor inverts it. [18:14:56 CEST] <iive> 0 x 1 -> 1 [18:15:04 CEST] <iive> 1 x 1 -> 0 [18:15:54 CEST] <jamrial> atomnuker: https://pastebin.com/FGnAaeFs this removes two haddps [18:16:07 CEST] <jamrial> the other can also be removed, probably [18:17:26 CEST] <atomnuker> whoa [18:17:53 CEST] <iive> is that the sound of a benchmark going though the roof :D [18:19:29 CEST] <atomnuker> pretty much, thanks, that saved around 80 decicycles [21:14:05 CEST] <cone-632> ffmpeg 03James Almer 07master:505cb8e390f2: avformat/oggenc: check for stream private data in ogg_free() [22:09:14 CEST] <BBB> michaelni: can you respond faster to the idct-related patches? youre the single person holding them up so Id like to move them forward [22:09:54 CEST] <BBB> michaelni: e.g. for vf_spp, if you want to extend avdct to do that in other ways - go for it, but it shouldnt block idct-related patches as-is because avdct design is totally unrelated to the idct implementations [22:10:38 CEST] <durandal_1707> spp nobody uses [22:19:54 CEST] <kevmark> BBB, looks like push access isn't in the cards for now (according to the M/L) but thanks for the suggestion anyway. I'll just ping my patches once they get stale. [22:20:02 CEST] <BBB> sgtm [22:20:19 CEST] <BBB> Im happy to push patches, and am usually fairly pokeable (?) [22:21:28 CEST] <kevmark> Haha, I'll keep that in mind. Nothing I'm patching is particularly urgent but at the same time nothing particularly complex. I found that the scale2ref filter was nearly useless and I've just been working on stuff from there [22:28:29 CEST] <kevmark> I'm getting ERR_CERT_REVOKED in Chrome 61 for ffmpeg.org's cert. Anybody else? [22:29:28 CEST] <JEEB> it's a startcom cert so I am not surprised [22:29:35 CEST] <jamrial> works fine for me on firefox, but a week or so ago someone mentioned the cert was raising alarms on some ssl checker [22:29:48 CEST] <jamrial> because, yeah, startcom [22:29:51 CEST] <JEEB> yea, mozilla and google will be blocking it soon [22:29:52 CEST] <kevmark> I think I was there for that [22:30:19 CEST] <jamrial> time to hit up letsencrypt i guess [22:30:53 CEST] <JEEB> that's a good idea [22:30:59 CEST] <kevmark> GlobalSign is also an option if the 3 month expiry isn't palatable [22:31:21 CEST] <JEEB> crontab entry should keep the cert nicely around [22:31:39 CEST] <JEEB> so the 3 months thing shouldn't be a problem [22:32:02 CEST] <kevmark> Kinda :P [22:32:31 CEST] <JEEB> the only issues are pieces of software that think that warning you about certs going out in 2-3 months is a good idea :) [22:32:44 CEST] <JEEB> I think outlook or so herp a derp about that? [22:32:45 CEST] <JEEB> some MS tool [22:33:02 CEST] <kevmark> Not sure, I knew a few tools didn't like the chain for LE but that might've been handled now [22:33:20 CEST] <kevmark> I've been using 15 3 * * * root /usr/bin/certbot renew --quiet --renew-hook "/bin/systemctl reload nginx" [22:33:22 CEST] <JEEB> LE's chain should be OK. they're hooking onto another CA which is how they got up [22:33:31 CEST] <JEEB> kevmark: very similar to mine [22:33:45 CEST] <JEEB> also I thought you needed restart for cert updates? [22:34:03 CEST] <kevmark> JEEB, I don't /think/ so, but I'll be honest that I never checked [22:34:07 CEST] <kevmark> I can try real quick [22:34:45 CEST] <durandal_1707> Compn: hey, gonna add gremlin codecs to mplayer? [22:35:18 CEST] <Compn> what codecs ? [22:35:21 CEST] <Compn> my power just died lol [22:35:27 CEST] <kevmark> I tried the nginx plugin for certbot but it doesn't seem to work very well at all. Best way seems to be to point servers to the live certificate locations and then do a certbot renew and restart server [22:36:23 CEST] <JEEB> kevmark: yea I chose the same way. if you have a scriptable DNS thing that's another way [22:36:29 CEST] <JEEB> that way no config needs to be touched [22:36:38 CEST] <durandal_1707> Compn: gdv gremlin digital video and gremlin dpcm, needs demuxer hack probably [22:37:28 CEST] <Compn> wheres codecs and samples? sorry i wasnt paying attention [22:38:02 CEST] <durandal_1707> Compn: on wiki.multimedia.cx use search [22:38:08 CEST] <kevmark> JEEB, According to this ( https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html ) Chrome was going to keep trusting certs until the ones that were already issued had expired. I guess something happened that moved up their timetable. [22:39:22 CEST] <Compn> you know, untrusting certs is going to bite the internet in the ass [22:39:34 CEST] <Compn> so many websites i've been denied to access because of cert time date problems [22:39:49 CEST] <Compn> which is why i dont use chrome anymore. [22:40:08 CEST] <kevmark> Apple and Mozilla both implemented a similar policy fwiw [22:40:26 CEST] <atomnuker> jamrial: fixed most things you mentioned, sent a v2 of the patch [22:41:17 CEST] <jamrial> mozilla apparently still honors certs that were issued before startcom went full retard, though [22:42:07 CEST] <kevmark> So does Apple. But they've both said that they reserve the right to deviate from the plan [22:42:32 CEST] <kevmark> So they could follow suit any day now [22:45:51 CEST] <Compn> so this is how the internet dies, cert wars [22:49:01 CEST] <BBB> michaelni: still sounds like an enum to me :-p so would you like me to add an enum to avdct as public api? [22:49:13 CEST] <BBB> michaelni: I _personally_ prefer the checksum approach TBH [22:49:31 CEST] <kevmark> JEEB, According to this https://nginx.org/en/docs/control.html I think a reload would be sufficient. Potentially zero downtime as the current requests are served with the old certs and new requests get fresh nginx processes with new certs [22:49:32 CEST] <BBB> e.g. a crc of the permtable in vf_spp to check against [22:49:49 CEST] <BBB> michaelni: that wouldnt need changes to avdct and is fairly safe I think, WDYT? [22:51:57 CEST] <JEEB> kevmark: would make sense [22:55:38 CEST] <kevmark> Looks like Apache works in the same way (graceful is reload) https://httpd.apache.org/docs/2.4/stopping.html [22:56:45 CEST] <wm4> would anyone mind if we changed the TLS improper disconnection error messages to verbose level? (CC wbs) [23:03:35 CEST] <wbs> wm4: if you can limit it only to that case and not all tls errors, then +1 from me [23:04:40 CEST] <wm4> yeah I think there's even a special error code for that for gnutls, though didn't check [23:05:57 CEST] <michaelni> BBB, if you like the checksum more, lets go with the checksum. [23:06:09 CEST] <BBB> do you like it also? [23:06:17 CEST] <wm4> also the fucking fuck? https://github.com/FFmpeg/FFmpeg/pull/153#pullrequestreview-45843387 [23:06:23 CEST] <michaelni> iam fine with either [23:06:45 CEST] <BBB> ok [23:09:09 CEST] <BBB> wm4: lol :D how did he get write access to approve pull requests? [23:09:45 CEST] <atomnuker> BBB: approve == "+1" [23:09:56 CEST] <atomnuker> some newfangled github thing [23:11:10 CEST] <wm4> no idea [23:11:18 CEST] <wm4> maybe anyone can become a reviewer [23:14:43 CEST] <durandal_1707> we got hacked! [23:17:24 CEST] <BBB> Ill go spam-approve anything I hate [23:18:28 CEST] <durandal_1707> huh? like what? [23:19:10 CEST] <BBB> durandal_1707: just joking [23:38:29 CEST] <cone-632> ffmpeg 03Rostislav Pehlivanov 07master:7e98da9c4f42: opus_celt: do not use double precision exp2 [00:00:00 CEST] --- Fri Jun 23 2017

1 0

ffmpeg.log.20170622
by burek 23 Jun '17

23 Jun '17

[00:20:19 CEST] <ArsenArsen> Anyone knows why the ubuntu 16.04 FFMpeg doesnt have codecpar in AVStream and avcodec_parameters_from_contex [05:17:30 CEST] <hendry> i need a testsrc but with the current date/time burnt in.. Want to test a streaming setup. Anyone have a clue how to achieve that? [08:36:46 CEST] <MarkG> I am trying to write a script that checks mp3 files and reencodes them only if the sample rate is not 44.1k [08:38:01 CEST] <MarkG> I have started playing with ffprobe (assuming this is the best way?), but got stuck with the syntax. Using [08:38:14 CEST] <MarkG> ffprobe -show_streams -select_streams a format=sample_rate -of default=noprint_wrappers=1:nokey=1 myfile.mp3 [08:50:39 CEST] <thebombzen> MarkG: try this: ffprobe -v error -select_streams a -show_entries stream=sample_rate [08:51:26 CEST] <thebombzen> Or in your case, something like this: ffprobe -of default=noprint_wrappers=1:nokey=1 -select_streams a -show_entries stream=sample_rate [08:53:34 CEST] <thebombzen> thanks? [08:55:12 CEST] <thebombzen> MarkG: try this: ffprobe -of default=noprint_wrappers=1:nokey=1 -select_streams a -show_entries stream=sample_rate [08:55:51 CEST] <thebombzen> also you might want to use -v error, which hides the banners and the "Input #0" crap, and only prints errors to stderr [08:56:09 CEST] <thebombzen> errors like "Is a directory" or "Invalid data found when processing input" or "No such file or directory" etc [08:56:23 CEST] <thebombzen> does that work? [08:57:29 CEST] <Markg1224> Thanks, that worked perfectly [10:05:07 CEST] <Mathieu_> Hello everyone, I currently programming with opencv and I would like to make a live stream from my output. I can currently save this output to a jpg image always update so I thought to create a mjpeg stream with ffmpeg but I don't know how to do that, thank you for your help ! [10:05:30 CEST] <Mathieu_> updated* [12:06:09 CEST] <verb5> hello everyone [12:06:33 CEST] <verb5> i need help i am trying to capture live stream with /usr/local/bin/ffmpeg -hwaccel cuvid -c:v mpeg2_cuvid -c:a mp2 -i "http://127.0.0.1:9981/stream/service/6359f06817a7d135314bf821ea47ad69?ticke…" -c:v h264_nvenc -preset llhq -c:a copy "otest21.mp4" [12:06:47 CEST] <verb5> but only the audio stream is recorded [12:07:00 CEST] <verb5> any idea why ffmpeg maps only the audio stream ? [12:07:14 CEST] <thebombzen> are you sure the input stream is mpeg2? [12:07:36 CEST] <thebombzen> I'd recommend removing "-hwaccel cuvid -c:v mpeg2_cuvid -c:a mp2" and see what happens [12:07:52 CEST] <thebombzen> and once you see what happens, do this: [12:08:16 CEST] <verb5> ok sorry [12:10:08 CEST] <verb5> what i am trying is load as less as possible the cpu that's why i am trying to use hwaccelerated decoder [12:44:51 CEST] <styler2go> Hey everyone.. I guess this is the best channel where i can ask for help.. So, i have a camera which stores gps informations inside the video file. Can anyone think of a way to export it or to find out where in the video file it is being stores? [12:45:39 CEST] <styler2go> Maybe just a hint where i could ask for help regarding this [12:47:28 CEST] <styler2go> ffprobe output says this: https://p.styler2go.de/438538/ Where the subtitle stream looks pretty interesting [12:50:02 CEST] <Nacht> Looks like Stream 0:2 is your GPS data [12:50:19 CEST] <styler2go> Any idea how i could open it to look into it? [12:50:37 CEST] <styler2go> Just selecting a subtitle in vlc palyer doesn't show anything [12:52:51 CEST] <Nacht> Perhaps extracting them as subtitle. [12:53:13 CEST] <Nacht> ffmpeg -i Movie.mkv -map 0:s:0 subs.srt [12:53:17 CEST] <styler2go> can i just use ffmpeg like ffmpeg -i video.mp4 subtitlle.ass [12:53:17 CEST] <Nacht> see what that gives [12:53:24 CEST] <styler2go> ah nice, will try [12:54:04 CEST] <styler2go> error while decoding stream [12:54:59 CEST] <styler2go> https://p.styler2go.de/4627686/ looks like that [12:56:24 CEST] <Nacht> Not really sure what else to do then [12:57:15 CEST] <Nacht> Perhaps the others have a solution [12:57:16 CEST] <styler2go> Any idea where i could ask in irc? [12:58:24 CEST] <Nacht> This would be the correct place [13:02:14 CEST] <furq> you should at least be able to extract it with mp4box [13:02:32 CEST] <furq> mp4box -raw 3 src.mp4 [13:02:40 CEST] <furq> idk whether that'll give you a file you can do anything with [13:02:49 CEST] <styler2go> gpac? [13:02:51 CEST] <furq> yeah [13:04:26 CEST] <styler2go> [isom] not enough bytes in box text: 8 left, reading 51 (file ..\..\src\isomedia\box_code_3gpp.c, line 339) [13:04:52 CEST] <styler2go> Error opening file .\M0070116.MP4: Invalid IsoMedia File [13:05:00 CEST] <furq> nice [13:05:19 CEST] <furq> it might be -raw 2 [13:05:27 CEST] <furq> i forget whether mp4box starts numbering at 0 or 1 [13:05:38 CEST] <furq> doesn't sound like it'll work though [13:06:02 CEST] <styler2go> it's the same for any number i try: https://p.styler2go.de/8553466/ [13:06:10 CEST] <furq> yeah i figured that'd be a generic error [13:06:51 CEST] <furq> well i suspected that tomtom were just shoving binary data into a stream marked as mov_text, which would be awful [13:07:00 CEST] <furq> but i guess it's just spitting out busted mp4s [13:07:02 CEST] <styler2go> gopro and DJI does that to for their video files.. i migh tjust try to find some informaiton about them first maybe [13:07:06 CEST] <furq> i can't decide if that's less awful [13:07:26 CEST] <furq> you could maybe try remuxing it [13:07:45 CEST] <bencoh> gpac might be "picky" [13:07:47 CEST] <furq> with ffmpeg [13:07:52 CEST] <furq> or l-smash [13:08:14 CEST] <bencoh> (or "strict" depending on your view on this) [13:08:24 CEST] <styler2go> https://github.com/stilldavid/gopro-utils maybe that can help somehow hmm [13:08:37 CEST] <styler2go> it uses ffmpeg to export something too [13:09:51 CEST] <furq> well that's just a data track [13:10:07 CEST] <furq> yours shows up as a subtitle track, so i guess tomtom are doing some different kind of hell [13:10:22 CEST] <styler2go> maybe they have the binary in a subtitle track [13:10:27 CEST] <furq> maybe [13:10:38 CEST] <styler2go> how could i export the subtitle as a binary? [13:10:51 CEST] <furq> well that was what that mp4box command was supposed to do [13:10:56 CEST] <styler2go> oh [13:11:06 CEST] <styler2go> what about the command they show on the github readme [13:11:08 CEST] <furq> i'm not sure if you can do that with ffmpeg if the stream is flagged incorrectly [13:11:11 CEST] <styler2go> ffmpeg -y -i GOPR0001.MP4 -codec copy -map 0:m:handler_name:" GoPro MET" -f rawvideo GOPR0001.bin [13:11:15 CEST] <styler2go> is this of any help? [13:11:21 CEST] <furq> you could try that [13:11:29 CEST] <furq> except it'd be -map 0:2 [13:11:31 CEST] <styler2go> Ok, just need to find the nadler name [13:11:34 CEST] <styler2go> ah, nice [13:12:00 CEST] <styler2go> it does export something [13:12:00 CEST] <furq> genuinely curious if that works now [13:12:24 CEST] <styler2go> got a 754mb file out of it o.O [13:12:49 CEST] <furq> lol [13:13:02 CEST] <furq> yeah i did notice ffprobe marked it as 6289kbps mov_text [13:13:07 CEST] <furq> i guess it was true after all [13:13:17 CEST] <styler2go> well it's a lot of informational text [13:13:33 CEST] <styler2go> 18 minutes each second gps, temperature, gyro data etc. [13:13:38 CEST] <styler2go> but 754mb i dunno [13:13:53 CEST] <furq> yeah that's a fair old amount of text [13:14:43 CEST] <furq> i've got 18 months of #ffmpeg logs here that are only 36MB [13:14:53 CEST] <furq> and this channel is poppin' [13:15:38 CEST] <styler2go> the gopro has 3-axis gyro at 400 Hz.. that's a lot at least [13:16:02 CEST] <furq> oh right [13:16:38 CEST] <furq> yeah that'll add up fast [13:17:11 CEST] <styler2go> and a 3-axis accelerometer at 200 Hz and some more stuff.. maaaaybe it's that much.. wondering how i can chekc that now [13:17:26 CEST] <styler2go> should i just be that guy and try the gopro converter on the tomtom? [13:19:39 CEST] <bencoh> I'd go xxd and look for 0s and/or redundancy, but ... :) [13:22:48 CEST] <furq> i'd be shocked if tomtom used a common format [13:23:03 CEST] <furq> even if "common" means you need some rando on github's tool to extract it [13:23:10 CEST] <styler2go> I think neither of those are "common" [13:23:37 CEST] <furq> never underestimate the capacity of companies making consumer video equipment to invent their own fresh piece of shit [13:23:41 CEST] <styler2go> Is there some official way to store something like those datas in a mp4 file? like, are there regulations/standards on such? [13:23:57 CEST] <furq> well gopro just stores it as a data track [13:24:10 CEST] <furq> and i've seen other cameras storing it as a timecode track [13:24:21 CEST] <styler2go> and that's not too off? [13:24:29 CEST] <furq> idk if i'd call either of them correct [13:24:34 CEST] <furq> probably better than a subtitle track though [13:24:46 CEST] <styler2go> yeah.. datat soudns about right at least [13:24:47 CEST] <furq> a data track is supposed to just be opaque data so you can throw anything you want in there [13:25:02 CEST] <furq> but obviously there's no generic way to read it [13:25:25 CEST] <styler2go> seems like i have no way of obtaining that data [13:30:16 CEST] <furq> probably just search for tomtom on github [13:30:45 CEST] <furq> i found something that processes "ttbin" files off one of their gps watches [13:30:51 CEST] <furq> https://github.com/ryanbinns/ttwatch [13:31:14 CEST] <styler2go> wow nice [13:31:14 CEST] <furq> if you're very lucky and you've been a very good boy all year then it'll be the same format [13:31:28 CEST] <styler2go> i'll give it a shot [13:31:40 CEST] <styler2go> is this someting i nee dto build? [13:31:45 CEST] <furq> looks like it [13:31:46 CEST] <styler2go> ok i see [13:32:04 CEST] <styler2go> hmm [13:32:17 CEST] <styler2go> wonder if it works on windows somehow [13:35:55 CEST] <furq> oh hey [13:35:58 CEST] <furq> https://developer.tomtom.com/camera-media-server/sensor-data-format [13:36:04 CEST] <furq> this looks promising [13:36:09 CEST] <styler2go> wow [13:36:15 CEST] <styler2go> don't tell me they documented it [13:37:37 CEST] <styler2go> i wouldn't have imaginated that hey even have a sdk [13:38:18 CEST] <furq> i feel bad for calling them shits now [13:38:22 CEST] <furq> sorry tom [13:38:24 CEST] <furq> and sorry tom [13:38:32 CEST] <styler2go> they still use it as subtitle stream [13:42:12 CEST] <styler2go> https://github.com/Rupan/tomtom oh look [13:42:27 CEST] <styler2go> oh well it's just firmware stuff :( [13:50:45 CEST] <bencoh> looks like there's everything you need on this sdk page [13:51:40 CEST] <styler2go> Yeah.. But my knowledge is not good enough to actually use it to be honest.. i do have the bin file i guess and i iknow how the data is in this bin file but i never worked with such a "low level" stuff.. [14:51:09 CEST] <ArsenArsen> How can I fix [swscaler @ 0x7f0d580a7060] Warning: data is not aligned! This can lead to a speedloss, I am using the libraries in my C++ code, and even though I get this printed the resulting file is perfectly fine [14:51:40 CEST] <kerio> speed loss, not errors in the data [14:54:29 CEST] <furq> ArsenArsen: https://github.com/FFmpeg/FFmpeg/blob/03ce71e4a1187340720e1569ac96c285c145a… [14:55:18 CEST] <ArsenArsen> o.O [14:56:24 CEST] <ArsenArsen> so, it's probably my source buffer, which is comes from QImage's bits() [14:58:03 CEST] <ArsenArsen> is coming* [15:02:31 CEST] <kerio> is it fast enough for your purpose? [15:02:48 CEST] <DHE> if you're using av_frame_get_buffer, are you specifying a large enough alignment value? [15:03:02 CEST] <kerio> furq: hold on, why isn't warnedAlready checked as the first step? [15:03:38 CEST] <furq> why are you asking me [15:05:18 CEST] <ArsenArsen> DHE, I do it to allocate the buffer, and I use 32 [15:05:23 CEST] <furq> actually that makes sense [15:05:33 CEST] <furq> HAVE_MMXEXT is guaranteed to short-circuit out more often than warnedAlready [15:05:44 CEST] <furq> because warnedAlready is only set if HAVE_MMXEXT is true [15:07:16 CEST] <ArsenArsen> av_frame_get_buffer(out->frame, 32); is what I use after allocating the frame [16:45:55 CEST] <hiihiii> hello [16:47:05 CEST] <hiihiii> I've been trying a command to get thumbnails at specific times but the images always come offset [16:47:17 CEST] <hiihiii> for instance [16:47:47 CEST] <hiihiii> ffmpeg -i input.mp4 -vf fps=1/30 img%03d.png [16:48:55 CEST] <hiihiii> on a 60fps 02:30 long input video will result in 6 images [16:49:29 CEST] <hiihiii> the first starting at 00:00:14.983 [16:50:09 CEST] <hiihiii> and the 2nd at 00:00:44.983 (1st + 30sec) [16:51:34 CEST] <hiihiii> Question: I'd like to know if it's possible to get images at the exact times specified (or at least be very close) [16:51:39 CEST] <hiihiii> i.e. [16:51:40 CEST] <furq> !filter select @hiihiii [16:51:40 CEST] <nfobot> hiihiii: http://ffmpeg.org/ffmpeg-filters.html#select_002c-aselect [16:52:09 CEST] <furq> the fifth example [16:53:50 CEST] <hiihiii> 00:00:30, 00:01:00, 00:01:30 ...etc [16:54:17 CEST] <hiihiii> I tried ffmpeg -i input.mp4 -vf "setpts=PTS-STARTPTS,fps=1/30" img%%03d.png [16:54:22 CEST] <hiihiii> but didt' work [16:54:28 CEST] <hiihiii> so with select [16:56:02 CEST] <hiihiii> ffmpeg -i input.mp4 -vf select='not(mod(n\,3600))' img%%03d.png [16:57:47 CEST] <furq> 900 if it's 30fps [16:58:23 CEST] <hiihiii> ? I got over 6000 files [16:58:35 CEST] <hiihiii> maybe I should add fps=1 ? [17:00:29 CEST] <furq> you might want to use t and prev_selected_t then [17:01:15 CEST] <h0par> hi [17:03:07 CEST] <hiihiii> furq: -vf "select='not(mod(n\,900))',fps=1/30" img%%03d.png did the job [17:03:39 CEST] <hiihiii> not sure why -vf select='not(mod(n\,900))' alone wouldn't work [17:03:49 CEST] <furq> it should work [17:04:02 CEST] <furq> fps doesn't do anything there as far as i can tell [17:05:04 CEST] <hiihiii> no bro I just get a huge number of files [17:07:42 CEST] <furq> oh right [17:07:44 CEST] <furq> add -vsync 0 [17:08:18 CEST] <hiihiii> and what does that do? [17:09:01 CEST] <furq> -vsync 1 will duplicate frames [17:09:10 CEST] <furq> obviously you don't want that [17:10:08 CEST] <hiihiii> ok [17:13:25 CEST] <hiihiii> it did work thx for the advice [18:59:35 CEST] <styler2go> Is there any documentation to lavfi except for https://www.ffmpeg.org/ffmpeg-devices.html#lavfi ? [18:59:52 CEST] <c_14> the doxygen [19:00:07 CEST] <c_14> https://ffmpeg.org/doxygen/trunk/group__lavfi.html [19:10:39 CEST] <DHE> styler2go: there's some examples in doc/examples [19:59:52 CEST] <ChocolateArmpits> So I asked yesterday about encoding-transmission-playback latency. It seems a large part of what I had was caused by an older Decklink card that itself introduces around 120ms of latency. When removed from the result, then the overall latency is only 100-120ms. [20:02:23 CEST] <ChocolateArmpits> Newer Decklink cards have the latency down to 1 frame if we go by information from blackmagic. [20:02:43 CEST] <JEEB> yea, calculating that latency can get fun :P [20:12:11 CEST] <ChocolateArmpits> the setup had a camera shoot a timecode counter along with the output and then taking screenshots the latency would get computed [20:12:30 CEST] <ChocolateArmpits> the output as in the stream output via network [21:00:31 CEST] <RandomCouch> I have a bit of a weird question for you guys [21:01:06 CEST] <RandomCouch> So, I have an android application that can record gameplay of my mobile game, I want to then append another video to that recorded video [21:01:17 CEST] <RandomCouch> the problem is every video that gets recorded does not have a fixed frame rate [21:01:52 CEST] <RandomCouch> is there a way to adapt my second video (that I want to append to the game recording video) to the first one's dynamic frame rate? [21:02:06 CEST] <RandomCouch> It uses h264 Constrained Baseline codec [21:02:13 CEST] <RandomCouch> I'm not sure what constrained baseline means [21:04:01 CEST] <kerio> mux to mpegts, concatenate files, mux back? idk [21:13:33 CEST] <DHE> constrained baseline means a lot of encoder features are forced off [21:13:52 CEST] <DHE> but variable framerate containers exist. mpegts is one. MKV is another [21:15:35 CEST] <kerio> furq do i buy the radioheds [21:16:03 CEST] <kerio> the price goes from 13¬ for MP3 320 to 19¬ for 24-bit wav [21:16:04 CEST] <kerio> D: [21:18:32 CEST] <ChocolateArmpits> 24bit audio has no practical use for listening purposes, eardrums will be blown before the full dynamic range is reached [21:21:50 CEST] <durandal_1707> huh [21:29:48 CEST] <kepstin> on the other hand, I'd probably buy the lossless copy just on principle [21:30:28 CEST] <kerio> ye [21:30:34 CEST] <kerio> but 24-bit costs more than 16 D: [21:30:46 CEST] <kerio> like 3¬ more [21:31:28 CEST] <kerio> fuck it i'll... obtain it... somewhere else [21:32:14 CEST] <kepstin> the real question is whether there's any difference in the mastering between the 16 and 24bit copies. If they're the same master (e.g. both have clipping or have compressor/limitor applied) then no point in getting the 24bit at all [21:32:33 CEST] <durandal_1707> yea [21:32:54 CEST] <durandal_1707> even 16bit [21:38:36 CEST] <furq> the real question is "should i pay 19 euros for a reissued radiohead album" [21:38:39 CEST] <furq> and the answer is no [21:38:47 CEST] <furq> same as it would be without the word reissued [21:43:23 CEST] <kerio> hey furq [21:43:40 CEST] <kerio> you're my man of war [21:48:46 CEST] <furq> are you calling me a jellyfish [21:57:35 CEST] <RandomCouch> I'm trying to change the major brand metadata on a mp4 file [21:57:38 CEST] <RandomCouch> and it doesn't seem to work [21:58:00 CEST] <RandomCouch> I'm using the command ffmpeg -i myVideo.mp4 -metadata major_brand="mp42" out.mp4 [21:58:11 CEST] <RandomCouch> but nothing is changing [22:07:55 CEST] <JodaZ> RandomCouch, theres a -brand flag, did you try that? [22:08:05 CEST] <RandomCouch> I did not, thank you I will try now [22:08:38 CEST] <RandomCouch> that worked! JodaZ [22:25:05 CEST] <kerio> furq: does this rerelease replace the old ok computer tho [22:25:07 CEST] <kerio> i am confus D: [23:53:22 CEST] <gwohl1> I am trying to encode a 4096x4096 ProRes 422 source to FFV1, but when I do, I get the following output repeatedly from FFmpeg: 'Cannot allocate worst case packet size, the encoding could fail'. Tried both 3.3.2 and today's git master, both builds do this. Any idea if this is bad or if I can safely ignore? [23:54:11 CEST] <c_14> ignore it [23:54:25 CEST] <c_14> (unless ffmpeg actually aborts) [23:54:50 CEST] <gwohl1> c_14 thank you. Is it reporting this because of the frame size? [23:55:37 CEST] <c_14> yeah [23:55:53 CEST] <c_14> it just means that if the frame is basically uncompressable it won't fit in the allocated buffer [23:56:15 CEST] <c_14> because width*height*37*4 + buffer is > INT_MAX [00:00:00 CEST] --- Fri Jun 23 2017

1 0

ffmpeg-devel.log.20170621
by burek 22 Jun '17

22 Jun '17

[00:51:22 CEST] <jamrial> there, some merges for nasm love on the ml [00:58:33 CEST] <J_Darnley> Ha. I was half working on similar too [01:01:25 CEST] <atomnuker> jamrial: been waiting for those, they all LGTM [01:02:24 CEST] <atomnuker> "generating dependency information as a sideeffect of assembling, thus cutting build times in half" [01:02:28 CEST] <atomnuker> seriously? [01:03:04 CEST] <JEEB> :D [01:03:26 CEST] <atomnuker> (is that compared to nasm without the second patch or to current yasm?) [01:10:34 CEST] <iive> atomnuker: assembly compilation is not something that takes much time... [01:10:46 CEST] <JEEB> tell that to some of the stuff in x265 [01:10:58 CEST] <iive> it's C++ [01:11:02 CEST] <JEEB> there's asm [01:11:08 CEST] <iive> intrinsics? [01:11:08 CEST] <JEEB> I meant the actual yasm execution [01:11:26 CEST] <JEEB> x265 actually used asm so that yasm needed its hash table largened [01:11:57 CEST] <JEEB> https://github.com/yasm/yasm/commit/e32ff2c2abc22532a58c9b687d922500d23fd709 [01:11:58 CEST] <iive> ok, at least one thing they've done right [01:30:45 CEST] <Gramner> oh yeah, that commit. I got tired of yasm being slow as hell so I went and made it 20x faster [01:41:47 CEST] <iive> what is that hash used for? [01:42:09 CEST] <iive> branchs ? [01:46:51 CEST] <Gramner> macros invocation and stuff like that. and since almost all sse instructions are overloaded as macros in x86inc that ends up being a lot [01:47:26 CEST] <iive> i see. [01:54:42 CEST] <cone-135> ffmpeg 03Luca Barbato 07master:19bf50406ebf: configure: Move up the avbuild directory creation [02:21:58 CEST] <BBB> JEEB: have you never built ffmpeg? [02:22:14 CEST] <BBB> JEEB: without that patch, building the vp9 inverse transform also takes several minutes [02:22:19 CEST] <BBB> its not just x265 ;) [02:25:41 CEST] <iive> well, who needs more than 31 macros? [02:26:50 CEST] <atomnuker> I'll tell you who [02:26:56 CEST] <atomnuker> people who use avx2, that's who [02:27:07 CEST] <atomnuker> 8 floats... my head hurts [02:27:08 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:e95fcfe8fb28: avcodec/lpc: signed integer overflow in compute_lpc_coefs() (aacdec_fixed) [02:27:09 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:5443c4bdf482: avcodec/mpeg4videodec: Fix overflow in virtual_ref computation [02:27:10 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:fdfbcbdd1487: avcodec/hevcdec: Check beta and tc offset in hls_slice_header() [02:27:11 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:d7b3d5c3f2e2: avcodec/hevc_filter: Fix invalid shift [02:27:12 CEST] <cone-135> ffmpeg 03Michael Niedermayer 07master:70a7df049c41: avcodec/mpegvideo: Use intra_scantable in dct_unquantize_h263_intra_c() [02:38:06 CEST] <iive> atomnuker: that was kind of rethorical question, like who needs more than 640KB of ram... [02:38:57 CEST] <atomnuker> I'll tell you who [02:39:06 CEST] <atomnuker> people who use avx2, that's who [02:39:41 CEST] <iive> :D [04:19:33 CEST] <thebombzen> it appears that some sort of fuzzing is going on [04:19:37 CEST] <thebombzen> that's a lot of bug fixes [04:28:20 CEST] <rcombs> 0.o iOS 11 supports Opus [04:28:23 CEST] <rcombs> (in CAF) [04:28:38 CEST] <rcombs> (in Podcasts.app) [04:45:42 CEST] <jamrial> rcombs: got a sample? would be nice to support i guess [04:45:58 CEST] <rcombs> https://hetzel.net/2017-06-12/ios-11-opus-support-in-podcast-feeds/ [08:09:04 CEST] <cone-583> ffmpeg 03Memphiz 07master:998609ddb888: aarch64: vp9: Fix assembling with Xcode 6.2 and older [08:09:04 CEST] <cone-583> ffmpeg 03Memphiz 07master:9e85c5d6a7e6: aarch64: vp9 16bpp: Fix assembling with Xcode 6.2 and older [13:41:27 CEST] <durandal_1707> i will work on atrac9 only if somebody pays me [14:07:33 CEST] <RiCON> rcombs: "Podcasts.app supports Opus playback, if you claim the file is AAC, although its CAF containing Opus." lol [14:09:56 CEST] <ritsuka> iOS 11 added opus and flac at the system level, so every app can decode it if you avoid the existing file type checks [14:11:04 CEST] <durandal_1707> it have strange extradata [14:11:37 CEST] <ritsuka> I have not found any documentation for the extradata [14:12:32 CEST] <thebombzen> ios 11 finally added flac and opus support? well finally [14:12:59 CEST] <ritsuka> opus probably for webrtc [14:14:04 CEST] <atomnuker> did they write their own decoder or did they use libflac/opus? [14:18:03 CEST] <thebombzen> probably their own. NIE [14:18:08 CEST] <thebombzen> err NIH [14:20:54 CEST] <atomnuker> until I see proof I shall still consider ffopusenc to be the first and only non-libopus based thing out there [14:23:29 CEST] <ritsuka> symbols names look likes standard libflac/libopus [14:25:43 CEST] <durandal_1707> ritsuka: you have binary of ios decoder? [14:26:11 CEST] <ritsuka> I checked the macOS one [15:00:17 CEST] <cone-485> ffmpeg 03Ronald S. Bultje 07master:42dd1434bf6a: mdec: use correctly permutated quant matrix for dequantization. [15:01:58 CEST] <cone-485> ffmpeg 03Ronald S. Bultje 07master:e639d09199dd: mdec: stop preferring the simple IDCT. [15:04:42 CEST] <BBB> J_Darnley: do you have a tree or patches for the outstanding ones so I can address michaelnis issues/comments/review? [15:04:49 CEST] <BBB> J_Darnley: I dont remember which ones are outstanding [15:31:36 CEST] <J_Darnley> BBB: I'll rebase and push [15:31:43 CEST] <BBB> push? [15:31:47 CEST] <BBB> oh to gitlab [15:31:49 CEST] <BBB> :) [15:31:54 CEST] <J_Darnley> yes [15:32:02 CEST] <BBB> ty! [15:33:40 CEST] <BBB> michaelni: any idea where to look for that rgb bug? [15:33:58 CEST] <J_Darnley> BBB: mpeg2_asm8 [15:34:40 CEST] <BBB> ah cool, so 3 patches remaining [15:34:44 CEST] <J_Darnley> yes [15:40:12 CEST] <jamrial> ritsuka: you have the High Sierra beta? think you can create a couple varied opus-in-caf files? mainly channels other than mono [15:41:05 CEST] <jamrial> might help identifying what the contents of the extradata are. the only obvious one is samplerate [15:41:40 CEST] <jamrial> for some reason they didn't just dump the usual Ogg OpusHead like matroska and mp4 do [15:42:48 CEST] <atomnuker> jamrial: if you're familiar with ogg could you take a look why https://jmvalin.ca/misc_stuff/chain_works.opus fails to decode correctly? [15:43:12 CEST] <atomnuker> its a chained opus file, used by online radios [15:43:35 CEST] <atomnuker> (we support chained vorbis, I tried to look at why we do so I could replicate it but couldn't) [15:47:06 CEST] <BBB> ah fixed, easy [16:11:37 CEST] <BBB> atomnuker: chained opus, nooooooooooooooo [16:22:02 CEST] <atomnuker> then there's also the fact that our opus muxer doesn't code pre-skip properly [16:22:41 CEST] <atomnuker> *post-skip, not pre-skip, I think at least pre-skip is coded correctly [16:25:43 CEST] <durandal_170> ritsuka: can you create stereo file? [16:29:37 CEST] <ritsuka> yes [16:55:16 CEST] <durandal_170> atomnuker: how is noiseredux going? [16:57:22 CEST] <ritsuka> durandal_170 jamrial : https://www.dropbox.com/s/si70wf7cpxcqnni/opus-caf.zip?dl=0 mono and stereo, I couldn't create any other channel layout with afconvert [16:59:49 CEST] <durandal_170> lol, than just ignore extradata and it should work [17:16:03 CEST] <jamrial> durandal_170: yeah, but i guess one of those values is pre-skip, so while working skipping extradata is not "ideal" [18:17:36 CEST] <atomnuker> durandal_170: I'll work on it tonight after I finish fft15 asm [18:17:40 CEST] <atomnuker> so close now [18:17:52 CEST] <atomnuker> what's the best way of doing strided writes? [18:18:39 CEST] <atomnuker> e.g. first 8 bytes go to stride*(2), next ones to to stride*(2), etc. [18:19:13 CEST] <atomnuker> I think I remembered seeing an instruction which handled that but I could be mistaken [18:20:24 CEST] <nevcairiel> i always thought there is only load instructions for that pattern [18:21:15 CEST] <iive> atomnuker: hum? [18:21:35 CEST] <iive> 8 bytes are 2 floats? [18:22:11 CEST] <jamrial> sounds like scatter, but that's avx512 [18:22:17 CEST] <nevcairiel> fft always operates in two float elements, real and imaginary [18:22:35 CEST] <atomnuker> yep, 2 floats [18:22:50 CEST] <iive> ssse3 had something similar [18:23:13 CEST] <atomnuker> I guess I'll have to extract and do 4 movs [18:23:37 CEST] <jamrial> oh, you can use extractps then, sse4 [18:24:06 CEST] <atomnuker> that extracts 1 float value, I need 2 [18:24:26 CEST] <atomnuker> extractpd? [18:24:38 CEST] <jamrial> for two there's mov[lh]ps, but that only works on xmm regs afaik [18:24:39 CEST] <atomnuker> huh, there isn't an extractpd [18:25:18 CEST] <iive> movhps movlps [18:25:48 CEST] <jamrial> for ymm i don't think you can extract 8 bytes from an arbitrary position of the reg. Gramner complained about the lack of such functinality once [18:26:38 CEST] <iive> yeh, and it's sse1 [18:26:47 CEST] <Gramner> correct, you can't [18:26:49 CEST] <jamrial> same with extracps now that i check. only xmm [18:27:00 CEST] <Gramner> need to first vextractf128 [18:27:40 CEST] <gh0st__> That's unfortunate [18:29:18 CEST] <gh0st__> I was looking such thing all over avx2 spec, but didn't find anything. [18:36:38 CEST] <dcherednik> Hi. Can someone read fft function in libavcodec/dcaenc.c? Is it correct implementation? [18:38:17 CEST] <atomnuker> dcherednik: that's actually a duplicated function [18:38:23 CEST] <atomnuker> dcaenc uses an integer mdct [18:38:31 CEST] <atomnuker> *fft [18:38:54 CEST] <atomnuker> we already have an integer fft if you switch a define before including libavcodec/fft.h [18:39:06 CEST] <dcherednik> Yes, and i want to replace it with common function [18:39:17 CEST] <atomnuker> ah, cool, I was also wanting to do that [18:39:24 CEST] <dcherednik> but got a bit different result [18:39:25 CEST] <atomnuker> it used the fft for analysis only, right? [18:39:32 CEST] <dcherednik> right [18:40:31 CEST] <atomnuker> I'd suggest logging the coefficients you get from one function vs the other and plotting them against each other [18:40:39 CEST] <atomnuker> if they look similar they'll be right [18:41:03 CEST] <atomnuker> I guess the fft inside dcaenc used a different approximation [18:41:24 CEST] <atomnuker> jamrial: I'm quite annoyed by the fact I can't do [outq + strideq*(1 + %8)] [18:42:48 CEST] <atomnuker> why is nasm telling me I have an invalid effective address, it should know better to resolve the argument of the macro [18:49:06 CEST] <Gramner> that should work? [18:49:24 CEST] <Gramner> assuming the resulting multiplier is 1,2,4 or 8 [18:49:30 CEST] <iive> atomnuker: I think there are just *1 *2 *4 [18:49:49 CEST] <iive> *8 too? [18:50:12 CEST] <Gramner> yes [18:50:15 CEST] <iive> definitely not mmsize [18:50:46 CEST] <atomnuker> oh, I didn't know you could only multiply by a power of two [18:51:00 CEST] <atomnuker> I need to multiply by 3 so that's out the window then [18:51:08 CEST] <iive> it's hidden shift [18:52:16 CEST] <nevcairiel> you can cheat by using an extra addition, but you already have one in there, so thats out too [18:52:32 CEST] <iive> is stride a constant? [18:52:56 CEST] <iive> i guess not, if you keep it in register [19:02:15 CEST] <jamrial> atomnuker: if you need to do stride * 3, you need to store that value in a separate register using for example "lea stride3q, [strideq+strideq*2]" [19:02:47 CEST] <iive> or increment outq [19:03:11 CEST] <jamrial> "lea stride3q, [strideq*3]" also works, as nasm/yasm will convert it into the above before assembly [19:11:57 CEST] <atomnuker> have to use 4 LEAs, no choice [19:15:49 CEST] <atomnuker> oh come on [19:17:05 CEST] <atomnuker> shit, I need to also multiply the stride and keep it in a separate register [19:22:00 CEST] <cone-485> ffmpeg 03Paul B Mahol 07master:664ac7c5e2e9: avfilter/af_stereotools: add forgotten break [20:01:53 CEST] <atomnuker> 20% increase in opus decoding performance [20:02:05 CEST] <atomnuker> I still need to clean it up though [20:04:55 CEST] <iive> total?! [20:05:12 CEST] <iive> that's massive! [20:05:12 CEST] <atomnuker> yep [20:19:40 CEST] <durandal_170> ritsuka: i cant fetch it [20:22:24 CEST] <jamrial> durandal_170: https://0x0.st/lkh.caf that's the stereo one [20:22:52 CEST] <jamrial> durandal_170: https://0x0.st/ldr.caf and the mono [20:23:46 CEST] <jamrial> durandal_170: there are apparently five values in the extradata for these opus-in-caf files. first one seems to always be 2048, second is sample rate (fixed to 48000 and not original sample rate as in OpusHead it seems), third is the same as frames_per_packet from the desc chunk, fourth seems to always be -1000, and fifth is channel count [20:24:10 CEST] <jamrial> no idea what 2048 and -1000 are, but most likely not pre-skip [20:24:51 CEST] <jamrial> so unless you find something i didn't notice, i guess skipping extradata is the way to go [20:49:12 CEST] <dcherednik> atomnuker: It looks like fft inside dcaenc works wrong with DC. Plots looks similar, but shifted for one line. If disable windowing, put DC - I get correct result in case of common ffmpeg implementation, and something strange with long tail in case of dca fft. [20:50:19 CEST] <atomnuker> put dc? from where? [20:50:48 CEST] <atomnuker> (also could you just change the implementation to use float FFTs? it'll make working with it far easier) [20:52:00 CEST] <dcherednik> I have already implemented fixed and fixed_32 rdft, tests passes. [20:52:01 CEST] <durandal_170> why? [20:54:38 CEST] <dcherednik> Just emulate dc input for fft, I expect to get x*N in first real output. [20:58:13 CEST] <atomnuker> durandal_170: because you don't have to do weird scaling everywhere [21:06:22 CEST] <tdjones> atomnuker: Have you been able to make any more progess on the opus psy transient detection? [21:09:35 CEST] <atomnuker> no, had other things to do [21:31:49 CEST] <ubitux> jamrial: about the aacpsdsp fate tests; do you want me to apply with your patches separated or you prefer to squash them in my original commit with signed-off + desc of the changes [21:32:06 CEST] <jamrial> squash them, yeah [21:32:10 CEST] <ubitux> ok [21:32:16 CEST] <ubitux> i won't integrate your latest test though [21:32:22 CEST] <ubitux> you can still add it on top [21:32:25 CEST] <ubitux> i'll just pick your fixes [21:32:30 CEST] <jamrial> alright [21:32:47 CEST] <ubitux> sorry for the delay btw, i'm still fighting with these boards and their shitty kernel support [21:33:24 CEST] <ubitux> i'll send the final patchset tmr and probably apply in the week-end or next week [21:33:43 CEST] <jamrial> ubitux: btw, i'm about to push the build system libav cherry picks i sent to the ml. that includes making nasm the default, so you might want to change your nasm fate client to instead force yasm after that :p [21:34:06 CEST] <ubitux> sure [21:34:25 CEST] <ubitux> i need to catchup with the ml [21:39:12 CEST] <jamrial> ubitux: i'd like to get back to merges as well, whenever you have time. it would be ideal to get to the major bump before ~4 months since the last release have passed [21:39:21 CEST] <jamrial> we're relatively close and there are a lot of noops ahead (bitstream reader commits, or cherry picked stuff) [21:40:16 CEST] <ubitux> well the question is what to do with dash [21:40:27 CEST] <ubitux> the guy finally answered me to say he'll have a look when he has time [21:40:36 CEST] <ubitux> but it's been days/weeks now [21:40:38 CEST] <ubitux> so.. [21:40:44 CEST] <jamrial> for things that we have already implemented in a different way and the person that wrote them can't be reached, lets just favor the merged version and not waste time with it [21:40:59 CEST] <jamrial> and yeah, if they take a lot of time then IMO lets do the same [21:41:35 CEST] <ubitux> i agree, but i'd like to test anyway, and testing dash lazyness++ [21:42:51 CEST] <ubitux> i'm ok spending days doing mostly monkey merging and noops [21:43:03 CEST] <ubitux> but spending days trying to figure out how to test the code is really annoying [21:43:34 CEST] <ubitux> unless we're almost 1 on 1 with libav [21:44:42 CEST] <jamrial> let dashenc users test it by rushing to trac to report regressions :p [22:01:33 CEST] <wm4> just skip the dash stuff? [22:02:15 CEST] <Compn> yeah dont mess up dash :P [22:02:17 CEST] Action: Compn runs [22:03:39 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:fd502f4f5fe8: build: Generalize yasm/nasm-related variable names [22:03:40 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:0cc0c5b6dbf1: build: Allow generating dependencies as a side-effect of assembling [22:03:41 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:d44935cbf4e4: build: Explicitly set 32-bit/64-bit object formats for nasm/yasm [22:03:42 CEST] <cone-485> ffmpeg 03James Almer 07master:3cc73d3d6d2a: build: fix commandline selection of nasm [22:03:43 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:4f9297ac3b39: build: Prefer NASM assembler over YASM [22:03:44 CEST] <cone-485> ffmpeg 03Diego Biurrun 07master:5cae5a1defa3: configure: Move x86 assembler sanity check into assembler probe function [22:03:48 CEST] <jamrial> so long, yasm, and thanks for resurrecting nasm [22:24:57 CEST] <mateo`> maybe i should turn one of my aarch64 board into a fate instance [22:43:30 CEST] <leif> Hello, I have found several typos in the doxygen documentation. I'd be happy to submit a patch/PR/etc to fix these typos. It looks like the only way to submit the fix for the docs is to subscribe to ffmpeg-devel, is this correct? [22:44:08 CEST] <J_Darnley> It is easier to email the list of you subscribe, otherwise you wait in the mod queue. [22:44:22 CEST] <J_Darnley> However you can turn off email delivery. [22:44:34 CEST] <durandal_170> leif: yes, which typos? [22:49:23 CEST] <leif> J_Darnley: okay thanks. [22:49:33 CEST] <leif> durandal_170: Sure, one moment: [22:50:11 CEST] <leif> For starters: [22:50:16 CEST] <leif> next input/input in the list, NULL if this is the last [22:50:21 CEST] <leif> I suspect you meant input/output there [22:50:29 CEST] <leif> (In the docs for AVFilterInOut) [22:51:38 CEST] <durandal_170> ah i thought about documentation, just send patch [22:52:11 CEST] <leif> OH, okay [22:52:15 CEST] <leif> Will do, thanks. [22:52:30 CEST] <leif> But ya, just some small things here and there. [22:52:36 CEST] <leif> Thanks. :) [22:57:00 CEST] <jamrial> nevcairiel: msvc does not like nasm "LINK : fatal error LNK1000: unknown error at 00007FF6E623F74C; consult documentation for technical support options" [22:57:52 CEST] <nevcairiel> jamrial: seems to work for libav [22:58:29 CEST] <nevcairiel> .. unless configure figures that out and switches to yasm [22:58:37 CEST] <jamrial> it's libavcodec only [22:58:42 CEST] <jamrial> other libraries don't throw that error [22:58:46 CEST] <jamrial> http://fate.ffmpeg.org/log.cgi?time=20170621204044&log=compile&slot=x86_32-… [22:59:40 CEST] <nevcairiel> so likely some specific code somewhere [22:59:45 CEST] <nevcairiel> something libav doesnt have [23:00:50 CEST] <nevcairiel> interestingly only --enabled-shared as well [23:00:54 CEST] <nevcairiel> maybe nasm needs a flag? [23:02:12 CEST] <jamrial> nevcairiel: the static client hasn't yet run with the nasm commits [23:02:24 CEST] <jamrial> unless you mean you tried just now yourself [23:02:30 CEST] <nevcairiel> oh right i only looked at the time, not the rev [23:02:57 CEST] <jamrial> i'm also wonder wtf is going on with netbsd: http://fate.ffmpeg.org/log.cgi?time=20170621101529&log=compile&slot=x86_64-… [23:03:05 CEST] <jamrial> "yasm: warning: can open only one input file, only the last file will be processed" [23:03:35 CEST] <jamrial> yasm, not nasm, so i guess the command line is faulty [23:04:01 CEST] <jamrial> can't reproduce on mingw or archlinux x86_64 [23:47:51 CEST] <atomnuker> (-166.398041 -0.023095) vs (-166.398041 -0.023098) [23:48:06 CEST] <atomnuker> does these differences look like they're because of fma? [23:48:39 CEST] <durandal_170> whats that? [23:48:53 CEST] <atomnuker> coefficients [23:49:30 CEST] <atomnuker> they're so very slightly different but they break the fft [23:49:47 CEST] <durandal_170> bug somewhere? [23:50:34 CEST] <jamrial> nevcairiel: yeah, shared only it seems [00:00:00 CEST] --- Thu Jun 22 2017

1 0

ffmpeg.log.20170621
by burek 22 Jun '17

22 Jun '17

[00:00:05 CEST] <furq> yes there is [00:00:16 CEST] <kerio> well ok you can brag about it [00:00:20 CEST] <furq> 96/24 is essential if you want ot be Smug On Line [00:00:22 CEST] <alexpigment> kerio: I was really talking about bitrates in response to Threads' comment [00:00:24 CEST] <Threads> alexpigment thats very true yes i cant lie i have an old drive somewhere with flac albums on it [00:00:54 CEST] <alexpigment> but yeah 96/24 is not a delivery format for most music, so yeah, i'm at 16-bit 44.1khz for pretty much everything [00:01:18 CEST] <kerio> 7056000hz when [00:02:02 CEST] <kerio> so you can downsample to 44100 and 48000 without complicated math [00:02:06 CEST] <alexpigment> kerio: maybe they'll update DSD and it'll have a comically large sample rate [00:02:08 CEST] <durandal_170> look at sacd [00:02:23 CEST] <kerio> thankfully we're not bound to physical media anymore [00:02:51 CEST] <alexpigment> durandal_170: yeah that was the joke I was making. DSD has a low bit depth but huge sample rate [00:04:11 CEST] <pzy> 24/96 and HDR audio only! [00:04:38 CEST] <alexpigment> "HDR"... that word is getting used in more and more ridiculous ways every day ;) [00:04:53 CEST] <pzy> audio had it first ;) [00:04:55 CEST] <alexpigment> yeah [00:05:01 CEST] <alexpigment> i mean admittedly it makes sense with audio [00:05:22 CEST] <pzy> kerio: did you see that bizarro "metal positive matrix" OK Computer rip? [00:05:35 CEST] <alexpigment> i have to explain to people all the time why HDR video is not the same as HDR photos from a few years ago [00:05:40 CEST] <kerio> vinyl lul [00:05:47 CEST] <pzy> that's what I said [00:05:50 CEST] <pzy> but it's not quite that [00:06:02 CEST] <pzy> http://forums.stevehoffman.tv/threads/metal-positive-matrix-vinyl.663612/ [00:06:11 CEST] <kerio> i mean [00:06:15 CEST] <kerio> it might be high quality [00:06:19 CEST] <kerio> but it's still some analog crap [00:06:38 CEST] <kerio> also, the mastering is the same as the 97 cd right [00:06:53 CEST] <pzy> yeah but.... the original tapes are analog too :P [00:07:11 CEST] <pzy> just another interesting version to digest [00:07:12 CEST] <furq> is it still radiohead [00:07:15 CEST] <kerio> yeah but the original tapes are not in a format ready for distributio [00:07:15 CEST] <kerio> n [00:07:24 CEST] <kerio> furq is SO HYPED about the ok computer rerelease [00:07:30 CEST] <durandal_170> what about dolby atmos and dts:x? [00:08:05 CEST] <alexpigment> you know, i'm a pretty huge radiohead fan, but i find them to be too relatable as humans during the OK Computer era. I can kinda get how they wrote some of the songs [00:08:41 CEST] <alexpigment> with Kid A and onward, I'm just puzzled by how they made any of those songs. it really makes me think less of any 90s-era radiohead [00:09:19 CEST] <kerio> you mean kid A and amnesiac, right [00:09:29 CEST] <kerio> and maybe half of HTTT [00:10:23 CEST] <kerio> i mean whats not to understand about bangers+mash [00:14:56 CEST] <alexpigment_> weird, what's going on with freenode? [00:15:26 CEST] <pzy> you'll get it [00:15:26 CEST] <pzy> 10 years from now [00:15:26 CEST] <pzy> time uncomplicates all music [00:15:49 CEST] <alexpigment> sorry, freenode went down on me [00:16:08 CEST] <alexpigment> kerio: yes, kid A up to king of limbs [00:16:16 CEST] <DHE> it does that a lot. IRC tends to be like that [00:16:25 CEST] <kerio> alexpigment: to be fair [00:17:11 CEST] <kerio> even kid A can be decomposed quite easily in its main constituents [00:17:25 CEST] <kerio> namely, "thom is sad" and "jonny bought an ondes martenot" [00:17:26 CEST] <alexpigment> what about the song "Kid A"? [00:17:31 CEST] <alexpigment> haha [00:18:22 CEST] <kerio> my biggest regret in life is always going to be not having a lossless version of https://soundcloud.com/iamjfp/a-thousand-miles-x-hard-in-da-paint-vanessa-c… [01:07:56 CEST] <Sashmo_> is there a way to make ffmpeg encoding to file to always end on a I frame? [01:09:21 CEST] <vlt> Sashmo_: One would be to use I-frames only. [01:09:37 CEST] <vlt> Technically. [01:10:00 CEST] <JEEB> Sashmo_: you could use the API or use a frame type file (at least for x264, no idea about the rest of the encoders) [01:10:01 CEST] <Sashmo_> dont have that option, need to set bitrate to like 1Mbps and if I do all I frames only, I get crappy quality [01:10:12 CEST] <JEEB> no idea why you'd need an I frame at the end tho [01:10:54 CEST] <Sashmo_> well, if I dont end on an I frame, then the end of the file GOP is incomplete and will allways get a macro block at the end [01:11:54 CEST] <kerio> https://www.youtube.com/watch?v=WIIKXOrt3bk "high quality 256kbps mp3" [01:11:57 CEST] <kerio> and no mention of opus [01:12:00 CEST] <kerio> ayfkm [01:12:37 CEST] <JEEB> Sashmo_: what [01:12:39 CEST] <furq> why are you watching this [01:12:41 CEST] <JEEB> that makes no sense [01:12:50 CEST] <JEEB> a GOP is from a RAP to X [01:13:04 CEST] <kerio> furq: because i go hard in the motherfucking paint [01:13:06 CEST] <Sashmo_> it does for special project, I need to end on a key frame regarless of the diration of the file if its not factor of the GOP [01:13:20 CEST] <furq> is that why you're banned from so many basketball courts [01:13:26 CEST] <JEEB> well there you go. it's just really misleading to say that your GOP is broken because it doesn't end with a RAP [01:13:33 CEST] <JEEB> :P [01:14:13 CEST] <JEEB> Sashmo_: anyways, if you know the input lengths every time, with libx264 you can use a frame type file [01:14:23 CEST] <JEEB> which lets you define the last picture as a RAP [01:14:32 CEST] <JEEB> and everything else will be "auto" [01:14:32 CEST] <Sashmo_> whats a RAP ? [01:14:36 CEST] <JEEB> Random Access Picture [01:14:51 CEST] <JEEB> includes IDR as well as all the other types of things including those in Open GOP [01:15:14 CEST] <Sashmo_> I need a fixed GOP, with the ability to complete the last GOP in a file regardless of duration, even if it has to be "vairiable gop" becuase of the timeing, that can happen at the end, I dont care [01:15:27 CEST] <Sashmo_> hmmm Ive never heard of RAP before [01:15:33 CEST] <Sashmo_> thats an x264 option? [01:15:35 CEST] <JEEB> no [01:15:39 CEST] <JEEB> it's a thing in the specification [01:16:03 CEST] <JEEB> also what does "complete the last GOP" actually mean? [01:16:19 CEST] <Sashmo_> what dont you get? if the file has a fixed gop of 15 [01:16:20 CEST] <JEEB> because that just means a normal GOP for me [01:16:38 CEST] <Sashmo_> that calculation of how many GOPS it does till the end of the file [01:16:50 CEST] <Sashmo_> needs to be a factor of that duration or it will be incomplete [01:17:01 CEST] <Sashmo_> hence the file ends on a P or B frame [01:17:05 CEST] <Sashmo_> indtead of an I frame [01:17:12 CEST] <JEEB> ... [01:17:16 CEST] <Sashmo_> and P and B are not complete frames [01:17:21 CEST] <kerio> why would the file end on a I-frame [01:17:21 CEST] <JEEB> a GOP is complete even if it doesn't have a RAP at the end [01:17:27 CEST] <Sashmo_> no its not [01:17:43 CEST] <JEEB> yes it is, this is your specific requirements, just note that instead of trying to speak in generalities [01:17:44 CEST] <Sashmo_> jsut do ffrpobe show pict [01:17:55 CEST] <Sashmo_> the end of the file can be I P or B [01:18:00 CEST] <Sashmo_> but its not constant [01:18:03 CEST] <kerio> a GOP just means that all the frames inside can be decoded without referring to frames outside of the GOP [01:18:07 CEST] <JEEB> ^this [01:18:28 CEST] <JEEB> a GOP is "something that starts with a RAP and all following images in presentation order can be decoded after you start from the RAP" [01:18:52 CEST] <Sashmo_> ok sure thats the begining of the file [01:18:58 CEST] <Sashmo_> Im talking about the end [01:18:59 CEST] <kerio> JEEB: does it have to start from a RAP [01:19:04 CEST] <JEEB> kerio: yes [01:19:14 CEST] <kerio> why can't the RAP be like the second frame [01:19:22 CEST] <kerio> with the first frame being a B frame [01:19:26 CEST] <JEEB> you can have coded images in decoding order that are after the RAP but are before in presentation [01:19:32 CEST] <kerio> oh i see [01:19:34 CEST] <JEEB> and which do not have to be decode'able [01:19:39 CEST] <JEEB> it's complicated.jpg [01:19:48 CEST] <JEEB> that's why I specify "in presentation order" [01:19:54 CEST] <kerio> no no it's as i imagined it [01:19:59 CEST] <kerio> i think [01:20:29 CEST] <Sashmo_> do you think if I add force keyframes option and set the end of the file time as the key frame it would throw one in there? or is that option a starting point to insert from? [01:20:29 CEST] <JEEB> Sashmo_: it really doesn't matter in general. if you will get out of that state that what you're required to create is the standard we're all OK [01:20:47 CEST] <kerio> -g 1 [01:20:51 CEST] <JEEB> otherwise I will keep telling you that your definition is incorrect [01:21:01 CEST] <kerio> trivial groups of pictures [01:21:18 CEST] <Sashmo_> JEEB: I disagree. If I want to seemless replace at the frame level one video for another video, it should happen on the key frame [01:21:19 CEST] <JEEB> anyways, do you want a RAP at the end or do you want to make the image count divisible by your GOP legnth? [01:21:38 CEST] <Sashmo_> JEEB: thats acceptable [01:21:46 CEST] <Sashmo_> I think that could work [01:21:55 CEST] <Sashmo_> the GOP in the file dosnt matter [01:22:03 CEST] <Sashmo_> as long as I start and end on Is [01:22:49 CEST] <JEEB> Sashmo_: no. if you want to replace GOPs in your file all that is needed in AVC and HEVC is that a) the parameter sets match (and/or are avaialble to the decoder) and B) you have all the images in your previous GOP decode'able and start with the RAP of the GOP that you want to stick together [01:23:20 CEST] <JEEB> thus it is not a requirement for stitching streams together to have a RAP at the end of a GOP [01:23:30 CEST] <JEEB> but maybe I have no fucking clue about these things [01:23:36 CEST] <JEEB> yea, that must be it [01:25:16 CEST] <Sashmo_> well could be [01:25:27 CEST] <Sashmo_> cuz RAP is not random access picture [01:25:37 CEST] <Sashmo_> its a random access point [01:25:39 CEST] <Sashmo_> as I read it [01:27:48 CEST] <JEEB> it's the previous one in 14496-12, and "picture" in HEVC most likely [01:27:56 CEST] <JEEB> 14496-12 being the mp4 container [01:28:15 CEST] <JEEB> or wait no [01:28:23 CEST] <Sashmo_> I trust 10000% you know more than me [01:28:27 CEST] <Sashmo_> so I wont debate [01:28:29 CEST] <Sashmo_> just asking.... [01:28:40 CEST] <JEEB> picture in HEVC I thought, but it could be that they write "RAP picture" there [01:28:48 CEST] <JEEB> in that case it's the same as 14496-12 [01:28:50 CEST] <JEEB> "point" [01:29:10 CEST] <JEEB> but yea, as long as you have the parameter sets available and all of the coded images in the "first" GOP are decode'able [01:29:30 CEST] <JEEB> then as long as your start from the RAP of your "following" GOP [01:29:34 CEST] <JEEB> you should be OK [01:29:45 CEST] <JEEB> (exceptions would be bugs in the decoders) [01:30:01 CEST] <Sashmo_> correct, on the decoders 100% [01:30:15 CEST] <JEEB> preferably you have the exact same parameter sets on all GOPs tho [01:30:21 CEST] <JEEB> in which case bugs are unlikely [01:30:53 CEST] <JEEB> (which basically means using the same settings and having the same resolution and bit depth and chroma subsampling between the GOPs) [01:32:09 CEST] Action: JEEB hits the sack [01:32:19 CEST] <kerio> ouch D: [01:33:48 CEST] <Sashmo_> gnight! thanks for the wise info [01:46:45 CEST] <thomedy> i have broken up my mp4 into images and seperated out the audio [01:47:22 CEST] <thomedy> i can combine the audio back into the the film when i push the imges together agin and go from 0 - end frames [01:48:02 CEST] <thomedy> but i want too use -start_number and vframes to only do lets say 31 - 60 frames or the 2nd second with synced audio [07:16:12 CEST] <fern> anoyne here can help me trying to split an FireWire DV Camera into audio and video? I only get video and can't get audio [10:06:09 CEST] <termos> I'm pushing some decoded video to my filter graph with av_buffersrc_add_frame_flags and receiving it in another thread, but on the receiving end the AVFrame.pkt_dts is no longer monotonically increasing. Is the filter graph known to reorder packets somehow? It's making my flv muxer complain about the dts values [10:07:13 CEST] <termos> The AVFrame.pkt_dts is monotonically increasing before I push it into my filter graph, but not on the outcoming AVFrames [10:11:38 CEST] <durandal_1707> depends on graph [10:17:04 CEST] <termos> ah it's happening after the filter graph, I need to investigate some more [10:29:11 CEST] <DHE> AVFrames usually don't have dts values [10:29:20 CEST] <DHE> or at least the value is not relevant [10:31:38 CEST] <termos> the problem was caused by my own code, huge surprise! I'm pushing AVPackets from different encodings into the same AVThreadMessageQueue and pulling from it into the muxer. weird artifacts in the video as well, which makes sense [14:32:34 CEST] <kerio> theres radioheds [14:32:39 CEST] <kerio> in mp3 320 D: [14:32:43 CEST] <kerio> fug [14:33:29 CEST] <kerio> ok nvm got the flac [16:05:09 CEST] <immelting> I have a question about FFmpeg 3.3.1: I've downloaded & installed it. According to what I've read I've expected to have to do anything additional so that FFmpeg uses the GNU GPLv3 license. [16:05:31 CEST] <c_14> --enable-gpl --enable-version3 [16:06:05 CEST] <c_14> though I'm not sure what requires v3, v2 should be fine for almost everything [16:07:05 CEST] <immelting> But when I run "ffmpeg -version" it says under "configuration" "--enable-gpl" and "--enable-version3", so... is FFmpeg GNU GPLv3 by default? [16:07:16 CEST] <c_14> in that config, yes [16:07:23 CEST] <c_14> by default no [16:07:38 CEST] <c_14> the person who built your ffmpeg binary decided to make it gplv3 [16:07:55 CEST] <furq> ffmpeg is normally lgpl2 [16:08:03 CEST] <immelting> but I've switched or changed nothing; just downloaded & installed, so said config is the default... [16:08:05 CEST] <furq> some external libs require gpl2, and some require gpl3 [16:08:19 CEST] <c_14> immelting: FFmpeg the project does not distribute binaries [16:08:23 CEST] <furq> if you downloaded an ffmpeg binary then the license depends on what libs that binary comes with [16:08:42 CEST] <c_14> the binaries are distributed by independent third parties who decide how they're built [16:08:47 CEST] <furq> https://www.johnvansickle.com/ffmpeg/ [16:08:56 CEST] <furq> if you downloaded this then it's gplv3 because of libopencore [16:08:59 CEST] <c_14> they are only linked on the main page to make it easier for people who don't want to build from the source [16:09:49 CEST] <immelting> Really? This is where I got FFmpeg 3.3.1 from - it was linked from the official page and seem official, as well: https://ffmpeg.zeranoe.com/builds/ [16:10:02 CEST] <furq> yeah those aren't official [16:10:05 CEST] <furq> otherwise they'd be on ffmpeg.org [16:10:09 CEST] <immelting> Oh... [16:10:35 CEST] <c_14> I swear there was a disclaimer there at some point [16:10:36 CEST] <furq> they're just done by people who the project considers reasonably trustworthy [16:11:13 CEST] <immelting> Well, but I'm fine with it. All I wanted to do is rendering an animation with a software, which uses GNU GPLv3, apparently this official build embodies this. :) [16:11:50 CEST] <immelting> ehm, inofficial build... [16:12:26 CEST] <furq> c_14: yeah i remember there being a disclaimer [16:12:37 CEST] <furq> not sure why they'd get rid of that [16:12:41 CEST] <furq> whoever "they" is [16:13:10 CEST] <immelting> But I do encourage the official project to fully transition to GNU GPLv3 - I'm certainly not the only one for whom user freedom has top priority when it comes to choosing software. [16:26:34 CEST] <alexp> hey guys. I logged an issue regarding bad aliasing on NVENC in certain scenarios, and it turns out that the issue is specific to the yuv420p pixel format - it doesn't occur with nv12. being a bit of a pixel format noob, does nv12 differ in a significant enough way to cause player compatibility issues, particularly on hardware formats like Blu-ray/AVCHD? [16:38:37 CEST] <alexp> \nick alexpigment [16:41:03 CEST] <dreamon> Hello. doing ffmpeg -i input.mpg out.mkv http://pastebin.ubuntu.com/24917350/ [16:41:18 CEST] <jkqxz> alexpigment: NV12 and YUV420P contain identical information, and should generate identical output. [16:42:15 CEST] <jkqxz> alexpigment: Them doing different things suggests a bug somewhere. How are you testing the two to come to that conclusion? [16:43:01 CEST] <dreamon> what I did. playing a VHS video recording it with a DVD recording DVD-RW media. Now I rip it with k9copy. Now I have a mpg. VLC plays it without problems. All other player making fragmented picture. [16:43:29 CEST] <alexpigment> jkqxz: https://trac.ffmpeg.org/ticket/6260 [16:44:08 CEST] <dreamon> now tried to convert with ffmpeg but getting a huge mount of errors. Playing the output.mky looks same bad. But vlc can play the mpg well. [16:44:34 CEST] <alexpigment> the reproduction steps cause the issue; if you add -pix_fmt yuv420p, the issue occurs. if you add -pix_fmt nv12 instead, the issue goes away [16:46:02 CEST] <dreamon> alexpigment, me? [16:46:11 CEST] <alexpigment> jkqxz: but if the output of yuv420p and nv12 are functionally identical, it's sort of a non-issue for me going forward, even if it's an issue with ffmpeg [16:46:27 CEST] <alexpigment> dreamon: no, I was talking to jkqxz, sorry [16:46:38 CEST] <dreamon> ;) [16:46:59 CEST] <alexpigment> i've done a lot of VHS > DVD Recorder stuff in the past though. it's very finicky from what I recall. I don't have any solutions though :( [16:47:19 CEST] <furq> alexpigment: they're both 4:2:0 yuv, just packed slightly differently [16:47:34 CEST] <alexpigment> good to know, furq. thanks [16:47:40 CEST] <furq> i think all the commercial hardware encoders use nv12 natively [16:47:50 CEST] <furq> so i guess some conversion is going wrong somewhere [16:48:00 CEST] <furq> s/commercial/consumer/ [16:49:28 CEST] <jkqxz> From the picture on that bug, maybe it has switched the top and bottom field? [16:49:37 CEST] <furq> do you actually get nv12 output from it [16:49:59 CEST] <jkqxz> No idea why nv12 would change anything with that, though. Maybe there is something funny in the nvidia driver depending on the input format. [16:50:55 CEST] <jkqxz> furq: The output is an H.264 stream, so there will be no difference between yuv420p and nv12 (they're both YUV 4:2:0, which is all H.264 cares about). [16:51:42 CEST] <furq> actually nvm [16:51:58 CEST] <furq> i was wondering if it would be sending yuv420p input to nvenc, but of course it is [16:52:15 CEST] <furq> i forgot how video encoding works for a minute there [16:52:28 CEST] <alexpigment> jkqxz: if the bottom and top were switched, I figure I'd see the problem everywhere. oddly, it's only certain places you notice it. it also happens on progressive too, but to a lesser degree [16:53:10 CEST] <jkqxz> It looks switched everywhere on that image. [16:54:11 CEST] <furq> yeah that looks like textbook wrong field order [16:54:37 CEST] <furq> at least the png does [16:54:40 CEST] <furq> i've not looked at the videos [16:54:53 CEST] <alexpigment> I guess you guys can look at the sample video if you don't believe me, but the motion itself isn't judder-y [16:54:56 CEST] <alexpigment> it's perfectly smooth [16:55:04 CEST] <jkqxz> Yeah, I only looked at the png too. [16:55:51 CEST] <alexpigment> now if there was some sort of color-only field problem, I might believe that, but it still doesn't explain why it affects progressive [16:57:36 CEST] <furq> does the progressive output look noticeably better with nv12 [16:58:00 CEST] <furq> progressiveoutput.mp4 looks broadly fine to me [16:58:55 CEST] <alexpigment> lemme check [17:00:13 CEST] <furq> i mean it doesn't look amazing but it doesn't look obviously buggy [17:01:19 CEST] <alexpigment> yeah, i'm still seeing it there [17:01:23 CEST] <alexpigment> look at the bottom area of the red ring [17:01:34 CEST] <furq> with nv12? [17:01:36 CEST] <alexpigment> there's this aliasing that kinda moves down the ring [17:01:37 CEST] <alexpigment> oh [17:01:38 CEST] <alexpigment> no [17:01:41 CEST] <furq> oh right [17:01:42 CEST] <alexpigment> with yuv420p [17:01:53 CEST] <alexpigment> nv12 looks good [17:02:05 CEST] <furq> fair enough then [17:03:01 CEST] <alexpigment> yeah, i at least have a good workaround, so I'm fine now [17:03:18 CEST] <alexpigment> but it does make a good argument to always use nv12 rather than assuming yuv420p [17:03:36 CEST] <furq> it would maybe be better if yuv420p just broke [17:03:39 CEST] <alexpigment> rather, it makes a good argument for FFMPEG to use nv12 for nvenc rather than assuming yuv420p [17:03:46 CEST] <furq> oh [17:03:50 CEST] <furq> i thought you were specifying yuv420p [17:03:59 CEST] <alexpigment> no [17:04:00 CEST] <furq> i should probably read the bug report better [17:04:10 CEST] <alexpigment> however if i specify yuv420p it's the same as not specifying it [17:04:49 CEST] <alexpigment> furq: no worries. my bug report was probably long-winded and didn't summarize it well in the first place [17:05:38 CEST] <alexpigment> and at the time i logged it, I didn't know it was a yuv420p problem. that info came from a comment on the bug that someone made 6 hours ago [17:14:49 CEST] <alexpigment> on an entirely unrelated note, I'm trying to recreate AVC Intra (more or less) with NVENC right now. I can't figure out how to turn off CABAC. I guess -coder 0 is just ignored? [17:16:39 CEST] <alexpigment> also, if i'm setting the gop to 1, should I use this -forced-idr parameter? admittedly, i'm not sure if there's any difference between I and IDR in a "-g 1" setup [17:17:13 CEST] <JEEB> AVC Intra is a fucked up thing [17:17:15 CEST] <alexpigment> (ignore the IDR thing. they're doing that already) [17:17:21 CEST] <alexpigment> JEEB: why is that? [17:17:45 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=9b94896b3735052cabb52d081de3… [17:17:47 CEST] <alexpigment> are you talking about the format itself or the concept of an intra-only video? [17:17:49 CEST] <JEEB> missing parameter sets [17:17:51 CEST] <JEEB> etc [17:17:58 CEST] <JEEB> AVC-Intra, the way of doing vendor lock-in [17:18:03 CEST] <JEEB> with a standard format [17:18:04 CEST] <JEEB> :V [17:18:16 CEST] <JEEB> you should just look at some of that crap and FFFUUUU [17:18:45 CEST] <alexpigment> ahh, I'm not really trying to recreate AVC Intra to comply with any specifications to be honest [17:19:08 CEST] <JEEB> well that's what you mean when you say "AVC(-| )Intra" [17:19:10 CEST] <alexpigment> the principles of AVC Intra, though, are important for NLEs [17:19:11 CEST] <JEEB> with the big things [17:19:20 CEST] <alexpigment> fair point [17:19:25 CEST] <JEEB> if you said just intra-only AVC that'd be OK [17:19:46 CEST] <alexpigment> ok, yes, i'm trying to create intra-only AVC [17:20:09 CEST] <jkqxz> If only the real H.264 specification included intra profiles. [17:20:42 CEST] <alexpigment> well, MediaInfo shows a profile of High Intra on x264, for what it's worth [17:20:56 CEST] <alexpigment> i'm not sure if that makes any difference [17:21:06 CEST] <JEEB> that's most likely just mediainfo's bullshit [17:21:07 CEST] <alexpigment> but NVENC just produces High profile [17:21:18 CEST] <alexpigment> JEEB: tell us how you *really* feel ;) [17:21:30 CEST] <jkqxz> NVENC doesn't have any options for producing the intra profiles. [17:21:47 CEST] <jkqxz> If you set it up right you can just edit the profile_idc byte after the fact, though. [17:21:51 CEST] <JEEB> there are no intra profiles AFAIK, and thankfully this poor person doesn't need actual AVC-Intra [17:21:57 CEST] <JEEB> or are there? [17:22:03 CEST] <alexpigment> yeah, I guess I'm less concerned about that, and more concerned with turning off CABAC and forcing the refs to zero [17:22:05 CEST] <JEEB> (AVC-Intra is the mangled piece of shit) [17:22:27 CEST] <jkqxz> And constraint_setwhicheveroneitis_flag. [17:22:56 CEST] <alexpigment> but that does kinda make me wonder: what does CABAC do, and what does a reference frame do, when all frames are IDR? [17:23:00 CEST] <jkqxz> Yes, there are a load of standard intra profiles in H.264. [17:23:28 CEST] <jkqxz> To turn off CABAC in NVENC, you can probably just set -profile baseline. [17:23:41 CEST] <jkqxz> There aren't really any ways to set each feature individually. [17:24:02 CEST] <alexpigment> I suppose I could try that [17:24:41 CEST] <alexpigment> but if CABAC = CALVC when GOP is 1, then maybe it's not even worth messing with it [17:24:52 CEST] <jkqxz> Looks like there is a config option for it if you want to hack the lavc wrapper. [17:25:06 CEST] <alexpigment> link? [17:25:09 CEST] <jkqxz> Er, what? No, they're completely unrelated. [17:26:00 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=compat/nvenc/nvEncodeAPI.h#l…> [17:26:06 CEST] <alexpigment> i thought cabac did some sort of multi-frame referencing, but maybe i'm just mixing things up [17:26:50 CEST] <JEEB> no [17:26:56 CEST] <JEEB> CABAC you could think of is at the end of the process [17:26:58 CEST] <JEEB> you have the data [17:27:03 CEST] <JEEB> then you compress it [17:27:09 CEST] <alexpigment> well it's good to know that the API supports turning CABAC off at least [17:27:10 CEST] <JEEB> CAVLC and CABAC are just two ways of compressing it [17:27:13 CEST] <alexpigment> ahh [17:27:25 CEST] <JEEB> then during decode you decompress it and handle it [17:27:43 CEST] <JEEB> that's also why the more bit rate you use the more CPU you use because CABAC and CAVLC start eating more and more of the cycles [17:27:52 CEST] <alexpigment> right, and CAVLC is easier to decode presumably [17:28:15 CEST] <JEEB> yes, but at high bit rates I'd be surprised if it had significant effect on anything [17:28:28 CEST] <alexpigment> gotcha [17:28:29 CEST] <JEEB> I remember someone doing some tests like seven (?) or so years ago [17:28:43 CEST] <JEEB> and for editing even a two-three frame GOP was fast enough with lossless AVC [17:28:54 CEST] <JEEB> of course intra-only enables other things [17:32:38 CEST] <alexpigment> JEEB: I guess if you're using Intra-only, file size isn't a huge concern, so you might as well set the GOP 1 rather than worry about the sweet spot [17:33:29 CEST] <alexpigment> but yeah, I'm sure it's a diminishing returns situation [18:12:52 CEST] <billyshambrook> Hey, I am using the command at the bottom in this guide - (https://trac.ffmpeg.org/wiki/Scaling%20(resizing)%20with%20ffmpeg) but with the w and h set to 640 and 360 (ffmpeg -i in.mp4 -vf scale=w=640:h=360:force_original_aspect_ratio=decrease out.mp4) but am getting the error "width not divisible by 2 (203x360)" [18:13:22 CEST] <billyshambrook> Is there anyway of forcing it to round up to the closest divisible by 2 number? [18:30:50 CEST] <alexpigment> billyshambrok: yeah scale=-2,360 I believe [18:31:36 CEST] <alexpigment> assuming you want to enforce the 360 height [18:31:56 CEST] <alexpigment> oops [18:32:01 CEST] <alexpigment> scale=-2:360 [18:32:03 CEST] <alexpigment> sorry about that [18:32:32 CEST] <alexpigment> if you want to enforce the 640 instead, you can do scale=640:-2 [18:40:15 CEST] <alexpigment> man, this nvenc has so many strict rules that just result in unexplained failure [18:40:54 CEST] <alexpigment> for example, I just found out that 1080i will fail if you try and use a bitrate over 37.5mbps with strict bitrate constraints [18:41:09 CEST] <JEEB> not surprising [18:41:30 CEST] <alexpigment> it will also fail if you use a profile level of 5.0 with that same bitrate (granted, I know this doesn't make sense, but I was getting failures with 5.0 and 100mbps and I had to figure out what was breaking) [18:42:33 CEST] <alexpigment> well, that pretty much rules out doing a high bitrate intra-only 1080i... [18:46:07 CEST] <JEEB> I do know the nvidia encoder at least in gtx 1080 supports uhd at 60hz with 4:4:4, lossless [18:46:19 CEST] <JEEB> that made my ssd sweat [18:46:21 CEST] <JEEB> :) [18:46:36 CEST] <alexpigment> yeah, i assume the 1060 I have does as well [18:46:55 CEST] <alexpigment> but yeah, that's wayyyyy overkill for my needs [18:47:17 CEST] <alexpigment> i'm just looking for common formats to use in NLEs [18:47:18 CEST] <JEEB> it does also do 4:2:0 and 4:2:2 I guess [18:47:34 CEST] <alexpigment> actually, i don't know how to specify 4:2:2 on this 1060 [18:48:29 CEST] <alexpigment> it allows you to specify 4:4:4 as the pix_fmt [18:48:34 CEST] <alexpigment> 4:2:2 isn't there though [18:57:58 CEST] <jasom> If I have a large number of files to transcode to x265, what's the tradeoff between several parallel single-threaded encodes and a single multi-threaded encode? It looks like unlike x264 there's not a significant bitrate difference between single and multithreaded encodes, but I would expect to get a nearly linear speedup of parallel single-threaded encodes, but a sublinear speedup of a single multi-threaded [18:58:00 CEST] <jasom> encode. [18:58:20 CEST] <furq> "unlike x264"? [18:58:38 CEST] <furq> i wasn't aware that was a thing [18:59:13 CEST] <furq> unless you're using slice threading [19:09:17 CEST] <DHE> frame threading in x264 does increase the file size, but it's quite minor. less than 1% typically [19:11:05 CEST] <furq> yeah that's not significant [19:33:30 CEST] Action: jasom reads up on x265 and discovers his my x264 info is out of date; slice threading was the only thing last time I looked at it [19:36:35 CEST] <furq> that's a pretty long way out of date [19:36:55 CEST] <jasom> 2009 maybe? [19:38:21 CEST] <jasom> sadly I lack the free-time for reading nitty-gritty details of video encoders these days [19:39:07 CEST] <JEEB> frame threading was added quite a bit earlier than 2009 [19:39:56 CEST] <JEEB> http://git.videolan.org/?p=x264.git;a=commit;h=7b4f6a1fd95c7e0ab479e116fe59… [19:39:59 CEST] <JEEB> 2006 :) [19:40:06 CEST] <kepstin> if you really want to encode stuff fast, the trick is of course to get multiple computers, then do parallel multi-threaded encodes. [19:41:53 CEST] <jasom> kepstin: or one multi-threaded encode per NUMA zone [19:42:51 CEST] <jasom> JEEB: I'd believe 2006; I just know it was post-college and pre-kids which is 2004-2009 [19:43:29 CEST] <JEEB> I linked the commit that added frame threads :) [19:48:37 CEST] <jasom> JEEB: but someone could have faked the timestamp, just to confuse me ;) [19:50:32 CEST] Action: kepstin wonders where the best video encoder efficiency on EPYC is gonna be - per CCX? per die? per socket? [19:53:48 CEST] <jasom> kepstin: well I hear Zen has significantly slower per-core AVX, so x265 could be CPU bound at low thread-counts. [19:57:44 CEST] <kepstin> yeah, i heard it was 2-clock avx2 instructions instead of the 1-clock that intel has (although recent intel also reduces frequency on heavy avx2?, but not nearly enough to make up the difference) [19:58:23 CEST] <furq> yeah zen doesn't have any 256-bit registers [19:58:50 CEST] <furq> it has avx2 instructions but they don't really do anything [20:27:36 CEST] <DHE> yes, e6-2600v4 series CPUs will throttle down cores executing avx2 instructions. older cpus would throttle down the whole package [20:28:16 CEST] <DHE> kepstin: I have a ryzen 7.. know of a test/benchmark app? [20:28:47 CEST] <BtbN> Prime95 [20:29:10 CEST] <kepstin> well, a test/benchmark for what, video encoding? [20:29:28 CEST] <kepstin> just get yourself a sample video file and do a few runs in ffmpeg :/ [20:30:30 CEST] <kepstin> on the ryzen out now you can only really do per-ccx and per-die tests, it won't be until threadripper/epyc that there are multiple dies per socket or multiple sockets. [20:30:33 CEST] <DHE> I meant in terms of AVX specifically [20:31:10 CEST] <DHE> and epyc is supposed to be released. motherboard manufacturers (I've seen supermicro) are touting their products now [20:34:54 CEST] <ChocolateArmpits> So I'm trying to get near real time streaming with video only. Currently latency including encoding, transmission and playback is around 250-300ms. I'm using x264 to encode for lowlatency intra refresh, transmitting mpegts over udp and mplayer for playback using benchmark and a few other corner cutting parameters. [20:35:11 CEST] <ChocolateArmpits> Is there some special sauce to push the latency even further down? [20:37:03 CEST] <kerio> DHE: the names are so dumb tho [20:37:56 CEST] <DHE> ChocolateArmpits: zerolatency is about the best x264 can offer. do note that the player will buffer at least a little bit. 300 ms is actually pretty reasonable [20:40:19 CEST] <ChocolateArmpits> DHE, well as per the archived shikari blog post it's not just zerolatency but also using buffer the size of a single frame and using intra refresh that minimize encoder latency too [20:41:09 CEST] <ChocolateArmpits> so the frames would get sent to the output as fast as possible keeping same size to get over the network faster [20:41:39 CEST] <kepstin> intra-refresh iirc doesn't really reduce total encoder latency, but it does make the latency more consistent frame-to-frame (otherwise e.g. keyframes would take longer to cabac because they're bigger, for example) [20:42:02 CEST] <ChocolateArmpits> yeah I probably should've written it like that [20:44:39 CEST] <DHE> intra refresh is more for the bitrate and size of each frame. since zerolatency means no forward prediction decisions can be made, having a ~80 kilobyte keyframe is a huge kick in the nuts when you're under a birate constraint and have no way to predict how far off course you'll go [20:46:05 CEST] <furq> what are you actually encoding [20:46:15 CEST] <furq> if it's from a v4l source or something then that'll probably add some latency [20:47:03 CEST] <ChocolateArmpits> source is camera output that's captured via decklink [20:48:54 CEST] <ChocolateArmpits> 300ms delay is sort of acceptable for slower speech but when spoken faster the delay is more apparent [20:56:33 CEST] <BtbN> kepstin, my Ryzen can do 1080p60 with x265 at decent settings [20:57:14 CEST] <kepstin> BtbN: not bad. I only have an R7 1700, but I haven't done any x265 on it yet. [20:57:25 CEST] <BtbN> I got the 1800X [20:57:31 CEST] <hpp> try vp9 [20:57:38 CEST] <BtbN> you can just overclock a 1700 to 1800X levels though, very easily [20:57:59 CEST] <kepstin> hmm, I'm using a ... novelty case design, so I'm a bit cooling limited ;) [20:58:26 CEST] <kepstin> if you do try vp9, make sure you have a recent git build so you have the new row threading stuff [20:58:44 CEST] <BtbN> I put a NH-D15 on mine [20:58:50 CEST] <BtbN> it's basically at room teperature at all times [20:58:51 CEST] <alexpigment> noctua is a nice choice [20:58:58 CEST] <BtbN> The D15 is _huge_ [20:59:03 CEST] <BtbN> It's almost 2kg of metal [20:59:07 CEST] <alexpigment> is it a 2-fan design? [20:59:10 CEST] <BtbN> yes [20:59:21 CEST] <alexpigment> wow [20:59:31 CEST] <alexpigment> the pictures on that are ridiculous [20:59:37 CEST] <alexpigment> it takes up the whole width of the boar [20:59:39 CEST] <alexpigment> *board [20:59:40 CEST] <kepstin> yeah, I'm running the stock wraith spire with the 1700, and I actually had some issues because one of the edges on the fan rim was ~1mm too tall [21:00:07 CEST] <furq> lol that's insane [21:00:19 CEST] <furq> http://abload.de/img/82q8sba.jpg [21:00:26 CEST] <kepstin> and the only reason it was too tall was the silly rgb leds they stuck in the top edge :( [21:00:42 CEST] <furq> i bet a lot of people with fancy ram heatsinks have had to return those [21:01:06 CEST] <alexpigment> furq: almost all of those horizontal coolers get in the way of RAM tbh [21:01:25 CEST] <kepstin> the fan mounting height on the D15 is adjustable, it can be moved up to clear ram if you have enough height in the case [21:01:35 CEST] <kepstin> but yeah, it is an issue :) [21:01:47 CEST] <BtbN> furq, you can just mount the fan higher [21:01:48 CEST] <furq> that's probably a big if [21:02:13 CEST] <BtbN> I had to move it up on mine a bit [21:02:15 CEST] <alexpigment> yeah, I just have a coolermaster hyper evo or whatever it is. it keeps my i7-5930k at 30 idle and 50 max. i can't complain [21:02:19 CEST] <BtbN> even without big heat sinks on the RAM [21:04:35 CEST] <alexpigment> kepstin: still you've got a 65 watt chip with the 1700. i would think your cooler could handle a decent bump in speed [21:04:43 CEST] <BtbN> I could probably just remove the fans, and it'd still not overheat [21:04:47 CEST] <alexpigment> (unless it runs hotter than other 65w chips) [21:05:01 CEST] <BtbN> pretty much all R7 can hit 3.8GHz [21:05:07 CEST] <kepstin> alexpigment: the actual restriction is the lack of case airflow / limited ventiliation [21:05:13 CEST] <alexpigment> ah [21:05:16 CEST] <BtbN> And they all cap out at 3-9-4.0GHz, so a 1800X is mostly pointless [21:05:22 CEST] <alexpigment> how "novelty" is your case? ;) [21:05:50 CEST] <kepstin> alexpigment: hmm, I think i've shared this image before: https://www.kepstin.ca/dump/DSC_4562.JPG [21:06:00 CEST] <alexpigment> haha [21:06:06 CEST] <alexpigment> lol [21:06:46 CEST] <BtbN> https://btbn.de/public/pc.jpg that's my current build [21:06:59 CEST] <BtbN> I'd say the airflow is decent [21:07:23 CEST] <alexpigment> BtnB: is that an antec? [21:07:28 CEST] <BtbN> no [21:07:35 CEST] <BtbN> Fractal Design [21:07:38 CEST] <kepstin> the problem with this case is that it doesn't have space for a proper exhaust fan, it had the psu mounted over the cpu socket on the board and relied on psu exhaust [21:07:56 CEST] <alexpigment> ah [21:08:26 CEST] Last message repeated 1 time(s). [21:08:26 CEST] <alexpigment> i haven't used a fractal before [21:08:31 CEST] <kepstin> I switched the psu for a sfx in an adapter bracket to gain z-space, and the board I'm using puts the main 16x pcie one slot down, so I have an old-fashioned "pci slot cooler" in slot 1 [21:08:31 CEST] <alexpigment> i've been an antec guy for so long [21:09:11 CEST] <kepstin> that gets me enough airflow, combined with an 80mm fan in the front, to keep it stable around 70-75C at stock clocks, which is... ok. [21:09:22 CEST] <furq> that's not really that ok [21:09:31 CEST] <alexpigment> kepstin: this is dedication to a flawed design :) [21:09:47 CEST] <hpp> why power supply goes bottom these days when heat goes up? [21:09:55 CEST] <furq> i take it you're not running any spinning disks in there [21:10:09 CEST] <alexpigment> hpp: i think it's because the intake is from the bottom of the case where the air isn't hot from components below it [21:10:19 CEST] <alexpigment> the PSU intake, i mean [21:10:51 CEST] <hpp> hmm, makes sense i guess [21:11:17 CEST] <alexpigment> but it also allows you to have a chambered airflow at the bottom, which my old antec has. the bottom part is basically just fan, HDD, HDD, fan, PSU. and the airflow is completely separated from the top part of the case [21:11:34 CEST] <furq> living the P180 lifestyle [21:11:41 CEST] <alexpigment> furq: that's the one [21:11:51 CEST] <furq> lol do you actually have a P180 [21:11:54 CEST] <alexpigment> yeah [21:11:54 CEST] <furq> did they make a new version or something [21:12:03 CEST] <kepstin> heh, at some point I might give up on this case and move it into my old P180 ;) [21:12:05 CEST] <alexpigment> they have a p280 that's wider - i have that at work [21:12:10 CEST] <furq> lol [21:12:21 CEST] <furq> my friend had a P180 in like 2005 [21:12:25 CEST] <alexpigment> but the p180 is fine for my main machine at home. the only thing that sucks is the front USB 2.0 ports [21:12:26 CEST] <furq> iirc he hated it [21:12:42 CEST] <kepstin> oh, its an awful case. huge and annoying to work in [21:12:49 CEST] <furq> yeah apparently it was a pig to work on [21:12:52 CEST] <furq> looked nice though [21:12:54 CEST] <alexpigment> if you have a lot of drives, the P180 is great [21:12:59 CEST] <furq> and i imagine it does have very good airflow [21:13:03 CEST] <alexpigment> i have 6 HDDs in mine and they all have spaces in between them [21:13:09 CEST] <kepstin> yeah, I did have 6 spinning disks in mine at one point [21:13:19 CEST] <kepstin> now I moved all the disks to a dedicated nas, so... [21:13:44 CEST] <kepstin> I think I have my old athlon 64 x2 in there, I wonder if it still works [21:13:56 CEST] <alexpigment> I would do nas if I had gigabit ethernet to my main system. unfortunately, i have to settle for 801.11AC 3x3 [21:14:02 CEST] <furq> i still have an antec sonata 2 somewhere with an a64 3000+ in it [21:14:07 CEST] <furq> and no door [21:14:21 CEST] <alexpigment> my wife has the antec sonata 2 still [21:14:25 CEST] <kepstin> alexpigment: if you read the marketing, 802.11ac is faster than gigabit ;) [21:14:32 CEST] <furq> covered in fingerprints no doubt [21:14:44 CEST] <alexpigment> kepstin: well it's not duplex, so you're not going to get gigabit speeds [21:15:01 CEST] <kepstin> (in actual use, I've seen 500-600mbit real throughput on my laptop, which isn't that bad.) [21:15:05 CEST] <alexpigment> but my connection reads a steady 1.3gbps in windows, for what it's worth [21:15:14 CEST] <alexpigment> and that's pretty fast [21:16:00 CEST] <furq> the main reason to have a nas is because nobody wants freebsd on their desktop system [21:16:01 CEST] <alexpigment> kepstin: yeah i get the same on my laptop. my desktop is a bit faster I believe because of the 3x3 card. honestly, it's fast enough that I haven't paid someone to drop ethernet in our place [21:16:10 CEST] <furq> and that's the most usable thing that has worthwhile zfs support [21:18:41 CEST] <alexpigment> do you guys actually do high bitrate encoding straight to the NAS? [21:18:58 CEST] <alexpigment> i'd be worried about bottlenecking the speed [21:19:15 CEST] <alexpigment> rather, waiting for a 20GB file to write over the network [21:20:13 CEST] <kepstin> I generally don't do extremely high bitrate stuff, biggest I deal with is BD sizes. I have local SSDs and some local spinning rust on all of my boxes that I sometimes use for temp work tho. [21:21:13 CEST] <alexpigment> yeah, I deal with mostly broadcast or Blu-ray bitrates daily. nothing below ~12mbps really [21:21:24 CEST] <kepstin> only a single local hdd tho, so it's only a little faster than the gigabit network. [21:21:40 CEST] <alexpigment> fair enough [21:22:53 CEST] <furq> i encode to local disk and then move it across [21:23:01 CEST] <furq> regardless of the bitrate [21:23:08 CEST] <furq> i do that with dvdrips and flac as well [21:23:47 CEST] <alexpigment> i guess i just do all my encoding on my system that serves as a network server for my HTPCs, so a NAS feels kinda like extra work for me [21:24:04 CEST] <furq> like i said, i only have a nas for zfs [21:24:13 CEST] <alexpigment> oh right [21:24:31 CEST] <furq> i wouldn't bother if i was just running a jbod [21:27:52 CEST] <kepstin> I have the nas nfs mounted and honestly a lot of the time I just do stuff over the network directly, particularly if I expect it would be cpu limited anyways. [21:28:26 CEST] <furq> you can't defrag zfs so i prefer not to move stuff onto the nas until it's done [21:28:43 CEST] <furq> it also has a tendency to allocate blocks wherever the fuck it feels like [21:29:37 CEST] <alexpigment> sounds like a ringing endorsement ;) [21:48:23 CEST] <alexpigment> does anyone know why transcoding from 1080i60 (i.e. 29.97fps) to 1080i60 with NVENC would cause "Original Frame Rate" to show up as 59.94fps in MediaInfo? [21:48:54 CEST] <alexpigment> If I do the same encode with libx264 and QSV, that field doesn't show up in MediaInfo [21:54:22 CEST] <ChocolateArmpits> alexpigment, nvenc might insert some information in the encoded stream [21:55:04 CEST] <alexpigment> possibly [21:55:28 CEST] <alexpigment> it just seems weird that the original frame rate is 29.97. perhaps they're meaning the original *field* rate? [21:58:46 CEST] <BtbN> nvenc interlaced encoding is horribly broken on the driver side [21:59:00 CEST] <alexpigment> well, from what I've read, they fixed it [21:59:17 CEST] <alexpigment> https://devtalk.nvidia.com/default/topic/976088/ffmpeg-h264_nvenc-interlace… [22:06:22 CEST] <alexpigment> and it works in Staxrip for what it's worth [22:07:06 CEST] <alexpigment> the working copy from Staxrip doesn't have the "Original Frame Rate: 59.94fps" field at all [22:36:51 CEST] <dystopia_> hey all [22:36:54 CEST] <dystopia_> https://pastebin.com/USh7pEEr [22:37:17 CEST] <dystopia_> im setting -x264opts force-cfr=1 [22:37:28 CEST] <dystopia_> but getting a variable framerate output [22:37:56 CEST] <dystopia_> going from a 23.976fps source back to 23.976 [22:38:02 CEST] <dystopia_> anyone know whats up? [22:38:18 CEST] <furq> i'm pretty sure mediainfo always reports 24000/1001fps in mkv as vfr [22:38:40 CEST] <furq> mkv has a fixed timebase of 1/10000 which can't accurately represent 24000/1001 [22:38:51 CEST] <furq> so the PTS values aren't evenly spaced [22:38:59 CEST] <RandomCouch> I apologize for cutting in, but I am trying to copy one video's metadata into another video but something isn't working right [22:39:03 CEST] <RandomCouch> I'm using this command .\ffmpeg.exe -i .\sourceVideo.mp4 -map 1 -c copy -map_metadata 0 -map_metadata:s:v 0:s:v -map_metadata:s:a 0 :s:a .\Out.mp4 [22:39:13 CEST] <RandomCouch> And I'm getting this error :Invalid input file index: 1. [22:39:24 CEST] <RandomCouch> my Out.mp4 file exists in the folder [22:39:24 CEST] <furq> -map 1 refers to the second input file [22:39:26 CEST] <furq> you only have one [22:39:27 CEST] <dystopia_> hmm ok furq [22:39:51 CEST] <furq> also you shouldn't need the other -map_metadata calls [22:39:59 CEST] <furq> -map_metadata 0 will map all metadata from input file 0 [22:40:52 CEST] <furq> dystopia_: maybe consider using mp4 for 24000/1001 [22:41:40 CEST] <dystopia_> ok :) will give it a shot [22:42:36 CEST] <RandomCouch> Awesome thanks furq that worked! [22:43:11 CEST] <RandomCouch> Wait actually... it just copied the whole file [22:43:22 CEST] <RandomCouch> now my out.mp4 is exactly the same video as my sourcevideo [22:44:37 CEST] <kepstin> RandomCouch: that's what you told it to do, yes? [22:44:58 CEST] <RandomCouch> I only want to copy the metadata [22:45:03 CEST] <RandomCouch> mainly the resolution and the framerate [22:45:20 CEST] <kepstin> that... doesn't make sense [22:45:32 CEST] <furq> lol what [22:45:38 CEST] <RandomCouch> hmm, I have 2 mp4 videos, I need the second one to have the same resolution and framerate as the first oen [22:45:48 CEST] <RandomCouch> I'm not sure if I'm asking for the right thing now [22:46:11 CEST] <furq> that is technically what you've got [22:46:15 CEST] <furq> is that not good enough [22:46:37 CEST] <RandomCouch> well the two videos are not the same, like one is a video of a gameplay for a game, the other is a video of a generic Game Over screen [22:46:41 CEST] <kepstin> RandomCouch: ok, then you have to re-encode the second video, and use the -s and -r options (or scale and fps filters) to set the output size and framerate appropriately. [22:46:53 CEST] <RandomCouch> when I tried that method you showed me, my second video became exactly the first video which was the gameplay [22:46:55 CEST] <furq> you don't need to set -s and -r if you want them to be the same as the source video [22:47:15 CEST] <furq> wait [22:47:15 CEST] <kepstin> RandomCouch: I'm guessing what you actually want to concatenate these two videos, but can't because they're different sizes? [22:47:19 CEST] <furq> ok go back to the start again [22:47:23 CEST] <RandomCouch> kepstin: exactly [22:47:30 CEST] <furq> ah [22:47:32 CEST] <RandomCouch> but I'm not concatenating with ffmpeg, I'm using an external library for android [22:47:40 CEST] <furq> sherlock kepstin over here [22:47:51 CEST] <kepstin> I can apparently read minds over the internet! [22:47:57 CEST] <kepstin> time to go off and get rich. somehow. [22:48:01 CEST] <RandomCouch> I just need them to be the same resolution and framerate haha [22:48:09 CEST] <RandomCouch> I believe in you kepstin [22:50:50 CEST] <kepstin> RandomCouch: so yeah, something like "ffmpeg -i SecondVideo.mp4 -s 1280x720 -r 30 SecondVideoResized.mp4" - replace the size and framerate with the desired values - although you might also want to add other options to set the video encoder/quality. Do you also have audio? [22:51:43 CEST] <kepstin> there's no way to have ffmpeg read the values from the first file and then apply them to the second, you'll have to do that manually. [22:51:48 CEST] <RandomCouch> Yeah I have audio, both are already using the same audio codec [22:51:51 CEST] <RandomCouch> although the bitrate is different [22:52:03 CEST] <RandomCouch> gotcha, that shouldn't be an issue [22:52:08 CEST] <RandomCouch> I'll give it a try, thanks kepstin and furq ! [22:52:11 CEST] <kepstin> then you'll want to add "-c:a copy" to keep the audio without re-encoding [22:52:18 CEST] <RandomCouch> gotcha [22:52:27 CEST] <kepstin> the video has to be re-encoded to do the resize, of course. [22:53:56 CEST] <kepstin> by default it will (probably) use the x264 video encoder with crf 23 when encoding to mp4. If it's too low quality add a "-crf" option with a lower number, e.g. around 18 should give very good quality. [22:54:33 CEST] <hpp> 18 give also too large file [22:54:41 CEST] <hpp> 23 it like optimal [22:54:50 CEST] <hpp> is* [22:55:39 CEST] <hpp> 20 will do [23:19:53 CEST] <alexpigment> Is there no way to modify the body of a ticket I created on trac.ffmpeg.org? [23:30:30 CEST] <furq> i don't think much of this bwdif [23:30:41 CEST] <furq> granted i tried it with a 5-second sample but it's done a poor job [23:31:15 CEST] <alexpigment> it's a deinterlacing filter? [23:31:20 CEST] <furq> yeah [23:31:32 CEST] <alexpigment> is there any supposed avantage over yadif? [23:31:35 CEST] <furq> it's supposedly better than yadif, but squinting is better than yadif [23:31:46 CEST] <alexpigment> haha [23:31:56 CEST] <furq> better meaning slower but higher quality [23:32:06 CEST] <furq> i normally use qtgmc for dvdrips so i'm totally fine with slow deinterlacing [23:32:08 CEST] <alexpigment> is anything in ffmpeg better than yadif already? [23:32:17 CEST] <furq> bwdif is in ffmpeg [23:32:22 CEST] <furq> assuming it is actually better [23:32:40 CEST] <alexpigment> oh gotcha. you're trying out bwdif to get something close to qtgmc [23:33:13 CEST] <furq> nah i was just cutting out an interlaced clip and i;m not breaking out vapoursynth for that [23:33:26 CEST] <furq> so i figured i'd try bwdif since i've seen people talking about it [23:33:31 CEST] <alexpigment> gotcha [23:33:35 CEST] <furq> https://0x0.st/l5e.mp4 [23:33:37 CEST] <furq> you be the judge [23:34:46 CEST] <alexpigment> I mean I see the aliasing for sure, but I don't know how qtgmc would do on that same clip [23:35:23 CEST] <furq> i'd have to double check but it generally does really well on that kind of edge aliasing [23:35:35 CEST] <alexpigment> I've gotten to the point where I just leave everything interlaced. The DXVA2 deinterlacer seems to do a good job for me, and I maintain the ability to go back to a DVD or Blu-ray later [23:35:37 CEST] <furq> that's always the thing i notice most when i use something else [23:36:07 CEST] <furq> qtgmc is higher quality than anything i can use realtime [23:36:28 CEST] <furq> although the best thing about qtgmc by far is the bad deinterlacing repair mode [23:36:40 CEST] <furq> i have a ton of early-2000s bbc dvds that have been really badly deinterlaced [23:36:44 CEST] <alexpigment> I'll take your word for it. I've still never gotten into avi/vapoursynth [23:36:48 CEST] <furq> it does an amazing job of cleaning that shit up [23:37:10 CEST] <furq> without destroying the quality as much as a full deinterlacer would [23:37:15 CEST] <alexpigment> I'll have to force my old man brain to learn vapoursynth and try it out sometime [23:37:25 CEST] <pa> hi [23:37:26 CEST] <furq> it can be a bit annoying to set up [23:37:26 CEST] <pa> question [23:37:31 CEST] <furq> but once you've got it all installed it's pretty simple [23:37:40 CEST] <furq> vs is definitely much less hassle than avisynth [23:37:41 CEST] <pa> i try to grab the screen with ffmpeg and output to a pipe [23:37:56 CEST] <furq> i literally only use it for deinterlacing though [23:38:00 CEST] <pa> but if i do that, i get "unable to find a suitable output format for pipe:" [23:38:03 CEST] <furq> so if you just encode interlaced then it might not be that useful to you [23:38:06 CEST] <pa> i even specify -format matroska [23:38:08 CEST] <pa> but nothing [23:38:19 CEST] <pa> if i specify a file, say foo.mp4, things work [23:38:29 CEST] <pa> how can i pipe the output of ffmpeg? [23:38:42 CEST] <furq> -f, not -format [23:38:48 CEST] <pa> ah [23:38:51 CEST] <pa> -f matroska? [23:38:52 CEST] <pa> i try [23:38:54 CEST] <furq> yeah [23:38:54 CEST] <pa> thanks [23:39:24 CEST] <alexpigment> furq: well, I *do* deinterlace sometimes for some specific workflows, but it's not common. either way, it's a skill that I need under my belt at some point [23:40:09 CEST] <furq> the main annoyance with vs is that a lot of the filters (particularly qtgmc) depend on a bunch of nonstandard c libraries [23:40:27 CEST] <furq> if you're on windows you need to hunt all those down yourself [23:40:53 CEST] <furq> and of course these libs are all using the avisynth documentation model, which is forum posts on doom9 [23:41:04 CEST] <furq> so it's not particularly easy to even know what libs you need [23:41:17 CEST] <alexpigment> you've just described my exact situation [23:41:29 CEST] <alexpigment> on windows, and I don't like hunting through forum posts [23:41:39 CEST] <furq> yeah it can be a bit annoying [23:41:58 CEST] <furq> i figured it all out but i could probably upgrade half the libs by now [23:42:08 CEST] <furq> but there's not much chance of that [23:42:16 CEST] <alexpigment> hence why i hang out here. there's enough collective knowledge here, that I save a lot of frustration with undocumented stuff [23:42:28 CEST] <alexpigment> (and hopefully I don't ask dumb annoying questions too often) [23:42:35 CEST] <pa> furq: works indeed! [23:43:01 CEST] <pa> btw what's the fastest encoder i could use for grabbing screen?`space efficiency is not important at all, i'm piping it to a player [23:43:06 CEST] <pa> only cpu usage is [23:43:12 CEST] <furq> just use rawvideo then [23:43:19 CEST] <pa> ah awesome [23:43:20 CEST] <pa> i try [23:43:24 CEST] <pa> thanks agian [23:44:11 CEST] <durandal_170> utvideo [23:45:31 CEST] <pa> rawvideo seemingly not supported in matroska, i can force it, but then it doesnt play bwell [23:45:38 CEST] <furq> use -f nut [23:46:10 CEST] <alexpigment> so right now, I'm logging up several NVENC issues in an effort to get FFMPEG's implementation whipped into shape. does it seem overboard to log up several enhancement requests for explicit error messages on things that fail and give generic errors? [23:46:15 CEST] <durandal_170> .nut extension [23:46:17 CEST] <pa> thanks i try that [23:46:31 CEST] <furq> durandal_170: he's piping it to a player [23:47:09 CEST] <durandal_170> alexpigment: ask nvidia devs [23:47:35 CEST] <alexpigment> durandal_170: this request is specific to FFMPEG though, I would think [23:48:18 CEST] <alexpigment> If FFMPEG sees a bitrate that it knows is out of range for NVENC, FFMPEG could give a specific error message [23:49:02 CEST] <alexpigment> but maybe i'm thinking about this wrong, so feel free to state your case [23:49:13 CEST] <durandal_170> if ffmpeg knows.... [23:49:39 CEST] <alexpigment> ffmpeg is sentient now, right? ;) [23:50:20 CEST] <durandal_170> if nvenc exports that info [23:50:57 CEST] <alexpigment> durandal: I mean I know what the limits are now. 144Mbps for progressive, 37.5Mbps for interlaced [23:51:38 CEST] <alexpigment> I would think that information could be just parsed by ffmpeg and error out before it gives a generic NVENC error [23:53:59 CEST] <alexpigment> again, I accept that I could be misunderstanding how FFMPEG works and this may indeed be something for the Nvidia developers, but I was hoping for a "you're wrong and this is why" sort of response [00:00:00 CEST] --- Thu Jun 22 2017

1 0

ffmpeg-devel.log.20170620
by burek 21 Jun '17

21 Jun '17

[00:02:29 CEST] <nevcairiel> Gramner: now that the intel nda is officially over, do you have some numbers how much avx512 helps for x264? i would guess some single digit percentages at best? [00:03:37 CEST] <hanna> `master` fails building: make: *** No rule to make target 'libavcodec/x86/simple_idct.c', needed by 'libavcodec/x86/simple_idct.o'. Stop. [00:04:11 CEST] <durandal_1707> make clean [00:04:17 CEST] <iive> hanna: make distclean [00:04:19 CEST] <durandal_1707> make distclean [00:04:20 CEST] <Gramner> 5-10% faster overall vs avx2 on preset veryfast on a cpu with a single 512-bit ALU. note: on my early ES with low freqencies etc., don't know how well that correlates to retail cpu:s [00:04:27 CEST] <durandal_1707> configure [00:04:42 CEST] <Gramner> also it's not finished. still stuff left to optimize [00:05:11 CEST] <hanna> Ah, that fixes it (I ran `git clean -fdx`) [00:05:23 CEST] <J_Darnley> BBB: noted and tyvm. How many beers do we owe you yet? [00:05:41 CEST] <J_Darnley> Enough to die from alcohol poisoning I bet. [00:06:32 CEST] <wm4> so, why does nobody fix that build failures like this can happen? [00:06:44 CEST] <BBB> its ok, I hear france has much better medical care than me [00:06:47 CEST] <BBB> wm4: what happened? [00:06:54 CEST] <nevcairiel> wm4: because make is dumb [00:06:58 CEST] <wm4> BBB: see hanna's comment [00:07:06 CEST] <BBB> hanna: rm -f libavcodec/x86/simple_idct.d [00:07:14 CEST] <BBB> make it unfortunately kind of stupid, yes [00:07:15 CEST] <wm4> nevcairiel: never happens to me with my own makefile for my own project (also has "auto" deps) [00:07:31 CEST] <nevcairiel> if its in a .d file, make wont ignore it [00:07:50 CEST] <jamrial> wm4: do you often replace c files with asm files of the same name? because that's what generated that error :p [00:08:02 CEST] <J_Darnley> My bad [00:08:04 CEST] <BBB> it doesnt have to be the same name [00:08:05 CEST] <wm4> jamrial: it also happens if you remove files [00:08:07 CEST] <J_Darnley> and yes [00:08:08 CEST] <jkqxz> You're basically meant to clean after any update with the system we have. It's just that it usually doesn't break, because people rarely remove files. [00:08:09 CEST] <BBB> if its a different name, it still happens [00:08:20 CEST] <cone-329> ffmpeg 03Michael Niedermayer 07master:ae6f6d4e34b8: avcodec/x86/mpegvideo: Use intra scantable in dct_unquantize_h263_intra_mmx() [00:09:00 CEST] <BBB> michaelni: any idea why it used the inter scantable in h263_intra_mmx/c? [00:09:14 CEST] <BBB> also how about sending patches [00:09:40 CEST] <BBB> (note it does the same thing for C code also) [00:09:51 CEST] <J_Darnley> Hm. Does that obselete one of ours? [00:10:04 CEST] <BBB> line 228 in mpegvideo.c: [00:10:06 CEST] <BBB> nCoeffs= s->inter_scantable.raster_end[ s->block_last_index[n] ]; [00:10:19 CEST] <BBB> note inter_scantable use in function dct_unquantize_h263_intra_c() [00:10:22 CEST] <BBB> michaelni: ^^ [00:10:33 CEST] <TMM> crap, I accidentally merged two commits [00:10:36 CEST] <jamrial> curious fate wasn't affected. guess this code isn't tested? [00:10:36 CEST] <nevcairiel> Gramner: i'll definitely give it a try on a retail cpu, if you're interested in numbers. presumably the 10-core has 2 AVX512 ports as well, instead of just one like the 6 and 8 cores [00:10:55 CEST] <michaelni> BBB, i noticed, i changed it and i forgot to safe the file so it ended up not in the commit [00:11:02 CEST] <BBB> michaelni: ah, ok [00:11:13 CEST] <BBB> should send patch for review :-p [00:11:18 CEST] <BBB> anyway [00:11:23 CEST] <jamrial> BBB: git blame blames d50635cd247 [00:11:28 CEST] <J_Darnley> TMM: check `git reflog` then `git reset` [00:13:28 CEST] <BBB> michaelni: I think the confusing thing for me is: why is mpeg1/2 using the intra scantable for quantize_inter as well as intra, and why is (was) h263 using the inter scantable for quantize_intra as well as inter? [00:13:42 CEST] <michaelni> BBB either it was a copy / paste mistake that it was inter or it was an attempt to reduce data cache use but as its wrong it doesnt t realy metter [00:13:46 CEST] <BBB> michaelni: does that mean anything? or are they all typos? [00:13:59 CEST] <BBB> ok, that clears things up [00:14:05 CEST] <BBB> is the mpeg1 thing also buggy then? [00:14:25 CEST] <BBB> e.g. int j= s->intra_scantable.permutated[i]; in dct_unquantize_mpeg1_inter_c():92 [00:14:31 CEST] <michaelni> for mpeg1 inter=intra scantable so it should be fine [00:14:36 CEST] <BBB> aha, ok [00:14:43 CEST] <BBB> mpeg2 also? [00:17:19 CEST] <Gramner> nevcairiel: yeah, feel free to test. I'll be replacing my ES with a retail version as well later [00:18:34 CEST] <michaelni> BBB, yes mpeg2 also has intra == inter, it can be zigzag or alt scan depending on a bit in picture coding ext [00:18:44 CEST] <BBB> okay [00:19:11 CEST] <BBB> tnx [00:21:34 CEST] <BBB> J_Darnley: so Im guessing that (after the C function is updated), that patch can be dropped [00:21:42 CEST] <TMM> J_Darnley, thans [00:22:01 CEST] <J_Darnley> Mm. I will check though before discarding [00:24:07 CEST] <BBB> J_Darnley: good idea, tnx [00:43:57 CEST] <wm4> opinions? https://haasn.xyz/files/ffmpeg-threads/img.png [00:44:59 CEST] <iive> scan order should not depend on inter/intra, however normal/alt is used for progressive/interlaced pictures [00:45:04 CEST] <iive> however [00:45:18 CEST] <iive> quant tables does differ for inter/intra. [00:45:37 CEST] <Compn> speedup defined as ? [00:46:48 CEST] <nevcairiel> wm4: that graph needs more context, are there actually 32 cpu threads, or is it just flodding the cpu with more work [00:47:01 CEST] <wm4> hanna: please provide context lol [00:47:12 CEST] <hanna> 16 core CPU with hyperthreading [00:47:26 CEST] <wm4> nevcairiel: these are libavcodec threads [00:47:31 CEST] <hanna> speedup is defined as frames per second, normalized to single thread being the baseline [00:47:33 CEST] <wm4> AVCodecContext.threads or something [00:47:36 CEST] <hanna> ffmpeg -threads [00:47:49 CEST] <TMM> I really don't know how to git it seems [00:47:58 CEST] <hanna> hmm maybe I should have normalized it so that 1.0 is realtime [00:48:02 CEST] <hanna> that could have been more interesting in retrospect [00:48:12 CEST] <nevcairiel> wm4: i assumed that, but for the graph to make sense you still need to know how many threads the cpu actually can run at the same time [00:48:29 CEST] <wm4> right [00:48:30 CEST] <hanna> but since some of these clips inherently decode way faster than others (for some reason) it would also obscure the trend [00:48:48 CEST] <nevcairiel> the pink one is rather obscure with its "levels" [00:48:53 CEST] <hanna> I wonder what's up with the pink one yeah [00:49:12 CEST] <nevcairiel> perhaps enough to get a new reference frame into the decoder earlier [00:49:16 CEST] <hanna> I didn't go to great lengths to make sure the system had no other load at the time, so the numbers jittering occasionally makes sense [00:49:23 CEST] <nevcairiel> more threads = more "look ahead" [00:49:25 CEST] <hanna> but that seems too regular and weird to be just jitter [00:49:52 CEST] <nevcairiel> if it can work on more I frames in parallel (which are the most expensive), you can probably get more speed that way [00:50:02 CEST] <hanna> that would make sense [00:50:04 CEST] <nevcairiel> but yeah HEVC decode doesnt scale all that well [00:50:23 CEST] <hanna> I bet if you look up the I frame distribution in that pink clip it would match the number of threads needed per step [00:50:41 CEST] <nevcairiel> at one point someone was suggesting a combined frame/slice decode mode to speed up costly intra frames further [00:50:48 CEST] <hanna> I would if it wouldn't make more sense to load an I-frame per thread and have each thread do the P/B frames on its own [00:51:06 CEST] <hanna> or maybe those pink steps are P frames and not I frames [00:51:29 CEST] <hanna> either way, parallelize the ones that are the hardest and generate the ones that are easy on-demand [00:51:59 CEST] <nevcairiel> the threading is way too rigid for that [00:52:11 CEST] <hanna> maybe with some sort of hierarchical thing: each contiguous group of B-frames gets a single thread [00:52:14 CEST] <iive> hanna: at least with x264, the threads used to encode the video translated quite nicely to the threads used to decode the video [00:52:23 CEST] <atomnuker> Gramner: are there many places where avx512 can help x264? [00:52:31 CEST] <atomnuker> with blocks that small... [00:52:43 CEST] <nevcairiel> something like the idea above where you use slice thread to decode intra frames faster may help scaling on such clips [00:52:49 CEST] <iive> because the encoding was done in parallel and thus, less dependencies between the threads [00:53:07 CEST] <nevcairiel> especially if a clip is encoded with wavefront parallel processing [00:53:07 CEST] <hanna> it's possible the jump in the organge test was also such a phenomenon [00:53:14 CEST] <Gramner> a decent amount, yes. obviously a lot less than more modern video formats though [00:53:42 CEST] <iive> hanna: also, in the graph it seems that the speed saturates somewhere around 16 cores, that is also the number of physical cores. [00:53:54 CEST] <nevcairiel> thats no surprise [00:55:12 CEST] <wm4> so I assume libavcodec frame threading is not advanced enough to decode multiple GOPs in parallel given enough worker threads? [00:55:31 CEST] <hanna> iive: I'm not sure if I'm seeing that [00:55:34 CEST] <hanna> for the blue clip yes [00:55:38 CEST] <hanna> for the orange it keeps going up [00:55:42 CEST] <hanna> for the green it saturates way earlier [00:55:43 CEST] <nevcairiel> it'll decode as many frames as you have threads [00:55:45 CEST] <hanna> for the pink it also keeps going up [00:56:02 CEST] <nevcairiel> but of course it doesn't try to be s mart about it [00:56:12 CEST] <nevcairiel> it just decodes the next X frames [00:56:51 CEST] <hanna> it's actually technically two 8 core CPUs with NUMA in between them, I would expect that to maybe introduce some sort of extra overhead after 8 cores [00:57:07 CEST] <wm4> I'm wondering whether it'd make sense to make things async (with packet and frame queues) to reuse the worker threads faster or so [00:57:34 CEST] <hanna> wm4: the most important speedup would be to have lavc decode directly to GPU-mapped buffers [00:57:38 CEST] <hanna> instead of doing the extra memcpy() [00:57:47 CEST] <iive> hanna: it does keep going up, but at much smaller rate. basically +2 speed for 16 more threads. [00:57:51 CEST] <hanna> you could steal atomnuker's code from his vulkan branch for this [00:57:52 CEST] <wm4> hanna: that's possible with the API [00:57:55 CEST] <hanna> that one helps a _lot_ [00:58:07 CEST] <nevcairiel> doubtful that has a huge impact, since if an early thread is still busy any following frames will likely depend on it [00:58:12 CEST] <hanna> and would almost surely make your frame queue thing irrelevant [00:58:12 CEST] <wm4> but we're stuck with OpenGL, so... [00:58:18 CEST] <hanna> wm4: OpenGL can do this too [00:58:21 CEST] <hanna> that's what PBOs are for, right? [00:58:33 CEST] <iive> hanna: are you sure you are not going to hit PCIE limit? [00:58:43 CEST] <wm4> hanna: the decoder needs to be able to read from the frames even while the renderer uses them [00:58:57 CEST] <wm4> classic PBOs AFAIK can't do this, altrhough newer GL things can [00:58:58 CEST] <iive> the problem is that frames are used as reference and need to be read back. [00:59:11 CEST] <wm4> (and then you have to do synchronization manually) [00:59:42 CEST] <wm4> atomnuker: when you tried with vulkan, how much did marking get_buffer2 as thread-safe help? [00:59:45 CEST] <nevcairiel> in my experience the upload to the gpu doesnt really limit that many things, you can spin that off into a different thread and dont block the decoder [01:00:07 CEST] <iive> also, gpu can use dma to upload [01:00:19 CEST] <hanna> iive: suppose each frame needs to be written to once and read back once, that gives us an approximate bandwidth consumption for 4K 60 Hz 10-bit 4:2:0 content of 7.5 Gbps [01:00:28 CEST] <hanna> iive: actually [01:00:48 CEST] <iive> hanna: with 16 ref frames for h264... you can do a lot of reading. [01:00:57 CEST] <hanna> iive: I don't think this goes through PCIe at all [01:01:16 CEST] <hanna> GPU mapped buffers are still in system RAM, but the GPU DMA engine can access them [01:01:28 CEST] <wm4> hanna: could also be that we should try to pipeline upload better [01:01:39 CEST] <hanna> what happens under the hood is a vkCmdCopyBufferToImage call (or w/e it's called) which copies out from the VkBuffer (on system memory) into the VkImage (on GPU memory) [01:01:41 CEST] <hanna> using the DMA engine [01:01:51 CEST] <hanna> but this is free CPU-wise (no memcpy) [01:02:04 CEST] <iive> hanna: hum, I though that the dma is not limited to specific range [01:02:16 CEST] <iive> anymore [01:02:19 CEST] <atomnuker> wm4: significantly with 8k30 and 4k60 [01:02:24 CEST] <hanna> whereas what happens in the vo_opengl example currently is: 1. decode to buffer malloc()'d by lavc, 2. memcpy() into buffer malloc'd by OpenGL driver, 3. DMA engine copies out from this driver-allocated buffer [01:03:04 CEST] <wm4> hanna: we also try to use the texture immediately after issuing the copy, which might not be ideal [01:03:12 CEST] <wm4> but who knows how many other pipeline stalls there are [01:03:22 CEST] <hanna> most OpenGL drivers optimize client-side pixel transfers by copying the data to internal memory anyway. from the opengl wiki page on PBOs [01:03:25 CEST] <nevcairiel> unless your system is super low powered, the s ingle memcpy shouldn't really hurt that many things, spin it into its own thread to not block the decoder, and it should be fine [01:03:39 CEST] <atomnuker> though if you can map a buffer with a device memory vkcmdcopybuffertoimage is free :) [01:03:46 CEST] <wm4> hanna: yeah, still brought a speedup in some situations though (which is ????) [01:03:53 CEST] <atomnuker> even better on intel where gpu memory == system memory [01:04:06 CEST] <nevcairiel> for the upload itself, NVIDIA actually has dedicated copy engines for OpenGL PBOs, and you can use fences to get signaled when its done uploading to avoid a stall in the render pipeline [01:04:17 CEST] <hanna> nevcairiel: the memcpy() is in the VO thread which can block for longer than the duration of a vsync when the machine needs to access memory from the other CPU iirc [01:04:27 CEST] <hanna> and also for random reasons otherwise [01:04:36 CEST] <hanna> forcing all allocations to come from the same NUMA node helps but doesn't completely eliminate it [01:04:42 CEST] <nevcairiel> then move it out of that thread, why does it have to be in there? =p [01:04:47 CEST] <hanna> it also takes a non-trivial amount of time overall [01:04:47 CEST] <wm4> hanna: so I think we should try uploading a few frames ahead, with dedicated PBOs, which should be pretty simple with the infrastructure for interpolation [01:04:58 CEST] <hanna> nevcairiel: that's actually what I did in my vo_vulkan test, I had a thread dedicated to the memcpy()ing [01:05:02 CEST] <hanna> but it's annoying for many reasons [01:05:13 CEST] <hanna> wm4: possible [01:05:19 CEST] <hanna> wm4: I mean we essentially already do this for interpolation [01:05:29 CEST] <nevcairiel> uploading PBOs is actually one of the only things that you can properly multi-thread even in OpenGL .. and GL otherwise hates any sort of threading [01:05:32 CEST] <atomnuker> wm4: btw the vo.h changes allow VOs to flag for threadsafe buffer using VO_CAP_GET_BUFFER_THREADSAFE [01:05:33 CEST] <wm4> hanna: interpolation also uses the texture immediately [01:05:35 CEST] <hanna> although interpolation uploads and then immediately accesses them [01:05:37 CEST] <hanna> yeah [01:05:41 CEST] <wm4> hanna: we just need to add an "offset" [01:06:30 CEST] <hanna> ;Most of what you gain is the ability to load data directly into the PBO itself, which means that OpenGL won't need to copy it. You may even be able to stream data directly from disk into a mapped buffer. [01:06:34 CEST] <hanna> this is literally what we would need to do [01:06:44 CEST] <hanna> wm4: I'm pretty sure we just need to copy/paste the vo_vulkan code from atomnuker's branch [01:06:50 CEST] <hanna> 1. allocate PBOs, 2. give these to vd_lavc, let it decode into them [01:07:16 CEST] <hanna> this avoids the memcpy() and everybody's happy [01:07:25 CEST] <wm4> hanna: feel free to try [01:07:26 CEST] <hanna> there's also some CUDA shit we could do [01:07:34 CEST] <hanna> I hate OpenGL :p [01:07:47 CEST] <wm4> well yeah maybe it's easier to use cuda surfaces [01:08:01 CEST] <hanna> CUDA lets you basically take an existing memory region (not allocated by the driver) and make it GPU-visible [01:08:04 CEST] <hanna> so the DMA engine can then copy out of it [01:08:04 CEST] <wm4> although these requires weird on-GPU memcpys [01:08:14 CEST] <hanna> but iirc OpenGL itself does not inherently let you do this [01:08:23 CEST] <wm4> (or maybe this case is too hardcoded for ffmpeg cuvid) [01:08:23 CEST] <hanna> you have to let the driver allocate the buffer for you [01:08:26 CEST] <nevcairiel> you need to keep the PBOs mapped for way long, OGL may not like that [01:08:36 CEST] <wm4> nevcairiel: yes, that needs newer stuff [01:08:45 CEST] <TMM> goddamnit, whenever I rebase edit one of the commits I end up with a merge conflict and when I resolve it git merges the two commits [01:08:58 CEST] <wm4> and the "do it correctly or the driver will abort()" kind of manual synchronization [01:09:21 CEST] <hanna> https://en.wikipedia.org/wiki/CUDA_Pinned_memory this thing iirc [01:09:22 CEST] <wm4> TMM: you're doing something wrong [01:09:30 CEST] <TMM> wm4, I have no doubt :) [01:09:47 CEST] <wm4> hanna: why does it have a wikipedia page [01:10:05 CEST] <nevcairiel> with classic PBOs the problem is that it would only flush it to the GPU when you unmap it, and you can only unmap it when the frame is removed from the DPB ... which would be way too late. Not sure what these more modern extensions really do [01:10:09 CEST] <hanna> Non-locked / non-pinned memory does not reside only in main memory (e.g. it can be in swap), so the driver needs to access every single page of the non-locked memory, copy it into pinned buffer and pass it to the Direct Memory Access (DMA) (synchronously page-by-page copy). [01:10:17 CEST] <hanna> ^ this is the situation with OpenGL as well [01:10:24 CEST] <hanna> the opengl driver copies it into pinned memory [01:10:40 CEST] <hanna> which is why we can't just take vd_lavc's char* and somehow give it to the GPU, it's not pinned [01:10:42 CEST] <wm4> nevcairiel: the modern extensions (and maybe standard in one of the 4.x versions) let you keep it mapped, somehow [01:10:54 CEST] <hanna> and may be paged, moved around, compressed, swapped etc. by the kernel [01:10:56 CEST] <hanna> at any time [01:11:52 CEST] <hanna> To allocate page-locked memory on the host in CUDA language one could use cudaHostAlloc.[3] [01:12:12 CEST] <hanna> 03>Allocates size bytes of host memory that is page-locked and accessible to the device. The driver tracks the virtual memory ranges allocated with this function and automatically accelerates calls to functions such as cudaMemcpy(). [01:12:36 CEST] <hanna> but then how to import it as an OpenGL texture? lol [01:13:57 CEST] <hanna> https://github.com/nvpro-samples/gl_cuda_interop_pingpong_st seems there is an interop API [01:14:36 CEST] <nevcairiel> cuda gl interop exists, but its a bit iffy [01:15:33 CEST] <hanna> https://www.cs.cmu.edu/afs/cs/academic/class/15668-s11/www/cuda-doc/html/gr… [01:15:51 CEST] <TMM> oh, I think it's because I committed the patches not rebased them [01:16:01 CEST] <hanna> and then maybe you can use the cuda memcpy thing to copy from the cudaHostAlloc'd buffer to this registered image [01:16:11 CEST] <hanna> TMM: `rebase -i` is your friend [01:16:54 CEST] <nevcairiel> cudaHostAlloc docs warn about using it to allocate too much memory, but who knows how much is "too much" :D [01:17:13 CEST] <rcombs> this reminds me, is it generally possible to convert/remap a buffer between "regular" (WB) and "video" (WC) memory on Intel? [01:28:16 CEST] <iive> rcombs: in theory these are controlled by registers or page table attributes [01:28:34 CEST] <iive> i mean, mtrr or pta [01:40:19 CEST] <hanna> nevcairiel: probably if the kernel can no longer find contiguous memory regions big enough to fit your allocations [01:40:30 CEST] <hanna> since pinning means it has to be contiguous in physical memory, right? [01:41:14 CEST] <philipl_> hanna: mpv already uses the cuda GL interop to transfer cuvid decoded frames in vo_opengl [01:41:45 CEST] <hanna> philipl: oh neat, so in theory we could piggy-back on top of this as a new hwdec type that uses libavcodec but allocates frames using cudaHostAlloc instead? [01:42:35 CEST] <hanna> also why is there commented-out code in hw_cuda.c [01:43:06 CEST] <hanna> oh, that entire file is for the old CUDA API [01:43:11 CEST] <hanna> whatever that means [01:44:23 CEST] <philipl> Look at the hwdec implementation to see how it's used. It's all very simple in that context. [01:44:24 CEST] <hanna> Oh, the code I'm looking for is hwdec_cuda.c [01:44:29 CEST] <philipl> Yeah [01:44:52 CEST] <philipl> So, I don't know what you're actually trying to do. You want to optimize memcpy for software decoding? [01:45:15 CEST] <philipl> If it's in the context of some vo_vulkan with cuvid, nvidia have yet to explain the right way to do gpu side buffer sharing. [01:45:38 CEST] <philipl> There's no vulkan/cuda interop and vk_external_memory seems incomplete without a cuda side api [01:45:43 CEST] <hanna> philipl: No, the context has nothing to do with vulkan and nothing to do with cuvid [01:45:57 CEST] <hanna> philipl: I want to eliminate the memcpy() from vo_opengl [01:46:11 CEST] <philipl> Ok. [01:46:36 CEST] <hanna> the idea is to make vd_lavc use cudaHostAlloc() instead of malloc() and then replace memcpy() by cuMemcpy2D() [01:46:51 CEST] <hanna> (which uses the GPU's DMA engine instead of the host's RAM bandwidth and CPU time) [01:47:14 CEST] <hanna> well it still uses RAM bandwidth but less [01:47:26 CEST] <hanna> 1x read instead of 1x read + 1x write + 1x read [01:48:58 CEST] <hanna> philipl: in theory it should be possible to re-use this code with minor modifications; it wouldn't really be a `hwdec` though, more of a `cuda_swdec` [01:49:13 CEST] <hanna> maybe --hwdec=cuda-memcpy [04:55:38 CEST] <philipl_> hanna`: neat. I'd be interested to see how much difference it makes. [10:05:07 CEST] <cone-165> ffmpeg 03wm4 07master:f1df7cc10c62: ffmpeg: remove misleading and incorrect warning messages [10:24:20 CEST] <ubitux> why do we have an AVProgram.program_num and an AVProgram.id? [10:32:27 CEST] <wm4> doesn't only the .ts demuxer use this [10:34:07 CEST] <nevcairiel> basically, yes [10:34:22 CEST] <nevcairiel> hls also uses it for variant streams, but it doesnt set any of those fancy fields [11:13:02 CEST] <wm4> hm did merges completely stop? [11:18:36 CEST] <ubitux> someone needs to merge the dash stuff [11:18:47 CEST] <ubitux> and i really wasn't motivated to do it [11:19:43 CEST] <wm4> libav really made dash changes we don't have? [11:21:23 CEST] <ubitux> yes, afaik [11:21:26 CEST] <ubitux> and the other way around [11:21:30 CEST] <ubitux> it's clashing [11:21:45 CEST] <ubitux> feel free to look at this, because i won't [11:27:35 CEST] <wm4> yeah those changes look pretty wild [11:36:48 CEST] <durandal_1707> can i push random libav patches? not as merge, not as cherrypick.? [11:37:50 CEST] <nevcairiel> they kinda are either one or the other, are they not? :p [11:42:26 CEST] <wm4> I'd say that is ok, as long as the merges are trivial enough and pass fate [11:42:42 CEST] <wm4> but mark them as merges in the commit msg [11:44:00 CEST] <iive> patches should go through review, either in ffmpeg or in libav. [11:45:02 CEST] <ubitux> durandal_1707: please reference the original commit hash from Libav [11:45:06 CEST] <ubitux> it helps to noop the merge [11:45:17 CEST] <ubitux> and document the differences if appropriate [11:45:19 CEST] <nevcairiel> (so basically, do a cherry-pick) [11:45:22 CEST] <ubitux> yeah. [11:45:29 CEST] <ubitux> cherry-pick -x [11:45:58 CEST] <ubitux> btw, we're again at 400+ commits to merge [11:59:44 CEST] <cone-165> ffmpeg 03Diego Biurrun 07master:155f071bad5a: build: Add missing idctdsp dependency for clearvideo [12:13:24 CEST] <wm4> ubitux: any specific format we should use when referencing libav commit hashes? [12:13:56 CEST] <ubitux> cherry-pick -x is fine, i usually just --grep the hash in the log [12:14:11 CEST] <ubitux> as long as it's present in the log history, it's fine [12:14:16 CEST] <ubitux> preferably not shorten [13:00:01 CEST] <J_Darnley> BBB: did you discover anything with the mov file? [13:16:00 CEST] <J_Darnley> Did anyone have any objections against me pushing the first 2 patches of my set? The two for avcodec/x86/mpegvideoenc_template.c? [13:27:42 CEST] <BBB> J_Darnley: if its approved, push it [13:28:10 CEST] <BBB> J_Darnley: havent looked at mov file yet, just woke up, need to have bath and get to work, then Ill look [13:28:21 CEST] <J_Darnley> That's fine [13:29:33 CEST] <cone-165> ffmpeg 03James Darnley 07master:fa30a0a54854: avcodec/x86/mpegenc: check IDCT permutation type is a valid value [13:29:34 CEST] <cone-165> ffmpeg 03James Darnley 07master:e3db94302c79: avcodec/x86/mpegenc: support transpose permuation type [13:35:43 CEST] <BBB> J_Darnley: can you also push some of the clean-up patches to the 10-bit assembly template file? [13:35:50 CEST] <BBB> or is there a patch missing approval in that series? [13:36:05 CEST] <J_Darnley> I'll check [13:39:14 CEST] <J_Darnley> You've signed off on 2 of 4 so I can push those [13:40:00 CEST] <TMM> It seems that line length, comment style and other formatting style things in all the MVE related files are kind of all over the place [13:40:09 CEST] <TMM> should I submit a patch that normalizes all of that? [13:40:32 CEST] <TMM> some of the old comments are also super outdated, even compared to after my changes [13:40:43 CEST] <TMM> err compared to *before* my changes [13:42:24 CEST] <cone-165> ffmpeg 03James Darnley 07master:8781330d80e3: avcodec/x86: cleanup simple_idct10 [13:42:25 CEST] <cone-165> ffmpeg 03James Darnley 07master:d2597fb0c1c8: avcodec/x86: modify simple_idct10 macros to add an action paramter [13:57:15 CEST] <BBB> I just reviewed 8/9 [13:57:18 CEST] <BBB> 6/7 already pushed [13:57:25 CEST] <BBB> 1/2 also pushed [13:57:40 CEST] <BBB> 5 not needed [13:57:44 CEST] <BBB> 3-4 and 10-11 still todo? [13:57:57 CEST] <BBB> 3-4 is mdec... [13:58:10 CEST] <BBB> 10 awaits my mov thing [13:58:15 CEST] <BBB> 11 is the simple change [13:58:16 CEST] <BBB> ok [13:58:36 CEST] <BBB> you said youd do the changes to mdec to work, right? [13:59:59 CEST] <J_Darnley> Yes [14:00:50 CEST] <BBB> J_Darnley: I changed my opinion on 3, just push as-is [14:01:06 CEST] <BBB> 4 needs some modifications as suggested by michaelni, theres example code elsewhere of how to do that [14:01:33 CEST] <J_Darnley> I'm sure I'll manage [14:02:00 CEST] <BBB> e.g. mpegvideo_enc.c:1013-1033 [14:02:04 CEST] <BBB> ok :) [14:02:28 CEST] <J_Darnley> I've got other things to do so I will just do the "push as is" ones for now [14:05:04 CEST] <BBB> I notice youre also tired of this patchset :-p [14:05:52 CEST] <J_Darnley> Well yes, partly. But I also feel like I'm not working on the things kierank wants me to work on. [14:06:55 CEST] <cone-165> ffmpeg 03James Darnley 07master:9d11fedd1129: avcodec/mdec: override IDCT choice before initing DSP structs [14:09:07 CEST] <kierank> BBB: yeah, there's stuff we need to do at job [14:21:22 CEST] <BBB> :-p [14:21:38 CEST] <BBB> Ill test if the idct simple override in mdec is still needed [14:21:41 CEST] <BBB> I dont think it is [14:21:51 CEST] <BBB> I think the reason it was there is because of the zigzag bug which also affected the mmx simd [14:22:00 CEST] <BBB> with that fixed (4/11), that patch can go [14:22:17 CEST] <BBB> s/patch/code/ [14:22:19 CEST] <BBB> anyway [14:22:22 CEST] <BBB> Ill do that part [14:22:31 CEST] <BBB> I think its mostly done anyway [14:38:13 CEST] <kierank> BBB: sorry :) [14:38:14 CEST] <kierank> :( [14:38:24 CEST] <BBB> I get it [14:47:44 CEST] <BBB> patch for mdec sent [14:48:20 CEST] <BBB> I probably need to rebase it on top of j_darnleys pushed patch, but then his patchset is pushed all the way until 9/11 [15:04:37 CEST] <BBB> J_Darnley: that one was fairly simple [15:05:56 CEST] <J_Darnley> ah you did that in the end [15:06:42 CEST] <BBB> I meant the .mov file michaelni says changed [15:07:05 CEST] <J_Darnley> oh my mistake [16:35:40 CEST] <J_Darnley> Does anyone know how to fast-forward a local branch I'm not on to the current HEAD? [17:15:38 CEST] Action: J_Darnley curses git [17:16:07 CEST] <tdjones> You want the other branch to have the same head as the branch you're on? [17:17:06 CEST] <iive> i think he is detached from the current HEAD of the branch [17:48:30 CEST] <durandal_1707> who the fuck designed activate in lavfi? [18:26:28 CEST] <jamrial> durandal_1707: a reason why the ticket is "invalid" would be helpful there [18:40:09 CEST] <TMM> evening all [18:44:46 CEST] <cone-165> ffmpeg 03James Darnley 07master:8221c7170317: avcodec/x86: allow future 8-bit simple idct to use slightly different coefficients [18:55:15 CEST] <atomnuker> why does VBROADCASTSD not work with 2 registers and only accepts 1 register and 1 address [18:55:25 CEST] <atomnuker> the non-macro version supports 2 registers [18:56:56 CEST] <jamrial> atomnuker: that macro was written before avx2 was a thing i guess [18:56:59 CEST] <atomnuker> also what's the alternative to movlhps? using INIT_YMM instead of xmm results in "invalid combination of opcode and operands" when using it to splat 2 floats to the entire register [18:57:47 CEST] <J_Darnley> vbroadcastq? [18:57:52 CEST] <jamrial> with avx, you need to splat using xmm then vinsertf128 to splat to the upper half of the reg [18:58:06 CEST] <atomnuker> I'm only using 1/2 the full reg here [18:58:14 CEST] <jamrial> with avx2 you have vbroadcastsd [18:59:17 CEST] <atomnuker> vbroadcastsd still makes nasm print the same error [18:59:38 CEST] <jamrial> using what? [18:59:43 CEST] <atomnuker> 2 registers [18:59:51 CEST] <jamrial> xmm source and ymm dest? [18:59:58 CEST] <jamrial> otherwise it wont work [18:59:59 CEST] <atomnuker> no, both ymm [19:00:02 CEST] <atomnuker> ah, ok [19:00:03 CEST] <jamrial> that wont work :p [19:00:19 CEST] <atomnuker> wait, I can combine xmm and ymm regs? [19:00:27 CEST] <atomnuker> I thought once I INIT_XMM/YMM, that was it [19:00:46 CEST] <J_Darnley> xmN ymN [19:00:46 CEST] <jamrial> that just makes the m* alias expand into either xmm or ymm [19:01:08 CEST] <jamrial> use the xm* alias to force xmm regs when you use INIT_YMM [19:02:49 CEST] <jamrial> INIT_XMM -> m0 == xmm0, xm0 == xmm0 [19:02:53 CEST] <jamrial> INIT_YMM -> m0 == ymm0, xm0 == xmm0 [19:04:40 CEST] <iive> you can overried register with prefixing it xmm%1 , there are redefines xmmymm into xmm. [19:05:57 CEST] <iive> atomnuker: i have vbroadcastss emulation in my patch, you can easy change it to *sd [19:34:18 CEST] <BtbN> hm, I can't think of a clean way to make ffmpeg.c automatically use the cuvid/qsv variants of decoders [19:40:50 CEST] <durandal_1707> nice way to troll us: write convoluted code nobody understand [20:17:20 CEST] <BBB> J_Darnley: Ill push [20:17:45 CEST] <BBB> J_Darnley: just waiting for michaelni to wake up and see if he objects [20:18:32 CEST] <J_Darnley> noted [22:15:44 CEST] <cone-973> ffmpeg 03John Rummell 07master:966a0a814d4e: avcodec/decode: Update decode_simple_internal() to get the side data correctly. [22:56:54 CEST] <atomnuker> what's the standard way of moving 2 xmm vectors into 1 ymm vector (1 high and 1 low)? [23:01:34 CEST] <Gramner> vinserti128 [23:03:03 CEST] <nevcairiel> the xmm regs are basically half of the actual ymm regs, arent they? so mova the low part into xm0, and vinserti128 the high part into ym0? [23:03:34 CEST] <atomnuker> vinserti128 m4, m4, xm5 -> invalid combination of opcode and operands [23:04:00 CEST] <nevcairiel> it needs a imm8 as the 4th argument [23:04:11 CEST] <nevcairiel> to control it [23:04:26 CEST] <atomnuker> oh [23:04:35 CEST] <atomnuker> btw, mova m4, xmm5 -> invalid combination of opcode and operands [23:05:33 CEST] <nevcairiel> afaik, 0 for low, 1 for high, in the imm8 [23:06:33 CEST] <nevcairiel> to fill a full ymm, you would do like: mova xm4, xm5; vinserti128 m4, m4, xm6, 1; [23:06:45 CEST] <nevcairiel> (or just take over xm5 if you dont need it anymore) [23:07:13 CEST] <atomnuker> oh, ok, you can switch between ymm and xmm without losing data then [23:07:35 CEST] <nevcairiel> well, you can go upwards i think, down requires zeroing the upper parts [23:07:53 CEST] <nevcairiel> or something [23:08:28 CEST] <jamrial> <@atomnuker> btw, mova m4, xmm5 -> invalid combination of opcode and operands [23:08:29 CEST] <Gramner> vinserti128 dst, src_low(ymm), src_high(xmm), 1 [23:08:29 CEST] <jamrial> mova ymm, xmm is of course invalid [23:13:52 CEST] <TMM> with regular registers I don't think that going from al/ah to eax/rax ever destroys data [23:15:27 CEST] <nevcairiel> well you just have to hope the datatype you have in there thought of that :) but thats not a problem with simd regs anyway, since you increase the number of elements, not the size of the data [23:20:15 CEST] <atomnuker> having 8 floats in 1 registers is huge, how can anyone deal with this many values, this should be outlawed [23:20:29 CEST] <J_Darnley> :) [23:20:29 CEST] <atomnuker> btw is there any way to not resolve arguments passed to macros? [23:20:30 CEST] <BBB> you poor fellow [23:20:37 CEST] <BBB> we integer people use 32 values per register [23:20:43 CEST] <BBB> muhahahaha [23:20:47 CEST] <BBB> :-p [23:20:59 CEST] <TMM> Pff, I write only code using short ints [23:21:01 CEST] <atomnuker> e.g. FFT5 m4 when INIT_YMM is on resolves the m4 to ymm4 and replaces it in the macro [23:21:03 CEST] <nevcairiel> i have a cpu on the way that fits 16 floats, get with the times [23:21:05 CEST] <TMM> I do 64 values per register [23:21:28 CEST] <durandal_170> write asm for ffr [23:21:35 CEST] <atomnuker> ffr? [23:21:42 CEST] <BBB> atomnuker: if you want it to stay m so you can do x%d or y%d, use just 4 as arugment [23:21:57 CEST] <BBB> atomnuker: see e.g. how transposeNxN do that [23:22:00 CEST] <atomnuker> yeah, but I use just "4" just before it as an offset [23:22:10 CEST] <atomnuker> and it looked kinda bad, but w/e, it works [23:22:18 CEST] <BBB> its a little shitty yes [23:22:27 CEST] <BBB> assembly is never super-pretty :( [23:22:41 CEST] <BBB> especially if you only have 8 floats instead of 32 uint8_ts <evil> [23:22:44 CEST] <BBB> :-p [23:22:47 CEST] <atomnuker> it was before I decided I could use huge registers [23:22:49 CEST] <rcombs> atomnuker: pretty much anything _writing_ to an xmm will zero the upper 128 bits if V-prefixed and leave them unmodified if not [23:23:13 CEST] <durandal_170> fft [23:23:15 CEST] <rcombs> while reading is nondestructive [23:23:20 CEST] <atomnuker> now I can't think about it looking ugly, I have 8 floats in 1 register [23:23:42 CEST] <atomnuker> durandal_170: I plan to some day, fft64 doesn't have simd and its generated by lesser ffts [23:23:57 CEST] <atomnuker> (this is for opus/aac's mdct15 which uses a 15-point fft) [23:24:14 CEST] <atomnuker> 15 complex values -> 30 floats [23:24:37 CEST] <rcombs> (also, mixing VEX-prefixed vector instructions with non-VEX-prefixed ones is a very bad idea, but x86inc makes it easy not to do that) [23:24:46 CEST] <rcombs> oh this reminds me [23:24:57 CEST] <nevcairiel> if you're using floats, shouldnt it be vinsertf128 instead of the "i" variant to avoid the float/int context thing? [23:25:10 CEST] <rcombs> does nasm have the same issue as yasm, where if your code is macro-ized, it's impossible to get any useful line number information out of diagnostics [23:25:20 CEST] <jamrial> yes, and also because the integer ones are avx2, not avx [23:25:51 CEST] <rcombs> even at compile-time, if you fucked up operands yasm would tell you there was an error on the line the macro was invoked on, rather than the line in the macro that was wrong [23:25:54 CEST] <Gramner> yes, f for floats [23:26:00 CEST] <atomnuker> rcombs: nope, it works fine for me [23:26:07 CEST] <rcombs> GOOD [23:26:09 CEST] <atomnuker> prints the error inside the macro on the correct line [23:26:16 CEST] <rcombs> EXCELLENT [23:26:38 CEST] <BBB> whats nasm? [23:26:46 CEST] <BBB> are we on that again? [23:26:50 CEST] <BBB> is it in macports? [23:26:59 CEST] <nevcairiel> yasm is dead [23:27:08 CEST] <nevcairiel> nasm supports new things like avx512 [23:27:13 CEST] <BBB> nasm @2.13.01 (lang) [23:27:15 CEST] <rcombs> >macports [23:27:16 CEST] <BBB> is that good enough? [23:27:20 CEST] <Gramner> yes [23:27:21 CEST] <rcombs> is that actually a thing people still use [23:27:23 CEST] <nevcairiel> yes thats the most recent version [23:27:28 CEST] <BBB> rcombs: what should I use then? [23:27:29 CEST] <rcombs> isn't everyone on brew now [23:27:40 CEST] <rcombs> BBB: brew sucks about 95% less than port and fink [23:27:42 CEST] <BBB> I can try brew, I dont know anything dude :D [23:27:57 CEST] <BBB> I use stuff because it worked 100 years ago and Im too lazy to try anything else [23:28:32 CEST] <rcombs> oh, also [23:28:43 CEST] <rcombs> does nasm write debug information in Mach-O [23:28:59 CEST] <rcombs> and function bounds, and such [23:29:10 CEST] <BBB> does nasm have the same CLI invocation as yasm? [23:29:21 CEST] <Gramner> it has macho-o dwarf debug support [23:29:22 CEST] <BBB> nope [23:29:40 CEST] <rcombs> nice [23:29:43 CEST] <nevcairiel> its similar-ish, but ffmpeg build system should support both [23:30:05 CEST] <Gramner> but you can make command lines that works with both nasm and yasm [23:33:29 CEST] <jamrial> does anyone know what's this DBG stuff in the build system that creates .dbg.asm files and how do i enable/test it? [23:34:45 CEST] <iive> jamrial: it is like gcc -S, runs only the pre-processor, and then strips the debug information from the result file [23:35:07 CEST] <jamrial> how do i enable it? a configure option? [23:35:15 CEST] <iive> so in case of error, you get meaningful line of error, instead the address of the big macro [23:35:32 CEST] <iive> jamrial: make variable [23:37:37 CEST] <jamrial> iive: which one? DBG doesn't seem to work [23:37:46 CEST] <iive> let me rephrase, if compilation fails, the yasm and old nasm would usually give the line where the error hapened, in our case it would be the single line with the macro that contains the implemented function. [23:37:53 CEST] <iive> make DBG=1 ? [23:38:12 CEST] <Compn> iive : is it a nasm/yasm flag ? [23:38:22 CEST] <iive> Compn: no [23:38:59 CEST] <rcombs> sounds like that's fixed in current nasa? [23:39:01 CEST] <rcombs> *nasm [23:39:12 CEST] <rcombs> (going by what atomnuker said) [23:39:19 CEST] <rcombs> I used to sometimes do that manually [23:39:35 CEST] <jamrial> iive: ah, i see, i need to call "make whatever.dbg.asm DBG=1", not "make whatever.o DBG=1" for it [23:39:39 CEST] <jamrial> thanks [23:39:50 CEST] <nevcairiel> are you sure you even need the DBG=1 then [23:40:13 CEST] <nevcairiel> you can do like whatever.S/i as well to get gcc to give you various intermediates [23:40:15 CEST] <iive> it calls yasm -e , this just expands all macros and writes the result in a temp file. then strips that file from debugging information, because yasm actually keeps like data in that file [23:40:45 CEST] <jamrial> nevcairiel: apparently not because the command is harcoded to use DEFAULT_YASMD instead of YASMD, which is what DBG sets [23:40:46 CEST] <iive> then compiles the stripped file, so if some instruction fails compilation, you get the line number in the temp stripped file. [23:41:51 CEST] <iive> s/like data/ line data [23:50:40 CEST] <wm4> can't wait until nasm dies and yasm undies again [23:51:06 CEST] <durandal_170> w h y ? [23:51:36 CEST] <jamrial> yasm-ng [23:51:51 CEST] <BBB> nasm doesnt seem to deal with -I and %includes in subpaths correctly [23:51:52 CEST] <iive> zasm! [23:51:57 CEST] <iive> for zmm registers [23:52:06 CEST] <BBB> I have -I .. and %include path/to/bla.asm [23:52:12 CEST] <BBB> with bla.asm being in ../path/to/ [23:52:14 CEST] <BBB> and it cant find it [23:52:17 CEST] <BBB> yasm finds it correctly [23:52:23 CEST] <BBB> so thats the end of me using nasm for the day [23:52:33 CEST] <durandal_170> write patch [23:52:39 CEST] <BBB> why [23:52:42 CEST] <BBB> yasm works correctly ;) [23:52:49 CEST] <BBB> Im not activist about which assembler I use [23:52:52 CEST] <BBB> its a tool, not a goal [23:52:52 CEST] <iive> write bugreport [23:52:55 CEST] <atomnuker> avx512 [23:52:56 CEST] <BBB> I dont care about yasm vs nasm [23:53:00 CEST] <BBB> people tell me nasm is amazing [23:53:02 CEST] <BBB> I test it, it fails [23:53:04 CEST] <BBB> I complain [23:53:07 CEST] <BBB> and move on with my life [23:53:08 CEST] <BBB> ;) [23:53:19 CEST] <durandal_170> but yasm is d e a d [00:00:00 CEST] --- Wed Jun 21 2017

1 0

ffmpeg.log.20170620
by burek 21 Jun '17

21 Jun '17

[00:00:33 CEST] <furq> you might want to look at line 551 as well [00:01:50 CEST] <durandal_1707> ugh, are you sure looking at right source code? [00:02:41 CEST] <durandal_1707> i mean nothing in ffmpeg should use libavresample [00:02:46 CEST] <furq> i was talking to fiera [00:03:04 CEST] <furq> line 551 is #if CONFIG_AVRESAMPLE [00:03:23 CEST] <durandal_1707> but even that shouldnt exist [00:03:40 CEST] <durandal_1707> somebody fucked up [00:06:34 CEST] <furq> speaking of swresample, is it worth changing any of the defaults other than -filter_size [00:07:02 CEST] <furq> i couldn't find anything on the ML other than stuff like exact_rational which is default enabled now anyway [00:11:03 CEST] <durandal_1707> furq: filter_type [00:11:25 CEST] <furq> i take it there isn't a "best" one of those [00:12:28 CEST] <furq> i was going to submit some new samples to that resampler comparison, so it'd be nice to have the most overkill settings possible [00:12:36 CEST] <durandal_1707> furq: hmm, could be better than default [00:12:39 CEST] <fiera> 551 line does not cancel 37, I'm trying to compile in the VC 2015, if I comment line 37, then the build ffplay is successful, but the does not sound [00:13:32 CEST] <furq> i'll probably send one set with defaults and one with -filter_size 256 -filter_type kaiser [00:13:50 CEST] <furq> i had a look at the sweep spectrograph and filter_type made no difference for that [00:14:14 CEST] <furq> the defaults are already much better than the ffmpeg 1.1 samples they've got there anyway [00:15:12 CEST] <durandal_1707> yes, but note that only >90 dB matters in spectogram [00:15:44 CEST] <furq> sure [00:15:57 CEST] <furq> filter_size 256 looks basically the same as soxr defaults [00:16:53 CEST] <furq> so that's one less thing that i need to build ffmpeg for [00:17:02 CEST] <furq> shame i still want fdk [00:22:18 CEST] <fiera> Can still tell me how to build ffplay in Visual Studio? I do not need ffmpeg, only ffplay. Too many dependencies are created with the mingw, how it avoid? [00:23:26 CEST] <durandal_1707> i do not use windows, exp visual studio [00:24:57 CEST] <fiera> ok, which flag and where to pass, in order to avoid dependencies libwinpthread-1.dll etc. [00:25:44 CEST] <furq> --enable-static --disable-shared [00:28:12 CEST] <fiera> These are enabled by default, but there are dependencies [03:46:30 CEST] <ac_slater> hey guys. When I'm muxing two streams in an mpegts container (manually via libavformat), do the timestamps (PTS/DTS) of the two streams have to be interleaved? [03:47:11 CEST] <ac_slater> or related in any way? [03:49:56 CEST] <DHE> as in audio and video? [03:50:44 CEST] <DHE> as best you can you should submit AVPackets in globally ascending dts order [03:51:00 CEST] <DHE> av_interleave_write_frame (sp?) can help here [03:52:26 CEST] <ac_slater> DHE: thanks for the reply [03:52:34 CEST] <ac_slater> specifically, I have a video and a data source [03:53:01 CEST] <ac_slater> the data source isnt subtitles or anything, but it is a format the ffmpeg/mpegts has a mapper for [03:53:07 CEST] <ac_slater> it's KLVA [03:53:57 CEST] <ac_slater> currently, I just increment the data source's PTS/DTS monotonically from 0 for every packet :-/ [03:54:20 CEST] <ac_slater> I'm wondering if I should scale it to the container (mpegts) clock or just let demuxers handle it [03:59:01 CEST] <hendry> ffserv is mentioned to be removed the next release ... http://ffmpeg.org/index.html#ffserv will it be ? [04:06:41 CEST] <furq> i hope so [04:06:59 CEST] <furq> actually no, that's from last year [04:07:05 CEST] <hendry> yes, a year ago [04:07:22 CEST] <furq> it was supposed to be dropped in 3.2 but some dev decided it was their pet project and they were suddenly very interested in it again [04:07:31 CEST] <hendry> i'm looking for software to dump an rtmp stream, do you have any alternatives to suggest furq ? [04:07:33 CEST] <furq> and by "very interested" i mean they did the bare minimum to port it to non-deprecated apis [04:07:42 CEST] <furq> and then didn't fix any of the stuff that makes it shit [04:08:00 CEST] <furq> and er [04:08:03 CEST] <furq> rtmpdump? [04:08:38 CEST] <ac_slater> hendry: rtmpdump works well [04:09:21 CEST] <hendry> oh, thanks, i somehow discounted it before since it didn't have a listening server component (i thought) now i see rtmpsrv [04:09:38 CEST] <furq> if you want a server then use nginx-rtmp [04:10:08 CEST] <hendry> i just need it to to listen reliably [04:10:27 CEST] <hendry> nginx-rtmp seems to do transcoding and lots of other stuff on the fly that i don't need. i think. [04:10:36 CEST] <furq> only if you ask it to [04:10:47 CEST] <furq> and it only does transcoding if you ask it to exec ffmpeg [04:11:12 CEST] <hendry> what's the benefit of using saying nginx-rtmp over rtmpdump's rtmpsrv ? [04:11:30 CEST] <hendry> is it more robust / tested or something ? [04:11:48 CEST] <furq> it depends what you actually want [04:12:01 CEST] <furq> rtmpsrv is a fake server that you use to invoke rtmpdump [04:12:37 CEST] <hendry> basically want to convert a rtmp stream to Web playback, but also have an archive. so thinking dump + generate some HLS playlists [04:12:50 CEST] <furq> nginx-rtmp will do exactly that [04:13:40 CEST] <hendry> furq: ok, must revisit it. thanks [04:14:05 CEST] <hendry> i guess the nginx part put me off, since i intend to have everything off the S3server httpd [04:14:46 CEST] <furq> you can just disable all the http modules when you build nginx [04:15:45 CEST] <hendry> so what is nginx actually doing? the listening part? [09:49:13 CEST] <Diego_> Hi there. I want to know the bitrate and FPS of a video. I've tried "ffprobe -i video.webm -select_streams v:0 -show_entries format=bit_rate:stream=avg_frame_rate -v quiet -of default=noprint_wrappers=1", but avg_frame_rate shows "15/1". In VLC shows that "video.webm" FPS are 21.0000020. How can I obtain those 21 FPS from codec information? [10:16:45 CEST] <Diego_> Can someone help me with my problem with FFprobe, please? [12:22:50 CEST] <Diego_> Why ffmpeg procees does not exit normally when finishes compiling? It doesn't use any CPU resources, but the process stays up without errors and compilation is fine [13:04:36 CEST] <DHE> it means it's trying to do something. maybe a graceful close of hardware that didn't close so gracefully? maybe flush data to a slow disk or network share? [13:17:30 CEST] <Diego_> I don't think so. I have an SHDD and every other process is finishing fast. Probably a graceful close of the process(?) I don't know. Doesn't show errors nor warnings [14:19:44 CEST] <Diego_> I've tested converting the webm videos to mp4 and when I create the mp4 compilation, the process stops immediatelly, but not when the compilation is in webm [14:46:09 CEST] <dido> Hi, need help with parallel encoding for hls segments. More detailed info on https://stackoverflow.com/questions/44628825/hls-parallel-segment-encoding [14:47:23 CEST] <__jack__> that's not how it works [14:47:30 CEST] <__jack__> it reads the input file [14:47:32 CEST] <__jack__> then decode it [14:47:35 CEST] <__jack__> then encode it [14:47:42 CEST] <__jack__> then chunks the output into multiple ts [14:49:44 CEST] <dido> my point is to encode all .ts segments at the same time, not one by one [14:51:13 CEST] <dido> splitting into multiple ts and encode each wont be slower? [15:17:09 CEST] <termos> I'm pushing AVPackets onto a AVThreadMessageQueue in order, but they are received in a different thread sometimes out of order giving me "non monotonically increasing dts to muxer". Is there some re-ordering happening? From looking at the implementation I don't see anything like that happening [15:40:16 CEST] <DHE> dido: depends. encoding can be multi-threaded. if you only have one machine to do the encoding work, you may be better off having it do the whole thing at once in multi-threaded mode [15:40:34 CEST] <DHE> (though there is diminishing returns if you have some crazy core count and the video is low resolution) [15:45:39 CEST] <dido> DHE: i know it can be multi-threaded but still segments will be done one by one if i m right [15:46:24 CEST] <dido> i just want to speed up the encoding of one video [15:50:16 CEST] <DHE> if you have 1 hour 1080p video and a quad-core CPU, just do it in one instance and let libx264 multi-threading to do its job [16:15:46 CEST] <Diego_> DHE: Does "-preset ultrafast" option work only on h264 codecs? I'm trying it to compile a mosaic with VP8 and speed seems the same [16:16:39 CEST] <DHE> presets, and what they mean, are per-encoder. [16:16:55 CEST] <DHE> wait, why are you asking me? [16:20:59 CEST] <Diego_> DHE: because you are the only one that answers here XD [16:21:02 CEST] <Diego_> sorry [16:21:22 CEST] <BtbN> ultrafast is libx264 specific. [16:22:40 CEST] <Diego_> Thanks BtbN [16:23:12 CEST] <furq> libvpx uses either -speed or -cpu-used [16:23:19 CEST] <furq> i forget which one is the ffmpeg option and which is the libvpx option [16:23:32 CEST] <BtbN> libvpx is not exactly good with that [16:23:41 CEST] <furq> and yeah it's going to be pretty slow either way [16:23:47 CEST] <furq> particularly vp8, which doesn't do any kind of multithreading [16:24:04 CEST] <furq> i imagine vp9 will actually be faster on a decent cpu since they added row-mt [16:24:12 CEST] <Diego_> So the best way is to convert vp8 to h264 then recompile into mosaic with -preset if I want a fast compilation, right? [16:24:23 CEST] <BtbN> what? [16:24:36 CEST] <BtbN> why would you add a pointless transcode? [16:24:40 CEST] <furq> yeah don't do that [16:24:53 CEST] <furq> the vp8/9 decoder is very fast anyway [16:25:34 CEST] <Diego_> Because I have 2 videos in webm (VP8 codec) and I want to create a mosaic with them and I need to do it very fast [16:25:48 CEST] <furq> well then don't encode it twice when you only need to encode it once [16:26:03 CEST] <BtbN> video encoding is not going to be very fast [16:26:41 CEST] <Diego_> I meant "very fast". If I can get a 15 mins video into a mosaic output in 2 mins, its quite decent [16:27:24 CEST] <BtbN> that's That's 7.5x real-time, that's not very realistic for any decent quality [16:27:30 CEST] <Diego_> And I've tested to do a codec conversion while generating the mosaic, but throws an error about I can't do that or something like that [16:28:03 CEST] <Diego_> I don't need full hd, just kinda nice quality and I'm testing it right now with -preset option. Not bad at all [16:28:53 CEST] <DHE> <Diego_> DHE: because you are the only one that answers here XD # I still discourage this though. I might be gone for hours and there's no way to tell on IRC [16:30:10 CEST] <Diego_> Tbh, I've been asking here for 6 hours and you were the only one that answered one of my questions (I've made only 2 questions though) [16:30:25 CEST] <Diego_> I didn't want to offend anyone [16:31:25 CEST] <BtbN> nice quality and fast don't go with each other [16:31:32 CEST] <BtbN> you buy the speed with quite horrible quality [16:31:38 CEST] <BtbN> Or huge files [16:32:15 CEST] <furq> 15:27:29 ( Diego_) And I've tested to do a codec conversion while generating the mosaic, but throws an error about I can't do that [16:32:23 CEST] <furq> pastebin the command and output [16:34:12 CEST] <Diego_> BtbN: yea, I know, but I get a "good" quality. Enough for the project [16:34:36 CEST] <sgermain> Hi! I'm trying to convert MPEG-TS to HLS and I'm running into problems. The main problem is, when the source stream is being transcoded at the source (using Zenverge transcoding chip), the HLS ends up with lots of macroblocks. When I turn off the transcoding at the source, the stream is fine, but way too big. Also, the machine running ffmpeg isn't strong enough to do software transcoding (which work fine, I tried it, as a te [16:34:41 CEST] <Diego_> furq: I can't do that right now as I must go for now. I will give another shot and check if I can get it work [16:35:18 CEST] <sgermain> I can provide the command line I use. [16:35:58 CEST] <furq> that just sounds like a fundamental problem with the chip you're using [16:36:25 CEST] <furq> if you're not encoding with ffmpeg then it has no control over the quality [16:36:51 CEST] <sgermain> If I view the HLS stream using VLC, the stream is fine, but not with any Apple devices using their native HLS support. [16:37:44 CEST] <sgermain> I understand it has no control over the quality of the stream, but maybe it has something to do with timing? I'm not entirely sure. [16:38:55 CEST] <sgermain> Because macroblocks come and go [16:39:55 CEST] <sgermain> For example, it'll play perfect for 1 second, then show macroblocks for a second or 2, then go back to perfect, so on and so forth. [16:55:31 CEST] <RandomCouch> Hi, is anyone around? [16:55:44 CEST] <RandomCouch> I'm trying to compile ffmpeg for android using this guide https://ericnjennifer.wordpress.com/2014/07/25/android-porting-ffmpeg-with-… [16:55:51 CEST] <RandomCouch> but I keep getting compile errors [16:56:00 CEST] <RandomCouch> using NDK r13b and ffmpeg-3.3.2 [16:56:22 CEST] <RandomCouch> also I'm on windows so I'm using cygwin to execute the shell script [17:21:26 CEST] <sgermain> I'm reading the documentation on ffmpeg's hls demuxer and I'm curious as to how do I set multiple hls_flags? [17:26:09 CEST] <c_14> separated by + afaik [17:43:10 CEST] <AnonBaiter> so [17:44:44 CEST] <AnonBaiter> has anyone gotten around to decode this early mdec file? [17:44:45 CEST] <AnonBaiter> https://www.sendspace.com/file/6s3oiw [17:44:45 CEST] <AnonBaiter> the sector in which CD-XA is stored can be decoded, while the video can`t [17:45:16 CEST] <AnonBaiter> *video sector [17:45:48 CEST] <AnonBaiter> the rest is just "unknown sector type ##" [17:51:32 CEST] <AnonBaiter> oh, and this file came from an early PS1 game called Jumping Flash, released in 1995 [17:52:14 CEST] <AnonBaiter> it`s not just Jumping Flash however, there were some early PS1 games that used this format too [18:06:28 CEST] <RandomCouch> unfortunately this place seems inactive [18:06:38 CEST] <RandomCouch> wish I could get some help building ffmpeg for android [18:41:44 CEST] <jasom> Is the correct set of filters for performing an IVTC of an NTSC source: dejudder,fps=30000/1001,fieldmatch,decimate ? [18:45:08 CEST] <furq> there isn't a correct set, it depends on the source [18:45:35 CEST] <furq> you probably want either that or pullup,fps=24000/1001 [18:45:49 CEST] <furq> someone else has probably done a lot more ivtcing than me though [19:08:02 CEST] <AnonBaiter> guess I need to have that issue I`m having on trac.ffmpeg [19:19:42 CEST] <RandomCouch> Is there an updated guide on building ffmpeg for android [19:55:49 CEST] <kepstin> jasom: I think you'd want the dejudder after the decimate, since its purpose is to smooth out the framerate after decimate removes the dup frames. [19:57:37 CEST] <kepstin> and yeah, there's no such thing as a perfect/correct automatic ivtc. If you have movement on every frame and no interlaced crossfades, fieldmatch will probably do pretty well. [20:06:51 CEST] <FishPencil> Does it make sense to use FFmpeg as an image decoder? Or should I tie into the libs themselves (libjpeg, libpng)? [20:07:30 CEST] <furq> depends what you're doing [20:07:35 CEST] <furq> something like libvips might be a better choice [20:08:05 CEST] <DHE> it makes sense if you're using it for video work on top of it. like image overlays... [20:08:17 CEST] <DHE> otherwise, yeah I'd just go with an image-specific library' [20:08:39 CEST] <furq> if you need absolutely comprehensive format support then libavcodec/libavformat is probably a good choice [20:08:52 CEST] <furq> but it's probably not going to be particularly quick or lightweight [20:08:57 CEST] <FishPencil> I just need to decode jpg, fits, gif, and png. I don't think FFmpeg supports fits, so I'll have to go elsewhere for that anyway [20:09:04 CEST] <furq> libvips does fits [20:10:14 CEST] <FishPencil> Doesn't vips just use the libraries themselves and ties it into one API? [20:10:55 CEST] <furq> yeah it does [20:11:02 CEST] <furq> saves you the effort though [20:16:06 CEST] <FishPencil> I bet it does, I'll probably just use it. No need reinventing the wheel [20:30:20 CEST] <alexpigment> hey guys, I'm trying to figure out if this fix/patch is working: https://trac.ffmpeg.org/ticket/6260 [20:30:32 CEST] <alexpigment> i feel like I've done everything to ensure that my build has this fix in place [20:30:37 CEST] <alexpigment> but it's clearly not fixed at all [20:31:08 CEST] <alexpigment> can anyone else check to see if their interlaced output gets really bad stair-stepping? [20:54:18 CEST] <jasom> kepstin: the main thing I want is to never lose audio-sync; I don't care too much if a few crossfades have combing [20:55:43 CEST] <kepstin> jasom: yeah, keeping sync won't be a problem unless you throw a setpts filter in them. I think all the detelecining stuff in ffmpeg should preserve timestamps fine. [20:56:24 CEST] <kepstin> (which is part of the reason the dejudder filter is needed, it fixes the jump in timestamps where the frames that the detelecine filter dropped used to be) [20:57:00 CEST] <furq> afaik if you have a clean source then pullup,fps will work great [20:57:21 CEST] <furq> according to the docs, dejudder is mostly for fixing hybrid interlaced/telecined sources [20:57:44 CEST] <jasom> furq: but lots of sources start out with e.g. an interlaced intro or will switch field order on some scene changes. [20:57:47 CEST] <furq> sure [20:57:58 CEST] <furq> those are not clean sources [20:58:13 CEST] <furq> films are generally clean sources, tv shows tend not to be [20:58:31 CEST] <jasom> kepstin: using some of the suggested ivtc filters on the wiki, I've ended up losing sync [20:59:28 CEST] <jasom> furq: I've never tried ivtc from TV, but 1/3 of all DVDs I've tried do not maintain the same field order for the entire film (either with the studio logo at the beginning being 29.97 native, or field-order switch at a scene change) [20:59:45 CEST] <furq> fair enough [20:59:50 CEST] <furq> i'm in a pal region so i don't really know much about ivtc [21:00:19 CEST] <jasom> furq: I've heard some pal musicals use a 24/25 pulldown, but never encountered one. [21:00:31 CEST] <furq> yeah i've never seen that [21:00:35 CEST] <furq> it's usually just sped up by 4% [21:00:37 CEST] <furq> which is easy to fix [21:00:58 CEST] <furq> we have more than our fair share of hybrid interlaced/film though [21:01:09 CEST] <furq> which is probably still easier to fix than hybrid interlaced/telecine [21:38:32 CEST] <RandomCouch> I really need help with ffmpeg for android build [21:38:46 CEST] <RandomCouch> If anyone can provide me with a working guide or tutorial [21:38:54 CEST] <RandomCouch> for building ffmpeg for android on windows [21:39:08 CEST] <RandomCouch> with the latest versions of NDK and ffmpeg [21:55:06 CEST] <JEEB> RandomCouch: building FFmpeg with NDK is rather simple to be honest... make the toolchain with the python script that comes with the NDK, and then gas-preprocessor if you want to use clang [21:55:22 CEST] <JEEB> of course personally the latest NDK (r15) breaks the mediacodec hwdec [21:56:08 CEST] <RandomCouch> Thanks JEEB, I'll have to look up what clang and gas-preprocessor is, I'm a bit of a novice [21:56:20 CEST] <JEEB> NDK comes with two compilers. gcc and clang [21:56:26 CEST] <RandomCouch> Ultimately what I'm trying to do is just combine two mp4 files together on native android [21:56:49 CEST] <RandomCouch> I feel like ffmpeg is overkill for that but it's the only solution I'm finding [21:58:39 CEST] <JEEB> gas-preprocessor is a script you can get from https://git.libav.org/?p=gas-preprocessor.git;a=summary [21:58:44 CEST] <JEEB> it's for ARM [21:59:04 CEST] <JEEB> gcc can handle the asm that's in FFmpeg as-is, but clang still needs manual love which the gas-preprocessor can do [21:59:09 CEST] <JEEB> just needs to be in PATH [22:01:34 CEST] <JEEB> and the standalone toolchain stuff is this https://developer.android.com/ndk/guides/standalone_toolchain.html [22:02:02 CEST] <JEEB> (because with FFmpeg you cannot use the google hackjobs that's called the "NDK build system" [22:32:05 CEST] <RandomCouch> Thanks JEEB I'm looking into all this now [23:26:09 CEST] <kerio> this .wmv is slow to open in mpv [23:26:12 CEST] <kerio> how do i fix [23:26:25 CEST] <kerio> don't say "transcode to a real codec" [23:26:39 CEST] <kerio> oh ok actually it just doesn't work in mpv [23:27:24 CEST] <durandal_170> kerio: please upload it somewhere [23:27:36 CEST] <kerio> ... [23:27:44 CEST] <durandal_170> it might be asf demuxer issue [23:27:57 CEST] <kerio> wouldn't that get fixed after remuxing into mkv? [23:28:03 CEST] <kerio> i tried that and it still failed to open [23:28:34 CEST] <hpp> maybe vlc plays it better? [23:28:38 CEST] <kerio> HERESY [23:28:45 CEST] <kerio> oh hold on i have vlc installed [23:29:11 CEST] <durandal_170> kerio: if it doesnot work with ffmpeg but does with wmp please upload short sample [23:29:35 CEST] <kerio> durandal_170: well, it's (correctly?) transcoding with ffmpeg [23:29:39 CEST] <kerio> the same ffmpeg that mpv is built against [23:31:07 CEST] <durandal_170> hmm, make sure you are not using hwdec [23:31:15 CEST] <kerio> ...i am ;o [23:31:22 CEST] <kerio> wait there's hwdec for wmv? [23:31:24 CEST] <kerio> on macos? [23:32:10 CEST] <kerio> what do you fucking know, it was hwdec [23:32:24 CEST] <durandal_170> what video codec is it using? [23:33:00 CEST] <kerio> Stream #0:1: Video: wmv3 (Main) (WMV3 / 0x33564D57), yuv420p, 1280x720, 5210 kb/s, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn, 1k tbc [23:33:15 CEST] <furq> yeah i tend to remux wmv to mkv [23:33:21 CEST] <furq> seeking is a fucking nightmare in wmv [23:33:22 CEST] <kerio> why's hwdec even attempted [23:33:35 CEST] <furq> remuxing to mkv fixes most issues i have with wmv [23:33:42 CEST] <kerio> furq: given that this is pretty vile porn, i should probably remux to .nut [23:33:44 CEST] <furq> other than the big issue of "it's fucking wmv" [23:33:46 CEST] <kerio> U( )W [23:33:52 CEST] <furq> ofc it's porn [23:33:54 CEST] <furq> why else would you have wmv [23:34:02 CEST] <kerio> well whats the alternative [23:34:03 CEST] <kerio> transcoding? [23:34:08 CEST] <kerio> we must preserve our history [23:34:19 CEST] <kerio> i think i have some like [23:34:22 CEST] <kerio> 160x120 .rm or something [23:34:25 CEST] <furq> i've reencoded a lot of 1080p wmv porn to 576p x264 [23:34:43 CEST] <furq> it looks just as good considering how blocky the source looked [23:34:49 CEST] <durandal_170> you lost bunch of pixels [23:34:59 CEST] <furq> im cryeing [23:35:21 CEST] <kerio> anyway why is hwdec messing with a wmv of all things [23:35:26 CEST] <furq> vc-1? [23:35:33 CEST] <kerio> i'm pretty sure that wmv is not accelerated on macos [23:35:41 CEST] <furq> intel has vc-1 hwdec iirc [23:35:46 CEST] <furq> if it's wmv9 then no idea [23:36:06 CEST] <kerio> isn't it just videotoolbox [23:36:14 CEST] <furq> shrug [23:37:04 CEST] <kerio> furq: it's not wmv9, it's wmv3 [23:37:12 CEST] <furq> wonderful [23:37:26 CEST] <furq> oh those are the same [23:37:31 CEST] <furq> just a different fourcc [23:37:55 CEST] <kerio> anyway it's still a bug right [23:37:56 CEST] <kerio> in mpv [23:37:57 CEST] <furq> vc-1 is based on wmv9 so maybe the vc-1 hwdec still works [23:38:05 CEST] <furq> also that seems like a question for #mpv [23:38:10 CEST] <furq> those guys fucking suck though [23:38:46 CEST] <durandal_170> no they are nice and friendly [23:40:33 CEST] <kerio> why can't i get some lossless porn [23:40:46 CEST] <furq> make it yourself [23:42:17 CEST] <kerio> hold on lemme take a pic of my dick in raw [23:42:26 CEST] <kerio> i'll pm it to you [23:43:06 CEST] <furq> go on then [23:43:23 CEST] <dystopia_> these seems rather off topic [23:43:37 CEST] <kerio> does mpv do its own thing for hwdec [23:43:50 CEST] <durandal_170> this ch is logged and stay ontopic [23:44:30 CEST] <kerio> should i enable more things in my ffmpeg [23:44:40 CEST] <kerio> i have --with-x265 --with-opus [23:44:47 CEST] <kerio> in brew [23:46:55 CEST] <durandal_170> depends what you need? [23:47:35 CEST] <kerio> is openh264 any good? [23:47:39 CEST] <kerio> other than the patent thing [23:47:51 CEST] <furq> no [23:47:53 CEST] <furq> it's baseline only [23:48:04 CEST] <kerio> fdk-aac? [23:48:04 CEST] <furq> it exists solely for the patent thing [23:48:16 CEST] <furq> fdk is better than the builtin encoder, especially if you want he-aac [23:48:21 CEST] <kerio> that's the only thing in this list that i could see myself using [23:48:22 CEST] <kerio> aite [23:49:00 CEST] <kerio> why isn't the builtin encoder better [23:49:10 CEST] <kerio> why can't you guys just git gud [23:49:26 CEST] <furq> it's already better than every oss encoder that isn't fdk [23:49:33 CEST] <Threads> how about you code it for them and they port it into ffmpeg :P [23:49:44 CEST] <furq> and better than every gpl compatible encoder [23:49:58 CEST] <Threads> last i looked online nobody uses the dead format wmv anymore [23:50:01 CEST] <iive> furq: are you sure about builtin aac encoder? [23:50:15 CEST] <furq> there hasn't been a listening test so i'm not 100% sure [23:50:34 CEST] <furq> if nothing else fdk is definitely better for he-aac and vbr [23:50:45 CEST] <kerio> iive: well, when anyone says "better" it's always implied "other than the fact that at >128k, aac is pretty much perceptually lossless anyway so yea" [23:50:45 CEST] <Threads> ^ [23:50:50 CEST] <furq> i don't think the builtin encoder even supports those yet [23:50:58 CEST] <Threads> just lc [23:51:00 CEST] <kerio> "also just use opus" [23:51:01 CEST] <hpp> since there is OPUS that is all you need [23:51:12 CEST] <furq> you'd struggle to tell the difference at 128k cbr [23:51:26 CEST] <furq> it was designed to replace faac, not fdk [23:51:42 CEST] <kerio> i have laptop speakers and bluetooth headphones [23:51:50 CEST] <kerio> i'd probably struggle to tell the difference at 128k cbr mp3 [23:52:01 CEST] <furq> definitely [23:52:30 CEST] <Threads> all you want todo is listen to the music does bitrate really matter :/ [23:52:40 CEST] <kerio> ok thats not true, mp3 128 is noticeable even on my shit listening setup [23:52:41 CEST] <kerio> but only barely [23:53:29 CEST] <kerio> Threads: https://www.dropbox.com/s/wngqdpdttau2alk/Screenshot%202017-06-20%2023.53.2… mfw [23:58:33 CEST] <Threads> are you one of them audiophiles or what ever they call them that has to have high bitrates for music [23:59:03 CEST] <kerio> nah, only radiohead :^) [23:59:22 CEST] <alexpigment> Threads - when storage is so cheap, why would you not? You never know when your audio setup will improve and you regret ripping at something lower [23:59:24 CEST] <pzy> amen to that kerio [23:59:27 CEST] <alexpigment> (I'm speaking from experience) [23:59:55 CEST] <kerio> alexpigment: there is absolutely no reason whatsoever to have 96/24 audio if you're not in a mixing studio [23:59:56 CEST] <alexpigment> But yes, you want Weird Fishes - Arpeggio at the highest bitrate possible :) [00:00:00 CEST] --- Wed Jun 21 2017

1 0