Selur's Little Message Board

Hello,

Long time no post. I have been doing pretty well with the AV stuff since, but now I need some help.

I record various movies and series from DVB-C TV, then use AviDemux to trim and remove ads. I save them as MKV, usually. Most files work wonderfully after, with no problems (unless the coax transmission went wrong somewhere).

But this file that I encoded in the 6th of May while also studying for uni, I managed to mess up - no clue how, I can't remember what I did. The resulting file stutters and loses frames in MPC-HC with LAV Filters 0.78.0 and Windows Media Player. Tried using different MPC-HC and LAV Filters versions, tried playing the file on a different PC (to avoid bad config on my side), but no avail.
Also tried using FFmpeg to copy to MP4, tried forcing FPS, timecodes and fixing bitstream info with MKVToolNix.
The file seems to play just fine on my Blu-ray player and the TV decoder, however.

Unfortunately, I do not have the source .ts file for this recording to re-trim it, so I have to find a way to fix it.

While analysing .ts sources and previous cut videos from the same TV channel using MediaInfo, I notice two wrong parameters:

The TV channel definitely did not change these two parameters just for a day, to change them back the next day, it would make no sense, so I definitely changed them somehow.

Here are two video samples, one correct and one from the video that I botched: https://drive.google.com/drive/folders/1...JDXjkgQRS7
The stuttering on the botched one (7x14) is most obvious during the fade in animation.

Any advice?

Thanks a bunch!

Taking 7x14 as source.
The AP intro is real progressive 25fps, then it looks like a norm conversion from 23.976 to 25fps by adding frames.
It doesn't seem interlaced by field shifted.
Bobbing the source and looking at the frames 300-349 (so 1 second of content)
300 301 302 304 306 309 312 314 317 320 322 325 326 328 330 333 334 336 338 341 342 343 346 349
so 24fps.
But looking at their differences: 1, 1, 2, 2, 3, 3, 2, 3, 3, 2, 3, 1, 2, 2, 3, 1, 2, 2, 3, 1, 1, 3, 3 there does not seem a fixed pattern.
(no clue whether the source was already like this or whether using Avidemux&Co you messed this up)

So one would either:
a. try to find an automated way to select the unique frames (using TIVTC or sRestore with adjusted settings)
or
b. use TFM or QTGMC or TIVTC (all with adjusted settings) + FillDuplicates (with Rife and an adjusted threshold, probably 0.004)
(or buy the complete DVD set box from ebay and upscale it themselves)

=> maybe someone over at videohelp&co has a good idea how to configure TIVTC or sRestore to detect the right unique frames.

Cu Selur

Ps.: https://forum.doom9.org/showthread.php?t=176104 might be interesting for some background on norm conversions.
PPs.: some h.264 headers can be changed wit ffmpegs bitstream filters https://ffmpeg.org/ffmpeg-bitstream-filters.html

(19.07.2024, 21:15)Selur Wrote: [ -> ]Taking 7x14 as source.
The AP intro is real progressive 25fps, then it looks like a norm conversion from 23.976 to 25fps by adding frames.
It doesn't seem interlaced by field shifted.
Bobbing the source and looking at the frames 300-349 (so 1 second of content)
300 301 302 304 306 309 312 314 317 320 322 325 326 328 330 333 334 336 338 341 342 343 346 349
so 24fps.

Weird... The audio tells a different story: i.e. the original file is just sped up by 104.2%. While watching any other episode in MPC-HC at 0.96% speed, the audio and video are fairly close to normal with no (visible) artifacts.

(19.07.2024, 21:15)Selur Wrote: [ -> ]But looking at their differences: 1, 1, 2, 2, 3, 3, 2, 3, 3, 2, 3, 1, 2, 2, 3, 1, 2, 2, 3, 1, 1, 3, 3 there does not seem a fixed pattern.
(no clue whether the source was already like this or whether using Avidemux&Co you messed this up)

Not sure what that sequence of numbers means. But you should be able compare to 7x13, which plays as it should and is not botched.

(19.07.2024, 21:15)Selur Wrote: [ -> ]So one would either:
a. try to find an automated way to select the unique frames (using TIVTC or sRestore with adjusted settings)
or
b. use TFM or QTGMC or TIVTC (all with adjusted settings) + FillDuplicates (with Rife and an adjusted threshold, probably 0.004)
[...]

=> maybe someone over at videohelp&co has a good idea how to configure TIVTC or sRestore to detect the right unique frames.

Wait, wait. I am not looking for a solution where I have to re-encode the video, neither do I want to mess with the 25 FPS, getting it to the original rate.
I don't remember what I did to break the file, but I know for a fact I did not re-encode it, so the fix should (ideally) not involve re-encoding, unless necessary.

But I am really curious, do you notice any difference in terms of timecodes, etc. (anything that would cause stutter) between 7x13 and 7x14?
Could you notice the stutter in MPC-HC on 7x14? It's supposed to be missing on 7x13.

(19.07.2024, 21:15)Selur Wrote: [ -> ]PPs.: some h.264 headers can be changed wit ffmpegs bitstream filters https://ffmpeg.org/ffmpeg-bitstream-filters.html

This might be useful for the purpose, I will read that and report back. Thanks!

(19.07.2024, 21:15)Selur Wrote: [ -> ](or buy the complete DVD set box from ebay and upscale it themselves)

Nah, too much work for too little fidelity. I'm actually thinking of getting the Blu-ray collection instead, since I like this show.

Length of each time codes in both files seems to be 24ms (attached file).
I see no combing at all in the 7x13 file, that seems to be just progressive, but flagged as interlaced.
(7x14 is a mix of progressive and interlaced content)

Quote:Could you notice the stutter in MPC-HC on 7x14? It's supposed to be missing on 7x13.

No. (using MPC-HC 2.3.3., NVIDIA Hardware decoding and MPC Video Renderer)


Cu Selur

(20.07.2024, 07:25)Selur Wrote: [ -> ]Length of each time codes in both files seems to be 24ms (attached file).
I see no combing at all in the 7x13 file, that seems to be just progressive, but flagged as interlaced.
(7x14 is a mix of progressive and interlaced content)

Interesting. Just took a look myself frame-by-frame on MPC-HC. What seems to be causing the stutter is the fact that, while deinterlacing, the resulting frame is played after one frame is repeated 3 times, then 2 new frames are played one after the other.
Sort of like (frame numbers): 1, 1, 2, 2, 3, 3, 3, 4, 5, 6, 6, 7, 7...
In any case, it is clear the TV station changed (one time only - you can see 7x13 was broadcasted the next day) the way they speed up the show for broadcast.

Now, how is this supposed to be played, or at least re-encoded?

If I process it with AviDemux, deinterlace with YADIF Field mode and decimate, the result is very strange still: 1, 2, 3, 3, 4, 5, 6, 7, 8, 8, 9.
Identical result is achieved with YADIF in Frame mode.

(20.07.2024, 07:25)Selur Wrote: [ -> ]

Quote:Could you notice the stutter in MPC-HC on 7x14? It's supposed to be missing on 7x13.

No. (using MPC-HC 2.3.3., NVIDIA Hardware decoding and MPC Video Renderer)

Strange. I am using MPC-HC 1.9.2.12, but still NVIDIA Hardware decoding and MPC Video Rendered. Also tried EVR (CP), but the result is the same.


EDIT: Oh, I think I just realized something obvious. One sure way to fix this is to resample the video to play at the original 24/1.001 FPS. That's a sure way to fix this.
Is there any other way, preferably done during decoding & playback?

Quote:Now, how is this supposed to be played, or at least re-encoded?

You don't want any duplicates and thus end up with 23,976 frames.

Quote:One sure way to fix this is to resample the video to play at the original 24/1.001 FPS.

That would be the idea, problem is just to find a good method to automatically remove the duplicates and end up with 23.976 fps

Quote: In any case, it is clear the TV station changed (one time only - you can see 7x13 was broadcasted the next day) the way they speed up the show for broadcast.

I do not think so, seems more like either you changed the way you captured/saved the content or how they broadcasted it.
Both files have are created through a norm conversion.

Quote:Is there any other way, preferably done during decoding & playback?

In theory, a player could do some ivtc like thing (fieldmatch + decimate using some proper detection or pattern), but I do not know of a player that would do that.

Cu Selur

So, I was able to fix the file.

The good news is I definitely was not the one who broke it, neither did the broadcasting. The problem is in the source file they broadcasted, since I doubt they were editing the episode on the fly (bear with my explanation): I used Hybrid and SelectEvery (AviSynth) to select the frames I wanted to keep. Every 8 frames, the same offset was used (there was a rule to the duplicates).
However, after every fade-out->fade-in transition, the offsets would change, indicating (to me, at least) that the TV station had this norm-converted file, to which they then trimmed the fades, while disregarding the offset.

Hence, in my opinion (and experience with TV recording), if I were to record this episode again in the future from this same station, I would get the same resulting file.

In any case, there's no way I broke it like this. While trimming it, I did not have the time to mess around with such complex settings, let alone re-encode a file in x264 (slow! - this trim was done in 5 minutes, including setting the trim points, opening the file, etc.): I had to learn for uni at the same time.

Thanks for the help, couldn't have solved this without!

Happy, you worked out a way to fix the problem!

Cu Selur