[FFmpeg-devel-irc] IRC log for 2010-08-09

[irc at mansr.com]

[01:09:24] <BBB> spyfeng: patches are probably ok
[01:09:32] <BBB> spyfeng: I can't review today, will do (for you) tonight (for me tomorrow morning)
[01:24:12] <Dark_Shikari> BBB: so, what happened to xvp8?
[01:24:26] <BBB> I was away for the long-weekend
[01:24:30] <BBB> so no progress
[01:27:20] <Dark_Shikari> I know
[01:27:25] <Dark_Shikari> but I mean.... when we going to start
[01:32:04] <BBB> oh yeah, I gotta find a stroller for the baby also, preferrably one that works in new york
[01:32:12] <BBB> anyone got suggestions?
[01:32:12] <BBB> (probably wrong channel ;) )
[01:32:35] * BBB wonders if urbanbaby has an IRC channel
[02:32:49] <Compn> heh
[02:32:55] <Compn> doh, where did bbb go
[03:15:18] <saintdev> hmm this actually works surprisingly well
[03:23:17] <saintdev> kshishkov: so what tradeoff do i get between the sine and kbd windows?
[04:23:43] <xxthink> where is the sws_init_swScale_C funciton
[04:23:51] <xxthink> I grep ffmpeg and can't find it
[04:29:29] <xxthink> o, it's in swscale_template
[05:08:16] <kshishkov> saintdev: sine packs energy better and KBD preserves frequencies IIRC. But the common agreement is to use sine for short windows and KBD for long ones
[05:08:59] <saintdev> well that's useful to know. that's exactly what nero does. itunes just uses sine, however.
[05:09:40] <thresh> moroning
[05:13:04] <kshishkov> well, that arrangement is mentioned in 3GPP or MPEG-4 doc, that's why I used it
[05:14:10] <saintdev> umm, you just use kbd
[05:14:36] <saintdev> or maybe it got changed, either way 3gpp just uses kbd currently
[05:14:47] <thresh> kshishkov: guess what, Moscow is in Futurama: http://www.oyaeboo.com/pic/futu1.gif
[05:15:12] <saintdev> lol
[05:18:07] <kshishkov> saintdev: hmm, indeed. Though it's possible to indicate different window type there
[05:18:17] <saintdev> yeah
[05:22:23] <cartman> moin
[05:22:40] <kshishkov> merhaba
[05:23:34] <cartman> günaydın kshishkov , iyisindir umarım
[05:26:29] <kshishkov> cartman: yesterday I've heard muhedzin for the first time
[05:26:40] <cartman> kshishkov: I have no idea what that means
[05:27:32] <kshishkov> cartman: the guy who sits on minaret and calls somebody for namaz
[05:27:41] <cartman> müezzin
[05:27:42] <cartman> you mean
[05:27:47] <kshishkov> the thing you can't see in Switzerland :)
[05:28:01] * kshishkov knows no Turkish
[05:28:23] * cartman is not exactly a Muslim
[05:28:51] <kshishkov> you like in half-Muslim environment, some things just stick
[05:29:37] <kshishkov> the only thing that bugs me - why would anyone hire him for railroad station announcer?
[05:31:14] <cartman> railroad station announcer? :)
[05:31:28] <pJok> god morgon kshishkov
[05:33:13] <kshishkov> cartman: yes, but intonation and style are left from previous work
[05:33:21] <kshishkov> god morgon, pJok
[05:33:22] <cartman> lol
[06:45:25] <xxthink> what's the scaling filter used in ffmpeg
[06:45:45] <xxthink> for example,  scale a 720x576 image to 1280x720
[06:55:50] <xxthink> ?
[07:16:14] <superdump> xxthink: -> #ffmpeg
[07:17:54] <CIA-92> ffmpeg: vitor * r24745 /trunk/libavcodec/atrac3.c: Fix handling of truncated files. Should fix random FATE breakages.
[07:37:46] <kshishkov> mru, does today Dilbert strip remind you of anything?
[07:38:55] <KotH> greetings earthlings, i come to bring peace
[07:39:22] <kshishkov> greetings KotH, please read my conversation with cartman above
[07:39:39] <cartman> moin KotH
[07:43:51] * KotH lols at kshishkov 
[07:43:57] * KotH greets cartman 
[07:44:11] <cartman> kshishkov is half Turkish now :P
[07:44:46] <kshishkov> nope, I'm 70-80% Ukrainian, the rest is Russian and Polish Jew (probably)
[07:45:45] * elenril throws http://tvtropes.org/pmwiki/pmwiki.php/Main/WeComeInPeaceShootToKill at KotH 
[07:46:29] <cartman> kshishkov: there is some rumour that I might be %1 jew too
[07:46:44] <cartman> makes my nick totally ironic :P
[07:47:20] <kshishkov> well, rumours say that certain Austrian guy was also 6-12% Jewish
[07:48:23] <KotH> elenril: i didnt say i come in peace, but to bring you peace
[07:48:28] <cartman> kshishkov: my sister believes our grand grand grand that was a Russian jew
[07:48:39] <cartman> she has some proof too
[07:48:42] <cartman> based on our surname
[07:48:53] <kshishkov> Donmezovitch?
[07:49:01] <cartman> yeah
[07:49:05] <cartman> ;)
[07:50:14] <kshishkov> whatever, it's hard to keep track of family history here
[07:50:48] <kshishkov> and since some relative was arrested in 1930s, nobody would ever mention other realtives as well
[07:52:34] <xieyi> does it mean that my ffmpeg library was compiled without video for linux support if the av_find_input_format("video4linux2") returns null?
[07:52:54] <xieyi> however the ffplay can play video captured from webcam
[07:53:38] <kshishkov> this question does not belong here, it's for #ffmpeg
[07:53:52] <xieyi> oh, sorry
[08:04:55] <KotH> hint: if you ever buy a soerkris board: dont get the standard case unless you run it stand-alone (ie no harddisk, no wireless card, no pci card)...
[08:05:16] <KotH> whoever did the mechanical design of that case did never think about its users
[08:07:46] <kshishkov> well, it's positioned for devices without those trinkets
[08:08:02] <kshishkov> (Compact Flash socket is a good hint)
[08:14:07] <KotH> kshishkov: it's just they sell the case with an opeing for a pci card, and sell together with it a hd mount kit and wireless cards
[08:14:40] <KotH> not to mention that the antennas/pigtails they sell have a connector so large, that there is literally no space for them to be mounted
[08:15:16] <kshishkov> ah, very wise indeed, encourages you to buy more
[08:15:41] <CIA-92> ffmpeg: mstorsjo * r24746 /trunk/libavformat/http.c:
[08:15:41] <CIA-92> ffmpeg: http: Return EOF at the end of the content even if the connection isn't closed
[08:15:41] <CIA-92> ffmpeg: We do request Connection: close, but some servers ignore it.
[08:15:49] <KotH> oh.. and the board comes with zero documentation
[08:16:02] <KotH> no booklet, no cd nothing
[08:16:04] <wbs> Vitor1001: when rsyncing fate samples, the new(?) files seem to have bad perms so they can't be read
[08:16:22] <KotH> all you can find is an inofficial wiki explaining a few things, written by people who asked tech support
[08:16:41] <KotH> wbs: which samples?
[08:17:00] <wbs> atrac3/mc_sich_at3_{066,105,132}_small.pcm
[08:18:35] <KotH> hmm.. permissions look ok on the server
[08:18:40] <KotH> so it must be client side
[08:18:45] <KotH> is your umask set correctly?
[08:18:50] <wbs> hmm, now it seems to work
[08:21:20] <KotH> hmm.. sounds like elenril was in your computer
[08:22:57] <KotH> salve iive
[08:23:36] <iive> hi
[08:33:00] <Vitor1001> wbs: There is a cron script that updates it
[08:33:26] <Vitor1001> wbs: Should be fine by now.
[08:33:32] <wbs> ah, that explains it
[08:33:37] <wbs> yes, it worked fine a while later :-)
[08:43:25] * elenril drops an anvil on KotH 
[08:43:51] <cartman> D:
[08:43:54] <cartman> ooops
[08:43:56] <cartman> sorry
[08:45:11] * kshishkov tries to remember anvil smiley
[08:52:49] * KotH calls O.A.D.S. for a preventive strike back
[09:35:49] <janneg> Vitor1001: atrac3 fate specs need an update
[09:36:13] <Vitor1001> janneg: It is already done, people just need to run rsync.
[09:38:50] <janneg> ok
[10:06:25] <CIA-92> ffmpeg: mstorsjo * r24747 /trunk/libavformat/ (rtpdec_mpeg4.c utils.c internal.h):
[10:06:26] <CIA-92> ffmpeg: Make hex_to_data a lavf internal function
[10:06:26] <CIA-92> ffmpeg: This is useful for other future RTP depacketizers
[10:08:42] <twnqx> hm
[10:24:19] <CIA-92> ffmpeg: mstorsjo * r24748 /trunk/libavformat/rtpenc_xiph.c: rtpenc_xiph: Don't needlessly cast pointers to integers
[10:32:50] <CIA-92> ffmpeg: mstorsjo * r24749 /trunk/libavformat/ (sdp.c rtp.h rtpenc_xiph.c): rtpenc_xiph: Set the ident value via a define
[12:41:34] <KotH> dear brothers and sisters in code, do you have me a recomendation for a book/resource to learn SQL?
[12:42:32] * cartman hides under a rock
[12:42:53] <merbzt1> KotH: the internet
[12:43:27] <KotH> ^^'
[12:43:46] <KotH> the intarwebz is full of lies, cakes and b-tards
[12:44:19] * KotH needs something well founded
[12:49:12] <lu_zero> KotH: learn exactly what?
[12:49:23] <lu_zero> which db?
[12:49:29] <lu_zero> which purpose?
[12:53:37] <KotH> create my own little db's... and i'd like to know what i'm doing instead of just copying examples from the net
[12:56:34] <kshishkov> KotH: our teacher in school recommended old FoxPro manual
[12:57:18] <KotH> sorry, i dont mean to hurt your feelings, but i dont regard .ua schools very highly
[12:57:38] <kshishkov> neither do I
[12:57:38] <lu_zero> your db as in a sql-compliant dbms?
[12:57:48] <KotH> for the moment yes
[12:58:02] <KotH> postrelational and non-relational db's are left for later :)
[12:58:20] <lu_zero> you might look at sqlite and mysql manuals
[12:58:35] <kshishkov> or postgresql
[12:58:46] <kshishkov> sqlite is the easiest to toy with though
[12:58:47] <KotH> i'm already reading the sqlite manual... but it's a bit.. dense
[12:59:42] <lu_zero> uhm
[12:59:43] <kshishkov> if you understand why it's called "relational", everything should be fine
[13:02:02] <kshishkov> I've never read any book on SQL and yet managed to create quite complex databases and queries for those
[13:04:03] <KotH> .o0(why do half of the us shops think that if someone comes from europe, that he wants the prices in GBP?)
[13:04:23] <KotH> kshishkov: well, i might not be as intelligent as you are :)
[13:04:49] <kshishkov> KotH: because the only English-speaking country there uses pounds
[13:05:18] <kshishkov> KotH: http://xkcd.com/327/
[13:06:38] <kierank> lol foxpro
[13:07:33] <kshishkov> kierank: yes, that's what we've learned at school (and what I've forgotten there as well)
[13:07:49] <KotH> kshishkov: :-)
[13:09:01] <kierank> wow foxpro still exists
[13:09:03] <kshishkov> KotH: you can try something easier, like calculating parameters of RC-circuit to replace http://xkcd.com/730/
[13:10:11] <KotH> kshishkov: eh..
[13:10:16] <KotH> kshishkov: i was just looking for that one :)
[13:10:28] <KotH> kshishkov: it's what i'm doing all day long when i'm not programming
[13:11:01] <kshishkov> yes, I also liked to draw such schematics when I was little
[13:11:26] <KotH> you see, i'm just lagging behind a few years
[13:14:58] <kshishkov> as for SQl, main idea is that all tables are just an arrays of dictionaries - each has its property (column name) but their order does not matter
[13:17:08] <kshishkov> and you can use sql SELECT output as just another table
[13:20:01] <kshishkov> oh, and the most wonderful thing is that some of trivial things - like autoincrement, date/time handling - are not defined in standard so each RDBMS invents its own way to handle it
[13:29:08] <KotH> i know how sql works in principle, i understand how relations are handled and get why it should be normalized, etc pp...
[13:29:32] <KotH> what i'm needing is exactly these small details that do not immediatly follow from the understanding of the basic theory behind it
[13:34:58] <kshishkov> no, I won't tell you how to write lavc wrapper in it
[13:35:53] <KotH> lol
[13:37:07] <cartman> SELECT * FROM pr0n;
[13:37:07] <cartman> :P
[13:38:07] <KotH> no, you're are generelizing from yourself
[13:38:21] <KotH> it should be  SELECT * FROM anime;
[13:38:23] <KotH> ;)
[13:39:13] <cartman> ln -s pr0n anime
[13:39:14] <cartman> done
[13:40:36] <kshishkov> proper command is, however, SELECT * FROM anime WHERE uploader='KotH'
[13:40:51] <kshishkov> otherwise it may select Pokemons as well
[13:42:00] <KotH> uploading is illegal in .ch
[13:42:14] <KotH> so it'll have to be SELECT * FROM anime WHERE downloader='KotH';
[13:42:34] <kshishkov> whetever, you got the idea
[13:42:36] <cartman> nothing is legal in .tr
[13:42:39] <cartman> wtf I do ;)
[13:43:46] <kshishkov> army is legal in .tr
[13:44:05] <cartman> damn right kshishkov
[13:44:11] <cartman> kshishkov known too much about .tr
[13:44:19] <cartman> he might be half Turkish indeed :P
[13:44:26] <cartman> knows*
[13:44:38] <KotH> or he was a secret agent in .tr
[13:44:47] <KotH> spying for the evil empire of .ua
[13:44:51] <cartman> might be
[13:44:53] <cartman> :D
[13:46:08] <kshishkov> knowing too much is my hobby
[13:47:04] * kshishkov has never been to Turkey and wants to keep it this way
[13:48:50] * thresh been and semi-liked
[13:51:37] <kshishkov> Russian tourist
[13:53:53] * cartman goes to debug a git bug
[13:55:36] <KotH> kshishkov: you know, that many people died because they knew too much?
[13:55:51] <CIA-92> ffmpeg: rbultje * r24750 /trunk/libavcodec/wmavoice.c:
[13:55:51] <CIA-92> ffmpeg: Fix buffer overrun if idx is negative (it can be down to -23>>4), by prepending
[13:55:51] <CIA-92> ffmpeg: two padding zeroes before it. Should fix fate failures on openBSD and crashes
[13:55:51] <CIA-92> ffmpeg: on MacOSX (that I cannot reproduce).
[13:55:59] <KotH> kshishkov: it's a very dangerouse disease... and very deadly too
[13:56:36] <kshishkov> KotH: yes, I know
[13:59:58] <cartman> why would you zip a setup.exe
[14:00:00] <cartman> its stupid
[14:00:51] <KotH> cartman: so that it passes trough stupid virus scanners
[14:01:09] <cartman> KotH: still stupid though ;>
[14:01:24] <KotH> well.. in a world, where stupid people are in the majority...
[14:01:37] <cartman> stupid people live longer
[14:01:39] <cartman> I admire them
[14:03:35] <kshishkov> stupid people live happier
[14:03:57] <cartman> like Wally
[14:04:50] <kshishkov> Wally is very intelligent, he is smart enough to avoid work. But if you look into happy upper management...
[14:04:50] <KotH> why should they live longer?
[14:05:09] <KotH> kshishkov: you dont get rich by working
[14:05:30] <KotH> kshishkov: you only get richt by letting other people work for you
[14:05:37] <KotH> s/cht/ch/
[14:06:19] <kshishkov> yes
[14:06:48] <cartman> ah need some inspiration
[14:06:54] <cartman> http://www.mopo.ca/uploaded_images/Still_Got_Payed-792851.jpg
[14:06:57] <cartman> that'll do
[14:08:56] <KotH> cartman: if you are looking for inspiration, try http://dynamic.xkcd.com/random/mobile_comic/
[14:09:44] <cartman> an rms comic showed up
[14:09:46] <cartman> I am doomed :P
[14:20:35] <twnqx> could someone apply my bitrate sanity checking patch?
[14:20:56] <iive> cartman: the angry god of freedom would hunt you down for creating drm scheme!
[14:21:18] <cartman> iive: I passed the job to someone else
[14:21:22] <cartman> thats what would wally do
[14:21:32] <iive> smart move :)
[14:21:53] <cartman> indeed ;)
[14:26:02] <KotH> cartman: do you have a WWWD bumper sticker? :)
[14:26:31] <cartman> nope :p
[14:29:27] * kshishkov remembers Dilbert animated series, in one they hypnotised Wally so he did some work
[14:29:48] <cartman> lol
[14:31:27] <kshishkov> it also featured a scene: - We need to think like Wally! *everybody falls asleep* - No, like young Wally.
[15:35:16] <BBB> can anyone ban that "maxie" guy from ffmpeg-user mailinglist?
[15:36:23] * kshishkov has banned himself from there
[15:37:12] <BBB> that's a great solution also
[15:37:46] <kshishkov> I've never regret it
[15:43:59] <kierank> kshishkov: except when you miss great troll threads
[15:44:06] <kierank> like the "i hate Dark_Shikari one"
[15:44:21] <kierank> and ffmpeg produces different colours to quicktime and thus is broken
[15:47:51] <xxthink> does PMT table always follow the PAT table in the MPEG TS stream?
[15:47:59] <kshishkov> those are not too subtle to be considered real trolling
[15:49:44] <xxthink_> does PMT table always follow the PAT table in the MPEG TS stream?
[15:51:33] <janneg> xxthink: no
[15:53:57] <xxthink> janneg: ok. I print the TS info and find that the PMT always follow the PAT table
[15:54:08] <kierank> depends on the muxer
[15:54:51] <xxthink> ok
[15:56:30] <janneg> xxthink: that's a sensible aproach for a single program mux
[15:57:15] <xxthink> ok
[17:49:11] <tetsuo--> hello, over at project mpc-hc we are working on a directshow based version of libavformat
[17:49:36] <tetsuo--> kierank pointed out that if done cleanly it could be partially upstreamed as part of the ffmpeg api
[17:50:02] <kierank> i didn't say it could be upstreamed
[17:50:20] <tetsuo--> then what did you mean?
[17:50:22] <kierank> i said you could maintain your own patches with ffmpeg svn
[17:50:26] <kierank> cleanly
[17:50:34] <kierank> instead of the messy way that ffdshow/mpc-hc do
[17:50:41] <tetsuo--> thats possible?
[17:51:08] <tetsuo--> is there already such a patch for a different project on the git?
[17:55:17] <wbs> janneg, lu_zero, BBB: regarding rtp/latm - anyone against committing the standalone depacketizer?
[17:56:27] <BBB> if you think it's better, and the latm people agree, then it's fine with me
[17:56:35] <BBB> I tried to not get involved there since I don't know latm at all ;)
[18:00:44] <Vitor1001> tetsuo--: AFAIK, patches making libavformat API easier to use are very welcome, if done cleanly.
[18:01:59] <tetsuo--> Vitor1001:  and like kierank says it will be a patch hosted somewhere  in the ffmpeg sourcetree?
[18:02:03] <tetsuo--> do you have any examples?
[18:02:19] <Vitor1001> tetsuo--: A patch hosted in ffmpeg source tree is not welcome.
[18:02:31] * tetsuo-- gets confused
[18:02:32] <tetsuo--> :D
[18:02:57] <Vitor1001> tetsuo--: But if you created new functions to the libavformat public API that might be used both to ffdshow and other clients apps, that would be welcome.
[18:04:02] <tetsuo--> for directshow the data that libavf outputs needs to be padded or renamed or something to that extent
[18:04:31] <tetsuo--> once that is done it practially works standalone
[18:05:02] <Vitor1001> tetsuo--:  I don't see how this would be useful for other applications
[18:05:34] <tetsuo--> im not sure either
[18:05:41] <peloverde> Is the way the LATM demuxer handles implicit SBR specified in the spec?
[18:05:51] <tetsuo--> but there are 2 projects (intending) to use this patched libavf
[18:05:53] <tetsuo--> mpc-hc and xbmc
[18:06:01] <Vitor1001> tetsuo--: But if you are duplicating any code from ffmpeg.c, it might be useful to factor it out to some public functions
[18:06:05] <tetsuo--> the source tree for the patched libavf is here http://git.1f0.de/gitweb?p=lavfsplitter.git;a=tree
[18:07:28] <Vitor1001> tetsuo--: Where are the patches?
[18:09:48] <tetsuo--> they are committed to that git as revisions
[18:09:53] <tetsuo--> let me try to find a representative one
[18:11:13] <tetsuo--> lol
[18:11:18] <tetsuo--> kierank:  you wont believe this
[18:11:27] <tetsuo--> the patch works on the directshow/windows side completely
[18:11:30] <tetsuo--> ffmpeg is left vanilla
[18:12:08] <peloverde> so it isn't a patch at all
[18:12:11] <peloverde> just a wrapper
[18:12:53] <Vitor1001> tetsuo--: Let's put in another way: is there any of this code that would be eventually useful to VLC?
[18:12:57] <tetsuo--> yeah, it got implemented as a wrapper to prevent hacking around in ffmpeg lol
[18:13:51] <tetsuo--> well vlc could use it, but i think it would only cause more problems in the long run
[18:14:34] <Vitor1001> tetsuo--: So it is a all-or-nothing piece of code or several small useful functions?
[18:14:36] <tetsuo--> the wrapper could be implemented as an ffmpeg api extention, it would be usefull for every open source windows based player
[18:15:07] <tetsuo--> that whole project, as it sits there on the git is a standalone demuxer for windows
[18:15:30] <tetsuo--> any windows app capable of directshow graph building could in theory use it
[18:16:04] <Vitor1001> tetsuo--: Hmm, a single demuxer could be acceptable...
[18:16:15] <peloverde> You could make analogous claims about gstreamer-ffmpeg which lives separately
[18:16:18] <tetsuo--> vlc would need a whole lot of work to be able to build a complete directshow graph
[18:16:53] <tetsuo--> but there must already be some minor directshow code to support dxva
[18:17:46] <tetsuo--> or mediafoundation code
[18:18:33] <peloverde> and there is also special code for vdpau support
[18:18:46] <tetsuo--> yeah but thats on the linux side
[18:18:52] <peloverde> so?
[18:19:07] <tetsuo--> the discussed change only affects windows
[18:19:11] <peloverde> Nothing mandatory about FFmpeg is linux specific
[18:19:30] <peloverde> just some alsa and v4l drivers
[18:19:49] <peloverde> How is this different from gstreamer-ffmpeg?
[18:21:15] <tetsuo--> i dont know, let me check the gstreamer site
[18:26:27] <tetsuo--> its not clear from the website, and the binaries are hidden in an installer
[18:27:00] <tetsuo--> but does gstreamer-ffmpeg compile to a valid .ax that register itself as a directshow filter?
[18:27:00] <peloverde> http://cgit.freedesktop.org/gstreamer/gst-ffmpeg/
[18:27:24] <peloverde> My point has nothing to do with directshow or gstreamer
[18:27:51] <peloverde> gstreamer-ffmpeg is a gstreamer wrapper for libavformat and libavcodec
[18:28:04] <peloverde> But as a wrapper it lives outside of FFmpeg
[18:28:09] <tetsuo--> obviously
[18:28:25] <tetsuo--> but the point of the wrapper we made is for it to be a standalone directshow splitter
[18:28:32] <tetsuo--> at least just the libavformat part
[18:30:22] <peloverde> So how does the wrapper living inside FFmpeg help that goal?
[18:31:57] <tetsuo--> with the existence of gstreamer it would be less interesting for other 3rd party projects
[18:32:37] <tetsuo--> maybe kierank  knows of a good reason
[18:33:01] <elenril> less wrapper projects -> greater good, no?
[18:33:07] <tetsuo--> well thats true
[18:33:19] <elenril> (-> world domination)
[18:33:30] <tetsuo--> if ffmpeg intents to be a serious about windows support, then supporting the windows codec language would be a step in that direction
[18:34:11] <tetsuo--> just being able to tell ffmpeg, output your stuff in directshow or mediafoundation mode would make the rest of the code a lot simpler
[18:34:17] <peloverde> -> if ffmpeg intents to be a serious about mac support, then supporting the mac codec language would be a step in that direction
[18:34:32] <peloverde> -> if ffmpeg intents to be a serious about gnome support, then supporting the gnome codec language would be a step in that direction
[18:35:03] <peloverde> yet perian lives elsewhere even though it is developed by a core FFmpeg developer
[18:35:14] <Vitor1001> peloverde: libavwrappers? ;)
[18:35:25] <peloverde> gstreamer-ffmpeg lives elsewhere though we have a somewhat tenuous relationship with them
[18:36:22] <pJok> tetsuo--, patch welcome
[18:37:15] <tetsuo--> pJok: i think peloverde is telling me the oposite
[18:37:44] <tetsuo--> i think both perian and gstreamer do something different from what we are doing right now
[18:38:08] <pJok> what he is saying is that if someone wants to do it and maintain the code, they are free to do so, but noone is going to do it for you
[18:38:13] <tetsuo--> our patch gives libavformat "native" access to the windows directshow api
[18:38:19] <tetsuo--> allright
[18:38:22] <Vitor1001> pJok: tetsuo--: Check with a detailed description on ffmpeg-devel before considering "patch welcome"
[18:38:42] <tetsuo--> just to be clear, we already maintain the "fork" so to speak
[18:38:56] <pJok> Vitor1001, true
[18:39:01] <tetsuo--> it might be interesting for more people, and that could warrant inclusion in the ffmpeg project itself
[18:39:16] * pJok just reads the ffdevel list to spot interesting stuff
[18:39:19] <tetsuo--> however, as it stands right now, in theory every windows developer can use it directly
[18:39:26] <tetsuo--> as hosted on our git
[18:39:31] <elenril> send a RFC, see how people react
[18:40:04] <pJok> Vitor1001, ffmpeg at least supports avisynth, which is windows only so far
[18:40:05] <tetsuo--> i asked around, and the devs tried to keep ffmpeg as vanilla as possible, thats why they wrote it as a wrapper in its current form
[18:40:11] <mru> framework wrappers do not belong in ffmpeg
[18:40:53] <elenril> what's alsa/v4l doing there then?
[18:40:55] <tetsuo--> i would think so too
[18:41:54] <tetsuo--> this is only interesting if anyone cares about libavformat speaking native directshow/mediafoundation
[18:42:39] <janneg> wbs: I'm undecided
[18:43:09] <peloverde> alsa lives in libavdevice, it is an i/o library, vfw lives there too
[18:43:55] <Vitor1001> wouldn't it qualify as a protocol?
[18:47:19] <peloverde> From what I understand the code makes a direct show filter and puts libavformat inside the filter, that doesn't seem like a protocol to me
[18:48:12] <peloverde> There is nothing wrong with this idea, infact I like it, but it doesn't seem to fall into the scope of FFmpeg
[18:48:14] <mru> alsa and v4l are not frameworks
[18:48:17] <mru> they are device interfaces
[18:48:28] <tetsuo--> peloverde: you understand correctly
[18:48:36] <peloverde> What does it do then?
[18:48:44] <tetsuo--> what you said
[18:48:45] <tetsuo--> :P
[18:48:58] <peloverde> oh, duh, sorry :)
[18:49:14] <tetsuo--> ok now that peloverde  said that, it would take a lot of patchwork to make the directshowspeak usefull outside of this wrapper
[18:49:32] <tetsuo--> people using it would also have to add all the other stuff to make it usefull in a directshow graph
[18:49:45] <tetsuo--> so you have to take ALL of it or none of it, as i see it
[18:49:52] <tetsuo--> and that doesnt make sense, so its best to leave it seperated
[18:51:55] <peloverde> All of the framework specific wrappers for FFmpeg are not useful without FFmpeg
[18:52:44] <tetsuo--> thats true
[18:54:06] <mru> nor without the franework
[18:54:37] <peloverde> Yes, I would petition Microsoft to get this included directly into Direct Show :)
[18:54:52] <mru> it's not our job to support every framework
[18:56:29] <peloverde> As an aside you are free to license your code how you wish but I think LGPL is probably a more appropriate choice for a framework wrapper
[18:57:09] <tetsuo--> i think its currently gpl3
[18:57:12] <tetsuo--> or2
[18:57:36] <peloverde> Your copying file says GPLv2+
[18:57:45] <tetsuo--> then its 2 :p
[18:58:11] <tetsuo--> the rest of the projects are gpl too
[18:58:38] <tetsuo--> i just got a chance to talk to one of the devs who wrote this wrapper, he seems to agree that it doesnt belong in ffmpeg after all
[19:01:14] <tetsuo--> the way its being coded right now, and will be distributed later will probably make it available to all windows media developers in its current form, fully usable
[19:03:14] <tetsuo--_> got disconnected
[19:06:14] <peloverde> you missed nothing
[19:06:52] <tetsuo--_> so we agree keeping this "wrapper" a seperate project, that uses a vanilla ffmpeg as its core
[19:07:00] <tetsuo--_> well just libavformat
[19:07:19] <peloverde> yes
[19:07:23] <tetsuo--_> :)
[19:07:39] <peloverde> You can even get the project added to http://ffmpeg.org/projects.html
[19:08:08] <tetsuo--_> did my message get through, about reaching millions of users?
[19:08:43] <tetsuo--_> we're already on the list under the 2 mother projects
[19:09:33] <tetsuo--_> but it might be interesting to list this seperately
[19:09:44] <tetsuo--_> as it can be considered completely standalone
[19:10:04] <tetsuo--_> it doesn't really have any dependencies from the mother projects at all
[19:22:37] <lu_zero> hi j0sh
[19:23:13] <j0sh> yo
[19:33:16] <lu_zero> any good news?
[19:34:22] <j0sh> yeah, let's talk sometime this week
[19:37:32] <tetsuo--_> hmm, i just ran into a sample that seems to fail on ffplay
[19:37:42] <tetsuo--_> http://sharebee.com/2cb3273f
[19:38:45] <tetsuo--_> heh, the first audio stream is empty, the 2nd contins a pcm track
[19:43:17] <lu_zero> =)
[19:43:21] <lu_zero> when?
[19:48:55] <j0sh> whenever works for you guys, we are on 24/7
[20:08:55] <Vitor1001> mru: why some fate boxes report 681/681 while others report 686/686?
[20:10:33] <tetsuo--_> ok that sample does work with the splitter we made
[20:14:25] <mru> Vitor1001: the BE boxes run fewer tests
[20:14:43] <Vitor1001> mru: lavfi related?
[20:14:49] <mru> yes
[20:16:45] <Vitor1001> I see
[20:17:27] <Vitor1001> mru: BTW, would you be ok now to merge fate.mak and fate2.mak?
[20:17:55] <Vitor1001> Now that Mike's agree to deprecate the original fate system?
[20:19:12] <gxben> mru, just to report a potential bug that i'm too lazy to report by list but vp8.c seems to define some vars (EDGE_TOP) in an enum that are already defined in dsputils.h (included in vp8.c) with another value
[20:19:56] <Dark_Shikari> talk to BBB
[22:05:21] <geo> ...having trouble with the drawtext command... soc -r5873 ... http://ffmpeg.pastebin.com/xSqCWstz
[22:16:32] <geo> anybody? I think this is just an invocation syntax issue...
[22:23:26] <geo> saintdev: hello
[22:23:43] <saintdev> hi
[22:23:59] <geo> ever use dratext?
[22:24:08] <geo> s/drawtext
[22:24:27] <saintdev> no
[22:25:07] <geo> seems to be "working" per internet but I cannot get invocation right
[22:25:18] <geo> http://ffmpeg.pastebin.com/xSqCWstz
[22:31:12] <Dark_Shikari> mru: so can armcc compile ffmpeg's h264 decoder?
[22:31:43] <Dark_Shikari> for that matter, is there any way to use a compiler other than gcc for compiling for ipad?
[22:37:32] <BBB> geo: this is #ffmpeg-DEVEL, not #ffmpeg-USER, please ask user questions in the appropriate channel
[22:38:05] <BBB> or actually #ffmpeg ;)
[22:47:48] <mchinen> is there a flag to specify variable frame size (FLAC) in ffmpeg? didn't see one in the man
[22:48:11] <geo> BBB: well my main problem is determining which soc commit has working drawtext and overlay in libavfilter
[22:48:45] <mchinen> oops, I should probably also ask this at user :)
[22:48:52] <geo> BBB: I'm about to bulk build all of them because I think my syntax is correct, no responce on user channel
[22:49:47] <BBB> mchinen: you're developer enough to ask here ;)
[22:50:02] <BBB> geo: if all else fails, ask on ffmpeg-users at mplayerhq.hu
[22:51:05] <J_Darnley> mchinen: Do you need set an option?  My flac files are variable frame size.
[22:52:38] <mchinen> J_Barnley: variable frame size as in different number of samples per frame, (independent of frame byte length)
[22:53:00] <J_Darnley> If that is what the property metaflac reports, then yes
[22:53:23] <J_Darnley> oh no, those are bytes
[22:54:03] <J_Darnley> Do you mean the block size?
[22:54:40] <mchinen> yes, maybe thats the right term
[22:57:16] <mchinen> Or if someone has at test file with variable block size and can give it to me that would help
[22:57:46] <Dark_Shikari> isn't all FLAC variable block size?
[22:58:21] <mchinen> Dark_Shikari: many use constant
[23:00:08] <mchinen> I'm not at home right now and in my portable collection and all ffmpeg test files all are constant block size
[23:01:37] <J_Darnley> Sorry, I don't think I've ot any
[23:01:40] <J_Darnley> *got
[23:01:50] <CIA-92> ffmpeg: aurel * r24751 /trunk/libavformat/rdt.c: get ride of MAX_STREAMS limit in RDT
[23:02:05] <CIA-92> ffmpeg: aurel * r24751 /trunk/libavformat/rdt.c: get ride of MAX_STREAMS limit in RDT
[23:02:05] <CIA-92> ffmpeg: aurel * r24752 /trunk/libavformat/ (rtsp.c rtsp.h): get ride of MAX_STREAMS limit in RTSP
[23:03:59] <Dark_Shikari> wtf
[23:04:05] <Dark_Shikari> why is gcc not turning my 15-case switch into a jump table?
[23:04:14] <Dark_Shikari> it's doing the log2-comparisons approach instead
[23:06:02] <Dark_Shikari> ugh, now it has a jump table, but in every stage of my duff's-device-like loop, it reloads everything back off the stack.  joy.
[23:11:13] <J_Darnley> mchinen: Does the flac website have test files?
[23:13:16] <mchinen> J_Barnley: closest thing seems to be cvs, and couldn't find them in test dirs.
[23:13:44] <pengvado> ffflac doesn't support varaible block size
[23:14:35] <pengvado> iirc ruggles tried it in flake, but never added it to the ffmpeg version
[23:15:07] <J_Darnley> I should try compiling that again
[23:15:24] <mchinen> pengvado: thanks
[23:15:28] <Dark_Shikari> pengvado: and yet it still beats official flac in compression?
[23:15:35] <Dark_Shikari> (do you mean encoder or decoder?)
[23:15:38] <pengvado> official flac doesn't do variable block size either
[23:15:39] <mchinen> It doesn't seem like theres an option for the official flac tool for this
[23:15:42] <Dark_Shikari> lol
[23:15:47] <pengvado> encoder
[23:17:10] <Dark_Shikari> who does do it then?
[23:17:28] <J_Darnley> oh...
[23:17:34] <J_Darnley> now I remember why I gave up!
[23:21:58] <CIA-92> ffmpeg: aurel * r24753 /trunk/libavformat/mpegts.c: get ride of MAX_STREAMS limit in mpegts
[23:22:32] <pengvado> flake
[23:23:45] <J_Darnley> If that is a question which is directed to me, yes. cmake