DG made DGIndexNV completely free now - it can read MKV directly, and reliably. (But you still need a compatible Nvidia card).
+ Reply to Thread
Results 61 to 69 of 69
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.
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.
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
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.
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.
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"
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)
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.