mpeg4vol - tool to decrypt the vol

[yakima]

mpegip has a new tool (cvs as of now) that decrypts the vol - it seems to work nicely, can even take a vol (string of hex) as input, recognizes userdata .... it should build (after some fiddling) on both w32 and osx.

--- big delete edit ---
there seems to be a minor bug in mpeg4vol preventing xvid vols from being read o.k., should be fixed soon.

[bond]

nice

as i understand it its not directly related to container stuff. i move it to the codec forum

[yakima]

well, no problem, though the usual input would be mp4 ... but of course you can hex any vol for an input ...

[bond]

thanks to rjamorim this tool can now be found on rarewares (http://www.rarewares.org/mp4.html)!

i also tested this tool little bit more now and found the following issues:
- test streams encoded with the 3ivx and ffvfw encoder, caused an "abnormal program termination" error message
- on divx5 and nerodigital streams it didnt display the userdata, altough its there of course
- there are two possibilites of userdata in xvid:
a) with packed bitstream - the bitstream description looks like DivX999b000p XviD00029 (two fields used) - mpeg4vol only displays the divx one
b) without packed bitstream - only XviD00029 is used by xvid - mpeg4vol shows the "abnormal termination" message

moved back to the container forum

[Stux]

test streams encoded with the 3ivx and ffvfw encoder, caused an "abnormal program termination" error message

sounds like the vol parsing in this tool is buggy then

[yakima]

yep, it is not perfect. but i did test xvid/divx files some time ago, and the output seemed pretty much reliable (reading a vol manually really is a pain ..); 2 problems did occur:
- userdata was not always/fully displayed (mpeg4vol doesn't look in all places)
- abnormal termination (or: abort in macosx) if that marker for the next start code isn't recognized (or the vol wasn't read to the end or the vol was incomplete)

@ bond: could you verify that for 3ivx/ffvfw? (i have a 3ivx here, but that one works right)

still, i think this is a valid tool if you want to take a look at the vol of your mp4s.
don't be scared by "abnormal program termination" - for the files/vols i have seen it just means: "unexpected end of vol"

edit:
i forgot to add: the version at rarewares was build from mpeg4ip 1.0 (plus a little fix for the bug mentioned in the first post); i don't know if there are changes in 1.1, didn't have time to look at that yet.

[bond]

Originally posted by yakima
- userdata was not always/fully displayed (mpeg4vol doesn't look in all places)yep with xvid files with packed bitstreams it didnt display it fully
would be great if mpeg4vol could be updated to look everywhere cause this would be very usefull for finding out which codec was used to encode the video stream in a mp4 :)

- abnormal termination (or: abort in macosx) if that marker for the next start code isn't recognized (or the vol wasn't read to the end or the vol was incomplete)
don't be scared by "abnormal program termination" - for the files/vols i have seen it just means: "unexpected end of vol"hm in all cases i wrote that i got "abnormal term." mpeg4vol didnt output anything else but this error message :(

[yakima]

hm, that seems odd - it doesn't even say "decoding vol ..."?
in any case, this doesn't seem to happen with all xvid (029, not packed) & 3ivx streams as the ones i got give an output ...

[bond]

Originally posted by yakima
hm, that seems odd - it doesn't even say "decoding vol ..."?nope :(

in any case, this doesn't seem to happen with all xvid (029, not packed) & 3ivx streams as the ones i got give an output ... yep seems so, at least it doesnt depend on the used mp4 muxer, tried both mp4box and 3ivx with the same results

[yakima]

so it seems mpeg4vol doesn't find the vol in these files - if it would find anything, it would first give that "decoding ..." msg. - strange. you might want to contact bill may about that & maybe hint at that userdata thing cause as you say, it would and should be a handy tool.

[bond]

hm it seems adding "> vol.txt" to the commandline to print the info in an external .txt is not a good idea

without this
ffvfw and xvid (without packed bitstream and without b-frames at all) works correctly (userdata including codec info is displayed)
3ivx works too but the codec info userdata doesnt get displayed

so to sum it up the problems i have here are:
- 3ivx, divx5 and nero digital doesnt show the codec description info
- xvid with packed bistream only displays the half codec info (as described above)
- printing the results to an external .txt sometimes causes an termination without any results

[yakima]

do i get this right: the print to file was the problem? well, that's relieving.
so i guess what we still need is:
-correct userdata info
-checking for correct next startcode marker
and maybe:
-allow different input formats (m4v, avi, mkv, ogm ..)?

[bond]

Originally posted by yakima
do i get this right: the print to file was the problem?yep :)
i wonder why it causes problems

[yakima]

yeah, strange it is.

[bond]

ok according to bill may he fixed the bitstream info issues in the cvs, now we only need a new compile :D

[yakima]

i just compiled it from cvs and did some quick tests - i only got one file where the userdata wasn't read right, which is a xvid packed bitstream. here at least there is no change, it still only prints the divx999 string.
@ bond: are you sure this is in cvs already?

btw.: taking a vol string instead of a file as input seems only to work in macosx, not in win2k

[bond]

seems bill may didnt commit the sources to cvs till now, but who knows maybe a new compile is already on its way to roberto ;)

[yakima]

mpeg4ip 1.1 is out, there are two fixes that might be of interest:
- mpeg4vol problems seem fixed (at least the ones i could test: no more termination on xvid userdata)
- mp4creator has some workaround for their userdata handling; userdata now seems to be put at the very beginning of the mp4, so no more "MP4ERROR" due to userdata (however, there are some vols that will still produce that error) - so after all the userdata is not deleted
windows binaries should be up at rarewares shortly.

[bond]

Originally posted by yakima
windows binaries should be up at rarewares shortly.hopefully, roberto seems to be busy, he had the updated mpeg4vol binary for a week now :(

[bond]

hm it seems that mpeg4vol (1.1) has problems reading out the profile set by divx5
it seems to work with all codecs (xvid, 3ivx, nd, ffvfw) but not with divx5. i tried muxing with mp4box, mp4ui and 3ivx (with 3ivx always sp@l1 gets hardcoded always so its not really usable for testing this)

can anyone confirm this? is this a known problem?

[yakima]

what do you mean? any divx5? and does it abort or is it just ignored?

[bond]

it displays "No Video Object Sequence" (which includes the profile/level indication)

[Stux]

There might not be a VOS ;)

[bond]

well mp4box detects the profile/level of divx5 streams...

[yakima]

well, are you sure mp4box doesn't just write some vosh/vo if none is found just as 3ivx does? have you checked to see if there is one? at least older divx encodes didn't have it, i am not sure about newer ones ...

[bond]

Originally posted by yakima
have you checked to see if there is one?hm no, i assumed its there as mp4ui and mp4box report the same pl afaik and remembering the problems the tool had with xvid...

but well, maybe its really not there :D