2012-10-03, 15:14
Thanks Fritsch!
2012-10-03, 17:25
Will the audio-quality suffer from the transcoding to ac3?
Sorry for asking, I'm a soundnoob and just at the beginning of my soundadventure
Sorry for asking, I'm a soundnoob and just at the beginning of my soundadventure
2012-10-03, 17:35
@cirkator:
Yes it does - but if you hear it is another question. This answer is retorical: As you convert lossless into something that has a lower bandwidth. I would compare it like "flac" to 320 mp3. And of course no more 8 channels only 6 left.
May the audiophile people crucify me now :-). I only have 5.1 setup here at home - so no need for 8 channels anyways. Most of the time the "core" of DTS-HD is good enough. There are fewer TrueHD/VC1 blurays out there. This is at least my feeling as a Lovefilm customer.
Yes it does - but if you hear it is another question. This answer is retorical: As you convert lossless into something that has a lower bandwidth. I would compare it like "flac" to 320 mp3. And of course no more 8 channels only 6 left.
May the audiophile people crucify me now :-). I only have 5.1 setup here at home - so no need for 8 channels anyways. Most of the time the "core" of DTS-HD is good enough. There are fewer TrueHD/VC1 blurays out there. This is at least my feeling as a Lovefilm customer.
2012-10-03, 18:09
New package available: 2:12.0~git20121003.1134-e9388b8
- upstream changes september + selected fixes
Notes:
- After upgrade you might have to set your audio device again, there were changes in the device enumeration code.
- Xdvr users must recompile their addon, as the API version has been upped
- There might be a bug in AE that causes framerate to be very low after playing many videos with certain audio types.
If you hit it, please let us know which files you were playing before, specially which audio codec
- upstream changes september + selected fixes
Notes:
- After upgrade you might have to set your audio device again, there were changes in the device enumeration code.
- Xdvr users must recompile their addon, as the API version has been upped
- There might be a bug in AE that causes framerate to be very low after playing many videos with certain audio types.
If you hit it, please let us know which files you were playing before, specially which audio codec
2012-10-03, 18:28
Hi, I'm using the xvba-testing ppa listed in OP, I'm wondering would it be possible to use xvba for SD live-tv (mpg2) ?
Problem is, playback of SD streams is somewhat stuttering, not smooth, looks like its dropping frames, but it's not, and when you go to menu while playing SD, menu is slower, and the video is sluggish and much worse than fullscreen all this with less than 40% cpu use. Doing the same with playback of HD streams live-tv (x264) is perfect smooth.
Problem is, playback of SD streams is somewhat stuttering, not smooth, looks like its dropping frames, but it's not, and when you go to menu while playing SD, menu is slower, and the video is sluggish and much worse than fullscreen all this with less than 40% cpu use. Doing the same with playback of HD streams live-tv (x264) is perfect smooth.
2012-10-03, 18:43
(2012-10-03, 15:06)fritsch Wrote: @tomtomme:
I hope you did not forget to supply --enable-xvba and put the amdxvba.h into /usr/include/amd directory.
no i did not forget
and it compiled succesfully. And it also seems to install, but then complains at startup: Code:
bv3xbmc:/opt/xbmc-master/xbmc # make install
Copying XBMC binary to /usr/local/lib64/xbmc/
You can run XBMC with the command 'xbmc'
Copying support and legal files...
Done!
Copying system files to /usr/local/share/xbmc
bv3xbmc:/opt/xbmc-master/xbmc # xbmc
** (process:11150): WARNING **: Trying to register gtype 'GMountMountFlags' as enum when in fact it is of type 'GFlags'
** (process:11150): WARNING **: Trying to register gtype 'GDriveStartFlags' as enum when in fact it is of type 'GFlags'
** (process:11150): WARNING **: Trying to register gtype 'GSocketMsgFlags' as enum when in fact it is of type 'GFlags'
Unable to find path to XBMC data files!I do not know whats wrong.
sh /usr/local/bin/xbmc
gives the same error...
2012-10-03, 19:02
@KRA77:
Not supported by AMD on linux. If they support it, we will implement it. See als the reply I gave Robotica this evening.
@tomtomme:
XBMC_HOME=/usr/local/share/xbmc /usr/local/bin/xbmc
Try something like this. You did not specify a correct --prefix on this brilliant Suse box :-)
Not supported by AMD on linux. If they support it, we will implement it. See als the reply I gave Robotica this evening.
@tomtomme:
XBMC_HOME=/usr/local/share/xbmc /usr/local/bin/xbmc
Try something like this. You did not specify a correct --prefix on this brilliant Suse box :-)
2012-10-03, 19:19
fritsch, thanks for reply, I take it might happen sometime in the future then.
I have another question if you don't mind, you ppa xbmc-xvba-testing, is the same as master xbmc source with added xvba support ? So the version you release today is same as official xbmc as of today ?
I have another question if you don't mind, you ppa xbmc-xvba-testing, is the same as master xbmc source with added xvba support ? So the version you release today is same as official xbmc as of today ?
2012-10-03, 19:40
@KRA77:
Basically yes - but... Normally xbmc-xvba-testing is what you get from xbmc master + all the work fernetmenta has done, like dropsdl, xrandr, player buffering, xvba, vdpau rework. That is the normal situation.
But as there is currently a new "merge window" opened we decided to take the version from end of September, a pretty stable version with some patches I cherry-picked and make a really stable release out of it.
Before a package can go to xbmc-xvba it is first build for xbmc-xvba-testing. wsnipex and me are testing it and if we find it better (>=) than current it is going into xbmc-xvba repo.
xbmc-xvba-testing is bleeding edge and is likely to break, nothing for non supportive/debugging users, nothing for every day work or for the girl friend at home :-)
So to get to the point:
During months: xbmc-xvba-testing is bleeding edge. At the end of the month it is used to package and test the new monthly stable.
I park the "end of month results" in my git repo, so that fernetmenta does not have to manage multiple trunks or even maintain a "stable version".
Basically yes - but... Normally xbmc-xvba-testing is what you get from xbmc master + all the work fernetmenta has done, like dropsdl, xrandr, player buffering, xvba, vdpau rework. That is the normal situation.
But as there is currently a new "merge window" opened we decided to take the version from end of September, a pretty stable version with some patches I cherry-picked and make a really stable release out of it.
Before a package can go to xbmc-xvba it is first build for xbmc-xvba-testing. wsnipex and me are testing it and if we find it better (>=) than current it is going into xbmc-xvba repo.
xbmc-xvba-testing is bleeding edge and is likely to break, nothing for non supportive/debugging users, nothing for every day work or for the girl friend at home :-)
So to get to the point:
During months: xbmc-xvba-testing is bleeding edge. At the end of the month it is used to package and test the new monthly stable.
I park the "end of month results" in my git repo, so that fernetmenta does not have to manage multiple trunks or even maintain a "stable version".
2012-10-03, 21:58
Ok, I think I understand a bit more, the reason I ask is because there was a PVR API change a few days ago, and I was wondering if that made it into xvba-testing ppa. Basically to know that the code in your testing ppa is the same as the code in official xbmc nightly. Like the build for today support the same as official xbmc nightly for today.
also, isn't your xvba work gonna be in official Frodo release ?
also, isn't your xvba work gonna be in official Frodo release ?
2012-10-03, 22:26
@KRA77:
Yeah, we pulled in the API change, as you can read in wsnipex anouncement: http://forum.xbmc.org/showthread.php?tid...pid1205370
(Following is my personal opinion, not speaking for our xvba team)
The goal is to get that code in of course. But to be honest - it does not matter that much for me personally. XVBA was a great experience, learning a lot, meeting interesting people and so on. Openelec 2.0 and Openelec next will ship with this code - so it is working really great and a huge userbase has tested xbmc + those patches, no question.
The changes are quite intrusive and when working on a huge codebase (xbmc) there have to be reviews. There have to be PRs in small parts. Some things go fast - others don't, others are ignored :-)
Several coreparts are already on their way (in?) - PRs have been made. Some are untouched, uncommented there since weeks / months.
I hope the best and use the time in between to help doing what was intended: Give the best out of the box experience when using xbmc especially on AMD hardware running linux.
Yeah, we pulled in the API change, as you can read in wsnipex anouncement: http://forum.xbmc.org/showthread.php?tid...pid1205370
(Following is my personal opinion, not speaking for our xvba team)
The goal is to get that code in of course. But to be honest - it does not matter that much for me personally. XVBA was a great experience, learning a lot, meeting interesting people and so on. Openelec 2.0 and Openelec next will ship with this code - so it is working really great and a huge userbase has tested xbmc + those patches, no question.
The changes are quite intrusive and when working on a huge codebase (xbmc) there have to be reviews. There have to be PRs in small parts. Some things go fast - others don't, others are ignored :-)
Several coreparts are already on their way (in?) - PRs have been made. Some are untouched, uncommented there since weeks / months.
I hope the best and use the time in between to help doing what was intended: Give the best out of the box experience when using xbmc especially on AMD hardware running linux.
2012-10-04, 10:48
(2012-10-03, 22:26)fritsch Wrote: @KRA77:
Yeah, we pulled in the API change, as you can read in wsnipex anouncement: http://forum.xbmc.org/showthread.php?tid...pid1205370
(Following is my personal opinion, not speaking for our xvba team)
The goal is to get that code in of course. But to be honest - it does not matter that much for me personally. XVBA was a great experience, learning a lot, meeting interesting people and so on. Openelec 2.0 and Openelec next will ship with this code - so it is working really great and a huge userbase has tested xbmc + those patches, no question.
The changes are quite intrusive and when working on a huge codebase (xbmc) there have to be reviews. There have to be PRs in small parts. Some things go fast - others don't, others are ignored :-)
Several coreparts are already on their way (in?) - PRs have been made. Some are untouched, uncommented there since weeks / months.
I hope the best and use the time in between to help doing what was intended: Give the best out of the box experience when using xbmc especially on AMD hardware running linux.
very well put
+1
2012-10-07, 02:58
pardon my ignorance, I'm not a programmer, and don't completely understand this git stuff.
I notice on https://github.com/wsnipex/xbmc/commits/master the last change was done oct. 3rd, however there was a new release in ppa respository oct 6, is there somewhere else I can follow changelog or is the october 6 build accordning to the github list ?
I notice on https://github.com/wsnipex/xbmc/commits/master the last change was done oct. 3rd, however there was a new release in ppa respository oct 6, is there somewhere else I can follow changelog or is the october 6 build accordning to the github list ?
2012-10-07, 04:30
(2012-10-03, 19:40)fritsch Wrote: So to get to the point:
During months: xbmc-xvba-testing is bleeding edge. At the end of the month it is used to package and test the new monthly stable.
I park the "end of month results" in my git repo, so that fernetmenta does not have to manage multiple trunks or even maintain a "stable version".
ahaa!
good to know!
I always used fernet mentas git to check out the developement. I did not know that you guys have all your own git. I found it however and will now use the "monthly tested" version - many thanks!
