On 12/29/15, Hendrik Leppkes <h.lepp...@gmail.com> wrote: > 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.
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- _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
