Recherche avancée

Sur d’autres sites (11978)

• avformat/rtsp : Send mode=record instead of mode=receive in Transport header

  15 janvier 2024, par Paul Orlyk

  avformat/rtsp : Send mode=record instead of mode=receive in Transport header
  Fixes server compatibility issues with rtspclientsink GStreamer plugin.
  >From specification :
  
  RFC 7826 "Real-Time Streaming Protocol Version 2.0" (https://datatracker.ietf.org/doc/html/rfc7826), section 18.54 :
  
     mode : The mode parameter indicates the methods to be supported for
  
           this session.  The currently defined valid value is "PLAY".  If
  
           not provided, the default is "PLAY".  The "RECORD" value was
  
           defined in RFC 2326 ; in this specification, it is unspecified
  
           but reserved.  RECORD and other values may be specified in the
  
           future.
  
  RFC 2326 "Real Time Streaming Protocol (RTSP)" (https://datatracker.ietf.org/doc/html/rfc2326), section 12.39 :
  
     mode :
  
            The mode parameter indicates the methods to be supported for
  
            this session. Valid values are PLAY and RECORD. If not
  
            provided, the default is PLAY.
  mode=receive was always like this, from the initial commit 'a8ad6ffa rtsp : Add listen mode'.
  For comparison, Wowza was used to push RTSP stream to. Both GStreamer and FFmpeg had no issues.
  
  Here is the capture of Wowza responding to SETUP request :
  
  200 OK
  
  CSeq : 3
  
  Server : Wowza Streaming Engine 4.8.26+4 build20231212155517
  
  Cache-Control : no-cache
  
  Expires : Mon, 15 Jan 2024 19:40:31 GMT
  
  Transport : RTP/AVP/UDP ;unicast ;client_port=11640-11641 ;mode=record ;source=172.17.0.2 ;server_port=6976-6977
  
  Date : Mon, 15 Jan 2024 19:40:31 GMT
  
  Session : 1401457689 ;timeout=60
  Test setup :
  
      Server : ffmpeg -loglevel trace -y -rtsp_flags listen -i rtsp ://0.0.0.0:30800/live.stream t.mp4
  
      FFmpeg client : ffmpeg -re -i "Big Buck Bunny - FULL HD 30FPS.mp4" -c:v libx264 -f rtsp rtsp ://127.0.0.1:30800/live.stream
  
      GStreamer client : gst-launch-1.0 videotestsrc is-live=true pattern=smpte ! queue ! videorate ! videoscale ! video/x-raw,width=640,height=360,framerate=60/1 ! timeoverlay font-desc="Sans, 84" halignment=center valignment=center ! queue ! videoconvert ! tee name=t t. ! x264enc bitrate=9000 pass=cbr speed-preset=ultrafast byte-stream=false key-int-max=15 threads=1 ! video/x-h264,profile=baseline ! queue ! rsink. audiotestsrc ! voaacenc ! queue ! rsink. t. ! queue ! autovideosink rtspclientsink name=rsink location=rtsp ://localhost:30800/live.stream
  Test results :
  
  modified FFmpeg client -> stock server : ok
  
  stock FFmpeg client    -> modified server : ok
  
  modified FFmpeg client -> modified server : ok
  
  GStreamer client       -> modified server : ok
  Signed-off-by : Paul Orlyk <paul.orlyk@gmail.com>
  
  Signed-off-by : Michael Niedermayer <michael@niedermayer.cc>
  

  • [DH] libavformat/rtspdec.c

• h264 lossless coding

  19 juillet 2022, par cloudraven

  Is it possible to do completely lossless encoding in h264 ? By lossless, I mean that if I feed it a series of frames and encode them, and then if I extract all the frames from the encoded video, I will get the exact same frames as in the input, pixel by pixel, frame by frame. Is that actually possible ?
Take this example :

  



  I generate a bunch of frames, then I encode the image sequence to an uncompressed AVI (with something like virtualdub), I then apply lossless h264 (the help files claim that setting —qp 0 makes lossless compression, but I am not sure if that means that there is no loss at any point of the process or that just the quantization is lossless). I can then extract the frames from the resulting h264 video with something like mplayer.

  



  I tried with Handbrake first, but it turns out it doesn't support lossless encoding. I tried x264 but it crashes. It may be because my source AVI file is in RGB colorspace instead of YV12. I don't know how to feed a series of YV12 bitmaps and in what format to x264 anyway, so I cannot even try.

  



  In summary what I want to know if that is there a way to go from

  



  Series of lossless bitmaps (in any colorspace) -> some transformation -> h264 encode -> h264 decode -> some transformation -> the original series of lossless bitmaps

  



  If there a way to achieve this ?

  



  EDIT : There is a VERY valid point about lossless H264 not making too much sense. I am well aware that there is no way I could tell (with just my eyes) the difference between and uncompressed clip and another compressed at a high rate in H264, but I don't think it is not without uses. For example, it may be useful for storing video for editing without taking huge amounts of space and not losing quality and spending too much encoding time every time the file is saved.

  



  UPDATE 2 : Now x264 doesn't crash. I can use as sources either avisynth or lossless yv12 lagarith (to avoid the colorspace compression warning). Howerver, even with —qp 0 and a rgb or yv12 source I still get some differences, minimal but present. This is troubling, because all the information I have found on lossless predictive coding (—qp 0) claims that the whole encoding should be lossless, but I am unable to verifiy this.

  


• h264 lossless coding

  29 septembre 2014, par cloudraven

  Is it possible to do completely lossless encoding in h264 ? By lossless, I mean that if I feed it a series of frames and encode them, and then if I extract all the frames from the encoded video, I will get the exact same frames as in the input, pixel by pixel, frame by frame. Is that actually possible ?
  Take this example :

  I generate a bunch of frames, then I encode the image sequence to an uncompressed AVI (with something like virtualdub), I then apply lossless h264 (the help files claim that setting —qp 0 makes lossless compression, but I am not sure if that means that there is no loss at any point of the process or that just the quantization is lossless). I can then extract the frames from the resulting h264 video with something like mplayer.

  I tried with Handbrake first, but it turns out it doesn’t support lossless encoding. I tried x264 but it crashes. It may be because my source AVI file is in RGB colorspace instead of YV12. I don’t know how to feed a series of YV12 bitmaps and in what format to x264 anyway, so I cannot even try.

  In summary what I want to know if that is there a way to go from

  Series of lossless bitmaps (in any colorspace) -> some transformation -> h264 encode -> h264 decode -> some transformation -> the original series of lossless bitmaps

  If there a way to achieve this ?

  EDIT : There is a VERY valid point about lossless H264 not making too much sense. I am well aware that there is no way I could tell (with just my eyes) the difference between and uncompressed clip and another compressed at a high rate in H264, but I don’t think it is not without uses. For example, it may be useful for storing video for editing without taking huge amounts of space and not losing quality and spending too much encoding time every time the file is saved.

  UPDATE 2 : Now x264 doesn’t crash. I can use as sources either avisynth or lossless yv12 lagarith (to avoid the colorspace compression warning). Howerver, even with —qp 0 and a rgb or yv12 source I still get some differences, minimal but present. This is troubling, because all the information I have found on lossless predictive coding (—qp 0) claims that the whole encoding should be lossless, but I am unable to verifiy this.