Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

January 2015

1 participants
62 discussions

ffmpeg-devel.log.20141231
by burek 01 Jan '15

01 Jan '15

[00:01] <BBB> iive: same answer as h264 decoder [00:01] <BBB> in general, for the plumbing bits, sure, yes [00:01] <BBB> for the stuff that actually does stuff (basically all dsp routines and the stuff calling them): no [00:02] <iive> how about moving the whole image 2 bits and hacking few parts here and there? [00:05] <iive> let's say that we implement 16bit decoding, can we use same routines for decoding all of the image. (ignoring speed concerns) [00:05] <iive> i mean, all of the bitdepths. [00:48] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:a288d08d84f6: avfilter/vf_cropdetect: adjust Default threshold based on bit depth [02:16] <BBB> iive: not that simple [02:16] <BBB> in the more general theoretical sense, yeah sure [02:16] <BBB> but in practice, it wouldnt make any sense [03:30] <cone-77> ffmpeg.git 03James Almer 07master:37b35feb64e4: x86/swr: add SSE2/AVX pack_8ch functions [03:34] <BBB> what is madvr [03:39] <jamrial> A renderer [03:40] <jamrial> really popular among those that watch anime, at least [03:40] <jamrial> http://forum.doom9.org/showthread.php?t=146228 [03:47] <Daemon404> i wouldnt call it really popular [03:47] <Daemon404> source: anime person [03:47] <Daemon404> it's the ricer of the renderer world [03:48] <Daemon404> (with it's "jinc" resize, which is dumb) [03:48] <Daemon404> its* [03:58] <kierank> wtf [03:58] <relaxed> ^^^ somewhat realistic bug report with a penis pump ad at the end. [03:58] <kierank> its a bot [03:58] <relaxed> I wonder if there's a bot cloning bug reports [04:02] <jamrial> and the BadContent list keeps growing [04:05] <Daemon404> i dont get why bots would spam bug trackers in the first place [04:10] <kierank> pagerank [04:10] <kierank> clicks [04:10] <kierank> etc [04:14] <c_14> Anybody know why the capabilities for ff_libx264_encoder don't include CODEC_CAP_FRAME_THREADS and CODEC_CAP_SLICE_THREADS ? [04:17] <Daemon404> because threading is provided by the library and not ffmpeg [04:17] <c_14> Just wondering because it makes `ffmpeg -h encoder=libx264' output that there are no Threading capabilities which can be misleading. [04:18] <Daemon404> it has CODEC_CAP_AUTO_THREADS set [04:18] <Daemon404> maybe the cli could be updated [04:20] <cehoyos> Hi! Before anybody asks: The two tickets that looked like normal invalid tickets (and contained real questions) both also contained spam links so I deleted them (and will ban the user). [04:27] <c_14> Daemon404: what kind of change are you envisioning? something like adding a fallthrough that maps CODEC_CAP_AUTO_THREADS to "auto" ? [04:39] <Daemon404> c_14, what? [04:40] <c_14> I'm trying to think of how best to get the cli to output the threading support for libx264 [04:41] <c_14> It currently uses a switch case to check which capabilities are enabled and then outputs "frame and slice", "frame", "slice", or "no" accordingly [05:06] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:d97b94f1af43: avcodec/loco: Support LOCO reference encoder with odd width [05:06] <cone-77> ffmpeg.git 03Michael Niedermayer 07master:037b527d6250: doc/filters: document bit-depth independent cropdetect limit [06:13] <aabuild> Hi [06:14] <aabuild> I have some question about build ffmpeg [06:15] <aabuild> enabled-pthreads vs enabled-w32threads vs both disabled (zaranoe default?) [06:15] <aabuild> what's better for encoding performance ? [06:21] <Tim_G> aabuild: w32threads should be a little better [06:21] <Tim_G> aabuild: never disable it [06:24] <aabuild> ok.. but I seen disable-w32threads in zaranoe build [06:24] <aabuild> any reason? [06:38] <Tim_G> aabuild: I think some time ago somebody did a benchmark on w32threads vs pthreads, and pthreads came out to be faster. Not sure if this is the case still though [06:38] <Tim_G> it's Zeranoe BTW and he sometimes hangs out in this chanel as well [06:59] <aetasx> pthreads is still screwed for ffmpeg without passing in a posix flag, dunno if its the same with w32 [07:07] <aabuild> hm.. I tried build with --enable-w32threads, then I get error "ERROR: libilbc not found" [07:13] <aabuild> no error when build with only --enalble-libilbc but error with --enable-w32thread , --enable-libilbc ... [07:13] <aabuild> I don't understand [07:18] <aabuild> ffmpeg developer in chat? [07:19] <aabuild> recently avira wrong virus detection on ffmpeg.exe [07:21] <aabuild> I tried upload to virus total, only avira detect TR/Crypt.XPACK.Gen2 on ffmpeg.exe [07:40] <anshul__> wm4: updated doc snippet here http://paste.ubuntu.com/9649287/ [07:48] <anshul_m> to not break ABI, do we have to change version number [08:00] <Tim_G> aabuild: can you show the relevant part of config.log [08:03] <anshul_mahe> I see in git log there were no other significant changes were done when adding parameter in AVCodec [08:06] <aabuild> Tim_G: That's ok :) just exclude libilbc. maybe I will not use libilbc [08:07] <aabuild> sorry but I have last question... [08:08] <aabuild> If build with --cpu=core-avx-i , [08:08] <aabuild> can I use that on athlon64 cpu or anohter old intel cpu? [08:10] <Tim_G> aabuild: most people don't use --cpu [08:13] <aabuild> yea I just wanted little more optimization for i7 avx cpu [09:16] <anshul_m> if I change some structure in AVCodec what version I need to increase, minor one or major one [10:06] <ubitux> anshul_m: you must not "change" fields unless you major bump, but you don't want to bump anyway, unless you macro protect (see FF_API* stuff) [10:06] <ubitux> if you add fields at the end that's fine [10:06] <ubitux> and you can just minor bump [10:10] <anshul_m> ubitux: thanks I will look at it, [10:11] <anshul_m> I am not planning to bump anything nither major not minor, till that patch get cleared with reviews [10:11] <anshul_m> since I dont what time it will take and there would be merge conflicts because of that [10:11] <anshul_m> *dont know [10:31] <j-b> 'lo [12:39] <wm4> does ffmpeg detect teletext .ts streams as mp3? [12:59] <funman> wm4: hm? [13:00] <funman> http://pastie.org/9806394 [13:00] <wm4> hm, maybe old versions did that [13:50] <pengvado> <BBB> some yasm macro to interleave the output of other macros [13:50] <pengvado> the only way I can think of is: add a mode to our instruction wrapper that appends the instruction to a yasm variable instead of actually emitting it. [13:50] <pengvado> but while appending works, I'm not sure if there's any way to split such a list again for interleaving. so rather that one variable, you might have to emulate arrays using a bunch of variables with the array index in the variable name. [14:04] <BBB> I could have a global that is the interleaving amount, right? [14:04] <BBB> like %interleave 2 [14:04] <BBB> macro [14:05] Last message repeated 1 time(s). [14:05] <BBB> and the second macro would then up the interleave_cycle from 1 to 2, which could be used as a condition to emit after append [14:05] <BBB> I guess that might be fun to try (helps atom etc.) [14:13] <BBB> maybe Ill try this [14:28] <wm4> does vp9 in avi exist? [14:28] <JEEB> ask the chinese [14:28] <wm4> ah yes it does [14:29] <wm4> ffmpeg supports it according to the riff tables [14:29] <wm4> head->table [14:33] <anshul_mahe> if some patch depend on other patch then do we have to metion in commit message or in mail while replying [15:06] <BBB> omg I love these emails [15:06] <BBB> dear sirs, were using ffmpeg and its not working, please fix asap important because were stuck midway!!12 [15:06] <j-b> "dear sirs, please go f**k yourselves" [15:07] <BBB> oh, also, we have ported ffmpeg to ios8 [15:07] <j-b> no way? [15:07] <BBB> his statement [15:07] <j-b> quite an achievement, sir [15:07] <BBB> We have tried porting FFMPEG to iOS 8.0 [15:08] <BBB> pls do the needful as we are stuck midway in the project [15:08] <BBB> do latest macbookpros have haswell? [15:08] <j-b> yes [15:09] <wm4> oh he said this literally: "pls do the needful as we are stuck midway in the project." [15:09] <j-b> they also have a overheating problem [15:09] <wm4> quite a thing [15:14] <compn> has there ever been a useful email that started with "dear sirs" ? [15:14] <BBB> I was mistaken, it said Dear Friends" [15:15] <BBB> Dear Friend," [15:15] <BBB> maybe I should get that new macbook so I can write avx2 [15:39] <ubitux> j-b: http://ifixit.org/blog/6882/why-i-drilled-holes-in-my-macbook-pro-and-put-i… ? [15:39] <ubitux> BBB: i can provide you a ssh on my laptop for avx2 [15:39] <ubitux> it's already available for jamrial and others [15:39] <BBB> nah I want my own :-p [15:40] <ubitux> okay [15:40] <BBB> whats the fun in writing avx2 if I cant run it myself [15:40] <ubitux> fine with me as well :) [15:40] <ubitux> well that's why i propose a ssh :p [15:41] <ubitux> BBB: btw, you didn't see the version where he gets crazy with caps lock on ffmpeg-user [15:41] <ubitux> BBB: https://ffmpeg.org/pipermail/ffmpeg-user/2014-December/024814.html [15:43] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:131a18582682: avcodec/loco: use enum for mode variable [15:43] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:5ba62e89dfca: avcodec/loco: check the init_get_bits8() return code [15:43] <BBB> :-o [15:44] <bencoh> wtf is this "port" [15:44] <ubitux> JUST HELP HIM NOW [15:44] <ubitux> Regards, [15:44] <bencoh> (and wtf with the mail) [15:44] <bencoh> haha [15:45] <BBB> bencoh: port for these kind of users means they RTFMed and figured out how to use a cross-compiler [15:45] <BBB> (for some, thats a miraculous accomplishment) [15:45] <bencoh> (huhu) [15:46] <compn> we really need some indian/hindi people in our project to help that side of our userbase. i think making fun of users isnt helping much :P [15:46] Action: compn trolls and runs [15:53] <anshul_mahe> compn: In India people gets job on there refrence basis, no one care if they have knowledge or not :( [15:55] <anshul__> may be I should take care while sending mails on devel list,name of my country is attached to it ;) [16:05] <anshul__> michaelni: I was looking for such review comment from start of that mail chain, thats why I didn't wrote decoder or encoder that time, for my first mail, bad about me was not explaining scte-35 and disscusing about it [16:06] <anshul__> Now I have to start from scratch again [16:06] <wm4> I still don't understand what's with that new public API function [16:13] <kierank> "do the needful" [16:15] <anshul__> wm4: I am trying to decode Data stream, since data streams does not have some generic output after decoding, therefore I have kept interface much abstract [16:16] <wm4> what does the "decoding" do? [16:16] <wm4> and why can't it happen in the demuxer? [16:16] <wm4> assuming it doesn't really decode, but rather unscramble weird stuff [16:17] <anshul__> In my SCTE-35, it tells the timing when adverisement start [16:17] <anshul__> and when they stop, And who are authorised to remove and put new add [16:17] <anshul__> *add = advertisement [16:18] <anshul__> Yes It unscramble the stuff, if its is unencrypted [16:19] <anshul__> michaelni gave me another idea to use AVformat Chapters for timing segmentation [16:20] <anshul__> instead of Data decoder and encoder pair [16:22] <BBB> I think the idea of generally decoding data into stuff is a little too abstract to be generally useful [16:23] <BBB> I mean, we could put video in data, or audio [16:23] <BBB> but we didn't [16:23] <BBB> why? [16:23] <BBB> so I think I agree with the general idea that we should not add an api for data, but rather have simpler one-offs that actually solve that one problem youre solving [16:24] <wm4> anshul__: for timed events, the chapter or subtitle API could do it [16:24] <wm4> maybe using chapters would be cleaner? but I don't know [16:25] <wm4> both could lead to very strange results when transcoding [16:26] <wm4> oh I know! side data! [16:27] <wm4> anshul__: you could attach unscrambled data as AVPacket.side_data [16:28] <anshul_m> wm4: and What about the idea of chapter in AVFormat context [16:29] <kierank> scte35 is not a chapter [16:29] <kierank> scte35 comes as and when, it's not a header at the beginning of a file [16:29] <kierank> so it's not a chapter [16:30] <anshul_m> kierank: something similar to chapter a new interface like chapter? [16:30] <wm4> I suppose using chapters was an idea of _somehow_ exporting the data [16:31] <kierank> you can do whatever but scte35 doesn't fit into the ffmpeg model [16:32] <wm4> so what _is_ scte35? [16:32] <kierank> it's some data that comes in a transport stream to signal that you need to splice local advertising in [16:32] <kierank> I have no idea what anshul_m is trying to do [16:32] <kierank> but clearly it hasn't been thought through [16:33] <BBB> side-sdata may be ok [16:33] <BBB> if its just some metadata, like a boolean signal [16:33] <kierank> it's not associated with any audio or video frame [16:33] <kierank> so it's not side data [16:34] <wm4> does it have a timestamp? [16:34] <BBB> it must have a timestamp [16:34] <anshul_m> yes its not sidedata we will loose it, by decode and encoder and will not have that data on muxer [16:34] <BBB> so it can probably be exported as timed metatadata (like chained ogg crap) in the demuxer [16:34] <wm4> then it could be a separate pseudo-stream [16:34] <wm4> wgich just returns scte35 packets [16:34] <BBB> although thats whacky [16:34] <anshul_m> yes it has time stamp [16:34] <kierank> anshul_m: time stamp relative to what? [16:34] <wm4> ogg metadata has no timestamps, at least not as exposed in ffmpeg [16:35] <anshul_m> but it does not have time stamp of its own packet [16:35] <anshul_m> it has timestamp of video frames [16:35] <BBB> no, but ogg files can have multiple chains each with their own metadata [16:35] <BBB> so by that logic, segments of ogg have metadata associated with them [16:35] <BBB> like segments of mpegts would have Im local advertisement boolean: true/false associated wtih them [16:35] <wm4> so what happens with ogg is that as soon as a packet _after_ the new metadata is returned, the metadata field is overwritten, and a change flag is set [16:35] <BBB> right? [16:36] <anshul_m> BBB: not exactly its not only boolean but lot more with taht [16:36] <anshul_m> *that [16:36] <BBB> wm4: so we could do that here also I suppose [16:37] <BBB> its still whacky [16:37] <wm4> also I'm not sure how this works with packet interleaving and parsing [16:38] <kierank> wm4: more importantly what does ffmpeg even plan to do with the scte35 data? [16:38] <anshul_m> Its have full specs about packet interleaving and parsing, they dont use PTS [16:38] <anshul_m> Its have full specs about packet interleaving and parsing, they dont use (sorry) PES [16:40] <anshul_m> kierank: I was thinking to write filter taking 2 input and use it to provide local advertisement [16:41] <wm4> kierank: dunno, isn't that up to users [16:41] <kierank> yeah so then just export it as some random data that's not audio and video [16:41] <kierank> nothing new there [16:41] <kierank> but anshul_m wants to put it in ffmpeg [16:41] <kierank> because ffmpeg needs to be the kitchen sink [16:41] <wm4> so what exactly does scte35 do? is it about _inserting_ new audio/video at a single point (like external ads), or is it _replacing_ audio/video (time range)? [16:42] <anshul_m> its _replacing_ audio/video (time range [16:43] <wm4> and does this scte35 thing announce the time range at once, or is it more like having start/end packets? [16:44] <anshul_m> it tell just before its time start and signal whenits end [16:44] <anshul_m> There are some implementation of scte35 where user can give when it start and the duration till it end [16:46] <anshul_m> kierank: In my current implementation I just exporting the data but not in random format, in xml format [16:46] <michaelni> the way i understand scte35, it marks a part of the stream (generally this is an advertisement IIUC) to allow it to be replaced by a localized advertisemnet, but the text i read said its also used fo other things [16:46] <wm4> anshul_m: why xml?? [16:47] <michaelni> from what i understand scte35 would be usefull to remove advertisements automatically [16:47] <anshul_m> wm4: for making the path complete, [16:47] <kierank> michaelni: no [16:48] <kierank> it's for inserting adverts and making sure remuxed streams also have the insertion markers [16:48] <anshul_m> kierank: why not [16:48] <kierank> it won't remove all the ads [16:48] <anshul_m> It depend on user how he want to use it [16:48] <kierank> because there are network advertisements and local advertisements [16:49] <anshul_m> What I understood was that scte35 is for replacing network advertisement to local advertisement [16:50] <kierank> what the feed would do is play network advertisements, send a scte35 message and go to black [16:50] <kierank> then send another scte35 message when it's done [16:51] <anshul_m> no its not like that, you can see the video in scte35 hls ticket [16:52] <kierank> why is it not like that [16:52] <kierank> hls will segment it fine [16:52] <anshul_m> it was never like that [16:52] <anshul_m> why means [16:52] <kierank> but in broadcast it's just spliced [16:53] <anshul_m> yes It have start and end time of advertisement [16:53] <kierank> ok [16:54] <kierank> i don't see what difference that makes [16:54] <anshul_m> Yes but there is never one broadcaster, it is captured and rebroadcasted again [16:54] <kierank> yes I said that [16:54] <kierank> "making sure remuxed streams also have the insertion markers" [16:55] <anshul_m> yes I will make sure if user wants it through option [16:55] <anshul_m> be right back [16:57] <kierank> anyway it should be dealt with at a level higher than ffmpeg.c [16:57] <kierank> I know some people here can't fathom this but it's not a bad thing to not have a feature in ffmpeg.c [16:59] <wm4> heretic! [17:00] <wm4> kierank: the problem is of course that ffmpeg.c does so much work, and there's no way to extend it from outside [17:00] <wm4> so there are 2 things possible: 1. hack it into ffmpeg.c, or 2. duplicate all the effort ffmpeg.c does in your own tool [17:00] <wm4> guess which one people will pick [17:01] <kierank> or god forbid build tools specialised for particular things [17:01] <kierank> if you need an ad inserter, build an ad inserter [17:01] <wm4> no, I'm just saying that the ffmpeg api is so low level, and that ffmpeg.c contains significant boilerplate etc. which deals with it [17:02] <wm4> in a better world, everything would be better (amen) [17:36] <anshul_m> I dont have any problem with 2nd option if my work was just to make adinserter [17:38] <anshul_m> So for conclusion can we have the implementation as it is, since chapter and sidedata dont work here [17:38] <wm4> IMO the cleanest would be exporting the scte stuff as packet on a special AVStream just for data [17:40] <anshul_m> But i need to change the data, since we cant use pts as it is,I need to accomadate it as it change in our ffmpeg [17:41] <kierank> why can't you use pts as it is? [17:41] <cone-469> ffmpeg.git 03James Almer 07master:5f14f9e98495: x86/swr: add missing alignment check to pack_6ch functions [17:42] <anshul_m> since we change the offset of video frame pts in ffmpeg [17:42] <wm4> you mean in ffmpeg.c? [17:43] <anshul_m> yes after transcoding we never get the same pts as in input stream [17:43] <wm4> well of course you need to handle this somewhere [17:43] <wm4> but it's not different from the other options, or is it [17:44] <anshul_m> didn't understood last line what is other options? [17:45] <wm4> like this special API that "decodes" packets [17:46] <anshul_m> are there some special api for "decodes" packets other then decode_video decode_audio and decode_sub? [17:47] <wm4> I mean the API introduced in your patch [17:48] <anshul_m> but where they will recide, decode_data with other decode_* would be good place? [17:49] <wm4> I meant that even with the special API your patch introduces, ffmpeg.c would have to do extra work to adjust the PTS values [17:50] <wm4> also: "With ffmpeg 2.5.2, Teletext-pid-data is still guessed as mp3 and then it complains that the mp3 header is missing in all packets. " [17:51] <anshul_m> i was thinking to add options in scte 35 decoder, which can change the offset of pts by scte [17:52] <anshul_m> so if we are changing pts that time we will change it for scte decoder [17:54] <anshul_m> What is register parser, and where do we use it [17:54] <wm4> that sounds worse [17:55] <anshul_m> I do need a place to store the offset PTS (may be in minus) for Scte [17:58] <wm4> what for? [17:58] <anshul_m> to update pts in scte35 packet [17:58] <wm4> as I imagine it, the user (ffmpeg.c in this case) should shift them [17:59] <anshul_m> but user will never know what ffmpeg has shifted [18:00] <anshul_m> ffmpeg has different sync algo as I have seen, which change pts differently [18:01] <anshul_m> some algo drop packets and keep pts same for keeping the bitrate [18:07] <kierank> anshul_m: what is this pts measured relative to [18:07] <kierank> it makes no sense it all [18:07] <kierank> wm4: no surprise [18:07] <kierank> lots of shit is misdetected as mp3 [18:07] <kierank> gotta break everything to fix some stupid file [18:07] <kierank> </troll> [18:08] <JEEB> I think it was the "no PMT" "fix"? [18:08] <kierank> lol no pmt [18:08] <kierank> what a joke [18:09] <JEEB> yes [18:09] <JEEB> I've seen someone whose receiver makes such dumps (except the PMT data at the beginning is dumped into a separate file), and told him to get better shit [18:09] <JEEB> I think it was one of the southern american countries [18:11] <anshul_m> pts is measured relative to video frame, means if changing the pts of video frame, then tell scte35 about it [18:11] <kierank> eugh [18:11] <kierank> but is the pts of the scte stream guaranteed to match a video frame [18:11] <kierank> or is it just a pts in the mpeg-ts "timeline" [18:12] <anshul_m> no its not guranteed but its practice told scte-67 spec [18:13] <kierank> I guess I'll find this all out one day when I implement it in my code [18:14] <anshul_m> or you could help me to implement this, then I could be some use 4 u [18:15] <kierank> I will be implementing the scte-35 insertion part on my side [18:16] <anshul_m> Should I belive that There is no way other then use libav api and implement own ffmpeg.c :( [18:19] <anshul_m> i could have made a patch for ffmpeg and used that, but changes are in so many places that struggle with merging it with ffmpeg development is horrific [18:20] <kierank> yes some things just don't fit in the ffmpeg paradigm [18:21] <Daemon404> it's not so bad if you use the API and implement it on the level above [18:21] <Daemon404> (usually) [18:21] <anshul_m> ok so we dissmiss this patch [18:21] <anshul_m> ? [18:22] <Daemon404> i havent looked at it, i have no opinion on the matter (and no context) [18:24] <kierank> anshul_m: well you can at least export the packets [18:24] <kierank> in a non-xml format [18:26] <anshul_m> those packet have no meaning and useless, since pts given by packet is not there in whole video [18:27] <anshul_m> I implemented that first, but it didn't work [18:28] <kierank> "not there in whole video"? [18:29] <anshul_m> means whole output video/audio does not have pts that are defined in scte packet [18:29] <kierank> so what does the pts represent? [18:30] <anshul_m> they are according to actual input, but pts are changed in ffmpeg [18:32] <kierank> changed how in ffmpeg? [18:34] <anshul_m> you should look at -vsync parameter of ffmpeg [18:35] <kierank> yes but in the api you don't have vsync [18:35] <kierank> so it doesn't matter [18:36] <anshul_m> yes That patch is draft just to start disscission about its implementation [18:36] <anshul_m> What eventually it will matter [18:37] <kierank> no because vsync is a feature only available in ffmpeg.c [18:38] <kierank> if you make scte-35 a feature that is not used in ffmpeg.c but only by api users then it's a non-issue [18:41] <anshul_m> but yet I have not understood what is the issue with it in ffmpeg.c, just people dont like it. that does not matter when they will find its application they will do it eventually [18:42] <anshul_m> is it breaking something that works now, or is it using some programming practice that is not used yet in ffmpeg [18:44] <kierank> because it's a mess [18:45] <kierank> ffmpeg.c is just full of undocumented hacks to make things work [18:45] <anshul_m> why I am taking responsibility of data streams, will be maintainer of it [18:46] <wm4> when will ffmpeg.c be in its own repo? [18:47] <anshul_m> isnt it now in its own repo? [18:48] <wm4> no it's in the ffmpeg repo [18:48] <wm4> together with the libs [18:48] <wm4> -> big mess [18:49] <wm4> and the devs are not forced to keep compatibility in a reasonable way [18:50] <anshul_m> so you all guys are discouraging to make that mess more big? [18:51] <Daemon404> ubitux, i see the fdk pkg-config thread exploded in exactly the wya i thought it would [18:51] <nevcairiel> we have like 3 of those in parallel now [18:52] <anshul_m> isn't we stick to c not cpp, I thought we encourage more about proceduere then objectivism [18:54] <anshul_m> I am really bad in understanding peoples feeling, I was here because I thought people prefer output then feeling of bad and good [19:00] <ubitux> Daemon404: haha [19:02] <Daemon404> i saw it before bed [19:02] <Daemon404> 0 replies [19:02] <Daemon404> looked in the morn, loled [19:03] <wm4> I too knew this would become funny [19:03] <wm4> it always goes this way [19:08] <Daemon404> wm4, im just surprised there isnt more carl [19:08] <wm4> I think he's starting to understand that everyone is against him in this matter [19:26] <j-b> not again the pkg-config discussion [19:26] <j-b> It's amazing how obtuse some people are. [19:28] <Daemon404> the word youre looking for is autistic, j-b [19:28] <j-b> Well, I met reimar, and he did not seem autistic [19:29] <gnafu> It's a large spectrum these days ;-). [19:29] <Daemon404> on the internet, nobody knows you are a dog. [19:30] <j-b> but the "pkg-config has too many dependencies is a flowed one". [19:30] <j-b> but the "pkg-config has too many dependencies" argument is a flawed one. [19:30] <j-b> I don't know how to write tonight. [19:30] <Daemon404> yes [19:30] <Daemon404> i dont get the pkg-config hate wagon [19:31] <wm4> well pkg-config, the official one, is pretty dumb [19:31] <wm4> there's absolutely no reason to depend on fucking glib [19:31] <Daemon404> wm4, nobody using a binary distro [19:31] <Daemon404> aka eveyrone [19:31] <Daemon404> gives any shit [19:31] <Daemon404> youre not the pkg-config maintainer [19:31] <Daemon404> why do you care [19:31] <Daemon404> etc [19:31] <Daemon404> if youre that bothered, compile pkgconf, which is dep free [19:31] <Daemon404> to what end you'd require this, i do not know. [19:32] <Daemon404> /weekly_pkg_config_rant [19:32] <wm4> well this was more about windows [19:32] <wm4> have fun with cross compiling glib [19:32] <Daemon404> who cares [19:32] <Daemon404> do you compile msys yourself? no. [19:32] <Daemon404> why would you compile pkg-config [19:32] <Daemon404> there are binaries easily available as well [19:34] <ubitux> j-b: what, msys2 uses "pacman"? same as archlinux package manager or sth else? [19:34] <Daemon404> yep [19:34] <JEEB> yup [19:34] <Daemon404> also there are official gnome pkg-config win32 binaries if you use msys1 [19:34] <ubitux> yes same, or yes sth else? [19:34] <j-b> ubitux: it is the same [19:34] <ubitux> fun, ok [19:35] <j-b> ubitux: they use the SAME PKG_BUILD files [19:35] <j-b> ubitux: and they port the pacman files directly from archlinux.org [19:35] <j-b> ubitux: pacman -S vlc there will compile VLC [19:35] <j-b> not a joke. [19:35] <ubitux> that's fun, wasn't aware of this [19:35] <ubitux> "compile"? [19:35] <j-b> it's normal [19:35] <j-b> it's new [19:35] <ubitux> i see [19:36] <j-b> it's great. [19:36] <ubitux> interesting [19:36] <j-b> for VLC, we do pacman -S git subversion cvs automake autoconf libtool m4 make gettext pkg-config mingw-w64-i686-lua [19:36] <j-b> ubitux: see https://wiki.videolan.org/Win32CompileMSYS/ [19:36] <j-b> It used to be 10x longer to do this. [19:37] <Daemon404> what i dont get is why people keep saying pkg-config is bad for cross-compiling [19:37] <Daemon404> it is literally 0 issue [19:37] <wm4> true, but stupidity [19:37] <JEEB> some weird people are used to not using a prefix [19:37] <JEEB> and building in-source-root [19:37] <Daemon404> if you dont make install your deps, youre gonna have a bad time [19:37] <Daemon404> and be a bad person [19:37] <j-b> Daemon404: because they don't understand it. [19:38] <JEEB> ^ [19:38] <Daemon404> i didnt think it was that hard to understand [19:38] <j-b> Daemon404: they don't understand what cross-compilation is. [19:38] <Daemon404> ah. [19:38] <Daemon404> ok [19:38] <Daemon404> that makes much more sense [19:38] <j-b> they think they do, but they don't [19:38] <JEEB> anyways, I guess I should move to msys2 one of these days [19:38] <JEEB> it seems to finally be mature enough [19:38] <Daemon404> inigo_montoya.jpg [19:38] <Daemon404> etc [19:38] <j-b> Understanding more or less what cross-compilation is is simple. Understanding correctly is hard. [19:39] <Daemon404> i had it beaten into me working for Wind RIver [19:39] <j-b> Stuff like gettext+iconv, moc or libtool and yasm is not trivial. [19:39] <Daemon404> so maybe i think it's easier to understand tahn it is [19:39] <Daemon404> >moc [19:39] <j-b> or protoc [19:39] <Daemon404> anythign related to qt is very nontrivial [19:39] <Daemon404> source: i worked on cross-comp qmake [19:39] <j-b> qmake is crap. [19:39] <j-b> cmake is almost crap. [19:40] <Daemon404> aye [19:40] <j-b> everything that is not autotool based is crap, btw [19:40] <j-b> with the exception of FFmpeg configure [19:40] <wm4> but autotools is also crap [19:40] <j-b> and zlib, IIRC [19:40] <wm4> and ffmpeg configure [19:40] <Daemon404> thats only because it was written by mans [19:40] <j-b> autotools works. [19:40] <Daemon404> no project has a mans. [19:40] <j-b> Ah yes, Mans [19:40] <wm4> j-b: mostly [19:41] <wm4> and I heard automake has no maintainer anymore (lol) [19:41] <j-b> but also, because ffmpeg configure has less dependencies than other projects [19:41] <Daemon404> wm4, iirc someone talked to the old one and he might come back or something [19:41] <j-b> wm4: the other don't work. [19:42] <Daemon404> mostly if you see broken autotools build systems, its not autotools breaking it [19:42] <Daemon404> its that they wrote custom shell script in the .in [19:42] <Daemon404> s/.in/.ac/ [19:42] <compn> someone actually complementing ffmpeg configure ? [19:42] <j-b> autotools syntax is crazy [19:42] <j-b> and libtool is insane [19:42] <compn> heh [19:43] <Daemon404> thats why you read diego's ebook, j-b [19:43] <Daemon404> obv [19:43] <j-b> Daemon404: believe me, I've asked Diego questions he could not answer on these topics. [19:43] <j-b> compn: it's the only non-autotools configure that I've seen that is not Über-crap. [19:43] <j-b> compn: and that mostly works. [19:43] <wm4> what does it do right? [19:44] <j-b> cross-compilation in many weird cases [19:44] <j-b> All the cmake projects are out [19:44] <compn> "it works" [19:44] <ubitux> it doesn't have dependencies too [19:44] <wm4> I hate cmake so much [19:44] <compn> and its not impossible to read [19:44] <ubitux> i think that's a major point [19:44] <wm4> it's a really great target for hating [19:44] <ubitux> like, not needing "python" for building is kind of cool [19:44] <Daemon404> i feel like this pkg-config thread needs the "You composed this email at a rate of more than N.NN cps" message [19:44] <Daemon404> from bikeshed.com [19:45] <wm4> ubitux: yeah because python is so obscure [19:45] <compn> i have python runtimes installed but not python dev :P [19:45] <ubitux> wm4: python is 80M here [19:45] <compn> or maybe thats not needed for python, nevermind [19:45] <j-b> All the custom configure, like live555 (lol) or VPX (WTFFFFFFFFF) are totally broken [19:45] <compn> i need to know what mingw/mingww64/msys2 people are using [19:46] <Daemon404> j-b, vpx is based on ffmpeg too [19:46] <Daemon404> :D [19:46] <JEEB> j-b, also le GPAC [19:46] <jamrial> getting python dev to work on msys was a pita [19:46] <jamrial> msys2 fixed that with their package manager [19:46] <wm4> that reminds me I hacked mplayer's configure file from 10kloc down to 1kloc for mpv [19:46] <ubitux> wm4: also, when i see what they did between python2 and python3, i'm quite happy something as sensible as a build system doesn't need to be rewritten [19:46] <Daemon404> JEEB, thats not a build system, thats an abomination [19:46] <j-b> Daemon404: well, vpx is done by people who have NO idea what they are doing. [19:46] <compn> wm4 : but is it faster? :P [19:46] <Daemon404> ofc [19:46] <j-b> compn: on Linux, Mingw-w64 [19:46] <j-b> compn: on Windows, Msys2 [19:47] <wm4> some people don't even know that mingw-w64 exists [19:47] <jamrial> libvpx configure is weird. last time i checked make distclean didn't really clean everything, for example [19:47] <j-b> some people refuse pkg-config [19:47] <j-b> jamrial: weird? you are nice. It's a piece of shit. [19:47] <Daemon404> it's better than some [19:47] <Daemon404> go try and compile openexr [19:48] <Daemon404> then try and cross-compile it (you cant) [19:48] <compn> would you guys be opposed if someone maintained a non-pkg-config system along side the pkg-config system ? [19:48] <compn> like a fallback if it fails ? [19:48] <j-b> Daemon404: oh, openjpeg was nice! [19:48] <Daemon404> compn, ubtiux proposed that many moons ago and carl shat on him [19:48] <j-b> compn: sure, it's git, they can maintain their fork [19:48] <bencoh> JEEB: gpac buildsys is not broken, it's non-existent (seriously) [19:48] <JEEB> :D [19:48] <compn> i'm not sure if carl saw that offer. [19:48] <j-b> people using gpac deserve the pain. [19:48] <bencoh> :D [19:48] <compn> j-b : says the person who wants less forks [19:49] <Daemon404> thats only until j-b can fork [19:49] <j-b> Daemon404: ? [19:49] <Daemon404> failed joke, carry on [19:49] <kierank> Daemon404: I'm considering forking [19:49] <ubitux> compn: i would honestly prefer if we put pkg-config-lite.c into the repository [19:49] <kierank> properly [19:49] <ubitux> instead of these shitty hack we need to do [19:49] <Daemon404> kierank, ffmbc-ng [19:49] <j-b> Daemon404: I'm seriously thinking of forking, though. [19:49] <kierank> Daemon404: no a fork that delete's ffmpeg.c [19:49] <wm4> soon j-b will have forked the whole open source multimedia infrstructure! [19:49] <j-b> Daemon404: I just need a maintainer. [19:49] <kierank> and makes it just for api users [19:49] <compn> ubitux : duplicate an easily buildable pkg-config for our libs only? sounds good to me. [19:50] <j-b> wm4: mpv-ng! [19:50] <ubitux> compn: not for our libs, for probing external libs [19:50] <compn> thats what i meant :) [19:50] <compn> our external libs [19:50] <compn> the ones we support [19:50] <Daemon404> that is the epitome of retardedness. [19:50] <Daemon404> or close to it. [19:50] <ubitux> :) [19:51] <compn> Daemon404 : when we have to battle distros, OS's , toolchains and other nonsense, there is no smart-ness involved. [19:51] <Daemon404> what? [19:51] <Daemon404> literally everything has pkgpconfig [19:51] <Daemon404> 100% of things [19:51] <j-b> not 100% [19:51] <wm4> ffpkgconfig [19:51] <compn> kierank : a libav libs only fork? no more .c tools ? [19:51] <Daemon404> j-b, for all intents and purposes [19:51] <kierank> compn: yes [19:52] <Daemon404> anyway, the only thing that we're battling here is autism [19:52] <Daemon404> from anti-pkg-config people [19:52] <j-b> Daemon404: live555 [19:52] <wm4> you mean cehoyos? [19:52] <compn> kierank : how would you test changes? a collection of test programs ? [19:52] <kierank> compn: correct [19:52] <compn> basically fate but c programs [19:52] <Daemon404> j-b, i have never looked at it nor will i [19:52] <Daemon404> 0 benefit to me [19:52] <bencoh> there's already a collection of tests afaik [19:52] <ubitux> j-b: oh damn you actually download pkgconfiglite in your build system [19:53] <j-b> Daemon404: gme, libmatroska, libmpcdec [19:53] <ubitux> that's actually pretty close to what i was proposing [19:53] <j-b> ubitux: of course. [19:53] <ubitux> i wonder if i should send a patch to do that in the configure [19:53] <ubitux> if pkg-config is not found [19:53] <wm4> lol libmatroska [19:53] <compn> ubitux : if we can copy vlc then its not our 'retardeness/autism' fault :) [19:53] <j-b> ubitux: we have a extra/tools folder that does fill the issue for limited systems (builder system) [19:53] <wm4> ubitux: maybe an in-tree copy would make sense [19:53] <wm4> I mean how much is pkg-config [19:54] <wm4> maybe some hundreds of lines max? [19:54] <kierank> bencoh: all based around ffmpeg.c [19:54] <j-b> ubitux: and then, we have a contrib folder that compiles for the running system [19:54] <ubitux> j-b: do you know why -lite hasn't been merged upstream? [19:54] <compn> Daemon404 : huhuhu , look what has happened, we are going to do this to pkgconfig ;) [19:54] <Daemon404> i hate all fo you [19:54] <Daemon404> of* [19:54] <j-b> ubitux: after years of backshedding, noone complains anymore. [19:54] <ubitux> :( [19:55] <j-b> ubitux: and we compile for OS/2, BeOS, iOS, Android (since 2.1 up to 5.0), Windows RT, Windows Phone, and also with MSVC [19:55] <wm4> 4760 glib-snippet.c [19:55] <wm4> 825 main.c [19:55] <wm4> 1118 parse.c [19:55] <wm4> 1335 pkg.c [19:55] <ubitux> j-b: i see :) [19:55] <wm4> where glib-snippet.c is apparently from glib (wtf) [19:55] <wm4> also the wholr source tree is 2MB [19:56] <wm4> source is 240k, rest is autoconf crap [19:56] <j-b> ubitux: so tools to compile (autotools, pkg-config) [19:56] <j-b> ubitux: and then 3rd party libraries [19:56] <ubitux> echo 'all: $(CC) pkg.c -o pkg-config' > Makefile [19:57] <j-b> (including FFmpeg) [19:57] <Daemon404> i dont see why we dont just use /bin/sh instead of Makefiles [19:57] <Daemon404> i mena [19:57] <Daemon404> bsdu sers have to install gmake [19:57] <Daemon404> OMG DEPS [19:57] <Daemon404> !!!!111 [19:57] <ubitux> j-b: yeah i remember something along this [19:57] <compn> because bin/sh is outdated everywhere. same problem with bash [19:57] <ubitux> Daemon404: oh that reminds me of something fun [19:57] <compn> or missing some stupid feature [19:57] <compn> and users cannot update ssystem binaries [19:57] <compn> or something like that [19:57] <j-b> Daemon404: that's a good one :) [19:57] <bencoh> :] [19:58] <j-b> Daemon404: but we could download gmake too [19:58] <ubitux> Daemon404: https://github.com/bsdphk/Ntimed/blob/master/configure#L77 [19:58] <Daemon404> hurr durr [19:58] <ubitux> still better than autools [19:58] <ubitux> autotools* [19:59] <Daemon404> thats not enough though [19:59] <j-b> compn: not everything that VLC does is stupid, my friend. [19:59] <Daemon404> it wont build on plan9, ubitux [19:59] <Daemon404> they use mk. [19:59] <Daemon404> and windows needs .bat and .vbs [19:59] <compn> when did i say that j-b ? [19:59] <JEEB> Daemon404, nmake! [20:00] <compn> j-b : i have no ill will against vlc [20:06] <j-b> Anyway, good trolling tonight! [20:06] <j-b> See you next year, guys! [20:10] <compn> i have an idea [20:11] <compn> confauto. it reads custom configure scripts and builds the files itself instead of using the configure! :P [20:12] <ubitux> yes, that's autoconf [20:12] <Daemon404> sounds more like mplayer [20:14] <jamrial> ugh, the pack_8ch asm is failing on msvc/icl x86 [20:15] <nevcairiel> msvc is funny like that [20:15] <compn> Daemon404 : we only duplicated ffmpeg building for a while :P [20:16] <wm4> you still do [20:16] <wm4> I wonder when reimar will have enougn of that [20:16] <compn> i thought we just called ffmpegs' ./configure [20:16] <compn> been a while sincei looked at it, but i guess we do have to update when ffmpeg adds a new thing [20:17] <jamrial> i'm guessing HAVE_ALIGNED_STACK being 0 is making x86inc's PROLOGUE macro require an extra reg it can't really use [20:17] <wm4> no, the ffmpeg configure is completely duplicated in mplayer, I think [20:17] <jamrial> awesome [20:19] <nevcairiel> i would imagine that defining the function using 10 regs on 32-bit is going to confuse some code [20:20] <jamrial> x86inc changes that to 7 on x86_32. that's not the issue [20:24] <nevcairiel> oh yeah i see, it changes it to 7, but then it needs a stack pointer and adds one again, and then the assert blows up [20:24] <nevcairiel> you could use a negative stack size, that avoids the stack pointer, but it also makes some syntax impossible to use, which exactly i forgot [20:27] <nevcairiel> worst case put it under a have_aligned_stack check for now [20:29] <jamrial> yeah, i'm going to do that [20:31] <rcombs> this is usually the part where I say "screw it, this function's 64-bit-only" [20:33] <nevcairiel> i only use msvc for debugging, i'm happy as long as it works in gcc builds :d [20:36] <jamrial> rcombs: well, it works on 32bits if you have a decent compiler :p [20:36] <nevcairiel> i wonder why they dont just add an option to produce aligned stack, the 64-bit compiler does it, mandated by ABI even [20:40] <cone-469> ffmpeg.git 03James Almer 07master:975ff6a3c638: x86/swr: disable pack_8ch functions on msvc/icl x86_32 [20:40] <jamrial> there. msvc x86 can live a little while longer without these functions until i figure out how to fix this [21:24] <JEEB> seems like some project will now get less access from india https://twitter.com/pranesh_prakash/status/550196008416600064/photo/1 [21:26] <kierank> Might be a good thing ;) [21:26] <wm4> lol [21:26] <JEEB> kierank, but videolan.org is not blocked 8) [21:27] <kierank> Nor FFmpeg.org [21:27] <JEEB> yup [21:30] <Rodeo> Happy New Year! [21:30] <nevcairiel> blocking all kinds of pastey websites, sense this makes none [21:32] <wm4> I don't know, paste sites run in other countries must be pretty terrible for internet censors [21:32] <wm4> anyone can publish freely [21:32] <nevcairiel> should launch a new paste site now [21:33] <wm4> there are probably still a few hundreds of such sites left [21:34] <JEEB> "The action has been initiated to unblock the following sites -- weebly.com, vimeo.com, dailymotion.com and gist.github.com," said a statement from the communications and information technology ministry. [21:34] <JEEB> so it seems like they've now decided to unblock those four [22:36] <cone-469> ffmpeg.git 03Michael Niedermayer 07master:3eb5cbe0c50d: avformat/cdxl: Fix integer overflow of image_size [22:57] <cone-469> ffmpeg.git 03Michael Niedermayer 07release/2.1:41802887eb64: avformat/cdxl: Fix integer overflow of image_size [23:43] <cone-469> ffmpeg.git 03Michael Niedermayer 07fatal: ambiguous argument 'refs/tags/n2.1.7': unknown revision or path not in the working tree. [23:43] <cone-469> Use '--' to separate paths from revisions [23:43] <cone-469> refs/tags/n2.1.7:HEAD: avformat/cdxl: Fix integer overflow of image_size [23:46] <Daemon404> https://ffmpeg.org/pipermail/ffmpeg-user/2014-December/024814.html [23:46] <Daemon404> thats why im not subscrubed to user... [23:47] <Daemon404> subscribed even [00:00] --- Thu Jan 1 2015

1 0

ffmpeg.log.20141231
by burek 01 Jan '15

01 Jan '15

[02:06] <schiho> Hi guys [02:08] <schiho> I have attached an SDI Input to my Computer, the video input is "Rawvideo (UYVY422) what is the difference to yuv420p ? [02:14] <c_14> the subsampling [02:16] <troy_s> schiho: in a YCbCr 422 your luma channel is 1:1 [02:17] <troy_s> schiho: With your Cb / Cr (Blue / Yellow and Red / Green axes) are half res [02:17] <troy_s> schiho: In 420, the Cb and Cr are quarter res. So if your sources were 1920x1080, in 422 your Y' is 1920x1080, and your Cb/Cr is 960x540 [02:18] <schiho> ohh [02:18] <schiho> didn't know that the resolution changes in this manner [02:18] <troy_s> schiho: In 422, your Cb / Cr would be 960x1080 [02:19] <troy_s> It's not resolution per se. It is chroma subsampling. [02:19] <schiho> i see [02:19] <troy_s> The general agreement is that our perceptual systems (subject to sociological stuffs for sure) are more susceptible to luminance than chroma [02:19] <schiho> Is there much difference in processing overhead in between UYVY422 and YUV420p? [02:19] <troy_s> So video attempts to leverage that to compress the signal, providing more data of luminance than chrominance. [02:20] <troy_s> Not really. It is literally a scale. [02:20] <troy_s> And playback might be different than say, online needs (by online in reference to post production, not internet) [02:20] <schiho> i see what you mean, online, offline editing like [02:20] <troy_s> So you may choose a faster and less quality scaling technique for playback because it might not matter as much, versus say, some post production pipe that has decided to use a subsampled format. [02:20] <troy_s> Correct. [02:21] <troy_s> The scaling of those Cb / Cr planes has a _tremendous_ impact on the quality of the bits, as does the quantization level. [02:21] <troy_s> And in fact, you can also get false colors and plenty of other strange bits depending on the technique one uses to go from the merged YCbCr planes back to RGB. [02:21] <troy_s> Glen Chan has a decent exploration of that IIRC. [02:22] <troy_s> schiho: http://www.glennchan.info/articles/technical/chroma/chroma1.htm [02:22] <schiho> link saved [02:23] <schiho> Maybe i should elaborate further, i am reading from my camera the raw video input and i am streaming it over udp to the network after encoding [02:23] <schiho> I already read all the live-streaming and low-latency pages from ffmpeg [02:24] <schiho> There are some suspicous things, where i couldn't find anything [02:24] <schiho> 1) When i change the gopsize to 1, so that only keyframes are sen't shouldn't the encoding process be faster? [02:24] <troy_s> schiho: Well first, it isn't raw. [02:24] <troy_s> :) [02:25] <troy_s> It's a YCbCr conversion based off of the (likely) Bayer sensor. [02:25] <troy_s> And while it is pure speculation, there's plenty of stuff going on there to make any sort of guess useful. [02:25] <troy_s> What camera? [02:25] <schiho> Blackmagic Cinema Camera + Baclkmagic Decklink Studio 2k PCI Card [02:26] <schiho> So i am connected over SDI [02:26] <troy_s> Remember that your camera has plenty of onboard chips to try and accelerate the blasted conversions, and those are nothing more than algorithms baked into a chip. So if the camera was designed primarily to use Foo chip to do A, and you choose B, you can see that you may very well take a performance hit. [02:26] <troy_s> Right. So that is a different scenario. That is a YCbCr signal coming out the pipe then? [02:27] <troy_s> And why aren't you shooting raw? [02:27] <troy_s> ( :) ) [02:27] <schiho> this is just for playback, we are of course shooting raw :) [02:27] <troy_s> Ok. So your issue is? [02:28] <troy_s> It is sluggy? [02:28] <troy_s> (I don't personally own a BMCC but I know of a couple of friends that own a pair each.) [02:28] <schiho> my problem is pure latency [02:28] <troy_s> How are you streaming it? [02:28] <troy_s> And is there a bad latency direct off of the SDI? [02:29] <schiho> [BMC CAMERA]---->[BLACKMAGIC SDI CARD]----->[FFMPEG to UDP with x264 (tune:zerolatency, preset:ultrafast)]------>ffplay [02:29] <troy_s> I'd bet heavy on network issues then. [02:30] <schiho> you mean, the bandwith limit ? i wouldn't think [02:30] <schiho> i am currently streaming local [02:30] <troy_s> (Although granted, going from 420 to 422 would increase your data relatively significantly as you can see. 420 has quarter the resolution on two planes, where 422 has half the pixel count on the two. That's a reasonable overhead.) [02:30] <schiho> for test purposes [02:31] <troy_s> Just network stuffs. [02:31] <troy_s> What sorts of latency are you seeing? [02:31] <schiho> it's delayed between 0,7 and 0,9 seconds [02:31] <troy_s> And this is causing havoc for your audio playback I take it? [02:31] <schiho> my ffmpeg option for audio is -an [02:32] <schiho> so there shouldn't be audio? [02:32] <troy_s> What is the issue for latency then? [02:32] <relaxed> what is your command? [02:32] <troy_s> If it is operating, I seem to recall 30-40hz being the threshold, and I'd seriously doubt that you can hit that with network. [02:33] <schiho> -f dshow -i video=\"Blackmagic WDM Capture\" -pix_fmt yuv420p -vf scale=1280:720 -r 25 -vcodec libx264 -preset ultrafast -tune zerolatency -g 1 -f mpegts udp://192.168.0.10:1234" [02:33] <schiho> ignore the backslahes [02:33] <troy_s> Well that's going to take software scaling in there. [02:34] <troy_s> Have you tried dumping raw? [02:34] <troy_s> as in just copying the YCbCr stream? [02:34] <schiho> you mean "dumpring raw" --->"sending raw over network" ? [02:34] <troy_s> That's going to A) scale it B) encode it [02:34] <troy_s> Yes. Just transmit the YCbCr across the network direct from camera to destination. No scaling. No encoding. [02:34] <relaxed> do you think -g 1 is wise? [02:35] <schiho> i was just messing around with gop size, as i had a theory, that it will decrease latency as the encoder won't wait for a nother frame? [02:36] <troy_s> schiho: You are going to get latency subject to FFMPEG's ability to run. You are wiser to get a baseline of "what happens if I simply transmit the raw YCbCr from the camera to the destination" [02:36] <troy_s> schiho: The g1 is again, an encoding parameter. Not going to be faster if you are re-encoding. [02:37] <troy_s> schiho: So try copy first. [02:37] <schiho> allright i will use vcodec copy [02:37] <schiho> let me try this out [02:37] <troy_s> schiho: Start there. [02:37] <schiho> (just a side note: at the end i want to stream to my mobile phone :) ) [02:38] <troy_s> schiho: Sure. Wireless and bandwidth might be a slug. [02:38] <troy_s> schiho: Can you control what is dumped off of that BMCC YCbCr out? Is it via the SDI out? [02:39] <schiho> yeah, one sec i will check it out [02:40] <schiho> no not really, i can just set the SDI-Mode to "HD" or "4K" [02:40] <troy_s> HD is a good start. :) [02:41] <troy_s> 4k is 4x the information. [02:41] <troy_s> (as a rough starting point.) [02:41] <schiho> :) [02:41] <troy_s> See if you can get 2k working smoothly then build upwards. [02:41] <schiho> 4k is not in my interest for now [02:41] <schiho> and dumping now a raw video i get "circular buffer" error [02:41] <troy_s> I can't remember which camera has the better latitude. [02:41] <schiho> -f dshow -i video=\"Blackmagic WDM Capture\" -pix_fmt yuv420p -vcodec copy -f mpegts udp://192.168.0.10:1234" [02:42] <troy_s> ? [02:42] <troy_s> Uh... the -f isn't needed is it? you are copying. [02:42] <schiho> ffplay udp://192.168.0.10:1234 [02:42] <schiho> you mean the -f mpegts [02:43] <troy_s> Yes. [02:43] <troy_s> (basically we don't want FFMPEG doing anything) [02:43] <schiho> just removing "-f mpegts" isn't working [02:43] <schiho> "Unable to find a suitable output format for 'udp://192.168.0.10:1234' [02:45] <troy_s> relaxed: Idea? [02:51] <troy_s> schiho: No clue on how to do a -vcodec copy UDP. [02:52] <troy_s> Hum. Maybe you have to transcode for UDP? [02:53] <schiho> hmmm yes, me neither :) however, maybe we can concentrate on other questions too. So you wouldn't expect that the encoding takes too long? [02:53] <troy_s> Well the encoding is going to probably (speculating) take up the vast bulk of time. [02:53] <troy_s> try a -f mpegts at the start instead of dshow? [02:54] <schiho> i already did a test with a raw-video from disk, for a 90 seconds video it took me 17 seconds to encode [02:54] <troy_s> Well we have to try and get rid of that reencode. [02:54] <troy_s> And just transmit the data I'd think. [02:55] <troy_s> But I have NO clue if that is even possible when streaming. [02:55] <schiho> but -f mpegts at the beginning won't work i thought the "-f dshow" defines the input? [02:55] <troy_s> Oh probably. [02:55] <schiho> or forces the input [02:56] <troy_s> (duh) [02:56] <troy_s> What are you receiving with? [02:56] <troy_s> Not FFPLAY right? [02:56] <schiho> sure, with ffplay i am receiving [02:56] <troy_s> That has built-in latency as I understand it [02:56] <schiho> ffplay udp://192.168.0.10:1234 [02:56] <troy_s> can you try it with mplayer and the benchmark option? [02:57] <troy_s> as in mplayer -benchmark methinks? [02:57] <schiho> will do that, (sidenote: i am on windows ) [02:58] <troy_s> Should still be fine. [02:58] <troy_s> (Although an interesting point might be to stick an el-cheapo Linux headless box in there for transmitting to see if you can scrape down the latency that way too.) [02:58] <troy_s> (Even a super small micro styled box would probably work better than a full blown Windows instance.) [03:00] <troy_s> (And I think your pix_fmt is in the wrong place, and not it would apply with copy.) [03:01] <schiho> i can remove it, it should automatically detect it [03:01] <schiho> i mean it seems to work [03:01] <schiho> frame= 117 fps= 25 q=-1.0 size= 510799kB time=00:00:04.68 bitrate=894059.8kbits/s [03:01] <schiho> but i cannot replay it [03:02] <troy_s> ? [03:02] <schiho> the pasted line is output from ffmpeg [03:02] <troy_s> So did you get it working? [03:02] <schiho> no i get the circular buffer error on ffplay [03:03] <troy_s> Can you ditch ffplay for the time being? I'm reasonably certain I remember reading about latency issues wit hit. [03:03] <schiho> sure [03:03] <schiho> i will use mplay [03:04] <troy_s> Please. That circular buffer is some threaded loopy thing with FFPLAY and I am deep enough over my head. [03:04] <schiho> :) thats a good hint... i shouldn't use it for debugging now [03:05] <pinkette> why does apple h264 encoder looks like crap [03:05] <troy_s> schiho: Win? [03:05] <schiho> @troy_s give me a minute i have to restart my computer [03:05] <schiho> brb [03:18] <t4nk655> i am back [03:19] <schiho> so know i am back :) [03:20] <schiho> you won't believe but latency of mplay is wors then vlc, ffplay [03:32] <pinkette> would upgrading from amd phenom 2 x4 to amd fx-8300 x8; make big difference running ffmpeg [03:37] <schiho> Does anyone know if the option "threads" in ffmpeg uses frame based or slice based threading? [03:37] <c_14> ffmpeg -h encoder=[encoder] [03:37] <c_14> Check the therading capabilities output [03:46] <schiho> threading/capabilities> no [03:47] <schiho> so libx264 has no treading options? [03:47] <c_14> libx264 has threading [03:48] <schiho> in my output "ffmpeg -h encoder=libx264" [03:48] <schiho> it says "Threading capabilities: no" [03:49] <schiho> http://pastebin.com/J1WjLQyQ [03:51] <c_14> according to the manpage it does slice and frame threading [03:52] <c_14> depending on the -thread_type option [03:52] <c_14> https://ffmpeg.org/ffmpeg-codecs.html#Options-19 [03:52] <c_14> The help should state that though... [04:00] <schiho> Hmm... there is barely a speed gain with and without threads [04:00] <c_14> The default is -threads 0 which is automatic [04:02] <schiho> Ok now i see the difference, -threads 1 is 1/4 slower [04:02] <schiho> where did you read the default? what is the default for thread_type ? slice or frame? [04:07] <c_14> according to this, frame [04:07] <c_14> http://mewiki.project357.com/wiki/X264_Settings#threads [04:08] <pinkette> what would you say would be a stronger computer? 2014 $2000.00 computer or year 2000 supercomputer [04:08] <schiho> i see, for me slice has better performance [04:09] <c_14> Also, not sure why CODEC_CAP_SLICE_THREADS and CODEC_CAP_FRAME_THREADS were never added to the capabilities for libx264... [04:09] <c_14> Might have to ask someone. [04:09] <c_14> pinkette: depends on the usecase probably [04:09] <c_14> For a desktop workload the 2014 one. [04:09] <schiho> yes, maybe you should do that [04:11] <schiho> I am wondering what ffmpeg does when you stream with libx264, is he sending an image as soon it is finished or is it waiting for more images and send them as a bunch? If it is sending the images 1 by 1 the threads option with frame will not have any effect, or even worse effect [04:14] <c_14> I don't know much about the buffering logic, sorry. [04:15] <c_14> That is, besides the -bufsize option [04:17] <schiho> hmmm [04:17] <schiho> so i will now sleep a bit thank you c_14 very much for your knowledge! and s_troy you as well, thank you very much providing me with so much information [04:18] <c_14> np [04:26] <schiho> ok i cannot sleep :) i will try the vbufsize [04:28] <schiho> the -bufsize option will limit the size of one image? is this correct? [04:29] <c_14> https://trac.ffmpeg.org/wiki/EncodingForStreamingSites [04:29] <troy_s> schiho: Sorry [04:29] <troy_s> schiho: Was dinner [04:29] <troy_s> schiho: Did you make any progress? [04:30] <troy_s> pinkette: It should. [04:30] <schiho> not with the raw streaming, but i've send an email to the mailing list with the problem. I searched online and there is nothing describing rawvideo streaming [04:31] <troy_s> schiho: I'm not sure that you can perhaps. [04:31] <troy_s> schiho: But if you can figure out a way to simply transmit and catch the data and then decode, you surely will reduce your latency. [04:31] <troy_s> schiho: I'm reasonably sure there must be a method to do that via UDP [04:32] <schiho> yeah should be [04:34] <schiho> c_14: i already looked into that document.. But the description from another document is a bit different : "With a single VBV, every single frame is capped to the same maximum size. this means that the server can instantly send all frames after encoding them" [04:35] <c_14> Where'd you find that? [04:36] <schiho> http://x264dev.multimedia.cx/ [04:36] <troy_s> schiho: I'd also try mpeg2 based because that encode shouldn't take long.; [04:36] <schiho> i am not sure if he is talking about the same buffer, but the idea, limiting the framebuffer is for me trivial [04:37] <troy_s> schiho: And did you use the -benchmark to get quantitative results? [04:38] <schiho> troy_s: yes i read about mpeg2 and results here: http://www.waitwut.info/blog/2013/06/09/desktop-streaming-with-ffmpeg-for-l… [04:39] <troy_s> schiho: The thing is, what is that YCbCr coming out there? is it not already in a wrapper? [04:40] <troy_s> I'd have thought that there was a codec, but perhaps it is some plain planar YCbCr [04:40] <schiho> allright i dont know what i did but the latency is now very low [04:41] <troy_s> schiho: What is your command? [04:41] <troy_s> Also, DarkShakiri was one of the more knowledgeable folks around the codec parts for a long while... terse too. http://x264dev.multimedia.cx/archives/249 [04:44] <pinkette> does ffmpeg support x265 ? [04:44] <c_14> If you build it with support, yes. [04:45] <troy_s> Erf. I really should look at the color code again and see if the silly sRGB thing was lifted. [04:45] <pinkette> what about the one where you download [04:46] <c_14> `ffmpeg -codecs | grep 265' [04:46] <c_14> Check if it has DE [04:47] <schiho> troy_s: i didn't really change anything, i thought maybe it's because of the slice option of threading, but it's not [04:47] <c_14> and/or check the configuration line if it was built with --enable-libx265 [04:48] <schiho> troy_s: but with the threadtype slice i's remarkable amout better then without [04:49] <schiho> Delay in Seconds mPlayer with slice: 0.23, 0.229, 0.288, 0.23 [04:49] <troy_s> schiho: Because slice encodes a single frame across cores. [04:49] <schiho> Delay in Seconds mPlayer no Slice: 0.406, 0.289, 0.241, 0.287 [04:49] <troy_s> schiho: Which puts all threads into encoding a single frame. Great for encoding latency, at a tradeoff of quality probably. [04:49] <schiho> yes and i suppose the default is frame [04:50] <troy_s> schiho: That about does it then. Doubt you will get it lower. [04:50] <schiho> exactly [04:50] <troy_s> schiho: What codec? [04:50] <troy_s> schiho: Is that x264? [04:50] <schiho> libx264 [04:50] <troy_s> schiho: With the zerolatency option? [04:50] <schiho> yes [04:50] <troy_s> I'm sure that is close to as good as it will get. [04:50] <schiho> that makes me happy troy! :) [04:50] <troy_s> The _only_ better option would be zero encoding if it is possible, and transmit that [04:51] <troy_s> But again, that's just me speaking as a YCbCr codec nerd, not as an ffmpeg expert. I'm not sure it is even possible. [04:51] <schiho> yeah i should definetely try this out [04:51] <troy_s> schiho: The good news is that with what you have now, you have your mobile streaming working now. [04:51] <troy_s> schiho: Also, I would seriously consider running a headless Linux box if this is an important thing. You can almost certainly shave some latency off that. [04:52] <troy_s> .25 latency isn't horrible though. [04:52] <schiho> what do you mean exactly by headless linux, you mean virtual box? [04:52] <troy_s> I'd say that is very manageable. [04:52] <schiho> http://pastebin.com/bd4rrzDK => you can see here where i began [04:52] <troy_s> No. I mean if this is a 'thing' i'd heavily consider a Brix or NUC box and run it headless. [04:52] <troy_s> What processor are you running now? [04:52] <troy_s> Because threads will make a hell of a difference for you. [04:52] <schiho> intel core i7 [04:53] <troy_s> How many threads are you running with that command? [04:53] <troy_s> It should be 8 [04:53] <schiho> it's the default, and i think default is automatic according to the number of cpus [04:53] <troy_s> set it manually just to be sure. [04:54] <troy_s> If you have a quad core i7, roll with 8 (although sometimes for reasons that are known only to schedulers, total +1 or some other dark alchemy may be better.) [04:54] <schiho> yes i set it manually now, but for some reason i cannot go more than 7 [04:54] <troy_s> ? [04:54] <troy_s> That's odd. [04:55] <troy_s> Quad core with HT should work with 8. [04:55] <troy_s> Is FFMPEG barfing out an error? [04:57] <schiho> nope nothing [04:57] <troy_s> What is your line? [04:57] <schiho> and i am using 12% of my overall cpu [04:57] <schiho> -f dshow -i video=\"Blackmagic WDM Capture\" -pix_fmt yuv420p -r 25 -vcodec libx264 -preset ultrafast -tune zerolatency -threads 16 -thread_type slice -f mpegts udp://192.168.0.10:1234" [04:57] <troy_s> Yes... that should be higher if the threads are more optimized. [04:57] <troy_s> 16? [04:58] <troy_s> What happens with 8? [04:58] <schiho> jep, this is the maximum recommended [04:58] <troy_s> You will add scheduling overload with too many [04:58] <troy_s> (You lose time flipping jobs.) [04:58] <troy_s> So I'd try 8 and 4. [04:58] <troy_s> and test the benchmarks. [04:59] <schiho> okey you know what, i was killing the process of ffmpeg everytime i was starting a new one, so ffmpeg.exe was still in the processes but rubbish [04:59] <troy_s> That's no good. [04:59] <schiho> so i killed now every instance of ffmpeg exe [05:00] <troy_s> (You _really_ need that Linux install. Have a spare SSD kicking around?) [05:00] <troy_s> Best 60$ you can probably spend right now. :) [05:00] <schiho> :) i will get one tomorrow, it's 05.00 am here atm [05:00] <troy_s> You get my PMs? [05:01] <schiho> ah yeah got it [05:01] <schiho> i didn't see it [05:01] <schiho> however, i am not sure if ffmpeg is starting hidden threads, so that i cannot see it under process in the task manager [05:02] <pinkette> is it just me or h263 is horrible [05:02] <pinkette> what is best h263 encoder [05:03] <troy_s> schiho: The threads will be under the instance, not multiple instances. [05:03] <schiho> yes, i am watching them now under the ressource monitor [05:04] <schiho> when i explicitly write 1 threads under windows it appears with 4 , writing 2 it appears with 10 [05:05] <schiho> i am sure ffmpeg is starting threads for other tasks as well with every instance, maybe for communication [05:06] <schiho> oh i've realized that the blackmagic camrea has an ssd 512gb inside :) [05:10] <troy_s> schiho: Decent camera. Form factor is junk. Off speed lacking is junk. But really solid latitude. [05:11] <troy_s> schiho: (On the smaller sensor version. The larger sensor suffers from the CMosis buggy) [05:15] <schiho> and the camera gets hot reallz fast....i mean for me it|s good, wheni am freezing, i am putting my hands on it [05:16] <schiho> and i already replaced the display and now the battery is dieng [05:17] <schiho> troy_s: allright mate, i will sleep now, and hopefully install linux on my machine tomorrow [05:17] <schiho> troy_s: thank you for you help, i will come around this channel tomorrow night [05:19] <troy_s> schiho: Good stuff. [05:19] <troy_s> schiho: Feel free to hit me via email [05:19] <troy_s> schiho: I'll pm you. [05:20] <troy_s> schiho: You should have it. I'd be interested to see if you can shave some ms off of that with a Linux install on a small 120 SSD. [05:23] <schiho> troy_s: Great ;) [05:24] <pinkette> is it normal that x265 is very slow ? [05:37] <klaxa> yes [13:38] <mr_lou> I'm trying to create blu-ray folder with tsMuxeR (not GUI version). I can run the same command line 5 times in a row without changing anything. It'll fail 4 times but be succesful 1 time. The errors generally just "Segment fault, core dumped". but there's also been a "moov atom not found" every now and then. [15:06] <Subsentient> I need to force a constant bitrate converting m4a to mp3. [15:07] <Subsentient> It won't listen to anything I try including -minrate or -maxrate [15:07] <Subsentient> It starts off at some insanely high bitrate and then goes down to like 32 [15:15] <Subsentient> iive: Nobody? [15:15] <Subsentient> Nobody knows how to do something that simple? [15:16] <iive> Subsentient: what is the audio encoder that you are using? [15:16] <Subsentient> libmp3lame [15:16] <Subsentient> ffmpeg -i Zealot\ -\ 04.\ Undercat\ $feat.\ Zealot$.m4a -b:a 320k -minrate 320k -maxrate 320k -bufsize 2048k -codec:a libmp3lame Zealot\ -\ 04.\ Undercat\ $feat.\ Zealot$.mp3 [15:16] <Subsentient> that's the full command [15:17] <Subsentient> iive: It deteriorates down to like 50kbps halfway through conversion [15:17] <Subsentient> [15:18] <iive> i don't think mp3lame even looks at minrate/maxrate [15:19] <iive> try -b:a 128k [15:19] <Subsentient> iive: Still deteriorates [15:25] <iive> also, have in mind that the position of the option does matter. [15:26] <Subsentient> iive: I know it does. Does my command line look correct? [15:26] <Subsentient> iive: Show me how you'd convert an m4a to mp3 with a constant bitrate of 320kbps. [15:27] <iive> for me `ffmpeg -i some.mp4 -vn -b:a 320k c:a libmp3lame test.mp3` does work [15:27] <iive> ops, -c:a [15:28] <iive> and i've tried 64,128,192 and they all seem to work. [15:30] <Subsentient> iive: m4a, not mp4 [15:30] <iive> the input shouldn't matter. [15:30] <iive> i actually used .ts [15:31] <iive> m4a is just short of mp4audio [15:32] <iive> i added -vn to disable to video. [15:38] <Subsentient> iive: I solved it by converting the m4a to flac and then the flac to mp3 [15:39] <iive> i tried with m4a i found, I cannot reproduce this problem. [15:40] <Subsentient> iive: Thanks for your help. [15:41] <Subsentient> I get cranky. [15:41] <Subsentient> I never have luck with ffmpeg\ [15:41] <Subsentient> it always does weird stuff to me. [15:41] <iive> are you running it on windows? [15:52] <Subsentient> iive: No, Linux. [15:52] <Subsentient> i686 [16:37] <crschmidt> Hi. I'm trying to convert a video to a time-lapse style preview image. I know I can do this using the image2 muxer and another tool (like `convert`), but I'd like to do it in a single ffmpeg command if possible. The problem I'm having is that I can't seem to 'speed up' the gif output; the frame delay is always consistent with the frames that are being dropped. so if I use (eg) -vf "select='not(mod(n,60))'", the frame delay is set to 1s, whe [16:37] <crschmidt> Is there any way to do this in a single command? [16:38] <c_14> try changing the output fps? [16:41] <crschmidt> c_14: using -r? Adding -r combined with the -vf above does not change the frame delay of the resulting .gif [16:43] <c_14> Why not just use setpts? [16:46] <crschmidt> c_14: Because I have no clue what I'm doing :) Looks like the right answer; thanks! [16:48] <crschmidt> for posterity: ./ffmpeg -i flying.MP4 -filter:v "setpts=0.01*PTS" -t 5 -r 5 output.gif seems to give me approximately what I was looking for [16:51] <raytiley_> need help googling... is there a way to export the volume data for a video file as a text file... something like generating a thumbnail for every second, but with audio data instead? [18:23] <BadHorsie> So I have a couple of raspberry pis with cameras and I'm wondering what's good for watching them, Just for testing I have a cron taking pictures every minute and rsync'ing them to my laptop, course faaaar from ideal haha... [18:24] <BadHorsie> So, knowing nothing on the subject as you can see, I told myself, "why not go to ffmpeg and ask them what's cool and new and have something to learn?" [18:24] <c_14> use-case ? [18:25] <BadHorsie> Some initial searches (given I know close to nothing I am probably not coming up with hte right keywords even haha) have stuff about rtsp/rtmp... [18:26] <BadHorsie> I would like to see them on a browser maybe... Like a security system I guess [18:26] <BadHorsie> They are masking-tape'd to a couple of telescopes [18:27] <c_14> You can take them all and combine them as separate streams, or take them and layout them so they're all next to each other, you can output to a file or something networky [18:28] <BadHorsie> Can I do that with ffmpeg or what software/techniques should I be investigating? [18:28] <c_14> I only listed things that I know ffmpeg is capable of. [18:29] <BadHorsie> Nice [18:29] <BadHorsie> Can you expand a bit on the "networky" ? What would you recommend ? [18:31] <c_14> For looking at with a browser? [18:33] <BadHorsie> I... guess... I don't really know much so I'm biased by my lack of experience... Is there a better alternative? I was guessing I could use WebGL/Flash or maybe some other sort of software [18:34] <BadHorsie> Eventually I would like to add some analysis to the frames, like opencv or something like that... Just to see if I'm looking at anything useful (not a cloud) [18:35] <BadHorsie> But that would be on my laptop maybe, not the raspberry pi [18:35] <c_14> You can, but at that level you usually have to find a flash streamer, web server etc. I'd probably use something hls-like. Either with a webserver that supports hls or just a file I can open. [18:36] <c_14> You can use opencv with ffmpeg, but that usually requires some form of programming. [18:37] <BadHorsie> Yeah I don't mind programming... I have fooled around with processing images before, it's the codecs, transports, video techniques that I know nothing about haha [18:38] <c_14> The easiest start point for you would probably be just to grab all the individual streams from the rpis and stream them to one central location for processing/viewing [18:46] <BadHorsie> Hmm mlike ffserver on the rpi and ffmpeg client on the laptop ? [18:48] <c_14> not really [18:48] <c_14> basically just a bunch of ffmpeg processes sending videos ta an ffmpeg process on the laptop [18:50] <BadHorsie> Aight lemme read on it, thanks so much for the hints, happy new year! [20:09] <ac_slater> hey all. I'm interested in demuxing/decoding in 'realtime' via libavformat, etc (ie - not the command line utility). I can't figure out how the command line utility implements the `-re` flag. [20:10] <ac_slater> any clue? [20:14] <c_14> Check ffmpeg.c for all occurrences of rate_emu [20:20] <ac_slater> c_14: interesting [20:21] <ac_slater> I see now [00:00] --- Thu Jan 1 2015

1 0