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

[irc at mansr.com]

[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-harmful/
[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-and.html#comment-form
[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?