Just a side note from my conversion testing, but Handbrake seems to reduce the size of the file considerably (about 5 times?).
Is this to be expected?
Just putting this here as a reminder for further research.
In article <jn6h6vFt1vU5@mid.individual.net>,
David <wibble@btinternet.com> wrote:
Just a side note from my conversion testing, but Handbrake seems to
reduce
the size of the file considerably (about 5 times?).
Is this to be expected?
Just putting this here as a reminder for further research.
What does ffmprobe tell you about the content of the source file and the Handbrake output file?
If Handbrake is transcoding it may be re-compressing differently, and possibly discarding data. This will depend entirely on your settings and
the source file details. Result may or may not be a noticable change in
the
appearance (or sound) depending on the details.
Jim
--
Please use the address on the audiomisc page if you wish to email me. Electronics https://www.st-andrews.ac.uk/~www_pa/Scots_Guide/intro/electron.htm
biog http://jcgl.orpheusweb.co.uk/history/ups_and_downs.html
Audio Misc http://www.audiomisc.co.uk/index.html
Video compression algorithms work by transmitting a "key frame" every so often (typically every 10-15 frames) which is a full-detail frame
(subject to lossy JPEG-
People tell me it has to do with how the areas that do not change between frames are encoded. Whether a sighted person will notice is very dependent
on whether the brain papers over the mistakes. After all the working eye itself has a lot of processing before it can become the image you actually see, or think you see. A lot of it is inferred from the bit the macular
has seen being added to the lower definition parts of what you are
seeing.
"Brian Gaff" <brian1gaff@gmail.com> wrote in message news:tenf2m$1psru$1@dont-email.me...
People tell me it has to do with how the areas that do not change
between frames are encoded. Whether a sighted person will notice is
very dependent on whether the brain papers over the mistakes. After
all the working eye itself has a lot of processing before it can
become the image you actually see, or think you see. A lot of it is
inferred from the bit the macular has seen being added to the lower
definition parts of what you are seeing.
Video compression algorithms work by transmitting a "key frame" every so often (typically every 10-15 frames) which is a full-detail frame
(subject to lossy JPEG-type compression). This is followed by a series
of difference frames: differences between the current frame and the last
key frame). For a scene that is fairly static with just a small amount
of movement, this means that the difference frames are very small. The encoder has to be able to compare successive source frames and insert a
new key frame, even if it is sooner than the normal 10-15 frames, if the scene changes dramatically (eg at a shot change). This avoids having to transmit huge difference frames between the current frame and a key
frame that is dramatically different.
It works well, but it can lead to macro-blocks (large squares that are typically 16 pixels square) on parts of a frame that change very rapidly
- eg if the camera is panning or the subject moves across the frame very quickly. Ideally the encoder would allocate a higher bit rate (ie larger difference frame) is there is large movement, but sometimes the encoder
is restricted on the maximum bit rate.
If you record a programme that has a lot of camera-panning or other
movement and play back those sequences frame by frame you can see a lot
of macro-blocking.
Another possible artefact is detail that goes missing on fairly plain backgrounds when there is a lot of movement: the classic one is a
football match where there is detail in the grass which can degenerate
into a featureless green mass if the bits that are needed to reproduce
the grass detail are suddenly needed when many of the players move in
the frame.
As with any lossy compression, the art is in choosing a bitrate which
only removes details that a normal viewer would not notice, while not reducing the bitrate to the extent that the picture looks overcompressed
- blocky or lacking in detail. In general, a bitrate is often chosen
which removes just a bit too much detail, so the artefacts are just
visible - or am I being cynical?
Just a side note from my conversion testing, but Handbrake seems to reduce the size of the file considerably (about 5 times?).
Is this to be expected?
Just putting this here as a reminder for further research.
"Brian Gaff" <brian1gaff@gmail.com> wrote in message news:tenf2m$1psru$1@dont-email.me...
People tell me it has to do with how the areas that do not change between
frames are encoded. Whether a sighted person will notice is very
dependent on whether the brain papers over the mistakes. After all the
working eye itself has a lot of processing before it can become the image
you actually see, or think you see. A lot of it is inferred from the bit
the macular has seen being added to the lower definition parts of what
you are seeing.
Video compression algorithms work by transmitting a "key frame" every so often (typically every 10-15 frames) which is a full-detail frame (subject
to lossy JPEG-type compression). This is followed by a series of
difference frames: differences between the current frame and the last key frame). For a scene that is fairly static with just a small amount of movement, this means that the difference frames are very small. The
encoder has to be able to compare successive source frames and insert a
new key frame, even if it is sooner than the normal 10-15 frames, if the scene changes dramatically (eg at a shot change). This avoids having to transmit huge difference frames between the current frame and a key frame that is dramatically different.
It works well, but it can lead to macro-blocks (large squares that are typically 16 pixels square) on parts of a frame that change very rapidly -
eg if the camera is panning or the subject moves across the frame very quickly. Ideally the encoder would allocate a higher bit rate (ie larger difference frame) is there is large movement, but sometimes the encoder is restricted on the maximum bit rate.
If you record a programme that has a lot of camera-panning or other
movement and play back those sequences frame by frame you can see a lot of macro-blocking.
Another possible artefact is detail that goes missing on fairly plain backgrounds when there is a lot of movement: the classic one is a football match where there is detail in the grass which can degenerate into a featureless green mass if the bits that are needed to reproduce the grass detail are suddenly needed when many of the players move in the frame.
As with any lossy compression, the art is in choosing a bitrate which only removes details that a normal viewer would not notice, while not reducing
the bitrate to the extent that the picture looks overcompressed - blocky
or lacking in detail. In general, a bitrate is often chosen which removes just a bit too much detail, so the artefacts are just visible - or am I
being cynical?
The processing of the eye / brain is incredible. It is hard to believe
that the image that the eye sends has a hole in it, which corresponds to
the blind spot where the optic nerve enters the eye, and the eye
compensates for this by constantly moving slightly so as to fill in the
blind spot - and yet the brain filters out that movement, even in cases of people with nystagmus where the movements are so large that other people
can see the person's eyes moving around. Flautist/flutist James Galway is
an example of this: in close-ups you could see his eyes dancing around.
On 31/08/2022 12:33, NY wrote:
Video compression algorithms work by transmitting a "key frame" every
so often (typically every 10-15 frames) which is a full-detail frame
(subject to lossy JPEG-
I think 10-15 is rather shorter than used in practice. A suggested
value for a video server was 2 seconds, and up to 4.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 297 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 08:47:12 |
| Calls: | 6,666 |
| Files: | 12,213 |
| Messages: | 5,336,260 |