VfW Support for h265 and others?

[movmasty]

Also VPx - Thor and Daala for vfw-Virtualdub


:search: :thanks:

[sneaker_ger]

VirtualDub does not need VfW, it can also pipe to external cli encoders. See VirtualDub's help on "external encoders". You can even get some presets ready to import for easy setup which include x265 among others: http://forum.videohelp.com/threads/367446-Virtualdub-External-Encoder-feature

[Jamaika]

There are no new ones for VirtualDub. You can use some tricks at X265 / vpx / Daala / MP4Box / mkvmerge, but do they work?
http://forum.doom9.org/showthread.php?t=172546
As for me, why artificially create workarounds like they are converters for the new codecs.
Container Avi deleted. There isn't even VP8 codec.
You can force the creation of an AVI using ffmpeg:
ffmpeg -i input.mts -s 1920x1080 -r 50000/1000 -f avi -c:v libx265 -x265-params ... -vtag HEVC output_H265.avi
Disadvantage: you don't open the file in any editor.

[movmasty]

Disadvantage: you don't open the file in any editor.
I was referring mainly to import filters,

Thanks.

[MZ/X]

Hi All,

The initial (the first widely working) version of x265vfw, based on the x264vfw, using the x265 library dll.

Homepage:
http://mpxplay.sourceforge.net

Follow on FB:
http://www.facebook.com/mpxplay

[MZ/X]

x265vfw v120 is updated with decoder side and x64 version. The direct stream copy (with VdubMod) and dshow playing (with Mpxplay-MMC) seems to work.
I've found that the 2-pass encoding crashes with original VirtualDub versions, but it seems to work with VirtualDubMod (x86).
Under testing...

http://mpxplay.sourceforge.net

[BlockABoots]

Im trying to use the above x265vfw for capturing live via AmaRec, but when i try and capture i get the following 2 popup windows....

"ICCompressBegin"

&

"x265vfw [error]:x256_encoder_openfailed"

any idea?

[MZ/X]

That also happens at me sometimes (untested reasons), so I'm on it...

[BlockABoots]

Seems to happen all the time, with AmaRec. So im unable to use 265vfw, 264vfw on the other hand works fine however

Also have noticed that the x64 bit version never shows up in the codec list within AmaRec (x86 shows up however), is there a reason for this?

[Ajvar]

My-my, it's AmmAZING! Just tried this on Vegas Pro and it works like a charm. I always set Logging Level to NONE since x264's problems with any other option of this setting. x64 bit. Choosing FILE mode and container would be nice perks but it works without it so cool indeed.
P.S. Command line working would be good too. For example in Vegas I need to set --range-pc in vfw264 and vfw--265 to keep original levels.

[MZ/X]

Sorry for the long delay...

x265vfw v1.30 is released on http://mpxplay.sourceforge.net

Diffs between v1.20 and v1.30
- updated x265lib to v2.2 release (build 102)
- updated FFmpeg decoder to v3.2.2
- enabled multi-threaded decoding (depending on the number of CPU cores)
- added x265lib command line options handling and list of them under Help ("?") button (needs test)
- x265lib errors are displayed in x265vfw error window (stdout redirection, missing EoL)
- added "Full" log level to display all x265 library messages (needs test)
- disabled "Update stat file" option by default
- modified x264.stats to x265.stats by default
- removed untested and probably unusefull GordianKnot workaround
- added "hvc1" and "hev1" to fourCC list
- binaries are built with MinGW 6.3

"latest" release files are removed from x265vfw directory, please visit my homepage for the latest versions

I haven't made major changes in the encoding method, so some problems is still the same
(like crashing in original VirtualDub in 2-pass encoding, and x265vfw file output doesn't work yet)

@BlockABoots
1.Maybe the newer x265vfw drops some extra error messages to identify the problem.
2. x64 driver for the x64 applications, x86 driver for the x86 applications...
I think so You can install and use both driver parallel, but I haven't tested it

[Jamaika]

Thanks for the resumption of the project vfw X265 .
Certainly there is already progress.

I looked at the codec in Vegas Magix 14.

I have got some questions:
1) Will I be able in the future to import files RGBA64?
2) Will I be able to export files 10bit?
3) Do you plan to add function tune VMAF?
I noticed that you can't add functions colorMatrix, transfer, colorprism and range. I understand that something is in the implementation.
http://i63.tinypic.com/2bbkwp.png

[MZ/X]

Thnx for the feedback.

I plan to rework (replace) the color space conversions, because it's a weakness (an ugly part) of the codec.
Then I will check what is supported in the VFW API at all. Maybe everything (RGBA64 input, 10 bits output), but I don't know yet.

Probably I have to review the command line options, because some of them are unsupported (invalid), other ones (vfw config related) are dropped out (but should work).
But first please press '?' to list the available options, because --input-csp and --output-depth are surely not supported.
And report those ones only, which should work, but has no effect.
(I've tested the "--lossless" option, while the GUI Rate control was ABR, and it made lossless output, using the command line setting)
Maybe the VUI info is not written into the bitstream, I'll check this. I have no knowledge about this part. ("--colormatrix" and such options)

btw. What is the VMAF tune? It's not here:
http://x265.readthedocs.io/en/default/presets.html

[Jamaika]

But first please press '?' to list the available options, because --input-csp and --output-depth are surely not supported.
It was a rhetorical question. These options are in the X265, of course without rgba64. This function RGBA64 appears only as an overlay with the X265 for photos BPG, but this project has been suspended. I asked, because I have the preview options in Magix Vegas 14 in RGBA64.;)
btw. What is the VMAF tune? It's not here:
http://x265.readthedocs.io/en/default/presets.html
VMAF is a perceptual video quality assessment algorithm developed by Netflix. VMAF Development Kit (VDK) is a software package that contains the VMAF algorithm implementation, as well as a set of tools that allows a user to train and test a custom VMAF model. Read this tech blog post for an overview.
He was touted in this forum as an important addition to the codec X265. Regards
http://www.streamingmedia.com/Articles/Editorial/Featured-Articles/Netflix-Finds-x265-20-More-Efficient-than-VP9-113346.aspx
https://github.com/Netflix/vmaf/commits/master

[MZ/X]

VMAF = complete Linux mess
The package contains something ptools lib too, probably the Netflix's tools, including socket communication and other weird things.
I don't think so that x265lib developers will add this feature to their code in this shape (and I also don't plan to do it)...
It requires a strong rework for a general use...

[MZ/X]

x265vfw v1.41 is released on http://mpxplay.sourceforge.net

Diffs between v1.30 and v1.41
- updated x265lib to v2.5 release (build 130), added new x265 command line options to x265vfw, corrected/modified some older ones
- x64 release has 10 and 12 bit (per channel) encoding modes too, can be controlled by "--output-depth" option
- corrected PC/TV (full/limited) range conversions
- added option "--input-range" to specify input light range, it can be "full" (PC) or "limited" (TV), default is "auto" (YUV: limited, RGB: full)
- replaced internal colorspace conversions by FFmpeg's ones: added GRAY8, GRAY16, RGB555LE, RGB48BE, ARGB64BE,
BGR48LE, BGRA64LE, YUV420P16LE, YUV422P16LE, YUV444P16LE pixel formats

[MZ/X]

x265vfw v1.51 is released on http://mpxplay.sourceforge.net
A major new feature is the file output writing (AVI,MP4,MKV).

Jamaika:
There is a strong improvement in the VMAF to use it as a library (I can compile it),
but - it seems for me - the VMAF is just a measurement tool, I don't see yet how can it be used to tune a video encoding.
This is a good description anyway:
https://www.diycode.cc/projects/Netflix/vmaf

[Jamaika]

There is a strong improvement in the VMAF to use it as a library (I can compile it),
but - it seems for me - the VMAF is just a measurement tool, I don't see yet how can it be used to tune a video encoding.
This is a good description anyway:
https://www.diycode.cc/projects/Netflix/vmaf
Probably you are right, but vmaf is advertising its ffmpeg filter.
What's New
•(8/12/17) VMAF is now included as a filter in FFmpeg main branch, and can be configured using: ./configure --enable-libvmaf.
•(7/16/17) VMAF is now packaged into a library call libvmaf and can be called from a C/C++ program directly. See this section for details.

[EasyStart]

Is there anyone tried version v1.70 (x265vfw_x86_v170_x265b146_8bit_20171223). My 32 bits program, ImageToAvi v1.3, does not output anything when using the latest x86 version.

[EasyStart]

I am on Windows 7 x64 with sp1.

[MZ/X]

Jamaika:
VMAF is added to x265 too, but in the current implementation method, I cannot use it in the x265vfw, so I've made a ticket to the x265 developers:
https://bitbucket.org/multicoreware/x265/issues/408/vmaf-make-it-configurable
Currently I cannot investigate into x265 development so much...

EasyStart:
x86 version exists, but it's not really supported by x265 devs nor by me, due to the high memory usage of encoding process.
Earlier version worked? Did you try the file output mode?

btw. x265vfw v2.80 is released on http://mpxplay.sourceforge.net

[Jamaika]

That's what you do, it will certainly come in handy. There are still many fans of the AVI container, because it is simple to build and compatible with everything.
VMAF is still in development. The author's concepts are evolving. X265 no longer matches VMAF because command lines change.
typedef struct x265_vmaf_commondata
{
char *format;
char *model_path;
char *log_path;
char *log_fmt;
int disable_clip;
int disable_avx;
int enable_transform;
int phone_model;
int psnr;
int ssim;
int ms_ssim;
char *pool;
int n_thread;
int n_subsample;
}x265_vmaf_commondata;
I compiled BPG and HEIF codecs based on X265 from VMAF. Unfortunately vmaf doesn't start

[MZ/X]

Because I haven't seen any updates on the original x264vfw codec in the last 3 years, I've made a new version, based on the x265vfw.
You can download it on http://mpxplay.sourceforge.net

Advantages over the original x264vfw:
- 8 and 10 bit encoding output (use --output-depth 10 option in the extra command line)
- Supports more input color spaces, including 10 and 16 bit per channel ones (see list in the help, press '?' button)
- Reworked color space selection ("Convert to ...")
- Reworked Display Aspect Ratio setting
- Optional HW accelerated decoding
- New file output writing, based on FFmpeg
- x264 encoder library is updated to the latest available version (build 159, revision 2991)
- Optional OpenCL based encoding (8-bit output only), it can be enabled with --opencl option in the extra command line (but the encoding can be slower at the case of weak OpenCL support, like at my testing Intel CPUs)

Known disadvantage(s):
- dts-compress option is not implemented in this x264vfw
- Gordian Knot workaround is removed (whatever was that)

[MZ/X]

Initial version of xAV1vfw v0.82 is released on http://mpxplay.sourceforge.net

The GUI is similar to the other (x264,x265) VFWs.

XAV1vfw uses the svt-av1 encoder library (git 20200419), which is still under development with several limitations, like
- it doesn't work properly under Windows 7 (at me), only under Win10 (wrong CPU detection)
- it's very slow, even in the fastest encoding mode (full HD encoding, 4 cores, AVX2, ~5 fps)
- AVX512 support is unofficial/experimental, disable it (on the GUI) at encoding problems (crash)
- some GUI settings have no svt-av1 support yet (encoder may rejects these), like YUV, Tuning and Profile settings

Enabling the Debug log level to Full can display some additional svt-av1 errors and infos.

So, this codec is just a TryOut/PlayWithIt version yet...

You can follow the updates of my VFW on sf.net page
https://sourceforge.net/p/mpxplay/discussion/219198
or on my FB page
https://www.facebook.com/mpxplay

[stax76]

broken at 288 DPI

[MZ/X]

x265vfw v3.40 is released on http://mpxplay.sourceforge.net

Diffs between v3.31 and v3.40
- updated x265lib to v3.4 (build 192), added new x265 command line options to x265vfw
- corrected Fast first pass mode (but it's effective only from Slow presets)
- removed/disabled bcrypt.dll dependency (in FFmpeg build)

xAV1vfw is also updated.

Diffs between v0.85 and v0.82
- updated svt-av1 encoder lib to v0.8.5+ (git 20201021), improved speed, quality and stability; modified encoder options
- updated libdav1d decoder to 0.7.1
- updated compiler to MinGW-w64 10.2
- added / modified "Enable AVX512 instruction set" switch
- removed Slow 1st pass selection, because svt-av1 always uses Fast 1st pass mode (and it's not configurable)
- removed manual "Create stat file" switch (stat file is made for 1st pass execution only)
- workarounds for some svt-av1 problems (less crash)

"broken at 288 DPI" doesn't tell me too much, but I think so this xAV1vfw is much better then the previous one.
The memory can be still a limit, 16GB total memory was not enough to (re)encode a 4K videoclip to AV1,
it's freezed/crashed after allocating ~9GB. (at this point I cannot start/open any other application neither, before closing the encoding)
I see some pending modifications in the svt-av1 development, which can reduce the memory footprint.

[benwaggoner]

x265vfw v3.40 is released on http://mpxplay.sourceforge.net

Diffs between v3.31 and v3.40
- updated x265lib to v3.4 (build 192), added new x265 command line options to x265vfw
- corrected Fast first pass mode (but it's effective only from Slow presets)
- removed/disabled bcrypt.dll dependency (in FFmpeg build)

xAV1vfw is also updated.

Diffs between v0.85 and v0.82
- updated svt-av1 encoder lib to v0.8.5+ (git 20201021), improved speed, quality and stability; modified encoder options
- updated libdav1d decoder to 0.7.1
- updated compiler to MinGW-w64 10.2
- added / modified "Enable AVX512 instruction set" switch
- removed Slow 1st pass selection, because svt-av1 always uses Fast 1st pass mode (and it's not configurable)
- removed manual "Create stat file" switch (stat file is made for 1st pass execution only)
- workarounds for some svt-av1 problems (less crash)

"broken at 288 DPI" doesn't tell me too much, but I think so this xAV1vfw is much better then the previous one.
The memory can be still a limit, 16GB total memory was not enough to (re)encode a 4K videoclip to AV1,
it's freezed/crashed after allocating ~9GB. (at this point I cannot start/open any other application neither, before closing the encoding)
I see some pending modifications in the svt-av1 development, which can reduce the memory footprint.
You should also post about AV1 updates in the VP9/AV1 forum: https://forum.doom9.org/forumdisplay.php?f=84

I am somewhat gobsmacked that people want to do something as new as AV1 in something as ancient as VfW, which was deprecated in favor of DirectShow during the Clinton administration. Microsoft announced that VfW was going to be replaced before DVDs existed! Probably connected, as VfW's lack of B-frame support meant it wasn't good for MPEG-2.

[Forteen88]

I only use a VfW-codec for the Amiga-emulator WinUAE (it uses it to capture video), but is there a better way to provide a video-codec for that program?

[benwaggoner]

I only use a VfW-codec for the Amiga-emulator WinUAE (it uses it to capture video), but is there a better way to provide a video-codec for that program?
Use DirectShow or MediaFoundation at least; both are modern APIs. Many PCs these days have hardware accelerated HEVC encoding available. Efficiency isn't as good as a software encoder, but it can work in realtime with very little overhead. Quality is fine as long as you use a high enough bitrate.

[Forteen88]

Use DirectShow or MediaFoundation at least; both are modern APIs. Many PCs these days have hardware accelerated HEVC encoding available. Efficiency isn't as good as a software encoder, but it can work in realtime with very little overhead. Quality is fine as long as you use a high enough bitrate.Thanks, but which specific video-codec should I use? I hope it's not some codec-pack like ffdshow?!
I have a crappy old AMD Radeon graphics-card right now, so no hardware-encoding :P

UPDATE: I tried installing the DirectShow H264(AVC)-codec HAX264. Devs wrote: "It also includes a VFW driver.", yet WinUAE don't recognizes it!
The x265vfw_x64 codec is recognized by WinUAE though.

[MZ/X]

Use DirectShow or MediaFoundation at least; both are modern APIs. Many PCs these days have hardware accelerated HEVC encoding available. Efficiency isn't as good as a software encoder, but it can work in realtime with very little overhead. Quality is fine as long as you use a high enough bitrate.

This topic sounds about VFW support of newer codecs. Is this a problem for you (as admin)?

And I assume you've never checked the functionality of these VFWs (GUI config, 8/10/12 bits per channel support, detailed configuration options, etc.).
The decoder side can be problematic at VFWs, but the encoder side has no too much limitation, especially not at writing directly into file (File output mode).
A couple of old program supports VFW output, the new ones usually have internal implemetation for video ouput/encoding.
I've never used HW based encoding, due to the worse quality.

Maybe later I'll make DirectShow or MediaFoundation version of these codecs, but currently it's not on my todo list.
(btw. some DirectShow solutions use a VFW encoder at the end of the filter chain)

[MZ/X]

New versions of x264vfw, x265vfw and xAV1vfw are released on http://mpxplay.sourceforge.net
with updated encoder and decoder libraries, and with some minor bugfixes.

[blob2500]

Thanks for the new versions of x265vfw/x264vfw.
Would it be possible to implement something avidemux-style that warns about Restore Points to "discourage" cutting (in direct stream copy of Virtualdub) on such K-frames(but non-IDR frames)?


https://i.postimg.cc/bvZT6dRh/Rec-Point-Adv.png


This window appears in Avidemux, when you try to make a cut at a Recovery Point.

[Z2697]

Thanks for the new versions of x265vfw/x264vfw.
Would it be possible to implement something avidemux-style that warns about Restore Points to "discourage" cutting (in direct stream copy of Virtualdub) on such K-frames(but non-IDR frames)?


https://i.postimg.cc/bvZT6dRh/Rec-Point-Adv.png


This window appears in Avidemux, when you try to make a cut at a Recovery Point.

Why should an encoder warn about such things?
You mean when you encode a video with such settings it warns you?

[blob2500]

Why should an encoder warn about such things?
You mean when you encode a video with such settings it warns you?
I don't mean the vfw encoder side, but the vfw decoder side. Basically, that the decoder recognizes the non-IDR K-frame (and it already knows how to do this, otherwise it wouldn't even know how to display the frames involved) but also warns when the editor is on that frame. The purpose of reporting it would be to avoid (or at least let it be known) creating video files with frozen frames or corrupted during normal playback with the players, if they have been edited without taking into account the non-IDR K-frames.
In some cases I have found that the x264vfw decoder makes a small window appear that reports messages related to the frames (corrupted or otherwise), so theoretically the possibility of implementing what I say, I think there is.

Non-IDR K-frames are unfortunately often present when dealing with videos encoded with the "open GOP" or "Picture Intra refresh" options. This is often the case with many TV channels via DVB-S2/DVB-T. So editing (without reencoding) to get a well-made file becomes problematic without taking this into account.

[lvqcl]

Basically, that the decoder recognizes the non-IDR K-frame (and it already knows how to do this, otherwise it wouldn't even know how to display the frames involved) but also warns when the editor is on that frame..

How can the decoder know an internal state of some totally different program (editor)?

[blob2500]

How can the decoder know an internal state of some totally different program (editor)?

at bitstream level, for each frame, the frame type, the recovery point (into SEI Nal) are identified.

[lvqcl]

...And?

[blob2500]

Why all these questions?

I made a request, and I am answered with other questions.

I have exposed the question enough. The author of the new versions of x264vfw / x265vfw I think understands what I am talking about. If he (or other developers) accepts the suggestion and it is possible to implement this feature, it is fine, otherwise it is fine too.

[Asmodian]

I believe they were trying to help you understand why your feature request is unrealistic.

when you try to make a cut at a Recovery Point.

The problem is that the vfw decoder would have no idea you were making a cut. It could show that message every time it decoded such K-frames(but non-IDR frames), but that would be really annoying.

[blob2500]

The problem is that the vfw decoder would have no idea you were making a cut. It could show that message every time it decoded such K-frames(but non-IDR frames), but that would be really annoying.
Hi.
I agree that it would be annoying especially if there are many non-IDR K-frames in the stream, but it would be enough to insert it as an option when needed (a checkbox in the decoder GUI). The approach of implementing these codecs via VFW (advanced ones like H264/H265) seems to want to reduce the difficulties of this environment to the minimum possible... An option like the one I suggest goes in this direction. Moreover, the absence of such an option that identifies those K-frames, makes the editing that Virtualdub(direct stream copy)+VFWcodec proposes even less realistic. It would still potentially be problematic, but a little less (IMHO).

[MZ/X]

Thanks for the new versions of x265vfw/x264vfw.
Would it be possible to implement something avidemux-style that warns about Restore Points to "discourage" cutting (in direct stream copy of Virtualdub) on such K-frames(but non-IDR frames)?


As far as I know the "direct stream copy" does nothing with VFW, this is an internal Virtualdub function,
this feature (to detect properly keyframe boundaries) should be implemented there (and requires partial h264/h265 bitstream handling).

I also record DVB/MPEG-TS source and sometimes cut it with MKVtoolnix, some hw decoders don't like those streams (if referenced frame doesn't exist), but it can be handled on decoder side.
https://git.ffmpeg.org/gitweb/ffmpeg.git/commit/02eda84bf2fcf0db7793872204b0f564a6557232

[FranceBB]

I also record DVB/MPEG-TS source and sometimes cut it with MKVtoolnix, some hw decoders don't like those streams (if referenced frame doesn't exist), but it can be handled on decoder side.

I don't know about .mkv, but when trimming an .mxf file on a non intra frame, like a P or a B, the muxer should always still trim physically trim the file at the actual I frame so that the reference is there and then add a precharge value (literally an integer) that will tell the decoder how many frames to "discard" from the beginning of the physical file before showing the actual first frame (which is the one we wanted to display when trimming). This is what ommcp (i.e the Omneon muxer from Harmonic) does, for instance, and I've been using it for years without any issues.

[blob2500]

A strange thing with the CamStudio software.
I have both x265vfw 4.10 and x264vfw 2.10 installed on my system. Regardless of which codec I choose, only the x265vfw panel always appears; so I can't use x264 with camstudio.

No problems with Virtualdub (2/mod).

Nor do I have any problems with CamStudio if I install the old "official" x264vfw (Core 152 - r2851).

https://i.postimg.cc/vDXq5h0H/x264vfwcs.png (https://postimg.cc/vDXq5h0H)
[click to enlarge]

[Jamaika]

A strange thing with the CamStudio software.
I have both x265vfw 4.10 and x264vfw 2.10 installed on my system. Regardless of which codec I choose, only the x265vfw panel always appears; so I can't use x264 with camstudio.

No problems with Virtualdub (2/mod).

Nor do I have any problems with CamStudio if I install the old "official" x264vfw (Core 152 - r2851).
This isn't a CamStudio issue. This problem has been around for a long time. Someone created and posted junk on Sourceware and VideoHelp.
Do not install xav1vfw under any circumstances. It should work now.
Edit: The AVI container is deprecated. We don't recommend using x265vfw.

[blob2500]

This isn't a CamStudio issue. This problem has been around for a long time. Someone created and posted junk on Sourceware and VideoHelp.
Do not install xav1vfw under any circumstances. It should work now.

Thanks for the reply.

Edit: The AVI container is deprecated. We don't recommend using x265vfw.


Who deprecates AVI? And what are the hacks that are always mentioned but never specified?
The workarounds are for vfw, not AVI. The only hack for AVI was the packed bitstream introduced by DivX, but even that was for vfw; besides, it could have been done without, since xvid didn't use it.
Excuse me, but in this forum it seems clear that there's a widespread preconceived hatred for AVI as soon as it's mentioned (and also for vfw and xvid), even in a thread dedicated to them.
It's not a question of old systems, because for MPEG-2, mov, and asf, for example, the same aversion isn't seen.

In any case, my Digiquest decoder / pvr (models Ti9, Q30, Q60... from the years 2021-22) reads h265 but only if in AVI, or at most in MKV but in V_MS / VFW / FOURCC / HEVC mode (instead of the standard V_MPEGH / ISO / HEVC mode), which however in MKV is not recognized by other devices that accept the standard mode;, which however in MKV is not recognized by other devices that accept the standard mode V_MPEGH/ISO/HEVC; AVI in such cases becomes the preferable one to use because it is more supported.

[Ritsuka]

AVI is stuck in the '90: b-frames (a 30 years old feature) are still a big hack, poor subtitles support, poor chapters support, no vfr (without hacks), lack of standardized metadata, unsupported by most modern softwares, newer formats have no specifications on how to mux them in AVI. No official specs update since 30 years ago.

MOV is still used because it has been continuously updated, with proper B-frames support. MP4 is MOV with a bunch of minor differences. I don't know anyone using AFS nowadays.

Anyway, if AVI works for you, just use it. I would spend 50$ on a decent hardware instead.

[blob2500]

AVI is stuck in the '90: b-frames (a 30 years old feature) are still a big hack, poor subtitles support, poor chapters support, no vfr (without hacks), lack of standardized metadata, unsupported by most modern softwares, newer formats have no specifications on how to mux them in AVI. No official specs update since 30 years ago.

MOV is still used because it has been continuously updated, with proper B-frames support. MP4 is MOV with a bunch of minor differences. I don't know anyone using AFS nowadays.

Anyway, if AVI works for you, just use it. I would spend 50$ on a decent hardware instead.

It's a common misconception that B-frames in AVI are a hack. Frames are stored in decoding order, like all other multimedia containers (MP4, MKV, etc.). They aren't marked as "B-Frames" at the AVI container level, but it's not essential for the container to know this. The decoder knows what to do with the split bitstream it receives.

The workaround is in the vfw codec (due to the strict 1 frame in/1 frame out rule), not in the resulting AVI. ;)

It's true, it doesn't support VFR and the other features you mentioned, but it's annoying that every time the topic is avi+h264 (or h265), its limitations are reiterated by suggesting other containers. We know that mkv, mp4, asf, and others perform better in general, but that's outside the scope of the topic ;)

[Ritsuka]

It's an hack because multiple frames are stored in the same packet, it's not in any official specifications, they have got no proper decode and presentation timestamps, and requires more messing around in the demuxes.

It's 2025, maybe we can be let go those 1996 ugly workarounds now.

[blob2500]

It's an hack because multiple frames are stored in the same packet, it's not in any official specifications, they have got no proper decode and presentation timestamps, and requires more messing around in the demuxes.

You're confusing this with the Packed Bitstream used by DivX (and optionally also by Xvid), which was probably created to make direct editing of MPEG-4 ASP in a VfW environment with VirtualDub more user-friendly; otherwise, it was difficult to cut video. But PB wasn't needed even with ASP, it just became popular because of DivX. Xvid actually allows you not to activate it.


With h264/h265, no multiple frames packing is used in AVI chunks, and in fact, cutting with VirtualDub is very difficult due to the multiple b-frames, but the stream in the AVI file is compliant.


There are limitations to the AVI container with "modern" streams: no VFR, no subtitles, and other difficulties with audio with variable frame sizes and duration (vorbis...). However, h264 or h265 (if CFR) video streams don't require any hacks to be encapsulated in AVI. It only requires that the muxing be in the "Annex-B format" (which is part of the official specification) the same bitstream format used for blu-ray (BDAV container), .ts, .mts.... as opposed to the one used for MP4 and MKV, which do not use the so-called start/end codes. But those are not hacks ;)


It's 2025, maybe we can be let go those 1996 ugly workarounds now.
https://forum.doom9.org/showpost.php?p=1570293&postcount=4