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

[burek]

[00:12:40 CEST] <jamrial> jkqxz: right, nevermind, the ff_stream_add_bitstream_filter() call happens only with mp4 encapsulated packets
[00:12:54 CEST] <jamrial> for some reason i assumed it was always inserted
[00:16:54 CEST] <jkqxz> So, IVF only?
[00:18:50 CEST] <jkqxz> (Or should MKV also be included since vp9_superframe is included unconditionally there?)
[00:19:27 CEST] <jamrial> yes, vp9_superframe should be a dep for both matroska and ivf
[00:20:01 CEST] <jamrial> as i said, it prevents muxing split packets that neither muxer can detect and promptly abort
[00:21:29 CEST] <jkqxz> I don't think you can do that anyway, because the muxer will fail at init with VP9 if the BSF isn't there.
[00:24:01 CEST] <jamrial> true
[03:26:25 CEST] <BBB> tmm1: Im at demuxed this week </late>
[03:52:51 CEST] <peloverde> me too
[08:26:20 CEST] <BBB> peloverde: woohoo! see you tomorrow :)
[16:56:17 CEST] <durandal_1707> Compn: can you search web for ScreensDMO.ax file?
[17:43:08 CEST] <durandal_1707> posted on reddit, looking if anything useful appears
[17:44:50 CEST] <BtbN> philipl, do you have a commandline I can test with? I have no idea how mpv works.
[17:45:45 CEST] <philipl> mpv --gpu-api=opengl --hwdec=nvdec --msg-level=vo=debug <file>
[17:46:12 CEST] <philipl> At the top, it'll say if it's using angle or not. I would assume not unless you went out of your way to install it.
[17:46:22 CEST] <philipl> There's some other command line option to force the gl context.
[17:46:57 CEST] <philipl> --gpu-context=win
[17:47:24 CEST] <philipl> That should get you to symbol loading failing.
[17:50:13 CEST] <philipl> BtbN: I think the issue is the simplified load/sym calls in the header aren't enough.
[17:50:22 CEST] <philipl> w32dlfcn is a lot more elaborate.
[17:50:42 CEST] <BtbN> it really only does security checks. A plain stupid implementation should work
[17:51:22 CEST] <BtbN> also... why is my mpv.exe 1.3GB in size
[17:51:41 CEST] <BtbN> Just noticed that it took weirdly long to copy it around
[17:51:52 CEST] <philipl> Better strip those symbols. :-)
[17:52:17 CEST] <BtbN> now it's 163M
[17:54:19 CEST] <BtbN> "./mpv.exe --gpu-api=opengl --hwdec=nvdec --msg-level=vo=debug /mnt/d/Cache/game.of.thrones.s01e01.1080p.mkv" seems to work fine, but it "Cannot load cuInit"
[17:54:49 CEST] <philipl> Yes. That's what I saw
[18:00:40 CEST] <BtbN> I do wonder how it can compile, but not actually load the symbols
[18:01:35 CEST] <philipl> You don't need the cuda dll around to compile do you?
[18:02:42 CEST] <BtbN> no
[18:02:58 CEST] <BtbN> But the loading of the DLL seems to work
[18:03:02 CEST] <BtbN> but loading the symbol fails
[18:06:45 CEST] <philipl> Weird.
[18:12:29 CEST] <BtbN> A stupid simple test program works
[18:12:53 CEST] <BtbN> https://bpaste.net/show/c7037d22a702
[18:13:25 CEST] <BtbN> https://bpaste.net/show/cb742c9ea259
[18:14:29 CEST] <philipl> urp
[18:25:16 CEST] <BtbN> I have no idea what's going wrong when mpv does it
[18:28:28 CEST] <BtbN> I have a slight suspiciou it has something to do with it also linking against ffmpeg, which also loads the symbols, but differently
[18:35:05 CEST] <BtbN> oh, I have a suspicion
[18:36:54 CEST] <thebombzen> so apparently you can modify the timestamps of the AVPacket returned by av_read_frame to change the speed of video
[18:37:14 CEST] <BtbN> That's how timestamps work, yes?
[18:37:17 CEST] <thebombzen> however ffmpeg.c has no way to harness this
[18:37:30 CEST] <thebombzen> would it make sense to add an input option -force_framerate
[18:37:46 CEST] <iive> that's how video stamps work, audio is a little bit special
[18:38:05 CEST] <philipl> BtbN: your suspicion is?
[18:38:49 CEST] <thebombzen> yea I'm just referring to video here. I'm thinking of adding an input option -force_framerate that just modifies the timestamps on the AVPacket returned by av_read_frame for a video stream
[18:39:08 CEST] <thebombzen> to harness that feature on the ffmpeg.c CLI, but I'm not entirely sure if this is the best way to go about doing it
[18:39:23 CEST] <thebombzen> it might also make sense to implement as a bitstream filter
[18:41:03 CEST] <BtbN> philipl, http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=commitdiff;h=5054a06eb730fa5f024b945d62b13a30ab2d42d8;hp=d098cb44f6103a03476d16ac2bbe14ecbc9e1175
[18:41:27 CEST] <BtbN> mpv is probably built in WString mode
[18:43:03 CEST] <JEEB> :)
[18:43:28 CEST] <BtbN> I wonder why this even compiled without a single warning?!
[18:43:32 CEST] <JEEB> yea
[18:43:40 CEST] <JEEB> something definitely skipped a check somewhere
[18:43:48 CEST] <JEEB> or auto-converted in a header
[18:43:57 CEST] <BtbN> This is gcc-8.2.0 as well
[18:44:00 CEST] <philipl> BtbN: cool. So with that, it worked?
[18:44:03 CEST] <BtbN> I'd expect it to be warn-happy
[18:44:11 CEST] <BtbN> no idea, didn't test yet, but it was definitely wrong
[18:45:41 CEST] <BtbN> Yeah, load error is gone with that
[18:46:09 CEST] <BtbN> I can't really see if it's now using cuda hwaccel. Everything else looks the same
[18:46:42 CEST] <philipl> It'll say something like: VO: [gpu] 1920x1080 cuda[nv12]
[18:46:55 CEST] <BtbN> yes, it does do that
[18:47:00 CEST] <philipl> Then you did it.
[18:47:09 CEST] <philipl> You're the hero
[19:18:22 CEST] <BtbN> philipl, I updated the 8.0 branch and created an up to date 8.1 branch of the SDK, to avoid higher driver requirements where they are not needed.
[19:26:23 CEST] <philipl> OK
[19:30:29 CEST] <BtbN> So, not to get this Vulkan stuff working
[19:32:26 CEST] <philipl> yay!
[19:32:32 CEST] <philipl> s/not/now/
[19:32:59 CEST] <philipl> For reference: https://github.com/NVIDIA/cuda-samples/blob/master/Samples/simpleVulkan/vulkanCUDASinewave.cu
[19:33:06 CEST] <philipl> That has both linux and win32 interop in it
[19:33:56 CEST] <BtbN> They have the cuda side stuff different?
[19:34:08 CEST] <philipl> Just the handle type
[19:34:31 CEST] <BtbN> https://github.com/NVIDIA/cuda-samples/blob/master/Samples/simpleVulkan/vulkanCUDASinewave.cu#L281
[19:35:17 CEST] <BtbN> hm, that looks like normal C, why is it .cu?
[19:35:23 CEST] <philipl> filename weirdness
[19:37:46 CEST] <JEEB> has to be special because nvidia and cuda?
[19:38:45 CEST] <BtbN> I guess it's to make it be compiled with nvcc, not normal cc
[19:39:28 CEST] <BtbN> Is Vulkan on Windows 64bit only?
[19:46:23 CEST] <BtbN> this looks way messier than I expected
[19:46:36 CEST] <philipl> I think it is
[20:37:46 CEST] <cone-539> ffmpeg 03bnnm 07master:02ea060b2976: avformat/xwma: fix WMAv2 with incorrect bit rate
[20:38:14 CEST] <BtbN> philipl, mingw dxgi header don't have some required stuff...
[20:40:37 CEST] <JEEB> release or master?
[20:40:44 CEST] <JEEB> unfortunately they often only have some stuff in master
[20:43:10 CEST] <BtbN> master has DXGI_SHARED_RESOURCE_READ/DXGI_SHARED_RESOURCE_WRITE
[20:43:17 CEST] <BtbN> ".dwAccess = 0x80000001, // DXGI_SHARED_RESOURCE_READ | DXGI_SHARED_RESOURCE_WRITE" it is...
[20:47:39 CEST] <cone-539> ffmpeg 03Carl Eugen Hoyos 07master:b9136c1b9003: lavf/mxfenc: Remove a write-only variable.
[21:13:00 CEST] <BtbN> philipl, https://github.com/BtbN/mpv/commit/f858fec34d5078934d6723c4137f578d76e5e927 WinAPI is just lovely
[21:13:48 CEST] <JEEB> fancy
[21:17:38 CEST] <BtbN> it's far from done btw
[21:40:24 CEST] <nevcairiel> do you even need the security attributes, its optional
[21:41:03 CEST] <nevcairiel> its probably only needed if you want cross-process access or shit like that
[21:42:03 CEST] <nevcairiel> heck the entire struct may be unneeded if you want default access
[21:42:19 CEST] <nevcairiel> (which is READ|WRITE)
[22:11:16 CEST] <BtbN> no idea, this is straight from nvidias example
[22:12:51 CEST] <BtbN> https://www.khronos.org/registry/vulkan/specs/1.0-extensions/html/vkspec.html#VkExportMemoryWin32HandleInfoKHR yeah, it can just be NULL.
[22:13:02 CEST] <BtbN> that simplifies things... a bit
[22:29:01 CEST] <BtbN> philipl, so, how do I use this vulkan interop?
[22:50:21 CEST] <BtbN> "[vo/gpu/vulkan] Failed initializing SPIR-V compiler!" hm
[22:50:58 CEST] <atomnuker> nvidia deprecated their glsl to spriv extension, didn't they? did they disable it as well?
[22:51:18 CEST] <atomnuker> if so you'll have to compile shaderc, good luck
[22:53:37 CEST] <philipl> 2I had to compile shaderc yeah
[22:53:43 CEST] <philipl> It is not bad on linux
[22:53:56 CEST] <philipl> it expects you to checkout all the dependencies into its tree
[22:54:11 CEST] <philipl> the nvidia extension is gone in 4xx drivers.
[22:54:15 CEST] <philipl> which you need for interop
[22:54:34 CEST] <BtbN> This is Windows. It's probably a hot mess.
[22:55:58 CEST] <JEEB> shaderc is OK as long as you just vendor it with your app
[22:56:16 CEST] <JEEB> (in other words, no .pc file and nobody suddenly breaks your build)
[22:58:08 CEST] <BtbN> Doesn't seem like mpv does that
[22:58:32 CEST] <philipl> I had to do CFLAGS/LDFLAGS to find libshaderc for my linux build.
[22:58:42 CEST] <philipl> So no danger of .pc messing with you...
[22:59:13 CEST] <JEEB> BtbN: I've wondered but then people want to package it...
[22:59:34 CEST] <JEEB> although someone on #mpv just built it with mingw-w64 so apparently it works right now
[23:00:05 CEST] <JEEB> philipl: yes, the "you have to know which flags" is as fun as always :)
[23:09:10 CEST] <BtbN> ../third_party/glslang/StandAlone/StandAlone.cpp:1157:29: error: 'thread' is not a member of 'std'
[23:09:11 CEST] <BtbN> fun
[23:09:53 CEST] <philipl> newer libstdc++!
[23:10:25 CEST] <nevcairiel> and dont go around blaming windows again, msvc supports that since 2012!
[23:11:21 CEST] <BtbN> this is mingw
[23:11:35 CEST] <BtbN> And I'm running on gcc 8.2.0
[23:12:03 CEST] <philipl> https://stackoverflow.com/questions/37358856/does-mingw-w64-support-stdthread-out-of-the-box-when-using-the-win32-threading
[23:12:06 CEST] <philipl> ?
[23:12:17 CEST] <nevcairiel> mingw and threading is a terrible situation
[23:12:45 CEST] <nevcairiel> i wonder if their threading library stopped sucking these days
[23:14:11 CEST] <kierank> tmm1 on stage
[23:14:14 CEST] <BtbN> Do the "official" mpv Vulkan builds for Windows also do all that shit?
[23:14:28 CEST] <philipl> There are no official builds, per se.
[23:14:43 CEST] <JEEB> not sure which modules lachs0r enables but his docker images are used in the CI
[23:14:54 CEST] <philipl> You can ask shinchiro what he does too
[23:15:02 CEST] <philipl> His builds have vulkan
[23:15:17 CEST] <JEEB> he seems to build his own toolchain and all that crap, while I'm mostly just using fedora's standard toolchain with updated CRT and headers
[23:15:17 CEST] <BtbN> I have to re-build mxe
[23:15:22 CEST] <BtbN> this is gonna take an hour
[23:15:58 CEST] <BtbN> They have a special target for that
[23:16:13 CEST] <JEEB> ok, travis seems to build vulkan
[23:16:16 CEST] <JEEB> https://travis-ci.org/mpv-player/mpv/jobs/442733580
[23:16:27 CEST] <JEEB> so in theory you could use lachs0r's sysroot
[23:16:35 CEST] <philipl> but only for linux...
[23:16:58 CEST] <BtbN> I have x86_64-w64-mingw32.static right now. Need to re-build the toolchain to get x86_64-w64-mingw32.static.posix
[23:17:45 CEST] <nevcairiel> all these weird complicated projects to build cross-compilers
[23:17:58 CEST] <BtbN> mxe seems to be the most decent one so far
[23:18:05 CEST] <nevcairiel> i just use a shell script to invoke the configures etc
[23:18:20 CEST] <BtbN> Doing that for all the stuff mxe does would take me a week
[23:20:21 CEST] <nevcairiel> I strongly believe that one should at least once figure out how to build stuff, which is also why I really dislike these things like "Media Autobuild Suite" or however that thing is called that everyone uses to build ffmpeg and x265 these days. If you cant figure out how to build stuff, then just download binaries :)
[23:20:38 CEST] <BtbN> There are no binaries for this
[23:20:45 CEST] <BtbN> mxe is basically cross-compiler-emerge
[23:20:58 CEST] <nevcairiel> there is plenty cross-compiler binaries
[23:21:07 CEST] <BtbN> The compiler is the smallest problem of this
[23:22:09 CEST] <BtbN> It would take me a whole day to setup the environment mxe gives me within half an hour build time
[23:25:30 CEST] <wbs> fwiw, libc++ supports c++11 threads without any of the winpthreads mess inbetween. I've got prebuilt toolchains for windows now if anyone wants to give them a try; https://github.com/mstorsjo/llvm-mingw/releases
[23:26:44 CEST] <nevcairiel> the typical mingw stuff is so messy because it tries to get by without shipping its own C l ibrary or C++ library, and instead use the one in Windows, but at least for C++, they are really bad at it
[23:28:34 CEST] <nevcairiel> because it ends up an odd mixture of components, some from GCC, some from mingw, some from Windows itself
[23:29:25 CEST] <wbs> fwiw, my toolchains also target ucrt instead of the old deprecated/discouraged msvcrt.dll
[23:33:28 CEST] <wbs> ... and they support address sanitizer
[23:36:52 CEST] <jamrial> now that's interesting
[00:00:00 CEST] --- Thu Oct 18 2018