jirim100 Posted January 13 Share Posted January 13 (edited) 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 January 13 by jirim100 Quote Link to comment
Griga Posted January 13 Share Posted January 13 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... Quote Link to comment
jirim100 Posted January 13 Author Share Posted January 13 Transport stream protocol is very complicated. At least for me. Quote Link to comment
Griga Posted January 13 Share Posted January 13 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. Quote Link to comment
Griga Posted January 14 Share Posted January 14 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! Quote Link to comment
jirim100 Posted January 14 Author Share Posted January 14 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. Quote Link to comment
Griga Posted January 16 Share Posted January 16 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. Quote Link to comment
jirim100 Posted January 17 Author Share Posted January 17 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) Quote Link to comment
jirim100 Posted January 29 Author Share Posted January 29 On 1/14/2021 at 6:35 AM, 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. ... Exist similar fast decoder for H264 which can be used, for example, in MPC-HC player (or in video editing software VideoRedo V5)? Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.