VideoHelp Forum
+ Reply to Thread
Page 1 of 2
1 2 LastLast
Results 1 to 30 of 35
Thread
  1. Hi,

    I have a documentary film I purchased but noticed that the video has a lot of what I'll call "combing" artifacts whenever there is movement in the scenes.

    I posted a picture so you can see.


    Now I am satisfied with the results of my fix, I used the Decomb filter and AviSynth, here is the after picture just for fun.


    Now I am recoding the video, but would like to keep all the original menus and special features, while swapping out the "defective" video.

    Here is a picture of how the VIDEO_TS folder looks now.


    What I thought about doing was reencoding the two clips in question (VTS_02 and VTS_03), then create VOB's by authoring a simple DVD in TMPGEnc DVD Author, and just swap out the VOB files, old with new.

    The catch is, and here is my question, that the new VOB's would not be exactly the same size (KB's), because I am not so sophisticated that I can reencode at the same bitrate (and/or size), and so I am just reencoding the files, and hoping because the length time-wise the same is, that there won't be any problems.

    Did I explain myself OK? I hope so, because I would just like to fix the crappy video, whose solution I'm currently happy with, and reauthor the DVD "back to normal".

    Let me know if you guys can help, I do appreciate it!

    Chipsndukes
    Quote Quote  
  2. Member fritzi93's Avatar
    Join Date: Nov 2003
    Location: U.S.
    Search Comp PM
    How about DVDRebuilder?

    Options -> AVS Options -> Advanced (Expert) Options -> Deinterlace with Decomb

    Or add a line of script to the filter editor and save. Then rebuild the DVD.

    Alternatively, do it your way and replace the VOBs in the DVD with VobBlanker, PgcEdit, Muxman, IfoEdit. There are a number of guides that should apply, for instance look under available guides for VobBlanker.

    Good luck.

    [EDIT] Eh, Manono beat me to it while I was editing the first time.
    Pull! Bang! Darn!
    Quote Quote  
  3. I don't think there's much point in using DVD Rebuilder when he just wants to reencode part of the DVD. You can't set the rest of the DVD to no compression, can you, with the free version?

    chipsndukes, you shouldn't have to deinterlace anyway. You won't see it on any television. An interlaced CRT TV set plays only the uninterlaced fields, and a progressive display will either deinterlace it or IVTC it. I'd say to leave it alone, especially since you don't know what you're doing.

    If you still insist on "deinterlacing" the 2 PGCs, demux them (PGCDemux), figure out if you need to IVTC them or deinterlace them (or upload a sample for us to check), reencode them, author them (Muxman), and then replace the 2 PGCs in the original DVD using VobBlanker. That will allow you to keep the menus and anything else that was already there.
    Quote Quote  
  4. Member
    Join Date: Aug 2005
    Location: Palo Alto, California USA
    Search Comp PM
    I agree with Manono -- you should just leave it be. Most of the "fixes" you are proposing to implement/have implemented will degrade the image. Try evaluating whether you have a real problem by viewing the video in question on the actual equipment intended for display (e.g., a TV). You may discover, as Manono suggests, that there is not actually a problem.
    Quote Quote  
  5. Here is a sample to look at.

    IMHO the artifacting is encoded in the video, it is not an interlacing problem.
    The way I found the issue, was it was so obvious on TV, everytime anyone moved anything, there was "combing". It's really distracting.

    If you need a different format, like an .AVI format, I can provide this.



    sample.m2v
    Quote Quote  
  6. and here is an .AVI file, it is from a frameserved file using DGIndex and AviSynth.

    Maybe this is easier for someone to look at.
    It is true that I don't know what I'm doing, but I still feel that this "combing" is a real problem and not just interlacing I am seeing on a computer display.

    sample.avi
    Quote Quote  
  7. Member
    Join Date: Aug 2005
    Location: Palo Alto, California USA
    Search Comp PM
    The screenshots are very much consistent with standard interlacing artifacts. If you have relatively fast lateral motion, then you will get those teeth around the moving objects. If they are objectionable when viewed with the client's hardware-software combo, then you do in fact have a post-processing challenge. There are several de-interlacing strategies, and you will have to experiment a bit to find one that solves your problem without introducing significant new ones. If your original source was from film, then your problems can be due to, or compounded by, telecine artifacts, hence Manono's reference to IVTC filters. In any case, after you've fixed up the video, his suggestions for reauthoring are the ones I would follow.
    Quote Quote  
  8. Thanks, tomlee. Just for reference, the original source was a PAL DVD.
    I don't know much about transfer from NTSC and PAL DVD's, but I never had a problem with other documentary films from the same company, I play the discs on a NTSC/PAL DVD player and decode them to an NTSC TV (I just select NTSC as output on the DVD player menu).
    I looked at the DVD again on both a plasma TV and an old CRT TV on 2 different players, it still looks horrible, like "checkerboards" on all the lines and edges whenever anything moves.

    As soon as I have the video reencoded, I might need your alls' help again with VOB Blanker, I looked at it but still am not sure how to replace one VOB set with another, I'll be back.

    Chipsndukes
    Quote Quote  
  9. Oh, so you're in NTSC land and are depending on your players to do the conversion? Then you might have mentioned that to begin with. I see nothing at all wrong with the PAL DVD source you uploaded. Well, except for some chroma bleeding, or something similar. Perhaps the players can't do it properly.

    And since it's from a PAL DVD, there's no IVTC. You'll just be deinterlacing. And not with Decomb, unless by Decomb you meant the FieldDeinterlace component. There are much better, yet still fast, AviSynth deinterlacers. TDeint, LeakKernelDeint, and Yadif come to mind.
    Quote Quote  
  10. Video Restorer lordsmurf's Avatar
    Join Date: Jun 2003
    Location: dFAQ.us/lordsmurf
    Search Comp PM
    Using your proposed method, you'll only exchange the interlace/frame-rate problem for a severely ghosted image on the television. Just FYI.
    Quote Quote  
  11. well, I guess it is an interlacing problem, but I feel that the fields are swapped.
    I tried to play it on 2 Philips DVD players on 2 TV's, both have the same issue.
    Like I said, it doesn't happen on any of the other DVD's I have from "PAL land".

    I reencoded the video just using FieldDeinterlac() (not messing with decombing artifacts, vthres or whatever) and the result was perfect once I checked it on a TV.
    No more checkerboarding at the interfaces, I'll have to make some better screen shots and post them.

    I think that the interlacing of the source is fine, but somehow the field order is wrong, I'll mess around and post more later.

    Thanks for your help gentlemen!
    Quote Quote  
  12. The problem is solved and I wanted to thank you guys for your help.

    As usual, it was a group effort with everyone contributing, I couldn't have done it all on my own.

    The problem was this, I tried to retrace my steps to understand how I had missed the interlacing issue.
    The thing was at the beginning I performed the "AssumeTFF().SeparateFields()" test to determine field order, and found none. The stream was progressive, and that is why I went directly to decombing instead of deinterlacing.

    What brought me to that was LordSmurf's suggestion to use ReStream, when I loaded the "bad" stream, it showed up as being progressive, I was not able to change the field order to correct it, it had been hard encoded that way, hence why I stuck to my guns on that but couldn't remember why.

    Anyway, I reencoded using FieldDeinterlace and reinterlacing it as PAL video. Because I didn't know what the final size should be, I just encoded with CQ100, reinserted the streams with VOBBlanker, like manono said, and DVDShrink'ed everything back to the right size.
    Not elegant, but it worked, it's just a documentary DVD (for information, mainly) and I just wanted to get rid of the artifacting.

    The statement in the ReStream guide you posted for me LordSmurf sums it up:

    Note: If the MPEG is supposed to be interlaced, and has the combing effect ... AND is saved as a progressive MPEG format, the video was encoded improperly and may need to be re-encoded.

    Thanks again guys, sorry for the trouble, but all's well that ends well.

    If anyone is interested, I uploaded a little mini-DVD that you can just burn to a DVD-RW and watch the first few seconds of the video.
    You see right away what I mean, at least on a CRT. On the computer it isn't nearly as noticeable. It looks terrible.

    Thanks guys. Once again, your help was much appreciated.

    Chipsndukes

    video_ts.zip
    Quote Quote  
  13. Originally Posted by chipsndukes
    The problem was this, I tried to retrace my steps to understand how I had missed the interlacing issue.
    The thing was at the beginning I performed the "AssumeTFF().SeparateFields()" test to determine field order, and found none. The stream was progressive, and that is why I went directly to decombing instead of deinterlacing.
    That first M2V you made available, the sample.m2v, was encoded as interlaced. What makes you say it's progressive? Or did you reencode it as progressive and thus mess it up?
    The thing was at the beginning I performed the "AssumeTFF().SeparateFields()" test to determine field order, and found none.
    That makes no sense if you started with an interlaced source. It should easily show what the field order is. If the fields advance smoothly, it's TFF. If they move with a jerky back-and-forth motion, it's really BFF.
    What brought me to that was LordSmurf's suggestion to use ReStream, when I loaded the "bad" stream, it showed up as being progressive,
    Is this after being reencoded?
    Anyway, I reencoded using FieldDeinterlace and reinterlacing it as PAL video.
    Makes no sense. If you made the frames progressive, they won't be made interlaced again unless you do something stupid like field-shifting. Did you deinterlace the fields before reinterlacing? Which it looks to me like you may have done.

    And that last sample you uploaded, the video_ts.zip, is a complete mess as it's interlaced yet was encoded as progressive. I have no idea at all how you can say you've solved your problem, when I think all you've done is to compound it.
    Quote Quote  
  14. Originally Posted by chipsndukes
    The problem was this, I tried to retrace my steps to understand how I had missed the interlacing issue.
    The thing was at the beginning I performed the "AssumeTFF().SeparateFields()" test to determine field order, and found none. The stream was progressive, and that is why I went directly to decombing instead of deinterlacing.
    Originally Posted by manono
    That first M2V you made available, the sample.m2v, was encoded as interlaced. What makes you say it's progressive? Or did you reencode it as progressive and thus mess it up?
    Yes, the sample clip was actually reencoded with TMPGEnc, I didn't know any better way to just extract a clip to post and, because the stream showed it was progressive, I assumed that reencoding it wouldn't make a difference.
    But it apparently did and caused a lot of confusion.

    Originally Posted by chipsndukes
    The thing was at the beginning I performed the "AssumeTFF().SeparateFields()" test to determine field order, and found none.
    Originally Posted by manono
    That makes no sense if you started with an interlaced source. It should easily show what the field order is. If the fields advance smoothly, it's TFF. If they move with a jerky back-and-forth motion, it's really BFF.
    If the sample.m2v file I posted was interlaced, it must have been for the above reason--it was reencoded.

    Originally Posted by chipsndukes
    What brought me to that was LordSmurf's suggestion to use ReStream, when I loaded the "bad" stream, it showed up as being progressive,
    Originally Posted by manono
    Is this after being reencoded?
    No, it actually showed that with the original stream.
    I think all the confusion started with reencoding the sample clip, I really didn't think it would make a difference for a progressive stream.

    Originally Posted by chipsndukes
    Anyway, I reencoded using FieldDeinterlace and reinterlacing it as PAL video.
    Originally Posted by manono
    Makes no sense. If you made the frames progressive, they won't be made interlaced again unless you do something stupid like field-shifting. Did you deinterlace the fields before reinterlacing? Which it looks to me like you may have done.
    That is correct. I just used the FieldDeinterlace() command in my AviSynth script and fed the original stream to TMPGEnc and reencoded as PAL interlaced.

    Originally Posted by manono
    And that last sample you uploaded, the video_ts.zip, is a complete mess as it's interlaced yet was encoded as progressive. I have no idea at all how you can say you've solved your problem, when I think all you've done is to compound it.
    Yes, that is actually a sample of the original stream. I finally found a way to make just a clip with DVDShrink.

    Here now is an example of the final product, which is probably not perfect, but I am pleased with it.

    vts_01_0.zip

    Thanks again for all your help, manono, I really appreciate you jumping in.
    Chipsndukes
    Quote Quote  
  15. Originally Posted by chipsndukes
    Here is a sample to look at.

    IMHO the artifacting is encoded in the video, it is not an interlacing problem.
    By implication, the sample.m2v you supplied was from the source. If you reencoded it you're supposed to say so. What good is something you reencoded when we're trying to diagnose a problem with your source?

    Also, I went over that sample.m2v again, the one you reencoded using TMPGEnc. It's encoded as TFF, but is really BFF. If you burned that one to disc and played it on the standalone, it would have played jerky and ReStream could have fixed it. Or you could have done it correctly in the first place. The sample was TFF. The entire thing may have been either TFF or BFF, but in any case you set the field order incorrectly.
    If anyone is interested, I uploaded a little mini-DVD that you can just burn to a DVD-RW and watch the first few seconds of the video.
    Rereading that part, I see that I misunderstood that the video_ts.zip wasn't your final result, but the source, something you should have provided originally.

    The most recent sample, the vts_01_0.zip , was made progressive but then encoded as interlaced. There's nothing really wrong with that, but if I had a progressive source (which you have after deinterlacing it), I'd encode it as progressive, especially if I had a funky DVD player. I don't but you do.

    None of this would have been necessary had you a decent DVD player. You have flag readers, evidently, and interlaced material encoded as progressive won't play properly on them. A decent cadence reader, such as a good Oppo player, would have had no trouble at all with your source DVD.
    I didn't know any better way to just extract a clip to post
    Open a VOB in DGIndex, use the [ and ] buttons to isolate a small section, and then File->Save Project and Demux Video. Upload the resulting M2V.
    Quote Quote  
  16. Here is a sample clip from the original, using the procedure you described.

    sample.m2v

    When I made the .d2v file in DGIndex, I got this error for the first titleset:



    For the second titleset I got this error:


    I thought I should mention that in case it was important.
    I'm going to keep working on understanding what happened here.

    Chipsndukes
    Quote Quote  
  17. That sample was BFF. I don't believe when cutting with DGIndex that the field order gets reversed, so it's BFF but you had reencoded it as TFF originally. As for those messages, I think they're different now. First, you should probably upgrade your DGIndex (and the DGDecode.dll that comes with it in the DGMPGDec package), and then when you get that message it'll fix it automatically after you give the OK.

    And that is a messed up DVD. Someone screwed up royally to have encoded an interlaced source as progressive.
    Quote Quote  
  18. Here is the new DGIndex, I'm reading the manual now.

    Quote Quote  
  19. Here is the new DGIndex, I'm reading the manual now.

    Quote Quote  
  20. You say "Yes" and it'll correct the illegal transition. It probably went from 0 to 2 (or vice-versa) without the required 1 (or 3) in between. You may be able to spot it by opening and scanning the D2V project file.
    Quote Quote  
  21. I didn't correct the illegal transition because I still don't know what it means and want to leave it alone until I understand.
    I did look at the file in VirtualDub using "AssumeBFF.SeparateFields()" and tried to find places where the field order was swapped, but everything I found was BFF, the motion was smooth.

    I also downloaded all the deinterlacing filters you mentioned above and am studying everything I can find on deinterlacing. I changed my mind and want to really make this "perfect", if I can.

    So, it appears that the only problem is that the field order is wrong. All the original fields are there, just in the wrong order, am I right?
    And I can't fix field order with ReStream, because it says the source is progressive.

    And now I learn that deinterlacing involves either blending or interpolation, but both involve changing the original source, and therefore some degradation to the video.

    Isn't there a way I can simply determine what the field order was supposed to be and correct it without blending or interpolation?

    The only other clue I maybe found was the "fields coded" in Restream.

    Here is a shot of the original "bad" video:



    Here is a shot of the reencoded "good" video:



    Do these BB's and PP's have something to do with the field order, or is this also a dead end?

    Thanks for your help manono,
    Chipsndukes
    Quote Quote  
  22. I changed my mind and want to really make this "perfect", if I can.
    Then don't deinterlace it.
    And I can't fix field order with ReStream, because it says the source is progressive.
    I've never seen a progressive source encoded as interlaced, but ReStream seems to be able to fix it, although it works only with elementary streams. That is, you'll have to demux it (DGIndex->Save Project and Demux Video). Take the demuxed M2V, open it in ReStream, uncheck the Frametype Progressive and Progressive Sequence boxes and have it write out a new M2V. Remux and try it out. Remember it's BFF, at least the sample is. Also, there may be minor problems with the way the colors wind up, since you're just changing the flagging without reencoding it. jagabo knows more about that than I. But since your source isn't so good to begin with, I don't think you'll be able to tell the difference. Or just reencode it.
    Isn't there a way I can simply determine what the field order was supposed to be and correct it without blending or interpolation
    Yes, by separating the fields. I didn't have any trouble with the source sample cut with DGIndex that you uploaded, although I bobbed it:

    AssumeBFF()
    Yadif(Order=0,Mode=1)

    It shows the same as this, but with full frames:

    AssumeBFF()
    SeparateFields()
    Do these BB's and PP's have something to do with the field order?
    No.
    Quote Quote  
  23. OK, thanks.
    I will work on this today and report back.

    Chipsndukes
    Quote Quote  
  24. Video Restorer lordsmurf's Avatar
    Join Date: Jun 2003
    Location: dFAQ.us/lordsmurf
    Search Comp PM
    Originally Posted by manono
    That sample was BFF. I don't believe when cutting with DGIndex that the field order gets reversed, so it's BFF but you had reencoded it as TFF originally. As for those messages, I think they're different now. First, you should probably upgrade your DGIndex (and the DGDecode.dll that comes with it in the DGMPGDec package), and then when you get that message it'll fix it automatically after you give the OK.

    And that is a messed up DVD. Someone screwed up royally to have encoded an interlaced source as progressive.
    How long has DGIndex been able to fix this?

    A lot of satellite MPEG_TS streams flip the field dominance throughout the program, usually at the commercial breaks. Many commercials clip from progressive to various interlacing, or even different framerates altogether (23.976 + pulldown, instead of 29.97 like show). It's a mess.

    I've got some satellite streams saved on disc that I can't do anything with, because it's just slop to work with. It sounds like DGIndex might help it?

    Sorry to threadjack, just a small question, and it might help this poster in concept anyway.
    Quote Quote  
  25. It's been able to do it for years now, but the method in which it was implemented has changed over time. For a while you had to run the D2V Project File through Fix DTV yourself (as with chipsndukes' original version of DGIndex). I believe at one point it did it automatically, until it was shown this wasn't always a good idea. These days it asks you and then does it automatically if you give the go-ahead. Here's what the doc (DGIndexManual.html) has to say about it:
    Sometimes streams are encountered that contain mixtures of TFF and BFF material. In MPEG2, these field order transitions are fixed at display time via the TFF/RFF flags. But we usually want to output a stream with one consistent field order, and some tools, such as Telecide and (Leak)KernelDeint, require a fixed field order. Indeed, AVI does not carry a field order property!

    This tool adjusts the TFF/RFF flags so that a stream with a single field order is output. This affects only streams containing field order transitions, of course. When field order correction is applied using this tool, the uncorrected D2V file is renamed so that it ends with the extension ".bad". The corrected version is output as the usual D2V file.

    This tool should be used only when you have reason to believe that field order transitions are present in the stream. For some pathological streams, however, you may find that the field order correction causes problems that you don't encounter when using the ".bad" D2V file. Therefore, it is always advisable to treat the correction as an advisory and to test both the good and bad D2V files.

    Note that field order correction should not be applied to streams containing frame repeat RFFs.
    Since the author (neuron2, aka Donald Graft) is a long time capture enthusiast, many of his tools and filters have been developed to help make capping easier and more efficient. Again though, it only fixes the D2V Project file and not the video itself. You'll have to reencode using that corrected D2V in an AviSynth script to get the benefit of the "fix". The docs included with the DGMPGDec package explain how to do this, but if you're still unclear there are lots of people here willing to help.
    Quote Quote  
  26. Originally Posted by lordsmurf
    Sorry to threadjack, just a small question, and it might help this poster in concept anyway.
    No problem, this started out as an authoring thread and ended up as interlacing, or field order, or whatever--anything learned is of value.

    So just quick to close things up--I CAN'T BELIEVE IT--I swear I tried the field order thing in ReStream, reburned the video (demuxed with PGCDemux) and it didn't work!
    Now I did it again, both with DGIndex and PGC to demux the vid. and it came out fine.
    The only thing was to uncheck the 2 progressive boxes and rerun.

    That was all that it was the whole time. Deinterlacing not necessary...

    The only thing I can think of was that I didn't uncheck the second progressive box "sequence extension-progressive sequence" because, yes, I didn't know what it did and didn't want to mess anything up.

    Here is a clip of the "new" old video:

    sample.m2v

    Thanks for the help, guys, I still can't believe I went 3 full circles to come back to beginning, the story of my life?
    Chipsndukes
    Quote Quote  
  27. Here is a mini-DVD of the new video:



    dvd.zip
    Quote Quote  
  28. Hmmm...

    Now the audio is out of sync.
    Tried muxing with both TMPEnc DVD Author and Muxman, same result, both clips.

    Am trying the different deinterlace filters to see which one I like best, unless someone can tell me how to resync the audio without doing more work that what reencoding the video will be.

    Sorry, didn't see (hear?) the out of sync audio until later, the first part of the film doesn't have shots of people talking, wasn't able to tell...

    Thanks guys,
    Chipsndukes
    Quote Quote  
  29. It's out-of-synch by the same amount all the way through? And the demuxed audio you got from DGIndex didn't have the delay listed in the file name? Or when checking the A/V Delay in PGCDemux it didn't tell you anything? Here's one way find and fix the out-of-synch audio, but only if the asynch is constant:

    Open an out-of-synch VOB in Media Player Classic. Right-click the screen and go Options->Internal Filters->Audio Switcher and make sure the "Enable built-in audio switcher filter" box is checked. You'll only have to do this once. If doing it for the first time, then hit "OK", close MPC and reopen it. Play the VOB in it and use the + or - buttons on the right side of your keyboard to add in a positive or negative delay. A positive delay causes the audio to play later (delays it). 1000ms=1 second. If you have trouble synching to lips moving, try and find a sharp noise like a door slamming or a gunshot and synch to that. It shows the amount of delay applied in the bottom left of the player. Once you get it the way you like, remember that figure and close MPC.

    Now open the AC3 audio in DelayCut. In the Delay section fill in the Start box with your delay. That's all - only fill in that one box. Don't check anything or add anything else. Then Process it and use the fixed audio in your authoring program.
    Quote Quote  



Similar Threads