1) do streams that have been altered (with fades and dissolves) keep their original bitrate, or are you forced to raise the bitrate?
2) what kind of quality compromises does your process create (at both a quant block and full image level)
3) when adding titles or other image-area-specific effects, are you re-rendering entire picture groups, or just the appropriate quant blocks?
Thanks,
Halstead York
Journeyman
Just a company. A little ahead of it's time, but just a company.
Andrew Palfreyman wrote:
> Halstead -
>
> I reply to your points below. I'm reproducing some of my reply to Chris O'Leary here:
> When I refer to "Tailor", I mean FutureTel's frame-accurate MPEG editing engine, which is integrated into both the VideOh! and the Video Sphinx Pro products. Tailor is a cut-and-paste non-real-time frame-accurate MPEG editor. Tailor includes support for special effects, two of which (Fades and Titling or both) are integrated into ClipView 2.0. The current implementation of Effects is a complete re-encode (but a careful one, in the VBV sense) over the effect duration.
>
> At 12:02 AM 10/3/98 PDT, Halstead W. G. York wrote:
> >O.K. first of all, GRRRRRRRR.
>
> (I guess the R's are interframes...)
>
> >2nd, full spec MPEG-1 doesn't *have* all (or even most) it's frames. So you generally can't do frame based editing.
>
> Correct, generally speaking.
>
> >3rd, it is misleading in the extreme to call any proprietary I-frame only MPEG MPEG, because it still needs to be compressed as an MPEG-1 file *after editing*. I know that many of these editable formats do an intraframe subset of MPEG encoding when digitized, and that's cool, as it speeds up final MPEG compression. But, it is not a final delivery codec.
>
> Agreed; I also detest liars and misrepresentation.
>
> >4th, there are solutions out there that can re-produce a full frame-based timebase from a small GOP encode in a lossless fashion. However, they are all very expensive, and require fairly small GOP length (and therefore large file sizes).
>
> I wonder if you are referring to the techniques being researched by (_inter alia_) the people on the Atlantic Project? They are presenting proposals for solving the all-digital studio dilemma of the next few years, whereby streaming MPEG-2 needs to be realtime spliced on the fly seamlessly and without appreciable generational loss. It is indeed do-able, and I mention this also so as to show that I am not a lone voice crying in the wilderness about MPEG editing; the Atlantic Project has big names and big bucks behind it - and it's all on the Web, down to a level of detail that will make your teeth ache. Go viddy it.
>
> >If FutureTel is reproducing frames from final compressed MPEG files in real or near real time, then I apologize profusely. Otherwise, I feel that your statement is, from both a technical and a practical workflow perspective, misleading.
>
> You've really no need to apologise, since I can't see what slander you've committed...
> The misrepresentation reference certainly doesn't apply to Tailor. To reiterate, in its current incarnation Tailor is not billed as realtime - although it actually already is, and much more so, for a large number of the possible edit cases one finds - notably on long streams.
>
> A final case in point: The VideoCD MPEG streams which Tailor can produce as a result of splicing together multiple VideoCD MPEG streams, or just trimming a single one.
> The bitstream legality constraints for being able to burn a VideoCD CD-ROM, which is subsequently playable without problems on a Video CD player, are significantly tougher than the bitrate constraints generally applicable to streams piped into run-of-the-mill MPEG software decoders/players (the latter being a case Chris O'Leary brought up). We have seen no problems whatsoever in the playability of composite VideoCD streams which Tailor produced and which were burned onto VideoCD CD-ROM.
>
> Cheers,
> Andrew