splitmuxsink - robust to unexpected shutdowns

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

splitmuxsink - robust to unexpected shutdowns

jcbrock
This post was updated on .
I am trying to figure out how to make videos created by splitmuxsink robust
to unexpected shutdowns. For a mp4mux+filesink, I usually just create an
atom file and recover it later if something goes wrong. However for
splitmuxsink I don't appear to have this option from what I can tell.

Suggestions I've come across recommend using the reserved-max-duration,
reserved-moov-update-period, max-size-time, and use-robust-muxing
properties. I've tried this with several configurations to no avail. Here's
the pipeline I've come up with so far (the tees are included since this is a
trimmed down version of a larger pipeline I'm working on):

gst-launch-1.0 v4l2src device=/dev/video0 ! videoscale !
'video/x-raw,width=1280,height=720,framerate=30/1' ! videoconvert ! tee !
queue ! x264enc speed-preset=ultrafast tune=zerolatency ! tee ! queue !
h264parse ! splitmuxsink location="videos/video%02d.mov"
reserved-max-duration=3000000000000000000
reserved-moov-update-period=1000000000 max-size-time=900000000000
use-robust-muxing=1

If I change the pipeline so the EOS propagates on shutdown (i.e. adding the
-e option) the video file is playable. However if I ctrl-C or kill the
process otherwise, the resulting video file is unplayable. Furthermore, I
don't know of any way to recover files after the fact.

My questions are as follows:
 1) Is it possible to configure splitfilemux so the files it creates are
readable after unexpected shutdowns?
 2) Is it possible to recover corrupted files created by splitfilemux?

Thanks,
Jaclyn



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
gstreamer-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink - robust to unexpected shutdowns

jcbrock
Using muxer-properties doesn't appear to work. I used the following property
with splitmuxsink:

muxer-properties="properties,reserved-max-duration=600000000000,reserved-moov-update-period=1000000000"



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
Reply | Threaded
Open this post in threaded view
|

Re: splitmuxsink - robust to unexpected shutdowns

jcbrock
In reply to this post by jcbrock
I kind of got it working. I couldn't get gst-launch to behave so I decided to
jump straight to implementation. Adding a custom muxer with
"reserved-max-duration" and "reserved-moov-update-period" did the trick.
Here's a snippet of Rust code:


const VIDEO_PATH: &str = "split%02d.mp4";
const MAX_SIZE_TIME_SEC: u64 = 35;

fn create_pipeline(device: &String) -> Result<gst::Pipeline, ()> {
    let pipeline = gst::Pipeline::new(None);
    let src = gst::ElementFactory::make("v4l2src", None).unwrap();
    let scale = gst::ElementFactory::make("videoscale", None).unwrap();
    let filter = gst::ElementFactory::make("capsfilter", None).unwrap();
    let conv = gst::ElementFactory::make("videoconvert", None).unwrap();
    let queue = gst::ElementFactory::make("queue", None).unwrap();
    let enc = gst::ElementFactory::make("x264enc", None).unwrap();
    let parse = gst::ElementFactory::make("h264parse", None).unwrap();
    let sink = gst::ElementFactory::make("splitmuxsink", None).unwrap();

    let video_caps =
        gst::Caps::new_simple("video/x-raw", &[("width", &1920i32),
("height", &1080i32)]);

    let max_time_ns = MAX_SIZE_TIME_SEC * 1_000_000_000;
    let mux = gst::ElementFactory::make("mp4mux", None).unwrap();
    mux.set_property("reserved-max-duration", &max_time_ns.to_value())
        .unwrap();
    mux.set_property("reserved-moov-update-period",
&1000000000u64.to_value())
        .unwrap();

    src.set_property_from_str("device", device);
    filter.set_property("caps", &video_caps.to_value()).unwrap();
    enc.set_property_from_str("speed-preset", "ultrafast");
    enc.set_property_from_str("tune", "zerolatency");
    sink.set_property("max-size-time", &max_time_ns.to_value())
        .unwrap();
    mux.set_property("use-robust-muxing", &true);
    sink.set_property_from_str("location", VIDEO_PATH);
    sink.set_property("muxer", &mux).unwrap();

    // Build the pipeline
    let elems = [&src, &scale, &filter, &conv, &queue, &enc, &parse, &sink];
    pipeline.add_many(&elems).unwrap();
    gst::Element::link_many(&elems).unwrap();

    return Ok(pipeline);
}


Killing the process doesn't disrupt the video outputs. However, the length
of the videos are always on 10-second intervals. If the MAX_SIZE_TIME_SEC is
60, videos will be of length 50. If MAX_SIZE_TIME_SEC is length 65, videos
will be of length 65. There doesn't appear to be any frames getting skipped,
however, and experiments with gst-launch-1.0 pipelines with splitmuxsink
have the same behavior. So it's likely nothing to worry about.

If I'm still doing something wrong that someone notices, of course, please
let me know.



--
Sent from: http://gstreamer-devel.966125.n4.nabble.com/
_______________________________________________
gstreamer-devel mailing list
[hidden email]
https://lists.freedesktop.org/mailman/listinfo/gstreamer-devel