Encoding issues after edit SCTE-35 message Break_Duration
Closed this issue · 7 comments
Hello,
First of all, thanks for the tool.
I'm trying to edit a break duration. The example I have is the one from the spec which is the one in your examples but I cannot reproduce the results in that example.
Example reference: https://github.com/futzu/SCTE35_threefive/blob/master/examples/encode/edit_break_duration.py
Note 1: For some reason, using base64 format returns "false" when I try to decode so all I did was using HEX format.
Using Mint. Python3. PIP Fresh installed. threefive fresh installed.
What I do:
$python3
Python 3.10.12 (main, Mar 22 2024, 16:50:05) [GCC 11.4.0] on linux
Type "help", "copyright", "credits" or "license" for more information.>>> import threefive
>>> eds="FC302F000000000000FFFFF014054800008F7FEFFE7369C02EFE0052CCF500000000000A0008435545490000013562DBA30A"
>>> threefive.decode(eds)
{
"info_section": {
"table_id": "0xfc",
"section_syntax_indicator": false,
"private": false,
"sap_type": "0x03",
"sap_details": "No Sap Type",
"section_length": 47,
"protocol_version": 0,
"encrypted_packet": false,
"encryption_algorithm": 0,
"pts_adjustment_ticks": 0,
"pts_adjustment": 0.0,
"cw_index": "0xff",
"tier": "0x0fff",
"splice_command_length": 20,
"splice_command_type": 5,
"descriptor_loop_length": 10,
"crc": "0x62dba30a"
},
"command": {
"command_length": 20,
"command_type": 5,
"name": "Splice Insert",
"time_specified_flag": true,
"pts_time": 21514.559089,
"pts_time_ticks": 1936310318,
"break_auto_return": true,
"break_duration": 60.293567,
"break_duration_ticks": 5426421,
"splice_event_id": 1207959695,
"splice_event_cancel_indicator": false,
"out_of_network_indicator": true,
"program_splice_flag": true,
"duration_flag": true,
"splice_immediate_flag": false,
"event_id_compliance_flag": true,
"unique_program_id": 0,
"avail_num": 0,
"avail_expected": 0
},
"descriptors": [
{
"tag": 0,
"descriptor_length": 8,
"name": "Avail Descriptor",
"identifier": "CUEI",
"provider_avail_id": 309
}
]
}
True
>>> cue = threefive.Cue(eds)
>>> cue.decode()
TrueThe step above returns "false" if I use the base64 SCTE-35 message for some reason. Same result in two different systems.
>>> cue.command.break_duration
60.293567
>>> cue.command.break_duration=90.00
>>> cue.show()
{
"info_section": {
"table_id": "0xfc",
"section_syntax_indicator": false,
"private": false,
"sap_type": "0x03",
"sap_details": "No Sap Type",
"section_length": 47,
"protocol_version": 0,
"encrypted_packet": false,
"encryption_algorithm": 0,
"pts_adjustment_ticks": 0,
"pts_adjustment": 0.0,
"cw_index": "0xff",
"tier": "0x0fff",
"splice_command_length": 20,
"splice_command_type": 5,
"descriptor_loop_length": 10,
"crc": "0x62dba30a"
},
"command": {
"command_length": 20,
"command_type": 5,
"name": "Splice Insert",
"time_specified_flag": true,
"pts_time": 21514.559089,
"pts_time_ticks": 1936310318,
"break_auto_return": true,
"break_duration": 90.0,
"break_duration_ticks": 5426421,
"splice_event_id": 1207959695,
"splice_event_cancel_indicator": false,
"out_of_network_indicator": true,
"program_splice_flag": true,
"duration_flag": true,
"splice_immediate_flag": false,
"event_id_compliance_flag": true,
"unique_program_id": 0,
"avail_num": 0,
"avail_expected": 0
},
"descriptors": [
{
"tag": 0,
"descriptor_length": 8,
"name": "Avail Descriptor",
"identifier": "CUEI",
"provider_avail_id": 309
}
]
}
>>> cue.encode_as_hex()
'0xfc302f000000000000fffff014054800008f7feffe7369c02efe0052ccf500000000000a0008435545490000013562dba30a'
>>>Note that the output is the same as original input:
0xFC302F000000000000FFFFF014054800008F7FEFFE7369C02EFE0052CCF500000000000A0008435545490000013562DBA30A
0xfc302f000000000000fffff014054800008f7feffe7369c02efe0052ccf500000000000a0008435545490000013562dba30a
I did a different test using the same SCTE-35 message but instead of editing the break duration I have deleted the descriptors. In that case it worked. I mean, the output is a new HEX SCTE-35 that once decoded has the descriptor removed.
Am I doing something wrong?
Thanks
Great explanation of the issue, thank you for that , let me take a look at it and I'll get back to you.
I see what's happening. When I did that example I was not using ticks and everybody yelled at me for it.
So what it does is read the break_duration_ticks, before the break_duration,
because If I have both, how do I know which one to read?
The easiest way is just to set break_duration_ticks to None, when you set break_duration to 90.0.
so you know, there are 90,000 ticks in a second.
Or you can just set cue.command.break_duration_ticks=90.0*90000
a@fu:~$ pypy3
Python 3.9.16 (7.3.11+dfsg-2+deb12u2, May 20 2024, 22:08:06)
[PyPy 7.3.11 with GCC 12.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>>> from threefive import Cue
>>>> cue = Cue("FC302F000000000000FFFFF014054800008F7FEFFE7369C02EFE0052CCF500000000000A0008435545490000013562DBA30A")
>>>> cue.decode()
True
>>>> cue.command.break_duration
60.293567
>>>> cue.command.break_duration_ticks=None
>>>> cue.command.break_duration=90.0
>>>> cue.encode_as_hex()
'0xfc302f000000000000fffff014054800008f7feffe7369c02efe007b98a000000000000a0008435545490000013550767c9b'
>>>> cue.command.break_duration
90.0
>>>>
>>>> cue.encode()
'/DAvAAAAAAAA///wFAVIAACPf+/+c2nALv4Ae5igAAAAAAAKAAhDVUVJAAABNVB2fJs='
>>>> cue.encode_as_int()
2543800754001302697244199520382553557495786694061752983105500878892174355897298371112187679823451743975006196999690550427
# use the output in a new Cue
>>>> cue2=Cue(cue.encode_as_hex())
>>>> cue2.decode()
True
>>>> cue2.command.break_duration
90.0
I do really need to come up with a better way to handle that. I am open to suggestions.
Everything is supposed to be in ticks, but my brain can't work with such big numbers, so I do them in seconds.
cue has a method as ticks so you can do it like this
cue.command.break_duration_ticks= cue.as_ticks(90.0)As I heard myself explaining this to you, I realized that this is a horrible way for me to do things and super confusing.
I'm about to drop using ticks all together, I hate them. If someone needs ticks they can multiply by 90,000. It make take me a few days, there are other ticks besides break_duration. You have inspired me.
Thanks My Friend.
I could just read you responses today. After post the issue, I gave one more try by exporting the cmd session to a variable, editing what i needed, in this case the break and them import back. At that point, I got the tool complaining about duration in ticks. So I have calculated and filled and it worked.
I'll keep in mind the options you have indicated above.
As suggestion, you could select to use either one user supplies, giving priority to ticks. In my case, it's just a basic testing duration in seconds is fine and human readable. If precision is required, user can supply ticks. If some maniac supplies both, take ticks. ...or just keep it as it is stating that ticks is required in some documentation
Finally, thanks for the fast response and great/unique tool.
You don't understand how it works, both were always present, but don't worry about it, I got rid of ticks, I've been to do that anyway. Update to 2.4.61.
python3 -mpip install --upgrade threefiveNow it will work like you expected.
>>> from threefive import Cue
>>> eds="FC302F000000000000FFFFF014054800008F7FEFFE7369C02EFE0052CCF500000000000A0008435545490000013562DBA30A"
>>> cue = Cue(eds)
>>> cue.decode()
True
>>> cue.command.break_duration
60.293567
>>> cue.command.break_duration=90.0
>>> cue.encode()
'/DAvAAAAAAAA///wFAVIAACPf+/+c2nALv4Ae5igAAAAAAAKAAhDVUVJAAABNVB2fJs='
>>> cuetoo = Cue(cue.encode())
>>> cuetoo.decode()
True
>>> cuetoo.command.break_duration
90.0
>>> you cool?