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

[burek]

[00:15] <llogan> michaelni: thanks
[00:25] <lukaszmluki> Hi, question quite peculiar, but do you know any method to test if conversion from AV_PIX_FMT_YUV420P into AV_PIX_FMT_ARGB is bugged? :)
[00:27] <lukaszmluki> I test opengl shader, and when i force ARGB format i get A and G components swapped
[00:27] <lukaszmluki> at least it looks this wat
[00:34] <wm4> it's very unlikely that it's bugged
[00:34] <wm4> maybe you're confusing component and byte orders?
[00:34] <wm4> it's not always easy to tell with these RGB formats
[00:35] <lukaszmluki> i use the same code for all rgb's and this is the only now working
[00:36] <lukaszmluki> i don't say its bugged, but i dont see error in my code and wanted to check another posibility :)
[00:37] <lukaszmluki> I was hoping ffmpeg allows some doube conversion  to check it
[00:41] <lukaszmluki> I use av_pix_fmt_desc_get() and offset_plus1 and it returns correct values
[00:41] <lukaszmluki> and all other formats are working with it
[00:41] <lukaszmluki> ok, thx anyway
[00:41] <wm4> I guess pixdesc being wrong is a real possibility
[00:41] <wm4> but it's also hard to use
[00:42] <lukaszmluki> nah, i debugged it and this part seems ok
[00:42] <lukaszmluki> I just try to print alphas now :P
[00:51] <lukaszmluki> wm4: BTW, why you dont want to develop devices as (de)muxers?
[00:51] <wm4> because the API is not made for this
[00:51] <wm4> and you'll have to add weird things to the generic muxer API to make devices non-crappy
[00:52] <wm4> it's just a bad hack, and now you want to build on it
[00:52] <wm4> bad idea.
[00:52] <lukaszmluki> this is right, but on other hand if we add and real muxers ignore it is not end of the world
[00:53] <lukaszmluki> i mean muxers dont implement callbacks for devices
[00:53] <saste> lukaszmluki, can try with alphamerge or extractplanes
[00:53] <saste> uhm no alphaextract
[00:53] <wm4> lukaszmluki: that doesn't make it any better
[00:56] <lukaszmluki> thx Stefano, will check it.
[00:57] <lukaszmluki> wm4: personally i don't have nothing about separation from muxers, but it will big break of current api/approach
[00:58] <wm4> maybe so
[01:00] <lukaszmluki> saste: but does't it really allow to prove to conversion is ok or corrupted?
[01:04] <Timothy_Gu> michaelni: is there a reason why the Libav Git remote is called "qatar"?
[01:06] <Compn> makes it easier to grep ?
[01:06] <Compn> (hi timothy)
[01:06] Action: Timothy_Gu wave hand
[01:07] <Timothy_Gu> compn: maybe...
[01:07] <Compn> is there a reason ubuntu ships an 'ffmpeg' package for years and years ? 
[01:07] Action: wm4 suspects it was because the existence of Libav couldn't be acknowledged or accidentally be spread
[01:08] <Compn> which is actually libav package
[01:08] <Compn> and an outdated ffmpeg binary that says its deprecated ?
[01:09] <wm4> yes, there's a reason: the debian maintainers are also Libav devs
[01:09] <Timothy_Gu> compn: well, if I am Libav, and I want to get rid of the ffmpeg.c cruft with unwanted stuff, I'd call it 'deprecated'
[01:10] <Timothy_Gu> compn: for the reason ubuntu still ships ffmpeg package, is because the fear that removing that would break millions of blog posts, shell scripts, etc. etc.
[01:10] <Compn> but the message is the entire ffmpeg program is deprecated
[01:10] <Compn> not any particular piece of cruft
[01:10] <Timothy_Gu> compn: it is for Libav
[01:10] <Compn> also if you wanted to get rid of cruft, why git rename ffmpeg.c avconv.c in the first place :p
[01:12] <Compn> hilarious circular logic, its deprecated , why ship it? because it would break things. its breaking things already. well its in transistion. for 3+ years?
[01:12] <wm4> the main reason ffmpeg.c printed deprecated on Libav was because avconv.c was not a direct replacement
[01:12] <wm4> but slightly different command line semantics or something
[01:13] <wm4> but even if that is right, it sure was a clumsy move
[01:13] <Compn> its like breaking the wheels on your car and then building another car you have to learn how to drive again
[01:13] <Compn> and then trying to sell the broken car
[01:13] <wm4> I mean it was clumsy PR-wise
[01:14] <wm4> I really hate ffmpeg CLI
[01:14] <wm4> I can never get it do what I want
[01:14] <Compn> you like mencoder better? admit it!
[01:14] <wm4> and I frequently make it overwrite my input files
[01:14] <Compn> i ... admit i overwritten a input sample file the other day :(
[01:14] <wm4> well, mpv's encoding functionality has mencoder compatible options AFAIK
[01:14] Action: Compn inserts grammar into that sentence
[01:15] <Timothy_Gu> wm4: I always found it weird why mpv has encoding feature
[01:15] <Compn> wm4 : it actually can encode things, not just vaporware ?
[01:15] <wm4> Timothy_Gu: me too, but why not
[01:15] <wm4> Compn: yes
[01:15] <Compn> neat
[01:16] <wm4> but it uses ffmpeg, there's not a single line of mencoder code in there
[01:16] <Compn> i never would suggest that :)
[01:16] <Timothy_Gu> wm4: what advantage does that have over ffmpeg.c
[01:17] <Compn> Timothy_Gu : it doesnt overwrite his input files ?
[01:17] <Compn> :P
[01:17] <wm4> this
[01:18] <wm4> Timothy_Gu: for a serious reply, you'll have to ask divVerent
[01:18] <Timothy_Gu> wm4: in #mpv ?
[01:19] <wm4> no, that channel is inhabited by pokemon fans
[01:19] <cone-200> ffmpeg.git 03Diego Biurrun 07master:14abeaa43d02: build: Separate building programs linking against libav* from building av*
[01:19] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:5ded4332f195: Merge commit '14abeaa43d021afdce9119d906891abe89c03b88'
[01:19] <wm4> we're in #mpv-player
[01:19] <Compn> wm4 : at least you have good company :P
[01:19] <Compn> ohhh
[01:19] <Compn> :P
[01:20] <Timothy_Gu> Any ideas about elenril's vdpau patch (or commit, rather) to ffmpeg/avconv?
[01:20] <Timothy_Gu> Why does it like duplicates so many lavc code?
[01:20] <wm4> it's not supposed to be fast, but for testing
[01:20] <wm4> it does?
[01:21] <Compn> reimar said it would be nice as a decoder, instead of hardcoded in ffmpeg.c
[01:21] <Compn> i think
[01:21] <wm4> like this vda thing?
[01:23] <Timothy_Gu> Why does lavc have a special HWAccel infrastruct? Why don't we just make them like a normal codec?
[01:23] <Compn> so we can fallback to normal codecs if they fail ?
[01:23] <Timothy_Gu> compn: yeah
[01:23] <Compn> really i have no idea
[01:23] <Compn> i just make things up and cause trouble :)
[01:24] <wm4> I have no idea either
[01:24] <Compn> ask carl :)
[01:24] <wm4> for fallback, and because it's Better(tm)
[01:24] Action: Compn waves to carl
[01:24] <wm4> but uh, I'm doing my own fallback anyway
[01:24] <wm4> because lavc's didn't work until recently
[01:25] <wm4> Compn: these movtext subtitles contain weird things like "cc608:AAAAEcX//JQm/YCA/wMi/oj//gAA0.000"
[01:25] <Compn> wm4 : some kind of encoding, no doubt
[01:26] <Timothy_Gu> If so that would save VLC & MPlayer and family (& ffmpeg.c) so many code
[01:26] <wm4> and the duration of each sub packet is only 30ms
[01:26] <wm4> Timothy_Gu: fallback isn't much code
[01:26] <Compn> Timothy_Gu : i've always asked if ffmpeg could include all the vdpau glue code so we can eliminate and combine forces with vlc and mplayer :)
[01:27] <wm4> Compn: what do these subs look like in flash player?
[01:27] <Compn> wm4 : like closed captioning
[01:27] <Compn> "CEA-608", used to be the standard for closed captioning for NTSC TV broadcasts in the United States,
[01:27] <wm4> Compn: vdpau is not easy because decoding and display depend on each other, basically
[01:27] <Compn> "cc608"
[01:27] <Timothy_Gu> compn: but why didn't ffmpeg do that
[01:27] <wm4> Compn: and what does it look like
[01:27] <wm4> Timothy_Gu: because things are not as simple
[01:28] <Compn> wm4 : dont you have quicktime installed ?
[01:28] <wm4> no
[01:28] <Timothy_Gu> wm4: that is a concise answer
[01:28] <Compn> wm4 : black bg, white text
[01:29] <wm4> Timothy_Gu: the long version would require explaining how vdpau works
[01:29] <Compn> Timothy_Gu : i dont know. libav devs removed a lot of glue code and libcode from ffmpeg
[01:29] <Compn> and apis...
[01:29] <wm4> Compn: uh, so, they just dumped CCs into a mov_text track?
[01:29] <Compn> like libxvid etc
[01:29] <Compn> wm4 : no, thats how dumb apple encodes its closed captions > http://documentation.apple.com/en/finalcutstudio/workflows/index.html#chapter=6%26section=4%26tasks=true
[01:29] <Timothy_Gu> wm4: and what about va-api?
[01:30] <Compn> in mov
[01:30] <wm4> Timothy_Gu: same issue... and also dxva and vda
[01:30] <wm4> Compn: also, vlc knows to error out correctly
[01:30] <wm4> and doesn't interpret it as movtext
[01:31] <Compn> its mov_text , just a diff type of ... parsing that mplayer doesnt have
[01:31] <Compn> like utf characters
[01:31] <Compn> represented in /abc/def i think
[01:31] <wm4> Timothy_Gu: the main problem is that you just have to share the hw device handle with lavc
[01:32] <wm4> maybe lavc could handle some more aspects of hwaccel api usage, but the basic problem is the same
[01:32] <Timothy_Gu> wm4: why are all hwaccels so stupid?
[01:32] <Timothy_Gu> wm4: why are all hwaccels API's so stupid?
[01:33] <wm4> dunno, but I'd say they're not as bad as opengl (which has an implicit context etc.)
[01:33] <Compn> Timothy_Gu : because nvidia made vdpau ? 
[01:33] <wm4> the only really bad thing about vdpau is preemption
[01:33] <Compn> and they wrote the patches for ffmpeg...
[01:33] <Compn> (and mplayer)
[01:34] <Compn> (everyone blames mplayer)
[01:34] <wm4> yeah... mplayer's craptastic internals might actually have contributed to ffmpeg's hwaccel api being so low level
[01:34] <Compn> lol
[01:34] <wm4> but the "real" hwaccel still came later
[01:34] <wm4> so you can still blame ffmpeg plenty
[01:35] <wm4> lu_zero on libav actually wants to improve the hwaccel api
[01:35] <llogan> Timothy_Gu: it's called qatar because they claimed to have moved to qatar or something
[01:35] <llogan> http://misc.socialbladeshow.com/afd/screenshots/10781-l.jpg
[01:35] <Compn> the qatar thing was an april fools joke, a few years back, iirc
[01:36] <Timothy_Gu> llogan: that's weird
[01:36] <wm4> lol
[01:36] <Timothy_Gu> wm4: that's nice... as long as they don't ABI anymore
[01:36] <llogan> Timothy_Gu: i won't be able to look at your web patches for at least another day or two. i just had some hardware failure to deal with...
[01:37] <wm4> Timothy_Gu: if they do it, it will be a 100% API break
[01:37] <Timothy_Gu> Gotta go
[01:39] <Compn> wm4 : stupid links in apple documentation are 404 :\
[01:39] <Compn> llogan : did you do a scan of ffmpeg website for broken links ?
[01:39] <llogan> not for a long time
[01:39] <Compn> someone should do that
[01:40] Action: Compn volunteers to be lazy
[01:41] <iive> there must be a script of project that does it.
[01:42] <Compn> yes the w3c validator does it
[01:42] <Compn> if you want to run it iive :)
[01:43] <iive> i have no idea what that is... sounds painful.
[01:43] <Compn> timothy worked a lot on the undocumented options in ffmpeg
[01:43] <llogan> Compn: by now you could have validated at least one page
[01:45] <BBB> ok well that was a silly bug
[01:45] <Compn> http://validator.w3.org/checklink
[01:45] <Compn> llogan : ok, running now
[01:47] <Compn> http://americancensorship.org/images/stop-censorship-small.png is 404
[01:48] <Compn> heh
[01:48] <Compn> bunch of soc urls are dead
[01:49] <Compn> one mphq mailing list post is 404
[01:50] <wm4> ?
[01:50] <wm4> how does this happen?
[01:53] <Compn> ml gets rebuilt once in a while
[01:53] <Compn> the numbers all change
[01:53] <Compn> link to old number > 404
[01:54] <Compn> file a bug with mailman
[02:13] <lukaszmluki> i'm an idiot :)
[02:14] <cone-200> ffmpeg.git 03Diego Biurrun 07master:ab81f24ad43b: build: Integrate multilibrary examples into the build system
[02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:6d34aa245df8: Merge commit 'ab81f24ad43bddf77ddd25cba86780c1c884996c'
[02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:325c918fa3d6: Makefile: Fix building progs out of progs_g
[02:14] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:f1db007e008d: doc/Makefile fix PROGS
[02:15] <lukaszmluki> spending whole night to figurei swapped columns with rows  of the matrix
[02:19] <BBB> hm the scalability of this thing isn't fantastic
[02:19] <BBB> 9.7 -> 6.0 for 1 -> 2 threads, but only 6.0 -> 5.2 for 2 -> 4 threads :(
[02:19] <BBB> the 2-pass really is hurting
[02:55] <cone-200> ffmpeg.git 03Diego Biurrun 07master:5145ccf02b17: aacsbr: Add some const casts to silence warnings in ff_sbr_apply()
[02:55] <cone-200> ffmpeg.git 03Michael Niedermayer 07master:a9a3afec1a9c: Merge remote-tracking branch 'qatar/master'
[03:12] <llogan> michaelni: if the current crop of spam filters is working adequately then i don't think we'll need more if they slow down trac (i'm not sure if the current ones do or not).
[03:13] <llogan> also we can contact http:bl to periodically download the DNS zone file instead of querying the remote DNS server each time if it causes slowness.
[03:14] <michaelni> feel free to close the ticket in that case (and reopen if the spam issue seems not resolved at a later point)
[03:14] <michaelni> about slowness, no idea, did you notice a slowdown ?
[03:15] <llogan> no, but i haven't really done much with trac since
[03:15] <llogan> just thinking out loud...
[03:15] <michaelni> also note that there are 2 threasholds and when the score is above them then external services wont be contacted 
[03:15] <michaelni> for a submission
[03:16] <llogan> ok. i'll wait a few days to a week and if things seem good i'll close ticket unless you do first
[09:01] <plepere> aaaaarg. why does asm hate me so much ?
[09:02] <plepere> doing a call <function> gives me a seg fault
[09:02] <plepere> call put_hevc_mc_pixels_2_8 wroks
[09:02] <plepere> but call put_hevc_epel_v_8_8
[09:02] <plepere> does not
[09:02] <plepere> *works
[09:03] <plepere> both functions are fully functional
[09:03] <plepere> doing the call after the function declaration
[09:13] <kurosu> calling convention changes across abis
[09:13] <kurosu> ie whether an arg is in a reg, and what regs, and what order of regs
[09:13] <kurosu> plepere: http://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention
[09:14] <kurosu> I prefer avoiding doing calls if possible, but I know this bloats code
[09:15] <kurosu> also, are you doing work/reserving space on the stack and are you restoring it properly ?
[09:15] <kurosu> anyway, afk
[09:15] <plepere> hmm
[09:15] <plepere> it's working on a function with 6 arguments
[09:16] <plepere> so you're saying that if I call a function, I should manually load the arguments from the stack to the registers beforehand ?
[09:18] <plepere> thanks anyway. :)
[09:20] <ubitux> plepere: it depends.
[09:20] <plepere> I found the error. I'm apssing too many arguments
[09:20] <plepere> *passing
[09:21] <ubitux> also, can't you avoid the call with macrotization?
[09:22] <plepere> ubitux : I'm having different functions for different levels of optimisation depending of width size. I'm testing the width to see which function to call.
[09:22] <plepere> in the end, we will probably go through pointers directly, but at the moment, it's simpler for the higher-levels
[09:23] <ubitux> ok
[09:31] <plepere> if using macros can help, then I'm ready to do it, but I never used macros before.
[10:00] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:4c4710a745ae: configure: define CONFIG_THIS_YEAR at the configure level
[10:35] <ubitux> i see some more complains about restoring hall of fame
[10:35] <ubitux> shame*
[10:37] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:8bf7ea8ac210: cmdutils: remove this_year constant, use CONFIG_THIS_YEAR instead
[10:53] <ubitux> BBB: what is this 2 pass thing?
[11:34] <oden> hello. trying to understand what security fixes has been fixed in 0.10 since 0.10.6 to 0.10.10. http://ffmpeg.org/security.html does not say.
[12:24] <michaelni> oden, ill try to update the page, but 0.10 is quite old
[12:25] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:de44dfc7c0ec: vc1: Reset numref if fieldmode is not set
[12:25] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:0290a646ac66: Merge commit 'de44dfc7c0ec02bda7d846ef713145c890bfae3f'
[12:33] <BBB> ubitux: evil stuff
[12:33] <ubitux> can you summarize the concept?
[12:33] <BBB> ubitux: remember bw probability updates? i.e. where one frame's distribution helps update the prob tables for the next frame?
[12:34] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:56d061ce9da9: metasound: add last missing modes (8kHz @ 6kbps per channel)
[12:34] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:ac021fdc4063: Merge commit '56d061ce9da954560892e3551513d5ecc0439846'
[12:34] <ubitux> BBB: ok, yes 
[12:34] <BBB> let's say yes
[12:34] <BBB> so this means I can't start the next frame until the previous frame has updated its prob tables
[12:35] <BBB> else I'll get garbage
[12:35] <ubitux> oh ok
[12:35] <BBB> so I can't do interleaved mode decoding and reconstruction
[12:35] <BBB> because then I can only start the next frame when the prev frame is done
[12:35] <BBB> which is not very helpful
[12:35] <BBB> so we do 2pass decoding
[12:35] <BBB> pass 1: bitstream parsing (i.e. decode_mode only)
[12:35] <BBB> pass 2: everything else (recon_inter/intra and loopfilter_sb)
[12:36] <ubitux> i see
[12:36] <ubitux> you were mentioning samples in "threading" mode, so i guess with a different prob update method?
[12:42] <BBB> ubitux: yeah, that uses fw only, so we can do what vp8 did
[12:42] <BBB> ubitux: but I have no samples for that, so no idea if it works at all
[12:57] <cone-395> ffmpeg.git 03Kostya Shishkov 07master:a16577d98572: MSN Audio support
[12:57] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:8c87658fdc65: Merge commit 'a16577d9857206089fd8bce6a342b31dbd7fb9b0'
[12:57] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:cd51d9a98403: Revert "avcodec/gsmdec: reject unsupported msn audio modes"
[13:11] <cone-395> ffmpeg.git 03John Stebbins 07master:1eaac1d6f7bb: mpeg12dec: Extract CC user data into frame side data
[13:11] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:625b29037e52: Merge commit '1eaac1d6f7bb8e52d82e1a114c88a59a9a8e5025'
[13:12] <oden> michaelni: thanks.
[13:19] <mraulet> michaelni:https://github.com/OpenHEVC/FFmpeg/commit/211c39ade87bc079eabc862a6b684544dc88a786
[13:19] <mraulet> fix valgrind
[13:21] <cone-395> ffmpeg.git 03Anton Khirnov 07master:c6080d890090: lavc: remove mp3_header_(de)compress bitstream filters
[13:21] <cone-395> ffmpeg.git 03Michael Niedermayer 07master:75ec40b083ff: Merge remote-tracking branch 'qatar/master'
[13:27] <cone-395> ffmpeg.git 03gcocherel 07master:3c846fda1ca3: HEVC : valgrind fix : vps_list
[13:27] <michaelni> mraulet, applied, thanks
[13:43] <BBB> ubitux: want to help amending patches? I'll only have time this weekend
[13:44] <BBB> babies fuss too much to be able to do anything right now
[13:44] <ubitux> i'm not really available currently
[13:45] <ubitux> i mean, it doesn't look like it, but i have a job too :(
[13:50] <BBB> lol :) but I have kids
[13:51] <BBB> anyway I'll update this weekend or so
[14:13] <BBB> ubitux: ok fixed the indent and missig alloc check on github
[14:14] <ubitux> i'll try to have a look tonight
[14:14] <ubitux> it's not a RFC btw right?
[14:14] <ubitux> it's complete?
[14:26] <smarter> ubitux: I think you can generate samples without backward probability updates using vpxenc --frame-parallel=1
[14:27] <smarter> also I guess you could combine tile-mt and frame-mt to decode the modes faster?
[14:29] <ubitux> mmh ok
[14:29] <ubitux> speaking of libvpx
[14:29] <ubitux> i should test for the annoying encoding bug with vp8
[14:29] <ubitux> with libvpx itself
[15:10] <plepere> I remember someone posting an example of calling a C function from asm here, but I can't get my hands on it. :/
[15:13] <ubitux> cd libavcodec/x86
[15:13] <ubitux> git grep call
[15:14] <plepere> why git ?
[15:16] <plepere> anyways, it works. thank you
[15:25] <ubitux> plepere: because git grep rox ofc
[15:25] <plepere> yes, found out that git grep is unrelated to git .:p
[15:26] <nevcairiel> calling C functions from asm is problematic in many cases though, so make sure you really need it
[15:26] <ubitux> plepere: it is.
[15:26] <plepere> nevcairiel : it's for a slow pass.
[15:27] <plepere> ubitux, ok, I give up T_T
[15:27] <nevcairiel> emulating all the calling conventions between win64, win32 and linux is just a bit complicated :d
[15:27] <plepere> ok ok
[15:29] <plepere> r7d is a byte ?
[15:29] <nevcairiel> d is double-word, 32-bit
[15:29] <plepere> so w is 16
[15:58] <michaelni> oden, security page updated, ill add CVE# where they are missing as soon as they are assigned
[16:10] <oden> michaelni: thanks. so 0.10.10 has no sec flaw fixes?
[16:24] <michaelni> oden, there where some things backported that may or may not be security relevant, for example a infinite loop fix, also there was some fixes merged from libav that i belive where redundant and fixed previously. also i dont think any ffmpeg version or fork from the 0.10 times is completely free of security issues
[16:24] <ubitux> does anyone know if anton has me in ignore list?
[16:27] <av500> on irc?
[16:30] <ubitux> yes
[16:31] <ubitux> i raised a bug in the hwaccel yesterday and provide him an avconv backtrace but he didn't react
[16:31] <ubitux> and i asked something about arm offsets after the mpegcontextenc update he did
[16:31] <oden> michaelni: ok. thanks. it's quite difficult to tell these days.
[16:33] <michaelni> oden, yes, iam aware of that, ill try to keep the security page more upto date in the future
[16:34] <ubitux> av500: maybe i'm wrong about the arm offsets so he thought it didn't matter to answer me, but if i'm right he might be interested about it
[16:34] <oden> michaelni: great.
[16:36] <ubitux> av500: well it seems he actually ignores me, so feel free to forward my hwaccel backtrace from the other day and the arm offset thing
[16:47] <ubitux> well i guess i should stop reporting them bug & fixes
[16:47] <ubitux> it seems it's still seen as a "you show us than ffmpeg is better than libav"
[16:47] <ubitux> &like i would try to demonstrate something we know since years&
[16:47] <ubitux> whatever
[16:48] <ubitux> </rant>
[18:18] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:7de3b1394b71: lavd/sdl: add event handler thread
[18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:7467b4f71b4b: lavd/sdl: factorize overlay rect size in a separate function
[18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:0464d272ff9d: lavd/sdl: move compute_overlay_rect() before event_thread()
[18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:b23dea27fdb6: lavd/sdl: allow to change window size
[18:19] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:35349bbb97eb: lavd/sdl: apply misc cosmetics to options
[18:39] <cone-395> ffmpeg.git 03Stefano Sabatini 07master:704331196910: lavd/sdl: add delay when no events are found in the event queue
[20:19] <llogan> the new trac looks nice
[20:20] <llogan> especially stuff like `-option` in the wiki
[20:30] <Timothy_Gu> llogan: what do you mean? What's the `-option?
[20:31] <llogan> that's WikiFormatting markup for "monospace" font style
[20:32] <llogan> http://trac.ffmpeg.org/wiki/WikiFormatting#FontStyles
[20:32] <llogan> previously it was not as easy to see a difference between the normal text and the monospace text which i used to differientiate options and commands
[21:49] <Timothy_Gu> Is cone-* ("irker irc client") related to VLC?
[21:51] <JEEB> it's a bot hosted by VideoLAN, the git repository is currently hosted by VideoLAN as well
[21:51] <JEEB> VideoLAN provides such services for various projects
[21:56] <Timothy_Gu> JEEB: then why did it quit?
[21:57] <Timothy_Gu> JEEB: http://naevis.jbkempf.com
[21:57] <Timothy_Gu> JEEB: "Chaussure" down?
[21:58] <JEEB> ask that from videolan?
[00:00] --- Wed Nov 27 2013