When configuring an encoding, and specifying how to access the input file, there are 2 mechanisms available to you:

• Supplying the information directly in the [`Stream` payload](🔗).

• Or creating an [`IngestInputStream`](🔗) and providing its identifier in the `Stream`

The 2 mechanisms are functionally equivalent, and require the same type of information:

• `inputId`, the identifier of the `Input` storage

• `inputPath`, with the full path to the input file on that storage

• `selectionMode` and `position`, to define what stream to use in the input file.

The difference between the 2 mechanisms is historical. Specifying the information directly on the `Stream` was sufficient for most use cases, until we added support for more complex workflows where more than one input file is involved, such as [trimming and concatenation](🔗), Dolby Vision, Dolby Atmos, etc. For those, we had to create a more flexible and more consistent way to specify files (and transformations on files), with multiple subtypes of `InputStream` objects, the primary one for specifying video and audio input files being the `IngestInputStream`.

So, whilst for simple use cases the 2 methods are equivalent, we strongly recommend, if only for consistency, to use the second one. In the future any new input functionality will be provided through `InputStreams`.

# Conversion

To convert your existing code to use the `IngestInputStream` is very simple. Here is an example for Java:

## Before

## After

Note that unlike `StreamInput`, which is an abstraction internal to the SDKs used in the construction of the `Stream`, `IngestInputStream` is an API endpoint in its own right, and you therefore need to call it (as shown on line 8 above), before you can use it in the definition of the `Stream`.