Single-Table vs. Multi-Table design
As with all database design don't think just about what you want to store but also about how you wish to retrieve and modify the information.

If you never need to refer to or search by individual parts of the contents then your first schema is fine. Similarly if you do need to do those things but you are suing a database that allows efficient indexing and manipulation of JSON blocks.

As a general rule though I would normalise the data which means breaking it down as you have in separate tables rather than using one column to store many values.

BTW: the pattern you seem to be heading towards in your second example is called table inheritance - you have a general "posts" object which contains properties common to all your object types and a detail table for each object containing properties that are unique to that object (or at least are not common to other object types). Unless one post could contain multiple photos (or videos, or ...) which is implied by your first design then you don't need a separate ID for each detail table: there will be zero or one rows per row in posts so the post_id is valid as both the primary key and foreign key. Also there is no need to repeat user_id in each table (as that can be derived from the link to posts) unless a different user could add the photo/video to someone else's existing post.