Hi,
I’m currently using smooth streaming to deliver on demand content to STBs, found out a compatibility problem with certain videos recorded by mobile devices. (i.e.: Samsung Galaxy S4). The original video “original.mp4” does not play using wowza’s smooth streaming and also http progressive download does not work due to the moov atom being at the end of the file, using smooth streaming the STB loads the Manifest and then stalls. If I move the moov atom to the beginning of the file (using ffmpeg) (faststart.mp4) the STB plays the video flawlessly, but still fails when using using smooth streaming. We are currently looking for a way to get the video to play using smooth streamning.
I’ve attached the files.
I’ve noticed that the Manifest generated by the two files is similar.
I’ve tested with several other videos from various sources and all work great besides this video.
The difference between an OK video seems to be related with the length of the SPS/PPS (codec private data).
I’m using Wowza 3.6.4 build9641
OK video: https://dl.dropboxusercontent.com/u/182869306/wowza/ok.mp4
Original NOTOK video: https://dl.dropboxusercontent.com/u/182869306/wowza/original.mp4
Faststart NOTOK video: https://dl.dropboxusercontent.com/u/182869306/wowza/faststart.mp4
Thanks in advance!
Filipe
Filipe,
I don’t have your STB to test of course, but tested your original.mp4 in the Wowza Silverlight smooth player, and it does work there.l
Looking for anything that might be a problem, one thing you might look at is the profile level, frame-size and bitrate. It’s about 17mbs, large frame and Profile is High.
Video info: {H264CodecConfigInfo: codec:H264, profile:High, level:4.0, frameSize:1920x1080
Richard
Does the Wowza sample.mp4 play on the STB with smooth playback? If so, that points in the same direction: limitations on the STB client-side
Richard
Hi Richard,
That’s my guess for the time being, whilst the video plays well using http progressive download, it does not when using the STBs SmoothStreaming player. I understand that this may be a limitation on the client size since we are facing a high profile combined with large frame sizes and large bitrates. Ill have to devise some sort of testing know what might be the specific problem.
Thanks
Hi FBrunido,
I think that 'at could be caused by a Wowza inability to generate a standard valid CodecPrivateData parameter.
Not sure what you can do about it.
Add info:
Check this thread, e.g. ( VOD Adaptive Smooth Streaming Judder with Buffer at the end?)
Take a any PrivateCodecInfo
CodecPrivateData="00000001674d401f9656022026f2fff820001ffa84000003000400000300c981800186a000055733f18e30300030d40000aae67e31c3b4244a700000000168ea5352"
try to decode it according to the standard.
Standard:
QualityLevel Element and Attributes: The QualityLevel
http://msdn.microsoft.com/en-us/library/ff728116(v=vs.95).aspx
CodecPrivateData. [Required] Specifies the codec private data property of this video stream:
-
For H.264 MPEG4 Part15, the CodecPrivateData field must contain SPS and PPS, in the following form, base16-encoded: [start code][SPS][start code][PPS], where [start code] is the following four bytes: 0x00, 0x00, 0x00, 0x01.
In other words, you can just take the last part of the string after 00000001 and try to binary16 decode it.
In our example:
00000001674d401f9656022026f2fff820001ffa84000003000400000300c981800186a000055733f18e30300030d40000aae67e31c3b4244a700000000168ea5352
00000001674d401f9656022026f2fff820001ffa84000003000400000300c981800186a000055733f18e30300030d40000aae67e31c3b4244a700000000168ea5352
- Go here:
Online base16 decoder and encoder
http://online-calculators.appspot.com/base16/
-
Paste Online base16 decoder and encoder
-
Ouch Wowza