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

[burek]

[04:51:23 CET] <atomnuker> what's the difference between map to/from and derive to/from?
[04:51:51 CET] <atomnuker> map_to and derive_to seem to do the same thing in opencl
[05:02:54 CET] <philipl> BtbN: I won't be able to. Just curious.
[12:02:42 CET] <wm4> why would a format flagged with AVFMT_NOTIMESTAMPS actually have timestamps on its packets
[12:04:33 CET] <wm4> utils.c must be making them up again
[12:04:39 CET] <wm4> what the fuck
[12:05:03 CET] <wm4> this of course ends up with totally unexpected behavior
[12:13:26 CET] <wm4> libavformat/utils.c is one of those parts of ffmpeg that would be improved by deleting almost everything of it
[14:05:08 CET] <mypopydev> @jkqxz Hi
[14:05:34 CET] <mypopydev> Submitted V4 for VPP part, please help to review, thanks a lot
[15:42:28 CET] <cone-573> ffmpeg 03Carl Eugen Hoyos 07master:7652af9df06d: lavf/swfdec: Reduce score when auto-detecting swf files.
[16:21:08 CET] <wm4> jamrial: looked at my git history, apparently this file was said to require parsing: http://www.cccp-project.net/beta/test_files/mzero_truehd_sample.mkv
[16:21:18 CET] <wm4> seems to work without parsing, though (at least today)
[16:30:36 CET] <jamrial> wm4: without full frame reconstruction, it emits several warnings for the first frame (or frames), but ultimately it decodes the same
[16:34:13 CET] <wm4> yeah
[16:34:36 CET] <wm4> the commit message seems to indicate the problem was worse, dunno how that makes sense
[16:37:41 CET] <JEEB> well there was some reason why that sample was posted to me back in ye olden days - could check some really old logs
[16:39:03 CET] <wm4> it was a largish change to mpv's mkv demuxer in 2013, so there was probably a reason indeed
[16:39:24 CET] <wm4> but retrying it with parsing disabled now appears to work
[16:39:31 CET] <wm4> maybe the truehd decoder got more tolerant?
[16:41:23 CET] <atomnuker> yeah, I forget if it doesn't emit the warning on seeks
[16:41:36 CET] <atomnuker> but it shouldn't
[17:58:38 CET] <atomnuker> that's a bit of a curveball but you never know, lots of university students sit around and do things like that rather than study
[18:15:08 CET] <cone-573> ffmpeg 03Marton Balint 07master:e3acba0d5d7b: avfilter/formats: remove support for deprecated channel count specification
[18:38:09 CET] <jamrial> atomnuker: "godlike familiarity" isn't exactly encouraging
[18:39:35 CET] <wm4> would be something for hanna?
[18:39:54 CET] <raytiley_> trying to submit my first patch... is there a delay in how fast it shows up in patchwork? just wanna make sure I'm doing this right
[18:40:03 CET] <wm4> also why does it say GLSL - Vulkan doesn't support GLSL
[18:40:03 CET] <JEEB> patchwork might take a while
[18:40:13 CET] <JEEB> wm4: glsl extension IIRC
[18:40:24 CET] <wm4> JEEB: only nvidia, and it's broken
[18:40:24 CET] <jamrial> raytiley_: it already showed up in the mailing list, so it went through just fine
[18:40:40 CET] <raytiley_> jamrial: thanks 
[18:40:42 CET] <JEEB> wm4: why am I not surprised, although it seems like mesa also implemented it?
[18:40:44 CET] <wm4> you can use any language that can be compiled to spir-v so you're technically free to pick the shader language
[18:40:57 CET] <wm4> JEEB: maybe they added it then
[18:51:08 CET] <atomnuker> I'd rather not have spriv binaries in the repo, so glsl's the only option
[18:51:53 CET] <wm4> do you want to rely on the GLSL extension?
[18:51:56 CET] <atomnuker> nope
[18:52:09 CET] <JEEB> so some glsl-spirv compiler?
[18:52:12 CET] <wm4> so you'd need to link a shader compiler anyway
[18:52:27 CET] <atomnuker> no, we don't need runtime shader compilation
[18:52:37 CET] <atomnuker> most distros ship glslang so that's nice
[18:55:42 CET] <wm4> so you do want spirv binaries in the repo?
[18:55:59 CET] <cone-573> ffmpeg 03Vishwanath Dixit 07master:7c27bbd590e6: avdevice/decklink: addition of copyts option
[18:56:01 CET] <cone-573> ffmpeg 03Vishwanath Dixit 07master:dfa2523bdd82: avdevice/decklink: addition of PTS_SRC_NB in enum DecklinkPtsSource
[18:56:01 CET] <cone-573> ffmpeg 03Vishwanath Dixit 07master:fc93eca126aa: avdevice/decklink: addition of absolute wallclock option for pts source
[18:56:02 CET] <cone-573> ffmpeg 03Devin Heitmueller 07master:5409f065f2c4: avdevice/decklink: Suppress warning about misuse of struct instead of class
[18:56:03 CET] <cone-573> ffmpeg 03Devin Heitmueller 07master:b5b48685043e: avdevice/decklink: Fix compilation of module on OSX
[18:56:26 CET] <atomnuker> no, glsl shaders which get converted to binaries and are included in whatever's going to use them as tables
[18:56:49 CET] <atomnuker> so not in the repo, but in the compiled library
[18:57:27 CET] <wm4> kind of bothersome, but ok
[19:02:33 CET] <c3-Win> If I can point to how Steam does it: You get the code with an option to have Steam deliver pre-compiled binaries.
[19:03:06 CET] <c3-Win> In this case the code=FFMPEG and the pre-compiled binaries are the various distros/hosts that provide the pro-compiled FFMPEGs that are installed.
[19:03:19 CET] <c3-Win> *pro=pre
[19:04:26 CET] <atomnuker> so steam games don't ship vulkan shader binaries but give some hl syntax to valve so it can distribute them separately?
[19:13:57 CET] <c3-Win> I'm guessing that's what happens.
[19:14:36 CET] <c3-Win> In Settings->Shader Pre-Caching it reads as follows:
[19:15:08 CET] <c3-Win> Shader Pre-Caching allows Steam to download pre-compiled GPU shaders matching your system configuration. This allows Vulkan
[19:15:25 CET] <c3-Win> and OpenGL games to load faster and improves framerate stability during gameplay.
[19:15:55 CET] <c3-Win> If enabled, Steam will collect shaders from your system when needed. Enabling this feature may slightly increase disk and bandwidth usage.
[19:16:51 CET] <c3-Win> and with over 2 TBs of games installed (not a lot of them are OpenGL or Vulkan though) 11MB of disk space is being used on the pre-cached shaders.
[19:18:28 CET] <atomnuker> I thought it used the layers subsystem to somehow get the compiled shaders and provide them to the drivers if they match
[19:30:25 CET] <cone-573> ffmpeg 03Henrik Gramner 07master:3a02cbe3facc: x86inc: Enable AVX emulation for floating-point pseudo-instructions
[19:30:26 CET] <cone-573> ffmpeg 03Henrik Gramner 07master:9e4b3675f226: x86inc: Use .rdata instead of .rodata on Windows
[19:30:27 CET] <cone-573> ffmpeg 03Henrik Gramner 07master:6b6edd121699: x86inc: Support creating global symbols from local labels
[19:30:28 CET] <cone-573> ffmpeg 03Henrik Gramner 07master:eb5f063e7ccc: x86inc: Correctly set mmreg variables
[19:30:29 CET] <cone-573> ffmpeg 03Henrik Gramner 07master:6f62b0bd4ff2: x86inc: Drop cpuflags_slowctz
[20:56:55 CET] <SortaCore> is there a reason the metadata is stripped if it's set before av_write_header?
[20:57:15 CET] <SortaCore> I get it's written in av_write_footer, but why is it stripped if it's early?
[21:35:26 CET] <cone-573> ffmpeg 03Nikolas Bowe 07master:ef5994e09d07: avformat/lrcdec: Fix memory leak in lrc_read_header()
[21:35:27 CET] <cone-573> ffmpeg 03Michael Niedermayer 07master:725353525e73: avcodec/ulti: Check number of blocks at init
[21:35:28 CET] <cone-573> ffmpeg 03Michael Niedermayer 07master:2eecf3cf8eea: avcodec/snowdec: Fix integer overflow before htaps check
[22:40:25 CET] <atomnuker> jkqxz: could you test my latest vulkan hwaccel on your amd card again?
[22:41:42 CET] <atomnuker> use -vf "format=rgb24,hwupload,hwdownload,format=rgb24" since radv doesn't support ycbcr formats yet, thought it should soon
[22:43:16 CET] <atomnuker> you can now specify an index as a device, so -init_hw_device "vulkan=sl:0,extensions=VK_EXT_debug_report" will work, though you can still pass a device name
[22:43:53 CET] <atomnuker> if it crashes make sure to add the debug extension like above and -loglevel trace so I can see what goes wrong
[00:00:00 CET] --- Sun Jan 21 2018