[FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress

[Roger Pack]

As a quick follow up, there is a full working example (windows DTV
[ATSC/DVBT/DVBS], works with MPEG or H264 streams, capture channels
*with their subchannels* all at once)

https://github.com/rdp/ffmpeg/tree/dtv_protocol

It uses the "schizo" way where digital TV comes in as a "protocol"
from libavformat, and the rest is via normal libavdevice device
(suggestions welcome still there...I want to be able to send "raw"
mpeg streams to FFmpeg so that it can use its selectors on it, but
send that in from a device...wish there were an option for a
libavdevice to send "raw" stream-like data :| ).

ATSC usage example:
https://github.com/rdp/FFmpeg/blob/dtv_protocol/go_protocol_local.bat

DVB example: https://github.com/rdp/FFmpeg/blob/dtv_protocol/ffmpeg_dvbt.bat

I haven't had the umph to get something ready for merging yet, just
linking it in case it's useful to someone in the meantime.

Cheers!

On 5/28/16, Roger Pack <rogerdpack2 at gmail.com> wrote:
> 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>
>> wrote:
>>> On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack <rogerdpack2 at gmail.com>
>>> wrote:
>>>>> 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:
>>>>> MEDIATYPE_Stream
>>>>> with subtype
>>>>> KSDATAFORMAT_SUBTYPE_BDA_MPEG2_TRANSPORT
>>>>> which is apparently treated the same as MEDIASUBTYPE_MPEG2_TRANSPORT
>>>>> by the built in directshow mpeg demuxer [1] 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.
>
> Cheers!
> -roger-
>