<p>Cutting a video doesn't require more knowledge than what you are trying to do here. I'd even say it requires less knowledge.
Consider the free video editing tool Lightworks and this short video tutorial on how to cut videos with it:
<div class="youtube-embed"><div>
                <iframe width="640px" height="395px" src="https://www.youtube.com/embed/Hbp13oZPsEQ?start=0"></iframe>
            </div></div></p>

CC BY-SA 3.0
2014-10-03T17:39:14.787Z
Thanks for your recommendation, but I want to tackle the problem in this way and of-course it doesn't seem too problematic.
Mohammad Namakshenas
CC BY-SA 3.0
2014-10-13T16:17:53.097Z
I'd have to agree Professor - it is much easier, and less fraught with potential embarrassment to cut the video in advance. Then all you need on the day is to be able to hit **play**
Dr Mayhem
CC BY-SA 3.0
2014-10-03T17:21:55.110Z
2014-10-03T17:21:55.110Z
timonsku
<p>I'd agree with Dr Mayhem's comment that it's risky to have a file with content you don't want public sitting there on your laptop hooked up to a projector.  <code>mkvmerge</code>, or another remuxing tool, will be able to chop up your video.  I think avidemux might do well for this, since you can use the GUI to find edit points, and it supports remuxing instead of transcoding.  (IDK if any full-fledged video editors can just remux if you're only making timeline changes, and cutting on keyframes.)</p>

<p>I just tried avidemux.  It still doesn't have proper support for B frames, so tt's stuck in the dark ages.  It did seem to work for cutting some segments out of an MP4(h.264/aac) and saving to an mkv.  It did warn about using it's workaround mode for B frames, on loading the file, though.  I wouldn't use it for encoding (its x264 config dialog is terrible), but it does appear to work for remuxing.</p>

<p>But anyway, if you're confident that un-authorized users won't be poking at your laptop and playing files you want to keep private, I do have a proper answer for your question.</p>

<p><a href="http://mpv.io/" rel="nofollow">mpv</a> supports "edit decision lists" in a similar format to what mplayer uses.  (It's a fork of mplayer that drops some old drivers, and focuses on new features, like better colorspace defaults.  mplayer is mostly focused on being stable / backwards compatible, which prevents some kinds of changes.)  It runs on all 3 major desktop OSes.</p>

<p>The EDL format is similar to mplayer's, but mplayer takes an EDL as an option while playing a different file.  Mpv instead has an EDL demuxer, so an EDL is an input file that references other files.  (mpv can thus play multiple files as if they were one long seamless file, for the purposes of seeking.)</p>

<p>Anyway, mpv's <a href="https://github.com/mpv-player/mpv/blob/master/DOCS/edl-mpv.rst" rel="nofollow">EDL format</a> uses <code>filename,start,length</code> tuples.  (note: length not end point):</p>

<pre><code># mpv EDL v0
input.mkv,5,13
input.mkv,42,10
input.mkv,60,10
input.mkv,112.2,3.2
</code></pre>

<p>Then you run mpv on that file (<code>mpv my-segments.edl</code>, or double click or whatever).</p>

<p>The <code>edl://</code> syntax is for putting the contents of the edl on the command line, without using a separate file.</p>

<p>This appears to be fairly robust.  Even with the seek controls, I can't play parts of the file outside the virtual stream created by the EDL.  Chapter seeks go to EDL segment boundaries.  (I haven't tried it on an mkv with chapters, or a DVD.)</p>

<p>Actually, you CAN escape the EDL virtual stream, but only by 2 seconds into the part of the file before the first segment.  So there's no issue if your first segment starts at the beginning of a file.  (Accurate-seek by 1 sec backwards, and frame-step-backwards, are the commands that can take you to negative 2 seconds into the stream.)  If that's an issue, unbind those keys in an <code>mpv.conf</code> file.</p>

<p>If your file has chapters, you can use those instead of seconds.  (see the end of the edl-mpv.rst doc I linked).</p>

<p>If your edit points are far from a previous keyframe, mpv will pause briefly while it decodes from the seekable I frame up to the exact frame you told it to start on.  This could be noticeable with a slow CPU and HD content, if it has to decode hundreds of frames.</p>

<p>I was surprised how well mpv does at being seamless with this, with seeks back and forth across an edit point being really fast.  And even frame-step backwards obeys the edit list (except when you go off the beginning by up to 2 secs.)</p>

CC BY-SA 4.0
2024-04-04T19:34:23.543Z
Great answer. Signed up for video-SE just to upvote. I have been unable to find _any_ good documentation on the subject. Other than a vague discussion of the `edl` protocol, the *mpv* docs don't really offer any insight at all. Now that it makes sense to me, I was able to combine this with ffprobe (and a spreadsheet) and quickly produce and test a useful EDL. Thanks.
Mockman
CC BY-SA 3.0
2015-03-03T04:30:11.777Z
2015-03-03T04:41:05.760Z
2015-03-03T04:41:05.760Z
Peter Cordes
<p>I have a video file and I want to play it to some people in a public place. Actually, some parts of the video are not suitable for the public display. As you might guess, it is not respectful to skip this parts manually in front of them and I want to play the video automatically, i.e., without any manual skipping (actually when I use my mouse or keyboard to skip it, I don’t know exactly to what frame should I click and that stresses me out).  I have neither enough time nor special knowledge how to cut the pieces and re-render it. I’m using K-Lite to play my videos files for some reasons such as loading subtitles. A friend of mine said that I can make a text file with the jump sequences included <strong>but I don’t know how to do it (and he is not sure either!).</strong> My jump sequences are like this:</p>

<p>00:00:00 – 00:07:03 -- jump – 00:07:54 -- 00:26:22 – jump – 00:28:12 -- so on</p>

<p><strong>Other techniques are also appreciated (without cutting and re-rendering the video file).</strong></p>

CC BY-SA 3.0
2014-10-03T16:49:38.233Z
It is just as easy or more easy to just use a basic file of the times to make a basic editing tool edit the video together for you and then it will play on any player.  It is also certainly more reliable and less user error prone.
AJ Henderson
CC BY-SA 3.0
2015-02-01T01:30:33.347Z
I am confused, isn't K-Lite a codec. http://www.codecguide.com/about_kl.htm
eLouai
<video><playback>
Playing back a video file with an optional time sequence
Mohammad Namakshenas
# Playing back a video file with an optional time sequence

(Asked by: username_0 on 2014-10-03)

I have a video file and I want to play it to some people in a public place. Actually, some parts of the video are not suitable for the public display. As you might guess, it is not respectful to skip this parts manually in front of them and I want to play the video automatically, i.e., without any manual skipping (actually when I use my mouse or keyboard to skip it, I don’t know exactly to what frame should I click and that stresses me out). I have neither enough time nor special knowledge how to cut the pieces and re-render it. I’m using K-Lite to play my videos files for some reasons such as loading subtitles. A friend of mine said that I can make a text file with the jump sequences included **but I don’t know how to do it (and he is not sure either!).** My jump sequences are like this:

00:00:00 – 00:07:03 -- jump – 00:07:54 -- 00:26:22 – jump – 00:28:12 -- so on

**Other techniques are also appreciated (without cutting and re-rendering the video file).**

**Tags:** video, playback

> **Comments:**
> **username_1**: It is just as easy or more easy to just use a basic file of the times to make a basic editing tool edit the video together for you and then it will play on any player.  It is also certainly more reliable and less user error prone.  
> **username_2**: I am confused, isn't K-Lite a codec. http://www.codecguide.com/about_kl.htm  

---

## 2 answers

### Answer by username_5 on 2015-03-03. Score: 2 | Accepted answer

I'd agree with username_4's comment that it's risky to have a file with content you don't want public sitting there on your laptop hooked up to a projector.  mkvmerge, or another remuxing tool, will be able to chop up your video.  I think avidemux might do well for this, since you can use the GUI to find edit points, and it supports remuxing instead of transcoding.  (IDK if any full-fledged video editors can just remux if you're only making timeline changes, and cutting on keyframes.)
I just tried avidemux.  It still doesn't have proper support for B frames, so tt's stuck in the dark ages.  It did seem to work for cutting some segments out of an MP4(h.264/aac) and saving to an mkv.  It did warn about using it's workaround mode for B frames, on loading the file, though.  I wouldn't use it for encoding (its x264 config dialog is terrible), but it does appear to work for remuxing.
But anyway, if you're confident that un-authorized users won't be poking at your laptop and playing files you want to keep private, I do have a proper answer for your question.
mpv supports "edit decision lists" in a similar format to what mplayer uses.  (It's a fork of mplayer that drops some old drivers, and focuses on new features, like better colorspace defaults.  mplayer is mostly focused on being stable / backwards compatible, which prevents some kinds of changes.)  It runs on all 3 major desktop OSes.
The EDL format is similar to mplayer's, but mplayer takes an EDL as an option while playing a different file.  Mpv instead has an EDL demuxer, so an EDL is an input file that references other files.  (mpv can thus play multiple files as if they were one long seamless file, for the purposes of seeking.)
Anyway, mpv's EDL format uses filename,start,length tuples.  (note: length not end point):
# mpv EDL v0
input.mkv,5,13
input.mkv,42,10
input.mkv,60,10
input.mkv,112.2,3.2

Then you run mpv on that file (mpv my-segments.edl, or double click or whatever).
The edl:// syntax is for putting the contents of the edl on the command line, without using a separate file.
This appears to be fairly robust.  Even with the seek controls, I can't play parts of the file outside the virtual stream created by the EDL.  Chapter seeks go to EDL segment boundaries.  (I haven't tried it on an mkv with chapters, or a DVD.)
Actually, you CAN escape the EDL virtual stream, but only by 2 seconds into the part of the file before the first segment.  So there's no issue if your first segment starts at the beginning of a file.  (Accurate-seek by 1 sec backwards, and frame-step-backwards, are the commands that can take you to negative 2 seconds into the stream.)  If that's an issue, unbind those keys in an mpv.conf file.
If your file has chapters, you can use those instead of seconds.  (see the end of the edl-mpv.rst doc I linked).
If your edit points are far from a previous keyframe, mpv will pause briefly while it decodes from the seekable I frame up to the exact frame you told it to start on.  This could be noticeable with a slow CPU and HD content, if it has to decode hundreds of frames.
I was surprised how well mpv does at being seamless with this, with seeks back and forth across an edit point being really fast.  And even frame-step backwards obeys the edit list (except when you go off the beginning by up to 2 secs.)

> **Comments:**
> **username_6**: Great answer. Signed up for video-SE just to upvote. I have been unable to find _any_ good documentation on the subject. Other than a vague discussion of the `edl` protocol, the *mpv* docs don't really offer any insight at all. Now that it makes sense to me, I was able to combine this with ffprobe (and a spreadsheet) and quickly produce and test a useful EDL. Thanks.  

---

### Answer by username_3 on 2014-10-03. Score: 0

Cutting a video doesn't require more knowledge than what you are trying to do here. I'd even say it requires less knowledge.
Consider the free video editing tool Lightworks and this short video tutorial on how to cut videos with it:

> **Comments:**
> **username_0**: Thanks for your recommendation, but I want to tackle the problem in this way and of-course it doesn't seem too problematic.  
> **username_4**: I'd have to agree Professor - it is much easier, and less fraught with potential embarrassment to cut the video in advance. Then all you need on the day is to be able to hit **play**  

---

