[01:06] <BBB> michaelni: if its get_delay, I think this patch should fix it [01:06] <BBB> not sure, didnt have a ton of time to test [01:07] <BBB> will do over weekend or so... [01:09] <cone-197> ffmpeg.git 03Michael Niedermayer 07master:10012fa961a1: ffmpeg: Fix bitstream filters manipulating AVCodecContext [01:19] <michaelni> BBB, ok, thx, ill maybe do some testing as well [11:48] <J_Darnley> When writing a filter with audio input, is there a short hand way of saying it accepts "all sample formats" like there is for channel layouts and sample rates? [11:50] <wm4> hm, af_ashowinfo accepts everything [11:50] <wm4> but it just doesn't implement the format query fn [11:51] <J_Darnley> Oh, might it be ff_all_formats()? [11:51] Action: J_Darnley wonders how he failed to spot that. [11:52] <wm4> but depending on what you do, it's probably a bad idea to support all formats, just because you can handle all formats right now [11:52] <J_Darnley> Yes, there it is in concat, resample, pan, ... [11:52] <wm4> because someone could always add a really weird format that breaks everything in creative ways [11:52] <J_Darnley> True [11:53] <J_Darnley> You would need a test for an "unknown" format [11:53] <J_Darnley> because at the very least you would need to convert the data pointer into the correct type. [11:55] <J_Darnley> Then I think I will just make my example take a few explicitly defined formats [11:56] <wm4> sounds like a better idea, especially if it's example code (?) [16:44] <michaelni> Timothy_Gu, as you are maintainer now, you get OP in #ffmpeg-devel, also if anyone else is in MAINTAINERs and doesnt have op here, ping me [16:54] Action: michaelni wonder why cone isnt here [17:01] <j-b> michaelni: should come [17:25] <BtbN> Interesting. The hevc decoder is that big that i can't create a static ffmpeg.exe anymore. It fails to link it because stuff gets out of range for relative jumps. [17:25] <wm4> that must be a sucky linker [17:26] <BtbN> just normal gcc [17:26] <BtbN> http://bpaste.net/show/fNabl66Xjmu20ywlOOLA/ [18:35] <Daemon404> will swscale always bitshift while upsampling from e.g. 10 to 16 bits? [18:40] <wm4> hm, what else would it do? [18:40] <Daemon404> no idea [18:40] <j-b> magic [18:42] <wm4> libswscale is a software implementation of murphy's law, so I guess it's hard to tell what exactly it does [18:42] <wm4> weren't there complaints that it introduces bias? [18:42] <wm4> something about being too green? [18:44] <J_Darnley> IIRC you need to do something about the new low bits [18:45] <Daemon404> right [18:46] <J_Darnley> perhaps that IIRC should be "as I understand it" [18:46] <michaelni> if sws doesnt set the low bits correctly please open a ticket with testcase [18:47] <BtbN> what else than 0 should it set them to? [18:47] <J_Darnley> the most basic demonstration I can think of is: 255<<8 != 65535 [18:47] <J_Darnley> (not that I am saying that swscale does this) [19:08] <kierank> Daemon404: what do you want it to do [19:08] <Daemon404> no i was just asking [19:08] <Daemon404> easier than grepping swscale [19:08] <Daemon404> usually. [19:08] <kierank> swscale should shift iirc [19:08] <kierank> for yuv [19:08] <kierank> and for rgb it should shift and add [19:09] <Daemon404> i meant for yuv, so yeah [19:09] <Daemon404> are you back in the motherland yet kierank [19:09] <kierank> yes [19:09] <Daemon404> \o/ [19:10] <Daemon404> it is already getting too hot here. [19:10] Action: Daemon404 has to have a fan pointed at him at all times. [19:11] <kierank> had a lovely whale steak yesterday [19:11] <Daemon404> i saw [19:11] <Daemon404> lol [19:13] <kierank> norway is beatiful [19:13] <kierank> albeit expensive [19:13] <Daemon404> the nature photos you posted [19:13] <kierank> photos don't do it justice [19:13] <Daemon404> pretty much look like where i grew up in Canada :P [19:14] <Daemon404> 800km radius of nature around my hometown [19:14] <Daemon404> lakes, mountains, forest, etc [19:15] <Daemon404> did you see any maelstrom? [19:16] <kierank> duno [19:17] <kierank> the train into the mountains is crazy [19:17] <kierank> really crazy [19:17] <kierank> you see so much nature [19:17] <kierank> it's like the train in the hunger games [19:17] <kierank> that's the only way to put it [19:18] <Daemon404> :P [19:20] <cone-576> ffmpeg.git 03Carl Eugen Hoyos 07master:6ac3c8c6a0c6: Fix compilation with --disable-everything --enable-parser=vc1. [19:54] <cone-576> ffmpeg.git 03Marton Balint 07master:66f4891e6422: mpeg12enc: add support for PANSCAN side data in sequence_display_extension [19:54] <cone-576> ffmpeg.git 03Marton Balint 07master:9236f7b5a23b: mpeg12enc: add seq_disp_ext option for deciding when to write a sequence_display_extension [20:01] <Timothy_Gu> michaelni: thanks! [20:03] <BBB> that should clean things up a bit... [20:09] <Timothy_Gu> BBB: swri_resample() moves out of [20:09] <Timothy_Gu> resample_template.c into resample_template.c <--- this doesnt make sense [20:10] <BBB> oh [20:10] <BBB> I guess I should fix that [20:11] <BBB> fixed [20:22] <ubitux> https://github.com/alankila/Junk/tree/master/wav2png haha wat [20:31] <jamrial> BBB: why not use the macros from x86/cpu.h in swresample_dsp_x86_init()? [20:31] <Daemon404> ubitux, hand picked sample [20:31] <Daemon404> its a load of crap [20:31] <Daemon404> :D [20:34] <jamrial> well, they acknowledge as much [20:34] <jamrial> not only they call it a toy that only works with samples like the one they used. it's also part of a repository named "junk" :P [20:34] <Daemon404> lol [20:42] <cone-576> ffmpeg.git 03Ronald S. Bultje 07master:7128a35f8c4b: swr: split out DSP functions. [20:43] <Timothy_Gu> ironically, the "junk" repo has 44 stars and is the user's most popular repo [20:45] <wm4> 44 internet points [20:48] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:b065d0014be3: avcodec/ppc/idct_altivec: add plain idct() [20:52] <BBB> jamrial: no idea they existed [20:52] <BBB> jamrial: feel free to simplify and use the macros if you like that [20:53] <BBB> jamrial: I was thinking of actuall removing some inline asm now - sounds like a good time [20:53] <jamrial> cool [20:53] <BBB> or you could do it too, I think most of the digging is finished now [20:53] <jamrial> and yeah, there are macros for both external and internal checks [20:54] <BBB> aha [20:54] <BBB> ok [20:54] <Timothy_Gu> guys, what is the use of different idct implementations else than optimization? E.g. how is ipp better than faani, or how is simplemmx is better than xvidmmx? [20:54] <BBB> Timothy_Gu: idct isnt exactly defined [20:54] <BBB> Timothy_Gu: so each has slightly different output [20:54] <BBB> b/c of rounding etc. [20:54] <BBB> Timothy_Gu: so which one you want to use typically might depend on multiple factors [20:54] <BBB> most users just care about speed, but sometimes people want higher precision [20:54] <ubitux> yay, hq4x working. [20:55] <ubitux> ~150 lines [20:55] <ubitux> and i may be able to get it down to 100 lines [20:55] <ubitux> hq3x remaining [20:58] <BBB> whats hq4x? :-p [20:59] <jamrial> giving round corners to pixel art, basically :P [20:59] <Timothy_Gu> BBB: can you give a rough rank of precision of simple, faani, ipp, and int? [21:00] <BBB> jamrial: oh that, Ive seen that before, cool [21:01] <iive> imho, it could be quite useful for subtitle enlarging, dvdsub etc... [21:01] <BBB> Timothy_Gu: & like from the top of my head? no, not really& I can try to look up what they are exactly and which one is better or worse, whats the purpose? [21:02] <Timothy_Gu> none really, but i can document them so that other confused users can understand what the option is used for. [21:06] <BBB> ok I can try to figure out for a few of them, as far as I understand them [21:07] <ubitux> BBB: what i just sent [21:08] <BBB> how come the md5 of all filters is identical? [21:08] <Timothy_Gu> BBB: thanks! [21:08] <BBB> Timothy_Gu: do you have a list of all idcts you want information on? [21:09] <Timothy_Gu> From http://ffmpeg.org/ffmpeg-codecs.html [21:09] <Timothy_Gu> I assume that simple* is basically the same algo, so you dont need to test/look at them [21:10] <Timothy_Gu> *you only need to look at one of them [21:10] <ubitux> iive: heh yeah maybe; but... we need subtitles in libavfilter lalala here we go again [21:10] <Timothy_Gu> im not interested in sh4 or altivec either [21:11] <BBB> alpha/neon is also just arch-specific [21:11] <BBB> as is all the arm ones [21:11] <Timothy_Gu> so what's left is int, ipp, faani, xvidmmx, and simple [21:11] <BBB> sh4 same [21:11] <BBB> Ill look at simplemmx also [21:12] <BBB> I bet its not identical [21:13] <Timothy_Gu> i remember seeing somewhere that some functions of simplemmx is bit-identical with simple (C) [21:13] <BBB> the high bit ones likely aren't [21:13] <BBB> maybe the 8bit is [21:13] <BBB> the high bit ones are tricky, I remember that from prores [21:13] <kierank> Is Pierre-Edouard LEPERE on irc? [21:13] <BBB> you can get them bitexact but its slightly slower [21:13] <BBB> kierank: plepere [21:13] <kierank> ah not online currently [21:14] <kierank> I'm wondering why he uses 3 operand in his asm but then only defines sse4 [21:14] <BBB> not sure [21:14] <BBB> doesnt x86inc.asm take care of that? [21:14] <BBB> i.e. it automatically introduces a mova [21:15] <kierank> yeah but he only does INIT_XMM sse4 [21:15] <kierank> and doesn't do avx for some reason [21:15] <jamrial> in his latest patch he added an avx version for functions where he used three operand instructions [21:15] <jamrial> but before that use used mova + instruction. i was the one that merged them. at least in hevc_deblock.asm [21:16] <jamrial> i didn't touch hevc_mc.asm. kurosu did [21:18] <jamrial> hevc_mc.asm still needs some work. most functions there are ssse3, and a couple sse2 even. but they are all defined as sse4 [21:18] <kierank> ah [21:22] <michaelni> some of the simple idcts for arm arent identical to simple C in output [21:24] <michaelni> about precission, see libavcodec/dct-test --help [21:25] <michaelni> and the best idct to use in a decoder is one that matches the encoder [21:25] <michaelni> if a encoder used a "inaccurate" one, its better to use that same "inaccurate" one than a accurate one [21:27] <kierank> michaelni: should have let smarter comment [21:28] <michaelni> kierank, well i didnt push yet, i can wait [21:31] <michaelni> also, we have noone listed in MAINTAINERs for hevc, if someone, smarter? wants to maintain it, please say so or send patch for MAINTAINERs [21:31] <Timothy_Gu> michaelni: do you mean the "official" encoder when you say "encoder" or the lavc one? [21:31] <michaelni> I meant the encoder used to encode a specific file [21:32] <michaelni> if someone encodes foobar.mpg with a very inaccuarte IDCT, it can look bad when decoded with a accurate IDCT [21:33] <Timothy_Gu> how do you know which idct the file used? especially for codecs like MPEG-4 [21:34] <michaelni> some encoders leave their name & version in the file in user data in the video stream or metadata in the container or cna be identified from the used fourcc in avi [21:34] <michaelni> libavcodec generally tries to use a matching idct when it can figure out that one would be better [21:35] <michaelni> an example for this is FF_IDCT_XVIDMMX [21:36] <Timothy_Gu> OK, thanks alot for the information [21:36] <michaelni> np [21:36] <kurosu> last bench on mpeg2 was xvid idct > simple idct, but that's mostly because the former is sse2 [21:36] <kurosu> the AAN one I think is mostly historical [21:36] <Timothy_Gu> one last question: can you give some common use case for each idct? [21:37] <kurosu> idct should match forward dct, in particular for temporal prediction [21:38] <kurosu> otherwise you get drift, even if you acertain your idct conforms to the max/average requirements in some mpeg specs [21:38] <michaelni> no, you get drift if the idct in the encoder and the idct in the decoder mismatch [21:39] <Daemon404> Timothy_Gu, http://guru.multimedia.cx/the-mpeg124-and-h26123-idct/ [21:39] <Daemon404> michaelni's own post [21:40] <nevcairiel> in practice, idcts are not "special", all you have to do is match the algorithm used in the encoder [21:40] <nevcairiel> and every implemented idct does that for some codec [21:40] <Daemon404> "all you have to do" [21:40] <michaelni> the dct in the encoder could significnatly mismatch the idcts and it should still not drift as the encoder always performs the mc+idct steps from the decoder so their intenal state should not drift apart [21:40] <Daemon404> because its so simple! [21:40] Action: Daemon404 runs [21:40] <nevcairiel> Daemon404: just because you failed with your latest codec endavour [21:40] <JEEB> and this, boys and girls, is why AVC and HEVC have bit-exact specified IDCTs [21:41] <Daemon404> nevcairiel, technically kostya used simple_idct :P [21:42] <nevcairiel> and luckily what JEEB said, modern codecs got smarter and figured out that its useful to specify the idct [21:42] <nevcairiel> in mpeg2 it was implementation dependendent, which kinda sucked [21:42] <kurosu> jamrial, the hevc_mc.asm is very very wrong - but it actually does not matter [21:43] <kurosu> the effort to fix it has probably an equivalent magnitude to rewriting it [21:43] <J_Darnley> Wow. I didn't expect to see IDCTs discussed in 2014 [21:44] <nevcairiel> blame Timothy_Gu [21:44] <Daemon404> J_Darnley, how else would someone learn the basics? [21:44] <J_Darnley> Good point [21:44] <J_Darnley> I only learned the same things from using DGDecode [21:45] <JEEB> all these animoos on my screen, they're there thanks to it 8) [21:45] <Daemon404> oh holy shit, michaelni's blog was updated twice this year [21:45] <Daemon404> and i missed it because planet doesnt track it anymore [21:45] <Daemon404> :< [21:45] <Daemon404> J_Darnley, bad ida [21:45] <Daemon404> dgdecode code base is so terrible [21:46] <Daemon404> (fyi i replaced dgdecode with a ffmpeg-based d2v reader :P) [21:48] <llogan_> kierank: where did you ride to and from on the train in Norway? [21:48] <kierank> llogan_: oslo to bergen [21:48] <kierank> bergensbanen [21:48] <jamrial> the last blog entry is about ffhufffyuv, and gives some numbers. wonder if it changed after kurosu's work from the past few weeks [21:49] <Daemon404> gmx too [21:50] <llogan_> fun. i went from trondheim to oslo (partially by bus). some parts reminded me of home, but it was so much cleaner. no yard refrigerators. [21:51] <llogan_> a beer costs at least 2x though. [21:52] <J_Darnley> Daemon404: I didn't (and probably still don't) care what the code base was like. [21:53] <Daemon404> heh [21:54] <J_Darnley> It must have been 10 years since I first used it. [21:55] <J_Darnley> Maybe not quite [21:56] <J_Darnley> It was probably on my first DVD rip. Futurama. It want alright apart from the interlacing. [21:57] <J_Darnley> *it went [21:57] <kurosu> jamrial, maybe 10% better for decoding - but most of my test files were actually low entropy <-> short codes, therefore less memory-bound [21:57] <kurosu> on one of those test files, random changes can cause a 5% speedup, but there's no way to control it :( [22:00] <kurosu> when looking at how utvideo encoded inexisting values, I saw there was assembly for the vlc, but I really don't want to go down that road [22:00] <kurosu> I don't think there's much to improve in the encoder, except for context=1 multithreading [22:01] <llogan> so that's what my quit message is. how dumb. [22:50] <kierank> what does "epel" refer to? [22:50] <kierank> oh eighth [22:50] <kierank> duh [22:54] <cone-576> ffmpeg.git 03Lou Logan 07master:3fc37a3d2f13: doc/filters: remove double quotes from zoompan example [22:59] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:d82ecfce07d1: cmdutils: implement FFREPORT=level=... [23:09] <llogan> michaelni: seeing cmdutils reminds me that there is a trivial patch involving it in ML: "version string: add copyright line to version string" [23:33] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:378ad2249231: ffmpeg: print values of mismatching has_b_frames [23:33] <cone-576> ffmpeg.git 03Michael Niedermayer 07master:5ded0b390b61: ffmpeg: for h264 we need has_b_frames from the decoder [23:36] <michaelni> llogan, yes, should it be applied ? if so dont hesitate to apply [23:44] <kierank> gah why can changing hevc asm break resample [23:45] <kurosu> kierank, hevc asm clobbers some regs it doesn't declare as using? [23:46] <kierank> literally all i've done is move the init_xmm below and got rid of the sse4 name in the table [23:46] <kierank> and resample breaks [23:46] <kurosu> ok then that's too small a change to cause that at first guess [23:49] <kurosu> kierank, was it passing before *with* resampling ? [23:49] <kierank> http://pastebin.com/kLXXQvKV is all i did [23:50] <kierank> hmmm breaks from git as well [23:52] <kurosu> so your test was already broken even before your change ? [23:54] <kurosu> beware than in some places, widths are not multiple of 4 (eg 2/6) and so pextrw is used [23:54] <kurosu> though that should only happen for epel, indeed [23:54] <kurosu> but for those sse4 is needed [23:55] <kurosu> *that in some places [23:56] <kierank> dunno but on my machine i've always had fate fail sometimes [23:56] <kierank> I remember why at some point [23:56] <kierank> I'll* [23:56] <kurosu> hevc or ? [23:56] <kierank> random tests [23:56] <kierank> just used to fail [23:56] <kierank> there was a reason iirc [23:57] <kurosu> overheating would cause errors only with simd code on a pc I had [23:59] <kurosu> btw, openhevc intrinsic code is really faster - like 3-5% overall [23:59] <kurosu> I didn't even start to study why [23:59] <kierank> dunno [00:00] --- Sun Jun 15 2014