[01:43:02 CET] <cone-588> ffmpeg 03James Almer 07master:cc25529420e3: avcodec/libdav1d: update the API usage after upstream changes [03:09:03 CET] <cone-588> ffmpeg 03Lauri Kasanen 07master:46c5693ea3a9: swscale/output: Altivec-optimize yuv2plane1_8 [03:09:04 CET] <cone-588> ffmpeg 03Michael Niedermayer 07master:90ac0e5f29ba: avcodec/tiff: Limit filtering to decoded data [11:17:19 CET] <BtbN> Does lavf automatically re-configure filters when the input parameters, like size, change? [11:24:19 CET] <nevcairiel> no, dynamic changes are not supported [11:24:44 CET] <nevcairiel> it would usually insert a new scale filter to restore the original size, if necessary [11:25:23 CET] <BtbN> So the answer to that guy on trac is just a mere "That's not supported." [11:26:39 CET] <nevcairiel> i have no idea whats that about, but its safe to say that ffmpeg filtering with a video that changes resolution mid-playback is often not going to do what someone might want [11:26:53 CET] <nevcairiel> it usually works, but only by scaling stuff [11:26:59 CET] <BtbN> He has scale,hwupload,hwfilters,hwdownload [11:27:07 CET] <BtbN> and then at runtime changes parameters on the first scale [11:27:24 CET] <nevcairiel> yeah thats probably not really supported [11:28:25 CET] <nevcairiel> the majority of filters are not build for changing input parameters [11:28:34 CET] <BtbN> It should be fairly straight forward to add support to hwupload/hwdownload [11:29:02 CET] <BtbN> hwdownload would be trivial, and hwupload needs to monitor the frame size and pix_fmt and re-run config_props when they change [11:29:18 CET] <nevcairiel> or maybe not, because you need a new frame context and tell all following hw filters abouut the new frame context [11:29:30 CET] <nevcairiel> which is probably not something we can do right now [11:30:25 CET] <BtbN> true. All the filters would need the same kind of logic [11:30:45 CET] <BtbN> Makes me wonder if this couldn't be written once globally outside of the filters [11:34:03 CET] <BtbN> hwupload_cuda can probably be removed by now btw. [12:44:48 CET] <BtbN> I give up on this guy. Either he sends patches, or I don't care anymore. [12:54:26 CET] <durandal_1707> lol [12:57:17 CET] <BtbN> Also not sure if that empty paste is a track issue, a mistake on his end, or some kind of joke. [15:24:59 CET] <durandal_1707> BradleyS: is something with pcmdec patches wrong? [15:25:52 CET] <BradleyS> nope, just curious about any connected issues [15:26:35 CET] <BradleyS> aside, it would be good to cherry-pick https://git.ffmpeg.org/gitweb/ffmpeg.git/commitdiff/027f032bbce9bdf7bbec4066... [15:26:40 CET] <BradleyS> onto release/4.1 [15:26:56 CET] <BradleyS> handbrake needs that one, we'll patch for now [15:39:00 CET] <cone-468> ffmpeg 03Paul B Mahol 07release/4.1:fcffed470a52: avformat/movenc: fix size calculation in mov_write_eac3_tag() [15:39:00 CET] <cone-468> ffmpeg 03Paul B Mahol 07release/4.1:59e30c05d74e: avformat/movenc: get number of written bytes from bitstream writer [15:40:14 CET] <BradleyS> ty [18:38:54 CET] <durandal_1707> what was the reason we do not have pcm-dvd encoder? [19:10:51 CET] <kierank> jya: what was the link to reporting a page that doesn't work in firefox [19:49:29 CET] <philipl> BtbN: credit where credit is due, he did write a patch. [19:51:13 CET] <BtbN> I'm not sure about that patch though. Scaling to frames which have a way over-allocated buffer? Plus, with a hw_frames_ctx that reports a size that doesn't match the frames? [19:51:25 CET] <BtbN> That's asking for trouble [19:55:24 CET] <BtbN> Also, nvenc absolutely expects CUDA frames to be in a continous buffer [19:55:29 CET] <BtbN> this would 100% break it [20:51:19 CET] <durandal_1707> good luck with that guy, he will take you all exp [20:52:58 CET] <philipl> He's something special. [20:53:24 CET] <philipl> Sounds like he has it all sorted out. Maybe we have a new project leader. [20:54:28 CET] <durandal_1707> why mpeg muxer is full of hacks? [20:55:06 CET] <durandal_1707> for example it muxes pcm as pcm_dvd this is gross hack [20:55:41 CET] <durandal_1707> muxer should not do transcoding, who wrote this mess [20:55:57 CET] <philipl> Does it date back to pre-ffmpeg days... [20:58:40 CET] <durandal_1707> philipl: its very old, from 2003 [21:00:28 CET] <durandal_1707> i will remove direct PCM encoding, and it will use pcm-dvd encoder instead, if nobody is against [21:00:47 CET] <kierank> sure [21:00:48 CET] <kierank> remove hacks [21:00:59 CET] <philipl> Is there a command line compatibility issue? [21:01:17 CET] <durandal_1707> yes, but who cares [21:01:38 CET] <durandal_1707> basically pcm direct muxing will no longer work [21:02:18 CET] <philipl> I'm not personally affected, but doesn't command line behaviour fall under our major/minor compatibility contract? [21:02:45 CET] <philipl> (I guess it's also programmatic usage too) [21:03:31 CET] <philipl> I love getting rid of hacks too, so just wanted to point it out. [21:03:49 CET] <durandal_1707> i could leave pcm_s16be path but it looks like hack, so i rather not [21:04:56 CET] <atomnuker> what's wrong with the pcm_xxx encoders? [21:05:48 CET] <durandal_1707> atomnuker: mpeg muxers does not support directly pcm s16be [21:05:55 CET] <durandal_1707> they need header [21:08:33 CET] <atomnuker> can't it insert the header itself? [21:08:40 CET] <philipl> haha. [21:09:03 CET] <philipl> The circle is complete. [21:09:59 CET] <BtbN> I'm just gonna ignore him, no matter how valid some of the points might be, cba dealing with that shit. [21:11:15 CET] <philipl> Yeah. That attitude isn't productive. [21:12:44 CET] <BtbN> He's also wrong. His patch still uses data[0] and data[1], and never adjusts them. So sure, it might work in his special case, but it produces invalid frames. [21:18:11 CET] <philipl> I'm pretty sure he said he's not wrong, so that means he can't be wrong. [21:18:35 CET] <BtbN> true [23:09:28 CET] <cone-786> ffmpeg 03James Almer 07master:2ddaaaf59570: avcodec/libaomenc: increase the default bitrate [23:51:17 CET] <cone-786> ffmpeg 03Mark Harris 07master:01dc152a92d3: avformat/vivo: Don't log null value [23:51:18 CET] <cone-786> ffmpeg 03Mark Harris 07master:8108064043bf: avfilter/vf_chromashift: Fix mixed declaration and code [23:51:19 CET] <cone-786> ffmpeg 03Mark Harris 07master:4361293fcf59: avutil/mem: Fix invalid use of av_alloc_size [00:00:00 CET] --- Tue Nov 27 2018