Recherche avancée

Sur d’autres sites (9047)

• avcodec/mjpegenc : support writing ICC profiles

  10 mars 2022, par Niklas Haas

  avcodec/mjpegenc : support writing ICC profiles
  This is mostly straightforward. The major complication is that, as a
  
  result of the 16-bit chunk size limitation, ICC profiles may need to be
  
  split up into multiple chunks.
  We also need to make sure to allocate enough extra space in the packet
  
  to fit the ICC profile, so modify both mpegvideo_enc.c and ljpegenc.c to
  
  take into account this extra overhead, failing cleanly if necessary.
  Also add a FATE transcode test to ensure that the ICC profile gets
  
  written (and read) correctly. Note that this ICC profile is smaller than
  
  64 kB, so this doesn't test the APP2 chunk re-arranging code at all.
  Signed-off-by : Niklas Haas <git@haasn.dev>
  

  • [DH] libavcodec/ljpegenc.c
  • [DH] libavcodec/mjpegenc.c
  • [DH] libavcodec/mjpegenc_common.c
  • [DH] libavcodec/mjpegenc_common.h
  • [DH] libavcodec/mpegvideo_enc.c
  • [DH] tests/fate/image.mak
  • [DH] tests/ref/fate/jpg-icc

• lavfi : add a new filtergraph parsing API

  16 janvier 2023, par Anton Khirnov

  lavfi : add a new filtergraph parsing API
  Callers currently have two ways of adding filters to a graph - they can
  
  either
  
   create, initialize, and link them manually
  
   use one of the avfilter_graph_parse*() functions, which take a
  
    (typically end-user-written) string, split it into individual filter
  
    definitions+options, then create filters, apply options, initialize
  
    filters, and finally link them - all based on information from this
  
    string.
  A major problem with the second approach is that it performs many
  
  actions as a single atomic unit, leaving the caller no space to
  
  intervene in between. Such intervention would be useful e.g. to
  
   modify filter options ;
  
   supply hardware device contexts ;
  
  both of which typically must be done before the filter is initialized.
  Callers who need such intervention are then forced to invent their own
  
  filtergraph parsing, which is clearly suboptimal.
  This commit aims to address this problem by adding a new modular
  
  filtergraph parsing API. It adds a new  avfilter_graph_segment_parse()
  
  function to parse a string filtergraph description into an intermediate
  
  tree-like representation (AVFilterGraphSegment and its children).
  This intermediate form may then be applied step by step using further
  
  new avfilter_graph_segment*() functions, with user intervention possible
  
  between each step.
  

  • [DH] doc/APIchanges
  • [DH] libavfilter/avfilter.h
  • [DH] libavfilter/graphparser.c
  • [DH] libavfilter/version.h

• FFMPEG frames are choppy when piping images to mp4

  15 décembre 2020, par Michael Joseph Aubry

  I'm working to optimize my rendering technique, it has some noticeable frame drops here and there. It's hard to tell, if you take a look at this recording you will see what I mean https://share.getcloudapp.com/6quxYe5O

  


  My technique involves hardcoding a default FPS to be 25 and to use that to take a screenshot of the video every (25 / 1000) = 0.4 ms inside a Chrome instance.

  


  When I run ffmpeg -i ORIGINAL_VIDEO I get this output

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'https://s3.us-west-1.amazonaws.com/storycreator.clips/e7d87660-51a8-11ea-a753-8f195b459e44':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.29.100
  Duration: 00:00:20.36, start: 0.000000, bitrate: 6095 kb/s
    Stream #0:0(und): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1920x1080 [SAR 1:1 DAR 16:9], 6092 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : L-SMASH Video Handler


  


  When I run it on the newly made video from the screenshots here is the ffmpeg output.

  


  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'https://s3.us-west-2.amazonaws.com/storycreator.testing/4aa5e5c0-3e89-11eb-a8b5-a38609fab693.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf58.29.100
  Duration: 00:00:15.04, start: 0.000000, bitrate: 4775 kb/s
    Stream #0:0(und): Audio: aac (LC) (mp4a / 0x6134706D), 16000 Hz, stereo, fltp, 83 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
    Stream #0:1(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1080x1080 [SAR 1:1 DAR 1:1], 4698 kb/s, 25 fps, 25 tbr, 12800 tbn, 50 tbc (default)
    Metadata:
      handler_name    : VideoHandler


  


  Some slight differences. You can see the bitrate drops from 6095 to 4775. You will also notice audio was attached in the new one. The video size changed — this was intentional.

  


  You also notice it go from 6092 kb/s to 4698 kb/s not sure what that means, open to clarification. Another change before that is [SAR 1:1 DAR 16:9] to [SAR 1:1 DAR 1:1] not sure what that is.

  


  The last major difference I notice is handler_name    : L-SMASH Video Handler to handler_name    : VideoHandler. Very curious about those properties as a learning bit.

  


  Not sure out of those changes which one is the most important for smooth playback like the original. I assume its bitrate.