Wowza Community

DASH Segment Generation Issue


I searched the forums, but I didn’t find any thread about this, I’m sorry if I missed something. If this is the wrong place to post this, could you please move it to the correct location? :slight_smile:

I am experiencing weird behavior when trying to stream VOD DASH content - at one point in time the get request for the next segment simply fails with 404 error code, it seems the requested segment does not exist???

I’m running the dashif JS player ( with some changes to the adaptive quality selection (but it’s the same with the original version).

With each of the streams available in that list things work just fine, so the player seems to be alright.

Therefore, it should to be a problem with the content.

The smil for my videos is as follows

            <video src="mp4:BM240a.mp4" system-bitrate="250000"/>
            <video src="mp4:BM240b.mp4" system-bitrate="500000"/>
            <video src="mp4:BM360a.mp4" system-bitrate="1000000"/>
            <video src="mp4:BM360b.mp4" system-bitrate="2000000"/>
            <video src="mp4:BM480a.mp4" system-bitrate="3000000"/>
            <video src="mp4:BM480b.mp4" system-bitrate="4000000"/>
            <video src="mp4:BM720a.mp4" system-bitrate="5000000"/>
            <video src="mp4:BM720b.mp4" system-bitrate="6000000"/>
	    <video src="mp4:BM1080a.mp4" system-bitrate="7000000"/>
	    <video src="mp4:BM1080b.mp4" system-bitrate="8000000"/>			

Wowza Server is running on one PC in my home network while the Client is running on another PC in the very same network.

With that setup I am able to play Smooth Streaming, HLS and Flash HTTP VOD streams without any issues, but DASH at one point fails with the mentioned missing(?) chunk.

Here’s a screenshot of that failing get request in Chrome’s Network Records: (Funny point in time for failure :))

It has been the same in multiple tests, always fails at one point.

What’s puzzling, however, is that the lower qualities up to and including

Content was encoded with ffmpeg as follows (if that helps)

:: Settings for video encoding with ffmpeg
:: frameRate
set fR=24
:: GOP size 
set GOP=120
::240p set
ffmpeg -y -i %inputFile% -s 426x240 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 250k -threads 64 BM240a.mp4
ffmpeg -y -i %inputFile% -s 426x240 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 500k -threads 64 BM240b.mp4
::360p set
ffmpeg -y -i %inputFile% -s 640x360 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 1000k -threads 64 BM360a.mp4
ffmpeg -y -i %inputFile% -s 640x360 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 2000k -threads 64 BM360b.mp4
::480p set
ffmpeg -y -i %inputFile% -s 854x480 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 3000k -threads 64 BM480a.mp4
ffmpeg -y -i %inputFile% -s 854x480 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 4000k -threads 64 BM480b.mp4
::720p set
ffmpeg -y -i %inputFile% -s 1280x720 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 5000k -threads 64 BM720a.mp4
ffmpeg -y -i %inputFile% -s 1280x720 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 6000k -threads 64 BM720b.mp4
::1080p set
ffmpeg -y -i %inputFile% -s 1920x1080 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 7000k -threads 4 BM1080a.mp4
ffmpeg -y -i %inputFile% -s 1920x1080 -y -strict experimental -an  -vcodec libx264 -vprofile baseline  -g %GOP% -r %fR% -b:v 8000k -threads 4 BM1080b.mp4

I’m using no audio portion, but that shouldn’t be a problem. It’s also the same for the same settings but WITH audio.

I also tried different vprofiles (specifically main and high), not setting the keyframe interval and also using " -force_key_frames expr:gte(t,n_forced*5) " to set keyframe inverals instead.

To no avail, all the same, it doesn’t work.

The other streaming solutions have no issues with the content, so there seems to be an issue with the dash chunking/segment generation?

MPEG Dash configuration is done as described here

It’s also working up to that one point of failure so it seems to be set-up right.

However, there’s obviously (hopefully?) something I’m missing, would be great if you have any ideas as to what is going on here.

If you need any further information, please let me know.

On a second note, I set

	<!-- Properties defined here will override any properties defined in conf/HTTPStreamers.xml for any HTTPStreamer loaded by this applications -->

in my Application.xml and it affected the segment lengths, it seems this is now a supported feature? However, chunksize is fluctuating quite heavily, some chunks get to be of 8s duration, which is quite a huge difference. What could be causing this?

(Removing this did not remove the first problem, btw.)

Hope we can figure this out…

Ciao :slight_smile:

Please see this article for encoding VOD:

How to encode video on demand content

Note: that the article explains “FFmpeg is a good option for encoding single videos (multi-bitrate encoding hasn’t worked using FFmpeg).”

You could try Expression 4 Encoder or similar Handbreak for example.


You can check whether keyframes are aligned properly by following this guide:

How to debug encoder multi-bitrate key frame alignment

Encoding keyframe aligned renditions with ffmpeg has been known to be problematic and unreliable.

However, I did come across a forum contribution that showed a successful approach for generating keyframe aligned multi-bitrate rendition for VOD with ffmpeg by doing multiple passes. This was done on Linux and I have not tested. It may not work on other platforms.

ffmpeg -y -i bigbuckbunny_1500.mp4 -c:a libfaac -ac 2 -ab 64k -c:v libx264 -preset:v veryfast -threads 0 -r 24 -g 48 -keyint_min 48 -sc_threshold 0 -x264opts no-mbtree:bframes=1 -pass 1 -b:v 286k -s 384x216 bigbuck-350k.mp4
ffmpeg -y -i bigbuckbunny_1500.mp4 -c:a libfaac -ac 2 -ab 64k -c:v libx264 -preset:v fast -threads 0 -r 24 -g 48 -keyint_min 48 -sc_threshold 0 -x264opts no-mbtree:bframes=1 -pass 2 -b:v 286k -s 384x216 bigbuck-350k.mp4
ffmpeg -y -i bigbuckbunny_1500.mp4 -c:a libfaac -ac 2 -ab 64k -c:v libx264 -preset:v fast -threads 0 -r 24 -g 48 -keyint_min 48 -sc_threshold 0 -x264opts no-mbtree:bframes=1 -pass 2 -b:v 836k -s 640x360 bigbuck-900k.mp4


Your welcome, glad I could help.


I had seen that article, but I thought this does no longer apply, as the other streamers seem to have no issues with the content?..

Thanks for the suggestions, I’ll try another encoder to see if that’s the cause :slight_smile:


thank you! From a first look the multi-pass approach seems to work so far, the player now gets to stream the entire video without failed requests at one point.

However, it seems that the resulting stream now takes longer to play than with the other streamers - it takes about 10:30 min for a roughly 10:00 min video (Big Buck Bunny) without any kind of bandwith limitations or the like, while the others make it at roughly the 10 minute mark.

But that might now be a player issue, I’ll have to see…

In any case, thanks so far!