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

[burek]

[00:51:34 CEST] <rcombs> remind me why the data arg is void* instead of AVFrame*
[00:52:18 CEST] <rcombs> also isn't that changed with the new API anyway
[01:13:16 CEST] <atomnuker> rcombs: I'll answer if you push your patches
[01:15:45 CEST] <rcombs> is everyone okay with how they fuck up the MD5
[01:16:27 CEST] <rcombs> or, well, can, if you trim in a remux
[01:16:37 CEST] <rcombs> dunno if that's really solvable
[01:16:56 CEST] <atomnuker> md5?
[01:17:08 CEST] <atomnuker> I just want the one to mux in coverart
[01:21:10 CEST] <J_Darnley> No, no!  Flac files do not have video streams!
[01:25:24 CEST] <rcombs> oh boy, an objection
[01:25:28 CEST] <rcombs> of some sort
[01:29:10 CEST] <J_Darnley> Not to your patches but rather to how ffmpeg treats these binary data attachments.
[01:30:31 CEST] <cone-352> ffmpeg 03Michael Niedermayer 07master:426a322aa2bf: avcodec/cavsdec: Check I frame mb decode for errors
[01:30:31 CEST] <cone-352> ffmpeg 03Michael Niedermayer 07master:b9ce43625c43: avcodec/cavsdec: Check P/B frame mb decode which return error codes
[01:38:41 CEST] <rcombs> oh yeah, that's kinda weird
[01:38:45 CEST] <rcombs> but it's how it works so w/e
[03:08:08 CEST] <atomnuker> michaelni: there's something wrong with swr I think
[03:08:45 CEST] <atomnuker> lets say I have a huge buffer of say 13230000 samples I want to resample from 44100 to 48000 hz
[03:09:41 CEST] <atomnuker> and I give it to swr directly and ask for a small amount of samples back, e.g. swr_convert(swr, out, 1024, in, 13230000)
[03:09:58 CEST] <atomnuker> (and of course the number of samples resampled is returned)
[03:10:59 CEST] <atomnuker> if I do this until swr_convert returns 0 I get a total of 21216000 samples back
[03:11:28 CEST] <atomnuker> which at 48000 hz is 442 seconds
[03:11:48 CEST] <atomnuker> but the 13230000 samples I fed in at 44100 are exactly 300 seconds
[03:12:08 CEST] <atomnuker> so swr returned an extra 142 seconds of audio
[03:13:29 CEST] <atomnuker> up until 300 seconds its all fine, then what's resampled is 142 seconds of reversed audio starting from the end
[03:14:09 CEST] <atomnuker> what the fuck is going on?
[03:15:08 CEST] <atomnuker> if I feed in swr say 4096 samples at a time the amount of extra samples at the end gets reduced
[03:16:00 CEST] <atomnuker> and if I reduce that to 1800ish samples I get almost a correct time
[03:25:55 CEST] <michaelni> atomnuker, is this a regression ? and how can this be reproduced ? ... would be ideal if we had a fate test to test such things
[03:26:12 CEST] <atomnuker> no idea if its a regression
[03:26:25 CEST] <atomnuker> it has been this way since May
[03:26:36 CEST] <atomnuker> (when I first used it)
[03:56:48 CEST] <atomnuker> michaelni: https://pars.ee/temp/resample_fail.c
[03:57:18 CEST] <atomnuker> compile with gcc example.c $(pkg-config --libs libavcodec)
[03:58:15 CEST] <atomnuker> put some audio in the buffer and fwrite it, you'll hear the same as what I hear
[04:00:28 CEST] <atomnuker> change const int samples_avail = FFMIN(1800, samples_left); and you'll see it'll be a few thousands longer instead of several hundred seconds
[04:03:18 CEST] <atomnuker> (I guess it could be made into a fate test but its no point testing something that seems to be broken)
[04:13:46 CEST] <michaelni> will take a look when i have time, unless someone else does before
[15:05:33 CEST] <cone-544> ffmpeg 03Paul B Mahol 07master:8d2da0939cbd: avfilter/vf_datascope: make it possible to change pixscope window position
[15:52:58 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:14604087031d: Add single precision planar RGB pixel formats
[15:52:59 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:8b9ae9a8e03c: zscale: Enable single precision input/ouput filtering
[15:53:00 CEST] <cone-544> ffmpeg 03Vittorio Giovara 07master:62dfa2ba14d9: Add tonemap filter
[17:25:09 CEST] <J_Darnley> In a decoder what do I put into the "void *data" argument, and when?
[17:25:15 CEST] <J_Darnley> How do I tell it where the AVFrame is I want to output is when it is ready?
[17:25:50 CEST] <J_Darnley> Do I need to set something other than got_frame to 0 or NULL when I am not outputting anything?
[17:27:01 CEST] <atomnuker> *data always points to an avframe, it just lacks allocated buffers
[17:27:46 CEST] <atomnuker> if you have a frame set *got_frame to 1 and alloc/transfer buffers onto the *data avframe
[17:29:40 CEST] <J_Darnley> Do I just copy/assign the contents of my AVFrame struct into the address data points to then?
[17:30:07 CEST] <atomnuker> you have an internal avframe, right?
[17:30:13 CEST] <J_Darnley> I do now.
[17:30:47 CEST] <atomnuker> then do av_frame_ref(data, internal_av_frame)
[17:30:53 CEST] <J_Darnley> Yes, I leave data untouched.
[17:31:09 CEST] <J_Darnley> okay, I will try that.
[17:33:27 CEST] <J_Darnley> Colour me surprised.
[17:33:41 CEST] <J_Darnley> That seems to work.
[17:34:09 CEST] <J_Darnley> Now we're back to 1 frame of decoding, kierank.
[17:34:36 CEST] <kierank> atomnuker: why av_frame_ref?
[17:34:50 CEST] <kierank> surely that leaves a reference with the internal frame as well
[17:34:55 CEST] <kierank> this is confusing me quite a bit
[17:35:46 CEST] <kierank> J_Darnley: I think we want av_frame_move_ref
[17:36:16 CEST] <J_Darnley> coming right up.
[17:37:20 CEST] <atomnuker> kierank: hm, you're right
[17:37:33 CEST] <atomnuker> (since the internal avframe is reused)
[17:38:09 CEST] <atomnuker> so if you wanted to decode more than 1 frame and do nothing the first one would be junk
[17:40:04 CEST] <J_Darnley> Better, 20 frames output with move_ref
[17:40:58 CEST] <J_Darnley> Runnign valgrind
[17:42:18 CEST] <atomnuker> michaelni: does the swresample patch fix the issue I had?
[17:43:15 CEST] <J_Darnley> Valgrind looks good.
[17:43:28 CEST] <J_Darnley> Do you want the diff, kierank?
[17:43:40 CEST] <kierank> can you send me a git-format path
[17:43:43 CEST] <kierank> patch
[17:44:32 CEST] <J_Darnley> Do you want me to cram it all into one collosal patch?  Not I think there are any changes I could separate.
[17:45:11 CEST] <kierank> yes
[17:45:47 CEST] <J_Darnley> Okay.  I will leave out the printfs though.
[18:02:28 CEST] <kierank> lol 
[18:02:29 CEST] <kierank> I came across your website ffmpeg.org  and you would be good fit to our program focused on international oriented startups and scale-ups that can provide added value for media companies in the areas of content, advertising or technology. Dutch media organizations are actively looking for companies like you. 
[18:12:58 CEST] Action: J_Darnley feels left out of the spam party
[19:31:09 CEST] <durandal_1707> im out of ideas for new filters
[19:31:27 CEST] <atomnuker> durandal_1707: write simd?
[19:31:56 CEST] <atomnuker> (transpose is slow and doesn't have simd, but at least it does slice threading)
[19:35:20 CEST] <durandal_1707> how would you transpose simd?
[19:36:10 CEST] <BtbN> the color/chromakey filters could also use some work
[19:36:43 CEST] <BtbN> They are very simplistic and slow. Made them in the hopes for there to be enough interest to get them improved, but so far that didn't happen
[19:37:05 CEST] <atomnuker> durandal_1707: lookup tables
[19:38:07 CEST] <J_Darnley> durandal_1707: have a holiday
[19:38:12 CEST] <durandal_1707> atomnuker: that doesnt makes sense?
[19:39:36 CEST] <atomnuker> durandal_1707: you're right, it doesn't, transpose only has moves, no multiplies
[19:41:06 CEST] <durandal_1707> vs have simd, but there is no nice way to bench it
[19:43:12 CEST] <J_Darnley> if you're desperate for something to do you could finish that differencemax mode I proposed for overlay or blend
[19:50:27 CEST] <kierank> durandal_1707: lipsynctest filter with correct 1601 NTSC support ;)
[19:56:40 CEST] <durandal_1707> kierank: what?
[19:57:21 CEST] <kierank> Filter to generate lipsync test but working correctly with ntsc
[19:57:27 CEST] <kierank> So 1601, 1602 pattern
[21:51:34 CEST] <michaelni> atomnuker, it should fix the issue you reported yesterday
[22:32:18 CEST] <durandal_1707> atomnuker: posted patch that speeds up transpose filter
[22:37:36 CEST] <atomnuker> durandal_1707: lgtm'd
[22:37:40 CEST] <atomnuker> michaelni: I'll test it now
[22:46:02 CEST] <atomnuker> michaelni: patch lgtm'd, tested and works, thanks alot
[23:15:15 CEST] <durandal_1707> why are compilers shit?
[23:16:19 CEST] <durandal_1707> i created inline function of 2 hardcoded parameters that are used in loops and speed was raised with inlined function
[23:16:57 CEST] <durandal_1707> its just hardcoding w and h
[23:17:43 CEST] <TD-Linux> look at the assembly
[23:18:20 CEST] <durandal_1707> why its just hardcoded loop number
[23:18:52 CEST] <TD-Linux> you're comparing hard coding and not hard coding?
[23:19:03 CEST] <durandal_1707> and compiler is instructed to not add own simd code
[23:19:20 CEST] <durandal_1707> TD-Linux: just loop numbers
[23:20:17 CEST] <TD-Linux> it can still copy larger chunks at once (and potentially unroll without lead in/out). look at the assembly
[23:21:23 CEST] <atomnuker> even with tree vectorization off gcc still vectorized some simple shifts + movs double loops
[00:00:00 CEST] --- Wed Aug 16 2017