[Ffmpeg-devel-irc] ffmpeg-devel.log.20141231

[burek]

[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-it-in-the-oven/ ?
[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