[MPlayer-users] MOV Dimensions Not Set Error
Larry Reznick
lreznick at idistream.com
Wed Jun 13 18:27:53 CEST 2007
Larry Reznick wrote:
> Hi, gang.
>
> I'm trying to mux an H264-ES file with audio into an MOV file format. I
> get the following error:
>
> $ ~/download/mplayer/mencoder -fps 30000:1001 gearsofwar_g264_2000.264
> -audiofile gearsofwar_g264_2000.wav -ofps 30000:1001 -o
> gow_g264_2000.mov -of lavf -lavfopts
> i_certify_that_my_video_stream_does_not_use_b_frames -oac mp3lame
> -lameopts abr:br=64 -ovc copy
> MEncoder dev-SVN-r23491-4.1.1 (C) 2000-2007 MPlayer Team
> CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 6, Stepping: 5)
> CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
> Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
>
> success: format: 0 data: 0x0 - 0xcdc7a7
> H264-ES file format detected.
> Audio file file format detected.
> FPS seems to be: 14.985015
> [V] filefmt:65536 fourcc:0x10000005 size:0x0 fps:14.99 ftime:=0.0667
> Input fps will be interpreted as 29.97 instead.
> ==========================================================================
> Opening audio decoder: [pcm] Uncompressed PCM audio decoder
> AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
> Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
> ==========================================================================
> ** MUXER_LAVF
> *****************************************************************
> You have certified that your video stream does not contain B frames.
> REMEMBER: MEncoder's libavformat muxing is presently broken and will
> generate
> INCORRECT files in the presence of B frames. Moreover, due to bugs MPlayer
> will play these INCORRECT files as if nothing were wrong!
> *******************************************************************************
> OK, exit
> videocodec: framecopy (0x0 24bpp fourcc=10000005)
> MP3 audio selected.
> VIDEO CODEC ID: 0
> AUDIO CODEC ID: 15001, TAG: 0
> Writing header...
> [mov @ 0x874f988]dimensions not set
> Floating point exception
>
>
> For some reason, the H264-ES frames are interpreted with half their
> frame rate, so I imposed the -fps and -ofps options. Otherwise, I
> thought it should be straightforward. Apparently not. I have no idea
> what dimensions it wants set. The video frame size is 1280x720 and,
> mplayer plays the H264-ES file just fine except for the half frame rate
> problem.
>
> Does anyone have an idea what's wrong or what I'm missing? I've included
> the -v output below if that helps.
>
> --Larry
Hi. I was sorry not to get a reply to this with any help or suggestions
but I worked on it and have some news and some questions.
I found that the "dimensions not set" problem is caused by the
VIDEO_H264 case inside video_read_properties() in libmpdemux/video.c not
setting the sh_video->disp_w and sh_video->disp_h members.
Interestingly, those settings happen for the VIDEO_MPEG12 case and two
other cases, but not for the VIDEO_H264 case even though the call to
h264_parse_sps() provides them from the VUI. To see this, I enabled a
debugging statement within the h264_parse_vui() function in
libmpdemux/mpeg_hdr.c. It showed the following.
$ ~/download/mplayer/mencoder -fps 30000:1001 gow_2000.264 -ovc copy
-audiofile gearsofwar_g264_2000.wav -ofps 30000:1001 -o gow_2000.mov -of
lavf -lavfopts i_certify_that_my_video_stream_does_not_use_b_frames -oac
mp3lame -lameopts abr:br=64
MEncoder dev-SVN-r23491-4.1.1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 6, Stepping: 5)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
success: format: 0 data: 0x0 - 0xd24c34
H264-ES file format detected.
Audio file file format detected.
H264_PARSE_VUI, OVESCAN=0, VSP_COLOR=0, CHROMA=0, TIMING=1, DISPW=1280,
DISPH=720, TIMERES=30000, TIMEINC=1001, FIXED_FPS=1, FPS=14.985015
FPS seems to be: 14.985015
[V] filefmt:65536 fourcc:0x10000005 size:0x0 fps:14.99 ftime:=0.0667
Input fps will be interpreted as 29.97 instead.
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
** MUXER_LAVF
*****************************************************************
You have certified that your video stream does not contain B frames.
REMEMBER: MEncoder's libavformat muxing is presently broken and will
generate
INCORRECT files in the presence of B frames. Moreover, due to bugs MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
OK, exit
videocodec: framecopy (0x0 24bpp fourcc=10000005)
MP3 audio selected.
VIDEO CODEC ID: 0
AUDIO CODEC ID: 15001, TAG: 0
Writing header...
[mov @ 0x874fae8]dimensions not set: w=0 h=0
Floating point exception
Notice the "H264_PARSE_VUI" line, which shows that the VUI has the
proper width & height. (The frame rate is still wrong, but more on that
later.) Notice in the "[V]" line two lines below that the size is "0x0".
So, the width & height known and stored in the
picture.display_picture_width and picture.display_picture_height members
are present but not delivered.
I made the following change:
--- video.c.orig 2007-06-13 08:43:56.000000000 -0700
+++ video.c 2007-06-13 08:48:56.000000000 -0700
@@ -213,6 +213,8 @@
return 0;
}
h264_parse_sps(&picture, &(videobuffer[pos]), videobuf_len - pos);
+ sh_video->disp_w=picture.display_picture_width;
+ sh_video->disp_h=picture.display_picture_height;
mp_msg(MSGT_DECVIDEO,MSGL_V,"Searching for picture parameter set...
");fflush(stdout);
while(1){
int i=sync_video_packet(d_video);
With those settings in place, the mencoder command delivers:
$ time ~/download/mplayer/mencoder -fps 30000:1001 gow_2000.264 -ovc
copy -audiofile gearsofwar_g264_2000.wav -ofps 30000:1001 -o
gow_2000.mov -of lavf -lavfopts
i_certify_that_my_video_stream_does_not_use_b_frames -oac mp3lame
-lameopts abr:br=64
MEncoder dev-SVN-r23491-4.1.1 (C) 2000-2007 MPlayer Team
CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (Family: 15, Model: 6, Stepping: 5)
CPUflags: Type: 15 MMX: 1 MMX2: 1 3DNow: 0 3DNow2: 0 SSE: 1 SSE2: 1
Compiled for x86 CPU with extensions: MMX MMX2 SSE SSE2
success: format: 0 data: 0x0 - 0xd24c34
H264-ES file format detected.
Audio file file format detected.
H264_PARSE_VUI, OVESCAN=0, VSP_COLOR=0, CHROMA=0, TIMING=1, DISPW=1280,
DISPH=720, TIMERES=30000, TIMEINC=1001, FIXED_FPS=1, FPS=14.985015
FPS seems to be: 14.985015
[V] filefmt:65536 fourcc:0x10000005 size:1280x720 fps:14.99
ftime:=0.0667
Input fps will be interpreted as 29.97 instead.
==========================================================================
Opening audio decoder: [pcm] Uncompressed PCM audio decoder
AUDIO: 44100 Hz, 2 ch, s16le, 1411.2 kbit/100.00% (ratio: 176400->176400)
Selected audio codec: [pcm] afm: pcm (Uncompressed PCM)
==========================================================================
** MUXER_LAVF
*****************************************************************
You have certified that your video stream does not contain B frames.
REMEMBER: MEncoder's libavformat muxing is presently broken and will
generate
INCORRECT files in the presence of B frames. Moreover, due to bugs MPlayer
will play these INCORRECT files as if nothing were wrong!
*******************************************************************************
OK, exit
videocodec: framecopy (1280x720 24bpp fourcc=10000005)
MP3 audio selected.
VIDEO CODEC ID: 0
AUDIO CODEC ID: 15001, TAG: 0
Writing header...
Pos: 0.7s 22f ( 0%) 0.00fps Trem: 0min 0mb A-V:0.070 [0:63]
Skipping frame!
Pos: 1.0s 32f ( 0%) 0.00fps Trem: 0min 15mb A-V:0.070 [1222:63]
Skipping frame!
Pos: 1.3s 42f ( 0%) 0.00fps Trem: 0min 21mb A-V:0.070 [1264:63]
Skipping frame!
Pos: 1.6s 52f ( 1%) 0.00fps Trem: 0min 13mb A-V:0.070 [1303:62]
Skipping frame!
Pos: 1.9s 62f ( 1%) 0.00fps Trem: 0min 16mb A-V:0.070 [1387:62]
Skipping frame!
Pos: 2.2s 72f ( 2%) 0.00fps Trem: 0min 13mb A-V:0.070 [1483:61]
Skipping frame!
Pos: 2.5s 82f ( 2%) 0.00fps Trem: 0min 16mb A-V:0.070 [1586:61]
Skipping frame!
Pos: 2.8s 92f ( 3%) 0.00fps Trem: 0min 14mb A-V:0.070 [1664:61]
Skipping frame!
Pos: 3.1s 102f ( 5%) 0.00fps Trem: 0min 13mb A-V:0.070 [1718:61]
Skipping frame!
Pos: 3.4s 112f ( 5%) 0.00fps Trem: 0min 14mb A-V:0.070 [1761:61]
Skipping frame!
H264_PARSE_VUI, OVESCAN=0, VSP_COLOR=0, CHROMA=0, TIMING=1, DISPW=1280,
DISPH=720, TIMERES=30000, TIMEINC=1001, FIXED_FPS=1, FPS=14.985015
Skipping frame!
Pos: 3.8s 124f ( 7%) 0.00fps Trem: 0min 12mb A-V:0.013 [1878:61]
1 duplicate frame(s)!
Pos: 3.8s 125f ( 7%) 0.00fps Trem: 0min 12mb A-V:0.020 [1861:61]
1 duplicate frame(s)!
[...]
Writing index...46f (99%) 184.47fps Trem: 0min 8mb A-V:0.027 [1021:61]
Video stream: 1021.902 kbit/s (127737 B/s) size: 13694392 bytes
107.207 secs 1846 frames
Audio stream: 61.151 kbit/s (7643 B/s) size: 470439 bytes 61.544 secs
This time the "[V]" line has the correct width & height settings and the
encoding goes through. Some other problems remain:
1. Why is it skipping frames or calling out duplicate frames, which it
does from frame 125 on for nearly all the frames following?
2. When playing the muxed result, the frame rate is correct until the
next VUI comes along. Then, the frame rate goes back to the ~15 fps
(15000:1001) instead of staying with the ~30 fps (30000:1001) requested
during the encoding. Shouldn't mencoder's -ofps override whatever the
VUI says? When I have mplayer play the H264-ES data directly that is
used by mencoder for muxing, and I specify the -fps option, the 2nd VUI
reverts the output back to ~15. Again, shouldn't mplayer's -fps option
override the VUI?
3. During the first VUI display, the picture has severe macroblock
deterioration. After the 2nd VUI, although the frame rate drops to ~15,
the macroblock deterioration disappears and never reappears. So, why is
the 1st VUI so deteriorated? The original H264-ES data has no such
trouble. Is this some trouble with the "-ovc copy" option?
The ~15 fps problem in the H264-ES file is my own problem. I'm encoding
that on the outside. I found out that frame data -- even progressive
frames -- must be identified to an H.264 encoder as twice the frame rate
as desired. That is, it must always be represented as a field rate even
though the frames are progressive. This is something I'll have to
correct on my encoder's side, which produces the H264-ES data. Still, it
could be a moot issue if mplayer & mencoder disallow the VUI from
overriding the -fps & -ofps options' settings.
Any thoughts? Does anyone want me to upload my sample files to help
track these problems down?
--Larry
More information about the MPlayer-users
mailing list