rtp payloader for h261 in gstreamer

[JHenson]

Does anyone no how the rtppayload should work for ffenc_h261? I can't find one via gst-inspect | grep rtp or gst-inspect | grep h261. All of the others have one, i.e. rtph264pay, rtph263pay etc... I also can't find one on Google. Does it not need a payloader?

[Rubberman]

This is so specific to ffmpeg (I assume that is what you are using, given the ffenc_h261 reference), that you really should post this question on the ffmpeg web site's forums.

[JHenson]

This is so specific to ffmpeg (I assume that is what you are using, given the ffenc_h261 reference), that you really should post this question on the ffmpeg web site's forums.

eh..., I like you guys better. Anyways here is my thinking.

#1. ffenc_h261 has an rtp mtu attribute while none of the other encoders do.

#2 h261 is a much simpler algorithm, and it is only used for the purposes of rtp. Lord knows no one would use it to encode their dvds.

#3 This would be a very obvious oversight by the smart guys at ffmpeg--iif they didn't include an rtp payloader for h261 and the encoder didn't have native rtp support-- which I would think they would have caught.

So, I am going to go ahead and start working assuming that it does go ahead and encapsulate the stream for RTP. In the meantime, I will post this question to FFMPEG for confirmation. When I hear back, I will post it as follow up here. When either, my program works with another h323 client, or I hear back from ffmpeg I will post the results.

All the best,

[JHenson]

Ok, I've lost my brain obviously. If the filter encapsulated the packets in RTP, then the src pad would have rtp in the caps, but it doesn't. It has video/H.261. I have posted this to FFMPEG and am awaiting an answer. Regardless, I am wrong about it not needing a payloader. Plus, I tried it in my application today and I couldn't even link ffenc_h261 to gstrtpbin.