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

[burek]

[04:54:27 CET] <cone-765> ffmpeg 03James Almer 07master:a4fc63c0f9eb: x86/lossless_videodsp: don't overread the dst buffer in ff_add_left_pred_unaligned_avx2
[04:54:28 CET] <cone-765> ffmpeg 03James Almer 07master:438f884fc48b: x86/lossless_videodsp: rename ff_add_left_pred_int16_sse4 to ff_add_left_pred_int16_unaligned_ssse3
[04:54:29 CET] <cone-765> ffmpeg 03James Almer 07master:1215889bc189: checkasm/llviddsp: fix mixed code and declarations
[12:22:47 CET] <durandal_1707> why everybody is silent when big stuff is posted on ml, but like to shit about it when nobody tackles it?
[12:51:01 CET] <atomnuker> everyone's silent because its sunday and for some reason everyone's silent on sundays
[13:08:32 CET] <durandal_1707> atomnuker: no, devs are worse people than users
[13:17:16 CET] <durandal_1707> i will spam ml until you accept all my patches, enjoj spam!
[14:02:17 CET] <JEEB> begesus
[14:09:29 CET] <wm4> I see 154 new mails - yeah, not today
[14:18:17 CET] <durandal_1707> what not today?
[14:43:20 CET] <cone-761> ffmpeg 03Mateusz 07master:149268b47c4b: fix MSVC compilation errors
[15:29:52 CET] <durandal_1707> atomnuker: atrac9 released,  do you want to write decoder for lavc?
[15:32:38 CET] <JEEB> I thought ATRAC9 was released ages ago?
[15:32:51 CET] <JEEB> I've had some binaries for it since...
[15:33:08 CET] <JEEB> nov, 2015
[15:33:10 CET] <durandal_1707> the SOURCE 
[15:33:13 CET] <JEEB> oh
[15:33:39 CET] <JEEB> well that's an unexpected change of events if it got OSS'd :P
[15:34:11 CET] <durandal_1707> it was REd
[15:34:57 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/tree/atrac9-docs/docs/atrac9
[15:35:01 CET] <JEEB> at least some docs
[15:35:06 CET] <durandal_1707> in this cs files
[15:35:14 CET] <durandal_1707> C sharp for you
[15:35:23 CET] <JEEB> yea, it's a UWP app
[15:35:54 CET] <JEEB> wait :D
[15:35:58 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/commit/42cede619a6afba149da7ec2d805577bd7bd0132
[15:36:12 CET] <JEEB> > At9ToolPath = Path.Combine(directory, "at9tool.exe")
[15:36:26 CET] <JEEB> oh there we go
[15:36:27 CET] <JEEB> https://github.com/Thealexbarney/VGAudio/commit/6a4062cc43da458dc71b698de77e90ac4f4fc79d
[15:36:38 CET] <atomnuker> durandal_1707: there's no code, right?
[15:36:46 CET] <JEEB> see the last commit I posted
[15:36:53 CET] <JEEB> that seems like their decoder
[15:37:21 CET] <JEEB> also the ATRAC3+ decoder needs to be fixed to work with MPEG-PS. it's been on my roadmap for a while but all the other things have popped up instead :V
[15:37:39 CET] <JEEB> currently the decoder wants all the info in extradata
[15:37:43 CET] <JEEB> but there's a format with a per-frame header
[15:37:48 CET] <JEEB> which is used in MPEG-PS
[15:38:24 CET] <JEEB> there were some attempts by the PPSSPP guy and the Shiz but they never got through due to the parser not being right or something
[15:38:42 CET] <JEEB> since i think they were poking extradata from the parser or something
[15:39:08 CET] <JEEB> how does lavc in general handle formats like this btw?
[15:39:29 CET] <JEEB> is it just a case of checking "is there something in avcodeccontext?"
[15:39:34 CET] <atomnuker> what does the PS stand for?
[15:39:43 CET] <JEEB> it's standard MPEG-PS
[15:39:53 CET] <JEEB> program stream
[15:40:12 CET] <durandal_1707> atomnuker: it have imdct, so code is available
[15:40:22 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/ad1652a0c9ddaf76ee7c1f955057d66c7581b2d0
[15:41:02 CET] <JEEB> also I think I had a newer version which included the header sony used for PS3
[15:41:13 CET] <atomnuker> durandal_1707: yeah I'll do it alongside the denoise filter
[15:41:40 CET] <atomnuker> but first I need to finish the bloody atomics and I've encountered a big distraction - pillars of ethernity
[15:41:47 CET] <JEEB> heh :D
[15:41:51 CET] <durandal_1707> it will be finished in next year?
[15:42:57 CET] <atomnuker> maybe not, yesterday I saved av1 thanks to TD-Linux so I should have more time now
[15:43:06 CET] <durandal_1707> just write rust decoder i will c one
[15:43:38 CET] <atomnuker> bah sorry mate I don't write rust just loads of C code
[15:45:34 CET] <iive> i thought we are rewriting ffmpeg in rust ;)
[15:47:35 CET] <durandal_1707> iive: thats your only full time job
[15:52:32 CET] <iive> nope
[15:53:18 CET] <durandal_1707> dont nope here
[16:34:36 CET] <atomnuker> jamrial / nevcairiel / michaelni: I could use some help with the atomics patches
[16:35:38 CET] <atomnuker> I think the only way to solve the locking issue is to use mutexes
[16:35:52 CET] <atomnuker> (e.g. when registering filters)
[16:36:17 CET] <atomnuker> I can't make the entire array atomic and even if I did another thread trying to add would probably mess things up
[16:36:22 CET] <nevcairiel> I still have no clue why you are trying to even change the logic instead of just replacing the atomics functions
[16:36:45 CET] <nevcairiel> all of those resolve to the same underlying hardware instructions
[16:36:49 CET] <atomnuker> can't replace the bloody avpriv cas function
[16:37:00 CET] <nevcairiel> you claim that, but i dont believe you
[16:37:09 CET] <atomnuker> have you looked at it?
[16:37:15 CET] <nevcairiel> sure
[16:37:22 CET] <nevcairiel> i even posted a proposal on the ml
[16:37:31 CET] <atomnuker> link?
[16:38:20 CET] <nevcairiel> dont have that handy right now, but the gist of it is that compare_exchange_strong is basically the same as the avpriv cas
[16:38:32 CET] <atomnuker> well it isn't
[16:39:18 CET] <atomnuker> the issue is that the avpriv one takes in a pointer to the new value
[16:39:48 CET] <atomnuker> and the c11 one takes a value directly
[16:40:28 CET] <atomnuker> this is the main issue why you can't replace it directly, you'll need a temp value to store the newval
[16:40:33 CET] <atomnuker> which breaks atomicity
[16:42:15 CET] <atomnuker> I think if I take the patches I posted which removed atomics and just added a mutex at start/end it would be better
[16:42:40 CET] <atomnuker> because unlike the avpriv function you'll not be locking/unlocking at every iteration while adding a filter but only once
[16:42:41 CET] <nevcairiel> static mutexes dont work portably
[16:42:53 CET] <nevcairiel> and you have no context to put them in
[16:43:16 CET] <atomnuker> what about pthread_once? we have that all over the codebase?
[16:43:35 CET] <atomnuker> to init the mutex during the first execution
[16:45:33 CET] <nevcairiel> i still dont understand your problem with the cas function, it doesnt take any unexpected arguments, the only difference is that it takes a pointer for the old value (so it can return the found value in it), but that value is NULL initially anyway so it makes no difference what kind of variable it is
[16:46:02 CET] <atomnuker> no, it takes a value for the new value, the old one's identical
[16:46:32 CET] <atomnuker> and also the avpriv one always returns the old value
[16:47:28 CET] <nevcairiel> so does the c11 one, just differently
[16:47:32 CET] <atomnuker> but the c11 atomics returns what we need in the old value
[16:47:42 CET] <nevcairiel> they both do the exact same thing with different syntax
[16:48:12 CET] <atomnuker> I tried to replace them - that was my first attempt and it didn't work
[16:48:26 CET] <atomnuker> but if you could show me how to do it properly for one, I could do the rest
[16:49:13 CET] <nevcairiel> i can make an actual patch later
[16:49:32 CET] <atomnuker> thanks
[16:58:39 CET] <wm4> the correct solution is to make the lists static
[16:59:34 CET] <atomnuker> yeah, I agree, I don't get why there's a need to register anything at all
[16:59:56 CET] <atomnuker> future external filter registration?
[17:00:36 CET] <atomnuker> (which is also pointless when you'll just have your own AVFilter struct
[17:02:05 CET] <wm4> you can't have external filters because there's a whole load of issues about it needing private APIs
[17:02:27 CET] <wm4> and if libs could register process global filters it'd be chaos anyway
[17:02:40 CET] <wm4> so that needs to be fundamentally changed from the current API and design anyway
[17:02:41 CET] <nevcairiel> more importantly we should fix the currently-broken atomics thing with msvc, either revert the patch because thsoe variables dont need atomic access (they werent even before), or just remove them entirely
[17:02:48 CET] <wm4> (but some people don't want to understand this)
[17:02:57 CET] <iive> in theory they could be complete autonomous implementations. But somehow this is not feature I like.
[17:03:56 CET] <atomnuker> nevcairiel: I posted a patch on the ml to remove them a few days ago, could use a review
[17:04:46 CET] <atomnuker> oh nvm, you did post something as a reply but michaelni thought they're useful
[17:05:46 CET] <nevcairiel> usually it would likely deadlock from the pthread lockmgr anyway before those things become useufl, but shrug
[17:05:56 CET] <atomnuker> michaelni: would you mind if we remove them anyway?
[17:10:00 CET] <durandal_1707> there are no 3rd party filters
[17:10:57 CET] <durandal_1707> and any 3rd filters are circulated as patches anyway
[17:11:20 CET] <nevcairiel> third party registration is not really possible right now, you need too much internal apis to build them
[17:12:24 CET] <durandal_1707> what about codecs?
[17:13:03 CET] <atomnuker> not possible and with good reason too I think
[17:13:11 CET] <JEEB> if we really want to support that it has to be thought well. right now we might as well not have those APIs that seem as if we support it
[17:13:24 CET] <JEEB> because currently if someone wants to use that public API that we have they need to use private symbols
[17:13:29 CET] <JEEB> which is a no-go anyways
[17:13:43 CET] <atomnuker> we do not want to support external codecs, filters maybe, but not codecs
[17:14:03 CET] <durandal_1707> no
[17:14:14 CET] <nevcairiel> filters maybe in the future
[17:14:54 CET] <durandal_1707> there is enough filters,  you do not need more ever!
[17:15:14 CET] <JEEB> yea, currently we don't properly support external registration so when someone thinks that needs to be properly supported we can think about it. right now fixing builds and possibly cleaning up the public API that doesn't make sense are OK.
[17:15:26 CET] <JEEB> if removing that public API for registration is what fixes things, that is
[17:15:40 CET] <wm4> if external registration ever becomes possible, it won't be a global registration anyway
[17:15:44 CET] <JEEB> yea
[17:15:47 CET] <wm4> so the current API and code can't be used
[17:15:55 CET] <JEEB> ayup
[17:20:07 CET] <durandal_1707> make those functions nop and deprecate them
[17:39:35 CET] <michaelni> For an open source project, not supporting external filters is very odd. Also some filters i was considering to write, iam not sure would really fit that well into libavfiler core though i have way too much to do anyway then start working on mor things
[17:40:36 CET] <wm4> and here you go, completely ignoring all the arguments
[17:40:37 CET] <michaelni> also libavfilter had a usable public API  that allowed external filters which is step by step disappearing
[17:41:37 CET] <nevcairiel> it was never really usable, and keeping it stable would hinder the ability to further develop avfilter
[17:46:00 CET] <cone-761> ffmpeg 03Thomas Guillem 07master:84936f68ede2: lavc: Make hardware config method support more explicit for hwaccels
[17:46:12 CET] <michaelni> nevcairiel, i dont agree that it wasnt usable. But of course aou are correct that a public API restricts the kind of changes that can be done. I do belive that a stable and public API is very important. A always changing API is not good even if its not public
[17:47:05 CET] <wm4> you mean you want to prevent that some things can ever be fixed or improved
[17:48:43 CET] <durandal_1707> if you want to prevent stuff from happening just leave
[17:49:35 CET] <jamrial> changing api if it's needed to move forward is obviously acceptable
[17:50:06 CET] <michaelni> durandal_1707, do you mean me ? if so i think you misunderstand what i meant, i just stated my oppinion
[17:50:25 CET] <jamrial> we're not the win32 kernel. we can remove old deprecated api every couple of years
[17:57:36 CET] <iive> michaelni: i would very much prefer if filter you write are in libavfilter, even if they do not fit into the core and use private ffmpeg apis
[17:58:12 CET] <iive> I'm still angry at BBB for blocking the 100fps interpolation filter
[17:58:38 CET] <durandal_1707> iive: where is such filter posted?
[17:58:56 CET] <JEEB> how is a 100Hz interpolation filter any different from the interpolation filters we currently have?
[17:59:09 CET] <iive> JEEB: using motion estimation?
[17:59:12 CET] <JEEB> yea
[17:59:21 CET] <durandal_1707> also michaelni only have to write gpl fitlers
[17:59:23 CET] <JEEB> we also have the simple thing that just duplicates stuff
[17:59:57 CET] <durandal_1707> no. you are wrong. again.
[18:00:01 CET] <iive> JEEB: what's the name of that one?
[18:00:21 CET] <JEEB> which one?
[18:00:33 CET] <durandal_1707> framerate, fps, minterpolate
[18:00:42 CET] <JEEB> but yes, those are the three
[18:00:54 CET] <JEEB> first two are simple, minterpolate does actual mocomp etc
[18:09:52 CET] <iive> michael's filter has been named vf_mcfps and it has been proposed around august 2015. minterpolate seems to land a year later 2016.
[18:11:22 CET] <JEEB> I just replied at the comment about blocking a "100Hz interpolation filter" regarding teh current state
[18:12:06 CET] <durandal_1707> why.  dont be mean.
[18:17:38 CET] <iive> JEEB: i'm glad you did.
[18:18:21 CET] <cone-761> ffmpeg 03Mark Thompson 07master:2adfb1092166: configure: Move V4L2 M2M help line to the hardware library section
[18:20:11 CET] <iive> anyway, back to the topic.
[18:20:36 CET] <jkqxz> Has something horrible happened recently to configure on Windows?  "Real  24m26.712s"
[18:21:01 CET] <wm4> shell programming
[18:22:04 CET] <JEEB> ^
[18:22:04 CET] <jkqxz> I can't see anything in the history, but it was only five minutes or so a week or two ago.
[18:22:23 CET] <JEEB> but yea, that sounds real bad
[18:22:31 CET] <durandal_1707> Diego happened
[18:22:33 CET] <JEEB> and thus makes me real happy that I'm doing the shell part from *nix
[18:22:38 CET] <wm4> the deps handling changes make it slower
[18:22:44 CET] <JEEB> durandal_1707: that happened more than 2 weeks ago
[18:23:08 CET] <jamrial> yeah, but not 24m
[18:23:17 CET] <jamrial> it was more like 15m
[18:23:19 CET] <JEEB> yea
[18:23:31 CET] <wm4> also I suspect a win10 update shat on performance
[18:23:42 CET] <wm4> maybe something about fork performance
[18:23:48 CET] <jamrial> still awful, but not "lets watch an anime episode while this thing figures out dependencies" awful
[18:23:55 CET] <wm4> or filesystem peformance
[18:24:02 CET] <wm4> +r
[18:24:09 CET] <jamrial> yes, win10 fall creator fucked up somewhere it seem
[18:24:16 CET] <jamrial> it wasn't this bad in the previous build
[18:24:28 CET] <wm4> but yeah recently running configure on windows has meant "take a break" even more recently
[18:24:31 CET] <jkqxz> It uses very little CPU, and feels like it's just not doing anything most of the time.
[18:25:09 CET] <jamrial> if you look at task manager, you'll see sh.exe spawning constantly
[18:25:47 CET] <durandal_1707> somebody added bunch of sleep calls
[18:25:55 CET] <wm4> so when will the current build system be replaced wih cmake
[18:26:21 CET] <durandal_1707>  next gsoc 2018
[18:26:58 CET] <wm4> ok let's stop the nasty jokes... meson would potentially be good
[18:27:00 CET] <jamrial> agree, cmake is what all the cool github c++ kids are using nowadays
[18:27:54 CET] <wm4> more realistically, "someone" could probably investigate whether other shells spawn fewer processes
[18:28:13 CET] <wm4> and I think someone actually did that?
[18:28:21 CET] <JEEB> yea I think ash was faster?
[18:29:20 CET] <jamrial> or microsoft could fix whatever broke so we can go back to ~1m configure times
[18:29:56 CET] <JEEB> of course that's a thing that I'd like anyways :P
[18:30:05 CET] <JEEB> since it most likely would speed up other things as well
[18:30:06 CET] <durandal_1707> or fix configure to give rt feedback
[18:30:50 CET] <wm4> can their new linux subsys be used for building?
[18:30:53 CET] <JEEB> yes
[18:31:10 CET] <wm4> hm I assume technicallly that'd be a cross compile
[18:31:13 CET] <JEEB> yup
[18:31:19 CET] <wm4> weird shit
[18:31:36 CET] <JEEB> well, not like cygwin isn't a cross compile either (mingw-w64 compiler in cygwin)
[18:31:49 CET] <iive> the spawning slowdown is caused by the tests themselves
[18:31:53 CET] <JEEB> just that they all look like "exe"s
[18:32:21 CET] <iive> so using another method would be helpful only if they run less tests.
[18:32:49 CET] <durandal_1707> tests  can  run  in  parallel
[18:33:11 CET] <wm4> could, not can
[18:34:55 CET] <iive> as for the slowdown. it might be related to antivirus, checking for signatures and even dns/inet lookup.
[18:35:13 CET] <iive> there's been an old issue with offline C# startup.
[18:37:19 CET] <wm4> dns lookups?
[18:44:26 CET] <BtbN> jkqxz, try rebooting
[18:44:41 CET] <BtbN> windows has a bug that creating a new process gets slower the more processes it has created since it started
[18:45:00 CET] <durandal_1707> huh?
[18:45:24 CET] <BtbN> so configure on a fresh boot is like 5-10 minutes, after a couple days of uptime(which is easy, as windows does suspend to disk by default when you tell it to shut down) it goes to shit
[18:45:38 CET] <nevcairiel> mine has never done suspend by default
[18:45:45 CET] <BtbN> Windows 10 does that
[18:45:49 CET] <nevcairiel> not mine
[18:45:51 CET] <BtbN> you have to dig deep to turn that off
[18:46:02 CET] <BtbN> It being used as dev machine that constantly spews processes doesn't help with that issue either
[18:47:11 CET] <jkqxz> Another run got "Real  24m50.485s  User  1m48.368s  System  2m15.295s", so pretty close to the first one.
[18:47:16 CET] <jkqxz> I'll reboot and see if it helps.
[18:47:44 CET] <BtbN> https://www.techpowerup.com/235169/windows-10-process-termination-bug-slows-down-mighty-24-core-system-to-a-crawl was the related article iirc
[19:20:16 CET] <jkqxz> "Real  26m40.647s  User  1m52.611s  System  2m19.629s"
[19:20:17 CET] <jkqxz> Oh well.
[19:20:33 CET] <jkqxz> I shall be glad that I do not build on Windows very often.
[19:21:43 CET] <JEEB> I just used Fedora's mingw-w64 toolchain and updated mingw-w64 crt and headers manually (for the D3D11 stuff in mpv)
[19:27:43 CET] <durandal_1707> JEEB: where you posted that 100Hz mcfps message?
[19:27:52 CET] <JEEB> what
[19:28:18 CET] <JEEB> I have no idea of the darn context, I just replied that there might (you know, right now) be a reason to say no to a specific mocomp interpolation filter
[19:28:24 CET] <JEEB> which is limited to 100Hz
[19:29:04 CET] <JEEB> and you were replying on this channel at that time as well
[19:29:07 CET] <JEEB> so this is like ?!?!?!
[19:29:25 CET] <durandal_1707> yea, very strange
[19:29:49 CET] <iive> i don't think it was lmited to 100Hz
[19:30:09 CET] <iive> i just used it as generic name...
[19:54:37 CET] <durandal_1707> michaelni: and to what it should convert formats instead?
[19:55:01 CET] <durandal_1707> you dont like to provide solutions at all
[19:59:37 CET] <durandal_1707> i see nothing wrong with it
[20:00:25 CET] <durandal_1707> you just dont want to get rid of yuvj and instead picks random nonissues at a whim
[20:09:11 CET] <michaelni> durandal_1707, it should not convert twice as it needs just one convertion, noise supports yuv420p which the encoder uses
[20:14:01 CET] <durandal_1707> michaelni: i dont think what you reported is valid, the same issue existed before. And since when the encoding pixel format should be in priority when filtering
[20:14:34 CET] <nevcairiel> behavior of any given command should not result in a worse result then before
[20:15:18 CET] <durandal_1707> the same issue existed before
[20:15:37 CET] <durandal_1707> i dont think my patch introduces this
[20:16:38 CET] <JEEB> yes, probably not. there's probably an issue somewhere in the filter chain generation
[20:16:46 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:1d0817d56b66: avcodec/amrwbdec: Fix division by 0 in voice_factor()
[20:16:47 CET] <cone-761> ffmpeg 03Michael Niedermayer 07master:eaff5fcb7cde: avcodec/vp9_superframe_split_bsf: Fix integer overflow in frame_size/total_size checks
[20:17:44 CET] <durandal_1707> its not a bug, first filter can not know encoder format
[20:17:58 CET] <durandal_1707> *should not
[20:20:30 CET] <michaelni> the format lists are merged step wise, convertion would occur where merge is not sensible or possible, so if noise and the output have a comon format the lists would be merged and no convert would occur there. That is what i would guess should happen but something seems not to work this way after the patches
[20:49:05 CET] <cone-761> ffmpeg 03Carl Eugen Hoyos 07master:514cf22a0d3a: lavc/huffyuvenc: Move a variable declaration up.
[20:52:11 CET] <durandal_1707> michaelni: there are only 2 cases: convert to encoder fornat first and do filtering or second convert to filter format and do filtering
[20:53:53 CET] <durandal_1707> which case have more sense to you?
[21:03:43 CET] <michaelni> each filter has a list of formats on each of its in and outputs together with linkage where they need to match. These lists are merged or linked, only once such merging is not possible is convertion needed
[21:04:15 CET] <michaelni> this can sometimes be on the input and sometimes be the output side of a filter
[21:05:43 CET] <michaelni> in A->B->C if A and B have a common format but B and C do not then convert is needed between B and C if its the other way around then A and B
[21:06:57 CET] <michaelni> this worked last time i looked at the code which indeed was some time ago
[21:09:55 CET] <durandal_1707> im this case scale is inserted only for color range from output
[21:13:06 CET] <michaelni> noise should support any color range, it should not care about it as long as input and output match
[21:13:34 CET] <michaelni> so noise out shouldnt need a convert 
[21:17:49 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:c5fd23879ac2: avformat/utils: Fix warning: ISO C90 forbids mixed declarations and code
[21:17:50 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:60d250386bb1: avcodec/amrwbdec: Fix division by 0 in voice_factor()
[21:17:51 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:1fab842fbb43: avcodec/vp9_superframe_split_bsf: Fix integer overflow in frame_size/total_size checks
[21:56:26 CET] <durandal_1707> michaelni: mpeg encoder does care as it supports limited only color range
[22:06:09 CET] <michaelni> yes, the filter chain end has to produce what the next part (the encoder) needs
[22:12:43 CET] <durandal_1707> michaelni: so how should i proceed?
[22:27:07 CET] <michaelni> i didnt debug this / didnt review all the chnages but spliting color_range out of pixel format should not worsen the amount of inserted converters 
[22:28:35 CET] <michaelni> maybe s/ not worsen the amount of inserted converters/not make the converter choices worse/
[22:31:28 CET] <michaelni> the audio codepath may have had similar issues to deal with as audio is also split in several paramaters (layout, sample format ...)
[22:31:56 CET] <michaelni> s/may have//
[22:36:12 CET] <durandal_1707> atomnuker: what you managed to code today?
[22:57:10 CET] <cone-761> ffmpeg 03Michael Niedermayer 07release/3.4:bc839fb39dc3: Changelog: Update for the last 3 commits
[23:03:48 CET] <durandal_1707> michaelni: i see no code where this can be changed
[23:17:01 CET] <cone-761> ffmpeg 03Carl Eugen Hoyos 07n3.4.1:HEAD: lavc/huffyuvenc: Move a variable declaration up.
[23:50:22 CET] <BtbN> 115 new mails since a few hour ago...
[00:00:00 CET] --- Mon Dec 11 2017