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

[burek]

[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 at 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