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

[burek]

[00:21:48 CET] <cone-870> ffmpeg 03Michael Niedermayer 07master:d872643cfe07: avformat/utils: Check AVFormatContext->duration in compute_chapters_end() before use
[00:21:49 CET] <cone-870> ffmpeg 03Michael Niedermayer 07master:ec7a3be11ed3: avformat/utils: Move end_time1 AV_NOPTS_VALUE Check after rescale
[00:21:50 CET] <cone-870> ffmpeg 03Michael Niedermayer 07master:26379d4fddc1: avcodec/vp3: ensure header is parsed successfully before tables
[00:32:29 CET] <cone-870> ffmpeg 03Ganesh Ajjanagadde 07master:1bb7db217d90: avutil/crc: avoid needless space wastage of hardcoded crc table
[00:32:30 CET] <cone-870> ffmpeg 03Ganesh Ajjanagadde 07master:fa5d299496c1: avfilter/vsrc_mptestsrc: use lrint instead of floor hack
[00:32:31 CET] <cone-870> ffmpeg 03Ganesh Ajjanagadde 07master:c6bea81acfa4: avfilter/vf_perspective: use lrint instead of floor hack
[00:32:32 CET] <cone-870> ffmpeg 03Ganesh Ajjanagadde 07master:d64b6c38198e: avfilter/af_flanger: use rint instead of floor hack
[00:53:33 CET] <kierank> so I need to use RLE decoding but my escape level doesn't fit into an int8_t. how should I use the RL api?
[00:54:01 CET] <kierank> durandal_1707, perhaps?
[00:54:04 CET] <kierank> needed in cfhd
[00:59:15 CET] <kierank> wtf but RL_VLC_ELEM is an int16_T
[01:11:13 CET] <Timothy_Gu> nevcairiel: when "configure: Replace `pr` since it is Nothing4You provided by busybox" is pushed to Libav don't merge it in FFmpeg; I'll send a patch for it after that is pushed
[01:11:27 CET] <Timothy_Gu> oops not sure where "Nothing4You" came from
[01:12:27 CET] <Timothy_Gu> But it's "configure: Replace `pr` since it is not provided by busybox"
[01:16:53 CET] <kierank> hmm seems dv does a trick to avoid that
[01:17:00 CET] <kierank> but with eugh global state
[01:32:14 CET] <Compn> Timothy_Gu : did you already change your "Nothing4You" password? :P
[01:38:34 CET] <iive> it is more likely to be auto correction / replacement feature.
[02:01:40 CET] <llogan> it's a tab completition for a user here
[02:06:49 CET] <Compn> Nothing4You : identify yourself :P
[02:07:01 CET] <Compn> ahh hes in every channel
[02:19:24 CET] <Timothy_Gu> llogan: yeah figured. there was a tab character after "not," and when copying irssi just autocompleted
[02:44:11 CET] <cone-870> ffmpeg 03Michael Niedermayer 07master:0afdfbe11678: avcodec/jpeg2000: fix type of arguments of tag_tree_size
[04:11:18 CET] <cone-870> ffmpeg 03Michael Niedermayer 07master:b46dcd5209a7: avutil/timecode: Fix fps check
[05:40:59 CET] <cone-870> ffmpeg 03James Almer 07master:9ac5beaa86b5: avformat/mpjpegdec: fix mixed declarations and code
[09:13:29 CET] <wm4> meh how did I overlook that one
[10:22:05 CET] <cone-971> ffmpeg 03Hendrik Leppkes 07master:46db068c5957: tests/api: Fix API test build on windows with --enable-shared
[11:08:47 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:acc2347cf47b: avfilter/af_agate: prepare for adding sidechain version
[11:08:48 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:bd5afecdcbb6: avfilter: add sidechaingate filter
[11:08:50 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:6907046130ee: avfilter/af_agate: add level_sc option for sidechaingate filter
[11:08:50 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:1b22bdf4e350: avfilter/af_agate: compile agate only when requested.
[11:08:51 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:4a43e559e1b3: avfilter/af_sidechaincompress: kill init function
[11:08:52 CET] <cone-971> ffmpeg 03Paul B Mahol 07master:fff7f2df31e9: avfilter/af_agate: change default for detection to rms
[12:04:03 CET] <atomnuker> nice, vp9 hwdec patches
[12:04:22 CET] <atomnuker> any hardware which can use dxva VP9 hwaccel?
[12:05:03 CET] <nevcairiel> intel braswell and skylake
[12:06:08 CET] <wm4> skylake, really? is it full hw decode?
[12:06:19 CET] <nevcairiel> no hybrid only afaik
[12:06:32 CET] <wm4> oh ok
[12:06:35 CET] <nevcairiel> nvidia seems to also be working on adding hybrid decoding, but their latest drivers still seem broken
[12:07:25 CET] <kierank> nevcairiel: hmm there was the product manager at vdd
[12:07:25 CET] <kierank> for nvidia 
[12:07:48 CET] <kierank> maybe j-b could give you his contact details
[12:07:51 CET] <kierank> seemed like a nice guy
[12:08:30 CET] <nevcairiel> i kinda expect a new nvidia driver this month, maybe they already finished it then
[12:09:13 CET] <nevcairiel> the spec from MS is relatively new as it is, so maybe they worked with a pre-release spec and needed to update for the final
[13:52:28 CET] <wm4> michaelni: so why exactly did you try to make codec and hwaccel registration O(1)? this doesn't look very thread-safe
[13:52:47 CET] <wm4> even though the previous code attempted so by using avpriv_atomic_ptr_cas
[13:57:56 CET] <michaelni> what is non thread safe on it ?
[13:58:07 CET] <michaelni> the previous code was not O(1)
[13:58:17 CET] <michaelni> it always iterated over the whole list
[13:58:43 CET] <wm4> I mean, it was somewhat thread safe
[13:59:01 CET] <wm4> I suppose the new code could also be considered thread safe if you assume that no atomics means weak atomics
[13:59:35 CET] <wm4> how much did this speed it up?
[14:00:29 CET] <michaelni> it was meassureable IIRC, i dont remember the exact value, but with lets say 1000 codecs the old code would do i belive ~ 500 000 iterations
[14:10:14 CET] <wm4> and I suppose we remove this lock manager stuff only when all codecs have thread safe init
[14:10:31 CET] <wm4> instead of using a global mutex
[14:15:36 CET] <durandal_1707> what codecs have nonthread safe init?
[14:16:39 CET] <wm4> all which don't have FF_CODEC_CAP_INIT_THREADSAFE set in AVCodec.caps_internal
[14:16:48 CET] <wm4> but most of them are maybe actually safe
[14:21:07 CET] <kierank> dv is nonthreadsafe
[15:16:29 CET] <durandal_1707> complex is in c99
[15:16:43 CET] <nevcairiel> durandal_1707: you should specifically check for complex.h presence, I know of a bunch of systems that have cabs in math.h, but no complex.h
[15:17:08 CET] <durandal_1707> huh?
[15:18:06 CET] <durandal_1707> how It's supposed to work?  
[15:24:32 CET] <nevcairiel> they just have a small subset of complex functions in math.h
[15:26:49 CET] <atomnuker> what about tgmath.h?
[15:28:06 CET] <nevcairiel> tgmath.h is generally not present on windows at all
[15:28:46 CET] <BtbN> It should be, starting with VS2013
[15:28:51 CET] <atomnuker> <ctgmath>?
[15:29:18 CET] <Daemon404> dont use tgmath please
[15:29:20 CET] <nevcairiel> BtbN: no, the C tgmath.h header is not present even today
[15:29:21 CET] <Daemon404> it is an abomination
[15:29:29 CET] <Daemon404> it cant even be implemented in C
[15:29:32 CET] <Daemon404> (until C11)
[15:30:11 CET] <nevcairiel> <ctgmath> is available, but thats C++
[15:31:21 CET] <nevcairiel> C99 support in VS2015 is nearly complete, except tgmath.h and iirc some slightly different preprocessor behavior
[15:31:50 CET] <Daemon404> VLAs
[15:32:35 CET] <nevcairiel> considering they are no longer mandatory in future C versions, thats a thing we can all do without =p
[15:32:43 CET] <Daemon404> theyre evil anyway
[15:32:46 CET] <Daemon404> so is tgmath
[15:32:50 CET] <Daemon404> nothing of value was lost
[16:48:10 CET] <kierank> hahahaha
[16:48:12 CET] <kierank> ahahahah
[16:49:04 CET] <durandal_1707> so?
[16:49:22 CET] <J_Darnley> Can he not read or do I misunderstand that commit message?
[16:49:50 CET] <Daemon404> J_Darnley, system libraries wont ship with libav abi compat enabled
[16:50:17 CET] <J_Darnley> Oh
[16:50:25 CET] <J_Darnley> I thought firefox hated ffmpeg.
[16:50:50 CET] <J_Darnley> Why do they suddenly want to use a system lavc?
[16:51:03 CET] <Daemon404> they switched from gst to libavcodec i think recently?
[16:51:06 CET] <Daemon404> i thought someone said that
[16:52:04 CET] <J_Darnley> I wonder if that means they're going to support h264 on XP now.
[16:53:06 CET] <Daemon404> who gives a crap?
[16:53:51 CET] <Daemon404> people who stick to an unsupported os can use unsupported software.
[16:53:52 CET] <durandal_1707> there is more than just that int for abi compat
[16:53:57 CET] <Daemon404> yeah i know
[16:54:24 CET] <J_Darnley> Well all browsers should have just used a system lavc from the begining and ignored the codec war shit.
[16:59:47 CET] <ubitux> heh, so abi compat was useful in the end ;)
[17:00:10 CET] <nevcairiel> i think that guy is just weird
[17:00:25 CET] <nevcairiel> what does he want, ship a b inary that works on all possible systems without recompiling?
[17:00:30 CET] <nevcairiel> thats unrealistic at best
[17:00:40 CET] <Daemon404> chrome ships their own libs on every os
[17:00:43 CET] <Daemon404> the only sane thing to do.
[17:00:58 CET] <nevcairiel> lunuxers will hate you for it, but yes
[17:01:29 CET] <J_Darnley> Excuse me, static linking into one giant exe is the sanest!
[17:01:46 CET] <Daemon404> thats not legal in this case
[17:02:06 CET] <Daemon404> the one case where i'd prefer a system library is crypto.
[17:02:13 CET] <Daemon404> s/^/also, /
[17:02:20 CET] <nevcairiel> yeah leaves security concerns to the system and nto you
[17:02:21 CET] <nevcairiel> :)
[17:02:42 CET] <J_Darnley> Only cause google doesn't want to open their spyware for all the world to see.
[17:04:27 CET] <Daemon404> J_Darnley, well also because of flash
[17:06:50 CET] <J_Darnley> Surely that sounds like a feature to people else days.
[17:07:20 CET] <J_Darnley> "Flash deprecated"
[17:07:38 CET] <J_Darnley> *sounds of joy heard all over the world*
[17:08:44 CET] <nevcairiel> why is that even a problem for Firefox, do they really provide generic binary packages instead of shipping through distribution channels?
[17:08:51 CET] <nevcairiel> open-source much? :)
[17:14:27 CET] <wm4> nevcairiel: yes I think there are binary Linux builds for FF
[17:15:01 CET] <nevcairiel> that must be super painful code to try to support various ffmpeg/libav versions in a binary level
[17:15:06 CET] <nevcairiel> at compile time is already terrible
[17:15:10 CET] <wm4> that's what they're trying
[17:15:17 CET] <wm4> they dlopen libavcodec
[17:15:29 CET] <nevcairiel> well $work dlopen's avcodec
[17:15:39 CET] <wm4> why?
[17:15:58 CET] <nevcairiel> avoids linking, its not used very often unless you watch a video
[17:16:13 CET] <nevcairiel> but we still ship a specific version and compile against its headers
[17:16:48 CET] <wm4> even then you'd be better off dlopening your own wrapper
[17:17:12 CET] <nevcairiel> why
[17:17:15 CET] <ubitux> > There was never binary compatibility between FFmpeg and Libav, unless FFmpeg was compiled with a special configure flag not enabled by default.
[17:17:22 CET] <ubitux> wm4: complete* binary compat
[17:17:37 CET] <ubitux> the flag was just for stuff that would make it incompatible with ourselves
[17:17:44 CET] <ubitux> limited scope
[17:17:57 CET] <ubitux> rest was abi compat
[17:18:58 CET] <wm4> ok, changed it to avoid flames with certain assholes
[17:20:43 CET] <Daemon404> i find it hard to believe there are millions of people downloading ff binaries direct from mozilla on linux
[17:20:55 CET] <wm4> there probably aren't
[17:21:05 CET] Action: J_Darnley must resist making a trac account and shit posting
[17:54:22 CET] <cone-020> ffmpeg 03Timo Teräs 07master:64f7db554ee8: mpegencts: Fix overflow in cbr mode period calculations
[17:59:58 CET] <Compn> what i find odd is that ffmpeg tells the distros how to distribute ffmpeg and they ignore us, but someone like mozilla will come along and get it fixed within a week
[18:00:01 CET] <Compn> i'm not bitter. :(
[18:02:56 CET] <Compn> michaelni : probably you should reply to that trac ticket, https://trac.ffmpeg.org/ticket/5057
[18:06:53 CET] <wm4> Compn: where did FF get a fix?
[18:10:59 CET] <Compn> i'm saying they could get a fix from the distros, easily
[18:11:09 CET] <Compn> just another distro patch to revert that commit
[18:11:33 CET] <wm4> can't do that, the API would be different
[18:11:36 CET] <Compn> nevcairiel : why not offer some assistance to this bug reporter ?
[18:12:05 CET] <wm4> what kind of assistance
[18:12:22 CET] <Compn> i dont know, figure out what needs to be changed in firefox code maaaaybe
[18:12:24 CET] <BBB> hrmblegh
[18:12:43 CET] <BBB> so &
[18:12:51 CET] <BBB> Im not saying we should introduce libav compat again
[18:12:52 CET] <BBB> but
[18:12:55 CET] <Compn> then write this information down for other projects, due to api change.
[18:13:09 CET] <BBB> it may be worth hearing out this mozilla dude and see if he has any more practical thoughts or suggestions on this subject
[18:13:21 CET] <Compn> right
[18:13:24 CET] <BBB> mozilla is a pretty cool user to have, we already have chrome
[18:13:33 CET] <BBB> you have to realize how absolutely awesome that is
[18:13:36 CET] <Compn> wm4 : firefox wont be the only project to have this trouble with the api change.
[18:13:50 CET] <BtbN> it's not even an api change, just abi
[18:13:55 CET] <Compn> .... whatever
[18:14:28 CET] <Compn> also it makes us look like jerks if our replies in our trac are "dont care, its already decided"
[18:14:37 CET] <wm4> the type changes, so it's an API change, but a minor one
[18:14:54 CET] <wm4> Compn: that's wrong, nobody will have a problem with it, except those who want to play ABI games
[18:16:05 CET] Action: Compn stares into the abyss
[18:18:47 CET] <atomnuker> the abyss stares back at Compn 
[18:46:43 CET] <nevcairiel> BBB: a project that tries to keep binary compatibility with a wide range of versions will be blocking every change we want to make, we already have those people =p
[18:48:54 CET] <nevcairiel> imho its a rather silly goal, at least chrome is sensible enough to just ship their version with the browser
[18:49:53 CET] <nevcairiel> I dont even want to see the amount of nonsense such compatibility layer would collect
[19:07:11 CET] <atomnuker> any opposition to dropping the AAC encoder experimental flag?
[19:07:45 CET] <atomnuker> so far the only discussion was whether to have coders !twoloop usable only with experimental compliance
[19:08:02 CET] <nevcairiel> well the biggest concern was that those are still broken
[19:08:09 CET] <nevcairiel> so if you push that patch with it, its fine with me
[19:10:58 CET] <michaelni> atomnuker, did you or claudio look at coverity issue 1338325 ? 
[19:11:49 CET] <michaelni> iam atm checking over the coverity issues and that is i think the only aac one
[19:11:59 CET] <michaelni> aacenc that is
[19:12:42 CET] <atomnuker> could you give me a link?
[19:13:44 CET] <michaelni> just type 1338325 in the CID search field at the top right, or you have no coverity account ?
[19:15:02 CET] <michaelni> if you need an account say so and ill send you an invite
[19:15:24 CET] <atomnuker> yeah, I don't have an account
[19:15:32 CET] <atomnuker> so and invite would be nice
[19:15:56 CET] <fritsch> BtbN: http://lists.freedesktop.org/archives/libva/2015-December/003748.html
[19:15:59 CET] <fritsch> hevc 10 bit decoding
[19:16:34 CET] <fritsch> and direct vp9 decoding support
[19:17:12 CET] <michaelni> atomnuker, invite sent, 50% chance it will be in your spam folder
[19:17:19 CET] <nevcairiel> fritsch: "direct"?
[19:18:05 CET] <nevcairiel> as opposed to? :)
[19:18:27 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003749.html
[19:18:28 CET] <fritsch> yes
[19:18:43 CET] <fritsch> nevcairiel: here is the P010 handling
[19:18:47 CET] <fritsch> it converts to rgba32
[19:19:12 CET] <michaelni> if anyone else needs/wants a coverity account for ffmpeg, ping me
[19:19:13 CET] <Daemon404> someone outside of MS uses P010?
[19:19:39 CET] <nevcairiel> Daemon404: its just nv12 in 10-bit, its not unsurprising that its being used for hwaccels
[19:19:46 CET] <Daemon404> i suppose
[19:20:17 CET] <nevcairiel> i should clean out my patches for p010 support in ffmpeg
[19:20:37 CET] <fritsch> nevcairiel: yeah you should :-) we have tested them in kodi and wait for you sending them upstream
[19:20:40 CET] <nevcairiel> i only did a rather simple implementation, enough to suit my own needs
[19:20:41 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/date.html <- here VP9 bits
[19:21:13 CET] <fritsch> it's broxton only it seems
[19:21:21 CET] <fritsch> did anyone know "broxton"? <- kabilake?
[19:21:28 CET] <nevcairiel> maybe atom
[19:21:44 CET] <nevcairiel> yes, broxton is the next atom
[19:21:49 CET] <fritsch> nice :-)
[19:21:50 CET] <fritsch> http://lists.freedesktop.org/archives/libva/2015-December/003756.html
[19:22:15 CET] <nevcairiel> guess they dont do hybrid decoding in libva eh
[19:22:24 CET] <nevcairiel> because vp9 hybrid works through dxva2 on braswell
[19:22:39 CET] <cone-020> ffmpeg 03Nicolas George 07master:3ab1e5a48c53: lavf: add FFERROR_REDO to let demuxers return no packet.
[19:22:40 CET] <fritsch> vp9 hybrid is also there for braswell on linux
[19:22:40 CET] <cone-020> ffmpeg 03Nicolas George 07master:0bac7a436be6: lavf/flvdec: use FFERROR_REDO instead of AVERROR(EAGAIN).
[19:22:41 CET] <cone-020> ffmpeg 03Nicolas George 07master:cb14d30240b0: lavf/mpeg: use FFERROR_REDO instead of AVERROR(EAGAIN).
[19:22:42 CET] <cone-020> ffmpeg 03Nicolas George 07master:eb2e4fb6745b: lavf/lxfdec: use FFERROR_REDO instead of AVERROR(EAGAIN).
[19:22:43 CET] <cone-020> ffmpeg 03Nicolas George 07master:085ab74972bc: lavf/mpegts: use AVERROR_INVALIDDATA instead of AVERROR(EINTR).
[19:22:49 CET] <fritsch> there is a intel-hybrid driver on 01 org
[19:23:04 CET] <fritsch> i thought BtbN is working on it - therefore I pinged him
[19:24:08 CET] <fritsch> that broxton should be available right now :-)
[19:43:12 CET] <atomnuker> "memset(&sce->lcoeffs[0], 0.0f, 3072*sizeof(sce->lcoeffs[0]));"
[19:43:24 CET] <atomnuker> how is that supposed to overflow?
[19:43:49 CET] <atomnuker> sorry, out of bounds access
[19:44:33 CET] <BBB> why memset 0.0f?
[19:44:37 CET] <BBB> why not just memset 0?
[19:47:54 CET] <atomnuker> it shouldn't matter, memset takes an int so the compiler should convert it to an int
[19:48:11 CET] <atomnuker> though I'll change it once I figure out how to applease coverity
[20:08:43 CET] <kierank> BBB: ping
[20:09:00 CET] <BBB> pong
[20:09:11 CET] <BBB> atomnuker: ty
[20:09:38 CET] <kierank> so, atomnuker and I are adding 10-bit decoding to dirac. What's the best way to have mixed 8/10-bit functions like in h264?
[20:10:20 CET] <wm4> what do you need dirac for?
[20:10:29 CET] <kierank> various things
[20:10:41 CET] <Daemon404> he's british
[20:10:43 CET] <Daemon404> it's in his blood
[20:10:43 CET] <wm4> I always thought it was a dead codec
[20:11:16 CET] <KGB> [13FFV1] 15michaelni pushed 5 new commits to 06master: 02http://git.io/vRZlT
[20:11:17 CET] <KGB> 13FFV1/06master 1482bbb6d 15Dave Rice: typos
[20:11:17 CET] <KGB> 13FFV1/06master 14bad4526 15Dave Rice: more readable descriptions of operators
[20:11:17 CET] <KGB> 13FFV1/06master 14723fbd0 15Dave Rice: capitalize Range coder when used
[20:11:37 CET] <BBB> huh?
[20:11:42 CET] <BBB> kierank: ehm...
[20:11:54 CET] <BBB> is that the ffv1 spec repo?
[20:11:56 CET] <BBB> odd
[20:12:07 CET] <BBB> kierank: uh & so & I think templating is easiest
[20:12:21 CET] <BBB> kierank: but it really depends on how much you care about performance vs. binary size
[20:12:29 CET] <BBB> templating of dsp functions I mean
[20:12:37 CET] <kierank> how does it work with structs
[20:12:37 CET] <kierank> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/diracdsp.h
[20:12:47 CET] <BBB> and then the rest of the code would just take an extra bytes per sample param
[20:12:50 CET] <kierank> is there a way of reusing the function pointers?
[20:12:52 CET] <kierank> oh
[20:13:08 CET] <michaelni> BBB yes its ffv1, i wonder why KGB doesnt show all 5 commits when there are 5 btw
[20:13:24 CET] <BBB> function pointers should be eay
[20:13:31 CET] <BBB> just use uint8_t everywhere
[20:13:38 CET] <BBB> and in the 10bpp functions internally, cast them to uint16_t
[20:13:42 CET] <kierank> ah you just change it
[20:13:43 CET] <kierank> ...
[20:13:44 CET] <BBB> stride would always be in bytes, not pixels
[20:13:46 CET] <kierank> so simple when you know how
[20:13:56 CET] <BBB> and then it just works
[20:14:01 CET] <BBB> theres a little casting in the dsp.c files
[20:14:02 CET] <BBB> but its ok
[20:14:07 CET] <BBB> we have helper templates for that
[20:14:22 CET] <BBB> bit_depth_template.c
[20:14:27 CET] <BBB> should be fairly helpful
[20:14:34 CET] <BBB> I believe vp9 and h264 both use it
[20:14:48 CET] <BBB> hevc also
[20:14:58 CET] <kierank> there's not much to change actually, it's mostly dsp functions that need changing in dirac
[20:15:03 CET] <BBB> right
[20:15:22 CET] <BBB> so its a little magic, but I think in the dsp, your function changes from uint8_t *px to uint8_t *_px
[20:15:31 CET] <BBB> and then you cast pixel *px = (pixel *) _px;
[20:15:37 CET] <BBB> where pixel comes from bit_depth_template.c
[20:16:15 CET] <kierank> I think it's only 8/10-bit that exists for now so it should be simple
[20:16:25 CET] <kierank> just the "next one up" for each integer type
[20:19:06 CET] <BBB> right, well, 8 to 10 is hardest
[20:19:10 CET] <BBB> because everything changes
[20:19:13 CET] <BBB> 10 to 12 is super trivial
[20:22:35 CET] <durandal_1707> nevcairiel: I added chech for complex funcs similar to one for math funcs
[20:26:08 CET] <durandal_1707> 10bit support for dirac decoder?
[20:27:07 CET] <kierank> durandal_1707: it's for the new hq profile
[20:27:29 CET] <kierank> Which is 10-bit and also slightly different
[20:48:05 CET] <cone-020> ffmpeg 03Michael Niedermayer 07master:32bf6550cb9c: avformat/riffdec: Initialize bitrate
[20:48:06 CET] <cone-020> ffmpeg 03Michael Niedermayer 07master:4e31176e145f: avformat/riffdec: remove special case for bitrate > 32bit
[21:14:05 CET] <fritsch> nevcairiel: http://sprunge.us/GbiR which is faster the assignment or the memcpy?
[21:15:48 CET] <nevcairiel> any half-decent compiler would hopefully replace the memcpy with a simple assignment in such a case
[21:17:29 CET] <fritsch> hehe :-)
[21:17:32 CET] <fritsch> exactly this happens
[21:18:17 CET] <fritsch> nevcairiel: https://github.com/FernetMenta/xbmc/commit/adfa2b8c978754f3824b6a0cb46cd44ca9c43692#commitcomment-14772074 <- we had a major discussion here
[21:18:30 CET] <fritsch> and our ARM devs jumped in
[21:18:42 CET] <fritsch> and protested against the memcpy
[21:20:13 CET] <nevcairiel> seems like mostly you discussing with yourself
[21:20:50 CET] <fritsch> read on bottom of the page :-)
[21:21:22 CET] <nevcairiel> sometimes it just avoids ugly casting or whatnot to use memcpy
[21:21:45 CET] <fritsch> that was the original intention
[21:23:39 CET] <wm4> I'd rather question why there's truehd specific code in some big generic audio function (?)
[21:24:00 CET] <fritsch> cause our syncer needs 24 packages
[21:24:19 CET] <nevcairiel> thats just how truehd passthrough works, the frames are so small that the spec says to pack 24 together
[21:24:46 CET] <nevcairiel> which gives a 20ms buffer, iirc
[22:10:14 CET] <kierank> michaelni: ping, have a question
[22:17:35 CET] <michaelni> kierank, just ask, ill awnser when ive time / am done with what i work on atm
[22:17:50 CET] <kierank> it's a very historical question
[22:18:12 CET] <kierank> Any idea why this contradicts the spec
[22:18:13 CET] <kierank> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/diracdec.c#L656
[22:18:20 CET] <kierank> https://usercontent.irccloud-cdn.com/file/66bkVKzQ/
[22:18:22 CET] <kierank> spec ^
[22:18:26 CET] <kierank> https://lists.ffmpeg.org/pipermail/ffmpeg-soc/2008-December/006067.html
[22:18:30 CET] <kierank> commit that changed it
[22:24:26 CET] <michaelni> why does it contradict the spec ? isnt that commit just a simplification
[22:25:11 CET] <kierank> spec says level 0 only has LL
[22:25:22 CET] <kierank> whereas code appears to do 0,1,2,3 for level 0
[22:25:33 CET] <kierank> for orientation
[22:25:50 CET] <nevcairiel> maybe the spec just 1-indexes everything?
[22:25:56 CET] <nevcairiel> that would explain the code we have
[22:26:13 CET] <kierank> it doesn't
[22:26:17 CET] <nevcairiel> level 0 gets 0-3, level 1+ just get 1-3
[22:26:47 CET] <kierank> there are other loops in the spec that loop through 0
[22:27:42 CET] <kierank> the commit changes it from the spec version to another
[22:27:45 CET] <nevcairiel> i suppose it seems wrong then, yes
[22:27:47 CET] <kierank> not that the spec for loop is inclusive
[22:27:56 CET] <kierank> note*
[22:29:51 CET] <nevcairiel> but it seems like something that would result in rather noticeable  problems
[22:31:01 CET] <michaelni> the code does before and afterwards 0,1,2,3,1,2,3, ... i dont see the difference
[22:31:33 CET] <kierank> not for level=0
[22:33:23 CET] <nevcairiel> according to the spec its [0] = {0}, [1] = {1,2,3}, etc, the old code did this, the new code does not, it reads [0] = {0,1,2,3}, [1] = {1,2,3} ... unless some other code was changed to treat level 0 differently and expect it to  be read like this
[22:35:14 CET] <TD-Linux> nevcairiel, actually there is hybrid decoding for libva but it's a separate driver (not the i965 one)
[22:36:28 CET] <nevcairiel> kierank: the code handling these levels seems somewhat complex, he may just as well have decided to just put level 0 and 1 into the same struct, because they dont overlap
[22:36:46 CET] <kierank> it's a possibility yes
[22:37:57 CET] <kierank> hmm could be
[22:37:58 CET] <kierank> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/diracdec.c#L833
[22:43:22 CET] <fritsch> TD-Linux: but the default driver was extended to load the hybrid .so files
[22:43:49 CET] <fritsch> so for the future it can use all of those "third party hybrid thingies" via the same api
[22:44:36 CET] <kierank> +    int cb_numx = s->codeblocksh[b->level + (b->orientation != subband_ll)];
[22:44:36 CET] <kierank> +    int cb_numy = s->codeblocksv[b->level + (b->orientation != subband_ll)];
[22:44:39 CET] <kierank> seems offsetted here
[22:49:10 CET] <TD-Linux> fritsch, ah cool. I built the hybrid driver but didn't get around to actually testing it yet. motivation is really low because ffvp9 is fast enough :)
[22:55:44 CET] <fritsch> TD-Linux: see the latest libva ML messages
[22:56:06 CET] <fritsch> TD-Linux: vp9 will be supported natively with next gen - so good chance to get it going in ffmpeg
[22:56:08 CET] <nevcairiel> I didnt actually get a chance to properly benchmark the vp9 hybrid decoder on braswell yet
[22:56:24 CET] <fritsch> i benchmarked hevc-10bit decoder for broadwell ...
[22:56:26 CET] <nevcairiel> the ffmpeg_dxva2.c module is bad for performance
[22:56:27 CET] <fritsch> nightmare :-)
[22:56:52 CET] <nevcairiel> once its pushed and everything I should benchmark using my own code
[22:56:52 CET] <fritsch> 4k 10 bit hevc you can just forget
[22:57:08 CET] <fritsch> on those hybrid
[23:00:12 CET] <fritsch> nevcairiel: ah just seen your vp9 hwaccel preperation
[23:10:59 CET] <nevcairiel> preperation? Thats everything thats needed for dxva2 vp9 :)
[23:15:21 CET] <kierank> durandal_1707: that random number at the beginning of the table is the length
[23:32:43 CET] <atomnuker> hm, git send-email gets stuck when sending to ffmpeg-devel at ffmpeg.org
[23:32:57 CET] <atomnuker> or maybe it's my internet
[23:34:16 CET] <nevcairiel> the ML wont be involved in any case, either your internet or your mail server
[23:35:50 CET] <atomnuker> just took a long time for some reason
[23:48:36 CET] <nevcairiel> atomnuker: lcoeffs is only 1024 elements
[23:49:29 CET] <nevcairiel> maybe you wanted ltp_state, wh ich is 3072 elements?
[23:52:48 CET] <nevcairiel> left a comment on the ML, time for sleepz
[00:00:00 CET] --- Fri Dec  4 2015