Tim Wescott <tim@seemywebsite.com> wrote:

(snip, I wrote)
>> It seems to me that one case that MPEG doesn't do well is rapid changes
>> in overall illumination.  Specifically, the case where many flash
>> photographs are being taken in a short time.

(snip)
> The MPEG standard only specifies how things are decoded -- not how they 
> are encoded.  So the video quality and size is heavily dependent on how 
> the encoding is done, and that encoding is up to the system designer (or 
> the user, depending on what system he's using).  One could make one's 
> entire movie out of reference frames, if one didn't mind the size of the 
> resulting file.

> Put that together with Vladimir's cited fact that you can have 16 
> reference frames (good idea, that -- it's been a while since I paid much 
> attention to MPEG), you could theoretically have a "white" reference 
> frame that you'd stick in for a flash.

Yes, I didn't know about the 16 reference frames.  So, the real
problem is that the encoders aren't so good.  I would have thought
that broadcast television would be able to afford the best encoders.

Now, I have a DVD recorder that probably doesn't have the fanciest
encoder, and when the picture doesn't look so good I know why.  
(Because it didn't cost all that much.  I think less than $100 new.)

-- glen

On Mon, 26 Sep 2011 23:54:19 +0000, glen herrmannsfeldt wrote:

> While posting to the DCT vs. FFT discussion, I was reminded of some
> thoughts related to MPEG and video compression.
> 
> It seems to me that one case that MPEG doesn't do well is rapid changes
> in overall illumination.  Specifically, the case where many flash
> photographs are being taken in a short time.
> 
> That causes little problem with analog video, where frames are
> independent of each other.  For MPEG, which depends on the change
> between frames being small, it fails badly.
> 
> It would seem that a small number of bits added appropriately could help
> somewhat.  In the case where the frame suddenly goes completely white
> (or black), a single bit (or two) could represent this.  If done
> carefully, the prediction algorithm could continue after the flash.   If
> the frame doesn't go completely white, then it isn't quite as easy, but
> it might still be possible to handle.
> 
> I don't know if anyone who works on MPEG reads this group. If there are
> better groups to post, I will post there.

The MPEG standard only specifies how things are decoded -- not how they 
are encoded.  So the video quality and size is heavily dependent on how 
the encoding is done, and that encoding is up to the system designer (or 
the user, depending on what system he's using).  One could make one's 
entire movie out of reference frames, if one didn't mind the size of the 
resulting file.

Put that together with Vladimir's cited fact that you can have 16 
reference frames (good idea, that -- it's been a while since I paid much 
attention to MPEG), you could theoretically have a "white" reference 
frame that you'd stick in for a flash.

-- 
www.wescottdesign.com

glen herrmannsfeldt wrote:

> While posting to the DCT vs. FFT discussion, I was reminded of some
> thoughts related to MPEG and video compression.
> 
> It seems to me that one case that MPEG doesn't do well is rapid
> changes in overall illumination.  Specifically, the case where
> many flash photographs are being taken in a short time.

> That causes little problem with analog video, where frames are
> independent of each other.  For MPEG, which depends on the change
> between frames being small, it fails badly.  
> 
> It would seem that a small number of bits added appropriately
> could help somewhat.  In the case where the frame suddenly goes
> completely white (or black), a single bit (or two) could represent
> this.  If done carefully, the prediction algorithm could continue
> after the flash.   If the frame doesn't go completely white, then
> it isn't quite as easy, but it might still be possible to handle.
> 
> I don't know if anyone who works on MPEG reads this group.
> If there are better groups to post, I will post there.

MPEG-4 provides up to 32 (IIRC) different reference frames to handle the 
rapid changes in the picture (like switching from one camera view to 
another). There is also a lookahead buffer of several hundred kilobytes 
to accomodate peak demands in the bit rate when the picture is changing. 
All of that works great if you could allow for the processing delay, but 
it could not do very well with the real time as it could not foresee the 
future. Some companies employ a human "Compressionist" to optimize the 
digital image compression in the real time.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

While posting to the DCT vs. FFT discussion, I was reminded of some
thoughts related to MPEG and video compression.

It seems to me that one case that MPEG doesn't do well is rapid
changes in overall illumination.  Specifically, the case where
many flash photographs are being taken in a short time.

That causes little problem with analog video, where frames are
independent of each other.  For MPEG, which depends on the change
between frames being small, it fails badly.  

It would seem that a small number of bits added appropriately
could help somewhat.  In the case where the frame suddenly goes
completely white (or black), a single bit (or two) could represent
this.  If done carefully, the prediction algorithm could continue
after the flash.   If the frame doesn't go completely white, then
it isn't quite as easy, but it might still be possible to handle.

I don't know if anyone who works on MPEG reads this group.
If there are better groups to post, I will post there.

-- glen