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

[Niobos]

> I think it would be easier to generate a CBR transport stream, however
> I think it's good to generate a VBR ts if it works :)
> Well, for my purpose, a VBR would be very nice, so I'll look into  
> that.

Finally got around to do this. I reworked the previous patch quite a  
lot.

In attachement:
* ffmpeg-mpegts-freq-period-rename2: addition to the previous patch: I  
forgot one.
* ffmpeg-mpegts-vbr: Changes to support VBR Transport Streams
* 2 graphs showing the timing in the first 1000 TS-packets of my test- 
stream, illustrating the effect of the changes
Both patches are against svn19750.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-mpegts-freq-period-rename2.diff
Type: application/octet-stream
Size: 757 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090831/773709ee/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ffmpeg-mpegts-vbr.diff
Type: application/octet-stream
Size: 4722 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090831/773709ee/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svn19750+patch.png
Type: image/png
Size: 6627 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090831/773709ee/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svn19750.png
Type: image/png
Size: 6238 bytes
Desc: not available
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20090831/773709ee/attachment-0001.png>
-------------- next part --------------


Summary of changes:
* Changed the calculation of total_bit_rate to be more accurate
* Specifying -muxrate on the command line switches to CBR mode; no - 
muxrate means VBR
* I increased the log-level of the av_log to display the calculated  
bitrates by default. This should facilitate the users to determine the  
correct CBR muxrate
* To maintain a CBR stream, null-packets are inserted when DTS drifts  
from PCR
* To maintain DTS/PCR sync in VBR streams, the PCR is increased  
without a null-packet
* Since the PCR is only stepped forward, the initial calculated  
mux_rate is wildly overestimated

Currently the patch defaults to VBR. I'd like to get some feedback  
whether or not this is a good idea.

Niobos