[FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.
Jerome Borsboom
jerome.borsboom at carpalis.nl
Sat Oct 13 11:50:54 EEST 2018
> On Sat, Oct 13, 2018 at 12:55 AM mypopy at gmail.com <mypopy at gmail.com> wrote:
>>
>> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos <ceffmpeg at gmail.com>
> wrote:
>> >
>> > 2018-10-12 15:41 GMT+02:00, Jun Zhao <mypopydev at gmail.com>:
>> > > case 1:
>> > > use the hexdump -C SMM0005.rcv get:
>> > > size skip (size - 4)
>> > > | |
>> > > V V
>> > > 00000000 18 00 00 c5 05 00 00 00 4d f1 0a 11 00 e0 01 00
>> > > 00000010 00 d0 02 00 00 0c 00 00 00 88 13 00 00 c0 65 52
>> > > ^
>> > > |
>> > > size + 16
>> > > case 2:
>> > > same the command for SMM0015.rcv get:
>> > > size
>> > > |
>> > > V
>> > > 00000000 19 00 00 c5 04 00 00 00 41 f3 80 01 40 02 00 00
>> > > 00000010 d0 02 00 00 0c 00 00 00 00 00 00 10 00 00 00 00
>> > > ^
>> > > |
>> > > size + 16
>> > >
>> > > There are different the RCV file format for VC-1, vc1test
>> > > just handle the case 2 now, this fix will support the case 1.
>> >
>> > Both with and without your patch, I get identical output from
>> > FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
>> > What exactly is your patch supposed to change?
>> >
>> > $ md5sum SMM0005.rcv
>> > abd0fa5ec90d44f7b4865c6930d65ff2 SMM0005.rcv
>> > $ md5sum SSM0015.rcv
>> > 21a0281f83b7f2e99a048b180dd3347f SSM0015.rcv
>>
>> In my test clips, I get md5 like this
>> $ md5sum SMM0005.rcv
>> 39eb225dbfafacea3e3737deba789530 SMM0005.rcv
>> $ md5sum SMM0015.rcv
>> 78e45e50079e143e69f69d677c37ac3b SMM0015.rcv
> RCV format have a different version, you can google the rcv1 rcv2 for VC-1.
> (e,g:
> http://www.ti.com/lit/ml/sprs363a/sprs363a.pdf), I think we use a different
> RCV format for test clips SMM0005.rcv
This has nothing to do with the version. Version is coded as the sixth
bit in the initial byte, i.e. 0x85 = version 1, 0xc5 = version 2.
VC-1(2006) is quite clear in Annex L that the second dword should be a
0x00000004. The reference decoder, however, is more lenient and gives
more insight. The 0x00000004, and the 0x0000000c in the seventh dword,
seem to be meant as a length indicator for the STRUCT_C and the
STRUCT_B, respectively.
This may be a leftover from older versions. I think it won't hurt to
follow the reference decoder here and interpret these dwords as length
indicators. The patch could be adjusted to do this for the 0x0000000c as
well.
Regards,
Jerome
More information about the ffmpeg-devel
mailing list