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

[burek]

[01:07:45 CET] <rcombs> JEEB: I think I was wrong about closed captions not carrying language information
[01:07:53 CET] <rcombs> (or was it someone else who asked about that)
[06:05:43 CET] <kierank> JEEB: any idea if it's possible to overlay side data using ffplay?
[06:17:33 CET] <kierank> atomnuker: wow
[08:01:34 CET] <JEEB> kierank: sorry I've not used or generally looked at ffplay at all
[08:02:13 CET] <JEEB> rcombs: yea in theory us could have en/sp f.ex.
[08:50:54 CET] <cone-379> ffmpeg 03gxw 07master:4571c7c05d84: avcodec/mips: [loongson] mmi optimizations for VP9 put and avg functions
[10:05:57 CET] <JEEB> michaelni: for the record there's two fixes for your sub2video use case on the mailing list. I prefer https://patchwork.ffmpeg.org/patch/12159/ because it's not hard-coding zero as the initializer, but then there's https://patchwork.ffmpeg.org/patch/12142/ which just effectively sets the value to what that struct implicitly got initialized to before
[10:07:39 CET] <JEEB> and for debugging sub2video I've generally utilized this sort of debug logging https://github.com/jeeb/ffmpeg/commit/f1750f489be345f74525f7a2ad89e40c4d7e0493
[10:09:22 CET] <JEEB> I'm currently trying to figure out the least bad way of filtering a blu-ray PGS sample which could be then utilized for testing sub2video in this way :P
[10:09:45 CET] <JEEB> because I could just filter by PIDs but if the PCR is on the video PID then I have to keep the PCR there
[12:10:02 CET] <durandal_1707> YES!, I got basic decoding working without artifacts; no ASPX, so only up to 12k freqs are decoded
[12:10:37 CET] <JEEB> \o/
[12:10:42 CET] <JEEB> that is something already
[12:11:40 CET] <durandal_1707> but it is 0.7-0.9 speed :-)
[12:12:08 CET] <JEEB> that is one fancy codec
[12:12:13 CET] <JEEB> for audio that is
[12:12:16 CET] <durandal_1707> without FFT optimizations
[12:12:27 CET] <nevcairiel> naive FFT is just super slow
[12:12:33 CET] <JEEB> ah
[12:12:51 CET] <durandal_1707> with QMF filtering it would be even slower
[12:16:30 CET] <atomnuker> what do you mean qmf filtering?
[12:19:26 CET] <durandal_1707> Quardature Mirror Filter, filter that converts a PCM sample stream into two sample streams of half the input sampling rate, so that the output data rate equals the input data rate
[12:20:30 CET] <atomnuker> no, I mean is it like mp3?
[12:21:32 CET] <durandal_1707> AC-4 decoders employ a complex QMF analysis/synthesis filter bank pair to enable alias suppressed frequency-domain processing
[12:23:55 CET] <atomnuker> so after the fft? could have been worse
[12:26:20 CET] <durandal_1707> after IMDCT, also have silly companding code - should I implement that at all?
[12:27:31 CET] <durandal_1707> samples I have are very basic, single presentation + max 1 audio substream
[12:27:45 CET] <atomnuker> so the qmfs are optional?
[12:32:46 CET] <durandal_1707> nope, they are mandatory for ASPX
[12:37:57 CET] <atomnuker> right, reading the description makes it sound a bit like sbr
[13:18:46 CET] <durandal_1707> with what sizes our imdct works?
[13:21:30 CET] <durandal_1707> lol there were dolby atmos code on github, taked down before I could look
[13:22:02 CET] <JEEB> :<
[13:22:08 CET] <JEEB> (lol atmos)
[13:27:19 CET] <atomnuker> durandal_1707: only power of twos
[13:28:00 CET] <atomnuker> and even multiples of 15 for mdct15
[16:59:10 CET] <durandal_1707> i've got big headache working today, need to rest now...
[17:05:34 CET] <BradleyS> feel better
[18:03:08 CET] <cone-379> ffmpeg 03Martin Vignali 07master:a3f65f5e9fed: avcodec/proresenc_aw : fix sub_image_with_fill for interlaced encoding
[18:03:09 CET] <cone-379> ffmpeg 03Martin Vignali 07master:b38dd2d219c9: fate/proresenc_aw : add test for interlace and 444 encoding
[18:31:02 CET] <philipl> BtbN: You will merge the nvcc changes?
[18:36:07 CET] <BtbN> yes
[18:36:16 CET] <philipl> thanks
[18:36:20 CET] <BtbN> But I'm not done testing
[18:36:28 CET] <BtbN> And they will still be nonfree
[18:49:05 CET] <philipl> BtbN: sure. small steps.
[18:49:34 CET] <philipl> We'll need to continue arguing about is needed to enable kernels in lgpl builds.
[18:49:40 CET] <BtbN> My MSVC installation decided to dismantle itself, and I'd like to test that as well
[18:49:49 CET] <philipl> Sorry to hear :-)
[18:50:42 CET] <nevcairiel> speaking of that, this "load kernels externally" hack this guy keeps pitching is not really an acceptable solution to me, because if we can't find a way we're confident is within the license, that is only a way to circumvent our own license,  and not a good idea
[18:51:11 CET] <BtbN> I hate it because it seems like the by far most user-unfriendly way of doing things
[18:51:27 CET] <BtbN> Like, having to pass a seemingly random file to your filter for it to do things...
[18:51:28 CET] <nevcairiel> that too
[18:51:45 CET] <nevcairiel> if we had a generic thing like "pass video through this cuda filter", loading an external filter would be fine
[18:51:58 CET] <nevcairiel> but something like yadif, which has a lot of support code  and will never work out of the box, thats just bad
[18:52:20 CET] <BtbN> Yes, I'd be very open for a generic vf_cuda or something
[18:52:27 CET] <BtbN> that just takes in generic ptx files
[18:53:58 CET] <BradleyS> is there a timeline or roadmap for releases?
[18:54:08 CET] <BradleyS> curious when 4.2 is planned at the very least
[18:54:43 CET] <nevcairiel> there is a rough gap between releases thats targeted, but thats not being enforced very strictly
[18:55:42 CET] <nevcairiel> its supposed to be roughly every half year I think
[18:56:41 CET] <BradleyS> i guess i haven't followed closely enough to know, are point releases cut from master?
[18:56:49 CET] <nevcairiel> no
[18:57:01 CET] <BradleyS> okay, so master is next major then
[18:57:04 CET] <JEEB> yes
[18:57:06 CET] <nevcairiel> 4.1.1 is from the 4.1 branch, which only gets bugfixes backported
[18:59:24 CET] <BradleyS> right, i didn't notice a release/4.2 branch, what will that be based on?
[18:59:34 CET] <nevcairiel> master in a few months time
[18:59:50 CET] <nevcairiel> "4.2" is the major, not just 4
[18:59:51 CET] <nevcairiel> :)
[19:00:04 CET] <BradleyS> ah, okay, i should have said minor release not point
[19:00:12 CET] <BradleyS> thanks for the clarification
[19:00:16 CET] <nevcairiel> there is really no minor or major release
[19:00:22 CET] <BtbN> ok, it also works on msvc
[19:00:22 CET] <nevcairiel> we just make up numbers as we want
[19:00:39 CET] <BradleyS> no worries
[19:00:50 CET] <nevcairiel> ie. 4.0 wasnt that more impactful then 3.3
[19:01:06 CET] <nevcairiel> i think someone once tried to align those changes with soname bumps
[19:01:10 CET] <cone-379> ffmpeg 03Philip Langdale 07master:5f47bfd50ac4: configure: Add an explicit check and option for nvcc
[19:01:11 CET] <cone-379> ffmpeg 03Philip Langdale 07master:7debf4277c29: avfilter/vf_yadif_cuda: Switch to using ffnvcodec
[19:01:12 CET] <cone-379> ffmpeg 03Philip Langdale 07master:2544c7ea67ca: avfilter/vf_scale_cuda: Switch to using ffnvcodec
[19:01:12 CET] <nevcairiel> but not sure if that was strictly followed
[19:01:12 CET] <BradleyS> yeah, sort of a modified semver
[19:01:13 CET] <cone-379> ffmpeg 03Philip Langdale 07master:b4c9c09915de: avfilter/vf_thumbnail_cuda: Switch to using ffnvcodec
[19:01:14 CET] <cone-379> ffmpeg 03Philip Langdale 07master:114ead9735f2: configure: deprecate cuda_sdk dependency option
[19:01:15 CET] <cone-379> ffmpeg 03Timo Rothenpieler 07master:c775410f3183: configure: pass windows-path to nvcc whenever cygpath is available
[19:01:16 CET] <cone-379> ffmpeg 03Timo Rothenpieler 07master:85051febc62e: configure: update minimum required ffnvcodec versions
[19:01:34 CET] <BradleyS> handbrake does that also, we add features in minor releases but aren't too worried about breaking compatibility there
[19:01:57 CET] <BradleyS> the strictest semver interpretation says minor shouldn't have breaking changes but that's not entirely realistic
[19:02:15 CET] <JEEB> well, we have release branches that can have minor versions on their name. then further releases in that branch are always just back-ports of fixes
[19:03:06 CET] <BradleyS> yeah
[19:03:50 CET] <BradleyS> release/<major>.<minor> branch is effectively <major>.<minor>.x in handbrake
[19:03:52 CET] <BradleyS> same concept
[19:03:59 CET] <BradleyS> (just fyi)
[19:04:51 CET] <BradleyS> was just curious because some things in 4.2 will be beneficial for us, but needed to know what it's based on since we normally only update contribs for bug fixes when we're pushing out only bug fixes in a patch release
[19:05:19 CET] <BradleyS> so handbrake 1.2.x will stay on 4.1.x and 1.3.x when released will probably get 4.2 ;)
[19:09:31 CET] <philipl> BtbN: cheers.
[19:09:50 CET] <philipl> nevcairiel: agreed. For us to be comfortable with external loading, we'd need to be comfortable with internal loading.
[19:52:42 CET] <BtbN> Why are all the news sites reporting that OBS just now added nvenc support? oO
[19:53:46 CET] <nevcairiel> i didnt see that anyway, like w here?
[19:54:02 CET] <nevcairiel> anywhere*
[19:54:59 CET] <BtbN> https://www.golem.de/news/nvidia-turing-obs-unterstuetzt-encoder-der-geforce-rtx-1902-139694.html (German) https://www.phoronix.com/scan.php?page=news_item&px=OBS-Studio-23.0-Released
[19:55:26 CET] <nevcairiel> i guess someone overhyped an update of the video sdk
[19:55:53 CET] <BtbN> They did add a nvenc code, but it only avoid a copy to system RAM and back to the GPU
[19:55:58 CET] <BtbN> nvenc support in itself isn't new
[19:56:05 CET] <BtbN> *add new
[19:56:16 CET] <nevcairiel> the news thing really says "nvenc support for turing enhancements"
[19:56:28 CET] <nevcairiel> but its totally overreported anyhow
[00:00:00 CET] --- Thu Feb 28 2019