Announcement

Collapse
No announcement yet.

G400-TV MPEG Encoding switches from colour to B&W

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • G400-TV MPEG Encoding switches from colour to B&W

    System:

    Gigabyte 5AX Motherboard
    AMD K6-2 350 CPU
    128 Meg memory
    G400-TV Video Card
    Soundblaster PCI 64
    Fujitsu 10.8 and 6.4 Gig HD

    I have the PAL version of the G400-TV card. I can capture to AVI files without problems. The audio/video looks and sounds great during the capture and during the playback of the AVI files. Colour and audio are very good.

    However when I use the LSX-MPEG encoder to convert the file to MPEG1, the encoding will all of a sudden change from colour to black & white. Sometimes it will revert back to colour but generally once it switches to B&W - that's it for the rest of the encoding session.

    I thought the problem was with the LSX-MPEG software. However, the same problem occurs as well with the Xing and Panasonic encoders. I have tried capturing in 352 x 288 and 352 x 576 PAL format. Both formats have the same problem when using the MJPEG encoder of the G400-TV. The capture starts off in colour and then switches to B&W.

    If I capture the same video WITHOUT COMPRESION using AVI_IO, all three encoders have no problems encoding the file to VCD/MPEG - PAL format. The encoding stays in colour for the whole file. Capturing without compression works fine but of course the files are huge and I'm unable to capture all of what I want before I run out of disk space.

    Other than that, the G400-TV is working fine. It consistently captures video without dropping frames or if it does - maybe 1 in several thousand.

    Right now I'm dead in the water capturing (until I get that 37 gig IBM drive).

    Maybe this is a problem with the PAL version of the G400-TV. I image that if the same problem occured with NTSC, I would have found mention of this in the forum.

    Anyone have this problem? Any suggestions?

    Thanks - ChuckM

  • #2
    Chuck,

    I just saw your problem and ran a test. I captured 30 seconds of BBC news from the TV tuner at 352*288 PAL, 25fps dropping 1 frame out of 790. This with minimum compression (4.1:1) using the RRICM codec.

    I then used Ligos LSX to encode the clip into MPEG1 352*288, 25 fps using the settings provided (video 1198Kbits/s). I watched it encode without any switch to B&W, and the resulting MPG doesn't have any problems either.

    Although I do have a problem with my sound on that machine at the moment (I've been messing about, probably pulled a connection out somewhere).

    PC used P2 266, 96Mb RAM, Aopen AX6L mobo, 4.3 (partitioned) and 8.4 Fuji drives, Win98 (original).

    Any other info you can give me ?

    Comment


    • #3
      I had that happen to me once. It changed right at a droped frame. I figured the glitch in the video must have switched a bit and lost the color. That's my guess at least.

      Comment


      • #4

        I just experimented with my NTSC SC converter. I converted the same video from PAL to NTSC and captured in NTSC 352 x 240 format and then encoded with Xing and LSX-MPEG. Both encoders had no problems with the NTSC format. The entire MPEG1 files are in colour. Thus the problem seems that it must lay with the Matrox PAL MJPEG capture.

        However, this isn't a solution. The colour coming out of my NTSC converter looks washed out compared to the PAL input.

        I also found a news group article from a G400-TV user in France who had the same problem with his SECAM captures. It looks like the MJPEG capturing works OK as long as you are doing it in NTSC format.

        Usually, it takes more than 30 seconds for the switch from colour to B&W to occur - sometimes several minutes. Short captures are usually OK. I was trying to convert some of my Babylon 5 VHS PAL tapes to VCD. Sometimes I can capture with no drops and the problem still occurs. If I capture uncompressed with drops or no drops, the encoding of the uncompressed file is OK.

        I think scene changes might be triggering the problem. On my last Bab 5 PAL recording, it happens consistently when the Narn fighters blast the Centuri space station. You see the explosions and then the video switches from colour to B&W.

        I think Matrox needs to look at their MJPEG encoder for PAL and SECAM captures.

        Is it possible to use another MJPEG encoder other than the Matrox encoder?

        Thanks - Chuck.

        Comment


        • #5
          I just experimented with my NTSC to PAL converter. I converted the same video from PAL to NTSC and captured in NTSC 352 x 240 format and then encoded with Xing and LSX-MPEG. Both encoders had no problems with the NTSC format. The entire MPEG1 files are in colour. Thus the problem seems that it must lay with the Matrox PAL MJPEG capture.

          However, this isn't a solution. The colour coming out of my NTSC converter looks washed out compared to the PAL input.

          I also found a news group article from a G400-TV user in France who had the same problem with his SECAM captures. It looks like the MJPEG capturing works OK as long as you are doing it in NTSC format.

          Usually, it takes more than 30 seconds for the switch from colour to B&W to occur - sometimes several minutes. Short captures are usually OK. I was trying to convert some of my Babylon 5 VHS PAL tapes to VCD. Sometimes I can capture with no drops and the problem still occurs. If I capture uncompressed with drops or no drops, the encoding of the uncompressed file is OK.

          I think scene changes might be triggering the problem. On my last Bab 5 PAL recording, it happens consistently when the Narn fighters blast the Centuri space station. You see the explosions and then the video switches from colour to B&W.

          I think Matrox needs to look at their MJPEG encoder for PAL and SECAM captures.

          Is it possible to use another MJPEG encoder other than the Matrox encoder?

          Thanks - Chuck.

          Comment


          • #6
            I've done some 704x480 NTSC captures that have the same problem. Whenever it happens, I'm lucky if I can even open the AVI in Premiere (or LSX or VirtualDub) to work with it. I usually get an illegal operation when I try to do so.

            The file plays back fine in Media Player but switches from color to b&w after about a second or two when I look at with an editor...

            Comment


            • #7
              ChuckM I still have the same problem as you describe. I hope someone has a solution to fix this problem. I called Matrox Germany and asked if they knew about the problem but the operator sayed to me that I have to search for the problem in my hardware configuration. I did this but all works fine, only capturing with my RR-G produces error like you describe. I need help!!!!

              Here my Hardware
              Celeron 300@464
              Abit ZM6
              64MB
              G400 DH + RR-G
              Soundblaster Live
              Symbios SCSI
              IBM 15 GB
              IBM 6.4 GB

              Bender

              Comment


              • #8
                Chuck,

                I'll have to do some more at this end then. I've just uninstalled the G400 (wouldn't ya just believe it !), so I'll have to refit this PC with it tomorrow - If I get it wrong I'll probably be away for a couple of days, I normally manage to at least lose my email).

                I don't think it's PAL specific from the other comments, but from your own evidence it seems to me as if a "hot" frame is knocking the codec out somehow. Kinda like the "rogue frames" that Patrick was talking about in a different thread.

                You could try editing the footage and killing that frame.

                Comment


                • #9
                  Hello T_I,

                  I think it's still PAL and SECAM related at least because it happens MUCH MUCH more often when recording in PAL format.. I tried one VHS tape that had several switches from colour to B&W and back to colour and so forth when recording in PAL format. With recording using the same tape, same VCR, same cables in NTSC format - no problems! The MPEG1 encoded file was entirely in colour.

                  If the Colour/B&W switch happened this often in NTSC format, I would have hoped that Matrox Quality testing would have caught the error. I suspect they didn't do much testing in PAL and SECAM formats...

                  As I said, converting my PAL signal to NTSC seems to work just fine except for the less brilliant colours. I may try another PAL - NTSC converter and see if I can get better colour or I may check out one of those NTSC colour enhancers I see advertised by Sima corporation in the US. Maybe using a colour correction in combination with the PAL - NTSC converter will give me what I want.

                  I was thinking about getting a 37GB IBM drive and capturing uncompressed but the G400-TV has too many drops if I take the resolution up to 352 x 288. From what I understand it has a transfer rate of about 3mbs which is too low to capture anything of reasonable quality video.

                  My previous cheapie TV Tuner card did a better job in recording that this expensive dud ($479 US in Australia). I wish I could return the thing and buy a Pinnancle DC10 Plus which at least can capture uncompressed at a much higher rate. (They're about the same price in Australia) Until Matrox fixes the encoding problem, I would not recommend this card to anyone using PAL/SECAM.

                  Before I give up on this card, I have a few of questions...

                  1. I know it's a "rogue" frame causing the
                  problem. I get a flash of colours when
                  the switches occurs. You mentioned
                  editing out the bad frame. What editor
                  would you suggest to edit the MJPEG file?

                  2. Having to do this would be very time
                  consuming. Would anyone know of a
                  utility which removed "bad" frames from
                  the MJPEG file? I suppose it would
                  have to read in the AVI file and create
                  another (good) AVI file. This would
                  increase the disk usage by double so I'd
                  probably have to get that IBM drive
                  afterall.

                  3. I have tried Panasonic, Xing, and LSX-
                  MPEG MPEG1 encoders. They all choke
                  when they hit the bad frame. Does anyone
                  know of any other encoders that
                  might be more "fault tolerant"?

                  4. Is it possible to use another encoder
                  than the supplied Matrox encoder. I
                  have heard something about a "Morgan"
                  encoder. Could it be used with the
                  G400-TV?

                  Thanks - Chuck.

                  Comment


                  • #10
                    I have noticed exactly the same problem - and it has already been discussed in this forum. The error message that all editors display when it tries to look at the problem MJPEG files is the RRCIH (or something like that) thing that has already been established as a problem with the MJPEG to RGB process when a capture has a dropped frame. I think Haig said this, and that it is being looked at for the next driver upgrade.

                    Just as a side note, EVERY capture I have made has dropped frames - at a rate of about 1% of the total captured. And that is just at quarter size resolution with MJPEG compression! I tried all the obvious - separate drive just for video, DMA, high score in HD benchmark. No luck. This is proving very irritating, especially in conjunction with the b/w problem being discussed here.

                    Hope this is sorted out soon...

                    Comment


                    • #11
                      Maybe you're right and it's the same PAL "wibble" that has been reported causing the jitters during playback.

                      If so, it's sposed to be fixed in the next driver release (or that's what's been posted here, I haven't heard anything officially).

                      Haig/Olliver, can you comment on this at all?

                      Comment


                      • #12
                        I believe I have circumvented the problem by using the Morgan codec rather than the Matrox codec. I was able to succesfully convert a problem tape to PAL VCD Mpeg1 without any colour switching. The same tape with the Matrox codec resulted in a number of switches.

                        I'll keep testing by converting more VHS tapes to VCD and report back in a few days whether the problem has been satisfactorily solved.

                        You can get the Morgan codec at:
                        http://www.morgan-multimedia.com

                        It was easy to install. Just comment out the VIDC=RRICM.DLL and add the morgan codec to your system.ini file and copy the M3JPEG32.DLL file to your Windows/System directory.

                        Thus far both Xing and LSX Mpeg encoders haven't performed any switching from colour to B&W. The output from the Morgan codec seem s better than the Matrox. LSX-MPEG is reporting better "video quality" when it encodes the file.

                        I'll see how Matrox does with their updated drivers. For now, I'll register the codec as it expires by year end. The charge is $25 US.

                        Maybe Matrox will pick up the bill?

                        Cheers, Chuck

                        Comment


                        • #13
                          Hi,

                          Chris is correct, the next driver release will have addressed the issue of corrupted frames and the B&W after effect.

                          I can't give anyone an exact date as to when this driver will be released, though it shouldn't be too much longer.

                          Olliver
                          All comments and statements are purely of my own opinion and in no way reflect on my employer.

                          Comment


                          • #14
                            Thanks for the input Olliver, I'm glad (?) that this looks like the same problem.

                            I haven't heard of any rumours on release dates for new VT's but then the last couple of releases have caught me cold-footed. Maybe I'm losing my touch or perhaps I'm catching a cold.

                            I'll investigate and see if I can find something

                            Comment

                            Working...
                            X