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

[burek]

[00:44:14 CEST] <cone-842> ffmpeg 03Carl Eugen Hoyos 07master:c3aa4844f393: lavfi/fspp: Remove two unused macros.
[02:03:05 CEST] <cehoyos> JEEB: Please push if the patch is ok.
[02:52:23 CEST] <cone-842> ffmpeg 03fumoboy007 07master:036b4b0f8593: avcodec/videotoolbox: add support for 10bit pixel format
[05:25:08 CEST] <unlord> I'm sure you all saw https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_currently_crashes_64bit/
[08:37:19 CEST] <JEEB> unlord: interesting if only 32bit is borked and not from libaom's side. funny enough when I used avisynth more getting the extra speed from 64bit encoding was worth it so I would utilize avs2pipe and friends to get the video data into a 64bit encoder process :)
[11:40:16 CEST] <nevcairiel> I really don't see how that could be our crash
[11:40:39 CEST] <nevcairiel> It reads like all of those people use some pre-built third-party binary
[11:40:52 CEST] <cehoyos> which crash?
[11:40:58 CEST] <nevcairiel> so  presumably what really changed is the libaom version
[11:41:12 CEST] <nevcairiel> https://www.reddit.com/r/AV1/comments/bdmk6h/32bit_ffmpeg_and_libaom_currently_crashes_64bit/ https://trac.ffmpeg.org/ticket/7844
[11:41:33 CEST] <cehoyos> You could build locally and test...
[11:42:01 CEST] <nevcairiel> I could, but that would go against my prime directive of being lazy!
[11:42:51 CEST] <nevcairiel> mostly because i dont have libaom handy anyway
[11:46:58 CEST] <cehoyos> There is no repo?
[11:47:00 CEST] <cehoyos> ;-)
[12:06:23 CEST] <nevcairiel> crashes in some simd function in libaom, so unless they changed their padding or alignment requirements without a major bump and didn't tell anyone, its likely their bug
[12:15:20 CEST] <JEEB> nevcairiel: it's probably zeraenoe's binaries
[12:16:17 CEST] <nevcairiel> crashes in my build as well
[12:17:27 CEST] <JEEB> yea, that's how you were able to get the SIMD function
[12:17:54 CEST] <nevcairiel> i just dont see how any change in ffmpeg might've caused this to start
[12:18:04 CEST] <nevcairiel> especially between 4.1.0 and 4.1.1 as is claimed
[12:18:04 CEST] <JEEB> yea
[12:19:41 CEST] Action: JEEB just started getting angry comments about FFmpeg sucking with regards to SVT-AV1 and AOM crashes too, for some reason
[12:19:48 CEST] <JEEB> I guess AV1 is popular today? :P
[12:20:10 CEST] <JEEB> and getting more information from these people isn't exactly the simplest of things always
[12:20:30 CEST] <nevcairiel> of course
[12:20:37 CEST] <nevcairiel> oh well back to writing this config parser
[12:20:48 CEST] <nevcairiel> i'm still wondering if i should bother to l earn some parser generator or just do it manually
[12:27:45 CEST] <j-b> config parser?
[12:29:15 CEST] <nevcairiel> basically an advanced ini file
[12:29:45 CEST] <cone-857> ffmpeg 03Karthick J 07master:bcde9ec02056: avformat/dashenc: Disable streaming for webm output
[12:30:37 CEST] <nevcairiel> meh i'll just do it manually, it only has like 5 syntax elements
[12:59:13 CEST] <cehoyos> How do I build 32-bit libaom?
[12:59:45 CEST] <cehoyos> JEEB: Is there a reason you did not push 2/2?
[13:05:06 CEST] <JEEB> cehoyos: still needs a bump I think
[13:05:15 CEST] <JEEB> and I was going to talk with the author
[13:07:41 CEST] <cehoyos> A bump?
[13:07:41 CEST] <JEEB> also it was late and I hadn't looked as much into the second patch :P
[13:07:47 CEST] <JEEB> cehoyos: it adds a new av_* function
[13:07:56 CEST] <cehoyos> Of course.
[13:07:57 CEST] <JEEB> as far as I can see
[13:07:59 CEST] <JEEB> :/
[13:08:05 CEST] <cehoyos> (In that case, I mean)
[13:08:09 CEST] <JEEB> yea
[13:08:30 CEST] <cehoyos> To answer my question: cmake -DCMAKE_CXX_FLAGS=-m32 -DCMAKE_C_FLAGS=-m32 ../aom
[13:08:46 CEST] <JEEB> yes, with multiarch that should work :)
[13:09:02 CEST] <JEEB> otherwise you have to either define a lot of stuff or a full cross-file
[13:09:18 CEST] Action: JEEB kind of dislikes build systems with cross-files because mostly you just need --cross-prefix or something like it
[13:09:37 CEST] <JEEB> of course if you need to override more stuff a separate file does start making sense
[13:09:49 CEST] <nevcairiel>  yeah the cross-file concept is weird, rather stick to cross-prefix, thats how most stuff works anyway
[13:10:01 CEST] <cehoyos> I do not consider compiling x86_32 Linux on x86_64 Linux cross-compiling.
[13:10:14 CEST] <JEEB> well yes, esp. with multiarch
[13:10:32 CEST] <JEEB> I think my comments were more towards general cross-compilation with cmake/meson
[13:10:45 CEST] <cehoyos> I still hope I can avoid this.
[13:10:52 CEST] <cehoyos> (I won't test on Windows)
[14:02:13 CEST] <cehoyos> Has anybody ever installed libmfx?
[14:02:33 CEST] <cehoyos> FFmpeg and the github source disagree about the header location: I just wonder why this was never reported...
[14:03:59 CEST] <BtbN> You are supposed to use mfx_dispatch
[14:04:11 CEST] <cehoyos> And have you tried it?
[14:04:19 CEST] <BtbN> On Windows on Cygwin, yes. Worked fine.
[14:04:39 CEST] <cehoyos> Where did it install the header files?
[14:04:50 CEST] <BtbN> No idea anymore
[14:05:19 CEST] <cehoyos> The reason I ask is that the header files cannot be found by FFmpeg where the installer puts them.
[14:05:30 CEST] <BtbN> Looking at the Makefile.am, they'd end up in /usr/include/mfx/*.h
[14:05:54 CEST] <cehoyos> They ended up in /usr/include here
[14:05:57 CEST] <cehoyos> (No mfx)
[14:06:18 CEST] <BtbN> When you installed https://github.com/lu-zero/mfx_dispatch via autotools?
[14:06:30 CEST] <cehoyos> via autotools?
[14:06:38 CEST] <cehoyos> How do I install via autotools?
[14:06:42 CEST] <cehoyos> Aaaaaaaaaaa
[14:06:47 CEST] <BtbN> Yeah, it also supported cmake, which I didn't test
[14:07:03 CEST] <cehoyos> The cmake is just for deception, well it hit me;-))
[14:07:20 CEST] <cehoyos> But that's really smart, I couldn't guess!
[14:07:37 CEST] <nevcairiel> the cmake is vastly out of date
[14:08:43 CEST] <nevcairiel> Personally on Windows I use the official intel variant though, since they fixed a bunch of stuff related to their new driver versions and finding the runtime libraries
[14:09:00 CEST] <cehoyos> As said, this is a smart deception, not something that can be immediately understood
[14:09:23 CEST] <BtbN> cmake and autotools supposedly both work (and haven't been touched in years)
[14:09:37 CEST] <cehoyos> I don't think that is true
[14:09:49 CEST] <nevcairiel> cmake doesnt work properly
[14:10:11 CEST] <nevcairiel> at least the .pc.cmake is wrong in some ways
[14:10:44 CEST] <nevcairiel> i had to deal with that only weeks ago
[14:10:52 CEST] <nevcairiel> when i tried to figure out why the new drivers didnt work anymore
[14:10:58 CEST] <nevcairiel> and ended up building with t he official one instead
[14:11:31 CEST] <nevcairiel> i tried to copy its cmake thing to the official one so i could build  it with gcc, so i noticed it needed some work =p
[14:15:01 CEST] <cehoyos> Why is mfx not auto-detected?
[14:22:10 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:1e8475b507ee: lavc/libaomenc: Mark a potentially unused variable as av_unused.
[14:29:39 CEST] <cone-857> ffmpeg 03Carl Eugen Hoyos 07master:5ba769214f91: lavu/hwcontext_qsv: Mark a pointer as const.
[14:32:10 CEST] <thardin> libmxf or libMXF ?
[14:32:19 CEST] <nevcairiel> the intel one
[14:32:25 CEST] <nevcairiel> mfx
[14:36:04 CEST] <thardin> oh joy, another library called exactly "libmxf"
[14:36:14 CEST] <JEEB> yea
[14:36:15 CEST] <JEEB> :/
[14:36:19 CEST] <JEEB> unfortunate
[14:37:00 CEST] <nevcairiel> mfx
[14:37:04 CEST] Last message repeated 1 time(s).
[14:37:04 CEST] <nevcairiel> :P
[14:37:30 CEST] <nevcairiel> its a different order!
[14:37:37 CEST] <nevcairiel> its not like its new though
[14:37:43 CEST] <JEEB> ah right :D
[14:37:43 CEST] <nevcairiel> it probably exists for 8 years by now
[14:37:48 CEST] <JEEB> also yes, the library is old
[14:37:52 CEST] <thardin> aha
[14:37:57 CEST] <thardin> lol
[14:38:02 CEST] <JEEB> (it shows that I deffo didn't get enough sleep)
[14:38:22 CEST] <nevcairiel> i never get enough sleep, you get used to i t
[14:38:26 CEST] <cehoyos> nevcairiel: gcc claims here that strftime() does not understand %s on mingw either
[14:38:35 CEST] <nevcairiel> this is true
[14:38:39 CEST] <cehoyos> hlsenc.c:1693
[14:38:40 CEST] <nevcairiel> because thats not gccs doing
[14:38:51 CEST] <nevcairiel> gcc on mings compiles against the MS crt
[14:38:54 CEST] <nevcairiel> mingw*
[14:39:10 CEST] <cehoyos> Then why do we use %z on mingw?
[14:39:29 CEST] <cehoyos> Didn't you block my patch changing this? Or do I misremember?
[14:39:32 CEST] <nevcairiel> mingw likes to override some functions with its own variants
[14:39:43 CEST] <nevcairiel> for better gcc-style compat
[14:39:50 CEST] <nevcairiel> but not strftime afaik
[14:40:25 CEST] <cehoyos> So what is the solution?
[14:40:49 CEST] <nevcairiel> configure should really test this instead of some runtime test being performed
[14:41:02 CEST] <nevcairiel> i recommended that to the author at the ti me, but apparently that never came as a follow up
[14:41:16 CEST] <cehoyos> How can configure test this?
[14:41:27 CEST] <nevcairiel> make a binary, execut it, see what happens
[14:41:34 CEST] <cehoyos> When cross-compiling?
[14:41:38 CEST] <cehoyos> As I do atm
[14:42:38 CEST] <nevcairiel> we could also just adjust that guard there to account for mingw
[14:42:42 CEST] <nevcairiel> or generally all windows in that case
[14:43:06 CEST] <cehoyos> What is our preferred check for Windows in c files?
[14:43:46 CEST] <nevcairiel> #ifdef _WIN32 typically, but you can't use that inline like the existing check
[14:57:14 CEST] <cehoyos> How does "CYGWIN" relate here? Can CYGWIN target MSVCRT?
[14:57:32 CEST] <BtbN> no, Cygwin is Linux for most things ffmpeg cares about
[14:58:08 CEST] <BtbN> _WIN32 is also not defined on Cygwin
[15:09:06 CEST] <cehoyos> nevcairiel: How do you know where libaom crashed when encoding on win32?
[15:09:24 CEST] <cehoyos> I can reproduce the crash with wine but I don't get very useful debug information...
[15:10:08 CEST] <nevcairiel> i just ran it through gdb and it showed that
[15:11:25 CEST] <cehoyos> Found gdb in the packager...
[20:56:49 CEST] <faLUCE> JEEB and others: (about patching when a patch includes also a modification to a file which is frequently changed, like configure)  before format-patch, should I rebase my-dev-branch against local master or against origin/master ?
[20:57:42 CEST] <nevcairiel> against the central master of course, thats what the patch has to apply against
[20:59:12 CEST] <JEEB> faLUCE: the end result is what nevcairiel says. the branch you rebase against can be local or remote branch, but main thing is that you're rebasing against current central master :P
[20:59:48 CEST] <faLUCE> nevcairiel JEEB: ok, then should I call:  "git format-patch -o patches origin/master..HEAD" or is the last token unnecessary given that I already rebased?
[21:32:24 CEST] <mkver> AVPacket's duration field says that a duration of 0 means "unknown". But how does one distinguish the case of an unknown duration (which probably means "show until the next subtitle (of this stream) is to be displayed) from a zero duration subtitle (like a comment that is not to be displayed at all)?
[21:36:04 CEST] <JEEB> usually you decode the subtitle and then you get an AVSubtitle
[21:36:35 CEST] <JEEB> which has its own fields
[21:37:36 CEST] <mkver> I am more interested in the case of (de)muxing.
[21:38:02 CEST] <JEEB> then you're usually at the behest of your input container
[21:38:19 CEST] <JEEB> for example MPEG-TS just has zero
[21:38:27 CEST] <JEEB> for pkt_duration
[21:38:52 CEST] <mkver> But how should the demuxer set the duration field for a subtitle with an explicit duration of zero (as opposed to an unknown length duration)?
[21:39:22 CEST] <nevcairiel> Also Set it to zero, not like you have options
[21:39:42 CEST] <mkver> If the demuxer can't signal this, the information is lost and whatever works with this data will not be able to handle it properly.
[21:40:16 CEST] <mkver> Duration is signed, so one could signal it by using a negative value or so.
[21:40:20 CEST] <durandal_1707> cehoyos: you gonna add new codecs to mplayer svn code?
[21:42:03 CEST] <JEEB> mkver: yea it's unfortunate - for AVSubtitles I noticed -1/UINT32_MAX is what got utilized
[21:42:27 CEST] <nevcairiel> Is there really an actual semantic difference between unknown and no duration from a demuxer perspective? The decoder will figure out if there is a subtitle to show forever, or some other content 
[21:44:06 CEST] <nevcairiel> Ultimately both mean "I have no duration'
[21:45:13 CEST] <mkver> Duration zero can also mean "I should not be shown at all." This way one could add comments.
[21:46:17 CEST] <JEEB> yea, that's really format specific
[21:46:21 CEST] <JEEB> unfortunately
[21:46:54 CEST] <JEEB> if you then decode that and it actually has a subtitle that is supposed to be shown or not then that should be signaled in the decoded AVSubtitle
[21:47:15 CEST] <JEEB> what formats are you specifically talking about btw, for reference?
[21:48:34 CEST] <nevcairiel> The decoder will know that
[21:48:40 CEST] <mkver> Matroska. It can distinguish between duration zero (for comments) and unknown duration.
[21:48:40 CEST] <nevcairiel> Does the container have to?
[21:50:17 CEST] <mkver> How should the decoder be able to find out when a subtitle is not to be shown?
[21:50:40 CEST] <mkver> If said information is only stored at the container level and can't be forwarded?
[21:50:45 CEST] <nevcairiel> The codec would have a way to signal comments of course
[21:51:01 CEST] <JEEB> like ASS, which most likely are what have comment lines
[21:51:10 CEST] <JEEB> the actual line contents contain a comment
[21:51:36 CEST] <JEEB> also I'm trying to check what the matroska spec exactly says just out of interest
[21:51:36 CEST] <nevcairiel> Trying to rely on duration 0 not being shown instead of shown until next seems very specific and likely to break in 90% of all software
[21:51:52 CEST] <mkver> Really? What way do e.g. srt subtitles (S_TEXT/UTF8 in Matroska) have for this?
[21:52:35 CEST] <nevcairiel> I don't really get the point of this feature. It's not like you have video frames that get silently skipped for no reason
[21:52:49 CEST] <nevcairiel> On a demuxer controlled level no less
[21:52:55 CEST] <mkver> Ok, then there is also the invisible flag in the (Simple)Block header, but this can't be exported either.
[21:53:51 CEST] <JEEB> SRT IIRC has had all sorts of stuff put into it, I wouldn't be surprised if there's some ways of putting a comment into a line
[21:53:54 CEST] <JEEB> but yes
[21:53:57 CEST] <nevcairiel> Matroska likes to invent nonsensical features tbh
[21:53:58 CEST] <JEEB> SRT is a format with an exact start and end time
[21:54:07 CEST] <mkver> For videos, this feature (whether through duration zero or no the invisible flag) could be used for frame-accurate cutting, similar to edit lists for mov/mp4.
[21:54:23 CEST] <JEEB> we already have virtual time lines, though?
[21:54:29 CEST] <JEEB> in matroska
[21:54:37 CEST] <JEEB> as part of chapters
[21:55:11 CEST] <mkver> And if said start and end time coincide, it will be indistinguishable from a subtitle packet without a duration at all.
[21:56:06 CEST] <nevcairiel> btw AV_PKT_FLAG_DISCARD exists for frames that should not be shown, but decoded
[21:56:14 CEST] <nevcairiel> but good luck hoping that anyone implements that properly
[21:57:25 CEST] <JEEB> mkver: anyways yea - currently the "unknown" duration thing is a mess
[21:58:13 CEST] <JEEB> if you really need to hold that info on the demuxer/muxer level and can't decode
[21:58:22 CEST] <JEEB> since a lot of stuff is thus format-specific :P
[22:01:26 CEST] <mkver> @nev: You are right. That info can be exported. Thanks. Sorry for the noise.
[22:01:29 CEST] <JEEB> and if we want to differentiate unknown (say, -1) and zero. we'd have to change quite a few
[22:01:52 CEST] <nevcairiel> yeah something like that is unlikely to get changed without reaaaaally good reasons
[22:01:58 CEST] <JEEB> or actually I'm not sure how many demuxers use -1 and which use 0 already
[22:02:02 CEST] <nevcairiel> since its very hard to deprecate and inform callers
[22:02:05 CEST] <JEEB> the default value is probably 0
[22:07:11 CEST] <JEEB> we do have some -1s although I'm not sure for how long those stay like that
[22:07:21 CEST] <JEEB> git grep is not perfect
[22:07:48 CEST] <nevcairiel> AVPacket->duration of -1 is technically invalid
[22:09:02 CEST] <JEEB> looked with `git grep -E "duration\s*=\s*" -- libavformat/`
[22:09:16 CEST] <JEEB> which isn't perfect but it has some seeming AVPacket sets
[22:09:26 CEST] <mkver> @JEEB: If by "we" you mean FFmpeg, then I have to say that Matroska ordered chapters (the virtual timelines) are not really supported (just like the file linking stuff). The current code basically ensures that only the first edition will be used.
[22:09:52 CEST] <nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle"
[22:09:55 CEST] <nevcairiel> it should never reach the caller
[22:10:25 CEST] <JEEB> mkver: yes I know, there was a lot of hurf and durf about it back in the day, and nowadays I think we kind of have a consensus'ish about making it metadata/side data
[22:10:42 CEST] <JEEB> mkver: which is how seemingly ISOBMFF edit lists should have been implemented like
[22:11:01 CEST] <nevcairiel> the edit list stuff constantly causes issues
[22:11:06 CEST] <JEEB> yes
[22:11:15 CEST] <JEEB> quite a few API users just disable the "advanced" edit list code
[22:11:16 CEST] <JEEB> :)
[22:11:24 CEST] <nevcairiel> indeed i do that myself
[22:11:35 CEST] <mkver> In LAV?
[22:11:40 CEST] <nevcairiel> i also was one to push for that option even being present
[22:11:47 CEST] <JEEB> mkver: aye
[22:12:00 CEST] <JEEB> mpv also disables it because it does things on the wrong layer
[22:12:06 CEST] <JEEB> (it's a presentation layer thing)
[22:12:51 CEST] <nevcairiel> technically the same applies to mkv
[22:13:12 CEST] <JEEB> yes
[22:13:15 CEST] <nevcairiel> but mkv is far more limited by implementation, and most files and tools around that were build against how haali made it work on a demuxer level, so it sort of works out
[22:13:22 CEST] <JEEB> yup
[22:14:51 CEST] <nevcairiel> for mp4 .. i dont remember ever getting a real request for such files anyway
[22:18:02 CEST] <mkver> So all the edit lists that you encounter are of the type that just shift the pts of the first packet to zero?
[22:18:41 CEST] <nevcairiel> something like that yea
[22:18:45 CEST] <JEEB> that's 99% of it all. then there's both borked samples (clearly not meant to be what the edit list says), and some which might be output from a video editor... as a project file
[22:18:58 CEST] <JEEB> because MOV files were also supposedly utilized as at least partial project files
[22:23:26 CEST] <JEEB> anyways, exported to the presentation layer (API client), and then that layer can handle it in ways it requires/knows
[22:23:59 CEST] <JEEB> I'm just happy that it's pretty rare we get people actually having issues with the on-by-default advanced edit list stuff
[22:24:41 CEST] <JEEB> every now and then, like once in a few months or so on the user channel I have to explain people how to disable it 
[22:25:31 CEST] <mkver> @Nev: If there is no next subtitle packet and the duration is still -1, what does it get set to?
[22:26:29 CEST] <JEEB> which layer?
[22:26:37 CEST] <JEEB> or what was the context? :)
[22:27:14 CEST] <mkver> "<nevcairiel> the subtitle queue stuff uses -1 as a special marker that means "set me to the start time of the next subtitle""
[22:45:29 CEST] <nevcairiel> would have to read the code, so you can do that too :D
[22:46:30 CEST] <mkver> Ok.
[00:00:00 CEST] --- Wed Apr 17 2019