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

[burek]

[00:39:31 CET] <vicky> Video conversion_status failed due to libx264 or any codes that is installed by your application.  Please read this link for more details: https://docs.clipbucket.com/how-to-fix-video-conversion-problem
[00:40:00 CET] <vicky> how to fix this issue?
[00:40:50 CET] <vicky> ======
[00:40:52 CET] <vicky> File : /home/ppxyz/public_html/clip/files/thumbs/2017/12/07/1512668598dc0ae-768x432-1.jpg  ====== End : Thumbs Generation =======    Conversion Completed --------------------   Time Took : 1.4912 seconds   conversion_status : failed
[00:40:54 CET] <vicky> =====
[00:41:04 CET] <vicky> this is a conversion error
[00:41:12 CET] <vicky> Can anyone help on this issue?
[00:47:43 CET] <vicky> Can anyone check my query?
[00:56:53 CET] <SortaCore> vicky: IRC is not a fast thing
[00:57:08 CET] <SortaCore> you should expect up to a few hours
[00:57:26 CET] <vicky> @sortacore - okay, will wait
[00:57:43 CET] <SortaCore> at a guess, do you have perms for it?
[00:57:57 CET] <vicky> what perms?
[00:58:08 CET] <vicky> Can you please clarify on this?
[00:58:12 CET] <SortaCore> looks like linux-style path
[00:58:29 CET] <SortaCore> so writing file perms always makes me question folder permissions
[00:59:35 CET] <vicky> @sortacore - will check that path on my server
[01:09:59 CET] <vicky> @sortacore - Can you please tell me path linux-style?
[01:21:16 CET] <SortaCore> you put the path up there
[01:21:40 CET] <SortaCore> try running whatever you were doing for video conversion with sudo
[01:43:47 CET] <kisahoshi> Hi guys
[01:45:17 CET] <kisahoshi> I am trying to run ffmpeg to record desktop + audio but unfortunately its not working sa intended. it wont capture my audio but it records just fien
[01:45:33 CET] <kisahoshi>  ffmpeg -video_size 1336x768 -framerate 30 -f x11grab -i :0.0 -f alsa -i hw:0 -qscale:a 2 -c:v libx264 -crf 20 -preset veryfast vid.mkv
[01:55:27 CET] <kisahoshi> hello
[01:56:56 CET] <kisahoshi> hi
[01:59:00 CET] Last message repeated 1 time(s).
[02:03:06 CET] <kisahoshi> Helloooo
[02:03:09 CET] <kisahoshi> Can someone help
[04:36:25 CET] <hendry> has anyone made a script to do a animated Youtube style poster of an MP4?
[04:38:59 CET] <SortaCore> isn't that just pulling every X frame from a video?
[04:39:21 CET] <SortaCore> probably not a script, but you would get the duration, get frame rate, then pick frame by modulus or multiplier
[04:39:42 CET] <SortaCore> chuck them into a video output and you're good
[05:04:32 CET] <furq> -skip_frame nokey will get you most of the way there
[05:04:36 CET] <furq> depending on the codec
[05:04:58 CET] <furq> if that's still too many frames then ffprobe -count_frames and then -vf select
[05:05:14 CET] <furq> don't expect it to be quick though
[08:11:02 CET] <liyou> i want to link static-ffmpeg into so file, how can i do it?
[10:40:02 CET] <pihpah_> The question is HLS vs progressive downloading (mp4, h.264). Currently I utilize the latter method, now I am thing of the former. The problem is I already serve tons of videos using progressive downloading.
[10:40:17 CET] <pihpah_> I am thinking*
[10:41:11 CET] <pihpah_> And for some reason on macOS I can't play those videos, don't know why.
[10:41:32 CET] <pihpah_> I already asked about that problem in this channel.
[11:06:09 CET] <kerio> "on macOS"?
[11:06:13 CET] <kerio> you mean in safari?
[11:10:34 CET] <pihpah> kerio: I have the same problem both in Safari and Firefox on macOS.
[11:12:39 CET] <pihpah> I've tried HLS streaming, works fine for Safari but now it does not work on Linux in Firefox and Chromium, jeez.
[11:13:31 CET] <Nacht> Firefox and Chrome dont have native support for HLS
[11:13:35 CET] <Nacht> Only Edge and Safari
[11:13:46 CET] <ritsuka> pihpah: wasn't that a issue with your server configuration?
[11:14:09 CET] <ritsuka> or something like that
[11:14:45 CET] <kerio> yeah firefox does its own thing
[11:14:59 CET] <pihpah> ritsuka: does not think so. All I know HLS works on Android and Safari, but does not work on Chromium and Firefox
[11:15:00 CET] <kerio> video playback shouldn't differ between different OSes
[11:15:25 CET] <ritsuka> pihpah: I mean the issue with progressive download
[11:16:19 CET] <Nacht> If you use a HTML5 player, such as JWPlayer or some sorts, you can play HLS perfectly on Firefox and Chrome
[11:16:25 CET] <pihpah> ah, no, that does not relate to this problem. I run all tests locally.
[11:16:50 CET] <pihpah> Nacht: I test using html5 video tag
[11:17:25 CET] <pihpah> Ok, I'll try using JWPlayer
[11:26:49 CET] <Nacht> pihpah: the HTML5 video tag alone isn't enough
[11:27:00 CET] <Nacht> That's only for MP4, WebM and OGG
[11:27:29 CET] <Nacht> You need an actual player, like TheoPlayer, JWPlayer or Meisterplayer
[11:46:53 CET] <JEEB> or just a basic thing on top of hls.js or dash.js. they generally provide you enough for a PoC
[12:40:50 CET] <th3_v0ice> Hello, I would like to call the FFmpeg from my application but not trough system calls like I am doing now, I would like to do it with the function call. The easies way is to rename the int main() of ffmpeg.c and call that method with already constructed arguments. The problem is that after including required headers, putting requred files where they belong I cant compile the project. For example I am getting libavutil/x86/asm.h No such file or
[12:40:50 CET] <th3_v0ice> directory, but the file is there. I am guessing that gcc is not invoked with proper arguments from the Eclipse. Thanks for the help!
[12:51:18 CET] <BtbN> th3_v0ice, that's not supported. Either use the API, or run the program.
[12:55:25 CET] <th3_v0ice> Ok, thanks! Will use the API.
[13:07:43 CET] <tommy``> there is a windows build with installer?
[13:09:08 CET] <tommy``> i would like to add PATH on windows
[13:09:45 CET] <pihpah> Okay, nice. Looks like the pain in my ass for about half year was just one byte I have been failing to read: https://pastebin.com/wksvKN2k
[13:09:53 CET] <pihpah> Darn it
[15:18:21 CET] <kerio> Nacht: but <video> is enough for safari :3
[15:22:01 CET] <Nacht> kerio: For HLS you mean ?
[15:22:13 CET] <JEEB> and edge
[15:22:28 CET] <JEEB> (edge actually supports both DASH mpd and HLS m3u8 in <video>)
[15:22:31 CET] <JEEB> but it's the exception
[15:22:37 CET] <JEEB> everything else wants you to parse everything in JS <3
[15:23:17 CET] <Nacht> As JEEB says, you want to use JS. As Safari and Edge aren't really the most used browsers :)
[15:45:32 CET] <Intektor> I am trying to do a really low latency p2p network stream, but I cant seem to get the right variables, I still have a latency of around 1 second, any tips?
[15:46:17 CET] <Intektor> this is my current command: https://i.imgur.com/Laxk5WH.png
[16:02:21 CET] <InTheWings> wth does an ffmpeg remuxed AAC with its 2 bytes of extra, ends with 24 extradata bytes (22 more in front) in AVI ?
[16:02:52 CET] <InTheWings> and that's not an adts header
[16:06:27 CET] <InTheWings> WAVE_FORMAT_EXTENSIBLE ok
[16:07:37 CET] <kepstin> Intektor: hard to say where the latency is being added - it might actually be in the pipe connecting the process generating the images to ffmpeg, rather than something ffmpeg is doing.
[16:07:50 CET] <alexpigment> does using CRF add latency?
[16:08:02 CET] <kepstin> no
[16:08:18 CET] <alexpigment> gotcha. i didn't know if certain rate control methods were slower than others
[16:08:20 CET] <Intektor> kepstin, thats sounds interesting, I will take a look at that
[16:08:55 CET] <kepstin> (well, crf mode might be a bit slower than other rate control methods, but it doesn't cause any additional frame buffering)
[16:09:06 CET] <alexpigment> is rc lookahead even used at all for CRF?
[16:09:20 CET] <kepstin> it depends on other settings
[16:09:32 CET] <kepstin> in this case, the -tune zerolatency disables all lookahead
[16:09:44 CET] <alexpigment> ah, good to know
[16:10:12 CET] <kepstin> in normal usage with slower presets, rc lookahead will be used with crf mode.
[16:10:31 CET] <kepstin> i think? need to confirm that.
[16:11:05 CET] <kepstin> it certainly does some lookahead and/or frame buffering, but it might not be due to the rc code. hmm.
[17:19:27 CET] <tmatth> kepstin: is CRF ok for live/real-time use (I've been it in conjunction with veryfast and zerolatency)
[17:20:49 CET] <kepstin> it doesn't give you any direct control over the stream bitrate, so it might not be useful for network streaming to people with limited bandwidth.
[17:21:30 CET] <kepstin> (you can use crf in combination with vbv controls, tho)
[17:41:10 CET] <tomtomb> hey, another question, can ffmpeg create AAF files, somehow?
[17:51:59 CET] <tmatth> kepstin: yeah that's what i've been doing
[18:01:43 CET] <kepstin> huh, aaf files are weird. use the storage mechanism from old ms documents, which is basically a fat filesystem in a file?
[18:02:33 CET] <kepstin> looks like there was an open-source implementation way back when. If you really need it, might be best to encode media with ffmpeg then find some external tool to put everything in the aaf file.
[18:33:16 CET] <delsol> if I'm encoding with x11grab, ffmpeg -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -preset ultrafast /video/2017-11-30/TEST_VIDEO.mkv     are there any easy format changes that could reduce CPU load without making filesize skyrocket? Bit depth?
[18:36:16 CET] <alexpigment> delsol: do you have the option to use hardware encoding?
[18:36:40 CET] <delsol> I can't get it to work. intel embedded GPU
[18:36:49 CET] <alexpigment> vaapi should support that i thought
[18:36:57 CET] <delsol> Yeah, i can't get it to work.
[18:37:11 CET] <delsol> in some cases doing 3-4-5-10 encodes at once from different screens :0, :1, :2, etc
[18:37:21 CET] <alexpigment> k
[18:37:24 CET] <delsol> not sure it'll work there either, or if it'll even help
[18:37:36 CET] <alexpigment> what's your current problem with CPU load?
[18:38:58 CET] <delsol> when multiple encodes going, non-encoding tasks slow down. Additional memory bandwidth with same task (by inserting second stick of ram to get dual channel) made recordings better, less dropped frames, but slowed actual workload task from 6 seconds to 10 seconds
[18:39:17 CET] <alexpigment> also another member here mentioned using -tune zerolatency to solve a latency issue, but he mentioned that it tuns off rc_lookahead (and presumably the lookahead threads). might be worth trying that
[18:41:11 CET] <alexpigment> delsol: well, at a certain point you have to accept that CPU encoding x264 is not a trivial task, so maybe it's worth considering another format
[18:42:01 CET] <alexpigment> or, perhaps a better CPU
[18:42:23 CET] <alexpigment> lastly, make sure you're writing to an SSD or at least a non-OS HDD
[18:42:36 CET] <alexpigment> and not in a virtual machine if that's a factor
[18:42:36 CET] <delsol> yeah, writing to a non-OS drive.
[18:43:30 CET] <alexpigment> and my 2 cents on this: i would not personally want to work on a computer that is live capturing my screen doing x264 encoding
[18:44:16 CET] <alexpigment> it's pretty much always going to affect performance, unless you have a monster CPU
[18:45:08 CET] <delsol> not a VM. current CPU is G3258 @ 3.2ghz       most are similar. Have over 50 locations. Most would only be doing 1-2 encodes though.
[18:45:20 CET] <alexpigment> that's dual core, right?
[18:45:22 CET] <delsol> yeah
[18:45:34 CET] <delsol> dual core haswell, no hyperthreading.
[18:45:50 CET] <alexpigment> multiple encodes on a dual core haswell just doesn't seem like a good idea imho
[18:46:04 CET] <delsol> its what I've got.
[18:46:07 CET] <alexpigment> you'd ideally want something like ryze
[18:46:10 CET] <alexpigment> *ryzen
[18:46:41 CET] <alexpigment> understandable. my 2 cents (others may disagree), you've got the wrong tool for the job, so you need to make some sacrifices somewhere
[18:47:52 CET] <delsol> well, I can't just go spend a new car on hardware. Thats why I'm looking for ways to reduce load in an acceptable manner.
[18:50:43 CET] <delsol> figured maybe color bit depth would be an easy gimme or something
[18:50:51 CET] <delsol> or maybe theres no more to give there...
[18:51:34 CET] <alexpigment> well, try -pix_fmt yuv420p if you haven't tried already
[18:59:12 CET] <delsol> 14% without / 10% with      but mostly 12% without, 10% with at 15fps, 30 quality
[18:59:33 CET] <alexpigment> ok
[19:00:10 CET] <alexpigment> from my perspective, that's the best you're going to get
[19:01:34 CET] <delsol> thats a good difference if the quality is still usable.
[19:04:04 CET] <pszafer> hi, few years ago I converted music cd to mp3. ffmpeg saying for most of files that header is missing. I see similar bug and fix for it 803c058a6f0c835c3094621d03d6e8c02565f28e
[19:04:07 CET] <alexpigment> well if you want to have maximum compatibility, you want to be using yuv420p
[19:04:43 CET] <pszafer> do you know for which version fix suppose to be released? I'm using 3.4
[19:04:44 CET] <alexpigment> which has half the chroma resolution compared to the luma resolution, but it's sadly still the de facto standard
[19:05:01 CET] <delsol> thanks alexpigment :) gets me closer and pushes hardware limits further away.
[19:11:31 CET] <notbatman_> Hello. Would like to use ffmpeg to convert RealMedia RV40 video stream to almost anything else. Is RV40 video conversion supported in the current build v3.4?
[19:12:11 CET] <alexpigment> yes, there's a decoder for it
[19:12:16 CET] <alexpigment> (at least on paper)
[19:12:31 CET] <alexpigment> whether you have any problems with it is another story
[19:12:38 CET] <alexpigment> i haven't seen a realvideo file in many years
[19:13:04 CET] <notbatman_> Yes, these are from 2005-2006
[19:13:24 CET] <alexpigment> right
[19:13:41 CET] <alexpigment> well, rv40 decoder support has been in ffmpeg for quite a while
[19:14:22 CET] <notbatman_> As I understand it, the conversion selects the highest resolution stream of video and audio and converts that unless specified otherwise.
[19:15:05 CET] <alexpigment> are you implying that there are multiple video and audio streams in your video files?
[19:15:36 CET] <notbatman_> Yes, there typically are multiples to accommodate different bandwidth users
[19:16:03 CET] <alexpigment> gotcha
[19:16:33 CET] <alexpigment> if you do a test conversion with just ffmpeg -i [input] output.mp4 , it'll show you all the streams available
[19:16:46 CET] <notbatman_> Will do.
[19:16:54 CET] <alexpigment> so just make sure the final resolution is the same size as the highest resolution listed
[19:17:12 CET] <alexpigment> of course, you'll probably want to specify more parameters than the command above
[19:17:50 CET] <notbatman_> Will see if that works first and add more later if that works.
[19:20:23 CET] <notbatman_> Ugh. Not good. Conversion failed.
[19:37:42 CET] <notbatman_> @alexpigment Tried the basic input-output conversion and it failed. Pasted terminal output to pastebin under notbatmanbgordon.
[19:40:19 CET] <SortaCore> just link the pastebin here
[19:42:10 CET] <alexpigment> sorry back
[19:42:18 CET] <alexpigment> i'm an old technologically-challenged man
[19:42:26 CET] <alexpigment> paste the pastebin link here and i'll click on it
[19:42:36 CET] <notbatman_> Ah. Sorry. Here's the link:   https://pastebin.com/RfCsW2q1
[19:44:18 CET] <alexpigment> there are others here who know a lot more than me about ffmpeg
[19:44:36 CET] <alexpigment> but just based on this, i would try specifically mapping one of the other video streams and seeing if that works
[19:45:07 CET] <alexpigment> for example, stream 0:2 or 0:6
[19:45:38 CET] <notbatman_> Makes sense. Thanks.
[19:46:09 CET] <alexpigment> i mean it's complaining about headers being incorrected and bad packet sizes and invalid data, so another stream might not have those same problems
[19:46:25 CET] <alexpigment> *incorrect, rather
[19:48:36 CET] <notbatman_> Yeah, let's hope that's it. Will give it a shot in my copious free time. Back when I do.
[21:47:22 CET] <delsol> so --scenecut XX is a % of pixel change to determine if a new keyframe is generated?
[21:48:27 CET] <delsol> and --keyint YYY gives a number of frames maximum before a new keyframe is generated?
[21:51:26 CET] <sfan5>   -I, --keyint <integer or "infinite"> Maximum GOP size [250]
[21:51:26 CET] <sfan5>       --scenecut <integer>    How aggressively to insert extra I-frames [40]
[21:51:30 CET] <sfan5> from x264 --fullhelp
[21:52:42 CET] <sfan5> if you need it more precise you might need to read the code, but those sounds correct to me
[22:04:17 CET] <delsol_> looks like things have changed, --scenecut and --keyint don't seem to be supported anymore or I'm doing it wrong.
[22:08:37 CET] <BtbN> Those are x264 options
[22:08:40 CET] <BtbN> not ffmpeg.
[22:08:46 CET] <kepstin> those aren't ffmpeg options; keyint maps to '-g' in ffmpeg, and for scenecut you need to use -x264-params
[22:09:06 CET] <kepstin> hmm, or maybe it's -sc_threshold? not sure, actually
[22:09:24 CET] <kepstin> the -x264-params way will def. work, tho :)
[22:10:06 CET] <kepstin> and I can never remember which of -x264opts or -x264-params is preferred
[22:15:56 CET] <delsol_> ahhhh
[22:16:29 CET] <furq> params is preferred now
[22:19:01 CET] <notbatman_> Has anyone been successful in converting RealMedia RV40 streams to any format using FFmpeg 3.4, or even earlier versions? Just curious.
[22:21:36 CET] <JEEB> notbatman_: I'm pretty sure some of my playback test samples are RV
[22:21:39 CET] <JEEB> either 30 or 40
[22:22:03 CET] <delsol_> should i care about "Past duration 0.999413 too large" blowing up my command line repeatedly?
[22:24:03 CET] <durandal_170> notbatman_: if samples don not decode with ffmpeg, open bug report on trac to link of sample
[22:36:02 CET] <kepstin> delsol_: that usually means the framerate of the input file was misdetected. It can mean some frames get dropped. If it's supposed to be constant framerate and you know the correct value, you can throw a -r 24 or whatever on the output to fix it.
[22:36:39 CET] <kepstin> or I think you can work around with with some settings of the -vsync option to force it to assume vfr output
[22:37:26 CET] <delsol_> ahh. I don't give a rats ass about dropped frames within reason, so long as there isn't massive huge amounts of time-skew over a 20-30-60 minute screengrab
[22:37:43 CET] <kepstin> it doesn't affect a/v sync
[22:38:08 CET] <delsol_> its just screen capture for security purposes, there is no audio at this time.
[22:38:51 CET] <alexpigment> delsol_: the past duration too large will always occur when your output framerate is lower than your input frame rate, from what i recall
[22:39:01 CET] <alexpigment> and if you're doing 15fps, it probably means you're intentionally dropping frames
[22:43:16 CET] <alexpigment> notbatman_: assuming this is a one-time project and you don't mind using a different tool, realmedia has their own converter: http://www.real.com/features/basic/convert
[22:43:41 CET] <alexpigment> that'll at least get you out of realvideo, presumably, if not into the format you want in the end anyway
[22:47:34 CET] <notbatman_> alexpigment_: Thanks, I may try that--although I'm sure to run into more RealMedia, so it would be nice eventually to work with FFmpeg in the CLI.
[22:48:51 CET] <durandal_170> notbatman_: tried ffmpeg already or?
[22:51:15 CET] <delsol_> alex: so in software, i've got selection spots to do 10,15,20 FPS, and quality 20,25,30,35,40 if I remember right. I'm doing 15 fps, quality 30 default. (will have to go lower quality on machines doing many encodes at once)
[22:51:57 CET] <delsol_> thinking about nice 5'ing the main encode, :0 and maybe nice 8 or so on :1, :2, :3, etc
[22:52:03 CET] <kepstin> delsol_: what input options are you using?
[22:52:21 CET] <kepstin> if you're getting that past duration message during the live capture, something's messed up
[22:52:43 CET] <delsol_> ffmpeg -framerate 15 -video_size 1024x768 -f x11grab -i :0 -vcodec libx264 -crf 30 -pix_fmt yuv420p -preset ultrafast /video/2017-11-30/TEST_VIDEO.mkv
[22:53:46 CET] <kepstin> hmm, strange, that really should be ok. That's the correct way to specify the capture framerate, and it shouldn't ever be capturing frames *faster* than that, especially under load.
[22:54:37 CET] <delsol_> after about 10 seconds I've got: frame=  142 fps= 15 q=-1.0 Lsize=     130kB time=00:00:11.40 bitrate=  93.5kbits/s dup=0 drop=29 speed=1.23x
[22:54:37 CET] <notbatman_> @durandal_170_: Yes that's why I'm here:) The RealMedia files play fine in RealPlayer. FFmpeg sees the streams and all the metadata but says they're f-ed up--not in those exact words.
[22:56:20 CET] <durandal_170> notbatman_: pastebin ffmpeg output
[22:56:27 CET] <kepstin> delsol_: can you pastebin the full output up until you get a 'past duration too large' message?
[22:56:58 CET] <delsol_> you just want 2-3 seconds of pastebin from start to end?
[22:58:05 CET] <kepstin> I want the console output from the ffmpeg command from start to the point where you see that message.
[22:58:30 CET] <delsol_> https://pastebin.com/mR6GjENu
[22:58:36 CET] <delsol_> thats from start to end for about 4 seconds
[22:58:43 CET] <delsol_> with both ends of the console output
[23:01:30 CET] <notbatman_> @durandal_170_: pasted at https://pastebin.com/22aLfUrc
[23:01:38 CET] <kepstin> alright, so the input is setting the framerate to 15 with 1000k tb, that's correct, the output framerate is 15, and it's converting to timebase of 15, which should be fine.
[23:01:57 CET] <kepstin> so the only explanation is that x11grab is actually grabbing frames slightly faster than 15fps, which is really odd
[23:02:33 CET] <notbatman_> Gotta catch a train. Continue later.
[23:02:39 CET] <kepstin> well, in this case, I'd just ignore the message - the final result will be 15fps, although there might be minor jitter.
[23:02:44 CET] <durandal_170> notbatman_: rm demuxer issue, upload sample if you can
[23:02:56 CET] <notbatman_> ok
[23:05:20 CET] <delsol_> 1000k tb?
[23:08:16 CET] <kepstin> the x11grab pts values work by simply setting the frame timestamp to the current realtime (ms accuracy), converted to ffmpeg's internal "AV_TB" (µs, iirc)
[23:09:05 CET] <kepstin> so it grabs a frame, sets timestamp to current time, sends it on, then sleeps until it's supposed to grab the next frame & repeat.
[23:09:34 CET] <delsol_> ahhhhh
[23:10:20 CET] <delsol_> so its grabbing a frame slightly earlier/later than expected, and thus throwing warnings
[23:10:59 CET] <kepstin> slightly earlier - or maybe one slightly later and the next on time?
[23:11:11 CET] <kepstin> hard to say.
[23:11:54 CET] <kepstin> you can either ignore it and maybe have some jitter, or throw a "-r 15" or "-vf fps=25" on the output and hope that cleans up the timestamps (should be minimal overhead)
[23:12:20 CET] <kepstin> I typoed that 15’25, but I assume you get the idea :)
[23:19:34 CET] <delsol_> if the extraneous output on shells that don't really exist isn't going to memory leak horribly, and isn't going to somehow declare world war three on my drive or cause kernel panics, I give zero shit about some random extra output
[23:19:59 CET] <delsol_> video starts every login,
[23:20:33 CET] <delsol_> on logout, ps ax gets grepped for ffmpeg on the right display :0, :1, etc and gets killed.
[23:23:32 CET] <delsol_> video files get named according to YYYYMMDD_HH-MM-SS_<userid>_<loginid>_<machinename> in a directory named after sales date. :) makes it easy to blow away days worth of video when free space is less than a given amount or given %.
[23:24:10 CET] <delsol_> while(drive_too_full_%) {delete_oldest_day}
[23:24:36 CET] <delsol_> while(drive_not_enough_gb_free) {delete_oldest_day}
[00:00:00 CET] --- Sat Dec  9 2017