Messages

1

SFML projects / Re: VideoStreamer - .NET Video Player

« on: August 14, 2013, 10:59:01 pm »

I would love to know what is MS specific at the higher levels. The initial release contained MS specific code with C++/CLI code, but that has since been removed.

It's C#/.NET. They invented it. Maybe just prejudice. And there's MONO. Doesn't matter.

Yes this should be changed, if I ever get back around to working on this code I will do that.

Done.

Well the reason a new DataFrame is created on every GetNextDataFrame is because in the C# code the frames are put in a queue and then read back when they are needed.

What I'm planning to do is to have a pool queue of preallocated DataFrames which are then used to decode, taken from this queue and pushed at the end of the processing queue from where they are consumed and pushed back at the end of the pool queue. So it's going to be just moving some pointers around, not creating a new DataFrame every time GetNextDataFrame gets called. Shouldn't be to hard to implement in C#, either. And using tbb::concurrent_bounded_queue the threading overhead is marginal.

Also if you plan on just using this for C++ you should take a look at Ceylo's sfeMovie Project(linked in first post) as part of my video player is implemented just in C#.

Exactly this was my first start - but it simply does much more than I need - gimme a frame, next frame please etc. - so I stumbled upon your two classes which provide exactly what I need. So Thank you for their existence.

2

SFML projects / Re: VideoStreamer - .NET Video Player

« on: August 14, 2013, 07:15:27 pm »

After searching for a SFML based ffmpeg wrapper I found your code and liked it despite it being C# and M$ dependend in the higher levels. What I'm going to do is to wrap it up in C++ and use it as a base for my own project which involves playing a number - up to 16 - video streams in parallel so performance will be an issue.

After browsing through the implementation of the VideoStream and DataFrame I found some places where there's some space for optimizations.

First I'd suggest not to do the copying "by hand" and byte by byte in the constructors of DataFrame. A simply memcpy does the job perfectly in less time. Initializing the array would be done using memset().

Second I am thinking about reusing the DataFrame in GetNextDataFrame() by passing it as a parameter - GetNextDataFrame(DataFrame*) - so there's no need to do the allocate - deallocate - 2step all the time. One could use some sort of a ring buffer and avoid trashing the heap to much over time. Maybe making the AVPacket used in GetNextDataFrame a class member and reusing it would go in the same direction.

Keep up the good work. I'm going to post my changes after testing and cleaning them up.