HLS Live stream issue
Before entering a bug I was wondering if someone could help me with the reading of HLS video (m3u8) with opencv.
Also, sorry but the question is a tad long, but I felt background was useful here.
First of all, an on-demand HLS video (one with ##EXT-X-ENDLIST) works fine
The problem occurs when working with live m3u8 videos. Since frame indexes in the opencv code don't rely on actual pts or dts, it's just an increment, it is off when starting to read a live video.
To start at the actual first frame on a live video, you need to add {code} err = av_dict_set(&dict, "live_start_index", "0", 0); {code} To modules/videoio/src/cap_ffmpeg_impl.hpp in CvCapture_FFMPEG::open
But even this isn't enough. This makes reading live feeds possible, but seeking still doesn't work. Problem is get_total_frames is always 0 in a live stream since...it's live
So the first line of seek: _frame_number = std::min(_frame_number, get_total_frames()); always returns 0, the first frame
and this if (get_total_frames() > 1) av_seek_frame(ic, video_stream, time_stamp, AVSEEK_FLAG_BACKWARD);
skips the seek entirely.
These checks were added in commit 3ec43a11edf8f7c36cbf934906221fd1aabc5b7cwhich seemed to fix http://code.opencv.org/issues/1892
If I just remove the checks using get_total_frames everything seems to work just fine whether video is live or on-demand.
Reading the original bug this code didn't fix the problem at all and caused mine. The bug got closed because there was no activity for 3 years.
So unless I am missing something else, I guess I need to submit a patch that reverts this bug fix that didn't fix anything and is now causing problems on live HLS feeds?
thank you
a link instead of a number is better. version 2.4.3-rc
You are right, and you also made me realise that I posted the parent commit to the actual culprit. I edited my question accordingly. thanks