[FFmpeg-soc] Extend TSMuxer to H264 muxing

[zhentan feng]

Hi

2008/4/16, Michael Niedermayer <michaelni at gmx.at>:
>
> On Wed, Apr 16, 2008 at 05:03:13PM +0800, zhentan feng wrote:
> > Hi
> >
> > 2008/4/15, Michael Niedermayer <michaelni at gmx.at>:
> > >
> > > On Tue, Apr 15, 2008 at 09:33:34PM +0800, zhentan feng wrote:
> > > > Hi
> > > >
> > > > 2008/4/14, Baptiste Coudurier <baptiste.coudurier at smartjog.com>:
> > > > >
> > > > > On Mon, Apr 14, 2008 at 02:40:54PM +0800, zhentan feng wrote:
> > > > > > [...]
> > > > > >
> > > > > > > > +                if(st->codec->codec_id == CODEC_ID_H264){
> > > > >
> > > > > > > > +                    H264Context * h_st =
> st->codec->priv_data;
> > > > > > >
> > > > > > > This is invalid, there is a reason why its called priv_data,
> and
> > > that
> > > > > is
> > > > > > > that it is private to the codec.
> > > > > >
> > > > > > I think it is the key point to write descriptors into PMT for
> AVC
> > > > > stream.
> > > > > > Can't I get the h264 codec information when init TS out stream?
> > > > > > Do you mean the *priv_data* only could be used by libavcodec
> > > functions,
> > > > > we
> > > > > > can't read some information from it by other extern functions?
> > > > > > If so, I am a little confused how could I get information when
> init
> > > the
> > > > > > descriptor?
> > > > > >
> > > > >
> > > > >
> > > > > No you cannot, only libavcodec h264 decoder is allowed to use
> > > priv_data,
> > > > > TS muxer has to parse PPS/PPS and gather needed infos.
> > > >
> > > >
> > > > Here is the  new patch names "h264_desc_aud_patch4-15.diff" attached
> > > below.
> > > >
> > > > 1,Add a new struct MpegTSH264Desc in MpegTSWriteStream to collect
> > > > information of AVC stream descriptors.
> > > > 2,Parser the SPS and VUI to write descriptor into PMT.
> > > > 3,Check the AUD nal units. if pkt don't have ,then insert AUD nal
> units
> > > into
> > > > the AVPacket data.
> > > >
> > > > Thanks for your any advice and best wishes.
> > >
> > > [...]
> > > > +void pre_decode_vui(MpegTSH264Desc * h_dsc, GetBitContext *gb)
> > > > +{
> > > > +    int aspect_ratio_info_present_flag;
> > > > +    unsigned int aspect_ratio_idc;
> > > > +    int nal_hrd_parameters_present_flag,
> > > vcl_hrd_parameters_present_flag;
> > > > +    aspect_ratio_info_present_flag= get_bits1(gb);
> > > >
> > > > +    if(aspect_ratio_info_present_flag){
> > > > +        aspect_ratio_idc= get_bits(gb, 8);
> > > > +        if(aspect_ratio_idc == EXTENDED_SAR){
> > > > +            get_bits(gb, 16);
> > > > +            get_bits(gb, 16);
> > > > +        }else if(sizeof(pixel_aspect)/sizeof(*pixel_aspect) <=
> > > aspect_ratio_idc){
> > > > +            return -1;
> > > > +        }
> > > > +    }
> > > > +
> > > > +    if(get_bits1(gb)){      /* overscan_info_present_flag */
> > > > +        get_bits1(gb);      /* overscan_appropriate_flag */
> > > > +    }
> > > > +
> > > > +    if(get_bits1(gb)){      /* video_signal_type_present_flag */
> > > > +        get_bits(gb, 3);    /* video_format */
> > > > +        get_bits1(gb);      /* video_full_range_flag */
> > > > +        if(get_bits1(gb)){  /* colour_description_present_flag */
> > > > +            get_bits(gb, 8); /* colour_primaries */
> > > > +            get_bits(gb, 8); /* transfer_characteristics */
> > > > +            get_bits(gb, 8); /* matrix_coefficients */
> > > > +        }
> > > > +    }
> > >
> > > duplicate of decode_vui_parameters()
> >
> >
> >  Yes, it is a duplicate code from H264.c.
> > I am in a dillema to handle the problem :
> > When init TS muxer , I should read some information about AVC stream
> from
> > H264Context, which is priv_data of AVCodecContext(libavcodec) so, I
> cannot
> > get them directly from upper level(libavformat).
> >
> > I think it may has 4 ways to handle the peoblem:
> >
> > 1, Decode the SPS by TS muxer and *don't* reuse the code of h264.c
> >
> > At libavformat level, just parser the AVC data independently from
> AVPacket
> > and get information what we need. Because we don't  need all information
> of
> > the H264Context, so we can simplify the decode process.
> >
> > That's just my latest patch method to do. So, this causes some duplicate
> > code with H264 decode of h264.c.
> >
> > 2, Decode the SPS by TS muxer and reuse the code of h264.c
> > This method will change some code of h264.c to export the interface, so
> it
> > may break up the logic level process and encapsulation of the H264
> decoder.
> >
> > 3, Don't decode the SPS by TS muxer and get the information by add a new
> > struct in AVCodecContext, such as MpegTSH264Desc.
> > When decode the H264 stream, we can write useful information into
> > MpegTSH264Desc and will be later fecthed by the upper level.But we still
> > decode the AVC stream to check the AUD nal units, if the pkt->data
> donnot
> > have the AUD, we should insert AUD nal units to the AVC stream before
> muxing
> > into PES packet.
> >
> > Any ideas about the methods?
>
>
> 1. duplicates code
> I do not understand what you suggest in 3.


I mean 3 as two patrs :
1)Since AVCodecContext priv_data could not be used to pass parameters from
avcodec to avformat, I think it would be feasible to pass these using other
field of AVCodecContext, like opaque, or add additional field to pass that.
That would avoid the redundant work to decode h.264 packet in muxer again
and keep the code in the h264.c decoder clean.

2）This is about AUD nal unit problems.
It is necessary to confirm the AVC stream data wrapped in AVPacket have AUD
nal units. If not,we should decode the AVC stream again and insert AUD nal
uints into the stream. So, this may cause some changes to H264.c or just
decode the stream by TS muxer in the upper level and this may cause some
small duplicate code.

>
>
>

-- 
Best wishes~