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

[burek]

[00:55:22 CET] <SortaCore> (SOCKET)*(*(*(((int ***)rtsp_format_context->priv_data) + 1) + 2) + 1);
[00:56:26 CET] <wm4> beautiful
[00:56:34 CET] <wm4> (wat)
[01:16:02 CET] <jcdutton> Hi. Is the mailing list broken?  It will not let me subscribe
[01:20:13 CET] <jamrial> jcdutton: not that i know of
[01:20:20 CET] <jamrial> Compn: ^
[01:22:21 CET] <jamrial> BBB: http://coverage.ffmpeg.org/libavcodec/vp9_superframe_bsf.c.gcov.html collateral damage of keeping packet splitting strictly within the decoder
[01:23:27 CET] <jamrial> i mean, in a way it's much better now since there's no way to mux broken files anymore, but this filter is essentially untested now :p
[01:26:25 CET] <wm4> there are other BSFs for fixing obscure things
[01:26:35 CET] <wm4> like the one for mpeg4
[01:26:51 CET] <wm4> also mp3_header_decompress maybe
[01:27:28 CET] <wm4> whatever their use is...
[01:28:17 CET] <wm4> (not sure if those have coverage)
[01:28:28 CET] <jamrial> it was two filters, compress and decompress. the former was removed since the gains were minimal, but the latter was left in place to prevent rendering files created with the former unreadable
[01:29:14 CET] <jamrial> mpeg4_unpack_bframes is tested, yes
[01:30:20 CET] <Compn> jcdutton : did it give you an error message ?
[01:32:13 CET] Action: Compn approves a couple patches stuck in mod queue
[01:33:03 CET] <Compn> jcdutton : if you tell me your mail i can check your subscription status ?
[01:33:11 CET] <Compn> or subscribe you manually
[01:33:12 CET] Action: Compn afk
[01:34:11 CET] <daddesio> jcdutton: I just subscribed today, using gmail.
[01:34:42 CET] <daddesio> and I was able to submit my patchset fine, after confirming my email.
[01:37:43 CET] <Compn> daddesio : you are getting mails from the list ?
[01:37:59 CET] <Compn> could be problem with ffmpeg mail ip is in a sorbs blacklist
[01:38:00 CET] <Compn> :\
[01:41:01 CET] <Compn> nope
[01:41:04 CET] <Compn> just a problem with gmail labels
[01:41:07 CET] <Compn> everything is a-ok
[01:41:08 CET] Action: Compn runs
[01:42:47 CET] <BBB> jamrial: how can it be untested?
[01:42:56 CET] <BBB> jamrial: we have a fate file that uses it
[01:43:07 CET] <BBB> jamrial: one of the fate samples uses superframes and should thus use the bsf
[01:43:39 CET] <BBB> oh I see
[01:43:40 CET] <BBB> the inverse
[01:43:41 CET] <BBB> hm
[01:43:41 CET] <BBB> yes
[01:43:42 CET] <BBB> well...
[01:43:46 CET] <BBB> thats your problem :-p
[01:43:51 CET] <BBB> maybe we dont need it anymore?
[01:43:54 CET] <BBB> I dont know
[01:44:05 CET] <BBB> jamrial: if you want to remove it, Im ok with it
[01:45:43 CET] <jamrial> no, i don't
[01:45:59 CET] <jamrial> just pointing that the existing test is not using it anymore :p
[01:46:51 CET] <jamrial> short of using a broken file (one muxed without it before the parser changes), there's probably no way to test it
[02:23:57 CET] <cone-899> ffmpeg 03Michael Niedermayer 07master:4bb7d72bcfb5: avcodec/h264_parse: Treat escaped and unescaped decoding error equal in decode_extradata_ps_mp4()
[03:48:11 CET] <atomnuker> daddesio: yeah, I really don't think that the opus decoder should be able to downmix by itself
[03:49:25 CET] <atomnuker> can you figure out how -ac 1 could get piped to it so we can test it (I don't think it can, ffmpeg should autoinsert a swr downmix for you) or just remove that codepath entirely?
[04:44:20 CET] <hanna> JEEB: I think those benchmarks are out-of-date now
[04:49:43 CET] <TD-Linux> there is an optional way to do downmixing in libopus where you don't do the stereo phase flips
[04:50:51 CET] <atomnuker> decoder side downmixing is ridiculous nevertheless
[04:51:23 CET] <atomnuker> if this was sanely designed by ac-3 we'd have some sort of side data that real downmixers could use
[05:06:35 CET] <SortaCore> @wm4: lets me access rtsp's socket so I can check bytes_available and guess whether a read call will block
[05:35:05 CET] <SortaCore> there's always *some* data available, but if there's not enough for a H264 frame, I can leave it for a bit
[05:35:35 CET] <SortaCore> that's for single-threaded mode though, for multithreaded I don't bother
[06:09:16 CET] <cone-909> ffmpeg 03Jim DeLaHunt 07master:42a22d01d1a0: doc: reorganize developer.texi chapter hierarchy
[11:33:55 CET] <durandal_1707> who is working on sbc integration?
[11:34:24 CET] <atomnuker> no, I think the author's too busy
[11:34:56 CET] <atomnuker> weren't that much things to do to it though, I'll just ping the thread
[12:14:20 CET] <BtbN> http://git.videolan.org/?p=ffmpeg/nv-codec-headers.git;a=summary is a thing now.
[12:25:16 CET] <durandal_1707> do same for avisynth so we can ditch both
[19:19:27 CET] <cone-856> ffmpeg 03Martin Vignali 07master:fa470384ea3f: avfilter/vf_threshold : move context func init in ff_threshold_init
[19:19:28 CET] <cone-856> ffmpeg 03Martin Vignali 07master:cfce4427503a: checkasm/vf_threshold : add checkasm test for threshold8
[19:19:29 CET] <cone-856> ffmpeg 03Martin Vignali 07master:51345cb1d553: avfilter/x86/vf_threshold : make macro for threshold8 in order to add avx2 version
[19:19:30 CET] <cone-856> ffmpeg 03Martin Vignali 07master:9719d57b34f2: avfilter/x86/vf_threshold : add avx2 version for threshold 8
[19:19:31 CET] <cone-856> ffmpeg 03Martin Vignali 07master:6e3e69659148: avfilter/x86/vf_threshold : cosmetic indent
[20:05:26 CET] <JEEB> I don't think our H.264 decoder can even give you the frames in the incorrect order? so if someone's "latency' is coming from reordering I can only tell him "too bad"
[20:09:21 CET] <nevcairiel> if you set the low latency flag i believe you can
[20:09:39 CET] <JEEB> oh
[20:13:00 CET] <JEEB> don't see an avoption and has_b_frames isn't poked in h264dec.c
[20:13:19 CET] <JEEB> the person I'm trying to help in #ffmpeg is focused only on decoding so most likely no avformat
[20:13:59 CET] <JEEB> but I already told him that reordering is a requirement in the decoder so if the stream requires reordering then rip
[20:14:00 CET] <nevcairiel> -flags low_delay
[20:14:02 CET] <nevcairiel> i believe
[20:14:35 CET] <JEEB> doesn't seem to be utilized in H.264 decoder
[21:53:22 CET] <cone-856> ffmpeg 03Marton Balint 07master:5a93a85fd0ad: avformat/mxfdec: fix last packet timestamps
[23:59:23 CET] <atomnuker> durandal_1707: does setrange solve an issue when dropping YUVJ or was it just missing?
[00:00:00 CET] --- Mon Dec  4 2017