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

Tue Nov 7 03:05:02 EET 2017

[00:17:40 CET] <cone-597> ffmpeg 03Marton Balint 07master:d68a557df493: ffplay: use SDL2 audio API
[00:41:21 CET] <atomnuker> holy crap 5000+ lines of bluetooth audio decoders, awesome
[00:41:28 CET] <JEEB> wat
[00:41:41 CET] <JEEB> oh, amr
[00:41:41 CET] <JEEB> lol
[00:42:50 CET] <JEEB> oh, saw them now
[00:42:51 CET] <JEEB> SBC
[00:42:56 CET] <JEEB> and aptX
[00:43:19 CET] <durandal_1707> bluetooth?
[00:43:27 CET] <JEEB> yup
[00:43:32 CET] <JEEB> he wanted to encode/decode with lavc
[00:43:34 CET] <JEEB> so implemented
[00:43:36 CET] <JEEB> based on RE
[00:44:38 CET] <atomnuker> I wanted to decode sbc only 2 months ago and I couldn't get either the library, the library's example nor the gstreamer plugin using the library to run
[00:45:11 CET] <atomnuker> no, wait, I wanted to encode, nvm
[00:51:19 CET] <atomnuker> WHAT, BOTH PATCHES ALSO ADD ENCODERS? and there's even some asm code
[00:52:19 CET] <JEEB> najs
[00:52:24 CET] <atomnuker> they're both fixed point but of well, it makes sense for something that simple
[00:53:34 CET] <kierank> apt-x isn't a complex codec
[00:53:40 CET] <kierank> it's from the early 90s
[00:54:45 CET] <atomnuker> "if (error < 0)  quantized_sample--;", "quantized_sample ^ inv;"
[00:55:13 CET] <atomnuker> wow, *= -1 was too difficult
[00:55:38 CET] <JEEB> people don't always come up with the obvious
[00:57:59 CET] <iive> -1^-1 = 0 ; -1*-1 = 1
[00:58:21 CET] <iive> oh, that's why --
[00:58:26 CET] <iive> ignore it.
[00:59:00 CET] <iive> and yeh, compilers were stupid enough to use multiply when you write multiply
[01:00:22 CET] <kierank> it's REd code
[01:00:40 CET] <iive> hum... no, that's not how you do sign inverse without multiply.
[01:03:45 CET] <durandal_1707> are there actual aptX files in wild?
[01:14:16 CET] <kierank> it's not a file codec
[01:14:18 CET] <kierank> it's a live codec
[01:14:59 CET] <durandal_1707> k
[01:18:25 CET] <atomnuker> ugh, horrible, it interleaves the samples instead of outputting to planar
[01:18:34 CET] <atomnuker> (the aptx decoder)
[01:19:13 CET] <durandal_1707> tell him that
[01:19:34 CET] <durandal_1707> we now have planar audio
[01:19:36 CET] <atomnuker> I am, currently reviewing code
[01:37:27 CET] <atomnuker> ...and it has its own dct code
[01:37:42 CET] <atomnuker> the sbc
[01:39:24 CET] <atomnuker> yeah, no, we have a fixed point dct
[01:40:18 CET] <atomnuker> and nobody wants to maintain the dca encoder which has its own fixed point dct but one guy (who's currently converting the encoder to float)
[01:56:03 CET] <atomnuker> MMX simd
[01:56:06 CET] <atomnuker> in this day and age?
[02:01:30 CET] <JEEB> if that's what one knwos
[02:01:32 CET] <JEEB> *knows
[02:02:23 CET] <kierank> atomnuker: there is no spec he RE'd it
[02:02:30 CET] <kierank> that's why he has weird constructs
[02:05:24 CET] <JEEB> yea, implementation RE + patents
[02:52:48 CET] <Compn> +static int##size##_t rshift##size(int##size##_t value, int shift)   
[02:53:02 CET] <Compn> is my mailer broken or is ## stuff normal ?
[02:53:35 CET] <JEEB> that looks like macro (ab)use
[02:55:56 CET] <Compn> do cars use the bluetooth audio? i think so
[02:56:17 CET] <Compn> or just use bluetooth as a connection with some other kind of codec hmmm
[04:21:50 CET] <liyou> hi, i want to know how to package ps to rtp, which file should i read?
[05:42:58 CET] <atomnuker> the mailing list's really fast these days, much faster than the old wait times of up to half an hour
[06:17:51 CET] <uau> atomnuker: about your "return sbc_encoder_process_input_s4_internal(position, pcm, X, nsamples, 1 + (nchannels > 1));", i think the whole point of the original was to use a constant of the last argument
[06:18:09 CET] <uau> so there would be two separate inlined versions, one optimized for one constant and the other for another
[06:35:56 CET] <atomnuker> meh, I doubt it would make much of a difference
[06:42:49 CET] <uau> no idea whether it makes a difference, but i'm pretty sure that was the rationale for writing it that way
[10:42:18 CET] <durandal_1707> is ty demuxer ready to push?
[11:58:57 CET] <BtbN> iive, there is no callback. You just must just wait with pulling the frame from the decoder until you have fed it a couple more frames
[11:59:43 CET] <BtbN> With the current cuvid standalone implementation, that's no problem. It can just choose not to output a frame.
[12:00:01 CET] <BtbN> But cuvid is about to become a classic hwaccel. So it's no longer in a position where it can delay frame-output.
[12:00:36 CET] <BtbN> And if you don't delay frame output, it really cripples the performance to the level of it being useless
[12:50:57 CET] <atomnuker> BtbN: how is the delay set? is it a constant or per hwaccel?
[12:51:16 CET] <BtbN> It's just "as late as possible"
[12:51:42 CET] <BtbN> So right now it just waits with delivering frames until it would otherwise run out of buffer space
[12:53:06 CET] <BtbN> In case of nvenc it's even user-configurable
[12:53:08 CET] <nevcairiel> this is just creating the infrastructure to even make such a delay possible, it could very well be per-hwaccel
[12:53:31 CET] <BtbN> Yeah, the current patches introduce no delay at all.
[12:53:34 CET] <nevcairiel> but that part is not implemented yet, the only delay it benefits from right now is the inherent delay from frame-reordering
[12:53:47 CET] <BtbN> Which is usually already enough
[12:54:06 CET] <BtbN> Doesn't need more than 2~3 frames to be performant, which the usual reordering provides
[12:54:14 CET] <BtbN> Just craps itself with I/P only stuff
[12:55:32 CET] <BtbN> For that private frame data patch, the "easiest" solution to address the concerns would be to just do exactly the same thing, but on a new field, which is declared as libav* private API
[12:55:42 CET] <BtbN> But that's ugly imo
[12:55:51 CET] <nevcairiel> thats the patch michael send to the ML
[12:56:02 CET] <BtbN> I haven't seen that patch yet? When did he send it?
[12:56:23 CET] <nevcairiel> on the weekend
[13:37:31 CET] <cone-637> ffmpeg 03Carl Eugen Hoyos 07master:0a60cc909ed5: lavf/amr: Do not set codec_tag for raw amr_nb and raw amr_wb.
[13:52:20 CET] <cone-637> ffmpeg 03Ashish Pratap Singh 07master:4c38aa79ece4: avfilter/vf_libvmaf: fix errors while running with psnr=1.
[13:52:21 CET] <cone-637> ffmpeg 03Ashish Pratap Singh 07master:7b7037e5b035: avfilter:vf_libvmaf: improve docs.
[14:15:57 CET] <kierank> J_Darnley: do you think it's a good idea to make that individual function zmm
[14:16:01 CET] <kierank> since it's pretty useless?
[14:16:11 CET] <kierank> and will downclock
[14:16:18 CET] <J_Darnley> the v210 one?
[14:16:22 CET] <kierank> the other one
[14:16:26 CET] <kierank> pixel_ whatever
[14:16:40 CET] <J_Darnley> oh, that's just for testing that it all works.
[14:17:04 CET] <J_Darnley> ... including zmm
[14:17:16 CET] <kierank> ah, but will that be on by default
[14:17:25 CET] <kierank> because I wouldn't like my machine to downlock just for that crappy function
[14:17:38 CET] <J_Darnley> I probably won't commit it.
[14:17:58 CET] <kierank> ah
[16:17:28 CET] <J_Darnley> Is it a currently known bug that nasm isn't listing the included files (x86inc) as dependencies?
[16:17:30 CET] <J_Darnley> I feel like I've heard that story before.
[16:18:19 CET] <nevcairiel> it is
[16:18:38 CET] <nevcairiel> 2.13.02rc2 should fix it
[16:18:56 CET] <jamrial> they are taking too long to just tag that release
[16:19:01 CET] <jamrial> that bug has been fixed for months now
[16:19:21 CET] <nevcairiel> development feels like a gnu project =p
[16:19:42 CET] <jamrial> heh
[16:20:08 CET] <J_Darnley> okay thanks
[17:10:27 CET] <BtbN> <BtbN> iive, there is no callback. You just must just wait with pulling the frame from the decoder until you have fed it a couple more frames
[17:22:08 CET] <iive> BtbN: is there a way to pull/query the status without waiting on it?
[17:22:19 CET] <BtbN> no
[17:23:34 CET] <iive> then, what is async to it?
[17:30:13 CET] <brontosaurusrex> Can I get ubanned from #ffmpeg?
[17:30:41 CET] <brontosaurusrex> Thanks in advance.
[17:31:22 CET] <durandal_1707> brontosaurusrex: what have you done to be banned?
[17:32:51 CET] <brontosaurusrex> durandal_1707: no idea
[17:37:06 CET] <brontosaurusrex> But, if I'am accused of something, I will prepare my defense.
[17:37:19 CET] <brontosaurusrex> Lawyers and everything.
[17:46:09 CET] <kierank> lol
[17:46:42 CET] <iive> the ban is set at 27 jan by ubitux 
[17:48:58 CET] <iive> oh, ye, I have it in the logs. You did a mass highlight
[17:51:48 CET] <brontosaurusrex> iive: whats that?
[17:52:25 CET] <iive> 2017-01-27 15:56:19 (+0200)<brontosaurusrex>    Nicks #ffmpeg: [@`md @durandal_1707 @superdump @ubitux [...]
[17:54:06 CET] <iive> that is mentioning all the people who are in the channel, with the hope that they would be highlighted and will look at you and your question.
[17:54:40 CET] <brontosaurusrex> sort on an attention whore?
[17:55:02 CET] <iive> yes.
[17:55:35 CET] <brontosaurusrex> Ok, I'am not aware of that action, and I will blame my irc client. Do I have a case or ... ?
[17:56:15 CET] <iive> that's even worse... because you could accidently do it again.
[17:57:36 CET] <iive> and what kind of client would have a feature like that?
[17:58:02 CET] <brontosaurusrex> How about some community work? I could write an example for nnedi (in time) and add that to docs.
[17:58:33 CET] <brontosaurusrex> Also in my defence I have changed irc client.
[18:01:16 CET] <iive> i'm ok with removing the ban, unless ubitux  has some objections.
[18:04:17 CET] <brontosaurusrex> Sounds promising, also perhaps rethink the banning strategy, obviously I'am an extermly nice person and permaban is a bit strong.
[18:05:45 CET] <brontosaurusrex> I rest my case.
[18:11:47 CET] <iive> yeh, we usually don't keep bans for long. but sometimes they got forgotten.
[18:17:48 CET] <atomnuker> jamrial: okay to push the gamma side data stuff?
[18:18:09 CET] <atomnuker> also do I bump the lavu minor?
[18:20:46 CET] <jamrial> atomnuker: send a new set fixing what i mentioned in my reviews for patches 1 and 2
[18:20:54 CET] <jamrial> and yes, minor lavu bump
[18:22:36 CET] <durandal_1707> i gonna push ty demuxer soonTM
[18:25:12 CET] <kierank> durandal_1707: y u fork mpv?
[18:25:23 CET] <durandal_1707> yes
[18:26:10 CET] <kierank> why
[18:27:27 CET] <BtbN> iive, the hardware itself is. If you give it a picture or a frame(It's the same behaviour for cuvid and nvenc), it will give you the result back pretty much immediately, if there is no re-ordering. But if you try to access it immediately, you force the driver to synchronize itself with the hardware to actually get the data. If you just let it sit for a while, it will download the data asynchronously, and you can keep feeding it in the meantime.
[18:28:54 CET] <BtbN> Otherwise you end up giving it data, then waiting for it to be done with the data, and then getting the data from it
[18:31:37 CET] <atomnuker> jamrial: patch 1 which adds the data type was okay'd
[18:32:07 CET] <atomnuker> patch 2 which adds ffprobe support was okay'd after you agreed checking the size wasn't needed
[18:32:08 CET] <jamrial> atomnuker: yes, but you mistyped the version number in APIChanges :p
[18:32:21 CET] <jamrial> no, that's patch 3
[18:32:54 CET] <jamrial> my patch 2 review was about checking for alloc failure, and to consider using av_make_q
[18:33:15 CET] <atomnuker> I've fixed the version number but sending a patch for 2 digits is too buerocratic for me
[18:34:52 CET] <atomnuker> jamrial: actually nevermind, I'll need to resend patch 1
[18:35:02 CET] <atomnuker> because I have no idea where to put the line in apichanges
[18:35:12 CET] <atomnuker> is it above the cut line or below?
[18:35:39 CET] <jamrial> above, obviously
[18:35:41 CET] <jamrial> 3.4 was already released
[18:38:45 CET] <atomnuker> done
[18:40:14 CET] <durandal_1707> kierank: because mpv doesnt work with ffmpeg anymore
[18:48:32 CET] <kierank> loool
[18:48:33 CET] <kierank> fork wars
[19:03:13 CET] <cone-637> ffmpeg 03Paul B Mahol 07master:a6a6935ee870: avformat: add TiVo ty demuxer
[20:26:33 CET] <cone-637> ffmpeg 03James Almer 07master:f7c01ff24d70: avformat/rtpdec_asf: free the buffer pointed by the AVIOContext
[20:30:53 CET] <ubitux> iive: yeah idc
[20:33:40 CET] <iive> ok, ban removed
[20:54:08 CET] <cone-637> ffmpeg 03Paul B Mahol 07master:cdd19e2c5603: avformat/ty: try harder to find stream signature
[21:02:29 CET] <cone-637> ffmpeg 03Paul B Mahol 07master:a29a0aba79da: avformat/ty: do not overread chunk
[22:03:15 CET] <cone-857> ffmpeg 03Diego Biurrun 07master:f519e131c101: af_bs2b: Add missing casts to complex pointer assignments
[22:03:16 CET] <cone-857> ffmpeg 03Martin Storsjö 07master:333a34da3a6d: configure: Automatically add -isysroot for darwin if --sysroot is specified
[22:03:17 CET] <cone-857> ffmpeg 03Janne Grunau 07master:857e26b655a7: build: Add an option for passing linker flags to the shared library build
[22:03:18 CET] <cone-857> ffmpeg 03James Almer 07master:163e3bd097ea: Merge commit 'f519e131c101ae3948dabf1f7f598efbff5fb536'
[22:03:19 CET] <cone-857> ffmpeg 03James Almer 07master:7a5a1c8c97d6: Merge commit '333a34da3a6d13155de480e7d16ec5fec7f4cd6c'
[22:03:20 CET] <cone-857> ffmpeg 03James Almer 07master:88d6f79ac087: Merge commit '857e26b655a769e5a56bada1a0d9adb44cc176b7'
[22:11:31 CET] <cone-857> ffmpeg 03Ben Chang 07master:bb65eb62991e: nvenc: Add an explicit auto alias
[22:11:32 CET] <cone-857> ffmpeg 03Ben Chang 07master:2e8d88ad5281: nvenc: Use a fifo to manage the free surface pool
[22:11:33 CET] <cone-857> ffmpeg 03Ben Chang 07master:7cb053e4ddf2: nvenc: Minimize the surface allocation
[22:11:34 CET] <cone-857> ffmpeg 03James Almer 07master:29ba2900cb6c: Merge commit '7cb053e4ddf258e2dbf52ccc586548680742d758'
[22:18:08 CET] <cone-857> ffmpeg 03Diego Biurrun 07master:0e83e95c6089: configure: Reset X86ASM_DEP(FLAGS) when probing for the assembler program
[22:18:09 CET] <cone-857> ffmpeg 03James Almer 07master:d9e59029a156: Merge commit '0e83e95c60892747f2f1bd8382f915f2397f99a5'
[22:35:03 CET] <cone-857> ffmpeg 03wm4 07master:70e5e7c02232: dxva: add declarative profile checks
[22:35:04 CET] <cone-857> ffmpeg 03wm4 07master:752ddb45569f: dxva: fix some warnings
[22:35:05 CET] <cone-857> ffmpeg 03wm4 07master:086321c61218: hwcontext_d3d11va: fix crash on frames_init failure
[22:35:06 CET] <cone-857> ffmpeg 03wm4 07master:98d73e417433: hwcontext_d3d11va: allocate staging texture lazily
[22:35:07 CET] <cone-857> ffmpeg 03wm4 07master:5030e3856c21: dxva: support DXGI_FORMAT_420_OPAQUE decoding
[22:35:08 CET] <cone-857> ffmpeg 03wm4 07master:cfc9e7c94eaf: hwcontext_d3d11va: add option to enable debug mode
[22:35:09 CET] <cone-857> ffmpeg 03wm4 07master:068eaa534e7d: dxva: verbose-log decoder GUID list
[22:35:10 CET] <cone-857> ffmpeg 03Anton Khirnov 07master:3fdf50f9e864: hwframe: Allow hwaccel frame allocators to align surface sizes
[22:35:11 CET] <cone-857> ffmpeg 03James Almer 07master:a82a10e08f5d: Merge commit '3fdf50f9e864c88da2139cf066832944de81acaa'
[22:35:27 CET] <JEEB> oppan merges
[22:47:21 CET] <cone-857> ffmpeg 03Lorenz Brun 07master:1cfd566324f4: dvbsubdec: Fixed segfault when decoding subtitles
[22:47:22 CET] <cone-857> ffmpeg 03Vittorio Giovara 07master:a594f17f83a1: dvbsubdec: Free subrect memory on allocation error
[22:47:23 CET] <cone-857> ffmpeg 03James Almer 07master:7d1c79f533e0: Merge commit 'a594f17f83a1ffdc1eec18818208fe39487dd5d7'
[22:48:36 CET] <sfan5> oh are those the commits that caused mpv not to work?
[22:49:34 CET] <durandal_1707> nope
[23:17:11 CET] <cone-857> ffmpeg 03Martin Vignali 07master:4ada428aae2f: avcodec: remove remaining uses of avcodec_get_chroma_sub_sample
[23:17:12 CET] <cone-857> ffmpeg 03Martin Vignali 07master:bb3d62874e87: avutil/pixdesc: remove reference to avcodec_get_chroma_sub_sample
[00:00:00 CET] --- Tue Nov  7 2017