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

[irc at mansr.com]

[06:08:45] <benoit-> good morning !
[06:12:04] <j-b> 'morning
[06:12:10] <av500> 'jour
[06:15:13] <thresh> mourning
[06:17:37] <superdump> mornin
[06:49:34] <hyc> anyone know what goes into the H264 extradata?
[06:49:53] <hyc> still trying to figure out the difference between a program served by DSS vs one served by ffserver
[06:50:09] <merbzt1> SPS ?
[06:50:19] <wbs> SPS and PPS, yes
[06:50:20] <hyc> the only significant difference in the SDP is this
[06:50:48] <hyc> sprop-parameter-sets=Z0LAFZpyA8EdCAAAAwAIAAADAYB4sXJA,aM4yyA==
[06:50:52] <hyc> G1 rejects that
[06:51:06] <hyc> sprop-parameter-sets=Z0LAFZpyA8Ef1gIgAAADACAAAAYB4sXJ,aM4yyA==
[06:51:11] <hyc> G1 accepts that.
[06:51:49] <hyc> but as near as I can tell, I have the identical vcodec options passed to ffmpeg in both cases
[06:52:14] <hyc> the working case is produced by ffmpeg feeding to DSS over rtsp
[06:52:30] <hyc> the non-working case is ffmpeg feeding to ffserver / ffm
[06:53:11] <hyc> feeding to DSS:
[06:53:14] <merbzt1> is the SDP string BASE64 encoded ?
[06:53:27] <hyc> looks like it, yes
[06:54:07] <hyc> ./ffmpeg -i test.flv -vcodec libx264 -b 300000 -vpre default -vpre baseline -s 480x270 -acodec copy -re -f rtsp rtsp://localhost/test.sdp
[06:54:20] <hyc> that works
[06:55:18] <Dark_Shikari> if you want CBR, you probably want maxrate/bufsize too.
[06:55:21] <hyc> ./ffmpeg -i test.flv -threads 0 http://192.168.1.25:8090/feed1.ffm
[06:55:40] <hyc> this obviously depends on the settings in ffserver.conf
[06:55:54] <hyc> I copied in all of the vpre settings so it should be identical
[06:55:56] <hyc> and yet it's not
[06:56:45] <hyc> ffserver was using CBR by default, and that still didn't work
[07:05:06] <hyc> so how do I correlate this encoded SPS back to the x264 encoder settings?
[07:09:18] <Dark_Shikari> hyc: you're better off looking at the SEI
[07:09:26] <Dark_Shikari> Which ffmpeg conveniently prints for you on stderr.
[07:10:12] <hyc> Dark_Shikari: I've been looking but I thought they were identical already
[07:10:18] <hyc> lemme pastebin...
[07:11:41] <hyc> here's the working invocation http://hyc.pastebin.com/C8qgN8cE
[07:13:35] <hyc> here's the non-working ... http://hyc.pastebin.com/RR7pK635
[07:14:21] <Dark_Shikari> wtf is with that ratetol
[07:14:49] <hyc> dunno, ffmpeg and ffserver provide it by default
[07:15:01] <Dark_Shikari> you mean that you forgot to set it correctly
[07:15:02] <Dark_Shikari> also neither has vbv set
[07:15:17] <hyc> I've been pecking at it to get ffserver to match the ffmpeg output
[07:15:31] <hyc> ffserver had vbv set by default, I turned it off to make the output match up
[07:15:49] <hyc> ffserver also defaulted to cbr
[07:16:42] <hyc> but none of that made a difference, the G1 still quits as soon as it reads the sdp
[07:17:36] <hyc> (and it works fine with audio-only)
[07:18:21] <Dark_Shikari> >defaulted to cbr
[07:18:23] <Dark_Shikari> it says "abr" here
[07:18:28] <Dark_Shikari> and yes this is probably not related to your problem
[07:18:40] <hyc> right, I #if'd out that code in ffserver so that it would use abr
[07:18:58] <hyc> this is several iterations from where it started...
[07:24:02] <hyc> so, any suggestions on how to approach this?
[07:25:17] <Dark_Shikari> sounds like a protocol/muxer issue
[07:28:21] <pJok> mornings :)
[07:34:17] <KotH> a wonderfull good morning everyone!
[07:34:24] <thresh> :(
[07:34:31] <kshishkov> goda morgnar, pJok
[07:34:43] * KotH gives thresh some swiss chocolate
[07:34:44] <kshishkov> KotH: looks like you're wrong again
[07:34:56] <thresh> KotH: not a big fan :)
[07:35:01] <KotH> kshishkov: no problem that a bit of swiss chocolate cannot solve! :)
[07:35:16] <thresh> really tough weekend + almost no sleep for two days
[07:35:34] <Dark_Shikari> speaking of sleep, I should take a few hours nap before finishing packing
[07:35:51] <Dark_Shikari> spent all of today reading on2 code, it wears out the mind.
[07:36:52] <kshishkov> KotH: try diabetes or allergy
[07:37:01] <Dark_Shikari> and worse, on2 specs
[07:37:10] <kshishkov> Dark_Shikari: why would you do that?
[07:37:29] <av500> VP9!!!!
[07:37:39] <hyc> lol
[07:38:10] <hyc> kinda how I feel after all this beating on ffserver
[07:38:16] <KotH> kshishkov: the people i know who've diabetes, always carry a bar of chocolate with them :)
[07:38:18] <Dark_Shikari> kshishkov: so I can beat the shit out of it in a detailed blog post on wednesday
[07:39:01] <KotH> kshishkov: and as for allergy... i've never hread that anyone has a chocolate allergy
[07:39:29] <wbs> KotH: my girlfriend is allergic to chocolate
[07:39:39] <KotH> wbs: huh?
[07:40:57] <KotH> wbs: poor girl...
[07:41:27] <wbs> KotH: not the "deadly if eaten" kind of allergy, though, it just makes her itch a bit
[07:41:36] <wbs> just as does peppers and onion and a few other vegetables
[07:41:44] <wbs> a bit of antihistamines and everything's fine again
[07:41:44] <kshishkov> garlic?
[07:42:08] <av500> in swiss chocoloate?
[07:42:09] <wbs> kshishkov: hmm, don't remember about that, but perhaps yes
[07:42:28] <kshishkov> wbs: silver? holy sulphuric acid?
[07:42:49] <pJok> goda morgonar, kshishkov :)
[07:42:57] <KotH> wbs: you sure it's an allergy to chocolate and not to nuts?
[07:42:58] <kshishkov> av500: if not in Swiss chocolate then in Japanese one for sure
[07:42:58] <hyc> a girl I grew up with was allergic to chocolate. she ate a piece of chocolate cake and vomited a few minutes later. nasty...
[07:43:15] <av500> nice end to a romantic diner...
[07:43:46] <wbs> KotH: nuts is a problem too, but I think the raw cocoa has the same effect, too
[07:44:17] <KotH> hmm.. strange
[07:44:21] <KotH> first time i hear that
[07:44:32] <KotH> hyc: you sure it's not some psychosomatic form of bullemia? ;)
[07:45:12] <wbs> kshishkov: no problems with silver as far as I know :-)
[07:45:52] <hyc> no idea, this is 30-some years ago, that wasn't trendy then
[07:47:02] <kshishkov> wbs: fine. Although your Fazer chocolate is rather good.
[07:47:50] <wbs> kshishkov: yeah, fazer's blue is fantastic. :-)
[07:49:47] <spaam> so this is the new chocolate channel? :D
[07:51:16] <spaam> blame KotH for that ..
[07:51:43] <KotH> spaam: trying to get the blame to other people?
[07:52:19] <spaam> yes.
[07:52:31] <spaam> but i was right :)
[07:53:48] * KotH kicks spaam
[07:53:51] <KotH> no, you're not
[07:54:16] <spaam> dont kick me!
[07:54:43] <spaam> its always you when someone speak about chocolate..
[07:54:52] <spaam> you live in .ch :P
[08:00:06] <KotH> ofc, i know why i live here
[08:00:33] <av500> KotH: speaking of chocolate...
[08:01:27] * KotH knows
[08:01:38] * KotH has not forgotten about it
[08:01:41] <av500> :)
[08:01:53] <KotH> i just didnt had time to go to the good shops yet
[08:01:55] <KotH> :-(
[08:03:01] <spaam> poor thing. :(
[08:06:04] * kshishkov now lives in little Switzerland too
[08:09:52] <kshishkov> it's so Swiss that in the nearest supermarket people say "Salaam aleikum"
[08:16:18] <av500> kshishkov: you met KotH in your supermarket?
[08:16:48] <spaam> av500: do you think KotH working there? :D
[08:18:20] <kshishkov> av500: no, but I can recognize that name like "Abdul Kerim" is Swiss when I see one
[09:54:49] <CIA-7> ffmpeg: benoit * r23150 /trunk/libavcodec/raw.c: Fix typo ('B', 'O', 'W', '1') => ('B', '0', 'W', '1')
[10:39:35] <hyc> Well, I have ffserver working with my G1 now
[10:39:46] <hyc> but I have to figure out which of a bunch of changes was responsible...
[10:48:18] <Tjoppen> no Bultje here atm it seems. I'd ask him to review my updated HTTP patch
[10:48:43] <kshishkov> Tjoppen, he usually appears here at 14-15 CET
[10:48:57] <Tjoppen> ah, ok
[11:22:48] <av500> ... at tataelxsi.co.in  why am I not surprised....
[11:23:12] <kshishkov> why should you?
[11:29:46] <jai> :)
[11:33:59] <wbs> hyc: the SDP/ffserver hack you posted...
[11:34:57] <wbs> hyc: can you solve it within ffserver instead? e.g. something like this: http://pastebin.org/243967
[11:36:29] <wbs> hyc: the sdp generator can emit the c= line at a few different places, and your patch would make it emit that line redundantly/erroneously at some places
[11:41:10] <hyc> wbs: hmmm.... I'll take a look
[11:42:37] <hyc> your patch isn't quite right. we just need an IP address, not an rtp URL
[11:43:55] <hyc> ohhhhh
[11:43:57] <hyc> I see.
[11:44:16] <hyc> you pass in the URL and avf_sdp_create puts an address there
[11:44:21] <wbs> exactly
[11:44:33] <hyc> ok, lemme try that
[11:44:51] <hyc> can't we put the actual interface address of the incoming connection?
[11:44:58] <hyc> this is the server's address, right?
[11:45:23] <wbs> yes, but this should be the remote peer's address iirc
[11:45:58] <hyc> the rfc language takes several re-reads to understand that point
[11:46:14] <hyc> or I'm just tired from staring at this for the past 20 hours
[11:48:21] <hyc> hmm. rtsp_cmd_describe already uses getsockname to get the local address
[11:49:11] <hyc> ok this should be easy then
[11:49:35] <wbs> nevertheless - SDP is used for describing RTP sessions in general - when RTSP is used for setting it all up, the destination address is implied in that, and the server usually just sets 0.0.0.0 there
[11:50:29] <hyc> so you think 0.0.0.0 is still fine?
[11:50:50] <hyc> easy enough to call inet_ntoa here, just like for the multicast addr
[11:51:05] <wbs> 0.0.0.0 should be fine for unicast, yes
[11:51:10] <hyc> ok
[11:54:54] <hyc> yeah, that works fine
[11:55:17] <hyc> should I followup my email or should you?
[11:55:35] <wbs> ok, great, that has a much higher chance of getting accepted :-)
[11:55:56] <wbs> did you do the same modification as I showed on pastebin, or were there any modifications? i didn't even test compile it
[11:56:07] <wbs> but I can post a follow-up now at least
[11:56:08] <hyc> exactly what you pasted
[11:57:39] <wbs> ok, I'll post that to the list then
[11:57:53] <hyc> cool
[11:59:02] <hyc> it's still not all perfect. mplayer shows an endless stream of "non-existing PPS referenced" when playing a/v
[11:59:29] <hyc> ffplay logs that too, but not as annoyingly
[11:59:46] <wbs> yeah, I think I've seen that in all cases of h264/rtp
[12:00:40] <hyc> hm, ok
[12:01:01] <hyc> well, it's all streaming nicely to my phone, and that's all that I cared about ;)
[12:01:06] <wbs> :-)
[12:02:14] <Compn> there was a patch for that pps thing i thought ?
[12:02:28] <hyc> really? is it recent? perhaps I need to svn up
[12:02:49] <wbs> no, I still get those warnings with the latest stuff
[12:02:55] <hyc> ffserver is still a pig though, eating 100% CPU
[12:03:10] <hyc> that's one really nasty input loop....
[12:04:00] <hyc> I might try disabling chunked encoding and see if that lightens the load. is there any paraticular benefit to chunked encoding here?
[12:04:10] <merbzt1> ffserver ACL is buggy also
[12:04:16] <merbzt1> feel free to fix
[12:27:37] <hyc> all of it is buggy...
[12:27:56] <hyc> plenty to fix, not much time though
[12:28:23] <hyc> speaking of which, on its RTSP/HTTP headers it responds with the date/time in localtime but with a GMT designation
[12:28:30] <hyc> pretty silly
[12:35:37] <hyc> wbs: thanks again for all your help
[12:36:17] <wbs> hyc: no problem, it's more or less the same things I've fought lately :-)
[12:37:40] <hyc> yeah well it's always easier when you know someone else has hit the problems. then it's not just you being a dummy... ;)
[13:27:43] <BBB> wbs: for patch #1, is it possible to position rtp_parse_packet_internal() above rtp_parse_packet()? that way, you don't need the ugly fw function declaration
[13:28:08] <wbs> BBB: yes, fully possible, but the diff is much smaller that way. I'll change it that way if you prefer that
[13:28:23] <BBB> diff size for cosmetic patches isn't all that important to me...
[13:28:32] <BBB> as long as they're just cosmetic :)
[13:29:22] <wbs> yeah, but since it's both split + move, it's a bit harder to see whether anything was changed in the move or not... since the function preamble and the variable declarations are changed anyway
[13:29:38] <wbs> and for the noreorder thing, yes, that can be passed as a parameter, too
[13:29:51] <BBB> I'm nitpicking there ...
[13:29:59] <BBB> I'm reviewing patch #2 right now, that's the actual patch
[13:30:04] <BBB> I like most of it
[13:30:24] <BBB> can you document the 4 variables in a doxy block, and then each individually?
[13:30:42] <BBB> like /** stuff for packet reordering\n@{*/
[13:30:54] <BBB> and then /**@} */ at the end
[13:31:01] <wbs> do you have any opinion on the thing that luca a pointed out - how to pass the desire from the user not to have any reordering, or to specify a max queue length?
[13:31:07] <BBB> and then document each variable that you added to rtp.h
[13:31:19] <wbs> ah, that's a good idea, too. I'm not that familiar with advanced doxygen syntax :-)
[13:31:32] <BBB> wbs: I think that is a similar issue as things like passing tcp/udp as a preference
[13:31:50] <BBB> we don't really do that, we should, keep that in mind while designing it but I don't have a clear answer on how it should be done
[13:31:57] <wbs> ok
[13:32:03] <BBB> I think we need an AVOptions passed to demuxers for demux-specific options
[13:32:06] <BBB> like tcp, udp, etc.
[13:32:12] <BBB> and then integration of that in ffmpeg.c/ffplay.c
[13:32:15] <BBB> but that's a lot of work
[13:32:20] <BBB> I don't want to require you to do that for this
[13:32:52] <wbs> so as long as the max queue length is dynamic in the external interface of rtpdec, the rest is another problem to solve
[13:33:20] <BBB> add a max as a variable, or as a define (for now)
[13:33:26] <BBB> make sure it doesn't grow to infinity
[13:33:29] <BBB> then it's fine, yes
[13:34:26] <wbs> ok
[13:34:40] <wbs> thanks for the input, I'll probably fix those things later today
[13:35:37] <BBB> ok
[13:35:39] <wbs> as a side note, ffplay is notoriously bad at playing rtsp stuff; -noframedrop usually is required, and since it sometimes waits quite long between av_read_frame() calls, it may easily drop packets when using UDP
[13:35:45] <BBB> if you're interested I can lay out this whole demux-specific options
[13:35:53] <BBB> it's a big FIXME and I'm trying to motivate people (or myself) to do it
[13:36:08] <BBB> ffplay always worked fine for me...
[13:36:10] <BBB> not sure what's wrong
[13:36:14] <BBB> we might want to look into that
[13:36:20] <BBB> maybe it's related to all the timestamp fixings lately
[13:36:23] <BBB> they might've broken things
[13:36:36] <wbs> no, things were broken both before and after that
[13:37:01] <wbs> the frame dropping introduced in march (iirc) has some problems in some cases, I think luca a ran into it with v4l devices, too
[13:37:40] <wbs> I guess it's common to all realtime sources
[13:41:53] <BBB> hm...
[13:42:02] <BBB> I haven't looked lately but don't remember that form last year
[13:42:05] <BBB> let's look into that
[13:42:07] <BBB> I'll give it a go also
[13:42:13] <BBB> demuxing should be flawless
[13:42:22] <wbs> yes, the demuxing works just fine
[13:42:41] <wbs> the frame dropping was added quite only a few months ago
[13:43:14] <wbs> either when starting a rtsp stream, or after seeking, things may either work well, or start stuttering, or stop completely
[13:44:15] <wbs> the timestamps of the returned packets are correct, but if they are returned slightly too late (e.g. blocking a second before the first packet), ffplay notices that it's processing a packet with timestamp 0, while it should be at play time around (e.g.) 1 second
[13:44:44] <wbs> so it notices that it's behind and drops the frame in order to get back up to speed
[13:44:58] <wbs> but since the source is a realtime source, you can't advance faster by skipping frames
[13:57:54] <BBB> wbs: right... we need to work on fixing that
[14:07:48] <BBB> wbs: is prev_ret to distinguish handling of internal parsers returning versus you returning 1 because of multiple packets in-queue?
[14:08:09] <wbs> BBB: yeah, exactly
[14:08:22] <BBB> because if that's the case, I think A) it should be documented, B) it should check that it's != 0, but that it's == 1
[14:08:29] <BBB> you're forgetting the < 0 return case
[14:08:46] <wbs> ah, yeah
[14:09:08] <BBB> also, the rv | has_more_packets(); handling isn't right
[14:09:17] <BBB> it should use ||, not |
[14:09:29] <BBB> i.e. if rv = 1 or -1 or anything < 0, it should return just that
[14:09:36] <BBB> it should only return 0/1 for more packets if rv == 0
[14:09:59] <wbs> hmm, that works too - currently, if rv is either 1 or -1, | 1 doesn't do anything
[14:10:09] <wbs> but using || probably is neater
[14:12:02] <BBB> I'm affraid if you return anything else <0, it might confuse the error code
[14:12:10] <BBB> if it's even and we have packets left, |1 will make it odd
[14:12:13] <BBB> so it changes the errno
[14:12:17] <wbs> true
[14:12:54] <BBB> enqueue_packet() laeks memory if we're dropping the last packet
[14:13:53] <BBB> can you document what the intended handling is in case we actually really lost a packet?
[14:14:12] <BBB> should we wait forever until it comes in? should we just go with whatever we have and drop if it comes in later?
[14:14:16] <BBB> is there code handling this?
[14:14:22] <wbs> hmm, i don't see how it could leak anything
[14:14:28] <BBB> if queue_len = 10
[14:14:38] <BBB> and I insert in position 5
[14:14:47] <BBB> I move 6-10 to 7-10 and drop old#10/new#11
[14:15:04] <wbs> no, the queue will never get that full
[14:15:18] <wbs> since after enquing one packet, we consume the first one if the packet became full
[14:15:20] <BBB> oh I see the code after enqueue_packet() always empties it if it's full
[14:15:33] <BBB> ok that's good
[14:15:50] <wbs> and if we totally miss a packet, the queue will fill up
[14:15:53] <BBB> can you assert that queue_len < MAX_QUEUE_LEN in enqueue_packet?
[14:15:59] <BBB> just to make clear that's the intended behaviour
[14:15:59] <wbs> sure
[14:16:20] <wbs> and if we actually receive the missed packet sometimes later, we ignore it
[14:16:28] <BBB> looks pretty good then
[14:16:34] <wbs> that way, we get just one discontinuity instead of 3
[14:16:37] <BBB> yes
[14:17:17] <BBB> ok, can you please document that a little bit clearer (in enqueue_packet, refer to rtp_parse_packet(), and in rtp_parse_packet() that code block, document it in actual works for the people with a short memory like me)
[14:17:42] <BBB> and I think then it should be fine
[14:18:00] <wbs> great, thanks!
[14:18:12] <wbs> I'll go through this later tonight, hopefully, and resend it then
[14:18:22] <BBB> ok, take your time, thanks for this patch, another long-awaited one
[14:25:24] <Tjoppen> BBB: did you get a chance to look at my revised HTTP patches?
[14:26:20] <BBB> a little, but not completely
[14:26:26] <BBB> I'll try to re-look today
[14:26:27] <BBB> sorry :(
[14:27:48] <Tjoppen> np :)
[14:31:40] <BBB> heya spyfeng
[14:31:50] <Tjoppen> ooh, NetBeans 6.8 can create new projects from CMakeLists.txt files
[14:31:51] <BBB> did michael already ok your mms-tcp patch?
[14:33:10] <kshishkov> BBB, have you worked on supporting different interleavers for RM?
[14:34:51] <BBB> no
[14:35:01] <kshishkov> we may need it
[14:35:19] <av500> we need RM?
[14:36:07] <kshishkov> yep, for completeness sake
[14:36:50] <kshishkov> and if you ask that question then Archos is not popular in China
[14:37:59] <kierank> presumably chinese will use AVS in rm?
[14:38:21] <kshishkov> only if Buffering Inc. will cripple it into RV5
[14:40:09] <av500> kshishkov: it is, but we do not encode, just play back :)
[14:40:10] <kierank> rv5 will be a prototype of h.264
[14:40:15] <kierank> h.265*
[14:40:43] <kshishkov> vice versa
[14:41:00] <kshishkov> and it should have 1/5th pel MC
[14:42:23] <Dark_Shikari> well, samsung+bbc has 1/12th pel
[14:42:45] <kshishkov> we'll leave that for RV12
[14:46:16] <av500> kshishkov: why limit at 1/12, just use a "float", its all the rage these days...
[14:46:40] <mru> floating pixels
[14:47:01] <av500> mru: you recovered!
[14:47:12] <kshishkov> av500: rv2 used 1/2 pel MC, rv3 used 1/3 pel MC, rv4 used 1/4 pel MC, guess the sequence
[14:47:38] <mru> recovered? I've done nothing to recover from...
[14:48:20] <av500> btw, you are missing #beagleboard-gsoc atm
[14:48:41] <av500> (all hands meeting)
[14:49:26] <mru> too many channels
[14:49:33] <mru> can't keep track of it all
[14:49:41] <av500> hire a secretary
[14:50:07] <av500> one that prints out irc, brings it over to the pool for you to read....
[14:50:08] <kshishkov> and caddy body for shotguns
[15:06:11] * BBB lols at Buffering Inc.
[16:49:44] <BBB> Tjoppen: can you send me an actual test-case so I can test+fix it myself? I think this can be done simpler. ideally something I can test against apache or so, or ffserver or whatever you wish
[16:52:27] <Tjoppen> hm. I'll look into it
[16:53:28] <Tjoppen> I might have a bare bones microhttpd based thing lying aruond
[16:56:01] <Tjoppen> actually, I think there's an example that comes with that library that'll do
[16:57:11] <BBB> ok, I'll look into it again once I have the test then, thanks
[17:24:30] <mchinen> Hey all, I'm Michael Chinen, doing the seeking api for gsoc 2010
[17:24:44] <mchinen> I never introduced myself before, tho i've chatted a bit
[17:26:14] <mchinen> was thinking to discuss the design for the index table to be used with the new api
[17:26:59] <mchinen> What's the best place to discuss? irc? ffmpeg-devel mlist?  ffmpeg-soc list?
[17:28:04] <wbs> irc is good, as long as there are some authoritive or otherwise knowledgeable discussion partners available :-)
[17:28:46] <mchinen> aha.  another thing is that I don't know whose irc nicks correspond to devs
[17:29:07] <wbs> just use /whois, many have sensible realnames set
[17:29:26] * mru is the troll
[17:30:32] <mchinen> okay, thanks
[17:31:29] <mchinen> i guess i'll just start asking when they don't have a real name in whois
[17:33:22] <BBB> your mentor's nick is bcoudurier
[17:33:29] <BBB> but he's in CA so he
[17:33:29] <BBB> 's
[17:33:32] <BBB> still asleep
[17:33:48] <wbs> BBB: he replied to a mail on the ML 10 minutes ago actually
[17:33:50] <mchinen> ah, yes.
[17:33:56] <BBB> actually he did
[17:34:01] <BBB> I guess he dislikes IRC today
[17:34:35] <mchinen> maybe this project can help me to devlop such bad sleep patterns that it won't be an issue
[17:35:05] <av500> bad sleep is guaranteed
[17:35:10] <CIA-7> ffmpeg: mstorsjo * r23151 /trunk/ffserver.c:
[17:35:10] <CIA-7> ffmpeg: ffserver: Make sure a destination URL is set when creating the SDP
[17:35:10] <CIA-7> ffmpeg: Debugged by Howard Chu, hyc at highlandsun dot com.
[17:37:36] <BBB> mchinen: your project is seeking, right?
[17:37:49] <mchinen> BBB:yes
[17:38:29] <mchinen> I've read through a bunch of the existing code so far
[17:38:40] <BBB> was there ever general agreement on the direction that you'll be taking it into?
[17:38:47] <BBB> I remember there being some disagreement about that in the past
[17:38:57] <BBB> did you and your mentor discuss that, so that there's a clear plan?
[17:39:20] <BBB> I mean, the worst possible thing that could happen is that soc starts, you start coding and all of a sudden we go like "wait that's not what we thought you'd do!"
[17:39:29] <mchinen> Yeah, basically provide accurate seeking interface implemented on five or six popular formats
[17:39:36] <BBB> ok
[17:39:59] <mchinen> yes, this also one reason I thought to discuss publicly
[17:42:53] <BBB> it's good you come in, now at least (almost) all soc students are on irc :)
[17:44:01] <mchinen> ah, I didn't know the party had started
[17:44:18] <mchinen> but yes, its good
[17:44:49] <mchinen> i notice svn commits on ffmpeg-soc
[17:44:55] <mchinen> what's this about? branches?
[17:45:26] <wbs> BBB: hmm, btw, regarding the "return rv || has_next_packet(s);" that we discussed earlier - i'm not sure that does what you'd want
[17:45:57] <wbs> BBB: if rv is e.g. -4, evaluating "rv || has_next_packet(s);" may return just 1, since the toplevel || is true
[17:46:13] <wbs> instead of passing the original rv through as intended
[17:46:33] <_troll_> s/may return/returns/
[17:47:09] <wbs> so to get the desired effect, we'd have to do "if (!rv) return has_next_packet(s); return rv;"
[17:47:34] <wbs> or "return rv ? rv : has_next_packet(s);"
[17:47:49] <_troll_> yes, either would do
[17:48:35] <_troll_> in Perl you'd use the 'or' operator
[17:58:19] <BBB> wbs: oh, right
[17:58:32] <BBB> wbs: well, but you see what I meant about | being wrong right? ;)
[17:58:46] <BBB> || is wrong also, unfortunate that C doesn't have a good operator like that
[17:59:01] <wbs> BBB: yeah, it can mess things up too, but would actually handle the cases -1, 0 and 1 properly
[17:59:11] <BBB> but not -2 ;)
[17:59:18] <wbs> nope :_)
[18:00:45] <wbs> also, your comment on handling of prev_ret, the current if (!s->prev_ret) return rtp_parse_queued_packet(s, pkt); should be ok as far as I can see
[18:01:02] <wbs> that is, only if the previous code returned exactly 0, we try to dequeue a packet
[18:02:20] <wbs> I think you missed some negation in the thing you said earlier:
[18:02:22] <wbs> 17:07 <BBB> wbs: is prev_ret to distinguish handling of internal parsers returning versus you returning 1 because of multiple packets in-queue?
[18:02:25] <wbs> 17:08 <BBB> because if that's the case, I think A) it should be documented, B) it should check that it's != 0, but that it's == 1
[18:02:28] <wbs> 17:08 <BBB> you're forgetting the < 0 return case
[18:11:04] <DonDiego> mmu_screen: so one C89 patch was enough to fix the beos port?
[18:13:44] <bcoudurier> hi guys
[18:13:50] <CIA-7> ffmpeg: bcoudurier * r23152 /trunk/libavformat/matroskadec.c: set avg frame rate in mkv demuxer
[18:14:20] <bcoudurier> Dark_Shikari, can you retry the codec copy from mkv ?
[18:18:47] <BBB> wbs: yeah, I think that's ok
[18:18:54] <BBB> wbs: I missed that in the first few things I said
[18:28:51] <Dark_Shikari> bcoudurier: ok
[19:01:07] <lu_zero> hi
[19:01:13] <lu_zero> what I'm missing today?
[19:03:15] <wbs> lu_zero: do you have any idea of why one would want to intentionally send rtp packets out of order?
[19:05:04] <lu_zero> want?
[19:05:13] <lu_zero> might happen in one case
[19:05:34] <lu_zero> producer -> bad network -> receiver -> server -> client
[19:06:06] <lu_zero> the receiver tries its best but the bad network does misorder packets
[19:06:50] <lu_zero> you might assume the client fares better if it gets all the packets even if they are misordered
[19:07:30] <lu_zero> (and you have a reorder buffer there and you have it large enough to actually do the reorder)
[19:08:22] <lu_zero> when you had this experience?
[19:23:31] <wbs> lu_zero: I've got a youtube rtsp video that consequently sends packets out of order, almost as if it is intentionally
[19:23:53] <wbs> lu_zero: doesn't seem to support tcp interleaving though, so I can't test whether it actually sends them in that order
[19:34:29] <lu_zero> want me to check on my side to see if different networks get the packets in different order?
[19:34:37] <wbs> sure
[19:34:44] <wbs> rtsp://v4.cache7.c.youtube.com/CkYLENy73wIaPQlAxD6Aps4FuxMYEiASFEIJbXYtZ29vZ2xlSARSBWluZGV4Wg5DbGlja1RodW1ibmFpbGD82u-DktbbwUsM/0/0/0/video.3gp
[19:34:59] <elenril> bcoudurier: OMG did you just fix the most annonying bug in ffmpeg
[19:35:52] <Dark_Shikari> WOOOOT
[19:35:54] <Dark_Shikari> IT WORKS
[19:35:57] <Dark_Shikari> THANK YOU SO MUCH bcoudurier
[19:35:59] <Dark_Shikari> THANK YOU
[19:36:02] <av500> st->avg_frame_rate = av_d2q(1000000000.0/track->default_duration, INT_MAX); ???
[19:36:27] <mru> does that fix -vcodec copy?
[19:36:36] <bcoudurier> :)
[19:37:03] <elenril> \\\o///
[19:37:21] <mru> and there was much rejoicing
[19:37:50] <av500> err, so ffmpeg is all about pts and dts and VFR and then it needs an average frame rate to work?
[19:38:22] <ramiro> what bug did that fix?
[19:38:32] <mru> lavf seems to grow a new timebase/framerate every 6 months
[19:39:03] <bcoudurier> we never had avg frame rate
[19:39:18] <mru> eh? avg_frame_rate...
[19:39:26] <lu_zero> uhmmmm
[19:39:30] <bcoudurier> it's recent
[19:39:46] <lu_zero> wbs: the 106 one?
[19:39:46] <elenril> wait, system ffmpeg works too
[19:40:21] <elenril> so it was fixed earlier
[19:40:35] <mru> we have time_base, avg_frame_rate, and r_frame_rate in struct AVStream
[19:40:44] <mru> and a few more variants made up on the fly
[19:40:55] <wbs> lu_zero: no, 105.. I just watched that one
[19:41:07] <wbs> lu_zero: since the format in 106 isn't supported
[19:41:11] <bcoudurier> that's exact and they represent different things
[19:42:05] * av500 just remuxed his 1st mkv into something else using ffmpeg....
[19:42:10] <lu_zero> wbs: uhm?
[19:42:16] <lu_zero> 106 should be h264
[19:42:33] * lu_zero is messing up with wireshark 
[19:42:44] <wbs> 105 is h264 here, 106 is mp4a-latm
[19:42:53] <wbs> but nevertheless, both are non-monotonic
[19:43:04] <lu_zero> same here
[19:43:17] <wbs> and quite systematically non-monotonic, not random in any way
[19:44:19] <lu_zero> I should check what happens with the pvcore implementation
[19:44:45] <av500> hmm, almost: [matroska @ 0x8b673b0]st:1 error, non monotone timestamps 13 >= 13
[19:45:10] <wbs> lu_zero: I think hyc said that it worked on android phones
[19:47:27] <lu_zero> ffplay pukes, vlc+live555 uses lots of concealment, mplayer+nemesi uses lots of concealment as well
[19:48:11] <av500> hmm, no, remuxing mkv still does not work, and where it worked, it was working before 23152...
[19:48:27] <lu_zero> am I wrong or it doesn't handle seek?
[19:49:34] <wbs> haven't checked seeking at all
[19:51:41] <bcoudurier> av500 can you please share your file ?
[19:52:05] <av500> I found one file where the fix helps
[19:57:24] <lu_zero> ok, vlc seek is ok, libnemesi issue pauses with a range and that triggers badrequest...
[19:57:56] <lu_zero> ffplay needs a *bit* of time to discover it can decode h264...
[20:03:25] <av500> bcoudurier: it is uploading: /MPlayer/incoming/mkv_cannot_remux_for_bcoudurier/atlantis405-test.mkv
[20:03:44] <bcoudurier> thanks
[20:10:44] <av500> bcoudurier: I did: ffmpeg -i atlantis405-test.mkv  -vcodec copy -an test.[mp4|mkv]
[20:14:20] <bcoudurier> I have to wait until the script change the perms
[20:14:23] <bcoudurier> !
[20:14:39] * av500 summons mru
[20:17:21] * av500 feeds the _troll_ a cookie
[20:18:04] <bcoudurier> great
[20:18:06] <bcoudurier> thanks
[20:20:28] <saintd3v> av500: please don't feed the _troll_
[20:20:33] <bcoudurier> well no default duration in your file
[20:20:40] <bcoudurier> and the h264 stream has no time base
[20:20:56] <mru> bcoudurier: perms fixed
[20:21:16] <bcoudurier> yup, noticed, thanks
[20:25:56] <kierank> so...did anybody get a chance to look at that h.264 decoding bug I reported
[20:27:33] * mmu_screen slaps DonDiego 
[20:27:35] <mmu_screen> no
[20:28:34] <mmu_screen> I've got an alternate workaround for those PRI* macros, but first I want to make sure the haiku part in configure works so I can commit the split patch
[20:29:05] <mmu_screen> but the R1/alpha2 I installed seems crashprone :^)
[20:29:16] <bcoudurier> av500, no luck with this file, it will work only if the file has num_reorder_frames set
[20:31:30] * mru thought beos was non-existence-prone
[20:33:53] * mmu_screen unmaps the stacks of mru and removes gdb
[20:34:07] <mmu_screen> usually it works quite well :D
[20:34:30] <lu_zero> beos is a nifty idea with a half decent implementation
[20:34:45] <lu_zero> pity that didn't get enough support to improve
[20:34:48] <mmu_screen> hopefully Haiku is much more decent
[20:34:52] <mru> it can be as nifty as it likes, if it has no users it's still irrelevant
[20:34:58] <mmu_screen> lu_zero: Haiku is opensource, you can send a patch :D
[20:35:31] <lu_zero> mmu_screen: I try to not dabble with C++ ^^;
[20:36:03] <mru> making the primary OS interface c++ was probably a big mistake
[20:36:24] <lu_zero> I'm not proficient enough to try to write something sane and I have doubts anything sane could be done with the current tools/standard nonetheless...
[20:36:39] <mmu_screen> tsssk
[20:36:55] * lu_zero wonders if llvm will help or damage in that field
[20:37:14] <lu_zero> their libc++ seems working properly
[20:37:18] * mmu_screen delete mru;
[20:37:30] <mmu_screen> lu_zero: I heard that clang now builds itself with c++
[20:37:39] <lu_zero> yup
[20:37:54] <mru> mmu_screen: syntax error
[20:38:03] <mmu_screen> the BeAPI is quite clean despite being C++
[20:38:13] <mru> that's an oxymoron
[20:38:15] <lu_zero> I'm afraid of llvm since I'm afraid of everything written in C++
[20:38:17] <mmu_screen> no 10-lines templates like in Boost
[20:38:21] <mru> and it doesn't matter how clean it is
[20:38:23] <mmu_screen> pfff
[20:38:28] <mru> forcing people to use c++ is a mistake
[20:38:45] <lu_zero> mmu_screen: I know, beos is probably one of the first system I written something for
[20:38:47] <mmu_screen> trying to do OO stuff in C isn't usually much better
[20:38:50] * mmu_screen pets QEMU
[20:38:59] * mmu_screen throws GTK away
[20:39:11] * lu_zero looks at gobject
[20:39:51] <mmu_screen> lu_zero: btw there are bindings being developped, there is a Qt port now (ok C++ too, and even uglier), there is GUI support for BePascal
[20:40:29] <lu_zero> mmu_screen: I know haiku is getting more and more functional =)
[20:40:32] <mru> keeping the base system interfaces in C is a good thing
[20:40:34] <mmu_screen> I should write a macro for irssi since we already had this troll like 10 times
[20:40:37] <mru> everything is based on C
[20:41:01] <mmu_screen> lu_zero: the Kernel Kit is C only, drivers use a C interface (but can be written in C++)
[20:41:11] <lu_zero> uh?
[20:41:25] <lu_zero> really?
[20:41:39] <lu_zero> I thought that the kernel was C++ as well
[20:41:40] <mmu_screen> http://www.haiku-os.org/legacy-docs/bebook/TheKernelKit_ThreadsAndTeams.html
[20:41:59] <mmu_screen> it has some blobs but the interfaces are plain C
[20:42:13] <mmu_screen> anyway, shower
[20:43:23] <mru> yes, clean those ugly thoughts from your mind
[20:44:15] * mmu_screen has pictures of mru compromising himself with C++
[20:44:32] <mmu_screen> ugh, frightening
[20:47:45] <lu_zero> mru would write embedded asm there as well =P
[20:51:07] <mru> a decent system interface should be easy to call from asm, yes
[21:39:45] <bcoudurier> anyone familiar with the png decoder ?
[21:40:14] <hyc> aside from the sdp patch, what about the rest of the ffserver fixes I posted?
[21:40:51] <wbs> hyc: perhaps a repost of them with thorough explanation of what the problems are and what you're fixing? or just a ping on those parts
[21:41:31] <mru> bcoudurier: what about it?
[21:42:04] <bcoudurier> it seems zlib frees a buffer that it shouldn't
[21:42:09] <hyc> wbs: I thought I already posted clear explanations with each incremental email
[21:42:24] <mru> bcoudurier: I'm not surprised if it does, but do you have more details?
[21:42:24] <hyc> but I guess I can repost it all again...
[21:42:26] <bcoudurier> but I'm not sure
[21:42:33] <mru> valgrind doesn't complain
[21:42:35] <bcoudurier> let me paste it in private
[21:42:49] <mru> zlib is basically evil
[21:43:24] <_av500_> bcoudurier: so the file can be played but not remuxed?
[21:43:32] <bcoudurier> basically, yes
[21:43:57] <_av500_> what is lost between playing it and bein able to mux it?
[21:45:01] <bcoudurier> dts
[21:45:07] <bcoudurier> nothing is lost
[21:45:09] <bcoudurier> mkv misses dts
[21:45:17] <_av500_> i know
[21:45:39] <_av500_> so, what to remuxable mkv files have?
[21:45:41] <bcoudurier> to compute dts, you need duration and pts and delay basically
[21:45:53] <bcoudurier> or delay and cfr
[21:46:18] <bcoudurier> only files that have the delay in extradata basically
[21:46:39] <_av500_> in codec extradata for h264?
[21:46:42] <bcoudurier> I thought that was very common for files encoded with x264
[21:46:48] <bcoudurier> Dark_Shikari ?
[21:47:18] <_av500_> i thought all h264 was encoded with x264 by now :)
[21:47:29] <bcoudurier> nah
[21:47:46] <kierank> [22:45] <@bcoudurier> to compute dts, you need duration and pts and delay basically --> or you can use hrd sei messages if they are available
[21:47:49] <bcoudurier> all dvdripping stuff surely :>
[21:48:45] <bcoudurier> hrd sei are mostly used with TS AFAIK
[21:48:51] <bcoudurier> TS has dts so no problem here
[21:49:08] <kierank> yes, the dts of ts should be exactly the same as the hrd sei message
[21:49:11] <bcoudurier> mkv is utterly crap because it only has pts
[21:49:32] <_av500_> unless it had dts :)
[21:49:56] <_av500_> in VFW muxing mode...
[21:50:00] <bcoudurier> doh
[21:50:06] <bcoudurier> ugly ugly ugly
[21:50:11] <kierank> x264 should write num_reorder_frames
[21:50:31] <_av500_> or out of order audio in "lets be a little be realvideo" mode
[21:51:33] <bcoudurier> kierank, yup that's what I thought
[21:53:36] <_av500_> but mkv provides some "back ref" values for reordered frames, no?
[21:59:27] <_av500_> bcoudurier: "delay" so that you know how long to keep frames in a reorder buffer`
[21:59:30] <_av500_> ?
[21:59:50] <bcoudurier> so you know at which value dts start
[22:00:08] <bcoudurier> usually for pts 0,1,2,3,4,5,6,7
[22:00:13] <bcoudurier> dts start at -delay
[22:00:53] <hyc> wbs: reposted ... there are still a lot more problems with ffserver though
[22:01:21] <hyc> the ffm interface omits a number of config options
[22:01:47] <hyc> so the settings that ffmpeg actually uses are different from what was set in ffserver.conf
[22:02:14] <hyc> trellis encoding is missing, sample_aspect_ratio is missing
[22:03:14] <hyc> many others, and these affect e.g. x264. so the stream generated by ffmpeg doesn't agree with the sps/pps extradata that ffserver sends
[22:03:29] <hyc> (that ffserver sends to the rtsp client)
[22:04:59] <hyc> this might account for those endless "non-existing PPS" error messages. dunno yet.
[22:06:21] <hyc> bcoudurier: is there any special steps needed for adding new fields to the ffm header?
[22:07:59] <bcoudurier> nope
[22:09:48] <hyc> ok, then I'll probably post a patch to push some more settings into there
[22:12:10] <hyc> not worth the effort until the other ffserver fixes are committed though
[22:21:15] <Dark_Shikari> next patch round
[22:21:17] <Dark_Shikari> er
[22:21:18] <Dark_Shikari> bcoudurier: ?
[22:23:57] <hyc> btw, Dark_Shikari thanks for your help yesterday
[22:24:06] <hyc> of course it turned out I was chasing a red herring...
[22:24:38] * mru already has plenty of those in his trophy case
[22:25:10] * hyc feeds them to his cats
[22:26:27] * mru likes cats
[22:26:59] <bcoudurier> <bcoudurier> I thought that was very common for files encoded with x264
[22:27:07] <bcoudurier> have num_reorder_frames
[22:27:30] <Dark_Shikari> yes, all x264 files have num_reorder_frames
[22:28:10] <bcoudurier> oh
[22:28:19] <bcoudurier> av500 gaves me one without
[22:28:50] <_av500_> i did not say it was x264 encoded
[22:28:55] <bcoudurier> it is
[22:29:01] <_av500_> ah
[22:29:10] <bcoudurier> core 56 svn-680
[22:29:18] <bcoudurier> lol
[22:29:35] <kierank> youtube uses a version from that era
[22:29:44] <kierank> dunno if they upgraded it yet
[22:29:54] <bcoudurier> that's from haali
[22:30:29] <Dark_Shikari> going back to at least 2005 it seems to be set in x264
[22:30:56] <bcoudurier> rofl
[22:31:10] <bcoudurier> the sceners used a 2 years old version
[22:31:25] <bcoudurier> this episode was aired 26 october 2007
[22:31:39] <_av500_> bcoudurier: it might well be from then
[22:32:22] <bcoudurier> anyway this files has no timing info
[22:32:27] * mru has no respect for people who self-apply the term "scene"
[22:32:35] <iive> _av500_: x264 from 2005 used to encode episode aired 2007 - 2 years old x264
[22:32:58] <_av500_> iive: yeah, math is rusty this late :)
[22:33:10] <iive> _av500_: :)
[22:34:01] <bcoudurier> yes, no vui in this file
[22:34:07] <bcoudurier> so no luck
[22:34:24] <mru> x264 has use vui for a very long time
[22:34:58] <_av500_> vui is the noise it makes when it encodes really fast?
[22:35:51] <mru> I remember writing actual code for that, so it must have been in early 2004
[22:36:03] <kierank> git blame says num_reorder_frames was written in march 2005
[22:36:24] <mru> the vui may have been extended later
[22:36:44] <kierank> yes you wrote the vui in '04
[22:37:11] <kierank> your name produces a lot of console spam
[22:40:11] <mru> I wrote some ratecontrol back then too
[22:40:16] <mru> nothing left of it now :-(
[22:40:28] <mru> it wasn't very good
[22:40:36] <mru> but better than constant-qp
[22:41:06] <kierank> you wrote ratecontroll
[22:41:46] <mru> as I said, it wasn't very good
[22:42:04] <kierank> never mind
[22:42:43] <kierank> (mru didn't see what i did there)
[22:43:06] <drv> ratecon-troll
[22:44:59] <kierank> You could submit ffv2 to this if you can read past the buzzwords: http://tech.ebu.ch/news/amwa-and-ebu-issue-request-for-media-tec-26apr10
[22:50:32] <CIA-7> ffmpeg: stefano * r23153 /trunk/libavcodec/ (avcodec.h options.c): Add log_level_offset to AVCodecContext.
[23:00:20] <Compn> mru : you should ask people on irc if they are going to linuxtag :P
[23:02:25] <mru> I thought everybody here read the ML
[23:02:45] <mru> but as you wish:
[23:02:50] <mru> anyone going to linuxtag?
[23:03:29] <BBB> not me
[23:03:38] <BBB> I didn't want to spam the ml with "no" messages :)
[23:03:58] <mru> you could still contribute some ideas
[23:04:30] <BBB> ok
[23:04:34] <BBB> what do you need exactly?
[23:04:39] * BBB goes read ml
[23:04:50] <mru> ideas for demos, posters, t-shirts, anything you can think of
[23:05:01] <mru> and transport of a fairly heavy case from darmstadt to berlin
[23:05:17] <mru> it's ok, it's too small to hold a corpse
[23:05:33] <BBB> can it hold a mouse corpse?
[23:05:37] <BBB> if so, big enough for me
[23:05:44] <BBB> ("academic purposes")
[23:05:52] <BBB> slogan: "ready for HTML5"
[23:05:53] <mru> I didn't see any mice in _av500_'s office...
[23:06:03] <BBB> is av500 a scientist?
[23:06:04] <mru> we've already done "works with html5"
[23:06:08] <BBB> oh :(
[23:06:14] <mru> at fosdem
[23:06:18] <BBB> oh right
[23:06:31] <mru> I guess I'll reuse that tshirt one day
[23:07:04] <BBB> how about a funny nag on that hulu-to-android script hyc wrote?
[23:07:11] <mru> too obscure
[23:07:14] * mru hasn't heard of it
[23:07:24] <mru> hulu mostly isn't in europe
[23:07:29] <BBB> oh...
[23:07:34] <BBB> it's pretty big here, but that's useless the
[23:07:40] <BBB> I guess you guys still watch tv, do you
[23:07:41] <BBB> ?
[23:07:49] <mru> rarely
[23:07:55] <kierank> hulu quit the uk
[23:08:10] * mru has been watching aac in md5 lately
[23:08:22] <BBB> watching aac is quite impressive
[23:08:44] <mru> it's faster and more accurate than listening to it
[23:09:12] <BBB> diego has foundation money, he can send you money to rent a car to transport beast, for all I care
[23:09:24] <mru> still need a driver
[23:09:28] <BBB> I think that's a pretty fair way of "getting closer to our goal"
[23:09:29] <mru> we have devs in that area
[23:09:30] <BBB> you?
[23:09:35] <mru> hopefully someone will be going
[23:09:39] <BBB> I thought you were driving
[23:09:48] <mru> from the UK?  I don't think so
[23:09:58] <BBB> right
[23:09:59] <mru> and I don't have a car
[23:10:18] <mru> that's one thing I like about europe
[23:10:21] <mru> you don't need a car
[23:10:34] <BBB> you're confused with the westcoast
[23:10:45] <BBB> in NYC, if you have a car, you're an idiot
[23:10:50] <mru> yeah, I guess you don't need one in NYC either
[23:10:53] <BBB> :)
[23:11:10] <BBB> ok, slogan
[23:11:43] <BBB> "Can <i><b>your</b></i> browser play h.264?"
[23:11:46] <bcoudurier> well in nyc I found subway very dirty
[23:12:04] <mru> we've done html already
[23:12:18] <mru> that would just look like a google advert
[23:12:22] <bcoudurier> but that's probably my frog taste
[23:12:29] <BBB> bcoudurier: no, it's dirty
[23:12:37] <BBB> bcoudurier: but it's all we have :-/
[23:12:50] <mru> stockholm underground is probably the cleanest I've seen
[23:12:53] <BBB> on the upside, we have amazing restaurants
[23:12:59] <bcoudurier> in manhattan you can walk for sure
[23:13:05] <mru> might be because the replaced all trains ~10 years ago
[23:13:11] <bcoudurier> yes, amazing == cost you an arm
[23:13:24] <BBB> hehe :)
[23:13:27] <BBB> not really
[23:13:44] <BBB> some of them are very cheap (under $10, some even under $6, per person for dinner)
[23:13:48] <bcoudurier> well ok
[23:13:58] <mru> BBB: taco bell isn't a restaurant
[23:14:00] <BBB> don't expect jean george quality, but they're surprisingly good sometimes
[23:14:06] <bcoudurier> mru, exacly :)
[23:14:06] <BBB> baoguette
[23:14:12] <BBB> is absolutely amazing
[23:14:16] <BBB> and dirt-cheap
[23:14:27] <BBB> </google ads>
[23:14:28] <bcoudurier> I mean I found that a real problem in the us
[23:14:43] * mru used to eat really cheaply on the west coast
[23:14:44] <bcoudurier> you want something "decent", it will cost you at least $35 per person
[23:14:47] <mru> company was paying...
[23:15:32] <bcoudurier> the wine is very pricey
[23:15:49] <bcoudurier> in paris I could eat for 20 euros
[23:15:51] <mru> with a $40/dinner allowance you tend to not care
[23:16:06] <mru> that was the good thing about that company
[23:16:18] <bcoudurier> yup
[23:16:26] <BBB> hm
[23:16:29] <kierank> geneva is even worse
[23:16:31] <BBB> my next idea was not so good
[23:16:32] <BBB> http://www.googlefight.com/index.php?lang=en_GB&word1=%22ffmpeg+rocks%22&word2=%22ffmpeg+sucks%22
[23:16:35] <BBB> aiiiii
[23:16:36] <bcoudurier> haha
[23:16:41] <hyc> there's always BBC iPlayer for you UK folks
[23:16:48] <hyc> the same type of hack will work for that
[23:17:08] <mru> I don't need a hack for iplayer
[23:17:11] <mru> works fine on the ps3
[23:17:16] <hyc> in fact, my hulu scripts originated from the get_iplayer project
[23:17:26] <mru> although I usually end up torrenting it anyway
[23:17:32] <kierank> get_iplayer folded because bbc said drm > open source
[23:17:42] <kierank> their loss
[23:17:58] <hyc> well, that's the beauty of open source - the original author stopped but the project lives on
[23:19:54] <kierank> the bigger issue was that about 10 years ago on satellite effectively put open source above drm when they got rid of videoguard. People are saying now it's back to square one for the internet
[23:20:00] <kierank> bbc* effectively
[23:20:35] <kierank> ofc there was a lot of money saved too
[23:22:33] <mru> videoguard ain't cheap
[23:22:40] <mru> and the code is very, very ugly
[23:22:43] <iive> kierank: i've heard that internet "broadcast" is also lower quality than the dvb broadcast.
[23:23:00] <kierank> only because the encoder sucks
[23:23:07] <kierank> it's 1500kbps h.264
[23:23:08] <kierank> for sd
[23:23:24] <mru> should be plenty
[23:23:29] <kierank> yes but the encoder sucks
[23:23:33] <kierank> blocks galore
[23:23:33] <hyc> also the default players may not be choosing the highest rate stream for your particular session
[23:23:56] <kierank> hyc: they have a thing where you can right click and see the bitrate
[23:24:10] <kierank> they also don't use the flash "smooth-streaming" thing; they wrote their own
[23:24:14] <bcoudurier> cable sucks hard
[23:24:28] <bcoudurier> it's worse than OTA dtv
[23:24:29] <hyc> yeah... but I prefer scripts like get_iplayer that just let you specify which stream to pull
[23:24:52] <hyc> yeah, cable sucks
[23:25:00] <mru> US cable and satellite tends to suck
[23:25:05] <hyc> I haven't upgraded my cable subscription to digital
[23:25:09] <mru> atsc is often much better
[23:25:10] <hyc> there's no point...
[23:25:24] <hyc> unfortunately I get no OTA signal where I live
[23:25:35] <bcoudurier> you can see that easily if you watch BBT on CBS
[23:25:48] <bcoudurier> the slate is _really_ blocky
[23:25:48] <kierank> the problem with cbs is the distribution feed is shit as well
[23:26:09] <kierank> so the problem is compounded
[23:26:49] <kierank> dunno about fox but abc and nbc have something reasonable to start from
[23:26:55] <hyc> I think commercial TV is all a loss anyway... was watching some old shows on Hulu, from back in the 70s. They had 52 minutes of program time per 1-hour show.
[23:27:03] <hyc> today we're down to 42 minutes. the rest is commercials.
[23:27:16] <Compn> heh
[23:27:36] <Compn> atsc would be good, if only broadcasters could agree on widescreen/pillarbox nonsense
[23:27:53] <kierank> my favourite is the halfway house widescreen/4:3 Compn
[23:27:56] <Compn> maybe i just mean usa dtv... not atsc.
[23:28:05] <kierank> it's like a stretchy time warp thing
[23:28:17] <Compn> you mean widescreen stretched to 4/3 ?
[23:28:28] <kierank> no, there's some weirder thing that some channels use
[23:28:38] <hyc> that'd be like old cinemascope movies on 4:3
[23:28:39] <Compn> need a screenshot, but sounds horrible :P
[23:28:41] <mru> the worst is the non-linear scaling some TVs use to scale 4/3 to 16/9
[23:28:52] <mru> never seen anything actually encoded like that
[23:28:55] * Compn is still using super old tvs with converter boxes
[23:29:09] <Compn> no reason to upgrade, nothing to watch on broadcast in years
[23:29:13] <kierank> mru explained it better
[23:29:34] <kierank> some tv channels in the us used that non-linear scaling thing once
[23:29:37] <mru> they stretch the edges more than the centre
[23:29:37] <hyc> I haven't watched live TV in years. just watch the S-video output of my laptop.
[23:29:53] <bcoudurier> well, they should not get the distribution feed
[23:29:58] <bcoudurier> when the OTA feed is good
[23:29:59] <hyc> mru: I thought that approach was kinda clever really
[23:29:59] <Compn> i need to pickup some cheap s-vdeo to rca cable/converter things ;\
[23:30:01] <mru> idiots don't notice that round objects turn elliptical as they move towards the edge
[23:30:20] <kierank> bcoudurier: i'm talking about the distribution feed to the station
[23:30:20] <mru> it's clever as idiot mode
[23:30:21] <hyc> I think our Samsung big screen TVs offer that mode too
[23:30:21] <Compn> oh i've seen those streches hahaha
[23:30:23] <bcoudurier> mru, what bandwidth is dvb-t ?
[23:30:30] <Compn> fish eye lense
[23:30:33] <bcoudurier> kierank, yes I know
[23:30:45] <mru> most widescreen TVs have that mode
[23:30:51] <mru> bcoudurier: don't know
[23:30:56] <mru> varies between countries
[23:31:03] <bcoudurier> but AFAIK cable don't rewrite pictures anyway
[23:31:16] <bcoudurier> so just get the ota feed and reencode it
[23:31:26] <mru> the US cable market is so fucked up anything could happen there
[23:31:46] <bcoudurier> I even see inverted fields
[23:31:48] <Compn> ooh, maybe i should put up some donation requests for dvb-s stuff :D
[23:31:48] <bcoudurier> on some ads
[23:31:51] <bcoudurier> on tv
[23:32:04] <Compn> probably no free- sattelite channels left
[23:32:04] <mru> I've seen compositions where an insert had wrong field order
[23:32:33] <kierank> those random channels towards the end of the epg are like that
[23:32:37] <kierank> on sky
[23:32:56] <kierank> everything wrong
[23:32:59] * mru wouldn't let a sky box through his front door
[23:33:00] <kierank> field order, chroma
[23:33:07] * mru has seen the code they run
[23:33:20] <kierank> yes but my CAM doesn't work any more
[23:33:28] <kierank> so i'm stuck with it
[23:33:39] <kierank> because of the new cards
[23:33:54] <mru> yeah, they did a switch a few years back
[23:34:27] <kierank> there was one 6 months ago as well
[23:34:39] <mru> could be the same one still in progress
[23:34:42] <mru> those things take time
[23:34:59] <kierank> it's over now I think because the old card doesn't work
[23:35:18] <mru> yeah, they send dual ECMs during the transition
[23:35:24] <kierank> of course the newer generation of CAMs worked fine
[23:35:28] <kierank> didn't need any updates or anything
[23:35:33] <Compn> cam?
[23:35:38] <kierank> conditional access module
[23:35:45] <kierank> basically a smartcard reader
[23:35:48] <Compn> ah
[23:36:03] <kierank> they are grey market devices
[23:36:14] <mru> the nds cards obviously don't follow standard protocol
[23:36:27] <mru> electrically they're compatible with the iso smartcard spec
[23:36:50] <kierank> there was a software cam that worked with the old cards
[23:37:41] <mru> some broadcasters use(d) CI
[23:37:45] <mru> those would work
[23:37:49] <kierank> the germans
[23:38:07] <mru> the US directv system is much more secure
[23:38:29] <Kovensky> idea for whoever makes a panel at an OSS convention: bring a bikeshed with you, then put in the middle of the audience and tell them to paint it
[23:38:41] <mru> Kovensky: lol
[23:38:42] <kierank> nobody wants to pirate directv anyway
[23:38:45] <kierank> looks like crap
[23:38:47] <mru> yeah
[23:38:49] <mru> awful
[23:39:00] <kierank> though getting better i've been told now that they bought ateme encoders
[23:39:11] <kierank> but still bitrates that are way too low
[23:39:26] <mru> they started doing 1080p30 a while ago at least
[23:39:42] <mru> when someone realised the decoders could in fact do it
[23:39:53] <mru> which should've been no surprise
[23:41:50] <kierank> hbo does it properly though with 1080p24, 1080p30 and 1080i60
[23:45:42] <kierank> [00:30] <kierank> bcoudurier: i'm talking about the distribution feed to the station --> wiki says I actually mean "affiliate"
[23:54:26] <bcoudurier> yes
[23:54:32] <bcoudurier> err
[23:54:41] <bcoudurier> you mean local affiliate ?
[23:54:51] <bcoudurier> I don't think cable gets the local affiliate feed
[23:55:08] <bcoudurier> or maybe they do
[23:55:15] <bcoudurier> then their encoder is utter crap
[23:57:46] <Dark_Shikari> that's a given