[00:03:52] <BrknCodes> Anyone notice that vp6 support is broken on Generic Big Endian machines, since around Christmas 2009? [00:04:01] <BrknCodes> (decode) [00:04:34] <DonDiego> generic as in? [00:04:37] <DonDiego> sample? [00:04:47] <BrknCodes> as in (powerPC, no altivec) [00:05:09] <BrknCodes> as in (MIPS BE, NXP 8635) [00:05:18] <DonDiego> hmm [00:05:23] <kierank> let google fix the bugs ;) [00:05:31] <DonDiego> i have a g4, i could test [00:05:33] <BrknCodes> same issue in both CPU's [00:05:42] <BrknCodes> G4 has an altivec... [00:06:05] <BrknCodes> STB4100 however does not [00:06:40] <BrknCodes> neither does IBM STB 250 [00:07:18] <DonDiego> sample? [00:07:28] <BrknCodes> define sample please [00:07:46] <DonDiego> sample == file that triggers the problem [00:07:49] <BrknCodes> yes [00:07:53] <BrknCodes> where to upload? [00:07:59] <DonDiego> incoming [00:08:00] <BrknCodes> want on tinyupload.com? [00:08:01] <DonDiego> or wait [00:08:29] <DonDiego> http://samples.ffmpeg.org/V-codecs/VP6/ [00:08:31] <DonDiego> first [00:08:44] <DonDiego> see if one of the ones we already have triggers it as well [00:09:21] <BrknCodes> I will test predator2_vp6HuffyYuv [00:09:46] <BrknCodes> will take less than 3 mins [00:09:53] <DonDiego> os x or linux? [00:10:26] <mru> vp6 is fine here: http://fate.multimedia.cx/index.php?build_record=232160 [00:10:28] <BrknCodes> baremetal [00:10:37] <mru> that BE with no special asm [00:11:29] <mru> pa-risc is BE too [00:11:48] <mru> and sparc of course [00:13:06] <BrknCodes> problem that occurs, is that it destroys all the intra frames, causing "bleeding" and color effects [00:13:49] <BrknCodes> it runs, just fine, however, it is unwatchable, except for a few frames after each keyframe [00:14:21] <BrknCodes> dont know if this would be detected by the FATE system? [00:15:00] <mru> fate verifies a checksum of the decoded frames [00:16:47] <BrknCodes> so, is there a "recomended" config for my SOC that will curb this effect? or should I go back to #ffmpeg? [00:17:05] <mru> I'm not aware of a bug [00:17:30] <BrknCodes> if I assumed you were aware, mru, I would not be here trying to report it :) [00:17:42] <Compn> BrknCodes : run the make test or whatever that fate runs to verify vp6 [00:17:49] <BrknCodes> miss talking to you on #beagle [00:17:52] <mru> I played several vp6 files on x86 a couple of days ago, and they all seemed fine [00:18:05] <BrknCodes> x86 is not generic, nor is it BE [00:18:29] <mru> what I mean is that vp6 decoding seems ok there at least [00:18:47] <mru> and fate hasn't complained [00:19:13] <mru> it's possible of course that the samples tested there don't trigger the bug [00:19:21] <lu_zero> you can run make test on your bare metal? [00:19:32] <BrknCodes> no, I cannot [00:19:48] <mru> hold on, I'll do a no-asm build on ppc and check [00:20:11] <BrknCodes> is there a configure option for no-asm? [00:20:18] <mru> --disable-asm [00:20:34] <BrknCodes> although, I dont see any asm in vp6.c, or vp56.c [00:20:44] <mru> you wouldn't [00:21:05] <mru> they use the vp3 idct [00:21:10] <mru> which does have asm versions [00:24:39] <DonDiego> seems to work fine here with altivec.. [00:27:05] <BrknCodes> DonDiego Look above, I said "Without Altivec" [00:27:26] <BrknCodes> :D [00:29:24] * Dark_Shikari is headdesking [00:29:31] <Dark_Shikari> reading the A119 h265 proposal software here [00:29:39] <Dark_Shikari> it has a separate copy-pasted function for every single block size comparison [00:29:44] <Dark_Shikari> i.e. sad 16x16, 16x8, 8x16... [00:29:44] <BrknCodes> I have been bashing my head for 8 days over this issue [00:29:49] <Dark_Shikari> every single one has a 10 line function header comment [00:29:54] <Dark_Shikari> i.e. function, purpose, input, return, parameters [00:30:02] <Dark_Shikari> yes, every single one has a separate "purpose" line [00:30:08] <Dark_Shikari> and it goes on and on and on and *GAH* [00:30:08] <mru> corporate policies gone mad [00:30:10] <BrknCodes> umm [00:30:58] <Dark_Shikari> here's a good one [00:31:07] <Dark_Shikari> http://pastebin.org/289029 [00:31:10] <Dark_Shikari> explain to me what "FAST_MODE" does. [00:31:34] <Dark_Shikari> and what kind of drugs the author of this function is on. [00:31:52] <BrknCodes> Item: Bicycle Fuction: Mode of Transportation Purpose: Get ya there with no fuel Input: Pedals Return: Forward Motion Input: Steering bar (Handlebar Struct) [00:32:24] <kierank> Dark_Shikari: LOL [00:32:57] <Dark_Shikari> FAST_MODE [00:33:02] <kierank> who needs SIMD when you can have FAST_MODE [00:33:03] <BrknCodes> fast mode is 64+64 iterations, non is 64*64 iterations [00:33:03] <mru> copy the line out before calculating the sad? [00:33:05] <mru> wtf? [00:33:48] <Dark_Shikari> some of them use memcpy! [00:33:54] <BrknCodes> so, 128, or 4096, pick and choose [00:34:02] <kierank> "Clean and fast software written from scratch using C" [00:34:04] <mru> BrknCodes: what are you talking about? [00:34:13] <Dark_Shikari> kierank: is that an actual quote? [00:34:14] <mru> both calculate the same thing [00:34:21] <mru> FAST_MODE with an extra "memcpy" [00:34:43] <kierank> yes from the powerpoint [00:34:55] <Dark_Shikari> LOL [00:35:05] <DonDiego> BrknCodes: can you reproduce with one of our samples? [00:35:15] <mru> fate passes w/o asm on my ppc [00:35:16] <BrknCodes> umm, fast_mode appears to take longet to me, iteratively [00:35:34] <Dark_Shikari> THATS THE POINT [00:37:14] <kierank> disappointingly they've left track changes on the proposal documents but there doesn't seem to be a history [00:37:56] <BrknCodes> test samples work [00:38:38] <BrknCodes> my test.flv, however does not, and I have several samples which dont [00:38:45] <BrknCodes> some AVI, some FLV [00:38:52] <mru> upload one [00:38:58] <BrknCodes> link for upload? [00:39:32] <bcoudurier> why doesn everybody misinterpret bt601/709 and full/normal range yuv [00:39:43] <mru> upload.ffmpeg.org [00:39:48] <BrknCodes> found upload.ffmpeg.org [00:39:54] <mru> bcoudurier: because they know nothing about the subject [00:40:45] <bcoudurier> yeah, and somebody will blog crap and it will get worse [00:41:45] <BrknCodes> uploading test.flv [00:41:57] <BrknCodes> 9 years, 37 days remaining [00:42:46] <Dark_Shikari> oh wow. the comments are mispelled too [00:42:52] <Dark_Shikari> "Check whetehr SVT mode should be skipped" [00:43:23] <BrknCodes> LOL [00:44:40] <BrknCodes> 4 years remaining [00:45:51] <hyc> wbs: you don't happen to have a copy of iSO/IEC 14496-10:2005 online too do you? [00:46:16] <mru> hyc: why such an old version? [00:46:20] <Dark_Shikari> here's another great representative 5 lines from the A119 software [00:46:21] <Dark_Shikari> { [00:46:22] <Dark_Shikari> { [00:46:23] <Dark_Shikari> { [00:46:27] <Dark_Shikari> (two extra line breaks omitted) [00:46:34] <hyc> mru: I guess the particular version doesn't matter [00:46:51] <hyc> I was just trying to understand the format of sps/pps encoded in SDP sprop-parameter-sets [00:48:09] <mru> http://www.itu.int/rec/T-REC-H.264-200903-S/en [00:48:15] <mru> grab your free copy there [00:48:29] <hyc> ah found it. 03/09 ? [00:49:45] <hyc> mru: thanks [00:50:03] <BrknCodes> file uploaded, in incoming folder, "test.flv" [00:50:05] <hyc> so it looks like sprop-parameter-sets is SPS,PPS [00:50:25] <BrknCodes> works fine on x86, fails on every generic BE machine I have here [00:50:43] <hyc> if a stream has multiple spss then they should all be concatenated into that first part? [00:50:45] <BrknCodes> which is 6 different machines, including 3 Mips BE [00:51:37] <kierank> Dark_Shikari: mixed tabs and spaces all over the place too [00:52:22] <kierank> eugh and random unformatted tables [00:54:21] <DonDiego> BrknCodes: test.flv is not exactly a great name.. [00:56:11] <BrknCodes> ok [00:56:47] <DonDiego> please either use a name that describes the problem or the sample [00:58:29] <lu_zero> hyc: you might also send them inline [00:58:42] <hyc> is there a sample H.264 file with multiple SPSs and/or PPSs? Most of the ones I've seen have only 1 of each [01:00:39] <BrknCodes> uploading "vp6_intra-frame_fail_BE_Generic.flv" [01:00:51] <mru> you don't need to upload another [01:01:03] <BrknCodes> he told me to rename, cannot rename [01:01:05] <mru> and I can't reproduce the problem [01:01:08] <hyc> lu_zero: just trying to make sure when I encode an AVC extradata in rtpenc_h264.c that it still makes sense [01:01:12] <BrknCodes> Canelled [01:01:24] <mru> still no need to upload several copies of the same file [01:01:30] <BrknCodes> gotcha [01:01:42] <BrknCodes> next time, I name correctly before to make upload [01:02:11] <mru> however, I still can't reproduce the error [01:02:30] <BrknCodes> shame [01:02:47] <mru> which means pebkac for you [01:02:54] <mru> most likely [01:02:55] <BrknCodes> STB4100 is based on PowerPC 750CL [01:03:03] <BrknCodes> all other codecs work fine [01:03:11] <mru> ppc is ppc [01:03:13] <lu_zero> mru: do not factor out the compiler [01:03:21] <mru> I used gcc 4.3 [01:03:31] * lu_zero still reminds some funny typos in the ancient ones... [01:03:32] <BrknCodes> I am using gcc 4.4.3 [01:04:04] <BrknCodes> same issue on 4.4.2 [01:04:18] <lu_zero> cflags? [01:04:36] <mru> defaults I hope [01:04:41] <mru> otherwise he's wasting our time [01:05:31] <hyc> hmm. av_base64_encode() ought to return pointer to end, not pointer to beginning of output [01:05:45] <hyc> you passed in the pointer to out, you don't need it back again [01:06:19] <hyc> returning the pointer to end of output would let callers calculate len without wasting a call to strlen() [01:07:19] <BrknCodes> -MD -MP -Wstrict-prototypes -Wmissing-prototypes -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -mpaired -ffast-math -I. -Wdeclaration-after-statement -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -g -O3 -pipe -mrvl -mcpu=750 -mtune=750 -meabi -mhard-float [01:07:49] <mru> that doesn't look like our flags [01:07:59] <mru> works with 4.4.3 here [01:08:14] <mru> so WHY DID YOU MESS WITH THE FLAGS? [01:08:32] <BrknCodes> will not build for my baremetal without them [01:08:40] <mru> of course it will [01:08:47] <mru> get rid of -ffast-math to begin with [01:08:54] <BrknCodes> no help [01:08:59] <mru> and put back -fno-tree-vectorize [01:09:07] <BBB> we need this on the quotes page [01:09:30] <mru> I see nothing funny [01:12:08] <mru> and what's -mrvl? [01:12:41] <BrknCodes> Broadway, testing on Wii, cuz is closest to the board, without having to TFTP [01:12:55] <mru> uh? [01:13:24] <BrknCodes> -mrvl, enables wii linking [01:13:28] <BrknCodes> nm [01:13:31] <BrknCodes> not important [01:13:37] <mru> you don't know that [01:13:51] <BrknCodes> dont know what "not important" [01:13:53] <BrknCodes> ?? [01:14:00] <j0sh_> lu_zero: how should the client specify they want tunnelled http? do we need a new option for that? [01:14:01] <mru> obviously you don't [01:14:07] <mru> if you did, you'd have fixed it by now [01:14:22] <BrknCodes> ok... [01:14:35] <AbuseMePls> is that better? [01:15:05] <mru> good riddance [01:15:44] <BBB> j0sh_: same as ?tcp or ?udp [01:15:47] * lu_zero abusemepls please also drop -mpaired [01:15:48] <BBB> ?http would be good [01:15:57] <lu_zero> sad but true =_= [01:15:58] <mru> lu_zero: he ran away [01:16:14] <lu_zero> mru: and I mistyped [01:16:20] * lu_zero feels sleepy [01:16:21] <mru> I have no desire to help people who insist on stupid cflags [01:16:24] <kierank> i wonder what he's up to doing vp6 on the wii [01:16:26] <DonDiego> gnite [01:16:41] <mru> I had enough when a customer insisted we use -mbig-endian -mlittle-endian [01:16:48] <mru> or something like that [01:16:59] <lu_zero> mixedendian missing? [01:17:32] <lu_zero> on 64bit would it cause have the first 32bit big and the second little? [01:17:38] <mru> I asked which one was correct, they said we were to use both [01:17:41] <mru> we did, it broke [01:17:51] <hyc> lol [01:17:55] <lu_zero> that's evil =P [01:17:58] <hyc> The Customer Is Always Wrong [01:18:01] <mru> but which order would the high/low words have? [01:18:23] <Dark_Shikari> so mru [01:18:31] <lu_zero> probably they had a cpu that worked better as le and one as be of the same arch ^^; [01:18:37] <Dark_Shikari> we need to decode 1024x768 video on an ipad in about 23ms or less in motion [01:18:41] <Dark_Shikari> i.e. not with a static screen [01:18:50] <Dark_Shikari> Sorenson FLV1 takes about ~34ms with ffmpeg in motion [01:19:03] <Dark_Shikari> so my next challenge is to hack it until it takes less than 23ms [01:19:07] * Kovensky wonders how many WTFs are on TDWTF's source code [01:19:11] <mru> find something that's close and optimisable, then throw me some cash ;-) [01:19:12] <Dark_Shikari> Besides swapping out the transform, any ARM-specific optimizations you can think of? [01:19:25] <Dark_Shikari> i.e. modifying the video format to make it faster. [01:19:47] <lu_zero> that cpu doesn't have any accelerator you could use beside relying on neon? [01:19:57] <mru> lu_zero: not accessible [01:20:07] <lu_zero> neon or the accelerators? [01:20:10] <Dark_Shikari> latter [01:20:11] <mru> accels [01:20:16] <Dark_Shikari> we may get it in time [01:20:18] <Dark_Shikari> But not fast enough. [01:20:23] <Dark_Shikari> er, not soon enough [01:20:53] <mru> do you have a sample file? [01:20:59] <mru> I can do a quick profile [01:21:13] <Dark_Shikari> one moment [01:21:40] <lu_zero> the gpu could be abused ? [01:22:30] <Dark_Shikari> that would be a ton of owrk [01:23:45] <lu_zero> the color conversion/scaling is already managed through the native scaler? [01:24:00] <Dark_Shikari> we do it in opengl [01:24:01] <Dark_Shikari> yes [01:24:04] <Dark_Shikari> mru: http://x264.nl/developers/Dark_Shikari/output.flv [01:24:08] * mru thinks people should learn to see in yuv [01:24:20] <Dark_Shikari> That's a representative "hard" sample [01:24:30] <ohsix> braintap yub [01:24:33] <Dark_Shikari> i.e. "this is the hardest footage we will have to handle in realtime" [01:24:37] <Dark_Shikari> It's not the right resolution but whatever [01:24:49] <lu_zero> so you already are using some of the gpu [01:25:56] <Dark_Shikari> yeah, but that's easy [01:32:19] <kierank> could an ARM926 decode 700kbps h.264? [01:32:39] <kierank> i'm wondering how iplayer wii manages to decode 700kbps h.264 [01:32:52] <mru> no way [01:33:15] <mru> probably has some hardware support [01:33:17] <Dark_Shikari> yes, hardware [01:33:21] <Dark_Shikari> wii doesn't even have altivec [01:33:42] <Dark_Shikari> got a profile yet? [01:33:50] <kierank> because the bbc blog post says it was done on the cpu and 700kbps was their upper limit and they tweaked their encoding profile [01:34:03] <mru> Dark_Shikari: yeah [01:34:09] <mru> idct is quite a bit [01:34:18] <Dark_Shikari> link? [01:34:19] <mru> and dequant [01:34:32] <Dark_Shikari> interesting that _dequant_ is a lot [01:35:10] <mru> yeah, it's usually much less [01:37:11] <Dark_Shikari> ... link? [01:37:22] <mru> to what? [01:37:53] <Dark_Shikari> the profile [01:38:41] <mru> http://pastebin.com/WftRrss8 [01:39:09] <Dark_Shikari> armv5te?!?! [01:39:13] <mru> what weird settings did you encode with? [01:39:22] <Dark_Shikari> -B 6000000 [01:39:26] <Dark_Shikari> er, -b [01:39:26] <mru> that function is usualy insignificant [01:39:35] <Dark_Shikari> why would it be insignificant? [01:39:38] <Dark_Shikari> it's run before every single idct [01:39:45] <mru> <1% is insignificant [01:39:51] <Dark_Shikari> that sounds like your bitrate is really low [01:40:02] <Dark_Shikari> 13%+ spent on dequant is huge [01:40:06] <mru> yes [01:40:07] <Dark_Shikari> you think you could make that faster in neon? [01:40:10] <mru> never seen that before [01:40:15] <mru> I'll try a neon version [01:40:21] <mru> should be easy [01:40:22] <Dark_Shikari> should be easy, yeah [01:40:24] <Dark_Shikari> quant is trivial [01:40:43] <Dark_Shikari> amazing how much idct uses up [01:40:51] <Dark_Shikari> how much faster would h264 idct be? [01:41:06] <mru> quite a bit I imagine [01:41:23] <mru> the mpeg2/4 idct has to use 32-bit maths [01:41:35] <mru> and multiplication [01:41:49] <Dark_Shikari> like, 2x? 3x faster? [01:42:12] <mru> I honestly don't know [01:42:19] <Dark_Shikari> k [01:44:39] <kierank> interesting...the wii has it's own video format as well [01:44:51] <mru> wiideo [01:45:49] <Dark_Shikari> so lets see here [01:46:10] <Dark_Shikari> 11.87% + 7.93% + 5.8% + 3.69% + 2.81% + 2.15% [01:46:11] <Dark_Shikari> holy crap [01:46:19] <Dark_Shikari> 35% of time is the idct. [01:46:32] <Dark_Shikari> what's put_dct? [01:46:35] <mru> it's usually <20% [01:46:45] <mru> I don't know what put_dct is [01:46:46] <Dark_Shikari> yeah, it's because every single block has a residual [01:46:49] <Dark_Shikari> EVERY single block [01:47:08] <Dark_Shikari> due to high motion [01:47:20] <mru> I should go back over that dct, maybe there's something I can improve [01:49:07] <Dark_Shikari> Yeah, 35% of time seems unreasonably high [01:49:16] <Dark_Shikari> though I guess multiplies suck on neon [01:49:23] <Dark_Shikari> what's the latency/throughput like on typical 32-bit multiplies? [01:49:26] <mru> they should all be 16x16 [01:49:30] <mru> with 32-bit result [01:49:50] <Dark_Shikari> so what's latency/throughput on those [01:50:33] <mru> 5/1 [01:50:42] <Dark_Shikari> that sounds like a bitch to schedule [01:50:49] <mru> it is [01:51:19] <mru> as I said, I might revisit the idct [01:51:40] <Dark_Shikari> what are the different parts for? [01:51:42] <Dark_Shikari> e.g. "pld" [01:52:04] <mru> I don't remember [01:52:14] <Dark_Shikari> heh, so a while ago then. [01:52:20] <mru> 2 years [02:42:48] <kierank> oooh, found the wii h.264 decoder binary [02:46:07] <kierank> interesting string: "MATSUSH.ITA_H264.DECODER" [02:49:07] <Dark_Shikari> interesting [02:50:11] <kierank> dunno how to dissasemble it though [02:52:00] <ShadowJK> panasonic? [02:52:44] <kierank> matsushita became panasonic [03:14:05] <kierank> it seems to have debug symbols too [03:16:26] <Dark_Shikari> o.0 [03:17:57] <kierank> there's a lot of mentions of words relating to h.264 decoding like: coeff, transform, vui, baseline [03:18:42] <Broken> btw, mru, those didn't help [03:19:11] <Broken> -fno-tree-vectorize and removing -ffast-math [03:19:18] <kierank> Broken: do you know what an rso file is? [03:19:19] <mru> use default flags [03:19:23] <kierank> (off-topic) [03:19:24] <Broken> I cannot [03:19:27] <mru> why? [03:19:28] <Broken> will not compile [03:19:30] <mru> why? [03:19:40] <Broken> you ask me why [03:19:49] <mru> it's your job to find out [03:19:53] <Compn> paste errors [03:19:57] <Compn> or we cant guess [03:20:01] <Broken> by default flags, what do you mean? the ones generated by the configure script? [03:20:04] <mru> yes [03:20:26] <Broken> mp_fifo.c fails to compile, showing like 80 pages of errors [03:21:54] <Broken> btw, yes, its a mplayer compile, but the error is relegated to libavcodec [03:22:08] <Broken> which as I understand is ffmpeg [03:22:15] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaahh [03:22:35] <Broken> gaaawhat? [03:22:48] <Compn> lol. [03:23:06] <Compn> mplayer compilation is different than ffmpeg [03:23:14] <Broken> yippee [03:23:17] <Compn> no matter how much mplayer uses ffmpeg... [03:23:22] <Broken> k [03:23:39] <Compn> sometimes mplayer is broken , because of changes to ffmpeg and mplayer hasnt been updated yet [03:23:49] <Broken> so, do I need to go beg someone in #mplayer ? [03:24:08] <Compn> you need to paste your errors to pastebin.com so #mplayer people can help you, yes [03:24:14] <Broken> errm [03:24:32] <Broken> there are no errors, just incorrect playback of vp6 [03:24:57] <Compn> i forgot to mention that i hit those vp6 errors too [03:25:23] <mru> Compn: then maybe _you_ can explain what you did and why [03:25:44] <Compn> i'm pretty sure i filed a report [03:25:45] * Compn looks [03:26:06] <Broken> and I'm not the only one with the issue, wiimc, has the issue, as well as mplayer-CE for Wii, and the recent NXP release of the NXP 8635 (based on ffmpeg march release) [03:26:20] <Compn> http://roundup.ffmpeg.org/issue182 [03:26:43] <Compn> http://roundup.ffmpeg.org/issue708 [03:26:48] <mru> Broken: all of those are full of hack [03:26:51] <mru> we can't support them [03:27:04] <Compn> http://roundup.ffmpeg.org/issue965 [03:27:38] <Compn> there, three vp6 bleeding problems [03:27:48] <Broken> mru, this doesn't explain why building ffmpeg, and using the compiled static lib gives the exact same issue [03:28:09] <mru> using broken flags breaks build [03:29:00] <Broken> awesome [03:29:21] <Broken> so, icanhas working flags, and know the taboo ones? [03:29:34] <mru> configure sets good flags [03:29:37] <mru> don't screw with them [03:29:38] <Broken> ... [03:29:48] <mru> if that doesn't work, we can start talking [03:30:07] <Broken> okie dokie [03:30:13] <Broken> see you in 18 minutes [03:30:15] <Compn> mru : bcoudurier at least confirmed this bleeding vp6 bug > http://roundup.ffmpeg.org/issue965 [03:30:26] <mru> yes, I see it too [03:30:29] <Compn> :P [03:30:34] <mru> probably a different issue [03:30:43] <Broken> or the same issue [03:30:45] <Broken> ... [03:30:50] <mru> Broken: your file plays perfectly [03:30:53] <mru> ergo, not same [03:31:24] <Compn> where is Broken's file ? [03:31:28] * Compn wants to checks :) [03:31:41] <Compn> incoming? [03:31:42] <mru> incoming/test.flv [03:31:44] <Compn> oo [03:31:45] <mru> yeah, great name [03:31:50] <Broken> if by perfectly, you mean the screen tears all to hell, and blocks get misdecoded, then sure, it plays perfectly, and PC gets it wrong by making intelligible video, without nasty artifacting [03:32:02] <mru> I mean I can watch a family guy clip [03:32:12] <Broken> so can I [03:32:15] <mru> if it was meant to be some other show, well... then we have a problem [03:32:29] <Compn> Broken : just relax, some bugs arent found on all systems [03:32:35] <Compn> and this one is one of those :) [03:32:51] <Compn> just because mru cant reproduce, doesnt make it any less of a bug [03:32:55] <Broken> its the entire show after the first commercial, and on mplayer PC, it looks beutiful [03:33:18] <mru> I built ffmpeg on ppc w/o altivec [03:33:23] <mru> perfect decode [03:33:31] <Broken> on PowerPC 750CL, not perfect decode [03:33:36] <Compn> mru : --disable-optimizations? -O0 ? [03:33:37] <mru> ppc is ppc [03:33:45] <mru> Compn: --disable-asm [03:33:53] <Broken> I cannot configure [03:34:07] <Compn> Broken : ffplay gives the same artifacts ? [03:34:15] * Compn cant remember if he tested ffplay or not [03:34:30] <Broken> cannot test, ffplay is not part of mplayer [03:35:02] <Compn> you know this is the ffmpeg channel right ? you should test with ffmpeg/ffplay if you want to report bugs here [03:35:31] <Broken> I compiled libavcodec from ffmpeg sources, and used directly, accomplished same error [03:37:01] <Broken> mru, if you want to pastebin the resulting Makefile, and config.mak, so I can compare, that might be helpful [03:38:47] <Broken> if you wonder why I cannot run configure, open NXP's SDK, and try typing ./configure [03:39:01] <Broken> fun time converting the configure script... fun fun fun [03:39:16] <mru> what has an nxp sdk got to do with ffmpeg? [03:39:25] <Broken> errm [03:39:39] <Broken> thats what I'm trying to get results with? [03:39:47] <mru> so? [03:39:54] <Broken> and it worked perfectly before november 2009 [03:40:00] <mru> you must have a compiler for the target system [03:40:04] <Broken> yep [03:40:07] <mru> use that with the normal ffmpeg configure script [03:40:16] <Broken> mru [03:40:30] <Broken> there is no shell in the sdk from our nice frinds at nxp [03:40:39] <mru> wtf are you babbling about? [03:40:48] <mru> does your system not come with a shell? [03:41:02] <Broken> typing ./configure into it results in 4 beeps, and the edit window opening [03:41:13] <mru> typing into WHAT? [03:41:14] <Broken> yes, cmd prompt [03:41:22] <mru> do you have a linux system with xterm and bash? [03:41:31] <Broken> yes [03:41:53] <mru> and it can't run the ffmpeg configure script because you _also_ have an unidentified sdk somewhere on the system? [03:42:06] <Broken> no [03:42:11] <mru> what then? [03:42:17] <Broken> the linux system is another computer altogether [03:42:27] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah [03:42:58] <Broken> the nxp SDK is a crappy windows based tool [03:43:04] <mru> so don't use it [03:43:12] <Broken> fun [03:43:35] <Broken> apps built with the gcc cross compile dont load [03:43:56] <mru> maybe you should get a working compiler _before_ trying to build ffmpeg [03:44:06] <Broken> i have a working compiler [03:44:07] <Broken> and [03:44:11] <mru> evidently not [03:44:16] <Broken> it worked fine before November 2009 [03:44:27] <mru> < Broken> apps built with the gcc cross compile dont load [03:44:37] <mru> that's not working [03:44:40] <Broken> umm [03:45:01] <Broken> THE NXP SDK worked fine, with ffmpeg sources from BEFORE November 2009 [03:45:32] <mru> not my fault [03:45:45] <Broken> I never said it WAS your fault [03:47:06] <Broken> My indication, in all of these matters was, a) there is a known issue with vp6, confirmed by another, b). it did not exist locally before November 2009, c) you indicate its a CFLAG problem, d). I have asked to see your CFLAGS, and e). we seems to speak different versions of english, [03:47:47] <mru> I have yet to hear two consistent statements from you [03:47:55] <mru> therefor, I give up [03:48:07] <Broken> awesome, show me 2 conflicting statements pls [03:48:13] <mru> scroll up [03:48:24] <Broken> I have [03:48:28] <mru> why don't you track down the commit that broke it instead? [03:48:41] <Broken> I have been present in all of the conversation, between you, and myself [03:49:25] <Broken> according to you its not broken, so that (according to you) would be a complete waste of time [03:49:56] <mru> it's not broken here [03:50:03] <mru> and I can't fix what ain't broken [03:50:18] <Broken> true, its not broken in alot of places, that does not disprove the issue [03:50:29] <mru> _if_ there is a bug, it's more restricted than "all big-endian" [03:51:17] <Broken> I never said "all big endian" I said "General Big Endian" meaning CPU set to General, and Endianness set to BIG_ENDIAN [03:51:33] <mru> what's the difference? [03:51:44] <mru> and where do you set the cpu to "general" [03:51:45] <mru> ? [03:51:46] <Broken> yet, I have asked to see your cflags, and we are arguing about what I did not say [03:51:53] <mru> that's not an option in our configure script [03:52:00] <Broken> nope, its not [03:52:15] <mru> CFLAGS= -mcpu=7450 -mpowerpc-gfxopt -std=c99 -fomit-frame-pointer -maltivec -mabi=altivec -g -Wdeclaration-after-statement -Wall -Wno-switch -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wno-pointer-sign -Wcast-qual -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=implicit -Werror=missing-prototypes [03:52:34] <mru> we only support builds made with our build system [03:52:40] <Broken> hi [03:52:46] <mru> hi? [03:52:47] <Broken> Can you test without altivec? [03:52:59] <mru> that is wihtout altivec [03:53:10] <Broken> -maltivec -mabi=altivec [03:53:17] <Broken> is not without altivec [03:53:50] <mru> the actual altivec code is still disabled [03:54:14] <Broken> then it wouldn't hurt to test without altivec now would it? [03:54:22] <mru> I DID [03:54:42] <mru> now you claim to have one version of the source that works and one that doesn't [03:54:53] <mru> it's your job to find out exactly which revision "broke" it [03:55:02] <mru> until you do, I'm not saying another word [03:55:09] <mru> I might, however, kick you [03:56:02] <Broken> according to our nice friends at gcc, -mabi=altivec means "generate AltiVec code wherever possible". [03:57:02] <Broken> no need to kick me, this river is very deep, denial solves nothing [03:57:12] <saintdev> lol [05:05:48] <j0sh_> is there a reason some internal functions are prefixed ff_ and others are not? [05:08:30] <jai> non-static functions not part of the public api -> ff_ [05:14:04] <j0sh_> alright [07:29:24] <CIA-93> ffmpeg: kostya * r23370 /trunk/libavcodec/vc1dec.c: [07:29:24] <CIA-93> ffmpeg: 321l: do not use shifted s->linesize instead of correct s->uvlinesize. [07:29:24] <CIA-93> ffmpeg: This should fix chroma issues in WMV3/VC-1 decoder with avfilter enabled. [09:41:14] <CIA-93> ffmpeg: diego * r23371 /trunk/configure: [09:41:14] <CIA-93> ffmpeg: Require --enable-nonfree flag for libvpx. [09:41:14] <CIA-93> ffmpeg: The license of libvpx is incompatible with the (L)GPL. As long as this is [09:41:14] <CIA-93> ffmpeg: the case, the only way to use it is by marking the result as nonfree. [09:43:26] <lu_zero> 05:52 <@mru> the actual altivec code is still disabled [09:43:38] <lu_zero> with -O3 the autovectorizer kicks in [09:44:42] <lu_zero> but I read -fno-tree-vectorize that makes the point moot [11:44:15] <superdump> mru: ping? [12:03:31] <mru> superdump: pong [12:04:11] <superdump> i'm having trouble with shared library symbol resolution in debian unstable 64-bit when using stuff installed to /usr/local but only with ffmpeg [12:04:30] <superdump> i'm wondering if the build system is doing something that debian is finding unusual [12:04:33] <mru> sounds like a debian problem [12:04:51] <superdump> ldconfig -v shows /usr/local/lib is listed first [12:05:00] <superdump> and libx264.so.96 is found in there [12:05:47] <superdump> but when i build ffmpeg against libx264, it seems the one from /usr/lib gets picked up [12:06:03] <mru> why do you have two of them? [12:06:03] <superdump> and i can't remove that because i want some of the other dependencies [12:06:13] <siretart> wtf? x264 is at soname 96 already?! [12:06:17] <mru> --extra-ldflags=-L/usr/local/lib [12:06:57] <superdump> hmm, someone just said ldconfig and gcc/ld resolution order have nothing to do with each other - why? [12:07:04] <superdump> and i'll try that [12:07:05] <mru> that's how it is [12:07:10] <superdump> ok [12:07:39] <mru> you can also set LIBRARY_PATH to a list of directories to search before the standard ones [12:08:12] <superdump> LIBRARY_PATH or LD_LIBRARY_PATH? [12:08:26] <mru> LD_LIBRARY_PATH is for the dynamic linker at runtime [12:08:31] <superdump> that worked, thank you [12:09:54] <mru> btw, lol @ dilbert [13:12:10] <CIA-93> ffmpeg: siretart * r23372 /branches/ (0.6 0.6/libavcodec/audioconvert.h): [13:12:10] <CIA-93> ffmpeg: Fix documentation of av_audio_convert. [13:12:10] <CIA-93> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net [13:12:10] <CIA-93> ffmpeg: backport r23285 by cehoyos [13:12:48] <CIA-93> ffmpeg: siretart * r23373 /branches/ (0.6 0.6/libavformat/utils.c): [13:12:49] <CIA-93> ffmpeg: Display a more descriptive log message when probe buffer limit is [13:12:49] <CIA-93> ffmpeg: reached. [13:12:49] <CIA-93> ffmpeg: backport r23288 by jai_menon [14:04:01] <CIA-93> ffmpeg: siretart * r23374 /branches/ (8 files in 4 dirs): [14:04:01] <CIA-93> ffmpeg: VP8 decoding via libvpx [14:04:01] <CIA-93> ffmpeg: Patch by James Zern for Google, Inc., jzern google com [14:04:01] <CIA-93> ffmpeg: backportd r23191,23303,23307-23308 by conrad, cehoyos and mstorsjo [14:05:53] <CIA-93> ffmpeg: siretart * r23375 /branches/ (0.6/doc/general.texi 0.6): [14:05:53] <CIA-93> ffmpeg: Fix VP8 listing in general.texi [14:05:53] <CIA-93> ffmpeg: backport r23306 by mstorsjo [14:11:52] <CIA-93> ffmpeg: siretart * r23376 /branches/ (0.6/libavformat/matroska.c 0.6): [14:11:52] <CIA-93> ffmpeg: matroska: Add V_VP8 [14:11:52] <CIA-93> ffmpeg: Patch by Google [14:11:52] <CIA-93> ffmpeg: backport r23192 by conrad [14:11:54] <siretart> \o/ - with this patch, 0.6 can finally and properly playback the elephants dream! [14:12:12] <J_Darnley> Don't forget the non-free [14:12:28] <siretart> I'll discuss that with diego [14:12:57] <siretart> any other backport candidates? - last nominations? [14:13:33] <ramiro> are we still waiting for libvpx encoding? [14:13:47] <siretart> good question. [14:13:59] <ramiro> that would be nice [14:14:07] <siretart> I guess playback is way more important, given that the encoders are probably in flux for quite some time [14:14:17] <siretart> or do you mean encoding support for libvpx? [14:14:19] <peloverde> there should be no release without vpx "non-free" or (L)GPL compatible libvpx imho [14:14:27] <mru> how evil is it to hardcode struct offsets in asm? [14:14:47] <ramiro> mru: michael seems to not mind (look at swscale_internal.h) [14:14:50] <peloverde> mru, if you have to do it, put a note in the struct [14:15:15] <mru> it's the h263 dequant functions [14:15:27] <mru> they use a bunch of fields in MpegEncContext [14:16:07] <mru> ramiro: swscale would not pass review today [14:16:14] <ramiro> heh, that's true... [14:16:29] <ramiro> specially with the "do not commit unrelated things on the same commit" [14:16:38] <ramiro> rule [14:19:28] <peloverde> I would object to any new toplevel repository included via svn:externals :) [14:20:56] <CIA-93> ffmpeg: siretart * r23377 /branches/ (0.6/libavcodec/api-example.c 0.6): [14:20:57] <CIA-93> ffmpeg: api-example: Try to avoid decoding incomplete frames [14:20:57] <CIA-93> ffmpeg: Use a larger input audio buffer, refill it when it has less than 4 KB data [14:20:57] <CIA-93> ffmpeg: left. [14:20:57] <CIA-93> ffmpeg: backport r23323 by mstorsjo [14:25:07] <j-b> no backport of non-free? [14:26:20] <CIA-93> ffmpeg: siretart * r23378 /branches/ (0.6 0.6/libavcodec/h264_ps.c): [14:26:20] <CIA-93> ffmpeg: Check for VUI overeading and reset num_reoder_frames. [14:26:20] <CIA-93> ffmpeg: This helps the video from issue1831 [14:26:20] <CIA-93> ffmpeg: backport r23328 by michael [14:33:58] <CIA-93> ffmpeg: siretart * r23379 /branches/ (5 files in 4 dirs): [14:33:58] <CIA-93> ffmpeg: Add CODEC_CAP_EXPERIMENTAL and prefer encoders without it. [14:33:58] <CIA-93> ffmpeg: Patch by Janne Grunau, janne-ffmpeg jannau net [14:33:58] <CIA-93> ffmpeg: backport r23334,23337-23338 by cehoyos and stefano [14:34:42] <CIA-93> ffmpeg: siretart * r23380 /branches/ (0.6 0.6/libavcodec/aacenc.c): [14:34:42] <CIA-93> ffmpeg: Mark AAC encoder as experimental. [14:34:42] <CIA-93> ffmpeg: backport r23350 by alexc [14:35:25] <CIA-93> ffmpeg: siretart * r23381 /branches/ (0.6 0.6/libavcodec/vorbis_enc.c): [14:35:26] <CIA-93> ffmpeg: Mark vorbis encoder as experimental. [14:35:26] <CIA-93> ffmpeg: backport r23339 by cehoyos [14:41:23] <CIA-93> ffmpeg: siretart * r23382 /branches/ (0.6 0.6/ffserver.c): [14:41:24] <CIA-93> ffmpeg: backport latest ffserver fixes like memory leaks and invalid reads [14:41:24] <CIA-93> ffmpeg: Patches by Howard Chu, hyc at highlandsun dot com [14:41:24] <CIA-93> ffmpeg: backport r23290-23295 by mstorsjo [14:42:17] <CIA-93> ffmpeg: siretart * r23383 /branches/ (0.6 0.6/ffserver.c): [14:42:17] <CIA-93> ffmpeg: ffserver: Send a Content-Base header in the reply to RTSP DESCRIBE requests [14:42:17] <CIA-93> ffmpeg: This is needed for QuickTime Player to be able to connect properly. [14:42:17] <CIA-93> ffmpeg: backport r23325 by mstorsjo [14:46:03] <CIA-93> ffmpeg: siretart * r23384 /branches/ (0.6/libavformat/riff.c 0.6): [14:46:03] <CIA-93> ffmpeg: Samsung uses SIPP as FourCC for MPEG-4 ASP. [14:46:04] <CIA-93> ffmpeg: backport r23309 by cehoyos [14:49:48] <jai> ^ you'll need another patch for that [14:58:01] <siretart> jai: which one? [14:59:11] <siretart> rev 23336? [15:03:37] <jai> siretart: yeah [15:07:59] <CIA-93> ffmpeg: siretart * r23385 /branches/ (0.6/libavcodec/h263dec.c 0.6): [15:07:59] <CIA-93> ffmpeg: Treat SIPP like xvid, fixed issue1966 [15:07:59] <CIA-93> ffmpeg: backport r23336 by michael [15:30:33] <CIA-93> ffmpeg: mru * r23386 /trunk/libavcodec/arm/ (Makefile mpegvideo_arm.c mpegvideo_neon.S): ARM: NEON optimised dct_unquantize_h263_{intra,inter} [16:25:17] <peloverde> http://tech.blog.aknin.name/2010/05/29/mailing-list-debates-considered-harmf... [16:26:15] <mru> and he can't spell [16:26:42] <mru> gaah [16:26:47] <mru> another mistake [16:27:07] <mru> wow, a sentence without errors [16:35:07] <kshishkov> mru: then that post was intended for Diego and not you [16:39:22] <nfl> is there an api call for arithmetic shift? [16:39:51] <kshishkov> >> [16:39:53] <mru> nfl: in practise shift of signed values is arith [16:43:33] <hyc> wbs: what do you think about adding -vpre support to ffserver config? [16:44:39] <wbs> hyc: sure, if you get it implemented cleanly [16:45:16] <hyc> picky, picky... ;) [16:46:21] <hyc> still trying to see if I can simplify the sdp patch any further [16:46:48] <hyc> doesn't seem like it [17:15:09] <lu_zero> uhmm [17:16:23] * lu_zero consider ffserver config annoing at best [17:16:38] <hyc> agreed [17:19:01] <_troll_> change it to xml! [17:19:55] * hyc changes his mind about agreeing to devel policy, relinquishes svn access... [17:19:57] <kshishkov> and rewrite in Java! [17:20:26] <jai> or c++ with boost [17:20:41] <kshishkov> ok, ou win [17:20:44] <kshishkov> *you [17:21:09] <jai> :) [17:21:20] <hyc> kshishkov: I guess a java wrapper is enough http://javacodegeeks.blogspot.com/2010/05/rtmp-to-rtsp-re-stream-using-wowza... [17:22:01] <_troll_> it has to be wrappers all the way down [17:22:54] <_troll_> when nds started writing wrappers for their own wrappers, I was one step closer to leaving [17:24:47] <Dark_Shikari> _troll_: oh nice, dct unquant n eon [17:24:50] <Dark_Shikari> what % time does it use now? [17:25:02] <_troll_> 5% [17:25:13] <Dark_Shikari> heh, nice, so almost 3x faster [17:25:16] <kshishkov> what made you leave then? docmenting wrappers on wrappers on own wrappers? [17:25:20] <Dark_Shikari> It does bug me the way that h263 works [17:25:26] <Dark_Shikari> it does unquant as a separate function instead of during decoding [17:25:31] <_troll_> kshishkov: it helped that the wrappers were _wrong_ [17:25:40] <Dark_Shikari> the latter would probably be faster in many cases [17:25:47] <_troll_> hard to simd though [17:25:49] <Dark_Shikari> i.e. when there aren't many dct coeffs per block [17:25:50] <Dark_Shikari> yeah [17:25:55] <Dark_Shikari> but h264 does that for example [17:26:39] <Dark_Shikari> anyways, thanks a lot -- 10% free speed without horribly munging anything. [17:27:02] * _troll_ sends Dark_Shikari an invoice [17:31:30] <lu_zero> 19:17 <@_troll_> change it to xml! [17:31:44] <lu_zero> if anything maybe json =P [17:31:58] <lu_zero> the problem is what you put there not how anyway [17:32:02] <_troll_> drk_shikari? [17:32:04] <peloverde> ebml! [17:32:22] <hyc> Dark_Shikari: it looks to me like x264_encoder_headers() only outputs one sps and one pps. is that pretty typical? [17:32:53] <hyc> trying to figure out if I need to handle more than one of each when pushing codec->extradata into sdp sprop-parameter-sets [17:33:20] <kierank> multiple sps/pps is rare [17:33:49] <lu_zero> I find strange having ffmpeg called outside with params to produce a feed file and then you have another way to feed ffmpeg params in ffserver [17:34:40] <hyc> kierank: kinda suspected that. [17:34:43] <kshishkov> put them to XML extradata :P [17:35:09] * elenril would compress it with crc32 [17:35:24] <hyc> lu_zero: hm? you can't set ffmpeg params when outputting to a feed [17:35:46] <kshishkov> s/compress/hash/ [17:36:15] <lu_zero> uh? [17:36:26] <elenril> kshishkov: i stand behind what i said =p [17:36:30] <lu_zero> at least input params for sure [17:36:48] <lu_zero> hyc: btw what are you trying to archive? [17:37:03] <hyc> kierank: rtpdec_h264 seems to be set up to parse an arbitrarily long list of sps/pps [17:37:21] <hyc> lu_zero: hm? what archive? [17:37:31] <lu_zero> 19:31 <+hyc> trying to figure out if I need to handle more than one of each when pushing codec->extradata into sdp sprop-parameter-sets [17:37:57] <lu_zero> I was quite sure that the code for that is already present [17:38:07] <hyc> lu_zero: currently ffserver will not serve FLV files over rtp correctly [17:38:24] <hyc> because the flv extradata is in AVC format, not bytestream format [17:38:44] <hyc> and libavformat/sdp.c currently only encodes bytestream extradata [17:38:59] <hyc> I just posted a patch for it to use AVC format [17:39:07] <hyc> but my patch only handles a single sps and pps [17:39:16] <hyc> not sure if it needed to be able to handle multiple [17:39:16] <lu_zero> uhmm [17:39:17] <lu_zero> eng/src/media/parser/h264.c [17:39:19] <lu_zero> f [17:39:21] <lu_zero> check there [17:39:36] <hyc> ok [17:39:38] <hyc> thx [17:40:26] <lu_zero> http://cgit.lscube.org/cgit.cgi/feng/tree/src/media/parser/h264.c#n91 [17:40:35] <lu_zero> is that missing? [17:40:51] <hyc> I have the source tree here [17:41:12] <lu_zero> ok =) [17:43:28] <hyc> lu_zero: ok, it looks like you just output them all, with a comma between each b64 string [17:44:12] <lu_zero> yes [17:44:16] <lu_zero> that's the idea [17:44:55] <hyc> ok, then my last emailed patch is wrong. thanks for clarifying [17:46:08] <hyc> seems like you ought to check in case there were no sps in encode_avc1_header [17:46:12] <lu_zero> I should doublecheck the rfc if you found something different [17:46:24] <lu_zero> uhm? [17:46:33] <hyc> or would that have been an invalid setup, rejected much earlier? [17:47:23] <hyc> the RFC said something about these being sps/pps pairs, which confused me. led me to believe there was a strict sps,pps,sps,pps order or something. [17:48:25] <lu_zero> cnt = *(p+5) & 0x1f; // Number of sps [17:48:57] <hyc> right, is it ever legal for that cnt to be zero? [17:49:08] <lu_zero> I'm afraid right now it doesn't check if it is zero [17:49:12] <lu_zero> and isn't expected [17:49:52] <hyc> it would certainly make no sense to encounter that, but ya never know [17:50:54] <lu_zero> that reminds me that ffmpeg doesn't fill the extradata for elementary streams [17:51:27] <hyc> and just to confirm, in avc1 header, only sps and pps are present, no other nal types [17:52:11] <hyc> sdp.c currently checks to make sure type is 7 or 8 when encoding a bytestream extradata [17:53:09] <lu_zero> if anything got there it would be serialized the same way [17:53:20] <hyc> ok [18:13:25] <hyc> I looked at mp4, mkv, and flv, it seems they all store the extradata in AVC format [18:13:44] <hyc> so ffserver always fails to stream H.264 from these files [18:14:15] <hyc> is there a file format that doesn't use AVC? [18:36:08] <astrange> .h264 [18:36:10] <astrange> maybe .ts [18:38:52] <hyc> thx, will try .h264 [18:44:34] <hyc> hmm. ffmpeg -i xxx.flv -vcodec copy -an test.h264 [18:44:44] <hyc> ffprobe test.h264 -> detects as mp3 [18:44:59] <lu_zero> ffmpeg -i ? [18:45:41] <hyc> yes, what's wrong with that? [18:46:00] <lu_zero> I mean [18:46:07] <lu_zero> ffmpeg -i test.h264 [18:46:16] <hyc> lots and lots of garbage [18:46:17] <lu_zero> says the right thing? [18:46:42] <hyc> no, it says the same as ffprobe. mp3 [18:47:03] <hyc> [NULL @ 0x28fc470]Format detected only with low score of 24, misdetection possible! [18:47:04] <hyc> [mp3 @ 0x28fd710]Header missing [18:48:41] <lu_zero> pretty bad [18:48:57] <lu_zero> file says the same? [18:49:19] <hyc> "file" says "test.264: data" [18:49:40] <hyc> s/264/h264/ [18:53:08] <kierank> hyc: you need to convert from mp4 to annex b [18:53:33] <kierank> ffmpeg should really do that by itself when you use .h264 output though [18:54:29] <hyc> kierank: ah, that's better, thanks [18:57:41] <lu_zero> works? [18:57:49] <hyc> yep [18:58:16] <hyc> hmmm. not playing well from ffserver though [18:59:37] <hyc> and playing the file directly, frame rate is wrong [19:00:00] <lu_zero> the extradata is correctly parsed? [19:00:37] <hyc> I think so, overall the image looks fine [19:06:38] <hyc> ffserver doesn't serve it properly [19:06:50] <hyc> with or without my rtpenc_h264 patch [19:07:04] <hyc> so at least I didn't break anything :P [19:07:56] <lu_zero> good =) [19:09:49] <hyc> ffplay on the .h264 file, frame rate appears to be too fast [19:10:05] <hyc> ffplay thru ffserver, I get one frame and then nothing [19:10:22] <kierank> the .h264 file might be vfr [19:12:16] <hyc> variable frame rate? [19:12:57] <kierank> yes [19:13:58] <kierank> I'm not sure how ffmpeg does it but it could have put the flv timebase in the h.264 vui. [19:14:47] <kierank> or there might not even be a vui since some h.264 files don't have any [19:15:02] <hyc> seems like it recorded the timebase [19:15:06] <hyc> here's the .flv [19:15:16] <hyc> Stream #0.0: Video: h264, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 29.97 tbr, 1k tbn, 59.94 tbc [19:15:23] <hyc> here's the .h264 [19:15:43] <hyc> Stream #0.0: Video: h264, yuv420p, 640x360 [PAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 1200k tbn, 59.94 tbc [19:18:55] <hyc> if you want to take a look, http://highlandsun.com/hyc/test.flv [19:21:58] <kierank> it's flagged as vfr though [19:22:09] <kierank> s/though/ [19:23:03] <kierank> it should play at the right speed though [19:23:38] <hyc> what do you get when you copy the video stream to a .h264 file? [19:24:30] <kierank> num_units in tick: 1001 time_scale: 60000 [19:25:04] <kierank> which is correct [19:35:08] <hyc> but does it look like the correct rate when you play it? [19:39:30] <kierank> no [19:42:16] <hyc> looks to me like 24 or 25fps would have been correct [19:42:56] <hyc> mebbe the original encoder lied [20:10:04] <Kovensky> <kierank> it's flagged as vfr <-- isn't flv always vfr [20:15:10] <kierank> yes [22:01:57] <lu_zero> wbs: around? [22:33:46] <lu_zero> mru: poing [22:41:50] <DonDiego> gnite [22:45:59] <Kovensky> <@peloverde> It's an interesting game but it's no starcraft <-- peloverde++ [22:46:28] <Kovensky> (yes i only saw that today lol) [22:51:07] <superdump> about sc2 or...? [22:55:17] <Kovensky> about soccer [22:55:50] <Kovensky> silly argentinians [22:59:49] <superdump> aha :) [22:59:53] * superdump sleeps [23:02:24] <mru> lu_zero: pong [23:03:16] <Compn> everyone knows brazil is the best... ;p [23:04:27] <mru> some say spain has a good chance... [23:09:19] <lu_zero> I'm hopefully completing the sctp protocol [23:09:38] <lu_zero> (it will end up w/out deps on libsctp) [23:10:12] <lu_zero> wanted to know if my way to check for headers and struct is correct [23:10:41] <mru> send patch [23:11:27] <lu_zero> http://pastie.org/983764 [23:32:43] <Kovensky> Compn: tell me about it; I'll be forced to hear people talking about football the whole day every day for a whole month -_- [23:33:05] <Kovensky> not like I'm not forced to that usually though; it'll just be more intense D: [23:33:39] <Kovensky> lu_zero: StarCraft Transmission Protocol protocol? [23:49:44] <lu_zero> Kovensky: uhmmm [23:49:50] <lu_zero> would be fine for gaming indeed [23:50:03] <lu_zero> sctp isn't about starcraft anyway [23:55:23] <mru> lu_zero: that looks reasonable but fix the whitespace [23:58:18] <lu_zero> which line?