
Recherche avancée
Autres articles (98)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...) -
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)
Sur d’autres sites (7670)
-
Adding images on both sides of a vertical video using FFmpeg
7 juin 2016, par John DakotaI have a video that I recorded with my phone vertically. When viewing the video on a computer, a large margins on both sides of the video are black. I would like to replace this with an image using FFmpeg.
I read the section on pads on the FFmpeg docs, but it does not say anything about using images as pads (correct me if I’m wrong), it only mentions using colors.
-
Play UDP live video stream in UWP
19 avril 2018, par Nicolas SévenoI need to display a live video stream in a UWP application.
The video stream comes from a GoPro. It is transported by UDP messages. I think it is a MPEG-2 TS stream.
I can play it successfully using FFPlay with the following command line :
ffplay -fflags nobuffer -f:v mpegts udp://:8554
I would like to play it with MediaPlayerElement without using a third party library.
According to the following page :
https://docs.microsoft.com/en-us/windows/uwp/audio-video-camera/supported-codecs
UWP should be able to play it. (I installed the "MPEG 2 video extension" in the Windows Store).I tried using DatagramSocket and the MessageReceived event to receive the UDP packets, it works without problem :
_datagramSocket = new DatagramSocket();
_datagramSocket.MessageReceived += (s, args) =>
{
Debug.WriteLine("message received");
};
await _datagramSocket.BindServiceNameAsync(8554);Then I create a MseStreamSource :
_mseStreamSource = new MseStreamSource();
_mseStreamSource.Opened += (_, __) =>
{
_mseSourceBuffer = _mseStreamSource.AddSourceBuffer("video/mp2t");
};
this.MediaSource = MediaSource.CreateFromMseStreamSource(_mseStreamSource);And in the DatagramSocket.MessageReceived event I send the messages to the MseStreamSource :
using (IInputStream stream = args.GetDataStream())
{
_mseSourceBuffer.AppendStream(stream);
}The AppendStream method fails with error HRESULT 0x8070000B for some packets.
If I catch the error, the MediaPlayerElement displays the message "video not supported or incorrect file name". (not sure of the message, my Windows is in French).Is the MseStreamSource the correct way to display the stream ? Is there a better solution ?
-
How to send encoded video (or audio) data from server to client in a way that's decodable by webcodecs API using minimal latency and data overhead
11 janvier 2023, par Tiger YangMy question (read entire post for context) :


Given the unique circumstance of only ever decoding data from a specifically-configured encoder, what is the best way I can send the encoded bitstream along with the bare minimum extra bytes required to properly configure the decoder on the client's end (including only things that change per stream, and omitting things that don't, such as resolution) ? I'm a sucker for zero compromises, and I think I am willing to design my own minimal container format to accomplish this.


Context and problem :


I'm working on a remote desktop implementation that consists of a server that captures and encodes the display and speakers using FFmpeg and forwards it via pipe to a go (language) program which sends it on two unidirectional webtransport streams to my client, which I plan to decode using the webcodecs API. According to MDN, the video decoder needs to be fed via .configure() an object containing the following : https://developer.mozilla.org/en-US/docs/Web/API/VideoDecoder/configure before it's able to decode anything.


same goes for the audio decoder : https://developer.mozilla.org/en-US/docs/Web/API/AudioDecoder/configure


What I've tried so far :


Because this remote desktop will be for my personal use only, it would only ever receive streams from a specific encoder configured in a specific way encoding video at a specific resolution, framerate, color space, etc.. Therefore, I took my video capture FFmpeg command...


videoString := []string{
 "ffmpeg",
 "-init_hw_device", "d3d11va",
 "-filter_complex", "ddagrab=video_size=1920x1080:framerate=60",
 "-vcodec", "hevc_nvenc",
 "-tune", "ll",
 "-preset", "p7",
 "-spatial_aq", "1",
 "-temporal_aq", "1",
 "-forced-idr", "1",
 "-rc", "cbr",
 "-b:v", "500K",
 "-no-scenecut", "1",
 "-g", "216000",
 "-f", "hevc", "-",
 }



...and instructed it to write to an mp4 file instead of outputting to pipe, and then I had this webcodecs demo https://w3c.github.io/webcodecs/samples/video-decode-display/ demux it using mp4box.js. Knowing that the demo outputs a proper .configure() object, I blindly copied it and had my client configure using that every time. Sadly, it didn't work, and I since noticed that the "description" part of the configure object changes despite the encoder and parameters being the same.


I knew that mp4 files worked via mp4box, but they can't be streamed with low latency over a network, and additionally, ffmpeg's -f parameters specifies the muxer to use, but there are so many different types.


At this point, I think I'm completely out of my depth, so :


Given the unique circumstance of only ever decoding data from a specifically-configured encoder, what is the best way I can send the encoded bitstream along with the bare minimum extra bytes required to properly configure the decoder on the client's end (including only things that change per stream, and omitting things that don't, such as resolution) ? I'm a sucker for zero compromises, and I think I am willing to design my own minimal container format to accomplish this. (copied above)