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

[burek]

[00:00:57 CEST] <philipl> "working" is a probabilistic statement
[00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:315f51128a95: avcodec/prores_kostya: increase bits usage when alpha is used
[00:05:30 CEST] <cone-547> ffmpeg 03Paul B Mahol 07master:4bd4fc56abf9: avcodec/proresenc_kostya: use frame metadata instead of avctx
[01:07:29 CEST] <cone-547> ffmpeg 03Michael Niedermayer 07master:7d317d4706b4: avcodec/frame_thread_encoder: Fix AV_OPT_TYPE_STRING handling in priv_data
[01:07:49 CEST] <michaelni> durandal_170, should be fixed
[02:03:10 CEST] <iive> atomnuker: what asm did you use for the tests?
[02:04:24 CEST] <atomnuker> nasm
[02:04:40 CEST] <iive> version?
[02:05:21 CEST] <atomnuker> 2.13
[02:05:30 CEST] <atomnuker> 2.13.01
[02:05:47 CEST] <iive> ok, i have the same nasm version.
[02:12:40 CEST] <iive> atomnuker: btw, I do not have complete benchmarks from you. some defines were missing the the file. have you done them?
[02:14:18 CEST] <iive> if you haven't, don't do them now, i'll be leaving in a moment
[02:15:42 CEST] <atomnuker> no, not yet, what should I do?
[02:15:46 CEST] <atomnuker> *what else
[02:19:33 CEST] <iive> stall_write_forwarding, short_syy_update,
[02:19:50 CEST] <iive> const_in_x64_reg_is_faster
[02:20:06 CEST] <iive> and the blends...
[02:30:28 CEST] <iive> see ya
[03:19:40 CEST] <kierank> atomnuker: no it was fork drama at the time
[03:19:44 CEST] <kierank> iirc
[04:01:37 CEST] <atomnuker> ?
[08:41:35 CEST] <rcombs> atomnuker: the prores stuff, presumably
[09:14:00 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading
[09:56:00 CEST] <cone-442> ffmpeg 03Matthieu Bouron 07master:db5bf64b214d: lavc/x86: clear r2 higher bits in ff_sbr_sum_square
[12:56:28 CEST] <TMM> good afternoon all!
[13:07:50 CEST] <wm4> it's not good, it's too hot
[13:14:15 CEST] <durandal_1707> michaelni: have you looked at #5405, its about ffv1?
[13:30:03 CEST] <TMM> wm4, it finally cooled down here a bit, it was way too hot lately though 
[13:35:24 CEST] <kierank> J_Darnley: ask atomnuker here if you have questions please
[15:27:48 CEST] <BBB> gh0st__: Ill probably push your patch sometime today
[15:27:54 CEST] <BBB> gh0st__: unless people have review comments
[15:28:10 CEST] <gh0st__> BBB:Sure
[15:28:41 CEST] <BBB> next& threading?
[15:29:03 CEST] <kierank> durandal_1707: holy crap you are 
[15:29:04 CEST] <kierank> ][';/./#
[15:29:04 CEST] <kierank> ][=]
[15:29:08 CEST] <kierank> shit
[15:29:52 CEST] <durandal_1707> kierank: what?
[15:30:13 CEST] <kierank> finally getting rid of prores dupes
[15:30:38 CEST] <BBB> \o/
[15:30:40 CEST] <BBB> hurray
[15:32:34 CEST] <gh0st__> BBB: Yes, I'll do one or two more avx2 versions of the directional intra predictions, by then I'll settle all my business with my university, and we can do tile threading. =)
[15:32:45 CEST] <BBB> ok
[15:35:42 CEST] <BBB> which one is next? I guess one of the hu/hd or vl/vr ones?
[15:35:54 CEST] <BBB> hu/vl are probably easier since they only use one edge
[15:36:08 CEST] <BBB> hd/vr are like ddr, they use both edges so a little more complicated
[15:37:59 CEST] <gh0st__> Yeah, I'll do vl and vr they are pretty simple indeed.
[15:38:50 CEST] <atomnuker> what about loopfilter avx2?
[15:39:26 CEST] <gh0st__> atomnuker: I will do that too.
[15:41:21 CEST] <atomnuker> BBB: do you know if youtube enable tile threaded decoding on any encodes they do?
[15:41:37 CEST] <BBB> I believe it is, yes
[15:41:56 CEST] <BBB> atomnuker: 10-bit will be done; 8-bit is in the planning but also very hard so cant guarantee well get to it
[15:44:56 CEST] <atomnuker> odd, on a 4k video ripped from youtube I'm getting 1 row and 8 cols (s->s.h.tiling.tile_cols)
[15:45:09 CEST] <atomnuker> on an 8k I'm getting 1 row and 16 cols
[15:46:14 CEST] <nevcairiel> twice the width, twice the cols? :)
[15:46:27 CEST] <atomnuker> yes, but 1 row?
[15:51:48 CEST] <BBB> rows affect latency, not threading
[15:52:03 CEST] <BBB> they have rows-mt also but apparently youtube isnt using it
[15:52:16 CEST] <BBB> its a bitstream thing
[15:52:22 CEST] <BBB> rows are different than cols in dependency handling
[15:52:43 CEST] <BBB> so threading for cols is more independent than rows
[15:55:33 CEST] <J_Darnley> atomnuker: So kierank has asked me to add sliced threading to the VC-2 encoder.  Do you have any suggestions on where to start?
[15:57:02 CEST] <atomnuker> J_Darnley: start with small 128x128 yuv444p samples, set -slice_width 128 and -slice_height 128
[16:01:45 CEST] <atomnuker> that way you can reorder stuff knowing quickly whether it works
[16:01:53 CEST] <atomnuker> also -wavelet_depth 1
[16:02:12 CEST] <atomnuker> then add support for multiple wavelet levels
[16:02:19 CEST] <atomnuker> then add support for more than 1 slice
[16:03:06 CEST] <atomnuker> for now bodge the function which calculates slice sizes to output the worst case scenario
[16:03:45 CEST] <J_Darnley> kierank said I should forget about rate control and just use const quant.
[16:04:18 CEST] <J_Darnley> I guess bodging would have a similar effect
[16:04:39 CEST] <atomnuker> if you have a constant quant you'll still need to calculate the worst case scenario
[16:04:58 CEST] <atomnuker> (its one and the same, of course you need to fix the quantizer)
[16:05:26 CEST] <atomnuker> and do keep in mind the worst case scenario in dirac is very very bad in terms of size
[16:06:17 CEST] <atomnuker> and even the best scenario with a high quantizer will still give you a grey output and a large amount of bits spent encoding just gray
[16:07:31 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:449cdfa687f7: avcodec/ffv1: Increase the maximum number of slices to 1024
[16:07:32 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:4147bb905346: avcodec/ffv1enc: Try to choose slice count so that slice packet sizes are within the supported size
[16:07:33 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:ea5366670e26: avcodec/jpeg2000dwt: Fix integer overflow in dwt_decode97_int()
[16:07:34 CEST] <cone-442> ffmpeg 03Michael Niedermayer 07master:3c7025178064: avcodec/jpeg2000dwt: Fix integer overflows in sr_1d97_int()
[16:31:04 CEST] <atomnuker> durandal_1707: which decoder do you plan on leaving?
[16:32:00 CEST] <JEEB> ffmpeg Paul B Mahol master:915be7e13a0e: avcodec/proresenc_kostya: enable frame threading <- based on this the kostya one?
[16:32:24 CEST] <JEEB> because I'd be surprised if he improved an encoder if he was going to drop it
[16:32:27 CEST] <JEEB> &32
[16:32:38 CEST] <kierank> atomnuker: constant quant to experiment
[16:32:48 CEST] <kierank> J_Darnley: no it's not slice threading
[16:33:25 CEST] <atomnuker> JEEB: I said decoder, not encoder
[16:33:38 CEST] <kierank> J_Darnley: it's slice-by-slice encoding
[16:34:11 CEST] <BBB> durandal_1707: \o/
[16:35:40 CEST] <JEEB> atomnuker: ah right
[16:35:47 CEST] <JEEB> didn't remember we had multiple *decoders*
[16:36:04 CEST] <BBB> we should get rid of the gpl one
[16:36:07 CEST] <BBB> this is so ridiculous
[16:36:15 CEST] <BBB> arent they both the same anyway?
[16:36:29 CEST] <BBB> (or maybe theyre now both lgpl; still, get rid of the one that is not in libav)
[16:46:02 CEST] <JEEB> 734
[16:50:05 CEST] <durandal_1707> BBB: libav one is slightly slower
[16:50:34 CEST] <BBB> then delete the other
[16:50:42 CEST] <cone-442> ffmpeg 03Kyle Swanson 07master:c11ca6105e69: avcodec/g722enc: force mono channel layout
[16:51:30 CEST] <durandal_1707> BBB: but the other one is less nice looking code
[16:51:36 CEST] <BBB> are you plannign to address decoder duplication also?
[16:51:49 CEST] <durandal_1707> will try
[16:52:06 CEST] <BBB> \o/
[16:52:08 CEST] <BBB> hero
[16:53:00 CEST] <atomnuker> durandal_1707: here performance > code quality, this isn't some hypercomplicated codec, its jpeg, you can always fix code if you don't like it
[16:54:58 CEST] <kierank> it's an encoder
[16:55:03 CEST] <kierank> surely the best quality is best
[16:58:49 CEST] <atomnuker> DEcoder
[16:59:04 CEST] <atomnuker> both decoders are lgpl
[17:13:23 CEST] <durandal_1707> the elvis one was initially gpl for some reason
[17:41:20 CEST] <BBB> hehe the sizeof_mismatch isnt doing its job in coverity
[17:55:04 CEST] <ubitux> durandal_1707: feel free to update the "Collateral damage" section in doc/libav-merge.txt
[17:55:13 CEST] <ubitux> (when you're done)
[17:56:26 CEST] <durandal_1707> only when kierank posts dolby-e decoder
[18:04:47 CEST] <durandal_1707> kierank: could you at least improve dolby-e description in wiki?
[19:44:33 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:e9510dc03284: avfilter: remove usage of empty header
[19:52:20 CEST] <JEEB> durandal_1707: cool stuff with utvideodec
[19:52:29 CEST] <JEEB> funny how everyone forgot aboug planar RGB
[19:52:50 CEST] <JEEB> even though, indeed, that is the native format
[19:53:29 CEST] <BBB> did that exist when the native decoder was written?
[19:53:41 CEST] <BBB> (planar rgb pix_fmt)
[19:54:00 CEST] <JEEB> I don't exactly remember
[19:54:10 CEST] <JEEB> I think it was circa 2011 or so
[19:54:37 CEST] <JEEB> I then started poking around the encoder in 2012, and I even was a hard-headed SIMD "student" for you at one point :)
[19:54:51 CEST] <BBB> oct 2011
[19:56:47 CEST] <BBB> aaaa
[19:56:48 CEST] <BBB> and
[19:56:53 CEST] <BBB> I added planar RGB (really!)
[19:56:54 CEST] <BBB> in nov 2011
[19:56:55 CEST] <BBB> bd97b2e1ce713a4886d909f71b6f1f5403446f53
[19:57:07 CEST] <BBB> I dont even remember that
[19:57:18 CEST] <JEEB> :D
[19:57:20 CEST] <BBB> so yes, it wasnt around back then ;)
[19:57:30 CEST] <JEEB> just like I don't remember adding high bit depth y4m into x264cli
[19:57:47 CEST] <BBB> hbd y4m is a hack anyway :-p the original y4m software doesnt support it
[19:57:53 CEST] <JEEB> true that
[19:57:59 CEST] <JEEB> but it was simpler than adding NUT
[19:58:13 CEST] <JEEB> and FFmpeg already supported it
[19:58:17 CEST] <BBB> indeed
[19:58:28 CEST] <BBB> wasnt that the point of y4m? to be an interop format between different tools?
[19:58:38 CEST] <BBB> I thought it originated in mjpegtools but maybe Im way off
[19:58:45 CEST] <JEEB> yea, it originated around there
[19:59:52 CEST] <BBB> (I originate from mjpegtools also :-p)
[20:00:05 CEST] <wm4> BBB is deprecated!
[20:00:14 CEST] <BBB> its about time
[20:00:35 CEST] <BBB> /shutdown -h now
[20:04:44 CEST] <BBB> is anyone here attending VDD?
[20:04:46 CEST] <BBB> err
[20:04:47 CEST] <BBB> I mean
[20:04:48 CEST] <BBB> demuxed
[20:06:02 CEST] <Compn> what country is demuxed in ?
[20:06:09 CEST] <BBB> us, san fransisco
[20:06:29 CEST] <Compn> october 5th
[20:07:03 CEST] <wm4> lol traveling to the US
[20:07:18 CEST] <kierank> BBB: if my submission is accepted
[20:08:07 CEST] <JEEB> wm4: no laptops and reset your phone before you go
[20:08:15 CEST] <BBB> Im wondering if I should talk about stuff
[20:08:38 CEST] <JEEB> wm4: actually this seems to be pretty solid advice https://mricon.com/i/travel-laptop-setup.html
[20:08:47 CEST] <JEEB> even if not going to china
[20:09:00 CEST] <Compn> bring usb drive? then just buy cheap netbook when you get to the states ?
[20:09:15 CEST] <JEEB> Compn: or bring over a basic laptop with a pure install that isn't encrypted
[20:09:21 CEST] <BBB> the easiest solution is to live in the US
[20:09:22 CEST] <JEEB> just so you can boot it up and connect to wifi
[20:09:26 CEST] <BBB> then you dont have to worry about bring stuff in
[20:09:37 CEST] <JEEB> I would probably never fit into the US
[20:09:46 CEST] <nevcairiel> BBB: as long as you never leave =p
[20:09:49 CEST] <JEEB> I like government help and pay 40% taxes
[20:10:02 CEST] <BBB> JEEB: depends on the state
[20:10:29 CEST] <kierank> JEEB: yes but you don't have a space programme
[20:10:33 CEST] <kierank> which is the best part of usa
[20:10:45 CEST] <JEEB> yes, and I like the fact that the private enterprises are doing that now
[20:10:48 CEST] <wm4> doesn't russia have a better one
[20:10:49 CEST] <JEEB> I mean, not lockheed etc
[20:10:53 CEST] <nevcairiel> at this state i dont even want to visit the US, never mind living there
[20:11:25 CEST] <Compn> now would probably be a good time to visit
[20:11:32 CEST] <Compn> as long as you arent muslim...
[20:17:15 CEST] <BBB> kierank: what are you talking about again?
[20:17:25 CEST] <kierank> Uncompressed video over IP
[20:17:53 CEST] <kierank> and the simd & zero copy stuff around that
[20:48:02 CEST] <kierank> JEEB: any idea who filler56789 is?
[20:48:23 CEST] <JEEB> nope
[20:49:12 CEST] <nevcairiel> i've seen the name around doom9 in places
[20:59:05 CEST] <TD-Linux> nevcairiel, speaking of, do you know how I can get my posts on doom9 approved?
[21:02:40 CEST] <JEEB> TD-Linux: huh, yours are still in mod queue?
[21:08:50 CEST] <TD-Linux> JEEB, yes
[21:09:24 CEST] <shincodex> "buffer_size",        "Send/Receive buffer size (in bytes)",   
[21:09:31 CEST] <shincodex> but this only applies to udp
[21:09:32 CEST] <shincodex> yet
[21:09:39 CEST] <shincodex> the wording is lies
[21:09:46 CEST] <shincodex> "buffer_size",        "Underlying protocol send/receive buffer size", 
[21:09:56 CEST] <shincodex> the rtsp buffer_size does not control
[21:10:12 CEST] <shincodex> "send_buffer_size",
[21:10:13 CEST] <shincodex> for tcp
[21:10:15 CEST] <shincodex> why?
[21:21:22 CEST] <BBB> I dont know. do you want it to?
[21:29:15 CEST] <shincodex> hmmm
[21:29:34 CEST] <shincodex> better business bureau?
[21:33:28 CEST] <kierank> lol
[22:04:15 CEST] <BBB> still waiting for j_darnleys glorious push
[22:04:17 CEST] <BBB> where is it?
[22:05:58 CEST] <feliwir> hey, how do i synchronise two seperate files with libav for playback? E.g. i have a video file (vp6) and an audio file that is the audiostream for that video (mp3)
[22:09:41 CEST] <shincodex> So
[22:09:51 CEST] <shincodex> send_buffer_size or recv_buffer_size
[22:09:58 CEST] <shincodex> are in options list but are ignored for tcp.c
[22:10:05 CEST] <shincodex> does that sound right to you?
[22:10:39 CEST] <shincodex> coming from RTSP
[22:12:05 CEST] <BBB> feliwir: https://ffmpeg.org/faq.html#How-can-I-join-video-files_003f
[22:12:17 CEST] <BBB> feliwir: and I think this probably belongs in #ffmpeg, not here
[22:12:36 CEST] <BBB> shincodex: like I just said, not necessarily. if youd like it to be different, submit a patch? :)
[22:12:57 CEST] <shincodex> Why is it like a giant guess with this whole framework
[22:13:10 CEST] <shincodex> I really wish i was just using it wrong
[22:13:31 CEST] <shincodex> 	sprintf(tempBuff, "%lld", tcpOptions.sendBufferSize); 	av_dict_set(&options, "send_buffer_size", tempBuff, 0);
[22:13:35 CEST] <shincodex> 	int err = avformat_open_input(&formatContext, openPath.c_str(), inputFormat, &options);
[22:13:38 CEST] <shincodex> its in there somewhere
[22:17:38 CEST] <shincodex> oh... this really might be unfinished code
[22:24:56 CEST] <feliwir> BBB, i want to do it in libav
[22:24:56 CEST] <feliwir> not ffmpeg
[22:25:21 CEST] <BBB> maybe ask in #libav-devel then or so?
[22:26:01 CEST] <rcombs> I'm in London; anybody wanna hang out?
[22:26:41 CEST] <rcombs> kierank?
[22:26:57 CEST] <wm4> BBB: I think he means via the ffmpeg libraries and C API
[22:27:08 CEST] <BBB> oh I see
[22:27:15 CEST] <BBB> feliwir: you mean libavcodec/format etc.?
[22:27:52 CEST] <kierank> rcombs: where in london
[22:28:29 CEST] <kierank> If you are near the river I might end up seeing you anyhow
[22:28:50 CEST] <rcombs> Holland Park Station
[22:29:04 CEST] <rcombs> I'll be around until Friday
[22:29:44 CEST] Action: kierank is running round the thames
[22:30:14 CEST] <wm4> why are you in Britain anyway?
[22:30:53 CEST] <kierank> Place to be
[22:31:13 CEST] <rcombs> vacation
[22:32:16 CEST] <wm4> strange choice
[23:14:23 CEST] <atomnuker> iive: I'll do the tests in an hour or so, haven't forgotten
[23:21:30 CEST] <iive> np
[23:29:13 CEST] <BtbN> Why does the ocr filter have no way to dump out what it's recognizing? Getting out the frame metadata is hard.
[23:29:24 CEST] <BtbN> I ended up just hacking file dumping into there
[23:36:17 CEST] <rcombs> BtbN: because lavfi doesn't do subtitles yet
[23:36:29 CEST] <BtbN> I don't want it as subtitle
[23:36:36 CEST] <BtbN> I just want it as plain text
[23:36:56 CEST] <BtbN> just log it for all I care, I can grep that out of the output
[23:38:05 CEST] <BtbN> I just put something in that fopens a file, and writes every scanned line into a text file
[23:38:21 CEST] <BtbN> it works surprisingly well
[23:40:47 CEST] Action: wm4 can't wait for the trainwreck that will be subtitles
[23:40:52 CEST] <wm4> it can barely do audio/video
[23:41:35 CEST] <cone-442> ffmpeg 03Paul B Mahol 07master:3594788b713e: avcodec/utvideodec: decode to GBR(A)P
[23:45:50 CEST] <BtbN> Well, I want it to parse a 140x60 image for a 2 or 3 digit number. It does that reliably.
[00:00:00 CEST] --- Tue Jun 27 2017