[02:33] <michaelni> ubitux, fate sub-charenc seems failing on qemu boxes [02:34] <cone-286> ffmpeg.git 03Jean First 07master:2d7044683f3c: ffmpeg_opt: add -to option to specify stop time [03:10] <cone-286> ffmpeg.git 03Michael Niedermayer 07master:1672624ddc74: mpegvideo_enc: fix gray flag with 444 jpeg [03:10] <cone-286> ffmpeg.git 03Michael Niedermayer 07master:0dcecf45d80c: avcodec: mbd has a range of 0..2 [03:56] <cone-286> ffmpeg.git 03Michael Niedermayer 07master:5d2f2c76435e: oggdec: chained oggs have timestamp discontinuities [11:59] <cone-803> ffmpeg.git 03Martin Storsjö 07master:31a23a0dc663: x86: dsputil_mmx: Remove leftover inline assembly fragments [11:59] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:f2bbc2ffc338: Merge commit '31a23a0dc663bd42bf593275971b4277a479b73d' [12:03] <cone-803> ffmpeg.git 03Diego Biurrun 07master:096cc11ec102: x86: vc1dsp: Move ff_avg_vc1_mspel_mc00_mmxext out of dsputil_mmx.c [12:03] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:04ec796bda79: Merge commit '096cc11ec102701a18951b4f0437d609081ca1dd' [12:35] <cone-803> ffmpeg.git 03Diego Biurrun 07master:845cfc92f908: x86: dsputil: Drop aliasing of ff_put_pixels8_mmx to ff_put_pixels8_mmxext [12:35] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:cdb9752a0f96: Merge commit '845cfc92f908791714b8c4c8a49c91b8c64b685e' [12:40] <cone-803> ffmpeg.git 03Diego Biurrun 07master:ebc701993fec: x86: dsputil: Drop some unused function #defines [12:40] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:50c2738883b7: Merge remote-tracking branch 'qatar/master' [13:58] <ubitux> michaelni: yes but i don't have a good solution in mind [13:58] <ubitux> the issue is that some iconv setup seems to lack the cp1251 info [13:59] <ubitux> i thought about adding another flag specifically for that info in the configure, but it kind of sucks hard [14:03] <michaelni> ubitux, cant you check in configure that cp1251 is available and if not then not enable iconv [14:03] <michaelni> ? [14:04] <ubitux> some people might want the feature even without having the russian character encoding info [14:04] <ubitux> michaelni: can you send me the result of the iconv -l command on one of those machine? [15:09] <michaelni> ubitux, trying to execute the installed iconv through qemu results in "Error -1 while loading iconv" [15:10] <michaelni> and i dont think theres a target specific iconv excutable installed [15:10] <Daemon404> who runs the ffmpeg-devel thread archives? (http://ffmpeg.org/pipermail) [15:11] <Daemon404> its stopped being updated about 10 days ago [15:14] <Compn> Daemon404 : http://ffmpeg.org/pipermail/ffmpeg-devel/2013-February/date.html [15:14] <Compn> what ? [15:14] <Compn> i see posts from feb 27th... [15:14] <Compn> http://ffmpeg.org/pipermail/ffmpeg-devel/ [15:14] <Compn> same amount of messages in both thread and date [15:15] <Daemon404> hmmm [15:15] <Compn> you mean the downloadable tar.gz ? [15:15] <Daemon404> inb4 it's chrome's cache being rap [15:15] <ubitux> michaelni: arg... so isn't iconv just broken on those systems? [15:15] <Compn> ehe [15:15] <Compn> >using google software [15:16] <Daemon404> >using windows 2000 [15:18] <Compn> the irony being , chrome doesnt work on win2k [15:19] <Daemon404> i think you need to look up teh definition of irony. [15:20] <Compn> firefox dropped support as well [15:22] <ubitux> microsoft as well [15:22] <ubitux> (no?) [15:22] <Daemon404> microsoft ropped win2k support YEARS ago [15:22] <Daemon404> any years ago [15:22] <Daemon404> compn is basically botnet [15:22] <Compn> gotta do my part , for skynet! [15:23] <nevcairiel> cant wait for june 2014 when XP support finally drops [15:23] <Daemon404> ^ [15:23] Action: JEEB high-fives nevcairiel [15:24] <nevcairiel> i'm sure the millions that use XP right now still because they believe its better wont change their mind until then, but i stop caring then [15:25] <Daemon404> 13 years is a good run. [15:26] <michaelni> ubitux, no clue about iconv under user mode qemu [15:26] <JEEB> for a commercially supported piece of software used by end users as well as corps, it is very well (if you go for corps-only you will find software that has run for 20+ years, but that doesn't count) [15:26] <nevcairiel> even debian stable isnt that old =P [15:27] <Daemon404> 20+? [15:27] Action: Daemon404 knows of vax emus [15:27] <michaelni> ubitux, but if its broken it should not get enabled [15:27] <ubitux> michaelni: the configure says it's working [15:27] <ubitux> michaelni: it just seems cp1251 codepage is not available [15:27] <ubitux> so the particular fate test can not work [15:28] <michaelni> cant configure test for that codepage ? [15:28] <ubitux> yes sure it can, we can just add a "HAVE_ICONV_WITH_CP1251" just for fate [15:28] <ubitux> would that be fine? i find it a bit clumsy but well... [15:29] <michaelni> is there a point in enabling iconv at all if cp1251 isnt there ? [15:29] <ubitux> yes, maybe the iconv has various other convertion charsets [15:29] <ubitux> cp1251 is just for russian, it may have some other [15:29] <ubitux> (that's the reason i asked for a iconv -l to list them) [15:29] <Compn> what if its listed under windows 1251 ? :P [15:30] <ubitux> i have both here [15:30] <ubitux> - iconv -l|grep 1251 [15:30] <ubitux> CP1251// [15:30] <ubitux> WINDOWS-1251// [15:30] <ubitux> afaik they are the same [15:30] <Compn> ah [15:31] <michaelni> ubitux, id have to cross compile a iconv first before i can run qemu iconv -l [15:32] <michaelni> isnt there a easier way [15:32] Action: michaelni lazy [15:32] <ubitux> mmh [15:32] <ubitux> is there some stuff in /usr/share/i18n/charmaps ? [15:32] <Daemon404> that doesnt sound portable at all [15:33] <Daemon404> espeiallt to more unixy things like solaris [15:33] <ubitux> i'm not trying to ask a portable question :) [15:33] <ubitux> just trying to figure out a bit how this iconv is setup [15:33] <Daemon404> i thought all the cool kids used icu nowadays [15:35] <ubitux> the choice of iconv was purely arbitrary, i never tried icu [15:36] <durandal_1707> michaelni: your opinion on libswscale drop? [15:37] <ubitux> wat? [15:37] <JEEB> but icu has to be used together with something else [15:37] <Daemon404> oh [15:37] <Compn> durandal_1707 : thread or more detailed plan ? [15:37] <JEEB> also jesus christ I've read/heard too much Japanese to not see "icu" as the verb "iku" [15:38] <ubitux> oci [15:38] <ubitux> oic [15:38] <Compn> isnt iku japanese for .... [15:38] <JEEB> let's just say "to go" [15:38] <JEEB> and not take it further ;) [15:38] <durandal_1707> Compn: i want to use babl [15:38] Action: Compn seen too much "anime" too [15:39] <Compn> durandal_1707 : like everything, i'm sure ffmpeg would be ok with having two swscale setups. or a branch with a different sws library. if its faster, it will be approved... [15:40] <Compn> and merg-ed [15:43] <michaelni> durandal_1707, do you have a replacement that has same features and speed? [15:44] <michaelni> ubitux, i see /usr/share/i18n/charmaps but thats just the host i dont see target specific ones [15:52] <Compn> durandal_1707 : are you asking for michaelni's help in swapping in a new sws ? do you have a list of libs that can replace it ? [15:53] <durandal_1707> Compn: no i just dream about such library [15:55] <kierank> me too [15:55] <wm4> me too (please handle all corner cases) [15:56] <Daemon404> babl certainly is not this library though [15:58] <Compn> what about just replacing one scaler at a time ? whats the fastest rgb to yuv lib ? [15:59] <Daemon404> proably swscale. [16:00] <Compn> shh dont tell them that [16:00] <kierank> swscale can only do rgb to yuv with 601 [16:00] <Daemon404> ive personally been using a a diff lib, but it is slow [16:01] <Daemon404> and kind of mangled atm [16:01] <Daemon404> and teh author hates VCS [16:01] <Compn> kierank : you want rgb2yuv 702? [16:01] <Daemon404> no, but he might want 709 [16:01] Action: Compn forgets the numbers [16:01] <Compn> 709! [16:02] <Daemon404> whenever i do rgb<->yuv conversions for import into e.g. After effects, i use avisynth or dithertools [16:02] <Daemon404> for that very reason [16:03] <Daemon404> oh wait its called fmtconvert now [16:03] <wm4> yeah, I pointed durandal_1707 to it [16:04] <Daemon404> wm4, i feel like people around here could benefit from reading doom9 sometimes [16:04] <Daemon404> instead of being in an mplayer bubble [16:04] <Daemon404> me runs [16:04] <JEEB> wonder how easily you could first make fmtconv into a video filter to test it [16:04] <Daemon404> iirc its not so fun [16:04] <Daemon404> he mngled it in with teh plugin code [16:04] <Daemon404> and usd intrinsics [16:04] <Daemon404> used* [16:05] <Daemon404> sometimes with no C/C++ version... [16:05] <Daemon404> he's a classic avs dev. [16:05] <JEEB> so it seems [16:05] <wm4> and releasing source code by posting it as forum attachments too... interesting culture [16:05] <Compn> >blame mplayer forever [16:05] <Compn> :P [16:05] Action: Compn trolled [16:05] <Daemon404> Compn, well if the glove fits... [16:06] <Daemon404> wm4, most have oved to VCs (github) now [16:06] <JEEB> also regarding d9 [16:06] <Daemon404> or google code [16:06] <Daemon404> fmtconv guy is just a weirdo [16:06] <JEEB> someone just posted a damn swscale question in the H.264 forum [16:06] <kierank> oh it's that guy [16:06] <Compn> vlc uses swscale too ? [16:06] <kierank> yes [16:06] <Compn> i guess it has to [16:07] <wm4> doesn't vlc have some custom conversion code too? [16:07] <Compn> sure, they like to reinvent wheels [16:07] <Daemon404> practically every project in existence does [16:07] <Daemon404> precisely because fuck swscale [16:11] <durandal_1707> why not babl? [16:12] <durandal_1707> did we just get new kind of spamming with git format-patch ? [16:14] <Daemon404> maybe [16:14] <Daemon404> definitely. [16:15] <Compn> so what sws does imagemagick have ? [16:15] <Daemon404> oh wait nvm that wasnt git-send-email [16:15] <Daemon404> Compn, i dont know but it is hilariously slow [16:15] <Compn> we should help them [16:15] <Compn> give them swscale :D [16:16] <wm4> "give them deadly poison" [16:17] <wm4> well at least it's very fast [16:17] <Daemon404> i dont know if youve ever touched imagemagick [16:17] <Daemon404> but i ts p retty close to dealy poison itself [16:17] <wm4> everyone dies, best case /sarcasm [16:18] <michaelni> only safe way is to rewrite everything, never contribute never reuse. This is the 1st rule of FOSS ;) [16:19] <Compn> michaelni : should make it closed source, then they cant complain about what it looks like [16:19] <Daemon404> michaelni, i heard you like linux's audio subsystems [16:19] <wm4> I wonder how gstreamer's dynamic compiler thing fares from a technical point of view (I guess probably not much, but still interesting idea) [16:19] <Daemon404> has gstreamer ever done anything technical of note? [16:19] <Daemon404> ever [16:19] <michaelni> Daemon404, i dont like them because they tend not to "just work" from a user perspective [16:20] <durandal_1707> michaelni: just give bounty for rewrite of some part of swscale code [16:20] <Daemon404> michaelni, theyre also bad from a dev perspective :P [16:20] <michaelni> iam not planing to rewrite any or add more to the already existing number [16:20] <Daemon404> durandal_1707, money isnt enough for people to work on swscale [16:20] <Daemon404> hence the guy who wrote XYZ support put it in lavfi [16:20] <Compn> someone emailed projects@mphq requesting mplayer make ao oss priority ahead of ao alsa in the try audio outputs order... [16:21] <Daemon404> why u no pulse? [16:21] <durandal_1707> michaelni: also note that exr float conversions is making image outputs too underexposed [16:21] <Compn> because fuck ubuntu thats why [16:21] <Daemon404> >implying pulse<->ubuntu [16:22] <wm4> Daemon404: pulse adds additional bugs on top of alsa (really) [16:22] <Compn> what distro you running Daemon404 ? [16:22] <Daemon404> i run a distribution called windows 8 [16:22] <Daemon404> and also debian unstable [16:22] <Compn> did you install pulse or did debian ? [16:22] <Daemon404> neither [16:22] <Daemon404> beause its head;ess [16:22] <Daemon404> headless* [16:23] Action: Compn slaps himself [16:23] <Daemon404> ok, so i also have an ubuntu box for dev work sometimes (with fluxbox) ;) [16:23] <Daemon404> i guess that uses pulse [16:24] <Compn> but yes i'm implying no one would be using pulse if ubuntu didnt jump that shark [16:24] <Daemon404> michaelni, quick ping, re: swscale rgb patch -- libav finally OK'd it, so once ffmpeg Oks it i can finally let that 6 mnth old patch die [16:24] <Daemon404> Compn, i think you forget rhel and fedor [16:25] <Daemon404> who employ the guy wh wrote pulse [16:25] <Compn> its a conspiracy! [16:25] <Compn> but also i'm not the one who makes the decisions in mplayer [16:25] <Compn> so thats why i no pulse [16:25] <cone-803> ffmpeg.git 03David Favor 07release/1.1:d4d1f32e48d9: Slight bug building ffmpeg-1.1.3 on OSX + patch to fix [16:26] <cone-803> ffmpeg.git 03Michael Niedermayer 07release/1.1:cdbaaa4f001e: doc/ffmpeg: remove non ascii char [16:26] <wm4> as soon as systemd has a hard dependency on pulse, everyone will use it [16:26] <Daemon404> hahahaha [16:29] <ubitux> michaelni: http://pastie.org/private/isycwcxhp1opps2olfeew [16:29] <ubitux> i have no better idea in mind currently [16:30] <Daemon404> eh.. if check_exec does what i think it does [16:30] <Daemon404> then that oesnt work at all for cross compilation [16:32] <ubitux> i have no other mean to test this [16:32] <Daemon404> exactly. you cant. [16:33] <Daemon404> its up to teh target system [16:33] <ubitux> so what do you propose? [16:34] <Daemon404> a runtime check that fails gracefully [16:34] <Daemon404> as for fate -- probably nto feasible. [16:34] <ubitux> right, so the current solution is correct [16:35] <ubitux> (without this patch) [16:35] <Daemon404> it's not "correct" [16:35] <Daemon404> its actully outright WRONG [16:35] <Daemon404> oh [16:35] <Daemon404> without the patch [16:35] <ubitux> :) [16:35] <ubitux> maybe and iconv-test program can be built [16:36] <ubitux> and used before running the sub char enc test [16:40] <cone-803> ffmpeg.git 03Derek Buitenhuis 07master:c87c2d0d0287: swscale: Add support for unscaled 8-bit Packed RGB -> Planar RGB [17:16] <Compn> ehe [17:16] <Compn> i'd add "binary codec loader" to gsoc idea, but probably no one wants that :) [17:17] <Daemon404> you mean some ancient wine code copypasta'd? [17:21] <nevcairiel> native-only would be boring [17:21] <nevcairiel> need to load windows codecs! [17:21] <durandal_1707> Compn: this is not #mplayer [17:27] <gnafu> "Ain't nobody got time for that!" [17:29] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:21c2e201f6aa: vf_lut: correct color/comp permutation [17:29] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:5c924c9b7d6d: dv: Correctly identify CDVC profile [17:34] <cone-803> ffmpeg.git 03Paul B Mahol 07master:9774145fe5ae: exr: simplify decompression path [17:53] Action: durandal_1707 found that uploading images becomes extremly hard [17:55] Action: durandal_1707 translated adverts hurts my eyes [18:06] <durandal_1707> what compression is this: http://www.imagetoo.com/?v=omvm.png ? [18:07] <nevcairiel> that looks a bit like a wavelet transform [18:09] <Daemon404> doesnt look like a transform me me... more like some prediction [18:09] <Daemon404> but what do i know [18:10] <Daemon404> or dithered [18:13] <durandal_1707> its 16 bit haar wavelet [18:13] <nevcairiel> see, wavelet! [18:16] <Daemon404> ive never seen haar produce that sort of pattern [18:16] <Daemon404> (and only one image to boot) [18:18] <durandal_1707> that is what you get prior to calling wavelet decoding in exr with piz compression [18:18] <Daemon404> dont you need the lowpass info to reconstruct such a transform [18:21] <michaelni> ubitux, did you see the darwin iconv failures ? [18:22] <michaelni> (on fate) [18:22] <ubitux> arg [18:22] <ubitux> wtf is wrong here.. [18:24] <ubitux> maybe we should move to a config mode for iconv [18:25] <ubitux> this built-in vs lib mess is going to be a problem [18:43] <durandal_1707> should i use realloc for blocks of structures or there is higher api for it? [18:53] <cone-803> ffmpeg.git 03Frederic Jean 07master:c53e8d9029f5: Include fix for building ismindex under MinGW [18:53] <cone-803> ffmpeg.git 03Michael Niedermayer 07master:1fd04cac001f: Merge remote-tracking branch 'fredjean/master' [19:01] <cone-803> ffmpeg.git 03Nicolas George 07master:f102c24d9040: ffmpeg: free last sub when using -fix_sub_duration. [19:07] <cone-803> ffmpeg.git 03Nicolas George 07master:13811b19d6b4: lavc/libopusenc: report an error if global_quality is set. [19:26] <ubitux> trac looks down [19:27] <durandal_1707> not for me [19:27] <nevcairiel> seems fine here too [19:27] <ubitux> looks fixed [19:30] <Compn> ubitux : hows mplayer or vlc handle iconv ? [19:33] <ubitux> Compn: problem is not that much iconv support [19:34] <ubitux> afaik they don't have fate first [19:34] <ubitux> also, cross compiling mplayer is not known to be the most trivial op [19:35] <ubitux> anyway, it seems darwin will need some more advanced check (or maybe something is broken in the additional check_lib) [19:54] <llogan> http://i.stack.imgur.com/SxV5s.jpg [19:54] <llogan> used to illustrate an answer for ubuntu users about their "ffmpeg" [19:55] <gnafu> Hehe. [19:59] <Compn> lol [20:00] <Compn> llogan : why not make an infographic about it ? [20:05] <Compn> llogan : what does ubuntu ffmpeg now say? from the bug trac it looks like they changed it? or no? [20:09] <ubitux> nothing changed [20:10] <llogan> Compn: infographic would be interesting/fun, but meatspace work. [20:10] <llogan> ...is in the way [20:10] <llogan> only new thing that has happened is that the bizarro ffmpeg package has been dropped from Debian experimental, AFAIK. [20:11] <llogan> and i'm probably going to re-open the "deprecated" message bug. [20:11] <ubitux> afaik, on debian/sid, when you checkout ffmpeg, you still get the criminal "FFMPEG DEPRECATED" message [20:11] <Compn> llogan and the two gsoc 2013 pages [20:11] <Compn> s/pages/threads [20:11] <llogan> yeah, that was my fault. [20:12] <llogan> Drunky McDrunkerton [20:53] <burek> is there anyone here who managed to use ffmpeg for real-time voice streaming (like voice chat) [20:54] <durandal_1707> you mean ffmpeg as utility? [20:54] <burek> well, yes [20:55] <durandal_1707> you could use it, as there are some speech encoders [20:55] <burek> well, I'd like to make a working scenario and create a wiki for that [20:55] <Daemon404> libcelt or libopus [20:55] <Daemon404> are what you want likely [20:55] <burek> since I realized by accident that a lot of people are eager to know that [20:56] <Daemon404> i dont know if the cli util can... seems more suited to lib use [20:56] <burek> i see, and what containers would you recommend for those two [20:56] <Daemon404> opus is ogg ofc [20:56] <Daemon404> no idea what celt uses [20:56] <JEEB> I'm not sure what ffmpeg even supports for opus [20:56] <durandal_1707> same [20:56] <Daemon404> (ogg is crap at streaming) [20:56] <JEEB> to mux [20:56] <JEEB> I think it has a matroska mapping, which is EXPERIMENTAL [20:57] <JEEB> (and IIRC not the same that Mosu implemented) [20:57] <Daemon404> lol awesome [20:57] <Daemon404> 2 years from now, bugs galore [20:57] <JEEB> also ffmpeg IIRC didn't even mark it as experimental in the ID or whatever [20:57] <durandal_1707> JEEB: can you point at what exactly is broken? [20:58] <burek> it would be very cool if we could make just a basic example of using ffmpeg <-> ffplay for creating a simple p2p voice chat [20:58] <podman> Compn: hey, this is Adam from SproutVideo. Just saying hi. [20:58] <durandal_1707> ffmpeg mark it as experimental, libav still does not [20:58] <burek> no need for something professional and stuf for a start [20:58] <JEEB> funky [20:58] <JEEB> durandal_1707, not necessarily broken but since the spec for opus-in-mkv still isn't set... [20:58] <JEEB> lemme find mosu's post [20:59] <durandal_1707> JEEB: i read forums threads too [20:59] <JEEB> anyways, opus just shows a thing where matroska is limited (no pre-roll signaling support) [20:59] <JEEB> lulz [21:02] <cone-803> ffmpeg.git 03Clément BSsch 07master:2ecf564f94f8: build: fix iconv detection on some systems. [21:03] <durandal_1707> burek: theoreticaly it could be possible, you could try to setup something if you have two computers [21:03] <burek> no problem, i have a will [21:04] <burek> i could try with opus/speex/celt, and use ts format for a start [21:04] <burek> but since I'm considering using ffplay on the other side [21:04] <durandal_1707> first, ts cant be used with opus/celt [21:04] <burek> is there a better/easier way to not use some standard format, but some, i dunno, internal ffmpeg's format, like nut or so [21:05] <durandal_1707> second using ffplay on other side, means other side could only listen [21:05] <burek> the goal is for that to work, it doesn't have to be standard at all :) [21:05] <burek> durandal_1707 yes [21:05] <durandal_1707> for start you could use 8k alaw [21:05] <burek> and other side will also use ffmpeg -> ffplay for vice versa [21:05] <burek> if you get my idea [21:06] <burek> ok i'll write that down for tests [21:06] <durandal_1707> 8k - 8000 hz sample rate mono [21:06] <burek> yes yes i get it [21:09] <burek> is it possible that I use raw audio output from ffmpeg over udp for example [21:09] <burek> and to capture it on the other side with ffplay [21:10] <durandal_1707> raw over udp? that is not going to work at all [21:11] <durandal_1707> you just pick port and stream to it [21:13] <burek> hmh [21:13] <burek> the problem is i dont know what formats are suitable for which of those, to start from something [21:26] <Compn> podman : oh, hello [21:26] <podman> Compn: starting to build out my own transcoding stack so I figured I'd start lurking around here [21:29] <Compn> youtube-in-an-archive [21:29] <Compn> ehe [21:30] <podman> have a lot of learning to do but it'll pay off [21:30] <podman> should be a lot cheaper than using third party transcoders [21:30] <Compn> sure, yeah [21:31] <Compn> i think its only the corner cases that will give you trouble [21:31] <podman> yeah, luckily i know what a lot of them are since the other providers i used ran into them [21:31] <Compn> for those i'd run the official software under virtual machines. like quicktime + qt_tools project to script it [21:32] <podman> seems like certain WMVs have a lot of weird things with display aspect ratios and whatnot [21:33] <podman> and there seem to be a lot of issues with VFR videos of slide shows [21:35] <Daemon404> [15:31] <@Compn> for those i'd run the official software under virtual machines. like quicktime + qt_tools project to script it <-- except that violates apples licenses [21:35] <podman> i accidently found out that -vf fps seems to fix it, although i have no idea what that filter is or what it does. [21:44] <Compn> Daemon404 : which license ? i mean... what would be the violation? virtualization? or ? [21:46] <podman> i think apple doesn't like people running osx under virtualization [21:47] <Compn> says its ok on apple hardware :P [21:47] <Compn> i didnt say run it on non apple stuff [21:47] <Compn> mr Daemon404 [21:47] <podman> heh [21:47] <Compn> and mr podman [21:47] <Compn> buy a mac :P [21:47] <podman> looks like almost 65% of my uploads are AVC1 [21:48] <podman> so, things should be fairly simple [21:48] <Compn> got any super rare codecs you cant figure out ? :) [21:48] <Compn> thats my hobby, finding old rare codecs [21:50] <podman> I have a feeling FFMPEG covers most of them, but i'll see what i've got [21:51] <Daemon404> um [21:51] <Daemon404> you cant just use capples encoders/decoders for a paid service [21:51] <Daemon404> apple's* [21:51] <Daemon404> is what i meant [21:52] <Daemon404> (paid or not actually) [21:54] <podman> Compn: here is a weird one i just noticed: "Road Pizza" ? [21:54] <Compn> i think rpza [21:54] <Compn> its normal [21:55] <podman> silly name :) [21:56] <podman> I only have a corpus of roughly 100k videos, so I'm not sure I'll have too many odd ones. [22:00] <podman> the majority of uploads seem to be h264 anyway [00:00] --- Thu Feb 28 2013