VideoHelp Forum

Our website is made possible by displaying online advertisements to our visitors. Consider supporting us by disable your adblocker or buy Replay Video Capture or PlayON and record Netflix, HBO, etc! :)
+ Reply to Thread
Results 1 to 14 of 14
Thread
  1. I decided to re-ask this question to get a normal answer, and this time left everything in the archive link, study it and you'll understand what I'm talking about. The error is due to the fact that after changing one number in the header, the entire frame becomes incorrect (although the aspect ratio of 640x480 1:1 and 720x480 4:3 is the same).
    Download: https://www.dropbox.com/s/xc9opzn3ujrfxlt/Bug%20in%20video.zip?dl=0
    Quote Quote  
  2. What, exactly, did you change, and what tool did you use to make the change?
    Quote Quote  
  3. Originally Posted by Megafox View Post
    I decided to re-ask this question to get a normal answer, and this time left everything in the archive link, study it and you'll understand what I'm talking about. The error is due to the fact that after changing one number in the header, the entire frame becomes incorrect (although the aspect ratio of 640x480 1:1 and 720x480 4:3 is the same).
    Download: https://www.dropbox.com/s/xc9opzn3ujrfxlt/Bug%20in%20video.zip?dl=0

    It's not the same thing.

    Changing the coded frame size is always problematic - it's not something you can do with a header or metadata edit. You need to re-encode in order to change the actual encoded frame size.

    ie. Where do the extra pixels go ? In case you're bad at math, 720 is not the same thing as 640 .

    Actual macroblocks make up each frame, you can't just discard some of them, because some are referenced in other frames; you should expect corruption



    You can sometimes change the AR signalling, but the resultant effect is dependent on the playback application. Some may abide by the signalling and do something, or some ignore, or some do something entirely different. 720x480 4:3 might be resized to 640x480 on plaback in some applications, but in others they might resize to 720x540 . Both are 4:3 . (technically 640x480 is more correct)

    Moreover, the quality of the resize depends on the algorithm used by the playback application. It might use a blurry algorithm, or it might use something sharp, or something super low processing but fast like nearest neighbor.
    Quote Quote  
  4. Originally Posted by johnmeyer View Post
    What, exactly, did you change, and what tool did you use to make the change?
    Look in archive
    Quote Quote  
  5. Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    I decided to re-ask this question to get a normal answer, and this time left everything in the archive link, study it and you'll understand what I'm talking about. The error is due to the fact that after changing one number in the header, the entire frame becomes incorrect (although the aspect ratio of 640x480 1:1 and 720x480 4:3 is the same).
    Download: https://www.dropbox.com/s/xc9opzn3ujrfxlt/Bug%20in%20video.zip?dl=0

    It's not the same thing.

    Changing the coded frame size is always problematic - it's not something you can do with a header or metadata edit. You need to re-encode in order to change the actual encoded frame size.

    ie. Where do the extra pixels go ? In case you're bad at math, 720 is not the same thing as 640 .

    Actual macroblocks make up each frame, you can't just discard some of them, because some are referenced in other frames; you should expect corruption



    You can sometimes change the AR signalling, but the resultant effect is dependent on the playback application. Some may abide by the signalling and do something, or some ignore, or some do something entirely different. 720x480 4:3 might be resized to 640x480 on plaback in some applications, but in others they might resize to 720x540 . Both are 4:3 . (technically 640x480 is more correct)

    Moreover, the quality of the resize depends on the algorithm used by the playback application. It might use a blurry algorithm, or it might use something sharp, or something super low processing but fast like nearest neighbor.
    I just made the pixels square instead anamorphic, from this there should hardly be any errors. You see archive?
    Quote Quote  
  6. OK, I guess you are using MPGPatcher.exe, although I am only guessing, since you won't say for sure. I have used similar MPEG patching tools and there are some things you can change without re-encoding which will result in a perfectly valid MPEG-2 file. As poisondeathray has said, there are other things you can't change without causing problems.
    Quote Quote  
  7. Originally Posted by Megafox View Post
    I just made the pixels square, from this there should hardly be any errors
    Wrong. You should expect errors with this method

    You're not just "making the pixels square" ; and this is the wrong way to do it anyways
    Quote Quote  
  8. Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    I just made the pixels square, from this there should hardly be any errors
    Wrong.
    And 4:3 to 1:1 - wrong? Without editing resolution
    Quote Quote  
  9. Originally Posted by Megafox View Post
    Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    I just made the pixels square, from this there should hardly be any errors
    Wrong.
    And 4:3 to 1:1 - wrong? Without editing resolution
    Yes wrong. It requires re-encoding

    The resolution is the problem. You can't just add or discard pixels without re-encoding. The video relies on that data. Macroblocks from frames rely on other macroblocks from other frames when using temporal compression. If you reference an area that is "missing" you have corruption

    You can signal 720x480 1:1 without re-encoding (DAR = 1.5) . That is what "square pixel" means. But then your AR is wrong , picture is distorted, objects too fat or wide



    Why are you trying to do this ?
    Quote Quote  
  10. Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    I just made the pixels square, from this there should hardly be any errors
    Wrong.
    And 4:3 to 1:1 - wrong? Without editing resolution
    Yes wrong. It requires re-encoding

    The resolution is the problem. You can't just add or discard pixels without re-encoding. The video relies on that data. Macroblocks from frames rely on other macroblocks from other frames when using temporal compression. If you reference an area that is "missing" you have corruption

    You can signal 720x480 1:1 without re-encoding (DAR = 1.5) . That is what "square pixel" means. But then your AR is wrong , picture is distorted, objects too fat or wide



    Why are you trying to do this ?
    For normally load to Avisynth without such distortions
    Quote Quote  
  11. Originally Posted by Megafox View Post
    To normally load and Avisynth without such distortions


    If you're using avisynth for processing, that requires re-encoding anyways . It frameserves uncompressed video & audio.

    Or did you mean just for preview / look development ?

    There are no distortions in the original . If you meant how it displays the AR as "square pixel" - You can load original and resize in the script too. For example if you wanted 640x480 , square pixel, 4:3 DAR . You can choose which resizing method (e.g. maybe you wanted a sharper algorithm), instead of relying on player.
    Quote Quote  
  12. Originally Posted by poisondeathray View Post
    Originally Posted by Megafox View Post
    To normally load and Avisynth without such distortions


    If you're using avisynth for processing, that requires re-encoding anyways . It frameserves uncompressed video & audio.

    Or did you mean just for preview / look development ?

    There are no distortions in the original . If you meant how it displays the AR as "square pixel" - You can load original and resize in the script too. For example if you wanted 640x480 , square pixel, 4:3 DAR . You can choose which resizing method (e.g. maybe you wanted a sharper algorithm), instead of relying on player.
    I need to make it so that he thinks it's 640x480, cheat somehow because the size change spoils the video, and the fields. Which is the best way?
    Ok, finding best resizer or loader with keeping dar. Thanks
    Last edited by Megafox; 12th Feb 2018 at 17:20.
    Quote Quote  
  13. Originally Posted by Megafox View Post
    I need to make it so that he thinks it's 640x480, cheat somehow because the size change spoils the video, and the fields. Which is the best way?

    In general, for DVD and cartoons, you need IVTC and resize to 640x480 . This requires re-encoding

    IVTC is inverse telecine, to fieldmatch and decimate to recover the original film frames. The only reason it's like that in the first place was to make it compliant for DVD-video, you're just trying to reverse the process

    But cartoons can be tricky, sometimes they have different effective fps sections (eg. sections with duplicates would be effectively ~12 fps) , other types of cartoons might have "video" sections with 59.94. But for most NTSC DVD cartoons, they should be 23.976p
    Quote Quote  
  14. You can change the AR flag with MPGPatcher (or DVDPatcher, or a number of other programs). The frame size remains the same within the encoded file but it will be displayed with a different aspect ratio by the player.

    I recommend you use the /all flag in MPGPatcher because there are many headers with the AR flag in an MPG file.
    Last edited by jagabo; 12th Feb 2018 at 17:32.
    Quote Quote  



Similar Threads