Yes, that would be one way of doing it. Things are a lot simpler if you can assume constant bit rate elementary streams, for example. In that case, you'll have to maintain a constant bitrate, not forgetting to account for the packetization overhead. The PTS coding is straightforward - just display the frames in sequence, taking care to display them only at the appropriate time (every 3003 clock cycles in NTSC, for example). Determining the DTS is more involved, and I can't tell you off the top of my head how to go about calculating the DTS correctly. Ori Vinod Kumar wrote: > hello > The best way to assure that the there is no overflow underflow in the > T-STD buffers, according to my knowledge (pls correct me if I am wrong), > would be to emulate the T-STD buffers at the transport stream generation > end. This ensures that the PTS and the DTS coded is right. > > regards > vinod > Ori Pessach wrote: > > > > Thenmozhi, > > > > What do you use as an output device? Do you feed some hardware on the back end, or > > do you just generate a bitstream, store it someplace, and then use a software > > decoder to read it? > > > > The reason I'm asking is that typically, your TS bitrate is determined by your > > output medium. A 64QAM digital cable system will have a bitrate of 26970350 bps, > > for example. You'll have to generate enough null packets to get that bitrate. > > > > As Vinod pointed out, you'll have to worry about the T-STD. Read that part of the > > spec, and then read it again. Then sleep over it, and read it once more. It's > > nasty, but it's good for you. > > > > Cheers, > > > > Ori > > > > Vinod Kumar wrote: > > > > > Hi > > > yes the padding of the transport stream with the null packets will be > > > constrained upon the fact that the TSD buffers at the transport stream > > > will not overflow. > > > > > > Thenmozhi Arunan wrote: > > > > > > > > I'm not sure if this is the right mailing-list to post this query? If not > > > > pls redirect me to mailgroups that discuss mpeg-2 systems. > > > > > > > > In our multimedia lab, I have been working on developing a s/w > > > > transport stream multiplexer. I have it working and a std IRD is able to > > > > decode the stream. It is a single program ts generator. However, I'm not > > > > clear as to what should be set as the TS bitrate value. > > > > > > > > Currently, i'm setting ts bitrate = video_bitrate + audio bitrate + psi > > > > rate + overhead for PES/TS headers + alpha(for null packets). > > > > > > > > How can one decide on the # of null pkts that will be required for > > > > multiplexing? It could depend on vbv_buffer size used in mpeg-2 encoding. > > > > > > > > Your suggestions are most appreciated. > > > > Thenmozhi > > > > -- > > > > ---------------------------------------------------------------------------- > > > > Thenmozhi Arunan > > > > then@xxxxxxxxxxxxxxxxxxxxxxx DV012, Vigyanpura Campus, > > > > Multimedia Systems Lab IISc Quarters, (Opp ISRO Headquaters) > > > > SuperComputer Educ & Research Centre New BEL Road > > > > Indian Institute of Science Bangalore-560094 > > > > Bangalore-560012, India. KARNATAKA,India > > > > Office Ph: 80-309 2896. Home Ph: 341 1952 > > > > ---------------------------------------------------------------------------- > > > > > > -- > Vinod Kumar MV > Research Engineer > Video Coding Group > Fraunhofer Institut für Integrierte Schaltungen > Am Weichselgarten 3, D-91058 Erlangen, > Phone : +49 (0) 9131 / 776 363 > Fax : +49 (0) 9131 / 776 999 > > _______________________________________________ > Video4linux-list mailing list > Video4linux-list@xxxxxxxxxx > https://listman.redhat.com/mailman/listinfo/video4linux-list ========================== WorldGate Communications, Inc.
