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

[burek]

[00:06:19 CET] <Zeranoe> j-b: is that a trick question so I get nailed for distributing?
[00:06:35 CET] <j-b> Zeranoe: lol
[00:07:01 CET] <j-b> Zeranoe: sharing a link is not distributing, you know that, right?
[00:10:00 CET] <Zeranoe> I jest, but are you looking to analyze it something? It just installs with the SDK into NewTek NDI 3.7 SDK\Bin\x86\ffmpeg 
[00:10:29 CET] <JEEB> just having the binary is enough
[00:10:44 CET] <j-b> Zeranoe: yes, to see what x264 version is used.
[00:12:52 CET] <Zeranoe> Is there somewhere you'd like me to put it? I don't want it on my site.
[00:13:51 CET] <JEEB> the original URL for the download is OK, too
[00:13:53 CET] <JEEB> if it still works
[00:14:22 CET] <j-b> Zeranoe: it's more for archiving, before people remove it.
[00:18:57 CET] <Zeranoe> They use a short URL for downloading the SDK: http://new.tk/NDISDK The 3.7 one brought me here: http://514f211588de67e4fdcf-437b8dd50f60b69cf0974b538e50585b.r63.cf1.rackcdn.com/Utilities/SDK/NDI_SDK_v2/NewTek%20NDI%203.7%20SDK.exe
[00:19:09 CET] <j-b> Zeranoe: thx
[00:19:26 CET] <j-b> good.
[00:19:46 CET] <j-b> that one is better, because no agreement needed
[00:20:23 CET] <Zeranoe> j-b: Yeah, they make you enter an email to get the link.
[00:21:46 CET] <Zeranoe> Though, as far as I can tell I'm not agreeing to anything, either in the form or by clicking links in the email. I think they just want to get you on a mailing list
[00:21:56 CET] <j-b> ok
[00:22:11 CET] <j-b> It's easy also to extract the binary, without agreeing to the license
[00:22:44 CET] <j-b> libx264-144.dll
[00:22:52 CET] <j-b> thanks.
[00:23:50 CET] <BtbN> The Download-Signup-Thing also doesn't work in Firefox
[00:23:54 CET] <BtbN> Had to fire up Chrome
[00:25:24 CET] <j-b> Zeranoe: does your build dlopen x264?
[00:25:47 CET] <BtbN> Does ffmpeg even support that?
[00:26:30 CET] <j-b> probably not.
[00:26:35 CET] <j-b> i686-w64-mingw32-objdump -x ffmpeg.exe| grep dll
[00:26:40 CET] <j-b> DLL Name: libx264-144.dll
[00:27:43 CET] <nevcairiel> that sounds like its just a linker entry
[00:28:49 CET] <nevcairiel> or if its build with msvc, they could technically enable delay loading just by passing compiler flags
[00:29:13 CET] <BtbN> It's MSVC. And I think gcc can do that too
[00:29:16 CET] <j-b> nevcairiel: oh really? interesting.
[00:29:25 CET] <nevcairiel> its really not a compiler feature as such
[00:29:30 CET] <j-b> -DX264_API_IMPORTS
[00:29:56 CET] <BtbN> Some tool just automatically builds a static shim lib that delay load on first function use
[00:30:09 CET] <BtbN> forgot which one it was
[00:30:22 CET] <nevcairiel> yeah i found various tools that do that for linux etc
[00:30:35 CET] <j-b> yeah, no.
[00:30:37 CET] <nevcairiel> microsoft has that as a standard feature for years now
[00:30:47 CET] <j-b> without libx264-144.dll, it does not run at all.
[00:30:57 CET] <nevcairiel> yeah then its just linked
[00:31:02 CET] <j-b> yup
[00:31:08 CET] <j-b> So, they ship x264 too.
[00:31:17 CET] <nevcairiel> does that really matter license wise?
[00:31:23 CET] <nevcairiel> if i dlopen a dll, its suddenly gpl-ok?
[00:31:33 CET] <BtbN> If you don't ship said dll, yes
[00:32:29 CET] <JEEB> you might make a case of it if you don't ship it, and the thing clearly wasn't made to be used just with it (or whatever the actual definition of 'derivative work' was)
[00:32:47 CET] <JEEB> even if you totally don't distribute libxyz, if the thing clearly needs it to work properly
[00:33:18 CET] <j-b> nevcairiel: it depends.
[00:33:33 CET] <j-b> BtbN: not always, no.
[00:34:07 CET] <j-b> If your software works without the GPL module, and has just "reduced functionality", then it's harder to argue
[00:34:19 CET] <j-b> Think of gstreamer GPL modules or dshow plugin.
[00:34:51 CET] <j-b> If it does not work, whatever they way, dlopening, linking, soft-linking, activex, delayed-linking, you are a derivative.
[00:34:59 CET] <JEEB> yea
[00:52:19 CET] <haasn> ^ SVP pretty blatantly violates the GPL of MVTools
[00:52:41 CET] <haasn> it absolutely cannot function without being "conveniently" paired up with the open source components of MVTools at runtime by friendly avisynth
[00:52:45 CET] <j-b> I am not a huge fan of SVP
[00:52:54 CET] <haasn> the author of MVTools knows about this
[00:52:58 CET] <haasn> but it's russian so
[00:53:01 CET] <j-b> (understatement of the year)
[00:54:08 CET] <j-b> anyway, this was good trolling, thanks NewTek
[01:10:19 CET] <Zeranoe> How is it decided if it stays or is removed?
[03:05:47 CET] <cone-293> ffmpeg 03Lauri Kasanen 07master:78c7ff7d250f: swscale/ppc: Move VSX-using code to its own file
[06:11:52 CET] <cone-527> ffmpeg 03Andrey Semashev 07master:f176d6587bcf: lavf/dashenc: Write media trailers when DASH trailer is written.
[08:15:07 CET] <JEEB> any comments on the dolby vision identifier patch set?
[12:10:15 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:8bd791969960: doc: chromaprint
[13:38:02 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:aae7e009b3a9: doc: libgme
[15:19:25 CET] <cone-756> ffmpeg 03Martin Vignali 07master:e53901ba5ec3: avcodec/utils : add ff_int_from_list_or_default func
[15:19:26 CET] <cone-756> ffmpeg 03Martin Vignali 07master:4141d45ae385: avcodec/prores_aw : add vendor option
[15:19:27 CET] <cone-756> ffmpeg 03Martin Vignali 07master:bbbbf237597e: avcodec/prores_aw : only set color prim, trc, space values if supported
[15:19:28 CET] <cone-756> ffmpeg 03Martin Vignali 07master:1edaf601f3a2: avcodec/prores_aw : add 4444 xq support
[15:46:02 CET] <cone-756> ffmpeg 03Gyan Doshi 07master:ea68e02c6d4f: doc: remove licensing claims for chromaprint and libgme
[18:01:21 CET] <durandal_1707> what bug/feature to do now?
[18:15:20 CET] <kierank> durandal_1707: fix carl
[18:17:17 CET] <atomnuker> lossless jpeg transpose bsf
[19:17:37 CET] <kurosu> transpose/rotate 90,180,270/crop
[19:29:25 CET] <LigH> Hi.
[19:32:08 CET] <LigH> JVET VVC just got ready to be built with MSYS/MinGW too ... so I guess it is not yet in a stage to be considered to be linked into ffmpeg. What would be your criteria to consider this encoder? How would we get to know that you start considering it? Looking for a thread in the mailing list?
[19:33:21 CET] <kurosu> please don't do that
[19:34:09 CET] <kurosu> let's not have hundreds of versions producing incompatible bitstreams
[19:34:24 CET] <BBB> I don't tihnk we've ever linked to models
[19:34:33 CET] <kurosu> we already had various versions of hevc's hm, that's enough, thanks.gif
[19:34:49 CET] <BBB> youcan use  ffmpeg -f rawvideo - | .. to use ffmpeg for decoding and input into vvc software for encoding
[19:34:54 CET] <LigH> Aha ... so you will wait for a final bitstream to be announced. Okay.
[19:35:03 CET] <LigH> That was my point.
[19:35:18 CET] <LigH> No hurry. Just curiosity.
[19:35:57 CET] <LigH> With a codec at this complexity, I can imagine to wait rather years than months...
[19:36:33 CET] <kurosu> at the very least, don't make producing "invalid" bitstreams so easy that we'll have tickets requesting to support them
[19:37:08 CET] <LigH> I remember just a recent case of "final" bitstreams being announced ahead of time. Was it for AV1? :D
[19:37:26 CET] <durandal_1707> joke
[19:37:32 CET] <LigH> OK, thank you.
[19:37:50 CET] <LigH> Bye
[19:38:34 CET] <nevcairiel> honestly people should really not care about VVC at this point at all
[19:40:46 CET] <jamrial> i'd very much rather people actually started caring about hevc instead, and contributed to ffhevc
[19:41:40 CET] <kurosu> need more $
[19:42:25 CET] <kurosu> at this point, h/w decoders are such ubiquituous that almost nobody is interested in that, same for vc1 and vp9 in a way
[19:42:32 CET] <kurosu> s/such/so
[19:44:17 CET] <jamrial> ffvp9 was done and fully optimized before hw hit the market
[19:44:30 CET] <jamrial> so it doesn't matter if nobody cares about software vp9 right now
[20:09:00 CET] <durandal_1707> atomnuker: when you gonna finish non-power of 2 dct/fft ?
[20:16:51 CET] <JEEB> some comments on the dolby hevc/avc identifiers used with dolby lolvision?
[21:08:34 CET] <cone-162> ffmpeg 03Paul B Mahol 07master:ed5680f37ed3: avcodec/dpx: add support for 10bit gray
[23:08:08 CET] <BtbN> nvidia claims their turing encoder narrowly beats x264 fast on Turing, comparing PSNR.
[23:08:48 CET] <atomnuker> lol
[23:10:22 CET] <nevcairiel> that might as well be true
[23:10:25 CET] <nevcairiel> just not very meaningful
[23:28:35 CET] <philipl> "We can achieve potato quality the fastest"
[23:29:39 CET] <nevcairiel> the quality is really not that bad anymore
[23:29:45 CET] <nevcairiel> definitely improved over prev gens
[23:29:51 CET] <philipl> This is true.
[23:29:55 CET] <nevcairiel> just that PSNR is a  bad metric
[23:30:00 CET] <nevcairiel> but popular nevertheless, unfortunately
[23:31:20 CET] <nevcairiel> i've been wanting a new streaming GPU for my media server, I wonder when they'll actually have low-end GPUs with the new media chip
[23:31:53 CET] <philipl> Define low-end? The low end pascal had no encode support - only decode. So not much use.
[23:31:56 CET] <nevcairiel> as an alternative I could possibly rebuild the server with a Ryzen or so to get higher x264 profile support
[23:32:09 CET] <philipl> So it was a 1050 at the minimum if you wanted to transcode.
[23:32:15 CET] <nevcairiel> that would be fine
[23:33:21 CET] <philipl> Based on past behaviour, I'd expect the better part of a year before we see low end parts.
[23:33:46 CET] <philipl> Perhaps it's even more complicated for them now, given that low end parts won't do ray-tracing so how will they brand them?
[23:33:56 CET] <nevcairiel> just use GTX again
[23:35:39 CET] <nevcairiel> but rebuilding with ryzen would probably be wasted, so probably just wait for a low-end gpu
[23:35:52 CET] <nevcairiel> it'll just inherit my current cpu when I rebuild this one in 2020 or so  =p
[23:36:05 CET] <nevcairiel> whenever icelake vs zen2 are out and about
[23:43:37 CET] <BtbN> Something that's not 600¬+
[23:44:02 CET] <BtbN> I also want to get rid of my first gen Ryzen platform. Way too many issues
[23:44:25 CET] <BtbN> All but the CPU driven PCIe slots are virtually unusable
[23:44:33 CET] <BtbN> The USB controler is a nightmare
[23:44:57 CET] <BtbN> It takes 3 to 5 attempts to power on.
[23:45:08 CET] <BtbN> "RAM training"
[23:46:29 CET] <Sesse> hi. :-) I'm trying to ship MJPEG around with nonstandard chroma (left location instead of center, rec. 709 coefficients instead of 601). I've set it correctly in the mux, but mjpegdec.c just overrides it unconditionally. would a patch that only overrode it if the mux didn't specify it (ie., AVCOL_SPC_UNSPECIFIED etc.) be accepted?
[23:47:09 CET] <thardin> probably
[23:47:17 CET] <thardin> does it pass FATE?
[23:47:26 CET] <Sesse> haven't tried, I'm not sure if I have any way of running FATE tests myself
[23:47:29 CET] <Sesse> (never tried it)
[23:47:41 CET] <Sesse> I haven't written the patch yet either, I'm trying to get a feel for what my options are
[23:47:55 CET] <thardin> you set SAMPLES=some_path then make fate-rsync then make fate
[23:47:56 CET] <Sesse> there's the CS=ITU601 hack, but it only specifies TV range, nothing else
[23:47:59 CET] <thardin> I think
[23:49:17 CET] <thardin> it seems you have the right idea though. maybe someone in here has a different opinion
[23:49:48 CET] <Sesse> I guess the counterargument would be that this is so obscure that it's better to just always override
[23:50:01 CET] <thardin> maybe. or add an option for it
[23:50:05 CET] <thardin> or maintain your own fork
[23:50:20 CET] <Sesse> the latter is not really going to fly
[23:50:37 CET] <Sesse> I could probably set some private option in the stream, though
[23:50:38 CET] <thardin> the way to find out is send a patch in and see if it passes muster :)
[23:50:41 CET] <Sesse> :-)
[23:50:59 CET] <Sesse> interestingly enough, the mux options are not probed if I set the nobuffer flag
[23:51:13 CET] <Sesse> which is a bit odd, but I also really can't find out exactly how much buffering there is without nobuffer
[23:51:20 CET] <Sesse> it appears to be mainly related to initial probing
[23:52:02 CET] <thardin> there's plenty of weirdness in lavf
[23:52:32 CET] <thardin> a few years ago I used to harp on how awful it is
[23:54:52 CET] <Sesse> the documentation just says something like turn off the optional buffering
[23:54:55 CET] <Sesse> :-)
[23:55:06 CET] <jkqxz> I don't think there is a way to pass the colour information in from a demuxer at all?  I suspect the easiest answer is to just overwrite the field when it comes out of the decoder.
[23:55:38 CET] <Sesse> jkqxz: I'm not sure how to interpret your first sentence, isn't the field set when the decoder runs?
[23:56:58 CET] <Sesse> e.g., dnxhd_decode_init has 
[23:56:59 CET] <Sesse>     if (avctx->colorspace == AVCOL_SPC_UNSPECIFIED) {
[23:56:59 CET] <Sesse>         avctx->colorspace = AVCOL_SPC_BT709;
[23:56:59 CET] <Sesse>     }
[23:57:04 CET] <jkqxz> Yes, the fields are only set by the decoder from the stream it can see.  If you have anything from a demuxer then I think you need to apply that separately afterwards.
[23:57:16 CET] <Sesse> hm, if so, dnxhd is broken
[23:57:34 CET] <thardin> isn't it that demuxers guess, but the real truth is in the decoders?
[23:57:45 CET] <thardin> oftentimes it's multiple points of truth
[23:57:54 CET] <Sesse> yes, some demuxers can set some of this information
[23:57:55 CET] <thardin> and the real truth is in the essence
[23:58:04 CET] <Sesse> annoyingly, only matroska seems to really have the full set here
[23:58:08 CET] <Sesse> ie., with chroma location and all
[23:58:09 CET] <thardin> unless you have customer specific things
[23:58:10 CET] <jkqxz> Those fields are all documented as "* - decoding: Set by libavcodec".
[23:58:25 CET] <Sesse> interesting
[23:58:35 CET] <Sesse> well, compiling now, so we'll see what actually happens in practice, I guess
[23:59:00 CET] <jkqxz> That code in dnxhd seems like the condition wouldn't do anything, since the default is UNSPECIFIED anyway?
[23:59:16 CET] <Sesse> jkqxz: unless the demuxer already set it?
[00:00:00 CET] <jkqxz> Hmm.  That doesn't seem to be allowed, but maybe it happens to work anyway for some decoders.  Yuck.
[00:00:00 CET] --- Wed Dec  5 2018