Weird prob with AVIs containing x264 video

[sneaker_ger]

Originally Posted by JimmyBarnes

Ones I tried then which claimed to be able to cut an any downstream (or maybe given) frame did so by recoding a small section around the cut frame.

If the inter-frames compression around that frame requires it that's a given. It's not possible otherwise.

[JimmyBarnes]

Originally Posted by sneaker_ger

If the inter-frames compression around that frame requires it that's a given. It's not possible otherwise.

Mainly referring to downstream cutting i.e. at the very end of a clip, where it should be no big deal to truncate frames from any given frame through to the end of the clip.

[JimmyBarnes]

OK, everything is always easier in hindsight...

Being a longtime WinXP x86 user who'd only recently upgraded to Win10 x64, I assumed that when 32- and 64-bit versions of a program were on offer, the 64-bit one should be used.

So when I originally installed x264vfw and it offered both 32- and 64-bit versions, I chose only the 64-bit one (I keep a log).

As sneaker_ger suggested, I reinstalled x264vfw, but this time both 32- and 64-bit versions.

Now VDubMod 1.5.10.2 opens AVI with x264 without problems, the video stream can be viewed, cut points nominated and the result saved using Direct Stream Copy - just as it used to do under WinXP.

Clearly VDM is a 32-bit prog which can't use 64-bit codecs.

Curiously VDFM still won't do Direct Stream Copy, but I don't need it now...

Thanks to everyone for their contributions.

[JimmyBarnes]

Originally Posted by sneaker_ger

Is the decoder component of x264vfw deactivated?

BTW What does deactivating the decoder actually do?

The default setting is enabled and normally I have always used it like that.

[Midzuki]

Originally Posted by mariush

.............

AVI is worse, it supports only 2 audio streams (good luck storing original audio and multiple commentary tracks in one avi file)

Speaking in the name of Alex Noe

Originally Posted by Alexander Noe

AVI can only handle 1 or 2 audio streams

Totally wrong. A few people who think to write container comparisons still believe this, or even write such disinformation in order to make up advantages of OGM that do not exist, although even the original AVI file specification supports 256 streams (no matter how many of them are audio or video), and although AVI-Mux GUI has been able to create AVI files with multiple audio streams for years

Originally Posted by mariush

and AVI should just die

After Ogg gets dead and incinerated, AVI may be killed soon afterwards

[nevcairiel]

The real reason AVI should not be used for an advanced codec like H.264 is that it just doesn't support B-Frames properly (as mariush said, even XVID already had this problem and they used even worse hacks to encode "packed B-Frames" in AVI), you don't get correct timestamps and decoders need to implement all sorts of hacks to somehow "guess" timestamps for H.264 in AVI (which sometimes works, but sometimes doesn't, resulting sync problems). The real question is why would you prefer AVI when you can use something much better suited to store H.264?

[sneaker_ger]

Originally Posted by JimmyBarnes

Mainly referring to downstream cutting i.e. at the very end of a clip, where it should be no big deal to truncate frames from any given frame through to the end of the clip.

You don't think it be like dis but it do. You cannot always arbitrarily cut H.264 even when setting end points on account of the re-ordering.

[shekh]

Originally Posted by nevcairiel

The real reason AVI should not be used for an advanced codec like H.264 is that it just doesn't support B-Frames properly (as mariush said, even XVID already had this problem and they used even worse hacks to encode "packed B-Frames" in AVI), you don't get correct timestamps and decoders need to implement all sorts of hacks to somehow "guess" timestamps for H.264 in AVI (which sometimes works, but sometimes doesn't, resulting sync problems). The real question is why would you prefer AVI when you can use something much better suited to store H.264?

here https://en.wikipedia.org/wiki/Compar...mats_supported
there is a footnote 41 "B-frames in an AVI file are a problem only for the ancient Video-for-Windows API, not for the AVI container itself."

I've no idea who wrote it, but do you think this article is wrong? Can you name usage case when h264 in avi is wrong, given that all the following is met:
* CFR
* encoding and decoding is done with something that knows what to do, e.g. ffmpeg.exe

asking because of curiosity.

[JimmyBarnes]

Originally Posted by sneaker_ger

You don't think it be like dis but it do. You cannot always arbitrarily cut H.264 even when setting end points on account of the re-ordering.

I must be extraordinarily lucky then, hundreds of blu-ray to AVi/x264 rips scrutinised carefully without visible problems. I should clearly go and buy a Lotto ticket...

[sneaker_ger]

Ignorance is a bliss

[JimmyBarnes]

Originally Posted by sneaker_ger

Ignorance is a bliss

You don't like empirical evidence, dogma rules..

[sneaker_ger]

If you cut through references you end up with stray/missing slices. That's just the way it is. So if softwares specifically designed to edit H.264 re-encode on such cut points you can assume they do it for a good reason. If VirtualDub that was designed around VfW does not do that it should raise your eyebrows. Playback behavior on such points can be erratic.

[JimmyBarnes]

Originally Posted by sneaker_ger

If you cut through references you end up with stray/missing slices. That's just the way it is. So if softwares specifically designed to edit H.264 re-encode on such cut points you can assume they do it for a good reason. If VirtualDub that was designed around VfW does not do that it should raise your eyebrows. Playback behavior on such points can be erratic.

But that's the whole point, such problems are NOT observed... If they were, I would have long sought something better.

Look, I got the answer to my problem, its clear this has become a a discussion on the merits or otherwise of MKV / AVI.

You are convinced your POV is correct just as I am mine, there is no point continuing such a discussion.

[burfadel]

AVI also doesn't support formats like AAC, and has a larger overhead than MKV. Cutting at keyframes is done because cutting anywhere else would effectively result in a corrupted stream. They got around this in the past by cutting at the keyframe then re-encoding to the cutpoint, then appending it to the original stream. It's messy and not really a direct steam copy. Even x264 through the VFW interface was a hack and not supported by the x264 development team. Support came through unofficial hack. Only reason to use AVI in 2012, let alone 2017, is for old stand alone players that don't support MKV or MP4, but even these would support at least MP4 if they support h264.

Virtualdubmod is ancient from a software perspective, and VFW is deprecated and will never be updated apart from it being removed entirely; I thought it already had. I would consider updating your whole lot of tools. Why the need to make all the cuts in the video? Reasons for your specific needs would be helpful. Why the need for encoding then cutting through direct stream copy? Why not cut when doing the initial encode?

[sneaker_ger]

Originally Posted by burfadel

AVI also doesn't support formats like AAC

http://www.alexander-noe.com/video/amg/en_myths.html
http://www.alexander-noe.com/video/d...containers.pdf

[Andouille]

<pengvado> <Dark_Shikari> if a fansubber or DVD rip group uploaded an H.264-in-AVI file they'd get laughed off the internet
<Dark_Shikari> Probably
<pengvado> but asp-in-avi wouldn't be laughed at
<Dark_Shikari> of course not, ASP in AVI is normal unless you want softsubs
<pengvado> and asp-in-avi requires exactly the same ugly hacks
<Dark_Shikari> Probably because its been that way so long that everyone is accustomed to it
<pengvado> which just goes to show that our campaign to use a new codec as an excuse to tell people to upgrade their container is working

From http://www.x264.nl/developers/Dark_Shikari/loren.html

[burfadel]

Maybe so, but those quotes are from several years ago.

[hello_hello]

Originally Posted by JimmyBarnes

But that's the whole point, such problems are NOT observed... If they were, I would have long sought something better.

Look, I got the answer to my problem, its clear this has become a a discussion on the merits or otherwise of MKV / AVI.

You are convinced your POV is correct just as I am mine, there is no point continuing such a discussion.

Unless someone tests your claims.

I ran a few little encodes with the vfw version of x264 and VirtualDub. They were each encoded with the default x264 settings. I only changed the output options or checked the zero latency option.

My test encodes had 418 frames. When I used the "write to a file" option, the first keyframe was at frame zero, and the next at frame 98. I cut the first 50 frames and saved a new AVI using direct stream copy. I did the same for the other test encodes.

For the encode written directly to a file, nothing was cut and the new AVI still had 418 frames.
The result was exactly the same for the encode with the VirtualDub hack enabled and using the vfw output method, whatever that does. The first 50 frames couldn't be cut.

For the vfw encode without the VirtualDub hack enabled, the first 48 frames weren't encoded. It looks like they were replaced with null frames. The next keyframe was now at frame 147, so I moved my cut point up to frame 110. After saving with direct stream copy the new AVI should have had 380 frames. It had 369, so obviously VirtualDub simply moved the cut point up to the next available keyframe.

The zero latency option seems to just disable B frames, so the bitrate increases quite a bit, but still didn't let me cut at frame 50.

I'd be interested to learn the incantation you're using when encoding that permits cutting anywhere.

I've nothing against the AVI container but I use MKV myself because I don't think a single hardware player in our house supports h264 in an AVI, but they're happy to play it in an MKV or MP4. That's reason enough for me even if AVI had magic properties that allowed cutting on non-keyframes without ill effects, but the keyframe cutting problem is mostly a minor inconvenience and easy enough to work around.

[raffriff42]

Good testing there hello_hello. By the way, according to the developers, x264 optimized for zero latency reduces all the following sources of latency:

Diary Of An x264 Developer 01/13/2010
x264: the best low-latency video streaming platform in the world

The total latency of x264, including encoder/decoder-side buffering, is:
B-frame latency (in frames) + Threading latency (in frames) + RC-lookahead (in frames) + Sync-lookahead (in frames) + VBV buffer size (in seconds) + Time to encode one frame (in milliseconds)

I don't know if the "Zero latency" checkbox does all that or not. None of these optimizations help a file-based (not live-streamed) video anyway - they only increase file size.

[hello_hello]

raffriff42,
It seems to be the same zero latency, at least to a certain extent. I read the post you linked to and while I don't understand it all fully yet, some of the relevant x264 settings obviously changed when zero latency was enabled. B Frames disabled, Slices enabled, Threads reduced, Lookahead threads increased. Nothing that'd make it possible to cut on any frame.

A small SD test encode using the default settings. x264 set High Profile, Level 3 each time. An old 4 core CPU with no hyper-threading used for encoding.

Without the zero latency checked:

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=6 / lookahead_threads=1 / sliced_threads=0 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=3 / b_pyramid=2 / b_adapt=1 / b_bias=0 / direct=1 / weightb=1 / open_gop=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc_lookahead=40 / rc=crf / mbtree=1 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00

With the zero latency option checked:

cabac=1 / ref=3 / deblock=1:0:0 / analyse=0x3:0x113 / me=hex / subme=7 / psy=1 / psy_rd=1.00:0.00 / mixed_ref=1 / me_range=16 / chroma_me=1 / trellis=1 / 8x8dct=1 / cqm=0 / deadzone=21,11 / fast_pskip=1 / chroma_qp_offset=-2 / threads=4 / lookahead_threads=4 / sliced_threads=1 / slices=4 / nr=0 / decimate=1 / interlaced=0 / bluray_compat=0 / constrained_intra=0 / bframes=0 / weightp=2 / keyint=250 / keyint_min=25 / scenecut=40 / intra_refresh=0 / rc=crf / mbtree=0 / crf=23.0 / qcomp=0.60 / qpmin=0 / qpmax=69 / qpstep=4 / ip_ratio=1.40 / aq=1:1.00