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 _______________________________________________ ffmpeg-user mailing list [email protected] http://ffmpeg.org/mailman/listinfo/ffmpeg-user
