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

[burek]

[00:01] <beastd> Please read and improve!
[00:02] Action: beastd is not that happy yet
[00:05] <beastd> I hope I got the most important stuff down in a clear enough fashion. also the whole document could be a bit more fun ;) But that is over me tonight.
[00:14] <KGB> [FFmpeg] michaelni pushed 2 new commits to master: http://git.io/ZwQ2fA
[00:14] <KGB> [FFmpeg/master] doc/fate: Move fate config example into doc subdirectory - Alexander Strasser
[00:14] <KGB> [FFmpeg/master] cyuv: implement raw cyuv - Michael Niedermayer
[00:25] <ubitux> beastd: make: *** No rule to make target `doc/../tests/fate_config.sh.template', needed by `doc/fate.html'.  Stop.
[00:26] <ubitux> :(
[00:26] <ubitux> mmh maybe an old dep.
[00:26] <beastd> ubitux: seems so
[00:26] <beastd> there is no such path in the new version
[00:27] <ubitux> yeah my bad
[00:32] <iive> beastd:  i don't like the term "bitrod" and I'll be glad if you avoid it. Would you please just replace the sentence so that is says "keep their code in working condition as new versions...." etc.
[00:37] <beastd> iive: would "keeping their code in shape as new version..." also sound good to you? or is it too informal?
[00:39] <iive> imho, working condition resonates more with the idea of maintenance 
[00:42] <beastd> iive:  OK, thanks. Done.
[00:47] <ubitux> michaelni: http://b.pkh.me/0001-swscale-fix-To-Y-UV-extern-protoypes.patch
[00:48] <ubitux> does this make any sense?
[00:48] <ubitux> it's fixing all these warnings for me: http://pastie.org/4867868
[00:49] <ubitux> it's based on the prototypes from yuy2ToY_c and yuy2ToUV_c from sws/input.c
[00:49] <iive> it is the first time i see "she" used as general term. I think it is kind of standard to use "they" even as singular). Not really that important.
[00:49] <ubitux> and the pointer types
[00:50] <beastd> iive: might need further grammatical changes to that sentence. so postponing it for now
[00:51] <iive> something else. It may be good idea to mentions somewhere that the position doesn't give you any additional (super) powers, only more work to do.
[00:52] <ubitux> (typo protoypes/prototypes fixed)
[00:53] <ubitux> btw, these warnings look weird:
[00:53] <ubitux> libswscale/swscale.c:587:31: warning: assignment from incompatible pointer type [enabled by default]
[00:53] <ubitux> libswscale/swscale.c:588:31: warning: assignment from incompatible pointer type [enabled by default]
[00:53] <ubitux> libswscale/swscale.c:619:35: warning: assignment from incompatible pointer type [enabled by default]
[00:54] <ubitux> mix of int16/int32
[00:55] <beastd> iive: agreed. but please don't be upset if i won't add it soon.
[00:56] <iive> beastd: no problem, I don't see good spot to put it atm. and the (super) powers thing is a joke... in case it is not obvious.
[00:56] <beastd> :)
[00:56] <beastd> and yeah you are right the document isn't as complete as i wish it to be (certain aspects that deserve mention are missing completely)
[01:13] <beastd> i am leaving. thank you for the help. good night...
[09:52] <saste> ubitux: should I push the two remaining ffprobe patches?
[10:26] <ubitux> saste: maybe explicit that SECTION_FLAG_HAS_VARIABLE_FIELDS requires the element_name field, but anyway should be ok
[10:26] <ubitux> though, "variable fields" isn't really explicit but well
[10:26] <ubitux> the other patch is ok
[10:27] <saste> ubitux: variable_keys?
[10:27] <saste> ubitux: variable_field_keys?
[10:27] <ubitux> i have a problem with "variable" actually :p
[10:27] <saste> variable = nonfixed
[10:28] <ubitux> i can't tell at first what's variable
[10:28] <ubitux> if it's the number of entries or anything
[10:28] <saste> it's the number and the keys of the entries
[10:28] <saste> it is describing a "tags" section
[10:29] <saste> you don't know how many tags, you don't know which are the keys
[10:29] <ubitux> you should explicit that in the doxy then :)
[10:29] <saste> yes
[10:29] <ubitux> because the name isn't that obvious imo
[10:30] <saste> i'll keep the name and extend the doxy
[10:30] <ubitux> okay
[10:30] <ubitux> so well, both ok :)
[10:31] <ubitux> oh Nicolas finally pushed the av_opt_set_from_string patch
[10:31] <saste> \o/
[10:32] <ubitux> i don't remember, you were waiting for this for what purpose?
[10:32] <saste> a lot of purposes :)
[10:32] <ubitux> :D
[10:32] <ubitux> you're gonna change the world now then
[10:32] <saste> so we can drop the lame sscanf in many filters
[10:33] <saste> and avoid to keep ad-hoc backward compatibility checks
[10:33] <ubitux> ok :)
[10:33] <saste> it also should simplify some stuff, for example when you add a new param in a filter which was supporting only one argument
[10:33] <saste> for example the volume filter
[10:34] <ubitux> ah right, libav changed the syntax to the key=value form
[10:34] <saste> (which BTW they rewrote in libav)
[10:34] <ubitux> would be nice to support both
[10:34] <saste> i feel the dB = deciBel thing a bit silly
[10:35] <saste> ubitux, no the best thing is to pull the libav filter
[10:36] <saste> they did some nice improvements (like optimizations)
[10:36] <ubitux> i meant supporting both syntax
[10:36] <ubitux> like volume=value:... and volume=volume=value:...
[10:36] <ohsix> Bel :D
[10:36] <saste> yes
[10:37] <saste> volume=+10dB:precision=...
[10:37] <saste> is acceptable once you make use of av_opt_set_from_string()
[10:37] <saste> same as: volume=+10dB
[10:37] <saste> so we save backward compatibility
[10:37] <ubitux> yup
[10:37] <ubitux> and peace on earth
[11:23] <ubitux> [~/src/ffmpeg/libavfilter]- make
[11:23] <ubitux> rm -f 
[11:23] <ubitux> this is pretty funny.
[11:44] <ubitux> cbsrobot_: the sound of your sample is pretty awesome :)
[12:03] <saste> ubitux: how is it going with your EBU R.128 filter?
[12:04] <ubitux> i'm trying to fix a small bias with the results from another app cbsrobot_ provided me
[12:04] <ubitux> i've fixed locally what you pointed me out
[12:04] <ubitux> it should be applied this week
[12:04] <ubitux> maybe tonight if i suceed in fixing the problem
[12:05] <saste> ubitux, great
[12:06] <saste> did you receive any feedback relating to the CGA fonts thing?
[12:06] <saste> anyway I think that's safe to apply
[12:07] <ubitux> no, no feedback about the cga thing
[13:30] <KGB> [FFmpeg] michaelni pushed 4 new commits to master: http://git.io/RjLJHA
[13:30] <KGB> [FFmpeg/master] opt: implement av_opt_set_from_string(). - Nicolas George
[13:30] <KGB> [FFmpeg/master] lavu/opt: cosmetic fixes forgotten in the previous patch. - Nicolas George
[13:30] <KGB> [FFmpeg/master] ffprobe: generalize nesting model for the XML writer - Stefano Sabatini
[14:25] <ubitux> 14:03:53 < twnqx> Starting with 1.7.7 MakeMKV for Windows and Mac OS comes with a (patched) copy of ffmpeg. The biggest difference between MakeMKV's mmffmpeg and a stock version, is a FLAC encoder that handles 24-bit audio. If you need this functionality, the full mmffmpeg source code is available at http://www.makemkv.com/download/ffmpeg .
[14:25] <ubitux> i confirm the patch includes 24-bit flac encoding
[14:26] <ubitux> it seems to make ffmpeg sws dependency optional as well
[14:27] <ubitux> not sure if that's a good idea though
[14:39] <ubitux> saste: would it make sense to add a timing format following hh:mm:ss.xxx instead of just ss.xxx?
[14:39] <ubitux> +function
[14:39] <ubitux> (or change av_ts_make_time_string)
[14:40] <saste> ubitux, where do you need it?
[14:40] <saste> we have code that does that in several places (ffprobe.c amongst the others)
[14:41] <ubitux> i added the pts time in the av_log output of ebur128 filter
[14:41] <ubitux> and i though a more expressive timing information would be nice
[14:42] <ubitux> (where in ffprobe?)
[14:42] <saste> -pretty
[14:43] <ubitux> oh, right.
[14:43] <ubitux> then maybe a av_ts_make_pretty_time_string would be nice
[14:44] <ubitux> (along with av_ts2prettytimestr)
[14:44] <ubitux> i would reduce the precision though
[14:45] <ubitux> something like %02d:%02d:%02d.%03d
[14:45] <ubitux> (easy to align, and re-use as cmd line)
[15:10] <durandal_1707> michaelni: so if get_bits_long is used with n>32 other bits are going to be lost?
[15:14] <michaelni> durandal_1707, yes or worse ...
[15:15] <michaelni> get_bits_long could be changed to int64 but its not needed for 99% of the code so feels a bit odd
[15:23] <durandal_1707> in 24 bit case i prefer to not do extra copy, same is already done for tta
[15:26] <KGB> [FFmpeg] michaelni pushed 18 new commits to master: http://git.io/frLsCA
[15:26] <KGB> [FFmpeg/master] indeo3: fix out of cell write. - Anton Khirnov
[15:26] <KGB> [FFmpeg/master] indeo5: check tile size in decode_mb_info(). - Michael Niedermayer
[15:26] <KGB> [FFmpeg/master] ivi_common: make ff_ivi_process_empty_tile() static. - Anton Khirnov
[15:27] <michaelni> durandal_1707, agree but i think the allocated buffer pointer should be kept seperate
[15:27] <michaelni> because now IIRC if its assigned to frame and then something goes wrong (return -1 whatever)
[15:28] <michaelni> the wrong ptr would be freed
[15:41] <ubitux> it seems the threading problem is not arch specific (the 2 threads arm instance failed)
[15:42] <ubitux> just once: http://fate.ffmpeg.org/history.cgi?slot=armv7l-panda-gcc4.6-cortexa8-threads2 :)
[15:42] <michaelni> yes, i saw it
[15:43] <michaelni> its a pitty that its not readily reproduceable otherwise it would be relatively easy tp debug
[15:51] <ubitux> michaelni: at some point, maybe some gdb scripting could help; like forcing a break if it's writing 0xB2 instead of 0xB1 at 0x000A8160
[15:51] <ubitux> and then run over and over again the test until it's triggered
[15:52] <ubitux> i'm not familiar with gdb and its scripting system though, and i don't think i would be able to debug it even i triggers it :p
[16:08] <cbsrobot_> ubitux: yeah - it's my favorite soundtrack atm ...
[16:21] <ubitux> (cia story: http://pastebin.com/9RBBniM1)
[16:36] <Compn> ubitux : shouldnt we be shaming this new hosting company due to bad hosting practises ?
[16:36] <Compn> and by shame i mean full out internet blacklist against this company ...
[16:36] <Compn> never forget never forgive.
[16:37] <ubitux> no one should ever trust its data to a any company...
[16:38] <ubitux> you can't blame the company for your own negligence
[16:38] <Compn> it wasnt him who rm rf-d 
[16:38] <ubitux> as soon as you realize every company is evil, the obvious move is to take care of its own data
[16:38] <ubitux> whatever
[16:38] <Compn> cant blame the company? thats what i'm doing.
[16:38] <ubitux> you *know* that at some point a company will disapear or just delete your data
[16:39] <Compn> but yeah, why wasnt cia.vc on github or some repo where people could copy it ?
[16:39] <Compn> was it open source ?
[16:39] <ubitux> the code still exists afaict
[16:39] <ubitux> it's the data that's missing (not sure what that means though)
[16:39] <ohsix> no backups is kind of low rent, they're as much to keep the provider from fucking things up
[16:39] <ubitux> (https://code.google.com/p/cia-vc/)
[16:40] <ohsix> "atheme infrastructure" -> databases that weren't backed up, and possibly code for services that wasn't public, no?
[19:53] <Daemon404> j-b, you see the ML? re: DCP
[19:54] <j-b> Daemon404: yes, I saw that
[19:54] <j-b> Daemon404: I am just wondering WTH do XYZ to RGB and not XYZ to YUV ?
[19:55] <j-b> and also, shouldn't that be in swscale? WTH²
[19:55] <nevcairiel> for display purposes, i guess
[19:55] <Daemon404> j-b, yes
[19:55] <Daemon404> it shoud be in swscale
[19:55] <nevcairiel> no, swscale should not be :P
[19:55] <j-b> nevcairiel: so?
[19:55] <Daemon404> nevcairiel, it should be in swscale, but swscale should not be
[19:56] <nevcairiel> you display rgb, rarely do you directly display yuv
[19:56] <j-b> what?
[19:56] <nevcairiel> also, having no idea about XYZ, maybe it converts to RGB easier? :d
[19:56] <Daemon404> hes right, but thats irrelevant
[19:56] <Daemon404> im not sure how easy XYZ fits into swscale
[19:56] <j-b> I disagree
[19:56] <Daemon404> given how annoying even planar rgb is
[20:03] <nevcairiel> anything non-YUV is really even less fun then usual in swscale
[20:44] <durandal_1707> michaelni: i'm using scalarproduct_int16 (appears there is MMX only) and benefits are marginal, reference decoder is ~%33 faster
[20:48] <michaelni> durandal_1707, theres ff_scalarproduct_int16_sse2 that should get used
[20:48] <durandal_1707> pure C appears to be slightly slower than pure Delphi
[20:49] <durandal_1707> my cpu have sse2 and ssse3 and sse2 is slower than ref mmx
[20:49] <durandal_1707> ref have ssse3 which is even faster
[20:50] <durandal_1707> (it does not have sse2 at all)
[20:51] <durandal_1707> would branching cause this?
[20:51] <durandal_1707> because our scalarproduct works only for order multiply of 16
[20:52] <ubitux> saste: ping
[20:53] <saste> ubitux: pong?
[20:53] <KGB> [FFmpeg] michaelni pushed 4 new commits to master: http://git.io/YpWSUQ
[20:53] <KGB> [FFmpeg/master] Move subrip/text API change info from Changelog to doc/APIchanges. - Clément BSsch
[20:53] <KGB> [FFmpeg/master] APIchanges: fill hashes. - Clément BSsch
[20:53] <KGB> [FFmpeg/master] swscale: fix To{Y,UV} extern prototypes. - Clément BSsch
[20:53] <ubitux> saste: http://b.pkh.me/0001-lavfi-ashowinfo-check-plane-value-before-deferencing.patch
[20:53] <ubitux> does this make any sense to you?
[20:53] <ubitux> (spotted because gcc was complaining)
[20:54] <saste> ubitux, ok if it fixes a problem / a warning
[20:55] <ubitux> thx, pushed
[21:06] <cbsrobot_> Daemon404: maybe he stared 29.5h at swscale and then decided to do it in lavfi, which took him half an hour
[21:06] <Daemon404> lol
[21:06] <Daemon404> probably
[21:40] <saste> ubitux: BTW ashowinfo should check extradata
[21:44] <ubitux> saste: you mean extended_data?
[21:44] <saste> yes
[21:45] <ubitux> have fun doing it :)
[22:11] <ubitux> argh f* bug, wth is wrong with my code :(
[22:21] <KGB> [FFmpeg] michaelni pushed 4 new commits to master: http://git.io/b-ZUJw
[22:21] <KGB> [FFmpeg/master] lavfi/ashowinfo: check plane value before deferencing. - Clément BSsch
[22:21] <KGB> [FFmpeg/master] qt-faststart: speedup - Jan Ehrhardt
[22:21] <KGB> [FFmpeg/master] qt-faststart: dont allocate a bigger buffer than needed - Michael Niedermayer
[22:48] <ubitux> cbsrobot_: ok i think i fixed the integrated loudness :)
[23:29] <cbsrobot_> ubitux: nice
[23:43] <KGB> [FFmpeg] michaelni pushed 2 new commits to master: http://git.io/Z53AzQ
[23:43] <KGB> [FFmpeg/master] swscale: move main swscale wraper to swscale.c - Michael Niedermayer
[23:43] <KGB> [FFmpeg/master] sws: drop unused variable - Michael Niedermayer
[23:52] <KGB> [FFV1] michaelni pushed 1 new commit to master: http://git.io/lQJlQg
[23:52] <KGB> [FFV1/master] Document minor_version - Michael Niedermayer
[00:00] --- Mon Oct  1 2012