The answer is on the contract that every employee has signed with the company. Whatever number of hours is reflected there should be not only acceptable but what you must expect and rely on to get the job done. Now, taking off my 'union hat'... development is not a production chain where number of hours translates directly in productivity or maybe it does but in such a complex way that the comparison will always be dangerous to be considered for you as project manager.. supplies shortage, unplanned repairs, ... have their analogous in the IT world but it's a game that you cannot win if your problem as it looks refers to most of your team.
What can be done then? There is a fine balance to be kept and a small 'cheat' to play. The planning of the work, following whatever methodology you use (waterfall, agile, ..) must be realistic and with enough definition level so that when things don't work the person taking a task considers himself responsible for the miss. The developer will be responsible but you will still be accountable (I am using the RACI model here). Getting to a level enough of definition may not be easy so, involve the team on achieving it (write specs, contact customer representatives, ...) make them feel IMPORTANT and they will be motivated. The cheat to play is that you must fix a minimun that is slightly higher that what you think can be done. More often that you can imagine, you will see this threshold achieved, sometimes because the person will push, others because you will have underestimated and some others because the team will come out with more efficient solutions...
The size of your company is another important factor. In big companies, where the failure of a project or the loss of an important customer is not relevant. This false conclusion must be conveyed to every employee in the company to avoid that they get accomodated.
About salary, in my life as developer I have had sustantial salary increases and none of them have made me work more or better nor staying in the company. Salary is a short-term motivator in the best case. For this, I consider important that any incentives can be awarded directly linked to direct contributions by individuals and given with a regularity enough so that effect may last from one to the next if both are achieved but if one fails there is the possibility for another not far down the road.
And incentive may not be only referred to money. You must get to know your people to know what they like: training, attending a conference, public recognition, a second screen, extra holidays, ... will be easier for you to provide as companies CFO don't see them in the same way. Given them what they prefer not what you would like to get yourself.
But of course, as several people have already mentioned, if everything else fails after trying for some time, you must know how much effort you can afford, you must redistribute the team to other functions or just fire them and have a better assessment on people responsibility and motivation when hiring. Quite often though this will be difficult to do because the burnt out people will be people who has been on the company for long and hence, is difficult to justify that they are no longer valid.
It is important to take advantage of annual appraisal to stay in touch with your people expectations and motivations. This will require that you have honest and open communication with the team throughout the whole year so that the environment is friendly. No doubt, if there are indicators that show a problem you must act inmediately.
To finish, let me tell you also something that I hope you will take it properly. I detect in the way your question is expressed certain old-times attitude that I think is biasing how you approach the problem. You should, and here I connect with my first paragraph, consider your developers not 'blue-collar' workers that will try to work the least but 'artists' looking for a muse that inspires them to create.