tsvbr2cbr/tspcrmeasure tools incorrectly decodes certain PCR values. Causes files to be incorrectly filled with null packets.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
opencaster (Ubuntu) |
New
|
Undecided
|
Unassigned |
Bug Description
Package: opencaster
Version: 3.2.2+dfsg-1.1
OS release: Ubuntu 16.04.2 LTS
System info: 4.4.0-59-generic
#80-Ubuntu SMP Fri Jan 6 17:47:47 UTC 2017
x86_64 x86_64 x86_64 GNU/Linux
The "tsvbr2cbr" tool in opencaster converts a variable bitrate transport stream file to a constant bitrate one. It incorrectly decodes and processes certain PCR values due to a typecast bug and not handling wrapping of PCR values when determining the instantaneous bitrate. The result is that, for certain PCR values, it estimates an instantaneous bitrate close to infinity of the input stream and therefore incorrectly inserts gigabytes of null padding at that point in the output.
The "tspcrmeasure" tool does not have the typecast bug and so correctly decodes PCR. However it does not correctly handle wrapping of PCR.
I will attach (in follow-up comments) patches that fix the problem and two small example transport stream files that demonstrate the problem.
The transport stream files contain 5 seconds of audio and video from the "Tears of Steel" Open Movie project short film and are used here under the Creative Commons Attribution 3.0 license: https:/
Steps to reproduce below...
tspcrmeasure: Incorrect wrapping behaviour
=======
$ tspcrmeasure wrapping.ts 1000000
Actual output (line 17):
-------
70322: pid 256, new pcr is 333504 (0.012352 sec), pcr delta is 184467414967327
Expected output (when patched, line 17):
-------
70322: pid 256, new pcr is 333504 (0.012352 sec), pcr delta is 3573504, (132.352000 ms), indices delta is 4136 bytes,( 33.088000 ms), pcr accuracy is 0.0992640000, instant ts bit rate is 250000.0000000000
tsvbr2cbr wrapping problem
=======
$ tsvbr2cbr wrapping.ts 1000000 > output.ts
Expected behaviour is that it finishes, producing an output file of about 500 KBytes. However actual behaviour is that it stalls after 17 lines of output to STDERR, because it is incorrectly writing huge quantities of null padding to the output stream:
Actual output (stderr, line 17):
-------
70322: pid 256, new pcr is 333504, pcr delta is 184467414967327
Expected output (stderr, line 17):
-------
70322: pid 256, new pcr is 333504, pcr delta is 3573504, (132.352000 ms), indices delta is 4136 bytes,( 370.588565 ms), instant ts bit rate is 250000.0000000000
wasted time 0
tsvbr2cbr PCR decoded incorrectly
=======
$ tsvbr2cbr pcr_decoded_
Actual output (first line):
-------
17870: pid 256, new pcr is 532537235088, pcr delta is 7553088, (279.744000 ms), indices delta is 17484 bytes,( 139.872000 ms), instant ts bit rate is 500000.0000000000
wasted time 0
Expected output (first line):
-------
17870: pid 256, new pcr is 1821027423888, pcr delta is 7553088, (279.744000 ms), indices delta is 17484 bytes,( 139.872000 ms), instant ts bit rate is 500000.0000000000
wasted time 0
For comparison, run the same stream through tspcrmeasure which does correctly decode PCR:
$ tspcrmeasure pcr_decoded_
Output (first 2 lines):
-------
386: pid 256, new pcr is 1821019870800 (67445.180400 sec)
17870: pid 256, new pcr is 1821027423888 (67445.460144 sec), pcr delta is 7553088, (279.744000 ms), indices delta is 17484 bytes,( 139.872000 ms), pcr accuracy is 0.1398720000, instant ts bit rate is 500000.0000000000
Attached transport stream file that demonstrates the bug when PCR values wrap.