Dear Michael, Community Committee and FFmpeg community,
At the end of January 2026 I sent a PR that adds a WHEP demuxer:
https://code.ffmpeg.org/FFmpeg/FFmpeg/pulls/21603
I spent several weeks working on it.
The PR splits whip.c into a WHIP-specific part and a common WebRTC part,
so I asked Jack Lau and Steven Liu to prioritize the review, because any
work on WHIP in the meantime would cause conflicts.
Unfortunately, the PR was ignored. It got no review on the substance,
the only reply from Jack Lau was:
> I'd prefer improving current WHIP implementation for future
maintainability, then support WHEP feature this year.
Already back then this seemed strange to me. What does it even mean? I
offered ready code and only asked for a review. I was ready to maintain
my code myself, but formally I needed an approval from the WHIP
maintainer, because the PR touches whip.c (WHIP part is just a move of
the code, almost without functional changes).
On October 9 Michael asked me to rebase the PR on the current master. It
took me about a week of work, because of the conflicts I mentioned above
and because I had to fully retest the demuxer.
While doing it, I noticed that the WHIP implementation hasn't improved
much in the last 9 months. Even simple bugs that I mentioned or fixed in
my PR are still not fixed.
I wondered what was being worked on then, and to my big surprise I found
that from May 2026, about three months after my PR, a student worked on
a WHEP demuxer as a Google Summer of Code 2026 project, mentored by the
same Jack Lau and Steven Liu:
https://summerofcode.withgoogle.com/programs/2026/projects/JhXI42g2
Two of FFmpeg's three GSoC 2026 projects were WHIP and WHEP, both with
the same mentors. Jack Lau definitely knew about my PR, since he replied
in it, and both of them were requested as reviewers.
So I don't think it's possible to say the maintainers had no time for a
review.
An even bigger surprise was that the GSoC project was marked as passed
in August, but there is no WHEP code in the FFmpeg repository. It turned
out the work was done in a separate repository,
https://github.com/ossrs/ffmpeg-webrtc, and the WHEP demuxer never
reached FFmpeg. According to the student's final report, SRTP and
receiving media were still in the "What's next" list:
https://gist.github.com/Nariman-Sayed/b62504b6725f438cd3400193285ac974
In my opinion this result is much less complete than my PR from February
2026, but I'll leave that to the community.
This is my personal opinion and I can't prove it, but I believe Jack Lau
and Steven Liu deliberately put my PR aside in favour of their GSoC
project. Either way, FFmpeg didn't win from this. If my code is suitable
for FFmpeg, then:
1. FFmpeg would have had WHEP support almost a year earlier.
2. I could have spent this time improving WHEP and WHIP (some of the
minor bugs come from the common code I split out of WHIP).
3. FFmpeg could have used the GSoC slot for another useful feature.
4. The same work wouldn't have been done twice.
Nobody pays me for upstreaming this work. I only spend my time, and my
money on testing.
I would understand and accept it if my code wasn't suitable for FFmpeg
for some reason. But ignoring it in this context doesn't look good or
ethical.
Since there is a clear conflict of interest here, I ask to appoint an
independent reviewer for this PR, so that it finally gets a review and
it's decided whether it fits FFmpeg or not.
I also ask Michael and the Community Committee to look into this
situation and give their assessment.
Thank you for your understanding.
Artem Smorodin
_______________________________________________
ffmpeg-devel mailing list -- [email protected]
To unsubscribe send an email to [email protected]
