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

[burek]

[00:47:03 CET] <ItWasntMe2013> does anyone have any addtional suggestions when converting interlaced video to progressive?   other than deinterlacing, are there any other options that I can use to get rid of the ghosting video in high motion scenes?
[00:56:10 CET] <llamapixel> Is that a job for https://ffmpeg.org/ffmpeg-all.html#mpdecimate  ?
[00:56:25 CET] <llamapixel> https://ffmpeg.org/ffmpeg-all.html#decimate-1
[02:21:17 CET] <fling> How to capture a fast seekable low-fps h264 stream?
[02:21:24 CET] <fling> Should I mangle with i-frames?
[02:21:32 CET] <fling> Or should I use another codec instead?
[02:21:52 CET] <fling> The problem is it does not seek right when I capture with 1/5 or 1/6 or so fps
[02:22:37 CET] <fling> I'm capturing a screencast with a webcam in a separate stream.
[02:23:05 CET] <fling> I encode low-fps screencast with the fps matching to webcam to keep all the streams in sync to the audio btw
[02:23:20 CET] <fling> Lots of dupes! But atleast it is at sync.
[02:23:29 CET] <fling> The last step is to improve seeking :>
[02:24:04 CET] <fling> mpv seeks +-20minutes :D
[02:28:00 CET] <fling> hmmm hmmm new issue is Invalid audio PTS: 10081.370449 -> 10082.365000 but I will fix this later
[02:30:14 CET] <fling> ok the audio has the wrong rate in some files, not a huge issue
[03:02:40 CET] <onurhb> Is this right place to ask for help related to linking ffmpeg with my c++ project? :)
[03:06:06 CET] <klaxa> it is not the wrongest place
[04:12:32 CET] <llamapixel> Today is no f day you have to omit any f letters in your question when it is c++ related.
[04:13:15 CET] <thebombzen> fling: what do you mean by "capture" a fast seekable low-fps h264 stream
[04:14:37 CET] <furq> how are you going to discuss c++ without f words
[04:19:09 CET] <llamapixel> ucking diicult furq ;)
[04:35:56 CET] <thebombzen> >furq
[04:36:00 CET] <thebombzen> oops
[05:00:57 CET] <fling> thebombzen: Hello. something like this for a single stream -> ffmpeg -f x11grab -video_size cif -framerate 1/6 -i :0.0 -r 29.97 /tmp/single.nut
[05:01:12 CET] <thebombzen> um
[05:01:20 CET] <fling> thebombzen: -r 29.97 specified at the end to match the stream of a webcam to make them both in sync with audio
[05:01:34 CET] <thebombzen> you do realize that this won't work unless your screen is actually size cif
[05:01:39 CET] <thebombzen> and is actually framerate1/6
[05:01:50 CET] <fling> Just try this command /tmp/single.nut is not really seekable. ff and rev want to move the time pointer by +-20 minutes :>
[05:01:58 CET] <thebombzen> -video_size and -framerate are input options that describe your screen
[05:02:01 CET] <fa0> hello all
[05:02:24 CET] <fling> thebombzen: the screen has no framerate.
[05:02:32 CET] <thebombzen> it has a refresh rate
[05:02:41 CET] <fling> Should I capture at refresh rate?
[05:02:43 CET] <thebombzen> and the video size of the screen isn't cif, is it?
[05:02:47 CET] <thebombzen> cause
[05:02:56 CET] <thebombzen> if the screen you're capturing isn't cif, this will be problematic.
[05:02:58 CET] <fa0> Can someone please tell me for 3.2.2 does it matter if I use speex-1.2rc2 or is it better to use speex-1.2rc3?
[05:02:59 CET] <fling> thebombzen: for this example it only takes left top corner for smaller output
[05:03:26 CET] <thebombzen> fa0 it's probably irrelevant but you can always update it later
[05:03:31 CET] <thebombzen> without rebuilding ffmpeg
[05:03:36 CET] <thebombzen> in case it does matter
[05:04:14 CET] <fa0> I've always used rc2 then I noticed on the site; https://www.speex.org/downloads/ Current Unstable Release (recommended) for rc3
[05:04:15 CET] <fa0> hmm
[05:04:40 CET] <fa0> I guess that word 'Unstable' has me wondering LOL
[05:04:44 CET] <thebombzen> well that means it has bugs
[05:04:48 CET] <thebombzen> but it shouldn't affect ffmpeg
[05:04:55 CET] <fa0> hey what doesn't have bugs
[05:04:58 CET] <thebombzen> fling: either way
[05:05:07 CET] <fa0> I assumed rc2 was probably no better/worse...
[05:05:14 CET] <thebombzen> I'm not sure why you're just straight up encoding to nut without specifying a codec
[05:05:24 CET] <thebombzen> that'll use 200kb/s mpeg4
[05:05:43 CET] <fling> whoops ;>
[05:06:00 CET] <thebombzen> also
[05:06:03 CET] <thebombzen> what do you mean it's not seekable
[05:06:06 CET] <thebombzen> it totally is
[05:06:15 CET] <fling> it is not for me :<
[05:06:20 CET] <fa0> I guess I'll just stick to rc2 for now thanks
[05:06:58 CET] <fling> thebombzen: the time scale drops to 0 when I'm trying to ff in mpv
[05:07:33 CET] <thebombzen> I can't reproduce that.
[05:07:34 CET] <thebombzen> works fine for me.
[05:07:44 CET] <thebombzen> I captured like 30 seconds and then seeked it fine.
[05:07:54 CET] <fling> Btw will not it be a huge overhead capturing at screen refresh rate and then converting to 1/6 (low) fps and then to 29.97 (matching other stream) fps?
[05:08:13 CET] <fling> What is your ffmpeg version?
[05:08:27 CET] <fling> I also tried on windows with gdigrab with the same results!
[05:08:37 CET] <fling> Or is it my mpv bad?
[05:10:52 CET] <fling> the doc says it is fine to specify video size and framerate for x11grab https://ffmpeg.org/ffmpeg.html#X11-grabbing
[05:11:47 CET] <fling> thebombzen: another question is not it possible to keep multiple videos in sync if they are encoded at different fps?
[05:12:04 CET] <thebombzen> me? my ffmpeg is build nightly
[05:12:08 CET] <thebombzen> so it's git master
[05:12:58 CET] <fling> mine is 2 days old
[05:13:15 CET] <thebombzen> and no the doc definitely doesn't say that
[05:14:00 CET] <fling> thebombzen: then what would be the proper command?
[05:17:52 CET] <thebombzen> depends on what your screen size is
[05:17:56 CET] <thebombzen> and what your refresh rate is
[05:18:38 CET] <fling> thebombzen: from xrandr output -> 1280x800      60.00*+  50.00
[05:19:13 CET] <thebombzen> well, that.
[05:23:52 CET] <fling> thebombzen: are you saying I should capture at this size and rate and then crop and change fps with vf?
[05:24:01 CET] <thebombzen> yes
[05:24:14 CET] <thebombzen> -vf framerate and -vf scale
[05:24:18 CET] <thebombzen> or rather
[05:24:20 CET] <thebombzen> -vf crop
[05:24:22 CET] <thebombzen> both work
[05:24:29 CET] <thebombzen> depending on what you're trying to do
[05:26:42 CET] <fling> thebombzen: trying to capture a seekable low-fps screencast
[05:26:56 CET] <thebombzen> "screencast"
[05:27:06 CET] <thebombzen> you realize x11grab captures your actual screen right
[05:27:14 CET] <fling> right
[05:27:27 CET] <thebombzen> that's not capturing a screencast
[05:27:28 CET] <thebombzen> tha'ts just
[05:27:32 CET] <thebombzen> capturing your screen
[05:27:37 CET] <fling> right
[05:28:01 CET] <thebombzen> what exactly are you trying to do
[05:28:07 CET] <thebombzen> cause your screen isn't exactly seekable
[05:28:18 CET] <thebombzen> whatever is on the screen at the moment is what you get
[05:30:02 CET] <fling> A screencast is a digital recording of computer screen output, also known as a video screen capture, often containing audio narration.
[05:30:12 CET] <fling> This is what I do.
[05:30:37 CET] <fling> I also include a video captured from webcam as another video stream
[05:32:16 CET] <thebombzen> okay but
[05:32:20 CET] <thebombzen> why is it seekable
[05:32:27 CET] <thebombzen> if you capture the screen and write it to a file
[05:32:32 CET] <thebombzen> it's now just a video file.
[05:32:39 CET] <thebombzen> so it's seekable.
[05:32:51 CET] <thebombzen> but the original capturing is not.
[05:33:03 CET] <fling> I will try using vf instead, hope it will fix the issue
[05:33:18 CET] <fling> The file produced by the command ^ is not seekable by my mpv
[05:33:27 CET] <thebombzen> then your mpv is borked.
[05:54:01 CET] <thebombzen> fa0 when they same something is unstable or has bugs
[05:54:08 CET] <thebombzen> what they mean is that it hasn't gone through extensive testing
[05:54:17 CET] <thebombzen> so there's no general expectation that it should work
[05:54:32 CET] <thebombzen> a "stable" build is a build that has lots and lots of testing and works pretty consistently.
[06:33:43 CET] <Abbott> I am trying to rotate a now horizontal video with no (helpful) metadata using: "ffmpeg -i input.mp4 -vf "rotate=90*(PI/180),format=yuv420p" -metadata:s:v rotate=0 -codec:v libx264 -codec:a copy output.mp4" as suggested here: http://superuser.com/questions/578321/how-to-rotate-a-video-180-with-ffmpeg
[06:34:24 CET] <Abbott> The video I get is flipped, but the original width seems to be preserved, as the video is now square. Is there a different way to flip 90 degrees?
[06:45:46 CET] <llamapixel> Abbott: ffmpeg -i in.mov -vf "transpose=1" out.mov
[06:46:06 CET] <llamapixel> http://stackoverflow.com/questions/3937387/rotating-videos-with-ffmpeg
[06:46:59 CET] <Abbott> thanks llamapixel
[06:47:06 CET] <llamapixel> npm8
[08:18:29 CET] <JerryT> Is there a way to get 10 frames from a video every minute, starting 30 seconds into a video?
[10:48:54 CET] <beauty> Hello
[10:50:05 CET] <beauty> how to use a linux server decode 4000 video file in memory ?
[10:51:20 CET] <llamapixel> beauty: install biebian
[10:51:21 CET] <llamapixel> http://biebian.sourceforge.net/
[10:52:09 CET] <beauty> llamapixel: ???
[10:55:29 CET] <DHE> please rephrase the question, preferably with better grammar if possible
[11:39:05 CET] <IggyGee> hey all, I'm making an app that alters select few images and puts them back together in video form. but for some reason, the ffmpeg command to stitch the images back together specifically skips those images.
[11:39:19 CET] <IggyGee> I'd greatly appreciate any help
[11:40:12 CET] <IggyGee> I haven't changed their filename or anything
[11:40:53 CET] <DHE> what's your ffmpeg commandline, including the output of ffmpeg itself
[11:48:39 CET] <IggyGee> DHE: I'm having trouble cleanly getting the output into a file, but here's the command
[11:48:41 CET] <IggyGee> ffmpeg -hide_banner -r 29.97 -f image2 -s 1920x1080 -i "cccc/%d.png" -vcodec libx264 -b:v 111k -pix_fmt yuv420p videoOutNoSound.mp4
[11:50:23 CET] <DHE> with the output please. (use the pastebin service of your choosing as long as it's not a dumb one) :)
[11:51:44 CET] <IggyGee> DHE: here ya go :)
[11:51:44 CET] <IggyGee> https://gist.github.com/IgorGee/3e52ad0aa4a5c665e0e719ef05e329f1
[11:54:43 CET] <Nacht> Anyone who got some good knowledge how TS files work ?
[11:54:52 CET] <DHE> Nacht: fairly good, sure
[11:55:12 CET] <DHE> IggyGee: output seems okay. 41 frames too short?
[11:55:30 CET] <IggyGee> 41 frames?
[11:55:47 CET] <Nacht> We're cutting TS files at the I-frames. But with a new stream we seem to break the TS files. They seem to lose their codec information. They're not being reconised as movie files.
[11:55:58 CET] <DHE> oops, that's the fps
[11:56:04 CET] <Nacht> I just can't seem to find the information where the actual codec information is being stored
[11:56:52 CET] <IggyGee> can I send the images to you and see if you can try to stitch them together?
[11:56:57 CET] <IggyGee> i know that sounds silly lol
[11:57:06 CET] <IggyGee> it's an 8 second video into 190 images
[11:58:11 CET] <DHE> IggyGee: drop=73 means it's dropped a lot of frames, and x264 says your QP is extremely high. 110 kilobits for 1080p video is extremely low. have you tried 2M or higher?
[11:58:34 CET] <IggyGee> what's QP?
[12:00:13 CET] <IggyGee> why does it drop those frames?
[12:00:37 CET] <DHE> Nacht: are you using global headers?
[12:00:57 CET] <DHE> IggyGee: QP is the quantization parameter, loosely image quality. 0 is lossless, 51 is an ugly colour smudge
[12:01:03 CET] <Nacht> DHE: YEs
[12:01:13 CET] <DHE> Nacht: toggle the setting and try again
[12:02:05 CET] <Nacht> k
[12:02:56 CET] <IggyGee> I'm not really concerned about the quality right now
[12:03:14 CET] <IggyGee> I'm looking up how to solve those dropped frames though
[12:03:18 CET] <DHE> still, I'd recommend replacing -b:v 111k  with -qp:v 30
[12:04:48 CET] <IggyGee> i think i figured it out
[12:05:06 CET] <DHE> oh?
[12:05:19 CET] <IggyGee> http://superuser.com/a/728697
[12:05:35 CET] <IggyGee> I'm doing something similar with another library that transforms png files
[12:06:16 CET] <IggyGee> erm, what's the convert option? lol
[12:06:20 CET] <DHE> that is listed in the output of ffmpeg, but it seems to soldier on through it?
[12:08:58 CET] <IggyGee> where would I put that -define png:color-type=2 option in my command?
[12:09:17 CET] <DHE> I think that's an imagemagick command, not ffmpeg
[12:09:42 CET] <DHE> forces consistent output formats
[12:09:51 CET] <IggyGee> welp, time to research that library lol
[12:11:02 CET] <IggyGee> hmm
[12:11:17 CET] <IggyGee> one option would be to have that library touch all the png files just for consistency lol
[12:12:28 CET] <IggyGee> or is there an ffmpeg command to convert all image file formats?
[12:24:31 CET] <beauty> DHE: for example, use a ffmpeg process to decode ten mp4 file at the same time
[12:30:01 CET] <luc4> Hello! While building chromium for arm I got this error: http://pastebin.com/AY01s2BH. Previous versions were building properly. It seems to be related to ffmpeg. Anybody who knows if this is something known? I can't find much related to this except https://review.cyanogenmod.org/#/c/83285/, but it seems pretty old.
[12:30:33 CET] <luc4> I typically build ffmpeg just fine for arm actually.
[12:33:07 CET] <IggyGee> FUCK THE PNGS
[12:33:11 CET] <IggyGee> the jpegs work
[12:33:12 CET] <IggyGee> omg
[12:33:13 CET] <IggyGee> im so happy
[13:17:55 CET] <BtbN> luc4, looks more like an issue with your toolchain, generating assembler instruction it itself does not understand
[13:18:00 CET] <BtbN> or you are mixing toolchains
[13:27:20 CET] <onurhb> Check this question: http://stackoverflow.com/questions/40954264/c-how-to-link-ffmpeg-with-cmake-on-windows
[13:28:28 CET] <BtbN> ffmpeg does not support cmake, you'll have to ask the author of that module on how to use it.
[13:28:49 CET] <BtbN> Or you can just leave, that works as well...
[14:03:10 CET] <eranchetz> Hi guys
[14:03:38 CET] <eranchetz> I have posted this question http://stackoverflow.com/questions/40995792/ffmpeg-get-md5-from-local-m3u8
[14:03:52 CET] <eranchetz> anyone has an idea? I am baffled
[14:05:21 CET] <c_14> You probably need a newer version of ffmpeg
[14:07:02 CET] <JEEB> also did you put that whitelist before or after -i?
[14:09:14 CET] <eranchetz> I am using the latest version
[14:09:22 CET] <eranchetz> ffmpeg version 3.2.1 Copyright (c) 2000-2016 the FFmpeg developers   built with gcc 5.3.0 (Alpine 5.3.0)   configuration: --prefix=/usr/local --extra-cflags=-I/usr/local/include --extra-ldflags=-L/usr/local/lib --bindir=/usr/local/bin --disable-doc --disable-static --enable-shared --disable-ffplay --extra-libs=-ldl --enable-version3 --enable-libfdk_aac --enable-libmp3lame --enable-libopus --enable-libtheora --enable-libvorbis --en
[14:09:40 CET] <eranchetz> I put the whitelist first
[14:19:36 CET] <luc4> BtbN: I actually build many things with this toolchain, and it is provided by the manufacturer.
[14:20:52 CET] <luc4> BtbN: I also build ffmpeg itself.
[14:22:13 CET] <luc4> BtbN: also I can build previous versions of chromium that also include ffmpeg...
[14:22:50 CET] <BtbN> Well, then the chrome update broke something. Or uncovered a bug in the toolchain.
[14:22:52 CET] <luc4> BtbN: but is that assembly code generated by the compiler? Isn't it included in ffmpeg sources?
[14:23:44 CET] <BtbN> The message shows up while compiling a c file.
[14:23:55 CET] <BtbN> So it's the C compiler generating assembly its own assembler does not understand.
[14:24:30 CET] <luc4> BtbN: but with this identical toolchain and sysroot I can build many versions of ffmpeg up to 3.1
[14:27:05 CET] <beauty> how to  use a ffmpeg process to decode ten mp4 file at the same time
[14:27:11 CET] <beauty> anybody can help me?
[14:53:56 CET] <beauty> how to  use a ffmpeg process to decode ten mp4 file at the same time
[15:11:40 CET] <Nacht> Good lord, just had a crash course 'Dissecting TS files'
[15:12:00 CET] <Nacht> Just wondering. Anyone know what the difference is between a Random Access Indicator and an I-Frame ?
[15:14:24 CET] <JEEB> I-frame is just a frame that is intra-only
[15:14:56 CET] <JEEB> it only promises that you can decode that picture as-is (if you of course have the parameter sets)
[15:15:13 CET] <JEEB> it doesn't promise that the following coded pictures don't contain references to other pictures
[15:15:34 CET] <DHE> unless you're using a codec like mpeg2video. (please don't do that)
[15:15:52 CET] <kerio> ?
[15:15:54 CET] <JEEB> in AVC (H.264) they kind of half-assed the specificness of where actual random access points are
[15:16:12 CET] <JEEB> so you either have an IDR picture, or you have to have a random access SEI message + an I picture
[15:16:36 CET] <DHE> mpegts has a "randon access indicator" bit to assist in finding that
[15:17:01 CET] <JEEB> in HEVC (H.265) they noticed that this was a bad idea and just rolled out multiple picture types which all fell under the umbrella of IRAP (Intra Random Access Picture)
[15:17:30 CET] <JEEB> with the SEI business you actually had to look into multiple packets while having new packet types just let you compare the type of a single packet against multiple
[15:28:02 CET] <Nacht> Ah, I always thought that every frame after an I-frame is always a reference to that I-frame
[15:28:09 CET] <Nacht> But that doesn't seem to be the case then
[15:28:28 CET] <JEEB> not sure about MPEG-1/2 video, but formats after that do not say that the reference buffer has to be cleaned
[15:28:34 CET] <JEEB> like AVC or HEVC
[15:29:47 CET] <JEEB> newer formats separate "this is an intra only picture" and "this is an intra only picture that lets you random access into the content from here"
[15:29:57 CET] <JEEB> and then there's of course stuff like periodic intra refresh
[15:30:27 CET] <JEEB> where parts of the picture are refreshed in intra little by little so that you get a full picture after N pictures
[15:30:38 CET] <JEEB> but that will probably just confuse you :D
[15:31:24 CET] <Nacht> Well you've giving me allot of leads to dig into. I'll continue studying the fields off video :)
[15:31:31 CET] <Nacht> Cheers!
[15:41:16 CET] <DHE> mpeg2 only has 1 reference frame. so there's no difference between an I and IDR frame (to use h264 nomenclature)
[15:41:32 CET] <DHE> well, it does have b-frames but they don't affect this
[15:45:26 CET] <JEEB> or well, all I pictures are effectively IRAP pictures
[15:45:35 CET] <JEEB> *IRAPs
[15:45:39 CET] <JEEB> since P in IRAP is picture ^^;
[15:46:05 CET] <JEEB> I really like the IRAP umbrella term because IDR is not the only type of IRAP
[15:46:21 CET] <JEEB> even though the term is really only used in HEVC
[16:49:15 CET] <ItWasntMe2013> does anyone have any addtional suggestions when converting interlaced video to progressive?   other than deinterlacing, are there any other options that I can use to get rid of the ghosting video in high motion scenes?
[17:06:57 CET] <furq> ItWasntMe2013: how are you deinterlacing
[17:21:38 CET] <ItWasntMe2013> furq: im using yadiff 1 for now
[17:22:25 CET] <ItWasntMe2013> I would like to keep the cpu usage down to a realistic usage, but would sacrifice more to gain better quality, but yadiff 2 doesn't show me anymore improvement
[17:23:38 CET] <furq> there are better deinterlacers but they probably fail the cpu usage requirement
[17:23:42 CET] <furq> the one i'm thinking of certainly does
[17:23:52 CET] <ItWasntMe2013> furq: oh yeah? which is that?
[17:24:00 CET] <furq> nnedi
[17:24:10 CET] <furq> although it's much better if you use it with qtgmc in vapoursynth/avisynth
[17:24:16 CET] <furq> it is incredibly slow, though
[17:24:37 CET] <furq> i wouldn't have thought yadif in frame-per-field mode would introduce ghosting so that might just be your source
[17:25:09 CET] <ItWasntMe2013> I get it.... so no real time stuff
[17:25:21 CET] <ItWasntMe2013> The video looks great, just I can see that there is ghosting in the video....
[17:25:27 CET] <ItWasntMe2013> I notice it, but some people wouldnt care
[17:26:38 CET] <ItWasntMe2013> any other suggestions? I might be able to live with the ghosting but I can see in horizontal scrolling text that its very choppy
[17:26:55 CET] <ItWasntMe2013> I tired adding B frames to compensate, but that didt help much if at all
[17:31:13 CET] <jkqxz> ItWasntMe2013:  What platform are you on?  Many GPUs include hardware deinterlacers, which are of variable quality but typically fast.
[17:41:30 CET] <ItWasntMe2013> jkqxz: I use both CPU and GPU and get the same result, but right now I have nvenc for my processing
[17:48:21 CET] <jkqxz> The cuvid decoder has some sort of auto-deinterlace built-in.  ffmpeg doesn't support any other route, though I imagine there is some CUDA stuff to do it.
[17:51:07 CET] <ItWasntMe2013> So you suggest to try cuvid  for decoding, my current setup is CPU decode, and GPU encode... Try GPU on both?
[17:55:30 CET] <jkqxz> Maybe?  I'm not particularly familiar with how that works; maybe there is some way to access the deinterlacer stand-alone as well.
[18:32:36 CET] <BtbN> jkqxz, it's not automatic. You have to explicitly enable it.
[18:32:58 CET] <BtbN> And there are some catches to it, as ffmpeg.c does not exactly support a decoder outputing two frames per input
[18:33:25 CET] <BtbN> so for i50 content you have to specify the input framerate yourself
[18:33:41 CET] <BtbN> ffmpeg -r 50 -deint adaptive input.mkv ...
[18:33:50 CET] <BtbN> + -c:v h264_cuvid of course
[18:34:26 CET] <BtbN> without -r 50 ffmpeg throws away every second frame, leaving you with p25 instead of p50
[19:51:27 CET] <ShaneC_> Does preset ultrafast deinterlace video?  I am trying to capture interlaced source, but my output looks deinterlaced.
[19:54:11 CET] <DHE> no, deinterlacing in ffmpeg is all up to you. maybe your player is auto-deinterlacing?
[20:06:56 CET] <ShaneC_> @dhe, ty!
[20:45:15 CET] <andydufresne> is it possible embed album art using ffmpeg while converting from flac to mp3?
[21:03:25 CET] <durandal_1707> andydufresne: nope, not yet
[22:33:52 CET] <cnote> why does video/audio  uses  bit/s  not  byte/s
[22:33:56 CET] <cnote> for example  mp3 128 kbps
[22:54:01 CET] <durandal_1707> cnote: because it's convenient
[23:34:11 CET] <kepstin> cnote: mostly because it's traditional, I think. It's always used bits, so changing it now would cause confusion.
[23:36:58 CET] <kepstin> (using bits to measure bandwidth of transmitted signals significantly predates computers using 8-bit bytes)
[23:51:55 CET] <andydufresne> thank you durandal_1707
[00:00:00 CET] --- Wed Dec  7 2016