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

[burek]

[00:10] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rfecdc76a9f 10ffmpeg/libswresample/audioconvert.c: 
[00:10] <CIA-122> ffmpeg: swr: fix cpy() after the len was changed to be in samples.
[00:10] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:10] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rbd1d975cd0 10ffmpeg/libswresample/audioconvert.c: 
[00:10] <CIA-122> ffmpeg: swr: fix silence buffer for planar U8
[00:10] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:10] <CIA-122> ffmpeg: 03Robert Nagy 07master * r4f5c5416ca 10ffmpeg/libavfilter/vf_yadif.c: 
[00:10] <CIA-122> ffmpeg: yadif: Add yuva444p to format list.
[00:10] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[01:04] <Compn> i'd love to talk secret watermarking techniques
[01:04] <Compn> but since its evil, i wont
[01:04] <Compn> like the zzuf guy, he made a captcha beating software to test which captcha was the best. but he didnt release it due to nefarious uses 
[01:05] <Compn> even if you are on the other side of it, can be reverse engineered from your code :P
[01:05] <Daemon404> i dont really see any legit uses for captcha breaking...
[01:09] <Compn> to ... test if your captcha was good ? :P
[01:09] <Compn> i dunno 
[01:09] <Compn> ehe
[01:09] <ohsix> making better captchas ya
[01:10] <Compn> http://caca.zoy.org/wiki/PWNtcha
[01:11] <Compn> there it is
[01:11] <Compn> Given the number of captcha-breaking software available for sale now, I changed my mind and decided to publish the PWNtcha source code. It can be downloaded from Subversion:
[01:11] <Compn> lol
[01:11] <Compn> well i have outdated information so dont listen to me :P
[01:14] <ohsix> some people affiliated with GNAA had uses for it ;] and they helped him "research" it, they used it for some stuff but i always ignored what they were doing
[01:14] <Daemon404> lulz
[01:14] <Daemon404> of course timecop has links to something called caca
[01:14] <ohsix> not caca, but pwntcha
[01:15] <ohsix> sam is cool
[01:15] <ohsix> fwiw, timecop pretty much ignored those guys too
[01:15] <Daemon404> timecop doesnt seem the type to be interesting in captchas.
[01:16] <Daemon404> interested*
[02:47] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r16b9156b7e 10ffmpeg/libavformat/ffmdec.c: 
[02:47] <CIA-122> ffmpeg: ffm: disable adjust_write_index()
[02:47] <CIA-122> ffmpeg: This code can in its current form not work with ffserver
[02:47] <CIA-122> ffmpeg: Fixes Ticket1249
[02:47] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[10:07] <cbsrobot_> huh - there is no yuva422p pixel format ?
[10:08] <cbsrobot_> is it non existent ?
[12:34] <wolfgangw> Hi, trying to play an encrypted MXF with "ffplay -cryptokey fbcb09cf602548101aeaa4857a286524 j2c.mxf" which returns "Operation not permitted". I see that EPERM is returned only from libavformat/rtsp.c. does that make sense to anyone?
[13:24] <Compn> wolfgangw : i didnt know -cryptokey worked with anything but wmv...
[13:24] <Compn> you sure ffmpeg supports encrypted mxf ?
[13:25] <wolfgangw> don't know at all
[13:25] <wolfgangw> just tried
[13:25] <wolfgangw> there's my answer, thanks
[13:31] <cbsrobot_> wolfgangw - you're behind https://github.com/wolfgangw ?
[13:34] <wolfgangw> cbsrobot_, yes
[13:35] <cbsrobot_> what you want to accomplish with ffmpeg ? encoding ? decoding ?
[13:35] <wolfgangw> right now I'm looking at ways to playback stuff
[13:36] <cbsrobot_> ok
[13:39] <cbsrobot_> I guess there are several issues if you want to accomplish it ... and we could use some help !
[13:39] <cbsrobot_> but the culprit is mostly openjpeg beeing too slow
[13:41] <cbsrobot_> but j-b from videolan could spend some money if you can help speed up j2k decoding - (am I right j-b ?)
[13:41] <av500> and j2b
[13:43] <wolfgangw> let me look something up ... there: http://reduser.net/forum/showthread.php?33118-Digital-Cinema-Package&s=0a58a55a491c7e59a02df9812922df70&p=597220&viewfull=1#post597220
[13:43] <j-b> cbsrobot_: yep
[13:45] <wolfgangw> j-b, may i ask what project you are working on?
[13:45] <cbsrobot_> wolfgangw: is this merged in openjpeg 1.5 ?
[13:45] <wolfgangw> good question, i'll check
[13:47] <Compn> what i want to see are people cracking the digital projection system stuff ;D
[13:47] <cbsrobot_> because in my opinion openjpeg 1.5 is not significantly faster for dcp decoding then 1.4  
[13:47] <j-b> wolfgangw: not working on anything
[13:48] <Compn> cant the gpu offload some of the jp2k stuff ?
[13:48] <Compn> ehe
[13:48] <cbsrobot_> j-b: it always the same with you .... lol
[13:49] <cbsrobot_> wolfgangw: see http://cuj2k.sourceforge.net/
[13:49] <j-b> cbsrobot_: ?
[13:49] <wolfgangw> cbsrobot_, yes, it is in openjpeg.googlecode.com/files/openjpeg-1.5.0.tar.gz
[13:49] <cbsrobot_> j-b not workin i meant
[13:49] <j-b> I :)
[13:49] <Compn> wolfgangw : j-b is/was lead devel of videolan :)
[13:49] <wolfgangw> k, hi j-b 
[13:50] <Compn> we hold him in highest reguards here :)
[13:50] <j-b> I just see a lot of requests for DCP playback in VLC. GOod idea? Bad idea? Not my problem. But decreasing the number of support mail is my problem :)
[13:51] <wolfgangw> cbsrobot_, yes, the cuj2k people (university stuttgart) have done it, only they've not implemented the digital cinema related jpeg2000 profiles.
[13:52] <wolfgangw> gpu-based is all nice and dandy but i'm explicitly looking at a generic way which will work anywhere, not requiring people to have a specific gpu and all that
[13:53] <wolfgangw> j-b, i hear you :)
[13:54] <j-b> wolfgangw: as we got a bit of money for bounties, those days... You do the math
[13:55] <wolfgangw> ffplay with -threads x is already quite decent. now if it were able to use lower resolution layers from the codestream (i'm not entirely sure that this would decrease decode load though) it might work rather well for preview purposes
[13:56] <cbsrobot_> on http://cuj2k.sourceforge.net/cuj2k.html they say that the tier1 (which takes up to 90% of computation time) cannot be parallised
[13:56] <cbsrobot_> wolfgangw: how many fps you get with what machine ?
[13:57] <cbsrobot_> I get up to 8fps on a dual 6 core with ht for a 2k dcp
[13:58] <j-b> 12 core?
[13:58] <cbsrobot_> yeah something like this
[13:58] <j-b> how can openjpeg be _that_ slow?
[13:58] <cbsrobot_> I never remember the specs
[13:58] <Compn> so cant use lowres with j2k ?
[13:59] <cbsrobot_> j-b: see http://cuj2k.sourceforge.net/Benchmark.html
[13:59] <wolfgangw> sorry, i'm jumping between here and making a tiramisu for the first time ever which seems equally diffcult i'm afraid
[13:59] <cbsrobot_> Compn: sure - tried that aswell but not much difference
[14:00] <cbsrobot_> I think j2k could potentially be encode with several layers of resolution
[14:01] <cbsrobot_> but I think cinemadcp specs allow only 1 layer - so there is no real speed benefit for lowres
[14:01] <Compn> is our j2k decoder faster than openjpg ?
[14:02] <cbsrobot_> but I'm not really sure
[14:02] <wolfgangw> cbsrobot_, nope, multiple layers valid
[14:02] <cbsrobot_> hmm
[14:02] <wolfgangw> look at fraunhofer's easydcp player demo. it will make significantly higher fps with lower res layer
[14:03] <wolfgangw> (they're using kakadu and cuj2k though)
[14:05] <wolfgangw> i'll get 24fps with 1/4 res on a pathetic laptop
[14:06] <wolfgangw> just to illustrate that in principle it should be possible
[14:07] <cbsrobot_> yeah well I thought it would be possible
[14:07] <cbsrobot_> but I never went into it
[14:11] <cbsrobot_> wolfgangw: do you have dcp with multiple layers ?
[14:11] <cbsrobot_> Compn: problem is our j2k decoder in not yet in shape to decode dcps
[14:12] <Compn> i know 
[14:12] <cbsrobot_> no commits since a long time on https://github.com/rukhsana ...
[14:13] <wolfgangw> cbsrobot_, you can extract the jpeg2000 essence from their mxf containers and then extract various resolution layers, yes. was that the question?
[14:14] <wolfgangw> it's a jpeg2000 property
[14:15] <cbsrobot_> wolfgangw: I mostly encode with opendcp and in my understanding https://github.com/tmeiczin/OpenDCP/blob/master/libopendcp/opendcp_j2k.c#L90 sets the num layers to 1
[14:16] <cbsrobot_> can you extract various resolution layers even the j2k has only 1 layer ?
[14:16] <wolfgangw> think so, i'll go and check
[14:17] <cbsrobot_> even I think we do that in our libopenjpeg wrapper: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/libopenjpegdec.c;h=4d91f4131c80038d0a448efdab4eaa19247d6d8a;hb=HEAD#l302
[14:17] <cbsrobot_> or at least lets say we still use the parameter lowres
[14:18] <cbsrobot_> do you get faster decoding when you set ffplay -lowres 2 input.mxf ?
[14:22] <wolfgangw> cbsrobot_, yes and no. there are "quality layers" and "resolution levels" and i meant to say the latter: j2k_to_image -i some.j2c -o decoded.tiff -r [1-5] discards resolution levels and will decode significantly faster
[14:23] <wolfgangw> depending on -r parameter
[14:25] <wolfgangw> cbsrobot_, oops, just read your last msg, i'll try that now
[14:26] <wolfgangw> cbsrobot_, yes, higher fps with -lowres here
[14:26] <cbsrobot_> ok then
[14:26] <cbsrobot_> how much ?
[14:27] <wolfgangw> how can i get a fps report out of ffplay?
[14:27] <cbsrobot_> hmmm well - I guess it will just stick to the fps specified
[14:27] <cbsrobot_> so if you are decoding with 25 fps it will not go above that
[14:27] <cbsrobot_> nevermind - but is it realtime ?
[14:28] <wolfgangw> with -lowres 3 it is close, not quite
[14:28] <wolfgangw> this with -threads 4
[14:29] <cbsrobot_> I think you do not need to specify threads as ffmpeg and ffplay use autothreads
[14:29] <cbsrobot_> something like num cpu + 1
[14:30] <wolfgangw> less fps without the -threads switch here
[14:31] <wolfgangw> anyway, that does prove the principle. great!
[14:35] <wolfgangw> one thing re VLC/DCP playback: I'm aware that people think desktop playback of DCPs is awesome, magic bullet and potion in one go. It's not as looking at this potentially high quality stuff on 6bit displays can give them an impression, at the most, of their material. Gamma/color will be all over the place etc. But what would make a lot of real-world sense is a preview mode to check integrity, check if its the right clip etc.
[15:00] <cbsrobot_> wolfgangw: true that. But as you know a lot of people are used to watch dvd / youtube / itunes quality movies too !
[15:22] <cbsrobot_> so yuva4XXp stores full range in a (not 16-235) - is there a way to specify alpha is not in the full range ?
[16:14] <michaelni> cbsrobot_, what format has a less than full range alpha ?
[16:14] <cbsrobot_> y4m 444alpha
[16:14] <cbsrobot_> see http://linux.die.net/man/5/yuv4mpeg
[16:15] <cbsrobot_> "The alpha channel data is follows the same range as the Y' luma channel: full transparency is at 16 and full opacity is at 235. "
[16:33] <PapaSmurf007> Compn: some of the arguments you are making for watermarking being evil are the same that were made against cryptography in the 70's
[16:33] <PapaSmurf007> people were arguing that new crypto-systems should be kept secret so that they were not used for evil (or adversaries)
[16:35] <PapaSmurf007> but the general consensus became that the more eyes on the crypto-system, the more secure it became
[16:35] <PapaSmurf007> similar arguments have been made for open source software
[16:35] <PapaSmurf007> so you saying that watermarking is evil goes against these trends
[16:36] <ubitux> i think watermarking is more like steganography than cryptography
[16:36] <PapaSmurf007> absulutely
[16:36] <ubitux> and steganography plays with the fact it is hidden
[16:36] <PapaSmurf007> and steganalysis plays detecting steganography
[16:36] <PapaSmurf007> so new hiding techniques warrant new detection techniques
[16:37] <PapaSmurf007> and so the process continues 
[16:38] <PapaSmurf007> and what i came here asking was for help in performing more realistic motion vector watermarking with mpeg2video so that i can perform more realistic detection
[16:38] <ubitux> well, i think keeping a watermarking/steganography secret might be benefic
[16:38] <ubitux> but well, just my opinion
[17:05] <av500> ubitux: I agree
[17:05] Action: ubitux feels relieved
[17:09] <PapaSmurf007> if your enemies are hiding their messages using steganography, wouldn't you want a way of detecting it?
[17:10] <ubitux> you might not know the enemy is using it
[17:10] <gnafu> ubitux: You would if you could detect it automatically ;D.
[17:10] <wolfgangw> assume it
[17:11] <ubitux> and loose your sanity
[17:11] <PapaSmurf007> steganography has been used for thousands of years
[17:11] <PapaSmurf007> they used to tattoo messages on the scalp of slaves and then send them to deliver the message when their hair grew back
[17:11] <PapaSmurf007> talk about message latency...
[17:11] <av500> its a bit like writing about the best places to hide stuff in your house
[17:11] <av500> sure, people might discuss it and suggest better places
[17:11] <av500> but all these places are now useless :)
[17:12] <ubitux> if i start assuming all the video services on the net are my enemies and are using watermarking, i'm going crazy
[17:12] <av500> ubitux: blueray has started
[17:12] <av500> and it seems to work for now
[17:12] <ubitux> OTOH if i have a tool to detect a wide set of known watermarking methods
[17:12] <ubitux> and it doesn't detect on the service X
[17:13] <ubitux> because they use an internal tricky method
[17:13] <PapaSmurf007> ok, so what if i gave you a closed source encryption library and said "this is secure, trust me"
[17:13] <ubitux> then i'm fucked; sure i can assume it is watermark and dig more
[17:13] <ubitux> but it's painful.
[17:13] <av500> PapaSmurf007: secure != watermark
[17:13] <av500> secure = safe in your house, watermark = hiding place
[17:13] <av500> safe we can discuss
[17:13] <av500> hiding place not
[17:14] <PapaSmurf007> if the level of distortion caused by the watermark is at or beneath the normal amount of distortion in your digital media being watermarked, the watermark is secure
[17:14] <PapaSmurf007> well, it is steganographically secure
[17:14] <av500> no
[17:15] <av500> is it secure against overwriting it with another mark?
[17:15] <av500> what if I take your algo and apply 100 watermarks?
[17:15] <av500> is that still secure?
[17:15] <PapaSmurf007> thats more about robustness than secure
[17:15] <ubitux> hidding the fact there are some steganography in use is part of the game
[17:15] <av500> ubitux: but watermark != steganography
[17:16] <av500> e.g. bluray uses audio watermarking
[17:16] <PapaSmurf007> secure meaning undetectable in watermarking
[17:16] <av500> and its known
[17:16] <av500> so its not steganography
[17:16] <PapaSmurf007> yes, watermark is steganography
[17:16] <ubitux> av500: ah? what kind of watermarking?
[17:16] <av500> ubitux: I forgot the name
[17:16] <ubitux> how does it work? (quickly)
[17:16] <av500> but certified players are being updated to not play stuff with watermark and no DRM
[17:16] <ubitux> they hide a serial num in the audio stream?
[17:16] <av500> no
[17:16] <av500> they only say "I am from a bluray"
[17:17] <ubitux> not which one?
[17:17] <av500> and the player knows if the bluray has AACP
[17:17] <ubitux> or at least country/vendor
[17:17] <av500> if no AACP but watermark: copy
[17:17] <ubitux> (to track down the guy)
[17:17] <av500> no
[17:17] <PapaSmurf007> watermarking and steganography are hiding information in such a way that only the transmitter and intended recipient are aware of its presence
[17:17] <ubitux> ok
[17:17] <ubitux> totally pointless then
[17:17] <PapaSmurf007> i am referring to digital watermarking 
[17:17] <av500> its to block ISOs
[17:17] <av500> or MKVs
[17:17] <av500> on controlled hardware
[17:17] <ubitux> haha ok
[17:17] <av500> of course, the chinese DMA does not care
[17:18] <j-b> AACP?
[17:18] <av500> but the legal owner of 100 bluray cannot NAS then any more
[17:18] <nevcairiel> its mostly to block copied BD discs
[17:18] <av500> j-b: the bluray DRM
[17:18] <av500> insert correct name
[17:18] <nevcairiel> if you MKV them, most likely you wont be playing them with commercial software anyway :p
[17:18] <av500> nevcairiel: unless its a networked bluray 
[17:18] <av500> some of them do play that
[17:19] <av500> and the watermark survives transcoding it seems
[17:19] <j-b> av500: no.
[17:19] <av500> no?
[17:19] <PapaSmurf007> thats a robust watermark
[17:19] <j-b> av500: Bluray has AACS BD+
[17:19] <av500> http://en.wikipedia.org/wiki/Cinavia
[17:19] <PapaSmurf007> if you can't tell that its there, then it is a secure watermark
[17:19] <j-b> and HDCP and Macrovision
[17:19] <nevcairiel> the watermark is even supposed to survive analog digital conversion
[17:19] <j-b> av500: ah, that?
[17:19] <av500> j-b: ok, AACS
[17:19] <nevcairiel> recording with a microphone, at that
[17:20] <av500> nevcairiel: if its robust, it should
[17:20] <ubitux> crappy content is a good watermarking method then
[17:20] <ubitux> it survives any digital conversion
[17:21] <av500> anybody remembers the SDMI challenge?
[17:21] <PapaSmurf007> i hadn't heard of this Cinavia
[17:21] <av500> PapaSmurf007: neither had I until recently
[17:22] <av500> but from what I see from forum posts, it seems to work and frustrate people
[17:22] <av500> again, the chinese DMA will not care
[17:22] <av500> but e.g. popcorn hour with their bluray license might be fucked
[17:23] <nevcairiel> i should put more effort into blu-ray menu playback
[17:23] <nevcairiel> foss to the rescue
[17:24] <av500> www.cc.gatech.edu/~traynor/f08/slides/lecture22-sdmi.pdf
[17:53] <kierank> av500: note that with cinavia the audio isn't lossless any more
[17:53] <kierank> so someone could sue for that
[17:55] Action: gnafu likes that argument.
[17:55] <av500> kierank: sue who?
[17:56] <av500> du people buy the avengers bluray for its lossless sound?
[17:56] <av500> do
[17:56] <av500> or any other?
[17:56] <ubitux> do ppl buy the avengers bluray?
[18:02] <kierank> it's a false claim though
[18:03] <JEEB> cinavia is derp
[18:03] <JEEB> did they have to start breaking the audio in the name of "copy protection"
[18:03] <JEEB> I wonder why the hifist parts of people aren't in uproar already
[18:03] <av500> JEEB
[18:04] <av500> JEEB: does hifi matter much for protection hollywood blockbusters?
[18:04] <av500> they can leave the jazz recordings unprotected
[18:04] <JEEB> I'm not really limiting it there to be honest, although yeah -- it's mostly used in those spheres
[18:24] <tg_> > <@ubitux> do ppl buy the avengers bluray? Truth
[18:24] <tg_> guys any idea what parts of the script I need to modify to get more than 12 threads for decoding?
[18:25] <tg_> in the sauce
[18:25] <tg_> or is it a libav issue
[18:25] <burek> -threads
[18:26] <tg_> it caps
[18:26] <tg_> at 12 decoding threads
[18:26] <tg_> regardless of -threads setting
[18:26] <Compn> tg_ : did you change pthread.c ?
[18:26] <tg_> i did
[18:26] <tg_> err
[18:26] <Compn> crap
[18:26] <tg_> i changed the file you asked last time
[18:26] <tg_> the MAX_THREADS
[18:26] <tg_> didnt' do much
[18:26] <Compn> i found another file 
[18:26] <tg_> shoot the filename
[18:26] <Compn> tg_ : look at libavcodec/pthread.c
[18:27] <tg_> ahhhh
[18:27] <tg_> ok i'll check
[18:27] <tg_> my dev server is on a truck right now
[18:27] <tg_> so i'll check it when it's plugged in
[18:27] <Compn> an ... actual truck :)
[18:27] <tg_> yeah physical realm stuff
[18:27] <Compn> real world, bah!
[18:27] <tg_> apparently they use them for transportation or something
[18:27] <tg_> not sure
[18:27] <Compn> series of tubes
[18:27] <tg_> i pinged it
[18:27] <tg_> didn't reply
[18:28] <Compn> no gps tracking ? :P
[18:28] <tg_> no jokes
[18:28] <Compn> i forgot if thats legal now in usa
[18:28] <tg_> I've shipped a server in a truck with 2 generators running to keep them up
[18:28] <tg_> lol
[18:28] <Compn> i dont think it is
[18:29] <Compn> strapping gps trackers to cars
[18:29] <tg_> gps tracking your own shipments isn't
[18:29] <Compn> from police anyhow
[18:29] <Compn> legal with a warrant of course
[18:29] <tg_> naw dont kid yourself they don't need a warrant 
[18:29] <tg_> "suspected terrorist"
[18:29] <tg_> done
[18:29] <tg_> no need to justify it
[18:29] <tg_> "anonymous source tipped us off"
[18:29] <tg_> ok
[18:29] <tg_> patriotact at gmail.com
[18:30] <tg_> ukno
[18:30] <Compn> whats the point of all the rules if they can probable cause its way around it
[18:30] <tg_> bah, non development related discussions ;D
[18:30] <Compn> i should really test pthread change instead of asking you to do it all of the time 
[18:30] <Compn> ;)
[18:31] <tg_> lol
[18:31] <Compn> if you have extra bitcoins, they can be deposited to me here 1Hait21gG9Ldzv5SQL7a78qs2xhh4UTR1c
[18:31] <tg_> i have them in cash at mtgox
[18:31] <Compn> ah
[18:31] <tg_> so if you want a USD mtgox coupon
[18:31] <tg_> I can do that
[18:31] <tg_> i just bought a 7970 to supplement my 5970
[18:31] <tg_> mad coinz y0
[18:32] <tg_> up to 1000 Mhash/s
[18:32] <tg_> ~20 btc per month
[18:32] <Compn> ever hash your own block ?
[18:32] <tg_> naw
[18:32] <Compn> 50btc
[18:32] <tg_> I will soon though
[18:32] <tg_> they're putting it down to 25btc per block this summer
[18:32] <tg_> once they reach 50% of bitcoins distributed
[18:32] <tg_> it will sucks
[18:32] <Compn> so what are the estimates until we reach full bitcoin hashed ?
[18:32] <Compn> i mean 100% 
[18:32] <tg_> 2018 or seomthing, 2020 maybe
[18:33] <Compn> oh cool
[18:33] <Compn> probably in 5 years computing power will amp up and fix those estimations :)
[18:33] <tg_> "he coin value of a block is 50 BTC for each of the first 210,000 blocks, 25 BTC for the next 210,000 blocks, then 12.5 BTC, 6.25 BTC and so on."
[18:34] <Compn> strange the block value decreases as difficulty increases
[18:34] <tg_> guess I was off a bit
[18:34] <tg_> "The last block that will generate coins will be block #6,929,999. This should be generated around year 2140. Then the total number of coins in circulation will remain static at 20,999,999.9769 BTC."
[18:34] <Compn> whoa
[18:34] <tg_> gotta start buying up coins ;D
[18:35] <Compn> backing up yer wallet 
[18:35] <tg_> I wish I would have had the foresight to buy 100k worth when they were like 20c per coin
[18:35] <tg_> lol
[18:35] <Compn> do people still blame mtgox for crashing the market ?
[18:35] <Compn> when it was $30 /btc
[18:35] <tg_> well, it was overinflated
[18:35] <tg_> lol
[18:36] <tg_> if anything the press about it made it stronger
[18:36] <tg_> and more globally accepted
[18:36] <Compn> true i guess
[18:36] <tg_> they still need a better site for listing all the places that accept bitcoins
[18:36] <Compn> more people using it gives it more value
[18:36] <tg_> right now it's basically a wikipedia page with links
[18:36] <tg_> it wasn't worth 30$ per BTC
[18:36] <Compn> anything to beat paypal really
[18:36] <tg_> yeah I know friends at alertpay
[18:37] <tg_> i pray for the day that paypal goes under
[18:37] <tg_> ebay can go with it for all I care
[18:37] <Compn> ebay and paypal double dipping like crazy
[18:37] <tg_> they have fucked so many people out of so much money it's not even funny
[18:37] <Compn> letting scammers run amok
[18:37] <tg_> bitcoins up to 5.14!
[18:37] <Compn> so so many scams
[18:37] <Compn> yeah it wasnt worth $30, but i did sell one for $29 :D
[18:38] Action: Compn boots up his build box and sees if pthread fixes limit
[18:39] <Compn> hmm
[18:39] <tg_> f;)
[18:39] <tg_> for the record, never buy a steelseries keyboard, typing accuracy on it is attrocious
[18:39] <Compn> astrange did the ffmpeg-mt
[18:39] <tg_> hm
[18:39] <Compn> could ask him
[18:39] <tg_> wasn't it merged?
[18:39] <Compn> yeah
[18:39] <Compn> he knows the code :)
[18:40] <tg_> contact?
[18:40] <Compn> his nick is on irc
[18:40] <Compn> just not in this channel
[18:40] <Compn> let me dig up email
[18:40] <tg_> what channel does he inhabit :D
[18:41] <tg_> what was the other place you said to ask?
[18:41] <Compn> Alexander Strange <astrange at ithinksw.com>
[18:41] <Compn> #libav-devel
[18:41] <Compn> fork of ffmpeg
[18:42] <tg_> libav was it
[18:42] <tg_> thx
[18:55] <Compn> pthreads.c: max_auto_threads maybe
[18:55] <tg_> ahhh
[18:55] <tg_> did it work?
[18:56] <Compn> compiling now
[18:56] <tg_> takes long to compile on my vm :(
[18:56] <tg_> lol
[18:56] <tg_> longer than with 48 cores
[18:56] <Compn> i booted the wrong box,  ehe
[18:59] <CIA-122> ffmpeg: 03Tobias Rapp 07master * r8da0a6cda1 10ffmpeg/libavformat/mp3enc.c: 
[18:59] <CIA-122> ffmpeg: mp3enc: Fix Xing tag identification string for CBR files
[18:59] <CIA-122> ffmpeg: Fixes the Xing tag identification string to be "Info" for MP3 files with
[18:59] <CIA-122> ffmpeg: constant bitrate. The previous "Xing" caused some decoders to recognize the
[18:59] <CIA-122> ffmpeg: file as VBR.
[18:59] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:59] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rf14f3bae6b 10ffmpeg/libavformat/mp3enc.c: 
[18:59] <CIA-122> ffmpeg: mp3enc: avoid ifdef
[18:59] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:59] <CIA-122> ffmpeg: 03Nick Brereton 07master * r8036a69e6b 10ffmpeg/libavcodec/dca.c: 
[18:59] <CIA-122> ffmpeg: Decode XBR extension in first asset
[18:59] <CIA-122> ffmpeg: Reviewed-by: Benjamin Larsson <benjamin at southpole.se>
[18:59] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[18:59] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rc6aa2c4b12 10ffmpeg/ffmpeg.c: 
[18:59] <CIA-122> ffmpeg: ffmpeg: print next_dts too on debug_ts
[18:59] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[19:03] <Compn> were the libav people able to help you ?
[19:03] <av500> we are at it
[19:04] <tg_> they are on it
[19:04] <tg_> thx av500
[19:04] <Compn> tg_ : was jason able to figure out x264 thread limit ?
[19:05] <Compn> i guess what i mean is, did he fix it
[19:05] <Compn> :D
[19:05] <tg_> yes
[19:05] <tg_> there are some parts that cannot be threaded
[19:05] <tg_> but those are being optimized
[19:05] <tg_> as there are redundancies 
[19:05] <tg_> there is only 1 function that cannot be threaded
[19:05] <tg_> x264_macroblock_tree_propagate
[19:06] <tg_> but that only accounts for ~2% of processing
[19:06] <tg_> when optimized, maybe less
[19:14] <PapaSmurf007> another golden comment: /* MPEG-2-specific - I wished not to have to support this mess. */
[19:16] <PapaSmurf007> Well, it doesn't seem that ffmpeg is using the void *opaque field of MpegEncContext, so I guess I'll use it and hope I don't break everything
[19:21] <Compn> ehe
[19:22] <Compn> tg_ : unfortunately in windows i cant tell how many threads ffmpeg is using
[19:22] <Compn> to test if this change makes it use more threads :P
[19:22] Action: Compn should boot linux box
[19:25] <tg_> lol
[19:25] <tg_> hol dup
[19:25] <tg_> http://technet.microsoft.com/en-us/sysinternals/bb896653
[19:25] <tg_> install that puppy
[19:25] <tg_> then you can see threads
[19:25] <tg_> if you right click the process and go "properties" then select threads
[19:26] <tg_> it will show them
[19:27] <Compn> oh ok
[19:27] <tg_> any idea how to compile libc so that you can see the methods in perf ?
[19:27] <tg_> like --disable-stripping
[19:27] <tg_> http://i.imgur.com/SKE7H.png
[19:28] <tg_> instead of 0x138a67
[19:28] <Compn> --enable-debug=3 ? 
[19:28] <tg_> k
[19:28] <Compn> no idea
[19:28] Action: Compn just guessing
[19:28] <Compn> oh
[19:28] <Compn> try running ffmpeg_g binary
[19:28] <tg_> i can see with ffmpeg
[19:28] <Compn> i cant remember if that was disabled 
[19:28] <tg_> i recompiled with stripping disabled
[19:29] <tg_> libc is still not showing hte method
[19:29] <tg_> i'll try and do a debug of it
[19:37] <Compn> ok , threads in process explorer >> -threads 1 reports 4, -threads 2 reports 6, -threads 3 reports 7 , -threads 4 reports 8, -threads 16 reports 20.
[19:37] <Compn> so i guess threads X + 4
[19:37] <Compn> now to test new binary
[19:43] <Compn> hah , yep, -threads 20  = 24 threads reported :)
[19:44] <Compn> well that could be due to mpeg4 thread liimit of 16
[19:44] <Compn> need to test another encoder without a limit
[19:45] <Compn> arg they all have limits
[19:46] <Compn> and the rest dont have thread encoding supported
[19:46] <Compn> tg_ : how goes it on your end ?
[19:47] <Compn> i wonder if its a pthread limit 
[19:47] <Compn> i think i'm using w32threads on windows ;\
[19:48] <Compn> no i guess pthreads doesnt have that kind of limit
[19:50] <Compn> well i leave you in the capable hands of people who know what they are doing :)
[19:50] <tg_> bah fucking trucks are slow
[19:50] <tg_> according to libav guys
[19:51] <tg_> if you do "avconv -threads 48 -i file -f null -" it should use all 48 threads
[19:51] <tg_> i haven't tested yet
[19:51] <Compn> i just had an idea tho... if you are limited by decode threads to 16, you cant actually get more than 16 encoding threads, since there arent more threads to decode with ...
[19:51] <Compn> so you DO have to change decoding thread limit as well :)
[19:51] <Compn> if there is one, i forgot how far we got on that issue
[19:52] <Compn> i dont see a decode thread max limit so nevermind
[19:53] <Compn> [mpeg4 @ 03BFE200] too many threads/slices (17), reducing to 16
[19:55] <Compn> that looks like encoding max
[19:55] <Compn> doesnt seem to be decoding limit
[19:55] <michaelni> just increase the #define and recompile if you need mor ethreads
[19:56] <Compn> which define ?
[19:56] <Compn> mpegvideo.h:#define MAX_THREADS 16
[19:57] <tg_> tried that already
[19:57] <tg_> still limits at 16
[19:57] <tg_> try decoding to raw
[19:57] <Compn> good idea
[19:58] <tg_> ffmpeg -threads 24 -i file.mpg -an -f rawvideo -y /dev/null
[19:58] <Compn> that sets 24 decoding threads
[19:58] <tg_> does it actually spawn 24 decoding threads?
[19:58] <Compn> yes
[19:58] <tg_> orly
[19:59] <tg_> on mine it was still at 16 after makign the change to mpegvideo.h
[19:59] <Compn> but i'm on windows and using w32threads , not pthreads (which linux should be using)
[19:59] <tg_> did you hange anything else?
[19:59] <tg_> change *
[19:59] <Compn> i did in fact
[19:59] <tg_> threads.h?
[19:59] <Compn> er no, this is on default build
[19:59] <tg_> whut
[19:59] <tg_> windows magic
[19:59] <tg_> lol
[20:00] <Compn> default build works with 24 threads 
[20:00] <Compn> reports 28 threads in process explorer...
[20:00] <tg_> hmmm
[20:00] <tg_> 99% sure it doesn't on linux
[20:00] <tg_> i tried -threads 48
[20:00] <tg_> and it only gave 16 threads
[20:00] <tg_> what if you put 48 threads?
[20:01] <Compn> oh waid
[20:01] <Compn> you were testing h264 input ?
[20:01] <tg_> yes
[20:02] <Compn> says 52 threads in process explorer with -threads 48
[20:02] <Compn> and i get this nifty warning in ffmpeg > [h264 @ 04078740] too many thread_release_buffer calls!
[20:02] <tg_>  [h264 @ 0x134d000]too many threads [h264 @ 0x134d000]decode_slice_header error [h264 @ 0x134d000]no frame! 
[20:02] <tg_> yup
[20:03] <michaelni> try increase #define MAX_BUFFERS (32+1)
[20:04] <Compn> i cant believe this all works with windows :D
[20:04] <Compn> tg_ : -threads 20 gives 24 threads with h264 input ...
[20:04] <tg_> haha
[20:04] <tg_> fucking windows
[20:04] <tg_> i'm trying this on a machine with 2 cores
[20:04] <tg_> lol
[20:04] <tg_> a VM at that
[20:04] <tg_> hypervisor is like dude wtf you doing 
[20:05] <tg_> I also get this
[20:05] <tg_> [h264 @ 0xcd0000]Cannot parallelize deblocking type 1, decoding such frames in sequential order 
[20:06] <Compn> hmmm
[20:07] <michaelni> try -flags2 +fast or something 
[20:07] <Compn> guess we better wait for your truck first :P
[20:07] <tg_> yeah
[20:08] <tg_> fun fact, it's faster to fill a shipping container with harddrives and ship it overseas than transferring it over the internet
[20:10] <Compn> unless it hits an iceburg
[20:10] <Compn> or iceberg, however they want to be named
[20:38] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * rcb982739fa 10ffmpeg/libavcodec/mpegvideo.h: 
[20:38] <CIA-122> ffmpeg: mpegvideo: double thread limit
[20:38] <CIA-122> ffmpeg: 16 seems a bit tight for current high end and expected near term future boxes.
[20:38] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[20:45] <bahar> for real-time video transcoding in software, how important is processor cache? does anyone know?
[20:45] <bahar> wondering if a 6 core w/ 10mb cache is as good as a 6 core w/ 15mb cache or if clock speed is more important than cache.
[21:04] <Compn> good question
[21:04] <Compn> i think dark_shikari worked on real-time video encoding
[21:04] <Compn> he may know some secrets
[21:06] <kierank> depends what you're transcoding in realtime
[21:07] <Compn> bahar : ask in #x264
[21:07] <bahar> thanks
[21:09] <iive> more cache is always better :)
[21:10] <Compn> more fsb too
[21:10] <Compn> :P
[21:12] <iive> but it matters the type/speed of the cache.
[23:06] <CIA-122> ffmpeg: 03Luca Barbato 07master * re004bc16a1 10ffmpeg/doc/developer.texi: 
[23:06] <CIA-122> ffmpeg: doc: clarify check for NULL pointer style
[23:06] <CIA-122> ffmpeg: Our code should be terse and clear.
[23:06] <CIA-122> ffmpeg: 03Anton Khirnov 07master * r828bd088f3 10ffmpeg/ (4 files in 2 dirs): 
[23:06] <CIA-122> ffmpeg: lavc: add sample rate and channel layout to AVFrame.
[23:06] <CIA-122> ffmpeg: Rationale is the same as for video width/height etc.
[23:06] <CIA-122> ffmpeg: 03Mina Nagy Zaki 07master * r11b6a82412 10ffmpeg/libavfilter/formats.c: 
[23:06] <CIA-122> ffmpeg: lavfi: avfilter_merge_formats: handle case where inputs are same
[23:06] <CIA-122> ffmpeg: This fixes a double-free crash if lists are the same due to the two
[23:06] <CIA-122> ffmpeg: merge_ref() calls at the end of the (useless) merging that happens.
[23:06] <CIA-122> ffmpeg: Signed-off-by: Anton Khirnov <anton at khirnov.net>
[23:06] <CIA-122> ffmpeg: 03Paul B Mahol 07master * r37f4a976b3 10ffmpeg/libavcodec/zerocodec.c: 
[23:06] <CIA-122> ffmpeg: zerocodec: check if the previous frame is missing
[23:06] <CIA-122> ffmpeg: ZeroCodec relies on the keyframe flag being set in the container, and
[23:06] <CIA-122> ffmpeg: prev is the previously decoded frame. A keyframe flags incorrectly set
[23:06] <CIA-122> ffmpeg: will lead to this condition.
[23:06] <CIA-122> ffmpeg: Signed-off-by: Paul B Mahol <onemda at gmail.com>
[23:06] <CIA-122> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[23:06] <CIA-122> ffmpeg: 03Anton Khirnov 07master * r0bbd874743 10ffmpeg/libavfilter/avfilter.c: lavfi: support audio in avfilter_copy_frame_props().
[23:06] <CIA-122> ffmpeg: 03Sean McGovern 07master * rb68c4ac293 10ffmpeg/libavcodec/pthread.c: 
[23:06] <CIA-122> ffmpeg: pthread: warn on high thread counts
[23:06] <CIA-122> ffmpeg: 03Diego Biurrun 07master * rdbe6ba55a3 10ffmpeg/ (5 files in 5 dirs): build: cosmetics: Add missing end-of-line backslashes to item lists.
[23:06] <CIA-122> ffmpeg: 03Diego Biurrun 07master * r9eb83a56aa 10ffmpeg/ (6 files in 6 dirs): build: cosmetics: Split HEADERS/OBJS/PROGS lists into one entry per line.
[23:06] <CIA-122> ffmpeg: 03Diego Biurrun 07master * r246b050f51 10ffmpeg/libavcodec/mmvideo.c: 
[23:06] <CIA-122> ffmpeg: mmvideo.c: Remove unused variable in mm_decode_pal().
[23:06] <CIA-122> (23 lines omitted)
[23:35] <tg2> any reason i'm getting this on ffmpeg configure
[23:35] <tg2> ./configure --disable-stripping --prefix=/usr --enable-libx264 --enable-libfaac --enable-nonfree --enable-gpl
[23:35] <tg2> ERROR: libx264 version must be >= 0.118.
[23:36] <tg2> and yet
[23:36] <tg2>  x264 --version
[23:36] <tg2> x264 0.124.2197 69a0443
[23:36] <tg2> built on May  7 2012, gcc: 4.5.2
[23:37] <tg2> my bad, disregard
[23:39] <CIA-122> ffmpeg: 03Michael Niedermayer 07master * r364c71c80e 10ffmpeg/libavformat/movenc.c: 
[23:39] <CIA-122> ffmpeg: movenc: store codecs that dont provide a frame_size as audio_vbr=1
[23:39] <CIA-122> ffmpeg: Fixes Ticket1240
[23:39] <CIA-122> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[00:00] --- Tue May  8 2012