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

[burek]

[03:27:51 CEST] <cone-263> ffmpeg 03Karsten Otto 07master:3bf39f2aeff0: libavcodec/mpegaudiodecheader.h : detect reserved mpeg id
[03:27:51 CEST] <cone-263> ffmpeg 03Karsten Otto 07master:6cc6b619b951: aadec: add chapters and seeking
[11:33:42 CEST] <haasn> atomnuker: I wonder if we could make a fast vulkan crop detection filter
[12:03:41 CEST] <atomnuker> what did a crop detection filter do again?
[12:05:37 CEST] <haasn> detect black bars in the image
[12:05:43 CEST] <haasn> and export metadata about what --crop filter to set to remove them
[12:06:24 CEST] <atomnuker> does it detect black bars around all edges or just left/right?
[12:09:59 CEST] <haasn> all edges
[12:10:04 CEST] <haasn> I think top/bottom is more common than left/right
[12:10:11 CEST] <haasn> for 21:9 movies and stuff
[12:10:32 CEST] <haasn> question would be, how much information do you need to decide that something is definitely a black edge
[12:10:43 CEST] <haasn> and how tolerant should it be to edge smear due to lossy encoding
[12:11:03 CEST] <haasn> also what would be cool is if it can do it in realtime, i.e. if the black bar stops being a black bar in one scene
[12:11:18 CEST] <haasn> for movie with mixed 16:9 and 21:9 aspect ratios
[12:11:29 CEST] <haasn> (e.g. one of the black knight movies did this)
[12:11:35 CEST] <haasn> dark knight w/e
[12:12:22 CEST] <atomnuker> I suppose the most optimal way of doing this would be to have each workgroup process a line by doing some rolling average of say a few pixels until it ticks over a treshold
[12:12:59 CEST] <atomnuker> and then with atomics you could average all workgroups' averages so you get a more or less accurate edge
[12:22:26 CEST] <haasn> well you'd want to make sure the deviation isn't too high
[12:22:28 CEST] <atomnuker> I'd do something but I need to implement the semaphore waiting on frames rather than using fences
[12:23:11 CEST] <haasn> that might require two passes, or CPU postprocessing
[12:23:18 CEST] <haasn> well you need the data on the CPU anyway I guess
[12:23:23 CEST] <haasn> unless you generate vertex buffer information using the shader.. hah
[12:23:24 CEST] <atomnuker> what for?
[12:23:26 CEST] <haasn> that would be a cool parlor trick
[12:23:31 CEST] <haasn> well for setting the --crop parameters
[12:23:53 CEST] <haasn> or do you mean why make sure the deviation isn't too high?
[12:24:03 CEST] <haasn> imagine you have a dark scene where there's a large shadow blob that goes into the edge of the frame
[12:24:13 CEST] <haasn> some of those work groups are going to have much higher values for the edge estimate as a result
[12:24:24 CEST] <atomnuker> no, was wondering why you'd need the info on the CPU, I thought you referred to having the entire frame on system RAM
[12:24:26 CEST] <haasn> if anything you want to use the _minimum_ value
[12:24:30 CEST] <haasn> of all the work groups
[12:24:34 CEST] <haasn> not the averagfe
[12:24:50 CEST] <haasn> or maybe the lowest 5% value
[12:25:15 CEST] <atomnuker> but the minimum will be affected by blurring around the edges cased by e.g. compression, so I think the average would work better
[12:25:54 CEST] <haasn> well ideal would be some sort of low-biased average that discards high outliers
[12:26:03 CEST] <haasn> maybe the average to some power
[12:26:41 CEST] <haasn> or imagine sorting all of the entries and then taking not the first value but the value at 1/10th the way through
[12:26:45 CEST] <atomnuker> yeah, that would work, then blotches of black spanning inside the cropped line wouldn't get detected
[12:27:09 CEST] <atomnuker> yeah, you're right, maybe starting from a min value would work better
[12:27:52 CEST] <haasn> each thread could process one vertical line at once and write the result to an SSBO at index n
[12:28:11 CEST] <haasn> while also counting how often each value occurs in a second SSBO containing atomics
[12:28:17 CEST] <haasn> then you could arrange them in-place in O(1) on a second pass
[12:28:21 CEST] <haasn> to get a sorted array
[12:28:27 CEST] <haasn> for O(n) overall
[12:46:48 CEST] <atomnuker> but qsort is at best N*log(N), or by arrange did you mean a simple min/max?
[13:00:03 CEST] <haasn> https://en.wikipedia.org/wiki/Counting_sort
[13:00:35 CEST] <haasn> the simplest sorting algorithm :p
[20:37:16 CEST] <jamrial> jkqxz: if you can look at the patchset i just sent whenever you have time, regarding the comments i added and to be sure you're ok with it
[20:41:50 CEST] <BBB> is cbs the same as bsf?
[20:43:05 CEST] <nevcairiel> cbs is an internal framework to write bitstream parsing components
[20:43:16 CEST] <nevcairiel> doesnt have to be a bsf, although most p robably are
[20:45:23 CEST] <jamrial> BBB: check vaapi h264 encoder and some bsfs like vp9_metadata to see how it works
[20:45:54 CEST] <jamrial> it's pretty neat and powerful, especially to read and parse supported bitstreams
[20:45:58 CEST] <BBB> ok
[20:46:06 CEST] <BBB> I was hoping to see a av1 bsf sometime soon
[20:46:09 CEST] <BBB> nice to see it already :)
[20:47:28 CEST] <nevcairiel> what would a av1 bsf do if you want? =p
[20:47:37 CEST] <nevcairiel> bsfs need a purpose
[20:48:18 CEST] <jamrial> same as the other metadata ones
[20:48:25 CEST] <jamrial> change color and timing info
[20:48:35 CEST] <jamrial> insert and remove obus
[20:49:21 CEST] <jamrial> inserting temporal delimiter OBUs will be necessary, for example
[20:50:14 CEST] <jamrial> to remux from mp4/mkv to ivf, or maybe also for the eventual hardware decoders
[20:51:07 CEST] <jamrial> adding a size field to OBUs that don't have one
[20:51:50 CEST] <jamrial> av1 bsfs have a lot of posibilities, unlike vp9 which was color info and that's it :p
[20:53:35 CEST] <cone-464> ffmpeg 03Karsten Otto 07n3.2.11:HEAD: aadec: add chapters and seeking
[21:41:17 CEST] <pkeroulas> atomnuker: hello, could you give your feeling about interlaced smpet2110-20? https://patchwork.ffmpeg.org/patch/9076/
[21:42:10 CEST] <atomnuker> pkeroulas: merge the patch with the patch which implements support for allocating that side data type
[21:43:47 CEST] <pkeroulas> alright, thanks
[21:44:56 CEST] <pkeroulas> anything else?
[21:47:28 CEST] <atomnuker> give links to the other patches
[21:52:28 CEST] <pkeroulas> https://patchwork.ffmpeg.org/patch/9077/ and https://patchwork.ffmpeg.org/patch/9079/
[21:56:05 CEST] <kierank> SDP lol
[21:56:07 CEST] <kierank> nobody is using sdp
[21:59:38 CEST] <atomnuker> tru dat, I don't get why sdp is needed like at all
[22:01:46 CEST] <atomnuker> pkeroulas: check that frame_size is mod 2 when you check its larger than the packet size
[22:02:06 CEST] <atomnuker> or are non-mod2 resolutions supported?
[22:03:09 CEST] <atomnuker> that checking bit of code seems fragile to me
[22:04:14 CEST] <atomnuker> what the fuck
[22:04:20 CEST] <atomnuker> bc->cur_interlaced_frame = av_frame_alloc();
[22:04:24 CEST] <atomnuker> you're leaking this per-frame
[22:04:38 CEST] <atomnuker> in case of progressive
[22:05:32 CEST] <atomnuker> oh, that's in the init function, nevermind
[22:06:42 CEST] <atomnuker> the field variable is uninizialized when there's no side data
[22:07:18 CEST] <atomnuker> "AVAncillaryData * ancillary;" coding style issues
[22:09:41 CEST] <atomnuker> rest doesn't look bad
[22:26:27 CEST] <pkeroulas> frame_size is always mod 2 (*20LL), width mod 2 is checked but height check is missing
[00:00:00 CEST] --- Tue Jul 10 2018