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

[burek]

[00:04:54 CET] <llogan> michaelni: i looked at 6 randomish proposed changes by your script and it seemed fine
[00:27:20 CET] <michaelni> llogan, ok thanks, will run the commands then, they should improve the status on average then at least
[14:52:52 CET] <atomnuker> "SVT-AV1 support a compressed 10-bit format"
[14:53:03 CET] <atomnuker> yes, as in packed 10 bit, no padding
[14:53:58 CET] <atomnuker> "to achieve a higher speed and channel density levels." <- right, they're high
[14:54:18 CET] <JEEB> so they did packing and then compress that too?
[14:54:24 CET] Action: JEEB golfclaps
[14:55:02 CET] <atomnuker> well, its an encoder, so either they based their whole thing around packed 10bit (e.g. you need a bitstream reader to read a pixel e.g. they're beyond nuts) or they uncompress it for you
[15:20:09 CET] <thardin> I thought it was Sveriges Television at first
[15:20:43 CET] <thardin> and I was excited that they're doing things that benefit the free software world
[15:20:46 CET] <thardin> but alas
[15:21:35 CET] <thardin> 48GB to encode 4k, yikes
[15:26:43 CET] <gnafu> thardin: In realtime across over 100 cores.  I'm not sure if non-realtime modes across fewer cores would need as much RAM.
[15:27:03 CET] <gnafu> I'm hoping to play with it on much more meager machines and see what happens :-).
[15:27:19 CET] <thardin> realtime eh?
[15:27:33 CET] <thardin> sounds a bit like poor man's FPGA
[15:27:45 CET] <gnafu> thardin: Hehe.
[15:28:02 CET] <gnafu> Or a rich man's, since I imagine realtime 4K requires Intel's most expensive processors.
[15:34:17 CET] <gnafu> atomnuker: It looks like the packed 10-bit input is optional, and it can still take 8-bit yuv420p.
[15:34:30 CET] <gnafu> (Or 10-bit yuv420ple.)
[15:34:46 CET] <gnafu> (Err, yuv420p10le.)
[15:41:38 CET] <thardin> good point :)
[15:42:00 CET] <thardin> actually that very much sounds like typical cluster stuff
[15:42:24 CET] <thardin> an MPI based encoder would make a lot of sense for a format as complex as AV1
[15:44:18 CET] <nevcairiel> mthe 
[15:44:37 CET] <nevcairiel> the SVT things are  strongly focused on scaling to endless resources
[15:45:25 CET] <thardin> I guess realtime implies broadcast or large streamer at the very least. would be hard to justify needing an entire rack or two of machines for the bandwidth savings otherwise
[15:46:21 CET] <thardin> hrm, perhaps I should fix up the patches I've been working on the last few weeks so they can be pushed
[15:46:35 CET] <thardin> .. after the next meeting
[19:09:33 CET] <trfl> looks like trac exploded https://trac.ffmpeg.org/
[19:10:42 CET] <durandal_1707> all bug reports lost, finally!
[19:16:32 CET] <kurosu_> realtime over 100 cores? what is that? 4* E7-8890 v4 or some Platinum 81xy with xy>50 or some such? around 20K for that system?
[19:17:29 CET] <kurosu_> s/that system/just the CPUs
[19:17:30 CET] <nevcairiel> their hevc encoder has quoted realtime numbers for the Platinum 8180
[19:17:41 CET] <nevcairiel> so probably in that area
[19:18:55 CET] <kurosu_> codecs: everybody loses, but Intel
[19:19:33 CET] <nevcairiel> hardware costs are mostly irrelevant for big companies anyway
[19:20:21 CET] <nevcairiel> 10k for one cpu seems unthinkable, but there is still racks full of that =p
[19:26:40 CET] <kurosu_> encoding videos of cats
[19:26:54 CET] <nevcairiel> of course
[20:59:29 CET] <cone-278> ffmpeg 03Jun Zhao 07master:6c586303a14a: lavfi/nlmeans: improve the performance
[20:59:30 CET] <cone-278> ffmpeg 03Clément BSsch 07master:65e61febc8ad: lavfi/nlmeans: simplify log() call
[20:59:31 CET] <cone-278> ffmpeg 03Clément BSsch 07master:1a9c6cc41102: lavfi/nlmeans: use a dynamic size for the weight LUT
[21:16:27 CET] <JEEB> how many here have tried out videolan's gitlab merge request flow and think of it positively btw?
[21:22:52 CET] <atomnuker> its meh, no better than github
[21:23:51 CET] <atomnuker> I think by default pushers should be able to rebase PRs as they merge them but currently they need permission from the author
[21:24:14 CET] <JEEB> possibly because it's considered still a branch in the author's repo
[21:25:52 CET] <atomnuker> at least it doesn't make merge commits
[21:26:14 CET] <JEEB> that's configurable @ github as well
[21:26:24 CET] <JEEB> w/39
[21:26:27 CET] <JEEB> whoops
[23:18:54 CET] <JEEB> if anyone is still awake, feel free to check out the two commits on the top of https://github.com/jeeb/ffmpeg/commits/mpegts_arib_stuff_upstreaming
[23:19:02 CET] <JEEB> if those look good I'll post them on the ML :)
[23:19:53 CET] <cone-278> ffmpeg 03Carl Eugen Hoyos 07master:73d4efc596ad: lavu/imgutils: Use FFABS() instead of abs() for ptrdiff_t.
[00:00:00 CET] --- Sat Feb  2 2019