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

burek burek021 at gmail.com
Sun Jun 9 03:05:04 EEST 2019


[00:01:31 CEST] <BtbN> no
[00:02:17 CEST] <uartie> :(
[00:51:58 CEST] <jdarnley> I know there are tests for the hash functions in avutil but where is the reference/comparison files?
[00:54:46 CEST] <nevcairiel> depending on how its tested, may not even have one
[00:56:07 CEST] <nevcairiel> many internal base components like that have test code written in C
[00:56:30 CEST] <jdarnley> ah, it might be tests/ref/fate/hash
[00:57:54 CEST] <jamrial> that's the ref file for the AVHashContext framework, but each specific hash module has its own test and ref file in that same folder
[01:00:10 CEST] <jdarnley> I see the md5 file now, I think
[02:45:03 CEST] <cone-225> ffmpeg 03Peter Ross 07master:b6ca032adebe: avcodec/vp3data: combine eob_run_base and eob_run_get_bits tables
[02:48:59 CEST] <J_Darnley> Does fate strip trailing spaces in stdout somewhere?
[02:55:26 CEST] <J_Darnley> sort of
[02:55:47 CEST] <J_Darnley> it uses diff -b which is "ignore changes in the amount of white space"
[02:56:45 CEST] <pross> uartie: what are other good tools?
[07:37:13 CEST] <uartie> pross: github and gitlab come to mind
[07:38:09 CEST] <uartie> ...and are all-in-one solutions
[08:00:01 CEST] <uartie> pross: afaict, ffmpeg project uses several unrelated tools/methods to handle website, wikis, git, bug tracking, ci, patch submission/review, etc.  I assume someone in the community has to maintain the servers/hardware to host these services, too.  And trying to integrate any of these together must be a nightmare to deal with!  Something like GitLab/Hub would handle all of this stuff.
[08:57:04 CEST] <grosso> hi
[15:34:24 CEST] <BtbN> Just suggesting gitlab will be shot down, because a lot of contributors really like their mailing list.
[15:34:40 CEST] <BtbN> Anything that needs a Browser pretty much stands no chance.
[15:54:54 CEST] <rcombs> so, as of macOS 10.15, Secure Transport is deprecated
[15:55:08 CEST] <nevcairiel> let me guess, the replacement isnt available yet :D
[15:55:17 CEST] <rcombs> it's still present, and I'd expect it to remain present for the foreseeable future for compatibility, but it doesn't (and won't) support TLS 1.3
[15:55:26 CEST] <rcombs> the replacement is Network.framework
[15:55:37 CEST] <rcombs> which is a replacement for the entire BSD Sockets API
[15:55:40 CEST] <nevcairiel> as a developer, i really fiercely hate Apples philosophy for development
[15:55:50 CEST] <nevcairiel> they change everythign every couple versions
[15:56:00 CEST] <rcombs> it bundles TLS and TCP into a single API, and it's very async
[15:56:10 CEST] <BtbN> So they are kicking out sockets and OpenGL? Fun.
[15:56:14 CEST] <BtbN> Time to drop support.
[15:56:15 CEST] <rcombs> it's been available since 10.14
[15:56:28 CEST] <rcombs> BSD sockets are still supported
[15:56:34 CEST] <rcombs> (and not deprecated)
[15:56:43 CEST] <rcombs> but there's no way to use, say, MPTCP with them
[15:56:55 CEST] <nevcairiel> I would say that if they ever truely kill OpenGL, they would be in a world of pain, but then the Apple fanboi crowd will still praise them :p
[15:56:58 CEST] <rcombs> (the Linux folks are working on solutions for that but they're mostly server-oriented)
[15:57:22 CEST] <rcombs> nevcairiel: it'd be pretty dumb given that they have to ship a GL-on-Metal implementation regardless (for WebGL)
[15:57:29 CEST] <BtbN> They already did truely kill OpenGL. They are not maintaining the drivers anymore, and a wide range of applications stops working with each update.
[15:57:53 CEST] <BtbN> Dolphin-Emulator for example already dropped support due to that.
[15:58:12 CEST] <rcombs> so, philosophical arguments aside: I'd expect I'll implement Network.framework TLS in lavf
[15:58:20 CEST] <rcombs> how do we want to handle that?
[15:58:32 CEST] <nevcairiel> good luck with that, I figure i'll just swap to  GnuTLS on there
[15:58:56 CEST] <rcombs> I'll set it up for weak-linking so it doesn't create a runtime dependency on 10.14
[15:59:29 CEST] <rcombs> I'm not sure if it'll fit in with the other tls.c infrastructure, since it won't be layered on top of lavf TCP
[16:00:07 CEST] <rcombs> the biggest thing I'm wondering about is how to handle protocol selection
[16:00:11 CEST] <nevcairiel> that'll practically make it impossible to use it in lavf, tbh
[16:00:28 CEST] <nevcairiel> unless you want to change every single thing that uses it
[16:00:34 CEST] <rcombs> how so?
[16:01:08 CEST] <rcombs> don't most users basically open tls://[host]:[port], and it's an implementation detail that it's layered on top of lavf's tcp protocol?
[16:04:57 CEST] <rcombs> BtbN: dunno where you heard that Dolphin was dropping support for macOS but it doesn't seem to be the case
[16:05:08 CEST] <rcombs> apparently they're in the process of moving to MoltenVK there
[16:05:42 CEST] <rcombs> my biggest question is around how tls_nwf (final name TBD?) and tls_securetransport will coexist
[16:06:09 CEST] <nevcairiel> you can't build ffmpeg with two tls protocols currently
[16:06:10 CEST] <rcombs> or should tls_securetransport just internally use Network.framework when available and otherwise fallback on ST?
[16:06:23 CEST] <rcombs> yeah, so I need some sort of a solution to that
[16:06:44 CEST] <BtbN> They implemented MoltenVK as alternative, but as it stands right now, it has even more issues than OpenGL
[16:06:52 CEST] <BtbN> so effectively, Dolphin is unuseable on current OSX
[16:07:31 CEST] <rcombs> maybe that means tls_securetransport gets renamed to tls_apple and implements both ST and Network.framework?
[16:08:03 CEST] <rcombs> or maybe it means we add some sort of abstraction that allows multiple TLS implementations (which would be useful for testing anyway)
[16:09:54 CEST] <nevcairiel> I would rather see that limited to the mac stuff
[16:11:34 CEST] <ritsuka> BtbN: dolphin with moltenvk worked quite well with a few game I tried (Twilight Princess for example)
[16:11:44 CEST] <rcombs> sounds like my best route is probably to rename tls_securetransport to tls_apple and have 2 implementations in 2 file with runtime version checks and #ifdefs around the new version
[16:12:06 CEST] <BtbN> TP is pretty basic in terms of graphics pipeline usage
[16:13:19 CEST] <rcombs> ¯\_(Ä)_/¯ I've run games on Dolphin under macOS years ago and didn't have significant problems
[16:13:29 CEST] <rcombs> it's not gotten _worse_ since then
[16:16:17 CEST] <BtbN> It is though, since dolphin is making use of a lot more OpenGL features now, which OSX never even implemented, or does implement, but incorrectly
[17:48:37 CEST] <rcombs> also I'm gonna go ahead and get rid of the private-API crap in tls_securetransport that people have complained about wrt app store rejections
[17:49:04 CEST] <rcombs> the private API it uses is to create a SecIdentity from a SecKey and an array of SecCertificates loaded from PEM data
[17:49:40 CEST] <rcombs> there's no public way to do that, _but_ there's a public way to create a SecIdentity from a PKCS#12 blob
[17:49:51 CEST] <rcombs> and also a public way to convert an array of keys and certificates to a PKCS#12 blob
[17:51:55 CEST] <rcombs> this is dumb as shit but sure whatever
[17:56:04 CEST] <JEEB> yea
[17:56:17 CEST] <JEEB> makes sense to not do private apus
[17:56:20 CEST] <JEEB> *apus
[17:56:23 CEST] <JEEB> ffuu
[18:47:07 CEST] <mkver> Does anybody know whether it would be legal to put an H.264 picture into multiple PES packets when muxing it into a transport stream? (I.e. can a H.264 access unit cross the boundaries of PES packets?)
[18:48:23 CEST] <j45> yes
[18:50:35 CEST] <mkver> That's bad. If it were otherwise, this could be exploited to remove some (then unnecessary) memcpys when parsing H.264 in transport streams/program streams..
[18:51:50 CEST] <j45> to expand a bit, video in pes is always escaped so that start codes are not spoofed.  so when read and un-escaped, the access unit boundaries can be found by looking for the start codes
[18:53:03 CEST] <nevcairiel> Whats the "boundary" of a PES packet anyway? Some streams forget PUSI and you have to entirely rely on  the parser to put it back together properly
[18:55:19 CEST] <nevcairiel> if that was reliable, we wouldnt need annexb in the first place :D
[19:05:42 CEST] <mkver> I hoped that the packetization contained a rule like "A PES packet either consists of a complete H.264 access unit or of two complete H.264 access units provided that these two access units contain coded fields that together constitute a complememtary field pair."
[19:07:33 CEST] <j45> nope.  dvd is a good counter example, although it's mpeg2, same rules apply.  pes packets in dvd are limited to 2KB
[19:08:34 CEST] <mkver> By "boundary" of a PES packet I meant the positions in the extracted elementary stream that correspond to the first byte extracted from a PES packet.
[19:09:03 CEST] <mkver> Ok, then it seems that there is no simple way to avoid some memcpys.
[19:10:50 CEST] <mkver> (Even if a PES packet contains a complete H.264 access unit, it is copied into the parser's buffer, because that it is a complete access unit will only be apparent when the next access unit is received. And upon returning it will be copied once more because parsers don't make use of refcounted buffers.)
[00:00:00 CEST] --- Sun Jun  9 2019


More information about the Ffmpeg-devel-irc mailing list