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

[burek]

[00:00:09 CET] <nevcairiel> just got my build finished and even with d3d11 input i can only get like 30% encode usage, but this is transcoding a blu-ray source, so maybe it gets better with smaller resolutions or something like that. mind you, still 320 fps
[00:05:22 CET] <jkqxz> jamrial:  The MJPEG code has a lot of Js in it which need to be disentangled.
[00:06:41 CET] <nevcairiel> J for JPEG.
[00:06:42 CET] <nevcairiel> :D
[00:11:12 CET] <jkqxz> Any opinions on having an OpenCL project on GSoC?
[00:13:28 CET] <jkqxz> atomnuker's Vulkan one is somewhat speculative and researchy, so I was thinking more straightforward practical stuff like scaling and deinterlacing.
[00:15:52 CET] <atomnuker> deinterlacing yeah, but I think scaling's better suited for vulkan (unless you can sample from textures in a non-quantized way like you do in opengl)
[00:16:19 CET] <jkqxz> Quantised how?
[00:16:29 CET] <Chloe> nevcairiel: I'm quite ill atm, but as soon as I get well enough to look at a screen for more than 10 min I'll be able to send my patches for WSL and linked-lists
[00:16:50 CET] <Chloe> sorry it's taking so long, I'd rather the patches be good, and I dont think there's really any rush anyway
[00:17:36 CET] <jkqxz> (Are we still in the ABI-unstable period?)
[00:18:14 CET] <atomnuker> jkqxz: nvm, I'm tripping, yeah, that'll be a fine project to do, add me as a backup mentor if you're thinking of adding it
[00:18:47 CET] <atomnuker> we'll be able to use the code in vulkan too so that'll be cool
[00:21:30 CET] <jamrial> jkqxz: sorta? strictly speaking, until we tag ffmpeg 4.0 we could still play with the ABI as there's nothing to be binary compatible with except previous git snapshots post bump
[00:21:51 CET] <cone-031> ffmpeg 03Karthick Jeyapal 07master:046a9468688a: MAINTAINERS: Add dashenc maintainer
[00:23:12 CET] <jkqxz> atomnuker:  Yeah.  Currently the CL code is built at runtime, but there is nothing stopping it being SPIRVified at build time instead and used in the same way with Vulkan.
[00:23:42 CET] <wm4> I'd still like to make a new side data API, but since I don't know how to reconcile old and new APIs I didn't try anything yet
[00:45:39 CET] <atomnuker> jkqxz: I was thinking of the code which created the LUTs with per-pixel weights, but yeah, there's code out there to turn opencl to spriv
[00:46:22 CET] <atomnuker> though the glsl code in mpv which handles general scaling is just a few lines IIRC so duplication wouldn't be a problem
[00:46:53 CET] <nevcairiel> scaling in general is just a simple kernel of varying size, isnt it
[00:47:05 CET] <jkqxz> Well, you could spend the whole time writing different scaling algorithms.
[00:47:15 CET] <jkqxz> nevcairiel:  Generally yes.
[00:48:52 CET] <nevcairiel> making those kernels is probably more involved then the shader to apply them
[01:15:56 CET] <jkqxz> atomnuker:  <https://0x0.st/sqw0.txt>
[01:16:02 CET] <jkqxz> Maybe I've written too much.
[01:24:48 CET] <jamrial> jkqxz: the qualification task reads like it's the same as the project proper
[01:27:46 CET] <jkqxz> I guess it's meant to be "write anything which works", even if it's basically useless.
[01:28:05 CET] <jkqxz> (I would regard a, say, vflip filter as satisfying that, even though it probably wouldn't be applied.)
[01:28:21 CET] <atomnuker> I think scaling and color conversion should go in the same filter, it really doesn't make sense not to since you'd be wasting resources splitting them up
[01:28:30 CET] <atomnuker> other than that looks fine
[01:30:25 CET] <jkqxz> Combining them is significantly more work once you want proper colour conversion.  (See how vf_colorspace and vf_scale are separate, say.)
[01:31:19 CET] <nevcairiel> yeah doing it properly is quite involved
[01:31:39 CET] <nevcairiel> of course if you go from 420 to rgb or something, you need to involve scaling, so having some automagic that resolves that would be nice
[01:34:08 CET] <jkqxz> If they are separate then it should be doable reasonably well with relatively simple filtering, but I agree that a full scaler there gives you more options.
[03:42:46 CET] <cone-076> ffmpeg 03James Almer 07master:172564ace9c5: configure: fix vaapi_encode_example dependencies
[03:42:46 CET] <cone-076> ffmpeg 03James Almer 07master:f0320afab977: avfilter/Makefile: skip compiling vaapi_vpp.h when vaapi is not enabled
[04:17:55 CET] <cone-076> ffmpeg 03Richard Shaffer 07master:8a4cc0a2567f: avformat: add option to parse/store ID3 PRIV tags in metadata.
[04:43:27 CET] <cone-076> ffmpeg 03Vishwanath Dixit 07master:1948b76a1bea: avformat/hlsenc: closed caption tags in the master playlist
[07:22:49 CET] <SortaCore> why does libopenh264 only have -profile option?
[07:23:07 CET] <SortaCore> https://github.com/cisco/openh264/issues/1529#issuecomment-89064235 seems to indicate options are available in priv_data
[07:33:16 CET] Action: SortaCore hunts for actual ffmpeg openh264 implementation
[07:42:01 CET] <SortaCore> ...openh264 looks kinda botched
[07:45:08 CET] <SortaCore> iRCMode is only ever set to rate-control quality mode, but iMaxQp/iMinQp is never set
[07:45:27 CET] <SortaCore> shouldn't it be bitrate quality mode?
[07:45:43 CET] <SortaCore> and there's an exposure of -profile but not -level?
[07:46:37 CET] <SortaCore> can anyone shed some light on this
[07:52:36 CET] <SortaCore> (I'll be getting to bed)
[10:01:14 CET] <JEEB> if you feed stuff avfilter, did you lose AV_FRAME_DATA_*?
[10:01:21 CET] <JEEB> *to avfilter
[10:01:27 CET] <JEEB> I think you did if I recall correctly
[11:31:32 CET] <cone-910> ffmpeg 03Jun Zhao 07master:4dbae00bac7a: lavfi/vf_xxx_vaapi: fix typo.
[13:16:13 CET] <JEEB> hmm, with the ATSC caption side data, it seems like there can be multiple streams of them at the same time from the same video stream?
[13:20:58 CET] <wm4> yeah, apparently
[13:21:00 CET] <kierank> huh
[13:21:03 CET] <kierank> should only be one
[13:21:10 CET] <kierank> there's a fixed bitrate in atsc
[13:21:21 CET] <kierank> the web guys do all sorts of weird shit but the broadcast ones have to be compliant
[13:24:07 CET] <JEEB> hmm
[13:24:24 CET] <JEEB> I just got noted that a video track could have multiple "tracks" of captions in broadcast
[13:24:29 CET] <JEEB> haven't seen a sample yet
[13:24:33 CET] <JEEB> and it was from ATSC broadcast
[13:24:38 CET] <JEEB> English vs Spanish etc
[13:25:23 CET] <JEEB> ok, it seems like a "track" is called a "channel"
[13:25:28 CET] <JEEB> CC1,2,3 etc
[13:26:13 CET] <wm4> aren't there 4 max?
[13:26:48 CET] <JEEB> haven't looked into that yet
[13:46:59 CET] <kierank> JEEB: yes multiple tracks internally
[13:47:14 CET] <JEEB> yea, that's what I meant "within the same video track"
[13:49:59 CET] <kierank> i thought you meant multiple SEIs
[13:50:05 CET] <kierank> it's a single SEI with multiple internal tracks
[13:50:08 CET] <JEEB> ah
[17:43:59 CET] <jdarnley> Why is ffmpeg erroring out without analysing this file?
[17:46:56 CET] <jdarnley> atomnuker: do you remember anything about the dirac parser?
[18:07:56 CET] <durandal_1707> jdarnley: what you need?
[18:09:07 CET] <jdarnley> I wish I knew.
[18:09:18 CET] <jdarnley> How do I make ffmpeg read the frame dimensions out of this file?  I'll start witht hat.
[18:10:14 CET] <jdarnley> ffmpeg doesn't enter av_dirac_parse_sequence_header
[18:15:56 CET] <durandal_1707> jdarnley: whats error you get?
[18:16:25 CET] <durandal_1707> can you play it with other players?
[18:16:40 CET] <durandal_1707> is file valid?
[18:16:53 CET] <jdarnley> ha ha
[18:17:01 CET] <jdarnley> It might be valid.
[18:17:41 CET] <jdarnley> It was created with my own code in ffmpeg and can only be decoded by other code of mine I am trying to add to ffmpeg
[18:18:04 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Format dirac probed with size=2048 and score=100
[18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Before avformat_find_stream_info() pos: 0 bytes read:32768 seeks:0 nb_streams:1
[18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] Could not find codec parameters for stream 0 (Video: dirac, 1 reference frame, none): unspecified size
[18:18:05 CET] <jdarnley> Consider increasing the value for the 'analyzeduration' and 'probesize' options
[18:18:05 CET] <jdarnley> [dirac @ 0x558e0756e6c0] After avformat_find_stream_info() pos: 248728 bytes read:248728 seeks:0 frames:0
[18:18:31 CET] <kierank> jdarnley: parser needs to parse the file
[18:19:00 CET] <durandal_1707> split it into packets for decoder
[18:20:14 CET] <jdarnley> cock!  I did forget that 1 line change in the parser
[18:22:54 CET] <jdarnley> so where did that commit disappear to?
[18:55:00 CET] <atomnuker> jamrial: everything
[18:55:20 CET] <atomnuker> keep in mind the parser doesn't support packets with distance to next packet == 0
[18:55:47 CET] <jamrial> i think you meant to ping jdarnley
[18:59:12 CET] <SortaCore> the openh264 encoder is need of some extra parameters exposed
[19:00:14 CET] <atomnuker> sorry, did mean jdarnley 
[19:19:58 CET] <SortaCore> unknown option --disable-ffserver?
[19:20:37 CET] <durandal_1707> SortaCore: whats issue?
[19:21:01 CET] <SortaCore> well, my previous configure was set to build static, and enable all the programs except ffserver
[19:21:18 CET] <SortaCore> I just git pulled from master, and now the configure isn't recognising --disable-ffserver
[19:21:46 CET] <SortaCore> It's not listed under program options in --help, so was ffserver removed entirely?
[19:23:42 CET] <kierank> yes
[19:24:07 CET] <SortaCore> ok
[19:24:20 CET] <SortaCore> and there's a severe lack of openh264 options, is anyone working on that
[19:25:09 CET] <SortaCore> there's profile but no level, no preset, tune etc, and the profile doesn't list options in ffmpeg.exe -help like it does in some other h264 codecs
[19:27:08 CET] <SortaCore> no crf option, although there are qpMin/Max available in openh264, they're not set at all in ffmpeg
[19:27:47 CET] <SortaCore> there also seems to be a bitrate, and quality mode rate controls, but the encoder always uses quality
[19:28:25 CET] <nevcairiel> noone cares about openh264, and neither should you
[19:28:25 CET] <SortaCore> also a complexity mode, not sure what that's about
[19:29:22 CET] <SortaCore> I don't want to GPL my code due to libx264 licensing :p
[19:29:32 CET] <nevcairiel> openh264 is a super terrible encoder though
[19:29:53 CET] <nevcairiel> it only supports one profile, so no options needed there, and level is just a function of bitrate and other properties, manually setting it makes no sense
[19:31:04 CET] <SortaCore> I saw code inside openh264's repo that indicated it had support for main and high
[19:31:22 CET] <SortaCore> but ignoring that, the other params should be there
[19:31:29 CET] <SortaCore> no point half-supporting something
[19:32:09 CET] <nevcairiel> feel free to make a patch
[19:32:14 CET] <nevcairiel> dont expect anyone else to waste their life :)
[19:32:17 CET] <SortaCore> https://github.com/cisco/openh264/wiki/TypesAndStructures#eprofileidc
[19:32:23 CET] <BtbN> might as well just use mpeg2 instead
[19:32:40 CET] <nevcairiel> just because it defiens those enums doesnt mean it actually does something with it
[19:32:45 CET] <nevcairiel> the docs clearly state its features
[19:32:46 CET] <SortaCore> ...how do you guys know if it's a bad encoder?
[19:32:58 CET] <BtbN> by looking at what it produces
[19:33:06 CET] <SortaCore> produces from what?
[19:33:15 CET] <BtbN> video oO
[19:33:42 CET] <SortaCore> yea, but what program is producing it?
[19:34:23 CET] <nevcairiel> that thing comes with its own  console encoder thing you can use to test it
[19:36:50 CET] <SortaCore> I'll look into it
[19:37:08 CET] <SortaCore> what's the style guide and patch how-to for git noobs
[19:37:14 CET] <BtbN> openh264 was designed for video-conferencing without paying roaylities
[19:37:31 CET] <BtbN> It originally only supported baseline h264
[19:37:44 CET] <BtbN> and even on high, which I doubt it actually supports fully, it looks terrible
[19:39:06 CET] <nevcairiel> the only "main" feature it even supports is using cabac, no other features are supported as far as I can tell
[19:40:35 CET] <SortaCore> atm I'm not particularly concerned with quality
[19:40:52 CET] <BtbN> just use mpeg2 then
[19:41:18 CET] <SortaCore> I am providing an interface for all the h264 codecs, and the parameters like preset, profile etc, if they're there in the codec, the user should be able to set them
[19:41:47 CET] <BtbN> the presets are highly encoder specific. Or even highly x264 specific. Same for crf.
[19:41:49 CET] <SortaCore> I don't want to deny level when it's available in the codec
[19:42:42 CET] <SortaCore> so out of curiosity, what do people use instead of h264 for their non-gpl code?
[19:42:52 CET] <SortaCore> *instead of openh264
[19:43:08 CET] <nevcairiel> nothing
[19:43:15 CET] <BtbN> some commercial encoder probably. Or they decice not to care.
[19:43:19 CET] <Gramner> commercially licensed x264
[19:43:21 CET] <nevcairiel> x264 is the only good h264 encoder
[19:43:30 CET] <nevcairiel> which is not pure commercial
[19:43:49 CET] <rcombs> are there good pure-commercial ones?
[19:44:01 CET] <rcombs> I know some people use main concept for some reason
[19:44:13 CET] <BtbN> There's a H264 encoder in Windows
[19:44:18 CET] <SortaCore> well, qsv and nvenc don't require GPL do they?
[19:44:26 CET] <SortaCore> although redistribution is a bit odd
[19:44:26 CET] <BtbN> those are hardware encoders.
[19:44:32 CET] <RiCON> mainconcept used to come close to x264 in those tests
[19:44:49 CET] <BtbN> But really, I think pretty much everyone except Browsers use x264
[19:45:03 CET] <rcombs> there's a software encoder in macOS as well but iirc it's worse than the hardware encoder
[19:45:21 CET] <rcombs> dunno whose it is originally, but I think it's the same one apple uses for everything and it's real bad
[19:45:26 CET] <tmm1_> huh i didn't know x264 had commercial licensing options
[19:45:26 CET] <rcombs> (e.g. iTunes)
[19:45:41 CET] <rcombs> dunno if it's the same as Compressor Dot App uses
[19:46:17 CET] <SortaCore> hardware or software aside, the qsv/nvenc aren't gpl?
[19:47:08 CET] <rcombs> well you can use quicksync via VAAPI
[19:47:26 CET] <rcombs> and there's a different QSV implementation that's MIT these days
[20:59:55 CET] <SortaCore> so er, what's the style guide and patch how-to for git noobs
[21:01:12 CET] <atomnuker> http://ffmpeg.org/developer.html#Contributing
[21:57:34 CET] <j-b> Heya, who owns the DTS decoder in libavcodec?
[21:59:43 CET] <wm4> foo86
[21:59:44 CET] <durandal_1707> j-b: me, for legal stuf contact trump
[22:00:05 CET] <j-b> durandal_1707: seriously you?
[22:00:08 CET] <j-b> wm4: ah, ok
[22:01:27 CET] <durandal_1707> j-b: you got some letters?
[22:01:45 CET] <j-b> durandal_1707: no, I want to give money for the DRC feature :)
[22:02:08 CET] <durandal_1707> drc?
[22:02:31 CET] <j-b> https://trac.ffmpeg.org/ticket/6803
[22:28:40 CET] <nevcairiel> You know most people would pay you to get a decoder which violates the spec and removes that anti-feature =p
[22:30:06 CET] <j-b> nevcairiel: sure.
[22:30:17 CET] <j-b> nevcairiel: does not mean some people don't want it
[22:30:44 CET] <nevcairiel> The problem with that feature is that it depends on the bitstream and will vary widely from file to file
[22:30:51 CET] <nevcairiel> if you want range compression, should do that on raw audio
[22:31:16 CET] <j-b> nevcairiel: I don't think I argued for the usefulness of this feature.
[22:31:48 CET] <j-b> if I did seem to, then sorry.
[22:31:57 CET] <nevcairiel> Wanting to throw money at it is basically that, isnt it
[22:32:05 CET] <j-b> nevcairiel: it is not.
[22:32:07 CET] <nevcairiel> unless you're crazy and have too much money? I would take some
[22:32:12 CET] <j-b> idiotic users are idiots: https://trac.videolan.org/vlc/ticket/19024
[22:32:22 CET] <j-b> and we receive donations from idiotic users
[22:32:42 CET] <nevcairiel> those are not a binding contract
[22:33:04 CET] <j-b> nevcairiel: sure, what bounty can you take care of?
[22:34:06 CET] <j-b> https://wiki.videolan.org/Bounties#Libavcodec_features
[22:34:30 CET] <j-b> (feel free to suggest new ones)
[22:35:26 CET] <nevcairiel> we got speedhq these days, btw
[22:35:56 CET] <j-b> nevcairiel: all versions?
[22:35:59 CET] <j-b> nevcairiel: who did it?
[22:36:03 CET] <nevcairiel> metasound too
[22:36:07 CET] <nevcairiel> no idea how complete those are
[22:36:09 CET] <nevcairiel> but they exist
[22:36:20 CET] <durandal_1707> metasound is incomplete
[22:36:31 CET] <j-b> IIRC, metasound was not complete, yes
[22:36:52 CET] <j-b> I'm wondering when we will bump MVC to 10.000¬
[22:37:10 CET] <nevcairiel> anton was working on that, but i havent seen him in months
[22:37:16 CET] <durandal_1707> mvc should die
[22:37:40 CET] <nevcairiel> for speedhq, http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=2a293ec7ac72723b5f07aa804bb981ce1de35b82
[22:37:48 CET] <nevcairiel> apparently even had support in implementing this from NewTek
[22:37:59 CET] <nevcairiel> This decoder can decode all existing SpeedHQ formats (SHQ05, 7, and 9),
[22:37:59 CET] <nevcairiel> including correct decoding of the alpha channel.
[22:38:03 CET] <nevcairiel> or so it claims
[22:38:20 CET] <j-b> ah, sure, Sesse
[22:38:36 CET] <j-b> FICV?
[22:39:00 CET] <durandal_1707> what?
[22:39:20 CET] <j-b> "Mirillis' Action! tool (FICV codec)"
[22:39:32 CET] <nevcairiel> we have a decoder for that, but again no clue how good
[22:40:33 CET] <j-b> Sad!
[22:40:37 CET] <nevcairiel> you would think at some point someone would invent the ultimate screen capture codec and we wouldnt have a new one every couple years
[22:41:23 CET] <j-b> lol :)
[22:41:55 CET] <durandal_1707> there is ultimate screen capture codec
[22:42:05 CET] <j-b> x264?
[22:42:26 CET] <durandal_1707> no
[22:42:28 CET] <nevcairiel> probably too slow
[22:44:50 CET] <durandal_1707> j-b: see fourcc SCPR, your vlc lavc code have issues with playing it
[22:45:16 CET] <j-b> oh?
[22:45:20 CET] <j-b> durandal_1707: thx for the pointer
[22:45:38 CET] <j-b> ScreenPressor
[22:47:22 CET] <durandal_1707> there is v3 of codec, need to finish it
[22:47:25 CET] <jkqxz> ... whatever hardware encoder you can use directly on the GPU to capture the screen completely for free?  CPU overhead sucks.
[22:48:37 CET] <j-b> JPEG2K?
[22:49:09 CET] <j-b> oh, btw, we would pay for a JP2K decoder on GPU
[22:50:12 CET] <nevcairiel> that seems slightly unlikely
[22:50:14 CET] <jkqxz> OpenCL?
[22:50:20 CET] <jkqxz> Doesn't sound very fun.
[22:50:25 CET] <nevcairiel> for someone to implement, i mean
[22:51:01 CET] <j-b> jkqxz: yup
[22:51:07 CET] <j-b> but it's easy to find 30K on that
[22:52:41 CET] <nevcairiel> the dca DRC thing looks pretty trivial fwiw, read index from bitstream, lookup scale factor in table, scale samples after reconstruction
[22:52:42 CET] <jkqxz> Does it actually have to be faster than a CPU?  Making a shitty one would be reasonably straightforward, I think.
[22:54:01 CET] <jkqxz> (I.e. is this meant to be for increased speed or just for offload.)
[22:54:17 CET] <atomnuker> lol, j2k entropy encoding on the gpu
[22:54:29 CET] <atomnuker> j2k has possibly the slowest designed entropy coder ever
[22:54:48 CET] <jkqxz> Yep, hence the question :P
[22:54:59 CET] <atomnuker> the transform and quantization are all doable on the gpu and the cpu but that's a thousand of the overhead and really not a problem
[22:55:13 CET] <atomnuker> *thousanth
[22:58:25 CET] <atomnuker> well, its doable on the GPU completely
[22:58:45 CET] <atomnuker> you just need so many tiles that its pointless to call it compressed anymore
[22:59:03 CET] <jkqxz> "decoder" ^
[22:59:07 CET] <j-b> jkqxz: decoding, not encoding
[22:59:20 CET] <j-b> and, as far as I know, this is for 256 tiles
[22:59:31 CET] <j-b> nevcairiel: yes, it is not hard to do, I believe.
[22:59:47 CET] <nevcairiel> although perhaps a bit unclear how it interacts with HD extensions
[23:02:13 CET] <atomnuker> j-b: could I have a sample? none of the 2 encoders support tile size setting
[23:03:16 CET] <j-b> atomnuker: a sample of those JP2K crap?
[23:03:28 CET] <atomnuker> yep
[23:03:33 CET] <j-b> atomnuker: any DCP should have this
[23:03:46 CET] <j-b> IIRC, blocks of 64x64 that are independent
[23:03:55 CET] <j-b> I can check tomorrow.
[23:03:57 CET] <nevcairiel> luckily i've only very rarely seen jp2k stuff, distributing DCPs has not come into fashion yet
[23:04:10 CET] <atomnuker> I've been looking for a jp2k DCP for ages, I can't find one anywhere and I don't have any private tracker regs
[23:04:22 CET] <atomnuker> I've got a dnxhd dcp though
[23:04:26 CET] <j-b> atomnuker: https://streams.videolan.org/streams/DCP/ 
[23:04:44 CET] <j-b> atomnuker: and I got around 25 at the office, totally around 4TB of DCPs, if you want.
[23:05:01 CET] <nevcairiel> i get the occasional request to handle the separate mono pcm streams from DCP though, i just tell them to bugger off, but shrug
[23:05:01 CET] <j-b> latest FFmpeg + openjpeg 2.3.0 is getting quite good at decoding those ;)
[23:05:07 CET] <atomnuker> of full movies?
[23:05:16 CET] <j-b> atomnuker: the ones at the office, yes.
[23:05:28 CET] <atomnuker> I need to find an excuse to go to paris
[23:06:03 CET] <j-b> atomnuker: can I ask why do you care about DCP? :D
[23:06:07 CET] Action: j-b is curious
[23:06:18 CET] <j-b> (besides, it's fun :)
[23:06:52 CET] <atomnuker> its the ultimate form of source material you can get for encoding, and its not staged to "push encoders to the limit", its real content
[23:06:57 CET] <atomnuker> and because its rare :)
[23:07:19 CET] <nevcairiel> lossy compressed formats, and he calls that ultimate
[23:07:25 CET] <j-b> well, my problem is mostly that decoders and encoders for that are very expensive.
[23:07:55 CET] <atomnuker> nevcairiel: BDs are worse
[23:08:12 CET] <nevcairiel> obviously
[23:08:22 CET] <nevcairiel> but lossless would be the real ultimate source
[23:08:55 CET] <atomnuker> j-b: I might do a hybrid j2k decoder if I find it interesting, just to prove they have their use
[23:09:35 CET] <j-b> atomnuker: well, my issue is that KAKADU is way faster than ffmpeg or ffmpeg+openjpeg
[23:09:53 CET] <atomnuker> how much faster, in terms of fps?
[23:09:57 CET] <durandal_1707> then make it faster
[23:10:02 CET] <j-b> atomnuker: twice?
[23:10:12 CET] <durandal_1707> instead of paying for drc
[23:10:14 CET] <nevcairiel> the native jp2k decoder in ffmpeg is barely optimized at all
[23:10:24 CET] <j-b> durandal_1707: I can pay for both :)
[23:10:31 CET] <j-b> durandal_1707: DRC is probably 1000¬ 
[23:10:49 CET] <durandal_1707> j-b: drc should be 100 max
[23:10:53 CET] <j-b> durandal_1707: JP2K XYZ decoder on GPU or hybrid would be around 30k¬
[23:10:59 CET] <nevcairiel> 1000 for such a simple feature?
[23:11:07 CET] <nevcairiel> how much do idiot users donate? :p
[23:11:14 CET] <j-b> nevcairiel: depends.
[23:11:19 CET] <j-b> usually 4¬
[23:11:23 CET] <j-b> sometimes 0.3 BTC
[23:11:41 CET] <j-b> durandal_1707: nevcairiel: ok, let's say 500¬, ok?
[23:11:57 CET] <nevcairiel> maybe i should've just shutup and just build it
[23:12:19 CET] <durandal_1707> lol, we are on wrong side of shop
[23:12:24 CET] <j-b> no.
[23:12:42 CET] <j-b> Selling to B2B can make a shitload more money
[23:13:00 CET] <j-b> nevcairiel: durandal_1707: seriously guys, if there are some features that can benefit us, we can add bounties.
[23:13:48 CET] <durandal_1707> j-b: there is even j2k unmentored project
[23:13:51 CET] <nevcairiel> if you find me some magic dolby spec i will fix truehd+atmos bitstreaming, but dolby hides their specs well :(
[23:14:34 CET] <Chloe> j-b: any bounties for rewriting lavd to be a useful library?
[23:15:06 CET] <durandal_1707> lol, thats vlc job
[23:15:06 CET] <j-b> Chloe: sorry, no, since we don't care yet about lavd
[23:15:21 CET] <Chloe> shame
[23:15:22 CET] <j-b> Chloe: libavfi, probably
[23:15:28 CET] <j-b> but lavd, not yet
[23:15:40 CET] <Chloe> libavfi?
[23:15:46 CET] <Chloe> libav's lavfi?
[23:15:52 CET] <j-b> ffmpeg libavfilter
[23:16:06 CET] <j-b> dunno the official shortname :)
[23:16:08 CET] <Chloe> what do you need for lavfi
[23:16:19 CET] <j-b> Chloe: because filters are fun
[23:16:33 CET] <j-b> nevcairiel: weren't you the one mentionning EAC3->AC3 simple conversino?
[23:16:47 CET] <durandal_1707> lavfi hhave more than 300 filters, its enough
[23:16:55 CET] <nevcairiel> j-b: nah that wasnt me
[23:17:04 CET] <j-b> nevcairiel: sorry then
[23:17:15 CET] <Chloe> j-b: 'libVLC API for filters' this?
[23:17:28 CET] <j-b> Chloe: libavfi module inside vlc
[23:18:40 CET] <j-b> 451779 12:47 <+kierank> j-b: yes there are optional "aids" in the bitstream for set top boxes to transcode
[23:18:46 CET] <Chloe> it doesnt matter actually, I dont have the hardware to compile vlc
[23:18:58 CET] <j-b> <+kierank> j-b: it's in the spec somewhere, libavcodec skips over the field
[23:19:04 CET] <j-b> nevcairiel: indeed, it was kierank 
[23:19:16 CET] <j-b> anyway, that is a feature that we could pay for too.
[23:19:27 CET] <j-b> Chloe: ah?
[23:19:32 CET] <kierank> pffft j2k
[23:19:41 CET] <durandal_1707> Chloe: what? toaster?  ask  carl some money
[23:19:46 CET] <Chloe> j-b: if you ever want lavd to be useful, hmu
[23:19:57 CET] <j-b> Chloe: ok
[23:20:11 CET] <durandal_1707> Chloe: we have money too
[23:20:38 CET] <Chloe> durandal_1707: yes, I have a toaster with a 1060 :-)
[23:20:46 CET] <Chloe> I think my CPU is actually faulty
[23:21:00 CET] <j-b> Also, if some people like pain, I have requests on mp4 metadata...
[23:26:25 CET] <Chloe> durandal_1707: we lack bounties though
[23:27:08 CET] <kierank> durandal_1707: and libavfilter sucks
[23:27:55 CET] <wm4> *dramatic music*
[23:28:21 CET] <kierank> DONT INSULT THE GLORIOUS LEAD^H^H FFMPEG PROJECT
[23:29:06 CET] <j-b> Chloe: would people be more interested in bounties if they were in BTC?
[23:29:25 CET] <nevcairiel> personally i would be less interested =p
[23:30:12 CET] <durandal_1707> kierank: thank you for your contributions to lavfi
[23:30:21 CET] <kierank> api sucks
[23:30:29 CET] <kierank> usable only from ffmpeg cli to printf nice values
[23:30:29 CET] <j-b> still, interested I am, for this stupid DRC and for EAC3->AC3
[23:30:45 CET] <j-b> in addition to new codecs
[23:31:26 CET] <durandal_1707> j-b: btc is dead
[23:31:40 CET] <j-b> durandal_1707: I know, right>
[23:33:01 CET] <wm4> even I have some severe issues with lavfi's API
[23:33:22 CET] <Chloe> j-b: i doubt it
[23:33:37 CET] <Chloe> and by 'we' i meant ffmepg themselves
[23:39:38 CET] <wm4> tmm1_: do you remember who our effective hls.c maintainer is?
[23:43:34 CET] <durandal_1707> carl
[23:54:23 CET] <tmm1_> i'm not sure
[00:00:00 CET] --- Thu Jan 25 2018