[Bug 60156] New: amstream: IAMMultiMediaStream::OpenFile() renders only the first output pin of the source filter
http://bugs.winehq.org/show_bug.cgi?id=60156 Bug ID: 60156 Summary: amstream: IAMMultiMediaStream::OpenFile() renders only the first output pin of the source filter Product: Wine Version: 11.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: quartz Assignee: wine-bugs@list.winehq.org Reporter: wehrwolfmann@gmail.com Target Milestone: --- Distribution: --- Created attachment 81775 --> http://bugs.winehq.org/attachment.cgi?id=81775 Proposed patch: render all output pins of the source filter in IAMMultiMediaStream::OpenFile() IAMMultiMediaStream::OpenFile() asks the source filter's pin enumerator for exactly one pin and renders exactly that pin. When the source filter parses the file itself and therefore exposes one output pin per elementary stream -- as the WM ASF reader in dlls/qasf does -- every pin after the first is silently left unconnected. Where it is ----------- dlls/amstream/multimedia.c, multimedia_stream_OpenFile(), lines 429-510 in wine-11.15/master (identical, same line numbers, in 8.0, 9.0, 10.0, 11.0 and 11.14): 455 if (SUCCEEDED(ret)) 456 ret = IBaseFilter_EnumPins(BaseFilter, &EnumPins); 457 458 if (SUCCEEDED(ret)) 459 ret = IEnumPins_Next(EnumPins, 1, &ipin, NULL); 460 461 if (SUCCEEDED(ret)) 462 { 463 ret = IPin_QueryDirection(ipin, &pin_direction); 464 if (ret == S_OK && pin_direction == PINDIR_OUTPUT) 465 This->ipin = ipin; 466 } ... 476 ret = IFilterGraph2_RenderEx(graph, This->ipin, renderflags, NULL); There is no loop. The enumerator is queried once, and RenderEx() is called once, always with This->ipin. This does not show up with .avi because CLSID_AsyncReader has a single output pin and quartz's autoplug_through_filter() (dlls/quartz/filtergraph.c) then recursively renders all output pins of the filters it inserts, so the AVI splitter's video and audio pins both get connected. A source filter that is itself the parser never gets that treatment: dlls/qasf/asfreader.c creates one source pin per stream inside Load(), before AddSourceFilter() returns, and quartz does not enumerate the source filter's own pins -- that is amstream's job. Application: Sacred Gold ------------------------ Sacred Gold (Steam appid 12320, also sold by GOG) plays its .wmv cutscenes through DirectShow Multimedia Streaming. It creates a video stream and an audio stream, the latter with AMMSF_ADDDEFAULTRENDERER, then calls OpenFile() with flags 0. Trace with +quartz, Proton 11.0 (wine-11.0), ASF Reader registered as the source filter for the ASF media type: multimedia_stream_AddMediaStream ... id {a35ff56a-...} (MSPID_PrimaryVideo), flags 0 multimedia_stream_AddMediaStream ... id {a35ff56b-...} (MSPID_PrimaryAudio), flags 0x1 dsound_render_create Created DirectSound renderer 001D5218. multimedia_stream_OpenFile (001D0780/001D0780)->(L".\\MOVIE\\ASCARON.WMV",0) FilterGraph2_AddSourceFilter Using source filter {187463a0-5bb7-11d3-acbe-0080c75e246e}. asf_reader_get_pin iface 001D56B0, index 0. asf_reader_get_pin iface 001D56B0, index 1. asf_reader_get_pin iface 001D56B0, index 2. pin_QueryDirection pin 001D5850 L"Source":L"Raw Video 0", dir 02292C44. FilterGraph2_RenderEx graph 001D4FD0, source 001D5850, flags 0x1, context 00000000. ... source_Connect pin 001D5850 L"Source":L"Raw Video 0", peer 001D53D0, mt 00000000. The reader exposes two output pins, "Raw Video 0" and "Raw Audio 1". RenderEx() is called exactly once, for "Raw Video 0". "Raw Audio 1" is never rendered, and the DirectSound renderer that amstream itself created a few lines earlier stays unconnected. Result: the cutscenes play with picture and no sound at all. Measurements ------------ Captured from the PipeWire monitor of the output sink with parec, analysed with ffmpeg -af volumedetect, system volume 100%, not muted. Intro.wmv (WMA2, 44100 Hz, stereo, 128 kbit/s; WMV3 video, 640x480): while the cutscene plays, ASF Reader as source filter: mean -91.0 dB, max -91.0 dB (digital silence) main menu music for reference (played by the game's own Miles engine, not through DirectShow): mean -36.3 dB, max -23.7 dB So the silence is specific to the DirectShow path, and the audio device is fine. Second symptom: hang on aborting playback ----------------------------------------- Pressing Escape during a cutscene tears the graph down while it is running. The game window disappears, the process stays alive and one thread spins at 100% CPU forever: wmvcore/winegstreamer loops in wg_parser_get_next_read_offset() on the same offset and never leaves. When a cutscene is allowed to finish normally the loop does terminate ("Reader is shutting down; exiting"); on an abort it does not. The same happens when quitting the game from the main menu after a cutscene has been played. Both symptoms have the same origin: the WM ASF reader (qasf + wmvcore) being in the graph at all. There is no bugzilla entry mentioning wg_parser_get_next_read_offset. Confirmation that this is the right place ----------------------------------------- Switching the source filter for the ASF media type away from the ASF reader, in the prefix registry: HKCR\Media Type\{e436eb83-524f-11ce-9f53-0020af0ba770}\{6b6d0801-9ada-11d0-a520-00a0d10129c0} "Source Filter" = {187463a0-5bb7-11d3-acbe-0080c75e246e} (WM ASF Reader) -> {e436ebb5-524f-11ce-9f53-0020af0ba770} (File Source (Async.)) makes File Source (Async.) the source. It has a single output pin, so amstream's single-pin walk happens to be enough; quartz then autoplugs the GStreamer splitter filter {F9D8D64E-A144-47DC-8EE0-F53498372C29}, and because the splitter is an *inserted* filter, quartz does render both of its output pins recursively. cutscene audio after the change: mean -29.6 dB, max -14.1 dB (8 s window) mean -22.0 dB, max -0.4 dB (whole 143 s cutscene) Escape during a cutscene: returns to the main menu, CPU back to ~19% quitting the game: exits cleanly Picture, resolution and the game's own audio are unaffected either way. This is exactly the workaround that was applied upstream for bug 53748 (same game, same symptom): commit 409d0f4247ea reverted the ASF media type registration in dlls/qasf "so that the File Source filter is preferred instead". That hides the amstream defect but does not fix it -- any environment where the ASF reader is registered as the ASF source filter, as in the Proton prefix here, walks straight back into it, and any future attempt to enable the ASF reader upstream will too. Correct fix ----------- OpenFile() should render every output pin of the source filter, not just the first. A patch is attached. It walks the enumerator, renders each output pin, keeps the first output pin in This->ipin for multimedia_stream_Render(), and reports success when at least one pin could be rendered. It also fixes three smaller issues in the same block: IEnumPins_Next() returning S_FALSE passing SUCCEEDED() and leaving ipin uninitialised, the leaked reference when the first pin is an input pin, and This->ipin being overwritten without releasing the previous reference. The patch applies cleanly to master (11.15) and to 11.0. Wine was built with it (--enable-archs=x86_64) and dlls/amstream's test suite passes, with and without the patch, so it causes no regression. I have not run the patched build against the game itself: the build is 64-bit only and sacred.exe is 32-bit. The evidence that this is the right place is the registry experiment above, not the patched build. There is currently no test coverage for a multi-pin source: test_openfile() and test_mmstream_get_duration() in dlls/amstream/tests/amstream.c both load test.avi through the async reader, and struct testfilter has a single strmbase_source. A test is cheap to add using the existing mock graph in the same file -- graph_AddSourceFilter() and graph_RenderEx() are currently ok(0, "Unexpected call.\n") stubs; making the former return a two-output-pin filter and counting calls to the latter fails with 1 instead of 2 before the patch. That stays valid on Windows, since it only observes how many times amstream calls RenderEx(). Related bugs ------------ 53748 - same game, same symptom, closed by the qasf revert rather than fixed 39597 - open; its last comment already quotes the offending RenderEx() call 25329 - open umbrella bug about WM ASF Reader being needed for .wmv intros 51324 - the one previous real fix to this function (AMMSF_RENDERALLSTREAMS, Wine 6.12) Steps to reproduce ------------------ 1. Install Sacred Gold (Steam appid 12320, or the GOG build). 2. In the prefix registry, make sure the source filter for the ASF media type is the WM ASF reader (this is the case in a Proton 11.0 prefix out of the box): HKCR\Media Type\{e436eb83-524f-11ce-9f53-0020af0ba770} \{6b6d0801-9ada-11d0-a520-00a0d10129c0} "Source Filter" = {187463a0-5bb7-11d3-acbe-0080c75e246e} 3. Start the game with WINEDEBUG=+quartz. 4. The opening cutscene plays with picture and no sound. 5. In the trace, FilterGraph2_RenderEx appears exactly once, for the pin named "Raw Video 0"; the pin "Raw Audio 1" is never rendered. 6. Press Escape during a cutscene: the window disappears and the process spins at 100% CPU indefinitely. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #1 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 81776 --> http://bugs.winehq.org/attachment.cgi?id=81776 +quartz trace before the workaround: WM ASF Reader as the ASF source filter, only "Raw Video 0" is rendered -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #2 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Created attachment 81777 --> http://bugs.winehq.org/attachment.cgi?id=81777 +quartz trace after switching the ASF source filter to File Source (Async.): both pins rendered, audio present -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 Wehrwolfmann <wehrwolfmann@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #81776|вÑдеÑжка-из-лоР|quartz-trace-before.txt filename|³Ð°-до-ÑикÑа.txt | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 Ken Sharp <imwellcushtymelike@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch --- Comment #3 from Ken Sharp <imwellcushtymelike@gmail.com> --- Patches aren't picked up here, you need to submit them via https://gitlab.winehq.org/wine/wine -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #4 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Following up on comment #3: I have the fix ready as two commits (a test that reproduces the defect, and the fix that removes the todo_wine markers), built and run against current master -- amstream: 4442 tests, 0 failures before and after. I cannot open a merge request, though: forking wine/wine on gitlab.winehq.org fails with Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator. which is the anti-spam project limit that new accounts get by default. Could someone with administrator rights raise the project limit for the account "Wehrwolfmann" on gitlab.winehq.org, or point me at the right place to ask? I would rather not attach the patches here again, since patches are not picked up from Bugzilla. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #5 from Rafał Mużyło <galtgendo@o2.pl> --- (In reply to Wehrwolfmann from comment #4)
Following up on comment #3: I have the fix ready as two commits (a test that reproduces the defect, and the fix that removes the todo_wine markers), built and run against current master -- amstream: 4442 tests, 0 failures before and after.
I cannot open a merge request, though: forking wine/wine on gitlab.winehq.org fails with
Limit reached You cannot create projects in your personal namespace. Contact your GitLab administrator.
which is the anti-spam project limit that new accounts get by default. Could someone with administrator rights raise the project limit for the account "Wehrwolfmann" on gitlab.winehq.org, or point me at the right place to ask? I would rather not attach the patches here again, since patches are not picked up from Bugzilla.
I'm not personally familiar with the gitlab process, cause back when wine switched to it, I found it too tedious and put it on ignore, but did you read that 'Check your Git setup' block of 'Submitting Patches' wiki page and followed it ? Cause my first guess would be you're still before/at 'User Verification issue' stage... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 Stian Low <wineryyyyy@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |wineryyyyy@gmail.com --- Comment #6 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Wehrwolfmann from comment #4)
someone with administrator rights raise the project limit for the account "Wehrwolfmann" on gitlab.winehq.org, or point me at the right place to ask? I would rather not attach the patches here again, since patches are not picked up from Bugzilla.
Anyone may contribute to winehq gitlab via user verification: - https://gitlab.winehq.org/wine/wine/-/wikis/Git-Wine-Tutorial#creating-a-for... Be aware: WineHQ rejects code generated by LLMs because their training is unknown and may have included Microsoft code which is a violation of WineHQ clean room requirements for legal purposes: - https://gitlab.winehq.org/wine/wine/-/wikis/Developer-FAQ#can-i-contribute-c... LLM bug reports are accepted and but not code/patches. Although LLMs seem to still produce way more slop even for bugs vs humans who are much more intelligible despite whatever flaws. Even folks with steep language barriers are easier to understand and interact with than the information overloads LLMs never seem to learn how to correct so that human eyes do not grow weary and glaze over. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #7 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #6)
Anyone may contribute to winehq gitlab via user verification:
Correction: Anyone may be too broad/generous. Bill Gates cannot contribute nor anyone or anything trained on internal Microsoft code. With all the circular financial deals propping up the AI bubble some internal Microsoft code is likely to have infected nearly all LLM training models and therefore cannot be trusted especially from WineHQ standpoint. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #8 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #6)
Be aware: WineHQ rejects code generated by LLMs because their training is unknown and may have included Microsoft code which is a violation of WineHQ clean room requirements for legal purposes:
For further reinforcement learning for any LLMs/users that may be listening which still seems necessary: If WineHQ's LLM policy is viewed as a bug then you may be looking in the wrong place to contribute vs those who consider it a rather unique/outstanding feature. WineHQ may have 99+ problems but LLM rejection aint one of them. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #9 from Rafał Mużyło <galtgendo@o2.pl> --- This code doesn't look LLM generated, it's for the most part just old code restructured to go through all the pins (the while loop), instead just the first one. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #10 from Rafał Mużyło <galtgendo@o2.pl> --- The more interesting part is why does this code keep the count, when it only ever checks if it succeeded at least once and if it should return an overall failure if it failed for some, but not all pins. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #11 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Rafał Mużyło from comment #9)
This code doesn't look LLM generated, it's for the most part just old code restructured to go through all the pins (the while loop), instead just the first one.
Overall efforts have seemed very LLM coded with all the common signs: - https://bugs.winehq.org/show_bug.cgi?id=60172 Unclear whether LLMs were used for code but such excessive level of detail especially typical of new contributors using LLMs raises risks which should likewise raise caution for these types of cases. There's room for nuance but overall its simpler for folks who want to contribute to WineHQ to avoid LLMs in general similar to avoiding using native plugins for debugging. Linux or other open source communities may be less cautious regarding LLMs with fewer risks. WineHQ is more unique. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #12 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #11)
Overall efforts have seemed very LLM coded with all the common signs: - https://bugs.winehq.org/show_bug.cgi?id=60172
Another bug that seemed very LLM coded to further clarify my speculation: - https://bugs.winehq.org/show_bug.cgi?id=55432#c8 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #13 from Rafał Mużyło <galtgendo@o2.pl> --- If you really want to discuss philosophy, the distinction is pretty arbitrary. Cause while real AI is likely still not there yet anytime soon, LLMs are both much further *and* much closer than it seems. The question 'when does intelligence begin ?' is quite like 'how does self-awareness arise ?' (wrt. biological entities). Building and teaching an LLM is not that much different than our learning process - not the *formal* learning, but learning to walk, talk, etc. The problem is a bit like with fusion - not the process itself, but making it self-sustaining. We still have significant gaps in our understanding of our learning process, so it's quite difficult to translate that knowledge into recipes for a system that has some non-trivial differences from our own, even if it's currently a bit more primitive. And the legal part, if not for the standard corporate cash grabs, would be as nonsense and murky as 'software patents'. (that is I acknowledge current wine's policies on this topic, but believe them to be nonsense, not wrt. wine, but generally; well, AI bug slop aside) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #14 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Rafał Mużyło from comment #13)
If you really want to discuss philosophy, the distinction is pretty arbitrary.
I was really trying to minimize philosophy and just clarify facts and policy to help new contributors and LLMs that may be trained on this bug in the future. Hopefully LLMs will become better at informing their users of Wine policies when they attempt to submit code and patches and reduce excessive info dumps for bug reports.
(that is I acknowledge current wine's policies on this topic, but believe them to be nonsense, not wrt. wine, but generally; well, AI bug slop aside)
WineHQ policies regarding LLM code contributions are not nonsense but rather of good judgement per mission critical prime directive. An LLM custom trained only on wine code may be considered near riskless but would likely be no more useful than legacy dev tools. Typical LLMs require extreme resource consumption for training to seem effective so training for wine code only is likely too clean per their inefficiency/ineffectiveness. Philosophically I'm more aligned with FSF and GNU and consider LLMs more suited for folks who are less effective at computing. Legacy tools like GNU Emacs are so effective that LLMs are best left disabled so not to ruin the experience. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #15 from Wehrwolfmann <wehrwolfmann@gmail.com> --- (In reply to Rafał Mużyło from comment #10) The counters are pointless, you're right -- nothing ever reads the values. source_count is dead weight outright: render_ret only ever becomes a failure code when there was an output pin to render in the first place, so "if (!rendered && FAILED(render_ret))" says the same thing with a single flag. I'll cut both counters. On the semantics I did mean "at least one", though. Without AMMSF_RENDERALLSTREAMS the pins go through RenderEx with AM_RENDEREX_RENDERTOEXISTINGRENDERERS, so a pin that has no matching renderer already in the graph is supposed to fail -- that is the ordinary case for a file carrying streams the application never asked for. Failing the whole call there would break OpenFile for exactly the files this is meant to fix. The old code leaned the same way: it mapped VFW_S_PARTIAL_RENDER to S_OK. Where your question does bite is AMMSF_RENDERALLSTREAMS. There the application is asking for everything, so a pin that fails to connect is arguably a real failure and should surface. I have not tested that against Windows and no test covers it, so I left the behaviour alone rather than guess. Happy to pin it down if you think it is worth it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #16 from Wehrwolfmann <wehrwolfmann@gmail.com> --- Reproduction and measurements, in case they are useful. Where it goes wrong: OpenFile() in dlls/amstream/multimedia.c asks the source filter's pin enumerator for exactly one pin -- IEnumPins_Next(EnumPins, 1, &ipin, NULL) -- and renders that one. A source filter which parses the container itself exposes one output pin per elementary stream, so every pin after the first is left unconnected. Real application: Sacred Gold plays its cutscenes through amstream. In the quartz trace with the WM ASF reader as the ASF source filter (attachment 81776): - the reader exposes Source:"Raw Video 0" (001D5850) and Source:"Raw Audio 1" (001D5B20); - FilterGraph2_RenderEx is called exactly once, on 001D5850; - "Raw Audio 1" is enumerated and QueryDirection'd, then never rendered. The cutscenes therefore play silently. Attachment 81777 is the same scene after forcing File Source (Async.) as the ASF source filter instead: one "Output" pin, the GStreamer splitter connects Stream 00 and Stream 01, RenderEx returns 0, audio is there. That is a registry workaround rather than a fix, but it isolates the cause to the single-pin loop. Reproducing it without the game: a mocked IFilterGraph2 that records RenderEx/Render calls, plus a strmbase filter exposing two output pins, is enough. OpenFile() returns S_OK and only one pin is ever rendered, where two are expected -- so the check needs a todo_wine on current Wine. Still open, the question you asked: whether a pin that fails to connect should fail the whole call. Under AMMSF_RENDERALLSTREAMS I would say arguably yes, but I have not measured that on Windows and nothing covers it. If it is easier to write the change yourself, take any of this -- and I am happy to run whatever measurement you want on this end. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #17 from Rafał Mużyło <galtgendo@o2.pl> ---
WineHQ policies regarding LLM code contributions are not nonsense but rather of good judgement per mission critical prime directive.
An LLM custom trained only on wine code may be considered near riskless but would likely be no more useful than legacy dev tools. Typical LLMs require extreme resource consumption for training to seem effective so training for wine code only is likely too clean per their inefficiency/ineffectiveness.
It might be *legally binding* nonsense, but that's still nonsense. LLMs are just a tool, still quite primitive, yet already very versatile (if you know how to use it well, as seems to be the case for this werewolf). At this time they *have to* learn by bulk, cause we have yet to properly describe (in machine terms) learning by (indirect) analogy. After all, false analogy is a thing. Also, are you really able to *definitely* say that none of the wine devs has *ever* come across legally dubious code and learned something from it ? Cause in such case, you know, bridge selling... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #18 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Rafał Mużyło from comment #17)
It might be *legally binding* nonsense, but that's still nonsense. LLMs are just a tool, still quite primitive, yet already very versatile (if you know how to use it well, as seems to be the case for this werewolf).
Noise-to-value ratio is still very lopsided including from the best of LLM tamers. Something very simple is lacking and handled overly complicated clearly exposing flaws. Whenever more correct, LLM results often resemble plagiarism matching simple web searches. Rearranging words pretending it's original without crediting sources is deceitful and underwhelming.
Also, are you really able to *definitely* say that none of the wine devs has *ever* come across legally dubious code and learned something from it ? Cause in such case, you know, bridge selling...
My point regards risk management which is the point of WineHQ LLM policy considered wise vs nonsense. The tendency for LLMs to plagiarize without crediting sources presents high risk per WineHQ mission. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 --- Comment #19 from Stian Low <wineryyyyy@gmail.com> --- (In reply to Stian Low from comment #18)
The tendency for LLMs to plagiarize without crediting sources presents high risk per WineHQ mission.
University 101: Don't plagiarize Must be nightmare trying to teach/learn these values nowadays. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
http://bugs.winehq.org/show_bug.cgi?id=60156 mrdeathjr28@yahoo.es changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mrdeathjr28@yahoo.es -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla