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

[irc at mansr.com]

[00:05:52] <Compn> a wicked wicked place no doubt
[00:09:51] <reynaldo> hi Compn
[00:13:45] <Compn> wb reynaldo
[01:33:37] <Compn> heh
[01:50:12] <peloverde> http://threatpost.com/en_us/blogs/cert-releases-basic-fuzzing-framework-052710
[01:51:28] <bcoudurier> humm, how do you mention that you are using full range yuv in h.264 ?
[01:52:33] <Dark_Shikari> --fullrange in x624
[01:52:56] <mru> I suppose it's signaled in vui or a special sei
[01:53:17] <Dark_Shikari> VUI
[01:55:50] <bcoudurier> vui ?
[01:55:59] <bcoudurier> I'm reading the specs
[01:56:26] <Dark_Shikari> video
[01:56:29] <Dark_Shikari> video_signal_type
[01:56:32] <Dark_Shikari> video_full_range_flag
[01:56:48] <mru> annex e
[01:57:17] <mru> what happened to annex f?
[01:57:19] <bcoudurier> all right
[01:57:24] <bcoudurier> why wasn't that fixed in svn ?
[01:57:28] <bcoudurier> it's pretty trivial
[01:57:36] <bcoudurier> if video_full_range pix_fmt = PIX_FMT_YUVJ420P
[01:57:47] <Dark_Shikari> I thought jpeg had some other thing going on?
[01:57:49] <bcoudurier> no
[01:57:54] <bcoudurier> jpeg uses 0-255
[01:57:57] <bcoudurier> yuv
[01:58:19] * Dark_Shikari wonders why we don't have another range flag
[01:59:03] <bcoudurier> libswscale already supports it, so it should work correctly
[02:00:33] <bcoudurier> and we do have one
[02:00:36] <bcoudurier> it seems
[02:00:49] <bcoudurier> AVCOL_RANGE_JPEG
[02:01:52] <mru> and h264 sets it
[02:05:26] <bcoudurier> but since the range is ignored
[02:05:52] <mru> having two ways of specifying the same thing is bad
[02:10:45] <bcoudurier> I agree, although we have some legacy stuff that is painful to remove
[02:12:24] <bcoudurier> BUG: unable to handle kernel NULL pointer dereference at 0000000000000009
[02:12:24] <bcoudurier> IP: [<ffffffff81071482>] free_pid+0x3d/0xbb
[02:12:24] <bcoudurier> PGD 12189b067 PUD 17ba91067 PMD 0
[02:12:59] <bcoudurier> has anybody any idea about how important this might be ?
[02:15:30] <ohsix> rebooting would be in short order
[02:19:09] <bcoudurier> agree :)
[04:11:34] <hyc> hm, the mpeg4video_parser also needs to look at avctx->extradata
[04:11:53] <hyc> and it just sets a flag and then checks it on every parse
[04:12:16] <hyc> I guess it's too much trouble to add a new API, just going to leave it with checking a flag
[04:39:09] <peloverde> gah! the psymodel is setting the threshold way too low on sfb 21 for some reason causing hilarity at low bitrates
[04:52:19] <kshishkov> peloverde: blame implementor
[04:53:08] <peloverde> Before that I spent 8 hours chasing down spectral holes due to a typo I made today :(
[04:56:43] <peloverde> I'm also not sure how much I really care about 32k/channel
[04:57:33] <kshishkov> that's 64kbps in total, sounds quite widespread
[04:58:56] <peloverde> Down in that space you are really starting to step into SBR territory
[05:02:55] <peloverde> I guess 64 is reasonable with decent stereo coding
[05:03:17] <peloverde> I've been focusing on mono only
[06:05:54] <Dark_Shikari> Yuvi: idct_dc for vp3 is wrong
[06:06:05] <Dark_Shikari> fyi.
[06:06:20] <Dark_Shikari> the correct version is faster, too.
[07:02:25] <CIA-93> ffmpeg: conrad * r23358 /trunk/libavcodec/x86/vp3dsp_mmx.c:
[07:02:25] <CIA-93> ffmpeg: vp3: The DC-only IDCT is surprisingly not supposed to be bitexact to the
[07:02:25] <CIA-93> ffmpeg: full IDCT. Fix this.
[07:03:10] <Dark_Shikari> Yuvi: you have to fix the c too
[07:03:16] <Yuvi> oh right
[07:16:55] <superdump> morning
[07:17:28] <wbs> morning
[07:17:59] <jai> morning
[07:18:19] <wbs> jai: isn't it more like noon over there? :-)
[07:18:38] <jai> wbs: yeah, just blending in ;)
[07:19:00] <wbs> jai: or to put it in a kshishkov-ish way, you're pretending to be swedish? ;P
[07:19:18] <Tjoppen> kaffe.
[07:19:21] <jai> lol
[07:20:01] <thresh> moroning, btw
[07:20:01] <jai> wbs: there are only 2 kinds of people, swedes and wanna be swedes :)
[07:23:03] <CIA-93> ffmpeg: conrad * r23359 /trunk/libavcodec/ (arm/vp3dsp_neon.S vp3dsp.c): vp3: 10l Fix DC-only IDCT for C and ARM too
[07:23:56] <wbs> jai: at least in some people's minds :-)
[07:30:34] * _av500_ does not want to be suede
[07:31:12] <_av500_> gm btw
[07:52:55] <Tjoppen> I still don't get it - how can VP8 be considered unencumbered? all I see is handwaving like "google will use its patent stick"
[07:53:21] <_av500_> how iwll gg use its patent stick?
[07:53:22] <Dark_Shikari> that sounds sexual.
[07:53:26] <Tjoppen> :o
[07:53:26] <Dark_Shikari> "patent stick"
[07:53:34] <_av500_> you cann sue troll back usually
[07:53:41] <Dark_Shikari> frauenhofer will take google's patent stick right up its patent hole
[07:53:45] <_av500_> because they dont make product of their own
[07:54:00] <Yuvi> it's probably just different enough that any patents it infringes are of the stupidly overbroad variety
[07:54:01] <_av500_> you cannot sue trolls back usually
[07:54:12] <Tjoppen> basically mutually assured destruction?
[07:54:16] <Dark_Shikari> Yuvi: I think they're betting on prior art on some things
[07:54:24] <Dark_Shikari> e.g. hoping that nokia mvc prior arts the intra pred patents
[07:54:30] <Dark_Shikari> Which technically it _does_
[07:54:33] <Dark_Shikari> it's just that the courts are retardo
[07:54:36] <Yuvi> nokia doesn't have patents on it?
[07:54:43] <_av500_> Dark_Shikari: this will still not help many small players
[07:54:43] <Dark_Shikari> "everything that isn't a patent doesn't count as prior art"
[07:54:52] <Tjoppen> durr
[07:54:57] <_av500_> trolls go after small prey 1st
[07:54:59] <Dark_Shikari> Yuvi: any patents on spatial intra pred came 2002 or later iirc
[07:55:03] <Dark_Shikari> and mvc was 2000
[07:55:43] <Yuvi> still, if it's nokia patenting it, 2002 would mean it's "valid" regardless of mvc
[07:55:44] <Tjoppen> so it's basically as I suspected then
[07:56:07] <Dark_Shikari> and of course we all know that nokia never exercises its patents >_>
[07:58:09] <Yuvi> or it's possible that they might argue that the intra pred modes are pretty obvious (except for planar which they don't use)
[07:58:18] <Yuvi> and thus any patents on them should be invalid
[07:58:57] <Dark_Shikari> that would be REALLY hard to argue
[07:59:06] <Dark_Shikari> there are many codec patents on far similar things
[07:59:20] <Dark_Shikari> which most lawyers seem to think will hold up
[07:59:47] <Yuvi> yeah, but if google manages to successfully argue that, that would be a pretty good win against software patents
[08:00:02] <wbs> I want a pony, too. :-)
[08:00:08] <Tjoppen> err.. AV_NOPTS_VALUE is unsigned?
[08:00:11] <Yuvi> heh
[08:00:29] <Yuvi> Tjoppen: equivalent to INT64_MIN iirc
[08:00:37] <merbzt> ponys for everyone
[08:00:40] <Tjoppen> yes, but it's unsigned :o
[08:00:46] <Tjoppen> causing compilation warnings
[08:01:07] <Tjoppen> since timestamps are stored in int64_t's
[08:01:25] <Yuvi> which compiler? it's a literal, signed <-> unsigned shouldn't be warnings :/
[08:01:42] <Tjoppen> g++ -Wall
[08:01:46] <Yuvi> or wrong terminology, but same
[08:01:58] <Tjoppen> yes, I'm just doing ==, which should work
[08:03:03] <Tjoppen> time for fika
[11:18:59] <merbzt> mru: do you know hdmi stuff ?
[11:20:26] <mru> what about it?
[11:23:42] <merbzt> bit stream audio transfer
[11:24:34] <mru> what do you want to know?
[11:25:07] <twnqx> if it is existing in the driver it is shown in alsa as an spdif device
[11:25:10] <twnqx> does that help?
[11:25:29] <merbzt> how to transfer it, ie mux it
[11:26:35] <merbzt> for example how to send things that cant be sent over a spdif cable
[11:26:41] <merbzt> dts-ma
[11:26:43] <mru> the hdmi spec is freely available
[11:26:44] <merbzt> mlp
[11:26:49] <mru> hdmi.org
[11:29:31] <twnqx> merbzt: it can be sent
[11:29:55] <twnqx> e.g. my mainboard allows way higher bitrates on its spdif port than the usual 1536kbit/s
[11:30:12] <merbzt> neat
[11:30:29] <twnqx> i only noticed when i booted windows, and the driver allowed be to test higher rates
[11:30:39] <twnqx> dunno if it works with linux, though
[11:30:47] <twnqx> i have no amp to test for the other end ;)
[11:30:58] <merbzt> IC :)
[11:31:19] <twnqx> should check if my hdmi-enabled marantz would accept that on spdif as well
[11:33:25] <jai> you have a marantz receiver?
[11:34:44] <mru> gaaah, this mips manual is annoying
[11:37:45] <twnqx> jai: yes
[12:04:46] <Vitor1001> jai: Since you seems to understand quite a bit about .rm, have you seem issue1708?
[12:13:57] <scaphilo> hi everyone, im on my last steps in building my openloop mpeg2 to mpeg4part2 transcoder :-) the only thing that still doesnt work has something to do with the interlaced_dct macroblocks. Is there a differnece i dont know between mpeg2 and mpeg4?
[12:15:26] <scaphilo> it only happens when these macroblocks were refered by other mb's
[12:18:46] <jai> Vitor1001: yeah, those are old audio only streams. we dont support that currently
[12:19:31] <scaphilo> mpeg2 specialist here? what happens when a mb refers to such a mb's top field for example? does it refer to the interlaced field (which contains 4 lines of the top and 4 of the bottom) or does it refer to the top 8 lines?
[12:20:07] <jai> Vitor1001: shouldn't be too complex though, mplayer already has code which demuxes those
[12:20:49] <Vitor1001> jai: That's why I pinged you, I was hooping it would be pretty trivial for someone who knows the format ;)
[12:29:53] <jai> Vitor1001: sure, i'll take a look again
[12:30:06] <Vitor1001> jai: Great, thanks!
[12:32:57] <kshishkov> away away
[13:02:28] <siretart> hyc: are you aware of any Linux distribution that ships rtmpdump and librtmp?
[13:25:32] <lu_zero> we got a bug open to support rtmpdump
[13:27:55] <siretart> lu_zero: would gentoo distribute the rtmpdump tarball on their distfiles mirrors?
[13:30:32] <thresh> we still need a .so :(
[13:33:43] <lu_zero> siretart: what's the issue with it?
[13:33:51] <lu_zero> thresh: ?
[13:34:05] <j-b> just dlopen it, like libdvdcss
[13:37:12] <thresh> well i thought librtmp is a static library only
[13:37:50] <j-b> oh?
[13:39:56] <lu_zero> the bare makefile has just that
[13:52:43] <j-b> anyone knows where nico and Erik are on IRC?
[13:54:45] <merbzt> nico sabbi ?
[13:55:23] <kshishkov> sounds so
[13:55:35] <kshishkov> I think you should know a lot of Eriks though
[13:57:30] <j-b> merbzt:
[13:57:32] <j-b> merbzt: yes
[13:57:45] <j-b> Erik Hovland
[13:57:49] <merbzt> nicodvb is his nick if he is online
[13:57:59] <j-b> the 2 people maintaining libdvdread for us :)
[13:58:11] <j-b> +nicely
[13:58:16] <kshishkov> you should've said that at once
[13:59:00] <j-b> sorry, :) They don't seem to be around #mplayer or #mplayerdev
[13:59:53] <kshishkov> I'm not sure it's easy to meet them here anyway
[14:02:43] <janneg> j-b: I don't think Erik Hovland uses irc
[14:04:57] <j-b> kshishkov: many thanks
[14:05:00] <j-b> janneg: thanks
[14:17:53] <siretart> j-b: do you have a patch for libavformat to dlopen() librtmp.so? ;-)
[14:18:45] <j-b> siretart: nope
[14:21:25] <BBB> why dlopen?
[14:21:44] <twnqx> legal issues with linking against the lib
[14:22:59] <siretart> what legal issues?
[14:23:34] <twnqx> is rtmpdump considered a legal software? libdvdcss isn't in every country
[14:23:49] <siretart> hyc: ^^
[14:23:52] <KotH> twnqx: neither is ssh legal in every country
[14:23:54] <lu_zero> rtmpdump is legal as curl ...
[14:24:03] <twnqx> i see
[14:24:32] <lu_zero> and from what I'm seeing is quite useful since librtmp can also be used as building block for a server
[14:24:52] <siretart> similar freetard'ish discussion going on here: http://thread.gmane.org/gmane.linux.debian.devel.general/152320
[14:25:03] <BBB> ooo tard discussion
[14:25:05] * BBB clicks
[14:25:11] <siretart> lol
[14:25:20] <lu_zero> hyc: you'd accept to have the build system extended using ffmpeg one?
[14:27:50] <KotH> siretart: tell marillat that his "license problem" is none
[14:28:13] <KotH> siretart: they just wanted to scare people with a dmca, nothing more
[14:28:17] <Tjoppen> av_metadata_set2() seems to leak memory. about 50 B per av_write_header() call
[14:28:47] <KotH> siretart: and taht dmca notice is actually the reason why rtmpdump is hosted on natsuki
[14:29:17] <hyc> lu_zero: the rtmpdump build system? I guess. why does it need extending?
[14:29:37] <siretart> KotH: I've already prepared a draft but did not send it yet.
[14:31:11] <KotH> siretart: you may add to it that none of us has ever heard from adobe since rtmpdump is hosted on natsuki
[14:31:24] <BBB> Yuvi: regarding VP8Macroblock, is that supposed to be a visible macroblock (similar to libvpx' MACROBLOCKD) or is it also for prediction (analog to libvpx MODE_INFO)? I noticed you malloc intra4x4 (for prediction) and was wondering if you minded if I change that into a struct so we can store other prediction parameters in there as well (so it becomes a little like MODE_INFO in libvpx)
[14:31:26] <siretart> natsuki is the hostname?
[14:31:39] <KotH> (apperently they are smart enough to know that the dmca doesnt apply to .ch)
[14:31:44] <KotH> yes, natsuki is our main server
[14:31:53] <peloverde> libvpx in the MSU comparison I think a lot of people will be less than pleased https://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/thread/eef2b0232e2052b4#
[14:32:39] <mru> until they learn a thing or two about video, MSU might as well be comparing random-number generators
[14:35:52] <BBB> holy shit x264 comes out well :)
[14:37:40] <KotH> and theora loses to xvid... in all comparisons...
[14:37:56] <KotH> mru: what do you critizise in their test?
[14:38:35] <mru> they at least used to do them in total ignorance what settings were good
[14:38:40] <mru> and with ancient versions
[14:38:59] <mru> in fairness, the last couple of iterations have been a bit better
[14:41:14] <j-b> libvpx in MSU is quite a good idea to have FACTS not FUD
[14:41:57] * _av500_ loves FUDge
[14:42:36] * KotH loves sprüngli chocolate
[14:42:55] <_av500_> that too
[14:43:58] <KotH> hmm.. next week is going to be a bit colder
[14:44:10] <KotH> .o0(get up early tomorrow and buy tons of chocolate)
[14:44:24] <peloverde> I thought they ask devs for recommended versions and settings
[14:44:56] <mru> now they do
[14:45:34] <twnqx> Stream #0.0(jpn): Video: h264, yuv420p, 720x480, PAR 186:157 DAR 279:157, 24.39 fps, 23.98 tbr, 1k tbn, 47.95 tbc <- i really don't understand how ffmpeg comes to these seemingly random fps values
[14:45:41] <twnqx> (yes, it's in mkv)
[14:47:13] <hyc> rights-restricted libraries?
[14:47:37] <KotH> hyc: freetardism
[14:48:11] <KotH> hyc: rtmdump has been tainted by a dmca notice.. it is now considered unfree..violating the gpl... etc pp
[14:48:31] <lu_zero> hyc: to add shared library support
[14:48:39] <lu_zero> mostly
[14:48:47] <lu_zero> mru: https://review.webmproject.org/#change,40
[14:49:53] <hyc> lu_zero: I'll think about it. I guess it can always build a shared lib by default, in addition to static
[14:50:36] <Tjoppen> err.. libavutil/mathematics.c:80: av_rescale_rnd: Assertion `b >=0' failed.
[14:51:03] <lu_zero> and you are also lacking an install target
[14:51:06] <lu_zero> ^^
[14:51:13] <hyc> for now I just add -fPIC to the C flags. it still builds static, but can be linked into other shared libs then
[14:51:58] <hyc> librtmp has an install target. never really saw the need for one for rtmpdump
[14:52:39] <hyc> but that's easily added...
[14:52:54] <lu_zero> sure
[14:53:01] <lu_zero> same as libdir param ^^
[14:55:01] <kshishkov> KotH: here I usually can get only Lindt chocolate, no Sprüngli
[14:56:00] <mru> what, no sprüngli??!?!??
[14:58:03] <kshishkov> probably they have Lindt part from L&S for foreighners and Sprüngli for Switzerland
[14:58:28] <KotH> nope
[14:58:48] <KotH> lindt is just the cheap, mass produced chocolate
[14:59:06] <kshishkov> still, it's not bad
[14:59:42] <scaphilo> how whould they spell sprüngli in english :-)
[14:59:51] <scaphilo> thats why they only get lidt
[15:00:07] <scaphilo> "only"
[15:06:14] <Tjoppen> never mind that av_rescale_rnd() thing btw.. it was just me being a bit careless with finding a common timebase between NTSC and AV_TIME_BASE - 2.997 GHz :o
[15:06:38] <Tjoppen> clamping at INT_MAX worked well enough
[15:06:55] <reynaldo> mornings
[15:08:18] <j-b> Alex, you are my hero
[15:09:01] <mru> nice one
[15:10:12] <peloverde> :)
[15:16:00] <_av500_> ?
[15:18:20] <mru> vlc-devel
[15:18:45] <_av500_> ah
[15:25:53] <j-b> 'seeking [in ogg] is a little more complex'. Euphemism...
[15:27:03] <Tjoppen> I love how lavf seeks in mxf - basically fseek(timestamp*bitrate/8)  :)
[15:27:29] <mru> oh no it's not</monty>
[15:27:45] <mru> constant bitrate?
[15:29:28] <Tjoppen> uses average bitrate derived somehow. it then scans for the next SMPTE UL
[16:12:32] <BBB> is ffmpeg-user generally so flamy?
[16:13:04] * mru fetches petrol
[16:13:05] <ramiro> BBB: phil rhodes is
[16:13:11] <BBB> I notice :)
[16:13:30] <BBB> he's full of bs also
[16:13:36] <ramiro> yep, he's a troll alright...
[16:13:39] <BBB> ban him
[16:14:19] <ramiro> he gets bored after a while and stops replying...
[16:14:37] <BBB> that doesn't explain why he wasn't banned
[16:15:03] <ramiro> well if we are going to ban trolls on our mailinglist we will lose some of the best devs
[16:15:21] <BBB> we can exempt devs from the ban-rule
[16:15:40] <BBB> or, more specifically, a non-trivial patch exempts you from a ban-on-troll
[16:15:59] <BBB> that actually makes people want to contribute, so they can freely troll
[16:16:10] <ramiro> "troll-driven development"?
[16:16:20] <mru> ramiro beat me to it...
[16:16:47] <BBB> I see a new t-shirt text
[16:17:02] <ramiro> someone suggested that a few days ago, I just repeated the idea =)
[16:17:12] <BBB> darnit I missed that
[16:17:21] <BBB> you should do it, it sounds unique
[16:17:30] <mru> we will
[16:17:35] <mru> or I will
[16:17:43] <mru> I usually make t-shirts
[16:19:40] <mru> there's also "hope driven development": http://www.makinggoodsoftware.com/2009/05/12/hdd/
[16:20:18] <hyc> hope driven? I hope I found that last bug?
[16:20:30] <mru> "I hope this will work"
[16:21:24] <jai> there's asshole driven development too, though the line between that and "tdd" would be pretty thin
[16:21:46] <mru> jai: that's what you get in most companies
[16:21:50] <BBB> troll-driven sounds better
[16:21:55] <mru> a-hole = phb and/or customer
[16:21:56] <BBB> I'm sure the linux kernel counts as that also
[16:22:52] <jai> heh
[16:27:19] <kierank> are there any alternatives to hex-rays
[16:27:49] <mru> octa-rays are 33% better
[16:27:58] <jai> kierank: boomerang but it sucks
[16:28:08] <kierank> jai: didn't work at all for me. just crashed
[16:28:11] <jai> so no good alternatives
[16:28:31] <jai> kierank: yep, it crashes on anything slight more complex than hello world
[16:28:47] <kierank> and it wasn't able to see the .text section either
[16:30:11] <KotH> .o0(FFdisasm)
[16:33:15] <BBB> kierank: ?
[16:33:19] <BBB> hexrays was quite good for me
[16:35:34] <lu_zero> uhm?
[16:36:05] <kierank> i'm not saying hex-rays is bad
[16:36:12] <kierank> i'm saying it's expensive ;)
[16:39:20] <kierank> but it does look very god
[16:39:21] <kierank> good*
[16:40:50] <BBB> oh
[16:40:54] <BBB> but hexrays-old is free
[16:41:03] <BBB> go to their website, click a few links, you'll see a free download link
[16:41:08] <BBB> that's what most of us use I think
[16:42:39] <kierank> are you talking about IDA or the actual hex-rays decompiler?
[16:42:51] <jai> hexrays isnt free
[16:43:01] <BBB> ah
[16:43:03] <BBB> I meant ida
[16:43:04] <BBB> sorry
[16:43:14] <BBB> (I thought you meant that company's product)
[16:53:48] <BBB> (addendum: IDA rocks; I tried hexrays and it is ridiculously poor)
[16:54:44] <peloverde> The HexRays video looks impressive
[16:55:05] * mru has never been impressed with a video of software
[16:55:59] <peloverde> then you clearly should watch this: http://www.youtube.com/watch?v=9pwUdRKllo0 ;-)
[17:16:16] <KotH> .o0(someone should teach the germans the meaning of "actual" and "current")
[17:40:25] <_av500_> eh?
[18:01:43] <Tjoppen> hah. smplayer sucks pretty bad
[18:02:19] <Tjoppen> tried playing a remote dv file via my crappy 10 Mbps connection (dv is >= 25 Mbps). it crashed
[18:08:23] <josh_> my first patch ever was for smplayer... i dont think it got applied, lol
[18:11:49] <Tjoppen> it's pretty good. I should try vlc again though
[18:12:07] <Tjoppen> too bad smplayer has all these strange little bugs everywhere
[18:12:55] <KotH> if anyone needs a weekend project to work on, have a look at: http://spectrum.ieee.org/consumer-electronics/gadgets/backyard-star-wars
[18:12:58] <KotH> :)
[18:23:05] <CIA-93> ffmpeg: rbultje * r23360 /trunk/libavformat/ (rmdec.c rm.c rm.h):
[18:23:05] <CIA-93> ffmpeg: Move rm_codec_tags to rm.c so muxer/demuxer can share it.
[18:23:05] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>.
[18:23:05] <CIA-93> ffmpeg: rbultje * r23361 /trunk/libavformat/rmenc.c:
[18:23:05] <CIA-93> ffmpeg: Use ff_rm_codec_tags[] in RM muxer. This, incidentally, also allows muxing
[18:23:05] <CIA-93> ffmpeg: other audio codecs rather than only AC-3, so add some code that makes
[18:23:06] <CIA-93> ffmpeg: word byte-swapping only happen for AC-3, not for all audio codecs.
[18:23:06] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>.
[18:23:07] <CIA-93> ffmpeg: rbultje * r23362 /trunk/libavformat/rmenc.c:
[18:23:07] <CIA-93> ffmpeg: Reindent after r23361.
[18:23:08] <CIA-93> ffmpeg: Patch by Francesco Lavra <francescolavra interfree it>.
[18:26:41] <Yuvi> BBB: yeah, VP8Macroblock is somewhat similar to MACROBLOCKD, though I'm trying to avoid having all the stuff that's in MACROBLOCKD in it
[18:26:42] <Yuvi> intra4x4 is per-block and should remain by itself so fill_rectangle works
[18:27:16] <BBB> macroblockd is a little big, yes
[18:27:37] <Yuvi> actually
[18:27:38] <BBB> so I think I need a structure that contains macroblock prediction params, but with edges
[18:27:44] <Yuvi> it's more MB_MODE_INFO
[18:27:46] <BBB> so I can't relaly use VP8Macroblock
[18:27:59] <kshishkov> BBB: whatever you think about Apple, thold keyboards were better </offtrolling>
[18:28:09] <Yuvi> per-mb? just add edges to VP8Macroblock
[18:28:49] <BBB> I'm confused, I thought edges were macroblocks
[18:28:55] <BBB> or are edges blocks within a macroblock?
[18:29:12] <Yuvi> what do you mean by edges? an additional non-existant mb on each side?
[18:30:40] <BBB> top/left, yes
[18:31:38] <Yuvi> yeah, just do similar to intra4x4 and offset the macroblocks array by 1+mb_stride from the base pointer (mb_width+1)*(mb_height+1) and add mb_stride
[18:32:14] <BBB> ok
[18:44:17] <BBB> Yuvi: I'll ask more stupid questions at random intervals, not everything makes sense to me yet, hope that's ok
[18:51:29] <CIA-93> ffmpeg: hyc * r23363 /trunk/libavcodec/ (h264.h h264_parser.c):
[18:51:29] <CIA-93> ffmpeg: Parse avctx->extradata if available.
[18:51:29] <CIA-93> ffmpeg: Fixes many "non-existing PPS referenced" error messages
[18:51:55] <Yuvi> BBB: of course
[19:46:40] <hyc> hm, I jumped the gone and committed this patch before Michael replied. https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/089557.html
[19:47:17] <hyc> what now, email a fixed patch again?
[19:47:40] <wbs> I guess that would be appreciated
[19:47:53] <wbs> but nice to have those warnings gone, h264 over rtp looks oh so nice now :-)
[19:47:59] <elenril> hyc: seppuku is the way to go
[19:48:13] <wbs> yeah, that's always an option, too ;P
[19:48:36] <hyc> going to change "first_picture" to "did_first"
[19:48:47] <hyc> unless someone has a better name
[19:48:57] <wbs> got_first perhaps?
[19:49:08] <hyc> ok
[19:49:16] <wbs> didn't the mpeg4 parser do something similar, how does that do it?
[19:49:26] <hyc> it does exactly what I posted.
[19:49:32] <wbs> ah. :-)
[19:49:32] <hyc> first_picture
[19:49:47] <hyc> and the wasteful init to first_picture=1
[19:49:55] <wbs> so, the lesson is, use existing code as example, unless when you shouldn't. :-)
[19:50:01] <hyc> sigh....
[20:08:11] <lu_zero> wbs: ?
[20:08:15] * lu_zero just wakes up
[20:09:05] <lu_zero> hyc: \o/ thank you =)
[20:09:17] <wbs> lu_zero: hyc commited a fix to the h264 parser, which spit out one warning per decoded frame earlier :-)
[20:09:26] <wbs> .. as you found out yourself. ;P
[20:10:33] <hyc> but the patch wasn't quite *perfect* ... doh
[20:11:05] <lu_zero> add a ! and 1 and you are set or not?
[20:12:35] <hyc> yep
[20:14:28] <hyc> and now it's done.
[20:14:33] <lu_zero> =)
[20:15:05] <CIA-93> ffmpeg: hyc * r23364 /trunk/libavcodec/ (h264.h h264_parser.c): Cleanup prev commit, flag variable should start with 0
[20:20:13] <lu_zero> seems working nicely
[20:22:34] <hyc> cool.
[20:22:59] <hyc> now the only thing left in my tree is factoring out this extradata parsing for rtpenc_h264
[20:23:28] <wbs> don't we have the ffserver timestamp issue, still?
[20:23:35] <hyc> hm, oh yeah
[20:23:42] <wbs> I'll ping that thread
[20:23:42] <hyc> I have the last patch you posted
[20:26:21] <lu_zero> hyc: btw
[20:26:42] <lu_zero> ffserver in rtp mode is just useful for on demand or I'm missing something?
[20:26:53] <hyc> on demand or live
[20:27:00] <lu_zero> how's set live?
[20:27:11] <hyc> use ffmpeg to push something into feed.ffm
[20:27:21] * lu_zero wants to hammer and compare it with dss and feng
[20:27:38] <hyc> I posted some sample configs to the list already, lemme dig one up
[20:29:07] <lu_zero> thank you
[20:29:40] <lu_zero> btw wbs and hyc you both played with ffmpeg network protocols
[20:29:46] <lu_zero> I need your opinion
[20:29:52] <hyc> https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088706.html
[20:30:23] <lu_zero> I'm willing to add sctp to the supported protocols
[20:31:01] <lu_zero> my main problem is that it has an interface for send and receive that you might consider similar to sendmsg
[20:31:30] <lu_zero> and you want/need to get the additional control data
[20:31:59] <lu_zero> where you'd store it?
[20:32:48] <hyc> easy kludge - prefix the data
[20:32:57] <hyc> I did this for LDAP over UDP
[20:33:40] <hyc> the low-level recv just puts the control info in a fixed-size header in front of the data
[20:34:05] <hyc> the higher level LDAP parser knows it's UDP and strips out the control info then falls thru to the regular LDAP message parsing
[20:34:43] <lu_zero> that was the first way I thought
[20:34:52] <josh_> e free encyclopedia
[20:34:53] <josh_> Mikhail Romadin designed the space statio[B[B[B[B[B [13:34] [josh_(+i)] [2:freenode/#ffmpeg-devel(+cnt)] [Act: 1]                                                                                    -- more --
[20:34:57] <josh_> [#ffmpeg-devel]
[20:35:00] <josh_>  [13:34] [josh_(+i)] [2:freenode/#ffmpeg-devel(+cnt)] [Act: 1]                                                                                    -- more --
[20:35:03] <josh_> [#ffmpeg-devel]
[20:35:04] <wbs> josh_: oops? ;P
[20:35:09] <wbs> josh_: and hi :-)
[20:35:12] <lu_zero> it is a bit annoying  but...
[20:35:15] <lu_zero> hi josh_
[20:35:27] <lu_zero> welcome =)
[20:35:54] <lu_zero> well I'll need to specialcase it anyway
[20:36:05] <CIA-93> ffmpeg: siretart * r23365 /branches/ (4 files in 4 dirs):
[20:36:05] <CIA-93> ffmpeg: matroskaenc: Write codec time base as default duration for video tracks.
[20:36:05] <CIA-93> ffmpeg: This isn't exactly semantically equivalent, but the field has already been
[20:36:05] <CIA-93> ffmpeg: long abused to mean this, and writing it helps in determining a decent cfr
[20:36:05] <CIA-93> ffmpeg: time base when transcoding from a mkv where the video codec stores none (VP8).
[20:36:06] <CIA-93> ffmpeg: backport r23284 by conrad
[20:37:57] <lu_zero> the other option was putting the data in the context
[20:38:09] <lu_zero> so you read and then fetch it from there
[20:38:38] <hyc> that sounds ok
[20:42:06] <lu_zero> I need this since you can send over the same socket messages with a different stream id
[20:42:52] <CIA-93> ffmpeg: alexc * r23366 /trunk/libavcodec/aaccoder.c: aacenc: Remove unnecessary variables and scopes in the TLS.
[20:46:28] <CIA-93> ffmpeg: alexc * r23367 /trunk/libavcodec/aaccoder.c: Cosmetics: whitespace
[20:53:14] <Compn> >we're new to working in the open source
[20:53:14] <Compn> environment
[20:53:24] <Compn> >gsoc running for 4+ years
[20:53:25] <Compn> :P
[20:55:29] <Yuvi> former on2
[20:56:13] <Compn> yeah, just funny :P
[20:58:14] <Compn> diego requests open sourcing all on2 codecs? ahaha
[20:58:22] <Compn> wishful thinking no doubt
[20:58:50] <wbs> well, why are they naming their lib vpx if it isn't supposed to contain them all? ;-)
[20:59:22] <peloverde> It's actually roman numerals, vp10
[20:59:31] <peloverde> 50% better than H.265 ;)
[20:59:32] <wbs> ah, of course. ;P
[21:02:06] <Vitor1001> some people get things so wrong
[21:02:22] <Vitor1001> http://news.slashdot.org/story/10/05/28/2014200/Google-WebM-Calls-Open-Source-Into-Question
[21:02:55] <Vitor1001> people really think that GPL incompatible => non-free??
[21:02:57] <Vitor1001> :p
[21:03:05] <mru> freetards do, yes
[21:03:21] <twnqx> when will they learn that the GPL is essentially non-free? :X
[21:03:27] <peloverde> I believe it's two separate posts on the same topic amalgamated
[21:04:20] <Dark_Shikari> gpl gives maximum freedom for developers at the expense of freedom for users
[21:04:28] <Dark_Shikari> or er, the reverse
[21:04:29] <Dark_Shikari> that's bsd
[21:04:32] <peloverde> anyway should libvpx be under --enable-nonfree?
[21:04:39] <Dark_Shikari> gpl gives maximum freedom for users at the expense of freedom for developers.
[21:04:42] <Dark_Shikari> etc.
[21:04:49] <Dark_Shikari> peloverde: that would be great.
[21:05:08] <mru> or just ignore it
[21:05:11] <mru> they're fixing the licence
[21:05:13] <Vitor1001> peloverde: I think it would be under --enable-nonfree if google takes more than a week to solve it
[21:05:19] <Dark_Shikari> ok, yes, that's better
[21:05:23] <Dark_Shikari> if they can't fix it in due time
[21:05:24] <Dark_Shikari> nonfree it
[21:05:33] <Dark_Shikari> give 'em a few weeks.
[21:05:52] <peloverde> Maybe if this were an organic release I'd want tot cut them some slack
[21:06:04] <mru> organic?
[21:06:06] <mru> wtf?
[21:06:24] <Dark_Shikari> mru: no artificial flavorings.
[21:06:35] <peloverde> but they did this cart before the horse special effects and puppies and rainbows big release from nowhere, and they have failed over and over again to get the little things right
[21:08:17] <peloverde> If menno said he was "trying" to relicense libfaac would you move that out of enable-nonfree?
[21:10:31] <Dark_Shikari> but google owns the code
[21:10:33] <Dark_Shikari> they can relicense it
[21:10:38] <Dark_Shikari> menno doesn't own the problematic code
[21:10:39] <peloverde> and yet they haven't
[21:11:29] <peloverde> I guess I missed the memo where we became part of the Google PR department?
[21:14:05] <hyc> wbs: my mistake. currently the only timing patch I have in ffserver.c is to bypass the av_seek_frame
[21:14:30] <hyc> and it's working...
[21:14:56] <wbs> hyc: yeah, but I'm not sure that would work if we'd call the seek
[21:15:09] <wbs> I see it this way: either we fully can assume start_time always is initialized
[21:15:27] <wbs> OR, the if statement checking start_time absolutely needs an else clause doing something sensible
[21:15:39] <hyc> good point
[21:15:51] <wbs> in the former case, the if statement as such is unnecessary since we never should hit the else branch
[21:16:15] <wbs> in the latter, we need to make sure the values are in the correct range regardless of start_time
[21:30:46] <CIA-93> ffmpeg: alexc * r23368 /trunk/libavcodec/aaccoder.c: aacenc: Remove an unnecessary division from the TLS.
[21:33:08] <DonDiego> say
[21:33:18] <DonDiego> linuxtag clashes with the world cup...
[21:33:30] <mru> fine with me
[21:33:43] <mru> worse that it clashes with that damned air show
[21:33:55] <mru> or whatever is eating hotels for breakfast
[21:34:06] <lu_zero> ....
[21:42:35] <janneg> DonDiego: I'm sure there will be inofficial public viewing
[21:42:58] <kierank> put the football on the ffmpeg screens
[21:43:23] <janneg> and if not we can organize it
[21:44:19] <mru> if it's anything like here, there won't be many pubs _not_ showing the games
[21:44:25] <DonDiego> there is simply no thing in this world that will make me miss the argentina game
[21:44:28] <DonDiego> s
[21:44:43] <DonDiego> well, childbirth, accidents and similar maybe..
[21:45:08] * mru locks DonDiego in a room without tv or internet
[21:47:50] <lu_zero> DonDiego: ADDICTED!
[21:48:17] <janneg> I was more thinking of the fairground as the match argentinia nigeria is 16:00 local time saturday
[21:49:11] <DonDiego> yes
[21:49:28] <DonDiego> i'm not addicted, i'm passionate
[21:49:33] <mru> same thing
[21:58:46] <BBB> he's in denial
[21:59:32] <peloverde> It's an interesting game but it's no starcraft
[21:59:44] <DonDiego> i'm in no state of denial at all
[22:00:00] <kierank> what's the special thing between germany and argentina?
[22:00:02] <DonDiego> there is no higher priority except life and death
[22:00:15] <DonDiego> kierank: the history :)
[22:00:17] <kierank> ofc over here it's england vs germany and england vs argentina
[22:00:19] <DonDiego> also, i'm from argentina..
[22:00:24] <kierank> oh
[22:00:47] <kierank> the argentina rivalry is maradonna and falklands based
[22:01:44] <DonDiego> argentina - england, yes
[22:02:05] <DonDiego> argentina - germany rivalry comes from 86/90
[22:02:21] <mru> Yuvi: mmx has no non-rounding avg?
[22:02:27] <Yuvi> mru: nope
[22:02:30] <mru> what a joke
[22:03:03] <Yuvi> in fact, just mmx has no rounding avg either
[22:31:56] <DonDiego> Yuvi: seen gmaxwell's mail?
[22:32:12] <DonDiego> Yuvi: when was the last time you ran theora benchmarks?
[22:32:21] <Yuvi> some time ago
[22:32:24] <Yuvi> where?
[22:32:41] <DonDiego> foms mailing list
[22:32:50] <DonDiego> i think i CCed you on my reply, didn't i?
[22:33:06] <Yuvi> the charts with ffmpeg a bit behind libtheora?
[22:33:25] <mru> Yuvi: did the changes you did this week make much difference?
[22:33:27] <Yuvi> iirc gmaxwell's machine/toolchain likes libtheora better
[22:33:36] <DonDiego> yes, that one
[22:33:55] <mru> Yuvi: how did he manage to find such a combination?
[22:34:20] <Yuvi> mru: only the put_no_rnd should have any effect on speed
[22:34:30] <DonDiego> well, it's his machine, he must have bought it considering that criterion
[22:34:31] <DonDiego> ;)
[22:34:38] <Yuvi> the dc one cut out a few instructions
[22:35:04] <mru> Yuvi: what about skipping the loop filter when strength = 0?
[22:35:19] <mru> sounds like it would be doing less work
[22:35:31] <Yuvi> DonDiego: yeah, basically a while back we were benching on the same file in the same way, and my machine beat libtheora by 10% wheras on his libtheora won by 5%
[22:35:37] <Yuvi> (approximately)
[22:35:46] <Yuvi> mru: oh right, that
[22:35:51] <DonDiego> weird..
[22:35:54] <mru> do you know what compiler he uses?
[22:36:11] <mru> maybe he has a very noisy machine and picks the results carefully
[22:36:28] <bcoudurier> Yuvi, FAST flag can be used
[22:36:34] <bcoudurier> for non-bitexact optims
[22:36:35] <Yuvi> that should give ~7-10% boost when the loop filter is done
[22:36:42] <Yuvi> not done
[22:37:18] <Yuvi> bcoudurier: same problem, are codecs allowed to set that? the bitexact selection is in dsputil
[22:37:32] <bcoudurier> no
[22:37:34] <bcoudurier> but user can
[22:37:43] <bcoudurier> by default -> bitexact
[22:37:46] <bcoudurier> fast -> fast
[22:37:57] <Yuvi> mru: I doubt he's intentionally skewing the results
[22:37:59] <bcoudurier> not necessarly bitexact
[22:38:01] <mru> default bitexact would be very bad
[22:38:15] <Tjoppen> BBB: poke btw
[22:38:19] <mru> that would disable fast mpeg2 idct etc by default
[22:38:21] <Yuvi> and he should be good enough to do benches fairly
[22:38:27] <BBB> Tjoppen: sorry, haven't looked yet
[22:38:33] <bcoudurier> default has always been to be bitexact
[22:38:35] <bcoudurier> to the reference suite
[22:38:36] <mru> Yuvi: I don't trust those people
[22:38:36] <Tjoppen> k
[22:38:39] <BBB> I'm trying to understand vp8...
[22:38:43] <BBB> it's on my list
[22:38:46] <Tjoppen> aren't we all :)
[22:38:58] <mru> bcoudurier: only for codecs that have an exact definition
[22:39:06] <bcoudurier> yes, the ones that matters
[22:39:25] <mru> are you saying mpeg2, mpeg4, and all audio codecs are irrelevant?
[22:39:47] <bcoudurier> these conform to the reference implementation AFAIK
[22:39:56] <bcoudurier> ie libavcodec outputs the same
[22:40:01] <mru> they are within the required limits, yes
[22:40:14] <bcoudurier> theora should do the same
[22:40:17] <mru> they are not exact even across different machines
[22:40:35] <mru> much less against some reference code
[22:41:42] <bcoudurier> it seems only mpeg2 switch unquant intra
[22:41:48] <bcoudurier> depending on bitexact
[22:42:01] <mru> the default idct is different
[22:42:18] <mru> look at dsputil_init_mmx() or wherever it's set
[22:42:20] <bcoudurier> since md5 match on every arch
[22:42:26] <bcoudurier> I guess it's bitexact
[22:42:37] <mru> the regtests use -flags +bitexact
[22:42:47] <bcoudurier> yes so it only mpeg2 unquan intra changes
[22:42:51] <bcoudurier> everything else stays the same
[22:43:05] <bcoudurier> so the default is bitexact except for this case
[22:43:37] <mru> well, grep for CODEC_FLAG_BITEXACT and see is affected by it
[22:43:43] <mru> *what
[22:43:56] <bcoudurier> unquant intra for mpeg2 function
[22:44:19] <mru> and a bunch of other things
[22:44:22] <mru> I don't remember them all
[22:44:44] <mru> I get 33 matches
[22:44:47] <bcoudurier> wmaenc, tiffenc, aacenc, acelp, lsp mjpegenc, mpeg4enc
[22:45:10] <bcoudurier> and it's for the libavcodec ident
[22:46:15] <mru> there's about a dozen matches in libavcodec/x86
[22:46:37] <mru> but that's beside the point
[22:46:44] <mru> being slow by default is stupid
[22:46:53] <mru> default should be as fast as possible within spec
[22:47:11] <mru> even if that means varying across machines
[22:48:33] <Dark_Shikari> Unless the spec involves being the same.
[22:48:47] <mru> that's why I said "within spec"
[22:51:51] <bcoudurier> yes I agree
[22:53:27] <mru> hmm.. why so many branch mispredics in h264 loop filter?
[22:53:36] <Dark_Shikari> because the C code is branchy?
[22:53:59] <mru> the miss rate is disproportionately high there
[22:54:19] <mru> and yes, I'm measuring the C code
[22:55:14] <mru> it's also where most of the branches are happening
[22:55:24] <Dark_Shikari> why use the c code, use asm
[22:55:31] <Dark_Shikari> and of course the c code has tons of mispreds
[22:55:59] <mru> I have reasons for doing this
[22:56:09] <Dark_Shikari> explain them :)
[22:56:14] <mru> someone is paying
[22:56:40] <mru> this is just one of many tests
[22:57:43] <mru> comparing some CPUs in different ways
[22:58:02] <mru> using asm on some and not others wouldn't be fair
[23:00:27] <BBB> if the asm is never used in practice, what's the use?
[23:00:48] <Dark_Shikari> the c you mean
[23:01:00] <BBB> well yeah, sorry :)
[23:01:25] <mru> there isn't asm for all cpus
[23:01:40] <BBB> yes, but the same cpu will consistently use the same asm
[23:01:57] <mru> if the point is to compare branch prediction of different cpus?
[23:02:17] <mru> this is just a sample load
[23:02:19] <BBB> isn't that code-dependent?
[23:02:26] <mru> of course it is
[23:02:33] <mru> that's why this is only one of many tests
[23:02:37] <BBB> in other words, you're using an artificial testcase that will never in reality be run on that cpu
[23:02:49] <BBB> I won't bore you with my naiveness ;)
[23:03:06] <mru> there is no asm written for the cpu I'm looking at now
[23:03:14] <Dark_Shikari> but if it was to be used, asm would be written
[23:03:24] <Dark_Shikari> and more importantly
[23:03:31] <Dark_Shikari> the asm would have very different performance characteristics frmo the C
[23:03:32] <BBB> maybe the company wants to create a cpu that-needs-no-special-asm
[23:03:35] <Dark_Shikari> e.g. improving branch pred wouldn't help
[23:03:38] <Dark_Shikari> BBB: then they fund orc
[23:03:41] <mru> what the code does is unimportant
[23:04:04] <BBB> I guess I sort-of- see the point
[23:04:24] <mru> it's just a test of how the cpu behaves under this type of load
[23:04:42] <mru> this tests happens to have many hard to predict branches
[23:04:56] <mru> there's lots of code like that
[23:16:20] <CIA-93> ffmpeg: bcoudurier * r23369 /trunk/libavcodec/h264.c: In h264 decoder, use jpeg yuv pixel format when full range is set in vui