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

[burek]

[00:24] <cbsrobot> michaelni: thanks for 391f323615e8 !
[02:05] <cone-617> ffmpeg.git 03LYF 0723db5418ed2e: hls: create an AVProgram for each variant
[08:02] <cone-920> ffmpeg.git 03Clément BSsch 0757d7e21c3411: lavf: move libmodplug registration with the other ext lib.
[08:02] <cone-920> ffmpeg.git 03Clément BSsch 07030db0c1dd80: lavf/hls: whitespace cosmetics after 23db5418.
[10:32] <wm4> is it allowed to swap the data buffers (i.e. AVFrame.data, AVFrame.linesize) of the AVFrame used with avcodec_decode_video2() between decode calls? this would for course copying the image data into the data image data
[10:32] <wm4> or does the decoder somehow require that the data pointers never change?
[10:33] <wm4> (yes I know you can use direct rendering to do more extensive buffer management)
[10:47] <ubitux> wm4: will that have any effect?
[10:48] <ubitux> afaik most of the time the AVFrame you get is just a copy of the internal AVFrame kept in the decoder
[10:48] <ubitux> with data stored in the avctx
[10:48] <wm4> ubitux: it would mean that I could keep a decoded image as long as I want to (if the image is still in use by my code when the next frame us decoded, I'd switch the AVFrame.data pointers to a new image, which is a copy of the old one)
[10:53] <ubitux> i don't know that stuff very well, but unless you use the DR system to play with the data/linesize from the avctx, i'm not sure you can do that
[10:53] <ubitux> since decoders do something like *(AVFrame*)data = s->frame
[10:53] <ubitux> but maybe i'm missing something
[10:54] <ubitux> or just misunderstanding your point
[10:54] <wm4> the DR API is complicated (even cmdutils.c works around libavcodec bugs related to it), and not every decoder supports DR
[11:00] <ubitux> there are some doxy in avcodec.h, around the get_buffer callback
[11:01] <wm4> and
[11:02] <durandal_1707> what is this about?
[11:02] <ubitux> durandal_1707: http://pastie.org/private/1sj5gmd852idsuac8uq5g
[11:03] <ubitux> wm4: and nothing, might help you, dunno :)
[11:07] <cone-848> ffmpeg.git 03Piotr Bandurski 079a0ecd507a94: rpl: return AVERROR_EOF instead of -1
[11:08] <ubitux> fun times: http://lucy.pkh.me/diff/
[11:08] <ubitux> the filters diff is pretty entertaining
[11:12] <durandal_1707> ubitux: but nobody use lavfi
[11:13] <ubitux> ok :(
[11:16] <durandal_1707> that could change if more very fast and useful filters are added
[11:17] <wm4> ubitux: port vivtc
[11:18] <ubitux> vlc ivtc?
[11:18] <ubitux> i'm not really familiar with all the problematics around this
[11:18] <ubitux> not sure i'm the best person to do that
[11:19] <wm4> uh no
[11:19] <wm4> http://code.google.com/p/vapoursynth/source/browse/#svn/trunk/src/filters/vivtc
[11:20] <ubitux> ok
[11:20] <ubitux> vapour ivtc, ok
[11:25] <cone-848> ffmpeg.git 03Piotr Bandurski 0725d8ebd422f3: thp: signal EOF
[11:26] <JEEB> vivtc was basically Myrsloik reading TIVTC, seeing what it does and rewriting the main parts of it. Because just porting Tritical's code was impossible with all the asm obfuscation.
[11:26] <Myrsloik> obfuscated it was
[11:32] <ubitux> i wouldn't say impossible
[11:32] <ubitux> just veeeery long
[11:32] <Myrsloik> too long
[11:33] <Myrsloik> it even had some plain x86 asm only for some functions
[11:33] <ubitux> haha
[11:34] <Myrsloik> it had an over 1000 line constructor, 700 lines of which were dedicated to parsing a trivial line by line override file format
[11:35] <Myrsloik> *line++; of those lines many of them looked like that
[11:36] <cone-848> ffmpeg.git 03Paul B Mahol 07e94f4294746d: cafdec: return right code if EOF is reached
[11:36] <ubitux> anyway, i agree that we need an ivtc filter (suite?)
[11:43] <cone-848> ffmpeg.git 03Piotr Bandurski 074bf3bc6f96cf: sierravmd: signal EOF
[13:32] <wm4> ubitux: about changing ffmpeg -> Libav, I think that's not even legally allowed (I'm reading an udev shitstorm where greg kh was complaining that the udev fork did this)
[13:32] <durandal_1707> wm4: sue them
[13:32] <ubitux> i think that's ok
[13:32] <ubitux> the copyright holder is maintained, as well as the licence
[13:33] <ubitux> i'm not sure if the copyright is "Copyright - The FFmpeg project/developers" or sth like that
[13:33] <ubitux> but in that particular case, dunno
[13:37] <ubitux> wm4: anyway, the point of the diff really wasn't about this :)
[13:37] <wm4> what was it then
[13:38] <ubitux> how much nice things we have exclusively in ;)
[13:55] <durandal_1707> if i upload sample when i can expect to see it in samples.ffmpeg.org?
[14:11] <Compn> ubitux : thread ?
[14:11] <Compn> url i mean
[14:12] <ubitux> 11:08:20 <@ubitux> fun times: http://lucy.pkh.me/diff/
[14:13] <durandal_1707> that does not mentions features and bug fixs
[14:13] <ubitux> sure that's not complete
[14:15] <ubitux> if you want to insist on bugfixes, you can do stuff like git log --pretty=oneline --grep j00ru|wc -l
[14:15] <ubitux> and compare with the other
[14:15] <ubitux> obviously not complete
[14:16] <ubitux> (i get 521 vs 174 here)
[14:17] <ubitux> well, whatever :)
[14:20] <durandal_1707> zork is just adpcm_ima_wav with 8 bit 
[15:16] <Compn> j-b : fsp support for vlc ? fsp://d97bc8cf9c9a182bf9189ec1af79d31d8c41e592|auto=4|vt=1|c=mr|m=104432|ts=126602240|crt=0|torrent=http://www.btstream.org/fsp/2012-11-19/macross_1353304374_694.fsp
[15:17] <j-b> wtf is fsp?
[15:17] <Compn>  http://en.wikipedia.org/wiki/File_Service_Protocol
[15:17] <Tjoppen> no
[15:18] <Compn> yeah thats wrong
[15:20] <Compn> http://code.google.com/p/btstream/
[15:20] <Compn> gstreamer yay
[15:21] <wm4> gstreamer bridge in ffmpeg when?
[15:21] <j-b> libbtstream seems fine
[15:22] <Compn> sequential bittorrent bah
[15:24] <kierank> sequential bittorrent is good
[15:24] <kierank> as long as the swarm is healthy
[15:25] Action: kierank uses a patched client to do sequential download
[15:25] <av500> just make a player that plays blocks in the order they are downloaded
[15:25] <av500> makes a unique viewing experience
[15:26] <Compn> haha
[15:27] <kierank> probably an improvement for some shows
[15:32] <av500> kierank: in tarantino films, you dont notice
[15:36] <Compn> i'd hate to start playing and it goes for 30 seconds then BUFFERING
[15:36] <Compn> low seeded torrent haha
[15:47] <cone-848> ffmpeg.git 03Luca Barbato 07cbe5a60c9d49: pixdesc: add PIX_FMT_ALPHA flag
[15:47] <cone-848> ffmpeg.git 03Luca Barbato 07d1d9efaae6c7: avcodec: split avpicture from imgconvert
[15:47] <cone-848> ffmpeg.git 03Michael Niedermayer 07494945cb66fa: Merge commit 'd1d9efaae6c7e8466b06c30ca21c6b569dd2e480'
[16:18] <ramiro> michaelni, saste: in libavcodec/codec_desc.c, mpeg2video's long_name says "MPEG-1 video". typo i suppose?
[16:21] <durandal_1707> ramiro: yes
[16:38] <cone-848> ffmpeg.git 03Paul B Mahol 07168a7f06dea7: rawenc: cosmetics: reindent
[16:40] <michaelni> yes, looks like a typo, ill fix it later if noone is faster
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 07be19e7e37396: imgconvert: add self test code
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 070efa240f2bd2: is_yuv_planar: remove use of PixFmtInfo
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 07ad9333d5ef82: imgconvert-test: add avg bits per pixel
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 07649d8bd8a56d: pixdesc: add av_get_padded_bits_per_pixel()
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 070880f26bbe89: avcodec_find_best_pix_fmt_of_2: favor formats with fewer components if it does not incur a loss.
[17:11] <cone-848> ffmpeg.git 03Michael Niedermayer 07f6c439537486: imgconvert: remove PixFmtInfo use from avg_bits_per_pixel()
[17:41] <cone-848> ffmpeg.git 03Paul B Mahol 07e4e7846db830: cdxl: use url_feof()
[17:45] <cone-848> ffmpeg.git 03Michael Niedermayer 07fc04c99deaca: imgconvert: print color type too
[17:45] <cone-848> ffmpeg.git 03Michael Niedermayer 076adf97fe0049: avcodec_get_pix_fmt_loss: remove PixFmtInfo use
[17:45] <cone-848> ffmpeg.git 03Michael Niedermayer 076ff544e473a5: imgconvert: fix color type for non normal pix_fmts like HW stuff and unused entries.
[17:56] <tg2> is it just me or does avconv's ffprobe not have json output?
[17:57] <ubitux> avprobe has a limited json output
[17:57] <ubitux> ffprobe has a more complete one, with more writers
[17:57] <ubitux> if that's what you meant
[17:57] <durandal11707> avconv's probe is called avprobe
[17:59] <tg2> yeah thats what I mean ubitux
[17:59] <tg2> it doesn't seem to be a drop in replacement
[17:59] <tg2> I really don't understand the move to avconv from ffmpeg
[17:59] <tg2> but alas
[17:59] <ubitux> there is no move, it's a fork
[17:59] <tg2> why are distros using avconv?
[18:00] <ubitux> only debian-like afaik
[18:00] <tg2> if it doesn't have the features that ffmpeg has
[18:00] <ubitux> because the debian maintainer is one of the libav folks
[18:01] <durandal11707> tg2: http://blog.pkh.me/p/13-the-ffmpeg-libav-situation.html
[18:02] <Skyler_> avconv is the name of the libav main program, while ffmpeg is the name of the ffmpeg main program
[18:02] <tg2> seems dramatic
[18:03] <Skyler_> it was kind of a mess where most of the main development team split off for political reasons.
[18:03] <Skyler_> (avconv and ffmpeg should be largely similar in functionality though, I think)
[18:03] <tg2> which pulls from which
[18:03] <ubitux> Skyler_: i wouldn't say so
[18:03] <Skyler_> both pull from each other
[18:03] <tg2> they are not similar in functionality
[18:04] <tg2> well, not identical
[18:04] <tg2> rather
[18:04] <tg2> I think the current version of libav in the packaging system is like 2 months old
[18:04] <tg2> lol
[18:04] <Skyler_> That's pretty amazing, the distros used to have 3 year old versions of ffmpeg ;)
[18:05] <Tjoppen> Skyler_: libav cherry-picks
[18:05] <tg2> might be older
[18:05] <Skyler_> isn't cherry-picking the same as pulling?
[18:05] <Skyler_> i.e. using each others' patches
[18:05] <JEEBsv> pulling is merging history
[18:05] <Skyler_> ahhh.  neither pull then, they both cherry-pick
[18:06] <Skyler_> I think
[18:06] <JEEBsv> cherry-picking is trying to apply specific commits from another branch
[18:06] <JEEBsv> (at least that's how I've understood it)
[18:06] <Skyler_> that makes sense
[18:07] <tg2> ffmpeg 7:201211081919-git-1 newer than version in archive
[18:07] <tg2> lol
[18:07] <tg2> noshit
[18:08] <tg2> p   4:0.8.4-0ubuntu0.12.04.1
[18:08] <cone-848> ffmpeg.git 03Luca Barbato 07ae3822bca16f: imgconvert: remove PixFmtInfo
[18:08] <cone-848> ffmpeg.git 03Michael Niedermayer 07b044e81f069c: Merge commit 'ae3822bca16f1cdb2460a35b16f8ef636a04314e'
[18:08] <tg2> that's whats in ubuntu 12.04 repo
[18:08] <ubitux> <Skyler_> both pull from each other // does libav really pull from ffmpeg? i don't see that often TBH.
[18:08] <tg2> well juding by avprobe
[18:08] <tg2> not enough
[18:09] <tg2> doens't support -print_format json
[18:09] <Skyler_> I think a lot of patches get submitted to both libav and ffmpeg?
[18:10] <Skyler_> so it's not always cherry-pickin but sometimes just two separate threads
[18:10] <Skyler_> it's kind of ugly
[18:10] <JEEBsv> aye
[18:10] <kierank> it's largely one way
[18:10] <kierank> imo
[18:10] <JEEBsv> aye
[18:11] <JEEBsv> most stuff goes into ffmpeg from libav, and libav merges after review and clean-up
[18:11] <JEEBsv> thus not a whole lot of stuff goes into lbiav
[18:16] <cone-848> ffmpeg.git 03Justin Ruggles 0700dd9a6d6a5c: pcm: fix decoding of pcm_s16le_planar on big-endian
[18:16] <cone-848> ffmpeg.git 03Diego Biurrun 0717fecb4a5992: flashsv: Drop unused function and struct parameters
[18:16] <cone-848> ffmpeg.git 03Michael Niedermayer 07ea5adf708040: Merge remote-tracking branch 'qatar/master'
[18:16] <Daemon404> hmm
[18:16] <Daemon404> does anyone have any 4:4:4 mpeg2 samples?
[18:17] <Daemon404> ffmpeg cant seem to encode it
[18:17] <durandal11707> you have them?
[18:17] <durandal11707> it can do only 420 and maybe 422 for some of them
[18:18] <Daemon404> i obviously do not have a sample
[18:18] <Daemon404> otherwise i would not ask
[18:21] <durandal_1707> Daemon404: you need 444 mpeg2 samples?
[18:21] <Daemon404> indeed
[18:22] <durandal_1707> but there is no decoder support in ffmpeg
[18:23] <Daemon404> man
[18:23] <Daemon404> what retardism is in that bug
[18:24] <Daemon404> who the hell reverted the fucking link to c99wrap binaries that libav added to teh platform docs
[18:24] <Daemon404> -_-
[18:27] <Daemon404> michaelni, you failed to merge c19e9d00a70616b86ae73111a7579a984c5fa585 correctly
[18:27] <Daemon404> or idneed at all
[18:27] <Daemon404> it points to c99-to-c89 binaries
[18:27] <Daemon404> re: bug 1938
[18:28] <durandal_1707> because it have libav
[18:28] <Daemon404> in the url?
[18:28] <Daemon404> big fuckin whoop
[18:28] <Daemon404> its the offical url for that tool
[18:28] <durandal_1707> i'm just contemplating
[18:30] <michaelni> Daemon404, i do not know if the libav converter works with ffmpeg. OTOH AFAIK ronalds is tested with ffmpeg
[18:31] <durandal_1707> shouldn't they be same?
[18:32] <michaelni> they are 2 seperate repositories
[18:32] <michaelni> one owned by ronald and one by libav
[18:33] <Compn> ronald one google approved?
[18:33] <Compn> libav not so much?
[18:35] <Daemon404> michaelni, ronalds IS libav's
[18:35] <Daemon404> it was moved to that page
[18:35] <Daemon404> ronald's is no longer maintaiend
[18:35] <Daemon404> its the SAME THING
[18:35] <Daemon404> just a new location
[18:35] <iive> durandal_1707: strange, i'm kind of sure that ffmpeg used to be able to decode 444 mpeg2.
[18:36] <Daemon404> michaelni, given i wrote part of the tool i should know...
[18:36] <Daemon404> ronald officially moved it to /libav/
[18:37] <Compn> oh yeah he did
[18:37] Action: Compn remembers now
[18:37] Action: Compn researching when fixing msvc docs
[18:37] <durandal_1707> iive: you have mpeg2 444 sample?
[18:37] <Daemon404> durandal_1707, apparently 4:4:4 is alluded to in the spec
[18:37] <iive> durandal_1707: i'll try to dig it up.
[18:37] <Daemon404> but doesnt really exist in practice
[18:38] <iive> 4:4:4 decoding is defined in the specs, but there is not a profile that uses it.
[18:39] <durandal_1707> well i added mjpeg 444 so it may be possible without of too much work
[18:40] <durandal_1707> but code is so 420 centric and it is hard and slow to grasp 
[18:42] <iive> btw, there is an official test suit from mpeg2... have you looked in there?
[18:43] <durandal_1707> if it is ziper or rared i have better things to do ...
[18:44] <iive> well, it would take a bit more to find it.
[19:10] <TheCycoONE> License question:  I have been suplimenting the outdated 'ffmpeg and SDL Tutorial' by reading ffplay.c.  The final result is some C++ code for using ffmpeg to play movies in a BSD licenced game, but it obviously has some resemblance to ffplay.c because that's where I'm learning from.  Does this end up being a derived work that requires an LGPL licence?
[19:11] <cone-848> ffmpeg.git 03Michael Niedermayer 0760b59d657e4d: codec_descriptors: fix typo in mpeg 2 video
[19:17] <burek> how can I sign up for mailing list to receive ONLY the messages related to the thread I created and/or replied to?
[19:17] <durandal_1707> burek: you cant
[19:19] <burek> it's stupid :(
[19:20] <durandal_1707> burek: you have email client to do that for you
[19:20] <burek> do what for me?
[19:21] <thegeek> TheCycoONE: ffplay is lgpl?
[19:21] <burek> you mean to filter 1 message out of 1000 ?
[19:22] <thegeek> TheCycoONE: oh sorry, I read your message wrong, I thought you said GPL
[19:22] <TheCycoONE> thegeek: that's what it says at the top of the file.
[19:22] <TheCycoONE> ah ok
[19:22] <thegeek> yes;P
[19:25] <durandal_1707> burek: to filter messages that you are not insterested in
[19:26] <burek> durandal_1707, you are actually serious in what you are suggesting?
[19:26] <thegeek> burek: afaik that is not possible, I've never seen a mailing list that can filter for you
[19:26] <burek> it's like your isp provider would tell you "well fiter out packets you don't need" when you experience a flood :)
[19:27] <burek> that's why forums are better :)
[19:27] <thegeek> filtering mail is hardly that intensive
[19:27] <thegeek> and if you use gmail etc you can always do the filtering on the server
[19:35] <michaelni> burek, you can also use gmane
[19:35] <michaelni> if you like its interface better than your mail user agents
[19:36] <burek> im not participating in this conversation :)
[19:37] <burek> I thought there is some value/reason why ML is still used, although ancient..
[19:37] <burek> but I believe it's just being used because it's simple and works
[19:37] <burek> nothing else
[19:38] <thegeek> it also raises the bar on making a post for newcomers while better exposing new posts to subscribers
[19:39] <thegeek> which can be seen as both good and bad
[20:08] <cone-848> ffmpeg.git 03Peter Ross 070705cbd0026f: bink: return AVERROR_EOF upon reaching end of file
[20:08] <cone-848> ffmpeg.git 03Michael Niedermayer 07c9ad2e9aa3da: imgconvert: remove avg_bits_per_pixel(), its redundant
[20:08] <cone-848> ffmpeg.git 03Michael Niedermayer 071dafbdac65ca: pixdesc: fix alpha flags
[20:08] <cone-848> ffmpeg.git 03Michael Niedermayer 072c5d9111663e: imgconvert-test: test alpha flags
[20:23] <cone-848> ffmpeg.git 03Stefano Sabatini 076ca9c74cc64f: ffprobe: add "," at the end of enum list
[20:23] <cone-848> ffmpeg.git 03Stefano Sabatini 0764dc383de566: ffprobe: fix typo in a comment
[20:26] <cone-848> ffmpeg.git 03Michael Niedermayer 07fb1bb97d875e: imgconvert-test: skip pix formats without name
[20:26] <cone-848> ffmpeg.git 03Michael Niedermayer 07b93c933cd253: imgconvert-test: count the number of unused pixel format values.
[20:26] <tg2> yeah sort of doesn't make sense that you get mailed for every item when you only reply to one in a mailing list.
[20:26] <tg2> if i post in a forum, I don't get an email every time somebody else posts to the same forum, only thread.
[20:29] <durandal_1707> enough trolling
[20:37] <ubitux> saste: please add an example for the tags in the -show_entries doc
[20:51] <saste> today i learned what a tinfoil hat is
[20:53] <ubitux> :D
[20:59] <saste> the way ffmpeg deals with input timestamps is somewhat like black magik
[21:01] <ubitux> michaelni: do you mind re-sync the c99-to-c89 thing with libav's doc so it could help to calm down a bit the related thread?
[21:02] <Compn> ubitux : why not you do it? :)
[21:02] <ubitux> because michaelni might not agree with it
[21:03] <ubitux> and because i'm not sure what was removed originally
[21:03] <Compn> he wont bite :)
[21:03] <Compn> ah
[21:06] <michaelni> ubitux, id like to give ronald a chance to reply
[21:07] <michaelni> that is before making any changes to the docs
[21:14] <durandal_1707> wtf happened to yop and ima adpcm ima apc
[21:15] <durandal_1707> omg what a typo
[21:16] <durandal_1707> but why fate did not break....
[21:18] <cone-848> ffmpeg.git 03Paul B Mahol 078e6957964e03: yop: fix 10l typo
[21:19] <durandal_1707> ^because of -an
[21:35] <durandal_1707> michaelni: can you just clone c99/wrap/conv into github.com/ffmpeg or any other?
[21:38] <ubitux> please don't do that
[21:38] <ubitux> if the "libav url" is the official repo
[21:41] <Daemon404> that seems liek pointless forking to me
[21:41] <Daemon404> given we test it with ffmpeg
[21:41] <Daemon404> hell, i exclusively use ffmpeg with it
[21:41] <ubitux> i agree
[21:43] <durandal_1707> but it is under libav umbrella
[21:44] <ubitux> as long as it's the official place for the project, and that the politic about ffmpeg/other-projects is clearly stated i see no point in forking it
[21:44] <ubitux> if it breaks with ffmpeg but not libav, we can still, in the worst case, fork it
[21:44] <ubitux> that's not the case, and i believe it won't happen
[21:44] <Daemon404> premature forking is a serious condition
[21:44] <Daemon404> talk to your doctor if you experience it
[21:44] <ubitux> and as Daemon404 pointed out, it's tested by fate
[21:45] <michaelni> Daemon404, honestly, you lately sound like mru
[21:45] Action: ubitux didn't want to say it
[21:46] <llogan> when did mru gain a sense of humor?
[21:46] <ubitux> haha
[21:46] <Daemon404> maybe if some sanity was gained once i na while
[21:46] <Daemon404> and less tinfoil hat
[21:46] <Daemon404> i wouldnt be
[21:46] <Daemon404> :|
[21:47] <Daemon404> :)
[21:47] <ubitux> is this a shame bit?
[21:47] <Daemon404> no
[21:47] <gnafu> It's a cross to keep away vampires...?
[21:47] <ubitux> a hat?
[21:47] <gnafu> A pope hat XD.
[21:48] <durandal_1707> he is demoding himself lets /kb him
[21:48] <ubitux> which brings us to http://24.media.tumblr.com/tumblr_m55go4Nsvl1rsslhno1_500.jpg
[21:48] <gnafu> Nice.
[21:48] <llogan> i want to replace it with a hot dog
[21:48] <llogan> i mean i want someone else to replace it with a hot dog
[21:49] <Daemon404> people might take less issue with me pointing out insanity if i am a commoner
[21:49] <Daemon404> and not a dev/op
[21:50] <llogan> that's insane
[21:50] <durandal_1707> Daemon404: you cant give yourself +o any more?
[21:50] <Daemon404> i could gain it back with /cycle
[22:02] <ubitux> ccache: FATAL
[22:02] <ubitux> yay.
[22:09] <Daemon404> ubitux, isnt ccache on ffmpeg kind of useless
[22:09] <Daemon404> every configure makes a new config.h, which differs
[22:09] <ubitux> not at all, why?
[22:09] <Daemon404> changing the hashes of ALL objects
[22:09] <Daemon404> thus everything is rebuilt anywya
[22:10] <ubitux> it clearly is faster here
[22:10] <Daemon404> youve timed it?
[22:10] <ubitux> i'm going to
[22:10] <Daemon404> ccache utterly failed on ffmpeg every time ive tried
[22:10] <Daemon404> also you have to do a fresh configure
[22:10] <Daemon404> a simple remake will not suffic
[22:10] <ubitux> really? i've seen a difference
[22:10] <Daemon404> e
[22:11] <ubitux> yes, distclean as well
[22:11] <Daemon404> yes it Doesn't Work
[22:11] <Daemon404> otherwise id have set my arm/netbsd box to be on FATE
[22:16] <ubitux> Daemon404: http://pastie.org/private/m7282th4fy67q3nlwelb9g
[22:17] <kierank> Daemon404: wiorks4 m e
[22:17] <kierank> works4me*
[22:17] <cbsrobot> -j20 only ?
[22:18] <ubitux> i know i could go twice faster with -j40
[22:18] <ubitux> but i don't want to see the world burning
[22:18] <Daemon404> also you didnt do a control
[22:18] <kierank> on an ssd ccache is impressive
[22:18] <ubitux> Daemon404?
[22:18] <cbsrobot> so configure takes 2 min and make 20 sec ...
[22:19] <Compn> lol @ c99 thread
[22:19] <Compn> whats wrong with you guys :D
[22:19] <ubitux> Compn: it's just ffmpeg devs being stupids and paranoid
[22:19] <Compn> probably my fault, i just said i'd like to mirror the tools :P
[22:19] <Daemon404> ubitux, humm weird
[22:20] <Daemon404> cause the "time build" in config.h always changes for me
[22:20] <Daemon404> time built*
[22:20] <Daemon404> i.e. the date
[22:20] <Daemon404> and config.h is in -everything-
[22:20] Action: Daemon404 no understands
[22:20] Action: kierank gets the popcorn out
[22:20] <ubitux> Daemon404: isn't it based on checksum?
[22:21] <Daemon404> checksum after preprocessing
[22:21] <Daemon404> otherwise itd be wrong
[22:21] <ubitux> wait, what's the time build you are talking about?
[22:21] <ubitux> fs info or something in it?
[22:21] <Daemon404> built on Mar  6 2012 21:27:20 with gcc 4.6.2
[22:21] <Daemon404> ^ date
[22:22] <wbs> ... which doesn't end up in the preprocessed output for most object files
[22:22] <wbs> so the hash of the preprocessor output shouldn't change anyway
[22:22] <ubitux> Daemon404: ah, ok
[22:22] <Daemon404> wbs, it isnt in config.h?
[22:22] <ubitux> i don't have this :)
[22:22] <ubitux> #define CC_IDENT "gcc 4.7.2 (GCC)"
[22:22] <wbs> Daemon404: yes, but after preprocessing, the #define itself isn't there, only the places where it's expanded, if any
[22:22] <Daemon404> true
[22:22] <wbs> Daemon404: in most files except cmdutils or so, it won't be expanded
[22:23] <wbs> so it won't change the hash of the preprocessor output
[22:23] <Daemon404> then why does ccache rebuilt every file when i reconfigure
[22:23] <Daemon404> @_@
[22:23] <Daemon404> demons!
[22:23] <ubitux> just make sure that date doesn't appear :p
[22:24] <ubitux> isn't this date the built date of gcc?
[22:24] <Daemon404> no
[22:24] <Daemon404> ffmpeg version N-38607-g57986c5 Copyright (c) 2000-2012 the FFmpeg developers built on Mar  6 2012 21:27:20 with gcc 4.6.2 (x86.generic.Komisar)
[22:24] <Daemon404> example
[22:24] <ubitux> march 6?
[22:25] <Daemon404> but as wbs explained, thats not it
[22:25] <Daemon404> yes its an old built
[22:37] <ubitux> saste: btw, should we do some testing for drawtext?
[22:37] <ubitux> like just running it, without actually checking the output
[22:37] <ubitux> just a pass to check for crashes/leak/etc
[22:38] <ubitux> and/or maybe make the filter inject metadata
[22:38] <ubitux> (typically the text written)
[22:40] <Daemon404> drawtext?
[22:41] <ubitux> Daemon404: something you don't care about, lavfi :(
[22:42] <saste> ubitux, so we depend on an external library
[22:42] <Daemon404> ubitux, im merely curious if it's libass
[22:42] <saste> we have no guarantee that different libfreetype issue the same output
[22:42] <Daemon404> or manual freetype etc
[22:42] <ubitux> saste: lib dep is possible for the fate test, and the point was indeed not to test the output as i said, because of this
[22:42] <ubitux> Daemon404: nope, drawtext is freetype
[22:42] <ubitux> ass filter uses libass
[22:43] <Daemon404> ah.
[22:43] <saste> which in turn uses libfreetype, right?
[22:43] <Daemon404> i wrote a small text-printign function recvently
[22:43] <Daemon404> but i converter terminus into a c header
[22:43] <Daemon404> and blitted it into video
[22:43] <Daemon404> lol.
[22:43] <ubitux> saste: yes, and various other libs
[22:43] <ubitux> Daemon404: i did something similar pour ebur128 :)
[22:44] <ubitux> for*
[22:44] <ubitux> wtf i'm writing french in the middle of the sentence
[22:44] <ubitux> ah, someone was talking in french in another terminal, brainfart reading it
[22:44] <Daemon404> i thought you were just being accentric
[22:44] <saste> lucky you was not writing in ancient greek
[22:44] <Daemon404> eccentric*
[22:45] <ubitux> Daemon404: there are some cga fonts in lavu, you can use them!
[22:45] <ubitux> :)
[22:46] <Daemon404> maybe
[22:46] <ubitux> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavfilter/f_ebur128.c;hb=HEAD#l177
[22:46] <ubitux> :p
[22:48] <Daemon404> ill stick with terminus
[22:48] <ubitux> :)
[22:48] <Daemon404> i use a perl script to generate the header at compile time
[22:48] <Daemon404> less hueg repo
[22:49] <michaelni> vf_drawtext + vf_ocr fate test 
[22:49] <ubitux> :D
[22:49] <ubitux> i hope we will have subtitles in lavfi soon
[22:49] <ubitux> so we can do some vf sed and stuff all around
[22:49] <ubitux> -sf*
[22:50] <saste> so you can detect and blip bad words
[22:50] <ubitux> yup, advanced censorship filter
[22:51] <michaelni> we need a filter that detects blips and puts a random bad word in 
[22:51] <ubitux> @_@
[22:52] <Daemon404> vf_tbs
[22:53] <ubitux> tech bitch syndrom?
[22:57] <Daemon404> tbs as in the tv channel
[22:57] <Daemon404> owned by ted turner
[22:58] <saste> is anyone aware of a decent speech recognition engine which could be integrated into ffmpeg?
[22:59] Action: Daemon404 is not aware of any decent one period...
[22:59] <ubitux> speech recognition is really hard afaict
[23:02] <michaelni> btw we need a a/vsrc_hatsune_miku filter
[23:03] <ubitux> :D
[23:03] <ubitux> i think divVerent can help here ;)
[23:37] <cone-848> ffmpeg.git 03Piotr Bandurski 07425d0888c3e8: bfi: signal EOF
[23:37] <cone-848> ffmpeg.git 03Piotr Bandurski 071ed7ca00dccb: bethsoftvid: signal EOF
[23:41] <llogan> my best work yet
[23:48] <llogan> now to slap a perpetual "under construction" gif and midi music and call it good.
[00:00] --- Thu Nov 22 2012