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

[burek]

[03:22] Action: michaelni looks at CIA-56 
[03:22] <michaelni> its nice you are back CIA-56 but where are my commits ?
[03:23] Action: michaelni kicks CIA-56 
[03:23] <CIA-56> ow
[03:31] Action: Compn hugs CIA-56
[03:31] Action: CIA-56 hugs Compn
[03:31] <Compn> he loves me, not you michaelni ! :P
[03:33] Action: michaelni eats CIA-56 
[03:33] Action: CIA-56 tastes crunchy
[03:34] Action: michaelni wonders if theres a list of keywords CIA reacts to ...
[03:37] Action: michaelni considers to rename himself to CIA and paste commit messages
[03:37] Action: michaelni is too lazy though
[04:07] <Compn> probably cia is backuped
[04:07] <Compn> i mean
[04:07] <Compn> queue full
[04:07] <Compn> it will start announcing commits later ?
[04:08] <Compn> no clue
[04:09] <Compn> michaelni : are you working on any new secret ffmpeg features? or just same old bug fixing? :)
[04:09] <michaelni> just fixing random bugs ATM
[04:23] <Compn> i havent even looked at the bug tracker in months :\
[04:30] Action: Compn edits some bug summaries
[05:26] <Compn> j-b : how come you dont force these decoders to be put into ffmpeg instead of vlc? http://mailman.videolan.org/pipermail/vlc-commits/2012-June/015127.html
[05:27] <Compn> vlc doesnt need to be maintaining codecs..... :P
[11:41] <japjap> Hello, can ffmpeg record video stream coming in thru local udp port as RTPs ?
[12:33] <burek> the description for -ss option in the documentation should be corrected a little bit, I think: http://ffmpeg.org/ffmpeg.html#Main-options 
[12:33] <burek> it doesn't describe how exactly -ss behaves before -i and after it
[12:33] <burek> which might be confusing to people when using it
[16:09] <pettter> Before I go off writing something myself - is there a way to get the bit depth of a particular pixel format?
[16:10] <pettter> either as bpp or simpler (8/10/16/foo per sample)
[16:15] <kierank> yes
[16:16] <kierank> you should get a pix_fmt
[16:16] <kierank> and the bitdepth is either specified or implied as 8
[16:18] <pettter> I found av_get_bits_per_pixel, which should be sufficient I think
[16:19] <pettter> either that or I go digging in the pix_fmt, as you say
[16:19] <kierank> yes that'll do
[17:44] <michaelni> who is responsible for our CIA bot ?
[17:45] <Daemon404> michaelni, it's not just ffmpeg's thats down
[17:45] <michaelni> hmm, ok, thx, ill wait patiently then
[17:45] <Daemon404> also
[17:45] <Daemon404> you can apply that patch i forwarded to the ML
[17:53] <michaelni> Daemon404, done, btw Topic for #cia is: ... current status: everything should be up and running as expected ...
[17:53] <Daemon404> weird
[17:53] <Daemon404> libav's is down
[17:53] <gnafu> Well, the CIA is known for deception.
[17:53] <gnafu> ;D
[17:54] <Daemon404> lul
[21:24] <ubitux> ITU-R schemas are insanely clueless
[21:24] <ubitux> seriously, wtf: http://ubitux.fr/pub/pics/_itu-wtf-schema.png
[21:25] <ubitux> the schema is confusing while the text is pretty clear
[21:31] <saste> ubitux: well you should have guessed it from the code in the figure
[21:31] <saste> B.S. 1770-07
[21:31] <saste> BS = Bull S@#t
[21:33] <ubitux> :)
[21:33] <ubitux> it's the name of the specs :(
[21:40] <ohsix> how is that confusing, there's a switch, a reference, and a buffer to set the level
[21:44] <ubitux> the point is that i wonder how does that help illustrating the text
[21:44] <ohsix> it's for people that like pictures :]
[21:45] <ubitux> :D
[21:45] <gnafu> Then where's the kitty?
[21:45] <ubitux> without the text i would be unable to figure out what that actually means :p
[21:46] <ohsix> i could see a scenario where the picture would explain the text, but in that case i don't know who the ITU is actually writing those for
[21:47] <JEEB> I still remember when I saw crypto stuff related pictures for the first time
[21:48] <ohsix> alice and bob make a cute couple
[21:50] <ubitux> bob is bald :s
[21:52] <saste> anyone has a clue w.r.t. AIFF?
[21:53] <saste> ticket #1660
[21:59] <ohsix> is there a way to coax ffplay or mplayer to do bitstream/error detection while skipping a full decode
[22:00] <ohsix> barring that, can it be done with the library
[22:01] <ohsix> i had reason to suspect that some percentage of almost 4tb of stuff was corrupted, and i've had to resort to scripting mplayer to play them all
[22:01] <ohsix> funny story: mplayer puts random messages on stdout/stderr, whether they look like errors or not, so i got to do it twice
[22:04] <ohsix> playing them back goes at a decent clip, but i dunno what i can do to make it go faster without it reducing what it might be able to report as an error
[23:05] <ubitux> CIA-56 :(
[23:05] <Compn> ohsix : mplayer -nosound -vo null 
[23:05] Action: ubitux hugs CIA-56 :(
[23:05] <Compn> if its video problem, will ignore the video output
[23:05] <ubitux> fucking bot
[23:05] <Compn> then you can add -speed 100
[23:05] Action: ubitux hits CIA-56 
[23:06] <ohsix> i'm already doing that, with -benchmark
[23:06] <Compn> ohsix : are you looking for incomplete frames or so ? 
[23:06] <Compn> you can speed up lavc decoding with tricks
[23:06] <ohsix> yea, and other bitstream errors
[23:06] <Compn> or you can skip into the file
[23:06] <Compn> i'm not sure what you want it to do...
[23:07] <Compn> oh, lowres speeds it up too
[23:07] <Compn> -lavdopts lowres=2 ;)
[23:07] <Compn> assuming its a lowres codec
[23:07] <ohsix> more than demuxing it and less than decoding it and throwing away the output
[23:07] <ohsix> it already goes pretty fast
[23:07] <Compn> wait what ?
[23:08] <Compn> oh
[23:08] <Compn> just to scan for errors eh
[23:08] <ohsix> yea
[23:08] <Compn> dont think there exists that option
[23:08] <Compn> did lowres help ?
[23:08] <ohsix> dunno, i will try it next batch, does it make it skip mv's?
[23:09] <Compn> i actually have no clue how lowres works. something about taking the dct and using magic and math to trick the data into behaving at half size
[23:10] <ohsix> ok, next time i end up with a file corrupted like that i'll try it, i don't want it to skip over any possible errors :p
[23:10] <Compn> lowres should require the whole frame to make it work properly
[23:10] <Compn> so if there is an error, lowres should detect it
[23:11] <Compn> libav removed its lowres support huh ? thats a pity
[23:11] <Compn> https://bugzilla.libav.org/show_bug.cgi?id=297
[23:13] <ubitux> saste: can't you use the dsputils for the diff 8x8?
[23:13] <ubitux> (decimate filter)
[23:13] <saste> ubitux: yes but that's a port
[23:14] <saste> also I'd avoid another lavc dep at this point
[23:14] <saste> until someone decides to port dsp to lavu :)
[23:14] <ubitux> i was wondering if lavc hadn't a better diff_8x8_mmx
[23:14] <ubitux> as well as other optims
[23:22] <saste> ubitux: i'll check it
[23:23] <ubitux> saste: IMO it will be simpler in the future to remove the lavc dependency from the filter than maintaining different optimized version of the diff function, as well as the assembly stuff in lavfi
[23:24] <ubitux> which in that case doesn't look at the "correct" place
[23:24] <saste> michaelni: do we have something resembing  diff_8x8_mmx?
[23:24] <saste> i can't find it
[23:24] <ubitux> isn't it diff_pixels?
[23:24] <ubitux> ah you mean the optimized version
[23:25] <ubitux> libavcodec/x86/dsputilenc_mmx.c:        c->diff_pixels = diff_pixels_mmx;
[23:25] <ubitux> looks like there is one
[23:35] <saste> ubitux: yep
[23:35] <ubitux> it seems available in various arch too
[23:36] <Compn> are there any h264 decoders that support lowres ?
[23:36] Action: saste needs to get a clue about dsputils
[23:39] <JEEB> Compn, I thought lowres was not possible with H.264?
[23:39] <JEEB> unlike MPEG-4 Part 2
[23:41] <saste> also dsputil is private, should i really use it in lavfi?
[23:41] <saste> michaelni: ^^
[23:41] <ubitux> that's what we do in various filter
[23:42] <saste> again the long term solution would be to move dsputil to lavu (and make it public)
[23:42] <ubitux> yeah& :)
[23:42] <ubitux> libaveverything
[23:42] <michaelni> ubitux, yes, "libaveverything"
[23:42] <saste> libavall
[23:43] <ubitux> or maybe libavfilter could be merged with libavcodec ;)
[23:43] <michaelni> btw, about CIA, http://www.omat.nl/2012/08/20/cia-vc-broken/
[23:44] <ubitux> meh.
[23:44] <ubitux> let's introduce ffcia
[23:45] <michaelni> saste, "git grep dsputil libavfilter" has hits so id say if you need dsp and dont mind the possible ABI issues then go ahead with using it
[23:46] <saste> michaelni: ok, seems the lesser evil
[23:46] <saste> ubitux: ffbi
[23:46] <JEEB> lol
[23:46] <ubitux> haha
[23:46] <ubitux> :D
[23:46] <ubitux> sounds awesome
[23:52] <saste> uh i need to pass an AVCodecContext struct... that's ugly
[00:00] --- Tue Aug 21 2012