no more hslv format ?

[Jim web]

In article <20180502152015.50EA621CC3 at orac.inputplus.co.uk>, Ralph
Corderoy <ralph at inputplus.co.uk> wrote:
> >
> > The challenge for me is to work out how to get the fetched file to go
> > onto the tmpfs

> Well, `df -t tmpfs' will probably show /tmp is a tmpfs so you could
> `--output /tmp' and you should see its intermediate files, and the final
> file, only appear there.  `--command' could then move that final file to
> the SSD, or run a conversion command that writes to the SSD and then
> removes the tmpfs input.

Thanks. :-)

> As for altering the ffmpeg command that get_iplayer is using, I'm not
> sure that's worthwhile?  It isn't doing any transcoding, just changing
> the container format, or splicing in better audio, that kind of thing.
> So your `lossy' slow-down ffmpeg from 50 fps to 25 fps won't be a second
> lossy one that you'd prefer to combine with the first.  I could be
> wrong, not knowing how to have ffmpeg do this conversion.  When you find
> out, let the list know.  :-)

My concern is that I only have a total of 8GB of ram at present on the
machine, and the 1280x720 50fps files tend to come in at 2GB or more per
hour. 

To save time and avoid running past 9am (and entering metered time) it
would be quickest to do all the fetches first. But this will mean more
files that I can store on ram on some days. So the wish would be to then
shift or process material and put it on hd.

As things are, I could then have gip+ffmpeg generate the 50 fps mp4 files
(i.e. in the current form) onto hd. This saves some hd wear but means I now
have those (big) files on hd before I then run a 50 -> 25 fps process to
create smaller ones (which will be akin in size to what I got from the
25fps fetching). The result using this approach means I've still done the
fetching as quickly as possible, but have about three times as much data
written to hd at some point.

It would be nice to do the process file by file and in each case only the
'final' 25 fps version gets written to hd. This means the same hd use as
previously. But that either means I need enough ram to hold all the 'temp'
files (masses of ram needed) or doing the process item by item. (slow)

I could use spinning rust I guess. but that seems messy. Otherwise it seems
to want me to buy and fit a lot of ram. :-)

So at present I'm wondering and experimenting. 8-]

Jim

-- 
Electronics  https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
Armstrong Audio  http://www.audiomisc.co.uk/Armstrong/armstrong.html
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc  http://www.audiomisc.co.uk/index.html