GNOME Bugzilla – Bug 600519
[h264psadd] New plugin
Last modified: 2010-09-23 00:23:23 UTC
Created attachment 146802 [details] Source file, header file and test file Reads codec_data from the caps for a packetized H.264 stream and extracts Sequence Parameter Set (SPS) and Picture Parameter Set (PPS). These are added to the stream prior to every I-frame.
Funny thing, I started writing some code to do the exact same thing two weeks ago, but I was sidetracked before I got to finish it. Shouldn't this kind of code be in the RTP payloader instead? And it that it should probably be done even if the PPS/SPS don't come in the codec-data but inline. Also, it would probably be nice to have a "minimum pps/sps interval" to make it possibly to sent it at most every X milliseconds.
I did consider to put it in the payloader but found it better to separate it since someone wanting SPS/PPS instream probably is a rather rare scenario. Also, it was easier doing it as a separate plugin since I could do it without seeking approval from others :) Yes, handling the instream case would probably be a good idea. But adding the new packages to a byte stream would cost a lot more than adding them to a packetized stream wouldn't it? I will only use the plugin for packetized data but that might not be the case for everyone I suppose. Adding an interval option also crossed my mind, I wasn't in need of it right now so I didn't though. I believe it is only about 25 bytes of data so for the sake of limiting the bandwidth usage it might perhaps be an unnecessary feature?
well, wanting the sps/pps instream is sadly more common than you'd hope in SIP/XMPP/etc calls :-( There is already code in the payloader to extract the codecdata from the bytestream, so re-inserting it shouldn't be too hard. And adding an extra udp packet before one that contains a keyframe isn't too expensive when its done in the payloader.
True, if its done in the payloader it wouldn't cost so much. If there is already code to extract codecdata in the payloader, then perhaps the right thing to do is to, as you suggested, add the functionality of this plugin to the payloader.
Isn't there a risk that adding the code to the payloader makes the solution undynamic? Are there no scenarios where one would need to add the SPS/PPS data to a stream where there is no payloader in the end of the pipeline? I'm asking because I have a well functioning solution now and therefor feel a little reluctant to go at it again.
Is this obsolete now that both rtph264pay and h264parse have this property: config-interval : Send SPS and PPS Insertion Interval in seconds (sprop parameter sets will be multiplexed in the data stream when detected.) (0 = disabled) flags: readable, writable Unsigned Integer. Range: 0 - 3600 Default: 0 Current: 0 ?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!