Results 1 to 3 of 3

Thread: Packetization of multiple transcodes

  1. #1
    Join Date
    May 2013

    Default Packetization of multiple transcodes

    We are using the Transcoder to create multiple bitrate renditions of source streams, and packetizing the streams into HLS, as a stream name group/master m3u8 playlist. The transcode profiles are the source stream using PassThru, several downscaled video transcodes with PassThru audio, and an audio-only with disabled video and PassThru audio. This gets us a multi-bitrate stream usable across devices and network conditions, and compliant with Apple mobile requirements.

    What we've noticed however, is that there is inconsistency in the packetization between the source, video transcodes, and audio streams. The effect is seen in two metrics: the length of each segment (ts file), and the number of segments generated. In a given chunklist m3u8 there is a media sequence, representing the number of segments that had been generated prior to the current sliding window. This will be different between the 3 sets of transcodes. In addition, the duration of each corresponding segment across renditions will be different.

    This is causing issues in our players when they try to switch renditions, as switching to a segment of a different rendition that has the same overall sequence of the current segment of the current rendition, will provide frames from a significantly offset point in the stream.

    So that is the issue. Here is my theory on what is happening:
    The transcoded streams are keyframe-aligned between each other, but not with the source stream. Since the stream is packetized by splitting at keyframes, any discrepancy forces a discrepancy in split points, and thus differing segment lengths and therefore differing numbers of segments.
    Also, the audio-only stream must not be packetized with any regard to other streams in the same name group, and (having no keyframe requirements) is thus is split at more precise segment lengths, which is also different from the source or transcoded streams.

    Assuming the above theory is correct, is there anything that can be done to solve this issue? Can transcodes be forced to align their keyframes with the source stream? Can an audio-only transcode be forced to split its segments at the same place as its sibling streams?

    We could do an actual transcode from source to source-equivalent resolution and bitrate. That would probably force proper keyframe alignment, and we could then ignore the actual source stream. However, that it is both lossy and resource inefficient to re-encode the same stream so we would like to avoid it if possible.

    I'm not sure how to address the audio-only stream's packetization though.

  2. #2


    If you are using the source stream as the high quality rendition in your ABR set, you might choose to exclude the source from the set, and encode the high quality rendition along with the rest of the set to eliminate the unaligned keyframe issue.
    One other check would be to make sure you are using:

    You can create a stream name group for Apple HLS streaming with an audio-only rendition as described in How to create Apple App Store compliant streams. If you do this, add a <MediaListRendition> element to the stream name group with a <WowzaAudioOnly> element set to true. The following is an example:

  3. #3
    Join Date
    May 2013


    Yes, I have Video/KeyFrameInterval/FollowSource set to true for all encodes in the transcode template. This doesn't seem to do what it claims - as in, as described above the keyframes in the encoded streams don't actually follow the source. What is this property intended to do?

    As far as re-transcoding to an equivalent quality as the source stream, yes as I mentioned that is an option that would solve the keyframe+packetization issue, but if there is a way to not have to resort to that, I would be interested. Since, as I mentioned, that introduces a slight loss of quality as well as increased computational requirements.

    As far as the audio-only, yes I remember using the MediaListRendition approach when first setting up the Transcoder, and something about the way it ended up presenting the playlists was suboptimal, but I will investigate that method again.

    I just tried the WowzaAudioOnly approach and realized what the problem was when I tried this before - whatever encode is used as the "source" with the audio-only option applied to it (i.e. the "160p" in your example), will pass through its codec info in the master playlist. For example, our lowest resolution is 234p, and the master playlist looks like this using WowzaAudioOnly based on that encode:
    Notice that the last rendition is supposed to be the audio-only, and in fact if that URL is requested it will be an audio-only HLS stream, however it is listed with a 416x234 resolution and avc1 codec. This causes problems for our players which depend on the codec information to properly interpret the multi-bitrate stream.

    So, is there any way to have segment-synced audio that presents correctly in the master playlist?
    Last edited by johnsterling; 01-10-2014 at 12:42 PM.

Similar Threads

  1. Is h.264 rtp packetization-mode of 2 supported?
    By jhlee1th in forum Live Streaming and Encoders
    Replies: 3
    Last Post: 05-07-2014, 09:10 PM
  2. Multiple live transcodes
    By cdpearce in forum AddOn: Transcoder
    Replies: 2
    Last Post: 10-21-2011, 11:46 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts