[FFmpeg-devel] mpegtsenc: Improve PCR generation and output

[Tomas Härdin]

On Mon, 2010-10-04 at 16:48 +0200, Tomas H?rdin wrote:
> On Thu, 2010-09-30 at 11:33 -0700, Baptiste Coudurier wrote:
> > Hi Tomas,
> > 
> > On 9/30/10 7:07 AM, Tomas H?rdin wrote:
> > > Hi
> > >
> > > While working some more on remuxing dvbsub in mpegts I noticed that the
> > > longer the sample I used was, the higher the muxdelay I needed in order
> > > to avoid the "dts<  pcr, TS is invalid" warning.
> > >
> > > This is due to how the current muxer calculates PCR. It simply
> > > accumulates TS_PACKET_SIZE*8*90000LL/ts->mux_rate in cur_pcr. Unless
> > > your mux_rate evenly divides 135360000 (TS_PACKET_SIZE*8*90000) this
> > > will cause rounding errors which quickly lead to unacceptable PCR drift.
> > >
> > > A second problem is that it only uses 90 kHz precision, when it should
> > > use 27 MHz. 90 kHz is insufficient to stay within the allowed +- 500 ns
> > > jitter.
> > >
> > > The attached patch calculates PCR based on max_delay and the current
> > > size of the output, in 27 MHz. This method should eliminate any PCR
> > > drift caused by the rounding errors in the previous solution. It also
> > > outputs the full PCR.
> > >
> > > The patch passes the regtests, but that seems to be because there are
> > > none for mpegts. Maybe some should be added?
> > 
> > The test is present, by default the muxer uses VBR, you activate CBR 
> > muxing by specifying a muxrate. Did you test specifying a muxrate ? :)
> > 
> > Patch looks good, thanks for the work, I'll test it against some tools.
> 
> Actually, I made a mistake. The six reserved bits are between
> program_clock_reference_base and program_clock_reference_extension, not
> after. So the patch writes the program_clock_reference_extension bits in
> the wrong place. See table 2-7 on page 44 in ISO/IEC 13818-1.
> 
> Updated patch attached.
> 
> As for testing, I failed to find a file in tests/ that contains "mpegts"
> or whose name includes "mpegts", so how would I go about testing this?
> 
> /Tomas

I discovered another bug yesterday. If dts ever becomes less than pcr
the check at line 668 causes the code to go into a near-infinite loop.
This is because the subtraction yields a negative value in an unsigned
result - in other words something around UINT64_MAX.

The attached patch fixes this by having the new code use int64_t instead
of uint64_t for pcr.

/Tomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mpegtsenc_pcr3.patch
Type: text/x-patch
Size: 5007 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101006/c2fe4a18/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20101006/c2fe4a18/attachment.pgp>