Recherche avancée

Sur d’autres sites (4782)

• Revision d35df2d8ea : High-level hooks for Profile 2 (10/12 bit) Adds some high-level hooks for profi

  5 avril 2014, par Deb Mukherjee

  Changed Paths :
   Modify /vp9/common/vp9_enums.h

  
   Modify /vp9/common/vp9_onyxc_int.h

  
   Modify /vp9/decoder/vp9_decodeframe.c

  
   Modify /vp9/encoder/vp9_bitstream.c

  
   Modify /vp9/encoder/vp9_onyx_if.c

  
   Modify /vp9/encoder/vp9_onyx_int.h

  
   Modify /vp9/vp9_cx_iface.c

  
  
  High-level hooks for Profile 2 (10/12 bit)

  Adds some high-level hooks for profile 2 before further
  progress on the implementation.

  According to the definitiion in this patch :
  1. Profile 2 only supports 10 or 12 bit color but not 8
  2. Profile 2 supports all color sampling modes : 444, 422 and 420,
  and alpha plane.
  3. Profile 3 is currently undefined.

  Please consider the definition carefully and suggest modifications
  to the definition as needed.

  Change-Id : I5b284fc679e54ac5aee171af72fa7994cfd28995

• rtpdec : Don’t free the payload context in the .free function

  24 février 2015, par Martin Storsjö

  rtpdec : Don’t free the payload context in the .free function
  This makes it more consistent with depacketizers that don’t have any
  
  .free function at all, where the payload context is freed by the
  
  surrounding framework. Always free the context in the surrounding
  
  framework, having the individual depacketizers only free any data
  
  they’ve specifically allocated themselves.
  This is similar to how this works for demuxer/muxers/codecs - a
  
  component shouldn’t free the priv_data that the framework has
  
  allocated for it.
  Signed-off-by : Martin Storsjö <martin@martin.st>
  

  • [DBH] libavformat/rdt.c
  • [DBH] libavformat/rtpdec.h
  • [DBH] libavformat/rtpdec_ac3.c
  • [DBH] libavformat/rtpdec_dv.c
  • [DBH] libavformat/rtpdec_h261.c
  • [DBH] libavformat/rtpdec_h263_rfc2190.c
  • [DBH] libavformat/rtpdec_h264.c
  • [DBH] libavformat/rtpdec_jpeg.c
  • [DBH] libavformat/rtpdec_latm.c
  • [DBH] libavformat/rtpdec_mpa_robust.c
  • [DBH] libavformat/rtpdec_mpeg4.c
  • [DBH] libavformat/rtpdec_mpegts.c
  • [DBH] libavformat/rtpdec_qt.c
  • [DBH] libavformat/rtpdec_svq3.c
  • [DBH] libavformat/rtpdec_vp8.c
  • [DBH] libavformat/rtpdec_xiph.c
  • [DBH] libavformat/rtsp.c

• How to record playable video files in gstreamer even if recording is interrupted unexpectedly (e.g. power disconnects) ?

  16 septembre 2021, par Otter_warrior

  I have been recording video streams on my Jetson Xavier NX using a simple gstreamer pipeline such as this

  


  gst-launch-1.0 -v \
nvarguscamerasrc sensor-id=0 ! \
'video/x-raw(memory:NVMM), width=(int)1920, height=(int)1080, format=(string)NV12, framerate=(fraction)30/1' ! \
nvv4l2h265enc ! 'video/x-h265, stream-format=(string)byte-stream' ! \
h265parse ! qtmux ! filesink location=video.mp4 -e


  


  All is working if the recording is interrupted by keyboard interrupt Ctrl + C, but if the recording is interrupted unexpectedly (e.g. power gets disconnected) the resulting file has no playable stream, even if the file size is correct.

  


  I know that mp4 recording needs to be stopped properly otherwise it won't have the necessary information at the end of the file, but I was wondering if there was any other gstreamer pipelines or final file formats that would allow for an H265 encoded video file to be playable even if the recording is ended unexpectedly.

  


  It would be good even if the recorded file needed to be converted before being playable (e.g. with ffmpeg), as long as the information can be recovered without having to go through non-free mp4 recovery tools.