Hello, On Fri, 01 Dec 2017, Carlos E. R. wrote:
On Friday, 2017-12-01 at 02:51 +0100, David Haller wrote:
On Wed, 29 Nov 2017, Carlos E. R. wrote: [..]
cer@Telcontar:~/Fusion/Hacer/Trek> vidcutter --debug p.mpeg [..] 2017-11-29 23:27 - vidcutter.libs.mpvwidget
Looks like vidcutter uses an embedded mpv for display...
- INFO - [opengl-cb] GL_VERSION='3.3.0 NVIDIA 340.102' 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] Detected desktop OpenGL 3.3. 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] GL_VENDOR='NVIDIA Corporation' 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] GL_RENDERER='GeForce 9500 GT/PCIe/SSE2' [..] 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] Loading hwdec driver 'vaapi-glx' 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb/vaapi-glx] Not using this by default. 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] Loading failed. 2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] Loading hwdec driver 'vdpau-glx'
Try disabling the vdpau-glx driver too. The HW-decoders are rather limited in regard to supported features of the codecs and may barf on stuff that software-decoders (e.g. from ffmpeg) plays without problem. It's why I stopped using hw-decoding it at all (and using hw-encoding)[1].
How do I disable it?
Settings -> Video -> Playback -> [ ] Hardware decoding
There is no command line option in vidcutter to do that.
The above probably sets hwdec=no in the [General] section of ~/.config/vidcutter/vidcutter.ini
2017-11-29 23:27 - vidcutter.libs.videoservice - INFO -
/usr/bin/ffprobe -hide_banner -v error -show_streams \ -show_format -of json "/home_aux/cer/Fusion/Hacer/Trek/p.mpeg"
Could you paste.opensuse.org the output of that ffprobe command?
cer@Telcontar:~/Fusion/Hacer/Trek> ffprobe -hide_banner -v error -show_streams -show_format -of json p.mpeg > ffprobeoutput.txt [h264 @ 0xa911e0] mmco: unref short failure cer@Telcontar:~/Fusion/Hacer/Trek> [..] http://susepaste.org/85780054
Hm. That looks ok.
2017-11-29 23:27 - vidcutter.libs.videoservice - ERROR - Error decoding ffprobe JSON output
As that what the python-code seems to barf on parsing...
Yes, and ffprobe has an error, too. I see.
I debugged it: the actual json output parses ok, but when adding the error from ffprobe, I get exactly the JSON decoder error:
2017-11-29 23:27 - root - CRITICAL -
: Expecting value: line 1 column 2 (char 1) You could also try updating python3-simplejson (if that does not pull in too much other stuff) from d:l:py (and downgrade back if it does not help). Could be that vidcutter expects a rather new version of the simplejson module (just guessing though).
Could try... As long as that doesn't break other things.
I tested it now with both simplejson-3.13.2 as well as 3.10.0. BTW: try it with this snippet: ==== #!/usr/bin/python3 import sys import simplejson as json #import json as json fh = open(sys.argv[1], "r") json.load(fh) fh.close() ==== $ python3 t.py 85780054.json $ python3 t.py 85780054_err.json Traceback (most recent call last): File "t.py", line 7, in <module> json.load(fh) [..] simplejson.scanner.JSONDecodeError: Expecting value: line 1 column 2 (char 1) (resp. when using the builtin json parser instead of simplejson): $ python3 t.py 85780054_err.json json.decoder.JSONDecodeError: Expecting value: line 1 column 2 (char 1) BTW: vidcutter first tries simplejson and then uses the builtin or dies. And simplejson is the "upstream" for the builtin. So you need to get rid of the ffprobe error. Try this patch with 'patch -p1 < the_patchfile' from inside your python3-dir: ==== vidcutter-5.0.5-ffprobe.patch ==== diff -x '*~' -purN a/site-packages/vidcutter/libs/videoservice.py b/site-packages/vidcutter/libs/videoservice.py --- a/site-packages/vidcutter/libs/videoservice.py 2017-12-02 19:17:08.048806154 +0100 +++ b/site-packages/vidcutter/libs/videoservice.py 2017-12-02 19:17:54.152807157 +0100 @@ -454,7 +454,7 @@ class VideoService(QObject): def probe(self, source: str) -> bool: try: - args = '-v error -show_streams -show_format -of json "{}"'.format(source) + args = '-v fatal -show_streams -show_format -of json "{}"'.format(source) json_data = self.cmdExec(self.backends.ffprobe, args, output=True) self.media = Munch.fromDict(json.loads(json_data)) return hasattr(self.media, 'streams') and len(self.media.streams) ==== Alternatively just edit site-packages/vidcutter/libs/videoservice.py manually. If it still doesn't work, try using other "loglevels", see option '-v' in 'man ffprobe' (i.e. try '-v panic', '-v quiet'). If it works, I guess the vidcutter guys would like a bugreport and possibly a (sample) of the offending file(s).
[1] I routinely get half the filesize by reencoding the files from the public tv-stations, just by using a variable bitrate and the internal de-noiser of x264 at "nr=750"... e.g. one that had about 2256kbps (IIRC just video) is down to 862kpbs (including 1 audio AAC). mencoder -nosound -ovc x264 -x264encopts \ crf=23:trellis=1:qcomp=0.8:weight_b:8x8dct:subq=6:nr=750:threads=1 \ -o out.avi in.mp4 && mkvmerge -o out.mkv out.avi -D in.mp4 (and after checking: rm out.avi in.mp4 ;) No scaling in that case.
I forgot to mention, if you don't want to remux anyway to mkv, you can use '-oac copy' instead of '-nosound' and skip the mkvmerge. Reason for me is that _my_ old mencoder barfs on copying aac audio. And I'm not sure if it's still recommended not to use the -af mkv muxer but use mkvmerge instead as I do.
Thanks for the hint :-)
Foir the moment, I was not looking at recoding at all, but just to remove commercials in the middle and the lead/tail sections, which sometimes are half of the file.
Yeah, and with recoding, you'd might get down to 25% ;) Always depends on the sizes ;) If I can get a file down from 3GB+ to about 1.2GB ... On the other hand, if getting a file from 400M to 200M in a few minutes... And as long as (my) CPU cores have nothing else to do ... BTW: you can also set nr= inside avidemux (second tab in the x264 settings IIRC). Anyway: if you get constant-BR streams or other stuff, it's sometimes really astonishing how much you can save while reencoding. the "crf=23" has so far always been more than good enough and the 'nr=750' might make it even a touch less noisy, but mostly the nr= removes (inside the x264 codec!) tons of noise that'd result in frames differences, which thusly won't have to be encoded at all. If you _see_ the noise and want to remove that, nr= is not what you need, that's not "strong" enough by far. But it's very efficient at removing stuff that'd blow up frame-diffs. Even with "normal" VBR encoded stuff, I got 20%-30% less size in the result, just by adding the nr= option for x264. HTH, -dnh PS: I can't even program python ;) -- Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western Civilization? Gandhi: I think it would be a good idea. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org