[mythtv-users] Concert footage and video artifacts

[Mike Hodson]

On Fri, Nov 18, 2016 at 3:47 AM, Simon Hobson <linux at thehobsons.co.uk>
wrote:

>
> That explains one reason why the bandwidth is constrained (even without
> any $$$ pressures, there'd still be technical limits) - but it doesn't
> explain why the effect itself happens (which was the purpose of my post).
>
>
This is my best guess, after about 18 years of messing around with video
encoding, from tmpgenc to div3/4/5/xvid/x264/265 I keep seeing a similar
pattern happen if you bitrate-starve a scene change. Div3 (with Nandub) 4/5
and beyond all had varying GOP structures; I am not sure MPEG2 ever gained
such in common use.

To my eyes and sensibility, the reason comes down to variable bitrate
encoding,  buffer sizes, and very likely being lockstepped to a IPBPBPBPB
GOP structure (assuming a 10 frame GOP structure to 'refresh' 3 times per
second with a full iframe at ~30fps)

The "sparkly effect" of the glittery studio set likely already used up all
of the (somewhat small) buffer accumulated from similar pictures before the
scene change, and to keep the VBR bitrate "about X megabits/s over Y time
period" the encoder is starved for bits mid-group-of-pictures and the scene
change looks ... bad until an I frame comes along.

In the example 10 image GOP (group of pictures) above, if for example the
scene changes on the 5th frame of this group, all you have is 2 progressive
frames and 2 between frames (low, and lower bitrates in that order) to try
and 'introduce' a whole new frame. It takes until the I frame, a
full-screen repaint by definition, to get everything "back to looking good"
and then the P and B frames can 'refine' the image after this I frame
within about 2-3 frames.

I honestly don't think that the mpeg2 encoders at local broadcasters are of
the quality, or delay buffer needed, to properly account for such a large
scene change by being able to decrease the bits of the 'sparkly scenes' and
provide enough bits 'just in time' for the new scene, mid GOP.  I also
don't think that these mpeg2 encoders -vary- their GOP structure at all.

If anyone can provide a stream copy of a stream copy from a headend encoder
that _does_ vary the GOP structure, I'd be very interested in seeing it.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mythtv.org/pipermail/mythtv-users/attachments/20161118/381b4a2f/attachment.html>