Recherche avancée
Autres articles (32)
-
Support de tous types de médias
10 avril 2011Contrairement à beaucoup de logiciels et autres plate-formes modernes de partage de documents, MediaSPIP a l’ambition de gérer un maximum de formats de documents différents qu’ils soient de type : images (png, gif, jpg, bmp et autres...) ; audio (MP3, Ogg, Wav et autres...) ; vidéo (Avi, MP4, Ogv, mpg, mov, wmv et autres...) ; contenu textuel, code ou autres (open office, microsoft office (tableur, présentation), web (html, css), LaTeX, Google Earth) (...)
-
Other interesting software
13 avril 2011, parWe don’t claim to be the only ones doing what we do ... and especially not to assert claims to be the best either ... What we do, we just try to do it well and getting better ...
The following list represents softwares that tend to be more or less as MediaSPIP or that MediaSPIP tries more or less to do the same, whatever ...
We don’t know them, we didn’t try them, but you can take a peek.
Videopress
Website : http://videopress.com/
License : GNU/GPL v2
Source code : (...) -
Keeping control of your media in your hands
13 avril 2011, parThe vocabulary used on this site and around MediaSPIP in general, aims to avoid reference to Web 2.0 and the companies that profit from media-sharing.
While using MediaSPIP, you are invited to avoid using words like "Brand", "Cloud" and "Market".
MediaSPIP is designed to facilitate the sharing of creative media online, while allowing authors to retain complete control of their work.
MediaSPIP aims to be accessible to as many people as possible and development is based on expanding the (...)
Sur d’autres sites (5020)
-
avformat/rtsp : extend the PATH buffer to 2048
7 août 2024, par Stefano Mandelliavformat/rtsp : extend the PATH buffer to 2048
Recently, I have been experiencing an increasing number of user that use ffmpeg
to retrive RTSP stream from personal mediaproxies (e.g. MediaMtx) with
authorization based on JWT. The current length of PATH does not permit to
insert the token in the URL failing the authorization with no possibilities to
get the video.VLC has just modified the RSTP max URL length, and it permits to use token
inside the URL.For these reasons, I propose this patch to extend the PATH buffer from 1024 to
2048 in order to use tokens and the authorization process based on JWT.Signed-off-by : Marton Balint <cus@passwd.hu>
-
FFmpeg Streaming Video SpringBoot endpoint not show video duration in video players
7 avril 2024, par lxluxo23it turns out that I've been working on a personal project just out of curiosity.
the main function is to stream video by first encoding it through ffmpeg
then playback said video from any other device
call it "plex" very very primitive


although I achieve my goal which is to encode and send the video to the devices that make the request
this video is sent so to speak as a live broadcast.
I can only pause it, no forward or rewind, anyone have any idea what I am doing wrong or if I should take some other approach either in my service or controller ?


I leave fragments of my code


THE CONTROLLER


@RestController
@RequestMapping("/api")
@Log4j2
public class StreamController {

 @Autowired
 VideoStreamingService videoStreamingService;

 @Autowired
 VideoService videoService;


 @GetMapping("/stream/{videoId}")
 public ResponseEntity<streamingresponsebody> livestream(@PathVariable Long videoId,@RequestParam(required = false) String codec) {
 Video video = videoService.findVideoById(videoId);
 if (video != null) {
 Codec codecEnum = Codec.fromString(codec);
 return ResponseEntity.ok()
 .contentType(MediaType.valueOf("video/mp4"))
 .body(outputStream -> videoStreamingService.streamVideo(video.getPath(), outputStream,codecEnum));
 }
 return ResponseEntity.notFound().build();
 }
}
</streamingresponsebody>

THE SERVICE


@Service
public class VideoStreamingService {

 public void streamVideo(String videoPath, OutputStream outputStream, Codec codec) {

 FFmpeg ffmpeg = FFmpeg.atPath()
 .addArguments("-i", videoPath)
 .addArguments("-b:v", "5000k")
 .addArguments("-maxrate", "5000k")
 .addArguments("-bufsize", "10000k")
 .addArguments("-c:a", "aac")
 .addArguments("-b:a", "320k")
 .addArguments("-movflags", "frag_keyframe+empty_moov+faststart")
 .addOutput(PipeOutput.pumpTo(outputStream)
 .setFormat("mp4"))
 .addArgument("-nostdin");
 if (codec == Codec.AMD) {
 ffmpeg.addArguments("-profile:v", "high");
 }
 ffmpeg.addArguments("-c:v", codec.getFfmpegArgument());
 ffmpeg.execute();
 }
}


I have some enums to vary the encoding and use hardware acceleration or not.


and here is an example from my player
the endpoint is the following


http://localhost:8080/api/stream/2?codec=AMD
screenshot

I'm not sure if there's someone with more knowledge in either FFmpeg or Spring who could help me with this minor issue, I would greatly appreciate it. I've included the URL of the repository in case anyone would like to review it when answering my question




I tried changing the encoding format.
I tried copying the metadata from the original video.
I tried sending a custom header.
None of this has worked.


I would like to achieve what is mentioned in many sites, which is when you load a video from the network, the player shows how much of that video you have in the local "buffer".


-
Anomaly in raw I420 video generated by GStreamer
16 avril 2024, par LeaSituation


I'm trying to convert RGBA image data to YUV420P in multiple threads, then send this data to a main thread which splits the data it receives from each thread into separate frames and combines them in order to a video. Currently, I'm using FFmpeg for this task but I've found GStreamer to do a quicker job at colorspace conversion than FFmpeg.


Problem


The raw video generated by GStreamer does not match the expectations for YUV 4:2:0 planar video data. To test this, I've made a raw RGBA test video of 3 red 4x4 (16 pixel) frames.


ffmpeg -f lavfi -i color=color=red -t 3 -r 1 -s 4x4 -f rawvideo -pix_fmt rgba ./input.rgba




FFmpeg


Now, first trying to convert it via FFmpeg as I'm doing it currently :


ffmpeg -f rawvideo -pix_fmt rgba -s 4x4 -i input.rgba -f rawvideo -pix_fmt yuv420p ./ffmpeg.yuv420p


This creates a 72 byte file => 1.5 bytes per pixel, 24 bytes per frame : As expected for yuv420p data.


$ hexdump -C ./ffmpeg.yuv420p 
00000000 51 51 51 51 50 50 50 50 50 50 50 50 50 50 50 50 |QQQQPPPPPPPPPPPP|
00000010 5b 5b 5b 5b ee ee ee ee 51 51 51 51 50 50 50 50 |[[[[....QQQQPPPP|
00000020 50 50 50 50 50 50 50 50 5b 5b 5b 5b ee ee ee ee |PPPPPPPP[[[[....|
00000030 51 51 51 51 50 50 50 50 50 50 50 50 50 50 50 50 |QQQQPPPPPPPPPPPP|
00000040 5b 5b 5b 5b ee ee ee ee |[[[[....|


GStreamer


Now trying to do the same via GStreamer, with the
I420format which corresponds to yuv420p as per their documentation :

gst-launch-1.0 filesrc location=./input.rgba ! rawvideoparse format=rgba width=4 height=4 \
! videoconvert ! video/x-raw,format=I420 ! filesink location=./gstreamer.yuv420p


This creates a 96 byte file => 2 bytes per pixel, 32 bytes per frame (?) : Unusual for yuv420p data. Additionally, none of the sections match the FFmpeg output, ruling out some kind of padding.


$ hexdump -C ./gstreamer.yuv420p 
00000000 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 |PPPPPPPPPPPPPPPP|
00000010 5a 5a 00 00 5a 5a 00 00 ee ee 00 00 ed ed 00 00 |ZZ..ZZ..........|
00000020 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 |PPPPPPPPPPPPPPPP|
00000030 5a 5a 63 6b 5a 5a 77 62 ee ee 78 6d ed ed 2c 20 |ZZckZZwb..xm.., |
00000040 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 50 |PPPPPPPPPPPPPPPP|
00000050 5a 5a 00 00 5a 5a 00 00 ee ee 00 00 ed ed 00 00 |ZZ..ZZ..........|


This output can also not be interpreted correctly as yuv420p by FFmpeg, leading to corrupted frames when trying to do so :


ffmpeg -f rawvideo -pix_fmt yuv420p -s 4x4 -i gstreamer.yuv420p -f image2 "./%d.png"




Solution ?


For my personal problem I need a way to chop up raw I420 video generated by GStreamer into separate frames to work with. However, I would also like to understand why GStreamer behaves this way and which key piece I'm missing here.


Additional notes


I've ruled out an issue with the input in GStreamer, as piping it to
autovideosinkleads to a normal result. I'm also aware of multifilesink, but I would like to avoid writing to disk and rather work with the data directly in buffers.

Syndiquer tout le site
