¿AVC incompatibilities with AVI?

[Rober2D2]

Hi I'd like to know if there are any incompatibilities in AVI container when using an AVC codec. I already read the topic from Bond about b-frames HERE (http://forum.doom9.org/showthread.php?s=&threadid=80430), but I'd like to know if there are any other issues.

Are there any similar problems with OGM?

[Sharktooth]

backward and forward reference frames for example...

[bond]

i actually wrote a list about the the downsides of the "vfw mode" of mkv and its actually exactly the same for avc-in-avi and also .ogm

have a look here (http://forum.doom9.org/showthread.php?p=701951#post701951)

[Sirber]

So using CLI is the way to go?

[bond]

of course

[Tommy Carrot]

AVC is exactly as incompatible with avi as ASP (xvid or divx) was. The problem is the same in both cases: b-frame delay. Not many people used xvid in CLI form, although it had exactly the same issues with vfw, so i simply don't see why it became such a big problem with x264.

Of course the CLI solution is more elegant, i just hope that VFW support will remain in the codec for a long time, because encoding and editing is much simpler with it.

[Revgen]

Of course the CLI solution is more elegant, i just hope that VFW support will remain in the codec for a long time, because encoding and editing is much simpler with it.

Thats true, but MeGUI is starting to change that. Hopefully Doom9 can turn the preview window into a fully functional cut and edit window a la Virtual Dub.

[bond]

AVC is exactly as incompatible with avi as ASP (xvid or divx) was. The problem is the same in both cases: b-frame delay. Not many people used xvid in CLI form, although it had exactly the same issues with vfw, so i simply don't see why it became such a big problem with x264not true, there are more issues with avc than with asp (eg arbitrary frame orders)

also there are issues which were workaround in asp but are not with avc (missing frames for example)

you should read the post i linked to and tell me that its the same for asp...

[Doom9]

well, I tried but BeSweet cannot handle avs input, plus the ac3source avisynth plugin is rather limited. And with separate cuttings, things would quickly go asynch, would they not?

[Tommy Carrot]

not true, there are more issues with avc than with asp (eg arbitrary frame orders)Arbitrary frame order is a typical example for a feature which will be used almost nowhere, except in the reference encoder. :D If you mean b-pyramid, the problem remains the same, just a bit bigger (+1 frame delay).
also there are issues which were workaround in asp but are not with avc (missing frames for example)I'm not really an expert in this topic, so i may be wrong, but i would think that the same workaround would work with AVC codecs too, it just should be applied on them.

[bond]

Arbitrary frame order is a typical example for a feature which will be used almost nowhere, except in the reference encoder. :D If you mean b-pyramid, the problem remains the same, just a bit bigger (+1 frame delay).arbitrary frame order is just another word for b-pyramid and i think it makes indeed sense to use it

if people want a 80ms delay for pal content in this case, well yeah, than they should go that way and use vfw and avi

but its not fair to deny this or act like this doesnt suck, especially since perfectly working alternative solutions are existing


and you seem to ignore the interoperability argument.
it might be nice that x264vfw works together with ffdshow, but thats it

[Tommy Carrot]

I'm the first to admit that cli is the more elegant solution, i'm just saying that VFW is perfectly usable despite its flaws, because these flaws are no real concern during normal usage, the workarounds hide them from the user. Imo vfw still has its place, it offers simplicity, flexibility and a standard interface for wide usability, and there are people like me who don't need the advanced features and "correctness" of the cli method, we just want to get the best quality we can. :)

[MeteorRain]

if you want to get the best quality, it's easy.

but if you want to get the best quality at the same size, then CLI is your best choice.
advanced features can help you get smaller filesize at the same quality, or say, get better quality at the same size.

[Tommy Carrot]

No, they have identical quality, in advanced features i meant MP4 or MKV container, and as i said, i don't need them. :D

[bond]

No, they have identical quality, in advanced features i meant MP4 or MKV container, and as i said, i don't need them. :Dwell define "the same quality"
does loosing some frames mean its still the same quality? :p

[Tommy Carrot]

Ok, i can accept that it can bother some people, but if i could live with this problem with xvid, why should it suddenly bother me with x264? In my opinion it's not that big deal, definitely not worth to hassle with CLI, especially if i don't need the advanced containers (avi is better for my purposes for editability reasons).

[bond]

if you can live with the issues of placing avc in avi its of course ok, but stop spreading the word that there are no issues or that the issues are the same as with asp, cause its not true...

[Tommy Carrot]

Ok, if you stop spreading the word that vfw is completely useless, and should die soon. :p

My point is that it still has its place, and perfectly usable if you can live with the flaws of it, which have negligible influence to the usability and quality anyway. If it's important to you to do it correctly, then of course use cli.

[MeteorRain]

well define "the same quality"
does loosing some frames mean its still the same quality? :p
if they can be played the same, i'll think they are the same quality.

or say, loose some frames won't hurt the quality, then they are the same quality.

[bond]

Ok, if you stop spreading the word that vfw is completely useless, and should die soon. :phey i never said its useless! ;)
but ok the only reason why it shouldnt die soon is the existance of virtualdub ;)

My point is that it still has its place, and perfectly usable if you can live with the flaws of it, which have negligible influence to the usability and quality anyway.well thats your personal opinion, for me for example this isnt true.

take the following example:
in my encodes i use 3 b-frames and b-pyramid, which imho makes absolutely sense

this means if i use x264vfw and .avi:
- i will have 3 frames less in my output stream than in my input
- i will have a delay of 200ms

thats not acceptable imho, especially as its totally easy to use x264cli, eg via the various excellent guis, like megui

[Isochroma]

I agree with bond that native H.264 in Matroska is the way to go. I use this format only for my releases. After testing in comparison to creating the stream using x264 vfw, the playback CPU usage is FAR higher when playing the vfw-encoded file, than H.264 native in MKV.

Probably due to my relatively slow Athlon XP 2500+ running on single-channel DDR333 (PC3200 underclocked, mobo doesn't support 400), the vfw-version stutters while the native version does not.

vfw is growing more and more useless as MPEG-4 standards implement more advanced features that transcend the limitations of the vfw architecture. Continuing to use this format will hobble the abilities of any ASP or AVC MPEG-4 codec.

Progress means moving from the stage of "horseless carriage" - ie. an old standard retrofitted with new technology - to the real "motorcar", ie. the new standard inside its native support infrastructure.

[stephanV]

I agree with bond that native H.264 in Matroska is the way to go. I use this format only for my releases. After testing in comparison to creating the stream using x264 vfw, the playback CPU usage is FAR higher when playing the vfw-encoded file, than H.264 native in MKV.

There's no need to make things worse than they are. :)

Two benchmarks of mplayer, one avi created with x264vfw r287 and one mkv created with x264cli r287. (source and settings were the same of course)

AVIMPlayer dev-CVS-050824-14:01-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium M Banias (Family: 6, Stepping: 5)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2


Playing D:\benchmark\x264-cpu-test.avi.
AVI file format detected.
AVI_NI: No audio stream found -> no sound.
AVI: No audio stream found -> no sound.
VIDEO: [H264] 624x352 12bpp 29.970 fps 780.9 kbps (95.3 kbyte/s)
VIDEO: [H264] 624x352 12bpp 29.970 fps 780.9 kbps (95.3 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm:ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 624 x 352 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is undefined - no prescaling applied.
VO: [null] 624x352 => 624x352 Planar YV12
V: 578.3 17331/17331 26% 0% 0.0% 0 0

BENCHMARKs: VC: 155.973s VO: 0.090s A: 0.000s Sys: 5.519s = 161.582s
BENCHMARK%: VC: 96.5287% VO: 0.0557% A: 0.0000% Sys: 3.4156% = 100.0000%

MatroskaMPlayer dev-CVS-050824-14:01-3.4.2 (C) 2000-2005 MPlayer Team
CPU: Intel Pentium M Banias (Family: 6, Stepping: 5)
Detected cache-line size is 64 bytes
CPUflags: MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 0 SSE2: 0
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2


Playing D:\benchmark\x264-cpu-test.mkv.
[mkv] Track ID 1: video (V_MPEG4/ISO/AVC), -vid 0
[mkv] Will play video track 1
[mkv] No audio track found/wanted.
Matroska file format detected.
VIDEO: [avc1] 624x352 24bpp 29.970 fps 0.0 kbps ( 0.0 kbyte/s)
==========================================================================
Opening video decoder: [ffmpeg] FFmpeg's libavcodec codec family
Selected video codec: [ffh264] vfm:ffmpeg (FFmpeg H.264)
==========================================================================
Audio: no sound
Starting playback...
VDec: vo config request - 624 x 352 (preferred csp: Planar YV12)
VDec: using Planar YV12 as output csp (no 0)
Movie-Aspect is 1.77:1 - prescaling to correct movie aspect.
VO: [null] 624x352 => 624x352 Planar YV12
V: 578.2 17329/17329 20% 0% 0.0% 0 0

BENCHMARKs: VC: 155.032s VO: 0.080s A: 0.000s Sys: 6.560s = 161.672s
BENCHMARK%: VC: 95.8929% VO: 0.0495% A: 0.0000% Sys: 4.0576% = 100.0000%

Seems to be decoding at the same speed to me. I'd suggest checking your playback filters.

[edit]On a side note: i see now that the mkv output module in x264cli might have dropped 3 frames (was b-frame setting)... time to check some stuff out. : :)

[dude051]

I have to ask. Are the same problems seen in x264vfw -to- avi inherent in x264cli -to- avi ?

I ask this because of two reasons. 1. I have not experienced any of the said problems when encoding a RAW x264 stream with x264cli, and using AVC2AVI to put in the AVI container... which I then use to mux into MKV (the MKV hacks for the CLI still seem too buggy for me.) 2. Using AVC in mp4 gives me gas. After muxing into the MKV container, TCMP doesn't like the final result and doesnt reconize any streams but the audio. This forces me to download the haali splitter (no offence, but i dont like it too much.), which doesnt work all the time for me. As of yet, I see no problems with the way im creating my content, which is: X264CLI Raw x264 muxed into AVI w/AVI2AVC and then muxed with Audio and Subs in MKVToolNix with the MKV container.

So in short, are there underlying problems that I am not catching because of the way im going about this?

P.S. - And no, I won't use the VFW version. I've been using the CLI since the start (mainly because in the beginning it had advanced features to offer that VFW didnt have), and have grown accustomed to it. Also, VDub + x264VFW gives my computer even more gas. It still has some issues where it doesnt finish and quits at 99%. Since i've used the CLI all these problems went away.. so i'd rather stay away from VFW at all cost.

[stephanV]

Yes, the problems are the same. The problem is not even really VFW, but it is AVI. MTX doesn't contain any raw h264 parsing code yet, which would be necessary to mux h264-in-AVI properly in Matroska. But it would be more helpful if you stopped saying things are buggy, don't work and give you gas and told what actually is wrong with mkv output in the CLI, Haali's splitter, etc., etc. I have been using all these things for quite some time without problems.

You do know that MTX doesnt officialy support muxing h264 in VFW mode any more right? (which is happens when you use AVI anyway, whether its from CLI or VFW).

But by all means, if this works for you, keep doing it this way. :)

[dude051]

Sorry if I wasn't clear about the buggy parts of those programs.

For one, i've found the resulting output in MKV to sometimes not work for me. Using either spliter I can't get the MKV produced to open on either of my machines here. If I do get it to work though, I have some sync issues. Using vfr, and it seems i've read here and other places that the MKV output might have the same issues as when converting to the AVI container. This would explain some of my sync issues messing up my entire vfr process (although I haven't noticed any issues with my current way of making the video.. wierd :( ). This is why I use the raw x264 format now.

For two, about Haali's Matroska Splitter. I just didn't word my sentence right. When using AVC in the MP4 container, and muxing to MKV, I have to download the Haali slpitter to properly split it. When I do this though, I loose fuctionality in both core media player and mpc to chage any streams. Although I am aware this is not a "bug" in Haali's splitter, it's more of a compatibility issue with the players, I don't like it.

Like you said though, as long as it's working I see no reason as of yet to change. The day I'll be happy though is when MKVToolNiX supports the raw x264 stream :sly:

[MeteorRain]

hum......

i encode videos to x264-in-mp4, and mux them into mkv with mkvtoolnix, and use mpc to split the mkv. everything works fine. the internal mkv splitter in mpc works perfectly.

hum......

that's what happens on my computer :o

[Teegedeck]

Using vfr, and it seems i've read here and other places that the MKV output might have the same issues as when converting to the AVI container. This would explain some of my sync issues messing up my entire vfr process Well, you cannot have vfr in AVI, so that explains that. MP4 muxing tools neither supports VFR, yet, to my knowledge. MKV is the only working solution as of now.

For two, about Haali's Matroska Splitter. I just didn't word my sentence right. When using AVC in the MP4 container, and muxing to MKV, I have to download the Haali slpitter to properly split it. When I do this though, I loose fuctionality in both core media player and mpc to chage any streams. Although I am aware this is not a "bug" in Haali's splitter, it's more of a compatibility issue with the players, I don't like it.??? For MPC, right click into the picture, choose 'filters', choose the Haali splitter, choose the stream. Voila.

Like you said though, as long as it's working I see no reason as of yet to change. The day I'll be happy though is when MKVToolNiX supports the raw x264 stream :sly:Err; doesn't it? I'm not sure, thought it would. I don't keep track of mkvmerge's development that closely.

And no, raw x264 (with b-pyramid)-->AVI is not working; see the beginning of this thread. You could as well use the vfw version of x264 if you insist on using AVI.

[dude051]

Well, you cannot have vfr in AVI, so that explains that. MP4 muxing tools neither supports VFR, yet, to my knowledge. MKV is the only working solution as of now.
Yes this is true. But I create a 30fps video file and using a time codes file to essentially drop frames i create the vfr mkv. What I meant by me saying that, was that if it was true that frames were being droped per-b-frame because of using the AVI container, that should mess up my VFR process. Because my time codes file does not reflect those changes. I encode using b-prymid and b-frame reference frames, 2 b-frames.

??? For MPC, right click into the picture, choose 'filters', choose the Haali splitter, choose the stream. Voila.
I don't have that option for some reason. I've uninstalled all codecs, splitters and players and reinstalled from the beginning with no luck. I have yet to find a way to fix it.

Err; doesn't it? I'm not sure, thought it would. I don't keep track of mkvmerge's development that closely.
Like I said, "I wish" it supported it. I know for a fact that it does not. It has though been discussed in this forum, but there was a question to its legality as to what the parsing routine was under license wise (weather it was GPL or not). As seen Here (http://forum.doom9.org/showthread.php?t=99105&highlight=avc+mkv)

As for the VFW, i've had problem with the VFW playing nicely with VDub, as I stated earlier. I like MeGUI though, and plan to stay with it.

And I did read about the b-prymid at the beginning of this thread. That is why i first posted because I was worried, mainly because I hadn't noticed any problems though. Interesting as it is, why can't the official matroska splitter split MP4 AVC's? MPC can split it with its internal splitter as MeteorRain said. But if I use another player it doesn't work (like TCMP). :confused: I would say maybe it's just my system, but others have this problem too.

[Teegedeck]

That's curious, too. Haali's splitter does work with AVC MP4s on my PC.