livelock using External encoder

[asaleo]

I have used External encoder for many years in VirtualDub.
Now I often receives "livelock 7749E78C" when checking log at saving.
I then have to use abort. Do any of you have any idea what has happened? I have not changed anything in program.

[raffriff42]

It's got something to do with threads, priorities, race conditions blah blah blah.

An early vdub blog post, not concerning external encoding, but points to the general issue:
The infamous frame 9995 MP3 bug
http://www.virtualdub.org/blog/pivot/entry.php?id=88

For years, I've been receiving reports about a mysterious problem with VirtualDub hanging during a save operation. The program's UI was still responsive, so the application hadn't totally died, but the processing pipeline jammed up such that the render couldn't make any progress or be aborted (a "livelock"). I had initially assumed that this was a deadlock caused by thread synchronization issues, which wouldn't lock the UI because VirtualDub's UI runs in a separate thread, and this was reinforced by the livelock log messages in recent versions indicating that the audio thread was stuck in a system call. However, I could never find the culprit or reproduce the problem. This was very frustrating for me, because it was a long-standing issue that made my program unusable for some people, and which I couldn't fix.

Until now.

I recently found out which software triggers the problem and why — it's the Creative Labs MP3 codec (ctmp3.acm), and it's because of peculiar notifications being sent by that codec. It comes with the software that ships with certain SoundBlaster Live! sound cards; in particular, installing the PlayCenter application will also install the codec. Either renaming the driver file temporarily, uninstalling it, or lowering its priority in the Sounds and Audio Devices control panel so that another MP3 codec has priority will work around the problem. I think I have a viable workaround that I can put into VirtualDub itself, but why this codec causes a lockup is an interesting question in itself....

Change codecs, experiment with thread priority.I have found that setting 'processing thread priority' to 'normal' makes the livelock issues go away.

[shekh]

In VDFM I fixed one bug which lead to this.
For the curious: https://github.com/shekh/VirtualDub2/blob/f61e4ba95d68cafd2ad0ec67fa42228e2239bf0e/src/VirtualDub/source/DubProcessVideo.cpp#L780-L784
The expression is either plain wrong or in undefined behavior area.
sfe.mBatchNumber - ofe.mBatchNumber may result as negative number threated as unsigned -> very large positive number.
(sint32) has no effect because then it is compared with unsigned -> converted to unsigned again. In practice this situation may occur very easily if the source file is decoded very fast (faster than some other processing in the chain).

[asaleo]

Thanks for your rapid answers. Saving .avi files from VDub works well.
I now suspects that it has something with the sound processing since I got saved mp4 files with bad sound. I will go on testing to see what factors are involved. I will use both VirtualDub and VirtualDub filter mod in tests.

[asaleo]

Saving files using external encoders to mp4 from Vdub- Vdub FilterMod worked well for small files but got stuck for bigger files,( 5000 frames) Vdub went into a loop at 99% ready. After abortion I got three files, an empty mp4 file, one sound file and a video file. It seems that merging of these files caused the livelock loop.

Saving with "save as" to mp4 in VirtualDub FilterMod worked well.

I learnt another thing too. Do not save Processing settings in VirtualDub FilterMod wirh Audio set to "Full processing mode" Loading these settings afterwards makes it impossible to change Audio to "Direct stream mode" if you need that. It seems to work since you can change Audio settings in Vdub without any problem but you will not get a proper sound in resulting video. Setting Audio setting "manually" for each process works.

VirtualDub FilterMod is otherwise the best VDub version I have used.

[shekh]

Saving files using external encoders to mp4 from Vdub- Vdub FilterMod worked well for small files but got stuck for bigger files,( 5000 frames) Vdub went into a loop at 99% ready. After abortion I got three files, an empty mp4 file, one sound file and a video file. It seems that merging of these files caused the livelock loop.


I have another bugfix still unpublished, related to external encoder.
Can you share everything related to this test so I can try to repeat it:
source video
.vdprof (external encoder settings)
job file with processing settings
registry tree export HKEY_CURRENT_USER\Software\VirtualDub.org

Also when it gets stuck, you can press "dump status" in the status window, "perf" page. It may have something interesting.
And everything from the log window.


Do not save Processing settings in VirtualDub FilterMod wirh Audio set to "Full processing mode" Loading these settings afterwards makes it impossible to change Audio to "Direct stream mode" if you need that. It seems to work since you can change Audio settings in Vdub without any problem but you will not get a proper sound in resulting video.

Will try this. What do you mean "not proper sound", is it completely destroyed?

[asaleo]

I have made "dump status" from processing windows when VDub is trying to end saving.

First line in log which shows that something is wrong:
"Dub processing thread has not cycled for 30 seconds - possible live lock ......"
(Thread action stalled due to full pipe processing thread) Current adress 775ED1C

I then made "dumb status" which is shown below:
=================
Processing thread
=================
Completed: Yes
Error encountered: No
Video push ended: Yes
Video ended: Yes
Flushing compressor: No
Codec frames buffered: 0
The processing thread is busy and could not be suspended.

I then made an abort.
Vdub FilterMod now shows: "Vdub in progress"
Later text about something stuck appears.
I confirm that Vdub should be closed.

Saving video without sound did not change anything.
Short videos with 1000 frames saves OK. Big videos with 5000 frames will mostly not succed. Sometimes the three resulting files have merged by themself long after VDub has been closed. Strange.

Regarding problem with Audio setting in saved settings: I used saved settings with Audio set to Full processing mode in Vdub FilterMod and changed Audio to Direct stream mode and made a short video with external encoder. My voice in saved video was hoarse. I could understand what I talked about but it was not a pleasant voice.

[shekh]

External encoder: the fact that it completes afterwards lets me think the external encoder process is waiting for more input. If you want, try with this version: https://drive.google.com/open?id=1f80IO9sKuLrF7e8tHWEpxwRHcigrro-6
There is a fix for wrong pipe output.

Audio: sorry, your description is too obscure. Are you saving with external encoder? Which preset for audio? And you say audio is in "direct mode". Is it already compressed? To which format?

[asaleo]

When using external encoder I normaly do nothing with the sound. Default setting in Vdub is Direct stream mode which works with external encoders. When finished with deshaker and other filters I export the result using external encoder. Since direct stream mode is default for external encoder I have to change audio if it set to full processing mode because of the "save as" possibility in VDub FilterMod. If "save as" also could use Direct stream mode as audio input there would be no conflict.

[asaleo]

I put everything on an USB pin and run in my old Vista computer.
Everything went well. File saved without problem with external encoder.
Thus it is something in my Windows 10 computer which affects saving my virtualDub file with the external encoder.

[raffriff42]

>something in my Windows 10 computer which affects saving my virtualDub file with the external encoder.

Okay, that reminds me - make sure processes like antivirus, search indexing, thumbnail generation and media player library scanning are not enabled for your write folder.

[asaleo]

Thanks Raffriff for your answer. I checked processing going on by using Task manager. No processes were running. I tried a saving but it got stuck as before.
I have now to add that files joined after abortion and VDub was not locked either. I have to wait before aborting to see what happens.
I have now marked in external encoders that files should be merge after abortion. It has not worked before but it worked today,

[exonx]

I realise that this is an old thread but I was wondering if anyone had yet found a solution to the problem between VirtualDub's external encoders and Windows 10.
As already mentioned in the the thread the external encoders demultiplex the multimedia file and produce a video file and an audio file then the process stalls.
On most occasions if the process isn't aborted, after an hour or more these two files are eventually remultiplexed. No idea why!
Alternatively if the process is aborted, then the audio and video files may be multiplexed immediately into a single multimedia file using something like mkvtoolnix.
This does however produce a non-standard file although on most occasions it will play in in MPC-HC.
I have returned frequently to this problem but never with any success.
My personal workaround is to dual boot with Windows 7 and use Virtualdub with its External Encoders within this operating system.
The remultiplexing works flawlessly within Windows 7.
Any pointers would be greatly appreciated.

[sneaker_ger]

As already mentioned in the the thread the external encoders demultiplex the multimedia file and produce a video file and an audio file then the process stalls.
On most occasions if the process isn't aborted, after an hour or more these two files are eventually remultiplexed. No idea why!
Alternatively if the process is aborted, then the audio and video files may be multiplexed immediately into a single multimedia file using something like mkvtoolnix.
This does however produce a non-standard file
The "external encoders" don't demux anything. VirtualDub handles the demultiplexing/decoding and sends raw video and audio to the external encoders. After both video and audio encoding have finished VirtualDub makes a call to a multiplexer like mkvmerge/mkvtoolnix. This isn't different from calling mkvmerge manually from the command-line. It's any more or less "non-standard" than doing in manually.

[shekh]

Did you try with VirtualDub2? Last found issue that I remember: there was unnecessary extra data (garbage) sent to encoders. I can imagine how this could result in non-standard files or hang the process. No idea how Win10 is involved (I don't do anything on it).

[exonx]

I apologise I made a mistake. I meant to say that external encoders re-encode and then re-multiplex the temporary audio and video files created after VirtualDub has demultiplexed and then decoded the original multimedia file. In my case I call either mkvmerge, mp4box or ffmpeg. to do the re-multiplexing
Mea Culpa.
I have tried VirtualDub2 but have had no success with that either.
I am just really curious to know why in Windows 7 the process runs perfectly every time and in Windows 10 it doesn't re-multiplex at all. I might add that all my other apps run well in windows 10.

[shekh]

The issue should be fixed now.
Under the hood:
the helper process vdlaunch.exe was not able to exit because some other software injects garbage thread. I don't have exact confirmation, it could be antivirus or even system compatibility layer.
The exit procedure of vdlaunch.exe was unreliable and failed. Now it is simply "ExitProcess" and works in all cases.
The updated vdlaunch.exe can also be used with old VirtualDub.

[exonx]

Hi shekh
Sorry I'm late updating you but I've been away for several days and only arrived back yesterday.
I've tested the new VirtualDub2 release with a large variety of file formats and codecs and; TA DA! it works like a dream. It really was a pain having to reboot into windows 7 every time I wanted to use External Encoders.
The only operation that fails now in Windows 10 is AC3 passthrough.
The command line I am using in FFMpeg is "-i - -vn -acodec copy". This throws up the error in the log, "invalid data found when processing input". Again this command works in Windows 7.
However please don't bother about this as I can always re-encode the audio. Windows 10 doubles the encoding speed compared to Windows 7
Thank you so much I'm really very grateful for your trouble.

[shekh]

Thanks for confirmation :)

[gvp]

The only operation that fails now in Windows 10 is AC3 passthrough.
The command line I am using in FFMpeg is "-i - -vn -acodec copy".

I'm using this conf for ac3 and I have no problems in win10


https://pasteboard.co/Hqm29pU.jpg

[exonx]

Thanks for replying but I think that the command you posted re-encodes the AC3 audio and I am trying to pass through the existing Audio in order to to re-multiplex it with a re-encoded video.

[sneaker_ger]

/EDIT: wrong information, ignore

The command line I am using in FFMpeg is "-i - -vn -acodec copy".
You are trying to use this command via VirtualDub's "External Encoder" feature to copy AC3? This will never work. VirtualDub's "External Encoder" feature always outputs uncompressed video/audio data. If anything you'd have to set the audio copying in the "muxer" part of the "External Encoder" settings and point ffmpeg/mkvmerge to the original file. Unfortunately VirtualDub doesn't provide a variable/token for the source file name and path. (You could trick by e.g. predicting the name or something with a different suffix.)

[exonx]

Sorry to contradict you but I have always been able to pass through AC3 audio in VirtualDub using windows 7, even 5.1. I have just rechecked it with 2 A/V files. the only proviso is that within VirtualDub, audio has to be Direct stream copy and within External Encoders the audio encoder must have Raw audio data checked and Wave file and Bypass compression unchecked.

[sneaker_ger]

/edit: WRONG, ignore

the only proviso is that within VirtualDub, audio has to be Direct stream copy
I'm not arguing about "Direct stream copy", only "External encoders".

Sorry to contradict you but I have always been able to pass through AC3 audio
[...]
I have just rechecked it with 2 A/V files
[...]
and within External Encoders the audio encoder must have Raw audio data checked and Wave file and Bypass compression unchecked.
How did you "recheck"? If your files have AC3 it doesn't prove the original AC3 data has been copied. It could be re-encoded AC3.


From VirtualDub help (F1):
Bypass compression: Causes the audio compression setting in VirtualDub to be ignored, disabling any compression. If the source audio data is compressed, it is decompressed prior to being passed to the external encoder.

[exonx]

The audio tracks are identical ac3 5.1 tracks and the ffmpeg command for the external encoder is "-i - -vn -acodec copy"

[sneaker_ger]

I'd love to be corrected but I have never seen that working. What input driver do you use on the Win 7 machine? Log?

[exonx]

I've enclosed the relative part of the log file below

i] VideoEnc: frame= 96 fps= 62 q=21.0 size= 1123kB time=00:00:02.25
bitrate=4084.9kbits/s

[i] AudioEnc: Input #0, ac3, from 'pipe:':

[i] AudioEnc: Duration: N/A, start: 0.000000, bitrate: 384 kb/s

[i] AudioEnc: Stream #0:0: Audio: ac3, 48000 Hz, 5.1(side), fltp, 384 kb/s

[i] AudioEnc: Output #0, ac3, to 'C:\Users\exonx\Desktop\wrestler
test.mkv.ac3':

[i] AudioEnc: Metadata:

[i] AudioEnc: encoder : Lavf55.12.102

[i] AudioEnc: Stream #0:0: Audio: ac3, 48000 Hz, 5.1(side), 384 kb/s

[i] AudioEnc: Stream mapping:

[i] AudioEnc: Stream #0:0 -> #0:0 (copy)

[i] VideoEnc: frame= 120 fps= 57 q=21.0 size= 1695kB time=00:00:03.25
bitrate=4268.0kbits/s


As you can see the AC3 5.1 audio input to the external audio encoder is taken straight from the pipe from VirtualDub. It is then copied without re-encoding to the audio elementary stream.
"AudioEnc: Stream #0:0 -> #0:0 (copy)"



Below is an extract from "stephanV" in the long defunct "Unofficial VirtualDub Support Forums dated June 11 2010.
You may possibly still find this discussion on the "Internet Archive"

Direct passthrough of AC3/MP3 audio

It is possible to pass AC3 and MP3 audio through the external encoder feature without having to recompress it. It might work for other audio formats too, but this is not tested. A precondition is that VirtualDub must have direct acces to the compressed audio. If you are using for example the DirectShow plugin to open files this method will not work.

This is actually very simple to set up. First, create an audio encoder profile using ffmpeg with this command argument:
QUOTE

-i - -acodec copy "%(tempaudiofile)"



Then change the extension of the output filename to .ac3 or .mp3 (whatever is needed). In the 'Audio'-tab set the input format to Raw and keep the 'Bypass compression'-option unchecked.

This profile can be used as audio encoder in an encoder set, and when Audio is set to Direct Stream Copy (important!) the original compressed audio will be used for the new file.



I might add that I have never been able to pass through AAC audio. Don't know why. I've never researched it.

I'm afraid I don't have the time to pursue this investigation any further at the moment. I'm coming to the end of a project that must be presented in two weeks time otherwise I'm up against penalty clauses. However I hope the above has been of some assistance and will help you resolve the issue of "Pass Through".

[sneaker_ger]

Well, what do you say, it works here. :D Then again, I'm on Windows 7 and don't have 10 to test.

I tested an mkv input file with the Matroska input plugin. I suspect the input plugin/driver could be responsible for the different behavior in your case. So try to copy the VirtualDub plugins from your Win7 to your Win10 machine and then when you go "File"->"Open video file" select it at the drop down on the bottom. Do you use VirtualDub 32/64 on both machines?

[exonx]

You were quite right sneaker_ger. I'm using VirtualDub2 on my Windows 10 machine and I hadn't noticed that the Caching Input Driver was getting priority and AC3 Passthrough was failing. I simply upped the merit on my FccHandler matroska plugin and AC3 was passed through without a problem. Many thanks for the HeadsUp