VirtualBox

Ticket #17307 (closed defect: fixed)

Opened 12 months ago

Last modified 5 weeks ago

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

Reported by: sgrassl Owned by: pentagonik
Priority: major Component: other
Version: VirtualBox 5.2.0 Keywords: video capture
Cc: Guest type: Windows
Host type: Windows

Description

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.

Attachments

VBox.log Download (153.2 KB) - added by sgrassl 12 months ago.
VBoxHardening.log Download (354.6 KB) - added by sgrassl 12 months ago.

Change History

Changed 12 months ago by sgrassl

Changed 12 months ago by sgrassl

comment:2 follow-up: ↓ 3 Changed 10 months ago by 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.

comment:3 in reply to: ↑ 2 Changed 10 months ago by 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 216-1 or 65535.

comment:4 Changed 10 months ago by socratis

@st2135
Impressive detective work there!

comment:5 Changed 10 months ago by pentagonik

  • Owner set to pentagonik
  • Status changed from new to assigned

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

comment:6 Changed 10 months ago by pentagonik

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

comment:7 Changed 9 months ago by pentagonik

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

comment:8 Changed 9 months ago by 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?

comment:9 Changed 9 months ago by pentagonik

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

comment:10 Changed 9 months ago by pentagonik

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

comment:11 Changed 9 months ago by sgrassl

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

Thanks @pentagonik!

comment:12 Changed 9 months ago by pentagonik

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

comment:13 Changed 9 months ago by pentagonik

  • Status changed from assigned to closed
  • Resolution set to fixed

comment:14 follow-up: ↓ 15 Changed 7 months ago by sgrassl

  • Status changed from closed to reopened
  • Resolution fixed deleted

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?

comment:15 in reply to: ↑ 14 Changed 6 months ago by 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.

comment:16 Changed 6 months ago by 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.

comment:17 Changed 6 months ago by 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...

comment:18 Changed 6 months ago by Grun

start before bootstart 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.

Last edited 6 months ago by Grun (previous) (diff)

comment:19 Changed 6 months ago by 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.

comment:20 Changed 6 months ago by Grun

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

comment:21 Changed 6 months ago by 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...

comment:22 Changed 2 months ago by 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...

comment:23 Changed 7 weeks ago by 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]

comment:24 Changed 7 weeks ago by 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...

Last edited 7 weeks ago by socratis (previous) (diff)

comment:25 Changed 5 weeks ago by klaus

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.

comment:26 Changed 5 weeks ago by pentagonik

I've a look at the issue shortly.

comment:27 Changed 5 weeks ago by pentagonik

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

comment:28 Changed 5 weeks ago by 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!

comment:29 Changed 5 weeks ago by 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.

comment:30 Changed 5 weeks ago by pentagonik

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

comment:31 Changed 5 weeks ago by 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!

comment:32 Changed 5 weeks ago by pentagonik

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

comment:33 Changed 5 weeks ago by pentagonik

  • Status changed from reopened to closed
  • Resolution set to fixed

comment:34 Changed 5 weeks ago by pentagonik

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

Note: See TracTickets for help on using tickets.

www.oracle.com
ContactPrivacy policyTerms of Use