[prev in list] [next in list] [prev in thread] [next in thread]
List: helix-server-dev
Subject: Re: [Helix-server-dev] fast channel switching question
From: Jamie Gordon <jgordon () real ! com>
Date: 2009-04-07 18:52:32
Message-ID: 49DBA0F0.1040201 () real ! com
[Download RAW message or body]
On 3/27/2009 11:28 AM, Rick Wager wrote:
> Thank you very much Jamie!
>
> We have used many different tools to get the video characteristics,
> particularly the average bit rate for a media file. They all seem to
> give slightly different answers with regards to average bit rate... Is
> there one particular tool or technique you can recommend to verify the
> compatibility of media files? One method we've used is to use the actual
> Helix server via a sdpgen URL and analyzing the returned sdp file to see
> what Helix server thinks are the average bit rates.
>
Most reliable to check what the server thinks they are will be to use
sdpgen to get the server to generate an SDP for each file and see what
it says the average bitrate is. You can then also compare all the other
characteristics in the SDP to see what does not match.
> Does the value set for config.ChannelSwitching.AvgBitRateThreshold in
> fast channel switching have any effect? We've set it based on perusal of
> the publicly available source and it doesn't seem to do anything.
>
I believe this should work. It should be an integer percentage, e.g.
"20" would be 20%.
> You mention the next release will likely relax some of the restrictions.
> Do you mean as in the 12.1 release?
>
Yep!
> Below are dumps from MediaInfo for Windows, version 0.7.8 for two files
> which we attempt to stream in order using FCS. We would really
> appreciate if you could point out what it is about these files that
> makes them incompatible - we think they match on all characteristics you
> mention but Helix rejects them - 274 incompatible.
>
From this they do look like they should switch okay from #1 to #2, but
possibly not from #2 to #1. (This is because the video stream lists
"Nominal BitRate" which I am guessing may be the max bitrate. The server
will not switch to a file with a higher max bitrate than what we told
the client, and #1 has a higher "Nominal BitRate" than #2.)
> Thanks in advance for any additional guidance you can offer.
It might help to file a bug report with Support if you can, and include
some sample content which doesn't switch. You can also attach content
here, but filing a bug report will also get the 'official' ball rolling
on it.
Thanks,
Jamie
> Rick
>
> *File 1:*
>
> General
> Complete name : 1.3gp
> Format : 3gs6
> Codec ID : 3gs6
> File size : 255 KiB
> Duration : 15s 325ms
> Overall bit rate : 136 Kbps
> Encoded date : UTC 2009-03-26 18:02:23
> Tagged date : UTC 2009-03-26 18:02:23
>
> Video
> Format : MPEG-4 Visual
> Format profile : Simple@L3
> Format settings, BVOP : Yes
> Format settings, QPel : No
> Format settings, GMC : No warppoints
> Format settings, Matrix : Default
> Codec ID : 20
> Duration : 15s 325ms
> Bit rate mode : Constant
> Bit rate : 90.2 Kbps
> Nominal bit rate : 82.0 Kbps
> Width : 480 pixels
> Height : 288 pixels
> Display aspect ratio : 1.667
> Frame rate mode : Variable
> Frame rate : 12.724 fps
> Minimum frame rate : 2.985 fps
> Maximum frame rate : 14.925 fps
> Resolution : 24 bits
> Scan type : Progressive
> Bits/(Pixel*Frame) : 0.051
> Stream size : 169 KiB (66%)
> Encoded date : UTC 2009-03-26 18:02:23
> Tagged date : UTC 2009-03-26 18:02:23
>
> Audio
> Format : AAC
> Format/Info : Advanced Audio Codec
> Format version : Version 4
> Format profile : LC
> Format settings, SBR : Yes
> Format settings, PS : No
> Codec ID : 40
> Duration : 15s 325ms
> Bit rate mode : Constant
> Bit rate : 28.0 Kbps
> Channel(s) : 1 channel
> Channel positions : C
> Sampling rate : 44.1 KHz
> Resolution : 16 bits
> Stream size : 52.4 KiB (21%)
> Encoded date : UTC 2009-03-26 18:02:23
> Tagged date : UTC 2009-03-26 18:02:23
>
>
> *File 2:
> *
> General
> Complete name : 2.3gp
> Format : 3gs6
> Codec ID : 3gs6
> File size : 1.73 MiB
> Duration : 1mn 54s
> Overall bit rate : 128 Kbps
> Encoded date : UTC 2009-03-22 16:53:38
> Tagged date : UTC 2009-03-22 16:53:38
>
> Video
> Format : MPEG-4 Visual
> Format profile : Simple@L3
> Format settings, BVOP : Yes
> Format settings, QPel : No
> Format settings, GMC : No warppoints
> Format settings, Matrix : Default
> Codec ID : 20
> Duration : 1mn 54s
> Bit rate mode : Constant
> Bit rate : 83.3 Kbps
> Nominal bit rate : 82.0 Kbps
> Width : 480 pixels
> Height : 288 pixels
> Display aspect ratio : 1.667
> Frame rate mode : Variable
> Frame rate : 13.642 fps
> Minimum frame rate : 2.035 fps
> Maximum frame rate : 14.925 fps
> Resolution : 24 bits
> Scan type : Progressive
> Bits/(Pixel*Frame) : 0.044
> Stream size : 1.13 MiB (65%)
> Encoded date : UTC 2009-03-22 16:53:38
> Tagged date : UTC 2009-03-22 16:53:38
>
> Audio
> Format : AAC
> Format/Info : Advanced Audio Codec
> Format version : Version 4
> Format profile : LC
> Format settings, SBR : Yes
> Format settings, PS : No
> Codec ID : 40
> Duration : 1mn 54s
> Bit rate mode : Constant
> Bit rate : 28.0 Kbps
> Channel(s) : 1 channel
> Channel positions : C
> Sampling rate : 44.1 KHz
> Resolution : 16 bits
> Stream size : 390 KiB (22%)
> Encoded date : UTC 2009-03-22 16:53:38
> Tagged date : UTC 2009-03-22 16:53:38
>
>
> Jamie Gordon wrote:
>> The main thing you need to be sure of is that you are using exact
>> same encoding parameters on all the encodes. You might want to use
>> constant bitrate encoding rather than VBR to ensure that the average
>> bitrates are close enough to be switchable. All critical encoding
>> parameters must match precisely - codec (of course!), sample rate,
>> video profile, audio object type, video frame size. MP4V average
>> bitrate needs to be within 10% of the original clip played. You don't
>> say what audio codec/packetization you are using, but with MP4V I am
>> guessing it is AAC-family. In 12.0, you need a very close match for AAC
>> audio, within 1%. With the next release the bitrate restrictions will
>> likely be relaxed.
>>
>> Thanks,
>> Jamie
>>
>> On 3/19/2009 7:01 PM, Rick Wager wrote:
>>> Hello,
>>>
>>> We're doing some work with the commercial Real Mobile server and fast
>>> channel switching - it seems to work really well. However, we're
>>> having problems with mpeg4 encoded videos and we've been unable to
>>> get a clear answer via support channels. I'm hoping someone here can
>>> help.
>>>
>>> Basically, we are unable to transcode videos such that they are
>>> consistently compatible with each other for purposes of FCS. The
>>> frustrating thing is that we cannot get a clear answer on what makes
>>> videos compatible from support. We do not use Real Producer - and
>>> support is clear that we need to be but its a very difficult thing
>>> for us to change transcoding solutions right now. We'd like to, if
>>> at all possible, understand the server's criteria for FCS
>>> compatibility and tune our encodings to conform.
>>>
>>> Can anyone shed some light on what makes mpeg4 videos compatible with
>>> one another for FCS? Looking through the publicly available source
>>> files gives hints - such as references to the average bit rate
>>> threshold. Not sure if that is really relevant or not, though.
>>>
>>> Thanks!
>>> Rick
>>>
>>> _______________________________________________
>>> Helix-server-dev mailing list
>>> Helix-server-dev@helixcommunity.org
>>> http://lists.helixcommunity.org/mailman/listinfo/helix-server-dev
>>
_______________________________________________
Helix-server-dev mailing list
Helix-server-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/helix-server-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic