Before the patch the code creating a Dolby Vision configuration record
for Annex B type bitstreams was located in the HEVC ES
reader. However, MPEG transport streams also contain HEVC as Annex B
type bitstreams, and for those the code wasn't used. Therefore move
the code to the packetizer used by both readers.
Part of the implementation of #3113.
The MR by quietvoid only implemented creating Dolby Vision
configuration records when reading HEVC from Annex B type bitstream
files (elementary streams), but not for case of reading them from MPEG
transport streams. Therefore the patch only implements #3113 partially.
When appending the HEVC packetizers of all the tracks in the appended
chain use the same HEVC ES parser object. When the one file is
finished, the packetizer is flushed, which in turn flushes the ES
parser. This is fine the first time the ES parser is flushed.
Now the core realizes that the first file is empty & starts reading
data from the appended file in order to determine the lowest
timestamp. The appended packetizer will add data to the same ES parser
object.
The core still reads from the first source file, though, especially if
there are more packetizers for the file (e.g. audio packetizers). That
file will run into "empty" more often for the original video
packetizer, causing more call to that packetizer's flush function.
The first file's packetizer will then flush the ES parser, which
already contains data from the second file. Those frames are then
queued in the first file's packetizer. However, the core already
considers the first file's packetizer to be done & won't pull from it
again.
The result is that data from the second file ends up in the first
file's packetizer's queue that's never processed further. It's still
there when mkvmerge finishes.
The fix is to only call the ES parser's flush function once per call
to a packetizer's flush function.
Fixes#3479.
See Blu-ray specs section 6.2.1.
On Blu-rays the MPEG transport streams consist of a sequence of
so-called "source packets". A "source packet" consists of a four-byte
long `TP_extra_header` structure followed by the "transport packet"
that we're actually interested in. The latter is the one that starts
with a `0x47` byte.
The MPEG TS reader contains code to find the start of the "transport
packet" by looking for that `0x47` byte & then reading 192-byte long
chunks starting from there. This works well as long as the
`TP_extra_header` structure itself doesn't contain a `0x47`. As that
structure contains some type of timestamp, this is very much possible.
If this is the case, the detection of the start of the "transport
packet" is thrown off. Often a resync is attempted, during which at
a handful of "transport packets" are skipped, leading to a loss of
frames in the content (often video, which means dropping everything
before the second key frame).
Fixes#3632.
