> However, changing resolutions at every flip of the coin is likely to > cause your STBs to fall over. Implementing such a system is an exercise > in futility. It is futile if your codec is not designed for it. Again, with a documented standard with no provision for it there could certainly be problems. But that is not to say it isn't possible or even a good idea. For instance I believe the MS VC9 codec already uses a variable sized macro block depending upon various conditions. And what really is the definition of "resolution" in a lossy codec? Just the number of sample points represented? If so you could certainly imagine conditions under which if would be effective to adjust that on the fly as material became more or less difficult or bandwidth became more or less available. Block based codecs reach a point where they create blocks. Filtering to excessive softness can help the bit rate but it is more effective to encode at a lower resolution and decrease the fixed overhead per block by decreasing the number of blocks that must be coded. Cable and satellite companies occasionally upgrade standards and boxes. They can change this if they feel it would be effective with a new codec. ATSC would certainly take longer. ;-) - Tom Kon Wilms wrote: >>But cable and satellite do not really have these restrictions so we >>will probably see more in between resolutions there. Personally I >>think resolution should vary instantly and continuously based upon the >>channel capacity and the possible benefits offered by the source. >>Stat muxing re-encoders should be able to change them on the fly. >> >> >> > > Ofcourse they do. They make their own restrictions. Restrictions mean > simplicity and simplicity means a low-cost STB. > > Now if youre talking pirated movies and that whole scene of video caps > in 640x272 and other 'inbetween' resolutions, then you may have a point. > But you aren't going to see these used anywhere except some 'dude's HTPC > or PC. > > If youre in the real world, good luck trying to convince the digital > asset management folks that you want to support anything under the sun. > > Newbie datacast rollouts have previously attempted the 'use any > resolution' mechanism. Ofcourse the first thing to do is chuckle as the > extoll the virtues of the type of system you envisage. Eventually they > come to their senses and realize that it is more expedient and less time > consuming to pick a short-list of standard resolutions and one codec and > use this across the board. Anything else wastes time and money. > > As for statmuxing VBR, you can do this already. You can use your > automation system to control the encoders and flip them between SD and > HD in the AM, or whatever the configuration is. All this stuff is > addressable over IP these days - no rocket science there. > > However, changing resolutions at every flip of the coin is likely to > cause your STBs to fall over. Implementing such a system is an excercise > in futility. > > Cheers > Kon > > > ---------------------------------------------------------------------- > You can UNSUBSCRIBE from the OpenDTV list in two ways: > > - Using the UNSUBSCRIBE command in your user configuration settings at > FreeLists.org > > - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word > unsubscribe in the subject line. > > ---------------------------------------------------------------------- You can UNSUBSCRIBE from the OpenDTV list in two ways: - Using the UNSUBSCRIBE command in your user configuration settings at FreeLists.org - By sending a message to: opendtv-request@xxxxxxxxxxxxx with the word unsubscribe in the subject line.