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

[burek]

[00:08:40 CET] <atomnuker> custom channel order? so codecs can just signal what the order is rather than reorder themselves? that'd be nicie
[00:08:43 CET] <atomnuker> *nice
[00:10:10 CET] <durandal_1707> that would need code that would do actual reorderring
[06:26:31 CET] <cone-177> ffmpeg 03Steven Liu 07master:cdbf8847ea97: avformat/hlsenc: remove duplicate operation at hls_write_header
[09:45:05 CET] <durandal_1707> so did I got any more comments about new channel layout API?
[10:19:27 CET] <pross> avcodec_decode_audio5?
[10:45:24 CET] <durandal_1707> no
[11:44:23 CET] <kurosu> pross, avcodec_decode_audio5.1, just to be confusing (ignore me)
[11:45:49 CET] <kurosu> (obviously 5_1, but being correct or relevant was not the point)
[11:52:08 CET] <pross> this change wont break existing tests, except for those codecs that are being upgraded to take advantage of the new abi/api?
[12:03:24 CET] <durandal_1707> pross: idea is to add new fields: int channel_order and int *channel_map instead of replacing channel_layout and channels with new struct
[12:04:17 CET] <durandal_1707> with new struct one would need to touch and modify more than 100 files
[12:12:41 CET] <pross> understood. seems reasonable, no objections here
[13:21:06 CET] <nevcairiel> I don't see how a new structure would require any of that, as long as its side by side with the old value. I don't like separate lose values that have to be interpreted together, and if we define a new API, it should be absolutely future proof
[13:22:54 CET] <durandal_1707> nevcairiel: using structure require touching all files that previously used old channels and channel layout
[13:24:38 CET] <atomnuker> durandal_1707: any patches anywhere
[13:25:10 CET] <atomnuker> and are you seriously adding a new decode function using the old-style api?
[13:25:18 CET] <durandal_1707> Vittorio patches: https://github.com/kodabb/libav/commit/c023b553e6ad6da5af6d0d4ff067ff844b2fcfac
[13:25:30 CET] <durandal_1707> atomnuker: no, that pross made up
[13:58:41 CET] <nevcairiel> durandal_1707: no it does not, just keep the old value as well and then fill the new one from that if the Decoder didn't use it. Voila only code that wants to use it has to
[14:03:33 CET] <nevcairiel> Two years time to eventually migrate all of it when the old one is removed. Also lazyness is no excuse for hacky api design
[14:33:19 CET] <durandal_1707> its not hacky, my approach is perfect
[14:34:42 CET] <atomnuker> I agree with nevcairiel
[14:34:45 CET] <JEEB> I wish you a happy christmas eve, but could you at least argument yourself since clearly some people think there are better ways of going around with it
[14:35:36 CET] <durandal_1707> you are perfect candidate to touch all those 500 files?
[14:36:08 CET] <JEEB> what?
[14:36:51 CET] <durandal_1707> to update to new ch_layout API
[14:39:31 CET] <atomnuker> can't we leave some wrapper layer to convert such that we won't have to touch all codecs?
[14:39:43 CET] <JEEB> ^ this is what was my 1st thought
[14:39:51 CET] <durandal_1707> and filters and demuxers and muxers
[14:41:07 CET] <durandal_1707> you can keep channel_layout and channels but ultimately you need conversion with ch_layout API
[14:57:33 CET] <durandal_1707> s
[15:02:42 CET] <durandal_1707> so you guys like ch_layout struct and want to use it instead of channels/channel_layout ?
[15:09:05 CET] <durandal_1707> ?
[15:16:31 CET] <durandal_1707> if not i will use my approach
[15:28:55 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:84d1adb118a7: avfilter/af_sofalizer: do not reduce LFE by 6dB
[15:28:56 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:3bc711a2675a: avfilter/af_headphone: do not reduce LFE gain too much
[16:34:15 CET] <nevcairiel> I like a comprehensive solution that is able to either represent anything imaginable, or is extensible in the future, and yet remains sane to use, not some quick and dirty thing for one or two usecases
[16:35:15 CET] <nevcairiel> In any case any API changes need to be discussed on the ML, and not I er Christmas when no one is around
[16:46:50 CET] <atomnuker> true, can't miss exclusive events in mmos
[16:52:07 CET] <durandal_1707> atomnuker: what events?
[16:53:28 CET] <durandal_1707> i will commit it ASAP!
[17:08:41 CET] <BradleyS> i'd pay a dollar to see that
[17:08:46 CET] Action: BradleyS runs
[17:50:02 CET] <kierank> durandal_1707: can you remove ndi
[17:52:30 CET] <durandal_1707> kierank: nope, I'm the leader of FFmpeg
[18:23:37 CET] <durandal_1707> should i keep 5.1(side) instead of 5.1(back) ?
[18:25:35 CET] <atomnuker> keep both? they're both common, with side being a standard and back being a common mistake
[18:26:27 CET] <durandal_1707> i will keep old behavior so fate stays green
[20:59:14 CET] <cone-636> ffmpeg 03Paul B Mahol 07master:d6fc20a3ba17: avfilter/af_surround: fix code indentation
[21:05:10 CET] <BradleyS> ^ that wasn't such a big change
[21:05:43 CET] <BradleyS> durandal_1707: are you going to push chaos or do i get my dollar back
[21:08:48 CET] <durandal_1707> BradleyS: it is on mailing list
[21:09:11 CET] <BradleyS> mailing list is not enough chaos
[21:10:14 CET] <BradleyS> o/ happy holidays
[21:10:44 CET] <durandal_1707> there are no holidays here, only hard work on ffmpeg
[21:12:15 CET] <BradleyS> as long as you enjoy it
[21:13:26 CET] Action: durandal_1707 only enjoys NAKing Carl patches
[21:43:06 CET] <JEEB> TIL SCTE-18 is just hard-coded PIDs
[21:43:12 CET] <JEEB> not even mentioned in the PMT
[21:44:19 CET] <kierank> JEEB: lol
[21:44:32 CET] <kierank> JEEB: aint got time for PMT during emergency
[21:46:55 CET] <JEEB> that kind of does make sense, although before re-reading the spec I did browse the PMT, and what I first thought was the SCTE-18 stream ended up being just HbbTV
[21:47:24 CET] <JEEB> although I would expect such emergency alerts getting retransmitted quite a few times
[21:49:35 CET] <JEEB> I think Japan has its own emergency alert system in broadcast, but I've never seen it action. it's always just broadcasters' own overlays on top of the video
[21:49:48 CET] <JEEB> that way there's no way some receiver isn't showing it
[22:17:01 CET] <cone-636> ffmpeg 03gxw 07master:f652c7a45c60: avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa
[22:21:16 CET] <cone-636> ffmpeg 03Rene Claus 07master:6a8cc8696339: avcodec/libvpxenc: add VP8/9 sharpness config option
[00:00:00 CET] --- Tue Dec 25 2018