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

[burek]

[00:15:26 CEST] <cone-340> ffmpeg 03Marton Balint 07master:366e6bfc517c: fate: add overlay filter tests with alpha
[00:23:47 CEST] <cone-340> ffmpeg 03Michael Niedermayer 07master:1e6cab874512: avcodec/diracdec: Check perspective_exp and zrs_exp.
[00:23:48 CEST] <cone-340> ffmpeg 03Michael Niedermayer 07master:92da23093c78: avcodec/diracdec: Fixes integer overflow
[00:43:35 CEST] <Shiz> k/w 58
[08:25:21 CEST] <rcombs> ubitux: oh hey, was it you that recommended the Odroid-C2
[08:26:39 CEST] <rcombs> consider vs the Rock64, which is slightly slower, but has USB-3, and a much better GPU (H264 High 10 support and a kernel API that's actually useful enough that someone's written an HWContext impl for it)
[08:54:02 CEST] <ubitux> rcombs: it was a relatively "safe bet"
[08:54:09 CEST] <ubitux> rockchip support should be good though
[08:54:24 CEST] <ubitux> your main issue with arm boards is the mainline support
[08:55:19 CEST] <rcombs> yeah, I think I'll use the C2 for ARM/ARM64 dev work, but the Rock64 seems like it actually might replace my Pi3 for home media playback
[08:57:05 CEST] <ubitux> how are you going to play 10-bit animes with that stuff :s
[08:58:40 CEST] <rcombs> it has H264 High 10 hardware decoding support
[08:59:02 CEST] <wm4> wat
[08:59:41 CEST] <rcombs> only consumer chip I'm aware of that does
[09:19:24 CEST] <JEEB> rcombs: wait what
[09:19:31 CEST] <rcombs> that was my reaction
[09:19:38 CEST] <JEEB> as in, proper or "the artifacts don't show up"
[09:19:51 CEST] <JEEB> because after 2011 I've seen a lot of samples with the latter
[09:22:11 CEST] <rcombs> I'll tell you when mine comes in
[09:22:36 CEST] <JEEB> k
[09:23:21 CEST] <rcombs> data sheet says "H.264/AVC Base/Main/High/High10 profile @ level 5.1; up to 4Kx2K @ 60fps"
[09:23:31 CEST] <rcombs> (RK3328)
[09:25:11 CEST] <rcombs> JEEB: how does one distinguish "proper" from "the artifacts don't show up"
[09:25:46 CEST] <rcombs> check if output is bitexact with lavc?
[09:27:48 CEST] <JEEB> rcombs: that and I think most 8bit decoders start with fabulous purple with this sample http://www.cccp-project.net/beta/test_files/H.264-10bit-sample-railgun.mkv
[09:28:03 CEST] <rcombs> yeah, that I have seen (on RPi)
[09:28:29 CEST] <JEEB> being able to verify bit-exactness with lavc would be the final verdict I guess
[09:28:31 CEST] <rcombs> fabulous purple as soon as the black+white portion ends
[09:29:06 CEST] <rcombs> I'm not sure if it returns 16-bit for 10-bit input, or if it internally truncates or dithers the output to 8-bit
[09:29:41 CEST] <rcombs> if the latter, that makes verification tricky
[09:29:56 CEST] <JEEB> true
[09:30:52 CEST] <JEEB> I guess if it outputs 8bit then you have to bit shift that into 10bit and check error
[09:32:13 CEST] <rcombs> oh apparently it does output 10-bit as 10-bit
[09:32:29 CEST] <rcombs> so yeah I'll give it a go once I've got mine
[09:36:16 CEST] <JEEB> cool
[09:36:42 CEST] <JEEB> I'd be honestly surprised if we got proper 10bit decoding with HWdec. although even if it supports it, it's not like you can use 10bit in general since most things just don't support it :<
[09:52:18 CEST] <wm4> for hevc rockchip returns bit-packed p010
[09:59:41 CEST] <rcombs> do you have a device or are you looking at docs
[10:05:23 CEST] <wm4> if it's rockchip it's probably the same one longchair has been working on
[10:05:31 CEST] <wm4> to add ffmpeg and mpv support
[11:47:15 CEST] <cone-745> ffmpeg 03Paul B Mahol 07master:28e9ba951d1a: avcodec/dnxhdenc: call slice thread code only if slice threading is enabled
[11:59:25 CEST] <rcombs> wm4: yes
[11:59:34 CEST] <rcombs> I pinged him about it to test, but he's out atm
[12:18:13 CEST] <wm4> make: *** No rule to make target 'libavcodec/x86/simple_idct.asm', needed by 'libavcodec/x86/simple_idct.o'.  Stop.
[12:18:22 CEST] <wm4> I can't tell how often I've hit this shit now
[12:19:36 CEST] <kierank>  heh
[12:19:36 CEST] <kurosu> from a branch where it was not templated to another? or the nasm bug?
[12:19:49 CEST] <kurosu> just do rm libavcodec/x86/simple_idct*
[12:20:25 CEST] <wm4> the dependency issue... I know how to fix it, but it's still very annoying
[12:20:40 CEST] <wm4> especially because with make -j4 it can look like it successfully finished the builfd
[12:33:44 CEST] <rcombs> wm4: rm libavcodec/x86/*.d libavcodec/*.d
[12:33:54 CEST] <rcombs> we really should fix that though
[12:35:02 CEST] <wm4> I'd rather not delete libavcodec/*.d because then the whole thing probably rebuilds, "rm libavcodec/x86/simple_idct.d" is enough (but annoying)
[12:35:17 CEST] <wm4> I must have hit that like 10 times when testing
[12:35:23 CEST] <rcombs> remaking the .d files isn't too bad, is it?
[13:17:33 CEST] <J_Darnley> Clearly nobody should ever delete a file in ffmpeg because out-of-date .d files might refer to it.
[13:18:19 CEST] <J_Darnley> And why the heck is put_bits_ptr so shit that it doesn't seem to point to the right place?
[13:20:19 CEST] <atomnuker> J_Darnley: you're doing something wrong
[13:20:25 CEST] <J_Darnley> Well clearly.
[13:21:51 CEST] <J_Darnley> Do I need to flush before calling it?
[13:23:39 CEST] <iive> imho, this is makefile bug 
[13:24:02 CEST] <iive> unless somebody knows how to write the makefile in a way that avoids this bug.
[13:25:02 CEST] <iive> i mean, it is a `make` bug
[13:25:38 CEST] <J_Darnley> Mmm.  I think x264 has a dependency generation step before building anything.  Maybe we should steal that.
[13:25:53 CEST] <wm4> iive: well it doesn't happen with my makefile for mpv, which is derived from mplayer's
[13:26:47 CEST] <iive> J_Darnley: the problem is that dependency are already generated, doing them again is kind of pointless
[13:27:18 CEST] <iive> wm4: well, i've seen it happen in mplayer, so maybe you could tell us how you solved that.
[13:29:31 CEST] <wm4> are you sure in mplayer it wasn't just a recursively called ffmpeg makefile
[13:30:27 CEST] <rcombs> is something actually depending on the .o
[13:31:04 CEST] <rcombs> or is make just noticing that there's a dep defined on a nonexistent file
[13:40:09 CEST] <wbs> look for "Dummy rule" in Makefile, there's a special case for this, but only for .h files
[13:44:51 CEST] <wm4> so the AVIO read_packet callback accepts partial reads?
[13:51:23 CEST] <durandal_1707> michaelni: why is frame encoder number of threads limited to 64?
[13:53:10 CEST] <durandal_1707> i feel there is nothing left to do
[13:53:51 CEST] <wm4> durandal_1707: htsp demuxer
[13:54:36 CEST] <durandal_1707> what the fck is that? some kind of abdomination?
[13:56:20 CEST] <wm4> it's tvheadend's streaming protocol https://tvheadend.org/projects/tvheadend/wiki/Htsp
[13:56:51 CEST] <nevcairiel> why do single products invent their own streaming shit now
[13:57:06 CEST] <wm4> dunno
[13:57:25 CEST] <nevcairiel> and its probably terrible? :)
[14:00:35 CEST] <J_Darnley> Ah ha!  I *do* need to flush even if put_bits is aligned to a byte boundary.
[14:03:02 CEST] <atomnuker> durandal_1707: ffa1 research?
[14:13:19 CEST] <durandal_1707> atomnuker: im more home with ffv2 research
[14:19:15 CEST] <atomnuker> cool
[14:20:30 CEST] <atomnuker> the key to that and imo to everything video codec related right now is this: frequency domain intra
[14:21:04 CEST] <atomnuker> daala couldn't figure it out but if it did it would have been almost perfect
[14:32:59 CEST] <Compn> durandal_1707 : mplayer netstream ? :P
[14:33:36 CEST] <Compn> durandal_1707 : bug kostya for indeo specs
[16:30:32 CEST] <cone-642> ffmpeg 03Michael Niedermayer 07master:931c0ac95ceb: avcodec/zmbv: Check decomp_size
[21:56:47 CEST] <cone-104> ffmpeg 03Marton Balint 07master:7160992431b0: avformat/utils: always av_reduce r_frame_rate
[22:25:14 CEST] <cone-104> ffmpeg 03Werner Robitza 07master:801ba0f0ee72: filters.texi: explain audio upsampling in loudnorm
[23:38:16 CEST] <cone-104> ffmpeg 03Kyle Swanson 07master:2955cd448282: filters.texi: clarify audio upsampling in loudnorm
[00:00:00 CEST] --- Fri Aug 18 2017