DVB T2 H265 reception

[jirim100 1]

Today I recorded from good quality source with DVB T2 with H265 .ts file. This file can be fine played  in MPC-HC and VLC player (because it is H265 the computer performance have to be very good) and recorded video and audio is without any corruptions (test in TS Doctor and VideoRedo V6).

But log file created by DMS 3.0.1.2 contains many these lines:

...

8:36:02 / 00:00:40 (~ 20,15 MB) PID 2123: ADTS AAC Audio Dual Ch., 44,1 khz, 2470 kbps
8:36:03 / 00:00:41 (~ 21,10 MB) PID 2123: LATM AAC Audio Mono, 48 khz, 64 kbps
8:36:16 / 00:00:53 (~ 29,34 MB) PID 2123: LATM AAC Audio 10.0, 48 khz, 64 kbps
8:36:17 / 00:00:54 (~ 29,94 MB) PID 2123: ADTS AAC Audio 3.0, 88,2 khz, 3167 kbps
8:36:18 / 00:00:55 (~ 30,66 MB) PID 2123: LATM AAC Audio Mono, 48 khz, 63 kbps
...

 

Recorded file you can download from here https://www.uschovna.cz/en/zasilka/GZBLZ46TG25K4ABM-DNH//?set_lang=en

Log file from DMS is attached here.

 

dfgdfgdfg; ; ; ; vysíláno 2021-01-13.log

Edited Wednesday at 08:33 AM by jirim100

[Griga 678]

I can reproduce it here. It's mainly the AAC mono stream with PID 2123 that causes the lines. The recorder format detection doesn't manage to stay in sync with the frame structure, which is

 

frame header - audio data - frame header - audio data....

 

The frame header contains the frame size and audio parameters like samplerate, number of channels etc. By checking the frame size the format detection is able to predict the position of the next header in the stream. However, this calculation seems to fail sometimes for unknown reasons, so the detection process doesn't find a header at the expected position, starts to search for the next header, finds something that could be a header, but may actually be some audio data mistaken for a header, yielding some odd format information that lets the recorder believe that a format change occured, which must be logged.

 

Up to now I have no idea what causes the issue, but I will try to find out...

 

[jirim100 1]

Transport stream protocol is very complicated. At least for me.

[Griga 678]

The transport stream protocol  is not the point of matter in this case, but the LOAS/LATM AAC audio stream, that is embedded in a packetized elementary stream (PES), that is embedded in the transport stream (TS). There are several protocol layers, so it's even more complicated... however, the format detection deals with the already extracted audio stream, so it should be able to read it properly.

 

[Griga 678]

This looks better:
 

Spoiler

 

Czech DVB-T2 13.01.2021

Naming Scheme: %date_%time_%station_%event
Device: TS Stream Device 2
Timer Name: 
Intended End Time: 14.01.2021 21:10:26
Timer Options: Teletext=1, DVB Subtitles=1, All Audio Tracks=1, Adjust PAT/PMT=1, EIT EPG Data=0, Transponder Dump=0

21:11:26 / 00:00:00 (~ 0,00 MB) Start
21:11:26 / 00:00:00 (~ 0,06 MB) PID 2120: LATM AAC Audio Stereo, 48 khz, 128 kbps
21:11:26 / 00:00:00 (~ 0,06 MB) PID 2121: LATM AAC Audio Stereo, 48 khz, 123 kbps
21:11:26 / 00:00:00 (~ 0,06 MB) PID 2122: AC3 Audio Stereo, 48 khz, 448 kbps
21:11:26 / 00:00:00 (~ 0,06 MB) PID 2123: LATM AAC Audio Mono, 48 khz, 61 kbps
21:11:26 / 00:00:00 (~ 0,06 MB) PID 2130: Videotext
21:11:27 / 00:00:01 (~ 0,42 MB) PID 2110: HEVC Video, 16:9, 1920x1080, 50 fps
21:11:30 / 00:00:04 (~ 1,31 MB) PID 2150: DVB Subtitles
21:26:30 / 00:15:04 (~ 559,69 MB) Stop

Average Data Rate: 0,619 MB/s
Total Size: 559,7 MB (586874712 Bytes)
Removed Filler Data: 4,3 MB (1,0%)

data:image/gif;base64,R0lGODlhAQABAPABAP///wAAACH5BAEKAAAALAAAAAABAAEAAAICRAEAOw==

 

 

 

 

The AAC audio frames are not aligned with the PES data packets, which means, they contain fragmented frames at the beginning and end. This is a bit unusual, but correctly indicated in the PES headers and allowed by the specifications, so the format detection should be able to handle it. But it fails every time when a frame header is cut by a packet boundary (part of the frame header in packet n and the other part in packet n+1). This causes the additional lines in the log. I'm still thinking about the optimal way to fix it...

 

BTW: If you need to decode HEVC by CPU, because your graphics card/chip is not able to do it by hardware, you may want to try the Lentoid/Strongene HEVC decoder. It's Chinese software, which means, your PC will be taken over by the Chinese secret service , but on the other hand you get a very fast HEVC software decoder - much faster than LAV 32 Bit without hardware acceleration. You can use 7-Zip to unpack the TAR archive to some place in Program Files (x86), e.g. the DVBViewer\Filters folder. If you want to  avoid using reg.bat, that registers some stuff in your system that DVBViewer doesn't need, you can use the Radlight Filter Manager to just register hevcdecfltr.dll in your system. It plays your sample pretty well. Please note that registering and unregistering filters requires admin rights!

 

[jirim100 1]

Yes, it's look much better.

 

1 hour ago, Griga said:

BTW: If you need to decode HEVC by CPU, because your graphics card/chip is not able to do it by hardware, you may want to try the Lentoid/Strongene HEVC decoder. It's Chinese software, which means, your PC will be taken over by the Chinese secret service

I bought the new fast PC (probably has hw acceleration in Intel graphics chip), but maybe I try it in my old PC.

Thanks.

[Griga 678]

A new Media Server hotfix version is up. Please note that the audio format detection of the recorder may still go wrong on first attempt, but should get it right afterwards and stay in sync, provided there are no drop-outs in the stream.

 

[jirim100 1]

I tried it and it seems much better

 

Spoiler

CT 1 HD T2 17.01.2021
W:\For The Record\drdfgfdgdfg; ; ; ; vysíláno 2021-01-17.ts
Naming Scheme: %name; ; ; ; vysíláno %year-%m-%d
Device: AVerMedia TD310 BDA Filter (2)
EventID: 48897
Timer Name: drdfgfdgdfg
Timer Start: 17.01.2021 19:29:00
Timer Duration: 00:30:00 (30 min.)
Timer Options: Teletext=1, DVB Subtitles=1, All Audio Tracks=1, Adjust PAT/PMT=1, EIT EPG Data=1, Transponder Dump=0
Timer Source: Web

19:29:54 / 00:00:00 (~ 0,00 MB) Start Recording
19:29:54 / 00:00:00 (~ 0,00 MB) Události running | EventID: 48897 PDC: 0x88CC0
19:29:55 / 00:00:01 (~ 0,21 MB) PID 2120: LATM AAC Audio Stereo, 48 khz, 150 kbps
19:29:55 / 00:00:01 (~ 0,21 MB) PID 2121: LATM AAC Audio Stereo, 48 khz, 157 kbps
19:29:55 / 00:00:01 (~ 0,21 MB) PID 2122: AC3 Audio Stereo, 48 khz, 448 kbps
19:29:55 / 00:00:01 (~ 0,21 MB) PID 2130: Videotext
19:29:55 / 00:00:01 (~ 0,21 MB) Branky, body, vteřiny not running | EventID: 48933 PDC: 0x88CF4
19:29:55 / 00:00:01 (~ 0,21 MB) EventID change 48897 to 48933
19:29:56 / 00:00:02 (~ 0,92 MB) PID 2110: HEVC Video, 16:9, 1920x1080, 50 fps
19:29:56 / 00:00:02 (~ 0,92 MB) PID 2123: LATM AAC Audio Mono, 48 khz, 63 kbps
19:29:56 / 00:00:02 (~ 0,92 MB) PID 2150: DVB Subtitles
19:36:07 / 00:06:13 (~ 196,55 MB) Stop

Average Data Rate: 0,527 MB/s
Total Size: 196,5 MB (206093120 Bytes)