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

[burek]

[01:53:44 CEST] <Timothy_Gu> Any more comments on https://patchwork.ffmpeg.org/project/ffmpeg/list/?submitter=17 ?
[09:51:48 CEST] <durandal_1707> michaelni: does dsmudhar have commit rights?
[10:42:23 CEST] <michaelni> durandal_1707, ive offered access as he is in MAINTAINERs, so probably soon but not yet
[11:11:59 CEST] <durandal_1707> then I gonna apply that minterpolate patch
[11:39:21 CEST] <durandal_1707> the one that fixes segv
[12:41:29 CEST] <wm4> mateo`: I think the mediacodec wrapper should convert timestamps to the correct unit using pkt_timebase
[13:12:21 CEST] <mateo`_> wm4: it still does if pkt_timebase is set
[13:12:48 CEST] <wm4> then I overlooked that
[13:15:12 CEST] <michaelni> durandal_1707, the green line one ? thats ok to apply but i think it didt apply cleanly without the other
[14:54:41 CEST] <durandal_1707> recursive lavfi calls are killing me, how is this able to work at all?
[15:02:41 CEST] <kierank> are there any full framerate deinterlacers faster than yadif
[15:02:44 CEST] <kierank> quality doesn't matter
[15:04:39 CEST] <j-b> BoB?
[15:08:20 CEST] <nevcairiel> w3fdif is faster, at least on 64-bit with full assembly
[15:09:59 CEST] <durandal_1707> it have slice threads too
[15:11:09 CEST] <durandal_1707> What is bob , just dupeing lines?
[15:11:10 CEST] <kierank> maybe bob yes
[15:11:27 CEST] <bencoh> 66
[15:11:29 CEST] <bencoh> woops
[15:11:48 CEST] <durandal_1707> Or use bilinear resize?
[15:13:45 CEST] <durandal_1707> michaelni: adding frame threading inside filter is much much much easier, don't you agree?
[15:15:14 CEST] <kierank> durandal_1707: probably going to do bilinear resize on both fields
[15:21:27 CEST] <michaelni> durandal_1707, i didnt try to implement either so i dont really know which is easier
[15:23:17 CEST] <cone-058> ffmpeg 03Steven Liu 07master:557ad3a4745c: avformat/hlsenc: add option hls_init_time to set init hls window segment duration
[15:23:17 CEST] <cone-058> ffmpeg 03Steven Liu 07master:7ba98824a948: doc/muxers: add option hls_init_time document
[15:28:06 CEST] <durandal_1707> michaelni: is my patchset to add finer control to lavfi slice threading, ok?
[15:30:32 CEST] <michaelni> durandal_1707, yes i think they are ok
[15:38:44 CEST] <BtbN> So, AV_PIX_FMT_P010 is NV12 for 10bit?
[15:41:45 CEST] <wm4> yes
[15:42:23 CEST] <BtbN> So there is no conversion to that in sws, hm
[15:44:20 CEST] <durandal_1707> So I must bump minor, when adding new field to AVFilterContext?
[15:44:41 CEST] <BtbN> yes. And only add them at the end.
[15:57:55 CEST] <BtbN> Does sws even support outputting 10bit formats? oO
[15:58:14 CEST] <JEEB> yes
[15:58:24 CEST] <JEEB> although I recommend you poke those things with zscale
[15:58:26 CEST] <BtbN> So there just isn't a single 10bit output format implemented yet
[15:58:40 CEST] <JEEB> huh
[15:58:51 CEST] <JEEB> it can do yuv420p10 to yuv420p just fine
[15:58:55 CEST] <JEEB> among other things
[15:58:55 CEST] <BtbN> Right now 10bit encoding with nvenc fails, because sws can't convert to that format
[15:59:02 CEST] <BtbN> that's 8bit output though
[15:59:08 CEST] <JEEB> yes, and it can do it the other way :P
[15:59:15 CEST] <JEEB> it probably only lacks a conversion to P010
[16:00:07 CEST] <BtbN> There is no notion of YUV420P10 in output.c
[16:00:29 CEST] <JEEB> no idea, it Just Works if you try it with, say, 10bit libx264 :P
[16:00:44 CEST] <BtbN> are you sure it's not just passing it through untouched?
[16:06:07 CEST] <BtbN> So looks like sws can only output YUV420P10 if it's not scaling.
[16:07:32 CEST] <nevcairiel> sws can output a variety of 10-bit formats, it just cant output p010
[16:07:52 CEST] <BtbN> But only in unscaled-mode from what it looks like.
[16:07:57 CEST] <nevcairiel> no
[16:08:04 CEST] <BtbN> Then I have no idea how and where it does it
[16:08:10 CEST] <BtbN> cause in output.c they are not listed
[16:08:12 CEST] <nevcairiel> is it important? :)
[16:08:24 CEST] <BtbN> well, I'd like to add P010
[16:08:26 CEST] <nevcairiel> utils.c format_entries lists all supported conversions
[16:08:32 CEST] <nevcairiel> the first 1 is for input, the second for output
[16:08:42 CEST] <nevcairiel> all of those work wit heverything
[16:08:55 CEST] <nevcairiel> and no you don'Ät
[16:08:58 CEST] <nevcairiel> don't
[16:09:05 CEST] <nevcairiel> sws output code is crazy ass magic
[16:09:10 CEST] <nevcairiel> guess why it wasnt added =p
[16:10:18 CEST] <nevcairiel> many of the base yuv4xxpxx formats are  handled by rather generic code
[16:10:23 CEST] <nevcairiel> all thats listed is probably more special cases
[16:10:26 CEST] <BtbN> But where does it do the YUV420P10BE output? Or is there no output function for it, as it's the native internal format that needs no conversion
[16:11:05 CEST] <BtbN> So I'll just set P010 to supported output in that format_entires list, and see where it explodes
[16:11:31 CEST] <BtbN> probably in the output.c function for it, where it then needs something to convert the planes, but that code is weird
[16:11:35 CEST] <nevcairiel> i'm not sure why you insist on going after yuv420p10be, and why be of all things, p010 is le =p
[16:11:44 CEST] <BtbN> Hm?
[16:11:52 CEST] <BtbN> I'm going after P010 for nvenc.
[16:12:02 CEST] <nevcairiel> should rather look for nv12 because its a half-packed format of the same base layout, and how thats handled
[16:12:12 CEST] <nevcairiel> and just make it do the same in 10-bit
[16:12:17 CEST] <BtbN> I was looking for some other 10 bit format, wondering why it works.
[16:12:34 CEST] <nevcairiel> like i said, all the planar formats probably use a rather generic function that handles all of them
[16:12:41 CEST] <BtbN> But YUV420P(10) is probably the native internal format, so no conversion is needed.
[16:12:55 CEST] <BtbN> They are not even handled in the output switchcase
[16:13:09 CEST] <durandal_1707> is there reason why filter-complex doesn't set number of graph threads?
[16:13:50 CEST] <nevcairiel> BtbN: of course they are
[16:14:18 CEST] <nevcairiel> they use yuv2planeX_10LE_c etc
[16:14:22 CEST] <nevcairiel> ie. the generic case
[16:14:42 CEST] <BtbN> yes, but that's not in the switchcase, but in front of it.
[16:14:55 CEST] <nevcairiel> well same difference
[16:15:07 CEST] <nevcairiel> no reason to override it if it works for the majority of formats
[16:16:00 CEST] <kierank> 3:10 PM <"nevcairiel> many of the base yuv4xxpxx formats are  handled by rather generic code
[16:16:00 CEST] <kierank> 3:10 PM <"nevcairiel> all thats listed is probably more special cases
[16:16:00 CEST] <kierank> yes
[16:16:41 CEST] <nevcairiel> anyway when i added p010 input support to sws i looked what output might need, and i decided its too scary to bother, since i have no interest in it
[16:16:53 CEST] <nevcairiel> sws input is trivial in comparison to output =p
[16:17:06 CEST] <BtbN> it shouldn't be too hard to add just P010BE/LE output.
[16:17:21 CEST] <BtbN> I don't think even BE is needed, but might as well add it.
[16:17:41 CEST] <nevcairiel> you would think so, but then again sws
[16:18:05 CEST] <JEEB> iä iä swscale f'thagn
[16:18:08 CEST] <kierank> what's P010 again?
[16:18:13 CEST] <BtbN> 10bit NV12
[16:18:14 CEST] <kierank> yuv422p16 with LSBS?
[16:18:14 CEST] <JEEB> NV12 with 10bit
[16:18:15 CEST] <kierank> oh
[16:18:23 CEST] <JEEB> and yes LSBS
[16:18:41 CEST] <JEEB> DXVA2 10bit is defined to be it
[16:18:47 CEST] <kierank> oh well you get what you deserve with LSBs :)
[16:19:08 CEST] <BtbN> nvenc also uses it as input format, and if they ever add 10bit to vdpau/cuvid, it will be that.
[16:19:11 CEST] <nevcairiel> thats really the annoying part of it, that it puts the bits at the other end as any of the internal formats
[16:19:36 CEST] <BtbN> it does?
[16:20:31 CEST] <nevcairiel> YUV420P10 is "000000XXXXXXXXXX", while P010 is "XXXXXXXXXX000000"
[16:20:48 CEST] <nevcairiel> assuming a 16-bit wrapper for both, of course
[16:21:19 CEST] <BtbN>  /**< 10 bit Semi-Planar YUV [Y plane followed by interleaved UV plane]. Each pixel of size 2 bytes. Most Significant 10 bits contain pixel data. */
[16:21:20 CEST] <BtbN> from nvenc
[16:21:29 CEST] <BtbN> so yeah, at least it matches in that regard
[16:21:34 CEST] <nevcairiel> yeah, in the most significant bits
[16:21:39 CEST] <nevcairiel> but thats not what the other formats we have do
[16:21:54 CEST] <BtbN> would have been annoying if it expected in in the LSB
[16:33:05 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:449339084fb2: avfilter: add nb_threads to AVFilterContext
[16:33:06 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:5b1907142dca: avfilter: add ff_filter_get_nb_threads()
[16:33:07 CEST] <cone-058> ffmpeg 03Paul B Mahol 07master:a0a57072c93b: avfilter: make use of ff_filter_get_nb_threads
[16:49:31 CEST] <BtbN> kierank, nevcairiel you happen to know if I can just copy the dither-logic from nv12?
[16:52:35 CEST] <BtbN> looks like nv12 is the only output format that applies dithering at all, or am I missing somthing again?
[16:52:53 CEST] <BtbN> at least using the chrDither8 variable
[16:53:24 CEST] <BtbN> ah, no. It's passed as argument, nevermind
[17:33:48 CEST] <cone-058> ffmpeg 03Davinder Singh 07master:11a631d4a768: avfilter/vf_minterpolate: do not right shift negative numbers
[17:41:45 CEST] <BtbN> so, this should be it: https://gist.github.com/14cd93969c084c303f127436388aaab3
[17:41:49 CEST] <BtbN> haven't tested it yet
[17:42:33 CEST] <BtbN> I wonder what happens if the filter size is 0 though. It just returns 0 values for everything?
[19:10:56 CEST] <BtbN> now I have to somehow verify if the P010 scaler works.
[19:12:21 CEST] <nevcairiel> fate should test that, i think
[19:12:39 CEST] <nevcairiel> but your earlier snippet probably lacked something to deal with luma
[19:15:18 CEST] <BtbN> oh right, luma also needs to be shiftes left by 6 bits...
[19:15:48 CEST] <BtbN> I don't think fate tests P010 output, as it didn't exist before?
[19:16:11 CEST] <BtbN> It should definitely start doing it now though
[19:28:56 CEST] <nevcairiel> It should automatically test any formats that have in and out support, I think
[19:33:11 CEST] <jamrial> nevcairiel: doesn't look like. none of the pixdesc filters test p010, only nv12
[19:33:44 CEST] <jamrial> pixfmts rather
[19:34:56 CEST] <nevcairiel> tests/pixfmts.mak is generated, it should include p010 if sws declares in/out support
[19:35:16 CEST] <nevcairiel> delete it and let fate remake it
[19:35:17 CEST] <jamrial> it only declares in
[19:35:37 CEST] <jamrial> ./ffmpeg -pix_fmts list | grep p010 -> I.... p010[lb]e
[19:35:38 CEST] <nevcairiel> yes, but thats what BtbN is trying to fix =p
[19:36:06 CEST] <jamrial> ah. i shall go back under my rock then :p
[19:36:33 CEST] <nevcairiel> as far as i know it tries to do a reversible conversion or something, so it might catch mismatches between in/out conversion
[19:36:37 CEST] <nevcairiel> at least that would be useful
[19:36:40 CEST] <nevcairiel> so maybe not
[19:36:40 CEST] <nevcairiel> :D
[19:37:35 CEST] <nevcairiel> anyway easy enough to just write raw yuv frames and read them back in manually
[19:58:31 CEST] <kierank> is there anything faster than bilinear (fewer taps please) in swscale
[20:01:20 CEST] <nevcairiel> point?
[20:03:31 CEST] <kierank> ah point = nearest neighbour
[20:03:52 CEST] <kierank> oh it's not
[20:04:00 CEST] <nevcairiel> i thought it would be
[20:04:02 CEST] <kierank> oh it is
[20:04:07 CEST] <kierank> meh confusing names are confusing
[20:05:46 CEST] <ubitux> there is "fast bilinear"
[20:10:50 CEST] <durandal_1707> and how would that be faster than w3fdif simple?
[20:12:36 CEST] <kierank> durandal_1707: eh?
[20:14:42 CEST] <durandal_1707> kierank: aren't you making bob deinterlacer?
[20:15:33 CEST] <kierank> avoiding libavfilter means I can render straight into hardware memory
[20:19:44 CEST] <durandal_1707> yes, but nobody told you to use lavfi :D
[20:28:43 CEST] <omerjerk> is there a place where the ffmpeg-devel mailing lists emails could be found?
[20:28:55 CEST] <omerjerk> like we have lkml.org for linu
[20:28:58 CEST] <omerjerk> *linux
[20:30:57 CEST] <JEEB> omerjerk: https://ffmpeg.org/pipermail/ffmpeg-devel/
[20:31:55 CEST] <omerjerk> thanks a lot
[20:41:19 CEST] <BtbN> how do I run just that one fate test?
[20:42:01 CEST] <JEEB> make fate-TEST
[20:42:19 CEST] <BtbN> but which one is the pixfmts copy back and fourth test?
[20:46:14 CEST] <jamrial> BtbN: fate-filter-pixdesc and fate-filter-pixfmts
[20:48:08 CEST] <BtbN> hm, they only output one hash though
[20:57:42 CEST] <BtbN> hm, something seems to go wrong with the Y part of it
[20:58:24 CEST] <BtbN> at least white is missing from the result of testsrc -> p010le -> raw file -> png
[21:19:45 CEST] <BtbN> Am I missing something about the Y plane? Shouldn't it just be identical to a normal one, except for a << 6?
[21:46:59 CEST] <BtbN> I don't understand this function: https://github.com/FFmpeg/FFmpeg/blob/master/libswscale/output.c#L193
[21:47:15 CEST] <BtbN> won't it, for 10 bits, just shift out 5 bits of the 10 bits?
[22:13:03 CEST] <BtbN> ok, this is confusing. p010be works fine
[22:13:07 CEST] <BtbN> it's only p010le that fails
[22:18:26 CEST] <BtbN> http://imgur.com/a/lCJim this is the luma plane missing, or is something else wrong there? Also, the very last line does have it
[22:32:11 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:adbf1c905447: avutil/version: Mention similarities and differences to semver
[22:33:53 CEST] <BtbN> There is something strange going on there. The conversion is definitely working correctly. It's just that the luma conversion function isn't called more than once.
[22:48:15 CEST] <BtbN> Oh... it's overriding the conversion function with some assembley one.
[22:48:21 CEST] <BtbN> Well that explains it
[22:49:53 CEST] <cone-427> ffmpeg 03Michael Niedermayer 07master:ac028794ad70: avutil/version: Improve lib versioning scheme for release branches with the next major release
[23:09:12 CEST] <BtbN> Ok, works now.
[23:09:30 CEST] <BtbN> Doing a "full" fate run (without samples) on it now.
[23:32:31 CEST] <BtbN> Is it only me or is the ffmpeg-devel list very slow recently?
[23:33:09 CEST] <bofh_> out of curiosity, why does alsdec do floating-point decoding via IEEE754 softfloats instead of just using, like, native IEEE754 floats?
[23:50:25 CEST] <Compn> BtbN : slow as in lack of emails? yes
[23:50:30 CEST] <Compn> probably summer vacation for many 
[23:50:39 CEST] <Compn> or just nice weather
[00:00:00 CEST] --- Tue Aug 30 2016