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

[burek]

[00:00] <mraulet> correct extensions here https://dl.dropboxusercontent.com/u/588600/hevc_bitstreams.zip
[00:04] <mraulet> some x86 12bits assembly commits 3fcb7a4595a6f40100a22110a5805e3b7510c0fd 97d46afe320c7d61d7b9525e5f5588355cde4bb0 a3f7282eaa6f1ab0524fb966c6eade50c3025f99
[00:09] <mraulet> michaelni: if we have in fate reference a bitstream with a wrong reference we can correct it?
[00:09] <mraulet> ie https://github.com/OpenHEVC/FFmpeg/commit/903236292f066bc321080e3e2192b64f8943d960
[00:15] <michaelni> mraulet, if the bitstream was used by a previous ffmpeg make fate, we can very likely not fix it
[00:15] <michaelni> it would break bisecting with make fate 
[00:15] <mraulet> so this bitstream has another version number
[00:16] <mraulet> we can use another version number and use it into hevc.mak and remove the old one
[00:16] <mraulet> ?
[00:17] <michaelni> we can add files to the rsync server and we can stop using files from the server in make fate, yes but we cant remove files from the server unless they where never used
[00:18] <mraulet> ok
[00:18] <michaelni> should i upload the files from the zip ?
[00:18] Action: michaelni just double checking
[00:19] <mraulet> yes
[00:19] <mraulet> I will add one more
[00:22] <mraulet> https://dl.dropboxusercontent.com/u/588600/RAP_B_Bossen_2.bit it has the same md5 hash than RAP_B_Bossen_1.bit
[00:23] <mraulet> I will fix the commit tommorrow once bitstreams are uploaded on fate
[00:24] <michaelni> if it has the same hash why should it be uploaded ?
[00:24] <BBB> I think he means the output of ffmpeg was wrong
[00:25] <mraulet> exactly
[00:25] <mraulet> jctvc (MPEG/ITU) provided wrong key before
[00:26] <mraulet> this commit fixes it according to the hash provided by the experts 
[00:26] <mraulet> https://github.com/OpenHEVC/FFmpeg/commit/903236292f066bc321080e3e2192b64f8943d960
[00:27] <mraulet> *according to the new hash
[00:29] <michaelni> if the ffmpeg output was wrong, there should be no need to reupload the same file
[00:32] <mraulet> ok
[00:32] <mraulet> so then the commit is ok
[00:44] <michaelni> bitstreams uploaded
[00:52] <mraulet> got them thanks
[01:16] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:a06fac353ce2: avformat/mux: ignore delayed vp8/9 packets in max_interleave_delta calculation
[01:55] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:7bdcf5c934f0: x86/hevc: add 12bits support for deblocking filter
[01:55] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:7df98d8c4d97: x86/hevc: remove unused constant in deblocking filter
[02:00] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:bd0f2d316fae: x86/hevc: add 12bits support for MC
[02:10] <llogan> are there any significant differences between using native nut and libnut for demuxing and/or muxing?
[02:16] <cone-217> ffmpeg.git 03Mickaël Raulet 07master:f6e218a02d6f: hevc: fix RAP_B_Bossen
[02:34] <cone-217> ffmpeg.git 03Diego Biurrun 07master:ff85334375c6: mpegvideo: Drop unused MPEG_BUF_SIZE and CHROMA_444 defines
[02:34] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:0a9bab5be64f: Merge commit 'ff85334375c6733c6116ea3686f128b4a11f33e7'
[02:37] <Timothy_Gu> llogan: yes. libnut is broken, nut is working.
[02:45] <cone-217> ffmpeg.git 03Diego Biurrun 07master:4fbb62a21bd0: mpegvideo: Move ME_MAP_* defines to the only place they are used
[02:45] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:8b395315a5e7: Merge commit '4fbb62a21bd04bf261da2382d5ba6c249c702af8'
[02:54] <cone-217> ffmpeg.git 03Diego Biurrun 07master:d8520d3ee032: mpegvideo: Move QMAT_SHIFT* defines to the only place they are used
[02:54] <cone-217> ffmpeg.git 03Michael Niedermayer 07master:7295ee7f51d9: Merge commit 'd8520d3ee032bf18f28897e0109f44b405caf5e3'
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:0f09436a4329: avfilter/vf_pullup: use ptrdiff_t as stride argument for dsp functions
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:97ccf31ecebc: avfilter/x86/vf_pullup: fix old typo
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:31b1589097cd: avcodec/hevc: Use av_malloc(z)_array()
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:969d8b9d60c1: avformat/utils: do not wait for packets from discarded streams for genpts
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:ab6dd7fea97f: avformat: add av_stream_get_parser() to access avformat AVParser
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:27375c25d9c8: ffmpeg: Use av_stream_get_parser() to avoid ABI issues
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:5302fa522bcf: avcodec/hevc_ps: do not loose all reference to pointers still in use
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:0bb71a85c398: avcodec/hevc_ps: prevent stale pointer in malloc failure case
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:b7638af9425a: avcodec/hevc: treat current_sps like sps_list
[03:21] <cone-217> ffmpeg.git 03Michael Niedermayer 07release/2.1:eb1e5cf818b9: avformat/dv: implement fallback in dv_extract_pack()
[03:21] <cone-217> ffmpeg.git 03Alessandro Ghedini 07release/2.1:aa09543659d8: vc1: Do not return an error when skipping b frames
[12:29] <cone-621> ffmpeg.git 03Christophe Gisquet 07master:036f11bdb565: x86: hevc_mc: replace simple leas by adds
[12:39] <mraulet> michaelni: support for bumping process f1e1ab74f6295d2ac3add2d19075c29739bc2945
[12:40] <mraulet> michaelni: fate for bumping process (new bitstream from yersterday) d4d61a071f087db2a4bc2b49559d40dd350a841e
[12:40] <mraulet> michaelni: fate for new bitstreams commits adcdabb4dd062694fb8de6df0faecaad1c36ba33 3b69a2dc469160ee87367191e630e8398e832227
[13:01] <cone-621> ffmpeg.git 03Lukasz Marek 07master:9a6ca20ef675: configure: replace pulse-simple with pulse
[13:04] <ubitux> > So that
[13:04] <ubitux> "-mno-red-zone" is not some "optional guideline". It's a hard and
[13:04] <ubitux> harsh requirement for the kernel, and gcc-4.9 is a buggy piece of shit
[13:04] <ubitux> for ignoring it.
[13:04] <ubitux> https://lkml.org/lkml/2014/7/24/584
[13:06] <ubitux> speaking of this gcc-4.9.1 is broken on my box as jamrial pointed out :(
[13:14] <J_Darnley> I've just been reading that too.
[13:22] <iive> it is always entertaining to read Linus
[13:32] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:c0a586d9d5cd: reintroduce avpriv_dsputil_init() to maintain ABI until next soname bump
[13:43] <wm4> ubitux: older versions are also affected, they just don't trigger in this specific case
[13:43] <wm4> older than 4.9, AFAIK
[13:43] <JEEB> "The bad compiler versions are 4.5.0 (when debug_insn came in) to 4.8.3 and 4.9.0 and 4.9.1."
[13:44] <ubitux> wm4: do you know what bug it is?
[13:44] <wm4> gcc really should focus a little on correctness
[13:44] <ubitux> i'm not sure it's actually related to what's mentioned in the lkml mail
[13:44] <wm4> ubitux: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61904
[13:45] <ubitux> right, but how do you know the aac failure is related to this?
[13:45] <wm4> what aac failure
[13:45] <ubitux> ah, seems it's now fixed for some random reason
[13:46] <wm4> the red zone bug is a kernel-only issue
[13:46] <wm4> probably
[13:46] <ubitux> wm4: i was refering to all my fate instances being yellow after the upgrade from 4.9.0 to 4.9.1 because of a failing aac test
[13:46] <ubitux> but they disappeared
[13:47] <ubitux> seems it was unrelated
[14:38] <BBB> so for hevc/h264, that startcode escaping, thats just to prevent 0x00000[012] sequences in the actual bitstream right? is that always done, even in already-packetized streams (rtp, mp4, etc.)?
[14:43] <kierank> iirc it is still done in mp4 etc
[14:47] <mraulet> BBB: always done
[14:47] <BBB> why
[14:49] <mraulet> you are speaking about AEB? or start_codes only?
[14:49] <mraulet> Anti Emulation Bytes
[14:50] <BBB> ABE is the escaping right?
[14:50] <BBB> 0x00000[0123] becomes 0x0000030[0123]
[14:50] <mraulet> you need to remove AEB before decoding the bitstream
[14:50] <mraulet> in all formats
[14:50] <mraulet> yes at the encoder side
[14:51] <BBB> so theres no format where the length is coded directly in the bitstream?
[14:51] <mraulet> it is with AEB
[14:51] <mraulet> in mp4
[14:51] <BBB> right, so thats my question
[14:52] <BBB> why, in mp4, if the length is known, do we need AEB
[14:52] <BBB> is it just because thats what people do? or is there some real reason why you want to escape startcode-like sequences in the bitstream because otherwise something would go wrong?
[14:53] <BBB> it seems to me you dont need startcodes (and likely dont have startcodes) in mp4, since you already know the length, no?
[14:53] <BBB> (Im not asking implementation; Im asking spec, design here)
[14:54] <kierank> probably for hrd purposes
[14:54] <kierank> so that the vbv doesn't change when moving from one to another
[14:54] <kierank> (then again it breaks with 3-byte startcodes and sps/pps)
[14:56] <BBB> Im going to have to question the sanity of this committee of old gray men that designed this spec
[14:57] <JEEB> mp4-sys is mostly controlled by le apple
[14:58] <mraulet> mr mp4 dave singer
[14:58] <JEEB> yup
[14:59] <mraulet> you can also ask Jean Le Feuvre from TelecomParis Tech
[14:59] <kierank> they'll tell you to look at gpac :)
[14:59] <kierank> since gpac is the reference to mp4 =p
[14:59] <Paranoialmaniac> lulz
[15:00] <kierank> Paranoialmaniac: are you going to vdd?
[15:00] <mraulet> Paranoialmaniac: you might have the answer for BBB
[15:01] <Paranoialmaniac> kierank: i haven't decided yet
[15:07] <mraulet> looking at the standard, it is to be agnostic from any containers
[15:07] <Paranoialmaniac> i think kierank's thought is reasonalble about AEB. 14496-15 even cares about hrd for filler data
[15:09] <mraulet> it is also forbidden in H.264 and HEVC to have startcodes inside a RBSP
[15:11] <Paranoialmaniac> well, it seems the spec of editors is confused about rbsp and ebps :P
[15:11] <Paranoialmaniac> NALUnitLength indicates the size of a NAL unit measured in bytes. The length field includes the size of both the one byte NAL header and the RBSP payload but does not include the length field itself
[15:11] <Paranoialmaniac> . NALUnit contains a single NAL unit. The syntax of a NAL unit is defined in the appropriate specification (e.g. ISO/IEC 1449610) and includes both the one byte NAL header and the variable length encapsulated byte stream payload.
[15:13] <Paranoialmaniac> you see the spec has a contradiction of the definition of NALUSample
[15:18] <BBB> it seems to me that the spec authors went out of their way to make .h264 output data (non-containerized) a well-supported use case, and they forgot that in the real world, nobody gives a fuck
[15:19] <BBB> and it just adds complexity
[15:25] <JEEB> there's a whole shitload of stuff in mpeg-4 systems that nobody but academics/GPAC has ever used
[15:25] <JEEB> I'm just thankful they're not thinking of doing similar shit with anything else yet
[15:51] <cone-621> ffmpeg.git 03Mickaël Raulet 07master:23480da0aa70: hevc: add support for bumping process
[15:59] <BBB> bump?
[15:59] <BBB> odd name
[15:59] Action: BBB goes take kids out
[18:29] <cone-621> ffmpeg.git 03James Almer 07master:1ace9573dce5: x86/hevc_idct: replace old and unused idct functions
[18:41] <smarter> BBB: I think it's just to make transcoding easier
[19:05] <ubitux> michaelni: the scope of "AVDSP" is not well defined
[19:06] <ubitux> as BBB says it will end up being filled with a bunch of stuff
[19:06] <ubitux> you probably want to split them, and actually move them to avutil
[19:07] <ubitux> (to avoid some lavc dep in lavfi notably)
[19:11] <michaelni> ubitux, you suggest that we move all idcts, dcts and other related functions to libavutil ?
[19:11] <ubitux> maybe
[19:11] <ubitux> i'm actually planing to add an fdct/idct in dctdnoiz
[19:11] <ubitux> but well
[19:12] <michaelni> ubitux, do you volunteer to do this ?
[19:12] <ubitux> but appart from fdct/idct that could stay in lavc, i think a few optimized utils could end up in lavu
[19:12] <ubitux> typically the sad or avg or stuff like that
[19:12] <ubitux> because they can be used a lot in filters as well
[19:12] <ubitux> but if you do that, it should be split from the fdct/idct anyway
[19:13] <ubitux> to me, it's different utils
[19:13] <ubitux> and it needs to be split
[19:13] <ubitux> not a whole "AVDSP" with all kind of ± shared shit
[19:13] <michaelni> you put alot of work on my sholders you realize this ?
[19:13] <ubitux> i'm really sorry :)
[19:14] <ubitux> but the point is too keep lightweight dep
[19:15] <michaelni> ubitux, if you want this, you should do it
[19:15] <michaelni> we can disable the filters that need it when shared libs are enabled
[19:16] <ubitux> well, i don't want to do that right now, but if you need to push a fix soon, at least don't make it public
[19:16] <ubitux> so it can be fixed later without too much trouble
[19:16] <michaelni> ubitux, this is prerequesite for debian packages
[19:16] <michaelni> its not a we can do it in a month thing
[19:17] <michaelni> its needed now
[19:17] <michaelni> so its either a volunteer doing that split, or we have to disable the filters
[19:17] <ubitux> ok, let me grasp the issue you're trying to really fix 
[19:17] <michaelni> ABI
[19:18] <michaelni> filters need the dsp code, other packages like mplayer need it too
[19:18] <michaelni> it must be public
[19:18] <michaelni> and its ABI/API must be stable
[19:19] <michaelni> iam happy with any solution but it cant just be left as is
[19:19] <ubitux> what's get_pixels()?
[19:22] <michaelni> 8x8 8bit ->16bit
[19:22] <ubitux> what's the usage?
[19:22] <ubitux> pre-dct?
[19:22] <michaelni> yes
[19:23] <michaelni> one can argue it and diff_pixels belong to fdct 
[19:23] <ubitux> why diff_pixels?
[19:23] <ubitux> ah because of only residual being coded?
[19:24] <ubitux> then i'd have a lavc AVDCT with get_pixels/idct/fdct, and lavu AVDSPUtils with diff_pixels and sad
[19:25] <ubitux> (and eventually diff_pixels being instanciated in AVDCT)
[19:25] <ubitux> diff_pixels and sad should be in lavu because they're useful in a bunch of filters
[19:25] <ubitux> and it's "generic"
[19:26] <ubitux> about ME i don't know
[19:26] <ubitux> it seems there is only sum_abs_dctelem to put somewhere, but with the "dctelem" it doesn't sound like it would belong to AVDSPUtils in lavu
[19:26] <ubitux> unless it's actually a generic func and could be renamed to sub_abs_16 or something
[19:27] <michaelni> make it int16
[19:27] <michaelni> instead of dctelem
[19:27] <michaelni> its not as if the asm would work if it was somethning else
[19:28] <ubitux> ah, sad is actually this
[19:28] <ubitux> ah, no
[19:29] <ubitux> michaelni: ok so i guess you want me to rush an API somehow with this?
[19:29] <michaelni> "rush" is the wrong word IMHO
[19:30] <michaelni> we just need these functions available and that need isnt new
[19:32] <michaelni> i am not against spliting it between libavutil (for common usefull functions) and libavcodec for more codec specific ones
[19:33] <ubitux> ok so, what about we start by creating a AVPixelsUtils with a scope being defined as "Generic simple pixels utils for usage in codecs and filters", with sad, diff_pixels, (get_pixels ?), and sub_abs_int16?
[19:34] <ubitux> and we take this opportunity to remove the lavc dep completely for a bunch of filters doing this
[19:35] <ubitux> then there is fdct/idct, which would actually be move in a lavc "AVDCT" context
[19:35] <ubitux> i'm not sure where the ME remaining bits would stand
[19:36] <michaelni> ubitux, so you suggest i should rename AVDSP -> AVDCT and drop non dct stuff ?
[19:36] <ubitux> yes
[19:36] <michaelni> AVDCT8x8 rather
[19:36] <michaelni> because its just 8x8
[19:36] <ubitux> i don't know exactly
[19:36] <ubitux> not sure how useful a "DCT" context could be
[19:37] <ubitux> like, we have all kind of possible DCT algorithm with different types, speed and numerical stabilities
[19:37] <michaelni> AVPixelsUtils sad is used by ac3enc
[19:37] <ubitux> it doesn't matter it's in lavu
[19:37] <ubitux> lavu is basically accessible from everywhere
[19:38] <ubitux> what do you want AVDCT to become?
[19:38] <ubitux> only a very specific 8x8 DCT?
[19:39] <ubitux> i mean, i'm actually looking at a 16x16 DCT for dctdnoiz
[19:39] <ubitux> it could belong here too
[19:39] <michaelni> my plan was to introduce AVDSP and add to it what we need from external applications and libavfilter
[19:39] <michaelni> but you and BBB dont like that
[19:39] <michaelni> so its MUCH more complex
[19:39] <ubitux> i'm afraid of having a context with everything into it
[19:40] <ubitux> we just need to define the scope properly
[19:40] <michaelni> its harder for us and its harder for our users
[19:40] <michaelni> iam ok with it but i dont want to have to do the work
[19:40] <ubitux> i'll try to do something tonight
[19:40] <ubitux> but i want to define first what we want
[19:41] <michaelni> sure
[19:41] <michaelni> but thats not so easy
[19:41] <ubitux> i'm unsure about the DCT/iDCT currently
[19:41] <michaelni> one can go as generic or specific with that as one wants
[19:42] <ubitux> i plan to write a very specific doxy above the struct
[19:42] <ubitux> so it doesn't evolve randomly
[19:42] <ubitux> anyway
[19:42] <ubitux> should i start with the sad & friends first?
[19:43] <michaelni> whatever you like
[19:43] <ubitux> ok
[19:43] <michaelni> just tell me if i should rename AVDSP remove non *dct and resubmit ?
[19:44] <michaelni> but can wait too i have other ffmpeg work iam working on atm
[19:44] <ubitux> mmh so rename to what?
[19:44] <ubitux> it's only the JPEG DCT?
[19:44] <michaelni> yes
[19:44] <ubitux> well then... AVJPEGDCT? :p
[19:44] <michaelni> i really thin thats a bad name
[19:45] <ubitux> why?
[19:45] <michaelni> dct("jpeg") or dct(8,8) ?
[19:45] <ubitux> isn't jpeg dct implicitely 8x8?
[19:46] <ubitux> i'm fine with AVDCT8x8 ofc
[19:46] <michaelni> it is but but why add indirection in the name
[19:46] <ubitux> because all other codecs have a different DCT for 8x8?
[19:46] <michaelni> no
[19:46] <ubitux> or do you plan to move the VP9 DCT into that context as well?
[19:48] <michaelni> i dont plan to, and i dont see the need to, but then i also dont see a reason why not if that would be what user apps want
[19:48] <michaelni> for example if its faster and can be used as substitute in some algo
[19:49] <ubitux> btw, do you plan to move the few (jpeg) float DCT 8x8 into it?
[19:50] <michaelni> all 8x8 dcts and idcts from the current contexts are available through AVDSP and would stay available in AVDCT*
[19:50] <michaelni> most user apps would want the fastest no matter which simd implementation or permutation type
[19:52] <BBB> michaelni: this isnt novel
[19:52] <BBB> michaelni: see e.g. AVFFT
[19:52] <BBB> thats a well-defined, very limited-scope public api
[19:52] <BBB> in fact, its not even direct function wrappers, its an api on top of that so you call functions, not function pointers
[19:53] <BBB> michaelni: why dont you try to model it after that, but call it AVDCT
[19:53] <ubitux> we mostly agreed on AVDCT
[19:53] <ubitux> i wasn't sure if it was too generic or should be more specific
[19:53] <ubitux> but i guess that's fine
[19:53] <BBB> Im not sure I like the idea of function pointers in a public API& AVFFT is not like that
[19:54] <BBB> well& its a DCT
[19:54] <ubitux> BBB: what about the permutations?
[19:54] <michaelni> what about SIMD
[19:54] <BBB> AVFFT has simd
[19:54] <BBB> check how it does it
[19:54] <BBB> Im not against function pointers btw, just pointing out differences
[19:55] <BBB> if you feel function pointers is fine, Im moderately ok with that
[19:55] <BBB> as for permutations, as longas its self-contained, its fine in the struct
[19:56] <michaelni> i dont mind which way its done, i just dont want to do this redesign because i dont "belive" in it improving anything
[19:56] <BBB> ubitux: so this is a model DCT, right? its a relatively high-precision dct with no specific application to any particular codec (like DHT/DWT/vp9-DCT/vp8-DCT/hevc-DCT, which are all bitexactly defined and basically slight variations on the model DCT)
[19:56] <ubitux> so i'm fine with lavc (with permutations it doesn't belong in lavu) AVDCT with only the DCT stuff
[19:57] <ubitux> but the permutations are very JPEG/MPEG specific, and the context will stays like this
[19:57] <iive> mpeg-DCT sounds like reasonable variant.
[19:57] <ubitux> PEGDCT
[19:57] <ubitux> alias PeggyDCT
[19:58] <ubitux> BBB: "this"? you mean the dct in the current patch?
[19:58] <ubitux> it looks like very JPEG specific with ± accurate integer op
[19:59] <ubitux> michaelni: why would you export the FF_API* stuff into it?
[19:59] <ubitux> why are the arch optim as option?
[19:59] <BBB> its a whole collection of DCTs right?
[19:59] <BBB> its not a bitexactly defined DCT
[19:59] <michaelni> whole collection, yes
[19:59] <BBB> just some relatively high-precision variants that are approximately identical and optimized per-arch (with slight rounding differences)
[20:00] <BBB> or even precision differences, whatever works best for that arch
[20:00] <ubitux> i don't understand the need for the "mmx" and similar options
[20:00] <michaelni> the filters that use it like spp are very dependent on its speed so tehy need the fastest
[20:00] <BBB> its not bitexact to the C one
[20:00] <BBB> so you can specify that you want the fastest, or the best, or (for testing) a specific one (e.g. MMX)
[20:00] <BBB> same like we do -cpuflags for testing of all optimizations
[20:00] <ubitux> yeah but it needs another name then no?
[20:01] <ubitux> like what happens if i pick "simplearmv5te" on my intel?
[20:01] <michaelni> yes, the *dct_algo is quite finegrained
[20:01] <BBB> same thing as when you happen to use -cpuflags mmx on arm
[20:01] <BBB> nothing good ;)
[20:01] <ubitux> it should be something like "fast", "simple", "accurate" or whatever
[20:01] <ubitux> the cpu flags are at another level
[20:01] <ubitux> we have an api for that
[20:01] <BBB> we didnt have that back then
[20:02] <BBB> I agree its kind of weird
[20:02] <ubitux> right, but i'm looking at the patch introducing this
[20:02] <BBB> and then theres xvid, etc. routines
[20:02] <ubitux> in a brand new exported public api
[20:02] <BBB> which are optimized to match the fdct in the encoder
[20:02] <ubitux> so i'm a bit uncomfortable
[20:02] <BBB> do we need that at all?
[20:02] <BBB> why not hide that inside lavc
[20:02] <BBB> and export it without that
[20:02] <ubitux> yes please :)
[20:03] <BBB> I mean were not using this as a xvid filter
[20:03] <BBB> its a denoise filter etc.
[20:03] <BBB> they will never use this stuff
[20:03] <ubitux> btw
[20:03] <ubitux> BBB: 19:33:46 <@ubitux> ok so, what about we start by creating a AVPixelsUtils with a scope being defined as "Generic simple pixels utils for usage in codecs and filters", with sad, diff_pixels, (get_pixels ?), and sub_abs_int16?
[20:03] <ubitux> do you mind this?
[20:03] <BBB> (unless the user is pressing buttons he shouldnt press)
[20:03] <BBB> as long as its not exported, sure
[20:03] <ubitux> ??
[20:03] <BBB> if its exported, Ill frown a little
[20:03] <ubitux> it will
[20:03] <BBB> hm...
[20:03] <ubitux> in lavu
[20:03] <BBB> I guess its ok
[20:03] <ubitux> for lavc and lavfi
[20:04] <BBB> make sure its disabled in decoder-only builds
[20:04] <BBB> then its fine
[20:04] <ubitux> it's "pixels utils", so not codec specific
[20:04] <ubitux> just a bunch of useful diff/sum stuff
[20:04] <BBB> right but you dont want that in chrome
[20:04] <BBB> (in fact, that returns us to lets make lavu pieces build-configurable)
[20:04] <ubitux> not already the case?
[20:05] <BBB> yes, but lets not make it worse
[20:05] <BBB> I spent some time making dsputil not needed for chrome
[20:05] <BBB> it was a big thing, like, really big
[20:05] <ubitux> the context could return NULL when not available
[20:05] <BBB> it saved several 100kb on a 20-mb package
[20:06] <BBB> so do we _need_ this in lavu?
[20:06] <ubitux> diff pixels are typically very useful in filters
[20:06] <BBB> I dont mind lavfi depending on such tools in lavc
[20:06] <ubitux> same for sad
[20:06] <ubitux> yeah but it's not very codec specific
[20:07] <BBB> I suppose...
[20:07] <BBB> I cant think of anything better, so sure, feel free to put it in lavu
[20:07] <ubitux> BUT
[20:07] <ubitux> :)
[20:07] <ubitux> in lavfi we could probably process them as line
[20:07] <ubitux> or something
[20:07] <BBB> depends how you use the results
[20:07] <BBB> if you use the results for a dct, you want it block-based
[20:08] <BBB> if you dont, then & sure
[20:08] <ubitux> sad, pix_abs and stuff are currently in ME code
[20:08] <ubitux> i think it really belongs in a pixel utils context
[20:08] <BBB> well the most typical use case for sad is ME, yes
[20:09] <BBB> the set of tools are basically RD and ME tools
[20:09] <ubitux> it's used in select (for scene detection) and it seems relevant for deshake
[20:09] <ubitux> (in lavfi)
[20:09] <BBB> deshake is basically ME, isnt it?
[20:09] <BBB> so that only fits
[20:09] <BBB> I dont know what select does
[20:09] <ubitux> scene detection
[20:10] <ubitux> (it's in select filter so you can pick only the frame when it differs a lot from the previous one)
[20:10] <ubitux> (typically useful to pick thumbnails)
[20:11] <BBB> oh I see, sure, yeah
[20:11] <ubitux> so, a lavu/AVPixelsUtils with sad & friends, and optional at build time (in which case av_get_pixels_utils_ctx() would return NULL)
[20:11] <ubitux> ?
[20:11] <BBB> sure, sounds ok to me
[20:12] <BBB> AVDCT stays in lavc?
[20:12] <ubitux> (do we have already configurable items in lavu like this?)
[20:12] <BBB> no
[20:12] <BBB> :-p
[20:12] <ubitux> ah.. :)
[20:12] <ubitux> ok
[20:12] <ubitux> AVDCT should stay in lavc
[20:12] <ubitux> it has permutation stuff
[20:12] <ubitux> which is codec specific
[20:12] <BBB> ok
[20:13] <BBB> but idct_type will stay private (i.e. not part of AVDCT), right?
[20:13] <BBB> I dont think theres any need for that ATM
[20:13] <BBB> (given the uses)
[20:13] <ubitux> currently all the options are exported as is
[20:14] <BBB> code can be removed
[20:14] <ubitux> but i believe there should be translated to "fastint", "int"
[20:14] <ubitux> not sure what's the diff between "fastint" and a "fast"+arch
[20:15] <ubitux> actually, even int could probably be dropped
[20:15] <ubitux> i'm not sure how much variants needs to be accessible
[20:15] <ubitux> we just want a "accurate" and a "fast" one
[20:15] <ubitux> that should be the only exported bits
[20:15] <BBB> kinda like -flags +fast?
[20:15] <ubitux> so as option, only dct={accurate,fast} and idct={accurante,fast}
[20:15] <BBB> or -flags +bitexact
[20:16] <ubitux> yeah it's set through avoptions
[20:16] <BBB> ok
[20:16] <BBB> michaelni: ok?
[20:16] <BBB> has anyone played with subidcts in hevc?
[20:16] <BBB> they gave massive gains in vp9, i only see dc_add optimizations so far
[20:17] Action: ubitux afk a bit, will work on lavu/AVPixelsUtils ASAP
[20:18] <michaelni> fast, accurate hmm, theres also no permutation vs permutation
[20:18] <ubitux> do you need that exported?
[20:18] <michaelni> some user apps might want "no permutation"
[20:19] <ubitux> when do we actually ever need the permutation outside lavc?
[20:20] <michaelni> vf_spp
[20:20] <michaelni> and theres the fast int (AAN) FDCT that requires postscaling
[20:20] <michaelni> squishing that in accurate vs fast seems tricky
[20:21] <ubitux> ok
[20:21] <michaelni> and we have a float based FDCT, which leads to the question of where to put that speed wise related to int
[20:21] <michaelni> the float AAN one is probably the most accurate but id have to recheck
[20:21] <ubitux> well, as long as you remove the arch specific option names
[20:21] <ubitux> i'm fine with whatever granularity
[20:22] <ubitux> gtg, bb sson
[20:22] <michaelni> ubitux, sure bye
[20:26] <michaelni> "<BBB> michaelni: ok?", iam really fine with any solution people like
[21:13] <cone-621> ffmpeg.git 03Anton Khirnov 07master:884f7c975f0a: output example: set the stream timebase
[21:13] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:1c0c19f8bd4b: Merge commit '884f7c975f0af25febe86660e87bf3b2165a0309'
[22:42] <ubitux> what are the "sse" functions in lavc/me_cmp.c?
[23:02] <ubitux> does it make sense to have a configurable height for sad8/sad16?
[23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:9ccb9c8df256: doc/examples/muxing: move swr context to OutputStream
[23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:ead22f42f4fc: doc/examples/muxing: pick a supported channel layout if stereo isnt supported by the encoder
[23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:5d2cf1ae8642: doc/examples/muxing: select a supported sample rate for the encoder, favor 44100
[23:05] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:7cf086555177: doc/examples/muxing: Support setting flags, for example for setting bitexact
[23:12] <michaelni> ubitux, sse = sum of squared error
[23:12] <ubitux> mmh ok, thx
[23:38] <cone-621> ffmpeg.git 03Anton Khirnov 07master:56f98e340fca: output example: convert audio to the format supported by the encoder
[23:38] <cone-621> ffmpeg.git 03Michael Niedermayer 07master:371cb96414bb: Merge commit '56f98e340fca894a76d1ddbe33118b8d8c4db34a'
[23:42] <ubitux>     if (INLINE_SSE2(cpu_flags) && !(cpu_flags & AV_CPU_FLAG_SSE2SLOW) && avctx->codec_id != AV_CODEC_ID_SNOW) {
[23:42] <ubitux>         c->sad[0] = sad16_sse2;
[23:42] <ubitux> ’ cfe675269bf44c49590e9076b5d2cd2503804f98
[23:42] <ubitux> why snow would use a sad16 (sad[0] is the 16 px width version)
[23:43] <ubitux> if it hasn't 16-bytes available?
[23:43] <ubitux> or is the sse2 version needing more that 16-bytes at once?
[23:43] <ubitux> (i'm asking just to make sure the sad16_sse2 requirements are indeed just a 16-byte width constraints)
[23:44] <michaelni> snow uses OBMC so 16x16 blocks overlap and dont always start at 16byte multiplies
[23:45] <ubitux> but the read are unaligned
[23:45] <ubitux> (or maybe not?)
[23:46] <michaelni> yes
[23:46] <ubitux> would psadbw be expected aligned pointers?
[23:46] <ubitux> expecting*
[23:47] <michaelni> basically all SSE* instructions expect aligned data except the unaligned moves
[23:47] <ubitux> what about mmx?
[23:48] <michaelni> mmx works with unaligned data
[23:48] <ubitux> mmh ok
[23:49] <ubitux> so basically, all C/MMX/MMXEXT are safe for unaligned access, but the SSE+ will require aligned data, at least for the second source
[23:50] <michaelni> C is safe within the data types
[23:50] <michaelni> so int64_t may need 8byte alignment
[23:50] <michaelni> mmx/mmxext should be safe
[23:50] <ubitux> no worry about C, it's a byte-per-byte diff afaict
[00:00] --- Sun Jul 27 2014