Re: [TIProtocol-askcisco] TIP Encoder Setting issue (Teliris)

[Aravind S. <ara...@te...>]

Hi David
Thank you....We will investigate and fix this...

as ever,
much appreciative

Aravind Sethuraman
Chief Software Architect
Teliris, Inc.
55 Broadway, 14th Floor, New York, NY 10006
C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869


On 09/21/2011 04:24 PM, David Benham (dbenham) wrote:
>
> Aravind
>
> What the logs indicate to us is;
>
> - 26 out of 17956 NALs where bad, perhaps because they were larger 
> than 3320 (item 10).
>
> - inter-frame RTP timestamp increments do not show as a multiple of 
> 3003 or 3000 (item 5)
>
>    (log entry at 2011-09-19 15:53:30.271: shows rtp timestamp diff 
> detected 6300).
>
> - The TIP negotiation status indicates your endpoint (the TIP peer) 
> supports LTRP (item 13) and GDR (item 14), but none were received of 
> either (you said "ignored," so you should probably negotiate those off).
>
> What the logs cannot tell us is your encoder is adhering to items 8, 9 
> and 11, which are required by our decoder.
>
> *From:*Aravind Sethuraman [mailto:ara...@te...]
> *Sent:* Wednesday, September 21, 2011 10:25 AM
> *To:* Aravind Sethuraman
> *Cc:* David Benham (dbenham); Girish Kondappa; 
> tip...@li...
> *Subject:* Re: TIP Encoder Setting issue (Teliris)
>
> Hi David and TIPers @ cisco
>
> any further update on the decode logs?
>
> Aravind Sethuraman
> Chief Software Architect
> Teliris, Inc.
> 55 Broadway, 14th Floor, New York, NY 10006
> C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869
>
>
> On 09/19/2011 01:29 PM, Aravind Sethuraman wrote:
>
> Folks
>
> Sorry for the delay in getting the logs back to you as i was off in 
> conference
> attached is the video logs generated from the CTS 1000 whilst in call...
>
> http://db.tt/hz6ocbL
>
>
> Hopefully you guys will be able to provided us further insight into 
> the quality issue
>
>
> On Sep 8, 2011, at 11:00 PM, David Benham (dbenham) wrote:
>
>
>
> Hello Aravind
>
> From a quick, cursory analysis of what you said/described, it seems 
> that at least #9, 10 and 11 are probably being not being adhered to by 
> the encoder ... and thus need find a way to enable those restrictions.
>
> Could you pull a copy the CTS' CMA logs and send back to us (or 
> provide a link to a drop box we can fetch them from)?
>
> *From:*Aravind Sethuraman [mailto:ara...@te...]
> *Sent:*Tuesday, September 06, 2011 8:08 AM
> *Cc:*David Benham (dbenham);tip...@li... 
> <mailto:tip...@li...>; Girish Kondappa
> *Subject:*TIP Encoder Setting issue
>
> Hi David et al @ cisco tip,
>
> We have been trying to interop our TIP Client with a CTS 1000 and 
> whilst we are able to make calls from our TIP Client to CTS 1000m we 
> are seeing quality issue in the CTS decode. The CTS video is getting 
> decoded fine in our TIP Client. So we are wondering if CTS 1000 is 
> extremly strict and we are missing out some encoder settings.
>
>
> If possible,Please share the encoder settings that could troubleshoot 
> the problem.
>
>
> We are referring  1.6b profile to set the settings in our encoder and 
> support the following wrt the encoding standard
>
>
> 1. MUST generate H264 Main Profile or High Profile (HiP), if 
> negotiated, compatible bit stream :*Using MAIN PROFILE*
>
> 2. MUST support CALVC
>
> 3. MAY support CABAC as a negotiated option*Using CABAC*
>
> 4. MUST support 1280x720 or 1920x1080 resolution*Using 1280x720*
>
> 5. MUST support fixed frame rate: 30 fps or 29.97 fps*Configured to 
> use 30fps*
>
> 6. MUST generate one macro block-row per slice
>
> -1280x720: 45 slices per frame, each slice must be 80 macro blocks in 
> length*Using 45 * 80*
>
> -1920x1072: 67 slices per frame, each slice must be 120 macro blocks 
> in length
>
> 7. MUST support deblocking_filter_control_present = 1 & 
> disable_deblocking_filter_idc = 1Added
>
> 8. MUST only use inter-prediction blocks of size 16x16*Couldn't find 
> this setting in our encoder*
>
> 9. MUST only use one reference picture and that reference picture must 
> be the immediate previous frame or a long term reference 
> picture*Couldn't find this setting in our encoder*
>
> 10. Each NAL MUST be less than 3320 bytes in size*Couldn't find this 
> setting in our encoder*
>
> 11. POC (Picture Order Count) MUST increment by 2 every frame*Couldn't 
> find this setting in our encoder*
>
> 12. MUST NOT USE SPS IDs in the range of 10 to 20*Uses 0*
>
> 13. Long term reference pictures (LTRPs) MAY be used for error 
> concealment. LTRPs requires max_num_ref_frames>=3. LTRPs use H.264 
> standard picture buffer management. MUST support long_term_frame_idx < 
> 2, MUST use memory_management_control_operation = 6. LTRPs are 
> optional and can be disabled.Ignored
>
> 14. Gradual decoder refresh pictures (GDRs) MAY be used at the start 
> of a sequence instead of an instantaneous decoder refresh picture 
> (IDR). A recovery point SEI precedes the GDR. The SEI always has the 
> broken_link_flag set to 0. GDRs are optional and can be disabled.Ignored
>
> 15. When high profile is negotiated, MUST support 
> seq_scaling_matrix_present_flag=0 and 
> pic_scaling_matrix_present_flag=0, MUST NOT use monochrome pictures, 
> MUST NOT use quantization matrices.Ignored
>
> Observations:
>
> 1.When we use GOP length > 1 We see poor jitter status in the CTS and 
> the video is bad.
>
> 2.We always see the black strip exactly at 2/3 from the top in the 
> screen. And Sometimes we have seen this strip slice  catching up 
> late.. But most of the time it remains black...
>
> It looks like CTS Decoder is expecting specific AVC bit stream that 
> our encoder is not able to send..
>
> There are few settings above ignored and some couldn't configure in 
> our encoder. Is that is causing the quality issue?
> Also, is it possible to provide a guidance as to how we can debug on 
> the CTS side for video quality issue?
>
> regards
>
>
> Aravind Sethuraman
> Chief Software Architect
> Teliris, Inc.
> 55 Broadway, 14th Floor, New York, NY 10006
> C +1.917.355.0119 | O +1.212.490.1065 x1408 | F +1.212.269.2869
>