demux: ts: fix seek issues in some streams

Fixes #27646 (closed)

Currently, VLC's SeekToTime algorithm for MPEG Transport Streams involves a number of arbitrary restrictions when searching for PCR timestamps. It rejects packets whose PIDs are not included in the current program and it also rejects packets that do not contain a payload as well as packets that do not contain the payload start indicator.

However, per the official documentation describing the MPEG-TS format (ITU-T H.222.0 version 7.0) there are no such restrictions placed on where the PCR can be set (nor are there official recommendations on it). It specifies that the PCR is part of the adaptation field, and it's perfectly valid to make a packet with "adaptation field only" and no payload.

References:

• Chapter 2.4.3.3:
  • Table 2-3: "The transport packets with PID values 0x0000, 0x0001, and 0x0010-0x1FFE are allowed to carry a PCR."
  • Table 2-5: "'10': Adaptation_field only, no payload"
  • Table 2-6: PCR is an optional part of the adaptation field, see 2.4.3.5 for details
• Chapter 2.4.4.10: See PCR_PID

Our observation of the existing algorithm is that the restrictions on the contents of the packet and the type of stream are intended more for the subsequent "ParsePESHeader" call, as those restrictions make sense when using that mechanism as a fallback method to find the PCR. However, by including these restrictions prior to the line that gets the PCR if "p_pmt->i_pid_pcr == i_pid", it's rejecting packets that could have otherwise provided PCR information.

By moving the restrictions to later within the algorithm, we allow for any packets containing a matching PCR_PID to potentially supply that PCR information. This resolves seeking issues on any video that was created with PCRs set on packets without payloads.

It would also be great if this could bet backported onto 3.x, let me know what work would be required to get that ball rolling if there's interest.