Incorrect Detection of Interlaced Video?

[markyp 38]

The included sample is from a recorded video from Live TV in the UK...

here are the details of the original video reported by Emby Server:

note the framerate...

@softworkz

t2.ts

[visproduction 315]

TV frame rates in the UK are 25 fps.  Since it is 1080P 16:9 there should be no interlace.  The example video plays back correctly as sequential but compressed frames, not interlaced.

[markyp 38]

this might be a better example - taken from the actual game!

t3.ts

[softworkz 5066]

@markyp- Thanks for posting the files.

The first one, t2.ts is not interlaced.

And when I add t3.ts to Emby it is correctly identified as interlaced:

 

Do you see a different result?

[Carlo 4560]

Historically, with few exceptions, broadcasts at 1080 were interlaced and 720 were not interlaced in the US & UK.

[markyp 38]

T2 and T3 are samples taken from the same recording!

Emby Server identifies the original recorded file as not interlaced as seen in the 1st post... but T3 is not!

 

Edited October 21, 2024 by markyp

[softworkz 5066]

From which source was that recording made? 

39 minutes ago, markyp said:

T2 and T3 are samples taken from the same recording!

And what exactly do you mean by that? Samples from the same .ts file?
How did it happen that one part is interlaced and the other not?

And also - what do you expect Emby to do? A single file can only be marked as interlaced or as not interlaced  

Edited October 21, 2024 by softworkz

[rbjtech 5284]

Some UK Channels (ITV for one) broadcast 1080i/25 on some programmes and 1080p/25 on others - it's a mixed bag.   I've seen it happen on commercial breaks, where the main programme is interlaced/the commercials not - or visa versa.

Depending on the client settings (mostly AndroidTV in my case), playback will direct play and the client will interlace if it needs to - or double the framerate to 50fps in some cases.  Easy to see using stats for nerds on AndroidTV - not easy to identify when using the replacement Android client - as it doesn't tell you these details ...

Edited October 21, 2024 by rbjtech

[Carlo 4560]

I've seen this in the US as well with commercials.
Besides the switch of Interlacing, the resolution can change as well.

[Guest]

I've always maintained that the video player should be responsible for choosing to deinterlace.

[softworkz 5066]

49 minutes ago, generiq said:

I've always maintained that the video player should be responsible for choosing to deinterlace.

MPV docs are mentioning false-positives at the frame level as the reason why "auto" is not the default for the --deinterlace option. That's why I'm currently enabling this only when Emby has probed a file as being interlaced. Probably it needs to be extended to always insert it when it comes from a .ts file.

[softworkz 5066]

10 hours ago, rbjtech said:

Some UK Channels (ITV for one) broadcast 1080i/25 on some programmes and 1080p/25 on others - it's a mixed bag.   I've seen it happen on commercial breaks, where the main programme is interlaced/the commercials not - or visa versa.

 

2 hours ago, Carlo said:

I've seen this in the US as well with commercials.
Besides the switch of Interlacing, the resolution can change as well.

I've seen aspect ratio changes, bandwidth changes, audio stream changes and others, but I've never seen a DVB stream changing from interlaced to non-interlaced during a broadcast of a program. I guess German broadcasters are too professional to do such things.  

Also, the provided *.ts snippets were in some way processed by ffmpeg - not original broadcast streams, that's why I was asking about the origin.

[Guest]

14 minutes ago, softworkz said:

MPV docs are mentioning false-positives at the frame level as the reason why "auto" is not the default for the --deinterlace option. That's why I'm currently enabling this only when Emby has probed a file as being interlaced. Probably it needs to be extended to always insert it when it comes from a .ts file.

But it operates on a frame by frame basis. So if it gets some frames incorrectly identified, the overall result is good. And in this case, if they were watching the live stream and began with progressive commercials, the actual show wouldn't be deinterlaced. This is much worse than some frames not being correctly identified and deinterlaced/not deinterlaced. My mpv deinterlacing config has never failed to provide a deinterlaced output. I'll take dynamic deinterlacing over static every time.

[softworkz 5066]

4 minutes ago, generiq said:

But it operates on a frame by frame basis. So if it gets some frames incorrectly identified

I don't think it's about "some frames". In that case, they could have made "auto" the default setting.

The way I understand it, is that in "some cases" all frames are marked incorrectly.

[Guest]

4 minutes ago, softworkz said:

The way I understand it, is that in "some cases" all frames are marked incorrectly.

As it is in this case.

[softworkz 5066]

15 minutes ago, generiq said:

As it is in this case.

No. In this case, the frames are marked correctly in each part.

[Guest]

I've just combined both clips into one file. The first half is progressive and the second is interlaced. Emby only tests the start, so this means when the second half starts, it will remain interlaced. Just as it would if you watched the whole stream from that point. This is a failure.

But when I play it in mpv with auto-deinterlacing, I can see in the stats when it activates.

 

 

 

 

[softworkz 5066]

10 minutes ago, generiq said:

Emby only tests the start, so this means when the second half starts, it will remain interlaced. Just as it would if you watched the whole stream from that point. This is a failure.

This is not a failure. Like I wrote above:

12 hours ago, softworkz said:

And also - what do you expect Emby to do? A single file can only be marked as interlaced or as not interlaced  

 

If Emby would mark it as interlaced, it would also be wrong, because the first part is not interlaced.

[softworkz 5066]

14 minutes ago, generiq said:

I've just combined both clips into one file.

BTW, just concatenating two ts files is absolutely not valid.

[Guest]

Just now, softworkz said:

If Emby would mark it as interlaced, it would also be wrong, because the first part is not interlaced.

And that is my point. Leave it to the video player, when possible. It's dynamic.

[Guest]

Just now, softworkz said:

BTW, just concatenating two ts files is absolutely not valid.

But his recording/live stream is exactly that

[softworkz 5066]

7 minutes ago, generiq said:

But his recording/live stream is exactly that

LOL, no. 

[Guest]

Just now, softworkz said:

LOL, no. 

Those two clips are from the same file/stream/recording. 

[softworkz 5066]

MPEGTS is the one format that I know down to the bit level, but I don't have the time right now to elaborate. I can only say that it's wrong for more than half a dozen or reasons. 

And for HLS it's not even valid to chop an existing, valid and continuous stream into pieces. That's also wrong.

Maybe I'll explain at another time when I got some passion to do so.. 

[Guest]

6 hours ago, softworkz said:

MPV docs are mentioning false-positives at the frame level as the reason why "auto" is not the default for the --deinterlace option. That's why I'm currently enabling this only when Emby has probed a file as being interlaced. Probably it needs to be extended to always insert it when it comes from a .ts file.

So, the manual says this:

The example being incorrect encoding. I believe we can rule that out, as you have established how the server does this....correctly, yes? And if a file were incorrectly encoded, the server would also incorrectly detect interlacing.

So the next question is, do you trust ffmpeg to detect interlacing, correctly? That caution was written a long time ago, and I would think you and your comrades have made improvements since then?

Next question. This is the property I use to detect interlacing.

video-frame-info/interlaced

I assume this is using ffmpeg? I've used it for a long time in my mpv.conf, and it has not failed me.

So, apparently this all hinges on ffmpeg detection, for the server and mpv.