To extract a DVR clip from Wowza Streaming Engine, convert an existing nDVR store to MP4 and specify the portion you need using the time rules for your chosen API route. REST start and end values are UTC Unix timestamps by default, REST duration is in milliseconds, and the Java example uses offsets in milliseconds; these are different parameter schemes, not interchangeable values.
First confirm that the recording exists and covers the period you need. Then choose either the documented REST converter action or the Java HTTP provider example, build the request using that route’s boundary semantics, and inspect the resulting MP4. Conversion cannot recover footage that was never recorded.
Confirm the nDVR recording and store
Wowza nDVR records a live stream as it is ingested, creating a store that can later be used for playback or conversion. Before composing a clip request, list the stores for the relevant application and inspect the intended store. The store detail response can show whether audio and video are available, whether the store is live, its DVR time boundaries and duration, its UTC boundaries, and its conversion status. Those fields help you establish that you have the right recording and that its time range includes the material you want.
The documented REST list path is:
/v2/servers/{serverName}/vhosts/{vhostName}/applications/{appName}/instances/{instanceName}/dvrstores
Append the store name to inspect one store. Replace each placeholder with the actual values for your Engine installation; the instance name commonly uses _definst_ when that is the application’s configured instance. Do not assume that a sample server, port, application name, or store name from a guide applies to your deployment.
A store may be live or may have been created through a recording configuration that has since stopped. Check the source and store status before requesting a clip. Wowza’s nDVR store management guide describes listing and inspecting stores. Its nDVR setup guide also explains that a disconnected live source can prevent recording. Playback over HLS or MPEG-DASH with DVR controls is context for the recording, not the MP4 extraction operation itself.
If you are preparing a separate always-on YouTube channel from recorded material, the concern is different: verify that the files are suitable and that the stream schedule is stable. Our guide to checking recorded classes for a 24/7 live stream covers source-file suitability rather than Wowza export parameters.
Choose REST or the Java converter workflow
For a direct documented operation, use the REST converter action on one store. The request is a PUT to the store path followed by /actions/convert. Wowza’s REST API guide for converting nDVR stores shows the store-list, store-detail, and conversion sequence. The REST API reference lists the converter action and its available options; check its converter action reference for your Engine build and parameters.
The Java API example is a different integration style. It describes a converter HTTP provider at /converter, enabled through the Engine virtual-host configuration and implemented as Java code. Its command vocabulary includes startoffset and endoffset, as well as convert, status, and expire operations. Use it if that provider approach fits your Engine-side integration; do not send its offset parameters to the REST action or treat the endpoints as equivalent.
| Choice | Boundary parameters | Integration and operational note |
|---|---|---|
| REST converter action | Start/end as UTC Unix timestamps by default, or duration in milliseconds; choose DVR time explicitly if needed | Direct store action with conversion options and status available through REST. The guide covers single stores and grouped ABR stores. |
| Java converter example | startoffset and endoffset in milliseconds, measured from opposite ends of the store |
Engine-side Java HTTP provider example. Conversion settings may be cached for up to 30 minutes; it documents an expire command. |
The documentation has distinct version qualifications. The REST guide identifies Engine 4.3.0 or later, while the Java example identifies 4.4.0 or later; the REST API reference separately identifies the converter action as available in builds 15942 or later. Confirm your exact Engine version and build against current Wowza documentation before adopting an example. These are compatibility requirements, not a promise that every setting behaves identically across versions.
Set REST clip boundaries in UTC Unix time
For the REST converter, dvrConverterStart and dvrConverterEnd use UTC Unix timestamps by default. These values represent absolute moments on the UTC timeline, not milliseconds since the store began and not a Java offset. Select the beginning and end of the desired clip from the inspected store’s time range, then convert those UTC instants to Unix timestamp values in the units expected by the REST guide. The key safeguard is to establish the time basis before calculating anything.
A typical single-store request has this shape:
PUT http://127.0.0.1:8087/v2/servers/{serverName}/vhosts/{vhostName}/applications/{appName}/instances/{instanceName}/dvrstores/{dvrStoreName}/actions/convert?dvrConverterStart={utcStart}&dvrConverterEnd={utcEnd}
This is a template, not a ready-to-run public endpoint. The local address and port are illustrative. Wowza’s REST reference specifies basic authentication; use the authentication and network controls configured for your own Engine rather than publishing a reachable endpoint or credentials. The route names the server, virtual host, application, instance, and store, so a typo at any level can send the operation to the wrong target or make it fail.
If you intend to select using Wowza DVR time rather than UTC, set the documented dvrConverterTimeType=DVR option. Do this only when the desired boundaries are expressed in DVR time. Wowza distinguishes DVR time, packet time, and UTC. DVR time starts at zero and advances in milliseconds, but does not count gaps when a source stops sending or in append-mode cases. Packet time preserves encoder timestamps. UTC is assigned as packets enter the nDVR module, so it indicates roughly when Wowza received them rather than exactly when the encoder sent them.
That distinction matters when you are matching an event to a wall-clock schedule. A local event in India, for example, may be described in Indian Standard Time, but the REST default is UTC Unix time. Convert the intended wall-clock moment to UTC deliberately, taking the applicable date and time zone into account; do not paste a local clock reading as if it were already a UTC timestamp. For a stream assembled across gaps, DVR-time duration can also diverge from elapsed wall-clock time. The guide to setting Indian Standard Time schedules is useful for schedule planning, but it does not change Wowza’s API time basis.
Use duration in milliseconds without start or end
The REST converter also accepts dvrConverterDuration, measured in milliseconds. Use it when you want a duration-based selection supported by the converter rather than boundaries expressed as absolute UTC start and end instants. Do not combine dvrConverterDuration with either dvrConverterStart or dvrConverterEnd; the documented rule is that duration cannot be used together with start or end.
This is a parameter constraint, not a convenient shorthand for setting both boundaries. For example, do not calculate an end timestamp and send it alongside duration because both seem useful, and do not reinterpret a duration value as an absolute timestamp. Decide which selection method answers your task: a pair of UTC boundary instants, or the documented duration setting. The request should make that decision explicit.
Before sending a duration request, check which time type applies and what the converter considers the selected range in that mode. The REST documentation exposes other conversion options, including output filename and tolerance in supported versions, but they do not change the fundamental units of start/end versus duration. Avoid adding options from an example without checking that they exist in the build you run.
A duration is often easier to reason about when you are extracting a known elapsed interval, but it is not automatically the right choice for an event with a known wall-clock start and finish. In that case, boundary timestamps may be clearer, provided you use UTC and account for the fact that UTC records Wowza’s packet receipt timing. If exact editorial cut points matter, inspect the exported MP4 rather than assuming that the request’s nominal duration guarantees a frame-exact result.
Select a clip with Java offsets in milliseconds
The Java converter example uses a different pair of parameters: startoffset and endoffset. Both are in milliseconds, but their reference points are opposite. startoffset measures from the beginning of the nDVR store. endoffset measures backwards from the end of that store. The documented zero value means use the beginning for the start offset or the end for the end offset, respectively.
For a store that spans a longer period than the clip you need, calculate each offset relative to the correct end of the store. Do not copy UTC Unix values from a REST request into these fields. Nor should you assume the Java example’s start offset and end offset are both elapsed times from the beginning; only the start offset uses that reference point. Write down the store’s duration and the selected clip’s position before translating it into offsets, then verify the interpretation against Wowza’s Java example.
The example’s endpoint is a custom provider such as http://[wowza-ip-address]:1935/converter, not the REST store action route. It is intended for developers who compile the example with the Wowza IDE and enable it in Engine’s virtual-host configuration. This makes Java offsets useful where that provider is already suitable, but it is more involved than issuing the documented REST operation.
There are two operational details to preserve. First, the Java article says conversion settings for a store can be cached for up to 30 minutes. A second request with changed parameters may reuse the previous settings, so use the example’s cache-expire operation when you need a fresh conversion after changing them. Second, for version-archive storage, Wowza says to use the base stream name rather than a version-specific suffix so that all versions are included. Check the Java API conversion example for the provider commands and conditions.
Run the export and verify the MP4
For REST, submit the PUT request to the single-store /actions/convert path with only the boundary scheme you selected. The guide’s example returns a success message indicating that conversion started. That response confirms that the request was accepted to start work; it is not itself proof that the final file is complete or playable. Use the available store conversion status and inspect the output once conversion has finished.
The REST reference describes a default output directory based on the application’s StorageDir; it also documents options for naming output and conversion behaviour. Confirm the actual output location and filename in your installation rather than assuming a local example’s paths. If you are converting an ABR group, the guide uses the /dvrstores/actions/convert route with a comma-separated dvrConverterStoreList parameter. That group request is a different scope from converting one named store, so ensure the list contains the intended stores.
For Java, use the provider’s documented conversion and status commands, and expire cached settings when appropriate. Keep a record of which route, store, time basis, and exact parameter values you used. That small record is helpful when an export must be repeated or when a later request appears to use old settings.
After the file appears, check that it opens as MP4 and that both picture and sound are present where expected. Compare the beginning and end against the intended content, not just the nominal duration shown by the request. The source documentation describes a tolerance option in newer Engine versions that can allow conversion to run past a specified duration while applying the last nDVR GOP; it does not establish frame-accurate cuts for every store. If the final seconds include an extra section or the opening is missing, review the selected time basis, store span, and converter options before requesting another export.
If the MP4 is then part of a YouTube playlist stream, treat file preparation and live-stream operation as separate jobs. Our article on converting videos for 24/7 YouTube streaming in HandBrake addresses compatibility of prepared videos; it is not a substitute for validating the Wowza export itself.
Troubleshoot boundary and parameter errors
Start with the request shape. A REST request that includes dvrConverterDuration together with a start or end boundary violates the documented parameter rule. Remove duration or remove the boundary fields so the request expresses one selection method. For a failed single-store request, check each path component and verify that the named store exists in the selected application and instance.
Next check units and reference points. A Unix timestamp is not a count of milliseconds from the store start. A REST duration is not an absolute UTC instant. A Java startoffset is measured from the store beginning, while endoffset is measured from its end. Many confusing failures start with a plausible number used in the wrong field, so label every value with both its unit and its origin before sending the request.
If a clip appears shifted relative to a real event, determine whether the request used UTC or DVR time. UTC reflects approximate packet arrival at the nDVR module and is not an exact encoder send time. DVR time excludes gaps under the documented conditions. Compare the requested range to the store’s reported UTC and DVR boundaries, and choose the basis that matches the task rather than converting between them casually.
If a Java request appears to ignore updated offsets or options, consider the conversion cache described in the example and expire it before retrying. If a REST option is rejected or behaves differently, verify the Engine version and build: the REST guide, Java example, and API reference have different minimum version notes. The interleave-delay setting, for instance, is documented as available from Engine 4.7.0.01, enabled by default at 100 ms, and adjustable from 0 to 2000 ms; higher values can increase conversion time while reducing storage I/O saturation. Those versioned settings should not be copied into an older deployment without checking support.
Finally, distinguish recording failure from conversion failure. If the desired interval is outside the store’s recorded boundaries, no converter parameter can create the absent footage. Check source continuity and the recorded store range first, then retry only when the store and request parameters are correct. If your broader workflow is an unattended YouTube channel, remote monitoring for a 24/7 nature stream covers a separate operational concern: noticing when a live source stops.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
Can the REST API take start and end values in milliseconds?
The REST converter’s default start and end parameters are UTC Unix timestamps, not millisecond offsets from the store. REST duration is a separate parameter measured in milliseconds, and it cannot be combined with start or end. If you choose DVR time explicitly, confirm the requested basis and values against Wowza’s documentation.
Are Java offsets the same as REST duration?
No. Java uses startoffset from the beginning of the store and endoffset from the end, both in milliseconds. REST duration is a single duration value in milliseconds; matching units do not make the reference points or parameter meanings interchangeable.
Does conversion recover a period that was not recorded?
No. The converter exports material available in an nDVR store. Check the store’s recorded boundaries and source continuity before requesting a clip; a gap or unrecorded interval cannot be filled by changing the export request.
Why did a Java conversion keep using old settings?
The Java example documents conversion settings cached for up to 30 minutes. When parameters change for the same store, use its expire command as documented, then request and verify the new conversion.