Re: Re: storing one video stream into multiple files

[Jan Spurný]

Hi,

I have some progress, but not in a form of a plugin/element yet. I'm now experimenting with "dynamic" element change when I block decoder's src pad, unlink the encoder from the rest of the pipeline, send EOS to the rest of the pipeline, destroy the rest, create new elements, link them, set them to PLAYING, link them with the static pipeline and unblock decoder's src pad. It looks a bit like this:

[live_source]->[decoder]--X-->[encoder]->[muxer]->[filesink]

where:
 [live_source]->[decoder] is a static part of a pipeline
 X is point where pipeline is blocked / cut / extended / unblocked
 [encoder]->[muxer]->[filesink] is dynamic part which is created 

This way I can use almost any muxer/encoder I want and I'm able to set new filename everytime the pipeline changes.

I have still some problems, but I think it'll work and then I'll just make new element for "Software DVR bin", let's call it "swdvrbin" for now.

But there is two major inherent problems with my approach:
 - video gets decoded and then reencoded, which can be a big performance problem 
 - stored video is different from the one which "live_source" has sent


Jan Spurny

>  ------------ Původní zpráva ------------
>  Od: Mike Mitchell <mike.mitchell at panometric.net>
>  Předmět: Re: storing one video stream into multiple files
>  Datum: 16.2.2012 23:00:29
>  ----------------------------------------
>  Jan,
>  I have a similar requirement and would be willing to collaborate with you
>  on this one. I agree that mutlifilesink is the right implementation from a
>  pipeline architecture perspective. But mux and codec complexities might
>  throw some curves.  I am interested in using it with the mp4mux.
>  It looks as if multifilesink is very close to doing it. Here's what I have
>  tried:
>  
>  gst-launch -vt --gst-plugin-spew  videotestsrc num-buffers=10
>  do-timestamp=true is-live=true ! queue \
>  ! 'video/x-raw-yuv,width=1280,height=720,framerate=15/1' ! x264enc pass=5
>  quantizer=22 speed-preset=4 profile=1 ! queue ! mux. \
>   audiotestsrc is-live=true  num-buffers=10  ! queue ! faac bitrate=44100  !
>   queue ! mux. \
>   mp4mux name="mux" faststart=true ! \
>   multifilesink location=segment%05d.mp4 post-messages=true next-file=1
>  #filesink location=segment.mp4
>  # above works but multifilesink fails to open file line 532
>  
>  There appear to be a few problems:
>  1. With any next-file value other than 0, multifilesink fails to open file
>  line 532. I'm not sure why.
>  2. There needs to be a new GstMultiFileSinkNext file for a certain amount
>  of time.
>  3. Currently, the files created with next-file=0 have size but are corrupt,
>  presumably because the lack the proper mp4 format. Although next-file=2 is
>  commented as being useful for TSMUX streams, which are similar.  Also not
>  sure why.
>  
>  It seems like a very useful feature for DVR applications. Anyone have some
>  guidance on this?
>  
>  *Mike Mitchell*
>  
>  
>  
>  
>  On Wed, Feb 1, 2012 at 3:00 AM, Jan Spurny <JSpurny at seznam.cz> wrote:
>  
>  > Hi,
>  >
>  > I'm trying to store video from one video stream into multiple files with
>  > given duration.
>  > Something which could look like this:
>  >
>  > gst-launch souphttpsrc location=http://1.2.3.4/video1 ! decodebin !
>  > x264enc ! SOMETHING filename="file_%D_%T.mp4" duration=2m
>  >
>  > and it would produce files like these:
>  >
>  > file_2012-02-01_10-12-43.mp4
>  > file_2012-02-01_10-14-43.mp4
>  > file_2012-02-01_10-16-43.mp4
>  > ..
>  >
>  > I don't expect that element "SOMETHING" already exists so I'll have to
>  > write it myself. I have written a few simple gstreamer elements (mostly
>  > some kind of raw-video transformations) so I'm quite confident I'll be able
>  > to do it, but I do need all advices and guidelines I can get.
>  >
>  > I'll have many different inputs - different input sources (files, http
>  > streams, rtsp streams, v4l, ..) and also different input formats (mjpeg,
>  > mpeg4, h264, raw-yuv). But that's ok, gstreamer can handle these without
>  > problems.
>  >
>  > Now I can either just simply reuse the stream and just "cut it into chunks
>  > of desired length", but as there are so many different formats to work
>  > with..
>  > Or I'll just recode video into some default format. That's why I have a
>  > "decodebin ! x264enc" in my pipeline above. I may support more formats in
>  > the future but for the first version one is enough.
>  >
>  > So with one known format (let's say h264) I'll have to "pack it" (muxer)
>  > into small chunks and write them down to disk.
>  >
>  > This is the part where I don't really know where to start - I guess
>  > studying some existing muxer and would be a good start, but I'm really
>  > scared of all the complexity with encoded video streams, B-frames,
>  > I-frames, and all this..
>  >
>  >
>  > Thanks in advance for any help, advices or suggestions.
>  >
>  > Jan Spurny
>  > _______________________________________________
>  > gstreamer-devel mailing list
>  > gstreamer-devel at lists.freedesktop.org
>  > http://lists.freedesktop.org/mailman/listinfo/gstreamer-devel
>  >
>  
>  
>