[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