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

[burek]

[00:15:16 CET] <pross> Compn: i think it is!
[01:56:22 CET] <rcombs> so, what's the thinking on my TLS patch series
[01:56:34 CET] <rcombs> particularly around enabling verification by default (except on mbedTLS)
[01:56:54 CET] <rcombs> should that be some kind of version bump?
[01:58:24 CET] <rcombs> (I don't think any of the other changes should be controversial; maybe enabling default CA paths in OpenSSL? that's just bringing its behavior in line with the other wrappers, but I suppose one could argue it's a significant enough behavior change to warrant a version bump)
[02:00:15 CET] <rcombs> last I'd seen, cehoyos was against and michaelni was for
[02:46:23 CET] <Compn> rcombs : enabling verification on tls where now ?
[02:46:47 CET] <Compn> for http streams ?
[02:47:28 CET] <rcombs> Compn: in the tls proto in general, which is mostly used for https streams yeah
[02:47:48 CET] <Compn> rcombs : is there a stream that requires it ?
[02:47:56 CET] <rcombs> huh?
[02:48:32 CET] <Compn> usually what happens when we change defaults is that it breaks a bunch of streams :D
[02:49:37 CET] <rcombs> I'm not sure what you mean by "stream" here
[02:50:19 CET] <rcombs> this is at the protocol level; it isn't affected by content at all
[02:50:28 CET] <rcombs> (in fact this all happens before we even see the first byte of content)
[03:20:28 CET] <rcombs> Compn: anything I can do to clear up what the change does for you?
[03:22:53 CET] <Compn> rcombs : i mean if verification fails does it do anything
[03:22:54 CET] <Compn> :P
[03:23:04 CET] <Compn> sorry i was thinking of crc checking in ac3 or so
[03:23:34 CET] <rcombs> if verification fails then the connection is aborted under the assumption that it's being MITM'd, as is standard behavior for TLS clients (e.g. curl, web browsers, etc)
[03:23:49 CET] <rcombs> this is verification of the server's certificate, not of anything in the content
[03:47:02 CET] <rcombs> is it even possible for aarch64 not to have the NEON CPU flag?
[03:47:18 CET] <rcombs> oh, I guess if it's forced off for testing
[03:49:23 CET] <Compn> right thats what i'm saying
[03:49:29 CET] <Compn> if a server has a bad cert
[03:49:31 CET] <Compn> which a lot do
[03:49:33 CET] <Compn> then ffmpeg will die
[04:07:18 CET] <rcombs> Compn: well that's why there's still a flag to disable it
[04:07:35 CET] <rcombs> as in pretty much all TLS clients
[04:08:27 CET] <rcombs> lavf is very unusual in having verification be off by default; AFAICT it's primarily like that because historically there hasn't been a reliable way to load the system trust store on all platforms
[04:08:53 CET] <rcombs> (particularly macOS and Windows, where there's no single .pem file or dir of them to use)
[04:09:38 CET] <rcombs> but these days we've got code to load the system trust store in those cases (by using the system's TLS implementation)
[06:47:03 CET] <rcombs> &why does this code shift 2 values right by 1, _then_ take the max of the 2 (and discard the other)
[07:00:48 CET] <Compn> rcombs : just sounds like a nightmare on windows :p
[07:01:18 CET] <rcombs> Compn: windows has a built-in TLS implementation and we use that there; it provides the system trust store out of the box with no configuration
[07:01:23 CET] <rcombs> (same with mac)
[07:02:22 CET] <Compn> vista tls is not compatable with w7 implementation
[07:02:35 CET] <Compn> or are you suggesting we kill vista support too?
[07:03:17 CET] <Compn> i ran into this on a vista box when a video game updated their tls ahhaha
[07:04:15 CET] <Compn> video game was rocket league
[07:04:25 CET] <rcombs> [citation needed]
[07:05:27 CET] <rcombs> AFAIK SChannel has been around since at least XP
[07:05:31 CET] <Compn> i think it was tls 1.3
[07:05:46 CET] <Compn> was not supported in vista
[07:05:49 CET] <rcombs> (I personally don't care about anything older than 7 since it's not even supported by the vendor anymore, but whatever)
[07:06:10 CET] <rcombs> that's a protocol version; it's got nothing to do with whether we verify certs or not
[07:06:24 CET] <rcombs> (and 1.3 is _very_ recent; I'm pretty sure 7 doesn't have it either)
[07:07:48 CET] <Compn> https://blogs.msdn.microsoft.com/kaushal/2011/10/02/support-for-ssltls-protocols-on-windows/
[07:07:59 CET] <Compn> TLS 1.1 & TLS 1.2 are enabled by default on post Windows 8.1 releases. Prior to that they were disabled by default. So the administrators have to enable the settings manually via the registry.
[07:08:16 CET] <Compn> ok i've confused everything then
[07:08:19 CET] <Compn> ignore me rcombs
[07:08:51 CET] <Compn> all i know is that tls is not easy on vista :D
[07:09:39 CET] <Compn> vista is garbage anyway
[07:47:28 CET] <j-b> 'morning
[09:21:04 CET] <rcombs> okay I hate the manual but otherwise writing aarch64 SIMD is AMAZING
[09:21:24 CET] <rcombs> feel like I'm drowning in registers
[09:21:41 CET] <rcombs> and the calling convention actually uses them effectively
[09:31:03 CET] <wbs> rcombs: yes
[09:32:16 CET] <wbs> rcombs: the manual is a bit hard to browse, but I'm often using ARMv8_ISA_PRD03-GENC-010197-30-0.pdf instead which is a super-brief version, and has got good mappings between armv7 and aarch64 forms of instructions as well
[09:32:44 CET] <rcombs> wbs: is there anything that actually includes definitions of the operations, like intel usually gives
[09:32:52 CET] <rcombs> like, I had to look up wtf a "zip" is separately
[09:36:40 CET] <wbs> rcombs: the brief overview (ARMv8_ISA_PRD03-GENC-010197-30-0.pdf aka "ARMv8 Instruction Set Overview" doesn't have that, but that one is great for easily finding out what instructions exist), but the ARM ARM (e.g. DDI0487A_a_armv8_arm.pdf) defines everything, but it's pretty scattered. for e.g. the zip1 instruction, it describes this:
[09:36:45 CET] <wbs> for p = 0 to pairs-1
[09:36:48 CET] <wbs> Elem[result, 2*p+0, esize] = Elem[operand1, base+p, esize];
[09:36:50 CET] <wbs> Elem[result, 2*p+1, esize] = Elem[operand2, base+p, esize];
[09:37:18 CET] <rcombs> sure, that's reasonable enough
[09:39:26 CET] <wbs> the armv7 versions of instructions sometimes have better descriptions as well - if you look for the vzip instruction, it shows an example of register contents before and after the operations
[09:39:39 CET] <rcombs> also I'm not clear on what does and doesn't set flags
[09:40:05 CET] <rcombs> and the aarch64 manual seems to just assume I'm already familiar with armv7 predicate syntax
[09:40:18 CET] <wbs> as far as I know, nothing normally sets flags, except for explicit compare instructions, or instructions with 's' suffix
[09:40:24 CET] <rcombs> like, it mentions that that syntax only works on jumps now, but doesn't actually explain it at all
[09:40:55 CET] <wbs> I'm pretty sure it is _somewhere_ there, but browsing it from start to end through all 5158 pages is a bit much
[09:41:49 CET] <wbs> C1.2.3 Condition Code explains them
[09:42:36 CET] <wbs> in practice I mostly only ever use eq/ne/gt/lt/ge/le out of them
[09:42:51 CET] <wbs> very occasionally hi/ls
[09:43:58 CET] <rcombs> I must be looking at a different document 'cause I don't have a 1.2.3
[09:44:01 CET] <rcombs> (or even a 1.2)
[09:45:08 CET] <wbs> DDI0487A_a_armv8_arm.pdf - that's a must-have
[09:45:22 CET] <wbs> you get it behind a registration wall at http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.subset.architecture.reference/index.html
[09:45:38 CET] <wbs> or enter the filename into google and you'll find a copy elsewhere
[09:46:02 CET] <rcombs> oh a registration wall
[09:46:10 CET] <rcombs> that probably explains why I hadn't stumbled across it yet
[09:46:14 CET] <wbs> and then the other one, ARMv8_ISA_PRD03-GENC-010197-30-0.pdf, is a nice complement for easier browsing
[09:46:46 CET] <rcombs> also helps that several other sites host convenient googleable HTML versions of intel's docs
[09:46:58 CET] <wbs> that one is also available without registration on https://www.element14.com/community/servlet/JiveServlet/previewBody/41836-102-1-229511/ARM.Reference_Manual.pdf
[09:47:00 CET] <rcombs> like, the ones you get if you google most x86 instructions that aren't also common english words
[09:47:20 CET] <wbs> then you finally need http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf occasionally
[09:47:31 CET] <wbs> for descriptions about calling conventions, what registers you can/can't clobber etc
[09:47:41 CET] <rcombs> thanks
[09:48:04 CET] <rcombs> oh that one, yeah, I actually already had a tab open to that
[09:48:23 CET] <rcombs> ("registers you can clobber: most of them!")
[09:48:52 CET] <wbs> yup, with x0-x15 free for clobbering you very very seldom need anything else, unless you do nested calls and need to backup x30
[09:49:07 CET] <wbs> and for neon, don't use v8-v15 unless you're starved
[09:49:16 CET] <rcombs> and it's hard to be starved
[09:49:53 CET] <wbs> the vp9/av1 inverse transforms use as much registers as you have, and more :P
[09:50:12 CET] <wbs> or if you work on many rows in parallel etc
[09:50:16 CET] <rcombs> yeah but those are hard :P
[09:50:19 CET] <wbs> lol
[09:50:37 CET] <wbs> and tedious as fuck
[14:06:45 CET] <Compn> why rawpcm in avi
[14:06:46 CET] <Compn> whyyy
[23:17:26 CET] <cone-215> ffmpeg 03caohui 07master:ee1c63eb8218: lavf/hlsproto: Replace a wrong eol comma with a semicolon.
[23:26:55 CET] <cone-215> ffmpeg 03Carl Eugen Hoyos 07master:cf81284b1c14: lavc/g723_1enc: Set the default bitrate to 6300.
[23:41:36 CET] <cone-215> ffmpeg 03Andreas Rheinhardt 07master:992532ee3122: h2645_parse: Make ff_h2645_packet_split reference-compatible
[23:41:37 CET] <cone-215> ffmpeg 03Andreas Rheinhardt 07master:8ca55a2b9e95: cbs_h2645: Avoid memcpy when splitting fragment #2
[00:00:00 CET] --- Thu Jan 24 2019