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

[irc at mansr.com]

[00:59:58] <Compn> hah
[01:00:20] <Compn> finally, someone else wants to support another image format/colorspace in ffmpeg :)
[01:00:25] <Compn> its not just me!
[01:09:38] <kierank> does 4.6566... ring any bells as a "magic number" for anything? it's related to mantissa unpacking.
[01:19:59] <pengvado> 2**-31 = 4.6566e-10
[01:20:07] <pengvado> is that magic enough?
[01:20:40] <kierank> yes
[01:32:36] <peloverde> Is it better to bloat my context leaving some extra space in the IPD/OPD arrays or bloat my object code and add more special cases for mapping?
[01:36:46] <pengvado> how much space in each version? (counting only space in the same cacheline as something that is actually used)
[01:38:06] <peloverde> when you put it that way...
[01:38:18] <peloverde> (it only costs 170 extra bytes per channel)
[01:55:33] <peloverde> Fun commit message of the day "Add some more braces so that gcc stops behaving a whiny child."
[02:18:42] <CIA-92> ffmpeg: alexc * r23439 /trunk/libavcodec/ (aac.c aac.h):
[02:18:42] <CIA-92> ffmpeg: aacdec: Work around illegal files with all elem_id tags set to the same value.
[02:18:42] <CIA-92> ffmpeg: Fixes issue 1882.
[05:47:08] <j0sh_> clear
[05:47:20] <j0sh_> oops
[06:29:48] <wbs> hyc: gah. now I posted the patch too ;P
[06:30:47] <wbs> j0sh_: regarding your patches btw, if you want someone else to try it out, you can always push works in progress to some temporary branch
[06:31:00] <wbs> j0sh_: that way you always have a fixed point stored, that you know that actually works
[06:31:15] <j0sh_> wbs: alright
[06:31:22] <wbs> j0sh_: otherwise there's always the risk of breaking stuff when going from "initial version that actually works" to "cleaned up version for submission"
[06:31:28] <j0sh_> did you hear about the real version of rtsp-http i found in the wild?
[06:31:35] <wbs> yeah, saw that one. interesting :-)
[06:32:07] <j0sh_> i just found out they have a bunch of opensource stuff under the 'helix dna' client
[06:32:25] <j0sh_> im trying to get ahold of the code so i can look at the protocol but the website is really broken
[06:32:35] <wbs> yeah, I've looked at that a few years ago.. at least what I saw then was a huge mess
[06:32:52] <j0sh_> heh prob hasnt improved in the meantime
[06:32:56] <wbs> infinite layers of abstraction without actually finding the code that does the shit
[06:33:25] <j0sh_> ahh
[06:33:31] <j0sh_> ok i'll push my changes to github
[06:33:39] <wbs> great
[06:33:46] <wbs> maybe I can have a look and see why it doesn't work with dss
[06:34:27] <j0sh_> that would be a help, it's driving me nuts... i've been poring throgh each packet, line by line
[06:34:43] <j0sh_> comparing vlc (which works, kinda) to lavf
[06:35:36] <wbs> ah, I see you posted the patches earlier, too
[06:35:41] <wbs> no need to push it to github then
[06:35:52] <wbs> (it takes a while to go through all the mail in the morning ;P)
[06:35:53] <j0sh_> anyway, the only local change that hasnt been committed is a hardcoded change from htp/1.0 to http/1.1
[06:36:06] <j0sh_> err the other way around, from 1.1 to 1.0
[06:36:53] <j0sh_> just use my most recent four
[06:37:00] <wbs> ok
[06:55:58] <j0sh_> wbs: pushed all my changes to a github branch called rtsp-tunneling
[06:56:12] <j0sh_> http://github.com/j0sh/ffmpeg-soc/tree/rtsp-tunneling
[06:57:22] <wbs> j0sh_: ok, great!
[07:01:21] <wbs> j0sh_: it looks quite good already, a few comments:
[07:02:02] <wbs> in http_connect, when you added if(!strlen(s->headers)), add the brace at the end of the if line, and add a space between if and the parentheses
[07:02:17] <j0sh_> woops ok
[07:02:37] <j0sh_> its not my standard coding convention, i always have to remind myself to do that
[07:03:01] <wbs> in the is_chunked edit - if chunked encoding is disabled, you need to avoid sending the Transfer-Encoding: chunked header, too
[07:03:11] <wbs> if you send custom headers it won't be sent at all of course
[07:03:37] <j0sh_> good catch
[07:03:43] <wbs> but that's also part of why I think the custom headers shouldn't replace all of them, so that the caller doesn't need to keep track of all that, only the part that it actually wants to customize
[07:04:35] <j0sh_> yeah, but i think ffregexp is out of scope for this summer :(
[07:04:45] <wbs> yeah, of course
[07:04:45] <j0sh_> unless we can come up with a quick and clean way to do it
[07:05:17] <wbs> but perhaps add a few of the headers even if the custom headers are set, and document it in http.h
[07:05:39] <wbs> e.g. user-agent, transfer-encoding and such
[07:05:47] <j0sh_> does the rfc say anything about possibly duplicated headers?
[07:05:59] <wbs> I'm not sure, but I don't think it's a good idea
[07:06:45] <j0sh_> yeah im just thinking of what if someone wants to set a custom user agent or something, but since this is internal-only for now, its not anissue
[07:07:04] <wbs> in rtsp.c, you're missing a space in ff_url_join(..., port,"%s",  path); and a double space before path
[07:07:43] <wbs> yeah, that's probably not an issue. you could just document that "if you set custom headers, you need to provide these yourself: --, --, --, and the http protocol always takes care of these: --, --, --"
[07:07:56] <j0sh_> gotcha
[07:08:52] <wbs> what's with the Expires: 9 Jan 1972 header in the POST? :-)
[07:08:55] <wbs> (no, I haven't read the spec)
[07:09:15] <j0sh_> the spec recommends that so proxy servers dont cache things
[07:09:25] <wbs> ok
[07:09:40] <wbs> btw, I think you're missing a url_close -> close_cxn in rtspenc.c, too
[07:09:54] <wbs> so you may need to change the close_cxn to be ff_-prefixed and add it to rtsp.h
[07:10:30] <wbs> except for that, it looks quite good to me. now on to why it doesn't work with dss...
[07:11:08] <j0sh_> i havent done anythingto rtspenc.c?
[07:11:28] <wbs> no, you haven't, but you should have. :-)
[07:11:42] <wbs> rtspenc.c shares initialization with rtsp.c
[07:12:32] <j0sh_> gotcha, but i don't think that the second rtsp_hd handler (which is what close_cxn takes care of) is ever initialized through rtspenc
[07:12:40] <j0sh_> (but i havent looked, of course)
[07:12:54] <j0sh_> i need to get sleep, will investigate that in the morning
[07:12:56] <wbs> it could very well be initialized, if one chooses to use it with an rtsp://...?http url
[07:13:24] <j0sh_> yup, you're right.
[07:13:48] <wbs> in that case, we'd need base64-encoding in the rtspenc.c codepath too, though
[07:14:33] <wbs> it could be interesting just out of curiosity, but if it adds too much code bloat, we could just disallow http tunneling for the muxer
[07:14:46] <wbs> just like we disallow udp multicast
[07:14:48] <j0sh_> i'll look into that, i dont know what else needs to be base64 encoded other than the rtsp requests that come out of rtsp.c
[07:15:05] <j0sh_> the rtp isn't, and server replies aren't
[07:15:47] <wbs> I don't think it's a matter of rtsp replies vs rtp packets, the outgoing stream is base64 encoded, the incoming isn't
[07:15:48] <j0sh_> im assuming if we're using the rtsp muxer,we're acting as a server?
[07:15:53] <wbs> nope
[07:16:06] <wbs> the rtsp muxer is feeding packets to an rtsp server
[07:16:16] <wbs> that reflects them to whoever wants to watch them
[07:16:32] <j0sh_> so is the whole handshake thing the responsibility of the muxer or the server?
[07:16:47] <j0sh_> the GET reply in particular
[07:17:09] <wbs> so you can do ffmpeg -re -i (whatever) -f rtsp rtsp://dss/mystream.sdp, and then watch rtsp://dss/mystream.sdp with any rtsp player
[07:17:16] <wbs> uhm.. what do you mean?
[07:17:34] <j0sh_> when you set up the connection, the client makes a GET and POST
[07:17:58] <j0sh_> the server only replies to the GET,confirming things, then rtsp requests go out over post
[07:18:08] <wbs> yes
[07:18:31] <wbs> with the rtsp muxer, all of that just works all the same. but instead of the server sending you rtp packets, you send packets to the server
[07:19:04] <wbs> so the packets go in the outgoing stream from you, and everything in that stream is base64-encoded
[07:19:44] <j0sh_> from muxer -> server -> client, nothing is base64 encoded
[07:19:56] <wbs> ...
[07:20:01] <wbs> no, but it should be
[07:20:09] <j0sh_> but from client -> server, they are (rtsp requests)
[07:20:12] <wbs> see, everything in the POST stream needs to be base64 encoded
[07:20:20] <j0sh_> right
[07:20:45] <wbs> how should the server otherwise know if it should try to base64 decode it and see if it's a packet, or just parse it as a rtp packet right away?
[07:20:50] <j0sh_> but the muxer/server only sends packets down the GET and receives from POST
[07:20:58] <wbs> no, no..
[07:21:07] <wbs> you're talking about totally differnt things now
[07:21:18] <wbs> the lavf RTSP muxer isn't in the DSS/feng server
[07:21:58] <wbs> the RTSP muxer allows you as a client application to _create_ a live feed
[07:22:05] <j0sh_> right
[07:22:12] <j0sh_> demuxer, receives that
[07:22:32] <wbs> yes, but now we're only focusing on the muxer side. forget the demuxer for a while
[07:23:05] <wbs> this part works exactly like a normal RTSP client that plays back streams from the rtsp server
[07:23:42] <wbs> you connect to the server, instead of DESCRIBE you do ANNOUNCE, then you set up the individual RTP streams using SETUP, then you start sending
[07:23:53] <wbs> so instead of the server sending you RTP packets, you send packets to the RTSP server
[07:24:10] <j0sh_> right
[07:24:13] <wbs> these packets can be sent over UDP or interleaved in the TCP stream
[07:24:27] <wbs> it doesn't matter which way they're transported
[07:24:42] <wbs> _then_, any rtsp client can connect and watch this stream
[07:25:05] <wbs> the rtsp server simply repackages the RTP packets that it's receiving from the sender over whatever transport mechanism that the player did set up
[07:25:36] <wbs> so the packets can go from muxer, over UDP to the rtsp server, that then can send them tcp-interleaved to the player
[07:25:54] <wbs> or vice versa, the packets from the muxer to the server could be tcp-interleaved, while the player receives them over UDP
[07:26:28] <j0sh_> ah i see
[07:26:38] <wbs> so, in the case where the muxer talks to the server over a http-tunneled connection, the packets go in the outgoing stream from the muxer
[07:26:59] <j0sh_> so you could have two transport mechanisms, one between muxer and server, and another between server and demuxer
[07:27:05] <wbs> exactly
[07:27:05] <j0sh_> i see what you're saying now, ok
[07:27:35] <wbs> not only "could" you have that, you already can. the rtsp muxer supports both tcp and udp at the moment
[07:27:42] <wbs> if you've got a dss setup, you can try it out
[07:28:01] <wbs> ./ffmpeg -re -i sample.mp4 -f rtsp rtsp://yourdss/whatever.sdp
[07:28:13] <wbs> and then watch it with ffplay rtsp://yourdss/whatever.sdp
[07:28:30] <j0sh_> sweet, will do that
[07:28:30] <wbs> as long as yourdss is on localhost, you don't need any password, otherwise you can set up a broadcasting password in the dss admin
[07:28:48] <wbs> and then you can add ?tcp or ?udp on either sender or receiver and receive the packets in any way you like
[07:29:02] <j0sh_> ...or ?http in our case
[07:29:06] <wbs> exactly
[07:29:49] <j0sh_> good tips, thanks
[07:30:22] <j0sh_> and thanks for the review, i made a note of everything, will do those first thing
[07:30:32] <wbs> great
[07:31:00] <j0sh_> first thing in the morning, that is -- time for bed
[07:31:07] <wbs> ok, good night!
[07:31:12] <j0sh_> 'night
[07:31:20] <j0sh_> well, good morning to you actually
[07:31:29] <wbs> yeah :-)
[07:37:21] <wbs> j0sh_: in case you're still here, I got http tunneling working with dss ;P
[07:37:33] <j0sh_> lol
[07:37:37] <j0sh_> what was the problem?
[07:38:03] <wbs> when using chunked encoding, you should send the chunk size before the data chunk, and then \r\n after the chunk
[07:38:11] <wbs> you just removed the chunk size, but not the trailing \r\n
[07:38:30] <wbs> also, the temp[] array in http_write was uninitialized, so it spewed out some random data for me
[07:38:35] <j0sh_> ahh
[07:40:40] <j0sh_> thats weird, if you look at where we print the chunk size to the buffer, there's a trailing \r\n
[07:40:49] <j0sh_> that should have been commented out
[07:41:00] <wbs> nope, not that one
[07:41:01] <j0sh_> but you're right about the uninitialized data
[07:41:14] <wbs> you've got an array named crlf, too
[07:41:21] <wbs> that you send after the actual data
[07:42:47] <j0sh_> aha, ok
[07:43:24] <j0sh_> that explains it, distinctly remember never seeing a trailing \r\n on other captures, but i admit i didn't notice that here
[07:44:02] <j0sh_> didnt know it was part of the chunked encoding scheme anyhow... i REALLY need to read the rfc, im never gonna catch things like this otherwise
[07:44:32] <wbs> well, if not using chunked, and the user wants to send data, you never, ever should add anything extra inbetween
[07:44:41] <wbs> unless it's encapsulated like in chunked encoding :-)
[07:45:11] <j0sh_> yeah, because chunked encoding can mean extra headers mid-stream, right?
[07:45:25] <wbs> nah, not really
[07:45:35] <wbs> but the point with chunked is that you can signal end of stream cleanly
[07:45:45] <wbs> e.g., if you're serving the output of a cgi-script
[07:46:01] <wbs> you don't know the length of the data beforehand, so you can't add a content-length header
[07:46:29] <wbs> so the receiver will just keep reading what the server sends, and can't signal end of file in any other way except closing the connection
[07:46:31] <twnqx> av500: nvidia claims 1080p decoding on tegra250 :X
[07:46:41] <wbs> which means you can't reuse the connection for a new request after that one
[07:46:43] <j0sh_> got it
[07:47:13] <wbs> so with chunked, you don't need to know the full length beforehand, but can send a few bytes at a time, or then send a terminating 0-sized chunk to indicate end of stream
[07:48:50] <j0sh_> that would've been useful to know a few months ago
[07:49:18] <j0sh_> i was trying to figure out how to stream live webcam over http
[07:49:35] <j0sh_> gave up and used ffrtmp instead
[07:50:06] <wbs> ah.. I don't think it would have helped there.. usually it should work without it, too, but it may make some things a bit cleaner
[07:50:31] <j0sh_> yeah, who knows
[07:50:41] <j0sh_> ok, update email sent... NOW it's time for bed
[07:50:45] <j0sh_> ttyl
[07:50:48] <wbs> bye
[07:53:23] <KotH> hoi zäme
[07:57:19] <_av500_> einen wunderschönen feiertag wünsche ich
[07:59:25] <ln-> arbeitstag meinen sie...
[08:03:02] <KotH> ln-: depends
[08:03:08] <KotH> ln-: heute ist tag der fröhlichen leichen
[08:05:12] <KotH> ln-: und wie wir wissen wird dieser tag nur in katholischen gemeinden gefeiert
[08:05:41] <ln-> ach so
[08:05:42] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BlackSpeech
[08:07:25] <KotH> elenril: ruhe uf de billige plätz!
[08:10:08] <elenril> KotH: would you stop using TheEncodingOfDoom
[08:11:34] <KotH> as BofH, it's my duty to bring doom to everyone!
[08:12:03] <KotH> be glad, that i dont use euc ;)
[08:12:10] <wbs> KotH: or modernise yourself, bring quake instead? ;P
[08:12:57] <KotH> wbs: nah.. quake is so 80s... today oil is all the rage! :)
[08:13:50] <elenril> KotH: EBCDIC!
[08:17:25] <lu_zero> morning...
[08:27:42] <hyc> wbs: your patch doesn't work for me
[08:27:49] <hyc> no pkts sent
[08:28:39] <wbs> oh crap
[08:28:51] <wbs> can you find out what's wrong in this approach compared to the earlier fixes, then?
[08:29:06] <hyc> looking now...
[08:30:24] <hyc> could be my video source, lemme check something else
[08:31:48] <hyc> it's fine
[08:31:53] <hyc> have a different bug
[08:32:02] <wbs> ok, great
[08:32:11] <hyc> a misfeature of flvdec
[08:33:14] <hyc> an flv saved by rtmpdump includes a bunch of timestamp=0 packets, whatever the rtmp server sent at the beginning of the stream
[08:33:30] <hyc> most of them are zero length or otherwise non-data-bearing
[08:33:48] <hyc> but, their header / packet type tells you they were audio or video
[08:33:58] <hyc> which is a clue to the receiver what contents will be present in the stream
[08:34:22] <hyc> so rtmpdump saves them all in the output flv
[08:34:35] <wbs> ah
[08:35:02] <hyc> when flvdec plays them back, if it reads a zero-length packet, it returns EAGAIN to the caller
[08:35:14] <hyc> and ffserver doesn't check for this code, it fails.
[08:35:38] <hyc> the hint that this happened is this:
[08:35:42] <wbs> ok, so that should be quite a clear fix, then
[08:35:48] <hyc> Thu Jun  3 01:29:47 2010 127.0.0.1 - - [] " RTP/UDP" 200 410
[08:35:59] <hyc> it sent the first metadata packet and nothing else
[08:36:08] <hyc> and then considered the stream complete
[08:36:27] <hyc> if you do an ffmpeg -i xx.flv -vcodec copy -acodec copy yy.flv
[08:36:39] <hyc> those dummy packets are dropped, and it plays fine
[08:36:53] <hyc> it's actually a little tricky to fix this
[08:37:18] <hyc> ffserver only expects EAGAIN when reading from an FFM
[08:37:30] <hyc> because presumably that's a live feed
[08:37:38] <hyc> and it recovers ok in that case
[08:37:57] <hyc> but if you're reading from a File feed, it assumes a file can never return EAGAIN
[08:38:35] <hyc> I have to think about this a bit...
[08:38:48] <hyc> I hacked a patch in there to just goto the beginning of the loop again on EAGAIN
[08:39:03] <wbs> I think that should be ok as such
[08:39:05] <hyc> which got past this issue, but then broke streaming from e.g. an http url
[08:39:16] <wbs> ah
[08:39:29] <hyc> it went into an infinite loop. it needs to drop out and hit the select loop.
[08:40:31] <hyc> this is probably easy, I just had a false start on the last fix :P
[08:44:28] <hyc> hm, what is FF_NETERROR as opposed to AVERROR ?
[08:44:36] <hyc> did this just show up recently?
[08:44:43] <wbs> no, it's been there for a while
[08:44:48] <hyc> which one should I be using for EAGAIN?
[08:45:20] <wbs> in this case, AVERROR(EAGAIN)
[08:45:29] <hyc> ok
[08:45:30] <wbs> that's what flvdec returns
[08:46:17] <wbs> some error codes are only available through FF_NETERROR (since on windows, they don't exist as such, only when prefixed with WSA-)
[08:50:52] <KotH> does anyone know whether we have already samples with non-constant framerate ?
[08:51:21] <hyc> KotH: I'm told that FLVs are always variable frame rate
[08:51:32] <hyc> though all the ones I have appear to be 24 or 29.97 fps
[08:59:13] <hyc> stupid tabs in my last patch. sigh, too many projects, too many coding styles.
[09:02:49] <KotH> ok, now we have an mjpeg sample :)
[09:03:05] <Dark_Shikari> hyc: all flv files use millisecond timestamps iirc
[09:03:06] <Dark_Shikari> no fps
[09:03:17] <Dark_Shikari> sorta like mkv.
[09:04:25] <hyc> Dark_Shikari: hm, you're right about that, every pkt has millisecond timestamp
[09:20:33] <lu_zero> wbs: poing
[09:20:52] <wbs> lu_zero: piong
[09:34:48] <lu_zero> wbs: let me beat into submission ejabberd and I'll start hammering the new feng and testing j0sh_ patches
[10:03:05] <elenril> heh, ejabberd
[10:03:23] <elenril> configuring it was major PITA
[10:04:37] <lu_zero> actually it wasn't
[10:04:50] <lu_zero> I just need to know how to migrate it
[10:05:04] <lu_zero> ejabberdctl seems to be the right tool
[10:11:03] <lu_zero> now I just have to switch a number of dns entries...
[10:11:51] <elenril> no? when i configured it, it didn't ever say anything about syntax errors
[10:11:59] <elenril> and pretended to be working just fine
[10:12:05] <elenril> except it didn't
[10:12:13] <lu_zero> ah
[10:12:22] * lu_zero was lucky
[10:31:17] <roselone> what's the usage of SDL_ffmpegGetAudioSpec ?
[10:50:56] <Tjoppen> hm. no PIX_FMT_RGB30
[10:52:45] <mru> wtf would that be?
[10:54:39] <janneg> 2 * RGB555
[10:58:09] <pross-au> 10-bit rgb
[10:58:23] <mru> why would anybody want that?
[10:58:24] <lu_zero> is it in use?
[10:58:39] <mru> monitors are only 8-bit, if you're lucky
[10:58:47] <mru> many cheap lcds are 6-bit
[10:58:54] <lu_zero> meh...
[10:59:13] * lu_zero would like to have support for 13bit rgbi
[10:59:23] <mru> i?
[10:59:29] <lu_zero> infrared...
[10:59:32] <wbs> mru: italian
[10:59:33] <wbs> ;P
[11:00:03] <lu_zero> wbs: help validating diego's work =P
[11:00:16] <wbs> lu_zero: I tested his branch yesterday, seemed to work fine for me
[11:00:26] <pross-au> some video cameras use 10-bit rgb
[11:00:35] <lu_zero> did you try hammering it?
[11:00:44] <lu_zero> pross-au: some also more
[11:00:53] <wbs> nope, didn't try that yet
[11:01:02] <lu_zero> and usually you might get the ir channel
[11:02:16] <pross-au> http://www.quickcamteam.net/documentation/how-to/how-to-enable-raw-streaming-on-logitech-webcams
[11:02:20] <pross-au> ^^ samples too
[11:03:46] <Tjoppen> 10-bit components, yes
[11:04:43] <Tjoppen> common in dpx. I'd rather not uselessly expand the data from 19 GiB to 28 GiB. also useful for r210
[11:05:47] <Tjoppen> I can live with it atm though. maybe later, if whoever wants support for it insists
[11:06:33] <pross-au> expand what?
[11:08:32] <Tjoppen> oh. I want to dump it as rawvideo rather than dpx "encoded" data (RGB30 with small header)
[11:09:32] <Tjoppen> into mxf. mxf supports both RGB30 and RGB48 via the quite general PixelLayout thing
[11:10:10] <mru> does it support bit-interleaved components?
[11:10:50] <pross-au> ah i see
[11:11:05] <Tjoppen> well, since you can specify "fill" as a component, I would assume leaving it out means it packs the data maximally
[11:11:24] <Tjoppen> see S377m E.2.46 (page 100)
[11:12:24] <Tjoppen> basically, good old RGB24 is {'R',8,'G',8,'B',8,0,0}, while RGB30 would be {?F?,2,?B?,10,?G?,10,?R?,10,0,0}
[11:12:40] <Tjoppen> err.. s/?/'/g
[11:13:19] <Tjoppen> if I understand it correctly it also allows for both big-endian and little-endian RGB48, but I'm not 100% sure
[12:42:40] <mru> t-shirts are printed
[12:42:44] <mru> that shop is fast
[12:44:01] <merbzt> M for I hope
[12:44:25] <merbzt> me ...
[12:44:43] <mru> there should be enough M
[12:44:54] <mru> I made some M and some L
[12:45:02] <merbzt> will we sell them also ?
[12:45:11] <mru> not enough
[12:45:59] <merbzt> ok
[12:46:25] <merbzt> I'll bring more of my bussiness cards then
[12:46:35] <merbzt> do we have some other giveaways ?
[12:50:13] <pross-au> whats the mention of trolls on the homepage about?
[12:50:26] <mru> you don't like trolls?
[12:51:11] <spd666> hi guys
[12:51:22] <spd666> need a fix in ffmpeg for my needs, gonna pay for the work
[12:51:26] <pross-au> it reads as if a public ffmpeg display is a magnetic for such people
[12:51:35] <pross-au> magnet, even
[12:52:07] <spd666> no, i was in public channel, they sent me here :)
[12:53:00] <spd666> 5 people who told "they know" what to do - failed, and i'm now 5 months back with job :(
[12:53:49] <spd666> what i need is a just working wrapper between h.264 rtsp and rtmp
[12:54:00] <spd666> i know that ffmpeg is capable off, but not this time
[12:54:38] <merbzt> spd666: hyc might know one thing or two about that
[12:54:54] <merbzt> but please elaborate some more
[12:55:00] <spd666> here?
[12:55:12] <merbzt> it's not entierly clear what you need
[12:55:26] <spd666> i have ip camera with rtsp h264 video data
[12:55:55] <spd666> but i need to trasfer this live video data using rtmp "publish" to outside Flash server
[12:56:32] <spd666> smtg like ffmpeg -i rtsp://x.x.x/channel1 -re -vcodec copy -o rtmp://y.y.y.y/path/flash
[12:57:12] <spd666> now ffmpeg sometimes with segfault, somethime just hangs
[12:57:49] <merbzt> ok, wbs, hyc and lu_zero might know who to do this
[12:57:54] <spd666> ffmpeg may be stripped with everything else and recompiled to high cpu arm
[12:58:05] <spd666> arm cpu*
[12:58:11] <merbzt> if things segfault file a bug report
[12:58:46] <merbzt> and details on how to reproduce it
[12:59:06] <spd666> ok gonna try
[12:59:15] <lu_zero> spd666: do you have a backtrace for it?
[12:59:43] <spd666> no
[12:59:55] <lu_zero> please provide one =)
[13:00:02] <spd666> but You can easy reproduce it
[13:00:28] <spd666> using: ffmpeg -i rtsp://82.177.67.57/channel1 -re -vcodec copy -o rtmp://82.177.67.51/axiscam1/stream
[13:00:43] <lu_zero> let me see
[13:00:57] <merbzt> what does -o do ??
[13:01:08] <spd666> oo sorry merbzt
[13:01:29] <spd666> i meant output
[13:01:48] <lu_zero> the rtsp part seems ok
[13:01:52] <spd666> i don't want to recompress video as it is already h264
[13:02:01] <spd666> and arm cpu has no power for it
[13:02:09] <merbzt> I know
[13:02:38] <merbzt> it's just that I've never seen a usecase with -o used
[13:02:53] <merbzt> what does -re do ?
[13:02:57] <lu_zero> realtime
[13:03:02] <merbzt> ok
[13:03:10] <mru> there is no -o option
[13:03:11] <merbzt> less buffering ?
[13:03:19] <mru> more making stuff up
[13:03:20] <lu_zero> it tries to not be too fast
[13:03:30] <merbzt> no -o option thats what I guessed
[13:03:43] <spd666> -o i meaned output - sorry, mistake
[13:04:23] <spd666> when i checked it and did some traces, it tries to guess duration, but from livestream it is impossible
[13:04:57] <spd666> SPS and PPS is right
[13:05:14] <spd666> RTP timestamps also
[13:05:27] <lu_zero> spd666: from here the rtsp part looks good
[13:06:01] <merbzt> does ffmpeg have rtmp output ?
[13:07:01] <lu_zero> mru: librtmp uses an ssl library
[13:07:15] <lu_zero> I'd use the pkgconfig to get the right library to link to =P
[13:07:24] <mru> eeeeeeeeeeeeeevil
[13:07:24] <spd666> it has :)
[13:07:57] <mru> link to shared librtmp and be done with it
[13:08:13] <spd666> right cmd line: ffmpeg -i rtsp://82.177.67.57/channel1 -re -vcodec copy -f flv rtmp://82.177.67.51/axiscam1/stream
[13:08:20] <spd666> forgot -f flv
[13:09:26] <merbzt> if you do ffmpeg -i rtsp://82.177.67.57/channel1 -re -vcodec copy -f flv out.flv and then send that file from the rtmp server does it work then ?
[13:10:22] <lu_zero> hyc: the librtmp.pc should be added to files to remove
[13:10:29] <lu_zero> on make clean
[13:10:55] <spd666> didnt check that merbzt
[13:11:49] <merbzt> guess you have something to do then
[13:12:24] <spd666> moment
[13:13:17] <spd666> ffmpeg doesnt create out.flv at all
[13:15:57] <lu_zero> ffmpeg -i rtsp://82.177.67.57/channel1 -vcodec copy -acodec copy -f mov out.mov
[13:22:52] <lu_zero> uhm
[13:23:00] <lu_zero> pressing q doesn't work anymore in ffmpeg...
[13:23:03] <lu_zero> _bad_
[13:23:11] <mru> ctrl-c
[13:23:19] <mru> that q thing was a stupid idea
[13:23:44] <lu_zero> ctrl-c when producing a mov -> bad idea
[13:24:12] <pross-au> why?
[13:24:24] <lu_zero> pross-au: try =)
[13:24:41] <mru> ctrl-c does exactly the same thing as q
[13:24:42] <pross-au> we have sig handlers to intercept that
[13:25:24] <spd666> so did you find something?
[13:25:37] <spd666> sorry, wife put a dinner on table :)
[13:26:13] <pross-au> Cya
[13:28:47] <spd666> i ust don't know what to do
[13:29:16] <spd666> i need that for our project and 5 months ago it should be done, 5 "programmers" tried to do that and nothing
[13:30:33] <spd666> only info i need is "how much"
[13:31:03] <lu_zero> oh
[13:31:05] <lu_zero> interesting
[13:31:53] <spd666> 1k USD?
[13:32:25] <lu_zero> from what I could see so far hyc is the one to be bribed
[13:32:57] <lu_zero> hmm
[13:33:16] <lu_zero> maybe the rtsp layer doesn't let you do a vcodec copy...
[13:34:04] <spd666> i don;t know
[13:34:10] <spd666> it is over my possibilites :)
[13:34:16] <lu_zero> spd666: let me play a bit on it
[13:36:17] <KotH> spd666: never trust "programmers" when ffmpeg codecs could be hired ;)
[13:36:40] <spd666> first i went to VLC dev irc channel
[13:36:44] <spd666> 5 months ago
[13:36:47] <spd666> when i aksed
[13:36:55] <spd666> about that, i got kicked and banned from channel
[13:37:03] <spd666> so i thought then that this is the wrong way
[13:37:11] <mru> you probably asked off-topic questions in an annoying way
[13:37:16] <mru> that gets you kickbanned over there
[13:37:18] <mru> and here too
[13:37:34] <spd666> no, mru, i asked the same way like here
[13:37:53] <mru> you're slightly more on-topic here
[13:38:07] <spd666> i'm not an idiot, i know irc rules, i'm also not MSN era guy :)
[13:38:23] <lu_zero> good =)
[13:38:26] <lu_zero> well
[13:39:01] <lu_zero> your camera supports rtsp-rtp-interleaved
[13:39:09] <lu_zero> so ffplay work with the bare url
[13:39:22] <lu_zero> ffmpeg needs ?tcp query param to use the right protocol
[13:39:43] <spd666> you mean rtp-over-tcp?
[13:39:59] <lu_zero> yes
[13:40:13] <lu_zero> the tcp part is secondary to the interleaving
[13:41:02] <spd666> but this should be done by player right?
[13:41:09] <spd666> as i debuged the rtsp server in camera - it is live555 based
[13:42:26] <lu_zero> ugh...
[13:42:55] <lu_zero> I can see a bug in the timestamps
[13:43:06] <lu_zero> probably our side
[13:44:31] <spd666> if that will help - we can add a cmd switch with bitrate parameter for it
[13:44:46] <lu_zero> which version of ffmpeg do you have?
[13:45:03] <spd666> last one i checked - was checout from 1 June
[13:45:07] <spd666> checkout*
[13:46:09] <spd666> in version 5.2.0 i downloaded there was problem with PPS and SPS being waited from rtsp
[13:46:18] <spd666> later You guys fixed this to read it from SDP file
[13:46:28] <lu_zero> we are working a lot on the rtsp side
[13:46:38] <lu_zero> j0sh_ is doing lots of interesting stuff =)
[13:46:49] <lu_zero> (and martin and hyc...)
[13:47:01] <spd666> i'm a programmer too - but multimedia based (codecs) is not my mainstream :)
[13:47:18] <lu_zero> I have an ugly hack for now
[13:47:22] <spd666> i passed out when i saw that there is a problem with DTS and PTS timestamps
[13:48:07] <lu_zero> that is
[13:51:16] <spd666> that is?
[13:52:11] <lu_zero> with a small and ugly/wrong hack I can get it to produce a file
[13:52:49] <spd666> this hack is about what?
[13:53:30] <lu_zero> I removed the safety check and let it be
[13:54:08] <lu_zero> could you make the camera deliver something that's not this flat?
[13:54:31] <lu_zero> hi BBB___
[13:54:46] <spd666> lu_zero - flat You wean what?
[13:54:56] <spd666> moving picture?
[13:55:04] <lu_zero> yes
[13:55:08] <spd666> sorry - no now - its in my office and i'm outside
[13:55:12] <spd666> this is not PTZ camera
[13:55:26] <lu_zero> nevermind =)
[13:55:49] <spd666> but You can try second rtsp url
[13:55:56] <spd666> rtsp://82.177.67.61/axis-media/media.amp
[13:56:08] <spd666> there is some movement - but this is different type
[13:57:58] <lu_zero> I'm trying to figure out why sometimes the timestamp reach that point
[13:59:36] <BBB___> hi
[14:00:16] <spd666> hi BBB___
[14:00:18] <BBB___> what was the git way of storing local uncommitted changes, then svn uping and then reappying those changes?
[14:00:47] <lu_zero> BBB: git stash
[14:00:54] <lu_zero> git pull
[14:01:00] <lu_zero> git stash pop
[14:01:00] <BBB> git stash; git pull; git stash apply
[14:01:01] <BBB> right
[14:01:03] <BBB> oh pop
[14:01:56] <spd666> oo shit :)
[14:01:57] <Tjoppen> not git svn rebase?
[14:02:20] <Tjoppen> that's what I do, but I suspect it might not be optimal
[14:03:49] <BBB> no svn
[14:04:32] <BBB> I wonder if yuvi minds if I put completely broken code into his git repo...
[14:05:47] <spd666> i would not be happy BBB
[14:05:55] <lu_zero> BBB: make a branch!
[14:06:03] <lu_zero> =P
[14:06:27] <lu_zero> btw we should set an impersonal account on github and gitorious
[14:06:48] <lu_zero> BBB: spd666 has an interesting issue
[14:07:04] <lu_zero> we periodically have a frame with dts = pts
[14:07:17] <lu_zero> and now ffmpeg pukes on it while transcoding ^^;
[14:08:38] <spd666> ha, so i'm not so dumb :)
[14:09:08] <lu_zero> spd666: I don't have an rtmp server to test the second part
[14:09:25] <spd666> i can give You one
[14:09:31] <spd666> what You need? shell access?
[14:10:40] <lu_zero> you might check what happens on rtmp://82.177.67.51/axiscam1/stream
[14:11:27] <spd666> lu_zero - switch it to:
[14:11:34] <spd666> rtmp://82.177.67.55/brickcom/stream
[14:11:35] <spd666> ok?
[14:11:45] <lu_zero> let me try
[14:12:44] <spd666> INFO session connect-pending 84.220.89.X
[14:13:00] <spd666> and i see involed publish command
[14:13:07] <elenril> Tjoppen: rebase is for committed changes
[14:13:07] <spd666> invoked*
[14:13:15] <lu_zero> it closed there after a bit
[14:13:41] <lu_zero> but seems working at least here
[14:13:56] <BBB> rtmp? I know little about rtmp
[14:14:08] <lu_zero> rtsp
[14:14:16] <spd666> but there is no video lu_zero
[14:14:34] <lu_zero> he is using ffmpeg to act as bridge
[14:14:39] <lu_zero> spd666: uhmmm
[14:14:43] <lu_zero> bad =_=
[14:15:22] <spd666> i know that's bad
[14:15:47] <spd666> lu_zero - does it look like its transferring video?
[14:15:49] <lu_zero> let me see what happens with another producer
[14:15:53] <lu_zero> it looked like
[14:16:01] <lu_zero> and my network was stating that
[14:16:26] <lu_zero> let me use another source
[14:16:29] <spd666> i will turn debug info on my side
[14:16:29] <spd666> wait
[14:16:50] <lu_zero> I'm sending you sindel
[14:17:10] <lu_zero> fetched from the original file through feng and then bounced back to rtmp by ffmpeg
[14:18:02] <lu_zero> no problems with timestamp in this case ...
[14:18:19] <spd666> try now
[14:18:40] <lu_zero> I'll try now with video only
[14:18:51] <spd666> ERROR server comment - Data format incorrect, killing client connection.
[14:18:58] <lu_zero> uhm?
[14:19:24] <lu_zero> how so?
[14:19:30] <spd666> same
[14:19:40] <merbzt> lu_zero: did you send mp4 or flv ?
[14:19:43] <lu_zero> what's expecting?
[14:19:53] <spd666> h264 stream data
[14:20:01] <j0sh_> good morning everyone
[14:20:03] <lu_zero> ./ffmpeg -re -i rtsp://lscube.org/sintel_trailer-1080p.mp4?tcp -an -vcodec copy  -f flv rtmp://82.177.67.55/brickcom/stream
[14:20:06] <lu_zero> hi j0sh_
[14:20:16] <j0sh_> lu_zero: i pushed my changes to a new branch on my github
[14:20:21] <j0sh_> http://github.com/j0sh/ffmpeg-soc/tree/rtsp-tunneling
[14:20:30] <lu_zero> I'll fetch it again
[14:20:50] <lu_zero> spd666: that should work for you
[14:20:52] <spd666> lu_zero - what is -an
[14:20:57] <lu_zero> no audio
[14:22:34] <lu_zero> j0sh_: you'd prefer an email or discussing here?
[14:22:37] <lu_zero> (or both?)
[14:22:54] <spd666> lu_zero can you do this again?
[14:23:15] <lu_zero> spd666: you should be able to use the line I pasted yourself
[14:23:21] <lu_zero> I can do
[14:23:42] <lu_zero> tell me what's better for you
[14:23:45] <j0sh_> lu_zero: sending an email out on the other thread now
[14:23:57] <lu_zero>  [FFmpeg-soc] [PATCH] rtsp tunneling
[14:25:22] <spd666> what is the debug options? verbosity?
[14:26:00] <j0sh_> lu_zero: prob email is easiest
[14:26:13] <j0sh_> for me to refer back to
[14:26:38] <lu_zero> spd666: uh?
[14:26:48] <spd666> this rtsp is wrong for me - nothing :)
[14:28:40] <BBB> j0sh_: how do we test this? specific uris that support this?
[14:29:15] <j0sh_> BBB: i just tested locally with feng and darwin
[14:29:37] <j0sh_> is the public feng server still available? if not, i can throw one up
[14:29:56] <spd666> axis camera supports http tunneling
[14:29:59] <spd666> you can check that
[14:31:37] <spd666> there is one at rtsp://82.177.67.61/axis-media/media.amp - You can try
[14:32:03] <j0sh_> sweet
[14:33:13] <spd666> j0sh_ - just please don't kill it - it mine :)
[14:35:21] <lu_zero> j0sh_: lscube.org is up
[14:35:38] <lu_zero> (with the latest feng)
[14:39:50] <spd666> this url is not working for me lu_zero - no connection
[14:39:56] <spd666> maybe blocked from here
[14:40:10] <spd666> no packet on tcp dump
[14:40:39] <BBB> it throws a h264 error for me
[14:40:40] <BBB> that's all
[14:41:11] <lu_zero> wait
[14:41:45] <lu_zero> you broke it =)
[14:41:56] <BBB> ?
[14:41:58] <lu_zero> Honoome: yet another bug for you =}
[14:42:04] <lu_zero> spd666: try again
[14:43:56] <j0sh_> lu_zero: who should own the copyright in http.h? im trying to match http.c
[14:44:23] <lu_zero> j0sh_: if you are the one who wrote it...
[14:44:34] <j0sh_> i wrote a very, very small part :)
[14:45:00] <BBB> j0sh_: what's the problem with always using urldelay?
[14:45:10] <j0sh_> what do you mean?
[14:45:22] <lu_zero> spd666: it should work for you now
[14:45:29] <lu_zero> meanwhile I fix I bug I introduced ^^;
[14:46:17] <j0sh_> lu_zero: reason the urldelay is in internal.h is because the function to continue the connection is private
[14:46:45] <j0sh_> we can make it public though, if you and others agree
[14:49:05] <spd666> lu_zero - nothing is playing, only 5 fps encoded
[14:49:11] <lu_zero> uuhm?
[14:49:12] <spd666> video:9kB audio:0kB global headers:0kB muxing overhead 4.094537%
[14:49:24] <lu_zero> what are you using?
[14:50:01] <spd666> i just passed Your command
[14:50:38] <spd666> i think there is seriously something wrong with this usecase
[14:50:53] <lu_zero> let me play a bit with it
[14:51:06] <spd666> You told that huc can find the problem
[14:51:30] <lu_zero> one problem had been found so far
[14:51:33] <spd666> example: [flv @ 0x96b3260]av_write_frame: pts:-9223372036854775808 dts:-22 cur_dts:0 b:2 size:1442 st:0
[14:51:44] <lu_zero> btw I'm sending using the command I gave you
[14:51:59] <spd666> i've never seend this pts and dts (they should be positive, right)
[14:52:13] <lu_zero> ./ffmpeg -re -i rtsp://lscube.org/sintel_trailer-1080p.mp4?tcp -vcodec copy -an -f flv rtmp://82.177.67.55/brickcom/stream
[14:52:31] <lu_zero> I guess you are receiving something
[14:52:51] <spd666> nothing
[14:53:05] <lu_zero> uhmm
[14:53:57] <lu_zero> there is something wrong in the dts
[14:54:05] <spd666> in ffmpeg?
[14:54:10] <lu_zero> yes
[14:54:19] <lu_zero> at least something
[14:54:29] <lu_zero> now I'm reproducing it with feng as well
[14:54:30] <spd666> now i recived from You
[14:54:31] <spd666> RROR server comment - Zero sized function (client:253253728:unknown): type:20 size:0 index:595:
[14:54:52] <lu_zero> I applied again the hack
[14:55:12] <spd666> so with the hack it seems that is getting worse
[14:55:25] <lu_zero> the strange thing with the axis is that I get the nonmonotone issue in a periodic way
[14:55:37] <lu_zero> sintel is too short
[14:56:07] <lu_zero> now I'm going back sending using your axis
[14:56:16] <spd666> ok
[14:56:21] <lu_zero> rtsp://82.177.67.57/channel1 is correct?
[14:56:40] <spd666> this is BrickCom camera - not Axis
[14:56:47] <spd666> rtsp://82.177.67.61/axis-media/media.amp - this is Axis
[14:57:21] <lu_zero> ok
[14:57:33] <lu_zero> so brickcom has this periodic issue
[14:57:35] <spd666> now i see something on server
[14:57:52] <spd666> but no video on flash side
[14:57:55] <lu_zero> something correct?
[14:57:57] <lu_zero> uhm
[14:58:06] <lu_zero> let's move to the axis
[14:58:48] <spd666> ok
[14:58:49] <lu_zero> that's even worse
[14:58:56] <lu_zero> [flv @ 0x2625110]st:0 error, pts < dts
[14:59:04] <spd666> huh...
[14:59:14] <spd666> so i think that there is a problem with h264 packetizer in ffmpeg
[14:59:31] * lu_zero hacks a bit more
[14:59:43] <spd666> now i ghave a video
[14:59:43] <spd666> :)
[14:59:46] <spd666> from Axis one
[14:59:46] <lu_zero> the rtp depacketizer might be at fault
[14:59:55] <spd666> look
[14:59:56] <spd666> http://webcamera.pl/andrychowWT.php?ffmpeg
[15:00:13] <spd666> some packet isse (garbage), but works
[15:00:52] <lu_zero> [flv @ 0x8a9110]st:0 error, non monotone timestamps 1 >= 1 Last message repeated 63 times   126kB time=0.01 bitrate=103118.4kbits/s
[15:00:55] <lu_zero> [flv @ 0x8a9110]st:0 error, pts < dts
[15:00:58] <lu_zero> [flv @ 0x8a9110]st:0 error, non monotone timestamps 1 >= 0
[15:00:59] <lu_zero> beside that works as should
[15:01:16] <lu_zero> I wonder why it is upset about sintel
[15:01:20] <spd666> bitrate reported from moon :)
[15:01:54] <lu_zero> mind if a spend 10min to fetch something to drink?
[15:02:03] <spd666> of course
[15:02:12] <spd666> i gonna go to a shop now
[15:02:16] <spd666> for some pepsi :)
[15:10:25] * lu_zero is back
[15:13:31] * KotH is front
[15:15:18] <lu_zero> KotH: python!
[15:17:59] <spd666> i go to shop now lu_zero
[15:18:11] <spd666> how can i contact someone outside IRC?
[15:19:13] <lu_zero> lu_zero at gentoo.org
[15:19:55] <spd666> some im?
[15:20:11] <lu_zero> luca.barbato at gmail.com -< jabber
[15:20:41] <lu_zero> or lu_zero at jabber.linux.it
[15:20:54] <spd666> Italian? :)
[15:20:58] <lu_zero> yes
[15:21:21] <spd666> ok, be back in 30 minutes
[15:21:26] <KotH> lu_zero: perl!
[15:21:31] <spd666> gretings from Wadowice, Poland :)
[15:23:52] <lu_zero> =)
[15:26:37] <lu_zero> roasted camel with a side of onions... yummm
[15:51:27] <j0sh_> lu_zero: what is the best way for me to make the changes you guys suggested?
[15:52:01] <j0sh_> modify commits, or create new ones? rebase to an older commit, branch and merge with -squash?
[15:53:13] <lu_zero> you can either rewrite the history
[15:53:47] <lu_zero> or just append patches with the fixes and once it's fine we can play with rebase -i
[15:54:04] <lu_zero> so michael will see thing split nicely and clean
[15:54:10] <j0sh_> alright
[15:54:33] <KotH> lu_zero: roasted camel? only if it's filled with sheep, filled with a goose, filled with a chicken, filled with eggs :)
[15:54:52] <lu_zero> KotH: that doesn't look that much perl ....
[15:54:54] <lu_zero> well
[15:54:58] <lu_zero> indeed it is!
[15:55:52] <KotH> lu_zero: back to the topic at hand
[15:56:10] <KotH> lu_zero: what do you want? want to move? dont want to move? when do you want to move?
[15:56:55] <KotH> lu_zero: if the answers are "move", "yes", "asap", then i've to make time to learn python :)
[16:02:56] <lu_zero> I'll move, I'll do within 4 months, I can put roundup on lscube.org and/or ask for a dedicated box to the top-ix
[16:03:14] <BBB> why isn't roundup on mphq?
[16:03:22] <BBB> roundup is TERRIBLY slow
[16:03:30] <lu_zero> - somebody hate python
[16:03:35] <lu_zero> - somebody hate bugzilla
[16:03:40] <lu_zero> - somebody hate mysql
[16:04:41] <BBB> idontgiveashitjustmakeitwork
[16:04:44] <BBB> ?
[16:05:19] <lu_zero> in the end I set it up somewhere, michael gave me his desiderata, I'll try to put them in form in the spare time while learning tal and the innards of roundup
[16:05:21] <BBB> how about this: move it to mphq and whoever opposes gets the title of freetard-of-the-week
[16:05:41] <BBB> you can call it securitard if you prefer
[16:05:47] <lu_zero> BBB: the box hosting roundup is doing just that and is a quite beefed up box
[16:06:00] <BBB> hmm....
[16:06:01] <lu_zero> using the deploy that should be most high performance
[16:06:12] <lu_zero> so if it is slow it's better if I have a look
[16:06:39] <j0sh_> yeah i was taking a look through roundup last night, its pretty slow
[16:08:02] <lu_zero> apache is doing almost nothing...
[16:08:33] <spd666> i;m back
[16:08:53] <lu_zero> model name	: AMD Opteron(tm) Processor 144
[16:08:53] <lu_zero> stepping	: 1
[16:08:53] <lu_zero> cpu MHz		: 1800.000
[16:08:53] <lu_zero> cache size	: 1024 KB
[16:08:53] <spd666> so lu_zero - any ideas?
[16:09:01] <lu_zero> spd666: about fixing it?
[16:09:06] <spd666> yes
[16:09:11] <lu_zero> first I noticed something wrong with the depacketizer
[16:09:42] <spd666> i did that too
[16:09:50] <spd666> but no skill to fix it, sorry :(
[16:09:59] <lu_zero> it's probably a 33 vs 32
[16:10:08] <lu_zero> but that doesn't change a thing
[16:10:37] <spd666> 33 vs 32?
[16:10:51] <lu_zero> av_set_pts_info
[16:10:59] <lu_zero> there is one that seems redundant and wrong
[16:11:13] <spd666> i've seen that threre is a problem with clock rate
[16:11:41] <lu_zero> the clock rate should be 90k
[16:12:36] <spd666> it is, the num timebase is set up to 90k, but \den\ is never guessed
[16:12:51] <spd666> this is a really a miracle when ffmpeg counts first pts/dts
[16:13:16] <lu_zero> in rtp 90k is a sort of magic number ^^;
[16:13:21] <lu_zero> (always used)
[16:13:57] <spd666> privded in SDP descriptor
[16:16:46] <lu_zero> anyway
[16:18:41] <J_Darnley> Is anyone here familiar with audio encoder performance on ARM?
[16:18:58] <kshishkov> mru
[16:19:13] <J_Darnley> A guy in #ffmpeg would like to reduce the cpu time reqired on his BeagleBoard
[16:19:22] <mru> encoding what?
[16:19:29] <J_Darnley> an audio device
[16:19:40] <mru> let me rephrase
[16:19:44] <mru> encoding using what codec?
[16:19:51] <J_Darnley> H says he's trying "ffmpeg -f oss -ac 1 -i /dev/dsp1 -acodec libfaac" at present
[16:20:00] <mru> I'm not touching libfaac
[16:20:16] <mru> if it's important, pay peloverde to finish our aac encoder
[16:20:19] <J_Darnley> is there an ffmpeg encoder you might reccommend instead
[16:21:13] <spd666> libmp3lame is fastest on arm, checked by myself
[16:21:27] <mru> of course lame is faster than faac
[16:21:32] <mru> mp3 is much, much simpler than aac
[16:21:56] <spd666> i tried to use aac as audio source in my ip camera
[16:22:02] <spd666> died on 500Mips ARM cpu
[16:22:12] <lu_zero> mru do you know if pts_wrap_bits means that to wrap on the Nth or the Nth+1 ?
[16:22:24] <mru> please do not ever quote cpu speed in "mips"
[16:22:40] <mru> lu_zero: 33 bits is correct for mpeg
[16:22:46] <mru> lu_zero: does that answer your question?
[16:22:49] <KotH> mru: what shall one use instead of mips?
[16:23:01] <KotH> mru: and dont say "arm" ;)
[16:23:02] <mru> architecture and MHz
[16:23:11] <lu_zero> that doesn't help me that much
[16:23:19] <mru> lu_zero: pts in mpeg is 33 bits
[16:23:39] <lu_zero> uhmmm
[16:26:41] <lu_zero> seems that rtpdec_h264 had a stray line =P
[16:28:35] <lu_zero> BBB: or wbs mind doublechecking http://pastie.org/990722 ?
[16:33:11] <BBB> why did it set that in the first place? :)
[16:33:17] <BBB> seems sane to me
[16:36:10] <hyc> siretart: librtmp has its own COPYING file. why isn't that sufficient?
[16:52:26] <lu_zero> BBB: do you know/recall something about who sets the pts/dts eventually?
[16:52:28] <CIA-92> ffmpeg: lu_zero * r23440 /trunk/libavformat/rtpdec_h264.c: Remove stray and possibly wrong line, rtpdec.c sets that already
[16:53:05] <BBB> lu_zero: for rtsp, it's rtsp, for asf-in-rtsp, it's asfdemux (don't ask), for real-rtsp it's rmdemux (don't ask)
[16:53:19] <BBB> I think for apple's qt-rtsp, rtsp sets it fine
[16:54:03] <lu_zero> not rtpdec?
[16:54:14] <BBB> I thought it was rtsp
[16:54:29] <BBB> oh right it's rtpdec
[16:54:31] <BBB> well same thing
[16:54:40] <BBB> rtpdec does it fine for most streams, but for rdt, rmdemux sets it
[16:54:46] <BBB> and for asf, asfdemux overrides it
[16:55:14] <lu_zero> right now something strange is happening
[16:55:20] <lu_zero> check rtsp://82.177.67.61/axis-media/media.amp?tcp
[16:56:28] <lu_zero> we have a quite bad assumption here
[16:56:29] <lu_zero> av_set_pts_info(st, 32, 1, 90000);
[16:58:03] <spd666> lu_zero - what is strange?
[16:59:47] <lu_zero> looks like we are ignoring the clock rate ^^;
[17:04:01] <lu_zero> anyway that's not a problem for your case
[17:04:02] <lu_zero> [rtsp @ 0x63a470]line= H264/90000
[17:05:50] <lu_zero> the axis takes a bit of time before it gets an rtcp packet
[17:06:57] <hyc> I seem to recall the RFC requires 90000 anyway
[17:10:47] <lu_zero> many rfc are perfectly sane
[17:10:54] <lu_zero> just are ignored...
[17:11:24] <lu_zero> usually you assume video will be in sync with audio so you use 90k
[17:14:48] <spd666> how can i help?
[17:17:59] <lu_zero> spd666: how fast you'd like to have a solution?
[17:18:08] <lu_zero> and how fast you'd like to have a workaround?
[17:20:57] <spd666> how fast it can be done?
[17:21:42] <lu_zero> workaround -> we have one now more or less
[17:21:49] <lu_zero> or at least works for axis
[17:24:26] <spd666> axis is not the option - its just testing
[17:24:26] <spd666> i need it for second camera
[17:24:29] <spd666> and asap
[17:25:39] <lu_zero> ok so let's go back to the second camera
[17:25:52] <spd666> i gave You axis rtsp (media.amp) only to compare
[17:25:58] <lu_zero> ah
[17:26:04] <lu_zero> give me your target url
[17:26:14] <spd666> rtsp://82.177.67.57/channel1
[17:28:07] <lu_zero> ok it doesn't send rtcp and our current implementation does rely a bit too much on it
[17:28:33] <lu_zero> you should get something
[17:29:07] <spd666> it doesnt send rtcp?
[17:29:42] <lu_zero> not as often as you'd like
[17:33:44] <spd666> i have contact to camera devs
[17:33:50] <spd666> what should i tell them?
[17:34:22] <lu_zero> that if they start sending rtcp as soon as possible
[17:34:31] <lu_zero> probably your issue will disappear
[17:34:44] <wbs> lu_zero: does the server send RTP-Info?
[17:34:59] <wbs> I've got a few unapplied parts from a previous patchset that uses that, to get proper timestamps before the first RTCP
[17:35:00] <lu_zero> is the next thing I'd look
[17:35:11] <lu_zero> where are those?
[17:35:19] <wbs> in my private git tree ;P
[17:35:22] <wbs> one moment
[17:35:25] <lu_zero> =E
[17:37:11] <spd666> you see
[17:37:13] <wbs> http://albin.abo.fi/~mstorsjo/rtsp-sync-dec-streams/
[17:37:32] <wbs> tested them a few months ago, just rebased to latest now but didn't test it any more
[17:37:52] <spd666> how this rtp-info packet look like?
[17:38:23] <lu_zero> it's part of rtsp
[17:39:22] <spd666> RTP-Info: url=rtsp://82.177.67.58/channel1/track1;seq=26517;rtptime=4191034428\r\n
[17:39:24] <spd666> ?
[17:39:31] <wbs> yes
[17:39:37] <spd666> ok, so it is
[17:39:40] <spd666> god bless wireshark
[17:39:54] <wbs> so you can use that as origin for converting rtp timestamps to pts/dts
[17:39:58] <wbs> until you get the first rtcp
[17:40:18] <lu_zero> exactly
[17:40:20] <wbs> the problem is that you may get a discontinuity when you get the first rtcp, and ffmpeg with stream copy usually doesn't like that
[17:40:55] <lu_zero> before we used the first packet as base and then calculate the deltas over it
[17:40:58] <wbs> but rtcp should override the rest, since it is supposed to correct sync in longer streams
[17:41:36] <spd666> lu_zero - this will be used inside a camera (arm based) on localhost so i dont think there will be any glitch on packet loss
[17:42:42] <lu_zero> uhmm
[17:42:58] <lu_zero> then probably you might simplify it quite a lot
[17:43:52] <lu_zero> I thought that this bridget would be an addon so people with a flash based solution can use professional cameras
[17:44:56] <spd666> this will work like that, so i can embed this bridge in camera FW
[17:45:17] <spd666> and using Web just point the destination flash mount point to start stream video by them
[17:45:28] <lu_zero> http://albin.abo.fi/~mstorsjo/rtsp-sync-dec-streams/0002-Use-the-currently-unused-base_timestamp-for-setting-.patch <- the first hunk is really related?
[17:45:57] <lu_zero> spd666: I'd consider pseudostreaming using html5
[17:45:58] <wbs> lu_zero: yes, it is
[17:46:32] <lu_zero> base_timestamp is the one read from the rtpinfo I guess
[17:46:40] <wbs> I think so, yes
[17:46:48] <spd666> lu_zero - no because then i have to know the camera address to start
[17:46:53] <wbs> it's a while since I wrote that so I don't recall everything right now ;P
[17:47:12] <spd666> with this - camera address is not a problem because camera starts connection
[17:47:12] <spd666> if You know what i mean
[17:47:58] <lu_zero> I mean on the front-end/server side
[17:49:08] <spd666> it will be done like that
[17:49:40] <spd666> first i need to get stream sent to server
[17:49:41] <lu_zero> so camera+producer -> mixer (optional) -> multiface streaming server -> clients
[17:50:39] <lu_zero> last try with martin's patches
[17:51:05] <lu_zero> uhm
[17:51:32] <spd666> lu_zero - exactly
[17:52:51] <lu_zero> ffplay does fetch the stream even if it takes age
[17:53:08] <lu_zero> let see what happens on ffmpeg
[17:53:19] <lu_zero> and then it's better if I run home
[17:53:27] <spd666> so where are You now?
[17:53:53] <lu_zero> my office
[17:55:02] <lu_zero> got something from your rtmp server?
[17:55:05] <wbs> spd666: btw, if you do run ffmpeg with rtsp as input, don't use -re
[17:55:27] <wbs> since the input itself is a realtime source, adding -re just adds potential waits, which can lead to dropped packets
[17:55:37] <spd666> nothing, tries to buffer and no luck
[17:55:53] <lu_zero> [flv @ 0x18f7190]st:0 error, non monotone timestamps 10 >= 10
[17:56:03] <lu_zero> that is a bit crazy
[17:56:16] <spd666> can you leave it for a minute?
[17:56:17] <lu_zero> still probably my bandwidth isn't enough
[17:56:30] <spd666> working?
[17:56:53] <lu_zero> if you have control over the producer code please doublecheck
[17:57:16] <lu_zero> still those timestamp numbers sound that strange -__-
[17:57:41] <lu_zero> frame= 2295 fps= 12 q=-1.0 size=   18878kB time=0.03 bitrate=5948002.2kbits/s
[17:57:50] <spd666> this is data reported by flash
[17:57:51] <spd666> Metadata:
[17:57:51] <spd666>   duration              0.00
[17:57:51] <spd666>   width                 1280.00
[17:57:51] <spd666>   height                800.00
[17:57:51] <spd666>   videodatarate         0.00
[17:57:51] <spd666>   framerate             90000.00
[17:57:52] <spd666>   videocodecid          7.00
[17:57:52] <spd666>   filesize              0.00
[17:57:52] <lu_zero> the bitrate is a bit... excesive
[17:57:53] <spd666> omg sorry
[17:58:44] <spd666> the framerate reported is more wierd...
[17:59:04] <lu_zero> if the axis is working then...
[17:59:40] <spd666> framerate reported = mpeg4 clockrate...
[17:59:56] <spd666> maybe if we can fix this framerate
[18:00:08] <spd666> so the encoder wont wait so much time to feed 90000 fps :)
[18:00:28] <lu_zero> uhmm
[18:00:49] <spd666> sory, i meant decoder (flash)
[18:01:02] <spd666> at working stream this data looks like this:
[18:01:19] <lu_zero> I think we could chat in 40-1h or tomorrow
[18:01:39] <spd666> 40-1?
[18:01:44] <spd666> 40 mintes u eman?
[18:01:46] <lu_zero> 40m
[18:01:47] <lu_zero> yes
[18:01:52] <spd666> ok, gonna wait
[18:02:00] <lu_zero> this irc session is over ssh
[18:02:01] <spd666> can You send me Your snapshot?
[18:02:16] <spd666> gonna try to fix this rtmp metadata
[18:02:39] <lu_zero> give me an email
[18:02:46] <spd666> marcin at speed666.info
[18:02:54] <spd666> this is also my MSN account
[18:03:01] <j0sh_> lu_zero: if i make the change to propagate rtsp_send_cmd errors, should i check every single write and reply?
[18:03:30] <lu_zero> the problem is: what happens if you ignore it?
[18:05:06] <lu_zero> anyway I must run ^^;
[18:05:15] <lu_zero> or will be more than an hour =|
[18:08:35] <spd666> ok
[18:22:44] <BBB> j0sh_: can you explain why you need the URL_DELAYOPEN flag? why can't you just set a s->init = 0 in http_open(), and then use that in http_read/write to open up?
[18:23:21] <wbs> BBB: if we don't have a delayopen flag, url_open will open the connection to the server immediately
[18:23:42] <wbs> I guess the whole http protocol handler could be changed to not do anything until the first url_read/write, but I'm not sure if that's a good change
[18:25:38] <wbs> BBB: btw, do you know what is needed from the http protocol side for doing mms-over-http?
[18:30:16] <BBB> no
[18:30:16] <BBB> but I'm sure you need custom headers
[18:30:50] <BBB> just always do a delay open
[18:30:55] <BBB> in practice it doesn't make a difference
[18:31:42] <wbs> hmmm, /away
[18:31:44] <wbs> oops
[18:31:49] <j0sh_> that breaks api behavior
[18:32:06] <wbs> alters, but not necessarily breaks
[18:32:20] <j0sh_> users may be depending on the fact that http writes to the connection immediately after opening
[18:32:34] <wbs> in some cases, yes
[18:32:44] <wbs> but I'm not sure if that actually is an issue
[18:33:38] <wbs> btw, how should we get custom http reply headers? I read the docs on the apple http tunneling stuff now, and noticed that the server can return a x-server-ip-address header, so that the second request actually go to the correct destination server
[18:33:50] <j0sh_> yesss thanks for pointing that out
[18:33:57] <j0sh_> i was goingt o mention it after my latest round of changes
[18:34:23] <j0sh_> we have no way of propagating that info back up
[18:35:19] <wbs> if we do the implicit delay open, we'd actually need a function for doing the connection, without reading/writing anything yet, so that we'd get the response header and can open the second connection
[18:37:08] <j0sh_> "doing the connection" == tcp handshake?
[18:37:24] <wbs> doing the http request
[18:37:38] <BBB> j0sh_: how would it depend on that?
[18:37:38] <BBB> wha
[18:37:49] <BBB> what else than url_write() or url_read() would it do?
[18:38:02] <BBB> everything in HttpContext is private
[18:38:05] <BBB> it can not be touched
[18:38:08] <j0sh_> the reason for the delayed open is to set headers
[18:38:46] <j0sh_> i tried adding an url_alloc sort of function but that was ugly, also broke api behavior
[18:39:38] <j0sh_> http://lists.mplayerhq.hu/pipermail/ffmpeg-soc/attachments/20100602/e9600f80/attachment.bin
[18:40:26] <BBB> I know
[18:40:41] <BBB> but just make url_open() not send the actual http request
[18:40:51] <BBB> do that on the first call to http_read()/http_write()
[18:40:53] <BBB> then it all works
[18:41:08] <spd666> j0sh_ - you work on http apple streaming?
[18:41:14] <BBB> the flag isn't necessary
[18:41:24] <CIA-92> ffmpeg: stefano * r23441 /trunk/ffmpeg.c:
[18:41:24] <CIA-92> ffmpeg: Change type of {audio,video,subtitle}_codec_tag variables from int to
[18:41:24] <CIA-92> ffmpeg: unsigned int, as the corresponding variable set in
[18:41:24] <CIA-92> ffmpeg: AVCodecContext.codec_tag is unsigned int.
[18:41:25] <j0sh_> spd666: yeah, im wrapping up a set of patches for that
[18:41:34] <j0sh_> spd666: i tried your server with rtsp-http, it works nicely
[18:41:57] <spd666> if You need some tests, i have wowza media server running which supports that (live streaming also)
[18:41:59] <j0sh_> BBB: i can do that, but i'm against it because it breaks api behavior
[18:42:03] <BBB> how?
[18:42:18] <j0sh_> like i said, users may be depending on that behavior
[18:42:30] <wbs> j0sh_: timing behaviour isn't part of the functional API, I'd say
[18:42:32] <BBB> the api is "allocate/init an objectX with url_open()" and "read data from objectX using url_read/write()"
[18:42:40] <BBB> how can they depend on it?
[18:42:54] <BBB> what sort of functionality would not work after calling url_open()?
[18:43:05] <BBB> is it url_read()? or url_write() or some other function that I'm not aware of?
[18:43:15] <j0sh_> plain GETs, for one
[18:43:21] <j0sh_> you dont send anyting in the body
[18:43:30] <wbs> but you do url_read
[18:43:40] <BBB> right
[18:44:09] <j0sh_> alright, i see your point now
[18:44:13] <BBB> as soon as you call url_read() to get the file data in response to the get, you still get the data, right? it's not like anything changed :)
[18:44:36] <BBB> some magic handle X of feature Y protocol Z changed in timing A by decision B of commit C by person D
[18:44:48] <BBB> but that's all nozzlefoobarwooh
[18:45:08] <j0sh_> heh
[18:45:15] <BBB> maybe I'm taking this too far ;)
[18:46:33] <j0sh_> i'll make another patch and make a note of that in the url_open docs
[18:51:46] <BBB> I reviewed the rtsp stuff too, good work
[18:51:51] <BBB> I have only small comments
[18:53:06] <wbs> haha, check http://en.wikipedia.org/wiki/Real_Time_Streaming_Protocol#Client_applications and the references discussing ffmpeg
[18:53:28] <j0sh_> BBB: thanks, im making fixes right now so send them to the ml
[18:53:30] <wbs> it seems that they're not totally sure if ffmpeg supports rtsp or not and whether there's any official source that can confirm or deny it ;P
[18:53:42] <j0sh_> and i'll have changes on github soon
[18:54:25] <CIA-92> ffmpeg: stefano * r23442 /trunk/libavcodec/eval.h: Fix misc typos.
[18:55:28] <mru> wbs: add a note in the docs stating something ambiguous and referencing the wikipedia page
[18:55:36] <j0sh_> lol
[18:55:55] <wbs> haha
[18:56:51] <spd666> :)
[18:57:40] <spd666> of course they are outdated as always, in ref: "built on Dec 3 2007"
[18:58:06] <spd666> in ffmpeg it is almost like last glacier...
[18:58:19] <wbs> also, it's unknown from which version it is supported... eh, much of the libavformat rtsp code is dating back to 2002 or something like that ;P
[18:58:36] * lu_zero is back
[18:58:47] <spd666> oo we have my hero :)
[19:00:40] <lu_zero> how's going?
[19:00:52] <spd666> waiting for You as i;m too dumb to patch the source :)
[19:01:00] <lu_zero> ehm...
[19:01:11] <spd666> (joke)
[19:01:19] <spd666> you have this branch now?
[19:01:30] <lu_zero> which branch?
[19:01:45] <spd666> you fixed 1h ago
[19:02:00] <lu_zero> currently I have my local tree with a mix of wbs and j0sh_ patches + the hack I sent you
[19:02:15] <spd666> ok can You run it with axis url?
[19:02:55] <lu_zero> doing now
[19:03:12] <spd666> i dumbed Your last run, extracted raw h264 ES and tested using stream analyzer from elecard - looks okay
[19:03:17] <spd666> dumped*
[19:04:10] <spd666> ok the parameters looks the same :( and works
[19:04:36] <lu_zero> ^^;
[19:05:01] <lu_zero> and with martins patches it doesn't have discontinuity
[19:05:17] <spd666> maybe we can try to fix this framerate?
[19:05:26] <spd666> and videocodecid
[19:05:32] <wbs> lu_zero: hooray :-)
[19:05:42] <lu_zero> let me get something to eat first
[19:05:48] <spd666> me too
[19:06:02] <lu_zero> then I'll use this also to validate feng
[19:08:02] <CIA-92> ffmpeg: stefano * r23443 /trunk/doc/ffmpeg-doc.texi:
[19:08:02] <CIA-92> ffmpeg: Put @ignore-d man page specific trailer at the end of the file.
[19:08:02] <CIA-92> ffmpeg: This makes the ordering of the sections in the file more consistent
[19:08:02] <CIA-92> ffmpeg: with that of the final man output.
[19:16:24] <wbs> j0sh_: FWIW, getting http tunneling working with the muxer too, isn't all that much work, I've tested it a bit here :-)
[19:17:01] <CIA-92> ffmpeg: stefano * r23444 /trunk/doc/ (4 files):
[19:17:01] <CIA-92> ffmpeg: Make consistent the various SEE ALSO sections in the FFmpeg man pages.
[19:17:01] <CIA-92> ffmpeg: Also replace "the HTML documentation of @file{ffmpeg}" with "the FFmpeg
[19:17:01] <CIA-92> ffmpeg: HTML documentation", which is more generic.
[19:17:06] <j0sh_> sweet, i made the connection-close changes you asked for and took a quick look
[19:17:37] <j0sh_> agreed it wont be that much
[19:17:49] <wbs> j0sh_: I ran into one minor detail regarding the muxer - the interleaving header + the packet needs to be base64-encoded in one chunk instead of as two separate ones
[19:18:01] <wbs> but I'll post a patch that makes that much easier
[19:18:06] <j0sh_> cool, thansk
[19:18:56] <j0sh_> ok be back in ~1h, going to do some laps before diving into ronald's patches
[19:24:08] <spd666> ok, i checked, something is wrong
[19:25:21] <spd666> the dumped file using axis has well  muxed reported framerate
[19:26:35] <spd666> reported framerate using brickcom is 77000fps
[19:26:51] <spd666> and timestamps in extracted files are 0 or 1 (muxed in FLV)
[19:27:00] <spd666> but in Axis reported fps is about 31
[19:27:16] <spd666> and timestamps are incremented by 31 or 32
[19:29:38] <wbs> j0sh_: posted the simplification for the rtsp muxer to the mailing list; I'll apply it in a while if nobody objects (it's code I maintain myself anyway...)
[19:33:32] <lu_zero> uhmm
[19:35:12] <hyc> wbs: is it normal to post patches to code you maintain?
[19:36:20] <wbs> hyc: nah, if it's an obvious fix you can do it straight away. in this case I figured I'll wait and see if someone thinks that is very bad for some reason
[19:36:42] <hyc> coalescing data instead of splitting across packets is always a good idea ;)
[19:37:51] <wbs> in this case, I'd think it might be coalesced by lower levels anyway, but if josh wants to base64 encode all of it, he'd need an intermediate buffer if it wasn't all in one consecutive buffer
[19:38:24] <wbs> or hack the base64 encoder, which also feels a bit out of scope ;P
[19:38:42] <hyc> ah reminds me, I still want to change the base64 encoder's return value
[19:38:53] <hyc> to point to the end of the returned string, instead of the beginning
[19:39:52] <hyc> most callers of av_base64_encode ignore the return value, so it should be a harmless change
[19:40:28] <hyc> but it would allow getting rid of the brainded p += strlen(p) in sdp.c
[19:41:11] <hyc> never traverse memory twice if you don't need to...
[19:41:38] <lu_zero> and av_base64_encode doesn't realloc so
[19:41:48] <lu_zero> the two values are always the same ^^;
[19:42:15] <hyc> exactly
[19:42:24] <hyc> currently the return value is utterly redundant
[19:44:19] <spd666> lu_zero - why it takes ages to start ffmpeg with rtsp?
[19:44:46] <spd666> You said that hyc might be able to find what is wrong...
[19:45:02] <lu_zero> if it was something in the rtmp side
[19:45:08] <lu_zero> but looks like that part is fine
[19:45:15] <hyc> what's the context? missed this conversation
[19:45:48] <lu_zero> takes age -> rtcp packets I think
[19:46:09] <hyc> is rtsp input or output?
[19:46:13] <hyc> rtmp is input?
[19:46:19] <spd666> trying to run ffmpeg -i rtsp://82.177.67.58/channel1 -vcodec copy -f flv rtmp://82.177.67.55/brickcom/stream
[19:46:26] <spd666> and will not work
[19:46:49] <hyc> how long does -i rtsp:// to local flv file take?
[19:49:04] <spd666> here doesnt even create
[19:49:45] <hyc> then it's not my fault (rtmp side), good.   ;)
[19:49:55] <spd666> haha :)
[19:50:04] <lu_zero> hyc: all rtp/rtsp fault so far =)
[19:50:11] <spd666> but there is smth wrong :)
[19:50:14] <spd666> with rtmp also
[19:50:25] <hyc> native rtmp or librtmp?
[19:50:35] <spd666> videocodecid based on adobe docs should report in metadata as avc1
[19:50:45] <spd666> and reports as (hex) 7
[19:50:55] <hyc> hmm. metadata is generated by flvenc
[19:50:55] <lu_zero> librtmp
[19:51:00] <lu_zero> in my case
[19:51:28] <spd666> i'm just dead...
[19:51:50] <hyc> well, FLV_CODECID_h264 = 7
[19:51:58] <hyc> so perhaps the data is correct
[19:54:26] * Honoome looks at lu_zero, not happy at all
[19:56:08] <lu_zero> hi!
[19:57:49] <spd666> gonna recompile last snapshot
[19:58:10] <lu_zero> what's up?
[19:58:32] <spd666> wierd because the created flv file is not playable nowhere - even in ffmpeg
[20:11:14] <spd666> so there is no way to make it work?
[20:11:34] <hyc> does ffplay work on the rtsp stream?
[20:11:50] <hyc> is this a public server that I can access?
[20:12:27] <CIA-92> ffmpeg: stefano * r23445 /trunk/doc/ffmpeg-doc.texi:
[20:12:27] <CIA-92> ffmpeg: Move section EXAMPLES towards the end of the ffmpeg-doc.texi file.
[20:12:27] <CIA-92> ffmpeg: This is consistent with the the rendered ordering of the ffmpeg man
[20:12:27] <CIA-92> ffmpeg: page.
[20:13:03] <spd666> yes, public
[20:13:09] <spd666> rtsp://82.177.67.58/channel1
[20:13:17] <hyc> ffplay sits there doing nothing for me
[20:13:44] <spd666> the wierdes think is that this is stream is playable using QT, VLC and others
[20:14:01] <hyc> hm, eventually I got 4 green dots
[20:15:12] <spd666> i made a lot of misconfs i think
[20:15:18] <hyc> hmmmmm
[20:15:21] <spd666> try the rtsp://82.177.67.57/channel1
[20:15:27] <hyc> now that it's playing, I see the timestamp counter resetting to zero
[20:15:31] <hyc> after about 8 seconds
[20:16:50] <spd666> iwerd
[20:17:30] <hyc> yeah, this stream is definitely flaky.
[20:17:34] <hyc> ok, lemme try with vlc
[20:17:34] <CIA-92> ffmpeg: siretart * r23446 /branches/ (6 files in 3 dirs):
[20:17:34] <CIA-92> ffmpeg: Add an entry to APIchanges for the addition of sws_convertPalette8ToPacked32 -24
[20:17:34] <CIA-92> ffmpeg: backport r23415 by siretart
[20:18:21] <hyc> nope. vlc1.0.6 isn't showing anything
[20:18:41] <hyc> I saw it start buffering for a moment, but then it stopped, 0/0
[20:19:03] <lu_zero> hyc: consider that by default you start with udp
[20:19:05] <lu_zero> then tcp
[20:19:14] <lu_zero> rtsp://82.177.67.57/channel1?tcp
[20:19:21] <hyc> ok
[20:19:57] <spd666> aaa
[20:20:01] <spd666> green dots are okay
[20:20:07] <spd666> there is just dark :)
[20:20:29] <hyc> still it takes a long time for anytying to show up
[20:20:47] <hyc> a minute now since I started the ffplay ? tcp
[20:20:55] <hyc> ok
[20:21:00] <hyc> just got the 4 green dots
[20:21:22] <hyc> 1:30 from start of command to receiving data
[20:21:52] <spd666> and in vlc - 3 seconds
[20:23:04] <wbs> isn't much of that kind of delay due to av_find_stream_info() that looks for some parameter that won't ever be found
[20:23:21] <lu_zero> I think the problem is related to our way to parse stuff
[20:23:26] <lu_zero> try ffplay with feng
[20:23:32] <lu_zero> it is quite quick
[20:24:05] <hyc> so that means feng is providing more info?
[20:24:17] <lu_zero> rtsp://lscube.org/sintel_trailer-1080p.mp4
[20:24:25] <lu_zero> rtsp://lscube.org/tc.mov
[20:25:07] <lu_zero> compare those two
[20:25:13] <spd666> when i tried to debug rtsp
[20:25:13] <bcoudurier> hi guys
[20:25:19] <lu_zero> hi!
[20:25:21] <hyc> time ffprobe rtsp://82.177.67.58/channel1?tcp
[20:25:26] <hyc> 1:19.60
[20:25:44] <hyc> time ffprobe rtsp://lscube,org/sintel_trailer-1080p.mp4
[20:25:49] <hyc> 0:12.32
[20:26:52] <hyc> tc.mov probed in 0:02.09
[20:27:17] <spd666> i found that ffmpeg is trying to feed full buffer before do something
[20:27:30] <hyc> though both streams have errors: [h264 @ 0x31ad310]concealing 4662 DC, 4662 AC, 4662 MV errors
[20:28:40] <lu_zero> try time ffprobe rtsp://lscube.org/sintel_trailer-1080p.mov?tcp
[20:29:16] <hyc> about the same. 0:11.73
[20:29:59] <spd666> is ffmpeg capable of reading h264 packets from a device (like /dev/h264enc) ?
[20:30:20] <lu_zero> spd666: what's that device?
[20:30:28] <spd666> hardware encoder in this camera
[20:30:30] <hyc> it supports raw h264 format. depends on the device...
[20:31:12] <spd666> i just don't know what to do...
[20:31:49] <spd666> tell me, the dts and pts values are in NAL Unit data?
[20:32:18] <hyc> I don't think so
[20:32:18] <CIA-92> ffmpeg: mstorsjo * r23447 /trunk/libavformat/httpauth.c:
[20:32:18] <CIA-92> ffmpeg: httpauth: Fix the length passed to av_strlcat
[20:32:18] <CIA-92> ffmpeg: Since the buffer always was large enough, this bug didn't have any
[20:32:18] <CIA-92> ffmpeg: effect in practice.
[20:36:39] <spd666> i just need that - not for free ofc :|
[20:37:04] <hyc> wbs: what about the strlen / snprintf changes in httpauth.c, while you're there... and it seems to me there ought to be a BASE64_SIZE() macro, instead of spelling out the calculation in each source file
[20:37:42] <wbs> hyc: yes, that would be a great thing, please feel free to suggest such a patch
[20:37:55] <wbs> if you don't have time, I might give it a shot in a few days
[20:39:14] <hyc> I'll post something. should it be AV_BASE64_SIZE() ?
[20:39:20] <wbs> I think so
[20:39:24] <hyc> ok
[20:40:49] <spd666> ok, so i wont take Your time
[20:41:56] <CIA-92> ffmpeg: ramiro * r23448 /trunk/libavformat/os_support.h:
[20:41:56] <CIA-92> ffmpeg: win32: Use _fstati64() instead of plain old fstat() on Windows to support file
[20:41:56] <CIA-92> ffmpeg: sizes greater than 4gb.
[20:41:56] <CIA-92> ffmpeg: Patch by kemuri <kemuri9 at gmail dot com>
[20:42:05] <spd666> by lu_zero - thanks for everything
[20:42:11] <spd666> i will abandon the project then
[20:43:10] <kierank> [21:31] <spd666> tell me, the dts and pts values are in NAL Unit data? --> possibly
[20:43:28] <kierank> they could be derived if hrd is present
[20:43:33] <kierank> nal-hrd*
[20:45:16] <spd666> i just dont know that kierank
[20:45:21] <spd666> too high skill for me
[20:48:50] <CIA-92> ffmpeg: cehoyos * r23449 /trunk/ (7 files in 3 dirs):
[20:48:51] <CIA-92> ffmpeg: VP8 encoding via libvpx.
[20:48:51] <CIA-92> ffmpeg: Patch by James Zern, Google, Inc.
[20:52:07] <lu_zero> oh
[20:53:56] <elenril> \o/
[20:53:59] <elenril> time for 0.6?
[20:54:13] <wbs> isn't the WebM muxer yet to be commited, too?
[20:55:15] <lu_zero> elenril: not yet =)
[20:55:18] <elenril> hmm, seems so
[20:55:46] <Kovensky> didn't some dude also devise VP8-in-RTP
[20:56:17] * elenril wonders why is alsa detecting a kernel version he deleted a few months ago
[20:56:29] <Kovensky> >alsa
[20:56:50] <lu_zero> Kovensky: in the mailing list there is a first draft
[20:57:13] <elenril> what about vp8 in ogg ;)
[20:59:16] <CIA-92> ffmpeg: mstorsjo * r23450 /trunk/ffserver.c:
[20:59:16] <CIA-92> ffmpeg: ffserver: Calculate cur_pts using first_pts as origin instead of ist->start_time
[20:59:16] <CIA-92> ffmpeg: This fixes cases where ist->start_time wasn't initialized. This also makes
[20:59:16] <CIA-92> ffmpeg: cur_pts calculated against the same origin for all streams.
[20:59:41] <hyc> yay
[21:00:35] <elenril> Kovensky: actually no, that was my fault :\
[21:01:19] <hyc> anyone know what video codec is being used here? rtsp://3gp-acl.bbc.net.uk:554/iplayerstream/secure_auth/1500kbps/Doctor_Who_Series_5_Episode_3_b00s567r.mp4
[21:01:44] <hyc> audio too, for that matter.
[21:01:54] <hyc> I'm getting CODEC_ID_NULL for both
[21:02:43] <hyc> and yet ffplay knows that the duration is 00:42:34.15.  ?
[21:03:01] <wbs> hyc: I get connection refused for that url
[21:03:12] <hyc> probably UK-only
[21:03:14] <ohsix> and you will depending on your region
[21:03:20] <hyc> I got this output relayed to me
[21:03:33] <ohsix> 3gp is in the url ...
[21:04:34] <hyc> you can grab the pkt capture and ffplay output from here http://linuxcentre.net/rtspdump.tbz2
[21:04:58] <hyc> hmm, they wouldn't be using amr on that would they?
[21:05:04] <hyc> don't recall if I enabled that in my build
[21:05:16] <hyc> and I thought 3gp is just mp4
[21:06:23] <wbs> no, it's not 3gp, it's mp4a-latm + some weird rtp h264 packetization I haven't seen before
[21:07:28] <wbs> lu_zero: have you seen h264 in rtp with the format name X-HX-AVC1 before?
[21:10:19] <CIA-92> ffmpeg: michael * r23451 /trunk/libavutil/pixfmt.h: Deprecate PIX_FMT_YUVJ*
[21:11:06] <wbs> looks like some proprietary helix streaming server packetization mode, that totally lacks documentation. (that is, wasn't on the first google result page at least)
[21:17:12] <wbs> BBB: one api-level change that can be observed if the http protocol is made to always delay opening, is that you can't use the url_open return value to check whether it succeeded or not
[21:17:34] <wbs> but it isn't breaking the api, just making it behave differently within the same spec
[21:23:36] <j0sh_> wbs: one other benefit i just realized making these changes
[21:23:48] <j0sh_> since we have to use url_read now to send the GET
[21:23:50] <CIA-92> ffmpeg: stefano * r23452 /trunk/doc/ffserver-doc.texi:
[21:23:50] <CIA-92> ffmpeg: Rename ffserver-doc.texi @chapter "Introduction" to "Description", for
[21:23:50] <CIA-92> ffmpeg: consistency with the corresponding man section.
[21:23:53] <CIA-92> ffmpeg: stefano * r23453 /trunk/doc/ffprobe-doc.texi:
[21:23:53] <CIA-92> ffmpeg: Rename ffprobe-doc.texi @chapter "Introduction" to "Description", for
[21:23:53] <CIA-92> ffmpeg: consistency with the corresponding man section.
[21:23:53] <CIA-92> ffmpeg: stefano * r23454 /trunk/doc/ffplay-doc.texi:
[21:23:53] <CIA-92> ffmpeg: Rename ffplay-doc.texi @chapter "Introduction" to "Description", for
[21:23:53] <CIA-92> ffmpeg: consistency with the corresponding man section.
[21:23:56] <j0sh_> we'll get the response
[21:24:23] <j0sh_> and we can add another ff_http_header_exsts func to parse it or something
[21:24:36] <j0sh_> to check for the existence of any expected headers
[21:24:48] <wbs> uhm, I'm not sure I'm with you on this
[21:25:04] <wbs> when you set up your custom http urlcontext and set its custom headers
[21:25:07] <j0sh_> x-server-ip=address
[21:25:16] <j0sh_> err x-server-ip-address
[21:25:42] <wbs> you'd have to do an extra url_read() and discard its results, to force it to connect and do the http request
[21:26:17] <wbs> and what would you do with the result from that one, just discard it? so for that, you on the contrary actually would have to have a function to explicitly start it
[21:26:38] <wbs> since the first url_read from that stream will happen in rtsp_read_packet or what it's named
[21:26:54] <j0sh_> does the http protocol strip headers before returning the result? (havent looked yet)
[21:27:05] <wbs> yes it does
[21:27:08] <j0sh_> ahh
[21:27:28] <wbs> sorry, the first url_read is when waiting for reply to the first rtsp request, not in rtsp_read_packet
[21:27:31] <wbs> but anyway
[21:33:49] <hyc> wbs: ok, Michael doesn't like AV_BASE64_SIZE
[21:34:16] <hyc> oh well. to me, reading the code makes me think twice about whether the calculation is correct or not
[21:37:27] <CIA-92> ffmpeg: siretart * r23455 /branches/ (8 files in 4 dirs):
[21:37:27] <CIA-92> ffmpeg: VP8 encoding via libvpx.
[21:37:27] <CIA-92> ffmpeg: Patch by James Zern, Google, Inc.
[21:37:27] <CIA-92> ffmpeg: backport r23449 by cehoyos
[21:40:49] <wbs> hyc: yeah, at least mru argues back, we'll see where it goes
[21:45:11] <lu_zero> 23:06 <@wbs> lu_zero: have you seen h264 in rtp with the format name X-HX-AVC1 before?
[21:45:14] <lu_zero> no
[21:46:19] <wbs> ok
[21:46:27] <wbs> their SDP looked disgustingly weird, too ;P
[21:48:34] <hyc> http://www.realnetworks.com/products-services/helix-mobile-server-gateway.aspx
[21:49:18] <hyc> the 832x468 rez and 1.5Mbps bitrate are both far beyond the specs for their Helix mobile client
[21:49:30] <hyc> so it sounds to me like a server to server stream.
[21:54:29] <CIA-92> ffmpeg: michael * r23456 /trunk/libavcodec/avcodec.h: Document the frames returned by the decoder better.
[22:00:19] <CIA-92> ffmpeg: michael * r23457 /trunk/libavcodec/avcodec.h: Clarify that get/release_buffer() overriding only works with CODEC_CAP_DR1 codecs.
[22:03:30] <lu_zero> in that case in a quite field of nonstandards
[22:03:39] * lu_zero looks at feng and flux
[22:17:57] <CIA-92> ffmpeg: stefano * r23458 /trunk/tests/lavfi-regression.sh:
[22:17:57] <CIA-92> ffmpeg: Exclude from the lavfi_pix_fmts regression test the output pixel
[22:17:57] <CIA-92> ffmpeg: formats which are not currently supported by NUT and which cannot be
[22:17:57] <CIA-92> ffmpeg: played by ffplay.
[22:20:41] <Dark_Shikari> mru: we're up to reliable 1024x768p24 on the ipad
[22:20:51] <mru> cool
[22:20:55] <mru> what did you do?
[22:20:56] <CIA-92> ffmpeg: stefano * r23459 /trunk/tests/lavfi-regression.sh: Fix typo.
[22:20:58] <Dark_Shikari> decoding is ~7-9ms in low motion, ~15-25ms with peaks up to 40ms in high motion
[22:21:05] <Dark_Shikari> rendering is ~5-8ms
[22:21:11] <Dark_Shikari> audio is another few ms
[22:21:13] <Dark_Shikari> (CELT)
[22:21:38] <mru> 24 fps is ~40ms...
[22:22:35] <Dark_Shikari> all of these things add up
[22:22:54] <Dark_Shikari> I'd say 35ms overall is our average in a "worst case" situation
[22:22:58] <mru> yes, so "40ms in high motion" is at odds with "reliable"
[22:23:15] <mru> even so, good work
[22:23:16] <Dark_Shikari> that just means we get behind and catch up later
[22:23:25] <Dark_Shikari> as long as they're only spikes, we're fine
[22:23:29] <Dark_Shikari> if it was a constant 40ms, we'd have issues
[22:23:36] <Dark_Shikari> I think it's reliable because of encoder-side CBR
[22:23:49] <Dark_Shikari> i.e. the real determinator of decode time is bitrate, and as long as bitrate is locally capped, you can't have a sequence of large spikes.
[22:23:56] <mru> depends on how much of a frame delay you can tolerate
[22:24:10] <Dark_Shikari> of course
[22:24:18] <Dark_Shikari> ok, so my next task is to make it faster
[22:24:20] <Dark_Shikari> we want p30
[22:24:40] <mru> so what did you do to the video?
[22:24:46] <Dark_Shikari> haven't modified the video format yet
[22:24:49] <mru> h263-ish?
[22:24:52] <Dark_Shikari> It's FLV
[22:24:57] <Dark_Shikari> which is like dead-simple h263
[22:25:04] <Dark_Shikari> I mean seriously it doesn't even have dc prediction
[22:25:06] <Dark_Shikari> not even for intra blocks
[22:25:58] <mru> so you ripped out the code for all other cases?
[22:26:05] <mru> like you mentioned the other day
[22:26:10] <Dark_Shikari> yes
[22:26:21] <Dark_Shikari> I hardcoded every single thing flv-related
[22:26:24] <Dark_Shikari> and ripped out 80% of mpegvideo
[22:26:46] <mru> anything remaining to neonise?
[22:26:54] <Dark_Shikari> let me get the profile
[22:26:57] <Dark_Shikari> I may de-neonize quant
[22:27:00] <Dark_Shikari> i.e. move it into decode_block instead
[22:27:03] <Dark_Shikari> and see if that's faster
[22:27:20] <Dark_Shikari> do you think itw ould be, given what you know of the neon?
[22:27:55] <Dark_Shikari> I also may go swap out the transform now
[22:28:05] <Dark_Shikari> mru: http://i45.tinypic.com/2ecnqdl.png
[22:28:07] <Dark_Shikari> here's a profile we did
[22:28:29] <mru> for some reason I don't trust those profiling tools
[22:28:56] <Dark_Shikari> yes, they kinda suck
[22:29:16] <Dark_Shikari> anyways, y ou can hopefully see where our time is going
[22:29:23] <Dark_Shikari> No obviuos neon candidates
[22:29:34] <mru> what's that float2int16?
[22:29:47] <Dark_Shikari> We're not sure.  It may be audio-related.  He's looking into that now.
[22:29:54] <mru> surely audio related
[22:30:17] <hyc> cool, a 20 gram VGA camera, mounted in a remote control plane http://www.engadget.com/2010/06/03/cheap-tiny-camera-for-rc-planes-captures-video-proof-when-you-b/
[22:30:31] <hyc> stream that live...
[22:30:36] <mru> remember that _anything_ touching floating-point on cortex-a8 can be sped up massively by asm
[22:30:50] <mru> or in some cases by a little type-punning
[22:31:01] <Dark_Shikari> Yeah
[22:31:03] <Dark_Shikari> I know that
[22:31:07] <Dark_Shikari> we may just move celt to pure fixed point
[22:31:21] <mru> and wtf is recvfrom doing with 10%?
[22:31:46] <ohsix> hyc: theres a bunch of even smaller ones on dealextreme, record to microsd :]
[22:32:00] <Dark_Shikari> mru: it's in another thread
[22:32:03] <Dark_Shikari> and we can't control that
[22:32:12] <mru> it just looks wrong
[22:32:18] <Dark_Shikari> also, it _is_ processing tons of data
[22:32:21] <Dark_Shikari> e.g. 6mbps
[22:32:35] <mru> eh, that shouldn't need 10% cpu time
[22:32:39] <Dark_Shikari> yeah yeah
[22:32:44] <Dark_Shikari> our current encoding settings are -b 6M -maxrate 6M -bufsize 1.5M -g 1000000
[22:33:15] <mru> put_pixels is shuffling much more data
[22:33:36] <Dark_Shikari> is there an arm version of mid_pred ?
[22:33:51] <mru> apparently so
[22:34:08] <mru> although gcc is usually better at using conditionals on arm than cmov on x86
[22:34:13] <Dark_Shikari> yup
[22:34:16] <Dark_Shikari> looks like it
[22:34:29] <Dark_Shikari> Is it possible to SIMD that on ARM using ARMv6?
[22:34:40] <Dark_Shikari> I guess it probably wouldn't be worth it
[22:34:48] <mru> simd what?
[22:34:56] <Dark_Shikari> do the two mid_preds at once
[22:34:58] <Dark_Shikari> we do that in x264
[22:35:00] <Dark_Shikari> using mmx
[22:35:07] <mru> hmm
[22:35:09] <Dark_Shikari> but the neon delay is probably too large to make that worthwhile on arm
[22:35:14] <Dark_Shikari> because of the way mid_pred is used in ffmpeg
[22:35:19] <Dark_Shikari> the values are immediately loaded after prediction, always
[22:35:21] <Dark_Shikari> and used
[22:35:35] <mru> what size are they?
[22:35:39] <Dark_Shikari> int16_t
[22:35:58] <mru> so it could possibly be done in armv6 simd
[22:36:06] <mru> which doesn't have the annoying delay
[22:36:12] <Dark_Shikari> but does it have packed comparisons?
[22:36:15] <Dark_Shikari> or packed min/max?
[22:36:37] <mru> are these signed values?
[22:36:40] <Dark_Shikari> yes
[22:36:48] <Dark_Shikari> hence int16_t
[22:37:21] <bcoudurier> I thought the ipad could play 720p at 30fps
[22:37:26] <Dark_Shikari> bcoudurier: with the built-in decoder
[22:37:28] <Dark_Shikari> Which we don't have.
[22:37:41] <Dark_Shikari> it's apple, remember
[22:37:49] <Dark_Shikari> we can't even do 720p at 15fps with ffmpeg h264
[22:37:58] <Dark_Shikari> with cabac and deblock and bframes and weightp and subpel off
[22:38:04] <bcoudurier> ouch
[22:38:14] <Dark_Shikari> so I'm customizing my own video format :)
[22:38:15] <bcoudurier> how is it possible ?
[22:38:22] <Dark_Shikari> how is what possible
[22:38:26] <bcoudurier> the decoder being so slow
[22:38:36] <Dark_Shikari> um... it's a single core arm
[22:38:39] <Dark_Shikari> it's not magic
[22:38:51] <Dark_Shikari> a cortex at 1ghz is not going to be playing HD
[22:38:56] <bcoudurier> oh you mean you cannot access the hardware decoder
[22:38:58] <Dark_Shikari> Yes
[22:39:01] <bcoudurier> make sense
[22:39:05] <Dark_Shikari> it's apple.
[22:39:10] <bcoudurier> fuckers...
[22:39:20] <Dark_Shikari> I'm going to modify h263 to use the h264 transform now
[22:39:29] <bcoudurier> they can't even build a transport stream implementation that works reliably
[22:39:34] <Dark_Shikari> 'course I'll have to modify the quant tables... ugh
[22:40:19] <bcoudurier> I'm not surprise though, they can't even get heir shit together between ipad/iphone/quicktime/fcp
[22:40:28] <bcoudurier> they all have different implementations of mov/mp4
[22:40:29] <Dark_Shikari> ah fuck.  the h263 dequant isn't quite what we want
[22:40:45] <Dark_Shikari> h264 dequant requires multiplying each coeff by a different dequant factor
[22:41:02] <Dark_Shikari> I guess we could use mpeg2 unquant instead
[22:41:35] <ohsix> zomg your new video amalgamation is going to have submarine patents
[22:41:55] <Dark_Shikari> we don't intend to actually use this anywhere except an E3 demo
[22:42:05] <Dark_Shikari> because once we have it working there, we can bitch at apple with more loud voices
[22:42:12] <Dark_Shikari> it's just that we definitely won't get a response from them within two weeks.
[22:42:29] <ohsix> this isn't OnLive related is it?
[22:42:48] <Dark_Shikari> It's onlive-related in the same way that the HD4870 is nVidia-related.
[22:43:23] <ohsix> meh they've just been in the news; its dum though
[22:45:15] <Dark_Shikari> mru: does the arm idct match any particular fdct?
[22:45:27] <mru> simple_idct
[22:45:42] <mru> don't know what that matches
[22:46:04] <mru> assuming you mean the neon one
[22:46:13] <mru> there are so many arm idcts
[22:47:01] <Dark_Shikari> heh
[23:20:19] <Dark_Shikari> mru: does the neon idct have a dc-only case?
[23:20:57] <mru> there's no dc-only indicator
[23:21:11] <Dark_Shikari> yes there is
[23:21:17] <mru> where?
[23:21:26] <Dark_Shikari> Oh fuck, we don't pass it to the idct
[23:21:27] <Dark_Shikari> WTF
[23:21:29] <Dark_Shikari> block_last_index
[23:21:37] <mru> exactly
[23:21:38] <Dark_Shikari> it's KNOWN IN THE DECODER, and used ONE LINE ABOVE THE IDCT CALL
[23:21:44] <mru> that's what I've been bitching about forever
[23:21:55] <Dark_Shikari> I think you could justify changing the function call syntax and adding an extra argument
[23:21:58] <Dark_Shikari> it won't break any existing idcts
[23:22:34] <mru> I'll look into it if you don't
[23:22:36] <mru> but not tonight
[23:22:52] <Dark_Shikari> ok
[23:23:07] <Dark_Shikari> I assume a dc-only idct would be dead simple?
[23:23:15] <mru> utterly trivial
[23:23:32] <mru> multiply by constant and splat
[23:23:35] <Dark_Shikari> Could you write one now if there was no need to even check that it works?
[23:23:41] <Dark_Shikari> I could just add it to the code hackily
[23:23:46] <Dark_Shikari> i.e. add a branch in the C.
[23:23:56] <Dark_Shikari> one moment, let me do some statistics to see how _common_ they are for starters.
[23:24:11] <mru> that's a good start...
[23:29:42] <Dark_Shikari> hmm "sort" is kinda slow on 250MB of input
[23:30:34] <mru> heh
[23:30:46] <Dark_Shikari> I really hope it uses an nlogn sort
[23:33:48] <Dark_Shikari> mru: http://pastebin.org/305160
[23:33:52] <Dark_Shikari> yes, bad sorting order
[23:33:56] <Dark_Shikari> first few hundred frames of an hdtv sequence, quant=6
[23:34:03] <Dark_Shikari> right is last nonzero coefficient
[23:34:05] <Dark_Shikari> (-1 == not coded)
[23:34:07] <Dark_Shikari> left is count
[23:34:18] <Dark_Shikari> I'd say that's a pretty freaking huge proportion of dc-only blocks.
[23:36:20] <iive> aren't they handled specifically in the decoder?
[23:36:26] <Dark_Shikari> That's the point. They're not.
[23:36:45] <iive> i mean, as special case. imho in mpeg(12) they are.
[23:36:51] <Dark_Shikari> Nope.
[23:36:52] <Dark_Shikari> They're not.
[23:37:09] <Dark_Shikari> There is no idct_dc for mpegvideo codecs.
[23:37:10] <Dark_Shikari> Doesn't exist.
[23:37:41] <Dark_Shikari> nor a theora-like idct_small (i.e. only upper left 4x4 block of the dct is coded)
[23:39:44] <Dark_Shikari> mru: what would the multiply be for an idct_dc, so I can write one?
[23:41:11] <Dark_Shikari> the simpleidct code is scary
[23:41:42] <mru> I was about to point at it
[23:42:06] <Dark_Shikari> a0 = W4 * (col[8*0] + ((1<<(COL_SHIFT-1))/W4));
[23:42:08] <Dark_Shikari> wtf is this shit
[23:42:47] <BBB> the asm output of that at anything else than -O0 should be pretty normal
[23:42:57] <Dark_Shikari> oh I mean it's just unreadable
[23:43:04] <BBB> true
[23:44:12] * Dark_Shikari does the math
[23:45:47] <iive> 8*0?
[23:47:39] <iive> oh, right, its column code.
[23:49:20] <Dark_Shikari> mru: are ROW_SHIFT and COL_SHIFT the same as in the c code?
[23:49:33] <Dark_Shikari> and the constants
[23:49:37] <Dark_Shikari> for the arm one
[23:49:45] <Dark_Shikari> yup, looks like it
[23:54:02] <CIA-92> ffmpeg: cehoyos * r23460 /trunk/libavcodec/vorbis_enc.c:
[23:54:02] <CIA-92> ffmpeg: Raise default vorbis encoding quality.
[23:54:02] <CIA-92> ffmpeg: Patch by Frank Barchard, fbarchard google com
[23:58:03] <Dark_Shikari> mru: any chance I can have a neon version of http://pastebin.org/305252 ?
[23:58:16] <Dark_Shikari> it's so trivial that I doubt you'll need to test it.
[23:58:49] <Dark_Shikari> and yes, this is confirmed to be correct for idct_dc