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

[burek]

[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/027f032bbce9bdf7bbec40665b98590cade33416
[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