Kieran Kunhya wrote:
For 720p25 you might need more than 3.5Mbps for more
demanding scenes. (Except increasing the bitrate or using a
better encoder will make iPlayer look better than the
broadcast...)
You do get an awful lot better results when you
are not compressing in real time, of course, because you
can use all the MPEG4 forward references, the ones you
don't get when you real time encode.
Real-time encoding with Bi-predictive frames (B-frames) in H.264 doesn't work like that.
There's a frame delay in order for B-frame encoding to take place. Most encoders worth
their while also have a lookahead for deciding frame-types and bit rate allocation.
(Sometimes this is called "2-pass" realtime, which is a bit of a misnomer for
marketing reasons. Some marketing people for manufacturers seem to spread this myth that
more passes is always better).
Using x264 with a recent CPU, if you ran it at realtime even at 720...@3mbit
you'd most likely do better than the £50k+ broadcast encoder at 1080i merely
because we're generations ahead of most (if not all) of the H.264 hardware and
software out there. Naturally, with 2-pass you can allocate bits more
efficiently but the benefits aren't as significant as they once were.
wouldn't it be 'easy' to statmux across channels - by using psuedo
multipass? You two encoders per channel - one whatever frame depth in
front of the other, and use the ideally required bitrate on each channel
to inform the 'real' codec of its bandwidth allocation?
For sufficiently high values of easy of course.
This should work well, especially with 1997 films starring Bruce Willis.
-
Sent via the backstage.bbc.co.uk discussion group. To unsubscribe, please
visit http://backstage.bbc.co.uk/archives/2005/01/mailing_list.html.
Unofficial list archive: http://www.mail-archive.com/backstage@lists.bbc.co.uk/
