Rendered MJPEG freezes

[Lalaith]

I am using Media Studio 6.0 pro on Windows XP SP2 and observe a strange problem when rendering a MJPEG video for export to VHS cassette. At a seemingly arbitrary position, the MJPEG video image freezes during play while time counter and sound proceed as normal. This is somehow based in the video itself and occurs in the MS Media Viewer, the Electronic Desogn Video Cockpit or any other video viewer used.

The problem is reproducable when rendering again the same project; altering or shortening the project may either relocate the freezing position or, if I am very lucky, remove it sometimes. The trouble also seems to be independent of the codec used because I observed it both using the MainConcept or the Morgan MJPEG codec. Changing codec settings also did not help, nor did running Media Studio 6.0 pro under Windows 98/ME compatibility mode, even though rendering always worked fine under Windows ME.

Can anyone offer a solution (other than buying an upgrade which may or may not solve it)?

Despaired,

- Lalaith

[DVDDoug]

I've had a similar problem due to corrupted MPEGs. (I was using Video Studio with "regular" MPEG-2 files.)

You used two different codecs, so you files should be OK... Did you edit the MJPEGs after encoding them?

I could consistantly get corrupted MPEGs by editing them. I call it "sneaky" corruption, because the file plays fine with Windows Media Player, and usually plays OK in VideoStudio. But, sometimes Video Studio would crash, and if it didn't the "sneaky" corruption would result in DVDs with the infamous "lip-sync" problem.

[Devil]

Certainly sounds like the original capture file is somehow corrupt.

What did you capture and how? Did the capture software display any dropped frames? A typical cause of problems of this nature may be frame dropping due to poor quality input (e.g., old VHS tapes) which may require time base correction, setting your capture settings too high or hard disk problems.

[Lalaith]

The procedure was just simple: I cut and edited DV1-scenes that I imported from my digital video camera, and I exported them as an MJPEG file that I want to view, unaltered, using Media Player, VideoCockpit, or any other video viewer. The export with MS6 works fine on my old Windows ME, but on Windows XP SP 2 most of the time the MJPEG file gets corrupted in the way I described. The corruption is in the MJPEG itself and not a problem of the system, for I copied one today onto my old Windows ME computer, and there as well the image froze at the expected point with the time-count and the sound proceeding as usual.

I tried with the LEAD MJPEG codec and the error still occurs. The only way for now to circumvent it seems to be to slice the project into units of 5 to 10 minutes length. But that of course is no practical solution nor a guarantee that it will work then.

Help!

- Lalaith

[Devil]

The obvious question stems from the rendering to MJPEG; why are you doing it? There are a number of more usual distribution formats (MPEG-1/2, Cinepac, Indeo etc.) if you need a compression level higher than DV. If the same thing happens with these, then we would have a better clue.

You have not filled in the requested system details in your profile, which makes life difficult for those trying to help you. Why don't you do it?

My guess - and it is only a guess - is that you have a bottleneck somewhere in your system. This is likely due to something to do with your hard drive(s), such as using an external drive or having insufficient temp file capacity, trying to do too many things at the same time on different clusters of the same drive (e.g., reading software, reading codec, using temp files, using swap files, writing the resultant file, etc., especially if the drive is fragmented). This is not an exhaustive answer.

[Lalaith]

The obvious question stems from the rendering to MJPEG; why are you doing it? There are a number of more usual distribution formats (MPEG-1/2, Cinepac, Indeo etc.) if you need a compression level higher than DV. If the same thing happens with these, then we would have a better clue.

Because I have to copy the rendered movie to VHS cassettes, and MJPEG is the only format my video-card (ANDI, a German product) tolerates.

You have not filled in the requested system details in your profile, which makes life difficult for those trying to help you. Why don't you do it?

Sorry; I will do that shortly.

My guess - and it is only a guess - is that you have a bottleneck somewhere in your system. This is likely due to something to do with your hard drive(s), such as using an external drive or having insufficient temp file capacity, trying to do too many things at the same time on different clusters of the same drive (e.g., reading software, reading codec, using temp files, using swap files, writing the resultant file, etc., especially if the drive is fragmented). This is not an exhaustive answer.

This again seems unlikely, because I never had such problems on an old computer with Windows ME and much smaller capacities.

- Lalaith

[Devil]

The only suggestion left is to use a lower quality MJPEG format. Your card probably uses a hardware decompressor and it may not be able to handle high bitrates in real time.

On the rare occasions when I need to make a VHS tape, I export the DV stream from the timeline to a D>A converter (I use the Canopus ADVC-100), so no format conversion is needed.

[Lalaith]

The only suggestion left is to use a lower quality MJPEG format. Your card probably uses a hardware decompressor and it may not be able to handle high bitrates in real time.

On the rare occasions when I need to make a VHS tape, I export the DV stream from the timeline to a D>A converter (I use the Canopus ADVC-100), so no format conversion is needed.

That does not explain, alas, why there is little trouble with videos that are shorter than 10 min. I have tried lower quality already, and that, quite interestingly, shifted the position where the image freezes around in the file but did not remove it.

BTW, I have now entered some details into the hardware profile.

- Lalaith

[Greg]

Actually, it may well explain why there is no problem with shorter clips. You said lower bit rates shifted the position of freezing, shifts it which way, ie increase bit rate results in shorter output and lower bit rates result in longer output? vice versa? random.
If the first option, here's what may be happening. If the card is trying to do real time decompression, it is receiving the source on the input, and outputting the compressed data, but is getting input faster than it can output, no problem, it can buffer the input. However the more it receives, the more it has to buffer. Once the buffer is full, it cannot receive any more data, and freezes. If input stops before the buffer is full, it can complete the transcode.
Many people will have seen the error message when capturing from an analogue source "flushing transcode buffer" (or words to that effect). It is the same thing happening in reverse.

Regards,
Greg

[Devil]

I tried to find some details about your ANDI card but haven't positively succeeded. It appears to be made by AJECO OY (INC) TAKKATIE 7 A, FIN-00370 HELSINKI, FINLAND. If it bears any resemblance to the ANDI-FG, which is a video frame grabber (analogue in only), you will have to make sure it is DMA-enabled and with no IRQ conflict, because it uses RAM for buffering over and beyond the 1 Mb luma buffer and 1 Mb chroma buffer on the card. Certainly, your description is symptomatic of buffer overflow. What would be worse would be if it tried to use the swap file to counter insufficient buffer space available in your RAM; does your hard disk start turning abnormally during the video out operation?

One thing does seem abnormal with your hardware set-up: 512 Mb for use with dualies is a little weak for video work. I suggest you add at least as much again, making sure you have matched pairs of memory cards (see the m/b instruction manual).

[Lalaith]

I tried to find some details about your ANDI card but haven't positively succeeded. It appears to be made by AJECO OY (INC) TAKKATIE 7 A, FIN-00370 HELSINKI, FINLAND. If it bears any resemblance to the ANDI-FG, which is a video frame grabber (analogue in only), you will have to make sure it is DMA-enabled and with no IRQ conflict, because it uses RAM for buffering over and beyond the 1 Mb luma buffer and 1 Mb chroma buffer on the card. Certainly, your description is symptomatic of buffer overflow. What would be worse would be if it tried to use the swap file to counter insufficient buffer space available in your RAM; does your hard disk start turning abnormally during the video out operation?

One thing does seem abnormal with your hardware set-up: 512 Mb for use with dualies is a little weak for video work. I suggest you add at least as much again, making sure you have matched pairs of memory cards (see the m/b instruction manual).

That is probably not the same one. This ANDI was produced by Electronic Design GmbH, a German company that has years ago collapsed (for obvious reasons IMHO). It is thus no longer on the market. A former employee, though, offers XP drivers for download on his private homepage, such as DUAL3000CPU.EXE.

As for the hard disk, no, there I do not observe anything abnormal. One thing may be interesting, though: There are moments during rendering when in the preview screen, the calculations of estimated and used memory are set back to zero. This usually occurs when the file approaches about 4 GB; but the corruption also appears in files that are smaller than that. So these are probably two unconnected phenomena.

The position of freezing seems to shift somewhat at random when the bit rate is increased or decreased. Most of the time, though, I observe it close to the end of the MJPEG. Only now I had a project that was about 45 minutes long when I noticed the freezing position after 1/3 of the movie; cutting it down to 30 minutes (selecting from the middle of the project, not its beginning) shifted it to 3/4, with 10 to 15 minutes it did not occur at all.

But what I do not understand about this problem is that MP6 produces error-free MJPEGS on my old system that has only 256 MB working memory and Windows ME!

- Lalaith

[Devil]

Ah! Now we are getting down to the nitty-gritty. I've seen this kind of thing before, but with a Matrox Marvel G200 or G400 card, which also used a hardware MJPEG codec, and possible date from the same era as your's. It is even possible that they used the same chipset, as there weren't many ones available. Pun intended, Marvel was marvellous with WIN98, 98SE and ME but simply would not work with WNT4, W2k or XP. Matrox tried like hell to sort out this problem and brought out a Marvel G-450 that used a different chipset and software codecs, but they failed miserably to get the older ones working with the NT core. This caused them a terrific loss of goodwill, exacerbated by an offer to upgrade existing users to the G-450 model at a special price which was higher than the high-street shop price for it.

Now, a few guys thought they could do better than Matrox and a rash of attempts were made to produce drivers for the old models that would work with W2k, extant at that time, with varying degrees of failure. One guy, I think in Poland or Russia, did succeed to some extent, but I think it failed with XP. I had a Marvel G-200 but I ditched it years ago because it was unusable with W2k.

I seriously suggest that the time may have come to give this card an honourable retirement. The question arises with what to replace it. There are many graphics cards which offer a video-out feature, with various degrees of quality. I am unable to discuss their relative merits. However, as you are working in DV, I seriously suggest you use a DV>analogue converter, rather than a graphics card which will force a double conversion and potential loss of quality. My suggestion would be the Canopus ADVC-110 which simply plugs into your IEEE-1394 card. It offers really hassle-free analogue in and out, to and from DV. It is fully compatible with MSP6.5, 7.n and 8,0 and allows you to see the video as scrubbed on the timeline, previews and judging effects, on a TV screen, as you are editing.

[Lalaith]

Thank you!

It seems that the decompression bitrate was after all a hint into the right direction. I sniffed into my computer's BIOS and found there an option "HDD acoustic output" which allows you to regulate the HDD's performance against the noise it produces (!?! only a GERMAN engineer could ever produce SUCH an idea!). The factory setting was "off - for older drives". I switched to "performance", that is highest speed and noise, and lo and behold! a 30 minute MJPEG rendered error-free. Who would have thought that?

Besides, switching off the automatic setting of system recovery points seems to assist, too!

Now a final question that is, though, marginal: As soon as the rendered MJPEG approaches 5.2 GB, MP6 stalls the rendering and pretends by an error message, there was no more disk space available. This is clearly a lie, for there are still 10+ free GBs on that same partition. Now, I could explain that with an incompatibility if the rendering stopped at 4 GB; but why 5.2? Is there somewhere an option or a patch to remove this blockage?

- Lalaith