Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2017

1 participants
62 discussions

ffmpeg-devel.log.20170130
by burek 31 Jan '17

31 Jan '17

[01:44:10 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:5b0ae88ca6b3: genh: prevent overflow during block alignment calculation [01:44:11 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:74bd17d31648: epafdec: prevent overflow during block alignment calculation [01:44:12 CET] <cone-988> ffmpeg 03Andreas Cadhalpun 07master:cba4f0e97ecb: xvag: prevent overflow during block alignment calculation [02:15:34 CET] <Lutier> Is it possible to add an option to ffplay so that is creates a borderless window? So that it could be used within other programs without hacks like this http://stackoverflow.com/questions/31465630/ffplay-successfully-moved-insid…. [02:19:31 CET] <Lutier> like MPlayer's -noborder option [06:16:02 CET] <Lutier> Am I just asking in the wrong place? [06:55:06 CET] <Compn> Lutier [06:55:33 CET] <Compn> Lutier : probably, patch welcome :) [06:56:06 CET] <Compn> possibly by modifying sdl before compile [07:17:33 CET] <Lutier> Compn: I don't speak C, so wouldn't know where to start [07:22:34 CET] <Lutier> Compn: Assuming I'm looking in the right place, looks like there's a way with SDL_WINDOW_BORDERLESS flag in SDL_CreateWindow [07:48:09 CET] <Lutier> Compn: Would this work? https://github.com/FFmpeg/FFmpeg/pull/249 [07:49:00 CET] <Polochon_street> Lutier: I don't know anything about your problem, but I guess the devs won't be happy https://github.com/FFmpeg/FFmpeg/pull/153 [08:36:59 CET] <wm4> man trolling is hard work [08:37:23 CET] <nevcairiel> choose the lazy route and don't? :) [08:37:24 CET] <wm4> too bad serious interaction doesn't work either and you get trolled [08:37:57 CET] <wm4> what can you do if you churn out a bunch of technical argument, and all what comes back is a mail replying "Rude." [11:03:13 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:76331361a51b: avformat/sccdec: simplify 2 sscanf calls [11:03:13 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:036e12b225b2: avformat: add SCC muxer [11:05:35 CET] <cone-395> ffmpeg 03Paul B Mahol 07master:13564fc24d82: avutil/eval: add atan2 function [12:04:09 CET] <cone-395> ffmpeg 03Clément BSsch 07master:3a3554871a13: lavc/hevcdsp: fix pretty printing mistake [12:04:10 CET] <cone-395> ffmpeg 03Clément BSsch 07master:de2f9f4b71ae: doc/libav-merge: add unmerged hevc commits hashes [12:07:58 CET] <nevcairiel> ubitux: thats just the old commits we skipped, not any new ones, right? [12:25:17 CET] <ubitux> nevcairiel: yes [12:25:52 CET] <nevcairiel> how is the merging going? I'm back home now and can probably help soon [12:26:52 CET] <ubitux> didn't start [12:27:00 CET] <ubitux> just looked around trying to understand [12:32:00 CET] <nevcairiel> durandal_1707: the scc fate test fails on all my systems, ie. http://fate.ffmpeg.org/report.cgi?time=20170129223531&slot=x86_64-msvc14-wi… [12:36:06 CET] <durandal_1707> nevcairiel: looks like it dumps lines with ` [12:36:29 CET] <nevcairiel> the stderr has some stuff about invalid utf8, not sure if thats related [12:37:15 CET] <durandal_1707> i dont get such errors at all [12:37:55 CET] <durandal_1707> and scc have little modified ascii not utf8 at all [12:39:10 CET] <durandal_1707> nevcairiel: does all your system have memory poisoning enabled? [12:39:18 CET] <nevcairiel> yes [12:39:26 CET] <nevcairiel> its default in the fate script we have in the repo [12:40:27 CET] <nevcairiel> i can try to debug it a bit later [12:41:07 CET] <cone-395> ffmpeg 03Tobias Rapp 07master:ec33ade7d300: avformat/Makefile: fix compilation of testprogs when networking is disabled [12:51:50 CET] <durandal_1707> nevcairiel: try to change definition of 0x27 code at line 76 of ccaption decoder to simple ' [12:53:24 CET] <nevcairiel> still seems rather odd, why would it only happen here, its not like there is some external library involved, or is there? [13:05:18 CET] <durandal_1707> that reverse ` doesnt seem like utf8 to me? [13:08:43 CET] <nevcairiel> even then why does it not error anywhere else :D [13:09:36 CET] <nevcairiel> unless the \u escape code is whats messing it up [13:15:38 CET] <nevcairiel> ccaption_dec.c(86): warning C4566: character represented by universal-character-name '\u2588' cannot be represented in the current code page (1252) [13:15:41 CET] <nevcairiel> hm plenty of those [13:23:24 CET] <nevcairiel> newest compiler has a /utf-8 switch to make it work, but older compilers are still screwed .. but then, what do I care about those. [13:38:10 CET] <rcombs> fuck anyone trying to build ffmpeg with old MSVC [13:42:35 CET] <nevcairiel> i should shutdown the vs2012 box one of these days anyway, maybe when 2017 comes along [13:42:47 CET] <nevcairiel> although 2013 would also be affected by this bug [13:42:48 CET] <kierank> who the hell is bananaman [13:50:55 CET] <durandal_1707> kierank: man who likes bananas [15:04:17 CET] <ubitux> what does 'q' and 'e' stands for in qpel, epel? "quad"? "edge"? [15:06:52 CET] <jkqxz> Quarter, eighth. [15:07:21 CET] <nevcairiel> eighth looks so wrong of a word with the hth at the end [15:07:24 CET] <funman> please use metric system: decipel, centipel [15:07:46 CET] <ubitux> jkqxz: ooh. thanks. [15:07:55 CET] <jkqxz> 2.5 decipels, 1.25 decipels? [15:08:12 CET] <funman> yes, just like camera manufacturers do already [15:09:57 CET] <ubitux> do we need a doc/lexicon where we put a list of "common shorthand we use that don't need a comment" [15:09:59 CET] <ubitux> ? [15:23:07 CET] <ubitux> what is fpel and hpel? fullpixel/halfpixel? [15:25:08 CET] <funman> femtopixel and hectopixel obviously [15:26:32 CET] <funman> ubitux: fullpel halfpel according to git grep in x264 [15:29:34 CET] <ubitux> ok so i was correct [15:29:52 CET] <ubitux> http://b.pkh.me/lexicon [15:29:56 CET] <ubitux> what should i add? [15:30:38 CET] <nevcairiel> other then the pel's those all seem so obvious [15:31:07 CET] <ubitux> maybe not for newcomers [15:31:16 CET] <ubitux> adding sw and hw [15:31:22 CET] <nevcairiel> if you dont know what dsp is, maybe you are too green =p [15:31:43 CET] <ubitux> maybe :) [15:32:38 CET] <kierank> full and half is better notation because some people refer to the pels as already being subsampled [15:32:46 CET] <kierank> (imo) [15:39:22 CET] <atomnuker> ubitux: (i)fft, vq (vector quantization), ec (entropy coding), vlc (variable length coding) [15:40:31 CET] <ubitux> if we add fft, should we add a bunch of common transforms? [15:41:46 CET] <atomnuker> wavelets don't really have an abbreviation, neither do legendre, gabor, etc. [15:42:29 CET] <ubitux> lexicon updated [15:43:30 CET] <atomnuker> oh yeah, add mdct (lapped dct) [15:44:11 CET] <jkqxz> CABAC, CAVLC, GOP, AC, DC, IDR, I, P, B, VBV, HRD, NAL, RBSP, SAR, DAR? [15:44:28 CET] <atomnuker> ubitux: and dst (discrete sine transform) and adst (asymmetric discrete cosine transform) [15:44:38 CET] <jkqxz> CPB, DPB, VCL. [15:44:42 CET] <atomnuker> *sine [15:44:48 CET] <nevcairiel> noone really needs to know what cabac stands for, its somewhat of a word on its own :p [15:45:48 CET] <ubitux> yeah and that's easily googlable [15:46:09 CET] <ubitux> the 2 or 3 letters ones are often tricky to search [15:46:16 CET] <jkqxz> Yeah, for a lot of those what it stands for isn't really relevant. Knowing what they are is still helpful. [15:48:25 CET] <rcombs> I know what CABAC stands for but not CAVLC [15:48:43 CET] <ubitux> atomnuker: adst = asymmetric discrete (co?)sine transform :) [15:48:51 CET] <jkqxz> It's just CABAC - BAC + VLC. [15:48:54 CET] <nevcairiel> rcombs: the CA is the same, and VLC is what its always is [15:49:07 CET] <atomnuker> yeah, its sine, not cosine, typo'd [15:51:48 CET] <kierank> atomnuker: ec clashes with error concealment [15:52:06 CET] <ubitux> jkqxz: don't assume i know all of them ;) [15:56:48 CET] <ubitux> anyway, good enough for a first version, i'll let you ppl add more [16:03:36 CET] <ubitux> we could add some nicknames in that file :° [17:35:41 CET] <cone-457> ffmpeg 03bnnm 07master:ebb83e2dc0b4: avformat/msf: fix codec 4 (joint stereo ATRAC3) and align [18:07:50 CET] <Chloe> ubitux: fdct = forward dct [18:24:09 CET] <BBB> atomnuker: sorry, had to run yesterday, pthread api still works, so you can just use that directly with mutex objects that exist in the per-slice data structs [18:24:17 CET] <BBB> (or global, if you want it shared) [18:24:24 CET] <BBB> (i.e. in the priv_data object) [18:25:25 CET] <BBB> atomnuker: I think the loopfilter would just run as an extra thread, the overhead of loopfilter on top of slice decoding should be small so a user should barely notice it [18:26:30 CET] <BBB> atomnuker: maybe wed want to enhance the slice threading api to give a decoder control back of the main frame decoding thread when the per-slice threads have started, so the main thread could do lpf and await the slice threads as it does that, so that itd be a more interactive form of blocking for the slices to be done decoding [18:26:49 CET] <BBB> (which reminds me, frame+slice combination would be fun to try) [18:30:00 CET] <nevcairiel> someone did that for hevc, but it might not have been worth it for the complexity [18:30:35 CET] <nevcairiel> so it never arrived here [18:32:05 CET] <kierank> it's useful for encoding high bitrate h264 [18:32:13 CET] <kierank> like gigabit h264 [18:32:21 CET] <atomnuker> BBB: is there anything that needs to be done on the slice threads after the loop filter has been applied? [18:32:36 CET] <atomnuker> sounds like its better to just do it in the main thread after slice decoding [18:33:02 CET] <BBB> that would increase latency a bit [18:33:11 CET] <BBB> so overall decoding time would go up [18:33:29 CET] <BBB> the goal of threading is to bring back wall clock time as much as possible, right? [18:33:42 CET] <BBB> so deinterleaving slice decoding and lpf would be a little bit strange in that context [18:34:08 CET] <BBB> slice threads dont have to do anything after lpf, in the reference decoder the lpf is done after the whole frame has been reconstructed [18:34:22 CET] <atomnuker> oh so you mean execute the loop filter inside the slice threads but sync them so that they don't overlap? [18:34:25 CET] <BBB> vp8 was the same, ffvp8 interleaves lpf with main decode loop but libvpx does it post-decode-frame [18:34:31 CET] <BBB> right, exactly [18:34:52 CET] <BBB> you want the loopfilter for row=0 to only run after all slices have decoder row=0 for their respective columns [18:35:09 CET] <BBB> if vp9 did what h264 does and skip loopfilter at tile boundaries, you wouldnt need any of this [18:35:29 CET] <BBB> (slice boundaries in case of h264, but same idea) [18:35:47 CET] <atomnuker> right, well if you have access to a mutex somewhere that's doable [18:35:56 CET] <BBB> right, its fairly trivial [18:36:05 CET] <BBB> in fact like you said, its just like the frame threading api [18:36:21 CET] <BBB> except the progress is per-tile column instead of per field/frame row [18:45:21 CET] <cone-457> ffmpeg 03Paul B Mahol 07master:acf1dd5b74ab: avfilter: add threshold filter [20:15:53 CET] <kierank> peloverde: do you know where the vp9 in ts repo is? [20:18:01 CET] <peloverde> It's in libwebm, I think it's still half finished though [20:43:27 CET] <Chloe> Is there a more efficient algorithm to do zigzag matrix traversal other than the logical method? [20:47:22 CET] <kierank> there is simd iirc [20:47:41 CET] <kierank> or you just merge it into your coefficient unpack [20:51:11 CET] <Chloe> kierank: It's a little off-topic (idk where else anyone is knowledgeable on this), to give some context--I'm writing an JPEG codec in Rust, trying to do it straight from the spec. I was thinking to go from DCT -> zigzag unpack -> quant -> etc. I guess you mean to merge zigzag with something else? [20:51:25 CET] <kierank> encoder or decoder? [20:51:36 CET] <kierank> if it's a decoder you can read your coefficients into the correct zigzag index [20:51:49 CET] <Chloe> I'm doing the encoder first [20:52:02 CET] <kierank> ah then probably you should zigzag in place [20:54:13 CET] <Chloe> I was thinking if I could merge the DCT & zigzag, but other things than the DCT use the zigzag too [21:35:19 CET] <BBB> Chloe: why do you want to unpack zigzag? [21:35:30 CET] <BBB> Chloe: is it so you know the last significant coefficient? [21:35:57 CET] <Chloe> so it's easier to quantize and then do rle on [21:36:22 CET] <Chloe> otherwise I have to put the zigzag algo in the quantization and rle functions [21:37:26 CET] <BBB> you mean because each quantizer is different and the ordering is in zigzag? [21:39:54 CET] <atomnuker> Chloe: meh, its just a lookup table, do that during quantization unless you're man enough to hardcode it in the dct [21:41:40 CET] <Chloe> My DCT is pretty trash (O(n^4) -- pls dont shoot me), I'd rather not put anything in it for now until I make it better. Is RLE not done in zigzag ordering? [21:42:39 CET] <BBB> atomnuker: omg :D man enough to hardcode it in dct :D [21:42:51 CET] <BBB> and trivial fdcts must exist already no? [21:43:19 CET] <BBB> rle can do the lookup inside, so having the zigzag there shouldnt be an issue [21:43:20 CET] <Chloe> Sure, but it's for a school project so I need to 'derive' everything myself. Can't use any library code [21:43:26 CET] <BBB> ah [21:43:42 CET] <Chloe> hence I'm implementing it directly from the spec pretty much [21:44:25 CET] <BBB> I think most people just give the zigzag scantable to the coding and quant functions [21:44:36 CET] <atomnuker> if you're still planning to write a faster dct then yeah, put the zigzag during RLE [21:44:46 CET] <BBB> as for quant, if the quantizers need to be in scanorder, just palce them as such in the initial array [21:44:51 CET] <BBB> so its just a matrix multiply again [21:45:09 CET] <BBB> if you need it to derive last sig coeff, just provide an inverse zigzag (T^-1) [21:45:28 CET] <BBB> so zigzag[izigzag[i]] == i [21:50:45 CET] <Chloe> That sounds fine. My other issue was: how do I even know it works? I'll know when it's all implemented, but until then I'm pretty much blind. [21:51:51 CET] <BBB> individual functions can be tested against the respective counterparts of the decoder [21:51:59 CET] <BBB> the full thing, yes, when its done [21:52:25 CET] <BBB> but component testing is pretty standard, e.g. idct(fdct(bla)) should minimize for error in bla[] [21:53:08 CET] <BBB> for quant/dequant thats a little harder, but you can model the error with different quantizers and make sure it goes up as expected (towards quant*0.5) [22:01:55 CET] <Chloe> BBB: I currently test if idct(fdct(bla)) == bla to 12d.p. and thanks for the pointer on how to test the quantizer. Anyway, from now on it's mostly implementing the format and then I'll finish rle/arithmetic coding [22:46:19 CET] <atomnuker> you can't really get jpeg quantization wrong, its scalar [22:46:47 CET] <atomnuker> and you can't get rle coding slightly wrong, if its wrong you'll desync by alot [22:48:37 CET] <rcombs> challenge accepted [22:49:17 CET] <JEEB> :D [22:50:53 CET] <atomnuker> BTW Chloe, do you really think you can do arithmetic coding? [22:51:13 CET] <atomnuker> I tried implementing it for the decoder and it was quite difficult [22:52:02 CET] <atomnuker> the information from the spec was barely anything and the mozjpeg code was not easy at all to read [22:52:40 CET] <atomnuker> you'll probably have to use code from an external library and you'll need a lot of effort to make it run [22:55:17 CET] <BBB> jpeg has arithcoding? [22:55:28 CET] <TD-Linux> yes but almost no one implements it [22:55:50 CET] <TD-Linux> it was covered by patents for a long time, plus it was really slow [22:56:19 CET] <TD-Linux> my system libjpeg has it enabled, but most software that bundles a jpeg decoder doesn't include it (like firefox) [22:56:30 CET] <BBB> *mind blown* [22:56:35 CET] <atomnuker> it doesn't save *that* much space as well [22:57:01 CET] <atomnuker> it'll likely be easier to introduce a new format than to get them to start shipping libjpeg with arithmetic decoding enabled [22:57:36 CET] <atomnuker> even debian doesn't compile anything with ac enabled [22:58:33 CET] <rcombs> AV1P when [22:58:55 CET] <TD-Linux> after video is solved [22:59:40 CET] <jkqxz> Yeah, there's little point in doing the arithmetic coding unless you really enjoy that sort of thing. Just do the normal huffman coding which ~all real images use. (And if you feel like doing something marginally more interesting with that, make the optimal tables for it.) [22:59:45 CET] <atomnuker> it doesn't have lapping and its either lapping or death now that daala proved what you can do with it [23:00:12 CET] <TD-Linux> well, daala proved that it worked for still images. it never proved that it worked for video. [23:00:43 CET] <atomnuker> yes, still images [23:19:58 CET] <Chloe> atomnuker: I was under the impression it was needed, if I can avoid implementing it that'd be great [23:20:14 CET] <Chloe> a DCT is enough to get full marks on algorithms/complexity [23:20:23 CET] <Chloe> even a fuckslow one [23:20:35 CET] <cone-337> ffmpeg 03Michael Niedermayer 07master:06c143e50577: avformat/mov: Fix integer truncation in mov_read_uuid() [23:23:47 CET] <Chloe> atomnuker: what encoding does a standard jpeg have then? only rle? [23:23:56 CET] <Chloe> standard meaning the most common one [23:24:08 CET] <TD-Linux> huffman [23:25:01 CET] <Chloe> ah yes ofc [23:25:50 CET] <atomnuker> you don't even need to make optimal tables, just use the default ones [23:26:39 CET] <Chloe> atomnuker: the spec have tables? [23:28:32 CET] <atomnuker> yeah, for luma and chroma [23:28:56 CET] <Chloe> oh for quantization? [23:29:38 CET] <jkqxz> See annex K. It's kindof presented as an example, but actually ~everyone just uses those. [23:31:11 CET] <Chloe> yep, I have both those tables for quantization. [23:31:16 CET] <Chloe> oh nice, it has huffman tables too [23:31:42 CET] <JEEB> yup [23:31:45 CET] <Chloe> I guess I can hardcode those [00:00:00 CET] --- Tue Jan 31 2017

1 0

ffmpeg.log.20170130
by burek 31 Jan '17

31 Jan '17

[01:32:22 CET] <faLUCE> well. MATROSKA AUDIO http stream works with ffplay, vlc and mplayer. MPEGTS works with ffplay, buggy with vlc and no-way with mplayer. OGG works with ffplay, mplayer and doesn't work with vlc [01:32:27 CET] <faLUCE> matroska is the winner [01:32:39 CET] <furq> or alternatively, vlc is the loser [01:32:45 CET] <faLUCE> furq: LOL [01:34:10 CET] <faLUCE> anyway, this matroska seems excellent to me. and much better than mpegts and ogg. [01:34:31 CET] <faLUCE> ogg must be avoided at all. It supports few things [01:34:45 CET] <faLUCE> mpegts is not good for HTTP, because of the PCR [01:35:01 CET] <faLUCE> so, matroska is the right choice [01:36:15 CET] <faLUCE> do you know if ffmpeg does well support matroska? it seems to me that, for example, some params can't be set, like the muxer's buffersize [01:43:43 CET] <furq> it's not widely used for streaming [01:43:46 CET] <kepstin> matroksa wasn't really designed for realtime streaming, so you won't get that level of control [01:43:50 CET] <furq> unless you include webm, which is based on matroska [01:44:01 CET] <furq> mpegts is pretty much the standard for this [01:44:33 CET] <furq> didn't you say you got the same pcr warning from vlc when you tried streaming ogg [01:44:50 CET] <furq> it could've just been a false alarm and the issue was somewhere else [01:44:53 CET] <faLUCE> kepstin: I don't agree: https://matroska.org/technical/streaming/index.html [01:46:38 CET] <faLUCE> furq: yes, but it's a bug of vlc. [01:46:47 CET] <furq> how come the matroska site styles it as matroaka and not matrëaka [01:47:18 CET] <faLUCE> kepstin: in addition, there's a "suggested buffer" field in the matroska header [01:47:38 CET] <furq> faLUCE: well yeah, i'm just suggesting that there was nothing wrong with your mpegts pcr [01:47:55 CET] <furq> and vlc was shitting the bed for some undisclosed reason [01:48:00 CET] <kepstin> I don't dispute that matroksa container /supports/ live streaming... [01:48:28 CET] <faLUCE> furq: yes, because it decodes http streams like dvb streams [01:48:52 CET] <faLUCE> then it causes this bug [01:49:47 CET] <faLUCE> furq: this doesn't happen with VBR, then, when I have audio+video vlc works good for mpegts [01:50:10 CET] <furq> i should hope so considering livestreaming was the only reason to use vlc for years [01:50:51 CET] <faLUCE> furq: anyway, for http livestriming MPEGTS is overkill [01:50:54 CET] <furq> it's pretty funny if it doesn't work with ogg live streams though [01:51:05 CET] <furq> although i guess most netradio stuff is using aac-he now [01:51:18 CET] <faLUCE> furq: I did not many tests with ogg, because it supports few codecs [01:51:30 CET] <Diag> faLUCE is your name a play on phallus... [01:51:31 CET] <furq> it supports the best audio codec though [01:51:36 CET] <kepstin> there's still a bunch of "shoutcast" style radios using ogg vorbis over http, i'd expect they work fine in vlc [01:51:49 CET] <furq> yeah maybe it works better with icecast stuff [01:51:58 CET] <kepstin> but yeah, if you can use opus why bother with any other codec? :) [01:52:07 CET] <faLUCE> kepstin: because of AAC [01:52:24 CET] <kepstin> opus is equivalent or better quality to aac, and lower latency [01:52:24 CET] <Diag> kepstin is opus ogg? [01:52:25 CET] <faLUCE> maybe AAC is better than opus... who knows? [01:52:29 CET] <furq> it isn't [01:52:45 CET] <furq> http://listening-test.coresv.net/s/scores_by_tracks_en.png [01:52:46 CET] <furq> hth [01:53:08 CET] <faLUCE> ok, but the main problem of OGG is that I can't use H264 [01:53:11 CET] <kepstin> Diag: tricky question. Opus is a codec can be used in many containers/protocols. An ".opus" file is opus in an ogg container. [01:53:21 CET] <kepstin> faLUCE: I thought you were just streaming audio tho [01:53:23 CET] <Diag> Huh [01:53:26 CET] <furq> i thought you were still using mpegts for video+audio [01:53:32 CET] <furq> i guess if you want the same thing for both then ogg is no good [01:53:40 CET] <faLUCE> kepstin: no, I stream both audio and video. But when I stream audio only I can't use mpegts [01:54:14 CET] <faLUCE> furq: yes, I can use mpegts for audio+video and ogg for audio only.... but it would be better to have a common container [01:54:32 CET] <faLUCE> in addition, matroska is codec independent [01:54:57 CET] <kepstin> alright, sounds like matroska fits your goals fairly well then. [01:54:58 CET] <furq> i mean i'm not trying to tell you to not use mkv, mkv is all right [01:55:13 CET] <furq> but i wouldn't hold your breath for advanced params for tuning streaming stuff [01:55:21 CET] <furq> and that's already there for mpegts because it's extremely widely used for that [01:56:04 CET] <faLUCE> the main advantage of mpegts is that you don't need a global header. then, you can share one muxer's instance between all the streamers [01:56:20 CET] <faLUCE> with matroska I have to create one muxer per client [01:56:43 CET] <faLUCE> (same with ogg) [01:57:15 CET] <furq> i think i'll just stick with hls [01:57:24 CET] <kepstin> I guess it makes the app logic more complex, but muxing overhead really isn't that big of a deal [01:57:24 CET] <furq> 20 seconds of latency is all right by me [01:57:28 CET] <faLUCE> but the disadvantage of mpegts is that it has this pcr, which confuses the http receivers [01:58:00 CET] <faLUCE> kepstin: there's not a overhead. [01:58:18 CET] <kepstin> (I mean, you already have to handle separate tcp connections, ssl context, etc. per client) [01:58:28 CET] <furq> he means the cpu overhead of muxing twice instead of once [01:58:31 CET] <furq> what little there is of it [01:58:41 CET] <faLUCE> well, it is really little [01:59:04 CET] <faLUCE> kepstin: yes, but remember that the libav API is broken [01:59:12 CET] <faLUCE> IMHO [01:59:50 CET] <faLUCE> so, when I manage the HTTP clients with libevent, it's all simple [02:00:05 CET] <faLUCE> when I manage muxers with libav ... it's a torture [02:00:20 CET] <Diag> kepstin: whats the best way to encode opus [02:00:26 CET] <faLUCE> so I'm considering to use libmatroska [02:00:50 CET] <kepstin> Diag: most convenient is probably to do it with ffmpeg? (-c:a libopus) [02:00:53 CET] <faLUCE> the other problem of opus is that you have to resample [02:00:59 CET] <Diag> reeeetarded [02:01:11 CET] <furq> is your source not 48k [02:01:16 CET] <Diag> fuck no [02:01:19 CET] <furq> not you [02:01:19 CET] <Diag> its at 192 [02:01:22 CET] <Diag> oh [02:01:33 CET] <furq> although lol if you have 192khz shit [02:01:40 CET] <Diag> ? [02:01:52 CET] <Diag> i think its actually 96/24 [02:02:00 CET] <Diag> its from my badass soundblaster [02:02:16 CET] <furq> only three times bigger than it needs to be then [02:02:22 CET] <Diag> ?????// [02:02:25 CET] <gurki> then you probably can just downsample it as sbs quality is kinda shitty [02:02:26 CET] <gurki> scnr [02:02:26 CET] <gurki> :P [02:02:39 CET] <kepstin> if you're wondering why opus doesn't support >48kHz, go read https://people.xiph.org/~xiphmont/demo/neil-young.html - there's no point :/ [02:02:47 CET] <furq> you can downsample it anyway unless your name is rex and you like to chase sticks because you are a dog [02:03:16 CET] <gurki> nah. 96/24 is actually pretty usefull assuming ure into recording n stuff [02:03:18 CET] <Diag> lol wrong button [02:03:28 CET] <furq> anything above 48k is completely pointless [02:03:30 CET] <kepstin> (iirc, the opus encoder also has a lowpass filter around ~20kHz before encoding, too) [02:03:30 CET] <Diag> i said this in ##audio [02:03:39 CET] <Diag> Theres a big difference between 441 and 96 [02:03:41 CET] <furq> 24-bit is useful if you are mastering a record [02:03:48 CET] <furq> the extra sample rate makes no difference though [02:03:57 CET] <Diag> yes it does [02:04:09 CET] <Diag> umcompressed [02:04:13 CET] <Diag> un* [02:04:26 CET] <kepstin> only if your recording equipment has aliasing problems at lower rates... :/ [02:04:28 CET] <furq> if you believe that then i have got some cables to sell you [02:04:39 CET] <furq> be sure to plug them in the right way or the bits will uh [02:04:40 CET] <furq> fall out [02:04:42 CET] <Diag> no, if you dont believe theres a difference youre a fuckin idiot [02:04:54 CET] <Diag> The closer you are to 24khz the shittier the wave will be [02:05:07 CET] <Diag> its not huge [02:05:11 CET] <furq> whoa whoa enough with the science terms there einstein [02:05:14 CET] <Diag> but its big [02:05:16 CET] <kepstin> the higher you are above 20kHz the more inaudible the sound is so it doesn't matter? [02:05:23 CET] <Diag> well [02:05:31 CET] <Diag> at 16khz on a 48khz sample rate [02:05:48 CET] <kepstin> at 16kHz on 48kHz sample rate... the wave will be represented perfectly. [02:05:57 CET] <Diag> no it wont lol [02:06:09 CET] <furq> here come some cool edit pro screenshots [02:06:11 CET] <faLUCE> another shitty thing of vlc is that I have to add the muxer format to the url. [02:06:15 CET] <faLUCE> this is so baaaad [02:06:25 CET] <faLUCE> http://foooo/stream.ts [02:06:32 CET] <furq> faLUCE: it's really best to just forget vlc exists [02:06:34 CET] <Diag> honestly [02:06:39 CET] <faLUCE> furq: I can't [02:06:48 CET] <furq> didn't you say you had control over the receiving end [02:06:56 CET] <faLUCE> furq: no, absolutely not [02:07:01 CET] <furq> oh [02:07:04 CET] <furq> well that's a shame [02:07:11 CET] <Diag> youre getting 3 samples per wave [02:07:14 CET] <faLUCE> I have to make it working with vlc player on android [02:07:15 CET] <Diag> thats fucking shit [02:07:29 CET] <Diag> id rather have 6 [02:08:05 CET] <phillipk> I'm having issues with my filter_complex. I have one video (with audio) on which I'd like to layer 3 or more audio files, starting at specific times. [02:08:24 CET] <faLUCE> in addition, I can't ask anything in the vlc channel, because I've been banned [02:08:26 CET] <kepstin> Diag: as long as you have >2 samples per sine wave period, the reconstruction will be perfect, by nyquist theorem. [02:08:36 CET] <Diag> I dont want "reconstruction" [02:08:41 CET] <Diag> I want better input [02:08:44 CET] <gurki> kepstin: theres a problem. world doesnt consist of sine waves. [02:08:44 CET] <phillipk> Neither of the following commands work--but what's doubly odd, is the command makes the audio (in the one video input) get out of synch: [02:08:46 CET] <phillipk> http://pastebin.com/fMhXuS9v [02:08:49 CET] <furq> actually, that's only a "theory". i believe in intelligent audio design [02:08:57 CET] <phillipk> http://pastebin.com/uN5nnSCr [02:09:20 CET] <gurki> its actually kind of problematic to just call nqquist and be done with. (which is why i call b$ on that link...) [02:09:33 CET] <kepstin> gurki: then you need to go read the theorem; all wave patterns can be represented by an infinite series of sine waves; an in practise you can ignore the ones above a point because they're inaudible anyways. [02:09:39 CET] <phillipk> if anyone can just tell me what might not be correct in my -filter_complex and -map commands that'd be awesome. [02:09:45 CET] <gurki> kepstin: i a aware of that. [02:09:54 CET] <phillipk> thanks in advance--gotta go eat dinner [02:10:11 CET] <gurki> problem: you will need quite a few high frequencies to reconstruct a sawtooth function, leave alone a rect [02:10:24 CET] <gurki> hf reconstructing a rect with sines. [02:10:51 CET] <kepstin> you need infinite sampling rate to represent a step function correctly, yes. [02:10:54 CET] <kepstin> what's the point? [02:11:09 CET] <faLUCE> anyway, is there any other multiplatform player that I can try, other than VLC and MPLAYER ? [02:11:14 CET] <furq> mpv [02:11:23 CET] <kepstin> all using higher sampling rates does is add more inaudible harmonics :/ [02:11:36 CET] <gurki> point is: there is reason behind 48kHz. but nyquist isnt the reason imho [02:12:06 CET] <faLUCE> furq: let's try it [02:12:23 CET] <faLUCE> but... is it better than vlc ? [02:12:26 CET] <furq> yes [02:12:29 CET] <Hello71> why do you CAPITALIZE random WORDS [02:12:31 CET] <kepstin> well, the audio cd 44.1kHz is perfectly fine, 48kHz is just a nice round number with easy integer divisions that's high enough to represent ~20kHz correctly. [02:12:43 CET] <Hello71> but YOU only do it HALF the TIME [02:12:53 CET] <gurki> you can swap out 44.1 and 48 as you like in that statement i made there :) [02:14:30 CET] <furq> my cables are still for sale btw [02:14:33 CET] <furq> http://i.ebayimg.com/00/s/MTA2NlgxNjAw/z/P9oAAOSwAKxWYsnn/$_57.JPG [02:17:23 CET] <kepstin> hmm? no, it follows - humans hear up to around or a little over 20kHz, by nyquist you need at least double that to represent it correctly, then round up a bit so we have a nice integer and a little headroom for the falloff of the anti-aliasing filter. [02:19:13 CET] <furq> ah, but you see; if it was pointless to have 24/192 flac, then why would i have spent so much money on it? [02:19:17 CET] <furq> check and mate [02:20:05 CET] <kepstin> maybe it has secret messages hidden in the high frequencies. try slowing it down to 1/4 or 1/8 speed to hear them. [02:20:19 CET] <Diag> furq: dunno, i could play 96mhz AM out of my card if i wanted to lol [02:20:29 CET] <furq> actually it's because it allows for better hidden drawings of aphex twin's face in the spectrals [02:20:30 CET] <Diag> KHZ* [02:20:31 CET] <Diag> jesus [02:20:34 CET] <Diag> i must be tired [02:20:55 CET] <Diag> i have plenty of samples [02:21:04 CET] <Diag> and plenty of room for higher freqs [02:21:09 CET] <Diag> why cap yourself to 24k lol [02:21:23 CET] <furq> because i'm not a dog [02:21:26 CET] <furq> at least, not yet [02:21:37 CET] <furq> who knows what the future holds [02:21:41 CET] <Diag> dunno [02:21:46 CET] <Diag> I like my card [02:21:50 CET] <Diag> Lots of good shit [02:22:10 CET] <Diag> Shit like [02:22:20 CET] <Diag> actual amps for the volume control [02:22:25 CET] <Diag> rather than just bit shifting/dropping [02:22:37 CET] <Diag> or stupid software shit [02:22:53 CET] <Diag> oh also [02:22:54 CET] <Diag> ALSO [02:23:03 CET] <furq> that's good because it is impossible to connect a soundcard to an external amp [02:23:08 CET] <kepstin> amps in general don't have volume control; that's usually done with variable resistors if it's done in analog [02:23:33 CET] <Diag> it produces a 96khz wave at ~95% amplitude of same at 60hz [02:23:41 CET] <Diag> cant say that about much audio hardware [02:23:45 CET] <kepstin> digital volume control probably has less distortion in most cases, particularly if you're using 24bit [02:23:45 CET] <Diag> my old desktop for ex [02:24:02 CET] <Diag> was dropping to about 25% at 20khz [02:24:19 CET] <furq> you keep saying a lot of things which are not remotely the same as "it sounds better" [02:24:25 CET] <Diag> it sounds better [02:24:44 CET] <furq> have you abx tested it [02:24:52 CET] <Diag> wtf is abx [02:25:05 CET] <furq> why am i even talking to someone about audio quality who doesn't know what abx testing is [02:25:25 CET] <furq> i guess at least that's better than the audiophiles who earnestly claim that doing an abx test reduces sound quality [02:25:29 CET] <Diag> because you think resampling sounds good loloololololol [02:25:40 CET] <Diag> you have no idea [02:26:11 CET] <kepstin> there's a lot of things that are easily way, way, more audible than resampling [02:26:22 CET] <furq> i bet you don't even have any 96khz audio [02:26:25 CET] <Diag> Ok [02:26:26 CET] <Diag> lol [02:26:27 CET] <furq> i bet you don't even have any ears [02:27:05 CET] <furq> this is just the card you picked from the tedious internet argument generator [02:27:12 CET] <Diag> ha [02:27:18 CET] <Diag> uhhuh [02:27:21 CET] <Diag> sorry i test this shit [02:27:27 CET] <Diag> and watch the waveforms with a scope [02:27:34 CET] <Diag> and watch the actual deformation [02:27:37 CET] <furq> shame you don't abx test it, eh [02:27:40 CET] <kepstin> confirmed: no ears. listens to music with eyes. [02:27:59 CET] <furq> the truth comes out at last [02:28:14 CET] <Diag> Couldnt you dumb fucks tell taht when i was posting pictures of waveforms [02:28:28 CET] <furq> i could tell something when you were doing that [02:29:44 CET] <kepstin> https://youtu.be/cIQ9IXSUzuM?t=520 hey look pictures of waveforms: https://youtu.be/cIQ9IXSUzuM?t=424 [02:29:51 CET] <kepstin> er, second link is more fun [02:30:48 CET] <furq> i should donate to xiph.org so monty can buy a razor [02:31:48 CET] <faLUCE> is there a way to detect a reference frame with libav? I have the AVPacket got from av_encode_audio() [02:32:07 CET] <kepstin> not sure what you mean by "reference frame" [02:32:21 CET] <kepstin> audio codecs in general don't have anything like keyframes in video [02:32:49 CET] <faLUCE> kepstin: something that helps to make the stream seekable [02:33:11 CET] <faLUCE> I encode on the fly, and at a certain point, I stream the packets [02:33:24 CET] <faLUCE> I don't stream when the encoding starts [02:33:39 CET] <kepstin> faLUCE: you can start decoding audio at any frame, but the decoder has to throw out the first few samples it decodes (depending on the codec this is either handled automatically, or has to be signalled) [02:34:54 CET] <faLUCE> kepstin, mp4 wants a seekable stream [02:35:21 CET] <faLUCE> then I have to start the stream with a keyframe [02:35:45 CET] <kepstin> for video, yes... audio isn't video. [02:36:35 CET] <faLUCE> kepstin: it warns me for audio-only [02:36:54 CET] <kepstin> what warns you, and what warning message do you get? [02:37:55 CET] <faLUCE> kepstin: [mp4 @ 0x353f860] muxer does not support non seekable output [02:38:37 CET] <kepstin> that has nothing to do with the codec, that's just saying you can't write mp4 container to a stream/pipe [02:38:52 CET] <kepstin> you can only write mp4 to files, because the format's silly. [02:39:08 CET] <kepstin> needs to write some data at the start which you only know after you've already written the end. [02:39:21 CET] <faLUCE> kepstin: I see [02:39:22 CET] <faLUCE> thanks [02:39:40 CET] <faLUCE> I thought mp4 could be streamed [02:39:41 CET] <kepstin> aac in mkv should work find, just mp4 won't [02:40:12 CET] <kepstin> mp4 can only be used for streaming with segmented files or video-on-demand pre-encoded files [02:40:44 CET] <kepstin> (where segmented files obviously has high latency, and you can't pre-encode live streams) [02:44:35 CET] <faLUCE> kepstin: but does the streamer send trailer infos to the receiver before it starts? [02:45:33 CET] <kepstin> for pre-encoded live streams, you can use tools after encoding (e.g. ffmpeg's "-movflags faststart") to move the index & format info to the start of the file so it can be played without seeking [02:45:41 CET] <kepstin> for pre-encoded not-live streams* [02:47:47 CET] <faLUCE> furq: mpv doesn't play matroska http at all. Tried with both my program and with ffmpeg (ffmpeg -i test.mka -listen 1 -f matroska http://localhost:8080/stream) [02:48:54 CET] <kepstin> faLUCE: works fine for me...? [02:49:49 CET] <faLUCE> kepstin: you can play http matroska live streams with mpv? [02:49:58 CET] <kepstin> yep [02:50:11 CET] <faLUCE> kepstin: how did you test it? [02:51:15 CET] <kepstin> in one terminal, `ffmpeg -f pulse -i default -c:a libopus -b:a 128K -listen 1 -f matroska http://localhost:8080/stream` in the other `mpv http://localhost:8080/stream` and now my room is full of feedback so i ctrl-c'd it. [02:53:31 CET] <faLUCE> kepstin: same error, which version of mpv do you use? [02:53:49 CET] <faLUCE> prebuilt or compiled? [02:54:15 CET] <kepstin> whatever my distro has, --version output claims 0.21 [02:54:58 CET] <kepstin> hmm, i should update that. [02:55:09 CET] <faLUCE> which distro do you use? [03:02:20 CET] <furq> that works for me with 0.23 [03:02:23 CET] <furq> it doesn't spawn a window though [04:06:29 CET] <gurki> dear god. theese libmfx compile-error-messages really need a rework. telling me that "libmfx not found using pkg-config" although it clearly has been found from what the config.log tells me, the issue being some mixup while throwing gcc at it [04:06:43 CET] <gurki> configure * [04:08:06 CET] <furq> that's not specific to libmfx, that happens with pretty much every dependency [04:08:27 CET] <gurki> i didnt know that. i assume the best until proven otherwise :) [04:08:51 CET] <furq> it's not great but anyone who builds ffmpeg regularly knows to just check config.log [04:09:25 CET] <gurki> well it took me quite a while and fumbling with strace output before i figured checking that might be an option :( [04:09:36 CET] <furq> it mentions config.log in the error doesn't it [04:10:01 CET] <gurki> actully it doesnt [04:10:02 CET] <furq> but yeah it should at least say something like "not found using pkg-config or error running tests" [04:10:10 CET] <furq> because it's normally the latter [04:10:11 CET] <gurki> (i was actually going to propose doing just that) [04:10:35 CET] <gurki> argh. i have to take that back. gurki failed. [04:11:52 CET] <gurki> it stats that including the log by whining here about the error might help [04:11:53 CET] <furq> it mentions it in a slightly roundabout way [04:11:57 CET] <furq> yeah [04:12:04 CET] <furq> https://github.com/FFmpeg/FFmpeg/blob/master/configure#L477-L498 [04:12:06 CET] <gurki> guess thats why i overlooked it [04:13:16 CET] <furq> i can imagine it's non-trivial to reliably tell why the test failed, but "not found using pkg-config" is usually not the reason [04:13:46 CET] <gurki> well it might actually be an idea to print the very error that could be found in the config.log ... [04:14:07 CET] <gurki> but then you seem to try-and-error a lot of stuff during the configure process, so that might not be that easy [04:14:32 CET] <furq> the way it's written atm makes that difficult [04:18:18 CET] <gurki> well you could tail the config.log ... [04:18:34 CET] <gurki> thats kind-of independent of internal states of whatever [04:18:53 CET] <gurki> not exactly good style, but should work [04:52:14 CET] <faLUCE> well. I don't understand.... it seems that there's no way to stream HTTP live audio with ffmpeg without having a big delay on the receiver [05:37:33 CET] <kepstin> unless you control the client side and can manage the buffering there, that's gonna be true regardless of whether ffmpeg is involved or not... [05:40:04 CET] <kepstin> i wouldn't be surprised if it's less noticable with video simply because the players are using a min buffer size that holds more audio than audio+video. [09:44:06 CET] <ePirat> What are good settings for swresample for realtime resampling with high quality? [09:48:49 CET] <thebombzen> anyone know how to get the image2 muxer to overwrite the same file [10:46:05 CET] <durandal_1707> thebombzen: you cant [10:46:21 CET] <thebombzen> um you used to be able to? [10:47:45 CET] <thebombzen> lol rtfm [10:47:50 CET] <thebombzen> @me it's just -update 1 [14:53:39 CET] <joltmode> I have a video source that emits a png to stdout at random intervals. How can I use it as an input for ffmpeg and render a video @ constant frame rate? I want that the last image to be looped until replaced. [14:58:40 CET] <DHE> I think you can do that if it overwrites the old file [15:00:58 CET] <joltmode> I have some png reading errors at times then. ffmpeg eventually stops because of those. Don't know, something with overwrite I/O or what not.. [15:02:03 CET] <DHE> probably needs to be an atomic overwrite. write to a new file and rename() over the old one [15:03:33 CET] <joltmode> Ah, I attempted with cp()... is rename() different from it? [15:03:49 CET] <BtbN> it's atomic [15:04:09 CET] <JohnPreston72> Anyone has some good doc ref: Use NVIDIA + FFMPEG for nvenc etc. [15:04:19 CET] <JohnPreston72> and maybe even some benchmarks ? :) [15:11:18 CET] <kerio> joltmode: cp will open the old file, write, truncate and close [15:11:48 CET] <kerio> anyone with that file open will see any of the modifications done to the file, essentially at random [15:12:11 CET] <kerio> (i'm not even sure the order of modification is preserved, without an explicit fsync) [15:12:25 CET] <kerio> so instead of updating the file by opening and writing to it [15:12:32 CET] <kerio> you should write to a brand new temporary file [15:12:36 CET] <kerio> and rename it [15:12:50 CET] <kerio> whoever opened the file will either get the old file, or the new file [15:13:00 CET] <kerio> and both will be written to completion [15:14:30 CET] <joltmode> cool, good to know [15:17:03 CET] <kerio> you can even do some slightly fancier and crazier stuff [15:18:12 CET] <kerio> but it depends on the OS, it's nonstandard [15:18:18 CET] <kerio> you can like [15:18:36 CET] <kerio> open a temporary file with no name, write to it, then rename its file descriptor onto the new file [15:36:29 CET] <joltmode> cool, changed cp to mv and it works flawlessly. thanks guys! [18:44:21 CET] <phillipk> I have a question about this excerpt: f -filter_complex "[0:2]adelay=10000| 10000[delayed];[0:1][delayed]amix[mixout]" [18:44:36 CET] <phillipk> what's "0:2" --the first input, third stream in that input? [18:48:31 CET] <JEEB> yup [18:49:44 CET] <phillipk> what if I did [0:a] audio in the first input? [18:51:38 CET] <JEEB> phillipk: that would map against all audio tracks [18:51:53 CET] <JEEB> thus 0:a:0 is something specific to a single track [18:52:03 CET] <JEEB> also languages can be picked etc [19:07:09 CET] <phillipk> thanks--now if I can figure out another issue (when I have a video+audio input and then several audio onlys that I'm adelay and amix... the audio in the main video gets out of synch). I'll see if doing adelay=n|n works better than what I had before: adelay=n [19:09:38 CET] <phillipk> so, if in my filter_complex, I do: [1] it just takes the entire second input right? [19:13:29 CET] <phillipk> here's my current command for this step--any insights are welcome (my issue is the audio in "audio_and_video.ts" gets out of synch!): http://pastebin.com/hbn3AzgP [19:40:49 CET] <durandal_1707> phillipk: all audio are stereo? [19:51:03 CET] <phillipk> yes [19:52:30 CET] <phillipk> the stuff in the -filter_complex (channel_layouts=stereo) is what I figured would ensure this--but I actually pre-process the audio to make sure every one is stereo [20:11:53 CET] <shincodex> so... this is a stupid question but [20:12:04 CET] <shincodex> is ffmpeg leaking like 4 bytes every other idk 5 minutes [20:12:41 CET] <JEEB> it shouldn't, but everything is possible so run that baby under valgrind to make sure :P [20:13:56 CET] <shincodex> hopefully vld will shoot something out [20:14:02 CET] <shincodex> and hopefully its my misuse [20:16:58 CET] <shincodex> whoa i think i found the pattern [20:17:10 CET] <shincodex> 8 seconds 4 bytes, 2 seconds 4 bytes 5 seconds 4 bytes repeat [20:17:35 CET] <shincodex> do these lotto numbers make anyone remember a time? [20:30:04 CET] <GNU\colossus> hi. I have a few hundred audio files (in OGG Vorbis and MP3 files) that I have rescued from a broken storage medium. can I somehow use ffmpeg to decode (but not play) them as fast as possible, and produce a list of files that seem to have problems in their data paylod/did not decode cleanly? [20:31:46 CET] <kerio> GNU\colossus: ffmpeg -i foo.mp4 -f null dummy [20:31:52 CET] <kerio> er, mp3 [20:32:05 CET] <kerio> it'll decode all the streams [20:32:10 CET] <GNU\colossus> kerio, thanks! [20:32:14 CET] <kerio> not sure how to make it block on errors [20:32:27 CET] <kerio> or how much of an error is an error, to you [20:32:58 CET] <GNU\colossus> I think Ican work with that :) [20:33:23 CET] <kerio> you probably want -nostats [20:33:27 CET] <kerio> to disable the progress thingy [20:33:31 CET] <GNU\colossus> I'm not sure, actually :) just looking for a way to trim down the list of files I'll have to listen to to determine if I need to restore them from elsewhere [20:35:33 CET] <kerio> and that is why we use filesystems with redundancy and checksums [20:38:32 CET] <GNU\colossus> kerio, well, not on a crappy mp3 hifi appliance that only supports FAT32-formatted media :) [20:38:41 CET] <GNU\colossus> but yeah, in a perfect world... [20:39:04 CET] <kerio> apple got so close [20:39:14 CET] <kerio> and then they decided that they didn't need checksums on data [20:39:29 CET] <Diag> >crappy mp3 [20:39:35 CET] <Diag> mp3 sounds fan fucking tastic [20:39:40 CET] <kerio> no it doesn't [20:39:45 CET] <Diag> (inb4 furq) [20:39:51 CET] <kerio> you can make it sound decent [20:40:00 CET] <kerio> by using way too much bits [20:40:04 CET] <kerio> many [20:40:05 CET] <Diag> kerio: http://i2.kym-cdn.com/photos/images/newsfeed/000/992/401/e37.png [21:11:02 CET] <DHE> I ran "sh configure --disable-hwaccels" but it still lists hwaccels as enabled, including nvenc, cuda, xvmc and so on. Bug? [21:32:21 CET] <francesco_> hey people, could you explain me the use of AVDiscard ? [21:32:28 CET] <francesco_> when is it useful? [00:00:00 CET] --- Tue Jan 31 2017

1 0

ffmpeg-devel.log.20170129
by burek 30 Jan '17

30 Jan '17

[01:24:26 CET] <cone-381> ffmpeg 03Andreas Cadhalpun 07master:e3f13d3a8727: 4xm: prevent overflow during block alignment calculation [01:24:27 CET] <cone-381> ffmpeg 03Andreas Cadhalpun 07master:8812d047bc85: electronicarts: prevent overflow during block alignment calculation [01:24:28 CET] <cone-381> ffmpeg 03Andreas Cadhalpun 07master:169c1cfa9280: pvfdec: prevent overflow during block alignment calculation [01:24:30 CET] <cone-381> ffmpeg 03Andreas Cadhalpun 07master:9ec8790ac478: boadec: prevent overflow during block alignment calculation [13:31:37 CET] <cone-988> ffmpeg 03Paul B Mahol 07master:c6f7f33eec8e: avfilter/vf_remap: add . at end of long description [15:20:17 CET] <Polochon_street> wm4: hi! I'm trying to make the fate test as you advised, with for example a flac file with id3v2 tags; do you think it should be on the libavformat.mak test file or more on the flac.mak test file? [15:21:02 CET] <durandal_1707> whatever you prefer [15:21:26 CET] <wm4> yeah [15:22:25 CET] <Polochon_street> okay thanks :) [16:13:11 CET] <cone-988> ffmpeg 03Michael Niedermayer 07master:bbd4d9230407: doc/examples/decoder_targeted: Disable error concealment after 20 frames [16:14:52 CET] <wm4> michaelni: are you really, really, really sure our examples should contain such a hack? [16:17:39 CET] <michaelni> that code is used by oss-fuzz [16:18:34 CET] <michaelni> maybe it should be in tools and not examples [16:18:56 CET] <wm4> ... [16:19:19 CET] <wm4> I hope you know that this code is very likely to be copied into random new projects using libavcodec [16:19:25 CET] <wm4> because that's what the examples are for [16:19:33 CET] <wm4> so should they really contain something this specific [16:20:18 CET] <Shiz> ^agree [16:20:25 CET] <michaelni> if someone wants to move it to tools, i support that [16:32:07 CET] <atomnuker> michaelni, wm4: patch sent [17:14:49 CET] <cone-988> ffmpeg 03Rostislav Pehlivanov 07master:e05d2dd86abc: doc/examples/decoder_targeted: move to tools/target_dec_fuzzer.c [17:16:41 CET] <t_than> BBB, I'd like to ask you a question about the VP9 GSoC project [17:17:00 CET] <t_than> seems interesting and I'm thinking about applying [17:17:36 CET] <BBB> ask away [17:18:01 CET] <t_than> to be sure, when you mention "tile threading support", that is VP9 tiles decoded using pthreads? [17:18:33 CET] <BBB> indirectly, yes [17:18:44 CET] <BBB> but I want it using the slice task api in libavcodec [17:18:56 CET] <BBB> so that its directly available in user applications and tools [17:19:21 CET] <BBB> compare h264/vp8 -thread_type frame or -thread_type slice [17:19:42 CET] <BBB> for vp9, -thread_type frame works, but -thread_type slice does not (I want that to work using the tiling feature) [17:20:57 CET] <BBB> t_than: check how some decoders use avctx->execute2() as part of their internal frame decoding loop [17:21:33 CET] <BBB> it splits the frame in multiple independent units and decodes each (using slice threading api and pthread) independently [17:21:40 CET] <BBB> I want that invoked for tiles also [17:23:11 CET] <t_than> ok, I'll check them out. I've just started out peeking the code and I'll be coming back for more info when I'll have some things figured out [17:24:02 CET] <BBB> okay [17:24:15 CET] <t_than> many thanks for the help :) [17:25:14 CET] <BBB> the main loop is in vp9_decode_frame line 4127-4254 [17:25:20 CET] <BBB> youll notice tile_row and tile_col [17:25:30 CET] <BBB> tile rows cannot be threaded, but tile cols can [17:25:42 CET] <BBB> so the idea is to split the decoding into independent tile col units [17:25:51 CET] <BBB> and use avctx->execute() to decode each unit independently [17:26:14 CET] <BBB> note that the loop filter crosses tile col boundaries so you need some pthread_cond logic to make sure theres no race conditions there [17:26:46 CET] <BBB> (e.g. do the loopfilter as one separate thread that waits for all tile cols for that y to be finished before it does its thing) [17:27:42 CET] <BBB> I can provide some tile col samples once you get to the testing part (not all files have tile cols enabled) [17:27:52 CET] <BBB> but youtube is a good source for clips also, all hd is tiled vp9 nowadays [17:28:27 CET] <t_than> that's a useful info [17:29:40 CET] <t_than> thanks again, I hope we'll talk again soon [18:27:13 CET] <atomnuker> BBB you can't do that, there's no way to synchronize with tile threading like that [18:27:27 CET] <BBB> atomnuker: there is, vp8 does it [18:27:53 CET] <atomnuker> like, it runs the loop filter as part of avctx->execute2? [18:28:13 CET] <atomnuker> how does it synchronize, do the functions for frame threading still work with slice therading? [18:39:35 CET] <Polochon_street> wm4: for the id3v2 tests, would a static test over a flac file with id3v2 tags + vorbis comments enough? Like, check if the decoded artist tag is "Artist" and not "Artist;Artist", for example [18:42:12 CET] <wm4> Polochon_street: yeah [18:54:01 CET] <cone-988> ffmpeg 03Nicolas George 07master:383057f8e744: lavfi: make ff_framequeue_skip_samples() more useful. [20:21:28 CET] <philipl> I got bored and decided to revist support for P016 input in swscale. I cannot for the life of me understand what it's doing. I patterned my change on the P010 code but it's not getting called. Something else is going on and some code path is being taken that is dropping all the chroma information (I just get monochrome output) [20:23:50 CET] <Polochon_street> wm4: for the id3v2 test, something like this? http://sprunge.us/OLaH (this is really a first version, just to check if we're thinking about the same thing) [20:25:14 CET] <wm4> Polochon_street: normally we'd check ffprobe output or so... I'm not sure if this case warrants adding a new test program, as it'd be relatively unusual [20:26:14 CET] <Polochon_street> wm4: oh, okay, nevermind then, I'll use ffprobe output [20:26:37 CET] <wm4> there are possibly other tests that check metadata support or so [20:33:55 CET] <Polochon_street> well, I'm trying to look for them right now, but I can't find anything. Maybe in audio-filter.mak? [20:34:09 CET] <Polochon_street> audio.mak* [22:07:32 CET] <cone-988> ffmpeg 03Matthieu Bouron 07master:2ae827883244: lavc/mjpegdec: consume SOS data even if the frame is discarded [22:30:58 CET] <ePirat> Good evening [22:39:39 CET] <durandal_1707> gonna push scc muxer [23:46:01 CET] <cone-988> ffmpeg 03Muhammad Faiz 07master:c4a3526b57dc: avfilter/showcqt: make minimum timeclamp option lower [00:00:00 CET] --- Mon Jan 30 2017

1 0

ffmpeg.log.20170129
by burek 30 Jan '17

30 Jan '17

[00:50:01 CET] <faLUCE> furq: well, I implemented the AAC encoding, and I can hear audio, but I still see the adaptation field in the mpegts header. So, I have this damned pcr again... In addition, audioCodec->capabilities & AV_CODEC_CAP_VARIABLE_FRAME_SIZE == 0, so it seems that this codec doesn't support VBR [00:52:07 CET] <faLUCE> I don't even understand if it's me that has to set AV_CODEC_CAP_VARIABLE_FRAME_SIZE , or it's left to the encoder [00:52:49 CET] <atomnuker> variable frame size is only supported by s302m [00:53:18 CET] <atomnuker> that's a property which just says you can feed the encoder any number of samples per frame [00:53:30 CET] <atomnuker> for aac you have to feed in 1024 samples per frame [00:53:50 CET] <atomnuker> VBR is something completely different to that [00:54:17 CET] <atomnuker> VBR means your output packets are going to vary in size [00:54:58 CET] <atomnuker> which they always do because AAC is only VBR [00:56:05 CET] <faLUCE> atomnuker: the problem is that for audio packets the muxer sends an adaption field and pcr... is there a way to set it with variable muxrate ? [00:56:42 CET] <faLUCE> atomnuker: or is it available only for s302m ? [00:57:20 CET] <faLUCE> if the pcr is sent through http, the receiver relies on it for buffering, and it messes up stuff [00:57:36 CET] <faLUCE> (I don't have this problem with video) [01:03:18 CET] <faLUCE> otherwise I don't find any other way to stream audio only with low latency.... maybe pseudo-raw mp2 or aac? (without mpegts container) [01:08:16 CET] <atomnuker> faLUCE: I don't get what the problem is, you give the muxer packets and that's it, no? [01:11:09 CET] <DHE> the mpegts muxer is writing PCR fields which is called for by the mpegts standard but apparnetly causes VLC to have a shit fit [01:11:46 CET] <JEEB> whiich could be worked around by just switching the container to something else the receiving end supports :P [01:12:59 CET] <DHE> what's a good alternative streaming format? ogg? does that support AAC audio? [01:13:02 CET] <kepstin> aac is always gonna be fairly high algorithmic latency, unless you're talking about AAC-LD which I have no idea what anything supports it... [01:15:11 CET] <JEEB> DHE: fragmented ISOBMFF, matroska are some of the more supported things. and then there's NUT if you're using libavformat on both sides. [01:15:29 CET] <JEEB> it's mostly a case of what the client supports rather than what's a nice alternative [01:15:41 CET] <faLUCE> I wonder if I can stream the mpga or aac container only. It has all the infos needed (samplerate, codec) [01:15:58 CET] <JEEB> nothing stops you from doing that :P [01:16:33 CET] <faLUCE> JEEB: I know but I have to spend much time for it [01:17:09 CET] <JEEB> which, fortunately, is none of my concern [01:17:38 CET] <faLUCE> then I wonder which is the most common way to stream http audio [01:17:51 CET] <kepstin> if you want tostream audio only with low latency, why aren't you doing opus in rtp or something like that? [01:18:10 CET] <faLUCE> kepstin: I don't want to use rtp [01:18:17 CET] <kepstin> (you could do that by being a webrtc endpoint, if you want to talk to a browser) [01:18:27 CET] <faLUCE> kepstin: few players support a good rtp client [01:19:03 CET] <faLUCE> kepstin: the main advantage of http is that it's supported by all the players [01:20:12 CET] <kepstin> hmm, with any sort of http streaming, you're gonna be dealing with pretty big buffers on the client side, so "low latency" on the encoder side isn't really something worth worrying about. [01:20:26 CET] <faLUCE> kepstin: really not. [01:20:35 CET] <faLUCE> I can stream audio+video with low latency [01:20:39 CET] <faLUCE> (200ms) [01:21:01 CET] Action: kepstin wouldn't call 200ms low, but he mostly does telephony/conferencing stuff. [01:21:26 CET] <faLUCE> kepstin: it's low for my purposes [01:21:57 CET] <faLUCE> but I don't understand how to mux audio only [01:23:47 CET] <kepstin> hmm, if I controlled the player side, and had to use straight http streaming, I'd probably just used opus in ogg container. Should work perfectly fine, ogg is streamable. [01:26:23 CET] <faLUCE> kepstin: but ogg doesn't seem to support AAC [01:26:34 CET] <furq> it supports opus though [01:26:36 CET] <kepstin> yeah, well, aac sucks for low latency stuff anyways [01:26:49 CET] <faLUCE> I have to try opeus then [01:26:51 CET] <faLUCE> opus [01:26:53 CET] <furq> mpegts supports opus as well afaik [01:27:00 CET] <kepstin> iirc most aac encoders will have 50-100ms of algorithmic delay? [01:27:02 CET] <furq> but you'll want to check anything you might want to use to playback this stream supports it [01:27:09 CET] <furq> and supports it in mpegts [01:27:25 CET] <faLUCE> furq: vlc mplayer and ffplay [01:28:13 CET] <furq> do you have control over which players are used [01:30:31 CET] <faLUCE> furq: yes [01:30:44 CET] <furq> do you need vlc support then [01:30:56 CET] <furq> does it work with mp2 audio in mpv or some other player which doesn't suck [01:31:23 CET] <faLUCE> furq: I just have to try opus+ogg [01:31:31 CET] <furq> fair enough [01:32:14 CET] <faLUCE> so, the remaining alternatives are ogg and matroska [01:32:17 CET] <faLUCE> from what I see [01:43:20 CET] <faLUCE> well, CODEC_ID_OPUS is not found with avcodec_find_encoder(). I tried also VORBIS, but it supports only two channels (and I have a mono input) [01:43:50 CET] <furq> is your ffmpeg built with libopus [01:44:23 CET] <faLUCE> furq: probably not. Let's recompile [01:44:25 CET] <faLUCE> thnks [02:01:59 CET] Action: ParkerR sees mention, greps log, just another mass spam mention like usual :( [03:07:21 CET] <the_k> how come i can't find -strftime in the documentation [03:07:25 CET] <the_k> is it depreciated? [03:12:38 CET] <thebombzen> the_k: man ffmpeg-all has it [03:14:26 CET] <thebombzen> this example is straight from the docs: ffmpeg -f v4l2 -r 1 -i /dev/video0 -f image2 -strftime 1 "%Y-%m-%d_%H-%M-%S.jpg" [03:15:18 CET] <thebombzen> it's an option for the segment muxer and the image2 muxer [03:15:23 CET] <thebombzen> see ffmpeg-formats or ffmpeg-all [03:16:21 CET] <the_k> i'm not sure what you mean by ffmpeg-all [03:16:30 CET] <the_k> is that a different project? [03:16:51 CET] <the_k> or a switch... -that doesn't seem to work [03:17:41 CET] <thebombzen> the_k: the documentation, as in "man ffmpeg-all" or "man ffmpeg-formats" [03:18:04 CET] <thebombzen> if you want the HTML reference, see this page: https://ffmpeg.org/ffmpeg-formats.html [03:18:06 CET] <the_k> right [03:18:09 CET] <the_k> well i'm on windows [03:18:14 CET] <the_k> so i'm looking at the docu online [03:18:19 CET] <thebombzen> see the above link [03:18:20 CET] <the_k> i searched for -all and found nothing [03:18:41 CET] <thebombzen> as for ffmpeg-all, it totally exists: https://ffmpeg.org/ffmpeg-all.html [03:18:56 CET] <thebombzen> it's all on the website [03:19:12 CET] <the_k> searching in that page for "-all" finds nothing [03:19:20 CET] <the_k> oh [03:19:23 CET] <the_k> i seeee [03:19:31 CET] <the_k> that's the entire documentation! [03:19:43 CET] <thebombzen> yes [03:19:45 CET] <thebombzen> yes it is [03:19:52 CET] <thebombzen> that's what ffmpeg-all means. it means "all the documentation" [03:19:58 CET] <the_k> gotcha! [03:20:30 CET] <the_k> ok right i see strftime in this documentation page [03:20:41 CET] <thebombzen> or rather, it's all the documetation for the ffmpeg tool and any related libraries [03:20:53 CET] <the_k> but not on http://ffmpeg.org/ffmpeg.html "ffmpeg Documentation" [03:21:08 CET] <thebombzen> well that's because ffmpeg is a command line tool [03:21:14 CET] <thebombzen> it tells you how to use ffmpeg.c [03:21:31 CET] <thebombzen> (often times here we call the CLI tool ffmpeg.c to disambiguate it from the FFmpeg project) [03:21:36 CET] <the_k> so what is strftime a part of [03:21:50 CET] <thebombzen> strftime is an option for the image2 muxer and the segment muxer [03:21:59 CET] <the_k> CLI means command line interface? [03:22:01 CET] <thebombzen> yes [03:22:05 CET] <the_k> riiight [03:22:08 CET] <the_k> ok [03:22:14 CET] <thebombzen> the image2 muxer and the segment muxer are part of libavformat [03:22:25 CET] <thebombzen> so ffmpeg-formats would have information on demuxer and muxer options [03:22:26 CET] <the_k> ok makes sense [03:23:21 CET] <the_k> strftime 1|0 [03:23:21 CET] <the_k> Use the strftime function to define the name of the new segments to write [03:24:07 CET] <the_k> so these are not DOS vars? name_%Y-%m-%d-%H;%M;%S.ts [03:24:15 CET] <the_k> i assumed they were [03:24:30 CET] <furq> %Y% would be a batch var [03:24:57 CET] <the_k> yeah that's right [03:25:03 CET] <the_k> ah ok [03:25:15 CET] <furq> also if you're who i think you are, https://www.ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_… [03:25:30 CET] <the_k> i was here the other nigth talking to u [03:25:36 CET] <the_k> last night [03:26:32 CET] <furq> actually i just remembered i made this damn thing months ago so i wouldn't have to keep pasting segments of the docs and then forgot about it [03:26:35 CET] <furq> i should bring it in here [03:27:16 CET] <furq> !muxer segment [03:27:16 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [03:27:19 CET] <furq> there [03:27:26 CET] <furq> if you hate my bot please tell me and i will make it leave [03:27:50 CET] <thebombzen> !encoder hevc_nvenc [03:27:59 CET] <furq> !encoder list [03:27:59 CET] <nfobot> furq: aac, ac3_fixed, amrnb, amrwbenc, dvdsub, encoders, flac, hap, jpeg2000, libfdk_aac, libkvazaar, libmp3lame, libopenh264, libopus, libshine, libtheora, libtwolame, libvorbis, libvpx, libwavpack, libwebp, libx264, libx264rgb, libx265, libxvid, mpeg2, png, prores, snow, vc2, wavpack [03:27:59 CET] <thebombzen> hmmm [03:28:06 CET] <furq> it only has the ones listed on the site [03:28:29 CET] <thebombzen> !hwaccel list [03:28:34 CET] <nfobot> furq: Available functions: muxer demuxer encoder decoder filter source sink indev outdev protocol bsf [03:28:42 CET] <furq> idk if there's a parseable list of hwaccels in the docs [03:28:44 CET] <thebombzen> I'm 0-2 lol [03:28:57 CET] <thebombzen> !muxer matroska [03:28:57 CET] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-formats.html#matroska [03:29:01 CET] <furq> there you go [03:29:15 CET] <furq> !muxer matroska @thebombzen [03:29:15 CET] <nfobot> thebombzen: http://ffmpeg.org/ffmpeg-formats.html#matroska [03:29:27 CET] <furq> and that's all the features [03:29:33 CET] <thebombzen> that's a very disappointinly small list of muxer options [03:29:35 CET] <thebombzen> for matroska [03:33:01 CET] <furq> the web docs for muxers and encoders are missing a bunch of stuff [03:33:10 CET] <faLUCE> furq: the problem with ogg is that only the FIRST packet (stream header) contains the infos about the codec. (mpegts collects this info at each packet). Then I wonder... is there anylibav function for getting the header of a muxed packet? I searched a lot but could not find anyone [03:33:12 CET] <furq> you're better off just using -h encoder for that [03:34:58 CET] <the_k> furq, even if i lower the fps and bitrate of the server's livestream - ffmpeg keeps dropping frames ("error while decoding MB ...") [03:35:33 CET] <furq> pastebin the command [03:35:42 CET] <the_k> if i remove the piped command on the end that piped it to mpv then it saves to disk fine [03:35:44 CET] <the_k> sure [03:35:46 CET] <furq> oh right [03:35:52 CET] <furq> maybe just don't pipe it to mpv then ;_; [03:36:02 CET] <the_k> well [03:36:08 CET] <the_k> if i do that then it would save bandwidth [03:36:18 CET] <furq> that shouldn't make any difference [03:36:20 CET] <the_k> enough to make a difference to what i can do with the stream [03:36:30 CET] <furq> ffmpeg only decodes the stream once [03:36:38 CET] <the_k> the hq stream is 1.5mb/s [03:36:47 CET] <the_k> so 1.5mb to save a continuous stream to disk [03:36:58 CET] <furq> piping to mpv should effectively be free [03:37:02 CET] <furq> pastebin the command anyway [03:37:04 CET] <the_k> then 1.5mb to show a realtime stream so i can see it [03:37:16 CET] <furq> there's only one 1.5mbit [03:37:23 CET] <furq> it only downloads and decodes the stream once [03:37:36 CET] <the_k> then if someone else wants to view the stream... that's it.. they have to view the secondary low quality stream .. or it breaks EVERYthing [03:38:00 CET] <the_k> yes that's why this would be good... to take the input and use it twice [03:38:19 CET] <the_k> otherwise i have to connect and take a second stream off it [03:38:37 CET] <the_k> it would be good if this stupid camera's multicast mode worked but it doesn't [03:39:04 CET] <the_k> and i'm not sure if i could use ffmpeg to save that too so i'm not so worried about trying to get that working [03:40:02 CET] <furq> pastebin the command [03:40:06 CET] <the_k> sec [03:40:18 CET] <the_k> http://pastebin.com/HA8uyaZ4 [03:40:36 CET] <furq> yeah that's probably breaking because you're transcoding the stream [03:40:52 CET] <furq> add another -c copy just before -f nut [03:41:00 CET] <the_k> ok [03:41:23 CET] <the_k> [NULL @ 0000000002d900a0] Unable to find a suitable output format for 'nut' [03:41:37 CET] <the_k> nut: Invalid argument [03:41:47 CET] <furq> -c copy -f nut - [03:41:52 CET] <the_k> oh crap [03:42:40 CET] <the_k> getting lots of "max delay reaced. need to consume packet" [03:42:57 CET] <the_k> and the mpv stream stops and starts [03:43:17 CET] <the_k> RTP: missed xxxx packets [03:43:55 CET] <furq> weird [03:44:04 CET] <furq> i don't see how adding a second output would cause that if you're copying [03:44:12 CET] <the_k> well it does [03:44:13 CET] <the_k> :) [03:45:26 CET] <the_k> ah wait [03:45:49 CET] <the_k> i was copying an old command i was testing with segment_time 10 in it [03:45:57 CET] <furq> also like i said, the whole thing will drop out if mpv closes [03:45:59 CET] <the_k> now i'm back to 24hrs there [03:46:02 CET] <furq> there's no less fragile way i know of [03:46:07 CET] <the_k> and it's better but still doing the same thing [03:46:26 CET] <the_k> yeah if mpv closes that's fine.. i'd just restart it [03:46:32 CET] <the_k> it hasn't crashed on me [03:46:35 CET] <the_k> and i woudln't close it manually [03:48:12 CET] <the_k> 3rd time running and this time it's fine... [03:48:18 CET] <the_k> really stable [03:48:32 CET] <the_k> it missed 158 , then 59., then 2 packets.. then stablized [03:48:45 CET] <thebombzen> srunge.us over quoto [03:48:52 CET] <thebombzen> not sure if my fault [03:49:03 CET] <thebombzen> like if I sent too much or if it's global [03:49:20 CET] <the_k> http://pastebin.com/raw/xezD2ubh [03:50:00 CET] <faLUCE> furq: well, I got it. It works (just had to add the header at the beginning of the stream). Both mplayer and ffplay can hear the http audio stream without the mpegts problems [03:50:19 CET] <faLUCE> vlc doesn't support opus, however. [03:50:23 CET] <thebombzen> wut [03:50:30 CET] <thebombzen> >vlc doesn't support opus [03:50:33 CET] <thebombzen> ...really? [03:50:36 CET] <furq> vlc is garbage though so who cares [03:50:45 CET] <thebombzen> vlc not supporting opus is very surprising [03:50:53 CET] <thebombzen> given that it's got avcodec [03:51:06 CET] <furq> maybe it's an ancient vlc or just a wonky build [03:51:13 CET] <faLUCE> thebombzen: but I compiled it from scratch. Maybe I did not configure it when compiling [03:51:20 CET] <furq> that could also explain why it was shitting the bed because of your pcr [03:51:26 CET] <thebombzen> pcr? [03:51:41 CET] <furq> https://en.wikipedia.org/wiki/MPEG_transport_stream#PCR [03:51:42 CET] <faLUCE> furq: no, also other versions of vlc do the same thing [03:51:56 CET] <furq> vlc wasn't working for him with audio-only streams because the pcr was set incorrectly(?) [03:51:59 CET] <furq> even though it shouldn't matter [03:52:00 CET] <thebombzen> lol people here love to give vlc shit but tbh it's a lot better than anything not mplayer-based [03:52:15 CET] <the_k> furq: would it be possible to get rid of the DTS error that it takes a second to fix? it seems like to get this working it needs a kind of headstart [03:52:20 CET] <thebombzen> compare to quicktime or windows media player which most people use or realplayer or itunes or whatever [03:52:27 CET] <faLUCE> furq: a possible reason for that problem is that in each case vlc wants the STREAM header [03:52:34 CET] <thebombzen> vlc isn't really that bad in the grand scheme of things [03:52:41 CET] <furq> it's pretty bad [03:52:42 CET] <faLUCE> now I just have to check [03:52:49 CET] <thebombzen> furq: compared to what? [03:52:55 CET] <thebombzen> like compared to mpv? yea it sucks [03:52:58 CET] <furq> yup [03:53:06 CET] <thebombzen> compared to basically anything else? not rally [03:53:24 CET] <thebombzen> recall that most people use quicktime/itunes/windowsmediaplayer crap [03:53:27 CET] <furq> i'm constantly seeing "savvy" people using/recommending vlc though [03:53:36 CET] <thebombzen> well mpv is a CLI player [03:53:48 CET] <furq> even old mplayer frontends are better than vlc though [03:53:55 CET] <thebombzen> hmm [03:54:00 CET] <furq> and mpc-hc on windows [03:54:06 CET] <thebombzen> mpc-hc? never heard of it [03:54:18 CET] <thebombzen> either way the biggest issue with vlc is that I found a big bug that the devs aren't willing to fix [03:54:19 CET] <faLUCE> anyway, this ogg container seems good [03:54:22 CET] <furq> https://mpc-hc.org/ [03:54:27 CET] <faLUCE> and it's completaly open [03:54:45 CET] <furq> i've been using it for years, it's nice [03:54:51 CET] <thebombzen> ohey it's big buck bunny [03:54:58 CET] <furq> even the directshow stuff isn't a huge deal any more thanks to lav filters [03:55:00 CET] <thebombzen> I'm not gonna switch over to mpc-hc just cause I use mpv [03:55:11 CET] <thebombzen> but it's a good thing to recommend it seems [03:55:13 CET] <furq> well yeah if i hadn't been using mpc-hc for the best part of a decade i'd switch to mpv [03:55:25 CET] <furq> i'm only sticking with it because of inertia [03:55:54 CET] <furq> whenever i get rid of this godforsaken windows install i'll definitely be using mpv [03:56:38 CET] <thebombzen> I"m looking at the thirdparty libraries and I don't see avcodec or avformat, which is interesting [03:57:08 CET] <thebombzen> ah there it is [03:57:14 CET] <thebombzen> apparently LAV Filters includes more than just libavfilter [03:58:20 CET] <thebombzen> wow okay this is really greasy [03:58:39 CET] <thebombzen> I'm making beef bowl for dinner and I didn't realize 80/20 was so much fat [03:58:49 CET] <thebombzen> I mean literally 1/5 but it's all melting off like crazy [03:59:54 CET] <faLUCE> [00007f4d7cc4e168] core decoder error: Codec `Opus' (Opus Audio) is not supported . this is really sad [04:00:22 CET] <faLUCE> and there's not any opus configure flag [04:01:32 CET] <faLUCE> I'm wrong... I compiled vlc with a previous compiled version of ffmpeg without opus [04:02:47 CET] <furq> i don't know if lav filters actually includes libavfilter [04:03:22 CET] <furq> filters refers to directshow filters [04:03:30 CET] <furq> which includes decoders, because microsoft are good at naming things [04:03:36 CET] <furq> and demuxers [04:19:52 CET] <the_k> furq: would it be possible to get rid of the DTS error that it takes a second to fix? it seems like to get this working it needs a kind of headstart [04:20:12 CET] <furq> no idea [04:20:20 CET] <the_k> ok [04:20:58 CET] <the_k> and it's not possible to view it in realtime without transcoding it? [04:26:23 CET] <faLUCE> LOOOOL! I just saw that VLC says "bad PCR value" even wih a OGG http stream [04:26:56 CET] <faLUCE> they made a mess [05:52:27 CET] <mantas322> Hi guys [05:52:32 CET] <mantas322> I have a tricky question [05:53:09 CET] <mantas322> Is it possible to use FFMPEG to convert *.MTS format into GoPro Studio acceptable *.MP4??????? [05:53:13 CET] <mantas322> with audio? [06:51:19 CET] <kepstin> mantas322: if the 'mts' files are mpeg TS, and you know what formats gopro studio accepts, then probably, yes? [18:08:08 CET] <zoli> hi. with wich parameter can I downsize my original video with lowering the fps ? [18:08:46 CET] <zoli> is it -r? [18:13:31 CET] <DHE> you want -s [18:39:35 CET] <zoli> DHE: tx, what is the difference between -r and -s? [18:44:09 CET] <furq> -r is fps, -s is size [18:44:11 CET] <furq> sounds like you want both [19:23:14 CET] <DHE> or under certain interpretations a lower bitrate... do be specific [20:08:50 CET] <Franciman> Is it possible to make av_read_frame discard frames that don't belong to a given AVStream? [20:20:49 CET] <kuroro> hello, i need to cut up lots of videos into 3 second segments, currently im just using "ffmpeg -ss <time> -i input.mp4 -t <duration> -c:v libx264 -c:a libfdk_aac segment_name.mp4" multiple times (i.e. 1200 times for a 60 minute video) [20:21:09 CET] <kuroro> is there a more efficient/faster way to go about this? [20:23:19 CET] <kuroro> i.e. should i use libavcodec directly in a c program and do the splitting in memory instead of having to shell out to a new ffmpeg process each time and incur overhead of system calls. and is there a library/wrapper that already does this instead of having to write one myself [20:26:56 CET] <JEEB> there's a segment muxer somewhere in lavf [20:27:01 CET] <JEEB> never used it personally [20:27:14 CET] <JEEB> also the DASH muxer writes segments into separate files, just like the HLS one [20:30:10 CET] <furq> !muxer segment @kuroro [20:30:10 CET] <nfobot> kuroro: http://ffmpeg.org/ffmpeg-formats.html#segment_002c-stream_005fsegment_002c-… [20:35:52 CET] <kuroro> ah cool awesome. works for fixed segment durations. thanks [20:36:39 CET] <kuroro> i also have cases where segment durations are widely varied though [20:37:34 CET] <furq> you can use -segment_times for that [20:41:24 CET] <kuroro> interesting [20:58:24 CET] <thebombzen> segment muxer is the hot topic these days [21:02:08 CET] <kuroro> oh yeah haha, i guess most people are using for hls [21:02:12 CET] <kuroro> using it* [21:05:39 CET] <JEEB> there's a hls muxer for that, though? [21:07:42 CET] <DHE> even though DASH is technically the standard, HLS is popular mainly because apple pushes it [21:08:11 CET] <kuroro> oh yeah true, probably. personally i mostly want to cut videos into word segments [21:08:20 CET] <Franciman> hey, I set an AVStream discard value to AVDISCARD_ALL, but in av_read_frame I get exactly one packet from that stream. How is that possible? [21:08:21 CET] <furq> hls is popular because it works everywhere [21:08:31 CET] <furq> which i guess is because of apple pushing it [21:08:50 CET] <kuroro> yeah with iphone, ipad adopting hls, it only makes sense people are gravitating towards it [21:09:15 CET] <furq> well they've not so much adopted hls as refused to adopt dash [21:09:35 CET] <furq> desktop browsers don't support hls but you can at least hack it into working without too much fuss [21:09:41 CET] <JEEB> well they did adopt ISOBMFF in HLS [21:09:50 CET] <JEEB> so now you can at least for some modes use the same segments [21:09:58 CET] <furq> in theory at least [21:10:13 CET] <JEEB> DRM had some differences which might lead you to contain multiple versions [21:10:21 CET] <JEEB> or create them on-demand [21:10:35 CET] <JEEB> (different AES modes) [21:11:48 CET] <DHE> key distribution is a fun topic for other reasons as well. the HLS spec only specifies how to provide a URL to the key, not how to actually protect it. HTTP authentication, cookies, or something more creative? [21:12:58 CET] <JEEB> well not like fairplay follows that spec [21:13:11 CET] <JEEB> unless they let you define custom protocols and it's using one of those [21:13:36 CET] <DHE> besides http? maybe... [21:14:09 CET] <JEEB> I haven't tried fairplay yet, although some people seem to be pushing it lately... I wonder if they got it through the hollywood rights owners [21:14:20 CET] <JEEB> since I remember only seeing other vendors' names until now :P [21:17:30 CET] <thebombzen> how do you get a browser to work with HLS [21:17:33 CET] <thebombzen> Javascript magic? [21:18:19 CET] <DHE> basically. decrypt the data if needed and reassemble the stream as an MP4 for the built-in decoders [21:18:34 CET] <kerio> thebombzen: i use safari [21:18:36 CET] <kerio> U( )W [21:18:46 CET] <thebombzen> >safari [21:19:02 CET] <thebombzen> plz [21:19:11 CET] <DHE> some browsers do support HLS. yeah safari, and I know chrome mobile does. [21:19:24 CET] <thebombzen> Linux why would I use Safari [21:19:24 CET] <JEEB> MS decided to go both ways and implemented both HLS and MPEG-DASH in edge [21:19:33 CET] <thebombzen> interesting [21:19:34 CET] <JEEB> natively that is [21:19:54 CET] <thebombzen> prediction: Chrome will implement HLS, then Firefox will copy it [21:19:59 CET] <JEEB> chrome and firefox mobile most likely just pass things to the native media framework [21:20:17 CET] <thebombzen> what is the "native media framework" on Linux [21:20:20 CET] <JEEB> neither have shown any signs of implementing HLS or MPEG-DASH natively [21:20:31 CET] <JEEB> thebombzen: none. closest are either gstreamer or libav* :P [21:20:42 CET] <thebombzen> cause I don't use gstreamer and I never thought of FFmpeg as a "media framework" [21:21:07 CET] <JEEB> it isn't as simple as gstreamer, but pretty much the next thing after that :P [21:21:08 CET] <thebombzen> does avformat support hls segments with mpegts [21:21:15 CET] <kerio> hey, ffmpeg supports hls [21:21:23 CET] <JEEB> in any case, chrome and firefox only do that on mobile [21:21:36 CET] <JEEB> since HLS is most likely supported in the media framework there [21:21:36 CET] <thebombzen> cause if libavformat does then there shouldn't be any real work needed for them [21:21:37 CET] <BtbN> they don't support HLS because of license/patents on mpegts [21:21:50 CET] <thebombzen> ...really? [21:21:58 CET] <thebombzen> License/Patents on mpegts [21:22:14 CET] <thebombzen> are causing the two most used browsers to be unable to support it? [21:22:18 CET] <JEEB> more likely they feel they can just pass the parsing into JS :P [21:22:24 CET] <JEEB> like hls.js and flv.js do [21:22:31 CET] <JEEB> (it's perverse but that's how it's going) [21:22:35 CET] <thebombzen> is there any reason to use flv anymore [21:22:38 CET] <JEEB> no [21:22:48 CET] <BtbN> Because rtmp exists and is the standard [21:22:51 CET] <thebombzen> what was the purpose of flv originally [21:22:53 CET] <JEEB> other than RTMP but that isn't really a reason nowadays any more [21:23:00 CET] <thebombzen> oh RTMP yea okay [21:23:03 CET] <BtbN> rtmp is the most widely used ingest protocol [21:23:17 CET] <BtbN> And it's essentialy flv over tcp [21:23:20 CET] <thebombzen> but does FLV support modern codecs [21:23:23 CET] <thebombzen> like Opus [21:23:29 CET] <JEEB> yea. thankfully some solutions have started taking in other stuff [21:23:29 CET] <thebombzen> or are you stuck with AAC [21:23:33 CET] <furq> you're stuck with aac [21:23:37 CET] <BtbN> "stuck" [21:23:45 CET] <BtbN> AAC is fine enough, and you want good player support anyway [21:23:47 CET] <furq> i mean i guess that's a big deal for low latency, but then so is rtmp [21:23:52 CET] <thebombzen> "aac is fine enough" [21:24:00 CET] <furq> it is tbh [21:24:01 CET] <thebombzen> well given that you can't encode it without --enable-nonfree [21:24:06 CET] <furq> sure you can [21:24:18 CET] <BtbN> Just don't use libfdk [21:24:20 CET] <JEEB> that limitation was removed after atomnuker improved the encoder [21:24:22 CET] <furq> you can't encode aac-he without nonfree [21:24:26 CET] <furq> but he sucks anyway [21:24:26 CET] <JEEB> ^this [21:24:36 CET] <thebombzen> yea but the native aac encoder isn't experimental, but that doesn't mean it's anywhere as good as libopus (or libvorbis) [21:24:52 CET] <JEEB> sure, you choose your weapons depending on what you're aiming [21:25:05 CET] <JEEB> if your clients can support opus or vorbis you should look for other stuff like icecast [21:25:05 CET] <thebombzen> like libopus is good enough to be fine for most purposes at 128k [21:25:17 CET] <JEEB> and the internal AAC encoder isn't? [21:25:23 CET] <thebombzen> avcodec's aac isn't in my experiences no [21:25:25 CET] <JEEB> that would surprise me [21:25:29 CET] <furq> sounds fine to me [21:25:43 CET] <JEEB> since it was "OK" before the updates at that rate (while not being good) [21:25:53 CET] <furq> bearing in mind how much stuff is out there using 128k mp2 [21:26:06 CET] <thebombzen> that's not really an excuse [21:26:15 CET] <thebombzen> anyway the trac wiki says this: libopus > libvorbis >= libfdk_aac > aac [21:26:28 CET] <thebombzen> for Encode/HighQualityAudio [21:26:39 CET] <furq> well yeah but the wiki is often talking out of its arse [21:26:45 CET] <thebombzen> it's written by us isn't it [21:26:48 CET] <furq> cf. literally every page about streaming [21:27:06 CET] <furq> if by "us" you mean "anyone on the internet" then sure [21:27:07 CET] <JEEB> edited by someone without any data I guess? but yes, I do agree that fdk-aac most likely is in some ways better. to what extent is debatable [21:27:20 CET] <furq> i'm not necessarily saying that's wrong, but i wouldn't treat it as gospel [21:27:28 CET] <JEEB> I do agree that libvorbis and libopus are nice [21:27:36 CET] <furq> the aac page says "aac >= fdk_aac" [21:27:46 CET] <furq> so it's not even consistent within the wiki [21:27:46 CET] <thebombzen> really? lol I knew the wiki was out of date [21:27:55 CET] <thebombzen> but internally inconsistent is pretty bad [21:28:08 CET] <thebombzen> what major changes did atomnuker make to the aac encoder [21:28:16 CET] <thebombzen> it "doesn't suck anymore" but that's not really descriptive [21:28:26 CET] <JEEB> pretty much a rewrite, he gave a talk on it at VDD '15 [21:28:31 CET] <furq> well yeah the problem is that people who'd write correct information would want to base it on actual evidence [21:28:34 CET] <furq> and there isn't any yet [21:28:44 CET] <furq> so the people who are basically just making shit up get to run the show [21:28:54 CET] <furq> cf. literally every page about streaming [21:29:05 CET] <thebombzen> yea the streaming pages have been somewhat useless [21:29:06 CET] <JEEB> thebombzen: https://www.youtube.com/watch?v=QiV60eGY11o&list=PLQLpBN3oI7E44HIdTOovThc1M… [21:29:14 CET] <thebombzen> JEEB: thanks [21:29:24 CET] <thebombzen> speaking of streaming, I have a question: [21:29:45 CET] <thebombzen> I have a webcam, and I want to stream it point-to-point with UDP with very low latency [21:31:29 CET] <thebombzen> I try using: ffmpeg -probesize 32 -f v4l2 -video_size 3840x1080 -i /dev/video0 -c:v libx264 -preset:v superfast -tune:v zerolatency -crf:v 26 -x264-params intra-refresh=yes -f mpegts udp://localhost:12555 [21:31:37 CET] <thebombzen> and playing it with: [21:31:49 CET] <thebombzen> ffplay -probesize 32 -f mpegts udp://localhost:12555 [21:31:59 CET] <thebombzen> the issue is I encur significant latency doing this [21:32:03 CET] <thebombzen> the idea is sub-100ms [21:32:19 CET] <thebombzen> but for some reason this command incurs about 150 to 200ms of latency, which is weird [21:32:36 CET] <furq> don't you need to do some weird stuff with the vbv to get single-frame latency [21:32:38 CET] <thebombzen> using -avioflags +direct -fflags +nobuffer doesn't help much [21:32:42 CET] <kerio> does zerolatency enable slice-based threading [21:32:45 CET] <furq> kerio: yes [21:32:54 CET] <kerio> oh, that's why it sucks? :D [21:32:59 CET] <thebombzen> furq: not quite sure what "vbv" is [21:33:00 CET] <furq> that's the biggest reason, yeah [21:33:07 CET] <JEEB> yeah, libx264's zerolatency tune is the one thing that optimizes for latency well [21:33:14 CET] <JEEB> lavf/lavc can be a crapshoot [21:33:28 CET] <thebombzen> but I guess my question is [21:33:37 CET] <thebombzen> why does the above command not work [21:33:40 CET] <thebombzen> why is there so much latency [21:33:55 CET] <kerio> buffering in ffplay? [21:33:57 CET] <kerio> i'd use mpv [21:34:02 CET] <thebombzen> I thought that but I don't think it is [21:34:05 CET] <thebombzen> mpv didn't change anything [21:34:22 CET] <JEEB> yeah, everything lavf-based would have to be optimized [21:34:27 CET] <thebombzen> plus, if I play from the webcam with: ffplay -probesize 32 -f v4l2 -video_size 3840x1080 -i /dev/video0 [21:34:29 CET] <JEEB> including mpv [21:34:36 CET] <thebombzen> that has very low latency [21:34:43 CET] <kerio> thebombzen: mpv with -cache=no? [21:34:53 CET] <thebombzen> --cache=no? hmmm [21:35:06 CET] <kerio> that's just one thing tho [21:35:15 CET] <furq> have you tried using rtp instead of mpegts [21:36:20 CET] <thebombzen> I tried using rtp, but ffmpeg complains that I need an SDP file [21:36:38 CET] <thebombzen> the muxer spits one out on stdout, but it doesn't say anywhere how to specify it to the video player [21:36:46 CET] <faLUCE> thebombzen: don't use ffmpeg for rtsp [21:36:46 CET] <furq> > foo.sdp [21:36:59 CET] <thebombzen> furq: I didn't install this OS yesterday [21:37:11 CET] <thebombzen> "it doesn't say anywhere how to specify it to the video player" [21:37:50 CET] <c_14> mpv foo.sdp [21:38:23 CET] <thebombzen> that works? [21:38:26 CET] <thebombzen> okay [21:38:27 CET] <furq> yeah [21:39:13 CET] <faLUCE> When open a matroska stream with mp2 codec it says: "[matroska @ 0x39e2860] Codec for stream 0 does not use global headers but container format requires global headers" ... do you know anything about that? Matroska supports mp2, from what I read... [21:39:16 CET] <thebombzen> well when I try that I just get "error reading packet" [21:40:45 CET] <thebombzen> http://0x0.st/VOz.txt [21:41:03 CET] <thebombzen> that's what happens why I try RTP [21:43:02 CET] <thebombzen> Also, if I try to go over plain UDP and play it with "mpv --cache=no udp://localhost:12555" it has enormous latency [21:43:07 CET] <thebombzen> like 1000ms [21:43:41 CET] <kerio> do you really need a container tho [21:43:58 CET] <thebombzen> no, I just need the video to go over udp with low latency [21:44:26 CET] <thebombzen> but how am I supposed to be able to deal with connection dropping without an mpegts or other container [21:44:28 CET] <thebombzen> raw h264 doesn't do that [21:45:44 CET] <faLUCE> thebombzen: If I can suggest you, just leave ffmpeg for rtsp/udp stuff. You don't have any control on it. I tried it for years. Use live555 instead [21:46:15 CET] <thebombzen> I've never heard of that. can you give me some tips (or a pointer) [21:46:22 CET] <faLUCE> thebombzen: in addition, udp has nothing to do with low latency [21:46:31 CET] <thebombzen> it doesn't I know but I need UDP [21:46:54 CET] <thebombzen> or rather UDP is better than TCP for the implemenation (independent of the latency) [21:46:56 CET] <faLUCE> thebombzen: if I may ask, why would you need udp ? udp is intended for very low bw [21:47:13 CET] <faLUCE> but it has many disadvantages [21:47:20 CET] <thebombzen> the webcam is going to be mounted on a rover which is driving around terrain far away [21:47:28 CET] <thebombzen> sending video to us so we can drive it [21:47:45 CET] <faLUCE> thebombzen: ok, but I don't understand why would you choose UDP instead of tcp [21:47:46 CET] <thebombzen> that's why we need low latency. as for why udp instead of tcp? cause tcp plays less well with random connection drops [21:48:06 CET] <thebombzen> and we're prone to random connection drops [21:48:07 CET] <faLUCE> thebombzen: really not. Rtp has an internal mechanism for avoiding that [21:48:15 CET] <thebombzen> if that's true then sure [21:48:28 CET] <faLUCE> UDP is only used when you want to reduce bw [21:48:32 CET] <thebombzen> My requirements are the latency has to be very low and it has to be resilient to connection dropping [21:48:40 CET] <thebombzen> but that's about it [21:48:45 CET] <thebombzen> anything else is really my choice [21:49:09 CET] <faLUCE> thebombzen: you have to do that: before experimenting latency with RTP/RTSP you have to be sure that all the stuff works [21:49:14 CET] <faLUCE> and you can't do that with ffmpeg [21:49:22 CET] <thebombzen> although I've never used rtsp or live555 before so is there some sort of tutorial [21:49:23 CET] <faLUCE> thebombzen: http://live555.com/ [21:49:28 CET] <thebombzen> I looked at that [21:49:43 CET] <faLUCE> thebombzen: it's very easy to use and well documented [21:49:48 CET] <kerio> does dvb-s/dvb-t use mpegts? [21:50:03 CET] <JEEB> pretty much all broadcast does [21:50:03 CET] <thebombzen> I'm looking at the website and I don't know where to begin [21:50:20 CET] <faLUCE> thebombzen: well. it's easy. Start with the examples [21:50:32 CET] <faLUCE> there's an example for streaming raw h264 data [21:50:42 CET] <thebombzen> there is no example on the page [21:50:46 CET] <faLUCE> thebombzen: wait [21:51:16 CET] <faLUCE> thebombzen: http://live555.com/liveMedia/faq.html#liveInput [21:51:19 CET] <thebombzen> I believe you that it's really easy and well-documented but the homepage is not really that helpful [21:51:40 CET] <faLUCE> thebombzen: you have to code in C++, though. [21:51:55 CET] <thebombzen> >_> [21:52:02 CET] <thebombzen> can I just tell it to read from /dev/stdin [21:52:14 CET] <faLUCE> yes [21:52:19 CET] <thebombzen> excellent [21:52:23 CET] <faLUCE> no, sorry [21:52:26 CET] <thebombzen> :( [21:52:28 CET] <faLUCE> no /dev/stdin [21:52:34 CET] <faLUCE> but you can make a pipe [21:52:52 CET] <thebombzen> "Even simpler, if your operating system represents the encoder device as a file, then you can just use the name of this file (instead of "test.*").)" [21:53:04 CET] <thebombzen> that sounds remarkably like telling it to read from /dev/stdin and then piping x264 [21:53:06 CET] <faLUCE> thebombzen: yes, because it's event looped [21:53:14 CET] <thebombzen> uh [21:53:19 CET] <faLUCE> thebombzen: exactly, what I said. Make a pipe [21:53:32 CET] <thebombzen> well yea that's clearly part of /dev/stdin [21:53:34 CET] <faLUCE> but anyway, explain better what you are doing [21:53:38 CET] <thebombzen> if I want to be clever I could use process substitution [21:53:46 CET] <thebombzen> but not necessary [21:53:54 CET] <faLUCE> do you have to read h264 frames from a device-encoder ? [21:54:22 CET] <thebombzen> um [21:54:33 CET] <faLUCE> or do you encode locally the frames? [21:54:42 CET] <thebombzen> well the webcam spits out yuyv422 frames [21:54:46 CET] <thebombzen> I have to encode them on the fly [21:55:02 CET] <faLUCE> ok, then you use x264, right? [21:55:08 CET] <thebombzen> yea [21:55:13 CET] <faLUCE> ok, wait [21:55:19 CET] <thebombzen> I'm still really not sure what to do [21:55:34 CET] <thebombzen> you say "it's well documented" but it appears that it's only well documented for someone who already knows what they're doing with it [21:55:43 CET] <faLUCE> thebombzen: [21:55:46 CET] <faLUCE> "Alternatively, if your encoder presents you with a sequence of frames (or 'NAL units'), rather than a sequence of bytes, then a more efficient solution would be to write your own "FramedSource" subclass that encapsulates your encoder, and delivers audio or video frames directly to the appropriate "*RTPSink" object" [21:56:02 CET] <faLUCE> this is what you have to do [21:56:12 CET] <thebombzen> wait so live555 has no reference CLI tools? [21:56:15 CET] <thebombzen> I have to write my own? [21:56:36 CET] <faLUCE> thebombzen: you have to make a subclass, and rewrite a method. few lines of code [21:56:43 CET] <thebombzen> don't know C++ [21:56:52 CET] <thebombzen> I feel like "v4l2 -> x264 -> stream" has go to be so common that someone has done it before [21:56:57 CET] <thebombzen> this just feels like reinventing the wheel [21:56:59 CET] <faLUCE> thebombzen: then, believe me, just avoid rtsp/rtp [21:57:20 CET] <thebombzen> well then what should I use lol [21:57:25 CET] <faLUCE> thebombzen: currently there's only support with c++ for rtsp/rtp [21:57:38 CET] <faLUCE> thebombzen: there are other libs, in C, but they are not good [21:57:49 CET] <thebombzen> I don't know C either. you're missing the point [21:58:14 CET] <thebombzen> I'm not looking for a LIBRARY I'm looking for an APPLICATION [21:58:21 CET] <faLUCE> thebombzen: if you don't know C, how can you gat separate frames? [21:58:22 CET] <thebombzen> ffmpeg.c does exactly what I need but it's too slow [21:58:24 CET] <faLUCE> get [21:58:34 CET] <thebombzen> I have no idea what you're talking about [21:58:44 CET] <thebombzen> I'm trying to stream from a webcam point to point with ultra-low latency [21:58:48 CET] <thebombzen> why do I need to get "separate frames" [21:59:00 CET] <faLUCE> thebombzen: you said that you use x264 for encoding [21:59:19 CET] <faLUCE> well, x264 takes a planar image and encodes it [21:59:37 CET] <faLUCE> but if you don't code, how do you split the encoded stream into frames? [21:59:43 CET] <thebombzen> I don't [21:59:45 CET] <thebombzen> my video player does [21:59:55 CET] <thebombzen> when I stream the h264 stream, I don't decode it [22:00:01 CET] <faLUCE> thebombzen: then you can't control params like low latency and similar things [22:00:09 CET] <thebombzen> um [22:00:13 CET] <faLUCE> unless you are very lucky [22:00:22 CET] <thebombzen> I'm really confused [22:00:49 CET] <faLUCE> thebombzen: in order to control the latency, you have to manage lot of different buffers [22:01:08 CET] <thebombzen> the idea is to take the v4l2 yuyv422 input, encode it with x264, stream the h.264 stream point-to-point over the network, decode, it and display it [22:01:12 CET] <thebombzen> this really isn't that hard [22:01:12 CET] <faLUCE> the v4l buffer, the x264 buffer, the network buffers (input/output) [22:01:20 CET] <thebombzen> the latency doesn't have to be perfectly exact [22:01:22 CET] <thebombzen> it just has to be very low [22:01:33 CET] <thebombzen> I don't care if it's 20ms or 18ms or 35ms or whatever [22:01:34 CET] <thebombzen> that's not important [22:01:42 CET] <faLUCE> thebombzen: ok, even if it has to be low, you have to control many buffers [22:01:49 CET] <faLUCE> now, you have two choices: [22:01:57 CET] <thebombzen> only if the CLI TOOLS DON'T ALREADY CONTROL THOSE BUFFERS WHICH IS WHAT I'M ASKING [22:02:00 CET] <thebombzen> why is this so hard [22:02:15 CET] <faLUCE> 1) control the buffers of the programs run by CLI (---> set them with arguments) [22:02:21 CET] <thebombzen> YES THAT WAS THE QUESTIN [22:02:23 CET] <faLUCE> 2) control the buffers in the code [22:02:23 CET] <thebombzen> HOW DO I DO THAT [22:02:34 CET] <faLUCE> thebombzen: be calm, I'm trying to explain [22:02:43 CET] <thebombzen> you're really not listening [22:02:53 CET] <faLUCE> if your choice is 1), it's not easy [22:02:59 CET] <thebombzen> everything you've said about controlling buffers is something I know about [22:03:09 CET] <thebombzen> the question is "how do I make it so these CLI tools don't have such a high latency" [22:03:11 CET] <thebombzen> which is the question [22:03:19 CET] <furq> but what's the question [22:03:21 CET] <faLUCE> thebombzen: I'm trying to answer, be calm [22:03:34 CET] <faLUCE> these buffers are HARD to control with CLI [22:03:43 CET] <thebombzen> I already asked it [22:04:15 CET] <thebombzen> I'm trying to stream point-to-point very low latency, but when I try using the ffmpeg tools there is a significant latency incurred [22:04:23 CET] <thebombzen> what do I do to fix this [22:04:28 CET] <faLUCE> thebombzen: I know that, I'm explaining what [22:04:31 CET] <faLUCE> why [22:04:36 CET] <thebombzen> I know why [22:04:40 CET] <thebombzen> the question is how do I not do that [22:04:44 CET] <thebombzen> I know there's internal buffers [22:04:57 CET] <thebombzen> I tried using -fflags +nobuffer and -avioflags +direct and -probesize 32 and stuff [22:05:06 CET] <thebombzen> none of them helped much [22:05:20 CET] <thebombzen> if the answer is "don't use ffmpeg.c" then what CLI tool should I be using for this [22:05:25 CET] <faLUCE> thebombzen: if you know ALL the buffers, and you know how to set them with CLI then... you should do all what you want. but I'm sure you DON't know all the buffers [22:05:27 CET] <thebombzen> this is all stuff I've said above [22:05:44 CET] <thebombzen> well knowing that ffmpeg has internal buffers doesn't necessarily mean I no how to disable them [22:06:14 CET] <faLUCE> thebombzen: you need to control them [22:06:19 CET] <thebombzen> well obviously [22:06:23 CET] <thebombzen> that's sort of the whole point [22:06:28 CET] <faLUCE> for example: do you know how to control the v4l buffer? [22:06:38 CET] <faLUCE> do you know how to control the tcp buffer? [22:06:55 CET] <faLUCE> if you want to control them with CLI::.. IT'S HARD [22:06:56 CET] <thebombzen> no, but the v4l buffer is not the bottleneck [22:06:59 CET] <JEEB> in any case, lavf and lavc have plenty of buffer points and I'm not sure if anyone here has correctly noted how to minimize all of them [22:07:16 CET] <thebombzen> JEEB: if it can't be done with lavf/lavc what should I use instead [22:07:19 CET] <BtbN> disabling buffers usually leads to a very bad experience overall [22:07:19 CET] <JEEB> you most likely can do it, but if someone has done that already properly it's not documented [22:07:22 CET] <BtbN> They exist for a reason [22:07:29 CET] <JEEB> thebombzen: not saying it can't be done [22:07:33 CET] <faLUCE> the only way to minimize is doing that through software, for a specific video device [22:07:38 CET] <JEEB> it's just that the defaults are not aimed for it and thus you have to go through things :P [22:07:50 CET] <thebombzen> well yes I know that [22:07:54 CET] <thebombzen> what are those things I must go through [22:08:03 CET] <thebombzen> sub-100ms point-to-point really doesn't sound like something that nobody has figured out how to do [22:08:07 CET] <JEEB> that's the thing, you only start looking into that when you try to optimize for that use case [22:08:16 CET] <JEEB> and nobody seems to have documented that :P [22:08:16 CET] <furq> thebombzen: http://archive.is/gUP7m [22:08:19 CET] <faLUCE> thebombzen: anyway, vlc has better control of the buffers than ffmpeg [22:08:28 CET] <furq> that doesn't deal with the libav* or v4l buffers but it might help [22:08:31 CET] <faLUCE> thebombzen: start with vlc before [22:08:39 CET] <thebombzen> lol recommending vlc [22:08:44 CET] <thebombzen> no I get you [22:08:49 CET] <furq> http://vpaste.net/gEvjj [22:08:51 CET] <thebombzen> I just find it funny since people spend so much time her trashing vlc [22:08:52 CET] <furq> specifically that bit of comment 8 [22:08:56 CET] <JEEB> basically the only thing I know is that libx264 (the library) is very good with the zerolatency tuning, but that's thus the simplest part of the equation [22:09:07 CET] <faLUCE> thebombzen: I'm not recommending vlc. I'm saying that in the vlc interface you can see easily all the WORKING options [22:09:21 CET] <faLUCE> JEEB: zerolatency is not enough [22:09:24 CET] <faLUCE> it's a minimal part [22:09:32 CET] <furq> he just said that [22:09:34 CET] <faLUCE> the main problem is the receiver's buffer [22:09:38 CET] <JEEB> well yes [22:09:56 CET] <JEEB> "but that's thus the simplest part of the equation" [22:10:02 CET] <faLUCE> anyway, don't do that with CLI. [22:10:15 CET] <JEEB> because it's the one component that is known to have simply usable low latency parameters :P [22:11:06 CET] <faLUCE> in addition: NEVER use ffmpeg as rtp streamer [22:11:12 CET] <furq> thebombzen: packet size is ?pkt_size= in the udp muxer, which iirc you want to set to your router's MTU [22:11:29 CET] <furq> s/muxer/protocl [22:11:35 CET] <faLUCE> never use UDP as well, except if you well know what you are doing [22:11:37 CET] <furq> there's also a buffer_size option in there you'll want to check [22:12:08 CET] <furq> also i am aware this isn't necessarily the answer, but it's easier to check this stuff than learn C [22:12:34 CET] <faLUCE> furq: in the receiver there are at least 4 different buffers [22:12:40 CET] <furq> yes there are [22:12:53 CET] <faLUCE> furq: if you sum them to at least 8 buffer of the sender.... [22:13:06 CET] <faLUCE> you can understand that with CLI it's almost impossible to control the latency [22:13:16 CET] <furq> probably! [22:13:24 CET] <furq> i guess we'll find out shortly [22:14:01 CET] <faLUCE> furq: good luck :-) [22:14:12 CET] <furq> i'm not the one who needs luck, i'm not doing anything [22:14:28 CET] <furq> i'm just sat here laughing at irc, and that's already going extremely well [22:14:53 CET] <faLUCE> [22:13] <furq> i guess we'll find out shortly [22:19:08 CET] <thebombzen> are x264 units in kbps or in bps [22:19:31 CET] <furq> bits iirc [22:19:37 CET] <JEEB> lavc works in bps [22:19:40 CET] <JEEB> libx264 works in kbpx [22:19:42 CET] <JEEB> *kbps [22:19:50 CET] <JEEB> thus if you work with the lavc libx264 wrapper that takes in bps [22:19:51 CET] <thebombzen> what about -x264-params and ffmpeg.c [22:19:53 CET] <furq> maxrate and bufsize are ffmpeg options though, so those should be bps [22:20:00 CET] <JEEB> -x264-params goes straight into libx264 [22:20:10 CET] <thebombzen> I'm using -x264-params vbv-bufsize [22:20:13 CET] <thebombzen> should I not do that? [22:20:17 CET] <furq> shrug [22:20:24 CET] <furq> i'm just reading this off a blog post [22:20:26 CET] <JEEB> it's OK to use it, but -maxrate and -bufsize are mapped to those [22:20:57 CET] <JEEB> -maxrate and -bufsize utilize bits per sec, and -x264-params's vbv-bufsize is in kbps because that one gets passed into libx264 API as-is [22:21:03 CET] <JEEB> (that's what the option is for) [22:21:12 CET] <furq> apparently slice-max-size is in bytes [22:21:34 CET] <JEEB> sounds feasible [22:21:35 CET] <furq> i guess that makes sense since packet size is in bytes as well [22:21:38 CET] <JEEB> yea [22:21:39 CET] <thebombzen> so the latency isn't gone [22:22:11 CET] <thebombzen> these are the encoder options -c:v libx264 -preset:v superfast -x264-params slice-max-size=4096:vbv-maxrate=10000000:vbv-bufsize=166667:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555 [22:22:12 CET] <furq> i'd probably doublecheck all the x264 options with x264 --fullhelp [22:22:28 CET] <thebombzen> but either way [22:22:34 CET] <faLUCE> thebombzen: hint: modify keyint. the player waits for a reference frame, before it displays something. [22:22:45 CET] <thebombzen> I don't care about startup delay [22:22:49 CET] <thebombzen> I just care about latency [22:22:55 CET] <furq> slice-max-size should be the same value as udp://0.0.0.0:12345/?pkt_size= [22:23:04 CET] <furq> and iirc that should probably be 1488 or whatever your router MTU is [22:23:08 CET] <kerio> faLUCE: we have no i-frames here [22:23:09 CET] <thebombzen> well I'm localhost [22:23:22 CET] <furq> you want this to go over th enetwork eventually though don't you [22:23:24 CET] <thebombzen> testing on localhost that is [22:23:31 CET] <thebombzen> so I just set some artificial parameters there [22:23:34 CET] <furq> either way i think you need to set the packet size to the same thing [22:23:37 CET] <faLUCE> kerio: there are reference frames, though [22:24:41 CET] <thebombzen> faLUCE: progressive intra refresh [22:24:57 CET] <furq> thebombzen: and yeah vbv-maxrate in x264-params is in kbps, not bps [22:25:10 CET] <thebombzen> oh hmm [22:25:11 CET] <furq> so i'm guessing 10 million is a bit too high [22:25:16 CET] <thebombzen> lol [22:25:18 CET] <thebombzen> it's crf [22:25:20 CET] <thebombzen> so that's just no maxrate [22:25:40 CET] <thebombzen> same with vbv bufsize? [22:25:44 CET] <furq> bufsize is kbit as well yeah [22:25:53 CET] <kerio> i thought the whole point of that whole low latency h264 thing was to have a constant size [22:26:01 CET] <JEEB> no [22:26:09 CET] <JEEB> the whole point was low latency [22:26:12 CET] <kerio> yeah ok but [22:26:20 CET] <JEEB> constant size is a separate requirement for specific use cases [22:26:38 CET] <thebombzen> just tested with this: -c:v libx264 -preset:v superfast -x264-params slice-max-size=4096:vbv-maxrate=10000000:vbv-bufsize=166667:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555 [22:26:39 CET] <furq> the point is that the maximum frame size is the same as the buffer size [22:26:47 CET] <thebombzen> wait where did it go [22:26:53 CET] <thebombzen> ah there it is [22:26:54 CET] <thebombzen> -c:v libx264 -preset:v superfast -x264-params slice-max-size=512:vbv-maxrate=10000:vbv-bufsize=166:intra-refresh=yes -crf 26 -tune zerolatency -f mpegts udp://127.0.0.1:12555?pkt_size=512 [22:26:55 CET] <thebombzen> this [22:27:16 CET] <furq> did it help at all [22:27:19 CET] <thebombzen> not really [22:27:33 CET] <thebombzen> I played it with: ffplay -probesize 32 -f mpegts -i udp://127.0.0.1:12555 [22:27:40 CET] <JEEB> &21 [22:27:42 CET] <thebombzen> I don't think it's a player buffer because if I just ffplay the input [22:27:47 CET] <thebombzen> it works fine [22:27:51 CET] <thebombzen> as in very low latency [22:28:02 CET] <faLUCE> thebombzen: you will do lot of tests, but at the end you will have to fight with the receiver's delay [22:28:11 CET] <faLUCE> beware of wasting time [22:28:15 CET] <thebombzen> >the receiver's delay [22:28:22 CET] <thebombzen> do you mean me? I'm the receiver [22:28:29 CET] <thebombzen> I have access to both ends [22:28:35 CET] <furq> he means the player [22:28:37 CET] <faLUCE> thebombzen: I mean the player [22:28:40 CET] <furq> see [22:28:42 CET] <thebombzen> well the player isn't hte bottleneck [22:28:48 CET] <thebombzen> which is literally what I just said [22:28:57 CET] <faLUCE> thebombzen: the player is the main problem in those things [22:29:05 CET] <furq> in fairness you don't know if it buffers udp differently from v4l [22:29:07 CET] <thebombzen> well I literally just said it isn't [22:29:14 CET] <thebombzen> but whatever [22:29:25 CET] <furq> i'd be more concerned about the muxer delay though [22:29:25 CET] <thebombzen> "the player is the main problem" [22:29:27 CET] <faLUCE> thebombzen: then, good luck to you too [22:29:34 CET] <thebombzen> clearly I'm trying to fix something else [22:30:44 CET] <thebombzen> I tried using a different client like VLC [22:30:50 CET] <thebombzen> it doesn't even like the udp stream [22:31:25 CET] <furq> there are a bunch of udp options you can try messing with fwiw [22:31:28 CET] <furq> https://ffmpeg.org/ffmpeg-protocols.html#udp [22:32:08 CET] <furq> i doubt a 64KB buffer size is going to have an impact on a 10mbit stream though [22:34:05 CET] <thebombzen> oh wow lots of decoder errors [22:36:48 CET] <thebombzen> https://i.imgur.com/z209VFI.png [22:36:59 CET] <kerio> that's not errors [22:37:00 CET] <thebombzen> that's what I get by setting the buffer_size and fifo_size [22:37:02 CET] <kerio> that's glitch art [22:37:19 CET] <kerio> https://www.reddit.com/r/glitch_art/ [22:37:54 CET] <thebombzen> Okay. [22:38:05 CET] <furq> i'm sure that's adequate consolation [22:45:46 CET] <thebombzen> you're right that ffplay might buffer differently for v4l2 than udp [22:45:52 CET] <thebombzen> so I'm going to try a different client (vlc) [22:46:00 CET] <thebombzen> mpv appears to make everything worse for some reason [22:51:13 CET] <thebombzen> >attempt to build from git master [22:51:16 CET] <thebombzen> -Werror [22:51:19 CET] <thebombzen> really dude [22:52:46 CET] <thebombzen> to those of you who use -Werror you just make it impossible to compile your stuff [22:54:06 CET] <JEEB> what version of waf are you using? [22:54:20 CET] <JEEB> I'm pretty sure the one that mpv uses in its repo isn't doing Werror [22:54:22 CET] <thebombzen> not mpv [22:54:23 CET] <thebombzen> vlc [22:54:25 CET] <JEEB> ok [22:54:29 CET] <thebombzen> mpv compiles fine for me [22:54:32 CET] <DHE> -Werror isn't a good idea for other reasons. gcc warnings vary by version [22:54:38 CET] <thebombzen> yea that's why I hate it [22:55:08 CET] <thebombzen> people who use -Werror just make it so anyone with a different version might randomly not compile [22:55:12 CET] <JEEB> for development it's "passable", but anything released should be buildable without it :) [22:55:22 CET] <thebombzen> well to be fair it's git master [22:55:44 CET] <thebombzen> ah well I found out why [22:55:51 CET] <JEEB> kind of surprised Werror would be used though, since I would guess FFmpeg linking/headers would cause a lot of warnings :P [22:55:51 CET] <thebombzen> it was -Werror=implicit-function-declaration [22:55:54 CET] <JEEB> or at least some [22:56:02 CET] <thebombzen> which really should be an error in the first place [22:56:08 CET] <JEEB> yea [22:56:21 CET] <JEEB> and yes, as I remember building VLC it didn't have a full Werror [22:56:32 CET] <JEEB> would have been surprised if j-b or remi had added it [22:57:09 CET] <thebombzen> ah so apparently luaL_checkint -> luaL_checkinteger [22:57:17 CET] <thebombzen> and the vlc devs didn't get the memo [22:57:36 CET] <JEEB> lua 5.2 => 5.3? [22:57:42 CET] <JEEB> 5.3 isn't used by many projects [22:57:46 CET] <JEEB> due to all the changes [22:58:11 CET] <thebombzen> yea I have 5.3 installed [22:58:43 CET] <furq> are you on one of those distros that thinks only packaging lua 5.3 is good because it's the latest [22:58:45 CET] <JEEB> I'd guess mpv specifically checks for older than 5.3 and doesn't enable it [22:58:53 CET] <JEEB> and thus no failures there [22:58:58 CET] <JEEB> since IIRC 5.3 support never went in [22:59:01 CET] <thebombzen> wait so I have 5.1, 5.2 and 5.3 installed [22:59:07 CET] <JEEB> ah [22:59:09 CET] <thebombzen> but VLC doesn't like htat [22:59:20 CET] <JEEB> the pc file for which do you have? [22:59:25 CET] <furq> doesn't vlc still use 5.1 [22:59:32 CET] <JEEB> you can use 5.1 or 5.2 I would guess [22:59:35 CET] <furq> if this is a debian-alike then the lua pcs should be versioned [22:59:39 CET] <JEEB> 5.3 is where a lot of changes happened [22:59:49 CET] <furq> although maybe update-alternatives is doing something funky [23:00:08 CET] <thebombzen> update-alternatives? [23:00:19 CET] <thebombzen> okay so apparently I only had one random library that depended on lua5.3 [23:00:21 CET] <furq> the debian thing which manages symlinks for multiple package versions [23:00:29 CET] <thebombzen> so I just ran pacman -Rcs lua [23:00:32 CET] <furq> oh it's arch [23:00:33 CET] <furq> nvm then [23:00:33 CET] <thebombzen> and let's hope it works [23:00:51 CET] <thebombzen> well now it says it can't find lua [23:00:55 CET] <thebombzen> ;p [23:01:40 CET] <furq> i'm pretty sure you need 5.1 fwiw [23:02:16 CET] <thebombzen> checking for LUA... no [23:02:16 CET] <thebombzen> configure: WARNING: No package 'lua5.2' found, trying lua 5.1 instead [23:02:26 CET] <furq> https://www.videolan.org/developers/vlc/share/lua/README.txt [23:02:29 CET] <furq> maybe this is out of date though [23:02:40 CET] <furq> also "LUA" nice work [23:03:27 CET] <thebombzen> ah that's because it's lua52.pc [23:03:31 CET] <thebombzen> not lua5.2.pc [23:03:40 CET] <JEEB> the file name doesn't matter [23:03:44 CET] <JEEB> it's the package name in the pc file [23:04:28 CET] <furq> idk how people using lua are still unaware that's an issue [23:04:44 CET] <furq> the pc files are named differently on every distro and every other weekday [23:05:56 CET] <thebombzen> you say it doesn't matter [23:06:02 CET] <thebombzen> but my symbolic link begs to disagree [23:06:09 CET] <furq> i think either works [23:06:14 CET] <JEEB> well, then I misunderstood how pkg-config works :P [23:06:20 CET] <JEEB> because it has the package name and version there [23:06:49 CET] <thebombzen> http://0x0.st/VOG.pc [23:07:01 CET] <thebombzen> does it? [23:07:03 CET] <furq> what [23:07:16 CET] <furq> why would they call it lua52.pc when the libname is lua5.2 [23:07:21 CET] <furq> oh wait it's because arch sucks [23:07:29 CET] <thebombzen> why is this arch's problem [23:07:38 CET] <furq> because they're the ones who made the pc [23:07:43 CET] <thebombzen> the maintainer did [23:07:45 CET] <thebombzen> not the distro [23:07:51 CET] <furq> the distro picks the maintainers [23:08:06 CET] <furq> the maintainer does definitely suck though [23:08:20 CET] <thebombzen> well debain sucks because of the FFmpeg maintainer right [23:08:22 CET] <thebombzen> ohwait [23:08:29 CET] <furq> not any more [23:08:56 CET] <furq> anyway at least it's not every rpm distro which only packages lua 5.3 because "it's the latest" [23:09:32 CET] <thebombzen> well arch generally only packages "the latest" [23:09:38 CET] <thebombzen> but they have old version #ed packages [23:09:42 CET] <thebombzen> like python and python2 [23:09:45 CET] <thebombzen> or lua and lua52 and lua51 [23:10:12 CET] <furq> well yeah most distros do that but they're capable of knowing when to make an exception [23:11:15 CET] <furq> anyway lua is pretty cool. i like it [23:11:55 CET] <thebombzen> except when I get a "version mismatch in a precompiled chunk" [23:11:56 CET] <thebombzen> um [23:12:01 CET] <thebombzen> I only ahve one version of lua installed [23:12:18 CET] <furq> you'll be needing 5.1 then [23:12:37 CET] <furq> that's fucking dumb if that's the issue and vlc's autoconf shit checks for 5.2 [23:12:57 CET] <furq> but yeah if they have precompiled bytecode for 5.1 then you can't run that with 5.2 [23:13:27 CET] <BtbN> lua also breaks its API with every release [23:13:31 CET] <furq> i don't know why they would precompile bytecode and then not do an explicit version check at build time, but that's their problem [23:14:08 CET] <gurki> im a bit confused. ffmpeg tells me that it "failed to load the nvenc library". strace tells me its looking for some libnvidia-encode.so. i guesstimate its referring to what can be built using the nvenc sdk. building said sdk fails at the step "cannot find -lnvidia-encode" - which is kind of correct, as i do not have such a library in my cuda 7.5 installation. [23:14:34 CET] <gurki> the thing i actually wnt to do is encode h264 using a nvidia gpu [23:14:37 CET] <gurki> any ideas? [23:14:38 CET] <BtbN> The library comes from the nvidia driver, the CUDA SDK is not needed at all. [23:15:05 CET] <thebombzen> interestingly, if I try to play the UDP stream with ffplay, it's okay-ish [23:15:09 CET] <thebombzen> VLC won't play it at all [23:15:14 CET] <gurki> assuming i cannot make changes to the driver as i do not have root on that system ... [23:15:52 CET] <BtbN> if the driver isn't installed properly, you obviously can't use it. [23:16:39 CET] <gurki> i kind of fail to understand how encoding stuff is a driver-related thing Oo [23:16:40 CET] <furq> thebombzen: like i was saying, vlc sucks [23:17:04 CET] <BtbN> How would it _not_ be driver related? It's using encoding hardware on the card, so of course it needs a driver. [23:17:10 CET] <furq> gurki: it's a hardware encoder. you need drivers to access the hardware [23:17:15 CET] <furq> like with most hardware [23:17:26 CET] <gurki> ah. i kind of thought it d do some cuda-stuff [23:17:32 CET] <gurki> makes sense in that case [23:17:34 CET] <BtbN> CUDA also needs a driver. [23:17:39 CET] <furq> yeah [23:17:46 CET] <furq> it's not cuda though, it's a separate asic [23:17:49 CET] <gurki> cuda works. hence my hope for it being some cuda stuff ;) [23:17:50 CET] <furq> it doesn't use the actual gpu at all [23:18:12 CET] <BtbN> it uses it to copy around frames and packets [23:18:28 CET] <furq> it doesn't use the actual gpu very much [23:18:30 CET] <BtbN> If CUDA works and nvenc doesn't, I'd guess you are using an ancient nvidia driver. [23:18:43 CET] <gurki> 375.20 to be precise [23:18:53 CET] <BtbN> that's more than recent enough, it's not installed properly then. [23:19:07 CET] <furq> are you sure your card has nvenc [23:19:13 CET] <gurki> its a gtx 1050 [23:19:21 CET] <BtbN> it's not even finding the library [23:19:45 CET] <BtbN> Have you tried latest ffmpeg master? [23:21:33 CET] <gurki> no i havent as nvidia told me to use some specific commit version and apply some specific patch. [23:21:39 CET] <gurki> will try using master [23:21:41 CET] <gurki> gimme a sec [23:22:40 CET] <thebombzen> Figures. [23:22:44 CET] <thebombzen> x264 requires 10bit input [23:22:54 CET] <BtbN> what? No it doesn't. [23:23:44 CET] <thebombzen> my build does [23:23:46 CET] <thebombzen> I have to recompile it [23:25:09 CET] <DHE> 8-bit is the default... [23:25:18 CET] <DHE> you have to go out of your way to get the 10-bit version [23:28:00 CET] <gurki> BtbN: sadly, no difference :( [23:28:49 CET] <gurki> oh. i thought the problem has been clear. pasting ... [23:29:50 CET] <BtbN> Well, I'm like 90% sure your driver is not installed correctly. [23:30:24 CET] <DHE> there's been updates to nvenv that are not backwards compatible. even a 1 year old version of the nvidia driver won't work anymore [23:30:38 CET] <DHE> (much to my own dismay) [23:30:42 CET] <BtbN> The driver is super recent. [23:30:47 CET] <BtbN> It's not even finding the .so [23:30:56 CET] <BtbN> Just search your system for libnvidia-encode.so.1, if it doesn't exist or isn't in a standard location, the driver is not installed properly. [23:30:59 CET] <gurki> http://pastebin.com/UMgPEbrk [23:31:11 CET] <BtbN> "Cannot load libnvidia-encode.so.1" [23:31:14 CET] <BtbN> yeah [23:31:22 CET] <gurki> ya thats been my very first message in this # [23:31:42 CET] <BtbN> no, that was without the .1 [23:32:02 CET] <gurki> my bad. [23:32:12 CET] <BtbN> And I suspected some distributor to remove the plain .so symlink, and latest master checks the correct one [23:32:35 CET] <BtbN> But yeah, your driver is not installed properly. [23:33:18 CET] <gurki> is there a way to get this a bit more specific? admins are gonna smash my head for telling them "something is not installed properly" ^^ [23:33:25 CET] <gurki> yes i know, lib x is missing [23:33:27 CET] <gurki> apart from that? [23:33:35 CET] <BtbN> that's pretty much it [23:33:37 CET] <gurki> (is it worth trying cuda stuff?) [23:33:38 CET] <BtbN> you need that library [23:33:42 CET] <BtbN> cuda stuff? [23:33:49 CET] <gurki> encoding using cuda, and not that asic [23:34:02 CET] <BtbN> You'll have to write a CUDA based encoder for that first. [23:34:05 CET] <DHE> the ASIC API involves going around CUDA. you need both [23:34:07 CET] <BtbN> And GPUs are bad at encoding videos. [23:34:15 CET] <BtbN> You don't want to use them for it. [23:35:04 CET] <BtbN> The nvidia-encode library is a standard part of the nvidia drivers for a while now. And for you it's plain missing, or not in the right location. [23:35:19 CET] <CoJaBo> Depends on the usecase; if you need realtime, you can't beat GPU-accel :P [23:35:23 CET] <BtbN> You can search for it, and adjust LD_LIBRARY_PATH if it's in some obscure location. [23:35:36 CET] <BtbN> CoJaBo, it's not GPU-accel, it's a dedicated ASIC [23:35:47 CET] <BtbN> GPUs are not well suited for video de/encoding workloads. [23:36:08 CET] <DHE> if you NEED realtime and minimal CPU pentalty, sure. if quality matters, use x264 [23:42:14 CET] <thebombzen> DHE: well yes [23:42:18 CET] <thebombzen> I had a 10bit version compiled [00:00:00 CET] --- Mon Jan 30 2017

1 0

ffmpeg-devel.log.20170128
by burek 29 Jan '17

29 Jan '17

[01:27:36 CET] <rcombs> saw I was highlighted in #ffmpeg; before I even tabbed to it I went "this is spam, isn't it" [02:53:24 CET] <cone-555> ffmpeg 03Aaron Colwell 07master:b9f2f9326154: mov: Fix spherical metadata_source parsing [12:29:46 CET] <wm4> is there any reason why mov.c supports reading spherical metadata but not HDR metadata? is the latter even defined for mp4? [12:30:20 CET] <JEEB> for VP9 in ISOBMFF? [12:30:28 CET] <JEEB> or shit like JPEG2000? [12:30:39 CET] <JEEB> in any case, I don't remember seeing any spec for ISOBMFF for it [12:32:08 CET] <wm4> not sure if it has to be codec-dependent [12:32:26 CET] <wm4> in mkv it doesn't have anything to do with the codec [12:32:34 CET] <JEEB> well those are the two things that come up with not having that in-stream [12:32:42 CET] <JEEB> but yes, I meant general colorspace stuff [12:32:51 CET] <JEEB> I think ISOBMFF did inherit some colorspace stuff from MOV [12:34:56 CET] <ritsuka> ISOBMFF has got the nclx box [12:36:52 CET] <JEEB> you mean colr box which then has colour type 'nclx'. which seems to contain the stuff that you used to have in AVC and HEVC in the bit stream [12:37:03 CET] <JEEB> except for the ICC profiles in case of rICC and prof [12:37:20 CET] <ritsuka> yep [12:37:31 CET] <JEEB> so in theory that could be extended, but I don't see it in 14496-12:2015 [12:37:48 CET] <JEEB> so the HDR stuff is not in there at least [12:38:24 CET] <JEEB> other than you being able to set stuff like BT.2020 I guess [12:38:38 CET] <JEEB> primaries, transfer, matrix [12:38:44 CET] <ritsuka> HDR has got its own transfer characteristics [12:38:47 CET] <JEEB> I guess you can set SMPTE ST.2084 there too [12:39:06 CET] <JEEB> ritsuka: I think the real additional metadata would be the MAXFall etc stuff [12:39:20 CET] <JEEB> but yes, this lets you set the primaries|transfer|matrix [12:39:35 CET] <JEEB> wm4: is this enough or did you want the max brightness etc stuff? [12:44:58 CET] <JEEB> too bad ISOBMFF specifies itself against https://www.itu.int/rec/T-REC-T.832-201608-I/en [12:45:11 CET] <JEEB> so the values available for primaries|transfer|matrix are limited to those :P [12:45:38 CET] <JEEB> (it specifies 29199-2 but that's effectively the same thing available for free) [12:45:51 CET] <rcombs> is distinguishing MOV, MP4, BMFF, etc. from each other useful [12:46:12 CET] <JEEB> I'd distinguish two things. MOV and ISOBMFF [12:46:21 CET] <JEEB> since those do have actual differences [12:46:28 CET] <rcombs> elaborate? [12:46:37 CET] <wm4> JEEB: yeah, some standards require the max brightness too, apparently [12:46:42 CET] <JEEB> I think one of them defined some values signed and others unsigned [12:46:47 CET] <JEEB> that's most I can remember [12:46:54 CET] <rcombs> oh joy [12:47:09 CET] <JEEB> I think MOV might have been the one with unsigned values [12:47:19 CET] <JEEB> and ISOBMFF then noticed that signed might be useful [12:47:21 CET] <rcombs> is it like OTF, where things are defined as signed but no meaning is defined for negative values [12:48:09 CET] <JEEB> I've not honed my skills in differentiating those two things like Paranoialmaniac has so unfortunately I can't go as far as that :D [12:48:37 CET] <JEEB> just that I know that they have some differences like that due to qtff being the initial thing [12:49:02 CET] <rcombs> (iirc TTF and OTF both define glyph count and point count as signed, despite neither of those fields having any meaning for negative values) [12:49:08 CET] <JEEB> wm4: so yeah, at this moment I don't see anything in addition to JPEG-XR's colorspace values (why the fuck did they specify the values have to come from there I have no idea) [12:49:27 CET] <JEEB> (the JPEG-XR spec hasn't been updated at ISO/IEC since 2012) [12:49:29 CET] <ritsuka> qtff has got some major differences in audio atoms for example [12:49:54 CET] <rcombs> ritsuka: like, incompatible stuff, or different atoms that do the same thing? [12:51:26 CET] <ritsuka> different atoms that are not defined in ISOBMFF [12:51:51 CET] <rcombs> oh okay [12:51:58 CET] <JEEB> ok, so those don't actually require separate parsing logic [12:52:05 CET] <rcombs> so you can just support both, and don't have to actually differentiate between the file types [12:52:49 CET] <JEEB> well, in that case at least. the cases where integer types've changed are a bit less simple although hopefully you just never find files with large enough values :P [12:52:59 CET] <rcombs> that's what I thought, based on mov.c (which I am somewhat familiar with, but haven't exactly read through extensively) [12:53:37 CET] <JEEB> but yeah, most differentiation is required on the writing side as opposed on the parsing side [12:55:20 CET] <wm4> mov.c is over 6000 lines so it'll take a bit longer to get familiar with it [13:35:29 CET] <BtbN> the mov/mp4 code is outright scary [13:36:39 CET] <JEEB> if you want something scary, go look at the vsync code in ffmpeg.c. I'm not sure if the original writer would even understand it at this point [13:37:38 CET] <BtbN> I don't mean it's bad code. The format itself makes it scary [13:37:54 CET] <JEEB> right [13:53:07 CET] <cone-499> ffmpeg 03Chris Moeller 07master:ecd360041ea7: avformat: fix ID3v2 parser for v2.2 comment frames [14:54:15 CET] <Compn> hehe [14:54:26 CET] <Compn> because mkv is sane, and mov is not. [14:55:12 CET] <JEEB> no [14:55:55 CET] <JEEB> ISOBMFF is at least specified insanity with proper timebases and matroska is a to-be-specified mess that tried to copy ISOBMFF at the time when ISOBMFF was still weak :) [15:01:56 CET] <wm4> I like mkv for being actually suitable for streaming [15:02:18 CET] <JEEB> fragmented isobmff handles that, too [15:02:29 CET] <wm4> fragmentation is a shitty hack [15:02:38 CET] <JEEB> given that the extradata issue should be the same in matroska as well [15:02:45 CET] <wm4> ? [15:03:11 CET] <JEEB> although I guess with ISOBMFF it's more of the index which I guess matroska doesn't have (you just get the extradata thing) [15:03:17 CET] <wm4> mkv might also be more resilient to corruption [15:03:21 CET] <JEEB> which is what the fragmentation is supposed to handle [15:03:38 CET] <wm4> which index? [15:04:06 CET] <kierank> 2:02 PM <wm4> fragmentation is a shitty hack [15:05:25 CET] <JEEB> wm4: moov [15:05:42 CET] <JEEB> although I might be mis-recalling things at this point :P [15:06:23 CET] <JEEB> because you've got the trak-edts-etc there [15:08:38 CET] <JEEB> then you've got moof etc for fragments [15:11:27 CET] <wm4> keep in mind that mkv needs no index at all [15:11:36 CET] <wm4> it only exists to make seeking faster [15:12:19 CET] <JEEB> yea [15:12:31 CET] <JEEB> I hope the matroska specification effort will lead to a proper v5 [15:12:40 CET] <JEEB> v4 will be specified as "what's there now" [15:14:01 CET] <wm4> "My guess is that the OpenBSD guys want the world to get rid of openssl completely (see for example http://opensslrampage.org/) and breaking API compatibility with openssl is their "strategy"." [15:14:03 CET] <wm4> jesus christ [15:15:46 CET] <jkqxz> The reference to a website which hasn't been updated in more than two years inspires great confidence, too. [15:17:15 CET] <ubitux> openssl started being sponsored by google & friends soon after the fork drama iirc [15:17:31 CET] <ubitux> (google or/and some other big corp) [15:18:06 CET] <ubitux> so actual developments and fixes happened there as well and prevented a turnover in usage [15:20:21 CET] <wm4> nice one, google [15:27:17 CET] <ubitux> or maybe that was http://www.theregister.co.uk/2016/01/04/dutch_government_says_no_to_backdoo… ? [15:28:29 CET] <ubitux> also https://groups.google.com/forum/m/#!topic/mailing.openssl.users/-P4T62ml_1I [15:29:30 CET] <ubitux> i guess i was confused about google, probably a memory derp [15:29:45 CET] <ubitux> but anyway, they got much more money after the libressl fork [15:36:38 CET] <wm4> ah [15:37:07 CET] <JEEB> google has its own fork now IIRC [15:37:17 CET] <phh> yes, boringssl [15:37:25 CET] <JEEB> https://boringssl.googlesource.com/boringssl/ [15:38:40 CET] <Gramner> libavssl [15:39:06 CET] <kierank> does kaby lake need new asm? [15:39:28 CET] <Gramner> no [15:40:18 CET] <Gramner> skylake e5/e7 xeons (and the skylake-x hedt versions based on those) does [15:51:50 CET] <atomnuker> avx512 finally? [15:57:46 CET] <Gramner> yes [15:58:20 CET] <kierank> maybe time to drop yasm [16:03:07 CET] <durandal_170> why? [16:03:35 CET] <Gramner> because it's been unmaintained since 2015 [16:03:58 CET] <durandal_170> why? [16:05:41 CET] <Gramner> because yasm was largely a one-man show (with the occasional third party patch) and he lost interest I guess? nasm on the other hand is actively developed and is backed by Intel [16:07:39 CET] <atomnuker> btw TD-Linux, matroska muxing overhead can be quite big: [16:07:41 CET] <atomnuker> 32kbps, 50 packets/sec - mka: 8.70%, ogg: 2.15% ; 32kbps, 25 packets/sec - mka: 5.64%, ogg: 1.54% [16:07:50 CET] <atomnuker> 32kbps, 16 packets/sec - mka: 4.18%, ogg: 1.28% ; 32kbps, 8 packets/sec - mka: 2.74%, ogg: 1.28%32kbps, 16 packets/sec - mka: 4.18%, ogg: 1.28% ; 32kbps, 8 packets/sec - mka: 2.74%, ogg: 1.28% [16:08:00 CET] <atomnuker> 128kbps, 8 packets/sec - mka: 0.68%, ogg: 0.63% ; 500kbps, 8 packets/sec - mka: 0.17%, ogg: 0.45% [16:08:35 CET] <atomnuker> double pasted the second line, but its matroska does save alot of overhead if you don't have many packets [16:09:00 CET] <atomnuker> and the bitrate is huge [16:09:38 CET] <atomnuker> for both formats this actually makes it worth it to pack as many frames into a packet [16:10:28 CET] <atomnuker> this is for cbr frames only, I'll need to check what its like for vbr where you pay 1 or 2 bytes per packet [16:10:52 CET] <atomnuker> (also there was no metadata at all anywhere, this was a clean test) [16:11:29 CET] <wm4> well at least you can seek in mkv, unlike ogg [16:12:10 CET] <wm4> Gramner: what's the story of nasm being unmaintained or falling behind yasm for a while? [16:13:15 CET] <Gramner> iirc the main reason for yasms existance is that nasm had a weird license back then. [16:13:39 CET] <Gramner> nasm has since relicensed so that's a moot point now [16:14:22 CET] Action: wm4 fondly remembers making his own assembler, using nasm's opcode table out of laziness [16:14:23 CET] <jamrial> what's this anou avx512 finally? [16:14:28 CET] <jamrial> *about [16:15:12 CET] <Gramner> not sure what "finally" implies, it has always been publically scheduled for SKX [16:15:36 CET] <jamrial> i was quoting atomnuker [16:15:38 CET] <Gramner> (the normal cpu version that is, not the xeon phi subset) [16:35:29 CET] <JEEB> Gramner: also at one point it wasn't fast enough for x264 to implement some things [16:50:43 CET] <Polochon_street> wm4: hi! I'm trying to make the last version of the ID3v2 patch, would the comment « ID3v2 metadata information » be enough for the id3v2_meta variable inside internal.h? I can't think of something better... [16:56:06 CET] <wm4> Polochon_street: sure [16:56:30 CET] <Polochon_street> I wanted to convey the idea that this was there only because of the MP3 problem, but heh [16:58:21 CET] <wm4> well, someone who wants to find out why it's needed will see that mp3dec.c uses it [16:59:54 CET] <Polochon_street> true [17:01:46 CET] <wm4> probably wouldn't be ok for external API, but this is just internal [17:07:24 CET] <jamrial> durandal_170: http://fate.ffmpeg.org/report.cgi?time=20170128103925&slot=x86_64-archlinux… [17:07:35 CET] <jamrial> it's the scc demuxer probe function [17:08:28 CET] <jamrial> easiest way to fix it would be to copy the behavior of the ass demuxer probe function [17:08:57 CET] <jamrial> or maybe make sure ff_subtitles_read_line() reads at least 18 bytes [17:25:37 CET] <cone-490> ffmpeg 03Paul B Mahol 07master:4cfa1f80a976: avformat/sccdec: attempt to fix valgrind issue [17:48:03 CET] <cone-490> ffmpeg 03James Almer 07master:dce863421b64: avformat/matroskaenc: don't reserve more bytes than needed for the Colour master size [18:59:36 CET] <durandal_170> can i push atrac advanced lossless decoders? [19:03:18 CET] <wm4> did the maintainer agree? [19:22:29 CET] <rakshith> hi guys. I'm interested in participating in this year's GSoC. I saw the GSoC page of FFMPEG, and I would like to work on the Ambisonic Decoder project. I need some help and advice here. Thanks! [19:28:27 CET] <wm4> rakshith: mail the mentor for the project [19:34:47 CET] <durandal_170> rakshith: im the mentor for that project [19:35:29 CET] <rakshith> wm4: And one more thing. Will additional ideas be added on to the page, or are they the final list of ideas? [19:35:50 CET] <durandal_170> wm4: maxim is ignoring me as usual [19:36:20 CET] <rakshith> durandal_170: Should we talk here, or shall I mail you? [19:36:55 CET] <durandal_170> rakshith: feel free to do whichever way you prefer/like [19:37:57 CET] <Polochon_street> Is there a page somewhere for the guidelines for submitting fate test files? The fate page https://ffmpeg.org/fate.html here is not very informative... [19:38:56 CET] <durandal_170> Polochon_street: talk privately with michaelni to upload files [19:39:39 CET] <Polochon_street> durandal_170: thanks, but I'm concerned over names guidelines, private property issues, etc [19:40:57 CET] <durandal_170> just tell in what directory to upload file with meaningful name [19:49:22 CET] <wm4> durandal_170: ignoring as in? also who's maxim [19:49:51 CET] <wm4> Polochon_street: yeah, usually someone like michaelni uploads it, then we wait a few days, then we push the fate tests [19:49:59 CET] <wm4> because it has to trickle down or something (???) [19:50:00 CET] <durandal_170> wm4: author of atrac3+ decoder [19:57:29 CET] <Polochon_street> wm4: alright thanks. I found this http://trac.ffmpeg.org/wiki/FATE/AddingATest explicative page, I'll probably need some days to figure out how to do it properly [20:00:22 CET] <wm4> durandal_170: how long did you wait? doc/developers.texi specifies waiting times [20:03:44 CET] <durandal_170> wm4: i wait very long, few days [20:04:19 CET] <wm4> it allows you to push "small" changes after a few days of waiting [20:09:16 CET] <durandal_170> wm4: this one just adds new decoder and changes single line in atrac3plus file [20:12:14 CET] <wm4> sounds like a "small" change [20:17:08 CET] <jamrial> ping him, and if he doesn't reply even after that then push it [22:06:38 CET] <TD-Linux> atomnuker, I assume for the different packets/sec you're using one of the matroska lacings? [22:07:43 CET] <wm4> does ffmpeg even write lacings [22:07:54 CET] <wm4> or just put every packet into separate elements [22:08:04 CET] <wm4> that could quite bloat up with small packet sizes [22:28:20 CET] <atomnuker> "put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0); // no lacing (yet)" <- apparently not [22:32:42 CET] <wm4> maybe remuxing with mkvmerge will merge them or something [22:57:47 CET] <TD-Linux> atomnuker, er how are you varying packets/s without using lacing? [22:58:04 CET] <TD-Linux> or is this AAC or something [22:58:10 CET] <TD-Linux> (or just blank data) [22:58:55 CET] <atomnuker> I'm just varying how much frames I put in the opus layer [22:59:47 CET] <TD-Linux> ok [23:09:41 CET] <cone-381> ffmpeg 03Paul Arzelier 07master:65862f57ad2f: avformat: Ignore ID3v2 tags if other tags are present e.g. vorbis [23:09:42 CET] <cone-381> ffmpeg 03Marijn Meijles 07master:227d602bb36f: avformat/ac3dec: Fix to prevent runaway ac3 detection by looking at the actual frame rather than the first detected frame. [23:19:15 CET] <kierank> michaelni: the fix is wrong no? [23:19:19 CET] <kierank> you should be reading the syncwords? [23:20:19 CET] <kierank> this is trigger happy committing :( [23:37:01 CET] <wm4> trigger happy [23:37:07 CET] <wm4> that's a nice description [23:37:26 CET] <wm4> although I have some faith if what the patch author claims is true [23:38:35 CET] <michaelni> kierank, not sure i understand, the code prior to the patch used the wrong buffer and after the patch is using the intended one. i dont know if there are more issues quite possibly there are [23:38:54 CET] <kierank> well not that I care about hacky probing but any ac3 in wav should have spdif syncwords [23:39:48 CET] <wm4> I don't know about AC3 specifically, but apparently it's ok to skip the spdif sync word if the data packet is as large as the spdif frame size [23:40:55 CET] <kierank> does that extreme case actually exist? [23:42:15 CET] <wm4> spdifenc.c supports it at least [23:42:28 CET] <wm4> btw. did I mention yet how much I hate spdif [23:43:21 CET] <wm4> hmm it's worth noting that spdifenc.c does this only in the DTS case [23:43:38 CET] <kierank> yes, losses could be a pathological case [23:44:00 CET] <kierank> lossless* [23:46:18 CET] <kierank> lossless could even be larger than the original pcm [23:46:31 CET] <kierank> so it won't work in that case at all [23:46:35 CET] <wm4> apparently that happens often with DTS [23:46:40 CET] <wm4> because DTS is a shit codec [23:47:03 CET] <wm4> that's also why the DTS-HD spdif output rate is much larger than the decoded PCM rate [23:47:08 CET] <wm4> bitrate [23:47:27 CET] <wm4> but hey at least the dts light goes on [23:51:06 CET] <kierank> oh yeah dts is 1536kbps [00:00:00 CET] --- Sun Jan 29 2017

1 0

ffmpeg.log.20170128
by burek 29 Jan '17

29 Jan '17

[00:01:07 CET] <furq> wtf [00:01:30 CET] <furq> i can fade the webm into testsrc but i can't fade testsrc into the webm [00:01:37 CET] <furq> it just starts the fade immediately [00:01:48 CET] <furq> this is baffling [00:01:56 CET] <Nune> i...er...sorry :? [00:02:13 CET] <Nune> source images: https://drive.google.com/open?id=0B3kkDhHHsCMhSGpjLW1MVzFFN2M (150 MB zip) [00:02:34 CET] <Nune> command to produce dialog_line_cropped.webm: ffmpeg -framerate 60 -i dialog_line_%03d.png -vf cropdetect dialog_line_cropped.webm [00:02:52 CET] <furq> ok that setpts is wrong but idk how [00:05:36 CET] <phillipk_> The following command is intended to layer the audio (at specific times) on top of the audio for the first input (video_with_audio.ts) but the result is shifting (by a delay of about 20 seconds) the audio in that first input. [00:05:37 CET] <phillipk_> http://pastebin.com/uN5nnSCr [00:06:12 CET] <phillipk_> Do I need to put that input (video_with_audio.ts) into the filter_complex amix? [00:19:40 CET] <furq> Nune: i'm a massive idiot [00:19:43 CET] <furq> http://vpaste.net/0hZKB [00:19:54 CET] <Nune> hush! whats different [00:20:05 CET] <furq> setpts=PTS+(5/TB) [00:20:09 CET] <phillipk_> the issue is that I've got an original (with audio) and I want to overlay the additional audios... that works except in the output, the original's audio is out of synch... it's audio is playing too early (or too fast so it drifts) [00:20:31 CET] <furq> also it's actually overlaying on the black background now, that was broken before [00:20:52 CET] <furq> that'll teach me to forget about timebases [00:20:54 CET] <phillipk_> yeah, I think the problem is NOT your map help [00:20:58 CET] <Nune> looks great furq :D [00:21:04 CET] <Nune> thank you so much [00:21:04 CET] <phillipk_> oh, maybe you're talking about Nune's issue. [00:21:27 CET] <furq> that should work with the image sequences as input too [00:21:29 CET] <Nune> not to see about not double-compressing with webm [00:21:32 CET] <furq> yeah [00:21:33 CET] <Nune> yeah ill try to wrap it all together [00:22:32 CET] <furq> phillipk_: are those audio sources all mono [00:22:42 CET] <phillipk_> yeah [00:22:50 CET] <phillipk_> the layered ones [00:22:51 CET] <furq> well that's me out of ideas [00:23:44 CET] <phillipk_> I think I found the issue... maybe I should change [0][a][b][c]amix=4[out] to instead [a][b][c]amix=3[out] because my map is taking ALL of 0 input and all of "out" [00:23:55 CET] <furq> yeah i was going to say maybe you need 0:a [00:24:03 CET] <furq> i figured it would just do the right thing though [00:24:16 CET] <furq> on the basis that it'd probably just throw an error otherwise [00:25:16 CET] <furq> if you exclude [0:a] from amix then that audio track will just be discarded [00:25:25 CET] <phillipk_> Oh, [00:25:54 CET] <phillipk_> so make the last segment of the filter to be: [0:a][a][b][c]amix=4[out] [00:25:56 CET] <phillipk_> ? [00:26:06 CET] <furq> yeah, i doubt that'll help though [00:26:16 CET] <furq> unless input 0 has multiple audio tracks [00:26:52 CET] <phillipk_> maybe change: -map 0:v -map "[out]" to instead -map 0 -map "[out]" [00:27:05 CET] <furq> that'll give you multiple audio tracks in the output [00:27:17 CET] <phillipk_> what if "out" is just audio? [00:27:41 CET] <furq> -map 0 will map all the streams from the input unfiltered [00:27:45 CET] <phillipk_> what's weird is the original code "works" ... it just jacks with the audio in the first input [00:27:52 CET] <furq> so you'll get 0:v, 0:a, and then [out] [00:28:28 CET] <furq> maybe the ts has a negative offset on one of the streams or something like that [00:28:43 CET] <phillipk_> when I play the .ts it plays nicely [00:28:45 CET] <furq> try demuxing the audio to wav (or whatever) and then use that as an input [00:28:47 CET] <phillipk_> synched etc. [00:30:47 CET] <phillipk_> you mean have input 0 be video only, input 1 be the audio from that video... then inputs 2,3,4 (audio only)... then use that input 1 at the beginning of the filter_complex? [00:30:56 CET] <furq> that probably won't work actually [00:31:08 CET] <phillipk_> splitting out the audio from the input seems odd. [00:31:14 CET] <furq> i'd guess[4~ the ts has an offset on the audio track which is being discarded by amix [00:31:22 CET] <furq> but demuxing it would also discard that offset, sot hat's no good [00:31:36 CET] <furq> maybe ffprobe -show_streams will show the offset if there is one [00:31:46 CET] <phillipk_> I create the .ts file but not sure how I could put (or remove) the offset--Okay, I'll look [00:34:56 CET] <Nune> furq: any way to pipe cropdetect result into a crop command? [00:35:05 CET] <phillipk_> furq [00:35:18 CET] <phillipk_> http://pasteboard.co/ri9GPr3tl.png [00:35:20 CET] <furq> not that i know of [00:35:46 CET] <Nune> so applying the result cropdetect has to be done manually? [00:36:11 CET] <furq> phillipk_: is the source audio 1.422422 seconds offset [00:36:19 CET] <phillipk_> ok [00:36:39 CET] <furq> that was a question, i don't know that's what that means [00:37:17 CET] <phillipk_> I don't know how that got in there--I'm just producing the .ts file by concating a bunch of .ts files [00:37:45 CET] <phillipk_> but, 1.4 seconds off doesn't explain the 25 seconds off (at least after 12 minutes) [00:38:30 CET] <furq> if it's desyncing and not just delayed then i've got no idea [00:39:02 CET] <furq> hopefully someone who's better than me with audio knows [00:41:40 CET] <phillipk_> I'll do some tests, but it seems like it's just off by 25 seconds at at least 2 points in the video...12 minutes and 30 minutes [00:46:48 CET] <Nune> furq this is working great; just trying to figure out how to automate the auto-cropping [00:46:55 CET] <Nune> thanks for the help getting it seamless [00:49:14 CET] <mosb3rg> anyone around with experience dumping HLS feeds with a cookie, i have all the values i need, but im getting a wierd tcp:443 error i havent seen previously. [00:49:22 CET] <mosb3rg> its on SiriusXM.com [00:49:36 CET] <mosb3rg> there live.. i can dump but the on demand it just throws this wierd error. [00:49:55 CET] <mosb3rg> [tcp @ 0x1c57f60] Connection to tcp://:443 failed: Connection refused [00:50:26 CET] <mosb3rg> its not throwing a forbidden.. 403 [00:50:33 CET] <mosb3rg> so clearly it seems something is missing in the processing. [00:51:53 CET] <mosb3rg> ahh wait.. i think it might be trying to connect outbound to verify a secret hash phrase perhaps i dunno [00:52:10 CET] <mosb3rg> can anyone perhaps take a look at the account and see if they are able to manage it [01:34:45 CET] <NapoleonWils0n> hi all [01:35:12 CET] <NapoleonWils0n> trying to record a video with closed captions, would -c:s copy be the right flag to use [01:35:50 CET] <NapoleonWils0n> and do you need to map the streams [01:36:08 CET] <furq> if this is from dvb or something then closed captions aren't a separate stream so that won't work [01:36:44 CET] <NapoleonWils0n> right trying to help someone in us where tv channels use closed captions, havent looked at the stream yet [01:37:22 CET] <furq> -f lavfi -i "movie=input.ts[out0+subcc]" [01:37:30 CET] <furq> apparently that'll give you a subtitle stream [01:37:47 CET] <NapoleonWils0n> i have seen that command floating around [01:37:50 CET] <furq> you'll need a container which supports that subtitle format though [01:37:59 CET] <NapoleonWils0n> using mkv [01:38:25 CET] <furq> that's as good a bet as any [01:38:53 CET] <NapoleonWils0n> thats why i picked it, can dump most things into an mkv [01:39:53 CET] <NapoleonWils0n> you can use wireshark to find and download subtitles files [01:40:05 CET] <NapoleonWils0n> if the subs are in external file [03:12:58 CET] <the_k> anyone ever played with motion detection with ffplay/ffmpeg? [04:08:44 CET] <xeons> Is lavfi missing from 3.2.2? I don't see it on OS X [04:09:27 CET] <xeons> fmpeg -filters | grep "lavfi" [04:09:42 CET] <xeons> *ffmpeg [04:10:36 CET] <furq> lavfi is a format, not a filter [04:11:00 CET] <furq> or a device, even [04:11:48 CET] <xeons> ffmpeg -f lavfi -i video.mov -> [lavfi @ 0x7fa7aa800000] No such filter: 'video.mov' [04:12:06 CET] <furq> well yeah [04:12:07 CET] <xeons> So I guess it is there [04:12:22 CET] <furq> it'll be in ffmpeg -devices [04:15:10 CET] <xeons> ok, thanks for clarifying that. I'm trying to use it to create a 2x2 grid (https://trac.ffmpeg.org/wiki/FilteringGuide#multipleinputoverlayin2x2grid) [04:16:37 CET] <xeons> Perhaps you can explain what I'm doing wrong as that doc results inn the "No such filter" error above no mater how I try to quote the files. [04:16:49 CET] <xeons> ffmpeg -f lavfi -i 003_003_MVI_1639.mov -filter_complex "[0:v]negate[a]" -map "[a]" -t 5 text.avi [04:17:50 CET] <furq> just get rid of -f lavfi [04:20:58 CET] <xeons> yep, works great. Why does the wiki say to specify it? Was that just an old requirement? [04:27:53 CET] <DHE> "-f lavfi" means a filter generates the video rather than reading from a traditional source. eg: testsrc2 [04:28:22 CET] <DHE> you can't request the video come from a filter and then give it a filename instead [04:37:48 CET] <xeons> So what was the wiki talking about? I thought the docs said "-f lavfi -i video" was feeding lavfi a video input. [05:06:40 CET] <DHE> *tuhnk* [05:06:50 CET] <DHE> they're using testsrc as the image generator. like I said above [05:18:12 CET] <the_k> is it possible to use ffmpeg to display a stream as it's saving it to disk? [05:18:31 CET] <the_k> i only want 1 connection to the source to save bandwidth [05:19:30 CET] <furq> ffmpeg -i foo -c:v libx264 out.ts -c:v rawvideo -f nut - | mpv - [05:20:14 CET] <the_k> so you use -c twice [05:20:34 CET] <furq> you just specify two output filenames [05:20:36 CET] <furq> one of them is - [05:20:54 CET] <the_k> hm [05:21:01 CET] <the_k> how is it then displayed to a window:? [05:21:10 CET] <furq> you pipe it to mpv [05:21:16 CET] <furq> or any movie player which accepts input on stdin [05:21:23 CET] <furq> ffplay would work fine too but ffplay isn't very good [05:21:29 CET] <the_k> i suspect that command won't work in window [05:21:30 CET] <the_k> i suspect that command won't work in windows [05:21:32 CET] <furq> it should do [05:21:38 CET] <the_k> ok [05:21:56 CET] <furq> ffmpeg can't display anything by itself, you need to pipe the output somewhere [05:22:08 CET] <furq> although you should just be able to play back the .ts as it's recording [05:22:11 CET] <the_k> does that go to an actual secoind file? [05:22:14 CET] <furq> no [05:22:19 CET] <the_k> ok [05:22:21 CET] <furq> - means "pipe to stdout" [05:22:22 CET] <the_k> yeah i can play the recording [05:22:26 CET] <furq> mpv - means "pipe from stdin" [05:22:31 CET] <the_k> but it's lagged, even when i skip to the 'end' [05:23:32 CET] <furq> actually that command might not be the best idea [05:23:40 CET] <furq> if you close the player then the recording will drop [05:25:15 CET] <furq> there are other ways to do it but they all have the same issue afaik [05:30:52 CET] <the_k> mpv or mpc? [05:34:22 CET] <the_k> mpv isn't an executable [05:35:37 CET] <furq> https://mpv.io/ [05:47:01 CET] <the_k> ah i was searching for a binary on https://github.com/mpv-player/mpv#downloads [05:47:03 CET] <the_k> thanks [05:47:15 CET] <the_k> do you use this as a main player? [05:47:22 CET] <the_k> as your main * [05:47:36 CET] <furq> no [05:47:48 CET] <furq> i probably should but i'm too lazy to switch from mpc-hc [05:47:57 CET] <the_k> ah [05:55:13 CET] <the_k> damn [05:55:25 CET] <the_k> it works but i'm getting a few errors [05:55:35 CET] <the_k> and the player window is shaking the video about [05:55:43 CET] <the_k> and and down by a couple pixels [05:56:58 CET] <the_k> ah i set the I Frame interval lower on the stream and it's a lot better [05:57:11 CET] <the_k> though it does still have the jumping thing going on a bit [05:58:15 CET] <the_k> and the saved to disk stream also picks up the errors [06:00:14 CET] <the_k> seems the problem is with the extra work it has to do [13:32:09 CET] <faLUCE> Hello. In a MPEG-ts header is there any info about the codec used? [13:32:40 CET] <DHE> yes, mpegts does have codec information, including some metadata like language for audio [13:33:16 CET] <faLUCE> DHE: in which field? http://dvd.sourceforge.net/dvdinfo/mpeghdrs.html <-- here's a list of the fields, but I can't find the correspnding one [13:33:47 CET] <DHE> that's the mpeg codec, not the mpegts container [13:33:58 CET] <JEEB> you first get the PAT, then the PMT [13:34:16 CET] <JEEB> IIRC the PMT lists what PIDs and what those PIDs contain :P [13:34:45 CET] <DHE> JEEB: that is correct for mpegts [13:34:54 CET] <DHE> but this document is DVD-specific which I don't think uses mpegts directly [13:35:14 CET] <JEEB> yea, it uses mpeg-ps [13:35:23 CET] <DHE> that makes sense [13:35:30 CET] <faLUCE> DHE: sorry. From wikipedia: "Program Map Tables (PMTs) contain information about programs. For each program, there is one PMT. While the MPEG-2 standard permits more than one PMT section to be transmitted on a single PID (Single Transport stream PID contains PMT information of more than one program), most MPEG-2 "users" such as ATSC and SCTE require each PMT to be transmitted on a separate PID that is not used for any other [13:35:32 CET] <faLUCE> packets. The PMTs provide information on each program present in the transport stream, including the program_number, and list the elementary streams that comprise the described MPEG-2 program. There are also locations for optional descriptors that describe the entire MPEG-2 program, as well as an optional descriptor for each elementary stream. Each elementary stream is labeled with a stream_type value." <--- It doesn't [13:35:34 CET] <faLUCE> mention anything about the codec [13:35:50 CET] <JEEB> > "optional descriptor for each elementary stream" [13:36:04 CET] <JEEB> there are some listed in the spec [13:36:08 CET] <DHE> which is the stream metadata. [13:36:37 CET] <DHE> there's also a mandatory byte that identifies the stream type. which basically comes down to the codec (mpeg2, h264, AAC, AC3, other program metadata) [13:36:55 CET] <faLUCE> I see, tnx [13:37:13 CET] <JEEB> just look for the latest version of H.222 :P [13:37:19 CET] <JEEB> that should answer your questions faster [13:37:20 CET] <DHE> here's what I suggest you do. install wireshark, make (or download) a .ts file and open it with wireshark's File, Open... dialog [13:38:51 CET] <faLUCE> the, a mpegts stream doesn't need to have a header at the beginning of the stream, right? [13:38:59 CET] <faLUCE> then* [13:39:10 CET] <JEEB> MPEG-TS is just a stream of 188 byte packets [13:39:42 CET] <DHE> mpegts is semi-headerless. it's designed to be received in a stream that may be joined at any point, even a point where the byte alignment of the stream is unknown [13:39:52 CET] <DHE> mpegts is the format used for ATSC over-the-air TV broadcasts [13:40:04 CET] <JEEB> but that also of course means that you have to send out the PAT/PMT information every now and then [13:40:18 CET] <JEEB> otherwise receivers wouldn't be able to know what streams there are and which PIDs are what [13:40:28 CET] <faLUCE> JEEB: yes [13:40:29 CET] <JEEB> and of course the video stream will have to have parameter sets around [13:40:31 CET] <DHE> right. so to join a stream you 1) find and align the sync bytes 2) find and parse the PAT 3) find and parse the PMT 4) find a keyframe [13:47:52 CET] <DHE> faLUCE: did you do the wireshark thing? [13:51:19 CET] <faLUCE> DHE: I'll do that, because I will need to go deeper into the argument. But currently I have to understand how the PCR works. I I created with libav a MPEGts stream with both audio(mp2) and video (h264). I computed video timestamps with av_gettime(), and then rescaled them to the mpegts time_base (1/90000). For audio I computed them based on the samples frequency, and then rescaled them too to the ts time_base. Now, given [13:51:21 CET] <faLUCE> that I sent both audio and video timestamps, why do I need a periodical PCR ? [13:52:10 CET] <DHE> ffmpeg will take care of PCR handling [13:52:34 CET] <faLUCE> DHE: yes, I know that it's automatically created. But why is it needed? [13:52:37 CET] <DHE> its mainly intended for use by streamers which need to send data at a fixed rate to know at what point each packet should be "in the air" [13:53:15 CET] <DHE> a lot of the time the transmission rate will be fixed and the transmission site needs to fill in unused time with NULL packets (pid 0x1fff). the PCR helps it get the timing right [13:57:02 CET] <faLUCE> DHE: if I send audio only, the bitrate is fixed (in my case, I send 32kb/s with 1/16000 sample rate). But given that these packets have incremental timestamps based 1) on the samples frequency + 2) on the mpegts timestamp (1/90000), why a PCR is needed? [13:57:38 CET] <faLUCE> the receiver has all the infos it needs.... without PCR [13:57:48 CET] <DHE> it's a requirement of the spec. mpegts is used in over-the-air and cable broadcasts where a single mpegts stream may carry multiple live TV channels, on-demand video, and maybe more [13:58:25 CET] <DHE> so the transmission needs to manage that all cleanly without risking buffer underrun in the players [14:00:24 CET] <faLUCE> DHE: I see, but it doesn't have sense yet, for me... if I have monotonous timestamps, and a time_base, why would I care about a PCR? the PCR should be the time_base itself.... [14:01:27 CET] <JEEB> if you find something to be not useful for yourself you can start looking at alternatives [14:01:40 CET] <JEEB> if the MPEG-TS spec says you need to have PCR then you need to have PCR [14:02:07 CET] <DHE> just because you don't find it useful for your particular use case doesn't mean it's useless [14:03:00 CET] <faLUCE> JEEB: DHE, I'm not saying that it's useless. I'm saying that I don't understand in which cases it's useful :-). Someone say that it's useful for CBR, but why ? [14:04:10 CET] <JEEB> to know when to fill the stream with null packets to create a CBR mux [14:04:59 CET] <DHE> CBR isn't the codec setting. it's the stream transmission setting [14:05:29 CET] <DHE> over the air broadcasts run at 18.8 (??) megabits per second. that's a requirement. if you're streaming a black image, you still have to fill 18.8 megabits of airtime [14:05:49 CET] <JEEB> exact numbers of course depend on your broadcast specs [14:10:00 CET] <faLUCE> ok, if I well understand, I have two rates: the codec's rate and the ts rate [14:10:19 CET] <faLUCE> the ts rate is higher than the codec's one [14:10:51 CET] <faLUCE> and it's fixed. [14:14:40 CET] <faLUCE> then the demuxer demuxes packets at a fixed rate, and these packets have a variable part with useful data, and zeroes for the remaining part? [14:15:09 CET] <faLUCE> (null packets, not zeroes) [14:15:27 CET] <DHE> not demuxer, but muxer [14:15:55 CET] <faLUCE> DHE: but also the demuxer receives these packets [14:16:06 CET] <DHE> in my 18.8 megabit estimate, that's 12,500 cells/second of the 188 byte cells (using "cell" in homage to the ATM connectivity term) [14:16:28 CET] <DHE> but if you only need 6,000 cells/second, then yes about 6500 cells are actually NULLs [14:17:11 CET] <Franciman> hi, how can I extract keyframes from a video? [14:17:23 CET] <DHE> Franciman: and do what? [14:17:28 CET] <faLUCE> then, if some bytes are LOST in the air, a PCR is useful to RESYNC [14:17:30 CET] <faLUCE> right? [14:17:36 CET] <DHE> ... no [14:18:00 CET] <Franciman> DHE, I need the corresponding AVFrame's [14:19:07 CET] <DHE> Franciman: the AVFrame contains a key_frame field you can check to see if the input frame was a keyframe [14:19:52 CET] <Franciman> oh... sorry for the dumb question, didn't notice it. Thanks a lot [14:20:19 CET] <DHE> eh, it happens [14:20:27 CET] <JEEB> the "keyframe" naming of it really is old though [14:21:04 CET] <JEEB> since nowadays it means a "random access picture", since not all keyframes are necessarily that [14:21:13 CET] <Franciman> oh! [14:21:33 CET] <JEEB> I think with all modern formats the keyframe flag *should* be exported only on IRAPs [14:21:43 CET] <JEEB> if not, that is a bug [14:26:58 CET] <faLUCE> Then I don't understand yet. JEEB said that PCR is useful fo know when to fill the stream with null packets. But given that the mpegts timebase is fixed to 90000, the muxer already knows how many null packets has to provide for creating the CBR. So, why a PCR is needed? [14:28:27 CET] <DHE> a PCR is program-wide and the timestamps on the frames are intended for players which buffer and do out-of-order processing. the PCR is intended for the muxer/transmitter which has stricter deadlines [14:28:31 CET] <DHE> which is why the PCR runs at 27 MHz [14:30:39 CET] <faLUCE> DHE: then are you saying that PCR is not necessary when you have timestamps? [14:30:48 CET] <DHE> I give up [14:30:55 CET] Action: JEEB pats DHE [14:31:27 CET] <faLUCE> :-( [14:48:05 CET] <faLUCE> ok, now (maybe) I'm starting to understand. With PCR the muxer creates a stream with a CONSTANT MUXRATE (which is the bitrate of the muxer). So it sends: PCR - (pkt with data) - (pkt with data) - (pkt with data) .... (NULL packets) - PCR - etc. Where the null packets are (more or less) before the next PCR is sent [14:49:12 CET] <faLUCE> with codecs' bitrate < muxrae [14:50:34 CET] <faLUCE> then, the demuxer knows the quantity of real data to demux based on the interval between two PCRs [14:51:12 CET] <faLUCE> the quantity of data per second [14:53:11 CET] <DHE> the demuxer doesn't care about the PCRs [14:54:37 CET] <Franciman> can I always rely on the fact that AVFormatContext's pb is not NULL if I create the context with avformat_open_input? [14:55:09 CET] <Franciman> or is there any case in which it is closed? [14:55:26 CET] <Franciman> (and NULL'd) [14:56:23 CET] <faLUCE> DHE: then the demuxer simply discards null packets? [14:57:00 CET] <DHE> yeah. demuxer doesn't need the padding [14:59:02 CET] <faLUCE> DHE: then, why someone says that PCR is used for syncing audio and video?? [15:01:51 CET] <faLUCE> wait: the answer is "because their contents have different codec's rate". Then, it gives a common base (with higher rate) for both [15:04:19 CET] <DHE> PCR is only attached to one stream. I think video is most common. it's indicated in the PMT [15:04:33 CET] <DHE> the audio and video sync is maintained by the PTS/DTS of the individual streams [15:12:49 CET] <faLUCE> DHE: thanks for all the infos. Then PCR is only used for MUXING. It has nothing to do with decoding (well... demuxers are often called "decoders", today). For displaying the decoded pkts in the correct time order, the decoder only uses the timestamps (which are provided by the muxer too) [15:14:10 CET] <faLUCE> lot of sites say that PCR is used for syncing audio and video. This confused me a lot. PCR is only used for creating a constant muxrate stream [15:18:00 CET] <DHE> I disagree. Factually only one of the audio or video will have a PCR attached which gives it little use in synchronization [15:54:40 CET] <faLUCE> DHE: even if attached to both, it would not give help for sync, given that there are timestamps [15:55:42 CET] <faLUCE> DHE: anyway, if timestamps are not provided, it could be useful for sync [15:57:39 CET] <faLUCE> DHE: anyway, there's one thing that I don't understand. You said that PCR is used only by the muxer. Then, it's nonsense to send it, if the demuxer will not use it [16:00:32 CET] <faLUCE> I'm seeing that a mpegts demuxer should have a parser, which checks for pcr discontinuities [16:02:48 CET] <faLUCE> https://github.com/hepek/MPEG-TS [16:05:54 CET] <DHE> that's a software package for demuxing mpegts, sure. the sample application that uses the library detects that as a proof of concept, not because it's strictly necessary [16:06:15 CET] <DHE> mpegts format has built-in (albeit weak) discontinuity detection [16:08:46 CET] <faLUCE> but it's nonsense to send this packet if it has not to be used by demuxers [16:08:56 CET] <DHE> head [16:08:57 CET] <DHE> hit [16:08:58 CET] <DHE> keyboard [17:48:34 CET] <wget> Hello everyone. I'm trying to get the content of the RT video streamer of my ISP (as the latter does not support linux) in order to be able to watch the content I paid for. The content is HLS using AES encryption provided with a FAXKS server. [17:48:34 CET] <wget> When I try to download the M3U8 the latter contains a EXT-X-FAXS-CM tag containing garbage data (looks like base64, but this is actually AES content); [17:48:34 CET] <wget> When I use ffmpeg on that link, ffmpeg succeeds to detect a key file and points to an URL which answers by a 404. (do not know why, as I force my cookies to be resent) [17:48:34 CET] <wget> How can ffmpeg find that key server URL? Is it using the ERE? I thought the latter was only available for HTML5 HLS not HLS send via Adobe Flash. [17:49:17 CET] <wget> I can provide the output in private if you want. [17:50:31 CET] <BtbN> Sounds like a proprietary protocol extension [17:50:43 CET] <BtbN> so, it probably can't. [17:53:42 CET] <wget> BtbN: It doesn't seem like [17:53:54 CET] <wget> Here is the output I have [17:53:55 CET] <wget> https://gist.github.com/wget/d447a6120d6bc871ed70f572cbcd7e06 [18:25:50 CET] <wget> EXT-X-FAXS-CM was not containing AES content but PKCS7 encoded as base64; I was able to recover a full list of certificate chain from it [18:26:13 CET] <wget> But still not link to any https://license.<URL> [18:34:14 CET] <faLUCE> DHE: finally I got the meaning of the PCR. Sorry to say that it's not what you say (but I'm not polemic, I'm just discussing about it). It's sent by the muxer and received by the demuxer in order to keep in sync the muxer's and demuxer's clocks: http://www.ce.unipr.it/~petrolin/livestreamer/PCRs.gif [18:35:01 CET] <faLUCE> obviously, it can be used by the DEMUXER in order to set the latency of the received stream [18:37:29 CET] <faLUCE> from wikipedia: "Presentation time stamps have a resolution of 90kHz, suitable for the presentation synchronization task. The PCR or SCR has a resolution of 27MHz which is suitable for synchronization of a decoder's overall clock with that of the usual remote encoder, including driving TV signals such as frame and line sync timing, colour sub carrier, etc.[1]" [18:40:17 CET] <faLUCE> it's also a way to determine the receiver buffer size [18:41:07 CET] <DHE> right, but it's only any good if the transmitter is sending the PCRs on time which is a major component of what it does [18:43:58 CET] <faLUCE> DHE: I don't understand your last answer ("on time which is a major component of what it does") what do you mean? [18:45:01 CET] <DHE> in order to synchronize clocks, it's necessary that the transmission of the PCR arrive properly [18:45:08 CET] <kerio> do you guys know if there's some VNC server/client combination that uses h264 for compression [18:45:10 CET] <DHE> I mean, a 27 MHz PCR written into a file on disk does nobody much good [18:45:42 CET] <faLUCE> DHE: then, for HTTP it's pretty overkill [18:47:05 CET] <furq> kerio: i don't think so [18:47:34 CET] <DHE> faLUCE: like I said, fixed rate live streaming [18:47:47 CET] <faLUCE> DHE: so I have to remove this PCR from the ts header, when streaming HTTP mpegts [18:48:07 CET] <DHE> oh my god... [18:48:12 CET] <DHE> just leave it as-is. it's fine. [18:48:58 CET] <faLUCE> DHE: the issue is that when I stream video+audio it's fine. But when I stream audio only, the vlc receiver takes care about the received PCR, and does a mess [18:49:29 CET] <faLUCE> DHE: in fact, video ts have not the adaptation field, and NO pcr [18:49:57 CET] <faLUCE> so, vlc ignores the PCRs, when receiving audio+video [18:50:50 CET] <faLUCE> but when it receives audio only, it sees this adaptation field, and it messes up the pkts' latencies [18:51:32 CET] <faLUCE> well: the best solution should be that VLC ignores PCR when it decodes HTTP mpegts [18:51:55 CET] <faLUCE> but given that it doesn't, I have to remove the adaptation field from the mpegts audio packets [18:52:06 CET] <faLUCE> (with mplayer there's the same problem) [19:07:06 CET] <faLUCE> well, I just saw that my question was really NOT trivial: https://ffmpeg.org/pipermail/ffmpeg-devel/2016-February/189713.html [19:20:27 CET] <faLUCE> at this point I wonder if is there an option for setting VBR in audio mpegts-muxing, on libav. CBR (and adaptation field with PCR) is automatically set for mp2. [19:22:07 CET] <faLUCE> otherwise, I have to change the muxer format... what could I use instead of mpegts for HTTP audio/video streaming? [19:26:22 CET] <furq> do you have to use mpeg2 [19:26:25 CET] <furq> er, mp2 [19:26:55 CET] <faLUCE> furq: not necessarily [19:27:03 CET] <furq> you could try vbr aac [19:27:27 CET] <faLUCE> furq: does mpegts include this codec? [19:27:30 CET] <furq> yes [19:27:38 CET] <faLUCE> furq: thnks [19:27:39 CET] <furq> that's what hls uses [19:28:45 CET] <faLUCE> furq: I well understand why, at this point :-))) [19:29:18 CET] <furq> well i imagine that has more to do with the fact that apple spent a lot of money making the best aac encoder, and paying for an aac license [19:29:28 CET] <furq> but maybe the pcr thing was a factor too [19:30:24 CET] <JEEB> I'm pretty sure Apple licenses its AAC encoder? [19:30:28 CET] <faLUCE> furq: I thought it was open source [19:30:29 CET] <JEEB> from dolby or so? [19:31:17 CET] <faLUCE> is there anything more open than AAC that can be used for audio? [19:31:17 CET] <faLUCE> maybe vorbis? [19:31:31 CET] <JEEB> AAC is fully open as a format [19:31:36 CET] <JEEB> opus is the latest addition [19:31:47 CET] <JEEB> in the audio formats, and officially supported in MPEG-TS [19:31:53 CET] <JEEB> although not many clients support it there [19:31:53 CET] <JEEB> yet [19:31:58 CET] <faLUCE> I understand. [19:32:09 CET] <faLUCE> then apple's implementation != ffmpeg implementation? [19:32:24 CET] <JEEB> apple uses whatever is used in QT, which is I think licensed from somewhere [19:32:37 CET] <JEEB> and FFmpeg can use various encoders through lavc [19:34:43 CET] <furq> i don't work for apple but i've read they developed it themselves [19:35:13 CET] <furq> http://wiki.hydrogenaud.io/index.php?title=Apple_AAC [19:35:19 CET] <furq> wouldn't surprise me if dolby were involved in some way though [19:41:31 CET] <thebombzen> what is this HLS thing that is all the hype of kids these days [19:42:19 CET] <furq> https://en.wikipedia.org/wiki/HTTP_Live_Streaming [19:42:50 CET] <furq> i wouldn't call it hyped, it's just the least shitty option in the septic tank that is the web [19:42:51 CET] <thebombzen> I read that, but Wikipedia is pretty bad about giving explanations to someone who isn't already familiar [19:43:12 CET] <furq> it serves mpegts fragments over http and your browser can play it without too much fucking around [19:43:27 CET] <__jack__> HLS is just an easy way of stream video over an existing efficient & common infrastructure [19:43:33 CET] <thebombzen> Well I got that, but it doesn't say a lot of things, like why is it Apple-oriented [19:43:33 CET] <furq> without the need for flash or whatever the fuck you even need to do to get mpeg-dash to work [19:43:42 CET] <furq> because apple made it for streaming to iOS [19:43:51 CET] <furq> don't ask me why [19:44:01 CET] <thebombzen> I mean sure Apple made it but Wikipedia doesn't explain why Apple's thing is the "best one" [19:44:05 CET] <__jack__> because nothing sane exists ? :) [19:44:15 CET] <furq> the only alternative that's widely supported by browsers is mpeg-dash [19:44:33 CET] <furq> and that's not and will never be supported by iOS, for mysterious reasons no mortal can comprehend [19:44:36 CET] <furq> so you're stuck with HLS [19:44:43 CET] <furq> which thankfully is at least fairly simple [19:44:51 CET] <thebombzen> Well "will never be supported by iOS" is extremely common [19:44:54 CET] <thebombzen> and really never a surprise [19:44:55 CET] <__jack__> owh, that's easy to understand : mpeg-dash is insanity [19:44:57 CET] <furq> yeah [19:45:00 CET] <c_14> Apple is special [19:45:01 CET] <__jack__> crazy stuff, that's it [19:45:05 CET] <thebombzen> examples: Ogg, Vorbis, FLAC, Opus [19:45:28 CET] <furq> __jack__: that would be a better reason if apple didn't secretly support mpeg-dash for netflix.com [19:45:33 CET] <thebombzen> You still can't use vorbis or opus music in iTunes synced to iOS [19:45:34 CET] <__jack__> I mean: look at the HLS format, and the dash format. Try to find some docs about both. You'll soon understand why HLS rulz dash :) [19:45:38 CET] <furq> but they do. they have a working implementation of it [19:45:52 CET] <furq> they just won't let you use it unless you're on the whitelist, and the whitelist consists of one huge company who told them to get fucked [19:45:59 CET] <thebombzen> I don't understand why you can't use FLAC, Vorbis, or Opus in iTunes/iOS [19:46:05 CET] <__jack__> furq: yep, that's apple :'( [19:46:07 CET] <furq> because google use opus [19:46:09 CET] <thebombzen> it's like Apple said "Fuck Xiph" [19:46:09 CET] <furq> that's why [19:46:15 CET] <thebombzen> this predates Opus [19:46:29 CET] <thebombzen> they refused to use Vorbis/Ogg/flac before Opus existed [19:46:33 CET] <thebombzen> like 8 years ago [19:46:38 CET] <furq> no browser supported flac until very recently [19:46:47 CET] <furq> and vorbis was never widely used [19:46:51 CET] <thebombzen> Forget browser [19:47:18 CET] <thebombzen> as far back as 2009 I had lossless CD rips as FLACs and I had to convert them to ALAC to sync them to my iCrap [19:47:46 CET] <furq> well yeah they have their own competing format [19:47:54 CET] <furq> remember they didn't let you use mp3s on ipods originally, you had to use aac [19:48:05 CET] <thebombzen> that makes even less sense [19:48:11 CET] <furq> that's apple [19:48:14 CET] <thebombzen> given that AAC and MP3 are both MPEG1/2 standards [19:48:28 CET] <thebombzen> but even still not supporting flac doesn't really make sense given that libFLAC is BSD-licensed [19:48:41 CET] <thebombzen> the CLI is GPLed but like so what [19:49:35 CET] <furq> it's just more vendor lock-in [19:49:37 CET] <__jack__> I guess it's easier to made working software and good integration with as few tech as possible [19:49:54 CET] <furq> most people would probably struggle to convert their alac to flac [19:50:14 CET] <furq> at least back when alac support was less common outside of apple world [19:51:04 CET] <furq> in summary, apple are dicks [19:51:12 CET] <furq> that's usually the answer [19:51:22 CET] <thebombzen> well converting alac to flac is easy tho [19:51:27 CET] <thebombzen> ffmpeg -i input.m4a output.flac [19:51:28 CET] <furq> sure it is [19:51:30 CET] <thebombzen> it's almost like [19:51:31 CET] <__jack__> people loves dicks [19:51:33 CET] <thebombzen> there's a program for this [19:51:39 CET] <__jack__> wait, that explains everything .. ! [19:51:49 CET] <thebombzen> I'm not particularly a fan of dicks [19:51:54 CET] <furq> i'm sure your average iOS user is a proficient ffmpeg user too [19:52:06 CET] <thebombzen> lol [19:52:24 CET] <thebombzen> you don't need to be a proficient ffmpeg user to know how to do "ffmpeg -i input.m4a output.flac" [19:52:25 CET] <furq> and they won't end up converting it with "jimmysoft.ru ultimate alac to flac conversion master 2000 FREE EDITION" [19:52:28 CET] <thebombzen> but then again [19:52:37 CET] <thebombzen> knowing what a CLI is helps [19:52:45 CET] <thebombzen> lol furq [19:53:02 CET] <thebombzen> it's like "YouTube Downloader Audio Ripper Master Converter" [19:53:20 CET] <thebombzen> when it's really just a gui for "youtube-dl -x" [19:53:47 CET] <furq> my old flatmate who was reasonably good with computers had a million of those "mp4 to docx" converters which were clearly just sponsored links at the top of google results for "convert x to y" [19:54:20 CET] <c_14> mp4 to docx? This I want to see. [19:54:27 CET] <furq> google it [19:54:30 CET] <furq> jimmysoft.ru has got your back [19:54:50 CET] <furq> also there's no way any of these tools would use anything as good as youtube-dl [19:55:46 CET] <thebombzen> well some of these tools use pretty good tools [19:56:04 CET] <thebombzen> AVS was a big one a few years ago and remember that AVSH264Codec.dll was just x264 but renamed [19:56:15 CET] <furq> it's all some bulgarian student's first year university project which he's now charging 200 lev for and bundling with the google toolbar and ILOVEYOU.VBS [19:56:37 CET] <thebombzen> I think I got that joke [19:57:13 CET] <thebombzen> I was under the impresion though that students who are learning to develop in their first year at uni will never be good programmers [19:57:20 CET] <furq> well yeah [19:57:56 CET] <thebombzen> people who learn to program during uni first year are usually the sort of people who write tumblr's website [19:58:06 CET] <thebombzen> it's shocking how awful my CS peers are at code [19:58:24 CET] <thebombzen> hell I'm a mathematician and I write better code than most of the CS majors I talk to [19:58:25 CET] <furq> but a good programmer would just tell you to use ffmpeg instead of trying to charge 100 koruny for a tool they wrote in turbo pascal which converts gif to rmvb [19:58:49 CET] <thebombzen> hey, I'll let you know that I wrote a graphical program (backed by ffmpeg) that converts video to GIF lmao [19:59:24 CET] <thebombzen> bbut it abstracts away all the annoyances like ending up with a 70 MB GIF file so it does the binary search for you so it ends up under 2 MB [19:59:28 CET] <furq> i'm not saying that's an inherently bad thing [19:59:34 CET] <thebombzen> lol [19:59:41 CET] <thebombzen> yea but at least I admit mines' backed by ffmpeg [19:59:42 CET] <furq> just that there are many bad ones, and that's inevitably what people find on google [19:59:45 CET] <thebombzen> lol [19:59:52 CET] <furq> yeah you're already disqualified by actually using libavcodec [20:00:01 CET] <thebombzen> mines pretty trash lol [20:00:16 CET] <thebombzen> it's not backed by avcodec, it's backed by ffmpeg.c [20:00:19 CET] <thebombzen> GUI written in Java [20:00:24 CET] <thebombzen> piece of shit software amirite [20:00:42 CET] <thebombzen> this is before I decided I'd abandon that terrible language [20:00:55 CET] <furq> i tried searching for "mp4 to mkv converter" and ublock won't let me visit any of the links [20:01:00 CET] <thebombzen> XD [20:01:51 CET] <thebombzen> but yea here's my thing #shameless self promotion https://thebombzen.github.io/TumblGIFifier/ [20:01:54 CET] <thebombzen> look at my terrible Java code [20:02:28 CET] <furq> is there any other type of java code [20:03:04 CET] <c_14> There's the kind that was never written. [20:03:24 CET] <furq> http://www.aviosoft.com/tips/wp-content/uploads/Aviosoft-video-converter-MP… [20:03:36 CET] <furq> i knew google wouldn't let me down [20:05:25 CET] <thebombzen> this is my favorite part tbh: https://github.com/thebombzen/TumblGIFifier/blob/master/src/thebombzen/tumb… [20:05:39 CET] <thebombzen> this language is a piece of crap [20:07:56 CET] <furq> nice comments [20:09:00 CET] <furq> is there some compelling reason to not just make e and f public [20:09:00 CET] <JEEB> thebombzen: you should try out kotlin [20:09:19 CET] <JEEB> it makes java environment feel saner a bit [20:09:33 CET] <JEEB> also you can move to kotlin part by part [20:09:42 CET] <JEEB> instead of having to completely switch a language [20:11:19 CET] <furq> i would make a smug "you should use x" suggestion but if you need a gui your only sensible choice is C++ [20:11:23 CET] <furq> and i can't recommend that [20:14:22 CET] <JEEB> nowadays the funky way to do a GUI seems to be to bundle chromium and add JS links to native code [20:14:30 CET] <JEEB> and do the GUI in HTML5+JS [20:16:24 CET] <furq> i don't think james brown would agree with you [20:17:32 CET] <JEEB> for many purposes as much as I dislike the idea it seems to be a passable way to do it [20:18:31 CET] <furq> was it spotify which was doing that and it turned out it was doing thousands of disk writes [20:18:53 CET] <furq> yeah it was [20:19:10 CET] <furq> cref was constantly running sqlite vaccum and doing ~100GB of disk writes every day [20:19:39 CET] <furq> vacuum [20:20:26 CET] <furq> "I just checked, and Task Manager says Spotify has written over 1TB in the past 15 days. I've played maybe 5 songs on this computer during that time." [20:23:15 CET] <faLUCE> JEEB: what would you do otherwise? Write and update GUIs for many platforms? it's a complete waste of time. Javascript is the only really portable language that I know, and with SVG you can realize excellent things [20:23:39 CET] <faLUCE> I don't write standalone GUI since 5 years [20:24:03 CET] <JEEB> Qt does the multiplatform thing well enough. although I must say that the barrier of entry is most likely lower with the HTML5+CSS+JS solution [20:24:21 CET] <JEEB> I'm just saying that I personally don't like it as much, but I must give it what's due [20:24:52 CET] <JEEB> it's much simpler to find your web jockies to make up a nice thing than UI coders capable of Qt et al [20:25:34 CET] <faLUCE> JEEB: Qt is multiplatform, but you have to update your GUI many times [20:26:28 CET] <faLUCE> this is bad [20:26:31 CET] <JEEB> I've had the exactly same code work on desktops as well as android, so I don't consider it any different from making your HTML5+CSS thing capable of resizing [20:26:48 CET] <JEEB> whatever the newfangled way of saying that is [20:27:19 CET] <JEEB> also do note that I'm not fighting for anything here, I have my personal preferences and that's it. I've already noted that the HTML5+CSS+JS way is most likely the thing with the lower barrier of entry [20:27:51 CET] <faLUCE> JEEB: you have the same code that works for many platforms now, but with js+svg the same code will work for many platforms forever [20:29:18 CET] <faLUCE> IMHO the absurdity is when you make server side js applications (nodejs) [20:36:18 CET] <furq> what if you care about your code not using a disgusting amount of memory [20:38:18 CET] <faLUCE> furq: listen.... today svg+js work perfectly on very cheap mobile phones [20:38:38 CET] <furq> well yeah they're using the system webview which everything on the device uses [20:38:55 CET] <faLUCE> if you want to do embedded stuff, then you have to do specific gui with specific libs [20:38:57 CET] <furq> they're not bundling 80MB of dlls for a hello world app [20:39:26 CET] <furq> if you're talking about an actual webapp which runs in my browser then sure [20:39:45 CET] <furq> but if you make it standalone then it's going to suck on desktops [20:40:56 CET] <faLUCE> furq: I used wxwidgets in the past, with a very very very minimal amount of memory. But today I'm not wasting my time in these things [20:41:03 CET] <faLUCE> I just don't have time [20:41:10 CET] <JEEB> well wxwidgets is the one thing that seems nice at first [20:41:22 CET] <JEEB> but then you drown in "fixing a bug for each OS" [20:41:29 CET] <faLUCE> JEEB: exactly [20:41:38 CET] <faLUCE> and with Qt, more or less the same [20:41:44 CET] <faLUCE> (you will not agree) [20:42:05 CET] <furq> i also like the way those libs insist on rewriting the entire stdlib, which makes them awful to use from scripting languages [20:42:08 CET] <JEEB> less but I do agree :P I mean, all of those things will have *some* bugs [20:42:21 CET] <JEEB> which are OS/arch specific [20:42:38 CET] <JEEB> and if you go low enough you will be trying to unfuck chromium on embedded [20:42:47 CET] <furq> everything sucks at some point in the chain [20:43:13 CET] <furq> i'd like to think i'd take the hit for a better user experience, but the reality is that i just don't write any gui stuff because it's all horrible [20:43:32 CET] <furq> on which note, i wonder if libui is usable yet [20:43:38 CET] <JEEB> wx is just the one that promises a lot ("we're using the native thing for each OS!"), but which will end up your crappiest alternative [20:44:04 CET] <furq> wx is certainly the one i like most as a user [20:44:04 CET] <JEEB> well, not crappiest but you know what I mean [20:44:13 CET] <furq> and i've had reasonable luck using it, although i didn't use it for anything major [20:44:22 CET] <JEEB> you can try talking about wx to Myrsloik [20:44:29 CET] <JEEB> he probably has PTSD for it [20:44:30 CET] <furq> and i never tested it on OSX which i bet is always the odd one out [20:44:36 CET] <JEEB> yup [20:45:43 CET] <faLUCE> 6 years ago wx was the only choice for embedded stuff [20:45:55 CET] <furq> the guy who wrote bsnes had a promising libui-style lib but he's taken it offline now [20:46:06 CET] <furq> or whatever bsnes is called now [20:46:35 CET] <furq> probably ispeakjapanese.exe [20:51:31 CET] <faLUCE> " The encoder 'aac' is experimental but experimental codecs are not enabled" . I added avctx->strict_std_compliance > FF_COMPLIANCE_EXPERIMENTAL but still get the error [20:56:03 CET] <c_14> shouldn't it be < ? [20:57:04 CET] <JEEB> faLUCE: well I'd say your first attempt would be to see if your thing still runs with newer FFmpeg :P [20:57:10 CET] <JEEB> that has the AAC encoder improvements [20:57:22 CET] <JEEB> otherwise you ain't going to have as much fun [20:59:09 CET] <faLUCE> JEEB: I had to workaround that with audioEncoderCodecContext->strict_std_compliance = -2; [20:59:53 CET] <JEEB> that requirement was removed in newer FFmpeg after the improvements to the AAC encoder [21:00:02 CET] <JEEB> and atomnuker did work on it a lot :P [21:05:27 CET] <faLUCE> now. This coded doesn't like AV_SAMPLE_FMT_S16. which format should I use? should I resample too? [21:05:33 CET] <faLUCE> codec* [21:06:07 CET] <JEEB> it just takes in float I guess [21:06:18 CET] <JEEB> you shouldn't have to make other adjustments [21:07:20 CET] <faLUCE> it doesn't allow to open the codec, with this format [21:07:40 CET] <JEEB> yes, because it requires another one. use avresample or swresample to resample if you don't want to use something else [21:07:47 CET] <JEEB> that lets you convert between audio formats [21:09:36 CET] <faLUCE> then resample from AV_SAMPLE_FMT_S16 to AV_SAMPLE_FMT_FLT [00:00:00 CET] --- Sun Jan 29 2017

1 0

ffmpeg-devel.log.20170127
by burek 28 Jan '17

28 Jan '17

[00:49:46 CET] <kierank> atomnuker: afaik no [00:50:08 CET] <kierank> (yes this makes opus weird) [00:50:41 CET] <atomnuker> nah, its cool, my encoder behaves normally [00:50:57 CET] <kierank> You can't make the user do that though [00:51:03 CET] <kierank> If that's what you're asking [00:51:24 CET] <atomnuker> no, I was just wondering, doesn't matter though since my code still works [00:51:34 CET] <kierank> Ah [00:52:04 CET] <kierank> Do you set codec->frame_size to the lowest opus frame length? [00:52:28 CET] <kierank> And then buffer input and output packets when you want? [00:52:46 CET] <atomnuker> yeah, you feed it in 120 sample frames and depending on the lookahead it'll output variable sized encoded frames [00:52:52 CET] <kierank> Ah good [00:52:58 CET] <kierank> That's the correct way :) [00:53:52 CET] <atomnuker> av_frame_clone()s the input avframes into a bufferqueue and then frees them when it finishes with them [00:54:17 CET] <atomnuker> cloning just refs the actual data planes so no copying, it works great [00:54:35 CET] <cone-619> ffmpeg 03Michael Niedermayer 07master:f28299da8d06: avcodec/h264dec: Clear ref_count on slice header processing failure [00:58:30 CET] <atomnuker> the audioframequeue is awesome since it doesn't require the #input to match the #output samples nor the #frames to match [00:59:10 CET] <atomnuker> you just ask it to remove #amount of samples from the buffer and it doesn't care, it'll just set the packet frame size and duration correctly [01:05:50 CET] <kierank> I never really understood audioframequeue [01:08:32 CET] <atomnuker> it just sets the output packet pts and duration, nothing more [08:36:22 CET] <cone-343> ffmpeg 03Carl Eugen Hoyos 07master:fca30832828a: lavf/img2dec: Reduce the probe score for incomplete jpgs. [10:47:42 CET] <Traktorrr> Hi people [10:52:46 CET] <Traktorrr> we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1 [10:53:46 CET] <Traktorrr> Now we need to get more, and the phase between audio channels, left and right is it possible? [11:08:45 CET] <Traktorrr> i need heeeeelp!!! [11:26:25 CET] <Traktorrr> nu suki ebanie [11:26:30 CET] <Traktorrr> shnelya [11:26:43 CET] <Traktorrr> hendehog [11:26:52 CET] <Traktorrr> fuck you spilberg [11:34:33 CET] <Traktorrr> Hi people [14:53:29] 9Traktorrr: we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1 [14:54:29] 9Traktorrr: Now we need to get more, and th [11:34:51 CET] <Traktorrr> Now we need to get more, and the phase between audio channels, left and right is it possible? [11:38:53 CET] <Polochon_street> wm4: about the ID3 tags issue, I'm not really a specialist about ffmpeg's innards, but I'd like to give a try to correct mp3dec.c . The idea would be to keep the previous modification, and to do what you said in mp3dec.c to avoid the nasty side-effects Michael talked about? [11:42:20 CET] <durandal_1707> atomnuker: i got some outlht with fft but samples do not line up, there is spike each 128 samples [11:47:20 CET] <atana> michaelni: I have problem understanding the valgrind message https://dpaste.de/LheE where is the problem at line 125 in https://github.com/atana1/FFmpeg/blob/master/libavfilter/af_peakpoints.c [11:50:31 CET] <Traktorrr> the ebur filter displays LUFS, DBFS necessary to us rovn of signals how to force it to display a phase??? [11:50:57 CET] <Traktorrr> the ebur filter displays LUFS, DBFS levels of signals necessary to us how to force it to display a phase??? [11:51:04 CET] <atomnuker> durandal_1707: each frame is 1024, right? a spike each 128 samples might mean there's a transient and they store the coeffs like [frame0_sample0...frame0_sample127] [frame1_sample0...frame1_sample127], etc. [11:51:27 CET] <atomnuker> *coeffs, not samples [11:51:51 CET] <atomnuker> or were you talking about the samples as in the samples you get after an inverse transform? [11:52:02 CET] <durandal_1707> there is 128 im and re coeffs [11:52:14 CET] <durandal_1707> yes after ifft [11:52:35 CET] <atomnuker> is it an imdct or an ifft you have to do? [11:53:21 CET] <durandal_1707> ifft [11:53:45 CET] <durandal_1707> sox uses sonething called dft [11:54:31 CET] <atomnuker> that's quite odd, I thought atrac9 was fully mdct based [11:55:29 CET] <atomnuker> you still do windowing, right? a spike each x samples could indicate you're not windowing correctly [11:59:32 CET] <JEEB> gotta love those probing functions, I guess? :3 [11:59:47 CET] <durandal_1707> atomnuker: i'm talking about new fir filter in lavfi, atrac9 is for later [11:59:57 CET] <JEEB> oh, atrac9? najs [12:00:09 CET] <JEEB> I was thinking of poking that at some point [12:01:07 CET] <durandal_1707> JEEB: you want to write decoder? [12:01:20 CET] <JEEB> I have other things to finish first :) [12:01:38 CET] <JEEB> some of which have been WIP since 2012, so... yeah. not high on my priority list [12:01:43 CET] <JEEB> so feel free if you're quicker [12:03:21 CET] <atomnuker> durandal_1707: we have an rdft too, did you see if you can use it? [12:04:11 CET] <durandal_1707> hmm [12:12:50 CET] <ubitux> atana: avc is uninitialized [12:14:42 CET] <mateo`> am i correct saying that there is no neon code for aarch64 for the simple idct code in libavcodec ? [12:15:08 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:29fbce8f8125: doc/filters: mention recently added option [12:16:38 CET] <mateo`> by "simple idct code" i mean ff_simple_idct_{add,put} [12:17:33 CET] <mateo`> I guess I'll work on that for the upcoming days [12:18:26 CET] <wm4> Polochon_street: yes, that's what I'm thinking about [12:19:09 CET] <wm4> Polochon_street: I'm not sure if it'll lead to success - there's always the possibility something else fucks it up, but I think the idea is the right thing and worth pursuing [12:19:26 CET] <atomnuker> mateo`: there isn't much aarch64 simd [12:19:40 CET] <atomnuker> besides, there are no machines you can run and compile code for that [12:20:05 CET] <atomnuker> since there are processors but few distributions support them [12:20:27 CET] <wm4> Polochon_street: the mp3dec.c case is because it expects the id3v2 metadata in AVStream.metadata for various reasons, and there's code to read an id3v1 tag too (which uses the same logic as your code - if AVStream.metadata is not empty, skip it) [12:20:29 CET] <atomnuker> and the ones which are supported use some ancient modified obscure distro and cost hundreds of bucks [12:20:55 CET] <wm4> no aarch64 on rpi3 yet? [12:20:56 CET] <mateo`> atomnuker: i use an rpi3 running arch linux in aarch64 mode for development [12:21:10 CET] <atomnuker> you can run arch on aarch64 now? [12:21:15 CET] <mateo`> yes [12:21:19 CET] <Polochon_street> wm4: alright, that makes sense. I'll investigate today, thanks for the hints :) [12:21:43 CET] <wbs> there's the $15 pine64 and $40 odroid c2 as well, both readily available [12:22:12 CET] <wbs> so aarch64 devboard sure are available and pretty cheap these days, and the out-of-the-box distros on them work just fine [12:22:32 CET] <wm4> I know odroid c2 has a better CPU than rpi3 but a worse video API [12:23:03 CET] <wbs> wm4: their cpus should be pretty much identical afaik, both are quad a53 [12:23:27 CET] <wm4> "oh" [12:23:49 CET] <michaelni> atana, the problem is that the avc variable used is not initialized, you define it as "void *avc;" [12:24:25 CET] <wbs> the rpi3 aarch64 support is a bit icky though since it's mostly based on vanilla-linux which isn't quite as well optimized on rpi hardware as the raspberrypi foundation kernels [12:24:35 CET] <michaelni> atana, av_log() treats the avc variable as a struct containing an AVClass pointer at its first field [12:25:12 CET] <michaelni> and tries to access that AVClas pointer (which fails as its not a struct or anything just a uninitialized void pointer) [12:26:59 CET] <ubitux> atomnuker: arch aarch64 also available on odroid c2, which i use [12:27:09 CET] <wbs> and as for hardware needing aarch64 asm; all modern iphones in the last 3 years run in 64 bit mode, and most high-end android devices since the last 1-2 years as well [12:27:10 CET] <michaelni> atana, you can use the AVFilterContext a first argument to av_log() it has a AVClass pointer [12:28:43 CET] <atomnuker> wbs: yeah, I know about the iphone, but I thought everything else was just crap [12:28:59 CET] <atomnuker> is there a board which can run a vanilla distribution though? [12:29:21 CET] <wbs> atomnuker: both yes and no [12:29:41 CET] <wbs> atomnuker: due to the differences in arm socs, you very very seldom can take a "stock vanilla" kernel and bootloader and expect it to work on anything [12:30:04 CET] <wbs> booting is really almost device specific in all cases, so you at least want a device-specifically packaged distro [12:30:35 CET] <wbs> but within that, you can in most cases run a vanilla distro. on rpi you can use plain debian or ubuntu if you want to [12:30:44 CET] <rcombs> not on IBM® PC"-compatible devices! [12:30:49 CET] <atomnuker> damn, so after a few years the distribution you're using dies out you just have to look for something new? [12:31:06 CET] <atomnuker> I had that happen to me 3 fucking times with the rpi when it came out [12:31:31 CET] <wbs> which distros died out? [12:32:01 CET] <atomnuker> there was a very nice cut down yet featured enough server distribution, I forgot its name [12:32:09 CET] <wbs> ah right [12:32:28 CET] <atomnuker> and it was up to date compared to rasbian [12:32:36 CET] <JEEB> yeah, ARM-specific ones tend to die easily [12:32:42 CET] <atomnuker> which fucking sucks because rasbian is staler than 3 year old bread [12:32:53 CET] <JEEB> I hear fedora should nowadays have rpi3 64bit thing? [12:32:56 CET] <JEEB> officially [12:33:07 CET] <atomnuker> heh, there was also the pidora [12:33:23 CET] <wbs> I'm a bit curious about that, since last I saw all rpi3 64 bit kernels were based on one guys hacks from april last year, which hasn't seen any work since [12:33:39 CET] <JEEB> I think rpi3 64bit stuff got in around 4.9 or so? [12:33:47 CET] <JEEB> and fedora is now officially on 4.9.* with fc25 [12:33:51 CET] <wbs> oh, nice then [12:34:02 CET] <JEEB> so in theory the pieces are in there [12:34:03 CET] <ubitux> not much is working on aarch64 with rpi3 [12:34:13 CET] <ubitux> it's good enough for ffmpeg development though [12:34:32 CET] <wbs> in any case, the rpi works much better with a raspberrypi foundation kernel (which is 32 bit only) than with the upstream-vanilla-kernels [12:34:44 CET] <ubitux> and odroid c2 seems to still lack proper mainline support too afaict [12:34:51 CET] <JEEB> yea [12:35:03 CET] <wbs> probably yeah. so if vanilla kernel is a must, then rpi probably is at least somewhat working [12:35:54 CET] <JEEB> also suse seems to have their enterprise distro running aarch64 on rpi3 [12:36:21 CET] <JEEB> I've been looking at the stuff recently because I want to get my rpi3 out of the box again after moving :) [12:37:31 CET] <atomnuker> I'm looking for something aarch64 with a usb-3 port and gigabit ethernet, is there a monster like that out which won't break the bank? [12:38:31 CET] <mateo`> isn't the odroid c2 what's your looking for ? [12:38:43 CET] <mateo`> oh usb-3 port, nvm ... [12:39:51 CET] <atomnuker> the pine64 (even though it doesn't have a usb-3 port) looked nice but then I saw allwinner [12:39:58 CET] <atomnuker> I'm staying well away from allwinner [12:40:40 CET] <atomnuker> the odroids are imo highly overpriced and if you buy them from an official distributor here they become grossly overpriced [12:41:48 CET] <ubitux> the arm world is very much tied to the mobile world [12:41:55 CET] <ubitux> it means everything is shit [12:42:07 CET] <ubitux> and you'll have to deal with bad treadoff [12:42:33 CET] <wm4> yeah [12:42:55 CET] <wm4> and usually multimedia things will only work with android, if at all [12:43:07 CET] <ubitux> currently my arch odroid is running 3.14 [12:43:19 CET] <ubitux> and the rpi3 is running a broken mainline one [12:43:47 CET] <ubitux> the rest of my arm boards are various armv7 crap in various flavour [12:44:43 CET] <mateo`> ubitux: doesn't your beagle bone board run arch with a mainline kernel ? [12:45:08 CET] <ubitux> yes but not aarch64 [12:45:17 CET] <mateo`> indeed [12:45:37 CET] <wbs> yeah, TI stuff had surprisingly good things merged upstream, while they still cared [12:46:16 CET] <ubitux> the cubieboard garbage board is also mainline [12:46:53 CET] <ubitux> (allwinner) [12:47:41 CET] <Polochon_street> michaelni: hi, could I please have the mp3_demuxer_EOI.mp3 file you used on the duplicate ID3 to show the regression so that I can test if I fixed it? [12:49:00 CET] <wm4> hm would have thought it's part of FATE, but apparently not [12:50:01 CET] <atomnuker> meh, I'll just get an odroid c2 [12:52:55 CET] <michaelni> Polochon_street, see http://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket4003/ [12:53:06 CET] <ubitux> atomnuker: hope you're fine with running 3.14 [12:53:12 CET] <Polochon_street> thank you! [12:53:23 CET] <michaelni> also if someone can make it a bit shorter ad still reproduce all issues i can upload it to fate [12:53:32 CET] <atomnuker> ubitux: even on arch? [12:53:35 CET] <ubitux> yes [12:53:51 CET] <atomnuker> ugh, maybe not [12:53:55 CET] <ubitux> :) [12:54:15 CET] <ubitux> the alternative is rpi3 which is a non working mainline kernel [12:54:18 CET] <ubitux> pick your poison [12:54:24 CET] <atomnuker> how non-working is it? [12:54:37 CET] <ubitux> barely manage to work without video display [12:54:49 CET] <wbs> apparently, according to JEEB, it's pretty ok-ish around 4.9 or so [12:54:56 CET] <atomnuker> hm, that's not too bad [12:55:03 CET] <wbs> to the point that fedora ships something based on it [12:55:06 CET] <ubitux> my dmesg is flooded with "i2c-bcm2835 3f805000.i2c: i2c transfer failed: 100" currently [12:57:40 CET] <ubitux> wbs: pretty sure you can't use it for desktop though [12:57:49 CET] <ubitux> not sure you can even manage to have a display [12:58:28 CET] <JEEB> I just overheard the fedora statement, and I have no idea how many patches they have on top for aarch64 [12:58:32 CET] <atomnuker> huh, apparently the c2 also is almost supported by the kernel's git master [12:58:44 CET] <wbs> ubitux: ok [12:59:06 CET] <ubitux> https://news.opensuse.org/2016/12/05/opensuse-leap-42-2-gets-64-bit-raspber… [12:59:08 CET] <ubitux> this is the news [12:59:09 CET] <JEEB> seems like officially they'll be supporting aarch64 with fc26 [12:59:23 CET] <JEEB> ubitux: yeah - I mentioned suse already doing the aarch64 game [12:59:25 CET] <ubitux> > which means that some not-yet-supported upstream features like HDMI-audio and hardware-accelerated-video decoding are not available yet in the image. [12:59:42 CET] <ubitux> basically it's useless for a lot of things and it's likely to last [13:00:00 CET] <ubitux> because no official support as the company behind is worse than satan and comcast together [13:00:21 CET] <JEEB> le broadcom face [13:00:23 CET] <ubitux> i still have some hope for c2 mainline though [13:00:44 CET] <ubitux> but i'm pretty sure rpi3 is a lost cause overall [13:01:05 CET] <ubitux> atomnuker: any idea what's missing btw? [13:01:43 CET] <ubitux> i remember some stuff going in around 4.4 but that's all [13:03:08 CET] <ubitux> atomnuker: did you also check the pine64? [13:03:25 CET] <ubitux> i remember looking at that one a while ago, don't remember the outcome [13:04:12 CET] <ubitux> allwinner though [13:08:10 CET] <wm4> <ubitux> because no official support as the company behind is worse than satan and comcast together <- which one? [13:08:18 CET] <ubitux> broadcom [13:08:37 CET] <wm4> well RPI support and APIs are relatively good [13:08:40 CET] <wm4> for ARM/Linux garbage [13:08:59 CET] <ubitux> 32-bit only [13:09:07 CET] <atomnuker> ubitux: the pine64 is allwinner and I dislike allwinner worse than broadcom [13:09:29 CET] <wm4> most people are more interested in being able to do anything with the device (other than compiling stuff) [13:09:59 CET] <ubitux> 32-bit proprietary userland they don't want to port to 64-bit [13:10:27 CET] <ubitux> really love how rpi was sold as a soc with a "64-bit cpu" [13:12:54 CET] <JEEB> yup [13:16:41 CET] <atomnuker> ubitux: ordered a c2, I like to be optimistic (besides for now it'll do the job of exposing my external hdd to the network) [13:18:08 CET] <ubitux> don't forget to set nographic to 0 [13:18:16 CET] <ubitux> to 1* sorry [13:18:23 CET] <ubitux> or you'll get random kernel traces [13:18:25 CET] <ubitux> ;) [13:18:31 CET] <ubitux> (arm always a lot of fun) [13:21:03 CET] <phh> for people interested in ARM boards, I recommend rockchip's SoCs. they are mostly mainlined, the VPU code is open-source (though only "real" API supported is gstreamer at the moment), the only binary blob needed is for the GPU, but it's mali, so ARM is maintaining it [13:24:31 CET] <Polochon_street> wm4: alright, after diving a bit inside the files, I understand that the problem was, as you said, « with the patch, idv3 metadata are not written in the s->metadata field, causing ff_id3v1 read to be triggered, filling s->metadata and preventing the later copy of the id3v2 tags », right? [13:25:11 CET] <wm4> Polochon_street: yes [13:37:30 CET] <Polochon_street> wm4: what you had in mind was to create an id3v2-dedicated stream in utils.c, and then checking it in mp3_read_header to skip (or not) the id3v1 read? [13:38:43 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:836c8750b313: avfilter/avf_showspectrum: fix 2 possible crashes [13:44:03 CET] <durandal_1707> michaelni: how i can avoid stupid hook that disallows commiting text files with trailing whitespaces? [13:44:48 CET] <wm4> Polochon_street: I meant adding an internal AVDictionary field somewhere, which contains the id3v2 contents [13:46:36 CET] <Polochon_street> inside of the s AVFormatContext you mean? We could also check if the format name is "mp3" and then do a direct ff_id3v2_read(), but that's *really* dirty [13:47:01 CET] <michaelni> durandal_1707, i think merges are exempt from it, also some file types possibly are [13:48:01 CET] <michaelni> the hook is on the videolan server [13:48:28 CET] <durandal_1707> just remove the hook [13:49:11 CET] <wm4> Polochon_street: yeah, I think we shouldn't do such format checks [13:49:20 CET] <Polochon_street> definitely [13:49:27 CET] <wm4> Polochon_street: yes in AVFormatContext, or the internal associated struct [13:49:53 CET] <michaelni> durandal_1707, if you need changes to the hook(s) talk with jb or thresh [13:50:19 CET] <wm4> Polochon_street: AVFormatInternal, accessible via AVFormatContext.internal [13:50:51 CET] <Polochon_street> okay, thanks for this, I'll try to do something! [14:16:19 CET] <Polochon_street> wm4: after looking a bit, it seems more logical to do a flag like id3v2_had somewhere, and to check it in mp3_read_header before ff_id3v1_read(), isn't it? I've looked for a place in AVFormatContext to put this flag, but I can't find anywhere suitable, even in AVFormatInternal :/ [14:16:49 CET] <wm4> Polochon_street: that won't work, mp3dec.c also reads/writes from the id3v2 tags in other places [14:20:38 CET] <Polochon_street> ok, so that would be more like « storing id3v2 AVDictionary somewhere, check for it at the beginning of the mp3_read_header, and copy it if it exists to avoid further problems »? [14:20:49 CET] <wm4> yeah [14:21:33 CET] <Polochon_street> right, well I've checked for some places to put it in AVFormatInternal, but it doesn't seem to have any suitable fields (same for AVFormatContext) [14:22:58 CET] <wm4> what are you looking for? [14:23:47 CET] <Polochon_street> some AVDictionary ** field, or some void * place that can handle this kind of "temporary" data [14:23:53 CET] <wm4> add one [14:23:56 CET] <Polochon_street> but maybe I should add this field? [14:24:03 CET] <wm4> yes [14:24:26 CET] <Polochon_street> oh, okay. Sorry, I'm used to the user side of ffmpeg, so adding fields to AVFormatInternal is not something I'm used to :p [15:41:28 CET] <Polochon_street> is there a special place to initialize some variables in AVFormatContext.internal ? [15:43:20 CET] <wm4> Polochon_street: probably in some open call [15:44:43 CET] <wm4> actually avformat_alloc_context [15:44:49 CET] <wm4> which is strangely in options.c [15:50:28 CET] <Polochon_street> wm4: thank you, I've made this patch http://sprunge.us/JBBC. Roughly, it sets the internal id3v2 dict to NULL and uses this to skip the « if (!s->metadata) ; else ... » conditionnal statement [15:50:53 CET] <Polochon_street> well the first one is the patch I submitted first, which I corrected in the second [15:51:51 CET] <Polochon_street> tell me when you have time if it could be sent to the ML, or if there is like some huge flaw I am not seeing :p [15:52:07 CET] <wm4> did you run fate? [15:52:44 CET] <Polochon_street> ah. Didn't know about it, I'll run that first. [15:54:14 CET] <wm4> there's a stray 1 line removal in the patch (or at least it looks like one) [15:54:21 CET] <wm4> an empty linr [15:54:24 CET] <wm4> *line [15:56:18 CET] <wm4> also it adss { } around ff_id3v1_read(s); for no reason [15:59:01 CET] <Polochon_street> true [16:20:20 CET] <Polochon_street> Okay, I've run make fate-rsync/make fate, but I can't seem to find where are the results, the readme only mentions how to send them to the server... [16:21:41 CET] <wm4> Polochon_street: if you did "make fate" and it found the samples, then everything is ok if it didn't stop make with an error [16:22:04 CET] <wm4> AFAIK "make fate" without samples will run tests that don't need samples, which isn't enough [16:22:19 CET] <wm4> but if fate-rsync worked you probably did that correctly [16:22:37 CET] <Polochon_street> ok, perfect. It tested the samples downloaded from fate-rsync, yep, so, perfect. [16:22:53 CET] <Polochon_street> I'll make one single patch and try to test it again before submitting to the ML [17:09:20 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:d1df72a7025b: fate: add SCC test [17:14:53 CET] <ubitux> durandal_170: thanks! [17:15:24 CET] <ubitux> she is a witch! [17:42:59 CET] <wm4> Polochon_street: sorry, found some more things to comment on, I hope that's not annoying [17:45:46 CET] <Polochon_street> wm4: no problem, I'll leave now but will reply tomorrow! [18:01:39 CET] <Franciman> Hi [19:15:03 CET] <basisbit> hey, just wanted to come by to say: screw you! stop messing around with API within version numbers. and don't chnage api names if there is no need for it. dealing with ffmpeg api is such a pain for so many developers out there. [19:15:37 CET] <kierank> LOL [19:22:42 CET] <JEEB> totally not surprised [19:22:58 CET] <JEEB> both Libav and FFmpeg have derp'd without API version bumps :) [19:29:12 CET] <BtbN> well, if there is an actual API break, it's usually fixed [19:29:20 CET] <BtbN> Most people who complain are using non-public API [19:29:46 CET] <JEEB> or people who just don't want to update API usage [19:30:30 CET] <JEEB> of course that doesn't mean that some of the requests for better update documentation aren't correct [19:35:25 CET] <durandal_170> netbsd sub-scc failure is strange. it eats ' character [19:58:22 CET] <BBB> durandal_170: possible that the shell eats it during the test instead of actual breakage? [20:00:31 CET] <durandal_170> BBB: do you know how generic FIR filter should be implemented when given coefficients? [20:00:51 CET] <BBB> dont we have generic code for that in celp/acelp decoders? [20:01:24 CET] <durandal_170> BBB: with fft? [20:01:42 CET] <BBB> I dont know TBH ;) [20:03:05 CET] <BBB> check ff_acelp_interpolatef in acelp_filters.h [20:03:22 CET] <BBB> theres MIPS DSP also \o/ [20:14:21 CET] <wm4> yeah, keeping up with ffmpeg API is very annoying [20:14:50 CET] <wm4> I know, because until recently I was compatible down with ffmpeg 2.4 and Libav 11 or so [20:15:13 CET] <wm4> doesn't change the fact that the API needs to change [20:16:25 CET] <JEEB> yup [21:43:39 CET] <Compn> i think the more interesting complaint is [21:44:02 CET] <Compn> why not change the api names but then keep the old ones just for backwards compat and let the idiots apps crash ?D [21:44:07 CET] <Compn> but im crazy sooo [21:44:42 CET] <BtbN> because they are usually deprecated and throw a warning when used, and are then removed after a good while [22:13:20 CET] <Compn> specifically talking about the renamed api, not the removed api, but thanks for playing [22:13:23 CET] Action: Compn runs [22:22:13 CET] <cone-343> ffmpeg 03Sasi Inguva 07master:e4a1d87ef88d: lavf/matroskaenc.c: Free dyn bufs in mkv_free. Fixes memory leaks when muxing fails. [22:22:14 CET] <cone-343> ffmpeg 03Sasi Inguva 07master:03e42a4fecae: ffmpeg.c: Add output file index and stream index to vstats file. [22:22:15 CET] <cone-343> ffmpeg 03Michael Niedermayer 07master:629424773054: avfilter/vf_gblur: Increase supported pixel count from 31bit to 32bit in filter_postscale() [00:00:00 CET] --- Sat Jan 28 2017

1 0

ffmpeg.log.20170127
by burek 28 Jan '17

28 Jan '17

[01:00:20 CET] <the_k> hello ppl [01:03:12 CET] <the_k> http://imgur.com/nSTYQdn [01:03:21 CET] <the_k> http://i.imgur.com/nSTYQdn.png [01:03:59 CET] <the_k> i'm recording a stream here.. just wondering if anyone could point out anything that could be corrected as i see some errors in the display [01:04:02 CET] <the_k> it does work though [01:05:59 CET] <the_k> is there a build for windows with pthread support, and would it help? [01:17:24 CET] <furq> recording from a live source to a non-streaming container seems like a bad idea [01:17:35 CET] <furq> also -b and -r don't do anything if you're copying streams [01:18:19 CET] <thebombzen> is there a way for libopus to do vbr encoding (like libvorbis's -q:a or libx264 [01:18:26 CET] <thebombzen> or its -crf:v) [01:18:53 CET] <furq> -b:a [01:19:25 CET] <furq> there is no abr mode in opus, -b:a 192k is more or less the same thing as lame -V2 [01:19:39 CET] <furq> it's nominally 192k but won't actually attempt to hit that bitrate [01:21:00 CET] <furq> -vbr on is the default iirc but if not then turn that on too [01:28:30 CET] <faLUCE> hello. I'm trying to h264-encode YUYV422 images. I already encoded YUYV420P images, and all worked fine. But with YUYV422 I obtain this error: [libx264 @ 0x29d81a0] Input picture width (320) is greater than stride (0). I'm sure that I have filled the img's stride with av_image_alloc(frame->data, frame->linesize, 640, 480, AV_PIX_FMT_YUYV422, 1); and I have a linesize of {1280, 0, 0}.... so.... why this error? [01:36:21 CET] <the_k> furq, so i should convert it? [01:36:36 CET] <the_k> i wanted the raw input so that i don't have any loss [01:38:08 CET] <furq> if you want 60fps output then you have to convert it [01:38:20 CET] <furq> although that's just going to duplicate every frame three times, so i don't see why you would [01:38:28 CET] <furq> you should definitely use a more robust container like mpegts though [01:42:55 CET] <the_k> ah yeah that part of the string was a suggestion from a friend [01:43:01 CET] <the_k> i tried asking him why it was needed [01:43:04 CET] <the_k> didn't answer [01:43:13 CET] <the_k> same goes for the 3000kbit part.. [01:43:35 CET] <the_k> couldn't figure out how if it was saving the raw input it would need a bandwidth figure [01:47:09 CET] <thebombzen> the_k: if you're just trying to dump the stream to view it later, you can use ffmpeg -i rtsp://input_stream -c copy output_stream.ts [01:47:27 CET] <thebombzen> that will never end if the stream never ends though, so be careful with that [01:47:42 CET] <the_k> -i is input? [01:48:09 CET] <the_k> i was going to terminate it after every 24 hours [01:48:23 CET] <the_k> with -t 24:00:)0 [01:48:26 CET] <the_k> with -t 24:00:00 [01:48:32 CET] <thebombzen> "-i foo" means use "foo" as an input [01:48:37 CET] <the_k> yep ok [01:48:44 CET] <furq> if you want 24-hour chunks you'd be better off using the segment muxer for that [01:49:41 CET] <the_k> ah [01:50:43 CET] <furq> -f segment -strftime 1 -segment_time 86400 out%F-%T.ts [01:51:10 CET] <furq> will give something like out2017-01-27-00:00:00.ts [01:51:12 CET] <thebombzen> does the segment muxer only mux mpegts into segments? [01:51:24 CET] <furq> the examples show it working with nut [01:51:28 CET] <furq> i'd imagine flv etc work as well [01:51:36 CET] <thebombzen> how do you specify the format then [01:51:42 CET] <furq> er [01:51:43 CET] <thebombzen> it appears you did via filename but -f won't work [01:51:46 CET] <furq> oh right [01:51:59 CET] <thebombzen> so like how would you force the format [01:52:04 CET] <furq> is there a need to [01:52:08 CET] <thebombzen> no, just curious [01:52:17 CET] <furq> i don't see how you'd use -f segment to output to anything other than files [01:52:21 CET] <thebombzen> or is this one of those muxers like image2 where the filename is important [01:52:27 CET] <thebombzen> so you can't [01:52:37 CET] <furq> probably not [01:52:58 CET] <furq> oh [01:53:00 CET] <furq> -segment_format [01:53:00 CET] <furq> duh [01:53:11 CET] <the_k> Could not get segment filename with strftime [01:53:25 CET] <furq> weird [01:53:36 CET] <the_k> it's a camera stream [01:53:40 CET] <furq> well `-f segment -segment_time 86400 out%d.ts` works too [01:53:44 CET] <the_k> should it contain a time index? [01:53:51 CET] <furq> no that's based off wallclock time [01:53:53 CET] <the_k> rtsp stream [01:53:58 CET] <the_k> right [01:53:59 CET] <furq> it's not affected by the input [01:54:02 CET] <the_k> oh [01:54:04 CET] <the_k> right ok [01:54:48 CET] <the_k> ok t his works but it's showing the bitrate as N/A [01:54:55 CET] <the_k> and size=N/A [01:54:59 CET] <the_k> which is different [01:55:00 CET] <furq> you can also use `-segment_atclocktime 1` if you want it to always change over at midnight [01:55:25 CET] <faLUCE> hello. I'm trying to h264-encode YUYV422 images. I already encoded YUYV420P images, and all worked fine. But with YUYV422 I obtain this error: [libx264 @ 0x29d81a0] Input picture width (320) is greater than stride (0). I'm sure that I have filled the img's stride with av_image_alloc(frame->data, frame->linesize, 640, 480, AV_PIX_FMT_YUYV422, 1); and I have a linesize of {1280, 0, 0}.... so.... why this error? [01:55:28 CET] <the_k> the file plays fine though [01:55:36 CET] <furq> maybe the segment muxer breaks the bitrate/size display [01:55:44 CET] <furq> since it'd have to keep track of multiple files [01:55:57 CET] <furq> it's not really useful if you're copying anyway [01:56:03 CET] <furq> as long as the frame counter works you know it's running [01:56:23 CET] <the_k> ok well the file actually plays now while it's saving to diskl [01:56:30 CET] <the_k> so that's a good improvement [01:56:32 CET] <furq> yeah that's one of the benefits of using mpegts [01:56:40 CET] <the_k> ok great [01:56:46 CET] <the_k> thanks for that!! [01:56:54 CET] <furq> it also won't make the file unplayable if the input drops [01:57:12 CET] <the_k> right ok [01:57:31 CET] <furq> i wonder why strftime doesn't work [01:57:35 CET] <furq> maybe it's a windows thing [01:57:53 CET] <the_k> i've no idea but i could test a few commands if you want [01:58:01 CET] <furq> oh [01:58:04 CET] <furq> no %F on windows [01:58:07 CET] <the_k> ah! [01:58:32 CET] <furq> %F-%T is the same as %Y-%m-%d-%H:%M:%S [01:58:39 CET] <furq> so try it with that if you want the files timestamped [01:58:56 CET] <the_k> so i'll add -strftime 1 [01:58:59 CET] <furq> yeah [01:59:12 CET] <the_k> i can add this just before the file output name right? [01:59:26 CET] <furq> anywhere between the input and output filenames [01:59:39 CET] <the_k> hm [01:59:40 CET] <the_k> out27.ts [01:59:44 CET] <the_k> this is the filename [01:59:53 CET] <furq> what's your command [02:00:05 CET] <the_k> .... out%d.ts [02:00:10 CET] <furq> oh right [02:00:14 CET] <the_k> i want %Y-%m-%d-%H:%M:%S ? [02:00:24 CET] <furq> yeah i meant out%Y-%m-%d-%H:%M:%S.ts [02:00:31 CET] <furq> or replace out with whatever prefix you want [02:01:00 CET] <the_k> [segment @ 0000000003b73820] Failed to open segment 'fdout2017-01-27-01:00:46.ts' [02:01:00 CET] <the_k> Could not write header for output file #0 (incorrect codec parameters ?): Protocol not found [02:01:13 CET] <furq> uhh [02:01:18 CET] <the_k> colons [02:01:21 CET] <furq> yeah [02:01:24 CET] <furq> that's stupid [02:01:34 CET] <furq> maybe it'll work in quotes, but w/e [02:01:50 CET] <the_k> fdout2017-01-27-01-01-40.ts [02:01:56 CET] <the_k> cool :) [02:02:09 CET] <the_k> no, windows won't allow a colon [02:02:30 CET] <the_k> could use a ; [02:02:30 CET] <furq> oh right yeah no colons in filenames [02:02:51 CET] <the_k> fdout2017-01-27-01;02;43.ts [02:02:57 CET] <the_k> looks a little silly but better [02:03:19 CET] <furq> i mean i'd probably just use %Y%m%d-%H%M%S [02:03:21 CET] <furq> but whatever suits you [02:04:17 CET] <the_k> mm [02:04:22 CET] <the_k> ok thanks for that [02:06:22 CET] <thebombzen> no colons in filenames [02:06:26 CET] <thebombzen> what? [02:06:45 CET] <thebombzen> I know NTFS already has weird restrictions like no parentheses or ? [02:06:55 CET] <thebombzen> but colons? [02:07:04 CET] <thebombzen> why not [02:08:35 CET] <the_k> ah this is great. i can play the file directly from the drive instead of taking up more network bandwidth [02:08:55 CET] <the_k> and yet i can also now skip back and forth in time [02:12:27 CET] <furq> thebombzen: drive letters [02:12:51 CET] <thebombzen> oh right [02:13:06 CET] <furq> that one at least makes sense [02:13:10 CET] <thebombzen> but other than \, :, and null, why does windows not allow other weird things [02:13:16 CET] <furq> i'm not sure why <>*| aren't permitted [02:13:33 CET] <thebombzen> oh because in windows you can't backslash a character [02:13:35 CET] <furq> is usually an acceptable substitute for \ and also that would be a nightmare for nfs and stuff [02:13:39 CET] <furq> / [02:13:58 CET] <furq> oh and ? isn't allowed as well [02:14:00 CET] <thebombzen> forward slash can be interpreted as a path separator for compatibility [02:14:06 CET] <furq> some of these are probably dos holdovers [02:14:25 CET] <thebombzen> well * and ? are primitive expansions but you should be able to quote them. [02:14:31 CET] <furq> yeah [02:16:01 CET] <furq> this page i'm reading this on also mentions PATH length, and don't get me started on that [02:16:08 CET] <furq> er, path length. not $PATH length [02:30:03 CET] <faLUCE> can I x264-encode directly from YUYV422 frames? I can't open the codec with this format (Specified pixel format yuyv422 is invalid or not supported) when calling avcodec_open2(), and I'm forced to resample i to YUV420P, but I see that ffmpeg command line can encode with YUYV422 format.... what's wrong? how can I debug? [02:30:26 CET] <thebombzen> furq: silly goose [02:30:29 CET] <thebombzen> it's %PATH% [02:33:34 CET] <furq> faLUCE: you have to convert it to planar [02:33:39 CET] <furq> yuv422p should work [02:36:15 CET] <faLUCE> furq: nope, when executing: "ffmpeg -f v4l2 -i /dev/video0 -pix_fmt yuyv422 -c:v libx264 -tune zerolatency -b:v 900k -listen 1 -f mpegts http://localhost:5556" it works, and also the player shows yuyv422 info, without the "p" (planar) token [02:37:51 CET] <faLUCE> furq: sorry, you are right [02:38:35 CET] <faLUCE> the strange thing is that the ffmpeg cli doesn't show the planar token: tream #0:0: Video: rawvideo (YUY2 / 0x32595559), yuyv422, 640x480, 147456 kb/s, 30 fps, 30 tbr, 1000k tbn, 1000k tbc [02:41:42 CET] <furq> that's the input stream [02:42:04 CET] <faLUCE> furq: yes, sorry again. [02:43:05 CET] <furq> the cli will normally try to convert to the closest accepted pixel format [02:43:36 CET] <furq> i didn't know it did that if you specify -pix_fmt but apparently it does now [02:46:27 CET] <faLUCE> well. Now my lib is finished, after a hard work of 3 weeks. I can stream x264 http with very low latency, [02:46:49 CET] <faLUCE> with both audio and video perfectly in sync [03:00:43 CET] <thebombzen> wha'ts the practical difference between -pix_fmt and -vf format, similar to -s and -vf scale [03:02:03 CET] <furq> i'm pretty sure one is an alias for the other in both cases [03:02:20 CET] <furq> iirc the difference is that the flag just appends it to the end of the filterchain [03:02:30 CET] <furq> rather than letting you put it where you want [03:45:39 CET] <beastwick> Hi, I am trying to use libav to open a x11grab device and encode the video. I *kind of* understand how this is all put together as I was working off of two different tutorials. I am able to see the encoding going for 250 frames and write to a file, that does fill with data, but when I try playing it back in VLC I see nothing. There is no duration i [03:45:39 CET] <beastwick> nformation or image. [03:46:08 CET] <beastwick> http://pastebin.com/u3pvTGEX [04:01:39 CET] <beastwick> My bad, that pastebin had a bug. [04:02:01 CET] <beastwick> http://pastebin.com/6zxXRJaR [04:02:07 CET] <beastwick> same issue [04:10:50 CET] <NermaN> Hello, when i'm trying to encode video using h264_vaapi encoder it seems to get only empty frames (full debug log here: http://pastebin.com/Pb9PdMx8 ) is there any way to solve this issue? [05:11:47 CET] <bms20> Hi All, I've got a question r/e reference frames and uploading textures to GL. I am wondering if I can coerce the decoder into writing its output into a PBO which I can render from another thread. My concern is that when the PBO is locked for rendering the decoder will not be able to use it as a reference frame. Is there a way to do this, or am I missing the point? [05:40:52 CET] <thebombzen> bms20__: an avcodec decoder won't necessarily output the right pixel format - for example afaik OpenGL can't render a yuv420p buffer [05:41:04 CET] <thebombzen> it might need to be bgra, bgr24, or bgr0 [05:42:12 CET] <bms20__> thebombzen: yuv420 is fine - just convert it in the pixel shader. [05:42:35 CET] <thebombzen> well then I don't know. I'm not very experienced with GL framebuffers [05:43:38 CET] <NermaN> drm.debug=0x06 don't shows anything about ffmpeg issue =( [05:43:53 CET] <NermaN> it still can't encode using h264_vaapi [05:44:09 CET] <NermaN> should i fill this like bug for ffmpeg or vaapi? [07:20:17 CET] <Nune> I am trying to learn how to render a h.264 mp4 with alpha transparency from an image sequence of semi-transparent .PNGs? [07:20:27 CET] <Nune> Any help greatly appreciated. :) [07:29:13 CET] <Nune> This seems pretty close: ffmpeg -framerate 60 -i dialog_line_%03d.png -vcodec png dialog_line.mp4 [07:29:27 CET] <Nune> Oh, actually, I think this is it :D [08:13:13 CET] <spiderkeys> Can anyone point me to some literature or reference for the exponential golomb encoding procedure that uses a table (as it is done in FFMPEG and x264)? I imagine this is a performance optimization over the rote algorithm, but would like to know how that approach was derived. [10:43:32 CET] <NermaN> Even current git version don't works with vaapi =( [10:43:38 CET] <NermaN> And nobody know why =( [10:46:43 CET] <jkqxz> Can you try a different version of the driver? [10:50:01 CET] <NermaN> jkqxz: you mean libva-intel-driver? [10:50:11 CET] <NermaN> i can try to build another version [10:56:22 CET] <Traktorrr> 9Traktorrr: Hi people [14:53:29] 9Traktorrr: we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1 [14:54:29] 9Traktorrr: Now we need to get [10:56:38 CET] <jkqxz> NermaN: Yeah. From what you've said so far it doesn't look like an ffmpeg issue, rather something further down the stack. [10:58:27 CET] <Traktorrr> Now we need to get more, and the phase between audio channels, left and right is it possible? [11:00:27 CET] <Traktorrr> in general we have data stream (lufs,dbfs), as we get the phase between the left and right channel? [11:05:05 CET] <Traktorrr> ((( [11:08:37 CET] <Traktorrr> i need help!!!!!!!!!!!!!! [11:26:07 CET] <Traktorrr> nu suki [11:26:16 CET] <Traktorrr> ebanie [11:26:58 CET] <NermaN> Traktorrr: a che tak? [11:27:17 CET] <Traktorrr> Uraaaaaaaa russkieeeeeeeee [11:27:18 CET] <Traktorrr> ))) [11:27:34 CET] <Traktorrr> 40 2@>B :><?>B =8:B> ?><>GL =5 <>65B [11:27:44 CET] <NermaN> C <5=O B0:65, >1=8<5<AO xD [11:27:51 CET] <Traktorrr> E0E0E00 [11:34:44 CET] <Traktorrr> Hi people [14:53:29] 9Traktorrr: we deduce from the audio stream data for analysis such as lufs, dbfs. ipolzuya command: ffmpeg -f s16le -ac 2 -ar 12K -i http: // xxx -icecast0.xxx .xxx: 8000 / ch_wav -af ebur128 = peak = true -f null - 2> & 1 [14:54:29] 9Traktorrr: Now we need to get more, and th [11:34:55 CET] <Traktorrr> Now we need to get more, and the phase between audio channels, left and right is it possible? [11:37:57 CET] <durandal_1707> Traktorrr: aphasemeter filter? [11:38:44 CET] <Traktorrr> yes [11:39:26 CET] <Traktorrr> example please [11:40:21 CET] <durandal_1707> Traktorrr: if you just need numbers? than call it with video output disabled [11:41:52 CET] <Traktorrr> i used audio icecast , NOT VIDEO , i need console output DBFS : Left, DBFS: right, LUFS, and PHASE i need numbers between [-1, 1] [11:43:52 CET] <durandal_1707> that aphasemeter does. gives metadata to frame when video is not enabled [11:44:53 CET] <durandal_1707> but it doesnt give global one because that doesnt make sense [11:48:17 CET] <Traktorrr> how to receive a phase? we need to remove indication of levels of signals of the left and right channel and besides to remove a phase [11:48:43 CET] <Traktorrr> how to receive a phase? we need to remove indication of levels of signals of the left and right channel and besides to display a phase [11:49:22 CET] <Traktorrr> the ebur filter to remove necessary to us rovn of signals how to force it to remove a phase??? [11:51:03 CET] <Traktorrr> the ebur filter displays LUFS, DBFS levels of signals necessary to us how to force it to display a phase??? [11:52:53 CET] <durandal_1707> you cant with ebur128 [11:53:08 CET] <durandal_1707> but can with another filter [11:55:26 CET] <Traktorrr> [Parsed_ebur128_0 @ 0x249af80] t: 0.0999792 M:-120.7 S:-120.7 I: -70.0 LUFS LRA: 0.0 LU FTPK: -14.6 -13.6 dBFS TPK: -14.6 -13.6 dBFS [11:55:45 CET] <Traktorrr> [Parsed_ebur128_0 @ 0x249af80] t: 0.0999792 M:-120.7 S:-120.7 I: -70.0 LUFS LRA: 0.0 LU FTPK: -14.6 -13.6 dBFS TPK: -14.6 -13.6 dBFS [Parsed_ebur128_0 @ 0x249af80] t: 0.199979 M:-120.7 S:-120.7 I: -70.0 LUFS LRA: 0.0 LU FTPK: -14.3 -13.2 dBFS TPK: -14.3 -13.2 dBFS [Parsed_ [11:56:00 CET] Last message repeated 1 time(s). [12:47:04 CET] <chamath> Hi I have a problem with video splitting. The time value seems not accurate. [12:48:31 CET] <chamath> ffmpeg -y -ss 0 -accurate_seek -i <input mp4> -ss 0.570 -f lavfi -i aevalsrc=0 -t 6.690000 -strict -2 -c:v libx264 -preset faster -crf 28 -acodec aac -map_metadata -1 -movflags faststart <output> [12:49:34 CET] <chamath> I expect final output video to be length of 6.69 seconds, but it is 6.712 seconds long. [12:49:48 CET] <chamath> I calculate the duration of the video using ffprobe [12:50:19 CET] <chamath> ffprobe -i <output file> -show_entries format=duration -v quiet -of csv="p=0" [12:50:30 CET] <chamath> Any idea what can be wrong here? [12:54:40 CET] <iive> JFY, what is your fps? what is the frame duration? [13:16:27 CET] <chamath> fps is 60 [13:22:12 CET] <Guest49090> Hey! I'd get the next error when I do try to stream an mp4 file to rtmp: [flv @ 0x2ecb980] video stream discovered after head already parsed [13:22:42 CET] <Guest49090> I'd hope someone can explain why I'd get this [13:22:54 CET] <Guest49090> and im not sure if it is an error [14:12:45 CET] <brontosaurusrex> would that 'ffmpeg -i in.mov -vf minterpolate=fps=50 -c:v prores -r 25 out.mov', assuming input is 25fps, valid command line? [14:12:52 CET] <brontosaurusrex> +be* [14:20:58 CET] <brontosaurusrex> nope. [14:23:07 CET] <brontosaurusrex> refrazing: minterpolate example that would slomo to 50% making output 2 times longer? [14:29:12 CET] <brontosaurusrex> cough [14:55:49 CET] <brontosaurusrex> Nicks #ffmpeg: [@`md @durandal_1707 @superdump @ubitux +uau [-T-] [mbm] ]R[ _0x5eb_ __jack__ _corrupt _Kate A3G1S aarwine aballier adgtl Aerroon Akira^^_ alexspeller Alina-malina alu alucryd Amadiro antlarr araml Arokh Arthur_D artista_frustrad Arwalk ashka asm89 AssPirate Asterisk AstralStorm atomnuker Azelphur Balliad balrog barhom basisbit bbert beastwick beatdown bencoh Benjojo benwilber besc bjoe2k4 [14:55:51 CET] <brontosaurusrex> Blaxar blb blinky42 bmhm boiled_sugar Bombo bove bret brontosaurusrex BtbN c_14 cantstanya CARAM__ cbdev cbsrobot chamath chandoo__ charims Chloe[m] chovy Cldfire Cloudef codebam CoJaBo colde comgot Cork cosmo1t courrier Croepha CruX| CustosLimen cyphase D-ion dagobert__ damdai damnlie_ dantti dashcloud_ DasMoeh davidmichaelkarr db01 DeathShot debianuser decay devster31 DHE Diag dl2s4 dlb76 dongs donics [14:55:53 CET] <brontosaurusrex> doogaille dro_bot drv dustinm` dv_ e Ekho Elysion_ enp0s3 Exagone313 f0lder faLUCE feliwir fengshaun fflogger fidothe Filarius22 firewyre_ flarunt Fletcher fling flux fnords foonix fritsch furq fusl fzn G gaeta gen93 georgie ghost1 ghoti gix glebihan glebihan_ gmh GRMrGecko Guest27309 Guest47316 Guest49090 Guest94912 gusto haagch haasn hamsheet HarryHallman hawken Hello71 hfb Hink Hobbyboy Holbrook howitdo [14:55:55 CET] <brontosaurusrex> hreinnbeck hurricanehrndz hyponic igitoor_ iive ikevin Intrepd irock ItWasntMe2013 ivanich jA_cOp JackWinter jacobwg Jaex jarainf jarryd jason_- jbermudes JEEB jfmcarreira Jikan jimbankoski__ jkqxz john51_ JohnPreston72 joshbaptiste JoshX jpf3 jswagner justinmrkva jya k-man K1rk k_sze[work] kam187 kasper93 KDDLB Kei_N kepstin kerio Keshl ketas kevc klaxa kode54 kraft Kronuz kuroro Kuukunen kvz larsi lavalike [14:55:57 CET] <brontosaurusrex> lebster LegendThinker Len lesderid limbo_ lkiesow llamapixel lomancer LRN lroe luc4 luminarys m1dnight_ madprops MadWasp manuelschneid3r maqr marcoslater Matador mateo` MatthewAllan93 matthiaskrgr Mavrik Me4502 merzo michaelni microchip_ Mista_D mixfix41 mixi miyalys monokrome mosb3rg moser MSG|Maverick mundus2018 Muzer Myrsloik Nanashi nate nd neonfuz Neville nirvanko Nitori nitrix Nothing4You nwoki [14:55:59 CET] <brontosaurusrex> nyuszika7h ObsidianX ocrete olspookishmagus oorm ootje Orphis ossifrage pa paperManu parasite_ ParkerR PaulCapestany pbos PharaohAnubis phillipk Phlarp_ phryk pigeon pigoz pinPoint ploop Plorkyeran_ podman Polochon_street pomaranc pprkut ps-auxw psychicist__ ptx0 pzich r0r0 raijin rcombs relaxed Relict retard rexbron ribasushi rikai ritsuka rjp421 rkantos_ road|runner rossome roundtrip rsully runawayfive [14:56:29 CET] <madprops> finally im in a list [14:56:35 CET] <colde> lol madprops [14:56:41 CET] <iive> you were quite fast :) [14:56:43 CET] <colde> I can add you to a few lists if you like ;) [14:56:57 CET] <DHE> how not to use IRC? [14:57:12 CET] <colde> How to piss of everybody he wants to help him at least [14:57:30 CET] <larsi> hey guys I need help [14:57:33 CET] <larsi> but let me annoy everyone first [14:57:37 CET] <ploop> christ [14:57:52 CET] <ikevin> oO [14:57:56 CET] <furq> well he did succeed in getting all the idlers to respond [14:58:08 CET] <rjp421> heh [14:58:28 CET] <ploop> if you guys have weechat you should install the colored nicks plugin, it turns spam into beautiful quilts https://lep.pw/img/839b91b4d2a76380.png [14:59:01 CET] <DHE> purdy [14:59:19 CET] <DHE> (that's supposed sound like "pretty") [15:14:08 CET] <Nanashi> *All* the idlers? http://i.imgur.com/PSWd2jl.png [15:14:23 CET] <Nanashi> Anyway, should off to discord where there's @everyone or @here unless disabled. [15:23:29 CET] <MSG|Maverick> there was a cat on his keyboard [15:31:01 CET] <faLUCE> Hello. How is it possible that on the first 3 or 4 frames to encode, avcodec_encode_video2(...., got_packet_ptr) returns 0 (success) and got_packet_ptr is=0 at the same time? [15:31:33 CET] <faLUCE> (codec = x264) [15:39:18 CET] <DHE> faLUCE: b-frames buffer a lot of packets in before providing frames out [15:41:10 CET] <faLUCE> DHE: where are them buffered? In some internal buffer of the codec context? [15:41:32 CET] <JEEB> libx264 handles required buffering and avcodec is just feeding to it [15:41:48 CET] <faLUCE> JEEB: I see [15:41:54 CET] <JEEB> if you need low latency just set tune to zerolatency or so [15:42:01 CET] <JEEB> that will disable features that add latency [15:42:21 CET] <JEEB> other parts of lavc/lavf will still of course need to be optimized, but libx264 itself will at that point be set to minimal latency [15:43:06 CET] <faLUCE> then the pkt filled by avcodec_encode_video2() does not correspond to the current frame, but to 4 frames before? [15:43:30 CET] <JEEB> when you start getting packets they will have their timestamps etc [15:43:51 CET] <JEEB> but yes, at the end you will have to flush the encoder, which IIRC is documented [15:50:18 CET] <faLUCE> is there a way to set the x264 buffer siize other than zerolatency ? [15:50:52 CET] <JEEB> yes, but if you need low latency then that's what you use :P [15:51:20 CET] <JEEB> otherwise you use stuff like the lookahead parameters and stuff like that to limit the amount of required buffering [15:51:40 CET] <faLUCE> JEEB :-) tnx [15:52:07 CET] <JEEB> as the zerolatency tune also adjusts stuff like the threading mode [15:52:22 CET] <JEEB> because frame threading adds latency [15:52:39 CET] <JEEB> while slice threading lessens compression but enables threading within a picture [15:55:19 CET] <faLUCE> JEEB: in addition, if I want to reduce the audio latency, I suppose I have to minimize the MPEG audio frame, right? Currently it's automatically set to 1152 samples by the audioEncoder's CodecContext and I dont' know how to minimize it [15:55:52 CET] <JEEB> depends on the encoder [15:55:56 CET] <faLUCE> mp2 [15:56:13 CET] <faLUCE> (but I could use another one) [15:57:18 CET] <JEEB> I won't be able to tell you :P I haven't cared about audio personally so you will have to read the code of the encoder to know if it can do that at all [15:57:28 CET] <JEEB> (and that will show you how to do it as well) [15:57:45 CET] <faLUCE> ok, I'll do that [16:16:56 CET] <kerio> opus is pretty good if you have strict requirements on latency [16:22:03 CET] <jubalh> hi [16:22:55 CET] <jubalh> I have several .mp4.ts files which i would like to convert into one mp4 file, could someone help me with that? [16:24:51 CET] <jubalh> I assume something like: ffmpeg *.ts -acodec copy -vcodec copy output.mp4 [16:24:59 CET] <jubalh> but that doesnt seem to be right [16:25:10 CET] <jubalh> ffmpeg -i *.ts <- I mean [16:25:24 CET] <JEEB> welcome to the hell of concatenation in FFmpeg [16:25:34 CET] <JEEB> there's like three or four different concat modules on different levels [16:26:11 CET] <JEEB> I think in your case the simplest way would be to just append the ts files in the correct order with cat, and then remux with `ffmpeg -i all.ts -c copy out.mp4` [16:26:36 CET] <JEEB> MPEG-TS just happens to be something that should work like that :P [16:27:25 CET] <JEEB> also you can use stdout output with cat and do input from that [16:27:28 CET] <JEEB> with piping [16:27:56 CET] <JEEB> -i - (a "-" as the 'input file') should be stdin) [16:29:08 CET] <dl2s4> good old mass highlight.. i was like "wow, i am important i am highlighted in #ffmpeg" =) [16:32:44 CET] <jubalh> JEEB: worked like a charm! Thanks a lot :) [16:33:37 CET] <thebombzen> jubalh: for future reference if you like the concat filter, you can use ffmpeg $(echo -i\ *.ts) [16:33:53 CET] <thebombzen> ohwait nvm that works with {} but not * [16:33:54 CET] <thebombzen> hmmm [16:34:40 CET] <thebombzen> if the ts files are labeled 01..20.mp4.ts or something, you could use ffmpeg $(echo -i\ {01..24}.mp4.ts) [16:34:46 CET] <thebombzen> and then use the concat filter [16:35:50 CET] <jubalh> ok [16:35:55 CET] <furq> wtf [16:35:57 CET] <furq> how does that work [16:36:07 CET] <JEEB> concat filter is after decoding [16:36:09 CET] <JEEB> so -c copy won't work [16:36:22 CET] <JEEB> concat demuxer or protocol might work, but it's a mess [16:36:35 CET] <JEEB> so if you've just got mpeg-ts I prefer to just go around that [16:37:11 CET] <thebombzen> furq: the shell expands -i\ {01..20}.mp4.ts into twenty different arguments: "-i 01.mp4.ts" "-i 02.mp4.ts" etc. [16:37:26 CET] <furq> yeah how does that work [16:37:37 CET] <thebombzen> {01..20} is a shell thing [16:37:43 CET] <thebombzen> it works similar to {a,b,c} [16:38:02 CET] <thebombzen> but the space is part oft he argument so filtering it through echo removes the space, and you end up with all 40 arguments instead of 20 [16:38:09 CET] <furq> oh duh [16:38:28 CET] <furq> i missed that \ [16:38:35 CET] <thebombzen> oh lol yea it's crucial [16:38:41 CET] <furq> yeah that makes perfect sense now [16:39:15 CET] <furq> that's a nice trick [16:39:25 CET] <furq> shame it doesn't work with globs though [16:39:38 CET] <thebombzen> yea it won't work with *. that requires more work [16:42:06 CET] <thebombzen> with * as long as you have no spaces in filenames, you can do ffmpeg -i $(echo *glob*.ts | sed 's/ / -i /'g) [16:46:14 CET] <furq> bye [18:00:06 CET] <Bombo> how do i add an rpath? [18:00:31 CET] <Bombo> wrong window [18:00:32 CET] <Bombo> ;=) [18:01:06 CET] <Bombo> (--enable-rpath) [18:01:55 CET] <Franciman> Hi [18:03:35 CET] <Bombo> ho [18:03:48 CET] <Franciman> I'd like to extract audio from a video file and get data to generate a waveform (not using the waveform filter), is libavfilter the right way to do that? [18:10:43 CET] <Bombo> Franciman: you want to do an audio player? [18:10:59 CET] <Bombo> good question ;) [18:11:00 CET] <Franciman> kind of, yeah [18:11:25 CET] <Franciman> it's a program to edit subtitles [18:11:31 CET] <JEEB> sounds like aegisub [18:11:55 CET] <Franciman> kind of [18:12:21 CET] <JEEB> but yes, libav{format,codec} to get decoded samples, and then libavfilter for adding filters that take in images or audio samples and output one or the other (or both) [18:12:39 CET] <JEEB> the first part you can simplify by using something like ffms2, which is what aegisub is doing as well [18:13:02 CET] <JEEB> (although I guess plugging in avfilter becomes a wee bit harder since you no longer deal with avcodec output avframes) [18:13:32 CET] <Bombo> hmm does it use the audio data to synch it to the subtitle? [18:14:03 CET] <Franciman> yes [18:14:17 CET] <Bombo> sounds quite useful [18:14:18 CET] <Franciman> I mean, you need to do that by hand, eh! [18:14:27 CET] <Bombo> oh ;( [18:14:29 CET] <Bombo> ;) [18:14:29 CET] <Franciman> but maybe... one day... [18:14:50 CET] <Bombo> but it displays the waveform [18:14:52 CET] <JEEB> you will never release stuff with any automated timing thing, you generally always want to at the very least finish it up manually [18:15:10 CET] <Bombo> does aegisub do that? i never did subtitles [18:15:13 CET] <JEEB> yes [18:15:17 CET] <JEEB> aegisub has a waveform [18:15:38 CET] <JEEB> and no, I'm pretty sure it has no automated timing stuff although it could be possible [18:15:45 CET] <JEEB> that said, the heuristics for it are hard :P [18:15:47 CET] <Franciman> yeah, that'd pretty hard, I guess [18:15:56 CET] <Bombo> just an idea ;) [18:15:57 CET] <Franciman> JEEB, do you do subtitles? [18:16:04 CET] <JEEB> I used to do them more [18:16:08 CET] <Franciman> cool! [18:16:18 CET] <JEEB> nowadays I'm a grumpy man doing video processing [18:16:28 CET] <Franciman> ahah, cool! [18:16:49 CET] <JEEB> but yeah, if I was developing something for subtitles I would most likely start by seeing if I could plug something into aegisub [18:16:55 CET] <JEEB> since it already has a whole lot of useful stuff [18:17:00 CET] <JEEB> and export modules etc [18:17:09 CET] <JEEB> cross-platform too [18:17:40 CET] <Franciman> yeah it's cool, absolutely. In my defense, I'm doing this by myself as a personal exercise [18:17:43 CET] <Franciman> ahah [18:18:55 CET] <JEEB> one thing that pops up would be to somehow make aegisub use mpv's opengl renderer stuff for the preview [18:19:06 CET] <JEEB> since it's currently opengl as well [18:19:17 CET] <JEEB> and mpv's is just much more feature-filled [18:19:31 CET] <Franciman> JEEB, shhh that's my killer feature [18:19:41 CET] <JEEB> lol [18:21:48 CET] <Franciman> aegisub is also written in C++11, neat! [18:24:18 CET] <Franciman> anyways, thanks a lot for your help Bombo and JEEB [18:25:27 CET] <JEEB> another thing I've thought of was export into blu-ray subpictures (since the spec for that is known). have libass (or VSFilter) render onto a video-sized canvas and write 4:4:4 YCbCr images [18:34:02 CET] <Franciman> that'd be really cool [18:55:44 CET] <hron84> Hi! I trying to stream a WebM video to an IceCast2 server, but I cannot pass 4-7 FPS while OGG streams work normally (24-28 FPS). I tried to stream to /dev/null to make sure it's not a IceCast limitation or a network issue, but it seems like not. Also, I cannot specify ffmpeg to do not reencode the stream just copy, because if I specify -f webm -c copy then ffmpeg exits instantly without starting the stream. Can anyone help me with t [19:03:41 CET] <JEEB> you might want to see the error related :P [19:04:06 CET] <JEEB> although most likely you're trying to push streams not allowed in "webm" (subset of matroska defined by el GOOG) [19:04:14 CET] <JEEB> and yes, libvpx is slow [19:04:18 CET] <JEEB> esp. if you're trying to do vp9 [19:06:19 CET] <hron84> JEEB: it does not display an error message, just exits [19:06:46 CET] <hron84> If you mean for -c copy [19:07:13 CET] <hron84> so i specify parameters, press enter, it display input and output stream details and instantly quits [19:07:44 CET] <JEEB> hron84: I would bet a piece of virtual money on that it gives you an error message [19:07:47 CET] <hron84> without any error. I tried enable a debug logging, it reads up the stream and the log ends without any information about what's happening [19:07:58 CET] <JEEB> just pastebin the full terminal log and link your paste here [19:08:02 CET] <JEEB> use whatever hits your fancy [19:08:07 CET] <hron84> let me do it [19:08:10 CET] <JEEB> either pastebin.com or something else [19:11:00 CET] <hron84> JEEB: http://pastebin.com/nJi3SdDZ [19:11:14 CET] <hron84> I cannot see any error here. [19:11:33 CET] <hron84> The next line is my prompt again. [19:12:00 CET] <furq> that's working correctly [19:12:13 CET] <hron84> except it does not do anything? [19:12:13 CET] <furq> you probably want -re to write at the input framerate [19:12:28 CET] <furq> that's copying the entire file into the output, just like you asked [19:12:33 CET] <furq> it's just doing it at 351x realtime [19:12:46 CET] <hron84> Ahh. [19:12:49 CET] <hron84> Hmm. [19:12:50 CET] <furq> add -re before -i if you're streaming from a file [19:13:06 CET] <hron84> let me check the output [19:13:56 CET] <Hello71> does it drop frames if it can't keep up then [19:14:15 CET] <hron84> So that is -re for! [19:14:20 CET] <hron84> I never understood it. [19:14:38 CET] <hron84> furq: you saved my ass. Thanks! [19:15:07 CET] <JEEB> -re is very fragile tho [19:15:29 CET] <JEEB> like, if your input suddenly has a timestamp jump it will derp you up [19:15:34 CET] <hron84> A risky question: can it work with -f concat too (I mean -c copy and -f concat)? It would be very wonderful. [19:15:41 CET] <furq> "very" is maybe an exaggeration [19:15:47 CET] <furq> i've never had any trouble with well-formed inputs [19:15:58 CET] <JEEB> well yes, but even well-formed transport streams can derp it up [19:16:01 CET] <furq> but yeah i wouldn't trust anything valuable to it [19:16:31 CET] <JEEB> hron84: might. concat related things work for very limited subsets of things [19:16:32 CET] <hron84> Can you explain how it can "derp"? Few dropped frames could be okay if the stream can keep up. [19:16:38 CET] <furq> hron84: it should do, but concat is a bit weird in itself [19:16:44 CET] <Threads> if i worked on the matroskaenc to allow aac bitrate display would it be looked at by ff-devs ? [19:17:03 CET] <furq> is that something that the muxer has control over [19:17:05 CET] <JEEB> all of the concat filters, demuxers etc have their capabilities and limitations [19:17:26 CET] <Threads> furq ac3/dts can be displayed [19:17:32 CET] <furq> well yeah those are cbr [19:17:43 CET] <Threads> mp3 even [19:17:53 CET] <JEEB> hron84: like ffmpeg.c going to wait for a few years because of a timestamp reset or so [19:17:58 CET] <JEEB> as in, -re [19:18:04 CET] <furq> i'm pretty sure that's flagged somewhere in the bitstream itself [19:18:05 CET] <hron84> JEEB: all i want is take N webm files and blow them to icecast. No reencoding, no remuxing, nothing but a simple 1:1 copy. [19:18:16 CET] <furq> it's nothing to do with the container, matroska doesn't have metadata for that afaik [19:18:16 CET] <hron84> JEEB: wow. [19:18:27 CET] <JEEB> furq: it has "tags" :DDD [19:18:29 CET] <furq> that's why it works in mp4, because mp4 does [19:18:53 CET] <JEEB> so you have timestamps in the container and then tags for example for the "duration" [19:18:53 CET] <furq> well yeah you could store that informatiom somewhere, but you could equally well write it on a post-it note and stick it to your dog [19:18:56 CET] <JEEB> or "bit rate" [19:19:08 CET] <furq> it's going to be readable by roughly as many people either way [19:19:08 CET] <JEEB> I really facepalmed when mkvmerge started writing that stuff [19:19:42 CET] <JEEB> hron84: it might work, the timestamp resets between multiple files are what might break -re completely [19:19:45 CET] <JEEB> in other words, try it out :P [19:20:02 CET] <JEEB> it will still remux of course, that's what -c copy does [19:20:08 CET] <hron84> Doing it right now :D [19:20:10 CET] <JEEB> it does demux completely and then remux [19:20:17 CET] <furq> that's what you want though [19:20:29 CET] <JEEB> well he specifically wanted to just throw the already muxed data as-is [19:20:36 CET] <JEEB> just saying he won't get exactly that [19:20:45 CET] <JEEB> he will get a demuxed and then once again muxed data [19:20:48 CET] <furq> well he said that's what he wanted but i'm pretty sure it isn't actually [19:20:51 CET] <hron84> Meh, i am not in this video-encoding thing, i just learning the whole stuff now, I have to maintain a icecast server and help my friend to stream videos [19:21:08 CET] <furq> does webm over icecast work reliably yet [19:21:13 CET] <furq> i tried it just after it landed and it was a mess [19:21:17 CET] <JEEB> furq: that might be true but warning him that it isn't 100% what he said is still OK in my books :P [19:21:32 CET] <furq> sure, i was just clarifying to him that remuxing is in fact what he wants [19:21:53 CET] <JEEB> well, what he wants would be possible with a way higher level thing as well as far as I can tell [19:22:05 CET] <JEEB> but yeh, with ffmpeg.c -c copy is what he wants [19:22:57 CET] <hron84> :-) [19:23:26 CET] <JEEB> furq: btw for nightmare food go look at the vsync code in ffmpeg.c [19:23:40 CET] <JEEB> I don't think even the people who originally wrote that fully understand WTF is going on [19:23:50 CET] <JEEB> s/food/fuel/ [19:24:09 CET] <furq> i'd rather hang on to the illusion of reliability from ffmpeg.c [19:24:19 CET] <furq> the best way to do that is to not ever read it [19:24:33 CET] <JEEB> yeah, it's surprising how many things are hanging on and kind of working with it :P [19:25:01 CET] <JEEB> the API itself is nowadays much more saner but ffmpeg.c is a special snowflake full of random stuff that screams "can we just make this stuff go away" [19:25:57 CET] <hron84> it seems like -f concat and -c copy are friends in this combination. \o/ [19:26:10 CET] <JEEB> just make sure you tested with -re if you're going to be using it [19:26:12 CET] <hron84> and no derps even with -re [19:26:15 CET] <JEEB> ok [19:26:18 CET] <JEEB> good luck then [19:26:31 CET] <JEEB> you're threading in deep waters that look shallow [19:26:32 CET] <JEEB> :D [19:26:46 CET] <hron84> It could make the tomorrow stream great again! :-) [19:28:44 CET] <faLUCE> Well, this is terribly confusing. How can I allocate an AVPacket on the heap with libav 2.8? I see there's av_new_packet(), but if I access the pkt's fields soon after this allocation, I obtain a segfault. Same thing if I call av_init_packet() after this allocation. [19:29:35 CET] <faLUCE> I don't have problem if the AVPacket is stacked [19:30:11 CET] <faLUCE> (sorry, I had problems with internet connection) Well, this is terribly confusing. How can I allocate an AVPacket on the heap with libav 2.8? I see there's av_new_packet(), but if I access the pkt's fields soon after this allocation, I obtain a segfault. Same thing if I call av_init_packet() after this allocation. [19:31:07 CET] <phillipk_> thanks in advance: I'm getting an output with audio in stream 1 and video in stream 2 (I want it the other way around)... see my cmd: [19:31:08 CET] <phillipk_> http://pastebin.com/uN5nnSCr [19:32:01 CET] <furq> phillipk_: https://www.ffmpeg.org/ffmpeg.html#Advanced-options [19:32:04 CET] <JEEB> use map [19:32:48 CET] <JEEB> also update your FFmpeg if you're using -strict experimental for the AAC encoder [19:32:58 CET] <JEEB> that enables you to remove that since the AAC encoder got improved [19:39:26 CET] <phillipk_> ok [19:39:48 CET] <phillipk_> so, I'm confused with how map works/conflicts with the filter_complex I made [19:41:30 CET] <furq> -map 0:v -map "[out]" [19:42:59 CET] <furq> and append [out] after amix=4 [19:43:58 CET] <phillipk_> let me test it, thanks [19:44:12 CET] <furq> i thought [out] was the default name for an unlabelled output but apparently not [19:44:22 CET] <furq> the docs say it is but it doesn't seem to work [19:46:05 CET] <JEEB> probably implied in something else :P and "map" then tries to explicitly use it or so [19:46:22 CET] <furq> http://vpaste.net/4R1mi [21:04:58 CET] <Nune> I have a sequence of semi-transparent images that I want to concatenate into a semi-transparent 6 second video clip (MP4). I've done this so far, yay! While the image sequence is not seamless, I'd like to loop the playback and crossfade the final frames into the initial frames. Can FFMPEG accomplish this? [21:25:45 CET] <durandal_170> Nune: how much to loop? [21:29:50 CET] <Nune> durandal_170 The video is 6 seconds. In the last 1 second of the 6, I'd like to blend out the frames towards alpha=0, and blend in the first frames towards alpha=1, so that at the end of the video, we're showing the first frame at alpha=1. [21:35:14 CET] <Nune> Ah, and obviously the clip would need to shrink by 1s to accomodate the crossfade. So the result would be 5s [21:50:16 CET] <Nune> This would be a command in Windows 10, btw. [21:50:25 CET] <Nune> Found this: https://superuser.com/questions/1001039/what-is-an-efficient-way-to-do-a-vi… [21:50:32 CET] <Nune> Not quite able to translate it into what I need yet. [21:55:17 CET] <monokrome> O_O [22:41:29 CET] <Nune> ok I think I need to use the overlay filter [22:42:13 CET] <Nune> I have a 6 second clip. My bottom layer needs to render 0..5s at full opacity. My top layer needs to render 5..6s, starting at full opacity and fading out to zero opacity. Both layers start playing at the same time. [22:51:44 CET] <durandal_170> Nune: for looping short sequence try loop filter [22:53:13 CET] <Nune> durandal_170: Oh, really? That will crossfade the loop? That'd be great! [22:55:16 CET] <durandal_170> Nune: loop just loops frames you want to loop [22:56:59 CET] <Nune> Ah, no, that's not what I want then. [22:57:16 CET] <Nune> have a 6 second video that isn't seamless [23:08:51 CET] <furq> Nune: how many times do you want it to loop [23:12:22 CET] <furq> i have no idea why the guy in this SO answer is jerking about with trim and concat, you don't need that [23:13:41 CET] <Nune> hah [23:13:47 CET] <Nune> I don't want the video to loop at all. [23:13:53 CET] <Nune> It will be played back on loop by the media player. [23:14:00 CET] <Nune> furq: ^ [23:14:09 CET] <furq> http://vpaste.net/d1MHP [23:14:15 CET] <furq> that's all you need for a crossfade [23:14:27 CET] <Nune> thank you, reading and trying [23:14:39 CET] <furq> you could just encode that to something lossless and then trim the start and end off to get a perfect loop [23:15:10 CET] <Nune> right.. [23:15:23 CET] <furq> you could probably do that in the same command [23:15:29 CET] <Nune> is there a way to do this from an image sequence? [23:15:33 CET] <Nune> that's my original source content [23:15:43 CET] <furq> just replace the inputs with img%03d.png or whatever you've got [23:15:49 CET] <Nune> right [23:16:15 CET] <furq> and replace st=4 in the 0:v filter, and FRAME_RATE*4 in the 1:v filter, to your input length minus one second [23:16:31 CET] <furq> or however long you want the fade to be (in which case change d=1 too) [23:16:37 CET] <Nune> right [23:16:42 CET] <Nune> 1s fade should be fine [23:17:05 CET] <Nune> st=4; is that the start point of the fade out? [23:17:39 CET] <furq> yeah [23:18:12 CET] <Nune> i think i need that to be st=5 then, since the original clip is 6s long [23:19:13 CET] <Nune> receiving 3 warnings that "Past duration 0.619.. too large" [23:20:30 CET] <Nune> regardless, it yielded a result; which i then trimmed [23:20:38 CET] <Nune> didnt seem to give the right result tho [23:20:51 CET] <furq> [0:v][tmp3]overlay,trim=start=1:end=6[out] [23:20:56 CET] <furq> that should give you a perfect loop [23:21:11 CET] <furq> the start will be offset but i guess that's not a problem [23:21:13 CET] <Nune> http://vpaste.net/eyKCE [23:21:23 CET] <Nune> yeah offset wouldnt matter [23:21:41 CET] <furq> yeah just replace the existing overlay bit of the filterchain with that [23:21:42 CET] <Nune> thanks for the help [23:21:45 CET] <Nune> ok [23:22:37 CET] <furq> oh [23:22:39 CET] <Nune> not sure what the FRAME_RATE bit is; do I want FRAME_RATE*5 since its 6s long? [23:22:43 CET] <furq> yeah [23:22:44 CET] <Nune> k [23:22:44 CET] <furq> i was just typing that [23:22:51 CET] <Nune> did i find all the other 4->5 caveats? [23:22:59 CET] <furq> that offsets the timestamps of the second input by FRAME_RATE*5 frames [23:23:06 CET] <Nune> ah [23:23:10 CET] <furq> those are the only two [23:23:46 CET] <Nune> hmm [23:23:49 CET] <Nune> ok, properly yields a 5s clip [23:23:54 CET] <Nune> not seamlessly looping though [23:24:06 CET] <Nune> http://vpaste.net/om89L [23:25:55 CET] <Nune> this is my image sequence -> video snippet, btw: http://vpaste.net/BVGTT [23:26:29 CET] <furq> you can probably just use the sequence as inputs to the main command [23:26:34 CET] <Nune> ahuh [23:27:02 CET] <furq> cropdetect doesn't actually crop btw [23:27:10 CET] <furq> it just prints out the params you should use with crop [23:27:14 CET] <Nune> thats.. what i thought... but then it did? [23:27:30 CET] <furq> er [23:27:34 CET] <furq> well it shouldn't have ;_; [23:28:03 CET] <Nune> was anticipating needing to take the final result (aggregate crop dimensions?) and plug that into a crop filter, but the output was cropped already so i went with it :P [23:28:10 CET] <furq> weird [23:28:31 CET] <furq> well yeah if nothing else you shouldn't use webm for that, use something lossless like ffv1 [23:28:43 CET] <furq> otherwise you're compressing it twice [23:28:50 CET] <Nune> i see.. [23:29:08 CET] <Nune> (very new to ffmpeg) [23:29:49 CET] <Nune> happy to rework that and optimize it, but want to get the seamless transition part ironed out first [23:30:02 CET] <Nune> something isnt quite right with what ive got so far [23:30:07 CET] <furq> not sure about that [23:30:43 CET] <furq> i just tried with that exact filterchain and it works [23:30:52 CET] <Nune> hmm [23:31:08 CET] <Nune> trying again then [23:31:19 CET] <furq> http://vpaste.net/Xc56J [23:31:22 CET] <furq> that's the exact command i used [23:31:43 CET] <furq> i changed color=black:d=10 but i don't think that should matter [23:32:01 CET] <furq> that shouldn't be visible after 8 seconds and you're trimming before then anyway [23:32:52 CET] <Nune> how do you define 'testsrc' in this command? [23:33:01 CET] <furq> -f lavfi -i testsrc is just a builtin test video source [23:33:04 CET] <Nune> oh [23:33:09 CET] <furq> it displays colour bars and a timestamp [23:33:34 CET] <furq> what player are you using btw [23:33:39 CET] <furq> maybe it's hitching at the loop point [23:33:53 CET] <Nune> VLC (quick test) and OBS Studio (final usage) [23:33:55 CET] <furq> `mpv --loop-file=inf out.mkv` works here [23:35:35 CET] <Nune> dialog_line_cropped.webm: https://drive.google.com/open?id=0B3kkDhHHsCMhMmVGNzlIRktKWTg [23:36:24 CET] <Nune> i rendered your exact command with the testsrc, worked fine; replaced testsrc definition with ^ content and unless im asking the wrong question, didnt seem to work as expected [23:37:19 CET] <Nune> though it also played to 6s, not 5s, so maybe it is setup but didnt trim properly, trimming manually.. [23:37:57 CET] <furq> weird, doesn't work here either [23:38:11 CET] <Nune> hmm newp [23:38:33 CET] <Nune> glad im not crazy then, could it be a problem with using .webm? i can render another format [23:38:41 CET] <furq> maybe try using the image sequence as inputs [23:38:44 CET] <Nune> ok [23:39:09 CET] <phillipk> Is there a way to figure out exactly the version of ffmpeg I have if I got a compiled one--for ffmpeg -version I see: N-71481-g1c37848 [23:39:59 CET] <drv> that g<hex stuff> at the end is the git short hash [23:41:00 CET] <phillipk> right on [23:44:52 CET] <Nune> furq: no dice [23:45:20 CET] <Nune> yielded a 6s video that loops at 5s, but not seamless [23:45:42 CET] <Nune> maybe has to do with the alpha data in the images? its a semi-transparent render [23:46:11 CET] <furq> those webms are yuv420p so that shouldn't make any difference [23:46:53 CET] <Nune> any chance youd be interested in the source content (image sequence)? tho i dont see why starting with them vs the dialog_line_cropped.webm would be any different [23:47:15 CET] <furq> oh hang on [23:47:34 CET] <furq> try with color=black=d:10:s=976x400 [23:47:55 CET] <Nune> sure [23:48:11 CET] <furq> lol [23:48:15 CET] <furq> yeah i think that's it [23:49:27 CET] <Nune> getting an argument error with that [23:50:06 CET] <furq> d=10 sorry [23:50:15 CET] <Nune> ah [23:51:37 CET] <furq> actually nvm it's something different [23:51:46 CET] <Nune> hehe [23:51:46 CET] <furq> if i remove trim the output file is still 6 seconds long [23:51:51 CET] <furq> something's gone to fuck with the timestamps [23:52:16 CET] <Nune> possible the input is broke? [23:52:34 CET] <Nune> maybe since its the cropdetect output? i did try from the images tho, so cant JUST be that. [00:00:00 CET] --- Sat Jan 28 2017

1 0

ffmpeg-devel.log.20170126
by burek 27 Jan '17

27 Jan '17

[01:14:38 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:3e3e095fc903: avformat/options_table: Set the default maximum number of streams to 1000 [01:14:39 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:9519b2560e18: avformat/utils: Print verbose error message if stream count exceeds max_streams [01:14:40 CET] <cone-947> ffmpeg 03Chris Cunningham 07release/3.2:533431d5af92: avformat/mp3dec: fix msan warning when verifying mpa header [01:14:41 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:7643e8584f3a: avutil/random_seed: Improve get_generic_seed() with higher precission clock() [01:14:42 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:07df85b9586f: swscale/swscale: Fix dereference of stride array before null check [01:14:43 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:ceeeccc86211: avutil/random_seed: Reduce the time needed on systems with very low precission clock() [01:14:44 CET] <cone-947> ffmpeg 03Matt Wolenetz 07release/3.2:2481f1320a7f: lavf/utils.c Protect against accessing entries[nb_entries] [01:14:45 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:cd81993070e8: avcodec/mjpegdec: Check for rgb before flipping [01:14:46 CET] <cone-947> ffmpeg 03Tobias Rapp 07release/3.2:d5154c055bab: avformat/avidec: skip odml master index chunks in avi_sync [01:14:47 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:7d222736c27e: avcodec/omx: Do not pass negative value into av_malloc() [01:14:48 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:3442c20c4d38: avcodec/bsf: Fix av_bsf_list_free() [01:14:49 CET] <cone-947> ffmpeg 03Andreas Cadhalpun 07release/3.2:41fc098a8612: libopenmpt: add missing avio_read return value check [01:14:50 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:bd6c1d5149fb: avcodec/pngdec: Fix off by 1 size in decode_zbuf() [01:14:51 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:14f555683a98: avcodec/mjpegdec: Check remaining bitstream in ljpeg_decode_yuv_scan() [01:14:52 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:dd36b3a06a0a: avcodec/vp56: Check for the bitstream end, pass error codes on [01:14:53 CET] <cone-947> ffmpeg 03Michael Niedermayer 07release/3.2:dc2d3856f300: avcodec/utils: correct align value for interplay [01:14:54 CET] <cone-947> ffmpeg 03Frank Liberato 07release/3.2:cc662476031b: avformat/flacdec: Check avio_read result when reading flac block header. [02:43:10 CET] <Zeranoe> A little off topic, but what editors/IDEs are the devs using for FFmpeg? [02:43:54 CET] <atomnuker> gedit [02:59:46 CET] <cone-947> ffmpeg 03Andreas Cadhalpun 07release/3.2:884cd3caa5cc: swscale: save ebx register when it is not available [03:42:53 CET] <BBB> Zeranoe: XCode [04:14:17 CET] <Zeranoe> Why isn't there a hwcontext file for OpenCL? [04:14:56 CET] <Zeranoe> (I'm more asking if there's a reason that there shouldn't be) [09:41:33 CET] <jkqxz> Zeranoe: There should be. Making it standalone isn't particularly useful, though, because all you can do is upload/process/download. It's only once you have mapping between hardware formats that it becomes of significant value. <https://lists.libav.org/pipermail/libav-devel/2016-November/080223.html> [09:42:11 CET] <wm4> you mean mapping to cuda surfaces and such? [09:42:22 CET] <wm4> oh wait cuda was nvidia's opencl, so maybe not [09:42:35 CET] <wm4> but maybe vaapi surfaces or d3d11 textures [09:42:37 CET] <jkqxz> VAAPI / QSV is the target there. [09:43:15 CET] <jkqxz> D3D whatever will also work. [09:43:37 CET] <wm4> what's the use case? filters? [09:45:01 CET] <jkqxz> Yeah. Run filters on your frames on the GPU without them ever coming to CPU memory. [10:03:45 CET] <wm4> jkqxz: currently I'm thinking of doing d3d11va -> d3d11 video proc (scaling/deint) -> qsv encoding, what do you think of that? [10:27:28 CET] <hyponic> Hello.. I am having an issue that requires libzvbi / ffmpeg to be modified. I am willing to pay someone to modify libzvbi / ffmpeg to do what i need. If you have the skill to do so or know who does please let me know. [10:36:44 CET] <kierank> what do you need? [10:36:49 CET] <hyponic> what i am trying to achieve is convert teletext subtitles to dvbsubtitles. [10:37:31 CET] <hyponic> kierank https://trac.ffmpeg.org/ticket/5913 [11:08:32 CET] <jkqxz> wm4: I think it's a thing? I certainly agree with the sentiment of using the platform decoder (VAAPI/DXVA) instead of QSV and only mapping to QSV for encode. [11:10:13 CET] <wm4> if by "thing" you mean mapping d3d11 to qsv, yes that seems to exist, haven't tried it yet though [11:13:10 CET] <jkqxz> That bit should be easy; you just make the QSV structure with references to the underlying platform surface. I have hwmap support for VAAPI <-> QSV in libav, but it needs better (not entirely hacked) device setup to be useful in filtering. [12:36:25 CET] <Polochon_street> hi wm4, I'm the one working on the duplicate id3 tags, quick question, how do you check after a read_header that the demuxer has (or hasn't) set any tag? [12:39:30 CET] <wm4> Polochon_street: if the demuxer did, it would add something to ->metadata, right? [12:39:39 CET] <Polochon_street> that's what I was doing, perfect! [12:39:53 CET] <Polochon_street> I thought there was something more than just checking s->metadata [12:40:09 CET] <Polochon_street> thanks! [12:40:33 CET] <wm4> so basically I'm saying it should do what you did, but in utils.c for all demuxers [12:40:44 CET] <wm4> not sure if the id3 reading code can be changed to that [12:40:47 CET] <wm4> +do [12:55:11 CET] <Polochon_street> wm4: alright thanks for your help, I've submitted the new version :) [13:13:05 CET] <wm4> libswscale/bayer_template.c:197:1: internal compiler error: in have_bool_attr, at recog.c:2044 [13:13:06 CET] <wm4> wat [13:14:24 CET] <wm4> this is with mingw... very annoying [13:15:37 CET] <wm4> and now the machine froze... so much for this [13:27:06 CET] <Polochon_street> wm4: is « Discarding ID3 tags because more suitable tags were found. » message for the id3 tags issue fine by you? [13:28:26 CET] <wm4> Polochon_street: yeah, sounds good (maybe "ID3 tag" instead of plural?) [13:29:48 CET] <Polochon_street> okay, done :) [13:57:07 CET] <Polochon_street> wm4: I'll make a last patch, but I didn't get which line is redundant in the duplicate ID3 patch? [14:00:45 CET] <wm4> Polochon_street: hm actually it's not redundant [14:01:11 CET] <wm4> I was thinking av_dict_free(&id3_meta); is always called in the end, but it actually is done only in the failure case [14:01:15 CET] <wm4> so my comment was wrong [14:02:15 CET] <Polochon_street> okay, but don't you think the av_dict_free(&id3_meta) should be called after the if ... else? [14:03:16 CET] <wm4> yeah it still needs to be freed in the case when both tags are present and the id3 one is rejected [14:03:37 CET] <wm4> sure is tricky [14:04:04 CET] <wm4> Polochon_street: also you can just do "s->metadata = id3_meta; id3_meta = NULL;" in the case when only the id3 tag exists [14:04:37 CET] <Polochon_street> so in both if and else, or right after? Even if the id3 tag doesn't exist, it is safe to free it right? [14:05:01 CET] <wm4> yes, it's safe to free if it's NULL [14:06:37 CET] <Polochon_street> wm4: something like http://sprunge.us/AiOd would do? [14:11:22 CET] <wm4> Polochon_street: unfortunately the "return AVERROR_INVALIDDATA;" can still leak it [14:11:42 CET] <wm4> maybe move av_dict_free(&id3_meta); into the else branch, before the return happens [14:12:55 CET] <Polochon_street> it looks like this now http://sprunge.us/aTfj [14:13:21 CET] <wm4> looks good [14:16:59 CET] <Polochon_street> alright I'll send it to the ML after lunch, thanks :) [15:26:19 CET] <durandal_1707> atomnuker: is it possible to code arbitary fir filter which would use user supplied coefficients, just using ffmpeg code? [15:39:15 CET] <atomnuker> durandal_1707: check out psy_hp_filter() in libavcodec/aacpsy.c [15:39:30 CET] <atomnuker> PSY_LAME_FIR_LEN is the order, psy_fir_coeffs[] are the coefficients [15:39:59 CET] <atomnuker> I think if you change those to what you need and remove the 32768.0f normalization at the end it should work [15:42:06 CET] <atomnuker> or just code it yourself, the first formula from the wikipedia page looks simple [15:43:21 CET] <atomnuker> (at least its not a serial filter where the previous output modifies the current output, fuck those well) [15:47:24 CET] <durandal_1707> atomnuker: i mean fir filter as used in sox [15:47:57 CET] <durandal_1707> user supplies some floats and thats it [15:48:34 CET] <durandal_1707> our rdft works only with power of two [15:50:48 CET] <atomnuker> I guess not, if the user supplies floats you count them, figure the order out and run the filter [15:51:09 CET] <atomnuker> (who'd want that when you can apply arbitrary expressions in the frequency domain though) [15:53:57 CET] <durandal_1707> atomnuker: people puts coefficients of size 128 into wav file as 16bit pcm [15:54:12 CET] <durandal_1707> 128 samples [15:55:59 CET] <atomnuker> damn, I guess you just convert them to float, you can probably see how sox does it if it can do it [16:00:33 CET] <durandal_1707> i think i will limit it power of 2 sizes [16:22:39 CET] <cone-165> ffmpeg 03Paul B Mahol 07master:ee8e00b70396: avfilter: add abitscope multimedia filter [17:08:50 CET] <durandal_1707> ubitux: didnt you wanted to write such filter? [17:09:34 CET] <ubitux> which one? abitscope? [17:31:52 CET] <durandal_1707> ubitux: arbitrary FIR [17:32:26 CET] <ubitux> ah yeah indeed [17:33:16 CET] <ubitux> but i gave up with life since working on subtitles and libav merges, so i'm ok with not writing it myself ;) [17:40:57 CET] <ubitux> 17:42:12 <@ubitux> http://hajo.me/blog/2014/12/28/how-surround-sound-for-headphones-works/ [17:40:59 CET] <ubitux> 17:42:18 <@ubitux> this one might be interesting [17:41:01 CET] <ubitux> 17:43:00 <@ubitux> also a generic FIR filter can be written relatively easily [17:41:05 CET] <ubitux> this is indeed what triggered be at that time [17:41:18 CET] <ubitux> (Feb 15 2015) [17:41:58 CET] <ubitux> i guess i wanted an arbitrary fir filter system to experiment stuff [17:54:49 CET] <durandal_1707> what about libav bitstream reader? [17:55:17 CET] <durandal_1707> it have some good and bad points [17:59:48 CET] <ubitux> we have a few thousands commits to merge before reaching the bitstream reader [17:59:56 CET] <ubitux> so you have time [18:07:34 CET] <atomnuker> the benchmark linked here had some unacceptably big regressions on 32 bits and only huffyuv had gains in some cases [18:10:59 CET] <durandal_1707> atomnuker: isnt it other way around?, smaller - better [18:12:03 CET] <iive> no [18:12:11 CET] <atomnuker> performance gains go the other way around [18:12:47 CET] <iive> we had bitstream reader that worked on same concepts, storing 64 bits in a tmp buffer, but it was slower, back in the time before 64 bit. [18:12:51 CET] <ubitux> the 32-bit tests are on x86 or arm btw? [18:13:36 CET] <iive> think of it like this. each memory access is one operation. [18:13:51 CET] <iive> you read the buffer and you shift it. that's 2 operations. [18:14:54 CET] <iive> on 32 bit, with 64 bit buffer, you have 2 ops for reading and 2 ops for shifting. making 4 operations. [18:19:33 CET] <iive> if you use 32 bit buffer on 32 bit, then you have 2 ops, however reading directly from the bitstream buffer also takes 1 or 2 ops. [18:21:59 CET] <atomnuker> you still have to AND the buffer with (1 << bits) - 1 [18:22:34 CET] <iive> the buffer helps also with the overflow checks. you can skip checks for the end of the bitstream, Once again, it gives better results with bigger cache. [18:25:42 CET] <iive> s/the buffer/ the cache [18:25:44 CET] <iive> sorry [18:35:28 CET] <iive> atomnuker: memory operations could be the slowest ones, if we have cache miss (video trashes a lot of data). Second comes conditions&branches. Logical operations are among the fastest especially if you don't have data dependency. [18:48:05 CET] <iive> (just to be clear, by shifting above i mean writing the shifted values back to the cache buffer) [19:23:01 CET] <wm4> isn't it only a few hundred commits [19:23:04 CET] <wm4> not a few thousands [19:57:44 CET] <ubitux> wm4: sorry yes, thousands obviously [19:57:53 CET] <ubitux> hundreds* [19:57:56 CET] <ubitux> damn it [20:16:23 CET] <BBB> haha [20:19:44 CET] <cone-619> ffmpeg 03Joel Cunningham 07master:f3778108d3eb: tcp: set socket buffer sizes before listen/connect/accept [21:33:19 CET] <jamrial> 3.3 changelog looks a bit short. we should pad it :p [21:36:47 CET] <wm4> the delayed merges show [21:42:44 CET] <jamrial> i guess. but it's mostly that durandal_1707 wrote a billion filters for the last couple releases [21:42:57 CET] <jamrial> so those got a lot of entries [22:22:41 CET] <ubitux> billion, thousands or hundreds? [22:56:59 CET] <llogan> anyone want to write RELEASE_NOTES? [22:59:34 CET] <atomnuker> can audio encoders get fed NULL frames in between encoding (before they get NULL at the end to flush)? [23:06:33 CET] <wm4> hmmm I would guess no, but wasn't there something weird about 0 sized packets that transport sid data for changing something [23:06:39 CET] <wm4> *side [23:30:59 CET] <cone-619> ffmpeg 03James Almer 07master:1ae39429e4c4: avformat/matroskadec: ProjectionPrivate is optional on Equirectangular projections [23:46:39 CET] <philipl> BtbN: should mention dynlink cuda in changelog. [23:46:58 CET] <BtbN> hm [23:47:22 CET] <BtbN> yeah, maybe [00:00:00 CET] --- Fri Jan 27 2017

1 0

ffmpeg.log.20170126
by burek 27 Jan '17

27 Jan '17

[00:38:59 CET] <rafasc> I am trying to record audio and video from my webcam, But the audio is desync'd. [00:39:02 CET] <rafasc> http://pastebin.com/xnUSrxbq [00:41:25 CET] <rafasc> http://pastebin.com/3Jqvwpu5 [00:48:39 CET] <llogan> are you sure toy need -ts and -af? [00:48:47 CET] <llogan> "you", not "toy" [00:54:59 CET] <rafasc> I put those options trying to fix the issue. [00:55:12 CET] <rafasc> but with no success. [01:35:37 CET] <tdude51> Hi folks, I'm attempting to capture NTSC composite video from a USB UTV007 capture card on my Raspberry Pi 3 Model B, and I'm getting the error "Dequeued v4l2 buffer contains corrupted data (691200 bytes)". I built ffmpeg using this guide: http://hannes.enjoys.it/blog/2016/03/ffmpeg-on-raspbian-raspberry-pi/ . I'm using the command "ffmpeg -f v4l2 -s 720x480 -i /dev/video0 -vf yadif -c:v libx264 -preset ultrafast test_ffmpeg.flv -y". [01:35:43 CET] <tdude51> The identical version of the command works fine when I use the version of avconv installed from the raspberry pi's built in package manager. The video generated by ffmpeg seems to have drops in framerate, but the video generated by avconv plays fine at 29.97fps. I ran both commands for ~10 seconds and they both had ~40% CPU usage throughout. I've included the commands and output from both in the following pastebin: http://pastebin.co [01:38:28 CET] <llogan> your paste was cut off [01:39:14 CET] <tdude51> What was in the pastebin, or one of my messages? [01:45:31 CET] <furq> the url [01:47:52 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [01:48:09 CET] <furq> if you're not using the builtin h264 encoder then you might as well use the armhf builds on there [01:49:07 CET] <furq> i'm not sure why that guide recommends building with --arch=armel, but i'm not sure if that actually does anything with ffmpeg's build system [01:49:21 CET] <furq> or why it recommends building x264 with --host when you're not cross-compiling [01:51:33 CET] <tdude51> http://pastebin.com/WMAfuuzV is the pastebin [02:11:00 CET] <tdude51> i had the same issue with both static arm builds. I'll see what I can do about making use of the builtin h264 encoder, I was unaware of that. thanks for your help. [02:43:00 CET] <Hexmind> Hi all. In a game I'm developing I want to implement video export. For now I save every frame to sequenced images and then from the command I create video with the images. I was wondering if it's possible to create a video directly from within the game using the ffmpeg api, and if so, what functions should I look into. [02:50:50 CET] <DHE> Hexmind: you'll need to deal with the libavcodec layer to encode audio and video, and libavformat to deal with the file IO [02:52:48 CET] <Hexmind> DHE, I'll look into those. thanks [02:54:42 CET] <DHE> Hexmind: http://ffmpeg.org/doxygen/3.2/group__lavf__encoding.html#details This gets you started on the file writing [03:21:45 CET] <faLUCE> I'm really getting crazy with these pts. I think that I have done all properly, but there's something wrong. I encode (mp2) into an AVPkt a frame of 1152 samples at each cycle, taken from an audio device set at 1/16000 sample rate. Then I compute the pkt's pts in this way: encodedAudioPkt.pts = 1152*cycleCounter; . Then I don't understand how to rescale this to the mpegts (stream) time_base. I tried with av_ [03:21:46 CET] <faLUCE> rescale_q(encodedAudioPkt.pts, audioEncoderTimeBase, mpegtsTimeBase) , where audioEncoderTimeBase is 1/16000, but in this way the packets are not synced with the system clock.... What I have to do? here's a very short snippet of my code, I don't understand what's wrong: http://paste.ubuntu.com/23867038/ [06:16:12 CET] <damdai> i found a bug in VLC but they are not willing to fix it : http://imgur.com/a/yvyyO [06:26:19 CET] <kepstin> damdai: so, why complain about it here?... [06:26:33 CET] <the_k> hello [06:26:55 CET] <damdai> kepstin i think there are lot of vlc supports here [07:14:16 CET] <Kuukunen> kepstin: he's been spamming that same thing to multiple unrelated channels for many days now [07:38:20 CET] <the_k> i'm saving an rtsp stream to disk but would like to be able to play the recorded stream file as it's being recorded.. any ideas? [08:24:38 CET] <xtina> hey guys. i have ffmpeg-3.1.4-armel-32bit-static.tar.xz on a Pi Zero and am having DNS issues streaming to rtmp urls that include domain names, so I've been forced to stream directly to IP addresses [08:27:10 CET] <xtina> i'm finding this unreliable, and would like a better solution. any suggestions? [08:27:39 CET] <xtina> is there a different version of ffmpeg that is compatible with the Zero, where I can stream directly to rtmp domains? [08:32:49 CET] <bencoh> I somehow doubt your dns issues come from ffmpeg (?) [08:37:53 CET] <xtina> @bencoh: i believe it does, i think i manually compiled ffmpeg with the help of some folks here, who realised the dns issues with my package [08:38:03 CET] <xtina> but different ffmpeg packages can't build properly on the zero (?) [08:38:06 CET] <xtina> my memory is a little hazy [08:38:27 CET] <xtina> but i had this same conversation a while back with guys in here, who reproduced my issue on their own machines [08:38:35 CET] <bencoh> okay [08:39:37 CET] <xtina> if there's a way to find historical logs for this channel, I can bring up the conversation we had about this previously? [08:43:19 CET] <xtina> @furq i think i remember us talking about this... [10:26:25 CET] <hyponic> Hello.. I am having an issue that requires libzvbi to be modified. I am willing to pay someone to modify libzvbi / ffmpeg to do what i need. If you have the skill to do so or know who does please let me know. [11:49:18 CET] <thebombzen> hyponic: well if libzvbi needs to be modded why are you asking in #ffmpeg [11:51:08 CET] <hyponic> thebombzen because i am not sure what needs to be modded. i just want the solution to work and i know there is a lot of capable people here that might be able to get it done. and i am willing to pay a bit to get it done. [11:51:55 CET] <thebombzen> well keep in mind you just waltzed into a FOSS channel and said "I will pay someone here to get this done" [11:53:00 CET] <thebombzen> especially since you say "I want a modded version of zvbi/ffmpeg" but didn't say what you need [11:53:27 CET] <thebombzen> most people will see that and be like "oh you need a modded version, that's nice, why don't you rename it or something then it'll be modified" [11:53:51 CET] <thebombzen> if you don't ask the question you want answered and instead are extremely vague, nobody's going to be able to help you [11:55:49 CET] <hyponic> thebombzen you are absolutely right.. i am sorry about that! [11:56:44 CET] <hyponic> What i want done is to be able to covert teletext subtitles to dvbsubtiles. https://trac.ffmpeg.org/ticket/5913 [11:57:00 CET] <hyponic> I am not sure how to explain it more to be honest. [11:58:44 CET] <thebombzen> it looks like you can do that with swscale [11:58:57 CET] <thebombzen> also when the maintainer changes the priority to "wish" [11:59:06 CET] <thebombzen> don't go and change it back to "important" you're just wasting everyone's time [11:59:22 CET] <thebombzen> that's a great way to get the ffmpeg devs to ignore the ticket [12:00:28 CET] <hyponic> thebombzen swscale ? i am not sure what you mean! [12:01:26 CET] <hyponic> thebombzen yeah.. i am new to the trac thing and it's not even my ticket. all i wanted to do was to say that i would sponsor a solution for it. My bad. :S [12:02:08 CET] <thebombzen> so an issue is "important" if it's like "ffmpeg can't decode h.264 streams encoded with libx264" [12:02:22 CET] <thebombzen> given that that issue will affect lots of people and break workflows, that's important [12:02:43 CET] <thebombzen> an issue like "ffmpeg has a security hole CVE-X that's easily exploitable" would be critical [12:02:58 CET] <thebombzen> something like "I want zvbi to do this one weird thing with ffmpeg for my own personal project" is neither [12:03:00 CET] <thebombzen> and you should know that [12:04:10 CET] <thebombzen> have faith and respect the people who know what they're doing - if a maintainer changes the priority to "wish" you should respect that they know what "wish" means and that they know that the ticket blongs there [12:04:55 CET] <hyponic> thebombzen you are right.. sorry about that. [12:08:06 CET] <hyponic> thebombzen how can swscale do it? [12:08:15 CET] <thebombzen> http://www.google.com/ [12:08:48 CET] <thebombzen> I'm not sure, that's just a guess [12:08:54 CET] <thebombzen> but start by learning what swscale is [12:09:03 CET] <thebombzen> meanwhile I'm going to get some sleep [12:46:47 CET] <mixfix41> c\\ [13:48:57 CET] <dooome> hello! [13:49:24 CET] <dooome> cant resize one of my testvideos for some reason [13:49:27 CET] <dooome> [h264 @ 0x29112c0] Aspect ratio mismatch between muxer (3200/3213) and encoder layer (1/1) [13:50:14 CET] <dooome> there must be something I can do to get it to work [13:50:27 CET] <dooome> http://pastebin.com/htFxapME [13:54:40 CET] <dooome> (I'm sorry for changing anamorphic, but I need to do that..) [14:12:06 CET] <dooome> never ming [14:12:08 CET] <dooome> mindÄ [14:12:11 CET] <dooome> * [14:12:16 CET] <dooome> think i've got it [15:14:06 CET] <NermaN> Hello, why ffmpeg freezes just after start? [15:14:22 CET] <NermaN> http://pastebin.com/2MmJBY04 [15:20:51 CET] <jkqxz> The encode driver hasn't produced any output? "[h264_vaapi @ 0x55945a613760] Output buffer: 0 bytes (status 00000000)." [15:21:31 CET] <jkqxz> What platform / driver is it using? [15:21:56 CET] <jkqxz> Also maybe try with the encoder on its own, not using the decode hwaccel at the same time. [15:23:11 CET] <NermaN> jkqxz: vainfo: VA-API version: 0.39 (libva 1.7.3) vainfo: Driver version: Intel i965 driver for Intel(R) Ivybridge Mobile - 1.7.3 [15:23:19 CET] <NermaN> jkqxz: linux [15:25:04 CET] <NermaN> jkqxz: disabling hwaccel does not change anything =( [15:27:36 CET] <jkqxz> Anything interesting about the input file? [15:29:45 CET] <NermaN> jkqxz: no, just simple h264 1920x1080 file without audio [15:29:49 CET] <jkqxz> Also how frozen is it? Can you get a backtrace from gdb? Are there any nasty messages in the kernel log? [15:30:44 CET] <jkqxz> (Same command works for me on Haswell.) [15:31:35 CET] <NermaN> jkqxz: it just stops on last message of log. Nothing on kernel log [15:36:30 CET] <jkqxz> Run in gdb, control-c after it's frozen, backtrace? [15:37:07 CET] <jkqxz> You could also try current git, though I don't think there will be any interesting difference. [17:59:39 CET] <lacrymology> hellp [17:59:42 CET] <lacrymology> hellO [18:00:20 CET] <lacrymology> is there any easy way to create a video that's just a black square with a timestamp? [18:03:43 CET] <furq> nullsrc and drawtext [18:03:49 CET] <furq> or color and drawtext, rather [18:17:03 CET] <phillipk> I have an issue with my script--I'm layering in a few audio files on top of a video that has audio and video. The primary issue is the output puts audio in stream 1 and video in stream 2--I want it in the other order--see command: http://pastebin.com/uN5nnSCr [18:42:31 CET] <IamTrying> 3 Books i bought on FFMpeg. But none of the book talks about how to use FFMpeg to create virtual webcam in Windows OS? [18:47:24 CET] <durandal_1707> who told you to buy books about FFMpeg instead of FFmpeg? [18:52:40 CET] <phillipk> are there any books? I've learned the most on this irc, friends, stackoverflow (of course), and the ffmpeg wiki (ffmpeg docs too, but they're not set up the way I learn anyway). [18:54:18 CET] <IamTrying> durandal_1707, phillipk no one, i am in the middle of project where i need to make a webcam source for directshow. i was 100% sure like FFMpeg is best expert multi media tool, it must have some sample. But i was obviously wrong even FFmpeg experts does not had any sample. was shocking [18:56:07 CET] <durandal_1707> IamTrying: im not on windows so i cant help you [18:56:56 CET] <IamTrying> http://www.e2esoft.cn/vcam/vcamsdk.asp - something like this i need but open-source, just to get the idea how its made. then i can write my own C++ prototype [19:48:12 CET] <CesarSouza> Hello, anybody could help me find some information on how to debug an errorcode -22 when calling avcodec_open2() on Windows (using Zeranoe's builds)? [19:49:13 CET] <Zeranoe> CesarSouza: How are you calling it? [19:51:18 CET] <BtbN> using av_strerror would be a good start [19:51:34 CET] <CesarSouza> well, passing a codecContext that is coming from a AVStream that I got from calling avformat_new_stream [19:51:35 CET] <DHE> under linux that means Invalid Argument [19:52:00 CET] <DHE> was there anything logged to stderr at the same time? (or if you redirect logging yourself, to your log target) [19:52:04 CET] <CesarSouza> BtbN hey thanks I wasn't aware of strerror [19:53:17 CET] <DHE> ah, you're on windows [19:58:29 CET] <CesarSouza> I am trying to setup a better test environment, it seems VS wasn't capturing stdout or stderr when the code runs from a unit test [20:25:18 CET] <kira666> hello i have a question related to embed h.265 with ffmpeg. [20:26:46 CET] <llogan> what is your question? [20:28:41 CET] <kira666> i changed the h.265 code for my college project and i want to embed with ffmpeg so i can use like streaming features but the video will encode with my customized h.265. please can you tell how i embed my h.265 with ffmpeg [20:29:28 CET] <Zeranoe> kira666: The decoding H.264 code in FFmpeg, or libx264? [20:29:30 CET] <spiderkeys> does anyone know if the HRD parameters in h264 SPS NALs are critical for decoding? [20:30:40 CET] <kira666> H.265 [20:31:09 CET] <JEEB> spiderkeys: I think they're mostly meant for the decoder making sure it buffers enough (and for verification) [20:31:22 CET] <kira666> @zeranoe H.265 encoder [20:31:41 CET] <kira666> i am pretty noob [20:31:54 CET] <JEEB> kira666: libavcodec itself doesn't contain HEVC encoding, you would have to patch one of the encoders that can be used through it (libx265, libkvazaar etc) [20:32:04 CET] <JEEB> and then link your FFmpeg to that :P [20:32:27 CET] <JEEB> of course, if you break the HEVC spec with your bit stream then good luck and have fun of course [20:32:39 CET] <JEEB> because absolutely nothing will be able to decode your thing [20:34:27 CET] <spiderkeys> JEEB: Yea, I ran into a situation where not having the bitstream_restriction_flag and max_frame_num_reorder fields set caused the hardware decoder to expect 15 frames, introducing a half second latency at 30fps. The library that I'm using to read and write SPS NALs has an incorrect implementation of read/write exponential golomb, so it fails to properly read and write bit_rate_value_minus1 and cpb_size_value_minus1, since the values in h264 can be [20:34:27 CET] <spiderkeys> larger than it is written to handle. Since those are the only two problematic values, I was thinking of just leaving the HRD section out [20:34:48 CET] <spiderkeys> But I don't want to run into a new latency problem by taking them out :P [20:35:22 CET] <Zeranoe> spiderkeys: This is a library that isn't currently supported by FFmpeg? [20:35:48 CET] <kira666> my customized code H.265 is working. i have encoded successfully and decoded using mplayer. but to stream it i want to use ffmpeg. please can you tell me how to libx265 with mycode [20:35:49 CET] <JEEB> spiderkeys: it really depends on how your exact thing you're going to be using for decoding behaves :P [20:35:54 CET] <spiderkeys> Zeranoe: it is h264bitsream: https://github.com/aizvorski/h264bitstream [20:36:05 CET] <spiderkeys> It had a bunch of other bugs too, which I fixed [20:36:39 CET] <spiderkeys> ffmpeg has a correct implementation for golomb exponentials, but it doesnt have a public API for parsing and modifying SPS NALs in the c library [20:37:11 CET] <spiderkeys> I was going to work at upgrading h264bitstream to use ffmpeg's implementation, but that will take a while, so I'm exploring temporary solutions [20:38:09 CET] <llogan> kira666: at the very least: "./configure --enable-gpl --enable-libx265" [20:38:39 CET] <JEEB> spiderkeys: personally I would just poke the decoding thing so it would start playback ASAP if you know your network will always be way faster than what you're doing [20:38:57 CET] <JEEB> unless you know your HRD info that the encoder is writing is incorrect [20:39:11 CET] <JEEB> in which case I would propose a bug report or a patch to the encoder [20:40:14 CET] <kira666> llogan can i have to compile my code with ffmpeg using --enable libx265 [20:40:40 CET] <llogan> you can haz ffmpeg use libx265 [20:42:00 CET] <kira666> llogan is there any thing so i can replace it from linux without recompiling whole ffmpeg with it [20:42:29 CET] <furq> ./myencoder - | ffmpeg -f h265 -i - [20:43:09 CET] <furq> if you have a patched libx265.so you can try replacing your system one with it, but that's probably going to break [20:43:38 CET] <kira666> can you explain above command [20:45:05 CET] <kira666> furq can you explain above command [20:49:09 CET] <llogan> it is piping the output from "myencoder" into ffmpeg [20:49:36 CET] <llogan> basic linux stuff [20:50:15 CET] <Zeranoe> Hey, Windows has that too llogan [20:50:24 CET] <Zeranoe> Basic computer usage? [20:50:58 CET] <spiderkeys> JEEB: Yea, the only reason I found out there was an issue was that the Chromium team told us that the hardware decoder was buffering because of the bitstream restriction flag (we are feeding in fragmented mp4 frames one by one to get super low latency livestreaming in the browser). Unfortunately, our camera doesn't expose an API to the SPS settings that we need to change and the firmware is proprietary :( [20:51:19 CET] <JEEB> rip you then [20:51:28 CET] <JEEB> my condolences [20:52:22 CET] <spiderkeys> I've successfully modified the SPS in the way I need, the only issue being I have to remove the HRD fields. I guess we'll see if that introduces any new problems haha [20:52:24 CET] <kira666> Thankyou for your help llogan JEEB furq [20:52:50 CET] <spiderkeys> I wish h264bitstream was still actively developed, really deserves some love and attention [20:53:11 CET] <JEEB> those kinds of tools usually end up just being something used for a trick or two [20:53:13 CET] <spiderkeys> or alternatively, I wish libx264 also had parsing functionality [20:53:30 CET] <JEEB> also there's an ancient patch to add bit stream filters into libavcodec [20:53:38 CET] <JEEB> that modify the contents of certain NAL units [20:54:01 CET] <JEEB> (can be found on doom9) [20:54:04 CET] <spiderkeys> Yea, unfortunately that patch didn't target the fields I needed [20:54:33 CET] <spiderkeys> I think no support for VUI parameters [23:17:41 CET] <throwaway> Hi, I am livestreaming from a Pi Zero, and I was instructed from this IRC channel to install the static ARMEL ffmpeg tar from https://www.johnvansickle.com/ffmpeg/. It is called ffmpeg-release-armel-32bit-static.tar.xz - md5 [23:18:14 CET] <throwaway> with this ffmpeg build, I'm forced to use the IP addresses in the RTMP URLs to avoid a DNS issue that others in this channel were able to Repro [23:18:40 CET] <throwaway> using the IP addresses has been fine for the Twitch and Youtube Live RTMP urls, but isn't working for Facebook Live [23:18:54 CET] <throwaway> I suspect it's because Facebook Live's URL seems to run across many IP addresses? [23:19:38 CET] <throwaway> I'm wondering what I should do. I remember someone in this chat telling me I could try using the armhf ffmpeg build with my Zero, but I'd have to do some stuff first, and I don't recall the details... [23:20:39 CET] <throwaway> furq: were we chatting about this? I recall your name, but it has been a while, haha [23:24:45 CET] <furq> oh right i'm pretty sure that's a librtmp issue [23:25:02 CET] <furq> actually maybe i'm thinking of something else [23:25:58 CET] <kerio> throwaway: any particular reason you're not installing ffmpeg from the repo? [23:26:08 CET] <furq> iirc the one from repos didn't work at all [23:26:21 CET] <furq> if it's a pi zero then it'll be raspbian which i think is still using libav [23:27:34 CET] <throwaway> right - and libav would not work for me, i tried for a very long time [23:28:46 CET] <throwaway> kerio: Pi Zeros/Pi 1s use ARMEL, i think in the ffmpeg repo it was ARMHF, only compatible with Pi 2+? [23:29:04 CET] <BtbN> armel just means little endian [23:29:06 CET] <kerio> soft float/hard float is only a software thing [23:29:09 CET] <furq> technically they're both armhf [23:29:12 CET] <BtbN> armhf means it has a hardware float unit [23:29:18 CET] <BtbN> But it's still little endian [23:29:25 CET] <furq> but debian's armhf packages are for armv7 [23:29:33 CET] <kerio> isn't hard float vs soft float just a different way to use the fpu registers [23:29:34 CET] <furq> the pi 1 and zero are armv6, which is why you need to use the armel packages [23:29:38 CET] <kerio> in the calling convention [23:29:40 CET] <BtbN> Yeah, the Pi CPU is a bit weird, being armv6 with hard floats [23:29:54 CET] <BtbN> Debian does not build packages for that combination [23:29:57 CET] <furq> that's why raspbian exists [23:30:10 CET] <throwaway> this is the command I used with Twitch live, it works perfectly [23:30:12 CET] <furq> running armel stuff on a hardfloat cpu is obviously less than ideal [23:30:32 CET] <throwaway> Hmm, I don't know why it won't let me post it.. [23:30:44 CET] <throwaway> command: /usr/bin/raspivid -o - -t 0 -vf -hf -fps 20 -b 6000000 | ./ffmpeg -f lavfi -re -i anullsrc -f h264 -thread_queue_size 512 -framerate 20 -probesize 100 -i - -vcodec copy -acodec aac -g 20 -f flv rtmp://192.108.239.81/app/live_109737872_ER4YNwvMbSrwalvK8YU2WUMmohP6rv [23:31:06 CET] <throwaway> it works perfectly. but when I replace the twitch RTMP URL (note the IP addr) with the facebook live one, I start to get RTMP header packet errors [23:31:09 CET] <furq> i know librtmp has some dns lookup issues but the one i'm thinking of is basic auth in rtmp urls [23:31:32 CET] <furq> but iirc i checked your issue with a native rtmp build and it didn't work [23:31:34 CET] <BtbN> you maybe should not share your streams credentials in a public IRC channel [23:31:38 CET] <throwaway> the only thing I'm switching is the rtmp url from twitch to fb. suspiciously I've noticed that when I lookup the Ip addr for the fb live domain, it changes frequently... [23:31:48 CET] <furq> yeah it'll do that [23:31:56 CET] <throwaway> BtbN, yes, whoops. it's a totally empty channel, but yes :) [23:32:31 CET] <throwaway> could that be causing this issue with facebook live? otherwise i'm not sure why it's the only domain causing rtmp header problems [23:32:53 CET] <furq> what, the ip changing? [23:32:56 CET] <furq> i doubt it [23:33:09 CET] <furq> you'll get the same thing with youtube and any sufficiently large org [23:33:11 CET] <BtbN> does rtmp send a Host-Header like http does? [23:33:44 CET] <furq> i remember trying the domain you pasted and it didn't work here, so i doubt it's down to dns caching or something like that [23:34:07 CET] <throwaway> I see. the FB Live RTMP url looks like this: rtmp://rtmp-api.facebook.com:80/rtmp/KEY [23:34:29 CET] <throwaway> I am not sure what IP to use to replace rtmp-api.facebook.com, as there are many.. [23:34:38 CET] <BtbN> any of them [23:34:51 CET] <BtbN> But why would DNS lookup not work? That makes no sense [23:35:34 CET] <furq> yeah the ip will work but there's a good chance the one you pick will become invalid at some point [23:36:09 CET] <throwaway> I am currently using rtmp://31.13.66.23:80/rtmp/KEY. here is the full pastebin of the log: http://pastebin.com/3CgEYwfJ [23:36:46 CET] <throwaway> ultimately it says Opening an output file: rtmp://157.240.3.12:80/rtmp/KEY. [rtmp @ 0x2a7ba00] No default whitelist set RTMP_ReadPacket, failed to read RTMP packet header rtmp://157.240.3.12:80/rtmp/KEY: Unknown error occurred [23:37:13 CET] <furq> well that's happening with the ip so it can't be a dns issue [23:37:13 CET] <throwaway> BtbN: I see, I am indeed just trying some of the IP addresses associated with that domain. [23:37:44 CET] <throwaway> it isn't a DNS issue, but i'm unsure what's causing the rtmp packet header issue, as I only see it with Facebook RTMP URL [23:38:05 CET] <furq> that could be any number of things [23:38:12 CET] <throwaway> could this indicate something wrong with how I configured the facebook livestream from the browser? [23:38:15 CET] <furq> invalid key, someone's already streaming to that channel, etc etc [23:38:20 CET] <throwaway> i'm unsure if it's related to ffmpeg [23:38:26 CET] <throwaway> I see [23:38:37 CET] <furq> afaik "failed to read packet header" normally just means the remote host closed the connection [23:38:52 CET] <furq> which could be down to anything [23:39:38 CET] <throwaway> I see. I'll investigate the configuration of the stream, then.. [00:00:00 CET] --- Fri Jan 27 2017

1 0