Splicing point calculation

[anshul-tiwari]

I'm receiving a stream and storing it in the .ts files. However, when I receive the SCTE 35 cue tone information for splice insert - local avail, I calculate the splicing point. The calculated splicing point does not always align with the actual time when the local insertion has taken place. Sometimes, the splicing point falls a few seconds after the local insertion start time, and sometimes it falls before.

The calculation I use is as follows: start_time of the .ts file where I received the SCTE 35 splice insert command + pts_time + pts_adjustment.

I'm seeking assistance to address this issue and ensure that the calculated splicing point aligns accurately with the actual time of the local insertion.

Kindly let me know if you need any extra details on this.

[futzu]

I know what you're talking about, it's a common problem, I spent most of the two months addressing the same thing for a client. The thing to fix is whatever is inserting the SCTE-35, , there is no easy way to address it after the fact.
If you can discern a pattern, the SCTE-35 spec suggests re-encoding the SCTE-35 and use the pts adjustment to make it accurate. To be clear , threefive DOES NOT add in the pts_adjustment, I did for a while, but everybody got upset about it.

   "info_section": {
        "table_id": "0xfc",
        "section_syntax_indicator": false,
        "private": false,
        "sap_type": "0x3",
        "sap_details": "No Sap Type",
        "section_length": 42,
        "protocol_version": 0,
        "encrypted_packet": false,
        "encryption_algorithm": 0,
        "pts_adjustment_ticks": 0,
        "pts_adjustment": 0.0,                 <------- pts adjustment
        "cw_index": "0xff",
        "tier": "0xfff",
        "splice_command_length": 15,
        "splice_command_type": 5,
        "descriptor_loop_length": 10,
        "crc": "0xd497da82"
    },
    "command": {
        "command_length": 15,
        "command_type": 5,
        "name": "Splice Insert",
        "time_specified_flag": true,
        "pts_time": 22960.350067, <----  this + pts_adjustment is the Splice Point. 
        "pts_time_ticks": 2066431506, 
        "splice_event_id": 24,
        "splice_event_cancel_indicator": false,
        "out_of_network_indicator": false,
        "program_splice_flag": true,
        "duration_flag": false,
        "splice_immediate_flag": false,
        "unique_program_id": 1,
        "avail_num": 8,
        "avail_expected": 255
    },
    "descriptors": [
        {
            "tag": 0,
            "descriptor_length": 8,
            "name": "Avail Descriptor",
            "identifier": "CUEI",
            "provider_avail_id": 8
        }
    ],
    "packet_data": {
        "pid": "0x415",
        "program": 1040,
        "pts_ticks": 2065851904,
        "pts": 22953.910044    <----  when the SCTE-35 Cue is received ,usually 4 seconds before the splice.
    }

[futzu]

This is what I use to help me locate where things should be, all black frame detection.
Often Splice points are delimited by all black frames.

allblack.sh

#!/bin/sh

ffmpeg -copyts -i  $1 -vf blackdetect=d=0:pix_th=.01 -f mpegts   -y /dev/null  2>&1 | grep -3 'black'

• chmod it

chmod +x allblack.sh

• run it

./allblack.sh video.ts

[anshul-tiwari]

I can't rely solely on black frames. There are instances of black frames even when there is no advertisement present. I have tested the script 'allblack.sh' on a few streams, and while it can be used in the pipeline to enhance the accuracy as a double-check, it should not be the sole determining factor.

[futzu]

There are instances of black frames even when there is no advertisement present

Why would that matter?

All black frames not only used ad breaks , they are also used at scene cuts and such.

You aren't verifying all black frames, you should be using all black frames to verify SCTE-35.

When you see a SCTE-35 cue,
look and see if it lines up with some all black frames,
that's how you verify it.

• From a real CNN stream with SCTE-35

    "info_section": {
        "table_id": "0xfc",
        "section_syntax_indicator": false,
        "private": false,
        "sap_type": "0x3",
        "sap_details": "No Sap Type",
        "section_length": 52,
        "protocol_version": 0,
        "encrypted_packet": false,
        "encryption_algorithm": 0,
        "pts_adjustment_ticks": 7755790832,
        "pts_adjustment": 86175.453689,      <----------------------   pts_adjustment
        "cw_index": "0x0",
        "tier": "0x0",
        "splice_command_length": 5,
        "splice_command_type": 6,
        "descriptor_loop_length": 30,
        "crc": "0x74d6479b"
    },
    "command": {
        "command_length": 5,
        "command_type": 6,
        "name": "Time Signal",
        "time_specified_flag": true,
        "pts_time": 12226.2196,   <----------------------  pts_time
        "pts_time_ticks": 1100359764
    },

• pts_adjustment + pts+time % rollover

(86175.453689 + 12226.2196) % 95443.717678 = 2957.955611

• Meanwhile, all black frames is running in another window

a@debian:~/tunein$ sh ~/allblack.sh cnn.ts
black_end:2114.68 black_duration:0.0667333
black_end:2372.03 black_duration:1.2012
black_end:2597.33 black_duration:0.0667333
black_end:2957.85 black_duration:0.166833  <--------- The only one that matters

• SCTE-35 Splice Point @ 2957.955611
• Black Frames @ 2957.85

Verified.

[futzu]

How did it go? check out https://github.com/futzu/scte35-threefive/blob/master/examples/stream/cue2vtt.py,
if you do something like

 pypy3 cue2vtt.py video.ts | mplayer video.ts -sub -

you get subtitles in the video like

and they stay for the duration of the break, I just updated it because I'm using it myself right now.

[anshul-tiwari]

I came across tsduck, which seems promising, but it is not working with the transport stream files I have. It could be because the files have been modified in some way. I have temporarily switched to other tasks, but I will revisit this soon and see if I can make use of tsduck.

[futzu]

tsduck is amazing, but I dont know of anything it can do in this situation, but I may be wrong.
Just out of curiosity, how far are the splice points off and are they all off by a similar amount?
You need to send me a chunk of the video with one of the off SCTE-35 cues,
I am wondering if I am misunderstanding something you're telling me.

[anshul-tiwari]

FYI, The discussion I went through on tsduck: tsduck/tsduck#20

[futzu]

Dude, I'm not reading all that, what is your point?
Do you have a better to align them?
My answers haven't changed.

[futzu]

check this out 👍🏻

two files

• showtime.py

#!/usr/bin/env python3


import sys
from threefive import Stream,print2

def  show_time(cue):
    if "pts_time" in cue.command.get():
        print2(f"cue: {(cue.command.pts_time+cue.info_section.pts_adjustment) % 95443.717678}")

strm =Stream(sys.argv[1])

strm.proxy(func=show_time)

• blackcues.sh

#!/bin/sh

./showtime.py $1 | ffmpeg -copyts -i - -vf blackdetect=d=0:pix_th=.01 -f mpegts   -y /dev/null  2>&1 | grep -oE  'black_end:.+? '

• chmod them

chmod  +x showtime.py
chmod +x blackcues.sh

• run

a@debian:~$ ./blackcues.sh tunein/cnn.ts
black_end:2114.68         # <----  non-relevant black frames
cue: 2372.070311000003       
black_end:2372.03           #< ----- look for black_end immediately following a cue
cue: 2597.295311000009
black_end:2597.33 
cue: 2957.9556109999976
black_end:2957.85 
a@debian:~$ 

[futzu]

If you come up with a better to do it, let me know.