VideoHelp Forum
+ Reply to Thread
Page 4 of 4
FirstFirst ... 2 3 4
Results 91 to 112 of 112
Thread
  1. My thinking was certain lighting conditions can cause patterns on faulty sensors - this looks like an acquistion problem to me (bad camera sensor)

    If pattern fluctuates, then there is a chance you might be able to improve it by applying a temporal filter to the V channel

    Why don't you post a short clip?

    (Besides, the girls aren't exactly hard to look at )
    Quote Quote  
  2. Originally Posted by poisondeathray View Post
    My thinking was certain lighting conditions can cause patterns on faulty sensors - this looks like an acquistion problem to me (bad camera sensor)

    If pattern fluctuates, then there is a chance you might be able to improve it by applying a temporal filter to the V channel

    Why don't you post a short clip?
    Sure thing, clip is attached. Mind you, I noticed that this error doesn't appear all the time. I just checked, whenever I run it in an avs script that colour problem doesn't appear for some reason. If I call the original .ts file with DirectShowSource and open it in Virtualdub, the colours are normal. When I run the original, I get the problem I described and posted a screenshot of. So since I had to trim the clip, you probably won't see those colour issues that happened before for some reason. Any clue why that is?

    Originally Posted by poisondeathray View Post
    (Besides, the girls aren't exactly hard to look at )
    Oh my, seems like somebody got infatuated :3 True, they are a marvel to look at, but it could be even better if they weren't recorded in such a blocky manner

    EDIT: lol, forgot clip
    Image Attached Files
    Quote Quote  
  3. There are a bunch of issues, but no color bar issue as depicted in your earlier screenshot . It's probably a decoding or source filter issue , or interlaced chroma upsampling issue. How are opening it in avs script ? What decoder
    Quote Quote  
  4. Originally Posted by poisondeathray View Post
    There are a bunch of issues, but no color bar issue as depicted in your earlier screenshot . It's probably a decoding or source filter issue , or interlaced chroma upsampling issue. How are opening it in avs script ? What decoder
    Exactly, oddly enough, it only happens in the source file. I used DirectShowSource() to open the file with the script. But I only opened it, no deinterlacing or anything.
    Quote Quote  
  5. I just checked, whenever I run it in an avs script that colour problem doesn't appear for some reason. If I call the original .ts file with DirectShowSource and open it in Virtualdub, the colours are normal. When I run the original, I get the problem I described and posted a screenshot of. So since I had to trim the clip, you probably won't see those colour issues that happened before for some reason. Any clue why that is?
    wait.... to clarify: ONLY the full sized .ts exhibits the problem? but NOT with avs using directshowsource? You cannot reproduce the issue with the smaller cut clip ?

    What do you mean it only occurs when you "run the original" ? How are you "running" the original ? How are you taking screenshots with defects ?
    Quote Quote  
  6. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    I'd ask the same questions. Meanwhile it took some heavy 16-bit filters to smooth the block noise and compression artifacts. Can't figure how they got low-bitrate artifacts out of 20Mbps. I brought levels within sanity, too, but red still gets a little haywire.
    Image Attached Files
    - My sister Ann's brother
    Quote Quote  
  7. Originally Posted by LMotlow View Post
    Can't figure how they got low-bitrate artifacts out of 20Mbps.
    All those strobing/moving lights eliminate most inter frame compression. And this is at least the second time it's been compressed.
    Quote Quote  
  8. Originally Posted by poisondeathray View Post
    wait.... to clarify: ONLY the full sized .ts exhibits the problem? but NOT with avs using directshowsource? You cannot reproduce the issue with the smaller cut clip ?
    Yes, I'm as confused as you.

    Originally Posted by poisondeathray View Post
    What do you mean it only occurs when you "run the original" ? How are you "running" the original ? How are you taking screenshots with defects ?
    The problem occurs when I open the file with MPC-HC apparently... At least in that second scene. The problem from the first screenshot is consistent, I attached a sample from the scene of the first screenshot. This time I'm using Lagarith, just to make sure that nothing else happens other than trimming, but the file is 226 MB. I'll attach a smaller 18 MB .ts as well though. Looking at it, I think it might have to do with really bad interlacing. Look at Frames 110-115 of the file I attached, seems to me that the lighting is turning red at that moment, and I just caught the worst frame to look at. It's probably not a big problem then, but I saw it in the preview coincidentally and was surprised.

    Originally Posted by LMotlow View Post
    I'd ask the same questions. Meanwhile it took some heavy 16-bit filters to smooth the block noise and compression artifacts. Can't figure how they got low-bitrate artifacts out of 20Mbps. I brought levels within sanity, too, but red still gets a little haywire.
    Yeah, the blocking was crazy, baffles me too... You did a stellar job on that sample though! May I ask what you used? Googling for 16-bit filters hasn't brought up much and the avisynth wiki is also kind of quiet about it.

    Originally Posted by jagabo View Post
    All those strobing/moving lights eliminate most inter frame compression. And this is at least the second time it's been compressed.
    Huh, interesting. Maybe while I was cutting it, it was re-encoded, therefore compressed another time? For that reason, I attached the Lagarith avi file too, just to be sure that isn't an issue.
    Image Attached Files
    Quote Quote  
  9. Originally Posted by bschneider View Post
    Originally Posted by jagabo View Post
    All those strobing/moving lights eliminate most inter frame compression. And this is at least the second time it's been compressed.
    Huh, interesting. Maybe while I was cutting it, it was re-encoded, therefore compressed another time? For that reason, I attached the Lagarith avi file too, just to be sure that isn't an issue.
    The TS file shows problems where interlaced YV12 was treated as progressive at some point in the processing. That has caused blending of the chroma channels. The video in post post #92 shows this too. The two videos in post #35, and your latest Lagarith AVI do not have this problem. You need to figure out where in your processing this is happening, or if it's in the source file.

    One common place for this error is in VirtualDub. It treats incoming interlaced YV12 as progressive YV12 when it converts to RGB for filtering, blurring the two chroma channels together. When using AviSynth to feed VirtualDub you need to convert to YUY2 or RGB in AviSynth to prevent this. Use ConvertToYUY2(interlaced=true) or ConvertToRGB(interlaced=true). Or deinterlace the video before giving it to VirtualDub (thereby converting interlaced YV12 to progressive YV12).

    How did you create the TS samples in post 92 (which was compressed by x264) and 98 (which wasn't compressed by x264)?

    I was able to reproduce the green and purple bars from your Lagarith sample with a simple Bob().

    Code:
    AviSource("Orange Caramel Sample.avi")
    AssumeTFF()
    Bob()
    Last edited by jagabo; 6th Jul 2014 at 08:36.
    Quote Quote  
  10. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    jagabo makes some good points about re-encodes. Be careful how you make cuts. Many "editors" don't smart render. If you don't know what that means, it means that smart rendering apps will re-encode only the few frames involved in the cut area and will try to match the original encoding as well as they can. All the other frames go through as-is. Most freebies don't smart render (licensing for decoders/encoders ain't cheap!). TVMW5 does converting and re-encoding better than most, and it usually decodes to a clean AVI. But it's not a smart rendering app. For quick cuts like that I use TMPGenc Smart Renderer a lot (TMSR4), but more often I go with Avisynth.

    Originally Posted by bschneider View Post
    May I ask what you used? Googling for 16-bit filters hasn't brought up much and the avisynth wiki is also kind of quiet about it.
    The .m2t in post #96 used 16-bit processing with the dither plugin. Dither has its own versions of some Avisynth support files. I colored them blue in the script below. I keep the components in a separate folder and load them as needed. Here's the script I used -- It did OK, but slow as heck with big 1920x1080 stuff:

    Code:
    #####  dither v1.22.1  #####
    Import(path to dither plugins\"Dither.avsi")
    Import(path to dither plugins\"mt_xxpand_multi.avsi")
    LoadPlugin(path to dither plugins\"avstp.dll")
    LoadPlugin(path to dither plugins\"dither.dll")
    LoadPlugin(path to dither plugins\"dfttest.dll")
    LoadPlugin(path to dither plugins\"mvtools2.dll")
    LoadPlugin(path to dither plugins\"mt_masktools-26.dll")
    
    DirectShowSource(path to "Orange Caramel Sample.ts")
    ColorMatrix(mode="Rec.709->Rec.601",interlaced=true) 
    ColorYUV(cont_y=-20,off_y=-10)
    SmoothLevels(14, 0.83, 255, 16, 245,chroma=200,limiter=0,tvrange=true,dither=100,protect=4)
    AssumeTFF().QTGMC(preset="fast")
    FixChromaBleeding()
    dfttest()
    GradFun3(thr=0.7)
    LimitedSharpenFaster()
    AddGrainC(2.0, 2.0)
    AssumeTFF().SeparateFields().SelectEvery(4,0,3).Weave()
    ColorMatrix(mode="Rec.601->Rec.709",interlaced=true)
    Those "lines" and other objects are being projected onto the background from behind the stage.
    - My sister Ann's brother
    Quote Quote  
  11. Originally Posted by jagabo View Post
    The TS file shows problems where interlaced YV12 was treated as progressive at some point in the processing. That has caused blending of the chroma channels. The video in post post #92 shows this too. The two videos in post #35, and your latest Lagarith AVI do not have this problem. You need to figure out where in your processing this is happening, or if it's in the source file.
    Yeah, it was a mistake on my part, thanks for pointing it out. I wasn't feeding it through Virtualdub, but it's good to know that what you described is a potential source of errors. Actually, it was just that I didn't pay enough attention, I trimmed the video with my newly-acquired TMPGEnc (Video Mastering Works) and it asks for display mode in the beginning, which it usually detects correctly by itself. But when encoding I just quickly selected a template, didn't pay attention and it was a progressive one. I attached the new sample, which should be encoded correctly, still interlaced.

    Originally Posted by jagabo View Post
    I was able to reproduce the green and purple bars from your Lagarith sample with a simple Bob().

    Code:
    AviSource("Orange Caramel Sample.avi")
    AssumeTFF()
    Bob()
    So as I thought, it was a problem that had to do with de-interlacing? Seeing as Bob() deinterlaces as well?

    Originally Posted by LMotlow View Post
    jagabo makes some good points about re-encodes. Be careful how you make cuts. Many "editors" don't smart render. TVMW5 does converting and re-encoding better than most, and it usually decodes to a clean AVI. But it's not a smart rendering app. For quick cuts like that I use TMPGenc Smart Renderer a lot (TMSR4), but more often I go with Avisynth.
    Yeah, I've read in the FAQ on TMPGEnc's website that Mastering Works unfortunately doesn't support smart rendering. You say you often go with Avisynth for simple cutting, but what do you use to generate your output file? So far, I usually fed the avs script with Trim(x, y) to Virtualdub, but more frequently to MeGUI and now TMPGEnc.

    Originally Posted by LMotlow View Post
    The .m2t in post #96 used 16-bit processing with the dither plugin. Dither has its own versions of some Avisynth support files. I colored them blue in the script below. I keep the components in a separate folder and load them as needed. Here's the script I used -- It did OK, but slow as heck with big 1920x1080 stuff
    [...]
    Those "lines" and other objects are being projected onto the background from behind the stage.
    Thanks a ton for the exact script! I will have to take some time tomorrow to read up on some of the filters that I haven't made any acquaintance with so far. Seems very different from what I used so far. (Which is always nice )
    Image Attached Files
    Quote Quote  
  12. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    Originally Posted by bschneider View Post
    You say you often go with Avisynth for simple cutting, but what do you use to generate your output file? So far, I usually fed the avs script with Trim(x, y) to Virtualdub, but more frequently to MeGUI and now TMPGEnc.
    When I use Avisynth I expect a decoded lossless AVI for various reasons, then re-encode the results. Smart renderers let you cut anywhere. Some freebies can edit without re-encoding, if you're willing to cut only on the first frame of a GOP (Group Of Frames). GOP is a frame group with at least one "I" or key frame. The other frames, from about 12 to more than 100, aren't complete pictures. They're just data for parts of the frame that change since the last key frame. If a second or two of extra video won't ruin your day, H264TS-Cutter and DGAVCDec are two free apps I often see being used. DGAVCDec is easiest to get a cut with, but it puts out 3 files: a .dga file (which is just an index), a .264 file for raw video, and an .ac3 audio file. ".264" files won't fly in most players or VirtualDub, but if ffdshow is installed then Avisynth can open them with DirectShowSource(). Many editors can get confused by telecined or field-blended video. In this case, your samples so far have been simple interlace.
    - My sister Ann's brother
    Quote Quote  
  13. Originally Posted by bschneider View Post
    Originally Posted by jagabo View Post
    I was able to reproduce the green and purple bars from your Lagarith sample with a simple Bob().

    Code:
    AviSource("Orange Caramel Sample.avi")
    AssumeTFF()
    Bob()
    So as I thought, it was a problem that had to do with de-interlacing? Seeing as Bob() deinterlaces as well?
    No, it's in the video. Deinterlacing just makes it more obvious. The bands are 8 pixels thick so I think it has something to do the quick changing colors and brightness, and the 8x8 macroblocks used in compression. A field or two earlier you can see more random 8x8 blocks.

    Name:  v.jpg
Views: 632
Size:  29.0 KB

    Regarding samples, try using a tool like h264tsCutter to extact samples from TS files.
    Quote Quote  
  14. Sorry guys, I'm a bit busy at the moment, I will try to find some time on Wednesday. Thanks for your enthusiasm and continuous efforts to help me out
    Quote Quote  
  15. I don't consider them a problem since they're so transient, but McTemporalDenoise() can get rid of most of the purple/green bars

    Code:
    MergeChroma(last, McTemporalDenoise(settings="very high"))
    You probably don't want filtering that strong for the entire video so you might limit it to just those few frames with ReplaceFramesSimple().
    Quote Quote  
  16. Member
    Join Date
    May 2014
    Location
    Memphis TN, US
    Search PM
    Originally Posted by jagabo View Post
    .....McTemporalDenoise() can get rid of most of the purple/green bars

    Code:
    MergeChroma(last, McTemporalDenoise(settings="very high"))
    You probably don't want filtering that strong for the entire video so you might limit it to just those few frames with ReplaceFramesSimple().
    Yep, I thought about trying that. I've seen it used earlier to good effect. I think you've delivered enough in this thread so far to keep us busy for a week.

    Originally Posted by bschneider View Post
    Sorry guys, I'm a bit busy at the moment, I will try to find some time on Wednesday.
    Time? What's that? I signed up mainly to make searching the archives easier. But I've already worn myself out with posts about other projects. Time to get back to my own, I guess, and look closer into some of jagabo's posted ideas. Thanks for your patience with all this information overload, LOL!
    - My sister Ann's brother
    Quote Quote  
  17. I apologise, things are getting so stressful... I simply don't have the time to read up on all the new filters and such, it will probably stay like this for another 2 weeks. Exam time is a pain. I have read what you have posted, thank you all very much for your input, I just don't have the time to properly respond at the moment and to thoroughly get into it.

    I noticed one other thing that comes up again and again, I think it's ringing artifacts, I'm not sure. It happens frequently after deblocking+deinterlacing and I wondered what I could do against it. HQDering didn't seem to do much (the description itself says it's a very careful filter), and I don't always use .d2v files, so Mpeg2Source's deringing isn't always available. I did notice that santiag seemed to help every now and then, after that, I usually sharpen the picture back up a little with LSFMod(), it worked quite well so far, but I want to make sure there aren't better ways to do it. I attached a picture displaying the problem, the picture shows a video that's been filtered with Deblock_QED (as jagabo suggested to use it on interlaced videos) and QTGMC afterwards, because else the jaggies hide those artifacts.

    Originally Posted by LMotlow View Post
    Thanks for your patience with all this information overload, LOL!
    Haha, it's nice how understanding you are, as I said earlier, I would reverse that statement. Thanks to all of you for being patient with me, even though I have little time to research much on my own. I feel like I've learned a lot, even some things I never thought I'd get into. Really interesting stuff!
    Image Attached Thumbnails Click image for larger version

Name:	how to avoid this.png
Views:	255
Size:	601.4 KB
ID:	26308  

    Quote Quote  
  18. It's tough with a low quality source.

    You've got to do a better job of deblocking, filtering before sharpening , because the sharpening will enhance those edge artifacts. But that will reduce details significantly that's the trade off you have to make. You decide how far you want to take it

    Many filters like QTGMC, MTCD have contra sharpening, you might want to lower the strength, or at least take that into consideration in your filter chain. Especially QTGMC seems to have sharpen strength very high at default. I almost always lower the sharpen strength for QTMC right off the bat . The combination of temporal smoothing and excess sharpening is one of the criticisms of QTGMC for producing that "oil painting" look

    The TNLMeans , NLMeansCL family of filters tend to work well on these types of edge artifacts before they have been filtered and sharpened, but they are slow. When you begin to stack deblocking, QTGMC, other denoise filters, etc... it becomes very very slow

    You might want to use stronger filtering settings and reduce the resolution . Some of the videos you posted are barely worth SD in terms of resolution
    Quote Quote  
  19. Originally Posted by poisondeathray View Post
    It's tough with a low quality source.

    You've got to do a better job of deblocking
    Oh, don't misunderstand me, I don't mean to present this as a "final outcome" sort of thing, it was just an illustration because it was easier than to describe the effect I mean.

    Originally Posted by poisondeathray View Post
    because the sharpening will enhance those edge artifacts.
    Ah yes, that makes sense.

    Originally Posted by poisondeathray View Post
    Many filters like QTGMC, MTCD have contra sharpening, you might want to lower the strength, or at least take that into consideration in your filter chain. Especially QTGMC seems to have sharpen strength very high at default.
    Oh, I did not know that, thank you for telling me! I will pay attention to that from now on.

    Originally Posted by poisondeathray View Post
    The TNLMeans , NLMeansCL family of filters tend to work well on these types of edge artifacts before they have been filtered and sharpened, but they are slow. When you begin to stack deblocking, QTGMC, other denoise filters, etc... it becomes very very slow
    Thanks a lot, I will look at those filters! Speed is not that much of a concern for me, but thank you for the warning.

    Originally Posted by poisondeathray View Post
    You might want to use stronger filtering settings and reduce the resolution . Some of the videos you posted are barely worth SD in terms of resolution
    Yeah, I do use more filters than just what you saw in that picture, as I said, it was just an illustration. I've taken many cues from all of you and every now and then just picked some filters I found on the wiki and tried them out. I contemplated reducing the resolution, but I don't like the idea very much :/ I might give it a try once, but I doubt I'll really use that measure. After all, I'm going to watch it on a 1200p display anyway, so it's going to be stretched in fullscreen and look effectively the same (possibly worse), won't it?
    Quote Quote  
  20. MCTD has edgecleaning modes you can try. But the settings and strengths (with any filter) required to clean these types of edge artifacts in the samples you've posted will errode a lot of details, especially hair detail, background detail. Basically it will look as if you blurred the hell out of everything. Or if you're familar with neat video, it would be like using neat video in a non discriminatory manner. It's difficult to isoloate which lines are to be included or excluded in the edge masks - so all edges are filtered . This is subjective - many people would use a lot less filtering and live with the more natural looking noise
    Quote Quote  
  21. I think part of the problem with reducing those DCT ringing artifacts is that your videos have been through multiple encodings. And possibly some upscaling too. HQDering() worked much better on the After School sample when it was downscaled to 1280x720, deringed, then upscaled back to 1920x1080 and sharpened.
    Quote Quote  
  22. Originally Posted by poisondeathray View Post
    MCTD has edgecleaning modes you can try.
    I think I tried those before, without too much of a result, if I remember correctly.

    Originally Posted by poisondeathray View Post
    It's difficult to isoloate which lines are to be included or excluded in the edge masks - so all edges are filtered . This is subjective - many people would use a lot less filtering and live with the more natural looking noise
    Yeah that makes sense. The whole smoothing to get rid of artifacts vs. sharpness while keeping artifacts seems to be a prevalent theme in all matters concerning encoding

    Originally Posted by jagabo View Post
    I think part of the problem with reducing those DCT ringing artifacts is that your videos have been through multiple encodings. And possibly some upscaling too. HQDering() worked much better on the After School sample when it was downscaled to 1280x720, deringed, then upscaled back to 1920x1080 and sharpened.
    Yeah, I can't do much about the multiple encode problem unfortunately. I managed to find some better sources, but it gives me a whole show, meaning I have to cut 3-4 minute performances out of hour long shows. Some problems consist, too, the entire show upload is far from flawless. But at least it doesn't give me even worse cuts, even though it's more work cutting it manually.
    Are you sure about downscaling all the way to 720p and then back up though? It seriously looked better?

    Btw, I tried h264tscutter and it's a marvelous program. The only problem is that it crashes after the second or third cut sometimes, and one of my videos it won't load without crashing at all, so I can't even cut that once. DGAVCDec hasn't worked once so far, it always gives me countless errors for any video I try to load and then just doesn't do anything.

    EDIT: Damn, h264tscutter doesn't have much in the way of support anymore. Can't really find much on it. Already installed Haali Media Splitter because the dev recommended it repeatedly, doesn't help. It says it needs some decoders, ffdshow should do that, if I'm not mistaken, and I have that installed. So I have no clue what the issue is. Downloaded the trial for the TMPGEnc Smart Renderer, that one reads the file perfectly without issues. But of course there's the water mark and everything. Unless you know what could cause the problem with the tscutter, I might have to dig deep into my wallet again :/
    Last edited by bschneider; 12th Jul 2014 at 07:03.
    Quote Quote  
Visit our sponsor! Try DVDFab and backup Blu-rays!