mysqlbinlog recovery table wise
The most error-proof approach is to restore all databases -- the entire server -- to a different machine, by loading a backup (dump) file and playing back the appropriate logs, beginning at the binlog coordinates where the dump began... and then using mysqldump to extract the one table of interest and copy it to the desired destination.

In any event, you do have to restore something from a backup, first -- which I assume you understand, but have not mentioned.  Playing back the binary logs allows you to capture the events that occurred between the restored backup and the end of the log. 

Playing back a single table's row events is, to my knowledge, not supported.  But, even restoring a single database (schema) this way is a complex operation.

The --database or -d option for mysqlbinlog can only definitively identify the desired database with sufficient accuracy when the binlog_format on the server that created the log entries was set to ROW, or, in the case where the binlogs were generated by a replica with log_slave_updates enabled, at least one of the servers in the cascade, including the last one, had its binlog_format set to ROW, because this coerces the replication events into ROW format, which is a one-way process.

If the events were not logged in ROW format, then playing back the binary logs can't be guaranteed to work correctly without all of the other data on the server also being present.  It is also not possible to be certain that the --database or -d option will catch all of the statements, if they were not logged in ROW format, because of interactions with the USE statement and other intricacies of how MySQL interprets replication events.

This does not mean that mysqlbinlog is broken, only that it's an advanced tool that can only be used within the constraints of the way replication works.

The binary log format was designed for replicating changes from one server to another, and only contains enough information to do that when the two servers in question begin with the same data set -- hence the reference to restoring from a backup. 

Also, playing back a binary log into your production system is really not something you would ever want to do unless your production system had been damaged so badly that you had no choice but to completely reload it from a backup and wanted to play-forward through the available logs to minimize the amount of lost data.