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

[burek]

[00:10:05 CET] <cone-487> ffmpeg 03Carl Eugen Hoyos 07master:978880c803d1: lavf/latmenc: Error out for unsupported codecs.
[00:54:33 CET] <cone-487> ffmpeg 03Marton Balint 07master:e85f37d51e97: avfilter/af_astats: add support for selecting measured statistics
[00:54:34 CET] <cone-487> ffmpeg 03Marton Balint 07master:233fdd84c2c7: avfilter/af_astats: fix identation
[00:54:35 CET] <cone-487> ffmpeg 03Marton Balint 07master:235228ea5090: avfilter/af_astats: factorize sample loops
[00:54:36 CET] <cone-487> ffmpeg 03Marton Balint 07master:5cc4b79b295d: avfilter/af_astats: rework sample loops
[00:54:37 CET] <cone-487> ffmpeg 03Marton Balint 07master:6af67dcc3519: avfilter/af_astats: add support for optimized min/max/peak calculation
[01:39:52 CET] <cone-487> ffmpeg 03Martin Vignali 07master:6dc1da416e14: Maintainers : remove myself
[02:46:43 CET] <cone-487> ffmpeg 03James Almer 07release/2.8:88588a24e915: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:45 CET] <cone-487> ffmpeg 03James Almer 07release/3.0:b307cbe27613: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:47 CET] <cone-487> ffmpeg 03James Almer 07release/3.1:f8e254716b62: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:50 CET] <cone-487> ffmpeg 03James Almer 07release/3.2:a06cd0283eea: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:52 CET] <cone-487> ffmpeg 03James Almer 07release/3.3:884ecede1701: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:54 CET] <cone-487> ffmpeg 03James Almer 07release/3.4:da6a61606a19: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:57 CET] <cone-487> ffmpeg 03James Almer 07release/4.0:d53202f92dc5: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[02:46:59 CET] <cone-487> ffmpeg 03James Almer 07release/4.1:dbef08b60f44: avcodec/hevcdec: decode at most one slice reporting being the first in the picture
[10:41:09 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:7ce56329e71f: avcodec/clearvideo: Check remaining data in P frames
[10:41:10 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:b429df281d50: avcodec/dfa: Check the chunk header is not truncated
[10:41:11 CET] <cone-026> ffmpeg 03Michael Niedermayer 07release/4.1:a7cb7a2e4314: Changelog: update
[10:54:07 CET] <j-b> kierank: wow, this guy does not like yo.
[10:56:22 CET] <durandal_1707> j-b: who is that guy? have nick on github?
[10:56:32 CET] <j-b> no clue
[10:56:44 CET] <j-b> he is active on various mailing lists saying "use libmpv"
[10:57:35 CET] <JEEB> I don't think anyone in that thread is an active mpv dev that I know of
[10:57:51 CET] <JEEB> unless there are user names I just don't remember
[10:57:57 CET] <JEEB> (which there probably are)
[10:58:11 CET] <durandal_1707> j-b: you should use libmpv
[10:58:27 CET] <JEEB> you never cease to try and troll people, do you?
[10:59:05 CET] <durandal_1707> are you attacking me?
[10:59:10 CET] <JEEB> no?
[11:00:22 CET] <j-b> durandal_1707: of course!
[11:00:28 CET] <j-b> durandal_1707: where is my AC-4 decoder? :D
[11:00:31 CET] <kierank> j-b: lol
[11:00:39 CET] <j-b> durandal_1707: also, I've seen more and more requests for IMM5
[11:00:42 CET] <kierank> durandal_1707: why you not respond to me tweets
[11:00:45 CET] <JEEB> :)
[11:01:00 CET] <j-b> kierank: because durandal_1707 hates you now. He's in love with me, now!
[11:03:50 CET] <kierank> j-b: :(
[11:03:54 CET] <kierank> All Brexit fault
[11:04:08 CET] <kierank> durandal_1707: do you come to my birthday
[11:04:31 CET] <j-b> that would be really cool!
[11:04:41 CET] <thardin> are any of you folks in london?
[11:05:20 CET] <funman> https://www.youtube.com/watch?v=acq2MvoSkJI
[11:05:26 CET] <thardin> say in two weeks
[11:05:49 CET] <kierank> No, in Vegas those weeks
[11:06:17 CET] <durandal_1707> j-b: then raise bounty for IMM5
[11:06:58 CET] <thardin> darn
[11:07:32 CET] <j-b> durandal_1707: OK
[11:43:18 CET] <cone-026> ffmpeg 03Carl Eugen Hoyos 07master:4d8875ec23cf: lavf: Constify the probe function argument.
[11:58:22 CET] <j-b> > It makes me unhappy that one FFmpeg developer apparently decided to leave
[11:58:25 CET] <j-b> the project already because of this. 
[11:58:27 CET] <j-b> who?
[11:58:35 CET] <nevcairiel> ffmpeg Martin Vignali master:6dc1da416e14: Maintainers : remove myself
[11:58:50 CET] <j-b> ok
[11:58:55 CET] <nevcairiel> (also, very unprofessional using the git log as his soap box)
[11:59:51 CET] <j-b> (very wtf, you mean)
[12:00:25 CET] <j-b> he does not even commit on the NDI code...
[12:40:21 CET] <BBB> is qsv open source?
[12:48:24 CET] <jkqxz> QSV is the marketing name for the hardware blocks.  The use of the name in FFmpeg is rather misleading, but has stayed for historical reasons.
[12:49:09 CET] <jkqxz> On Linux, the host software (both VAAPI and libmfx) is all open source.  Firmware blobs for the GPU are required for some encoding features, though.
[12:50:04 CET] <jkqxz> On Windows, decode works via the standard DXVA2/D3D11 OS interfaces but obviously the drivers themselves are proprietary.
[12:51:06 CET] <BBB> ok
[12:51:07 CET] <jkqxz> Other stuff on Windows is via libmfx, and all of that is closed.
[12:51:37 CET] <BBB> that is not great :-/
[12:52:02 CET] <JEEB> yea, I think the windows version is part of the Intel Media SDK?
[12:52:06 CET] <JEEB> which is not OSS?
[12:52:12 CET] <JEEB> unlike the lunix variant
[12:52:28 CET] <JEEB> although IIRC the intel media SDK on linux is a mess
[12:52:33 CET] <JEEB> like having to patch the kernel etc
[12:52:39 CET] <JEEB> vaapi on the other hand seems much saner
[12:52:43 CET] <JEEB> (and has dec and enc)
[12:53:25 CET] <jkqxz> Yes.  The Windows part is as bad an NVENC with dynload stuff for GPL evasion.
[12:53:49 CET] <jkqxz> libmfx on Linux is much saner than it used to be.  It works on normal kernels with no funny business nowadays.
[12:54:02 CET] <jkqxz> However, there is very little reason to use it rather than VAAPI.
[12:54:20 CET] <JEEB> yup
[12:54:27 CET] <BBB> you know GPL evasion is a bad word right?
[12:54:37 CET] <JEEB> ý(´ü@)Î
[12:54:37 CET] <BBB> in america, we have to bleeb that out on public broadcasts
[12:55:54 CET] <jkqxz> I'm sure the actual argument is that it falls under the system library exception.
[12:58:09 CET] <JEEB> > driver specific API installed by the hardware driver > provided by OS
[12:58:11 CET] <JEEB> ayyy lmao
[13:05:31 CET] <BBB> I've said before that I totally don't buy the current era's use of the system exception in the GPL
[13:07:09 CET] <JEEB> generally with proprietary operating systems it's pretty concise what is a component of the OS and what's not. like Videotoolbox being an OS component, or DXVA2 or D3D11VA
[13:07:53 CET] <JEEB> linux is the place where people generally tend to try and widen it mostly because linux by itself is just the kernel. then if you add the software from the distro then that area gets very very wide
[13:09:37 CET] <jkqxz> The firmware blobs for quick sync are a rather ugly problem.  They've built them into the userland driver to load when needed, which is very sensible technically.  But, it means that package contains a load of blobs and therefore lacks the full human-readable source code.
[13:10:41 CET] <jkqxz> The other drivers (e.g. Mesa / AMD) put their blobs in the linux-firmware repo to load at boot time, so the userland driver doesn't contain them.
[13:10:59 CET] <nevcairiel> that seems like a rather technical distinction
[13:11:09 CET] <nevcairiel> there is a blobl somewhere that you cannot read
[13:12:01 CET] <jkqxz> Debian does some splitting of this.  There is a blobless i965 VAAPI driver with partial functionality in Debian free.
[14:47:51 CET] <j-b> On windows, the QSV encoding part are installed with the drivers.
[14:48:56 CET] <j-b> It totally fits the "normally distributed with the major components" case
[14:49:52 CET] <j-b> We say that this part of the GPL is unclear and unfortunate, but we cannot redefine the GPL
[14:50:18 CET] <JEEB> yea, if we consider drivers as part of the OS
[14:51:01 CET] <j-b> This is the common interpretation since forever, of the GPL.
[14:51:15 CET] <j-b> " with the major components (compiler, kernel, and so on) "
[14:51:27 CET] <j-b> drivers are considered part of the "and so on"
[14:51:40 CET] <JEEB> esp. on linux I guess where the line is less clear-cut
[14:51:59 CET] <j-b> that is possible.
[14:53:16 CET] <j-b> But NDI is a clear-cut, IMHO
[14:53:24 CET] <JEEB> yes
[14:53:42 CET] <JEEB> (I think we had this discussion yesterday 8))
[14:54:01 CET] <JEEB> and now mostly were talking about the windows intel media SDK, which is how QSV is utilized on windows
[14:54:10 CET] <JEEB> the linux one is an open source thing anyways
[14:56:08 CET] <j-b> we use libmfx on Windows, I thought
[14:58:26 CET] <j-b> philipl: what is libnpp?
[15:00:19 CET] <j-b> BBB: openssl and tls are also part of the OS on some macOS/BSD, so they have the system library exception
[15:05:27 CET] <KombuchaKip> Why does the ffmpeg write it's own ./configure manually instead of using the autotools? Isn't it more work to reinvent its functionality?
[15:06:46 CET] <BtbN> Because autotools is a horrible mess.
[15:06:59 CET] <BBB> KombuchaKip: it's a sensitive subject to some devs
[15:07:16 CET] <BtbN> Almost everything is less of a pain than autotools
[15:07:21 CET] <KombuchaKip> BBB: Looks like it.
[15:07:30 CET] <j-b> meson is the future
[15:07:48 CET] <BtbN> I'd rather have cmake or configure re-written in python or something instead.
[15:08:07 CET] <JEEB> KombuchaKip: it probably was "simple enough" at first
[15:08:15 CET] <JEEB> then with time it got a lot of stuff in there
[15:11:19 CET] <atomnuker> somehow though the script ended up being faster than meson though
[15:13:51 CET] <JEEB> if it's less than minute(s) then really nobody cares /that/ much :D
[15:14:07 CET] <JEEB> it's just when it took minutes (and up to 10min on windows) when people cared about the speed
[15:16:35 CET] <nevcairiel> j-b: libnpp is a library of pre-defined cuda functions to execute on the gpu, ie. it has a scaler and other stuff like that, but that  one is certainly closed source
[15:17:19 CET] <nevcairiel> and honestly, that part is the easiest to get rid of
[15:17:50 CET] <nevcairiel> since w e have scale_cuda now, whats the point of scale_npp anymore
[15:17:59 CET] <jamrial> can you even make autotools handle fine grained dependecies for the hundreds of ffmpeg modules like our custom configure does?
[15:18:07 CET] <jamrial> i know you can with meson
[15:18:31 CET] <jamrial> but i've never seen autotools used for anything but relatively basic system deps checks
[15:19:09 CET] <KombuchaKip> jamrial: The autotools have had an M4 macro for pkg-config for many years to check dependencies.
[15:19:29 CET] <jamrial> i mean internal modules
[15:19:50 CET] <uau> about that "system library exception" thing, IIRC relying on that is still a problem for distributions even if you interpret it widely to include just about anything in the distribution
[15:19:59 CET] <jamrial> decoder depending on parser, which in turn depends on a bsf, and so on
[15:20:14 CET] <uau> since it's not permitted to rely on that for the system itself
[15:20:35 CET] <uau> i.e. microsoft can't ship ffmpeg as part of windows and say it's relying on system library exception for its own system
[15:20:42 CET] <KombuchaKip> jamrial: If you want recursive automake, it supports that. Otherwise you just add the dependencies as rules. They can be automatically generated for you if you like.
[15:21:20 CET] <uau> so that does not allow linux distributions themselves to ship ffmpeg
[15:23:50 CET] <j-b> BtbN: meson is in python :)
[15:24:26 CET] <BtbN> I was more thinking like literally translating the shell script we have now to python
[15:24:38 CET] <BtbN> My experiences with meson so far have been very underwhelming
[15:25:32 CET] <nevcairiel> i'm not overly impressed with meson either
[15:25:35 CET] <nevcairiel> a lot of rough edges still
[15:25:44 CET] <j-b> sure, but it will improve
[15:25:53 CET] <j-b> and people are moving to it :)
[15:46:48 CET] <jdarnley_obs> Did vlc finish moving to meson yet?
[15:47:38 CET] <jdarnley_obs> Also "recursive automake"?
[15:47:47 CET] <jdarnley_obs> that is insanity^2
[15:48:48 CET] <jdarnley_obs> or is it just regular automake insanity?
[15:49:08 CET] <j-b> jdarnley_obs: we're finishing it.
[15:49:30 CET] <j-b> jdarnley_obs: CMake is an insane mess. Meson is rough, but works.
[15:49:35 CET] <BtbN> I tried cross compiling stuff that used meson, and pretty much ended up compiling the thing manually
[15:49:46 CET] <BtbN> Cross-Compiling with cmake just works.
[15:49:47 CET] <jdarnley_obs> Good.  As a followup does vlc have any of its own x86 asm files?
[15:50:07 CET] <j-b> jdarnley_obs: and GTK*, Gnome, Systemd, Gstreamer, all low-level utils and libraries will move to meson, in the next year or so
[15:50:21 CET] <j-b> I expect this to happen more and more
[15:50:37 CET] <BtbN> Will be fun for anything that also needs to work on Windows
[15:50:45 CET] <BtbN> And support msvc especially
[15:50:47 CET] <j-b> BtbN: we use meson for dav1d without any problem and we compile on Android, iOS, Windows, Windows/ARM
[15:50:56 CET] <j-b> we use meson with MSVC already
[15:50:58 CET] <jdarnley_obs> BtbN cross compiling seems to be one area that is always ignored by configure/make replacements.
[15:51:12 CET] <j-b> we cross-compile with meson, without any issue.
[15:51:25 CET] <nevcairiel> cross-compiling with meson sort of works, but it defies any existing conventions and wants you to learn it all over again
[15:51:25 CET] <j-b> since meson has a MSVC backend, it produces directly a MSVC project file
[15:51:26 CET] <BtbN> It's not ignored, just not exactly well tested. I ran into numerous issues that were known but with no known workaround.
[15:52:14 CET] <jdarnley_obs> Maybe I should use meson to re-invigorate my interest in my visualization project.
[15:52:29 CET] <j-b> my experience is that there are still bugs in meson, true. But it is the less shitty alternative there is.
[15:53:07 CET] <nevcairiel> in my limited experience, its not finished enough to consider it, if you care about anything but plain linux builds
[15:53:38 CET] <j-b> nevcairiel: dav1d compiles all platforms with it. And it works fine
[15:53:52 CET] <j-b> CMake is beyond broken and horrible syntaxically. Bazel is a hammer that requires a very specific nail to work. Scons, qbs are slow and not useful. Qmake is limited.
[15:53:52 CET] <nevcairiel> once you figure out all the quirks of meson, sure
[15:54:02 CET] <BtbN> david doesn't exactly have dependencies though?
[15:54:27 CET] <j-b> dependencies are easy with pkgconfig
[15:54:27 CET] <nevcairiel> even a simple project like dav1d had me run against a few annoying meson quirks already
[15:54:31 CET] <BtbN> qmake is the Qt thing, right? If so, that's considered deprecated anyway.
[15:54:45 CET] <j-b> It's quite recent, so sure, there are issues, but compared to the others, it is a better alternative
[15:54:50 CET] <j-b> and custom scripts are always wrong
[15:55:01 CET] <BtbN> Yes, exactly that was the issue when I built stuff for Windows. meson wanted pkg-config everything. All the stuff did not have pkg-config on Windows.
[15:55:33 CET] <BtbN> Or it found the system pkg-config file instead, and blew up
[15:55:42 CET] <j-b> Fighting pkg-config in 2019 is unwise, sorry.
[15:56:00 CET] <BtbN> Well, I ended up hand writing a dozen pkg config files just to make it build
[15:56:15 CET] <BtbN> Because the libraries (a bunch of Vulkan stuff) does not ship with any
[15:57:10 CET] <BtbN> With CMake you can just override the paths and it will work. meson, nope, no dice.
[15:58:23 CET] <j-b> CMake is a huge mess
[15:58:42 CET] <j-b> With hundreds of Find**Package.cmake files that are never in sync
[15:59:01 CET] <j-b> and you get the same crap as m4/ scripts that are copied from one project to another
[15:59:02 CET] <BtbN> From my experience with dealing with build systems, cmake is the least troublesome
[15:59:32 CET] <BtbN> Most of those Find*.cmake scripts just invoke pkg-config anyway, and only do stuff if that fails.
[15:59:34 CET] <kurosu> j-b: I find meson MSVC solution file for dav1d horrendeous
[15:59:45 CET] <kurosu> not something I'd work with - only good for compiling
[15:59:54 CET] <j-b> kurosu: compared with the one from CMake? come on.
[15:59:56 CET] <JEEB> :D
[16:00:15 CET] <JEEB> yea, I was about to ask if it looked better or worse than such generated by cmake
[16:00:25 CET] <j-b> almost the same
[16:00:32 CET] <kurosu> j-b: there's stuff for CMake and dav1d? want! :p
[16:00:41 CET] <j-b> absolutely not
[16:00:44 CET] <kurosu> j-b: no really, I do prefer CMake output
[16:00:52 CET] <JEEB> you should detail that
[16:00:58 CET] <JEEB> and possibly make an issue/improvement into meson
[16:01:01 CET] <j-b> Cmake is a huge mess. We tried to move to CMake for VLC
[16:01:14 CET] <j-b> we had to stop, since litterally nothing was working
[16:01:35 CET] <j-b> I talk to KDE people a lot, and they are unhappy with CMake with Xcompilation
[16:01:51 CET] <kurosu> I'd post a screenshot of the solution file but can't at the moment
[16:02:11 CET] <kurosu> I just have the object files listed, not sure about the c files
[16:02:12 CET] <j-b> CMake being turing complete, people just write things in Find*.cmake that are redefining everything
[16:02:20 CET] <j-b> FindQt.cmake being the worst
[16:02:30 CET] <kurosu> and absolutely sure headers are not shown (or burried somewhere I haven't found yet)
[16:02:59 CET] <j-b> Anyway, I don't care if you love CMake more than meson
[16:03:11 CET] <j-b> my opinion is that meson will gain a lot more traction soon
[16:03:12 CET] <JEEB> he doesn't, he just liked the MSVS project file structur emore :P
[16:03:27 CET] <JEEB> thus I recommended him to provide an issue about that - or improve it with a patch
[16:03:36 CET] <j-b> and that people staying near CMake are going to have a big battle to fight against it
[16:04:07 CET] <BtbN> FindQt.cmake is deprecated for a reason
[16:04:13 CET] <BtbN> you use the Qt config files that come with Qt
[16:04:15 CET] <kurosu> JEEB: effort for something I have no need for yet
[16:04:34 CET] <JEEB> kurosu: well at the very least mark what the isuse with those project files is for you :P
[16:04:48 CET] <JEEB> fixing it yourself is one thing, but at least the possibility for improvement is noted
[16:07:38 CET] <kurosu> to be fair, j-b is more likely speaking about maintaining and building with A vs B, whereas I don't care about what's under the hood as a end user
[16:08:30 CET] <j-b> With VLC, we have more dependencies than most projects (around 120) and we ship VLC on more platforms than any other big project (more than Chrome, Firefox, libreoffice, or Adobe Reader)
[16:08:38 CET] <j-b> the conclusion is this one:
[16:09:07 CET] <j-b> "if a project does not use autotools or meson, (or at the limit Cmake), it will fail in a way or another"
[16:09:34 CET] <j-b> (including FFmpeg, of course, but live555, libvpx, zlib are horrible)
[16:09:35 CET] <kurosu> *ffail
[16:09:37 CET] <philipl> j-b: did anyone answer your libnpp question. It's an nvidia library distributed with the cuda sdk that provides high level calls to do various accelerated operations that are implemented with cuda underneath.
[16:10:02 CET] <j-b> philipl: ok.
[16:10:12 CET] <j-b> philipl: not open source?
[16:10:15 CET] <philipl> j-b: so unlike the filters directly written against cuda, you need the SDK for headers and libraries.
[16:10:18 CET] <philipl> right
[16:10:37 CET] <j-b> I would say that this is not fine, according to my opinion, then.
[16:10:40 CET] <philipl> There are two filters written against libpp today.
[16:10:59 CET] <j-b> philipl: and I started discussing with Brad, as I said the day before yesterday
[16:11:10 CET] <philipl> One of them is basically obsolete, (the scale filer, where we have a direct cuda one too)
[16:11:26 CET] <philipl> The other is a transpose filter that BtbN knows more about than me.
[16:11:41 CET] <philipl> I don't have a problem removing them if it helps us get to a consistent licence position.
[16:11:57 CET] <j-b> understood.
[16:12:07 CET] <BtbN> The libnpp scale filter is far from obsolete sadly
[16:12:12 CET] <philipl> :-(
[16:12:19 CET] <BtbN> it's the only filter that can do on-gpu format conversion
[16:12:24 CET] <nevcairiel> so improve the cuda filter =p
[16:12:40 CET] <BtbN> We basically need format_cuda
[16:12:49 CET] <BtbN> Which would be a huge mess to write
[16:12:51 CET] <philipl> yeah - that would be the replacement.
[16:13:09 CET] <BtbN> And scale_cuda is lacking some higher quality algorithms that npp has
[16:13:27 CET] <BtbN> Plus, npp is heavily used by a lot of people, removing it would cause serious upset
[16:13:54 CET] <BtbN> I got very unfriendly E-Mails already when the in-tree headers were removed.
[16:14:25 CET] <nevcairiel> tell them to go send money or shove it
[16:14:50 CET] <BtbN> The primary complaint was that nvenc was now no longer automagically enabled in various binary distro builds.
[16:15:49 CET] <j-b> the entitlement of some people is amazing
[16:17:48 CET] <j-b> JEEB: I should add my "drivers have a GPL exception" in my signature, wdyt?
[16:18:00 CET] <JEEB> :D
[16:18:13 CET] <j-b> philipl: I have a call with nVidia people next week. Do you have requests?
[16:18:16 CET] <j-b> BtbN: same ^^
[16:18:53 CET] <JEEB> RGB input officially supported since they already support 4:4:4 encoding
[16:19:08 CET] <BtbN> Pretty sure nvenc supports RGB input?
[16:19:26 CET] <JEEB> I think it was still limited to YCbCr
[16:19:30 CET] <JEEB> at least the FFmpeg wrapper
[16:19:37 CET] <philipl> j-b: Beyond their help with the licencing, I would like a way to use the official deinterlacer as a filter.
[16:19:52 CET] <philipl> JEEB: there are rgb0 and 0rgb input formats for nvenc.
[16:19:57 CET] <BtbN> The ffmpeg wrapper supports AV_PIX_FMT_0RGB32 and AV_PIX_FMT_0BGR32 inptu
[16:20:01 CET] <JEEB> huh
[16:20:10 CET] <JEEB> and it doesn't have to be planar?
[16:20:23 CET] <JEEB> I would have expected RGBP
[16:20:28 CET] <JEEB> GBRP I mean
[16:20:44 CET] <JEEB> just stuff it into the three planes and you get lossless RGB encoding :P
[16:21:03 CET] <BtbN> Pretty sure it runs a shader internally to convert it to YUV
[16:21:13 CET] <j-b> philipl: your goal is to get cuda_nvcc outside of non-free right? libnpp is less important, correct?
[16:21:14 CET] <JEEB> currently I have been doing it by feeding it GBRP planes as 4:4:4 YCbCr and then filtering the bit stream
[16:21:30 CET] <JEEB> so that the colorspace info in the output H.264 is RGB
[16:21:31 CET] <JEEB> vOv
[16:21:33 CET] <BtbN> j-b, I mean, I wouldn't mind a source code drop of libnpp, though I think that's highly unlikely.
[16:21:41 CET] <j-b> very.
[16:21:44 CET] <JEEB> BtbN: yea that's not RGB support - just RGB *input* support :P
[16:21:44 CET] <philipl> j-b: for me, that is correct. BtbN has just said by libnpp is important for other users.
[16:21:58 CET] <nevcairiel> if cuda stuff could be (L)GPL, then at least we could work towards making npp entirely obsolete and free in the process
[16:22:15 CET] <BtbN> indeed
[16:22:25 CET] <BtbN> Someone just needs to write the Kernels
[16:22:26 CET] <JEEB> they already have 4:4:4 YCbCr support so no real technical reason not to be able to do RGB at that point unless I'm missing something :P
[16:23:52 CET] <BtbN> It would cause confusion with the wrapper
[16:24:08 CET] <BtbN> How do you tell if it's stuffing RGB into the encoder itself, or converting to YUV?
[16:25:10 CET] <JEEB> planar vs packed?
[16:25:17 CET] <JEEB> but yes
[16:25:27 CET] <JEEB> if we already "support RGB" in the FFmpeg wrapper with the packed ones :P
[16:26:00 CET] <JEEB> I know why those magical conversions are there, but at times like these it becomes really derpy
[16:26:26 CET] <JEEB> I just don't want to keep on hacking the thing like that - getting RGB encoded for local capture is <3
[19:11:55 CET] <tmm1> i'm trying to track down some bugs in timestamp handling.. anyone have hunches as to what is happening here: https://gist.github.com/tmm1/1a0b04930c88b0a6f652e60ec73843c0
[19:12:44 CET] <JEEB> that's funky
[19:12:51 CET] <JEEB> see -debugts ?
[19:13:08 CET] <JEEB> that prints out the timestamps in different spots
[19:13:19 CET] <JEEB> also, -vsync passthrough might remove some ffmpeg.c logic
[19:13:23 CET] <JEEB> together with copyts
[19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:9664c3a4d40e: avcodec/mpegaudio_parser: Consume more than 0 bytes in case of the unsupported mp3adu case
[19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:86ba4473fa30: avcodec/mpeg4videodec: Clear partitioned frame in decode_studio_vop_header()
[19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:92382748e4ad: avcodec/cavsdec: Propagate error codes inside decode_mb_i()
[19:15:50 CET] <cone-509> ffmpeg 03Andreas Rheinhardt 07release/4.0:5bdc1e51fd3a: h264_redundant_pps: Fix logging context
[19:15:50 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:4b0d040e1837: avcodec/shorten: Fix integer overflow with offset
[19:15:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:dab6409d84a7: fftools/ffmpeg: Repair reinit_filter feature
[19:15:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:0e11b2983448: avcodec/pngdec: Check compression method
[19:15:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:040aa140748a: avcodec/truemotion2: fix integer overflows in tm2_low_chroma()
[19:15:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:773f58229ff0: avcodec/truemotion2rt: Fix rounding in input size check
[19:15:53 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ee20d64bec7e: avcodec/msmpeg4dec: Skip frame if its smaller than 1/8 of the minimal size
[19:15:54 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f3095068d85d: avcodec/wmv2dec: Skip I frame if its smaller than 1/8 of the minimal size
[19:15:55 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c3e263b862ec: avcodec/msvideo1: Check for too small dimensions
[19:15:56 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:7070de99c082: avcodec/ppc/hevcdsp: Fix build failures with powerpc-linux-gnu-gcc-4.8 with --disable-optimizations
[19:15:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ff8ba749b439: avcodec/dxv: Check that there is enough data to decompress
[19:15:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:50ee16431c56: avcodec/clearvideo: Check remaining input bits in P macro block loop
[19:15:59 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:5d9daae62b9c: lavf/mov: ensure only one tkhd per trak
[19:16:00 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b80d50441233: avformat/nutenc: Document trailer index assert better
[19:16:01 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:e02f55a3c5c3: lavf/id3v2: fail read_apic on EOF reading mimetype
[19:16:02 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:bd9525b4bf14: avcodec/mjpegdec: Fix indention of ljpeg_decode_yuv_scan()
[19:16:03 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:965eddc7ed0c: tests/fate/filter-video: increase fuzz for fate-filter-refcmp-psnr-rgb
[19:16:04 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:d0e900187c2d: avformat/mpegts: Fix side data type for stream id
[19:16:05 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b29b6afdfbbf: avcodec/avcodec: Document the data type for AV_PKT_DATA_MPEGTS_STREAM_ID
[19:16:06 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5161e1e61041: avcodec/rpza: Move frame allocation to a later point
[19:16:07 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:90d73a207c6a: avcodec/rpza: Check that there is enough data for all the blocks
[19:16:08 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:3006a5675c7b: postproc/postprocess_template: Avoid using %4 for the threshold compare
[19:16:09 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:33555963259c: postproc/postprocess_template: remove FF_REG_sp from clobber list
[19:16:11 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:67bc75d5b1bc: avcodec/fic: Fail on invalid slice size/off
[19:16:11 CET] <cone-509> ffmpeg 03gxw 07release/4.0:4dbfbcef1670: avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa
[19:16:12 CET] <cone-509> ffmpeg 03David Bryant 07release/4.0:cdf1dc136caa: avformat/wvdec: detect and error out on WavPack DSD files
[19:16:13 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:541b62796256: avcodec/mjpegbdec: Fix some misplaced {} and spaces
[19:16:15 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:472498ed473f: avcodec/v4l2_m2m: fix cant typo
[19:16:15 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ab0a8e477242: avformat/libopenmpt: Fix successfull typo
[19:16:17 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:96ef96f6ba8f: avcodec/4xm: Fix returned error codes
[19:16:17 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:6c2b4c716b1b: avcodec/exr: Check for duplicate channel index
[19:16:18 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:11e8ea4d0a85: avcodec/exr: set layer_match in all branches
[19:16:19 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5a9170345a29: avcodec/h264_slice: Fix integer overflow in implicit_weight_table()
[19:16:20 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:bf83eadbccbe: avcodec/tests/rangecoder: initialize array to avoid valgrind warning
[19:16:22 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:1e09bf4d1028: avcodec/diracdec: Check component quant
[19:16:22 CET] <cone-509> ffmpeg 03James Almer 07release/4.0:48ca78728afc: configure: bump year
[19:16:23 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63de02051d72: avutil/mem: Optimize fill32() by unrolling and using 64bit
[19:16:25 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f5c6d42124a4: avutil/imgutils: Optimize memset_bytes() by using av_memcpy_backptr()
[19:16:26 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:fcfa104b0e05: avcodec/tiff: Check for 12bit gray fax
[19:16:26 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c600c06af96e: avcodec/fic: Check that there is input left in fic_decode_block()
[19:16:27 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:636e66f35001: avformat/rtsp: Clear reply in every iteration in ff_rtsp_connect()
[19:16:28 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:a066fc25ca7a: avformat/rtsp: Check number of streams in sdp_parse_line()
[19:16:29 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:b9269c960cae: avcodec/pgssubdec: Check for duplicate display segments
[19:16:31 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:12a09ce97514: avformat/mov.c: require tfhd to begin parsing trun
[19:16:32 CET] <cone-509> ffmpeg 03chcunningham 07release/4.0:32017af5ef62: avformat/mov: validate chunk_count vs stsc_data
[19:16:33 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:d5a946615ffc: avcodec/sbrdsp_fixed.c: remove input value limit for sbr_sum_square_c()
[19:16:34 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5f799f0cee95: avformat/mov: Do not use reference stream in mov_read_sidx() if there is no reference stream
[19:16:34 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:8183623ca38c: avcodec/mpeg4videodec: Clear interlaced_dct for studio profile
[19:16:35 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:c50ba3cb6cec: avformat/matroskadec: Do not leak queued packets on sync errors
[19:16:36 CET] <cone-509> ffmpeg 03Kevin Backhouse via RT 07release/4.0:381fa4a29d38: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for tag scaning
[19:16:38 CET] <cone-509> ffmpeg 03Kevin Backhouse via RT 07release/4.0:7dc5c930354c: avcodec/htmlsubtitles: Fixes denial of service due to use of sscanf in inner loop for handling braces
[19:16:38 CET] <cone-509> ffmpeg 03Wenxiang Qian 07release/4.0:02518ba07fe6: avformat/ftp: Fix Out-of-Bounds Access and Information Leak in ftp.c:393
[19:16:40 CET] <cone-509> ffmpeg 03Wenxiang Qian 07release/4.0:4a9f11129697: avformat/http: Fix Out-of-Bounds access in process_line()
[19:16:41 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f1263f5c7d65: avformat/webmdashenc: Check id in adaption_sets
[19:16:42 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:5f52e2c420e0: avcodec/h264_direct: Fix overflow in POC comparission
[19:16:43 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ffaa3c3071ea: avcodec/jvdec: Check available input space before decode8x8()
[19:16:43 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:f32ce15f7c0b: avcodec/zmbv: obtain frame later
[19:16:44 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:80c881544410: avcodec/mlpdec: Insuffient typo
[19:16:45 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63957591e951: avcodec/error_resilience: Use a symmetric check for skipping MV estimation
[19:16:46 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:4ee463b69f30: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
[19:16:48 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:24e4039c6fa1: avcodec/bethsoftvideo: Check block_type
[19:16:48 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:87eecb7d8545: avcodec/gdv: Check for truncated tags in decompress_5()
[19:16:49 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:ccf6ca1701d8: avcodec/aic: Check remaining bits in aic_decode_coeffs()
[19:16:51 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:36a1939b59f0: avcodec/qpeg: Limit copy in qpeg_decode_intra() to the available bytes
[19:16:52 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:8f6d7a454a32: avcodec/scpr: Fix use of uninitialized variable
[19:16:53 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:63383dea3b16: avcodec/dxv: Correct integer overflow in get_opcodes()
[19:16:54 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:aadce82c5851: avcodec/mpeg4videodec: Check idx in mpeg4_decode_studio_block()
[19:16:55 CET] <cone-509> ffmpeg 03Guo, Yejun 07release/4.0:01209d220b36: configure: add missing pthreads extralibs dependency for libvpx-vp9
[19:16:56 CET] <cone-509> ffmpeg 03Guo, Yejun 07release/4.0:33651c09407e: configure: use vpx_codec_vp8_dx/cx for libvpx-vp8 checking
[19:16:57 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:1d77b60e3531: avformat/gdv: Check fps
[19:16:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:09b6cce9ba49: avcodec/cdgraphics: Use ff_set_dimensions()
[19:16:58 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:86af0e2a8732: avcodec/dvbsubdec: Check object position
[19:16:59 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:599cfce022b3: avcodec/clearvideo: Check remaining data in P frames
[19:17:00 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:2a2bc7918727: avcodec/dfa: Check the chunk header is not truncated
[19:17:02 CET] <cone-509> ffmpeg 03Michael Niedermayer 07release/4.0:162b44e110cb: Update for 4.0.4
[19:29:36 CET] <tmm1> hmm looks like maybe the value is changing during timebase conversion from 1/90k to 1001/30k
[20:31:38 CET] <cone-509> ffmpeg 03Lou Logan 07master:171f8ee40bd7: doc/mailing-list-faq: ffmpeg-devel is now subscription only
[20:38:29 CET] <cone-509> ffmpeg 03Lou Logan 07master:736617408622: MAINTAINERS: remove myself as mailing list maintainer
[20:45:46 CET] <tmm1> JEEB: vsync passthrough didn't change anything. i updated the gist with the debug_ts output, looks like coming out of the encoder is where the ts changes
[20:48:32 CET] <JEEB> alright
[20:59:35 CET] <tmm1> JEEB: figured it out, it is the timebase conversion. updated gist to show the math
[21:11:17 CET] <JEEB> hmm
[21:11:23 CET] <JEEB> if I have some code that outputs UCS-2
[21:11:34 CET] <JEEB> how simple is it to go from UCS-2 to UTF-8?
[21:15:40 CET] <atomnuker> apparently its compatible with utf-16 so same as utf-16 to utf-8
[21:19:32 CET] <JEEB> yea, now i'm just wondering if I should add iconv as a dep or make something up myself
[21:21:07 CET] <atomnuker> everyone has iconv, I think
[21:21:35 CET] <atomnuker> though everyone has zlib, and I've seen plenty of people complain lavu has no zlib
[21:21:47 CET] <JEEB> it just gets a bit corny because I effectively made a thing out of an iconv module that didn't go upstream :P
[21:21:56 CET] <JEEB> it even has a test which is nice
[22:09:07 CET] <uau> atomnuker: everyone has zlib installed, not everyone has zlib development headers installed
[23:14:00 CET] <thardin> got a little tour at one of the local broadcast shops, and a bit of an explanation what the hell ndi is
[23:15:46 CET] <thardin> partly a way to pipe video over ethernet as already surmised. but also the codec is idempotent, meaning if you decode it, pipe it over sdi and re-encode it on the other side then you get the same bits 
[23:16:03 CET] <thardin> and some metadata and control crap
[23:55:28 CET] <jdarnley_obs> Is that rfc4175 other than the "metadata and control crap"?
[23:58:08 CET] <jdarnley_obs> or maybe hbrmt?
[00:00:00 CET] --- Fri Mar 22 2019