Recherche avancée

Sur d’autres sites (14703)

• mov : use tkhd enabled flag to set the default track

  22 août 2013, par John Stebbins

  mov : use tkhd enabled flag to set the default track
  Signed-off-by : Anton Khirnov <anton@khirnov.net>
  

  • [DH] libavformat/isom.h
  • [DH] libavformat/mov.c

• Problem accessing audio track from mp4 file

  20 décembre 2019, par Thomas Spycher

  For a TV Project we want to transcode the source videofiles to other formats. The Sourcefiles are fragmented mp4 files. Destination format could be mp4 or any other format.
  The sourcefile contains multiple audio tracks for different codes (aac, eac3, aac-otherlanguage).

  Something with this files is odd. I can play them without problems on quicktime or VLC. Import them into Premiere for example ends up with the video but without sound.

  Converting them on AWS MediaConvert results in weird issues as well like (depending on the settings) :

  • No audio frames decoded on [selector-(Audio Selector 1)-track-1-drc] (selecting aac audiotrack (Track:1))
  • Decoder : [Dolby decoder error : failed to configure to stream in first 100 frames] (selecting eac3 audiotrack (Track:2) )

  I’m able to convert the files with Handbreak and the result is a MP4 file with one audiotrack which is working everywhere. I’m trying to figure out whats odd with this file to make them working with AWS MediaConvert.

  Here is the ffprobe output of one of the files :

  ffprobe version 4.1 Copyright (c) 2007-2018 the FFmpeg developers
  
    built with Apple LLVM version 10.0.0 (clang-1000.10.44.4)
  
    configuration: --prefix=/usr/local/Cellar/ffmpeg/4.1 --enable-shared --enable-pthreads --enable-version3 --enable-hardcoded-tables --enable-avresample --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gpl --enable-libmp3lame --enable-libopus --enable-libsnappy --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-libx265 --enable-libxvid --enable-lzma --enable-libfreetype --enable-opencl --enable-videotoolbox
  
    libavutil      56. 22.100 / 56. 22.100
  
    libavcodec     58. 35.100 / 58. 35.100
  
    libavformat    58. 20.100 / 58. 20.100
  
    libavdevice    58.  5.100 / 58.  5.100
  
    libavfilter     7. 40.101 /  7. 40.101
  
    libavresample   4.  0.  0 /  4.  0.  0
  
    libswscale      5.  3.100 /  5.  3.100
  
    libswresample   3.  3.100 /  3.  3.100
  
    libpostproc    55.  3.100 / 55.  3.100
  
  Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '123893.mp4':
  
    Metadata:
  
      major_brand     : mp42
  
      minor_version   : 0
  
      compatible_brands: mp42isomiso2iso5dashavc1dby1mp41
  
    Duration: 00:01:24.02, start: 0.000000, bitrate: 5600 kb/s
  
      Stream #0:0(deu): Video: h264 (Main) (avc1 / 0x31637661), yuv420p, 1280x720 [SAR 1:1 DAR 16:9], 4869 kb/s, 50 fps, 50 tbr, 1k tbn, 100 tbc (default)
  
      Metadata:
  
        handler_name    : VideoHandler
  
      Stream #0:1(deu): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 127 kb/s (default)
  
      Metadata:
  
        handler_name    : SoundHandler
  
      Stream #0:2(deu): Audio: eac3 (ec-3 / 0x332D6365), 48000 Hz, 5.1(side), fltp, 256 kb/s
  
      Metadata:
  
        handler_name    : SoundHandler
  
      Side data:
  
        audio service type: main

  An example file can get downloaded here : https://wilmaa-rnd.s3-eu-west-1.amazonaws.com/124041.mp4

• Does a track run in a fragmented MP4 have to start with a key frame ?

  18 janvier 2021, par stevendesu

  I'm ingesting an RTMP stream and converting it to a fragmented MP4 file in JavaScript. It took a week of work but I'm almost finished with this task. I'm generating a valid ftyp atom, moov atom, and moof atom and the first frame of the video actually plays (with audio) before it goes into an infinite buffering with no errors listed in chrome://media-internals

  



  Plugging the video into ffprobe, I get an error similar to :

  



  [mov,mp4,m4a,3gp,3g2,mj2 @ 0x558559198080] Failed to add index entry
    Last message repeated 368 times
[h264 @ 0x55855919b300] Invalid NAL unit size (-619501801 > 966).
[h264 @ 0x55855919b300] Error splitting the input into NAL units.


  



  This led me on a massive hunt for data alignment issues or invalid byte offsets in my tfhd and trun atoms, however no matter where I looked or how I sliced the data, I couldn't find any problems in the moof atom.

  



  I then took the original FLV file and converted it to an MP4 in ffmpeg with the following command :

  



  ffmpeg -i ~/Videos/rtmp/big_buck_bunny.flv -c copy -ss 5 -t 10 -movflags frag_keyframe+empty_moov+faststart test.mp4


  



  I opened both the MP4 I was creating and the MP4 output by ffmpeg in an atom parsing file and compared the two :

  



  

  



  The first thing that jumped out at me was the ffmpeg-generated file has multiple video samples per moof. Specifically, every moof started with 1 key frame, then contained all difference frames until the next key frame (which was used as the start of the following moof atom)

  



  Contrast this with how I'm generating my MP4. I create a moof atom every time an FLV VIDEODATA packet arrives. This means my moof may not contain a key frame (and usually doesn't)

  



  Could this be why I'm having trouble ? Or is there something else I'm missing ?

  



  The video files in question can be downloaded here :

  



  

  • ffmpeg-generated file : test.mp4

  


  • manually-generated file : invalid-nal-size.mp4

  


  



  Another issue I noticed was ffmpeg's prolific use of base_data_offset in the tfhd atom. However when I tried tracking the total number of bytes appended and setting the base_data_offset myself, I got an error in Chrome along the lines of : "MSE doesn't support base_data_offset". Per the ISO/IEC 14996-10 spec :

  



  


  If not provided, the base-data-offset for the first track in the movie fragment is the position of the first byte of the enclosing Movie Fragment Box, and for second and subsequent track fragments, the default is the end of the data defined by the preceding fragment.

  


  



  This wording leads me to believe that the data_offset in the first trun atom should be equal to the size of the moof atom and the data_offset in the second trun atom should be 0 (0 bytes from the end of the data defined by the preceding fragment). However when I tried this I got an error that the video data couldn't be parsed. What did lead to data that could be parsed was the length of the moof atom plus the total length of the first track (as if the base offset were the first byte of the enclosing moof box, same as the first track)