Recherche avancée

Sur d’autres sites (12963)

• movenc : Allow writing timed ID3 metadata

  17 janvier 2024, par Martin Storsjö

  movenc : Allow writing timed ID3 metadata
  This is based on a spec at https://aomediacodec.github.io/id3-emsg/,
  
  further based on ISO/IEC 23009-1:2019.
  Within libavformat, timed ID3 metadata (already supported by the
  
  mpegts demuxer and muxer) is handled as a separate data AVStream
  
  with codec type AV_CODEC_ID_TIMED_ID3. However, it doesn't
  
  have a corresponding track in the mov file - instead, these events
  
  are written as separate toplevel 'emsg' boxes.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DH] libavformat/movenc.c
  • [DH] libavformat/tests/movenc.c
  • [DH] tests/ref/fate/movenc

• lavf/matroskaenc : Check for valid metadata before creating tags

  17 juillet 2013, par James Almer

  lavf/matroskaenc : Check for valid metadata before creating tags
  Tags must have at least one SimpleTag element to be spec conformant.
  
  Updated lavf-mkv and seek-lavf-mkv FATE references as the tests were affected by
  
  this.
  Fixes ticket #2785
  Signed-off-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michaelni@gmx.at>
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/ref/lavf/mkv
  • [DH] tests/ref/seek/lavf-mkv

• HTML5 Progressive Streaming — no follow-up range requests

  20 septembre 2023, par user2333829

  I'm working on an embedded device that is recording video on the fly. I'd like to stream that to an HTML5 video element, using our own custom server. I have this almost working and would like some help.

  



  So far as I can tell, I've got libav / ffmpeg doing their job right. I encoded an mp4 in RAM with the moov atom at the start of the file. I've written this file to disk and it plays everywhere it should.

  



  The problem, I think, lies with how I'm responding to HTTP range requests. When I try to do a live stream, I get an initial range request from the browser / player (currently tried Chrome, Firefox, and VLC) for bytes:0-. I responded with some initial bytes. The browser / player actually plays this fine, but never asks again. So the live stream doesn't work, just the first 3 seconds or whatever.

  



  I've looked at the RFC spec of partial content, and my understanding is I'm doing what I should be... Clearly I'm not though. Here is an example of a request / response with Chrome as the requester :

  



  ---

  



  
get /live.mp4 HTTP/1.1
host: localhost:1235
connection: keep-alive
accept-encoding: identity;q=1, *;q=0
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.167 Safari/537.36
accept: */*
dnt: 1
accept-language: en-GB,en-US;q=0.9,en;q=0.8
range: bytes=0-


  



  
HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Type: video/mp4
Content-Length: 182400
Content-Range: bytes 0-182399/*


  



  ---

  



  Again, with that request / response pair, Chrome plays the first 182400 bytes but never makes a second request. I thought having the '*' in Content-Range would make this happen...