59.94 fps > 23.976 fps not working correctly

[Digital Corpus]

I didn't see any topics about this directly when searching, but if this has been discussed, please link me to the relevant thread. I'm also not sure if this is the proper forum since I'm using mencoder/mplayer and working with ATSC video.

Anyhow, I'm doing some fairly regular encoding of ATSC mpeg-2 streams. From stepping through most of my 1080i and 720p recordings, I noticed a pattern. All of the actual shows are at 23.976 fps. The broadcast video stream is setup at 59.94 fps though. For the 1080i shows this isn't a big deal since passing them through a de-telecine filter works just fine.

My stumbling block is with every 720p show. I cannot encode them directly to 23.976 fps because across different scenes/cuts/edit, the order of those 24 frames isn't always in the same "pattern", such as what can happen to interlaced or telecined material if edited too much. Passing the 720p video through mencoder's pullup is fail so I'm wondering what alternatives I can try to ensure I lock onto the right frames when going from 59.94 fps > 23.976 fps. I've been using an encoded frame rate of 29.97, but having every 5th frame be a duplicate of the 4th gets visually annoying. :thanks::thanks:

[thewebchat]

Decimate by 2 and then use TDecimate? Maybe use TDecimate(cycle=10,cycleR=6)? Actually, if these are TV broadcasts, they often use the RFF flag to do "progressive telecine," so perhaps you could just force film.

[linyx]

I would give it a shot with FDecimate(23.976).
BTW - A little clip from the source (~30 seconds) wouldn't hurt to help identify how to properly decimate it.

[Ghitulescu]

I'm from EU, where the 720p is the approuved norm (EBU), and I wonder how can 720p be broadcast at 59,94, because 59,94 is 59,94i. It should be broadcast at either 23,976p or 24p, or in EU at 25p. Maybe the flags are incorectly set ...

[Digital Corpus]

I've never used decimate before, but that seems like it would work. I used dd to cut this. It's about 33 seconds long.

http://atlas.selfip.net/Castel-30sec.ts

...Actually, if these are TV broadcasts, they often use the RFF flag to do "progressive telecine," so perhaps you could just force film.
If I understand that correctly, that wouldn't apply as each frame is progressive. I'm playing them back in VLC without any filtering.

[2Bdecided]

I'm from EU, where the 720p is the approuved norm (EBU), and I wonder how can 720p be broadcast at 59,94, because 59,94 is 59,94i. It should be broadcast at either 23,976p or 24p, or in EU at 25p. Maybe the flags are incorectly set ...No. 720p50 and 720p60 (59.94....!) are most common. 720p25 and 720p30 (29.97....!) are less common.

(...at least for broadcast. Obviously 720p24, p25, and p30 are common on the web, while p50 and p60 are not)

Cheers,
David.

[thewebchat]

I've never used decimate before, but that seems like it would work. I used dd to cut this. It's about 33 seconds long.

http://atlas.selfip.net/Castel-30sec.ts


If I understand that correctly, that wouldn't apply as each frame is progressive. I'm playing them back in VLC without any filtering.

If applied to frame-based progressive video, the RFF flag repeats entire frames.

And you are wrong, Ghitulescu, the 720p standard supports framerates of 60 fps for NTSC and 50 fps for PAL.

[Ghitulescu]

If applied to frame-based progressive video, the RFF flag repeats entire frames.

And you are wrong, Ghitulescu, the 720p standard supports framerates of 60 fps for NTSC and 50 fps for PAL.

I knew that, I thought that 59,94 came from TCed progressive material to make them compatible also with the previous generations of HDTV TVs which were not capable of 24p but 60i (DF included). I've checked with a colleague that is in the States and indeed there are broadcasts that are 1280x720p59.94 - usually sport events. My mistake sorry. In this case the signal should have been pure progressive, as true 60p cameras were/should have been employed.

[Digital Corpus]

Well so far I've gotten this far with decimate
decimate=2:10240:1024:1/50 It's not perfect as I get a little bit of ghosting here or there and I still have some stuttering with duplicate frames. Now I was wondering if there is a way, without two pass that I can do a conversion to 30/29.97 fps and then pipe that to mencoder again and have it filter out that one duplicate frame. I'm hoping that this would be more accurate and a bit faster maybe.

[manono]

Well so far I've gotten this far with decimate
decimate=2:10240:1024:1/50
I have no idea what that means but have you figured out yet that the average framerate isn't 23.976fps? ABC is up to its old tricks in speeding up the video so they can fit in more ads. Unlike last year, though, when they were dropping frames, this time they're frame-blending. The effective framerate is roughly 24.3fps. I don't know if you can get rid of all the dupe frames, but having some dupes is better than dropping unique frames. You can also get rid of some/most of the blended frames by using an unblender on it before decimating. Plus, that ABC HD logo moving around even when the rest of the frame is a dupe messes up the dupe removal. I had decent results using a simple:

SRestore(FRate=24.3)

You won't need to add a bobber first as it's, in effect, bobbed already. There are still some dupes remaining, but a short examination of the result didn't turn up any dropped frames, although there may be some. You can probably tweak it a bit for better results.

http://avisynth.org/mediawiki/Srestore

[Digital Corpus]

I have no idea what that means but have you figured out yet that the average framerate isn't 23.976fps? ABC is up to its old tricks in speeding up the video so they can fit in more ads. Unlike last year, though, when they were dropping frames, this time they're frame-blending. The effective framerate is roughly 24.3fps. I don't know if you can get rid of all the dupe frames, but having some dupes is better than dropping unique frames. You can also get rid of some/most of the blended frames by using an unblender on it before decimating. Plus, that ABC HD logo moving around even when the rest of the frame is a dupe messes up the dupe removal. I had decent results using a simple:

SRestore(FRate=24.3)

You won't need to add a bobber first as it's, in effect, bobbed already. There are still some dupes remaining, but a short examination of the result didn't turn up any dropped frames, although there may be some. You can probably tweak it a bit for better results.

http://avisynth.org/mediawiki/Srestore
Sorry that I wasn't more clear, but I'm running a Linux box using mencoder. Do you have any other information where I can read up on individual stations/channel frame rates?

BTW, that doesn't seem too major of a difference for them. It equates to a single 30 second commercial per hour.

[manono]

Do you have any other information where I can read up on individual stations/channel frame rates?
Nope, I don't cap and just see samples here and there. I'm sure others know more about it than I.
It equates to a single 30 second commercial per hour.
Every $100,000 helps. :)

[Digital Corpus]

How would/could I go about figuring out the "true" frame rate other than counting one by one by stepping through the 60 fps goodness?

[manono]

You have to figure out the cycle if, indeed, there is one with these things. This involves counting hundreds, if not thousands, of frames. With this kind though, you could just get a rough approximation of the exact framerate, good enough so that there aren't any dropped frames, and not worry about a few dupe frames here and there.

And the cycle, if you discover one, may not hold true for the next show, or even for the next episode of the same show, so it's kind of a fruitless exercise.

[Guest]

You could also coerce MultiDecimate into giving the base frame rate, but blends would confuse things.

[2Bdecided]

If you're not a perfectionist, the source isn't that bad as it stands - at least in terms of blending and stuttering.

I know it can be encoded far more efficiently, but you're unlikely to make the frame rate "issues" look much better when actually watching it.


...and if you are a perfectionist, you'll probably be looking out for where the de-duping went wrong. And you'll end up with a non-standard frame rate or need to mess with the audio.

So maybe... encode the 60 frames per second that you have? (I can't find an appropriately horrified smiley to put after this suggestion ;) )

cheers,
David.