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

[burek]

[00:48:00 CET] <atomnuker> nevcairiel: did you have the time to port one avpriv cas to c11 exchange?
[00:48:17 CET] <atomnuker> jamrial_: as soon as the atomics stuff get removed
[01:41:02 CET] <tmm1> i'm trying to add prores support to the videotoolbox encoder
[01:41:46 CET] <tmm1> can someone help me figure out the AV_PIX_FMT_YUV422P10LE version of get_cv_pixel_info here: https://github.com/FFmpeg/FFmpeg/blob/master/libavcodec/videotoolboxenc.c#L1944-L1971
[01:42:01 CET] <tmm1> would it be the same as AV_PIX_FMT_YUV420P 
[01:44:36 CET] <jkqxz> Probably, but without the /2s on chroma height.
[01:45:36 CET] <jkqxz> Make sure the videotoolbox layout is actually the same as YUV422P10LE, though.  They can do all sorts of things with weird packing when it's 10-bit.
[01:48:24 CET] <jkqxz> What advantage would that encoder have, anyway?  Is it something GPU something for great somehowbetterness?
[01:50:24 CET] <tmm1> yea its hardware accelerated supposedly
[01:55:25 CET] <tmm1> encoder is throwing kVTPixelTransferNotSupportedErr, i guess its probably not in v210 format
[03:20:11 CET] <jamrial_> nevcairiel: your msvc 2017 fate failures are almost all an EPERM error
[04:51:00 CET] <cone-886> ffmpeg 03Steven Liu 07master:0e5260226a72: avformat/hlsenc: reindent after previous commits
[05:35:11 CET] <G30rge> Seeing an issue where the AAC decoder is populating the AVFrame linesize incorrectly.  Is there a known issue related to this?  The sample format is FLTP and the linesize is being set as though it is a packed format - not interleaved (IE the linesize = chan 1 + chan 2)
[05:39:08 CET] <G30rge> I meant to say treated as packed/interleaved instead of planar
[05:49:57 CET] <durandal_1707> G30rge: really? 
[05:52:27 CET] <G30rge> @duranda1_1707 : I have a situation where nb_samples == 1024, bytes per sample is 4 (fltp), channels is 2
[05:52:38 CET] <G30rge> linesize[0] == 8192
[05:52:45 CET] <G30rge> linesize[1] = 0
[11:13:09 CET] <durandal_1707> michaelni: ffv1 doesnt store color_range anywhere 
[11:53:21 CET] <atomnuker> durandal_1707: that's something than can be fixed actually, version 4 is still unstable so you can add a flag
[13:02:08 CET] <durandal_1707> so what is consensus versus adding color range to AVCodec?
[13:02:53 CET] <atomnuker> IMO I think it should be there and it should be an array (to indicate e.g. what ranges an encoder supports)
[13:03:06 CET] <JEEB> yup
[13:04:50 CET] <wm4> I'd prefer an array too
[13:08:21 CET] <jdarnley> What?  An array like luma min/max and chroma min/max?
[13:08:27 CET] <durandal_1707> that is sick
[13:08:46 CET] <durandal_1707> int should be enough
[13:08:49 CET] <atomnuker> lol no, an array of enums which map to luma/chroma min/max
[13:09:07 CET] <atomnuker> durandal_1707: the issue is that a single int isn't enough
[13:09:23 CET] <durandal_1707> 0 supports both
[13:09:45 CET] <atomnuker> sure you can treat the field as a bitmask to signal values but I think it should be treated the same as pixfmts
[13:10:01 CET] <durandal_1707> or you gonna add more ranges?
[13:10:18 CET] <durandal_1707> this complicares code a lot
[13:10:39 CET] <wm4> I'm only suggesting AVColorRange ranges[];
[13:10:52 CET] <atomnuker> that's exactly my concern, its a matter of time before someone with half a brain cell decidec for something like an alternative range for hdr
[13:11:06 CET] <wm4> but I'm not opposed to a flat AVColorRange value either to stop the bikeshedding lol
[13:11:10 CET] <atomnuker> where the top part is full but the bottom is still limited
[13:12:14 CET] <atomnuker> (technically in broadcast IIRC overshoots over 235 are allowed sparingly but not undershoots under 16 or whatever that was)
[13:14:14 CET] <JEEB> well broadcast is signalled limited range and we don't care if the values overshoot
[13:14:43 CET] <atomnuker> durandal_1707: if it complicates the code I wouldn't mind making the field a bitmask
[13:14:45 CET] <JEEB> I don't think those flags mean that you have to make sure your content is within that level if it is already flagged so
[13:15:07 CET] <JEEB> overshoot? it goes right through like it would in 99% of those darn processes
[13:15:14 CET] <atomnuker> e.g. color_range = AVCOL_RANGE_FULL | AVCOL_RANGE_LIMITED | AVCOL_RANGE_SHIT
[13:15:54 CET] <wm4> just make it an array
[13:16:08 CET] <wm4> a bit mask would require separate flag constants
[13:16:17 CET] <atomnuker> I really doubt that as bad as things might get in 50 years there'll be more than 32 different ranges
[13:17:10 CET] <kierank> atomnuker: well arguably HLG is already like that
[13:17:18 CET] <kierank> the range is kinda limited
[13:17:26 CET] <atomnuker> yeah, an array would make it pretty much identical to a pixfmt so it would be consistent with what we have
[13:18:32 CET] <atomnuker> there you go then, a reason for AVCOL_RANGE_KINDA_LIMITED to exist
[13:24:03 CET] <rcombs> AVCOL_RANGE_FUZZY
[13:26:26 CET] <JEEB> kierank: eh, I thought all those fancy HDR things follow limited range YCbCr and it's then the colorspace information that then leads to different handling
[13:26:38 CET] <JEEB> as far as something that cares about limited/full range goes it's either full or limited
[14:31:40 CET] <kierank> JEEB: afaik hlg uses some of the peaks
[14:58:22 CET] <durandal_1707> buahaha, enjoy more spam
[15:23:18 CET] <atomnuker> awesome
[19:53:58 CET] <cone-343> ffmpeg 03Paul B Mahol 07master:a0e4c41d086b: avfilter/vf_pseudocolor: add support for more formats
[20:47:37 CET] <durandal_1707> no more filters for you folks, you were all very evil this year
[20:59:48 CET] <BtbN> "I made git log to the first bad after this revision" he what?
[21:10:05 CET] <jkqxz> Er, what?  I'm not sure what the bug is now.
[21:14:23 CET] <BtbN> same
[21:25:25 CET] <BtbN> I have no idea what he's going on about. nvenc not being x264 is a bug now?!
[21:37:20 CET] <atomnuker> durandal_1707: did you run out of ideas?
[21:38:11 CET] <durandal_1707> atomnuker: you stole all ideas and atrac9, ruined my christmas
[21:38:45 CET] <atomnuker> I'm a generous person so I shall give you an idea
[21:39:52 CET] <durandal_1707> generic glsl shader filter?
[21:40:41 CET] <BtbN> Shadertoy as a filter
[21:41:07 CET] <atomnuker> nope, nope, those are mine and mine alone and will see the light of day once I finish my vulkan patchset
[21:41:08 CET] <jkqxz> With Vulkan, sure.  Please no OpenGL.
[21:41:41 CET] <durandal_1707> wtf?
[21:42:05 CET] <atomnuker> durandal_1707: we don't have enough generators
[21:42:39 CET] <atomnuker> for audio
[21:43:15 CET] <atomnuker> I think it would be great to have a rain / thunder generator
[21:43:31 CET] <atomnuker> which synthesized the effects for both proceduraly during init
[21:44:46 CET] <atomnuker> you could probably have one or two samples stored as tables and you'd manipulate them to generate different variations randomly
[21:45:24 CET] <durandal_1707> synths are beast on their own
[21:46:01 CET] <atomnuker> yeah, so just manipulate some existing samples, with time stretching, bandpassing, etc. to make variations of
[21:46:48 CET] <durandal_1707> for synths you need midi
[21:46:59 CET] <atomnuker> no, you don't
[21:48:02 CET] <atomnuker> I'm not talking about midi synth synth, just about general synthesis (e.g. a thunder is pretty easy to synthesise, look at how smoke is synth'd in video)
[21:49:55 CET] <durandal_1707> atomnuker: one could create special waves, but how to control them
[21:51:24 CET] <durandal_1707> and how to combine them?
[21:51:25 CET] <atomnuker> randomly
[21:51:36 CET] <atomnuker> how to combine them? mix 'em
[21:52:31 CET] <durandal_1707> atomnuker stole my christmas and new year
[21:53:13 CET] <durandal_1707> sox have its synth filter
[22:29:06 CET] <alevinsn> nevcairiel:  Not sure if you are around, but could you provide an example of a codec for which FF_CODEC_CAP_INIT_THREADSAFE isn't appropriate yet?
[22:30:28 CET] <wm4> any codec which hasn't it set could be affected and must be checked manually
[22:30:54 CET] <alevinsn> I get that, but what sort of thing should I be looking for?
[22:31:11 CET] <alevinsn> any modification to the AVCodecContext * that is passed in?
[22:31:33 CET] <wm4> no
[22:31:36 CET] <alevinsn> the argument that is passed in is an AVCodecContext * (to .init), not the AVCodec * object
[22:31:42 CET] <wm4> this is mostly about initializing global data
[22:31:51 CET] <wm4> like tables used for decoding or encoding
[22:32:01 CET] <alevinsn> got it
[22:32:14 CET] <alevinsn> so, some that aren't marked thread safe may very well already be
[22:32:36 CET] <wm4> yes
[22:32:43 CET] <durandal_1707> atomnuker: what literature you propose?
[22:32:45 CET] <wm4> but it'd not always easy to find out
[22:33:00 CET] <wm4> and those which are definitely affected must be fixed
[22:33:01 CET] <alevinsn> right, and difficult to test properly if you didn't do it properly
[22:33:18 CET] <wm4> either by moving the data into a context, or initing them with ff_thread_once
[22:33:40 CET] <alevinsn> or doing things differently if appropriate
[22:34:18 CET] <durandal_1707> you wrote decoder of some sort?
[22:34:40 CET] <alevinsn> no--but I was thinking about doing this, at least for the decoders/encoders that I use for my project
[22:35:08 CET] <alevinsn> wm4:  Once all codecs are made thread-safe, then what's the plan?
[22:40:17 CET] <wm4> alevinsn: remove the codec locking
[22:40:35 CET] <wm4> I believe this makes the "lock manager" useless
[22:40:51 CET] <wm4> (a thing which MS just implemented in their ffmpeginterop, for unknown reasons)
[22:40:58 CET] <alevinsn> right, but beyond that, how will it be ensured that new codecs are threadsafe on init and codecs that are merged in from libav?
[22:41:19 CET] <wm4> libav has the same ideas about this
[22:41:41 CET] <wm4> it's unlikely they will add new code that requires locking on init
[22:42:06 CET] <durandal_1707> or any code at all
[22:42:24 CET] <alevinsn> so, the basic idea, is, if any locking is necessary, move that into codec's init method, not do at the global level
[22:46:08 CET] <wm4> the basic idea is: never use global mutable data
[22:46:43 CET] <wm4> but if you do anyway (like "lazy" conversion of old code), use ff_thread_once()
[23:45:45 CET] <atomnuker> durandal_1707: also here's another idea - move the cng from being a codec to being a filter
[23:46:27 CET] <atomnuker> because as-is it just ignores all input and generates noise, which is what a filter generator ought to do
[23:47:17 CET] <durandal_1707> isnt that nicolas stuff?
[23:48:50 CET] <atomnuker> no? its very old
[23:49:32 CET] <atomnuker> durandal_1707: here's some literature on storm noise generation - http://www.planetz.com/Pulsar/files/modular/emulatingthunder.PDF
[23:51:17 CET] <atomnuker> actually nvm about the cng stuff, its a legit codec
[00:00:00 CET] --- Wed Dec 13 2017