[FFmpeg-devel-irc] IRC log for 2010-03-31

[irc at mansr.com]

[00:11:07] <Dark_Shikari> mru: well, it seems my "readahead grep" works
[00:11:31] <Dark_Shikari> on a 12 gigabyte folder with ~1000 subfolders, each with ~1000 subfiles, with files that were written in random order and size from 0 to 30kb
[00:11:35] <Dark_Shikari> on a machine with 6gb of ram
[00:11:44] <Dark_Shikari> grepping with my grep takes about 30 minutes
[00:11:53] <Dark_Shikari> grepping with unpatched grep takes about 90 minutes
[00:12:12] <Dark_Shikari> what's the easiest way to see what filesystem the system is using?
[00:12:25] <mru> cat /proc/mtab
[00:12:30] <mru> err, /proc/mounts
[00:13:07] <Dark_Shikari> which one do I care about?  there's a lot, and "/" isn't listed
[00:13:23] <Dark_Shikari> oh nvm.  every actual filesystem runs reiserfs
[00:13:36] <Dark_Shikari> Now, that's interesting, reisefs is supposed to have awesome performance on small files.
[00:13:50] <mru> haha
[00:13:51] <mru> very funny
[00:13:56] <Dark_Shikari> what?
[00:14:06] <Dark_Shikari> that was one of the selling points of reiserfs
[00:14:11] <mru> selling, yes
[00:14:15] <Dark_Shikari> much better performance on tons of small files than, say, ext2
[00:14:18] <mru> did anyone ever say it delievered?
[00:14:20] <Dark_Shikari> it did
[00:14:26] <Dark_Shikari> all the benchmarks I saw, it crushed ext*
[00:14:28] <Dark_Shikari> which isn't _hard_
[00:14:38] <Dark_Shikari> since, at least at the time, ext* sucked horrifically on small files
[00:14:49] <mru> most of those benchmarks were done on ext* w/o b-tree dirs
[00:14:58] <mru> and that _really_ sucked
[00:15:33] <Dark_Shikari> when were those added?
[00:15:39] <mru> many years ago
[00:15:46] <mru> but after reiserfs gained traction
[00:16:31] <mfg> I want to add something to ffplay that prints the chapter metadata whenever a new chapter is reached (to demonstrate the shoutcast chapters stuff).  Is this something people would want added to ffplay, and if so, in what way?  I have it logging the into out (after making dump_metadata public), but the way we write the current pos to stdout and then flush makes it look bad. Any thoughts?
[00:16:31] <Dark_Shikari> http://www.gurulabs.com/archive/ext3-reiserfs/
[00:16:34] <Dark_Shikari> interesting
[00:16:40] <Dark_Shikari> it's heavily filesize dependent
[00:16:51] <mru> reiserfs has the tail packing thing too
[00:16:51] <Dark_Shikari> just adjusting the params on postmark can make ext3 or reiser win by large margins
[00:17:14] <mru> tail packing is good for space but bad for performance
[00:17:31] <Dark_Shikari> they find that on small files, ordered journaling in ext3 suuuuuuuuuucks
[00:17:44] <Dark_Shikari> http://www.gurulabs.com/archive/ext3-reiserfs/page5.html
[00:17:54] <Dark_Shikari> (that's the test reiser wins on)
[00:18:06] <Dark_Shikari> also, by using reiserfs, you can make jokes about partitioning wives
[00:18:23] <hyc> ugh
[00:18:39] <mfg> booo
[00:18:40] <hyc> I still use reiserfs for most of my machines
[00:18:50] <mru> I never used it on my machines
[00:18:56] <hyc> hey, anyone have time to comment on my seek patch? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/086166.html
[00:18:59] <mru> I don't trust people like him
[00:19:09] <mru> even if they're not murderers
[00:19:14] <hyc> I trust ext4 even less
[00:19:39] <hyc> I used to use xfs for everything
[00:19:43] <mru> ext4 is just a knee-jerk we-need-an-extN-with-extents design
[00:19:46] <hyc> but it seems to only be good for large files
[00:19:53] <mru> xfs is wonderful for large files
[00:20:04] <mru> and it's not too shabby with small ones either
[00:20:15] <mfg> does it still have that grub problem?
[00:20:16] <Dark_Shikari> btfs!
[00:20:18] <Dark_Shikari> *btrfs
[00:20:25] <mru> but beware of how the large files are written
[00:20:27] <Dark_Shikari> it sounds like a dairy product so it must be good
[00:20:34] <hyc> lol
[00:20:52] <mru> if you mmap a large, empty file and write to it in random order, it gets horribly fragmented and very slow
[00:21:00] <mru> like bittorrent tends to do
[00:21:07] <mru> if you pre-allocate the space it's fine
[00:22:04] <Dark_Shikari> utorrent preallocates space for that reason
[00:22:25] <mru> rtorrent does it with special xfs calls that don't actually write anything
[00:22:29] <mru> at least with my patch :-)
[00:22:33] <Dark_Shikari> lol
[00:22:35] <Dark_Shikari> utorrent does it nearly instantly
[00:22:39] <Dark_Shikari> so I suspect it does something similar
[00:22:46] <Dark_Shikari> it also supports sparse files in NTFS, but that's off by default
[00:22:52] <Dark_Shikari> because it's worse for somewhat obvious reasons
[00:26:29] <hyc> also, anyone familiar with the flv demux? why does it "start" a frame at the last 4 bytes of the previous frame?
[00:26:42] <hyc> why doesn't it start at the actual start of the frame?
[00:42:27] <CIA-1> ffmpeg: michael * r22739 /trunk/doc/ffmpeg-doc.texi: Better documentation of -vsync
[00:42:59] <hyc> don't all speak up at once now ... ;)
[00:45:09] <peloverde> hyc, Michael is the flv maintainer
[00:45:24] <peloverde> so you probably are best of sending an e-mail to ffm-devel
[00:45:33] <hyc> peloverde: thanks
[00:45:47] <hyc> I already have 2 emails outstanding there
[00:45:54] <hyc> guess I'll just have to wait
[00:46:25] <astrange> rtorrent's ui freezes for very long times on os x if it has to create a new blank file, i never checked what it was doing
[00:46:59] <hyc> rtorrent has a nasty habit of re-checksumming files even when they were just created
[00:50:20] <mru> I never noticed that
[00:52:45] <hyc> hm, are we talking about the same rtorrent? there are two
[00:53:00] <mru> I've only used one
[00:53:05] <mru> an ncurses thing
[00:53:14] <hyc> rakshasa?
[00:53:20] <mru> ?
[00:53:37] <hyc> libtorrent.rakshasa.no
[00:53:56] <hyc> http://libtorrent.rakshasa.no/wiki
[00:54:06] <mru> yes, apparently
[00:54:17] <hyc> maybe it's been fixed in later versions
[00:54:28] <hyc> I haven't actually torrented anything since I started working on rtmp
[00:55:09] <hyc> hmm. I don't see how stream->index_entries gets populated
[00:55:22] <hyc> where does that happen?
[00:56:18] <hyc> oh, I got it
[00:56:22] <hyc> av_add_index_entry
[00:56:34] <drv> there are two libtorrent, i think - only one rtorrent
[00:57:33] <bcoudurier> hi guys
[01:03:56] <Kovensky> hi bcoudurier's onjoin
[01:20:14] <hyc> [aac @ 0x1348a10]Transition from an ONLY_LONG or LONG_STOP to an EIGHT_SHORT sequence detected. If you heard an audible artifact, please submit the sample to the FFmpeg developers.
[01:20:32] <hyc> got this message while seeking around in an flv
[01:21:24] <hyc> I'm guessing that this can be ignored in this situation...
[01:21:37] <mru> yes, probably
[01:22:04] <peloverde> hyc, If you are seeking then that message makes perfect sense
[01:22:54] <peloverde> In AAC basicaly there are two window types short and long. but you need a special transitional window to switch between them without artifacts
[01:23:26] <hyc> peloverde: thanks
[01:23:49] <peloverde> Any artifact should only last one frame (1024 samples)
[01:24:08] <hyc> hm, ATRAC and MP3 have short and long frames too, but I don't recall them having such artifacts
[01:25:44] <peloverde> MPEG does specify a normative way to switch without the transition (which I guess should help reduce artifacts)
[01:26:04] <peloverde> That section of the code was written by one of the previous FFmpeg AAC authors
[01:26:27] <peloverde> possibly superdump (Rob)
[01:26:34] <hyc> also, the sole reason to switch to short frames was to catch transients, sharp attacks
[01:27:09] <hyc> I'd guess most times you wouldn't know the difference between a glitch and the actual transient ;)
[01:27:12] <peloverde> indeed but the encoder should look ahead and plan the transition one frame in advance
[01:29:47] <peloverde> What is proper downmix behavior these days? I saw a bug quickly open then close
[02:27:39] <bcoudurier> astrange, I only answered to you by mistake
[02:27:50] <bcoudurier> I'm off bye guys
[02:27:54] <astrange> oh, i didn't notice
[02:27:58] <bcoudurier> I meant only to you, not the list
[02:28:02] <astrange> btw mkv does have dts
[02:28:10] <bcoudurier> huh ?
[02:28:16] <astrange> import all pts for a block, sort in ascending order, there's dts
[02:28:30] <bcoudurier> hum
[02:28:36] <bcoudurier> like -2 ?
[02:28:43] <bcoudurier> if pts is 0 and tb is 24
[02:28:58] <astrange> i'm not sure it always works but i think that's what you're supposed to do
[02:29:04] <bcoudurier> you can't
[02:29:06] <bcoudurier> you need delay
[02:29:10] <bcoudurier> for mp4 at least
[02:29:20] <bcoudurier> ctts is -2 for b pyramid
[02:29:52] <bcoudurier> worst case is when it is activated
[02:29:58] <bcoudurier> but the usage only appears in the middle of the file
[02:29:58] <astrange> yuvi's demuxer in perian creates mov with dts from mkv and works in all practical situations
[02:30:08] <astrange> i never compared it against a direct encode-to-mp4 though
[02:30:49] <bcoudurier> well michael fixed it in most cases by honoring the value in sps
[02:30:59] <bcoudurier> but if the value is missing
[02:31:02] <bcoudurier> you have to compute it
[02:31:34] <bcoudurier> I guess you don't have the problem with most mkv files since they are created with x264 ;)
[02:31:46] <Dark_Shikari> most mkv files are created with mkvmerge
[02:32:00] <bcoudurier> encoded with
[02:32:03] <Dark_Shikari> oh
[02:32:21] <bcoudurier> my files aren't created by x264 at all
[02:32:35] <Dark_Shikari> what's the particular issue?
[02:32:41] <bcoudurier> value in sps
[02:32:47] <Dark_Shikari> sps_id?
[02:32:49] <bcoudurier> dpb delay
[02:32:51] <Dark_Shikari> ah
[02:32:53] <Dark_Shikari> what is it set to?
[02:32:56] <Dark_Shikari> or is it not set?
[02:32:58] <bcoudurier> no value
[02:33:04] <Dark_Shikari> Yes, this is a problem with the h264 spec
[02:33:12] <Dark_Shikari> the only solution is to be willing to make the decoder wait a frame or two later
[02:33:17] <Dark_Shikari> if you run over the guessed value
[02:33:23] <bcoudurier> yes
[02:33:48] <bcoudurier> or you use max delay, 16
[02:34:00] <bcoudurier> that's painful though
[02:34:12] <bcoudurier> anyway I'm off
[02:34:14] <bcoudurier> see you guys
[02:44:41] <Kovensky> [flv @ 0xbe9d20]Estimating duration from bitrate, this may be inaccurate <-- what about the 'duration' metadata header?
[02:52:00] <hyc> Kovensky: yeah, that always bothered me too
[02:52:23] <hyc> but looking at the actual code, it doesn't seem to matter
[02:57:11] <hyc> the cause is the av_has_duration() function
[02:57:25] <hyc> it looks for a duration in each individual stream (audio or video)
[02:57:50] <hyc> and it ignores whatever duration is recorded by the container (which is where the metadata duration got stored)
[02:58:44] <hyc> the comment in av_has_duration is "Returns TRUE if the stream has accurate duration in any stream."
[02:58:51] <hyc> what is "accurate"? how accurate?
[03:16:24] <ramiro> how do I tar cfvj some/long/path, but when I extract the file it outputs to "path" instead of "some/long/path"?
[03:25:44] <ramiro> got it: tar cfvj x.tar.bz2 -C some/long path
[03:38:18] <BMintern> hi, i'm in the process of writing a fade filter for libavfilter. the problem is that i don't know a whole lot about working with yuv/rgb formats. i feel like if i was fading in the rgb space i would scale each color down to 0. working in the yuv space, however, all i've come up with is scaling y down to 0. obviously this is going to have 2 separate effects. which would be correct?
[03:40:39] <Dark_Shikari> y to 0, u to 128, v to 128
[03:41:44] <BMintern> thank you
[03:42:34] <relaxed> BMintern: did you ever get that overlay working?
[03:42:59] <BMintern> yes, the "problem" was that i was using a 16-bit png instead of an 8-bit one
[03:43:08] <BMintern> converting the png to 8-bit fixed the problem
[03:43:16] <BMintern> probably a bug that ffmpeg can't handle 16-bit pngs?
[03:53:51] <Dark_Shikari> more likely a missing feature
[03:56:18] <Compn> Dark_Shikari : michael wants you to report bugs instead of just complaining about them :P
[03:56:21] <Compn> ehe
[03:56:36] <Compn> i reported a bunch of bugs about unsupported image formats and some poor soul implemented all of them
[03:56:47] <Compn> poor kostya :D
[04:01:42] <BMintern> thanks Dark_Shikari, that was perfect
[04:02:05] <BMintern> i was stupid initially and didn't realize that the value was in the range [255, 0], but i figured it out
[04:02:50] <BMintern> i'm happy to announce that i just finished a simple fade filter for libavfilter, i'll be sending a patch to ffmpeg-soc
[04:08:42] <relaxed> BMintern: port yadif next :)
[04:09:18] <BMintern> this will be my first ever code contribution to open source. i'm pretty satisfied with what i've done so far :)
[04:10:02] <relaxed> yeah, that's great.
[04:10:35] <hyc> he's on the road to a lifetime addiction :P
[04:11:13] <Dark_Shikari> welcome to the club
[04:12:04] <BMintern> well i have some (poorly-) paid work that i'm doing to process videos automatically, and i was like, "wtf, ffmpeg doesn't have fade?"
[04:12:20] <BMintern> after i saw the "how to create your own filter" documentation, it looked like something i could do
[05:13:57] <av500> the real dodo: http://www.bbc.co.uk/blogs/radiolabs/2009/10/realmedia_an_update.shtml
[05:32:50] <astrange> should 'ffmpeg -i x -vpre veryslow -vcodec libx264' work? it doesn't
[05:32:55] <astrange> vpre has to go after vcodec
[05:34:56] <Dark_Shikari> astrange: is there an easy way to make it work?
[05:36:24] <astrange> store the preset string and only read presets right before opening the encoder
[05:36:44] <Dark_Shikari> would work
[05:37:21] <astrange> hmm if you did -vpre x -vpre y and they didn't set all the same options behavior would change slightly
[06:28:09] <wbs> hyc: had time to look at the patches I sent to the rtmpdump list?
[06:28:26] <hyc> wbs: which ones?
[06:28:53] <wbs> I sent 4 separate patchds on march 28
[06:29:08] <hyc> hmm. don't remember them, lemme check the archives
[06:29:08] <wbs> three of them are quite trivial, the fourth perhaps needs discussion
[06:31:35] <hyc> strange, I never got them. reading the archive now.
[06:32:44] <wbs> weird, perhaps some spamfilter doesn't like me
[06:33:10] <hyc> possible I guess
[06:33:18] <hyc> ok, makefile patch, ok.
[06:33:29] <hyc> you forgot DESTDIR on INCDIR but I'll fix that
[06:34:09] <hyc> duh, destdir is already there, never mind
[06:34:21] <KotH> salut
[06:34:28] <kshishkov> shalom
[06:34:34] <merbzt> priviet
[06:34:41] <kshishkov> hej (:
[06:34:44] <pJok> buenos noches
[06:35:26] <hyc> hmm, you really think we need to check for the pkgconfig directory to exist?
[06:35:31] <hyc> seems odd, but whatever...
[06:35:32] <pJok> i hate this alternative route from kävlinge to malmö
[06:35:45] <pJok> no cell signal
[06:36:07] <wbs> hyc: yes, in my case, I choose to install to a completely nonexistant directory, e.g. /home/foobar/localstuff/rtmpdump
[06:36:18] <hyc> right ok
[06:37:52] <hyc> seektime/stoptime log - oops. left over from when they were doubles.
[06:38:37] <wbs> yeah, one wouldn't expect a crash due to that one :-)
[06:38:39] <kshishkov> pJok: here cell signal is not always present on major routes
[06:40:38] <pJok> this is at least not a major route
[06:41:08] <kshishkov> and "cell signal booster" is something not heard of completely
[06:41:08] <pJok> its used by freight trains normally to go around lund
[06:41:45] <hyc> wbs: hmm, I thought I just copied this command sequencing from the ffmpeg rtmpproto.c
[06:41:56] <hyc> and I thought folks had already tested that against wowza
[06:42:15] <wbs> the one i rtmpproto.c worked, yes, I haven't compared them
[06:42:28] <hyc> frankly it made no sense to me. since this is at the initial connection, there should not be any streams existing yet
[06:42:29] <av500> kshishkov: see, they even have freight trains with cell coverage :)
[06:42:44] <wbs> but doing first createstream, then removestream, perhaps isn't sensible
[06:42:46] <pJok> hehe
[06:43:11] <pJok> av500, the new standard for rail signalling actually uses gsm-r ;)
[06:43:13] <wbs> but the problem at least seems to be that we're waiting for a reply to the createstream, and if sending removestream, fcpublish, createstream all at once, we just ge a reply to the first one
[06:43:51] <wbs> perhaps they should be chained so that only one is sent at a time, waiting for the reply to that and then proceeding with the next one
[06:43:53] <hyc> wbs: I understand. but that's a server bug
[06:44:12] <kshishkov> av500: I suspect that even their freight trains are more comfortable than ours
[06:44:15] <hyc> normal flash clients and servers pipeline multiple messages at once. (Adobe)
[06:44:54] <hyc> anyway, this makes no sense. ffmpeg rtmpproto.c also sends all 3 messages at once.
[06:45:35] <hyc> oh, crap. in rtmpproto.c "hack for Wowza, it does not send result for release and publish calls"
[06:46:05] <hyc> sounds to me like that comment is slightly incorrect then
[06:46:14] <hyc> every invoke is tagged with a command counter
[06:46:30] <kshishkov> and its maintainer was lazy and has not added keeping server version to allow better hacks
[06:46:52] <hyc> and every result is tagged with the same number, so that results can be associated to their requests.
[06:47:33] <hyc> so if in fact it is hanging waiting for a reply to CreateStream, which would be request #3 here, then that means woza sent a reply to #1 or #2
[06:49:33] <hyc> ah, except now I see that rtmpproto is sending them with hardcoded command numbers
[06:49:44] <hyc> grumble...
[06:52:13] <hyc> I guess I need to see a real Adobe client publishing to a real Adobe server
[06:52:26] <hyc> this sequence of events looks all wrong
[06:53:02] <hyc> (it works against rtmplite, but rtmplite only cares about the FCpublish and createstream
[06:53:12] <hyc> it doesn't have a handler for releasestream)
[06:53:45] <wbs> ok.. I don't have any such server to test with, unfortunately, but you should be able to use e.g. oflademo from red5 as client - that'd use adobe's routines for these things from within flash, right?
[06:55:14] <hyc> dunno will look around
[07:04:31] <kshishkov> I think you can always ask red5 devs for cooperation
[07:08:14] <hyc> I guess. found this http://osflash.org/pipermail/red5commits_osflash.org/2007-March/001343.html they implemented these but they're no-ops
[07:09:45] <wbs> hyc: sure that this is a wowza bug and not an intended protocol feature, btw? i.e., the server is allowed to only send a result to the last invoke, if it doesn't have anything else to say about the previous invokes
[07:10:35] <kshishkov> could be gray area
[07:12:43] <kshishkov> maybe transaction IDs are the same?
[07:14:14] <hyc> no, I increment a counter on every invoke, they're all unique
[07:14:19] <hyc> found this
[07:14:30] <hyc> http://whispercast.org/trac/browser/trunk/whisperstreamlib/rtmp/rtmp_protocol.cc
[07:14:42] <hyc> looks like FCPublish gets no reply on success
[07:14:43] <kshishkov> official crap says each call should be responded
[07:20:20] <wbs> hyc: what about this one, then? http://albin.abo.fi/~mstorsjo/check-txn.patch
[07:23:41] <hyc> heh, no that won't do
[07:24:02] <wbs> why not?
[07:24:12] <hyc> AV_erase can be called for other reasons, so the list will not have a predictable number of entries
[07:25:02] <hyc> are you assuming that getting one reply means all previous txns are resolved?
[07:25:10] <hyc> I don't think that's valid
[07:25:44] <wbs> ok, but the current code, doing methodInvoked = methodCalls[0] without checking which transaction actually was responded to, is that valid?
[07:26:41] <wbs> shouldn't you then keep track of which transaction number each item in methodCalls had, and find the matching one?
[07:26:47] <hyc> good question. this used to fail all the time in 1.x
[07:29:22] <hyc> ah, some "results" come back with a txn of zero, regardless of the original request number
[07:29:42] <hyc> that's why e.g. the __pnbwdone handler has to search for the request to erase
[07:29:47] <hyc> __onbwdone
[07:29:58] <kshishkov> __pwndone?
[07:30:04] <hyc> typo
[07:30:16] <hyc> this whole protocol sucks
[07:30:25] <kshishkov> I know
[07:30:38] <kshishkov> at least they made extra-sucky versions too
[07:30:38] <hyc> took me days to figure out why onbwdone was corrupting the result queue...
[07:31:58] <hyc> and look at play and publish - their "result" isn't a result message at all, it's an onStatus message
[07:32:59] <wbs> hyc: that patch I showed above should at least handle that, if the transaction id is 0, we don't remove any method calls. the removing of skipped calls should perhaps be moved to within _result, though
[07:34:12] <hyc> anyway, your patch won't fix the hang, since we're looking for an actual result that corresponds to the createStream request
[07:34:22] <hyc> just erasing all the queued requests won't fix that
[07:34:51] <wbs> no, that was just misunderstanding the code earlier
[07:35:19] <wbs> I thought the server reply was for releasestream, but that was only the librtmp code _assuming_ the reply belonged to that invoke, through methodCalls[0]
[07:35:46] <hyc> right
[07:35:54] <wbs> the patch I showd does fix the hang, I actually do check my patches before I submit them
[07:36:10] <wbs> I also valgrinded it to see that I didn't do anything else stupid
[07:36:33] <hyc> but I don't want to poke and prod at the code until I know what is actually supposed to happen on the wire
[07:36:52] <hyc> if releaseStream is normally a non-replied request, we can account for that without any other hacks
[07:38:33] <wbs> yes, that seems to be the case, releaseStream and FCPublish aren't replied at all - if I comment out the SendCreateStream, I get no reply at all
[07:39:14] <hyc> ok, then just change SendReleaseStream
[07:39:22] <hyc> when it invokes RTMP_SendPacket
[07:39:25] <hyc> change true to false
[07:39:33] <hyc> and it won't go into the result queue
[07:39:44] <hyc> do the same for SendFCPublish
[07:39:47] <hyc> and it should all be fine
[07:40:50] <wbs> ok, that's one solution, but the whole mess of just guessing which transaction was replied is giving me bad vibes - if the server CLEARLY says that "this is a reply to your transaction #4", then there should not need to be any guessing about which method the reply belongs to
[07:41:08] <hyc> yes, true
[07:41:17] * kshishkov thinks that his approach when client just cared for the first few invokes and mostly ignored results for the latter is not a very bad thing
[07:41:36] <hyc> lol
[07:42:16] <hyc> wbs: but you have to see some packet traces to realize
[07:42:30] <hyc> more results come back with 0 / invalid txn ID than not
[07:42:56] <wbs> yes, but if the txn ID is set, then I think that should be believed to be true at least?
[07:43:21] <hyc> wbs: it doesn't gain anything
[07:43:32] <hyc> if you get replies out of order, you're still hosed.
[07:44:02] <wbs> yes, but it would gain you not needing to know whether releasestream and fcpublish are replied normally or not
[07:44:17] <wbs> but anyway, I'll just fix it by assuming that they're not replied
[07:44:36] <wbs> which is fine for me but perhaps breaks things for someone else
[07:45:04] <hyc> which is why I'm googling to see what Adobe really expects here
[07:46:00] <kshishkov> wireshark is your best friend then
[07:48:28] <wbs> hyc: http://albin.abo.fi/~mstorsjo/no-reply-releasestream-fcpublish.patch works for me, too
[07:49:29] <hyc> ok
[07:49:39] <hyc> that's probably what I'll commit
[07:49:45] <hyc> going to keep digging for a little while...
[08:02:51] <hyc> I'm not convinced those requests are even necessary...
[08:03:10] <hyc> most example source code I see only does createStream then publish
[08:03:15] <hyc> no FCpublish
[08:03:30] <hyc> no releaseStream
[08:06:06] <wbs> hyc: that works for me, too
[08:12:55] <hyc> http://www.rtmpd.com/browser/trunk/sources/thelib/src/protocols/rtmp/basertmpappprotocolhandler.cpp
[08:13:10] <hyc> FCPublish gets an onStatus response, not a _result
[08:13:38] <hyc> releaseStream might get a result
[08:13:41] <hyc> sigh
[08:13:49] <wbs> with my version of wowza, it doesn't get on onStatus response either
[08:15:55] <hyc> I'm going to drop the releaseStream request
[08:16:07] <hyc> it appears to only be needed if there was already an active stream
[08:24:57] <hyc> wireshark transcripts http://forum.telestream.net/forum/messageview.aspx?catid=45&threadid=4178&enterthread=y
[08:25:03] <hyc> too bad they're only of wowza
[08:44:44] <CIA-1> ffmpeg: astrange * r22740 /trunk/libavcodec/h264.c:
[08:44:44] <CIA-1> ffmpeg: H264: Copy h264dsp when creating new slice threads
[08:44:44] <CIA-1> ffmpeg: Fixes slice multithreading (broken in r22565)
[08:44:44] <CIA-1> ffmpeg: Fixes issue1815
[08:47:44] <av500> peloverde: [aac @ 0x8b9a1b0]Transition from an ONLY_LONG or LONG_STOP to an EIGHT_SHORT sequence detected. If you heard an audible artifact, please submit the sample to the FFmpeg developers.
[08:48:49] <astrange> did you seek?
[08:48:53] <peloverde> That warning raises three default questions:
[08:48:59] <peloverde> a) Did you seek?
[08:49:17] <peloverde> b) was it on the first frame (that's a false positive that needs to be cleaned up)
[08:49:27] <peloverde> and c) was there an audible artifact?
[08:50:24] <av500> al03_48.mp4
[08:50:28] <av500> no seek
[08:50:47] <av500> no on 1st frame, after 1s or so
[08:50:56] <peloverde> Ahh al03_48.mp4
[08:50:59] <av500> :)
[08:51:22] <peloverde> the al03* series was created to test this very condition
[08:52:33] <peloverde> This transition is both illegal and has a normative behavior that isn't throwing up your hands and walking away (yes i know that sounds like an oxymoron)
[08:53:04] <peloverde> So technically al03* isn't actually AAC because it contains forbidden syntax ;)
[08:53:10] <av500> ok, I understand
[08:53:20] <av500> I thought all these streams are supposed to decode ok
[08:53:37] <peloverde> That stream is the exception
[08:53:54] <av500> I picked it randomly :)
[08:54:03] <peloverde> Also PNS streams have a special conformance tool and can't be compared by normal means
[08:54:07] <hyc> damn, av500 is lucky
[08:54:22] <KotH> av500: you should play lotto :)
[08:54:22] <hyc> quick, pick 6 numbers between 1 and 57 for me
[08:55:31] <av500> KotH: if I write al03_48.mp4 on the lotto thingy, u think I win?
[08:56:00] <peloverde> I really should add a field to my fancy table <http://wiki.multimedia.cx/index.php?title=AAC_Conformance_Vectors> for that
[08:56:01] <KotH> who knows... but it's worth a try
[08:56:27] <peloverde> But I still think maybe it's time to just implement that windowing condition properly
[08:56:37] <peloverde> I really don't think the overhead should be that significant
[08:57:14] <hyc> and that "please submit a sample" message clearly needs to be extended: "unless you were seeking when this message occurred, or unless this was the very start of a stream, or unless you're playing a bogus stream, or your nick is av500"
[08:57:41] <Dark_Shikari> lol
[08:57:47] <peloverde> Also all the AAC streams from the MPEG4 file format conformance suite are basically broken too
[08:58:38] <peloverde> They all signal AOT-1 rather than AOT
[08:59:30] <peloverde> They also are inconsistent with the spec wrt header formats :/
[08:59:52] <Dark_Shikari> :/
[09:00:09] <Dark_Shikari> on an unrelated note, some good news.  apparently google wants to pay to have the gpl h264 decoding asm relicensed
[09:00:27] <KotH> of ffmpeg?
[09:00:40] <KotH> interesting
[09:00:41] <merbzt> Dark_Shikari: to lgpl ?
[09:00:46] <av500> bsd?
[09:01:03] <astrange> apparently?
[09:01:11] <Dark_Shikari> yes
[09:01:12] <Dark_Shikari> lgpl
[09:01:12] <av500> or the GooglePublicLicence?
[09:01:37] <Dark_Shikari> astrange: apparently as in "fbarchard emailed me about it, following up a previous discussion"
[09:03:11] <peloverde> Dark_Shikari, They are looking for a scaler
[09:03:27] <peloverde> be sure to let them know that libswscale is for sale
[09:03:35] <Dark_Shikari> I thought vso already paid?
[09:04:09] <merbzt> lets sell it twice
[09:04:13] <Dark_Shikari> lol
[09:04:28] <peloverde> I could have sworn that the x86 asm was still GPL
[09:04:37] <merbzt> we can just change the license back to gpl
[09:04:39] <Dark_Shikari> well, it's in the process of being fixed
[09:04:42] <Dark_Shikari> due to the payment of $20k
[09:04:58] <merbzt> peloverde: one file is still not lgpl
[09:05:01] <av500> merbzt: cron job?
[09:05:16] <thresh> :)
[09:05:32] <av500> 4) profit!
[09:05:33] <merbzt> av500: something like that yeah
[09:06:35] <astrange> does swscale have enough documentation for people to get the details of yuv colorspaces right?
[09:06:55] <av500> so patches get discussed, applied, paid and relicenced?
[09:07:08] <peloverde> So who owns the last file?
[09:07:25] <merbzt> peloverde: some asian semiconductor company
[09:07:32] <peloverde> ahhh
[09:07:36] <merbzt> dead end
[09:07:47] <merbzt> so it's getting rewritten
[09:08:44] <peloverde> ahh, who is working on that?
[09:09:09] <merbzt> I think we had 3 possible candidates
[09:20:48] <kshishkov> astrange: we have, I can write you a quick spec what to reimplement
[09:21:58] <kshishkov> for example, I've tried to rewrite that x86 yuv2rgb but it's not that easy for me with GCC inline asm
[09:23:29] <CIA-1> ffmpeg: cehoyos * r22741 /trunk/libavformat/asf.c:
[09:23:29] <CIA-1> ffmpeg: Remove superfluous space from a conversion table.
[09:23:29] <CIA-1> ffmpeg: Patch by Anton Khirnov, wyskas gmail
[09:24:35] <astrange> i meant "does it tell you how to map AVColorSpace to an sws context setting"
[09:25:07] <astrange> looks like no, none of the SWS_CS_* are used except SWS_CS_DEFAULT (601)
[09:25:16] <kshishkov> peloverde: thanks for your state-of-ffaacenc mail, it's fun to read
[09:25:32] <av500> peloverde: al_sbr_cm_48_[4|5].mp4, what is the expected channel ordering?
[09:26:18] <peloverde> The channel ordering may be wrong, it fails my test harness due to an ordering mismatch
[09:26:22] * bilboed-pi hugs people for updating APIchanges :)
[09:26:34] <peloverde> superdump redid the channel ordering most recently
[09:27:18] <av500> I have not tried yet, I was just wondering
[09:27:45] <astrange> so it handles AVColorRange because that overlaps with pixel formats, but not really AVColorSpace and not really AVChromaLocation
[09:27:54] <peloverde> The channel ordering issue is honestly something I haven't paid enough attention to
[09:28:28] <merbzt> IIRC the channel order is correct now
[09:28:36] <merbzt> or consistent
[09:28:44] <peloverde> I figure that's an area where people seem to have strong enough opinions that they will fix it themselves
[09:29:38] <av500> I see some 5.1 AAC streams return  actx->channel_layout = 0x3F, but others return 0x00...
[09:30:12] <av500> 0x3F and the WAVEFORMAT defines ordering makes sense to me
[09:30:17] <av500> defined
[09:30:26] <peloverde> PCE based vs non-PCE based?
[09:30:56] <av500> probably, I looked into aac.c and found a place where it sets the layout to 0
[09:31:13] <av500> so, if it 0x00, the decoder cannot tell?
[09:31:20] <peloverde> For PCE based configurations we get stuck with this weird annex in 13818-7 that seems difficult to map onto sane channel orderings/spatial configurations
[09:32:16] <peloverde> The PCE is the 3rd biggest flaw of the AAC bitstream format IMHO
[09:32:32] <Dark_Shikari> 3rd?
[09:32:35] <Dark_Shikari> what are 1st and 2nd?
[09:32:48] <peloverde> #1) Implicit PS
[09:33:01] <peloverde> you can always find implicit SBR on the first frame
[09:33:18] <peloverde> you can't find implicit PS until SBR processing actually gets turned on
[09:33:37] <peloverde> So your channel count may spontaneously increase mid-decode
[09:33:59] <Dark_Shikari> lol
[09:34:14] <peloverde> #2) http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=7c9d74801ae7281b2a880806d9e7a3bb544c3bf3
[09:34:53] <Dark_Shikari> lol
[09:34:53] <kshishkov> maybe it would be better to hide 5.1 DTS inside stereo AAC instead
[09:34:54] <peloverde> Zero sized codebook sections are both legal and create havoc
[09:37:54] <peloverde> The PCE code should probably sniff if the arbitrary channel order matches something sane
[09:38:57] <merbzt> peloverde: how depressed do you get when you work on aac ?
[09:39:08] <av500> peloverde: ok, but e.g. al_sbr_cm_48_4.mp4, is it FL/FR and BL/BR?
[09:39:26] <av500> or FL/FR and CTR and LFE?
[09:40:24] <kshishkov> merbzt: try amr-nb spec, it's quite depressing as well
[09:41:30] <peloverde> It's supposed to be deciphered according to this chart as far as I can tell: http://www.iec.ch/cgi-bin/getcorr.pl/yab/iso/isoiec13818-7-cor1%7Bed1.0%7Den.pdf?file=iso/isoiec13818-7-cor1%7Bed1.0%7Den.pdf
[09:41:33] <peloverde> Annex G
[09:43:00] <merbzt> atrac3 had a juvel in the bitstream syntax also
[09:43:12] <peloverde> The actual PCE tells you: front, side, back or LFE
[09:43:28] <peloverde> As far as I can tell no other information id provided
[09:43:38] <merbzt> first we say how many subbands we have
[09:44:02] <merbzt> then we can override that number later in the bitstream
[09:44:35] <peloverde> (err Annex H, not G, the picture in the Cor)
[09:45:02] <av500> I see the picture
[09:45:04] <av500> :)
[09:45:35] <av500> but that is an "example" for 22.2 channels, no?
[09:46:33] * av500 larts MP4 for giving him a channel count of 0...
[09:46:44] <peloverde> See the first paragraph on the first page
[09:47:01] <peloverde> Also according to the PCE all those channels are front
[09:47:28] <peloverde> Everything except the LFE is tagged front on that stream
[09:49:46] <peloverde> al07* tags one channel pair back
[09:50:11] <peloverde> Though I think al07* was finally removed from conformance
[09:50:45] <peloverde> I'm sorry, I'm thinking of al15*
[09:50:49] <peloverde> al07* is ok
[09:51:17] <av500> peloverde: thx for the insights, but I doubt I will go at great length there. my users will prolly have stereo and 5.1 only :)
[09:52:24] <peloverde> They might have some mono
[09:52:42] <merbzt> av500: is channel_layout a nice field for you ?
[09:54:12] <peloverde> I would say that PCEs don't see much use int he wild for channel configurations that can otherwise be specified but I was proven wrong on aac-main yesterday
[09:54:19] <av500> peloverde: yes, but mono is most trivial to support :)
[09:54:49] <av500> merbzt: it would be if the number of bits set inside it would match the channel count
[09:55:06] <merbzt> it should
[09:55:16] <merbzt> if not then the decoder is borked
[09:55:26] <av500> as I said, for some aac, ch=6 and layout=0 :(
[09:55:46] <av500> but I am OK if =0 means "i dont know"
[09:56:11] <peloverde> It is a bit of a "I don't know"
[09:56:25] <av500> like "I don't"?
[09:56:35] * kshishkov remembers theoretical MoosePack parser which should do almost everything decoder does except actual synthesis
[09:57:03] <peloverde> This "file doesn't know because the PCE is a piece of crap"
[09:58:37] * av500 files that under "i dont know"
[09:59:16] <peloverde> The PCE really seems to have opened a door to add certain reconfiguration features that they never added
[10:03:49] <peloverde> How does your previous AAC decoder handle such files?
[10:27:25] <av500> peloverde: no idea
[10:28:50] <av500> peloverde: btw, the al_sbr_cm_48_[1|2|4|5] samples return a good channel layout, only 5.1 is 0
[10:32:36] <peloverde> av500, That makes sense, only the 5.1 file uses a PCE
[10:32:42] <av500> ok
[10:33:49] <peloverde> Also thanks for reminding me how much I hate the PCE :)
[10:35:22] <superdump> av500 , peloverde : if there are channel ordering issues, it's probably because the spec's definitions of channel orders are confusing
[10:35:29] <superdump> the maps can easily be changed
[10:35:33] <superdump> i did the best i could :)
[10:35:38] <peloverde> You did well with it
[10:35:42] <peloverde> the PCE is a mess
[10:35:44] <av500> superdump: no, actually it looks ok to me
[10:35:58] <superdump> but one of you said that there was a conformance issue due to channel ordering
[10:36:06] <superdump> is that with a layout = 0 case?
[10:36:37] <peloverde> There are two issues, I never updated my conformance scripts for the channel order fixes
[10:36:44] <superdump> oh
[10:37:12] <peloverde> And PCE based configs spit out actx->channel_layout = 0x00
[10:37:16] <superdump> bilboed-pi: yeah, stefano is good with that :)
[10:37:46] <superdump> well, maybe we could do some kind of layout matching thing for PCEs...?
[10:37:53] <peloverde> I was thinking about that
[10:37:55] <superdump> or maybe that would just add to the nightmare :)
[10:38:12] <peloverde> Then i wondered how often the PCE is used for common layouts in the wild?
[10:38:31] <peloverde> Most of the use case of the PCE is that the layout is strange and uncommon
[10:38:40] <superdump> well, the ideal usecase
[10:39:14] <superdump> but i would be interested to see if there are actually strange/uncommmon layouts for which the pce is used properly
[10:39:29] <superdump> maybe a pce is used because people are confused by the specified channel layouts
[10:39:41] <peloverde> All the 48 channel files use the PCE
[10:39:47] <superdump> maybe it's used because it's there and so people think it should be used
[10:39:52] <superdump> well, they have to don't they?
[10:40:02] <peloverde> indeed
[10:40:02] <av500> peloverde: 48 ch files in the wild? :)
[10:40:07] <superdump> if they want any kind of specified layout
[10:40:28] <superdump> i don't recall precisely, but only up to 8 channels have channel configs, right?
[10:40:37] <superdump> the rest are not defined
[10:40:41] <peloverde> indeed: 1,2,3,4,5,5.1, and 7.1
[10:40:46] <peloverde> IIRC nero, ct, and quicktime/itunes don't generate PCEs
[10:40:52] <superdump> good
[10:41:06] <av500> I bet they refuse to encode 48 channels as well
[10:41:14] <peloverde> probably :)
[10:41:29] <superdump> but that probably means that <weird encoder here> does <weird pce stuff>
[10:41:35] <peloverde> At some point I need to do an encoder feature matrix
[10:41:52] <superdump> i intend to read your ffaac summary now
[10:41:54] <superdump> i'm intrigued
[10:42:00] <av500> superdump: for me it is not an issue to treat layout=0 as "I dont know, assume something"
[10:42:04] <superdump> it is something i would really like to improve so we can ditch faac
[10:42:13] <superdump> but i have no time
[10:42:17] <superdump> i'm knackered as it is
[10:42:27] <superdump> av500: ok :)
[10:42:51] <superdump> av500: then i guess it's as good as it can be right now if the ones with layouts are mapped correctly for you
[10:43:06] <superdump> well, short of best matching for pce layouts
[10:43:08] <peloverde> superdump, Also some of the 5.1 conformance files request 5 front channels
[10:43:11] <peloverde> :)
[10:43:16] <superdump> om...
[10:43:21] <av500> peloverde: which ones?
[10:43:22] * superdump head in hands
[10:43:30] <av500> m)
[10:43:56] <peloverde> al15*
[10:44:12] <peloverde> al_sbr_cm_48_5.1
[10:45:20] <peloverde> al15* I believe is the stream that was removed from the conformance suite most recently (for a different reason)
[10:45:40] <peloverde> I would try something on mp4-tech for al_sbr_cm_48_5.1 but no one seems to care anymore :(
[10:45:58] <peloverde> maybe we need to get moving on the usac bandwagon asap?
[10:46:07] <CIA-1> ffmpeg: cehoyos * r22742 /trunk/libavformat/utils.c:
[10:46:07] <CIA-1> ffmpeg: Probe aac codecs for CODEC_ID_PROBE.
[10:46:07] <CIA-1> ffmpeg: Patch by Joakim Plate, elupus ecce se
[10:46:36] <superdump> ok, adding flexibility may be nice, but making things stupidly complicated for decoders to do correctly is not nice
[10:47:01] <superdump> remind me, what is usac?
[10:48:16] <superdump> "causing the FAAC method
[10:48:18] <superdump> to shit the bed."
[10:48:20] <superdump> rofl
[10:48:22] <superdump> :)
[10:48:40] <superdump> peloverde: i'd like to meet you and buy you a drink someday
[10:48:58] <superdump> i have no idea when i'll swing by ohio though
[10:49:14] <superdump> NY and CO, yes
[10:49:24] <superdump> OH... not so much
[10:50:19] <superdump> why is "it's what the reference encoder uses" a con?
[10:50:23] <superdump> if it works well...
[10:52:48] <superdump> peloverde: ideally i would say implement the ones that are useful for speed/quality tradeoff and make them selectable
[10:53:11] <superdump> that is, if an algorithm is both slower and worse quality than something else, don't implement it
[10:56:52] <superdump> it would be quite shiny to have a FOSS implementation of an AAC encoder beat the shit out of all other AAC encoders, as x264 does for h.264
[10:59:21] <pJok> wouldn't that require people actually start tackling ffaac rather than just talk about how bad it is? ;)
[11:00:24] <superdump> yes
[11:00:25] <siretart> superdump: FYI, related link: http://www.omgubuntu.co.uk/2010/03/aac-codec-to-be-removed-from-ubuntu.html
[11:00:31] <superdump> it would
[11:00:42] <superdump> it would need someone with the time and interest to work on it
[11:00:43] <peloverde> USAC is Unified Speech and Audio Coding
[11:01:08] <peloverde> It's basically CELP + AAC + Arithmetic coding pushed together into a nice little package
[11:01:53] <peloverde> I've managed to distract myself from it with paid gigs on decoder parts
[11:02:43] <peloverde> Dark_Shikari thinks he can ind a big pile of money but I question how far I can take it on my own
[11:03:22] <superdump> is it used in the wild for anything?
[11:03:39] <peloverde> It's still under development
[11:03:43] <superdump> siretart: mmm, it'd be nice if canonical took an interest and funded its development
[11:03:45] <peloverde> It should be very close to being done
[11:03:51] <superdump> peloverde: then why is it interesting?
[11:04:11] <superdump> munging CELP into AAC... urgh
[11:04:14] <superdump> i know it's in the spec
[11:04:15] <superdump> but urgh
[11:04:41] <peloverde> superdump, It's interesting because the players are still engaged
[11:04:53] <peloverde> So when I find these nasty inconsistencies they may still be fixable
[11:04:59] <superdump> i see
[11:05:12] <superdump> interesting from a spec reviewers perspective
[11:05:43] <peloverde> It basically seems to be the Subpart 4 do over 10 years later
[11:05:55] <peloverde> I have to head out, adios guys
[11:12:41] <superdump> t'ra peloverde
[11:21:41] <twnqx> wow, even strange codecs like vp6f work
[11:21:46] <twnqx> <3 ffmpeg
[11:44:41] <av500> lol http://marc.info/?l=openbsd-ports&m=126805847322995&w=2
[11:46:37] <nfl> hi how is an rtp depacketizer for a static payload format different from that of dynamic ones?
[11:47:03] <merbzt> the former is more easy to implement
[11:48:22] <CIA-1> ffmpeg: benoit * r22743 / (trunk trunk/tools): Add .version and graph2dot to ignore list.
[11:48:30] <wbs> i guess the (de)packetization can be as easy/hard, but with dynamic payloads, there can be more configuration through sdp parameters
[11:55:42] <twnqx> are there plans for a dts encoder?
[11:56:51] <merbzt> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#DTS_Encoder
[11:56:57] <merbzt> we have code for it already
[11:57:01] <merbzt> in the soc repo
[11:57:58] <merbzt> twnqx: good enough answer ?
[11:58:45] <twnqx> yes :]
[11:58:56] <twnqx> thanks a lot, looking forward to it
[12:04:32] <superdump> it might not be any good though if it doesn't get tuned
[12:09:44] <merbzt> superdump the party pooper
[12:09:52] <merbzt> it's gonna be awesome
[12:11:02] <mru> http://news.ycombinator.com/item?id=1231454
[12:11:13] <mru> everybody upvote
[12:11:16] <mru> autoconf bashing
[12:11:51] * thresh thinks it's more of a *bsd people bashing
[12:11:54] <pross-au> what about qmake bashing?
[12:13:11] <mru> thresh: the enemy of my enemy is my friend
[12:13:14] <mru> at least on facebook
[12:15:00] <merbzt> on what ?
[12:16:48] <pross-au> Seems to be more about the 'Linux versus Irrelevant Operating Systems' crusade, rather then autoconf specifically
[12:18:17] <mru> he has a point
[12:18:30] <mru> checking for versions when you should be checking a feature is wrong
[12:21:26] <pross-au> we're talking GNU features though
[12:22:04] <mru> not really
[12:28:50] <nfl> i'm really sorry, the electricity went out
[12:28:56] <nfl> wbs: you were sayin?
[12:29:06] <mru> did you catch it?
[12:29:17] <mru> runaway electricity can be dangerous
[12:29:27] <nfl> under control now ;)
[12:29:30] <wbs> nfl: didn't say anything else than what you probably saw, if you saw me say anything at all :-)
[12:29:42] <nfl> ok
[12:29:54] <pross-au> Hehe. No more free solaris
[12:30:03] <wbs> that is, the only difference that I know about, is that static payloads have fixed payload id:s, while dynamic ones are taken from a pool >= 96 and configured through sdp lines
[12:30:11] <pross-au> "I feel sorry for the person that this affects" ... :D
[12:30:26] <wbs> and therefore, the dynamic ones probably can be configured much more flexibly
[12:30:54] <CIA-1> ffmpeg: cehoyos * r22744 /trunk/ (52 files in 5 dirs):
[12:30:54] <CIA-1> ffmpeg: Replace all occurences of PKT_FLAG_KEY with AV_PKT_FLAG_KEY.
[12:30:54] <CIA-1> ffmpeg: Patch by Jean-Daniel Dupas, devlists shadowlab org
[12:31:45] <merbzt> nfl: is this real ? http://www.bombay-connection.com/en_GB/site/page/1/releases
[12:33:19] <nfl> merbzt: dunno sorry
[12:34:05] <merbzt> nfl: where you even born then ? :)
[12:37:11] <nfl> merbzt: no actually ;)
[12:38:08] <nfl> dont chide me but am not much into music anyway :)
[12:43:36] <mru> http://news.ycombinator.com/item?id=1230890
[12:43:50] * mru likes the first comment
[12:44:58] <kshishkov> maybe some company will buffer for few more years before it notices one of the clients is gone
[12:45:08] <nfl> lol
[12:45:33] <av500> they have clients buffered
[12:47:24] <nfl> i see that rtpdec_h263.c doesn't define parse_sdp_a_line. does this have anything to do with its payload type being static?
[12:47:48] <wbs> nope, there are no fmtp parameters to parse out for h263
[12:48:07] <wbs> h263 nowadays do use a dynamic payload (where it has a different format than in the deprecated static payload format)
[12:48:37] <nfl> hmm
[12:56:10] <CIA-1> ffmpeg: michael * r22745 /trunk/libavformat/ (options.c utils.c avformat.h): Add AVFMT_FLAG_NOFILLIN and AVFMT_FLAG_NOPARSE.
[13:25:59] <av500> is there any 7.1 sample in mplayer samples?
[13:26:12] <mru> probably
[13:29:05] <av500> dts has some
[13:29:57] <twnqx> pcm might have some too :P
[13:30:21] <twnqx> dunno if those .m2ts were ever added to the samples collection, though
[13:30:29] <mru> http://rainwarrior.thenoos.net/music/moon8.html
[13:30:52] <av500> is that in 7.1? :)
[13:31:03] <mru> yeah, the 8-channel NES
[13:31:16] <mru> one bit per channel...
[13:34:18] <kshishkov> you've typed ~176 bits in this channel
[13:34:26] <kshishkov> and that's just last line
[13:35:08] <mru> http://www.youtube.com/watch?v=ZaR4fsUeTVY
[13:36:16] <nfl> is a static payload depacketizer also supposed to define an RTPDynamicProtocolHandler? or is there some other method?
[13:41:51] <nfl> anybody there? or is just that stupid questions dont get answered? ;)
[13:42:07] <kshishkov> repeat again, BBB should know the answer
[13:42:26] <BBB> huh?
[13:42:31] <nfl> here goes: is a static payload depacketizer also supposed to define an RTPDynamicProtocolHandler? or is there some other method?
[13:42:48] <BBB> uhm...
[13:42:50] * BBB goes think
[13:42:52] <BBB> I think so
[13:43:09] <BBB> lu_zero and luca abeni (no IRC) would know
[13:43:25] <nfl> ok
[13:44:19] <BBB> the name of the "dynamic" handler should be the same one as in AVRtpPayloadTypes in rtp.c
[13:44:47] <nfl> hmm
[13:47:57] <jai> read the source
[13:48:17] <av500> cool, bits_per_raw_sample is "set by libavcodec", except when it is not..... /sigh
[13:53:54] <mru> btw, someone's giving indians a bad name on the gsoc-mentors list...
[13:54:14] <KotH> how?
[13:54:25] <kshishkov> maybe it's indians themselves and somebody just carries that along
[13:57:40] <kshishkov> you're quite lucky that foreign language classes in ex-USSR taught mostly to hate English, otherwise you'll get another batch of people not comprehending what you say
[14:01:24] <jai> :|
[14:06:00] <KotH> kshishkov: they do that still?
[14:07:16] <thresh> they did not at least 10 years ago
[14:07:35] <thresh> though i attended nice schools
[14:08:09] * KotH knows that there was a time, when you could end up in jail, if you studied english
[14:10:17] <av500> of course, image somebody writes instruction on how to build *the bomb* in that language!
[14:11:46] <peloverde> I wish that rule applied to my high school english teachers
[14:11:47] <BBB> wbs: hah, you're just early, I wanted to ask you to co-mentor already ;)
[14:12:35] <wbs> BBB: :-) blame merbzt ;-)
[14:12:54] <BBB> do you want to do it?
[14:12:54] <KotH> peloverde: lol
[14:13:13] <BBB> it's fun stuff, and then I can focus on mms/speech codecs
[14:13:18] <BBB> (amrwb, for example)
[14:13:52] <merbzt> BBB: I'm ahead of you already
[14:13:56] <merbzt> by 5 minutes
[14:14:18] <wbs> BBB: given a good project and good student, sure. :-)
[14:14:27] <BBB> one of those online forums I used to visit has a really suitable smiley that would fit here
[14:14:40] <CIA-1> ffmpeg: cehoyos * r22746 /trunk/libavcodec/h264enc.c: Fix likely typo in r15937.
[14:15:49] <CIA-1> ffmpeg: jai_menon * r22747 /trunk/doc/ffmpeg-doc.texi: Fix a few typos/grammar nits from r22739.
[14:16:17] <BBB> http://gathering.tweakers.net/global/smileys/worshippy.gif
[14:16:18] <BBB> that one
[14:16:25] <BBB> or http://gathering.tweakers.net/global/smileys/pompom.gif
[14:16:36] <jai> also
[14:16:38] <jai> http://ffmpeg.pastebin.com/N9AByizu
[14:17:00] <jai> ^ problem with the post commit hook
[14:17:03] <wbs> oh boy do I love filling forms where I'm not allowed to type my name properly ;P
[14:17:35] <mru> you should anglify your name
[14:17:46] <merbzt> hahah, you got the same problem as andoma
[14:17:58] <wbs> yep
[14:18:06] <mru> I've learned to live with it
[14:18:32] <wbs> i mostly try with the native form first, but i'm quite used to just doing ö->o
[14:18:35] <mru> to the point that the 7-bit version _is_ my official name in some places
[14:18:44] <wbs> oh, that's an accomplishment :-)
[14:20:04] <merbzt> my work collegue was in the Philippines last year, his name Thunström got translated to Thunderstorm
[14:20:12] <mru> nice
[14:20:27] <merbzt> yeah, awesome
[14:20:52] <wbs> living with a swedish name in finland isn't all that awesome all the time either - the finns don't find it that easy to write just given the name verbally
[14:29:27] <kshishkov> wbr: try writing or at least properly pronouncing my name - in Russian or Ukrainian edition
[14:30:05] <av500> "kshishkov" :)
[14:30:31] <kshishkov> no (and it would be Polish version :)
[14:30:52] <kshishkov> ask mru if he can remember it
[14:31:31] <merbzt> K. Sergeiovich S.
[14:31:53] <kshishkov> ies, that too
[14:32:07] <av500> К. Шишкоъ
[14:32:36] <kshishkov> that's Bulgarian ;)
[14:32:43] <av500> К. Шишкоь
[14:32:51] <kshishkov> mine ends with "в"
[14:33:10] <av500> it was supposed to be serbian, but my cyrillic is beyond rusty
[14:33:24] <av500> but u are right, sorry:
[14:33:30] <av500> К. Шишков
[14:35:34] <kshishkov> and guess why I'm mostly known as Kostya instead of correct "Konstantin"
[14:35:51] <av500> ☭. ☹♜☂♱♦⚒
[14:36:13] <kshishkov> first symbol seems correct
[14:36:50] <av500> so google translator did well :)
[14:38:45] <thresh> yeah, everyone fails to spell my name too
[14:39:35] <kshishkov> there are still Chinese and Indians
[14:39:49] <Compn> kshishkov : probably 'kostya' from ffmpeg commit nick ? :)
[14:40:33] <kshishkov> Compn: good guess, now figure how I got that one in first place
[14:41:02] <kshishkov> also meaning of Indian name "Kumar" in slang Russian usually corresponds to its bearer
[14:49:12] <merbzt> jai: have you gotten your social-security number yet ?
[14:49:38] <merbzt> the news has hit swedish press now
[14:49:49] <jai> merbzt: the one about studera?
[14:50:05] <mru> what news?
[14:50:09] * mru missed something
[14:50:17] <kshishkov> merbzt: for the record I got mine even before going to university. Not that it gives any security (especially social)
[14:50:46] <merbzt> no, there is a 10 year old Indian project of giving each citizen over 15 years of age a "social security" number
[14:51:21] <jai> merbzt: oh, everyone assumed that was vaporware :)
[14:51:38] <merbzt> it's not
[14:51:52] <merbzt> it has hit swedish press
[14:51:54] <kshishkov> I'd rather call it KLZ anyway
[14:51:55] <merbzt> must be true then
[14:52:26] <nfl> i've posted the depacketizer to the soc-ml. please take a look
[14:52:42] <jai> merbzt: the project is being handled by one of the local sweatshops here
[14:54:43] <merbzt> in sweden we get ours by birth
[14:55:21] <merbzt> jai: hows the application process going ?
[14:55:25] <kshishkov> we get ours sometime after internal passports. In tax offices as you do
[14:55:27] <jai> merbzt: oh, its over :)
[14:55:45] <merbzt> jai: yeah but did you get accepted ?
[14:56:05] <jai> merbzt: yeah, i'll be working with the comparch group at uwisc
[14:56:44] <jai> btw, http://www.uidaicards.com/, for the coding scheme
[14:57:16] <merbzt> the UK ?? I thought you where going to join the ranks of proud ffmpeg-swe devs
[14:57:34] <jai> merbzt: they haven't processed my application yet :(
[14:57:38] <jai> merbzt: chalmers that is
[14:57:51] <jai> merbzt: and s/UK/US :)
[14:58:07] <merbzt> omg
[14:58:18] <kshishkov> merbzt: for the record, UK is subsidiary of Sweden. At least in FFmpeg development sense
[14:58:25] <merbzt> but think about the timezones
[14:58:35] <merbzt> kshishkov: true true
[14:58:40] <jai> merbzt: i know, sucks bigtime :(
[14:58:42] <av500> he can talk to peloverde and Dark_Shikari all day long
[14:58:53] <merbzt> but think about the children
[14:59:06] <merbzt> the children
[14:59:09] <av500> merbzt: that is what prevents me going there!
[14:59:16] <merbzt> :)
[14:59:18] <kshishkov> merbzt: also I've heard thatt Johan III was king of Scotland as well
[14:59:22] <jai> i'd much rather prefer chalmers, but apparently they get spammed by asian applicants each year, which kinda works against us :/
[14:59:53] <merbzt> jai: coz we don't charge for education ...
[15:00:01] <kshishkov> jai: local universities are spammed by both asian and african applicants
[15:00:47] <jai> merbzt: also, the place is awesome :)
[15:01:03] <merbzt> indeed
[15:01:54] <merbzt> everyday I go to work and I have to jump of the buss 2 stops before my regular stop because of the traffic I think of the awesomeness
[15:02:39] <kshishkov> at least it goes
[15:02:53] <av500> ok, understood, actx->bits_per_raw_sample is useless, it is av_get_bits_per_sample_format(actx->sample_fmt) that counts...
[15:04:14] <jai> merbzt: i thought swedes prefer cycling :)
[15:04:24] <merbzt> my bike got stolen
[15:04:28] <kshishkov> jai: not if you compare them to Danes
[15:04:34] <merbzt> and there still is icey outside
[15:04:47] <merbzt> need to buy  a new one
[15:05:14] <kshishkov> and don't forget that Christopher Polhem invented a thing for you
[15:05:27] <av500> merbzt: http://www.wendmag.com/blog/wp-content/uploads/ice-bike.jpg
[15:05:28] <jai> av500: not really useless, if the container stores such information we could always remux it back
[15:05:44] <av500> jai: right
[15:05:59] <merbzt> nice helmet
[15:07:28] <thresh> it is a moto helmet
[15:07:55] <av500> then u need this I guess: http://www.iceroadracing.net/galleryfrench2/images/athiebault1.jpg
[15:10:36] <kshishkov> merbzt: it should be better in three years for you - http://sl.se/templates/Page.aspx?id=8795
[15:11:00] <mru> kshishkov: never trust SL
[15:11:10] <merbzt> kshishkov: thank you for the comforting words :)
[15:11:46] <kshishkov> mru: why?
[15:12:10] <mru> they lie to you
[15:12:48] <kshishkov> do they close lines forever without any forewarning?
[15:13:21] <av500> with ppl still inside?
[15:14:21] <kshishkov> av500: if you think that somebody _cares_ about people here you need you optimism deflated
[15:14:37] <jai> lolwut
[15:15:20] <kshishkov> mru: while I was enjoying SL transport in April they managed to close one of the most important tram lines here
[15:15:37] <mru> to understand SL you must understand how the money flows
[15:15:53] <kshishkov> and it took only a few months to prepare a replacement bus for a wee part of the removed route
[15:16:06] <mru> the county council takes tax money and pays private companies to run the trains and buses
[15:16:14] <av500> 4) profit
[15:16:32] <mru> the lowest bidder gets the contract
[15:17:05] <kshishkov> yes, that's why you got MTR instead of Veolia for Tunnelbanan
[15:17:05] <mru> the contractors only care about following the letter of the contract to ensure they get paid
[15:17:29] <mru> around here veolia transports rubbish
[15:17:42] <av500> here they transport people :)
[15:17:43] <merbzt> no more veolia
[15:17:50] <kshishkov> around here it's all rubbish
[15:17:54] <mru> av500: is there a difference where you live?
[15:18:11] * av500 is offended
[15:18:20] <mru> I didn't mean it like that
[15:18:29] * mru rephrases
[15:18:30] * kshishkov used a Veolia bus from Helsingfors Central to Vanda Airport
[15:18:41] <mru> av500: are you lucky enough to live in a place where there's a difference?
[15:18:58] * av500 thinks so
[15:19:20] <kshishkov> mru: ask merbzt about "marshrutka"
[15:19:32] <mru> anyway, one of the SL rules states no more than 5% (iirc) of trains may be delayed, or the contractor has to pay fines
[15:19:47] <mru> another rule states that any delay less than 5 minutes is considered on time
[15:19:57] <mru> guess how much delay all trains have
[15:20:09] <kshishkov> 5 mins
[15:20:13] <mru> correct
[15:20:31] <mru> a certain number of cancelled trains are also allowed
[15:20:39] <mru> guess how many they cancel every day
[15:20:44] <av500> as much as allowed
[15:20:47] <mru> exactly
[15:20:51] <kshishkov> here trains have delays from5 to 70 mins
[15:21:31] <mru> when a train is delayed by more than 5 minutes, they'll cancel it, delay it for another 10 minutes and pretend it's the next one
[15:21:39] <mru> if they have cancel slots remaining
[15:21:43] <av500> lol
[15:21:45] <jai> lulz
[15:22:09] <mru> I'm not making this up
[15:22:24] <kshishkov> and how it's in comparison to British transport?
[15:22:39] <mru> probably not much difference
[15:22:45] <mru> I rarely use public transport
[15:22:59] <mru> there's one good thing about southampton: taxis are practically free
[15:23:05] <kshishkov> you should come here to understand you live in wonderful world
[15:23:15] <mru> you can go anywhere in the city for £5 or so
[15:23:27] <mru> split between 3 or 4 people that's less than a bus fare
[15:23:39] <mru> assuming there is a bus in the first place
[15:23:42] <jai> 3-4 people fit in a single taxi?
[15:24:06] <benoit-> jai: why wouldn't they ?
[15:24:06] <kshishkov> yes, it has 4 seats IIRC
[15:24:10] <mru> a normal taxi can take 4 passengers
[15:24:40] <mru> if at least 3 of them are reasonably slim at least
[15:24:48] <jai> ah, i guess taxis here are a bit smaller then...
[15:24:59] <mru> probably cheaper too
[15:25:04] <jai> of course
[15:25:09] <jai> welcome to the third world :)
[15:25:16] <mru> depends on your income though
[15:25:33] <mru> I gather the income gap in india is huge
[15:25:35] <kshishkov> jai: I'm already there
[15:25:44] <jai> kshishkov: so i've heard ;)
[15:25:57] <jai> mru: yeah
[15:31:15] <kshishkov> Compn: considering you mail to mplayer-dev-eng. The best approach is to replace them all with lavc native decoders
[15:35:25] <kshishkov> I suspect we need FFmpeg Enterprise^W Developers Edition specially for testing new features and loading binary codecs
[16:17:49] <mru> now daring fireball found my ogg article
[16:18:03] <mru> only took him a month...
[16:18:04] <kshishkov> better late than never
[16:19:29] <av500> he could not see through the flames I guess
[16:31:48] <pJok> mru, but ogg is the best container in the universe!!!111[/trollmode]
[16:32:06] <av500> not our universe
[16:32:17] <av500> but there are others
[16:32:24] <kshishkov> then you don't live in xiphverse
[16:32:46] <pJok> who cares about xiph anyways?
[16:34:09] <kshishkov> RMS, I think
[16:34:22] <pJok> but who cares about RMS?
[16:34:39] <kierank> fsf
[16:34:56] <pJok> this is ffmpeg... who cares about RMS? ;)
[16:35:09] <av500> kshishkov: no way, he uses an all free laptop and the only audio/video he can decode on it is txt and libaa
[16:35:29] <jai> yep, gNuisance
[16:35:39] <pJok> hmm
[16:35:47] <pJok> shouldn't ffmpeg have libcaca support? ;)
[16:35:59] <kshishkov> av500: free laptop as "RMS free" or as "free beer"
[16:36:17] <kshishkov> pJok: I think we'll get it soon
[16:36:18] <jai> pJok: hook up ffplay to libvo :)
[16:37:09] <av500> kshishkov: RMS free
[16:37:21] <av500> bios in source code
[16:37:50] <kshishkov> based on Sparc as the only CPU with open VHDL too?
[16:38:01] * elenril thinks opensource bios is a great idea
[16:38:06] * elenril kicks his broken bios
[16:38:17] <kshishkov> we have some of those
[16:38:30] * kshishkov prefers firmware to bios though
[16:38:36] <kshishkov> or at least a monitor
[16:38:40] <elenril> coreboot doesn't work on laptops
[16:38:45] <av500> kshishkov: it is actually something you might know: Loongson 2F CPU, 797-900MGHz
[16:38:46] <pJok> kshishkov, but you need propriotary software to make the logic mesh in the fpga
[16:38:56] <av500> Lemote YeeLoong 8101B 10"
[16:39:09] <mru> eeew
[16:39:11] <av500> maybe it does decode theora though
[16:39:15] <mru> elenril: have you tried seabios?
[16:39:25] <kshishkov> av500: I have Gdium, almost the same stuff
[16:39:26] <av500> mru: no, (fr)eeeew
[16:39:40] <av500> kshishkov: hence my remark :)
[16:40:26] <mru> I heard the lemote machines not only used a weird cpu, they also used a crappy northbridge/pci-controller not quite compatible with the cpu
[16:40:51] <av500> mru: no read: "The unique programmable Northbridge provides space for customization; the operation and application of free operating system could adopt a free open-source software (FOSS), which is a powerful software package management mechanism that provides the most convenient methods for users' customization and development demands to exempt from getting into the trouble of software copyright."
[16:40:53] <av500> :)
[16:41:29] <av500> who care if it does not match the CPU when you can have this
[16:41:43] <elenril> mru: no
[16:42:07] <elenril> when i last asked in #coreboot, they told me it won't work on most laptops
[16:42:17] <elenril> and recovery would be very hard
[16:42:36] <mru> the bios is something that runs for a few seconds a few times a year
[16:42:41] <mru> I don't really care much about it
[16:42:45] <kshishkov> mru: Gdium crap (SiS 501) is no better
[16:42:57] <mru> kshishkov: that's the remarkable thing
[16:43:00] <mru> it _is_ better
[16:43:06] <kshishkov> yuck!
[16:43:28] <elenril> well my bios practically can't boot from an usb disk
[16:43:38] <mru> that sucks if you need it
[16:43:41] <kshishkov> also don't say such things about bios in presence of DOS programmers
[16:43:56] <mru> they have only themselves to blame
[16:44:07] <pJok> the only advantage of dos is the boottime
[16:44:38] <mru> linux boots pretty damn fast with init=/bin/sh
[16:44:51] <mru> and that's already much more than dos ever provides
[16:44:58] <av500> why boot?
[16:45:21] <kshishkov> mru, you can replace bios with linux kernel too
[16:45:39] <mru> not quite
[16:45:44] <mru> you still need something to configure ram etc
[16:45:56] <av500> kshishkov: sound better than DOS approach to replace kernel with BIOS :)
[16:46:45] <kshishkov> s/replace kernel/make OS around BIOS with somecrap.sys/
[16:47:10] <mru> the idea of the bios wasn't entirely without merit at the time
[16:47:18] <mru> unfortunately they botched the implementation
[16:48:52] <kshishkov> well, making PC out of 8088 with cheesy CP/M clone was a botched idea
[16:50:34] <kshishkov> why couldn't they do something like Acorn machine?
[16:52:13] <jai> ^ freenode failure
[16:52:51] <kshishkov> nah, quite good for blackmailing
[17:04:04] <BBB> kshishkov: wanna help with a math problem?
[17:05:05] <BBB> kshishkov: http://ffmpeg.pastebin.com/QVzT46cn there's two pieces of code, I'd expect them to do the same but they don't - why not?
[17:08:50] * BBB is confused
[17:12:46] * kshishkov looks for function sources
[17:15:35] <kshishkov> BBB: looks like celp_filterf sets first value before actual filtering and tilt does that after filtering
[17:16:03] <BBB> should be done before
[17:16:12] * BBB sent his interpretation of the postfilter to the list
[17:18:08] <kshishkov> oh, the order!
[17:18:32] <kshishkov> celp_filterf is ascending
[17:18:37] <kshishkov> and tilt is descending
[17:18:58] <kshishkov> so in tilting it uses _untouched_ samples during compensation
[17:19:34] <kshishkov> and in celp_filterf it updates in[n-1] = out[n-1] before calculating out[n] from it
[17:23:53] <BBB> I see
[17:24:17] * BBB guesses that's a bug in the code then
[17:24:22] <kshishkov> I really suggest you take VoxWare MetaS...
[17:24:28] <BBB> ?
[17:24:31] <BBB> the dll?
[17:24:37] <BBB> I'm lazy, I'd like to do video
[17:24:40] <kshishkov> the codec
[17:24:52] <BBB> I'll do it some other time :)
[17:24:54] <kshishkov> ok, WVP2 will wait for you too
[17:25:12] <BBB> I doubt it, you guys are on it fast
[17:25:28] <kshishkov> "you guys"?
[17:25:34] <BBB> you, that soc student :)
[17:26:36] <kshishkov> I remember only three successful REs for GSoC - WMAPro, MLP and RV4
[17:26:57] <kshishkov> so you have better chances it's audio codec that will be REd, not video ;)
[17:28:13] <BMintern> has anyone here worked on libavfilter? i already got a fade filter working, but now i'm having trouble getting a concatenate filter to register
[17:28:19] <BMintern> http://ffmpeg.pastebin.com/iCub2y4Z
[17:29:10] <BMintern> if i copied those 2 files along with vf_concatenate.c to ffmpeg/libavfilter/ and then did "make ffmpeg_g", it should work, right?
[17:29:53] <kshishkov> have you run configure after you added that filter?
[17:30:38] <BMintern> yes
[17:31:00] <BMintern> it seems really strange to me
[17:31:47] <kshishkov> just check for CONFIG_CONCATENATE_FILTER in config.mak and HAVE_CONCATENATE_FILTER or similar in config.h
[17:33:05] <BMintern> CONFIG_CONCATENATE_FILTER=yes
[17:33:05] <BMintern> and
[17:33:05] <BMintern> #define CONFIG_CONCATENATE_FILTER 1
[17:33:05] <BMintern> respectively
[17:33:19] <kshishkov> make clean && make
[17:33:48] <kshishkov> it should help
[17:34:19] <kshishkov> if not then ask DonDiego, he has magic crystal ball
[17:35:17] <BMintern> thanks, doing it now. i was just kind of lost because i thought i followed the same process as i did when i did it before
[17:41:26] <BMintern> so weird, it's still not showing
[17:42:01] <kshishkov> look into vf_concatenate.c for filter name then
[17:42:26] <BMintern> ha! wow i'm dumb
[17:43:35] <BMintern> obv working now
[18:45:49] <CIA-1> libswscale: reimar * r30978 /trunk/libswscale/rgb2rgb_template.c:
[18:45:49] <CIA-1> libswscale: Replace some "m" constraints by MANGLE to avoid issues with some compilers not
[18:45:49] <CIA-1> libswscale: being able to compile it and deduplicate the code at the same time.
[18:51:52] <bcoudurier> hi guys
[18:51:57] <Dark_Shikari> hi bcoudurier's onjoin script
[18:55:59] <jai> someone should make fftrollbot respond next time :)
[18:56:41] <kshishkov> just fill default onbcoudurierjoin script, that's all
[19:03:52] <CIA-1> ffmpeg: stefano * r22748 /trunk/libavformat/avformat.h:
[19:03:52] <CIA-1> ffmpeg: Make av_match_ext() declaration public (move its declaration out of
[19:03:52] <CIA-1> ffmpeg: the #ifdef HAVE_AV_CONFIG_H block in avformat.h).
[19:05:19] <bcoudurier> fucking mkv
[19:05:36] <bcoudurier> requiring a parser for every codec is fucking useless
[19:06:12] <bcoudurier> I really don't get how people can prefer mkv to mp4
[19:06:41] <elenril> because it supports more codecs?
[19:06:52] <CIA-1> ffmpeg: stefano * r22749 /trunk/doc/APIchanges: Add entry for the addition of av_match_ext() to the public API.
[19:07:45] <Dark_Shikari> bcoudurier: for the user, it's better
[19:07:50] <Dark_Shikari> better tools, better support
[19:08:03] <bcoudurier> what usage ?
[19:08:11] <Dark_Shikari> It's much like the ogg argument, where the xiph devs excuse shitty design by saying that it doesn't matter for users.
[19:08:11] <bcoudurier> elenril, isom is a _generic_ container
[19:08:11] <jai> anime ;)
[19:08:15] <Dark_Shikari> And they're often right
[19:08:25] <bcoudurier> ie it provides mechanism to encapsulate _any_ codec
[19:08:37] <Dark_Shikari> Find me a player that supports vorbis in mp4.
[19:08:42] <Dark_Shikari> Or ASS subtitles.
[19:08:46] <bcoudurier> just pick one fourcc
[19:08:49] <bcoudurier> gpac does
[19:08:54] <Dark_Shikari> gpac isn't a media player
[19:08:58] <Dark_Shikari> I'm talking from the _user_ perspective
[19:08:59] <bcoudurier> they have one
[19:08:59] <Dark_Shikari> this is the problem
[19:09:04] <Dark_Shikari> yes but nobody uses it
[19:09:07] <bcoudurier> ffplay supports it
[19:09:14] <bcoudurier> you can put vorbis in mov
[19:09:17] <Dark_Shikari> nobody uses ffplay, and it doesn't do subtitles
[19:09:17] <bcoudurier> ffplay will play it
[19:09:22] <ramiro> Dark_Shikari: I do
[19:09:27] <ramiro> (use ffplay)
[19:09:29] <bcoudurier> so what ? do you want me to patch VLC for you ?
[19:09:32] <bcoudurier> I can do that
[19:09:35] <Dark_Shikari> my point is that, right now
[19:09:38] <bcoudurier> your reasoning is dumb
[19:09:39] <Dark_Shikari> mkv supports a ton of things that mp4 doesn't
[19:09:44] <bcoudurier> no
[19:09:45] <Dark_Shikari> in _practice_
[19:09:46] <Dark_Shikari> people use it because of that
[19:09:49] <Dark_Shikari> I'm not talking about developers
[19:09:54] <Dark_Shikari> I'm not talking about capabilities
[19:09:59] <Dark_Shikari> I'm talking about what players _actually support_.
[19:10:10] <bcoudurier> and extending broken basement is not really clever IMHO
[19:10:10] <Dark_Shikari> if you want to change things, make players support those things for mp4 too.
[19:10:15] <bcoudurier> players means VLC
[19:10:22] <bcoudurier> if VLC supports it
[19:10:24] <Dark_Shikari> players means MPC-HC
[19:10:25] <bcoudurier> that's enough
[19:10:26] <Dark_Shikari> and VLC
[19:10:27] <Dark_Shikari> and mplayer
[19:10:42] <bcoudurier> I don't care about MPC-HC
[19:10:46] <Dark_Shikari> But users do
[19:10:50] <Dark_Shikari> they don't care what you care about
[19:10:53] <Dark_Shikari> they care about what they use
[19:11:06] <Dark_Shikari> and considering everyone distributing MKV files almost universally says "don't use VLC"...
[19:11:15] <Dark_Shikari> what are the odds they will switch to a format that only VLC supports?
[19:11:26] <bcoudurier> that's just false
[19:11:34] <bcoudurier> tell me why users are always remuxing to mp4 ?
[19:11:42] <bcoudurier> we get a _ton_ of remuxing errors
[19:11:43] <Dark_Shikari> I've never seen a user remuxing to mp4
[19:11:44] <kierank> they are?
[19:11:48] <bcoudurier> because mkv is _not_ suitable
[19:11:49] <Dark_Shikari> I've seen a user _re-encoding_ to mp4
[19:11:50] <elenril> for ipods?
[19:11:52] <Dark_Shikari> for ipods
[19:11:56] <Dark_Shikari> but high profile mp4 won't play on an ipod either
[19:11:57] <bcoudurier> ipods, ps3
[19:12:06] <bcoudurier> everything that's just not piracy
[19:12:09] <Dark_Shikari> you cannot remux a typical mkv to play on an ipod
[19:12:21] <Dark_Shikari> and the peoplewho distribute ipod-compatible h264 files do so as mp4 anyways
[19:12:35] <bcoudurier> mkv was good for one thing
[19:12:39] <bcoudurier> subs
[19:12:48] <bcoudurier> it provided a solution before everybody else
[19:12:53] <Dark_Shikari> you are ignoring reality.  people wonder why anyone at all uses ogg: it's because of support and tools.  if you want to beat a shitty format, make your better one have better tools, and better support.
[19:13:04] <kierank> at the time of decision there was no ac-3 in mp4 too
[19:13:10] <bcoudurier> well
[19:13:23] <bcoudurier> my tree has covert art support for mp4
[19:13:40] <Dark_Shikari> now make everything support it.  that's what matters to users
[19:13:47] <Dark_Shikari> Once everything supports it, you can convince the pirates to use it
[19:13:50] <Dark_Shikari> once the pirates use it, everyone will
[19:14:00] <bcoudurier> it's funny because the _technical_ arguments against ogg matters
[19:14:02] <bcoudurier> but not against mkv
[19:14:08] <Dark_Shikari> huh?
[19:14:11] <bcoudurier> you need to get some logic here
[19:14:21] <Dark_Shikari> I have no idea what you're saying
[19:14:26] <Dark_Shikari> I'm saying the situation with ogg and mkv is the same
[19:14:34] <Dark_Shikari> both are technically worse formats than isom, though ogg is much worse
[19:14:41] <Dark_Shikari> But you can't "beat them" by just whining about how much they suck
[19:14:46] <bcoudurier> yes
[19:14:46] <Dark_Shikari> you beat them by making better tools and better support
[19:15:30] <bcoudurier> nero put ac-3 in mp4 since a long time
[19:15:42] <bcoudurier> same for vobsub
[19:18:41] <bcoudurier> <Dark_Shikari> I've never seen a user remuxing to mp4
[19:18:54] <bcoudurier> how can you say that, when you told so many users to use gpac
[19:19:01] <bcoudurier> because of the monotone timestamps error
[19:19:02] <Dark_Shikari> gpac can't remux to mp4 either
[19:19:04] <Dark_Shikari> it doesn't take mkv input
[19:19:22] <bcoudurier> extract essences.....
[19:19:28] <Dark_Shikari> ok, better said, I've never seen a user remuxing to mp4 for ipod
[19:19:40] <Dark_Shikari> I have seen users remuxing to mp4 for ps3 or whatever, but most of the time what they're doing _won't work_
[19:19:49] <bcoudurier> I bet a lot more people will do now for ipad
[19:19:52] <Dark_Shikari> for example, ASS subtitles won't work on PS3
[19:19:59] <Dark_Shikari> and users will find later, after remuxing, that their subs are gone
[19:20:11] <Dark_Shikari> bcoudurier: apple still isn't officially supporting high profile on ipad yet :/
[19:20:16] <bcoudurier> I know
[19:20:20] <Dark_Shikari> I wonder how long until they finally get around to that
[19:20:30] <bcoudurier> I know
[19:20:37] <kierank> same day all the quicktime bugs are fixed
[19:20:52] <Dark_Shikari> lol
[19:21:22] <bcoudurier> fixing quicktime doesn't mean fixing anything else unfortunately, apple uses different implementations/base
[19:21:39] <bcoudurier> in FCP, iphone
[19:21:57] <kierank> speaking of which does iphone support weightp
[19:21:58] <Dark_Shikari> same with apple tv
[19:22:00] <Dark_Shikari> fork of quicktime :/
[19:22:07] <Dark_Shikari> kierank: yes.  it doesn't use the quicktime decoder either
[19:22:09] <Dark_Shikari> it uses the OMAP thingy
[19:38:31] <BBB> bcoudurier: so what's the status of officer-vote?
[20:05:39] <BMintern> would anyone care to look over a filter for me and try to help me figure out what i'm doing wrong?
[20:06:17] <Dark_Shikari> don't ask to ask, just ask
[20:06:36] <BMintern> ok, it's http://bmintern.homeunix.com/vf_concatenate.c
[20:06:46] <Dark_Shikari> 404
[20:06:52] <BMintern> yeah sorry, one sec
[20:07:49] <BMintern> http://bmintern.homeunix.com/~brandon/vf_concatenate.c
[20:08:07] <Dark_Shikari> don't we already have a concat filter?
[20:08:10] <BMintern> the point is to take two clips and just combine them into one
[20:08:12] <BMintern> do we?
[20:08:29] <drv> there is a concat protocol, not a filter afaik
[20:08:42] <Dark_Shikari> oh.  I guess you're right
[20:09:28] <BMintern> is my approach completely wrong?
[20:10:37] <BMintern> right now it just outputs the first input and seems to ignore the other one
[20:11:59] <BMintern> there's also http://bmintern.homeunix.com/~brandon/vf_concatenate.patch if you're interested in compiling
[20:17:10] <BMintern> Vitor1001- i'm working on concatenate and i'm not sure what i've done wrong. it's only outputting the first video and seems to ignore the 2nd
[20:17:25] <BMintern> http://bmintern.homeunix.com/~brandon/vf_concatenate.c or http://bmintern.homeunix.com/~brandon/vf_concatenate.patch
[20:17:32] <Vitor1001> BMintern: sorry, can't talk right now :(
[20:17:36] <BMintern> ok, np
[20:41:41] <CIA-1> ffmpeg: rbultje * r22750 /trunk/libavcodec/ (avcodec.h options.c): Add avcodec_copy_context().
[20:56:48] <BBB> wbs: can you change the rtsp muxer code to use avcodec_copy_context() in that one location that we talked about? ;)
[20:58:56] <bcoudurier> Dark_Shikari, I completely agree that the better tools and better support is the key
[21:03:36] <CIA-1> ffmpeg: rbultje * r22751 /trunk/ (ffserver.c ffmpeg.c): (log message trimmed)
[21:03:36] <CIA-1> ffmpeg: Fix FFM-based streaming from ffmpeg to ffserver. The basic problem is that
[21:03:36] <CIA-1> ffmpeg: we'd memset() the codec context to zero, thereby setting audio input to U8
[21:03:36] <CIA-1> ffmpeg: and video to YUV420P. For most video encoders, that actually works, but for
[21:03:36] <CIA-1> ffmpeg: most audio codecs, it doesn't. This patch changes defaults to those set by
[21:03:36] <CIA-1> ffmpeg: avcodec_context_get_defaults() and have ffmpeg figure out the optimal encoding
[21:03:37] <CIA-1> ffmpeg: format itself if not set explicitely (as it does for the non-ffserver-cases
[21:11:42] <CIA-1> ffmpeg: rbultje * r22752 /trunk/ (libavcodec/avcodec.h doc/APIchanges): Document API addition of avcodec_copy_context().
[21:33:00] <BBB> latest x264 in mac/darwinports is 20090810-2245 :(
[21:33:02] <BBB> that's old...
[21:33:51] <astrange> fink is... far worse
[21:34:11] <astrange> i haven't taken over ffmpeg and related packages there as there's a lot of them, and i have no idea what some (libquicktime) even are
[21:35:26] <BBB> do you remember cinderella?
[21:35:41] <BBB> it's this video editor made by this biologist (I always think it's funny, because that sounds like me)
[21:35:48] <BBB> it had native quicktime support
[21:36:01] <BBB> that code was forked so others could use it too, and they called it libquicktime
[21:36:07] <astrange> is it the same as cinelerra?
[21:36:16] <BBB> yeah, the name changed a couple of times
[21:36:59] <BBB> mjpegtools (my first step into free software coding) actually used libquicktime at some point
[21:37:01] <BBB> maybe it still does
[21:39:59] <janneg> iirc mjpegtools on gentoo has still a quicktime use flag
[21:40:32] <pasteeater> looks like libquicktime is still being developed
[21:40:37] <pasteeater> 23. Feb 2010 libquicktime-1.1.5 released: This release brings encoding of AC3 and H.264 in AVI
[21:40:43] <pasteeater> ooh...H.264 in AVI
[21:43:04] <BBB> libquicktime does avi now?
[21:43:09] <BBB> something sounds weird
[21:43:39] <troy_s> On that subject, is there any work at getting >8bpc bit depth into ffmpeg?
[21:43:49] <BBB> I thought we had that already
[21:44:27] <Dark_Shikari> not in most encoders/decoders whose formats support it
[21:47:00] <troy_s> Dark_Shikari: So is the groundwork in place then?
[21:47:24] <troy_s> Dark_Shikari: Because I have asked a pretty astute fellow (working on RED code implementation) and he suggested that there wasn't infrastructure in ffmpeg for it.
[21:47:30] <troy_s> Dark_Shikari: Granted, that may have changed.
[21:49:26] <Dark_Shikari> there is, afaik
[21:49:30] <Dark_Shikari> we have pixfmts and swscale functions
[21:49:51] <saste> BMintern: post the concatenate patch to the soc ML
[21:50:22] <saste> BMintern: I have some fix for you...
[21:50:44] <troy_s> Dark_Shikari: Thanks for that. Is the patch to non-scale 16-235 results on HD x264 material in place in upstream yet? As in can I output a non squished 16-235 PNG from an x264 source?
[21:51:28] <BBB> troy_s: your fellow is right that in the past, the ifnrastructure wasn't there, but afaik it is there now
[21:51:50] <troy_s> BBB: Well that is most excellent news. Any chance we will see ICC / LUT support?
[21:52:05] <Dark_Shikari> troy_s: x264 has a --fullrange flag
[21:52:15] <BBB> I'm not the person working on that ;)
[21:52:21] <troy_s> Dark_Shikari: ffmpeg or x264 itself?
[21:52:25] <Dark_Shikari> I'm talking about x264
[21:52:41] <Dark_Shikari> if you're talking about ffmpeg (don't say x264), swscale has some... weirdness
[21:52:45] <Dark_Shikari> afaik, it still assumes EVERYTHING is BT.601
[21:52:49] <troy_s> Dark_Shikari: Yes. That's exactly what I am talking about.
[21:53:07] <troy_s> Dark_Shikari: (And I believe the clamp (SMPTE?) could happen in 709 as well?
[21:53:16] <troy_s> Dark_Shikari: But I kindly got a patch from David here.
[21:53:20] <Dark_Shikari> fix it then
[21:53:23] <Dark_Shikari> get it committed =p
[21:53:33] <troy_s> Dark_Shikari: I was hoping that it would land in upstream.
[21:53:37] <Dark_Shikari> pcrange vs tvrange is rarely called "clamping"
[21:54:28] <BMintern> saste: i will, thank you
[21:55:29] <troy_s> Dark_Shikari: Thanks for your time.
[21:56:06] <Dark_Shikari> you also don't have to ping me with every single message
[22:48:58] <dchana> hi there
[22:49:12] <dchana> I have a question about the j2k project
[22:49:19] <dchana> anyone here is a mentor for that project?
[23:01:56] <BBB> dchana: better to email ffmpeg-soc/ffmpeg-devel about that
[23:03:37] <Compn> kostya worked on j2k a bit i think
[23:03:55] <Compn> but i guess hes not here atm
[23:04:29] <dchana> thanks
[23:04:38] <BBB> jai did it as soc project last year
[23:04:41] <BBB> you could also ask him
[23:05:02] <dchana> Jai is not here
[23:05:14] <dchana> I'm looking for the mentor
[23:05:20] <DonDiego> dchana: mail ffmpeg-soc please
[23:05:36] <DonDiego> let's try to reduce the traffic on -devel where reasonably possible