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

[burek]

[00:00:46 CEST] <jkqxz> Here you go:  <https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/i915/intel_device_info.c#n678>.
[00:01:02 CEST] <jkqxz> Apparently you get more overlays on the embedded platforms.
[00:01:23 CEST] <jkqxz> Which makes sense, since you are more likely to actually use them there rather than just compositing all the things together.
[00:02:35 CEST] <jkqxz> Though if by "newer intel cpus" you actually mean Cannonlake then I guess they do have more.
[00:03:09 CEST] <atomnuker> dunno, TD-Linux told me >= skylake were full of them, but apparently no
[00:03:12 CEST] <jkqxz> (Gemini Lake uses the same display hardware as Cannonlake, though the GPU and media parts match Kaby Lake.)
[00:06:34 CEST] <TD-Linux> I tried to find which had them and the marketing material seemed to imply skylake but I guess I might be wrong
[00:09:30 CEST] <jkqxz> "marketing material" - I think I can guess where you went wrong on finding accurate information :P
[00:36:38 CEST] <rcombs> atomnuker: https://gist.github.com/e37043818f1c3ba515f73dfa58ecbdc8
[00:40:37 CEST] <rcombs> on E3-1275 v6
[01:45:12 CEST] <cone-864> ffmpeg 03Jacob Trimble 07master:e5ba5fab493b: avformat/mov: Fix parsing of saio/siaz atoms in encrypted content.
[03:05:22 CEST] <atomnuker> any idea why ./configure is crazy?
[03:05:31 CEST] <atomnuker> it works fine if I reboot
[03:05:44 CEST] <atomnuker> but once I do a minor modification nothing makes sense
[03:05:51 CEST] <atomnuker> if enabled_all vulkan libshaderc ; then
[03:05:58 CEST] <atomnuker> vulkan is disabled, so 0
[03:06:07 CEST] <atomnuker> libshaderc is 1
[03:06:15 CEST] <atomnuker> and the code inside the if condition gets run
[03:06:40 CEST] <atomnuker> I can do "enable vulkan" unconditionally and yet vulkan stays disabled
[03:07:26 CEST] <atomnuker> make distclean doesn't help so I don't think something gets dirty
[10:08:09 CEST] <durandal_1707> I FIXED 5 YEARS OLD BUG IN VC1
[10:10:23 CEST] <nevcairiel> i'm sure there is even older ones!
[11:01:14 CEST] <j-b> <3 durandal_1707 
[11:03:15 CEST] <durandal_1707> j-b: i'm still waiting for that number of coins
[11:05:16 CEST] <j-b> send me invoices :)
[11:06:56 CEST] <durandal_1707> ok, sending for 10000000 coins
[11:37:06 CEST] <cone-309> ffmpeg 03Paul B Mahol 07master:21da248b5fee: avfilter: add deblock filter
[12:41:09 CEST] <KGB> [13FFV1] 15JeromeMartinez opened pull request #112: Version 0 and 1 can have some content after SliceContent (06master...06Reserved) 02https://git.io/vpYRX
[14:44:48 CEST] <atomnuker> durandal_1707: what do first? lavu fft or atrac9?
[14:45:37 CEST] <durandal_1707> atomnuker: your choice, doesn't really matter when you are extremly slow :/
[14:56:58 CEST] <atomnuker> hey I did finish the vulkan stuff, didn't I?
[15:00:11 CEST] <durandal_1707> yes, somehow
[17:11:05 CEST] <atomnuker> how many tls libraries would be support with mbedtls now?
[17:12:03 CEST] <nevcairiel> 6, two of which are OS components, so 4 libraries
[17:12:26 CEST] <atomnuker> I'm counting those in as well
[17:13:59 CEST] <nevcairiel> you want to use the one your OS favors, so what can you do
[17:17:12 CEST] <atomnuker> nothing wrong with that
[17:17:28 CEST] <wm4> when will there be a good TLS lib
[17:20:02 CEST] <klaxa> i remember when there was heartbleed some company advertised their java implementation to be super good and such because "anyone can write open-source, even 17 year old kids!"
[19:43:14 CEST] <LigH> Hi
[19:43:56 CEST] <LigH> Is there a table of relations between v#.# milestone version numbers and N-##### revisions?
[19:44:07 CEST] <JEEB> not really
[19:44:20 CEST] <JEEB> I mean, if you don't have a release it's all based on the initial N-tag
[19:44:37 CEST] <JEEB> you can just look up the branching point if you really want to
[19:45:06 CEST] <JEEB> and you shouldn't be using the number anyways, but rather the gXXXX
[19:45:09 CEST] <JEEB> which is the git hash
[19:45:34 CEST] <LigH> So if I just keep updating and building, without analyzing the commit history, revision N-90793 won't tell me which version+patches it is...
[19:45:59 CEST] <JEEB> if you have patches you're hosed anyways
[19:46:05 CEST] <JEEB> since all those commits get counted into it
[19:46:10 CEST] <LigH> No, I just let MABS build it.
[19:46:29 CEST] <JEEB> I have NFI what the flying fsck that does
[19:46:33 CEST] <LigH> And be surprised when users in a forum tell me that this is suddenly v4.0
[19:46:51 CEST] <BtbN> I tried replacing the N thing with commits since last branching of a release
[19:46:54 CEST] <JEEB> master is always N-based, and then you have the git hash after that as gXXXXXXXX
[19:46:57 CEST] <BtbN> carl didn't like that, at all
[19:46:57 CEST] <LigH> MABS is my abbreviation of https://github.com/jb-alvarado/media-autobuild_suite/
[19:47:15 CEST] <JEEB> I know what MABS is, but the main point is I have no idea what on earth it does
[19:47:20 CEST] <JEEB> if it just git apply's patches
[19:47:23 CEST] <JEEB> (no commits)
[19:47:27 CEST] <JEEB> then the N number is correct
[19:47:39 CEST] <LigH> An autobuild script which updates all available modules and ffmpeg sources, and builds one of several different choices of license compatible builds.
[19:47:39 CEST] <JEEB> and the gXXXXXX should be your git hash that you built
[19:48:57 CEST] <atomnuker> what's the correct way to read subtitle files with lavf?
[19:49:14 CEST] <atomnuker> doing what I do for normal container files doesn't work (using av_read_frame())
[19:49:29 CEST] <atomnuker> by subtitle files I mean non-embedded, raw, .ass or .vtt files
[19:49:31 CEST] <JEEB> huh, I would have thought that'd work
[19:49:38 CEST] <LigH> You can select either a sensible minimum selection for modern codecs, a broader selection like Zeranoe, everything-you-can-include, or your personal choice based on linker options in a text file.
[19:49:43 CEST] <LigH> ^ MABS
[19:49:55 CEST] <JEEB> that's not the goddamn point
[19:50:03 CEST] <JEEB> what I was trying to hint is that you go and look at your gXXXXXX
[19:50:13 CEST] <JEEB> and master is never a release, it can just be before/after a branch point
[19:50:33 CEST] <JEEB> and if you can find the gXXXXX (without the 'g' at the start) in the repo, that is the goddamn revision you built
[19:51:17 CEST] <LigH> Yes, I understood that much... and I am really sorry to be less experienced than you.
[19:51:57 CEST] <LigH> So I will read commit logs to know which milestone got passed last.
[19:52:19 CEST] <JEEB> no, that has nothing to do with it, it's just annoying when you ignore what I mention and keep on explaining about a system
[19:52:28 CEST] <LigH> For a "release build", MABS would have to update from a release branch, not the master branch.
[19:53:04 CEST] <atomnuker> stop spamming the dev channel, go to #ffmpeg to flog your build system
[19:53:08 CEST] <JEEB> yes
[19:53:09 CEST] <JEEB> that too
[19:53:18 CEST] <LigH> Sometimes I just miss one of your replies because I am looking at my keyboard while typing, not at the screen.
[19:53:43 CEST] <LigH> I'm not a "blind typer".
[19:54:05 CEST] <LigH> Takes me a while to understand all the consequences of your replies.
[19:54:46 CEST] <JEEB> atomnuker: anyways it feels weird if av_read_fr^Wpacket (best misnomer ever) doesn't give you anything
[19:54:49 CEST] <JEEB> I've just never tried it
[19:56:50 CEST] <LigH> So I'll leave before I get kicked... 
[19:57:33 CEST] <wm4> love it when ffmpeg devs try to use ffmpeg public API and fail
[19:59:36 CEST] <nevcairiel> i never thought the api was particularly hard to use
[19:59:44 CEST] <nevcairiel> and subtitles should be no different then any other file, fwiw
[20:00:05 CEST] <JEEB> yea
[20:00:18 CEST] <JEEB> so if AVPackets aren't coming.. that's weird
[20:00:28 CEST] <JEEB> the only difference is that you don't get AVFrames from the decoders
[20:02:51 CEST] <durandal_1707> look how ffmpeg.c does it
[20:08:15 CEST] <atomnuker> wm4: this time it seems it was my fault, I failed to allocate memory to read the packets
[20:08:55 CEST] <wm4> durandal_1707: bad advice
[20:09:05 CEST] <atomnuker> I sorta wish ubitux would finish his subs in avframes patch
[20:09:26 CEST] <atomnuker> anyone heard from him? he's been on holiday for months now, hasn't he?
[20:12:51 CEST] <durandal_1707> "holidays"
[20:16:33 CEST] <ubitux> no i'm back from holidays
[20:16:40 CEST] <ubitux> i just don't have time for ffmpeg currently
[20:17:02 CEST] <atomnuker> :/
[20:27:41 CEST] <ubitux> atomnuker: why the sudden interest in this subs avframe?
[20:28:58 CEST] <wm4> because he has to use the horrible subtitle API
[20:29:23 CEST] <ubitux> ah, yeah ok
[20:29:41 CEST] <atomnuker> its a neat solution and I'm wondering why it wasn't done like that in the first place
[20:30:39 CEST] <wm4> because it's complex
[20:30:52 CEST] <wm4> and AVFrame was "designed" for audio and video
[20:39:32 CEST] <durandal_1707> it is trivial
[20:45:30 CEST] <wm4> you could do some lame things, like just making AVFrame.data[0] point to AVSubtitle - but this still would not work well
[20:46:14 CEST] <wm4> I guess you could manage it like hwaccel frames, where data[0] also ignores normal rules about AVBufferRefs and AVFrame.bufs
[20:46:44 CEST] <wm4> even if you do this you still have the problem that AVSubtitle sucks
[20:47:34 CEST] <wm4> maybe you could set AVFrame.format to a specific value to signal that AVSubtitle is used, and reserve other values for other representations
[21:18:02 CEST] <cone-800> ffmpeg 03Ruiling Song 07master:f3341a045241: lavf: make overlay_qsv work based on framesync
[21:18:03 CEST] <cone-800> ffmpeg 03Ruiling Song 07master:d865783b6c8d: lavf/qsv: clone the frame which may be managed by framework
[21:47:46 CEST] <wm4> is it timebase or time_base
[21:48:14 CEST] <wm4> time_base seems more popular within ffmpeg
[21:51:00 CEST] <klaxa> i've barely touched things and i've already seen both
[21:52:03 CEST] <JEEB> yes
[21:52:16 CEST] <JEEB> both are used but time_base IMHO is better since it's two_words
[21:52:23 CEST] <ubitux> thousands of mails on ffmpeg-devel, meh, i've been away for too long
[21:52:47 CEST] <ubitux> did i miss anything important?
[21:53:04 CEST] <JEEB> mostly the removal of the register functions
[21:53:10 CEST] <JEEB> (except for avdevice, because reasons)
[21:53:13 CEST] <wm4> just lots of secondary drama
[21:57:57 CEST] <ubitux> is there some stuff i should review?
[22:04:44 CEST] <durandal_1707> ubitux: you missed silencedetect filter changes
[22:18:58 CEST] <wm4> lovely, AVFormatContext.max_delay is undocumented
[22:29:43 CEST] <ubitux> durandal_1707: seems these are contrib from my previous company, interesting
[22:30:35 CEST] <ubitux> i suppose they're using the filter to detect stream downtime
[22:30:44 CEST] <ubitux> well, at least it's tested now
[22:31:34 CEST] <ubitux> wm4: isn't this the former has_b_frames?
[22:32:33 CEST] <ubitux> mmh. maybe not
[22:33:05 CEST] <wm4> fascinatingly not
[22:33:39 CEST] <wm4> I think some sort of interleaving control maybe, but only supported by some muxers
[22:33:40 CEST] <wm4> (?)
[22:34:03 CEST] <atomnuker> ubitux: a lot of arm patches
[22:34:42 CEST] <ubitux> aarch64 or arm?
[22:35:30 CEST] <JEEB> some standard NEON and some aarch64
[22:51:18 CEST] <atomnuker> both
[22:52:15 CEST] <atomnuker> mostly neon though
[22:59:48 CEST] <cone-800> ffmpeg 03Carl Eugen Hoyos 07master:8592ae1a1e4c: lavf/dashdec: Do not use memcpy() to copy a struct.
[23:10:33 CEST] <wm4> "at least we've fixed a compiler warning"
[23:10:40 CEST] <wm4> no real fix in  sight
[23:11:55 CEST] <JEEB> I found it real fun that dashenc.c didn't work with its webm mode for a very long time as far as I can see
[23:11:59 CEST] <JEEB> if it ever worked at all
[23:12:05 CEST] <JEEB> nobody seemed to notice
[23:12:28 CEST] Action: JEEB only noticed because someone from facebook was complaining that doing VP9+Opus in DASH wasn't working
[23:12:58 CEST] <JEEB> (and according to akamai even if  you fix the crash it still wouldn't work in browsers)
[23:13:04 CEST] <JEEB> (and we have a separate webm dash muxer)
[23:23:41 CEST] <wm4> I'm kind of tired of carl trolling
[23:23:55 CEST] <wm4> if his goal is to piss me off with his troll persistence he might win
[23:23:57 CEST] <rcombs> JEEB: I noticed and fixed it and sent a patch
[23:24:17 CEST] <wm4> I also have to check what exactly austrian law says about libel
[23:24:50 CEST] <durandal_1707> just ban
[23:26:22 CEST] <JEEB> rcombs: oh
[23:26:35 CEST] <JEEB> I only saw the akamai patch regarding that which was just hiding the VP9 case under the rug
[23:26:41 CEST] <JEEB> which I kind of responded with salt to
[23:26:51 CEST] <wm4> reminds me of a german saying: never argue with trolls... first they pull you down to their level, then they beat you with their experience
[23:31:53 CEST] <JEEB> rcombs: right, I saw that you had posted stuff regarding it in March
[23:32:13 CEST] <JEEB> that patchset seems to have stalled since I see in patchwork that you noted you'd resend and then that seemingly never happened
[23:32:24 CEST] <iive> wm4, to me it looks like you are trolling here, talking about stuff out of context, that has happened somewhere else.
[23:32:41 CEST] <rcombs> oh im bad
[23:32:46 CEST] <durandal_1707> iive: stop!
[23:32:48 CEST] <JEEB> no you are not
[23:33:08 CEST] <JEEB> also yea, I really didn't care about that thing until someone herped a derp about its breakage somewhere I could see and easily replicate
[23:33:33 CEST] <JEEB> but yea, I would probably start thinking if that webm mode actually makes sense there
[23:33:38 CEST] <wm4> iive: just being trolled by an experienced troll
[23:33:55 CEST] <JEEB> since according to akamai the webm mode doesn't even work with browsers right now?
[23:34:08 CEST] <JEEB> (or maybe he was just not doing it correctly)
[23:34:22 CEST] <JEEB> while VP9 in ISOBMFF seems to work with chromium, firefox and edge
[23:34:24 CEST] <JEEB> of all things
[23:34:56 CEST] <wm4> edge = the thing?
[23:35:02 CEST] <JEEB> yes
[23:35:05 CEST] <JEEB> ms edge
[23:35:31 CEST] <wm4> not that surprising because they seem to try their hardest to be MS Chrome
[23:35:49 CEST] <JEEB> although at this point the HDR test clip that comes with windows 10 is also VP9 in Matroska
[23:39:48 CEST] <wm4> it sure is a nice change from IE6 days
[23:42:05 CEST] <rcombs>  <JEEB> no you are not
[23:42:14 CEST] <rcombs> idk I have a long history of not bothering to follow through on patches
[23:42:25 CEST] <JEEB> I totally cannot fault you on that :P
[23:42:54 CEST] <rcombs> okay but I can fault myself
[23:43:02 CEST] <JEEB> :)
[23:43:25 CEST] <rcombs> btw remuxing adts to live mkv is still broken
[23:43:32 CEST] <JEEB> \o/
[23:43:51 CEST] <rcombs> (fine in my fork, patch is on the list, but I haven't followed through!)
[23:44:28 CEST] <wm4> this is so weird... the dict arg for avcodec_open2 is redundant because you can just call av_set_opt directly, except for ff_frame_thread_encoder_init()
[23:44:52 CEST] <klaxa> i thought i was the only one in the world using live mkv, even though it's listed as intended use on the matroska site!
[23:45:04 CEST] <rcombs> klaxa: that one might be me
[23:45:13 CEST] <wm4> though it uses av_opt_copy magic, so maybe that is redundant too
[23:45:57 CEST] <klaxa> why _is_ nobody else using mkv for live content though?
[23:46:30 CEST] <JEEB> because true live is not really utilized because of how browser's XHR and CDN setups work
[23:46:39 CEST] <JEEB> it's always pseudo-live with segments
[23:46:47 CEST] <JEEB> (which can be cached by a dumb CDN)
[23:47:01 CEST] <klaxa> mmhh, but at least use mkv for the segments instead of mp4, then you can have proper subtitles :/
[23:47:12 CEST] <klaxa> but nooo, fragmented mp4 has to be shilled
[23:47:15 CEST] <wm4> mkv for live streaming wouldn't be too bad
[23:47:26 CEST] <wm4> there's webm dash
[23:47:41 CEST] <wm4> there's probably no reason why you couldn't have mkv dash
[23:48:04 CEST] <JEEB> yea, youtube in vp9 mode uses matroska (webm) segments
[23:48:19 CEST] <rcombs> yeah my use-case doesn't involve a dumb CDN
[23:48:25 CEST] <JEEB> yup
[23:48:30 CEST] <JEEB> true live <3
[23:48:57 CEST] <rcombs> though matroska is still plenty usable for segmented streaming (and AAC-in-that is also broken in that patch)
[23:49:14 CEST] <rcombs> far moreso than mp4, really
[23:49:34 CEST] <rcombs> JEEB: also it's less about XHR (which can stream just fine) and more about how MSE was designed by idiots
[23:49:49 CEST] <rcombs> so you have to send entire segments at once instead of streaming because ???????
[23:49:50 CEST] <JEEB> rcombs: I got once told that XHR will buffer the whole thing
[23:50:13 CEST] <JEEB> and then TD-Linux said there was some chunked mode, but then I got told that that one will buffer all the data as well
[23:50:24 CEST] <JEEB> which is why all webshits are doing websockets or so
[23:50:38 CEST] <JEEB> because websockets doesn't have that stupid "buffer all the data" thing
[23:50:48 CEST] <rcombs> ah yeah it does buffer the whole thing regardless
[23:50:56 CEST] <rcombs> just, you can get at the data before it finishes
[23:50:57 CEST] <wm4> JEEB: actually it does, partially
[23:51:00 CEST] <rcombs> fetch fixes that at least
[23:51:07 CEST] <JEEB> yes, you can get the data :D
[23:51:15 CEST] <JEEB> but yes, you are buffering a fuckload after a while
[23:51:19 CEST] <wm4> JEEB: it's packet based, and the JS interface returns full packets
[23:51:46 CEST] <JEEB> but I think that's less bad than "all the data so far"?
[23:51:54 CEST] <JEEB> if it's just a single packet (Whatever that is)
[23:51:57 CEST] <rcombs> but hey all of web is based around the assumption that RAM is an infinite resource
[23:52:27 CEST] <JEEB> I had pop corn material listening to some people poking at dash.js on an embedded device
[23:52:37 CEST] <JEEB> with 4K content
[23:52:43 CEST] <klaxa> wow
[23:52:48 CEST] <rcombs> so chromecast
[23:53:06 CEST] <rcombs> I built our MKV streaming infrastructure to deal with chromecast
[23:53:17 CEST] <JEEB> not exactly but it worked just as well as you would expect
[23:53:29 CEST] <rcombs> because DASH requires buffering entire GoPs and 1080 GoPs can be bigger than chromecast allows you to buffer
[23:53:46 CEST] <JEEB> :)
[23:54:07 CEST] <rcombs> google's stance seems to be "emit keyframes more often" and I'm like okay sure I'll tell my users to get on that
[23:54:21 CEST] <rcombs> also love too bloat encodes because webshits can't into video
[23:54:31 CEST] <wm4> I thought it can be independent from GoPs and keyframes
[23:54:39 CEST] <BtbN> Chromecast seems like a useless waste of money to me
[23:54:45 CEST] <BtbN> an RPi can do anything it can, but better
[23:54:53 CEST] <klaxa> except the botnet part
[23:55:04 CEST] <klaxa> unless you run win10 on it
[23:55:06 CEST] <klaxa> i guess
[23:55:07 CEST] <wm4> but a RPI is already bad
[23:55:10 CEST] <rcombs> in theory you can start segments on non-keyframes but it has a tendency to break shit
[23:55:27 CEST] <wm4> fun
[23:56:19 CEST] <rcombs> can't figure out exactly what's going wrong because while chromium _is_ open-source, it's such a gigantic project that it's not really practical to try to build and debug for this
[23:56:27 CEST] <JEEB> yea
[23:56:28 CEST] <rcombs> and I get issues in other browsers too
[23:56:51 CEST] <JEEB> spec says fragments don't have to be GOP-starting but effectively everyone will derp something wrong
[23:57:07 CEST] <JEEB> and yes, chromium is a lulzy project to start debugging
[23:57:35 CEST] <rcombs> also everything's across like 12 processes and good luck figuring out which one you need to look at
[23:59:16 CEST] <atomnuker> what was wrong with threads again so browsers need to use processes?
[23:59:42 CEST] <JEEB> to make it harder to go into other parts of the browser
[23:59:50 CEST] <JEEB> put everything behind IPC
[23:59:59 CEST] <rcombs> yeah it's for sandboxing
[00:00:00 CEST] --- Sun Apr 22 2018