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

Sun Jan 29 03:05:03 EET 2017

[01:27:36 CET] <rcombs> saw I was highlighted in #ffmpeg; before I even tabbed to it I went "this is spam, isn't it"
[02:53:24 CET] <cone-555> ffmpeg 03Aaron Colwell 07master:b9f2f9326154: mov: Fix spherical metadata_source parsing
[12:29:46 CET] <wm4> is there any reason why mov.c supports reading spherical metadata but not HDR metadata? is the latter even defined for mp4?
[12:30:20 CET] <JEEB> for VP9 in ISOBMFF?
[12:30:28 CET] <JEEB> or shit like JPEG2000?
[12:30:39 CET] <JEEB> in any case, I don't remember seeing any spec for ISOBMFF for it
[12:32:08 CET] <wm4> not sure if it has to be codec-dependent
[12:32:26 CET] <wm4> in mkv it doesn't have anything to do with the codec
[12:32:34 CET] <JEEB> well those are the two things that come up with not having that in-stream
[12:32:42 CET] <JEEB> but yes, I meant general colorspace stuff
[12:32:51 CET] <JEEB> I think ISOBMFF did inherit some colorspace stuff from MOV
[12:34:56 CET] <ritsuka> ISOBMFF has got the nclx box
[12:36:52 CET] <JEEB> you mean colr box which then has colour type 'nclx'. which seems to contain the stuff that you used to have in AVC and HEVC in the bit stream
[12:37:03 CET] <JEEB> except for the ICC profiles in case of rICC and prof
[12:37:20 CET] <ritsuka> yep
[12:37:31 CET] <JEEB> so in theory that could be extended, but I don't see it in 14496-12:2015
[12:37:48 CET] <JEEB> so the HDR stuff is not in there at least
[12:38:24 CET] <JEEB> other than you being able to set stuff like BT.2020 I guess
[12:38:38 CET] <JEEB> primaries, transfer, matrix
[12:38:44 CET] <ritsuka> HDR has got its own transfer characteristics
[12:38:47 CET] <JEEB> I guess you can set SMPTE ST.2084 there too
[12:39:06 CET] <JEEB> ritsuka: I think the real additional metadata would be the MAXFall etc stuff
[12:39:20 CET] <JEEB> but yes, this lets you set the primaries|transfer|matrix
[12:39:35 CET] <JEEB> wm4: is this enough or did you want the max brightness etc stuff?
[12:44:58 CET] <JEEB> too bad ISOBMFF specifies itself against https://www.itu.int/rec/T-REC-T.832-201608-I/en
[12:45:11 CET] <JEEB> so the values available for primaries|transfer|matrix are limited to those :P
[12:45:38 CET] <JEEB> (it specifies 29199-2 but that's effectively the same thing available for free)
[12:45:51 CET] <rcombs> is distinguishing MOV, MP4, BMFF, etc. from each other useful
[12:46:12 CET] <JEEB> I'd distinguish two things. MOV and ISOBMFF
[12:46:21 CET] <JEEB> since those do have actual differences
[12:46:28 CET] <rcombs> elaborate?
[12:46:37 CET] <wm4> JEEB: yeah, some standards require the max brightness too, apparently
[12:46:42 CET] <JEEB> I think one of them defined some values signed and others unsigned
[12:46:47 CET] <JEEB> that's most I can remember
[12:46:54 CET] <rcombs> oh joy
[12:47:09 CET] <JEEB> I think MOV might have been the one with unsigned values
[12:47:19 CET] <JEEB> and ISOBMFF then noticed that signed might be useful
[12:47:21 CET] <rcombs> is it like OTF, where things are defined as signed but no meaning is defined for negative values
[12:48:09 CET] <JEEB> I've not honed my skills in differentiating those two things like Paranoialmaniac has so unfortunately I can't go as far as that :D
[12:48:37 CET] <JEEB> just that I know that they have some differences like that due to qtff being the initial thing
[12:49:02 CET] <rcombs> (iirc TTF and OTF both define glyph count and point count as signed, despite neither of those fields having any meaning for negative values)
[12:49:08 CET] <JEEB> wm4: so yeah, at this moment I don't see anything in addition to JPEG-XR's colorspace values (why the fuck did  they specify the values have to come from there I have no idea)
[12:49:27 CET] <JEEB> (the JPEG-XR spec hasn't been updated at ISO/IEC since 2012)
[12:49:29 CET] <ritsuka> qtff has got some major differences in audio atoms for example
[12:49:54 CET] <rcombs> ritsuka: like, incompatible stuff, or different atoms that do the same thing?
[12:51:26 CET] <ritsuka> different atoms that are not defined in ISOBMFF
[12:51:51 CET] <rcombs> oh okay
[12:51:58 CET] <JEEB> ok, so those don't actually require separate parsing logic
[12:52:05 CET] <rcombs> so you can just support both, and don't have to actually differentiate between the file types
[12:52:49 CET] <JEEB> well, in that case at least. the cases where integer types've changed are a bit less simple although hopefully you just never find files with large enough values :P
[12:52:59 CET] <rcombs> that's what I thought, based on mov.c (which I am somewhat familiar with, but haven't exactly read through extensively)
[12:53:37 CET] <JEEB> but yeah, most differentiation is required on the writing side as opposed on the parsing side
[12:55:20 CET] <wm4> mov.c is over 6000 lines so it'll take a bit longer to get familiar with it
[13:35:29 CET] <BtbN> the mov/mp4 code is outright scary
[13:36:39 CET] <JEEB> if you want something scary, go look at the vsync code in ffmpeg.c. I'm not sure if the original writer would even understand it at this point
[13:37:38 CET] <BtbN> I don't mean it's bad code. The format itself makes it scary
[13:37:54 CET] <JEEB> right
[13:53:07 CET] <cone-499> ffmpeg 03Chris Moeller 07master:ecd360041ea7: avformat: fix ID3v2 parser for v2.2 comment frames
[14:54:15 CET] <Compn> hehe
[14:54:26 CET] <Compn> because mkv is sane, and mov is not.
[14:55:12 CET] <JEEB> no
[14:55:55 CET] <JEEB> ISOBMFF is at least specified insanity with proper timebases and matroska is a to-be-specified mess that tried to copy ISOBMFF at the time when ISOBMFF was still weak :)
[15:01:56 CET] <wm4> I like mkv for being actually suitable for streaming
[15:02:18 CET] <JEEB> fragmented isobmff handles that, too
[15:02:29 CET] <wm4> fragmentation is a shitty hack
[15:02:38 CET] <JEEB> given that the extradata issue should be the same in matroska as well
[15:02:45 CET] <wm4> ?
[15:03:11 CET] <JEEB> although I guess with ISOBMFF it's more of the index which I guess matroska doesn't have (you just get the extradata thing)
[15:03:17 CET] <wm4> mkv might also be more resilient to corruption
[15:03:21 CET] <JEEB> which is what the fragmentation is supposed to handle
[15:03:38 CET] <wm4> which index?
[15:04:06 CET] <kierank> 2:02 PM <wm4> fragmentation is a shitty hack
[15:05:25 CET] <JEEB> wm4: moov
[15:05:42 CET] <JEEB> although I might be mis-recalling things at this point :P
[15:06:23 CET] <JEEB> because you've got the trak-edts-etc there
[15:08:38 CET] <JEEB> then you've got moof etc for fragments
[15:11:27 CET] <wm4> keep in mind that mkv needs no index at all
[15:11:36 CET] <wm4> it only exists to make seeking faster
[15:12:19 CET] <JEEB> yea
[15:12:31 CET] <JEEB> I hope the matroska specification effort will lead to a proper v5
[15:12:40 CET] <JEEB> v4 will be specified as "what's there now"
[15:14:01 CET] <wm4> "My guess is that the OpenBSD guys want the world to get rid of openssl completely (see for example http://opensslrampage.org/), and breaking API compatibility with openssl is their "strategy"."
[15:14:03 CET] <wm4> jesus christ
[15:15:46 CET] <jkqxz> The reference to a website which hasn't been updated in more than two years inspires great confidence, too.
[15:17:15 CET] <ubitux> openssl started being sponsored by google & friends soon after the fork drama iirc
[15:17:31 CET] <ubitux> (google or/and some other big corp)
[15:18:06 CET] <ubitux> so actual developments and fixes happened there as well and prevented a turnover in usage
[15:20:21 CET] <wm4> nice one, google
[15:27:17 CET] <ubitux> or maybe that was http://www.theregister.co.uk/2016/01/04/dutch_government_says_no_to_backdoors/ ? 
[15:28:29 CET] <ubitux> also https://groups.google.com/forum/m/#!topic/mailing.openssl.users/-P4T62ml_1I
[15:29:30 CET] <ubitux> i guess i was confused about google, probably a memory derp
[15:29:45 CET] <ubitux> but anyway, they got much more money after the libressl fork
[15:36:38 CET] <wm4> ah
[15:37:07 CET] <JEEB> google has its own fork now IIRC
[15:37:17 CET] <phh> yes, boringssl
[15:37:25 CET] <JEEB> https://boringssl.googlesource.com/boringssl/
[15:38:40 CET] <Gramner> libavssl
[15:39:06 CET] <kierank> does kaby lake need new asm?
[15:39:28 CET] <Gramner> no
[15:40:18 CET] <Gramner> skylake e5/e7 xeons (and the skylake-x hedt versions based on those) does
[15:51:50 CET] <atomnuker> avx512 finally?
[15:57:46 CET] <Gramner> yes
[15:58:20 CET] <kierank> maybe time to drop yasm
[16:03:07 CET] <durandal_170> why?
[16:03:35 CET] <Gramner> because it's been unmaintained since 2015
[16:03:58 CET] <durandal_170> why?
[16:05:41 CET] <Gramner> because yasm was largely a one-man show (with the occasional third party patch) and he lost interest I guess? nasm on the other hand is actively developed and is backed by Intel
[16:07:39 CET] <atomnuker> btw TD-Linux, matroska muxing overhead can be quite big:
[16:07:41 CET] <atomnuker> 32kbps,  50 packets/sec - mka: 8.70%, ogg: 2.15% ; 32kbps,  25 packets/sec - mka: 5.64%, ogg: 1.54%
[16:07:50 CET] <atomnuker> 32kbps,  16 packets/sec - mka: 4.18%, ogg: 1.28% ; 32kbps,   8 packets/sec - mka: 2.74%, ogg: 1.28%32kbps,  16 packets/sec - mka: 4.18%, ogg: 1.28% ; 32kbps,   8 packets/sec - mka: 2.74%, ogg: 1.28%
[16:08:00 CET] <atomnuker> 128kbps,  8 packets/sec - mka: 0.68%, ogg: 0.63% ; 500kbps,  8 packets/sec - mka: 0.17%, ogg: 0.45%
[16:08:35 CET] <atomnuker> double pasted the second line, but its matroska does save alot of overhead if you don't have many packets
[16:09:00 CET] <atomnuker> and the bitrate is huge
[16:09:38 CET] <atomnuker> for both formats this actually makes it worth it to pack as many frames into a packet
[16:10:28 CET] <atomnuker> this is for cbr frames only, I'll need to check what its like for vbr where you pay 1 or 2 bytes per packet
[16:10:52 CET] <atomnuker> (also there was no metadata at all anywhere, this was a clean test)
[16:11:29 CET] <wm4> well at least you can seek in mkv, unlike ogg
[16:12:10 CET] <wm4> Gramner: what's the story of nasm being unmaintained or falling behind yasm for a while?
[16:13:15 CET] <Gramner> iirc the main reason for yasms existance is that nasm had a weird license back then.
[16:13:39 CET] <Gramner> nasm has since relicensed so that's a moot point now
[16:14:22 CET] Action: wm4 fondly remembers making his own assembler, using nasm's opcode table out of laziness
[16:14:23 CET] <jamrial> what's this anou avx512 finally?
[16:14:28 CET] <jamrial> *about
[16:15:12 CET] <Gramner> not sure what "finally" implies, it has always been publically scheduled for SKX
[16:15:36 CET] <jamrial> i was quoting atomnuker
[16:15:38 CET] <Gramner> (the normal cpu version that is, not the xeon phi subset)
[16:35:29 CET] <JEEB> Gramner: also at one point it wasn't fast enough for x264 to implement some things
[16:50:43 CET] <Polochon_street> wm4: hi! I'm trying to make the last version of the ID3v2 patch, would the comment « ID3v2 metadata information » be enough for the id3v2_meta variable inside internal.h? I can't think of something better...
[16:56:06 CET] <wm4> Polochon_street: sure
[16:56:30 CET] <Polochon_street> I wanted to convey the idea that this was there only because of the MP3 problem, but heh
[16:58:21 CET] <wm4> well, someone who wants to find out why it's needed will see that mp3dec.c uses it
[16:59:54 CET] <Polochon_street> true
[17:01:46 CET] <wm4> probably wouldn't be ok for external API, but this is just internal
[17:07:24 CET] <jamrial> durandal_170: http://fate.ffmpeg.org/report.cgi?time=20170128103925&slot=x86_64-archlinux-gcc-valgrindundef
[17:07:35 CET] <jamrial> it's the scc demuxer probe function
[17:08:28 CET] <jamrial> easiest way to fix it would be to copy the behavior of the ass demuxer probe function
[17:08:57 CET] <jamrial> or maybe make sure ff_subtitles_read_line() reads at least 18 bytes
[17:25:37 CET] <cone-490> ffmpeg 03Paul B Mahol 07master:4cfa1f80a976: avformat/sccdec: attempt to fix valgrind issue
[17:48:03 CET] <cone-490> ffmpeg 03James Almer 07master:dce863421b64: avformat/matroskaenc: don't reserve more bytes than needed for the Colour master size
[18:59:36 CET] <durandal_170> can i push atrac advanced lossless decoders?
[19:03:18 CET] <wm4> did the maintainer agree?
[19:22:29 CET] <rakshith> hi guys. I'm interested in participating in this year's GSoC. I saw the GSoC page of FFMPEG, and I would like to work on the Ambisonic Decoder project. I need some help and advice here. Thanks!
[19:28:27 CET] <wm4> rakshith: mail the mentor for the project
[19:34:47 CET] <durandal_170> rakshith: im the mentor for that project
[19:35:29 CET] <rakshith> wm4: And one more thing. Will additional ideas be added on to the page, or are they the final list of ideas?
[19:35:50 CET] <durandal_170> wm4: maxim is ignoring me as usual
[19:36:20 CET] <rakshith> durandal_170: Should we talk here, or shall I mail you?
[19:36:55 CET] <durandal_170> rakshith: feel free to do whichever way you prefer/like
[19:37:57 CET] <Polochon_street> Is there a page somewhere for the guidelines for submitting fate test files? The fate page https://ffmpeg.org/fate.html here is not very informative...
[19:38:56 CET] <durandal_170> Polochon_street: talk privately with michaelni to upload files
[19:39:39 CET] <Polochon_street> durandal_170: thanks, but I'm concerned over names guidelines, private property issues, etc
[19:40:57 CET] <durandal_170> just tell in what directory to upload file with meaningful name
[19:49:22 CET] <wm4> durandal_170: ignoring as in? also who's maxim
[19:49:51 CET] <wm4> Polochon_street: yeah, usually someone like michaelni uploads it, then we wait a few days, then we push the fate tests
[19:49:59 CET] <wm4> because it has to trickle down or something (???)
[19:50:00 CET] <durandal_170> wm4: author of atrac3+ decoder
[19:57:29 CET] <Polochon_street> wm4: alright thanks. I found this http://trac.ffmpeg.org/wiki/FATE/AddingATest explicative page, I'll probably need some days to figure out how to do it properly
[20:00:22 CET] <wm4> durandal_170: how long did you wait? doc/developers.texi specifies waiting times
[20:03:44 CET] <durandal_170> wm4: i wait very long, few days
[20:04:19 CET] <wm4> it allows you to push "small" changes after a few days of waiting
[20:09:16 CET] <durandal_170> wm4: this one just adds new decoder and changes  single line in atrac3plus file
[20:12:14 CET] <wm4> sounds like a "small" change
[20:17:08 CET] <jamrial> ping him, and if he doesn't reply even after that then push it
[22:06:38 CET] <TD-Linux> atomnuker, I assume for the different packets/sec you're using one of the matroska lacings?
[22:07:43 CET] <wm4> does ffmpeg even write lacings
[22:07:54 CET] <wm4> or just put every packet into separate elements
[22:08:04 CET] <wm4> that could quite bloat up with small packet sizes
[22:28:20 CET] <atomnuker> "put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0);    // no lacing (yet)" <- apparently not
[22:32:42 CET] <wm4> maybe remuxing with mkvmerge will merge them or something
[22:57:47 CET] <TD-Linux> atomnuker, er how are you varying packets/s without using lacing?
[22:58:04 CET] <TD-Linux> or is this AAC or something
[22:58:10 CET] <TD-Linux> (or just blank data)
[22:58:55 CET] <atomnuker> I'm just varying how much frames I put in the opus layer
[22:59:47 CET] <TD-Linux> ok
[23:09:41 CET] <cone-381> ffmpeg 03Paul Arzelier 07master:65862f57ad2f: avformat: Ignore ID3v2 tags if other tags are present e.g. vorbis
[23:09:42 CET] <cone-381> ffmpeg 03Marijn Meijles 07master:227d602bb36f: avformat/ac3dec: Fix to prevent runaway ac3 detection by looking at the actual frame rather than the first detected frame.
[23:19:15 CET] <kierank> michaelni: the fix is wrong no?
[23:19:19 CET] <kierank> you should be reading the syncwords?
[23:20:19 CET] <kierank> this is trigger happy committing :(
[23:37:01 CET] <wm4> trigger happy
[23:37:07 CET] <wm4> that's a nice description
[23:37:26 CET] <wm4> although I have some faith if what the patch author claims is true
[23:38:35 CET] <michaelni> kierank, not sure i understand, the code prior to the patch used the wrong buffer and after the patch is using the intended  one. i dont know if there are more issues quite possibly there are
[23:38:54 CET] <kierank> well not that I care about hacky probing but any ac3 in wav should have spdif syncwords
[23:39:48 CET] <wm4> I don't know about AC3 specifically, but apparently it's ok to skip the spdif sync word if the data packet is as large as the spdif frame size
[23:40:55 CET] <kierank> does that extreme case actually exist?
[23:42:15 CET] <wm4> spdifenc.c supports it at least
[23:42:28 CET] <wm4> btw. did I mention yet how much I hate spdif
[23:43:21 CET] <wm4> hmm it's worth noting that spdifenc.c does this only in the DTS case
[23:43:38 CET] <kierank> yes, losses could be a pathological case
[23:44:00 CET] <kierank> lossless*
[23:46:18 CET] <kierank> lossless could even be larger than the original pcm
[23:46:31 CET] <kierank> so it won't work in that case at all
[23:46:35 CET] <wm4> apparently that happens often with DTS
[23:46:40 CET] <wm4> because DTS is a shit codec
[23:47:03 CET] <wm4> that's also why the DTS-HD spdif output rate is much larger than the decoded PCM rate
[23:47:08 CET] <wm4> bitrate
[23:47:27 CET] <wm4> but hey at least the dts light goes on
[23:51:06 CET] <kierank> oh yeah dts is 1536kbps
[00:00:00 CET] --- Sun Jan 29 2017