On Wed, Dec 30, 2015 at 12:33 AM, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > On Wed, Dec 30, 2015 at 12:23 AM, Roger Pack <rogerdpa...@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. >
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. - Hendrik _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
