[x264-devel] Re: 264 transport

[Alex Izvorski]

On Wed, 2007-01-31 at 14:41 -0800, Axel Gunter wrote:
> Hi,
> 
> What are the most common ways to carry H264 elementary and audio in a 
> program / transport stream? Are there any softwares out there that can 
> encapsulate H264 streams in mpeg2 transport or AVI ?
> 
> Any pointers are appreciated.
> 
> -Axel

Axel,

The definitive reference on how to carry H.264 in a MPEG2 program or
transport stream is ITU H.222 amendment 3.  There is also a standards
track-recommendation by ATSC, CS/TSG-660r1
( http://www.atsc.org/standards/cs_documents/CS-TSG-660r1.pdf ), which
will probably be included in the next revision of A/53.  The ATSC
recommendation is stricter than the ITU standard, but as far as I can
tell fully backward compatible.  

I will try to summarize what these say below, and then give some
pointers on what I think is a recommended implementation.

The stream_type for H.264 must be 0x1B.  Both standards allow arbitrary
packing of H.264 NAL units into PES packets, i.e. NALs may be split
between packets, and a single packet may contain multiple NALs.
However, the PES data_alignment_indicator may be set to 1 *only if* a
H.264 access unit begins at the beginning of that packet, and that
packet does not contain any other access unit (an access unit is defined
in H.264 section 3.1 as a set of NALs which contains all the slices of
one picture and no other slices).  The PTS and DTS of a PES packet which
contains a start of access unit must be set to the correct values for
the first access unit in that packet.  In ATSC, PES packets *must* have
PES_packet_length equal to 0 (aka "unbounded packet"); also, if a packet
contains multiple access units, information sufficient to determine
their PTS/DTS must be contained in VUI timing info (num_units_in_tick,
time_scale, etc).

I think the recommended way of packing NALs into PES packets is to
concatenate all slice NALs for one picture, in order, together with any
immediately preceding SPS/PPS/AUD/SEI NALs, and put those in a single
PES packet with data_alignment_indicator=1 and PES_packet_length=0 and
with PTS/DTS corresponding to that picture.  This will work for MPEG2
transport streams but not for program streams because then there would
be no good way to find the beginning of next packet; in that case, split
the data between as many 64k-length or smaller PES packets as needed,
all with the same PTS/DTS, but of which only the first one has
data_alignment_indicator=1.  This is simple, low overhead, and
relatively standards-compliant.

For carrying other data types (AC3, AAC, ...) in MPEG2 transport
streams, look at ITU H.222 and ATSC A/53.

I have not examined the MPEG2 streams produced by ffmpeg/mplayer/vlc in
great detail but I suspect they are not fully compliant, mainly because
the spec is so tricky.  From glancing at the code briefly, they are only
a partial implementation of the standard anyway: I think a really
complete open-source implementation of MPEG2 (like gpac is for MPEG4)
just doesn't exist yet.

I hope this helps.  I'm interested to hear any comments (does anyone
have a better approach to carrying H.264 in MPEG2?) or pointers to any
MPEG2 open-source libraries I have missed.

Regards,
--Alex Izvorski



-- 
This is the x264-devel mailing-list
To unsubscribe, go to: http://developers.videolan.org/lists.html