[FFmpeg-devel] ffserver and ffmpeg with capture card.

julien.savarese at dcnsgroup.com julien.savarese
Mon Jun 9 11:21:26 CEST 2008


Is possible to capture and send via RTP a captured file by chose the frame 
rate, the width, height and the codec ?
     Julien Savarese 
     Apprenti ing?nieur. 
     Division SIS/DPM/RMS/MIE.

madshi <dear at madshi.net> 
Envoy? par : ffmpeg-devel-bounces at mplayerhq.hu
09/06/2008 11:19
Veuillez r?pondre ?
FFmpeg development discussions and patches <ffmpeg-devel at mplayerhq.hu>

FFmpeg development discussions and patches <ffmpeg-devel at mplayerhq.hu>

Re: [FFmpeg-devel] [RFC] additinal desc_type for dtshd mpeg-ts  demuxer

M?ns Rullg?rd schrieb:
> madshi wrote:
>> To my best knowledge this is the right way to demux TS and m2ts files:
>> 0x01: MPEG2 video
>> 0x02: MPEG2 video
>> 0x03: MP2 audio (MPEG-1 Audio Layer II)
>> 0x04: MP2 audio (MPEG-2 Audio Layer II)
>> 0x06: private data (can be AC3, DTS or something else)
>> 0x0F: AAC audio (MPEG-2 Part 7 Audio)
>> 0x11: AAC audio (MPEG-4 Part 3 Audio)
>> 0x1B: h264 video
> These are standardised in ISO 13818-1.


>> 0x80: MPEG2 video or PCM audio
>> 0x81: AC3 audio
>> 0x82: DTS audio
>> 0x83: TrueHD/AC3 interweaved audio
>> 0x84: E-AC3 audio
>> 0x85: DTS-HD High Resolution Audio
>> 0x86: DTS-HD Master Audio
>> 0x87: E-AC3 audio
>> 0xA1: secondary E-AC3 audio
>> 0xA2: secondary DTS audio
>> 0xEA: VC-1 video
> These are all non-standard.

So the Blu-Ray specification is not a standard?  :-)

>> There are two problematic situations:
>> (1) 0x80 can be either MPEG2 video or LPCM audio. In the M2TS
>> container
> There is no such thing as "the m2ts container", at least not anything
> standardised.


Wikipedia sais: "A *technical standard* is an established norm or
requirement. It is usually a formal document that establishes uniform
engineering or technical criteria, methods, processes and practices."

There's an official and very detailed Blu-Ray specification available,
which according to my understanding and also according to wikipedia's
definition makes it a "technical standard".

>> 0x80 should always be LPCM audio.
> Says who?

Sais the Blu-Ray specification.

>> In the TS container 0x80 is normally MPEG2 video.
> In a standard MPEG-TS container, 0x80 is undefined.  It should certainly
> not be MPEG2 video, since there is a defined stream type for that.

Do you want ffmpeg to support common TS files which
are out in the wild or not?

>> BUT - if people convert an M2TS stream to TS, 0x80 can be PCM.
> Such people are stupid, and should be handed to the firing squad.

There is software available which does these conversions,
as stupid as it may seem.

End users do not know what the software does in detail.
They just expect things to work. Now of course you can
hold your hands over both ears and say "la la la la". But
that doesn't change the fact that sooner or later people
will bump into TS streams with 0x80 Blu-Ray PCM in it.
Users of my "eac3to" Blu-Ray and HD DVD handling tool
already did come to me with samples of such streams.

I see no basic problem adjusting ffmpeg so that it detects
such situations. Heck, I've no problem with it complaining
about it. It could post a big warning "incorrect PCM track
detected" or anything. But just pretending that such
misformatted TS streams wouldn't exist is not the right
thing to do in my book.

> The *only* way to have any clue whatsoever about the contents of streams
> with stream type in the private range is by looking at various 

If such descriptors are present. Unfortunately some
Blu-Ray tracks just have a "HDMV" descriptor and that's
it. You have no choice than to rely on the stream type
identifier sometimes.

Regards, madshi.
ffmpeg-devel mailing list
ffmpeg-devel at mplayerhq.hu

Pensez a l'environnement : avez-vous besoin d'imprimer ce message ?
Think Environment : Do you need to print this message ?

Ce courrier ?lectronique, et ?ventuellement ses pi?ces jointes, peuvent contenir des informations confidentielles et/ou  personnelles et a ?t? envoy? uniquement ? l'usage de la personne ou de l'entit?  cit?e ci-dessus. Si vous receviez ce courrier ?lectronique par erreur, merci de bien vouloir en avertir l'exp?diteur imm?diatement par la r?ponse en retour ? ce courrier  et effacer l'original et d?truire toute copie enregistr?e dans un ordinateur, ou imprim?e ou encore sauvegard?e sur un disque . Toute  revue, retransmission ou toute autre forme d'utilisation de ce courrier ?lectronique par toute autre personne que le destinataire pr?vue est strictement interdite.

L'internet ne permettant pas d'assurer l'int?grit? de ce message, l'exp?diteur d?cline toute responsabilit? au cas o? il aurait ?t? intercept? ou modifi? par quiconque.

This e-mail and possibly any attachment may contain confidential and/or privileged information and is intended only for the use of the individual or entity named above.  If you have received it in error, please advise the sender immediately by reply e-mail and delete  and destroy all copies including all copies stored in the recipient's computer, printed or saved to disk. . Any review , retransmission, or further use of this e-mail by by persons or entities other than the intended recipient is strictly  prohibited.  Because of the nature of the Internet the sender is not in a position to ensure the integrity of this message, therefore the sender disclaims any liability whatsoever, in the event of this message having been intercepted and/or altered.

More information about the ffmpeg-devel mailing list