VideoHelp Forum
+ Reply to Thread
Results 1 to 16 of 16
Thread
  1. Hi. I downloaded a programme off the TV and got a .ts file. I used MeGUI to index it and saw combing in the preview. In the 'script' tab I put 'separatefields()' and then clicked 'Preview Script' and there was motion every field. I then saved the script and closed MeGUI.

    I opened the saved script with MeGUI and, as a double check, added separatefields() again. Motion every second field! I started from scratch but the result was the same - in it's pre-saved state, I'm seeing motion every field but after saving the script, it's every second field.

    Why should that be and which one do I go with - QTGMC or TIVTC? A sample of the file follows.

    Supplementary question: when I use separatefields in the pre-saved (preview) version of the script, the preview is squashed as in the attachment. The 'Fit' buttons don't work despite looking active. Why should this be and can I fix it?

    Many thanks indeed.
    Image Attached Thumbnails Click image for larger version

Name:	SF.jpg
Views:	40
Size:	46.4 KB
ID:	56526  

    Image Attached Files
    Quote Quote  
  2. Member
    Join Date
    Mar 2008
    Location
    United States
    Search Comp PM
    Originally Posted by pooksahib View Post
    Hi. I downloaded a programme off the TV and got a .ts file. I used MeGUI to index it and saw combing in the preview. In the 'script' tab I put 'separatefields()' and then clicked 'Preview Script' and there was motion every field. I then saved the script and closed MeGUI.

    I opened the saved script with MeGUI and, as a double check, added separatefields() again. Motion every second field! I started from scratch but the result was the same - in it's pre-saved state, I'm seeing motion every field but after saving the script, it's every second field.

    Why should that be and which one do I go with - QTGMC or TIVTC? A sample of the file follows.

    Supplementary question: when I use separatefields in the pre-saved (preview) version of the script, the preview is squashed as in the attachment. The 'Fit' buttons don't work despite looking active. Why should this be and can I fix it?

    Many thanks indeed.
    The preview would be squashed since separatefields gives a half height image. It looks interlaced to me, 25 frames/50 fields per second
    Quote Quote  
  3. Yes, it's interlaced TFF, not telecined. One should just apply QTGMC for (bob-)deinterlacing.
    The frame width of 544 (including the pillarboxing) looks a bit unusual to me, but when one forces the playback as 4:3 the AR looks (about) correct to me.
    As has been mentioned by davexnet when you separate the fields they will be displayed at half height, so 576/2=488, hence nothing wrong there.
    Quote Quote  
  4. Thanks, guys. It would be interesting to know why using separatefields in the 'preview' stage i.e. before saving the script, gives motion every second frame.

    In the circs, would it be fair to say that the separatefields test should preferably be done on a saved script?
    Quote Quote  
  5. Originally Posted by pooksahib View Post
    Thanks, guys. It would be interesting to know why using separatefields in the 'preview' stage i.e. before saving the script, gives motion every second frame.
    Well, you probably saved the script which contained the separatesfields(), then re-opened that script and added separatefields() again. Hence you ended up with a fieldsequence of 100 fields per second of 144 pixels height, duplicating every field. You should separate the fields only once, getting 50 field per second of 288 pixels height.
    Quote Quote  
  6. Originally Posted by pooksahib View Post
    It would be interesting to know why using separatefields in the 'preview' stage i.e. before saving the script, gives motion every second frame.
    Probably because the video was already deinterlaced elsewhere in the script.

    Yes, the video is interlaced (shot on video, not film), TFF, 544x576, 4:3 DAR. The frame size isn't unusual at all in the EU. Try something like:

    Code:
    Mpeg2Source("sample.d2v", CPU2="ooooxx", Info=3) 
    QTGMC(EZDenoise=1.0, DenoiseMC=true)
    Spline36Resize(768,576)
    Quote Quote  
  7. Originally Posted by jagabo View Post
    Yes, the video is interlaced (shot on video, not film), TFF, 544x576, 4:3 DAR. The frame size isn't unusual at all in the EU.
    By 'unusual' I was probably mislead by the approx. 64:45 PAR of the anamorph capture, which is PAL standard (or PAL typical) for 16:9 DAR rather than 4:3 for which I would have expected a PAR of 16:15 or 12:11.
    I didn't know that frame sizes of 544x576 are not unusual in EU.
    Last edited by Sharc; 30th Dec 2020 at 09:49.
    Quote Quote  
  8. Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    Quote Quote  
  9. Originally Posted by jagabo View Post
    Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    I see, thanks. So one is actually free in mpeg2 video to resize to any PAR (or SAR, sampling aspect ratio) and add borders to comply with the specified DAR (4:3 or 16:9) for correct playback.
    Quote Quote  
  10. Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    I see, thanks. So one is actually free in mpeg2 video to resize to any PAR (or SAR, sampling aspect ratio) and add borders to comply with the specified DAR (4:3 or 16:9) for correct playback.
    No, the full frame should be resized to the specified display aspect ratio. Unless there is a sequence display extension that specifies otherwise.
    Quote Quote  
  11. Originally Posted by jagabo View Post
    Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    I see, thanks. So one is actually free in mpeg2 video to resize to any PAR (or SAR, sampling aspect ratio) and add borders to comply with the specified DAR (4:3 or 16:9) for correct playback.
    No, the full frame should be resized to the specified display aspect ratio. Unless there is a sequence display extension that specifies otherwise.
    Yes, full frame = active picture plus the borders. In this example resizing to 768 (including the borders) : 576 = 4:3. The active picture then becomes 720x576 and is displayed with the correct AR, right?
    But do we know for sure whether the pillow boxing in the original capture was justified, or would we need to have a circle as reference?
    Last edited by Sharc; 30th Dec 2020 at 11:11.
    Quote Quote  
  12. Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    I see, thanks. So one is actually free in mpeg2 video to resize to any PAR (or SAR, sampling aspect ratio) and add borders to comply with the specified DAR (4:3 or 16:9) for correct playback.
    No, the full frame should be resized to the specified display aspect ratio. Unless there is a sequence display extension that specifies otherwise.
    Yes, full frame = active picture plus the borders. In this example resizing to 768 (including the borders) : 576 = 4:3. The active picture then becomes 720x576 and is displayed with the correct AR, right?
    But do we know for sure whether the pillow boxing in the original capture was justified, or would we need to have a circle as reference?
    According to the MPEG 2 spec the full frame, whatever size it is, should be scaled to the specified display aspect ratio. So a 720x576 4:3 DAR frame should be resized to 768x576, or 960x720, or 1440x1080 or 2880x2160, or whatever. A 544x576 4:3 DAR video should also be scaled to those same sizes. There is no concept of active picture in the MPEG 2 spec (unless specified by a sequence display extension).

    If you need a pixel aspect ratio you must calculate it yourself via the usual equation:

    Code:
    pixel aspect ratio = display aspect ratio * frame height / frame width
    You might think the OP's video should be cropped to remove the black borders (ie, the active picture) and then resized to a 4:3 frame. But if you look at the actual picture content there are a few round objects which don't look right when you do that.
    Last edited by jagabo; 30th Dec 2020 at 12:09.
    Quote Quote  
  13. Originally Posted by jagabo View Post
    Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Originally Posted by Sharc View Post
    Originally Posted by jagabo View Post
    Mpeg 2 video doesn't specify the pixel aspect ratio (more properly called sampling aspect ratio) directly. It only specifies the display aspect ratio and frame size.
    I see, thanks. So one is actually free in mpeg2 video to resize to any PAR (or SAR, sampling aspect ratio) and add borders to comply with the specified DAR (4:3 or 16:9) for correct playback.
    No, the full frame should be resized to the specified display aspect ratio. Unless there is a sequence display extension that specifies otherwise.
    Yes, full frame = active picture plus the borders. In this example resizing to 768 (including the borders) : 576 = 4:3. The active picture then becomes 720x576 and is displayed with the correct AR, right?
    But do we know for sure whether the pillow boxing in the original capture was justified, or would we need to have a circle as reference?
    According to the MPEG 2 spec the full frame, whatever size it is, should be scaled to the specified display aspect ratio. So a 720x576 4:3 DAR frame should be resized to 768x576, or 960x720, or 1440x1080 or 2880x2160, or whatever. A 544x576 4:3 DAR video should also be scaled to those same sizes. There is no concept of active picture in the MPEG 2 spec (unless specified by a sequence display extension).

    If you need a pixel aspect ratio you must calculate it yourself via the usual equation:

    Code:
    pixel aspect ratio = display aspect ratio * frame height / frame width
    You might think the OP's video should be cropped to remove the black borders (ie, the active picture) and then resized to a 4:3 frame. But if you look at the actual picture content there are a few round objects which don't look right when you do that.
    Yes, I agree. That's what I meant when I wrote that borders may have to be added to the 'active picture' such that when the full frame is displayed at the specified DAR (4:3 in the OP's case) the 'active picture' will be presented undistorted i.e. with its native intended aspect ratio. Otherwise the borders in the OP's picture would not make sense.
    We have to trust that this has been done correctly, or we have to apply the circle test and rescale + add (or remove) borders accordingly. I think we are talking about the same.
    Quote Quote  
  14. When I listen to guys like you, I realise how little I know. But I know enough to do some half decent editing so I'm grateful for that...

    With regard to loading the video as per jagabo's method:
    Code:
    Mpeg2Source("sample.d2v", CPU2="ooooxx", Info=3) 
    QTGMC(EZDenoise=1.0, DenoiseMC=true)
    the only way I can find to load it is:
    Code:
    a=DGDecode_mpeg2source("G:\sample.d2v")
    b=NicMPG123Source("G:\sample ... DELAY -753ms.mp2").delayaudio(-0.753)
    audiodub(a,b)
    What is CPU2="ooooxx" all about?

    Also, when I added 'EZDenoise=1.0, DenoiseMC=true' to my QTGMC() command, the script wouldn't load ("The video stream cannot be opened")
    Quote Quote  
  15. [QUOTE=pooksahib;2605878]What is CPU2="ooooxx" all about?
    That enables the deringing filter in the 32 bit version of mpeg2source. It doesn't work on the 64 bit version (whoever ported it didn't implement those filters). I almost always use that filter with MPEG 2 sources. It reduces the mosquito noise at sharp edges. I usually don't use the associated deblocking filters because the blur away too many small details.

    http://www.avisynth.nl/index.php/DGDecode/MPEG2Source

    Originally Posted by pooksahib View Post
    Also, when I added 'EZDenoise=1.0, DenoiseMC=true' to my QTGMC() command, the script wouldn't load ("The video stream cannot be opened")
    You're probably missing one (some?) of the optional filters for QTGMC. It's just some light noise reduction, so you don't have to use it.
    Quote Quote  
  16. OK, thanks for that. I added the deringer but wasn't able to spot any difference if I'm honest...

    Regarding my method of loading (specifying a and b, adding delayaudio to b then audiodubbing ab) is that a good way to do it?

    Code:
    a=DGDecode_mpeg2source("G:\sample.d2v")
    b=NicMPG123Source("G:\sample ... DELAY -753ms.mp2").delayaudio(-0.753)
    audiodub(a,b)
    Last edited by pooksahib; 1st Jan 2021 at 00:25.
    Quote Quote  



Similar Threads

Visit our sponsor! Try DVDFab and backup Blu-rays!