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

[burek]

[00:01:45 CEST] <llogan> BBB: do you have an example command I can try with colorspace? i can only get "Failed to inject frame into filter network: Invalid argument"
[00:02:23 CEST] <BBB> you didnt set the output colorspace
[00:02:44 CEST] <BBB> try ffmpeg -i bt2020_to_bt709.mp4 -vf colorspace=trc=smpte240m:primaries=smpte240m:range=jpeg:space=smpte240m -f null -
[00:03:36 CEST] <BBB> you can also try -vf colorspace=format=yuv420p12:trc=bt2020-12:primaries=bt2020:range=jpeg:space=bt2020ncl
[00:03:45 CEST] <BBB> I agree the filter isnt terribly user-friendly
[00:04:08 CEST] <BBB> like, it would be nice to not have to repeat yourself 4x and so on, thats in the FIXME list on top of vf_colorspace.c
[00:04:36 CEST] <nevcairiel> could use a kind of preset for common combinations
[00:04:41 CEST] <llogan> by the way applying the patch complained about some whitespace somewhere.
[00:04:56 CEST] <llogan> <- Mr. Useful
[00:06:14 CEST] <BBB> llogan: thanks, fixed in https://github.com/rbultje/ffmpeg/tree/colorspace
[00:06:32 CEST] <BBB> (https://github.com/rbultje/ffmpeg/commit/7e8001142929e8ff39362647dcea011f92ba1827)
[00:06:55 CEST] <BBB> nevcairiel: yes thats what colormatrix does (although thats the only way to use it, which is limiting and sometimes wrong)
[00:07:26 CEST] <BBB> nevcairiel: Ill try to make it work and have it be correct in the normal cases
[00:08:58 CEST] <BBB> I guess some error messages would also help (please set property X) instead of just returning EINVAL
[00:09:06 CEST] <BBB> anywya, gotta go home
[00:30:54 CEST] <BBB> llogan: Ill add some doxy for the filter if the general idea is ok with people
[00:32:40 CEST] <durandal_170> check return of ff_get_video_buffer?
[00:40:01 CEST] <nevcairiel> so watching a video about the new windows subsystem for linux, if this stuff actually works properly and clang for windows also starts becoming reliable, i could finally get rid of all this msys and mingw crap, this  would be a good day indeed
[00:41:14 CEST] <wm4> heh
[00:42:40 CEST] <Gramner> GNU/Windows
[00:43:04 CEST] <nevcairiel> noone would have ever believed them if the announcement would have been tomorrow
[00:43:11 CEST] <nevcairiel> its just too crazy
[00:43:15 CEST] <Gramner> yeah
[00:43:46 CEST] <nevcairiel> emulating unix syscalls in the windows kernel, running ELF binaries
[00:43:56 CEST] <wm4> oh so it uses elf?
[00:44:04 CEST] <nevcairiel> its unmodified ubuntu binaries
[00:44:07 CEST] <nevcairiel> apt-get and all
[00:44:08 CEST] <wm4> does it emulate the linux abi?
[00:44:14 CEST] <wm4> woah
[00:44:21 CEST] <wm4> the linux abi is pretty crazy
[00:44:29 CEST] <wm4> because it used to emulate other commcerical unixes
[00:44:34 CEST] <wm4> depending on platform
[00:44:35 CEST] <Gramner> i wonder if you can get better performance with that compared to native windows binaries
[00:45:06 CEST] <nevcairiel> i would be happy if fork is implemented fully and bash scripts just run fast
[00:45:07 CEST] <wm4> but this also definitely means you can't load DLLs into such procsesses
[00:45:27 CEST] <nevcairiel> no, loading windows dlls wouldnt work, but I would be happy if it can launch windows processes
[00:45:35 CEST] <j-b> it can.
[00:45:59 CEST] <nevcairiel> although translating the pathes around again would be a fun thing to do
[00:46:00 CEST] <smarter> what if you run windows dlls through wine through windows ? :)
[00:46:07 CEST] <wm4> hope will they map the filesysten
[00:46:15 CEST] <wm4> might be worse than with msys/cygwin
[00:46:16 CEST] <nevcairiel> windows drives are in /mnt/c/ etc
[00:46:24 CEST] <Gramner> C: was under /mnt/c/ in the ms demo
[00:46:39 CEST] <wm4> smarter: linux binaries can't use wine as a library
[00:46:57 CEST] <nevcairiel> wm4: tell that to mplayer using wine to run windows codecs
[00:47:12 CEST] <wm4> nevcairiel: mplayer uses a very old hacked wine copy
[00:47:27 CEST] <wm4> when coreavc was still the best thing ever this was a problem
[00:47:35 CEST] <wm4> someone even wrote some sort of wine codec server
[00:47:42 CEST] <wm4> to run coreavc on linux with mplayer
[00:47:45 CEST] <nevcairiel> anyway if you limit yourself to relative paths, building with a windows compiler from this linux shell should in theory work
[00:47:59 CEST] <nevcairiel> or maybe its super smart and translates paths for you
[00:48:02 CEST] <nevcairiel> now that would be amazing
[00:48:12 CEST] <nevcairiel> but probably crazy, mingw fails at this badly
[00:49:42 CEST] <Gramner> afaik there's no way of doing automatic path translation that works in 100% of cases since there can be ambiguous cases
[00:50:52 CEST] <Gramner> here's how it works in msys: http://www.mingw.org/wiki/Posix_path_conversion
[00:52:02 CEST] <nevcairiel> yeah its complex and not very reliable, its probably best to stay away from that
[00:52:15 CEST] <wm4> yeah, the best I could imagine is mapping paths like /c/...
[00:53:16 CEST] <Gramner> the main cause of path conversion frustration in msys is msvs with it's crazy command line syntax
[00:53:33 CEST] <nevcairiel> things like /Fo<name> is just silly
[00:53:46 CEST] <nevcairiel> no space, no separator
[00:53:49 CEST] <nevcairiel> silly msvc
[00:53:49 CEST] <Gramner> exactly
[02:29:10 CEST] <atomnuker> J_Darnley: do you happen to know how sample_size and sample_w are determined in v210?
[02:30:05 CEST] <J_Darnley> If they're what I think then they are just "constants" set along side the DSP functions
[02:30:28 CEST] <J_Darnley> but I will go look at the source
[02:30:39 CEST] <BBB> michaelni: so, about swscale
[02:30:45 CEST] <BBB> michaelni: Im sure you know my objections to it
[02:33:32 CEST] <J_Darnley> atomnuker: yes, sample_size is the number of samples the DSP function does per iteration and then ...
[02:33:44 CEST] <BBB> nevcairiel: msys is just as stupid to convert paths from c:\ to /c/
[02:33:44 CEST] <J_Darnley> sample_w is the width processed by the dsp function leaving a remainder to be done in C
[02:33:50 CEST] <BBB> nevcairiel: that couldve been done much more compatibly
[02:59:53 CEST] <cone-752> ffmpeg 03James Almer 07master:9bf3d01d9147: avformat/latmenc: auto-insert aac_adtstoasc bitstream filter when needed
[03:48:11 CEST] <cone-752> ffmpeg 03Claudio Freire 07master:be746ae47063: AAC encoder: fix undefined behavior
[04:04:29 CEST] <rcombs> so I had audiotoolboxdec set up to take a channel layout struct from AT, convert it to a channel_layout bitmask, sort the layout struct to match lavu's channel order, and then set the output channel layout to the sorted struct
[04:04:59 CEST] <rcombs> in the AAC decoder, this resulted in the decoder reordering the channels into the order lav* expects
[04:05:10 CEST] <rcombs> turns out in the AC3 decoder, the order is ignored
[04:06:03 CEST] <rcombs> the "set output channel layout" API returns success
[04:06:13 CEST] <rcombs> and just silently does nothing
[04:06:42 CEST] <rcombs> so I figure "OK, let's see if I can use planar audio then"
[04:07:20 CEST] <rcombs> nope, there are flags for planar output but the decoders error when you use 'em
[04:22:23 CEST] <BBB> rcombs: looks like a ffmpeg developer designed their api and implemented it (for one decoder)
[04:22:27 CEST] <BBB> rcombs: :-p
[08:07:36 CEST] <mateo`_> Daemon404: hi, only codec_ctx->codec->caps_internal in the test is illegal right ? or is it illegal too to access it from lavf/utils.c ?
[10:33:26 CEST] <cone-623> ffmpeg 03Clément BSsch 07master:263eb76bdf5c: sws/aarch64: add ff_hscale_8_to_15_neon
[10:57:59 CEST] <ubitux> any idea why on x86 the vscale optimization are only effective for dst format in little-endian?
[10:58:28 CEST] <ubitux> oh my bad, that's only for >8-bit
[11:18:05 CEST] <cone-623> ffmpeg 03Paul B Mahol 07master:241a3a6ca493: doc/filters: add sofalizer examples
[11:18:06 CEST] <cone-623> ffmpeg 03Paul B Mahol 07master:cf925e0ac19d: doc/filters: add stereotools examples
[12:05:29 CEST] <ubitux> https://software.intel.com/sites/default/files/managed/a4/ed/palignr_w.png
[12:05:34 CEST] <ubitux> my brain just went upside down
[12:07:03 CEST] <Gramner> that's quite a horrible image
[12:08:03 CEST] <nevcairiel> that image tells me nothing of how the instruction works :D
[12:08:12 CEST] <Gramner> more readable to look up a 128-bit palignr instead, the 256-bit is just two separate 128-bit lanes anyway
[12:08:37 CEST] <ubitux> http://www.officedaytime.com/tips/simdimg/palignr_1.png
[12:08:41 CEST] <ubitux> makes more sense already
[12:09:54 CEST] <Gramner> you basically concatenate the registers and pick out a 16-byte section starting at byte imm8
[12:10:05 CEST] <nevcairiel> i like how msdn has C code to explain it, r := (CONCAT(a, b) >> (ralign * 8)) & 0xffffffffffffffff
[12:11:15 CEST] <nevcairiel> that still doesnt really explain the original image though
[12:12:00 CEST] <nevcairiel> it looks like its done twice
[12:12:03 CEST] <benoit-1> the coloring on the first line of the first image is strange
[12:13:21 CEST] <benoit-1> (no actually, all this light blue vs. blue makes no sense :))
[12:16:01 CEST] <Gramner> it looks like someone used a 128-bit palignr as a base and extended it to 256-bit when making that image without bother to adjust the colors
[12:16:46 CEST] <Gramner> because the colors in the first row makes sense if those were xmm registers. after that it's just a mess
[12:17:33 CEST] <JEEB> :D
[12:19:40 CEST] <nevcairiel> so vpalignr really just treats ymm like the two ymm regs are 4 xmm regs which it would use palignr on? that sure is confusing
[12:20:14 CEST] <Gramner> 256-bit palignr really should've been made cross-lane, because it rarely makes sense to use it anywhere the way it currently is
[12:21:06 CEST] <Gramner> blame Intel
[12:21:26 CEST] <nevcairiel> avx2 seems like a rather lazy approach
[12:21:31 CEST] <nevcairiel> concat two avx units, call it a day
[12:21:48 CEST] <Gramner> I'm sure there are reasons
[12:21:48 CEST] <nevcairiel> eh two sse units
[12:28:56 CEST] <ubitux> what's the usage of palignr actually? doing some kind of ring buffer?
[12:29:49 CEST] <wbs> similar to vext?
[12:30:13 CEST] <wbs> i.e. shift elements, if I read the pictures right
[12:45:54 CEST] <ubitux> in the vscale, offset is always 0 or 3?
[13:47:02 CEST] <mateo`> Daemon404: I've probably missed your reply if any (my irc box went down)
[14:01:54 CEST] <JEEB> was there a way to increase the verbosity for just a single demuxer?
[14:01:58 CEST] <JEEB> or otherwise a single compnent
[14:35:15 CEST] <cone-649> ffmpeg 03Alex Smith 07master:a677121cc568: configure: Fix debugging on mingw-w64 with gdb
[14:43:08 CEST] <BBB> michaelni: poke
[15:02:11 CEST] <michaelni> BBB, pong ?
[15:02:39 CEST] <BBB> michaelni: so whos going to work on swscale?
[15:03:02 CEST] <BBB> like, you really seem to like swscale. I think it needs tons of love to get that kind of status. who will do that work?
[15:03:08 CEST] <BBB> (the loving)
[15:03:57 CEST] <michaelni> i had hoped that a GSoC student would move it forward but i think noone submitted a proposal
[15:04:28 CEST] <BBB> thats because it needs love
[15:04:38 CEST] <wm4> BBB: swscale can't be saved
[15:04:40 CEST] <BBB> you cant expect students to give it love; students have no background, they add some new features
[15:04:41 CEST] <michaelni> pedro does work slowly on improving it it seems
[15:04:52 CEST] <BBB> maintainers need to give it love, ideally the original developer(s)
[15:04:58 CEST] <BBB> swscale needs massive amounts of love
[15:05:02 CEST] <wm4> because it's not a code problem but a development problem
[15:05:10 CEST] <kierank> wm4: ^
[15:05:13 CEST] <kierank> that
[15:05:17 CEST] <BBB> wm4: I think it can be salvaged - Im not sure any of the original code will be left at the end
[15:05:55 CEST] <michaelni> BBB with comments like wm4&kieranks i will not even think about touching the code, iam not enjoying this environment
[15:06:08 CEST] <BBB> michaelni: but youre not talking to them, youre talking to me
[15:06:15 CEST] <BBB> michaelni: and I didnt say we should rm -fr swscale
[15:06:19 CEST] <BBB> michaelni: I just said it needs love
[15:06:25 CEST] <michaelni> yes it does
[15:06:34 CEST] <BBB> michaelni: so& who will give it that kind of love?
[15:06:42 CEST] <wm4> michaelni: well it's because you actively resists any radical measures which might actually save swscale
[15:06:44 CEST] <BBB> we need some maintainers stepping up the love game, otherwise it will go down the drain
[15:07:08 CEST] <BBB> michaelni: did you ever read https://wiki.libav.org/Blueprint/AVScale ? (ignore the politics for now, focus on the technical complaints in the document)
[15:07:43 CEST] <michaelni> i read it long ago
[15:07:52 CEST] <michaelni> not recently if it changed
[15:08:14 CEST] <BBB> I dont think it did
[15:08:26 CEST] <BBB> so & lets say (hypothetically) that we wanted to salvage swscale
[15:08:37 CEST] <BBB> can we totally redesign it? and will you actively help in coding it up?
[15:09:35 CEST] <michaelni> iam happy if its totally redesigned, thats not a problem at all
[15:10:10 CEST] <michaelni> i want the main practically used codepathes to stay fast though
[15:10:40 CEST] <michaelni> a 5% slowdown should not happen
[15:10:44 CEST] <BBB> well, theres many dimensions to the total set of problems in swscale& api is one, lack of integration with the rest of ffmpeg is another
[15:10:56 CEST] <wm4> the first thing you'd have to accept to make progress at all (instead of burning developer time on all these crazy details every time someone dares to take a look at it) is (temporary) deoptimization
[15:11:06 CEST] <nevcairiel> swscale isnt very fast to begin with 
[15:11:23 CEST] <nevcairiel> all its "fast" optimization are super low quality
[15:11:28 CEST] <kierank> not true
[15:11:40 CEST] <BBB> the internals are very & unextendable, which isnt necessarily a problem for corner case optimizations, but at this point, xyz support is a total hack, whereas if we are moving from to bt2020 support, we really should start thinking about xyz being a central component of the processing chain
[15:12:02 CEST] <BBB> michaelni: obviously one thats skipped if its not necessary, but swscale as it is right now would be merely one of the steps
[15:12:20 CEST] <BBB> michaelni: fast paths for direct conversions are obviously ok, but its mostly very static and unpredictable right now
[15:12:38 CEST] Action: michaelni need to awnser apoe call iam bac in 5min
[15:12:40 CEST] <BBB> michaelni: I still believe we go through a full yuv conversion and scaling path if we convert gbrp14 to gbrp12
[15:12:48 CEST] <BBB> ok
[15:13:56 CEST] <kierank> anotherother big question is whether to include the pseudo pixel formats
[15:14:06 CEST] <kierank> r210, v210 etc
[15:14:16 CEST] <BBB> nevcairiel: most optimizations are from 1985, so theyre mmx (or sometimes mmx2) at best
[15:14:46 CEST] <BBB> theres little bits of sse2/avx2 added by various people a few years ago
[15:14:49 CEST] <BBB> and now finally some arm
[15:14:56 CEST] <BBB> but its mostly still a mess
[15:14:59 CEST] <ubitux> optimisation behaves strangely when constraints don't fit btw
[15:15:32 CEST] <ubitux> like, it seems x86 yuv2rgb will just ignore the last pixels if linesizes are not enough
[15:15:50 CEST] <kierank> the problem I hacked around is when doing chroma conversions swscale does a full luma multiply and shift which ends up being a NOOP
[15:15:51 CEST] <ubitux> it would be great to have some kind of automatic c-fallback to fill the padding
[15:15:54 CEST] <kierank> but burns an entire cpu core
[15:16:01 CEST] <ubitux> and make sure all simd received aligned & padded stuff
[15:16:59 CEST] <ubitux> btw, anyone for my vscale question earlier? in yuv2planeX, offset can only be 0 or 3?
[15:17:17 CEST] <ubitux> (x86 simd seems to assume so, and it looks like it's the case in practice in my tests so far)
[15:18:48 CEST] <BBB> ubitux: let me check
[15:20:31 CEST] <ubitux> only one where it could not be 3 or 0 would be where it is use_mmx_vfilter ? (c->uv_offx2 >> 1) : 3
[15:20:31 CEST] <BBB> oh god the dithering
[15:20:52 CEST] <ubitux> yes, dithering should be optional btw, it's badly done currently in the options
[15:24:43 CEST] <BBB> ubitux: I dont know what uv_offx2 does ...
[15:24:54 CEST] <ubitux> libswscale/utils.c:    c->uv_offx2 = dst_stride + 16;
[15:24:58 CEST] <durandal_1707> pile of hacks upon hacks let it rest in peace
[15:25:11 CEST] <ubitux> durandal_1707: please be more constructive
[15:25:26 CEST] <ubitux> we're not going to depend on an external lib for converts
[15:26:08 CEST] <BBB> where is use_mmx_vfilter set?
[15:26:48 CEST] <ubitux> libswscale/x86/swscale_template.c:                c->use_mmx_vfilter= 1;
[15:27:58 CEST] <ubitux> so, it can only be ` (0, 3) when this special yuv2yuvX function is used
[15:28:06 CEST] <ubitux> so it shouldn't matter
[15:28:40 CEST] <ubitux> i was surprised the other day when it was triggering this yuv2yuvX instead of the ff_yuv2planeX_{mmx,see,...}
[15:28:47 CEST] <ubitux> (which also exists)
[15:29:05 CEST] <ubitux> while it is triggering yuv2planeX_8_c when running on arm
[15:29:14 CEST] <ubitux> (or basically with no asm)
[15:29:51 CEST] <BBB> it seems we dont set the sse2 versions if this was already initialized
[15:29:59 CEST] <BBB> that looks like a bug
[15:30:06 CEST] <BBB> ../libswscale/x86/swscale.c:    case 8: if ((condition_8bit) && !c->use_mmx_vfilter) vscalefn = ff_yuv2planeX_8_  ## opt; break; \
[15:30:18 CEST] <BBB> we should just force c->use_mmx_vfilter to 0?
[15:30:21 CEST] <BBB> anyway
[15:30:30 CEST] <BBB> yes youre right its only 0 and 3 then, for your use case
[15:34:02 CEST] <BBB> ubitux: re simd behaving stragenyl, thats certainly something Id like to discuss with michaelni later on in this conversation
[15:34:10 CEST] <BBB> ubitux: but lets start by keeping things simple
[15:34:22 CEST] <durandal_1707> ubitux: I'm still waiting for nlmeans
[15:34:53 CEST] <ubitux> yeah, i should get done with this one
[15:36:13 CEST] <ubitux> BBB: btw, i agree with michaelni about having the colorspace convert in sws
[15:36:16 CEST] <ubitux> since it's already there...
[15:37:21 CEST] <BBB> what is already there?
[15:37:47 CEST] <michaelni> BBB all scaling goes through yuv, unscaled rgb converts might be without yuv
[15:38:07 CEST] <ubitux> BBB: SWS_CS_* :p
[15:38:09 CEST] <michaelni> theres some avx in swscale
[15:38:18 CEST] <BBB> lets do one dimension of this problem set at a time
[15:38:56 CEST] <BBB> lets start with api: swscale api is from the 80s. it needs to die and the approach in the avscale blueprint isnt so bad. backwards compatibility to hell, no part of the public api (except maybe the version macros) should stay
[15:39:00 CEST] <BBB> do you agree?
[15:39:25 CEST] <ubitux> i think wm4 had a patch for that?
[15:39:36 CEST] <ubitux> unless you're not talking about the AVFrame wrapping?
[15:39:52 CEST] <BBB> the api should integrate with the rest of ffmpeg (e.g. use AVOptions, like swresample does; use AVFrame; etc.), and no context caching, sws_convertPalette8ToPacked24 or vector api
[15:39:53 CEST] <michaelni> BBB the old API interface should be provided by using wrapers around the new
[15:40:01 CEST] <BBB> no, the old api should just die
[15:40:13 CEST] <ubitux> yeah i agree with deprecating the old api
[15:40:15 CEST] <BBB> its useless and nobody wants it except mplayer, which is almost actual proof that it should die
[15:40:18 CEST] <kierank> no kill the old api
[15:40:20 CEST] <kierank> it's horrible
[15:40:27 CEST] <kierank> which implies a new lib
[15:40:34 CEST] <BBB> michaelni: I think you have pretty much consensus that the old api needs to die here
[15:41:01 CEST] <michaelni> sure, if thats what people want
[15:41:09 CEST] <BBB> michaelni: so, thats dimension 1. now, dimension 2: scaling stages& 
[15:41:18 CEST] <BBB> (Ill talk simd/platform ops later)
[15:41:36 CEST] <BBB> so, right now, we have two kind of paths: direct conversions like yuv422p_to_yuyv
[15:41:56 CEST] <BBB> and we have the scaled path, as invoked (iirc) by gbrp14 to gbrp12
[15:42:12 CEST] <BBB> (fortunately it uses a filter size of 1 so its not that bad, but still)
[15:42:24 CEST] <BBB> we need a more generic approach to scaled path
[15:42:29 CEST] <michaelni> yes
[15:42:32 CEST] <BBB> I think avscale calls this kernels
[15:42:56 CEST] <BBB> you can sort of see this in the colorspace thing also, although thats obviously fairly limited (on purpose)
[15:43:06 CEST] <BBB> internal format should be dynamic, it cant be only yuv
[15:43:12 CEST] <BBB> if input and output is xyz, that should be ok
[15:43:30 CEST] <BBB> also, to go from rgb to rgb should not involve a yuv conversion, and xyz to rgb shouldnt either
[15:43:36 CEST] <michaelni> it was planed since the 80ties that the internal format should be anything just wasnt ever done
[15:43:49 CEST] <BBB> right, but so this is a component of major love"
[15:44:02 CEST] <BBB> weve been saying for years that stuff needs to be done and nobody does it
[15:44:35 CEST] <BBB> it may well be that a new approach will be so fundamentally different that we need new implementations of every simd function, and that pretty much all existing code will eventually be rewritten
[15:44:41 CEST] <michaelni> also you(plural) should talk with pedro arthur he imlemented a more generic filter path last year
[15:45:25 CEST] <michaelni> and that code is enabled and works but i think it itself needs cleanup and documentation
[15:45:48 CEST] <BBB> a kernel style approach has issues btw, as can be seen in the avscale document
[15:45:51 CEST] <ubitux> BBB: small parenthesis about xyz: it appears many people use lut3d to do the convert
[15:45:57 CEST] <ubitux> (vf lut3d does that)
[15:46:16 CEST] <ubitux> (i had a local patch to support xyz as input, needs to upstream it, but i have some format negociation issues)
[15:46:30 CEST] <BBB> I actually wrote avscale years ago, long before libav started caring about it, I tihnk I talked about it on irc back then
[15:46:51 CEST] Action: michaelni maybe wasnt on iRC back then :)
[15:46:53 CEST] <BBB> the issue with kernels is that you tend to want to design it in such a way (naturally) that the number of memory intermediates goes up a lot compared to swscale
[15:47:14 CEST] <BBB> so this needs to be designed by ery knowledgable people who understand performance
[15:47:37 CEST] <BBB> and will end up with a lot of functions, some near-duplicates, to do the same thing, if you want the same performance as you have with swscale
[15:47:40 CEST] <BBB> (in all cases)
[15:47:47 CEST] <michaelni> BBB i think you absolutely must talk with pedro arthur about this
[15:47:50 CEST] <BBB> so, lots of code, or slightly slower
[15:48:17 CEST] <michaelni> as pedro did alot of work on swscale filter stuff and that is i think very similar to kernels
[15:48:18 CEST] <BBB> (and you can see why I eventually threw my avscale out of the window, I just didnt care enough to write so much code)
[15:48:58 CEST] <BBB> so, simd is largely a game about assumptions, right? as kierank sayd, we have tons of simd that doesnt work right on odd image sizes or non-multiple-of-4-s etc.
[15:49:15 CEST] <BBB> a nice thing of a new api is that we can document assumptions
[15:49:24 CEST] <BBB> e.g. buffers should have at least this much padding"
[15:49:32 CEST] <BBB> and then just require that to be the case
[15:49:47 CEST] <BBB> and then we can just overwrite in our simd instead of underconvert
[15:49:59 CEST] <BBB> (or, worst of all, revert to C, which is just so ugly that I dont know what to say)
[15:50:06 CEST] <BBB> (swscale does a combination of all 3)
[15:50:17 CEST] <michaelni> the lack of SIMD assumtation docs is a real problem, yes
[15:50:35 CEST] <michaelni> yes
[15:50:38 CEST] <BBB> and about pedro& I can look back at what he did, but you see my point about students, right? this is the job of a maintiner, not a student
[15:51:01 CEST] <BBB> if we want pedro to help discussing this, he should be here, or we should get him here. is he on irc?
[15:51:10 CEST] <michaelni> pedro is no student anymore in the gsoc sense :)
[15:51:22 CEST] <BBB> is he ready to be maintainer?
[15:51:30 CEST] <michaelni> i suspect he isnt on irc but yes he should join ideally
[15:51:57 CEST] <BBB> in the short term, none of this will happen, which is why I wrote the filter
[15:52:11 CEST] <BBB> it fixes my immediate problem and will allow me to move forward with actual things Id like to do
[15:52:25 CEST] <michaelni> i think he is ready but maybe he lacks confidence or maybe time i dont know
[15:52:55 CEST] <michaelni> pedro agreed to co/backup mentor a swscale task if we had a student (which we dont)
[15:53:30 CEST] <wm4>     do
[15:53:30 CEST] <wm4>         *out-- = 0;
[15:53:30 CEST] <wm4>     while (out >= end && strspn(out, WHITESPACES));
[15:53:32 CEST] <wm4> is this ub?
[15:53:44 CEST] <wm4> (end points to start of the memory alloc for out)
[15:54:22 CEST] <michaelni> if out is ever pointing to 1 before the array then its UB
[15:54:43 CEST] <wm4> this is from av_get_token()
[15:56:41 CEST] <BBB> michaelni: is pedros filter chaining work documented anywhere? or where do I find it?
[15:58:05 CEST] <BBB> ubitux: for video, I doubt people use xyz much, its primarily an image thing to actually ever want the data in xyz& but xyz is an intermediate useful to convert between various rgb chromaticity primaries (colorspaces)
[15:59:59 CEST] <michaelni> BBB iam not sure its documented all that much, pedro last summer ended up doing more than i wanted and possibly good docs where one thing that he forgot
[16:00:18 CEST] <BBB> where do I look for the code?
[16:00:47 CEST] <BBB> I should make a wiki page out of this discussion so we can refer to it in future continuations
[16:01:19 CEST] <michaelni>  git log -p --author Arthur
[16:02:45 CEST] <durandal_1707> I can help with coding if blueprints are there
[16:13:55 CEST] <Shiz> wm4: sounds UB
[16:14:21 CEST] <wm4> nothing like taking a superficial look at random C string processing code to find UB on the spot
[16:16:10 CEST] <kierank> is it possible to write a decoder that allows a choice of output pixel formats
[16:16:59 CEST] <jamrial> isn't that what -pix_fmt for the output stream is for?
[16:17:28 CEST] <kierank> no that does a conversion
[16:17:39 CEST] <wm4> kierank: get_format
[16:17:40 CEST] <michaelni> kierank, from a API point of view the user app can tell the decoder via get_format() callback what format it wants
[16:17:56 CEST] <wm4> specifically you pass a list to ff_get_format I think
[16:18:46 CEST] <michaelni> the decoder passes a list of formats (possibly bitstream dependant) to the callback and the callback from the user app can then select one
[16:19:09 CEST] <michaelni> i think hwaccel stuff is the only code that uses this though
[16:19:28 CEST] <michaelni> but it was originally written with other uses in mind 
[16:19:34 CEST] <ubitux> we don't do this for audio (float vs int?)
[16:19:41 CEST] <ubitux> +?
[16:20:52 CEST] <michaelni> no but it would be rather simple to change that
[16:21:29 CEST] <michaelni> only the argument type would be a annoying thing as get_format uses const enum AVPixelFormat * fmt
[16:21:41 CEST] <michaelni> and not int *
[16:24:03 CEST] <BBB> https://trac.ffmpeg.org/wiki/swscale ?
[16:24:17 CEST] <BBB> please comment and so on
[16:24:17 CEST] <michaelni> LGTM
[16:24:26 CEST] <BBB> Id like to be able to use that as a reference for future discussions
[16:27:41 CEST] <ubitux> BBB: about assembly, the unscaled path is actually very complex to handle
[16:27:48 CEST] <ubitux> first, it has way too much arguments
[16:28:06 CEST] <ubitux> 2nd, to workaround this, since it's using inline asm in x86, it passes the sws context
[16:28:18 CEST] <ubitux> in which the fields are duplicated and directly readable
[16:28:49 CEST] <BBB> I think we should add that, I hadnt complained that much about the unscaled optimizations yet, indeed
[16:28:50 CEST] <ubitux> (by offsetting the context with some)
[16:28:54 CEST] <BBB> but some of that code is hideous also
[16:29:02 CEST] <ubitux> (with some +macro)
[16:29:07 CEST] <BBB> yeah I remember
[16:29:15 CEST] <BBB> the fast bilinear scaler is also very "interesting""
[16:29:21 CEST] <BBB> (its fast, I admit)
[16:30:22 CEST] <ubitux> BBB: also slicing
[16:30:31 CEST] <BBB> I have surprisingly few opinions on slicing
[16:30:36 CEST] <BBB> some people seem to hate it, I dont really care
[16:30:44 CEST] <ubitux> do you know how it's done currently?
[16:30:55 CEST] <BBB> roughly, yes
[16:31:22 CEST] <BBB> I wonder if it isnt easier if slicing was done internally and externally it just had a -threads parameter that users can set
[16:31:36 CEST] <ubitux> it's not threadable slicing, it's just for the destination
[16:31:53 CEST] <BBB> I always thought it was for threading
[16:31:58 CEST] <ubitux> no
[16:32:02 CEST] <BBB> :-p
[16:32:11 CEST] <BBB> well good thing I had no opinion on it I guess
[16:32:38 CEST] <ubitux> apparently it was about some cache locality of some sort
[16:32:50 CEST] <michaelni> btw as slicing is mentioned, theres the use case where the whole image doesnt fit in memory (gimp does that) this may be worth a thought in case of a redesign
[16:33:37 CEST] <ubitux> michaelni: doesn't work by squares?
[16:33:39 CEST] <ubitux> only slices?
[16:34:05 CEST] <ubitux> photoshop works by big blocks (call it tiles/squares/bigblocks/whatever)
[16:34:06 CEST] <michaelni> to clarify we dont support that currently, gimp uses its own scaler
[16:34:29 CEST] <michaelni> i just saw that gimp caching code a long time ago (which used squares)
[16:34:43 CEST] <michaelni> or rectangles dont remember
[16:36:20 CEST] <michaelni> also some kind of square / slice /tiling for multitreading is probably "important"
[16:37:52 CEST] <ubitux> yeah
[16:37:59 CEST] <ubitux> BBB: about the poor api, let's talk about the options...
[16:38:16 CEST] <ubitux> dithering configuration is broken
[16:38:22 CEST] <BBB> hm, dithering
[16:38:28 CEST] <ubitux> like, you haven't a dither=none
[16:38:33 CEST] <ubitux> it's just enabled, sometimes
[16:38:36 CEST] <ubitux> (0=auto)
[16:38:43 CEST] <BBB> yeah, nobody knows when its enabled
[16:38:44 CEST] <michaelni> btw, iam not sure though how important/usefull such non memory squares are ...
[16:38:57 CEST] <ubitux> also the scaler selection mixed within flags
[16:39:23 CEST] <BBB> the avscale blueprint is pretty good at explaining that, the filter selection should be an enum
[16:39:26 CEST] <BBB> (AVOption)
[16:39:35 CEST] <BBB> and the rest of the flags can just be bools or whatevers as separate options
[16:39:51 CEST] <BBB> I Guess pre-AVOption extending api was hard so this made sense, but with AVOption we realy dony need it anymore
[16:39:57 CEST] <ubitux> small nit: wth are param0 and param1
[16:40:04 CEST] <BBB> hahaha right
[16:40:14 CEST] <BBB> they are options for some filters
[16:40:20 CEST] <BBB> wasnt it alpha/beta for one of the larger filters?
[16:40:25 CEST] <ubitux> error_diffusion belongs to dithering btw
[16:40:31 CEST] <ubitux> it's currently a sws falgs
[16:40:49 CEST] <ubitux> what are the implication of accurate_rnd too
[16:40:50 CEST] Action: michaelni doesnt remember exactly what param0 and 1 did for each filter but yes they where filter params
[16:41:08 CEST] <BBB> For SWS_BICUBIC param[0] and [1] tune the shape of the basis function, param[0] tunes f(1) and param[1] f´(1) | For SWS_GAUSS param[0] tunes the exponent and thus cutoff frequency | For SWS_LANCZOS param[0] tunes the width of the window function
[16:41:35 CEST] <ubitux> no other comment so far
[16:41:56 CEST] <michaelni> these all should be AVOptions
[16:42:00 CEST] <BBB> theres also SWS_FULL_CHR_H_INT/INP
[16:42:19 CEST] <BBB> in fact, I just noticed SWS_DIRECT_BGR, ...
[16:43:10 CEST] <BBB> I believe int/inp had to do with non-420p support
[16:43:15 CEST] <BBB> (I mean, practically speaking)
[16:43:35 CEST] <BBB> doesnt accurate_rnd increase precision of some internal codepath/something?
[16:43:43 CEST] <ubitux> small note: there are a few dithering algorithms in vf paletteuse filter 
[16:43:59 CEST] <michaelni> BBB, yes accuarte_rnd uses more accurate code
[16:44:18 CEST] <michaelni> IIRC no pmulhw
[16:44:35 CEST] <michaelni> which would loose the lsbs
[16:44:35 CEST] <ubitux> it has different meaning depending on the codepath
[16:44:40 CEST] <BBB> I think its totally fine to basically eliminate all these flags and go back to lets just make it do the right thing
[16:44:43 CEST] <ubitux> it's not well defined
[16:44:59 CEST] <BBB> I can see how pmulh(u)w was critically important for performance in the mplayer era
[16:45:09 CEST] <BBB> I think its totally fair to say that with axv2, it is not all that relevant anymore
[16:45:19 CEST] <ubitux> it's used between 32 vs 16 in some rgb code iirc
[16:45:38 CEST] <BBB> I also wonder if half of the filters should be deleted
[16:45:53 CEST] <BBB> like sinc, gauss
[16:46:01 CEST] <BBB> maybe even fast-bilinear
[16:46:09 CEST] <BBB> (that would clean up the code so much)
[16:46:27 CEST] <michaelni> the filters like sinc gauss should have nearly no complexity as its just different numbers
[16:46:35 CEST] <BBB> its user complexity
[16:46:46 CEST] <BBB> we should expose the ideal configuration settings to our user
[16:47:01 CEST] <BBB> when to use spline or lanczos: when upscaling
[16:47:06 CEST] <BBB> (and caring about quality)
[16:47:17 CEST] <BBB> when to use bicublin: when speed is critical and youre downscaling
[16:47:21 CEST] <BBB> thats very helpful to end users
[16:47:28 CEST] <BBB> when to use gaussian?
[16:47:33 CEST] <BBB> I dont know& I dont think anyone knows
[16:47:34 CEST] <michaelni> with scalig different people will want different options and some people just like to have the choice
[16:47:44 CEST] <ubitux> i'd keep the different filters
[16:47:55 CEST] <ubitux> it's useful to make various visual comparison
[16:48:22 CEST] <michaelni> sinc is something that some people "know" is best until they try it
[16:48:31 CEST] <ubitux> :D
[16:48:36 CEST] <BBB> but doesnt that mean we should remove it?
[16:48:39 CEST] <BBB> why keep the option there
[16:48:54 CEST] <ubitux> people will bug you to implement it because it's the perfect filter
[16:48:56 CEST] <nevcairiel> many of the various filters are just different kernels over the same kind of filter, so preserving them costs you practically nothing
[16:48:59 CEST] <BBB> do you know how many people thought x264 was the best encoder in the world but they were using it with default ffmpeg parameters (instead of presets)?
[16:49:16 CEST] <ubitux> so you have it to show them it's shit, or just as a visual demonstration (educative purpose, experiment, ...)
[16:49:24 CEST] <michaelni> its very important that the defaults are good
[16:49:36 CEST] <BBB> I guess as long as defaults and documentation is good, I dont mind
[16:49:41 CEST] <BBB> but documentation is not good right now :D
[16:50:47 CEST] <michaelni> the docs need some love, i could probably help with that if theres a list of what needs new/better docs
[16:51:08 CEST] <fritsch> michaelni: "sinc" <- one still learns that in university, that's why
[16:51:47 CEST] <av500> avscale
[16:52:17 CEST] <av500> /undo
[16:52:21 CEST] <Shiz> BBB: alternatively, pseudo-filter names like 'upscale' and 'downscale' that are just aliases for whatever is best
[16:52:26 CEST] <nevcairiel> a perfect sinc filter is perfect - a windowed sinc is just an approximation =p
[16:52:47 CEST] <BBB> hm, filter presets
[16:53:18 CEST] <michaelni> fritsch, yes, its true what one learns but sinc results from some axioms and these dont apply that way to images
[16:53:20 CEST] <ubitux> what's the filter window used in sws? is there such concept?
[16:55:28 CEST] <fritsch> the raspberry pi people that implemented one from scratch decided to go for a special weighted bicubic filter
[16:55:40 CEST] <fritsch> cause of implementation details / performance quality
[16:56:11 CEST] <fritsch> kodi's lanczos3 filter needs quite a bit oomph and for example a hsw gpu is too slow to do 50 fps from 1080 to 4k
[16:57:14 CEST] <wm4> fritsch: does kodi's scale width and height separately?
[16:58:53 CEST] <fritsch> pi uses mitchell-natravali iirc, so the default most likely also ffmpeg uses
[16:59:26 CEST] <fritsch> wm4: i need to look in detail, we use a pseudo separated filter
[16:59:29 CEST] <fritsch> so most likely no :-)
[16:59:34 CEST] <fritsch> but wait a mo
[16:59:47 CEST] <fritsch> it's from a time where you did not have a float intermediate buffer in the gpu
[16:59:58 CEST] <fritsch> or where that extension was "patented" by someone
[17:01:13 CEST] <BBB> so this may just be me, but I tend to think that swscale should be software. Im all for doing things in hardware, but I dont know if we should make swscale more complex for that
[17:01:26 CEST] <BBB> or, rather, I wouldnt know how to do it so it makes no sense for me to design it
[17:01:33 CEST] <BBB> I dont even know if the concept makes any sense at all
[17:01:49 CEST] <fritsch> wm4: it uses a 4x4 convolution shader at the end
[17:01:57 CEST] <fritsch> wm4: so "no" to your question
[17:02:24 CEST] <fritsch> BBB: shaders are really, really mighty especially for convolution
[17:02:31 CEST] <fritsch> i don't see a point doing that on the cpu
[17:02:46 CEST] <BBB> I know shaders, I love them
[17:03:02 CEST] <BBB> but my point is more about do you want to use the swscale api if youre going to scale stuff in hardware?
[17:03:03 CEST] <nevcairiel> shaders work fine if you already have the image on the gpu
[17:03:16 CEST] <nevcairiel> if you dont, its a lot of overhead and potentially not worth it
[17:03:31 CEST] <BBB> Im not saying you shouldnt scale in hw; you should, totally!
[17:03:44 CEST] <BBB> Im just wondering if swscale is the ideal place to serve as an intermediate layer
[17:03:46 CEST] <wm4> fritsch: separating them makes it quite a bit faster
[17:03:50 CEST] <fritsch> jep
[17:04:00 CEST] <fritsch> but you need a float intermediate buffer
[17:04:02 CEST] <fritsch> to do so
[17:04:24 CEST] <fritsch> which we did not have (on all gpus) at this time
[17:04:44 CEST] <fritsch> iirc gwenole also implemented his lanczos3 in libva without separated kernels
[17:04:55 CEST] <Daemon404> nevcairiel, do you know what's left to do on codecpar except xmv and converting the few files left to use it?
[17:04:57 CEST] <wm4> fritsch: no you don't
[17:05:13 CEST] <fritsch> wm4: then you loose information
[17:05:22 CEST] <wm4> nonsense
[17:05:33 CEST] <nevcairiel> Daemon404: besides careful squashing, separating a bunch of the changes that should remain standalone, and a proper and complete review? :)
[17:05:39 CEST] <fritsch> nonsense :-)
[17:05:54 CEST] <fritsch> come one doing a float multiplication and storing in non float intermediate buffer
[17:05:54 CEST] <Daemon404> nevcairiel, is ffmpeg capable of "proper and complete review" of this if we send it to the ML
[17:05:59 CEST] <fritsch> drives the separation nuts
[17:06:04 CEST] <Daemon404> or will be it a anti-libav circlejerk
[17:06:07 CEST] <wm4> a 16 bit fixed point buffer preserves more information than a 16 bit float buffer
[17:06:18 CEST] <ubitux> Daemon404: ml ’ endless review
[17:06:20 CEST] <nevcairiel> Daemon404: dont care about the ML, but I want to review myself when its squashed
[17:06:21 CEST] <phh> but obviously it's better for your start of day
[17:06:23 CEST] <ubitux> or inactivity
[17:06:26 CEST] <Daemon404> nevcairiel, ok sure
[17:06:37 CEST] <Daemon404> i am happy to do the squashing and conversions of left over files
[17:06:48 CEST] <ubitux> Daemon404: pretty sure 3-4 developers on github will be enough of a review
[17:06:48 CEST] <Daemon404> im excited it's nearing a "end"
[17:07:02 CEST] <Daemon404> ubitux, all righty
[17:07:06 CEST] <nevcairiel> should go through the list first, some of those commits should be pulled out first
[17:07:19 CEST] <nevcairiel> i did some myself that changed unrelated parts to be compatible with codecpar more easily
[17:07:20 CEST] <fritsch> wm4: then you need to scale appropriately twice
[17:07:29 CEST] <Daemon404> nevcairiel, those can be sent
[17:07:29 CEST] <fritsch> e.g. scale the filter weights
[17:07:34 CEST] <fritsch> and inverse at the end
[17:07:35 CEST] <Daemon404> but i think sending the whole thing to the list is a death sentence
[17:07:47 CEST] <nevcairiel> indeed, just avoid that nightmare
[17:08:10 CEST] <wm4> Daemon404: agreed
[17:08:43 CEST] <Daemon404> all right
[17:08:48 CEST] <Daemon404> i will trudge on converting stuff
[17:09:01 CEST] <Daemon404> i tired xmv but didnt get anywhere
[17:09:05 CEST] <Daemon404> tried*
[17:12:58 CEST] <fritsch> wm4: do you have one separated in mpv? and a link handy for me?
[17:13:43 CEST] <wm4> fritsch: yes... well it's a common technique (even libswscale does it), and the code is all there
[17:15:28 CEST] <Daemon404> ill do all the suqashing and rebasing this weekend (or tomorrow if ready( if you guys can figure out xmv
[17:20:32 CEST] <mateo`> I guess it's not the right time to ping the mediacodec/hwaccel patch ? (and is something that will happen after the codecpar merge ?)
[17:21:53 CEST] <Daemon404> mateo`, ping!
[17:22:06 CEST] <Daemon404> there's a problem with the api test you added to fate
[17:22:14 CEST] <Daemon404> it accesses non-public API and structs
[17:22:33 CEST] <Daemon404> (i ran into this curing tep2 merge)
[17:24:27 CEST] <mateo`> Daemon404: is that also a problem accessing this field from lavf/utils.c ?
[17:24:50 CEST] <Daemon404> i dont think it does post-merge, but i need to check
[17:25:02 CEST] <Daemon404> because accessing stream->codec is going away in lavf
[17:25:10 CEST] <Daemon404> unless it is the avctx used inside find_stream_info
[17:25:13 CEST] <Daemon404> then it is ok
[17:25:32 CEST] <Daemon404> but it's definitely not ok to access codec_internal in public api tests
[17:25:39 CEST] <Daemon404> "internal" in the name.
[17:25:40 CEST] <mateo`>     if (st->codec->codec->caps_internal & FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM) {
[17:25:46 CEST] <mateo`> I do this in lavf/utils.c
[17:25:52 CEST] <ubitux> the purpose of these tests is to make sure the information is filled without decode
[17:26:00 CEST] <Daemon404> yeah thats not really ok
[17:26:58 CEST] <Daemon404> ubitux, not really an api test then
[17:26:59 CEST] <mateo`> Daemon404: there is also another issue in the fate test (this one is documented), i write into st->codec_info_nb_frames
[17:27:02 CEST] <Daemon404> because the user cannot access that.
[17:27:21 CEST] <ubitux> Daemon404: it's testing find_stream_info api
[17:27:33 CEST] <Daemon404> ubitux, thats nice, but it is testing a non-accessible property
[17:27:37 CEST] <Daemon404> thats not an *API* test
[17:27:40 CEST] <Daemon404> because its not availabel via api
[17:28:16 CEST] <mateo`> Daemon404: would it be ok to move the test to another category ? ("internal" tests ?)
[17:28:31 CEST] <ubitux> rename it notapi
[17:28:32 CEST] <Daemon404> mateo`, can probably move it to utils-test.c or something in lavf
[17:28:34 CEST] <Daemon404> we have a lot of those
[17:28:48 CEST] <Daemon404> but the issue is still accessing avcodec-internal stuff from not-avcodec
[17:28:57 CEST] <Daemon404> it may be worth addign an accessor function? 
[17:29:04 CEST] <Daemon404> why does avf need to know a codec flag anyway
[17:29:31 CEST] <wm4> it checks whether the decoder can act as a parser
[17:29:46 CEST] <mateo`> to know if it can tell the decoder to not decode a frame (while the decoder still sets the width/height/pixfmt/sar/...)
[17:30:12 CEST] <Daemon404> seems like a hack to me
[17:30:15 CEST] <mateo`> it is
[17:30:39 CEST] <mateo`> the proper "fix" is relying on parsers to get those info, but that is a lot of work
[17:30:41 CEST] <Daemon404> ideas for solution? avpriv_do_i_have_some_flag?
[17:30:59 CEST] <Daemon404> theres a few places in lavf flags are checked i need to fix for tep2
[17:31:05 CEST] <Daemon404> but it's all for very.... interesting... uses
[17:31:12 CEST] <Daemon404> that i'd rather get rid of, but people would revolt
[17:31:15 CEST] <Daemon404> and lynch me
[17:32:00 CEST] <BBB> michaelni: and I assume you dont mind the filter as a stopgap solution - given that swscale-style will take a while?
[17:34:09 CEST] <mateo`> Daemon404: avpriv_do_i_have_some_flag would require for those flags definition to be public (they are currently included via libavcodec/internal.h)
[17:34:29 CEST] <ubitux> BBB: +#include "libavcodec/bit_depth_template.c"
[17:34:34 CEST] <ubitux> missing file?
[17:34:52 CEST] <Daemon404> mateo`, any ideas then? It's no longer "ok" to access the stream->codec member in lavf soon.
[17:34:59 CEST] <ubitux> oh my bad
[17:35:02 CEST] <ubitux> it's already upstream
[17:35:02 CEST] <Daemon404> i could add a 'flags' member to codecpar
[17:35:05 CEST] <Daemon404> but that seems... wrong
[17:36:53 CEST] <BBB> ubitux: :D
[17:37:26 CEST] <mateo`> Daemon404: it could be a temporary solution but would still require to include libavcodec/internal.h to know those flags
[17:37:46 CEST] <Daemon404> mateo`, a temporary solution would also be to just surround it in deprecation guards
[17:37:50 CEST] <Daemon404> and pray it can be properly fixed
[17:38:27 CEST] <mateo`> but again, it seems wrong in the first place to use a decoder to get codec information (such as width/height/pix_fmt/sar)
[17:38:27 CEST] <ubitux> BBB: i think lavfi can have negative stride
[17:38:35 CEST] <ubitux> so you might not be able to do stride << x
[17:38:48 CEST] <ubitux> (but stride * (1<<x))
[17:38:50 CEST] <BBB> right
[17:38:50 CEST] <wm4> mateo`: that's why we have parsers
[17:38:56 CEST] <Daemon404> mateo`, the alernative is to write a parser for *every* codec that needs it
[17:39:03 CEST] <wm4> and I've mentioned the solution via parser
[17:39:06 CEST] <BBB> can you comment on list? Ill fix
[17:39:09 CEST] <Daemon404> while nice, i cant see that ever happening
[17:39:12 CEST] <ubitux> BBB: you might be able to trigger negative linesizes with hflip
[17:39:23 CEST] <ubitux> BBB: yeah i'll do a proper review later
[17:39:26 CEST] <mateo`> I know, but this work just need to happen ...
[17:39:29 CEST] <BBB> ty
[17:39:40 CEST] <mateo`> we already discussed it
[17:39:53 CEST] <Daemon404> so what would you suggest we do in the meantime
[17:41:35 CEST] <mateo`> I would be OK with an accessor as you mentionned
[17:43:32 CEST] <kierank> peloverde: ever tried emailing qticefloe at apple.com for old times sake
[17:43:46 CEST] <mateo`> I will try to figure out a solution using parsers for avformat_find_stream_info
[17:44:26 CEST] <Daemon404> ok
[17:44:46 CEST] <Daemon404> nevcairiel / wm4 - xmv may be wasier to fix than we thought
[17:44:53 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/wmv2dec.c#L125
[17:44:57 CEST] <Daemon404> this is the only place it is used
[17:46:03 CEST] <BBB> ubitux: fixed locally
[17:51:53 CEST] <michaelni> BBB, sure ok
[18:01:49 CEST] <BBB> michaelni: for vector api, can you put the api and implementation under a version macro so they automatically disappear upon next version bump?
[18:01:57 CEST] <BBB> (and thanks for patch)
[18:04:34 CEST] <wm4> heh I thought mplayer used this
[18:04:34 CEST] <Daemon404> wm4, can you upload that mov/vp6 somewhere and push a ref change
[18:04:46 CEST] <wm4> Daemon404: give me a moment
[18:04:54 CEST] <Daemon404> if there is an api, mplayer uses it
[18:05:01 CEST] <Daemon404> even if its not public
[18:05:07 CEST] <Daemon404> and the api was probably added just for mplayer
[18:06:08 CEST] <wm4> Daemon404: https://0x0.st/PA8.mov
[18:06:34 CEST] <Daemon404> thanks
[18:07:18 CEST] <Daemon404> also, there's surprisingly little code left unconverted to codecpar
[18:07:28 CEST] <Daemon404> but a few wtf things
[18:07:52 CEST] <wm4> I'll push the ref change
[18:08:44 CEST] <Daemon404> i am hopeful i can start squashing very soon
[18:08:52 CEST] <Daemon404> and the worst part of the saga will be over
[18:10:06 CEST] <wm4> such a nightmare
[18:11:46 CEST] <Daemon404> hence i am keen on finishing it
[18:11:58 CEST] <Daemon404> all the changes have been for the better
[18:12:15 CEST] <Daemon404> it's been painful because the task was basically "fix a shitload of hacks in ffmpeg in a correct way"
[18:13:34 CEST] <wm4> yeah
[18:14:07 CEST] <wm4> too bad ffmpeg's style is adding bad hacks to fix single samples...
[18:14:18 CEST] <BBB> hey Daemon404 did I mention I went to bathtub gin the other day?
[18:14:22 CEST] <BBB> its a really nice place
[18:14:23 CEST] <Daemon404> how was it
[18:14:26 CEST] <Daemon404> oic
[18:14:30 CEST] <wm4> to a degree it's understandable and even wanted, but there's a limit
[18:14:31 CEST] <BBB> the food is surprisingly good for a bar
[18:14:35 CEST] <Daemon404> and to think i lived accross from it for 9 months
[18:14:36 CEST] <BBB> and the drinks are great
[18:14:37 CEST] <Daemon404> and never went
[18:14:42 CEST] <BBB> boo
[18:14:49 CEST] <BBB> well go next time youre here
[18:14:56 CEST] <Daemon404> thats soon ;P
[18:14:57 CEST] <BBB> like a thanks for merging codecpar
[18:14:57 CEST] <BBB> or so
[18:15:03 CEST] <BBB> when soon?
[18:15:10 CEST] <Daemon404> may 1st until may 13th
[18:15:15 CEST] <BBB> oh thats not soon
[18:15:17 CEST] <BBB> ok
[18:15:22 CEST] <Daemon404> "soon"
[18:15:37 CEST] <Daemon404> i'd buy everyone who helped merge a drink or something
[18:15:41 CEST] <Daemon404> but a few them dont show up to events
[18:15:42 CEST] <Daemon404> :P
[18:17:52 CEST] <BBB> thats fine also
[18:17:56 CEST] <BBB> do they live nearby?
[18:20:05 CEST] <Daemon404> BBB, no
[18:20:07 CEST] <Daemon404> i meant in general
[18:20:23 CEST] <Daemon404> at VDD or somesuch
[18:24:16 CEST] <peloverde> kierank: No I haven't, qticefloe was mostly defunct by the time I started multimedia programming
[18:24:43 CEST] <Daemon404> peloverde, thats cant be right... it was useful when i started, and that was later than you
[18:24:48 CEST] <Daemon404> mostly for the various pix formats
[18:25:47 CEST] <peloverde> The old stuff was still useful for quite a while, but I think the last post was around '01
[18:32:29 CEST] <Daemon404> indeed
[18:35:07 CEST] <kierank> peloverde: I want to email it just because
[18:36:33 CEST] <peloverde> go for it
[18:45:44 CEST] <Daemon404> ... wtf
[18:45:56 CEST] <Daemon404> im trying to delay xmv stream creation until a packet is read
[18:46:04 CEST] <Daemon404> but xmv_read_packet is *never called* during find_stream_info!
[18:46:20 CEST] <wm4> wat
[18:46:29 CEST] <Daemon404> ikr
[18:46:38 CEST] <wm4> what's the fate test for this again?
[18:46:51 CEST] <Daemon404> fate-demux-xmv
[18:47:26 CEST] <Daemon404> i added a printf to the read_packet function and it never prints
[18:48:04 CEST] <wm4> actually it's fate-xmv-demux
[18:48:16 CEST] <Daemon404> (i removed the avformat_new_stream calls in read_header)
[18:48:55 CEST] <wm4> did you set the NOHEADEr flag?
[18:49:02 CEST] <Daemon404> oh!
[18:49:03 CEST] <Daemon404> i didnt know
[18:50:37 CEST] <Daemon404> i should be able to fix this now
[19:15:03 CEST] <BBB> michaelni: is SwsVector still a header existing in public headers after your change?
[19:15:53 CEST] <BBB> I guess it has to be b/c of SwsFilter, right?
[19:16:02 CEST] <BBB> michaelni: I think patch is fine then, at least its progress, tnx
[19:21:16 CEST] <Daemon404> nevcairiel / wm4 - xmv is fixed
[19:21:33 CEST] <Daemon404> fate is all passes now.
[19:22:14 CEST] <JEEB> wohoo
[19:25:52 CEST] <Daemon404> also ubitux 
[19:27:54 CEST] <Daemon404> i will convert what i can that is left
[19:28:37 CEST] <Daemon404> help sending bits that cant be sent to the ML welcome
[19:29:00 CEST] <Daemon404> (although everyone seems stuck permanently in 'no time to do anything' zone :/)
[19:31:40 CEST] <Daemon404> ...
[19:31:41 CEST] <Daemon404> av_freep(&s->streams[i]->codec->rc_eq);
[19:31:45 CEST] <Daemon404> what the hell ffmdec
[19:32:28 CEST] <JEEB> lol
[19:34:06 CEST] <wm4> Daemon404: awesome
[19:34:23 CEST] <wm4> and I don't think there's a single line of ffserver related code that is sane
[19:34:32 CEST] <Daemon404> no of course not
[19:39:18 CEST] <Daemon404> i think i can maybe have codec use cleaned up by the endo f today
[19:39:20 CEST] <Daemon404> pretty excited.
[19:46:29 CEST] <Daemon404> only 3 files left
[19:46:41 CEST] <Daemon404> ffm, mux, and sdp
[19:55:58 CEST] <BBB> ffm \o/
[19:56:12 CEST] <Daemon404> mux is almost fixed
[19:56:16 CEST] <Daemon404> now sure wtf to do about ffm
[19:56:22 CEST] <Daemon404> nevcairie handled the other ffm thing
[19:56:36 CEST] <BBB> I was hoping to help by bringing sanity into sws design
[19:56:38 CEST] <BBB> but maybe not
[19:56:46 CEST] <BBB> lavf is just not my thing, sorry
[19:57:58 CEST] <Daemon404> ffm isnt even lavf IMO
[19:58:01 CEST] <Daemon404> it's a shitty ffserver hack
[20:00:12 CEST] <wm4> Daemon404: let the maintainer of ffserver handle it
[20:00:26 CEST] <wm4> after the merge
[20:00:36 CEST] <Daemon404> right
[20:00:37 CEST] <Daemon404> ok
[20:01:49 CEST] <JEEB> > ffserver > maintainer
[20:02:08 CEST] <wm4> and if there's drama this decision has backing by Daemon404 nevcairiel ubitux BBB and me I suppose?
[20:02:19 CEST] <BBB> we have logs
[20:02:32 CEST] <BBB> oh you mean nobody approved it"?
[20:02:42 CEST] <BBB> github link?
[20:02:43 CEST] <BBB> Ill review
[20:02:50 CEST] <wm4> ffserver:
[20:02:50 CEST] <wm4>   ffserver.c                            Reynaldo H. Verdejo Pinochet
[20:03:37 CEST] <rcombs> why does ffserver even exist
[20:03:49 CEST] <rcombs> or, if it's going to exist, why is it part of the main repo
[20:04:37 CEST] <j-b> for the same reason as usual?
[20:07:59 CEST] <wm4> it was added, thus it shall not be removed
[20:08:06 CEST] <wm4> for every code is holy
[20:08:21 CEST] <wm4> every code is sacred
[20:09:01 CEST] <BBB> :D
[20:10:26 CEST] <fritsch> i know that song
[20:10:43 CEST] <fritsch> probably will play it with my new: wireless power plug
[20:10:45 CEST] <fritsch> https://scontent-ams3-1.xx.fbcdn.net/hphotos-xpt1/t31.0-8/12901122_1055378191199904_6731891541910785989_o.jpg
[20:12:16 CEST] <wm4> can't it fry birds? otherwise I don't want it
[20:12:20 CEST] <durandal_1707> with what?
[20:12:29 CEST] <wm4> with that
[20:12:46 CEST] <fritsch> :-)
[20:12:56 CEST] <fritsch> it's a fake (of course) but nicely made
[20:14:01 CEST] <Daemon404> think i fixed mux.c... fate running
[20:14:03 CEST] <Daemon404> home stretch
[20:18:05 CEST] <Zeranoe> Does $arch in configure default to x86 if it isn't specified and a native compile is being preformed? I don't see it using uname or anything
[20:25:09 CEST] <Daemon404> nevcairiel / wm4 - how well do you understand bitstream filters
[20:25:15 CEST] <Daemon404> thats teh only ting left in mux.c to fix
[20:25:25 CEST] <Daemon404> i tried two ways that changed output
[20:25:29 CEST] <wm4> not too well
[20:25:38 CEST] <wm4> what's broken at all?
[20:26:05 CEST] <Daemon404> av_apply_bitstream_filters(st->codec, pkt, st->internal->bsfc);
[20:26:06 CEST] <Daemon404> in mux.c
[20:26:20 CEST] <wm4> is that something ffmpeg-original?
[20:26:23 CEST] <Daemon404> if i make a new avctx based on codecpar, or use the internal avctxs it has different output
[20:26:30 CEST] <nevcairiel> just do some intermediate fix, new bsf api doesnt need avcodec
[20:26:39 CEST] <nevcairiel> +context
[20:26:46 CEST] <durandal_1707> Different how?
[20:26:56 CEST] <Daemon404> nevcairiel, there is no immediate fix
[20:26:56 CEST] <nevcairiel> wm4: and yes, its part of rcombs' auto filtering
[20:27:18 CEST] <Daemon404> nevcairiel, should i just leave the warning
[20:27:22 CEST] <Daemon404> and fix it when i merge the new bsf api?
[20:27:32 CEST] <wm4> that sounds good
[20:27:59 CEST] <michaelni> BBB, ive deprecated the functions  which are unused outside in that first step. To get rid of the SwsVector and filter structs some suggestion is needed what to do instead. Theres some code that uses these features
[20:29:46 CEST] <BBB> you can keep the structs
[20:30:06 CEST] <michaelni> ok
[20:36:06 CEST] <BBB> I believe that ubitux and a few others here expressed interest in designing a more standard API interface that could replace the current one
[20:36:17 CEST] <BBB> Im more interested in the inner guts of things, so Id probably want to do that kind of work
[20:37:58 CEST] <Daemon404> wm4 / nevcairiel - just sdp.c left.. any ideas besides "shove it in side data"?
[20:38:46 CEST] <wm4> which part of it?
[20:38:50 CEST] <wm4> the speex crap?
[20:38:53 CEST] <Daemon404> yes
[20:39:04 CEST] <wm4> oh god
[20:40:50 CEST] <Daemon404> im not even sure i can use side data, since that requires access to either the stream or packets
[20:40:56 CEST] <Daemon404> and im not sure it has a packet by then
[20:41:07 CEST] <wm4> what does it even _do_
[20:41:27 CEST] <Daemon404>     sdp: output speex optional vbr parameter
[20:41:27 CEST] <Daemon404>     Optional sdp speex payload parameter is outputed only when
[20:41:27 CEST] <Daemon404>     data is encoded. It's not printed in case of stream copy.
[20:41:30 CEST] <Daemon404> according to git.
[20:41:38 CEST] <wm4> ah
[20:41:47 CEST] <Daemon404> vbr=on/vad/off
[20:41:53 CEST] <Daemon404> it looks a bit wtf
[20:41:57 CEST] <Daemon404> it is checking options on st->codec
[20:42:01 CEST] <Daemon404> but if youre not using that to encode
[20:42:04 CEST] <Daemon404> it wont even work.
[20:42:07 CEST] <wm4> so it needs to know how it was encoded
[20:42:26 CEST] <Daemon404> the code didnt even work with proper api usage
[20:42:32 CEST] <Daemon404> in the first place
[20:42:33 CEST] <Daemon404> >_>
[20:42:43 CEST] <wm4> so awesome
[20:42:45 CEST] <cone-919> ffmpeg 03Michael Niedermayer 07master:3b905b9fe611: swscale: Deprecate vector functions which are unused outside swscale
[20:43:03 CEST] <Daemon404> what is one to do in such a case
[20:43:10 CEST] <wm4> clearly there should be codecpar side data
[20:43:52 CEST] <Daemon404> i dont even know how one would fix it
[20:44:05 CEST] <Daemon404> considering it was broken to begin with
[20:45:23 CEST] <Daemon404> :/
[20:45:46 CEST] <wm4> does it break fate?
[20:45:51 CEST] <Daemon404> no
[20:46:02 CEST] <wm4> then fuck it and send the author of that patch a mail
[20:46:15 CEST] <Daemon404> all right
[20:46:22 CEST] <Daemon404> then merge fixup is done.
[20:46:31 CEST] <Daemon404> unless i am missing something
[20:46:39 CEST] <Daemon404> (and squashign and sending bits can begin)
[20:46:42 CEST] <durandal_1707> what's wrong with sdp?
[20:46:53 CEST] <wm4> durandal_1707: muxer tries to access encoder options
[20:47:28 CEST] <durandal_1707> huh?
[20:47:36 CEST] <wm4> what huh
[20:51:08 CEST] Action: Daemon404 pings nevcairiel to point out some patches to send (unless you marked them obviously already)
[21:03:48 CEST] <michaelni> Daemon404, "Test dca-core failed. Look at tests/data/fate/dca-core.err for details." "Assertion avctx->codec_id == s->parser->codec_ids[0] || avctx->codec_id == s->parser->codec_ids[1] || avctx->codec_id == s->parser->codec_ids[2] || avctx->codec_id == s->parser->codec_ids[3] || avctx->codec_id == s->parser->codec_ids[4] failed at libavcodec/parser.c:149"
[21:04:24 CEST] <michaelni> try codecpar with --assert-level=2
[21:08:00 CEST] <Daemon404> michaelni, all right
[21:08:13 CEST] <Daemon404> im preparing a small set that is independant right now
[21:08:17 CEST] <Daemon404> ill look after
[21:08:27 CEST] <Daemon404> jamrial, ping
[21:09:28 CEST] <Daemon404> gmm nvm
[21:14:40 CEST] <nevcairiel> Daemon404: will look those over tomorrow morning and send them
[21:16:03 CEST] <Daemon404> nevcairiel, do you have time tonight to look at a simple branch
[21:16:18 CEST] <Daemon404> its just the merge of adding the new api + your and jamrials and my fixes / addtions
[21:16:23 CEST] <Daemon404> specifically to the new api funcs
[21:16:37 CEST] <Daemon404> i figure that is a good starting place to merge
[21:24:43 CEST] <Daemon404> nevcairiel, https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expand=1
[21:24:50 CEST] <michaelni> Daemon404, also before the merge is pushed i think it should be announced so people can test it for crashes and regressions
[21:25:06 CEST] <Daemon404> michaelni, ok
[21:25:14 CEST] <Daemon404> intiially i'd like just to merge what i linked above
[21:25:21 CEST] <Daemon404> it wont break anything, it's only additions
[21:28:35 CEST] <wm4> that audio frame duration function is some funky stuff
[21:28:45 CEST] <Daemon404> part of it is a fix from jamrial 
[21:28:55 CEST] <Daemon404> that was squashed
[21:30:25 CEST] <Daemon404> er, actually, i need to unsquash that
[21:30:33 CEST] <Daemon404> 1 sec
[21:31:01 CEST] <jamrial> that was https://github.com/dwbuiten/FFmpeg/commit/7a3ef8ceac73b9077c63126d9c26377d86aabca1
[21:31:03 CEST] <Daemon404> yes
[21:31:18 CEST] <Daemon404> im pretty sure it should be squashed in
[21:31:22 CEST] <Daemon404> but not totally.
[21:31:41 CEST] <jamrial> that whole function is kinda crazy
[21:31:47 CEST] <Daemon404> yes
[21:31:58 CEST] <Daemon404> and yeah it should not be squashed 
[21:32:08 CEST] <Daemon404> let me review.
[21:33:18 CEST] <Daemon404> it was missing a ,
[21:33:24 CEST] <Daemon404> other than that it is ok
[21:33:33 CEST] <Daemon404> i will push that fix and ask michaelni and nevcairiel for review.
[21:34:48 CEST] <Daemon404> done
[21:34:53 CEST] <Daemon404> nevcairiel / michaelni - please take a look.
[21:34:59 CEST] <Daemon404> it should not be much work to review.
[21:35:57 CEST] <Daemon404> going to run fate just in case right now
[21:36:23 CEST] <kierank> dammit my assembly is the same speed as c
[21:41:09 CEST] <kierank> slower actually :(
[21:41:33 CEST] <jamrial> Daemon404: the seek_preroll commit in the squashwork branch should ideally include https://github.com/dwbuiten/FFmpeg/commit/10702f91d106b6ee212fce9e8cf29daf68e7234d
[21:41:48 CEST] <jamrial> but it can be added post merge anyway if that's easier for you
[21:41:59 CEST] <Daemon404> jamrial, ill squash it
[21:42:05 CEST] <Daemon404> it wont affect review in any case
[21:42:08 CEST] <jamrial> alright
[21:44:24 CEST] <Daemon404> michaelni / nevcairiel - fate passes on that branch
[21:44:47 CEST] <cone-919> ffmpeg 03Pedro Arthur 07master:6de58b49032a: swscale: cleanup unused code
[21:46:21 CEST] <Daemon404> jamrial, squashed
[21:46:53 CEST] <Daemon404> it should be good to merge IMO, but i will wait for nevcairiel to OK it for me.
[21:47:08 CEST] <Daemon404> and then ill start picking stuff to send to the ML
[21:50:26 CEST] <ubitux> so is it ready for the final review?
[21:50:42 CEST] <Daemon404> teh entire thing? no i have to pick/squash and send some mails.
[21:50:52 CEST] <Daemon404> but the very first bit is ready to merge if i get an OK
[21:50:57 CEST] <Daemon404> https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expand=1
[21:51:14 CEST] <ubitux> you can integrate chunks in this one
[21:51:23 CEST] <Daemon404> ?
[21:51:31 CEST] <ubitux> typically, you can add the AVMEDIA_TYPE_SUBTITLES case in this one
[21:51:37 CEST] <ubitux> where width/height are copied
[21:51:42 CEST] <Daemon404> right
[21:52:00 CEST] <Daemon404> the point of review ;)
[21:52:02 CEST] <ubitux> cac9ad979b518e6220626a85a7af86a3071bd867
[21:52:04 CEST] <ubitux> this chunk
[21:52:13 CEST] <ubitux> can be part of that merge
[21:52:40 CEST] <Daemon404> on it.
[21:52:55 CEST] <ubitux> are you going to add the delay/bframes thing and friends as well?
[21:53:40 CEST] <Daemon404> theyre already in there separately
[21:53:43 CEST] <Daemon404> rather than squashed
[21:54:11 CEST] <Daemon404> would people prefer the yare squashed into the merge commit?
[21:54:26 CEST] <Daemon404> nevcairiel / wm4 ^
[21:55:23 CEST] <michaelni> atomnuker, theres a randomly occuing crash with "./ffmpeg_g -i ~/tickets/1784/yo.raw.wav  -acodec aac -ac 6 -ab 384k -y test.aac" i dont have a backtrace yet
[21:56:09 CEST] <wm4> Daemon404: if they can be separate, why not keep it this way?
[21:56:11 CEST] <michaelni> but with enabled assertions it fails in av_clip_c() before crashing it only crashes if i comment the amin > amax abort out
[21:56:21 CEST] <Daemon404> wm4, i dont care either way
[21:56:52 CEST] <michaelni> crash happes in search_for_quantizers_twoloop i dont have line numbers yet
[21:57:44 CEST] <Daemon404> ubitux, i have added it as a separate commit for now
[21:58:33 CEST] <ubitux> Daemon404: with s/fix/will be needed for/ ?
[21:58:52 CEST] <ubitux> (also need for sub2video btw)
[21:59:24 CEST] <Daemon404> ubitux, i can add, but i thought it should be self explanatory that subs have a codecpar
[21:59:58 CEST] <ubitux> so you dropped the ()?
[22:00:08 CEST] <ubitux> (in the commit message)
[22:00:10 CEST] <Daemon404> yes
[22:00:18 CEST] <ubitux> ok!
[22:00:58 CEST] <Daemon404> i'd have liked to merge today, but i think it is too late in EU-time
[22:01:04 CEST] <Daemon404> people are starting to vanish
[22:01:16 CEST] <Daemon404> by merge i mean these few commits.
[22:01:54 CEST] <michaelni> atomnuker, crash doesnt occur if i build with debug symbols so i cant provde a backtrace
[22:02:48 CEST] <Daemon404> michaelni, sounds like heap corruptions
[22:04:45 CEST] Action: michaelni is tryng under valgrind but its slooow
[22:06:20 CEST] <ubitux> michaelni: passive aggressive method: add a fate test with that sample and wait for the fate valgrind instance to run on it
[22:08:50 CEST] <michaelni> i could but the sample is 8mb, ill try to find out if a subset of that triggers it
[22:10:29 CEST] <michaelni> valgrind output (with no crash occuring) http://pastebin.com/DdmJuvX9
[22:14:11 CEST] <ubitux> nevcairiel we miss you
[22:14:16 CEST] <jamrial> Daemon404: those couple commits should be safe to commit. except for the get_audio_frame_duration part, they are not making changes, just additions
[22:14:24 CEST] <Daemon404> yes
[22:14:27 CEST] <Daemon404> i also ran all of fate
[22:14:29 CEST] <Daemon404> twice.
[22:15:04 CEST] <jamrial> then go ahead
[22:15:20 CEST] <Daemon404> if nev smacks me, the fist is beign redirected to you!
[22:15:21 CEST] Action: Daemon404 runs
[22:15:45 CEST] <jamrial> haha
[22:16:09 CEST] <nevcairiel> did you squash all followup changes to the get audio frame duration thing?
[22:17:02 CEST] <jamrial> he's applying the frame_size and seek_preroll additions separately https://github.com/FFmpeg/FFmpeg/compare/master...dwbuiten:squashwork?expand=1
[22:17:30 CEST] <wm4> btw. why is initial padding and seek preroll separate? aren't they the same concept?
[22:17:58 CEST] <Daemon404> nevcairiel, i applied all i found
[22:18:02 CEST] <Daemon404> teh followups i mean
[22:18:09 CEST] <Daemon404> all of jamrial's
[22:18:27 CEST] <Daemon404> i will diff the functions in the branches before i push
[22:19:40 CEST] <jamrial> wm4: initial_padding is not separated. and the two i mentioned are our additions. IMO they don't really belong squashed in the merge of libav's commit
[22:20:44 CEST] <wm4> I mean, why are they separate fields
[22:20:54 CEST] <jamrial> oh
[22:21:10 CEST] <Daemon404> nevcairiel, theyre identical
[22:21:17 CEST] <Daemon404> md5sum of the file is even the same
[22:21:18 CEST] <jamrial> no, they are not the same concept, at least doesn't look like
[22:22:18 CEST] <wm4> I mean in both cases initial decoder output is skipped because it's invalid... seek preroll is for adjusting the seek target, but why wouldn't it be the same value as the initial padding
[22:22:25 CEST] <nevcairiel> no, its different concepts, the only codec with proper seek preroll i know is opus though
[22:22:30 CEST] <nevcairiel> at least the only one that cares to signal it
[22:22:47 CEST] <cone-919> ffmpeg 03Anton Khirnov 07master:998e1b8f521b: lavc: add codec parameters API
[22:22:48 CEST] <cone-919> ffmpeg 03Anton Khirnov 07master:a8068346e48e: lavc: add a variant of av_get_audio_frame_duration working with AVCodecParameters
[22:22:49 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:f9b1cf15c233: Merge commit '998e1b8f521b73e1ed3a13caaabcf79eb401cf0d'
[22:22:50 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:e6053b3b19c0: Merge commit 'a8068346e48e123f8d3bdf4d64464d81e53e5fc7'
[22:22:51 CEST] <cone-919> ffmpeg 03James Almer 07master:3fafde6cbe34: lavc: Add seek_preroll to AVCodecParameters
[22:22:52 CEST] <cone-919> ffmpeg 03Hendrik Leppkes 07master:5b4f8af2f1ac: Add frame_size to AVCodecParameters
[22:22:53 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:dd77dad4e6ff: codecpar: Add video delay field
[22:22:54 CEST] <cone-919> ffmpeg 03Clément BSsch 07master:be8d98c1ad38: lavc/utils: transfer width/height for subs in codecpar
[22:23:02 CEST] <jamrial> \o/
[22:23:03 CEST] Action: Daemon404 puts on bulletproof vets
[22:23:07 CEST] <Daemon404> vest*
[22:23:24 CEST] <jamrial> keep it for when the actual lavf changes are merged :p
[22:23:41 CEST] <Daemon404> indeed
[22:24:17 CEST] <JEEB> unts-unts \o/
[22:24:24 CEST] <wm4> suddenly ffserver users, devs, supporters everywhere
[22:24:42 CEST] <wm4> and it will be the end of the world
[22:24:50 CEST] <Daemon404> i dunno, the "maintainer" has 2 years to fix it
[22:24:53 CEST] <Daemon404> that is not unreasonable.
[22:25:39 CEST] <ubitux> i'd suggest to make an official post on the ml
[22:26:01 CEST] <michaelni> i might work on fixing ffserver if it had some kind of fate tests 
[22:26:04 CEST] <ubitux> so in 2 years when people will say "just don't drop this deprecate definery"
[22:26:18 CEST] <ubitux> you will have a message to refer to
[22:26:23 CEST] <Daemon404> ubitux, yes i plan to
[22:26:37 CEST] <Daemon404> i will cc reynaldo too.
[22:26:43 CEST] <michaelni> but with no real way to test iam afraid changing anything n it could do ore harm than good
[22:27:09 CEST] <Daemon404> i'd argue simply keeping ffserver alive does more harm than good.
[22:27:10 CEST] <Daemon404> so.
[22:27:23 CEST] <JEEB> yeah, so many poor folks trying to use it
[22:27:56 CEST] <JEEB> because it's in the code base and becomes available when  you install FFmpeg in a distro usually
[22:27:56 CEST] <michaelni> it would be nice to have a "ffserver" that supports modern protocols and is easy to use
[22:28:08 CEST] <JEEB> well depends on what exactly you need
[22:28:16 CEST] <JEEB> a lot of stuff is already possible with ffmpeg itself
[22:28:16 CEST] <Daemon404> that wouldnt pretty much necessitate a rewrite
[22:28:21 CEST] <Daemon404> also what jeeb said
[22:28:37 CEST] <JEEB> and then you have extensions to http servers like nginx-rtmp
[22:28:44 CEST] <JEEB> (it just takes in rtmp and serves HLS/DASH)
[22:29:08 CEST] <JEEB> or whatever the OSS shoutcast thing was
[22:29:11 CEST] <JEEB> icecast?
[22:29:39 CEST] <ubitux> there was crtmpserver or sth like this too?
[22:30:00 CEST] <JEEB> yeah, I think that was an actual rtmp thing for end users tho
[22:30:11 CEST] <JEEB> and flash is becoming less relevant these days
[22:30:26 CEST] <wbs> JEEB: crtmpserver does other formats as well, or at least in the commercial version
[22:30:29 CEST] <JEEB> ah
[22:30:31 CEST] <JEEB> ok
[22:31:46 CEST] <ubitux> Daemon404: just realized that code should probably use ff_alloc_extradata
[22:32:27 CEST] <kierank> is it possible in yasm to use an offset to a field in RODATA?
[22:32:33 CEST] <Daemon404> ubitux, should be easy to fix :P
[22:32:54 CEST] <ubitux> ah no, wait, it's in lavf
[22:33:11 CEST] <ubitux> why the hell is it there
[22:33:51 CEST] <ubitux> well whatever
[22:34:34 CEST] <Daemon404> "why the hell <...>"
[22:34:39 CEST] <Daemon404> that is me every day for the last two weeks
[22:34:41 CEST] <Daemon404> fixing hacks
[22:40:13 CEST] <BBB> kierank: what exactly?
[22:40:24 CEST] <BBB> kierank: what are you trying to do?
[22:40:30 CEST] <kierank> like do pshufb   m0, [v210_uyvy_chroma_shuf+10] or whatever
[22:41:53 CEST] <BBB> that should work, except it should be 16-byte aligned
[22:42:06 CEST] <kierank> ah might as well declare a new one then
[22:42:17 CEST] <BBB> oh the align was the problem? sorry about that
[22:42:52 CEST] <kierank> yeah I'm writing a v210 -> uyvy422-10bit converter and the masks and shuffles have a repeating pattern
[22:43:00 CEST] <BBB> right udnerstood
[22:43:06 CEST] <BBB> yeah just make copies
[22:43:11 CEST] <BBB> its a little wasteful but its ok
[22:43:13 CEST] <BBB> memory is cheap
[22:43:18 CEST] <BBB> at this rate, at least
[22:43:51 CEST] <Gramner> cache isn't really cheap, but yeah, a few bytes is unlikely to matter
[22:45:30 CEST] <kierank> v210 -> uyvy422-10bit is a nightmare, requires palignr
[22:49:58 CEST] <Daemon404> nevcairiel, sending one of your patches to the ML.
[23:07:04 CEST] <Daemon404> 53
[23:11:09 CEST] <cone-919> ffmpeg 03Derek Buitenhuis 07master:54ccaaeb2b93: psxstr: Remove some commented out code
[23:31:27 CEST] <Daemon404> blarg, done for the day. have fun picking some patches tomorrow, nevcairiel.
[23:46:28 CEST] <michaelni> Daemon404: ./ffmpeg-codecpar-dooall-2016-0331-21 -f concat -i ~/tickets/3108/concatfile.txt -codec copy out.avi <-- gives 250 frames and error while git master gives 500 and no error
[23:54:06 CEST] <Daemon404> michaelni, is that with the branch
[23:55:59 CEST] <michaelni> your branch yes
[23:56:18 CEST] <Daemon404> all right
[23:56:28 CEST] <Daemon404> im not doing any fixes today though, im beat.
[23:56:45 CEST] <michaelni> sure, iam just trying to do some random testing
[00:00:00 CEST] --- Fri Apr  1 2016