[Ffmpeg-devel-irc] ffmpeg-devel.log.20140614

[burek]

[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