HLS - EXT-X-DATERANGE Compliance - ios

HTTP Live Streaming, draft-pantos-http-live-streaming-23 (Version 23) defines EXT-X-DATERANGE tag. Which has multiple attributes also defined by the specification: ID, START-DATE, etc.
Among defined attributes are SCTE35-OUT, SCTE35-IN. The specification mentions the following about them:
Used to carry SCTE-35 data; see Section 4.3.2.7.1 for more information. These attributes are OPTIONAL.
... value is the big-endian binary representation of the splice_info_section(), expressed as a hexadecimal-sequence.
However, the specification does not define how critical the value of this attributes is.
For example in the documentation of AWS Elemental the values for SCTE35-OUT and SCTE35-IN are identical:
#EXT-X-DATERANGE:ID="999",START-DATE="2018-08-22T21:54:00.079Z",PLANNED-DURATION=30.000,
SCTE35-OUT=0xFC302500000000000000FFF01405000003E77FEFFE0011FB9EFE002932E00001010100004D192A59
.
.
.
#EXT-X-DATERANGE:ID="999",END-DATE="2018-08-22T21:54:30.109Z",DURATION=30.030,
SCTE35-IN=0xFC302500000000000000FFF01405000003E77FEFFE0011FB9EFE002932E00001010100004D192A59
Although HLS specification states:
For splice_insert
The "in" splice_info_section() (with out_of_network_indicator set to 0) MUST be placed in a SCTE35-IN attribute, with the same formatting as SCTE35-CMD.
For time_signal
The "out" splice_info_section() MUST be placed in a SCTE35-OUT attribute; the "in" splice_info_section() MUST be placed in a SCTE35-IN attribute.
Hence, I would expect that the value of these attributes should be always different. Am I missing something? Or this values are completely irrelevant to the clients?
Note: the hex string can be parsed and compared by using: https://openidconnectweb.azurewebsites.net/Cue

The same hex is used twice because break auto return is true,
and the break duration is specified.
"command": {
"command_length": 20,
"command_type": 5,
"name": "Splice Insert",
"time_specified_flag": true,
"pts_time": 13.094733, # The CUE-OUT is at this time
"pts_time_ticks": 1178526,
"break_auto_return": true, # Automatically return from the break
"break_duration": 30.0, # The CUE-IN is 30 seconds later.
"break_duration_ticks": 2700000,
"splice_event_id": 999,
"splice_event_cancel_indicator": false,
"out_of_network_indicator": true,
"program_splice_flag": true,
"duration_flag": true,
"splice_immediate_flag": false,
"unique_program_id": 1,
"avail_num": 1,
"avail_expected": 1
},
"descriptors": []
}
Check out threefive

Related

Exclude empty fields from Log4J2 JsonTemplateLayout output

The log4j2 PatternLayout offers a %notEmpty conversion pattern that allows you to skip sections of the pattern that refer to empty variables.
Is there any way to do something similar for JsonTemplateLayout, specifically for thread context data (MDC)? It correctly (IMO) suppresses null fields, but it doesn't do the same with empty ones.
E.g., given the following in my JSON template:
"application": {
"name": { "key": "x-app", "$resolver": "mdc" },
"context": { "key": "x-app-context", "$resolver": "mdc" },
"instance": {
"name": { "key": "x-appinst", "$resolver": "mdc" },
"context": { "key": "x-appinst-context", "$resolver": "mdc" }
}
}
is there a way to prevent blocks like this from being logged, where the only data in the subtree is the empty string values for context?
"application":{"context":"","instance":{"context":""}}
(Yes, ideally I'd prevent those empty strings being put into the context in the first place, but this isn't my app, I'm just configuring it.)
JsonTemplateLayout author speaking here. Currently, JsonTemplateLayout doesn't support blank property exclusion for the following reasons:
The definition of empty/blank is ambiguous. One might have, null, {}, "\s*", [], [[]], [{}], etc. as valid JSON values. Which one of these are empty/blank? Let's assume we have agreed on a certain behavior. Will it apply to the rest of its users?
Checking if a value is empty/blank incurs an extra runtime cost.
Most of the time you don't care. You persist logs in a storage system, e.g., ELK stack, and there blank value elimination is provided out of the box by the storage engine in the most efficient way.
Would you mind sharing your use case, please? Why do you want to prevent the emission of "context": "" properties? If you deliver your logs to Elasticsearch, there you can easily exclude such fields via appropriate index mappings.
Near as I can tell, no. I would suggest you create a Jira issue to get that addressed.

Swagger Code generation with minItems and maxLength for items

I would like to post an array of strings with min items of 2 and max length of 50 for the strings inside the array.
I set up my swagger like so :
"values":{
"desciption":"values of file",
"type":"array",
"items":{
"type":"string",
"maxLength": 50
},
"minItems": 2
}
but for some reason in the codegen it only takes the minItems without taking into consideration the maxLength I can type 50+ characters and it passes
I find your definition within yml is correct, and even code is not generated correctly. So, I will advise raising a separate bug for this will help other users as well.
Even there are some of the bugs that are not working for example minItems: and maxItems: for the same list doesn't restrict or code is not generating is not automatically for this behavior. #Size(min=2,max=4) i.e.
values:
description: values of file
type: array
items:
type: string
maxLength: 20
minItems: 2
maxItems: 4
So I will suggest you raise a separate bug through the given link:
https://github.com/OpenAPITools/openapi-generator/issues/new?assignees=&labels=Issue%3A+Bug&template=bug_report.md&title=%5BBUG%5D+Description
There are at least two different open issues related to this problem (assuming you want to generate java code):
https://github.com/OpenAPITools/openapi-generator/issues/10026
https://github.com/OpenAPITools/openapi-generator/issues/4947
Even the swagger-api code-generator (https://github.com/swagger-api/swagger-codegen) does have the same issue.
IMHO, everything boils down to a problem with the mustache templates and the underlying java code that can not use BeanValidation 2.0 features like:
https://beanvalidation.org/2.0/spec/#constraintdeclarationvalidationprocess-containerelementconstraints
List<#NotNull #Size(max=20) String> searchTerms

What are the available condition constants under uiGridConstants.filter?

Did I miss the link that documents ALL the available uiGridConstants for uiGrid fields in one place? I was working on columnDefs filter and found out EQUAL does not work. That's when I realized there is no central documentation for all the condition constants for uiGridConstants.
columnDefs:
[ { }
, { field: '_pointXID', filter
: {
condition: uiGridConstants.filter.CONTAINS, placeholder: '%PATTERN%'
}, headerCellClass: $scope.whatfilter}
, { field: '_statU16', width: "5%", filter
: {
condition: uiGridConstants.filter.EQUAL, placeholder: '=='
}, headerCellClass: $scope.whatfilter}
, { field: '_valDoub', width: "5%", enableFiltering: false }
]
EQUAL's not one of them, and heck how do I know?!
Looks like I have to open up the source ui-Grid.js to find “uiGridConstants.filter.” literals in the code. Here it is, my summary for all the ui-grid’s available filter conditions in these constants 
1. STARTS_WITH
2. ENDS_WITH
3. CONTAINS
4. EXACT
5. NOT_EQUAL
6. GREATER_THAN
7. GREATER_THAN_OR_EQUAL
8. LESS_THAN
9. LESS_THAN_OR_EQUAL
Have I got all of them or still missed something? (Notice that I can’t locate EQUAL in the source, instead, EXACT!)
You guys are asking of whether there is a default condition. I don't believe there's one, but if your input filter.condition value is not any of the above, your Column filter will return a TRUE which means you have no filters!
So in other words, the default is NO FILTERS : anything goes if your condition constant is not valid
Here be central documentation now
It says:
Used in columnDef.filter to configure filtering on the column
SELECT and INPUT are used with the type property of the filter, the rest are used to specify one of the built-in conditions.
Available condition options are:
uiGridConstants.filter.STARTS_WITH
uiGridConstants.filter.ENDS_WITH
uiGridConstants.filter.CONTAINS
uiGridConstants.filter.GREATER_THAN
uiGridConstants.filter.GREATER_THAN_OR_EQUAL
uiGridConstants.filter.LESS_THAN
uiGridConstants.filter.LESS_THAN_OR_EQUAL
uiGridConstants.filter.NOT_EQUAL
Available type options are:
uiGridConstants.filter.SELECT - use a dropdown box for the cell header filter field
uiGridConstants.filter.INPUT - use a text box for the cell header
filter field

Grails excel-import plugin Numbers populated as real with exponent

I am trying to import a ms-excel 2007 sheet using excel-import plugin. It was simple to integrate with my project and I found it working as expected until I noticed that the number values in the cells are populated as real numbers with exponent.
For example if the cell contains value 9062831150099 -(populated as)->9.062831150099E12 i.e.
A |
_____________________
Registration Number |
____________________
9062831150099
Is populated as: [RegNum:9.062831150099E12]
Anyone could suggest me how I can change this representation back to its original format keeping its type as number?
Missed it at the first attempt but I figured out how to to achieve it:
When invoking the key methods (the ones that process cellMap and columnMaps) for example List bookParamsList = excelImportService.columns(workbook, CONFIG_BOOK_COLUMN_MAP) or Map bookParams = excelImportService.cells(workbook, CONFIG_BOOK_CELL_MAP )
There is also ability to pass in configuration information, i.e. to specify what to do if a cell is empty (i.e. to provide a default value), to make sure a cell is of expected type, etc.
So in my case I created a configuration parameter Map of properties of the object and passed it to the above methods. i.e.
Class UploadExcelDataController {
def excelImportService
static Map CONFIG_BOOK_COLUMN_MAP = [
sheet:'Sheet1',
startRow: 2,
columnMap: [
'A':'registrationNumber',
'B':'title',
'C':'author',
'D':'numSold',
]
]
static Map configBookPropertyMap = [
registrationNumber: ([expectedType: ExpectedPropertyType.IntType, defaultValue:0])
]
def uploadFile(){
...
List bookParamsList = excelImportService.columns(workbook, CONFIG_BOOK_COLUMN_MAP,configBookPropertyMap )
...
}
}

How to access nested JSON in Google Tag Manager value collection in iOS Swift

I'm using the GoogleAnalytics-iOS-SDK 3.10 with iOS 8.1/Swift/XCode 6.1.
I have a GTM container with a value collection macro, which has nested JSON, like this:
{
"cat":
{
"legs": 4,
"sound": "meow"
},
"dog":
{
"legs": 4,
"sound": "woof"
},
"fox":
{
"legs": 4,
"sound": "?"
}
}
How do I get the number of legs a dog has? I've tried (among other variations)
container.stringForKey("dog.legs"), where container is an instance of TAGContainer, and that doesn't work.
If I inspect container.stringForKey("dog"), I get a string, "{legs=4, sound=woof}". Unfortunately, I can't use the .propertyList() string method to get a dictionary from the string because there are commas instead of semicolons, and even if I replace the commas with semicolons, I run into issues if values have spaces in them. For instance, if I used "woof woof" instead of just "woof", the .propertyList() method fails to parse a dictionary from the string. It's also not a valid JSON string so I can't use JSON parsing tools, either.
Is there a clean (or at least recommended) way to do this in Swift?

Resources