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

[burek]

[00:03:30 CET] <SortaCore> ok done
[00:03:45 CET] <SortaCore> there is -j option, but I've not heard of the one you describe iive
[00:04:18 CET] <SortaCore> yea, configure is slow, but make without -j num_cores is half an hour or so
[00:04:36 CET] <jdarnley> The man page suggests -j without argument will spawn all jobs
[00:04:37 CET] <iive> the problem with -j is that you should specifiy a number and the optimal number is different for every different cpu
[00:05:18 CET] <SortaCore> I was recommended "number of real cores, not hyperthreaded"
[00:05:33 CET] <SortaCore> I use one less than that so the rest of my computer isn't slowed
[00:06:00 CET] <iive> imho, bad advice
[00:06:01 CET] <jdarnley> alias make="nice make"
[00:06:23 CET] <iive> yeh, nice is much nicer :D
[00:06:31 CET] <wm4> I guess GNU isn't making -j something the default because you can write makefiles that break with -j
[00:06:36 CET] <wm4> but who knows
[00:06:56 CET] <ubitux> -j auto would be nice though
[00:07:00 CET] <jdarnley> I also did: alias mean="nice -n-10"
[00:07:00 CET] <SortaCore> Chloe: https://pastebin.com/XLJ6GvVk
[00:07:04 CET] <ubitux> so you could at least document it in the documentation
[00:07:43 CET] <ubitux> right now if you want to document that you wrote a clean make, you have to give examples like make -j$(nproc), or another non portable alternative
[00:07:52 CET] <ubitux> or hardcode a random constant like 4 or 8
[00:08:01 CET] <ubitux> or do sth not copy/pastable
[00:08:03 CET] <ubitux> etc
[00:08:42 CET] <wm4> well ffmpeg could switch to a real build system
[00:08:49 CET] <iive> yeh, I'm also quite interested if there is somebody who really wants to spawn thousands jobs at once.
[00:08:52 CET] <jdarnley> I want many of these old tools to be updated to relatively modern standards.  make should detect cpu count, grep and ls should default to --color
[00:09:04 CET] <Chloe> SortaCore: stick a '#define _Atomic' on line 26 of ./compat/atomics/win32/stdatomic.h
[00:09:08 CET] <Chloe> then try make again
[00:10:16 CET] <iive> jdarnley: you mean, "grep and ls should default to --color when used to stdout"
[00:10:21 CET] <iive> like git does
[00:10:43 CET] <jdarnley> yeah, that is what --color does, I didn't say --color=always
[00:11:11 CET] <jdarnley> another silly option for silly tools that can have no argument
[00:11:19 CET] <iive> btw, I think my distro already does that, suspect it sets some env vars
[00:12:18 CET] <iive> yep, there is "LS_OPTIONS"
[00:12:50 CET] <jdarnley> I should change to that, then it would work when I use xargs
[00:12:59 CET] <jdarnley> or find
[00:14:12 CET] <SortaCore> Chloe: seems to be ok, but I'm getting warning C4024: 'atomic_compare_exchange_strong': different types for formal and actual parameter 3
[00:15:08 CET] <Chloe> it's just a warning, I believe it should still work
[00:15:17 CET] <mateo`> i will push the MediaCodec hwdevice type, do i need to bump the minor version of libavutil (+reset micro) ?
[00:16:09 CET] <SortaCore> I'm also getting a bunch of libavcodec\get_bits.h(308): warning C4101: 're_cache': unreferenced local variable, altho that's not yours
[00:16:11 CET] <jdarnley> New public facing feature?  Yes bump minor (and reset micro)
[00:16:18 CET] <SortaCore> just seems like something you guys can drop
[00:17:07 CET] <mateo`> jdarnley: thx
[00:17:17 CET] <SortaCore> also libavcodec/mpeg4videodec.c(386): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?)
[00:17:25 CET] <SortaCore> that seems like it might break something?
[00:19:52 CET] <mateo`> should i also bump minor in libavcodec in the second patch which enable the use of the hw device ctx ?
[00:20:19 CET] <Chloe> SortaCore: you dont have to repeat all the warnings
[00:20:23 CET] <Chloe> there will be a lot
[00:20:32 CET] <Chloe> just post a log if it fails or completes
[00:21:39 CET] <jdarnley> mateo`: not entirely sure.  I would say that two consecutive commits do not need two bumps but then I don't have to deal with users and APIs.
[00:23:20 CET] <SortaCore> it completes OK
[00:23:36 CET] <SortaCore> I'm posting the warnings that aren't to do with your code here so the other devs see it 
[00:25:04 CET] <Chloe> no need
[00:25:22 CET] <Chloe> can you run FATE?
[00:26:58 CET] <mateo`> jdarnley: first one is in libavutil and the second one is in libavcodec, it feels to me that I also need to bump libavcodec in the later
[00:27:20 CET] <jdarnley> ah, I guess yes in that case
[00:30:28 CET] <SortaCore> I dunno, how do?
[00:31:54 CET] <Chloe> SortaCore: make fate-rsync then make fate
[00:32:03 CET] <Chloe> not sure how rsync works on windows though
[00:34:39 CET] <SortaCore> says use 'make fate-rsync SAMPLES=/path/to/samples' to sync the fate suite
[00:35:09 CET] <mateo`> jdarnley: sorry to bother you with that again but since the second patch does add any new api but only make the decoder honor the avctx.hwctx field, is it considered a minor or micro bump ?
[00:35:22 CET] <mateo`> does *not*
[00:35:46 CET] <jdarnley> I don't know.
[00:36:18 CET] <Chloe> SortaCore: yeah, so just do make fate-rsync SAMPLES=fate
[00:36:26 CET] <Chloe> to download them all to the 'fate' folder
[00:36:31 CET] <jdarnley> I think the reasoning is: if a user might want to know whether a given feature exists they can look at the version number
[00:43:40 CET] <SortaCore> fate-rsync just error 127, but make fate seems to do stuff
[00:45:43 CET] <jdarnley> there is a subset of tests that can run without the samples.
[00:47:24 CET] <Chloe> it probably cant find rsync
[00:49:02 CET] <Chloe> SortaCore: here's a cygwin compiled rsync for windows https://www.itefix.net/content/cwrsync-free-edition
[00:49:46 CET] <Chloe> from what I see, you dl the zip, and stick the rsync command at the bottom of the included bat file and run it: rsync -vrltLW --timeout=60 --contimeout=60 rsync://fate-suite.ffmpeg.org/fate-suite/ fate-suite/
[00:50:12 CET] <Chloe> then you can just copy the fate-suite folder into the ffmpeg folder and run make fate SAMPLES=fate-suite
[00:50:53 CET] <Chloe> In the meantime, I'm trying to setup visual studio on a VM on an external drive, but it's looking like it'll take several hours to install
[00:51:22 CET] <nevcairiel> vs2017 installs pretty fast, if your internet isnt the bottleneck
[00:51:52 CET] <Chloe> nevcairiel: it's all downloaded, disk speed is the bottleneck
[00:52:07 CET] <Chloe> also lack of cpu
[00:52:33 CET] <Chloe> (in my case)
[00:54:36 CET] <Chloe> michaelni: which compiler are you using on ubuntu? 
[00:55:08 CET] <Chloe> oh. 4.8.5
[00:56:44 CET] <michaelni> Chloe, yes, its 4.8.5 as i mentioned in the mail :), and x86-64 in case it matters, suspect the cpu doesnt make a difference
[00:57:35 CET] <michaelni> i would guess the failure is related to some compatibility layer but i am just guessing
[00:58:38 CET] <michaelni> if theres something else you need, just say so
[01:00:44 CET] <Chloe> michaelni: I'm a bit confused to as why that cast wouldn't work. Do you know if `type _Atomic**` is different to `type * _Atomic *`?
[01:01:33 CET] <nevcairiel> of course it is,  one is a pointer to an atomic pointer, and one is an atomic pointer to a pointer
[01:01:50 CET] <nevcairiel> position matters equally as with const
[01:02:01 CET] <Chloe> ok that's what i thought
[01:02:52 CET] <nevcairiel> but the main problem as far as I can see is that the actual variable is not declared atomic, so even if you do this one cas call atomic, any other accessed would not be
[01:02:53 CET] <Chloe> so maybe a (atomic_intptr *) would work?
[01:03:37 CET] <cone-220> ffmpeg 03Aman Gupta 07master:e4d9f05ca799: lavu/hwcontext: add AV_HWDEVICE_TYPE_MEDIACODEC
[01:03:37 CET] <cone-220> ffmpeg 03Aman Gupta 07master:8bf4e6d3ce25: lavc/mediacodec: use AVMediaCodecDeviceContext hw_device_ctx if set
[01:03:37 CET] <cone-220> ffmpeg 03Matthieu Bouron 07master:f3cffd121b99: lavc/mediacodec_wrapper: factorize MediaCodec creation functions
[01:03:37 CET] <cone-220> ffmpeg 03Matthieu Bouron 07master:1f1207145a0f: lavc/mediacodec_wrapper: fix potential jni global reference leak
[01:04:04 CET] <Chloe> Right, I was wondering if I should have changed the head/current pointers to atomics, so I wouldnt need to cast
[01:04:23 CET] <Chloe> I don't really understand it to be honest
[01:05:04 CET] <nevcairiel> the entire algorithm for the link listed is overly convoluted because it inserts at the end, which makes it additionally complex
[01:07:13 CET] <michaelni> Chloe, i suspect _Atomic is not understood by that gcc, its also not in the compat layer. I get the same errors if i replace it by _FooBar
[01:08:23 CET] <Chloe> michaelni: ah, windows has the same issue of not understanding the _Atomic keyword, so just using the atomic_* types instead may fix both
[01:34:15 CET] <Chloe> nevcairiel: is there any benefit declaring the lists' heads globals as `static AVType **` opposed to `static atomic_intptr_t *`?
[01:34:26 CET] <Chloe> s/heads//
[03:06:54 CET] <daddesio> Is rate-distortion optimization just a search for the best quality/bitrate tradeoff or is it more involved than that? What does it mean for an encoder to "have RDO"? Wikipedia says it's (sometimes?) a Lagrange multipliers problem.
[03:07:02 CET] <daddesio> (sorry if it's not the best place to ask)
[03:08:25 CET] <Compn> what now
[03:08:34 CET] <Compn> which codec even has rdo ?
[03:09:11 CET] <daddesio> well, here's Wikipedia's supposed list of such codecs: https://en.wikipedia.org/wiki/Rate%E2%80%93distortion_optimization#List_of_encoders_that_support_RDO
[03:10:53 CET] <Compn> you might want to try asking in #x264
[03:11:01 CET] <Compn> and #x265
[03:11:36 CET] <Compn> not sure if our internal h264 encoder has rdo
[03:12:14 CET] <Compn> or read the h264 spec , if you are interested :)
[03:12:44 CET] <daddesio> My guess is that a "non-RDO" encoder tries to achieve the best quality without going over the target bitrate, and an "RDO" encoder tries to achieve the "best balance" of good quality and staying near the target bitrate. And that an "RDO codec" makes the latter algorithm very mathematically easy.
[03:13:56 CET] <Compn> well, it could mean different things in different codecs
[03:14:20 CET] <Compn> or maybe "rdo" just has another name and we use it
[03:14:26 CET] <jkqxz> To my mind RDO just means "compares costs for different modes after the entropy coder rather than before".
[03:15:43 CET] <jkqxz> A non-RDO mode a codec can do motion estimation using SAD or SATD and some guessed metric for what they mean.  In RDO mode, it actually checks how many bits each possibility will really take to use.
[03:17:18 CET] <jkqxz> So it is a technique for using the fewest bits you can to achieve a given quality, but takes a lot of time to do it because you need to do much more in each test.
[03:18:20 CET] <daddesio> Oh, I forgot about "target quality" instead of "target bitrate".
[03:19:24 CET] <jkqxz> Doing full RDO for something as complex as H.264 is prohibitively time-consuming.  The H.264 reference encoder uses RDO throughout (tuned to PSNR), and is absurdly slow because of it.
[03:19:36 CET] <daddesio> heh
[03:20:04 CET] <jkqxz> H.265 is even worse, and then there is AV1...
[03:20:57 CET] <daddesio> But there's no way that it can perfectly achieve the desired quality in the *minimal* possible number of bits. For all but the most trivial codecs, that would require testing all combinations of bitstreams, decoding them, and finding the first one that has the given quality.
[03:21:56 CET] <daddesio> So I guess RDO isn't applied to the entire codec, but to certain elements.
[03:21:57 CET] <jkqxz> Yes, it's generally per-macroblock.  They don't take into account how it changes the prediction for following blocks, or if they do it is in some approximated way.
[03:23:22 CET] <jkqxz> (With a per-symbol-adaptive arithmetic coder would indeed be pretty much completely impossible.)
[09:35:43 CET] <kurosu> RDO is indeed a lagrangian minimization of distortion under a rate constrain: distortion + lambda*rate
[09:36:02 CET] <kurosu> usually applied to mode and prediction selection
[09:36:31 CET] <kurosu> but you can do it in a lot of places (eg quantization), if your encoder can run that slow
[09:37:22 CET] <kurosu> motion estimation also somewhat uses that: typically, sqrt(lambda)*(sum of abs diff) + some_bit_evaluation(mv diff)
[09:38:21 CET] <kurosu> most s/w encoders use rdo in some places
[09:38:38 CET] <durandal_1707> can i get review for my sar aspect patches?
[11:27:08 CET] <durandal_1707> atomnuker: did you wrote any more code lines for atrac9 or adenoise?
[11:52:34 CET] <atomnuker> no, busy making lavc codec arrays static
[11:53:03 CET] <atomnuker> almost got it working too
[11:53:17 CET] <atomnuker> though after it I'll still need to do lavf and lavfi
[12:06:50 CET] <wm4> atomnuker: for lavf, don't forget about lavd
[12:07:47 CET] <atomnuker> oh yes, and lavd
[12:07:55 CET] <atomnuker> but that list is small enough to ignore
[12:08:46 CET] <wm4> what do you mean, ignore
[12:09:09 CET] <wm4> the trickiness is that in theory the formats list actually depends on whether lavd was loaded at runtime
[12:10:40 CET] <atomnuker> ignore == it'll be easy to convert
[12:11:10 CET] <wm4> so what do you plan to do for this?
[12:11:52 CET] <atomnuker> so lavd can optionally appear on runtime as a demuxer/muxer?
[12:12:02 CET] <wm4> yes
[12:12:39 CET] <wm4> via avdevice_register_all()
[12:12:47 CET] <wm4> don't know if that matters
[12:12:55 CET] <wm4> we could just always add them
[12:13:12 CET] <wm4> (and make lavf and lavd somehow depend on each other?)
[12:13:29 CET] <wm4> or lavd could be a separate list, that is added as an atomic pointer to lavf
[12:13:53 CET] <wm4> (still easier than list appending, just a trivial atomic pointer load/store of the array pointer)
[12:13:54 CET] <atomnuker> maybe just add it as a corner case in av_format_next or whatever the equivalent to av_codec_next is
[12:14:18 CET] <wm4> yes, so it'd go over two arrays
[12:14:38 CET] <atomnuker> wait, can every lavd device appear as a separate demuxer/muxer?
[12:14:47 CET] <wm4> anyway that was always a pain point when we discussed converting those lists to arrays
[12:14:57 CET] <wm4> "can"
[12:15:04 CET] <atomnuker> will?
[12:15:13 CET] <wm4> every lavd device is a libavformat muxer/demuxer, so yes
[12:15:26 CET] <wm4> there's no way to use lavd in another way
[12:17:35 CET] <atomnuker> then yeah, 2 arrays
[12:17:55 CET] <atomnuker> maybe I'll add a "avformat_is_device" too
[12:18:02 CET] <atomnuker> unless there's already one
[12:18:35 CET] <atomnuker> that's how I do things for lavc, since I get 2 separate decoder and encoder lists and use av_codec_is_decoder to figure out which list to use
[12:19:45 CET] <wm4> huh, isn't av_codec_next just a single list?
[12:19:51 CET] <wm4> API wise
[12:21:16 CET] <atomnuker> hm, you're right, this would break the api
[12:21:39 CET] <atomnuker> I guess the register function will populate ->next to avoid breaking that
[12:22:44 CET] <wm4> ->next is private
[12:23:12 CET] <wm4> av_codec_next() is the iteration function
[12:23:31 CET] <wm4> is just returns both decoders and encoders
[12:23:38 CET] <atomnuker> I don't need it then, I'll just convert lavc to not use ->next (used 1 or 2 times in utils.c)
[12:23:52 CET] <atomnuker> if its private can I remove it directly without deprecation?
[12:24:07 CET] <atomnuker> (still in the ABI unstable period)
[12:25:07 CET] <wm4> yes
[12:25:13 CET] <wm4> even without ABI bump
[12:25:42 CET] <wm4> apropos ABI fields, did the mess in AVFormatContext (or was it AVStream) fixed yet?
[12:25:47 CET] <wm4> +get
[12:26:08 CET] <durandal_1707> atomnuker: why it takes that so long for you?
[12:27:04 CET] <wm4> seems like it did, but this note is outdated now:
[12:27:05 CET] <wm4>      * Internal note: be aware that physically removing these fields
[12:27:05 CET] <wm4>      * will break ABI. Replace removed fields with dummy fields, and
[12:27:05 CET] <wm4>      * add new fields to AVStreamInternal.
[12:29:28 CET] <atomnuker> durandal_1707: I've been in a convention for the last 5 days, I'm not able to work on many things at once but on one
[12:30:03 CET] <atomnuker> thankfully I'm flying back today, if british airways don't screw up
[12:30:56 CET] <durandal_1707> atomnuker: than quit your job as programmer and pick something else
[12:32:30 CET] <atomnuker> I like my job as a programmer
[12:33:53 CET] <durandal_1707> is ffplay maintainer here?
[14:21:58 CET] <cone-495> ffmpeg 03Martin Vignali 07master:ee2dfa34a25e: libavcodec/magicyuvenc : fix warning
[15:34:37 CET] <daddesio> kurosu: When you say it's a Lagrangian minimization, do most (or any?) encoders actually pose it as a Lagrange multipliers problem and try e.g. solving for (<compression parameters>, lambda)?
[15:46:22 CET] <atomnuker> yes
[15:46:38 CET] <atomnuker> the encode with a particular set of parameters with a given lambda
[15:47:20 CET] <atomnuker> after encoding they calculate distortion using some function of input and output, multiply it by the cost and then multiply it by the lambda
[15:48:25 CET] <atomnuker> hence why its called rate (lambda) distortion optimization
[15:49:16 CET] <atomnuker> the encoder picks the set of parameters which had the least cost so filtering out the obviously bad choices saves time
[15:50:21 CET] <atomnuker> lambda gets updated at the end of the encoding process though cost_for_frame / specified_cost_per_frame (bps / packets per second)
[15:50:34 CET] <atomnuker> *through lambda =
[16:08:02 CET] <daddesio> I assume f(<compression parameters>) is the cost in bits (which we're optimizing) and g(<compression parameters>) is some quality metric (e.g. PSNR) which we're constraining to a target value.
[16:08:43 CET] <daddesio> since f and lambda*g have to have the same units, then lambda has units of bits/quality?
[16:09:02 CET] <daddesio> Unless you optimize for quality subject to a bitrate constraint, in which case lambda has units of quality/bits.
[16:11:10 CET] <kurosu> There's a lot of empirical stuff in there: lambda for instance depends on your quantization parameter and some hierarchical stuff (e.g. intra vs Nth level of e.g. pyramid frame referencing)
[16:11:40 CET] <kurosu> you could try to reach/enforce some of the goals (whether rate or distortion)
[16:11:56 CET] <kurosu> but generally you have a first guesstimate that is approximately correct
[16:12:10 CET] <kurosu> and you refine as you encode
[16:12:19 CET] <daddesio> So I'm guessing that 99% it's just some "search" for the best compression parameters as opposed to algebraically solving for it.
[16:12:24 CET] <daddesio> s/99%/99% of the time/
[16:12:48 CET] <kurosu> completely, all the more since it's hardly perfectly "modelized"
[16:13:22 CET] <kurosu> though audio codecs are a different beast
[16:13:58 CET] <daddesio> Yeah, I was about to say that a lot of problems in audio are (matrix) least squares problems which can be solved directly.
[16:14:06 CET] <atomnuker> kurosu: wut? lambda doesn't depend on your qp, your qp depends on lambda
[16:14:31 CET] <atomnuker> well it does, but indirectly
[16:15:09 CET] <kurosu> I think you have a few encoders to look from to see which comes first in that chicken and egg problem
[16:15:32 CET] <atomnuker> a few encoders?
[16:16:02 CET] <atomnuker> also distortion can be modeled perfectly (or to a good enough degree), even for pvq
[16:16:57 CET] <atomnuker> the plan was to have that in av1 but eh, kinda difficult when the encoder's moving underneath you
[16:18:01 CET] <kurosu> well of course there are a few problems you can model through distortion only and find "optimal" parameters (in the sense of your minimization and distortion)
[16:18:34 CET] <kurosu> but in the end, neither the distortion from the encoder viewpoint means anything, nor your simulation of bitrate (unless you actually encode)
[16:19:04 CET] <kurosu> e.g. do you update entropy cost for every bit you'd have to encode when you *test*
[16:19:11 CET] <kurosu> as for qp/lambda: https://git.videolan.org/?p=x264.git;a=blob;f=encoder/analyse.c;hb=ba24899b0bf23345921da022f7a51e0c57dbe73d#l271
[16:19:18 CET] <kurosu> but you can of course find the reverse
[16:25:21 CET] <kurosu> or https://hevc.hhi.fraunhofer.de/HM-doc/_t_enc_slice_8cpp_source.html#l00145
[16:25:50 CET] <kurosu> (not saying these examples are to follow or they are the best, just that it's been done that way)
[16:27:08 CET] <atomnuker> >using a reference hxxx encoder as an example
[16:29:19 CET] <daddesio> lol
[16:29:39 CET] <wm4> "Int" "Double" this source must be full of fun
[16:31:16 CET] <kurosu> your hxxxx is a strawman here, because I could be as derisive using pvq, but I was trying to have a discussion
[16:31:22 CET] <kurosu> well, whatever
[16:43:34 CET] <atomnuker> kurosu: you can't mock pvq, it is a special type of perfection which can be improved
[18:24:05 CET] <durandal_1707> atomnuker: how should notes/tones be entered for synth filter?
[18:25:43 CET] <cone-627> ffmpeg 03wang-bin 07master:dc08caa8f727: configure: fix probing armv6zk
[18:34:34 CET] <atomnuker> durandal_1707: for the storm/rain noise generator? randomly, use the av_lfg
[18:37:33 CET] <durandal_1707> atomnuker: thats nonsense
[18:37:54 CET] <durandal_1707> and how am i supposed to generate rain?
[18:38:50 CET] <atomnuker> a single sample stretched by a random factor + amplified by a random factor
[18:39:00 CET] <atomnuker> the only issue would be mixing them
[18:44:06 CET] <cone-627> ffmpeg 03Paul B Mahol 07master:d29f784a54f2: avfilter/vf_overlay: add premultiplied alpha mode
[19:10:25 CET] <ubitux> should i use AVFrame.data[3] to hold a subtitle struct (+its rectangle) instead of attempting to abuse the ref'ed extended_buf?
[19:11:26 CET] <ubitux> well, i'll give it a try in the next days
[19:13:12 CET] <wm4> sounds cleaner at least
[19:33:02 CET] <atomnuker> ubitux: for subtitles in avframes? awesome
[19:34:22 CET] <JEEB> <3
[19:38:07 CET] <ubitux> atomnuker: yeah, i'm back in the game for like at least 2 weeks
[19:38:41 CET] <ubitux> so i'm rebasing and reworking my previous attempt at subtitles in avframe
[19:38:58 CET] <ubitux> initial implementation was abusing the extended_buf to stick the "rectangles"
[19:39:17 CET] <ubitux> it was the best i could come up with wrt shared allocation mechanism between a,v & s
[19:39:40 CET] <ubitux> but in the end, using data[3] as if it was a different beast like hwaccel might actually be a better way
[19:40:17 CET] <ubitux> i wonder why i havent done that in the first place, but let's hope i was just stupid and there was no good reason
[19:40:24 CET] <ubitux> i'll figure it out soon enough
[19:42:12 CET] <Chloe> atomnuker: wm4 said you were doing something with the linked lists which used atomics too?
[19:46:27 CET] <atomnuker> no, I'm removing the linked lists
[19:52:36 CET] <durandal_1707> ubitux: use extended_data
[19:52:58 CET] <ubitux> that's what i did
[19:53:10 CET] <ubitux> it holds the rectangle
[19:53:21 CET] <ubitux> +s
[19:53:51 CET] <ubitux> damn my wip is from last year
[19:54:04 CET] <ubitux> http://ffmpeg.org/pipermail/ffmpeg-devel/2016-November/202152.html
[20:30:24 CET] <Chloe> atomnuker: so I guess there's no point me trying to fix the atomics there? just removing them is fine?
[20:36:10 CET] <atomnuker> I think, that avpriv_cas function is only used during registration afaik
[20:39:03 CET] <durandal_1707> can i get review
[21:08:32 CET] <Chloe> atomnuker: yes it is. Ping me when you've got a patch and I'll resubmit a fixed ver. of mine. 
[21:11:00 CET] <JEEB> durandal_1707: I wanted to poke the SAR from link thing but when I last checked it it lacked any explanation on why so as I didn't have enough info on lavfi I just couldn't say yay or nay :P
[21:11:08 CET] <JEEB> as for the range stuff I haven't had time to test it
[21:14:13 CET] <durandal_1707> JEEB: its invalid to set sar or anything on inlink
[21:15:31 CET] <JEEB> ok, makes sense then
[21:15:40 CET] <JEEB> and makes me wonder how it wasn't noticed so far :P
[21:25:55 CET] <durandal_1707> michaelni: what you think about querying combination of pix fmt and color range and other stuff what some other clueless devs mentioned  on ml?
[21:33:28 CET] <durandal_1707> atomnuker: how is removing linked list going?
[22:41:48 CET] <michaelni> durandal_1707, i dont know if its needed or avoidable
[22:53:47 CET] <JEEB> &25
[22:57:17 CET] <durandal_1707> michaelni: it fails because its experimental to do mpeg color range
[22:57:56 CET] <durandal_1707> michaelni: how could you not get it
[22:58:30 CET] <durandal_1707> michaelni: please remove experimental from mjpeg encoding
[22:58:50 CET] <durandal_1707> michaelni: or i will do it
[22:59:46 CET] <durandal_1707> looks like everybody had major lobotomy
[23:00:48 CET] <atomnuker> go ahead and remove it then
[23:39:07 CET] <michaelni> durandal_1707, before your patchset the code converts to jpeg color range, after the patch it fails trying to use the experimental color range. Thats all with the same command line, it should not use the experimental range unless requested / enabled
[23:40:29 CET] <michaelni> its just a simple dv -> jpeg convertion
[23:43:42 CET] <durandal_1707> michaelni: thats not doable andyou know it
[23:47:10 CET] <michaelni> it works currently, so it is doable. I dont know how to best do it without yuvj, but it certainly can be done. Maybe its easier to remove the feature but is this the only feature we would not be able to have anymore then?
[23:48:04 CET] <michaelni> theres some code to do special handling for the jpeg experimental case, it may be possible to update this?
[23:48:54 CET] <michaelni> avfilter will need to negotiate color_range like pix_fmt so naively i would assume that the output from avfilter would be the non experimental jpeg range
[23:56:59 CET] <Compn> are we going to add -color to ffmpeg command line ? to choose 709 vs 601 ?
[23:57:15 CET] <Compn> and then double the fate tests with both of these color ranges ?
[23:57:37 CET] <Compn> would that make it easier than specifiying each pixfmt ?
[00:00:00 CET] --- Sun Dec 17 2017