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

[burek]

[00:54:50 CEST] <cone-013> ffmpeg 03Michael Niedermayer 07master:0ac8fce2679e: swresample/resample: Fix flush refelction length
[01:49:03 CEST] <iive> refelction? reflection?
[03:14:37 CEST] <jamrial> nevcairiel: "LINK : fatal error LNK1000: Internal error during BuildLibrary" :D
[03:15:02 CEST] <jamrial> msvc2017 x86_32
[03:17:32 CEST] <jamrial> this is after you updated the compiler yesterday it seems
[03:18:02 CEST] <jamrial> affects static builds only
[03:18:13 CEST] <jamrial> it also started failing some audiomatch tests in shared builds (which compile fine)
[03:45:07 CEST] <cone-013> ffmpeg 03Nikolas Bowe 07master:4b54d5a721cc: avformat/mov: Fix memory leak when reading DDTS box.
[03:45:08 CEST] <cone-013> ffmpeg 03Leo Izen 07master:cbd8e070561b: encoders.texi: Replace x264 --full-help suggestion with --fullhelp
[09:16:23 CEST] <gene_> Hi guys, I ran into a weird ffmpeg issue that I'm hoping you guys might know how to squeeze past
[09:16:58 CEST] <gene_> I'm trying to add a epoch timestamp to a video recording, which is formated by %s
[09:17:30 CEST] <gene_> Pretty much all other drawtext formats work fine (%a %b %S %d %Y) etc.
[09:18:20 CEST] <gene_> but when I put the %s in there the recording immediately breaks and it prints out something about side data (    Side data:       cpb: bitrate max/min/avg: 0/0/0 buffer size: 0 vbv_delay: -1)
[09:19:35 CEST] Action: rcombs summons reviews; prepares for controversy
[09:20:15 CEST] <durandal_1707> rcombs: for what?
[09:20:28 CEST] <rcombs> TLS verify-by-default
[09:21:11 CEST] <gene_> I'm hoping one of you might know how to avoid using this seemingly special %s side data code sequence.  Been trying to figure it out for like 3 hours with no luck lol.  Or if you guys know a different way to drawtext without referencing %s
[09:21:12 CEST] <nevcairiel> unless you can hook up proper callbacks for API users to be notified, thats not going to work =p
[09:21:50 CEST] <rcombs> nevcairiel: I have it configurable at compile-time, and people who need the current behavior and use the system-installed library can turn it off at runtime
[09:22:54 CEST] <nevcairiel> the point stands that plainly failing without the ability to know why from an API standpoint is no good
[09:23:33 CEST] <rcombs> there are any number of ways to fail without knowing why from an API standpoint
[09:24:03 CEST] <rcombs> not sure why this is any different
[09:25:11 CEST] <nevcairiel> because bad cert is something you may want the ability to let the user intervene and add an exception or whatever
[09:25:29 CEST] <rcombs> I mean, I guess it could be a new AVERROR code
[09:26:05 CEST] <rcombs> but it's currently AVERROR(EIO) with an error logged, and you can always try again with verify=0
[09:26:53 CEST] <nevcairiel> i do wonder though, if its such an important topic for you, why don't you just set verify to 1 in your code :D
[09:27:27 CEST] <rcombs> because it matters to me that people using ffmpeg.c, or mpv, or whatever else, actually are protected by TLS
[09:27:38 CEST] <rcombs> right now it's effectively worthless by default
[09:28:23 CEST] <nevcairiel> i never understand that, people claim that everytime and make it out to be that unverified tls is somehow much much worse then plain http, but you still get encryption and everything
[09:28:49 CEST] <rcombs> it makes the user think it's safe when it's really not
[09:28:53 CEST] <cone-446> ffmpeg 03Paul B Mahol 07master:7b19e76aeb0a: avfilter/vf_transpose: rewrite for x86 SIMD
[09:29:03 CEST] <rcombs> and encryption is useless if the other party is an impersonator
[09:29:15 CEST] <rcombs> sure, it protects against a purely-passive attacker
[09:29:22 CEST] <nevcairiel> you're downloading a media file =p
[09:29:35 CEST] <rcombs> but anyone in a network position to do passive snooping is also in a position to intercept your connection
[09:30:01 CEST] <rcombs> potentially on a private server with auth, potentially with private contents
[09:31:09 CEST] <rcombs> alternately, an attacker could modify the file to trigger a code-exec bug and pwn you (not like there's never been a code-exec bug in media code)
[09:31:42 CEST] <rcombs> fwiw opportunistic encryption (i.e. encryption without authentication) is a good thing when it doesn't produce a false sense of security
[09:32:53 CEST] <rcombs> meanwhile, if consumer code really cares about the current behavior, and doesn't care about verification& they can just as easily set verify to 0 in their code
[09:33:20 CEST] <rcombs> I'll yell at them if they do, but they can just as easily as I can add verify=1 to mine
[09:34:20 CEST] <nevcairiel> my point however stands, as long as I cant add a callback or w hatever that gives me cert information on  failure so i can ask the user, its practically unusable
[09:35:26 CEST] <rcombs> "verification failed and the user wants to skip it" is an extremely edgy case these days
[09:35:44 CEST] <rcombs> the only real reason you'd want to do that in 2017 is for debugging
[09:35:56 CEST] <rcombs> and if you're debugging you can set verify=0 yourself
[09:37:55 CEST] <rcombs> nevcairiel: would you be okay with a callback that runs synchronously during tls_open() and passes you an engine-specific pointer?
[09:38:38 CEST] <rcombs> (like, SSL* for OpenSSL, gnutls_session_t for GNUTLS, SSLContextRef for Secure Transport&)
[09:41:55 CEST] <nevcairiel> thats how curl handles this iirc, just gives you those structs. if you also tell it what the engine actually is, it could probably work
[09:42:09 CEST] <rcombs> that would be easy enough to do
[09:42:45 CEST] <rcombs> I don't think this should block on that, though, since anything that needs to disable verification can still do so
[09:44:38 CEST] <rcombs> (if I was going to build that, I'd want to work with a consumer that's using it, and do more testing)
[09:47:56 CEST] <nevcairiel> our use-case at work for that is that people host their media at home and may want to stream that on the go or wherever, you know, everyone offers this these days. Of course you want that encrypted, but because its a home connection they don't have a proper hostname and thus no proper certificate - to give us some security we exchange the fingerprint through our servers on a secure and verified channel, and do our own fingerprint 
[09:47:57 CEST] <nevcairiel> check on the certificate
[09:48:25 CEST] <rcombs> oh, we have that same use-case
[09:48:28 CEST] <rcombs> we just give them certs
[09:48:48 CEST] <nevcairiel> we thought about offering a dynamic-dns service with certs
[09:48:54 CEST] <nevcairiel> but thats too much right now
[09:49:22 CEST] <rcombs> you could use let's encrypt and wildcards, when those are available
[09:49:53 CEST] <rcombs> <IP with s/\./-/>.<user fingerprint>.<domain>
[09:50:31 CEST] <rcombs> but yeah, that sounds like a reasonable use-case for self-verification, sure
[09:51:24 CEST] <nevcairiel> to be honest by the time they would get to ffmpeg reading the media, our app would already have verified the cert, unless someone jumps in between right then and there
[09:51:28 CEST] <rcombs> that sounds like rather than having a callback on failure, you'd want a callback that runs instead of the default verification routine
[09:51:43 CEST] <rcombs> yeah, the trick would be to fingerprint lavf's TLS connections against your app's
[09:51:51 CEST] <rcombs> which is probably doable
[09:51:59 CEST] <nevcairiel> on failure works, as long as it lets me say "try again and ignore failure this time"
[09:52:19 CEST] <rcombs> wouldn't even necessarily have to be "try again"
[09:52:29 CEST] <rcombs> just "continue with the connection despite the failure"
[09:53:06 CEST] <rcombs> could implement it as a callback whose default is the default verification function, which is also available as public API
[09:53:28 CEST] <rcombs> and then if you want to do the default, and then do something else if it fails, you just call the default function first thing in your own handler
[09:57:02 CEST] <rcombs> nevcairiel: alternately you could provide your custom CA in the ca_path arg and set the custom domain in the host arg
[09:59:10 CEST] <rcombs> in other news: I was really surprised to find that https://wrong.host.badssl.com/ worked with verify=1 with tls_openssl
[09:59:36 CEST] <rcombs> turns out it verifies the root but not the leaf's subjectname
[09:59:52 CEST] <wbs> rcombs: because implementing that is a pretty large, nontrivial piece of code
[10:00:02 CEST] <rcombs> wbs: not in OpenSSL 1.1
[10:00:05 CEST] <wbs> (and as you noticed, they only recently got a function that does that for you)
[10:00:08 CEST] <wbs> exactly
[10:00:20 CEST] <wbs> our openssl code integration was written in 2011, long long before openssl 1.1
[10:00:29 CEST] <rcombs> yeah
[10:00:55 CEST] <wbs> and when I did our openssl code, I looked at how curl does it (it was like a 100+ line function, that just at the same time had a found vulnerability in hostname/cert parsing)
[10:01:13 CEST] <rcombs> fun!
[10:01:26 CEST] <rcombs> I also looked at that, actually
[10:01:53 CEST] <rcombs> briefly considered porting it but settled on the warning
[10:01:59 CEST] <wbs> it's pretty astonishing that openssl, given how widespread it is, hasn't provided that until now
[10:02:15 CEST] <rcombs> yeah that's a mess
[10:02:20 CEST] <JEEB> aye
[10:02:35 CEST] <wbs> because it's really nontrivial code to do right (an trivial case that handles the simplest ones would probably be pretty simple)
[10:03:19 CEST] <wbs> but then, doing a security relevant function intentionally half-assedly doesn't sound right either, then I rather don't pretend to do it at all (a warning telling the user about this, instead of a code comment, probably is smart) :P
[10:04:07 CEST] <rcombs> yeah, that's what I was thinking as well
[10:04:44 CEST] <rcombs> and then 1.1 handles it just fine, so that's solved for future
[10:05:13 CEST] <rcombs> how long until their relicense finishes and people can actually redistribute ffmpeg builds using it
[10:05:17 CEST] <rcombs> I wanna stop building GNUTLS
[10:05:49 CEST] <rcombs> (god building GNUTLS is a mess)
[10:06:10 CEST] <wbs> for client code, I don't mind gnutls, but for the server side of things (at least on older debian stables), openssl is the only usable thing
[10:06:45 CEST] <rcombs> I haven't looked at the APIs much; the build is just a mess
[10:07:01 CEST] <wbs> yeah
[10:07:11 CEST] <wbs> although openssl with their weird custom build system isn't too nice either
[10:07:20 CEST] <rcombs> true
[10:07:24 CEST] <rcombs> that's getting a bit better though
[10:08:55 CEST] <wm4> last time we heard about the relicensing, it made headlines by offending people with badly worded letters
[10:09:12 CEST] <rcombs> their CLA process is a mess
[10:09:34 CEST] <rcombs> it involves downloading a PDF, filling it out and signing it (in Preview Dot App), and emailing it back
[10:09:57 CEST] <wm4> there are simpler methods that aren't legally worse (apparently)
[10:10:25 CEST] <rcombs> yeah I get the feeling lawyers came up with this without asking any non-lawyers if it was a good idea
[10:10:39 CEST] <rcombs> and lawyers are used to deal with bullshit like that all day
[10:10:55 CEST] <rcombs> (or, their paralegals are, anyway)
[10:11:00 CEST] <wm4> lol
[10:13:02 CEST] <JEEB> yup
[10:13:11 CEST] <JEEB> sounds like "the usual process for lawyers"
[10:13:18 CEST] <JEEB> which for tech people is meh dot png
[10:13:44 CEST] <rcombs> at least they only want it once per person
[10:13:59 CEST] <rcombs> I could imagine lawyers wanting once per contribution
[13:45:37 CEST] <cone-534> ffmpeg 03Paul B Mahol 07master:16efcfe4138f: avfilter/vf_weave: fix top vs bottom field order
[13:54:20 CEST] <rcombs> what is with the MPEG people and size-size fields that are always completely useless because everybody just sets them to 4
[13:55:21 CEST] <JEEB> ah yes
[13:55:32 CEST] <JEEB> theoretical optimization :D
[14:24:47 CEST] <rcombs> wow
[14:24:57 CEST] <rcombs> I'm working on HEIF in lavf because I'm stupid
[14:25:04 CEST] <rcombs> and damn this is way overengineered
[14:25:17 CEST] <JEEB> yea
[14:25:53 CEST] <rcombs> it can split an image across multiple mdats because& why not, I guess?
[14:26:04 CEST] <rcombs> (why not is that that's stupid and unnecessarily complex)
[14:26:41 CEST] <rcombs> but this is MPEGshit so the words "unnecessarily complex" produce boners
[14:27:06 CEST] <wm4> commercial multimedia standards are designed to produce consultants
[14:27:21 CEST] <atomnuker> rcombs: does heif store jpegs as well?
[14:27:31 CEST] <wm4> maybe it's for incremental encoding/loading
[14:27:46 CEST] <rcombs> atomnuker: afaik that's not specced but there's no reason it couldn't if you defined an ID for it
[15:01:25 CEST] <BtbN> Interesting, that NDI video codec is lossy, but without generation-loss.
[15:01:45 CEST] <BtbN> So re-compressing the same video again and again will only reduce the quality once initially
[15:04:02 CEST] <kierank> BtbN: allegedly
[15:04:10 CEST] <kierank> but depends on their dct and their encoder
[15:04:13 CEST] <BtbN> that should be easy to prove?
[15:04:15 CEST] <kierank> vc-2 can do the same thing
[15:05:11 CEST] <niklob> Hello, I was trying to soft-embed srt subs as dvbsubs: ffmpeg -i in.mkv -i English.srt -c:v copy -c:a copy -c:s dvbsub out.mkv but I get "Application provided invalid, non monotonically increasing dts to muxer in stream 2: 3005830 >= 1670230 av_interleaved_write_frame(): Invalid argument"
[15:05:23 CEST] <niklob> I thought this was fixed: https://trac.ffmpeg.org/ticket/2024
[15:09:32 CEST] <niklob> it's ffmpeg version n3.0.7-2-gdffd455 von win10 x64 if it matters
[15:10:03 CEST] <BtbN> that's in bad need of an update.
[15:10:15 CEST] <BtbN> Also not really a -devel question.
[15:15:50 CEST] <niklob> sorry, I will try 3.3.3 now. Any advice in case it fails?
[15:17:47 CEST] <JEEB> the error says the reason. your input is borked. first there was a packet pushed into the output with a timestamp 3005830 , and then 1670230
[15:17:56 CEST] <JEEB> time is going backwards!
[15:29:41 CEST] <niklob> JEEB: those are miliseconds right? Because I looked in my srt file and it's not going backwards at anywhere near that marker
[15:31:13 CEST] <JEEB> that's in the output time base
[15:48:51 CEST] <ubitux> do we have a global init function somewhere?
[15:49:19 CEST] <nevcairiel> kind of, what do you want to init?
[15:49:48 CEST] <ubitux> global system configuration stuff somehow
[15:50:13 CEST] <ubitux> don't we have a global mutex initialized somewhere?
[15:51:21 CEST] <nevcairiel> we have the w32thread stuff that globally inits once when its used first, maybe you can follow that pattern?
[15:51:41 CEST] <nevcairiel> use pthread_once to init on first use
[15:51:51 CEST] <ubitux> mmh. i guess yeah. thanks
[15:52:37 CEST] <nevcairiel> in other news, nasm must surely be producing oddly shaped win32 object files, now it breaks even more msvc builds =p
[15:52:53 CEST] <JEEB> \o/
[15:54:06 CEST] <niklob> 3.3.3 did it. ty guys
[15:54:40 CEST] <wm4> ubitux: we don't add new global init stuff
[15:54:52 CEST] <wm4> <nevcairiel> we have the w32thread stuff that globally inits once when its used first, maybe you can follow that pattern? <- that's per source file
[15:58:26 CEST] <atomnuker> ubitux: av_register_all() (or the lavc-only one)?
[15:58:44 CEST] <ubitux> yeah, no ;)
[15:59:03 CEST] <ubitux> it's fine, i'll hack something, it's just a PoC
[16:57:54 CEST] <nevcairiel> jamrial: the static build failure was nasm, they must truely be producing odd object files. the audiomatch thing is a few single bit differences in the decoded audio, presumably using float for comparison is a bad idea? :)
[16:58:13 CEST] <jamrial> lol nasm
[17:00:09 CEST] <jamrial> honestly, if we can't even take advantage of the feature that allows dependency creation and assembly in one call, then maybe we should keep yasm as the default until avx512 code starts to land
[17:02:42 CEST] <nevcairiel> i switched it over to yasm anyway, cant really do anything for the audiomatch other then suggesting to use aac_fixed for decoding =p
[17:05:06 CEST] <ubitux> what's the nasm bug count up to now?
[17:05:33 CEST] <nevcairiel> they fixed the dependency thing upstream after wbs send a patch
[17:05:40 CEST] <nevcairiel> but unreleased of course
[17:06:16 CEST] <nevcairiel> it basically being broken with visual studio 2017 is still out there
[17:06:31 CEST] <ubitux> should i report that one? https://trac.ffmpeg.org/ticket/6516
[17:06:57 CEST] <nevcairiel> guess it wouldnt hurt
[17:06:57 CEST] <ubitux> or you know a related existing bug report?
[17:07:16 CEST] <nevcairiel> trying to slim down a minimal reproduction case for the vs2017 breakage is rather annoying
[17:18:02 CEST] <rcombs> BtbN: I just recently learned the same is true of JPEG
[17:18:38 CEST] <BtbN> really?
[17:18:48 CEST] <rcombs> yeah, at a given quantizer
[17:18:56 CEST] <BtbN> interesting
[17:19:13 CEST] <rcombs> "indempotent" is the term
[17:19:49 CEST] <rcombs> technically it's true at the block level, specifically; in theory an encoder could apply different quantizers on different blocks
[17:20:10 CEST] <rcombs> but most (all?) JPEG encoders just take your "quality" input and use it as the quantizer setting for the whole image
[17:20:56 CEST] <nevcairiel> jpeg defines how this quality value is to be used
[17:21:04 CEST] <nevcairiel> it scales the DCT table
[17:21:15 CEST] <wm4> does libavcodec's mjpeg encoder use this?
[17:24:50 CEST] <nevcairiel> no idea, its mpegvideo_enc, not going to find out
[17:34:23 CEST] <wm4> here be dragons
[17:34:50 CEST] <atomnuker> wat
[17:35:07 CEST] <wm4> https://en.wikipedia.org/wiki/Here_be_dragons
[17:35:49 CEST] <atomnuker> nah, I meant that surely at least one encoder besides mozjpeg is smart enough to do rdo
[17:42:31 CEST] <TD-Linux> rcombs, JPEG doesn't have any way to signal quantizers at different blocks. however you can use RDO to shift it
[17:55:57 CEST] <J_Darnley> Is the FFALIGN macro only able to align for power-of-2 values?
[17:56:55 CEST] <atomnuker> J_Darnley: nope, it works for everything
[17:56:57 CEST] <J_Darnley> Nevermind, I do have a power of 2 value
[18:02:57 CEST] <J_Darnley> Ah... of course, put_bit_count will return something much larger than expected with that change.
[18:07:51 CEST] <nevcairiel> atomnuker: i dont think FFALIGN works for anything but powers of two, or perhaps some sums of power of twos
[18:09:07 CEST] <nevcairiel> it uses bitmath after all, so if the binary representation of a-1 doesnt turn out to have a bunch of ones at the end, it wouldnt work
[18:09:32 CEST] <atomnuker> hm, you're right, I guess I misremembered
[19:25:16 CEST] <durandal_1707> kierank: how would lipsync work with noninteger framerates?
[19:28:18 CEST] <kierank> 1601, 1602 pattern
[19:28:41 CEST] <kierank> But afaik you can't do that in avfiltrr
[19:29:12 CEST] <durandal_1707> kierank: why?
[19:29:33 CEST] <durandal_1707> what is 1602 pattern?
[19:29:47 CEST] <kierank> There is a pattern which averages to 8008/5
[19:29:53 CEST] <kierank> The NTSC average
[19:30:11 CEST] <kierank> Because your click needs to be sample accurate but you don't know what the video generator is doing
[19:30:31 CEST] <kierank> You could set the click every n frames I guess
[19:30:34 CEST] <kierank> That's the easiest way
[19:34:05 CEST] <durandal_1707> kierank: i already filter that does av sync test
[19:34:19 CEST] <durandal_1707> *wrote
[19:34:36 CEST] <kierank> But it's not sample accurate for NTSC for example
[19:35:12 CEST] <kierank> But a bit of a niche use case
[19:35:51 CEST] <durandal_1707> its useful to fix av sync issues with hw and sw
[19:36:45 CEST] <durandal_1707> is there somewhere code that does this already?
[19:37:18 CEST] <kierank> No
[19:37:48 CEST] <kierank> Actually I think the issue isn't that big a deal
[19:37:56 CEST] <kierank> Ignore me
[19:38:21 CEST] <kierank> Ah I remember
[19:38:35 CEST] <kierank> I wanted to draw a box at the same time as a click
[19:38:44 CEST] <kierank> And I wasn't sure how to sync the two
[19:38:48 CEST] <kierank> That was it
[19:39:19 CEST] <J_Darnley> atomnuker: If you remember the specifics, to write a boolean in vc2enc can I just use "put_bits(pb, 1, bool)"?
[19:40:47 CEST] <atomnuker> J_Darnley: not if you have to write them golomb coded
[19:41:52 CEST] <J_Darnley> uh, I don't know.  I'm trying to write it in the transform_parameters header if that makes a difference.
[19:43:06 CEST] <J_Darnley> It does come after one of the uint writes.
[19:44:12 CEST] <atomnuker> yeah, to toggle between custom and non-custom things you use regular put_bits
[22:29:51 CEST] <J_Darnley> If you call avpriv_align_put_bits() do you need to call flush_put_bits() before calling put_bits_ptr() to get the right pointer?
[00:00:00 CEST] --- Thu Aug 17 2017