Recherche avancée

Sur d’autres sites (11531)

• Fragmented MP4 : TrackFragHeader TFHD must have TrackID, is this in the spec ?

  27 juillet 2021, par Penquin

  I'm building a fragmented mp4 muxer and noticed that the track id is repeated inside the TFHD.
If the video does not have this undocumented track id, it will simply not play.

  


  Here's an example of a muxer adding it :
https://github.com/edgeware/mp4ff/blob/bb9320744777dc97f18034c8aed45a9bcdbaa995/mp4/tfhd.go#L154

  


  I was relying on the open spec provided by Microsoft :
https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstr/513ea48c-9a57-4792-a32a-fb6202ce2a58

  


  Is this an addition to the spec ? Is the spec provided by Microsoft wrong ?

  


• Supported audio and video formats in Windows Store apps

  27 décembre 2013, par TheQuestioner

  I searched a lot on the internet and I know that this problem has been discussed on several forums, but because I am making a media player and I intend to sell it, I fell the need to ask for a more complete answer.
  As I understand, this is the list with the audio and video formats available in Windows Store Apps : http://msdn.microsoft.com/en-us/library/windows/apps/hh986969.aspx. This are indeed the most used formats for playing audio and video, but I truly fell the lack of support for the .MKV files. So my questions are :

  1. Will Microsoft include .MKV in that list ? When ?
  2. Can I somehow include the .MKV codec in my app ? (or other codecs, like .flv)
  3. If I can't add the MKV codec in my app and Microsoft doesn't intend to add it, is there a way that I can convert the .MKV in , let's say, a .MP4 so that my app can be able to play it ?

  I know that I'm not the first that asks this questions, but I didn't find anywhere a good/complete answer or solution to this problem.

  In my opinion .MKV in pretty popular already. Searching for media players in the Windows Store I found one which claims that it supports .MKV (but only if you buy it, so I didn't try it). So is this possible ? How ?

• 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 Yang

  My 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)