[MPlayer-dev-eng] Re: [PATCH] H264 over rtsp, v5

Carl Eugen Hoyos cehoyos at ag.or.at
Fri Mar 9 02:00:15 CET 2007


Nico Sabbi <nicola_sabbi <at> fastwebnet.it> writes:

> I can't believe that there isn't a simpler way to play this kind of 
> content. This repacking is a huge mess, and doesn't belong to a demuxer.
> Since now lavc can decode out of order NALs can't we simply pass them 

(I assume you mean "individual NAL units that are not complete frames" here)

> to the decoder assuming that one demux_packet contains exactly one 
> NAL?  (Ross, is this the case? )

As pointed out on ffmpeg-devel
(http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/45593) several problems
exist with this approach:

Framerate is not correct: It would be necessary to multiply with n (number of
NALs per frame), but if we knew n we could just concatenate the packets as in my
original patch, couldn't we? Or is forcing -correct-pts acceptable?

I haven't been able to set the "NALs might not be frames" option to libavcodec
in the demuxer, I tried this line:
((AVCodecContext*)sh_video->context)->flags2 |= CODEC_FLAG2_CHUNKS;
For every frame, but that didn't work.

It would still be necessary to insert 0x000001 into every packet, which wouldn't
make the patch so much smaller, additionally, Michael pointed out a possible
problem with out-of-sync packets that the decoder tries to apply to wrong frame
(see thread in ffmpeg-devel).

> Michael an Loren, are there  limitations in how the decoder can deal
> with out of order NALs?

Not worse than with AVParser, if I remember Michaels comment about Ryans patch
correctly: Out of order NALs are simply not corrected.

Carl Eugen





More information about the MPlayer-dev-eng mailing list