haunted by "invalid dts"

[linux.chips]

Hi...i am new here, long time vlc user

i have several streaming servers over a private lan/wan networks. and i was struggling with an error, the "x264 [warning]: invalid DTS: PTS is less than DTS" is causing me much much trouble. each time i use vlc in any project i get this message at least few times.
i was wondering if this dts/pts discontinuity are so common or am i doing some thing incorrect?. i have this error when streaming a perfectly playable files, perfectly playable video streams from dvblast, and even from capture cards (intensity pro).
in all cases where i get the mentioned error (it says "warning" but i prefer to call it an error, due to the devastating results) the video is no more watchable, it gets very messy with trails of moving objects and green artifacts all over the screen.
i have searched this form and googled. to no avail. there are not any work around.
is there any way this could be fixed (i.e. in vlc). as i understood, vlc is dropping the frame with the invalid dts, causing x264 to loose important data to generate the next frame.

currently i have three scenarios/services:
1- vlc streaming a playlist of files, some files works good and some don't. the solution: trash the bad files. not really what i want, i tried transcoding them to different formats before x264, but that did not help.
2- i have a linux box (not built by me, it is a DVB to ip gateway) that uses dvblast to stream the content from satellite channels. that one drove me crazy, as the manufacturer of the dvb-ip gateway told me the problem is from the content provider (i.e. the channels i am viewing). the solution was messy and ugly and far far from perfect. i knew that multicat rebuild the stream clock, so i gave it a shot, simply restream with multicat (dvblast --> multicat --> vlc --> users). i was happy for like 5 min, and the error is on my tail again. i ended up restarting multicat each 5 min, with a stutter on each restart.
3- vlc streaming live content from capture card (a blackmagic intensity pro). that i did not find a fix for it yet. i am capturing from an analog device, isn't the clock generated inside the card or something?! so the problem this time is from my end. is it?! i have found this post with similar problem viewtopic.php?f=13&t=98889&p=350953&sid ... 44#p350953

can't vlc just insert the badly timed frames at an arbitrary time?? why it have to drop them! (i think it is the x264 encoder who is responsible for this, is it?)
is the source files really having bad time stamps, or vlc is just miss reading them??

i am willing to help fixing it, just need to know where the problem is (where to start reading/coding)... if any one has any work around or some thing, i ll appreciate it.
currently i am using vlc 2.0.2, on fedora 17 64bit. so far i have tried pre vlc 1, vlc 1.1 and vlc 2, on ubuntu, fedora, debian, centos, all with the same results.

[linux.chips]

i forgot to mention that the problem also exists in windows. i tried file streaming and restreaming/transcoding the dvblast output. with exactly the same outcome.