On Thu, May 13, 2004 at 04:25:46PM +0200, Marcus Metzler wrote: > >>>>> "M�ns" == M�ns Rullg�rd <[EMAIL PROTECTED]> writes: > > M�ns> Chris Chatfield <[EMAIL PROTECTED]> writes: > >>> > I can't be the only one trying to transcode DVB output. What > >>> does > everyone else do? > >>> > >>> I've been playing around with DVB a bit, never had any > >>> problems like that. > >> I can't offer a solution to the original problem, but at least > >> I can explain briefly what's going on - DVB is transmitting > >> over the air, and you'd be doing very well to get 100% of the > >> TS packets. I suspect the OP had a moment of less than perfect > >> reception at that point - hence a missing packet. > > M�ns> This is the reason TS uses fixed-size packets and other > M�ns> things that make recovery easy. > > >> Transcode and other mpeg utilities generally expect a perfect > >> mpeg stream. We're not able to supply one unless you convert > >> the TS to mpeg with a utility that can cater for unreliable > >> input. > >> > >> It's worse if you demultiplex the stream into separate audio > >> and video streams before transcoding - a loss of a single audio > >> frame can play havoc with a/v synchronisation. > > M�ns> Isn't that what PTS is for? > > The problem is that DVD players expect an unbroken stream since a DVD > is supposed to be mastered from a reliable source. In contrast, DVB > decoders expect errors and are prepared to correct them.
> Would it be a good idea to insert of drop audio frames in replex to > avoid PTS inconsitencies? I am not sure how I should fix video frames. > Any ideas for a consistent strategy? I think it would be a good idea - it would certainly make re-encoding much easier. The logical 'filler' video would be to repeat the last known frame to fill the gap - so it would look like the video had 'frozen'. Audio is more of a problem, or less - silence might be the only option. -- /__ \_|\/ /\ -- Info: To unsubscribe send a mail to [EMAIL PROTECTED] with "unsubscribe linux-dvb" as subject.
