[d7o3g4q]

frodo is right, mplayer won't produce field based output.

most of the time, this isn't much of a problem. when i encode avi's from interlaced sources, i always deinterlace at encoding time. saves cpu time during playback.

however, this is problematic with dvds. since some content is encoded interlaced (field based). other aspects, such as tivo playback, are usually interlaced source video.

the xbox does, however, support field based rendering. we don't use it since the output from mplayer is frame based.

d7o

[sneals]

thanks for this. i did a bit of mplayer digging - and it seems that others have got pc based mplayer running with field-based interlaced replay working smoothly and cleanly.

video cards that can run at video rates (and not by converting 800x600 via a tv out converter process that mangles the video) - such as some of  the matrox g400 etc. devices have an option in their mplayer drivers (i think - i'm a hardware not a software person) to support fieldparity on replay - allowing you to force either top or bottom field dominance to ensure smooth replay matching the interlaced source materials dominance.

i have no idea if this is specific to the matrox drivers - or indeed at all relevant to the xbox implementation of mplayer - but it does imply that some mplayer implementations can cope reliably with interlaced replay in interlaced mode. the option seems to be mention in section 2.3.1.2.13. directfb of the mplayer documentation - i found it by some googling on mplayer and interlaced replay.  the search "-vo dfbmga:fieldparity" seems to call up a hit or two - this was the recommended solution on a mailing list to reliably provide smooth replay of interlaced material on interlaced displays. (i.e. tvs fed directly from video cards - rather than via a tv output option)

indeed there are a number of posts from people who are using pc based mplayers with suitable (it seems matrox) video cards connected via their vga (not tv out) outputs to rgb scart enabled tvs (and watching video encoded in mpeg2 from a pvr250 or similar)

of course i suspect all of this is bobbins - and not relevant to the xbmc implementation of mplayer - as the video output side of the xbox probably works differently.  however it does suggest that mplayer can reliably replay interlaced material in some cases. (presumably care must be taken to ensure no vertical scaling - or only simple field-based scaling - is performed - and that material is shown in its native resolution?)

nb - i've also found references to nvidia cards (again on pcs) being persuaded to display smooth interlaced video replay from mplayer (this time from a freevo thread) - and being compared to matrox ones.

freevo interlaced replay with mplayer and nvidia

[Frodo]

hmmm read that story, but it it got nothing todo with true interlaced playback.
the guy just setup/tweaked freevo to use the correct params for mplayer for his nvidea card
(something freevo should do automaticly)
he changed the setup from 800x600 to 720x480.
but the fact still remains that
1. mplayer deinterlaces the video stream
2. mplayer outputs full fields(non-interlaced) to gfx card
2. the nvidia card itself converts it to interlaced video again using its video output chip

just like the xbox does.
frodo

[Gamester17]

you and everyone hopping to see this in the future should really lobby the function to the mplayer and mplayer g2 developers

[sneals]

hmmm read that story, but it it got nothing todo with true interlaced playback.
the guy just setup/tweaked freevo to use the correct params for mplayer for his nvidea card
(something freevo should do automaticly)
he changed the setup from 800x600 to 720x480.
but the fact still remains that
1. mplayer deinterlaces the video stream
2. mplayer outputs full fields(non-interlaced) to gfx card
2. the nvidia card itself converts it to interlaced video again using its video output chip

just like the xbox does.
frodo

thanks for this. i read the freevo/nvidia article and wasn't sure to be honest - though it did seem relevant that it was possible to generate a proper 1:1 mapping.

however the articles detailing the fieldparity options for direct frame buffering did seem to imply that they were getting smooth motion via an interlaced video output when it was correct, and juddery when it wasnt.

sorry if this is not relevant directly to this forum but how do i post / contact the mplayer / mplayer g2 teams? i don't want to annoy people (and apologise if i am) - so would like to know the most acceptable way of doing this?

again 100 apologies for being such a software/xbmc newbie - i used to work with interlaced digital video (uncompressed) a lot in my previous job - so am happy with the broadcast digital video aspects up until mpeg2 encoding, and also with interlaced displays etc. i'm not an expert with the software stuff - and so at the mercy of other people helping!

thanks again.

[Gamester17]

how do i post / contact the mplayer / mplayer g2 teams?   would like to know the most acceptable way of doing this?

they don't use forums like we do, the mplayer project uses mailing_lists instead so you have to subcribe to it first then send them a mail

[owain_thomas]

i'm a bit confused by this problem. i have a dvt-t recorder on my pc which i regularly use to record programmes. when i come to watch them on xbmc (via 480p over component leads), some are deinterlaced perfectly and look broadcast quality and others have horrible combing artefacts around any areas of movement. is this difference caused by xbmc or by the recording itself?

owain

[gryphon]

it isnt either, it is because of the stream. some shows are progressive, which means they arent interlaced at all, so when you watch them, you simply see what you would normally see though the television. but some other streams you have recorded will be interlaced and as xbmc has problems with interlacing, it gives you the artifacts that you can see.

[owain_thomas]

cheers for the reply, this seems to happen mid programme on some of the things i record, do broadcasters change things during the actual show some times?

example: watching a football highlights programme, the live action has awful interlacing artefacts, on some of the montages between matches (where they use actual footage from the same match, but add effects to it like slightly posterising the colour or whatever) everything looks great.

another point, the dvb-t software i have (nebula's digitv) has a deinterlacing option, when i watch on my pc monitor the whole programme is perfect.  is this somehow detecting that the different parts are not all interlaced and applying the filter to only the ones which are?

cheers
owain

[gryphon]

yes, that is very common, the studio and live match will be recorded with different equipment, so you can see it shifting mid-show, yes.

and yes, with a deinterlace filter, as far as you can see, it is the same but without the interlace artifacts

however, the way it works is that it blends to two fields together, so you get a slightly blurred version of the original image. sometimes, you will have a ghosting effect too which follows any high motion sequences. xbmc has this filter to get rid of interlace artifacts, but i find that only does it create a blurred version, but it can affect video which has already been deinterlaced and make it very blocky and unwatchable.

the point of this thread isnt that interlaced video can't be veiwed without interlace artifacts, because with the filter, it can. the point is, it shouldnt have to, as televisions are designed to show interlaced video, which is why you dont see it when watching television. but xbmc uses mplayer and mplayer "works with deinterlaced video internally" which means it doesnt treat it as interlaced video, and as such, it shows with extra artifacts on the tv.

it seems like a pointless exercise deinterlacing an interlaced video twice for us to be able to watch a video which should just output natively interlaced in the first place.

but as has already been pointed out, this is because of the way mplayer works so there isnt anything the xbmc team can do.

[sneals]

got a bit further with this...

bought an xbox - installed xbmc and xbmp latest builds i could find. both are very cool - amazing accomplishments. being able to play my mp3s, and mpeg1,2,4 video over my home network to my downstairs tv is fab. however correctly encoded mpeg2 interlaced material is a bit of a disappointment.

however i have also played with the xbox native dvd player.

1. the xbox standard dvd player doesn't seem to properly replay interlaced video as i had been led to believe. comparing video sourced dvds (625/50i aka 576/50i) replayed on a standard dvd player and the xbox it is clear that there is some pretty nasty processing taking place in the xbox, smearing the motion between fields, and reducing the nice smooth "video-look" motion.

2. the observation about footy matches is almost certainly an editing issue. in the uk it is universal for the live matches to be shown as 576/50i with full interlaced video motion (i.e. motion between fields), but match of the day and other bbc one shows routinely grade and "film-effect" highlights etc. to convert the 576/50i material to 576/25p removing the motion between fields, creating one frame (like film). in other words although the highlights are broadcast as interlaced video they contain no motion between the fields - so look a bit progressive, just like film. this means there is no need for de-interlacing filters on this stuff - so the motion will appear "smooth" albeit at half the field-rate of interlaced normal video.

dvb-t and dvb-s transmissions, in the uk at least, are permanently broadcast as 576/50i with no transmissions explicitly as 25p, and no mode change in the transmitted stream afaik (there is no signalling in the bbc system to allow for this?).

doing a bit of digging on a couple of xbox linux sites it is becoming clear that the connexant chip being used for tv video output on most (but not all?) xboxes has all sorts of filtering options for luma and chroma, including interline interlace flicker reduction. these can all be switched off. if this is done, and if an output resolution is chosen that is 1:1 mapped to a 576 or 480 resolution, and no scaling implemented, then in theory the interlaced signal should survive?

i suspect that there is possibly scaling, flicker reduction, etc. being implemented both by the mplayer bit of xbmc and by the tv output/gfx chipset in use in the xbox?

[sneals]

another point, the dvb-t software i have (nebula's digitv) has a deinterlacing option, when i watch on my pc monitor the whole programme is perfect.  is this somehow detecting that the different parts are not all interlaced and applying the filter to only the ones which are?

cheers
owain

important thing to watch out for with de-interlacing is how the de-interlaced progressive frame rate compares to the interlaced source material field rate.

there are two standard options for field / frame rate conversion, but they require quite different amounts of processing...

1. the 50/60hz interlaced material is converted to 25/30hz progressive material. this requires that any motion between the two fields is "hidden" - either by blending fields, dropping one of the fields, or other methods - effectively the two fields are merged to create a single frame, and efforts are made to hide the "combing" effects.  this is easier to implement in software, and requires less processing. it works really well on film-sourced material (where there is no motion between fields - and thus no combing artefacts to hide) however the motion portrayal for video sourced material is effectively halved - making it seem less fluid - and look the same as film sourced material (and video material flickered to look like film).

2. the 50/60hz interlaced material is converted to 50/60hz progressive material. this requires a full frame to be interpolated for each field, creating a sequence with the same frame rate as the interlaced field rate.  the motion portrayal is the same as the interlaced source material, with no loss of fluidity, but as you are generating twice as many frames as option (1) it requires significantly more processing power.

option 2 offers no real benefit for film-sourced material carried via interlaced transmission, but massively improves interlaced video source material. as many de-interlacing algorithms are produced for dvd replay, and a large chunk of dvds contain mainly film-sourced material, the impetus for producing good fluid de-interlaced results from video material is less pressing...

some pc based de-interlacing algorithms (i think the moonlight elecard pack popular for hdtv decoding on pcs - 1080i interlaced video is a common hd standard) offer both options 1 and 2 - with 2 requiring more processing power, but providing a far smoother result...

(nb this ignores the requirements for inverse-telecine 3:2 pulldown removal that works well to convert 24hz film carried by a 60hz interlaced system back to 24hz progressive by removing the redundant field, and creating a 2:2 sequence)

[gdhgdh]

does this 'holy grail' appear to be any closer now that the hardware video format conversion of yv12 to yuy2 is now working?

i was hoping things would just 'magically work' in more recent cvs builds, but it isn't so :( pal dvb recordings are still being shown at 25 frames/sec and looking very jerky.

cheers,
gavin.

[Butcher]

no, it requires mplayer to support separate fields. there's no need to try and work around the chipset to get interlaced output - the xbox supports rendering each field separately. however since we recieve a progressive stream from mplayer it's not possible to actually do that.

[gdhgdh]

ok, thanks for the info.

given that the previous request made to the mplayer mailing lists fell pretty much on deaf ears[1], could you as an xbmc devel possibly chime in with a request, given you're already comfortable with the codebase?

otherwise i'm likely to be seen as just another 'whinging user' (i'm a sysadmin at work so i know all about that...)

cheers,
gavin.
[1] http://mplayerhq.hu/pipermail/mplayer-us...42956.html