whitefrt wrote:I sniffed out the conversation between MediaCenter7 and the X360, they are using the RTP protocol which is more flexible in terms of mix and matching formats - the actual data being sent is mpeg4-AVC (x264) / wma-pro so no big surprises there, the raw data even contains:
"#..x264 - core 68 r1183M f21daff - H.264/MPEG-4 AVC codec - Copyleft 2003-2009 -
http://www.videolan.org/x264.html - options: cabac=1 ref=5 deblock=1:-3:-3 analyse=0x3:0x113 me=umh subme=9 psy_rd=0.9:0.8 mixed_ref=1 me_range=32 chroma_me=1 trellis=2 8x8dct=1 cqm=0 deadzone=21,11 chroma_qp_offset=-4 threads=6 nr=0 decimate=1 mbaff=0 bframes=3 b_pyramid=1 b_adapt=1 b_bias=0 direct=3 wpredb=1 keyint=250 keyint_min=25 scenecut=40 rc=2pass bitrate=6551 ratetol=1.0 qcomp=0.60 qpmin=10 qpmax=51 qpstep=4 cplxblur=20.0 qblur=0.5 vbv_maxrate=50000 vbv_bufsize=50000 ip_ratio=1.40 pb_ratio=1.30 aq=1:1.00"
The exact involvement of VLC is yet unknown to me (perhaps the DivX AVC implementation is using the opensource videolan x264 encoder) which is odd as I have verified that the DivX encoder indeed passes data to a second hardware accelerated encoder when applicable.
Actual response from MC7 to RTP's SETUP command packet requested by the X360 is:
audio:
m=audio 0 RTP/AVPF 96
b=AS:129
a=rtpmap:96 wma/1000/2
a=fmtp:96 version=STD;profile=2;samplesize=16;samplerate=48000;blocksize=2731;bitrate=128016;preroll=1000;config=008800000f0000000000
a=predecbufsize.dlna.org:16002
a=rtcp-fb:96 nack
a=trans-rate-adapt.dlna.org:1
a=lang:en-us
a=mid:1
a=control:audio
video:
m=video 0 RTP/AVPF 97
b=AS:7957
a=rtpmap:97 x-wmf-pf/1000
a=fmtp:97 video/vnd.avi;codec="H264";config=73646976-0000-0010-8000-00AA00389B71/0/1/2764800/F72A76A0-EB0A-11D0-ACE4-0000C0CC16BA/00000000000000000000000000000000000000000000000000000000000000009969790000000000a45d0600000000000000000000000000100000000900000000000000000000002800000000050000d0020000010000004832363400302a0000000000000000000000000000000000;extsys=C6BD9450-867F-4907-83A3-C77921B733AD/2
a=predecbufsize.dlna.org:2983833
a=rtcp-fb:97 nack
a=trans-rate-adapt.dlna.org:1
a=lang:en-us
a=mid:2
a=control:video
Again same as above, the good news however is that I think I have a solution and hopefully my implementation will work, it's going to be a C++ external DLL (or an executable that will send PMS data via pipes) as java is not suitable for handling media foundation interface objects natively (and I'm a C++ coder, not a big java fan..) - hopefully integration with PMS won't be too painful. Will hopefully have something soon as free time permits
wow , now hang on ,think about this for a minute, your telling us with the above that right now the generic xbox360 when sent the right handshake will negotiate and stream AND actually decode and play an avc/wma-pro/rtp file from the multicast pipe ?
and not only that its playing SMOOTHLY ref=
5 , (iv Never managed to smoothly stream or directly usb pluged in and play anything .mp4 with a ref greater than 3) and vbv_maxrate=50000 vbv_bufsize=50000 as in the maxrate is way above even for mearly peaks/spikes of the recomended the 10Mbit/s for 1080P (again not smooth mp4 above 10Mbit/s)
the use of x264 or libx264 and even vlc doesnt suprise me as the divx avc guy on doom openly admits they used and even encuraged people to use x264 to produce upto level4.0 high profile (hence the 50000 limit i assume) for use with their divXAVC the and theres some howto's on their site somewere, cant find them right now though, il find them later if its important.
to be sure your wireshark data is right, whats the actual mediainfo data for the actual mkv file your asking it to/its transcoding ?, does that match the x264 - core 68 r1183M data above, and so they are just using some non open wma-pro encoder (ffmpeg/vlc etc dont have one to use, so they must be using some MS closed or other custom closed code) and remuxing the raw x264 and that wma-pro into an RTP container with a wma-pro encoder patched vlc perhaps, then doing the win7 magic perhaps, but as i said ref5 doesnt play for me inside mp4 so how come it does when they send it ? , no new updated codec/decoder firmware is installed on the 360 is it.
your proposed c++ wapper ,can you make it so you can pipe lets say vlc (yeah i know shagrath LOL) to your dll input, do your thing then send the output to however shagrath sets up the multicast pipe ?
perhaps we need a second user activated multicast pipe we can activate adn have ps3ms just idle on it until it gets real input if we set the option inside somewere to make this experimentation easier ?
or better from my /most peoples non programmer pov, you could do the simple thing seeing as your a programmer, and just write your dll and also wrap it into a simple and quick rebol script wrapper, and have that rebol script do the network piping (and many other things too, GUI if you like etc) at both ends see
http://www.rebol.org/view-script.r?scri ... lay-avi-.r and
http://www.rebol.org/view-script.r?script=eztwain.rfor how it seems simple to wrap dlls etc and then send simple commands through ip , if only the devs picked something actually useful (like who actually needs or uses MS-CRAM Microsoft Video 1) and upto date to wrap (ffmpeg.x264, your dll etc
) and make available with actual tryed and tested working script examples etc.
edit: wrong url its right now,read the whole
http://musiclessonz.com/rebol_tutorial. ... ction-17.1 and do the examples
download
http://www.rebol.com/download-view.html for your OS and run those scripts etc
or even try the newer R3
http://www.rebol.com/r3/docs/concepts/extensions.htmlbut whatever works for the general use, remember not everyone is using win7 so if you can produce a generic fifo box option that takes input and outputs ps3ms data that works for xp and even linux/mac with a little more thought all the better
the main problem seems to be if your dll works OC is how do you actually ENCODE wma-pro on the fly and pipe it to your input ?
the current x264 takes lot of video input now, ffmpeg takes wma-pro and can decode it but nothing OSS encodes wma-pro right now so that might be a real problem until someone re's the codec and writes the encoder for it!!
i should have picked it up earlier, that url is the home for the constantly updated x264 on freenode #x264
irc://irc.freenode.net/x264 not the vlc wrapped libx264 code etc, so vlc probably isnt used,but thats good , it could mean they are probably keeping up to speed with the current x264 codebase patches etc and perhaps patching their codebase accordingly. or its just the data from the file you asked it to process which is far more likely OC.
