Forum Replies Created

Page 23 of 56
  • Charles Simonson

    July 31, 2006 at 6:03 am in reply to: Popwire WMV Jumpy

    If you want to see a excellent case of where blending can really hurt an encode, check out this gem on Apple’s site:
    https://www.apple.com/trailers/mgm/flyboys/trailer/
    I could barely watch it the motion was so terrible. And certainly while I was watching it I wasn’t paying attention to the actual stuff going on in the trailer.

  • Charles Simonson

    July 27, 2006 at 6:37 pm in reply to: Popwire WMV Jumpy

    Yes, don’t use blend, use the dominate field and adaptive.

    Blending does create a smoother image, too smooth for my tastes, but to each their own. I greatly prefer sharpness and detail over a smooth image, but would use smooth when maybe targeting a very agressive bit rate where image quality was less important.

    I understand 6.5 has the same deinterlace options as 6, I just don’t know if there have been any changes to the code in this area from the previous version.

  • Charles Simonson

    July 27, 2006 at 3:50 pm in reply to: Popwire WMV Jumpy

    Andy, what you just mentioned sounds exactly like a blended deinterlace issue, as I described in my earlier post. This issue would be especially notable on panning sequences. This is often refered to as a “strobing” effect by some, which is usually noticed when a WVC1 interlaced encode is played back on a computer monitor with default settings. As I said, in the default playback case, the issue is because the decoder blends the fields, creating the sort of stuttering you see.

    Only in your case, you are encoding progressive by first blending the fields so that you are seeing the same effect on WMV3 encodes. By default, this is the method that the PC encoder uses when encoding from an interlaced source to WMV3. Personally, I would never choose to blend the fields for an encode. I see the merits in using that method to playback an interlaced encode on a progressive monitor, but I don’t see it for the actual encode method.

    So… by proper deinterlace, I mean a deinterlace where a field is actually removed (adaptive is best) or a deinterlace that takes the fields and makes frames out of them (usually requires some scaling and a doubling of the frame rate). Cleaner (at least versions prior to 6.5 did; I haven’t really spent too much time with 6.5 to see if there are any changes for deinterlacing) and Compression Master have good deinterlacers. If using Cleaner, Craig might be able to elaborate on how the F4M encoder handles Cleaner’s deinterlace settings with F4M’s own deinterlacer.

    As far as Popwire, the same thing could be happening there as well if you are using just the WMV QT export component. And I doubt the issue would be that they work better with NTSC than PAL, as PAL is a better format and Popwire is a Swedish company.

  • Charles Simonson

    July 26, 2006 at 5:15 pm in reply to: Graphics Compression

    No tricks really except to always be sure to use lines and pixel values divisable of at least 2, with the minimum recommended size for NTSC being 4 pixels. Pretty much the same as for editing NTSC for broadcast.

  • Charles Simonson

    July 26, 2006 at 5:12 pm in reply to: cleaner xl 1.5 windows

    Second that.

  • Charles Simonson

    July 26, 2006 at 5:00 pm in reply to: Jerky FLVs

    I can’t think of anything that can be done in Flash that can’t be done in Director (without some modding at least), but I can understand why some designers are more comfortable in Flash than Director. If you really like Flash, then design the UI in Flash and import the SWF into Director and use actions to initiate a movie start (encoded with MPEG-1).

  • Charles Simonson

    July 25, 2006 at 3:44 pm in reply to: Popwire WMV Jumpy

    While I’m not going to say it is a bad idea to use a PC for WMV encoding, I do find it strange to hear complaints of “jumpiness” with both Popwire and F4M’s encoders. Would you call the jumpy part more like a bouncing in the actual frames or more like a strobing effect of fields?

    On the PC side, the only time I have ever heard of this is if you were using an interlaced encode and viewing on a computer monitor. By default, the WMV decoder blends the fields of a VC-1 encode. But playback of interlaced WMVs is not supported on the mac (no decoder for it) and you can only really encode frame-based interlaced WMV with F4M (but still no way to view that on the mac), so that is likely not it.

    When encoding and viewing WMVs on the mac, you have to remember that all encode viewing must be of progressive material (WMV3). If you have an interlaced source and do not do a proper deinterlace for the encode, then the fields will blend together and this can sometimes encode in an strange way and create what could be called a “jumpy” experience I suppose.

    BTW, the mac also has some faster or close to real-time MPEG-2 SW encoders. Popwire Compression Master 4, MainConcept Encoder 1.5, and Apple Compressor 2.1 all fit this bill.

  • Charles Simonson

    July 25, 2006 at 3:16 pm in reply to: Jerky FLVs

    I wasn’t referring to it being an internet bandwidth issue, but rather an issue with the decoder needing to decode so many bits. And unfortunately, in order to get really good looking FLV with v7 or 8, you need to use a fair amount of bits to encode (no moreso than many other codecs, but still enough), I would say even more for CD-ROM distribution. This is one of the primary reasons why I still use Director and MPEG-1 for my CD-ROM authoring.

    FLVv8 looks great for web distribution at smaller sizes where it has been heavily optimized. However, the large-format space is not something that seems to have retained much attention from the developers yet, and thus you are noting its shortcomings. As it stands, decoding FLVv8 requires too much processing power for larger sizes to be really worth it IMO.

  • Charles Simonson

    July 25, 2006 at 4:12 am in reply to: Compressor Help

    The easiest solution would be to use a DVD+R DL. You can fit about 7.9GB on one of those. The next option would be to build your project with the current assets, and then recompress it using something like DVD2OneX. I do this all the time for projects that end up a little over what I originally encoded for and it works like a charm. The third option is to re-encode all assets according to what you can fit on a standard DVD-R by specifying bit rate parameters. The final option that I can think of would be to use iDVD. I believe iDVD might be a really good choice for you and should do a good job.

    Here’s a calculator to plug in your settings: https://www.3ivx.com/support/calculator/
    Use that to calculate bit rate.

  • Charles Simonson

    July 24, 2006 at 5:51 pm in reply to: Jerky FLVs

    Hard to tell your problem without seeing a sample of the file. Only thing that comes to mind is that you are encoding to too large of a frame size and bit rate for the computer it is being played back on. FLV is not really intended to be used at above 480×360 and high bit rates for across-the-board smooth playback on all systems.

Page 23 of 56

We use anonymous cookies to give you the best experience we can.
Our Privacy policy | GDPR Policy