[closed] Saving FLV Recording Crashes

[Brad Pikkaart]

This may not be a bug as I haven't seen anything else about this in the forums (although I may have missed it), so perhaps it's just me. But, I am running VidBlaster Home v1.07, and I am unable to successfully save an .flv recording. Every time I go to save it, it starts the process of converting/saving the file, and after it makes it partway through, I get "ffmpeg.exe has encountered a problem and needs to close." It actually saves part of the recording (the part that was rendered prior to the crash), but not the whole thing. I can save .wmv recordings just fine. Any suggestions?

[Mike]

Please read the FAQ before posting, it says you should confirm the bug in the latest beta before reporting it. Have not had any reports, but not sure how many actually use this format.

[Brad Pikkaart]

Sorry Mike. I did try the latest beta version today (v1.11), and it had the same problem - it crashed about 3/4 of the way through the encoding process when trying to save the .flv. However, it also seems that this beta version puts a greater strain on the CPU, as the CPU was pretty much pegged around 95% during the entire broadcast. Using v1.07, my typical CPU utilization was around 20-25% less during a standard broadcast. It might be the recording module, as when I stopped recording, CPU utilization dropped to around 30%.

Just so you know, on every broadcast I do, I use the streaming module to stream to a FMS, I use the recording module, 1 camera module, 1 video overlay module and the program module.

For now, I'm going to downgrade back to v1.07 simply because of the CPU utilization problem. I can get around the .flv saving issue by saving the file as a .wmv and converting it in a different program. But, that is certainly not ideal. Any suggestions?

[Mike]

Not right now. Version 1.11 has had several reports that it uses less CPU, so I am surprised about that remark. Perhaps you changed a setting without realizing? If you really see an increase you should not ignore it as I won't be able to fix it, instead you should mention it in a bug report.

[Brad Pikkaart]

Mike, I will post a new bug report, but I'd first like to do some testing to confirm that this is really an issue. At this point, I've only tried the new version once. I'll keep you posted on that. In the meantime, if anyone has any insight into saving .flv recordings, I'd appreciate it!

[Mike]

I am unable to reproduce this problem and had no other complaints, so I am closing this for now. I suggest trying a clean system, the only explanation I can come up with is buggy codecs on your system, either from other applications or codec packages.

[Allan Bunt]

I am having this fault now. UPDATE: This is a 1 hour recording that am trying to save. Over 500MB.

And I get a message that ffmpeg.exe has stopped working (see screen cap).

VB does not crash and I can save as WMV ok. Just the FLV save stops. I saved the log file and here is the last paragraph before I shut VB down;

bitrate=2303.3kbits/s    8:24:17 PM frame=73447 q=0.0 size=  824795kB time=2933.6 bitrate=2303.3kbits/s    8:24:17 PM frame=73531 q=0.0 size=  825693kB time=2936.8 bitrate=2303.2kbits/s    8:24:17 PM Internal buffer inconsistency. flushbits <> ResvSize
8:24:17 PM bit reservoir error: 
l3_side->main_data_begin: 1048 
Resvoir size:             -98856 
resv drain (post)         0 
resv drain (pre)          0 
header and sideinfo:      288 
data bits:                1204 
total bits:               1492 (remaind
8:24:17 PM er: 4) 
bitsperframe:             1672 
This is a fatal error.  It has several possible causes:90-0X1.#QNAN0P+0ME compiled with buggy version of gcc using advanced optimizations 9Your system is overclocked 1bug in LAME encoding libraryInternal buffer in
8:24:17 PM consistency. flushbits <> ResvSizeInternal buffer inconsistency. flushbits <> ResvSize
8:24:17 PM Internal buffer inconsistency. flushbits <> ResvSize
8:24:17 PM Internal buffer inconsistency. flushbits <> ResvSize
8:24:41 PM TEncode::ToFlv exit

Is this in VB or external Mike? I only started using this after v1.19 so can verify any other versions

[Mike]

The problem is in ffmpeg, it offers multiple potential causes including system unstability, memory shortage or faults and I'd like to add hard drive full. None of which seem very likely? Can you reproduce this on your system, or is it random?

Why do you use this feature? It is a remnant of old podcast times and if it causes any problems my first instinct is to simply remove it.