Abnormal frame length on MP4 files #29388

New Issue

Ejner Fergo · 2011-11-24T20:03:59+01:00

Ejner Fergo commented

2011-11-24 20:03:59 +01:00

%%%Ubuntu 11.04 Linux 64bit
Blender SVN r42134
lib/linux64 SVN r42134

Opening a ~5 sec. video recorded with a Samsung Galaxy S2 in the sequencer gives a video-strip with unrealistic frame length (163320 frames).

Sample video:
http://dl.dropbox.com/u/11299813/SGS2.mp4

I had this problem before, but it was fixed using an updated ffmpeg-git I compiled. Here is the output of 'ffprobe SGS2.mp4':

built on Oct  3 2011 19:32:23 with gcc 4.5.2
configuration: --enable-shared --enable-x11grab --enable-vdpau --enable-libmp3lame --enable-libopenjpeg --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-openal --enable-gpl
libavutil    51. 19. 0 / 51. 19. 0
libavcodec   53. 19. 0 / 53. 19. 0
libavformat  53. 13. 0 / 53. 13. 0
libavdevice  53.  4. 0 / 53.  4. 0
libavfilter   2. 43. 6 /  2. 43. 6
libswscale    2.  1. 0 /  2.  1. 0
libpostproc  51.  2. 0 / 51.  2. 0

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'SGS2.mp4':

Metadata:
  major_brand     : 3gp4
  minor_version   : 768
  compatible_brands: 3gp43gp6
Duration: 00:00:05.44, start: 0.000000, bitrate: 11960 kb/s
  Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1280x720, 11900 kb/s, 29.94 fps, 59.83 tbr, 30k tbn, 60k tbc
  Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 16000 Hz, mono, s16, 54 kb/s

Since Cycles was included in trunk, I'm building with the official libs instead of my own. Seeing that ffmpeg has been updated to 0.8.7 I assumed the MP4 files would now work, but it still has the abnormal frame length.
%%%

%%%Ubuntu 11.04 Linux 64bit Blender SVN r42134 lib/linux64 SVN r42134 Opening a ~5 sec. video recorded with a Samsung Galaxy S2 in the sequencer gives a video-strip with unrealistic frame length (163320 frames). Sample video: http://dl.dropbox.com/u/11299813/SGS2.mp4 I had this problem before, but it was fixed using an updated ffmpeg-git I compiled. Here is the output of 'ffprobe SGS2.mp4': ffprobe version N-33243-g85ea5c6, Copyright (c) 2007-2011 the FFmpeg developers ``` built on Oct 3 2011 19:32:23 with gcc 4.5.2 configuration: --enable-shared --enable-x11grab --enable-vdpau --enable-libmp3lame --enable-libopenjpeg --enable-libtheora --enable-libvorbis --enable-libvpx --enable-libx264 --enable-openal --enable-gpl libavutil 51. 19. 0 / 51. 19. 0 libavcodec 53. 19. 0 / 53. 19. 0 libavformat 53. 13. 0 / 53. 13. 0 libavdevice 53. 4. 0 / 53. 4. 0 libavfilter 2. 43. 6 / 2. 43. 6 libswscale 2. 1. 0 / 2. 1. 0 libpostproc 51. 2. 0 / 51. 2. 0 ``` Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'SGS2.mp4': ``` Metadata: major_brand : 3gp4 minor_version : 768 compatible_brands: 3gp43gp6 Duration: 00:00:05.44, start: 0.000000, bitrate: 11960 kb/s Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p, 1280x720, 11900 kb/s, 29.94 fps, 59.83 tbr, 30k tbn, 60k tbc Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 16000 Hz, mono, s16, 54 kb/s ``` Since Cycles was included in trunk, I'm building with the official libs instead of my own. Seeing that ffmpeg has been updated to 0.8.7 I assumed the MP4 files would now work, but it still has the abnormal frame length. %%%

Ejner Fergo commented

2011-11-24 20:03:59 +01:00

Changed status to: 'Open'

Sergey Sharybin commented

2011-11-28 17:46:32 +01:00

%%%The problem is that this file doesn't contain valid information to calculate length in frames without reading it from the very beginning to the very end. Proxy/Timecode stuff is supposed to deal with this, but currently implemented timecodes aren't useful here too. We'll add new timecode which will help you here. Until this please use mencoder to convert your file to something acceptable for blender (commend for this video is mencoder -o output.avi -ovc copy -oac pcm input.avi)

It's not actually a bug, just we can't support all kinds of broken video files. Thanks for the report, but will close it.%%%

%%%The problem is that this file doesn't contain valid information to calculate length in frames without reading it from the very beginning to the very end. Proxy/Timecode stuff is supposed to deal with this, but currently implemented timecodes aren't useful here too. We'll add new timecode which will help you here. Until this please use mencoder to convert your file to something acceptable for blender (commend for this video is mencoder -o output.avi -ovc copy -oac pcm input.avi) It's not actually a bug, just we can't support all kinds of broken video files. Thanks for the report, but will close it.%%%

Sergey Sharybin commented

2011-11-28 17:46:33 +01:00

Changed status from 'Open' to: 'Archived'

Sergey Sharybin closed this issue

2011-11-28 17:46:33 +01:00

Ejner Fergo commented

2011-11-30 22:08:41 +01:00

%%%Fair enough.

I don't know about the broken video files... As I wrote the files worked as expected with my own ffmpeg (0.8.6) before, but maybe because I used libx264?%%%

%%%Fair enough. I don't know about the broken video files... As I wrote the files worked as expected with my own ffmpeg (0.8.6) before, but maybe because I used libx264?%%%

Sergey Sharybin commented

2011-11-30 22:12:27 +01:00

%%%What do you mean they worked? Normally, FFmpeg doesn't use amount of frames in the video -- it's just handles the stream as-is. Blender requires to know exact amount of frames. The problem is: with that information which is stored in your file it's impossible to find amount of frames which can be treated as trusted. Will write new timecode which can help you here, but it'll require some time. But without this timecode it'll be impossible to handle your video correct in blender.%%%

Ejner Fergo commented

2011-11-30 22:23:20 +01:00

%%%I mean that instead of +160000 frames in the 5 sec clip, I got ~300 frames. Should have put "worked" in quotes, since it is still not precise, but my experience with ffmpeg in the sequencer have never been precision...

In any case I don't want to cause trouble for you, as I doubt I'll use these videos from my phone directly. I just like the fact that Blender sequencer has always been able to use all kinds of files reasonably, and haven't experienced a file that freaked out like this one.%%%

%%%I mean that instead of +160000 frames in the 5 sec clip, I got ~300 frames. Should have put "worked" in quotes, since it is still not precise, but my experience with ffmpeg in the sequencer have never been precision... In any case I don't want to cause trouble for you, as I doubt I'll use these videos from my phone directly. I just like the fact that Blender sequencer has always been able to use all kinds of files reasonably, and haven't experienced a file that freaked out like this one.%%%

Sergey Sharybin commented

2011-12-15 13:19:44 +01:00

%%%New timecode called "Free run no gaps" was just implemented in trunk (svn rev42641). It allows to deal with file with broken time base stored in the header.%%%

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Abnormal frame length on MP4 files #29388