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

[jcdr428]

For M2TS, the packet is 192 bytes = 4 bytes extra-header then 188 bytes.
For each packet, DVB Inspector shows the 192 bytes from the sync_byte 0x47, therefore it ignores the ATS in the first packet, and shows the ATS from the next packet in the current 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.

[EricBerendsen]

This is fixed in release 1.19

[ValeZAA]

Last Video PES packet is not parsed/displayed.

From https://www.digitalekabeltelevisie.nl/dvb_inspector/bugs.shtml

In M2TS all packets are parsed now too. Does that mean that bug is also fixed?

[EricBerendsen]

Last Video PES packet is not parsed/displayed.

From https://www.digitalekabeltelevisie.nl/dvb_inspector/bugs.shtml

In M2TS all packets are parsed now too. Does that mean that bug is also fixed?

No, these are not related. For M2TS all TS-packets are parsed. For video PES packets the problem is that the length field is set to zero. You don't know a PES video field is finished until a new one is started.

End of file could indicate that video file is finished, but for normal streams end of file might also be cause by end of capture.

[ValeZAA]

So how does that bug look like so I am aware? Does it still happen with M2TS?

[EricBerendsen]

So how does that bug look like so I am aware? Does it still happen with M2TS?

Yes, it still happens with M2TS. You will only notice it when you expect a certain number of video PES packets (frames). Maybe because you used another tool to analyse a short AVCH stream. If it is 50 frames/sec at 10 seconds you expect 500 video PES frames. DVB Inspector will show 499.

It also shows for HLS streaming. HLS can use MPEG TS packets of fixed duration. (6 or 10 seconds)

For the 'normal' use of DVB Inspector, investigating a stream captured from a never ending broadcast, you will not notice it. The capture has to end somewhere, and maybe the last of several PES packets is not shown. But you would not know beforehand how many there will be.