Revision history [back]

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 ca5723961819379c11ce2b2e8aa862abba85a091 Date: Wed May 2 13:07:30 2012 +0000

fixed some problems after r8280 (lost code)

So the reason for this is completely unknown...what does it protect us from except asking for a frame past the last?

If I just remove the checks using get_total_frames everything seems to work just fine whether video is live or on-demand.

tl;dr: So, my long winded questions is, what was commit ca572396181937 (fixed some problems after r8280 (lost code) protecting us from?

thank you

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 ca5723961819379c11ce2b2e8aa862abba85a091 Date: Wed May 2 13:07:30 2012 +0000

fixed some problems after r8280 (lost code)

So the reason for this is completely unknown...what does it protect us from except asking for a frame past the last?3ec43a11edf8f7c36cbf934906221fd1aabc5b7c which 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.

tl;dr: So, my long winded questions is, what was commit ca572396181937 (fixed some problems after r8280 (lost code) protecting us from?So unless I am missing something else, I guess I need to submit a patch to keep the old bug fixed and this new bug fixed as well?

thank you

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 3ec43a11edf8f7c36cbf934906221fd1aabc5b7c which 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.

So unless I am missing something else, I guess I need to submit a patch to keep the old bug fixed and this new bug fixed as well?

thank you

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 3ec43a11edf8f7c36cbf934906221fd1aabc5b7c which 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 to keep the old that reverts this bug fixed fix that didn't fix anything and this new bug fixed as well?is now causing problems on live HLS feeds?

thank you