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

[burek]

[00:09:34 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:94d3d98246fc: fate: update after addition of gray10 to lavc/raw
[00:22:49 CET] <michaelni> durandal_1707, thx
[00:23:59 CET] <cone-857> ffmpeg 03Andreas Cadhalpun 07master:c0175fa92b7e: idroqdec: fix leaking pkt on failure
[01:02:56 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:2475858889cd: avcodec/flac_parser: Update nb_headers_buffered
[01:16:31 CET] <cone-857> ffmpeg 03Michael Schenk 07master:18b94669372d: matroskadec: prevent access of elements after freeing
[02:23:47 CET] <cone-857> ffmpeg 03Andreas Cadhalpun 07master:2c908f22c2af: avidec: fix leaking extradata
[03:35:13 CET] <philipl> BtbN: yeah. I was waiting for you to review it :-)
[07:30:52 CET] <Timothy_Gu> philipl: so I've been tinkering with Docker again. The thing is, the tarball containing Coverity build tools is huge, so it's impractical to download it on every Travis CI run. OTOH, it requires security tokens in order to download the tools in the first place, so we can't rely on Docker Hub's automated builders to download and unpack the tarball for us without leaking the same token we use to submit
[07:30:54 CET] <Timothy_Gu> builds.
[07:33:08 CET] <Timothy_Gu> So right now the only option I can find is manually download the coverity tools, and manually build the Coverity image before pushing it to Docker Hub
[07:34:38 CET] <Timothy_Gu> I've put my current files here: https://github.com/TimothyGu/ffmpeg-coverity; you have to manually go to https://scan.coverity.com/download to download the tarball as "coverity_tools.tgz" and put the file in the ffmpeg-coverity directory, before `docker build -t ffmpeg/coverage .`
[07:37:09 CET] <Timothy_Gu> Another option is, we could find a way to pass the Coverity tools in the Travis CI host system into the container, but I don't know if that's technically possible right now
[07:57:33 CET] <Timothy_Gu> Okay turns out that the Travis CI addon just downloads the Coverity tools on-the-fly: https://travis-ci.org/TimothyGu/ffmpeg-coverity/builds/180002159#L254. I guess we can do the same, by building the Coverity image in Travis CI instead of pushing it to Docker Hub
[09:50:17 CET] <ubitux> is segmenter + encode + concat stiching supposed to work for audio or there are inherent limitations? (AAC here)
[10:27:42 CET] <Dark-Star> what would be needed to add another audio format to ffmpeg? I have a working decoder to WAV (as source code, ~1.5 KLOC) and tons of sample files. I'm tired of going the extra way to WAV before feeding everything to ffplay ;-)
[10:30:32 CET] <wm4> look at some simple audio decoder in ffmpeg?
[10:31:22 CET] <wm4> usually a source file in libavcodec/
[10:31:54 CET] <wm4> libavcodec/apedec.c for example
[10:32:08 CET] <wm4> and then you need to find all the other places where you have to add 1 or 2 lines of text
[10:32:44 CET] <Dark-Star> ok, so how big would the chances be of having that code upstreamed? are there any policies for inclusion (apart from coding conventions of course)
[10:36:40 CET] <wm4> if it's a codec that actually exists in the wild (or has a chance to be in the future), then I'd say very high?
[10:37:14 CET] <Dark-Star> yeah, it's a codec used extensively in a lot of PS3 games (similar to ADX which is already supported in ffmpeg)
[10:40:44 CET] <atomnuker> is the source code public somewhere?
[10:42:25 CET] <Dark-Star> there's a ZIP file from a japanese developer with the C++ source code on mediafire (the comments are in japanese though)
[10:42:45 CET] <Dark-Star> also, vgmstream has imported the decoder and it's in their github repo
[10:43:05 CET] <Dark-Star> https://github.com/kode54/vgmstream/blob/master/ext_libs/clHCA.c
[10:43:34 CET] <Dark-Star> and http://www.mediafire.com/file/858tqikj74qinw4/HCA_decoder.zip
[10:45:08 CET] <ElAngelo> http://trac.ffmpeg.org/ticket/5982
[10:45:13 CET] <ElAngelo> have a question on this ticket
[10:45:16 CET] <nevcairiel> well we cant just import random code without a license, so if anything it would need to be clarified what license the code is under
[10:45:22 CET] <ElAngelo> in the last comment it says 'Patch sent'
[10:45:26 CET] <ElAngelo> what does that mean?
[10:46:23 CET] <ElAngelo> there is a patch already developed? and if so, where would i be able to find this?
[10:46:52 CET] <wm4> Dark-Star: yeah, license is a problem
[10:47:03 CET] <j-b> 'morning
[10:47:15 CET] <Dark-Star> good point. vgmstream is bsd so it'd be problematic to import this into lgpl right?
[10:47:19 CET] <durandal_1707> Dark-Star: i have working code for hca but license is an issue
[10:47:47 CET] <nevcairiel> bsd is fine, but i see no mention of license in the original decoder
[10:48:03 CET] <nevcairiel> so what vgmstream did might be questionable unless they received permission from the author
[10:50:11 CET] <Dark-Star> hm, the original author probably wanted to keep a low profile because the code looks like he just reverse-engineered some (probably copyrighted) binary ;-)
[10:56:19 CET] <durandal_1707> try contact him?
[10:59:56 CET] <Dark-Star> as soon as I find out where this code comes from I can do that, yes :) he hasn't put in his name/handle/tag/mail anywhere in the source code
[11:42:34 CET] <cone-316> ffmpeg 03Michael Niedermayer 07master:8cbdaa4b01ef: ffserver: Add client requested urls to the status page
[11:43:56 CET] <kierank> J_Darnley: i guess you can push the h264 changes, no?
[12:01:08 CET] <J_Darnley> kierank: probably
[12:09:20 CET] <jya> does FFmpeg AAC decoder prime the first 2112 frames before returning the decoded PCM?
[12:13:18 CET] <jya> reason I ask is that doing wave -> aac -> wave appears to introduce silence on both ends
[12:42:41 CET] <cone-316> ffmpeg 03Philip Langdale 07master:27038693bb4a: avcodec/nvenc: Delay identification of underlying format of cuda frames
[12:42:42 CET] <cone-316> ffmpeg 03Miroslav SlugeH 07master:f2dd6aee80c5: avcodec/nvenc: always reduce DAR width and height
[12:42:43 CET] <cone-316> ffmpeg 03Miroslav SlugeH 07master:1d056dd855e4: avfilter/vf_scale_npp: move aspect ratio correction after av_frame_copy_props
[12:42:44 CET] <cone-316> ffmpeg 03Timo Rothenpieler 07master:88281a5256f0: avfilter/vf_scale_npp: check ff_set_common_formats return value
[12:42:45 CET] <cone-316> ffmpeg 03Timo Rothenpieler 07master:52773a2c68bd: avutil/hwcontext_cuda: check for missing pixel format
[12:42:46 CET] <cone-316> ffmpeg 03Timo Rothenpieler 07master:7dafb3a25a58: avfilter/vf_hwupload_cuda: fix potential leak
[12:42:47 CET] <cone-316> ffmpeg 03Timo Rothenpieler 07master:c2f3af57a5af: avcodec/nvenc: mark intentional fall through
[13:08:01 CET] <BtbN> philipl, have you done any work on the ffmpeg coverity thing yet? Otherwise I'd set up a repository to start off the Docker-Container.
[13:08:19 CET] <BtbN> Is there some documentation on how to run coverity testing?
[13:09:10 CET] <BtbN> michaelni, ^
[13:25:39 CET] <michaelni> BtbN, thats how i did run it (there are likely some recently added things that lack enables) http://pastebin.com/iKyCD43n
[13:26:44 CET] <BtbN> I'll start with a minimal configure line, and work up from there
[13:27:14 CET] <michaelni> please dont upload it if its incomplete otherwise issues will disappear i assume
[13:27:32 CET] <BtbN> I'll just setup a test-project for it
[13:32:51 CET] <BtbN> Where does cov-build come from?
[13:38:37 CET] <BtbN> Does it need the fate samples?
[13:55:43 CET] <michaelni> i think it doesnt
[13:56:13 CET] <BtbN> it's not run anyway, as it's just static analysis
[14:03:20 CET] <BtbN> The cov-build tool needs a license and login to download...?
[14:04:36 CET] <BtbN> https://github.com/oleg-nenashev/docker-coverity-scan-maven/blob/master/Dockerfile
[14:04:38 CET] <BtbN> looks like it
[14:04:46 CET] <BtbN> so a public Docker-Image for this is outright impossible
[14:06:17 CET] <JEEB> the free coverity service thing that cannot create reports by itself is freely available and just requires an identifier
[14:06:34 CET] <JEEB> the full cov-build with local reports etc costs moneys
[14:06:54 CET] <BtbN> But where do I download it?
[14:07:49 CET] <JEEB> you have to log in for the download but https://scan.coverity.com/users/sign_in
[14:07:56 CET] <BtbN> I am logged in
[14:08:06 CET] <JEEB> https://scan.coverity.com/download
[14:08:06 CET] <JEEB> then
[14:08:15 CET] <BtbN> "Admin access to at least one project is required to download the Coverity Build Tool."
[14:08:20 CET] <ElAngelo> is anyone working on a docker to build ffmpeg mingw builds? sounds like a prime candidate to dockerize?
[14:08:23 CET] <JEEB> it's supposed to work with travis tho
[14:08:40 CET] <BtbN> Travis supports secret variables tho
[14:08:41 CET] <JEEB> ElAngelo: look at videolan's docker images
[14:08:49 CET] <JEEB> BtbN: yes, of course the creds are gonna be secrets
[14:08:59 CET] <BtbN> So a public docker container is impossible
[14:09:01 CET] <JEEB> unless you want anyone to be able to push in requests
[14:09:08 CET] <JEEB> BtbN: I thought docker supports env vars?
[14:09:14 CET] <JEEB> so when you run it
[14:09:16 CET] <JEEB> you set an env var
[14:09:22 CET] <BtbN> Which would be publicly available for everyone then
[14:09:27 CET] <JEEB> really?
[14:09:35 CET] <BtbN> They get baked into the container
[14:09:40 CET] <JEEB> I'd think when you start it you could ask for a param or something
[14:10:01 CET] <JEEB> or the command you run in the container should then have it provided to itself
[14:10:24 CET] <BtbN> yes, but the commands and everything get baked into the container. So it's impossible to pre-install the tools
[14:10:31 CET] <ElAngelo> ghe?
[14:10:44 CET] <ElAngelo> you can quite some stuff with docker
[14:11:02 CET] Action: ElAngelo has some experience... might be able to help
[14:11:08 CET] <ElAngelo> if you tell me the problem
[14:12:18 CET] <JEEB> anyways, better to check if videolan already does it :P
[14:12:25 CET] <JEEB> they've made their own docker repo after all
[14:12:33 CET] <BtbN> But they don't run coverity
[14:12:41 CET] <BtbN> On these images, at least
[14:13:01 CET] <ElAngelo> is coverty build tool something you need to install?
[14:13:06 CET] <BtbN> of course it is
[14:13:18 CET] <BtbN> And aparently it includes credentials to upload the build
[14:13:41 CET] <BtbN> So a public docker image with it is impossible
[14:14:20 CET] <ElAngelo> no way to provide credentials at run time?
[14:14:30 CET] <BtbN> It needs credentials to _download_
[14:14:39 CET] <ElAngelo> ah to download the tool you mean
[14:14:54 CET] <BtbN> And the download you get is customized so it seems
[14:14:58 CET] <BtbN> to upload reports
[14:15:27 CET] <ElAngelo> there are some other docker containers out there that use coverty
[14:15:43 CET] <BtbN> like the one I just posted, which needs private credentials to just build.
[14:16:22 CET] <ElAngelo> could you download and run at runtime?
[14:16:29 CET] <ElAngelo> takes a long time to download?
[14:16:37 CET] <BtbN> Would defeat the purpose of a docker container.
[14:16:48 CET] <ElAngelo> a bit only
[14:17:05 CET] <ElAngelo> it still gives you the benefit of code as infrastructure
[14:19:37 CET] <BtbN> what?
[14:20:37 CET] <ElAngelo> i don't know what problem you are trying to solve. but if it's 'only' the problem that coverity is hard to set up and run consistently you can still fix that problem with a docker
[14:20:55 CET] <ElAngelo> if you're purely after speed of deployment then indeed you can't do it with a public image
[14:21:04 CET] <BtbN> no I can't, as making a public docker image with it would enable everyone to upload builds.
[14:21:10 CET] <ElAngelo> indeed
[14:21:46 CET] <ElAngelo> but if it's about providing a convenient docker image for other devs to run, it could still help you
[14:22:58 CET] <ElAngelo> on another topic... if a patch is proposed to the ffmpeg-devel mailing list how long does it take before it gets merged?
[14:34:12 CET] <wm4> ElAngelo: depends, can take as long as 5 minutes, or it can be forgotten and never applied
[14:44:31 CET] <BtbN> isn't AviSynth Windows-Only?
[14:44:41 CET] <BtbN> As it's enabled in that configure line in your paste, michaelni 
[14:47:38 CET] <ElAngelo> thnx wm4 
[14:49:20 CET] <RiCON> BtbN: there's avxsynth too
[14:49:51 CET] <RiCON> but avisynth should work in wine too, iirc
[14:52:23 CET] <michaelni> BtbN, theres some av?synth for linux, dont remember exactly though
[14:53:43 CET] <BtbN> Looks like it doesn't need any build time deps though?
[14:53:51 CET] <durandal_1707> don't use it, it eats little kids
[14:53:58 CET] <BtbN> it's for coverity testing
[14:54:06 CET] <wm4> ElAngelo: just be sure to ping the patch if nobody reacts
[14:54:06 CET] <RiCON> just loadlibrary/dlopen
[14:54:06 CET] <BtbN> it just needs to compile
[14:54:25 CET] <wm4> vapoursynth is the one you should use
[14:54:32 CET] <ElAngelo> wm4: will certainly do
[14:55:10 CET] <durandal_1707> wm4: nope, use the lavfi
[14:59:46 CET] <BtbN> wm4, I'm just looking for whatever it needs to build ffmpeg with it enabled
[14:59:55 CET] <BtbN> and it seems like, nothing is needed for that, as it's runtime-loaded
[15:00:10 CET] <J_Darnley> Oh lawd!  I really hate the cpp sometimes.
[15:01:56 CET] <BtbN> This is going to be one huge Docker-Container
[15:02:16 CET] <BtbN> Just because of all the deps
[15:03:05 CET] <durandal_1707>  J_Darnley : doing what with cpp?
[15:03:24 CET] <wm4> do you mean c++ of the pp
[15:03:29 CET] <wm4> s/of/or/
[15:03:39 CET] <J_Darnley> the preprocessor
[15:03:52 CET] <J_Darnley> The amount of indirection when defining functions in libavcodec/x86/h264dsp_init.c
[15:04:17 CET] <J_Darnley> I think the function I just wrote is already defined, I just need to assign it to the pointer.
[15:06:13 CET] <BtbN> Somehow just the list of dev-packages ffmpeg needs pulls in an entire unity desktop environment.
[15:06:44 CET] <J_Darnley> :)
[15:08:44 CET] <BtbN> --no-install-recommends seems like a good idea
[15:36:34 CET] <BtbN> Timothy_Gu, what's the preferred way to build this: https://github.com/TimothyGu/libilbc
[15:36:36 CET] <BtbN> cmake or autotools?
[16:01:26 CET] <philipl> BtbN: i built the image
[16:01:43 CET] <philipl> you found that or timothy told you about it
[16:01:46 CET] <philipl> ?
[16:02:11 CET] <BtbN> it's one of the first google hits
[16:04:09 CET] <J_Darnley> Can anyone tell me in what order I want the arguments for TRANSPOSE4x4W to swap rows into columns?
[16:06:21 CET] <philipl> so aounds like what you want to do is pull the image with dependencies from docker hub and then add the coverity tools as part of the travis job.
[16:06:48 CET] <philipl> is that what you guys decoded? it's hard to follow the conversation history.
[16:06:53 CET] <philipl> decided.
[16:08:41 CET] <BtbN> philipl, yes
[16:08:45 CET] <BtbN> seems like the best way
[16:08:52 CET] <BtbN> I'm setting up a script that does it
[16:10:51 CET] <J_Darnley> I think it should be: TRANSPOSE4x4W row1, row2, row3, row4, temp
[16:10:51 CET] <philipl> sounds good to me.
[16:18:23 CET] <BBB> J_Darnley: thats correct
[16:18:43 CET] <J_Darnley> Thanks.
[16:25:51 CET] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/40056982b032913e6eba1b64b5ddc5a776a0ca35
[16:26:01 CET] <philipl> That's the full command line that works with the image
[16:27:13 CET] <BtbN> https://github.com/BtbN/FFmpeg-Coverity/blob/master/Dockerfile that's the Dockerfile I came up with that contains all deps for the current coverity configure line
[16:29:45 CET] <philipl> Well, if you replace the 16.04 base with my image you'll get the additional dependencies I pulled in.
[16:31:06 CET] <philipl> and we can add the unpackaged stuff to that.
[16:31:50 CET] <BtbN> It shouldn't need the ppas, adding those makes the image large
[16:32:14 CET] <philipl> hmm? If the goal is maximum dependencies. they have to come from somewhere.
[16:32:23 CET] <philipl> the ppa definition is just a source.list file
[16:32:36 CET] <BtbN> but the tool to manage the PPAs pulls in half a desktop env
[16:33:03 CET] <philipl> Huh. I thought that was already getting pulled in
[16:33:15 CET] <philipl> We can hard-code the ppa repositories
[16:33:26 CET] <BtbN> No, software-properties-common has like 200 deps, entirely pointless
[16:33:41 CET] <BtbN> I'd rather just build those 1~2 packages manually
[16:34:13 CET] Action: durandal_1707 summons voters/reviewers
[16:34:54 CET] <BtbN> You also don't want to have multiple RUN commands for the apt stuff
[16:35:08 CET] <BtbN> you want it all in one, with cleanup in the end. saves several GB of the final image
[16:35:36 CET] <philipl> Well, if you're using add-apt-repository, it does need to be two passes.
[16:35:40 CET] <philipl> patches welcome? :-)
[16:35:50 CET] <BtbN> I'll combine the two dockerfiles
[16:39:35 CET] <philipl> in the weekend discussion, we concluded that we wanted a base image built outside of travis. If you want to do it all locally in the travis job, that's fine by me.
[16:39:48 CET] <BtbN> hm? No, that's a docker image.
[16:39:54 CET] <BtbN> With all the dependencies
[16:40:09 CET] <BtbN> and if you run it, it downloads the coverity build tools, latest ffmpeg, and does the coverity build
[16:43:30 CET] <philipl> oh, ok. i thought you were saying you were going to build your dockerfile in travis.
[16:43:58 CET] <BtbN> I'd like to embed the coverity tools too, but they seem to be some kind of secret
[16:44:14 CET] <BtbN> And embed the api key or something, so enable people to upload stuff
[17:11:13 CET] <durandal_1707> how to cast 'valid' vote in that ugly thread?
[17:13:19 CET] <jamrial> durandal_1707: you already did cast a valid vote
[17:13:48 CET] <nevcairiel> i told you he would find some pseudo-legal to somehow call it invalid
[17:22:53 CET] <Chloe[m]> so turingcodec doesn't have an incompatibility with macOS, it just doesnt work with clang, at all
[17:23:27 CET] <wm4> wow
[17:23:28 CET] <wm4> how
[17:23:35 CET] <JEEB> :D
[17:23:46 CET] <JEEB> should I try compiling it just to see how badly it abuses something?
[18:14:01 CET] <durandal_1707> Compn: do you have pixlet binary?
[18:31:29 CET] <kierank> durandal_1707: you can pull it from an apple update
[18:32:25 CET] <durandal_1707> what's that? I don't have Mac, just wine
[18:35:17 CET] <cone-316> ffmpeg 03Vittorio Giovara 07master:7010ebdf1ff7: mov: Evaluate the movie display matrix
[18:35:18 CET] <cone-316> ffmpeg 03Vittorio Giovara 07master:33f7f636ff15: ffprobe: Fix displaying side data list only
[18:35:19 CET] <cone-316> ffmpeg 03Vittorio Giovara 07master:115b834dcff0: fate: Add test for mov displaymatrix
[18:39:20 CET] <kierank> durandal_1707: there are downloadable apple security updates
[18:39:22 CET] <kierank> with the dll
[18:44:01 CET] <J_Darnley> Oh jeez!  I need to focus more on the small details.
[19:00:21 CET] <durandal_1707> kierank: have a link?
[19:01:28 CET] <kierank> durandal_1707: ask kostya
[19:01:47 CET] <kierank> can't find it at the moment
[19:01:52 CET] <kierank> if you have the name of the standard dll I could find it
[19:05:21 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg-Coverity/blob/master/Dockerfile that's the "final" Dockerfile I ended up with. Should have all the deps from both.
[19:10:16 CET] <philipl> BtbN: why not 16.10 base? The deps will be newer
[19:10:54 CET] <BtbN> so you don't need to worry about updating it that frequently
[19:11:39 CET] <philipl> In what sense?
[19:11:45 CET] <philipl> Changing the base is always a deliberate choice
[19:11:46 CET] <BtbN> 16.04 is LTS
[19:13:25 CET] <philipl> to be sure, but I'd expect us to want to switch to new distros to keep deps as modern as possible
[19:13:41 CET] <philipl> I wouldn't want to say on 16.04 until 18.04 comes out
[19:13:59 CET] <BtbN> hm
[19:14:07 CET] <BtbN> package names already differ between 16.04 and 16.10
[19:14:39 CET] <philipl> Not by much. you don't need to specify the libnpp ones at all on 16.10. nvidia-cuda-dev pulls them all in
[19:14:42 CET] <philipl> (and it's cuda 8)
[19:14:57 CET] <philipl> but anyway - you only support one distro at a time
[19:16:53 CET] <philipl> do you have a docker hub account? I'll add you to the org so you can re-point it at your Dockerfile
[19:17:55 CET] <BtbN> btbn
[19:18:16 CET] <BtbN> It's not done yet though. Need to figure out how to do the coverity stuff
[19:18:22 CET] <BtbN> as it won't let me download their tools
[19:44:18 CET] <philipl> I wonder if it's worth trying to copy from the travis VM as Timothy_Gu contemplated earlier
[19:46:45 CET] <BtbN> hm?
[19:46:49 CET] <BtbN> Copy the travis VM?
[19:46:58 CET] <BtbN> This is a two liner for travis
[19:47:03 CET] <BtbN> docker pull + docker run
[19:52:33 CET] <BtbN> docker run --env DL_TOKEN btbn/ffmpeg-coverity
[19:52:38 CET] <BtbN> is all it should need
[19:52:54 CET] <BtbN> with DL_TOKEN being the FFmpeg/FFmpeg token from the project settings
[19:53:00 CET] <BtbN> on coverity, that is
[19:57:19 CET] <philipl> BtbN: you said you can't download the tools.
[19:57:32 CET] <BtbN> yes, because you need to be project admin to do so
[19:57:52 CET] <philipl> Timothy_Gu was saying the travis VM (with the coverity add on turned on) has the tools. So COPY them from the VM into the docker container between pull and run
[19:58:12 CET] <BtbN> seems unneccesary
[19:58:18 CET] <BtbN> we need to token to upload stuff anyway
[19:58:20 CET] <philipl> If you can't download them on demand...
[19:58:23 CET] <BtbN> so might as well use it to download
[19:59:19 CET] <philipl> If it works, it works. Just a thought. Save time on download, etc.
[20:01:08 CET] <BtbN> can you PM me the FFmpeg token? It should be in the project settings.
[20:16:40 CET] <durandal_1707> michaelni: so there's no gbrp16 output support, why?
[20:18:34 CET] <Compn> durandal_1707 : apple pixlet? hmmm
[20:18:55 CET] <durandal_1707> yes
[20:19:18 CET] <Compn> i think its part of quicktime.qts isnt it 
[20:19:19 CET] <Compn> ?
[20:21:43 CET] <BBB> omg more colorspaces
[20:22:02 CET] <BBB> reminds me of https://xkcd.com/927/
[20:27:25 CET] <durandal_1707> Compn: nope
[20:39:25 CET] <j-b> Do we really need those colorspaces?
[20:39:44 CET] <BtbN> philipl, https://github.com/BtbN/FFmpeg-Coverity this should be it
[20:40:41 CET] <kierank> j-b: yes
[20:41:03 CET] <wm4> j-b: I assume they're directly from the h264 or hevc bitstream
[20:41:17 CET] <j-b> make me sad
[20:42:08 CET] <j-b> JEDEC P22 is from hevc bitstream?
[20:42:39 CET] <wm4> no clue
[20:42:46 CET] <jamrial_> it's defined in ISO/IEC 23001-8:2013/DCOR1
[20:42:59 CET] <wm4> but normally these enums are mapped to bitstream values which are allocated and defined by other standards
[20:43:13 CET] <wm4> and by mapped I mean using the same numeric values
[20:55:11 CET] <Mockarutan> Hi ppl, going mad here. Trying to encode h264 and AAC into mp4. 1mb bit rate on video, that works. Audio: 192kb, 48khz, AV_SAMPLE_FMT_FLTP. In VLC, It always just plays ~1 sec audio, like 1 image frame and nothing more. Interlaced with video or not... is this a weird compination or is it just my shit code?
[20:58:09 CET] <Compn> durandal_1707 : do you know what filename the codec binary uses? i cant find info on pixlet...
[20:58:22 CET] <Compn> durandal_1707 : also how do you know its not in quicktime.qts ?
[20:59:05 CET] <Compn> Mockarutan : ask in #ffmpeg , not here
[20:59:14 CET] <durandal_1707> Compn: qt doesn't plays it
[20:59:22 CET] <Compn> durandal_1707 : what ver qt ?
[21:00:00 CET] <durandal_1707> Compn: 7, latest for Windows
[21:00:56 CET] <Compn> hue hue hue
[21:01:03 CET] <Mockarutan> Compn: ohhh.. damit :P Sorry
[21:01:07 CET] <Compn> QuickTime 6.4, released on October 16, 2003
[21:01:12 CET] <Compn> Addition of the Apple Pixlet codec (only for Mac OS X v10.3 and later).
[21:01:23 CET] <Compn> according to wikipedia, quicktime never released pixlet codec for windows
[21:07:43 CET] <Compn> durandal_1707 : got any mac osx vms ?
[21:09:27 CET] <Compn> durandal_1707 : this wikipedia page also says osx only, https://en.wikipedia.org/wiki/Pixlet
[21:15:37 CET] <BtbN> philipl, export COV_EMAIL=... && export COV_TOKEN=... && docker pull btbn/ffmpeg-coverity && docker run --env COV_EMAIL --env COV_TOKEN btbn/ffmpeg-coverity
[21:15:41 CET] <BtbN> works
[21:16:07 CET] <BtbN> it just uploaded a new build, no idea if and when it's going to show up
[21:16:46 CET] <BtbN> COV_EMAIL and COV_TOKEN can be private travis environment variables, that leaves it with a two line build script.
[21:30:28 CET] <BtbN> Yeah, it worked
[21:31:15 CET] <atomnuker> coverity works again?
[21:31:27 CET] <BtbN> Well, kind of.
[21:31:35 CET] <BtbN> We have a working docker image for it now.
[21:31:43 CET] <BtbN> Running it on travis is trivial now
[21:31:48 CET] <BtbN> Or anywhere, really
[21:32:01 CET] <BtbN> Could also offer my machine to run it the 2~4 times a week it's allowed.
[21:41:12 CET] <philipl> BtbN: I got a result notification
[21:41:26 CET] <philipl> Timothy_Gu already got travis going. No reason not to use it.
[21:41:33 CET] <philipl> No need to depend on ad-hoc hardware
[21:41:50 CET] <BtbN> so we just create a coverity branch on the main ffmpeg repo, and let travis built that?
[21:42:21 CET] <philipl> Yeah, basically.
[21:43:08 CET] <philipl> No one reviewed my coverity tool change.
[21:43:35 CET] <BtbN> the zero alloc one?
[21:43:38 CET] <philipl> yeah
[21:43:49 CET] <BtbN> should be fine imo, but not my code
[21:46:13 CET] <philipl> So your docker hub email?
[21:46:20 CET] <philipl> Let's get this connected up
[21:46:36 CET] <BtbN> E-Mail? No idea. Username is just btbn
[21:46:41 CET] <philipl> Ok
[21:46:48 CET] <BtbN> let me look up the e-mail I used there
[21:47:35 CET] <philipl> I've added you
[21:48:15 CET] <philipl> So I'd say add your github repo and then redirect the docker repo to use it
[21:48:54 CET] <BtbN> It's impossible to change github repo
[21:49:11 CET] <BtbN> I'll just create a new one. build might be a bit confusing of a name anyway for the coverity image
[21:49:16 CET] <BtbN> What about just ffmpeg/coverity?
[21:50:21 CET] <philipl> sure.
[21:50:36 CET] <philipl> Especially as it's coverity specific.
[21:50:49 CET] <BtbN> It's still a huge image, btw
[21:50:52 CET] <BtbN> around 1GB
[21:50:53 CET] <philipl> in reality, we should have a base image without the script and then the second one that adds it
[21:51:02 CET] <philipl> that's dependencies for you.
[21:51:12 CET] <BtbN> that gigantic base image isn't usefull for anything else imo
[21:51:23 CET] <BtbN> For just using ffmpeg you want a way smaller one, without all the build deps
[21:51:24 CET] <philipl> If we start running FATE tests, it's useful for us
[21:51:52 CET] <BtbN> fate runs don't need all the -dev packages
[21:52:05 CET] <BtbN> cutting out at least a good 400MB of the image, if not more
[21:52:14 CET] <philipl> fair. Anyway, that's secondary.
[21:52:24 CET] <philipl> The coverity image is the important part for now
[21:52:31 CET] <BtbN> it's building now
[21:59:37 CET] <philipl> michaelni: are you ok with the coverity tool change?
[22:08:45 CET] <durandal_1707> Compn: it may be Mac binary
[22:08:45 CET] <michaelni> philipl, yes, you might want to fix the recently found issues first though / wait fr them to get fixed , but theres noting wrong with changing it before if you prefer
[22:10:26 CET] <BtbN> I think all the nvenc/cuda related ones are fixed
[22:10:42 CET] <BtbN> The one left is a false positive, where a fix is on the ML for
[22:12:38 CET] <Compn> durandal_1707 : have to ask mac person. 
[22:12:41 CET] <Compn> any mac people in here ?
[22:13:13 CET] <Compn> durandal_1707 : also i dunno if its ppc or if pixlet also works on intel macs...
[22:18:25 CET] Action: Compn asks mac friend for copy
[22:28:02 CET] <cone-869> ffmpeg 03Philip Langdale 07master:5eb68520635d: tools/coverity: Add models for av_mallocz and av_free
[22:28:07 CET] <durandal_1707> Compn: you are my only friend here 
[22:29:18 CET] <philipl> oh cute. It will rerun the last analysis against the new tool.
[22:29:21 CET] <philipl> no need for a new build
[22:30:11 CET] <cbsrobot_> durandal_1707: I have ApplePixletVideo.component if you need it
[22:30:49 CET] <durandal_1707> cbsrobot_: how big it is?
[22:31:21 CET] <cbsrobot_> durandal_1707: https://transfer.sh/2PTMD/applepixletvideo.component.zip
[22:31:37 CET] <cbsrobot_> 159kb
[22:38:36 CET] <durandal_1707> cbsrobot_: great, thanks, it is there
[22:39:41 CET] <cone-869> ffmpeg 03Andreas Cadhalpun 07master:0bd227e31ca7: tests: print errors from ffserver
[22:39:42 CET] <cone-869> ffmpeg 03Andreas Cadhalpun 07master:7f034a02cdcf: tests: drop -d option from ffserver invocation
[22:39:43 CET] <cone-869> ffmpeg 03Andreas Cadhalpun 07master:122190392b29: ffserver: use codec time_base for stream
[22:39:59 CET] <BtbN> philipl, hm?
[22:41:13 CET] <philipl> BtbN: when I uploaded the tool file to coverity it started rerunning the analysis of the build you uploaded
[22:41:26 CET] <BtbN> because it was 100% identical?
[22:41:48 CET] <philipl> because the tool file isn't part of the build. coverity builds it and uses it as part of the analysis.
[22:42:06 CET] <philipl> The copy in our git repo isn't actually used. You upload it directly to coverity
[22:42:28 CET] <BtbN> I'm not sure I understand what you mean
[22:42:45 CET] <philipl> You ran a coverity build, which uploaded to their webiste.
[22:42:53 CET] <philipl> We got notified that the scan had completed.
[22:42:58 CET] <BtbN> yes, to test the whole thing
[22:43:05 CET] <philipl> I then uploaded the new coverity.c to their webiste.
[22:43:17 CET] <BtbN> oh, you need to upload that?
[22:43:19 CET] <philipl> Now they are reanalysing your build with the new coverity.c
[22:43:20 CET] <philipl> yes.
[22:43:25 CET] <BtbN> didn't know that, yeah, now it makes sense
[22:43:33 CET] <durandal_1707> I absolutely hate swscale
[22:43:59 CET] <BtbN> keep in mind, ffmpeg only has 4 analyzes per week
[22:44:25 CET] <BtbN> so we're already at 3 now
[22:44:38 CET] <philipl> Well, the good news is that it didn't silence the false positive in ffmpeg_cuvid.c :-)
[22:45:12 CET] <philipl> It's not smart enough
[22:45:27 CET] <BtbN> it doesn't look like it's done yet
[22:46:14 CET] <BtbN> now it's done
[22:46:21 CET] <BtbN> it found 122 new ones
[22:46:44 CET] <philipl> Yeah. because the mem.h functions aren't all covered.
[22:46:46 CET] <philipl> I'm not surprised.
[22:47:19 CET] <BtbN> a _ton_ of incorrect deallocator used
[22:47:33 CET] <philipl> Yeah, because I marked av_free as a deallocator.
[22:47:43 CET] <philipl> but most of the allocators aren't covered yet.
[22:47:45 CET] <BtbN> so more allocation functions need to be marked
[22:47:52 CET] <philipl> yep
[22:48:03 CET] <Timothy_Gu> BtbN: tbh I don't even know if that works or not, but personally I prefer using autotools
[22:49:05 CET] <BtbN> I opted for cmake now, and it compiled
[22:49:29 CET] <BtbN> All it needs to do is make ffmpeg compile, for coverity
[22:49:30 CET] <philipl> I wonder if uploading a new tool file counts as a run
[22:49:48 CET] <BtbN> I'm quite sure it does
[22:49:57 CET] <Timothy_Gu> I just got 2 emails from Coverity today if it matters
[22:50:17 CET] <Timothy_Gu> and philipl I got a working travis configuration in https://github.com/TimothyGu/ffmpeg-coverity/blob/master/.travis.yml
[22:50:58 CET] <BtbN> "Storage is returned from allocation function av_mallocz. [Note: The source code implementation of the function has been overridden by a user model.]"
[22:50:59 CET] <Timothy_Gu> the secure env variable contains COVERITY_SCAN_TOKEN
[22:51:12 CET] <BtbN> so it does realize, but it's not smart enough to also realize it entered an impossible branch
[22:58:50 CET] <philipl> BtbN: sad panda.
[22:59:12 CET] <philipl> Timothy_Gu: you and BtbN will want to reconcile your work.
[23:00:31 CET] <Timothy_Gu> Most of our scripts are the same either way, but my script downloads the coverity tools outside the container
[23:01:36 CET] <Timothy_Gu> mine uses the ffmpeg/build image philipl made, but we can add the source installation to ffmpeg/build too
[23:01:56 CET] <Timothy_Gu> I guess it shouldn't be that hard to reconcile them
[23:02:13 CET] <BtbN> you basically just need to rename the variables in your travis script, and it will work
[23:02:18 CET] <BtbN> COV_EMAIL and COV_TOKEN
[23:02:29 CET] <BtbN> no need for the install part
[23:05:07 CET] <durandal_1707>  somebody make swscale rewrite startup
[23:12:32 CET] <J_Darnley> Did anyone have any final comments about my h264 assembly patches before I push?
[23:13:03 CET] <durandal_1707> yes, push it
[23:13:50 CET] <durandal_1707> fate covered all cases?
[23:14:46 CET] <J_Darnley> I think it does.  fate failed in development but now passes
[23:16:59 CET] <J_Darnley> git push origin 13d71c2:master --dry-run -v
[23:17:06 CET] <J_Darnley> wrong window
[23:17:52 CET] <cone-869> ffmpeg 03James Darnley 07master:815ea8c6ccf7: avcodec/h264: mmxext 4:2:2 chroma intra deblock/loop filter
[23:17:53 CET] <cone-869> ffmpeg 03James Darnley 07master:1dae7ffa0b11: avcodec/h264: mmx 4:2:2 idct add8 function
[23:17:54 CET] <cone-869> ffmpeg 03James Darnley 07master:13d71c28cc44: avcodec/h264: sse2 and avx 4:2:2 idct add8 10-bit functions
[23:20:36 CET] <J_Darnley> kierank: I finished the 10-bit chroma h filter, between 2.4 to 3.8 times faster
[23:21:14 CET] <kierank> Sweet
[23:22:17 CET] <durandal_1707> very little content is in that format ?
[23:22:17 CET] <kierank> That's probably 5% or so speedup then
[23:24:49 CET] <kierank> durandal_1707: we get a lot of stuff in 10-bit 4:2:2
[23:26:09 CET] <durandal_1707> huh, I don't :angry:
[23:26:28 CET] <Timothy_Gu> BtbN: the way i thought of it is that when I build the image once, I can execute it for multiple times (locally) w/o having to download it every single time, but yeah it doesn't really matter for Travis
[23:26:45 CET] <kierank> durandal_1707: that format is used on private satellite feeds
[23:26:49 CET] <BtbN> Timothy_Gu, you can still do exactly that
[23:26:52 CET] <BtbN> that's the idea
[23:27:02 CET] <BtbN> as ffmpeg itself is not part of the image, only all the dependencies
[23:27:11 CET] <Timothy_Gu> the Coverity tools, I meant
[23:27:39 CET] <BtbN> Those are a bit weird, as they seem to be half-confidential
[23:28:17 CET] <durandal_1707> kierank: not switching to something fancier/modern?
[23:28:26 CET] <kierank> durandal_1707: the feeds are interlaced
[23:28:33 CET] <durandal_1707> oops
[23:29:03 CET] <durandal_1707> no HD content?
[23:33:07 CET] <kierank> yes 1080i :)
[23:41:23 CET] <philipl> BtbN: adding av_realloc should remove the vast majority of the new false positives.
[23:41:57 CET] <jamrial_> durandal_1707: there you have a reason to add 10/12bit support to vf_tinterlace and vf_w3fdif :p
[23:42:10 CET] <BtbN> philipl, also seen av_strdup in there a couple times
[23:42:26 CET] <BtbN> or is that covered by that?
[23:42:36 CET] <philipl> Yes. strdup uses av_realloc internally
[23:44:37 CET] <BtbN> why though
[23:45:41 CET] <durandal_1707> jamrial: tinterlace is gpl, I avoid gpl
[23:46:52 CET] <BtbN> what's diffrent about av_realloc(NULL, len); from just a normal malloc?
[23:47:53 CET] <philipl> BtbN: why does av_strdup use it? no idea.
[23:47:58 CET] <philipl> but I'm glad it does.
[23:48:05 CET] <philipl> it would suck if we used malloc-family calls from everywhere.
[23:48:52 CET] <BtbN> well, it would use the av variant, of course
[23:49:04 CET] <nevcairiel> BtbN: technically you are not allowed to call realloc on a pointer allocated with malloc, although i dont think any common systems actually use that limitation
[23:49:34 CET] <nevcairiel> (more specifically, you are not allowed to realloc something allocated with memalign, which av_malloc can use)
[23:49:52 CET] <BtbN> so it uses realloc, to be able to realloc it again?
[23:50:04 CET] <nevcairiel> but like I said, i dont think any typical systems care for that limitation
[23:50:14 CET] <nevcairiel> probably.
[23:51:32 CET] <durandal_1707> jamrial_: weave filter can interlace highbitdepth already 
[23:52:00 CET] <philipl> https://github.com/philipl/FFmpeg/commit/9459915534a6549b52ef61a655a43c84cf9b2c65
[23:52:38 CET] <durandal_1707> see doc example
[00:00:00 CET] --- Thu Dec  1 2016