Recherche avancée

Sur d’autres sites (6362)

• avformat/matroskaenc : Don't ignore tags of chapters written late

  29 avril 2020, par Andreas Rheinhardt

  avformat/matroskaenc : Don't ignore tags of chapters written late
  The Matroska muxer writes the Chapters early when chapters were already
  
  available when writing the header ; in this case any tags pertaining to
  
  these chapters get written, too.
  Yet if no chapters had been supplied before writing the header, Chapters
  
  can also be written when writing the trailer if any are supplied. Tags
  
  belonging to these chapters were up until now completely ignored.
  This commit changes this : Writing the tags belonging to chapters has
  
  been moved to mkv_write_chapters(). If mkv_write_tags() has not been
  
  called yet (i.e. when chapters are written when writing the header),
  
  the AVIOContext for writing the ordinary Tags element is used, but not
  
  output, as this is left to mkv_write_tags() in order to only write one
  
  Tags element. Yet if mkv_write_tags() has already been called,
  
  mkv_write_chapters() will output a Tags element of its own which only
  
  contains the tags for chapters.
  When chapters are available initially, the corresponding tags will now
  
  be the first tags in the Tags element ; but the ordering of tags in Tags
  
  is irrelevant anyway.
  This commit also makes chapter_id_offset local to mkv_write_chapters()
  
  as it is used only there and not reused at all.
  Potentially writing a second Tags element means that the maximum number
  
  of SeekHead entries had to be incremented. All the changes to FATE
  
  result from the ensuing increase in the amount of space reserved for the
  
  SeekHead (21 bytes more).
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@gmail.com>
  

  • [DH] libavformat/matroskaenc.c
  • [DH] tests/fate/matroska.mak
  • [DH] tests/fate/wavpack.mak
  • [DH] tests/ref/fate/aac-autobsf-adtstoasc
  • [DH] tests/ref/fate/binsub-mksenc
  • [DH] tests/ref/fate/matroska-flac-extradata-update
  • [DH] tests/ref/fate/rgb24-mkv
  • [DH] tests/ref/fate/webm-dash-chapters
  • [DH] tests/ref/lavf-fate/av1.mkv
  • [DH] tests/ref/lavf/mka
  • [DH] tests/ref/lavf/mkv
  • [DH] tests/ref/lavf/mkv_attachment
  • [DH] tests/ref/seek/lavf-mkv

• ffmpeg still fails if captured late in the video

  15 décembre 2020, par pherris

  I have a video clip that is 12.035177s long. When I attempt to take a still of one frame it fails :

  


  command :

  


  ffmpeg -loglevel debug -ss 00:00:08.1 -accurate_seek -i ./25e13b0b-d2e6-426a-920b-6bb2445a1324-original.ps -y -frames:v 1 ./test9-before.jpg


  


  error :

  


  


  Output file is empty, nothing was encoded (check -ss / -t / -frames parameters if used)

  


  


  However, if I take the still from slightly earlier in the clip it works (note 8.0 in the working example vs 8.1 in the failing example) :

  


  ffmpeg -loglevel debug -ss 00:00:08.0 -accurate_seek -i ./25e13b0b-d2e6-426a-920b-6bb2445a1324-original.ps -y -frames:v 1 ./test9-before.jpg


  


  Additionally, if I move the -ss to after -i (the output buffer) with the failing command above, it also works.

  


  Comparing a diff of the debug output of the working vs non-working I see these lines in the failing example :

  


  


  [h264 @ 0x7fbc3a01c200] Frame num gap 15 13

  


  


  these lines (or something similar) is present much more often :

  


  


  cur_dts is invalid st:0 (0) [init:0 i_done:0 finish:0] (this is harmless if it occurs once at the start per stream)

  


  


  


  168 [h264 @ 0x7fbc3a01c200] nal_unit_type : 1(Coded slice of a non-IDR picture), nal_ref_idc : 2

  


  


  this is also present in the failing example :

  


  


  [out_0_0 @ 0x7fbc3c6053c0] EOF on sink link out_0_0:default.

  


  


  In the succeeding example, I see this line which is not present in the failing example :

  


  


  7 Clipping frame in rate conversion by 0.000008
  
n
138 [image2 @ 0x7fba2f812000] Opening './test9-before.jpg' for writing
  
139 [file @ 0x7fba30130000] Setting default whitelist 'file,crypto,data'
  
140 [AVIOContext @ 0x7fba2e611b00] Statistics : 0 seeks, 2 writeouts

  


  


  

  


• avcodec/pixblockdsp : Improve 8 vs 16 bit check

  27 mai, par Andreas Rheinhardt

  avcodec/pixblockdsp : Improve 8 vs 16 bit check
  Before this commit, the input in get_pixels and get_pixels_unaligned
  
  has been treated inconsistenly :
  
   The generic code treated 9, 10, 12 and 14 bits as 16bit input
  
  (these bits correspond to what FFmpeg's dsputils supported),
  
  everything with <= 8 bits as 8 bit and everything else as 8 bit
  
  when used via AVDCT (which exposes these functions and purports
  
  to support up to 14 bits).
  
   AARCH64, ARM, PPC and RISC-V, x86 ignore this AVDCT special case.
  
   RISC-V also ignored the restriction to 9, 10, 12 and 14 for its
  
  16bit check and treated everything > 8 bits as 16bit.
  
   The mmi MIPS code treats everything as 8 bit when used via
  
  AVDCT (this is certainly broken) ; otherwise it checks for <= 8 bits.
  
  The msa MIPS code behaves like the generic code.
  This commit changes this to treat 9..16 bits as 16 bit input,
  
  everything else as 8 bit (the former because it makes sense,
  
  the latter to preserve the behaviour for external users*).
  * : The only internal user of AVDCT (the spp filter) always
  
  uses 8, 9 or 10 bits.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/aarch64/pixblockdsp_init_aarch64.c
  • [DH] libavcodec/arm/pixblockdsp_init_arm.c
  • [DH] libavcodec/mips/pixblockdsp_init_mips.c
  • [DH] libavcodec/pixblockdsp.c
  • [DH] libavcodec/pixblockdsp.h
  • [DH] libavcodec/ppc/pixblockdsp.c
  • [DH] libavcodec/riscv/pixblockdsp_init.c
  • [DH] libavcodec/x86/pixblockdsp_init.c