Length of sprint

I will start with suggesting that you "rtfm".  (No offense meant.)   https://www.scrumguides.org/scrum-guide.html

The Scrum Guide states some boundaries from which I think you would benefit.

I suggest you work on the team size first.  Twenty people is way too many people to work effectively and gain consensus.  It is possible to have multiple teams work from the same product backlog and given your makeup of the product backlog, it should be very easy for you to have multiple teams work on a separate product which as you suggested could result in splitting the large team into multiple smaller teams. 

Daily Stand Up of 1 hour is not a daily stand up and Planning for an entire day is not usual either. Read the section in the guide about the Scrum Events paying close attention the purpose and suggested duration of each. Remember that the Scrum Guide uses a one month sprint for the basis on all of their suggested durations. Make sure to do the math to adjust times to fit whatever duration you end up settling on. 

I also work where we have "product backlogs" that contain more than one product.  I actually call them team backlogs instead.  It can be managed but you have to make good use of refinement, backlog ordering and sprint goals to help focus the team on work that will deliver value when that value is needed.

The Scrum Guide states that sprints should be no more than 1 month, so you are doing that part right.  However, everywhere I have worked has found that 2 week sprints are more manageable. 

I will also suggest that you might benefit from bringing an external "expert" to help your organization.  There are many agile coaches that can help you.  And I have found that when a company is paying someone a consulting fee to be an expert, they are more likely to listen to them than to someone that is already on their payroll. 

As per scrum guide, effective team size in Scrum is 3 to 9 team members. Your team size is an issue here. 20 is way too much.

Adopt the practices that suits your team the best , Ask yourself do you actually need scrum. don't follow scrum for the heck of it, which is now a days a trend.

20 people is way too much. 

As Daniel pointed out: Check the Scrum Guide, so you can start doing Scrum, which you don't, as:

1. One month sprint cycle

- Max is four weeks. Why might this be?

2. Daily stands up last an hour

- Max is 15 minutes. Why might this be?

4. We have about 20 developers working on the sprint and that’s the number of people who join the calls 

- Max is 9. Why might this be?

At products and teams of this size, you should think about implementing one of the many approaches to scale scrum like Scrum of Scrums, LeSS or Nexus (by scrum.org). Implementing such a scaled approach comes with the additional complexity of managing dependencies between teams, product backlog items and the concurrent work on them, but if done the right way, it still won't slow you down as much as staying at your current scale of sprint/daily/team does.

Your organization should think about the following questions:

1. How could those 20 developers assigned to 3-4 teams cross-functional teams, being able to independently work on the product backlog?

2. How can product backlog items be assigned to those teams without creating dependencies between the work of those teams

3. Could the previous answer provide ideas for a better use of epics?

4. Could the previous two answers provide ideas on how to answer question one?