On Fri, 01 Dec 2017, Carlos E. R. wrote:
On Friday, 2017-12-01 at 02:51 +0100, David Haller
On Wed, 29 Nov 2017, Carlos E. R. wrote:
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
2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] Detected desktop OpenGL
2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] GL_VENDOR='NVIDIA
2017-11-29 23:27 - vidcutter.libs.mpvwidget - INFO - [opengl-cb] GL_RENDERER='GeForce
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
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
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).
How do I disable it?
Settings -> Video -> Playback -> [ ] Hardware decoding
There is no command line option in vidcutter to do
The above probably sets
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_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
Hm. That looks ok.
2017-11-29 23:27 - vidcutter.libs.videoservice - 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 - <class
'simplejson.scanner.JSONDecodeError'>: Expecting value: line 1 column 2 (char
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:
import simplejson as json
#import json as json
fh = open(sys.argv, "r")
$ python3 t.py 85780054.json
$ python3 t.py 85780054_err.json
Traceback (most recent call last):
File "t.py", line 7, in <module>
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
--- 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:
- args = '-v error -show_streams -show_format -of json
+ args = '-v fatal -show_streams -show_format -of json
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
If it works, I guess the vidcutter guys would like a bugreport and
possibly a (sample) of the offending file(s).
>  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
> 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
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.
PS: I can't even program python ;)
Reporter (to Mahatma Gandhi): Mr Gandhi, what do you think of Western
Gandhi: I think it would be a good idea.
To unsubscribe, e-mail: opensuse+unsubscribe(a)opensuse.org
To contact the owner, e-mail: opensuse+owner(a)opensuse.org