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

[burek]

[00:35:44 CEST] <Compn> BBB : its tough to work on open source, i've been told to leave a bunch , yet i have not. just gotta keep working on things and ignore the haters i guess.
[00:39:01 CEST] <Compn> BBB : i hope you stick around, you seem more level headed than most
[00:42:15 CEST] <klaxa> so if i wanted to expose a connected tcp client's address in the public api where would i put that? URLContext? AVIOContext? also what kind of field? char* seems inapropriate unless name resolving is done and then it may be too long
[00:43:03 CEST] <atomnuker> avdict as metadata?
[00:46:05 CEST] <klaxa> ok sounds reasonable, neither URLContext nor AVIOContext have a metadata dict yet though, where would it make more sense? i'm leaning toward AVIOContext since that's what the "network level code" already interfaces with and i think the URLContext itself is private to AVIOContext as well
[00:50:02 CEST] <atomnuker> why do you need the client's address?
[00:50:17 CEST] <atomnuker> couldn't you figure it out in some other way?
[00:52:06 CEST] <klaxa> not really, i'd need the fd
[00:52:18 CEST] <klaxa> and i mean i'd kind of like to know who connects to my stream no?
[00:53:09 CEST] <atomnuker> yeah
[00:53:29 CEST] <atomnuker> how would multiple clients work?
[00:53:54 CEST] <klaxa> the client's AVIOContext would get the address, so each client has its own address
[00:54:13 CEST] <klaxa> would have to be added in avio_accept() i think
[00:58:48 CEST] <klaxa> hmm might require even more work on lower levels
[01:01:26 CEST] <kierank> klaxa: you should really do this in your own code
[01:01:35 CEST] <kierank> there are so many tcp examples online
[01:01:40 CEST] <kierank> it's like 100 lines of code
[01:01:50 CEST] <klaxa> but i can't get the filedescriptor
[01:01:59 CEST] <atomnuker> he's using lavf's http server
[01:02:19 CEST] <klaxa> it's in AVIOContext->private(URLContext)->HTTPContext->URLContext->TCPContext->fd
[01:02:37 CEST] <kierank> atomnuker: I am aware but simple http servers are not exactly a novel problem
[01:03:02 CEST] <kierank> not to mention lavf shouldn't have a damn http server inside it
[01:08:44 CEST] <JEEB> yea, a module for nginx or something could be a more interesting proposition. let the HTTP pros handle the HTTP part, and what the primary goal is to provide actual serving of multimedia
[01:09:10 CEST] <JEEB> that way you don't have to then reinvent the wheel for HTTP/2, or that new funky UDP based thing by GOOG
[01:10:12 CEST] <klaxa> module == cgi stuff or something else?
[01:10:47 CEST] <JEEB> there are actual modules
[01:10:56 CEST] <JEEB> like https://github.com/sergey-dryabzhinsky/nginx-rtmp-module/
[01:11:14 CEST] <JEEB> (that takes in RTMP and exports HLS/DASH)
[01:11:20 CEST] <JEEB> (in addition to RTMP)
[01:25:47 CEST] <klaxa> maybe for starters i should look into using a different lib for the network stuff like wm4 suggested then?
[01:26:41 CEST] <klaxa> although tbh it kinda does hurt abandoning the api i wrote (apparently very controversial as i noted after the fact), but if it helps the code to be better, so be it
[02:22:54 CEST] <klaxa> JEEB: reading about how to write nginx modules, this is definitely interesting, thanks!
[02:23:10 CEST] <JEEB> :)
[02:23:18 CEST] <JEEB> yea, and it lets you use all the infra they have
[04:37:38 CEST] <Chloe> ffserver as an nginx module sounds nice
[04:41:19 CEST] <atomnuker> yeah, afaik what people do currently is they make ffmpeg dump a bunch of segments in a dir somewhere with a playlist and nginx serves them
[04:42:30 CEST] <Chloe> I thinking JEEB actually had an example for that (though I cantremember if he showed the config)
[13:39:50 CEST] <cone-743> ffmpeg 03Carl Eugen Hoyos 07master:2442cf3615a1: lavf/os_support: Only compile inet_aton() if getaddrinfo() is needed.
[18:09:56 CEST] <BtbN> Why is AVCodecContext::sw_pix_fmt unused for encoding? I could use it in nvenc.
[18:10:50 CEST] <wm4> it's set in the frames_ctx
[18:13:22 CEST] <BtbN> What if there is no frames_ctx? That value is pretty much the only reason why a hw_frames_ctx is required.
[18:13:28 CEST] <BtbN> A user can totally allocate CUDA frames on their own
[18:17:46 CEST] <wm4> but a user can't use cuda frames without frames_ctx
[18:17:55 CEST] <BtbN> he can, why couldn't he?
[18:17:59 CEST] <wm4> they're mandatory
[18:18:03 CEST] <BtbN> I don't see why
[18:18:07 CEST] <BtbN> a hw_device_ctx is enough
[18:18:12 CEST] <wm4> because that's how it works
[18:18:17 CEST] <BtbN> no
[18:18:24 CEST] <wm4> the frames_ctx exists exactly the represent such extra metadata
[18:18:33 CEST] <wm4> *to
[18:18:34 CEST] <BtbN> They exist to take frame allocation from you
[18:18:43 CEST] <wm4> that's just on top
[18:18:44 CEST] <BtbN> In this case, the user wants to pass mapped OpenGL textures.
[18:18:55 CEST] <wm4> there are some frame contexts which don't even support allocation
[18:18:58 CEST] <atomnuker> other hwaccels need extra metadata
[18:18:58 CEST] <BtbN> So a hw_frames_ctx is impossible to use without a pointless copy
[18:19:14 CEST] <wm4> why would it need a copy
[18:19:29 CEST] <BtbN> Because you can only get pre-allocated frames from the hw_frames_ctx
[18:19:33 CEST] <atomnuker> technically you can create a hwframescontext and attach it to avframes
[18:19:39 CEST] <atomnuker> the fields are public
[18:19:47 CEST] <BtbN> It's pointless
[18:20:07 CEST] <BtbN> nvenc works fine without a hw_frames_ctx. The only value it takes from it is the sw_pix_fmt, which avctx itself has a field for
[18:21:54 CEST] <wm4> BtbN: you can set an allocator on them
[18:22:07 CEST] <BtbN> Which is useless if you already have your data
[18:22:09 CEST] <wm4> I'm using user allocated hw frames myself (though for decoding)
[18:23:01 CEST] <wm4> well in theory AVFrame would only need a data field for anything
[18:23:10 CEST] <wm4> because you could put the other params into the AVCodecContext
[18:23:20 CEST] <wm4> but we're moving away from that
[18:26:31 CEST] <BtbN> The hw_device_ctx was introduced specifically to not always need a full hw_frames_ctx
[18:27:05 CEST] <wm4> well I'll leave it to jkqxz 
[18:27:20 CEST] <BtbN> The changes to nvenc are minimal
[18:33:49 CEST] <BtbN> https://github.com/BtbN/FFmpeg/commit/9f1e2159ca474292a47c3560492b3efc7c1ddd03
[18:35:05 CEST] <nevcairiel> i would use nvenc with only a device context
[18:35:16 CEST] <nevcairiel> because mapping external resources into a frames ctx is a big pita
[18:36:43 CEST] <nevcairiel> and entirely unnecessary for encoders
[18:37:04 CEST] <BtbN> It's nice if you use a hw_frames_ctx to allocate your frames
[18:37:15 CEST] <jkqxz> Seems like a bad idea to allow some of these frames to exist without the metadata.  They will only work in some places.
[18:37:19 CEST] <BtbN> but I don't see any reason why a hw_frames_ctx should be required
[18:37:31 CEST] <jkqxz> Would you prefer some sort of make_trivial_frames_ctx function?
[18:37:45 CEST] <BtbN> What metadata is even in there?
[18:38:18 CEST] <jkqxz> BtbN:  Does that change work with the frame sizes?  You've changed it from using the surface size to using the size of the image on the surface.
[18:38:36 CEST] <nevcairiel> basically i have an extenal api that gives me frames, i cannot obtain the full pool of frames to put them into a frames ctx, so basically i would create an empty frames ctx and hope that noone ever tries to get a frame from it for some reason
[18:38:38 CEST] <jkqxz> (Maybe it doesn't matter as long as the pitch is valid.)
[18:38:40 CEST] <nevcairiel> its just bad api to have to do that
[18:39:02 CEST] <BtbN> jkqxz, I'm actually surprised it worked before with that. The actual frame width makes more sense, given that it asks for the pitch
[18:40:58 CEST] <jkqxz> Well, the real encode height and width are set separately (from AVCodecContext.(height|width) - so perhaps the number there is actually irrelevant?
[18:42:35 CEST] <jkqxz> Wrt metadata, AVFramesContext.hwctx.  That doesn't contain anything for CUDA, but it is required elsewhere.
[18:45:40 CEST] <jkqxz> (And those cases generally need it before they have any frames at all.)
[18:46:15 CEST] <BtbN> The only thing nvenc needs before it has frames is the sw_pix_fmt, for which there already is a field in AVCodecContext
[18:47:56 CEST] <jkqxz> The frames context also tracks the device the frame exists on.
[18:48:00 CEST] <nevcairiel> for my point of view, whatever solution there is, there should be an easy way to feed external  frames to an encoder, if that is some api and clear definition to make an empty mock frames ctx (which feels bad, imho), or being able to run with only a device ctx
[18:48:35 CEST] <nevcairiel> I absolutely cannot put frames into an hwframes ctx in this a usecase, and it kinda just works because the encoder never tries to use the hwframes ctx for anything
[18:49:16 CEST] <nevcairiel> (I'm using nvenc with d3d11 in this)
[18:50:57 CEST] <jkqxz> I'm ambivalent about the encoder API, but I really don't like the idea of frames hanging around without the right metadata.
[18:51:19 CEST] <nevcairiel> maybe frames should just have their metadata on a frame basis then
[18:51:51 CEST] <nevcairiel> or change the definition of hwframes ctx to make it clear that it can be an empty metadata object in some cases, and encoders are never allowed to try to read a frame out of it
[18:51:55 CEST] <BtbN> well, for frames which need the metadata, it obviously should be there. But requiring it for CUDA frames, which don't need any special metadata outside of the hw_device_ctx
[18:52:38 CEST] <BtbN> Maybe all the metadata should be moved into a separate struct, which all hwframes need?
[18:56:29 CEST] <BtbN> but that'd be a big change of API and ABI...
[18:56:52 CEST] <BtbN> So I guess metadata-only hw_frames_ctx is what we need to put up with now.
[18:59:22 CEST] <nevcairiel> thats how i use it right now, it just felt a bit icky to basically hope that nothing ever tries to get a frame out of the framesctx
[18:59:28 CEST] <nevcairiel> but then, why would a decoder ever try
[19:00:29 CEST] <nevcairiel> i basically have the same problem with filtering - i have an external frame that I want filtered, so for that to work I absolutely have to give my postprocessing filter a different input and output hwframesctx - input being the "mock" one again, and output one it can actually use to create output frames
[19:01:28 CEST] <nevcairiel> although actually implementing the vpp filter has stalled a bit =p
[19:33:11 CEST] <BtbN> Using a hw_frames_ctx to allocate frames seems to be unsafe to begin with if you're not the one who created it
[20:10:36 CEST] <llogan> someone on twitter wants to know if it is "possible to compile ffmpeg to WASM?". I've never heard of wasm. what do i tell him?
[20:10:51 CEST] <JEEB> webasm, which I guess LLVM supports?
[20:10:55 CEST] <JEEB> except no threads of course
[20:11:37 CEST] <JEEB> people seem to have been poking around it already? https://github.com/jonasof/videoconverter.js-wasm-demo/issues/1
[20:16:59 CEST] <wm4> that will suck because no threads, and less efficient than a native binary that was compiled without hand written asm
[20:17:45 CEST] <jdarnley> But, but, but, you can do it all in a browser!  Isn't that so incredible?
[20:18:04 CEST] <JEEB> yes, that's the whole point
[20:18:18 CEST] <JEEB> "zomg video conversion IN THE CLOUD BROWSER!"
[20:24:42 CEST] <llogan> I should do him a favor and say "no".
[20:29:03 CEST] <jamrial> jkqxz: anything blocking your cbs vp9 patchset? my review was just nits
[20:52:38 CEST] <cone-134> ffmpeg 03Thomas Volkert 07master:62f5c9d68bf6: libavformat: add mbedTLS based TLS
[20:56:05 CEST] <wm4> huh it got pushed
[20:56:54 CEST] <jamrial> and he was asked not to
[20:57:51 CEST] <wm4> yeah, didn't atomnuker block it
[21:01:20 CEST] <wm4> oh no durandal_1707 got a rival
[21:04:17 CEST] <nevcairiel> the mail doesnt exactly read blocking to me
[21:07:24 CEST] <kierank> durandal_1707: woah that guy came out of nowhere
[21:07:51 CEST] <wm4> nevcairiel: he asked for comparisons before he pushes, and he didn't do that
[21:10:14 CEST] <jamrial> he sent the patch yesterday and it go no reviews. it was pushed in a rush
[21:12:11 CEST] <wm4> well it won't be the last TLS wrapper anyway
[21:13:41 CEST] <wm4> ah he replied, but no comparisons
[21:15:53 CEST] <jamrial> "I see mbedTLS as an enrichment for FFmpeg. MbedTLS seems to be a promising alternative to OpenSSL and other TLS implementations in the context of embedded systems"
[21:15:58 CEST] <jamrial> that reads like marketing speech
[21:16:09 CEST] <wm4> yeah had that feeling too
[21:18:10 CEST] <kierank> oh mbedtls = polarssl
[21:18:14 CEST] <kierank> iirc quite a clean implementation
[21:18:31 CEST] <TD-Linux> yeah it's one of the better tls implementations. ARM paid polarssl to license it OSS
[21:19:08 CEST] <TD-Linux> er not OSS, GPL -> Apache
[21:19:33 CEST] <nevcairiel> mbed is polar? TIL
[21:19:42 CEST] <JEEB> same here. TIL
[21:19:50 CEST] <wm4> yeah, that name is more familiar
[21:20:13 CEST] <wm4> uh so it was made OSS, and they didn't think of allowing LGPL? wtf
[21:20:32 CEST] <nevcairiel> apache 2 is usually considered a pretty good license
[21:20:41 CEST] <nevcairiel> leave it to gpl to somehow conflict with it
[21:20:52 CEST] <JEEB> GPLv2 anyways
[21:20:56 CEST] <JEEB> v3 is compatible isn't it?
[21:21:00 CEST] <wm4> well just that this project happens to be (L)GPL
[21:21:00 CEST] <JEEB> if it's apache v2
[21:21:04 CEST] <wm4> JEEB: not if it's v2-only
[21:21:11 CEST] <wm4> JEEB: yes if it's v2-or-later
[21:21:14 CEST] <JEEB> yup
[21:21:15 CEST] <nevcairiel> i dont understand that conflict anyway
[21:21:21 CEST] <JEEB> --enable-v3 required
[21:21:24 CEST] <JEEB> just like some other things
[21:21:31 CEST] <JEEB> or *version3
[21:21:33 CEST] <JEEB> I think that was it
[21:21:44 CEST] <wm4> some software is GPLv3 only, some if GPLv2 only, of course those are incompatible, what's hard to understand
[21:21:55 CEST] <TD-Linux> https://www.apache.org/licenses/GPL-compatibility.html
[21:22:00 CEST] <JEEB> yea nothing hard with that
[21:22:14 CEST] <JEEB> so you can't make a build with apachev2 stuff with GPLv2 only stuff
[21:23:18 CEST] <nevcairiel> i dont understand what gplv2 has against apache, i tried reading that t hing a couple times and its just gibberish to me
[21:24:32 CEST] <wm4> nevcairiel: well you're not a lawyers
[21:24:39 CEST] <wm4> lawyers usually make things up and then stick with it
[21:24:46 CEST] <wm4> until a judge tells them they're full of shit
[21:24:58 CEST] <nevcairiel> except that most of this was probably never tested in court
[21:24:58 CEST] <wm4> and then a higher judge tells the lower judge... etc.
[21:25:20 CEST] <wm4> summary: because lawyers tell us so
[21:26:10 CEST] <klaxa> they paid good money to be able to
[21:30:41 CEST] <TD-Linux> GPLv2 says you can't add restrictions, apachev2 adds patent termination clauses (which are a good thing)
[21:30:48 CEST] <JEEB> yup
[21:30:54 CEST] <cone-134> ffmpeg 03Rostislav Pehlivanov 07master:4ac0ff8ec2af: Revert "libavformat: add mbedTLS based TLS"
[21:30:55 CEST] <TD-Linux> it was a mistake when writing the GPLv2, hence they fixed it in v3
[21:31:02 CEST] <rcombs> yeah, and GPLv3 explicitly says they're okay
[21:32:59 CEST] <jamrial> atomnuker: couldn't you have waited for him to do it himself? we don't need a revert war
[21:36:45 CEST] <JEEB> durandal_1707: wohoo, VC-1 patches for you D:
[21:38:03 CEST] <atomnuker> jamrial: maybe, though now we won't have to have an argument whether to revert or keep waiting to hear some numbers and eventually forgetting
[21:38:57 CEST] <wm4> also what's the big discussion about rv11? this codec most likely won't have success anyway (unless china picks it up because they still like realvideo for whatever reasons?)
[21:39:08 CEST] <llogan> for every new TLS liberry we should remove one
[21:39:34 CEST] <BBB> wm4: its not a native decoder, so its more conceptual (it has downstream implications)
[21:39:43 CEST] <BBB> encoder see what durandal_1707 said
[21:40:11 CEST] <wm4> do we have a policy that closed encoders are ok but decoders are not?
[21:40:31 CEST] <wm4> or, correction: closed decoders are not ok, unless there's already a native open decoder
[21:41:23 CEST] <nevcairiel> its not really written policy or anything, but I agree with BBB's arguments that ffmpeg shouldn't be a sales platform for those proprietary codecs that we never get anything out of
[21:41:37 CEST] <iive> we usually drop external libraries if our implementation is better
[21:42:05 CEST] <wm4> iive: no, we didn't... although we started doing that recently
[21:42:16 CEST] <durandal_1707> iive: we are not mplayer
[21:42:30 CEST] <iive> durandal_1707, mplayer never removes anything :P
[21:42:36 CEST] <nevcairiel> even more so, they'll probably end up violating our license anyway because they then ship ffmpeg with their closed software, and we never know because we dont spend money to find out =p
[21:43:31 CEST] <rcombs> OpenSSL's going apache2 soon anyway
[21:43:39 CEST] Action: llogan wonders if synology is still violating
[21:44:06 CEST] <llogan> next time you see them at a conference please ask them
[21:44:32 CEST] <rcombs> they've got giant tarballs on& source forge? I think
[21:44:53 CEST] <klaxa> still hasn't died yet, huh
[21:44:55 CEST] <rcombs> dunno if they're in v3 violation somehow though
[21:45:07 CEST] <wm4> personally I'd just reject all non-free things, and things that allow creating DRM'ed files
[21:45:25 CEST] <wm4> or that only matter for DRM implementations
[21:45:31 CEST] <llogan> rcombs: IIRC, they used to send nonfree. then they would delay releasing tarballs for a very long time.
[21:45:32 CEST] <wm4> (like this crypto side data export)
[21:45:34 CEST] <rcombs> >cenc
[21:45:55 CEST] <rcombs> on one hand, that's pretty shitty
[21:46:15 CEST] <rcombs> on the other hand, I can guarantee there's nothing in synology patches that you'd actually want to use
[21:48:01 CEST] <llogan> it's mostly the annoyance factor of corporate horseshit behavior
[21:49:32 CEST] <wm4> wasn't GPL actually tested in court?
[21:49:53 CEST] <TD-Linux> yes it was, more than once.
[21:49:54 CEST] <nevcairiel> it has so many facets, even if some lawsuit touched on some of them..
[21:50:49 CEST] <TD-Linux> this is why router manufacturers send out a printed GPL in the box, as a way to cargo cult compliance (if you're lucky they also release source)
[21:51:54 CEST] <durandal_1707> nice beating, jerome fixed bug i was working :)
[21:52:36 CEST] <wm4> yeah it's always odd when you get printed GPLs and such but no code
[21:52:53 CEST] <nevcairiel> durandal_1707: so is that thing now identical to MS decoder?
[21:55:28 CEST] <durandal_1707> nevcairiel: one bug is already fixed by him, 8th patch on ml fixes another glitch with interlaced decodign, 2 bugs remaining to check, one of them is for wmv3 I do not expect to get fixed
[21:56:07 CEST] <jamrial> nevcairiel: the guy says his patchset makes the decoder bitexact to what a haswell hardware decoder outputs
[21:56:33 CEST] <JEEB> yea, at least in FATE samples the hashes seem to get updated
[21:56:34 CEST] <nevcairiel> jamrial: which is interesting because in the past intel was not bitexact :p
[21:56:42 CEST] <jamrial> heh
[21:56:43 CEST] <nevcairiel> not sure if that was fixed
[21:56:56 CEST] <nevcairiel> i could break out the MS hashes again and see if the fate updates match
[21:57:06 CEST] <durandal_1707> well, our is not bitexact with leaked source anyway
[21:58:31 CEST] <nevcairiel> seems like the fate ref file updates match the MS decoder results in posted earlier
[21:58:50 CEST] <nevcairiel> so at least for that one file that I have the hashes at hand it looks good
[21:59:23 CEST] <nevcairiel> i do wonder though why someone would suddenly care so much about vc1
[21:59:28 CEST] <nevcairiel> but everyone has their own motivations :)
[22:01:18 CEST] <atomnuker> durandal_1707: leaked source?
[22:01:56 CEST] <atomnuker> nevcairiel: me too, I've never seen VC-1 when I worked in broadcasting or on BDs (I have only one from the very early days, and its progressive)
[22:02:14 CEST] <durandal_1707> atomnuker: VC1_reference_decoder_release6
[22:02:18 CEST] <nevcairiel> I have a lot of VC-1 Blu-rays
[22:02:27 CEST] <nevcairiel> both kinds of interlacing too
[22:02:59 CEST] <nevcairiel> some of the early BBC documentaries use VC-1 interlaced on BDs
[22:03:06 CEST] <atomnuker> ah, yeah, planet earth
[22:03:20 CEST] <atomnuker> though the rip I have is progressive
[22:03:29 CEST] <nevcairiel> someone might have made it that way
[22:03:35 CEST] <atomnuker> (still vc-1, so I think its straight from the BDs)
[22:03:45 CEST] <nevcairiel> there might a lso be different releases
[22:04:17 CEST] <nevcairiel> Galapagos is VC-1 interlaced, one of the specials
[22:04:55 CEST] <nevcairiel> https://en.wikipedia.org/wiki/Gal%C3%A1pagos_(2006_TV_series)
[22:07:35 CEST] <Compn> durandal_1707 : good job with the vc-1 bug :)
[22:08:40 CEST] <nevcairiel> Madagascar as well, apparently many of those outside of the main Planet Earth stream
[22:08:46 CEST] <durandal_1707> #3262 is fixed with 8th patch from vc1 patch set on ml, #4372 is not, reference decoder decodes it fine
[22:09:26 CEST] <nevcairiel> oh well, progress is progress
[22:09:44 CEST] <nevcairiel> maybe jerome is interested in the sample to look into that as well
[22:10:44 CEST] <Compn> i have only one bluray disc but no bluray drive to rip it and see if theres a problem
[22:11:25 CEST] <Compn> i have 5 laserdisc players though heh go figure
[22:11:31 CEST] <rcombs> people complain to me about VC1 all the damn time
[22:11:44 CEST] <rcombs> including a fair bit of whining about interlacing
[22:11:56 CEST] <rcombs> idk where they get this shit from, maybe HD-DVDs?
[22:12:26 CEST] <JEEB> some blu-rays until 2011 used VC-1
[22:12:29 CEST] <Compn> i have one hddvd but no hddvd drive
[22:12:31 CEST] <iive> microsoft spent a lot of effort to include vc1 in bluray format.
[22:12:39 CEST] <JEEB> I think it was mostly some US companies
[22:12:41 CEST] <rcombs> and I'm like "have you considered encoding, or acquiring an existing encode, in a codec that isn't obscure garbage"
[22:12:52 CEST] <rcombs> and they're like "BUT MUH REMUXESSSSSS"
[22:13:25 CEST] <wm4> remuxing interlaced video, totally worth it
[22:13:42 CEST] <wm4> apparently mixing progressive/interlaced/telecined is popular too
[22:13:54 CEST] <JEEB> I think one of the funkiest ones were the blu-rays for canaan (the crappy typo-moon thingy), which only got blu-rays in the US
[22:13:54 CEST] <wm4> which makes playback and thus remuxes even less nice
[22:13:57 CEST] <JEEB> and thus only got VC-1
[22:13:57 CEST] <JEEB> lol
[22:14:56 CEST] <jamrial> the only vc1 samples i have are old trailers for xbox games released by microsoft
[22:15:13 CEST] <j-b> and blurays?
[22:15:15 CEST] <jamrial> i remember reading that the latest firmware for the x360 doesn't even recognize the hd-dvd addon
[22:15:23 CEST] <jamrial> wonder if it can even play vc1 as well
[22:15:34 CEST] <JEEB> they did use vc1 on the console
[22:15:38 CEST] <JEEB> in games, too I think
[22:15:56 CEST] <jamrial> ah, if it's in games then they are pretty much forced to support it
[22:15:58 CEST] <Compn> do we support the SACD format at all ?
[22:16:06 CEST] <Compn> dont even think we have samples ?
[22:16:12 CEST] <JEEB> SACD is not PCM
[22:16:19 CEST] <rcombs> JEEB: are they qtec
[22:16:22 CEST] <JEEB> it's that one-bit thing which changes megahurtzes
[22:16:35 CEST] <Compn> muh mhz
[22:16:37 CEST] <JEEB> rcombs: canaan? it should be field cross-whatever'd
[22:16:41 CEST] <JEEB> at least on TV
[22:16:46 CEST] <rcombs> I mean on the BD
[22:16:56 CEST] <JEEB> I think they didn't fuck it over too much but I'd need to find a sample
[22:17:35 CEST] <durandal_1707> we have support for DSD audio
[22:18:40 CEST] <wm4> but no DSD samplefmt, which means ffmpeg is SHIT for audiophiles
[22:18:48 CEST] <durandal_1707> lol
[22:19:02 CEST] <JEEB> rcombs: ok I'm sorry. amazon was lying to me by not showing out of stock things
[22:19:06 CEST] <durandal_1707> the DSD->PCM conversion is perfect
[22:19:07 CEST] <JEEB> there is a .jp BD box for it
[22:19:10 CEST] <JEEB> which is AVC
[22:19:14 CEST] <rcombs> ah
[22:19:18 CEST] <rcombs> so the VC1 is pointless
[22:19:56 CEST] <JEEB> they even made a "compact" BD box of it in 2017... (wat)
[22:20:14 CEST] <durandal_1707> lol vs guy ported pp7 filter
[22:20:51 CEST] <Compn> it goes to 7!
[22:20:51 CEST] <Compn> ehe
[22:25:32 CEST] <atomnuker> Compn: I think we do
[22:25:41 CEST] <atomnuker> DSD
[22:26:36 CEST] <nevcairiel> durandal_1707: does our dsd decoder do low-pass filtering or do i have to chain that after? (dsd to pcm requires a strong low-pass filter or you get crap quality from all the ultrasonic interference)
[22:26:45 CEST] <atomnuker> I think it does low pass
[22:26:55 CEST] <atomnuker> but only to 384 khz
[22:28:13 CEST] <nevcairiel> you need a strong low-pass well below that
[22:28:28 CEST] <nevcairiel> like 24kHz 48db/octave or so
[22:30:42 CEST] <durandal_1707> we have 6db per pole per octave butterworth lowpass filter
[22:31:14 CEST] <durandal_1707> you can chain it, or design your own 48db/octave lowpass filter with aiir
[22:34:17 CEST] <durandal_1707> you could also chain biquads, if you knew coefficients, recalculated for each sample rate
[22:34:52 CEST] <nevcairiel> yeah i never bothered to try to understand how such filters are defined
[22:35:22 CEST] <durandal_1707> or use fir filtering, looks like firequalizer could support lowpass/highpass easily
[22:36:22 CEST] <durandal_1707> it does, support it, but dunno about slope
[22:37:13 CEST] <durandal_1707> note that fir filtering introduces delay 
[22:37:50 CEST] <atomnuker> what samplerate does the dsd decoder output at?
[22:38:32 CEST] <nevcairiel> 1/8th of the DSD rate
[22:38:36 CEST] <durandal_1707> iir filter does not, but iir introduces group delay which some says it is noticeable, but one can add X-order irr allpass filter that compensate this
[22:38:47 CEST] <nevcairiel> which is common for this kind of conversion
[22:38:53 CEST] <kierank> 9:13:26 PM <"wm4> remuxing interlaced video, totally worth it
[22:39:02 CEST] <kierank> 25p must be encoded as interlaced in blu-ray
[22:39:13 CEST] <kierank> some TVs back then couldn't handle 25p
[22:39:37 CEST] <JEEB> yea, thankfully a lot of fake interlacing, but yes - the specs mandate "interlacing"
[22:39:58 CEST] <kierank> vc-1 was real interlacing
[22:40:42 CEST] <nevcairiel> so DSD64 is 2.8MHz, that gives you 352.8 kHz PCM
[22:40:56 CEST] <TD-Linux> you would get the best quality from dsd by always downsampling till you hit 44.1 or 48
[22:41:24 CEST] <Compn> https://github.com/avaneev/r8brain-free-src
[22:42:16 CEST] <nevcairiel> you probably want to low-pass before you downsample further, but a good downsampler probably does that anyway
[22:42:44 CEST] <JEEB> kierank: right, yes - within that context it was indeed true interlacing :)
[22:43:22 CEST] <TD-Linux> right I meant both of those together :)
[22:43:44 CEST] Action: durandal_1707 have DSD512
[23:06:04 CEST] <klaxa> hmm i must have missed the period on the ML where people explain their positions :/
[23:16:28 CEST] <j-b> fun fact: I met the Real people at NAB
[23:16:43 CEST] <j-b> and told them they should fund an open source implementation of RV60
[23:19:06 CEST] <JEEB> given how focused they are on China I wonder how much business sense that makes
[23:19:23 CEST] <JEEB> of course I'd love it if they did an OSS implementation
[23:19:59 CEST] <klaxa> is x264 banned in china or what?
[23:20:00 CEST] <j-b> JEEB: exactly, china does not care at all about open source and not open source
[23:20:07 CEST] <j-b> so, it would cost them nothing
[23:20:20 CEST] <JEEB> and I guess the chinese fork of x264 being OSS possibly made it simpler to utilize?
[23:20:38 CEST] <JEEB> klaxa: they surely are on some level trying to push their own forks of AVC/HEVC I think?
[23:21:02 CEST] <JEEB> AVS I think was the AVC one?
[23:21:02 CEST] <klaxa> i'm guessing there are some political reasons for that
[23:21:23 CEST] <klaxa> just to be incompatible with western stuff?
[23:21:44 CEST] <JEEB> I think this is more about "homegrown tech"
[23:21:51 CEST] <JEEB> "we made this"
[23:22:04 CEST] <klaxa> ah
[23:29:57 CEST] <TD-Linux> china does not want to pay US companies for H.264 licensing
[23:30:41 CEST] <TD-Linux> unfortunately, rather than work on free formats, they make formats like AVS and XAVS that are also not free, just you have to pay chinese companies instead. (they are cheaper too)
[23:31:09 CEST] <nevcairiel> since w hen does china care about honoring trademarks or copyright
[23:31:23 CEST] <atomnuker> at least because its difficult to translate "intellectual property" in chinese you don't have to pay licensing fees
[23:31:56 CEST] <klaxa> so with AV1 this nonsense will stop? probably not...
[23:32:15 CEST] <atomnuker> eh, maybe
[23:32:26 CEST] <TD-Linux> nevcairiel, when their products get exported. it's not especially consistent though.
[23:32:27 CEST] <durandal_1707> what they use for audio?
[23:34:02 CEST] <TD-Linux> the standard includes an audio format too, I know nothing about it
[23:34:37 CEST] <TD-Linux> (rv11 is probably not avs, but has basically the same reason for existing - it's cheaper)
[23:35:39 CEST] <iive> nevcairiel, china cares only about their own copyright and trademarks.
[23:35:40 CEST] <atomnuker> durandal_1707: ever heard of DRA? me neither
[23:35:42 CEST] <atomnuker> https://en.wikipedia.org/wiki/Dynamic_Resolution_Adaptation
[23:36:36 CEST] <TD-Linux> http://wwwen.zte.com.cn/endata/magazine/ztecommunications/2016/2/articles/201605/P020160512439922463588.pdf
[23:37:14 CEST] <durandal_1707> give me binary blobs and samples
[23:37:42 CEST] <TD-Linux> lol them comparing against FAAC
[23:37:46 CEST] <TD-Linux> and losing
[23:38:14 CEST] <JEEB> lol
[23:40:10 CEST] <durandal_1707> ok to apply removal of interlace filter code? it is merged with  tinterlace
[23:40:41 CEST] <durandal_1707> i will apply it, as fate passes, and its removes dupe code
[23:40:55 CEST] <durandal_1707> and i LGTMed it already
[23:40:56 CEST] <atomnuker> anyone with a springer.com account?
[23:40:58 CEST] <atomnuker> https://link.springer.com/chapter/10.1007%2F978-1-4419-1754-6_15
[23:42:07 CEST] <durandal_1707> probably fake
[23:43:03 CEST] <atomnuker> doesn't seem so, though maybe it doesn't describe the spec itself
[23:43:14 CEST] <atomnuker> very suspicious lack of chinglish though
[23:43:56 CEST] <durandal_1707> https://github.com/tianyigeng/DRA-Audio-System
[23:44:39 CEST] <nevcairiel> DRA even made it into the blu-ray spec, but i c ant say I ever saw a single disc with it
[23:45:17 CEST] <atomnuker> durandal_1707: what absolute legends
[23:45:39 CEST] <atomnuker> sure its not free as in beer but you can always count on someone from china to leak stuff
[23:45:59 CEST] <atomnuker> er, free as in freedom, but it is free as in beer
[23:46:10 CEST] <TD-Linux> looks like vorbis--
[23:47:10 CEST] <TD-Linux> er no, per frame codebooks
[23:49:25 CEST] <cone-134> ffmpeg 03Vasile Toncu 07master:9c01cdb94e24: avfilter/vf_interlace: remove duplicate code with same funcionality
[23:51:07 CEST] <cone-134> ffmpeg 03Paul B Mahol 07master:daba36947137: avcodec/vc1: check return value of bitplane_decoding()
[00:00:00 CEST] --- Tue Apr 24 2018