#1502 closed defect (fixed)
vc1 decoding regression
Reported by: | Carl Eugen Hoyos | Owned by: | |
---|---|---|---|
Priority: | important | Component: | avcodec |
Version: | git-master | Keywords: | vc1 regression videolan |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | yes | |
Analyzed by developer: | no |
Description
http://trac.videolan.org/vlc/ticket/6904
I will attach crash.wmv (does not crash, no invalid reads) that cannot be played since 4f00519 ("Fix VC-1 width/height handling.")
FFmpeg claims a resolution change to 7710x7746 with current git head and decoding fails.
$ ffmpeg -i crash.wmv ffmpeg version N-42076-g51d2578 Copyright (c) 2000-2012 the FFmpeg developers built on Jun 30 2012 21:45:24 with gcc 4.3.2 configuration: --cc=/usr/local/gcc-4.3.2/bin/gcc --enable-gpl --enable-libopenjpeg --enable-libvorbis --enable-libspeex --enable-libmp3lame --enable-libtheora --extra-ldflags=-lm --enable-libvpx --enable-libxavs --enable-libfaac --enable-nonfree libavutil 51. 63.100 / 51. 63.100 libavcodec 54. 31.100 / 54. 31.100 libavformat 54. 14.100 / 54. 14.100 libavdevice 54. 0.100 / 54. 0.100 libavfilter 3. 0.100 / 3. 0.100 libswscale 2. 1.100 / 2. 1.100 libswresample 0. 15.100 / 0. 15.100 libpostproc 52. 0.100 / 52. 0.100 [asf @ 0x903a3c0] max_analyze_duration 5000000 reached at 5016000 Input #0, asf, from 'crash.wmv': Metadata: WMFSDKVersion : 12.0.7601.17514 WMFSDKNeeded : 0.0.0.0000 IsVBR : 1 Duration: 00:00:17.21, bitrate: 1508 kb/s Stream #0:0(eng): Video: vc1 (Advanced) (WVC1 / 0x31435657), yuv420p, 640x480 [SAR 1:1 DAR 4:3], 1472 kb/s, 30.30 fps, 29.97 tbr, 1k tbn, 29.97 tbc At least one output file must be specified
Attachments (1)
Change History (7)
by , 12 years ago
comment:1 by , 12 years ago
comment:2 by , 12 years ago
I originally tested ffplay, but it does not work with MPlayer either afaict.
Additionally, I wonder how it works for you with ffmpeg, at least the following command clearly shows a regression here:
$ ffmpeg -i crash.wmv -vframes 50 out%2d.png
follow-up: 4 comment:3 by , 12 years ago
I was not able to verify the output (AMD broke their Linux drivers again).
The problem with the file is that the stream starts with a header that seems valid that specifies 7710x7746 as the resolution.
Any later headers do not specify a resolution, so it does not fix itself.
This is why it plays with -ss: seeking skips that header with the bad resolution.
Do any other players play this file?
Ignoring resolution changes for files in wmv would be possible, but quite a hack.
A bitstream filter to discard those 0x10e headers would be possible, too I think.
But none seem like a really good solution.
comment:4 by , 12 years ago
comment:5 by , 12 years ago
Reproduced by developer: | set |
---|---|
Resolution: | → fixed |
Status: | new → closed |
comment:6 by , 12 years ago
Keywords: | videolan added |
---|
What exactly is the problem? ffmpeg -f framecrc seems to decode it just fine except for a few errors at the beginning. ffplay aborts with an X error, but that is due to a SDL issue. ffplay -ss 10 plays it fine.