Announcement

Collapse
No announcement yet.

Some video questions: weird MPEG2 files

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

  • Some video questions: weird MPEG2 files

    I'm backing up data, splitting avi's in multiple CDs and trying to tame those pesky Mpeg2 files.

    I have particular problems with this file and I don't know what exactly to do with it.

    - it's a 4x3 TV capture
    - now check this out, pixel format: 480H x 576V px?!? 0_o x 25fps Why do you make a 3 : 4 TV capture in such weird format with non 1:1 pixel aspect ratio?
    - Audio 224kbps Layer II 44kHz stereo
    - File Size 735MB, I'd like to make the target 716MB to fit on one cd
    - another problem with the file is that it has black border so it needs cropping and resizing. I plan to dump a few frames with frontal views of objects such as squares, circles and letters O and C to find out the target true aspect ratio by measuring x and y pixel distance.

    I'm toying with this in VirtualDubMod.

    Now here's the problem:
    I set the target size to 768x576px, try few settings of XVID MPEG4 codec and audio from 128 to 256kB, variable MP3, constant MP3, AC3...


    Whenever I click save, the projected filesize is 1100GB, which was not my goal.

    Do I sample it down to 480x360?

    What do I do with audio, it appears, audio takes as much data as video?

    One good thing about this is that to my astonishment VirtualDubMod is multithreaded and it crunches at about 9 to 16fps (depending on settings) as both CPU graphs spike to full utilization in task manager.
    Last edited by UtwigMU; 13 June 2004, 11:08.

  • #2
    MPEG2 never is in 1:1 pixel aspect ratio

    720x576, 480x576 and 360x576 are widely used resolutions for MPEG2 PAL video streams. The aspect ratio is defined with a flag, and is either 4:3 or 16:9 for DVDs and SVCDs (though 90+% of all standalone players will always display SVCD at 4:3).

    Comment


    • #3
      480 x 576 is standard SVCD PAL format. I would guess your system detects you are using a CD and as mini-DVDs (a CD recorded with DVD style data) are non-standard (and don't play correctly in most set-top players, it is automatically setting itself to the best standard format for recording on CDs.

      You don't say what format your avis are in. If they are in DV format, you would be more likely to get away with it as 720 x 576. If the capture is as analogue, I suggest 704 x 576 would be more appropriate.

      I wouldn't worry about the black borders. These are normal and are in the overscan area, so not seen on a TV.
      Brian (the devil incarnate)

      Comment


      • #4
        I reencoded it as avi two times, once a 2-CD version and once a 1-CD version.

        I cropped the image to video, eliminating black borders. The black borders were about 25 px on each side, about 16px on the bottom and strangely 0px at the top. If one would go with TV overscan safe, I'd expect the top being bordered as well and Y borders larger than X borders.

        I also dumped a few images to disk with frontal images of objects such as drums, opening credits with letters O, pentagrame and enlarged the video to ratio that is proper.

        The original was horizontally squashed by about 9% - a kinf of cinemascopic efect - even when I played it in PowerDVD, which correctly shown it at 4:3 ratio.

        I also used sharpen of 3.

        The processing/rendering times were about 1h for first XVid pass and 2:30h for larger file second pass and 1:15h for smaller file second pass.

        The codecs I used vere XVid for video and AC3 for Audio.

        768 x 568 x 25 + 192kB/s AC3 turned at about 1250MB

        480 x 320 x 25 + 112kB/s AC3 turned at 650MB

        Although I'm still wondering how MPEG2 with 480x576 ratio (~0.276 Mpx) per frame and 224 kB/s Audio takes about as much as 0.173 Mpx XVid MPEG4 video (which is cropped which amounts to action on entire frame, while I imagine, black borders can be compressed rather well). Isn't MPEG4 (XVID, DIVX) supposed to be superiour in terms of quality per same amont of data compared to MPEG2?


        Quality in both cases is subjectively same to not a lot worse from original (which bad already to begin with).

        The target of video is to be watched on computer, hence the cropping.

        How does one get rid of blocks?

        if it were a single 2d image, I'd do blur by x pixel, median by x*1.5 to x*2 pixels and sharpen by x pixels. I didn't found anything equivalent of median in VirtualdubMod, which I was using.

        One more question?

        What would be equivalent of .tiff in videoediting world. In other words a lossless format used to export and import images between various 2D editing applications that all understand is tiff.

        With video, you can't just dump lossless tga image sequence to disk for a few-hour video to try to open it in other applications - it would amount to 50-100GB.



        This was my first dabble in videoediting and I find it interesting.
        Last edited by UtwigMU; 14 June 2004, 02:10.

        Comment


        • #5
          UtwigMU,

          The first thing you need to understand is that pixels do not need to be square in the video world. They can be short and fat or tall and skinny to produce the proper final image aspect ratio.

          As Brian Ellis mentioned, 480x576 is the standard size for PAL Super Video CD (SVCD). This is a medium quality MPEG format for recording about 30 minutes of interlaced video on a standard CD. If you burned that 480x576 file to a CD as an SVCD the player would automatically stretch the image to fit the width of the screen when played back.

          The second thing you need to know is that the size of an MPEG or XVID file is determined by the running time of the video and the bit rate at which it is encoded. In the simplest case, with constant bitrate, you indirectly specify the final size of the file by specifying the bit rate. If you encode a 1 hour video at a constant 6000 kbps you will get a file that's 2.7 GB (ignoring audio) with either codec you use. That's 6,000,000 bits per second times 60 seconds per minute times 60 minutes per hour divided by 8 bits per pyte. As you surmised, at a given bit rate, XVID usually produces better image quality than MPEG.

          Things get more complicated when you use variable bit rates. Variable bit rates allow the codec to use more or fewer bits per second as required by the video content. There are several methods of specifying variable bit rates. Sometimes you just tell the codec what file size you want and it decides for itself (using two passes) how to allocate the bit rate. Sometimes you specify the average bitrate, maximum bitrate and minimum bitrates to use. Or you can specify a constant image quality and let the file come out to whatever size is necessary to produce that quality. Variable bit rates usually allow you to get better image quality for a given file size.

          So it's not surprising that your XVID file turned out larger than your original MPG file. In the process of conversion you specified a higher bitrate for the XVID file. If you want a smaller file specify a lower bit rate.

          I ignored audio in this discussion to simplify matters. And since your using VirtualDub you may be passing the audio along unchanged (that is the default in VirtualDub). But if you changed the audio from MP3 to PCM (ie, compressed to uncompressed), or from a low bitrate MP3 to a high bitrate MP3, it will grow larger too.

          Regarding "blocks" in your video -- if these are macro blocks (16x16 pixel blocks resulting from over compression) there isn't much you can do -- they're already in your MPEG file. Yes, you could blur the image to reduce the blockiness, but you will blur the rest of the image too.

          If the blocks aren't in the MPEG but appear in the XVID file you've used too low a bitate. Try using a higher bitrate, or a variable bitrate with two passes. During the first pass the codec examines the video to determine exactly how much bitrate is needed for each frame of the video. During the second pass it allocates the bits to make the final output the size you requested.

          VirtualDub doesn't have an automatic two pass setting. What you do is run the program once with the "twopass, 1st pass" setting of the XVID codec. The codec creates a temporary file which lists the bitrate required for each frame. Then you run the program again at "two pass, 2nd pass". The codec now creates the final XVID file based on what it learned from the first pass.

          Comment


          • #6
            Thanks for excelent replies, I knew I could count on you.


            I have further questions, this time regarding another file.

            File information:

            Length 1:28:09 (5289s)

            352x228x25 (4:3) (80.256px/frame)

            Video: 119kB/s = 952kb/s MPG2
            Audio: 160kb/s layer II

            File size: 793.446kB

            Here's what I'd like to do:
            - Crop and resample it to 388x228 (88.464px/frame)(to remove top and bottom black border), target = computer.
            - Encode in XVid and AC3 to fit on one CD (700MB)

            Question: Now here strange things start

            I ground the file through first pass which amounted to 917.384kB = ~1.16 of original (the larger effective size of frame - I'd expect black border to compress perfectly. - can explain this).

            Now I again choose Save as avi.

            I pick:
            - target size 700MB
            - time 1:28:09
            - Audio AC3 with 128kb/s bitrate

            video bitrate is calculated at 973kb/s =~122kB/s = close to original
            video size is calculated at 628.819kB

            After letting the box grind for first 5000 frames (to avoid error in approximation), the projected size in dialog appears as 1400MB.


            Clearly there is something wrong here


            I know that calculation of target size can miss a bit, but missing more than 100% (twice the size) is clearly indicating there's something wrong.

            I have opened comparable avi file and dropped it in G-spot:

            A file of duration of 1:38:34 with 640x360 frame size at 25FPS and video bitrate of 848 and with 128kb/s audio (in all aspects similar to the one I'm working on) works to 700MB.
            Last edited by UtwigMU; 14 June 2004, 13:49.

            Comment


            • #7
              I reopened first file and it appears Audio went through uncompressed...


              EDIT, so it appears I answered my own question.

              I don't see option to save MP3 higher than 56 in VdubMod, so I'll have to dump it to wav and reencode it to either MP3 or AC3.
              Last edited by UtwigMU; 14 June 2004, 14:45.

              Comment


              • #8
                IMHO, do NOT crop black borders. I feel you have misunderstood overscan.

                A TV set sees a single "blacker than black" pulse for line synch. Theoretically, this should work on the dV/dt of the leading edge, but the pulse is usually not perfectly rectangular when it reches the TV set and can vary in waveform according to the signal strength. The time when the horizontal time base can trigger can vary by several µs. Similarly, the vertical time base is triggered by the integration of long pulse, interspersed with short negative line synch pulses. The moment of triggering is therefore even less precise.

                To overcome this lack of precision, the displayed picture is masked, so that you can never see the synch pulses on any of the four sides of the picture. This is called overscan and is a deliberate and standard procedure on all TVs. You see nothing in the overscan area.

                The black lines you see on a 'puter monitor therefore disappear when viewed on a TV.

                So what happens when you crop them away? For the sake of argument, let's assume your image is 720 x 576 and you crop off 25 pixels all round. That means you have reduced your image to 670 x 526, which you then expand back to 720 x 576 on re-rendering. You have therefore significantly lowered the resolution. Furthermore, you have lost an extra 25 pixels from your image all round, because part of what was visible now falls into the overscan area and becomes invisible.

                Apart from this, the re-rendering is quite time-intensive.

                As you say this is the first time you've done something like this, I suggest you may be making a lot of difficulties for yourself. Rather thal beat yourself with a stick on your own back, I suggest you start with a low-cost video package, such as Ulead VideoStudio and use that with its default settings throughout. When you have mastered capturing, editing and authoring with that single application and understood what is going on, should you consider starting to tweak or using more complex software. Sorry to be brutal
                Brian (the devil incarnate)

                Comment


                • #9
                  Hehe, no offence Brian.

                  Like I said, the target (where I intend to watch said video) is computer monitor and the reason was to reencode it so that it fits on single CD (reduce file size by about 10%), hence the cropping.

                  The first video I did had problems with, like I said, judging from rectangular and circular objects, when expanded to 3:4 resolution (as PowerDVD which understands MPEG2 files would play it) was horizontally squished by 10% and had 25px black border on sides which amounts to 5.6%.

                  The second video on the other hand had only about 1-2px of black border.

                  I will follow your adwice and start learning the process in a one package software. I know I'm proabably making a newbie-mistakes, just like I was using brightness and contrast instead of levels and curves in Photoshop untill I took the effort to learn it.

                  As for rendering times, it took about 45 mnutes for first pass, about hour for 2nd pass and about 5 minutes to reencode sound. The main reason I bought dual Athlons was to expand my knowledge in the area of videoediting and 3D modelling/animation.
                  Last edited by UtwigMU; 15 June 2004, 08:11.

                  Comment


                  • #10
                    Yup! If you watch it on a computer monitor full screen, the black borders merge with the edge of the screen and you still won't notice them if you are engrossed in the subject matter (how engrossing that is, is up to how well you shoot and edit ).

                    I'm aware of how complex video editing etc. is and, although I've been doing it for many years, I still don't pretend to know everything, even about the softwares I beta-test. What I do know is that many users, seeking perfection, do exactly the opposite, As I've often said, they try to be more royalist than the king. An example of this is that they try to use bitrates much higher than is desirable, even though they cannot see the difference on their viewing medium. It is analogous to those who spend $200 or more on a loudspeaker cable, when a $5 one will perform exactly the same. Any improvement they think they hear is only in the imagination, because they expect an improvement having wasted their bucks. Before I get flamed by anyone for stating this, yes, I do know what I'm talking about. I worked as an engineer for 10 years in a company manufacturing some of the best professional audio equipment in the world, used by nearly every major TV/radio/film studio globally.
                    Brian (the devil incarnate)

                    Comment


                    • #11
                      Hehe, stories about "audiophiles" who spend loads of cash on equipment that doesn't pay of or use green markers on edge of cds since they "prevent red laser light from escaping disk and reflecting, thus influencing sound".

                      I'll try to learn more about video, but I have no camera, no capture device, no DVD burner, no TV and no VCR.

                      So I can't dabble in capturing and dvd/VHS authoring, I can only play with encoding.

                      Comment

                      Working...
                      X