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

[Tomas Härdin]

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
-------------- 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/20101014/4908c74c/attachment.pgp>