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.
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).
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.
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.
:bump:
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.
4.2.2 mpeg2 - XBMC Community Forum::
XBMC for Xbox - Help and Support. 0. 2005-04-18 00:08. Pal 50field .mpeg2 and .vob stutter? Joergen. XBMC Feature Suggestions discussion forum
http://xbmc.org/forum/showthread.php?t=372HOME |
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!
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 :sniffle:
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.
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
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. :no:
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.
i put vf=tfields=2 into the mplayer.conf and while it eliminates the reversed field-order problem it still leaves the jumps and bumps, either where it would normally switch field-order or perhaps its another problem causing it to hitch and then switch field-order.
but bob gets you closer to the smooth motion, though at the expense of the video quality. but, that filter is really bad for progressive lower-res material like xvid movies, so its best left off.
i found a post on the mplayer mailing list by somebody on the same track http://www1.mplayerhq.hu/piperma....56.html (http://www1.mplayerhq.hu/pipermail/mplayer-users/2004-february/042956.html)
response: http://www1.mplayerhq.hu/piperma....66.html (http://www1.mplayerhq.hu/pipermail/mplayer-users/2004-february/042966.html)
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:
http://usuarios.arsystel.com/josemuk/xbmc/50fps.gif
- hardware overlays filter isn't as smooth as pixel shader.
 Red Hat's Rough Recovery From CFO Exit
 Windows Live Finds a New, Pre-installed Home
|
Pal 50field .mpeg2 and .vob stutter?