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

[burek]

[00:33] <J_Darnley> What was that joke RFC?  IP over Carrier Pigeon?
[00:33] <nevcairiel> IP over Avian Carriers
[00:34] <nevcairiel> RFC 1149
[00:34] <J_Darnley> :)
[01:29] <BBB> J_Darnley: well Im taking advantage of the convention that all 4byte operations zero the upper four bytes (i.e. auto zero extend)
[01:31] <Daemon404> Timothy_Gu, fyi: in 109 of libx265.c
[01:31] <Daemon404> ctx->params->frameNumThreads = avctx->thread_count;
[01:31] <Timothy_Gu> yeah?
[01:31] <Daemon404> something to point to rather than benchmarks
[01:31] <Daemon404> is all
[01:35] <Timothy_Gu> you can add a link to that in the ticket. im too lazy to do it myself :)
[01:36] <J_Darnley> BBB: I didn't see anything else when I was looking and it compiled without complaint.
[01:36] <J_Darnley> ... but I couldn't test it (patch didn't apply cleanly).
[01:37] <J_Darnley> If you have a public repository somewhere, I will clone it tomorrow and try actually running it and do some debugging.
[02:05] <BBB> J_Darnley: https://github.com/rbultje/ffmpeg/tree/swr
[03:42] <jamrial> BBB: fixed the win64 crash
[03:42] <BBB> \o/
[03:42] <jamrial> you were doing "mov ctxq, r0mp" before PUSH r3
[03:42] <jamrial> ctx is r3
[03:43] <BBB> ...
[03:43] <BBB> *headbump*
[03:43] <jamrial> :P
[03:44] <BBB> ok pushed that to github then
[03:44] <jamrial> anyway, try doing some benchs on your end. i got some really weird results on my linux x64 vm
[03:44] <BBB> so speed is slower?
[03:44] <BBB> Ill do a few tomorrow
[03:44] <BBB> I havent done anything on that end, just random instruction sequences that work in terms of md5
[03:44] <jamrial> on my second try (win32 and linxu x64 on ubitux's box) it was slightly slower
[03:44] <BBB> well slower isnt good, it should be faster :-p
[03:45] <BBB> Ill have a look, thanks for testing anyway& youre just using a long mp3 -af & right?
[03:45] <BBB> or is there a long test sequence I can use?
[03:45] <BBB> like testsrc or so
[03:45] <jamrial> a 22 minutes aac 44khz into 48khz
[03:47] <jamrial> a very long Dream Theater song :P
[03:47] <BBB> I see
[03:47] <BBB> ok Il use something similar'ish
[03:47] <BBB> bbl, test tomorrow
[03:47] <jamrial> ok, later
[04:21] <BBB> jamrial: did you test avx? or just win64?
[04:21] <BBB> (or has anyone tested the avx?)
[04:32] <cone-958> ffmpeg.git 03Michael Niedermayer 07master:1caedf629a06: avcodec/ituh263enc: fix advanced intra coding
[04:42] <jamrial> i tested avx and it fate passes
[11:41] <J_Darnley> BBB: I apologise that this sounds really stupid but, how do I test your resample re-write?
[11:42] <J_Darnley> More than just using -ar and ffmpeg?
[11:55] <cone-471> ffmpeg.git 03Diego Biurrun 07master:97578f5f3b27: build: Add missing object file for Matroska demuxer
[13:00] <BBB> J_Darnley: I think you take a long music sample and you play it, and then resample (using e.g. ffmpeg -i audiofile -af aformat=fltp,aresample=some_value:internal_sample_fmt=fltp -f null -)
[13:02] <BBB> then run that in a debugger or so to ensure it really hits that function, and then put START/STOP_TIMER around the function call in resample.c (*consumed = c->dsp.resample_common[fn_idx](c, dst, src, dst_size, update_ctx);, line 301) or time the whole ffmpeg run, before and after patch
[13:02] <BBB> (the timing is obviously not in a debugger)
[13:03] <J_Darnley> Ah planar, that might help
[13:10] <J_Darnley> Well... I doesn't crash
[13:11] <J_Darnley> gdb reaches the breakpoint I set in ff_resample_common_float_sse
[13:18] <BBB> ok then youre fine
[13:18] <BBB> so go out of debugger and time the function calls or the executable runtime :)
[13:19] <J_Darnley> Yeah, its running
[13:20] <J_Darnley> with your patch: 11479 decicycles in resample, 698905 runs, 349671 skips
[13:20] <J_Darnley> (that's a lot of skips)
[13:21] <ubitux> (there is no threading involved, right?)
[13:21] <J_Darnley> Almost certainly, ffmpeg uses threads all over the place
[13:22] Action: J_Darnley reconfigures
[13:35] <J_Darnley> ugh, that's not any better
[13:35] <J_Darnley> without patch: runtime 14.98, 10594 decicycles in resample, 698947 runs, 349629 skips
[13:38] <J_Darnley> with patch: runtime 15.89, 11006 decicycles in resample, 698933 runs, 349643 skips
[13:42] <J_Darnley> I'll be right in a short while.
[13:42] <J_Darnley> um
[13:42] <J_Darnley> I'll be back in a short while.
[14:29] <BBB> ok new patch on github
[14:29] <BBB> for me its a lot faster
[14:29] <BBB> (I added some loop aligns)
[14:53] <BBB> maybe llvm just sucks
[14:53] <cone-471> ffmpeg.git 03Anshul Maheshwari 07master:36393434782b: ffmpeg: fix memleak and corruption of AVSubtitle with multiple outputs
[15:04] <J_Darnley> FYI: you have left timer macros in it.
[15:04] <BBB> in a top patch, to make it easier to reproduce my testing
[15:05] <BBB> you can remove the patch if you dont like it :)
[15:05] <BBB> I wonder if llvm is really that bad
[15:05] <J_Darnley> No I don't mind, I just saw them when git said I had come conficts to merge
[15:07] <J_Darnley> dammit git!
[15:09] <J_Darnley> uh
[15:09] <J_Darnley> is 520 decicycles right?
[15:11] <J_Darnley> Maybe that's just your TIMER2 macro
[15:13] <J_Darnley> With the usual STOP_TIMER() macro I get the same speed
[15:19] <J_Darnley> without patch: runtime 13.29, 10466 decicycles
[15:19] <J_Darnley> with patch: runtime 14.07, 11011 decicycles
[15:38] <BBB> J_Darnley: you had massive numbers of skips, right?
[15:38] <BBB> thats b/c the number of samples per run varies
[15:38] <BBB> so I changed it to measure per-sample speed (thats my custom macro)
[15:39] <BBB> then number of skips is minimal
[15:39] <BBB> and yes per-sample cycle count is expected to be much smaller
[15:41] <J_Darnley> that makes sense
[15:42] <J_Darnley> I will re-run shortly
[15:50] <BBB> yeah total runtime is also faster for me
[15:50] <BBB> I wonder if its compiler or something else...
[15:50] <BBB> can I see disassembly pooped out for the inline asm functions for you?
[15:50] <BBB> and which compiler?
[15:55] <ubitux> you can use asetnsamples to control the number of samples going into aresample
[15:56] <ubitux> but i guess the internals split them again
[15:56] <ubitux> swr internals*
[16:07] <BBB> I get near-zero skips with this adaptation, versus about 50% skips before
[16:07] <BBB> so I think this is ok
[16:08] <BBB> 12.9sec -> 12.3sec total runtime (linear)
[16:08] <BBB> or 10.1 -> 9.6 (non-linear)
[16:08] <BBB> on 32bit, but I guess its the same for 64bit
[16:09] <BBB> commandline: ./ffmpeg -i /tmp/x.wav  -af aformat=fltp,aresample=48000:internal_sample_fmt=fltp[:linear_interp=1] -f null -nostats -v error -
[16:09] <BBB> where the stuff [] is only for linear
[16:09] <BBB> x.wav is a one-hour mp3 file transcoded to wav to decrease runtime spent in mp3 decoding
[16:13] <J_Darnley> BBB I'll post those a little later  I'm about to go out.
[16:13] <BBB> ty
[16:13] <J_Darnley> But I am using cygwin's gcc 4.8.2 or .3
[17:05] <cone-471> ffmpeg.git 03Michael Niedermayer 07master:a2de7b1bd504: avcodec/bitstream: document the double volatile
[17:05] <cone-471> ffmpeg.git 03Michael Niedermayer 07master:5ab51f753583: avcodec/libtwolame: fix encoding lsf with defaults
[18:55] <J_Darnley> BBB: I have what you asked for.
[18:56] <J_Darnley> It is gcc 4.8.3
[18:57] <J_Darnley> and here is the output of objdump: http://pastebin.com/xBGpS3zZ
[19:33] <cone-471> ffmpeg.git 03Clément BSsch 07master:ded3c9fd32af: avfilter: add hqx filter (hq2x, hq3x, hq4x)
[19:39] <wm4> ubitux: :D
[19:40] <ubitux> :)
[19:40] <ubitux> i'm almost done writing about it for the curious
[19:47] <Compnn> ubitux : nice job on hqx stuff :)
[19:47] <Compnn> hows it look compared to lanczos ? :P
[19:48] <Compnn> on real video not ... pixel art
[19:48] <Compnn> i think hq2x is also used on video games , emulators etc ?
[19:48] <Compnn> maybe its useful to those x264 guys
[19:49] <ubitux> try it
[19:49] <ubitux> but it will probably be a very ugly scale
[19:50] <ubitux> Compnn: hqx should be compared to xbr or stuff like http://research.microsoft.com/en-us/um/people/kopf/pixelart/
[19:54] <j-b> how does it improve the old DivX blocks?
[19:56] <ubitux> lol
[19:57] <j-b> :D
[20:00] <wm4> j-b: use libpostproc and vf_spp
[20:01] <wm4> vf_fspp that is
[20:01] <wm4> because supposedly that's the reason why these can't be deleted
[20:01] <ubitux> 02:17:20 < michaelni> matrixbench_mpeg2.mpg -vf scale=320:240,format=monow,spp=6:63,hqx=4
[20:01] <ubitux> ;)
[20:01] <j-b> wm4: libpostproc is too old and really not good
[20:02] <wm4> ubitux: format=monow
[20:02] <wm4> wat
[20:02] <j-b> wm4: fspp?
[20:02] <wm4> j-b: some old libmpcodec crap filter
[20:02] <wm4> I think this one uses snow ;D
[20:02] <ubitux> no, uspp is snow
[20:03] <wm4> oh
[20:03] <ubitux> fspp is just a "fast" version of spp
[20:03] <ubitux> (fast but different)
[20:03] <wm4> lol
[20:03] <wm4> anf vf_spp which was ported is not enough?
[20:03] <wm4> I don't get this
[20:03] <j-b> wm4: but seriously, a lot of the 200x DivX/Xvid around look very very bad on our HD screens
[20:03] <ubitux> well it's probably not fast enough ;)
[20:04] <wm4> j-b: no doubt
[20:04] <wm4> ubitux: having dozens of pp filters is not useful...
[20:04] <ubitux> wm4: let's add another one to rule them all
[20:04] <wm4> users will have no idea which one to use in the first place
[20:04] <wm4> so pick a good one and delete the rest as useless
[20:04] <ubitux> probably depends on source and settings
[20:05] <j-b> I agree with my enemy wm4 on this :)
[20:05] <wm4> enemy? :(
[20:05] <j-b> wm4: lol :)
[20:05] <j-b> One good pp filter would be nice
[20:05] <ubitux> spp isn't good?
[20:05] <wm4> ubitux: we don't know
[20:05] <iive> spp uses 2d (i)dct, fspp uses a series of 1D (i)dct's
[20:05] <wm4> I haven't really seen convincing results from them whenever I tried, either
[20:06] <j-b> me neither
[20:06] <j-b> gradfun and yadif are amazing piece of filter code, but for pp, it's disappointing for users
[20:06] <iive> spp is excellent, but it is kind of slow.
[20:06] <wm4> michaelni: you probably know most about these pp filters, your opinion?
[20:07] <iive> gradfun and yadif and not postprocessing filters.
[20:07] <wm4> j-b: I often see gradfun being ridiculed for being crap
[20:07] <j-b> wm4: I see that too. But I disagree. It works wonders for anime and ocean-movies.
[20:08] <j-b> it's crap if people apply it everywhere, like Complex Sharpen 2 :)
[20:09] <j-b> iive: how slow?
[20:09] <iive> j-b: it does about 64 2d fdct and idct for every block.
[20:09] <iive> at the maximum (6) level.
[20:11] <michaelni> spp with the right parameters can make old low bitrate files look much nicer then without
[20:12] <iive> it is also an excellent non-temporal denoiser 
[20:12] <iive> btw, I wonder if maybe h264 8x8 dct would give slightly better results when h264 video is handled. (and speed wise)
[20:15] <cone-471> ffmpeg.git 03Carl Eugen Hoyos 07master:29fc468d0a22: Do not show libzvbi in the configure output if it was not enabled.
[20:15] <cone-471> ffmpeg.git 03Carl Eugen Hoyos 07master:e3fd263f0b73: Show duration for large asf files as written in the file header.
[20:31] <ubitux> https://news.ycombinator.com/item?id=7925671 here you go
[20:38] <cone-471> ffmpeg.git 03Michael Niedermayer 07master:dc5972f88601: avformat/flvdec: give live_flvdec a separate name
[21:06] <Daemon404> [19:07] <@iive> gradfun and yadif and not postprocessing filters. <-- gradfun can be used just fine as a postprocessng filter
[21:06] <Daemon404> during playback
[21:06] <Daemon404> its used to be quite popular to do so
[21:07] <Daemon404> unless youre using a strict definition of 'post process' so as not to be 'process post encoding'
[21:07] <iive> yes i do
[21:07] <iive> i mean post processing that hides encoding artifacts. like blocking and ringing.
[21:08] <Daemon404> gradfun can hide banding
[21:08] <Daemon404> thats what people use it for during playback
[21:08] <iive> while banding could be considered encoding artifact...
[21:08] <Daemon404> it de-facto *is*
[21:08] <Daemon404> common artefact of dct
[21:08] <Daemon404> on flat areas
[21:09] <iive> still, gradfin is not replacement for postprocessing filter, it could be used in addition to one.
[21:10] <Daemon404> it IS a postprocessing filter, by definition
[21:10] <Daemon404> just because libpp is a deblocker, doesnt mean thats all pp is
[21:10] <Daemon404> >the english language
[21:12] <iive> every filter applied in video chain is post processing, because it is processing post decoding
[21:12] <Daemon404> yes
[21:12] <iive> however postprocessing have its own meaning, more specific than the english word.
[21:12] <Daemon404> more specifcally, in this particular multimedia scene, it is applied to playback filters
[21:13] <Daemon404> [20:12] <@iive> however postprocessing have its own meaning, more specific than the english word <-- yes and the one you refer to you are taking from a set of filters that smply used the word since it was convenient
[21:13] <Daemon404> they were not named as such due to a definition postprocess
[21:13] <Daemon404> you have cause and effect mixed up here
[21:13] <iive> no, you ignore it, just to have something to argue about.
[21:14] <Daemon404> what the fuck?
[21:14] <iive> have a nice day.
[21:14] <Daemon404> ...every time you speak, you somethign fuckign retarded
[21:14] <Daemon404> for real
[21:15] <Daemon404> youre the only person in ere i get the urge to stab in the face on a regular basis
[21:15] <ubitux> haha
[21:17] <iive> wasn't Daemon404 the one explaining what decimation means, and how we should be using it like avisynth and not use it for what decimation word really means?
[21:18] <ubitux> that's indeed another topic where you fight with him
[21:25] <J_Darnley> You mean reducing by one tenth?
[21:25] Action: J_Darnley runs
[21:25] <iive> yes.
[21:25] <ubitux> "I asked the author, he apparently made the entire unrolled table by hand."
[21:26] <ubitux> holy shit.
[21:26] <J_Darnley> :O
[21:37] <jamrial> [NULL @ 00000000004c4880] [IMGUTILS @ 000000000032b140] Picture size 27792x16128
[21:37] <jamrial> probably a bit too big source for hqx4 :p
[21:39] <jamrial> sorry, full error was "Picture size 27792x16128 is invalid"
[21:40] <ubitux> :)
[21:42] <jamrial> source was http://lego.wikia.com/wiki/File:MegaManMix.png that, if you're curious
[21:43] <jamrial> hqx2 and hqx3 work, but ffmpeg eats ~2gb of ram
[21:47] <ubitux> aw. 
[21:47] <ubitux> strange, i'm not doing much with memory
[21:49] <wm4> <jamrial> sorry, full error was "Picture size 27792x16128 is invalid"
[21:49] <wm4> fixing this is hard
[21:50] <wm4> it's a big mess :(
[21:52] <nevcairiel> this one you could probably fix by simply taking bitdepth into account
[21:52] <nevcairiel> and not assuming 8 bytes per pixel
[21:53] <nevcairiel> but i guess the function doesnt know the bitdepth, and adding it is a API break
[21:53] <anshul> Michlani, page_segment and end_segment can be called multiple times in a single call to dvbsub_decode. This will not cause save_subtitle_set() to be called multiple times.      since that function is called optionaly   according to compute edt value
[21:53] <wm4> nevcairiel: yeah, that's a problem too
[21:54] <jamrial> i posted that as a curiosity. doubt anyone will actually have a legit use for hqx4 with 6948×4032 images
[21:57] <wm4> hm yes, but in general this is a problem
[21:58] <wm4> high res images can easily reach these resolutions
[21:59] <BBB> J_Darnley: ty!
[22:00] <BBB> the main difference appears to be that it saves more stuff in intermediate registers than straight from-memory operations
[22:00] <BBB> J_Darnley: so if thats true, then on a 32bit build, we should already be faster than the code that gcc-4.8.3 generates, only on 64bit is it faster, can you test that?
[22:02] <michaelni> anshul, if tehre are 2 DVBSUB_PAGE_SEGMENT, dvbsub_parse_page_segment will be called twice
[22:03] <michaelni> and it will call save_subtitle_set() twice if compute_edt == 1
[22:03] <michaelni> and if there are 2 DVBSUB_DISPLAY_SEGMENT, dvbsub_display_end_segment will be called twice
[22:03] <michaelni> and it will call save_subtitle_set() twice if compute_edt == 0
[22:09] <anshul> Michaelni,In my last patch I moved ffswap in dvbsub_decode but for memleak I will have to add more code
[22:10] <anshul>  I do need one sample having such segments, without them its difficult   for me.
[22:12] <J_Darnley> BBB: probably.  You want me to compare your patch vs. not on 32-bit cygwin, right?
[22:12] <michaelni> anshul, i understand but i dont have such sample
[22:12] <J_Darnley> that is basically 32 bit windows anyway
[22:15] <anshul> I am comparing data size and    ret values because if I dont do that way then parse_end_segment update datasize to 0 while actually it should be 1
[22:18] <anshul> To set datasize only in save_subtitle_set I have to put it in ctx or increase one parameter of some functions, before I was trying to solve with minimum changes.
[22:25] <michaelni> theres also the "got_segment == 15 && sub" case that overrides data_size, i think this too can cause it to become wrong
[22:25] <michaelni> before the patch this couldnt execute when the other case did i think
[22:34] <cone-471> ffmpeg.git 03Clément BSsch 07master:4d8fc0e08828: avfilter/hqx: unroll the pattern calculation
[22:34] <cone-471> ffmpeg.git 03Clément BSsch 07master:79198cb65a0b: avfilter/hqx: add some self promotion in doxy.
[22:39] <BBB> J_Darnley: yes
[22:41] <J_Darnley> 32-bit, cygwin x86, gcc 4.8.3
[22:41] <J_Darnley> without patch: 13.74 runtime, 535 decicycles/sample in float_resample, 1048484 runs, 92 skips
[22:41] <J_Darnley> with patch: 14.07 runtime, 543 decicycles/sample in float_resample, 1048448 runs, 128 skips
[22:42] <BBB> :(
[22:42] <BBB> weird
[22:42] <BBB> ok
[22:42] <J_Darnley> I also pulled in the latest changes from github
[22:42] <BBB> thanks, Ill look what it does
[22:42] <BBB> its clearly not just register pre-loading
[22:43] <J_Darnley> You want the objdump again?
[23:09] <cone-471> ffmpeg.git 03Carl Eugen Hoyos 07release/1.2:6011b806dd5d: Show duration for large asf files as written in the file header.
[23:09] <cone-471> ffmpeg.git 03Carl Eugen Hoyos 07release/2.1:f3802aa3250c: Show duration for large asf files as written in the file header.
[23:09] <cone-471> ffmpeg.git 03Carl Eugen Hoyos 07release/2.2:52572ca1b339: Show duration for large asf files as written in the file header.
[23:25] <cone-471> ffmpeg.git 03Michael Niedermayer 07master:04776cedec82: avfilter/avf_showspectrum: fix macro ()
[23:25] <cone-471> ffmpeg.git 03Michael Niedermayer 07master:84de3ed795d0: avfilter/deshake_opencl: fix macro ()
[23:28] <michaelni> ubitux, your fate valgrind client doesnt like your hqx filter http://fate.ffmpeg.org/report.cgi?time=20140621205440&slot=x86_64-archlinux-gcc-valgrindundef
[23:28] <ubitux> mmh
[23:29] <ubitux> that wouldn't be a problem in swscale right?
[23:30] <michaelni> could be, didnt really look at it
[23:31] <BBB> J_Darnley: hm& that might be useful yes
[23:31] <BBB> J_Darnley: theres definitely a few differences, I have to test how relevant each of them is
[23:32] <ubitux> michaelni: i wonder if it doesn't like the resolution change
[23:34] <ubitux> michaelni: that seems related to it indeed
[23:35] <ubitux> michaelni: and i can't reproduce with -cpuflags none
[23:35] <ubitux> "valgrind ./ffmpeg_g -i ~/fate-samples/filter/pixelart%d.png -vf hqx=3 -f null -" vs "valgrind ./ffmpeg_g -cpuflags none -i ~/fate-samples/filter/pixelart%d.png -vf hqx=3 -f null -"
[23:36] <ubitux> individual pixelart*png don't triggers it
[23:36] <ubitux> so it's related to the resolution change
[23:37] <michaelni> maybe its rescaling 
[23:37] <michaelni> from one res to another
[23:39] <michaelni> also it might be a false positive (not that i have evidence just saying as there sure is code that overreads)
[23:40] <michaelni> overread the odd size usig the padding that is
[23:40] <ubitux> i have no idea how the reconfiguration of sws works and is actually triggered
[23:41] <wm4> why would there be any scaling, other than hqx3 itself
[23:42] <ubitux> rgba ’ bgra maybe
[23:42] <ubitux> (png outputs rgba, filter takes bgra)
[23:43] <ubitux> it's strange that the issue is not reproducible with hq2x and hq4x though
[23:55] <ubitux> it's fun that it's not reproducible with -cpuflags none, but with optimizations the issue happens in yuv2bgra32_full_X_c
[00:00] --- Sun Jun 22 2014