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

[burek]

[00:00:10 CEST] <dualz> It's been 10 years since I've written C, I have a noob question about compiling 
[00:00:32 CEST] <dualz> I made my own filter, now I want to change things, I don't want to recompile all of ffmpeg
[00:00:38 CEST] <dualz> every time I do it
[00:00:39 CEST] <michaelni> kierank, everyone with an account on the server should have access, durandal_1707 should have access
[00:01:08 CEST] <kierank> Q: who has access. A: everyone who has access...
[00:01:26 CEST] <dualz> is there a way I can make myfilter.o and link the other existing objects
[00:02:43 CEST] <michaelni> (everyone please forive me the highlitging of you) kierank: michael,compn,cehoyos,reimar,beastd,llogan,ubitux,durandal,nevcairiel,daemon404,jamrial,martinvignali,thilo
[00:02:58 CEST] <kierank> thx
[00:03:14 CEST] <kierank> michaelni: can you document this somewhere, so people can contact them
[00:04:26 CEST] <jkqxz> dualz:  If you change config (by rerunning configure) then you have to rebuild everything.  If config hasn't changed then running make should only rebuild files which actually need to be.
[00:04:34 CEST] <michaelni> kierank, it could probably be put in maintainers i guess
[00:05:25 CEST] <dualz> that's probably why I didn't notice, because I didn't ./configure before make
[00:05:45 CEST] <atomnuker> michaelni: do I have access? previously I've had to complain to people periodically to upload new stuff there
[00:09:26 CEST] <michaelni> atomnuker, i dont think you have an account on that box. 
[00:12:39 CEST] <michaelni> is there someone who wants to help with maintaining the fate samples / upload files for others (not just ones own samples) and who has no access currently ? 
[00:12:57 CEST] <michaelni> atomnuker ?
[00:17:40 CEST] <atomnuker> sure, I'll help, I can see the need for some aac pce files soon for tests
[00:19:55 CEST] <michaelni> atomnuker, send me your public ssh key or do you want to use the same as for git ?
[00:23:08 CEST] <jkqxz> jamrial:  Something like <https://0x0.st/s6bq.diff>?  (Only does read.)
[00:28:54 CEST] <atomnuker> michaelni: same one as git
[00:29:01 CEST] <jkqxz> Without actually doing the parsing it won't be possible to avoid passthrough (av1_metadata) magically fixing up any incorrect cases.  That's probably fine, I guess.
[00:32:06 CEST] <jamrial> jkqxz: that check bit by bit of the frame header and the redundant frame header looks kinda slow
[00:33:00 CEST] <jamrial> ideally it would check field by field by storing a copy of the filled AV1RawFrameHeader. but that's probably even slower
[00:35:05 CEST] <jkqxz> The frame header shouldn't be too large, though it can easily be optimised by checking (bits_left < 24 ? bits_left : 24) or something bits at once.
[00:35:22 CEST] <jamrial> also, can't you pass the unit's avbufferref instead of allocating a copy of the frame header in the priv context?
[00:36:41 CEST] <jkqxz> Filling an AV1RawFrameHeader for comparison is painful because you then always need to keep a copy of the previous reference state for the second parse to work.
[00:37:05 CEST] <jamrial> alright
[00:38:26 CEST] <jkqxz> Yeah, I started to write with a bufferref but it messes with the write case because you don't yet have a bufferref there.
[00:38:40 CEST] <jkqxz> (It's still writing into the temporary buffer.)
[00:39:21 CEST] <jkqxz> Maybe there is a nicer way to make that work...
[11:51:15 CEST] <funman> ttps://git.ffmpeg.org/gitweb/ffmpeg.git/commit/4241e44a3c0193d182d3d614e7b4977c00c0225c misses a VERSION bump
[11:51:19 CEST] <funman> +h
[11:53:50 CEST] <kierank> funman: LIBAVUTIL_VERSION_MICRO 101 -> 102?
[11:55:49 CEST] <funman> I don't know what MICRO means
[11:56:29 CEST] <durandal_1707> big MICRO optimization
[11:57:53 CEST] <kierank> afaik micro needs bumping
[11:57:54 CEST] <funman>  Bug fixes not affecting the API increment the patch version, backwards compatible API additions/changes increment the minor version
[11:58:08 CEST] <kierank> ok maybe not then
[11:59:15 CEST] <January> kierank: also, it's maybe missing a changelog entry, not sure if it's significant enough to warrant one
[12:01:43 CEST] <kierank> January: might as well
[12:01:57 CEST] <kierank> January: I think we should push a hotfix
[12:02:01 CEST] <kierank> when you are sure it's correct
[12:03:07 CEST] <January> 'sure it's correct', what do you mean?
[12:05:31 CEST] <kierank> when you're sure you've bumped the right version
[12:07:20 CEST] <January> It's a MINOR bump with a MICRO reset in lavu, then nothing else in API changes later, right?
[12:08:34 CEST] <kierank> don't know, ask someone who knows like durandal_1707 
[12:10:19 CEST] <January> durandal_1707: ?
[12:12:16 CEST] <durandal_1707> January: just bump minor of lavu (or also lavc) and reset micro to 100
[12:12:52 CEST] <atomnuker> yep, that's what you
[12:13:20 CEST] <atomnuker> lavu yes, but no need for that in lavc, a micro bump would be fine there
[12:14:19 CEST] <January> michaelni: what's your setup for testing qemu architectures? ubuntu images on them?
[12:14:45 CEST] <funman> should be just lavu
[12:16:54 CEST] <January> atomnuker: why bump lavc at all? dont think there were any API changes?
[12:18:42 CEST] <nevcairiel> micro bumps are bnasically done on feelings, since the behavior of lavc was changed one might argue a bump might be appropriate, but considering lavu is going to get bumped at the same time anyway, usually you just wouldnt bother
[12:19:17 CEST] <atomnuker> yep, pretty much
[12:28:00 CEST] <cone-169> ffmpeg 03Josh de Kock 07master:f9d4126f2882: lavu: bump version, add Changelog entry
[12:30:14 CEST] <durandal_1707> oh no!, you bumped major
[12:30:59 CEST] <January> ?
[12:31:06 CEST] <January> wait did i
[12:31:22 CEST] <atomnuker> haha he made you look
[12:31:43 CEST] <atomnuker> oh wait, he had me too
[12:32:02 CEST] <January> :c
[13:34:12 CEST] <michaelni> January, no images, IIRC its based on some Emdebian packages installed on a ubuntu box but emdebian is dead since 4 years so its probably not a good startpoint for a new setup
[13:36:15 CEST] <michaelni> thats for the "environments" qemu itself i have multiple and much newer on the box
[16:27:44 CEST] <durandal_1707> why you guys ignore xvc?
[16:32:56 CEST] <nevcairiel> proprietary codec with oddball design, i doubt it'll ever get used anywhere
[16:36:31 CEST] <durandal_1707> nevcairiel: it is open-source
[16:37:25 CEST] <nevcairiel> its not
[16:37:31 CEST] <nevcairiel> it may be visible source, but its not open-source
[16:38:02 CEST] <funman> https://github.com/divideon/xvc/blob/master/LICENSE ?
[16:38:25 CEST] <nevcairiel> they have all sorts of licensing shit on their website, you should read it =p
[16:39:03 CEST] <durandal_1707> nevcairiel: on their website they also claim to be better than AV1 =p
[16:39:15 CEST] <nevcairiel> they also want you to pay them
[16:39:30 CEST] <durandal_1707> where is that written?
[16:39:44 CEST] <nevcairiel> and their entire design of "if we get a patent claim against a feature that we cant solve, we'll just remove the feature and break all your files" is just insane
[16:39:52 CEST] <nevcairiel> https://xvc.io/license/
[16:40:01 CEST] <durandal_1707> yea...
[16:41:41 CEST] <nevcairiel> if its truely LGPL t hat means I can use it commercially quite easily, but if their website is to be trusted, commercial use wants money
[16:41:43 CEST] <nevcairiel> so which is it
[16:42:11 CEST] <gnafu> It's clearly been made by people who don't understand licensing, software or patent.
[16:42:38 CEST] <gnafu> I appreciate the focus on technical excellence without regard to the legal side of things, but then they try to make legal claims that just don't work in the present world.
[16:42:39 CEST] <nevcairiel> which would be funny because patent protection is like one of their main selling points
[16:43:21 CEST] <gnafu> It could be the best codec in the world, generations ahead of anything else, and it would still be unusable in any commercial setting.
[16:43:53 CEST] <gnafu> So maybe we'll start seeing scene releases using xvc, but not much else ;-).
[17:42:56 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:bc940cf95c3b: avfilter/vf_datascope: fix rgba mapping for oscilloscope filter output
[17:56:33 CEST] <BtbN> I somehow have doubts about it being miles ahead of everything else
[18:11:14 CEST] <pkv> @peloverde thanks very much for your input; I was preparing to send an updated patch when you sent your review, which passes fate. I have one issue though with one of the vectors which will require an updated ref, not sure how to proceed.
[18:11:38 CEST] <cone-973> ffmpeg 03Baptiste Coudurier 07master:8c733013af47: avformat/mxfenc: simplify dnxhd handling and add more flavors
[18:12:38 CEST] <JEEB> pkv: reference file or just the reference result?
[18:13:00 CEST] <JEEB> if the reference file was incorrect to begin with, then it'll have to be re-uploaded as fixed with a different file name
[18:13:45 CEST] <pkv> it's this vector: al_sbr_cm_48_5.1.mp4 , pce is FRONT: 0-SCE[0] 1-CPE[0] 2-CPE[1] ;  it is decoded atm as '5.1' = AV_CH_LAYOUT_5POINT0_BACK ; but with my patch it is decoded as FL+FR+FC+FLC+FRC+LFE which better corresponds to PCE
[18:15:22 CEST] <pkv> @JEEB this entry : fate-aac-al_sbr_hq_cm_48_5.1: REF = $(SAMPLES)/aac/al_sbr_hq_cm_48_5.1_reorder.s16 
[18:16:30 CEST] <pkv> so I guess this is the file which needs update ? I am unfamiliar with that stuff
[18:16:35 CEST] <pkv> as you can guess
[18:17:30 CEST] <nevcairiel> we cant change reference files, because that would break old tests, but if really needed we can add a second one with a different name (ie _v2 or such)
[18:19:16 CEST] <pkv> these refs files would be the output of ffmpeg command used in test ? or are they produced with a reference decoder ?
[18:19:36 CEST] <JEEB> would have to see into the history for those unfortunately :<
[18:19:53 CEST] <JEEB> and yea, unfortunately those .s16 references are there instead of per-frame hashes being used
[18:19:53 CEST] <pkv> the ref was changed 
[18:20:05 CEST] <pkv> lemme find the commit
[18:20:30 CEST] <JEEB> well, history of FATE-SUITE which unfortunately probably isn't versioned :<
[18:21:18 CEST] <pkv> the test was added by peloverde here: https://github.com/FFmpeg/FFmpeg/commit/46ef355c652fed8984a5c92e961b78282d9ebb2c#diff-77afd26cdbf51e4fed4b802a9bc93f35
[18:21:37 CEST] <pkv> and he updated the ref later: https://github.com/FFmpeg/FFmpeg/commit/37bed6ff3f7f48e25d1e0c3efdf8cbb90bcf9514#diff-77afd26cdbf51e4fed4b802a9bc93f35
[18:23:00 CEST] <JEEB> I wonder if framehash could be used instead since for a lot of tests that's being used to check exactness
[18:23:10 CEST] <JEEB> and the references would be in the code repo then
[18:23:51 CEST] <JEEB> I mean, sure - it would have a lot of frames because it's audio, but it would notice nonexactness in a similar way if this is an exact example
[18:24:04 CEST] <JEEB> if this calculates some sort of % against something then it won't work of course
[18:25:40 CEST] <pkv> what's this s16 format ? those are raw pcm_s16 I assume ?
[18:26:06 CEST] <nevcairiel> probably yes
[18:26:31 CEST] <JEEB> yup
[18:27:37 CEST] <pkv> thanks @JEEB @nevcairiel
[18:34:29 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:d94d2527317d: avfilter/vf_waveform: add gratcicule to rgb input
[18:34:30 CEST] <cone-973> ffmpeg 03Paul B Mahol 07master:22d6d9164944: avfilter/vf_waveform: abort early if there are no components to show
[18:54:04 CEST] <peloverde> pkv: With current git master I'm seeing FL+FR+FC+LFE+FLC+FRC
[19:01:09 CEST] <pkv> @peloverde: :facepalm: you're right, I must have mixed the binaries . Sorry for the trouble and thanks again !
[19:25:23 CEST] <January> michaelni: I have now setup a mips qemu with debian stretch, but I'm encountering all sorts of header issues with the default toolchain. Are you running a weird configure or...? I have all the system -dev packages
[19:28:03 CEST] <JEEB> January: if there's a mips FATE system you could check its configure
[19:28:16 CEST] <JEEB> doesn't seem so...
[19:28:22 CEST] <JEEB> at least ctrl+F on http://fate.ffmpeg.org/
[19:28:26 CEST] <JEEB> gives nothing
[19:36:17 CEST] <philipl> BtbN: in nvdec_decoder_free, we don't push the context before calling destroy. Is that a bug?
[19:36:33 CEST] <philipl> I happened to run under cuda debug tools (for my deinterlacer) and it called it out
[19:36:44 CEST] <BtbN> probably, yes
[19:38:12 CEST] <philipl> I adjusted it and things seem happy.
[19:44:34 CEST] <philipl> BtbN: https://github.com/philipl/FFmpeg/commit/2d0ee127be14f44df19790d3aab5b551319f4a62
[19:45:03 CEST] <BtbN> ok
[19:45:20 CEST] <cone-973> ffmpeg 03Philip Langdale 07master:2d0ee127be14: avcodec/nvdec: Push the context before destroying the decoder
[19:48:04 CEST] <durandal_1707> ubitux: did you see that cube parsing patch on ml?
[19:58:16 CEST] <cone-973> ffmpeg 03James Almer 07master:78f04843bf32: doc/APIchanges: add entry for AV_FRAME_DATA_S12M_TIMECODE
[19:59:12 CEST] <January> michaelni: can you re-upload https://0x0.st/s6ap.nal as fate/h264/crew_cif.nal (it's a fixed file, the test hasnt been committed yet)
[21:23:00 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:66974311b1da: avfilter/show_info : add print of color information (range, color_primaries, color_trc, colorspace)
[21:23:01 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:3db33b446f3c: swscale/utils : simplify unscaled initial test for float pixfmt
[21:23:02 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:26bf4a40507d: swscale/unscaled : add grayf32 le to be
[21:23:03 CEST] <cone-973> ffmpeg 03Martin Vignali 07master:156120fcf8fa: swscale/swscale_unscaled : rename packed_16bpc_bswap
[21:43:21 CEST] <michaelni> January, crew_cif.nal uploaded
[21:43:47 CEST] <cone-973> ffmpeg 03James Almer 07master:87588caf8cff: Revert "avcodec/decode: copy the output parameters from the last bsf in the chain back to the AVCodecContext"
[21:47:42 CEST] <BBB> atomnuker: did you make progress on rewriting the multisymbol coder in dav1d? or not really interested?
[23:15:30 CEST] <uartie> Is there a way to tell ffmpeg (e.g. via command-line flag) to abort/exit non-zero if hw initialization fails instead of silently falling back to software mode?
[23:15:57 CEST] <cone-973> ffmpeg 03Michael Niedermayer 07master:203ccb874699: avcodec/msrle: Check that the input is large enough to contain a end of picture code
[23:15:58 CEST] <cone-973> ffmpeg 03Michael Niedermayer 07master:3cc3cb663bf3: avutil/integer: Fix integer overflow in av_mul_i()
[23:40:31 CEST] <cone-973> ffmpeg 03Marton Balint 07master:b02490a49700: avcodec/libx264: remove FF_CODEC_CAP_INIT_THREADSAFE flag
[23:41:47 CEST] <atomnuker> BBB: with the speed you're writing simd at you could probably rewrite it in 5 minutes
[23:42:22 CEST] <BBB> I doubt that&
[23:46:05 CEST] <BBB> apart from that being highly unlikely, there is also some goal of having multiple people involved in their relative fields of expertise. I know very little about arithmetic coding, and youve actually written one of those for the ff daala decoder
[00:00:00 CEST] --- Thu Oct 25 2018