[FFmpeg-devel] RTP mark bit not passed to parse_packet
Thu Jan 15 12:10:31 CET 2009
Alexandre FERRIEUX - FT/RD/SIRP/ASF/SOFTL wrote:
>> I think the RTP de-packetiser is not supposed to split the stream in
>> frames, but simply to simply return the payload. libavcodec then contains
>> a parser (see libavcodec/h263_parser.c) that is in charge of splitting the
>> stream in frames. You just have to ensure that rtp_parse_open() sets
>> st->need_parsing = AVSTREAM_PARSE_FULL for H.263 too (as it already does
>> for mpeg video, and audio, H.264, etc...).
> Thanks, that is indeed the key info I was missing.
> Discovering this, I realize I may not have read all the relevant
> documentation. I apologize for this. I'd appreciate a pointer to the
> part describing the interaction between the encapsulation and codec layers.
Well... There is not much written documentation (you know, the code is
the documentation ;-)
If you have doubts, just ask and if someone knows the answer he will
> In the meantime, just one point I'd like to clarify regarding H263:
> The follow-on-packet method just uses a payload-header of 2 bytes, with
> values 0x0400 for the first packet (P bit set) and 0x0000 for
> follow-ons. In addition, the P bit in the first packet "encode" two zero
> bytes of the subsequent bitstream (which are thus removed on
> encapsulation). Then, when depacketizing the first packet, should I pass
> to the decoder:
> - the 0400 header + bitstream without 0000
> - the 0400 header + bitstream with 0000
> - bitstream with 0000 but no payload header
I do not know the H.263 bitstream format, but if I understand well the
third option looks the correct one. Basically, you should return a
valid H.263 bitstream (removing the RTP payload header and adding back
the parts that have been removed during the RTP packetisation).
> (and similar question for follow-ons).
In the follow-on the RTP packetiser does not remove any byte from the
bitstream, right? So, I think you should just remove the two bytes
of the payload header without adding anything to the bitstream.
> But here is already what I did on the other side, to allow ffmpeg to
> stream H263 out. Of course it is just the simple follow-on method, hence
> no error resilience. It is notably less ambitious than what is currently
> done for H264; but I have the plan to improve it later).
I have a similar patch in my local tree, but I never committed it because
it is correct (AFAICS) but suboptimal... I wanted to implement something
smarter, but I never found the time. Anyway, in the next months I'll clean
up your patch (or I'll finish my one) and I'll commit it.
More information about the ffmpeg-devel