Re: no more hslv format ?

[Christopher Woods]

Curious - 25p @ 1/50th is the generally accepted 180° rule, unless they're 
doing weird stylistic stuff in post? Or does it all just look smooshy and 
motion is really badly defined?


Personally I wish people would shoot 50p and frame drop instead of shoot 
25p, I think it's more flexible.


(Making me feel old now. The last yoof soap I watched regularly was Byker 
Grove)


On 7 May 2018 18:14:40 Lucy Walker  wrote:


On 07/05/2018 17:09, Christopher Woods wrote:


Steve is right on the doubled technique, this is the filmic look you
see on documentaries and dramas. That source material will be likely
be captured as progressive frames, then upconverted to 50 fields per
second, 'progressive segmented frame' format (PsF) in the edit.



At least one "yoof soap" shoots 1080p25 shuttered to 1/50th - looks like
shit, but the head of cameras is a fucking moron. No more processing
than that

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer





___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[Lucy Walker]

On 07/05/2018 17:09, Christopher Woods wrote:


Steve is right on the doubled technique, this is the filmic look you 
see on documentaries and dramas. That source material will be likely 
be captured as progressive frames, then upconverted to 50 fields per 
second, 'progressive segmented frame' format (PsF) in the edit.




At least one "yoof soap" shoots 1080p25 shuttered to 1/50th - looks like 
shit, but the head of cameras is a fucking moron. No more processing 
than that


___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[Ralph Corderoy]

Hi Jim,

> > 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.
>
> the df command listed various 'locations'. These included
>
> tmpfs  815696   1352  814334   /run
> none   4078460  0 4078460  /run/shm
> none   102400   8 102392   /run/usr

/run/shm is half your RAM, as I'd expect.  I'd also expect /tmp to be
there.  What does `df -T /tmp' show?  Perhaps that's using SSD for all
temporary files and you might not want that given your concerns.

> Inside /run/usr I did find a directory for my user id and could use
> that as the user.

But it's deliberately constrained to be small.

> However I don't know what the /run/shm is for, so need to do some
> finding out...

POSIX's communication methods of shared memory and semaphores;
shm_overview(7), and sem_overview(7).  Again, not what you want.

> I did set up an explict ramdisc on another machine ages ago by adding
> a line to the /etc/fstab file. But that fixed the size to 256 MB,
> which in this context is tiny. System monitor says I have 8GB of ram.

That's the right idea.  Here, the system has /tmp be a tmpfs that is
half the RAM, like the `shm' one above.  They share one single half.
`systemctl status tmp.mount' is what creates it on some systems these
days, not an /etc/fstab entry.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[Christopher Woods]

On 3 May 2018 21:38:23 RS  wrote:


On 03/05/18 12:18, Steve Dodd wrote:


Is it possible it depends on the source material? From the BBC quote
earlier it sounds like their "source" material is still mostly HD
interlaced, but perhaps some of their sources are all also
progressive, and those ones get doubled identical frames (which might
be a logical result of feeding 25p material into something that's
designed to interpolate interlaced fields into frames)?

The satellite broadcasts I have seen from the BBC and other broadcasters
are 1920x1080i25 for HD and 720x576i25 or 704x576i25 for SD.  Everything
that is broadcast is in an interlaced format at some stage, however it
is generated.  Some programmes are only produced for the iPlayer, so
they may be generated in a different way.



A handful of HD is still 1440x1080i25 :( the non-square pixel format is a 
great cheat for bandwidth saving. The chroma compression on current 
generation terrestrial broadcasting also makes everything look bad. Once 
you watch uncompressed HD-SDI you never want anything else :) Some SD is 
way below what we would accept as SD resolution as well, all in the name of 
cost saving.



Steve is right on the doubled technique, this is the filmic look you see on 
documentaries and dramas. That source material will be likely be captured 
as progressive frames, then upconverted to 50 fields per second, 
'progressive segmented frame' format (PsF) in the edit.


The same image is stored across every two fields that constitute one frame, 
meaning you're being shown one effective whole full resolution image, 25 
times a second.


With standard interlaced footage, you're being shown overlapping effective 
'images' at half-resolution, 50 times a second. Persistence of vision 
(well, nowadays, flat panel processing circuitry) bob deinterlaces the 
fields to produce 50 images per second.



However, TVs sometimes do this artificially by taking true progressive 
sources and interpolating the footage to a higher refresh rate (100/200 
Hz). This inherently looks dire and should be disabled.


On some TVs with poorly written image DSP (or badly chosen settings) you'll 
see the picture suddenly go 'filmic' as the deinterlace method changes to 
blend, which literally blends together pairs of fields to produce 25 frames.


Some explainers of fields, frames and progressive segmented format interlaced:

https://en.m.wikipedia.org/wiki/Progressive_segmented_frame

https://wolfcrow.com/blog/understanding-terminology-progressive-segmented-frames-psf/
https://wolfcrow.com/blog/understanding-terminology-progressive-frames-interlaced-frames-and-the-field-rate/



___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer

Re: no more hslv format ?

[Ralph Corderoy]

Hi Jim,

> 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. 

Yes, you'd need to finish one download off, clearing RAM disk, before
starting the next.

> To save time and avoid running past 9am (and entering metered time) it
> would be quickest to do all the fetches first.

I too have metered broadband, but have automated use of it begin at
00:03 using timeout(1) to ensure it is killed by my 08:00 cut-off time
if it didn't complete for some reason.  Have you considered something
similar, perhaps using get_iplayer's `--pvr-queue', etc., to add
programmes of interest, and then telling it to `run' some or all of the
queue items?

> but have about three times as much data written to hd at some point.

Yes, with my preferred choices, get_iplayer's writes to disk would be

downloaded video
downloaded audio
video and audio combined into MP4
tagged MP4

so 3(v+a), and I'm not converting to 25 fps.

> I could use spinning rust I guess. but that seems messy.

Do you have it already available in the machine to use?  That seems an
easy compromise.

You could also look at your SSD's specifications and whether you're
striving too hard to avoid what might not be a problem with modern ones
and their built-in wear levelling.

-- 
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy

___
get_iplayer mailing list
get_iplayer@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/get_iplayer