Selur
spamming old Newbie
Dabei seit: 13.03.2002
Beiträge: 10.933
 |
|
| Divx3.11 => Mpeg4 ISO (ohne Verluste) |
     |
Was man machen muss ist das Programm wie folgt aufrufen:
| code: |
1:
2:
|
ffmpeg -i inputdivx3.avi -vcodec mpeg4 -acodec copy -mstomp4 outputmpeg4.avi |
|
Was dann gemacht wird ist eine verlustfreie Umwandlung des Videostreams von DivX3.11
nach Mpeg4 ISO. => man bekäme alte Encodes ISO kompatibel.
Was bond bis dato dazu schreibt:
| Zitat: |
i also talked to him and here is a brief summary of the tool up to now given to me by him:
- it's a hack which passes quantized coeffs, mb types and vectors from the msmpeg4 decoder to the mpeg4 encoder directly
- it works for most msmpeg4v3 files, often with only a 3% size penalty
- it converts about 80% of the msmpeg4v3 videos he tried perfectly, but he can't figure out what's wrong with the rest
- all nandub rips seem to convert fine
- there are still bugs (some files fail to convert, it's no faster than a regular re-encode, mmx must be disabled, etc.)
- on some problem samples, it looks like certain inter frames aren't having their intra blocks copied properly
- it's almost as if certain blocks are being decoded differently for no apparent reason
- it all looks ok in terms of mb types, coeffs, etc.
- the problems only happen with files he doesnt know how they have been created
- it doesnt seem to be related to old nandub versions, as he, in order to do the conversion, stepped through every line of code that was involved, and there weren't any different workarounds being invoked between files that worked and didn't work
- if you tried "ffmpeg input.avi output.avi" it was fine (albeit re-encoded lossily), but if you tried "ffmpeg -mstomp4 input.avi output.avi" the decoded mb types, vectors and coeffs are the same as before, but it is displayed differently (-mstomp4 tells ffmpeg that the conversion will be lossless. without it ffmpeg does a regular decode->encode)
- one thing he hasn't done is decode the original and the buggy converted streams side-by-side and check that way
- he suspects that there's something ffmpeg is doing that he hasn't noticed till now
my findings till now:
- i tried decoding a problem sample myself with various decoders (ffdshow, 3ivx, xvid, divx5) in both the divx3 and mpeg-4 version and the used decoder shows no difference for the output
- maybe this has nothing to say but when i compressed a divx3.avi and the correctly converted resulting mpeg4.avi of it with winzip i got a 1% additional winzip compression
when i compressed a divx3.avi and the not correctly converted resulting mpeg4.avi of, winzip compressed the mpeg4.avi with 7%, which is pretty high i think?
- trying to place the resulting mpeg-4.avi to .mp4 via mp4box works fine (mp4box doesnt handle importing divx3 streams with "uncorrect" mpeg-4 fourccs!), still of course the distortions are still there. also mp4box detects a not existing audio stream, one time mpeg-1 (with the working sample), another time mpeg-2 (with the not working sample), which it never did before, maybe the .avi writing is not 100% correct? |
etwaige News dazu und das Tool gibt's bei:
http://forum.doom9.org/showthread.php?s=&threadid=85229
Auch wenn es noch bei manchen Encodes Probleme macht, ist es sicher eine ziemlich coole Sache.
Cu Selur
__________________
Hybrid
|
|
