I think you can use MPF on WP7 so you can maintain one sourceCode (I tried and I think its work)

Jan 21, 2014 at 8:30 AM
If you download sourceCode from playerframwork. You can see there's actually a WP7 version. But this version would not include in Microsoft.PlayerFramework.vsix.
So I download it and compiled myself.

Then I move code from WP8 project(which you use PlayerFramework already) to WP7 project. So there're two project need to be modify.
  1. Add DispatcherExtensions.cs to SM.Media.Platform.WP7
  2. Edit DispatcherExtensions.cs. Modify Line 69 From Task.FromResult(action()); to TaskEx.FromResult(action());
  3. Copy StreamingMediaPlugin.cs and MediaElementWrapper.cs from SM.Media.MediaPlayer.WP8 to SM.Media.MediaPlayer.WP7 (overwrite exist StreamingMediaPlugin.cs)
  4. Edit MediaElementWrapper. Comment Line 734 & 738 , because WP7 not support StopWatch
  5. Edit MediaElementWrapper. Modify Line 787 from Task.Run to Task.Factory.StartNew
then its done. Hopefully this would help.
Jan 22, 2014 at 12:50 AM
Edited Jan 22, 2014 at 4:19 AM
I've thought about it. The main hang up has been, as you point out, that there is no binary version available. The download would need to either supply an unofficial binary or tell folks to go build their own. For the people that track the Git version, there is a bit more flexibility, but the .zip download should "just work" as much as possible (i.e. "double click the .sln and 'Build Solution'"). Then again, the current phonesm-20130921 [*] already requires one to go download the SMF...

Any thoughts?

[*] Yes, yes, I know. There have been a zillion changes and bug fixes since then. I've been meaning to update it since December...
Jan 22, 2014 at 7:15 AM
I think SMF is the "past" and for me it confuses me at the begining of what difference between SMF & MMF.
Alough there's no "offcial" MMF for WP7, still MMF is a open source project. Which meaing everyone can download and compile.
The official release should be the same sourceCode theoretically.

So... I think you can provided a self compiled package of MMF.
Tell every if them like they can download and compiled himself or use the package you provid.
Also can document how to compile MMF them-self.

Here's smooth streaming client sdk for windows phone which is needed when compile MMF for WP.

And for the current WP7 version that using SMF, you can set a "tag" then release.
And then "moved on" to using MMF :P
Jan 23, 2014 at 3:04 AM
Edited Jan 23, 2014 at 3:05 AM
It's more the consequences than the "how" that concern me.

Right now, everything other than SMF is handled by NuGet. Switching WP7 to Player Framework means that there will be one Player Framework for WP8 (and hopefully--when I get around to it--for WIn8.1), one set of binaries I compile, and a note for folks to compile it themselves when compiling from source. I'm thinking this is probably the right thing to do, but it does sound a bit messy. I've had enough fun in the past dealing with importing Project A and Project B into something I'm working on, and finding that they both import incompatible versions of Project C (leading to dents in the wall with bloody clumps of scalp and hair and a curious resemblance to my forehead).

The projects in the Git source and the phonesm-* zip files are already different since the former builds PCLs and folks with VS Express can't load those project (unless this has changed recently?) . The Git source includes SM.Media and SM.TsParser as projects, while the ones in the ZIP files include them as binaries, with some manual changes to the .csproj files so that debug builds including debug binaries and release builds include release binaries. This is already more complicated than I like, so I'd prefer to keep any other build gunk as simple as possible.

Meanwhile, background audio appears to be broken, the Win8.1 app may be leaking buffers, and the processing pipeline still needs a bunch of work before it can handle #EXT-X-DISCONTINUITY.
Jan 23, 2014 at 3:32 AM
Wow... this is more complex than I thought.
Well then... forget what I've said.

I will try to use this WP7 Player Framework version myself. And if there's anything new I'll let you know.

And very thanks for your work. This helps me a lot.
Jan 23, 2014 at 6:52 AM
I think I agree with what you were suggesting originally. If the required source code changes really are that simple, then it's probably better to just make the switch. I'm inclined to rename the old WP7 stuff to keep it around. It may eventually suffer some code rot, but it should compile. It's not as if there aren't enough separate project files already, but some folks may have customized SMF-based players and aren't all that enthusiastic about diverting development efforts from WP8 to WP7.

I'll update my Player Framework source tree to what matches the current release (v1.3.2), update the Player Framework's NuGet packages where needed (last I checked, the Player Framework's WP7 projects were using older copies of Microsoft.Bcl, Microsoft.Bcl.Async, and Microsoft.Bcl.Build than phonesm), and use the resulting binaries for the next set of phonesm-* ZIP files. The folks building for WP7 from Git will have to copy the binaries from a phonesm-.*.zip or build their own.
Jan 23, 2014 at 8:31 PM
If you are going to use Player Framework with phonesm, you may want to take a look at this fork. There are no code changes, but there were enough changes in project files that it seemed prudent to save the changes somewhere.

I haven't really tested anything other than running the short test video once in whichever emulator instance popped up when I hit F5.
Jan 27, 2014 at 12:46 AM
Edited Jan 27, 2014 at 1:02 AM
OK~ I'll try this fork. Thank you.

by the way. Player Framework is much much faster than SMF when initializing Media Player.

Also Player Framework plays HLS streaming very fast and SMF takes about 30sec to start play. But I don't know if that is because I use a newer codebase of your library when I try use Player Framework.
Jan 27, 2014 at 1:26 AM
I have one questions about your comment on the fork of Player Framework.

Add a Microsoft.Media.ISO.Legacy PCL since the Microsoft.Media.ISO PCL does not support WP7.

But Microsoft.Media.ISO is target above WP7(the lowest WP platform) in master branch. I think this supposed support WP7.
Why you have to add another project for this?
Jan 27, 2014 at 6:25 AM
Microsft.Media.ISO.csproj specifies Profile136. I'm pretty sure that profile requires Windows Phone 8.

If you bring up the target framework dialog for the Microsoft.Media.ISO project in Visual Studio, what does it show?

I'm not sure where to find an official list, but there is an unofficial table here: http://blog.stephencleary.com/2012/05/framework-profiles-in-net.html

PCL projects that include WP7 support will not load in VS2013, so that might be why they set it up that way. At any rate, that is the reason I duplicated the projects in phonesm (for VS2013 support--which is required for targeting Win8.1--and for VS2012 support--which is required for targeting WP7).

As for the startup times, yes, the newer code should be much better in this regard. Seeks should also be more responsive. For streams that may need some tuning (e.g., very low bandwidth streams), the logic that determines how long to stay in "buffering" mode and the code that decided when to enable and disable network reads has been split out in to a "BufferingPolicy" class that can be easily customized (either by changing the parameters or by supplying a custom implementation of IBufferingPolicy).
Jan 27, 2014 at 7:11 AM
Here's my image of target framework of Microsft.Media.ISO
I open it with VS2012 Ultimate

I am not understand because you can see Microsoft.WP7.PlayerFramework.SL.Test also reference this project in master branch.
Jan 27, 2014 at 7:26 AM
What profile do you see in your .csproj file? playerframework's Microsoft.Media.ISO.csproj has been Profile136 since mid-September (eb54ba916f6a). Like so:
Jan 27, 2014 at 7:46 AM
Mine is

OK... I see.. I think I've downloaded a ancient version. Sorry, my mistake.

My sourceCode fileName is "playerframework-0668c18b4e79c54a235061c598765d1c97949e10.zip".