Recherche avancée

Sur d’autres sites (3870)

• avcodec/h26[45]_metadata_bsf : Use separate contexts for reading/writing

  6 juillet 2020, par Andreas Rheinhardt

  avcodec/h26[45]_metadata_bsf : Use separate contexts for reading/writing
  Currently, both bsfs used the same CodedBitstreamContext for reading and
  
  writing ; as a consequence, the state of the writer's context at the
  
  beginning of writing a fragment is exactly the state of the reader after
  
  having read the fragment ; in particular, the writer might not have
  
  encountered one of its active parameter sets yet.
  This is not nice and may lead to invalid output even when the input
  
  is completely spec-compliant : Think of an access unit containing
  
  a primary coded picture referencing a PPS with id id (that is known from
  
  an earlier access unit/from extradata), then a new version of the PPS
  
  with id id and then a redundant coded picture that is also referencing
  
  the PPS with id id. This is spec-compliant, as the standard allows to
  
  overwrite a PPS with a different PPS in between coded pictures and not
  
  only at the beginning of an access unit. In this scenario, the reader
  
  would read the primary coded picture with the old PPS and the redundant
  
  coded picture with the new PPS (as it should) ; yet the writer would
  
  write both with the new PPS as extradata which might lead to errors or
  
  to invalid data being output without any error (e.g. if the two PPS
  
  differed in redundant_pic_cnt_present_flag).
  The above scenario does not directly translate to HEVC as long as one
  
  restricts oneself to input with nuh_layer_id == 0 only (as cbs_h265
  
  does : it currently strips away any NAL unit with nuh_layer_id > 0 when
  
  decomposing) ; if one doesn't the same issue as above can happen.
  If one also allowed input packets to contain more than one access unit,
  
  issues like the above can happen even without redundant coded
  
  pictures/multiple layers.
  Therefore this commit uses separate contexts for reader and writer.
  Reviewed-by : Mark Thompson <sw@jkqxz.net>
  
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavcodec/h264_metadata_bsf.c
  • [DH] libavcodec/h265_metadata_bsf.c

• Ffmpeg video conversion for minidlna running on openwrt

  9 juin 2017, par user2977753

  im very close to have my media server running on openwrt in a extrooted tplink.

  So far everything is good but can not get all my video files exposed.
  After doing some research I noticed that I need specific video parameters (codec , size , etc) to get it to work.

  Any one can help me to go from this video settings :

  Stream #0:0(und) : Video : h264 (Main) (avc1 / 0x31637661), yuv420p,
  1280x720 [SAR 1:1 DAR 16:9], 2088 kb/s, 25 fps, 25 tbr, 90k tbn, 50
  tbc (default)

  To this :

  Stream #0:0(und) : Video : h264 (Constrained Baseline) (avc1 /
  0x31637661), yuv420p, 640x360 [SAR 1:1 DAR 16:9], 620 kb/s, 29.97 fps,
  29.97 tbr, 30k tbn, 59.94 tbc (default)

  Last format is the one I know is working.

• ffprobe/ffmpeg detect when video is unplayable

  8 mars 2018, par Philip Tenn

  We are calling ffpmeg 2.6.8 through Java to convert different video formats to MP4.

  Is there a way to detect that the resulting MP4 video will be unplayable ?

  We’ve explored :

  • stderr. Unfortunately ffmpeg is writing all diagnostic information to stderr.
  • -xerror. I tried it on a file and it stopped converting, but when I tried without this switch, it converted and I could play the resulting MP4 file.
  • exit code. From reading various forums, it sounds like 0 is success, 1 is error, and there are other codes, but that this isn’t completely reliable (we could get an exit code of 0 and video still unplayable).

  Has anyone faced a similar need ? Just looking for ideas/suggestions that I could research and explore. Thanks !