Recherche avancée

Sur d’autres sites (9638)

• FFmpeg concat creating corrupted video part (Media Info provided)

  6 mai 2022, par krv

  I am using concat to join a list of video files with the following command

  


  ffmpeg -f concat -safe 0 -i filesList.txt -c copy output.mp4 


  


  The issue here is that there are a few files that were recorded in slow motion on my phone. The slow-motion files have the same frame rate as the other files.

  


  But when concatenated the part where the slow-motion files are concatenated appears to be frozen / glitch (it does not play a single frame).

  


  I am able to seek forward and backward the part that does not play. So the portion of the video that contained normal files plays and as soon as the slow-motion video comes, nothing plays, and when a normal file comes it starts playing again.

  


  I am attaching the media Info of both files

  


  Info of the slow motion file :

  


  General
Complete name :     I:\concate Test\VID20210727114100.mp4
Format :    MPEG-4
Format profile :    Base Media / Version 2
Codec ID :  mp42 (isom/mp42)
File size :     27.6 MiB
Duration :  1 min 0 s
Overall bit rate :  3 825 kb/s
Encoded date :  UTC 2021-07-27 06:11:08
Tagged date :   UTC 2021-07-27 06:11:08
xyz :   +21.6146+071.2342/
com.android.version :   11

Video
ID :    1
Format :    HEVC
Format/Info :   High Efficiency Video Coding
Format profile :    Main@L3.1@Main
Codec ID :  hvc1
Codec ID/Info :     High Efficiency Video Coding
Duration :  1 min 0 s
Source duration :   1 min 0 s
Bit rate :  3 771 kb/s
Width :     1 280 pixels
Height :    720 pixels
Display aspect ratio :  16:9
Frame rate mode :   Variable
Frame rate :    30.000 FPS
Minimum frame rate :    29.910 FPS
Maximum frame rate :    30.090 FPS
Real frame rate :   240.000 FPS
Color space :   YUV
Chroma subsampling :    4:2:0
Bit depth :     8 bits
Bits/(Pixel*Frame) :    0.136
Stream size :   27.2 MiB (99%)
Source stream size :    27.2 MiB (99%)
Title :     VideoHandle
Language :  English
Encoded date :  UTC 2021-07-27 06:11:08
Tagged date :   UTC 2021-07-27 06:11:08
Color range :   Limited
Color primaries :   BT.709
Transfer characteristics :  BT.709
Matrix coefficients :   BT.709
mdhd_Duration :     60524
Codec configuration box :   hvcC


  


  Info of the regular video file

  


  
General
Complete name :     I:\concate Test\VID20210727113901.mp4
Format :    MPEG-4
Format profile :    Base Media / Version 2
Codec ID :  mp42 (isom/mp42)
File size :     39.0 MiB
Duration :  37 s 930 ms
Overall bit rate :  8 615 kb/s
Encoded date :  UTC 2021-07-27 06:09:40
Tagged date :   UTC 2021-07-27 06:09:40
xyz :   +21.6146+071.2342/
com.android.version :   11

Video
ID :    1
Format :    HEVC
Format/Info :   High Efficiency Video Coding
Format profile :    Main@L4@Main
Codec ID :  hvc1
Codec ID/Info :     High Efficiency Video Coding
Duration :  37 s 930 ms
Source duration :   37 s 900 ms
Bit rate :  8 408 kb/s
Width :     1 920 pixels
Height :    1 080 pixels
Display aspect ratio :  16:9
Frame rate mode :   Variable
Frame rate :    29.604 FPS
Minimum frame rate :    29.508 FPS
Maximum frame rate :    29.605 FPS
Real frame rate :   30.000 FPS
Color space :   YUV
Chroma subsampling :    4:2:0
Bit depth :     8 bits
Bits/(Pixel*Frame) :    0.137
Stream size :   38.0 MiB (98%)
Source stream size :    38.0 MiB (98%)
Title :     VideoHandle
Language :  English
Encoded date :  UTC 2021-07-27 06:09:40
Tagged date :   UTC 2021-07-27 06:09:40
Color range :   Limited
Color primaries :   BT.709
Transfer characteristics :  BT.709
Matrix coefficients :   BT.709
mdhd_Duration :     37930
Codec configuration box :   hvcC

Audio
ID :    2
Format :    AAC LC
Format/Info :   Advanced Audio Codec Low Complexity
Codec ID :  mp4a-40-2
Duration :  37 s 909 ms
Bit rate mode :     Constant
Bit rate :  128 kb/s
Channel(s) :    2 channels
Channel layout :    L R
Sampling rate :     48.0 kHz
Frame rate :    46.875 FPS (1024 SPF)
Compression mode :  Lossy
Stream size :   592 KiB (1%)
Title :     SoundHandle
Language :  English
Encoded date :  UTC 2021-07-27 06:09:40
Tagged date :   UTC 2021-07-27 06:09:40




  


• What exactly is the input to the coder part of a software video codec ?

  30 juin 2022, par usrnew xnew

  I am doing a project based on video codecs and have to implement a specific type of codec(one of the H.26x types). So far in my research, I've found out that mp4 files are simply container files that can contain video data in any coded form. I wanted to know if there is a raw file type for video files like how there are for images and audio. However, I came to find out that there is no standard raw file for a video format and since mp4 is a container, it may as well contain a completely uncompressed video with frames, audio etc.

  


  So basically, if there's no specific standard raw format for a video, what kind of file would the software codec take as input while encoding ? And if it does take an mp4, how do we find out if it's really an uncompressed mp4 file or an already encoded one, i.e. which atom holds the value of encoding name ?

  


  Edit :

  


• avcodec/iff : Split extract_header into extradata and packet part

  11 juillet 2022, par Andreas Rheinhardt

  avcodec/iff : Split extract_header into extradata and packet part
  183132872a1d8bc8a32e7fd8f994fa2f1b2d6bfc made the iff demuxer
  
  output extradata and made the decoder parse said extradata.
  
  To make this extradata extensible, it came with its own internal
  
  length field (containing the offset of the palette at the end
  
  of the extradata). Furthermore, in order to support mid-stream
  
  extradata changes, the packets returned by the demuxer also have
  
  such a length field (containing the offset of the actual packet
  
  data). Therefore the packet parsing the extradata accepted its
  
  input from both AVPackets as well as from ordinary extradata.
  Yet the demuxer never made use of this "feature" : The packet's
  
  length field always indicated that the packet data starts
  
  immediately after the length field.
  Later, commit cb928fc448f9566e6f6c28d53fa4c2388e732a2b stopped
  
  appending the length field to the packets' data ; of course,
  
  it also stopped searching for extradata in this data.
  Instead it added code to parse the packet's header to the function
  
  that parses extradata. This made this function consist of two disjoint
  
  parts, one of which is only reachable if this function is called
  
  from init (when parsing extradata) and one of which is reachable
  
  when parsing packet headers.
  Therefore this commit splits this function into two.
  Signed-off-by : Andreas Rheinhardt <andreas.rheinhardt@outlook.com>
  

  • [DH] libavcodec/iff.c