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

[burek]

[00:45:05 CET] <llogan> what's the minimum supported nasm version?
[00:48:06 CET] <nevcairiel> probably something ridicoulously old
[00:48:45 CET] <nevcairiel> according to some commits, 2.09 from 2010 should still work at the very least
[00:49:15 CET] <nevcairiel> apparently we're supposed to support all the way back to nasm 2.03 from 2008
[00:51:16 CET] <llogan> assisted living for the elderly
[00:52:19 CET] <jamrial> i don't think something that old works by now, but the minimum requirement in configure is a version with movbe support
[00:53:32 CET] <nevcairiel> the above was from a statement from not too long ago, i'm not sure we changed anything fundamental since then
[00:54:34 CET] <jamrial> some code might have been committed that doesn't work with a version that old. i don't think there's a fate test with it
[00:55:05 CET] <nevcairiel> i guess
[00:55:15 CET] <jamrial> i'll try a build with 2.08
[00:55:16 CET] <nevcairiel> there were fixes for at least 2.09 back in 2017 still
[00:57:52 CET] <nevcairiel> finding out the nasm version on fate boxes is apparently impossible
[01:02:27 CET] <llogan> for the wiki i'll just assume any nasm used in the currently supported ubuntu/debian repos will work. oldest is 2.10, but that distro version is going away 30 april then it will be 2.11.
[01:03:46 CET] <nevcairiel> hm apparently i updated nasm on my debian build box
[01:03:58 CET] <nevcairiel> i was trying to check which one i used there :D
[01:04:31 CET] <llogan> 2.13.03 didn't like gcc 8
[01:04:52 CET] <nevcairiel> for some reason latest nasm also doesnt like s ome windows tools
[01:05:11 CET] <nevcairiel> could never figure out whats up with that
[01:05:52 CET] <nevcairiel> so i'm still building iwth yasm :)
[01:06:24 CET] <llogan> looks like 2.03 got movbe
[01:32:11 CET] <jamrial> well, 2.08 doesn't work
[01:32:29 CET] <jamrial> guess now we know what to expect from 2.03 :p
[01:33:18 CET] <jamrial> nevcairiel: i can build mingw-w64 with nasm 2.14 just fine
[01:34:22 CET] <nevcairiel> mingw is fine
[01:34:28 CET] <nevcairiel> msvc is what breaks
[01:34:37 CET] <nevcairiel> for some reason the linker freaks out on some nasm object files
[01:34:40 CET] <nevcairiel> or well it used to
[01:34:45 CET] <nevcairiel> updated nasm and msvc since then
[01:40:31 CET] <llogan> jamrial: thanks for testing. only disto using something older that i know of is CentOS 6 with 2.07.
[01:42:51 CET] <jamrial> guess they force yasm
[01:43:17 CET] <nevcairiel> their ffmpeg is also  older then our switch to nasm default
[01:43:25 CET] <nevcairiel> built-in one anyway
[08:27:55 CET] <cone-725> ffmpeg 03Lauri Kasanen 07master:fc6022e1088d: avutil/ppc/cpu: Fix power8 linux detection
[08:33:39 CET] <cone-725> ffmpeg 03Lauri Kasanen 07master:8522d219ce80: libswscale/ppc: VSX-optimize 9-16 bit yuv2planeX
[09:17:39 CET] <JEEB> alright, so there's opposition to aribb24 library being utilized. time to see if I can at least get some of the AVCodec/demuxing stuff in since I'd rather like things to go in in pieces :/
[09:18:02 CET] <JEEB> since if we're going to start bringing in swathes of code that's going to take a while for anyone to review
[09:19:59 CET] <JEEB> and if we go bit by bit people will ask why something's being added if it's not necessarily being used yet (like I'd like to get the ARIB STD-B24 text conversion in first, and then the actual subtitle decoding which requires the former)
[09:20:27 CET] <JEEB> (the text decoding can be utilized for metadata encoding, but then we go into the mess that is "pick your MPEG-TS broadcast mode" :P
[09:20:35 CET] <JEEB> *metadata decoding
[09:23:02 CET] <JEEB> I already had patches doing similar stuff that VLC is doing for trying to probe ARIB-defined MPEG-TS muxes by certain things in the PMT, and to convert the metadata from ARIB STD-B24 to UTF-8
[09:23:23 CET] <JEEB> but I thought I'd ease the whole thing by first getting the subtitle demuxing in first :P
[09:23:51 CET] <JEEB> (since finding ARIB captions in MPEG-TS is a most obvious hint that it's ARIB specified)
[09:24:33 CET] <JEEB> I guess when I have actual time to formulate a proper response on the ML I will try to poke carl on what is his idea of going forward with this
[09:25:19 CET] <JEEB> because it's one thing saying "I am against this" and another to be able to help people move forward to a place of common understanding
[18:25:18 CET] <JEEB> phew
[18:25:23 CET] <JEEB> that took a while to write down
[18:25:37 CET] <JEEB> and to be honest, I don't want to throw what I've done so far into the garbage bin
[18:25:51 CET] <Taripe> ?
[18:26:02 CET] <JEEB> carl was against using libaribb24
[18:26:07 CET] <Taripe> Ah that
[18:26:31 CET] <JEEB> so I did write a full step-by-step thing towards a LGPLv2.1+ decoder, but geeez
[18:26:50 CET] <durandal_1707> ignore carl
[18:27:03 CET] <JEEB> although if that's what it takes to at least get the demuxing parts in, at least that gets in :V
[18:40:03 CET] <atomnuker> just ignore it, its packaged by debian which is definitely good enough
[18:47:55 CET] <JEEB> atomnuker: I will prod michaelni or so if there really is a stallmate :P
[19:15:41 CET] <JEEB> I love it how people tell me that they don't even apply for FFmpeg in GSoC because of the opinion they have regarding the mailing list.
[19:15:48 CET] <JEEB> or more like, I don't love it
[19:16:16 CET] <JEEB> just had someone mentioned it off-hand that he skipped trying to contribute because he felt the community was toxic :D
[19:16:28 CET] <JEEB> *mention
[19:17:51 CET] <JEEB> and this stuff is sad because what we need are capable, thinking newcomers
[20:36:02 CET] <durandal_1707> we need only Carl
[21:49:37 CET] <durandal_1707> lets create FFmpeg: most commits award!
[22:43:24 CET] <Mathieu_Du> Hey, please correct me if I'm mistaken, but the mpeg-2 encoder doesn't take side_data into account (eg A53 CC) right?
[22:44:26 CET] <JEEB> git grep "SIDE_DATA" libavcodec/mpegvideo_enc.c
[22:44:28 CET] <JEEB> gives nothing
[22:44:37 CET] <JEEB> so I would say it doesn't support closed captions
[22:44:51 CET] <Mathieu_Du> yeah I was looking at the source too (with -i :P)
[22:44:59 CET] <Mathieu_Du> seems nvenc does inject it as SEI
[22:45:17 CET] <JEEB> the newer format encoders do take it in
[22:45:22 CET] <JEEB> started with libx264, IIRC
[22:45:31 CET] <Mathieu_Du> I see, too bad but thanks :)
[22:45:37 CET] <Mathieu_Du> I'll figure out some other way
[22:46:07 CET] <JEEB> I have no idea if the data is similar, but you could try implementing it?
[22:47:50 CET] <Mathieu_Du> It's really similar, but it's not easy for me to test it, I'm using FFmpeg through gstreamer, built against my system wide FFmpeg
[22:48:28 CET] <JEEB> in the worst case you could try passing a source with captions through ffmpeg.c?
[22:48:29 CET] <Mathieu_Du> guess I could dust off my meson port :P
[22:49:39 CET] <Mathieu_Du> hrm, what do you mean ?
[22:51:31 CET] <JEEB> if you have an input stream that can be read and FFmpeg can parse the captions from into side data
[22:51:36 CET] <JEEB> then ffmpeg.c is able to pass that through
[22:51:43 CET] <JEEB> when you re-encode it
[22:52:02 CET] <JEEB> so you re-encode with libx264 and check if it's in the output. if it is, you've got yer test case
[22:52:15 CET] <JEEB> then you start poking at the mpeg-2 stuff and see if it gets passed
[22:53:07 CET] <Mathieu_Du> Well that's pretty much my setup already
[22:53:30 CET] <JEEB> ok, then I didn't fully get what your issue was
[22:53:38 CET] <Mathieu_Du> I'm getting the CC as side_data from the decoder all right
[22:53:53 CET] <JEEB> since that should validate your implementation if you do one
[22:54:55 CET] <Mathieu_Du> I can pass that to libx264 in the gstreamer wrapper and I get the expected result, but I was trying to do roughly the same in the gstreamer ffmpeg wrapper around the mpeg2 encoder and no luck
[22:55:03 CET] <Mathieu_Du> (using av_frame_new_side_data)
[22:56:14 CET] <BtbN> Can't you just use normal captions instead?
[22:56:40 CET] <BtbN> I'm still not sure why CC are a thing
[22:56:40 CET] <Mathieu_Du> nope :)
[22:56:56 CET] <Mathieu_Du> broadcasting industry kind of likes them afaiu :)
[23:00:59 CET] <nevcairiel> CC is mandatory in the US, because they forgot to spec proper subtitles
[23:01:19 CET] <nevcairiel> and its demanded by law that they are present or something
[23:01:59 CET] <BtbN> So everyone has to live with forced subtitles there? oO
[23:02:49 CET] <nevcairiel> its only mandatory that they are present
[23:02:52 CET] <nevcairiel> you dont have to turn them on
[23:02:58 CET] <JEEB> they're not mandatory to turn on, yea
[23:03:08 CET] <BtbN> At least my TV shows them without choice when present
[23:03:09 CET] <JEEB> but they're really used. I laughed out loud when the ADS had captions
[23:03:45 CET] <JEEB> nevcairiel: and now with web streaming I'm beginning to think that with live streams US style closed captions are the only sane way...
[23:03:51 CET] <JEEB> and I hate to admit that
[23:04:13 CET] <BtbN> well, as everything is still using rtmp for that stuff, it's the only caption kind it can carry
[23:04:20 CET] <nevcairiel> i dont remember if they specced something for ATSC 3.0
[23:04:25 CET] <nevcairiel> but that standard is terrible anyway
[23:04:29 CET] <nevcairiel> its like DASH for broadcast
[23:04:30 CET] <BtbN> Can there even be multiple CC streams? Like, multiple languages?
[23:04:56 CET] Action: Mathieu_Du didn't want to reopen old wounds, sorry :P
[23:05:03 CET] <BtbN> I remember people in #videolan talking about stuff in IPv6 in mpegts 
[23:05:09 CET] <nevcairiel> (literally DASH, they get the manifest etc from a web host, and only stream the main media data through the broadcast afaik)
[23:05:24 CET] <BtbN> what?
[23:05:37 CET] <BtbN> So if you're offline, no TV for you?
[23:05:50 CET] <JEEB> MMTP yo
[23:06:10 CET] <JEEB> let me find my X over Y thing for MMTP
[23:08:51 CET] <nevcairiel> they can also send you targeted ads from the web andshit like that, its really a terrible concept for broadcast, but everything is going web anyway
[23:09:31 CET] <JEEB> anyways, it's TLV (ip over broadcast) -> UDP multicasts -> you find out the index by a broadcast standard specific multicast address -> then you listen for different ISOBMFF parts over UDP multicast from the ones marked in the index
[23:09:35 CET] <JEEB> if I recall correctly
[23:09:55 CET] <JEEB> and the ISOBMFF parts can then also contain stuff like XML indices etc
[00:00:00 CET] --- Wed Feb  6 2019