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

[irc at mansr.com]

[00:04:43] <iive> sounds like sami. to clear subtitle you need empty line.
[00:05:20] <hyc> then that would be it, yeah
[00:05:28] <hyc> mplayer isn't playing it tho
[00:05:37] <hyc> stripped down to srt works
[00:06:07] <CIA-92> ffmpeg: michael * r23501 /trunk/ (10 files in 8 dirs): Add simple rgb/yuv in avi regression test.
[00:06:14] <hyc> would be nice to get this working in FLV as event cuePoints
[00:06:22] <hyc> but I guess it's not a big deal
[00:07:15] <hyc> these guys seem to support it http://www.moyea.com/forum/viewtopic.php?t=138
[00:08:34] <hyc> cuePoints get encoded as an AMF array in the onMetaData chunk at the beginning of the file
[00:09:14] <iive> ?
[00:09:23] <iive> flv uses sami?
[00:09:25] <hyc> seems a bit awkward to me, not sure why they didn't just embed them at their appropriate times in the stream
[00:09:27] <hyc> no no
[00:09:39] <hyc> hulu provides captions in sami format as a separate file
[00:09:49] <iive> what is hulu?
[00:09:49] <hyc> I was looking for a way to embed captions in flv
[00:09:55] <hyc> www.hulu.com
[00:10:03] <hyc> US-only tv/movie streaming site
[00:11:02] <iive> oh...
[00:11:07] <dezodorant> us-only...
[00:13:32] <dezodorant> this fckn mpegaudio_parser makes me cry. i understand why it`s works wrong, but don`t know how can i combine old one code and new one
[00:15:03] <iive> n8 ppl
[03:23:21] <peloverde> mru, maybe time to unban ohsix?
[03:30:46] <mru> peloverde: unban if you want him
[03:30:50] <mru> I'm in no rush
[08:29:22] <KotH> grüezi
[10:51:58] <CIA-92> ffmpeg: reimar * r23502 /trunk/libavformat/gxf.c: Support AVFMT_FLAG_IGNIDX in gxf demuxer.
[11:01:18] <CIA-92> ffmpeg: michael * r23503 /trunk/libavcodec/rawdec.c: fix rgb444 support in avi.
[11:32:23] <_av500_> kshishkov: today i travelled on: http://www.flickr.com/photos/av500/4673981263/
[11:44:42] <CIA-92> ffmpeg: michael * r23504 /trunk/ (libavformat/nut.c libavcodec/raw.c): bgr/rgb444 for nut
[12:54:40] <Dark_Shikari> fyi, someone broke hardcoded-tables
[12:56:36] <lu_zero> not me
[13:11:04] <lu_zero> hyc: ping
[13:18:03] <mru> someone broke a lot of things
[15:28:28] <CIA-92> ffmpeg: reimar * r23505 /trunk/libavcodec/Makefile: aacdec also depends on cbrt_tables.h for hardcoded-tables.
[15:48:33] <kshishkov> _av500_: I heard you call them "Dampfzug", there is one going in Stockholm sometimes
[16:02:09] <mru> janneg: ping
[16:08:59] <janneg> mru: pong
[16:09:26] <mru> janneg: status of BBB?
[16:15:35] <janneg> rendering almost fnished, I'll encode the complete scenes later tody
[16:51:16] <CIA-92> ffmpeg: mru * r23506 /trunk/tests/ref/seek/ (yuv.avi.ref rgb.avi.ref): regtest: add seektest reference files for rgb/yuv in avi
[17:26:23] <pJok> mru, why haven't you killed off OS/2 support yet? ;)
[17:27:32] <kierank> because some people live in 1995?
[17:28:09] <pJok> i know mru does not live in 1995
[17:28:15] <kierank> mru doesn't
[17:28:32] <kshishkov> maybe it's not that bad in API as *BSD
[17:28:57] <pJok> kshishkov, thats just because BSD people like to reverse engineer the wheel and implement it their own way
[17:29:35] <pJok> im still pondering on wether i should root my phone now or wait for android 2.2 to arrive
[17:29:40] <kshishkov> yep, triangular - it makes jess bumps per turn
[17:29:46] <kshishkov> *less
[17:30:10] <kshishkov> so it's optimal wheel, isn't it?
[17:30:33] <pJok> of course
[17:51:07] <iive> kshishkov: depends on the road.
[17:51:39] <kshishkov> yep, epicycloidal roads in vacuum
[17:55:15] <iive> i guess you mean something like that http://www.sciencenews.org/view/generic/id/4877/title/Riding_on_Square_Wheels
[17:55:59] <kshishkov> yes
[17:56:14] <kshishkov> looks like BSD way indeed
[17:59:20] * mru thought bsd was all about the forks, not wheels
[17:59:47] <kshishkov> wheels sometimes are hold with forks
[18:15:32] <BBB> wbs: thanks, I was about to go review the same patch ;)
[18:15:43] * BBB thinks wbs should be soc mentor for all students
[18:28:17] <wbs> BBB: thanks :-)
[18:30:37] <CIA-92> ffmpeg: stefano * r23507 /trunk/libavcodec/imgconvert.c: Fix width computation for nv12/nv21 in ff_get_plane_bytewidth().
[18:30:37] <CIA-92> ffmpeg: stefano * r23508 /trunk/ (libavformat/nut.c libavcodec/raw.c): Add support to B4BY and R4BY NUT codec tags added in NUT r672.
[18:47:06] <siretart> mru: I've just rechecked, but it's not possible to do that trick in the version script, it really needs to be done as asm directives
[18:47:31] <siretart> mru: do we support a single platform with gnu ld but not gcc? which?
[18:48:14] <wbs> what about icc on linux, does that use its own linker, or gnu ld?
[18:49:39] <CIA-92> ffmpeg: reimar * r23509 /trunk/libavformat/rmdec.c:
[18:49:39] <CIA-92> ffmpeg: Do not read the RM index when input is streamed (since it requires seeking
[18:49:39] <CIA-92> ffmpeg: forward and then back again) or AVFMT_FLAG_IGNIDX is set.
[18:51:18] <CIA-92> ffmpeg: stefano * r23510 /trunk/tests/lavfi-regression.sh:
[18:51:18] <CIA-92> ffmpeg: Do not exclude anymore the pixel formats rgb444, bgr444, rgb4_byte,
[18:51:18] <CIA-92> ffmpeg: and bgr4_byte from the lavfi-pix_fmts test.
[18:51:18] <CIA-92> ffmpeg: The formats are now supported by NUT.
[18:51:24] <siretart> hm, that's probably possible.. hmm
[19:03:28] <mru> siretart: many non-gcc compilers on linux use the native linker
[19:04:12] <siretart> mru: hm. perhaps the configure check can be improved then?
[19:04:25] <mru> that's not the issue
[19:05:19] <mru> we want to use the versioning if the linker supports it
[19:05:31] <mru> regardless of compiler/assembler
[19:05:44] <mru> you'd be removing functionality by making the check stricter
[19:06:03] <siretart> well, this trick only works with gas
[19:06:10] <mru> that's the point
[19:06:22] <mru> the version scripts depend on the _linker_
[19:06:29] <mru> your hack uses the _assembler_
[19:06:56] <siretart> hm, then I create a check for the assemler, and do that hack only when the assembler supports it, right?
[19:07:05] <mru> that will break
[19:07:21] <siretart> what will break?
[19:07:27] <mru> all of it
[19:07:33] <siretart> please elaborate
[19:07:46] <mru> your wrapper functions won't be used
[19:07:56] <mru> because the renaming isn't done
[19:08:11] <siretart> in that case, the wrapper won't be compiled at all
[19:08:17] <siretart> this won't be a regression
[19:08:23] <mru> but the symbol versioning is still there
[19:08:28] <lu_zero> <@siretart> mru: do we support a single platform with gnu ld but not gcc?
[19:08:29] <siretart> so?
[19:08:31] <mru> so it's as broken as when we started
[19:08:34] <lu_zero> clang ?
[19:08:38] <mru> lu_zero: plenty
[19:08:46] <mru> armcc
[19:08:50] <mru> TI compiler
[19:08:54] <mru> compaq ccc
[19:09:00] <mru> last one not important
[19:09:01] <lu_zero> that reminds me that I wanted to do stuff with armcc
[19:09:04] <lu_zero> =|
[19:09:08] <siretart> mru: not on platforms with gcc and gas. so what's your point?
[19:09:21] <mru> half a fix is no fix
[19:09:24] <lu_zero> siretart: clang on linux and freebsd...
[19:09:39] <lu_zero> but I'm digressing
[19:09:55] <siretart> mru: well, you admit that there is no fix, so you block fixing it on platform where it is possible?
[19:10:11] <siretart> there is no fix on some platforms, so you..
[19:10:13] <mru> I didn't say a fix is impossible
[19:10:16] <mru> I just haven't found it yet
[19:14:14] <siretart> well, the gnu extension is basically what we want here: define the same symbol twice, and declare one as the default symbol
[19:14:35] <siretart> the only other solution I see here is bumping soname
[19:14:50] <lu_zero> why that would be bad?
[19:15:09] <mru> it wouldn't imo
[19:16:44] <siretart> then just do it
[19:19:28] <lu_zero> good we got a simpler solution =)
[19:20:33] <siretart> with obvious drawbacks
[19:20:47] <mru> minor
[19:20:54] <Dark_Shikari> Yuvie: I think we never fixed dirac lossless...
[19:21:06] <siretart> well, that depends on the POV
[19:21:55] <siretart> the fact that non gcc platform don't benefit from my patch is a minor detail to me as well. but I understand that it is important to you
[19:22:10] <mru> we can't leave supported platforms broken
[19:22:40] <mru> either you fix the entire problem, or you don't fix it at all
[19:23:46] <siretart> thanks for acknowledging the problem :-)
[19:24:01] <mru> I'm not denying there's a problem at all
[19:24:22] <mru> but I strongly disagree with an ugly fix that doesn't even fix it
[19:32:05] <lu_zero> mru: btw in the end it's ok to add pkg-config for librtmp?
[19:32:19] <mru> you leave me no choice
[19:32:20] <lu_zero> (talking about things you dislike ^^; )
[19:35:18] <lu_zero> hi peloverde
[19:35:27] <peloverde> hey
[19:36:01] <CIA-92> ffmpeg: lu_zero * r23511 /trunk/configure:
[19:36:02] <CIA-92> ffmpeg: librtmp may link to different ssl implementations
[19:36:02] <CIA-92> ffmpeg: Make sure we link using the right libs by using pkg-config
[19:36:35] <BBB> oh no, pkg-config support
[19:36:37] <BBB> we're all gonna die
[19:36:47] <mru> yes, we are
[19:37:02] <mru> the commit message is somewhat overly positive
[19:37:15] <mru> s/make sure/attempt/ would be more accurate
[19:38:51] <lu_zero> mru: how you'd like to replace pkgconfig?
[19:39:08] <mru> adding proper deps to .a files
[19:39:15] <mru> just like for .so
[19:39:53] <lu_zero> and then tell the linker to do it's job
[19:40:03] <mru> yes
[19:40:10] <lu_zero> anybody tried to propose that already?
[19:40:15] <mru> too late now
[19:40:19] <lu_zero> why?
[19:40:28] <mru> pkgconfig has infected the world
[19:40:41] <siretart> how is 'adding proper deps to the .a files' to work in practice? - using something else than ar archives? adding a special metadata member to the archive?
[19:40:55] <mru> adding a file to the archive with a list of deps
[19:40:57] <siretart> pkg-config chooses to place the .la file next to the .a file
[19:41:06] <mru> .a files are just a dumb archive of files
[19:41:16] <mru> siretart: .la is libtool, not pkgconfig
[19:41:20] <mru> and is even more broken
[19:41:24] <siretart> err, right.
[19:41:28] <siretart> I meant .pc files
[19:41:44] <lu_zero> the .pc file is doing the same but outside
[19:41:47] <mru> the .pc files are _not_ beside the .a files
[19:41:50] <lu_zero> maybe trying to do too much
[19:41:53] <mru> and they contain bogus information
[19:42:01] <lu_zero> mru: depends
[19:42:15] <mru> they're solving a problem that isn't
[19:42:24] <mru> largely
[19:42:36] <mru> there is a problem with deps for static libs
[19:42:41] <mru> there's no denying that
[19:42:55] <mru> but pkgconfig goes much further
[19:44:48] <lu_zero> and is a bit too large for what it does IMHO
[19:45:18] <mru> it over-solves the problem, thereby introducing more problems
[19:48:40] <lu_zero> well I must say that's better than libtool's la
[19:49:02] <mru> some idiots combine both
[19:49:16] <lu_zero> o_O?
[19:49:31] <lu_zero> combine or provide?
[19:49:39] <CIA-92> ffmpeg: reimar * r23512 /trunk/libavcodec/Makefile: 10l, there is no aac.c any more, so no need for a dependency.
[19:50:51] <mru> that's not really a 10l
[19:53:01] <Compn> reimar sure is hard at work
[19:53:19] <mru> lu_zero: why do (some of) your replies on the ml ignore the reply-to header?
[19:58:06] <lu_zero> ignore how?
[19:58:26] <mru> lu_zero: sent directly to me with ffmpeg-devel in cc and such things
[19:58:39] * lu_zero should doublecheck thunderbird settings
[19:58:52] <lu_zero> sorry probably my bad
[19:58:59] <mru> so my simple filter misfiles them
[19:59:04] <mru> I can adjust it of course
[19:59:15] <mru> just thought I'd let you know
[19:59:39] <lu_zero> there is a reply-to-list option I nagged to have in their bugzilla loong ago
[20:02:16] <lu_zero> meh, I'll have to use reply on ffmpeg-ml for a while =P
[20:03:34] <mru> there, filter rules adjusted
[20:03:41] <mru> hopefully I won't be annoyed by this again
[20:03:55] <mru> I was filtering on List-Id
[20:07:42] * lu_zero updates thunderbird
[20:10:01] * Compn wonders if last lgpl violation roundup issue was a rival youtube downloader author who wanted to smear his competition
[20:11:29] <wbs> Compn: nevertheless, it's a good argument against for anyone to choose something else than that software
[20:12:33] <wbs> whoa, "nice" feature in libvpx: if the desired bitrate seems to be too low, it simply starts skipping frames in the encoder, skipping every second frame
[20:14:46] <Compn> wbs : too many double negatives in there i got lost :P
[20:14:57] <wbs> Compn: ;P
[20:15:37] <wbs> Compn: regardless of who reported it - if some software violates open source licenses, it's a good reason to choose another software to do that particular task
[20:15:47] <Compn> ah
[20:16:07] <wbs> even if it may seem as the rival is badmouthing it, it's very well earned
[20:16:08] <Compn> yeah but the report was invalid, that software has a big link and info at the bottom of the main page...
[20:16:13] <lu_zero> wbs: sounds a bit radical as feature frameskipping in the encoder
[20:16:18] <Compn> hense why i thought it was a rival...
[20:16:33] <wbs> Compn: ah, well then it's another thing entirely :-)
[20:16:33] <Compn> link to ffmpeg and source code locally hosted* that is
[20:17:00] <wbs> lu_zero: indeed... luckily, it at least seems to be exposed in the libvpx api, so the lavc wrapper can disable it
[20:17:37] <lu_zero> so it's just a bad default
[20:17:51] <wbs> yeah
[20:18:01] <Dark_Shikari> iirc theora did the same thing
[20:18:04] <Dark_Shikari> it is extraordinarily annoyoing
[20:18:08] <Dark_Shikari> but at least in libvpx you can disable it
[20:18:45] <wbs> in this case, it seems to stay at that decimation level even after that segment where it was needed, halving the framerate for the rest of the clip
[20:21:24] <Dark_Shikari> imo we should disable it by default
[20:21:43] <wbs> yeah, I'm preparing a patch for that right now
[20:22:36] <wbs> the thing I mailed about yesterday is "nice", too... if you set keyint_min == gop_size, it sets an encoder mode where no keyframes are output at all
[20:23:51] <Compn> heh
[20:24:13] <Compn> if you have low bitrate, it should automatically turn on the full cpu burn to get more bits in there :)
[20:25:04] <wbs> uh, for this particular clip I'm testing with, it doesn't even seem to need any more bitrate at that point, it just spontaneously chooses to start dropping frames after 89 sec
[20:25:26] <wbs> even if the output bitrate is roughly the same there compared to the rest of the file ;P
[20:26:05] <Compn> are you sure you didnt set like a 'total bitrate per file' option ?
[20:26:14] <Compn> 800K of video bitrate, then drop everything
[20:26:36] <wbs> I haven't set anything fancy at all, just using the lavc/libvpx defaults and ffmpeg without any options at all
[20:26:54] <wbs> don't really know what other odd defaults the lavc/libvpx wrapper sets
[20:27:02] <wbs> or libvpx for that matter
[21:42:24] <lu_zero> hyc: poing
[21:55:26] <bcoudurier> hi guys
[22:06:48] <hyc> lu_zero: gniop
[22:29:19] <lu_zero> hyc: do you have plans for a newer rtmpdump release?
[22:29:49] <lu_zero> I'd like to have librtmp support pic and possibly shared object
[22:52:05] <janneg> mru: I'm not sure if lossless x264 was a good idea, video is already 7G
[22:53:50] <hyc> lu_zero: no plans at the moment
[22:54:39] <mru> janneg: can you slice and encode the final version?
[22:55:40] <Dark_Shikari> this the BBB wall thing?
[22:55:50] <hyc> will need to patch a couple places in librtmp.c to make it safe/version independent
[22:57:32] <lu_zero> right now I'm forcing -fPIC in the gentoo ebuild
[22:57:59] <lu_zero> and use the static one
[23:03:44] <Dark_Shikari> janneg: ?
[23:04:25] <janneg> mru: probably. what did you use to slice the clips
[23:04:49] <mru> ffmpeg
[23:04:51] <janneg> Dark_Shikari: big buck bunny at 2700x1440
[23:05:10] <Dark_Shikari> you sure x264 lossless will play back fast enough on the beagleboards?
[23:05:57] <janneg> Dark_Shikari: probably not, that was just intended to losslessly transfer the source video to mru
[23:06:47] <janneg> the source pngs are 38G
[23:06:49] <Dark_Shikari> ah
[23:07:06] <Dark_Shikari> and x264 lossless is 7GB so far?  I'd expect it to be smaller
[23:07:32] <janneg> -vpre lossless-fast
[23:08:18] <Dark_Shikari> ah, that one has cabac off.
[23:08:35] <Dark_Shikari> on the other hand, you'll probably save enough time in encode + decode to justify the increased upload time =p
[23:12:01] <janneg> lossless-medium doesn't look that much slower
[23:14:50] <janneg> 16% smaller
[23:17:36] <janneg> mru: any special encoder settings? bitrate?