On Sat, Nov 28, 2015 at 09:03:20AM +0200, Timo Teras wrote:
> Hi,
>
> While the pcr is accuracte, I was measuring the cbr pcr frequence with
> opencaster suite's tspcmeasure tool, and it says that the frequency is
> not that accurate. With default options (just muxrate specified) the
> pcr should appear every 20ms. But it appears every 19-22.5ms (also
> there some appearances with 1-18ms but those are probably the extra pcr
> announces for key frames).
>
> While in practice this is not too bad for me, I wondered how it should
> be generated instead.
>
> Seems that the period is calculated in mpegts_write_header():
> pcr_packet_period = mux_rate * pcr_period / (TS_PACKET_SIZE * 8 * 1000)
>
> Which is the packet period over the whole mpeg ts stream. But the count
> is actually incremented like mpegts_write_pes():
> while (payload_size > 0) {
> retransmit_si_info(s, force_pat, dts);
> force_pat = 0;
> write_pcr = 0;
> if (ts_st->pid == ts_st->service->pcr_pid) {
> if (ts->mux_rate > 1 || is_start) // VBR pcr period is based on
> frames
> ts_st->service->pcr_packet_count++;
>
> The problem seems to be that only packets for pcr_pid are counted in
> the pcr period. That's why the gap goes >20ms when there's other
> streams muxed (usually audio) and depends on the other PES' bandwidth.
> Same is true for sdt and pat - they drift very slightly, because they
> don't count each other's packets.
>
> I was wondering how to fix this. Would it be best to remove all
> {sdt,pat,pcr}_packet_count variables, and replace it with single
> packet_count counter that is incremented everytime a packet is sent
> (in the four functions section_write_packet(),
> mpegts_insert_null_packet(), mpegts_insert_pcr_only(),
> mpegts_write_pes()) and then calculate just the next packet count when
> to trigger resend. packet_count + {sdt,pat,pcr}_packet_period.wouldnt packet_count overflow? (can be worked around of course just want to make sure i understand what you suggest) > > Another problem case is the inserting of null/pcr-only packets. If it's > a non-pcr stream PES packet triggering the stuffing, it should still > stuff pcr to the pcr_pid - not the pid of the stream triggering the > stuffing. Basically the strategy in cbr mode should be: > 1) Check / send SDT/PAT as currently > 2) Check if PCR needs to be sent > 3) If filler packets needed: a) send pcr on pcr_pid, OR b) send null > 4) If PCR send needed but ES PID != pcr pid: send PCR only on pcr_pid > 5) Proceed with sending ES on ES PID as regular > > Does this reasoning / approach make sense? yes > > Thanks, > Timo > _______________________________________________ > ffmpeg-devel mailing list > [email protected] > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus
signature.asc
Description: Digital signature
_______________________________________________ ffmpeg-devel mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
