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

[burek]

[00:00:29 CET] <JEEB> also most of all this really concerns me regarding the future because I do not know why this happened, and how I could make this stuff go through simpler. should I have said more clearly, earlier that I would like him to tell me specifically what was being required? I dunno
[00:02:26 CET] <BradleyS> i wouldn't blame yourself, especially since this is not a rare incident
[00:03:22 CET] <JEEB> and it's really weird since before I've posted quotes out of specs and he's thanked me for the check/review
[00:19:17 CET] <jkqxz> atomnuker:  I'm not sure that the visible responses there mean very much.  The only people who can actually push things are Intel.
[00:20:46 CET] <jkqxz> Though tbh I agree with the general position that the driver should be codec-only, and shouldn't include the WSI elements.  If a change in EGL and Wayland breaks the codec library, something is wrong.
[00:27:47 CET] <JEEB> michaelni: commented on the MPEG-TS subtitle case. that was one of the original alternatives I thought of, but since it was way too open ended I decided to not go for it.
[08:31:12 CET] <cone-663> ffmpeg 03Zhong Li 07master:978c935f2f65: lavc/qsv_hevc: correct QSV HEVC default plugin on Windows
[10:08:34 CET] <ubitux> note: display matrices may contain something else than a rotation; i have a case here where it's a vflip
[10:09:01 CET] <ubitux> (due to the classic GL thing)
[10:09:17 CET] <ubitux> with apple+mov
[11:42:52 CET] <durandal_1707> michaelni: i see no way too find which stream reached EOF with .interleave_packet
[11:56:47 CET] <michaelni> durandal_1707, the flush parameter would be set during trailer writing (and for one other case that would need to be distinguished). When flush is reached no more packets should get added into the buffers so the buffer content should work to indentify what is last.
[11:56:57 CET] <michaelni> maybe theres a easier way, i dont know
[11:59:06 CET] <michaelni> maybe st->last_in_packet_buffer can be used to simplify this
[12:03:49 CET] <cone-319> ffmpeg 03Shiyou Yin 07master:76952aa46163: avcodec/mips: [loongson] enable MSA optimization for loongson platform.
[12:24:15 CET] <JEEB> michaelni: I guess we have a difference in opinion regarding data that comes before PCR :) since in theory everything that comes before PCR is non-trustworthy :)
[12:24:29 CET] <JEEB> (in my opinion)
[12:25:40 CET] <durandal_1707> michaelni loves implementing hacks on top of hacks
[12:25:58 CET] <JEEB> I wouldn't say it that way
[12:26:22 CET] <JEEB> it's valid to want that result, but it's case of effort VS reward
[12:26:40 CET] <JEEB> (and then consider the actual format you're basing your logic on)
[12:35:31 CET] <michaelni> JEEB, if you prefer the simple solution iam fine with that too but i might (if i find time) rewrite it to do the buffering so the timestamps arent lost in the cases this affects
[12:38:33 CET] <JEEB> yea, that sounds good. I think we have some data structure for growing buffers
[12:50:40 CET] <JEEB> (although the real problem is in what sort of state are you going to start buffering? the full "pes" structure with buffer?)
[12:50:57 CET] <JEEB> (or just the AVPackets - for which you then have to start poking at some other points)
[12:52:19 CET] <JEEB> michaelni: also if you're interested in how f.ex. ffmpeg.c currently handles that sort of stuff, `ffmpeg -txt_format ass -fix_sub_duration -i https://kuroko.fushizen.eu/samples/2018-04-04-funky_teletext_mux.cut.ts -c:v libx264 -crf 21 -preset fast -c:a aac -b:a 192k -c:s ass out.mkv` for example is a good way to test :)
[12:52:22 CET] <nevcairiel> finished AVPackets with missing  timestamps seems like the most logical to me, unless you need a b unch of extra information to reconstruct the timestamp later, which cant be stored with it?
[12:53:18 CET] <JEEB> nevcairiel: also this reminds me I should throw at least one of your patches onto the ML from your fork :P
[12:54:22 CET] <JEEB> and compare that to what happens with the patch :)
[12:54:34 CET] <nevcairiel> one of the mpegts things?
[12:54:42 CET] <JEEB> I think it was some wrap-around hnadling thing
[12:54:47 CET] <JEEB> "skip teletext" or so
[12:54:52 CET] <JEEB> as in, don't use it as reference
[12:54:54 CET] <nevcairiel> oh that
[12:55:50 CET] <nevcairiel> it can probably be even more generic and dont use anything but audio/video for wraps, any other data can be rather spurious
[12:56:12 CET] <JEEB> yea
[12:57:47 CET] <JEEB> also talking of that
[12:57:53 CET] <JEEB> I have some Japanese patch which I don't get
[12:57:57 CET] <JEEB> but it helps with at least one sample
[12:58:03 CET] <JEEB> I might just throw that one out there as well
[12:59:02 CET] <JEEB> https://github.com/jeeb/ffmpeg/commit/dfeeeb226094a8b00f7319b89e4d3b3660326d35
[13:05:20 CET] <JEEB> a sample where that improves things was if I recall correctly http://kuroko.fushizen.eu/videos/pid_switch_sample.ts
[13:05:26 CET] <JEEB> https://kuroko.fushizen.eu/screenshots/ffmpeg/blue_vanilla-orange_patched.png
[13:05:33 CET] <JEEB> that's the timestamp values graphed
[13:06:29 CET] <durandal_1707> michaelni: the EOR packets injected into interleaver are of data size 0 ?
[13:06:40 CET] <nevcairiel> those pid change streams probably trip up all sorts of logic
[13:10:24 CET] <michaelni> durandal_1707, yes
[13:20:56 CET] <durandal_1707> michaelni: ffmpeg -f lavfi -i sine=d=3 -f lavfi -i sine=d=1 -f lavfi -i pal100bars=d=2 -map 0 -map 1 -map 2 -c:v rawvideo -c:a pcm_s16le t.nut  <<<<<-- with this one i receive flus too late
[13:21:56 CET] <durandal_1707> michaelni: *flush, this is all flawed design which can not be fixed in code
[14:18:54 CET] <cone-319> ffmpeg 03Michael Niedermayer 07master:568e1b229b85: avfilter/scene_sad: Fix funtions typos
[14:33:06 CET] <kwizart> Hi, I have a license question as I wanted to have a LGPL ffmpeg built with cuda, I fail to understand why it would not be redistributable ? is it because it would be a derrived work ? thx for any advices...
[14:33:40 CET] <JEEB> the enable-nonfree requirements in configure I think need to be better set. currently a lot of stuff is not nonfree if FFmpeg is configured as LGPL
[14:34:16 CET] <JEEB> which it seems like hearing opinions from j-b etc that that is not true, since then oyu are no longer able to abide by the LGPL and giving out the code for the LGPL dependency in full
[14:34:25 CET] <BtbN> cuda is one of the few cases which is not even lgpl compatible
[14:34:31 CET] <BtbN> primarily due to it needing nvcc to be built
[14:35:36 CET] <j-b> JEEB: hmm, difficult. LGPLv2 and v3 differ on that section
[14:36:24 CET] <JEEB> ok, so we definitely need to then refine the configure checks and possibly divide "nonfree" libraries into multiple groups
[14:36:38 CET] <JEEB> currently it's just dumb "if not GPL, nonfree is in various cases OK"
[14:36:42 CET] <JEEB> if not always
[14:38:02 CET] <BtbN> To build the CUDA filters you need nvcc which you can only get after registering with nvidia and accepting their EULA
[14:38:21 CET] <JEEB> esp. since we have some nonfree stuff that is closed source, and some that is open source but just incompatible with the GPL (which is I think what the enable-nonfree option was originally for)
[14:38:29 CET] <JEEB> which is why the check for GPL is incorporated there
[14:38:54 CET] <kwizart> BtbN, I don't think there is any issue to compile GPL(or LGPL) code with a close source compiler (maybe I'm wrong and that's the point) or it would not be possible to build any GPL/LGPL code with windows compiler or solaris one etc...
[14:39:15 CET] <BtbN> It wouldn't be a problem if there was an alternative
[14:39:37 CET] <BtbN> But as it is right now, it's impossible to reproduce the build without getting nvcc from nvidia in the way described.
[14:39:45 CET] <BtbN> And that very much is incompatible with both GPL and LGPL
[14:42:11 CET] <BtbN> Some cuda filters, like the npp stuff, also needs an external closed source library which is not part of the driver, so does not fall under the system lib clause
[14:43:40 CET] <j-b> JEEB: nonfree means not distributable. GPL or LGPL.
[14:43:48 CET] <j-b> They have similar requirements.
[14:44:32 CET] <j-b> kwizart: sorry, but I don't think that works.
[14:44:37 CET] <JEEB> yes, but it is IMHO harder to repro the code for an LGPL build with not open source deps?
[14:45:33 CET] <BtbN> As long as the closed source deps are freely available to everyone without accepting weird EULAs, it seems fine
[14:46:14 CET] <kwizart> j-b, nonfree (as in the ffmpeg's configure) it totally unclear. One can has floss code but with incompatible license, that will also be non-redistributable (such as BSD with advertising with GPL)
[14:46:59 CET] <durandal_1707> michaelni: what you want to do with EOR subtitle packets? and what with rest EOR packets? drop them?
[14:46:59 CET] <BtbN> There are some edge-cases with stuff like that, yes. But for nvidia they are very very far of any edge. It's as nonfree as it gets.
[14:47:04 CET] <j-b> BtbN: no, you need to also provide the relinking steps for this binary.
[14:47:13 CET] <j-b> So, for Cuda, it would be fine if you:
[14:47:21 CET] <j-b> - build the libray as a .so
[14:47:33 CET] <j-b> - give the .o of the cuda part, for other people to relink.
[14:48:13 CET] <BtbN> j-b, all our CUDA code is open, and the parts from nvidia are MIT licensed. The only thing holding it deep in nonfree is it needing nvcc to build the CUDA kernels, which are themselves also available as LGPL
[14:48:27 CET] <kwizart> I think one can reproduce the build with cuda, it's just a matter to accept the specific EULA
[14:48:40 CET] <j-b> ah, ok.
[14:48:52 CET] <BtbN> kwizart, you cannot without registering with nvidia to get nvcc, which requires you to accept two separate EULAs
[14:49:06 CET] <BtbN> sorry, but I fail to see how this is not incompatible with the requirements of the (L)GPL
[14:49:13 CET] <bencoh> k/63
[14:49:24 CET] <j-b> this is clearly incompatible with LGPLv3
[14:49:32 CET] <j-b> where you need to actually be able to rebuild
[14:49:42 CET] <j-b> For v2, this is debatable
[14:50:03 CET] <j-b> depending if nvcc adds some code or not, and if that code is RE-able.
[14:50:20 CET] <j-b> (See section 6 of the LGPLv2.1)
[14:51:31 CET] <kwizart> j-b, I don't think one can rebuild say libreoffice (that using the ms compiler) without accepting the ms EULA (both msvc and os)
[14:51:33 CET] <j-b> Because if it adds some code, and that code is not allowed to be RE-able, then, you cannot comply with LGPL, IIRC
[14:52:13 CET] <j-b> kwizart: libreoffice is compilable with gcc and llvm
[14:52:15 CET] <kwizart> but again, been abble to reproduce doesn't say without giving money (in this case)
[14:55:16 CET] <j-b> I wish nVidia was more reasonable
[14:57:12 CET] <michaelni> durandal_1707, in the demuxer ? yes, if EOR was created by the muxer the demuxer would drop it and only use it internally for seeking/duration
[14:58:01 CET] <BtbN> j-b, nvcc converts .cu (which is basically normal C/C++) to a ptx file, which is then baked into libavfilter as a string, which is passed to the CUDA runtime to run on the GPU
[14:58:40 CET] <j-b> BtbN: sure, but is the ptx file just the .cu converted or does it add more code?
[14:58:44 CET] <BtbN> It has an extensive standard library to do so which is also understood by the GPU. clang has some attempts to replicate it, but it's far from trivial and unusable in its current statew
[14:59:28 CET] <j-b> is that standard library RE-able?
[15:00:06 CET] <BtbN> No idea, never looked into it that deep
[15:00:24 CET] <BtbN> But it's definitely under their EULA, which forbids RE
[15:01:21 CET] <j-b> Then, I believe this is not LGPL compliant.
[16:14:03 CET] <philipl> there is some statically linked standard library that comes into play when building the ptx.
[16:14:32 CET] <philipl> that's why trying to build a ptx with clang still requires the cuda sdk
[16:15:05 CET] <philipl> or rather, trying to build the cu source.
[16:15:42 CET] <philipl> it may be possible to write something that can compile to ptx without the cuda sdk but it requires giving up a bunch of stuff.
[18:01:16 CET] <cone-873> ffmpeg 03Carl Eugen Hoyos 07master:06a436a224c0: lavc/mjpegdec: Interpret three-component Adobe transform 0 also as RGB.
[19:02:33 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:62dbcb7ddf10: avcodec/g723_1: add support for stereo files
[19:02:34 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:7a124138a719: avcodec/g723_1dec: reindent after last commit
[19:02:35 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:d283ee085f9a: avcodec/g723_1dec: improve stereo support
[19:09:20 CET] <durandal_1707> CCCCCCCCCCCCCCCAAAAAAAAAAAAAAAAAAAARRRRRRRRRRRRRRRRRRRRRRRRRLLLLLLLLLLLLLL!!!!!!!!!
[19:17:03 CET] <jamrial> JEEB: stop replying to that thread
[19:17:26 CET] <jamrial> you'll get nothing out of it but another day of stress
[19:17:53 CET] <JEEB> I still hang onto the thread of hope that we can improve this community
[19:18:43 CET] <JEEB> but yes, it is quite possible that there will only be short reponses without real meaning other than noting that I am incorrect
[19:18:52 CET] <jamrial> we can, but that thread is a lost cause. just look at his replies.
[19:19:02 CET] <jamrial> and yes, that's what i mean
[19:51:14 CET] <cone-873> ffmpeg 03Paul B Mahol 07master:c0fb6f963fd7: avformat/vorbiscomment: add support for writing chapters
[19:55:49 CET] <JEEB> michaelni: did you have something against this btw?
[19:55:51 CET] <JEEB> https://patchwork.ffmpeg.org/patch/10583/
[19:56:29 CET] <JEEB> because I think it's pretty important for the user to know if there's been discontinuities which ffmpeg.c has to handle?
[19:57:31 CET] <JEEB> relevant issue from which these patches came was an example of the ffmpeg.c logic not doing the correct thing https://trac.ffmpeg.org/ticket/7482
[20:06:47 CET] <cone-873> ffmpeg 03Jan Ekström 07master:3a36b0c4b8f2: ffmpeg: improve the intra stream discontinuity message
[20:17:53 CET] <michaelni> JEEB, i have no oppinion because i dont know how many warnings this would cause in practice. Also iam not sure warning is the best level 
[20:18:42 CET] <JEEB> for a live stream it would start appearing after lavf handles the first wrao-around, once per each 26h or so
[20:19:00 CET] <JEEB> the sample in the ticket will get it a lot
[20:19:17 CET] <JEEB> also no idea if warning is the right level, but if it starts spamming it's a clear sign that something's wrong
[20:19:21 CET] <JEEB> and it being under debug
[20:19:26 CET] <JEEB> will not make it visible to anyone
[20:19:34 CET] <JEEB> esp. since IIRC we cannot control verbosity per-module
[20:19:44 CET] <JEEB> so if you do -v debug
[20:19:50 CET] <JEEB> you will get a lot of stuff
[20:20:13 CET] <JEEB> info would be OK as well, but I definitely would make it visible by default
[20:20:34 CET] <JEEB> if it gets hit often it seems like it most likely is hiding a problem somewhere
[20:20:39 CET] <JEEB> or causing one
[20:21:55 CET] <JEEB> I hope this makes sense
[20:50:45 CET] <durandal_1707> michaelni: is latest nut patch ok now! (i will update fate before pushing)
[00:00:00 CET] --- Wed Dec 19 2018