[FFmpeg-devel] [PATCH] dshow: allow for more codecs take 2

Michael Niedermayer michaelni at gmx.at
Fri Feb 15 00:15:36 CET 2013


On Thu, Feb 14, 2013 at 01:46:44PM -0700, Roger Pack wrote:
> On 2/14/13, Hendrik Leppkes <h.leppkes at gmail.com> wrote:
> > On Thu, Feb 14, 2013 at 1:20 AM, Roger Pack <rogerdpack2 at gmail.com> wrote:
> >>>> still seems to not work correctly:
> >>>>
> >>>> <BBB-work> someone broke msvc dll builds by marking ff_codec_bmp_tags[]
> >>>> with av_export
> >>>> <BBB-work> can whoever did that fix it?
> >>>> <BBB-work> https://github.com/libav/c99-to-c89/issues/5
> >>>>
> >>>>
> >>>> [...]
> >>>
> >>> This is also covered by a fate instance:
> >>> http://fate.ffmpeg.org/history.cgi?slot=x86_32-msvc10-dll-windows-native
> >>>
> >>> Shared tables cannot be used as a constant initializer.
> >>
> >> so can anyone suggest something here?  I want to use ff_codec_bmp_tags
> >> shared, but apparently this is a special case where av_export won't
> >> work with it, because it is used elsewhere as a constant initializer?
> >> If there's no response I suppose I will just add a new (exported)
> >> method to riff.c that returns the table, and use that instead of raw
> >> access to the table...does that sound good?
> >> -roger-
> >
> >
> > It appears there already are functions for what you want:
> > - avformat_get_riff_video_tags gives you ff_codec_bmp_tags
> 
> Oh perfect.  I'll add a comment to the source so this is more clear.
> 
> > In general i think its a bad idea to export ff* functions and tables,
> > if something is needed rename it to avpriv* or for data tables a
> > getter function is a good idea, because sharing tables is always a bit
> > of a pain.
> 
> Yeah agree, it seemed odd to export anything named ff_* (but seems to
> be fairly common, so I left cleaning these and those like it for later
> work).
> 
> > So, hide ff_codec_bmp_tags again (remove av_export and the .v file
> > entry), and use the existing getter function. :)
> 
> Ok please somebody look at and merge rdp/dshow_c89 when you get the chance.
> 
> > While i was looking at the changes, something else confused me in your
> > commit.
> > You added "ff_raw_pix_fmt_tags" to the avformat .v file, but that
> > symbol lives in avcodec?
> 
> Oops I thought it was from avformat (since everything else I was using
> was), and, since absent from the .v file, should have been added.
> Looks like it is already being exported from avcodec, so we should be
> good there (removed the export .v line in the rdp/dshow_c89 branch).

merged with changed commit message (no c98 mention)

thanks

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20130215/6e723976/attachment.asc>


More information about the ffmpeg-devel mailing list