
Recherche avancée
Médias (1)
-
The Great Big Beautiful Tomorrow
28 octobre 2011, par
Mis à jour : Octobre 2011
Langue : English
Type : Texte
Autres articles (29)
-
Les vidéos
21 avril 2011, parComme les documents de type "audio", Mediaspip affiche dans la mesure du possible les vidéos grâce à la balise html5 .
Un des inconvénients de cette balise est qu’elle n’est pas reconnue correctement par certains navigateurs (Internet Explorer pour ne pas le nommer) et que chaque navigateur ne gère en natif que certains formats de vidéos.
Son avantage principal quant à lui est de bénéficier de la prise en charge native de vidéos dans les navigateur et donc de se passer de l’utilisation de Flash et (...) -
Use, discuss, criticize
13 avril 2011, parTalk to people directly involved in MediaSPIP’s development, or to people around you who could use MediaSPIP to share, enhance or develop their creative projects.
The bigger the community, the more MediaSPIP’s potential will be explored and the faster the software will evolve.
A discussion list is available for all exchanges between users. -
Publier sur MédiaSpip
13 juin 2013Puis-je poster des contenus à partir d’une tablette Ipad ?
Oui, si votre Médiaspip installé est à la version 0.2 ou supérieure. Contacter au besoin l’administrateur de votre MédiaSpip pour le savoir
Sur d’autres sites (5170)
-
Real-Time Buffer Too Full (FFMPEG)
25 janvier 2018, par NimbleSo I’ve been having this issue with ffmpeg, it has been a journey getting the hardware and command to actually do what I want, but I still have one problem.
Sometimes when I’m recording I just start dropping frames like crazy, this can be after an hour of recording or even ten hours in... Everything will be working fine and then suddenly I’ll start dropping frames due to "real-time buffer too full or near too full". This happens regardless of how low I put the bitrate, and the buffer size is high as it will allow, eventually I’ll just start dropping frames. Almost seems like it could be like a power saving feature kicking in but it’s too inconsistent it seems. Like I said sometimes I can go 10 hours without having this issue.
Any ideas ?
Here is my block of code :
ffmpeg -guess_layout_max 0 -y -f dshow -video_size 3440x1440 -rtbufsize 2147.48M -pixel_format nv12 -framerate 200 ^
-i video="Video (00 Pro Capture HDMI 4K+)":audio="SPDIF/ADAT (1+2) (RME Fireface UC)" -map 0:0,0:1 -map 0:1 ^
-preset: llhp -codec:v h264_nvenc -pix_fmt nv12 -b:v 250M -maxrate:v 250M -minrate:v 250M -bufsize:v 250M -b:a 320k ^
-ac 2 -r 100 -async 1 -vsync 1 -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\PC%02d.mp4 ^
-guess_layout_max 0 -f dshow -rtbufsize 2000M -i audio="Analog (3+4) (RME Fireface UC)" -map 1:0 -b:a 320k -ac 2 ^
-af "adelay=200|200" -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\Voices\Theirs\TPC%02d.wav ^
-guess_layout_max 0 -f dshow -rtbufsize 2000M -i audio="Analog (5+6) (RME Fireface UC)" -map 2:0 -b:a 320k -ac 2 ^
-af "adelay=825|825" -segment_time 600 -segment_wrap 9 -f segment C:\Users\djcim\Videos\PC\Voices\Mine\MPC%02d.wavHere is the error, it repeated around 300 times before locking up ffmpeg forcing my to quit before starting the recording again :
[dshow @ 0000019a596bdcc0] real-time buffer [Video (00 Pro Capture HDMI 4K+)] [video input] too full or near too full (62% of size: 2147480000 [rtbufsize parameter])! frame dropped!
-
Input/output error while using ffmpeg with pulse
2 septembre 2017, par user116522i want to record my audio output. Yesterday, i used the following command
ffmpeg -f pulse -ac 2 -i 1 -c:a libfdk_aac -b:a 192k test4.m4a
and it was working. But now, i receive the output :
ffmpeg version N-83415-g012dd8c Copyright (c) 2000-2017 the FFmpeg developers
built with gcc 4.8 (SUSE Linux)
configuration: --enable-gpl --enable-libx264 --enable-libx265 --enable-nonfree --enable-libfdk-aac --enable-libpulse
libavutil 55. 46.100 / 55. 46.100
libavcodec 57. 75.100 / 57. 75.100
libavformat 57. 66.101 / 57. 66.101
libavdevice 57. 2.100 / 57. 2.100
libavfilter 6. 73.100 / 6. 73.100
libswscale 4. 3.101 / 4. 3.101
libswresample 2. 4.100 / 2. 4.100
libpostproc 54. 2.100 / 54. 2.100
1: Input/output errorThe command
pactl list sources
says :
Source #0
State: SUSPENDED
Name: alsa_output.pci-0000_01_00.1.hdmi-stereo.monitor
Description: Monitor of HDA NVidia Digital Stereo (HDMI)
Driver: module-alsa-card.c
Sample Specification: s16le 2ch 44100Hz
Channel Map: front-left,front-right
Owner Module: 6
Mute: no
Volume: front-left: 65536 / 100% / 0,00 dB, front-right: 65536 / 100% / 0,00 dB
balance 0,00
Base Volume: 65536 / 100% / 0,00 dB
Monitor of Sink: alsa_output.pci-0000_01_00.1.hdmi-stereo
Latency: 0 usec, configured 0 usec
Flags: DECIBEL_VOLUME LATENCY
Properties:
device.description = "Monitor of HDA NVidia Digital Stereo (HDMI)"
device.class = "monitor"
alsa.card = "1"
alsa.card_name = "HDA NVidia"
alsa.long_card_name = "HDA NVidia at 0xf7080000 irq 17"
alsa.driver_name = "snd_hda_intel"
device.bus_path = "pci-0000:01:00.1"
sysfs.path = "/devices/pci0000:00/0000:00:01.0/0000:01:00.1/sound/card1"
device.bus = "pci"
device.vendor.id = "10de"
device.vendor.name = "NVIDIA Corporation"
device.product.id = "0fb9"
device.string = "1"
module-udev-detect.discovered = "1"
device.icon_name = "audio-card-pci"
Formats:
pcm -
ffmpeg 180 degree panoramic fisheye image to equirectangular / flat
7 juillet 2024, par Willy62I am trying to get my Hikvision Panovu image of a sportsfield to look like a standard camera image, similar to what would be seen with a Veo solution / traditional camera.


This is what the image would ideally look like with a little bit of zoom. Note the players are all upright and it looks "correct" and not skewed with the far end of the field in line with the horizon.




The original image looks like this (same field but other side). This is a 180 degree panoramic image from a Hikvision camera as found here.


It provides the following output natively.




I have had some luck converting the image with ffmpeg using the v360 filter. Note there is a downward tilt meaning I have to apply some yaw to correct it.


v360=input=fisheye:output=rectilinear:ih_fov=180:iv_fov=87.5:d_fov=87.5:pitch=20:yaw=5:w=3840:h=2160



And this gets the following output :




So the challenge here to make the original image flat/equirect but to address the skew such that :


- 

- the players are orientated "upright"
- the far sideline of the field looks like a straight line in line with the horizon
- the image quality is preserved as best as possible








With these cameras the image is 32MP so there is the opportunity to do an ePTZ into the area of interest.


I suspect v360 isnt the right choice here and it is some remap-style filter, or perhaps I am best going across to gstreamer or similar.


I tried an ffmpeg v360 filter and it partially works, but the players are still skewed because the top of the image is not wide enough. The issue can possibly be solved by correctly applying a couplex perspective filter, but I think this will only mask the issue and perspective requires a complex filter that hasn't worked for me so far.