We have activated the adaptive bitrate and the DVR functionality on our Wowza server.
We have implemented a tag video functionality on both VOD and Live videos. When a tag is created on a VOD file everything works fine. We are able to play only a part of the video (tagged by the user) by specifying parameters in the URL like this:
http://[wowza-server-url]/blizzard_vod/mp4:dome1_stream_de037829-576e-4e0c-aa4d-8a52e21dcf86.mp4/playlist.m3u8?wowzaplaystart=1308000&wowzaplayduration=30000
Where the parameter wowzaplaystart specifies from what millisecond to start the video and the parameter wowzaplayduration specifies the video duration. This is how our tag works.
Problem comes when we want to tag a live event and see the tag during the event is still live.
The URL for playing a tag when the event is still live look like this:
http://[wowza-server-url]/blizzard_live/smil:dome2.smil/playlist.m3u8?wowzaplaystart=797000&wowzaplayduration=30000&DVR
During live events we play SMIL file that handles the adaptive bitrate. Because of that, the parameters that we provide no longer "cut" the video at the specified time. The DVR option is enabled and gives us the ability to play, pause, rewind the video even if it is streamed live.
Does anyone know what URL parameters to provide to the SMIL file to play it at specific time?
VOD use wowzaplaystart and wowzaplayduration
Adobe HDS
/vod/mp4:sample.mp4/manifest.f4m?wowzaplaystart=30000&wowzaplayduration=40000
Apple HLS
/vod/mp4:sample.mp4/playlist.m3u8?wowzaplaystart=30000&wowzaplayduration=40000
MPEG-DASH
/vod/mp4:sample.mp4/manifest.mpd?wowzaplaystart=30000&wowzaplayduration=40000
Smooth Streaming
/vod/mp4:sample.mp4/Manifest?wowzaplaystart=30000&wowzaplayduration=40000
nDVR use wowzadvrplayliststart and wowzadvrplaylistduration
Adobe HDS
/dvr/myStream/manifest.f4m?DVR&wowzadvrplayliststart=60000&wowzadvrplaylistduration=300000
Apple HLS
/dvr/myStream/playlist.m3u8?DVR&wowzadvrplayliststart=60000&wowzadvrplaylistduration=300000
MPEG-DASH
/dvr/myStream/manifest.mpd?DVR&wowzadvrplayliststart=60000&wowzadvrplaylistduration=300000
Smooth Streaming
/dvr/myStream/Manifest?DVR&wowzadvrplayliststart=60000&wowzadvrplaylistduration=300000
SMIL
<video begin="30.0" dur="40.0" src="mp4:sample.mp4" system-bitrate="450000">
source: http://blog.iiwn.live/2015/11/wowza-how-to-specify-start-time-and.html
Related
So I know that one can adjust the rate of download with youtube-dl using the -r or --limit-rate flags; however, as part of a simulation testing, I am trying to simulate a user watching a video , and so I want to download a video at a rate such that the download would take as long as the video's duration is if one were to watch the video, so that a 2min long video would take 2min to download, and so on and so forth.
I have meticulously reviewed the available options on their github page, but it seems like there are no options natively to do that. But then the next best thing I can think of is to get the video duration in seconds (lets call it t) and the video size in bytes (lets call it s) and then use s/t as a value for the --limit-rate flag.
However now the problem is that there doesn't seem to be any options/flags to get the video file-size in bytes!
Is there anyway I can accomplish what my goal is here? I am open to using other tools/programs if this is outside the capabilities of youtube-dl.
To be more specific, I am working in linux server environment (no video-card and needs to be able headlessly), and the videos I'm dealing with are MPEG Dash videos from an MPD file, so whatever tool I use needs to be able to parse and work with MPD files.
Thank you for your help,
First of all, here is what I'm trying to accomplish:
We'd like to add the capability to our commercial application to generate a video file to visualize data. It should be saved in a reasonably compressed format. It is important that the encoding library/codecs are licensed such that we're allowed to use and sell our software without restriction. It's also important that the media format can easily be played by a customer, i.e. can be played by Windows Media Player without requiring a codec pack to be installed.
I'm trying to use DirectShow in c++ by creating a source filter with one output pin that generates the video. I'm closely following the DirectShow samples called Bouncing Ball and Push Source. In GraphEdit I can successfully connect to a video renderer and see the video play. I have also managed to connect to AVI Mux and then file writer to write an uncompressed AVI file. The only issue with this is the huge file size. However, I have not been able to save the video in a compressed format. This problem also happens with the Ball and Push Source samples.
I can connect the output pin to a WM ASF Writer, but when I click play I get "This graph can't play. Unspecified error (Return code: 0x80004005)."
I can't even figure out how to connect to the WMVideo9 Encoder DMO ("These filters cannot agree on a connection"). I could successfully save to mjpeg, but compression was not very substantial.
Please let me know if I'm doing something wrong in GraphEdit or if my source filter code needs to be modified. Alternatively, if there is another (non-DirectShow) option that would work for me I'm open to suggestions. Thanks.
You don't give details to help you with your modification of the filters, however Ball sample generates output which can be written to a file.
Your choice of WM ASF Writer filter is okay - it is a stock filter and it is more or less easy to deal with. There is however a caveat: you need to select video only profile on the filter first, and then connect video input. WM ASF Writer won't run with an unconnected input pin, and in default state it also has an audio input. Of course this can also be done programmatically.
The graph can be as simple as this, and it can be run and it generates a playable file.
I'm using Media Foundation to create an MP4 (H264 + AAC) output file out of an input MP4 after a series of filters. The creation of the video works perfectly and the video is reproduced without issues locally. The problem is that when executed remotely (through a web player or even VLC), the video doesn't start until it's fully downloaded.
I checked and confirmed that the http website hosting the file supports the Accepts-Ranges header field and after a while I figured out that the problem happens because the file hasn't been created with the "fast start" flag that allows for progressive download of the video.
I tried to search online for a solution, but I've been unable to find a way to apply that flag with Media Foundation's Sinkwriter. Any idea? (I can't use any external application to do this as this code is going to run within the Windows Store environment)
Progressive download requires that moov box goes before mdat box in the MPEG-4 file, which typically requires additional effort when the file is generated, and which is not the default behavior with Media Foundation.
Media Foundation introduced MF_MPEG4SINK_MOOV_BEFORE_MDAT attribute to handle this:
The default behavior of the mpeg4 media sink is to write 'moov' after
'mdat' box. Setting this attribute causes the generated file to write
'moov' before 'mdat' box.
In order for the mpeg4 sink to use this attribute, the byte stream
passed in must not be slow seek or remote for .
This feature involves an additional file copying/remuxing.
Note minimal requirements. Or, you need to post-process the file to move the moov box to the beginning.
See also:
How to generate "moov before mdat" MP4 video files with Media Foundation
I'm using c++ and poco libraries. I'm trying to implement a video streaming httpserver.
Initially i used Poco::StreamCopier.
But client failed to stream.
Instead client is downloading the video.
How can i make the server to send a streamresponse so that client can stream the video in browser instead of downloading?
While not within POCO, you could use ffmpeg. It has streaming servers for a number of video protocols and is written in C (which you could write POCO-like adapters for).
http://ffmpeg.org/ffmpeg.html#rtp
http://ffmpeg.org/ffmpeg.html#toc-Protocols
http://git.videolan.org/?p=ffmpeg.git;a=tree
And it has a pretty liberal license:
http://ffmpeg.org/legal.html
You need to research which video encoding and container that is right for streaming -- not all video files can stream
Without using something to decode the video at the other end but simply over HTTP, you can use The mime encoding "content-type:multipart/x-mixed-replace; boundary=..." and send a series of jpeg images.
This is actually called M-JPEG over HTTP. See: http://en.wikipedia.org/wiki/Motion_JPEG
The browser will replace each image as it receives it which makes it look like it's video. It's probably the easiest way to stream video to a browser and many IP webcameras support this natively.
However, it's not bandwidth friendly by any means since it has to send a whole jpeg file for each frame. So if you're going to be using this over the internet it'll work but will use more bandwidth than other method.
However, It is naively supported in most browsers now and it sounds like that is what you're after.
I have a Windows native desktop app (C++/Delphi), and I'm successfully using Directshow to display live video in it from a 'local' video capture device.
The next thing I want to do is display video from a 'remote' capture device, streamed over the LAN.
To stream the video, I guess I can use something like Expression Encoder or VLC, but I'm not sure what's the easiest way to receive/decode the streamed video. Inserting an ActiveX VLC or Flash player might be one option (although the licensing may be an issue then), but I was wondering if there's any way to achieve this with Directshow...
Application needs to run on XP, and the video decoding should ideally be royalty free.
Suggestions, please!
Using Directshow for receiving and displaying your video can work, but the simplicity, "openness" and performances will depend on the video format and streaming method you'll be using.
A lot of open/free source filters exist for RTSP (e.g. based on live555), but you may also find that creating your own source filter is a better fit.
The best solution won't be the same for H264 diffusion through RTP/RTSP and for MJPEG diffusion through simple UDP.