[FFmpeg-devel] [GSoC] BDA (DTV) Capture / tuning -- work-in-progress
rogerdpack2 at gmail.com
Tue Dec 22 04:09:57 CET 2015
On 12/17/15, Roger Pack <rogerdpack2 at gmail.com> wrote:
> On 8/22/15, Michael Niedermayer <michael at niedermayer.cc> wrote:
>> On Sat, Aug 22, 2015 at 05:18:04AM +0200, Máté Sebők wrote:
>>> > fails to build with mingw due to missing header
>>> > In file included from ffmpeg/libavdevice/dshow.c:33:0:
>>> > ffmpeg/libavdevice/bdadefs.h:8:24: fatal error: combaseapi.h: No such
>>> > file or directory
>>> > compilation terminated.
>>> > make: *** [libavdevice/dshow.o] Error 1
>>> > maybe a header check is needed in configure
>>> Maybe fixed... unnecessary headers removed (also some cleanup in the
>> i can confirm, the new patch builds fine with mingw here
>>> > +
>>> > > + gfilename = malloc((strlen(ctx->dtv_graph_
>>> > file)+4)*sizeof(WCHAR));
>>> > is this intended to be malloc() instead of av_malloc() ?
>>> Yes, it was intended, only a filename buffer for char-to-widechar
>> normally code in FFmpeg uses av_malloc() unless there is need for
>> the buffer to be passed into external functions which require a
>> different allocation
>> full review left to roger and anyone else who wants to review
> 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;
> 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
I guess to avoid this I can expose my device as a "URLProtocol" as
well as a AVInputFormat or some odd?
One option to work around it is to capture from the "mpeg2video" pin
in the graph.
My next problem appears to be that directshow "feeds" me the
mpeg2video packets in "ts" sized chunks (i.e. 8K or smaller). It
appears to me that the native mpeg2video decoder doesn't know how to
handle partial packets like that and proceeds to basically just render
the top part of frames. Any suggestions there?
Also even if I dump the mpeg stream "to file" and play that with
ffmpeg, a few artifacts appear to be introduced. Anybody know if
libmpeg2 is better at decoding, somehow, than the native mpeg2video
decoder, by chance, artifact wise? I doubt it but thought I'd check.
More information about the ffmpeg-devel