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

[burek]

[00:03:00 CEST] <philipl> BtbN: victory. I have cuda copying working in mpv
[01:31:40 CEST] <cone-498> ffmpeg 03Paul B Mahol 07master:496d97f46501: avfilter/vf_owdenoise: hight bit-depth support
[01:56:56 CEST] <BBB> the problem is that if you move avformatcontext to codecpar, you might just as well rename it back to avformatcontext
[01:57:00 CEST] <BBB> please keep codecpar clean
[01:57:05 CEST] <BBB> that was the whole point, right?
[01:57:07 CEST] <BBB> </late>
[02:00:15 CEST] <BBB> I also really feel you guys would have benefitted from attending VDD, there were only a few ffmpeg people, very sad to see our attendance rate dropped so much compared to last year
[02:00:31 CEST] <BBB> you - all of you, all of you - should come again next year
[02:02:10 CEST] <rcombs> BBB: still wtb a way to export arbitrary bitstream properties from an AVCodec in find_stream_info; maybe just an AVDict
[02:12:28 CEST] <BBB> if they are truly random and endless, than maybe AVDict is the way to go
[02:12:57 CEST] <DHE> conversely, shouldn't there be some standardization whenever possible?
[02:13:00 CEST] <BBB> adding 100 fields to codecpar seems suboptimal, because it doesnt solve the problem (or, worse, introduces the problem) of having 100 fields, most of whihc are unused in most cases, but no indication of when they are used or not
[02:13:18 CEST] <BBB> introspection ftw
[03:24:30 CEST] <kode54> lovely
[03:24:42 CEST] <kode54> found a new toy for some clever developers to figure out
[03:24:45 CEST] <kode54> [AVIOContext @ 0x7feaed400860] unknown subformat:d242e147ba368d4d88fc61654f8c836c {47e142d2-36ba-4d8d-88fc-61654f8c836c}
[03:24:52 CEST] <kode54> ATRAC9
[03:35:26 CEST] <kode54> funny Sony
[03:35:44 CEST] <kode54> they don't even let game software vendors like FMOD include their technology in their software
[03:36:06 CEST] <kode54> users of the software must acquire libatrac9.dll from the Sony platform SDK and toss it into the FMOD software
[04:37:49 CEST] <bp0> can someone point to an example use of read-only/export AVOptions?
[10:50:00 CEST] <DHE> ... you know someone's desperate when: the bounty goes up 33%  (re ticket 5818)
[10:51:19 CEST] <BtbN> I'm quite sure encoding interlaced with NVENC works just fine as it is...?
[10:51:21 CEST] <jkqxz> You know someone's desperate when they are trying to encode interlaced video in 2016.
[10:51:41 CEST] <DHE> unfortunately broadcast standard is still either 1080i or 720p
[10:52:51 CEST] <DHE> I just grabbed a copy of the nvidia PDF for their API and it doesn't explicitly state how to specify interlaced content is being processed...
[10:54:20 CEST] <nevcairiel> didnt someone try interlaced in nvenc and the output just wasnt "right" (on top of being interlaced, which some people might consider wrong :p)
[10:54:32 CEST] <BtbN> I did try it
[10:54:54 CEST] <BtbN> And it just seemed to be completely unimpressed by me trying to set interlaced encoding
[10:55:08 CEST] <BtbN> So it continued as if nothing the like ever happened
[10:55:12 CEST] <DHE> if done properly, ffprobe -show_frames on the output should indicate the content as being interlaced on top of the output looking properly
[10:55:23 CEST] <DHE> well, as proper as interlacing looks
[10:55:33 CEST] <BtbN> I'll look into it again, now that I have a Pascal card at hand
[10:55:45 CEST] <BtbN> I only had the very first nvenc generation before. So something might have changed
[11:04:47 CEST] <BtbN> I still wonder what it possibly means with "Interlaced field mode encoding is supported" vs. "Interlaced frame encoding and field mode encoding are both supported"
[11:15:16 CEST] <ubitux> CFHDContext.wavelet_depth doesn't look to be in use, or am i mistaken?
[11:15:29 CEST] <ubitux> is it really a wavelet (exclusive) codec?
[11:15:32 CEST] <ubitux> atomnuker ^
[11:15:44 CEST] <BtbN> DHE, where does ffprobe read that interlaced_frame information from? straight from the h264 NAL? Or some container? Does the encoder have to export some information about it encoding in interlaced mode? Can't find anything like that in libx264
[11:16:09 CEST] <ubitux> (same for lowpass_precision)
[11:29:14 CEST] <ubitux> durandal_1707: did you test your palette{gen,use} patch for encoding gifs?
[11:30:02 CEST] <durandal_1707> ubitux: nope, something wrong?
[11:31:21 CEST] <ubitux> i don't remember if the encoder is ready to deal with this (if palette changes, it probably can't use pixel transparency for instance, and if it does it will lead to issues)
[11:31:28 CEST] <ubitux> how did you test it?
[11:31:55 CEST] <ubitux> iirc the issue was that it was causing general lighting effect
[11:32:06 CEST] <ubitux> i'm going to test with gif but i'm curious how you tried
[11:32:59 CEST] <durandal_1707> that is irrelevant if one need single image output
[11:34:13 CEST] <ubitux> but in single mode, a full histogram would work?
[11:44:59 CEST] <BtbN> nvenc in forced interlace mode produces very broken output
[11:45:36 CEST] <ubitux> durandal_1707: do we have a filter to sync frames?
[11:45:45 CEST] <ubitux> i mean, sync 2 streams by frames
[11:45:54 CEST] <durandal_1707> sync what?
[11:46:52 CEST] <durandal_1707> How is that possible?
[11:46:56 CEST] <BtbN> https://btbn.de/images/test/out_nvenc.mkv anyone got an idea what might be going wrong here?
[11:48:07 CEST] <ubitux> durandal_1707: "[v1][v2] framesync", v2frame->pts = v1frame->pts
[11:48:23 CEST] <ubitux> but anyway, it doesn't seem to be my issue
[11:52:16 CEST] <ubitux> durandal_1707: colors seem fucked, http://b.pkh.me/ffgif-single-mode.gif
[11:52:22 CEST] <ubitux> but that might be a bug in the encoder
[11:52:31 CEST] <cone-108> ffmpeg 03Carl Eugen Hoyos 07master:70f4b453cba0: doc/showspectrum*: Change options order to reflect numeric values.
[11:52:34 CEST] <durandal_1707> BtbN: lt is interlaced?
[11:52:44 CEST] <BtbN> according to ffprobe it is
[11:54:04 CEST] <ubitux> ah wait my bad
[11:55:51 CEST] <ubitux> http://b.pkh.me/ffgif.gif vs http://b.pkh.me/ffgif-single-mode.gif
[11:55:51 CEST] <durandal_1707> ubitux: I tested it all in single graph
[11:55:53 CEST] <ubitux> nit bad
[11:55:55 CEST] <ubitux> not bad
[11:56:09 CEST] <ubitux> 23M vs 38M though
[11:56:15 CEST] <ubitux> but that's interesting
[11:56:51 CEST] <durandal_1707> isnt that reasonable?
[11:57:06 CEST] <ubitux> output LGTM
[11:57:22 CEST] <ubitux> i tried ./ffmpeg -ss 20 -i ~/samples/GoneNutty.avi -t 10 -vf "split=2[ref][copy]; [copy]palettegen=stats_mode=single[pal]; [ref][pal]paletteuse=new=true" -y ffgif-single-mode.gif
[11:57:32 CEST] <ubitux> vs a simple 2 pass
[11:57:47 CEST] <ubitux> there are black glitches though
[11:59:20 CEST] <rcombs> oh is this something to generate per-frame palettes instead of a single global one?
[11:59:30 CEST] <ubitux> yes
[11:59:41 CEST] <ubitux> but i think the encoder doesn't deal with it properly
[12:00:09 CEST] <ubitux> the glitches need to be fixed ideally
[12:01:40 CEST] <ubitux> http://b.pkh.me/2016-09-06-120202_640x352_scrot.png
[12:01:42 CEST] <ubitux> these ^
[12:29:33 CEST] <durandal_1707> ubitux: bug in gif encoder
[12:31:56 CEST] <ubitux> that's unfortunate
[12:40:33 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:3a3265899b86: avfilter/af_amix: make independent of the channel layout
[12:40:34 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:db3b93319dc8: avfilter/af_atempo: Make independent of the channel layout
[12:40:35 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:fdd9663781e3: avfilter/fifo: Make independent of the channel layout
[13:18:50 CEST] <durandal_1707> ubitux:  user used filters to create pal pngs, in single pass, via API
[13:26:05 CEST] <durandal_1707> ubitux: is naming of options ok?
[14:36:38 CEST] <ubitux> durandal_1707: no opinion on the naming yet
[14:36:44 CEST] <ubitux> so i updated the gif
[14:37:00 CEST] <ubitux> there is indeed no more glitch with your latest patch
[14:37:08 CEST] <ubitux> but now we indeed can see the lightning change
[14:37:25 CEST] <ubitux> in the sky in particular, we can see this unwanted "blinking" effect
[14:38:18 CEST] <ubitux> it's not that visible because there aren't many colors, but it's still an annoying artifact
[14:39:08 CEST] <ubitux> there isn't much we can do about it though
[14:44:15 CEST] <ubitux> you can see it well when using dither=none in paletteuse
[14:52:59 CEST] <flux> what all is affected by ff_*_muxer's .*_codec fields found from ie. movenc.c? it seems they at least affect the tracks chosen for copying when invoking ffmpeg without explicit mapping options. it seems nothing in the library makes use of them?
[15:16:53 CEST] <cone-108> ffmpeg 03Timo Rothenpieler 07master:e3fd1857fb9e: swscale: add unscaled conversion from yuv420p to p010
[16:36:30 CEST] <philipl> BtbN: Could you take a look my cuvid patches?
[16:57:16 CEST] <ubitux> michaelni: sorry forgot to answer; yes you can push these tests anytime
[18:09:07 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:86f8ce9f3d95: tests/fate-run: add transcode() as a simplified enc_dec()
[18:09:09 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:ba96a2ac855f: test/fate: Add Ticket 236 / mov stream copy test
[18:09:09 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:cf9500a4dc83: tests/fate/ffmpeg: add test for mpegts->mxf steram copy (Ticket 4914)
[18:09:10 CEST] <cone-108> ffmpeg 03Michael Niedermayer 07master:eed7e08646e5: tests/fate/ffmpeg: add simple ts->avi copy test
[18:10:59 CEST] <ubitux> thanks michaelni 
[21:02:08 CEST] <BtbN> Even Pascal has NV_ENC_CAPS_SUPPORT_FIELD_ENCODING == 1, so only "field mode encoding"
[21:02:12 CEST] <BtbN> whatever that means
[21:05:44 CEST] <RiCON> interlaced?
[21:07:35 CEST] <JEEB> BtbN: probably just coding the field so that the parameter sets say that it's a field picture
[21:07:37 CEST] <wm4> where's compn when you need him
[21:07:56 CEST] <BtbN> JEEB, but shouldn't that be enough to encode an interlaced frame, with two fields?
[21:07:57 CEST] <wm4> iive: maybe you care... apparent copyright violation by amlogic, probably: https://github.com/codesnake/libamcodec/blob/master/amplayer/player/player_sub.c
[21:08:09 CEST] <JEEB> BtbN: yes
[21:08:32 CEST] <BtbN> Because that's what the result looks like: https://btbn.de/images/test/out_nvenc.mkv
[21:08:52 CEST] <JEEB> I mean, interlaced coding never went anywhere. in HEVC they just removed the special coding modes that diged deep into the format (PAFF & MBAFF and all of that jazz)
[21:09:07 CEST] <wm4> iive: I've checked something specific (a bug fix to PJS subtitles), and it's in that amlogic code too, so high probability it was taken from mplayer, and not a common third source
[21:09:15 CEST] <BtbN> JEEB, so there is no interlaced HEVC?
[21:09:27 CEST] <JEEB> there is
[21:09:40 CEST] <JEEB> just the coding modes were removed
[21:09:47 CEST] <JEEB> or more like, not passed on from AVC
[21:14:50 CEST] <BtbN> No idea what the issue with interlaced coding in nvenc is then.
[21:15:03 CEST] <philipl> BtbN: Yeah, you can indicate it's interlaced but hevc doesn't care. It's up to the consumer to reconstruct the full frames
[21:15:34 CEST] <philipl> BtbN: I'd have thought it would only do something meaningful for !hevc
[21:15:43 CEST] <fritsch> wm4: from where was it copied?
[21:15:56 CEST] <BtbN> philipl, I'm only testing with h264
[21:16:01 CEST] <BtbN> and it just doesn't work.
[21:16:09 CEST] <BtbN> Not only does it not work, it completely messes up
[21:16:26 CEST] <philipl> Yay for lack of documentation.
[21:16:48 CEST] <wm4> fritsch: mplayer's sub/subreader.c
[21:16:56 CEST] <fritsch> oha
[21:17:04 CEST] <wm4> fritsch: the aml code has some cleanups and modifications
[21:17:15 CEST] <fritsch> the licence is wrong then in any case
[21:17:20 CEST] <fritsch> :-)
[21:17:37 CEST] <wm4> certainly, it should be GPL (thus the rest of the file should be GPL too)
[21:17:43 CEST] <wm4> s/file/project
[21:17:44 CEST] <philipl> BtbN: fun. Looks like it took the fields and just encoded them into a stream one after the other.
[21:19:09 CEST] <BtbN> philipl, I wonder if it tries to encode just one field...?
[21:19:15 CEST] <philipl> at a time, yeah.
[21:19:29 CEST] <philipl> If you were to weave the fields yourself and pass those in as frames...
[21:20:03 CEST] <philipl> (Well, that would be the hevc approach)
[21:20:14 CEST] <BtbN> So it would output one frame every two fields it gets...?
[21:20:28 CEST] <BtbN> That makes no sense at all
[21:20:34 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/compat/nvenc/nvEncodeAPI.h#L660
[21:20:45 CEST] <BtbN> but what else would "frame encoding" mean?
[21:20:53 CEST] <philipl> Quite.
[21:20:55 CEST] <BtbN> Even Pascal supports only 1.
[21:22:00 CEST] <philipl> So isn't MBAFF a "frame encoding"? You don't have separate fields in the bitstream, do you?
[21:22:18 CEST] <philipl> BtbN: And while I have your attention: cuvid reviews. It's simple, I promise.
[21:22:58 CEST] <BtbN> Yeah, it's basically fine but I don't have a working CUDA SDk setup anywhere at the moment.
[21:23:12 CEST] <BtbN> so that's where the delay comes from
[21:23:45 CEST] <philipl> alrighty.
[21:24:22 CEST] <philipl> I'm working through review feedback on the mpv part of my work. It was a fun weekend project.
[21:25:13 CEST] <BtbN> The cuvid headers in the nvenc sdk do have the 10bit fields, btw.
[21:25:30 CEST] <philipl> BtbN: Oh. I'm not conviced the cuvid test in configure is right. You don't actually need to link the final binary against nvcuvid (the magic cuda loader handles that) so why should the test demand it.
[21:25:44 CEST] <philipl> BtbN: You mean the bitDepthMinus8 thing? yeah.
[21:25:52 CEST] <philipl> or eve more 10bit than that?
[21:26:17 CEST] <BtbN> that's all there is i think
[21:26:41 CEST] <BtbN> also, which magic cuda loader?
[21:26:50 CEST] <philipl> Yeah. And maybe we should make our code work with the video sdk headers - those are MIT licenced and so we could bundle them.
[21:27:00 CEST] <BtbN> only some of them are
[21:27:13 CEST] <philipl> nvcuvid.h and cuviddec.h are and that's enough.
[21:27:20 CEST] <philipl> We can modify them to work with the normal cuda.h
[21:27:22 CEST] <BtbN> they include and need cuda.h though, which isn't.
[21:27:30 CEST] <philipl> But maybe that doesn't actually help.
[21:28:07 CEST] <philipl> BtbN: At least the latest linux nvidia drivers have something called the fatbinary-loader which does some crazy magic to resolve nvcuvid (if you need it) at run time
[21:28:34 CEST] <philipl> So you only have to link libcuda to the binary directly
[21:28:37 CEST] <BtbN> And that saves ffmpeg from linking to a library from which it needs symbols?
[21:28:41 CEST] <philipl> Right.
[21:28:50 CEST] <BtbN> that sounds horrible
[21:29:08 CEST] <philipl> Right now it's all weird because you need to put libnvcuvid in your ld_library_path which it never is by default.
[21:29:26 CEST] <fritsch> better than it dyloads something that fails on runtime
[21:29:30 CEST] <BtbN> it is for me
[21:29:41 CEST] <philipl> I think it's more magic than dyload.
[21:29:51 CEST] <fritsch> even _more_ magic :-)
[21:29:54 CEST] <fritsch> that must be good then
[21:30:18 CEST] <philipl> ldd resolves nvcuvid but it's not directly linked (not in objdump output)
[21:30:32 CEST] <philipl> anyway. I need to investigate that more
[21:30:47 CEST] <wm4> try lddtree
[21:31:05 CEST] <philipl> Cute. I'll try that when I get home
[21:31:20 CEST] <BtbN> https://bpaste.net/show/28585c90fe89
[21:31:26 CEST] <BtbN> that's how that stuff looks for me
[21:31:50 CEST] <BtbN> And i just have /usr/lib/libnvcuvid.so.1
[21:31:52 CEST] <BtbN> so it works fine for me
[21:31:58 CEST] <BtbN> coming from the nvidia driver
[21:32:55 CEST] <philipl> And nvcuvid is linked to your ffmpeg binary?
[21:33:00 CEST] <BtbN> yes
[21:33:15 CEST] <BtbN> "The Fatbinary Loader library (/usr/lib/libnvidia-fatbinaryloader.so.367.27) provides support for the CUDA driver to work with CUDA fatbinaries. Fatbinary is a container format which can package multiple PTX and Cubin files compiled for different SM architectures." that's how the readme describes that
[21:33:46 CEST] <philipl> huh. Alright. I need to understand what's going on on my end. Can't access the system right now
[21:33:47 CEST] <fritsch> a one fits all "snap" like system in a .so
[21:34:19 CEST] <BtbN> Maybe your distribution just never realized it needs to install those files
[21:35:34 CEST] <philipl> WHich do you use?
[21:35:52 CEST] <BtbN> Gentoo
[21:35:56 CEST] <philipl> Ubuntu puts all the nvidia driver libraries in a separate directory that's not in the default ld library path
[21:36:15 CEST] <BtbN> And only libcuda.so is?
[21:36:16 CEST] <philipl> (which is also how the nvidia installer does it)
[21:36:37 CEST] <philipl> I think libcuda.so comes from the cuda sdk package.
[21:37:27 CEST] <BtbN> x11-drivers/nvidia-drivers-370.23 (/usr/lib64/libcuda.so.1 -> libcuda.so.370.23)
[21:37:33 CEST] <BtbN> cuda applications have to work without the SDK
[21:37:49 CEST] <philipl> Yeah. I'm just saying I think that symlink doesn't come with the Ubuntu driver package.
[21:38:00 CEST] <BtbN> the one for just .so doesn't
[21:38:05 CEST] <philipl> right
[21:38:05 CEST] <BtbN> but the one for .so.1 should
[21:38:12 CEST] <philipl> True.
[21:39:12 CEST] <cone-516> ffmpeg 03Philip Langdale 07master:1891dfe01309: cuvid: Add hwaccels and decoders for remaining supported formats
[21:39:24 CEST] <iive> wm4: nice to see you back in ffmpeg.
[21:40:30 CEST] <wm4> not sure if I'm "back"...
[21:40:49 CEST] <iive> wm4: and no, i'm not interested in that... We had a fiasco about subtitle reader a decade ago... it went nowhere.
[21:41:16 CEST] <iive> e.g. something about kiss dvd player.
[21:41:34 CEST] <iive> wm4: well, you are here.
[21:42:25 CEST] <wm4> so mplayer doesn't care about GPL violations?
[21:42:38 CEST] Action: wm4 sees a shortcut for mpv LGPL relicensing coming lol
[21:42:43 CEST] <JEEB> lol
[21:43:20 CEST] <iive> ffmpeg had a lawyer hired who had signatures of the biggest committers at the time
[21:44:00 CEST] <iive> this way he could represent ffmpeg in legal matters.
[21:46:16 CEST] <wm4> and?
[21:46:16 CEST] <iive> this of course went into the drain when the project forked.
[21:46:22 CEST] <wm4> lol
[21:46:43 CEST] <wm4> that's a fiasco of another kind though
[21:46:51 CEST] <iive> there were quite a bit of money from settlement that were in the ffmtech foundation.
[21:47:00 CEST] <iive> settlements
[21:48:57 CEST] <iive> anyway, there are no shortcuts in legal matters.
[21:49:13 CEST] <BtbN> hm, from looking at other nvenc implementations, it seems like interlaced encoding should work
[21:52:42 CEST] <BtbN> Maybe it just works on Pascal? Didn't test that yet.
[21:54:06 CEST] <cone-516> ffmpeg 03Philip Langdale 07master:86910b15c9ee: cuvid: Implement flush to support seeking in media players
[21:54:22 CEST] <BtbN> added a micro bump to that one
[21:56:37 CEST] <BtbN> philipl, https://gist.github.com/de67a5d9dc482f8ac2a788ee6caf71d1
[21:56:43 CEST] <BtbN> just -lcuda isn't enough
[22:05:50 CEST] <BtbN> Turns out disabling the stupid malware real-time scanner makes compiling actually fast on windows.
[22:07:20 CEST] <jamrial> BtbN: or just add your msys environment to the exclusion folder list
[22:07:42 CEST] <BtbN> I'll just keep that thing disabled for good.
[22:08:01 CEST] <BtbN> pointless performance hug
[22:08:03 CEST] <BtbN> *hog
[22:08:48 CEST] <jamrial> in any case it's just not fast for me. the hdd trashes like mad every time i compile anything
[22:11:36 CEST] <BtbN> philipl, nope, interlaced encoding is just as broken on pascal.
[22:13:17 CEST] <BtbN> jamrial, I'm building in cygwin, maybe that's a difference.
[22:17:51 CEST] <BtbN> well.... i thought, maybe just leaving NVENC in frame mode, and still giving it interlaced frames might magically fix stuff
[22:18:02 CEST] <BtbN> turns out it doesn't. It just plain crashes the driver.
[22:27:21 CEST] <BtbN> The trash nvenc outputs in interlaced mode almost looks like it expects a diffrent pixel format?
[23:00:49 CEST] <BtbN> Hm, I'm at a loss why interlaced encoding doesn't work. Everything seems to be in order.
[23:01:00 CEST] <BtbN> And getting in touch with the nvidia devs seems impossible
[23:40:49 CEST] <philipl> BtbN: pay them for a 'real customer' support plan.
[23:40:57 CEST] <philipl> and thanks for the reviews and pushes
[23:42:29 CEST] <philipl> BtbN: Oh, new headers in sdk have dedicated vp8 pic params struct. Not that we use those.
[23:42:43 CEST] <BtbN> for cuvid?
[23:42:46 CEST] <philipl> yeah
[23:42:59 CEST] <BtbN> well, we use it. But only implicitly through their own parser
[23:43:05 CEST] <philipl> Right.
[23:43:54 CEST] <philipl> I suspect there's some dodgy magic going on if you ever actually tried to look at the parser output - presumably a new driver and old header would lead to you trying to look at it as a vp9 struct and the values would be garbage.
[23:44:19 CEST] <philipl> Unless it was always garbage and the header is catching up with the underlying data.
[23:44:27 CEST] <BtbN> No, it just won't work if you combine new header/sdk with old driver.
[23:44:35 CEST] <BtbN> same for nvenc
[23:44:57 CEST] <BtbN> bundling the nvenc header with ffmpeg put quite a high driver version requirement on nvenc
[23:45:22 CEST] <BtbN> I don't think any normal distro sastisfies it yet.
[00:00:00 CEST] --- Wed Sep  7 2016