[FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8

[Soft Works]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of Martin
> Storsjö
> Sent: Tuesday, May 24, 2022 11:29 AM
> To: FFmpeg development discussions and patches <ffmpeg-devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] fftools: Stop using av_fopen_utf8
> 
> On Mon, 23 May 2022, Soft Works wrote:
> 
> > Great. I rebased and resubmitted both patchsets. The primary long-path
> > patchset didn't need any change.
> >
> > Considerations for the latter were:
> >
> > - Should the file wchar_filename.h be renamed as it is now containing
> >  the path prefixing code?
> 
> I guess we could do that later at some point, but I don't see it as
> urgent.
> 
> > - I have kept the path functions in the same way like .NET does it,
> >  just for easy reference and following. Compilers will inline
> >  them anyway (my pov). Maybe others don't like that. I can change
> >  if it's got to be.
> 
> Having the individual functions inline compared to merging it all in one
> big function doesn't matter to me. But the amount of code in this inline
> header is growing a bit big, to the point that I think it is measurable
> when multiple files within the same library use these functions. Longer
> term, it would probably make sense to make them more shared in some way.

> If C would have the C++ style deduplication feature for non-static inline
> functions, this wouldn't be an issue. One could consider making them ff_
> functions and carry a copy in each library too, maybe. (But that also
> makes it trickier to use in fftools.) 

A copy in each library - isn't that exactly what's already happening?

The get_extended_win32_path() is used from 2 places:

1. file_open.c

For this, we already have copies in each library. file_open.c includes
wchar_filename.h and the new functions are inlined into file_open.obj.
So, there's only one copy in each library

2. os_support.h

This is used in libavformat exclusively. But in this case, the code gets
duplicated actually for each consumption of one of those file functions.
There aren't many usages in total, though, and I don't see any trend 
on the horizon for sudden increase, so I agree that there's no urgency.


BTW, thanks for your other comments, I have added the missing av_free()
calls and included URLs to the .NET source.
I chose to use permalinks. These are long and ugly, but they have changed
their structure (and even repo) so often during the past years, that
chances are low that the non-versioned links would still be valid in a
few years (I wouldn't even bet on months :-)

softworkz