VirtualBox

Opened 6 years ago

Closed 5 years ago

Last modified 5 years ago

#17307 closed defect (fixed)

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

Reported by: sgrassl Owned by: pentagonik
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 (2)

VBox.log (153.2 KB ) - added by sgrassl 6 years ago.
VBoxHardening.log (354.6 KB ) - added by sgrassl 6 years ago.

Download all attachments as: .zip

Change History (36)

by sgrassl, 6 years ago

Attachment: VBox.log added

by sgrassl, 6 years ago

Attachment: VBoxHardening.log added

comment:2 by Socratis, 6 years ago

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.

in reply to:  2 comment:3 by st2135, 6 years ago

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 by Socratis, 6 years ago

@st2135
Impressive detective work there!

comment:5 by pentagonik, 6 years ago

Owner: set to pentagonik
Status: newassigned

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

comment:6 by pentagonik, 6 years ago

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

comment:7 by pentagonik, 6 years ago

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

comment:8 by sgrassl, 6 years ago

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 by pentagonik, 6 years ago

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

comment:10 by pentagonik, 6 years ago

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

comment:11 by sgrassl, 6 years ago

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

Thanks @pentagonik!

comment:12 by pentagonik, 6 years ago

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

comment:13 by pentagonik, 6 years ago

Resolution: fixed
Status: assignedclosed

comment:14 by sgrassl, 6 years ago

Resolution: fixed
Status: closedreopened

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?

in reply to:  14 comment:15 by Grun, 6 years ago

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 by Socratis, 6 years ago

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 by Socratis, 6 years ago

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 by Grun, 6 years ago

start before bootstart after boot start before boot (existing file) start after boot (existing file)
5.2.12 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 after the ticket was closed it was listed as fixed for the changelog but unfortunately it is not quite fixed. Again. Any help would be appreciated.

Version 0, edited 6 years ago by Grun (next)

comment:19 by sgrassl, 6 years ago

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 by Grun, 6 years ago

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

comment:21 by Socratis, 6 years ago

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 by sgrassl, 6 years ago

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 by liuqunrui, 5 years ago

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 by Socratis, 5 years ago

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 5 years ago by Socratis (previous) (diff)

comment:25 by Klaus Espenlaub, 5 years ago

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 by pentagonik, 5 years ago

I've a look at the issue shortly.

comment:27 by pentagonik, 5 years ago

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

comment:28 by pentagonik, 5 years ago

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 by sgrassl, 5 years ago

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 by pentagonik, 5 years ago

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

comment:31 by sgrassl, 5 years ago

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 by pentagonik, 5 years ago

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

comment:33 by pentagonik, 5 years ago

Resolution: fixed
Status: reopenedclosed

comment:34 by pentagonik, 5 years ago

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

Note: See TracTickets for help on using tickets.

© 2023 Oracle
ContactPrivacy policyTerms of Use