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

[burek]

[01:04:08 CEST] <cone-671> ffmpeg 03Takayuki 'January June' Suwa 07master:ea93b74074c5: avdevice/alsa: wait until playback buffers are drained before closing
[01:04:09 CEST] <cone-671> ffmpeg 03Ricardo Constantino 07master:c0b3781bf2fe: rtmpproto: send swfverify value as swfurl if latter is unused
[03:59:29 CEST] <cone-671> ffmpeg 03James Almer 07master:fb0f29f9aaaf: avcodec/hevc_sei: actually propagate error codes
[04:14:07 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:1121d9270783: avcodec/msmpeg4dec: Correct table depth
[04:14:08 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:669419939c1d: avcodec/svq3: Fix multiple runtime error: signed integer overflow: 44161 * 61694 cannot be represented in type 'int'
[04:14:09 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:9e88cc94e58e: avcodec/ivi_dsp: Fix multiple left shift of negative value -2
[04:14:10 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:e92fb2bea180: avcodec/texturedsp: Fix multiple runtime error: left shift of 255 by 24 places cannot be represented in type 'int'
[04:14:11 CEST] <cone-671> ffmpeg 03Michael Niedermayer 07master:3e56db892600: avcodec/targa_y216dec: Fix width type
[04:54:12 CEST] <cone-671> ffmpeg 03James Almer 07master:4a51aa7ddaeb: configure: add missing avcodec dependencies to filters
[05:31:08 CEST] <cone-671> ffmpeg 03Steven Liu 07master:cc25a887c546: avformat/matroskadec: fix resource leak
[05:33:18 CEST] <atomnuker> bofh_: ping
[07:44:07 CEST] <atomnuker> does our flac muxer support writing attached pics (coverart)?
[07:45:01 CEST] <atomnuker> apparently not
[08:00:02 CEST] <rcombs> atomnuker: I have a patch for that
[08:00:34 CEST] <rcombs> https://gist.github.com/64a70e9aacd8c1f361098c59bafcb3a7
[08:00:52 CEST] <rcombs> I think it was sent back because of some GIF-related problem that I haven't gotten around to fixing
[08:01:28 CEST] <atomnuker> remove gif support then, its useless
[08:02:27 CEST] <rcombs> yeah that's the easy solution, I just haven't bothered
[08:02:36 CEST] <rcombs> lemme go see what all is blocking that patchset atm
[08:03:26 CEST] <rcombs> oh, just that
[08:03:41 CEST] <wm4> gif nicely breaks libavformat's awful abstraction for attached images
[08:04:00 CEST] <atomnuker> lgtm, +2, remof gaf support, skip the ml, commit, we'll fax issuas laterz
[08:04:20 CEST] <wm4> becaused attached images are "streams", except they're not, so gifs with multiple frames just don't git in
[08:05:18 CEST] <wm4> (probably better solution: just make them blobs, require user to open them as memory streams with another lavf context)
[08:09:16 CEST] <atomnuker> rcombs: when you submit the patch to the ML could you bump lavf micro as well? I need it for my cd ripper
[08:09:32 CEST] <rcombs> atomnuker: hah, that is what this is for :P
[08:09:50 CEST] <rcombs> (also includes segment.c breaking on chapters and a cue sheet demuxer)
[10:03:04 CEST] <rcombs> so, lavc's FLAC encoder's end behavior appears to be invalid
[10:04:12 CEST] <rcombs> it changes the block size for the last frame, which is fine, except that it encodes the timestamp as a frame number instead of a sample number, and my understanding is that you can only do that if every preceding frame has the same block size as the current one
[10:05:14 CEST] <wm4> doesn't the timestamp refer to the first sample in a frame
[10:05:22 CEST] <wm4> so how does the length of the last frame matter for timestamps
[10:06:49 CEST] <rcombs> wm4: the timestamp can be either in units of samples or of frames
[10:07:03 CEST] <rcombs> if it's in frames, then you convert to samples by multiplying by the block size
[10:07:14 CEST] <rcombs> this doesn't work if the block size has changed
[10:07:38 CEST] <rcombs> oh wait, there's a thing about this
[10:07:39 CEST] <rcombs> >(In the case of a fixed-blocksize stream, only the last block may be shorter than the stream blocksize; its starting sample number will be calculated as the frame number times the previous frame's blocksize, or zero if it is the first frame)
[10:08:26 CEST] <rcombs> so, what, you need to know a priori that it's the last block?
[10:08:35 CEST] <rcombs> who the fuck came up with that?
[10:08:58 CEST] <rcombs> also: "hey, let's put timestamps in the frame headers", :|
[10:09:00 CEST] <wm4> hm not sure if I get it
[10:28:34 CEST] <nevcairiel> rcombs: cant you just always calc from the previous clocks size
[10:28:44 CEST] <nevcairiel> blocks*
[10:31:40 CEST] <alevinsn> wm4:  I started doing the videotoolbox review tonight (before you sent the ping to the ML)--if you are willing to wait for my review
[10:31:44 CEST] <alevinsn> I'll get it done
[10:32:03 CEST] <wm4> ok
[10:32:29 CEST] <alevinsn> there is quite a bit of code, so its slow going
[10:32:55 CEST] <alevinsn> "    // Somewhat tricky because the API user can call av_videotoolbox_default_free()
[10:32:55 CEST] <alevinsn>     // at any time.
[10:32:55 CEST] <alevinsn> "
[10:33:01 CEST] <alevinsn> I didn't understand this comment
[10:33:15 CEST] <alevinsn> av_videotoolbox_default_free() doesn't do anything with hwaccel_priv_data
[10:33:23 CEST] <alevinsn> it only frees hwaccel_context
[10:35:38 CEST] <wm4> because videotoolbox_default_free calls that function
[10:37:36 CEST] <alevinsn> I don't understand why that matters--if it returns null, videotoolbox_default_free() just returns
[10:41:22 CEST] <rcombs> nevcairiel: yeah, that's what I'm doing in flacenc now
[10:41:59 CEST] <wm4> alevinsn: because there is an unusual situation with avctx->internal not being set because the codec context can be closed
[10:42:22 CEST] <rcombs> nevcairiel: but that doesn't work for e.g. flac_read_timestamp
[10:44:42 CEST] <alevinsn> wm4:  okay, but what does that have to do with av_videotoolbox_default_free()?  plus, if that's the case, why is it okay to use hwaccel_priv_data directly in the next function, videotoolbox_buffer_create()?
[10:47:51 CEST] <alevinsn> and then further, if we go to the places that call videotoolbox_get_context(), such as videotoolbox_session_decode_frame()
[10:48:15 CEST] <alevinsn> if it is possible for internal to be null, then what this function is doing looks wrong
[10:50:45 CEST] <wm4> av_videotoolbox_default_free() calls an internal function that's shared
[10:50:56 CEST] <wm4> it's not
[10:50:58 CEST] <wm4> ...
[10:56:20 CEST] <alevinsn> you mean how videotoolbox_default_free() is also called by videotoolbox_uninit()?
[10:58:55 CEST] <wm4> just read the code
[11:01:00 CEST] <alevinsn> I have--but, I still don't understand why the comment is relevant, and if it is relevant, why there aren't issues in the other places
[11:01:40 CEST] <alevinsn> maybe if you could describe the sequence that prompted that check, it would be helpful (for me)
[11:02:18 CEST] <wm4> when videotoolbox_default_free() is called if the codec is closed
[11:10:07 CEST] <alevinsn> so, are you saying there is the possibility that, because av_videotoolbox_default_free() is exposed to the user
[11:10:17 CEST] <alevinsn> if it is called after the codec has been closed
[11:10:25 CEST] <alevinsn> you have that check there to make sure it doesn't crash?
[11:10:33 CEST] <wm4> yes
[11:12:15 CEST] <alevinsn> OK, I got it, next thing, I know it was doing this in the existing code, but why isn't there a cast to (VTContext *) for hwaccel_priv_data?  hwaccel_priv_data is of type void *
[11:12:20 CEST] <alevinsn> I would think that this would at least produce a warning
[11:12:27 CEST] <alevinsn> a compiler warning
[11:13:08 CEST] <wm4> this is not C++
[11:13:31 CEST] <nevcairiel> yeah C does not need casting for that
[11:13:47 CEST] <alevinsn> but, it is needed for:     CVPixelBufferRef pixbuf = (CVPixelBufferRef)vtctx->frame;
[11:14:09 CEST] <nevcairiel> you dont need casts from void* to other pointers
[11:14:23 CEST] <nevcairiel> but you do need it for other complex type conversions
[11:14:50 CEST] <alevinsn> oh--that just looks wrong to me, but I can get used to it
[11:16:13 CEST] <alevinsn> ok, before I head to bed, I had a thought that you might find amusing that I thought I would share
[11:16:51 CEST] <alevinsn> since wm4 is effectively anonymous, wm4 could in theory be anyone... so, if we take that to its logical conclusion....
[11:17:05 CEST] <alevinsn> wm4 is cehoyos masquerading as wm4 :-)
[11:17:54 CEST] <alevinsn> ok, maybe not as amusing as I thought it was
[11:18:42 CEST] <nevcairiel> using a fixed name still identifies you, even if its not your real name
[11:19:29 CEST] <alevinsn> I meant
[11:20:08 CEST] <alevinsn> with the nature of the Internet, it is certainly possible to have multiple aliases
[11:21:19 CEST] <nevcairiel> that could be claimed about anyone
[11:21:34 CEST] <nevcairiel> how do we know you are who you are claiming to be? :d
[11:22:04 CEST] <alevinsn> yes, yes, a "real name" doesn't mean anything as well
[11:23:24 CEST] <alevinsn> but, at least with wm4, and the e-mail address associated with wm4 on the ML, I don't think there is anything to easily tie wm4 to the identity of a specific individual
[11:24:22 CEST] <alevinsn> so, I was suggesting that these arguments between wm4 and cehoyos may be a joke perpetrated by cehoyos entirely... its ridiculous, which is why I thought it was amusing
[11:31:55 CEST] <iive> alevinsn: you mean, this might be a joke by wm4 entirely :P
[11:47:36 CEST] <wm4> does anyone know what the allowed timestamp range is?
[11:47:43 CEST] <wm4> in libavformat
[11:51:12 CEST] <BtbN> Whatever fits into int64 I'd assume?
[11:52:14 CEST] <wm4> then stuff like RELATIVE_TS_BASE could probably not work
[11:52:17 CEST] <nevcairiel> 48 bit i think, because of this relative ts hack
[11:52:21 CEST] <wm4> lol
[11:52:38 CEST] <nevcairiel> (not like 48 bit isnt a lot of timestamps)
[11:53:52 CEST] <JEEB> relative TS base?
[11:53:58 CEST] <JEEB> it feels like I don't want to know about this...
[11:54:32 CEST] <wm4> indeed you don't
[11:54:58 CEST] <nevcairiel> i forget wtf this was even for
[11:58:09 CEST] <wm4> full 64 bit is a bit crazy, because it'd overflow most calculations that do something with timestamps
[11:58:27 CEST] <rcombs> OK now I've gotta know
[11:58:32 CEST] <rcombs> what is this
[11:58:39 CEST] <rcombs> (RELATIVE_TS_BASE)
[12:01:07 CEST] <wm4> see libavformat/utils.c
[12:01:09 CEST] <wm4> try not to cry
[12:02:13 CEST] <rcombs> &wat
[12:16:25 CEST] <BtbN> hm, adding support for the hw_device_ctx to nvenc.c is harder than expected
[12:16:42 CEST] <BtbN> as it relies on the data_pix_fmt from the context
[12:18:39 CEST] <wm4> what does it do with it? initialization?
[12:19:08 CEST] <BtbN> I'm trying to find out if it really needs it before getting the first frame
[12:19:53 CEST] <wm4> it it really does, using hw_frames_ctx might be reasonable, but only jkqxz knows whether this would be ok API use
[12:21:36 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L408 here it just gets the cuda context, using hw_device_ctx instead is trivial there.
[12:22:24 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1406 and here it gets the width/height and sw_format, which I'm pretty sure can all be gotten from the frame instead.
[12:22:43 CEST] <wm4> certainly
[12:23:00 CEST] <wm4> so it looks like hw_device_ctx support is possible/easy
[12:23:13 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/nvenc.c#L1305 but this is the place that's the problem
[12:23:42 CEST] <wm4> ah
[12:23:58 CEST] <BtbN> That data_pix_fmt is used in the capabilities checks, to see if the device supports 10bit/yuv444 and so on
[12:24:26 CEST] <wm4> you could init the encoder on the first frame
[12:24:37 CEST] <wm4> though that seems annoying
[12:24:38 CEST] <BtbN> That would be a huge re-structure
[12:25:04 CEST] <BtbN> It's also used when configuring the encoder, like vui->videoFullRangeFlag = (avctx->color_range == AVCOL_RANGE_JPEG || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ420P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ422P || ctx->data_pix_fmt == AV_PIX_FMT_YUVJ444P);
[12:25:54 CEST] <wm4> J formats, seriously
[12:26:13 CEST] <wm4> they're deprecated and hw_device_ctx doesn't have colorspace info AFAIK
[12:26:16 CEST] <BtbN> A lot of decoders still output those
[12:26:25 CEST] <wm4> sorry, hw_frames_ctx
[12:26:55 CEST] <wm4> you can check avctx->color_range though, which I suppose is set on init
[12:27:00 CEST] <wm4> (why not the pixfmt??)
[12:27:07 CEST] <wm4> maybe this is a non-issue
[12:27:25 CEST] <BtbN> hm, I'd assume I can just do ctx->data_pix_fmt = avctx->sw_pix_fmt;
[12:27:39 CEST] <wm4> yeah
[12:27:54 CEST] <wm4> just update the docs
[12:28:04 CEST] <BtbN> There are docs about that?
[12:28:19 CEST] <wm4> the current docs say about that field: * - encoding: unused.
[12:28:29 CEST] <wm4> (well, doxygen, not docs)
[12:28:34 CEST] <BtbN> ah, those docs
[12:30:32 CEST] <BtbN> Do I just put "set by user" there?
[12:30:50 CEST] <BtbN> Or should I describe it a bit more in detail?
[12:31:43 CEST] <wm4> maybe mention that it's only interpreted if pix_fmt is a hwaccel format
[12:32:43 CEST] <BtbN> "encoding: May be used by some hw encoders to find the underlying sw pixel format when pix_fmt is a hwaccel format."
[12:33:39 CEST] <wm4> sounds good
[12:33:41 CEST] <BtbN> I wonder if ffmpeg.c already sets it correctly when encoding
[12:33:46 CEST] <BtbN> It should?
[12:34:01 CEST] <wm4> searching for it shows nothing lol
[12:34:13 CEST] <wm4> but nothing should stop it from being able to
[12:34:30 CEST] <BtbN> cuvid.c makes use of it, so ffmpeg.c has to touch it somewhere
[12:37:58 CEST] <jkqxz> It's set in the get_format code in lavc.
[12:38:54 CEST] <jkqxz> I'm not sure exactly what you are trying to do here, but hw_device_ctx for encoders is only useful if you are using software frames as input.
[12:39:14 CEST] <BtbN> So far it was used by nvenc.c to get the cuda context
[12:39:26 CEST] <BtbN> And as such was also inter-mangled into some other things
[12:39:51 CEST] <BtbN> primarily only to get the sw pixel format. And I'm not trying to add avctx->hw_device_ctx support to nvenc.c
[12:39:58 CEST] <BtbN> to eventually migrate ffmpeg_cuvid.c
[12:40:03 CEST] <wm4> jkqxz: so he should access hw_frames_ctx?
[12:40:33 CEST] <wm4> the doxygen doesn't really say whether it's set on init
[12:40:45 CEST] <jkqxz> If you have hardware frames as input, then you use hw_frames_ctx (including the device inside it).
[12:41:06 CEST] <jkqxz> If you have software frames as input, use hw_device_ctx to get the device you are meant to use, or if not set you can make one up yourself by whatever means.
[12:41:25 CEST] <jkqxz> Yes, hw_frames_ctx must be set on init.
[12:42:05 CEST] <jkqxz> ("This field should be set before avcodec_open2() is called.")
[12:42:23 CEST] <wm4> oh damn
[12:42:26 CEST] <wm4> blindness
[12:42:38 CEST] <BtbN> But that makes the entire effort pointless
[12:42:47 CEST] <jkqxz> AVCodecContext.sw_pix_fmt shouldn't be relevant, because either it's the sw_pix_fmt of the hw_frames_ctx, or it's the pix_fmt itself because you are using software frames.
[12:43:09 CEST] <wm4> BtbN: well for sw mode, you still want to read hw_device_ctx to set the device to be used
[12:43:25 CEST] <wm4> makes for a better user API than messing with private options etc.
[12:43:39 CEST] <BtbN> in sw mode nvenc.c just creates its own cuda context
[12:44:37 CEST] <BtbN> But the whole idea was to get rid of the half-initialized hw_frames_ctx ffmpeg_cuvid.c does, and instead get rid of it entirely, as it's essentialy not needed at all
[12:44:56 CEST] <BtbN> And I'm pretty sure that can be done without any crazy hackery
[12:45:28 CEST] <jkqxz> The context created by nvenc will be on some device it picks (possibly with a private option), rather than on the one defined by the user with this common mechanism.  That's all you gain by using this.
[12:45:47 CEST] <jkqxz> (Same change for libmfx: <https://git.libav.org/?p=libav.git;a=commit;h=3d197514e613ccd9eab43180c0a7c8b09a307606>.)
[12:46:16 CEST] <jkqxz> (Except it's worse there, because of things opening for exclusive access by default and breaking multiple instances.)
[12:48:14 CEST] <wm4> BtbN: well the user can still init the hw_frames_ctx for decoding, it just isn't particularly useless
[12:48:24 CEST] <wm4> for videotoolbox the situation is similarly awkward
[12:48:41 CEST] <wm4> (maybe worse because neither hw_frames_ctx nor hw_device_ctx really make sense for it)
[12:48:45 CEST] <wm4> at least for decoding
[13:00:19 CEST] <BtbN> wm4, https://github.com/FFmpeg/FFmpeg/compare/master...BtbN:master this looks pretty clean to me.
[13:08:37 CEST] <wm4> BtbN: not sure
[13:09:11 CEST] <wm4> I think hw_device_ctx should be used in sw format mode only?
[13:09:45 CEST] <BtbN> But what was the whole point of the entire effort then? I thought it was to get rid of the ugglynes ffmpeg_cuvid.c does
[13:09:58 CEST] <BtbN> It didn't help with that at all
[13:13:59 CEST] <wm4> but what does this have to do with ffmpeg_cuvid.c?
[13:14:20 CEST] <BtbN> It currently half-initializes a hw_frames_ctx, which then gets fully initialized by cuvid.c
[13:14:31 CEST] <BtbN> That's ugly, and it really only needs to create a CUDA context
[13:15:29 CEST] <wm4> you can drop that
[13:15:48 CEST] <BtbN> No I can't, nvenc.c needs the hw_frames_ctx
[13:15:52 CEST] <wm4> output avframes will have a privately created heframesctx
[13:16:04 CEST] <BtbN> but nvenc needs it on the avctx
[13:16:09 CEST] <BtbN> at init-time
[13:16:12 CEST] <BtbN> to get the cuda context
[13:18:27 CEST] <wm4> encoders are initialized once the first frame was filtered/decoded, right?
[13:18:59 CEST] <BtbN> in ffmpeg.c, yes. But nvenc needs the hw_frames_ctx to be set on init, it being on the frames isn't enough.
[13:19:20 CEST] <atomnuker> they ought to be given container framesize != first image's framesize
[13:21:50 CEST] <jkqxz> hw_frames_ctx on the AVCodecContext is set from the first frame when the encoder is opened.
[13:22:59 CEST] <wm4> BtbN: so it looks like you're already done
[13:23:16 CEST] <wm4> although being able to set the device in sw mode would be good too
[13:23:54 CEST] <BtbN> jkqxz, where is that done?
[13:24:05 CEST] <jkqxz> I don't understand what sw_pix_fmt is even meaning there.  You already have the hw_frames_ctx in that case, so you already know the sw_pix_fmt.
[13:24:31 CEST] <BtbN> for cases where you don't have a hw_frames_ctx, but only a hw_device_ctx
[13:24:38 CEST] <BtbN> As for CUDA, there is no inherent need for one
[13:24:53 CEST] <jkqxz> <http://git.videolan.org/?p=ffmpeg.git;a=blob;f=ffmpeg.c;h=e798d922779f6fbcf019902cb0dfcd3cd877643d;hb=HEAD#l3430>
[13:25:13 CEST] <jkqxz> But the only such cases are software case where the pix_fmt is pix_fmt.
[13:25:29 CEST] <jkqxz> (Immediately before avcodec_open2()...)
[13:25:47 CEST] <BtbN> right now they are, but due to the new field being available, the whole cuvid/nvenc hwaccel could be migrated to not use an external hw_frames_ctx
[13:27:29 CEST] <wm4> hw_frames_ctx is also needed for filtering
[13:27:38 CEST] <wm4> mpv uses it to get the sw_format (and also screenshots)
[13:27:38 CEST] <jkqxz> There is no "external" hw_frames_ctx, but there is still the one carried in the frames (which is required, because you need the hardware metadata on them).
[13:27:56 CEST] <jkqxz> And you need to pass that one to the encoder.
[13:27:57 CEST] <wm4> oh with external you mean the one in ffmpeg_cuvid.c?
[13:28:03 CEST] <BtbN> yes
[13:28:10 CEST] <wm4> just create the hw_frames_ctx in the decoder
[13:28:12 CEST] <BtbN> cuvid.c conveniently creates one internally, so the frames coming out of it have one
[13:28:14 CEST] <wm4> like it's done now
[13:28:17 CEST] <wm4> (after my patch)
[13:28:48 CEST] <BtbN> hm, this basically means that ffmpeg_cuvid.c can be almost entirely removed now
[13:28:56 CEST] <wm4> if cuvid.c doesn't support custom frame allocation, and if changing the sw_format to something else doesn't make sense, the "external" hw_frames_ctx should be deprecated
[13:29:16 CEST] <wm4> (changing sw_format might make sense if the hw decoder supports multiple formats for the same video)
[13:29:28 CEST] <wm4> (like videotoolbox does, urgh)
[13:29:36 CEST] <BtbN> it does
[13:29:51 CEST] <BtbN> you can for example request an 8bit format for 10bit video, and it will do as you told it
[13:30:09 CEST] <wm4> in that case, only the half-initialized part needs to be deprecated
[13:30:24 CEST] <BtbN> cuvid.c already uses sw_pix_format for that
[13:30:26 CEST] <wm4> (so a user would either have to set a fully initialized one, or none)
[13:30:42 CEST] <wm4> well I don't think the user is supposed to set sw_pix_format
[13:31:00 CEST] <BtbN> But it looks like ffmpeg.c would have to learn about hw_device_ctx first. The InputStream only has a hw_frames_ctx
[13:31:12 CEST] <wm4> and for videotoolbox I made it so that it can select the sw_format with a hw_frames_ctx
[13:31:32 CEST] <wm4> advanced device selection is in Libav
[13:31:41 CEST] <BtbN> cuvid.c insist that thw hw_frames_ctx swformat is identical to the one in sw_pix_fmt
[13:31:47 CEST] <wm4> I think it's 50 commits or so away from the currently merged one
[13:32:05 CEST] <wm4> why does it do that?
[13:32:32 CEST] <BtbN> Because anything else doesn't make sense?
[13:33:17 CEST] <wm4> well what sw_pix_fmt is is not too well defined anyway
[13:33:30 CEST] <wm4> for example with real hwaccels, the hw_frames_ctx sw_format can be different
[13:33:35 CEST] <BtbN> What is it supposed to do if the sw_pix_fmt is NV12, but the externally supplied context is yuv420p?
[13:33:48 CEST] <wm4> e.g. if sw_pix_fmt is yuv420p, the hw_frames_ctx one is usually nv12
[13:33:49 CEST] <BtbN> So it just throws an error
[13:34:12 CEST] <wm4> does cuvid (the nvidia API) support yuv420p decoding?
[13:34:17 CEST] <BtbN> no
[13:34:21 CEST] <wm4> then throw an error
[13:34:31 CEST] <BtbN> It will throw an error whenever they mismatch
[13:34:34 CEST] <BtbN> no matter in what way
[13:35:36 CEST] <wm4> didn't you say it supports decoding 10 bit video to 8 bit surfaces?
[13:36:43 CEST] <BtbN> it does
[13:36:59 CEST] <BtbN> but that works by having 10bit hevc, and setting an 8 bit sw format
[13:37:00 CEST] <wm4> so in that case, if the user sets a hw_frames_ctx, it could set the sw_format to 8 bit
[13:37:08 CEST] <wm4> even though avctx->sw_pix_fmt is 10 bit
[13:37:36 CEST] <BtbN> It will want that to be 8 bit as well
[13:37:58 CEST] <wm4> then set it?
[13:37:58 CEST] <BtbN> which makes sense to me, as it represents the output pixel format. coded input doesn't have a pixel format
[13:38:08 CEST] <wm4> sw_pix_fmt has no meaning
[13:38:20 CEST] <wm4> it only has some meaning within hwaccels and get_format
[13:38:30 CEST] <wm4> but it's not interpreted or used otherwise by anything
[13:38:39 CEST] <wm4> so do whatever is convenient?
[13:41:47 CEST] <BtbN> https://github.com/FFmpeg/FFmpeg/compare/master...BtbN:master this should be enough for support in sw mode
[13:44:13 CEST] <wm4> yeah looks good to me
[13:44:22 CEST] <wm4> maybe the factoring could be improved
[13:44:39 CEST] <wm4> like moving device creation into a function (or just using the hwcontext's device creation)
[13:45:46 CEST] <BtbN> that's a bit complicated as it's interleaved with the capabilities check
[13:46:03 CEST] <BtbN> it will by default use the first device that supports the needed features for the current encode, unless user-specified
[13:46:56 CEST] <wm4> are there really multiple devices usually?
[13:47:19 CEST] <BtbN> I have come across multiple people who have more than one GPU
[13:47:29 CEST] <wm4> yeah, I'd expect one device per GPU
[13:47:30 CEST] <BtbN> Also some with very different GPUs
[13:47:56 CEST] <BtbN> Like, an old Quadro K600 as output-GPU, and a bunch of GPGPU-Cards on top
[13:47:57 CEST] <wm4> in theory you can pass an AVDictionary to device creation, but yeah maybe not worth the effort
[13:48:19 CEST] <BtbN> I'd still need to enumerate all devices
[13:48:25 CEST] <BtbN> And check each one for its nvenc capabilities
[13:48:34 CEST] <wm4> I mean you could do the enumeration in the hwcontext code
[13:48:46 CEST] <BtbN> And pass in a callback to check if it's ok? oO
[13:49:06 CEST] <wm4> no, just come up with a way to signal requirements via the AVDictionary
[13:49:18 CEST] <wm4> but that's probably way more complex than the current code
[13:49:38 CEST] <BtbN> That'd make the hwcontext code need to know about nvenc
[13:49:50 CEST] <BtbN> As qurying the device capabilities is nvenc api, not generic CUDA
[13:49:57 CEST] <jkqxz> Yeah, requirements would be nasty.
[13:50:50 CEST] <wm4> still a bit annoying that this nvenc can't be used when doing full-hw transcoding
[13:50:52 CEST] <jkqxz> I assume the default mode is also so that you automagically choose the next card when you run into the two-instances-per-consumer-GPU limit?
[13:51:12 CEST] <wm4> (is it still 2 per GPU?)
[13:51:22 CEST] <BtbN> 2 per nvenc chip on consumer cards
[13:51:25 CEST] <BtbN> which happen to have only one
[13:52:14 CEST] <BtbN> jkqxz, yes, it would indeed do that.
[13:52:20 CEST] <BtbN> Never tought about that, but yes, that would happen
[13:52:54 CEST] <jkqxz> Because that would be useful to some set of people, and isn't really achievable without weird configuration by any other route.
[13:53:49 CEST] <BtbN> nvEncOpenEncodeSessionEx is what fails in that case, which makes nvenc_open_session fail, which makes nvenc_check_device fail, which causes nvenc_setup_device to iterate to the next device
[13:56:15 CEST] <wm4> pretty nasty if you'd like that with full-hw transcoding
[13:56:24 CEST] <wm4> since the encoder is actually opened last
[13:58:45 CEST] <BtbN> With full-hw transcoding it gets a cuda context as input
[13:58:49 CEST] <BtbN> and that logic never runs
[13:59:01 CEST] <BtbN> it just runs a capability check on the passed context, and throws an error if it doesn't work
[14:03:54 CEST] <wm4> yeah
[14:04:04 CEST] <wm4> which is a problem if someone wants that fallback logic
[14:06:42 CEST] <BtbN> it's not possible in a sensible way to do that on full hw transcoding
[14:14:50 CEST] <cone-349> ffmpeg 03Timo Rothenpieler 07master:dad6f44bbd57: avcodec/nvenc: support external context in sw mode
[14:14:50 CEST] <cone-349> ffmpeg 03Timo Rothenpieler 07master:f89a89c5500c: avcodec/nvenc: use frames hwctx when registering a frame
[14:15:17 CEST] <BtbN> Is the git server busy/about to die? It just was sitting there at "remote: -Info-          Update is fast-forward" for almost two minutes
[14:15:48 CEST] <atomnuker> hm, I think I noticed a slowdown too
[14:16:19 CEST] <BtbN> j-b, ^
[15:32:57 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:464c4b86ee43: avcodec/mss34dsp: Fix multiple signed integer overflow
[15:32:58 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:78bf446852a7: avcodec/ra144: Fix runtime error: left shift of negative value -798
[15:32:59 CEST] <cone-349> ffmpeg 03Michael Niedermayer 07master:2162b862eba5: avcodec/magicyuv: Check len to be supported
[15:52:31 CEST] <Compn> BtbN : dont we run our own git ?
[15:53:20 CEST] <Compn> yeah git.ffmpeg.org goes to our bg host
[15:53:25 CEST] <michaelni> Compn, our git is not slow
[15:53:53 CEST] <Compn> BtbN and atomnuker were the reporters, not me :)
[15:54:08 CEST] <michaelni> deveopers use git at source.ffmpeg.org:ffmpeg
[15:54:31 CEST] <michaelni> source.ffmpeg.org.	600	IN	CNAME	git.videolan.org.
[15:54:34 CEST] <Compn> ah
[15:54:42 CEST] <jamrial> is this about fetch/pull or push? because while the former is fast as usual, the latter started being slow for me ever since the videolan server move
[15:54:43 CEST] <Compn> yeah sorry i was thinking something else :D
[15:55:22 CEST] <Compn> tracert is timing out to source.ffmpeg.org, somewhere in london
[15:55:38 CEST] <Compn> at least for me
[15:55:54 CEST] <Compn> not that that has anything to do with git slowdonw
[15:55:56 CEST] Action: Compn runs
[16:10:43 CEST] <philipl> BtbN: so what was the conclusion on whethere the hw_frame_ctx initialisation can be removed from ffmpeg_cuvid.c?
[16:11:55 CEST] <wm4> it can
[16:12:11 CEST] <BtbN> well, not without some merge from libav it seems
[16:15:32 CEST] <wm4> Libav brings the generic hwaccel
[16:15:42 CEST] <wm4> it will work with the current cuvid
[16:15:52 CEST] <wm4> (because it uses hw_device_ctx)
[16:16:09 CEST] <wm4> so ffmpeg_cuvid.c can be deleted, and the hwaccel entry in ffmpeg_opt.c slightly updated
[16:16:23 CEST] <philipl> And we think nvenc will work correctly after the last changes?
[16:16:50 CEST] <wm4> yes
[16:21:55 CEST] <philipl> great.
[17:18:02 CEST] <Compn> whos the nvenc maintainer ?
[17:18:03 CEST] Action: Compn runs
[17:42:32 CEST] <philipl> BtbN: So you guys were discussing using avctx->sw_pix_fmt in ff_nvenc_encode_init instead of hw_frames_ctx. Any reason not to do that now? I tried and it works with ffmpeg.c
[17:42:55 CEST] <BtbN> Because it's documented as unused
[17:43:15 CEST] <BtbN> And of course it works, data_pix_fmt being wrong wouldn't cause obvious failures
[17:43:43 CEST] <BtbN> Could only cause wrong colors, and wrong settings when doing yuv444 or 10bit encodes
[17:44:21 CEST] <BtbN> hw_frames_ctx is set anyway, so no need to jump through hoops here
[17:44:38 CEST] <philipl> fair enough
[17:45:24 CEST] <j-b> BtbN: yes, see https://munin.videolan.org/VideoLAN/goldeneye.videolan.org/vmstat.html
[17:45:56 CEST] <j-b> BtbN: or https://munin.videolan.org/VideoLAN/goldeneye.videolan.org/index.html in general
[17:46:41 CEST] <BtbN> yeah, looks very busy the last day or so
[17:47:06 CEST] <j-b> the load is very very high
[17:47:44 CEST] <j-b> and requests quite high too
[17:47:48 CEST] <BtbN> are there some people constantly cloning stuff with no end?
[17:47:54 CEST] <BtbN> that's how it looks to me
[17:48:15 CEST] <j-b> yes
[17:48:17 CEST] <j-b> very often
[17:48:31 CEST] <j-b> usually people start doing that in loop
[18:03:38 CEST] <j-b> BtbN: I did some magic. I hope it will help. Answer in 10 min.
[18:12:00 CEST] <j-b> BtbN: seems way better.
[18:12:12 CEST] <BtbN> banned some spamming IP(s)?
[18:16:47 CEST] <j-b> BtbN: + cleaning + restarting some services, yes.
[18:25:20 CEST] <atomnuker> BBB: what fails currently that we need to align stuff?
[18:25:29 CEST] <atomnuker> why didn't it happen before?
[18:30:19 CEST] <j-b> BtbN: everything is in place, yes. But it's weird to see that many git requests, aka 3x more than last week.
[18:33:02 CEST] <BtbN> probably a single user with a massive misconfiguration hammering the server
[18:35:13 CEST] <j-b> BtbN: does not seem so.
[18:52:42 CEST] <philipl> Shouldn't we add these new *.version files to .gitignore?
[19:12:25 CEST] <jamrial> they aren't?
[19:14:46 CEST] <BBB> atomnuker: see earlier emails about specifics, but the current patch series is trying to address the more general issue of how to make requirements for alignment specific and explicit
[19:14:56 CEST] <BBB> (right now its implied but undocumented and easy to get wrong)
[19:15:22 CEST] <jamrial> philipl: ah yeah, an upcoming merge adds them
[19:15:43 CEST] <jamrial> philipl: i'll cherry pick it since it's a bit far away from out current point
[19:19:23 CEST] <cone-834> ffmpeg 03Diego Biurrun 07master:fbc304239fe6: build: Ignore generated .version files
[19:33:47 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:c04aa148824f: avcodec/g726: Fix runtime error: left shift of negative value -2
[19:33:48 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:0ac1c87194a6: avcodec/eamad: Fix runtime error: signed integer overflow: 49674 * 49858 cannot be represented in type 'int'
[19:33:49 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:a38e9797cb41: avcodec/s302m: Fix left shift of 8 by 28 places cannot be represented in type 'int'
[19:33:50 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:a5e0dbf530d4: avcodec/aacdec_template: Do not decode 2nd PCE if it will lead to failure
[19:33:51 CEST] <cone-834> ffmpeg 03Michael Niedermayer 07master:441026fcb13a: avcodec/xwddec: Check bpp more completely
[19:48:31 CEST] <cone-834> ffmpeg 03Marton Balint 07master:c0443c1af1a7: lavfi/avfiltergraph: only return EOF in avfilter_graph_request_oldest if all sinks EOFed
[20:00:48 CEST] <cone-834> ffmpeg 03wm4 07release/3.3:059db2204046: ffmpeg: check for unconnected outputs
[20:00:49 CEST] <cone-834> ffmpeg 03Marton Balint 07release/3.3:508e410d348e: lavfi/avfiltergraph: only return EOF in avfilter_graph_request_oldest if all sinks EOFed
[21:01:43 CEST] <alevinsn> wm4:  just finished videotoolbox review
[21:22:33 CEST] <durandal_1707> would someone write cmadd SIMD for me?
[21:43:16 CEST] <kierank> durandal_1707: no
[21:44:57 CEST] <durandal_1707> kierank: why?
[21:45:03 CEST] <kierank> i dunno what cmadd is
[21:45:28 CEST] <durandal_1707> complex multiple and add
[23:58:29 CEST] <durandal_1707> jamrial: how should i name function that does complex multiplication and adds result to accumulator?
[23:59:16 CEST] <jamrial> scalarproduct_something?
[00:00:00 CEST] --- Mon May  8 2017