Opened 5 years ago

Closed 5 years ago

Last modified 5 years ago

#1502 closed defect (fixed)

vc1 decoding regression

Reported by: cehoyos 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)

crash.wmv (2.4 MB) - added by cehoyos 5 years ago.

Change History (7)

Changed 5 years ago by cehoyos

comment:1 Changed 5 years ago by reimar

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.

comment:2 Changed 5 years ago by cehoyos

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

comment:3 follow-up: Changed 5 years ago by reimar

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 in reply to: ↑ 3 Changed 5 years ago by cehoyos

Replying to reimar:

Do any other players play this file?

WMP plays the file fine.

comment:5 Changed 5 years ago by michael

  • Reproduced by developer set
  • Resolution set to fixed
  • Status changed from new to closed

comment:6 Changed 5 years ago by cehoyos

  • Keywords videolan added
Note: See TracTickets for help on using tickets.