> How have you confirmed MPEG-TS compliance? While not completely definitive, I looked at it with a transport stream analyser and tested it at our TV station. At the TV station stream the file from our server through a remultiplexer that assembles the multi program transport stream with our various subchannels. The signal goes through our ATSC transmitter and decodes fine on every TV I have tested.
> Seven TS packets go inside a single UDP packet. This is not dictated by the standards. They support anywhere between 1-7 TS packets per datagram. Seven packets per datagram is by far the most common though due to common MTU size limitations. > udp can work with any muxer that does not require seeking (if all > packets are received at the receiver end) The reason I asked is that I am trying to figure out where is best to determine the UDP rate. It may be more efficient to do that in the muxer as it has more information on the subject available and also already knows how the time stamps are saved in each packet. In that case, we need a list of all the FFmpeg muxers that currently support udp as an output. By reading PCR from the packets to determine the rate, we have to assume or set a header format and PCR location and format. If limiting smooth packet transmission to using the mpegts muxer is sufficient, then we could just implement a rate output option for the mpegts muxer and a corresponding rate control option in udp.c. > FYI, our awful hack looks like almost working except sometimes effective bitrate lost for 1-2 seconds, then spike and > then returns to normal (it can be once after 15 minutes or after more than 4 hours before this issue). This is probably a side effect of your UDP burst kicking in. The type of implementation you used would be better if it assumed a constant bitrate set by an input option. If you want to cover vbr streams also, you need a more complex rate control and measurement method. > Also there is a question: how it supposed schedule to send packets of 1316 size when muxer produces packets of > > 188 length? For mpegts, some of the muxer packets contain a PCR, or program clock reference. You count the number of bits between PCR values and derive a bitrate. From that you can calculate the datagram period based on datagram size and send at that constant rate. I havent' found a reference that specifies maximum datagram jitter, but my test setup using TV sets to decode works with datagrams that are late up to about 250 micro seconds. The console output of FFmpeg contains a bitrate value in the status line. If we can grab that at a high enough frequency and pass it to udp.c, then we no longer have to worry about header formats and bit rate calculations. I assume that originates in the muxer? Given the datagram size and the bitrate it should be simple to calculate the packet period and control the datagram transmission frequency. Zach On Thu, Nov 19, 2015 at 4:18 AM, Kieran Kunhya <kier...@obe.tv> wrote: > On 19 November 2015 at 12:00, Pavel Meshkov <pmesh...@kwikflixtv.com> > wrote: > > FYI, our awful hack looks like almost working except sometimes effective > > bitrate lost for 1-2 seconds, then spike and then returns to normal (it > can > > be once after 15 minutes or after more than 4 hours before this issue). > > > > Also there is a question: how it supposed schedule to send packets of > 1316 > > size when muxer produces packets of 188 length? > > Seven TS packets go inside a single UDP packet. > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
