jslhs / ffmbc

Automatically exported from code.google.com/p/ffmbc
0 stars 0 forks source link

FFmbc 0.7 rc8 detects Canon 5D movies as 1920x1088 #153

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?

If I use FFmbc 0.7 rc8 to look at the contents of a file from a Canon 5D then 
it tells me file will be interpreted as 1920x1088P: 

$ ffmbc -i "BAD - canon 5d.MOV" 
FFmbc version 0.7-rc8
Copyright (c) 2008-2013 Baptiste Coudurier and the FFmpeg developers
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'BAD - canon 5d.MOV':
  Metadata:
    major_brand: qt
    minor_version: 537331968
    compatible_brands: qt  CAEP
  Duration: 00:00:11.48, bitrate: 46304 kb/s
    Stream #0.0(eng): Video: h264 (Constrained Baseline), yuvj420p, 1920x1088p, 44765 kb/s, 25.00 fps
    Metadata:
      gamma: 2.199997
    Stream #0.1(eng): Audio: pcm_s16le, 48000 Hz, 2 channels, s16, 1536 kb/s
At least one output file must be specified

But FFmpeg gets the size correct: 

    Stream #0:0(eng): Video: h264 (Constrained Baseline) (avc1 / 0x31637661), yuvj420p, 1920x1080, 44765 kb/s, 25 fps, 25 

Interestingly, using movdump (on Linux) (or Atom Inspector on Mac OS X) to 
inspect the MOV structure there is no mention of 1088. There is only: 

moov->trak->track_height = 1080.00 
moov->trak->mdia->minf->stbl->height = 1080 

What is the expected output? What do you see instead?

1920x1080

Please use labels and text to provide additional information.

I shall make a file available and send a link to you on IRC

Original issue reported on code.google.com by mark.him...@gmail.com on 10 Jul 2013 at 10:32

GoogleCodeExporter commented 8 years ago
Quite sure that the Canon files are in fact 1920x1088 due to macroblocking.

Original comment by troy.sob...@gmail.com on 13 Sep 2013 at 8:46

GoogleCodeExporter commented 8 years ago
I agree that the video essence will be encoded at 1920x1088. But that is not 
the point here.
As I've said in the thread above, other applications (including very expensive 
broadcast applications) interpret the MOV differently.

-- 
Mark Himsley

Original comment by mark.him...@gmail.com on 13 Sep 2013 at 8:26