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

[irc at mansr.com]

[01:13:32] <astrange> http://pastebin.com/irns0w3w some list subscriber has a broken mail server
[02:57:29] <BBB> Dark_Shikari: is there a command like movhps for mm registers?
[06:21:51] <Dark_Shikari> "codec specific options are supported now"
[06:21:52] <Dark_Shikari> _WHAT_
[06:26:34] <KotH> a wonderfull good morning everyone around the ffmpeg world
[06:26:48] <thresh> good morning to you too
[06:27:13] <peloverde> Dark_Shikari: Don't you know, different rules apply to different people
[06:28:11] <ohsix> eventual realization is what happens to stubborn people
[06:36:11] <KotH> günaydin cartman
[06:41:49] <cartman> günaydın KotH , dün Dedem vefat etti, cenazesi için Giresun'daydık :(
[06:42:01] <KotH> :-(
[06:42:07] <KotH> basiniz sag olsun
[06:42:14] <cartman> KotH: dostlar saÄŸolsun
[06:51:22] <astrange> the one cutscene i've seen of halo reach was half in subtitled hungarian
[06:51:30] <Dark_Shikari> lol
[06:51:34] <astrange> maybe writing video players leads to writing space stations
[06:51:56] <astrange> /w/win 25
[06:52:04] <astrange> i'm getting really bad at switching windows...
[06:56:31] <cartman> yeah
[08:38:28] <cartman> x86/deinterlace.asm:79: error: macho: sorry, cannot apply 32 bit absolute relocations in 64 bit mode, consider "[_symbol wrt rip]" for mem access, "qword" and "dq _foo" for pointers.
[08:38:34] <cartman> possibly for BBB
[08:55:33] <KotH> boys, what can i do if i have two variants of the same function which i want to profile, but gprof has a higher stdev among runs of the same version, than between the two versions?
[08:56:30] <lu_zero> KotH: perf is an option?
[08:56:38] <kshishkov> flip a coin to determine which one to leave
[08:57:00] <kshishkov> or run them more times (probably from a test program)
[08:58:01] <KotH> lu_zero: perf?
[08:58:30] <KotH> kshishkov: the stdev is so high, that i'd have to run it several 1000 times... with each run taking about 5min
[08:59:19] <kshishkov> KotH: flip a coin then - totally fair resolution
[09:00:10] <cartman> yasm error is due to mplayer's configure not using DPIC for yasm
[09:00:19] <KotH> kshishkov: uhmm.. the tool is inaccurate, not the difference small
[09:00:29] <kshishkov> try oprofile then
[09:01:05] <_av500_> +1
[09:01:26] <lu_zero> http://perf.wiki.kernel.org/index.php/Main_Page
[09:01:27] <KotH> domo
[09:02:02] <lu_zero> like oprofile but somehow simpler to use
[09:05:17] <lu_zero> KotH: another option is valgrind calltrace
[09:07:58] <KotH> hmm.. right
[09:07:59] <KotH> thanks
[09:21:52] <Tjoppen> it seems  the code related to dts_delta_threshold in ffmpeg isn't behaving quite properly
[09:22:56] <Tjoppen> I had further mpegts remuxing woes today. one of the longer test files has a discontinuity in it, which ends up messing with the dvbsub timestamps enough to case non-monotonicity
[09:23:06] <Tjoppen> *cause
[09:25:28] <Tjoppen> luckily fixable by setting the threshold higher, but ffmpeg should complain louder and/or the code should be fixed
[09:27:04] <_av500_> mru: i tried to take the troll further, but so far nobody bites :)
[09:27:08] <_av500_> https://groups.google.com/a/webmproject.org/group/webm-discuss/browse_thread/thread/272cd40895e8d246
[09:30:35] <mru> morning
[09:30:40] <kshishkov> _av500_: you should've compared it to HTML handling more openly
[09:31:25] <_av500_> jaja
[09:32:08] <mru> html renderers are _too_ lenient
[09:32:26] <Tjoppen> .. what? better support considered a bug?
[09:32:35] <mru> html follows the motto, be generous with what you give and grateful for what you receive
[09:33:19] <kshishkov> i.e totally not like tax office
[09:33:35] <_av500_> Tjoppen: yes. it seems that if one creates webm to be actually mkv, one has to enforce it not being mkv, otherwise ppl will say, hey, its mkv..
[09:34:37] <Tjoppen> I'm not sure I follow
[09:38:25] <mru> webm not being mkv is a bit like ubuntu not being canonical
[09:41:49] <Tjoppen> I know that. but I'm a little curious why someone would considered something that works to be a bug
[09:42:11] <_av500_> in order to have a clean separation between webm and mkv
[09:42:30] <_av500_> because if it was not clear, ppl could start just using mkv
[09:42:41] <Tjoppen> oh, I see. bondage and dicipline
[09:42:48] <_av500_> ocourse
[09:43:03] <_av500_> bow to thy masters
[09:43:24] <Tjoppen> like java and its insisting on lots of stupid things
[09:43:51] <Tjoppen> or python and its significant indentation
[09:44:04] <Tjoppen> lunchtime
[10:47:08] <thresh> now that you mentioned ffmpeg-devel is a source for bikesheds, I see them everywhere
[10:52:14] <CIA-63> ffmpeg: stefano * r25267 /trunk/libavformat/avio.c:
[10:52:14] <CIA-63> ffmpeg: Make register_protocol() use the function av_register_protocol2()
[10:52:14] <CIA-63> ffmpeg: rather than av_register_protocol(), which is deprecated.
[10:52:14] <CIA-63> ffmpeg: Fix the GCC warning:
[10:52:14] <CIA-63> ffmpeg: avio.c: In function ?register_protocol?:
[10:52:15] <CIA-63> ffmpeg: avio.c:93: warning: ?av_register_protocol? is deprecated (declared at avio.c:86)
[10:56:00] <CIA-63> ffmpeg: stefano * r25268 /trunk/libavformat/avio.h: Document url_filesize().
[12:14:22] <wbs> mru: if I'd like to test an audio encoder (g722), but I'd need mono input test data (ffmpeg-synthetic/asynth1.sw is stereo), what's the best solution?
[12:14:45] <wbs> I could either add -ac 1 to the ffmpeg command line, passing all data through the resampler, testing both that and the encoder at the same time
[12:15:06] <wbs> or add -ac 1 to the input part, pretending that asynth1.sw is mono
[12:15:08] <mru> we've talked about creating multiple test inputs
[12:15:48] <wbs> yeah, justin added some code to the audiogen for that, but there's no current test using it yet
[12:27:34] <CIA-63> ffmpeg: cehoyos * r25269 /trunk/libavcodec/dvdata.c:
[12:27:34] <CIA-63> ffmpeg: Fix a yuv420p sample that was incorrectly detected as yuv411p
[12:27:34] <CIA-63> ffmpeg: (576i50 25Mbps 4:1:1 special case was wrong).
[12:27:34] <CIA-63> ffmpeg: Fixes issue2211
[12:27:34] <CIA-63> ffmpeg: Patch by Niobos, niobos dest-unreach be
[14:26:10] <merbzt> Tjoppen: where did you get the 27Mhz timebase from ?
[14:26:26] <merbzt> shouldn't it be 90kHz ?
[14:27:06] <mru> 27MHz is the fundamental time base of the universe
[14:27:33] * cartman would guess 42MHz
[14:27:37] <_av500_> 54!
[14:28:02] <kshishkov> _av500_: stop saying your age
[14:28:02] <mru> _av500_: in turbo mode
[14:28:15] <kierank> 54mhz because of interlaced
[14:28:26] <mru> kierank: no
[14:28:54] <kierank> yes, the universe accepted that interlaced is a hack
[14:30:20] <kierank> so the universe had to double the time base like in h.264
[14:33:10] <Compn> bcoudurier : btw , you removed 'duplicated' m2v2, but m2v1 was the original entry... now i'm not sure which is correct m2v2 or m2v1. i only see m2v1 results in apple forums
[14:33:31] <Compn> http://discussions.apple.com/thread.jspa?messageID=7988417
[14:51:59] <Tjoppen> merbzt: PCR is 27 MHz
[14:52:29] <Tjoppen> or maybe there's a better word for it. you basically multiply be 300
[14:52:32] <Tjoppen> *by
[14:53:01] <Tjoppen> also happens to be PAL's pixel clock IIRC
[14:53:18] <mru> that's no coincidence
[14:56:04] <Tjoppen> indeed. probably has to do with the PAL fields being non-integer number of lines too
[14:56:15] <Tjoppen> the need for such a high precision that is
[14:58:33] <Tjoppen> mostly the problem is the drift, but complying to the standard regarding jitter is probably a good idea too
[15:24:36] <mru> wtf happened? gsm test is passing on ppc/gcc-4.2 now
[15:33:19] <jb_OVC> BBB: saturday afternoon
[15:37:57] <CIA-63> ffmpeg: aurel * r25270 /trunk/libavcodec/ (resample.c avcodec.h utils.c): add FF_API_AUDIO_OLD define to disable the deprecated decode_audio API
[15:56:07] <BBB> jb_OVC: are you there friday?
[15:56:14] <BBB> bcoudurier: same question for you
[15:57:10] <kierank> troll xiph for me
[15:57:40] <_av500_> at ovc xiph trolls you
[15:57:49] <lu_zero> BBB: all ready?
[15:58:12] <BBB> for what?
[15:58:13] <kierank> _av500_: xiph troll by definition of their existence
[16:03:22] <BBB> lu_zero: ?
[16:04:01] <BBB> who's dave rice btw?
[16:04:09] <BBB> merbanan: and did you end up deciding to go or not?
[16:06:54] <lu_zero> BBB: the snagon presentation
[16:07:17] <lu_zero> just to make the xiph people at ease
[16:07:19] <jb_OVC> BBB: yes, of course
[16:07:19] <jb_OVC> e
[16:07:45] <jb_OVC> kierank: trolling xiph is the reason of this conf, no?
[16:13:55] <BBB> lu_zero: who's presenting then?
[17:38:52] <lu_zero> kshishkov: ping
[18:03:37] <bcoudurier> Compn, m2v1 is correct
[18:13:22] <CIA-63> ffmpeg: bcoudurier * r25271 /trunk/libavformat/isom.c: Correct tag is m2v1
[19:20:18] <_av500_> kshishkov: berlin did not explode today
[19:23:39] <mru> oh well, maybe next time
[19:26:23] <_av500_> mru: http://www.ccs.neu.edu/home/bchafy/lood.html  scroll down for some really old school video walling :)
[19:27:00] <Compn> _av500_ : is anyone scared of the vague threads against germany, france and u.k.?
[19:27:03] <Compn> threats*
[19:29:23] <_av500_> they found a 500kg bomb in berlin today it seems
[19:29:31] <_av500_> an olde one
[19:29:36] <mru> yes, from ww2
[19:29:50] <mru> american, no less
[19:30:05] <_av500_> not an ukranian make it seems
[19:30:50] <thresh> not russian? shame
[19:37:03] <astrange> http://news.cnet.com/8301-30685_3-20018146-264.html hey, it's vp8 I-frames
[19:37:25] <mru> and of course h264 intra beats it
[19:37:30] <mru> but they're not talking about that
[19:37:32] <astrange> Dark_Shikari: you missed the opportunity to advertise --tune stillimage
[19:37:55] <skal> arf
[19:38:00] <mru> h264 lossless intra isn't too bad either
[19:38:08] <skal> ffmpeg patch on its way
[19:38:51] <Dark_Shikari> astrange: no
[19:38:53] <Dark_Shikari> avc intra isn't a still image
[19:39:10] <Dark_Shikari> oh.  you mean as an image format?
[19:39:12] <astrange> yes
[19:39:14] <Dark_Shikari> I did advertise it, repeatedly
[19:39:20] <astrange> did it get its own blog post?
[19:39:21] <Dark_Shikari> nobody listened.  "jpeg is good enough"
[19:39:26] <Dark_Shikari> hmm.  it probably should have
[19:39:39] <Dark_Shikari> I don't really care
[19:40:56] * _av500_ waits for webE, the "nw shrtr nglsh lngg tht mks wbsts s mch smllr"
[19:41:20] <mru> webTXT
[19:41:37] <_av500_> and finally webWEB
[19:41:50] <_av500_> the all new closed garden aol, err google web
[19:42:13] <astrange> http://www.chromium.org/spdy/spdy-whitepaper
[19:42:53] <Compn> wow
[19:43:05] <Compn> so google figured out wavelet image compression?
[19:43:45] <Dark_Shikari> mru: h264 lossless intra kinda sucks
[19:43:54] <Dark_Shikari> I mean it's not terrible, but compared to ffv1...
[19:44:00] <_av500_> ...One convenient feature of WebP is that any hardware that supports WebM video encoding or decoding also supports WebP....
[19:44:11] <mru> Dark_Shikari: I meant compared to png
[19:44:21] <mru> or lossless jpeg
[19:44:35] <mru> _av500_: lol
[19:44:42] <Dark_Shikari> png wins for things where zlib does better
[19:44:49] <Dark_Shikari> i.e. repetitive patterns
[19:44:58] <mru> yeah
[19:45:01] <mru> but not photos
[19:45:22] <Dark_Shikari> yeah, but who losslessly compresses photos?
[19:45:49] <thresh> well huh
[19:45:54] <thresh> everyone who shoots raw
[19:47:21] <skal> http://pastebin.com/FbUvG77M
[19:47:36] <skal> .. but foude, first
[19:47:39] <Dark_Shikari> thresh: you want to compress before debayering first
[19:48:12] <Dark_Shikari> skal: let's get support in IE, first, ok?
[19:48:21] <Dark_Shikari> also, can you add h264 to that list?
[19:48:25] <Dark_Shikari> if you don't, I will commit support for it
[19:48:42] <bcoudurier> Dark_Shikari, I'm tryint to get AVCIntra 50 working in ffmpeg but having segv, it works with cli x264 though
[19:48:47] <thresh> Dark_Shikari: isnt it the same as on digital video camera though?
[19:48:49] <Dark_Shikari> bcoudurier: of course it segfaults
[19:48:54] <Dark_Shikari> ffmpeg is giving x264 the wrong input
[19:48:59] <Dark_Shikari> high-bit-depth x264 requires high-bit-depth input
[19:49:01] <Dark_Shikari> i.e. 16-bit input
[19:49:01] <bcoudurier> I changed that
[19:49:03] <Dark_Shikari> i.e. twice the input frame size
[19:49:06] <bcoudurier> I did the modifications
[19:49:09] <Dark_Shikari> well, actually, 10-bit input
[19:49:13] <Dark_Shikari> bcoudurier: pastebin?
[19:49:16] <bcoudurier> I give yuv420p16
[19:49:21] <bcoudurier> and set HIGH_CSP
[19:49:27] <Dark_Shikari> still wrong.  it requires 10-bit input
[19:49:31] <Dark_Shikari> the high 4 bits of each pixel must be zero
[19:49:31] <skal> yeah, let's get IE support for html5
[19:49:43] <Dark_Shikari> skal: imo a new image format is much more useful than html5
[19:49:56] <Dark_Shikari> html5 is just a new way to put Flash effects into my browser in a way I can't block
[19:50:12] <Compn> heh
[19:50:22] * Compn wonders how much x264 is going to pay for 10bit swscale
[19:50:41] <Dark_Shikari> er, why do we need it?
[19:50:43] <Dark_Shikari> we already wrote our own
[19:50:47] <Dark_Shikari> it's already committed
[19:50:56] <Compn> ah
[19:51:08] <bcoudurier> http://pastebin.com/7iRg4y0n
[19:52:23] <CIA-63> ffmpeg: aurel * r25272 /trunk/libavcodec/ (avcodec.h utils.c): add FF_API_VIDEO_OLD define to disable the deprecated decode_video API
[19:52:59] <_av500_> Dark_Shikari: yeah, ff html5_block extension :)
[19:53:03] <bcoudurier> you need to pass exactly 10 bits stored in 16 ?
[19:53:50] <bcoudurier> but with the cli it didn't segfault for the same input
[19:54:24] <bcoudurier> does cli assume 16in16 and convert ?
[19:54:54] <merbanan> BBB: not going
[19:55:07] <BBB> :(
[19:55:13] * _av500_ wonder if there will be MwebP?
[19:55:27] <bcoudurier> anyway I wish > 8 bit for libswscale to be funded
[19:55:34] <bcoudurier> only pros uses 10 bits
[19:59:26] <Compn> make ffmpeg for pros, charge $10k/license and make some money on support ?
[19:59:27] <Compn> ehe
[20:02:04] <bcoudurier> Compn, kinda, though $10k per license might be a bit much :>
[20:02:49] * Compn wonders what a blackmagic license goes for
[20:02:51] <cartman> bcoudurier: whats this "10 bit" thing?
[20:04:03] <Compn> ooh there is 12 bit too
[20:06:45] <bcoudurier> d-cinema is 12 bits
[20:07:25] <cartman> bcoudurier: what does the bit count represent?
[20:07:39] <bcoudurier> bit depth
[20:08:12] <cartman> I thought 24/32 bit depth was usual , at least for images
[20:08:41] <bcoudurier> 12 bits is 121212, 36
[20:10:08] <cartman> uh oh :>
[20:10:12] <Compn> cartman : its pretty confusing, checkup wikipedia
[20:10:18] * Compn has no idea about all these bits
[20:10:20] <cartman> Compn: title? :D
[20:10:22] * Compn should stfu :D
[20:10:28] <cartman> 888 is 24 then
[20:13:42] <CIA-63> ffmpeg: aurel * r25273 /trunk/libavcodec/ (avcodec.h utils.c): add FF_API_SUBTITLE_OLD define to disable the deprecated decode_subtitle API
[20:15:02] <twnqx> uau: is the git frontend right? no commits for the past two months? :S
[20:15:16] <twnqx> ugh, misclicked
[20:16:02] <_av500_> twnqx: yep, development is over :)
[20:16:13] <twnqx> :(
[20:16:45] <_av500_> it will be resumed once asm vs yasm is settled
[20:20:50] <Dark_Shikari> bcoudurier: yes you need 10 in 16
[20:20:52] <wbs> didn't you get the memo? everything that can be invented already is invented.. so stop coding ;P
[20:20:53] <Dark_Shikari> the CLI will convert for you
[20:20:59] <Dark_Shikari> the CLI will support any bit depth from 8 to 16 if you tell it (for raw input)
[20:21:01] <bcoudurier> ok
[20:21:13] <bcoudurier> it assumes 16 by default right ?
[20:21:40] <Dark_Shikari> no, probably 8
[20:22:00] <Dark_Shikari> --input-depth
[20:23:41] <bcoudurier> weird, it did work though
[20:24:11] <Dark_Shikari> http://www.mediafire.com/download.php?hookw5pxqcsmfb5
[20:24:15] <Dark_Shikari> here's a 10-bit encode in avc-intra
[20:24:17] <bcoudurier> anyway I got the shit working in fcp
[20:24:17] <Dark_Shikari> from x264
[20:24:21] <bcoudurier> using .mov
[20:24:21] <Dark_Shikari> awesome
[20:24:25] <Dark_Shikari> sweet
[20:24:31] <Dark_Shikari> does it pass it through, i.e. not re-encode?
[20:24:34] <bcoudurier> but cannot commit to ffmpeg since it doesn't work :P
[20:24:38] <bcoudurier> it does pass trough
[20:24:45] <Dark_Shikari> sweet, so our avc-intra does acutally work
[20:25:01] <Dark_Shikari> pastebin your ffmpeg patch
[20:25:01] <bcoudurier> ah no I didn't test using x264 encode
[20:25:03] <Dark_Shikari> and I'll look at it
[20:25:04] <bcoudurier> let me test
[20:25:11] <Dark_Shikari> oh btw, here's the problem with ffmpeg
[20:25:13] <bcoudurier> I did send it
[20:25:18] <Dark_Shikari> ffmpeg cannot choose compatible CSPs on runtime
[20:25:21] <bcoudurier> but p16 is actually 16 bits
[20:25:28] <Dark_Shikari> iirc
[20:25:34] <Dark_Shikari> bcoudurier: so copy x264's dithering code
[20:25:43] <Dark_Shikari> your pix_fmts is wrong.  x264 only supports one of the two
[20:25:47] <CIA-63> ffmpeg: stefano * r25274 /trunk/libavfilter/vsrc_nullsrc.c: Return AVERROR(EINVAL) rather than -1 in case of invalid values.
[20:25:48] <Dark_Shikari> it has to pick between them on _runtime_.
[20:25:50] <Dark_Shikari> ffmpeg's API can't do this
[20:25:56] <bcoudurier> I don't get it
[20:26:19] <Dark_Shikari> a given compile of x264 can ONLY take 16-bit or 8-bit, not both.
[20:26:22] <bcoudurier> yes
[20:26:26] <Dark_Shikari> ffmpeg does not know what x264 supports until _RUNTIME_.
[20:26:28] <bcoudurier> do you export that in the header ?
[20:26:33] <bcoudurier> you should if it's compile time
[20:26:40] <Dark_Shikari> No, we export it as extern x264_bit_depth;
[20:26:44] <bcoudurier> then it's only a matter of #ifdef
[20:26:48] <Dark_Shikari> I did not want to hack the installed headers
[20:26:51] <bcoudurier> compile time stuff should be in .h
[20:27:04] <Dark_Shikari> all the devs agreed that header hacking was bad
[20:27:06] <Dark_Shikari> even ffmpeg doesn't do header hacking
[20:27:13] <bcoudurier> what do you mean header hacking ?
[20:27:17] <bcoudurier> x264.h
[20:27:19] <Dark_Shikari> modifying .h files on compile time
[20:27:27] <bcoudurier> what ?
[20:27:36] <bcoudurier> we are creating them at compile time
[20:27:38] <bcoudurier> like the version
[20:27:42] <Dark_Shikari> that counts as modification
[20:27:48] <bcoudurier> that's what we do
[20:27:49] <Dark_Shikari> ffmpeg does not install config.h
[20:27:54] <Dark_Shikari> that isn't an installed header
[20:28:04] <Dark_Shikari> ffmpeg does not modify avcodec.h on compile time
[20:28:27] <Dark_Shikari> anyways I don't want to add yet another way that ffmpeg and x264 can be incompatibly linked.
[20:28:29] <bcoudurier> I don't agree with this
[20:28:32] <Dark_Shikari> ffmpeg should be able to switch on runtime.
[20:28:59] <bcoudurier> besides that's wrong
[20:29:03] <bcoudurier> because avconfig.h is installed
[20:29:11] <Dark_Shikari> ok, true, but you don't modify avcodec.h
[20:29:13] <bcoudurier> and it contains AV_HAVE_BIGENDIAN 0
[20:29:15] <Dark_Shikari> you're proposing we add x264config.h
[20:29:30] <Dark_Shikari> Now, anyways, how does avcodec define stride for 16-bit?
[20:29:45] <Dark_Shikari> in x264, stride is the number of bytes required to reach the next row of the frame.
[20:29:52] <Dark_Shikari> NOT the number of pixels
[20:30:21] <bcoudurier> yes
[20:30:24] <Dark_Shikari> hence the image being uint8_t * even in high bit depth
[20:30:33] <bcoudurier> that's the case I think
[20:30:40] <Dark_Shikari> next, are you sure x264 is getting 16-bit input?  your pixfmt line allows both 16-bit and 8-bit.
[20:30:45] <bcoudurier> but obvioulsy the high 4 bits are set
[20:30:52] <Dark_Shikari> Add a 4-line for loop.
[20:30:59] <Dark_Shikari> for( int y = 0; y < height; y++ )
[20:31:04] <Dark_Shikari> for( int x = 0; x < width; x++ )
[20:31:28] <Dark_Shikari> image->data[plane][x+y*stride] = image->data[x+y*stride] + 8 >> 4;
[20:31:29] <Dark_Shikari> etc etc
[20:31:47] <bcoudurier> yep let me try this
[20:32:04] <bcoudurier> btw I also got open gop working in .mov
[20:32:08] <bcoudurier> it's fun how quicktime works :>
[20:32:13] <Dark_Shikari> heh
[20:32:33] <CIA-63> ffmpeg: aurel * r25275 /trunk/libavcodec/ (avcodec.h flacenc.c options.c): add FF_API_USE_LPC define to disable the deprecated AVCodecContext.use_lpc field
[20:32:37] <Dark_Shikari> btw your other changes are ok, commit those
[20:32:39] <Dark_Shikari> e.g. opengop
[20:32:52] <bcoudurier> there is an API change here
[20:32:58] <bcoudurier> I need to consult others :>
[20:33:13] <bcoudurier> and you need special stuff in mov muxer as well
[20:33:20] <Dark_Shikari> ok, commit the keyframe thing then?
[20:33:34] <Dark_Shikari> also someone is adding SEI recovery point support to VLC, we should add it to avcodec too
[20:35:24] <CIA-63> ffmpeg: aurel * r25276 /trunk/libavcodec/ (opt.c opt.h avcodec.h): add FF_API_SET_STRING_OLD define to disable the deprecated av_set_string API
[20:36:01] <bcoudurier> the keyframe is an API change
[20:36:40] <skal> Dark: sesse?
[20:36:46] <bcoudurier> ah well explicitely 1 is mentioned in avcodec.h doxy
[20:36:51] <bcoudurier> so I guess 2 is just an extension ;)
[20:36:53] <Dark_Shikari> what does keyframe=2 mean?
[20:37:56] <skal> oh, Steinar it is
[20:38:16] <cartman> ooooh WebP
[20:38:29] <cartman> what a lame name
[20:38:57] <_av500_> webSingleFrameVP8
[20:39:05] <Dark_Shikari> webpatentmine
[20:39:07] <Dark_Shikari> webh264ripoff
[20:39:13] <Dark_Shikari> webmatroska
[20:39:14] <bcoudurier> means I frame but not IDR
[20:39:23] <Dark_Shikari> bcoudurier: but that can mean different things depending on the context
[20:39:33] <Dark_Shikari> What matters is recovery points
[20:39:42] <Dark_Shikari> It is completely useless to tell the calling app about non-IDR I-frames
[20:39:47] <Dark_Shikari> it is critical to tell the calling app about recovery points.
[20:39:54] <bcoudurier> it is necessary for the muxer
[20:39:57] <cartman> putting "web" into everything is just stupid
[20:40:01] <Dark_Shikari> bcoudurier: why?
[20:40:04] <bcoudurier> quicktime don't care about recovery poitns
[20:40:09] <bcoudurier> but care about "partial key frames"
[20:40:18] <Dark_Shikari> er... then it should detect that there is a recovery point
[20:40:21] <Dark_Shikari> and mark it
[20:40:22] <Dark_Shikari> in the mux
[20:40:31] <bcoudurier> it doesn't mark recovery points
[20:40:37] <Dark_Shikari> Did you read what I just said
[20:40:39] <Dark_Shikari> wait, no, of course not.
[20:40:44] <Dark_Shikari> I said, have the MUXER read recovery points
[20:40:46] <Dark_Shikari> and MARK  them in the mov file
[20:40:52] <bcoudurier> I could do that
[20:40:56] <Dark_Shikari> Here's why your method is completely wrong
[20:41:01] <Dark_Shikari> Not all I-frames are recovery points.
[20:41:01] <bcoudurier> but it's painful because I have to parse the bitstream
[20:41:03] <CIA-63> ffmpeg: aurel * r25277 /trunk/libavcodec/ (avcodec.h options.c): add FF_API_INOFFICIAL define to disable the deprecated 'inofficial' flag
[20:41:15] <Dark_Shikari> No you don't.  You can just export them in the API.
[20:41:36] <Dark_Shikari> and furthermore, not all recovery points are instant
[20:41:42] <Dark_Shikari> some recovery points have recovery times not equal to zero
[20:41:51] <Dark_Shikari> which, iirc, can be expressed in mov/mp4
[21:00:03] <jannau> Dark_Shikari: ffmpeg should set convergence_duration for SEI recovery points
[21:00:47] <Dark_Shikari> it shouldn't output frames until the recovery is complete imo
[21:00:55] <Dark_Shikari> when you seek
[21:00:55] <Dark_Shikari> etc
[21:02:32] <jannau> no, it's not. convergence_duration is always 0
[21:02:54] <jannau> except for TEXT subtitles in .mkv
[21:05:00] <astrange> that's a bug in matroska demuxer
[21:10:23] <jannau> and a bug in the h264 parser
[21:39:54] <wbs> uhm, this is interesting... I found some random opensource project.. that bundles the undistributable amr-nb reference code
[21:40:24] <wbs> and in a later commit, the author adds his own gpl copyright header, and a notice that " Permission to distribute, modify and use this file under the standard license
[21:40:27] <wbs> 28	 terms listed above has been obtained from the copyright holder."
[21:41:11] <mru> I'd verify that before trusting it
[21:41:17] <wbs> yeah
[21:41:37] <wbs> the "permission has been granted" clause is exacty the same as in opencore, but there the license is apache
[21:41:54] <wbs> so the question is, is this someone who has negotiated a proper deal, or just ignorant? :-)
[21:42:21] <wbs> http://code.google.com/p/siphon/source/diff?spec=svn605&r=605&format=side&path=/trunk/amr-nb/Headers/levinson.h
[21:42:30] <mru> who owns the copyright?
[21:43:08] <wbs> I guess the 3gpp owns it
[21:43:17] <mru> but who is that?
[21:43:36] <mru> getting code like that relicensed usually takes a lot of legal wrangling
[21:43:47] <wbs> yeah
[21:43:56] <wbs> I can imagine google/android/packetvideo managing to do it, for opencore
[21:44:14] <mru> yeah, but not some random guy
[21:44:26] <wbs> but "Samuel <samuelv0304 at gmail.com>" doing it, naming it "AMR codec for iPhone and iPod Touch", sounds a bit fishy
[21:44:52] <mru> the standard reply would be "sorry, we don't know who owns the rights to that, and we won't spend our time tracking it down"
[21:45:02] <wbs> yeah
[21:45:17] <Dark_Shikari> fun fact
[21:45:25] <wbs> I'm mostly annoyed by having spent a lot of time on that issue, doing the opencore-amr wrapper and all, trying to play by the book
[21:45:30] <Dark_Shikari> mozilla turned down google on "webp"
[21:45:50] <wbs> and then some joe random just blatantly ignores all common sense and slaps his own copyright on it and thinks it's all right
[21:46:11] <mru> Dark_Shikari: but xiph don't have their own dreadful image format...
[21:46:24] <kierank> mru: they'll make one in ogg, just wait and see
[21:46:27] <mru> wbs: welcome to life
[21:46:41] <Dark_Shikari> no, they think jpeg is fine
[21:49:11] <Dark_Shikari> btw, this means we can reject skal'
[21:49:14] <Dark_Shikari> *skal's patch.
[21:49:49] <wbs> mru: yeah, I know. boo hoo and all that. I guess I should grow a beard and become more grumpy and cynical :-)
[21:51:37] <mru> you can be cynical without being grumpy
[21:51:53] <Dark_Shikari> tell that to yourself
[21:51:54] <Dark_Shikari> ;)
[21:52:01] <wbs> hah :-)
[21:52:21] <mru> do you think I'm grumpy?
[21:55:31] <BBB> I thought I was grumpy
[21:56:11] <Dark_Shikari> no this is grumpy
[21:56:12] <Dark_Shikari> http://i679.photobucket.com/albums/vv159/Fireinferno225/Grumpy.jpg
[21:57:15] <kierank> mru isn't grumpy, he's just a troll
[21:58:25] <CIA-63> ffmpeg: michael * r25278 /trunk/ (5 files in 2 dirs):
[21:58:25] <CIA-63> ffmpeg: av_assert() system.
[21:58:25] <CIA-63> ffmpeg: With this the developer can now choose if he wants an assert always enabled or at which
[21:58:25] <CIA-63> ffmpeg: compile time assert level. This can thus replace the #define NDEBUG hacks
[21:59:24] <mru> I tried to do that years ago
[21:59:27] <mru> michael rejected it
[21:59:41] <Dark_Shikari> big, all-encompassing changes are fine if michael does them.
[21:59:47] <Dark_Shikari> if anyone else does them, they're bad.
[22:01:27] <BBB> Dark_Shikari: will you port my pred16x16/8x8plane to x264 or should I do it?
[22:01:37] <BBB> (I think it's nominally faster)
[22:02:16] <Dark_Shikari> I don't support replacing any code that isn't faster.
[22:02:28] <Dark_Shikari> That is, don't touch any of the function except the relevant parts that you think should be changed.
[22:02:40] <Dark_Shikari> and then confirm via checkasm that it's faster
[22:03:14] <BBB> hm, well, x264's 16x16plane is a c+asm combination mess so I could just as well not touch it I guess...
[22:03:32] <Dark_Shikari> Er....
[22:03:34] <Dark_Shikari> just replace the asm function
[22:03:45] <Dark_Shikari> you already read the asm anyways and copied it
[22:03:52] <Dark_Shikari> your change is eliminating the C part
[22:04:04] <BBB> the asm is different also
[22:04:12] <BBB> (and might well be slower)
[22:04:13] <Dark_Shikari> different != better
[22:04:15] <BBB> right
[22:04:21] <Dark_Shikari> I do not want you to make things slower
[22:04:28] <Dark_Shikari> this means you must demonstrate yours is faster
[22:04:41] <Dark_Shikari> the function consists of 4 parts:
[22:04:44] <Dark_Shikari> 1) horizontal sum/math
[22:04:46] <Dark_Shikari> 2) vertical sum/math
[22:04:51] <Dark_Shikari> 3) plane calculation
[22:04:53] <Dark_Shikari> 4) main loop
[22:04:54] <BBB> fair enough, I'll see when I get to that, so first c->asm and then assure which of the asms are faster
[22:05:02] <Dark_Shikari> all must be equal or faster in your function.
[22:06:07] <BBB> I gotta admit you guys are super-methodical
[22:06:10] <BBB> a little bit anal also
[22:06:33] <Dark_Shikari> tl;dr I don't want slower code
[22:06:40] <Dark_Shikari> You can start by porting yours to x264 and just plain timing it
[22:06:51] <Dark_Shikari> I don't trust timings unless they're done in exactly the same way
[22:07:10] <jannau> argh, /me suspects he knows why the h264 parser doesn't set convergence_duration
[22:07:43] <Dark_Shikari> BBB: I'm much more anal about these things when you're replacing something already believed to be 'good'
[22:07:44] <jannau> Dark_Shikari: is there a way to convert frame_num increments to time?
[22:07:54] <Dark_Shikari> poc.  not frame num.
[22:08:07] <Dark_Shikari> but why?
[22:08:39] <BBB> Dark_Shikari: got it, will do, don't expect it today though
[22:13:13] <jannau> recovery_frame_cnt is in frame_num increments: "All decoded pictures in output order are indicated to be (approx)  correct starting at the output order position of the reference picture having the frame_num equal to the frame_num of the VCL NAL units for the current access unit incremented by recovery_frame_cnt in modulo MaxFrameNum arithmetic."
[22:14:50] <Dark_Shikari> oh.  wow.  this means I have recovery_frame_cnt wrong in x264 if b-frames are on.
[22:15:04] <Dark_Shikari> let me fix that
[22:15:25] <astrange> ye5
[22:15:51] <Dark_Shikari> hmm.  it's not wrong, just overestimates.
[22:16:29] <Dark_Shikari> ok, I don't care about that anyways
[22:16:39] <Dark_Shikari> jannau: then h264 is incompatible with how ffmpeg (and x264) want it
[22:16:39] <jannau> could be wrong if you do the modulo MaxFrameNum
[22:16:59] <Dark_Shikari> the only way to handle it right is to do it in the decoder
[22:17:07] <Dark_Shikari> and tell the caller when it's converged
[22:53:19] <CIA-63> ffmpeg: michael * r25279 /trunk/libavutil/assert.h: typo
[23:21:54] <mru> does that mean he added a typo?
[23:44:10] <mru> am I the only one who thinks michael should follow the same rules as everybody else?
[23:44:41] <Dark_Shikari> he's the BDFL, he apparently makes the rules
[23:45:06] <mru> he also makes special rules for himself
[23:45:46] <spaam> special people need special rules..
[23:45:59] <mru> frankly, I think it's time he was removed from this "leader" position
[23:46:31] <ohsix> MUTINY!
[23:46:37] <mru> call it what you want
[23:46:45] <spaam> mru: so who will be the leader?  you?
[23:46:53] <mru> why do we need a leader?
[23:47:07] <ohsix> lord of the flies
[23:47:28] <mru> nothing would change, except that michael no longer has an excuse for being an arse and ignoring rules
[23:48:03] <spaam> did you try to say that to him?
[23:48:08] <mru> repeatedly
[23:48:49] <ohsix> will there still be rules when there is no leader
[23:49:07] <Dark_Shikari> woohooo
[23:49:12] <Dark_Shikari> now google comes to force webp into ffmpeg
[23:49:14] <mru> we will folow the rules we all make
[23:49:17] <Dark_Shikari> despite it not actually existing yet
[23:49:25] <Dark_Shikari> or supported by anyone besides google
[23:50:42] <Dark_Shikari> I think we should add support for file formats when they are used, not when they are declared to exist.
[23:50:52] <Dark_Shikari> (particularly encoding support)
[23:51:24] <ohsix> so are you the chicken or the egg
[23:51:39] <Dark_Shikari> there's no chicken/egg paradox.
[23:51:45] <Dark_Shikari> if for example, firefox said "we're supporting webp all the way"
[23:51:52] <Dark_Shikari> then you have the chicken.  now we can make the egg.
[23:51:57] <Dark_Shikari> But Mozilla rejected it.
[23:52:00] <Dark_Shikari> So now you have a dead chicken.
[23:52:04] <Dark_Shikari> And dead chickens can't lay eggs.
[23:52:13] <mru> we can have a bbq
[23:52:29] <Dark_Shikari> hmm, good point. dead chickens make for good sandwiches
[23:54:10] <BBB> "webp"?
[23:54:15] <BBB> what on earth are they smoking
[23:54:19] <BBB> is jpeg encumbered?
[23:54:25] <mru> no
[23:54:27] <BBB> or did one of their engineers have too much crackpot?
[23:54:30] <ohsix> jpeg is oldschool though
[23:54:41] <BBB> if it's old, it must be bad!12
[23:54:42] <mru> jpeg isn't exactly the most efficient format
[23:54:50] <Dark_Shikari> BBB: they are trying to push their shit on everyone else
[23:54:55] <ohsix> this sort of thing isn't unprecedented, during the jpeg2k stuff everyone had their pet image format, even microsoft
[23:55:04] <BBB> they all fail
[23:55:06] <mru> jpeg-xr
[23:55:06] <Dark_Shikari> ohsix: HD Photo was just an h264 ripoff though
[23:55:09] <Dark_Shikari> with i16x16 blocks only
[23:55:29] <Dark_Shikari> 09:55 < ubitux> revision 25278 has introduced some linkage error: ffmpeg/libavutil/libavutil.a(mathematics.o): In function `av_rescale_rnd' << undefined reference to `assert'
[23:55:32] <Dark_Shikari> lol michael broke things again
[23:55:47] <mru> as I said, he should follow the fucking rules
[23:55:52] <Dark_Shikari> BBB: pretty much.  this is getting really fucking obnoxious
[23:55:56] <ubitux> maybe it's something in mplayer i don't know
[23:56:00] <Dark_Shikari> I mean, first it was vp8
[23:56:01] <Dark_Shikari> then it was webm
[23:56:02] <Dark_Shikari> now it's webp
[23:56:07] <ubitux> but since there is some assert edit in ffmpeg
[23:56:09] <BBB> vp8 is fine
[23:56:13] <ubitux> ffmpeg still build correctly
[23:56:14] <Dark_Shikari> they're trying to use their own custom proprietary formats to displace everything
[23:56:21] <mru> ubitux: michael fuckedup
[23:56:23] <mru> again
[23:56:27] <ubitux> ok ok :p
[23:56:27] <skal> Dark: proprietary?
[23:56:38] * BBB will not update to latest svn for a while until assert.h is gone
[23:56:38] <Dark_Shikari> skal: absolutely.  it was developed without any community input or standardization process.
[23:56:41] <Dark_Shikari> Therefore, it's proprietary
[23:56:41] <ohsix> how stern was moz's rejection, if they've already got vpx there and someone prepares patches to add it to libpr0n are they just going to go with it?
[23:56:42] <mru> I already pointed out his stupid mistake
[23:56:45] <Dark_Shikari> proprietary is a development process
[23:56:47] <Dark_Shikari> not a state of being
[23:56:51] <skal> doesn't make it proprietary
[23:56:54] <Dark_Shikari> Google has declared that "this is webp"
[23:56:57] <Dark_Shikari> therefore, it's proprietary
[23:57:11] <Dark_Shikari> controlled by one company == proprietary
[23:58:05] <skal> launched by one company
[23:58:07] <skal> not owned
[23:58:10] <Dark_Shikari> no, controlled
[23:58:14] <Sho_> Dark_Shikari: Mozilla rejected it? link?
[23:58:23] <Dark_Shikari> How can you claim that google is not going to control this?
[23:58:25] <Dark_Shikari> you control vp8
[23:58:26] <Dark_Shikari> you control webm
[23:58:35] <Dark_Shikari> you haven't let anyone else have input into the standardization process
[23:58:45] <Dark_Shikari> if webp will be different, you need proof
[23:58:49] <mru> you mean bitstream guidance process
[23:58:53] <Dark_Shikari> lol
[23:59:09] <Dark_Shikari> Sho_: source is xiph.