[homze]

am i right at assuming the xbmc doesn't really support interlaced playback at the moment, becouse of the mplayer can't actually handle interlaced playback right?

the situation is, i have 50hz pal widescreentv and interlaced recordings from dvb-c. one way i have got this work is with mplayer parameter to ignore all odd or even fields, but then the vertical resolution drops from 576 -> 288, not good but atleast the motion is smooooooooooth. with deinterlace filter the motion gets some choppyness, and adding flicker filter the motion get's kind of smooth, not really natural and hte picture is very blurry - looking like picture in all those 100hz tv's

i got some smooooth motion and crystal clear picture with original resolution (720x576i) and some mplayer switch with the cvs version somewhere start february, but the picture lost it's sync (interlace sync, not the audio-video sync) after rr or rw, and the audio-video sync get too long to stable or if it really stabled at all...

are there any cure for this disease at this moment? and will there be a good support for interlaced playback in the new dvd core, and will it be able to playback other file formats with that new core?

dvd-movies with the other xbox dvd-players looks like or even better than in my pioneer dvd-player (with special made rgb-cable, the chinese advanced-scart xbox cable was crap...)

teemus

ps. if you can't get the idea what's my problem i think i can send some videoclips...

[jmarshall]

the main problem with interlaced material is scaling vertically.

if you run in "original size" mode, it should keep the vertical resolution in-tact, and only scale on the x-axis, so you should get no interlacing (in theory).

i haven't got any decent, short, clips from a confirmed interlace source from which to play with.

if you can provide such a clip, that'd be great. i'm looking for one the clearly shows the interlacing as soon as possible in a short clip that has not been touched since source recording.

cheers,
jonathan

[A600]

if you can provide such a clip, that'd be great.  i'm looking for one the clearly shows the interlacing as soon as possible in a short clip that has not been touched since source recording.

i've sent you a pm with the links of 3 mpg2 samples i've uploaded.

[billou2k]

you're right using the original size mode works... nearly...
i have a pal system and playing pal interlaced clips in that mode sort of works... if you are lucky you'll have the original smooth motion of the 50 hz (assuming you've set up the flickering filter to 0) but if you are not lucky you'll get one second of video smooth then a few frames will be jerky then another second smooth and then again a few frames jerky... the only solution i came up with is to pause the video and restart it several time until your video stays smooth all the time...
i suspect there is something to do with the frame not beeing refreshed in a synchronised way with the tv causing old/new fields being displayed in the wrong order (but that's just a guess).

the other problem with using "original size" mode is that playing interlaced ntsc clips doesn't work: in ntsc the fields are reversed therefore at best it appears jerky all the time...

i guess the solution would be to detect if the clip is pal or ntsc and then according to the system it is played on: reverse (or not) the fields (or the dominant field).
or if auto detection is not possible, just have an interlaced menu in the full screen mode (instead of a deinterlacing mode that i dont find very appropriate for a system using a tv) that would set up the flicker filter to 0 and force the "normal size" mode when ticking the "interlaced video" option, another option would allow to swap the dominant field (to playback pal/ntsc)

another better way to deal with interlaced would be (on top of field swapping if necessary) to rescale fields independantly (by converting the frame into two fields on top of each other, then rescale it to fit the custom screen boundaries), and then display the re-weaved fields.
that way we don't need to set up a special mode and hd interlaced clips could be played on standard res screens.

but that probably doesn't solve the jittering problem descirbed earlier.

(also i've noticed that setting "original size" mode during the playback of a clip, then exiting and opening a new clip results in having just one pixel zoomed to occupy the full screen (basically only one colour on screen), to fix this i have to cycle through all the modes and go back to "original size", anybody experienced this?)

[sneals]

i suppose the other way of implementing this would be to do what windows media center seems to do. i'm running win mce 2005 with powerstrip and a vga->rgb scart cable (using a radeon and powerstrip to create a 1024x576 50hz interlaced mode, with composite syncs)

mce seems to take a 576/50i video source, and de-interlace it - but creating a 576/50p (i.e. making a full frame from each field) rather than creating a 576/25p (i.e. merging two fields into one frame and thus blurring and reducing the motion rendition to half that of "video). the pc then re-interlaces this 576/50p signal back to 576/50i for display on the tv.

this means you get smooth video, no juddering or blurring on rolling or crawling text, or fast moving video sources like sports coverage etc.

if the xbox could be persuaded to treat interlaced video in this way, assuming it has the power (which i'm guessing it doesn't?), it might work. the problem with many "pc" video solutions is that people who implement de-interlacing de-interlace at the frame rather than field rate?

also if you get the de-interlacing right you can then scale the material and re-interlace without scaling artefacts - though this is only the case if you have a really good de-interlacing scheme, otherwise you still get nasty scaling artefacts. (mce suffers from these if you don't have optimisefor television set in the registry and are running a 1:1 input to output resolution mapping)

[Joergen]

i just recently noticed that when playing a 50 field mpeg2 or .vob (meaning camera material or tv etc) xbmc has trouble rendering the exactly 50 fields so that motion is smooth. it renders the video with segments of stuttering and jumping, then maybe a couple seconds of smooth motion and again stuttering.

with 25fps (movie) material in .vob or .mpeg2 (ie dvb capture with mp2 audio) this isnt noticeable as there is no fluid motion in the fields to reveal it, and it seems to render the 25 frames just fine.

i tried a couple 04.2005 builds without any difference.

i became aware of this problem while trying to stream dvb from mytheatre and the video was stuttery in places and smooth in others. i then made a clip .vob in dvdshrink of a tv show that has 50 fields of smooth motion (filmed on beta etc), copied to the xbox hd and it too has the same stuttering.

disabling the rss feed seemed to help at first but it was just luck it seems.

any ideas?

ps. it kinda looks like a field-order problem but i wouldnt bet on it.

[Joergen]

i tinkered with the unknown internet cache setting and setting it to where the dvd cache is by default (16+) makes the streaming blocky and full of block errors.

dropping it to under 10 makes the blocks go away but the few-seconds-smooth few-seconds-wrong-field-order-thingy comes back.

also playing the .vob off the hd.. if i jump forward with the up arrow it may play smoothly from thereon, but jump again and the field-bug comes back for good and not a millisecond of smoothness is seen from there forward.

i also tried going to ntsc by changing the eeprom and it seems these 50-field materials play solidly at all times in pal60, you can see the combing of the fields but the playback is solid and unchanging, even smooth. definetly smoother than at 50hz when the bug shows up.  

i'm calling it a field order bug cause i've done some svcd and dvd encoding in the past (from dv cam material) and setting the field order wrong gives pretty much the same flickery/stuttery effect.

ie when a fade-out comes (to black) the image flashes between the different shades (when it goes from darker-lighter evendarker-darker darkest-evendarker instead of lighter-darker darker-evendarker evendarker-darkest) and in fast panning people warp back and forward instead of going smoothly.

in fact, now that i've been looking at this fast paced x-treme bmx thing on the tv stream, i'm convinced its a field order bug.. changing on the fly.

[Joergen]

playing the actual dvd from where the .vob clip was taken in xbmc produces the same stutter. playing it in dvd region x has no stutter.

i tried reverting all the xbmc files to 1-apr-05 but it didnt help. next i'll try an even older build.

edit: ok i tried the 12-march-05 build and it has the same stutter. i guess nobody has tested .vob and .mpeg2 with non-film material recently

[Joergen]

does anybody know which .dll decodes mpeg2? i tried replacing libmpeg2.dll with the libmpeg2_ff.dll from my pc but it made no difference.

i can upload test clips so others can try, but any pal dvd with a smooth scrolling 50fps menu animation should do fine for testing if anybody wants to verify this bug.

edit: now i tried xbmp and it seems to have the same field-order bug but constant, never switching to smooth 50field motion at all. i tried scaling the image up and down to match the fields to the screen too.

so, i guess this is a really long running issue.

[Joergen]

oh i see, by default the flicker filter is set to 1 under "video filters", together with gui filter at level 5 it aids to effectively deinterlace the video down to 25frames instead of rendering each field separately, hiding the fact that 50field rendering is broken. take them both down to 0 to actually see both fields and its stutter-o-mundo.

and yes, its definetly a field-order bug.. field2 rendered before field1 (or reversed) resulting in a backward motion in every other field. :bomb:

the video still stutters a little in places but generally runs like a 25fps film material does.. and playing a normal pal film-based movie you wont notice the difference (only slightly more blurred image).

though i must say, thats a very drastic measure.. and really hurts interlaced material, and should deserve a mention in the known issues and limitations.

[Joergen]

1) took a short clip from cnn europe (has scrolling text that uses both fields for motion = good test).

2) dragged it into dvd2avi, saved the avi in divx5.

3) both flicker filters to 0

first start of the video = smooth motion, natural.
video ends, gui shows
second start of the video = field-order reversed, stable flicker/stutter
video ends, gui shows
third start of the video = field-order reversed, stable flicker/stutter

and a randomly it either starts with the correct field order or doesnt.

important: field-order bug affects .avi / divx5 material aswell as mpeg2

regardless of whether this method stores the fields correctly or just encodes a frame with field-combing, field-order chosen when playing the video is random. edit: profile was "home theater" interlace: allowed.

[Joergen]

the field-order switching seems to manifest itself even on 25fps film-based material as very small glitches, probably one frame pause or jump.. almost unnoticeable.

i have watched long sessions of film-based ntsc material at pal60 without problems, i havent yet watched any ntsc cam/60field material though (dont have any).

[jmarshall]

just so you don't think your posts are out in the ether with noone listening...

i know there is issues with interlaced material. there aren't many ways around it, unfortunately.

the problem is 2-fold:

1. we rely on mplayer sorting out which field to present first - this can be customised by you using a .conf file to specify the field order yourself.

2. scaling happens per frame and not per field. this is the most important issue imo, and i haven't had time to look into it properly.

there is some video filters you can use through mplayer to help solve this issue.

one of them is the one that splits frames -> fields effectively doubling the framerate.

i believe that if we scaled these correctly, i think the situation would be improved somewhat.

check the mplayer man page for info on the filters.

cheers,
jonathan

[A600]

one of them is the one that splits frames -> fields effectively doubling the framerate.

i believe that if we scaled these correctly, i think the situation would be improved somewhat.

the best filter is: vf=tfields=2 this doubles the framerate but have some cons:

- original resolution is reduced to the half so the picture quality when zoomed is worse. (is this normal?)

example:


- hardware overlays filter isn't as smooth as pixel shader.

[Joergen]

thanks for the response jm.

i believe you're talking about bob deinterlacing where the field is doubled into two rows of pixels and each field then alternates 50 times per second as a full frame. and like a600 said said the disadvantage is halved vertical resolution, and yes that is normal. weave would produce better results but again, the best way to draw it would be field to field.

it's very close now to perfection if you use normal or stretch 4:3 or original resolution when playing the 720x576 or 704x576 material, only the field order needs to be more stable and unaltering. sometimes it gets playing great and other times wrong with the same settings.

but any and all of those deinterlacing methods were designed for progressive displays (and are again useful if using such a display), and like you said mplayer needs to more precisely draw the fields to the screen.

in any case, i've been loving xbmc ever since i started using it a couple weeks ago and this thread is just me testing it to its limits

thanks for the great software, everybody involved in making it!