[01:15:44 CEST] <cone-965> ffmpeg 03Timo Rothenpieler 07master:665c05f7cb70: configure: Fail if CUDA enabled but not found [01:48:44 CEST] <BtbN> wow, merging even a single trivial commit is a pain. [01:59:28 CEST] <jamrial> where? [02:08:05 CEST] <BtbN> Already sorted it, cherry-picking was a bit easier than merging. [02:08:22 CEST] <BtbN> Want to mess with this a bit: https://git.libav.org/?p=libav.git;a=commit;h=07a844f32ebb78503981df017fa3eb... [02:09:23 CEST] <nevcairiel> merging is hard because it requires everything to be merged in order [02:09:30 CEST] <nevcairiel> getting single commits, thats what cherry-pick is for [02:09:53 CEST] <BtbN> Pushing that single one would mess with the merges though? [02:38:50 CEST] <BtbN> Great: "In the current version, the cuda context MUST be created from a D3D device, using cuD3D9CtxCreate function." [02:38:54 CEST] <BtbN> So much about that [02:41:46 CEST] <BtbN> http://docs.nvidia.com/cuda/video-decoder/ says otherwise... so the docs in their headers are outdated i guess? oO [02:42:21 CEST] <jamrial> BtbN: you can send a patch based on a libav commit to the ml for review and apply it. once it comes out in the merge queue it will simply get no-op'd [02:42:49 CEST] <BtbN> I primarily want this because it gives downloading of CUDA frames. [02:43:17 CEST] <BtbN> I'm fine with keeping it in my own branch for now. [02:43:36 CEST] <BtbN> Those two patches are probably somewhat controversial [05:03:36 CEST] <cone-192> ffmpeg 03Michael Niedermayer 07master:8f2a1990c06d: avcodec/diracdec: check bitstream size related fields for overflows [08:10:05 CEST] <midgetspy> Could somebody please do me a favor and forward http://ffmpeg.org/pipermail/ffmpeg-devel/2016-March/192207.html to the thread author (me, nic@wolfeden.ca)? I mistakenly thought I'd receive replies to my thread without being subscribed to the list, now I've subscribed but I can't figure out how to reply to that thread without having received the message originally. Thanks. [10:15:58 CEST] <cone-702> ffmpeg 03Matthieu Bouron 07master:308d3ed5aa3a: lavc/mediacodec: use ternary operator to set slice-height value [10:32:00 CEST] <Gramner> midgetspy: click on the e-mail address mailto link at the top of that page to reply with the correct headers [10:53:20 CEST] <cone-702> ffmpeg 03Paul B Mahol 07master:ff982e02b547: avcodec: add dca core extraction bsf [10:56:32 CEST] <nevcairiel> durandal_1707: you should really wait until someone reviews your code before pushing it, its only been about half a day and its the easter holidays... [10:57:06 CEST] <durandal_1707> its trivial code [10:57:44 CEST] <durandal_1707> jamrial have tested it [10:58:32 CEST] <durandal_1707> so only name can be changed if you prefer something else... [11:51:26 CEST] <ethe> michaelni: coc looks fine now [12:17:27 CEST] <JEEB> wow [12:17:43 CEST] <JEEB> just noticed the dict API change [12:18:59 CEST] <Mavrik> The one with duplicate key support? [12:22:27 CEST] <JEEB> yeah, or well the thread about it [12:23:04 CEST] <JEEB> > someone voices concerns > still pushed purely based on time (Ž4@) [12:23:56 CEST] <Mavrik> Yeah that's... fun. [12:24:10 CEST] <Mavrik> I'm now looking at the mediacodec patch... and I see much fun with AllWinner and MediaTek crap in the future. [12:24:15 CEST] <JEEB> yeah [12:24:19 CEST] <JEEB> I chuckled when I saw that [12:25:10 CEST] <nevcairiel> thats why mediacodec is crap [12:25:14 CEST] <nevcairiel> its api gets violated so much [12:25:40 CEST] <JEEB> also how things fail is completely dependant on the layer implementing it [12:25:48 CEST] <Mavrik> I think it's quite telling about the skill of Google devs that we got API to check for number of HW decoders in Android N :P [12:26:24 CEST] <JEEB> I totally understand why things have their own profile/level checks before passing stuff to the hwdec at all [13:30:26 CEST] <ubitux> mmh [13:30:39 CEST] <ubitux> i'm thinking of using av_codec_get_pkt_timebase() in lavc/ccaption_dec [13:30:47 CEST] <ubitux> instead of avctx->time_base [13:30:54 CEST] <ubitux> which seems to do the trick in the codecpar branch [13:31:02 CEST] <ubitux> would this be ok? [13:49:30 CEST] <ubitux> ooh i can do much better [14:17:18 CEST] <ubitux> huh, one patch didn't reach the ml [14:17:56 CEST] <ubitux> ah now it did [14:20:15 CEST] <ubitux> Daemon404: ccdec fixed in codecpar [14:22:03 CEST] <JEEB> nice [14:22:54 CEST] <ubitux> (as soon as the patch on the ml are applied and cherry-picked back into codecpar) [14:39:17 CEST] <durandal_170> BBB: whar have you done with colomatrix filter? [14:39:29 CEST] <BBB> context? [14:40:09 CEST] <durandal_170> BBB: patches on ml [14:40:40 CEST] <BBB> I didnt do anything, someone else sent patches and Im commenting on them, right? [14:40:46 CEST] <BBB> like, review [14:40:53 CEST] <BBB> and I havent approved any yet, have I? [14:45:15 CEST] <durandal_170> BBB: guy said that he will not work on it anymore [14:45:26 CEST] <BBB> yeah I just noticed that [14:45:32 CEST] <BBB> how about I finish the patch? [14:45:47 CEST] <BBB> his approach was mostly OK, I can do the templating and DSPization myself [14:45:57 CEST] <durandal_170> you mentioned something about simd [14:46:12 CEST] <JEEB> also you can test it against the zscale filter which also has colorspace conversions between, say, BT.709 and BT.2020 [14:46:31 CEST] <durandal_170> so just go ahead and finish it [14:46:33 CEST] <BBB> ok, so, a few things [14:46:37 CEST] <BBB> durandal_170: yes boss [14:46:51 CEST] <BBB> A) I am not testing against zscale, I want external libs to die, especially libxyz ones [14:46:57 CEST] <BBB> I fundamentally dont believe in them [14:47:03 CEST] <BBB> I dont want to install crap like that on my system [14:47:08 CEST] <JEEB> ok [14:47:20 CEST] <BBB> B) colormatrix is fundamentally broken, it doesnt convert between RGB spaces [14:47:21 CEST] <durandal_170> BBB: I'm not your boss [14:47:38 CEST] <BBB> i.e. it assumes that all matrix coefficients between XYZ/RGB are equal between colorspaces, which they are not [14:47:45 CEST] <BBB> not to mention gamma differences [14:48:10 CEST] <BBB> C) ideally all of this would live in swscale, if it wasnt for the fact that swscale is rotten as hell [14:48:13 CEST] <JEEB> zimg basically replaced swscale in vapoursynth [14:48:17 CEST] <BBB> so& more constructively [14:48:20 CEST] <durandal_170> mpv have code that does it correctly [14:48:21 CEST] <JEEB> which is what zscale uses [14:48:37 CEST] <BBB> I have a lot of code that corrects the XYZ/RGB issue [14:49:04 CEST] <BBB> its not finished but I guess I should just finish it [14:49:43 CEST] <BBB> it would still make it a two-stage process to convert from any to any, youd need both swscale as well as colormatrix [14:49:50 CEST] <BBB> but at least it does the theoretically correct thing [14:49:55 CEST] <JEEB> yeah [14:50:07 CEST] <BBB> at some point years ago I wrote a complete scaling library that replaced swscale to do all of this in one place [14:50:12 CEST] <BBB> I actually called it avscale also :-p [14:50:15 CEST] <BBB> but that name is taken now [14:50:38 CEST] <JEEB> well that never saw the light of day as far as I've seen so people made their own things for that [14:50:46 CEST] <BBB> but I forgot where I put that code. it was pretty good but particular optimized paths were not as fast (by design) as swscale and fixing that would involve lots of hacks, so I eventually lost interest [14:51:04 CEST] <BBB> and now I dont remember where it is anymore [14:51:15 CEST] <BBB> I might have deleted it& I probably have backups but I cant be bothered [14:51:18 CEST] <JEEB> and in the end zimg seemed to be the least retarded and generic [14:51:59 CEST] <BBB> what you want is a any-range | any-colorspace | any-size < to > any-range | any-colorspace | any-size, right? [14:52:21 CEST] <JEEB> the author is a troll of course, so I can understand not wanting anon32 code on one's machine :D (also he seems to be against enabling x86 SIMD by default for whatever reason) [14:52:25 CEST] <BBB> with optimal precision, least rounding artifacts, little intermediates, etc. [14:53:35 CEST] <JEEB> https://github.com/sekrit-twc/zimg but yeah, this seems to do the general cases [14:54:01 CEST] <BBB> so you want to use zscale? or you want to extend colormatrix? or you want to rewrite avscale? [14:55:22 CEST] <JEEB> I would at this point say that it should be looked into if zimg could be used or just taken into FFmpeg on the longer run. on the shorter run I guess fixing colormatrix could be a good thing [14:56:03 CEST] <JEEB> and my original comment regards testing against zscale meant that you could check the results against it if you wanted - without any further meaning :P [14:56:16 CEST] <JEEB> since "hey, there's another filter that can do that stuff probably too" [14:56:50 CEST] <BBB> I dont think we should take zimg [14:57:02 CEST] <JEEB> yeah, it's basically herecy due to C++ [14:57:02 CEST] <BBB> zimg is just another swscale piece of shit that will end up being unmaintained and hated [14:57:25 CEST] <JEEB> ok [14:57:30 CEST] <BBB> well c++ doesnt help either :-p [14:57:34 CEST] <BBB> let me start with colormatrix [14:57:58 CEST] <BBB> shall I work on top of thomasz patches? [14:58:11 CEST] <BBB> its only fair we attribute him for the work he did, I mean, he did put in quite some effort it seems [14:58:16 CEST] <JEEB> yeah [14:58:42 CEST] <BBB> but so, a funny thing about colormatrix is that youre alreading seeing its design limitations: every colorspace needs new functions [14:58:43 CEST] <Gramner> I've never looked at the swscale source code, what's the problem with it? poor design, or just generally code quality issues? [14:58:45 CEST] <BBB> its not generic at all [14:58:54 CEST] <BBB> Gramner: why dont you have a look :-p [14:59:07 CEST] <BBB> I recommend starting with the rgb2yuv or yuv2rgb code paths [15:00:22 CEST] <BBB> I recommend trying to figure out the difference between (or the need for) SWS_FULL_CHR_H_INP and _INT, and then figuring out where yuv/rgb conversion coefficients are stored, how a user sets them and when they are honoured vs. when they are not (bonus points if you can do this for the mpegrange/fullrange flag) [15:00:32 CEST] <kierank> BBB: colormatrix is gpl so maybe not the best place to start [15:00:38 CEST] <BBB> ??? [15:00:40 CEST] <BBB> really [15:00:43 CEST] <BBB> I didnt know that [15:00:58 CEST] <kierank> iirc yes because it came from avisynth origianlly [15:01:07 CEST] <BBB> ok so thats not happening then [15:01:11 CEST] <BBB> let me start from scratch [15:01:18 CEST] <BBB> I can probably rewrite it in a few minutes [15:07:10 CEST] <durandal_170> I wanted to rewrite it too [15:07:30 CEST] <durandal_170> using mpv as reference [15:09:52 CEST] <durandal_170> it uses primaries for constructing matrix [15:10:36 CEST] <durandal_170> It's smile matrix operations [15:10:44 CEST] <durandal_170> *simple [15:41:20 CEST] <kierank> J_Darnley: ping [15:44:04 CEST] <kierank> https://www.irccloud.com/pastebin/Q5chYDZK/ [15:44:12 CEST] <kierank> is it possible to SIMD that? [15:49:03 CEST] <J_Darnley> oh my, 10-bit packing [15:49:04 CEST] <nevcairiel> looks possible, although maybe not incredibly efficient [15:49:06 CEST] <J_Darnley> maybe [15:49:17 CEST] <J_Darnley> someone did manage to write it for v210 [15:49:30 CEST] <kierank> yeah but v210 has some level of alignment [15:49:34 CEST] <kierank> raw 10-bit doesn't [15:49:39 CEST] <J_Darnley> oh [15:50:00 CEST] <J_Darnley> yes 2 bits of padding for every 3 samples [15:51:13 CEST] <kierank> I also don't need to worry about interleaving chroma actually because the actual pixelformat is uyvy422-10bit [15:51:19 CEST] <kierank> but I don't want to add that to libavutil [15:56:10 CEST] <kierank> I guess I should do it in groups of 15 bytes [15:56:36 CEST] <kierank> 120-bits so 12x 10-bit words [16:14:12 CEST] <Daemon404> ubitux, cool [16:22:03 CEST] <midgetspy> Gramner: Thanks, I did see that link but in Outlook and gmail it didn't set my In-Reply-To header correctly and I couldn't find any way to force it. Forwarding the actual message preserves the In-Reply-To/References headers which should work. [16:32:56 CEST] <wm4> ubitux: heh, I think your timebase patches would break mpv? [16:33:37 CEST] <wm4> it doesn't copy the whole avcodeccontext from an AVStream, only select fields [16:34:57 CEST] <durandal_170> kierank: have you tried zoneplate source filter? [16:35:56 CEST] <kierank> I will do it at work [16:40:34 CEST] <ubitux> wm4: what would break? [16:40:39 CEST] <ubitux> ccaption? [16:41:01 CEST] <ubitux> or the legacy timing? [16:41:29 CEST] <wm4> I'm not sure [16:41:46 CEST] <ubitux> i mean which patch you think is going to break? [16:42:06 CEST] <wm4> currently my code sets the AVCodecContext.time_base [16:42:19 CEST] <wm4> if your patch changes it to pkt_timebase, wouldn't that break? [16:42:38 CEST] <wm4> at the very least it'd error-out [16:43:29 CEST] <ubitux> pkt_timebase is already used everywhere in the subtitles rescaling [16:43:52 CEST] <ubitux> do you set AVCodecContext.time_base to sth different than the stream tb? [16:44:04 CEST] <wm4> which stream tb [16:44:09 CEST] <ubitux> stream->time_base [16:44:26 CEST] <wm4> I send packets with timestamps according to AVCodecContext.time_base if you mean that [16:45:57 CEST] <ubitux> when a demuxer create a new stream and set the timing info, it seems to actually set the pkt_timebase [16:46:00 CEST] <ubitux> this is what i use now [16:46:22 CEST] <wm4> well I'm not using the API like ffmpeg.c does... [16:46:42 CEST] <ubitux> sure, but, what timebase value are you setting then? [16:46:52 CEST] <wm4> AVCodecContex.time_base [16:46:59 CEST] <ubitux> yes but to what value? [16:47:04 CEST] <wm4> 1/1000 [16:47:09 CEST] <ubitux> ah [16:48:23 CEST] <ubitux> why :( [16:48:29 CEST] <wm4> why not? [16:48:39 CEST] <wm4> I think I even asked whether it's right to set time_base [16:49:38 CEST] <ubitux> are you still using the old ass timing or you switched that? [16:49:48 CEST] <wm4> still the old one [16:49:52 CEST] <ubitux> mmh [16:50:12 CEST] <wm4> (no reason to switch until I actually get all timings in the correct time base) [16:50:33 CEST] <ubitux> so, so far, it seems there is only 2 remaining usage of avctx->time_base for subtitles [16:50:47 CEST] <ubitux> and that's the 2 things i changed in these patches [16:51:34 CEST] <ubitux> (1. the timing rescale for the deprecated ass payload 2. ccaption dec) [16:51:44 CEST] <ubitux> everything else is using pkt_timebase [16:52:05 CEST] <ubitux> it's strange that you get it working as expected with 1/1000 [16:52:54 CEST] <wm4> why is it strange? [16:53:15 CEST] <ubitux> because most of the subtitles code is using pkt_timebase [16:59:08 CEST] <ubitux> wm4: typically for bitmap subs your avctx->time_base will be ignored for instance [16:59:22 CEST] <ubitux> (afaict) [17:00:18 CEST] <wm4> that's because they either pass through the timestamp, or use a fixed timebase [17:00:33 CEST] <wm4> the only place where I have this problem are subtitle converters [17:01:32 CEST] <kierank> J_Darnley: seems to be possible in the same way as v210 [17:02:02 CEST] <kierank> load, copy, variable shift (pmullw), pxor [17:02:07 CEST] <kierank> 4:01 PM <"kierank> J_Darnley: seems to be possible in the same way as v210 [17:02:42 CEST] <kierank> https://usercontent.irccloud-cdn.com/file/4M1Ff8nt/ [17:02:49 CEST] Action: kierank writes enterprise simd [17:05:20 CEST] <J_Darnley> good [17:05:36 CEST] <J_Darnley> and sorry for the disconnects [17:05:59 CEST] <J_Darnley> This is the level of service my ISP provides during "business hours" [17:10:25 CEST] <kierank> going to be headache inducing though [17:10:29 CEST] <kierank> three loads for every store [17:10:40 CEST] <kierank> loads of 128*3 bits to write 120bits [17:12:52 CEST] <wm4> just wondering, would it be easier to generate such code with a script? [17:13:47 CEST] <kierank> dunno maybe [17:14:25 CEST] <kierank> a two loads per store, not so bad [17:46:04 CEST] <cone-033> ffmpeg 03Paul B Mahol 07origin/release/3.0:HEAD: avcodec: add dca core extraction bsf [17:49:11 CEST] <atomnuker> michaelni: which branch do I backport the aacenc fixes for 3.0.1? [17:49:53 CEST] <michaelni> to release/3.0, also use cherry-pick -x so the hash from the source commit is in it [17:58:52 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:7c2576e15d32: lavc/aacenc_utils: replace sqrtf(Q*sqrtf(Q)) by precomputed value [17:58:53 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:1cbe4ff2acdd: aacenc: avoid double in quantize_bands. [17:58:54 CEST] <cone-033> ffmpeg 03Reimar Döffinger 07release/3.0:b176ab055691: aacenc_utils: Use temporary variable. [17:58:55 CEST] <cone-033> ffmpeg 03Ganesh Ajjanagadde 07release/3.0:f281cb4ea93d: lavc/aacenc_utils: replace powf(x,y) by expf(logf(x), y) [17:59:46 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:6cb5bbc66024: Changelog: update for 3.0.1's aacenc optimizations [18:02:08 CEST] <kierank> Gramner: are the variable shifts in avx2 any good? [18:02:24 CEST] <kierank> instead of pmullw (2^n) [18:03:56 CEST] <Gramner> they accomplish the same thing essentially in most cases, assuming the shift amount is constant [18:04:12 CEST] <Gramner> they're useful if you have calculated shift amounts though [18:05:30 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:f01919b57af0: vc2enc: correctly zero out coefficient array padding [18:05:31 CEST] <cone-033> ffmpeg 03Rostislav Pehlivanov 07release/3.0:3d9ebfd27264: Changelog: update for 3.0.1's vc2enc fixes [18:08:56 CEST] <Angus__> Is anyone here familar with struct URLProtocol? [18:10:03 CEST] <cone-033> ffmpeg 03Paul B Mahol 07master:c2bbcf16077b: avfilter/vf_waveform: optimize 16bit lowpass filter [18:20:37 CEST] <ubitux> Daemon404: so mov is supposed to be fixed? [18:21:04 CEST] <ubitux> binsub-movtextenc is still failing, i'm wondering if the issue is within mov or the encoder [18:21:16 CEST] <ubitux> or maybe demux/decoder [18:22:15 CEST] <Daemon404> ubitux, i bet it is the same as all the other mov failures [18:22:17 CEST] <Daemon404> fiel atom [18:22:27 CEST] <Daemon404> nevcairiel explained it a few days back. [18:22:36 CEST] <ubitux> ok i'll grep my logs [18:22:38 CEST] <ubitux> thx [18:23:33 CEST] <ubitux> it seems to be in the tkhd atom though [18:23:55 CEST] <Daemon404> ubitux, easy way to check is to use boxdumper [18:23:58 CEST] <Daemon404> and diff outout [18:24:01 CEST] <Daemon404> thats what i did [18:24:22 CEST] <Daemon404> boxdumper oldfateoutput.mov > src.txt [18:25:04 CEST] <JEEB> yeah, boxdumper is quite useful [18:25:06 CEST] <Daemon404> you could simply be seeing the atom size changes due to nesting [18:26:14 CEST] <ubitux> lol, it's width/height [18:27:30 CEST] <ubitux> so width/height are missing for the subtitles track [18:27:39 CEST] <ubitux> meh. [18:28:28 CEST] <Daemon404> er what? [18:30:33 CEST] <ubitux> the original mp4 has a tx3g stream with width=400 height=60 [18:30:41 CEST] <ubitux> when transcoding, this information is now lost [18:30:51 CEST] <ubitux> maybe codecpar->{width,height} are copied only for video? [18:31:01 CEST] <nevcairiel> check the code and add it if needed [18:31:03 CEST] <nevcairiel> its possible [18:31:11 CEST] <nevcairiel> subtitle support is pretty limited in libav afterall [18:42:20 CEST] <BtbN> Hm, if I cherry-pick a new file from libav, do I keep their file-header, or do I replace it with the ffmpeg one? (Keeping license and author of course) [18:42:37 CEST] <Daemon404> :%s/Libav/FFmpeg/ [18:42:59 CEST] <Daemon404> since the file is now a part of a different project [18:43:14 CEST] <ubitux> can we get done with codecpar asap? :( [18:43:39 CEST] <Daemon404> ubitux, after subtitles, most of what's left is slightly over my head [18:43:51 CEST] <Daemon404> like voc [18:44:23 CEST] <ubitux> we're now 150+ commits behind [18:44:37 CEST] <Daemon404> behind libav? [18:44:38 CEST] <Daemon404> or ffmpeg? [18:44:54 CEST] <ubitux> libav has 150+ commits not merged [18:45:11 CEST] <ubitux> in ffmpeg [18:45:16 CEST] <Daemon404> wm4 / nevcairiel - can we hunker down then? [18:45:32 CEST] <Daemon404> i really am not capable of figuring out one or three of some stuff [18:45:41 CEST] <nevcairiel> i dont see how the number of commits makes any difference [18:45:55 CEST] <nevcairiel> 30 of those are cleanup of svq3, etc [18:46:08 CEST] <Daemon404> sure [18:46:13 CEST] <Daemon404> but i still would lik to get tep2 done [18:46:18 CEST] <Daemon404> it haunts me [18:46:30 CEST] <nevcairiel> like I said the other day, libav prepared for this over months, dont expect to get it done quickly [18:46:41 CEST] <Daemon404> there's a difference bteween not doing it quickly [18:46:43 CEST] <Daemon404> and nothing for weeks [18:50:25 CEST] <Daemon404> booting my dev vm for ffmpeg, will hack on some stuff [18:52:10 CEST] <ubitux> st->codecpar->{width,height} are properly set in the demuxer, but aren't in the muxer [18:52:15 CEST] <ubitux> any idea where that information could be lost? [18:52:39 CEST] <nevcairiel> it translates to avctx in between, check the translation code, like Daemon404 said, its probably not set for subtitles [18:52:51 CEST] <nevcairiel> (or copied for that matter) [18:53:30 CEST] <nevcairiel> its in avcodec/utils.c [18:53:55 CEST] <ubitux> ah, perfect [18:53:57 CEST] <ubitux> thanks [18:54:45 CEST] <nevcairiel> Daemon404: there is a few "simple" open questions, like what happens with has_b_frames, could introduce a new element with a more appropriate name in codecpar that conveys the decode delay information that has_b_frames previously included [18:55:06 CEST] <Daemon404> i thought we agreed on that [18:55:15 CEST] <Daemon404> but there's als oa bunch of work unrelated to bframes [18:55:25 CEST] <nevcairiel> i dont remember anyone agreeing, just people throwing around ideas [18:55:35 CEST] <Daemon404> im perfectly fine with some sort of delay entry [18:55:41 CEST] <Daemon404> i thought wm4 was too [18:56:03 CEST] <nevcairiel> fiel will probably be annoying [18:56:18 CEST] <Daemon404> i know [18:56:26 CEST] <nevcairiel> could add some ugly hack to check avctx [18:56:32 CEST] <nevcairiel> under deprecation guards [18:56:41 CEST] <Daemon404> because we change stream-level stuff after alreadfy muxing some packets, if i understand? [18:56:47 CEST] <nevcairiel> yes [18:56:56 CEST] <nevcairiel> which kind-of works for mov since it writes headers at the end [18:56:59 CEST] <Daemon404> we could queue some packets after reading some in ffmpeg.c [18:57:03 CEST] <Daemon404> and then set it [18:57:06 CEST] <Daemon404> and then write the header [18:57:18 CEST] <nevcairiel> any changes to ffmpeg.c would be bad [18:57:22 CEST] <nevcairiel> breaks api still for anyone else [18:57:34 CEST] <Daemon404> that's only true if the api was actually validand documented [18:58:18 CEST] <nevcairiel> you could also just ignore it then, as it fixes itself when ffmpeg.c siwtches to codecpar [18:58:35 CEST] <Daemon404> does it? [18:58:39 CEST] <nevcairiel> of course [18:58:56 CEST] <Daemon404> i did switch field_order to codecpar (you had me revert it), but i didnt fix it [18:58:58 CEST] <nevcairiel> the problem only exists because the compat code that generates codecpar is only run once [18:59:06 CEST] <Daemon404> right [18:59:10 CEST] <ubitux> is it ok to copy sar in addition to width/height for subtitles? [18:59:28 CEST] <wm4> never seen sar applied to subtitles [18:59:34 CEST] <Daemon404> ubitux, if it's in codecpar, i dont see why it would be wrong. [18:59:35 CEST] <wm4> (although the _video_ sar might matter) [18:59:37 CEST] <Daemon404> but yeah what wm4 said [18:59:40 CEST] <nevcairiel> Daemon404: thats because https://github.com/dwbuiten/FFmpeg/commit/435bc7ff51c9bba5bd475486ab8c45417b... was wrong in many ways. ;) [18:59:58 CEST] <Daemon404> it's reverted ;) [19:00:02 CEST] <nevcairiel> i know [19:00:08 CEST] <nevcairiel> but it didnt fix anything because you switched it only half [19:00:09 CEST] <Daemon404> this is also why i said i need help [19:00:28 CEST] <Daemon404> for now, ill ignore fiel then [19:00:34 CEST] <ubitux> even for bitmaps? [19:00:37 CEST] <nevcairiel> would be nice to get those fails out of the list [19:00:40 CEST] <Daemon404> true [19:00:49 CEST] <Daemon404> but i am not qualified to fix ffmpeg.c [19:00:54 CEST] <Daemon404> as you have shown. [19:01:01 CEST] <ubitux> anyway, i fixed binsub-movtextenc, thanks for the hints [19:01:30 CEST] <Daemon404> ill take a look at the ogg one [19:01:33 CEST] <Daemon404> which i am sure ill regret [19:01:34 CEST] <nevcairiel> maybe it would be best to just add some magic code movenc to re-read fiel from the deprecated avctx before writing headers [19:01:35 CEST] <Daemon404> because ogg [19:02:01 CEST] <nevcairiel> slightly ugly but preserves behavior [19:02:04 CEST] <Daemon404> nevcairiel, under deprecation guards? [19:02:07 CEST] <nevcairiel> of course [19:02:15 CEST] <Daemon404> i am not opposed [19:02:22 CEST] <Daemon404> since it is then deprecated properly [19:02:24 CEST] <nevcairiel> anyway dinner time [19:02:31 CEST] <nevcairiel> i might have time to work on things tomorrow [19:02:34 CEST] <Daemon404> ok [19:02:36 CEST] <nevcairiel> nto tonight tho [19:02:39 CEST] <Daemon404> i have time all week. [19:02:48 CEST] <Daemon404> i can dedicate some work time to it. [19:03:30 CEST] <Daemon404> i will add movenc.c stuff today then [19:03:48 CEST] <Daemon404> then most of the failures left will be odd one-offs [19:03:49 CEST] <Daemon404> i think. [19:04:46 CEST] <ubitux> oh it fixed sub2video too [19:04:53 CEST] <Daemon404> :) [19:06:08 CEST] <Daemon404> ubitux, btw do you mind helping out with merges once tep2 is in, to get caught up [19:06:15 CEST] <Daemon404> a good chunk of them will just be monkey work [19:06:17 CEST] <ubitux> yes [19:06:38 CEST] <Daemon404> there's a few important ones [19:06:44 CEST] <Daemon404> hwaccel stuff [19:06:45 CEST] <ubitux> i'm in holiday tomorrow and the day after [19:06:54 CEST] <ubitux> but i suppose codecpar won't be in? [19:06:56 CEST] <ubitux> :( [19:07:17 CEST] <Daemon404> probably not, but if we can make fate pass, maybe nevcairiel will get motivated again [19:07:20 CEST] Action: Daemon404 runs [19:07:51 CEST] <ubitux> wm4: can you check if the ccaption patch (only) is breaking something for you? [19:07:58 CEST] <wm4> btw. one thing I noticed about fate is that not all it testes and expects is actually sane [19:08:12 CEST] <wm4> ubitux: git branch? [19:08:14 CEST] <ubitux> for the legacy rescaling i might just make a fallback to pkt timebase if avctx tb isn't set [19:08:19 CEST] <Daemon404> wm4, yes thats why i updated several tests [19:08:24 CEST] <ubitux> wm4: will push somewhere, just a moment [19:08:25 CEST] <Daemon404> the reslt after codecpar was *more* correct [19:10:06 CEST] <ubitux> wm4: https://github.com/ubitux/FFmpeg/compare/ccaption-tb [19:17:06 CEST] <ubitux> keeping our HEAD chunks from fate-wtv-demux test makes fate pass here [19:17:11 CEST] <ubitux> so i'll commit that [19:17:15 CEST] <wm4> ubitux: still seems to work [19:17:36 CEST] <Daemon404> ubitux, HEAD chunks? [19:17:59 CEST] <Daemon404> merge conflict in the fate test? [19:18:03 CEST] <ubitux> http://sprunge.us/iXfe [19:18:10 CEST] <Daemon404> ok [19:18:14 CEST] <Daemon404> if HEAD is fine, it's not a problem [19:18:51 CEST] <ubitux> wm4: cool; i'm going to pick the 2nd commit and ask you to try if it breaks; if it does i'll try to amend something and ask for a test again [19:18:53 CEST] <ubitux> if you don't mind [19:19:23 CEST] <Daemon404> nevcairiel / wm4 / ubitux - btw, i am assumign we will just noop all the 10ish+ commits after the TEP2 commit in libav which are switching e.g. avconv to codecpar [19:19:27 CEST] <Daemon404> since well do that [19:19:48 CEST] <ubitux> ? [19:19:56 CEST] <Daemon404> avconv: convert to codecpar [19:19:59 CEST] <Daemon404> commits like that [19:20:08 CEST] <Daemon404> not useful to us, sinde we'll have to fix it ourselves [19:20:09 CEST] <wm4> I don't think they'd apply anyway [19:20:14 CEST] <Daemon404> exaxtly [19:21:13 CEST] <ubitux> you don't want to fix ffmpeg.c in the avconv.c merge? [19:21:37 CEST] <Daemon404> ubitux, im fine with fixing it in a spearate merge [19:21:44 CEST] <Daemon404> but im saying i can noop the libav ones. [19:21:55 CEST] <Daemon404> because it wont even been close to a clean merge [19:22:03 CEST] <ubitux> sounds weird not to do it in the merge commit [19:22:08 CEST] <ubitux> wm4: can you try https://github.com/ubitux/FFmpeg/compare/sub-time-base ? [19:22:11 CEST] <Daemon404> maybe [19:22:26 CEST] <Daemon404> ubitux, we can still push the lavf commit/merge first [19:22:32 CEST] <Daemon404> it helps us make the branch less... hge [19:22:33 CEST] <Daemon404> huge [19:22:36 CEST] <ubitux> yes ofc [19:22:50 CEST] <ubitux> btw, you'll have to squash everything before doing a rebase or a re-merge [19:23:01 CEST] <ubitux> (because i cherry-picked stuff from master) [19:24:10 CEST] <Daemon404> im going to make a new branch based off HEAD and cherrypick/squash stuff [19:24:16 CEST] <Daemon404> once it builds/works [19:24:30 CEST] <Daemon404> probably a 1-3 hrs work [19:25:45 CEST] <wm4> ubitux: cc_dec: packet time base not set [19:26:01 CEST] <wm4> ubitux: same for any other text subtitle format [19:26:16 CEST] <ubitux> but it worked with the commit in cc? [19:26:18 CEST] <ubitux> strange [19:26:30 CEST] <ubitux> but OK, let me try something then [19:31:19 CEST] <ubitux> wm4: can you pull & retry? [19:31:34 CEST] <ubitux> it will prefer pkt_timebase over avctx->time_base though [19:31:59 CEST] <ubitux> (if set) [19:32:17 CEST] <wm4> ubitux: appears to work [19:32:21 CEST] <ubitux> ok [19:32:29 CEST] <ubitux> do you think i should test for avctx->time_base instead? [19:32:58 CEST] <wm4> don't know, some other API user might have set both to different values? [19:33:08 CEST] <wm4> this was never a well-defined API [19:33:16 CEST] <ubitux> you think other people managed to make subtitles work? [19:33:18 CEST] <ubitux> @_@ [19:39:26 CEST] <Daemon404> nevcairiel, fiel stuff is all passing now. [19:40:14 CEST] <Daemon404> i think all of vsynth* works now [19:40:15 CEST] <Daemon404> running it. [19:40:42 CEST] <kierank> Prores spec is out [19:40:53 CEST] <Daemon404> spec or "spec" [19:42:55 CEST] <ubitux> timestamps are now set in fate-mxf-demux, should we just keep that change? [19:43:13 CEST] <Daemon404> i mean, that sounds better to me [19:43:29 CEST] <Daemon404> also: yes, all of the vsynth tests pass [19:43:30 CEST] <Daemon404> \o/ [19:44:30 CEST] <ubitux> http://sprunge.us/XZFK basically this (after keeping our local chunks) [19:44:57 CEST] <Daemon404> that looks more correct me [19:45:18 CEST] <ubitux> the reason it mismatch with libav change is because we have F=0x0 in the output [19:45:20 CEST] <ubitux> afaict [19:45:25 CEST] <Daemon404> ah [19:45:28 CEST] <Daemon404> yeah, ship it, [19:47:37 CEST] <ubitux> done [19:48:51 CEST] <ubitux> exact same thing with fate-nc-demux [19:49:11 CEST] <ubitux> http://ubitux.fr/pub/pics/fate-nc-colordiff.png [19:49:16 CEST] <ubitux> so going to ship it as well [19:52:12 CEST] <wm4> huh why does the diff not render this minimally [19:52:17 CEST] <Daemon404> ? [19:52:40 CEST] <wm4> I mean, the CRC is highlighted twice, but it doesn't change [19:53:26 CEST] <nevcairiel> probably only stops highlights on spaces [19:53:32 CEST] <nevcairiel> and this adds a , after the crc [19:54:09 CEST] <ubitux> same for fate-lmlm4-demux, pushed [20:01:38 CEST] <Daemon404> fate-movenc fixed [20:01:42 CEST] <Daemon404> it was all expected changes [20:02:01 CEST] <Daemon404> nevcairiel / wm4 - what is concat in the fate list? [20:02:04 CEST] <Daemon404> i dont see a concat test [20:02:56 CEST] <nevcairiel> there is various concat tests [20:03:36 CEST] <nevcairiel> concat-demuxer-extended-lavf-mxf etc [20:04:30 CEST] <Daemon404> hmm ok [20:04:51 CEST] <Daemon404> ubitux, ffprobe_*- just codec_time_base differs [20:04:56 CEST] <Daemon404> i wasnt sure what to do about this [20:11:33 CEST] <omerjerk> Hi everyone. [20:12:30 CEST] <omerjerk> So i need to perform Masked LZ Decompression at a place in ALS decoder. [20:13:02 CEST] <omerjerk> is by any chance this algorithm already present somewhere in the ffmpeg codebase ? [20:13:23 CEST] <omerjerk> else I'll need to write it myself. [20:19:14 CEST] <michaelni> ubitux, http://sprunge.us/XZFK <-- the mpeg4 in this is not marked as low_delay so dts==pts at least from codec level would be wrong [20:23:52 CEST] <Daemon404> michaelni, even if it is intar-only? [20:23:54 CEST] <Daemon404> intra* [20:29:40 CEST] <Daemon404> hmm, where are audio timestamps set during demux? [20:29:45 CEST] <Daemon404> for packets [20:32:44 CEST] <Daemon404> nevcairiel, the concat failures are the same as the ffprobe ones (concat tests use ffprobe output) [20:32:55 CEST] <nevcairiel> it seemd more broken before [20:33:06 CEST] <Daemon404> yeah before i fixed the rest [20:33:14 CEST] <Daemon404> now it's just codec_time_base beign reported as 0/1 [20:33:27 CEST] <Compn> hmm wasnt there some kind of file analyzer out there [20:33:27 CEST] <michaelni> Daemon404, intra only doesnt matter the VO type does for non coded low_delay, we arent checking that though currently and assume all VOs can contain B frames [20:33:35 CEST] <Compn> i thought someone wrote it ... maybe kierank [20:34:01 CEST] <Daemon404> nevcairiel, any opinion on ffprobe "codec timebase" output? [20:34:11 CEST] <Compn> theres a couple of forensic mpeg4/h264 file analyzers out there too. they count frame numbers and scan for mpeg frame startcodes etc [20:34:33 CEST] <Daemon404> let's see. [20:37:45 CEST] <Daemon404> think i might know what to do [20:43:15 CEST] <Daemon404> woo fixed [20:57:28 CEST] <Daemon404> nevcairiel, concat and ffproeb fixed. [20:57:44 CEST] <Daemon404> i think theres not a ton left to fix for fate now [20:59:11 CEST] <Daemon404> nevcairiel / ubitux / wm4 - do you mind if i trim down the etherpad to now have 9000 fied things in it? [20:59:35 CEST] <nevcairiel> i wanted to trim the todos anyway to only open items [20:59:40 CEST] <Daemon404> ok [21:09:09 CEST] <Daemon404> done [21:24:57 CEST] <cone-135> ffmpeg 03Kirill Gavrilov 07master:f3ec8ac0f422: lavc/mediacodec: fix zero stride for OMX.allwinner.video.decoder.avc [21:28:13 CEST] <cone-135> ffmpeg 03Paul B Mahol 07master:a55c953ef00c: avfilter/af_sofalizer: allow user to setup custom virtual speakers positions [21:34:18 CEST] <ubitux> Daemon404: sure [21:35:04 CEST] <ubitux> michaelni: ah... [21:35:21 CEST] <ubitux> so i should revert these commits? [21:37:06 CEST] <ubitux> michaelni: so it's actually supposed to be NOPTS? [21:38:49 CEST] <ubitux> ah you sent a patch [21:40:03 CEST] <michaelni> my patch improves low_delay (and thus has_b_frames) setting for mpeg4, the values posted where wrong for low_delay=0 / has_b_frames=1 [21:40:35 CEST] <michaelni> my patch is very unlikely to fix whatever problem caused the quoted values [21:41:12 CEST] <michaelni> it fixes a long standing mistake on the mepg4 header interpretation [21:41:47 CEST] <michaelni> mpeg4 header -> low_delay/has_b_frames -----libavformat---> timestamps [21:41:55 CEST] <Daemon404> nevcairiel, not much left, mostly the stuff you explained to be re: voc and swf. take a look tmr if you have time. [21:42:00 CEST] Action: Daemon404 forgets exactly what to fix [21:42:24 CEST] <kierank> BBB: so prores doesn't specify a specific idct [21:42:27 CEST] <Daemon404> michaelni, i think the idea is to add a delay field into codecpar [21:42:28 CEST] <kierank> which is very interesting [21:42:44 CEST] <BBB> is prores defined at all? [21:43:16 CEST] <michaelni> Daemon404, yes, something with a sane name that does what has_b_frames_ does now is needed [21:43:21 CEST] <kierank> BBB: yes spec released today [21:45:25 CEST] <jamrial> great oportunity to clean our duplicate decoders and encoders. whichever ended up being closer to spec shall stay :p [21:45:37 CEST] <JEEB> woah, spec for prores [21:45:42 CEST] <JEEB> my head just blew [22:03:33 CEST] <Daemon404> whyone know which func audip timestamps are generated in for packets? [22:03:35 CEST] <Daemon404> anyone* [22:09:55 CEST] <kierank> JEEB: a reference implementation too [22:11:40 CEST] <JEEB> and just a year or two ago it was all "proprietary stuff only for proper licensors, do not steal" [22:12:36 CEST] <kierank> it still is [22:12:45 CEST] <JEEB> :D [22:12:48 CEST] <kierank> they will threaten you if you implement it [22:13:11 CEST] <JEEB> sounds like dolby, although I only know that dolby goes against non-licensed payware distributors [22:13:15 CEST] <Compn> they threatened everyone who was using ffmpeg prores iirc :D [22:13:28 CEST] <Compn> in a commercial setting that is [22:20:17 CEST] <Daemon404> ok wm4 / nevcairiel / ubitux - ive done literally all i can do now without help, so please do have a look at a thing or two and hit me up. [22:20:28 CEST] <Daemon404> etherpad is updated - not much left [22:28:56 CEST] <wm4> will look tomorrow if I can do anything [22:29:09 CEST] <Daemon404> ok [22:47:13 CEST] <durandal_170> all demuxers not present in libav where converted? [22:57:28 CEST] <BtbN> hm, this CUVID decoder might prove difficult if not impossible. At least without pulling the frames to system memory right in the decoder. [22:58:10 CEST] <BtbN> The frames need to be mapped/unmapped to cuda surfaces, so the frames would need some kind of custom cleanup [22:58:31 CEST] <BtbN> And CUVID also only allows a certain number of mapped output frames, which might be only exactly one [23:00:23 CEST] <ubitux> durandal_170: git grep -- '->codec[^p_]' libavformat still has a few match [23:01:27 CEST] <ubitux> chromaprint, electronicarts, ffm{dec,enc}, libnut, microdvdenc, mov*, mux, nut{dec,enc}, oggdec, sdp, and utils [23:05:25 CEST] <BBB> this sucks so much [23:05:34 CEST] <BBB> Im trying to do some colorspace conversion tests [23:05:49 CEST] <BBB> and I have no content which is actually marked for anything else than colorspace unknown trc unknown and primaries unknown [23:06:04 CEST] <BBB> why does software suck so much? [23:06:25 CEST] <kierank> BBB: parkjoy sources i think are done correctly [23:07:08 CEST] <kierank> kinda big though [23:07:08 CEST] <BBB> is there a x264-encoded source somewhere? [23:07:14 CEST] <BBB> like, I only need a few frames [23:07:32 CEST] <Shiz> go to nyaa, pick literally anything [23:08:11 CEST] <BBB> nyaa? [23:09:00 CEST] <ubitux> nyaa.eu [23:09:09 CEST] <ubitux> or .se [23:09:17 CEST] <JEEB> lemme see if my bt.709=>bt.2020 thing had colorimetry info [23:09:24 CEST] <BBB> pff... [23:09:39 CEST] <BBB> I need something sfw [23:09:50 CEST] <BBB> and illegal torrents that are not porn are not sfw just because they are not porn [23:10:08 CEST] <ubitux> i can check my samples [23:10:12 CEST] <ubitux> is that info exported by ffprobe? [23:10:23 CEST] <JEEB> and ffmpeg as well IIRC [23:10:25 CEST] <BBB> should be in the frame, yes [23:10:45 CEST] <ubitux> what field? [23:10:49 CEST] <JEEB> ok, so I have my Japanese rugby sample [23:11:01 CEST] <JEEB> it's MPEG-TS so you can grab the first N megabytes of it [23:11:40 CEST] <BBB> that would be wonderful [23:11:45 CEST] <ubitux> - ffprobe -v error -of flat -show_entries stream=color_space,color_range ~/samples/big_buck_bunny_1080p_h264.mov [23:11:47 CEST] <ethe> JEEB: I have a raw of the Japan Vs South Africa game lying about somewhere [23:11:47 CEST] <ubitux> streams.stream.0.color_range="tv" [23:11:49 CEST] <ubitux> streams.stream.0.color_space="bt709" [23:11:51 CEST] <ubitux> so stuff like this? [23:11:53 CEST] <BBB> yes [23:11:56 CEST] <JEEB> https://kuroko.fushizen.eu/samples/Japanese_Rugby_Game-4K_Channel.ts [23:12:00 CEST] <JEEB> this is BT.2020 [23:12:31 CEST] <BBB> holy shit that is big [23:12:39 CEST] <BBB> how much do I need? [23:12:41 CEST] <ubitux> BBB: http://b.pkh.me/classics-in-lego-26.jpg [23:12:42 CEST] <ubitux> bt470bg [23:12:59 CEST] <Shiz> nice prompt [23:13:16 CEST] <ubitux> it's a red on error :X [23:13:17 CEST] <JEEB> BBB: it's MPEG-TS so a dozen megabytes or so should be OK even with that bit rate [23:13:24 CEST] <BBB> [hevc @ 0x7ff931833000] SPS 0 does not exist [23:13:26 CEST] <BBB> ... [23:13:31 CEST] <JEEB> https://kuroko.fushizen.eu/samples/bt2020_to_bt709.mp4 [23:13:37 CEST] <JEEB> downscaled and bt.709 [23:13:58 CEST] <JEEB> BBB: well yeah it was not cut exactly on an IRAP [23:14:13 CEST] <BBB> ah cool that works [23:14:16 CEST] <BBB> ty [23:14:27 CEST] <ubitux> streams.stream.1.color_space="smpte170m" [23:14:30 CEST] <ubitux> do you want this one? [23:14:52 CEST] <ubitux> http://b.pkh.me/PSDOP.mp4 [23:15:11 CEST] <BBB> JEEB: can you downscale the 4k one to lower resolution and cut the first few seconds out? Id love a bt2020 sample also [23:15:25 CEST] <BBB> ubitux: ty, downloading also [23:15:37 CEST] <BBB> now I need to figure out how lavfi works again [23:15:56 CEST] <ubitux> so what do you have now, bt709, bt470bg, smpte170m? [23:16:45 CEST] <BBB> just smpte170m and bt709 [23:17:03 CEST] <ubitux> you have bt470bg with the jpg [23:17:21 CEST] <BBB> oh right [23:18:32 CEST] <BBB> so I guess I need bt2020 and smpte240m then [23:18:36 CEST] <BBB> that should be about it [23:18:43 CEST] <ubitux> look for some [23:23:49 CEST] <ubitux> BBB: did you check fate samples? [23:27:58 CEST] <BBB> not yet, no [23:28:05 CEST] <BBB> I checked a handful of h264 conformance samples [23:28:10 CEST] <BBB> and theyre all unknown afaics [23:28:21 CEST] <ubitux> can't find anything matching bt2020|smpte428|smpte240m|bt470m|film [23:28:25 CEST] <ubitux> (so far) [23:29:02 CEST] <ubitux> oh there is one with fcc in fate [23:31:33 CEST] <ubitux> BBB: fate-samples/ea-mpc/THX_logo.mpc [23:31:36 CEST] <ubitux> for fcc [23:31:47 CEST] <BBB> cool! ty [23:32:30 CEST] <BBB> so can anyone explain to me how format negotiation works in lavfi? [23:32:38 CEST] <cone-135> ffmpeg 03Lou Logan 07master:cd76eb8f4adb: lavd/dshow_crossbar: remove trailing whitespace [23:32:38 CEST] <ubitux> yes [23:32:40 CEST] <ubitux> magically [23:32:43 CEST] <BBB> lets say Im writing a filter that changes colorspace from bt2020 to bt709 or so [23:33:03 CEST] <BBB> Im assuming the frame->color_primaries etc. fields are writable by me in the output frame, right? [23:33:14 CEST] <BBB> where output frame is the thing received from ff_get_video_buffer [23:33:22 CEST] <BBB> so, how do I set format? [23:33:33 CEST] <durandal_170> Yes [23:33:41 CEST] <BBB> lets say my filter is bitdepth-agnostic, and my input frame is yuv420p& how do I set the output to yuv420p12? [23:33:56 CEST] <BBB> (assuming I have some property bitdepth in my filter) [23:34:07 CEST] <durandal_170> query_formats [23:34:08 CEST] <BBB> (which maps to the variable s->bit_depth) [23:34:15 CEST] <BBB> what does query_formats do? [23:34:59 CEST] <ubitux> it specifies which pixel format you support as input and output [23:35:11 CEST] <BBB> but what if I dont care what the input is? [23:35:25 CEST] <ubitux> then you only set the output one [23:35:36 CEST] <BBB> like, I want to say input can be yuv420p10, 12 or 8, but output is yuv420p10 because the user said so [23:35:40 CEST] <BBB> oh [23:35:51 CEST] <BBB> how do I do that? [23:35:59 CEST] <ubitux> but then it means you're suppose to support any pixel format, right? [23:36:03 CEST] <BtbN> well, you most likely still want to define a range of supported input formats? Otherwise RGB and stuff would also be valid [23:36:32 CEST] <BBB> right, so the input will be a list like various filters have [23:36:35 CEST] <BBB> and the output will be 1 [23:37:38 CEST] <BBB> I see ff_set_common_formats [23:37:44 CEST] <BBB> does that set it on input and output? [23:38:23 CEST] <ubitux> yes [23:38:31 CEST] <durandal_170> yes [23:39:51 CEST] <durandal_170> see zscale/scale filters [23:45:43 CEST] <ubitux> BBB: if you have a db of samples, you can try find samples -type f -exec ffprobe -v 0 -of flat -show_entries stream=color_space,color_primaries {} \; -print > colorspace.log [23:45:48 CEST] <ubitux> and grep stuff in that [23:45:49 CEST] <cone-135> ffmpeg 03Marton Balint 07master:99f2a59c2f29: avcodec/utils: fix packet duration of frames with discarded paddings [23:46:03 CEST] <ubitux> i'm running this on my stuff, will see if sth comes up [23:47:42 CEST] <ubitux> i should write a script create a sqlite db based on ffprobe output [23:47:56 CEST] <ubitux> so we can do fun queries to find particular type of samples [23:49:35 CEST] <BBB> ok the filter format setting works now, nice [23:57:00 CEST] <dinux5> what to do to remove doxy and non doxy comment error message in patcheck ? [00:00:00 CEST] --- Tue Mar 29 2016