[FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
rogerdpack2 at gmail.com
Sat May 28 08:48:56 CEST 2016
On 12/29/15, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes <h.leppkes at gmail.com>
>> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack <rogerdpack2 at gmail.com>
>>>> OK I had this great idea to capture the incoming MPEG2 transport
>>>> stream from the digital TV capture device. Kind of like "raw" stream,
>>>> so FFmpeg could have access to, for instance, all the audio stream.
>>>> It appears that the type coming out of the tuner is:
>>>> with subtype
>>>> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT
>>>> by the built in directshow mpeg demuxer  so I assume is some kind
>>>> of typical MPEG2 TS stream.
>>>> I had hoped that if I set dshow's AVStream's codec_id to
>>>> codec->codec_id = AV_CODEC_ID_NONE;
>>>> codec->codec_type = AVMEDIA_TYPE_DATA;
>>> Oops that was meant to be
>>> codec->codec_id = AV_CODEC_ID_MPEG2TS;
>>> codec->codec_type = AVMEDIA_TYPE_DATA;
>>>> That it would somehow recognize that I was sending it an MPEG stream
>>>> and insert an appropriate demuxer for me.
>>>> However, when I run it, it fails like this:
>>>> Input #0, dshow, from 'video=Hauppauge WinTV 885 BDA Tuner/Demod':
>>>> Duration: N/A, bitrate: N/A
>>>> Codec 0x20000 is not in the full list.
>>>> Stream #0:0, 0, 1/27000000: Data: unknown_codec, 0/1
>>>> Successfully opened the file.
>>>> Output #0, mp4, to 'yo.mp4':
>>>> Output file #0 does not contain any stream
>>>> so it's definitely not, for instance, doing a probe or analyze on the
>>>> MPEG stream....
>>>> Is this possible or any hints/tips/tricks I could possibly use?
>>> To answer my own question, I turned the dshow capture device into both
>>> an AVInputFormat *and* a URLProtocol that "wraps" the AVInputFormat.
>>> Apparently ffmpeg can receive "raw" bytes only from URLProtocol (?)
>>> This way worked great both "segmented" MPEG2VIDEO streams as well as
>>> "raw" MPEG TS streams.
>> You should probably just make it use the mpegts demuxer directly, say
>> like the rtsp demuxer.
>> We have an API for that in the form of avpriv_mpegts_parse_packet
>> Making an input device a protocol seems rather ugly, the user needs to
>> know beforehand how to call it that way.
True, I wish I didn't have to do it (ex: use AV_CODEC_ID_MPEG2TS and
it "just work" -- any hints or clues to that welcome!) I'd like to
give them access to the command line demultiplexing options that raw
MPEG streams currently have.
(ex: if they want 3 streams out of 10, like
https://trac.ffmpeg.org/wiki/Map#Example8) without having to build
that functionality into dshow parameters as well.
> Or as an alternative, why not just add the mpegts demuxer to the DShow
> graph as well and directly get video/audio streams.
> For Live TV functionality, the MS demuxer seems to be working quite well.
Mostly so that they can record a channel and its sibling sub channels
(from the same card) all at once, which can be convenient at times.
More information about the ffmpeg-devel