<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Nov 18, 2016 at 3:47 AM, Simon Hobson <span dir="ltr"><<a href="mailto:linux@thehobsons.co.uk" target="_blank">linux@thehobsons.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
</span>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).<br>
<div class="HOEnZb"><div class="h5"><br></div></div></blockquote><div><br></div><div>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. </div><div><br></div><div>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) </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>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. </div><div><br></div><div>Mike</div><div><br></div><div><br></div><div><br></div></div></div></div>