Open unfa opened 10 years ago
It happens to me when I tell it to record audio but I don't have the appropriate audio system running. (that is, I use JACK, and when I don't have qjackctl open it does that.)
When you start the recording in SSR, SSR will actually wait until both the video and audio input start before it starts writing. This is necessary for synchronization. If your audio system never starts (for whatever reason), then you will end up with an empty file.
You can avoid this by making sure that the timer on the recording page is actually running before you continue. Maybe I should show an error message when the inputs take more than 10 seconds to start, that would also avoid problems like this
I guess even some bigger message could be good - like a red flashing box in a corner of the screen or something - so it can't be overlooked.
Yes an explicit warning that nothing is recording would be a very, very good thing. There's nothing worse than finishing the hard recording work only to realize that it's all wasted and gone. The program could for example check every second if the output file is growing in size or not (it seems to check this already maybe just monitor it for sanity).
I wonder if sound notifications help with this?
2014-07-30 13:41 GMT+02:00 MaartenBaert notifications@github.com:
When you start the recording in SSR, SSR will actually wait until both the video and audio input start before it starts writing. This is necessary for synchronization. If your audio system never starts (for whatever reason), then you will end up with an empty file.
You can avoid this by making sure that the timer on the recording page is actually running before you continue. Maybe I should show an error message when the inputs take more than 10 seconds to start, that would also avoid problems like this
— Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/227#issuecomment-50603857.
Tobiasz unfa
-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$ !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv b+>+++ DI>+ D+ G e h-->- !r y--() ------END GEEK CODE BLOCK------
There are sound notifications for all error messages (but not warnings). So a normal error would already trigger the notification.
Yes, but the sound notifications seem to leave their mark in the recording, so it's not suitable for no-editing production like simple screencasting.
2014-07-30 14:30 GMT+02:00 MaartenBaert notifications@github.com:
There are sound notifications for all error messages (but not warnings). So a normal error would already trigger the notification.
— Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/227#issuecomment-50607795.
Tobiasz unfa
-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$ !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv b+>+++ DI>+ D+ G e h-->- !r y--() ------END GEEK CODE BLOCK------
What do you mean, leave their mark? There's a delay before the recording start, the notification should not be recorded.
They were clipped but still audible on my test recording.
2014-08-01 21:34 GMT+02:00 MaartenBaert notifications@github.com:
What do you mean, leave their mark? There's a delay before the recording start, the notification should not be recorded.
— Reply to this email directly or view it on GitHub https://github.com/MaartenBaert/ssr/issues/227#issuecomment-50925649.
Tobiasz unfa
-----BEGIN GEEK CODE BLOCK----- Version: 3.1 GIT/MU/P d->-- s+:-(--)> a? C++(+++)>$ ULC+(++)>$ !P? L+++>++++$ E? W++>$ !N-? !o--? K-? !w-- O? !M-- V? PS++ PE++ !Y+ !PGP+? !t(+) 5? !X !R+ tv b+>+++ DI>+ D+ G e h-->- !r y--() ------END GEEK CODE BLOCK------
I guess it depends on the delay of the entire audio system. The current delay is sufficient for me, but maybe the ALSA-to-JACK bridge you're using adds an additional delay.
I got almost the same issue. save a emty file.
OS: Debian jessie AMD64 SSR: 0.3.0
Log:
[PageRecord::StartPage] Starting page ... [PageRecord::StartPage] Started page. [PageRecord::StartInput] Starting input ... [X11Input::Init] Using X11 shared memory. [X11Input::InputThread] Input thread started. [PageRecord::StartInput] Started input. [PulseAudioInput::InputThread] Input thread started. [PageRecord::StartOutput] Starting output ... [Muxer::Init] Using format mp4 (MP4 (MPEG-4 Part 14)). [Muxer::AddStream] Using codec libx264 (libx264 H.264 / AVC / MPEG-4 AVC / MPEG-4 part 10). [Muxer::AddStream] Using codec aac (AAC (Advanced Audio Coding)). [BaseEncoder::EncoderThread] Encoder thread started. [Muxer::AddStream] Warning: This codec is considered experimental by libav/ffmpeg. [BaseEncoder::EncoderThread] Encoder thread started. [DetectCPUFeatures] CPU features: mmx sse sse2 sse3 [Muxer::MuxerThread] Muxer thread started. [Muxer::MuxerThread] Muxer thread stopped. [DetectCPUFeatures] CPU features: mmx sse sse2 sse3 [PageRecord::StartOutput] Started output. [Synchronizer::SynchronizerThread] Synchronizer thread started. [FastResampler::Resample] Resample ratio is 1.0000 (was 0.0000).
What can i do ?
Can you send me the log file in .ssr/logs? It may contain more information.
The 'total time' is running so your inputs are OK. I suspect there's a muxing problem. I've recently made some changes to the muxing code that should improve compatibility with newer versions of libav (such as those used by Ubuntu 14.10, maybe Debian uses them too, I can't tell without the full log).
@MaartenBaert
This my full log of running ssr 0.3.0
https://gist.github.com/tannx/1297018cccc6dac88b58#file-run-full-log
You are using a version of libav that's so new it hasn't arrived in Arch Linux yet, so I haven't actually tested it. First, try recompiling the very latest SSR from the master branch. It contains a number of improvements related to libav compatibility (I do most of my testing with ffmpeg) which may be enough to solve your problem.
I guess it's just the header.
My MKV file after about an hour of recording is 3,4 kB is big. Can't hide I'm not happy with this. It happened before when I used other programs like Kazam.
Any idea what can cause this?
I have no SSR log, but here's the hexdump of produced MKV file: