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

[burek]

[00:45:42 CET] <ubitux> wow i'm impressed at the asan report
[00:46:24 CET] <ubitux> http://sprunge.us/ZQHc this is cute
[00:48:34 CET] <JEEB> is that gcc or clang asan?
[00:49:34 CET] <ubitux> gcc
[01:04:20 CET] <wm4> Assertion !c->frac && !c->dst_incr_mod && !c->compensation_distance failed at libswresample/resample.c:391
[01:04:21 CET] <wm4> heh
[01:04:23 CET] <wm4> who broke it
[01:04:51 CET] <wm4> that happens when I start mpv with current git master
[01:04:56 CET] <wm4> *ffmpeg git master
[01:05:13 CET] <jamrial> maybe the recent patch that enabled linear inter and extact rational
[01:05:20 CET] <jamrial> by default, that is
[01:05:25 CET] <jamrial> 1f7eb216b085cfd4f18f328182cabe3f89093edd
[01:05:28 CET] <cone-551> ffmpeg 03wm4 07master:b4b8ca24f624: avcodec: fix uninitialized variable read
[01:05:36 CET] <jamrial> try disabling those
[01:06:27 CET] <nevcairiel> if they can assert, should turn that off again until fixed
[01:06:49 CET] <wm4> setting exact_rational to 0 "fixes" it
[01:07:37 CET] <jamrial> reply to the relevant thread on ffmpeg-devel and point this out
[01:07:52 CET] <wm4> this is probably due to avresample_set_compensation() or something
[01:07:54 CET] <jamrial> if Muhammad Faiz or michaelni can't fix it in the short term then that commit should be reverted
[01:18:06 CET] <jamrial> wm4: swr_set_compensation() :P
[01:20:28 CET] <wm4> oops
[01:20:29 CET] <wm4> yes
[01:20:39 CET] <wm4> my code is compatible to both swr and lavr
[01:20:46 CET] <wm4> it #defines lavr names for swr
[04:00:24 CET] <cone-551> ffmpeg 03Muhammad Faiz 07master:3ba7b47d5cb4: swresample/resample: do not assert compensation_distance on rebuild_filter
[05:41:40 CET] <wm4> does anyone want to review this? some Libav changes for frame threading, and also allowing enabling threads for hwaccel decoding: https://github.com/wm4/FFmpeg/commits/thread-merge
[05:42:05 CET] <wm4> there are weird differences between lock use in ffmpeg and libav, so I guess I have no idea what I'm doing
[05:43:42 CET] <wm4> it appears to work, but that means nothing if threads are involved
[09:18:00 CET] <kierank> BtbN: you can write one of those trivially
[09:38:58 CET] <mateo`> i'm working on merging the next commit (0638b99cdb)
[10:06:16 CET] <rcombs> are there any guarantees about AVFrame data and linesize alignments
[10:07:59 CET] <nevcairiel> yes
[10:08:29 CET] <nevcairiel> although there is one exception, if you decode rawvideo it may just map the packet into avframe without re-aligning it
[10:08:33 CET] <nevcairiel> not sure if that was ever fixed
[10:08:58 CET] <rcombs> what's the alignment
[10:10:26 CET] <nevcairiel> 32 if build  with AVX, 16 otherwise
[10:11:17 CET] <rcombs> ah, so from mem.c
[10:11:37 CET] <nevcairiel> avcodec/internal.h has STRIDE_ALIGN with the same things
[10:11:43 CET] <wm4> uh
[10:11:46 CET] <wm4> the alignment is random
[10:11:54 CET] <wm4> the one who allocates the AVFrame can set it
[10:12:12 CET] <wm4> so, I'm not sure what filters will do to it
[10:12:14 CET] <nevcairiel> i assumed he talked about libav* internally allocated frames
[10:12:29 CET] <rcombs> oh, I meant what lavc encoders and lavfi filters expect
[10:12:44 CET] <wm4> e.g. if you use vf_crop, it could unalign the start pointer
[10:12:45 CET] <rcombs> like, can lavfi code assume a particular alignment?
[10:12:51 CET] <nevcairiel> giving it 32 aligned stuff for avx is always safe either way
[10:13:00 CET] <rcombs> I know
[10:13:07 CET] <rcombs> I'm asking if lavfi makes any assumptions about it
[10:13:26 CET] <wm4> so I'd say any align should work (modulo tons of bugs), but 32 bytes should be safest
[10:13:52 CET] <rcombs> like, does any lavfi or lavc code take a frame and do e.g. movdqa from it
[10:14:13 CET] <nevcairiel> probably
[10:14:14 CET] <wm4> they shouldn't
[10:14:15 CET] <rcombs> obv being <mmsize> aligned is optimal for perf
[10:14:20 CET] <wm4> (but maybe do)
[10:14:22 CET] <rcombs> but does not being mmsize-aligned break things?
[10:14:54 CET] <nevcairiel> surprisingly the random lavfi code i opened uses movu and not mova
[10:15:30 CET] <rcombs> afaik movu isn't actually slower than mova on aligned data, right?
[10:15:44 CET] <nevcairiel> to summarize, try to output aligned things w hen you can, but don't assume it is aligned on input data, i guess
[10:16:05 CET] <nevcairiel> and yeah i believe the difference is minimal at best on modern cpus
[10:16:14 CET] <rcombs> assuming unaligned just means you can't use SSE instructions that take input directly from memory
[10:16:45 CET] <nevcairiel> at worst do what sws does and fallback to super-slow-c-mode when input isnt aligned
[10:17:14 CET] <nevcairiel> (although sws being sws, i'm sure it still crashes)
[10:40:54 CET] <Gramner> the penalty for unaligned memory accesses is significanlty lower on modern cpus than it used to be, but that doesn't mean that you shouldn't try to avoid it. the exact penalty varies between cpu archs, and depending on what boundaries it crosses. page split > cacheline split > within cacheline
[10:41:51 CET] <rcombs> Gramner: I meant the penalty for using movdqu (as opposed to movdqa) in the data-is-aligned case
[10:41:52 CET] <nevcairiel> the more important question is how bad is using movu for safety, if the data is aligned most of the time
[10:41:57 CET] <rcombs> yeah
[10:42:07 CET] <Gramner> movu is identical to mova on modern cpus when used on aligned data
[10:42:20 CET] <rcombs> cool, so when in doubt, movu
[11:01:39 CET] <wm4> Gramner: and that's how it should have been from the start
[11:01:48 CET] <wm4> silly cpu designers
[11:02:46 CET] <rcombs> and SSE doesn't allow unaligned access in non-movu instructions, but AVX does, right?
[11:50:23 CET] <mateo`> another pair of eyes to review the merge commit before i merge it ? https://github.com/mbouron/FFmpeg/commit/ad87f71a4768193cd3b8c4cf6469d0ad365a0c02
[11:52:19 CET] <cone-610> ffmpeg 03Konda Raju 07master:2db5ab73d43a: avcodec/nvenc: allow different const-qps for I, P and B frames
[12:16:39 CET] <cone-610> ffmpeg 03Anton Khirnov 07master:8db301deadfc: ffmpeg: set the encoding framerate when the output is CFR
[12:16:40 CET] <cone-610> ffmpeg 03Tobias Rapp 07master:205b8fd078e5: avcodec: estimate output bitrate for uncompressed video codecs
[12:47:41 CET] <cone-610> ffmpeg 03Diego Biurrun 07master:0638b99cdba5: aiff: Skip padding byte for odd-sized chunks
[12:47:42 CET] <cone-610> ffmpeg 03Matthieu Bouron 07master:e2adbcbd97de: Merge commit '0638b99cdba52554691fc668d9e477bc184c7a33'
[13:01:15 CET] <michaelni> ubitux, do you have a example of a filter command thats not bit exact for thomas ?
[13:02:44 CET] <ubitux> mmh owdenoise?
[13:03:50 CET] <ubitux> otherwise a random list of filters that probably arent either: lut3d, nlmeans, dctdnoiz, selectivecolor
[13:04:16 CET] <ubitux> michaelni: http://ffmpeg.org/pipermail/ffmpeg-devel/2013-May/143810.html
[13:04:28 CET] <ubitux> concrete example of non bitexact
[13:05:15 CET] <ubitux> a command is given here
[13:15:35 CET] <Gramner> rcombs: correct, only VEX-encoded (and EVEX for that matter) instructions support unaligned addresses. AMD had (or still has? no idea) some functionality where you could set a bit in some control reg and legacy-coded instructions would support it as well, but it was kind of annoying to use since it was a global flag and some poorly coded libraries would clobber it causing headaches
[13:17:32 CET] <michaelni> ubitux, thx
[13:24:31 CET] <atomnuker> "Hi sir, it takes me a great hornor for you to read my letter on your spare time." <- a GSoC applicant
[13:24:48 CET] <atomnuker> 0 points if you guess where they're from
[13:26:36 CET] <DHE> well don't leave us in suspense...
[13:29:22 CET] <atomnuker> "I will spare no effort to make it successfully if I become the lucky dog."
[13:29:45 CET] <kierank> wtf
[13:30:45 CET] <J_Darnley> Well there is probably a lot of competition for thing in countries of 1 billion plus people
[13:31:04 CET] <J_Darnley> So I guess they often use that level of politeness
[13:37:41 CET] <michaelni> atomnuker, you should not quote private mail on a publically logged channel unless you have the consent of the author (dont know if yu have)
[13:40:56 CET] <iive> atomnuker: japan?
[13:41:27 CET] <atomnuker> I'm sure they're far from unique for a letter of this type (and a given century)
[13:42:10 CET] <iive> you mean, country ;)
[13:43:24 CET] <atomnuker> not necessarily, you need both the time and space to be able to describe where something is
[13:46:09 CET] <wm4> michaelni: my patch will be applied, and I will fight for it
[13:47:43 CET] <Compn> you guys hating on that country again
[13:50:52 CET] <Compn> wm4 : arguing about policy is the least fun thing to do in the project :(
[13:53:28 CET] <wm4> I'm not the one who's adding terrible hacks for obscure/nonsense reasons
[13:53:39 CET] <wm4> which the side data merging exactly is
[13:56:21 CET] <Compn> oh this is new battle, nevermind , i was looking at old thing
[13:56:22 CET] Action: Compn hides
[13:57:15 CET] <wm4> yes, we always have to have battles for this
[14:01:54 CET] <nevcairiel> the framework excuse is a farce, you cant just put random data into media buffers and send it through a generic framework, because there could be non-avcodec components at the end. and if you only have avformat/avcodec stuff, you dont need a generic framework
[14:04:57 CET] <iive> atomnuker: the earth continents doesn't move so fast, so you rarely need to type When something is. ;)
[14:16:59 CET] <atomnuker> wm4: supposing that side data gets merged into the main packet and gets transmitted via like rtp or something
[14:17:12 CET] <atomnuker> the receiver can misinterpret the side data as part of the main packet, right?
[14:17:42 CET] <atomnuker> (particularly messing up the total size of the packet)
[14:21:24 CET] <BBB> atomnuker: did you get that also?
[14:21:31 CET] <BBB> atomnuker: I got that exact email
[14:22:00 CET] <BBB> ndiswrapper etc. ;)
[14:22:20 CET] <BBB> the experience that I participated a project involved in ndiswrapper
[14:23:11 CET] <BBB> its probably poor habit to make fun of peoples language, but this is really hard to decipher&
[14:23:59 CET] <atomnuker> ndiswrapper was a big thing 12ish years ago
[14:24:23 CET] <atomnuker> (I think?)
[14:24:31 CET] <atomnuker> suprising that crazy idea worked at all
[14:25:11 CET] <J_Darnley> Now that I've sent those patches I can go run some errands.
[14:25:24 CET] <iive> running windows wifi driver under linux
[14:30:17 CET] <BBB> J_Darnley: Im not sure avx is worth the trouble in cases where its 1.0x as fast as sse2...
[14:30:29 CET] <BBB> (e.g. idct8_add4)
[14:31:03 CET] <BBB> J_Darnley: also what does broken FATE mean? is that a comment
[14:32:13 CET] <nevcairiel> +; FIXME: I produce incorrect output
[14:32:14 CET] <nevcairiel> :D
[14:33:15 CET] <J_Darnley> Yeah.  The patch doesn't work.  It does something wrong and makes the decoder produce incorrect output, hence "broken FATE".
[14:33:44 CET] <J_Darnley> BBB: yeah, feel free to object and block any patches which provide no speed up.
[14:34:13 CET] <J_Darnley> I didn't push two deblock patches which were not any faster.
[14:34:16 CET] <BBB> maybe if it breaks fate its not such a great idea ;)
[14:34:27 CET] <J_Darnley> Only that one patch
[14:34:28 CET] <BBB> or does that mean please help me figure out why its not working"?
[14:34:36 CET] <J_Darnley> Also a little of that.
[14:34:38 CET] <J_Darnley> :)
[14:35:06 CET] <J_Darnley> But I am leaving for now so I will deal with that later.
[14:35:09 CET] <BBB> hehe ok
[14:35:12 CET] <BBB> later
[14:35:16 CET] <J_Darnley> Sayonara
[14:37:50 CET] <kierank> J_Darnley: i'm sure you're aware since you did the stats that some of your functions have dubious speedups
[14:38:36 CET] <BBB> I have no idea what that code is trying to do, why create -d? and the upper half of the xmm register is not ever filled (xmm=16bytes=8words, youre loading 1 word and doing two punpcklwd which fills 4 words)
[14:39:01 CET] <BBB> try to use the splat macros or something like that
[16:28:55 CET] <rcombs> so allegedly, new Rockchip hardware can decode H.264 High 10
[16:32:57 CET] <JEEB> rcombs: surprising
[16:33:18 CET] <rcombs> same
[16:33:23 CET] Action: kierank makes sure to send 422
[16:33:26 CET] <kierank> so hardware decoders fail
[16:33:28 CET] <JEEB> :D
[16:33:40 CET] <JEEB> "it's all about the pentiums, baby"
[16:35:07 CET] <rcombs> it's all about the A7s now
[16:35:37 CET] <atomnuker> I wonder if its bitexact
[16:35:54 CET] <rcombs> is H.264 bit exact?
[16:36:39 CET] <atomnuker> I mean to a reference
[16:36:59 CET] <rcombs> I mean, is decoding bitexact?
[16:39:01 CET] <atomnuker> that's the whole point of having specifications
[16:40:30 CET] <rcombs> I mean, e.g. MP3 has specifications but decoding it isn't bit-exact
[16:41:11 CET] <BBB> rcombs: h264 decoding is bitexact, yes
[16:41:16 CET] <BBB> its not like the old mpeg days
[16:41:21 CET] <rcombs> OK, good to know
[16:41:27 CET] <BBB> rcombs: decoding of hevc, vp8/9, etc. is also bitexact
[16:41:46 CET] <rcombs> but not MPEG-4 Part 2, or MPEG2/1?
[16:41:50 CET] <BBB> correct
[16:42:32 CET] <BBB> rcombs: audio is indeed fundamentally not bitexact, which becomes self-evident if you imagine that the most popular way to represent audio samples nowadays is float
[16:42:45 CET] <BBB> and therefore audio codecs are usually not requires to be bitexact either
[16:42:52 CET] <nevcairiel> unless you use lossless codecs of course
[16:42:56 CET] <rcombs> hey, float can be bit exact if you're a masochist
[16:43:17 CET] <BBB> lossless codecs then again are not float-based ;)
[16:43:23 CET] <nevcairiel> they can be!
[16:43:30 CET] <nevcairiel> als has a crazy float mode
[16:43:38 CET] <atomnuker> float is bitexact, its just that the C specs do not forbit using a higher precision float intermediates which breaks it
[16:43:44 CET] <atomnuker> *forbid
[16:43:53 CET] <jamrial> BBB: ALS apparently is to some extent :p
[16:44:12 CET] <jamrial> ah, nevcairiel beat me to it
[18:19:30 CET] <TD-Linux> video codecs became bitexact more out of necessity - reconstruction error would build up and destroy the image
[18:33:57 CET] <uu8> hi
[18:34:28 CET] <uu8> can someone tell me what the wd variable is at ffmpeg project
[18:34:37 CET] <uu8> where it is declared?
[18:35:28 CET] <uu8> ***where is it declared?
[18:36:22 CET] <Compn> uu8 : in codec? demuxer ?
[18:40:28 CET] <uu8> hmm
[18:40:43 CET] <uu8> in codec
[18:41:19 CET] <uu8> i tried to use grep to find the declaration but failed
[18:41:58 CET] <uu8> may be i do not have enough c knowledge to understand such a project but...
[18:43:26 CET] <uu8> or assembly
[18:44:04 CET] <Compn> where are you seeing wd? error ? patch ? output ?
[18:44:15 CET] <Compn> just trying to figure out where you are finding this variable :)
[18:44:36 CET] <uu8> @Compn : at source
[18:45:37 CET] <Compn> in what file ? sometimes wd means width , but i cant guarentee...
[18:45:38 CET] <uu8> in libavcoded/x86/dirac_dwt.asm
[18:45:45 CET] <Compn> ahhh diract 
[18:45:50 CET] <Compn> -t
[18:46:30 CET] <Compn> so you're talking about like this ,     mov    w2d, wd
[18:46:41 CET] <Compn> yeah thats assembly
[18:47:14 CET] <uu8> yeah :185
[18:51:37 CET] <Compn> that should be a standard cpu instruction for x86
[18:52:24 CET] <jkqxz> It's not a variable called "wd", it's a variable called "w" being used with doubleword width.
[18:54:05 CET] <nevcairiel> assembly doesnt really have the concept of "variables", its just named registers (or sometimes stack space)
[19:35:53 CET] <feliwir> BBB: i was told that you can explain me this: https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0c7f/libavcodec/vp6.c#L393 
[19:36:21 CET] <feliwir> and also how the entire VLC stuff is working in ffmpeg. I know how Huffman works, but ffmpeg is calling this VLC stuff everywhere
[19:36:35 CET] <feliwir> (when creating Huffman Trees etc.)
[19:38:33 CET] <BBB> whats your specific question?
[19:38:41 CET] <BBB> please explain this is too broad, I cant answer that
[19:46:23 CET] <atomnuker> feliwir: are you asking how the vlc codes reader works?
[19:52:17 CET] <feliwir> because the huffman decoding is the part i am missing for my own vp6 decoder
[19:52:31 CET] <feliwir> and the reference implementation libvp62 doesn't support it
[19:57:00 CET] <feliwir> atomnuker, why were you asking?
[19:57:57 CET] <atomnuker> just asking, its unusual for someone to be writing a decoder for a format not used seriously in a decade
[19:58:51 CET] <feliwir> atomnuker, well to be fair the specification is from 2006 :) I am mostly writing it because i am trying to rewrite an old game engine in C# (which used vp6 for videos)
[19:59:18 CET] <feliwir> https://github.com/feliwir/sage/tree/master/vp6
[19:59:26 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:21a8e751ad6a: fate: Do not report side data size
[19:59:27 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:f20bcec4c2b1: spherical: Change types of bounding and pad to uint32_t
[19:59:36 CET] <feliwir> also it is interesting to see that C# doesn't perform as bad as i've expected
[20:00:39 CET] <atomnuker> feliwir: which game?
[20:01:06 CET] <durandal_1707> i know the answer but will not tell it for free
[20:01:34 CET] <Compn> who bulgarian here ?
[20:01:34 CET] <atomnuker> please tell me its the first and only need for speed most wanted
[20:01:40 CET] <JEEB> lol
[20:02:04 CET] <atomnuker> it had hilarious vp6 greenscreened full motion videos
[20:02:08 CET] <Compn> er nevermind thats hungaruan...
[20:02:22 CET] <atomnuker> "First I'm going to take your ride, then I'm going to take your girl!"
[20:07:54 CET] <atomnuker> only command and conquer 3 fits the time frame
[20:15:40 CET] <uu8> hey thanks for the answers
[20:30:29 CET] <cone-527> ffmpeg 03Vittorio Giovara 07master:95a72aed764a: mov: Drop extra format specifier in error message
[20:32:23 CET] <feliwir> sorry, my bouncer keeps dcing me
[20:32:37 CET] <feliwir> did BBB already answer my question atomnuker ?
[20:33:24 CET] <BtbN> * feliwir has quit (Excess Flood)
[20:33:42 CET] <BtbN> your bnc does not disconnect you. Freenode kicks you for spamming them
[20:34:11 CET] <Compn> uu8 : why are you learning assembly? working on a bug in dirac ?
[20:34:28 CET] <feliwir> BtbN, what am i spamming?
[20:34:40 CET] <BtbN> no idea
[20:34:45 CET] <BtbN> It's your BNC, not mine
[20:34:59 CET] <BBB> feliwir: I did not see a question
[20:35:09 CET] <Compn> he means "excess flood" which is such a confusing quit message... :P
[20:35:31 CET] <feliwir> BBB, i was asking about huffman decoding in vp6. atomnuker told me you were the right for asking about that
[20:35:50 CET] <BtbN> well, it means your connection sent so much data to freenode that the server decided it's too much and kicked you
[20:35:54 CET] <Compn> [14:35] <feliwir> BBB: i was told that you can explain me this: https://github.com/FFmpeg/FFmpeg/blob/967feea5ebb744dce97ab327d33502b43fca0c7f/libavcodec/vp6.c#L393 
[20:35:54 CET] <Compn> [14:36] <feliwir> and also how the entire VLC stuff is working in ffmpeg. I know how Huffman works, but ffmpeg is calling this VLC stuff everywhere
[20:35:54 CET] <Compn> [14:36] <feliwir> (when creating Huffman Trees etc.)
[20:35:54 CET] <Compn> [14:38] <BBB> whats your specific question?
[20:35:54 CET] <Compn> [14:38] <BBB> please explain this is too broad, I cant answer that
[20:37:18 CET] <feliwir> sorry, didn't get that :)
[20:38:03 CET] <feliwir> well i don't understand how ffmpeg creates a huffman tree. The first parts make perfect sense where it sorts the nodes by probabilities
[20:38:29 CET] <feliwir> but then i starts calling some VLC functions, which are simply huge macro blocks
[20:41:04 CET] <feliwir> this is the part i have replicated so far: https://github.com/feliwir/sage/blob/master/vp6/Huffman.cs#L61 But from then i don't understand what FFmpeg is doing anymore. Also it would be nice to know what get_vlc2 is doing
[20:41:42 CET] <BBB> get_vlc2() is simply an optimized function for getting VLC codes
[20:42:06 CET] <BBB> if you want to understand what it does, look at it; if you simply want to replicate what it does in a simpler way, its easier to implement your own
[20:42:20 CET] <BBB> the function is hard because its optimized for speed, not readbility
[20:42:47 CET] <BBB> the input to get_vlc2() is the VLC table, which is initialized elsewhere
[20:43:00 CET] <BBB> the VLC table init stores codes, code length and respective values
[20:43:05 CET] <feliwir> yeah it's initialized in huffman_create
[20:43:15 CET] <BBB> thats really all there is to know; once you know that, its trivial to reimplement
[20:43:27 CET] <BBB> probably not immediately at the same optimization level as get_vlc2(), but fucntionally identical
[20:43:38 CET] <feliwir> but i don't know what VLC is at all. Never heard that term and documentation in ffmpeg is poor on it
[20:43:50 CET] <BBB> if you want fast code, just copy the relevant code from ffmpeg without understanding it (or maybe just copy the whole vp6 decoder; I dont quite see the point in reimplementing it)
[20:43:57 CET] <BBB> oh I see
[20:44:00 CET] <BBB> VLC is variable length code
[20:44:03 CET] <BBB> its like a tree
[20:44:06 CET] <BBB> a binary tree
[20:44:06 CET] <feliwir> well i can't copy it into C#
[20:44:13 CET] <BBB> if you have a sequence of bits 011100001111&
[20:44:16 CET] <BBB> what does that mean?
[20:44:24 CET] <BBB> if you have a 1 bit element, you simply take 1 bit and its 0/1
[20:44:35 CET] <BBB> if you have a nbit element, you read n bits and make an integer from it
[20:44:39 CET] <BBB> variable length is a tree
[20:44:48 CET] <BBB> e.g. 0 means a, 10 means b, 11 means c
[20:44:52 CET] <feliwir> my decoder is written in C#, and i can't use some macro functions there like ffmpeg does, so i am basically required to understand how it works :)
[20:45:11 CET] <BBB> and usually variable length coding trees are longer than just 3 elements
[20:45:49 CET] <BBB> so the tree (from init) maps sequences of 0/1 bits of a particular length to actual values
[20:46:12 CET] <BBB> and get_vlc2() then reads bitstream values against the sequence+lengths from the table and returns the specified value for that sequence/length pair
[20:46:35 CET] <BBB> its variable length because 0, 10 and 11 arent all sequences of the same length (0 is 1 bit, 10/11 are 2 bits)
[20:47:55 CET] <BBB> huffman coding is a typical strategy for dynamically modifying the variable length coding tree/table (whether in the frame header or as part of the bitstream specification based on symbol entropy)
[20:48:10 CET] <BBB> the result is typically that symbols with higher occurence have a smaller sequence length
[20:48:27 CET] <BBB> so that the number of bits requires to code the stream of symbols decreases ( = better compression)
[20:48:40 CET] <BBB> and techniques that accomplish that are called huffman optimizations
[20:48:55 CET] <BBB> michaelni knows more about technical aspects of that than I do
[20:49:08 CET] <BBB> but I suppose I know the general idea behind it
[20:49:15 CET] <BBB> I gotta run, brb in 15 min or so
[21:14:37 CET] <BBB> feliwir: I still think you should consider using C code directly and just copy ffmpeg code& c# has native code and allows linking against native C code also& re-writing obscure codecs like vp6 is somewhat wasteful IMO unless youre actually interested in it
[21:17:20 CET] <atomnuker> just compile with --disable-everything --enable-decoder=vp6 and keep an ffmpeg repo as a git submodule
[21:17:27 CET] <atomnuker> that's what rpcs3 and ppsspp do
[21:18:02 CET] <JEEB> for some reason hw said that C#'s FFI was awful or something
[21:18:05 CET] <JEEB> *he
[21:20:30 CET] <feliwir> BBB, i am using .NET core which is cross platform
[21:20:43 CET] <feliwir> and with C code i would require native binaries for each platform
[21:21:05 CET] <BBB> you need that anyway
[21:21:12 CET] <BBB> unless you dont want SIMD code and everything is mega-slow
[21:21:42 CET] <BBB> (which you basically dont want)
[21:22:32 CET] <nevcairiel> yeah video decoding is not something you can just do cross-platform without effort
[21:22:35 CET] <nevcairiel> or its sloooow
[21:23:07 CET] <feliwir> BBB, well not like C# doesn't make use of SIMD
[21:23:36 CET] <BBB> cross platform and simd dont mix
[21:23:59 CET] <feliwir> well C# introduced System.Numerics namespace which is basically SIMD for C#
[21:24:14 CET] <BBB> Im gonna get liboil nightmares
[21:24:22 CET] <BBB> sure, do as you please
[21:24:37 CET] <feliwir> i'll try atleast :)
[21:25:34 CET] <BtbN> sounds like numpy for C#
[21:27:03 CET] <feliwir> well C# is faster than python by default
[21:27:18 CET] <BBB> his point is that numpy isnt simd
[21:27:33 CET] <BBB> numpy is just an higher-level integer manipulation utility
[21:27:42 CET] <BBB> it allows things like regressions, matrices/vectors, etc.
[21:27:47 CET] <BBB> and possibly uses simd for some of that
[21:27:56 CET] <BBB> but thats not the same as making simd platform-independent
[21:27:56 CET] <feliwir> it even states that System.Numerics is meant for SIMD abstraction
[21:28:06 CET] <BBB> since most operations wont be accessible and will thus revert back to being scalar
[21:28:39 CET] <BBB> also see aut-vectorization
[21:28:41 CET] <feliwir> apart from that where does vp6 make use of SIMD?
[21:28:44 CET] <BBB> (its a compiler feature)
[21:28:50 CET] <BtbN> Granted, C# pretty much only needs to care about ARM and x86_64
[21:28:50 CET] <feliwir> the most function i saw so far are plain C
[21:29:27 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp6dsp.asm;h=3d874ea62a690ec7a06fc99aa6c0fd641891eff7;hb=HEAD
[21:29:38 CET] <BBB> not much, I agree
[21:29:52 CET] <BBB> theres http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp56_arith.h;h=810cc8dcd817914aa143f9aefc4993c135f65e79;hb=HEAD
[21:29:56 CET] <nevcairiel> vp6 is probably old and simple enough to actually work in pure C if you had to
[21:30:33 CET] <BBB> we have significant simd for vp3
[21:31:28 CET] <BBB> vp6 also uses videodsp, vp3dsp and hpeldsp
[21:31:37 CET] <BBB> I believe all of these are fairly well-optimized
[21:31:58 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/hpeldsp_vp3.asm;h=cba96d06cb7c7d660dacf444fce967d781a70942;hb=HEAD
[21:32:08 CET] <BBB> http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/hpeldsp.asm;h=ce5d7a4e28ca9ca2c9dcb55f987362e8281c63e1;hb=HEAD
[21:32:25 CET] <BBB> videodsp: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/videodsp.asm;h=a807d3b888f5726cca0bf2666ba2dadf417403a5;hb=HEAD
[21:32:36 CET] <BBB> and vp3dsp: http://git.videolan.org/?p=ffmpeg.git;a=blob;f=libavcodec/x86/vp3dsp.asm;h=d457cd7de50a8ce930dadfb9077bbaf68a5a1266;hb=HEAD
[21:33:10 CET] <BBB> whether playback of vp6 without simd is tolerable depends on how big the file is (datarate/sec, resolution, fps, etc.) and also on what type of machine you plan to use for playback
[21:41:08 CET] <feliwir> well, my files are mostly low res (300*300px)
[22:08:18 CET] <feliwir> BBB, .NET native might interest you: https://blogs.msdn.microsoft.com/dotnet/2017/01/30/announcing-net-core-net-native-and-nuget-updates-in-vs-2017-rc/
[22:08:29 CET] <feliwir> also with impressive examples
[22:09:21 CET] <BBB> sorry Im really not the right person for that type of languages
[22:09:28 CET] <BBB> I generally dont care the least about languages
[22:09:39 CET] <BBB> I dont udnerstand the fuzz about them, theyre all the same
[22:10:26 CET] <atomnuker> I still remember installing .net framework 4.0 for ati drivers on win xp x64 which seriously took around 4 hours
[22:11:06 CET] <BtbN> Wasn't XP already quite dead by the time .NET 4 came to be?
[22:12:39 CET] <atomnuker> then it was some older version
[22:13:14 CET] <atomnuker> 3.0 probably
[22:14:00 CET] <feliwir> .NET core is the future. It can compile to native binaries and there is no need for a preinstalled framework at all. Also it is much faster than that .NET framework garbage
[22:15:02 CET] <atomnuker> its name is still stained for me after waiting 4 hours for an error message to fix which it was easier to reinstall windows
[22:16:06 CET] <BtbN> .NET can and does compile to native binaries for quite some time now
[22:16:08 CET] <JEEB> feliwir: so it builds a fat binary with the parts of framework in it that you're using for ARM/ARM64/intel32/intel64?
[22:16:32 CET] <JEEB> because otherwise you're losing the "runs fukken everywhere" part of it
[22:16:35 CET] <feliwir> JEEB, no when i want to do that i specify the platform & architecture
[22:16:47 CET] <BtbN> No, it just natively compiles the framework as well, and has that as a dependency.
[22:16:50 CET] <feliwir> well i am not required to that if i don't wish
[22:17:10 CET] <feliwir> the framework is shipped as shared libraries in that case like BtbN said
[22:17:23 CET] <BtbN> But .NET does that since almost a decade
[22:17:27 CET] <BtbN> That's nothing new
[22:17:31 CET] <feliwir> BtbN, on linux & mac?
[22:17:36 CET] <BtbN> No, on Windows.
[22:17:51 CET] <feliwir> well .Net core does it anywhere :P 
[22:18:01 CET] <BtbN> So running on more than windows is new
[22:18:05 CET] <BtbN> but natively compiling is not.
[22:18:19 CET] <feliwir> never tried it with .NET framework
[22:18:32 CET] <BtbN> It does it implicitly, and caches the binaries somewhere
[22:18:38 CET] <BtbN> but you can also tell it to give you a native .exe
[22:18:42 CET] <feliwir> but i never saw a standalone .NET framework application
[22:18:44 CET] <BtbN> then it pre-compiles
[22:18:52 CET] <BtbN> It does not turn standalone
[22:18:56 CET] <BtbN> it still depends on the framework
[22:20:07 CET] <feliwir> so .NET framework still needs to be available on the target computer?
[23:49:12 CET] <cone-090> ffmpeg 03Carl Eugen Hoyos 07master:9e6b269fea26: lavc/avcodec: Constify AVBitStreamFilter* in AVBitStreamFilterContext struct.
[00:00:00 CET] --- Sat Mar 18 2017