filesink and file durations

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

filesink and file durations

GStreamer-devel mailing list
Hello,

I am trying to have this pipeline end correctly, recorded files being corrupted (invalid duration):

appsrc format=time is-live=true do-timestamp=true name=src ! application/x-rtp,encoding-name=H264 ! tee name=teein ! queue max-size-buffers=0 max-size-bytes=0 max-size-time=5000000000 ! rtpjitterbuffer latency=100 ! rtph264depay ! h264parse ! matroskamux ! filesink location=logs/raw.mkv teein. ! queue max-size-buffers=0 max-size-bytes=0 ! appsink name=sink qos=true

At some point the pipeline is stopped by a:
gst_element_send_event(pipeline, gst_event_new_eos());

Then a bus watch callback stops the pipeline: gst_element_set_state(pipeline, GST_STATE_NULL); on GST_MESSAGE_EOS
(I thought that when a bus watch callback receives a GST_MESSAGE_EOS it meant EOS has been propagated to all sinks)

I am wondering if this may be due to tee and queue in the pipeline.
I could also catch EOS(s) on every appsink and filesink before ending the pipeline but that seems weird.

Two additional observations:
  • on rare occasions, the recorded file does have a duration
  • I've tried waiting (g_usleep) between receiving GST_MESSAGE_EOS and setting pipeline state to GST_STATE_NULL with no effect
Would you have any suggestions?
Thanks,
Guillaume




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

Re: filesink and file durations

GStreamer-devel mailing list
Hello,

It seems I was on the wrong track thinking EOS did not propagate till
filesink.

In the pipeline (from the previous post), the mkv file has indeed invalid
duration and meta data (resolution). A workaround is to decode from/reencode
to h264 between h264parse and matroskamux... but it's a lot heavier. It
seems to be related to a problem encountered with audio/ogg:
http://gstreamer-devel.966125.n4.nabble.com/oggmux-after-rtpopusdepay-mapper-didn-t-recognise-input-stream-td4697396.html
(also described some time ago
http://gstreamer-devel.966125.n4.nabble.com/connect-rtpbin-to-oggmux-td4659110.html)

To sum up, I have not found a way to record a media stream directly after
rtp-depaying, so what I do now is decode/reencode before muxing and
recording to a file.

Any help about a way to do without decoding/reencoding these "already
encoded" streams would be greatly appreciated.

Thanks, Guillaume



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