Project

General

Profile

Bug #4507

kodi - tsfix: transport stream H264, DTS discontinuity

Added by Anonymous over 7 years ago. Updated about 4 years ago.

Status:
Fixed
Priority:
Normal
Assignee:
-
Category:
IPTV
Target version:
-
Start date:
2017-07-30
Due date:
% Done:

100%

Estimated time:
Found in version:
4.3
Affected Versions:

Description

Hello,

I am using an irish service for IPTV called ibox.ie and a french one called camembert.tv.

French channels work ok - irish channel, via kodi:
  • no sound in 4.2
  • a lot of buffering after a few seconds of playing in 4.3.

Version of 4.3-308~g063765eaa~zesty from https://launchpad.net/~mamarley/+archive/ubuntu/tvheadend-git

The logs are:
2017-07-30 20:16:22.102 mpegts: list.m3u8 - E 4 in IBox - tuning on IPTV
2017-07-30 20:16:22.104 subscription: 001C: "127.0.0.1 [ blablack | Kodi Media Center ]" subscribing on channel "E4", weight: 150, adapter: "IPTV", network: "IBox", mux: "list.m3u8 - E 4", service: "E 4", profile="htsp", hostname="127.0.0.1", username="blablack", client="Kodi Media Center"
2017-07-30 20:16:22.875 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (385199)
2017-07-30 20:16:24.909 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (484166)
2017-07-30 20:16:27.501 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (424755)
2017-07-30 20:16:29.706 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (417561)
2017-07-30 20:16:31.708 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (415776)
2017-07-30 20:16:33.712 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (385139)
2017-07-30 20:16:35.712 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (408588)
2017-07-30 20:16:37.716 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (417577)
2017-07-30 20:16:40.018 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (345549)
2017-07-30 20:16:47.030 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (340176)
2017-07-30 20:16:51.238 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (336581)
2017-07-30 20:16:53.232 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (359990)
2017-07-30 20:16:55.232 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (385136)
2017-07-30 20:16:57.239 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (401345)
2017-07-30 20:16:58.411 tsfix: transport stream H264, DTS discontinuity. DTS = 1888000, last = 1232800
2017-07-30 20:16:59.436 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (350951)
2017-07-30 20:17:05.450 parser: IBox/list.m3u8 - E 4/E 4: H264 #481: DTS and PCR diff is very big (338391)
2017-07-30 20:17:14.755 parser: IBox/list.m3u8 - E 4/E 4: H264 @ #481: DTS and PCR diff is very big (338280)
2017-07-30 20:17:15.878 subscription: 001C: "127.0.0.1 [ blablack | Kodi Media Center ]" unsubscribing from "E4", hostname="127.0.0.1", username="blablack", client="Kodi Media Center"

Codec information via avprobe:
Input #0, mpegts, from 'http://192.168.2.4:9981/stream/mux/8ce32012fee9341262dcabe8e93ba8d9?ticket=EEA9A1601F927AB9911A2AB0801CC4991D8E148E':
Duration: N/A, start: 71884.234667, bitrate: N/A
Program 1
Stream #0:0[0x1e1]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0x1e2](eng): Audio: aac (HE-AACv2) ([15][0][0][0] / 0x000F), 48000 Hz, stereo, fltp, 64 kb/s

For information, this is the avprobe output from a working stream from camembert.tv:
Input #0, mpegts, from 'http://192.168.2.4:9981/stream/mux/c8585083f4ee9de7e293caecf53af194?ticket=4E0D700B92EEAB4700EAD2E19DB2CAFE50646794':
Duration: N/A, start: 18120.788056, bitrate: N/A
Program 1
Stream #0:0[0xd3]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 25 fps, 25 tbr, 90k tbn, 50 tbc
Stream #0:1[0xdd]: Audio: aac (HE-AAC) ([15][0][0][0] / 0x000F), 44100 Hz, stereo, fltp, 61 kb/s

If there is any other information you need, please let me know.

Thanks,
Aurélien

Files

logs.txt (550 KB) logs.txt Logs with '--trace pcr,parser' Anonymous, 2017-08-01 12:03

History

#1

Updated by Anonymous over 7 years ago

Hello,

Reviewing a previous similar bug, the dev at the time asked for a log from '--trace pcr,parser'.
Hoping this helps I attached a similar log here.

Regards,
Aurélien

#2

Updated by Anonymous over 7 years ago

I kept investigating the issue (have a few people relying on TV at home :))

I figured the way TVHeadEnd considers what is a too big a difference between the DTS and PCR was a bit too extreme.
Commented out all that part in parsers.c to see how it would do and....streaming is now working perfectly.

I can see in commit b66f57c6fccb5dd79af88c9328d1202965663262 that it was increased once before.
Could it simply need to be more "relaxed" again?

Hope this helps (probably not but you never know!)

#3

Updated by Mark Clarkstone over 7 years ago

Aurelien Leblond wrote:

I kept investigating the issue (have a few people relying on TV at home :))

I figured the way TVHeadEnd considers what is a too big a difference between the DTS and PCR was a bit too extreme.
Commented out all that part in parsers.c to see how it would do and....streaming is now working perfectly.

I can see in commit b66f57c6fccb5dd79af88c9328d1202965663262 that it was increased once before.
Could it simply need to be more "relaxed" again?

Create a PR on github! :)

Hope this helps (probably not but you never know!)

#4

Updated by Jaroslav Kysela over 7 years ago

About "extreme" word. Note that diff 338280 (90000Hz value) means approx. 3.75 seconds of difference. The standard specifies that PCR and DTS should not drift more than 1 second and PCR should be transmitted at most of 100ms intervals. Unfortunately, most of IPTV streams does not follow the broadcasting standards. There are two major points why I added PCR code to TVH:

1) check for invalid decoded data
2) in future, PCR will be used for timeshift

From logs, it appears that video stream is too much behind the audio stream and the interleaving of A/V streams is not perfect. I need to think more about this.

#5

Updated by Anonymous over 7 years ago

Hi,

The problem I have noticed with that stream (in TVHeadEnd with my changes and in VLC) is that the sound appears first, only a few second later the picture appears.
If I try to read a recording, the same few seconds the pictures is completely scrambled and if I check the codec additional info in Kodi it complains of crazy desynced audio/video for the first few seconds before resyncing.

So you are right, the a/v in the stream is completely desynced, but only for the first few seconds - after that reading is fine. Maybe the PCR is transmitted at much longer interval which would create this issue until tvheadend receives the first one?
Is it possible that then tvheadend just never manages to resync properly with the original code?

In any case, I am available if you want any additional information or for any additional testing.

#6

Updated by N Z over 7 years ago

I have the same issue, tvheadend doesn't seem to be able to re-sync.
version: 4.3-269~gd9645d63c

2017-08-05 19:48:28.555 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256 Continuity counter error (total 1)
2017-08-05 19:48:28.726 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257 Continuity counter error (total 1)
2017-08-05 19:48:28.846 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257: DTS and PCR diff is very big (336600)
2017-08-05 19:48:28.847 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256: DTS and PCR diff is very big (340200)
2017-08-05 19:48:28.903 TS: IPTV/iptv.m3u - CHAN3/11537: AAC-LATM @ #258 Continuity counter error (total 1)
2017-08-05 19:48:28.917 tsfix: transport stream H264, DTS discontinuity. DTS = 2563200, last = 2275200
2017-08-05 19:48:28.959 tsfix: transport stream H264, DTS discontinuity. DTS = 2563200, last = 2271600
2017-08-05 19:49:06.671 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257 Continuity counter error (total 2)
2017-08-05 19:49:06.671 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256 Continuity counter error (total 2)
2017-08-05 19:49:06.671 TS: IPTV/iptv.m3u - CHAN3/11537: AAC-LATM @ #258 Continuity counter error (total 2)
2017-08-05 19:49:06.672 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256: DTS and PCR diff is very big (336600)
2017-08-05 19:49:06.682 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257: DTS and PCR diff is very big (336600)
2017-08-05 19:49:06.760 tsfix: transport stream H264, DTS discontinuity. DTS = 5392800, last = 5108400
2017-08-05 19:49:06.760 tsfix: transport stream H264, DTS discontinuity. DTS = 5392800, last = 5108400
2017-08-05 19:49:14.634 tsfix: transport stream H264, DTS discontinuity. DTS = 6141600, last = 5875200
2017-08-05 19:49:14.678 tsfix: transport stream H264, DTS discontinuity. DTS = 6141600, last = 5871600
2017-08-05 19:49:17.823 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256 Continuity counter error (total 4)
2017-08-05 19:49:17.824 tsfix: transport stream H264, DTS discontinuity. DTS = 6663600, last = 6397200
2017-08-05 19:49:17.911 tsfix: transport stream H264, DTS discontinuity. DTS = 6663600, last = 6397200
2017-08-05 19:49:17.913 TS: IPTV/iptv.m3u - CHAN3/11537: AAC-LATM @ #258 Continuity counter error (total 4)
2017-08-05 19:49:17.913 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256: DTS and PCR diff is very big (333000)
2017-08-05 19:49:17.913 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257: DTS and PCR diff is very big (333000)
2017-08-05 19:49:21.358 TS: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257 Continuity counter error (total 4)
2017-08-05 19:49:21.434 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #257: DTS and PCR diff is very big (351000)
2017-08-05 19:49:21.435 parser: IPTV/iptv.m3u - CHAN3/11537: H264 @ #256: DTS and PCR diff is very big (354600)
2017-08-05 19:49:21.451 tsfix: transport stream H264, DTS discontinuity. DTS = 7221600, last = 6919200
2017-08-05 19:49:21.539 tsfix: transport stream H264, DTS discontinuity. DTS = 7221600, last = 6915600
#7

Updated by Jaroslav Kysela about 7 years ago

  • Status changed from New to Fixed
  • % Done changed from 0 to 100

Applied in changeset commit:tvheadend|8a43edd48e00a724eba76b37418ee18840dbe60e.

#8

Updated by Francisco Perea about 4 years ago

Hi,

Is there a way to bypass the PCR - DTS timestamp verification? I am trying to run this PR https://github.com/tvheadend/tvheadend/pull/1347 which offers among other things remote timeshifting. In this case, forward, backward, or skip actions are performed on server side instead of local file timeshifting. Therefore, it is obvious that there will be a difference between the PCR and DTS times when a timeshift command is sent to the server. The PCR local register will show a value, but transmission will start at a different point than the next PCR timestamp.
RTSP commands to rewind, forward or skip the stream work very well (checked with Wireshark) and the server receives the start points, speed change or skip well and starts the stream at requested point but TVH always detects those changes as errors and shows in debugging:
H264 #101 Continuity counter error (total 1) and
AC3 #102 Continuity counter error (total 1) and then
[ ERROR] tsfix: transport stream H264, DTS discontinuity. DTS = 1102665, last = 1114677
When tsfix try to fix the difference, the stream hangs until until PCR and clock are equal (if I try to skip -5 seconds, the sequence will freeze 5 seconds until the sequence returns to 0:00).
So, how could parser and tsfix be "disabled" to avoid those checks on remote-server-timeshift commands?

Also available in: Atom PDF