Video capture doesn't work after upgrade from 5.1.30 to 5.2.0

[sgrassl]

Video capture is enabled via settings page but when the virtual machine is started the actual recording is not started although the video capturing symbol is active. Right-clicking this symbol shows the context menu with the "Video Capture" entry not being checked. This is a regression to the previous release 5.1.30.

Enabling video capturing after the virtual machine is started works like expected.

[Socratis]

Related threads in the forum:

• ​https://forums.virtualbox.org/viewtopic.php?f=6&t=85660
• ​https://forums.virtualbox.org/viewtopic.php?f=6&t=86186

[Socratis]

Here's what I found out from ​https://forums.virtualbox.org/viewtopic.php?f=6&t=85660 (for 5.2.0 and 5.2.2), and today with 5.2.5:

VirtualBox 5.2.5 (120042)

• If you start the recording before or after you start the VM, then a .webm file is created, but Firefox (the "test" standard) says that it's a corrupt file. It plays fine on VLC.

VirtualBox 5.2.0 and .2

• If you start the recording before you start the VM, then no .webm file is created. Nothing in the logs.
• If you start the recording after you start the VM, then a .webm file is created, but Firefox (the "test" standard) says that it's a corrupt file. It plays fine on VLC.

VirtualBox 5.1.30

• If you start the recording before or after you start the VM, then a .webm file is created, Firefox and VLC play it just fine.

[st2135]

Replying to socratis:

VirtualBox 5.2.5 (120042)

• If you start the recording before or after you start the VM, then a .webm file is created, but Firefox (the "test" standard) says that it's a corrupt file. It plays fine on VLC.

I've the same problem. Most video players refuse to play webm files created by VirtualBox. And even if they do play them (vlc usually does), there are lots of problems with timing. After some digging I have figured out the reason. It appears that webm's Segment/Info/duration contains incorrect value. According to matroska specification it should contain duration of the segment in milliseconds (TimecodeScale=1000000) but in all files created by VirtualBox, it contains value less or equal to 65535.

And here is the reason:

source:trunk/src/VBox/Main/src-client/WebMWriter.cpp@:842#L842​

WebMTimecode is actually uint16_t so its maximum value is 2¹⁶-1 or 65535.

[Socratis]

@st2135
Impressive detective work there!

[pentagonik]

Thanks for the analysis -- I'll have a look at this as soon as time permits.

[pentagonik]

Found and fixed the issue -- I'll put up a new test build soon.

[pentagonik]

Can you please use the latest test build to verify if this fixed your issue? The test builds are available here: Testbuilds.

[sgrassl]

Tested with latest test build (5.2.7r120865) and can confirm that video capture works if enabled before starting the VM. The generated file plays fine in Firefox.

But in comparison to version 5.1.30 there is still a little difference. If the target file already exists a new file is created appending the current timestamp (e.g. capture-2018-02-27T12-07-34-553318700Z.webm) to the filename in 5.1.30. In 5.2.7r120865 the video capture symbol is active but it's not recording. This might be a different issue as originally it wasn't reported by myself...

@pentagonik would you prefer an extra ticket for that issue?

[pentagonik]

Thanks for feedback -- no, another ticket is not necessary, I'll just fix this within this ticket.

[pentagonik]

Reproduced; should be fixed with the next available test build.

[sgrassl]

Sucessfully tested with latest test build 5.2.9r121058. Ticket can be closed.

Thanks @pentagonik!

[pentagonik]

Thanks for verifying! The fix also will be included in the next upcoming maintenance version. Closing.

[sgrassl]

I'm sorry but I have to reopen this ticket as current version 5.2.10r122406 doesn't fix this bug completely... although I have successfully tested the full fix with 5.2.9r121058.

Here are my recent test results:

	start before boot	start after boot	start before boot (existing file)	start after boot (existing file)
5.2.8r121009	ok	ok	not ok	not ok
5.2.10r122406	not ok	ok	not ok	ok

As you can see the first part of the fix is working fine in 5.2.8 but not in 5.2.10. The second part is working fine in 5.2.10.

It seems that the first part of this fix doesn't made it into 5.2.10 somehow...

@pentagonik could you please have a look at this and confirm my test results?

[Grun]

Replying to sgrassl:

@pentagonik could you please have a look at this and confirm my test results?

@sgrassl and @pentagonik - I'm seeing the same fault here with Windows 10 (64 bit) host.

Any assistance would be greatly appreciated.

[Socratis]

Can you please try with

1. the latest test builds (rev. 122553 as of this writing), and
2. with the development builds, from the same page, but on the very bottom of the page? You might see some weird things with the dev. builds, so use them to just verify or not the video recording aspect only.

[Socratis]

OK, I didn't even have the time to try the test-matrix, and 5.2.12 was released! In the Changelog it says:

• Video recording: fixed starting / stopping recording under certain circumstances

I'd say those words alone are a good enough reason to test the new version...

[Grun]

	start before boot		start after boot	start before boot (existing file)	start after boot (existing file)
5.2.12r122591	not ok	ok		not ok	ok
5.2.10r122406	not ok	ok		not ok	ok

My results on testing with Windows 10 (x64) host system. Seems that unfortunately, it is not quite fixed. Any help would be appreciated.

[sgrassl]

Did some more testing with latest release, test and dev builds:

	start before boot	start after boot	start before boot (existing file)	start after boot (existing file)
5.2.11r122553 (test)	not ok	ok	not ok	ok
5.2.12r122591 (release)	not ok	ok	not ok	ok
5.2.97r122555 (dev)	ok	ok	ok	ok

I can confirm the result from @Grun that latest release 5.2.12 didn't fix this issue. Only with latest dev build video recording works like expected.

[Grun]

Just wondering if there was any update on this ticket. I see its reopened but is it assigned?

[Socratis]

What update would that be? It seems to work for the developer builds according to 'sgrassi', no? And there haven't been any updates since 5.2.12, so I'm not quite sure what updates you were expecting...

You can keep on trying with the test/development builds, and report here if there are any changes in the current state of affairs, i.e. if something that was working, breaks. Or something that was broken, gets fixed. Not a "situation unchanged" message update, that helps absolutely no one.

Other than that, you can take a look at the timeline and see what are the source code changes, but that won't help you, because you won't know if a particular changeset will make it to the next minor, or the next major release.

That's as close as you can get to an minute-by-minute play, if that's what you had in mind...

[sgrassl]

Actually I don't want to ask this but I have to right now... This issue was reported nearly one year ago and is still not fixed. Can anyone of the responsible developers say when it will be fixed?

I can see it's working in dev builds (e.g. 5.2.97r124972) so it seems to be just a matter of time. It would be very interesting if anyone could say how much time...

[liuqunrui]

MacOS host 5.2.97r124972 crashed on stopping video capture...

Process: VirtualBoxVM [3699] Path: /Applications/VirtualBox.app/Contents/Resources/VirtualBoxVM.app/Contents/MacOS/VirtualBoxVM Identifier: org.virtualbox.app.VirtualBoxVM Version: 5.2.97 (5.2.97) Code Type: X86-64 (Native) Parent Process: VBoxSVC [3690] Responsible: VirtualBoxVM [3699] User ID: 501

Date/Time: 2018-09-29 08:57:08.959 +0800 OS Version: Mac OS X 10.14 (18A391) Report Version: 12 Anonymous UUID: C4C75F89-7917-7BF9-E78F-33B91F94813E

Sleep/Wake UUID: 7613168E-72FB-46EF-8271-4DC588253691

Time Awake Since Boot: 73000 seconds Time Since Wake: 1200 seconds

System Integrity Protection: enabled

Crashed Thread: 2 nspr-2

Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x0000000000000004 Exception Note: EXC_CORPSE_NOTIFY

Termination Signal: Segmentation fault: 11 Termination Reason: Namespace SIGNAL, Code 0xb Terminating Process: exc handler [3699]

[Socratis]

	Before boot	Before boot (existing)	After boot	After boot (existing)
5.2.19 r125384	Fails to create .webm	Fails to overwrite .webm	Works	Creates a new webm: <VM>-yyyy-mm-ddThh-mm-ss-%06dZ
5.2.97 r125396	Works	Creates a new webm: <VM>-yyyy-mm-ddThh-mm-ss-%06dZ	Works	Creates a new webm: <VM>-yyyy-mm-ddThh-mm-ss-%06dZ

So, in summary, if you enable recording (before starting the VM) fails in the current tree, it works in all other cases.

But I think that the naming logic needs to be revisited. You can't have a new file being created with the timestamp, while the original file remaining as is, it's against common sense. I can think of two scenarios that "make sense"™:

• Name everything with a timestamp. The filename/location as set in the preferences ("<VM>.webm") would serve as the basis to which the actual filename will be formed. Just as it happens right now when an .webm already exists: "<VM>-yyyy-mm-ddThh-mm-ss-%06dZ.webm". Clean, simple, logical, consistent, preferred.

• If a "<VM>.webm" exists, rename the existing "<VM>.webm" (based on its file timestamp), and create a new "<VM>.webm" file, as dictated by the settings. More convoluted, error prone, but it maintains consistency between what you set the filename in the settings to be, with what you're getting.

@liuqunrui
I think that you may indeed have a different issue after all, and that your #18011 ticket might not be a duplicate of this one, as I originally thought. You are seeing a VirtualBox crash. None of us in this ticket sees that (apparently). So, we should probably stick to #18011 and try to resolve it there. Sorry about the confusion, mea culpa...

[Klaus Espenlaub]

We'll discuss the naming proposal... going with the 2nd solution will be somewhat quirky as the only truly reliable timestamp is the last modification date (the creation timestamp isn't available everywhere, and even if available it may not be reflecting the true creation time for various reasons).

Regarding the remaining regression in 5.2: I'll poke the dev...

For the "not fixed in a year": our devs have much more to do than they have time, so everything needs to be prioritized. We had much more severe bugs for much longer. Simply a consequence of the resource limitations.

[pentagonik]

I've a look at the issue shortly.

[pentagonik]

Found and fixed the issue; I'll do some more testing tomorrow and will supply a new 5.2 test build.

[pentagonik]

Test build 125689 for VirtualBox 5.2 should contain fix -- you can get the latest test builds on the Testbuilds page. Please let me know if this fixes the issue for you. Thank you!

[sgrassl]

Tested with latest test build 5.2.19r125689 as requested but it's still the same behaviour... If I start the video capture before the virtual machine is started no capture file is created.

[pentagonik]

@sgrassl Please retry with the latest test build 125704 -- I had to integrate another fix which should make it work finally.

[sgrassl]

Tested with latest test build 5.2.19r125704 and I can confirm that starting the video capture before the virtual machine is started is working again.

Thanks @pentagonik!

[pentagonik]

Great, thanks for verifying so fast! Resolving that ticket as being fixed then.

[pentagonik]

The fix will be available in the next upcoming maintenance version.