
Recherche avancée
Autres articles (43)
-
Supporting all media types
13 avril 2011, parUnlike most software and media-sharing platforms, MediaSPIP aims to manage as many different media types as possible. The following are just a few examples from an ever-expanding list of supported formats : images : png, gif, jpg, bmp and more audio : MP3, Ogg, Wav and more video : AVI, MP4, OGV, mpg, mov, wmv and more text, code and other data : OpenOffice, Microsoft Office (Word, PowerPoint, Excel), web (html, CSS), LaTeX, Google Earth and (...)
-
MediaSPIP v0.2
21 juin 2013, parMediaSPIP 0.2 is the first MediaSPIP stable release.
Its official release date is June 21, 2013 and is announced here.
The zip file provided here only contains the sources of MediaSPIP in its standalone version.
To get a working installation, you must manually install all-software dependencies on the server.
If you want to use this archive for an installation in "farm mode", you will also need to proceed to other manual (...) -
Installation en mode ferme
4 février 2011, parLe mode ferme permet d’héberger plusieurs sites de type MediaSPIP en n’installant qu’une seule fois son noyau fonctionnel.
C’est la méthode que nous utilisons sur cette même plateforme.
L’utilisation en mode ferme nécessite de connaïtre un peu le mécanisme de SPIP contrairement à la version standalone qui ne nécessite pas réellement de connaissances spécifique puisque l’espace privé habituel de SPIP n’est plus utilisé.
Dans un premier temps, vous devez avoir installé les mêmes fichiers que l’installation (...)
Sur d’autres sites (5358)
-
ffmpeg not working if run from py2app
28 juin 2018, par dprogramzI’m trying to build a simple app that concats 2 mp4 files. It works fine if I run it from the command line, but if I run it from py2app app it doesn’t work. If I run the app from within the py2app in the console (eg ’dist/addTag.app/Contents/MacOS/addTag’), it works fine. It only doesn’t work if i run the app by double clicking on it. Any ideas ? code below
#! /usr/bin/python
import argparse
import ffmpeg
import os
import shutil
import sys
from Tkinter import *
import time
fields = 'Input Video', 'Tag Video', 'Output Name'
def fetch(entries, bu, lb, rt):
bu['state'] = 'disabled'
lb['text'] = 'working'
rt.update()
ffmpeg.concat(ffmpeg.input(entries[0][1].get()), ffmpeg.input(entries[1][1].get())).output(os.path.expanduser("~/desktop/")+entries[2][1].get()).run()
bu['state'] = 'normal'
lb['text'] = 'Ready'
rt.update()
def makeform(root, fields):
entries = []
for field in fields:
row = Frame(root)
lab = Label(row, width=15, text=field, anchor='w')
ent = Entry(row)
row.pack(side=TOP, fill=X, padx=5, pady=5)
lab.pack(side=LEFT)
ent.pack(side=RIGHT, expand=YES, fill=X)
entries.append((field, ent))
return entries
if __name__ == '__main__':
root = Tk()
root.title("Video Maker")
ents = makeform(root, fields)
root.bind('<return>', (lambda event, e=ents: fetch(e)))
label = Label(root, text="Ready")
label.pack(side=LEFT)
b1 = Button(root, text='Make Video',
command=(lambda e=ents: fetch(e, b1, label, root)))
b1.pack(side=LEFT, padx=5, pady=5)
b2 = Button(root, text='Quit', command=root.quit)
b2.pack(side=LEFT, padx=5, pady=5)
root.mainloop()
</return> -
How to resolve the source of an RTSP server unstable problem ?
5 mars 2021, par EricLuI have already build an application by gstreamer rtsp-server with its appsrc.
It's workingflow like test-appsrc. And I implement
static void need_data (GstElement * appsrc, guint unused, MyContext * ctx)
function usingread
from a IP camera's RTSP streamcv::VideoCapture
inneed_data
.

All this function is working well and it's have worked already for a day.


However, I must use some algorithm deal with the IP camera source by OpenCV. When I do this algorithm at

need_data
. The RTSP Server seems unstable it always print something like the below :

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.738: gst_mini_object_add_parent: assertion 'object != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_mini_object_ref: assertion 'mini_object != NULL' failed



It seems the RTSP-server have losing connect appsrc.


One idea to reslove this problem is imporving the algorithm as it can respond as soon as framerate is.
Maybe there are some idea about caching the output of algorithm can let the appsrc element stable.
Can some one give me some advice or trahave already build a application by gstreamer rtsp-server with its appsrc.
It's workingflow like test-appsrc. And I implement
static void need_data (GstElement * appsrc, guint unused, MyContext * ctx)
function usingread
from a IP camera's RTSP streamcv::VideoCapture
inneed_data
.

All this function is working well and it's have worked already for a day.


However, I must use some algorithm deal with the IP camera source by OpenCV. When I do this algorithm at

need_data
. The RTSP Server seems unstable it always print something like below :

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.738: gst_mini_object_add_parent: assertion 'object != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_memory_get_sizes: assertion 'mem != NULL' failed

(opencv_rtsp_server:175041): GStreamer-CRITICAL **: 15:08:38.739: gst_mini_object_ref: assertion 'mini_object != NULL' failed



It seems the RTSP-server has losing connect appsrc.


Or h264 encoder give me error :


valid fps=23 [h264 @ 0x5598f7f2ba40] illegal short term buffer state detected
[h264 @ 0x5598f7f2ba40] Missing reference picture, default is 18
valid fps=24 Invalid UE golomb code
[h264 @ 0x5598f8011580] cbp too large (3199971767) at 8 95
[h264 @ 0x5598f8011580] error while decoding MB 8 95
valid fps=24 [h264 @ 0x5598f7eab3c0] corrupted macroblock 2 51 (total_coeff=-1)
[h264 @ 0x5598f7eab3c0] error while decoding MB 2 51
valid fps=25 [h264 @ 0x5598f8011580] illegal short term buffer state detected
[h264 @ 0x5598f8011580] Missing reference picture, default is 10
valid fps=24 [h264 @ 0x5598f7f2ba40] Invalid level prefix
[h264 @ 0x5598f7f2ba40] error while decoding MB 17 49
valid fps=24 Invalid UE golomb code
[h264 @ 0x5598f7fe1280] cbp too large (3199971767) at 3 163
[h264 @ 0x5598f7fe1280] error while decoding MB 3 163
valid fps=22 [h264 @ 0x5598f8011580] illegal short term buffer state detected
[h264 @ 0x5598f8011580] Missing reference picture, default is 40
valid fps=24 [h264 @ 0x5598f7fe1280] illegal short term buffer state detected
[h264 @ 0x5598f7fe1280] Missing reference picture, default is 40
valid fps=25 [h264 @ 0x5598f7eab3c0] illegal short term buffer state detected
[h264 @ 0x5598f7eab3c0] Missing reference picture, default is 36



One idea to resolve this problem is improving the algorithm as it can respond as soon as framerate is.
Maybe there is some ideas about caching the output of the algorithm that can let the appsrc element stable.
Can someone give me some advice or strategy about caching it or resolve its idea ?


Appreciate it so much...


-
Revision bcaf1d69ec : Moved call to vp9_clear_system_state() to a proper location The commit moved a
22 juillet 2014, par Yaowu XuChanged Paths :
Modify /vp9/encoder/vp9_encoder.c
Moved call to vp9_clear_system_state() to a proper locationThe commit moved a call to vp9_clear_system_state() to a correct
location, i.e. prior function calls using floating point numbers.
This was to fix a mismatch mmx code and sse2 version, where a
floating point number used in adjust_frame_rate(cpi) gets NAN due
to mmx registers being in wrong state.Change-Id : I40e0a6de98812000ccee6a729badb630604fd7e6