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

[burek]

[00:00:52 CET] <durandal_1707> they probably just wrappers
[00:29:52 CET] <cone-419> ffmpeg 03Andreas Rheinhardt 07master:ed9279afbd3b: h264_mp4toannexb: Remove unnecessary check
[02:53:49 CET] <mkver> stevenliu: This patch here: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254421.html fixes a recent regression (a memleak) in the hls muxer.
[04:09:29 CET] <mkver> stevenliu: Can you give a link to your dash patch where someone commented you should put the variables to the start of the function?
[04:11:28 CET] <stevenliu> let me find that
[04:27:43 CET] <stevenliu> mkver: wait some days later, i have to repair my computer, because the Macbooks' battery have bulging :(
[04:28:03 CET] <mkver> Ok. Sorry to hear that.
[04:28:27 CET] <stevenliu> i will do that use backup computer :D
[04:28:35 CET] <stevenliu> bye
[10:11:34 CET] <kierank> we should ban rude people from trac
[10:16:03 CET] <kurosu> that issue sure packs a lot of such people
[10:16:53 CET] <kurosu> I never quite understood the value of troll- or bully-driven incentivi[sz]ation
[10:17:56 CET] <kurosu> in this particular case, if someone was capable of implementing this, such ticket may drive him away from doing it
[10:18:20 CET] <thardin> idgi, isn't it just a case of telling ffmpeg to copy over the metadata?
[10:19:37 CET] <thardin> aha, it ties into lavfi's color model and whatnot
[10:20:12 CET] <thardin> real boomer energy in there
[10:23:03 CET] <kurosu> thardin: not paying further attention to this ticket anyway
[10:24:03 CET] <thardin> good call
[11:11:58 CET] <thardin> this guy doesn't seem to be aware that transfer functions are still a thing for 8-bit components
[11:33:46 CET] <nevcairiel> that entire ticket is full of so much ignorance
[11:40:04 CET] <JEEB> I think the ticket just veered somewhere ages ago
[11:40:11 CET] <JEEB> I haven't looked at it in months
[11:41:26 CET] <nevcairiel> The initial ticket was reported by that same guy thats still trying to educate everyone, so it never really had a good start to begin with
[11:42:59 CET] <nevcairiel> gotta love people that have an opinion how everyone else should run their projects and spend their time, but haven't contributed a single thing to anything in their lifetime
[12:08:51 CET] <cehoyos> This will make it much better;-)
[12:11:03 CET] <Illya> well... maybe he's not aware it's possible to sponsor work? :p
[12:11:09 CET] <Illya> not like it can get much worse anyway
[12:12:09 CET] <cehoyos> I'm not so sure: After all, the ticket was quiet for several months
[13:13:50 CET] <durandal11707> i get best output if i use normalize filter, so only tf is needed
[13:23:23 CET] <thardin> Illya: I think it's good
[13:24:20 CET] <thardin> someone exuding this amount of boomerism should not have a problem paying people for their hard work
[13:31:56 CET] <JEEB> teh colorspace info if it still is lost, is because ffmpeg.c initializes the encoder before it gets the output from filtering
[13:32:02 CET] <JEEB> you have that with non-HDR as well
[13:32:30 CET] <JEEB> I've been thinking if we should instead move libx264/5 to test init in init(), and actually properly init according to the AVFrame fed in case avcodeccontext doesn't have values set
[13:32:45 CET] <JEEB> that's AFAIR how VLC does it with their libx264 module
[13:34:05 CET] <nevcairiel> i thought we fixed some of that, but regardless, the HDR details are probably still lost, but imho their base assumption is just wrong, when they encode with  any other tool, they'll be prompted to pick what kind of of format of video they want to encode, and specify such information like HDR, but just because ffmpeg CLI is not interactive like that, they assume it'll magically do the "right thing" (whatever that is), without having 
[13:34:06 CET] <nevcairiel> to provide any information whatsoever
[13:34:45 CET] <JEEB> at least with filter_complex last I tested it wouldn't get the colorspace info, so libx264 got initialized with nope-nope-nope
[13:34:52 CET] <JEEB> but yes
[13:42:54 CET] <nevcairiel> there is a mechanic to wait for the filter to produce a frame before the output is setup, but it may just not hook up color properties at all
[13:43:10 CET] <nevcairiel> because of the disparity between context color properties and frame properties
[13:45:01 CET] <nevcairiel> in any case its not impossible to solve, someone just needs to untangle that a bit
[13:46:43 CET] <JEEB> yea
[13:46:57 CET] <JEEB> I tried to also make reconfig handle colorspace changes in libx264 once
[13:47:02 CET] <JEEB> got as far as adding code in x264
[13:47:12 CET] <JEEB> but I don't think it does anything unless you change rate control
[13:47:14 CET] <JEEB> :<
[13:48:15 CET] <durandal11707> yes, i found color space definitions for Blackmagic Design
[14:11:34 CET] <Illya> thardin: seems it was ignored anyway :'(
[14:15:11 CET] <JEEB> wow, they're in their own bubble
[14:31:29 CET] <thardin> no you see what he's saying is based on logic so he must be right
[16:18:36 CET] <cone-434> ffmpeg 03Andriy Gelman 07master:c07a77247363: lavc/cbs_h2645_syntax_template: Fix memleak
[20:45:56 CET] <philipl> BtbN: it was ffmpeg-devel.
[20:53:47 CET] <cone-529> ffmpeg 03Carl Eugen Hoyos 07master:84db67894f9a: lavu/log: Also print the log level for level trace.
[22:26:42 CET] <philipl> BtbN: https://patchwork.ffmpeg.org/patch/16329/
[22:41:00 CET] <cehoyos> Please don't feed the troll...
[22:46:43 CET] <cone-529> ffmpeg 03Carl Eugen Hoyos 07master:9f6a06d9271a: lavc/allcodecs: Add mpeg4 omx encoder, missed in 0e387232
[22:47:24 CET] <durandal11707> michaelni: please review swscale asm patches
[22:50:48 CET] <j-b> durandal11707: the ARM one?
[22:50:59 CET] <cehoyos> no, ssse3 iirc
[22:52:16 CET] <j-b> ok
[22:57:53 CET] Action: michaelni thought the developers who review all the x86 asm nowadays would want to review that too, but i can take a look, not today though, too late and too many other things to do
[22:58:55 CET] <j-b> Did someone summon Gramner or psilokos on those?
[23:32:43 CET] <BBB> I don't think psilokos is an active ffmpeg developer (yet)
[00:00:00 CET] --- Tue Dec 17 2019