[FFmpeg-devel] [bug/patch] MPEG-TS muxer: PCR not in sync withPTS/DTS

[Niobos]

On 09 Sep 2009, at 12:07, Stratford, Alan wrote:
> Thanks for the explanation. My algebra skills must be going rusty.
> However, while I can see that your rearrangement is equivalent I don't
> see the reason for it. It seems to make it less clear what the
> calculation does for no obvious gain.

I'll use "my" and "your" version in the list below to indicate the  
different approaches.
Reasons:
* To stay close to the original code
* My formula can be combined with the other overhead lines since it's  
an addition; your formula is a multiplication and needs its own  
statement.
* I don't think that "add 4 bytes of TS header ever 184" is unclear.

I'm ok with adopting your formula if more people support it.

> I have a couple of further points on the total_bit_rate calculation.
>
> 1. It seems that the PCRs are accounted for, but the fact that they
> contribute to extra TS headers are not. i.e. I think that the extra
> bytes due to PCRs should be added to total_bit_rate before adjusting  
> it
> for TS headers. Something like this:
>
> total_bit_rate += 1000 * 8 * 8 / PCR_RETRANS_TIME;
> total_bit_rate += 4 * total_bit_rate / (TS_PACKET_SIZE-4)
>                 + 1000 * 8 * sdt_size / SDT_RETRANS_TIME
>                 + 1000 * 8 * pat_pmt_size / PAT_RETRANS_TIME;

You are correct, although it hardly matters: 70bps with the current  
PCR_RETRANS_TIME.
Adapted patch (against r19796) in attachment
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-mpegts-vbr-3.diff
Type: application/octet-stream
Size: 5294 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090909/655430a7/attachment.obj>
-------------- next part --------------


> 2. It seems that the stuffing bytes in the last TS packet in each PES
> are also not accounted for. I don't know how one would account for  
> these
> as the size would depend on the achieved compression rate. Any ideas?

That is accounted for, kind of:
total_bit_rate += (19*8 + 184/2*8) / av_q2d(st->codec->time_base);
/* 1 PES per frame
* 19B of PES header
* on average a half TS-packet (184/2) of padding-overhead every PES */

The exact number of padding bytes depends on compressed frame size MOD  
184, which is highly unpredictable. The average of 92B is the best I  
could come up with. Worst case this gives an error of roughly 18kbps  
at 25fps, which is acceptable in my opinion.


> I am very new to MPEG, so please forgive any errors in the above.  
> Again
> I would greatly appreciate any explanation you can give.

I was a new to MPEG a few months ago, and still am... I'm glad that  
someone does the effort of going over my code and point me to things I  
have overlooked.

Thanks for the feedback,
Niobos