[FFmpeg-devel-irc] IRC log for 2010-09-22

[irc at mansr.com]

[00:17:59] <saintdev> you mean they actually would update...?
[02:18:55] <CIA-63> ffmpeg: rbultje * r25157 /trunk/doc/optimization.txt: Fix typo (instruciton -> instruction).
[05:37:38] <KotH> bonjour
[05:37:56] <kshishkov> servus
[07:15:10] <kshishkov> KotH: it seems to be excatly 102 years since proclamation of Bulgarian independence, time to celebrate
[07:17:03] <_av500_> we switch to bulgarian notation?
[07:18:03] <kshishkov> what so special about it?
[07:18:20] * iive wonders what he had done last night.
[07:18:47] <Dark_Shikari> what code in ffmpeg allocates Pictures?
[07:18:56] <Dark_Shikari> ff_alloc_picture doesn't allocate the Picture, it allocates the contents of the Picture
[07:18:57] <kshishkov> get_buffer
[07:18:59] <Dark_Shikari> i.e. there's two steps
[07:19:03] <Dark_Shikari> 1) allocate the Picture struct
[07:19:05] <Dark_Shikari> 2) allocate the pointers in it
[07:19:11] <Dark_Shikari> 2 is done with ff_allocate_picture
[07:19:15] <Dark_Shikari> but how do I do 1?
[07:19:23] <Dark_Shikari> am I just supposed to malloc every single time?
[07:19:29] <kshishkov> and struct is usually part of context and is allocated along with it
[07:19:39] <Dark_Shikari> But I'm dealing with pointers to pictures.
[07:19:52] <Dark_Shikari> a "copy" is copying a pointer.
[07:20:04] <Dark_Shikari> But ffmpeg REALLY doesn't like it when I put two of the same frame in the reference list
[07:20:12] <Dark_Shikari> (same frame in memory, that is)
[07:20:21] <Dark_Shikari> so I want to just try duplicating it.
[07:20:45] <kshishkov> look at h264 decoder
[07:20:54] <Dark_Shikari> That's what I'm looking at
[07:21:01] <Dark_Shikari> it's beyond ridiculous
[07:21:18] <kshishkov> feel free to submit a simplification patch
[07:21:23] <Dark_Shikari> rm -rf
[07:22:31] <cartman> Dark_Shikari: Password:
[07:22:44] <iive> if I remember right, (and I'm not really sure I do), there is difference in meaning between frame and picture. You allocate memory for a frame, and then you allocate picture in the frame
[07:23:01] <iive> the picture could be frame, or one of the 2 fields.
[07:26:56] <mru> Dark_Shikari: the struct holding the pointer is typically "static" somewhere else
[07:28:20] <Dark_Shikari> it turns out my patch from the other day breaks decoding much later
[07:28:24] <Dark_Shikari> after a number of lost frames
[07:28:29] <Dark_Shikari> because it fucks up the memory handling
[07:28:40] <Dark_Shikari> apparently ffmpeg just assumes all frames in the ref list are different.
[07:31:03] <mru> does the spec allow duplicate entries?
[07:31:38] <Dark_Shikari> Of course not, there's no way that could happen afaik
[07:31:49] <Dark_Shikari> But in practice you need to support it for error concealemnt
[07:31:53] <Dark_Shikari> if you lose a frame, you have to stuff something there
[07:32:08] <mru> not encouraged doesn't imply forbidden
[07:32:54] <Dark_Shikari> There is no way it can happen
[07:33:00] <Dark_Shikari> because no MMCO operation results in the duplication of frames
[07:33:02] <Dark_Shikari> they just move frames around
[07:33:32] <Dark_Shikari> Well, I made it stop generating massive floods of errors.  Now it just crashes in ntdll!RtlUpdateClonedSRWLock.
[07:33:32] <mru> right
[08:00:48] <KotH> kshishkov: this independence will end
[08:01:01] <KotH> kshishkov: .tr is currently discussing whether they should buy .gr :)
[08:01:17] <kshishkov> again?
[08:01:25] <cartman> KotH: lol
[08:18:11] <superdump> what does that have to do with bulgaria?
[08:18:35] <lu_zero> good morning Honoome
[08:19:09] <lu_zero> KotH: brrr...
[08:30:35] <Dark_Shikari> someone answer my email so my boss can stop breathing down my neck
[08:30:40] <Dark_Shikari> (ffmpeg-devel)
[08:31:16] <Dark_Shikari> I reimplemented my own entire reference counting system and I still can't get it to work
[08:32:12] <cartman> Dark_Shikari: that was the best patch mail I have seen ever
[08:33:04] <Dark_Shikari> It isn't a patch mail.
[08:33:17] <cartman> patch mail asking for help :P
[08:33:18] <Dark_Shikari> lol
[08:33:28] <Dark_Shikari> "this is what I did.  this broke.  so I did this.  then this broke."
[08:33:31] <Dark_Shikari> not that complicated =p
[08:33:47] <cartman> :>
[08:33:59] * cartman goes to optimize zsh startup
[08:42:56] <lu_zero> Dark_Shikari: FF_BUFFER_TYPE_SHARED might help?
[08:43:08] <Dark_Shikari> what is SHARED?
[08:43:21] <Dark_Shikari> er, that won't work
[08:43:23] <Dark_Shikari> #define FF_BUFFER_TYPE_SHARED   4 ///< Buffer from somewhere else; don't deallocate image (data/base), all other tables are not shared.
[08:43:28] <Dark_Shikari> >all other tables are not shared
[08:45:05] <lu_zero> from the dealloc code it seems to do what you want
[08:45:18] <Dark_Shikari> No it doesn't
[08:45:22] <Dark_Shikari> it tries to free all the tables anyways
[08:45:55] <lu_zero> then you have to patch that
[08:46:06] * lu_zero is running and just had a random look
[08:46:30] <Dark_Shikari> I did it.  it doesn't work
[08:46:40] <lu_zero> brb
[08:47:14] <Dark_Shikari> Even if I comment out all the frees of those tables, it still crashes.
[08:47:34] <Dark_Shikari> Wait.  Spoke too soon.
[08:47:38] <Dark_Shikari> No it doesn't.
[08:48:14] <lu_zero> ^^
[08:48:29] <lu_zero> good thing, now plug the leak =)
[08:49:52] <KotH> lu_zero: ?
[09:00:50] <cartman> mru: you already fixed this but, anyhow http://qt.pastebin.com/GsekmjiQ
[09:06:55] <Tjoppen> woo. I just found a bug in the mpegts muxer, or ffmpeg
[09:07:20] <mru> the mpegts muxer is only bug
[09:07:25] <Tjoppen> heh
[09:07:39] <Tjoppen> when remuxing it doesn't interleave subtitle packets properly
[09:07:46] <Tjoppen> they all end up at the end of the file
[09:30:36] <lu_zero> KotH: the idea of buy .gr wholesale
[09:32:31] <kshishkov> lu_zero: well, its value with debts concerned should be low enough that even Turkey can afford that
[10:36:20] <cartman> "I know, unfortunately my only Android hardware is Archos5 Internet
[10:36:20] <cartman> Tablet and I'm still waiting for Android 2.0 update from ARCHOS :-("
[10:36:26] <cartman> _av500_: ^^^^ stop slacking
[10:37:02] <mru> +1
[10:44:18] <_av500_> cartman: says who?
[10:44:44] <cartman> _av500_: some Android developer, his name is safe with me
[10:44:45] <cartman> :p
[10:46:14] <_av500_> we dont give in to anonymous terrorists
[10:46:28] * mru terrorises _av500_ non-anonymously
[10:47:18] <cartman> _av500_: some Qt developer, porting his app to Android
[10:47:34] <cartman> _av500_: Qt port in its all infancy pre-alpha quality does not support Android < 2.1
[10:49:00] <kshishkov> so why should av500 care about some Qt with too high requirements?
[10:49:11] <cartman> high?
[10:49:12] <cartman> lol
[10:49:25] <cartman> high would be requiring Android 2.2
[10:49:27] <cartman> or 3.0 :P
[10:50:27] <kshishkov> well, at least you can start bugging av500 to move to Android 4.0 now, maybe you'll convince him to the time it's released
[10:51:20] <cartman> kshishkov: seriously, 2.1 is not a high requirement
[10:54:27] <kshishkov> cartman: I don't know and don't care. Qt is a high requirement. Too bad it didn't die young, the world would be better without it and KDE
[10:54:53] <cartman> kshishkov: won't you ever get tired of this hatred stuff?
[10:59:28] <thresh> Qt is awesome
[11:00:03] <cartman> kshishkov & others just have pure baseless hatred
[11:00:17] <thresh> haters gonna hate, right..
[11:00:22] <cartman> true
[11:01:30] <kshishkov> cartman: I've tried Qt programming, even in times it was still very nonfree
[11:02:00] <cartman> kshishkov: 1.x times
[11:02:45] <kshishkov> same for KDE - when starting single app starts a lot of nonrelevant Kstuff and dumps a lot of noise to console, I say it's substandard design at best
[11:03:00] <kshishkov> cartman: does Qt still use moc?
[11:03:07] <cartman> kshishkov: yes
[11:03:23] <cartman> kshishkov: no more #include "foo.moc" though
[11:03:50] <kshishkov> cartman: still, do you call this "baseless" hate?
[11:03:59] <cartman> kshishkov: yup :P
[11:04:01] <spaam> mru: http://uncrustify.sourceforge.net/ maybe you can use that on c++ so it will be beutiful ;)
[11:04:23] <cartman> kshishkov: if you want Qt/KDE to be as fast as bare assembly, not going to happen
[11:05:54] <kshishkov> cartman: I don't care about speed in that case. But using additional tools and being forced to use their own inventions for standard stuff sucks
[11:06:23] <cartman> kshishkov: the only invention would signal/slot concept
[11:06:27] <cartman> not a bad idea :)
[11:08:30] <kshishkov> read about Objective C for starters
[11:08:48] <cartman> better way for this stuff?
[11:09:22] <kshishkov> yes, since it's in the language and not in crutches
[11:09:58] <cartman> ok, thanks for the tip
[11:10:54] <kshishkov> it's primary Apple language if you didn't know
[11:11:01] <cartman> yes I know
[11:47:46] <Tjoppen> an update on my mpegts subtitle remuxing woes: the packets get as far as to the parsing stage
[11:48:29] <Tjoppen> the original video sometimes strips three bytes from them, while the remuxed one just never return anything
[11:52:29] <mru> spaam: I prefer using rm on c++
[11:58:20] <Tjoppen> hm. since it strips that header when parsing, wouldn't it have to be re-added be a bsf when before being re-muxed?
[11:58:28] <Tjoppen> *by
[12:04:49] <wbs> CDGS? :-)
[12:05:27] <mru> lol
[12:05:28] <kshishkov> reminds me of certain module guy
[12:07:04] <spaam> the awesome amiga group!
[12:08:13] <kierank> yup, with one member
[12:08:18] <kshishkov> how awesome? They've ported FFmpeg to 68k?
[12:08:33] <kshishkov> kierank: you?
[12:08:45] <kierank> no, basty
[12:09:14] <mru> let's port everything to foocomposer
[12:09:33] <lu_zero> brrr...
[12:09:46] <Kovensky> <Dark_Shikari> http://pastebin.ca/1946114 <Dark_Shikari> this is a single symbol from a real application. <Dark_Shikari> 36 kilobytes
[12:09:49] <mru> start with the kernel and libc
[12:09:54] <kshishkov> and let's represent all video as MPEG-4 textures!
[12:10:02] <mru> Kovensky: yes, I posted it
[12:10:07] <mruCDGS> ok lets go
[12:10:12] <Kovensky> oh really
[12:10:13] <Kovensky> :D
[12:10:27] * Kovensky is just spreading C++ "love"
[12:11:07] * kshishkov thinks that the fact C++ creator was Danish should explain it all
[12:11:25] <mru> there are good danes too
[12:11:40] <mru> like kurt westergaard
[12:11:41] <spaam> yeah.. carlsberg ;D
[12:11:42] <kshishkov> yes, there are exceptions
[12:11:43] <Kovensky> weren't the vikings called "danes" in old english
[12:11:58] <mru> many danes were vikings
[12:12:02] <mru> and vice versa
[12:12:05] <kshishkov> Kovensky: only because England got Danish Vikings mostly
[12:13:05] * Kovensky should resume reading Vinland Saga
[12:13:11] <Tjoppen> I wonder what that symbol would look like in mangled form :>
[12:13:25] <kshishkov> and good Ukrainian rulers were Swedish Vikings, then they started to get closer to natives and it all went downhill
[12:14:01] <Kovensky> how is the "vi" from viking pronounced btw
[12:14:21] <kshishkov> as plural "jag"
[12:14:23] <mru> depends on what language you're speaking
[12:14:33] <Kovensky> well, english ._.
[12:14:41] <mru> there were no english vikings
[12:16:24] <Kovensky> =p
[12:16:33] <lu_zero> viking translates to something like sailor in the native language?
[12:16:35] * kshishkov hastily writes a saga about Vikings from icy cliffs of Portugal
[12:17:28] <Kovensky> lol
[12:17:32] <lu_zero> kshishkov: please, daylight glittering vampires are enough
[12:19:10] <kierank> lu_zero: twilight?
[12:19:21] * kshishkov scribbles notes for epic saga about Italian Empire in XVIIth century, all 20 of them
[12:19:31] <lu_zero> 20?
[12:20:24] <kshishkov> lu_zero: dunno exacty number. But IIRC in 17th century Italia was as united state as Germany
[12:20:34] <kshishkov> *exact
[12:21:37] <lu_zero> Italia was a geographic concept
[12:23:22] <kshishkov> but you had Italian state back then - every Italian city had its own IIRC
[12:27:45] <lu_zero> every city was a state
[12:27:52] <lu_zero> (more or less)
[12:27:58] <lu_zero> (still is)
[12:29:16] <kshishkov> so you live in mighty Fiatia?
[12:29:19] <BBB> Dark_Shikari: re: michael's reply, so do I misunderstand why red zone + call in inline asm is a problem?
[12:29:27] <BBB> Dark_Shikari: can you enlighten me?
[12:29:47] <mru> he's talking about how he thinks things should be
[12:29:52] <mru> not about how they actually are
[12:29:54] <mru> as usual
[12:30:56] <BBB> I had that impression also, I mean of course inline asm can just take redzone off esp before every call, but that's silly, wasteful and stupid
[12:31:03] <BBB> plus it takes cycles :p
[12:31:29] <mru> and that asm won't be able to take memory arguments on the stack
[12:32:33] <mru> or waste time adjusting sp around every call
[12:34:00] <iive> i was thinking that the problem with calling function from asm is in the fact that each architecture have its own calling convention.
[12:34:41] <mru> each arch has its own asm too
[12:35:29] <lu_zero> and each abi might change that as well...
[12:35:37] <iive> there is specific linux, windows and macosx assembly?
[12:35:55] <mru> those are operating systems
[12:36:31] <iive> and you are talking about processors.
[12:37:27] <BBB> x86-64 and x86-32 have different call convention, yes
[12:37:38] <BBB> so calling functions in general is a little problematic
[12:37:44] <BBB> but it can be done
[12:38:14] <BBB> (don't forget that for non-external functions, we can use any call convention, see various examples in the h264dsp asm)
[12:38:35] <BBB> (and you can abuse that to speed it up greatly by making assumptions that don't always hold for external functions)
[12:41:59] <kshishkov> BBB: what about different calling conventions in Win32 itself?
[12:42:31] <kshishkov> luckily, they're mostly for system stuff and we don't care but still...
[12:57:14] <cartman> is there a way / compiler option to make http://paste2.org/p/998565 fail?
[12:58:26] <mru> what are you trying to do?
[12:59:06] <kshishkov> cartman: -Dsigned=unsigned of course
[12:59:21] <cartman> mru: trying to reproduce a clang error
[12:59:29] <cartman> its in python ctypes test
[12:59:48] <mru> what is it you'd like to have fail?
[12:59:53] <cartman> ctypes claim clang return 43 here
[13:00:15] <cartman> tf_b(-126) returning something !-42
[13:00:15] <cartman> :)
[13:00:19] <cartman> 43 would be nice ;)
[13:00:32] <mru> 126/3 is 42
[13:00:41] <cartman> just trying to find out how the hell it would return 43
[13:00:41] <mru> when rounding towards zero
[13:00:49] <mru> -43?
[13:00:54] <cartman> nope positive 43
[13:01:00] <kshishkov> cartman: it treats input as unsigned char then
[13:01:09] <kshishkov> -126 = 130, 130/3 = 43
[13:01:17] <cartman> kshishkov: aha
[13:01:28] <cartman> kshishkov: but clang -O3 test.c doesn't exhibit the problem
[13:01:32] <cartman> might be some flag some define
[13:01:34] * kshishkov mourns another failed joke
[13:01:44] <mru> 54!
[13:02:06] <kshishkov> try the flag I typed above, it should work
[13:02:16] <cartman> kshishkov: right...
[13:44:13] <BBB> kshishkov: re: what you said an hour ago, if that ever becomes something we intend to do, we probably should kill ourselves... that's not what simd is for ;)
[13:51:30] <kshishkov> BBB: okay
[14:03:00] <Tjoppen> I finally figured out exactly why my subtitles weren't working. two things:
[14:03:04] <superdump> mru: another amr-wb mail with patch has been moderated on -devel
[14:03:13] <superdump> if you could allow it, that'd be sweet
[14:03:21] <Tjoppen> the mpegts muxer doesn't "undo" what the parser does (basically adding a zero byte)
[14:03:31] <superdump> BBB: marcelo doesn't come on irc
[14:03:36] <Tjoppen> and the extradata somehow ends up wrong
[14:03:45] <mru> superdump: he should
[14:05:04] <superdump> speak of the devil
[14:05:07] <superdump> ahoy mars____
[14:12:24] <superdump> mars____: say something! :)
[14:12:36] <mars____> hello all! :)
[14:12:41] <superdump> there we go
[14:13:13] <lu_zero> Tjoppen: how wrong?
[14:13:26] <kshishkov> superdump: traditional words are "Polly wants a cracker" though
[14:13:33] <Tjoppen> composition_id and ancillary_id are 1 instead of 2
[14:13:44] <lu_zero> btw who knows quite a lot of subtitles in ffmpeg?
[14:13:51] <Tjoppen> or: data is 00010001 instad of 00020002
[14:13:58] * lu_zero wants to get rtp-ass done sooner or later =P
[14:14:10] <Tjoppen> so I kind of wonder what code changes the extradata and why
[14:14:22] <BBB> superdump: devil indeed ;)
[14:14:38] <Tjoppen> and also whether I should have the dvbsub parser idempotent or not
[14:14:51] <Tjoppen> atm it can't parse parsed input
[14:15:34] <Tjoppen> the fix is simple: instead of requiring the packet to begin 20000F, also allow it to begin just 200F
[14:16:02] <mars____> mru: hey, I have a patch sent to ffmpeg-devel that needs approval
[14:16:12] <mars____> mru: because of the message size
[14:16:25] <mru> mars____: so I heard
[14:16:45] <mars____> mru: can you work it out for me?
[14:17:04] <mru> why are these patches so huge anyway?
[14:17:07] <mru> lots of tables?
[14:17:29] <mars____> mru: yes, and because its my whole gsoc project in one big patch :)
[14:17:36] <lu_zero> ouch
[14:17:45] <lu_zero> one patch or a patchset?
[14:17:48] <mru> maybe you could drop the tables from the mails
[14:17:59] <mru> lu_zero: it's one decoder
[14:18:06] <mars____> mru: since it was reviewed late, I gathered the code in one piece
[14:18:09] <mru> not much sense in splitting it
[14:18:52] <Tjoppen> wait a minute.. I can't just fix the parser since I'm required to make the output work in vlc as well
[14:19:18] <mars____> mru: hmm, I may remove the header file with the tables from the patch then
[14:19:19] <Tjoppen> bitstream filter seems like a decent choice then
[14:19:59] <mars____> mru: but others would have to analyze it separately, if necessary
[14:20:40] <mru> I doubt anyone is going to analyse hundreds of kB of tables carefully
[14:22:59] <mars____> the header file doesn't contain only the tables.. but i guess it is less important, in fact
[14:23:39] <mru> you might want to move the tables to a file of their own
[14:24:17] <mars____> i will consider that too
[14:24:38] <mars____> i will send another patch soon, thanks
[14:31:14] <Tjoppen> aha! the extradata thing is of course the muxer's fault. it always writes 00010001
[14:31:40] <kierank> this thread is going to attract all the audiophiles: http://forum.doom9.org/showthread.php?p=1445266
[14:34:14] <mru> lol
[14:34:58] <mru> always amusing to watch the blind leading the blind
[14:35:39] <_av500_> ...and through a minefield
[14:36:43] <Tjoppen> there. a three-line fix in the mpegts muxer
[14:41:00] <Tjoppen> now I just need to add a single 0x00 byte to the subtitle packets :o
[14:44:22] <Compn> simple ehehe
[14:44:35] <Compn> is anything related to mpegts simple ?
[14:44:51] <mru> demuxing is fairly simple
[14:45:22] <kierank> except for abominations like latm and 302m
[14:47:50] <Compn> hmm, someone was asking about uncommenting that latm aac audio stream check
[14:47:54] <Compn> but now i forgot where
[14:48:09] <mru> kierank: by mpegts I mean iso 13818-1
[14:48:17] <mru> neither latm nor 302m are defined there
[14:48:40] <kierank> thankfully
[14:49:04] <Tjoppen> mpegts looks fairly straightforward. try mxf
[14:49:19] <Compn> .  //{ 0x11, AVMEDIA_TYPE_AUDIO,        CODEC_ID_AAC }, /* LATM syntax */
[14:49:30] <kierank> lol mxf
[14:49:54] <Compn> line 500 mpegts.c
[14:50:05] <mru> Compn: mpegts defines IDs for payload types specified elsewhere
[14:50:14] <Compn> ok then
[14:50:15] <mru> extracting the payload from the ts is easy
[14:50:42] <kierank> ts is no ogg
[14:50:42] <Tjoppen> I don't think there's a player that can handle anything above op2b for mxfd
[14:50:45] <Tjoppen> -d
[18:18:34] <Naikrovek> is there a method in the ffmpeg api that can take two video streams, and merge them into a single stream with the two original streams side by side?
[18:27:33] <bcoudurier> hi guys
[18:28:27] <Naikrovek> hi
[20:59:29] <kierank> lol BBB: "we can create our own bar-party" --> that's going to be one heck of a party
[20:59:33] <kierank> new york watch out...
[20:59:39] <kierank> ffmpeg devs are in town
[21:07:00] <BBB> kierank: so you will come?
[21:10:54] <kierank> no
[21:11:05] <kierank> too far
[21:15:49] <j0sh> if didn't graduate in may, i would be there :)
[21:16:28] <kierank> get them to have it in london next time ;)
[21:17:00] <spaam> at your place?
[21:17:04] <kierank> yeah ok
[21:17:11] <kierank> plenty of beer
[21:17:15] <spaam> nice
[21:17:35] <kierank> you can have the cheap belgian crap spaam
[21:17:47] <spaam> no thanks
[21:17:58] <spaam> better with carlsberg export : )
[21:18:15] <spaam> hmm.. maybe go and buy some of that tomorrow :D
[21:20:58] <kierank> i haven't seen carlsberg at the pub for ages
[21:24:09] <spaam> ok :)
[21:24:51] <kierank> there are loads of different bitters though
[21:25:46] <spaam> try and find out then :)