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

[burek]

[01:50:13 CET] <cone-825> ffmpeg 03Shiyou Yin 07master:5c806d5b54a7: configure: enable mipsfpu for loongson platform.
[03:03:33 CET] <cone-825> ffmpeg 03Shiyou Yin 07master:5982614af1f5: avcodec/mips: [loongson] refine optimization in h264_chroma.
[03:03:34 CET] <cone-825> ffmpeg 03Michael Niedermayer 07master:7f22a4ebc978: avcodec/truemotion2rt: Fix rounding in input size check
[03:03:35 CET] <cone-825> ffmpeg 03Michael Niedermayer 07master:1a89ae1df858: avcodec/hevcdec: Check for overlapping slices
[14:10:48 CET] <atomnuker> BBB: having 8/10/12 bit object files and the ability to disable 12 bit considering its almost identical to 10 bit is indeed silly
[14:14:24 CET] <atomnuker> I think even having the option to disable high bit depth support is silly and would cause more problems for people who do it, but I'd let them find that out for themselves
[14:20:08 CET] <BBB> maybe we should reconsider allowing to disable certain bitdepths
[14:20:16 CET] <BBB> it was doable so we did it, but maybe that's not a good argument
[14:20:20 CET] <BBB> since even profile 0 has 10bit support
[14:22:17 CET] <atomnuker> storage space is cheap, and a megabyte more is a drop in the ocean compared to what browsers weight these days (their fault for shipping an entire OS)
[14:22:48 CET] <atomnuker> and given that youtube/netflix/et al want to have HDR which requires highbd browsers have to enable it anyway
[14:26:21 CET] <atomnuker> I can't think of anyone who'd have a good reason for disabling it except maybe embedded systems, but like I said storage space is cheap and they'd likely use hardware rather than software
[14:49:57 CET] <BBB> file a bug so we remember to remove it
[14:49:59 CET] <BBB> or send a patch
[19:38:43 CET] <durandal_1707> atomnuker: do you know reason why low-bitrate native opus decoding is worse than libopus one?
[19:40:40 CET] <atomnuker> eh? it should be better if anything
[19:41:16 CET] <atomnuker> is someone testing from on crappy 2.1 system where the lfe's contents are taken from both channels again?
[19:44:47 CET] <durandal_1707> https://0x0.st/sGaA.opus
[19:44:58 CET] <durandal_1707> atomnuker: ^
[19:59:17 CET] <cone-675> ffmpeg 03Paul B Mahol 07master:e9967822e412: avcodec: add PCM-DVD encoder
[19:59:17 CET] <cone-675> ffmpeg 03Paul B Mahol 07master:2a08faba8802: avformat/mpegenc: extend muxing PCM-DVD to other depths
[20:03:25 CET] <atomnuker> looks like sbr is messing it up, I can investigate
[20:04:48 CET] <atomnuker> have I mentioned how much I hate what the new opus rfc did or how opus has no proper specs?
[20:06:13 CET] <durandal_1707> no
[20:09:26 CET] <atomnuker> well, allow me to elaborate, you don't get to break decoding 4 years after the release and say "no no its not breaking, there are now 3 proper ways to decode a file!"
[20:10:16 CET] <atomnuker> the old "standard", the new one with the idiotic default of ignoring intensity stereo phase and the new one which does not ignore IS phase
[20:11:53 CET] <atomnuker> "standard" is in quote marks because giving a base64 encoded zip file of the reference implementation in an html is a spec is worse than libaom
[20:12:32 CET] <atomnuker> reference code is hard to understand, particularly with xiph's coding style, and not even having a rough guideline of what to do doesn't help when you have to RE the code
[20:12:36 CET] <nevcairiel> those foss people just cant make standards =p
[20:13:09 CET] <atomnuker> well the excuse I was given was that there was just not enough time to make a proper spec, but it could have been done after the fact
[20:13:31 CET] <atomnuker> and it would at least confirm and cement what the reference code does (properly or improperly)
[20:16:27 CET] <atomnuker> giving people code as a "stadnard" is no different than what all the codecs did in the 90's where the encoder itself was specified so you'd have no freedom to play with anything
[20:16:55 CET] <atomnuker> if we had to follow the opus "stadnard" to the dot we'd have to use their resampling code and their mdct
[21:10:34 CET] <BBB> "worse than libaom"
[21:10:39 CET] <BBB> I will remember that for life
[21:14:19 CET] <atomnuker> at least you got a spec with libaom roughly independent of the reference code so you could tell what in essence the reference did
[21:14:47 CET] <atomnuker> and you could point to it in case the reference deviated and get an answer which one is correct
[21:15:30 CET] <atomnuker> rather than just a vague "whatever the code dose is correct unless we say it isn't in a future version"
[21:16:17 CET] <atomnuker> or say "well its correct but so is this new way"
[21:17:10 CET] <atomnuker> having multiple ways to decode a file is very uncool
[21:18:12 CET] <atomnuker> if aom doesn't version 1.1 bitstreams that would be very uncool too but I think they will
[21:18:51 CET] <atomnuker> otoh you can't version opus streams because all packets are valid and there isn't even a single reserve bit
[21:20:09 CET] <atomnuker> well there is a way if you signal it in the padding between raw and ec bits, but then you'd need to define state
[21:20:56 CET] <iive> atomnuker, is there a way to know which of the 3 standard ways you should use with a given encode?
[21:21:07 CET] <atomnuker> nope, all methods are valid for all streams
[21:21:16 CET] Action: iive facepalms
[21:21:44 CET] <nevcairiel> is the "new" one worse for old files?
[21:23:19 CET] Action: iive quadruple facepalms https://static.tvtropes.org/pmwiki/pub/images/stephencolbertquadfacepalm_4937.jpg
[21:23:33 CET] <atomnuker> yes, I believe so, the sbr changes are better, but if you disable IS sign correction it'll be worse
[21:24:10 CET] <atomnuker> (btw the leftover padding bits would be better off used for fingerprinting the same way x264 does)
[21:24:47 CET] <atomnuker> it'll slightly violate the spec but any decoder would decode it fine, the same way x264 slightly violates the spec
[21:26:57 CET] <kierank> atomnuker: iirc x264 violates the non-normative note
[21:27:02 CET] <kierank> to play spec lawyer
[21:29:39 CET] <atomnuker> the rbsp_alignment_zero_bit is noted to be non-normatively zero?
[21:29:50 CET] <JEEB> kierank: btw I got my first TLV-based sample last week and I'm kind of filled with morbid curiosity still
[21:30:21 CET] <kierank> JEEB: tlv?
[21:30:32 CET] <JEEB> BT.1869 I think
[21:31:05 CET] <kierank> atomnuker: yes
[21:31:26 CET] <JEEB> and then you've got the thing that must not be named on top of IP over TLV
[21:31:35 CET] <kierank> JEEB: ah GSE?
[21:32:41 CET] <JEEB> http://livedoor.blogimg.jp/bs4k8k/imgs/1/3/132ab3d5.png
[21:32:51 CET] <kierank> oh dear lord
[21:32:54 CET] <kierank> that's fucking insane
[21:33:14 CET] <JEEB> yes, that's exactly why parsing that with a hex editor is such a bad activity for a sleepless night
[21:33:22 CET] <JEEB> you keep going "I don't believe someoen actually implemented this"
[21:33:51 CET] <JEEB> although I guess if you want to believe a receiver is a network interface I guess it makes sense on some level on the TLV/IP layer
[21:33:57 CET] <JEEB> what happens after that - less
[21:34:56 CET] <kierank> JEEB: main reason ofc is expiring mpegts patents
[21:35:00 CET] <kierank> so got to make it more insane
[21:35:07 CET] <JEEB> yes
[00:00:00 CET] --- Sun Dec  2 2018