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

[burek]

[00:01:03 CEST] <blue_misfit> rcombs, yeah it works in VLC lol. Avid is writing the outputs fyi via "same as source" export when cutting mixed media sources
[00:03:37 CEST] <wm4> blue_misfit: does that use edit lists?
[00:03:48 CEST] <wm4> or is it a single track that changes codecs?
[00:03:58 CEST] <wm4> (not too familiar with mp4 structure)
[00:04:09 CEST] <blue_misfit> well, it's real mov, not mp4 ;)
[00:04:14 CEST] <blue_misfit> but yeah there is an edit list
[00:04:22 CEST] <blue_misfit> I can't really tell whether it describes the codec switch tho
[00:04:25 CEST] <blue_misfit> don't have the tools to tell
[00:04:37 CEST] <blue_misfit> premiere says "track contains 2 types of video" when you get properties for it
[00:05:39 CEST] <wm4> l-smash boxdumper could help
[00:07:54 CEST] <blue_misfit> wm4, good call
[00:08:02 CEST] <blue_misfit> I'll do taht next time I have access to the file or one like it
[00:39:09 CEST] <nevcairiel> wm4: i would be more worried about lavf surviving the switch of the codec in the same track, I agree that lavc should be left out of this
[01:11:18 CEST] <atomnuker> jamrial_: seems like the decoder API restructuring commit broke opus decoding for someone using the old API
[01:14:16 CEST] <atomnuker> (told him to update to the new API or submit a trac issue, I'm suspecting the issue might be on his side)
[01:15:09 CEST] <nevcairiel> i still use the old api and opus decodes fine
[01:19:43 CEST] <BBB> atomnuker: do you have any insights on how av1 standardization is progressing?
[01:25:10 CEST] <tmatth> BBB: last I heard, bitstream freeze for this fall?
[01:25:18 CEST] <kevmark> [17:42:47]  <fiberbaby>	https://www.ssllabs.com/ssltest/analyze.html?d=ffmpeg.org
[01:25:18 CEST] <kevmark> [17:42:54]  <fiberbaby>	https://blog.qualys.com/ssllabs/2017/04/05/ssl-labs-distrusts-wosign-and-startcom-certificates
[01:25:18 CEST] <kevmark> [17:43:04]  <fiberbaby>	how about using Let's Encrypt
[01:25:18 CEST] <kevmark> Not saying Let's Encrypt shouldn't be used but that "T" rating isn't worth very much when Chrome 60 and Firefox 53 doesn't complain at all about the current certificate
[01:26:34 CEST] <cone-148> ffmpeg 03Nedeljko Babic 07master:c8e7fc8d9ad7: MAINTAINERS: Add Manojkumar Bhosale for MIPS, remove myself.
[01:33:28 CEST] <kevmark> There's also this if Let's Encrypt is off the table. I've gotten a free open-source cert from them before. https://www.globalsign.com/en/ssl/ssl-open-source/
[01:43:04 CEST] <KGB> [13FFV1] 15dericed opened pull request #71: add iana considerations section (06master...06iana-considerations) 02https://git.io/vHi4n
[03:00:16 CEST] <rcombs> kevmark: I would not be surprised if Google and Mozilla moved towards untrusting existing certs, and they're already not trusting new ones (so this will have to be changed before renewal)
[03:01:07 CEST] <kevmark> rcombs, from StartCom?
[03:01:16 CEST] <rcombs> yes
[03:02:23 CEST] <kevmark> According to this https://security.googleblog.com/2016/10/distrusting-wosign-and-startcom.html the current cert on ffmpeg.org should be untrusted, but it's not. I'm guessing they walked back on the timeline?
[03:03:04 CEST] <kevmark> Oh, sorry, I didn't see the issue date on the cert
[03:03:53 CEST] <rcombs> if StartCom/WoSign are caught backdating any more certs they'll be purged immediately
[03:03:54 CEST] <kevmark> So it sounds like we'd have until our cert goes up in April 2018, which is pretty generous.
[03:04:12 CEST] <rcombs> and they've been caught doing just that in the past
[03:04:14 CEST] <kevmark> unless, they yep
[03:04:19 CEST] <rcombs> so I wouldn't call that timeframe "safe"
[03:04:24 CEST] <kevmark> Fair
[03:04:51 CEST] <kevmark> At least(?) ffmpeg.org isn't putting out HSTS
[03:05:08 CEST] <rcombs> (they've been given an ultimatum with heavy consequences, so they _probably_ won't, but it's no guarantee)
[03:05:56 CEST] <kevmark> Gotcha. Well as a FOSS project there'd by no issue getting a cert from a reputable provider (like GlobalSign) or just using LE
[03:07:39 CEST] <rcombs> yeah
[03:07:52 CEST] <rcombs> I'd lean towards LE with autorenew
[03:08:32 CEST] <KGB> [13FFV1] 15dericed opened pull request #72: extend intro and add summary of version history (06master...06expand-intro) 02https://git.io/vHi2i
[03:08:59 CEST] <kevmark> The problem I've personally experienced with LE's short expiry tickets is when using it with multiple services.
[03:10:44 CEST] <kevmark> I believe their tool for automating Apache/nginx deployments works very well but I've had to spend a lot of time creating glue shell scripts that copy the certs over to where they're needed elsewhere. Like mail
[03:11:21 CEST] <kevmark> I'm not sure how big of an issue that could be for ffmpeg.org but I'd just put my two cents in there
[03:11:43 CEST] <kevmark> s/short expiry tickets/short expiry certs
[03:12:14 CEST] <rcombs> well it's either write some shell scripts once, or do it manually every time expiry comes near
[03:12:48 CEST] <kevmark> Or, if you're like me, write some shell scripts once, test them, have them break in three months (somehow), and write them again
[03:12:54 CEST] <rcombs> hah
[03:13:39 CEST] <kevmark> When the site goes down three months later, people complaining about the cert being expired, and you thinking to yourself "damn it the script I wrote explicitly so this would never happened didn't work"
[03:14:48 CEST] <kevmark> Although I'm sure someone is working on getting it integrated into systemd as we speak. And that will solve all these problems.
[03:17:47 CEST] <rcombs> clearly
[05:01:31 CEST] <cone-141> ffmpeg 03Vittorio Giovara 07master:35c76f2e138b: vf_colorspace: Add support for smpte248 color primaries
[10:30:27 CEST] <kierank> blue_misfit: that's insane
[10:30:45 CEST] <JEEB> I wonder how it signals the switch within the same track
[10:34:25 CEST] <nevcairiel> there is probably some mov magic to indicate which sample the codec changes
[11:38:01 CEST] <durandal_1707> wm4: what you mean by directly loading coefficients? tge method i pick is most friendly to the user
[11:42:20 CEST] <kierank> Interesting, hevc software encode on macs
[11:42:28 CEST] <kierank> I wonder which hevc encoder they used
[11:42:41 CEST] <wm4> durandal_1707: nothing about this is user friendly...
[12:18:58 CEST] <durandal_1707> wm4: sorry but it cant be user friendly, thought once you set it up you can forget about it
[12:24:33 CEST] <wm4> "it cant be user friendly" that's quite a statement
[13:26:21 CEST] <durandal_1707> wm4: its very friendly, if you want dumb friendly then compile sofalizer
[13:27:54 CEST] <durandal_1707> one just loads files for each loudspeaker he wants to use and than he can forget it
[13:58:47 CEST] <durandal_1707> wm4: are you strictly against filter?
[13:59:19 CEST] <wm4> well, not strictly, but I don't think it's overly useful/usable
[14:05:40 CEST] <durandal_1707> just because it needs little complicated options
[14:06:00 CEST] <RiCON> as long as the examples are clear enough
[14:06:55 CEST] <durandal_1707> also im reclutant to apply libmysofa patch because library is buggy and only latest git master is working correctly
[16:45:59 CEST] <cone-462> ffmpeg 03Vittorio Giovara 07master:f7f60749e0c9: vf_colorspace: Add support for jedec p22 primaries
[17:37:57 CEST] <cone-462> ffmpeg 03Michael Niedermayer 07master:4e3ab1a5c12f: avcodec/ac3dec_fixed: Fix multiple runtime error: signed integer overflow: -39271008 * 59 cannot be represented in type 'int'
[17:37:58 CEST] <cone-462> ffmpeg 03Michael Niedermayer 07master:a3b5b60bdf45: avcodec/indeo4: Check remaining data in Pic hdr extension parsing code
[17:56:24 CEST] <hexianren> Hi, All,I would like to contribute to ffmpeg,but I don't know how.Could you allocate some easy job for me, and I will try my best to finish it. Thanks
[18:12:03 CEST] <durandal_1707> ok to push gremlin stuff?
[18:12:15 CEST] <tdjones> Is it intended for fate to fail if the encoder writes out to stdout? It seems like a mistake to disguise this as a functional error: "stddev: |6450.74 - 296| >= 30". I may just be misunderstanding the output from fate.
[18:22:40 CEST] <jamrial> hexianren: maybe look at https://trac.ffmpeg.org/report for bug reports and feature requests, or search for TODO and FIXME lines in the codebase
[18:22:49 CEST] <atomnuker> tdjones: yep, you can't write to stdout
[18:41:38 CEST] <nevcairiel> Logging should go to stderr
[18:42:33 CEST] <wm4> logging should use av_log
[19:08:27 CEST] <tdjones> I was just quickly testing something on a different machine and didn't want to change compile settings for debugging symbols
[19:09:29 CEST] <tdjones> Felt like there should've been a message about incorrectly outputting information rather than displaying it as if there was an error in the audio file output
[19:11:08 CEST] <tdjones> But I was mistaken
[20:05:07 CEST] <cslcm> Hi! Does anyone know if any progress has been made on a vp9_qsv encoder? 
[20:07:01 CEST] <kierank> i heard rumours about patches
[20:15:17 CEST] <atomnuker> durandal_1707: how do you produce the wav coefficient files?
[20:15:56 CEST] <durandal_1707> atomnuker: hrtf ones?
[20:16:54 CEST] <durandal_1707> they are recorded same way as room impulse response filters
[20:17:35 CEST] <durandal_1707> except subject is placed in special room wearing microphones in ears
[20:18:10 CEST] <durandal_1707> subject can be human or artificial head
[20:20:16 CEST] <atomnuker> no, I meant from existing formats (e.g. sofa files)
[20:21:47 CEST] <durandal_1707> from sofa they can be only extracted, each wav takes exactly one loudspeaker position
[20:22:27 CEST] <durandal_1707> there are other formats
[20:23:16 CEST] <durandal_1707> do you want to try specific sofa file with this filter?
[20:26:47 CEST] <atomnuker> no, I just think that you should add a small program to do that into e.g. ./tools/
[20:27:26 CEST] <atomnuker> also possibly for other filters which take coefficients as streams
[20:30:13 CEST] <cone-462> ffmpeg 03Aman Gupta 07master:a32a6b4201dc: lavc: add mpeg2 mediacodec decoder
[21:43:38 CEST] <J_Darnley> How many of you have built NASM releases from its Git repo?
[21:46:05 CEST] <J_Darnley> Well clearly what's in the git repo isn't the same as the release tarball because the tarball builds and the repo doesn't.
[21:46:12 CEST] <JEEB> hah :D
[21:56:33 CEST] <J_Darnley> Yes.  If anyone wants to build old nasm: grab the tarballs, don't use the repo
[21:56:52 CEST] <J_Darnley> I've now got 10 years of nasm releases to test with
[21:59:16 CEST] <BBB> are there examples of pull-interface filters?
[21:59:18 CEST] <BBB> in libavfilter
[22:03:01 CEST] <cone-462> ffmpeg 03Paul B Mahol 07master:2336c76b2246: avfilter/af_sofalizer: switch to libmysofa
[22:05:16 CEST] <durandal_1707> BBB: wut?
[22:06:17 CEST] <BBB> filters that request_frame their input pad instead of input being pushed into it using filter_Frame
[22:36:13 CEST] <J_Darnley> Does anyone think requiring nasm-2.11 from 2013-12-31 is too new?
[22:36:44 CEST] Action: J_Darnley goes to check yesterday's logs
[22:41:08 CEST] <TMM> hi all
[22:42:03 CEST] <TMM> I'm reverse engineering the two remaining unknown upcodes for the interplay MVE videos, and I got one of the opcodes completely working. (opcode 0x06 if anyone cares) I believe I have decoding of op 0x10 working too but I think I'm fucking something up with buffer flipping somehow
[22:42:50 CEST] <TMM> I've not yet implemented the features in ffmpeg as I found the code a little too daunting to learn it as well as the codec at the same time btw.
[22:43:44 CEST] <TMM> This is what the video playing now looks like: https://tmm.cx/nextcloud/s/vpKUOHsBwEvvOml
[22:44:02 CEST] <TMM> can someone with more knowledge of video codecs in general please have a look at it and tell me if they see something that is obvious?
[22:45:02 CEST] <TMM> if I copy the backbuffer to the front buffer with a flip then things look ALMOST correct
[22:45:09 CEST] <TMM> but then there's some other garbage that stays behind
[22:45:48 CEST] <TMM> it clearly has something to do with this if you look carefully at the beginning you see that the content of the background kind of blinks between the top 1/4 and the bottom 3/4
[23:13:20 CEST] <J_Darnley> Gramner: I'm applying the x86inc patches from x264.  Should AESNI imply any other instructions other than SSE4.2?
[23:14:10 CEST] <J_Darnley> Specifically on the "Add some aditional cpuflag relations" patch
[23:14:44 CEST] <J_Darnley> jamrial BBB: do you want to give your thoughts on that ^^
[23:15:37 CEST] <BBB> I feel like I may not be knowledgeable enough to answer that (?)
[23:15:50 CEST] <BBB> I would say probably not
[23:15:54 CEST] <BBB> but Im not sure
[23:16:06 CEST] <J_Darnley> understood
[23:16:08 CEST] <jamrial> J_Darnley: no, afaik there are cpus with aesni that don't have avx
[23:16:38 CEST] <J_Darnley> Yes there are: Celerons and Pentiums have no AVX
[23:16:55 CEST] <J_Darnley> New ones I mean
[23:19:14 CEST] <J_Darnley> Like this then: aesni implies sse42, avx implies aesni
[23:20:57 CEST] <J_Darnley> Maybe I should upstream the aesni define
[23:26:20 CEST] <rcombs> J_Darnley: I have some ancient patches for AESNI
[23:36:35 CEST] <jkqxz> J_Darnley:  Some platforms can disable AES-NI in the BIOS, so nothing can imply it.
[23:36:52 CEST] <Gramner> J_Darnley_ aesni should probably imply sse42, but avx does not imply aesni. there are cpus with avx but without aesni. I guess due to market segmentation bullshit reasons
[23:37:57 CEST] <TMM> if you want to be sure about that, libvirt has a very complete database of cpu flag combinations for various cpus
[23:39:07 CEST] <nevcairiel> we generally check for actual availability reported by the cpu, but the implied relationships are helpful to know to simplify checks
[23:40:32 CEST] <TMM> On Interplay MVE, I based my demuxer off of this document: https://multimedia.cx/interplay-mve.txt, it mentions "The rendering process keeps track of the most recent frame in a separate buffer, and uses this double-buffering technique in the common way for animation.  The current frame's data is used in the construction of the next frame." I took that to mean that we just have 2 buffers and I just flip them
[23:40:39 CEST] <TMM> is that a correct interpretation of that statement?
[23:40:51 CEST] <TMM> (the diassembly bears this out as far as I can see btw)
[23:41:35 CEST] <nevcairiel> that just describes typical simple inter coded images
[23:41:54 CEST] <TMM> I'm not sure what that means
[23:42:13 CEST] <nevcairiel> but in our world we wouldnt flip buffers, but just make new ones
[23:43:00 CEST] <TMM> it seems that the original player really just swaps two ddraw surfaces
[23:43:09 CEST] <TMM> and it draws direct to them
[23:43:49 CEST] <TMM> nevcairiel, would you be willing to look at this? https://tmm.cx/nextcloud/s/vpKUOHsBwEvvOml <-- this is what my player does now for the unknown 0x10 frameformat for mve
[23:44:26 CEST] <TMM> I'm like... 95% sure that the actual decoding of the frames is doing the exact same thing as the original player does, but something is obviously wrong :)
[23:44:58 CEST] <nevcairiel> i dont know anything about that format
[23:45:31 CEST] <TMM> I understand, but I was hoping that the pattern of artifacts may hint at a more generic misunderstanding of mine
[23:45:48 CEST] <TMM> I'm vaguely hoping someone here will just go "Oh, you're not doing X" or something 
[23:49:09 CEST] <J_Darnley> Gramner: oh great!
[23:49:25 CEST] <J_Darnley> jkqxz: that will change runtime detection
[23:49:37 CEST] <J_Darnley> this is compile time stuff
[23:51:59 CEST] <jamrial> rcombs: your aesni patches were all committed except the one that made the aes module use aesni, right?
[23:52:14 CEST] <nevcairiel> so the most useful one missing? =P
[23:52:20 CEST] <jamrial> yeah :p
[23:52:57 CEST] <jamrial> rcombs: in any case, J_Darnley is trying to import the avx512 changes from x264
[23:53:12 CEST] <rcombs> ah, avx512, fun
[23:53:17 CEST] <J_Darnley> I didn't get that far yet
[23:53:47 CEST] <nevcairiel> how many changes did x86inc accumulate again, i feel like we synced a bunch of them not too long ago
[23:54:19 CEST] <Gramner> quite a few recently actually
[23:54:30 CEST] <Gramner> although most are trivial
[23:54:48 CEST] <nevcairiel> only the 2017 changes missing
[23:54:51 CEST] <nevcairiel> shouldnt be that much
[23:54:52 CEST] <jamrial> i wonder if for avx512 we shouldn't try to go ahead with that aligment patchset in the ml to avoid making everything 64 byte aligned long before we even write the first avx512 function
[23:59:01 CEST] <TMM> nevcairiel, at least, based off of that line is my interpretation of just having 2 buffers and swapping them a way to implement this?
[23:59:59 CEST] <nevcairiel> if done incorrectly that might violate frame lifetime in avcodec
[00:00:00 CEST] --- Fri Jun  9 2017