[FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: Fix path handling for Windows

[softworkz .]

> -----Original Message-----
> From: ffmpeg-devel <ffmpeg-devel-bounces at ffmpeg.org> On Behalf Of
> Marton Balint
> Sent: Freitag, 13. Juni 2025 23:36
> To: FFmpeg development discussions and patches <ffmpeg-
> devel at ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 3/3] avformat/hlsenc: Fix path
> handling for Windows
> 
> 
> 
> On Fri, 13 Jun 2025, softworkz wrote:
> 
> > From: softworkz <softworkz at hotmail.com>
> >
> 
> Can you give an example where the path handling is wrong and where
> this
> patch fixes it? Is there a trac ticket?
> 
> > Signed-off-by: softworkz <softworkz at hotmail.com>
> > ---
> > libavformat/hlsenc.c | 43 ++++++++++++++++++++++++++++-----------
> ----
> > 1 file changed, 28 insertions(+), 15 deletions(-)

> > +{
> > +    if (!path || *path == '\0')
> > +        return -1;
> > +
> > +    char *p = strrchr(path, '/');
> > +#if HAVE_DOS_PATHS
> > +    char *q = strrchr(path, '\\');
> > +    p = FFMAX(p, q);
> 
> You are comparing potentially NULL pointers here.


Hi Marton,

actually, there's a prequel to this patch, a simple form of which I had
submitted in 2022 and ended up in a discussion with Andreas:

https://lists.ffmpeg.org/pipermail/ffmpeg-devel/2022-January/291657.html


Obviously, this wasn't about performance-critical code in any way, but
as Andreas had insisted so much on it at that time, and there was also 
topic about null-pointer comparison, I actually wanted to go a very 
different route this time.
Looking at av_basename() (when HAVE_DOS_PATHS is enabled), it seemed 
to be easy to beat the tripled search by doing a single (reverse) 
search for all three chars.

So I created a function av_strrcspn(). The naming should be correct, 
while there's no strrcspn function in reality.

I tried various optimizations but I wasn't able to beta the triple
strrchar().

Code and benchmark are here, in case anybody is interested:
https://github.com/FFmpeg/FFmpeg/compare/master...softworkz:FFmpeg:test_av_strrcspn

I suspect that there's some parallelism/SIMD in strrchar() which 
makes it faster than expected.

Finally, I ditched that way and resorted to doing the same/similar
like in av_basename(). 
Now, either both a wrong or both are right...


Best regards,
sw