It's both. In sprint planning, the team creates an initial sprint backlog, which is a forecast of the tasks, or bits of work, that they feel represents the best path to achieving the sprint goal. The form this takes is up to them (hours, days, thrown chicken bone patterns, etc). They will refine how they create the backlog over time to improve the value of their forecasts.
The commitment part is more about a commitment to do their best to achieve the goal while maintaining quality.
The problem is that very often this commitment comes into conflict with the initial forecast. For example, one time I estimated it would take two days to implement drift-racing physics (with a handbrake control) into our vehicle dynamics model. I was able to do this, but it took another week to make it "fun", much of that time sitting next to a designer. This couldn't have been predicted and we could have stopped after two days and said "sprint goal achieved", but was it really?
At which point do we say, "it's good enough, time to move on"? That can't come from sprint planning. It has to come from the daily conversation with the team (including the product owner). Sometimes this results in the forecast growing and the team delivering a part of the goal that meets the quality bar.
This definition can scare managers that first hear about it and it's where they and teams struggle at first. This often comes from a culture that isn't prepared to trust developers to judge or achieve quality on their own and the inexperience of teams to be given this control. So the forecast becomes the commitment and the teams focus on making the hours look good, rather than the game. It takes time to establish the balance.
So, we killed the window boxes, but it was a good lesson on our team's path to learn how to build "95 MPH art.