mencoder AVI output problem

[namchik]

First of all, sorry for a probably offtop...
I've encoded a videoclip in VDMod with "x264 - H264/AVC encoder" and audio track from this clip - in Nero to HE AAC. Now there's a problem to put those two into one container (mp4, i suppose..)
I tried mp4box and mp4ui but no luck...
Can you advise me anything? Thanks.

[hellfred]

Originally posted by namchik
First of all, sorry for a probably offtop...
I've encoded a videoclip in VDMod with "x264 - H264/AVC encoder" and audio track from this clip - in Nero to HE AAC. Now there's a problem to put those two into one container (mp4, i suppose..)
I tried mp4box and mp4ui but no luck...
Can you advise me anything? Thanks.
There are some threads discussing this topic. And next to this forum is another forum called "New A/V Formats - Containers". There is a sticky post concerning the mp4 container and muxing to it.
See here (http://forum.doom9.org/showthread.php?s=&threadid=62723)
There is even a link to a guid.

Hellfred

[scorpdt]

1stly my gratitude to all concern.
2ndly my apology should this posting falls under the wrong thread, as I am not sure whether the problem lies with mencoder or x264 itself.

I did a full movie and the avi file does not play at all. I am using the latest mencoder CVS and rev 118 of X264.

When extracting the raw using avi2raw it reported 267908 written frames instead of 336873 frames which is the full movie.


D:\DEVDASSUB_SCN\VIDEO_TS>avi2raw S12.avi 12.264
avi2raw - mpeg4ip version 1.2.5
267908 video frames written


I include here the 2nd pass screen dump of the encoding. I am not sure whether the problem I am experiencing has to do with the RIFF chunk as the raw file extracted above with 267908 frames creates a .h264 file which is 1,042,161 KB.


D:\F_Drive\sex264>avs2yuv "D:\DEVDASSUB_SCN\VIDEO_TS\Swades1.avs" - | mencoder -
-ovc x264 -passlogfile "mencoder-2pass.log" -x264encopts pass=2:bitrate=940:fr
ameref=4:4x4mv -o "D:\DEVDASSUB_SCN\VIDEO_TS\S12.avi" -of avi -ffourcc x264
MEncoder dev-CVS-050201-21:40-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium 4/Xeon/Celeron Foster (Family: 8, Stepping: 4)
Detected cache-line size is 64 bytes
CPUflags: Type: 8 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2

81 audio & 192 video codecs
File not found: 'frameno.avi'
Failed to open frameno.avi
Reading from stdin...
success: format: 0 data: 0x0 - 0x0
D:\DEVDASSUB_SCN\VIDEO_TS\Swades1.avs: 704x272, 2997/100 fps, 336873 frames
YUV4MPEG2 file format detected.
YUV4MPEG2 Video stream 0 size: display: 704x272, codec: 704x272
VIDEO: [YV12] 704x272 12bpp 29.970 fps 0.0 kbps ( 0.0 kbyte/s)
[V] filefmt:12 fourcc:0x32315659 size:704x272 fps:29.97 ftime:=0.0334
Opening video filter: [expand osd=1]
Expand: -1 x -1, -1 ; -1 (-1=autodetect) osd: 1
==========================================================================
Opening video decoder: [raw] RAW Uncompressed Video
VDec: vo config request - 704 x 272 (preferred csp: Planar YV12)
Could not find matching colorspace - retrying with -vf scale...
Opening video filter: [scale]
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
SwScaler: using unscaled Planar YV12 -> Planar YV12 special converter
x264 [info]: no need for a SAR
x264 [info]: using cpu capabilities MMX MMXEXT SSE SSE2
Selected video codec: [rawyv12] vfm:raw (RAW YV12)
==========================================================================
Forcing output fourcc to 34363278 [x264]
Writing AVI header...
ODML: vprp aspect is 16384:6330.
ODML: vprp aspect is 16384:6330.
ODML: Starting new RIFF chunk at 1023MB. 0min 0mb A-V:0.000 [955:0]]
Pos:11240.3s 336873f ( 0%) 7fps Trem: 0min 0mb A-V:0.000 [941:0]
Flushing video frames

Writing AVI index...
Fixing AVI header...
ODML: vprp aspect is 16384:6330.

Video stream: 941.249 kbit/s (117656 bps) size: 1322495322 bytes 11240.341 s
ecs 336873 frames
x264 [info]: slice I:2965 Avg QP:20.74 Avg size: 20806
x264 [info]: slice P:333908 Avg QP:21.99 Avg size: 3771
x264 [info]: slice I Avg I4x4:74.1% I16x16:25.9%
x264 [info]: slice P Avg I4x4:1.8% I16x16:2.4% P:50.5% P8x8:6.5% PSKIP:38.
7%
x264 [info]: kb/s:940.0


Appreciate if someone could shed some light to the problem mentioned above.

Thanks in advance.
Scorpio

[akupenguin]

While I don't know anything specifically about avi2raw, I'm betting that it doesn't support ODML, and thus stops after reading the first RIFF chunk.
If you want just the raw H.264 stream, you can use "-of rawvideo" instead of "-of avi". If you want both an AVI and a raw, you can use "mencoder -ovc copy -of rawvideo S12.avi -o 12.264"

[bond]

Originally posted by akupenguin
While I don't know anything specifically about avi2raw, I'm betting that it doesn't support ODML, and thus stops after reading the first RIFF chunk.hm i tested avi2raw with shorter streams (~7000frames) and it always worked fine
scorpdt, make sure you use the latest cvs

how can i test whether an avi is odml?

[stephanV]

Originally posted by bond
how can i test whether an avi is odml?
Open it in AVIMux GUI and it should say right there. If necessary you could also use the riff chunk viewer of VirtualDub or AVImux gui.

[bond]

Originally posted by stephanV
Open it in AVIMux GUI and it should say right there.hm, 1.16x doesnt work here. 1.15x shows on all my files that they are "standard" (i assume this mean not odml)

still gspot tells me that the virtualdub encoded x264 files are "odml avi" (the mencoder ones "avi"), so i assume my tested files, which work with avi2raw, are odml

[stephanV]

all VirtualDub files under 2GB are standard. Gspot think they are ODML because of some redundant headers that VirtualDub doesnt remove. The structure of a VirtualDub file under 2GB, however, is that of a standard AVI. Any standard AVI parser would be able to read such a file.

This has been discussed with the GSpot developer once i think on this board, I dont know if he did anything about it.

[scorpdt]

Thanks akupenguin / bond,

Yes ... I am certain that I am using the latest CVS. This is my 1st attempt using mencoder. I used MeGUI to help generate the command line instruction for both the 1st and 2nd pass encoding.

Prior before this I was using GK 0.34.5.Beta and uses x264Rev115. I have no problem with the AVI file it creates .... muxing using MKVToolnix and mp4creator is not a problem at all.

I am not sure whether this problem with RIFF chunk has anything to do with mencoder perhaps Celtic can help advice the cause.

FYI, the Avi file failed on VDMod, failed on VLC, BSPlayer, MPC with latest ffdshow (20050402 Build) installed. The only consolation is that the raw file from avi2raw can still be mux using mp4creator but with a shorter runtime of 2hrs 29mins instead of 3hrs 07mins.

I attached here G-Spot info of S12.avi.
http://scorpio1.homeip.net:6970/images/S12-Gspot.gif

Once again thanks in advance.
Scorpio

[dragongodz]

Gspot think they are ODML because of some redundant headers that VirtualDub doesnt remove.
well it is picking up that Vdub is writing an opendml style header so its correct really. if you want a avi type 1.0 header you need to use the "save old format avi.." in Vdub.

The structure of a VirtualDub file under 2GB, however, is that of a standard AVI. Any standard AVI parser would be able to read such a file.
which is part of opendml avi compatability. in theory any avi parser is meant to be able to atleast parse the first chunk of an opendml avi no matter what the actual full file size. of course thats not always the case in reality. :)

i am curious how you expect Vdub to remove or change the header type while encoding though since the final size isnt know until the encoding is finished. do you expect it to reload and reparse the file ? of course if just streaming A/V then the final size should be known and if Avery wished he probably could have it auto set the different headers. he hasnt done that though and in general there should be no need. you do have the option as i said to save old style already.

[scorpdt]

Guys .... from the search on the net, the problem I mentioned above is related to mencoder. We need to include -noodml switch for avi files > 1GB.

I should have use "-of rawvideo" as suggested by our esteem member here. As always .... we learn new things everyday.

On another site (http://luniks.net/java/jtvd.do) .... they mentioned the same problem and provide an alternative to fix. It works with the avi file I have .... so my effort is not wasted.

mencoder -forceidx -noodml S12.avi -ovc copy -oac copy -o S12A.avi

Cheers!
Scorpio

[bond]

great it worked out :)

[stephanV]

Originally posted by dragongodz
well it is picking up that Vdub is writing an opendml style header so its correct really. if you want a avi type 1.0 header you need to use the "save old format avi.." in Vdub.


Not again...

http://forums.virtualdub.org/index.php?act=ST&f=6&t=8160&hl=omitted&

VirtualDub writes out AVI headers so that if the file is smaller than 2GB by the time it is finished, the OpenDML indices are omitted and the result is a standard AVI file.

Now you go tell Avery Lee that he doesnt know what his own program is doing. :)

The most important difference, between OpenDML and standard, is not in the file header but in the indices and the presence of a RIFF AVIX. Saying a file is OpenDML just because it has a ODML list in the main header is bit harsh. Also, consider the problem Akupenguin suggested:

I'm betting that it doesn't support ODML, and thus stops after reading the first RIFF chunk.

[dragongodz]

Now you go tell Avery Lee that he doesnt know what his own program is doing.
i have a better idea. why dont you actually read what i typed instead of trying to be smart.

The most important difference, between OpenDML and standard, is not in the file header but in the indices and the presence of a RIFF AVIX. Saying a file is OpenDML just because it has a ODML list in the main header is bit harsh.
importance is irrelevant to what you are bitching about. the fact is the initial header is different for opendml avi and avi type 1.0. that is what Gspot is picking up ,as i said, and this is not changed. so yes the file is 99.9% avi type 1.0(i never said it wasnt if you bother to reread) but if a program is just reading the intial header type then of course it will say its opendml because thats what the header says unless you "save with old avi format..".

Also, consider the problem Akupenguin suggested:
again why dont you go and reread what i said aswell. i specifically said if an avi parser doesnt support opendml it should still be able to read the first chunk, not the whole file. thats exactly what Akupenguin said, stopping after reading the first RIFF chunk.

Not again...
oh dont worry i wont waste any more time on someone who obviosly knows it all so well they dont have to actually read what people actually type.