Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

December 2016

1 participants
62 discussions

ffmpeg-devel.log.20161130
by burek 01 Dec '16

01 Dec '16

[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/Doc… [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/40056982b032913e6eba1b64b5ddc5a776… [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/9459915534a6549b52ef61a655a43c84cf… [23:52:38 CET] <durandal_1707> see doc example [00:00:00 CET] --- Thu Dec 1 2016

1 0

ffmpeg.log.20161130
by burek 01 Dec '16

01 Dec '16

[00:23:23 CET] <kurufu> so what is the A-V: number in the command line when playing something back with ffplay? [00:40:28 CET] <DHE> audio time minus video time. sync/drift [00:45:05 CET] <Sashmo> does anyone know how to get around this error "There are not enough buffered video frames. Video may misbehave!" when trying to output video on decklink card? [00:46:39 CET] <Sashmo> it looks like its a cpu and core issue.... no matter what I use on threads, its maxing out one core on my 16 core setup.... Its a multi threading thing 100%.... any suggestions? [00:57:50 CET] <kurufu> And what does the 'fd=' part mean DHE ? [01:22:40 CET] <DHE> kuroro: huh? [01:23:25 CET] <kurufu> The number right after A-V, given as say "fd= 147" [01:23:44 CET] <kurufu> Looks like some people think its frames dropped? [02:16:57 CET] <thebombzen> kurufu: I think it's that. sometimes ffplay will drop frames even if the framerate is lower than the monitor refresh rate [02:19:14 CET] <kurufu> im just looking to understand what these cryptic letters and numbers mean. [02:19:23 CET] <kurufu> is it actually frames dropped? [02:21:05 CET] <kurufu> and if anyone happens to know what the "f=X/Y" portion happens to mean that would be swell. [02:23:05 CET] <DHE> this is ffplay? [02:23:16 CET] <DHE> oh you already said so [02:33:16 CET] <kurufu> Yes i did. [02:33:17 CET] <kurufu> and it i [02:33:19 CET] <kurufu> is* [02:39:53 CET] <jarred> When I try to concat two mov files, I'm getting a strange error "Could not find tag for codec prores in stream #0, codec not currently supported in container". Here's a gist: https://gist.github.com/Jarred-Sumner/a59179c54393d62a129a92d92b2ff5bb. What am I doing wrong? [02:40:03 CET] <jarred> I need to preserve transparency in the mov [03:18:54 CET] <c_14> jarred: -c copy is overriding -c:v qtrle [03:18:58 CET] <c_14> put -c:v qtrle after -c copy [03:20:27 CET] <jarred> c_14: Could not find tag for codec qtrle in stream #0, codec not currently supported in container [03:20:27 CET] <jarred> Could not write header for output file #0 (incorrect codec parameters ?): Invalid argument [03:21:01 CET] <jarred> is what it's saying now [03:22:00 CET] <c_14> use -f mov or rename mp4 to mov [03:24:52 CET] <jarred> c_14: [qtrle @ 0x7fa460019a00] Problem: pixel_ptr = -4, pixel_limit = 2741760 now :( [03:24:55 CET] <jarred> when renaming mp4 to mov [03:24:57 CET] <jarred> i will try -f mov [03:25:08 CET] <jarred> (same for -f mov) [03:26:21 CET] <c_14> hmm, no clue [03:42:30 CET] <thebombzen> jarred I'm getting a 404 for that gist [03:43:25 CET] <jarred> thebombzen: https://gist.github.com/Jarred-Sumner/a59179c54393d62a129a92d92b2ff5bb [03:43:27 CET] <jarred> did that work? [03:44:40 CET] <thebombzen> jarred if you're only copying one stream why use -c copy? [03:46:16 CET] <jarred> i want to merge two videos together [03:46:21 CET] <jarred> or, specifically, i want to append [03:48:19 CET] <thebombzen> not sure if prores supports stream-level concatenation, but can you use: ffmpeg -f concat -i files.txt -c copy -f mov output.mov [03:49:28 CET] <thebombzen> cause jarred if ffmpeg doesn't whine on the decoding side then that should work [03:49:57 CET] <jarred> will that preserve the alpha channel? [03:51:18 CET] <thebombzen> it should because you're not re-encoding [03:51:32 CET] <thebombzen> the encoded data will be the same [03:51:52 CET] <jarred> It worked but created a 7 minute long file https://gist.github.com/Jarred-Sumner/94005cd1e373d94bc1fecd4b88a9be06 [03:52:03 CET] <jarred> (for something that should've been 2 seconds) [03:53:23 CET] <thebombzen> what happens if you ffprobe the two files? what is the output of that? [03:53:49 CET] <thebombzen> also note this: [concat @ 0x7f8f25003400] Could not find codec parameters for stream 1 (Unknown: none): unknown codec [03:54:17 CET] <thebombzen> it's possible prores doesn't support stream-level concatenation. if that's true you'll have to use the concat demuxer. [03:56:03 CET] <jarred> okay i'll run ffprobe [03:56:41 CET] <jarred> thebombzen: https://gist.github.com/Jarred-Sumner/e53391805a15d3309fa25780a919fbc0 ffprobe [03:56:55 CET] <jarred> i tried using the concat demuxer and it didn't work either [03:57:28 CET] <thebombzen> so there's a data stream in each file [03:57:40 CET] <thebombzen> how do you expect to concatenate those? [03:57:52 CET] <thebombzen> there's no "obvious" way to do that. [04:03:58 CET] <thebombzen> because if you don't care about the data, you can do: ffmpeg -i first.mov -i second.mov -map 0:v -map 1:v -lavfi concat -c prores -f mov output.mov [04:04:07 CET] <thebombzen> although you might have to set the bitrate with -b:v [04:04:26 CET] <thebombzen> and yes, that'll preserve the alpha channel if ffmpeg can encode prores in the pixel format [04:04:52 CET] <thebombzen> if it cannot it'll automatically change the pixel format, and will print a warning, and the output won't have it. [04:05:32 CET] <thebombzen> the pixel format is yuva444p10le (notice the "a" in "yuva", that's the alpha channel) [04:21:23 CET] <relaxed> "ffmpeg -h encoder=prores" says it only supports yuv422p10le [04:24:04 CET] <relaxed> prores_ks supports yuva444p10le [04:27:29 CET] <jarred> i got it working [04:27:33 CET] <jarred> what i did was [04:27:46 CET] <jarred> convert it into an avi file using mencoder [04:27:57 CET] <jarred> then turn those avi files into webm (this is for playing on a website) with ffmpeg [06:01:57 CET] <nate> Is there a generic list of what formats ffmpeg will likely always support cross-platform? ie; MP4, webm, flv, etc [06:02:00 CET] <nate> *eg; [06:05:16 CET] <Filarius> i think you need check each build about what formats supported [06:06:44 CET] <nate> Hm, yeah was afraid of that. Writing a generic thumbnailer script, was trying to set a generic 'default' list of what ffmpeg would likely always support. MP4, webm and flv were the only ones that really came to mind though :P [06:07:02 CET] <nate> (ie; that package managers wouldn't remove from a standard ffmpeg compile) [06:10:14 CET] <nate> That asked, a more random question as I don't have an ffmpeg installed to test with at the moment (still writing the script based on documentation details), but what exactly does the ffmpeg binary 'return' if a thumbnail process was successful? [06:10:40 CET] <nate> I'm assuming with `-v fatal` set it'll just return the error string in case of a failure, but otherwise does it just return a 0/1 for false/true? [06:20:21 CET] <relaxed> nate: 0 = success [06:21:20 CET] <nate> Cool, thanks much :P [06:23:36 CET] <relaxed> ffmpeg has native support for all the formats you listed [06:24:48 CET] <nate> Yeah I figured as much, but I know sometimes package managers 'mess' with stuff, but I figured those three, at minimum, will likely always be safely there [06:25:06 CET] <nate> I just wanted to define a 'default' list in this script [08:28:08 CET] <thebombzen> nate: when in doubt, use matroska [08:28:41 CET] <nate> mkv too? o.O ffmpeg generally supports that out of the box? [08:28:50 CET] <thebombzen> why wouldn't it? [08:28:55 CET] <thebombzen> it's a free format [08:29:07 CET] <thebombzen> it's one of the more likely ones that would work [08:29:17 CET] <thebombzen> it's also a web standard now [08:29:20 CET] <nate> just also I guess uncommon to spot, so didn't think of it :P [08:29:41 CET] <thebombzen> it's not uncommon, but that depends on your uses [08:30:05 CET] <thebombzen> it's the most common thing I come across to be honest and I try to use it whenever I can [08:30:36 CET] <thebombzen> matroska essentially does everything I need it to and doesn't really have any liabilities. the only thing that should work better with FFmpeg is NUT, which is specifically an ffmpeg container. [08:30:47 CET] <thebombzen> although that won't work with anything not based on libavformat. [08:31:41 CET] <thebombzen> and ffmpeg supports it out of the box unless you disable it, which you would do if you want a very small build (embedded device?) but there's usually no reason to [08:32:08 CET] <thebombzen> also, webm IS matroska just so you know. so that also shouldn't surprise you. [08:32:37 CET] <thebombzen> webm is matroska with a few extra restrictions but all webm files are valid matroska files [08:55:32 CET] <retard> mkv is uncommon? [08:55:37 CET] <retard> it's everywhere [09:05:19 CET] <ritsuka> retard: I guess he meant uncommon in the professional video and distribution world [09:18:01 CET] <yong> Assuming an uncompressed source (16-bit, 44.1 KHz CD-RIP), how often could you re-encode AAC 320 kbit/s until the quality drops below a 128 kbit/s first-time encode? [09:20:22 CET] <thebombzen> yong: that depends on the source material [09:20:55 CET] <thebombzen> certain genres of music are much more compressible than others. metal will lose quality much faster than folkrock for example [09:21:35 CET] <thebombzen> if it's speech it'll take a lot of re-encodes. [09:22:10 CET] <thebombzen> it also depends on the encoder. some encoders are relative stronger at higher bitrates and some shine at lower bitrates [09:23:28 CET] <yong> thebombzen: In that case, assuming metal/electronic type music that isn't easily compressible. Although I'm surprised that it matters considering we're comparing two compressed audio files in the end. Also assuming the best high bit-rate encoder vs the best low bit-rate encode, they don't have to be the same. [09:24:01 CET] <thebombzen> as for the actual number of times? I have no idea cause I haven't done the test [09:24:08 CET] <thebombzen> I've had no reason to. [09:24:15 CET] <thebombzen> there's no reason you can't do this testing though. [09:24:38 CET] <yong> How'd you set this test up? I'm not sure I wanna trying actually hearing the difference^^ [09:24:46 CET] <yong> -ing [10:00:57 CET] <yong> thebombzen: Damn, the ffmpeg native aac encode makes it sound absolutely disgusting after 8 reencodes, wtf [10:01:18 CET] <thebombzen> well I mean, that is sort of what you get for encoding it eight times [10:01:36 CET] <thebombzen> and yea there's no claim that the native aac encoder is good. it's not "experimental" anymore but it's nowhere near good [10:02:13 CET] <thebombzen> if you want a libavcodec-based encoder then you could use libfdk_aac, but it's nonfree. you have to build it yourself from source and then compile ffmpeg yourself with --enable-nonfree. [10:02:25 CET] <thebombzen> alternatively you could use Nero's codec which is good but not that good. [10:03:01 CET] <thebombzen> and how would I set it up? use a program called "abx" for... surprise! abx testing. [10:03:23 CET] <thebombzen> it's in the AUR but I'm not sure how to get it on other distros [10:04:02 CET] <thebombzen> also why do you care about re-encode quality? it's not really a good metric for how good an encoder is. [10:04:28 CET] <thebombzen> the only reason to care would be if you're constantly re-encoding, but if that's true then you probably shouldn't be doing that. [10:06:10 CET] <thebombzen> however I'm not sure why you're using AAC so I can't recommend an alternative [10:06:33 CET] <thebombzen> cause if your goal is quality lossy codec, libopus is usually the best. [10:07:32 CET] <thebombzen> if you need it to be Quicktime compatible, try ALAC (Apple Lossless). it's supported by Apple and ffmpeg-based projects, and is 100% resilient to re-encodes. [10:08:24 CET] <thebombzen> for non-apple applications, FLAC is more versatile and slightly better. [10:08:33 CET] <thebombzen> but then again, why do you want to re-encode it eight times? [10:09:07 CET] <thebombzen> that's generally "not recommended" i.e. I mean well, "makes it sound absolutely disgusting" sums it up pretty well [12:33:07 CET] <mpsag> I started a video conversion process and it has the PID 12345. How do I get progress status information from this process? [12:45:09 CET] <relaxed> mpsag: which OS? [12:45:19 CET] <mpsag> Debian [12:46:18 CET] <relaxed> you con [12:46:30 CET] <relaxed> er, you can't see the console output? [12:48:06 CET] <mpsag> I could, but there are multiple video conversion processes running and I want to get the progress status of one of them [12:52:10 CET] <relaxed> You would have to script something to do that. [15:00:03 CET] <ikevin> can i use ffmpeg to test if a stream is working? [15:34:18 CET] <fred1807> can I use ffprobe to test is video is VP9 or not? [16:06:47 CET] <DHE> yes... ffprobe by itself prints out the same stream summary that ffmpeg does. with -show_* parameters it provides more technical and machine-readable output [17:58:15 CET] <persina> Is it possible to take a video and specify a new width while maintaining the original aspect ratio? [17:58:28 CET] <persina> ...or specify a new hieght... [21:02:05 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? [21:06:36 CET] <relaxed> persina: yes, read about the scale filter [21:07:01 CET] <relaxed> Mockarutan: pastebin.com your command and console output [21:11:52 CET] <Mockarutan> No, it's c++ [21:12:20 CET] <Mockarutan> Working on a render plugin for Unity. [21:12:48 CET] <Mockarutan> I can post the source code if you want [21:13:11 CET] <relaxed> pastebin your code and maybe someone can help [21:20:19 CET] <Mockarutan> http://pastebin.com/YZbD8kfd [00:00:00 CET] --- Thu Dec 1 2016

1 0