[Ffmpeg-devel] Re: mpeg transport streams

[Eric L. Hernes]

Hi M?ns,

"Eric L. Hernes" <eric at hernes.ws <http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel>> writes:

(please CC me in any responses, as I am not subscribed to the list)

> >/
/> >/ The changes to mpegtsenc.c are
/> >/ * Send full frames as PES packets rather than breaking them into
/> >/ * transport sized blocks.
/>
> Oversized frames are not handled properly.  I-frames exceeding 64k are
> not uncommon at moderate bitrates.

That is easy to fix.

> >/ * Properly stuff the adaptation field if a packet is short.
/> >/ * Calculate a PCR from the PTS - framesize
/> 
> It's not that simple.  The PCR doesn't have any direct relation to the
> PTS.  The PCR is defined as the exact time the bits comprising the PCR
> leave the muxer (pretend it's real-time), whereas the PTS is the time
> (as given by the PCR) at which a frame should be displayed.  The
> elementary streams may have a variable bitrate (within VBV
> constraints), so the offset between PTS and PCR will vary.  The only
> requirement is that the PTS never be less than the PCR.  Allowing a
> few additional milliseconds for decoding is usually a good idea.  The
> allowed PCR jitter is 500 ns, and your method doesn't get anywhere
> near that.  Also note that the maximum interval between PCR values is
> 100 ms (40 ms being commonly used), whereas PTS values may have up to
> 700 ms intervals.
> 

This largely depends on your target.  With hardware muxers and a digital
distribution, the transport streams are required to be at a constant bit rate,
so it is the muxers job to null stuff the transport to get that rate.  The method
that I'm using works much better than what's in CVS now.  I know it isn't perfect,
or possibly even close to correct, but it does work.  I also realize that with the
setup I'm testing, these PCR values may only be used as a 'hint' to the hardware
mux that rewrites the PCRs anyway.

So what is the correct way to calculate a PCR? Have packet counters for the
audio/video streams and calculate when the next packet needs to arrive?
We still need a clock from somewhere.  If a target mux-rate is specified we can use
calculate a PCR from the mux_rate and packet count. If the mux_rate isn't specified
we could use (video_bitrate + audio_bitrate + some_mux_overhead), but then it is no
longer VBR.  In a VBR stream, the only clock available is the PTS (or
frame_number/frame_rate), so we have to somehow derive the PCR from that.

Or am I missing something here?

> 
> Another problem with your muxer is that it doesn't interleave the
> streams at the TS packet level.  VBV buffer sizes often approach a
> full second, so a transmission time of a few hundred milliseconds for
> a single frame is not unlikely.  If this happens, and there is no
> interleaving of audio data, the audio decoder is likely to underrun
> unless it has a very large buffer, which is unusual with hardware
> decoders.

It is just as broken now as it was, I haven't done anything to fix
or further break the interleaving of packets.  I haven't looked at the layers involved
there.  The streams that I'm using are already ATSC streams, i.e. MPEG2/AC3, so my acodec
is just 'copy', I'm assuming that the copy codec just sends an audio packet when it gets
one so if the input is properly interleaved, so is the output.

One thing that may be helping me here is that I am only encoding standard definition
resolutions, and decoding with a high-def box, so the set-top buffers are much bigger
than what I need.


> -- 
> M?ns Rullg?rd

-Eric

 <http://mplayerhq.hu/mailman/listinfo/ffmpeg-devel>