
Recherche avancée
Médias (91)
-
DJ Z-trip - Victory Lap : The Obama Mix Pt. 2
15 septembre 2011
Mis à jour : Avril 2013
Langue : English
Type : Audio
-
Matmos - Action at a Distance
15 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
DJ Dolores - Oslodum 2004 (includes (cc) sample of “Oslodum” by Gilberto Gil)
15 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Danger Mouse & Jemini - What U Sittin’ On ? (starring Cee Lo and Tha Alkaholiks)
15 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
Cornelius - Wataridori 2
15 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
-
The Rapture - Sister Saviour (Blackstrobe Remix)
15 septembre 2011, par
Mis à jour : Septembre 2011
Langue : English
Type : Audio
Autres articles (42)
-
Encoding and processing into web-friendly formats
13 avril 2011, parMediaSPIP automatically converts uploaded files to internet-compatible formats.
Video files are encoded in MP4, Ogv and WebM (supported by HTML5) and MP4 (supported by Flash).
Audio files are encoded in MP3 and Ogg (supported by HTML5) and MP3 (supported by Flash).
Where possible, text is analyzed in order to retrieve the data needed for search engine detection, and then exported as a series of image files.
All uploaded files are stored online in their original format, so you can (...) -
Emballe médias : à quoi cela sert ?
4 février 2011, parCe plugin vise à gérer des sites de mise en ligne de documents de tous types.
Il crée des "médias", à savoir : un "média" est un article au sens SPIP créé automatiquement lors du téléversement d’un document qu’il soit audio, vidéo, image ou textuel ; un seul document ne peut être lié à un article dit "média" ; -
L’utiliser, en parler, le critiquer
10 avril 2011La première attitude à adopter est d’en parler, soit directement avec les personnes impliquées dans son développement, soit autour de vous pour convaincre de nouvelles personnes à l’utiliser.
Plus la communauté sera nombreuse et plus les évolutions seront rapides ...
Une liste de discussion est disponible pour tout échange entre utilisateurs.
Sur d’autres sites (5310)
-
Why JPEG compressing an uncompressed image differs its original (FFmpeg, NvJPEG, ...)
22 juin 2021, par FruchtzwergI am currently struggling to understand why recompressing an uncompressed JPEG image differs its original.


It's clear, that JPEG is a lossy compression, but what if the image to compress is already uncompressed, which means all sampling losses are already included ? In other words : Downsampling and DCT should be inversable at this point without loosing data.




To make sure losses are not effected by the color space conversion, this step is skipped and YUV images are used.


- 

- Compress YUV image to JPEG (image.yuv —> image.yuv.jpg)
- Uncompress JPEG image to YUV image (image.yuv.jpg —> image.yuv.jpg.yuv)
- Compress YUV image to JPEG (image.yuv.jpg.yuv —> image.yuv.jpg.yuv.jpg)
- Uncompress JPEG image to YUV image (image.yuv.jpg.yuv.jpg —> image.yuv.jpg.yuv.jpg.yuv)










Step 1 includes a lossy compression, so we will not deal with this step anymore. For me, intresting is what happens afterwards :


Uncompressing the JPEG image back to YUV (step 2) leads to an image which perfectly fits all sampling steps if compressed again (step 3). So the JPEG image after step 3 should (from my understanding) be exactly the same as after step 1. Also the YUV images after step 4 and step 2 should equal each other.


Looking at the steps for one 8x8 block the following simplified sequence should illustrate what I am trying to descibe. Lets start with the original YUV image, which can only be decompressed loosing all decimal places :


[ 1.123, 2.345, 3.456, ... ] (YUV)
 DTC + Quantization
[ -26, -3, -6, ... ] (Quantized frequency space)
 Inverse DTC + Quantization
[ 1, 2, 3, ... ] (YUV)



Doing this with input, which already matches all steps, which may lead to loss of data afterwards (using round numbers in my example), the decompressed image should match its original :


[ 1, 2, 3, ... ] (YUV)
 DTC + Quantization
[ -26, -3, -6, ... ] (Quantized frequency space)
 Inverse DTC + Quantization
[ 1, 2, 3, ... ] (YUV)



There are also some sources and discussions, which are confirming my idea :


- 

- need help creating Jpeg Generational Degradation code
- What factors cause or prevent “generational loss” when JPEGs are recompressed multiple times ?
- Lossless Chroma Subampling








So much for theory. In praxis, I've runned these steps using ffmpeg and Nvidias jpeg samples (using NvJPEGEncoder).


ffmpeg :


#Create YUV image
ffmpeg -y -i image.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv image.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv image.yuv.jpg.yuv.jpg
#JPEG TO YUV
ffmpeg -y -i image.yuv.jpg.yuv.jpg -s 1920x1080 -pix_fmt yuv420p image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
ffmpeg -y -s 1920x1080 -pix_fmt yuv420p -i image.yuv.jpg.yuv.jpg.yuv image.yuv.jpg.yuv.jpg.yuv.jpg



Nvidia :


#Create YUV image
./jpeg_decode num_files 1 image.jpg image.yuv
#YUV to JPEG
./jpeg_encode image.yuv 1920 1080 image.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg image.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg
#JPEG TO YUV
./jpeg_decode num_files 1 image.yuv.jpg.yuv.jpg image.yuv.jpg.yuv.jpg.yuv
#YUV to JPEG
./jpeg_encode image.yuv.jpg.yuv.jpg.yuv 1920 1080 image.yuv.jpg.yuv.jpg.yuv.jpg



But a comparison of the images


- 

- image.yuv.jpg.yuv and image.yuv.jpg.yuv.jpg.yuv
- image.yuv.jpg.yuv.jpg and image.yuv.jpg.yuv.jpg.yuv.jpg






showing differences in the files. That brings me to my question why and where the difference gets happen, since from my understanding the files should be equal.


-
Multiple files concatenation using ffmpeg by the use of GPU Hardware acceleration
30 juin 2021, par bubusI need to concatenate multiple mp4, h264 encoded files into single one together with speed up filter, using GPU HW acceleration. I am using Debian 10 Buster 64bit, and the card I am using is Nvidia Gainward GTX960.


I have installed CUDA, together with Nvidia driver and configured ffmpeg with the following parameters :


./configure --enable-nonfree -–enable-cuda-sdk –enable-libnpp --extra-cflags=-I/usr/local/cuda/include --extra-ldflags=-L/usr/local/cuda/lib64`



The problem is, I believe, that GPU is not working at 100%, so the concatenation takes quite a long time.


The command I am using to concatenate files and speeding them up :


./ffmpeg -c:v h264_cuvid -f concat -i mylist.txt -c:a copy -c:v h264_nvenc -y -filter:v 'setpts='0.0625'*PTS' -an merged.mp4



Output of nvidia-smi while the above command is being executed :




ffmpeg version: ffmpeg version N-102801-gb74beba9a9
CUDA version: 11.2
Nvidia driver version: 460.84



I have no idea what else can I do to speed up the concatenation.


-
How to save frames to memory from video with ffmpeg gpu encoding ?
6 juillet 2021, par SpetraI'm trying to extract frames from video and save them to memory(ram).
With CPU encoding, I don't have any problems :


ffmpeg -i input -s 224x224 -pix_fmt bgr24 -vcodec rawvideo -an -sn -f image2pipe -



But when I'm trying to use some NVIDIA GPU encoding, I'm always getting noisy images.
I tried to use different commands, but the result was always the same, on Windows and Ubuntu.


ffmpeg -hwaccel cuda -i 12.mp4 -s 224x224 -f image2pipe - -vcodec rawvideo



With saving JPG's on disk, I don't have any problems.


ffmpeg -hwaccel cuvid -c:v h264_cuvid -resize 224x224 -i {input_video} \
 -vf thumbnail_cuda=2,hwdownload,format=nv12 {output_dir}/%d.jpg



There was my python code for testing these commands :


import cv2
import subprocess as sp
import numpy

IMG_W = 224
IMG_H = 224
input = '12.mp4'

ffmpeg_cmd = [ 'ffmpeg','-i', input,'-s', '224x224','-pix_fmt', 'bgr24', '-vcodec', 'rawvideo', '-an','-sn', '-f', 'image2pipe', '-']


#ffmpeg_cmd = ['ffmpeg','-hwaccel' ,'cuda' ,'-i' ,'12.mp4','-s', '224x224','-f' , 'image2pipe' ,'-' , '-vcodec' ,'rawvideo']

pipe = sp.Popen(ffmpeg_cmd, stdout = sp.PIPE, bufsize=10)
images = []
encode_param = [int(cv2.IMWRITE_JPEG_QUALITY), 95]
cnt = 0
while True:
 cnt += 1
 raw_image = pipe.stdout.read(IMG_W*IMG_H*3)
 image = numpy.fromstring(raw_image, dtype='uint8') # convert read bytes to np
 if image.shape[0] == 0:
 del images
 break 
 else:
 image = image.reshape((IMG_H,IMG_W,3))
 

 cv2.imshow('test',image)
 if cv2.waitKey(1) & 0xFF == ord('q'):
 break

pipe.stdout.flush()
cv2.destroyAllWindows()