Recherche avancée
Autres articles (57)
-
Websites made with MediaSPIP
2 mai 2011, parThis page lists some websites based on MediaSPIP.
-
MediaSPIP Core : La Configuration
9 novembre 2010, parMediaSPIP Core fournit par défaut trois pages différentes de configuration (ces pages utilisent le plugin de configuration CFG pour fonctionner) : une page spécifique à la configuration générale du squelettes ; une page spécifique à la configuration de la page d’accueil du site ; une page spécifique à la configuration des secteurs ;
Il fournit également une page supplémentaire qui n’apparait que lorsque certains plugins sont activés permettant de contrôler l’affichage et les fonctionnalités spécifiques (...) -
Creating farms of unique websites
13 avril 2011, parMediaSPIP platforms can be installed as a farm, with a single "core" hosted on a dedicated server and used by multiple websites.
This allows (among other things) : implementation costs to be shared between several different projects / individuals rapid deployment of multiple unique sites creation of groups of like-minded sites, making it possible to browse media in a more controlled and selective environment than the major "open" (...)
Sur d’autres sites (9597)
-
ffmpeg 4.1.4 wav to mp3 error of "deprecated pixel format used" [on hold]
26 août 2019, par yang jia[swscaler @ 0xc946d000] deprecated pixel format used, make sure you did set range correctly
[mp3 @ 0xc9621600] Frame rate very high for a muxer not efficiently supporting it.
Please consider specifying a lower framerate, a different muxer or -vsync 2
[auto_resampler_0 @ 0xd8e73be0] [SWR @ 0xc8058000] Output channel layout '6 channels (FLC+BC+SL+SR+TC+TFL)' is not supported
[auto_resampler_0 @ 0xd8e73be0] Failed to configure output pad on auto_resampler_0
Error reinitializing filters!
Failed to inject frame into filter network: Invalid argument
Error while processing the decoded data for stream #0:0
--------- beginning of crash
2019-02-26 16:04:58.368 27737-27737/com.blplayer.jbl.blplayer A/libc: Fatal signal 7 (SIGBUS), code 1, fault addr 0xc5ca in tid 27737 (er.jbl.blplayer)cmd
ffmpeg -i test.wav -acodec libmp3lame -ar 8000 -ac 2 -y wav2mp3.mp3This is the log :
then on Mac it success egg
ffmpeg -i input.wav -vn -ar 44100 -ac 2 -b:a 192k output.mp3Guessed Channel Layout for Input Stream #0.0 : stereo
Input #0, wav, from ’input.wav’ :
Metadata :
encoder : Lavf58.20.100
Duration : 00:02:08.29, bitrate : 256 kb/s
Stream #0:0 : Audio : pcm_s16le (1[0][0][0] / 0x0001), 8000 Hz, stereo, s16, 256 kb/s
Stream mapping :
Stream #0:0 -> #0:0 (pcm_s16le (native) -> mp3 (libmp3lame))Output #0, mp3, to ’output.mp3’ :
Metadata :
TSSE : Lavf58.31.104
Stream #0:0 : Audio : mp3 (libmp3lame), 44100 Hz, stereo, s16p, 192 kb/s
Metadata :
encoder : Lavc58.55.101 libmp3lamebut on android it gets error
-
The duration of the combined video with FFmpeg becomes 0
24 août 2019, par sidoI am developing an app for Android by Unity.
When I merge video and audio with FFmpeg, the duration of the output video file is 0 though it can be played back normally.I tried to set duration when merging, but it didn’t work.
The commands being executed are as follows :
-y -i /storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_video.mp4 -i /storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_audio.mp3 -t 3 -c copy -map 0:v -map 1:a -shortest /storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_merged.mp4I expected that the duration of the merged file was the value set in MovieTime, but the duration of the actually merged file was 0.
The log is as follows :
Started
ffmpeg version n3.0.1 Copyright (c) 2000-2016 the FFmpeg developers
built with gcc 4.8 (GCC)
configuration: --target-os=linux --cross-prefix=/home/vagrant/SourceCode/ffmpeg-android/toolchain-android/bin/arm-linux-androideabi- --arch=arm --cpu=cortex-a8 --enable-runtime-cpudetect --sysroot=/home/vagrant/SourceCode/ffmpeg-android/toolchain-android/sysroot --enable-pic --enable-libx264 --enable-libass --enable-libfreetype --enable-libfribidi --enable-libmp3lame --enable-fontconfig --enable-pthreads --disable-debug --disable-ffserver --enable-version3 --enable-hardcoded-tables --disable-ffplay --disable-ffprobe --enable-gpl --enable-yasm --disable-doc --disable-shared --enable-static --pkg-config=/home/vagrant/SourceCode/ffmpeg-android/ffmpeg-pkg-config --prefix=/home/vagrant/SourceCode/ffmpeg-android/build/armeabi-v7a --extra-cflags='-I/home/vagrant/SourceCode/ffmpeg-android/toolchain-android/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-strict-overflow -fstack-protector-all' --extra-ldflags='-L/home/vagrant/SourceCode/ffmpeg-android/toolchain-android/lib -Wl,-z,relro -Wl,-z,now -pie' --extra-libs='-lpng -lexpat -lm' --extra-cxxflags=
libavutil 55. 17.103 / 55. 17.103
libavcodec 57. 24.102 / 57. 24.102
libavformat 57. 25.100 / 57. 25.100
libavdevice 57. 0.101 / 57. 0.101
libavfilter 6. 31.100 / 6. 31.100
libswscale 4. 0.100 / 4. 0.100
libswresample 2. 0.101 / 2. 0.101
libpostproc 54. 0.100 / 54. 0.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from '/storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_video.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
creation_time : 2019-08-24 03:21:20
com.android.version: 7.0
Duration: 00:00:03.65, start: 0.000000, bitrate: 2821 kb/s
Stream #0:0(eng): Video: h264 (Baseline) (avc1 / 0x31637661), yuv420p(tv, smpte170m/smpte170m/bt709), 360x640, 2814 kb/s, SAR 1:1 DAR 9:16, 59.42 fps, 59.94 tbr, 90k tbn, 180k tbc (default)
Metadata:
creation_time : 2019-08-24 03:21:20
handler_name : VideoHandle
[mp3 @ 0xed92f600] Skipping 0 bytes of junk at 880.
Input #1, mp3, from '/storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_audio.mp3':
Metadata:
encoder : Lavf57.25.100
Duration: 00:00:03.55, start: 0.025057, bitrate: 257 kb/s
Stream #1:0: Audio: mp3, 44100 Hz, stereo, s16p, 256 kb/s
Metadata:
encoder : Lavc57.24
Output #0, mp4, to '/storage/emulated/0/Android/data/jp.ne.company.app/files/Record/20190824122116_merged.mp4':
Metadata:
major_brand : mp42
minor_version : 0
compatible_brands: isommp42
com.android.version: 7.0
encoder : Lavf57.25.100
Stream #0:0(eng): Video: h264 ([33][0][0][0] / 0x0021), yuv420p, 360x640 [SAR 1:1 DAR 9:16], q=2-31, 2814 kb/s, 59.42 fps, 59.94 tbr, 90k tbn, 90k tbc (default)
Metadata:
creation_time : 2019-08-24 03:21:20
handler_name : VideoHandle
Stream #0:1: Audio: mp3 (i[0][0][0] / 0x0069), 44100 Hz, stereo, 256 kb/s
Metadata:
encoder : Lavc57.24
Stream mapping:
Stream #0:0 -> #0:0 (copy)
Stream #1:0 -> #0:1 (copy)
Press [q] to stop, [?] for help
frame= 178 fps=0.0 q=-1.0 Lsize= 1098kB time=00:00:03.00 bitrate=2992.8kbits/s speed= 122x
video:997kB audio:95kB subtitle:0kB other streams:0kB global headers:0kB muxing overhead: 0.534772% -
RTP Timestamps Are Not Monotonically increasing
25 août 2019, par Fr0styI am finding it a bit difficult trying to understand whether or not the hack around with FFmpeg and OpenCV really provided a RTP timestamp. My last post helped a little bit but got me stuck in trying to validate the timestamps obtained through this work around by modifying ffmpeg and opencv.
FFmpeg version : 4.1.0
OpenCV version : 3.4.1import cv2
import time
from datetime import datetime, date
uri = 'rtsp://admin:password@192.168.1.66:554/Streaming/Channels/101'
cap = cv2.VideoCapture(uri)
'''One is the offset between the two epochs. Unix uses an epoch located at 1/1/1970-00:00h (UTC) and NTP uses 1/1/1900-00:00h.
This leads to an offset equivalent to 70 years in seconds (there are 17 leap years between the two dates so the offset is'''
time_offset = 2208988800 # (70*365 + 17)*86400 = 2208988800 (in seconds)
# offset = 3775484294
days = 43697
pdat = "1900-01-01 00:00:00:00"
mdat = "2019-08-23 22:02:44:00" # str(datetime.now()) + str(datetime.now().time())
pdate = datetime.strptime(pdat, "%Y-%m-%d %H:%M:%S:%f").date()
mdate = datetime.strptime(mdat, "%Y-%m-%d %H:%M:%S:%f").date()
delta = (mdate - pdate).days
offset = delta * 86400
def time_delta(s):
return (s - time_offset)
while True:
frame_exists, curr_frame = cap.read()
if frame_exists:
seconds = cap.getRTPTimeStampSeconds()
fraction = cap.getRTPTimeStampFraction()
timestamp = cap.getRTPTimeStampTs()
unix_offset = seconds - time_offset
msec = int((int(fraction) / 0xFFFFFFFF) * 1000.0)
ts = float(str(unix_offset) + "." + str(msec))
# print("Timestamp per Frame:%i" % timestamp)
print((datetime.fromtimestamp(float(ts) + offset)))
cap.release()My Output :
On August 23, 2019 at 22:02
...
2019-08-23 13:59:52.781000
2019-08-23 13:59:52.726000
2019-08-23 13:59:52.671000
2019-08-23 13:59:52.616000
2019-08-23 13:59:52.561000
2019-08-23 13:59:52.506000
2019-08-23 13:59:52.451000
2019-08-23 13:59:52.396000
2019-08-23 13:59:52.342000
2019-08-23 13:59:52.287000
2019-08-23 13:59:52.232000
2019-08-23 13:59:52.177000
2019-08-23 13:59:52.122000
2019-08-23 13:59:52.067000
2019-08-23 13:59:52.012000
2019-08-23 13:59:53.570000
2019-08-23 13:59:53.020000
2019-08-23 13:59:53.847000
2019-08-23 13:59:53.792000I’ve noticed how the time increments weirdly (that’s not suppose to happen in the real, current time), such as the last two lines and a few others in between in the output. A bit flabbergasted as to what went wrong. Also trying this out on multiple IP cameras, with each showing a different timestamp probably related to when they were turned on.
Syndiquer tout le site
