Interlaced video output support?

  Thread Rating:
  • 1 Votes - 5 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Post Reply
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Lightbulb  Interlaced video output support?
Post: #1
Please can we have interlace video output and let the TV do the hard work of deinterlacing and pulldown detection?

I understand the biggest problem to overcome in order to achieve this is maintaining correct field order.
Taking an idea from some MythTV discussion I read a while back there is a way to maintain correct field order without relying on any field synchronisation signal from the video card.

Currently 2 fields are presented to the frame buffer at the same time something like this:
Code:
Frame A  A  B  B  C  C  D  D
Field 12 12 34 34 56 56 78 78
Video t   b t   b t   b t   b (t=top field, b=bottom field)

This is fine if the video stream (encoded with top field first) just happened to start just before the top video field is displayed.
If the stream started when the bottom field was about to be displayed, field order would be incorrect with ugly consequences:
Code:
Frame A  A  B  B  C  C  D  D
Field 12 12 34 34 56 56 78 78
Video  b t   b t   b t   b t

If instead 1 field was presented to the frame buffer per vertical sync, field order would always be correct:
Code:
Frame A  A  B  B  C  C  D  D
Field 12 32 34 54 56 76 78 98
Video t   b t   b t   b t   b
Code:
Frame A  A  B  B  C  C  D  D
Field 12 32 34 54 56 76 78 98
Video  b t   b t   b t   b t

Let us assume we always have available the current decoded frame and 1 future frame and for this discussion the video source is top field first.
To start, the current frame is written to the frame buffer. After the first vertical sync (either field 1 or 2 has just been displayed) the top field of the future frame (field 3) is written over the top field in the frame buffer (field 1) leaving the bottom field untouched (field 2). Then after the next vertical sync the bottom field of the future frame (field 4) is written over the bottom field in the frame buffer (field 2) leaving the top field untouched (field3). After the next vertical sync a new decoded frame is available. The process repeats using the new frame as the future frame.

Other issues that would need consideration are:
The video cannot be resized and must be displayed 1:1.
Video and audio might be out of sync by 1 field depending on luck.

Benefits of interlace output are leaner hardware. I envisage IGP or CPU video decode where there is not enough computing power to implement high quality deinterlace and pulldown detection. I am assuming of course the TV has a good deinterlacer and does not just do plain old bob like some cheaper flat panel TVs do.

Stu-e
find quote
bobo1on1 Offline
cheapass Team-XBMC Developer
Posts: 2,758
Joined: Dec 2008
Reputation: 22
Post: #2
Only problem I see with this is, on interlaced resolutions, you get a vertical blank signal per field, and you have no idea which field you're on.
This could work if the tv could detect interlaced video on a progressive resolution.
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #3
Quote:you get a vertical blank signal per field, and you have no idea which field you're on.
The whole thrust of my post is it does not matter which field you are on. You get a vertical sync for each field. That is all that is required.

Quote:This could work if the tv could detect interlaced video on a progressive resolution.
I'm not sure I understand. Do you mean "the tv could detect progressive video on an interlaced resolution"? This is indeed how progressive content is delivered for nearly all broadcast TV and is reliant on the the TV detecting pulldown (2:2 for 50Hz and 3:2 for 60Hz). The method I have described in this post can deliver progressive content via an interlaced video stream providing the TV has adequate pulldown detection.

Stu-e
find quote
bobo1on1 Offline
cheapass Team-XBMC Developer
Posts: 2,758
Joined: Dec 2008
Reputation: 22
Post: #4
Quote:The whole thrust of my post is it does not matter which field you are on. You get a vertical sync for each field. That is all that is required.
Ok I get it now, if you use an interlaced resolution and output interlaced video with exact alignment, it should display correctly.

Quote:I'm not sure I understand. Do you mean "the tv could detect progressive video on an interlaced resolution"? This is indeed how progressive content is delivered for nearly all broadcast TV and is reliant on the the TV detecting pulldown (2:2 for 50Hz and 3:2 for 60Hz). The method I have described in this post can deliver progressive content via an interlaced video stream providing the TV has adequate pulldown detection.

Stu-e
Some tv's can detect the combing of interlaced video on a progressive resolution, and automatically turn on the deinterlacer.
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #5
Quote:Some tv's can detect the combing of interlaced video on a progressive resolution, and automatically turn on the deinterlacer.

Wow! That's a really cool feature. I want one. Would you happen to know what models do that?

Stu-e
find quote
elupus Offline
Team-XBMC Developer
Posts: 3,804
Joined: Mar 2004
Reputation: 3
Post: #6
I like the idea alot actually.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
elupus Offline
Team-XBMC Developer
Posts: 3,804
Joined: Mar 2004
Reputation: 3
Post: #7
Ps... Video can be resized, it just need to be weaved on output.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #8
Resizing interlaced video?
That sounds difficult.

Stu-e
find quote
bobo1on1 Offline
cheapass Team-XBMC Developer
Posts: 2,758
Joined: Dec 2008
Reputation: 22
Post: #9
It's really not that difficult actually.
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #10
I assume you would resize each field independently and then re-weave the 2 fields back into a frame. I was concerned about vertical detail becoming repeated. For example imagine the top half of the screen is red and the bottom half is green:
Code:
r
r
r
g
g
g
x2 would become:
Code:
r
r
r
r
r
g
r
g
g
g
g
g

Stu-e
find quote
elupus Offline
Team-XBMC Developer
Posts: 3,804
Joined: Mar 2004
Reputation: 3
Post: #11
the mixed one would not be red or green anymore thou.. they would be a gradient between red and green. same as if you would have scaled a non interlaced image. the border would not be read or green. it would be a transition value.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #12
Ok so the fields are not scaled independently. Instead they are scaled with some relationship between neighbouring fields. Forgive me but this is starting to sound like deinterlace followed by scaling on the resulting progressive frame (at field vsync rate). Trivial for interlace encoded film but tricky for true interlaced video where there is a temporal difference between every neighbouring field.

Stu-e
find quote
elupus Offline
Team-XBMC Developer
Posts: 3,804
Joined: Mar 2004
Reputation: 3
Post: #13
Stu-e you missunderstood.. Fields should be scaled independently. I was just saying that a similar issue exists for non interlaced video when you scale.

Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.


[Image: badge.gif]
find quote
Rachel Offline
Senior Member
Posts: 158
Joined: Jun 2009
Reputation: 0
Post: #14
I've been posting on this issue but I think I was doing so in the wrong place. :-) Because of my hardware I was adding my question to the "[LINUX] HOW-TO achieve perfect playback at 23.97 or 59.94 Hz with NVIDIA GPU hardware", with my posts starting partway down this page: http://forum.xbmc.org/showthread.php?tid=70068&page=29

To summarise, with respect to what's gone before in this thread...

I have some source media that I've been unable to detelecine satisfactorily - Stuff that had been telecined from 1080i@25fps to 1080i@29.97fps; with apparently different telecine patterns used on different titles from the same publisher.

I decided to give up on detelecining and achieving a good progressive rip, and instead just play them interlaced.

I got XBMC to output to an interlaced mode; the TV reports switching to 1080i, and *initially* the media starts playing perfectly.

But after a while (different while with different media) I think the field synchronisation drifts out, producing an unwatchable judder - I think basically as if it switches from Top-Field-First to Bottom-Field-First, though I don't know if that's what's actually happens; it looks like it.

My Bluray player can actually play MKV files from a USB drive, so I gave it the same files and it's playing them just fine; certainly not showing the same problems I saw via XBMC, though I may be seeing an unrelated problem due to the slowness of the USB stick I was testing with, so I believe the encoding of the files themselves is OK.

Now, I originally posted this on that other thread because it looked to me like it might be specific to the platform and hardware (Linux, GPU-assisted playback via VDPAU on an nVidia ION platform), but I just found this thread and am now wondering if it might be a more general issue? And maybe, that what I thought might just be a bug might actually be that interlaced playback just isn't fully implemented yet?
find quote
Stu-e Offline
Member
Posts: 89
Joined: Jan 2010
Reputation: 1
Post: #15
Yes interlaced output is not at all supported by XBMC or any other media playback software I can think of.

My experience is similar to yours in that it is better in many circumstances just to pass the video on to the TV as is and let the TV work out when to deinterlace or inverse-telecine and perform any other kind of video processing, just like most set-top boxes like DVD players for example.

What you describe is exactly what happens for most interlaced video material. It's generally pot luck when an interlaced video is played, field order is correct and if a graphics card vertical sync is missed for some reason, field order goes wrong (or if it was wrong goes right).

I must add I have only tinkered with XBMC code and I am not an XBMC developer.

I have been unable to suggest any patches to XBMC to support interlaced playback due to my lack of knowledge of XBMC code. However I have been experimenting with a somewhat ancient FFMPEG tutorial here:
http://dranger.com/ffmpeg/
So far I have managed to write video fields to the graphics card frame buffer at field rate as I described earlier. I have not yet viewed the result on a proper interlaced display like a TV. With correct vertical scaling (i.e. none) I am confident it will work, at the expense of switching video resolution to match the video source.

Stu-e
find quote
Post Reply