Recherche avancée

Sur d’autres sites (4459)

• avcodec/h264dec : apply H.274 film grain

  17 août 2021, par Niklas Haas

  avcodec/h264dec : apply H.274 film grain
  Because we need access to ref frames without film grain applied, we have
  
  to add an extra AVFrame to H264Picture to avoid messing with the
  
  original. This requires some amount of overhead to make the reference
  
  moves work out, but it allows us to benefit from frame multithreading
  
  for film grain application "for free".
  Unfortunately, this approach requires twice as much RAM to be constantly
  
  allocated for ref frames, due to the need for an extra buffer per
  
  H264Picture. In theory, we could get away with freeing up this memory as
  
  soon as it's no longer needed (since ref frames do not need film grain
  
  buffers any longer), but trying to call ff_thread_release_buffer() from
  
  output_frame() conflicts with possible later accesses to that same frame
  
  and I'm not sure how to synchronize that well.
  Tested on all three cases of (no fg), (fg present but exported) and (fg
  
  present and not exported), with and without threading.
  Co-authored-by : James Almer <jamrial@gmail.com>
  
  Signed-off-by : Niklas Haas <git@haasn.dev>
  
  Signed-off-by : James Almer <jamrial@gmail.com>
  

  • [DH] libavcodec/h264_picture.c
  • [DH] libavcodec/h264_slice.c
  • [DH] libavcodec/h264dec.c
  • [DH] libavcodec/h264dec.h

• avformat/electronicarts : add option to return alpha channel in the main video stream...

  13 novembre 2022, par Marton Balint

  avformat/electronicarts : add option to return alpha channel in the main video stream in VP6A codec
  VP6 alpha in EA format is a second VP6 encoded video stream where only the Y
  
  component is used and is interpreted as the alpha channel of the first VP6
  
  stream. The alpha VP6 stream is muxed separately from the main VP6 stream, has
  
  its own stream headers and packet headers. In theory the two streams might not
  
  even have the same resolution (although most likely that is not something that
  
  is seen or supported in the wild), but the format is capable of doing it.
  Merged VP6 alpha (also known as the VP6A codec) means that a packet of the
  
  video stream contains the corresponding packet of both VP6 substreams like
  
  this :
  OffsetOfAlpha, DataPacket, AlphaDataPacket
  So data and alpha data of a frame is merged to a single packet, this is how VP6
  
  video with alpha is muxed in FLV and SWF.
  The first approach is more like how the demuxer sees data in the EA format,
  
  unfortunately it is different to what the FLV or SWF format expects, so -
  
  having no better place for it in the framework - I decided to do an optional
  
  format conversion in the EA demuxer.
  Signed-off-by : Marton Balint <cus@passwd.hu>
  

  • [DH] doc/demuxers.texi
  • [DH] libavformat/electronicarts.c
  • [DH] libavformat/version.h

• gstreamer cant demux a .ts video but ffmpeg can. How can I fix the error ?

  8 octobre 2024, par Zack

  I have a .ts video that when I run through a basic gstreamer pipeline I get an error that it can't demux the video.

  


  comand :

  


  gst-launch-1.0 filesrc location="/videos/my_video.ts" ! tsdemux ! meta/x-klv ! fakesink


  


  I get the error :

  


  Setting pipeline to PAUSED ...
Pipeline is PREROLLING ...
WARNING: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Delayed linking failed.
Additional debug info:
gst/parse/grammar.y(853): gst_parse_no_more_pads (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
failed delayed linking some pad of GstTSDemux named tsdemux0 to some pad of GstFakeSink named fakesink0
ERROR: from element /GstPipeline:pipeline0/GstTSDemux:tsdemux0: Internal data stream error.
Additional debug info:
../gst/mpegtsdemux/mpegtsbase.c(1759): mpegts_base_loop (): /GstPipeline:pipeline0/GstTSDemux:tsdemux0:
streaming stopped, reason not-linked (-1)
ERROR: pipeline doesn't want to preroll.
Setting pipeline to NULL ...
Freeing pipeline ...


  


  When I run the same video through ffmpeg :

  


  ffmpeg -i /video/my_video.ts -map data-re -codec copy -f data


  


  I get out :

  


    Duration: 00:29:56.49, start: 1920.682267, bitrate: 1873 kb/s
  Program 1 
  Stream #0:0[0x21]: Video: h264 (High) ([27][0][0][0] / 0x001B), yuv420p(progressive), 1280x720 [SAR 1:1 DAR 16:9], 29.97 fps, 29.97 tbr, 90k tbn
  Stream #0:1[0x28]: Data: klv (KLVA / 0x41564C4B)


  


  I've also been successful in extracting that klv data using ffmpeg to a .bin file and analyzing the klv data within it.

  


  Though when the ffmpeg command runs it does also give me this error initially :

  


  Last message repeated 1 times
[h264 @ 0x15d004590] decode_slice_header error
[h264 @ 0x15d004590] no frame!
[h264 @ 0x15d004590] non-existing PPS 0 referenced


  


  Which prints out many times before producing the results. My understanding/theory is that the video is missing some keyframe data in the beginning and/or the start has a compression error of some kind, but thats just my guess. Whatever the problem is, ffmpeg is able to handle it but gstreamer is not.

  


  Is there anything I can do to the video or within gstreamer to handle what the error might be ? Is there any other tests that I can do on the video itself that would point to some other causes ?