Junk chunk size calculation

[maestro777]

Hi, I'm currently writing my diploma thesis.
It's about cutting OpenDML AVI Files in Java.
However, my question is:

how can i calculate the size of JUNK chunks in an AVI File?

May the field PaddingGranularity help in that case?

Here's a part of the avi's structure in xml-representation (I've written a tool, that extracts the metadata to a xml file).

<RIFF_AVI>
          Pos: 0
          id: RIFF whole chunk-length: 1884630016
          content length: 1884630008
          Format: AVI
          <LIST_hdrl>
                     Pos: 12 
                     id: LIST 
                     whole chunk-length: 17112 
                     content length: 17104
                     List-chunk-type: hdrl
                     
                     <_avih_chunk>
                                  Pos: 24 
                                  id: avih 
                                  whole chunk-length: 64 
                                  content length: 56 
                                  chunk has subchunks: false 
                                  MicroSecPerFrame: 40000 
                                  MaxBytesPerSec: 3788800 
                                  PaddingGranularity: 512 
                                  Flags: AVIF_HASINDEX, AVIF_MUSTUSEINDEX, 
                                  TotalFrames: 12514 
                                  InitialFrames: 0 
                                  Streams: 1 
                                  SuggestedBufferSize: 151552 
                                  Width: 720 Height: 576 Scale: 0 Rate: 0 
                                  Start: 0 Length: 0
                      </_avih_chunk>
                      <LIST_strl/>
                                  Pos: 88 
                                  id: LIST 
                                  whole chunk-length: 16720 
                                  content length: 16712
                                  .
                                  SOME OTHER CHUNKS
                                  .
                      </LIST_strl>
                      <_vprp_chunk>
                                   Pos: 16808 
                                   id: vprp 
                                   whole chunk-length: 48 
                                   content length: 40 
                      </_vprp_chunk>

                      <LIST_odml>
                                 Pos: 16856
                                 id: LIST 
                                 whole chunk-length: 268 
                                 content length: 260
                      </LIST_odml>
          </LIST_hdrl>
          <LIST_INFO>
                     Pos: 17124 
                     id: LIST 
                     whole chunk-length: 44
                     content length: 36 
          </LIST_INFO>
          <_JUNK_chunk>
                       Pos: 17168 
                       id: JUNK 
                       whole chunk-length: 48356 
                       content length: 48348 
                       chunk has subchunks: false
          </_JUNK_chunk>
          <LIST_movi>
                     Pos: 65524 
                     id: LIST
                     whole chunk-length: 1884363788 
                     content length: 1884363780 
                     List-chunk-type: movi
                     .
                     .
                     .
          </LIST_movi>
          <idx1_chunk>
                       AviIndexChunkPos: 1884429312 
                       id: idx1 
                       whole chunk-length: 200232 
                       content length: 200224
          </idx1_chunk>
          <_JUNK_chunk>
                       Pos: 1884629544 
                       id: JUNK 
                       whole chunk-length: 472 
                       content length: 464
          </_JUNK_chunk>
</RIFF_AVI>

[jagabo]

how can i calculate the size of JUNK chunks in an AVI File?

Isn't it the same as every other chunk in an AVI file? You have a 4 byte identifier ("JUNK"), a four byte length field (little endian), and then data of the length indicated by the length field. The full chunk is therefore the 4 + 4 + length.

[maestro777]

@ jagabo: Thanks for the quick reply, but what I intetially mean is a bit different:

One of the JUNK chunks in my example has the following structure:

<_JUNK_chunk>
Pos: 1884629544
id: JUNK
whole chunk-length: 472
content length: 464
</_JUNK_chunk>

It is on position 1884629544 and has the size 472, but why? Why doesn't it have a different size?
There must be a mathematical formula, how the encoding algorithm places the JUNK chunks.
I know, that this JUNKS are used for alignment, but on what bounds?
In this case the JUNK causes a block size of: POS + JUNKSIZE = 1884629544 + 472 = 1884630016 byte.
In this case the blocksize / PaddingGranularity = 1884630016 / 512 = 3680918 -> fills the blocksize to next 512 package, but o the other JUNK in my example:

<_JUNK_chunk>
Pos: 17168
id: JUNK
whole chunk-length: 48356
content length: 48348
chunk has subchunks: false
</_JUNK_chunk>
Blocksize is: POS + JUNKSIZE = 17168 + 48356 = 65524
But 65524/512 = 127,9765625 -> does not fit any blocksize! So why was this chunk placed on that position with this size?

[Cornucopia]

I don't program much, but I though [POS] just meant starting position. If true, it would have no bearing on the blocksize. Only the [JUNKSIZE] should.

So,
472 / 512 (mod) = 1 block
48356 / 512 (mod) = 95 blocks

Correct me if I'm wrong.

Scott

[maestro777]

I don't program much, but I though [POS] just meant starting position. If true, it would have no bearing on the blocksize. Only the [JUNKSIZE] should.

So,
472 / 512 (mod) = 1 block
48356 / 512 (mod) = 95 blocks

Correct me if I'm wrong.

Scott

In my opinion, JUNK chunks are only added, if the creator of the video (the encoder) wants the previous written data to align on a certain block size, so the position is important, I think.

In my last example there was 17168 bytes (chunks + data) written to the file and the encoder added on position 17168 a JUNK chunk of size: 48356 to achieve, that the next chunk begins on position: 65524

And I don't understand, why on that position? The size of that JUNK chunk makes to me no sense!

[jagabo]

I think the reason for the size of the first JUNK chunk was to align the first subchunk in the movi chunk on a block boundary (12 more bytes would put it in the right place, 65536). I just examined several AVI file and they all start the movi chunk on a 512 byte block boundary, not the subchunks.

I don't know if PaddingGranularity defines the block size. I believe 2048 is used a lot because that's the sector size used on CD/DVD.

[maestro777]

@jagabo: Thanks for your reply.
I think, that I have the reason!
The size of the LIST('movi') chunk's fields is 12 byte (4 byte fourCC, 4 byte size, 4 byte type)! 65524 + 12 = 65536. In that way the subchunks of the movi chunk are aligned on that offset. But why 65536? Ok thats 2^16, but why this data is aligned on that size?
There's no info in the header, that says, that the block should be 65536 bytes long, correct me if I'm wrong.
This information is for me very important, because I'm developing an algorithm, that soft-cuts an I-Frame-only avi-file by predicting the positions of each frame in the file (without using index chunks (except of the superindex)), and these JUNK chunks are a thorn in my side !

[vhelp]

@ maestro777

A while back, I made an experimental avi writer tool (just saved an RGB bitmap to an RAW
avi container for simplicity sake) to see and understand how they are put together. I can
say, I still am confused in some aspects. But, I did find a few things out in my searching.

For one, I found that sometimes, the JUNK is used to as -- to write junk inside the AVI
container. I seen where *other* avi editors suites do this.. ie, ULead and a few others,
where they wrote their "signature" name inside the JUNK area, usually at the top. I think
this is usually understood as the "versioning" or branding aspects.

And, two, sometimes we don't know *why* a given avi editor will include a JUNK inside
an avi file it creates. I wrote several [x,y] demension RGB -> AVI in VirtualDub-MPEG2
and seen it write JUNK -- from 8x8 to 64x64 to 352x480, etc. So, we may never know
for sure *why* they do, but they do -- possibly for their own propriatory purposes.

-vhelp 4322

[maestro777]

@vhelp thank you for your answer.
Looks like, I have to find a different way for my cutting-strategy.
In my test video, the JUNK chunks don't have any metadata, only zero-values.