DJ,
Thanks for your insights. I too am having fun and games trying to stream some ts video transcoded as an mpg that graphedit can render. The reason I want to render it in graphedit is because I want to stream it to a media server (on the same PC), which requires the feed to be compatible with graphedit.
It's always fun and games getting started. I think what you are trying to do is make the stream Direct Show compatible with stock codecs. While the stock codecs thing unfortunately, may be an issue. For example: Direct Show does not fully support MPEG-2 PS it's missing a decoder out of the set of codecs. I have found that I prefer WinDVD after going round and round with both free and paid programs. Windows or WinDVD does not support MPEG-2 TS at all and I have found it rather difficult to find a real good one that works in the HD forms. After trying bunches of them, I finally ended up with DVBportal HDTVpump and works real well with Graph Edit as does WinDVD's MPEG-2 decoder as a set. Sound is handled by WinDVD as well (ac3, DTS, MPGa). It will also work with DivX and XviD if you look for and install Gabest's avi2ac3filter.ax
I have found I can transcode the video to file and render the file in graphedit - but I can't get a stream to work for me. This may be due to my complete lack of networking skills!
I am trying to stream via
http://localhost:8080. I can render the stream if I encapsulate as an mpeg-ts, but it won't if I encapsulate as an mpeg-ps. Like mentioned previously in this forum, I can get video but no audio if encapsulated as raw.
The MPEG-PS format was not designed to be streamed but, the MPEG-TS format was and to make this compatible you will need to do what I mentioned above. Raw video and or audio just takes up to much space and power in most cases.
What I am wondering is whether I am better off using mmsh or udp streaming, and if so what sort of URL do I stream it from to. I see other URL's on the web (that the media server will stream) as mms://... If I stream (using ts encapsulation that works for http) to mmsh://localhost:8080, graphedit won't render the stream. If I try to pick up mms://localhost:8080, graphedit crashes.
MMS as I recall was designed by Microsoft to stream files across the Internet, because of the speed restrictions of the Internet a lot of attention needs to be paid to resolution and bit rate so as to stay within the bandwidth limitations, thus there is also some quality considerations in doing this on many non commercial connections. Hopefully, this will become easier in the next few years.
Considering appear to want to do this locally UDP should be fine.
As I said at the start, my ignorance of protocols and URLs is probably not helping, but I've looked around this and other forums to learn more (including the "VideoLAN Streaming Howto") - but I've not found anything that's advancing my understanding. So any clarification would be gratefully appreciated.
The most difficult thing in getting started is realizing how most of the formats and containers came into existence. Who created them and for what purpose. What formats work with (play nice) others and which ones don't. Then there is always, what VLC is supporting at the moment and what is intended and what isn't finished or broke.
The MPEG-TS container using MPGv and MPGa or MP3 is very safe and reasonably stable. This should work for both local playback and streaming. I have also found that if the original source is MPEG, often times transcoding is not necessary, just choosing the container works, but you may need to play with audio when streaming.
Now in case you haven't noticed there is no real easy answer to your questions, I have just tried to establish some guide lines that should help you accomplish what you say you are trying to do and do it with some quality.
Well, maybe .asf!
I am routing for H.264 with AAC sound in a MP4 or MOV container for streaming in the near future. But there are still some hurtles to overcome.
Now it's still possible I missed the point of your media server. If you intend to stream over the Internet.