For M2TS, each packet shows the arrival time stamp from the next packet

[ericberendsen]

For M2TS, each packet shows the arrival time stamp from the next packet

[EricBerendsen]

Hi,

Thank you, yes, I know this is a limitation/bug in DVB Inspector. It is also on https://www.digitalekabeltelevisie.nl/dvb_inspector/bugs.shtml

I think it will be difficult to implement auto detection where "extra" bytes belong. Most of the time it is at the end of a packet, but is it always at the start for a 192 byte packet size?

Or maybe I should ad an option to force 192 byte M2TS packets, just like you can now force other packet sizes.

Will put it on my TODO list.

[jan-adam]

I discovered this bug today.

I noticed a strange shift of timestamps (4 extra bytes) by one packet for the mts file. Additionally, DVB Inspector displayed one sync error and the last packet was missing. I tested other files - always the same results.

I wanted to report this bug, and here it is! A known and, unfortunately, very serious bug.

This is a serious bug because the specification clearly states that the additional 4 bytes are at the BEGINNING of the BDAV MPEG-2 Transport Stream packet. I don't know if there is any other variant of transport stream with additional bytes at the end of the 192-byte packet.

You can check it, for example, on Wikipedia. Wikipedia also gives a link to the specification:

https://web.archive.org/web/20201103093732/http://www.blu-raydisc.com/Assets/Downloadablefile/2b_bdrom_audiovisualapplication_0305-12955-15269.pdf

On page 14 you can read about BDAV MPEG-2 Transport Stream:

The length of a source packet is 192 bytes. One source packet consists of one TP_extra_header structure and one MPEG2 transport packet structure. The length of the TP_extra_header structure is 4 bytes and the length of the transport packet structure is 188 bytes.

In the diagram, TP_extra_header comes before the 188-byte packet.

This bug needs to be fixed. I suggest adding the "192 (BDAV, extra bytes first)" variant to the "Packet Size" menu and modifying the algorithm to correctly detect whether additional bytes are at the beginning or end of the packet.

[ValeZAA]

This is a cosmetic issue, just on EOF read the packet without a timestamp and write that the timetstamp is for next packet. For the first packet it will be a problem though.