[FFmpeg-devel-irc] IRC log for 2010-05-18

[irc at mansr.com]

[00:01:36] <Kovensky> Dark_Shikari: that on2 stuff you said you were reading is about vp7?
[00:01:42] <Kovensky> or did they release vp8 already?
[00:01:47] <Dark_Shikari> vp8
[00:01:54] <Dark_Shikari> no they didn't release
[00:01:56] <Dark_Shikari> I'm just that cool
[00:02:04] <Kovensky> hah
[00:02:12] <Kovensky> cheater ;P
[00:02:20] <Dark_Shikari> 5000 words written so far.
[00:02:23] <Dark_Shikari> enjoy your analysis on wednesday.
[00:02:29] <mru> Kovensky: NDA isn't cheating
[00:02:53] <Kovensky> mru: well, he *is* getting access to it before everyone else... =p
[00:02:55] <Dark_Shikari> I would say I have their spec, but "spec" is being too nice.
[00:03:05] <mru> Kovensky: untrue, I have it too...
[00:03:29] <Kovensky> meh
[00:03:38] <Kovensky> you have access to it before The Internets
[00:03:45] <Dark_Shikari> so do a lot of people
[00:04:11] * Kovensky wonders what they want with this NDA
[00:04:21] <mru> non-disclosure
[00:04:24] <Dark_Shikari> they want to be able to make drama when they release it obviously
[00:04:25] <Kovensky> well ofc
[00:04:30] <Kovensky> but what do they profit from that
[00:04:35] <mru> attention
[00:04:38] <Dark_Shikari> +1000
[00:04:54] <Kovensky> negative attention? ._.
[00:04:59] <Dark_Shikari> no such thing
[00:05:04] <Dark_Shikari> don't be impatient, only two days and you can learn yourself how shitty it is.
[00:05:12] <mru> that's what they'd get if they let Dark_Shikari publish his comments before they start beating the drum
[00:05:19] <Dark_Shikari> And yeah, that
[00:05:34] <Kovensky> oh, it's out on wednesday
[00:05:35] <mru> now they've worked up a nice hype
[00:05:37] <Kovensky> makes sense
[00:05:55] <Kovensky> I wonder how many freetards will praise it
[00:06:06] <Dark_Shikari> I suspect not as many as you think
[00:06:10] <mru> hehe
[00:06:12] <Dark_Shikari> especially after reading my blog post.
[00:06:17] <Dark_Shikari> And not because of compression or quality.
[00:06:19] <mru> Dark_Shikari: freetards don't trust us
[00:06:34] <Dark_Shikari> mru: maybe, but I think they are worried about patents.
[00:06:41] <Dark_Shikari> Way too much, perhaps
[00:06:43] <mru> only the ones they believe in
[00:06:44] <Dark_Shikari> but they are.
[00:06:44] <Kovensky> "yeah yeah he develops x264 he's just being defensive about his precious"
[00:07:16] <Dark_Shikari> I didn't get any of those comments on my previous vp8-related post ;)
[00:07:33] * Kovensky wonders if search ars would yield those comments
[00:07:36] <Kovensky> +ing
[00:07:39] <Dark_Shikari> well probably
[00:07:42] <Dark_Shikari> you search enough /. clones
[00:07:44] <Dark_Shikari> and you get /. comments
[00:07:49] <Kovensky> lol
[00:07:53] <Kovensky> true that
[00:10:44] * mru likes it when neon code is shorter than C version
[00:11:03] <kierank> [00:55] <@bcoudurier> then their encoder is utter crap --> my point was that for CBS the encoder between CBS--->affilliate is bad so the encoder from affiliate-->OTA/Cable doesn't stand a chance.
[00:11:05] <Dark_Shikari> in lines of code or total asm?
[00:11:10] <mru> lines of code
[00:11:15] <lu_zero> mru: isn't that expected? =P
[00:11:23] <Dark_Shikari> yeah, lines of code is rather nice =p
[00:11:24] <mru> uncompiled C
[00:11:48] <mru> sometimes the optimised code is much larger than compiled C
[00:11:51] <mru> depends on what it does
[00:11:52] <bcoudurier> OTA is ok
[00:11:55] <bcoudurier> cable is crap
[00:11:59] <mru> and on how insanely you optimise it
[00:12:26] <Dark_Shikari> I prefer optimized code that's much smaller
[00:12:34] <Dark_Shikari> like x264's CABAC, whose core 3 functions now fit in under 256 bytes
[00:12:41] <mru> sometimes you have to unroll more to get optimal scheduling
[00:12:43] <Dark_Shikari> previously each one was > 256 bytes, thanks to gcc
[00:12:52] <Dark_Shikari> now they all fit in less than the size of 1.
[00:13:27] <mru> if making it longer saves more than the cost of a cache miss, that's what you do
[00:13:36] <Dark_Shikari> well of course
[00:13:44] <Dark_Shikari> and the relative values of icache vs dcache
[00:13:56] <mru> extreme case: neon float2int16
[00:14:06] <Dark_Shikari> the nice thing about x86 is that with its powerful OOE, you can generally get away with really really small code
[00:14:14] <Dark_Shikari> which is really useful on intel chips with small L1
[00:14:29] <Dark_Shikari> additionally, you can often abuse memory arguments to get even smaller code
[00:14:39] <mru> depends on the instruction latency
[00:14:42] <Dark_Shikari> sub [mem], 2 is much smaller than load/sub/store
[00:14:48] <Dark_Shikari> and in many cases--actually faster.
[00:15:01] <mru> if you instructions have 5 cycles latency but you have less than 5 insns per iteration, you need to unroll
[00:15:14] <Dark_Shikari> there aren't any 5 cycle latency instructions on x86
[00:15:16] <Dark_Shikari> not that anyone uses
[00:15:19] <Dark_Shikari> unless you count atom or some shit
[00:15:24] <mru> not even floating-point?
[00:15:30] <Dark_Shikari> fpu multiply is 4 I think
[00:15:31] <mru> I mean result latency
[00:15:34] <mru> not issue rate
[00:15:37] <Dark_Shikari> yes
[00:15:41] <Dark_Shikari> issue rate is almost always 1 per cycle
[00:15:46] <Dark_Shikari> or 2 or 3
[00:16:03] <mru> it can only be >1 if there are no dependencies
[00:16:30] <Dark_Shikari> of course.
[00:16:39] <Dark_Shikari> fpu add: 3/1
[00:16:41] <Dark_Shikari> fpu mul: 4/1
[00:16:48] <mru> although a very short loop could fit several iterations in the reorder queue
[00:16:49] <Dark_Shikari> double-precision multiply is 5/1
[00:16:53] <Dark_Shikari> so yeah, there is one instruction that's latency 5
[00:16:57] <Dark_Shikari> but why the hell would you use double
[00:17:12] <Dark_Shikari> also the complex instructions (e.g. sqrt) are slower but that's a given.
[00:21:08] <Kovensky> OT: <Chandalen> http://fukung.net/v/28922/3de7b9e3e3c6e4f1dbc6ef5e0169b7b2.gif <~neo2sonic> oh, a snowflake. ahah... oh, mor-------------
[00:22:14] <mru> looks like a boring block of flats in a swedish suburb
[01:46:42] <thick_mcrunfast> Where can I find a description of the mpeg 2 TS stream format?
[01:47:46] <thick_mcrunfast> That was embarrassing.
[01:55:06] <Compn> thick_mcrunfast : might be on the wiki
[02:01:52] <Compn> thick_mcrunfast : http://wiki.multimedia.cx/
[02:02:02] <thick_mcrunfast> Compn: Ah, thank you
[02:02:50] <Compn> http://wiki.multimedia.cx/index.php?title=MPEG-2_Transport_Stream
[03:28:31] <saintd3v> peloverde: i opened up the ff-aac output in baudline, what causes the giant holes?
[03:29:28] <peloverde> I thought I fixed most of the holes
[03:29:37] <peloverde> are you using r23136 or newer
[03:29:53] <saintd3v> just did a git clone today
[03:30:24] <peloverde> hmm...
[03:30:39] <peloverde> what encoding parameters? mono or stereo?
[03:31:03] <saintd3v> it's not as bad as when the cutoff was there, but just curious
[03:31:32] <saintd3v> ffmpeg -i test.wav -acodec aac -ab 160k -f mp4 test.mp4
[03:31:37] <saintd3v> stereo
[03:31:49] <peloverde> In the past holes were caused by the codebook selector using information from the wrong frame
[03:32:26] <peloverde> I've been stereo, mid/side is probably buggy
[03:32:43] <peloverde> do you get holes for mono?
[03:32:57] <saintd3v> dunno, haven't tried it
[03:34:32] <saintd3v> peloverde: http://imgur.com/HmRPE.jpg
[03:37:13] <saintd3v> would that be the same issue?
[03:38:54] <peloverde> same issue as?
[03:39:26] <saintd3v> codebook using the wrong information?
[03:39:57] <peloverde> It could be
[03:40:25] <saintd3v> ok :) was just curious
[03:40:45] <peloverde> I'd have to verify that those are 0HCB and what's causing them to be
[03:41:41] <peloverde> previously the psymodel was giving mask ratios for the previous frames causing disaster whenever there was window switching
[04:33:38] <peloverde> If I have a container that sets a packet size to a fixed value then places a frame in the packet then zero pads the rest of the packet, what's the best way to deal with that?
[05:18:44] <Yuvi> is libopenjpeg really #include <openjpeg.h> not <openjpeg/openjpeg.h>?
[05:18:44] <Yuvi> I'm not sure one way or another given their install system put it in /openjpeg
[05:19:22] <Dark_Shikari> I think they might have changed it
[05:34:15] <peloverde> Fresh install of VC++ Express 2010 and I get a non-descript FileNotFound exception on launch, how are these people still in business?
[05:35:36] <Dark_Shikari> peloverde: http://thedailywtf.com/Articles/What_Is_Truth_0x3f_.aspx
[05:53:05] <Tjoppen> classic wtf :)
[06:01:55] <elenril> is aacenc still supposed to sound like shit at 320kbps?
[06:03:16] <Tjoppen> dunno.. it's been poked at recently so I haven't had time to test, but I've gotten good results with 256 kbps
[06:03:44] <Tjoppen> when it doesn't SIGSEGV of course :o
[06:09:41] <superdump> morning
[06:36:49] <thresh> moroning
[06:39:46] <av500> what thresh said
[07:04:08] <KotH> ohayou gozaimasu!
[07:04:30] <wbs> gomorgon
[07:04:42] <merbzt1> tere homikost
[07:35:37] <thresh> __gb__: could I suggest libva build-depends on libgl-dev (that is provided by nvidia-glx-dev and libgl1-mesa-dev on my sid system), and not only on libgl1-mesa-dev ?
[09:57:47] <scaphilo> has anyone an idea why i get the following error after calling ffmpeg with the following options: ffmpg_nios -i myownprotocol:filename -f mpeg4  myownprotocol:filename
[09:58:10] <KotH> scaphilo: wrong channel
[09:58:15] <KotH> scaphilo: try #ffmpeg instead
[09:58:30] <scaphilo> am i built my own protocol
[09:58:41] <scaphilo> thats wy i ask here sorry
[09:58:55] <KotH> oh.. then give more info :)
[09:59:30] <scaphilo> Unable for find a suitable output format for myownprotocol:filename
[09:59:47] <scaphilo> it refers to the -i file not the ouptut file
[09:59:52] <scaphilo> or better protocol
[10:00:07] <scaphilo> wait its not good described ill have to rewrite that
[10:00:27] <scaphilo> ffmpg_nios -i myownprotocol:filename.mpeg -f mpeg4  myownprotocol:filename.mp4
[10:00:34] <scaphilo> Unable for find a suitable output format for myownprotocol:filename.mpeg
[10:00:58] <scaphilo> thats strange i would suspect that i get the same error with  myownprotocol:filename.mp4
[10:03:04] <merbzt1> scaphilo: try asking on libav-users
[10:03:50] <scaphilo> oh thx
[10:05:36] <hyc> anyone interested in patches for ffserver to also serve rtmp ?
[10:06:05] <wbs> hyc: if ffserver actually works, I guess that would be interesting
[10:06:17] <merbzt1> hyc: bring em on
[10:06:19] <hyc> it would work, if my patches got committed
[10:06:40] <wbs> one problem with ffserver generally is that it totally abuses the libav* interfaces and uses lots of non-public stuff from libavformat
[10:07:00] <hyc> I think it'd be worth doing, but I still must admit to a degree of frustration getting any of my contributions in
[10:07:35] <wbs> hyc: I'm still waiting for review of stuff i made in mid-april ;P
[10:08:00] <wbs> but for the rest of your ffserver patches, they need the attention of someone more knowledgeable on ffserver, can't help you on that
[10:08:06] <hyc> so just par for the course huh
[10:08:07] <av500> hyc: come on, just implement that new seeking api and the rest is easy peasy... :)
[10:08:29] * hyc coughs ...
[10:08:48] <merbzt1> baptiste is the current maintainer for ffserver
[10:09:22] <hyc> apparently he's not spending any attention on it right nwo
[10:09:26] <hyc> (now)
[10:09:38] <hyc> we were all in IRC together a few hours ago and he didn't mention ffserver at all
[10:11:12] <hyc> (19:30:23) bcoudurier: mru, what bandwidth is dvb-t ?
[10:11:53] <merbzt1> well we all need more hours during the day
[10:13:10] <hyc> yeah
[10:19:19] <Compnn> hyc : we dont want to continue rtmp spreading, why put streaming in ffserver? :P
[10:20:08] <hyc> Compn: I'm actually considering dropping the rtmpdump command and just using ffmpeg
[10:20:51] <hyc> but the idea about ffserver is just because I googled "rtmp rtsp" and there appear to be more queries about going from rtsp to rtmp than vice versa
[10:21:06] <Compn> ah
[10:21:11] <hyc> which I must admit is frankly, quite odd
[10:21:36] <hyc> rtsp is an IETF standard. I think it's better to go from rtmp to rtsp
[10:21:53] <Compn> combining rtmpdumps features into ffmpeg and sticking with ffmpeg would be an interesting idea, as long as you dont get frustrated with ffmpeg review process :P
[10:21:55] <hyc> which we now can do, in a nlucky way
[10:22:14] <hyc> yeah, that's teh sticky part. I find this project quite annoying.
[10:22:24] <hyc> I only stick with it because the code is obviously useful
[10:23:06] <hyc> it only took a couple days to get my rtmp patches into libcurl
[10:23:37] <hyc> but libcurl isn't the proper vehicle for rtmp protocol. to really take advantage of it you need audio/video/media support.
[10:23:38] <Compn> thats neat, i remember curl had a seriously old patch for rtmp but it was never applied...
[10:23:49] <hyc> ffmpeg is really the place to do this work
[10:24:34] <Compn> i wonder if people would have to fork ffmpeg minus the encryption stuff (similar to flvstreamer )
[10:24:41] <Compn> if that was done
[10:25:05] <Compn> people/distros
[10:25:06] <hyc> that seems pretty unlikely. ffmpeg already has its own rc4 implementation
[10:25:14] <hyc> nobody gives that a 2nd thought
[10:25:34] <Compn> it doesnt have the ... secret code ... 'genuine adobe 001' or whathaveyou :P
[10:25:52] <hyc> ohhhhh, the super secret master key..... :P
[10:26:11] <hyc> you can't copyright a key
[10:26:27] <hyc> there's no legal standing to stop anyone distributing it
[10:26:45] <hyc> you can only copyright works of significant creative value
[10:26:45] <Compn> tell that to the bluray (aasc?)lawyers
[10:27:28] <hyc> I think the bluray story was more than the key, it was about the algorithm wasn't it?
[10:27:37] <hyc> I don't remember the details
[10:27:39] <Compn> no, it was just the key
[10:27:53] <Compn> a string of numbers/letters
[10:28:17] <Compn> but i dont think there was a lawsuit yet, i think they abandoned such a venture after the number was spread across them internets
[10:29:20] <Compn> the guy in charge was interviewed and sounded like he actually understood what happened even
[10:29:53] <Compn> http://en.wikipedia.org/wiki/AACS_encryption_key_controversy
[10:30:50] <hyc> thx, was looking for that...
[10:38:12] <hyc> illegal numbers, yeah right. nobody owns numbers. I hope they take this to court. when they lose, they can pay triple damages for racketeering.
[10:38:59] <hyc> I wonder what those bytes do as 6502 opcodes. for all we know it's a useful instruction stream on some microprocessor out there.
[10:39:27] <hyc> go back far enough and you might be able to sue them for violating your own copyright on this piece of vital program code ;)
[10:41:41] <Compn> the mpaa spews fourth an amazing amount of crap lawsuits each year :(
[10:47:10] <Compn> oh
[10:47:27] <Compn> so rtmp stuff goes into ffmpeg, then rtmpsuck just calls ffmpeg ?
[10:47:59] <Compn> could work.
[10:48:14] <hyc> just thinking out loud
[10:49:15] <mru> KotH: you're coming to linuxtag?
[10:54:45] <hyc> wbs: re: the ffserver patches, why was the c= patch so easy to get in, but the rest are waiting? they're all trivially small, and the current code is obviously incorrect.
[10:55:38] <hyc> nobody has gotten anything useful out of ffserver rtsp in years, it doesn't take a rocket scientist to see that...
[10:56:20] <wbs> hyc: I guess it's all up to psychology, what motivates people to read the patches or not - since luca a ok'd it, baptiste just had to add that he didn't have any further objections
[10:56:24] <Compn> not many people work / care about ffserver last i remember
[10:56:35] <hyc> http://www.mail-archive.com/ffserver-user@mplayerhq.hu/maillist.html
[10:56:41] <hyc> Compn: apparently that's true
[10:57:09] <hyc> questions about ffserver rtsp simply go unanswered
[10:57:23] * Compn laughs at browser being called a spambot by mail-archive.com
[10:57:42] <Compn> ahh http referrer, my arch nemesis
[10:58:22] <hyc> 2009/05/01 RTSP streaming using ffserver - no answer
[10:58:44] <Compn> maybe if someone offered to maintain ffserver ....
[10:59:09] <hyc> 2009/10/26 is rtsp output currently broken? - no answer
[10:59:41] <hyc> heh. effectively I *am* maintaining it. but not effectively, because I can't actually commit any of the required fixes. :P
[10:59:59] <Compn> cant you? heh
[11:00:23] <Compn> svn access used to be linked , but maybe that was changed
[11:00:37] <Compn> after the uau thing...
[11:00:42] <hyc> I think I tried a test commit in the mplayer svn, couldn't do it
[11:00:49] <Compn> ah, then probably not
[11:01:15] <Compn> wbs has commit access tho
[11:01:20] <hyc> and there's not much point in doing a commit without permission anyway
[11:01:30] <hyc> would just get other people pissed off
[11:01:53] <Compn> of course, i didnt mean to suggest that
[11:02:30] <wbs> Compn: yeah, but i'd like to get some ack on the patches by someone a little bit more familiar with ffserver than me (i've hardly even looked at it)
[11:02:55] <Compn> ffmpeg has some strict rules.
[11:03:02] <wbs> once they're ok'd I sure can volunteer to commit them ;P
[11:03:02] <hyc> sure it does
[11:03:18] <hyc> regardless, I spent the better part of 2 days in quality time with gdb and wireshark
[11:03:22] <Compn> it has to be reviewed, tested, pass regression tests, and ok'd by maintainer
[11:03:32] <hyc> it's obvious the code was completely broken before
[11:03:38] <hyc> and it is also obvious that it now works
[11:03:39] <Compn> probably some valgrind and benchmarks just to be sure :)
[11:03:53] <hyc> yes, some valgrind time too. you know me too well. :P
[11:04:14] <Compn> i meant a ton of stuff in ffmpeg goes thru valgrind , but ok :)
[11:04:46] <Compn> hyc : you using ffserver rtsp for your phone ?
[11:04:51] <hyc> I'm not a novice programmer, I know when code is wrong and when it's right. and I take the steps necessary to prove it. ;)
[11:04:55] <hyc> yep
[11:05:07] <hyc> works like a charm now
[11:05:32] <Compn> i think i'm waiting before cell phone data rate prices go down before i try any of that
[11:05:57] <hyc> ah, the t-mobile google phone plan is unlimited data and text
[11:06:16] <hyc> but the t-mobile network is ... spotty
[11:06:38] <hyc> I did most of the testing on my home wifi, and then tried on t-mobile 3G after I had everything working
[11:07:16] <Compn> i was just curious what people use rtsp for anymore :P
[11:07:23] <ohsix> more like their affiliation; they lease
[11:07:31] * Compn goes afk
[11:07:42] <wbs> Compn: all mobile phones except microsoft and apple support that for video streaming
[11:07:54] <hyc> I've decided to write a hulu-to-rtsp web page. navigate the hulu web site in one subframe, then click a link in the parent page to stream whatever is in the hulu frame.
[11:08:19] <hyc> I think it will be just a few lines of javascript to manage that...
[11:11:27] <hyc> maybe I should plug in the get-flash-videos script instead, then I can stream just about anything
[11:12:26] <hyc> one downside is that rtsp is UDP and lossy. Most of the stuff you'd want to view out there is plain ol' http.
[11:12:30] <Compn> tmobile has some lame clip site that mocks hulu dont they?
[11:12:38] * Compn seems to remember something about verizon having a site
[11:12:42] <hyc> no idea.
[11:13:03] <hyc> I recall trying to run rtmpdump from my phone using their 3G and being blocked
[11:14:40] <hyc> so ideally I would have the CGI on my web server fetch the video and then make it available using TCP to my phone.
[11:15:04] <hyc> and then run ffserver on my phone to reframe it as rtsp for the local media apps to play
[11:15:10] <hyc> talk about kludgy
[11:15:31] <wbs> hyc: rtsp can do tcp-interleaved packet transport, too
[11:15:39] <hyc> yes but my phone can't
[11:15:43] <wbs> don't know how to request that in the on-device media players though
[11:15:53] <hyc> apparently that's not implemented in the opencore code
[11:16:13] <hyc> I have the full android source code too, but the opencore stuff is all crappy C++ code
[11:16:39] <hyc> taking the route I've gone so far is much faster than figuring out how to connect librtmp into their framework
[11:17:04] <hyc> kinda pathetic
[11:17:07] <CIA-7> ffmpeg: mstorsjo * r23154 /trunk/ffserver.c:
[11:17:07] <CIA-7> ffmpeg: ffserver: Write proper GMT date/times in Date headers
[11:17:07] <CIA-7> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com
[11:17:19] <wbs> there you go, one down ;P
[11:17:23] <hyc> woohoo, thanks wbs ;)
[11:17:51] <hyc> of course, that only fixes a bug that only people using wireshark will ever see. :D
[11:18:14] <wbs> yeah, but nevertheless, one patch less in the review queue, once the almight maintainer decides to take a look :-)
[11:18:39] <hyc> yep. (And considering how much I was using wireshark, that bug annoyed the piss out of me. ;)
[11:19:29] <hyc> anyway, taking this route produces a solution (however kludgy) that works for any phone.
[11:19:50] <hyc> adding librtmp to the android source will only help people willing to burn new firmwares on their phones
[11:20:01] <KotH> mru: according to current planning, no
[11:20:14] <wbs> yeah, and you get the option to downscale the video to get a version suitable just for the environment you're in
[11:20:15] <KotH> mru: unless i've lots of luck
[11:20:25] <KotH> mru: i send the posters to janneg this morning
[11:20:27] <Compn> hyc : so , of course dumb question, ffplay cant handle playing on your phone because of a lack of hardware dsp decoder support? thats why you need the local programs
[11:20:35] <KotH> mru: but i take a t-shirt anways :)
[11:21:12] <hyc> Compn: I think it's more than that, you can't easily run native code in combination with the android UI
[11:21:16] <hyc> it has to be java
[11:21:33] <mru> there's the NDK
[11:21:45] <wbs> mru: which is for building JNI components only
[11:21:49] <hyc> yeah, but that's still a low-level thing
[11:21:50] <wbs> officially at least
[11:22:00] <hyc> you still have to paste a java front end on anything you write
[11:22:12] <mru> yes, but you can run native code
[11:22:12] <wbs> you interface with the platform solely through java, but can accelerate your app with algorithms in native code
[11:22:40] <mru> so you could write a thin java launcher and do everything else in native
[11:22:47] <hyc> right
[11:22:59] <wbs> in principle, you actually can do UI through opengl in native code
[11:23:40] <wbs> so ffplay with gl es output, and piping the audio over JNI to the java side for playback, could work
[11:24:03] <hyc> I guess you could actually use libav to just grab the data and feed it to the android video api
[11:24:14] <hyc> haven't looked into that at all
[11:24:51] <wbs> if working with custom roms and not only the official api, that's a possibility, too - i don't think there's any such apis that would be usable in the official sdk
[11:24:58] <hyc> haven't coded anything serious in java in 6-7 years either. the last thing I wrote in java just fork/exec'd a c program.
[11:25:52] <hyc> I downloaded the newest Sdk but  haven't looked inside yet
[11:26:10] <hyc> just recently flashed cyanogen's eclair onto my g1
[11:27:40] <hyc> so I can test the newest APIs. but not really interested in being a java dev...
[11:38:15] <Compn> a quick kludge is faster than a java wrapper anyways :P
[11:39:36] <hyc> yep ;)
[11:39:50] <wbs> hyc: when using ffserver, the ffmpeg process that feeds ffserver with data does the actual transcoding, and ffserver just relays the packets without {de,en}coding it, right?
[11:40:34] <hyc> right
[11:40:38] <wbs> ok
[11:40:44] <hyc> but there's a catch
[11:40:56] <hyc> the codec parameters are defined in the ffserver config
[11:41:10] <hyc> they get written into the feed ffm file
[11:41:33] <hyc> ffmpeg first does an http get on this file, and then does an http post with the transcoded stream
[11:41:50] <wbs> is this all in lavf/ffm* or something?
[11:42:01] <hyc> yes
[11:42:18] <wbs> can you choose an encoder using a name, if there's multiple ones implementing the same format?
[11:42:23] <hyc> nope
[11:42:32] <hyc> it only stores the numeric codec ID in the ffm header
[11:42:37] <wbs> ok
[11:42:54] <hyc> also the ffm header is incomplete, compared to all of the possible config settings
[11:43:33] <hyc> I mentioned this here several hours ago - it can be a problem, because ffserver actually generates the global header data that gets transmitted to an rtsp client
[11:43:45] <hyc> but ffmpeg generates the stream data
[11:43:57] <hyc> and ffmpeg's settings will be incomplete relative to ffserver's config
[11:44:17] <wbs> yeah, that's the thing I was about to comment on - doing it that way feels like a hack
[11:44:32] <wbs> since you can't really be sure that the extradata generated matches the one that ffmpeg would create
[11:44:38] <hyc> exactly
[11:44:49] <wbs> also, you leak the opened encoder in that patch
[11:45:13] <hyc> well... it's hard to call it a leak, since that handle is open anyway for the life of the process
[11:45:30] <hyc> it needs to be present
[11:45:37] <hyc> if you close it the extradata will eb freed.
[11:45:57] <wbs> well, if not sooner, it should be freed on exit
[11:45:58] <CIA-7> ffmpeg: mstorsjo * r23155 /trunk/ffserver.c:
[11:45:58] <CIA-7> ffmpeg: ffserver: Don't set me_method unconditionally
[11:45:58] <CIA-7> ffmpeg: Patch by Howard Chu, hyc at highlandsun dot com
[11:46:38] <hyc> hm. I assumed that closing the avcodecontext would do that.
[11:46:56] <hyc> ooo, you're making me do another svn up. cool. ;)
[11:47:14] <CIA-7> ffmpeg: mstorsjo * r23156 /trunk/ffserver.c: Cosmetics: reindent
[11:47:50] <wbs> yeah, closing it should be enough
[11:48:08] <wbs> is that done by the /* close each frame parser */ clause?
[11:48:56] <hyc> hm I don't think so, that's per-connection
[11:49:05] <hyc> the leak you're talking about is a global/master
[11:49:23] <wbs> yeah, but that's the only avcodec_close I find in the file
[11:49:48] <hyc> ok, then lemme take a closer look
[11:50:05] <wbs> ok
[11:50:13] <wbs> ideally would be to actually get the correct extradata from ffmpeg
[11:50:31] <hyc> yes, I agree
[11:51:07] <wbs> don't have any more time to spare, to dive into this at the moment, but at least some of the really obvious ones got commited ;P
[11:51:11] <hyc> valgrind agrees with you, the codec is leaked
[11:51:18] <hyc> thanks
[11:51:27] <hyc> I'll plug the leak and repost
[11:51:39] <wbs> ok
[11:52:12] <hyc> I was thinking the other alternative was to add more fields to the ffm header
[11:52:19] <wbs> I guess it would be good with a big fat todo/fixme note saying that the correct extradata should be fetched from ffmpeg, and a small explanation on why this isn't the case at the moment
[11:52:35] <wbs> ah, so that's the reason why the correct extradata isn't used? that's way, way much better then
[11:53:03] <hyc> yes, put the complete set of settings in so that it's possible for ffmpeg to generate the same result as ffserver expected
[11:53:36] <hyc> your way is quicker ;)
[11:53:49] <wbs> ah, but can't you send the actual extradata that was produced, through ffmpeg to ffserver?
[11:54:03] <hyc> yes, in fact it is sent already, and ffserver discards it
[11:54:21] <hyc> so like I said, your suggestion should be fast to implement
[11:54:47] <wbs> ok, how much work would it be to actually use that instead of discarding it and making up new extradata which may or may not match the actual one?
[11:55:06] <hyc> but ultimately i think it's not the correct thing to do. presumably the person configuring ffserver knows exactly what they want.
[11:55:13] <hyc> ffmpeg needs to be faithful to that...
[11:55:23] <wbs> yes, but extradata must match the actual data
[11:55:32] <wbs> not the intended config
[11:55:50] <hyc> right. so the proper fix is to make the actual data match the config.
[11:56:35] <wbs> IMO the better solution would be to make sure the actual extradata that the real encoder that encodes the data produced
[11:56:57] <wbs> otherwise you're just trying to patch things together, trying to produce a copy that hopefully matches
[11:57:09] <hyc> ultimately I agree with you that the correct extradat must be used
[11:57:31] <hyc> but ideally, what ffmpeg produces should be exactly what was configured in ffserver.conf
[11:58:02] <wbs> if they're built with the exact same version, linking to the exact same version of libx264 etc
[11:58:24] <hyc> yeah... ideal world.
[11:59:00] <wbs> so preserving the correct copy of extradata would be robust, then as a secondary improvement one can try to make sure that all the correct parameters actually are passed from ffserver to ffmpeg
[11:59:11] <hyc> ok
[12:00:28] <hyc> I would feel more comfortable about this if it were possible to augment the settings ffmpeg gets from ffserver using the ffmpeg commandline
[12:00:45] <hyc> but in my testing, ffmpeg's commandline settings were completely overridden
[12:20:12] <hyc> hmmmmm. ffserver actually has no clean shutdown handler anywhere
[12:20:55] <hyc> it doesn't trap sigint or sighup or any of the other usual suspects
[12:21:02] <hyc> and it has no quit command
[12:21:15] <hyc> so there is no way to make it clean itself up
[12:21:22] <wbs> oh, great
[12:25:54] <hyc> it's really not worth worrying about
[12:26:14] <wbs> is there any global cleanup code at all in ffserver.c?
[12:26:20] <hyc> nope, not a bit of it
[12:26:36] <hyc> there's another leak too, the poll_table used in http_server's event loop
[12:26:37] <wbs> ok, then I guess it's ok to leak global stuff as you like
[12:26:55] <hyc> yeah, it's not something that grows over time
[12:43:54] <mru> janneg: ping
[12:46:29] <hyc> wbs: I'm wrong, ffserver keeps a copy of the extradata that ffmpeg sends. but it's not getting stashed in the right place.
[12:46:59] <hyc> so I may be able to get rid of my extra avcodec_open, if I can figure out which stream structure it really belongs in
[12:47:21] <wbs> ok, that's good news
[13:07:39] <pentanol> hello, if I've got stream without duration, should I avoid dts then?
[13:07:52] <mru> uh?
[13:08:26] <pentanol> in source I receiver stream Duration: N/A, start: 0.000000, bitrate: N/A
[13:08:54] <pentanol> duration doesn't exist because it's infinity stream form camera
[13:09:17] <janneg> mru: pong
[13:10:06] <mru> janneg: is mythtv registered for linuxtag or do you need a pass from us?
[13:10:25] <pentanol> or, probablt in next:-9223372036854775808 dts:-9223372036854775808 off:0 0 dts such as unsigned value
[13:10:37] <pentanol> probably*
[13:12:04] <janneg> mru: mythtv is not registered. too few people for booth duty
[13:12:33] <mru> ok, adding you to our list then
[13:13:48] <pentanol> dts computed from stream duration?
[13:14:10] <mru> uh?
[13:14:45] <pentanol> what from dts computed?)
[13:15:05] <janneg> thanks. Do you know how much wall space the booth has? I would guess there's not enough for the beast and my LCD
[13:15:28] <mru> http://www.linuxtag.org/2010/dl/projects2010/Hall7.2b-14May.jpg
[13:15:41] <mru> I don't know how final that floorplan is
[13:15:58] <mru> but it looks like we have 5m of wall there
[13:15:59] <mru> to share
[13:17:26] <Kovensky> did you guys finish with rbultje
[13:17:27] <Kovensky> er, BBB
[13:18:31] <av500> mru: we need more monitors :)
[13:19:25] <mru> we have janneg's 32" (?) LCD
[13:19:33] <janneg> yeah, seen the floorplan, I wasn't sure if we have 2 or 3 open edges
[13:19:37] <janneg> 37"
[13:19:41] <mru> right
[13:20:35] <pentanol> put ctrl and turn scroll ;)
[13:20:43] <janneg> av500: I expect vlc and xbmc to bring some
[13:20:51] <av500> janneg: I meant for the wall :)
[13:21:02] <av500> mru: TI booth is in throwing distance
[13:21:16] <mru> yep
[13:21:22] <mru> so we can steal their beagles
[13:21:26] <twnqx> TVs... so old :\
[13:22:24] <av500> mru: that is not enough to calm my anger...
[13:22:42] <twnqx> Oo
[13:22:44] <twnqx> oO
[13:22:53] <twnqx> part delivery problems? :>
[13:22:55] <mru> you're angry with TI?
[13:23:35] <av500> twnqx: that too
[13:23:58] <twnqx> friend of mine has some parts on backorder with delivery set for august...
[13:24:51] <av500> no, they hurry to get our parts in time
[13:32:37] <pentanol> hm, I tries playing few rtsp stream, one from youtube and another from my camera, youtube works sell, but with camera I've got [h264 @ 0x95be570]non-existing PPS referenced
[13:33:29] <pentanol> also I tries different rates on the camera, looks like in demuxer everything well also, but it won't playing from my camera
[13:35:24] <pentanol> also in demuxed I found oddly thing such as 32 -1 , why not just 31?
[13:36:34] <mru> wow, only one build failure on FATE
[13:38:52] <pentanol> lets fill it:)
[14:03:31] <hyc> wbs: ok, posted the revised patch without extra avcodec_open()s
[14:03:53] <hyc> and now plugging a lot of per-session leaks. fun fun fun.
[14:15:03] <merbzt> hyc: MrNaz is a ffserver user, if you need something tested he might be able to help
[14:17:31] <hyc> thanks merbzt
[14:18:00] <hyc> MrNaz, have you looked at any of the ffserver patches I've posted?
[14:49:14] <hyc> wbs: valgrind now reports 0 lost bytes...
[15:09:27] <hyc> I find it hard to believe that *anybody* has been an ffserver user up till now
[15:09:50] <hyc> this code is strewn with bugs.
[15:59:53] <peloverde> The direct show SDK used to come with some ASF tools, do those tools (or modern equivalents) still exist? I can't find them in the "Windows SDK"
[16:01:04] * av500 has then on his pc
[16:01:57] <av500> peloverde: ping me if you cant find them
[16:24:42] <kshishkov> BBB: please look at that patch from Chinese guy on removing redundant code from RM demuxer
[16:32:28] <BBB> you already reviewed it
[16:32:31] <BBB> patch is fine with me
[16:39:41] <peloverde> I found a modern replacement but it is source only and requires ATL :(
[16:41:59] <peloverde> (ATL not being supported by VC Express)
[16:49:03] <BBB> kshishkov: apply it plaese? :)
[16:53:05] <Compn> peloverde : all i remember is that microsoft threatened virtualdub to remove asf support. did they change since then? i dunno.
[16:53:31] <Compn> peloverde : maybe you want the 'windows media sdk' ?
[16:54:00] <Compn> http://msdn.microsoft.com/en-us/library/dd757738(VS.85).aspx
[16:54:03] <_av500_> peloverde: ATL?
[17:03:35] <janneg> are all patch monkeys on vacation? I'm waiting for two ok-ed patches to get committed
[17:04:42] * janneg wonders how many reviewed patches get lost
[17:07:22] <pJok> quite a lot probably
[17:09:07] <janneg> I guess using patchwork is not an option for natsuki since it depends on django
[17:10:27] <peloverde> ATL is a windows template library, 'windows media SDK' doesn't install on windows 7 but I need their mpeg-4 stack which only comes with windows 7
[17:14:45] <kierank> Have you looked at the DirectX sdk peloverde? ASF could be part of directshow
[17:15:10] <peloverde> kierank: that stuff is all super deprecated
[17:15:35] <_av500_> peloverde: what asf bits do you need?
[17:15:41] <_av500_> their demo src code?
[17:16:26] <peloverde> I want to see how their tools remux AAC from ASF to MP4
[17:16:35] <_av500_> ah
[17:16:39] <peloverde> This tool seems perefect http://blogs.msdn.com/mf/archive/2009/12/02/mfsimpleencode.aspx
[17:17:00] <_av500_> the ones i have prolly dont do that at all
[17:17:44] <peloverde> yeah have have the old tools in a milk carton with an ASF T-shirt, that was a fun promotion
[17:19:23] <peloverde> The old tools *might* be capable of remuxing it to something but ideally I'd like to use a mediafoundation tool
[17:22:33] <peloverde> This demo seems to build :) http://blogs.msdn.com/mf/archive/2009/12/16/mfcopy.aspx
[17:29:06] <CIA-7> ffmpeg: bcoudurier * r23157 /trunk/libavformat/mpegts.c:
[17:29:06] <CIA-7> ffmpeg: In ts demuxer, output pes packet as soon as they are complete.
[17:29:06] <CIA-7> ffmpeg: This is needed for subtitles where packets are infrequent.
[17:29:06] <CIA-7> ffmpeg: Patch by Janne Grunau, janne-ffmpeg at jannau dot net.
[17:36:53] <janneg> thanks bcoudurier
[17:40:57] <mt> BBB:  fwiw, samples_per_frame in wma pro isn't per channel. (And there was nothing wrong with *data_size, my brain was just playing tricks on me I guess :) )
[17:42:53] <BBB> ok, great :)
[17:43:17] <BBB> janneg: ping me later today and I might be able to apply for you
[17:43:22] <BBB> give me some time for now
[17:44:47] <janneg> BBB: no hurry, I was going to ping on the ml anyway
[19:17:31] <CIA-7> ffmpeg: cehoyos * r23158 /trunk/ (4 files in 2 dirs):
[19:17:31] <CIA-7> ffmpeg: Factorize some code into the new function ff_toupper4().
[19:17:31] <CIA-7> ffmpeg: Patch by Francesco Lavra, francescolavra interfree it
[19:22:26] <peloverde> Do people have thoughts on the "best" way to handle \0 padded audio packets?
[19:23:01] <peloverde> The situation is pretty common with AAC in ASF
[19:23:21] <peloverde> And Quicktime will the equivalent MP4s
[19:24:21] <CIA-7> ffmpeg: cehoyos * r23159 /trunk/libavformat/utils.c:
[19:24:21] <CIA-7> ffmpeg: Validate AVCodecTag vs CodecID.
[19:24:21] <CIA-7> ffmpeg: Patch by Francesco Lavra, francescolavra interfree it
[19:24:50] <peloverde> I was thinking a "chomp" BSF might be the best approach
[19:25:09] <_av500_> how does it know what to chomp?
[19:25:49] <bcoudurier> hi guys
[19:26:00] <peloverde> chomp a string of zero bytes from the end of the packet until content is hit
[19:26:48] <_av500_> and content can never have a 0?
[19:27:12] <peloverde> An aac frame ends with 0b111 \bytealign
[19:28:39] <_av500_> ic
[19:29:25] <wbs> if a decoder is available, it can return how many bytes it consumed, too, but that's a bit out of place in demuxers
[19:30:54] <peloverde> An ADIF parser could also solve this, but an ADIF parser is basically a full decode and we don't have an ADIF parser
[19:33:52] <CIA-7> ffmpeg: mstorsjo * r23160 /trunk/libavformat/ (sdp.c internal.h):
[19:33:52] <CIA-7> ffmpeg: Make ff_sdp_write_media a lavf-internal function
[19:33:52] <CIA-7> ffmpeg: This is in preparation for RTP hinting in the MOV muxer, where
[19:33:52] <CIA-7> ffmpeg: it needs to be able to create SDP fragments for each media stream.
[19:34:36] <_av500_> adif?
[19:34:47] <_av500_> adif is just a header, no?
[19:35:11] <CIA-7> ffmpeg: mstorsjo * r23161 /trunk/libavformat/ (options.c avformat.h): Add a flag for enabling RTP hinting
[19:35:17] <wbs> _av500_: you might be thinking of ADTS... I think ;P
[19:35:31] <hyc> wbs: since you're tweaking sdp right now....
[19:35:41] <_av500_> no, adts is like mp3 framing
[19:35:49] <_av500_> one header per frame
[19:36:48] <hyc> one of the problems I found with ffserver streaming an flv file is that extradata2psets() doesn't recognize the extradata read from the flv file
[19:37:06] <hyc> the extradata doesn't start with the start sequence
[19:37:14] <peloverde> ADIF is an ASC like header with followed by concatenated RDBs
[19:37:18] <peloverde> no framing
[19:37:30] <hyc> of course ff_h264_decode_init() still handles it just fine
[19:37:38] <wbs> hyc: ok.. no idea about that, I don't know the h264 details too well
[19:38:01] <hyc> i was just in the midst of writing a patch for this when I saw your commit come across
[19:38:10] <wbs> ah
[19:38:16] <wbs> I'm just applying a month old code ;P
[19:38:24] <hyc> i don't know the details too well either, so it's been a slow process
[19:39:34] <CIA-7> ffmpeg: mstorsjo * r23162 /trunk/libavformat/ (movenc.c movenc.h): Move the mov muxer structures to a separate header
[19:40:06] <_av500_> peloverde: you have a sample of aac/h264 in asf somewhere?
[19:40:47] <hyc> if you look at libavcodec/h264.c ff_h264_decode_init() you see two cases. one where the extradata starts with the synch code, and one where it starts with 0x01.
[19:41:07] <CIA-7> ffmpeg: mstorsjo * r23163 /trunk/libavformat/ (movenc.c movenc.h): Make mov_write_packet non-static, add ff_ prefix
[19:41:32] <hyc> for the latter case it sets this flag h->is_avc=1
[19:41:41] <hyc> for the start-sequence case it sets it to 0
[19:41:56] <hyc> of course I have no idea of the significance of any of this...
[19:42:41] <_av500_> hyc: 2 ways of storing the extradata
[19:43:01] <wbs> I think it alters the format of the actual data packets, too
[19:43:19] <peloverde> _av500_: I have a sample, I'm not sure if I can redistribute it
[19:43:19] <wbs> and when packetizing h264 into RTP, it probably assumes either one of the formats
[19:43:48] <hyc> well, I'm going to take a stab at stuffing something in here and seeing if ffplay likes it
[19:43:51] <wbs> it _may_ be possible to alter it from one to another through some bitstream filter
[19:43:54] <wbs> iirc
[19:44:04] <hyc> the start sequence is omitted anyway in the sdp header
[19:44:58] <_av500_> wbs: right, different way to store payload as well
[19:45:03] <wbs> yes, but you may probably want to check what rtpenc_h264.c does, too - "fixing" the SDP in this case probably isn't enough
[19:45:20] <wbs> there's some h264 annex b bitstream filter, it may (or may not) be what you need
[19:48:17] <CIA-7> ffmpeg: mstorsjo * r23164 /trunk/libavformat/ (movenc.c movenchint.c Makefile movenc.h): Add initial support for RTP hinting in the mov muxer
[19:49:20] <CIA-7> ffmpeg: mstorsjo * r23165 /trunk/libavformat/ (movenchint.c movenc.h): Use a heuristic for describing the RTP packets using sample data
[19:53:34] <peloverde> _av500_: h264_aac_zeropad.asf in /incoming
[19:57:51] <_av500_> peloverde: i guess i am unworthy of downloading from there...
[20:18:22] <janneg> bcoudurier: thanks and sorry for the tabs. caused by quickly extending the comment with vim
[20:19:10] <bcoudurier> annoying :)
[20:19:31] <mru> M-x untabify ftw
[20:20:01] <peloverde> :set et:retab
[20:20:49] <drv> to quote the eloquent avcoder: "Dear: The patch is full of TAB"
[20:21:15] * mru likes that quote
[20:21:18] <mru> is it on the wiki?
[20:21:21] <drv> probably not
[20:21:37] <peloverde> file a bug against the wiki :)
[20:22:39] <drv> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-January/059550.html
[20:23:24] <drv> it always makes me think of the soda
[20:23:33] <drv> but i don't know if they even have tab elsewhere
[20:28:30] <mru> you mean the diet coke in a different-coloured can?
[20:28:48] <mru> haven't seen that one in a long time
[20:29:05] <drv> they still make it, just not very common
[20:29:05] <mru> maybe they don't have it here
[20:29:09] <drv> and rather disgusting taste :)
[20:29:23] <mru> diet coke by any other name is still diet coke
[20:29:52] <mru> not as disgusting as vanilla coke though
[20:36:34] <janneg> mru: and then there's Diet Vanilla Coke (http://whyjointhenavy.wordpress.com/2010/02/20/list-of-coca-cola-flavors/)
[20:37:04] <Dark_Shikari> nothing beats pepsi ice cucumber
[20:37:56] <kierank> nothing beats irn bru
[20:38:47] * mru is reminded of some of the more obscure "festis" flavours
[20:38:51] <mru> like "cactus lime"
[20:39:18] <wbs> cactus lime festis is quite good
[20:39:52] <mru> some KTH students invented a few others in Blandaren or another similar-spirited publication
[20:40:00] <mru> one of the best: gädda mango
[20:40:06] <wbs> haha
[20:40:25] <mru> that's a large fish
[20:40:38] <mru> don't know the english name
[20:42:06] <wbs> northern pike
[20:42:32] <mru> and what's english for krongädda?
[20:43:12] <mru> as if they existed
[20:43:50] <janneg> Crown pike
[20:43:57] <mru> yes, that's what google says
[20:45:02] <mru> and it is indeed the literal translation
[20:45:28] <mru> but I'd be surprised if anyone understood it
[20:49:56] <janneg> 442 google results and the top ones don't look related
[20:51:11] <mru> the only first-page hit of relevance refers to the swedish term
[20:54:21] <kierank> whoops
[20:54:28] <mru> nice quit message
[20:54:39] <janneg> swedish wikipedia page has no other language links, and I don't know if there's a german translation
[20:56:54] <ramiro> hm, asf_read_pts() uses variable length arrays... do we have many such functions in ffmpeg?
[20:57:15] <mru> wbs: do you have them in finland or it is a purely swedish thing?
[20:57:37] <mru> ramiro: I'm on a slow crusade against them
[20:59:09] <ramiro> linking on x86_64-w64-mingw32 with some bogus libraries gave me undefined errors for __chkstk() on a bunch of functions.
[20:59:24] <ramiro> that was the first one I checked and it had vla
[20:59:35] <mru> that's a win32 abi thing
[20:59:49] <mru> any function using more than a page of stack has to call it
[21:00:18] <mru> and since a vla might be any size, I guess it gets called there too
[21:00:38] <mru> what runtime were you linking against?
[21:03:00] <ramiro> mingw-w64-crt
[21:03:14] <janneg> mru: one good aspect of C++. VLA are not in the spec. not that it prevents g++ from supporting them but clang++ doesn't
[21:03:17] <ramiro> the default one, -lmsvcrt I guess
[21:03:41] <mru> janneg: but c++ has exceptions, which are every bit as bad
[21:05:08] <janneg> not trying to claim that missing VLA makes C++ bearable
[21:06:46] <mru> we are all doomed: http://gcc.gnu.org/wiki/gcc-in-cxx
[21:09:13] <drv> well, it can barely be worse than the existing "C" source
[21:09:27] <mru> that's the problem
[21:09:54] <mru> if you take C code as found in gcc and convert it to C++, you'll end up with something truly disgusting
[21:10:40] <janneg> lol "C++ is a standardized, well known, popular language." as reason for migrating to c++
[21:11:05] <mru> that page is the most dense collection of lies I've seen since I read xiph.org
[21:11:07] <drv> they already have their own garbage collector/allocator thing
[21:22:20] <CIA-7> ffmpeg: conrad * r23166 /trunk/libavformat/matroskadec.c:
[21:22:20] <CIA-7> ffmpeg: matroskadec: Use av_freep in ebml_read_ascii
[21:22:20] <CIA-7> ffmpeg: Based on a Chromium patch
[21:22:20] <CIA-7> ffmpeg: conrad * r23167 /trunk/libavformat/matroskadec.c:
[21:22:20] <CIA-7> ffmpeg: matroskadec: Ensure time_scale is nonzero, fixes divide-by-zero if the file
[21:22:21] <CIA-7> ffmpeg: has 0 written
[21:22:22] <CIA-7> ffmpeg: Based on a Chromium patch
[21:22:22] <CIA-7> ffmpeg: conrad * r23168 /trunk/libavformat/matroskadec.c:
[21:22:23] <CIA-7> ffmpeg: matroskadec: Fix buffer overread in matroska_ebmlnum_uint
[21:22:23] <CIA-7> ffmpeg: Based on a Chromium patch
[21:22:24] <CIA-7> ffmpeg: conrad * r23169 /trunk/libavformat/matroskadec.c:
[21:22:24] <CIA-7> ffmpeg: matroskadec: Free ebml binary buffer on error
[21:22:25] <CIA-7> ffmpeg: Based on a Chromium patch
[22:09:32] <hyc> hmm. I dunno if there's any way to configure ffserver to insert a bitstream filter
[22:57:12] <Compn> whats chromium doing with mkv input hmmmmm
[22:57:24] <Compn> general purpose html5?
[22:57:30] <Compn> not just h264+mp4 ?
[22:59:17] <Dark_Shikari> it seems someone else spotted it too =p
[22:59:58] <kierank> i wonder if they could make subtitles work too
[23:00:10] <Dark_Shikari> sure, around the time that pigs fly
[23:23:56] <astrange> ask hixie
[23:24:38] <astrange> his current idea for html5 subtitles is srt + some extra styling, the aegisub people are trying to finish an ass successor so it can be submitted instead