[FFmpeg-devel] RTP mark bit not passed to parse_packet

[Luca Abeni]

Hi Alexandre,

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
reply.


> 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.


			Luca