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

[burek]

[04:45:05 CET] <philipl> BtbN: https://github.com/philipl/nv-codec-headers/commit/2382e15b6e2e70ff5e4ff10b7966432c5c9ac0df
[12:27:56 CET] <JEEB> there, one patch posted
[12:28:34 CET] <JEEB> (was looking for the simplest way yesterday to fix that issue, and finally finished testing)
[12:44:08 CET] <JEEB> well that was one quick LGTM
[14:23:34 CET] <nevcairiel> sometimes fixes are hard to find but  easy to verify
[15:02:36 CET] <JEEB> true
[15:02:51 CET] <JEEB> esp. when a 30MiB sample caused almost 800MiB of RAM usage 8)
[19:20:24 CET] <cone-262> ffmpeg 03Jan Ekström 07master:8cf757ee8d80: ffmpeg_filter: initialize sub2video.end_pts together with last_pts
[19:29:21 CET] <durandal_1707> how many GBs i need to install MSVC 2017?
[19:29:55 CET] <JEEB> about 8? you can actually pick the components nowadays but the IDE is required
[19:30:29 CET] <j-b> a bit more, no?
[19:36:57 CET] <durandal_1707> this crap needs >60GB
[19:45:05 CET] <nevcairiel> VS itself is only like 4gb, plus some shared stuff and the windows sdk, overall you should probably stay below 10 i would reckon
[19:45:48 CET] <nevcairiel> if you only install the C/C++ target anyway
[19:48:14 CET] <nevcairiel> at least with 2017, which has that nice flexible installer (finally, before that the installer was terrible)
[19:48:54 CET] <JEEB> yea
[19:49:01 CET] <JEEB> as I said, you can pick the components these days
[19:49:20 CET] <durandal_1707> right now it is downloading 1.6 GB
[19:58:14 CET] <nevcairiel> technically you could save space by only getting the compiler and sdk, and foregoing the IDE
[19:58:33 CET] <nevcairiel> but i dont think they have a finished "package" for that, and you would have to pick the right components manually
[20:39:26 CET] <durandal_1707> michaelni: fix your fuzzing timeouts
[21:23:05 CET] <durandal_1707> do i need to install git to fetch lavfilters code?
[21:23:44 CET] <JEEB> that's the simplest I'd say
[21:23:52 CET] <nevcairiel> why do you want to build it anyway
[21:23:56 CET] <JEEB> http://git.1f0.de/gitweb?p=lavfsplitter.git;a=summary;js=1
[21:24:05 CET] <JEEB> nevcairiel: he wants to add AC-4 so he can feed it to the DShow decoder
[21:24:15 CET] <JEEB> and compare to his decoder
[21:24:39 CET] <nevcairiel> there is a dshwo decoder?
[21:24:53 CET] <JEEB> unless the ax file is vfw, yes
[21:25:02 CET] <nevcairiel> i can probably add demuxing support in a few minutes and make a binary
[21:25:08 CET] <nevcairiel> if there is a demuxing patch somewhere
[21:25:15 CET] <JEEB> also what the DShow UUID is
[21:25:19 CET] <JEEB> that part I didn't know :P
[21:25:29 CET] <durandal_1707> it is dshow, but it may be locked
[21:25:29 CET] <nevcairiel> well the decoder would usually tell you
[21:25:41 CET] <nevcairiel> where can i find it?
[21:26:54 CET] <durandal_1707> 0x7E326AC2, 0x0A60, 0x402C, 0xBB, 0xBC, 0xC1, 0xCD, 0x90, 0xC7, 0x66, 0x93, (for mplayer), dshow decoder is part of StreamXpert 2something 
[21:28:00 CET] <JEEB> right, dektek
[21:28:07 CET] <JEEB> *dektec
[21:29:39 CET] <durandal_1707> also it probably does not decode 2 version of bitstreams
[21:29:44 CET] <nevcairiel> it even c omes with ffmpeg l ibraries =p
[21:30:05 CET] <durandal_1707> yea, old libav actually
[21:30:53 CET] <durandal_1707> i havent checked if libs are modified somehow....
[21:33:24 CET] <nevcairiel> the filter exposes a "AC4 " media type, so that seems promising
[21:33:49 CET] <nevcairiel> next question, where can i find a sample that might work? :)
[21:35:13 CET] <nevcairiel> i got the mp4 ac-4 patch from the ml
[21:35:47 CET] <durandal_1707> http://dash.akamaized.net/dash264/TestCasesMCA/dolby/5/1/Living_Room_720p_20_96k_25fps_A.mp4
[21:36:41 CET] <JEEB> yea, DASH-IF's sample collection is the only place I ever saw public AC-4 samples at
[21:36:57 CET] <JEEB> other than that one raw bit stream @ Dolby's Exoplayer fork
[21:38:28 CET] <nevcairiel> lets see if this decoder works
[21:40:06 CET] <JEEB> the decoder is expecting MPEG-TS so I wonder if MP4 and MPEG-TS use the same packet format
[21:40:20 CET] <nevcairiel> hrm it connects but doesnt decode anything
[21:40:23 CET] <JEEB> IIRC there was some AC-4 packet format defined
[21:40:51 CET] <JEEB> > raw_ac4_frame, as defined in ETSI TS 103 190-1 [1], clause 4.2.1
[21:44:23 CET] <JEEB> also MPEG-TS might be utilizing the ac4_syncframe() structure
[21:44:26 CET] <JEEB> https://www.etsi.org/deliver/etsi_ts/103100_103199/10319001/01.03.01_60/ts_10319001v010301p.pdf
[21:44:26 CET] <nevcairiel> rebuilding with the raw ac4 reader and seeing if it likes the exoplayer sample
[21:44:51 CET] <JEEB> yea, raw AC-4 should be ac4_syncframe() based
[21:44:59 CET] <JEEB> 0xAC40 / 41
[21:45:19 CET] <nevcairiel> hate codecs with multiple bitstream variants
[21:45:33 CET] <nevcairiel> stop saving  one byte per frame
[21:46:03 CET] <JEEB> it's like annex b I guess, except it also has frame_size() in front
[21:46:21 CET] <JEEB> it then includes the raw_ac4_frame (and optionally crc_word)
[21:46:30 CET] <JEEB> (crc_word when 0xAC41)
[21:46:48 CET] <nevcairiel> i smell bsfs in the future
[21:47:10 CET] <JEEB> at least the raw ac4 frame structure should be the same but I wonder what the dshow decoder wants (extracted or within that syncframe structure)
[21:47:24 CET] <nevcairiel> well the data out of the mp4 frame didnt work
[21:47:36 CET] <JEEB> yea, those samples should be just raw_ac4_frames
[21:47:46 CET] <JEEB> since the AC-4 in ISOBMFF spec seems to define it as such
[21:47:57 CET] <JEEB> then it... probably wants ac4_syncframes XD
[21:48:49 CET] <JEEB> also wow
[21:48:51 CET] <JEEB> 16bit frame_size
[21:49:05 CET] <JEEB> then if frame_size == 0xffff => additionaly 24 bits of frame_size
[21:49:47 CET] <nevcairiel> still not doign any decoding this thing
[21:50:32 CET] <JEEB> do you see the 0xAC4{0,1} sync words if you dump the packets' first X bytes?
[21:50:59 CET] <JEEB> (also I just noticed the sync word has "AC4" in it
[21:52:49 CET] <nevcairiel> its lacking a parser, so the frames from the raw file are probably just jumbled up
[21:52:58 CET] <JEEB> quite possible
[21:53:05 CET] <durandal_1707> it may expect whatever as it is for stream analytics
[21:54:39 CET] <durandal_1707> the mp4 files have only raw ac4
[21:55:06 CET] <nevcairiel> a ts file might be useful, but if those dont exist
[21:55:23 CET] <durandal_1707> also it might only working with proper license
[21:55:39 CET] <nevcairiel> perhaps
[21:56:29 CET] <cone-262> ffmpeg 03Marton Balint 07master:5adc4a98b362: avformat/mpegtsenc: add support for service and provider names with utf8 encoding
[21:56:30 CET] <cone-262> ffmpeg 03Marton Balint 07master:a899b3b3c5f5: doc/formats: add reference to ffmpeg(1) stream specifiers as that docs is more complete
[21:57:59 CET] <durandal_1707> also looks like here nobody have capture card :( 
[22:01:57 CET] <atomnuker> even if they did is ac4 being broadcast right now?
[22:02:08 CET] <atomnuker> and even if they did it would likely be in north america only
[22:04:41 CET] <JEEB> atomnuker: I hear eastern paris has some
[22:07:22 CET] <atomnuker> pirate broadcast?
[22:08:04 CET] <atomnuker> or some sort of inverse border blaster from the us operating at XX megawatts?
[22:13:55 CET] <JEEB> > NRJ conducted broadcast tests for UHD 4K, HDR and Dolby AC-4 over DTTV in Paris and other regions across France (as well as by satellite) on three DTTV channels over two weeks. The first service was in UHD 4K HDR HLG 50p (over 24 Mbps high-speed broadband), the second and third in HD+ 1080p50 HDR HLG at different, lower rates.
[22:25:31 CET] <nevcairiel> i havent even seen a real-world hlg  sample
[22:25:38 CET] <nevcairiel> .. not that I have looked
[22:25:43 CET] <nevcairiel> but users also didnt complain yet
[22:25:49 CET] <JEEB> travelxp .ts
[22:26:22 CET] <nevcairiel> the nice thing about HLG is that you might just be watching it as SDR and never be the wiser =p
[22:26:34 CET] <JEEB> well it still has the BT.2020 usually
[22:26:52 CET] <JEEB> BT.709 + HLG is possible, but less likely
[22:27:46 CET] <durandal_1707> https://www.dvbviewer.tv/forum/topic/62027-dolby-ac4-sound-track/ ---> ask him for capture?
[22:28:44 CET] <nevcairiel> i know some of the devs, they use my filters afterall, I can inquire
[22:30:53 CET] <nevcairiel> sent him a mail
[22:31:12 CET] <nevcairiel> (its the griga person talking with the  user in that thread)
[22:32:10 CET] <durandal_1707> maybe ac4 is no longer broadcast at all, it was just for testing...
[22:32:26 CET] <j-b> you wish
[22:32:58 CET] <JEEB> what j-b says...
[22:33:01 CET] <JEEB> once they blowjob in...
[22:33:25 CET] <durandal_1707> codec is too much descriptive and bloated
[22:33:30 CET] <JEEB> they definitely have a better track record at getting into this stuff than DTS
[22:33:43 CET] <nevcairiel> wasnt ac-4 supposed to be a mainstream object-based codec, or am i misremembering stuff again
[22:33:45 CET] <JEEB> also this is what dolby's ES parser does > https://github.com/DolbyLaboratories/dlb_mp4base/blob/master/src/esparser/parser_ac4.c
[22:33:57 CET] <JEEB> nevcairiel: marketing wankery says that, and I think in theory they have that
[22:33:59 CET] <durandal_1707> nevcairiel: yes, 2 bitstream version have object crap
[22:34:42 CET] <nevcairiel> anyhow i'll let you know if i hear anything from the dvb viewer people
[22:34:48 CET] <JEEB> cool
[22:36:17 CET] <JEEB> another thing was the MPEG-H audio thing
[22:36:23 CET] <JEEB> which doesn't seem to have gone anywhere?
[22:36:41 CET] <JEEB> although I've seen broadcast things at least theoretically having support for it
[22:37:16 CET] <nevcairiel> it seems non-mainstream at best
[22:37:20 CET] <nevcairiel> with its 128 audio channel shit
[22:37:28 CET] <JEEB> yea
[22:38:14 CET] <nevcairiel> aac still seems to be good enough for the web, and mpeg-audio hasnt been in broadcast since mp2
[22:39:51 CET] <nevcairiel> compression-wise, audio probably doesnt have that many low-hanging fruit anymore
[22:40:03 CET] <nevcairiel> so they try to kill it with fancy features that noone wants
[22:40:14 CET] <JEEB> yuppo
[22:40:55 CET] <nevcairiel> ac3 is relatively old, so ac4 probably has some reason to exist, but aac is doing fine, so ..
[22:41:19 CET] <JEEB> yea, I'd either AAC or Opus if I was doing broadcast :P
[22:41:34 CET] <durandal_1707> what about he++ aac or whatever it is called?
[22:41:43 CET] <JEEB> isn't that low low bit rate?
[22:41:45 CET] <nevcairiel> there is so many of those now
[22:41:50 CET] <j-b> HE-AAC-v2-ELD
[22:41:51 CET] <nevcairiel> and yeah they mostly just focus on even lower bitrates
[22:42:05 CET] <nevcairiel> at "normal" bitrate (ie 96k+) all these extensions do nothing
[22:42:43 CET] <nevcairiel> there is also xHE-AAC now, which apparently android started to support recently
[22:42:55 CET] <JEEB> through fdk-aac yea
[22:43:09 CET] <nevcairiel> stealing ideas from opus, splitting music and speech
[22:44:08 CET] <nevcairiel> but all of those aim at really low bitrates, so yeah
[22:50:01 CET] <atomnuker> speaking of aac, I saw a tweet peloverde did a few days ago showing a vp9 facebook video with aac audio
[22:50:34 CET] <atomnuker> thought it was weird not to see opus used
[23:38:13 CET] <kurosu_> Dolby has an annex in France, and funny enough, not in Paris, in the French Riviera, rather
[00:00:00 CET] --- Fri Feb 22 2019