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

[burek]

[00:03:56 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:c3f781c52ad7: tests/Makefile: Fix ffservertest dependencies
[00:03:57 CET] <cone-287> ffmpeg 03Michael Niedermayer 07master:1e7f9b0ec602: tests: Fix running ffserver under qemu
[00:11:53 CET] <lotharkript> i'm looking on how to fix the examples/remuxing.c  to support y4m (or any container supporting rawvideo) to y4m. And following your idea, i will need to add code in the loop to convert the AVpacket from the demuxer to AVFrame, then either call wrapped_avframe_encode to wrap it to an AVPacket.  The loop will become ugly, no? 
[00:12:59 CET] <nevcairiel> like I said earlier, examples don't have to cover every case
[00:13:16 CET] <nevcairiel> its meant to be a simple illustration of API usage
[00:13:27 CET] <lotharkript> but the example are for people who want to know about the API, no?
[00:13:32 CET] <nevcairiel> a full blown app would probably factor a bunch of things into various components
[10:14:18 CET] <superware> hi, is cehoyos around?
[10:16:59 CET] <ubitux> rarely
[10:17:02 CET] <nevcairiel> he doesnt usually hang around here, no
[10:43:21 CET] <superware> I see
[10:48:35 CET] <superware> I'm trying to resolve https://trac.ffmpeg.org/ticket/5615, problem is I don't have sufficient knowledge to debug this myself.
[11:03:20 CET] <cone-542> ffmpeg 03Daniel Verkamp 07master:e856ac237328: avcodec/msrledec: implement vertical offset in 4-bit RLE
[11:23:56 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:d56c7830c097: avcodec/raw: add gray10 support in nut
[11:36:50 CET] <cone-542> ffmpeg 03Paul B Mahol 07master:57ef0f0f17a0: avfilter/vf_waveform: add gray10 and gray12 support
[12:58:52 CET] <wm4> jkqxz: wait what, vaapi 10 bit support confirmed?
[13:00:07 CET] <JEEB> najs
[13:06:34 CET] <jkqxz> wm4:  ?  It's been there for a while.
[13:13:10 CET] <wm4> I thought it was unconfirmed whether it works
[13:17:26 CET] <jkqxz> Um, why?  I'm sure all the Intel people would have enjoyed making lots of driver changes which didn't work at all.
[13:23:56 CET] <jkqxz> I only got a Kaby Lake last week.  I've been looking at encode first (VP9 is on libav ML), but I'll look at decode after that (if someone else doesn't do it for me first, as they kindly have here).
[14:04:01 CET] <BBB> J_Darnley: I love the new asm& one small thing (this isnt critical, just a personal preference), for the sse2/avx new simd you wrote, do you think it makes sense to start using named registers?
[14:04:11 CET] <BBB> J_Darnley: it tends to make the asm quite a bit more readable imo
[14:09:24 CET] <J_Darnley> That is usually my preference too
[14:10:32 CET] <J_Darnley> However, since so much of this is done through macros that don't use named regs I see less use for it
[14:13:53 CET] <ElAngelo> trying to create a bug, instructions tell me to upload the sample to upload.ffmpeg.org
[14:13:59 CET] <ElAngelo> but i get a connection timeout?
[14:17:50 CET] <kierank> BBB: do you know of anything that needs conversion to avx2 in h264?
[14:17:57 CET] <kierank> michaelni: ^ maybe a q for you as well
[14:18:39 CET] <BBB> maybe the MC?
[14:18:53 CET] <BBB> loopfilter might also be a good candidate
[14:18:56 CET] <BBB> let me check
[14:19:06 CET] <michaelni> everything thats not avx2 and would be faster with avx2
[14:19:33 CET] <BBB> ff_h264_idct8_add4 also?
[14:19:37 CET] <jamrial> not everything. i've written a couple functions that did not see any speed up because of cross lane crap
[14:19:48 CET] <BBB> michaelni: well, lots of it doesnt help because you need more data throughput
[14:19:51 CET] <kierank> various benchmarks https://usercontent.irccloud-cdn.com/file/VVxNyafi/h264_cavlc_sd.png https://usercontent.irccloud-cdn.com/file/g3qsZbqT/mpeg2hd.png https://usercontent.irccloud-cdn.com/file/BuzLCGg3/mpeg2sd.png https://usercontent.irccloud-cdn.com/file/8LfJgjjE/h264_cabac_422_10bit.png
[14:19:51 CET] <kierank> https://usercontent.irccloud-cdn.com/file/AuiHIqtO/h264_cabac_golf_sat_420.png
[14:20:06 CET] <BBB> I think the idct block functions can help (idct8_add4, idct_add16)
[14:20:12 CET] <BBB> MC should also help
[14:20:15 CET] <BBB> I wouldnt bother with intra
[14:20:34 CET] <BBB> I also wouldnt bother with chroma initially TBH, but thats just me
[14:21:11 CET] <kierank> (whoops put mpeg2 in there as well)
[14:21:13 CET] <BBB> and idct_addN, loopfilter, weight/biweight/MC stuff
[14:21:17 CET] <BBB> thats what I would go for
[14:21:39 CET] <BBB> I dont know how much gain youll get in general
[14:21:53 CET] <BBB> why dont you ignore h264 and optimize vp9 loopfilter instead? thats much more fun!!!
[14:22:02 CET] <BBB> </commercial break>
[14:22:23 CET] <nevcairiel> but thats your job
[14:22:24 CET] <nevcairiel> :)
[14:22:31 CET] <kierank> if there was an interlaced profile of vp9, sure
[14:22:32 CET] <kierank> </troll>
[14:22:32 CET] <BBB> I s'pose
[14:22:40 CET] <BBB> add8x4 is the idct block function
[14:22:42 CET] <BBB> that one can be made avx2
[14:22:46 CET] <BBB> but its only 3.2%...
[14:22:58 CET] <nevcairiel> you should totally invent a much faster way to decode cabac
[14:23:01 CET] <BBB> yeah
[14:23:07 CET] <BBB> cabac is the killer& 60%& wtf
[14:23:17 CET] <BBB> actually is that cavlc?
[14:23:21 CET] <kierank> yeah
[14:23:25 CET] <BBB> WHAT ARE YOU DOING!!!!!
[14:23:31 CET] <BBB> YOU TERRIBLE PERSON!!!!!
[14:23:41 CET] <kierank> it's some other encoder
[14:24:02 CET] <kierank> we get streams from it
[14:24:37 CET] Action: ElAngelo just reported 5982
[14:25:12 CET] <BBB> yeah so theres totally potential for avx2
[14:25:28 CET] <BBB> but you will get maybe 10% overall speedup if you do everything you can?
[14:25:32 CET] <BBB> its not very much I admit :(
[14:25:45 CET] <kierank> still worth it
[14:26:09 CET] <BBB> J_Darnley: I see your point btw, I guess its fine&
[14:26:14 CET] <kierank> and there's also 4:2:2 10-bit which has some opts needed
[14:26:29 CET] <BBB> I cant believe you guys wrote mmxext simd
[14:26:47 CET] <J_Darnley> BBB: If I need to rework the patch I will consider adding it with a bit more weight.
[14:27:30 CET] <BBB> h264 was written before named registers were a thing& its basically old cruft& it shows h264s age& its ok
[14:27:33 CET] <J_Darnley> Can I help it if there's only a 420 mmxext version I can copy?
[14:27:43 CET] <BBB> hahaha
[14:27:51 CET] <BBB> its fine, its just funny
[14:28:04 CET] <BBB> not bad funny, just funny
[14:28:30 CET] <J_Darnley> :)
[14:31:33 CET] <BBB> so& are we actually voting on ffserver yes/no removal now?
[14:31:38 CET] <BBB> or is that off the table again?
[14:31:44 CET] <BBB> I dont udnerstand the email thread anymore
[14:32:44 CET] <wm4> nicolas thinks he's making a vote to retract the earlier vote
[14:33:26 CET] <BBB> right, so is that vote on?
[14:33:27 CET] <BBB> or not?
[14:34:05 CET] <atomnuker> J_Darnley: chroma_format_idc == 3 maps to 444 so the 422 assembly is used, do the functions work with that?
[14:34:25 CET] <J_Darnley> oh, I don't know
[14:34:37 CET] <J_Darnley> It does pass fate but maybe fate doesn't have a 44 sample
[14:34:41 CET] <J_Darnley> *444 sample
[14:36:13 CET] <J_Darnley> I might guess that it doesn't work with 444 because I think I'm mostly just doing twice as many lines in 422
[14:37:32 CET] <BBB> fate should have 1 444 sample
[14:37:49 CET] <BBB> oh wait
[14:37:54 CET] <BBB> 444 doesnt use chroma functions
[14:38:01 CET] <BBB> it just uses the luma function pointers for all planes
[14:38:22 CET] <BBB> the chroma functions are only called for 422 and 420 (idct_format == 2 or 1)
[14:38:30 CET] <BBB> so its probably fine
[14:52:30 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:46752d6b12c8: avfilter/vf_extractplanes: add extract support for 10bit and 12bit formats
[14:58:48 CET] <durandal_1707> anybody wants to write some simd for free?
[15:00:58 CET] <atomnuker> durandal_1707: what do you need?
[16:34:34 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:c9dcd25288e3: avfilter/vf_bitplanenoise: add gray10 and gray12 suppport
[16:52:57 CET] <cone-857> ffmpeg 03Paul B Mahol 07master:9e9c2276c308: avfilter/vf_masked*: add gray10 and gray12 support
[17:41:39 CET] <BtbN> is there a way to mark intentional fallthrough in a switch case, so coverity doesn't complain?
[17:42:06 CET] <nevcairiel> write /* fall through */ on them
[17:44:46 CET] <BtbN> https://github.com/BtbN/FFmpeg/commit/00d8515150bf1c1b021f56df1cc4e48c2783b08d like this?
[17:45:33 CET] <nevcairiel> probably
[17:45:40 CET] <nevcairiel> look for such comments, its used elsewhere
[17:46:51 CET] <BtbN> yeah, seems about right.
[18:59:35 CET] <ElAngelo> where am i supposed to upload a sample video for a bug?
[19:03:48 CET] <BtbN> philipl, can I push the late-surface-format patch?
[19:04:26 CET] <jamrial> ElAngelo: https://ffmpeg.org/bugreports.html
[19:04:46 CET] <jamrial> but if it's small, you can attach it to the ticket instead
[19:05:00 CET] <ElAngelo> it's 20MB
[19:05:50 CET] <ElAngelo> i've tried the ftp server already
[19:05:54 CET] <ElAngelo> it was not responding
[19:27:03 CET] <ElAngelo> still not responing :s
[19:27:33 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:744a0b520663: avformat/idroqdec: Check chunk_size for being too large
[19:27:34 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:6216127d0cb9: tests/ffserver-regression.sh: give wget a timeout and prevent retries
[19:27:35 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:dbe18780609a: tests/ffserver.regression.ref: update ffserver checksums
[19:27:36 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:472fee91bcf9: ffserver_config: Setup codecpar in add_codec()
[19:27:37 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:606702ea3483: ffsrever: Make the status page bitexact if any stream is bitexact
[19:27:38 CET] <cone-857> ffmpeg 03Michael Niedermayer 07master:bced37c155c4: tests/ffserver-regression: Check the status page too
[20:00:47 CET] <jamrial> michaelni: this work you're committing is not an effort aimed at making ffserver standalone. it's aimed at helping the attempts at keeping it in the tree
[20:00:53 CET] <jamrial> please, either work in the former, or wait until this vote thing is over
[20:02:54 CET] <jamrial> work in the former will be useful regardless of the outcome. work in the latter will be wasted time if July's decision and agreement remains in place
[20:04:26 CET] <durandal_1707> shouldn't he work on making it not use internal stuff?
[20:04:35 CET] <wm4> and I hoped everyone would just ignore this thread
[20:05:11 CET] <michaelni> jamrial, i understand the work that i do may be wasted within ffmpeg but its interresting and fun work that i like doing, and like most i work on what is fun r what someone pays me to do
[20:05:27 CET] <jamrial> michaelni: alright
[20:06:14 CET] <jamrial> wm4: not acknowledging it will be good for nothing if others do
[20:06:42 CET] <wm4> I don't care, fuck it
[20:06:47 CET] <durandal_1707> if nobody is working on removing internal stuff I'm for removing ffserver
[20:07:02 CET] <jamrial> what we need to do is establish limits about what we can start a vote for. things like a vote to undo another vote shouldn't be allowed
[20:07:11 CET] <jamrial> however that is not the case here
[20:07:55 CET] <durandal_1707> just put up vote on ffserver immediate removal...
[20:08:08 CET] <wm4> time to turn this into a farce
[20:09:37 CET] <durandal_1707> michaelni: are you paid to work on ffserver?
[20:09:52 CET] <michaelni> durandal_1707, no
[20:22:41 CET] <wm4> should I send this lol http://pasted.co/c6d6ceb6
[20:23:29 CET] <nevcairiel> isnt it simpler to just vote no
[20:25:30 CET] <j-b> I'm sad to not be allowed to vote :)
[20:27:40 CET] <durandal_1707> revoke decision to revoke decision to revoke ...
[20:28:05 CET] <BBB> wm4: just vote no
[20:28:12 CET] <BBB> wm4: dont make this more difficult than it is
[20:28:24 CET] <wm4> but that's exactly what I want to do
[20:28:36 CET] <wm4> if nicolas can sabotage and be special, why not me as well?
[20:29:22 CET] <BBB> because we want to move on?
[20:29:29 CET] <BBB> hes looking for a final yes/no
[20:29:34 CET] <BBB> give him the final yes/no
[20:29:37 CET] <BBB> and then move on
[20:29:57 CET] <durandal_1707> hmm, change voting committee rules so Nicolas is not in? dirty me
[20:34:44 CET] <BBB> so meta
[20:34:54 CET] <BBB> just vote whatever way you want to and move on
[20:35:10 CET] <BBB> you guys are taking all this too personally, which makes it very complicated
[23:47:56 CET] <michaelni> fate is yellow, durandal_1707, d56c7830c0973dc4d2a068ba0b427ea6c1760dc2 breaks several tests
[23:50:02 CET] <michaelni> example, but it fails acros many platforms: http://fate.ffmpeg.org/report.cgi?time=20161129202409&slot=x86_64-freebsd10-clang33
[23:55:07 CET] <durandal_1707> michaelni: one just needs to update hashes
[23:56:24 CET] <jamrial> durandal_1707: you also forgot to add gray10 and gray12 to nut.c, i think
[23:57:14 CET] <jamrial> mmh, maybe not
[23:57:47 CET] <jamrial> no, they are there. you just forgot to update the hashes
[00:00:00 CET] --- Wed Nov 30 2016