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

[burek]

[00:31:17 CET] <kierank> michaelni: is there any easy way to turn off er just for 10-bit 
[00:40:30 CET] <michaelni> yes
[00:42:22 CET] <michaelni> see er_supported or ff_er_frame_end() its also turned off for other unsupported cases
[03:43:57 CET] <raytiley_> sending patches w/ git to an email list is new to me... I just messed up and sent a new patch instead of replying to the original thread. What should I do if anything?
[03:47:42 CET] <cone-873> ffmpeg 03Brendan McGrath 07master:4e3e8980b58f: dashdec: Fix segfault on decoding segment timeline
[03:52:42 CET] <wm4> raytiley_: that's not so bad... to reply, you can use --in-reply-to
[03:52:55 CET] <wm4> or just send them as attachments
[03:53:28 CET] <wm4> also my mail client shows your mail as a reply
[03:54:12 CET] <raytiley_> hmm.. I did that.. but showed up as a new thread in inbox. oh well...
[03:54:40 CET] <raytiley_> thanks
[03:54:41 CET] <Compn> its fine if new thread
[03:54:46 CET] <Compn> welcome to contributing 
[03:55:34 CET] <wm4> I don't think we have an overlay strict policy on whether updated patches should be posted as reply or new thread anyway
[03:57:15 CET] <raytiley_> cool, I'll keep that in mind for the future. The email list and git patches still stress me out a bit.
[04:12:03 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:05f4703a168a: avcodec/mpeg4videodec: Check mb_num also against 0
[04:12:04 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:4a94ff4ccd4f: avcodec/get_bits: Document the return code of get_vlc2()
[04:12:05 CET] <cone-873> ffmpeg 03Michael Niedermayer 07master:d4967c04e040: avcodec/mpeg4videodec: Avoid possibly aliasing violating casts
[14:42:30 CET] <jdarnley> atomnuker: if you're not busy I need to ask you a some questions about vc2 encoder.
[14:42:41 CET] <jdarnley> Which places does the order of transform coefficients matter?
[14:43:00 CET] <jdarnley> I am trying to remove the deinterleave
[14:43:49 CET] <jdarnley> I think I have teken care of encode_subband, count_hq_slice, and the haar transform.
[14:44:02 CET] <jdarnley> But I still can't get identical output.
[14:44:06 CET] <atomnuker> dunno what you mean, you can remove deinterleave and the only thing you should do is make the quantization functions pick the same coeffs as if there was deinterleave
[14:44:52 CET] <jdarnley> Yeah, skip over values
[15:04:25 CET] <Chloe> raytiley_: don't worry about fucking up sending stuff to the ML. It's clunky as shit and we've all done it
[15:04:25 CET] <kierank> jdarnley: what was the problem with getting fragments into master?
[15:04:49 CET] <kierank> jdarnley: for the encoder
[15:05:00 CET] <jdarnley> I couldn't decode the output correctly with my crap little program.
[15:06:00 CET] <jdarnley> So I think there is a bug since I think it did work correctly with our hacked branch
[15:06:33 CET] <jdarnley> *a bug in what I added to the encoder for the master branch
[17:43:09 CET] <kierank> jdarnley: but our hacked branch didn't touch encoder
[17:43:19 CET] <kierank> or the hacks to do low latency you mean?
[17:44:24 CET] <jdarnley> Yes, I do think my crap program could decode the output of our low-latency encoder branch
[18:11:57 CET] <rindolf> hi all! make check fails here - http://paste.debian.net/1007843/
[18:13:38 CET] <chance83> what room for avfilter development?
[18:16:26 CET] <Chloe> rindolf: distclean, reconfigure, and make
[18:18:00 CET] <rindolf> Chloe: ok
[18:24:47 CET] <rindolf> Chloe: done
[18:25:12 CET] <rindolf> Chloe: now run make check again?
[18:26:00 CET] <Chloe> yes
[18:26:51 CET] <rindolf> Chloe: same problem
[18:27:27 CET] <Chloe> make fate-api-threadmessage V=1
[18:28:44 CET] <rindolf> Chloe: http://paste.debian.net/1007847/
[18:29:26 CET] <Chloe> ldd ./tests/api/api-threadmessage-test
[18:29:53 CET] <jkqxz> I think you built with --enable-shared.  The test suite doesn't work normally in that case.
[18:29:57 CET] <Chloe> are you explicitly asking it to produce shared libraries
[18:30:13 CET] <rindolf> jkqxz: i did
[18:30:22 CET] <Chloe> jkqxz: this sounds like a bug?
[18:30:24 CET] <jkqxz> If you install it should work, as should setting LD_LIBRARY_PATH to point at the build directory containing the shared libraries.
[18:30:55 CET] <Chloe> I guess a patch which sets LD_LIBRARY_PATH temporarily when testing with shared libraries would be welcxome
[18:31:20 CET] <jkqxz> Chloe:  I guess?  Testing static builds is generally much saner.
[18:31:49 CET] <Chloe> jkqxz: sure testing static builds is better, but you can hardly call not testing shared builds sane.
[18:33:04 CET] <jkqxz> The only difference is the linking, which isn't really something the test suite is intending to test.
[18:34:57 CET] <rindolf> you can refuse to run check on a shared build w a helpful msg
[18:35:19 CET] <jkqxz> It works, you just have to install first.
[18:36:12 CET] <jkqxz> So that the shared libraries it picks are the right ones.  (The problem is more insidious when you already have older libraries with the same version installed, though.)
[18:37:07 CET] <rindolf> jkqxz: i installed and it still fails
[18:37:24 CET] <jkqxz> But yes, something to clean that up so it's harder to do the wrong thing would be welcome.
[18:40:02 CET] <durandal_1707> chance83: this one
[18:47:12 CET] <rindolf> jkqxz: ok
[19:13:07 CET] <chance83> durandal_1707, if I made a change to some of the filters like adding a process_command to get some of the internal coefficients (example: integrated loudness from ebur128), what is the likelihood that patch would be accepted?
[19:13:32 CET] <chance83> right now these patches just av_log on filter uninit
[19:13:39 CET] <chance83> s/patches/filters
[19:20:18 CET] <durandal_1707> chance83: dunno, ask ebur128 maintainer, ubitux 
[23:01:10 CET] <chance83> why doesnt a redirect on cout/cerr rdbuf work for av_log messages?
[23:04:59 CET] <BtbN> Why would ffmpeg care about some C++ thing?
[23:11:06 CET] <chance83> BtbN, duh... thank you
[23:11:08 CET] <chance83> =)
[00:00:00 CET] --- Tue Jan 30 2018