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

[Tomas Härdin]

On Thu, 2010-10-14 at 07:34 +0200, Tomas H?rdin wrote:
> On Wed, 2010-10-06 at 11:07 +0200, Tomas H?rdin wrote:
> > 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
> 
> ping?
> 
> I assume the PS discussion doesn't relate to this patch. Also, as I
> said, this is better than looping indefinitely and will reach the "dts <
> pcr, TS is invalid" line. Having that error out is unrelated to this
> patch.
> 
> /Tomas

Applied after OK in another thread.

/Tomas
-------------- 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/20101203/a7dbde1e/attachment.pgp>