VideoHelp Forum

+ Reply to Thread
Page 3 of 3
FirstFirst 1 2 3
Results 61 to 75 of 75
Thread
  1. Originally Posted by jagabo View Post
    Beware of DVD MPEG2 in MKV (MakeMKV rips) -- editors often screw that up as well. For example, DgIndex (commonly used to index DVD video for AviSynth doesn't work well with MKV from MakeMKV). You usually want to index the VOB files directly for that.
    A lot of it has to do with MKV container, timestamp jitter, VFR

    DG made DGIndexNV completely free now - it can read MKV directly, and reliably. (But you still need a compatible Nvidia card).
    Quote Quote  
  2. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    Hey poisondeathray, you kept mentioning that the problem was likely due to problems with the timestamps. That got me thinking about how to correct the timestamp issue. So as an experiment I took the source file I have been testing and ran it through tsMuxer and demuxed it, then I took the resulting files and remuxed them with tsMuxer figureing that would correct the timestamps.....then I ran the resulting TS file through FFmpeg Batch AV Converter with the exact settings as before that created a file with playback problems.....and viola!....now it plays fine in MPV.

    Is this a solution, at least for cable recorded content? I tried it with a MakeMKV ripped DVD and this process did not work on that. But if this works for recorded content I can simply run all my files through tsMuxer right after I edit out all the fluff. It's an extra step but if it solves my problem it's a few minutes a movie and worth it.
    Quote Quote  
  3. Yes, likely the input timestamps were messing ffmpeg up. It happens ...unfortunately a lot... It' s the #1 cause of various ffmpeg related issues

    If you don't have perfect timestamps, it can cause ffmpeg to match the wrong fields, decimate the wrong frames. So you end up with the wrong dropped frames (jumps in motion) , or duplicate frames

    The -vf fps=30000/1001 is supposed to correct for minor jitter in timestamps , but it won't help with bigger issues

    TSmuxer could be a solution, use whatever works, right

    I can't stand the headaches and flaky behaviour. I just use what is proven to work consistently. The avs/vpy method is more consistent for supposedly CFR sources (like TV recordings, DVD, BD) largely because the files are indexed and frame accurate. FFmpeg doesn't really run on "frames". It runs on timestamps. So when using avs/vpy - many of the ffmpeg timestamp related issues are avoided
    Last edited by poisondeathray; 14th Sep 2021 at 23:55.
    Quote Quote  
  4. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    I figure that my cable recorded stuff could have all kinds of little issues in the TS streams due to it being a recorded source that don't mess up watching the TS file or normal de-interlacing but with IVTC taking every 5th frame out that is what causes the issue because with bad timestamps ffmpeg does not know how to resynch?? I have had problems sometimes with Avidemux not wanting to save an edit because and it reports that the fault is likely timestamps....but usually running through tsMuxer solves the issue. I just happened across this solution through raw experimentation at the time not even knowing what I was actually doing.

    I will play with this and see if it truly is a solution for recorded content.....now I just have to figure out what to do about DVDs as MakeMKV is really the only good solution for ripping DVDs these days.
    Quote Quote  
  5. Originally Posted by Ronstang View Post
    I figure that my cable recorded stuff could have all kinds of little issues in the TS streams due to it being a recorded source that don't mess up watching the TS file or normal de-interlacing but with IVTC taking every 5th frame out that is what causes the issue because with bad timestamps ffmpeg does not know how to resynch?? I have had problems sometimes with Avidemux not wanting to save an edit because and it reports that the fault is likely timestamps....but usually running through tsMuxer solves the issue. I just happened across this solution through raw experimentation at the time not even knowing what I was actually doing.

    I will play with this and see if it truly is a solution for recorded content.....now I just have to figure out what to do about DVDs as MakeMKV is really the only good solution for ripping DVDs these days.

    If you had buggy timestamps, when you demux something, timestamps are discarded. This should work if the stream is CFR, untouched

    But sometimes it's the edits that are causing the problems, and the timestamps are actually the thing holding everything together in sync if it's been edited by user. So double check the output in different sections with that tsmuxer workaround

    You have to be careful about editing the cable recorded stuff - ideally you should remove pulldown (ivtc), before editing. So it's fully progressive first, before you edit. LAZY broadcast editors, don't do this - so there are all sorts of problems with interrupted cadences - some of your recordings might have those sorts of issues already. Many DVD's have those sorts of issues from TV drama/sitcom series


    Otherwise when editing make sure you
    1) cut on keyframe boundaries only, even if you have to include a few frames of fading to commercial

    2) don't interrupt the 3:2 cadence - you have to cut on complete cycles
    Quote Quote  
  6. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    My edits that need to be IVTC are only cable movies with no commercials. My editing consists of only cutting the beginning and end of the video off so I have only the movie itself and I cut on keyframes....so that should not cause any issues with the IVTC then, correct? I could do it the other way but it is a lot of wasted time as then I have to encode 2 hours for a 1 1/2 hour movie....but the real problem is the keyframes of TS files are a little less than a second (manageable) but the keyframes of Nvenc encoded files are closer to 10 seconds.....so edits are nearly impossible.

    The movies and shows I cut commercials out of I run simple de-intelacing on since these are broadcast TV shows and made fro TV movies like Hallmark and Lifetime.
    Last edited by Ronstang; 15th Sep 2021 at 01:38.
    Quote Quote  
  7. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    You will not believe this....I just ran another movie I recorded from TCM through FFmpeg Batch AV Converter without demuxing/remuxing as a test and it works fine. All this trouble I have caused was because I picked a file with an obvious problem and all my tests have been on the same damn file because I wanted direct comparison for every change I made.....and I picked a file with an issue...DOH!. I am sorry, and I do appreciate all your help....I have done a lot of searching on this forum and you are everywhere and one of the most knowledgeable and willing to help. You are a great asset to everyone here my friend. I commend you.

    Is there any program I could run my TS files through first to identify issues like in the original file I used? If not I will just encode what I have, check each one to make sure it plays and if not I will do the demux/remux and re-encode before I delete the TS files.
    Quote Quote  
  8. Originally Posted by Ronstang View Post
    My edits that need to be IVTC are only cable movies with no commercials. My editing consists of only cutting the beginning and end of the video off so I have only the movie itself and I cut on keyframes....so that should not cause any issues with the IVTC then, correct? I could do it the other way but it is a lot of wasted time as then I have to encode 2 hours for a 1 1/2 hour movie....but the real problem is the keyframes of TS files are a little less than a second (manageable) but the keyframes of Nvenc encoded files are closer to 10 seconds.....so edits are nearly impossible.
    Of course, definitely edit it beforehand as mpeg2, not afterwards. It should not cause problems cutting on the mpeg2 keyframes. But Fade in/outs "made for broadcast" are often interlaced fades applied afterwards by the editor, before broadcast - so those can cause artifact issues (but they are different than these wild timestamp playback issues) . Try to make sure cuts are at the 3:2 cycle boundaries - otherwise you interrupt cadence and cause additional artifact issues too


    Originally Posted by Ronstang View Post
    You will not believe this....I just ran another movie I recorded from TCM through FFmpeg Batch AV Converter without demuxing/remuxing as a test and it works fine. All this trouble I have caused was because I picked a file with an obvious problem and all my tests have been on the same damn file because I wanted direct comparison for every change I made.....and I picked a file with an issue...DOH!. I am sorry, and I do appreciate all your help....I have done a lot of searching on this forum and you are everywhere and one of the most knowledgeable and willing to help. You are a great asset to everyone here my friend. I commend you.

    Is there any program I could run my TS files through first to identify issues like in the original file I used? If not I will just encode what I have, check each one to make sure it plays and if not I will do the demux/remux and re-encode before I delete the TS files.

    But it should raise a red flag or serve as a warning - how many others are out there like that ? If something plays ok and is in sync to begin with - it should be "IVTCable". That's what your TV is doing "on the fly" - virtually all North American model flat panels have 3:2 cadence detection. But non perfect timestamps often causes a lot of trouble for some types of ffmpeg processing (such as ivtc)

    Not really any programs - you could examine the timestamps manually, maybe run vfrdet in ffmpeg, but there is no way to accurately and automatically determine if and what is wrong. e.g If timestamps are a bit off, that -vf fps can usually make ivtc work ok in ffmpeg.

    All broacast, DVD, BD are CFR encoded to begin with - There should be no VFR at all in this scenario. The content can be VFR (you can have 23.976p mixed with 59.94 fields/s interlaced, mixed with 29.97p sections, etc.. ) - BUT they the are all encoded in a CFR stream. That' s a big reason why frame accuracy more is important than "timestamps" for these type of operation. Frame accuracy means reliable results.
    Quote Quote  
  9. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    I did some more testing this morning. It isn't an MakeMKV issue either. Once again I picked the wrong file to test. I used the first episode of "The Bionic Woman" TV series I ripped from DVD the other day.....and it appear to have no interlacing. I looked at the file and went through it looking for motion and even though I looked in several places even moving frame by frame I could not see any interlacing. I have included the mediainfo info below because I dn't know what it means when it says "Frame Rate Mode = Variable"

    General
    Unique ID : 144042785650075739629185659104154252623 (0x6C5DA1A474A21D6F84B0B9CA2402754F)
    Complete name : X:\TV Shows\The Bionic Woman (1976)\Season 1\1. Welcome Home, Jaime, Part I.mkv
    Format : Matroska
    Format version : Version 2
    File size : 1.36 GiB
    Duration : 48 min 51 s
    Overall bit rate mode : Variable
    Overall bit rate : 3 985 kb/s
    Movie name : 1.Welcome Home, Jamie, Part I
    Encoded date : UTC 2021-09-08 06:00:23
    Writing application : MakeMKV v1.16.4 win(x64-release)
    Writing library : libmakemkv v1.16.4 (1.3.10/1.5.2) win(x64-release)

    Video
    ID : 1
    ID in the original source medium : 224 (0xE0)
    Format : MPEG Video
    Format version : Version 2
    Format profile : Main@Main
    Format settings : CustomMatrix / BVOP
    Format settings, BVOP : Yes
    Format settings, Matrix : Custom
    Format settings, GOP : Variable
    Codec ID : V_MPEG2
    Codec ID/Info : MPEG 1 or 2 Video
    Duration : 48 min 51 s
    Bit rate mode : Variable
    Bit rate : 3 783 kb/s
    Maximum bit rate : 9 800 kb/s
    Width : 720 pixels
    Height : 480 pixels
    Display aspect ratio : 4:3
    Frame rate mode : Variable
    Frame rate : 24.000 FPS
    Original frame rate : 29.970 (30000/1001) FPS
    Color space : YUV
    Chroma subsampling : 4:2:0
    Bit depth : 8 bits
    Compression mode : Lossy
    Bits/(Pixel*Frame) : 0.456
    Time code of first frame : 00:59:59;00
    Time code source : Group of pictures header
    Stream size : 1.29 GiB (95%)
    Language : English
    Default : No
    Forced : No
    Original source medium : DVD-Video

    I went ahead and looked at several movies I just ripped from DVD and found them to be 2:3 pulldown and ran them through FFmpeg Batch AV Converter with the same settings we got working and this time the movie played fine. So doing IVTC on a file that does not need it causes more problems obviously.

    Thankfully all this experimenting is teaching me many thing. I now see why you told me I really need to look at my source files to determine what kind if any of interlacing is present before I choose my settings. From now on whenever I edit TV movies I will do a quick check in Avidemux to verify interlacing type (although I assume a given station uses the same all the time, but it doesn't hurt to verify every once in a while). I will also load all my DVDs into Avidemux to determine interlacing also. I will then segregate my source files based on interlacing so I can run them through the encoder with customized profiles for each type.

    I am very thankful to have learned all this. I want to try avisynth too when I have a chance but at the moment I am testing with what I have been using with the new settings. I need to watch a few movies to see the results but I am sure things are much better now. STARZ was the one channel that always has jerky playback so I need to target a file from there for further testing on playback.
    Quote Quote  
  10. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    I have been using the following to IVTC for over a year and it has been working fine:

    fieldmatch,bwdif=mode=0:deint=1,decimate

    I just tried this to IVTC which was posted earlier in this thread and it worked also:

    fieldmatch=order=tff:combmatch=full, yadif=deint=interlaced, decimate

    Is one preferable?

    The first one seems to run faster, that is all I have noticed. I guess I can compare output by same movie with each and watch and see but if anyone has input that saves me the time that would be nice.

    Thanks
    Quote Quote  
  11. Originally Posted by Ronstang View Post
    I have been using the following to IVTC for over a year and it has been working fine:

    fieldmatch,bwdif=mode=0:deint=1,decimate

    I just tried this to IVTC which was posted earlier in this thread and it worked also:

    fieldmatch=order=tff:combmatch=full, yadif=deint=interlaced, decimate

    Is one preferable?

    The first one seems to run faster, that is all I have noticed. I guess I can compare output by same movie with each and watch and see but if anyone has input that saves me the time that would be nice.
    Not comparable, because the combmatch settings are only calculated on scene changes for the 1st example. In the 2nd example combmatch=full checks every frame . That explains the main speed difference ,but they could apply the deinterlacing differently too even if the same deinterlacer was used

    For bwdif vs yadif - in general bwdif will give better, sharper results . But "sharper" can sometimes lead to worse deinterlacing artifacts on some sources . For me, bwdif is also faster than yadif , but it's a non-issue speed wise. Both yadif and bwdif will almost never become a "bottleneck" - they are fast
    Quote Quote  
  12. Originally Posted by Ronstang View Post
    ....... So doing IVTC on a file that does not need it causes more problems obviously.
    Obviously. See the discussion here about the 47.952fps surprise.
    https://forum.videohelp.com/threads/408439-Encoding-with-IVTC-results-in-frame-rate-of-47-952
    Quote Quote  
  13. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    Not comparable, because the combmatch settings are only calculated on scene changes for the 1st example. In the 2nd example combmatch=full checks every frame . That explains the main speed difference ,but they could apply the deinterlacing differently too even if the same deinterlacer was used
    OK, but that doesn't give me any idea if I should be using one over the other. Does one do a better job if the cadence is disturbed by editing.....like in TV shows for instance. When I only edit out the beginning and end of a movies, say on TCM there is no way the editing can disturb the 3:2 cadence. I have been happy with what I have been using for movies since you straightened this out for me over a year ago but it never hurts to experiment.
    Quote Quote  
  14. Depends on the source, but checking every frame would theoretically be better but slower than only checking scene changes
    Quote Quote  
  15. Member
    Join Date
    Jun 2020
    Location
    Houston, TX
    Search PM
    I guess I'll encode a few movies and a few TV episodes I don't mind watching twice back to back and do some comparison.....like I said I have been very happy with what I have been doing for over a year that I learned in this thread so if there is no real difference then saving the time is definitely better.
    Quote Quote  



Similar Threads