How was the content encoded? I think the problem could be the keyframe interval - the buffer size should be set to 2x that interval.
Besides, all the bitrates from the MBR content should have keyframes at the same intervals for the switching to work correctly.
For debugging, you can use your SMP debug page or this page:
Thanks for the debug player link. Is there a way I can check keyframe info from this player link? I got this file from someone else, so don't know how was it encoded.
Tried, flvtool2.. which isn't returning any keyframe info to me.
$ flvtool2 -sP test.flv
Checked using avidemux its at every 2 secs. So buffer size should be 4sec - where do i set this?
Oh ok, checked params it was already 4, other params I checked in the demo page are -
dynamicStreamSwitching = false;
trying changing them the same way - &dynamicStreamBufferTime=4&autoDynamicStreamSwitch=true but it isn't changing
What is default download ratio or any other criteria for stream to switch?
The initial bitrate is set after the latest bitrate in a MBR file that you played.
There are several rules for stream switching, I will not detail them here since they're pretty complex. You should correctly set the bitrates in the f4m file in kbps, the rules rely on those values.
You can see the switching beginning and end events in the log on the debug page.
If you verified that each link works by itself (not in the f4m file), you can check the MBR information in the debug page and watch for switching events in the log pane.
I assume you read how the HD indicator works http://sourceforge.net/adobe/smp/wiki/HD%20Indicator/
cool, how do I enable autoDynamicStreamSwitch here?
what does dynamicStreamSwitching=false here means?
I can check which bitrate fragment is playing by monitoring fragment requests, so I know its always lowest bitrate playing for me right now.
I just see this event :
3. Tue Dec 7 2010 11:04:22 AM [EVENT] StrobeMediaPlayback org.osmf.events::MediaPlayerCapabilityChangeEvent (enabled:true type:isDynamicStreamChange )No other events related to stream switch.--Vishal
It is active by default (autoDynamicStreamSwitch=true). The other property is rather unknown by the SMP .
Do you see stream switching in the default example: http://osmf.org/dev/1.5gm/debug.html ?
What information do you have in debug, under Dynamic Streaming Info section?
For default debug player too I don't see any stream switching. Also autoDynamicStreamSwitch=false in debug log, you sure its true by default?
6. Tue Dec 7 2010 11:33:45 AM [DEBUG] StrobeMediaPlayback 11:33:45 GMT+0530>>> NetStreamSwitchManager.autoSwitch() - setting to false
For default debug player - (http://osmf.org/dev/1.5gm/debug.html),
PlaybackOptimizationMetrics averageDownloadBytesPerSecond 313848.15 averageDownloadKbps 2451.94 averageDroppedFPS 0 averagePlaybackBytesPerSecond 50377.67 averagePlaybackKbps 393.58 currentIndex 0 downloadRatio 6.23 droppedFPS 0 duration 653.85 maxAllowedIndex 0 maxFPS 25.40 updateInterval 100 Dynamic Streaming Info index 0 numDynamicStreams 5 currentBitrate 408 previousSwitchDuration NaN totalSwitchDuration 0 dsSwitchEventCount 0 avgSwitchDuration NaN currentVerticalResolution 428 bestVerticalResolution 720 bestHorizontatalResolution 1280 targetBitrate NaN targetIndex 0
I see this too, you sure its true by default?
StrobeMediaPlayer audioPan 0 autoDynamicStreamSwitch false
For the video I'm playing - here is the info -
PlaybackOptimizationMetrics averageDownloadBytesPerSecond 232177.5 averageDownloadKbps 1857.42 averageDroppedFPS 0 averagePlaybackBytesPerSecond 38017.74 averagePlaybackKbps 297.01 currentIndex 0 downloadRatio 2.89 droppedFPS 0 duration 1182.01 maxAllowedIndex 0 maxFPS 32.79 updateInterval 100 Dynamic Streaming Info index 0 numDynamicStreams 2 currentBitrate 300 previousSwitchDuration NaN totalSwitchDuration 0 dsSwitchEventCount 0 avgSwitchDuration NaN currentVerticalResolution 360 bestVerticalResolution 0 bestHorizontatalResolution 0 targetBitrate NaN targetIndex 0
The autoswitching should be true by default. I think this might be an injection. We're investigating it and we'll give you an answer soon.
You seem to have hit one of the bugs we deferred last sprint, you will be able to track it here: http://bugs.adobe.com/jira/browse/ST-366.
Initially, we thought it was in another area.
Thank you for signalling it to us. If you will find another potential issue, you could raise it directly in the bugtracker for a faster response.