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

[burek]

[00:03:57 CEST] <BBB> michaelni: ty for the second email :)
[00:10:18 CEST] <michaelni> BBB, np, that was really ambigous
[00:19:51 CEST] <cone-588> ffmpeg 03Martin Vignali 07master:a2b2af791ce6: Changelog : add OpenExr improvements
[01:27:27 CEST] <llogan> BtbN (or any other nvenc'er): what should I tell this guy? https://twitter.com/Alex_Qt/status/739933727493640192
[01:28:08 CEST] <llogan> i don't understand what he means by, "zero copy frame"
[01:30:21 CEST] <durandal_1707> michaelni: ping
[01:31:34 CEST] <michaelni> durandal_1707, pong
[01:32:33 CEST] <durandal_1707> michaelni: how I'm supposed to feed those numbers to init vlc?
[01:35:51 CEST] <michaelni> feeding them to the bits/codes/symbols tables with wrap being distance beteen consecutive elements and sizes being the int8/16/32 type
[01:35:59 CEST] <michaelni> does it not work ?
[01:36:12 CEST] <michaelni> i didnt try, just assumed it would "just" work
[01:37:16 CEST] <michaelni> you could put all in one table interlaved or in 3 tables init_vlc can read either
[01:38:43 CEST] <michaelni> look at ff_init_vlc_sparse() in libavcodec/bitstream.c theres doxy above
[01:44:38 CEST] <iive> i still don't understand what's the thing with the init_vlc?
[01:44:56 CEST] <iive> aka, where these tables came from...
[01:49:47 CEST] <durandal_1707> michaelni: so just copy, no sorting needed?
[01:50:01 CEST] <michaelni> i think no sort should be needed
[01:52:07 CEST] <DHE> llogan: it means the card can decode and encode the frame in-place. no copying to/from system RAM required...
[01:52:20 CEST] <DHE> which also means no filtering on the CPU is possible...
[02:03:21 CEST] <llogan> DHE: thanks. 
[02:46:38 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:e7f658be5747: avdevice/dshow: Fix frame rate
[03:01:36 CEST] <cone-588> ffmpeg 03Muhammad Faiz 07master:77d4dfbec69f: avfilter/af_firequalizer: add zero_phase option
[04:34:02 CEST] <cone-588> ffmpeg 03Michael Niedermayer 07master:153ab83bd37c: avcodec/utils: check skip_samples signedness
[09:48:00 CEST] <BtbN> llogan: That's exactly what the cuvid decoder will do.
[09:54:41 CEST] <BtbN> andrey_turkin, are you sure the ist/ost hw_frames_ctx need to be refed? I can't see them getting freed/unrefed anywhere.
[09:55:13 CEST] <andrey_turkin> well at least other hwaccels do it
[09:55:25 CEST] <BtbN> It looks like a leak to me
[09:55:55 CEST] <BtbN> either ffmpeg.c needs to free them, or they are not refcounted
[09:56:28 CEST] <andrey_turkin> I see it like this: every field that takes AVBufferRef* should get its own ref. So either you move reference or you add new one
[09:58:49 CEST] <andrey_turkin> otherwise it is just recipe for disaster waiting to happen
[09:59:22 CEST] <BtbN> It's a leak then and will prevent it from freeing the frames.
[10:00:10 CEST] <andrey_turkin> ok so you "share" reference with ist while having a reference for it in ctx
[10:00:39 CEST] <jkqxz> It's a "leak" of something which lives for the whole duration of the ffmpeg process.  Is there some case where that matters?
[10:00:59 CEST] <BtbN> It definitely should get freed somewhere
[10:01:24 CEST] <jkqxz> exit()
[10:01:46 CEST] <BtbN> That's not how you free stuff propperly.
[10:01:55 CEST] <BtbN> ffmpeg_cleanup should unref the hw_frames_ctx
[10:04:39 CEST] <BtbN> Also, I think ffmpeg_filter.c (in the one line that touches hw_frames_ctx, should also ref it? Or does av_buffersrc_parameters_set take care of that?
[10:05:04 CEST] <BtbN> Ok, it does.
[10:20:32 CEST] <andrey_turkin> I don't like that line either
[10:21:01 CEST] <andrey_turkin> Sharing ref-counted objects is something that shouldn't be done lightly
[10:21:29 CEST] <andrey_turkin> especially if it doesn't give any speedup bonuses
[10:26:43 CEST] <andrey_turkin> ffmpeg_vaapi.c IMHO does it better - it gives ist->hw_frames_ctx a proper reference and then cleans it up on uninit.
[10:31:54 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:f2e7f9966e3d: lavc/mediacodec: do not delete a local reference twice in case of error
[10:31:55 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:79efd3b8b87e: lavc/mediacodec: rename jfields_mapping to jni_amediacodeclist_mapping
[10:31:56 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:56ef387e21ce: lavc/mediacodec: move struct declarations at the begin
[10:31:57 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:cb89fd2334d3: lavc/mediacodec: rename MediaFormat field clazz to mediaformat_class for consistency
[10:31:58 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:93f4d1646e94: lavc/mediacodec: bypass width/height restrictions when looking for a decoder
[10:31:59 CEST] <cone-832> ffmpeg 03Matthieu Bouron 07master:1729387c7ad6: lavc/mediacodec: improve error messages
[10:38:27 CEST] <andrey_turkin> I think no hwaccelerated decoders support picture change as of now?
[10:46:11 CEST] <nevcairiel> the proper hwaccels support it fine
[11:06:39 CEST] <BtbN> thw hwcontext stuff does not support changing parameters after initialization.
[11:06:49 CEST] <BtbN> So that's what is blocking it.
[11:07:23 CEST] <andrey_turkin> way I see it you only need to keep device ctx, frames ctx can be changed
[11:07:35 CEST] <BtbN> It can't.
[11:07:41 CEST] <andrey_turkin> but it can't currently
[11:07:52 CEST] <BtbN> If the decoder creates a new hw frames ctx, no other part would see it.
[11:09:11 CEST] <BtbN> In the case of cuda, cuvid could just extract the hwdevice ctx from it, and then create its own. That's fine, as only the cuctx matters.
[11:10:08 CEST] <BtbN> Wait, no, it's not fine. NVENC and npp gets the width/height from the hw_frames_ctx.
[11:10:22 CEST] <BtbN> So if cuvid creates a private hw_frames_ctx, nvenc would still use the old width.
[11:10:35 CEST] <nevcairiel> would those even support changing parameters? some encoders are a bit stubborn about that
[11:10:50 CEST] <BtbN> NVENC can be fully re-configured at any point.
[11:10:51 CEST] <andrey_turkin> nvenc wouldn't be able to
[11:11:10 CEST] <andrey_turkin> not it can't. You need to specify maximum picture durations upfront
[11:11:12 CEST] <BtbN> The ffmpeg implementation doesn't support that at the moment though.
[11:12:05 CEST] <andrey_turkin> every hw AVFrame contains reference to a hw_frames_ctx, right? So cuvid and others could in theory propagate proper contexts through AVFrames
[11:13:01 CEST] <BtbN> I don't think there is a reference to the hw_frames_ctx in the frames.
[11:13:05 CEST] <BtbN> Only in the AVCodecContext.
[11:14:07 CEST] <BtbN> Ah, there is. It's set in av_hwframe_get_buffer.
[11:16:59 CEST] <jkqxz> ffmpeg_vaapi.c does work with reinit (making a new hw_frames_ctx), but none of the other stuff (filter, encode) does so it's only useful if you download the frame immediately.
[11:17:41 CEST] <jkqxz> (So it passes the fate tests but is otherwise useless.  Oh well.)
[11:22:15 CEST] <BtbN> With re-init I mean calling init in an existing, already initialized hw_frames_ctx.
[11:22:28 CEST] <BtbN> For cuda, that's not too hard to achive. Just cleanup a potentialy pre-existing buffer pool.
[11:24:58 CEST] <andrey_turkin> changing existing hw_frames_ctx might be a bad idea as others might be using it 
[11:27:54 CEST] <andrey_turkin> filters can be fixed to work with updated hw_frames_ctx; encoders are harder
[12:15:19 CEST] <BtbN> I'd say just not supporting re-initialization is perfectly fine for now.
[12:26:39 CEST] <andrey_turkin> I agree. I'd say streams which change picture parameters on the fly are at least as rare as high-depth streams, or 4:4:4 streams, or everything else not currently supported by hwaccels. So this is something to look forward but not necessary right now
[12:30:14 CEST] <BtbN> at least nvenc should support yuv444
[12:30:28 CEST] <BtbN> cuvid doesn't though. It's amazing list of chroma formats contains exactly NV12
[12:39:41 CEST] <nevcairiel> Like I hinted in my initial review, its very well possible for the sequence callback to be called again without the key parameters like w/h/chroma to change
[12:40:22 CEST] <BtbN> well, chroma/codec won't ever change.
[12:40:48 CEST] <BtbN> And if width/height don't change, is there anything that needs to be done at all? I don't think the cuvid decoder needs a re-init then.
[12:41:04 CEST] <nevcairiel> you might want to refresh aspect ratio and color info
[13:10:20 CEST] <BtbN> nevcairiel, you happen to have a sample file where that is the case? I think it should work now, but can't really test it.
[13:34:10 CEST] <philipl> BtbN: So is adding vp8/9 support to cuvid as simple as adding AVHWAccel entries?
[13:34:45 CEST] <BtbN> It should be as much of a difference as there is for h264/hevc
[13:35:08 CEST] <BtbN> so, two lines and the structs.
[13:35:11 CEST] <nevcairiel> cuvid has no codec defines for vp8/9
[13:35:22 CEST] <philipl> They are in the enum
[13:35:30 CEST] <nevcairiel> not in my copy of the header from video sdk 6
[13:35:42 CEST] <BtbN> 7.5 has them
[13:35:45 CEST] <philipl> yeah
[13:35:55 CEST] <nevcairiel> i checked last week and 6 was still the latest
[13:36:02 CEST] <philipl> in the cuda toolkit
[13:36:17 CEST] <nevcairiel> why do they release a video sdk and then not keep it up to date
[13:36:41 CEST] <BtbN> It was merged into the CUDA SDK a while ago.
[13:36:49 CEST] <BtbN> https://gist.github.com/BtbN/a8d2b98743d3fa9b843410778db082f9
[13:36:53 CEST] <nevcairiel> it was just split out of the cuda sdk a while ago
[13:37:03 CEST] <nevcairiel> so you dont have to download a gigabyte of sdk for a few video headers
[13:37:22 CEST] <BtbN> The CUDA SDK is a web installer now, and you can choose just to download the video component.
[13:38:05 CEST] <nevcairiel> in any case should check the symbol availability before using it
[13:38:23 CEST] <BtbN> It's just an enum value, no additional symbols?
[13:38:39 CEST] <BtbN> If it's not supported, decoder creation should just fail.
[13:38:42 CEST] <nevcairiel> that needs to be available too
[13:38:46 CEST] <nevcairiel> or build fails
[13:39:02 CEST] <philipl> BtbN: I'm horribly jetlagged so apologies if this is obvious. Can the decoder return frames in system memory for standard playback? I think it can from what I'm reading
[13:39:16 CEST] <BtbN> philipl, it can't.
[13:39:19 CEST] <philipl> In an ideal world, we'd support the cuda/vdpau interop
[13:39:20 CEST] <BtbN> But I'm pulling them manually.
[13:41:33 CEST] <philipl> Your personal use-case is a transcode straight into nvenc?
[13:41:43 CEST] <BtbN> Or just hw-decoding without X
[13:42:16 CEST] <BtbN> So, the ffmpeg cuvid decoder can output to NV12 sw frames.
[13:42:20 CEST] <BtbN> But cuvid itself can't.
[13:42:28 CEST] <philipl> Yeah, I see that.
[13:42:57 CEST] <BtbN> cuvid decode, cuda scale, nvenc encode already works fine, and is quite fast and good looking.
[13:43:04 CEST] <philipl> Nicde.
[13:43:17 CEST] <BtbN> Interlaced-Encoding with nvenc is broken though
[13:43:22 CEST] <BtbN> And I have no idea what's wrong.
[13:43:31 CEST] <philipl> So, optimal X playback would involve hooking up cuda interop in the player (eg: mpv)
[13:44:03 CEST] <BtbN> I wouldn't use CUDA for playpack
[13:44:05 CEST] <nevcairiel> at that point there is really not much of an advantage over vdpau or whatever
[13:44:11 CEST] <nevcairiel> unless you want to do cuda processing in some way
[13:44:28 CEST] <andrey_turkin> in which case cuda->opengl interop is probably way to go
[13:44:57 CEST] <BtbN> No real point to go for that, as vdpau->gl already exists.
[13:45:13 CEST] <andrey_turkin> I mean if you need to run CUDA kernels first
[13:45:14 CEST] <philipl> I'm thinking vp8/9 given we won't see that in vdpau any time soon
[13:45:50 CEST] <BtbN> Just noticed, there will be a bit more of a difference for vp8/9, as they don't need(?) an mp4->annexb bsf.
[13:45:53 CEST] <philipl> but yes, cuda->opengl and cuda->vdpau are both relevant depending on the player's video path
[13:45:54 CEST] <nevcairiel> heck this is even a bit pointless on windows, as nvenc could in theory accept d3d surfaces from dxva decoding, if someone would've hooked that up for a zero-copy path
[13:46:06 CEST] <andrey_turkin> yeah, that's a pain
[13:46:22 CEST] <nevcairiel> BtbN: you could use the "null" bsf so you dont need to change the processing flow
[13:46:27 CEST] <philipl> BtbN: Yeah - I assume you don't set up a bsf and it should just work (famous last words)
[13:46:32 CEST] <BtbN> nevcairiel, oh, that exists? Nice.
[13:46:40 CEST] <andrey_turkin> I did that (from d3d11va), and it involves running a compute shader just to copy pixels from one place to another
[13:46:41 CEST] <philipl> even better
[13:47:00 CEST] <nevcairiel> thats d3d11 being silly
[13:47:03 CEST] <nevcairiel> no such issues with 9
[13:47:22 CEST] <nevcairiel> 11 has other advantages, but some basic operations are just annoying
[13:47:32 CEST] <andrey_turkin> hmm, if it works with 9Ex, I might rethink some things
[13:47:56 CEST] <andrey_turkin> I mean code is already working but I really don't like shader there
[13:48:33 CEST] <andrey_turkin> with 11 I was able to get Y plane easily but UV plane just wouldn't be shared no matter what I did
[13:48:51 CEST] <philipl> BtbN: I'm away from my nvidia hardware for the month, but I'll play around with vp8/9 when I get back if you don't get to it
[13:49:14 CEST] <burek2> hi all :) is it a known bug that ffmpeg consumes all the ram memory when using "-vf reverse" ?
[13:49:15 CEST] <BtbN> I can add support for it in the code, but I don't think I'll be able to test it.
[13:49:21 CEST] <nevcairiel> what happens with the annexb bsf anyway when the input is already bsf?
[13:49:24 CEST] <andrey_turkin> not a bug but a feature
[13:49:29 CEST] <nevcairiel> already annexb*
[13:49:29 CEST] <BtbN> nevcairiel, the bsf does nothing.
[13:49:33 CEST] <nevcairiel> brain is overheating
[13:49:38 CEST] <BtbN> it notices that case and turns into a no-op
[13:50:24 CEST] <nevcairiel> burek2: the filter is meant to reverse small sections of the video, not an entire video, as it needs to buffer all frames and then play them back in the reverse order, so memory usage is expected
[13:51:05 CEST] <BtbN> There is a vp9 superframe bsf. No idea if that's something similar?
[13:51:09 CEST] <burek2> but it buffers all the frames? ah, right.. because it acts like a pipe tool.. makes sense.. ok :) thanks :)
[13:52:10 CEST] <philipl> BtbN: Sure. I'll be the guinea pig
[13:52:44 CEST] <nevcairiel> BtbN: no thats for muxing
[13:54:29 CEST] <philipl> BtbN: On a previous subject - what makes you think interlaced nvenc should work? I don't remember seeing a claim that it was supported.
[13:54:53 CEST] <BtbN> querying the capability returns a 1, which means field mode interlaced encoding is supported.
[13:55:25 CEST] <philipl> but not documented :-)
[14:11:50 CEST] <cone-832> ffmpeg 03Michael Niedermayer 07master:a2e6c785cec3: avformat/rawdec: Fix avg_framerate for h264
[14:16:18 CEST] <BtbN> philipl, I'm not sure if VP8 decoding is supported. There is no parameter struct for it.
[14:16:24 CEST] <BtbN> It might share the VP9 one though?
[14:20:29 CEST] <BtbN> nevcairiel, are you sure there is a null bsf? I can't see one anywhere.
[14:23:08 CEST] <nevcairiel> maybe it wasnt pushed yet
[14:32:45 CEST] <nevcairiel> nicolas had it on the ML some weeks ago
[14:51:54 CEST] <philipl> BtbN: Odd.
[15:04:31 CEST] <BtbN> Kind of annoying that decoder creation fails so late...
[15:04:50 CEST] <BtbN> ffmpeg will hapilly continue sending frames, even though creating the decoder failed.
[15:14:42 CEST] <BtbN> philipl, pushed the vp8/vp9 decoders.
[15:15:01 CEST] <BtbN> Could probably also go ahead and add vc1(that's the wmv thing, right?)
[15:17:41 CEST] <nevcairiel> you could decode the extradata, that should trigger the sequence callback
[15:19:21 CEST] <BtbN> so, send it the avctx->extradata as packet?
[15:19:43 CEST] <nevcairiel> the codec creation also has a field for sequence info
[15:19:46 CEST] <nevcairiel> not sure if you fill that
[15:20:27 CEST] <BtbN> The CUVIDDECODECREATEINFO?
[15:22:53 CEST] <nevcairiel> CUVIDPARSEPARAMS takes pExtVideoInfo, which can take a sequence info buffer
[15:23:19 CEST] <nevcairiel> CUVIDEOFORMATEX *pExtVideoInfo; // [Optional] sequence header data from system layer
[15:23:48 CEST] <BtbN> So I can fill that, and it calls the sequence callback immediately?
[15:27:26 CEST] <nevcairiel> not sure
[15:29:50 CEST] <nevcairiel> maybe not because it doesnt know if this sps/pps is the one used for the frames, since you could have multiple
[15:30:06 CEST] <BtbN> does VP8/9 have such extradata?
[15:30:25 CEST] <nevcairiel> no
[15:58:38 CEST] <cone-832> ffmpeg 03Michael Niedermayer 07master:e01b19deceaa: avformat/mpegts: Fix probing of mpegts with invalid ASC
[16:28:18 CEST] <BtbN> nevcairiel, doesn't trigger the sequence callback.
[16:28:52 CEST] <BtbN> I'm just creating and immediately destroy a dummy decoder now, to find out if the hardware supports the codec.
[16:28:57 CEST] <BBB> durandal_1707: did you see http://techblog.netflix.com/2016/06/toward-practical-perceptual-video.html ?
[16:29:06 CEST] <BBB> durandal_1707: should create a lavfi filter out of it
[16:35:33 CEST] <durandal_1707> if you sponsor it, yes :)
[16:44:20 CEST] <BtbN> [nvenc @ 0x2be6680] EncodePicture failed!: out of memory (10)
[16:44:25 CEST] <BtbN> never seen that one before
[16:44:40 CEST] <BtbN> So... VC1 is very memory hungry aparently?
[16:48:08 CEST] <BtbN> Quite sure it's not a leak, transcoding a full h264 movie works.
[16:48:27 CEST] <BtbN> Also only happens with CUDA passthrough.
[17:41:25 CEST] <pfelt> greatest of mornings everyong!
[17:41:37 CEST] <BBB> hi!
[18:46:30 CEST] <prelude2004c> BtbN , any update on cuvid ?
[18:46:40 CEST] <BtbN> hm?
[18:56:44 CEST] <Easyfab> Kabylake will encode HEVC in 10bit but no VP9 HW encoding ( for the moment ? ) https://software.intel.com/en-us/articles/whats-new-in-intel-media-sdk-r2
[19:02:14 CEST] <andrey_turkin_> they are Intel not Google )
[19:07:52 CEST] <Easyfab> sure. but hardware must support vp9 HW encoding   see in Gstreamer-vaapi : https://cgit.freedesktop.org/gstreamer/gstreamer-vaapi/commit/?id=221fb9351a9563a221bf4981cc0223627c252658
[19:08:07 CEST] <jkqxz> It's implemented in VAAPI for Kaby Lake.
[19:08:32 CEST] <Easyfab> ^  that's my point
[19:08:46 CEST] <jkqxz> Well, maybe the media SDK just sucks then?
[19:18:45 CEST] <andrey_turkin_> BtbN: btw why did you use cuvid's video parser?
[20:58:04 CEST] <cone-832> ffmpeg 03Lou Logan 07master:1748eb02c8f3: doc/filters: remove outdated showwavespic example
[21:12:53 CEST] <cone-832> ffmpeg 03Michael Niedermayer 07master:c36fc857b5a8: avcodec/alsdec: Check r to prevent out of array read
[21:23:02 CEST] <ubitux> michaelni: h264-xavc-4389 is currently failing with threads
[21:23:20 CEST] <ubitux> http://fate.ffmpeg.org/report.cgi?time=20160607114333&slot=x86_64-archlinux-gcc-threads-misc
[21:23:38 CEST] <ubitux> so not related to the sps/pps merge
[21:28:31 CEST] <michaelni> ubitux, it works with frame threads (which are default)
[21:28:53 CEST] <michaelni> didnt realize it fails wih slice threads
[21:28:54 CEST] <ubitux> right
[21:29:55 CEST] <michaelni> ill look into what happens with slices in git master
[21:30:20 CEST] <michaelni> does it work with frame threads after the merge ? i thought i tested the same before and after but i might have messed up
[21:31:10 CEST] <ubitux> it fails with frame threads after the merge
[21:31:27 CEST] <ubitux> (assuming that's indeed the default)
[21:35:44 CEST] <jamrial_> that's an enlightening wiki entry
[21:37:17 CEST] <jamrial_> lol
[21:39:37 CEST] <michaelni> user deleted
[21:41:30 CEST] <michaelni> feeded to bayesan filter and external services
[21:47:41 CEST] <cone-832> ffmpeg 03Paul B Mahol 07master:fdf832a98643: avcodec: add BitJazz SheerVideo decoder
[21:48:32 CEST] <llogan> michaelni: is it possible to delete a user without using admin/accounts/users?
[21:49:27 CEST] <michaelni> probably via trac admin command line tools but i never tried
[21:51:47 CEST] <llogan> just seems like overkill and unnecessary load to list all users
[21:54:10 CEST] <Shiz> [
[22:00:25 CEST] <Plorkyeran_> it's easy via editing the database directly since there's only a few tables you need to touch
[22:00:37 CEST] <Plorkyeran_> which is sometimes useful for bulk-deleting spam accounts
[22:00:45 CEST] <llogan> laziness
[22:06:21 CEST] <llogan> unfortunately the encountered regex instances are not cumulative. maybe i'll breakout some of the OR versions.
[22:06:36 CEST] <llogan> ...cumulative towards the negative score
[22:50:15 CEST] <cone-832> ffmpeg 03Paul B Mahol 07master:60bac785c3d9: avcodec/sheervideo: add support for 8-bit interlaced (A)RGB
[23:15:53 CEST] <cone-832> ffmpeg 03Paul B Mahol 07master:c206a3243566: avcodec/sheervideo: fix order of operations for raw lines
[23:29:18 CEST] <BtbN> andrey_turkin_, what else would I do? Manually filling all those structs is a mess, and it makes it way harder to use.
[23:34:52 CEST] <cone-832> ffmpeg 03Michael Niedermayer 07master:27c1eae55f24: avcodec/h264: Fix off by 1 context count
[23:40:10 CEST] <Compn> ffmpeg lacks 10 bit gbrap pixel format. ?
[23:40:16 CEST] <Compn> thought we had them all! :P
[23:40:18 CEST] <Compn> ehe
[23:44:45 CEST] <BtbN> andrey_turkin_, it's not that I didn't think of that. But writing a full hwaccel for all of those codecs? Writing just one of them was horrible.
[00:00:00 CEST] --- Wed Jun  8 2016