[Ffmpeg-devel] [Ffmpeg-devel-old] SVCD bug

[Måns Rullgård]

Michel Bardiaux said:
> M?ns Rullg?rd wrote:
>> Colin Ward <lists at codehq.org> writes:
>>
>>
>>>M?ns Rullg?rd wrote:
>>>
>>>>I can think of many reasons to want a proper MPEG file rather than a
>>>>VCD
>>>>encapsulated one.  The OP's file apparently causes problems for ffmpeg.
>>>>
>>>>
>>>>>   I have a VCD related problem that I have been meaning to look into.
>>>>>I have a couple of .dat files from a couple of different VCDs.  One of
>>>>>them plays in my FFMPEG based program and the other causes either
>>>>>av_open_input_file() or av_find_stream_info() to return an "unknown
>>>>>format" error.  I can't remember exactly at the moment as I am not in
>>>>>front of my development computer.
>>>>>
>>>>>   Why would one VCD .dat file be playable and not the other?
>>>>
>>>>Post some samples, please.
>>>
>>>   Sorry for the delay, I haven't been home for a few days to upload
>>>   the samples.  They can be found here:
>>>
>>>   http://www.codehq.org/Robots.dat
>>>   http://www.codehq.org/Legue.dat
>>>
>>>   They are both the first 1 MB from the respective .dat files on the
>>>   VCD.  As I said, one of them opens successfully and the other
>>>   returns an "unknown format" error.  And yet they both open
>>>   successfully with MPlayer.
>>
>>
>> Those files are both unmunged MPEG1 system streams, except for one
>> thing.  The one that fails (Legue.dat) starts with a block of 0x11058
>> zeros.  That is more junk than lavf searches when checking the file
>> format.
>>
> Stricto sensu, a bug, since the standard does not place any restriction
> on the amount of zero-stuffing.

I know, but how far is it reasonable to search for a start code?  Lavf
passes the first 2048 bytes of the file to each demuxer when checking the
file format.

What's the purpose of those leading zeros anyway?

-- 
M?ns Rullg?rd
mru at inprovide.com