Trying to wrap my head around what's possible and how it compares to web sockets. Http2 allows the server to continuously push to client, are there any limits that prevents this from being used to send video packets fast enough for video streaming to work?
HTTP/2 push has been designed to push resources associated to a primary resource.
It is mostly used for browsers, where upon requesting an index.html page, they get pushed style.css and application.js that are referenced by index.html.
Technically, it is be possible to stream a video to a client in a single response to a client request (bulk download).
For more advanced features such as buffering a little ahead and only download at video stream consumption, HTTP clients can make range requests.
For download of parallel streams with different resolution - 720p vs 1080p - the client can make two different requests.
HTTP/2 would need to be configured so that clients have a large flow control window (see this answer), but for browsers that is already the case, and most HTTP/2 client libraries do support this kind of configuration.
So it is technically possible, but how would it compare to WebSocket?
WebSocket lacks entirely the notion of metadata, so the application writer would have to invent some metadata format for requests and responses, such the video stream id/title, the resolution, the range, etc. and then download the raw video.
The HTTP/2 frame overhead is 9 bytes, the WebSocket frame overhead is 10 bytes (assuming large-ish frames). However, the max frame size is 16 KiB for HTTP/2 and could be larger for WebSocket, although probably not recommeded to be too large (as the client may decide to not allocate resources for super-large frames sent by the server).
Also, in WebSocket, there is the notion of a max message size. You typically cannot just send WebSocket frames all belonging to the same message, so you will need to split the video into multiple, smaller, messages (but it's just a technicality).
Lastly, HTTP/2 can carry a WebSocket communication in a HTTP/2 stream (RFC8441).
This means that a HTTP/2 request/response can perfectly simulate WebSocket communication: you will have an "infinite" request - one that has request content that never ends (until the communication is closed) - for client to server communication, and an "infinite" response - one that has a response content that never ends (until the communication is closed) - for server to client communication.
In summary, I would not use HTTP/2 push for streaming videos: a normal HTTP/2 response can do the job more efficiently (like WebSocket would).
I see WebSocket really useful for unsolicited communication from server to client. With HTTP/2, the client must always initiate the request.