#83 Direct Stream Copy for non-AVI Files

[yaru]

Hi. When I open an H.264 MP4/MKV file and then try to save it as another MP4/MKV file using the "Save as.." dialogue with video and audio set to "direct stream copy", I get an error that the source stream uses a compression algorithm that is not supproted by "AVI" files, despite the fact that neither my source nor my destination file is AVI. One of the main usages of VirtualDub for me is interactive video cutting, but this issue is preventing me from cutting naything other than AVI files; is this behavior intended?

[Anton Shekhovtsov]

Hi,
I did not review all error messages so the mention of AVI is wrong. The message just means "cant do this".
Initially there was a plan to allow direct copy for all formats, but I faced too much trouble with ffmpeg and left this feature only partially enabled.
https://sourceforge.net/p/vdfiltermod/wiki/direct_copy/

[yaru]

I see. I hope this feature is fully enabled in future, then. Thank you for your reply.

[isidroco]

Having same problem. Open h264 encoded AVI just to multiplex modified audio and receive this error: "The video stream uses a compression algorithm which is not compatible with AVI files. Direct stream copy cannot be used with this video stream"
It's crucial for my workflow being able to multiplex without touching audio and/or video. VirtualDub was ideal for quickly changing A/V synch or editing audio and remultiplexing without touching video and that is lost now. I'm dissapointed with that limitation. I have some scripts which are useless without direct stream copy feature. Will have to return to original Virtualdub.
PS: In my case I'm using AVIs.

[Anton Shekhovtsov]

Have you read the link above? You just need to switch the default driver for AVI to old one and it will continue to work.
This was hard decision to make the "caching driver" the default one but my priority was seamless decoding of H264. Which never worked fine with old/vfw pipeline.

[isidroco]

Yep, but it doesn't specify how can I change default behaviour. Or at least having a open in command line parameter so I can modify my scripts to choose old caching driver. Thanks.

[Anton Shekhovtsov]

Here related info: https://sourceforge.net/p/vdfiltermod/wiki/OpenVideo/
Step by step: use File->Open video, point to file of interest, change dropdown (2) to "Audio/video interleave", confirm opening the file. This way the choice is remembered in system registry and used later automatically.

For script it may be better to replace command
VirtualDub.Open("file.avi,"",0);
with
VirtualDub.Open("file.avi,"Audio/video interleave input driver (internal)",0);

The only difference is using explicit driver name instead of empty string (second argument).
This is old syntax compatible with original VirtualDub.

[isidroco]

That driver fails for .AVS scripts, using: "AVIFile/Avisynth input driver (internal)" works for everything but will fail to open AVIs bigger than 2Gb. It would be great if this last one worked for bigger files too...

[Anton Shekhovtsov]

I think it is impossible to improve "AVIFile" driver as it depends on operating system components (very legacy API).
You could substitute driver name based on file extension or return to auto-detection.

[Anton Shekhovtsov]

You can also lower initial priority of "caching input driver" if it is more convenient.
In the file cch_input.ini

[priority]
  default = 1

replace 1 with 0

[Anonymous]

What are the advantages of "caching input driver"?
I will change script to choose driver according to operation (non DirectStreamCopy operations could use the latest). Thanks for the answers.

[Anton Shekhovtsov]

There are multiple aspects. First, it is deterministic and portable way to decode everything supported by FFMpeg. Also "caching" helps with previewing: backward navigation is much smoother.
If you are looking at H264 in AVI, the "Audio/Video interleave" does not handle decoding itself, there must be a decoder in system and there are many possible decoders to take this job, with varying issues. It is already an issue to find, install and configure the "proper" decoder. x264vfw has decoding option, xvid has H264 decoding option, also ffdshow, maybe MS has one. AFAIK, all of them have same major problem: the order of decoded frames is undefined. You can easily observe this with numbered sequence rendered as H264 with B-frames. Typically the first frame would be just garbage, and other would mismatch with requested positions depending on where you move on timeline. This may be not critical for some uses, but for certain it ruined my attempts to work with Deshaker.
Other issues: impossible to get the correct colorspaces (color matrix, full/limited range), this may result in loss of detail or just inconvenience.

[isidroco]

"This may be not critical for some uses, but for certain it ruined my attempts to work with Deshaker." Same here, my work machine sistemetically misses first 3 frames (so Deshaker worked with final video shifted by 3 frames). But couldn't work on almost any other machine which gave untrustable results (shift was not always constant). With "caching" you solved that, THANKS!!! My script is near perfect now: With a command line will [deshake]/recompress all videos in folder with cfr/audio as I need.