-
Notifications
You must be signed in to change notification settings - Fork 11
Use of GCC-4.8 #4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
This commit fixes playback on the Windows 8 and 10 platforms. The behaviour of these platforms differs from the development (Windows 7) platform in that if the ByteStream supplied to the SourceReader does not have the MFBYTESTREAM_IS_SEEKABLE capability the stream recognition will fail without even reading any data. On Windows 7 the stream recognition phase executed seeks regardless of the capability setting. Highlights ---------- 1. Enable the MFBYTESTREAM_IS_SEEKABLE capability in the OpenHomeByteStream. This allows stream recognition to succeed. It does not enable stream seeking from a control point. 2. When OpenHomeByteStream receives a seek request outside of the initial recognition cache, during recognition, it updates iStreamPos to the requested position and passes the seek. The subsequent read request will execute an out of band read of the requested size from the 'seeked' location storing it at the start of the existing recognition cache. The required data will then be returned from the updated cache. NB. The out of bound read requires the IWriter interface be implemented. 3. Standardise on TBOOL to avoid passing pointers to TBOOL and casting to BOOL. I suspect this was causing some subtle data corruption. 4. In Process() check for stream start/end exception after all calls to ReadSample() so that can be passed back to the CodecController in a timely manner. Also avoid calling FlushPCM() on stream exceptions as it was seen to cause crashes.
|
I don't think changing compiler to Thing worth noticing is that As for suggesting |
|
From the sudo perspective, sudo is used in earlier commands so the presumption is that the current user is unprivileged. The make install will then fail unless prefixed with sudo. I guess I'm leaning towards consistency rather than insistence on sudo. If sudo is undesired, the docs should suggest that the user su - to root first, before apt-get, make install, etc. |
|
For the Makefile, the issue is that it doesn't work on anything except 4.8. Many systems have different versions available, but not defaulted. Global settings should not be demanded in order to make an exception work. The exception (ohplayer, in this case) should have a requirement on 4.8. I agree I've probably got CC and CXX incorrect. I'll update tomorrow evening and see how it goes. If need be I'll try and resubmit a patch, but I still feel strongly that the Makefile should be requiring 4.8, rather than messing with system-wide globals |
|
Yeah, it should either have sudo throughout or not at all. Regarding gcc-4.8, it would be great if things could be fixed to compile in 4.9/5.0 without breaking back compatibility. |
|
In my opinion burying |
|
I have some time to work on this next week, so will try to find a good approach, but considering my other two PRs haven't made it through yet I don't know how long it will take. Especially #5 will help to maintain the system. |
Use GCC 4.8 in the Makefile rather than editing global system settings.
Use sudo to execute make install
Tested with Ubuntu 15.10, but not Raspbian.