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

[irc at mansr.com]

[00:19:38] <iive> hum this change sounds .. fast.
[00:23:34] <CIA-92> ffmpeg: aurel * r22125 /trunk/libavcodec/h264.c: revert r22112 which broke playback of cathedral-beta2-400extra-crop-avc.mp4
[00:26:30] <drv> heh, that sample plays totally wrong in win7 media player
[02:22:58] <pentanol> hi anybody alive here?
[02:24:27] <mfg> yes, but I dont count.
[02:24:30] <pentanol> in sample avformat app I've seen fill_yuv_image() that do pictide on a screen? or where it output a stream?
[02:26:18] <pentanol> also I've seen AVInputStream\AVOutputStream in ffmpeg.c source, but there function used in more low level obstraction..
[02:27:37] <pentanol> in output-example.c it looks lire read a file and then output, but don't even undertand where...
[02:27:49] <pentanol> where that do output a stream?
[07:23:49] <CIA-92> ffmpeg: benoit * r22126 /trunk/ffmpeg.c:
[07:23:49] <CIA-92> ffmpeg: ffmpeg: copy stream metadata.
[07:23:49] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskasgmailcom
[07:27:35] <CIA-92> ffmpeg: benoit * r22127 /trunk/libavformat/nutdec.c:
[07:27:35] <CIA-92> ffmpeg: nutdec: make chapter start and length uint64_t to prevent overflows.
[07:27:35] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas chez gmail punto com
[09:16:09] <siretart> god morgon
[09:17:44] <DonDiego> what language was that?
[09:17:51] <thresh> moroning
[09:18:07] <DonDiego> who are you calling a moron?
[09:18:08] <DonDiego> ;)
[09:19:09] <siretart> heh
[09:19:47] <kshishkov> DonDiego: varför vet du inte svenska?
[09:20:08] <DonDiego> ja nje gavariu po ruski
[09:20:30] <kshishkov> but I was asking about Swedish, so that's not a reason
[09:21:26] <kshishkov> FYI all of Swedish-British section of FFmpeg devs know what does "god morgon" mean
[09:21:45] <thresh> even I do
[09:21:57] <twnqx> i guess the german section can guess >_>
[09:24:30] <kshishkov> I think it's the same story as with Russian language - while other languages from the same family evolved (and became a bit simpler), German/Russian remains the same beast and its speakers hardly can understand any other language
[09:24:52] <kshishkov> (while others can understand each other quite well)
[09:25:25] <elenril> dobré ráno?
[09:25:50] <kshishkov> in Ukrainian that would be "dobriy ranok"
[09:25:59] <twnqx> nah, i think dutch and swedish are borderline understandable
[09:27:37] <kshishkov> try Danish then
[09:27:44] <elenril> kshishkov: yeah, languages are like codecs
[09:28:11] <twnqx> danish as well
[09:28:17] <twnqx> when reading, at least
[09:28:33] <twnqx> but needs context
[09:29:06] <kshishkov> elenril: yeah, ineffective and mostly incomprehensible as well
[09:30:48] * elenril thinks russian would correspond to mpeg4
[09:31:01] <kshishkov> msmpeg4
[09:31:17] <elenril> meh, that would be one of its ripoffs
[09:31:27] <elenril> like ukrainian ;)
[09:31:28] * elenril runs
[09:32:41] * kshishkov reminds elenril that in times of Kievan Rus the place where certain city stands was called "Moscow Ukraine"
[09:33:26] * elenril knows, hence the ;)
[09:35:57] * elenril sighs
[09:36:12] <elenril> michael wants me to write nice, general and extensible things again
[09:36:26] <kshishkov> and that's against your nature?
[09:36:29] <elenril> and i was so looking forward to just hacking it together somehow
[09:36:32] <elenril> yeah, exactly
[09:44:07] <mister_electroni> hola alguten ahi
[09:44:32] <mister_electroni> hello
[09:44:43] <kshishkov> that's better
[09:44:57] <kshishkov> (unless you want to talk to DonDiego only)
[09:45:19] <mister_electroni> No I like talk with everybody...
[09:45:38] <mister_electroni> My english is no so good....
[09:47:04] <mister_electroni> I am looking to capture video with ffmpeg.
[09:47:30] <mister_electroni> but still I don't know how to do...
[09:47:54] <mister_electroni> someone help me?
[09:48:11] <DonDiego> mister_electroni: ask in #ffmpeg
[09:48:33] <mister_electroni> ok thanks and sorry....
[10:09:05] <pentanol> where output-example.c source output a stream? it looks like read audio and video from a file and then...
[11:10:30] <siretart`> DonDiego: what's the status on 0.5.1?
[11:11:32] <DonDiego> i'm on the phone right now
[11:11:39] <DonDiego> let's do it in a few minute
[11:11:39] <DonDiego> s
[11:11:48] <siretart`> sure
[11:12:37] <bilboed-pi> is 0.5.1 the same as 0.5.0 with only security fixes ?
[11:12:44] <kshishkov> yes
[11:12:58] <merbzt> and updated x264 interface
[11:14:23] <merbzt> Vitor1001: we need to update the news on the homepage
[11:14:46] <Vitor1001> merbzt: I agree. I think AMR deserves a mention.
[11:14:47] <kshishkov> yes, AMR-NB decoder is worth mentioning
[11:14:48] <DonDiego> bilboed-pi: and a few porting/packaging/license upgrades :9
[11:15:08] <merbzt> not indeo5 ?
[11:15:11] <DonDiego> Vitor1001: then go for it right away before we make the release
[11:15:18] <DonDiego> mention both
[11:15:18] <merbzt> we have looots of news
[11:15:34] <Vitor1001> I'm at work now, someone else volunteers?
[11:15:42] <kshishkov> merbzt: it's useless as Bink
[11:16:03] <Vitor1001> Bink also deserves a mention, like wmavoice
[11:16:06] <merbzt> kshishkov: :)
[11:16:12] <Vitor1001> and indeo
[11:16:25] <Vitor1001> and sipr
[11:16:43] <DonDiego> would someone please step forward and write a news update for all the new stuff?
[11:16:46] <merbzt> and rtp work
[11:16:48] <siretart`> bilboed-pi: kshishkov: and added symbol versioning!
[11:16:51] <Vitor1001> But we'll have to do it again once we have HE-AAc ;)
[11:17:08] <merbzt> and GSoC
[11:17:17] <kshishkov> someone should RE Indeo Audio to close Intel stack of codecs along with the ones from Buffering Inc.
[11:17:42] <siretart`> oh, and 0.5.1 comes with an LGPL'ed libswscale
[11:17:55] <bilboed-pi> siretart, libswscale is finally entirely LGPL'ed ?
[11:18:08] <siretart`> that's not what I said
[11:18:09] <merbzt> C version
[11:18:10] <kshishkov> bilboed-pi: it's usable
[11:18:22] <bilboed-pi> oh ok, so it's still dogslow in LGPL
[11:18:37] <kshishkov> 0.5.0 stuck with imgconvert which was even slower I think
[11:19:52] <siretart`> DonDiego: and we should make it clear that 0.5.1 will be the only upgrade path to 0.6 for users that don't want or cannot recompile applications
[11:20:09] <DonDiego> what do you mean by "only upgrade path"?
[11:20:33] <kshishkov> no future 0.5.x releases
[11:20:34] <DonDiego> and hold off, i'm writing the news entry while you guys keep up the random chatter
[11:20:43] <siretart`> if you replace libavcodec52 from 0.5 with libavcodec52 from 0.6, the applications will randomly crash
[11:20:48] <siretart`> this won't happen with 0.5.1
[11:26:56] <DonDiego> i will commit the following now:
[11:27:00] <DonDiego> "We have been busy over the past few months. The results are new decoders for Indeo 5 and Bink video as well as AMR-NB, Sipr, Bink, MPEG-4 ALS and WMA Voice audio, an RTSP muxer, Bluray (PGS) subtitle support and the ffprobe tool for extracting information from multimedia files."
[11:27:05] <DonDiego> anything missing?
[11:27:19] <kshishkov> Sipro
[11:27:27] <kshishkov> not Sipr
[11:27:41] <kshishkov> also mention Bink only once
[11:28:14] <kshishkov> also you have Changelog
[11:28:51] <iive> kshishkov: is there bink audio?
[11:29:08] <kshishkov> iive: yes, two of them
[11:29:40] <iive> that's why bink appears twice, once for video and twice for audio.
[11:30:01] <kshishkov> should be thrice then
[11:30:30] <kshishkov> still, ILBM, CDG and concat protocol are worth mentioning, especially the latter
[11:31:13] <iive> is aac sbr is svn already?
[11:31:21] <DonDiego> no
[11:32:06] <DonDiego> what is the concat protocol?
[11:32:22] <DonDiego> finally ffmpeg can concatenate files?
[11:32:34] <kshishkov> probably yes, never tried though
[11:33:41] <pentanol> hello,  could some one point me?  there this snuppet output-example.c output a stream? on a screen?
[11:34:13] <kshishkov> no, we have ffplay.c for outputting streams on a screen
[11:34:24] <pentanol> I see
[11:34:50] <pentanol> but where those snippet output it?
[11:35:07] <pentanol> input liiks like from a file
[11:35:12] <pentanol> looks*
[11:35:39] <DonDiego> kshishkov: what is CDG and ILBM
[11:35:40] <DonDiego> ?
[11:36:02] <kshishkov> CD+g video format for karaoke mostly
[11:36:32] <kshishkov> and if you don't know about image format ILBM then you had no Amiga nor even heard of Deluxe Paint
[11:38:31] <DonDiego> k, how about
[11:38:34] <DonDiego> "We have been busy over the past few months. Among other things, the
[11:38:35] <DonDiego> results are an Indeo 5 video decoder as well as audio decoders for
[11:38:35] <DonDiego> AMR-NB, Sipro, MPEG-4 ALS and WMA Voice, complete support for Bink,
[11:38:35] <DonDiego> CDG and IFF PBM/ILBM bitmaps, an RTSP muxer, Bluray (PGS) subtitle
[11:38:35] <DonDiego> support, a protocol for file concatenation and the ffprobe tool for
[11:38:36] <DonDiego> extracting information from multimedia files."
[11:40:01] <kshishkov> Some of us were busy, others were lazy.
[11:40:48] <pentanol> hm, no one knows where output-example.c output a stream?
[11:40:49] <kshishkov> and IIRC ffprobe was picked from some project at sourceforge
[11:41:19] <pentanol> actually I need just encode\decode sample, this one quite well
[11:41:41] <pentanol> but I still can't get it working
[11:47:42] <pentanol> or there input and output in the same file?
[11:58:53] <DonDiego> kshishkov: i think stefano is the author of ffprobe, dunno why he hosted it on sf
[11:59:24] <DonDiego> anyway, committed
[11:59:29] <kshishkov> good
[12:18:44] <j-b> ruggles?
[12:20:35] <kshishkov> unlikely
[12:21:24] <KotH> pentanol: you are asking a user question in the development channel
[12:21:29] <KotH> pentanol: please use #ffmpeg instead
[12:21:57] <pentanol> but ther nobody knows it
[12:22:08] <KotH> that is no excuse to ask here
[12:22:24] <KotH> there is a reason why there is a strict seperation between user and developer channel
[12:22:33] <kierank> it's like church and state
[12:22:58] <KotH> (ie that the developers can discuss stuff w/o reading tons of irrelevant user questions that could be answered by reading the documentation or the code)
[12:23:26] <siretart`> kierank:  and which of the two are the developers? ;-)
[12:23:34] <pentanol> it's not documenter
[12:23:41] <pentanol> documented*
[12:24:44] <kshishkov> kierank: guess who is the both head of Church of England and Queen of Commonwealth states though?
[12:25:29] <DonDiego> pentanol: your question remains offtopic, sorry
[12:28:33] <merbzt> pentanol: ask on the libav list
[13:09:49] <KotH> could someone enlighten me a bit on shell expansion? i cannot find a solution in the docs
[13:10:15] <KotH> i have a variable A='a b c "d e" f', which i pass to function
[13:10:29] <KotH> there it gets asigned to B=$1
[13:10:52] <KotH> set +x tells, me that the assignemt is executed as B='a b c "d e" f'
[13:11:18] <KotH> now i use B as a parameter to a command: blah $B
[13:11:38] <KotH> but here the parametes get split as 'a' 'b' 'c' '"d' 'e"' 'f'
[13:11:55] <kshishkov> try passing "$B" then
[13:12:18] <KotH> already tried, then it gets passed as 'a b c "d e" f'
[13:12:31] <KotH> instead of 'a' 'b' 'c' '"d e"' 'f'
[13:14:46] <DonDiego> tricky stuff, experiment with IFS
[13:15:29] <kshishkov> or use 'a b c d\te f' and substitute tab later if possible
[13:16:55] <KotH> DonDiego: tried, doesnt work
[13:17:08] <KotH> kshishkov: this approach has the same problem
[13:18:17] <siretart`> KotH: can't you pass A='a b c d\ e f' to your function?
[13:18:34] <KotH> siretart`: suffers from the same problem too
[13:18:48] * KotH tried all the obvious ways already ^^'
[13:19:02] <siretart`> and how about "a b c 'd e' f"? ;-)
[13:20:41] <KotH> siretart`: same
[13:20:50] <siretart`> ditch shell then ;-)
[13:21:18] * KotH doesnt want to ^^'
[13:21:32] <KotH> all the rest works just fine, it's just this little issue ^^'
[13:22:04] * elenril would rewrite it in python
[13:24:06] <siretart`> DonDiego: anything I can help you with regarding 0.5.1?
[13:24:44] <DonDiego> remind me what still needs doing :)
[13:24:59] <DonDiego> let me finish the news entry..
[13:28:18] <siretart`> do we want to amend the file RELEASE with changes in 0.5.1?
[13:28:53] <DonDiego> yes, why not..
[14:12:00] <DonDiego> siretart`: what exactly did you want to add to the RELEASE file?
[14:12:26] <siretart`> I pasted the diff yesterday, wait, I can repeat
[14:13:19] <DonDiego> ah, found it, sorry
[14:13:58] <siretart`> DonDiego:  http://paste.debian.net/61975
[14:22:33] <DonDiego> hmm
[14:22:47] <DonDiego> i feel we have a certain amount of duplication
[14:23:01] <DonDiego> no scratch that, not really
[14:23:15] <DonDiego> but there should be a bit more in the release notes
[14:23:22] <DonDiego> license upgrade fixes
[14:23:39] <DonDiego> not only upgrade, licensing-related in general
[14:24:04] <DonDiego> also
[14:24:19] <DonDiego> use "H.264" and "MLP"
[14:31:24] <CIA-92> ffmpeg: diego * r22128 /trunk/doc/general.texi:
[14:31:24] <CIA-92> ffmpeg: Fix AMR-NB entry in the supported audio codecs list.
[14:31:24] <CIA-92> ffmpeg: The decoding and encoding rows were switched around.
[14:36:35] <siretart`> DonDiego: the release notes are maintained where exactly? I thought the RELEASE file were the release notes...
[14:42:17] <DonDiego> http://www1.mplayerhq.hu/~diego/index.html
[14:42:25] <DonDiego> they are
[14:47:12] <DonDiego> oh, i forgot the libx264 wrapper..
[14:48:18] <siretart`> and that symbol versioning is enabled now!
[14:49:35] <DonDiego> that i mentioned..
[14:52:44] <siretart`> hm. "to help packagers" is a bit vague, we should make clear that distributors really should upgrade to 0.5.1 and rebuild their binaries as preparation step for 0.6
[14:53:19] <siretart`> applications that miss this step will cause horrible problems otherwise
[14:54:08] <DonDiego> suggest a wording :)
[14:54:59] <kshishkov> "merely for preserving ABI compatibility"
[14:57:02] <siretart`> kshishkov: we are effectively changing ABI
[14:57:11] <siretart`> so preserving is not exactly correct
[14:57:16] <siretart`> how about this wording:
[14:57:34] <siretart`> The backported symbol versioning change is enabled on platforms that support
[14:57:34] <siretart`> it. This allows users to upgrade from 0.5.1 to the upcoming 0.6 release
[14:57:34] <siretart`> without having to recompile their applications. Please note that distributors
[14:57:35] <siretart`> have to recompile applications against 0.5.1 before upgrading to 0.6!
[15:04:11] <DonDiego> ok, reload
[15:07:15] <DonDiego> should be fine now
[15:09:01] <DonDiego> anything left?
[15:09:15] <DonDiego> i want to add us both as release managers to the MAINTAINERS file
[15:09:22] <DonDiego> that's about it i think
[15:09:39] <DonDiego> siretart`: will you commit that RELEASE file change?
[15:10:11] <DonDiego> i need to run out for a moment to go shopping
[15:10:26] <DonDiego> i'll be back in no more than an hour
[15:26:50] * BBB hates xchat
[15:26:57] <BBB> so if you have a tab completion, and want it to complete
[15:26:59] <BBB> it turns yellow
[15:27:04] <BBB> how do I make it actually complete?
[15:27:18] <twnqx> Oo
[15:27:20] <kshishkov> press it again?
[15:27:30] <twnqx> it turns yellow?
[15:27:36] <twnqx> never seen that happen
[15:30:08] <KotH> you sure your xchat doesnt have hepatitis?
[15:37:54] <BBB> kshishkov, I tried, then it actually inserts a tab (\t)
[15:38:52] <kshishkov> BBB: Kahn axiom - if nothing helps, it's time to read that manual ;)
[15:41:12] <mru> BBB: why don't you a proper irc client instead?
[15:42:25] <BBB> I'm lazy and disinterested
[15:42:39] <BBB> I think mac people don't use irc
[15:42:46] <BBB> otherwise I'm sure there'd be something better than this
[15:42:57] <mru> don't be a mac person then
[15:43:17] <mru> doesn't irssi work on mac?
[15:43:28] <Honoome_> there's macirssi
[15:43:28] * kshishkov has used both XChat-aqua and Colloquy there, now stuck with irssi running in remote screen
[15:43:51] <kshishkov> (never used autocompletion, so no problem here ;)
[15:51:53] <BBB> can someone look at the audio clipping patch on the mailinglist?
[15:52:12] <BBB> it's quite a nasty bug which causes some artifacts in decoding of wmavoice files (and possibly others)
[16:13:24] <mru> BBB: fix the whole audioconvert madness instead
[16:13:48] <kshishkov> s/fix/replace with something sane/
[16:15:23] <BBB> what do you have in mind?
[16:15:32] <BBB> I doubt I would be able to come up with something that's better, honestly
[16:15:41] <mru> something using simd
[16:15:43] <kshishkov> liswscaler for audio
[16:15:43] <BBB> although I'd write pix_fmt-style convert tables instead of this
[16:15:51] <BBB> and then make each impl simd'able
[16:16:01] <BBB> right, swscale for audio
[16:16:05] <BBB> but that's a full soc project
[16:16:08] <BBB> so no go right now
[16:16:25] <kshishkov> you know, something to convert 5.1 48kHz to 2 ch 44.1 kHz without hassle
[16:16:37] <BBB> kshishkov, go, go, go!
[16:16:39] <BBB> I see a soc project
[16:17:08] <kshishkov> okay, wiki awaits you
[16:18:00] <BBB> who will mentor it?
[16:18:27] <kshishkov> maybe Benajmin or Andreas
[16:18:32] <kshishkov> *Benjamin
[16:18:57] <kshishkov> or anybody who knows a thing about multichannel codecs
[16:19:13] <kshishkov> and filters
[16:19:15] <mru> BBB: does the wmavoice decoder output full -1.0--1.0 inclusive range?
[16:19:34] <prupert> I think the #ffmpeg was the wrong place to ask this, so I am asking here: I have read that there are plans to add support for the Broadcom Crystal HD Hardware Decoder (BCM970012) to ffmpeg. Does anyone know if this will be purely for playback or are there plans to use it for transcoding to (so offloading some of the load from the CPU to the Decoder)?
[16:20:28] <BBB> mru: yes
[16:20:31] <janneg> prupert: playback is in the case of the crystal hd the same as decoding
[16:20:38] <mru> BBB: that's your problem then
[16:20:55] <BBB> mru: that's a feature, not a bug
[16:21:04] <mru> can you make it output [-1.0, 1.0) in hideous maths notation?
[16:21:25] <mru> or scale it by (1<<N)-1 instead
[16:22:06] <mru> either of those is preferable
[16:22:19] <BBB> [-1.0; 1.0) no
[16:22:22] <mru> your patch still has clipping
[16:22:23] <BBB> 1<<n-1: yes
[16:22:36] <siretart`> DonDiego: done
[16:22:37] <BBB> (1<<n)-1, I mean
[16:22:41] <BBB> but that's not really right
[16:22:53] <prupert> janneg: so, once support is added, it would make transcoding using fmpeg on the Intel Atom platform faster (or at the very least, less processor intensive)?
[16:23:01] <BBB> mru: which do you prefer?
[16:23:03] <mru> BBB: no, but it's better than clipping
[16:23:06] <BBB> agreed
[16:23:14] <janneg> prupert: yes
[16:23:15] <BBB> the decoder internally clips overflows to 1.0 already
[16:23:15] <CIA-92> ffmpeg: siretart * r22129 /branches/0.5/RELEASE: amend release notes for 0.5.1
[16:23:27] <BBB> so... it's not like we're clipping any less then
[16:23:32] <BBB> the binary also clips
[16:23:33] <prupert> awesome, thats great news, Imma off to eBay ;) thanks loads janneg
[16:27:09] <BBB> mru: could you send some msgs to the mailinglist so we can discuss if others prefer the (1<<n)-1 over av_clip* use?
[16:27:56] <kshishkov> BBB: due to filter nature you'd still have to use clipping I fear
[16:28:40] <BBB> probably
[16:28:46] <BBB> I didn't want to get into that discussion though
[16:28:49] <BBB> my bug is simple
[16:28:57] <BBB> 1.0*1<<n = 0x8000
[16:28:59] <BBB> which is -0x8000
[16:29:08] <mru> it's actually undefined
[16:29:22] <mru> on some CPUs you get 0x7fff
[16:29:27] <BBB> well, yeah
[16:29:33] <BBB> but it happens to come down to 0x8000 here
[16:29:36] <BBB> (as an int32)
[16:29:43] <BBB> which clipped to int16 = -0x8000
[16:29:57] <BBB> that's my bug, I want that bug fixed
[16:30:05] <BBB> I don't care much about the other filter-related bugs, yet
[16:30:08] <BBB> that'll come later
[16:30:13] <kshishkov> BBB: you probably won't encounter CPUs mru talked about in real life anymore
[16:30:25] * mru looks at mips
[16:30:44] <kshishkov> IIRC old Crays used 1-complement arithmetic but I saw one only in Technical Museum, Stockholm
[16:30:52] <mru> that's not what I'm talking about
[16:31:20] <mru> such a machine wouldn't have a problem at all
[16:31:45] <kshishkov> it will have different problems though
[16:31:46] <mru> the problem here is that the integer range is not symmetrical around zero
[16:31:56] <kshishkov> you talked about overflow/saturation
[16:32:08] <mru> converting 1.0*1<<31 to int is undefined
[16:32:17] <mru> some CPUs wrap, some saturate
[16:32:27] <mru> converting 1.0*1<<15 to int is always defined
[16:32:57] <kshishkov> hmm, on 16-bit CPUs too?
[16:33:22] <mru> they don't exist as far as we're concerned
[16:33:36] <mru> nor do they have an FPU
[16:33:43] <kshishkov> so no FFmpeg for my modem?
[16:33:49] <BBB> ok, let's focus guys
[16:33:55] <BBB> bug!!1122
[16:34:08] <mru> converting 1<<15 to int16_t is implementation-defined
[16:34:27] <kshishkov> BBB: it's whole arithmetic is buggy. I'd suggest simply clipping result
[16:34:27] <mru> meaning you can get anything, but the compiler has to document what happens
[16:34:35] <BBB> kshishkov, my patch does that
[16:34:39] <mru> slowly
[16:48:37] <CIA-92> ffmpeg: cehoyos * r22130 /trunk/ffmpeg.c:
[16:48:38] <CIA-92> ffmpeg: Don't let output pixel format influence input pixel format.
[16:48:38] <CIA-92> ffmpeg: Patch by Chris Stones, chris D stones A gmail
[16:53:23] <CIA-92> ffmpeg: cehoyos * r22131 /trunk/libavcodec/h263dec.c: Process packed bitstream also for VDPAU.
[17:02:04] <gthreepwood> Hi all. I'm a computer science student currently doing a masters project on block matching algorithms. I want to create a varient of the MPEG-4 codec for testing purposes. I think ffmpeg is a great place to start and want to jump into the code right away. Does anyone have any tips on getting started? http://wiki.multimedia.cx/index.php?title=FFmpeg_codec_howto seems like a good starting point.
[17:03:33] <BBB> gthreepwood, what do you want to do?
[17:03:47] <BBB> if you want to modify the mpeg4 encoder/decoder, I'd suggest looking there
[17:05:05] <gthreepwood> Okay, I'll have a look at that code. What do you think the easiest way will be for me to test the changes I make? Compile mplayer/mencoder against the modified libavcodec?
[17:05:26] <jai> ffmpeg/ffplay
[17:06:46] <siretart`> maybe ffprobe as well
[17:08:56] <gthreepwood> I see, thanks. My changes will alter the structure of the encoded bitstream, does that complicate things or, as long as I modify both the encoder and decorder to support this change, will it be fine?
[17:09:05] <jai> yes
[17:10:38] <gthreepwood> Sorry, could you clarify your answer?
[17:11:07] <BBB> he means it'll be fine
[17:11:18] <BBB> mru: is float: inf/inf defined?
[17:11:30] <BBB> or float: 0/0?
[17:11:50] <mru> 0/0 == nan
[17:12:52] <gthreepwood> Thanks. If you're interested, I'm looking at the effects of encoding the rotation of blocks as well as just their translation for motion compenstation.
[17:13:15] <BBB> mru: ok, thanks
[17:16:07] <mru> inf/inf is also nan
[17:16:18] <mru> in ieee754
[17:20:57] <Dark_Shikari> gthreepwood: block matching algorithms? really?
[17:21:03] <Dark_Shikari> that stuff has been beaten to death
[17:21:13] <Dark_Shikari> also, if you want to work on motion estimation, pick a good encoder to start with
[17:21:23] <mru> Dark_Shikari: exactly, more papers to plagiarise then
[17:21:27] <gthreepwood> :) Any suggestions?
[17:21:47] <Dark_Shikari> x264 obviously
[17:22:07] <Dark_Shikari> but seriously, block-matching motion estimation has been beaten to death
[17:22:22] <Dark_Shikari> no slow algorithm can possibly be better than sequential elimination
[17:22:34] <Dark_Shikari> no ultra-fast algorithm can be much better than DIA, since x264's predictors are so overkill that even DIA is good
[17:23:01] <Dark_Shikari> and in the middle, while there might be some gain to be had, the requirement that it must be SIMDable puts heavy restrictions on your options
[17:23:21] <Dark_Shikari> the primary mistake I see people make is to test motion estimation algorithms in encoders with few or no predictors
[17:23:28] <gthreepwood> I'm applying a new combinatorial rotation algorithm that is quite SIMDable
[17:23:29] <Dark_Shikari> this tends to greatly inflate the benefit
[17:23:36] <Dark_Shikari> don't use buzzwords, say what it actually does
[17:23:39] <BBB> is this a science project? or corporate?
[17:23:40] <Dark_Shikari> is it gradient descent?
[17:24:04] <gthreepwood> no the algorithm just enumates all of the rotations for a block efficiently
[17:24:42] <gthreepwood> BBB, a university project
[17:24:44] <mru> Dark_Shikari: hadn't you noticed that academic projects always study either pie-in-the-sky or long-obsolete stuff, sometimes both
[17:24:54] <Dark_Shikari> gthreepwood: oh, so it isn't a block-matching motion estimation project
[17:24:56] * BBB kicks mru
[17:25:08] <Dark_Shikari> you're writing a ROTATION-aware motion estimation algorithm
[17:25:12] <Dark_Shikari> now _THAT_ is actually interesting
[17:25:35] * BBB thinks Dark_Shikari isn't paying attention when he hears buzzwords
[17:25:45] <Dark_Shikari> Now, you will have to find some way to signal the rotation amount in the bitstream, and you'll need to find a way to fill the holes created by rotation (e.g. on the corners)
[17:26:10] <Dark_Shikari> and you will need to find a fast but good enough rotation interpolation algorithm so that the decoder doesn't get 5 times slower
[17:26:12] <gthreepwood> Yes, all interesting problems :)
[17:26:21] <Dark_Shikari> I've already designed a way to signal it in the bitstream though
[17:26:22] <Dark_Shikari> it's trivial
[17:26:43] <Dark_Shikari> with CABAC, here's how I'd do it:
[17:26:53] <Dark_Shikari> 1) We start by assuming 0 degree rotation.
[17:26:53] <mru> if pixels were triangular, we could use hexagonal blocks and rotations by pi/3 would leave no holes
[17:27:22] <Dark_Shikari> 2) We get a bit.  If the bit is 0, we stop, no rotation.  If 1, we continue.
[17:27:38] <Dark_Shikari> 3) We get a bit.  If the bit is 0, we rotate by -90.  If the bit is 1, we rotate by +90.
[17:27:45] <Dark_Shikari> repeat, each time refining the rotation
[17:27:50] <Dark_Shikari> so the next step, it'll go +/- 45
[17:27:54] <Dark_Shikari> then +/- 22.5
[17:27:57] <gthreepwood> I see, that's an interesting approach
[17:28:05] <Dark_Shikari> thus the encoder can choose an arbitrary level of precision based on whatever is RD-optimal
[17:28:13] <Dark_Shikari> and it simply writes an EOB bit at the end when it's done
[17:28:20] <kshishkov> mru: "always study either pie-in-the-sky or long-obsolete stuff,  sometimes both
[17:28:22] <Dark_Shikari> and thanks to arithmetic coding, it's cheap.
[17:28:26] <Dark_Shikari> Relatively.  We hope.  Maybe.
[17:28:36] <kshishkov> mru: sounds like "academic study" definition
[17:28:53] <Dark_Shikari> Though intuitively it seems as though it cannot actually code 180 degree rotations
[17:28:58] <Dark_Shikari> thanks, Zeno's paradox
[17:29:26] <gthreepwood> so you think I should be looking at modifying x264? I thought it might be a bit complex, although I haven't yet looked at the code
[17:29:30] <Dark_Shikari> but anyways, if you wanted to do this in x264, you would need the following:
[17:29:45] <Dark_Shikari> 1) Modify the motion compensation functions (x264_mb_mc and relatives) in common/macroblock.c
[17:30:00] <Dark_Shikari> 2) Find some place in the macroblock cache to store the rotation of each block (h->mb.cache.rotation or something?)
[17:30:09] <Dark_Shikari> I'd say that one rotation syntax element per partition is reasonable
[17:30:17] <Dark_Shikari> so an 8x16 block would have two rotation syntax elements.
[17:30:55] <Dark_Shikari> 3) Decide at what point you're going to do the rotation analysis and modify the motion search to consider it.
[17:31:05] <Dark_Shikari> 4) Modify ffh264 decoder to do the same thing
[17:31:54] <kshishkov> Dark_Shikari: does all that sounds to me only that "iterative systems" is the next logical step ;)
[17:31:54] <Dark_Shikari> the primary reason I recommend x264, other than bias, is that nobody in this channel really understands any of the mpegvideo encoders in ffmpeg, especially not the motion estimation parts ;)
[17:33:06] <gthreepwood> So the x264 code, that's in the separate x264 project, right?
[17:33:21] <Dark_Shikari> yes
[17:33:37] <gthreepwood> Thanks for your helpful comments
[17:33:40] <kshishkov> decoder for it is still in FFmpeg though
[17:34:01] <BBB> Dark_Shikari, nobody understands the decoder either :)
[17:34:06] <Dark_Shikari> Yeah, but modifying encoders is much harder than changing decoders =p
[17:34:10] <gthreepwood> If I have further questions relating to x264, where should I ask them?
[17:34:12] <Dark_Shikari> since there's no analysis step
[17:34:14] <Dark_Shikari> #x264dev
[17:34:24] <Dark_Shikari> feel free to ask _anything_
[17:34:30] <Dark_Shikari> there are no stupid questions, only stupid people
[17:35:01] <kshishkov> Dark_Shikari: but anime-related questions should be transferred to #mplayer-dev
[17:35:24] <Dark_Shikari> no, #x264
[17:35:30] <Dark_Shikari> oh wait, that's _Touhou_
[17:35:35] <Dark_Shikari> yeah, anime goes to #mplayerdev
[17:35:38] <kshishkov> my point exactly
[17:37:09] <Dark_Shikari> But wait a minute...
[17:37:11] <Dark_Shikari> what about a touhou anime...?
[17:37:18] <kshishkov> not drawn yet
[17:37:22] <Dark_Shikari> no, there is one
[17:37:37] <Dark_Shikari> I use it for my 50kbps encoding tests
[17:38:25] <jai> well, in that case cross-post to both channels
[17:38:27] <jai> :)
[17:38:41] <Dark_Shikari> gthreepwood: one more important thing to note; --dump-yuv in x264 dumps the internal state of the encoder to a file
[17:38:48] <Dark_Shikari> this MUST match the output data from the decoder.
[17:39:06] <Dark_Shikari> so whatever changes you make, the way to test that they worked is by doing that diff.
[17:39:19] <Dark_Shikari> (also, cmp is generally better than diff for large yuvs)
[17:39:49] <kshishkov> diff is not good for binary data anyway
[17:40:45] <Dark_Shikari> last time I ran diff on yuvs, it ran out of memory
[17:41:16] <kshishkov> maybe they were way > 50M
[17:41:24] <jai> lol, roundup registration is broken?
[17:41:27] <Dark_Shikari> 7GB each
[17:41:39] <kshishkov> jai: could be
[17:42:28] <jai> kshishkov: probably after the upgrade
[17:42:32] <jai> lu_zero: ^^
[17:42:51] <kshishkov> jai: Luca has fixed something for ordinary user registration
[17:43:16] <kshishkov> I remember somebody complained and was able to register later
[17:43:19] <jai> if he doesnt care about the actual diff, maybe just keep track of the md5
[17:43:31] <jai> kshishkov: ah
[17:44:05] <jai> there doesn't seem to be a registration page right now though
[17:44:12] <jai> atleast i cant find it...
[17:45:17] <kshishkov> https://roundup.ffmpeg.org/user?@template=register
[17:45:25] <jai> hmm
[17:45:36] <DonDiego> BBB: colloquy works fine as irc client on os x
[17:45:52] <jai> well screw me then
[17:46:03] <jai> kshishkov: is that accessible from the landing page?
[17:46:20] <kshishkov> jai: don't care since I know how to construct URLs ;)
[17:46:37] <jai> kshishkov: fair enough :)
[17:46:58] <BBB> Vitor1001, postfilter progress is in codec repo
[17:47:03] <BBB> Vitor1001, if you want to have a look
[17:47:13] <BBB> Vitor1001, do we have code for MDF? e.g. in AAC?
[17:49:24] <jai> hmm, our nsv maintainer doesnt seem to be around much
[17:49:51] <DonDiego> siretart`: are you fine with the news entry?
[17:49:58] <kshishkov> none of those Italians seems to be around much
[17:50:37] <jai> he is probably busy with haiku ;)
[17:51:09] <BBB> uhm... it doesn't ident?
[17:51:26] <CIA-92> ffmpeg: diego * r22132 /trunk/MAINTAINERS: Add Reinhard and myself as release managers.
[17:51:47] <kshishkov> jai: guess what nationality was always-absent maintainer of RM before some RV decoder maintainer and BBB took over?
[17:51:55] <BBB> italian
[17:51:57] <BBB> right?
[17:52:02] <jai> kshishkov: roberto you mean?
[17:52:18] <DonDiego> BBB: colloquy? it does ident for me..
[17:52:18] <kshishkov> yes
[17:52:29] <jai> rtogni hasnt been active on the ML too i think
[17:52:39] <BBB> DonDiego, is there a way to make it auto-ident to nickserv?
[17:52:51] <kshishkov> yes, nor does not he REs new codecs :(
[17:52:53] <BBB> BBB__: test
[17:52:54] <DonDiego> yes
[17:52:56] <jai> hmm, i always assumed mmu_man was french :)
[17:53:01] <DonDiego> jai: he is
[17:53:04] <BBB> dondiego: elaborate :)
[17:53:07] <iive> roberto vanished at once, without any trace or word
[17:53:26] <jai> DonDiego: ah, messed up context in that case :)
[17:53:30] <DonDiego> BBB: gimme a sec
[17:53:34] <kshishkov> and we see only 50% of Lucas here
[17:53:39] <av500_at> janneg: ping see query
[17:54:31] * BBB__ retries
[17:55:09] <BBB> aha
[17:55:10] <kshishkov> av500_at: http://b1.imgsrc.ru/w/wind_wing/0/17069990gWs.jpg
[17:55:14] <DonDiego> BBB: see, it works :)
[17:55:24] <BBB> dondiego: thanks, it was another prefs window :)
[17:55:46] <BBB> aha, tab completion here is better
[17:56:27] <av500_at> kshishkov: lol
[17:57:17] <av500_at> janneg: i hope BBB is doing well
[17:59:41] <CIA-92> ffmpeg: diego * r22133 /branches/ (0.5/MAINTAINERS 0.5): Add release managers, merged from trunk.
[18:04:43] <CIA-92> ffmpeg: diego * r22134 /branches/0.5/RELEASE: If we are using partial release names we might as well try to be funny.
[18:07:06] <BBB> av500_at: ARGH
[18:07:19] <BBB> now my dock icon keeps blinking at me everytime you mention that video
[18:07:29] * BBB might not like this after all
[18:07:48] <kshishkov> BBB: change nick or kill av500
[18:08:12] <BBB> I prefer the second
[18:08:46] <kshishkov> it's unlikely there will be a movie with the name like my nick. And users are too lazy to type it anyway
[18:15:41] <elenril> irssi doesn't work on os x? ;)
[18:15:55] <kshishkov> it does
[18:17:12] <CIA-92> ffmpeg: vitor * r22135 /trunk/ (4 files in 2 dirs): Revert r22119 and partially revert 22120.
[18:18:18] <Vitor1001> BBB: I will look at it later today or tomorrow
[18:19:10] <Vitor1001> BBB: I looked very quickly, and I saw that "FilterFrameFrequencyDomainF()" is just a complex multiplication.
[18:20:23] <Vitor1001> BBB: About the float clipping, did you look at the last messages of the thread I linked to?
[18:21:01] <Vitor1001> Looks like a good solution to me...
[18:27:16] <DonDiego> siretart`: http://www1.mplayerhq.hu/~diego/license.diff
[18:29:13] <DonDiego> siretart`: http://www1.mplayerhq.hu/~diego/license.diff.txt
[18:29:30] <DonDiego> i have nothing else pending
[18:29:47] <DonDiego> if you're good with the news entry, we're ready to roll
[18:29:55] * byteme` is getting more familiar with the code
[18:30:25] <kshishkov> good
[18:30:36] <BBB> Vitor1001: seems like you want to do it in the decoder
[18:30:46] <BBB> Vitor1001: I'm not sure I agree, lots of code duplication in each decoder
[18:30:53] <BBB> Vitor1001: but if you prefer that, then it's fine with me
[18:31:07] <Vitor1001> BBB: Well, the problem about the clipping is that for some codecs it is not needed
[18:31:10] <BBB> Vitor1001: my bug is that float:1.0 becomes int16:-0x8000, if you can fix that for me, I'm happy
[18:31:21] <Vitor1001> but michael found a way to make this clipping to [-1:1]
[18:31:52] <BBB> Vitor1001: I didn't rea the whole thread, I guess
[18:31:58] <BBB> anyway
[18:31:59] <BBB> again
[18:32:03] <BBB> if it fixes th ebug, I'm ok with it
[18:32:12] <BBB> I think the conv code right now is buggy, it requires input to be clipped already
[18:32:20] <BBB> that should be fixed
[18:32:23] <Dark_Shikari> Vitor1001: make it a codec pack
[18:32:23] <Dark_Shikari> er
[18:32:24] <Dark_Shikari> cap
[18:32:35] <Vitor1001> BBB: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-August/073899.html
[18:33:06] <Vitor1001> Dark_Shikari: That is a nice idea, patch welcome ;)
[18:33:31] <Dark_Shikari> no, I'm suggesting doing it as part of what you're already doing
[18:33:34] <Dark_Shikari> eliminating the code duplication
[18:34:08] <BBB> Vitor1001: lrintf(-0.5)->-1
[18:34:09] <Vitor1001> There is a lot to be done also, mainly using dsputils for conversion
[18:34:12] <BBB> (for input=float:0.0)
[18:34:13] <BBB> that's not good
[18:34:46] <janneg> av500_at: I can only speak for a single BBB instance. take 1 of the intro rendered fine on KotH's machine and my quadcore is busy rendering the last take of the intro
[18:35:17] <Vitor1001> BBB: why? it is conversion for signed int.
[18:35:28] <BBB> to signed int, right?
[18:35:29] <janneg> with 0.0003 fps. sigh
[18:35:39] <BBB> float->int16
[18:35:42] <BBB> input=float:0.0
[18:35:47] <Vitor1001> for unsigned it should be different
[18:35:59] <Vitor1001> have to go now
[18:36:00] <Vitor1001> brb
[18:36:00] <BBB> out=32767.5*0.0-0.5=-0.5, lrintf(-0.5)=-1
[18:36:11] <BBB> =problem
[18:36:26] <BBB> 0.0 -> 0 is correct, 0.0->-1 is bad
[18:40:15] <kshishkov> it should not happen
[18:40:44] <kshishkov> unless you have lim \sup{ x -> inf} - 1/x
[18:53:42] * siretart` calls it a day. cu later!
[19:02:39] <gthreepwood> Dark_Shikari, I can't seem to talk in #x264dev or #x264. What's wrong?
[19:03:25] <ShadowJK> need registered nickname?
[19:04:07] <kshishkov> I thought that Guybrush Threepwood is a Famous Pirate^TM already
[19:04:14] <Dark_Shikari> gthreepwood: register your nick
[19:04:25] <gthreepwood> Will do, thanks.
[19:49:19] <siretart> DonDiego: still around? are we there yet? :-)
[19:54:37] <kshishkov> siretart: release and forget about it already! We have 0.6 to prepare
[19:57:06] <Vitor1001> BBB: I see the problem...
[19:57:40] <CIA-92> ffmpeg: vitor * r22136 /trunk/libavcodec/celp_filters.c: Add commented-out unoptimized code to improve readability
[19:57:58] <BBB> thanks for that commit :)
[19:58:03] <BBB> I wish we would do that for code everywhere
[19:58:08] <BBB> optimized code is often unreadable
[19:58:30] <Vitor1001> BBB: Yeah, I should have done that since my optimization commit
[19:59:49] <Vitor1001> BBB: The problem is that the range [INT_MIN; INT_MAX] is centered around 0.5
[20:00:18] <Vitor1001> Err, I mean -0.5
[20:01:34] <Vitor1001> Maybe just lrintf(*(const float*)pi * 32767)
[20:01:43] <Vitor1001> Who cares it will never be -32768?
[20:05:47] <Vitor1001> BTW, am I the only one who finds that tree.c:av_tree_enumerate() does not enumerate anything?
[20:06:40] * elenril wonders if he should create a dummy stream for metadata muxer or fix all code that assumes at least one stream exists
[20:10:54] <BBB> Vitor1001: mru also suggested (1<<n)-1
[20:10:58] <BBB> Vitor1001: I'm ok with that
[20:11:18] <BBB> Vitor1001: please suggest that on ML, I'll send a new patch and apply
[20:11:38] <BBB> it causes significant distortion in some of my samples
[20:11:40] <Vitor1001> Remains to see if MN will like it.
[20:11:45] <BBB> qcelp hack should also be removed
[20:11:50] <BBB> it'll clean up qcelpdec :)
[20:11:57] <Vitor1001> qcelp, amr, sipr, ...
[20:12:20] <Vitor1001> But I think the clipping is more complicated.
[20:12:24] <BBB> right
[20:12:24] <BBB> anything float-based
[20:12:58] <Vitor1001> Maybe having two sample formats: SAMPLE_FMT_FLT and SAMPLE_FMT_FLT_UNCLIP
[20:13:06] <BBB> no... ewh
[20:13:10] <BBB> asking for problems :)
[20:13:18] <BBB> let's have one unified behaviour
[20:13:21] <BBB> there's no reason not to
[20:13:30] <Vitor1001> I know, but how to avoid clipping for codecs that does not need it?
[20:13:33] <BBB> if you want me to do 23767/32768 as cliprange in my decoder I'll do it
[20:13:44] <BBB> I just want it solved :)
[20:13:53] <BBB> which codecs btw?
[20:13:53] <Vitor1001> No, I'm talking about moving clipping to common code
[20:13:59] <Vitor1001> I think it will be hard
[20:14:03] <BBB> which codecs don't want that?
[20:14:53] <Vitor1001> none ATM, mostly because those who could use dsputils.float_to_int16()
[20:15:07] <Vitor1001> s/could use/could use use/
[20:27:42] <BBB> that function should never be used in codecs
[20:27:46] <BBB> if the internals are float
[20:27:50] <BBB> the codec should output float
[20:27:57] <BBB> (and reversely for int)
[20:28:19] <BBB> but anyway I'm blablabla'ing here, what do I know :)
[20:28:34] <BBB> I thought there was an issue tracker entry to move wma1/2dec to float
[20:37:13] <Vitor1001> BBB: If the codec is widely used and speed critical, converting output to float is a problem
[20:37:28] <Vitor1001> dsputils.float_to_int16() is _much_ faster than C code
[20:40:21] <BBB> I understand
[20:41:03] <BBB> anyway, fix it in whatever way you feel is best
[20:43:00] <CIA-92> ffmpeg: vitor * r22137 /trunk/libavcodec/celp_filters.c: Fix spelling in comment
[20:46:46] * byteme` is now registered on freenode
[20:59:16] <ramiro> who wants to have fun optimizing a strnlen implementation? http://pastebin.com/0NXhjhCj
[20:59:56] <Dark_Shikari> are we allowed to overread the array?
[20:59:57] <ramiro> this seems to be the code that gcc likes the best, everything else becomes huge. I'm not quite confident some compiler won't messup that post-increment in the while().
[21:00:00] <Dark_Shikari> can we assume that it's byte-aligned?
[21:00:05] <Dark_Shikari> er, 8-byte aligned
[21:00:07] <Dark_Shikari> or something like that
[21:00:37] <ramiro> heh, that's the most important thing you *cannot* do (overread the array)
[21:01:00] <Dark_Shikari> so you can't assume the input is aligned?
[21:01:00] <ramiro> and no need for SSE either, just keep it plain and safe C...
[21:01:06] <Dark_Shikari> that's crap
[21:01:18] <Dark_Shikari> any program in which you need a fast strlen should have aligned data
[21:03:41] <Dark_Shikari> also, the function sucks anyways
[21:04:05] <twnqx> no utf support? :>
[21:04:31] <Dark_Shikari> something like http://pastebin.com/dQtBLEJx should be faster
[21:04:37] <Dark_Shikari> (not guaranteed to work)
[21:09:35] <ramiro> doesn't work for strings greater than n.
[21:10:10] <Dark_Shikari> er, what?  the entire point is that it's not supposed to
[21:10:11] <Dark_Shikari> it's strnlen
[21:10:47] <Dark_Shikari> if you mean it's off by one, that was intentional, I didn't try to fix all the off by 1s
[21:10:52] <Dark_Shikari> you can probably fix that by adding 1 to end or something
[21:14:52] <ramiro> yes, it was off by 2 actually =)
[21:20:31] <Dark_Shikari> is it faster now that it's fixed?
[21:24:29] <ramiro> it's been hard to test actually... the strings are include file paths, so a couple hundred chars max. most of the time it's about 10 chars.
[21:25:33] <ramiro> the code used to have strlen() and clip to n afterwards. so it would strlen the whole file (instead of each line), and potentially crash.
[21:26:18] <ramiro> if anyone's interested, ccache might be upgraded to GPLv3: http://lists.samba.org/archive/ccache/2010q1/000475.html
[21:59:49] <Dark_Shikari> what the fuck, I'm confused
[22:00:02] <Dark_Shikari> my string starts with:
[22:00:03] <Dark_Shikari> timebase=1/1000 cabac=1 ref=1 debl
[22:00:14] <Dark_Shikari> sscanf( s, "timebase=%d/%d", &i, &j ) doesn't reutrn 2.
[22:01:01] <Dark_Shikari> oh, blah, there was a character before the start and sscanf apparently needs a strstr attached.
[22:51:35] <BBB> Dark_Shikari: you can add %.*s (or so) to skip random chars at the start, I forgot how it works exactly
[23:03:48] <CIA-92> ffmpeg: stefano * r22138 /trunk/ffprobe.c: Clarify the error message issued by ffprobe in case of more than one file provided as input.
[23:09:09] <mfg> does ftp://upload.ffmpeg.org allow anonymous uploads (as per developer.html)?  I'm having trouble uploading a sample.
[23:11:17] <CIA-92> ffmpeg: stefano * r22139 /trunk/ffplay.c: Add a check in the case more than one input file is provided to ffplay, make it complains and abort as just one input file is supported.
[23:20:39] <Kovensky> mfg: samples.mplayerhq.hu/incoming
[23:20:48] <mfg> ty