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

[burek]

[02:58:04 CEST] <thardin> pross: kostya wrote about your vp4 efforts
[02:58:52 CEST] <thardin> https://codecs.multimedia.cx/2019/05/vp3-vp6-the-golden-frame-age-of-duck-codecs/
[05:10:37 CEST] <pross> thardin: hey cool
[13:08:45 CEST] <cone-851> ffmpeg 03Derek Buitenhuis 07master:80757bed89c3: avcodec/libx265: Support full range videos
[14:44:21 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:a9fa6b8e025c: swresample/swresample: check for invalid sample rates
[16:44:06 CEST] <durandal_1707> hi!
[17:14:54 CEST] <cone-851> ffmpeg 03Paul B Mahol 07master:fc0de1c04be4: avfilter/avf_showfreqs: switch to activate
[17:54:20 CEST] <kierank> durandal_1707: you should write in rust
[21:05:33 CEST] <cone-150> ffmpeg 03Shiyou Yin 07master:6b67daa326f6: avcodec/mips: [loongson] fix mpeg4 decoding error on loongson platform.
[23:06:09 CEST] Action: InTheWings looking for AC-4 samples (isobmff preferred)
[23:06:20 CEST] <JEEB> DASH-IF?
[23:06:36 CEST] <InTheWings> If that's Living Room 720p, it's not correct
[23:06:45 CEST] <InTheWings> at least, it does not match the ETSI spec
[23:06:58 CEST] <InTheWings> dsi version being 0
[23:06:59 CEST] <JEEB> not sure which it is, but I just remember the DASH-IF sample collection having AC-4
[23:07:02 CEST] <JEEB> :<
[23:07:05 CEST] <JEEB> but too bad if it's derp'd
[23:07:09 CEST] <InTheWings> that's this one
[23:07:29 CEST] <JEEB> http://testassets.dashif.org/#feature/details/586fb3879ae9045678eab593
[23:07:36 CEST] <JEEB> this btw
[23:08:32 CEST] <Lynne> https://0x0.st/zAdN.ac4 https://0x0.st/zAdq.mp4 <- these were 2 of the used to write the yet-unmerged decoder
[23:09:43 CEST] <InTheWings> Lynne: okay so there's an issue also there
[23:10:21 CEST] <InTheWings> E.5.1 AC4SpecificBox
[23:10:35 CEST] <InTheWings> ie dac4
[23:10:53 CEST] <InTheWings> first 3 bits are ac4_dsi_version;
[23:11:09 CEST] <InTheWings> This field indicates the version of the DSI. For a DSI that conforms to the present document, the ac4_dsi_version field shall be set to '001'. 
[23:11:31 CEST] <InTheWings> all isobmff have 0 on first bytet
[23:12:46 CEST] <Lynne> so they're improperly contained in mp4?
[23:12:51 CEST] <JEEB> yea
[23:15:01 CEST] <InTheWings> hmm..
[23:15:09 CEST] <InTheWings> 2018 spec doesn't says 001
[23:15:26 CEST] <JEEB> funky
[23:17:43 CEST] <durandal11707> InTheWings: you are wrong
[23:17:47 CEST] <InTheWings> lol, Part 1 of the spec says 000
[23:18:35 CEST] <InTheWings> durandal11707: possible
[23:18:49 CEST] <InTheWings> but the 2015 02 spec says 001
[23:22:41 CEST] <durandal11707> you are reading most significant or least significant bits first?
[23:23:20 CEST] <InTheWings> most
[23:23:57 CEST] <InTheWings> so the 1 has been removed from part 02 in 2018 revision
[23:25:00 CEST] <durandal11707> the mp4 stuff is not used by decoder at all
[23:26:03 CEST] <InTheWings> But when you have 2 part of the spec defining the really same AC4SpecificBox without the same values...
[23:26:22 CEST] <InTheWings> Part 2 still says to set it to 1 on encoding
[23:26:38 CEST] <durandal11707> isnt part about object audio?
[23:26:53 CEST] <InTheWings> no idea
[23:27:06 CEST] <InTheWings> AC4SpecificBox should have only one def
[23:32:52 CEST] <InTheWings> okay seems they duplicated the definitions for a v0 & a v1
[23:33:08 CEST] <durandal11707> part 1 is for normal audio, part 2 is for object audio
[23:34:31 CEST] <durandal11707> iirc it depends also on bitstream version
[23:34:53 CEST] <durandal11707> there is 0, 1 and 2 iirc
[00:00:00 CEST] --- Mon May 27 2019