Split without transcoding: File output: save multiple small files instead of 1 big file

assigned to @ivoire

changed title from File output: save multiple small files instead of 1 big file to Split without transcoding: File output: save multiple small files instead of 1 big file

If VLC could split file of numerous formats as easily as it can play them, the popularity of VLC would grow even faster!

Currently, we must rely on MKVtoolnix to split MKV, MP4box to split MP4, and Virtualdub/AVIdemux to split AVI), and AsfBin to split ASF/WMV using rather clunky command-line tools that require careful reading of their command-line docs. Many tools require the user to guess/know the length (number of seconds) for each segment to split, instead of viewing the file and marking the split point.

VLC has a unique opportunity to excel beyond the other tools by combining the amazing ability to split source input files of VLC to visually display the video of numerous formats all in one common tool, which we have all come to know and love. For example, VLC could support splitting MP4 files without re-encoding them or reducing the quality, or breaking the synchronization of AC3 audio and MP4 video.

Best wishes to the awesome VLC team!

Any progress on this? At the moment, we have to use a in-house application to restart the VLM streams via telnet in order to force the recreation of the files but that only works when the filenames have a dynamic variable in them. It's ineffective and inefficient but I really don't want to have to move away from half of streaming infrastructure because of this one roadblock.

livehttp output isn't sufficient and people require more generic 'split any fileformat' feature?

commit 3dde002c00b4ad4e107e717461c346acf956c99c Author: Rémi Denis-Courmont remi@remlab.net Date: Sat Feb 21 00:01:23 2015 +0200

cycle: initial support for splitting stream output in time (refs [#561](https://code.videolan.org/videolan/vlc/-/issues/561))

Original author: remi@remlab.net

commit c599964d Author: Rémi Denis-Courmont remi@remlab.net Date: Sat Feb 21 00:01:23 2015 +0200

cycle: initial support for splitting stream output in time (refs [#561](https://code.videolan.org/videolan/vlc/-/issues/561))

Example:
 #cycle{duration=20m,
        dst=std{mux=ts,access=file,dst=sport.ts},   duration=5m},
        dst=std{mux=ts,access=file,dst=weather.ts}, duration=5m}

Skips 20 minutes, then records 5 minutes to sport.ts, then 5 more
minutes to weather.ts and restarts.

"duration" specifies the duration of the previous phase
"offset"   specifies the offset at which the previous phase ends
           and the next phase begins
           (mutually exclusive with duration)
"dst"      specifies the stream output chain for the phase
           (if missing, the phase is skipped/discarded)

Durations and offsets are so far expressed as an integer, optionally
followed by a unit: w=week, d=day, h=hour, m=minute, s=second. Second
is the default.

Currently only the decoding time stamp can be used as a reference, but
adding local or UTC clocks should be relatively easy.

ES synchronization and reference frames management is left for
further study.

Original author: remi@remlab.net

Thanks for the module! I tried it and found a few issues:

It does not specify alias "cycle", so you must call it: #stream_out_cycle{duration=20m, ...}
I'm recording from an IP camera via RTSP. The camera sends timestamp in the stream, which means that the stream can start at e.g. 02:00:00, or even "day 94, 15:00:32" (it's basically the uptime of the camera). The second case happened to me, and the module ran through this missing time, stopping and starting the output thousands of times.

I have added a function to initialize offsets from first block arriving in Send().

I'm new to VLC, so I'm not sure why does that happen and what does it mean, but I had to add

if(block == next) { next = NULL; }

before cycle.c:161 (as a first command in the for() block of Send()), because else it would get stuck in an infinite loop and/or crash. It appears that last available block does not have block->p_next == NULL, but block->p_next == block. Maybe it was only tested on a locally available file, and this happens when streaming from a live source?

I want the output filename, specified in dst={...}, to include current timestamp. Is this possible anyhow? I just hacked something in the source for myself, but that surely isn't of production quality.
Also key frames are in my case reported in block->i_flags, so I've added "only go to next in cycle when BLOCK_FLAG_TYPE_I", but I'm not sure if this information is always available, and how to detect if it is.

As for 1-3, I can submit a patch if desired, but I'm not sure I've solved these issues the right way, and I only write C occasionaly, so it may not be up-to standards. If you give me some pointers though, I can work on it.

Hello. Is this implemented or I have to compile the player including cycle.c? If yes how should I use this in something like this "vlc http:stream :sout=#standard{access=file,mux=ts,dst=c:\currentstream.mp4} "

Thank you

Original author: http://valentin80.livejournal.com/

mentioned in issue #2971 (closed)

marked #2971 (closed) as a duplicate of this issue

marked this issue as related to #2971 (closed)

added Component::Stream output label

added Type::feature label

Split without transcoding: File output: save multiple small files instead of 1 big file

Child items 0

Activity