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

Sat Apr 20 03:05:02 EEST 2019

[00:00:23 CEST] <JEEB> probably
[00:00:28 CEST] <mkver> One of those "via ffmpeg-devel" commits is mine (namely 18a851aca766ff8c7199c9e0c37d8fa642e41920).
[00:00:43 CEST] <mkver> Then it is time to change the email provider.
[00:01:57 CEST] <JEEB> yea, basically your name should be correct because the mailing list only rewrites the e-mail (and the "via xxx"), so at least that part should be OK
[00:02:19 CEST] <JEEB> of course it still was a mistake on part of whomever pushed. but most likely nobody expected the patches to come out like that
[00:02:35 CEST] <JEEB> then patchwork doing the name attribution incorrectly is another thing :D
[00:03:02 CEST] <JEEB> not sure if it actually also rewrites the patches if you try to get the patches from it
[00:03:14 CEST] <JEEB> if yes, then that's bad. I've sometimes used patchwork to curl | git am patches
[00:03:39 CEST] <mkver> Which (free) provider doesn't implement DMARC?
[00:22:58 CEST] <cone-741> ffmpeg 03Steven Liu 07master:608d5fd8b616: add tests/ref/fate/hls-segment-size for the fate test
[00:22:59 CEST] <cone-741> ffmpeg 03Steven Liu 07master:55619f30122e: rename hls_segment_filename in fate-hls-segment-size for fate
[01:15:07 CEST] <mkver> I have just found out that googlemail.com had a different DMARC policy than gmail.com. I thought googlemail was just an alias for gmail; apparently it's not so easy.
[01:15:38 CEST] <mkver> It's  v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:mailauth-reports at google.com for googlemail vs.  v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports at google.com for gmail.
[01:16:02 CEST] <mkver> Hopefully using @gmail will fix the problems in the future.
[01:17:32 CEST] <cone-741> ffmpeg 03Carl Eugen Hoyos 07master:96fc0cbfde24: tests: Add EXESUF to program calls.
[01:27:53 CEST] <BtbN> It affects it for a lot more servers than just googlemail.com
[01:28:04 CEST] <BtbN> google.com protonmail are the first ones that come up
[01:29:59 CEST] <cehoyos> I succeeded building and testing qsv on Windows but I wonder how this is supposed to work without the patch I just sent...
[01:32:18 CEST] <BtbN> You mean the EXECSUF for fate?
[01:32:46 CEST] <BtbN> That's a WSL specialty. Everywhere else you can just omit the .exe suffix and it'll run.
[01:33:29 CEST] <BtbN> oh, no, the mfx one, nvm
[01:34:01 CEST] <cehoyos> The mfx one, yes
[01:34:15 CEST] <BtbN> I remember that weird -llibmfx being there very intentionally for some horrid weird closed source version of the Media SDK
[01:34:21 CEST] <cehoyos> Although I also wonder why nobody ever used wsl for fate, I find it very useful
[01:34:44 CEST] <BtbN> Every other case is supposed to be covered by pkg_config
[01:34:45 CEST] <cehoyos> So there is another version of the same library that is called liblibmfx.a or similar?
[01:35:15 CEST] <BtbN> Pretty much, yes
[01:35:26 CEST] <cehoyos> Cool, where can I find it?
[01:35:40 CEST] <BtbN> Need to register with Intel and dig in their closed source media SDKs
[01:35:54 CEST] <cehoyos> I'll ask them to comment
[01:36:16 CEST] <BtbN> It's the issue of lib???.so -> ???.lib on Windows. But someone didn't pay attention and named the .lib lib???.lib
[01:36:20 CEST] <BtbN> so that's where that comes from
[01:40:40 CEST] <BtbN> See comment of 164e2773261451ef33c4616296ec5bebecff42af
[01:48:21 CEST] <cehoyos> BtbN: Thank you. I wonder how I am going to fix this for the "normal" case...
[01:50:23 CEST] <BtbN> Every other case should have a proper pkg-config file, you you probably just need to adjust your PKG_CONFIG_PATH?
[01:54:05 CEST] <cehoyos> I still need to see a toolchain for win32 that supports pkg-config by default
[01:54:44 CEST] <cehoyos> I don't like it, I use it if available but forcing users to install it when it is not needed still seems absurd to me.
[01:55:33 CEST] <cehoyos> Especially for a library like mfx that has exactly one constant dependency.
[04:29:46 CEST] <BBB> kierank: don't you ever sleep? :D
[04:29:54 CEST] <kierank> BBB: i'm in the usa
[04:30:01 CEST] <BBB> yay
[04:30:08 CEST] <BBB> east or west coast?
[04:30:12 CEST] <kierank> BBB: not really, it's hard to eat well in florida
[04:30:21 CEST] <BBB> ah
[04:30:21 CEST] <kierank> I saw my first vegetable for a week
[04:30:44 CEST] <kierank> was a joy to see broccoli on a plate
[04:30:46 CEST] <BBB> why wouldn't they say "we're adding chromecast support to prime video app" instead of "we're bringing prime video app to chromecast"
[04:31:13 CEST] <BBB> is my english so sub-standard?
[04:31:26 CEST] <kierank> BBB: chromecast doesn't have apps per-se
[04:31:41 CEST] <kierank> but yeah
[04:31:42 CEST] <kierank> oh 
[04:31:42 CEST] <BBB> exactly, so I have no idea what it means
[04:31:43 CEST] <kierank> hmm
[04:31:58 CEST] <kierank> I read it as you can cast to chromecast from the app
[04:32:18 CEST] <BBB> I want to read it that way, but it very specifically does not say that
[04:32:26 CEST] <BBB> that's why I said, it seems written by a marketing dude
[04:32:31 CEST] <kierank> I don't see what it can mean otherwise
[04:32:48 CEST] <kierank> but yeah maybe marking to make amazon sound more "dominant"
[04:33:07 CEST] <BBB> I could interpret it as "our prime video app player in your browser will allow casting to chromecast"
[04:33:20 CEST] <BBB> which would be incredibly underwhelming
[04:33:32 CEST] <kierank> I would be happy with that
[04:33:33 CEST] <BBB> but technically consistent with the message in the press release
[04:33:35 CEST] <kierank> that's better than nothing
[04:33:48 CEST] <BBB> we write all this software so we can get better than nothing
[04:34:05 CEST] <BBB> yeah, I know I still need dvd players, but hey, at least the dvd was encoded with x264
[04:34:23 CEST] <kierank> x264 blu-ray still (!) is a big deal
[04:34:46 CEST] <BBB> it's a big deal for blu-ray, but blu-ray still sucks
[04:34:56 CEST] <kierank> it's better quality than netflix
[04:35:00 CEST] <kierank> or all streaming
[04:35:10 CEST] <BBB> yes that's sadly true
[04:35:11 CEST] <kierank> and can't be revoked
[04:35:40 CEST] <BBB> I hope you're right and android app will support casting :)
[04:36:09 CEST] <BBB> we'll see "in the coming months"
[04:36:14 CEST] Action: BBB gonna sleep now
[04:36:19 CEST] <BBB> g'nite
[11:34:32 CEST] <durandal_1707> Nicolas George is full of shit, he thinks he is smartest asshole on planet, and have opinion about anything
[11:43:57 CEST] <j-b> durandal_1707: this is not a correct way to speak about anyone
[11:55:03 CEST] <ubitux> you just have to say "he's french", that's enough
[13:18:08 CEST] <BradleyS> it is better to upsample, do all processing, and then downsample, than to up/downsample for each audio filter
[13:19:35 CEST] <BradleyS> most quality audio plugins do both, if sample rate <= 48kHz, upsample+process+downsample, if > 48kHz only process
[13:20:18 CEST] <durandal_1707> yes, it is faster. Note this is different than resampling - which is basically interpolation
[13:20:21 CEST] <BradleyS> with multiple filters it makes sense to manually upsample and downsample before and after to limit the amount of sample rate changes
[13:21:21 CEST] <BradleyS> yes
[13:21:32 CEST] <BradleyS> just saying, paul is correct in this case
[13:22:08 CEST] <BradleyS> not sure what others' objections are about but it seems they might be applying video thinking to audio
[13:23:27 CEST] <BradleyS> patches look fine to me
[13:25:36 CEST] <BradleyS> it's not much different that processing 8-bit pixels in 32-bit, for instance
[13:25:47 CEST] <BradleyS> it's not about negotiation at all
[13:41:26 CEST] <cone-962> ffmpeg 03Gyan Doshi 07master:3bef1dab6e88: avutil/colorspace: add macros for RGB->YUV BT.709
[13:57:23 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:dd06f022b074: lavf/utils: Allow url credentials to contain a slash.
[13:59:10 CEST] <cone-962> ffmpeg 03Paul B Mahol 07master:78c8a765369d: avcodec/get_bits: unbreak get_bits_le() with cached reader
[14:02:24 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:53064e134ca6: lavc/alac: Make a variable unsigned.
[14:08:05 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:32215b21407e: lavf/vc1dec: Reduce probe score for streams with invalid frames.
[14:09:13 CEST] Action: BradleyS gives durandal_1707 a cookie
[14:20:59 CEST] <cone-962> ffmpeg 03Carl Eugen Hoyos 07master:a24a1523e8d7: lavu/hwcontext_d3d: Cast src pointers calling av_image_copy*().
[16:13:41 CEST] <cehoyos> nevcairiel: Is the new patch (with hostexesuf) ok? Tested with mingw64 and cl.exe from wsl.
[16:14:46 CEST] <nevcairiel> looks ok on first glance
[16:19:04 CEST] <cehoyos> nevcairiel: Thank you, I sent one more that I believe should be non-controversial, do you agree?
[16:19:57 CEST] <nevcairiel> probably also need the .exe in the cl_major_ver= line
[16:20:05 CEST] <cehoyos> The remaining issue is that out-of-tree builds need mklink run after configure, I wonder why configure overwrites a "src" symlink
[16:20:31 CEST] <cehoyos> fate fails for me with cl.exe 64bit, works with 32bit, but both work for you, right?
[16:21:01 CEST] <cehoyos> indeed
[16:21:13 CEST] <nevcairiel> there is a bug in fate that i sent a patch for that makes one test fail
[16:21:17 CEST] <nevcairiel> i should push that
[16:21:34 CEST] <nevcairiel> although its probably fine if you run on wsl anyway
[16:22:19 CEST] <cehoyos> Is that related to png or to mov/aac-fixed/rotate?
[16:22:24 CEST] <nevcairiel> apng
[16:22:42 CEST] <cehoyos> The problem I see is with the rotate-test that also tests aac wich outputs one different frame
[16:22:55 CEST] <cehoyos> I don't have zlib yet...
[16:23:19 CEST] <cehoyos> one different audio frame
[16:24:15 CEST] <cehoyos> Is it possible that I use a newer cl.exe than you?
[16:24:40 CEST] <nevcairiel> if you got vs2019, then i havent setup new stations for that yet
[16:24:46 CEST] <nevcairiel> if its 2017, i run the latest of that
[16:25:08 CEST] <cehoyos> I use vc2019
[16:25:11 CEST] <nevcairiel> 2019 only came out two weeks ago or so
[16:25:21 CEST] <cehoyos> Installed tonight...
[16:25:36 CEST] <cehoyos> Is it possible to uninstall the (huge) ide?
[16:25:59 CEST] <cone-962> ffmpeg 03Hendrik Leppkes 07master:a87774636b87: tests: don't include TARGET_PATH in the sample path needlessly
[16:26:11 CEST] <cehoyos> I chose "selected components" and only the compiler but it also installs the ide
[16:26:23 CEST] <nevcairiel> presumably its supposed to, but i dont know how to do it exactly
[16:26:32 CEST] <cehoyos> ok
[16:26:41 CEST] <JEEB> yea not sure the IDE is separately installable/uninstallable. mozilla and friends used to have scripts to archive just the compiler/SDK though
[16:27:19 CEST] <cehoyos> Does building from a separate directory work with msys?
[16:27:43 CEST] <nevcairiel> it also works with msvc, my fate boxes all do it
[16:27:43 CEST] <cehoyos> I mean out-of-tree builds
[16:27:50 CEST] <JEEB> yea, out of tree should work
[16:27:58 CEST] <cehoyos> you mean it works with msys and msvc, no?
[16:28:06 CEST] <nevcairiel> but the detection to not do a symlink my fail on wsl
[16:28:10 CEST] <nevcairiel> may*
[16:28:11 CEST] <JEEB> ah
[16:28:17 CEST] <cehoyos> as opposed to wsl and msvc
[16:28:34 CEST] <JEEB> well, at least it should be relatively easy to check if the result seems sane?
[16:28:37 CEST] <nevcairiel> indeed
[16:28:42 CEST] <cehoyos> I need a symlink: The full paths are completely incompatible
[16:28:54 CEST] <cehoyos> Windows "mklink" makes symlinks that work fine in wsl
[16:29:30 CEST] <cehoyos> wsl does not understand "C:\"
[16:29:40 CEST] <nevcairiel> this is true
[16:30:12 CEST] <cehoyos> But everything works fine if I run configure and then make a symlink with mklink
[16:30:28 CEST] <cehoyos> I just believe that if such a symlink exists, configure should not delete it
[16:32:11 CEST] <nevcairiel> i actually have vs2019 installed here locally for testing, lets see what happens in fate
[16:35:08 CEST] <cehoyos> Please!
[16:35:29 CEST] <nevcairiel> didnt really get around to testing it much yet the last two weeks
[16:35:40 CEST] <cehoyos> fate-filter-meta-4560-rotate0
[16:35:48 CEST] <cehoyos> is the test that fails with 64bit here
[16:40:20 CEST] <nevcairiel> i get that too
[16:48:04 CEST] <nevcairiel> only one audio frame being different is a bit weird, if it were to miscompile one would expect more then one error like that, and its not even floating point to generate inaccuracies there. but then, the aac fixed point decoder is rather hacky in various places, so who knows
[17:35:39 CEST] <cone-962> ffmpeg 03Andreas Hakon 07master:e750dc9de61b: libavformat: improve logs with cur_dts
[18:06:56 CEST] <cehoyos> nevcairiel: Thank you for the confirmation, I had similar thoughts...
[18:25:55 CEST] <cone-962> ffmpeg 03Dan Sanders 07master:fac761dae927: avformat/apetag: tag values are unsigned
[19:50:45 CEST] <JEEB> +This protocol provides most functionalities of the UDP protocol RTMFP :
[19:50:45 CEST] <JEEB> +unicast, direct p2p and multicast (via NetGroup).
[19:50:53 CEST] <JEEB> is this the zombie of RTMP going around?
[19:51:11 CEST] <JEEB> or I guess this is something new with a name resembling Adobe's still-walking zombie protocol
[20:33:46 CEST] <mkver> Can someone please confirm that my mails sent via gmail (the two sent today) are actually working properly and are not munged with "via ffmpeg-devel"?
[20:34:04 CEST] <JEEB> mkver: which thread?
[20:34:21 CEST] <mkver> E.g. this email: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-April/242818.html
[20:34:39 CEST] <JEEB> yea, that is how it was received
[20:35:08 CEST] <JEEB> think the via things get munged at a point before writing them onto the pipermail
[20:35:30 CEST] <JEEB> or maybe not
[20:35:36 CEST] <mkver> Good. Then I can now resend the munged patches.
[20:35:57 CEST] <JEEB> just trying to figure out if there were any munged mails from your name on the pipermail
[20:36:47 CEST] <JEEB> and yes, that mail you linked in my mail client shows up without the via ...
[20:36:50 CEST] <JEEB> thing
[20:36:53 CEST] <mkver> All mails on the mailing list archive are ok; but apparently those sent to other subscribers of the list were not.
[20:37:16 CEST] <mkver> And patchwork is affected, too.
[20:38:00 CEST] <JEEB> yeh, my (gmail) interface shows it as coming from your e-mail
[20:39:34 CEST] <mkver> Good. Thanks for the confirmation.
[21:10:19 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:837820f385af: avcodec/diracdec: Use 64bit in intermediate of global motion vector field generation
[21:10:20 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:110dce963315: avcodec/ivi: Move buffer/block end check to caller of ivi_dc_transform()
[21:10:21 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:bcf9d2a17242: avcodec/wmv2dec: Check that the P frame secondary header fit in the input
[21:10:22 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:3ed360ea5cba: avcodec/pictordec: avoid pointers in picmemset()
[21:10:23 CEST] <cone-962> ffmpeg 03Michael Niedermayer 07master:838710bd6c5f: avcodec/pictordec: Only recalculate d when y changes in picmemset()
[22:14:45 CEST] <durandal_1707> cehoyos: you are back!
[22:21:02 CEST] <cehoyos> Correct
[00:00:00 CEST] --- Sat Apr 20 2019