[FFmpeg-user] IMX50 NTSC framesize differs to the SMPTE 356M-2001 Standard - why?

[tim nicholson]

On 14/06/15 22:39, Christoph Gerstbauer wrote:
>>>> i seem to have missed this reply, my question is basicylly the same
>>>> as tims, where does the limit resulting in 39999920 come from ?
>>> Hi, I compared different encoder IMX40 formats, and all of these format
>>> has a pkt size of 166833bytes (=1 frame for IMX40).
>>> -> 166833*8*(30000/1001) = 39999920bits
>> Approximately!
>>
>>>> is there some specification that limits the VBV buffer size to a
>>>> lower value for "40mbit/sec" than "50mbit/sec" ?
>>> Maybe I didnt understand the using of the VBV buffer?
>>> I thought the VBV buffer size is always ONE frame. So it differs in size
>>> when using the 50, 40 or 30 mbit format. Is this wrong?
>> I think this is correct, I think Michael's question was slighly
>> confusing.
>>
>>> from SMPTE S356M - 2001 - Type D-10 Stream Specifications:
>>>
>>> " The vbv_delay parameter shall be constrained to a *1-frame* delay for
>>> each GOP by defining the following values:
>>>
>>> 525/60 systems
>>>
>>> – picture_header: vbv_delay = 0BBBh
>>>
>>> 625/50 systems
>>>
>>> – picture_header: vbv_delay = 0E10h"
>>>
>> But why does having a 1 frame delay, and therefore one frame buffer
>> which requires different buffer sizes for PAL and NTSC due to the frame
>> rate difference, require the bit rates to be different? The only reason
>> this is the case for the nominal 50M Operating point is because having
>> exactly 50M at 30000/1001 would lead to frames larger than the maximum
>> coded frame size. At lower bit rates this is not an issue.
>>
>> so buffer size = 40000000 x 1001/30000 = 1334667 (approx)
>>
>> Given the frame rates getting integer values all round is impossible and
>> even your figures contain rounding errors. So there will always be some
>> fudging somewhere. Quite how the coder copes with these slightly
>> incomatible constraints I am unclear.
>>
> Hello Tim,
> 
> I am now very confused about this issue, I didnt get your point.

You worked backwards from a defined frame size to derive an approxomate
bit rate that was not exactly 40M (and not exactly the figure you gave).
I was asking why not work forward from the exact bit rate to a dervived
frame size. Neither calculation will produce an a non integer result so
there will always be a conflict between specified/derived value
somewhere which the coder will have to resolve.

> 1.) Please can you tell me YOUR used syntaxes for IMX30/40/50  for PAL
> and NTSC? I want to compare it to mine.

Mine look remarkably similar to yours except for the ommission of 'ilme'
which makes no sense for an I frame only format.

I don't think I've ever  used 40M, we either use 50 or 30 but my
buffers/init_occupancy are 1200000 PAL and 1001000 NTSC at 30M

> I just want to find THE syntax for IMX50/40/30 D-10 MXFs for the ffmpeg
> encoding, so that it matches with the SMPTE D-10 standard paper.

The SMPTE paper is not specific on some of the details you are concerned
about, auch as exact frame size for 40M profile.

> 
> 2.) Furthermore: For IMX30 and 40 -> Do you think I can always use
> framebuffer size from the IMX50 format and no decoder will have a
> problem with that?

Not sure what you are asking, I use a frame buffer size comensurate with
the calculated size for 1 frame a given bit rate. This is different
therefore for each bit rate/frame rate

> [..]

-- 
Tim.
Key Fingerprint 38CF DB09 3ED0 F607 8B67 6CED 0C0B FC44 8B0B FC83