Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2017

1 participants
56 discussions

ffmpeg-devel.log.20170227
by burek 28 Feb '17

28 Feb '17

[10:29:02 CET] <cone-982> ffmpeg 03Carl Eugen Hoyos 07master:f8d2079a6786: ffmpeg: Add a linebreak to an error message. [10:58:28 CET] <pszemus> Hi, could anyone refer to http://ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207461.html ? I can provide more details about what I'm trying to accomplish there. [11:04:19 CET] <kierank> https://blog.sesse.net/blog/tech/2017-02-27-01-02_10_bit_h264_tests [11:21:27 CET] <JEEB> haha :D [11:21:40 CET] <JEEB> yea, the bad part is that all the AVC ASICs don't support it [11:41:34 CET] <JEEB> ugh, I still dislike the fact that the end of that article still tries to say that some things support 10bit AVC in HW, which is not true [11:41:51 CET] <JEEB> you might get very little artifacts out of decoding some samples as 8bit [11:41:57 CET] <JEEB> but it doesn't mean 10bit is supported [11:42:33 CET] <JEEB> and given how <beep> expensive any ASIC that supports even intra 10bit is, it's highly unlikely that anything that costs less than 1000 euros (or so) without the brand fee included has 10bit AVC support [11:46:35 CET] <jkqxz> Sounds like an opportunity for x264œ, which encodes to H.265 using only H.264 features (and is therefore much faster and simpler than x265). [11:47:53 CET] <JEEB> yea [11:49:01 CET] <JEEB> although quite a few people don't want to touch HEVC with a long stick [11:57:15 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:05aa53dc553a: avcodec/qdrw: fix decoding odd size images for 16bit case [11:57:16 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:dc78696ea4b8: avcodec/qdrw: fix decoding odd size images for 2bpp and 4bpp [11:57:17 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:1dcf91f2d360: avcodec/qdrw: fix decoding of odd sized images for 8bpp [12:06:39 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:3a7f8d2a1f30: avcodec/qdrw: consume bytes when end is reached for 8bpp case [12:22:58 CET] <wm4> jkqxz: deinterlace_vaapi gives me green (though admittedly I've only tried via mpv, so might be my fault) [12:23:46 CET] <jkqxz> Um, try not-via-mpv? [13:09:37 CET] <cone-982> ffmpeg 03Paul B Mahol 07h264_assembly:HEAD: avcodec/qdrw: consume bytes when end is reached for 8bpp case [13:09:59 CET] <J_Darnley> Oh shit. [13:10:21 CET] <J_Darnley> That's the wrong branch [13:11:14 CET] <cone-982> ffmpeg 03Carl Eugen Hoyos 07master:1e298e772400: lavc/svq3: Remove an unused function. [13:11:56 CET] <durandal_1707> J_Darnley: just push it to correct branch [13:12:04 CET] <durandal_1707> if possible [13:12:11 CET] <durandal_1707> :) [13:14:32 CET] <atomnuker> J_Darnley: you can't delete branches too so msg thresh to remove it [13:16:12 CET] <J_Darnley> Sorry, who? [13:16:46 CET] <durandal_1707> thresh on #videolan [13:22:42 CET] <cone-982> ffmpeg 03James Darnley 07master:5c56758843eb: avcodec/h264: add avx 8-bit chroma v deblock/loop filter [13:22:43 CET] <cone-982> ffmpeg 03James Darnley 07master:ac096fc82df6: avcodec/h264: add avx 8-bit 4:2:0 chroma h deblock/loop filter [13:22:45 CET] <cone-982> ffmpeg 03James Darnley 07master:88307b3eec01: avcodec/h264: add avx 8-bit 4:2:2 chroma h deblock/loop filter [13:22:45 CET] <cone-982> ffmpeg 03James Darnley 07master:987ffe4b8dce: avcodec/h264: add avx 8-bit chroma v intra deblock/loop filter [13:22:46 CET] <cone-982> ffmpeg 03James Darnley 07master:0e16b3e2be3a: avcodec/h264: add avx 8-bit 4:2:0 chroma h intra deblock/loop filter [13:22:47 CET] <cone-982> ffmpeg 03James Darnley 07master:cd893b9307b8: avcodec/h264: add avx 8-bit 4:2:2 chroma h intra deblock/loop filter [13:22:48 CET] <cone-982> ffmpeg 03James Darnley 07master:33de0fee2c33: avcodec/h264: enable sse2 chroma deblock/loop filter functions [13:38:10 CET] <J_Darnley> durandal_1707: I have but I guess he is offline/afk [13:38:20 CET] <J_Darnley> Do you know what TZ he's in? [13:42:37 CET] <durandal_1707> J_Darnley: he was just active before you joined [13:43:31 CET] <J_Darnley> Weird. No response to my message. I guess I'll do it publically [13:59:27 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:86ab6b6e08e2: avcodec/scpr: check if total_freq is 0 in decode0 [14:07:14 CET] <durandal_1707> he might not be near machine [14:19:51 CET] <cone-982> ffmpeg 03Paul B Mahol 07master:26a7d6a301b9: avcodec/qdrw: check bytes per scanline for 2bpp images [14:35:06 CET] <jkqxz> wm4: Driver? (I assume you intended that to be here.) [14:36:20 CET] <jkqxz> I test with current versions of both Intel drivers and Mesa; I haven't looked at older versions beyond ensuring that it builds with old headers. [14:37:32 CET] <wm4> jkqxz: I don't know, whatever you normally use with Intel [14:37:54 CET] <wm4> vainfo says i965 for broadwell [14:38:39 CET] <wm4> also I still get an assertion failure instead of an error if I try to allocate more surfaces than the pool size [14:38:50 CET] <jkqxz> Version? I can try on Braswell, which should be the same. [14:39:19 CET] <wm4> how do I find out the version? [14:45:02 CET] <jkqxz> vainfo should tell you. (Or your package manager.) [14:45:35 CET] <wm4> 0.39 1.7.3 [14:45:44 CET] <wm4> actually 0.39.4 [14:45:59 CET] <wm4> these are all numbers it shows [14:46:35 CET] <jkqxz> That's it; 1.7.3 is the driver version and 0.39.4 is the API version. [14:47:21 CET] <jkqxz> Also urgh, that is recent and should work. [14:47:47 CET] <jkqxz> I guess I can try later? Or you could try using a different driver and/or different hardware. [14:47:53 CET] <wm4> oh I thought 1.7.3 was the libva release version (while 0.39.4 is the pkg-config version) [14:48:06 CET] <wm4> I was wondering how you output 2 fields in this filter [14:48:13 CET] <wm4> or is that missing? [14:48:57 CET] <BtbN> that shouldn't be a problem for a filter, should it? yadif and others do it as well [14:49:51 CET] <jkqxz> Wrt assertion failure, I forgot about that one. It's still somewhere on the merge queue. [14:49:56 CET] <jkqxz> (Merge it yourself if you like.) [14:50:04 CET] <wm4> I'm just fighting with a problem with my own code where the fields seem switched or something when using something more advanced than bob [14:50:15 CET] <wm4> jkqxz: oh ok, I thought that was merged [14:50:46 CET] <wm4> jkqxz: why not just push it [14:51:59 CET] <jkqxz> Because I'm not at a machine with suitable keys. [14:58:47 CET] <jkqxz> The field handling is not there in the driver. You put an interleaved frame in and a deinterlaced frame comes out and that's about it. [15:02:15 CET] <BtbN> When I implemented the VPP deinterlacer for kodi, it could definitely output two progressive frames from one interlaced input frame. [15:04:19 CET] <jkqxz> Were they different? [15:04:26 CET] <J_Darnley> pscp --help [15:06:56 CET] <BtbN> jkqxz, yes [15:08:56 CET] <wm4> BtbN: I mean it works for bob [15:09:15 CET] <BtbN> Definitely at least for Motion Adaptive DI as well [15:09:31 CET] <wm4> but I can't get it to output in the right order for motion adaptive [15:09:55 CET] <wm4> so when frame-stepping it appears to go backwards one frame [15:10:16 CET] <wm4> well that can't really be, so I'm wondering wth I'm doing wrong here [15:10:29 CET] <BtbN> Top-First vs. Bottom-First reversed? [15:10:49 CET] <BtbN> with bob that wouldn't really matter, for for MaDi it does [15:11:23 CET] <wm4> something like this, I just couldn't find where I would have done that wrong [15:12:50 CET] <BtbN> Maybe it's wrong in the deinterlacer itself, and nobody ever tested it with frame-doubling before? [15:14:06 CET] <wm4> I very much doubt that [15:50:50 CET] <adeeln_> Could someone un-ban my original username 'adeel'? [15:54:21 CET] <BBB> theres no such ban in the banlist afaics [15:54:54 CET] <J_Darnley> Is there a macro that will shuffle qwords around to do this http://pastebin.com/DcqPD1NN with fewer loads? [15:55:05 CET] <adeeln_> oh, okay. I'll check. [15:55:34 CET] <adeeln_> durandal_1707: I manually removed the comments, but I'm still getting 'invalid data found when processing input' output [15:56:18 CET] <BBB> J_Darnley: mova x4 and then SBUTTERFLY qdq 0, 1, tmp and 2, 3, tmp [15:56:32 CET] <J_Darnley> thanks [15:56:49 CET] <BBB> J_Darnley: but I doubt its faster (itll have 4 loads instead of 8, but then it adds 2x4 punpck[lh]qdq [15:56:57 CET] <BBB> worth testing maybe [15:57:09 CET] <J_Darnley> It also avoids the int-float transition [15:57:20 CET] <BBB> fair enough [16:01:23 CET] <Gramner> just make sure to do the loads in the order +0, +32, +16, +48 [16:02:03 CET] <Gramner> also movhps is p5 anyway so using sbutterfly should be preferrable [16:02:31 CET] <Gramner> movhps when used as load that is [16:13:38 CET] <J_Darnley> BBB: Actually, it is even worse. I need 4 butterflies [16:14:10 CET] <BBB> ? [16:14:30 CET] <BBB> it shouldnt? [16:15:18 CET] <BBB> punpckl+hqdq m0, m1 after mova m0, [mem+0] and mova m1, [mem+32] should put mem+0 in m0:low, mem+8 in m1:low, mem+32 in m0:high and mem+40 in m1:high? [16:15:46 CET] <Gramner> mova m0, [r2+0]; mova m1, [r2+32]; mova m2, [r2+16]; mova m3, [r2+48]; SBUTTERFLY qdq, 0, 1, tmp; SBUTTERFLY qdq, 2, 3, tmp; [16:15:57 CET] <BBB> right [16:16:51 CET] <J_Darnley> Oh well it would help if I loaded from memory correctly [16:16:59 CET] <J_Darnley> :D sorry [16:17:20 CET] <BBB> typos in assembly are horrible yes [16:17:28 CET] <BBB> (horrible = undebuggable) [16:18:17 CET] <Gramner> I wonder if I should make some sort of printf macro [16:18:22 CET] <Gramner> for x86inc [16:18:42 CET] <J_Darnley> oh god. Compile time or run time? [16:19:06 CET] <Gramner> run time. there's asserts for compile time already [16:19:35 CET] <Gramner> just some easy way to print values without having to user a debugger every single time [16:19:37 CET] <BBB> I usually just have a hex_dump function built in and call that [16:19:46 CET] <BBB> but that does indeed require me to move registers into memory [16:20:05 CET] <BBB> printing registers outside a debugger would be very useful [16:21:59 CET] <durandal_1707> adeeln_: you need to add code to skip C comments [16:22:43 CET] <J_Darnley> Hey. It might have got me 1 percentage point faster [16:22:49 CET] <J_Darnley> (from 1 to 2) [16:22:55 CET] <BBB> oh nice [16:23:40 CET] <durandal_1707> is 10bit h264 path optimized enough? [16:28:46 CET] <J_Darnley> durandal_1707: enough for who? [16:29:16 CET] <J_Darnley> There's a similar number of lines assigning function pointers for both 8 and 10 bit [16:29:51 CET] <J_Darnley> 10 bit may get more benefit from avx2 and its wider registers [16:30:42 CET] <kierank> durandal_1707: J_Darnley is working on this, yes [16:32:01 CET] <durandal_1707> awesome [16:33:56 CET] <J_Darnley> If you have a particular function slowing you down please name it. [16:36:27 CET] <BBB> J_Darnley: I think hes just looking for stuff for you to do :-p [16:36:43 CET] <BBB> (btw this work is great, dont take this negatively, Im really happy someone is optimizing h264 further) [16:37:12 CET] <J_Darnley> I've got plenty to do :) [16:37:31 CET] <BBB> nice [16:38:03 CET] <BBB> and yes avx2 should give some gains (for both 8 as well as 10bit, although probably more for 10bit) in things like idct_add_block and mc [16:38:15 CET] <BBB> or I forgot what that stuff is called in h264dsp [16:39:10 CET] <BBB> idctN_addM [16:39:37 CET] <BtbN> I wonder how ryzen will do in terms of AVX performance [16:39:56 CET] <BtbN> And AVX2 [16:40:18 CET] <J_Darnley> Oh, does AMD finally have it? [16:41:01 CET] <Gramner> ryzen has 128-bit SIMD [16:41:10 CET] <Gramner> so avx2 is useless on it [16:41:15 CET] <adeeln_> durandal_1707: The error says "Invalid data found when processing input" which is not present in 'xpmdec.c' file [16:41:25 CET] <adeeln_> Not sure if C comments is causing it. [16:41:27 CET] <BtbN> Yes, but with two cycles per instruction, compared to Intel where its one [16:41:34 CET] <BtbN> but Ryzen does not need to clock down for it [16:41:44 CET] <jamrial> Gramner: you're shitting me [16:41:51 CET] <jamrial> no 256bit simd? [16:41:57 CET] <Gramner> correct [16:42:14 CET] <durandal_1707> adeeln_: you get that error message when receiving specific error code [16:42:15 CET] <BtbN> it supports the instructions though, but breaks it down to 128bit internally I guess, hence the two cycles [16:42:26 CET] <jamrial> no fucking way. i thought they would finally get a decent fp unit after getting rid of bulldozer [16:42:34 CET] <Gramner> it makes sense though for what amd is trying to do. very few applications uses avx so they spent their time and effort on the stuff that has the largest impact [16:42:37 CET] <adeeln_> okay. [16:43:02 CET] <BtbN> Yeah, supporting AVX and AVX2 is important, but having it super performant is more a bonus. [16:43:25 CET] <BBB> so were going to have that crap avxslow thing again? [16:43:28 CET] <BBB> like sseslow etc. [16:43:29 CET] <jamrial> ugh [16:43:31 CET] <Gramner> i'm guessing they'll widen their simd units in one of the next archs, e.g. zen+, zen++ or whatever they're gonna call it [16:43:37 CET] <jamrial> yeah, will have to add a check for family 0x17 i guess [16:43:53 CET] <BBB> pff& [16:44:02 CET] <BBB> so I guess datacenters will keep using intel [16:44:04 CET] <BtbN> Wonder if I'll be able to just upgrade on my AM4 board I ordered. [16:44:15 CET] <BtbN> My 1800X will be here on Friday or Saturday. [16:44:23 CET] <J_Darnley> Zen, Zen+, Zen Double Plus, Zen Double Plus Good [16:44:47 CET] <Gramner> "datacenters" is such a generic term though. yes if you're youtube and spend all your clock cycles encoding video then yes, you're going to keep using intel [16:44:51 CET] <jamrial> ryzen is the first cpu with the sha instruction set, though [16:45:01 CET] <BBB> Gramner: thats all I care about ;) [16:45:03 CET] <jamrial> at least that's what gcc says [16:45:04 CET] <kierank> some of the kaby lake pentiums are interesting [16:45:16 CET] <kierank> super cheap with dual core hyperthreading [16:45:18 CET] <kierank> but no avx(2) [16:45:50 CET] <BtbN> Once Ryzen R3 and R5 comes out those will have a hard time selling [16:46:01 CET] <J_Darnley> I'm considering a Kaby Lake Celeron for a NAS because it supports ECC [16:46:21 CET] <jamrial> why? high end ryzen is already like half the price of a similar performance i7 [16:46:21 CET] <BtbN> Ryzen also supports ECC. But so far no mainboard does... [16:46:40 CET] <jamrial> low end would destroy pentium/i3 if also priced right [16:46:51 CET] <BtbN> jamrial, well, but the cheapest ryzen is still way more expensive and overpowered than a Celeron [16:47:01 CET] <BtbN> jamrial, that's what I meant. [16:47:08 CET] <BtbN> The Intel ones will have the hard time, not Ryzen [16:47:23 CET] <jamrial> oh right, misread what you said [16:47:42 CET] <Gramner> ryzen is likely going to be awesome when it comes to performance/$ [16:47:56 CET] <BtbN> I'm upgrading to it from my i5-2500k [16:48:03 CET] <jamrial> we're about to have a cpu with the sha instruction set and we still haven't commited the aes-ni patchset :P [16:48:10 CET] <BtbN> I don't even care if it's the best performing CPU out there, it will definitely be fast enough. [16:52:46 CET] <Gramner> intel extreme editions will probably still be the way to go for max performance, but they're stupidly expensive. there hasn't been any reason for intel to drop prices when they keep selling 6950X for $1700 but ryzen will likely change that [16:53:16 CET] <BtbN> Well, the 1800X supposedly outperforms the Intel Extreme 8 core [16:53:40 CET] <BtbN> Also, http://wccftech.com/amd-ryzen-architecture-detailed/ claims "The floating point unit is capable of performing two FMAC operations or a single 256-bit AVX operation per cycle." [16:53:46 CET] <BtbN> no idea how accurate that is [16:54:23 CET] <kierank> always about the float [16:55:22 CET] <Gramner> hmm, everything I've read about ryzen so far has indicated 128-bit simd units [16:55:42 CET] <BtbN> Guess we'll know for sure in 3 days [16:56:15 CET] <BtbN> Would have been amazing if they supported AVX-512 right away [16:56:49 CET] <jkqxz> jamrial: The SHA instructions are already in Goldmont (the newest Atom arch, from last year). [16:57:15 CET] <jkqxz> (Which also probably benefits rather more from it...) [16:58:30 CET] <BtbN> is it useful for more than sha1? [16:59:08 CET] <Gramner> also skylake-x is coming later this year. would be kind of funny if intel starts going the previous amd route of competing by adding more cores. [16:59:36 CET] <BtbN> Intel can't really add more cores without dropping the clock speed [17:00:02 CET] <Gramner> sure you can, just add more ln2 ;) [17:02:12 CET] <kierank> skylake e5 xeons are out on google cloud [17:02:26 CET] <kierank> dunno if we should get one [17:03:21 CET] <BtbN> Gramner, maybe some wrong information comes from the gcc patch that adds march=znver1? [17:03:33 CET] <BtbN> Because it says "Costs and tunings are copied from bdver4, but we will be adjusting them later for znver1." [17:04:05 CET] <Gramner> maybe. but as you said - we'll know soon enough for certain [17:04:38 CET] <BtbN> I just hope they don't come up with a fixed and improved stepping or whatever in a few months... [17:10:25 CET] <adeeln_> durandal_1707: I manually removed comments from XPM file, but it's still not working. However, I did write up some logic: https://gist.github.com/adl1995/ee41f6c27d3922150664d0964a90f146 [17:10:43 CET] <adeeln_> haven't worked with uint_8 much [17:11:31 CET] <durandal_1707> uint8 is byte [17:13:22 CET] <durandal_1707> adeeln_: find out where it returns error [17:13:49 CET] <durandal_1707> does decode frame ever get called? [17:14:35 CET] <adeeln_> probably not. [17:16:06 CET] <durandal_1707> adeeln_: it should get called [17:16:50 CET] <adeeln_> How would I go on about doing that? [17:19:06 CET] <adeeln_> Error comes from "FFmpeg/libavutil/error.c" [17:20:47 CET] <jamrial> BtbN: sha256 as well afaik [17:22:17 CET] <adeeln_> durandal_1707: How is the workflow set up for decoder and encoders? [17:22:23 CET] <adeeln_> where could I learn? [17:23:47 CET] <durandal_1707> adeeln_: just add printf right at beginning of decode frame of xpm [17:24:21 CET] <durandal_1707> adeeln_: also you could get gui debugger running [17:26:55 CET] <adeeln_> It's always the simplest solution, isn't it? :D [17:27:10 CET] <adeeln_> will check out gui debugger [17:31:06 CET] <BtbN> aparently the Hyper Threading on Zen will be asymetric? Like, one thread has priority over the other. [17:31:16 CET] <BtbN> Sounds like a lot of fun if your scheduler is not aware [17:31:52 CET] <nevcairiel> (don't take a site like wccftech as too much authority on real infos) [17:32:20 CET] <BtbN> Yeah, they have a bit too much info for things still under NDA [17:32:38 CET] <nevcairiel> its a rumor mill and guess factory [17:32:55 CET] <Gramner> wccftech posts every rumor found on the net as news. they just happen to be right occasionally [17:33:03 CET] <nevcairiel> real infos come out friday? i think [17:33:10 CET] <BtbN> Thursday, the 3rd [17:33:15 CET] <BtbN> On Friday I will hopefully have mine [17:33:24 CET] <nevcairiel> but firday is the third [17:33:48 CET] <nevcairiel> and i don't pre-order hardware without knowing what it can do =p [17:34:05 CET] <BtbN> Well, I need an upgrade for my PC anyway [17:34:10 CET] <BtbN> And it will be fast enough [17:34:26 CET] <BtbN> It releases on the 2nd, not 3rd [17:35:52 CET] <nevcairiel> i'm mostly interested in single-thread performance, I expect it still to lack behind intel clock-by-clock, nearly all benchmarks that have been used by AMD marketing have been massive multi-threading [17:37:52 CET] <BtbN> I'll be sure to test ffmpeg on it. [17:38:07 CET] <BtbN> I'm positive it will outperform my SandyBridge [18:22:03 CET] <reynaldo> get got accepted to gsoc :) [18:22:46 CET] <reynaldo> we/ even [18:25:33 CET] <adeeln_> durandal_1707: Just added "printf("Testing XPM decoder");" at the beginning, but it's not getting printed [18:29:22 CET] <JEEB> you need to use av_log in lavf/c [18:34:50 CET] <durandal_1707> printf also works [18:39:01 CET] <durandal_1707> adeeln_: does it get probed at all? [18:39:35 CET] <durandal_1707> add debug flags to ffplay [20:07:36 CET] <adeeln_> durandal_1707: Getting this "[file @ 0x7f929c005760] Setting default whitelist 'file,crypto' [AVIOContext @ 0x7f929c005e00] Statistics: 1281 bytes read, 0 seeks /test.xpm: Invalid data found when processing input" [20:09:42 CET] <stevendz> I noticed a follow file option in the source code for ffmpeg. However, it is not documented anywhere. [20:09:54 CET] <stevendz> It looks like it is supposed to follow a growing file. [20:10:32 CET] <stevendz> I wrote some code to that in ffmpeg. Is it worth sumitting, or did I just reinvent the wheel? [20:11:03 CET] <JEEB> that sounds like exactly that feature in lavf :) [20:11:15 CET] <JEEB> and I'm pretty sure it's documented in `ffmpeg -h full` [20:11:17 CET] <durandal_1707> adeeln_: perhaps, look how xwd probing is done [20:17:24 CET] <adeeln_> durandal_1707: Going through this: [https://trac.ffmpeg.org/wiki/FFprobeTips] [20:18:10 CET] <adeeln_> Gotta get to bed. See ya tomorrow [20:20:15 CET] <stevendz> Maybe I'm mistaken. What exactly is the -follow option supposed to do? [20:21:44 CET] <JEEB> stevendz: https://github.com/FFmpeg/FFmpeg/blob/master/libavformat/file.c#L84 [21:00:25 CET] <chatter29> hey guys [21:00:27 CET] <chatter29> allah is doing [21:00:34 CET] <chatter29> sun is not doing allah is doing [21:00:35 CET] <chatter29> to accept Islam say that i bear witness that there is no deity worthy of worship except Allah and Muhammad peace be upon him is his slave and messenger [21:02:56 CET] <J_Darnley> Oh wow. The islam spam bots are back. I haven't seen one of those in quite a while [23:22:31 CET] <J_Darnley> lol wut. This function changes sse2->mmx->sse2 [23:24:38 CET] <BBB> yeah we have a couple of very strange ones [23:24:40 CET] <jamrial> J_Darnley: let me guess, using one of the obscure mov instructions that go xmm -> mmx and vice versa? [23:24:49 CET] <BBB> movq2dq/dq2q [00:00:00 CET] --- Tue Feb 28 2017

1 0

ffmpeg.log.20170227
by burek 28 Feb '17

28 Feb '17

[00:15:15 CET] <Darby_> DHE [00:15:25 CET] <Darby_> i have found the solution [00:17:31 CET] <Darby_> ffmpeg don't compile with libssh using libssl-dev but if you run sed -i "/Libs:/ i\Requires.private: libssl" "~/ffmpeg_build/lib/pkgconfig/libssh.pc" ffmpeg compile in the right way [00:20:13 CET] <Darby_> thanks DHE & BtbN ;) [04:51:32 CET] <c3r1c3-Win> Trying to find what Error Code -22 is. Happens when I try to initialize an abuffer filter. [07:28:08 CET] <Jonno_FTW> I'm trying to concatenate a bunch of mp4 files, but it's only putting the first file in [07:49:26 CET] <llamapixel> Are you using the methods listed here Jonno_FTW with regards to a txt file and know they are all exactly the same codec? https://trac.ffmpeg.org/wiki/Concatenate [08:26:58 CET] <satinder___> Hello everyone I have some serious problem [08:27:44 CET] <satinder___> which processor is sufficient for play and encode 4 raw videos in h.264 at same time playing and recording [08:27:54 CET] <satinder___> Is intel i3 good [08:27:59 CET] <satinder___> ?? [08:29:01 CET] <tdr> thats a lot of work on an i3 ... 4 encoding + playing on whats usually a dual core? [08:43:08 CET] <satinder___> yes [08:43:14 CET] <satinder___> tdr [08:44:09 CET] <tdr> sounds like your encoding could kill it depending on bitrate or whatever [08:44:26 CET] <satinder___> ok [08:45:01 CET] <satinder___> how many video we can play or encode on i3 if did any experiment [08:45:03 CET] <satinder___> ? [08:45:07 CET] <satinder___> tdr : ? [08:45:19 CET] <satinder___> whith h.264 [08:45:27 CET] <satinder___> with* [08:45:41 CET] <tdr> you'd have to test from yoru source [08:46:07 CET] <tdr> it depends alot on the bitrate you're trying to push, memory, whether theres audio too etc [08:46:14 CET] <llamapixel> There is a lot more to consider, eg drive speed, video size, memory etc [08:46:49 CET] <satinder___> ok [08:47:09 CET] <satinder___> Sir , have you used VPU with ffmpeg ? [08:47:29 CET] <satinder___> can I compile ffmpeg libVA [08:47:58 CET] <tdr> llamapixel, he said raw, figured he was getting raw streams live [08:48:07 CET] <tdr> (assumed continous feeds) [08:48:16 CET] <llamapixel> Ok [08:48:20 CET] <llamapixel> https://app.zencoder.com/docs/guides/encoding-settings/h264-advanced [08:48:41 CET] <satinder___> VPU ? [08:48:43 CET] <llamapixel> content matters as well so you better ask [08:49:04 CET] <llamapixel> anyway bbl [08:49:36 CET] <satinder___> llamapixel : Have you used vpu with ffmpeg for video acceleration [08:49:41 CET] <satinder___> ? [08:49:54 CET] <llamapixel> no I havent mate [08:50:00 CET] <satinder___> ok [08:50:36 CET] <satinder___> there have option in ffmpeg how we can accelerate vpu [08:50:50 CET] <satinder___> I am not able to findout [09:32:23 CET] <forgon> Is this syntactically correct? `ffmpeg -i input.mkv -ss 01:05:00 -to 01:06:51 -vcodec libx264 -qp 0 -preset veryslow -acodec flac -compression_level 12 output.mkv` [10:24:45 CET] <abdur91> hi my question is basically related to ffmpeg filter_complex.i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated. thanks [10:27:25 CET] <forgon> After compression, seeking is no longer possible, correct? [10:35:22 CET] <abdur91> hi my question is basically related to ffmpeg filter_complex.i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated. thanks [10:38:10 CET] <Hennio> hi, i am building ffmpeg with nvenc support, but there is an error... "ERROR: nvenc requested but not found" [10:39:13 CET] <Hennio> this is my configure: [10:39:14 CET] <Hennio> ./configure \ [10:39:14 CET] <Hennio> --enable-shared \ [10:39:14 CET] <Hennio> --disable-yasm \ [10:39:14 CET] <Hennio> --disable-static \ [10:39:14 CET] <Hennio> --disable-programs \ [10:39:14 CET] <Hennio> --disable-swresample \ [10:39:15 CET] <Hennio> --disable-postproc \ [10:39:15 CET] <Hennio> --prefix=build \ [10:39:16 CET] <Hennio> --enable-nvenc \ [10:39:16 CET] <Hennio> --enable-cuda \ [10:39:17 CET] <Hennio> --enable-cuvid \ [10:39:17 CET] <Hennio> --toolchain=msvc \ [10:39:18 CET] <Hennio> --extra-cflags="-IC:\\cuda_8\\include -D_WIN32" \ [10:39:50 CET] <JEEB> don't post such long things on the channel itself in the future [10:39:55 CET] <JEEB> and check your config.log [10:40:02 CET] <Hennio> sorry! [10:40:04 CET] <JEEB> that contains the results of the checks [10:40:25 CET] <JEEB> basically anything more than 2 lines should go to a pastebin (or a similar service) instead [10:40:29 CET] <Hennio> in the config.log there are a few errors [10:40:33 CET] <Hennio> ok [10:40:44 CET] <JEEB> and then linked on the channel, just fy [10:40:46 CET] <JEEB> *fyi [10:40:55 CET] <JEEB> <deity> damn it, Monday [11:02:39 CET] <satinder___> Is there anyone who ever play more than 4 videos in single window using ffplay ? [11:06:16 CET] <Hennio> @JEEB ok looking at the logs I found an issue with nvenc [11:06:20 CET] <Hennio> error C2440: 'initializing' : cannot convert from 'const GUID' to 'unsigned long' [11:06:33 CET] <Hennio> when compiling the check file [11:07:49 CET] <satinder___> Hennio : ? [11:08:01 CET] <satinder___> please see my question , help me [11:08:17 CET] <Hennio> satinder___: no idea mate, im asking my own questions too [11:08:36 CET] <satinder___> ok [11:08:41 CET] <satinder___> thanks [11:08:55 CET] <satinder___> JEEB : are you there ? [11:11:06 CET] <abdur91> hi all [11:11:34 CET] <abdur91> i have a question that i am trying to create a logic in which any 2 sounds files can overlap on each other and these must also merge with a video file having a silent file.Now what i wanted to do is basically use both amerge and concat at a time with filter_complex.Any help in this regard is highly appreciated. [11:19:26 CET] <satinder___> ffmpeg -i video.mp4 -i video.mp4 -i video.mp4 -i video.mp4 -filter_complex "nullsrc=size=640x480 [base]; [0:v] setpts=PTS-STARTPTS, scale=320x240 [upperleft]; [1:v] setpts=PTS-STARTPTS, scale=320x240 [upperright]; [2:v] setpts=PTS-STARTPTS, scale=320x240 [lowerleft]; [3:v] setpts=PTS-STARTPTS, scale=320x240 [lowerright]; [base][upperleft] overlay=shortest=1 [tmp1]; [tmp1][upperright] overlay=shortest=1:x=320 [tmp2]; [tmp2][lowerleft] overlay=shortes [11:19:27 CET] <satinder___> t=1:y=240 [tmp3]; [tmp3][lowerright] overlay=shortest=1:x=320:y=240" | ffplay - [11:19:56 CET] <satinder___> what is wrong in above command please anyone help me [11:24:46 CET] <abdur91> hi,any one here for help plz? [11:39:27 CET] <forgon> What is a good value for analyzeduration if the default is not enough? [14:32:03 CET] <xtina> hey folks. i have a question about bitrate. [14:32:53 CET] <xtina> i have been using ffmpeg to stream 480p@10fps video. sometimes the bitrate will be ~80kbps and ffmpeg speed is running at 1.0x. Other times bitrate is at ~160kbpsand speed is also running at 1.0x [14:33:26 CET] <xtina> i thought that, given a particular resolution (480p) and FPS (10) and speed (realtime), bitrate should be a constant value [14:33:40 CET] <xtina> how is it possible that 480p/10fps/1.0x speed can be both 80 and 160kbps bitrate? [14:34:06 CET] <BtbN> If you are using a constant quality, it will use however much it needs to reach the requested quality. [14:34:25 CET] <xtina> BtbN: what do you mean by 'quality'? [14:34:28 CET] <xtina> resolution? [14:34:47 CET] <BtbN> quite exactly that, the quality of the video [14:35:05 CET] <xtina> so how come sometimes it requres 160kbps to reach 480p 10FPS and sometimes it only requires 80kbps? [14:35:19 CET] <xtina> shouldn't it always require the same bitrate? [14:35:21 CET] <BtbN> no [14:35:38 CET] <BtbN> Unless you configure strict cbr, then it will adjust the quality to always reach the desired bitrate. [14:35:48 CET] <xtina> i thought 480p/10fps specifies exactly how much data should be sent per second [14:35:58 CET] <BtbN> if you send uncompressed video, maybe [14:35:59 CET] <xtina> i did not specify a bitrate [14:36:05 CET] <xtina> i'm sending h264 encoded video [14:36:21 CET] <BtbN> So it's not uncompressed [14:36:27 CET] <xtina> i specified the resolution in raspivid, from which i pipe h264 encoded video to ffmpeg [14:37:09 CET] <xtina> hmm sorry, i still don't understand why the bitrate would fluctuate if i've specified resolution and FPS [14:37:30 CET] <BtbN> Because it depends on the video and the requested quality. [14:37:39 CET] <xtina> but i specified the quality, right? 480p? [14:37:42 CET] <xtina> so that is constant? [14:37:46 CET] <BtbN> no, that's the resolution-. [14:37:57 CET] <BtbN> If you specified nothing, it will use whatever is the default [14:38:14 CET] <xtina> i see, which parameter in ffmpeg specifies video 'quality'? i'm not sure what this term refers to technically, sorry [14:38:28 CET] <BtbN> For libx264 it's -crf [14:40:09 CET] <xtina> oh, very interesting, i didn't know. thanks. [14:40:17 CET] <xtina> and if i pass a compressed h264 video to ffmpeg from raspivid [14:40:24 CET] <xtina> is there a way to specify 'quality' in raspivid? [14:40:31 CET] <BtbN> no idea [14:40:32 CET] <xtina> ffmpeg does nothing but mux the video so i suppose i don't specify it in there [14:41:05 CET] <BtbN> it might reencode if you specify nothing [14:41:29 CET] <xtina> i don't think ffmpeg is reencoding anything [14:41:30 CET] <xtina> Stream mapping: Stream #0:0 -> #0:0 (copy) Stream #1:0 -> #0:1 (copy) [14:42:05 CET] <xtina> but i think i do see a quality param in raspivid, -qp [14:42:06 CET] <xtina> "Varies from approximately 10 to 40, and will greatly affect the quality of the recording. Higher values reduce quality and decrease file size" [14:50:21 CET] <BtbN> xtina, yeah, if you specify -c copy it will just remux [14:50:35 CET] <BtbN> If you specify nothing at all it will re-encode though [14:55:14 CET] <Steve__> Hi, is it possible to force ffmpeg to make the video and audio stream to have exactly the same length, down to the ms? -shortest does not work that exactly it seems [14:55:41 CET] <BtbN> how should it do that? Even at 60 fps, a single frame covers more than one ms [14:56:27 CET] <Steve__> I was hoping that it would be possible to adjust the audio. video should have the same number of frames [14:56:51 CET] <BtbN> depending on the codec audio also has a frame size [14:57:49 CET] <Steve__> I used this "-c:v libx265 -movflags +faststart -preset medium -crf 20 -s 1280x720 -aspect 16:9 -r 24 -af "volume=29.90dB" -c:a aac -b:a 128k -shortest", but audio is 25ms longer, what causes a noticeable lag when looping the mp4 [15:06:21 CET] <xtina> another question, sorry >.< earlier tonight i was streaming to youtube, no problem. now i am trying again and Youtube Live says there is no stream. ffmpeg tells me everything is going great [15:06:32 CET] <xtina> if I try streaming to a flv file on disk, i can watch the video perfectly in VLC [15:06:40 CET] <xtina> here's my full log if i try streaming to youtube: [15:09:31 CET] <xtina> http://vpaste.net/a6QQq [15:09:38 CET] <xtina> i can't spot anything wrong in the log... [15:10:13 CET] <xtina> thanks in advance [15:11:40 CET] <BtbN> Log is fine, whatever is happening is on youtubes end. [15:11:53 CET] <BtbN> Also, if that rtmp url contains some private stream key, you should change it now. [15:12:02 CET] <BtbN> rtmp://209.85.230.23/live2/xbjs-a3gp-0yvk-ftdg is in the log [15:14:35 CET] <xtina> you're right, i will change it [15:14:38 CET] <xtina> hmm, thanks btbn [15:14:45 CET] <xtina> i will keep investigating. ffmpeg does look OK [15:18:54 CET] <xtina> BtbN: you were right, stream's OK if i send it to Twitch instead. wish services would send a message if they were down @_@ [15:46:46 CET] <Steve__> for my understanding: I just tried opus using "-frame_duration 2.5 -shortest", but in the resulting mkv the audio is still 18ms longer. but shouldn't it be max 2.5ms longer than the video? [16:02:22 CET] <DHE> what do I need to do to make a AVFrame I receive from avcodec_decode_video2() be reference counted? I'm getting a lot of time spent in memcpy while passing the AVFrame around. right now I just av_frame_alloc() and give that to the decoder immediately. [16:04:48 CET] <JEEB> there was an option for that I think [16:05:12 CET] <JEEB> ret = av_dict_set(&avdict, "refcounted_frames", "1", 0); [16:05:17 CET] <JEEB> yea, that's what I'm doing [16:07:28 CET] <DHE> oh wow that wording in the headers is concerning... [16:08:55 CET] <DHE> JEEB: thanks, I'm on it [16:12:45 CET] <JEEB> coal [16:26:03 CET] <bencoh> .48 [17:36:28 CET] <Darby_> hi guys, now configure run without errors but make stop compilation on LD FFMPEG_G [17:40:55 CET] <Darby_> https://clbin.com/0uaT6 [17:49:25 CET] <c_14> It looks like your linker can't find graphite/s-lang [17:50:23 CET] <c_14> are libharfbuzz/libcaca linked statically against them? [18:08:21 CET] <Phrk_> Hello, what is the easiest way to ffmpeg -c copy here.ts (and copy the same file at same time on a ssh server) ? [18:08:24 CET] <Phrk_> like a mirror [18:08:38 CET] <Phrk_> it's from a stream [18:08:55 CET] <c_14> not entirely sure what you want [18:09:00 CET] <c_14> 2 files from the stream, one local one remote? [18:13:13 CET] <Phrk_> exactly c_14 [18:13:46 CET] <Phrk_> for now i just scp the file every 5min, but this is dirty, and when the file will make 20gb, it will be unsuable [18:14:43 CET] <c_14> if ffmpeg is built with libssh then you can output directly via sftp [18:14:50 CET] <Phrk_> wow [18:15:03 CET] <Phrk_> but can i output 2 time ? [18:15:09 CET] <Phrk_> one local and one sftp ? [18:15:47 CET] <c_14> ffmpeg -i blah -c copy out.ts -c copy sftp://bar [18:16:13 CET] <Phrk_> wow very simple [18:16:28 CET] <Phrk_> thx ! ffmpeg is so powerfull [18:19:00 CET] <DHE> I'm a big fan of sshfs as well. Even if you don't use it here, it's useful in general. [18:21:59 CET] <c_14> if your ffmpeg isn't built against libssh it's probably easier to use sshfs than rebuild too [18:58:21 CET] <xtina> hi guys, i have a kinda complicated q... [18:58:37 CET] <xtina> i'm livestreaming using ffmpeg and my wifi signal varies during the stream [18:58:52 CET] <xtina> i'm using raspivid to send h264 encoded video and i'd like the quantization to be variable [18:59:21 CET] <xtina> effectively, i'd always like to have as high quality video as possible, but if the ffmpeg speed drops below 1.0x (realtime), then compression should increase a step until speed stabilizies at realtime [18:59:28 CET] <forgon> 'Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduratino' and 'probesize' options [18:59:39 CET] <forgon> What the hell is that, where does it come from and how do I fix it? [18:59:42 CET] <xtina> i'm not setting the quantization parameter, so i can have a variable bitrate. however, it's not that intelligent [19:00:06 CET] <xtina> sometimes my stream speed drops to 0.97x, but my bitrate isn't adjusting downwards to compensate, and as a result, my stream runs into problems [19:00:46 CET] <xtina> because i'm not setting quantization it should be using the quantization logic from h264 codec, right? do you guys think it is possible for me to implement what i'm describing (periodically check ffmpeg speed and use it to adjust h264 quantization)? [19:01:33 CET] <xtina> thanks in advance. [19:30:12 CET] <xtina> how about a stupid basic question [19:30:45 CET] <xtina> does anybody know - is the code for the h264 encoder the PI uses something I can modify? [19:30:47 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduratino' and 'probesize' options` [19:30:53 CET] <forgon> What the hell is that and how do I fix it? [19:31:50 CET] <xtina> analyzeduratino is definitely spelled wrong, for one [19:32:14 CET] <xtina> idk if you typoed that in here or misspelled it in ur cmd [19:34:27 CET] <xtina> where is the code for variable quantization for omx_h264 in ffmpeg? [19:37:51 CET] <furq> xtina: https://ffmpeg.org/doxygen/trunk/omx_8c_source.html [19:38:08 CET] <furq> i don't know how much of it can be modified [19:39:02 CET] <furq> if openmax exposes something which ffmpeg isn't using then i guess you could add it [19:39:59 CET] <xtina> ooh [19:40:30 CET] <xtina> er, is quantization in there? i searched 'quant', got nothing [19:40:43 CET] <BtbN> ffmpeg does not support dynamic bitrate changes at runtime based on network performance [19:40:52 CET] <xtina> oh dear [19:40:55 CET] <BtbN> you'll have to implement your own application for that. [19:41:00 CET] <xtina> does it support dynamic bitrate change based on ffmpeg's reported speed? [19:41:15 CET] <xtina> my desired logic is: if ffmpeg speed goes below 1.0x, lower bitrate exponentially til itgoes back to 1.0x [19:41:15 CET] <BtbN> Why would the speed have any relation to the bitrate? [19:41:22 CET] <xtina> what's happening now is [19:41:49 CET] <xtina> as i'm livestreaming, wifi signal sometimes drops, bitrate isn't dropping quickly enough, so i guess it has to wait more than 1s for 1s of video (?) [19:42:02 CET] <xtina> hmmm [19:42:10 CET] <xtina> BtbN: now i wonder if i'm misdiagnosing the problem [19:42:11 CET] <BtbN> yes, I get that. No support from ffmpeg.c for that. You'll have to write your own [19:42:26 CET] <xtina> do you think i'm on the completely wrong track? [19:42:39 CET] <xtina> at some point in my streams, my speed starts dropping to like 0.97x or so [19:42:45 CET] <xtina> and my bitrate drops a bit too [19:42:59 CET] <xtina> but if my ffmpeg is at 0.97x for a few mins the stream will buffer [19:43:18 CET] <xtina> and i want to avoid that, i thought i could avoid it by dropping bitrate b/c i don't know what else could cause it [19:43:18 CET] <kepstin> if it is due to net bandwidth, then some adaptation might help - also using a udp protocol (e.g. rtp) rather than rtmp might help [19:43:26 CET] <xtina> after like 30 min if successful streaming, 20% CPU, nothing looking wrong [19:43:31 CET] <xtina> full battery [19:43:36 CET] <xtina> all i can suspect is wifi variability [19:43:39 CET] <kepstin> iirc, your main problems are likely due to connection setup + backpressure from the rtmp tcp stream [19:44:02 CET] <kepstin> streaming udp (rtp) to a wired system which then pushes to rtmp might work better [19:44:09 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options` [19:44:18 CET] <forgon> Can someone explain that error to me? [19:44:42 CET] <forgon> Are there downsides if I try 100M as value for both analyzeduration and probesize? [19:44:45 CET] <DHE> forgon: information needed to process the video couldn't be inferred within the probe window. either something is wrong with the stream or you'll need to crank the parameters [19:44:54 CET] <DHE> there will be a slow startup and possibly more memory required [19:45:01 CET] <xtina> kepstin: if i want to add in some custom logic to adapt the bitrate downwards in response to occasional net bandwidth issues [19:45:12 CET] <xtina> do you know what code i'm supposed to modify? [19:45:20 CET] <kepstin> xtina: you'd be better off writing a custom app rather than starting with ffmpeg.c [19:45:23 CET] <xtina> i'm currently using the pi h264 encoder in raspivid but also happy to use omx_h264 in ffmpeg [19:45:49 CET] <kepstin> (in fact, starting with a custom app would solve most of the problems you've been having) [19:45:51 CET] <mdavis> Hey, so I'm one of those Cygwin64 weirdos. I'm trying to use the h264_cuvid decoder, but every time it fails on ctx->cvdl->cuvidCreateDecoder(&cudec, &cuinfo) with CUDA_ERROR_INVALID_VALUE. [19:45:53 CET] <mdavis> BUT! [19:46:16 CET] <xtina> kepstin: i'm not expert enough for that at all ... sadly @_@ [19:46:24 CET] <mdavis> Running the same command, same video, same machine against a mingw64-compiled version works just fine [19:46:40 CET] <xtina> there is some existing logic for varying quantization right? [19:46:52 CET] <xtina> there must be, as it seems variable. i just want to find it... [19:47:18 CET] <xtina> sorry if it sounds like i'm being stubborn, i understand your encouragement to build my own [19:47:22 CET] <xtina> however i've actually been going great with ffmpeg [19:47:24 CET] <forgon> DHE: What shall I do? '-probesize 100M -analyzeduration 100M -i inputfile -c copy outputfile'? [19:47:37 CET] <xtina> i can stream like 30min of 720P 30FPS audio+video from my Zero to Youtube w/o any desyncs or buffers [19:47:46 CET] <xtina> this current issue is the last one i face [19:47:52 CET] <xtina> so i'd really prefer to work from this point :) [19:48:21 CET] <mdavis> The call in question occurs at libavcodec/cuvid.c:670, in cuvid_test_dummy_decoder [19:48:37 CET] <xtina> i'm just trying to track down the code that currently takes care of quantization in raspivid, it can't just happen magically [19:49:02 CET] <xtina> or alternatively, the code for it in ffmpeg [19:49:08 CET] <xtina> since i can use either command to encode [19:49:41 CET] <kepstin> with hardware encoders, you usually either give them a static quantizer or a desired bitrate, and the rest happens magically in the black box [19:49:51 CET] <kepstin> not really much you can do [19:50:46 CET] <mdavis> So, anyone have any ideas why cuvid would work under mingw, but fail under cygwin? [19:51:04 CET] <BtbN> define fails [19:51:13 CET] <xtina> kepstin: hmm, so there's a bunch of quantizers out there.. and i could find one that works for me? [19:51:21 CET] <mdavis> [h264_cuvid @ 0x60024ec40] ctx->cvdl->cuvidCreateDecoder(&cudec, &cuinfo) failed -> CUDA_ERROR_INVALID_VALUE: invalid argument [19:51:27 CET] <xtina> oh [19:51:39 CET] <xtina> static quantizer = static compression rate..? [19:51:42 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options` [19:51:58 CET] <kepstin> xtina: bitrate of a given frame is a function of quantizer and frame complexity more or less [19:52:26 CET] <BtbN> mdavis, I'd guess it thinks it's on Linux which messed the library loading up. [19:52:29 CET] <kepstin> (if you encode in bitrate mode, the encoder picks quantizer to use on the frame based on the complexity to get the desired rate) [19:53:07 CET] <xtina> kepsin: so bitrate mode = i want this target bitrate, quantize appropriately. quantizer mode = use this much compression, and accept whatever bitrate comes out [19:53:16 CET] <xtina> and i can't feed a param into the quantizer based on how ffmpeg is performing [19:53:34 CET] <kepstin> xtina: not without substantial modifications to the ffmpeg command line tool, no [19:53:36 CET] <BtbN> you can, just have to implement it yourself. ffmpeg.c does not do that. [19:53:37 CET] <mdavis> BtbN: I'm trying to replace the current dynlink_loader.h setup and instead use CUDA implibs that I've generated, but I'm a bit out of my depth... [19:53:44 CET] <xtina> so how do people stream from their phones? anyone who is using data is never gonna have the same upload speed [19:53:54 CET] <xtina> i see [19:53:59 CET] <xtina> oh dear [19:54:00 CET] <kepstin> xtina: they don't use the ffmpeg command line tool :) [19:54:02 CET] <BtbN> mdavis, why? The entire dynloading thing is put in place to make things easier. [19:54:38 CET] <xtina> do you think it requires a ton of work on top of ffmpeg.c? [19:54:50 CET] <mdavis> BtbN: So far that's the only place that things start to differ between cygwin and mingw [19:55:05 CET] <BtbN> cygwin pretends to be linux [19:55:07 CET] <BtbN> mingw doesn't [19:55:12 CET] <BtbN> there are a lot of things that differ [19:55:20 CET] <mdavis> BtbN: I've gone into GDB and verified that both versions are passing identical info in the cuinfo param [19:55:36 CET] <kepstin> xtina: ffmpeg.c doesn't have any realtime handling code atm right now. you might be able to hack it into the main encoder loop, but ... well - i wouldn't know where to start :) [19:55:42 CET] <BtbN> could just be the wrong calling convention [19:56:12 CET] <BtbN> or different struct packing [19:56:40 CET] <mdavis> BtbN: Yeah, could be. I know I'm going outside the realm of reasonable usecases, but I figured it couldn't hurt to ask :) [19:57:06 CET] <xtina> so to make sure i understand. in bitrate mode ffmpeg picks a quantizer to achieve a bitrate. or is it the codec that picks the quantizer..? [19:57:10 CET] <xtina> i'm still curious where this actually occurs [19:57:14 CET] <BtbN> So you mean your modification does not work, but vanilla ffmpeg does just fine? [19:57:32 CET] <mdavis> Nah, vanilla ffmpeg doesn't work (in cygwin). [19:57:45 CET] <BtbN> xtina, ffmpeg just tells the encoder to deliver that bitrate. [19:57:54 CET] <BtbN> It will do whatever it wants to achive it [19:57:57 CET] <xtina> so it's the encoder's job [19:58:04 CET] <xtina> gotcha [19:59:11 CET] <xtina> OK. i guess i'm gonna have to make some compromises, i will use bitrate mode and use a low bitrate that i can hit 99% of the time and just end the stream if it starts buffering,i guess [19:59:14 CET] <mdavis> Although, speaking of silly usecases, I compiled a static SDL2 from cygwin, but it uses the Win32 display backends. I found out I then had to #define SDL_MAIN_HANDLED in ffplay.c [20:10:39 CET] <xtina> to further explain my troubles [20:10:46 CET] <xtina> i dont care at all if my stream buffers ever 20 min or whatever [20:11:00 CET] <xtina> the problem is that while the video is buffering the audio is overflowing the audio pipe and audio packets are dropping [20:11:09 CET] <xtina> so whenever my stream buffers, the audio and video become permanently desynced and the stream is ruined [20:11:25 CET] <xtina> so while it's pretty normal for streams to buffer.. for me it's fatal... [20:11:28 CET] <xtina> :( [20:11:57 CET] <alex1912> "ffmpeg --list-bsfs" gives "Unrecognized option '-list-bsfs'.Error splitting the argument list: Option not found" whats wrong? [20:12:28 CET] <forgon> alex1912: The argument is probably in the wrong place [20:12:45 CET] <kepstin> alex1912: that's not the right argument name. You probably mean "-bsfs" [20:12:59 CET] <kepstin> alex1912: note that no ffmpeg arguments start with -- at all, where did you see that? [20:13:24 CET] <alex1912> https://ffmpeg.org/ffmpeg-bitstream-filters.html#dca_005fcore [20:13:30 CET] <alex1912> section 2 [20:13:56 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format Consider increasing the value for the 'analyzeduration' and 'probesize' options` [20:14:16 CET] <kepstin> alex1912: that's an option to ffmpeg's "configure" script when building, not to the command line tool [20:14:27 CET] <alex1912> ah ok [20:15:00 CET] <alex1912> so i need dca_core filter, have i realy to build my own ffmpeg? [20:15:09 CET] <llogan> forgon: Consider increasing the value for the 'analyzeduration' and 'probesize' options [20:15:21 CET] <kepstin> alex1912: maybe not, run "ffmpeg -bsfs" to see if it's included in your current build [20:15:28 CET] <forgon> llogan: Be specific. [20:15:44 CET] <forgon> I have obviously tried this already, with 100M as value for both. [20:15:56 CET] <llogan> ffmpeg -analyzeduration <value> -probesize <value> -i input [20:16:12 CET] <llogan> perhaps your input is garbage [20:16:44 CET] <forgon> llogan: Everyone gets to that part. What about the output? [20:17:13 CET] <forgon> What you gave is no valid command. [20:17:14 CET] <alex1912> no its not [20:17:22 CET] <alex1912> already did the otion [20:17:29 CET] <llogan> forgon: ffmpeg -analyzeduration <value> -probesize <value> -i input output [20:17:58 CET] <durandal_1707> alex1912: from where you get your ffmpeg? [20:18:12 CET] <forgon> forgon: What will happen to the codec? [20:18:28 CET] <alex1912> pfff, dunno, i guest it came on windows 8.1 with megui, # [20:18:40 CET] <alex1912> and on ubuntu 16.04 with the system [20:18:51 CET] <alex1912> same reaction thou [20:19:20 CET] <durandal_1707> too old to be useful [20:19:37 CET] <llogan> or just download a recent build and try again [20:19:53 CET] <alex1912> will try [20:19:55 CET] <llogan> https://ffmpeg.zeranoe.com/builds/ or https://johnvansickle.com/ffmpeg/ [20:20:58 CET] <forgon> llogan: Zero change of the problem. [20:21:22 CET] <forgon> I already spammed the message here 10 times or so [20:22:00 CET] <llogan> i see no link provided by you that shows your actual, full, unscripted ffmpeg command and the resulting complete, uncut console output [20:25:33 CET] <forgon> http://sprunge.us/fMJH [20:28:03 CET] <llogan> this whole time i assumed you were using ffmpeg [20:30:10 CET] <forgon> It doesn't matter, you don't know the answer :p [20:31:11 CET] <kepstin> forgon: so you tried adding the '-analyzeduration' and '-probesize' options to the ffprobe command with big values, and it didn't help? [20:31:20 CET] <llogan> well, if that's the case then I don't have to do anything else [20:31:21 CET] <kepstin> if so, your mkv file is probably corrupt, I guess... [20:31:38 CET] <durandal_1707> how file was created? [20:31:57 CET] <kepstin> (that info should be stored in a global header in mkv, I thought) [20:33:20 CET] <forgon> kepstin: I tried that too. [20:33:37 CET] <forgon> The thing I notice is that 'ENCODER' is missing for the corrupt file. [20:33:42 CET] <alex1912> OH IT WORKED [20:34:00 CET] <alex1912> THANKX ALOT kepstin & llogan [20:34:06 CET] <alex1912> and all [20:34:24 CET] <forgon> Metadata are different: http://sprunge.us/fEEN [20:35:41 CET] <alex1912> well, with this thanks @all and bb [20:52:06 CET] <DHE> are there current instructions on how to deal with telecine content somewhere? preferably handling mixed content but if not I can deal with it the harder way [21:01:09 CET] <kepstin> DHE: fieldmatch works fairly well, but needs something to delete dup frames after which is harder with mixed content. iirc 'pullup' works reasonably well with mixed content and is more hands-off, you can throw a condititional deinterlacing filter and a dejudder after it to fix the remaining frames and smooth out the result. [21:01:46 CET] <DHE> oh dear... [21:01:53 CET] <kepstin> DHE: if you have really nasty content, like say the s.e.lain ntsc r1 dvds, well, ... [21:02:04 CET] <kepstin> buy the blu rays instead in that case ;) [21:02:26 CET] <DHE> it's a live MPEG-TS feed [21:03:45 CET] <JEEB> mixed content properly is hard [21:03:51 CET] <JEEB> as it's pretty much manual [21:03:58 CET] <DHE> well @#%! [21:04:04 CET] <kepstin> DHE: it really depends what you want to do with that. Really, bobbing it to 60/50fps is one of the easiest and least bad options to get everything to look okish [21:04:52 CET] <DHE> input is officially 1080i, but it seems to be jumping between telecine and traditional 1080i. commercials seems to be 1080i, some shows are telecine... [21:05:11 CET] <JEEB> yes [21:05:31 CET] <JEEB> in theory you can match up fieldmatch and friends and yadif [21:05:35 CET] <JEEB> but that's just in theory [21:06:39 CET] <JEEB> so unless you get metadata on where to handle crap properly [21:06:52 CET] <JEEB> you might as well be throwing a coin if you're getting it right [21:07:14 CET] <JEEB> and to be honest I've never seen that kind of metadata in broadcast sources :P [21:07:41 CET] <kepstin> I *think* pullup leaves the interlaced flag set correctly on frames that it doesn't match, so something like pullup,yadif=deint=interlaced,dejudder *might* work most of the time [21:07:55 CET] <JEEB> yes, but it really depends on things [21:08:10 CET] <kepstin> some stuff will sneak through because pullup's matching isn't that great [21:08:24 CET] <JEEB> fieldmatch and the rest also should in theory leave the interlacism flag on not so great matching [21:08:51 CET] <kepstin> but with fieldmatch you have to deal with removing the extra frames on telecined stuff, while not removing anything on interlaced stuff [21:09:10 CET] <DHE> the only thing that strikes me is that the AVFrame->interlaced_frame field cycles in a pattern that should be measurable with a bit of buffering. [21:09:55 CET] <kepstin> DHE: that's really weird, it should have all frames marked as interlaced in a stream such as you've described [21:10:44 CET] <kepstin> unless maybe the encoder is being too clever and i dunno checking for combing to set the flag adaptively? :/ [21:12:16 CET] <forgon> `Could not find codec parameters for stream 0 (Video: h264, none(progressive), 1280x800): unspecified pixel format` [21:12:21 CET] <forgon> What does this mean? [21:12:26 CET] <kepstin> the other thing you have to worry about is (particularly if it's mpeg2, dunno if h264 does this?) whether the content is soft-telecined, which is done with repeat-field flags, because then you can have a mix of 24p, 60i telecine, 60i interlaced [21:12:45 CET] <DHE> it is mpeg2... but I don't know about the details beyond that. [21:13:03 CET] <JEEB> kepstin: soft-telecine is possible with AVC just fine [21:13:15 CET] <JEEB> forgon: you're hosed [21:13:51 CET] <kepstin> at least current ffmpeg has a port of mplayer's softpulldown now - "repeatfields" - so you can treat the 24p stuff as 60i telecined to make it a little less complex to handle [21:14:25 CET] <forgon> The files are playable, they just are wrong in other ways. [21:15:00 CET] <kepstin> forgon: what are you trying to do with this file? why is this error a problem for you? [21:15:46 CET] <forgon> kepstin: Originally I tried to upload it to YouTube. Then I noticed that the thumbnail suggestion were in a horrible grayish mixture looking like an ant-war is going on. [21:16:05 CET] <forgon> This did never happen with other files which I made on the same day using the same method. [21:16:16 CET] <forgon> The difference is the error. [21:16:26 CET] <kepstin> forgon: ok, that's a start. how did you make the files? [21:16:44 CET] <kepstin> (because the issue is that this file is corrupt or incorrectly muxed) [21:17:40 CET] <forgon> First I maximally compressed file a, which constisted of flac and libx264: [21:18:07 CET] <forgon> 0) ffmpeg -i recording.mkv -vcodec libx264 -qp 0 -preset veryslow -acodec flac -compression_level 12 output.mkv [21:18:22 CET] <forgon> Then I split it into parts via seeking: [21:19:56 CET] <forgon> 1) ffmpeg -ss 05:14 -to 14:23 -i output.mkv -c copy final.mkv [21:20:28 CET] <forgon> The first file I got in such a way has no apparent flaws, all the others do. [21:21:06 CET] <kepstin> alright, can you give us the complete ffmpeg output from encoding one of those files that has flaws? [21:21:50 CET] <forgon> I don't have the logs left, I'm afraid. [21:22:27 CET] <kepstin> you could just re-run it, assuming you had the original file left. [21:22:58 CET] <forgon> Let me see first whether i can reproduce. [21:23:30 CET] <kepstin> keep in mind that even if it does work, you're not going to get accurate seek times, because in copy mode it can only seek to keyframes [21:24:04 CET] <forgon> I heard ffmpeg does some magic to get the least worst solution, which I assume is far better than what I would get. [21:24:07 CET] <kepstin> you might get better results re-encoding rather than copying, if you want accurate times (you're using lossless, so re-eocnding obviously doesn't lose you quality) [21:24:38 CET] Action: DHE is off to the drawing board [21:29:53 CET] <forgon> I got closer. [21:30:08 CET] <forgon> Apparently -c copy is to blame. [21:30:26 CET] <forgon> But now I am confused. [21:31:30 CET] <llogan> why did you do step "0" in the first place? reencoding (from lossy?) to lossless and making a huge, gigantic file. [21:31:42 CET] <kepstin> codec copy in combination with seeking is always going to be weird, at best. it's sometimes useful to break up lossy-encoded files where you want to avoid a transcode - but if you're working in lossless anyways, just transcode and be happy [21:32:35 CET] <forgon> kepstin: Compression won't suffer this way, correct? [21:34:14 CET] <kepstin> you're using lossless, compression suffering is the difference between an extremely large file and an extremely large file [21:47:43 CET] <mdavis> After quite a bit of effort spent on removing the CUDA dynload system, my problem persists. :/ [21:50:12 CET] <kepstin> attempting to load native windows stuff from cygwin sounds like worlds of pain that I don't want to get into :) [21:50:33 CET] <mdavis> That's what I'm quickly starting to see [21:52:01 CET] <mdavis> Maybe I should shoot nvidia an email, "Hey, can I have your CUDA, CUVID, and NVENC source code? Kthx" [21:56:29 CET] <BtbN> I did put some effort into making it work on cygwin, but for cuvid I never had much luck. [21:56:32 CET] <BtbN> nvenc works though iirc [21:56:44 CET] <BtbN> haven't tried it in a long while. Just build it natively. [21:56:49 CET] <mdavis> Yeah it does, which I appreciate <3 [21:57:11 CET] <BtbN> And I still don't see the point of directly linking. [21:57:16 CET] <BtbN> no benefit in that [21:57:16 CET] <mdavis> And at any rate, cuvid isn't even faster than CPU-based decoding... [21:57:30 CET] <BtbN> For HEVC and VP9 it most likely is [21:57:36 CET] <mdavis> BtbN: I thought it had something to do with it, but it didn't [21:58:04 CET] <BtbN> no, I suspect it's something about calling conventions(Linux uses cdecl, Windows stdcall), or cygwin-gcc packs some structs diffrently. [21:59:06 CET] <mdavis> If it's struct packing, I should be able to see that in GDB. I'll take a look. [21:59:36 CET] <xtina> hey guys. i hope i'm not asking the impossible. in my stream i'm targeting 800kbps [21:59:44 CET] <xtina> however in the first 30s the stream needs to speed up to "catch up" [21:59:56 CET] <xtina> so ideally it surges to like 1.5Mb before settling back down to 800kbps [22:00:17 CET] <xtina> in raspivid if i specify -b 800K, then in the beginning it never goes above 800K, so it can't "catch up" [22:00:36 CET] <xtina> but if i set -b 1.5M, then it always stays at 1.5M, which is too high [22:00:57 CET] <xtina> if i don't specify any bitrate at all then it naturally goes to 1.5M before settling back down around 800, but sometimes it wanders back up, which i don't want [22:01:33 CET] <xtina> essentially i want ffmpeg to be willing to stream up to 1.5M [22:01:36 CET] <xtina> so that it can catch up initially [22:01:41 CET] <mdavis> Is there a reason you want it to surge in the first 30 seconds? Do you want it to catch up time-wise, or bitrate-wise? [22:01:43 CET] <xtina> but raspivid should only be willing to stream up to 800k [22:01:56 CET] <xtina> so after everything is caught up, ffmpeg has no reason to go above 800, since raspivid is sending it 800 [22:02:06 CET] <xtina> mdavis: it needs to catch up time-wise [22:02:26 CET] <xtina> a period of time passes between when the video pipe starts recording and when that starts getting sent over RTMP [22:02:30 CET] <xtina> that video buffer needs to empty [22:02:53 CET] <xtina> my ffmpeg isn't encoding, just copying (c:v copy) [22:03:07 CET] <xtina> is it possible for me to tell fmpeg to stream up to 1.5M, even tho it's just copying and muxing? [22:03:13 CET] <xtina> -maxrate has no effect [22:04:19 CET] <xtina> b:v also seems to have no effect [22:04:29 CET] <mdavis> The bitrate you give ffmpeg only directs the encoder, so with c:v copy it won't do anything. To achieve what you're looking for, you might have to mess around with timecodes [22:05:13 CET] <xtina> (using a pi zero) [22:05:13 CET] <xtina> i don't have any timecode stuff, as i need as little processing as possible [22:05:27 CET] <xtina> the reason i'm using raspivid to write and then ffmpeg to read the video stream is so [22:05:30 CET] <xtina> i can decouple the two processes [22:05:37 CET] <xtina> and have the video pipe as a buffer [22:06:14 CET] <xtina> so i thought i should be able to set the write speed (-b in raspivid) as well as some kind of bitrate in ffmpeg [22:07:01 CET] <mdavis> Again, that doesn't actually tell the programs to write data faster, it tells them the encoder can use a higher bitrate -> better quality [22:07:35 CET] <xtina> so the only way i can do this "catch up" thing is by avoiding setting any bitrates? :( [22:07:39 CET] <mdavis> If you want to reduce latency, you should look into whether raspivid's encoder's buffer can be reduced [22:08:28 CET] <xtina> hmm, how do you mean? if i reduce raspivid's buffer [22:08:32 CET] <xtina> wouldn't that just cause frames to be dropped? [22:08:36 CET] <xtina> at the start of the stream [22:08:53 CET] <xtina> i was trying to get raspivid's buffer as large as possible to ensure no frames are dropped.. [22:09:23 CET] <kepstin> yes, but bigger buffer means more latency [22:09:26 CET] <kepstin> it's a trade-off [22:09:28 CET] <mdavis> Almost all encoders that target an average bitrate use a lookahead buffer, so they can preemptively drop quality if a complex scene is coming up/ [22:10:17 CET] <xtina> if a single packet is dropped from either my audio or video, my entire stream is doomed [22:10:22 CET] <xtina> as the audio and video would never get back in sync [22:10:34 CET] <xtina> from the moment the stream begins i need every recorded A/V packet to make it into the stream... [22:11:14 CET] <xtina> i mean, this is such trouble that i wonder if i can timestamp them? [22:11:28 CET] <mdavis> Maybe you should look into a streaming protocol? If you're doing raw A/V transport, then you will have problems with sync [22:11:45 CET] <xtina> the audio and video files? currently raspivid is writing h264 encoded video and sox is recording mp3 [22:12:04 CET] <kepstin> xtina: remember that this is all workarounds for the fact that ffmpeg isn't really a realtime streaming app - if you had a custom app handling the capturing and encoding and streaming, then you could start stuff up in the right order so you wouldn't need massive buffers [22:12:05 CET] <xtina> mdavis: as far as i can tell ffmpeg is the commonly used library for streaming from the raspberry pi [22:12:28 CET] <kepstin> the ffmpeg libraries are great, ffmpeg tool isn't really meant for realtime stuff [22:13:09 CET] <mdavis> xtina: In that case, you would probably be better off ditching raspivid and sox, and recording both audio and video with one ffmpeg instance. [22:13:38 CET] <xtina> mdavis: sadly there's some bug in ffmpeg that means audio encoding requires almost 100% of my CPU [22:13:46 CET] <kepstin> mdavis: xtina was trying that earlier, running into issues due to ffmpeg's poor multiple input handling not working well for realtime stuff on resource constrained systems [22:13:58 CET] <xtina> kepstin: that isn't the problem [22:14:11 CET] <xtina> the problem is that recording alsa audio in ffmpeg requires all o fmy CPU [22:14:38 CET] <xtina> i doubt anyone will ever get to this, but https://trac.ffmpeg.org/ticket/6156 [22:14:52 CET] <xtina> i just decided to use Sox instead, it takes like 15% of my CPU to record AND encode to mp3 [22:15:38 CET] <xtina> my livestreaming A/V with a combo of ffmpeg, raspivid, and Sox requres <25% of my CPU [22:15:42 CET] <kepstin> xtina: it looks like ffmpeg's doing a s32s16 conversion there, does it work better if you just capture s16 directly? [22:15:52 CET] <xtina> kepstin: s32 -> s32 same problem [22:15:58 CET] <mdavis> OK, can you get SOX to output raw or minimally encoded audio, and pipe that into ffmpeg? [22:16:02 CET] <kepstin> xtina: and s16s16? [22:16:23 CET] <xtina> mdavis: why would that help? [22:16:45 CET] <kepstin> xtina: there's really no reason to use higher bit depths than 16 except maybe as intermediates in music production [22:16:47 CET] <xtina> kepstin: dont think my mems mic does s16 natively [22:16:51 CET] <kepstin> xtina: just wastes bw/cpu [22:17:27 CET] <xtina> i mean, whatever it is, there's a bug in ffmpeg if 32->32 uses 95% of my CPU, right? [22:18:15 CET] <mdavis> Maybe it's not 32->32? It could be that it's getting scaled up to 32 somewhere. [22:18:26 CET] <xtina> ffmpeg tells me it is [22:18:30 CET] <xtina> maybe not [22:18:48 CET] <kepstin> hmm, if this issue is related to ffmpeg not doing a wait on the alsa device, I'm not sure that's fixable - since ffmpeg's single threaded, wouldn't a wait there cause the rest of the process to hang? [22:19:00 CET] <kepstin> you'd really need to use a separate input thread to handle that right [22:19:14 CET] <xtina> i don't really understand the issue, but if that's the case, that's the reason to use a separate process i suppose/ [22:19:16 CET] <xtina> ? [22:19:37 CET] <kepstin> well, with separate process you run into the issue of needing a big buffer to workaround ffmpeg's slow startup [22:19:39 CET] <xtina> though i'm not sure why there'd be an issue on ffmpeg not waiting for alsa.. doesn't ffmpeg have to wait for the h264 encoder [22:19:44 CET] <kepstin> which means high latency [22:19:50 CET] <xtina> @___@ [22:20:02 CET] <xtina> sorry.. running on low sleep.. this project has been giving me a headache [22:20:09 CET] <kepstin> xtina: ffmpeg has to wait for lots of things - but it can't wait for one thing while also waiting for something else [22:20:30 CET] <kepstin> it has to wait for alsa samples and wait for the h264 encoder and wait for the network data to send and... [22:20:39 CET] <xtina> i'm not looking for perfection and i know it's near impossible with this setup [22:20:50 CET] <xtina> my streams have been performing well for about 30mins which is already great [22:20:55 CET] <xtina> i just want them to stabilize at a certain bitrate [22:20:59 CET] <kepstin> since it's all single-threaded, it can't wait for one thing at the same time as something else, so stuff gets bogged down. [22:21:03 CET] <xtina> instead of wandering wherever they want [22:21:27 CET] <xtina> yea, makes sense [22:21:39 CET] <xtina> that's unavoidable yes? [22:22:07 CET] <xtina> with my current setup i need a bitrate surge at the start to catch up, which means i can't set a target bitrate [22:22:11 CET] <xtina> if i changed setups [22:22:23 CET] <kepstin> you don't need a "bitrate surge", that doesn't make sense [22:22:25 CET] <xtina> i'm not sure i understand an alternative plan [22:22:45 CET] <xtina> i mean, the only way i've gotten successful 30min streams so far is that the bitrate spikes to 2x for 5s and then lowers to 1x around 15 [22:22:46 CET] <xtina> 15s [22:22:49 CET] <kepstin> if you want to empty the buffers, you need to send faster than realtime, but you can't do that because the streaming server wont' accept that [22:22:59 CET] <xtina> if that doesn't happen, the stream buffers, audio overruns, and desyncs within 30s [22:23:15 CET] <xtina> so, what is happening when speed reads 2x? [22:23:22 CET] <xtina> where is all the extra data going? [22:23:27 CET] <xtina> just drops or what? [22:23:30 CET] <kepstin> xtina: hmm, then it must be sending to the server faster than realtime [22:23:37 CET] <kepstin> no idea what the server's doing with it [22:23:45 CET] <mdavis> What kind of server are you sending to? [22:23:46 CET] <kepstin> it might accept it until a buffer fills, then force you to wait [22:23:51 CET] <xtina> i dont care if data is thrown away as long as audio and video packets are thrown away together [22:23:54 CET] <xtina> which means i stay in sync [22:23:55 CET] <kepstin> mdavis: youtube, so a black box [22:24:10 CET] <xtina> youtube, also trying twitch etc [22:24:35 CET] <xtina> the way i see it is, with this initial surge i may lose some synced data, vs. letting one of the two pipes overflow causing permanent desync [22:24:43 CET] <kepstin> xtina: it's probably not throwing data away, but more likely filling a buffer then forcing ffmpeg to wait before submitting more (since tcp can't "lose" data) [22:25:04 CET] <xtina> maybe it just increases the latency? [22:25:09 CET] <xtina> like it starts 15s behind and then becomes 25s behind? [22:25:49 CET] <xtina> if the audio/video packets are thrown away in sync, fine. if they are streamed in sync with added latency, also fine [22:25:54 CET] <xtina> only thing that's not fine is desync haha [22:25:59 CET] <mdavis> Maybe I'm just not understanding how your setup works. What commands are you using to start sox, raspivid, ffmpeg, etc? [22:26:25 CET] <xtina> mdavis: http://vpaste.net/Ep89E [22:27:02 CET] <xtina> all in a bash script that executes upon boot [22:27:06 CET] <kepstin> xtina: it sounds like ffmpeg is sending data to youtube, then getting stuck because it can't send more, which then chains up and blocks raspivid/etc., which then causes data to be lost at capture time (xruns, etc) [22:27:17 CET] <xtina> kepstin: that doesn't happen.. [22:27:39 CET] <xtina> i havent' seen an xrun in weeks, unless they aren't printed [22:27:50 CET] <xtina> you mean overruns? [22:28:01 CET] <kepstin> xrun and overrun is the same thing, yes [22:28:08 CET] <kepstin> (well, xrun can also be underrun) [22:28:10 CET] <xtina> let me try to describe what i see happening, though maybe i made false assumptions [22:29:12 CET] <xtina> scenario 1: ffmpeg surges to 2x speed in first 5s, stabilizes at 1x around ~15s, no overruns or desyncs whatsoever, perfect realtime streaming for 30min-1hr, around which point the bitrate may start drifting and speed goes below 1x, causing buffering and audio overruns [22:29:32 CET] <ZexaronS> hello [22:29:43 CET] <kepstin> xtina: that's most likely caused by a desync between the audio and video timestamps, since they're sourced from separate processes [22:30:00 CET] <xtina> scenario 2: ffmpeg does not surge enough (only goes to 1.5x), takes 30-60s to stabilize, "too long" for the audio pipe which blocks, causing audio frames to be lost in the first 1min of stream and causing overrun/desync in first 1min of stream [22:30:14 CET] <shincodex> why is x264 pixelating [22:30:18 CET] <shincodex> Something default something [22:30:41 CET] <shincodex> "vlc had less pixelation" [22:30:49 CET] <shincodex> "when i set keyframes to 1" it best [22:30:49 CET] <furq> could you be less specific [22:30:57 CET] <xtina> kepstin: i set a max interleave delta to 500ms [22:31:03 CET] <xtina> if it goes above that the stream would fail with tons of error msgs [22:31:03 CET] <mdavis> xtina: I think you can get rid of the -analyzeduration by using -c:a mp3 and -c:v h264. Might help with the startup time. [22:31:04 CET] <xtina> i dont' see that [22:31:06 CET] <shincodex> Im so low on ram to even be more specific [22:31:07 CET] <shincodex> lol [22:31:17 CET] <xtina> instead i slowly see the ffmpeg speed drift to 0.97, 0.96, ... for minutes [22:31:35 CET] <shincodex> is there a avdictionary options [22:31:45 CET] <shincodex> for h264 to tell it the defaults are bad stop that [22:32:05 CET] <xtina> kepstin: the stream doesn't ever violate the 500ms desync and fail. i notice the audio overrun first and kill the stream [22:32:22 CET] <xtina> unless you're saying a small sub 500ms desync could be causing the audio to overrunn? [22:32:26 CET] <kepstin> xtina: that has nothing to do with the problem i'm talking about [22:32:33 CET] <mdavis> shincodex: Maybe you're looking for the -crf switch? [22:32:34 CET] <xtina> because i think this is possible - i was noticing the stream beginning to desync a tiny bit... [22:32:42 CET] <kepstin> the issue is probably that ffmpeg is reading the audio slightly faster than the video or vice versa [22:32:56 CET] <kepstin> because the timestamps on the audio vs video input streams aren't quite clocked the same [22:33:10 CET] <xtina> kepstin: i see. can i clock them...? [22:33:16 CET] <xtina> i've been curious if i can add timestamps and align them [22:33:20 CET] <kepstin> the solution to that is usually to retimestamp the video to match the audio, which you can't do in ffmpeg command line unless you re-encode [22:33:21 CET] <xtina> if so i could maybe ignore packet drops [22:33:27 CET] <shincodex> crf [22:33:31 CET] <mdavis> shincodex: -crf 23 is visually almost perfect [22:33:52 CET] <shincodex> --crf <float> (x264) -crf <float> (FFmpeg) Constant quality mode (also known as constant ratefactor). Bitrate corresponds approximately to that of constant quantizer, but gives better quality overall at little speed cost. The best one-pass option in x264. [22:33:59 CET] <shincodex> What is default crf [22:34:00 CET] <kepstin> nah, crf 23, the default, is "usually good enough for most cases" but it can get a bit blocky in high motion stuff [22:34:19 CET] <kepstin> default options, assuming you have a modern ffmpeg and not an old broken one, are preset=medium crf=23 [22:34:27 CET] <shincodex> hmm [22:34:30 CET] <xtina> mdavis: i will try your suggestion of reducing startup time with c:a etc [22:34:30 CET] <shincodex> let me see if i can find ver [22:34:33 CET] <mdavis> OK, visually perfect is a bit much, but it's pretty good [22:35:01 CET] <kepstin> around crf=18 is usually considered to not give noticable artifacts ("visually lossless") [22:35:11 CET] <kepstin> depends on preset a bit too [22:35:36 CET] <shincodex> hold on [22:35:50 CET] <shincodex> avcodec version [22:35:50 CET] <shincodex> right? [22:35:51 CET] <xtina> kepstin: gotcha, so no timestamping unless i re-encode [22:35:58 CET] <mdavis> That'll work [22:36:20 CET] <xtina> i have to use sox to encode the audio so there's no hope of adding timestamps without re-encoding at least the audio [22:36:27 CET] <shincodex> #define LIBAVCODEC_VERSION_MAJOR 56 #define LIBAVCODEC_VERSION_MINOR 12 #define LIBAVCODEC_VERSION_MICRO 101 [22:36:55 CET] <kepstin> xtina: the audio can't really be retimestamped, it's a fixed clock based on the samplerate (e.g. 48000 samples per second) [22:37:12 CET] <xtina> oh, well then that's straightforward right? [22:37:15 CET] <kepstin> xtina: which is why the video is usually reclocked - it's hard to notice difference of a few ms in frame timing [22:37:47 CET] <xtina> if i did video command and timestamped video in ffmpeg (omx_h264) would that be 1 encoding or 2? [22:37:53 CET] <mdavis> shincodex: The one I built last week is 57.80.101, so it's not that old [22:37:54 CET] <xtina> (no raspivid) [22:38:47 CET] <kepstin> if you have a 30fps video and a 48000kHz audio, but the device producing the video and the device producing the audio are running off different clocks with slightly different speeds (they usually are...), then something reading both of them will slowly get more and more desynced [22:38:50 CET] <xtina> would it be raw video -> add timestamp -> h264 encoding [22:38:59 CET] <xtina> or raw -> h264 -> decode+timestamp -> re-h264 [22:39:22 CET] <kepstin> xtina: I'm not sure, I don't know enough about how the rpi camera works [22:39:23 CET] <xtina> kepstin, ohh i see [22:39:31 CET] <shincodex> cant find default [22:39:35 CET] <shincodex> looking for it in code [22:39:46 CET] <xtina> that must be happening... my streams do slowly desync as they go on [22:39:59 CET] <shincodex> i assume its memset(blah, 0, sizeof(blah)); [22:39:59 CET] <shincodex> thop [22:40:17 CET] <xtina> kepstin: do you think i have a hope of timestamping my video in ffmpeg and then clocking it to my 44.1khz audio? [22:40:23 CET] <xtina> to avoid this little clock difference? [22:40:29 CET] <xtina> or is there a way to .. match the clocks? [22:40:44 CET] <mdavis> shincodex: So you're using the library API> [22:40:45 CET] <xtina> the video and audio clocks themselves, i mean [22:40:50 CET] <shincodex> Yes. [22:40:59 CET] <shincodex> that why i talk about options [22:41:01 CET] <shincodex> its prob 0 [22:41:12 CET] <shincodex> and ffmpeg or vlc or both give it 23 by default [22:41:17 CET] <mdavis> shincodex: Not as familiar with the library, let me dig around [22:41:26 CET] <shincodex> i just see crf everywhere [22:41:34 CET] <kepstin> xtina: probably the best you can do on ffmpeg is have it read the audio as fast as possible, then retime the video based on the "realtime" clock while also reading it as fast as possible, then the audio should more or less match up with the frame you get at the same time. [22:41:47 CET] <kepstin> xtina: that's the best you can do with the ffmpeg cli [22:42:40 CET] <xtina> i see, thank you. in this method, the audio has timestamps or no? [22:42:54 CET] <kepstin> audio timestamps are just the sample rate [22:43:19 CET] <xtina> oh sorry [22:43:28 CET] <xtina> and is the muxer able to mux based on timestamps in realtime? [22:43:43 CET] <mdavis> shincodex: and you're using libx264 for encoding [22:43:45 CET] <mdavis> ? [22:45:15 CET] <kepstin> xtina: you can use the setpts video filter to throw away the video timestamps and replace them with realtime. [22:45:53 CET] <kepstin> I'm not overall sure how well that will work, but it might be enough. [22:46:35 CET] <xtina> kepstin: cool :) i'm excited to hear a new idea. i'll try it out right now. thanks for humoring me [22:46:56 CET] <shincodex> Im using whatever is there [22:46:58 CET] <shincodex> so im guessing no [22:47:11 CET] <kepstin> (if you're using ffmpeg to capture audio and webcam video (v4l at least, not sure about rpi cam) at the same time, it generates video frame timestamps like this by default i think) [22:47:35 CET] <shincodex> rtsp stream [22:47:38 CET] <shincodex> no devices like that [22:47:42 CET] <shincodex> no audio either [22:48:13 CET] <kepstin> shincodex: hmm, you're doing network streaming (rtp/udp)? then you might be seeing packet loss rather than an encoding issue... [22:48:15 CET] <shincodex> --enable-parser=h264 --enable-decoder=h264 [22:48:23 CET] <xtina> kepstin: gotcha. i just can't do the audio this way i think but i'll try your suggestion [22:48:31 CET] <shincodex> "VLC IS SO MUCH BETTER" [22:48:35 CET] <shincodex> and im like "THERE THE SAME THING [22:48:49 CET] <shincodex> mostly [22:49:40 CET] <furq> who would ever suggest vlc for anything [22:50:01 CET] <mdavis> I mean, viewing media files on a desktop, sure [22:50:07 CET] <furq> nope [22:51:29 CET] <xtina> kepstin: i'm still trying to wrap my head around the possibility that, because a/v might have slightly diff clocks, audio is read faster than video, causing speed to go below 1.0x for a few mins (why?) before audio overflows [22:52:26 CET] <xtina> so speedd would go under 1.0x because eventually ffmpeg is sitting waiting for the slower clock (video)..? [22:52:44 CET] <kepstin> xtina: if it's reading audio faster than video, speed would go down because at some point it'll try to read audio, there's no audio ready, so it'll wait for a bit until some new audio is available [22:53:03 CET] <kepstin> then while it's waiting, the video buffer will be getting more and more full [22:53:09 CET] <xtina> right [22:53:19 CET] <mdavis> It might not even be about the clock. It could be due to the OS's thread scheduling. [22:53:19 CET] <kepstin> (if the speeds are the other way, switch "audio" and "video") [22:53:27 CET] <xtina> well my audio buffer is always the culprit of overflowing, but i don't know if raspivid complains when its buffer overflows [22:53:29 CET] <xtina> i've never seen it [22:53:38 CET] <xtina> probably the other way around [22:54:07 CET] <kepstin> raspivid probably just hangs, then gives the next frame with an even further off timestamp, which makes the problem worse :/ [22:54:24 CET] <kepstin> is the pi zero only single core? [22:54:46 CET] <kepstin> a single 1ghz arm core really isn't very much do doing, well, anything with video :) [22:58:32 CET] <xtina> kepstin: single core ya [22:58:52 CET] <xtina> hmm [22:59:05 CET] <xtina> so you think even if i use setpts to attach realtime ts's, they will be even further off [22:59:18 CET] <thebombzen_> xtina: what "times" is it reading/writing [22:59:18 CET] <xtina> so then it would be better if i added timestamps in a different thread than ffmpeg? [22:59:28 CET] <thebombzen_> is it still 0.66x or 0.67x? [22:59:38 CET] <kepstin> xtina: it should fix the gradual change of sync, but it might cause you to have a larger constant desync [22:59:38 CET] <xtina> thebombzen_: i'm not manually doing anything with timestamps [22:59:54 CET] <xtina> but if you mean my speeds.. i'm at 1.0x now after the first 20s or so [22:59:59 CET] <kepstin> (and depending on the other apps, it could make video "jumpy") [23:00:03 CET] <xtina> and stay there til 30min in when i start to go 0.99, 0.98, etc. [23:00:09 CET] <xtina> kepstin: i see [23:00:10 CET] <thebombzen_> because earlier, you mentioned that it was 0.66 or 0.67x and were encoding with raspivid at 10fps and used ffmpeg -framerate 15 -i [23:00:11 CET] <xtina> hmmmm [23:00:52 CET] <xtina> thebombzen_: er.. sorry, hard to remember because i've been through so many iterations :( but i got a new wifi module that is capable of better speeds [23:01:00 CET] <xtina> i think i was network throttled before [23:01:15 CET] <xtina> now i can get like 10 up or so if i'm lucky haha [23:04:54 CET] <xtina> kepstin: er, for realtime ts on the video, would i set setpts to time(0) [23:04:55 CET] <xtina> ? [23:05:03 CET] <xtina> RTCTIME The wallclock (RTC) time in microseconds. This is deprecated, use time(0) instead. [23:07:02 CET] <xtina> oh, doh, there's a 'realtime' filter.. [23:07:25 CET] <kepstin> nope, that's not what you want :) [23:07:33 CET] <xtina> oh nvm, that's wrong [23:07:38 CET] <xtina> realtime is wrong, at least :) [23:07:47 CET] <kepstin> xtina: using "settb=1000000,setpts=RTCTIME-RTCSTART" should do it [23:08:06 CET] <kepstin> (it says RTCTIME is deprecated, but it's easier than using time() since it has the same units as RTCSTART [23:08:07 CET] <kepstin> ) [23:08:28 CET] <xtina> ohh, i see :) [23:08:38 CET] <kepstin> settb=AVTB,setpts=RTCTIME-RTCSTART should be equivalent I think [23:10:42 CET] <thebombzen_> now, is it possible to use settb and setpts without decoding? [23:11:00 CET] <thebombzen_> ideally those are all managed by the container, right? [23:21:16 CET] <kepstin> thebombzen_: ffmpeg cli doesn't support doing much with timestamps when not re-encoding, since most ts manipulation is done by filters [23:21:36 CET] <kepstin> (ts manipulation on encoded video is tricky, since frames get re-ordered [23:21:47 CET] <kepstin> and then you have both dts and pts) [23:21:50 CET] <thebombzen_> ah so it's possible but specialized and therefore hard to do with ffmpeg.c [23:22:41 CET] <xtina> kepstin: how does this look for the audio ts? -filter:a "asettb=1000000,asetpts=N/SR/TB" \ [23:24:08 CET] <kepstin> xtina: don't manipulate the audio ts. if you do, the best you'll get is crackly audio since blocks of samples aren't continuous [23:24:18 CET] <kepstin> xtina: only do stuff to the video frame ts. [23:25:40 CET] <xtina> kepstin: ah i see :) [23:25:45 CET] <xtina> i get some crazy stuff if i only set video ts [23:25:46 CET] <xtina> http://vpaste.net/iknXI [23:26:01 CET] <xtina> frame= 1 fps=0.2 q=1.6 Lsize= 109kB time=19884:06:28.23 bitrate= 0.0kbits/s speed=1.31e+07x [23:38:35 CET] <mdavis> BtbN: I think I'm on to something. MinGW's unsigned long seems to be 4 bytes, but Cygwin64's unsigned long is 8 bytes [23:38:51 CET] <mdavis> Will explore further. [23:39:06 CET] <BtbN> so the sizes of the structs are different between them? [23:39:25 CET] <mdavis> Yup [23:39:33 CET] <BtbN> Well, that's a very good reason [23:39:42 CET] <mdavis> That would do it, I think [23:40:12 CET] <mdavis> So, with some judicious use of sys/types.h, this might be fixable :D [23:40:23 CET] <mdavis> rather, stdint.h [23:40:25 CET] <kepstin> that sounds like cygwin just watching linux programmer's expectations rather than mingw [23:40:40 CET] <kepstin> mdavis: that would kind of break using any cygwin system library... [23:40:46 CET] <BtbN> mdavis, no, that'd be bad. [23:40:55 CET] <BtbN> As the sizes would mismatch on other OS then [23:40:58 CET] <kepstin> mdavis: might as well just write native windows app instead [23:41:08 CET] <mdavis> :/ [23:41:19 CET] <BtbN> The official cuda headers use those types [23:41:32 CET] <BtbN> so we have to use the same, as the sizes between Linux and Windows would mismatch otherwise [23:42:03 CET] <kepstin> when linux went to 64bit, 'int' was left at 32bit and 'long' was made 64bit; windows left 'int' and 'long' as both 32bit for app compat reasons I guess :/ [23:42:03 CET] <mdavis> Alright, maybe there's a switch or a define for cygwin's GCC to make it behave more like mingw [23:42:21 CET] <kepstin> mdavis: no, that's such a fundamental change that switching it breaks everything [23:42:27 CET] <kepstin> just use mingw's compiler :/ [23:43:21 CET] <mdavis> That defeats the purpose of using cygwin! I want to make everything difficult! [23:43:37 CET] <xtina> kepstin: still tinkering but haven't found what's wrong with my setpts, anything you recognize? [23:43:43 CET] <xtina> http://vpaste.net/iknXI [23:43:43 CET] <mdavis> I'm not proposing that this be incorporated into the codebase, I just want it to work for me [23:43:51 CET] <kepstin> xtina: no idea :/ [23:44:30 CET] <xtina> i mean, the audio file doesn't have timestamps right? [23:45:01 CET] <xtina> it read 1 video packet and hundreds of audio packets [23:45:15 CET] <mdavis> kepstin: Indeed: https://cygwin.com/cygwin-ug-net/programming.html#gcc-64 [23:45:53 CET] <xtina> i thought i needed to set asetpts based on 44.1Khz so the audio file has timestamps for the video file to match with [23:46:02 CET] <xtina> but not sure [23:46:16 CET] <kepstin> xtina: the audio timestamps are inferred from the sample rate [23:46:42 CET] <kepstin> since there's e.g. 44100 samples in a second, that means the timestamp goes up by 1s every 44100 samples [23:46:47 CET] <xtina> in ffmpeg docs it gives this example: asetpts=N/SR/TB [23:46:52 CET] <xtina> is that really default? [23:46:57 CET] <xtina> otherwise why's it an example? [23:47:07 CET] <xtina> just wanna make sure the issue isnt w the audio [23:47:43 CET] <kepstin> xtina: the audio timestamps in your case are set by the wav demuxer when it reads the audio from the pipe, and they're set to the exact correct values based on the sample rate [23:48:12 CET] <xtina> i see [23:48:12 CET] <BtbN> yeah, "unsigned long" is 4 bytes on Windows, and 8 on Linux. [23:48:20 CET] <BtbN> cygwin follows linux, so it'S 8 bytes there [23:48:33 CET] <BtbN> which obviously breaks [23:48:48 CET] <xtina> the only ts-related printout i got: tb:1/1000000 pts:0 -> tb:1000000/1 pts:0 [23:48:51 CET] <thebombzen_> 44.1 kHz is divisible by 3^2 and 7^2 so that's not possible unless the timebase has two factors of three and two factors of seven [23:48:58 CET] <xtina> the 1st video packet [23:49:31 CET] <thebombzen_> in particular, one million has no factors of 3 and 7 so if PTS is per-sample, it's not possible to do 44.1 kHz perfectly with a timebase of 1 million [23:50:09 CET] <kepstin> thebombzen_: well, when audio's muxed into a container, and the container doesn't support 1/44100 timebase, then the times will have to be rounded to the nearest supported, yeah [23:50:26 CET] <kepstin> thebombzen_: but ffmpeg internally has no issue using 1/44100 timebase... [23:50:36 CET] <thebombzen_> but it depends on how they're rounded. if the muxer muxes them and rounds them afterward, sure [23:51:02 CET] <thebombzen_> but if the muxer has a fixed difference between samples, then there will be issues [23:51:38 CET] <thebombzen_> also it doesn't need to support a 1/44100 timebase - just 1 / any multiple of 44100 [23:53:14 CET] <xtina> thebombzen: do i need to choose a timebase other than 1000000? one that is a factor of 44.1k? [23:53:29 CET] <xtina> er [23:53:30 CET] <xtina> a multiple** [23:53:36 CET] <kepstin> xtina: don't change the audio timestamps! they're fine! [23:53:58 CET] <xtina> kepstin: alright :) [23:55:03 CET] <kepstin> most video players don't actually use the container timestamps on audio for anything other than seeking, normally... they simply get the continuous samples from the decoder, send them to the sound card to play on the soundcard clock, then show the video frames matching the audio rate as close as possible [23:55:47 CET] <xtina> i am trying to understand why my ffmpeg speed is 'speed=1.86e+07x' [23:56:18 CET] <kepstin> xtina: it probably read a bunch of video frames in a batch quickly, so the speed calculation got weird. [23:56:27 CET] <xtina> it seems like maybe just reading 1 video packet made ffmpeg think it was going super fast [23:56:38 CET] <xtina> kepstin: i mean i've never seen speed surge above 3x... not 7 orders of magnitude lol [23:56:46 CET] <xtina> whatever changed is a result of the setpts command [23:56:47 CET] <kepstin> I have no idea which timestamps the speed is calculated on, input or output [23:56:51 CET] <kepstin> could look at the code I guess [23:56:59 CET] Action: kepstin has to go now, tho [23:57:06 CET] <xtina> okok. thanks again for all the help [23:57:14 CET] <xtina> i think it might be a clock issue so i'll keep trying [23:58:21 CET] <BtbN> mdavis, https://github.com/BtbN/FFmpeg/commit/266087949410ca5820ceb1dccdaddead664a6… [23:59:19 CET] <BtbN> entirely untested though [00:00:00 CET] --- Tue Feb 28 2017

1 0

ffmpeg-devel.log.20170226
by burek 27 Feb '17

27 Feb '17

[01:35:19 CET] <mfg> Hi, I submitted a patch to the ML, but I'm having a hard time getting it pulled in -- are people just busy or did I offend someone. Its the strptime changes... [01:39:22 CET] <JEEB> people can be busy/not notice/etc [01:39:45 CET] <JEEB> I usually wait a few times and then ping if nobody has noted anything (usually a couple of work days) [01:40:18 CET] <mfg> ok... its been a week and i sent a reminder mid week. I'll ask again on Monday, but I wanted to make sure I hadn't been black-balled or something -- I accedentally top-posted in one of my emails. [01:42:54 CET] <memeka> hi, are there any plans on adding v4l2 m2m to ffmpeg? [01:44:08 CET] <JEEB> heh, just read what I replied to you @ the user channel :P [01:44:33 CET] <JEEB> mfg: people don't start ignoring you because of that as long as any future correspondence is OK [01:44:59 CET] <memeka> thanks; i saw there were some patches i see submitted a while ago (2 yrs) but they were refused [01:45:19 CET] <mfg> alright. I'll assume it just busy. Thanks [01:46:37 CET] <JEEB> also was going to say that it really depends on which component etc he had posted the patch :P [01:47:03 CET] <memeka> when i tried them with a more recent ffmpeg version, i had an issue with the h264 decoder: my v4l4 m2m decoder accepts only annexB format [01:48:01 CET] <memeka> so i added an annexB converter here: https://github.com/mihailescu2m/FFmpeg/commit/d012bc50211fbf8c2cd61624d71fc… -- however it didn't change anything, decoder still complains about annexB -- did i do something wrong with the converter? [01:48:37 CET] <JEEB> check what the error is actually checking for [01:48:39 CET] <memeka> converting an entire clip to ffmpeg to annexB and then playing it with the m2m decoder works fine [01:49:17 CET] <memeka> so with or without the patch, converting to annexB then playing the clip works fine [01:49:24 CET] <memeka> unconverted, it fails [01:51:41 CET] <memeka> JEEB: -codec:v copy -codec:a none -bsf:v h264_mp4toannexb -f rawvideo [01:51:49 CET] <memeka> if i add this it works [01:52:14 CET] <memeka> i thought adding this: https://github.com/mihailescu2m/FFmpeg/commit/d012bc50211fbf8c2cd61624d71fc… would do the same thing [01:54:58 CET] <memeka> JEEB: this is the entire command line that works: ffmpeg -i ./sintel_trailer_1080p.mp4 -codec:v copy -codec:a none -bsf:v h264_mp4toannexb -f rawvideo - | ffplay -an -vcodec h264_v4l2m2m - [01:55:23 CET] <memeka> h264_v4l2m2m decoder works if h264 is converted to annexB [01:58:58 CET] <wm4> libav has autobsf for decoding [01:59:46 CET] <memeka> libav doesn't do v4l2 m2m :( [02:01:55 CET] <jamrial> durandal_1707: dbc7f02a727286f353624cf690cc6f430e240e25 broke fate-ffprobe [02:05:50 CET] <jamrial> wm4: libav doesn't have autobsf. that's something rcombs wrote [02:06:30 CET] <wm4> jamrial: wut [02:06:44 CET] <wm4> "autobsf for decoding" [02:13:16 CET] <memeka> so, anyone can help ... why won't my patch convert to annexB? :( [02:14:10 CET] <JEEB> memeka: just check what the error you're getting inside the code is checking for [02:14:18 CET] <JEEB> then check why that is getting triggered [02:15:13 CET] <memeka> there is no error, i says that it was "successfully converted to annexb" (so av_bitstream_filter_filter is succefful) but then fails to decode [02:15:36 CET] <JEEB> that's why I'm asking [02:15:50 CET] <JEEB> "it still complains about annexb" [02:16:04 CET] <JEEB> what and where complains, and check why [02:16:25 CET] <JEEB> if you think you are doing it correctly, go check what that thing is checking for [02:16:40 CET] <memeka> the decoder refuses the frame [02:16:47 CET] <JEEB> either you will find that you have forgotten to do something, or the check is now incorrect [02:16:49 CET] <memeka> it doesn't know how to decode it [02:17:17 CET] <memeka> it's like trying to play a .txt file [02:17:55 CET] <JEEB> I don't think it's that hard to grasp the concept of "it's complaining of X even though I'm supposedly handling that already - I might need to check what that complaining check is actually checking for" [02:18:32 CET] <memeka> i was just wondering if i am doing annexB conversion correctly [02:18:49 CET] <JEEB> and that either leads you to noticing that you have overlooked something, or that the check in that other part of code is incorrect [02:18:55 CET] <memeka> it's the first time i look at the ffmpeg code, the m2m patches were not done by mw [02:19:43 CET] <JEEB> yes, I understand, but that's the only way. except for dumping the results of your annex b conversion to a file and trying to read that as -f h264 with ffmpeg.c f.ex. [02:19:52 CET] <JEEB> but even that you might get incorrectly [02:20:01 CET] <JEEB> so better check the darn complaining check [02:20:13 CET] <JEEB> it will either give you a hint of what you might be doing wrong [02:20:16 CET] <JEEB> or just missing [02:20:23 CET] <JEEB> or just plaing incorrect check at this point [02:20:27 CET] <JEEB> *plain [02:21:26 CET] <memeka> ok i will try to give more detailed info - i don't have access to the box atm so i couldn't give you the exact error [02:21:49 CET] <JEEB> *I* don't need the exact error [02:22:10 CET] <memeka> i noticed tho` that the first packet is not converted, only subsequent packets -- maybe that's my problem [02:22:24 CET] <JEEB> you know more or less which kind of error you are getting and you have your current FFmpeg code base public it seems, so you have access to that [02:22:40 CET] <JEEB> yes, that could very well be what the check's checking for :P [02:23:03 CET] <JEEB> first packet(s) and if they match annex b or AVCc f.ex. [02:24:29 CET] <memeka> i looked in the libav h264 decoder, and i don't see it converting to annexB either (https://github.com/libav/libav/blob/master/libavcodec/h264dec.c) [02:24:55 CET] <memeka> so if it's done, it must be done somewhere else [02:26:53 CET] <memeka> i see that ff_h2645_packet_split has argument is_avc, which i assume is related to annexB? [06:37:21 CET] <durandal_1707> adeeln_: also add decription to libavcodec/codec_desc.c [06:40:19 CET] <adeeln_> Done. Does XMP stand for Extreme Memory Profile? [06:43:56 CET] <durandal_1707> probably no [06:44:14 CET] <adeeln_> Extensible Metadata Platform? [06:46:23 CET] <durandal_1707> X PixMap [06:47:19 CET] <durandal_1707> its in link i sent you [06:48:22 CET] <adeeln_> Oh, my bad. [06:49:33 CET] <atomnuker> but its called XMP, it would have to be X MapPix which doesn't make sense [06:52:18 CET] <adeeln_> Wait. What? [06:54:06 CET] <adeeln_> It's Extensible Metadata Platform, I think. [https://github.com/fluent-ffmpeg/node-fluent-ffmpeg/issues/484] [06:57:20 CET] <durandal_1707> lol, ita description wrong, should be XPM on trac [06:58:06 CET] <adeeln_> Adobe XMP Core 5.5-c021 [https://trac.ffmpeg.org/ticket/4701] [06:59:48 CET] <durandal_1707> XMP is metadata thing [07:02:12 CET] <adeeln_> Read here [http://www.adobe.com/devnet/xmp.html] but I guess you already knew that. [07:02:45 CET] <durandal_1707> it was so long ago that i forgot to type it properly [07:04:02 CET] <adeeln_> Such silly mistakes... [07:05:33 CET] <durandal_1707> you found first bug [07:05:51 CET] <adeeln_> I don't think so. [08:35:22 CET] <adeeln_> durandal_1707: What about the changes made in other files? like the changes made in parseutils.c on [https://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/126647.html] are not available on GitHub[https://github.com/FFmpeg/FFmpeg/blob/master/libavutil/parseutils.c]. You only sent the difference file. [09:12:49 CET] <adeeln_> So, I have created extracted the xmpdec.c file, shared here[https://gist.github.com/adl1995/fda8021a256396a62c9606cfc65e6314]. Pastebin blocked in my country. I have made changes in the origianal Makefile in /examples directory and linked this with it. [09:13:07 CET] <adeeln_> original* [09:24:16 CET] <adeeln_> What should I do next? [09:54:50 CET] <durandal_1707> get it build [10:18:47 CET] <adeeln_> It's finally XPM :D [16:48:43 CET] <michaelni> durandal_1707, dbc7f02a727286f353624cf690cc6f430e240e25 seems to break fate-ffprobe_* [16:49:12 CET] <michaelni> http://fate.ffmpeg.org/report.cgi?time=20170226003803&slot=x86_64-netbsd-gc… [17:07:25 CET] <cone-272> ffmpeg 03Paul B Mahol 07master:3a003cc3817f: fate: update ffprobe stuff after dbc7f02a727286f3 [17:16:53 CET] <cone-272> ffmpeg 03Micah Galizia 07master:489c09ad4b1a: add locale month names to av_small_strptime [17:16:54 CET] <cone-272> ffmpeg 03Michael Niedermayer 07master:0716bcce5bdc: avcodec/ituh263dec: Check for the bitstream end in ff_h263_decode_mb() [17:16:55 CET] <cone-272> ffmpeg 03Michael Niedermayer 07master:aff8cf18cb0b: avcodec/mpeg12dec: Fix runtime error: left shift of negative value -2 [17:16:56 CET] <cone-272> ffmpeg 03Michael Niedermayer 07master:87eb3749708c: avcodec/eac3dec: Fix runtime error: left shift of negative value -3 [17:16:57 CET] <cone-272> ffmpeg 03Michael Niedermayer 07master:7e9ba78f6bd1: avcodec/flacdsp: Fix: runtime error: signed integer overflow: -1027555328 + -1226681270 cannot be represented in type 'int' [21:12:13 CET] <BBB> michaelni: please specify what SUINT means, its very unclear to me [21:14:03 CET] <BBB> michaelni: e.g. grep -r SUINT $srcdir is empty for me? [21:14:22 CET] <kierank> https://patchwork.ffmpeg.org/patch/1792/ [21:16:11 CET] <BBB> Im going to vomit for a second, hold on - brb [22:11:21 CET] <cone-272> ffmpeg 03Paul B Mahol 07master:6d856b257997: avcodec/scpr: add support for older version [22:12:25 CET] <durandal_1707> RiCON: ^ [22:32:51 CET] <Compn> durandal_1707 : any chance you want to tackle vivo codecs? h263 based... [22:33:16 CET] <JEEB> I should rebase some of my patches... [22:33:26 CET] <JEEB> (unrelated to that specific format family) [22:33:55 CET] <durandal_1707> Compn: have encoder and codec binary? [22:34:43 CET] <durandal_1707> JEEB: what patches? [22:34:52 CET] <JEEB> earthsoft dv demuxer [22:35:00 CET] <JEEB> I got as far as being able to play back audio [22:35:38 CET] <durandal_1707> good ;) being useful to community [22:36:11 CET] <JEEB> aye :) [22:36:18 CET] <JEEB> not something like the ISML shit :DDDDDDDD [22:36:26 CET] Action: JEEB hates that shit with passion by now [22:36:55 CET] <kierank> JEEB: i feel so bad [22:36:56 CET] <kierank> for you [22:37:46 CET] <JEEB> kierank: meanwhile I have a stash of booze for the time when someone tells me that I have to implement MMTP [22:38:00 CET] <kierank> lol [22:38:08 CET] <kierank> that thing [22:38:13 CET] <kierank> in.sane [22:38:35 CET] <JEEB> is it actually required by ATSC 3? [22:38:49 CET] <Compn> durandal_1707 : vivoactive producer for encoder [22:39:18 CET] <durandal_1707> you have it? [22:40:16 CET] <durandal_1707> is it vfw kind? [22:40:27 CET] <Compn> uhhhh [22:42:32 CET] <Compn> hmmmmm [22:42:35 CET] <Compn> not vfw i dont thin [22:43:09 CET] <durandal_1707> just encode full white or black frame [22:51:03 CET] <kierank> i wonder if I can troll durandal_1707 into finishing mpeg-4 sstp [22:51:53 CET] <durandal_1707> mpeg4 is one big mess in lavc [22:52:23 CET] <durandal_1707> kierank: whats missing? [22:52:58 CET] <kierank> dpcm mode and painful integration into mpegvideo.c [22:53:09 CET] <kierank> and samples [22:53:48 CET] <durandal_1707> thats why i prefer working on stuff i can freely encode [22:56:01 CET] <atomnuker> durandal_1707: write some encoders then, lol [22:56:15 CET] <JEEB> lulzifications [22:56:34 CET] <JEEB> since you'd still not know if your output would be interoperable [22:56:47 CET] <durandal_1707> i wanted to add some rle encoders [22:56:56 CET] <kierank> durandal_1707: https://wiki.videolan.org/Bounties/#Libavcodec_bugs [22:57:30 CET] <kierank> or add missing cineform features [22:57:58 CET] <durandal_1707> i hate sony [22:58:29 CET] <kierank> cineform is not sony [22:58:35 CET] <kierank> it is gopro [22:58:40 CET] <JEEB> ^ [22:58:44 CET] <RiCON> durandal_1707: nice, thanks [22:59:01 CET] <durandal_1707> cineform interlaced , looks easy [22:59:13 CET] <kierank> interlaced is easy yes [22:59:21 CET] <kierank> just modify code to do the transform on each field [22:59:32 CET] <kierank> but there are some samples which have some kind of p-frame [22:59:34 CET] <kierank> that I never did [22:59:49 CET] <durandal_1707> huh? [23:00:37 CET] <durandal_1707> i still need to motivate myself to work on atrac9 [23:02:39 CET] <atomnuker> durandal_1707: I'll help you myself, just give me some quantized coefficients [23:03:43 CET] <durandal_1707> i still need to find how to decompress them :) [23:10:47 CET] <cone-272> ffmpeg 03Marton Balint 07master:e0eb0bdab948: avdevice/decklink_enc: convert to codecpar [23:10:48 CET] <cone-272> ffmpeg 03Marton Balint 07master:48f8ad329010: avdevice/decklink_enc: add support to specify field order [23:10:49 CET] <cone-272> ffmpeg 03Marton Balint 07master:418ce915071e: avdevice/decklink_enc: convert AVFMT_RAWPICTURE to AV_CODEC_ID_WRAPPED_AVFRAME [23:10:50 CET] <cone-272> ffmpeg 03Marton Balint 07master:80b644c6ee3e: avdevice/decklink_dec: remove AVFMT_RAWPICTURE [23:16:25 CET] <RiCON> durandal_1707: without using illegal at9tool you mean? [23:17:21 CET] <Compn> probably he means something easy software to encode without installing 500mb program suite [23:17:41 CET] <durandal_1707> psst [23:18:43 CET] <Compn> durandal_1707 : do you encode on linux or windows ? [23:18:48 CET] <RiCON> Compn: it's easily found, but also comes with headers and code [23:18:52 CET] <RiCON> from sony [23:19:11 CET] <durandal_1707> i downloaded >2gb just to find out wine crashes [23:25:08 CET] <durandal_1707> could add dnxhr encoder as gsoc task :) [23:25:55 CET] <atomnuker> >yet another 8x8 dct codec [23:26:19 CET] <durandal_1707> it have alpha too [23:26:56 CET] <durandal_1707> can be stored losslesly [23:27:31 CET] <durandal_1707> or even raw - no mention in spec - how odd [00:00:00 CET] --- Mon Feb 27 2017

1 0

ffmpeg.log.20170226
by burek 27 Feb '17

27 Feb '17

[00:00:27 CET] <klaxa> because my allocted outputs all have AVStream->codec->codec_id == AV_CODEC_ID_NONE [00:00:34 CET] <klaxa> but i guess that doesn't matter then? [00:00:56 CET] <klaxa> (AVStream->codec is AVCodecContext) [00:01:22 CET] <klaxa> however when reading the AVStream->codec AVCodecContext has these fields populated with the correct values [00:02:19 CET] <klaxa> and avformat_new_stream() wants const AVCodec *c [00:02:33 CET] <klaxa> but how do i get the proper AVCodec then if it is nowhere set? [00:02:46 CET] <klaxa> AVStream->codec->codec is NULL also for reading streams [00:03:49 CET] <klaxa> i want to copy the streams, the remuxing.c example uses deprecated fields [00:03:53 CET] <klaxa> i started working from there [00:12:51 CET] <klaxa> hmm it seems all the codec parameters in the output file are set correctly, but no frames are written, well, seems like the mistake is somewhere else [00:48:27 CET] <DHE> klaxa: we're in a grace period where the fields are merely deprecated. you should avoid using them and eliminate the compiler warnings in preparation for the version where they're gone entirely [00:49:55 CET] <DHE> AVStream->codecpar still has most (if not all) of the basic identification fields you need including codec_id [01:42:20 CET] <memeka> hi, are there any plans on adding v4l2 m2m to ffmpeg? [01:43:16 CET] <JEEB> depends on if anyone cares about it. check the issue tracker (trac.ffmpeg.org) and add a feature request if there's none yet [01:43:39 CET] <JEEB> basically people don't necessarily know or care, and the lack of knowledge can be fixed with a feature request [02:47:50 CET] <TerNer> JEEB: Are you there? [02:47:58 CET] <JEEB> never [02:48:03 CET] <TerNer> :o [02:48:45 CET] <TerNer> I have checked out fragmented-mp4, but there's also needed duration information in mdhd header [02:50:14 CET] <JEEB> there's that kind of stuff for a *fragment* (will take a look at the exact box names in addition to moof), but since in a live situation you'd just be putting one fragment after another there really isn't a "duration" until you've written everything down, if you ever have [02:51:00 CET] <JEEB> and fragments can be as long or short as you want, that really doesn't matter. they don't even technically have to start on a RAP [02:51:56 CET] <TerNer> :o [02:52:36 CET] <TerNer> can you tell me easier ;-; I'm not good at english... [02:57:01 CET] <Aison> hello [02:57:19 CET] <Aison> is it possible that ffmpeg has problems with decoding truehd 7.1? [02:57:32 CET] <Aison> I just got this message: Dependent substream decoding is not implemented. [03:00:27 CET] <JEEB> Aison: check with latest FFmpeg HEAD [03:00:41 CET] <JEEB> if it still happens, report it with a sample if possible @ trac.ffmpeg.org [03:02:21 CET] <Aison> hmm, another mkv file is not generating this warning, but the sound is still completely wrong [03:02:38 CET] <Aison> I guess it is a problem with truehd decoder [03:02:51 CET] <Aison> eac3 7.1 works [03:02:58 CET] <Aison> k [03:04:25 CET] <JEEB> mpeg-ts and matroska can generally be cut with something simple like dd [03:04:33 CET] <JEEB> so you can try to cut the first 20MiB or so [03:04:40 CET] <JEEB> and see if you can replicate [03:04:44 CET] <JEEB> thus you can make a small sample [03:04:48 CET] <Aison> ok [03:08:15 CET] <TerNer> JEEB, I tested with increasing/decreasing duration but It's not affect at result video. thank you alot for help! [03:33:01 CET] <Aison> ok, mplayer plays truehd correctly, vlc doesn't and so ffmpeg [03:33:05 CET] <Aison> ffmpeg (git) [03:33:14 CET] <Aison> so I create a sample tomorrow [03:33:57 CET] <Aison> looks like vlc and ffmpeg are using the same decoder which is not working [03:35:27 CET] <Aison> on the other hand, it looks like mplayer is also using avcodec [03:35:28 CET] <Aison> hmm [04:03:46 CET] <solrize> this is probably the wrong place to ask, but i'm trying to watch a video lecture and there's a lot of electrical buzzing (amplifier feedback or so) in the audio. is there a decent way to get rid of that? it might be 60 hz hum with a lot of harmonics i.e. i don't think i can take it out with a simple notch filter. thanks [04:04:25 CET] <solrize> actually i should probably ask on audacity instead of here. just thought of that [05:23:46 CET] <adeeln_> I'm starting out with libavcodec. Could anyone please provide a good starting point? Currently going through the codebase[https://github.com/FFmpeg/FFmpeg/search?utf8=%E2%9C%93&q=libavcode… [05:24:17 CET] <DHE> there's a number of sample applications in doc/examples/*.c have you checked them out? [05:28:06 CET] <adeeln_> Yes, I did. Actually I was having some trouble using the data structure. I asked this question on SO[http://stackoverflow.com/questions/42455677/ffmpeg-swsfilter-structure-u…. Could you please check it out? [05:31:56 CET] <adeeln_> I also want to get started on a qualification task, any help would be appreciated! [05:43:52 CET] <durandal_1707> adeeln_: that is very less used sws feature [05:45:22 CET] <adeeln_> I was just tinkering with it. Thought it was fun. [05:46:45 CET] <durandal_1707> adeeln_: you should better ask on mailing list [05:47:00 CET] <adeeln_> Okay. I will, from now on. [05:55:23 CET] <durandal_1707> adeeln_: on what you are working? [05:56:46 CET] <adeeln_> On XMP decoding, atomnuker is guiding me. [05:57:17 CET] <atomnuker> I got as far as take libavcodec/dpx.c, remove everything dpx related [05:57:30 CET] <atomnuker> and add an entry to allcodecs.h and allcodecs.c [05:57:41 CET] <atomnuker> (for AV_CODEC_ID_XMP) [05:58:09 CET] <durandal_1707> ah, that. feel free to ask on ffmpeg-devel channel [05:58:47 CET] <atomnuker> durandal_1707: can you continue (explain about libavcodec/Makefile, get data on the XMP, format, etc)? [05:59:05 CET] <durandal_1707> yes, will try [06:00:21 CET] <durandal_1707> adeeln_: you are free to ask questions any time [06:00:35 CET] <adeeln_> Okay. Thank you. [06:01:21 CET] <durandal_1707> right now i was sleeping though, what timezone you are? [06:01:53 CET] <adeeln_> UTC +5 [06:03:01 CET] <durandal_1707> did you added AV_CODEC_ID_XPM to libavcodec/allcodecs.h? [06:03:51 CET] <adeeln_> No, I can't find 'libavcodec/xpmdec.c' [06:04:17 CET] <durandal_1707> adeeln_: you are supposed to create such file [06:04:25 CET] <adeeln_> Oh, got it. [06:04:49 CET] <durandal_1707> adeeln_: i think i sent basic xpm decoder i while ago [06:05:13 CET] <durandal_1707> just search mailing list for xpm patches [06:05:32 CET] <adeeln_> I see. I will look into it. [06:05:50 CET] <durandal_1707> you of course need to extend it to be full featured [06:06:38 CET] <durandal_1707> that means support for more than 256 colors [06:07:02 CET] <adeeln_> Okay. [06:07:07 CET] <durandal_1707> even that is straightforward [06:10:25 CET] <durandal_1707> https://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/126647.html [06:11:23 CET] <durandal_1707> you need just to clean this patch and remove colors name stuff for now [06:11:59 CET] <durandal_1707> and extend it for >256 colors [06:12:41 CET] <adeeln_> Understood. Where do I post the result when I'm done? (considering I can do it). [06:13:06 CET] <durandal_1707> to ffmpeg-devel mailing list [06:13:25 CET] <adeeln_> Okay. [06:21:51 CET] <adeeln_> Can't really find the old message you sent me. Searched the archive[http://www.ffmpeg-archive.org/]. Was this[https://ffmpeg.org/pipermail/ffmpeg-devel/2012-June/126647.html] just it? [06:34:34 CET] <adeeln_> durandal_1707: I've done this so far: 1) copy libavcodec/dpx.c into libavcodec/xpmdec.c 2) renamed ff_dpx_decoder into ff_xmp_decoder 3) add AV_CODEC_ID_XMP to libavcodec/allcodecs.c and libavcodec/avcodec.h [06:34:49 CET] <adeeln_> Should I move the discussion to ffmpeg-devel? [06:35:13 CET] <durandal_1707> adeeln_: yes [08:29:38 CET] <Aakash> I have made a rails app that can stream live videos to facebook rtmp server and deployed it on Digital Ocean. I have used nginx as web server and using a linux OS. The problem is that after streaming for some time(that keeps on varying) FFmpeg process gives the error av_interleaved_write_frame(): Broken pipe Pastebin link of command and logs: http://pastebin.com/vC1vLDEg [08:29:55 CET] <Aakash> Can anyone tell me the root cause of this errir? [08:30:02 CET] <Aakash> error*? [11:25:27 CET] <Ekho> when using map_metadata to add metadata from a file can I map the metadata to a specific stream and not the entire file? the [STREAM] tag seems to still add the metadata to the entire file, not sure I understand what it does exactly [13:25:22 CET] <BluesInTheNet> What video format would use least amount of cpu during playback if the video is just a single unchanging image? [13:29:24 CET] <adeeln_> Could it be H.264? Don't know for sure. [13:35:37 CET] <BtbN> CPU usage during playback isn't really a concern, unless you go for hevc or something like it. [13:36:25 CET] <JEEB> I think the AVC decoder is so optimized now that you can just use that (with -tune fastdecode if you really want to) [13:36:50 CET] <JEEB> but the best part for you if it's a single picture, is that if you just encode it once and set its duration to the duration of the whole video :P [13:37:09 CET] <JEEB> suddenly you've got that background image you needed really cheaply [13:38:54 CET] <BtbN> and then some crappy player barfs on it [13:39:03 CET] <BtbN> or YouTube just re-encodes to 2 second gops [13:40:07 CET] <JEEB> well youtube will do that anyways [13:40:14 CET] <JEEB> and in that case you've just saved bandwidth [13:40:24 CET] <JEEB> because you've transferred the image only once :P [13:40:39 CET] <BtbN> I'd just upload lossless stuff to YouTube if bandwidth and size allows [13:40:45 CET] <JEEB> yes [13:41:03 CET] <JEEB> even in that, having a single image vs the same image over 9000 times does save bandwidth, though :) [13:41:22 CET] <bencoh> :] [13:41:45 CET] <BluesInTheNet> thx [13:51:16 CET] <DHE> lower the framerate [14:13:41 CET] <JEEB> yes, that's what adding a single picture with all the duration you need means ;) [14:13:57 CET] <JEEB> and then utilize a container format that contains an actual duration, such as ISOBMFF [14:14:15 CET] <DHE> ah, yes that works [14:14:48 CET] <JEEB> stuff like matroska actually lacks a duration field, so the duration of the last picture is often left for guessing [14:15:19 CET] <JEEB> (there's a metadata field later added by mkvtoolnix, but, uhh... > trusting metadata fields where you have to parse a string to get a number) [14:15:52 CET] <JEEB> also that duration field IIRC is global, not track specific [14:16:26 CET] <JEEB> oh well, as long as it gets improved in matroska v5 which they will be making after they get the current crapshoot standardized :) [17:37:14 CET] <ftg> hello everyone, here is what ffmpeg -i outputs for my file: Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 12733 kb/s, 30 fps, 30 tbr, 60k tbn, 120k tbc (default) [17:37:46 CET] <ftg> I'd like to convert it into an ogg file to provide with video HTML5 player [17:38:17 CET] <ftg> what are the best options for ffmpeg to do it without too much quality loss [17:38:19 CET] <ftg> ? [17:39:18 CET] <BtbN> every browser supports h264 anyway. So why convert? [17:41:44 CET] <JEEB> ftg: theora is the worst alternative out of the freetard ones if you really want such. both vp8 and vp9 are available in all of the newer browser versions even if you strip out AVC/AAC support [17:42:24 CET] <JEEB> build FFmpeg with libvpx support (preferably the latest tag that chromium builds) and look at examples at the webm wiki [17:43:25 CET] <furq> or you know [17:43:29 CET] <furq> just leave it as h264 [17:43:36 CET] <ftg> furq: ok [17:43:52 CET] <JEEB> realistically, that's a good alternative as well as long as the bit rate is matching your requirements [17:43:59 CET] <JEEB> or I'd even say, the best alternative in that case [17:44:18 CET] <ftg> JEEB: may I degrade the video quality a little bit then? [17:44:37 CET] <JEEB> yes, anything but lossless compression has some sort of loss [17:44:54 CET] <ftg> because it is from a go Pro and file is heavy [17:44:57 CET] <JEEB> and lossy (which your source most likely is) to lossless is lolhueg [17:45:13 CET] <furq> if you're going to convert it then you might as well keep it as h264 [17:45:15 CET] <JEEB> (plus nothing supports lossless AVC other than lavc and a few other decoders) [17:45:24 CET] <furq> the only reason not to do that is if you're concerned about licensing [17:45:32 CET] <JEEB> yes, libx264 with CRF+maxrate|bufsize is your go-to choice [17:45:55 CET] <JEEB> encode like 2500 frames starting with -crf 23, and going lower if it looks bad, or going higher if it looks good [17:45:56 CET] <furq> i guess vp9 will potentially yield a smaller file at the same quality but it'll also take ten times longer [17:46:10 CET] <JEEB> (-vframes 2500 for the 2500 frames) [17:46:27 CET] <JEEB> then you have found the highest CRF that still looks good for you after a few tries [17:46:31 CET] <furq> consider downscaling to 720p as well [17:46:37 CET] <JEEB> and you can use that value for the rest of the similar clips [17:47:02 CET] <JEEB> and then set maxrate+bufsize according to the minimum requirements you have regarding someone watching without additional buffering [17:47:26 CET] <JEEB> (it will control the bit rate so that it limits bit rate to maximum of MAXRATE over BUFSIZE) [17:53:33 CET] <ftg> JEEB: thx for the info! apart of this, I am also looking for a python lib that could extract a thumbnail image from this video, do you have a tool in mind? [17:53:56 CET] <nadermx> hey all, I'm trying to convert a mp4 to mp3 in one command run with a thumbnail, I posted on SO http://superuser.com/questions/1182824/convert-mp4-to-mp3-with-thumbnail [17:54:13 CET] <nadermx> the command I tried that works for a flv to mp3 doesn't work with mp4 to mp3 [18:22:20 CET] <forgon> I'd like to convert '.mkv' made of lossless libx264 and lossless flac to '.webm' so that I could upload to YouTube. [18:22:40 CET] <JEEB> uhh, lossless AVC should work just fine o_O [18:22:43 CET] <JEEB> other than for the file size [18:22:47 CET] <forgon> I know both formats are fairly similar, so how much quality do I have to lose? [18:23:02 CET] <JEEB> and you definitely don't want to use libvpx if you want good price performance lossy encoding [18:23:59 CET] <dl2s4> doesnt encode youtube your uploads anyway? [18:24:45 CET] <BtbN> which is why you upload lossless there [18:24:58 CET] <BtbN> and mkv with h264 and flac should be fine to upload to YT [18:26:46 CET] <dl2s4> yeah [18:27:31 CET] <forgon> I'll try when my video is finished. [18:27:33 CET] <JEEB> yup, which is why the only issue with it is the file size - in which case you either go to a place that has better interwebs or have to recompress and make your upload less nice in order to upload it better [18:27:51 CET] <forgon> But I read that this is not possible to have flac and webm. [18:28:04 CET] <forgon> And that YouTube will never support mkv. [18:28:23 CET] <realies> av1 is the way to go [18:29:12 CET] <JEEB> forgon: it takes that shit in just fine, it will re-encode whatever you push into it [18:29:19 CET] <JEEB> it has a FFmpeg from circa 2011 or so [18:29:20 CET] <JEEB> inside [18:29:41 CET] <JEEB> so whatever that old FFmpeg can read it most likely can upload just fine [18:29:46 CET] <JEEB> realies: not finished yet [18:30:10 CET] <realies> JEEB, should be by the end of next month, no? [18:30:20 CET] <JEEB> I would... be surprised :D [18:30:37 CET] <JEEB> I remember at FOSDEM atomnuker was saying after the end of 2017 or so for bit stream freeze [18:30:51 CET] <realies> wait, what [18:30:52 CET] <JEEB> or at least his slides had something to that effect [18:31:03 CET] <JEEB> https://fosdem.org/2017/schedule/event/om_av1/attachments/slides/1795/expor… [18:31:32 CET] <JEEB> see the "After codec bitstream gets frozen experiments that didn't make it get removed" [18:31:40 CET] <JEEB> ** - Won't happen until the end of the year [18:32:02 CET] <forgon> What is the fastest way to cut my file cleanly into several parts at specific points? [18:32:02 CET] <JEEB> which I read as the bit stream not being frozen until the end of the year [18:32:25 CET] <JEEB> forgon: -ss and -t with -c copy [18:33:10 CET] <realies> JEEB, thanks for the info, I was relying on information from this https://youtu.be/lzPaldsmJbk that stated a bitstream freeze by the end of nov 2016 [18:33:39 CET] <forgon> JEEB: So, that would allow me to get one interval and write it to a file, correct? [18:33:45 CET] <JEEB> yes [18:33:57 CET] <forgon> And I do that several times to get several parts, correct? [18:34:40 CET] <JEEB> yes [18:35:48 CET] <forgon> Another question: Can I extract a single shot as a png image out of a video with ffmpeg? [18:35:58 CET] <JEEB> yes [18:36:20 CET] <forgon> How? [18:37:07 CET] <JEEB> you set output file to something dot png and do vframes 1 for that output? [18:38:18 CET] <forgon> K. [18:41:15 CET] <bencoh> JEEB: do they actually concat that properly? [18:41:25 CET] <bencoh> (results from -ss/-t and -c copy) [18:41:34 CET] <JEEB> that was not mentioned [18:41:37 CET] <JEEB> he just wanted it to be cut [18:41:39 CET] <bencoh> huhu :) [18:41:43 CET] <JEEB> no idea how well the concat shit works [18:41:43 CET] <bencoh> true [18:41:55 CET] <forgon> No need to concat. [18:42:15 CET] <bencoh> forgon: don't you intend to push resulting files to youtube? [18:42:28 CET] <forgon> I have a 66 Warzone2100 video and neeed to cut it into 5 parts for YouTube which has a 15 minute limit. [18:42:36 CET] <bencoh> oh, okay [18:42:36 CET] <forgon> ^66^66m [18:42:39 CET] <bencoh> nevermind then [19:14:11 CET] <forgon> Can I stop ffmpeg in som eway and continue after a reboot? [19:14:46 CET] <BtbN> no [19:15:27 CET] <jkqxz> Not built in. Run inside a VM and make a snapshot. [19:24:40 CET] <realies> can u do it without a vm snapshot? [19:25:00 CET] <realies> a generic way of snapshotting a process' ram usage [19:25:10 CET] <realies> is that not a thing [19:27:18 CET] <bencoh> actually it is, somehow [19:28:30 CET] <bencoh> thè question is how would you handle io (reopen fds?) [19:30:21 CET] <realies> that should be a function of that tool i guess [20:16:13 CET] <Sweepyoface> Hey, I'm using the palettegen and filter_complex method to convert an mp4 into a gif, but it's turning 3.3MB into 22.7MB [20:16:29 CET] <Sweepyoface> Is there a way to get this down without losing quality? It has to be <10MB [20:16:55 CET] <JEEB> you thought gif would be well compressed? too bad, E_NOT_GOING_TO_HAPPEN (although there are some options in the encoder to optimize the palette etc) [20:17:52 CET] <Sweepyoface> It seems to be able to convert >300MB avi/mov to a ~1MB gif [20:18:04 CET] <Sweepyoface> but I can't go straight from AE unless I find a way to crop without also losing quality [20:18:28 CET] <Sweepyoface> because the effect I used breaks when changing composition size [20:21:12 CET] <Sweepyoface> I just converted a 1.2GB avi to a 3MB gif using the same method [20:21:23 CET] <Sweepyoface> but if the input is only 3MB it gets inflated to 22MB [20:21:49 CET] <Sweepyoface> because I had to run it through camtasia to crop it [20:22:51 CET] <Sweepyoface> Maybe I can just convert first and then crop the gif [20:24:22 CET] <durandal_1707> whatever you are doing, you are doing it wrong [20:25:25 CET] <Sweepyoface> I need to convert a 1920x1080 AE animation (because changing the size in AE breaks it) to a 506x811 <10MB gif [20:26:36 CET] <Sweepyoface> When I convert to a 1920x1080 gif it works fine [20:26:39 CET] <Sweepyoface> but it has to be cropped [20:26:51 CET] <voxadam> Is it possible to convert an encrypted/DRMed ISMA file to a non-encrypted/non-DRMed file of some type using ffmpeg (or any other tool)? [20:27:34 CET] <voxadam> According to media info the file is an encrypted MPEG-4 PIFF with AAC audio. [20:28:57 CET] <BtbN> ffmpeg does not support DRM [20:32:31 CET] <voxadam> It supports encrypted files, right? [20:32:39 CET] <voxadam> http://ffmpeg.org/ffmpeg-all.html#Audible-AAX [20:33:01 CET] <DHE> sort of. I know HLS supports encryption but it lacks any means of doing a "secure handshake" or whatever is required to get the protected key. [20:33:16 CET] <BtbN> hls supports decryption with a static AES key iirc [20:33:19 CET] <BtbN> which seems super pointless [20:33:36 CET] <voxadam> I have the "activation bytes [20:33:45 CET] <voxadam> I have the "activation bytes" which I assume is a key. [20:33:58 CET] <DHE> then you should be able to specify it as per the example [20:34:47 CET] <voxadam> My problem seems to be related to the fact that the file I'm trying to convert isn't AAX but rather IMSA. [20:34:57 CET] <DHE> BtbN: HLS keys are specified by a URL which has a 16 byte (128 bit AES) payload. but any good implementation will require something like cookies, HTTP authentication, or something else in order to get the key [20:35:17 CET] <BtbN> But what's the point of that? Can just put the stream itself behind auth. [20:35:23 CET] <DHE> voxadam: they're part of a family of containers. give it a try. [20:35:43 CET] <DHE> BtbN: CDNs can carry the video payload, and a single secure point can hand out the keys [20:35:50 CET] <BtbN> hm, yeah [20:36:11 CET] <BtbN> does not really protect against re-distributions in terms of DRM [20:36:35 CET] <DHE> well that's DRM for you [20:36:45 CET] <__jack__> HLS security is pretty .. secure [20:38:51 CET] <__jack__> it's also vague on how to secure your stream [20:39:22 CET] <__jack__> let's take verimatrix, for instance : to fetch the AES key, you need to GET an https url (which is written on the playlist) [20:39:34 CET] <__jack__> the https server does client-side authentification via TLS [20:39:58 CET] <__jack__> which means only a trusted client (which have a signed certificate) can get the key and play the movie [20:40:10 CET] <voxadam> This is what I get when I try to convert the IMSA file: https://paste.fedoraproject.org/paste/Rvrxv3NLm8zNa7MeC5I-ql5M1UNdIGYhyRLiv… [20:40:11 CET] <DHE> so TLS client certs as authentication [20:40:29 CET] <__jack__> yes [20:43:14 CET] <voxadam> If I specify output.aac I only receive a single error "[aac @ 0x4cdd740] channel element 2.15 is not allocated" but the result doesn't play in vlc or ffplay. [21:06:14 CET] <Darby_> hi guys i have solved many issue for compile a ffmpeg static build [21:06:34 CET] <Darby_> i have a issue with libssh [21:06:35 CET] <Sweepyoface> Anyone able to help me with this? [21:08:54 CET] <Darby_> https://clbin.com/4BOjM [21:32:31 CET] <BtbN> Darby_, static libs have no idea of dependencies. And it seems like libssh does not correctly specify all of its deps in the pkg-config file. [21:32:41 CET] <BtbN> this looks like it needs to link against openssl [21:37:25 CET] <Darby_> hi BtbN [21:37:42 CET] <Darby_> have you a solution? [21:37:51 CET] <BtbN> link against openssl yourself [21:38:08 CET] <BtbN> Or just enable it, ffmpeg can use it itself, and that should workaround the issue with libssh [21:38:25 CET] <Darby_> can you make me a example, please? [21:38:46 CET] <BtbN> --enable-openssl [21:39:34 CET] <Darby_> i have --enable-openssl [21:39:52 CET] <Darby_> my issue is with libssh [21:40:05 CET] <BtbN> no, your issue is with libssh not finding openssl functions. [21:41:58 CET] <Darby_> BtbN, take a look please [21:42:00 CET] <Darby_> https://clbin.com/vN3lX [21:42:29 CET] <BtbN> I'm not going to fix your script for you. [21:42:36 CET] <Darby_> no man [21:42:57 CET] <Darby_> i don't want it [21:43:01 CET] <BtbN> make sure pkg-config is working, and that should sort most things [21:43:44 CET] <Darby_> i'm tryng to compile a ffmpeg full static binary [21:44:08 CET] <Darby_> debian libssh-dev don't have static .a files [21:45:04 CET] <Darby_> i'm compiling libssh in my custom dirs for incluede static library to ffmpeg binary [21:48:01 CET] <Darby_> BtbN, how can i link openssl function to openssl? [21:48:11 CET] <Darby_> *libssh [21:51:43 CET] <BtbN> you can't. Static libs don't support dependencies. [21:51:49 CET] <BtbN> That's why pkg-config helps [21:52:28 CET] <Darby_> i can't compile with static libssh? [21:53:56 CET] <BtbN> you have to pass all dependencies to the linker as well [21:54:03 CET] <BtbN> Or use pkg-config... [21:54:24 CET] <Darby_> how can i do this? [21:54:33 CET] <Darby_> i'm not a expert [22:00:04 CET] <Darby_> BtbN, please give me a little help [22:04:22 CET] <DHE> do you have a static lib for openssl? you need libcrypto.a and libssl.a [22:04:44 CET] <DHE> or possibly just libcrypto, I'm not sure of the specifics. [22:06:39 CET] <Darby_> thanks DHE i can compile it [22:14:47 CET] <Allaen5> Hi, I am trying to write chapter markers to an audio stream via -map_metadata, ouput file is a .m4a file. I can get it to work when I am using an existing input file but not when I am reading a stream from the pipeline e.g. BinaryWriter | -f s16le -ar 22050 -ac 2 -i pipe:0 -i "<path>\metadata.txt" -map_metadata 1 -id3v2_version 3 -write_id3v1 1 -y -b:a 64004 -metadata album="<album>" "<Output-File-Name-With-Full-Path.m4a" [22:46:46 CET] <Darby_> DHE thanks i have compiled libssl and now i have libssl.a and libcrypto.a in my custom build directory [00:00:00 CET] --- Mon Feb 27 2017

1 0

ffmpeg-devel.log.20170225
by burek 26 Feb '17

26 Feb '17

[03:54:11 CET] <cone-413> ffmpeg 03Michael Niedermayer 07master:310d2af319d9: avcodec/pngdec: Fix runtime error: left shift of 152 by 24 places cannot be represented in type 'int' [03:54:11 CET] <cone-413> ffmpeg 03Michael Niedermayer 07master:6bd79ba59f46: avcodec/amrwbdec: Fix 2 runtime errors: left shift of negative value -1 [04:02:26 CET] <cone-413> ffmpeg 03Steven Liu 07master:f73ef3748e83: avformat/hlsenc: fix hls_flags temp_file bug [04:28:40 CET] <cone-413> ffmpeg 03Hendrik Leppkes 07master:3aef2fceff32: avformat/hlsenc: don't use %s for strftime on msvc [11:51:03 CET] <nevcairiel> michaelni: 513a34943 broke fate on a variety of boxes, it would appear there is some other issue hidden there, ie. http://fate.ffmpeg.org/report.cgi?time=20170225072151&slot=x86_32-mingw-w64… [11:52:07 CET] <nevcairiel> in fact, basically every box that ran in the last couple hours is yellow now [11:54:45 CET] <michaelni> nevcairiel, odd, i did test this one on several things [11:55:17 CET] <nevcairiel> a quick check seems to show they all produce the same crc [12:06:27 CET] <michaelni> valgrind shows nothing [12:06:46 CET] <nevcairiel> and you still get the same crc? [12:07:01 CET] <nevcairiel> thats odd [12:10:40 CET] <michaelni> i can reproduce it with --enable-memory-poisoning [12:12:08 CET] <nevcairiel> weird that valgrind didnt show it then [12:12:36 CET] <michaelni> yes [13:01:34 CET] Action: ubitux just realized his fate instances were stalled one month ago [13:01:41 CET] <ubitux> they're all turning yellow now [13:10:32 CET] <cone-046> ffmpeg 03Michael Niedermayer 07master:d34bf886e963: avcodec/vp56: Implement very basic error concealment [15:06:42 CET] <kierank> wm4: so now I am confused about the rules, michaelni does not maintain vp5 or vp6 yet has pushed without review as far as I can tell [15:09:22 CET] <wm4> kierank: this seems to be a rule violation [15:09:29 CET] <wm4> michaelni: what do we do to enforce the rules? [15:15:42 CET] <wm4> kierank: yeah, it wasn't even on the ML [15:15:46 CET] <wm4> unless I'm missing some posts [15:16:25 CET] <wm4> the maintainer for vp5 and vp6 is "Aurelien Jacobs" [15:16:41 CET] <wm4> I assume that makes him maintainer of vp56.c [15:17:28 CET] <wm4> which I interpret as either "the rules don't mean shit" or "the MAINTAINERS file doesn't mean shit" [15:17:36 CET] <wm4> that's not really a good situation [15:17:38 CET] <Compn> aurel hasnt been around in a while [15:17:47 CET] <Compn> where a while = years [15:17:51 CET] <wm4> Compn: that affects most people list in MAINTAINERS [15:18:03 CET] <Compn> the maintainers list is more for historical purposes [15:18:09 CET] <Compn> in my opinion [15:18:26 CET] <wm4> well according to the "rules", it affects whether or not you can push stuff without reviews [15:18:44 CET] <wm4> and michaelni is "maintainer" of significant parts of the common code/headers [15:18:55 CET] <Compn> right, but whats the rule when the maintainer is gone ? [15:20:09 CET] <wm4> how do you even know whether the maintainer is "gone" [15:20:17 CET] <wm4> many of them are still reachable by mail [15:20:32 CET] <Compn> also, this is the kind of stuff that makes it not fun to work on the project for me. e.g. complaining about maintainers file, rules, review, patches, etc yet again. just letting you know my interest in the subject. [15:21:07 CET] <Compn> review it after its committed, theres not much difference honestly [15:21:20 CET] <Compn> before commit or after commit, the code is still code [15:22:05 CET] <wm4> yeah, I'd prefer pushing my code without reviews too [15:22:10 CET] <wm4> but I'm trying to follow the rules [15:22:15 CET] <wm4> should that make me an idiot [15:22:29 CET] <Compn> just ask michaelni again to post patches and move on [15:22:43 CET] <wm4> it's _completely_ unclear how to behave is the maintainer is obviously not active anymore, or not very active [15:22:53 CET] <Compn> so propose a rule [15:25:21 CET] <wm4> Compn: or in other words, if michaelni ignores the rules, why should I respect them [15:29:24 CET] <Compn> Do NOT commit to code actively maintained by others without permission [15:29:34 CET] <Compn> since vp56 isnt actively maintained, i dont see a rule violation [15:29:37 CET] <Compn> http://ffmpeg.org/developer.html#Development-Policy [15:30:35 CET] <Compn> wm4 : maybe you've been reading some other ruleset ? [15:31:00 CET] <Compn> in some other project [15:31:05 CET] <Compn> maybe a fork [15:33:49 CET] <wm4> so I have to guess whether it's "actively" maintained? also that would make it unmaintained code, not code maintained by michaelni - can you push changes to "unmaintained" code without reviews then? [15:33:57 CET] <wm4> and without even sending it to the ML [15:33:57 CET] <Compn> just look at git blame for vp56.c [15:33:58 CET] <Compn> 2012 [15:34:05 CET] <wm4> what does that matter [15:34:10 CET] <iive> wm4: is there some problem with the committed code? [15:34:21 CET] <wm4> iive: who knows? [15:34:36 CET] <Compn> wm4 : you are trying to apply a rule that is not ffmpeg policy to ffmpeg developers, it is infuriating [15:34:44 CET] <iive> wm4: you are making it a problem, that's why I am asking you [15:34:54 CET] <iive> is there any problem with this code [15:34:58 CET] <Compn> wm4 : propose a new rule , or stop applying rules that dont exist to ffmpeg developers [15:35:49 CET] <Compn> and yes, since there is no rule about pushing changes to unmaintained code... i say go for it [15:36:07 CET] <Compn> if anyone complains, point to maintainers and say 'that file wasnt under anyones maintainership' [15:36:10 CET] <JEEB> it's a valid point that there is no defined rule for "something is maintained", and thus you have to ballpark if the last change by that person was far back enough in the past [15:36:12 CET] <wm4> <Compn> wm4 : you are trying to apply a rule that is not ffmpeg policy to ffmpeg developers, it is infuriating <- uh what [15:36:21 CET] <wm4> I'm trying to fucking figure out what the rules are [15:36:25 CET] <JEEB> ^ this [15:36:27 CET] <wm4> because nobody fucking knows [15:36:33 CET] <Compn> [09:09] <wm4> kierank: this seems to be a rule violation [15:36:40 CET] <wm4> so far it looks like michaelni is doing whatever he pleases [15:36:44 CET] <Compn> ^^^ no, you made a claim it broke a rule [15:36:50 CET] <Compn> but there is no rule [15:36:55 CET] <Compn> you are arguing in bad faith, my friend [15:37:03 CET] <Compn> and it is shitty. [15:37:06 CET] <wm4> Compn: well how the fucking fuck does it work then [15:37:10 CET] <wm4> 1. the patch wasn't on the ML [15:37:16 CET] <Compn> who says it has to be on the ML ? [15:37:17 CET] <wm4> 2. it as pushed without a review [15:37:24 CET] <Compn> who said patches have to be reviewed ? [15:37:31 CET] <wm4> 3. the maintainer is not michaelni, but someone else [15:37:34 CET] <JEEB> please, let him finish [15:37:46 CET] <wm4> 4. the rules say code maintained by someone else has to be reviewed [15:38:00 CET] <Compn> "actively maintained" [15:38:12 CET] <wm4> 5. there's a timeout where you can push patches anyway if the maintainer doesn't react, but it's significantly over 0 [15:39:15 CET] <Compn> aurel is gone, afaict, so file is unmaintained , or at least, not actively maintained for years [15:39:16 CET] <wm4> Do NOT commit to code actively maintained by others without permission. [15:39:16 CET] <wm4> Send a patch to ffmpeg-devel. If no one answers within a reasonable [15:39:16 CET] <wm4> time-frame (12h for build failures and security fixes, 3 days small changes, [15:39:16 CET] <wm4> 1 week for big patches) then commit your patch if you think it is OK. [15:39:33 CET] <wm4> is he gone? I could reach him by mail a few months ago [15:39:49 CET] <Compn> i meant from ffmpeg, not gone from the internet or planet earth [15:39:55 CET] <Compn> heh [15:40:03 CET] <wm4> so why is he maintainer if he left? [15:40:29 CET] <Compn> he was maintainer at the time when his name was added to maintainers file :) [15:40:47 CET] <wm4> and why does this not warrant a review on the ML? we even post patches to the ML for code we maintain [15:40:55 CET] <wm4> that's bullshit [15:41:05 CET] <Compn> then dont post patches for code you maintain [15:41:11 CET] <JEEB> jesus christ [15:41:11 CET] <Compn> if you prefer not to [15:41:32 CET] <Compn> its not a policy rule [15:41:36 CET] <JEEB> the thing is, it would have been nice to get a patch and notice that the maintainer should be removed [15:41:46 CET] <JEEB> that way it would have been clear that there is no maintainer [15:41:52 CET] <iive> wm4: there is one rule. always act in good faith. [15:42:07 CET] <JEEB> although to be honest, I'd still prefer patches on ML pretty much always [15:42:15 CET] <Compn> then post patches if you prefer. [15:42:16 CET] <JEEB> the timeouts in some cases seem OK enough [15:42:48 CET] <iive> wm4: you are just trying to stir up shit and create controvercy. [15:43:06 CET] <iive> wm4: if you have problem with michael, ask him directly and in private [15:43:11 CET] <JEEB> I'm pretty sure he is just trying to point out that parts of the rules are currently "ballpark it" [15:43:12 CET] <iive> do not make it public issue [15:43:45 CET] <JEEB> and while the MAINTAINERS file seems to have some sort of weight to it, there is no effort in such cases to clean it up [15:44:15 CET] <Compn> JEEB : no, he said a rule was violated when no rule was violated. if he wants to propose a rule, he can post to ffmpeg-devel with a new rule proposal [15:44:31 CET] <wm4> all I get from this is "the rules don't mean shit" [15:44:31 CET] <Compn> stop trying to control the facts, JEEB [15:44:34 CET] <JEEB> Compn: it is not clear though, since the maintainer is still listed there [15:44:41 CET] <Compn> "actively maintained" [15:44:48 CET] <Compn> what part of "actively" do you not understand ? [15:44:52 CET] <wm4> iive: no, rules are there because they are SUPPOSED to resolve conflict [15:45:01 CET] <wm4> iive: if they can't do that they're not good rules [15:45:04 CET] <iive> wm4: and what is the conflict in this case? [15:45:13 CET] <jkqxz> iive: Compn: You are trying to sweep aside these concerns by noting that it is mostly irrelevant /in this specific case/. [15:45:17 CET] <iive> IS THERE A PROBLEM WITH THE CODE\ [15:45:19 CET] <wm4> or alternatively they don't mean anything (can ignore maintainers...) [15:45:31 CET] <Compn> jkqxz : which concerns? that wm4 wants to propose a new rule or clarification of a rule? [15:45:31 CET] <nevcairiel> jkqxz: he is not expressing general concerns, he is riding one specific case [15:45:32 CET] <jkqxz> The specific case is not important, the general rule is. [15:45:37 CET] <wm4> iive: it's not about code, it's about project development rules [15:45:46 CET] <Compn> jkqxz : i specifically am not sweeping anything aside, and am encouraging wm4 to propose a new rule [15:45:53 CET] <Compn> jkqxz : it insults me that you would say this. [15:46:07 CET] <iive> wm4: you just said that they exist to resolve conflict [15:46:11 CET] <JEEB> Compn: so if there's no bugs in the code for X months and I am not actively poking other components is that "actively maintaining" [15:46:15 CET] <iive> but you are creating conflict, by using them. [15:46:16 CET] <JEEB> (bugs that I know of) [15:46:44 CET] <Compn> JEEB : i am not dealing with hypothetical questions at the moment in time , sorry [15:46:47 CET] <JEEB> ok [15:46:49 CET] <JEEB> no problem [15:46:49 CET] <wm4> iive: there has been conflicts all along because of unclear/ignored rules [15:47:37 CET] <Compn> wm4 : so propose a clarification of a rule [15:48:04 CET] <iive> wm4: Do you want to destroy FFmpeg? Because this is the exactly same shit that broke FFmpeg apart [15:49:10 CET] <iive> do you want michaelni to be kicked out of FFmpeg? [15:49:12 CET] <wm4> iive: maybe the rules are not very good or not followed very well which _caused_ it to break apart already at least once? [15:49:19 CET] <nevcairiel> If you want clearer rules, then propose those, without starting the discussion through attacks on developers actions [15:49:27 CET] <Compn> nevcairiel speaks the truth [15:49:37 CET] <kierank> the rules are clear [15:49:37 CET] <wm4> nevcairiel: which attack [15:49:51 CET] <kierank> it's just "maintainers" is rooted in fantasy [15:49:53 CET] <wm4> I only pointed out that michaelni disrespected Aurlien as maintainer [15:50:01 CET] <JEEB> ok, something along the road of "if a component is considered not maintained a patch should be sent out to remove <whatever signifies that person as being a maintainer>", if we have noted something as being the sign of being a maintainer. in some cases people have pointed at the MAINTAINERS file, which is well-known to be not maintaned very well, and in some other cases other things have been pointed [15:50:07 CET] <JEEB> at. [15:50:25 CET] <iive> wm4: if Aurlien has objected on that, I would have supported him. [15:50:32 CET] <nevcairiel> wm4: and anyone with half a brain can see that he is not active anymore, so since I know you have one of those, you choose to ignore that, and thus acted in bad faith [15:50:39 CET] <iive> what do YOU have to do with it? [15:51:14 CET] <iive> rules are not laws [15:51:26 CET] <JEEB> anyways, effectively the ballparking in this case was correct, but it's unfortunate that the patch didn't go through the usual workflow [15:51:38 CET] <JEEB> and that's it [15:51:50 CET] <wm4> nevcairiel: then why the fuck is he in the maintainers file? [15:51:56 CET] <wm4> how can I determine whether someone is active? [15:52:20 CET] <iive> wm4: rules are there to protect you [15:52:33 CET] <Compn> git log file.c ... >5 years no commits = unmaintained [15:52:45 CET] <Compn> git log file.c ... >5 years no commits from maintainer = unmaintained [15:52:49 CET] <nevcairiel> because people don't tell you when they become inactive, they just go away, its just human nature [15:52:55 CET] <JEEB> yes [15:53:06 CET] <JEEB> which is why such files can be rather out-of-date [15:53:39 CET] <Compn> sometimes people do come back as well :) [15:53:48 CET] <Compn> rarely [15:53:50 CET] <JEEB> of course [15:54:13 CET] <iive> wm4: do you understand what "acting in good faith" means? [15:59:56 CET] <wm4> sent a patch [16:03:58 CET] <wm4> "Send a patch to ffmpeg-devel. If no one answers within a reasonable [16:03:58 CET] <wm4> time-frame (12h for build failures and security fixes, 3 days small changes, [16:03:58 CET] <wm4> 1 week for big patches) then commit your patch if you think it is OK. [16:03:58 CET] <wm4> " [16:04:02 CET] <wm4> is that the entire rule? [16:04:14 CET] <wm4> e.g. 3 days of silence -> I can just push? [16:05:54 CET] <iive> yes [16:06:38 CET] <iive> it is good to ping the maintainer of the file, so he could review it sooner. [16:08:10 CET] <wm4> so if you post a patch to the ML, and someone requests changes, but is not the maintainer, can I ignore those? [16:09:04 CET] <nevcairiel> the entire r ules are designed around a concept of good faith, if you ask such things maybe we should design new rules that assume malice in every contributor [16:09:41 CET] <wm4> again, rules are there to resolve conflicts... or else you could just make them "Act in good faith." [16:09:57 CET] <wm4> I've seen review comments being ignored myself [16:11:40 CET] <iive> well, it depends on the request and the consensus. [16:11:53 CET] <wm4> this "good faith" thing is unclear as hell, because it expects you to fill the gaps in the rules yourself, which obviously doesn't work (kierank and I were assuming michaelni violated that good faith when he just pushed that vp56.c patch without even putting it on the ML) [16:12:23 CET] <kierank> this is why the "Be excellent to each other" is nonsense [16:12:30 CET] <kierank> open to interpretation [16:12:37 CET] <nevcairiel> actually thats the wrong way around wm4, you assuming that is the bad faith =p [16:12:41 CET] <durandal_1707> who cares about vp56? [16:12:59 CET] <iive> nevcairiel: +1 [16:13:25 CET] <Compn> durandal_1707 : people who never admit that they were mistaken [16:13:29 CET] <wm4> nevcairiel: uh no [16:13:42 CET] <wm4> nevcairiel: I was assuming rules that I would have considered to be part of "good faith" [16:13:51 CET] <wm4> nevcairiel: and _then_ I assumed michaelni acted in bad faith [16:14:12 CET] <nevcairiel> you seem to not understand the concept of good faith [16:14:12 CET] <durandal_1707> i pushed same thing to dnxhd. even without review months ago [16:14:16 CET] <wm4> or does "good faith" mean we love us all and no rule gets ever violated [16:14:19 CET] <iive> nevcairiel: +2 [16:15:10 CET] <wm4> nevcairiel: I couldn't see any good faith in a rule being (apparently) violated [16:15:20 CET] <wm4> only after this discussion it's becoming clear he didn't actually violate any rules [16:15:28 CET] <nevcairiel> thats because your first assumption is a rule violation [16:15:36 CET] <wm4> <wm4> nevcairiel: I was assuming rules that I would have considered to be part of "good faith" [16:15:36 CET] <wm4> <wm4> nevcairiel: and _then_ I assumed michaelni acted in bad faith [16:15:36 CET] <nevcairiel> your entire mindset is based on bad faith, apparently [16:15:43 CET] <kierank> what rules were not broken? [16:15:50 CET] <nevcairiel> none were broken [16:15:51 CET] <wm4> nevcairiel: it's bad faith from you assuming that [16:15:57 CET] <nevcairiel> you just assume rules that dont actually exist [16:16:08 CET] <kierank> "Send a patch to ffmpeg-devel." [16:16:21 CET] <Compn> if the file is actively maintained by someone else... [16:16:23 CET] <wm4> nevcairiel: jesus christ [16:16:37 CET] <iive> Compn: you are not helping ;) [16:16:46 CET] <Compn> iive : i could say the same to you :) [16:17:41 CET] <durandal_1707> nobody reviews patches because of evil blood [16:18:05 CET] <Compn> durandal_1707 : you committed things without review? have you no shame!? [16:18:10 CET] <Compn> ehe [16:19:05 CET] <durandal_1707> but patch is 100% correct [16:19:51 CET] <Compn> i cant believe anyone uses our software , people committing things without review. so unprofessional :) [16:20:23 CET] <Compn> ok enough trolling [16:20:27 CET] <Compn> from me, bye [16:20:56 CET] <wm4> what's I'm more surprised about is that iive disagrees with the patch [16:21:52 CET] <iive> wm4: michael did wrong. He gets carried sometimes, it's not trival or security change. [16:22:18 CET] <iive> wm4: however going against him in public is bad faith from you. [16:22:21 CET] <wm4> well, non-trivial changes to unmaintained files don't require reviews, where do you see this? [16:22:30 CET] <iive> aka, you brand him criminal and try to punish him. [16:22:47 CET] <iive> and create huge fuss. [16:23:29 CET] <iive> wm4: that's why I said to Compn that he is not helping, I do not agree with Compn viewpoint. [16:23:34 CET] <iive> let it say it this way. [16:24:21 CET] <iive> I do not think that Aurelien would object on this commit. [16:24:47 CET] <wm4> whether he would or would not doesn't really matter [16:24:56 CET] <iive> yes, it does. [16:25:06 CET] <iive> the rules are there to protect you. [16:25:19 CET] <wm4> iive: I guess I apologize for doing that and misinterpreting the rules, but I'm not taking back my claim that the rules are shitty and useless [16:25:20 CET] <durandal_1707> iive: how do you know? [16:25:24 CET] <iive> if you follow the rules, you are protected from critizm. [16:25:41 CET] <wm4> that's what I said earlier, rules are there to resolve conflicts [16:25:51 CET] <wm4> as long as there's no conflict, you don't need rules either [16:25:58 CET] <iive> no, conflicts are not RESOLVED by rules. [16:26:28 CET] <iive> and i asked you, what is the conflict here? [16:26:29 CET] <wm4> ok, prevented [16:26:50 CET] <wm4> as I said before, it has long been unclear what exactly are the rules [16:26:56 CET] <iive> if the change is somehow broken, the michael is in hot water [16:27:12 CET] <iive> because the rules would have protect him. [16:27:51 CET] <iive> if he had followed him, he could say.. I sent patch, nobody found a problem in it. I didn't see it either. I tried my best. [16:28:28 CET] <iive> him/them (rules) [16:29:31 CET] <iive> some of us , the old developers, do trust michael to commit correct code, so we are not that outraged when he commits something directly [16:30:06 CET] <wm4> I don't really trust him that [16:30:23 CET] <wm4> I saw too many weird things which go back to his commits [16:30:25 CET] <iive> bingo! [16:30:30 CET] <wm4> that doesn't mean I think michaelni is a bad developer [16:30:53 CET] <wm4> just that it might be good to have additional eyes on his patches if the patches deal with messy cases [16:31:17 CET] <wm4> where "messy cases" means code or scenarios which are extra tricky [16:34:44 CET] <wm4> I also acknowledge that Libav sometimes commits outright broken code (or sometimes code which doesn't even compile), but I still don't think having a minimum of other eyes staring at your changes is a bad thing [16:35:04 CET] <wm4> (context: Libav has a policy to always review changes, even trivial ones) [16:35:08 CET] <Compn> forced review does slow down development [16:35:21 CET] <nevcairiel> libav reviews are sometimes quite ridicoulous when some persons just put a "maybe ok" under it and thats all it needs =p [16:35:21 CET] <iive> they don't follow it that strictly, either. [16:35:40 CET] <wm4> nevcairiel: yeah, I don't think that should be needed [16:36:10 CET] <iive> yeh, or "requested changes done locally and pushed". [16:37:10 CET] <wm4> something closer to the linux kernel development model might probably be good for a large project like ffmpeg [16:37:25 CET] <wm4> _no_ code gets into the main tree without getting reviewed, but it still works pretty well [16:38:13 CET] <BtbN> Something like gerrit. But good luck getting people to that. [16:40:50 CET] <wm4> I wonder if BBB has an opinion about this [16:43:37 CET] <jkqxz> I think it would be reasonable to say that all patches, however trivial, should be posted to the ML (or an ML, if ffmpeg-security is maybe more suitable for them, I don't know about that). [16:44:16 CET] <BBB> ? [16:44:17 CET] <jkqxz> Then the rules around pushing without review always apply directly. [16:44:34 CET] <BBB> whats the problem? [16:45:51 CET] <Compn> BBB : some devs want everything posted as patches to ml, and also possibly all patches reviewed before commit (basically libav rules) [16:45:59 CET] <wm4> BBB: it's apparently allowed to push patches to "unmaintained" code without posting them to the ML, which... surprises me [16:46:19 CET] <wm4> and I accused michaelni of a rule violation at first [16:48:27 CET] <durandal_1707> i have patch which needs review [16:53:17 CET] <wm4> durandal_1707: if nobody reviews it then you can really post it [16:53:48 CET] <Compn> i think maybe durandal_1707 is asking wm4 to review said patch [16:54:00 CET] <Compn> durandal_1707 : what is the mail patch subj or ml url ? [16:55:32 CET] <durandal_1707> it is about aeval filter [16:55:51 CET] <BBB> my understanding is that all patches are posted to the ML [16:56:00 CET] <BBB> I distinctly remember having a discussion about that with michaelni [16:56:10 CET] <BBB> I can look that up but I really dont feel like diggin in this old crap [16:56:48 CET] <BBB> I also recognize that most old code is fundamentally unmaintained so usually these patches go in without actual review (even though a patch was posted) after the patch lingers on ML for 1-2 days [16:57:25 CET] <BBB> this isnt any different from modern codecs btw [16:57:31 CET] <BBB> if I post a vp9 patch, its hard to get review [16:57:36 CET] <BBB> its generally hard to get review :) [16:57:53 CET] <BBB> review is unsexy and tricky, but does take considerable time [16:58:22 CET] <BBB> the libav model is not any better than ours, they may have mandatory review but most reviews are sure why not or ok I guess or maybe ok [16:59:14 CET] <BBB> you get a second set of eyes but these eyes really didnt want to be there and all they checked for is that the style is diegoesque and theres no system(format c:) in there, theres no actual checking whether the patch is doing the right thing (remember cinepak patches a few weeks ago?) [17:00:25 CET] <BtbN> There just aren't a lot of people proficient in those areas. [17:00:39 CET] <BtbN> And those who are are usually the author of the patch, or they are busy. [17:00:59 CET] <BBB> right [17:01:19 CET] <BBB> so life is imperfect& Im starting to accept that. [17:01:37 CET] <wm4> I'd propose every patch gets sent to the ML (except trivial typo or build fixes) [17:02:00 CET] <wm4> but then you should be allowed to push a patch after 24h [17:02:10 CET] <wm4> unless it's a big change and the maintainer didn't ack it [17:02:17 CET] <BBB> I dont like the trivial typo/build fixes exception& if its that simple, ask someone on IRC for a quick ack and commit it in 5 seconds [17:02:27 CET] <BBB> I agree the push-after-24h is a good idea [17:02:53 CET] <BBB> but dont pay too much attention to me, I can live with whatever, Im a little less attached to all of this stuff nowadays [17:03:16 CET] <BtbN> until someone sneaks in a complete rewrite of ffmpeg in rust, and nobody notices for 24h. [17:03:41 CET] <BBB> he said unless-big-change [17:03:59 CET] <BBB> which isnt very legal and can thus possibly be abused, but lets just go with it [17:04:07 CET] <Compn> BBB : no one wants to go back to look at 2011 mails... [17:04:10 CET] <BBB> if peolpe have commit rights, we assum we can trust them somewaht, right? [17:04:42 CET] <wm4> except commit rights are given out like candy past the expiration date [17:05:35 CET] <Compn> more committers speeds up development [17:09:47 CET] <TerNer> Hi guys, I have succeed to mux .mp4 video to memory from raw .h264 frames [17:10:24 CET] <TerNer> but I still have no idea how can I streaming it while muxing [17:11:47 CET] <TerNer> afaik, moov should have 'duration of video' information if I have streaming muxed video [17:11:50 CET] <BtbN> you should not use raw h264, where does that come from? [17:12:02 CET] <BtbN> also, you can't stream mp4. As the header gets written at the end. [17:12:14 CET] <JEEB> enable the option to fragment [17:12:20 CET] <JEEB> and you will get movie fragments [17:12:35 CET] <TerNer> BtbN: It comes from raw RGB32 BITMAP data [17:12:48 CET] <JEEB> anyways, this is usage talk so #ffmpeg is more correct [17:12:51 CET] <TerNer> JEEB: Is fragmented mp4 can streaming through http? [17:12:51 CET] <BtbN> but that's not h264 [17:32:27 CET] <durandal_1707> ok, will push without patch review [17:52:18 CET] <durandal_1707> nobody wants to review 2700 lines patch that i gonna commit right now? [17:54:54 CET] <kierank> wm4: where is this rule about "unmaintained" code [17:55:05 CET] <kierank> As far as I can tell the rules are made up here [17:58:12 CET] <iive> durandal_1707: you mean the patch you posted 30 minutes ago? Oh yes, pushing it now would really be an act of good faith, Not. [17:58:46 CET] <JEEB> durandal_1707: so is it your authorship or kostya's? [17:58:57 CET] <JEEB> I didn't notice an author field but that might be Gmail [18:00:01 CET] <durandal_1707> iive: i posted patch that is about aevalsrc [18:00:07 CET] <durandal_1707> long ago [18:02:02 CET] <iive> avfilter/aeval: trim last frame's number of samples to match requested duration (24 feb) ? [18:02:15 CET] <iive> that's yesterday, isn't it? [18:02:41 CET] <BBB> kierank: I sometimes feel that way also [18:08:35 CET] <durandal_1707> iive: yes [18:56:32 CET] <cone-654> ffmpeg 03Carl Eugen Hoyos 07master:353f509ee348: lswr/rematrix: Remove an aggressive loop optimization. [19:54:31 CET] <cone-654> ffmpeg 03Paul B Mahol 07master:dbc7f02a7272: avfilter/aeval: trim last frame's number of samples to match requested duration [20:49:34 CET] <adeel> tired! [21:12:16 CET] <durandal_1707> how writing sec patches can be fun at all? [21:35:57 CET] <durandal_1707> what next video codecs should be added to lavc? [21:36:10 CET] <durandal_1707> i added fmvc and scpr [21:36:19 CET] <durandal_1707> whats next? [21:41:46 CET] <jamrial> durandal_1707: https://trac.ffmpeg.org/ticket/4976 [21:43:07 CET] <durandal_1707> i hate game codecs, they are full of hacks [21:43:36 CET] <durandal_1707> also i need bunch of samples [21:44:03 CET] <durandal_1707> there is myriad bink versions [21:44:28 CET] <durandal_1707> also kostya have patch for some of them [22:17:40 CET] <cone-654> ffmpeg 03Michael Niedermayer 07master:5eb04570f660: avcodec/wavpack: Check post_shift [22:17:41 CET] <cone-654> ffmpeg 03Michael Niedermayer 07master:58f3469cc6df: avcodec/wavpack: Fix 280:22: runtime error: left shift of negative value -1 [22:17:42 CET] <cone-654> ffmpeg 03Michael Niedermayer 07master:5804201cbac2: avutil/frame: Reimplement av_frame_new_side_data() without size=0 special case [22:17:43 CET] <cone-654> ffmpeg 03Michael Niedermayer 07master:7e4f32f4e4b9: avutil/frame: Disallow zero sized frame side data [22:24:57 CET] <RiCON> durandal_1707: the samples in screenpressor's site don't work yet [22:25:45 CET] <durandal_1707> RiCON: those are old samples for old version [22:26:05 CET] <RiCON> oic [22:43:59 CET] <wm4> kierank: well, currently I'm in a state of extreme alcohol intoxication, but apparently that rule was always there [22:44:18 CET] <wm4> seriously fuck alcohol, why is that stuff even legal [22:45:22 CET] <wm4> I don't understand, why do legislators fail so hard [22:45:45 CET] <wm4> that stuff is obviously 100% harmful [22:47:19 CET] <atomnuker> hard alcohol or beer? [22:53:39 CET] <wm4> I think it was a bad combintion of champagne and beet [22:53:43 CET] <wm4> *beert [22:53:46 CET] <wm4> *beer [22:55:34 CET] <JEEB> ah, I know that feeling. except you get shots of salmiakki and vodka together with beer and brandy and whatever [22:55:47 CET] <JEEB> mixing and matching is probably the worst [22:58:50 CET] <atomnuker> "salmiakki (in Finland), is a variety of liquorice flavoured with ammonium chloride" [22:59:47 CET] <atomnuker> if the alcohol doesn't finish you this will [23:01:03 CET] <JEEB> atomnuker: we have nowadays everything from chocolate to ice cream with that [00:00:00 CET] --- Sun Feb 26 2017

1 0

ffmpeg.log.20170225
by burek 26 Feb '17

26 Feb '17

[00:23:50 CET] <thebombzen> is there an equivalent of -crf for libvpx-vp8? [00:39:29 CET] <TD-Linux> thebombzen, yes, -b:v 0 -crf x [00:39:42 CET] <TD-Linux> two pass still recommended though [01:08:53 CET] <thebombzen> TD-Linux: do you mean two-pass ABR or do you mean two-pass -b:v 0 -crf X? [01:09:21 CET] <thebombzen> and how do the CRF scales translate to the corresponding ones for libx264? [01:09:55 CET] <thebombzen> and does libvpx-vp9 do that as well? (in case I have time to kill) [01:11:37 CET] <furq> he means two-pass crf, i don't know, and yes [01:12:00 CET] <furq> iirc something like 30 is reasonable quality [01:12:13 CET] <thebombzen> "resonable" is sort of arbitrary [01:12:23 CET] <thebombzen> to some people, libx264's crf 23 is "reasonable" but I don't like it [01:12:27 CET] <furq> shrug [01:12:31 CET] <furq> try it and see i guess [01:12:37 CET] <thebombzen> lol usual compsci answer [01:12:41 CET] <thebombzen> "what happened when you tried it" [01:12:54 CET] <thebombzen> it's very dissatisfying but I guess knowing where to start (30) is good enough lol [01:13:02 CET] <furq> also i don't know how 2-pass crf could possibly make things better, but apparently it does [01:13:10 CET] <thebombzen> yea that seems weird to me idk [01:13:27 CET] <thebombzen> do I use the usual method, which is on the first pass use -pass 1 -f null - [01:13:32 CET] <thebombzen> and then -pass 2 -f ... [01:13:34 CET] <furq> i know libvpx's ratecontrol is bad but apparently it defies physics as well [01:13:42 CET] <furq> and yeah i think so [01:13:59 CET] <furq> i've avoided libvpx as much as possible because it's uselessly slow for sd [01:14:09 CET] <thebombzen> sd? [01:14:13 CET] <furq> standard def [01:14:25 CET] <thebombzen> doesn't that mean it's even more slow for HD? [01:14:36 CET] <furq> well yeah but not linearly [01:14:42 CET] <thebombzen> ah [01:14:47 CET] <furq> it only has slice threading and there's a minimum slice width [01:14:57 CET] <furq> so at 720 width it'll only use two threads [01:15:07 CET] <furq> which is less than ideal [01:15:09 CET] <thebombzen> is there any alternative to this suckiness? because it seems like the truly best reasonable alternative is to just use x264 [01:15:16 CET] <furq> yes, it's to use x264 [01:15:36 CET] <furq> vp9 itself isn't bad but libvpx is not great [01:15:41 CET] <TD-Linux> thebombzen, vp9 will generally work much better for crf [01:15:51 CET] <furq> and i wouldn't expect much more development on the vp8/vp9 stuff in libvpx [01:15:55 CET] <TD-Linux> its rate control is a separate codebase [01:16:05 CET] <thebombzen> why is vp10 happening? [01:16:08 CET] <thebombzen> or just av1 stuff [01:16:14 CET] <TD-Linux> vp10 is dead, av1 is new [01:16:19 CET] <furq> vp10 and av1 are much of a muchness [01:16:31 CET] <thebombzen> well av1 isn't even frozen yet, right? [01:16:37 CET] <TD-Linux> av1 has a theora and x264-style rate controller landed recently [01:17:14 CET] <thebombzen> but again it's not even frozen, so we shouldn't expect it anytime soon [01:17:23 CET] <furq> i'm perfectly happy with x264 until av1 lands [01:17:42 CET] <TD-Linux> correct [01:17:49 CET] <TD-Linux> in the meantime someone should really write a GOP parallel encoder [01:18:08 CET] <TD-Linux> this is why libvpx's threading is so bad, most companies don't use it [01:21:21 CET] <TD-Linux> er I think boram can actually do GOP parallel [01:23:42 CET] <TD-Linux> er no it can't [01:45:15 CET] <JEEB> TD-Linux: now try to do relatively low-latency live streaming with GOP parallelism [01:45:38 CET] <TD-Linux> JEEB, well frame parallel doesn't work for that either (unless you're talking about twitch latency) [01:45:39 CET] <JEEB> (without losing a whopping amount of compression) [01:45:52 CET] <JEEB> TD-Linux: within 5-10 seconds [01:46:03 CET] <JEEB> which is "bearable as you don't know the source" [01:50:52 CET] <thebombzen> is there an easy way to tell if a subtitle codec is a text-based codec or image-based codec on the fly? [01:51:24 CET] <thebombzen> cause I just tried -vf subtitles for a pgssub file and it said that it only supports text-based subs, but how would I check in advance (say, in a script) so I can switch between -vf subtitles and -vf overlay? [01:59:12 CET] <c_14> ffprobe the input format? [01:59:27 CET] <furq> ffprobe and codec_name is the best thing i can think of [01:59:37 CET] <furq> there's no flag in there that tells you if it's a text format [01:59:53 CET] <furq> but there aren't a great deal of text formats that you'll actually encounter [02:00:12 CET] <c_14> I think it might be easier to match for image formats [02:00:14 CET] <c_14> Not that many of those [02:00:35 CET] <c_14> It's easier to invent a new text-based format than an image based one [02:00:41 CET] <furq> i guess [04:28:15 CET] <llamapixel> file can determine ascii or binary [05:20:11 CET] <thebombzen> llamapixel: extracting the subs and checking if it's a binary file isn't the sort of thing I"m looking for [05:20:35 CET] <thebombzen> given that I could just attempt using -vf subtitles and parsing the ffmpeg output for "Only text based subtitles are currently supported" [05:21:35 CET] <thebombzen> especially since that doesn't work unless you can mux the raw stream [05:21:54 CET] <llamapixel> Extracting seems like overkill but ok [05:22:59 CET] <thebombzen> well how else am I supposed to use file to check that [05:23:10 CET] <thebombzen> given that it's muxed inside a binary container with a binary video and a binary audio [05:24:06 CET] <thebombzen> llamapixel: if you don't extract it, file will report "matroska data" or something useless [05:29:07 CET] <llamapixel> Which is just a zip file right? [05:30:48 CET] <llamapixel> Isn't Mkv just a container file in case that is incorrect? [05:39:55 CET] <llamapixel> Touchy [06:47:22 CET] <Aakash> Hello, I have made a rails app that can stream live videos to facebook rtmp server and deployed it on Digital Ocean. I have used nginx as web server and using a linux OS. The major problem that I am encountering after viewing log files of FFMpeg processes is that after streaming for some time(that keeps on varying) FFmpeg process gives the error av_interleaved_write_frame(): Broken pipe This is the command that I am using: [06:47:35 CET] <Aakash> $HOME/bin/ffmpeg -loop 1 -re -y -f image2 -i 'public/uploads/post/25/frame1.png' -acodec copy -bsf:a aac_adtstoasc -pix_fmt yuv420p -profile:v high -s 1280x720 -vb 400k -maxrate 400k -minrate 400k -bufsize 600k -deinterlace -vcodec libx264 -preset veryfast -g 30 -r 30 -t 14400 -strict -2 -f flv "rtmp_link" 2> "logfile" [06:48:00 CET] <kepstin> Aakash: all that error means is that the rtmp connection got dropped [06:48:20 CET] <kepstin> probably the best you can do is restart it, unless you can figure out the network issue [06:48:44 CET] <Aakash> Thans kepstin for your answer [06:48:49 CET] <Aakash> I am copying my logs [06:48:54 CET] <Aakash> please have alook at them [06:49:13 CET] <Aakash> ffmpeg version N-83442-gdac51d2 Copyright (c) 2000-2017 the FFmpeg developers built with gcc 4.8 (Ubuntu 4.8.4-2ubuntu1~14.04.3) configuration: --prefix=/root/ffmpeg_build --pkg-config-flags=--static --extra-cflags=-I/root/ffmpeg_build/include --extra-ldflags=-L/root/ffmpeg_build/lib --bindir=/root/bin --enable-gpl --enable-libass --enable-libfdk-aac --enable-libfreetype --enable-libmp3lame --enable-libopus --enable-libtheora --e [06:49:14 CET] <kepstin> heh, it's past midnight here, I'm off now. [06:49:19 CET] <kepstin> and don't paste in the channel [06:49:39 CET] <Aakash> okay [06:49:44 CET] <Aakash> I'll keep that in mind [06:54:03 CET] <Aakash> http://pastebin.com/vC1vLDEg [06:54:23 CET] <Aakash> this is the link having the command that I'm using and logs of ffmpeg process [07:07:30 CET] <Aakash> After combining things together, I have made a rails app that can stream live videos to facebook rtmp server and deployed it on Digital Ocean. I have used nginx as web server and using a linux OS. The problem is that after streaming for some time(that keeps on varying) FFmpeg process gives the error av_interleaved_write_frame(): Broken pipe Pastebin link of command and logs: http://pastebin.com/vC1vLDEg [09:43:36 CET] <Diag> Anyone here Chinese [10:31:33 CET] <IamTrying> Is there any knowledgeable person? what is i420 frames (my video renderer RTCEAGLVideoView.h renders i420 frames, and after certrain period of time its frozen) [10:31:46 CET] <IamTrying> i am trying to understand i420 anyone have some knowledge about it? [10:32:55 CET] <IamTrying> it use OpenGLES 2.0 [10:51:50 CET] <IamTrying> What the fuck? no body has fucking knowledge about it. [11:03:57 CET] <Ekho> does anyone happen to know how to properly add cover art to .opus/ogg files using ffmpeg? (https://wiki.xiph.org/VorbisComment#METADATA_BLOCK_PICTURE ?) [16:19:51 CET] <ben__> Hi, I'm trying to do livestreaming with ffmpeg. I'm using libavformat to produce an mkv output stream. The muxer has a is_live option. How can you set this option using libavformat? [16:23:15 CET] <JEEB> if it's an AVOption, yes [16:24:34 CET] <ben__> how can you set this option? Do I have to pass it in the dictionary when calling av_format_write_header()? [16:26:53 CET] <JEEB> according to how avformat/tests/movenc.c seems to do it, yes [16:40:02 CET] <ben__> JEEB thanks for your tip. haven't looked at this file before, seems to contain a lot of useful information. is there a way to very that the option has been set? [16:40:44 CET] <JEEB> other than checking if it's doing what you've requested, not sure [16:47:11 CET] <ben__> JEEB thanks again for your answer. It helped a lot :) [16:48:01 CET] <JEEB> no problemo [16:54:02 CET] <DHE> ben__: the AVDictionary you pass will be eaten, and any options NOT consumed will be left behind [16:54:55 CET] <DHE> you can imagine that's how ffmpeg works. your command-line is turned into AVDictionary options and given to the avformat_* functions. Anything left over goes to the avcodec_* functions. And so on. anything ultimately left over is a user error [17:01:25 CET] <ben__> DHE: great tip, thx. my options have all been consumed so they must have been correct. yeah :) [17:07:58 CET] <JEEB> coolio [17:08:05 CET] <JEEB> DHE: nice, I actually never thought of that [17:08:10 CET] <JEEB> or checked the implementation [17:08:11 CET] <JEEB> lol [17:11:42 CET] <DHE> JEEB: it's a bit more complicated since there -param:v:0 suffixes to be parsed, but still [17:11:59 CET] <JEEB> well, yeah. I was mostly talking about the avdictionary passage part [17:13:23 CET] <TerNer> JEEB, can I continue a question in this channel? [17:13:35 CET] <JEEB> yes [17:14:00 CET] <JEEB> anyways, yes - fragmented isobmff is something you can pass to a client in a streaming manner [17:14:49 CET] <TerNer> but JEEB, fragmented mp4 also have 'duration' data [17:15:02 CET] <TerNer> I want to streaming a video infinitly [17:15:03 CET] <JEEB> as instead of a single moov you get various other boxes that happen for each fragment [17:15:06 CET] <JEEB> uhh [17:15:11 CET] <JEEB> that's exactly what it is for [17:15:32 CET] <TerNer> fragmented mp4 not have duration data? [17:15:58 CET] <JEEB> it has all the data required to play a fragment after a fragment [17:16:21 CET] <JEEB> and whatever field you're talking of it is not limited by that [17:16:47 CET] <JEEB> the main thing with fragmented ISOBMFF is that you need to make sure your clients support it, though :P [17:16:55 CET] <JEEB> since the boxes are different from non-fragmented content [17:17:25 CET] <TerNer> so how does player realize end of stream/video if fragmented mp4 doesn't have duration data? [17:17:36 CET] <JEEB> end of stream means no more fragments [17:17:41 CET] <TerNer> oh [17:17:43 CET] <JEEB> or no more data from stream [17:18:14 CET] <TerNer> well, I'm trying to have streaming to chromium browser [17:18:41 CET] <JEEB> I have a hunch you will want something that is either HLS or DASH, since for that you have already done libraries [17:19:09 CET] <JEEB> DASH uses fragmented ISOBMFF [17:19:30 CET] <JEEB> but anyways, in other words it will work [17:19:31 CET] <JEEB> :P [17:19:41 CET] <JEEB> how well depends on how much effort you put into it [17:20:18 CET] <TerNer> :o [17:54:15 CET] <Darby_> hi guys, i need another little help [17:55:25 CET] <Darby_> i want compile a static ffmpeg binary and add some library with static library [17:55:58 CET] <Darby_> Debian Jessie don't have static library for some packet [17:56:38 CET] <Darby_> i must compile every library for have static .a files [17:57:31 CET] <Darby_> how can i compile ffmpeg binary with those library compiled by myself? [19:06:32 CET] <forgon> I'd like to compress a 13G lossless *.mkv file to the utmost without losing quality. How should I proceed? [19:06:59 CET] <forgon> Both flac audio and libx264 video are included. [19:07:27 CET] <JEEB> without losing quality already means that you have to be using something lossless [19:07:43 CET] <JEEB> thus you can use either ffv1 or libx264 with a very long GOP length [19:07:53 CET] <JEEB> and with libx264 the slowest preset you can take [19:08:21 CET] <forgon> JEEB: What compression could I reasonably expect if going from -ultrafast to -veryslow? [19:08:40 CET] <JEEB> depends on what your other parameters such as GOP length are? [19:08:48 CET] <JEEB> before/after [19:09:12 CET] <forgon> JEEB: Do you mean the framerate? [19:09:31 CET] <JEEB> no [19:09:42 CET] <JEEB> for how long the encoder goes without having to do an IRAP [19:10:48 CET] <JEEB> libx264 by default sets the GOP length to about 10 seconds and is dynamic about it, but of course if you set the thing to infinite you will get gains [19:14:41 CET] <furq> you also won't be able to seek [19:14:43 CET] Action: forgon doesn't know :| [19:15:29 CET] <furq> just reencode it with veryslow [19:15:55 CET] <furq> i doubt you'll get massive gains but from what i've seen it'll be a noticeable difference [19:17:26 CET] <forgon> furq: Okay, what is the command? Can I just run `ffmpeg -i inputfile -vcodec copy -acodec copy -qp 0 -preset veryslow outputfile`? [19:17:32 CET] <furq> no [19:17:40 CET] <furq> -vcodec libx264 [19:17:54 CET] <forgon> furq: The rest is correct? [19:17:56 CET] <furq> yes [19:18:08 CET] <furq> if you really want to squeeze every byte then you can set -g and -x264-params keyint-min [19:18:16 CET] <furq> the default is 250 frames [19:18:31 CET] <furq> i wouldn't bother messing with those though [19:18:55 CET] <furq> and of course you can also use a more efficient audio codec, but again i wouldn't bother with that [19:19:05 CET] <furq> you could maybe do -acodec flac -compression_level 12 [19:19:21 CET] <forgon> I'll use that acodec, thank you. [19:19:42 CET] <furq> there are more efficient lossless codecs than flac, but they're mostly not worth bothering with [19:20:05 CET] <furq> you're looking at 2-3% space savings with the tradeoff of much slower decoding and/or much worse decoder support [19:20:23 CET] <furq> i'm also not sure if libavcodec has encoders for any of them [19:20:33 CET] <furq> it definitely doesn't have ape or tak [19:20:42 CET] <forgon> Okay, I'll drop flac improvement then. [19:20:55 CET] <furq> -compression_level 12 should be fine [19:25:30 CET] <forgon> A noob question: How do I know how long it will take? does the redrawn line at the tail of program output as it is running give this info? [19:25:55 CET] <forgon> Currently it says `speed=0.144x` at the end [19:26:45 CET] <furq> then it's probably going to be the length of the video * 0.144 [19:27:46 CET] <forgon> Thanks. [19:40:10 CET] <DHE> furq: divided by, not multiplied by. [19:40:42 CET] <DHE> which is ballpark 7x the duration of the video [23:58:34 CET] <klaxa> so, has AVStream->codec beem deprecated in favor of AVStream->codecpar? [23:58:48 CET] <durandal_1707> yes [23:59:27 CET] <klaxa> and all the write functions definitely do not rely on AVStream->codec? [23:59:54 CET] <durandal_1707> yes [00:00:00 CET] --- Sun Feb 26 2017

1 0

ffmpeg-devel.log.20170224
by burek 25 Feb '17

25 Feb '17

[01:11:08 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:76ba09d18245: avcodec/mpeg4videodec: Check the other 3 sprite points for intermediate overflows [01:11:09 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:e98dfeb27c2a: avcodec/jpeglsdec: check shift for values that cause overflow later [01:11:10 CET] <cone-087> ffmpeg 03Michael Niedermayer 07master:0d85c7bb5a4c: avcodec/ituh263dec: Fix runtime error: left shift of 1342177279 by 1 places cannot be represented in type 'int' [06:52:16 CET] <nevcairiel> BtbN: most hwaccel have that limitation, you have to define a number of frames it has access to, and when the decoder needs some and they are still in use somewhere, bad things happen - its not a cuvid-exclusive problem [08:15:39 CET] <cone-335> ffmpeg 03Rostislav Pehlivanov 07master:22b8ada7b5e0: opus_pvq: improve PVQ search for low Ks [08:15:39 CET] <cone-335> ffmpeg 03Rostislav Pehlivanov 07master:f19442c06992: opus_pvq: remove unneeded assert [08:16:12 CET] <atomnuker> RiCON: this survived 2 hours of fuzzing well outside the normal operating conditions of the search [08:19:19 CET] <atomnuker> this algorithm _will_not_crash_ unless the compiler messed up [08:19:44 CET] <nevcairiel> you said that the first time =p [08:25:45 CET] <atomnuker> yeah well now me and the 100-odd expended watts up stand to prove me right [11:05:09 CET] <cone-335> ffmpeg 03Carl Eugen Hoyos 07master:560f5188c624: lavc/utils: Make second parameter to apply_param_change() const. [11:35:13 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:fa3e49568dc8: avcodec/aic: unbreak decoding of files with slice_width != 16 [11:39:26 CET] <durandal_1707> trac is utter garbage [11:44:55 CET] <wm4> yeah, github's issue tracker works actually pretty well [12:03:45 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:178cd50c47aa: avcodec/scpr: make sure that component value is <= 0x1F for 16 bpc [12:09:54 CET] <Compn> ok time to look at scpr for durandal_1707 :) [14:13:25 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:8696f254444c: avcodec/rv34: Simplify and factor get_slice_offset() code [14:13:26 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:2b8b7921c55a: avcodec/vp3dsp: Fix multiple signed integer overflow: 46341 * 47523 cannot be represented in type 'int' [14:13:27 CET] <cone-335> ffmpeg 03Michael Niedermayer 07master:c87ea47481d3: tools/target_dec_fuzzer: Fix misaligned read [14:13:58 CET] <kierank> wm4: anything interesting on ffmpeg-security? [14:14:26 CET] <wm4> kierank: you've read the ML thread? [14:14:50 CET] <kierank> i thought you were added? [14:14:59 CET] <kierank> or is it $realname stuff? [14:15:07 CET] <wm4> still pending [14:15:09 CET] <wm4> also http://lists.ffmpeg.org/pipermail/ffmpeg-devel/2017-February/207544.html [14:18:34 CET] <ismail> so basically he wants to fix security bugs all by himself? :) [14:22:17 CET] <RiCON> that's not an issue, didn't wm4/kierank just want to review patches? [14:23:07 CET] <wm4> RiCON: yes [14:23:47 CET] <wm4> smells a bit like trying to come up with whatever reason to deny access, but maybe I shouldn't make such presumptions [14:24:39 CET] <Compn> wm4 : very rarely have i ever seen michaelni say what he likes to do in ffmpeg [14:24:54 CET] <Compn> so if he says he likes security, let him enjoy that [14:24:55 CET] <wm4> *shrug* [14:25:03 CET] <wm4> I don't want to take that from him [14:25:12 CET] <wm4> <RiCON> that's not an issue, didn't wm4/kierank just want to review patches? [14:25:15 CET] <Compn> wm4 : if you just want to review bugs so you can fix them in mpv , say that too :P [14:25:16 CET] <wm4> and I've said that before [14:25:43 CET] <Compn> its also possible that this is an income source ... [14:25:49 CET] Action: Compn doesnt want to speculate [14:26:40 CET] <funman> Compn: i can sell you cheap FFmpeg 0days [14:29:15 CET] <Compn> i mean fixing them = bounties [15:30:26 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:0a28c505063f: avcodec/scpr: improve motion vectors checking for out of buffer write [15:34:25 CET] <RiCON> atomnuker: hehe https://i.fsbn.eu/gO9c.txt [15:40:55 CET] <RiCON> y array still has those INT_MAX INT_MIN first two values [15:41:36 CET] <iive> atomnuker: I was wondering, if the bug might be hidden somewhere is ffmpeg defies, like FFABS, MIN, MAX or something like that. [15:42:22 CET] <durandal_1707> michaelni: see ^ [15:49:04 CET] <michaelni> durandal_1707, thx but ATM oss-fuzz finds about 10 new undefined behavior cases each day so iam not short of ones to fix [15:49:59 CET] <ismail> durandal_1707: make oss-fuzz guys report it instead :p [15:51:46 CET] <michaelni> they just recently enabled ubsan ... [15:53:36 CET] <cone-335> ffmpeg 03Paul B Mahol 07master:c583e701bd52: avcodec/fmvc: initialize opcode to 0 [16:42:22 CET] <adeel_> I wish to make contributions to the 'libswscale' module. Could anyone here please point me in a direction? [16:52:03 CET] <jamrial> adeel_: a good start is to check https://ffmpeg.org/developer.html#Contributing [16:56:07 CET] <adeel_> Thanks, James. I am going through Bug tracker. After fixing a small bug, I plan on moving to a qualification task. [16:57:08 CET] <durandal_1707> anybody wants to sponsor atrac9 decoder? [17:01:37 CET] <adeel_> durandal_1707, for what purpose do you wish to use atrac9 decoder for? [17:02:29 CET] <durandal_1707> to play fancy game music [17:36:10 CET] <kierank> BBB: is there any stuff J_Darnley can do to speed up h264? [17:36:16 CET] <kierank> cabac bmi2 perhaps like x264? [17:36:30 CET] <BBB> decoding? [17:37:10 CET] <BBB> kierank: decoding? [17:37:13 CET] <kierank> yes [17:39:14 CET] <BBB> I think avx2 is the most obvious one [17:39:41 CET] <kierank> ok he is working on that already [17:42:07 CET] <BBB> MC at 16x16 blocks can use avx2 [17:42:19 CET] <funman> avx264 [17:42:20 CET] <BBB> and transform_block (2x2 8x8s or 4x4 4x4s) can use avx2 [17:42:37 CET] <BBB> if you use high bitdepth (10bit), you can avx2 a ton more [17:42:42 CET] <BBB> but you already know that probably [17:42:57 CET] <BBB> depending on bitrate or intra frequency, intra pred may be interesting also [17:46:23 CET] <atomnuker> iive: there is no damn bug anymore, its RiCON and his crappy compiler now [17:46:37 CET] <atomnuker> I dare someone to replicate it with another compiler [17:46:49 CET] <kierank> what compiler [17:47:37 CET] <iive> atomnuker: compiler bugs are still bugs, that have to be traced, reported and fixed. [17:47:59 CET] <iive> kierank: msys gcc 6.3.0 [17:48:44 CET] <RiCON> mingw* [17:48:56 CET] <RiCON> but the latest backtrace was using nevcairiel's gcc [17:50:35 CET] <RiCON> i could also try with clang, but i've never done it [17:50:37 CET] <nevcairiel> well then you know where to get older versions of my builds as well to check :) [17:51:18 CET] <iive> that's actually good idea. my distro is still using 5.4.0 [17:54:09 CET] <nevcairiel> kierank: cabac would always be a really good target to get faster, but its probably also one of the hardest thigns to target :) [17:54:52 CET] <nevcairiel> RiCON: which sample are you using for the opus test? [17:55:50 CET] <RiCON> https://i.fsbn.eu/instantcrash.flac [17:56:11 CET] <nevcairiel> thanks, lets see if it also happens [17:58:52 CET] <RiCON> oh, there's a new r25 build, hadn't noticed [17:59:19 CET] <nevcairiel> oh yeah just a minor fix in the crt that made ffmpeg fate fail otherwise [17:59:36 CET] <RiCON> unlikely to be that since it also happens with git mingw-w64 [18:00:19 CET] <nevcairiel> interesting [18:00:25 CET] <nevcairiel> for me it doesnt crash, it just hangs [18:00:38 CET] <nevcairiel> or its *really really* slow =p [18:01:22 CET] <RiCON> you trying on windows or wine? [18:01:28 CET] <nevcairiel> windows [18:02:56 CET] <nevcairiel> seems to infini loop in or around celt_pvq_search [18:03:49 CET] <RiCON> it always instantly segfaults here with 64-bit [18:03:55 CET] <RiCON> 32-bit yeah, some loop [18:03:57 CET] <nevcairiel> i tried 32 [18:04:13 CET] <RiCON> 32-bit used to trigger the assert atomnuker had before [18:04:56 CET] <nevcairiel> i put a breakpoint on that function, and it enters a couple times and then never exits [18:08:15 CET] <nevcairiel> (or at least not in any deterministic time) [18:10:12 CET] <jamrial> i'm also getting segfaults on this encoder with msys2's gcc 6.3.0 package and nevcairiel's gcc 6.2.0 package using a standard wav file here [18:10:23 CET] <jamrial> x86_64, didn't try x86_32 [18:10:41 CET] <RiCON> i'm trying with nev's 5.4 now [18:12:01 CET] <kierank> 4.9.4 works [18:12:26 CET] <jamrial> tried an aac file as source and it didn't crash [18:15:43 CET] <RiCON> same endless loop with nev's 5.4 32-bit, same segfault/backtrace with 64-bit [18:19:58 CET] <RiCON> also tried converting to aac and using that instead, no segfault then [18:31:00 CET] <nevcairiel> it seems to produce really odd values for K sometimes, taking the function for ever to finish by basically iterating through a full integer range [18:32:00 CET] <nevcairiel> i think the function works as expected, but the input is just odd [18:37:45 CET] <RiCON> i can reproduce the segfault with a ton of files randomly taken from my music library [19:05:10 CET] <RiCON> https://i.fsbn.eu/pub/ffopus-segfault-samples/ [19:05:23 CET] <RiCON> all cut to 5s [19:07:19 CET] <atomnuker> nope, not a single crash with any of them here and not even getting a single valgrind warning [19:08:00 CET] <RiCON> :( [19:09:20 CET] <jamrial> atomnuker: can't reproduce it with wine? [19:10:41 CET] <atomnuker> I don't have wine, the most exotic thing I have is an odroid c2 with some old gcc, I'm trying that now [19:14:31 CET] <RiCON> sample 11 doesn't actually crash, mistakenly added [19:16:51 CET] <peloverde> atomnuker: I can reproduce on -m32 builds [19:42:05 CET] <atomnuker> nope, I can't replicate it on an odroid c2 with gcc 6.3.1 [19:42:21 CET] <RiCON> might be a mingw-only bug then [19:42:37 CET] <atomnuker> how was it that you compiled ffmpeg for a 32 bit system on a 64 bit one? [19:43:04 CET] <RiCON> -m32 with multilib or just use a i686 gcc? [19:45:30 CET] <peloverde> I just did --extra-cflags=-m32 --extra-ldflags=-m32 [19:45:37 CET] <peloverde> I think it's a multilib solution [19:54:27 CET] <cone-476> ffmpeg 03Paul B Mahol 07master:e01c32f260fa: avcodec/scpr: remove 4 dead store [19:55:28 CET] <kierank> durandal_1707: you want more than https://support.apple.com/kb/DL480?viewlocale=en_US&locale=en_US [19:56:34 CET] <durandal_1707> kierank: i got it already [19:56:58 CET] <kierank> there is also apple h264 with alpha channel [19:57:01 CET] <kierank> might be interesting to RE [19:57:11 CET] <durandal_1707> ugh [19:57:21 CET] <durandal_1707> there are samples? [19:57:45 CET] <peloverde> atomnuker: What is celt_pvq_search supposed to do when res is 0 or near-zero? [20:03:47 CET] <atomnuker> nothing special, pulse allocation passes to the slow search which iterates over all positions and puts them one at a time [20:08:49 CET] <atomnuker> oh crap [20:08:59 CET] <peloverde> what? [20:15:01 CET] <cone-476> ffmpeg 03Rostislav Pehlivanov 07master:70259737cbad: opus_pvq: prevent division by 0 [20:15:40 CET] <peloverde> yeah, that's what I saw [20:16:27 CET] <peloverde> It's even worse because res*X[i] is inf*0 = NaN [20:18:23 CET] <atomnuker> libopus dealt with that in its pvq search by using a yet another hack and setting the entire input to 0 except at one position it would put a 1 [20:19:38 CET] <atomnuker> right, so RiCON, you know what to do, prove me wrong once again that this fixes nothing [20:20:21 CET] <RiCON> heh [20:40:08 CET] <RiCON> atomnuker: i think that did the trick [20:41:49 CET] <RiCON> i'll check with the full-length samples, just in case [20:48:49 CET] <RiCON> yeah, this bug's fixed, congrats atomnuker [22:04:01 CET] <iive> \o/ [22:24:01 CET] <cone-476> ffmpeg 03Michael Niedermayer 07master:5d81616be332: avcodec/mpegaudiodec_template: Correct return code on id3 tag discarding [22:24:02 CET] <cone-476> ffmpeg 03Michael Niedermayer 07master:513a3494396d: avcodec/vp56: Fix sign typo [22:26:34 CET] <durandal_1707> michaelni: what is needed to apply that security patch? [22:36:52 CET] <michaelni> durandal_1707, what security patch ? the addition of people to the alias one ? [22:37:21 CET] <durandal_1707> yes [22:39:17 CET] <DHE> durandal_1707: just figured it out. I'm also feeding it AAC audio instead of AC3, and AC3 does support in-codec downmixing but AAC does not... [22:39:26 CET] <michaelni> I wanted to give enough time so everyone can comment. It didnt seem to me to be important to apply it within 2 days of being posted [22:39:32 CET] <DHE> oh wrong channel. sorry. [00:00:00 CET] --- Sat Feb 25 2017

1 0

ffmpeg.log.20170224
by burek 25 Feb '17

25 Feb '17

[00:14:29 CET] <funyun> hi. can anyone help me with this error? http://pastebin.com/ke9pFz5E [00:14:56 CET] <funyun> i only get it when i add "-profile:v high -level 5.2" [00:19:32 CET] <BtbN> [h264_nvenc @ 000001ad98ab9f40] The variable bitrate rate-control requires the 'qmin' and/or 'qmax' option set. [00:19:58 CET] <BtbN> Also highly possible that your card simply does not support level 5.2. [00:20:18 CET] <BtbN> You usually use the level setting to limit the level, not set it to a high one. [00:21:02 CET] <funyun> BtbN: is there a specific qmin qmax setting? i've tried multiple variations and i get the same error only without that qmin line [00:21:13 CET] <funyun> BtbN: i have a gtx 1080 [00:21:20 CET] <funyun> will that support 5.2? [00:21:33 CET] <BtbN> no idea, doesn't look like it if it works without that level parameter. [00:22:21 CET] <funyun> BtbN: ah i see. thanks for the help [00:24:02 CET] <BtbN> There also is no level 5.2 restriction. The highest you can set is 5.1. [00:24:09 CET] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc_h264.c#L70 [00:27:13 CET] <funyun> BtbN: yep that's what it was. i just tried 5.1 and it worked fine. sucks but thanks for the help [00:27:23 CET] <BtbN> what? [00:27:35 CET] <BtbN> You do realize it's a restriction-setting? [00:27:48 CET] <funyun> what does that mean? [00:27:49 CET] <BtbN> Not a "use this level" [00:27:58 CET] <BtbN> It will most likely still use the lowest level possible. [00:28:16 CET] <BtbN> so restricting it to the highest level makes no sense to begin with [00:29:23 CET] <funyun> BtbN: no, the output was indeed 5.1. but i need 5.2 because anything else stutters on my player [00:29:37 CET] <BtbN> so don't specify a restriction then [00:29:55 CET] <BtbN> And I highly doubt that. [00:30:06 CET] <BtbN> The higher the level, the more complex it gets to decode it [00:30:20 CET] <funyun> BtbN: that's what i thought [00:30:22 CET] <BtbN> That's the entire point of the levels [08:32:18 CET] <k_sze[work]> ugh, ffmpeg is using over 1.5GB resident memory, WAT?! [08:32:48 CET] <k_sze[work]> I specified -c:v libx264 -preset veryslow, but still, 1.5GB, seriously? [08:42:40 CET] <JEEB> depending on the resolution, input format etc that's probably not too much [08:43:43 CET] <JEEB> at veryslow I think the lookahead in x264 is like 60 raw video frames? [08:44:08 CET] <JEEB> and then the rest of ffmpeg et al also has to have different buffers [09:06:32 CET] <ChuckLePlant_> good day, if I have compiled ffmpeg with cuvid support, how can I make sure I initialize AVCodec using cuvid instead of cpu based codec? Currently I call avcodec_find_decoder(AV_CODEC_ID_H264); [09:25:25 CET] <JEEB> ChuckLePlant_: if there's no separate AVCodecID, there's avcodec_find_encoder_by_name [09:25:31 CET] <JEEB> to which you can stick a string in [09:26:28 CET] <ChuckLePlant_> JEEB where can I find the valid strings to be used? [09:29:05 CET] <JEEB> in the actual decoder definitions [09:29:12 CET] <JEEB> it's the same name as you'd use with the ffmpeg cli tool [09:29:23 CET] <JEEB> ffmpeg -decoders or -encoders is one way :P [09:31:33 CET] <JEEB> there might be a "give me all strings for encoders for this one codec id" so you could go through them, but didn't look far enough [09:36:52 CET] <ChuckLePlant_> thanks! [11:35:55 CET] <acamargo> morning! people, I have a GPU 0: GeForce GTX 745 (UUID: GPU-ba41d615-c63f-1824-634d-15564856f881) and I want to transcode mpegts for streaming. But I'm receiving [h264_nvenc @ 0x423cde0] OpenEncodeSessionEx failed: out of memory (10) when I am going to use more than 268MiB (the board has 4GiB). how can I use full memory? [11:37:19 CET] <jkqxz> Is that when opening a third encode session? [11:40:24 CET] <acamargo> yep :-) [11:40:28 CET] <acamargo> http://pastebin.com/jwVLUkmj [11:41:16 CET] <jkqxz> I'm afraid you've been deemed unworthy because you didn't give enough money to nvidia. You need to have an "enterprise" card (i.e. one costing 10x as much) to encode more than two streams at once.have more than two streams [11:41:48 CET] <acamargo> really? [11:41:51 CET] <jkqxz> Yes. [11:43:56 CET] <acamargo> so, is there a limit of processes to use gpu at same time? [11:46:33 CET] <jkqxz> No, it's a limit on encode sessions specifically, independent of processes. (Presumably enforced by the driver.) [11:50:18 CET] <acamargo> :-( any official doc about that? [11:51:49 CET] <DHE> https://devtalk.nvidia.com/default/topic/800942/session-count-limitation-fo… [11:52:27 CET] <DHE> It's a 2 session limit, but each session has no speed limit. If you're not doing realtime transcoding (ie. not over-the-air, but from files on disk) it probably won't matter too much [11:58:57 CET] <acamargo> thank you so much guys, very helpful information ;-) [12:48:03 CET] <ChuckLePlant_> Hi [12:48:18 CET] <ChuckLePlant_> I'm building ffmpeg with cuda support, and get an issue with name mangling [12:48:33 CET] <ChuckLePlant_> http://pastebin.com/RAzDgYry [12:49:56 CET] <ChuckLePlant_> What that says is that ffmpeg tries to find _cuInit (unmangled).. and cuda.lib defines _cuInit@4 (mangled with stdcall convention) [12:50:37 CET] <ChuckLePlant_> In cuda.h CUDAAPI is defined as stdcall if _WIN32 is defined, So I define it like this: [12:50:44 CET] <ChuckLePlant_> --extra-cflags="-D_WIN32 -IC:\\cuda_8\\include" [12:50:59 CET] <ChuckLePlant_> (Full configure line here: http://pastebin.com/dMDRJNnA) [13:17:42 CET] <ChuckLePlant_> What is the cuda version compatible with ffmpeg? [14:03:54 CET] <Darby_Crash> hi guys. I'm working on Debian Jessie and i have wrote this script to compile a static build of ffmpeg using only repository for the libs https://clbin.com/UTclp [14:04:52 CET] <Darby_Crash> i have a issue, libx265 and librtmp not found using pkg-config [14:05:33 CET] <Darby_Crash> Can someone help me? [14:09:57 CET] <Darby_Crash> pkg-config --list-all | grep rtmp show me right result and also x265 [14:10:28 CET] <Darby_Crash> where is my bad? [14:11:03 CET] <jkqxz> Look in config.log for the actual error. [14:11:57 CET] <Darby_Crash> collect2: error: ld returned 1 exit status [14:11:57 CET] <Darby_Crash> ERROR: x265 not found using pkg-config [14:12:27 CET] <furq> look higher [14:13:39 CET] <Darby_Crash> https://clbin.com/fIp8B this is my config.log [14:14:05 CET] <furq> /usr/bin/ld: cannot find -lnuma [14:15:18 CET] <Darby_Crash> thanks furq, how can i fix this? [14:15:42 CET] <furq> install libnuma? [14:18:27 CET] <Darby_Crash> you're right, i haven't it [14:18:37 CET] <Darby_Crash> thanks mate ;) [14:25:52 CET] <Darby_Crash> furq i have fixed for libx265 but librtmp don't work [14:26:23 CET] <furq> librtmp sucks anyway [14:26:32 CET] <furq> ffmpeg's native rtmp stuff works fine [14:28:29 CET] <Darby_Crash> is native library equal? [14:30:05 CET] <Darby_Crash> https://clbin.com/MTsHk config.log [16:03:16 CET] <TerNer> Guys, can I write encoded data to memory not a file? [16:03:20 CET] <TerNer> in C [16:06:44 CET] <JEEB> yes [16:07:02 CET] <JEEB> if you want custom IO you can write an AVIO thing [16:07:19 CET] <JEEB> you basically can implement your own read,write,seek etc [16:07:58 CET] <JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper… [16:08:48 CET] <JEEB> and then https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn… [16:08:56 CET] <JEEB> this is my old code, but could be useful [16:09:55 CET] <JEEB> this was for reading, but you can do the same for writing [16:10:05 CET] <JEEB> (do note that APIs could have changed since, I have not updated that thing at all) [16:19:51 CET] <DHE> http://ffmpeg.org/doxygen/3.1/avio_reading_8c-example.html This documents how to do it for reading. Gives you an idea what to look at in the docs for writing. [16:20:55 CET] <TerNer> oh I got disconnected [16:21:21 CET] <TerNer> Someone can let me know how can I write encoded data to memory not a file? [16:22:13 CET] <JEEB> 17:08 < JEEB> https://github.com/jeeb/matroska_thumbnails/blob/master/src/istream_wrapper… [16:22:16 CET] <JEEB> 17:09 < JEEB> and then https://github.com/jeeb/matroska_thumbnails/blob/master/src/matroska_thumbn… [16:22:19 CET] <JEEB> 17:09 < JEEB> this is my old code, but could be useful [16:22:25 CET] <JEEB> and DHE linked an example in the code [16:22:26 CET] <JEEB> 17:20 < DHE> http://ffmpeg.org/doxygen/3.1/avio_reading_8c-example.html [16:22:38 CET] <JEEB> both of these examples are for reading, but it's very similar for writing [16:22:50 CET] <JEEB> you just define the write function instead of read [16:22:58 CET] <TerNer> JEEB, thank you for your help [16:24:11 CET] <TerNer> but JEEB, overriding writing function of avio is not providing "correct" encoded data [16:28:28 CET] <JEEB> it shouldn't differ in any way, so your AVIO stuff is most likely incorrect then [16:29:13 CET] <TerNer> JEEB, I just replaced some code of ffmpeg example [16:29:39 CET] <DHE> keep in mind ffmpeg itself uses the same APIs for its own network and file access [16:32:02 CET] <TerNer> DHE: There's no way to write in memory? [16:32:54 CET] <DHE> not built-in. you'll have to provide your own avio functions [16:33:00 CET] <DHE> similarly to the example for reading [16:33:52 CET] <TerNer> oh [19:21:46 CET] <zamba> hi! i'm in the process of digitalizing a bunch of old video cassettes.. for this i'm using ffmpeg.. and the following options: -f video4linux2 -channe 1 -i /dev/video0 -f alsa -i default -vf crop704:556:4:6,yadif,hqdn3d,format=yuv420p .. [19:22:01 CET] <zamba> on the status output i'm seeing dup=2 and drop=4.. what does this mean? [19:22:07 CET] <zamba> could that case to A/V desync? [19:44:42 CET] <Darby> hi guys i have a working script to compile ffmpeg in static mode but resulted binary required shared library [19:45:35 CET] <furq> which shared library [19:47:52 CET] <Darby> https://clbin.com/aR7ae hi furq [19:49:17 CET] <Darby> script is this https://clbin.com/d3g0s [19:50:15 CET] <furq> looks ok to me [19:50:17 CET] <furq> did you run make clean [19:51:04 CET] <Darby> but i want run it on another machine [19:51:28 CET] <furq> oh [19:51:35 CET] <furq> --extra-ldflags="-static" [19:52:24 CET] <Darby> only this furq? [19:52:53 CET] <furq> should be [19:52:58 CET] <furq> you can check what these are using [19:53:04 CET] <furq> https://www.johnvansickle.com/ffmpeg/ [19:57:11 CET] <Darby> i have compiled it from myself because i need something of more [19:57:27 CET] <furq> i mean you can check what config flags those builds are using [19:57:51 CET] <Darby> ahhhh thanks :) [19:57:53 CET] <furq> i forget if you need -static-libgcc -static-libstdc++ on linux [19:58:36 CET] <Darby> what must i add? [19:58:53 CET] <Darby> both -static-libgcc -static-libstdc++ [19:58:58 CET] <furq> i don't know [19:59:15 CET] <furq> you need those for mingw, i don't remember if you need them for linux [19:59:23 CET] <furq> those go in --extra-ldflags [20:08:56 CET] <thebombzen> Darby: furq: it's generally not recommended to compile -lc or -lstdc++ statically [20:09:22 CET] <furq> it is on mingw [20:09:22 CET] <thebombzen> because every Linux system is going to have libc and libstdc++, and compiling those statically makes it less portable [20:09:38 CET] <thebombzen> same with -lz and -lm etc. [20:09:46 CET] <thebombzen> well yea on mingw [20:09:48 CET] <furq> and i've never bothered building static for linux because distro packages are fine [20:09:59 CET] <furq> hence my advice to check the builds of someone who knows what they're doing [20:10:05 CET] <thebombzen> building static for linux seems silly to me tbh [20:10:21 CET] <furq> it makes sense if your distro isn't as good as mine [20:10:33 CET] <thebombzen> "distro isn't as good as mine" [20:27:42 CET] <relaxed> I started the linux static builds because people used to come in here all the time with an ancient version trying to get support. [20:53:25 CET] <dl2s4> hi, best command to downsample a flac 24bit to 16bit. best compression? [20:58:29 CET] <relaxed> dl2s4: try, ffmpeg -i input.flac -sample_fmt s16 -c:a flac -lpc_type 3 -lpc_passes 8 -lpc_coeff_precision 0 -prediction_order_method 5 -min_partition_order 1 -max_partition_order 8 output.flac [21:00:22 CET] <relaxed> that gave me the best compression from a particular sample, your results may vary [21:01:11 CET] <furq> is that better than -compression_level 12 [21:02:09 CET] <relaxed> hmm, "ffmpeg -h encoder=flac" doesn't list -compression_level so I never tried it [21:03:24 CET] <furq> apparently it is [21:04:04 CET] <furq> with that said the difference between no options other than -c:a flac and flac -8 is a couple of kbps [21:04:41 CET] <relaxed> Yeah, I just checked the source [21:06:11 CET] <dl2s4> thanks [21:06:43 CET] <relaxed> from what I remember ffmpeg's flac gave me better compression than `flac` [21:07:02 CET] <furq> yeah it does [21:07:07 CET] <furq> it's not enough to write home about though [21:08:44 CET] <Darby> thanks thebombzen, have you some help for me? [21:08:46 CET] <furq> i wonder if those settings are generating non-subset files [21:08:48 CET] <dl2s4> oh why ffmpeg is better? [21:10:07 CET] <relaxed> -compression_level 12 compressed better than my command :) [21:24:16 CET] <blue_misfit> hey guys, any advice on using -shortest? I've got a video that has 60ms more audio than video and I want to clip it down to make the audio match the video [21:24:38 CET] <blue_misfit> when I add -shortest prior to the output options I still get an output with an audio track that's 60ms longer than the video [22:30:00 CET] <Darby> furq now don't compile more [22:30:36 CET] <durandal_1707> ? [22:31:06 CET] <DHE> libavcodec: so there's an AVCodecContext field 'channels' that you should be able to set and force the number of output channels you want in your output, right? like if the input is surround but I request stereo, I get only stereo out. right? [22:31:13 CET] <Darby> i have added only --extra-ldflags="-static" and now i have this message: /usr/bin/ld: cannot find -lchromaprint [22:31:36 CET] <DHE> Darby: you need the ".a" version of libraries for static linking, not the .so files. a lot of distributions don't ship a full set [22:32:16 CET] <Darby> DHE i use Debian Jessie [22:32:21 CET] <durandal_1707> DHE: no, downmixing is made with swresample [22:32:56 CET] <DHE> durandal_1707: this has worked in the past. but I've made a lot of code changes and maybe it's my fault. [22:33:12 CET] <durandal_1707> it never worked [22:33:25 CET] <c3r1c3-Win> Does the 'abuffer' filter still exist by that name? [22:33:26 CET] <Darby> how can i compile a really static binary? [22:33:48 CET] <Darby> without shared [22:33:49 CET] <DHE> Darby: you need the .a files for all the features you're using. or you have to strip out features you can't find static components for. [22:34:36 CET] <Darby> how can i use .a files? [22:34:37 CET] <durandal_1707> c3r1c3-Win: why you need it? [22:35:12 CET] <Darby> where can i found those files? [22:35:49 CET] <c3r1c3-Win> durandal_1707: Yes. Trying to call it via avfilter_get_by_name("abuffer"), I get a NULL on return [22:35:54 CET] <DHE> Darby: that's up to your distribution. for fedora and most other RPM based distro look for package names with "-static" in the suffix. eg: zlib-static [22:36:23 CET] <Darby> many thanks DHE [22:36:45 CET] <Darby> now i do a search [22:37:12 CET] <durandal_1707> c3r1c3-Win: its still available [22:38:04 CET] <durandal_1707> what ffmpeg version you use? [22:38:40 CET] <c3r1c3-Win> durandal_1707: Hmm. . not sure. Letme find out (It's a precompiled build by the project head for Windows releases. [22:39:21 CET] <c3r1c3-Win> avfilter.dll is version 6.73.100.0 [22:39:38 CET] <DHE> durandal_1707: just figured it out. I'm also feeding it AAC audio instead of AC3, and AC3 does support in-codec downmixing but AAC does not... [22:40:11 CET] <furq> Darby: -dev packages on debian should have static libs [22:40:22 CET] <furq> if they don't then you need to build the libs yourself or just build ffmpeg without them [22:41:01 CET] <DHE> or ask someone who does have them to build you a static version. I have a gentoo system just for static building (gentoo has static libs for almost everything) [22:41:28 CET] <Darby> furq i have installed libchromaprint-dev [22:41:32 CET] <durandal_1707> c3r1c3-Win: what compile flags? perhaps it got disabled [22:41:52 CET] <c3r1c3-Win> That I don't know. I'll see if I can find out. [22:42:50 CET] <Darby> without --extra-ldflags="-static" i can compile ffmpeg, with it i have /usr/bin/ld: cannot find -lchromaprint [22:43:13 CET] <durandal_1707> c3r1c3-Win: abuffer should be build unconditionally [22:43:40 CET] <durandal_1707> meaning you dont need to register it [22:44:13 CET] <c3r1c3-Win> That's what I thought, but when calling it I get NULL back. [22:45:08 CET] <c3r1c3-Win> Everything in the code links and I get no compile-time errors (this is on Windows 10 running vs2015). [22:50:20 CET] <durandal_1707> c3r1c3-Win: do you call avregister_filter_all before? [22:51:23 CET] <c3r1c3-Win> No. The first call is to avfilter_graph_alloc (which clears), and then I call avfilter_get_by_name("abuffer"). [22:51:56 CET] <durandal_1707> call it first before anything else [22:54:07 CET] <c3r1c3-Win> The build flags for ffmpeg are as follows: [22:54:08 CET] <c3r1c3-Win> ./configure --enable-memalign-hack --enable-gpl --disable-doc --arch=x86_64 --enable-shared --enable-nvenc --enable-libx264 --enable-libopus --enable-libvorbis --enable-libvpx --disable-debug --cross-prefix=x86_64-w64-mingw32- --target-os=mingw32 --pkg-config=pkg-config --prefix="/home/me/packages/win64" --disable-postproc [22:55:04 CET] <c3r1c3-Win> durandal_1707: I'll insert said call first. Thanks! [22:57:51 CET] <c3r1c3-Win> durandal_1707: Is "avregister_filter_all" an actual function? [22:58:43 CET] <durandal_1707> see doc/examples in source code [22:59:30 CET] <durandal_1707> yes it is function [22:59:40 CET] <durandal_1707> no arguments [23:01:20 CET] <DHE> Darby: are you okay with a version of ffmpeg without chromaprint ? [23:02:19 CET] <Darby> i have tryed to delete chromaprint but after i have issue with libass [23:02:48 CET] <Darby> --extra-ldflags="-static" don't work for me [23:02:56 CET] <furq> https://packages.debian.org/stretch/amd64/libass-dev/filelist [23:03:00 CET] <furq> that should be fine [23:03:22 CET] <furq> libchromaprint-dev doesn't have a static lib, so you should report that as a bug i guess [23:04:12 CET] <furq> to debian, in case that wasn't clear [23:04:22 CET] <Darby> i have it https://packages.debian.org/jessie/amd64/libass-dev/filelist [23:05:51 CET] <Darby> collect2: error: ld returned 1 exit status [23:05:51 CET] <Darby> ERROR: libass not found using pkg-config [23:06:01 CET] <furq> what does config.log say [23:06:38 CET] <Darby> ok i have erased chromaprint and tryed to compile again [23:06:52 CET] <Darby> this is my config.log [23:07:36 CET] <Darby> https://clbin.com/SOVuI [23:08:25 CET] <furq> /usr/bin/ld: cannot find -lenca [23:08:26 CET] <furq> /usr/bin/ld: cannot find -lfribidi [23:08:31 CET] <relaxed> you're going to need to compile a static libass along with static libs it depends on [23:08:48 CET] <Darby> https://packages.debian.org/jessie/amd64/libenca-dev/filelist [23:09:09 CET] <Darby> here i can't find static library [23:09:12 CET] <furq> there isn't one [23:09:57 CET] <c3r1c3-Win> durandal_1707: Hmm... I just cloned the repo and did a search through all of the code and can't find anything that mentions avregister_filter_all [23:09:59 CET] <Darby> ok chromaprint and libass i must compile from myself, right? [23:11:01 CET] <durandal_1707> c3r1c3-Win: in doc/examples [23:12:07 CET] <durandal_1707> c3r1c3-Win: avfilter_register_all [23:12:23 CET] <c3r1c3-Win> durandal_1707: Searched there, nothing. [23:12:46 CET] <c3r1c3-Win> Ah! Thank you! [23:15:13 CET] <livingbeef> I'm converting image sequence into webm (vp9) and when I use -lossless 1 about 11 (from 36 total) frames at the end is dropped. Is that normal? [23:16:11 CET] <livingbeef> Just ommiting `-lossless 1' fixes it, but I'd like the losslessness [23:18:51 CET] <livingbeef> (ffmpeg 3.2.2, libvpx 1.5.0) [23:24:52 CET] <c3r1c3-Win> durandal_1707: Thanks again! [23:26:05 CET] <livingbeef> It seems like -quality best might work - after it finishes rendering at whopping 0.1fps [23:30:33 CET] <livingbeef> though quality-wise, it's awful... if you know any fix, I'll appreciate it [00:00:00 CET] --- Sat Feb 25 2017

1 0

ffmpeg-devel.log.20170223
by burek 24 Feb '17

24 Feb '17

[00:05:55 CET] <funman> kierank: sure but why? [00:07:14 CET] Action: funman reads thread [00:08:37 CET] <kierank> They are misunderstanding the things purpose [00:09:36 CET] <funman> please remind me tomorrow, i don't have my second factor at hand [00:09:43 CET] <funman> so no github [00:10:02 CET] <kierank> Ok [00:12:09 CET] <cone-439> ffmpeg 03Carl Eugen Hoyos 07master:6a22d2459d2c: lavd/opengl_enc: Fix a typo. [00:15:56 CET] <sfan5> sent a fixed rtmpdh patch [00:16:31 CET] <sfan5> apologies if i didn't reply correctly, i wasn't subscribed prior to sending the initial mail so i didnt manage to figure out how to reply properly [00:52:18 CET] <llogan> sfan5: you can always reply via the archives. just click on the email address link and it will include the In-Reply-To info [00:52:36 CET] <llogan> https://lists.ffmpeg.org/pipermail/ffmpeg-devel/ [02:39:20 CET] <cone-439> ffmpeg 03Jacek Manko 07master:c10455644897: avcodec/mips/Makefile: corrected conditional build of version 1 of vc1dsp optimizations for loongson mmi [02:39:21 CET] <cone-439> ffmpeg 03Michael Niedermayer 07master:9568b2e425f1: avcodec/h264_ps: Check chroma_qp_index_offset [03:11:50 CET] <DHE> I'm going to be making a local mod to ffmpeg and wondering if it makes sense to upstream. Basically I have an application that receiver over-the-air streams which sometimes changes stream layout (number of streams, metadata) and I need to be made aware of when this happens [03:12:20 CET] <DHE> to that end, I intend to add something to the AVProgram structure that changes to clearly indicate the stream information has changed for that program. thoughts? [06:09:44 CET] <cone-761> ffmpeg 03Rick Kern 07master:dcd3418a35aa: lavc/videotoolboxenc: check for dictionary key symbols [06:18:36 CET] <wm4> DHE: probably? we already have something for changing metadata [06:34:22 CET] <wm4> also hi Compn [06:50:51 CET] <Compn> wm4 : did you send mail to konst ? [06:50:58 CET] <Compn> or find a russian ? [06:52:01 CET] <Compn> i didnt get a reply from lnoor, so ping him on github maybe [06:52:11 CET] <wm4> sent mail to both, no reply [06:52:47 CET] <Compn> the two mplayerxp devs too ? [06:53:49 CET] <Compn> obviously that would be the first place you started... [06:57:50 CET] <wm4> the mplayerxp one and the beye one [07:02:44 CET] <Compn> anyone else you are looking for ? [07:03:06 CET] <Compn> i finished looking for nick's nickname in google, no luck finding any posts from him after 2010 [07:03:28 CET] <wm4> no, dead-end for me [07:06:52 CET] <Compn> wm4 : can you replace anything of what he wrote with anything from mplayerg2? it was lgpl iirc... although unfinished [07:08:21 CET] <wm4> is that available anywhere? but the problem is mostly not real code, but that it was replaced by other code during refactoring, which probably makes the copyright stick [07:08:28 CET] <wm4> anyway that's offtopic on this channel [07:09:36 CET] <Compn> yea [07:09:52 CET] <Compn> i still suggest you ask someone who speaks russian to help, they might have better idea where/how to search [07:10:18 CET] <Compn> cant remember if atomnuker was russian or not [07:10:22 CET] <Compn> thresh in vlc maybe [07:10:24 CET] Action: Compn afk [07:11:20 CET] <atomnuker> bulgarian, even though I somewhat know russian I wouldn't know where to look [07:15:02 CET] <Compn> wm4 : 2 more devs to ask, benjamin zores and mans from vidix project https://sourceforge.net/p/vidix/wiki/Home/ [07:17:03 CET] <Compn> and of course zdenek if you havent asked him yet [07:17:33 CET] <wm4> I asked zdenek and konstantin [07:26:02 CET] Action: Compn sleps [11:03:04 CET] <jkqxz> Can you delay frame output for arbitrarily long in H.265? (E.g. a sequence P 9001*B P, with all of the B frames referring to the two P frames, and the second P frame gets output at the end.) [11:05:08 CET] <wm4> I was under the impression that it's limited to 16 frames like in h264, but OTOH I have no clue [11:07:20 CET] <nevcairiel> i'm sure there is a max dpb size as well [11:07:49 CET] <nevcairiel> oh waits thats not that [11:07:56 CET] <nevcairiel> who knows then [11:08:16 CET] <jkqxz> That never gets exceeded here. I've deliberately chosen my example so that only the delay gets arbitrarily large. [11:09:16 CET] <jkqxz> And yeah, I was under the impression it was 16, too. But the standard is very opaque in this area... [11:19:07 CET] <rcombs> isn't the hard-maximum DPB size defined by the field used to reference a coded picture being 4 bits wide [11:19:16 CET] <rcombs> I might be making that up but I'd kinda assumed that was how it worked [11:23:15 CET] <jkqxz> It's up to 16 bits (fixed by an SPS parameter) for POC, which gives a somewhat larger limit. [11:24:40 CET] <jkqxz> Also you can duck the use of POC for reference pictures by using long-term pictures instead. [11:26:02 CET] <jkqxz> And long-term pictures can indeed be kept for arbitrarily long. My question, then, is whether you can set them to be output after an arbitrarily long delay. [12:04:24 CET] <rcombs> if you do I'll tell you you should probably put an IRAP somewhere [12:17:16 CET] <jkqxz> I think someone making a stream with 9001 B frames between every two P frames has worse problems than that. [12:19:10 CET] <wm4> yet someone will do it [12:20:14 CET] <Chloe> Are there more people on ffmpeg-security yet? [12:20:46 CET] <rcombs> if I'm on there then it's very quiet [12:22:14 CET] <Chloe> rcombs: you actually got added then? [12:22:22 CET] <rcombs> no idea [12:22:52 CET] <Chloe> michaelni: is anyone else on ffmpeg-security yet? [12:27:18 CET] <michaelni> Chloe, the list of members of the ffmpeg-security alias is in the MAINTAINERs file [12:27:27 CET] <DHE> <wm4> DHE: probably? we already have something for changing metadata # Oh? I didn't see anything in my searches, short of doing exhausting checking of parameters for changes [12:27:49 CET] <wm4> DHE: only for AVStream.metadata or such [12:31:48 CET] <Chloe> michaelni: wm4 or kierank weren't added? [12:33:51 CET] <DHE> wm4: so you suggest clearing the dictionary and waiting to see if it comes back with data? [12:33:52 CET] <michaelni> Chloe, iam talking with wm4 about that ATM. [12:34:05 CET] <Chloe> ok :) [12:35:13 CET] <wbs> sfan5: I had a look at your rtmpdh patch; it seems pretty close to what I did in libav in october already. have a look at 016387fe0fe3eff1a03ec0673bf4d2967f6cad94. I noticed a few minor details, like where I changed an av_malloc into av_mallocz (I tested my change with valgrind) [13:12:28 CET] <sfan5> wbs: indeed very similar; i have no idea about libav* internals so changing some malloc call didn't occur to me and i just wanted something that works anyway [13:13:33 CET] <sfan5> however whether the struct is zero'd before use (= overwriting the individual components) shouldn't make a difference anyway [13:15:05 CET] <nevcairiel> i kinda prefer the static functions over those defines with a ret parameter [13:16:51 CET] <nevcairiel> all in all i would just cherry-pick wbs' patch, also avoids having to deal with differences in a future merge [14:54:51 CET] <DHE> wm4: looks like it's not going to work the way I thought, but at the same time ffmepg doesn't provide what I want... [15:05:26 CET] <wm4> DHE: what was that again? [15:05:38 CET] <wm4> I think I only meant it as suggestion how the API could be extended [15:06:10 CET] <nevcairiel> DHE: you should talk to JEEB, he also wanted some ways to communicate changes in stream layout [15:06:38 CET] <JEEB> I haven't gotten to design it yet [15:07:11 CET] <DHE> wm4: yeah, I'm dealing with mpegts (over the air) channels that change streams. ffmpeg doesn't really announce these updates beyond adding new streams as needed. but what I've discovered is that the old streams may not be deleted. [15:07:41 CET] <JEEB> but yeah, programs and their updates should be replicated to API clients [15:07:53 CET] <JEEB> DHE: ah, ë(comrade) [15:08:07 CET] <nevcairiel> ffmpeg isnt really designed for all the weird concepts the japanese put into their broadcast [15:08:10 CET] <DHE> yeah it's me again. [15:08:15 CET] <nevcairiel> a more specialized component may be more fitting =p [15:08:15 CET] <DHE> :) [15:08:15 CET] <JEEB> nevcairiel: not limited to that [15:08:22 CET] <JEEB> BBC also does PID switches [15:08:36 CET] <JEEB> and Finnish DVB gets and loses tracks all the time [15:08:48 CET] <DHE> there's a multicultural channels here that will switch between english and portugese (that I've seen) and then my program goes up in flames [15:08:57 CET] <JEEB> Tokyo MX's video PID switches were the most funky though [15:09:16 CET] <DHE> seriously considering forcing a complete AVFormatContext reset when that happens. [15:09:38 CET] <nevcairiel> cant force that internally, that would break all sorts of things [15:16:46 CET] <wm4> AVStreams can't be deleted [15:16:56 CET] <wm4> except of course when the user closes the context [15:23:44 CET] <DHE> well, in the case of mpegts I think I have a hack. While I can't deleted AVStreams, it can delete the AVProgram listing and recreate it. so rather than looking at the AVSstreams directly I can use the AVProgram list as a stream reference to skip unwanted streams [15:24:13 CET] <DHE> so my program will have to check for the program stream index count and actual array contents for changes. which isn't too bad... [15:24:43 CET] <JEEB> hmm [15:24:51 CET] <JEEB> will have to check AVProgram [15:26:41 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:f06294726144: avcodec/qdrw: do better w/h parsing for direct bit packing [16:43:39 CET] <kierank> wm4: did you get added to security [17:05:47 CET] <wm4> kierank: no idea [17:23:26 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:fd7af82c53ea: avcodec/scpr: do not allow out of array access for 16bit case [17:25:49 CET] <michaelni> wm4, we just talked about it and i was waiting for your reply on what to put in the patch to the MAINTAINERs file for you in the ffmpeg-security entry [17:26:16 CET] <michaelni> so you are not on ffmpeg-security currently but once such patch is applied i add you [17:26:48 CET] <wm4> michaelni: ok, if has to be that way [17:26:51 CET] <michaelni> note i do not oppose adding "wm4" in there [17:27:12 CET] <michaelni> people wanted the list to be public [17:27:19 CET] <michaelni> the list of people that is [17:27:39 CET] <michaelni> wm4, ok so what should i put in the patch ? [17:28:13 CET] <wm4> michaelni: wm4 is fine [17:28:19 CET] <michaelni> ok [17:42:01 CET] <atana> michaelni, ping [17:42:30 CET] <michaelni> atana, hi [17:42:57 CET] <atana> michaelni, did you check the repo? any comment? [17:44:11 CET] <michaelni> atana, iam just looking now [17:44:17 CET] <atana> ok [17:54:50 CET] <michaelni> atana, you can replace all count = count + 1; by count++ similarly any other x = x+1 [17:55:13 CET] <atana> ok [17:59:25 CET] <michaelni> atana, also instead of prev_songid and prev_matchtime its easier to use p->mi[i-1] i think [18:51:12 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:95a5af446bd2: avcodec/scpr: check that current row is in valid range [19:34:52 CET] <tmm1> jkqxz: does vaapi deinterlace+encode work with the latest patch, or is that still a known issue [19:47:26 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:45ed942e7e16: avcodec/scpr: improve check for out of range motion vectors [20:07:01 CET] <jkqxz> tmm1: With Mesa? No, it still doesn't. That's just a Mesa problem, though. [20:14:11 CET] <tmm1> ah ok, misunderstood the old thread then [20:14:13 CET] <tmm1> thanks [20:19:44 CET] <jkqxz> It works cleanly on both Intel platforms (i965 and iHD). [20:38:29 CET] <llogan> jkqxz: do you think "[PATCH] omx: Add support for specifying H.264 profile [v4]" is acceptable? a user asked how to set profile for this encoder and i remembered this patch. [20:44:03 CET] <jkqxz> llogan: Oops, I forgot about that one. [20:45:26 CET] <jkqxz> No, because it still sets the profile explicitly to high if the user doesn't pass anything, which will fail on implementations which don't support that. [20:45:54 CET] <nevcairiel> gotta have some default profile, but main is probably better then high [20:47:10 CET] <jkqxz> No. Just don't set it (as happens now) and the openmax implementation chooses whatever it supports. [20:47:29 CET] <nevcairiel> i see [20:51:16 CET] <cone-087> ffmpeg 03Lou Logan 07master:f5fa12d6eefe: doc/filters: mention 'ffmpeg -filters' in timeline section [20:59:27 CET] <durandal_1707> kierank: do you have apple intermediate codec binary? [21:01:28 CET] <kierank> No but can be found I guess [21:57:28 CET] <jkqxz> wm4: Do you want to say anything else about the VAAPI interlacer? If you're happy with it then I'd just push it. [21:58:45 CET] <jkqxz> Um, *deinterlacer. [21:59:05 CET] <jkqxz> I like to think that I'm not quite insane enough to make new interlaced videos. [22:00:15 CET] <wm4> the only thing that sticks out is the duplication of the vaapi pipeline setup code that the vaapi scaler also has [22:00:19 CET] <wm4> but I guess it's fine [22:00:50 CET] <wm4> does it have an "interlaced frames only" mode like vf_yadif.c? [22:06:56 CET] <jkqxz> The filter just feeds in the frames and magic happens. [22:09:02 CET] <jkqxz> It doesn't obviously do horrific things to progressive frames, though. [22:15:13 CET] <wm4> well it's still your choice what to do with it (or whatever to feed progressive frames to it in the first place) [22:16:21 CET] <jkqxz> They would still need to be copied to make them end up in the right hardware frames context. [22:18:23 CET] <wm4> that's lame [22:19:30 CET] <jkqxz> Such is the price of abstraction. [22:19:52 CET] <jkqxz> (It probably all works anyway if you don't, but that would be Very Naughty.) [22:21:11 CET] <wm4> time for a hw->hw frame copy function? [22:24:58 CET] <jkqxz> Maybe av_hwframe_map() could do it? Mapping to another frames context on the same device could decide whether it's ok to just rename the frame, allocating a new one and copying if necessary. [22:25:54 CET] <wm4> no idea, it basically hangs on the hw_frames_ctx pointer, doesn't it [22:26:09 CET] <wm4> a bit weird that it has to be the same for a filter pad [22:26:16 CET] <wm4> even if the format is the same [22:26:23 CET] <BtbN> vaapi frames have a hard dependency on the hw_frames_context? [22:26:36 CET] <BtbN> For cuda the context does not matter at all anymore after the frame is created [22:26:46 CET] <BtbN> Only the CUDA context needs to match [22:26:57 CET] <jkqxz> The sameness requirement only actually matters if you pass it to something else which cares. [22:27:13 CET] <nevcairiel> most hw frames at least belong to a device, in some cases even a frame pool [22:27:17 CET] <wm4> which filters do (currently) [22:27:21 CET] <jkqxz> hwmap to QSV requires it, say. [22:27:55 CET] <BtbN> yeah, but the pool deallocation is handled by the frame itself [22:27:58 CET] <jkqxz> Nothing as currently in ffmpeg, I think. [22:28:00 CET] <wm4> jkqxz: so I'm not sure how mapping would solve it... wouldn't that make one frame pool reference another one? [22:28:02 CET] <BtbN> one doesn't need the context for it [22:28:36 CET] <jkqxz> I'm only speculating on overloading mapping to do it, because it's kindof a map operation. [22:29:04 CET] <jkqxz> And it's a single-frame-map, so the pool references wouldn't be changing. [22:29:06 CET] <nevcairiel> also cuda frames are only so independent because of the way you make them, you practically allocate a plain memory buffer and copy into it, its not really related to any video-specific function anymore at that point =p [22:29:24 CET] <jkqxz> As BtbN says, the pool doesn't matter for the deallocation. [22:29:42 CET] <BtbN> Yeah, a cuvid-frame would be much more sophisciated [22:29:52 CET] <BtbN> which actually has a map and unmaps on free [22:30:27 CET] <BtbN> But even that only depends on the CUDA context to be the same [22:30:51 CET] <nevcairiel> an actual cuvid frame needs to lug around the decoder reference to access it [22:31:04 CET] <BtbN> Not to access it, but to free it [22:31:33 CET] <BtbN> it's just mapped to a normal cuDevicePtr [22:32:04 CET] <nevcairiel> you really shouldnt keep it mapped all the time though [22:32:18 CET] <nevcairiel> a cuvid frame is safer as decoder+index [22:32:21 CET] <nevcairiel> and m apped when needed [22:32:32 CET] <BtbN> Yeah, carrying around a mapped cuvid frame would be kind of crazy [22:32:46 CET] <BtbN> which is why it's just copied to normal device memory [22:33:25 CET] <BtbN> In general cuvid frames would be insane, as I don't see a way to properly ensure the decoder doesn't reuse an index before the frame using it is freed [22:35:00 CET] <jkqxz> If only there were some way to deal with the frame management yourself... [22:35:26 CET] <BtbN> Even then it would still be insane [22:35:35 CET] <BtbN> Makes for funny deadlocks [22:35:54 CET] <BtbN> something waiting on more input frames, while the decoder is waiting on free output frames [22:38:10 CET] <BtbN> I like the way the CUDA frames work right now. It's quite fault tolerant and easy [22:38:16 CET] <BtbN> And not noticably slower [22:49:45 CET] <jamrial> https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html [23:03:37 CET] <cone-087> ffmpeg 03Paul B Mahol 07master:20789372da91: avcodec/shorten: support decoding AIFF-C variant [23:14:04 CET] <durandal_1707> jamrial: on what they loose cpu cycles [23:19:38 CET] <cone-087> ffmpeg 03Mark Thompson 07master:359586f14f46: lavfi: Add VAAPI deinterlacer [00:00:00 CET] --- Fri Feb 24 2017

1 0

ffmpeg.log.20170223
by burek 24 Feb '17

24 Feb '17

[00:01:13 CET] <xhip> nice tips @furq [00:01:28 CET] <llogan> I believe you'll want linux-headers-*-raspi2 for mmal and libomxil-bellagio-dev for omx [00:02:39 CET] <xhip> I'm using this tut: http://www.jeffreythompson.org/blog/2014/11/13/installing-ffmpeg-for-raspbe… but using: "git clone git://source.ffmpeg.org/ffmpeg.git ffmpeg" and "make -j4" [00:02:47 CET] <xhip> is this right? [00:05:59 CET] <furq> llogan: you shouldn't need anything for omx [00:06:17 CET] <furq> just add --extra-cflags=/opt/vc/include/IL [00:06:19 CET] <furq> er [00:06:24 CET] <furq> --extra-cflags=-I/opt/vc/include/IL [00:06:50 CET] <xhip> I'm downloading the lastest code [00:06:54 CET] <furq> assuming you get your kernel with rpi-update [00:07:13 CET] <llogan> ah, ok. i only did a search for what packages owned the required headers on a vanilla debian arm [00:07:33 CET] <xhip> I tried using arecord and it works.. so the mic is working.. now I need to re-make and see if it works with ffmpeg [00:08:21 CET] <furq> xhip: get rid of --arch=armel as well [00:09:12 CET] <xhip> so: sudo ./configure --enable-gpl --enable-libx264 --enable-nonfree -enable-omx-rpi --enable-mmal [00:09:21 CET] <furq> sure [00:09:29 CET] <furq> although you're not going to be using x264 on a pi, and there's no need for nonfree [00:09:38 CET] <furq> basically get rid of pretty much everything that tutorial tells you to do ;_; [00:09:56 CET] <xhip> :) [00:10:13 CET] <furq> i'm not sure what you'll need for mmal, but ./configure --enable-omx-rpi --enable-mmal --extra-cflags=-I/opt/vc/include/IL [00:10:37 CET] <xhip> Unknown option "-enable-omx-rpi" [00:11:16 CET] <xhip> my bad [00:11:21 CET] <furq> oh nvm you don't even need the --extra-cflags [00:11:31 CET] <furq> that should just work out of the box [00:11:37 CET] <xhip> I forgot to copy a "-" [00:12:20 CET] <xhip> so: sudo ./configure --enable-gpl --enable-omx-rpi --enable-mmal [00:12:30 CET] <furq> i don't think you need enable-gpl [00:12:51 CET] <xhip> :) ok I'll try using only: so: sudo ./configure --enable-omx-rpi --enable-mmal [00:13:02 CET] <furq> looks good to me [00:13:12 CET] <furq> like i say, check that alsa shows up in the configure output [00:13:33 CET] <furq> and also use -c:v h264_omx instead of -c:v mpeg4 when encoding [00:13:40 CET] <xhip> do I need to >> to a file so I can grep ? [00:13:59 CET] <xhip> is h264_omx faster? [00:14:00 CET] <furq> devices show up at the bottom iirc [00:14:09 CET] <furq> and yeah h264_omx is the pi's hardware h264 encoder [00:14:15 CET] <xhip> ohh cool [00:14:16 CET] <furq> mmal is the hardare decoder [00:14:26 CET] <furq> you won't be able to do much on a pi without those [00:14:58 CET] <llogan> why are you using sude for configure? [00:15:01 CET] <llogan> *sudo [00:15:10 CET] <furq> yeah don't do that [00:15:12 CET] <xhip> again tutorial :) [00:15:13 CET] <furq> sudo is only for make install [00:15:24 CET] <llogan> craptorial [00:15:40 CET] <furq> i don't think i've ever seen anyone link a good tutorial in here [00:15:48 CET] <furq> even the ones on the ffmpeg wiki are suspect [00:15:59 CET] <xhip> yeh thats why I'm saving your tips on a note [00:16:11 CET] <llogan> which ones and what's wrong with them? [00:17:55 CET] <furq> mostly the streaming stuff is a mess [00:18:13 CET] <furq> https://trac.ffmpeg.org/wiki/CompilationGuide/Ubuntu [00:18:20 CET] <furq> this one is ok but seems overcomplicated [00:18:29 CET] <furq> but then i'm generally pretty cavalier about throwing stuff in /usr/local [00:18:40 CET] <furq> it's debian, that's what /usr/local is for [00:18:53 CET] <furq> it's not the worst thing in the world to avoid that though [00:19:47 CET] <xhip> Enabled indevs: alsa... Enabled outdevs: alsa ... [00:19:53 CET] <furq> looks good [00:20:18 CET] <furq> llogan: https://trac.ffmpeg.org/wiki/CompilationGuide/RaspberryPi [00:20:24 CET] <furq> this one's not great [00:20:27 CET] <llogan> oh, that... [00:20:29 CET] <xhip> now I need to cook it :) make -j4 [00:20:53 CET] <llogan> and yeah, the "StreamingGuide" is just a stream of conciousness from rogerpack [00:20:55 CET] <furq> tbh considering how much time i spend in here telling people how to do this, it'd probably save me time to rewrite it [00:21:05 CET] <llogan> that would be nice [00:21:08 CET] <furq> but then i'd have nothing to do at work [00:21:17 CET] <xhip> ahah [00:22:03 CET] <xhip> btw any good tutorial how to stream it? using ffmpeg? rstp? or using netcat? :) [00:22:15 CET] <furq> most people are using nginx-rtmp for streaming [00:22:24 CET] <furq> by "most people" i mean most people in here who have hobbyist setups [00:22:48 CET] <xhip> :) cool [00:22:53 CET] <xhip> btw: "src_movie.c:524:9: warning: avcodec_decode_video2 is deprecated (declared at ./libavcodec/avcodec.h:4857) [-Wdeprecated-declarations] ret = avcodec_decode_video2(st->codec_ctx, frame, &got_frame, pkt);" [00:22:57 CET] <xhip> this is ok right [00:23:15 CET] <JEEB> xhip: it will work, it just means that that thing is using a deprecated API [00:23:16 CET] <furq> if you start pasting in all the warnings you'll be here all night [00:23:16 CET] <xhip> I'm getting some deprecated msgs [00:23:25 CET] <furq> as long as they're warnings and not errors, it's fine [00:23:29 CET] <JEEB> if it's during building of FFmpeg itself, yes that's OK [00:23:30 CET] <xhip> ok ok [00:23:41 CET] <JEEB> if you make an app yourself and you start getting those you will need to look into it [00:25:06 CET] <llogan> the ubuntu guide originally installed to /usr/local, and even integrated into package management system w/ checkinstall, but that led to other issues that the "local, not-really-installed" current method avoids. also, it is overly complicated to support all currently supported versions of ubuntu (i'm looking at you, old yasm). could be much simpler if it only targeted latest release. [00:25:26 CET] <JEEB> checkinstall is godawful [00:25:31 CET] <furq> tbh i think my objection to that ubuntu guide is that it doesn't recommend just debootstrapping debian testing into a chroot and installing the libs that way [00:25:34 CET] <JEEB> I've used it in some cases but it makes me cry [00:25:48 CET] <furq> since i would definitely have a testing/sid chroot if i was stuck on an old ubuntu [00:26:07 CET] <JEEB> or just newer ubuntu since it's branched off of one of those anyways [00:26:10 CET] <JEEB> every 6 months [00:26:12 CET] <furq> but then if you're going to do that you might as well just install ffmpeg in there [00:26:17 CET] <llogan> that too seems overcomplicated [00:26:26 CET] <furq> probably [00:26:32 CET] <llogan> so i just tell users to go to relaxed page [00:26:34 CET] <furq> it saves rebuilding all the libs though [00:26:46 CET] <furq> although yeah, if you don't need fdk then that page is pointless anyway [00:26:47 CET] <JEEB> systemd-nspawn is pretty simple, at least simpler than a lot of those chroot applications [00:27:00 CET] <JEEB> which was funny [00:27:11 CET] <furq> JEEB: i'm thinking of people who are stuck on an ubuntu lts for some reason [00:27:20 CET] <JEEB> which would be 16.04 nowadays [00:27:32 CET] <furq> 14.04 is still supported for a couple more years isn't it [00:27:35 CET] <JEEB> (and yes, I have some 14.04 machines under my administration) [00:27:43 CET] <JEEB> (and yes, I fucking hate it) [00:27:54 CET] <furq> didn't 12.04 only just get EOLed [00:27:54 CET] <thebombzen> perhaps "the latest release" and then every LTS release [00:27:55 CET] <JEEB> as someone who writes services [00:28:01 CET] <JEEB> furq: yea [00:28:04 CET] <JEEB> that's even worse [00:28:09 CET] <furq> yeah fuck that [00:28:13 CET] <thebombzen> 1404 is pretty sucky [00:28:16 CET] <JEEB> thebombzen: VLC does latest LTS [00:28:23 CET] <furq> debian stable is bad enough and that's only a couple of years old [00:28:24 CET] <JEEB> they stopped it from building on 14.04 [00:28:27 CET] <furq> imagine using a distro from 2012 [00:28:35 CET] <thebombzen> Imagine using an OS from 2001 [00:28:46 CET] <furq> is this a windows xp joke [00:28:49 CET] <thebombzen> It is [00:28:57 CET] <JEEB> furq: I remember seeing a 10.04 server once and quickly checked the network graph. and then promptly shut the fucker down [00:28:59 CET] <llogan> people still ask zeranoe why his builds won't work on XP no mo' [00:29:17 CET] <JEEB> oh of course, I once for shits and giggles in like 2013 built FFmpeg for win2000 [00:29:20 CET] <JEEB> it was god-awful [00:29:32 CET] <thebombzen> win2000 and winxp are sort of the same, right? [00:29:33 CET] <xhip> btw this is not a 100% ffmpeg question.. but I never saw answer to this problem... So "can I use python to get a img from a webcam and still use it for video stream.. same time?" just a curiosity [00:29:36 CET] <JEEB> thebombzen: no [00:29:37 CET] <thebombzen> it's NT5 vs NT5.1 [00:29:46 CET] <JEEB> xp sp2 and newer have a lot of better APIs [00:29:52 CET] <thebombzen> ah sp2 and sp3 [00:30:07 CET] <thebombzen> also, re: 1404, I used to use Linux Mint a few years ago when it was based on 1404 [00:30:09 CET] <furq> i built lua with turbo c 2.0 once [00:30:10 CET] <furq> does that count [00:30:11 CET] <thebombzen> I ended up getting fed up with it [00:30:24 CET] <thebombzen> cause it was so awful [00:30:35 CET] <thebombzen> I switched to Arch and now I feel like I actually have control over my OS [00:30:35 CET] <JEEB> yes, the further you go from the release date of the LTS the more the downstream distro has to package shit or feel like shit [00:30:41 CET] <furq> i briefly used LMDE [00:30:44 CET] <furq> that seemed sort of ok [00:30:51 CET] <furq> although at that point you might as well just use debian [00:31:09 CET] <JEEB> also mint officially doesn't support upgrades, so I'd just much rather use mint's cinnamon desktop on a vanilla ubuntu [00:31:18 CET] <JEEB> and upgrade every 6 months [00:31:24 CET] <thebombzen> yea Mint really was a pos [00:31:48 CET] <thebombzen> the two main advantages it had over Ubuntu were that it packaged MATE and proprietary drivers like nvidia [00:31:58 CET] <JEEB> uhh, ubuntu also packages nvidia drivers [00:32:05 CET] <thebombzen> if they do that's new [00:32:08 CET] <JEEB> it even asks you during/after install [00:32:10 CET] <JEEB> uhh [00:32:14 CET] <JEEB> at least since 12.03 [00:32:16 CET] <JEEB> *04 [00:32:19 CET] <JEEB> if not before [00:32:19 CET] <thebombzen> oh lol [00:32:34 CET] <thebombzen> I hate "modern DEs" tho so the MATE was enough [00:32:39 CET] <thebombzen> but given that I can do both on Arch, and I actually have control over my system, it's nice [00:32:49 CET] <thebombzen> I feel that "control of my system" is really not something I should be worried about [00:32:55 CET] <thebombzen> but Ubuntu just feels so hacked together [00:33:04 CET] <llogan> i prefer arch as well [00:33:06 CET] <JEEB> arch is something I happily leave to others who want to bite the bullet [00:33:18 CET] <JEEB> I'm OK following in the second chain for stuff I don't develop [00:33:43 CET] <thebombzen> with Ubuntu, I feel that, half of it is a direct copy of upstream, and half of it is LSB but mangled by canonical for no good reason [00:34:03 CET] <thebombzen> it's extremely difficult to tell on Ubuntu what will work exactly like other distros and what will work nothing like other distros [00:34:07 CET] <JEEB> thebombzen: ok, it was 12.04 it seems unless they're now hiding older versions' packages http://packages.ubuntu.com/precise/nvidia-current [00:34:13 CET] <thebombzen> at least on Arch, the documentation of the quirks is really good [00:34:21 CET] <furq> arch has a good wiki [00:34:28 CET] <furq> and uh [00:34:29 CET] <llogan> except their ffmpeg page [00:34:29 CET] <thebombzen> yea that's the best part of it [00:34:29 CET] <furq> it's not gentoo [00:34:36 CET] <furq> those are two good things i can say about arch [00:34:43 CET] <JEEB> yes, the arch wiki has some good stuff even if you're not on arch [00:34:44 CET] <thebombzen> FFmpeg wiki pages are sucky 100% of the time [00:34:49 CET] <thebombzen> including the FFmpeg's trac wiki [00:34:54 CET] <JEEB> yup [00:35:06 CET] <furq> i use the arch wiki a lot and i've never used arch [00:35:07 CET] <thebombzen> yea but Arch has really good documentation and that's I think one of its biggest benefits [00:35:14 CET] <llogan> i cleaned up some of the arch ffmpeg wiki page once but some mod or whatever bitched so i reverted it [00:35:31 CET] <thebombzen> depends on what you "cleaned up" [00:35:34 CET] <thebombzen> if you changed the style they won't like that [00:35:38 CET] <xhip> I'm watching other video tuts on ffmpeg and maybe I'll try to convert a cvlc comand into ffmpeg [00:35:44 CET] <thebombzen> if you just fix information to make it accurate according to the downstream package that should be fine [00:35:45 CET] <xhip> cvlc -vvv v4l2:///dev/video1:chroma=mjpg :input-slave=alsa://hw:2,0 --sout "#transcode{vcodec=mp1v,vb=4096,acodec=mp3,ab=128,scale=2,channels=2}:rtp{dst=10.10.12.1,port=8080,sdp=rtsp://10.10.12.1:8080/cam.sdp}" [00:35:49 CET] <thebombzen> (which is 3.2.? at this point) [00:35:54 CET] <furq> it's good about mentioning "hey if you have x installed then this won't work, you have to do this instead" [00:36:00 CET] <furq> which is the single most annoying thing about desktop linux [00:36:07 CET] <thebombzen> oh yea pacman is great [00:36:08 CET] <JEEB> xhip: sout in vlc is godawful, but do remember that shit like broadcast inputs can actually work better in vlc [00:36:12 CET] <llogan> i mostly got rid of retarded examples [00:36:14 CET] <furq> i mean the wiki [00:36:34 CET] <thebombzen> oh yea it does that [00:36:44 CET] <JEEB> I should probably go looking into how to handle PID switches in libavformat... [00:36:47 CET] <furq> that is especially useful for people on other distros [00:36:50 CET] <thebombzen> "You can't use a swap file on Btfs, use ext4 or a swap partition instead [00:37:01 CET] <thebombzen> but yea telling you when something won't work is really nice [00:37:15 CET] <thebombzen> "you need to do this with GPT or it own't work" [00:37:38 CET] <furq> stuff like "if you're running gnome 3 then you can't put this in .xinitrc, it has to go in /etc/gnome/piss.rc" [00:37:47 CET] <furq> paraphrased [00:37:58 CET] <xhip> @JEEB my problem is always cpu and network.. I want to keep it fast (cpu lower and still a good video) but the codecs.. [00:38:20 CET] <xhip> I still need to learn the best one (quality/cpu) [00:38:33 CET] <furq> xhip: your only real option on the pi is h264_omx [00:38:36 CET] <furq> that won't touch the cpu at all [00:38:53 CET] <xhip> yeh thats tru [00:38:56 CET] <furq> if you mean on a real computer then x264 pretty much always wins [00:39:07 CET] <xhip> but that cvlc thing is on a debian machine [00:39:09 CET] <thebombzen> furq: unless you're encoding losslessly, then nvenc is nice [00:39:24 CET] <xhip> but still the cpu is weak.. so [00:39:28 CET] <thebombzen> but on rpi software encoding is too slow tbh [00:40:03 CET] <xhip> ...still "compiling" the "make" [00:40:20 CET] <furq> i still occasionally run x264 576p downscales on my nas, which is a core 2 duo at stock clocks [00:40:32 CET] <furq> it'll do realtime at 576p with -preset fast [00:40:55 CET] <thebombzen> with x264 I usually use -preset slow with -crf rather than -preset veryslow [00:40:55 CET] <xhip> no 720p? :) [00:40:56 CET] <furq> you'd need a really bad cpu to not be able to get realtime with x264's fast presets [00:41:07 CET] <furq> unless it's 4k or something [00:41:16 CET] <thebombzen> the file size will be larger but I don't have the patience [00:41:26 CET] <furq> i don't actually use -preset fast fwiw [00:41:45 CET] <thebombzen> furq: 60fps 1080p high-motion content can be hard to encode realtime if generated by a videogame [00:41:59 CET] <thebombzen> simply because the game already is using your cpu [00:42:07 CET] <thebombzen> so you generally use ultrafast there [00:42:22 CET] <furq> yeah but most people who are encoding that aren't encoding 1080p60 because it's going to twitch and they have a 3.5mbit bandwidth limit [00:42:29 CET] <furq> so 1080p60 is going to look like piss [00:42:33 CET] <thebombzen> yea [00:42:43 CET] <thebombzen> 720p30 is better for that [00:42:55 CET] <thebombzen> I record to youtube private streams when I play vidya [00:43:02 CET] <thebombzen> waste their harddrive space, not mine [00:43:16 CET] <furq> what i do, and this is pretty revolutionary, is i play games and don't record myself doing it [00:43:23 CET] <thebombzen> haha [00:43:30 CET] <thebombzen> sometimes it's nice to send a clip to someone [00:43:40 CET] <thebombzen> I don't have an egotistical "I want people to watch me play for hours" idea [00:43:45 CET] <furq> i am sort of lying tbh [00:43:51 CET] <furq> i play a lot of games which have server-side demo recording [00:43:59 CET] <thebombzen> but parsing through 2 hours of gameplay video is annoying tbh [00:44:04 CET] <thebombzen> recently I've just been using OBS's replay buffer feature [00:44:12 CET] <furq> shadowplay seems nice but i've never really used it [00:44:13 CET] <thebombzen> where it keeps like 1-minute encoded buffer [00:44:28 CET] <thebombzen> and then by hotkey it can dump the 1-minute buffer to a file [00:44:48 CET] <thebombzen> it'll be like 500 mb but you can downscale the filesize with x264 easily [00:45:25 CET] <furq> it would have been nice to have recordings of the actual world records i have set in games [00:45:43 CET] <furq> yeah that's right. you're looking at a world record holder, in the prestigious field of the race mode in "rock of ages" [00:46:16 CET] <furq> yes, it does have that mode [00:47:02 CET] <thebombzen> what is "rock of ages" [00:47:11 CET] <thebombzen> is that like a game with a boulder [00:47:18 CET] <thebombzen> that withstands the test of time [00:47:37 CET] <furq> yes [00:47:39 CET] <furq> it is literally that [00:48:01 CET] <furq> also apparently i'm not the world record holder any more because someone has hacked their way to the top of all the leaderboards [00:48:19 CET] <furq> i still have the fastest time that isn't obviously fake [00:48:52 CET] <thebombzen> I don't have world records... I just record myself doing stupid overwatch brawls [00:49:04 CET] <thebombzen> and if something cool happens I send a video of it to my friends [00:49:25 CET] <thebombzen> who are like "haha" and then it's over [00:50:04 CET] <furq> is overwatch the one which is team fortress 2 with butts [00:50:14 CET] <thebombzen> Yes [00:50:26 CET] <thebombzen> even the guys have butts [00:50:33 CET] <furq> progressive [00:58:18 CET] <kerio> wait, nvenc can do lossless x264? [00:58:58 CET] <thebombzen> no, nvenc can do lossless H.264 [00:59:03 CET] <kerio> er yes [00:59:03 CET] <thebombzen> -preset lossless [00:59:56 CET] <thebombzen> furq is there a way to get your bot to do !encoder=h264_nvenc [01:00:15 CET] <xhip> ok done installing [01:01:21 CET] <thebombzen> I guess it doesn't matter because NVENC isn't mentioned on ffmpeg-codecs.html [01:02:12 CET] <xhip> btw what is the best audio codec for the pi? [01:02:18 CET] <JEEB> whatever runs fast enough [01:02:23 CET] <kerio> is h264_omx even usable [01:02:30 CET] <thebombzen> kerio: nothing else is [01:02:30 CET] <xhip> ffmpeg -f alsa -i plughw:1 -ar 22050 -ab 64k -strict experimental -acodec aac -y test.wav [01:02:43 CET] <llogan> you won't need -strict experimental [01:02:46 CET] <JEEB> I remember people with rpi1 just not being able to encode aac with the software encoder :D [01:02:47 CET] <thebombzen> you don't need -strict experimental anymore [01:02:47 CET] <kerio> yeah but i thought that copying stuff to and from the gpucore was slow as well [01:02:51 CET] <xhip> It's working :D [01:03:12 CET] <xhip> ok I've got some: [01:03:14 CET] <thebombzen> also libopus is still ffmpeg's best lossy audio encoder [01:03:14 CET] <xhip> Non-monotonous DTS in output stream 0:0; previous: 10170, current: 10067; changing to 10170. This may result in incorrect timestamps in the output file. [01:03:17 CET] <xhip> but looks fine [01:03:17 CET] <thebombzen> ignore that. [01:03:20 CET] <furq> thebombzen: if it's not on ffmpeg.org then no [01:03:43 CET] <furq> it literally just dumps the toc from the online docs [01:03:50 CET] <llogan> what bot? [01:03:54 CET] <nfobot> furq: Available functions: muxer demuxer encoder decoder filter source sink indev outdev protocol bsf [01:03:56 CET] <furq> that one [01:04:07 CET] <furq> !indev alsa [01:04:07 CET] <nfobot> furq: http://ffmpeg.org/ffmpeg-devices.html#alsa [01:04:19 CET] <thebombzen> why would it not be on ffmpeg.org? I thought that ffmpeg-*.html was generated from the same documentation as ffmpeg -h [01:04:21 CET] <thebombzen> but I guess I'm wrong [01:04:28 CET] <thebombzen> !encoder h264_nvenc [01:04:31 CET] <llogan> it is not [01:04:39 CET] <xhip> hmm.. [01:04:48 CET] <thebombzen> xhip: you should use libopus if you can [01:05:07 CET] <thebombzen> like if you can do the computation in realtime [01:05:13 CET] <thebombzen> it's got the best audio quality of all the lossy encoders [01:05:18 CET] <thebombzen> (especially at 64k) [01:05:18 CET] <furq> xhip: if you do end up using rtmp then your only option is aac [01:05:36 CET] <xhip> furq.. not for now.. [01:05:37 CET] <thebombzen> but you should consider using libfdk-aac because then you can use HE-AAC [01:05:41 CET] <furq> it should be fine on a pi 2 [01:05:44 CET] <xhip> I just want to record webcam [01:05:45 CET] <thebombzen> which is the best for rtmp [01:05:46 CET] <xhip> with audio [01:06:00 CET] <thebombzen> then libopus gives the best audio quality [01:06:07 CET] <xhip> without killing my pi and disk [01:06:32 CET] <thebombzen> well given that you're setting the bitrate, libopus @ 64k outperforms everything else @ 64k as long as you can do it in realtime [01:06:33 CET] <furq> he didn't build with libopus anyway [01:06:41 CET] <thebombzen> well then you should lol [01:06:46 CET] <furq> just use aac [01:07:04 CET] <xhip> weird.. I can't open that file.. let me try record another one [01:07:06 CET] <xhip> ffmpeg -f alsa -i plughw:1 -ar 22050 -ab 64k -strict experimental -acodec aac -y test.wav [01:07:08 CET] <xhip> using this [01:07:17 CET] <furq> don't use wav for aac [01:07:19 CET] <furq> use m4a [01:07:22 CET] <xhip> ok [01:07:45 CET] <xhip> "size= 79kB time=00:00:10.04 bitrate= 64.1kbits/s speed=0.994x" [01:07:47 CET] <xhip> looks fine [01:07:47 CET] <furq> also get rid of -ar 22050 and -strict experimental [01:07:49 CET] <xhip> let me see [01:07:53 CET] <xhip> ok [01:08:15 CET] <xhip> test2: ffmpeg -f alsa -i plughw:1 -ab 64k -acodec aac -y test2.m4a [01:08:52 CET] <xhip> 10/10 :D [01:09:24 CET] <xhip> now "all together now" :D [01:11:23 CET] <xhip> so: ffmpeg -f v4l2 -s 960x720 -i /dev/video0 -f alsa -i plughw:1 -ab 64k -acodec aac -y test3.mkv [01:11:29 CET] <xhip> should I use -r to lock fps [01:11:36 CET] <furq> no [01:11:38 CET] <xhip> ok [01:11:40 CET] <furq> use -framerate before -i [01:11:57 CET] <furq> also you need to add -c:v h264_omx [01:12:22 CET] <furq> and add -b:v 2000k or whatever you want the video bitrate to be [01:12:43 CET] <xhip> added [01:13:56 CET] <xhip> there is any good calculation.. to see how much space do 1h of recording... do. [01:14:27 CET] <furq> https://www.google.co.uk/search?q=2000%20kilobits%20per%20second%20*%201%20… [01:14:38 CET] <xhip> bitrate hm I only used that on streams.. never to record.. I'm going to add that to my command for now [01:14:53 CET] <xhip> oh ok that simple [01:16:13 CET] <xhip> how abou the file extension.. is mkv ok? [01:17:15 CET] <furq> sure [01:18:31 CET] <xhip> ffmpeg -f v4l2 -s 960x720 -c:v h264_omx -b:v 2000k -i /dev/video0 -f alsa -ab 64k -acodec aac -i plughw:1 -y test3.mkv [01:18:33 CET] <xhip> hm [01:18:39 CET] <xhip> Option b:v (video bitrate (please use -b:v)) cannot be applied to input url /dev/video0 -- you are trying to apply an input option to an output file or vice versa. Move this option before the file it belongs to. Error parsing options for input file /dev/video0. [01:29:03 CET] <furq> those are output options [01:30:35 CET] <xhip> so after the -y [01:31:44 CET] <thebombzen> xhip: the way ffmpeg works is all options before "-i input" are input options [01:31:58 CET] <thebombzen> and everything after all of the "-i input" are output options [01:32:18 CET] <xhip> Ok [01:32:34 CET] <thebombzen> so for you it's ffmpeg <video_input_options> -i videoinput <audio_input_options> -i audioinput <output_options> output [01:32:54 CET] <thebombzen> -b:v is the bitrate for the encoder, and it's an output option [01:34:36 CET] <xhip> ffmpeg -f <audio options> -i plughw:1 -f <video opts> -i /dev/video0 -y test3.mkv <output: -b:v 2000k -b:ad 64k > [01:37:26 CET] <thebombzen> you have to put the output options before the output file [01:37:46 CET] <thebombzen> and not inside angled brackets :P [01:37:57 CET] <xhip> lol [01:38:08 CET] <xhip> yeh [01:38:11 CET] <xhip> ffmpeg -f alsa -acodec aac -i plughw:1 -f v4l2 -s 960x720 -c:v h264_omx -i /dev/video0 -b:v 2000k -b:a 64k -y test3.mkv [01:38:34 CET] <furq> how did -acodec aac get there [01:38:47 CET] <thebombzen> yea why is it way over there [01:38:59 CET] <xhip> is a input flag right [01:39:10 CET] <thebombzen> no, you're specifying what codec you're coverting the input to [01:39:19 CET] <thebombzen> input options specify extra data about the input [01:39:26 CET] <thebombzen> that the input wouldn't otherwise know [01:39:37 CET] <thebombzen> same with h264_omx [01:39:40 CET] <thebombzen> that's an output option [01:39:51 CET] <thebombzen> also, use -video_size not -s [01:40:29 CET] <xhip> ffmpeg -f alsa -i plughw:1 -f v4l2 -video_size 960x720 -i /dev/video0 -c:v h264_omx -c:a aac -b:v 2000k -b:a 64k -y test3.mkv [01:40:36 CET] <xhip> on nice is working [01:41:06 CET] <xhip> "Non-monotonous DTS in output stream 0:1; previous: 16709, current: 16569; changing to 16709. This may result in incorrect timestamps in the output file." "ALSA buffer xrun" [01:41:10 CET] <xhip> but looks fine [01:41:31 CET] <xhip> "time=00:00:55.41 bitrate= 956.8kbits/s speed=1.04x" [01:41:51 CET] <xhip> ok stoped. lets see the video :) [01:44:54 CET] <xhip> its working video and audio :) [01:45:38 CET] <xhip> btw: [01:45:40 CET] <xhip> [aac @ 0x2a82790] Queue input is backward in time0:00:21.02 bitrate=1030.5kbits/s speed=1.26x [01:45:40 CET] <xhip> [matroska @ 0x2a7f890] Non-monotonous DTS in output stream 0:1; previous: 21848, current: 21430; changing to 21848. This may result in incorrect timestamps in the output file. [01:46:15 CET] <xhip> is this ok.. or should I try to fix it? [01:49:51 CET] <thebombzen> don't worry about that [02:09:39 CET] <xhip> I'm testing some configs.. [02:10:05 CET] <xhip> but my audio is still weird.. I can hear it but is all mess'y [02:10:31 CET] <xhip> maybe I need to play with -b:a 64k [02:26:43 CET] <xhip> no luck [02:31:17 CET] <mixfix41> hmm ive rebuilt ffmpeg 3.2.3 on my slackware system using oss ( i need it for a game) but I ve been having to restart my computer for ffplay to play smoothly, i recently updated my slackware system but before the update everything was good, then they integrated ffmpeg witht he main core packages, and I rebuilt the package for ffplay and a few other codecs/libraries to record sound and desktop... hmm mplayers [02:31:20 CET] <mixfix41> and other sound work good [02:32:53 CET] <xhip> I made this script to help me with the settings http://pastebin.com/61wfVjvS [02:33:03 CET] <xhip> but no luck on the audio [02:34:03 CET] <xhip> resolution* [02:44:31 CET] <mixfix41> xhip: which architech is that on [02:44:39 CET] <xhip> arm [02:44:41 CET] <xhip> (pi) [02:45:13 CET] <xhip> hm [02:45:15 CET] <xhip> Stream mapping: [02:45:15 CET] <xhip> Stream #1:0 -> #0:0 (rawvideo (native) -> h264 (h264_omx)) [02:45:16 CET] <xhip> Stream #0:0 -> #0:1 (pcm_s16le (native) -> aac (native)) [02:45:50 CET] <xhip> so he isn't using my usb mic [02:47:27 CET] <xhip> hm.. nvm [02:47:33 CET] <xhip> I try audio only and works.. [02:47:48 CET] <xhip> giving the same msg: Stream mapping: [02:47:48 CET] <xhip> Stream #0:0 -> #0:0 (pcm_s16le (native) -> aac (native)) [02:49:34 CET] <xhip> maybe is the pi that can't handle this.. [02:49:41 CET] <xhip> [aac @ 0x2469790] Queue input is backward in time0:00:09.24 bitrate= 79.6kbits/s speed=1.31x [02:50:07 CET] <mixfix41> which one [02:50:09 CET] <Diag> 79.6kbps? [02:50:10 CET] <xhip> [alsa @ 0x2459370] Thread message queue blocking; consider raising the thread_queue_size option (current value: 8) [02:51:39 CET] <xhip> my audio bitrate is -b:a 64k [02:52:37 CET] <atomnuker> xhip: try -aac_coder fast [02:52:44 CET] <xhip> ok [02:56:27 CET] <mixfix41> actually did you get audio stream to function good somewhere else, thats impressive i know I had the mpd http stream function on and that would bog my raspberry pi b+ model [02:56:50 CET] <xhip> when I ask for audio only [02:56:53 CET] <xhip> it works fine [02:56:59 CET] <xhip> but with video and audio [02:57:07 CET] <xhip> the audio is bugged [02:58:54 CET] <tatsuya> duranda_170! [03:00:09 CET] <xhip> #fml maybe I use 2 screen one for audio and other for video [03:04:30 CET] <mixfix41> do you think -thread_queue_size 1024 applies to your situation [03:05:13 CET] <mixfix41> nvm [03:06:22 CET] <xhip> https://www.dropbox.com/s/hwc9udmyv36thix/output.mkv?dl=0 [03:06:23 CET] <xhip> sample [03:09:10 CET] <xhip> should I use -thread_queue_size 512 ? [03:11:08 CET] <fulcan> I am trying to broadcast a cam to ffserver https://bpaste.net/show/24bf9fbe31bb and unable to get a connection. http://persiaspalace.us:8090/feed1.ffm tcpdump port 8090 shows the cam transmitting just fine. [03:12:39 CET] <fulcan> https://bpaste.net/show/15c9b81ea7b7 [03:37:03 CET] <xhip> is this a good iadea? [03:37:05 CET] <xhip> arecord -f cd -D plughw:1,0 | ffmpeg -i - ... [03:53:47 CET] <xhip> with the pipe.. works [04:02:52 CET] <mixfix41> hmm ok with the ffplay issue, i restart my comp, and its not linked with oss just yet, i gotta turn off pulseaudio and i can turn it back on and things will begin to play but after restarting [04:03:41 CET] <mixfix41> maybe i should switch to alsa to see if I got issues with that to narrow this [04:04:07 CET] <mixfix41> but oss has been pretty solid though with mplayer and medal of honor [05:08:41 CET] <mixfix41> allr ight i think i dealt with my issue with ffmpeg building without libpulse then when my screenrecorder needs pulse it starts up ... [05:16:26 CET] <mixfix41> also if this works continuously i wonder why the sound conflict with ffmpeg when it starts instead when it starts with a different application [05:16:41 CET] <mixfix41> with pulseaudio starting that is [05:17:01 CET] <mixfix41> esp with oss sound [08:23:00 CET] <SouLShocK> http://pastebin.com/y6rLg06j produces an overlapping of the background boxes as shown in https://ibin.co/3DHDA1mTedBS.jpg how do I avoid that overlap? [10:12:33 CET] <termos> I get messages like these printing forever when ffprobing an rtmp flv stream: [flv @ 0x23b7bc0] Packet mismatch -553637295 11. Any ideas? [12:33:37 CET] <NotChuck> Hi guys, I'm building ffmpeg with cuvid support. In the nvidia site (https://developer.nvidia.com/ffmpeg) they recommend --enable-nonfree. Is this necessary for nvidia decoding? [12:44:35 CET] <jiyuu> hi [12:44:55 CET] <jiyuu> wanted to check something about the subtitles filter, is this the right place? [12:50:41 CET] <durandal_1707> jiyuu: yes [12:55:50 CET] <jiyuu> ok [12:55:53 CET] <jiyuu> so its like this [12:55:56 CET] <jiyuu> http://ffmpeg.org/ffmpeg-filters.html#subtitles [12:56:36 CET] <jiyuu> says that i can use the subtitle filter to read the parse the subtitles from the video file directly, but i am not clear from the doc if it will properly handle ass subtitles [12:57:06 CET] <jiyuu> secondly it seems like this approach does not handle embedded fonts as i get errors for them being missing [12:57:46 CET] <jiyuu> is there any way to have them available for ffmpeg other then adding a stop of extracting the fonts out of the file and into the fontpath? [13:11:59 CET] <SouLShocK> speaking of subtitles, http://pastebin.com/y6rLg06j produces an overlapping of the background boxes as shown in https://ibin.co/3DHDA1mTedBS.jpg how do I avoid that overlap? [15:25:42 CET] <colde> SouLShocK: there is no lineheight option? [15:45:33 CET] <fred1807> I was to convert some videos on the cloud, using ffmpeg. This requires some RAM to work softly, and more Ram makes vps servers price goes up. I am still learning the basics of it all, but it seems that I could use cloud computing in "pay as you go" fashion. Example, if I only convert 3 videos a day = a couple of minutes of real usage a day. So I can afford a powerfull cloud computing, to use it only a couple of minutes a day, and shut it down the rest of [15:45:33 CET] <fred1807> Am i right? Or there is no such service? [15:46:08 CET] <dystopia> aws maybe [15:51:56 CET] <furq> what are you encoding that needs a lot of ram [15:53:07 CET] <DHE> 1080p video with a large lookahead buffer may consume a lot of memory. that's tunable though [15:54:11 CET] <furq> unless you're encoding 4k or doing a lot of filtering you should be fine with 1GB [15:54:32 CET] <furq> and that costs very little [16:04:24 CET] <fred1807> I see [16:04:53 CET] <fred1807> encoding normal video, but I would be more confortable with 2gb, there is also backroung sync jobs runnings [16:06:09 CET] <DHE> doing what? an installed VM shouldn't have any big CPU users installed from the install media. disk indexing might be the biggest concern [16:06:55 CET] <furq> what's "normal video" [16:07:01 CET] <furq> i don't think i've ever seen a normal video [16:08:03 CET] <fred1807> ah, sorry, 720p to 1080p h264 "hd internet streaming birate" stuff [16:11:23 CET] <furq> ovh are doing 2GB for 3 EUR/month [16:13:48 CET] <DHE> still, I budget 1 gigabyte of RAM for my own such jobs and have no issues [16:14:18 CET] <DHE> on a system with only 1 GB you should be able to run 1 job with no troubles. with x264 encoder tuning (assuming you use H264) you can get that lowered [16:14:55 CET] <furq> well yeah i only mention that because that's the lowest plan ovh are doing [16:15:14 CET] <furq> and that's barely more than i pay for a box with 256MB [16:17:46 CET] <bencoh> reducing available memory sometimes mean you'll have to reduce threads number, though [16:18:01 CET] <furq> well it's a cheap vps so you're probably only going to have one [16:18:35 CET] <bencoh> ah, in that case... [16:19:57 CET] <fred1807> yes [16:32:16 CET] <madno> Hello. Is there any way to hide the mouse cursor when recording the desktop as a video in ffmpeg? I tried using :0.0+nomouse as was said in many places. But it doesn't work at all. I am using Linux. [16:35:05 CET] <c_14> madno: -draw_mouse 0 [16:35:48 CET] <c_14> https://ffmpeg.org/ffmpeg-devices.html#Options-19 [16:38:52 CET] <madno> c_14: Thank you! Is there any specific version for where this option is supported? I mean, it's supproted in all 3.x and higher too? [16:39:45 CET] <c_14> I think that one's pretty old [16:39:48 CET] <c_14> At least 3 [16:40:44 CET] <c_14> It's in 2.8 too [16:40:59 CET] <madno> Ahh. Thanks. [16:42:02 CET] <fred1807> can I run ffmpeg on aws lambda? [16:46:09 CET] <DHE> seems like research would be required. maybe? [16:47:50 CET] <DHE> "Maximum execution duration per request = 300 seconds" so I'm going to say no [16:54:55 CET] <kepstin> well, it should work fine as long as it finished in the time limit... [17:08:32 CET] <ChuckLePlant_> Hi, I'm building ffmpeg shared libraries with cuda support for windows. I get a message that it is not distributable [17:08:51 CET] <ChuckLePlant_> This is because of --non-free [17:09:10 CET] <ChuckLePlant_> But I do want to distribute my build, what can I do? [17:12:13 CET] <kepstin> ChuckLePlant_: don't use the "non-free" option? as far as I can tell, cuda doesn't require that [17:12:28 CET] <kepstin> I'm guessing you enabled fdk_aac or something, you can turn that off and just use the internal aac encoder. [17:12:40 CET] <ChuckLePlant_> It does apparently [17:12:58 CET] <ChuckLePlant_> I will double check [17:13:45 CET] <kepstin> the only things that require nonfree in the current ffmpeg source are libnpp, and (if you have gpl enabled), libfdk_aac and openssl. [17:14:40 CET] <ChuckLePlant_> it must be libnpp, from nvidia docs I thought it was required for cuvid and nvenc [17:17:14 CET] <kepstin> looks like that'll lose you exactly one thing, an npp scale filter [17:18:30 CET] <kepstin> https://www.ffmpeg.org/ffmpeg-filters.html#scale_005fnpp so I guess that'll reduce what you can do with your ffmpeg a bit [17:19:19 CET] <ChuckLePlant_> why are those non-free? Don't those have a similar nvidia eula? [17:20:06 CET] <ChuckLePlant_> thanks btw [17:20:09 CET] <kepstin> don't ask me :/ [17:20:48 CET] <ChuckLePlant_> oh, seems cuda is also non-free [17:22:02 CET] <kepstin> it shouldn't be, neither 'cuda' nor 'cuvid' trigger the nonfree license check in ffmpeg. [17:22:36 CET] <kepstin> (in the configure script) [17:22:49 CET] <furq> ChuckLePlant_: https://github.com/FFmpeg/FFmpeg/blob/master/configure#L5148-L5150 [17:23:36 CET] <ChuckLePlant_> I'm at n3.2.2, what is the latest stable commit/tag? [17:23:44 CET] <furq> i think the nvidia stuff is exempt because you're not distributing any nonfree code [17:23:49 CET] <furq> it loads the libs on the user's system [17:24:22 CET] <furq> and 3.2.4 is the latest [17:24:50 CET] <ChuckLePlant_> cheers [18:02:49 CET] <balint> Hi! I would like to use the ocr filter on ubuntu. What is the easiest way to get it runnig? I have tried apt-get ffmpeg, but that version doesnt contain the ocr filter. [18:04:51 CET] <balint> I have tried the current static build too. [18:10:12 CET] <balint> Do I need to compile it for myself? [18:12:44 CET] <durandal_1707> yes [18:21:31 CET] <SouLShocK> colde I was unable to find a line height option for the subtitle plugin [18:26:10 CET] <funyun> hi. can anyone help me with this error i get when trying to encode to level 5.2? http://pastebin.com/ke9pFz5E [18:43:46 CET] <funyun> i only get this error when adding "-profile:v high -level 5.2" [19:03:28 CET] <funyun> anyone use ffmpeg? [20:20:54 CET] <pgorley> hi, is there a way to convert a AVCodecContext to a AVCodecParameters and vice-versa without copying each field? [20:25:01 CET] <jkqxz> pgorley: You mean like a pair of functions, one for copying in each direction, say? <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/avcodec.h;h=925a8…> [20:25:30 CET] <pgorley> yes, thank you! :) [21:37:36 CET] <hassonofer> Is it possible to connect to RTSP stream with '@' symbol at the password, e.g. rtsp://username:pass@word@example.com:554 ? [21:38:18 CET] <tdr> you'd probably have to quote or escape it [21:49:56 CET] <kepstin> I'd think that URL-encoding it there would work find, so rtsp://username:pass%40word@example.com [00:00:00 CET] --- Fri Feb 24 2017

1 0