分享

DivFix Support

 arm_embed 2012-11-27
For submit/view bug reports, feature requests, patch files and support requests, please follow this link.
   
   You can also create and update Translations. Please look at WiKi pages.



    DivFix++ initially checks for "AVI LIST" identifier. Because it couldn't convert a zip file to avi file of course :)
Than copy all headers to target file (to the "movi" chunk) and scan 00dc, 01wb and 00db chunks in avi file. It counts them and copies correct frames to target file sequentially. It also generates "index" table by this process. After reaching "idx1" chunk or end of file, it merges index table with target file. After this it adjust headers some variables and some chunks "size"s. If there are missing frames (of course there are missing frames if you use this program :) ) avi, stream and OpenDML headers frame counts will be corrupt (different than actual frame counts.) It makes errors/bugs at scanning avi file. They must be corrected. Movie size will shrink if you want to cut out bad parts from AVI. Because of this AVI size, "movi" chunk size and index part's location will be change. A program has to be adjust all of this variables...




        RIFF means "Resource Interchange File Format".
It has a basic structure. "ID,Size,Chunk"
This "chunk" could be recursive, means chunk could be a RIFF structure too.
This makes things little complex...

A standard AVI file is close to this format:

RIFF "size" AVI
    LIST "size"
        hdrl avih "size=56" ...
    LIST "size"
        strl strh "size" ...
             strf "size" ...
             JUNK "size" ...
    LIST "size"
        strl strh "size" ...
             strf "size" ...
             JUNK "size" ...
    LIST "size"
        odml dmlh "size" ...
    LIST "size" ...
        INFO ISFT "size" ...
        JUNK "size" ...
    LIST "size" movi
        01wb "size" ...
        00dc "size" ...
        00db "size" ...
        ....
        ....
        ....
    idx1 "size"
        01wb "key" "location" "size"
        00dc "key" "location" "size"
        00db "key" "location" "size"
    JUNK "size" ...

    avih means avi header, strh means stream header, dmlh means OpenDML header. This headers also keeps total frame numbers of it's data.
avih keeps total visual frame count, strh for video data keeps same number, OpenDML header too. But strh for audio keeps audio frame count...

... denotes there is data
"size" fields are 4 byte integer. Corresponds chunks size.
"key"  fields are to indicate that frame is key frame or not..
"location" fields are 4 byte relative location number. It's relative to "movi" chunk start.

    JUNK chunks are for give information about movie. They all ignored from avi players...
Last JUNK chunk is standing for complete avi file to "2048" byte and it's powers. This because for CD ROM can easily access file. (I don't know why engineers make it like this. It's totally crap but world is full of them... If you remove last chunk, your file has no injuries AFAIK...)

For fixing an avi file, you have to convert current source file to this structure.

    本站是提供个人知识管理的网络存储空间,所有内容均由用户发布,不代表本站观点。请注意甄别内容中的联系方式、诱导购买等信息,谨防诈骗。如发现有害或侵权内容,请点击一键举报。
    转藏 分享 献花(0

    0条评论

    发表

    请遵守用户 评论公约

    类似文章 更多