OpenCV_contrib contains cudacodec module that utilizes cv::VideoCapture to grub frames with FFmpeg and decode it with hardware codec on NVIDIA GPU. OpenCV cv::VideoCapture already has functionality to get RAW stream. Please take a look at the module source code: https://github.com/opencv/opencv_contrib/tree/master/modules/cudacodec

I understand that the raw stream can be retrieved, however it cannot be decoded on the CPU with FFMPEG at the same time as being written to disk without re-encoding. This would be useful when reading from an IP camera, processing the recieved video and archiving the footage. Currently to do this would require the overhead of wastefully re-encoding the decoded frames. This would also not result in an exact copy of the streamed data due to re-encoding.

This functionality could be added directly to cudacodec, however I thought it might be easier to add it directly to VideoCapture so that it can be seamlessly used by cudacodec, any class like cudacodec with reads the raw stream for decoding and VideoCapture. Additionaly it removes the need for querying when a new key frame occurs and/or manually parsing the raw stream for the frame type.

@asmorkalov
Just to confirm the expected functionality for this pull request is, given a srcUrl and a filename VideoCapture() can be called as

VideoCapture cap(filename,CAP_FFMPEG);
cap.writeToFile(filename);

and then any subsequent calls to
cap.read(img)
will retrieve the decoded frame to img and at the same time archive the raw encoded data to the file named filename. This raw data is then "exactly" the same as the source and can therefore be interogated at a later date should it be necessary. If instead the img is re-encoded using VideoWriter() any analytics run on that frame are not guaranteed to yield the same results.

Additionaly if a newFilename is given as
cap.writeToFile(newFilename);
VideoCapture() will wait until the next iFrame before closing the the first file (filename) and writing to the new file (newFilename).

From your comments I assume it is not desirable to add these extra api calls to VideoCapture(), if possible can you suggest a different way to achieve the same outcome?

If not I can just leave this feature out from VideoCapture() add it only to cv::cudacodec::VideoReader() as you suggested above. This would just require a small modification to VideoCapture::grab(img) (in addition to changes to cv::cudacodec::VideoReader()) to enable the returned img to indicate whether it contains the encoded data for an iframe and/or whether it additionaly contains the parameter sets (stored internally by ffmpeg for rtsp streams in AVFormatContext::streams[i]->codec->extradata). I was thinking that the channel parameter img.cn could be used for this, with img.cn == 0 indicating non iframe, img.cn > 0 indicating an iframe and img.cn == N indicating that the first N bytes of raw data contained in img are the parameter set (this will always be an iframe as it will only occur on the first call to VideoCapture::read()).

Would this alternative be acceptable?