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

[burek]

[00:19:39 CET] <cone-650> ffmpeg 03James Almer 07master:0e2fbd68e279: avformat/mux: factorize AVFormatContext->avoid_negative_ts initialization
[00:32:36 CET] <cone-650> ffmpeg 03Jun Zhao 07master:4280948702bc: avfilter/formats: fix wrong function name in error message
[01:38:47 CET] <cone-650> ffmpeg 03Aman Gupta 07master:88e2dc7d0448: libavcodec/mpegvideo_parser: improve detection of progressive mpeg2
[10:43:47 CET] <atomnuker> "in extremely sensitive medical, military and enterprise applications"
[10:44:34 CET] <atomnuker> so this is the most EXXXXTTIME!1!! existing protocol?
[10:45:56 CET] <atomnuker> "We see a dramatic adoption of the protocol in the market" <- is that guy seriously trying to market it this way on the ml?
[10:45:59 CET] <durandal_1707> should all rgb decoders set color range to full pc?
[10:47:34 CET] <atomnuker> absolutely, we do not currently support limited range rgb (which does exist but only on hdmi and sdi afaik)
[10:49:14 CET] <durandal_1707> they dont
[10:51:01 CET] <atomnuker> yep, so that's why they should set the range to full
[10:51:09 CET] <nevcairiel> even the hdmi spec calls it invalid, but some devices still accept it
[10:51:13 CET] <nevcairiel> or even expect it
[11:18:57 CET] <kierank> atomnuker: lol
[11:19:10 CET] <kierank> Marketing
[11:27:41 CET] <wm4> nevcairiel, atomnuker: yes, some devices apparently expect limited range rgb
[11:27:49 CET] <wm4> which is fucked up, but ok
[11:34:53 CET] <jkqxz> HDMI assumes limited range for CE modes and full range for IT modes.
[11:34:59 CET] <jkqxz> It's definitely not invalid.
[11:35:18 CET] <jkqxz> (Fun question: is 1920x1080 a CE mode or an IT mode?)
[11:35:48 CET] <cone-703> ffmpeg 03Martin Vignali 07master:46f534bdee34: avfilter/vf_hflip : move context func init in ff_hflip_init
[11:35:49 CET] <cone-703> ffmpeg 03Martin Vignali 07master:cefb7e00608d: checkasm/vf_hflip : add test for vf_hflip byte and short simd
[11:36:01 CET] <nevcairiel> HDMI also assumes YCbCr in CE modes however
[11:36:13 CET] <nevcairiel> consumer devices dont give you rgb
[11:38:32 CET] <nevcairiel> anyway limited range rgb is still just weird
[11:38:37 CET] <jkqxz> Is that a requirement in HDMI 2?  That's not in HDMI 1.4.
[11:39:34 CET] <jkqxz> Sinks are allowed to be RGB-only in 1.4 (with suitable EDID).
[11:39:49 CET] <nevcairiel> its supposed to default to YCbCr anyway if nothing restricts that
[11:40:08 CET] <jkqxz> True, but it's not required to be possible.
[12:26:15 CET] <cone-703> ffmpeg 03Kelly Ledford 07master:bc219082bb04: libavfilter/af_dcshift.c: Fixed repeated spelling error
[12:26:16 CET] <cone-703> ffmpeg 03Kelly Ledford 07master:309ddcbe6166: patcheck: Add 'threshhold' to common typo list
[12:49:51 CET] <rcombs> michaelni: presumably to have a FATE test for the matroska issue, we'd need to add a sample (since it only triggers on corrupt data)
[12:50:07 CET] <rcombs> I don't have a small sample, but I guess I could fuzz one
[13:16:43 CET] <michaelni> rcombs, if you have a small sample that i should upload then ping me
[16:12:02 CET] <cone-072> ffmpeg 03Tristan Matthews 07master:e8f0a463b0d2: ivfenc: add AV1 support
[16:48:55 CET] <durandal_1707> why not opengl generic shader filter? vulkan is immature.
[16:52:36 CET] <BtbN> Because OpenGL is bad
[16:52:47 CET] <BtbN> It would be a nightmare to do OpenGL filters with its global state
[16:52:48 CET] <jkqxz> OpenGL is a horrible mess of global state.  How do you set up the OpenGL context and avoid libavfilter interfering with anything else running in the program?
[16:53:12 CET] <BtbN> Well, I guess you could have a private internal context?
[16:54:14 CET] <atomnuker> durandal_1707: you're immature, vulkan is perfectly equipped for everything
[16:55:09 CET] <durandal_1707> using glfw
[16:55:52 CET] <durandal_1707> vulkan is dangerous it can erupt at any given time
[16:56:10 CET] <mateo`> glfw does not support Android or iOS
[16:57:00 CET] <durandal_1707> im gonna cry now
[16:57:09 CET] <atomnuker> durandal_1707: no, it can't, proprietary junk driver can though
[16:57:14 CET] <mateo`> but implementing a backend for each os is not that difficult
[16:57:43 CET] <atomnuker> *534
[16:57:50 CET] <ubitux> say that to apple
[16:57:51 CET] <jkqxz> I guess it depends on what the use-case for it actually is.
[16:58:34 CET] <jkqxz> If all you want is to be able to write stuff in GLSL rather than C, then keeping it internal to lavfi could work.
[16:58:54 CET] <atomnuker> our just use vulkan with glslang
[16:59:02 CET] <wm4> <jkqxz> OpenGL is a horrible mess of global state.  How do you set up the OpenGL context and avoid libavfilter interfering with anything else running in the program? <- you can use a different thread
[16:59:13 CET] <wm4> glslang sucks and has global state
[16:59:53 CET] <jkqxz> If the point is to actually make things faster for weak devices then you want all the device management and interop.
[17:02:10 CET] <durandal_1707> so how would one do vulkan custom filtering when glslang have global state?
[17:03:55 CET] <rcombs> you can also store the current context, switch to a different one, do your GL shit, and then switch back
[17:03:57 CET] <rcombs> I think
[17:05:03 CET] <rcombs> fuck global state though
[17:05:09 CET] <rcombs> and fuck thread-local state too
[17:05:42 CET] <BtbN> for interop you can share between an external and an internal context
[17:09:40 CET] <durandal_1707> actually there is already glfw filter for ffmpeg on github
[17:11:47 CET] <durandal_1707> atomnuker: should asynth filter use AVExpr or something else?
[17:16:09 CET] <wm4> rcombs: some OS APIs for this force flushing the GL context on switch, so it's not entirely transparent
[17:32:28 CET] <rcombs> wm4: lovely
[18:08:23 CET] <nevcairiel> some recent-ish extensions let you control the forced flush on switch
[18:11:27 CET] <wm4> yeah
[18:13:35 CET] <BtbN> properly done OpenGL/GLSL filters would be nice. There is interop for pretty much every other API
[18:17:03 CET] <atomnuker> there's opencl which is better
[18:17:40 CET] <durandal_1707> you can use shaders with it?
[18:18:00 CET] <BtbN> opencl lacks interop with CUDA, and I wouldn't be surprised if it also lacks it for stuff on osx
[18:20:05 CET] <jkqxz> durandal_1707:  Pixel shaders, sure.  See the "run arbitrary pixel shader program" filter which still isn't applied.
[18:20:52 CET] <durandal_1707> why it isnt applied  ?
[18:21:13 CET] <jkqxz> BtbN:  I would be fine with a good OpenGL implementation with interop.  It's just I'm pretty unsure what that would actually look like.
[18:21:39 CET] <BtbN> pretty similar to the current map stuff
[18:21:48 CET] <BtbN> you can map a GL texture to pretty much every hw format
[18:21:49 CET] <jkqxz> And a hacky thing looking like the old OpenCL implementation would not be good.
[18:22:27 CET] <jkqxz> I'm more thinking of how devices, frames and context management might work.
[18:25:07 CET] <jkqxz> durandal_1707:  Carl had concerns about it running arbitrary code, and whether it's making something like vhook (which was removed a long time ago).
[18:25:25 CET] <wm4> wat
[18:25:32 CET] <BtbN> a filter intended to run arbitrary shaders can run arbitrary code! Oh my god.
[18:25:33 CET] <durandal_1707> carl should be ignored
[18:25:35 CET] <wm4> as usual he's full of shit
[18:25:53 CET] <BtbN> Just don't allow it to download filters from the net
[18:26:13 CET] <BtbN> Carl also wants me to change an nvenc option to work exactly like it does in x264, even though it just doesn't...
[18:26:14 CET] <jkqxz> I just pushed the set without it.
[18:26:33 CET] <jkqxz> Because I wasn't feeling like spending more time on it.
[18:28:01 CET] <jkqxz> It loads from a local file only.  That is a bit ugly if someone can convince it to load a sensitive file, because something might be revealed in the compiler error messages.
[18:28:38 CET] <BtbN> easy, only log them to a local file as well
[18:28:48 CET] <BtbN> that way, if someone were to read it, they'd have access anyway
[18:34:11 CET] <jkqxz> Writing local files isn't so good either.
[18:34:48 CET] <jkqxz> And that stuff really should be in the normal log.
[18:35:44 CET] <wm4> it's a complete non-argument anyway
[19:11:36 CET] <Dis> Hi, from ffmpeg mp4 muxer code it looks like the senc item is written into the stbl box instead of traf box. Because of this issue, I observe macroblocks. Hence I moved the senc atom to traf atom but after this change I get senc duplicate atom. Did anyone observe this? thanks in advance
[19:57:04 CET] <atomnuker> BBB: yeah, that alignment was weird so I amended it
[20:41:11 CET] <philipl> BtbN: ignore Carl?
[20:41:34 CET] <BtbN> that's my plan so far
[20:41:49 CET] <BtbN> But I suspect he will come up with a patch for it
[20:42:42 CET] <philipl> That would surprise me, but then you can NAK it, and someone can call a vote, and it will end up with nothing happening. As long as "do nothing" gets you what you want, the system is very effective.
[20:43:58 CET] <philipl> jkqxz: Repeating a question you probably didn't see, does Paul's yuvj removal changeset also remove your yuvj problem with the mjpeg hooks?
[21:53:26 CET] <tmatth> BBB: are you frowning at me for av1 muxing or continued ternary abuse?
[21:53:40 CET] <BBB> continued ternary abuse
[21:53:44 CET] <tmatth> that is fair
[21:53:51 CET] <BBB> Id prefer a LUT or something
[21:53:56 CET] <tmatth> yeah
[21:54:50 CET] <BBB> (or reuse the fourcc LUTs)
[21:54:59 CET] <BBB> av1 muxing is awesome
[21:55:02 CET] <BBB> (and demuxing)
[23:23:52 CET] <durandal_1707> michaelni: the experimental limited support in mjpeg is  broken, it should be either fixed or removed
[23:29:26 CET] <cone-274> ffmpeg 03Michael Niedermayer 07master:f7617d4b83c0: libavcodec/decode: remove duplicate includes
[23:30:09 CET] <michaelni> durandal_1707, what broke it ?
[23:32:38 CET] <durandal_1707> michaelni: it doesnt insert required metadata
[23:32:51 CET] <durandal_1707> flag of some sort
[23:34:00 CET] <durandal_1707> it was never correct, so it is experimental
[23:38:00 CET] <michaelni> it should store "CS=ITU601" in jpeg_put_comments()
[23:39:31 CET] <wm4> which applications understand this
[23:39:32 CET] <michaelni> and it seems to still do that here
[00:00:00 CET] --- Thu Dec 14 2017