[FFmpeg-devel] Stream Type 0x80 (video?)

snacky at ikaruga.co.uk snacky
Sat Apr 11 06:41:44 CEST 2009


On Fri, 10 Apr 2009 21:39:15 -0400, Jose Mortensen
<josemortensen at gmail.com> wrote:
> 2009/4/10 M?ns Rullg?rd <mans at mansr.com>:
>> Jose Mortensen <josemortensen at gmail.com> writes:
>>
>>> On Fri, Apr 10, 2009 at 3:30 PM, compn <tempn at twmi.rr.com> wrote:
>>>> On Fri, 10 Apr 2009 15:24:44 -0400, Jose Mortensen wrote:
>>>>>I am New here. Please tell me where?
>>>>>
>>>>>-- Jose
>>>>>
>>>>
>>>> ftp://upload.mplayerhq.hu/MPlayer/incoming
>>>>
>>>> with a name like type80video.ts
>>>
>>> Done,
>>>
>>> 227 Entering Passive Mode (213,144,138,186,246,231)
>>> 150 Ok to send data.
>>>
>>> 226 File receive OK.
>>> 8400000 bytes sent in 63.9 secs (1.3e+02 Kbytes/sec)
>>
>> Mentioning the filename you used would have been nice, but I found the
>> file.
>>
> 
> Sorry about that, for some reason I though it would be the only file....
> 
>>
>> That file is not a valid MPEG-TS stream. ?Several "reserved" fields
>> which should be all ones are set to zero. ?Ignoring this, the video
>> stream has two descriptors, type 0x83 and 0x86, both in the private
>> range. ?There is no registration descriptor to identify any derived
>> spec that may be in use.

I hate replying to this block of text because I can't maintain the right
margin justification you achieved in your paragraph.

Descriptor 0x83: ANSI/SCTE 57, see
http://www.scte.org/documents/pdf/ANSISCTE572003DVS507.pdf table 7.1

Stream type 0x80: Same as above, table 7.4 

Descriptor 0x86: ANSI/SCTE 65, see
http://www.scte.org/documents/pdf/ANSISCTE652002DVS234.pdf table 6.2

How'd I know where to find these? I see it all the time, and also
http://www.atsc.org/standards/Code_Point_Registry.pdf

> This file came from satellite broadcasting in the USA (how networks
> broadcast content to cable companies and such).   It is supposed to be
> "broadcast quality" stuff. I don't know which encoder was used, but It
> was received by an Motorola IRD which has no problem what so ever
> decoding this thing. Look for DSR-4410MD

As you say, this type of stream is typical in the US.
 
> I also pased it through a mpeg analyzer, which could not identify the
> video stream either, alongs with a bunch of errors. The video size is
> also not standard.

The size is common. What standard do you think the video size violates? 

> It is like there is a hidden agreement between
> broadcasters and equipment manufacturers that they don't want anybody
> to know.

Maybe it's more like the equipment manufacturer is the same end-to-end
sometimes. The users just care that it works, and the sooner the better.

Although we see in this particular case, there are no secrets involved in
the format.




More information about the ffmpeg-devel mailing list