Draft Operational Guidelines



Download 217.92 Kb.
Page2/2
Date28.05.2018
Size217.92 Kb.
#51624
1   2

Scope


This document provides Operational Guidance for the use of the [Draft] Broadcast & Online IMF Application Constraints Specification when delivering to or exchanging content between DPP members or others who also use the DPP Broadcast & Online IMF Application Constraints Specification for the following purposes

  • Delivery of AS-11 X series Air Masters

  • Delivery of AS-11 Legacy V1.1 Air Masters

  • Exchange of content between IMF Applications

  1. Conformance Notation


[To be replaced with agreed DPP-SMPTE specification boiler plate text – example text only]

Normative text is text that describes elements of the design that are indispensable or contains the conformance language keywords: "shall", "should", or "may". Informative text is text that is potentially helpful to the user, but not indispensable, and can be removed, changed, or added editorially without affecting interoperability. Informative text does not contain any conformance keywords.

All text in this document is, by default, normative, except: the Introduction, any section explicitly labelled as "Informative".

The keywords "shall" and "shall not" indicate requirements strictly to be followed in order to conform to the document and from which no deviation is permitted.

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.

The keywords "may" and "need not" indicate courses of action permissible within the limits of the document.

The keyword “reserved” indicates a provision that is not defined at this time, shall not be used, and may be defined in the future. The keyword “forbidden” indicates “reserved” and in addition indicates that the provision will never be defined in the future.

A conformant implementation according to this document is one that includes all mandatory provisions ("shall") and, if implemented, all recommended provisions ("should") as described. A conformant implementation need not implement optional provisions ("may") and need not implement them as described

Unless otherwise specified, the order of precedence of the types of normative information in this document shall be as follows: Normative XML shall be the authoritative definition; Prose including Tables shall be next; followed by formal languages; then figures; and then any other language forms.

  1. Normative References


The following standards contain provisions which, through reference in this text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this standard are encouraged to investigate the possibility of applying the most recent edition of the standards indicated below. [INCOMPLETE AT THIS TIME]

Proposed Broadcast & Online IMF Application Constraints

SMPTE RDD 36:2015, Apple ProRes Bitstream Syntax and Decoding Process

SMPTE RDD 44:2017, Material Exchange Format — Mapping and Application of Apple ProRes

SMPTE ST 2067-2:2016, Interoperable Master Format – Core Constraints

SMPTE ST 2067-21:2016, Interoperable Master Format – Application #2E

SMPTE RDD 6

SMPTE RDD [ProRes IMF Application]

Note that this Pro-Res IMF Application essentially takes the provisions of IMF App 2e (SMPTE ST 2067-21:2016) and replaces the codec with ProRes. Initial copies of this document for DPP review are expected mid-August 2017.

SMPTE [IMF Sidecar File]

Note that this Sidecar document is still in the SMPTE draft state and can only be seen by participants of the SMPTE standards committee. Commenters who are interested in this functionality are encouraged to join the SMPTE TC-35PM working group and provide comments.

[Further TBD]

  1. General


These Operational Guidelines can be used with the following Application(s) or Application Constraints

Where ProRes is used, all provisions of Specification XXX (IMF Broadcast & Online Application Constraints - ProRes) shall apply unless specifically excluded.



Where J2K is used all provisions of SMPTE ST 2067-21 (Application 2e) shall apply unless specifically excluded

[Where H.264 is used all provisions of (documents to be proposed as required) shall apply unless specifically excluded]

  1. Video Requirements

    1. Video Format


Material delivered to this specification must be acquired, post-produced and delivered as follows:

  • 3840 x 2160 or 1920 x 1080 pixels in an aspect ratio of 16:9.

  • 25/50/100 frames per second progressive only.

  • Colour sub-sampled at a ratio of 4:2:2 or 4:4:4.

  • 10/12bit.

    1. Video Codec


The codecs, including the H.264 variants, must be I-frame only.

The information in the below table defines the Master Delivery Minimum bitrates for Library Mastering and assumes 10-bit processing 4:2:2 Progressive Scan. Where 4.4.4 12-bit, HDR image processing is required, respective minimum data rates may need to increase,

Table 1 Indicative Data Rates




ProRes 422HQ

[ITU-T H.264]

J2K

1080P/25

190Mb/s

[200Mb/s]

180Mb/s

1080P/50

370Mb/s

[400Mb/s]

350Mb/s

2160P/25

740Mb/s

[720Mb/s]

650Mb/s

2160P/50

1400Mb/s

[1400Mb/s]

1200Mb/s

The bitrates outlined in Table 1 are the recommended minimum and should be discussed with your broadcaster, distributor or content owner in advance to ensure you are delivering in accordance with the requirements specified in your contract.

Note: A Library Master may also be suitable as an Air Master.


  1. Audio Requirements

    1. Audio Codec


All audio tracks should be encoded as PCM with a sample rate of 48kHz at a bit depth of 24bits/sample. 96kHz may be delivered if available but must be discussed with your broadcaster in advance.

    1. Stereo Audio Requirements


Stereo tracks shall carry sound in the A/B (Left/Right) form. If mono originated sound is used, it shall be recorded as dual mono, so that it may be handled exactly as stereo. It shall meet all the stereo standards regarding levels, balance and phase. Stereo audio shall be delivered as a single Track in the MXF container with two discrete Channels.

    1. Surround Audio Requirements


Surround sound is transmitted in the 5.1 format however Surround sound programmes shall include a stereo mix that meets all requirements for stereo delivery. This should generally be an automated down-mix of the surround channels, using the same down-mix parameters as are held in the metadata. Surround audio shall be delivered as a single Track in the MXF container with six discrete Channels.

Each CPL referencing one or more audio track file containing 5.1SoundfieldGroup(s) shall also reference exactly one Dolby Audio Metadata SMPTE [IMF Sidecar File]


    1. Audio Channel Allocation


All audio channels shall contain audio channel labelling as defined in SMPTE ST 377.  Each Track shall be carried in it’s own MXF Track File, and shall be correctly referenced in the IMF structural components. Any Tracks that are included in the IMF package shall be as specified in the table below. Each delivered package shall contain exactly one Stereo Main Programme Mix and one Surround Main Programme Mix as defined in the table below.

Table 2: Audio Groups

Purpose

SoundfieldGroupLabel

GroupofSoundfieldGroups

Label2
Sound

Channels


Language

Number of Sound Tracks per Package

Stereo Main Programme Mix

SMPTE20678StandardStereo

MainProgram

2

En*

(or other

as agreed)


1

Surround Main Programme Mix

_5.1SoundfieldGroup

MainProgram

6

En*

(or other

as agreed)


1

Alternative Stereo Mix

(such as an additional language)
SMPTE20678StandardStereo

Alternative

Program


2

As

Required


As

Required


Stereo Music & Effects

(M&E)


SMPTE20678StandardStereo

MusicAndEffects

2

As

Required


As

Required


Alternative Surround Mix

(such as an additional language)
_5.1SoundfieldGroup

Alternative

Program


6

As

Required


As

Required


Surround Music & Effects

(M&E)


_5.1SoundfieldGroup

MusicAndEffects

6

As

Required


As

Required


Audio Description

(Pre-Mixed with Programme Audio)
SMPTE20678StandardStereo

AudioDescription

ProgramMix
2

As

Required


As

Required


Audio Description

Voice and Control Signal
AudioDescriptionStudioSignal

AudioDescription

2

As

Required


As

Required


En = English or other language as agreed.

Note: This table may be updated to match any work within SMPTE to provide common Audio Content and Element Kind definitions.

Auto Pitch Correction is Currently Out of Scope.

    1. Sound to Vision Synchronisation


The relative timing of sound to vision should not exhibit any perceptible error. Sound shall not lead or lag the vision by more than 5ms. Audio (files) shall remain frame locked to video (files) through the programme duration and shall conform to SMPTE ST2067-3. Any defined frame rate change shall be reflected across both media.

  1. Timecode


Conventional timecode does not exist in IMF. The composition playlist defines a unique timeline for the composition and associates a unique offset expressed in Edit Units. While this method allows precise synchronization of essence within the Composition Playlist it is not always appropriate for the synchronization of downstream devices. The Composition Playlist therefore provides the information necessary to generate a unique timecode output from its timeline.

  1. File Package


This section should be read in conjunction with the technical mastering format specification which specifies the core metadata structures of the IMF package (IMP). The sections below specify the delivery requirements for the CPL, OPL and associated Identifiers.

Each delivered IMF Package shall be an [reference needed].

Each Track File within an IMF package shall contain a Package UID as specified in SMPTE ST 330 and referenced in the Packing List. All Track Files referenced in the Packing List shall be present in the IMF delivery. UUIDs within an IMF file will normally be automatically generated and not easily human readable.

    1. Composition Playlist (CPL)


The CPL contains and controls the intended playback timeline for a specific programme version which references the associated Track Files UUID which contain the essence and enables their synchronisation. The Composition Playlist does not define any form of transition or overlap between Track Files and the Track Files should be created to avoid artefacts when reproduced using the delivered CPLs.

The CPL uses an XML structure specified by an XML schema, and is human readable.


    1. Output Profile List (OPL)


The OPL contains ‘macros’ which are used to transform or render the video and audio assets to the required format for the particular distribution platform or application. Examples are for ready to air broadcast, or delivery to a specific VOD platform. The OPL instructions available enable the functionality for transcoding, aspect ratio conversion, image cropping, and audio routing. Each OPL is associated with exactly one CPL.

As with the CPL, it uses an XML structure and is human readable.


    1. CPL and OPL Delivery


The number of CPLs and OPLs to be delivered with the IMF package for a given programme (composition) should be confirmed with the broadcaster in advance. This will depend on the number of versions and formats agreed as part of the deliverables, and some example use cases are given below, in table 3. 

With any programme delivery there should always be a minimum of one CPL delivered as part of the IMF package of files, representing the particular editorial version contracted for or licenced.

OPLs should be provided where different formats are to be delivered for onward distribution to broadcast or other platforms requiring the Master programme essences to be processed.

Example use cases are shown in table 3, together with the required CPLs and OPLs which should be included.



Table 3. Use Case Examples




IMF Delivery Use Case

CPL

OPL

1

Single Programme version delivered for Mastering use.

1 x CPL

x

2

Single Programme version delivered for both Mastering and Broadcast use.

1 x CPL

1 x OPL

(for AS-11)

3

Multiple editorial programme versions for Mastering use

1 x CPL for each editorial version.

x

4

Multiple formats of a programme delivered for distribution to multiple different platforms.

1 x CPL for each editorial version.

1 x OPL for each different format required for the platforms *

Note: not every distribution platform will require a separate format and therefore OPL. The CPLs and OPLs should use identifiers to clearly reference which programme version or format they refer to, (see the section Versioning and Identifiers below).

    1. Versioning and Identifiers


Each CPL should contain a universally unique identifier (UUID) that can be used to track versioning of the playback timeline and uniquely identify the editorial programme versions within the IMF package. The CPLID is a mandatory element of the CPL and shall be unique to the editorial programme version to which it relates. In addition, if one or more elements of the CPL metadata is changed, then the CPLID shall be changed. [To confirm and Delivery Group to discuss.]

The CPL shall also contain an element to identify the unique programme version using a human readable URI for the Content Version ID element. The allowable URI schemes for delivery are ISAN, EIDR, UUID SMPTE ST 2029, Basic UMID, and Custom.

The Content Version ID within the CPL should be identical to the ‘Production Number or Other Identifier’ and specify the ‘Other Identifier Type’ as in the main metadata set, (see Metadata Section above).

Proposed use of schemes TBD, e.g. use of ISAN, EIDR or Custom IDs, Broadcaster Specific etc. [The allowable Content ID schemes for this application should be discussed by the Delivery Group]

  1. AS-11 deliverables – Metadata and Segmentation


The final text in this section will conform to the published IMF Sidecar document when it is available. It will describe the optional inclusion, AS-11 Air Master XML Metadata.

Metadata is the name for all information which is not the audio or video essence, but which is required to ensure that contents of the file can be identified correctly.



Descriptive metadata is usually added manually by the producer of the file. This includes information which will be read by the users of the file in order to identify the material and use the appropriate parts for further operations.

Metadata shall be carried in a separate XML file. This metadata shall be associated with the CPL using the SMPTE Draft Sidecar file mechanism. The required metadata shall appear in the SidecarAssetList, Extra Metadata associated with the composition may be included in the SidecarAssetList. The AssociatedCPLList shall have one entry for every Composition that the metadata is associated with. The value of the Id child element of the SidecarAsset parent shall be used as the persistent identifier of the metadata.

The IMF CompositionTimecode child element properties shall be set as follows:


TimecodeRate

shall be set to match the Virtual Track Edit Rate: 25, 50, 100

TimecodeDropFrame

shall be false.

TimecodeStartAddress

shall be set so that the Line_Up Start and Ident Clock_Start of the required descriptive Metadata are correct

Metadata within the IMF package shall be as described by the add reference and shall correctly reflect the material contained in the IMF package.

    1. Metadata for AS-11 X1 UHD Air Master Delivery


The XSD for DPP AS-11 X1 is available at this address;

https://github.com/AMWA-TV/AS-11_X1/tree/master/specification_data_files/www.amwa.tv_c0f7b64/block/DM_Programmes/artefacts


    1. Metadata for AS-11 V1.1 HD/SD Air Master Delivery


Text and XSD details TBD

    1. Segmentation for X1 and AS-11 V1.1 HD/SD Air Master Delivery


Details TBD – [EBU QC “Programme Format” proposals to be considered and taken to the IMFUG]

  1. Access Services

    1. Closed Subtitles/Captions


The subtitles shall be correctly timed with respect to the corresponding audio track(s) and defined/referenced/labelled in a CPL track. Technical details within the Broadcast & Online IMF Application Constraints document.

    1. Audio Description (AD) / Described Video Service (DVS)


Audio Description files shall be presented in the IMF package as BWF (sometimes called ‘B-WAV’) files, conforming to the specification in EBU-Tech 3285, and the control track as described in BBC Research & Development White Paper WHP198. File duration shall match exactly the corresponding video element and be correctly defined/referenced in the CPL. All IMF rules for audio essence should be met (segment duration, MCA labelling etc.)

    1. Open Signing


In Vision signing is not currently in scope but could be supported by delivery of a Supplementary Package

  1. Validation


EBU.IO/QC IMF QC Items and QC Templates to be used to verify the following:

    1. Complete Delivery


The initial delivery of a version that is complete and made up of all required essences in full.

      1. The IMF package should at least include the following files:


  • Asset Map (ASSETMAP) XML File.

  • Volume Index (VOLINDEX) XML File.

  • Packing List (PKL) XML File.

  • Composition Playlist (CPL) XML File.

  • Output Profile List (OPL) XML File.

  • Video MXF Track File(s).

  • Audio MXF Track File(s).

    1. Supplemental Delivery


A supplemental delivery is the delivery of a package that provides the differences between the initial version and a new version or to fix issues found in an existing version.

      1. Package Contents


The IMF package should at least include the following files:

  • Asset Map (ASSETMAP) XML File.

  • Volume Index (VOLINDEX) XML File.

  • Packing List (PKL) XML File.

  • Composition Playlist (CPL) XML File.

  • Output Profile List (OPL) XML File.

  • Track Files of the new content.

    1. Packing List


The Packing List (PKL) XML file shall include references to all CPLs and essence files contained within the IMF package.

  1. Quality Control (QC)


Note – this section may become an Annex or just point to the DPP QC requirements (https://dpp-assets.s3.amazonaws.com/wp-content/uploads/2015/06/DPP_Quality_Control_Requirements_V2.0.pdf)

    1. General Quality


All programmes are expected to reach a high standard of video and audio quality. This does not mean low quality material cannot be used. Archive and specialist low quality material used in context is acceptable.

      1. General Video Quality


  • The picture shall be well lit and reasonably but not artificially sharp.  

  • The picture shall be free of excessive noise, grain and digital compression artefacts.

  • The picture shall be free of excessive flare, reflections, lens dirt, markings and obstructions (e.g. lens hood), and lens aberrations.

  • Movement should appear reasonably smooth and continuous, and should not give rise to distortions or break-up to moving objects, or cause large changes in resolution.

  • The picture shall be free of excessive black crushing and highlight compression. Hard clipping of highlights (e.g. by legalisers) shall not cause visible artefacts on screen.

  • Colour rendition, especially skin tones, shall be consistent throughout, and provide a realistic representation of the scene portrayed unless it is altered as an editorially essential visual effect.

  • The picture shall be stable and continuous – i.e. no jumps, movements, shifts in level or position. There should be no flash frames or very short shots unless editorially essential.  

  • There shall be no visible contouring/artefacts caused by digital processing. Quantisation noise must not be apparent.  

  • There shall be no noticeable spurious signals or artefacts e.g. streaking, ringing, smear, echoes, overshoots, moiré, hum, cross-talk etc.

      1. General Audio Quality


  • Sound shall be recorded with appropriately placed microphones, giving minimum background noise and without peak distortion.

  • The audio shall be free of spurious signals such as clicks, noise, hum and any analogue distortion.

  • The audio shall be reasonably continuous and smoothly mixed and edited.

  • Audio levels shall be appropriate to the scene portrayed and dynamic range should not be excessive. They should be suitable for the whole range of domestic listening situations.  

  • Surround and Stereo audio shall be appropriately balanced and free from phase differences, which cause audible cancellation in mono.

  • The audio shall not show dynamic and/or frequency response artefacts due to the action of noise reduction or low bit rate coding systems.


    1. Eyeball Quality Control


Refer to the separate DPP Quality Control Requirements document for the complete list of eyeball QC requirements. (https://www.digitalproductionpartnership.co.uk/publications/theme/quality-control/ - publication-6891)

      1. Complete Delivery


A full Eyeball QC shall be performed on the primary CPL and associated essence files. The QC is to ensure video and audio quality are consistent throughout. The receiver requires a QC Report in PDF form, to be delivered ancillary to the IMF package.

      1. Supplemental Delivery


An eyeball QC shall also be completed on the differences in a supplemental CPL and associated essence files to ensure they are correctly positioned and the video and audio quality is consistent with the primary CPL and associated essence files. The receiver requires a simple checklist in PDF form, to be delivered ancillary to the IMF package.

    1. Automated Quality Control


Refer to the separate DPP Mastering Format AQC document for the complete list of AQC requirements.

      1. Complete Delivery


An AQC process shall be performed on the primary CPL and associated essence files. The AQC shall test against the IMF Core Constraints (SMPTE ST 2067-2). All XML files shall be validated against their associated schemas. The receiver requires an AQC report in PDF form, to be delivered ancillary to the IMF package.

      1. Supplemental Delivery


An AQC process shall be performed on the differences in a supplemental CPL and associated essence files. The AQC shall test against the IMF Core Constraints (SMPTE ST 2067-2). All XML files must be validated against their associated schemas. The receiver requires an AQC report in PDF form, to be delivered ancillary to the IMF package.

Annex 1 Example DPP AS-11 X1 Metadata


Informative

The text in this Annex is an example of DPP AS-11 X1 production metadata. It will will conform to the published IMF Sidecar document when it is available Metadata



DPP AS-11 X1 Production Metadata Worked Example



Field Name

DPP UHD AS-11 X1 XML

Definition


Required

Example

Identifiers (At least one Identifier must be included)

Identifier_Value

The identifier itself

Required

PGMID

Identifier_Type


The type of identifier in Identifier_Value. Examples include broadcaster ID, Production Number, ISAN, EIDR, and UMID

Required

DPP broadcaster ID

EIDR

Identifier_Authority

The entity responsible for issuing the identifier

Optional

DPP broadcaster

EIDR

Programme Domain Specific Metadata

Title_1

The final name of a "group" of episodes to which the meme belongs. These episodes have a shared identification and branding and are linked by common characters, subject matter, style or story.

Required

Family – Series 2


Title_2

The final name of the programme used to identify it as an editorially distinct member of a series / season (in other words: an "episode"). This name may include a number (or consist only of a number) indicating the position of the episode within the series / season.

Required

Episode 3 – Fire

Title_3

The final name of the programme including details of any specific purpose for which this programme was created (in other words: "version" information).

Required

Episode 3 Pre-watershed

Synopsis

A brief descriptive summary of the programme.

Required

An eventful day for all the residents of the house.

Genre

A single style or category describing the whole programme.

Optional

Drama


Completion_Date

The date on which the programme file was completed ready for delivery to the broadcaster.

Required

2016-11-13

Copyright_Year

The full year in which one of the following occurred or will occur: completion of the production of the programme; delivery of the completed file to the broadcaster; transmission of the delivered programme.

Required

2016

Originator

The name of the person or organisation responsible for creating the programme.

Required

BBC Studios

Distributor

The name of the person or organisation responsible for supplying the programme to the broadcaster.

Optional

BBC

Contact_Email

The email address for the person or organisation responsible for supplying the programme file to the broadcaster.

Required

john@bbc.co.uk

Contact_Telephone_Number

The telephone number for the person or organisation responsible for supplying the programme file to the broadcaster.

Required

+44 123 456 7890

Picture_Ratio

The ratio of the display width to the display height of the smallest rectangle that completely contains (throughout the duration of the entire meme) the region of the video frame used for "programme content" (where "programme content" includes all pictures, captions, etc. but excludes any black bars).

Optional

Full Frame

Product_Placement

A flag to indicate whether the programme contains "product placement".

Optional

Yes

Textless_Elements_Exist

A flag to indicate whether the programme contains "text-less elements" after the end of the main me content.

Optional

Yes

Programme_Has_No_Text or Programme_Has_Text

The presence of Programme_Has_Text indicates that the main programme content contains text overlays (or similar) in the video.

Required

Programme Has Text

Programme Text Language: eng

Total_Programme_Duration

The sum of the durations of all the parts / segments in the entire programme.

Required

00:59:02:00

Line_Up_Start

The timecode at which the line-up test signals begin.

Required

09:59:30:00

Ident_Clock_Start

The timecode at which the initial "ident" / slate / countdown clock begins.

Required

09:59:50:00

Is_Not_Three_D or Is_Three_D

The presence of Is_Three_D indicates that the file contains video intended for stereoscopic rendition.

Required

Is Not 3D

In Vision Access Services

Open_Captions_Not_Present or Open_Captions_Present

The presence of Open_Captions_Present indicates that the programme contains visible (in-vision) subtitling information.

Required

Open Captions Present

Caption Language: en

Caption Type: Translation


Signing_Not_Present or Signing_Present

The presence of Signing_Present indicates that the programme contains visible (in-vision) signing.

Required

Signing Present

Signing Language: ase



Signing Type: Signer with programme

Content Details

Video_Comments

A description of the subjective quality of the video in the programme including notes on any global characteristics or video treatments.

Optional

Some video noise throughout as a result of using archive content

Audio_Comments

A description of the subjective quality of the audio in the programme including notes on any global characteristics or audio treatments.

Optional

Some audio clicks throughout as a result of using archive content

Audio_Loudness_Specification

The Audio Loudness Specification to which the maker of the programme intended the finished (ready for transmission) audio content to comply

Required

EBU R128

Compliance_To_Specification_Is_Not_Achieved or Compliance_To_Specification_Is_Achieved

The presence of Compliance_To_Specification_Is_Achieved indicates that the finished (ready for transmission) audio content complies with the indicated Audio Loudness Specification

Required

Compliance To Specification Is Achieved

Programme_Loudness_Value

The "Programme Loudness Value" in LUFS as measured in accordance with the indicated Audio Loudness Specification. This is intended to give an indication of the degree to which the content deviates from the indicated Audio Loudness Specification, rather than a precise measurement of the loudness of the content.

Optional

-23.1



1 Commenters who are interested and wish to contribute to the SMPTE draft documents are encouraged to join the relevant SMPTE working group and provide comments

2 Audio Element names used here and in AMWA AS-11 X series will be revised to comply with any proposed Audio Element and Content Kind as needed

Approved

Directory: wp-content -> uploads -> 2017
2017 -> Leadership ohio
2017 -> Ascension Lutheran Church Counter’s Schedule January to December 2017
2017 -> Board of directors juanita Gibbons-Delaney, mha, rn president 390 Stone Castle Pass Atlanta, ga 30331
2017 -> Military History Anniversaries 16 thru 31 January Events in History over the next 15 day period that had U. S. military involvement or impacted in some way on U. S military operations or American interests
2017 -> The Or Shalom Cemetery Community Teaching on related issues of Integral
2017 -> Ford onthult samenwerking met Amazon Alexa en introduceert nieuwe navigatiemogelijkheden van Ford sync® 3 met Applink
2017 -> Start Learn and Increase gk. Question (1) Name the term used for talking on internet with the help of text messege?
2017 -> Press release from 24. 03. 2017 From a Charleston Car to a Mafia Sedan
2017 -> Tage Participants
2017 -> Citi Chicago Debate Championship Varsity and jv previews

Download 217.92 Kb.

Share with your friends:
1   2



The database is protected by copyright ©ininet.org 2024
send message
    Main page
information contained
final version