Description of problem: VLC can't rip DVD - cannot find video encoder, but launch as "LC_ALL=C vlc" is no issue. Version-Release number of selected component (if applicable): vlc-3.0.0-0.git.19.mga6.tainted How reproducible: with another localisation (e.g. czech) Steps to Reproduce: 1. Launch KDE Plasma with another localisation 2. Launch VLC: "$ vlc" 3. Go to Media > Convert / Save > Disc > Convert / Save > choose profile "Video for DivX compatible player" > choose the destination > Save > "VLC could not open the DIV3 video encoder." Works well when: 1. Launch VLC: "$ LC_ALL=C vlc" 2. Go to Media > Convert / Save > Disc > Convert / Save > choode profile "Video for DivX compatible player" > choose the destination > Save
CC: (none) => doktor5000
Assigning to ghibo as package maintainer. Status: testing, no solution found at this moment
CC: (none) => ghibomgx
Assigning to shlomif as package maintainer. For version MGA6, MGA7 Status: Still I can't find any solution for that. Is possible to test another higher version than vlc-3.0.0-0.git.23.mga7.tainted? Can anybody help? E.g. via #IRC, online remote desktop etc?
Assignee: pkg-bugs => shlomifVersion: 6 => CauldronSource RPM: vlc-3.0.0-0.git.19.mga6.tainted.src.rpm => vlc-3.0.0-0.git.23.mga7.tainted.src.rpm
Whiteboard: (none) => MGA6TOO
That is a very strange problem. Does it happen with a VLC built from the vlc 3.0 git master sources and installed under a --prefix ?
Trying with a new nightly 20170925, but build fails (the same build works backported under mga6) facing a problem similar to this one: https://trac.videolan.org/vlc/ticket/18468
(In reply to Giuseppe Ghibò from comment #4) > Trying with a new nightly 20170925, but build fails (the same build works > backported under mga6) facing a problem similar to this one: > https://trac.videolan.org/vlc/ticket/18468 That means libebml must be rebuilt in cauldron.
(In reply to Shlomi Fish from comment #3) > That is a very strange problem. Does it happen with a VLC built from the vlc > 3.0 git master sources and installed under a --prefix ? I have tried to compile a nightly 20170921 with build fails (missing ´lua´ package, even if I installed devel packages already, I should find a trick to navigate for libs or so). But I builded the vlc successfully with the same way as it written https://wiki.videolan.org/UnixCompile with the "Contrib" method without installation, just to run ./vlc. If I did all correctly, the result is the same - can´t find ´div3´. It seems to be upstream issue. I will attach an output log later. Can anybody replicate it? Thanks to all
Created attachment 9690 [details] czech test (In reply to Martin Volf from comment #6) > > Can anybody replicate it? > Yes, I just installed vlc tainted, but have never done anything like this before and nerozumím česky... inserting a random DVD in my DVD player and then taking the steps from comment #0 wasn't enough, though I had: Zdroj Zdroj: dvdsimple:///dev/sr0 Typ: dvdsimple Nastavení Převést (has a tick before it) Zobrazit výstup (no tick) Odstranit Prokládnání (no tick) Profil Video for DivX compatible player Dump raw input (no tick) Cíl Cílový soubor: /home/marja/Videa/test6.avi For me, it was _not_ after saving that destination, but after pressing "Spustit" in that screen that I got the error. I haven't tried with different languages, yet Attaching my terminal output .... here's part of it, starting with the first error I see: [9d4e2c80] core input error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR ! [msmpeg4v3 encoder @ 0x9d981560] [Eval @ 0x8a7f86dc] Invalid chars '.0' at the end of expression '1.0' [msmpeg4v3 encoder @ 0x9d981560] Unable to parse option value "1.0" [msmpeg4v3 encoder @ 0x9d981560] Error setting option qsquish to value 1.0. [9d4ab240] avcodec encoder error: cannot open DIV3 video encoder
CC: (none) => marja11
Created attachment 9691 [details] more complete crash output I must have done something wrong ... copying from the terminal in which I issued the command gives a much larger output and includes a backtrace
I can reproduce it with LANGUAGE=nl vlc LANGUAGE=en vlc using LC_ALL=C vlc doesn't give that error, and a large file is written, but it does crash, too.
If you compile vlc 2.2.5 standalone from scratch you get the same probs? I wonder if it's not a problem of libdvdread which is pretty old.
(In reply to Marja van Waes from comment #7) > Created attachment 9690 [details] > czech test > > (In reply to Martin Volf from comment #6) > > > > > Can anybody replicate it? > > > > Yes, I just installed vlc tainted, but have never done anything like this > before and nerozumím česky... inserting a random DVD in my DVD player and > then taking the steps from comment #0 wasn't enough, though > > I had: > > Zdroj > Zdroj: dvdsimple:///dev/sr0 > Typ: dvdsimple > > > Nastavení > Převést (has a tick before it) > Zobrazit výstup (no tick) > Odstranit Prokládnání (no tick) > Profil Video for DivX compatible player > Dump raw input (no tick) > > Cíl > Cílový soubor: /home/marja/Videa/test6.avi > > For me, it was _not_ after saving that destination, but after pressing > "Spustit" in that screen that I got the error. > > I haven't tried with different languages, yet > > Attaching my terminal output .... here's part of it, starting with the first > error I see: > [9d4e2c80] core input error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR ! > [msmpeg4v3 encoder @ 0x9d981560] [Eval @ 0x8a7f86dc] Invalid chars '.0' at > the end of expression '1.0' > [msmpeg4v3 encoder @ 0x9d981560] Unable to parse option value "1.0" > [msmpeg4v3 encoder @ 0x9d981560] Error setting option qsquish to value 1.0. > [9d4ab240] avcodec encoder error: cannot open DIV3 video encoder You have a good shot, Marja! That's exactly the procedure and the results as I am getting. Thanks for the output log. (In reply to Giuseppe Ghibò from comment #10) > If you compile vlc 2.2.5 standalone from scratch you get the same probs? I > wonder if it's not a problem of libdvdread which is pretty old. I am going to test it...
Btw, after downgrading vlc and all other tainted packages that I had installed to non-tainted versions the bug still did _not_ occur with "LC_ALL=C vlc" but still did occur when starting vlc in Czech.
If you want to see vlc in your own language: LC_NUMERIC=C vlc is enough to no longer get the "cannot open DIV3 video encoder" error. Maybe there's a comma or dot somewhere, that is misinterpreted? (1.234,567 in most or all european languages, is 1,234.567 in en_US)
Summary: VLC cannot find video encoder => VLC cannot find DIV3 video encoder, but does find it when vlc is started with "LC_NUMERIC=C"
and, actually, the error isn't that the encoder can't be found, but that it can't be opened :)
Summary: VLC cannot find DIV3 video encoder, but does find it when vlc is started with "LC_NUMERIC=C" => VLC cannot open DIV3 video encoder, but does find it when vlc is started with "LC_NUMERIC=C"
Summary: VLC cannot open DIV3 video encoder, but does find it when vlc is started with "LC_NUMERIC=C" => VLC cannot open DIV3 video encoder, but can open it when vlc is started with "LC_NUMERIC=C"
VLC 2.2.5 can't be build due to unsupported libavutils >=55 version. Tested with packages downgraded, results the same as Marja. Next test was to create a new user with EN localisation. VLC doesn't complain about "can't find div3" / "can't open div3" and no warning window appeared! Any idea?
Perhaps I'm going closer to find the fault, see attached screenshots. It doesn't complain only about 'div3', but for all DIVX codecs (see attached file "vlc_warning_window_logs.png"), if one is selected into the encoding parameters (see attached file "vlc_profile_setting.png"). Please note, see details of the warning, when DIVX1 is selected: "It seems your Libav/FFmpeg (libavcodec) installation lacks the following encoder: MS MPEG-4 Video v1. If you don't know how to fix this, ask for support from your distribution. This is not an error inside VLC media player. Do not contact the VideoLAN project about this issue."
Created attachment 9692 [details] vlc_profile_setting.png
Created attachment 9693 [details] vlc_warning_window_logs.png
(In reply to Martin Volf from comment #15) > > Next test was to create a new user with EN localisation. VLC doesn't > complain about "can't find div3" / "can't open div3" and no warning window > appeared! > > Any idea? England uses the dot as decimal separator, too, like the USA. https://en.wikipedia.org/wiki/Decimal_mark#/media/File:DecimalSeparator.svg most European countries use the comma. So it is still possible that "LC_NUMERIC=C vlc" doesn't show this bug here in a Dutch install (haven't tried Czech, yet), while "vlc" does show it, because of a dot/comma problem. Can you confirm that the "LC_NUMERIC=C vlc" workaround works for you, too?
From Marja's post, it sounds like the error may have nothing to do with finding or opening the codec, but rather with parsing the "1.0". However, it should be easy enough to check by reproducing under strace: strace -f -e open -o /tmp/strace vlc and see if an open fails that doesn't fail with LC=C and why.
Additional info: The part of the output log when DIVX1 is selected: [00007fcb040009d8] core input error: Invalid PCR value in ES_OUT_SET_(GROUP_)PCR ! [00007fcae4001128] avcodec encoder error: cannot find encoder MS MPEG-4 Video v1 *** Your Libav/FFmpeg installation is crippled. *** *** Please check with your Libav/FFmpeg packager. *** *** This is NOT a VLC media player issue. *** [00007fcb00003498] stream_out_transcode stream out error: cannot find video encoder (module:any fourcc:DIV1). Take a look few lines earlier to see possible reason. @Marja: yes, it works. Your idea I can see when I launch as 'vlc', DIVX3 is selected and then I can see the fault: [msmpeg4v3 encoder @ 0x7f469001b960] [Eval @ 0x7f469bc78f70] Invalid chars '.0' at the end of expression '1.0' [msmpeg4v3 encoder @ 0x7f469001b960] Unable to parse option value "1.0" [msmpeg4v3 encoder @ 0x7f469001b960] Error setting option qsquish to value 1.0. [00007f46900013d8] avcodec encoder error: cannot open DIV3 video encoder
Actually, make that strace -f -e trace=file -o /tmp/strace vlc since a lot of code does "stat" before actual open, and it may be that failing.
Created attachment 9694 [details] strace -f -e open -o /tmp/strace vlc with DIVX3, czech localisation
(In reply to Martin Volf from comment #23) > Created attachment 9694 [details] > strace -f -e open -o /tmp/strace vlc > > with DIVX3, czech localisation Actually, the bit of interest is the resulting /tmp/strace file which will show all of the file-related system calls and any error codes.
CC: (none) => ftg
Created attachment 9695 [details] /tmp/strace Sorry for that. Here it is
Can you try it with -e trace=file ? That will also show where the stdout/stderr messages are being issued.
Created attachment 9696 [details] strace -e trace=file vlc
OK, the strace shows no file-related failure, so the cause must be the period versus comma clash.
(In reply to Frank Griffin from comment #28) > OK, the strace shows no file-related failure, so the cause must be the > period versus comma clash. Thanks a lot for your help, Frank! I'm glad you know how to read a strace output :-) I haven't managed to find a bug report or forums thread on https://www.videolan.org/ about this issue. That doesn't mean it doesn't exist :-/
So, what we can do more? Report it to VLC upstream or some patch will be applied? As we now, to run with 'LC_NUMERIC=C vlc" (or in System Setting → Locale → Formats → click to check-box → Numbers → change to 'Default C' → new login) helps.
Googling "error qsquish" gives one of the hits as https://ffmpeg.org/ffmpeg-codecs.html . From that page: qsquish float (encoding,video) How to keep quantizer between qmin and qmax (0 = clip, 1 = use differentiable function). This would indicate that the bug is in ffmpeg (or its immediate user). My guess is that somebody is using a locale-specific decimal decode routine to decode a floating point value. AFAIK, floating-point syntax does not vary by locale, and 1.0 should be valid anywhere. I can't find any reference to such a bug either. I'd report it to the ffmpeg devs and ask if they can provide any insight on who provides and parses qsquish values. Then check the changelogs for those projects.
Does it work OK now on Mageia 7 and 8? Note vlc-3.0.12.1-1.1.mga7.x86_64 is in testing.
CC: (none) => fri
That is a peculiar dilemma. Is this the case when VLC is constructed from the vlc 3.0 git master sources and installed with the —prefix option? https://cookieclicker2.io
CC: (none) => aricjoshua44
Hi, This issue there is here still in vlc 3.0.16, in mageia 8 Plasma Kde x86-64.
CC: (none) => joselpddj