Toast 8.0.3 in 10.5.1 leaking memory when multiplexing?

[Paul Hagstrom]

I'm using Toast 8.0.3 on Leopard (10.5.1), and what I'm doing is this: I take a number of files, which are already muxed MPEG2 with 48K audio (meaning: no reencoding needed, though Toast will still do the multiplexing step anyway), and add them to the DVD-Video pane.

 

I save the video disc out as a disc image, which I will burn later (with the verification pass).

 

What I observe is that although everything works just fine, when the procedure is over, Toast is using about 1.5GB of virtual memory. That's a lot of virtual memory. And if I then make a second disk image with different files (without quitting Toast in-between), the result is now 3GB of virtual memory used.

 

Something's not right here. Toast 7 never did anything remotely like that, and the fact that the memory is not released when the image has been created suggests to me that it's a real memory leak somewhere, presumably in the multiplexing step.

 

For reasons I don't fully understand, this doesn't seem to bog down my system really -- I think Toast must be reserving the memory but then never (or very rarely) accessing it again. But for now, I quit and relaunch Toast after every such disc image I make to keep the VM usage under control.

 

Does anyone else see this? (Is this something unique to something in my configuration, or is this just a bug in 8.0.3?)

[Atlantic]

Toast 8 has always crashed for me if I try to burn multiple disc images without quitting Toast first. Sometimes it will manage two images, sometimes only one, but it is reproducible up to 8.0.3 (and also in Popcorn, including its latest update). I normally drag in video from EyeTV (not using the media selector in Toast, though, just by dragging) though it also happens if I take folders from existing images and add them again (by mounting the disc image and dragging the video files into a new video DVD image). I assumed it was some kind of memory leak issue, but have now taken to quitting Toast after each encode and then starting it again. I never burn with an encode after I got too many coasters, so now I only burn disc images and then burn those (much less unreliable). Does anyone know if Roxio have acknowledged this issue?

[sjkrox]

Does anyone else see this?

What you're describing instantly reminds me of this long outstanding problem.

 

Toast 7 + Eyetv = 100% Virtual Memory (!)

 

Since that's never been resolved or explained to my satisfaction I really don't have help to offer (plus I'm still running 10.4.11).

 

I'm quite curious, what's the origin of your MPEG-2 files?

[Paul Hagstrom]

What you're describing instantly reminds me of this long outstanding problem.

 

Toast 7 + Eyetv = 100% Virtual Memory (!)

 

Interesting. My problem seems less dramatic -- a lot of VM is being used, but I have never had it reach 8GB or had a crash. Also, the VM is released after quitting Toast. I've never experienced the problem before Toast 8, either, using pretty an much identical burning situation (same video files, in the same locations, etc.)

 

I'm quite curious, what's the origin of your MPEG-2 files?

 

The MPEG-2 files are generally ones that I converted myself from DivX or Xvid, using ffmpeg or mpeg2enc at half-D1 size. Different ones have different framerates (29.97 NTSC, 25 PAL, 23.976 FILM), but they are generally 4:3 352x480 (NTSC/FILM) or 352x576 (PAL) muxed with 224 kbps 48KHz MPEG 1 layer 2 audio.

 

Specifically (ffmpegX generated this for me, but I now run it from the command line), the most common thing I do is this (takes a 23.976 16:9 source and converts it to a letterboxed 352x480 mpv file with 3:2 pulldown enabled, encodes 48K audio, and multiplexes it)

 

video:

 

ffmpeg -i inputfile.avi -y -f yu4mpegpipe -s 352x480 -map 0.0:0.0 -r 23.976 -an - | yuvscaler -v 1 -M BICUBIC -n n -m WIDE2STD -O SIZE_352x480 | mpeg2enc -v 1 -f 8 -F 1 -a 2 -b 2300 -q 5 -I 0 -M 2 -V 230 -S 9999 -d -p -o outputfile.mpv

 

audio:

 

ffmpeg -i inputfile.avi -y -vn -f mp2 -acodec mp2 -ab 224 -ar 48000 -ac 2 -map 0.1:0.0 outputfile.mpa

 

multiplex:

 

mplex -V -S 0 -f 8 -O 0 -b 230 -o outputfile.mpg outputfile.mpv outputfile.mpa

 

This is probably more than you needed to know, but it does mean that pretty much all of the MPEG2 files I deal with are fairly uniform. It's possible, perhaps, that there's something funny about the headers that mplex (which I suspect more) or mpeg2enc (which I suspect less) creates that trips Toast up in some kind of subtle way.

 

I also have not tried this with demultiplexed files on Toast 8.0.3, perhaps that would make a difference. If I get a chance soon I'll try it and report back.