Current Server Time: 23:29 (Central Europe)

#apertus IRC Channel Logs

2016/02/29

Timezone: UTC


00:20
jucar
left the channel
01:45
RexOr
left the channel
01:45
RexOr
joined the channel
01:48
aombk2
left the channel
02:42
John_K
joined the channel
03:43
baldand_
joined the channel
03:50
baldand
left the channel
03:50
mithro
Bertl_zZ: so, if you need a whole bank to operate at either 3V3 or 1V8 you can actually make that happen
04:08
RexOr
left the channel
05:57
tezburma
joined the channel
06:33
se6astian|away
changed nick to: se6astian
07:15
Guest59104
left the channel
07:22
rexbron
left the channel
07:36
rexbron
joined the channel
07:44
rexbron
left the channel
07:45
Bertl_zZ
changed nick to: Bertl
07:45
Bertl
morning folks!
07:45
rexbron
joined the channel
07:45
Bertl
mithro: how? switching I/O voltage on the fly on an FPGA seems to require reconfiguration
07:49
rexbron
left the channel
07:55
rexbron
joined the channel
07:59
rexbron
left the channel
08:00
rexbron
joined the channel
08:01
jucar
joined the channel
08:06
pusle
joined the channel
08:07
rexbron
left the channel
08:08
rexbron
joined the channel
08:12
faab64
joined the channel
08:18
tezburma
left the channel
08:20
jucar
left the channel
08:22
John_K
morning Bertl!
08:22
John_K
How is the power board testing going?
08:23
tezburma
joined the channel
08:28
Bertl
John_K: I hit a minor issue when trying to bitbang the ACBUS signals
08:29
Bertl
requires to upload an eeprom configuration (already done) and special commands (I'm working on that :)
08:29
John_K
ah yes, D2XX library :)
08:34
Bertl
but it looks good so far
08:36
aombk
joined the channel
08:58
Bertl
off for now ... bbl
08:58
Bertl
changed nick to: Bertl_oO
09:11
faab64
left the channel
10:55
mithro
Bertl_oO: I've seen it done with two stage FPGA config, IE you load one "boot loader" which configures things, then load a "second stage" which has the program which actually runs
10:55
mithro
Bertl_oO: I wonder if it would work with partial reconfiguration
10:56
mithro
Bertl_oO: oh, some of the standards on the Xilinx FPGAs use VCC-aux, while some use VCCIO of the bank
11:28
Bertl_oO
changed nick to: Bertl
11:29
Bertl
back now ...
11:30
Bertl
yeah, while I'm sure a recondiguration would work, the sequence to switch VCCIO together with that reconfiguration is probably very problematic
11:30
Bertl
*reconfiguration
12:01
mnicoletti
left the channel
12:45
Bertl
off again ... bbl
12:45
Bertl
changed nick to: Bertl_oO
13:39
getzi
joined the channel
14:49
cbohnens
changed nick to: cbohnens|away
14:53
tezburma
left the channel
14:59
getzi
left the channel
15:06
tezburma
joined the channel
15:33
getzi
joined the channel
16:16
se6astian
time to leave the office
16:16
se6astian
changed nick to: se6astian|away
17:14
se6astian|away
changed nick to: se6astian
17:23
alexML_
been hunting a bug in the filters stuff in the last few hours
17:23
Bertl_oO
okay?
17:24
alexML_
it appears to be a bug in ffmpeg
17:24
Bertl_oO
interesting
17:24
alexML_
I assumed that ffmpeg -vcodec copy does just that - copies exactly
17:25
alexML_
but, if I extract a PPM from a shogun MOV (let's say the first frame), and then I extract the same frame from a copied MOV (with -vcodec copy), the output is different
17:26
alexML_
http://files.apertus.org/AXIOM-Beta/snapshots/tmp/direct.jpg
17:26
alexML_
http://files.apertus.org/AXIOM-Beta/snapshots/tmp/copied.jpg
17:26
Bertl_oO
nice
17:27
Bertl_oO
well, could be a color space issue
17:27
Bertl_oO
i.e. transformation or misinterpretation of color ranges, etc
17:30
alexML_
indeed, a matrix transformation explains the difference between the two almost completely
17:30
Bertl_oO
so maybe limited vs full range?
17:31
alexML_
no, range is the same
17:32
alexML_
Stream #0:1(eng): Video: prores (apch / 0x68637061), yuv422p10le(bt709), 1920x1080, 470399 kb/s, SAR 1:1 DAR 16:9, 60 fps, 60 tbr, 6k tbn, 6k tbc (default)
17:32
alexML_
Stream #0:0(eng): Video: prores (apch / 0x68637061), yuv422p10le, 1920x1080, 470138 kb/s, 60 fps, 60 tbr, 12k tbn, 12k tbc (default)
17:32
alexML_
first is shogun, second is copied
17:32
alexML_
one uses bt709, the other... probably 601
17:33
alexML_
does it count as a bug in ffmpeg? (as in, should we report it?)
17:34
alexML_
(I encountered it while trying to get something from the team talk footage)
17:39
Bertl_oO
the main question is, can you easily change it?
17:39
alexML_
I can work around it with that matrix
17:39
Bertl_oO
i.e. with an option specifying the "proper" color space?
17:40
Bertl_oO
with something like colormatrix=bt709 or so?
17:40
alexML_
yeah, that should work
17:41
Bertl_oO
then I wouldn't consider it a bug, but nevertheless report the issue to the ffmpeg folks
17:41
alexML_
well, my expectation was to get identical output in both cases
17:41
Bertl_oO
maybe there is a good reason _why_ it changes
17:42
alexML_
idk, on Canon MOV I get identical output
17:42
Bertl_oO
e.g. different output color space, missing information, etc
17:42
intracube
it looks like a bug
17:43
intracube
even if ffmpeg is changing the metadata or container format slightly, the raw stream should be the same bitrate
17:44
Bertl_oO
which has no relation to the interpretation though
17:46
intracube
what do you mean?
17:46
Bertl_oO
the very same bitstream, considered as "limited range RGB" for example instead of "full range RGB" will result in quite a different image
17:46
alexML_
I guess the bitrate printed there is just an approximation (may include overhead, metadata), but for sure it's not recompressing (it's very fast)
17:47
intracube
Bertl_oO: oh, yep. of course
17:47
Bertl_oO
and I think that is what alexML_ is seeing here
17:57
alexML_
this one appears to get somewhat closer visually: -vf "colormatrix=bt709:bt601" -pix_fmt rgb48 (also tried bt601:709), but standard deviation of the difference image gets much worse in both cases
18:04
intracube
alexML_: what are you using to decode/playback?
18:05
intracube
if you force a colour space for the decode, you shouldn't see any differences between the encoded streams
18:07
alexML_
ffmpeg input.mov output.ppm
18:07
alexML_
can you suggest a command line that I could try?
18:22
intracube
alexML_: last time I tried, the ffmpeg colormatrix param didn't work as expected
18:23
intracube
I found other people having similar issues
18:23
intracube
iirc, I used mplayer/mencoder instead
18:25
John-K
joined the channel
18:25
intracube
got to eat now, but I'll see if the matrix command works any better after
18:25
intracube
*since I last tried it
18:26
baldand_
left the channel
18:28
baldand
joined the channel
18:33
getzi
left the channel
18:34
John-K_
joined the channel
18:34
John-K
left the channel
18:59
tezburma
left the channel
19:03
jucar
joined the channel
19:13
aombk
https://media.giphy.com/media/xT9DPl04nNfIDClaLu/giphy.gif
19:13
davidak
yep, scary future
19:24
intracube
alexML_: I tried the colormatrix setting again and it doesn't work when outputting a png image sequence
19:25
intracube
but translating color between regular codecs (libx264 in and out) at least shows some change
19:25
intracube
eg:
19:25
intracube
ffmpeg -i default.mp4 -vf colormatrix=bt709:bt601 bt709_to_bt601.mp4
19:25
intracube
and
19:25
intracube
ffmpeg -i default.mp4 -vf colormatrix=bt601:bt709 bt601_to_bt709.mp4
19:25
intracube
codec is libx264
19:26
intracube
but: ffmpeg -i default.mp4 -vf colormatrix=bt601:bt709 %04d.png doesn't produce any different output to:
19:26
intracube
ffmpeg -i default.mp4 -vf colormatrix=bt709:bt601 %04d.png
19:27
intracube
and with libx264, I don't know if it's doing the *correct* transform
19:27
alexML_
I've identified some change as well, but not in the right direction
19:28
intracube
outputting image sequences or prores?
19:31
alexML_
I'm working on a single frame for now, so I output just one ppm
19:34
John-K
joined the channel
19:34
John-K_
left the channel
20:15
intracube
https://ffmpeg.org/pipermail/ffmpeg-user/2012-July/007833.html
20:15
intracube
alexML_: ^
20:16
intracube
might be a complication (assuming this hasn't been fixed since 2012)
20:16
intracube
specifically: "ffmpeg always assumes the BT.601 colorspace when converting from RGB->YUV and from YUV->RGB. A patch to fix this is welcome, but no one has ever cared enough to provide it."
20:21
intracube
not sure if it's relevant for what you're doing
20:24
intracube
eh, probably not
20:24
intracube
just reread this topic from the start
20:28
alexML_
well, for what I'm doing, I don't really care in what exact color space it is, because I'm going to profile it anyway (I just need it to be consistent for all files)
20:43
se6astian
off to bed
20:43
se6astian
good night
20:43
se6astian
changed nick to: se6astian|away
20:46
Bertl_oO
nn
20:55
intracube
alexML_: isn't it an issue in so far as the YUV->RGB might end up clipping some values in the gamut?
20:55
intracube
so the profile will be based on an image with lost data?
20:58
alexML_
for what I'm doing, no
21:00
alexML_
because value range in those files is about 10000 - 50000, so it's quite hard to get it to overflow from this bug
21:01
intracube
ah ok
21:35
Bertl_oO
off to bed now ... have a good one everyone!
21:35
Bertl_oO
changed nick to: Bertl_zZ
21:37
mithro
TimVideos got into Google summer of code!
21:38
mithro
If anyone is interested in cross project collaboration as part of it, do like me!
22:02
davidak
left the channel
22:11
aombk2
joined the channel
22:15
aombk
left the channel
22:18
John-K
left the channel
22:47
jucar
left the channel