Giter VIP home page Giter VIP logo

sdpoker's Introduction

SDPoker

CLI tool and library for testing SMPTE ST 2110 compliant Session Description Protocol (SDP) files. The tool attempts to apply a number of rules that test relevant clauses of RFC 4566, ST 2110 and AES-67. The tool currently has 112 possible tests.

Just because an SDP file passes these tests does not mean it is 100% valid. However, if it fails one of the tests, the file is likely to need some work!

This is an open source tool contributed for the benefit of anyone developing and deploying professional IP media systems. Please use pull requests and issues to help to enhance it. Please do report any false positives or false negatives found by these tests. A list of possible enhancements is provided below.

SDPoker is part of the zenmos project to develop an automatic testing tool for AMWAs Network Media Open Specifications.

Important Note

This is a fork of the original repository from Streampunk/sdpoker including additional features and bug fixes. It is intended to be used alongside the NMOS Testing Tool.

Installation

Prerequisite

If not already installed, install Node.JS LTS for your platform.

Command line

Install SDPoker globally as follows (use sudo where appropriate):

npm install -g AMWA-TV/sdpoker

To run SDPoker, append a filename or URL to a SDP file:

sdpoker <file_or_url>

Note that the tool only prints an output if the tests fail. A successful test returns immediately with nothing printed and an exit code of 0.

A number of options can be used to configure the behavior of the test. To see the list, run:

sdpoker --help

Library

Install SDPoker as a dependency for the project you are working on:

npm install --save sdpoker

Use the module in your project with the following line:

const { getSDP, checkRFC4566, checkRFC4570, checkST2110 } = require('sdpoker');

Get SDP

The getSDP(path) method returns a native promise to read or download an SDP file from the given path. If the path starts with http://, the SDP file is requested from the given address. Otherwise, the path is treated as a file path related to the current working directory.

For example:

getSDP('http://localhost:3123/sdps/video_stream_1.sdp')
  .then(console.log)
  .catch(console.error);

The value of a fulfilled promise is the contents of an SDP file as a string. SDP files are assumed to be UTF8 character sets. Pass the result into the checkRFC4566, checkRFC4570 and checkST2110 methods.

Check RFC4566

The checkRFC4566(sdp, params) takes a string representation of the contents of an SDP file (sdp) and runs structural tests, format tests and some field specific tests relevant to ST 2110. This is not an exhaustive SDP file tester.

For example:

getSDP('examples/st2110-10.sdp')
  .then(sdp => checkRFC4566(sdp, { should: true }))
  .then(errs => { if (errs.length > 0) console.log(errs); })
  .catch(console.error);

The params parameter is an object that, when present, can be used to configure the tests. See the parameters section below for more information.

The return value of the method is an array of Javascript Errors. The array is empty if no errors occurred.

Check RFC4570

The checkRFC4570(sdp, params) takes a string representation of the contents of an SDP file (sdp) and runs source-filter tests relevant to SMPTE ST 2110.

For example:

getSDP('examples/st2110-10.sdp')
  .then(sdp => checkRFC4570(sdp, {}))
  .then(errs => { if (errs.length > 0) console.log(errs); })
  .catch(console.error);

The params parameter is an object that, when present, can be used to configure the tests. See the parameters section below for more information.

The return value of the method is an array of Javascript Errors. The array is empty if no errors occurred.

Check ST 2110

The checkST2110(sdp, params) takes a string representation of the contents of an SDP file (sdp) and runs through the relevant clauses of the ST 2110-10/-20/-21/-22/-30 documents, and referenced standards such as AES-67 and ST 2022-7, applying appropriate tests.

For example:

getSDP('examples/st2110-10.sdp')
  .then(sdp => checkST2110(sdp, { multicast: true }))
  .then(errs => { if (errs.length > 0)
    console.log(errs.map(e => e ? e.message : undefined));
  })
  .catch(console.error);

The params parameter is an object that, when present, can be used to configure the tests. See the parameters section below for more information.

The return value of the method is an array of Javascript Errors. The array is empty if no errors occurred.

Parameters

The parameters of the library are binary flags that match the command line options:

  • checkEndings: Check line endings are CRLF, no other CR/LF.
  • whitespace: Strict check of adherence to whitespace rules.
  • should: As well as shall, also check all should clauses.
  • noCopy: Fail obvious copies of the ST 2110-10 SDP example.
  • noMedia: Fail SDP files which do not include any media descriptions.
  • duplicate: Expect duplicate streams aka ST 2022-7.
  • videoOnly: Describes only SMPTE ST 2110-20 streams.
  • audioOnly: Describes only SMPTE ST 2110-30 streams.
  • channelOrder: Expect audio with ST2110-30 channel-order.
  • shaping: Check adherence to traffic shaping specification.
  • useIP4: All addresses expressed in IP v4 notation.
  • useIP6: All addresses expressed in IP v6 notation.
  • multicast: Connection addresses must be multicast.
  • unicast: Connection addresses must be unicast.
  • verbose: Print out tests that pass to the console as well as failures.

By default, all flags are false. To pass the parameters to the check methods, use a Javascript object as follows:

let params = {
  duplicate: true,
  multicast: true
};

Tests

For now, please see the comments in files checkRFC4566.js, checkRFC4570.js and checkST2110.js for a description of the tests. A more formal and separate list may be provided in the future.

Enhancements

The following items are known deficiencies of SDPoker and may be added in the future:

  • Tests for attribute a=recvonly
  • Testing whether an advertised connection address can be resolved, joined or pinged.
  • Testing whether advertised clocks are available.
  • Testing that, for AES-67 audio streams, the ptime attribute matches the sample rate and number of channels.
  • Testing ST 2110-30 audio streams against conformance level.
  • Ability to run the tests within a framework like tape.
  • Retrieval of SDP files over HTTPS.

Pull requests and issues will be resolved when the developers have sufficient time available. If you are interested in sponsoring the development of this software or supporting its ongoing maintenance, please contact Streampunk Media ([email protected]).

License

This software is released under the Apache 2.0 license. Copyright 2018 Streampunk Media Ltd.

sdpoker's People

Contributors

andrewbonney avatar garethsb avatar jonathan-r-thorpe avatar kierank avatar pkeroulas avatar rbgodwin avatar rbgodwin-nt avatar sparkpunkd avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sdpoker's Issues

fmtp value check

As to my interpretation of the SMPTE ST 2110 suite, fmtp parameters are only required in 2110-20 but not in 2110-30 nor 2110-40, whereas sdpoker makes them mandatory for all SDPs (e.g., raises an error if it's missing).

The proposal would be to parse if m!=audio or if a!= smpte291.
Only then, raise that the fmtp parameter is missing.

Attempt to update hangs

I'm attempting to update a system that has had a previous version of sdpoker installed to the latest, and the recommended command:

sudo npm install -g AMWA-TV/sdpoker

just hangs with

[..................] / rollbackFailedOptional: verb npm-session 89a985adcaa160e1

The hash at the end changes each time, but nothing else ever happens, even if left for many minutes.

Is there something obvious that is likely to be causing this?

CI workflows

We should add lint and ideally some regression tests to GitHub Actions!

Relax checking of a=fmtp line ending

Currently the a=fmtp line is checked for a tailing ; . This is only necessary because of an inclusion in ST.2110-10. Generic SDP files should not fail because of this, and as this requirement may be revised in ST.2110's one year review it seems unnecessary to penalise implementations for the error.

'request' and 'request-promise-native' deprecated.

'request' and 'request-promise-native' have been deprecated for a while which can lead to broken installations when installing on a fresh system (this can be worked around by executing npm i request-promise after the install).

However, an alternative to request needs to be found.

This issue suggests some alternatives, and although the suggestions are more than 4 years old, Axios seems to have some popularity and is still being actively developed.

Thoughts?

a=mediaclk:direct syntax

RFC 7273 says:

direct = "direct" [ "=" 1*DIGIT ] [SP rate]
rate   = "rate=" integer "/" integer

However, the tests for this only check the first part and allow any string for the rate part.
And the makeSDP function doesn't appear to put the / and denominator in the generated value.

(I've also seen a=mediaclk:direct=0 rate=48000 in the wild.)

Refactoring extractMTParams

This issue captures observations from code reviews performed as part of extending sdpoker to support ST 2110-22 (JPEG-XS). During the review it was observed that extractMTParams could do with refactoring

  • Ought to split on m= and then produce one entry for each media description,
  • currently files with e.g. two a=fmtp: lines per media description, or none (some media types don't need one), or media descriptions where the a=rtpmap: line comes after the a=fmtp: line rather than before, will produce unexpected results

Easier maintenance/string consistency

#21 is adding --verbose for ST 2110 tests which outputs "Test Passed" or "Test Skipped" messages as appropriate if there are no Errors to report. It would be nice to extend this to the RFC 4566 and RFC 4570 tests.

Some ideas also came up during review to reduce duplication of test messages/explanations, see e.g. #21 (comment), #21 (comment)

Check RFC 9134 format-specific parameters

For ST 2110-20 video/raw format-specific parameters like sampling, colorimetry, etc. are are described in the SMPTE spec, and tested by the associated test_20_7x_x functions.

However for video/jxsv the spec for the equivalent format-specific parameters and JPEG XS specific ones like profile and level is not in ST 2110-22, because that spec is agnostic to the compression. Rather they are specified in RFC 9134.

We need test functions for RFC 9134!

VSF TR-10-1 compatibility

sdpoker indicates a=mediaclk:sender as an error.

The 'direct' reference for the mediaclk parameter should be used, as per ST 2110-10 Section 8.1. Found 'a=mediaclk:sender'.

ST 2110-10:2017 Section 8.1 says

All stream descriptions shall have a media-level mediaclk attribute as per IETF RFC 7273 section 5.2. The
direct reference should be used.

ST 2110-10:2017 Section 2 says

The keywords, "should" and "should not" indicate that, among several possibilities, one is recommended as
particularly suitable, without mentioning or excluding others; or that a certain course of action is preferred but
not necessarily required; or that (in the negative form) a certain possibility or course of action is deprecated
but not prohibited.

VSF TR-10-1 overrides ST 2110-10:2017 Section 8.1 saying

If the Media Clock is asynchronous with respect to the Internal Clock, for example if Async
Media is present at the input of a Sender, the following form shall be used:
a=mediaclk:sender

Is there a room in sdpoker to handle this case?

Add support for testing other common SDP files

At present given the user-base this is likely to target SMPTE standards including:

  • ST.2110-22
  • ST.2110-31
  • ST.2022-6

However, it would be useful to include a mode which permits more general purpose SDP validation without the specifics from the standards.

Check for traffic shaping

In the current code the caller must specify --shaping in order that the 2110-20 check is ran to check for 2110-21 items. SMPTE2110-22 (the version on the IEEE site) mandates use of 2110-21 with specific parameters. When I implement the test I will for the first cut also allow skipping the test to avoid inconsistencies with the existing code.

Question is - should this test be mandatory for 2110-20 and 2110-22? In which case I think we should remove the --shaping parameter or override it if we can key off of SSN in the fmpt values.

[JT-NM Tested] Update to handle forthcoming ST 2110 revision

ST 2110-xx:2022 documents add some new format-specific parameters and new acceptable values for existing ones. The revision is now always identified by the SSN parameter.

SDPoker needs to be updated to report incorrect values for parameters based on the SSN for the forthcoming JT-NM Tested event.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.