Bug in H264 decode buffer size

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, 19 May 2014 12:15:04 -0400, Bill Gardner wrote:
> [...]
> PJSIP uses the largest possible frame supported by the H264 profile 
> level which also has 3/2 aspect ratio, in multiples of 16 pixels (the 
> H264 macroblock size). See function find_highest_res() in 
> vid_codec_util.c. So at level 3.0 PJSIP allocates a 768x512 frame, 
> exactly 3/2 aspect ratio. PJSIP can resize dynamically, but only to 
> smaller frame sizes. So when 4CIF comes in at 704x576 (which is a 
> slightly larger image but still supported by level 3.0) PJSIP can't 
> decode the video and emits error messages. Fortunately an easy 
> workaround is to set the profile level to 3.1 and then PJSIP allocates a 
> pretty huge frame for decoding.


Just curious, where does this imposed 3/2 aspect ratio come from?

(Has it indirectly anything to do with the default 720x480 at 15 for h264
in PJSIP as in ffmpeg_vid_codecs.c?)


If  "ITU-T H.264 Appendix A.3.1 e), f), g)"  is the proper document then
level 3.0 (max image size in macroblocks = 1620) should support frame
sizes (in pixels) something like from

    640 x 640  (quadratic)
to
    1808 x 16  (most "nonquadratic")

according to the size constraints specified there?

Does SIP/SDP pose additional restrictions?


P.S. Would anything change if the other endpoint reduces offered fps?

    Eeri Kask




[Index of Archives]     [Asterisk Users]     [Asterisk App Development]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [Linux API]
  Powered by Linux