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

burek burek021 at gmail.com
Tue Mar 12 03:05:03 EET 2019


[01:17:47 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:7e5bde93a1e7: build: Rename OBJDIRS variable to OUTDIRS
[01:17:48 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:e22ffb3805f6: tests: Unify output directory creation
[01:17:49 CET] <cone-755> ffmpeg 03James Almer 07master:06476249cd23: Merge commit '7e5bde93a1e7641e1622814dafac0be3f413d79b'
[01:17:49 CET] <cone-755> ffmpeg 03James Almer 07master:1c9ac700dd14: Merge commit 'e22ffb3805f6994bd1fd7ab73e6297f36a53f915'
[02:21:45 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:862914981693: tests: Drop duplicate variable declaration
[02:21:46 CET] <cone-755> ffmpeg 03James Almer 07master:44085b9951b0: Merge commit '8629149816930a43bf5a66b11c6224446cabd044'
[02:24:17 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:dad5fd59f3d6: tests: Enable CRC test for yuv4mpeg
[02:24:18 CET] <cone-755> ffmpeg 03James Almer 07master:bad70b7af6b9: Merge commit 'dad5fd59f3d6a8311365314cfcde0ebcd15c2b01'
[02:33:44 CET] <cone-755> ffmpeg 03Diego Biurrun 07master:5846b496f0a1: tests: Use a predefined function for lavf-rm test
[02:33:45 CET] <cone-755> ffmpeg 03James Almer 07master:5ab44ff20cdc: Merge commit '5846b496f0a1dd5be4ef714622940674305ec00f'
[08:42:59 CET] <j-b> 'tsup
[11:59:54 CET] <JEEB> can someone give me a quick run-down on LATM AAC vs ADTS AAC?
[12:00:09 CET] <JEEB> since it seems like more and more places are moving to LATM (for some reason)
[12:30:34 CET] <nevcairiel> both are simple containers around raw AAC streams
[12:30:41 CET] <nevcairiel> LATM is more complex and supports more features
[12:32:04 CET] <nevcairiel> LATM can theoretically contain multiple programs and multiple layers, whatever that exactly means, but ffmpeg only supports one of each
[12:32:55 CET] <nevcairiel> I could see your 22.2 stream use LATM layers, perhaps.
[12:37:30 CET] <kurosu> by now, I suppose 22 is not the actual number of channels, but also includes objects (ie 23008-3) ?
[12:38:22 CET] <nevcairiel> well that wouldnt exactly be AAC anymore then
[12:41:41 CET] <kurosu> well, the stream using AAC as an audio codec doesn't preclude it from being 23008-3? It's just that I haven't seen any atmos (which is already 3D audio) use more than 9.1.2 (or some such)
[12:42:09 CET] <kierank> JEEB: latm is lower overhead
[12:42:13 CET] <kurosu> "channel layout" (at least speaker setup)
[12:42:23 CET] <kierank> JEEB: goes to painful lengths to save bits
[12:42:28 CET] <kurosu> adding 10 more channels seems unlikely to be meant to be actual channels, that's what I meant
[12:44:11 CET] <kurosu> but well, you tell me, I'm likely wrong, just want to get educated
[12:44:12 CET] <nevcairiel> the latm header seems pretty long, it seems bigger then the ADTS header, but granted it also supports way more features
[12:44:56 CET] <nevcairiel> the aac profiles that fit into adts are even severely limited because it only has a limited bit field for it
[13:26:18 CET] <JEEB> kurosu: I'll be sure after I get the 22.2ch wagner 8K sample
[13:26:26 CET] <JEEB> but it seemed to just be normal AAC
[13:26:32 CET] <JEEB> with a 22.2ch map
[13:26:43 CET] <JEEB> (possibly multiple AAC streams)
[13:27:37 CET] <nevcairiel> that seems like a rather unlikely config for broadcast really
[13:27:57 CET] <nevcairiel> mix it all down to stereo in the end? =p
[13:28:08 CET] <JEEB> yea, it seems like just advertising
[13:28:18 CET] <JEEB> I've demo'd the tech at NHK in 2017
[13:28:25 CET] <JEEB> it was cool
[13:28:33 CET] <JEEB> but not something a normal person would have in his setup
[14:21:39 CET] <J_Darnley> JEEB: you dont think you could sell people 22 channels?  22 is bigger than 6.
[14:46:49 CET] <BBB> does anyone here have strong opinions on the closed-source thing? or do most people just not care so much?
[14:47:50 CET] <atomnuker> I don't like it, I could somewhat understand if it was a codec no one is interested in but this is h264
[14:48:16 CET] <nevcairiel> I like being able to use my hardware with ffmpeg, which in many cases means supporting access to a closed-source driver. That easily opens the door to someone asking whats the difference between a driver and just some library
[14:50:44 CET] <BradleyS> perception could be bad if you come off like american retail giants who move into town with low prices, take over by running smaller stores out of business, and then jack up the prices
[14:51:26 CET] <BradleyS> if there's a current expectation that certain features are provided, and later there's a wholesale removal, it comes off malicious even if it's not
[14:51:40 CET] <BradleyS> and comes off political even if it's not
[14:51:54 CET] <BradleyS> not an argument for or against, just something to think about
[14:53:00 CET] <BtbN> BBB, given how people are aggressively fighting some other closed source thing right now...
[14:53:07 CET] <BradleyS> there's a balance with what's technically good, philosophically good, legally good, and good for the users/customers... shift too far to any extreme and it won't be received well by some group
[14:53:48 CET] <BtbN> Only difference here is that it's for a hardware component. But the code needs quite some work from the looks of it.
[14:55:44 CET] <BBB> nevcairiel: that's a good point, I've been worrying about the driver vs. lib thing also, not just in terms of my personal opinion, but in terms of if you put a dividing line there, then people will try to play (cheat) to get into the harware list
[14:56:20 CET] <BBB> nevcairiel: it's also kind of a random line, it seems born out of convenience or necessity, I'm not sure I buy the system library thing when we're talking about custom hardware that nobody except BigCorps can afford
[14:56:28 CET] <BBB> (as opposed to consumer-level nvidia cards)
[14:56:37 CET] <BBB> so it's a very obscure line :-/
[14:57:05 CET] <nevcairiel> do we even have any bigcorp hardware support?
[14:57:44 CET] <BBB> that matrox thing did not appear to be targeted at consumers
[15:00:42 CET] <BradleyS> is any corp following a model where they keep things closed for a period of 2-5 years for market advantage and then open the source
[15:01:07 CET] <BtbN> probably not, they're too afroid of patent lawsuites if people get to dig around in their code
[15:01:19 CET] <BradleyS> yeah, tech patents in the us are a pain
[15:01:45 CET] <BradleyS> i'm mostly opposed but at the least they should be cut to a period like the aforementioned instead of 20 years
[15:32:39 CET] <iive> isn't there an open source implementation that we can replace the closed source one?
[15:34:25 CET] <JEEB> IIRC NDI worked pretty hard to squish open source implementations, although I don't know the details of that
[15:35:30 CET] <JEEB> and yes, in general the "letting non-OS closed source things in" thing should be cleared up. because right now it's grey and things like NDI can get pushed into FFmpeg due to not enough people caring
[15:35:39 CET] <JEEB> one way or another I mean
[15:40:02 CET] <j-b> BBB: it needs to be settled.
[15:40:21 CET] <j-b> Last year at NAB and demuxed, everyone is standardizing around FFmpeg/libav
[15:40:40 CET] <j-b> So everyone want to push their own crap on FFmpeg/libav and hope the project will maintain it for free for their customers
[15:41:18 CET] <j-b> We (videolabs) receive one FFmpeg patch contract per week (we refuse most) and it is always the integration of a crappy non-open source library
[15:42:38 CET] <j-b> Dolby, Zixi, NDI, DTS, Real and other folks
[15:42:46 CET] <BBB> I'm trying to bring it up, but not really getting any traction so far :-p
[15:42:56 CET] <j-b> "but our encoder is sooo amazing"
[15:44:03 CET] <j-b> VVC and AAC-ULL-ELD
[15:44:05 CET] <kurosu> dolby must be particularly delectable
[15:44:15 CET] <kurosu> well, dts too
[15:44:24 CET] <j-b> And I don't even speak about the new Dash extensions
[15:45:00 CET] <j-b> and the new ATSC will be new crap over crap
[15:45:15 CET] <JEEB> MMTP/TLV nîn
[15:45:23 CET] <JEEB> such a clusterduck
[15:48:55 CET] <nevcairiel> ATSC 3.0 is the worst crap in broadcast i've ever read
[15:49:05 CET] <nevcairiel> i dont envy anyone trying to implement that independently
[15:50:41 CET] <mayanksha> gsoc
[15:52:46 CET] <j-b> nevcairiel: yeah, horrible
[15:55:13 CET] <JEEB> nevcairiel: ATSC 3 is only one thing which contains the MMTP/TLV thingamajig
[15:55:30 CET] <JEEB> also unlike ATSC 3 broadcasts, I'm seeing an unfortunate amount of JP content with that being aired xD
[15:55:47 CET] <nevcairiel> well in my dayjob i dont really interact with asia
[15:55:52 CET] <nevcairiel> but US we cover
[15:55:53 CET] <JEEB> sure
[15:55:56 CET] <nevcairiel> so that may eventually bite us
[16:25:01 CET] <amaim_> Where can I find documentations about video/audio formats? for example the DHAV, I've been searching for a documentation(not about the code but about the file structure) about it and I can't find anything.
[17:05:47 CET] <durandal_1707> amaim_: what you want to know about DHAV?
[17:06:21 CET] <amaim_> The file structure, header contents,etc..
[17:06:45 CET] <amaim_> I'm trying to understand the DHAV code 
[17:06:49 CET] <durandal_1707> amaim_: that is proprietary info
[17:07:06 CET] <durandal_1707> amaim_: is something wrong about it?
[17:07:28 CET] <amaim_> No nothing wrong, I'm just trying to understand how demuxers work
[17:07:58 CET] <amaim_> So I chose DHAV (I was told it's an easy example) to educate myself
[17:08:18 CET] <durandal_1707> well its all in code
[17:08:39 CET] <durandal_1707> and there are much easier examples
[17:09:01 CET] <durandal_1707> and documented ones also, open source formats
[17:09:06 CET] <amaim_> Can you tell me one?
[17:09:11 CET] <amaim_> I was thinking maybe bmp
[17:09:21 CET] <amaim_> But that's an image format, I want a video one
[17:09:27 CET] <durandal_1707> matroska, nut, ....
[17:09:40 CET] <durandal_1707> bmp is image codec
[17:09:52 CET] <durandal_1707> not really codec actually
[17:10:01 CET] <amaim_> Okay I'll check matroska, great.
[17:10:22 CET] <amaim_> Thank you.
[17:10:23 CET] <durandal_1707> amaim_: are your working on format or codecs?
[17:11:15 CET] <amaim_> durandal_1707: I'm working on formats, my goal is to apply for the DICOM support project in GSoC
[17:11:42 CET] <amaim_> or HEIF
[17:11:44 CET] <jamrial> matroska demuxer is not the best introduction avformat demuxers...
[17:13:01 CET] <amaim_> What would you suggest @jamrial ?
[17:13:13 CET] <jamrial> an extremely simple one to get an idea of how to use the different callbacks is ivf
[17:14:50 CET] <jamrial> another less trivial is caf
[17:15:04 CET] <amaim_> Alright great, noted. thank you
[00:00:00 CET] --- Tue Mar 12 2019


More information about the Ffmpeg-devel-irc mailing list