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

[burek]

[01:28:05 CEST] <cone-914> ffmpeg 03Jerome Borsboom 07master:1cf6129d13a3: avcodec/vc1: fix condition guarding overlap filter on I picture
[01:28:05 CEST] <cone-914> ffmpeg 03Jerome Borsboom 07master:f92e95e9b5af: avcodec/vc1: change the internal ordering of blocks within a macroblock
[01:28:06 CEST] <cone-914> ffmpeg 03Jerome Borsboom 07master:975a1a81b28d: avcodec/vc1: fix overlap filter for frame interlaced pictures
[01:28:08 CEST] <cone-914> ffmpeg 03Jerome Borsboom 07master:efde2a70ffe6: avcodec/vc1: fix check for missing CBPTAB
[01:35:21 CEST] <cone-914> ffmpeg 03Carl Eugen Hoyos 07master:27662ed681cb: Changelog: Mention vc1 improvements by Jerome Borsboom.
[10:41:30 CEST] <kierank> gagandeep: ask durandal_1707 to explain threading
[10:42:24 CEST] <gagandeep> should i read pngdec.c also
[10:46:02 CEST] <atomnuker> slice threading is trivial
[13:01:24 CEST] <atomnuker> is there something like av_clip_uintp2 which zeroes out <bits> MSBs instead of clipping?
[13:01:55 CEST] <nevcairiel> you mean like a binary and?
[13:02:00 CEST] <nevcairiel> why do you need a function for that?
[13:06:02 CEST] <atomnuker> atrac9 weirdness, the RE'd decoder calls this SignExtend32 (which just does (val << bits) >> bits, where bits = 32 - zero_bits)
[13:06:42 CEST] <jdarnley> I think I've seen a sign extend macro/func somewhere
[13:07:00 CEST] <jdarnley> But that adds 1s
[13:10:38 CEST] <atomnuker> its very weird, for some reason the scalefactor delta from get_vlc2() has to be truncated to the maximum length of a code of the huffman table
[13:11:11 CEST] <atomnuker> which doesn't make sense because get_vlc2() shouldn't output more than the number of bits of the maximum length of a huffman symbol of the table
[13:30:39 CEST] <atomnuker> oh, its because the top bit is the sign bit, and its included as the first bit in the huffman tables
[14:49:00 CEST] <durandal_1707> atomnuker: so you are going to complete atrac9?
[15:24:26 CEST] <atomnuker> durandal_1707: yeah, I'm on it
[18:14:16 CEST] <atomnuker> atrac9 wtf
[18:14:42 CEST] <atomnuker> each coefficient isn't sent as a huffman coded value
[18:15:13 CEST] <atomnuker> instead you get a huffman coded value which has each coefficient in a small, constant size bitstream
[18:15:44 CEST] <atomnuker> usually 4 coefficients with 2 bits each
[00:00:00 CEST] --- Sat Jun 30 2018