
Recherche avancée
Médias (2)
-
GetID3 - Bloc informations de fichiers
9 avril 2013, par
Mis à jour : Mai 2013
Langue : français
Type : Image
-
GetID3 - Boutons supplémentaires
9 avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (55)
-
HTML5 audio and video support
13 avril 2011, parMediaSPIP uses HTML5 video and audio tags to play multimedia files, taking advantage of the latest W3C innovations supported by modern browsers.
The MediaSPIP player used has been created specifically for MediaSPIP and can be easily adapted to fit in with a specific theme.
For older browsers the Flowplayer flash fallback is used.
MediaSPIP allows for media playback on major mobile platforms with the above (...) -
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) (...)
-
Support audio et vidéo HTML5
10 avril 2011MediaSPIP utilise les balises HTML5 video et audio pour la lecture de documents multimedia en profitant des dernières innovations du W3C supportées par les navigateurs modernes.
Pour les navigateurs plus anciens, le lecteur flash Flowplayer est utilisé.
Le lecteur HTML5 utilisé a été spécifiquement créé pour MediaSPIP : il est complètement modifiable graphiquement pour correspondre à un thème choisi.
Ces technologies permettent de distribuer vidéo et son à la fois sur des ordinateurs conventionnels (...)
Sur d’autres sites (7902)
-
FFMPEG : output scene change times in frames
29 mai 2019, par Mark RaishbrookI’m successfully using the
-vf select='gte(scene,0.4)',metadata=print:file=shotcuts.txt
command to get FFMPEG to detect scene changes and output the results to file. Is it possible to force the pts field to be in frames rather than the default, which seems to vary depending on the video format (e.g. frames for AVI files, nanosecs for MOV/MP4) ?Processing an AVI file, for example, outputs time stamps in frames :
frame 0 pts 151
frame 1 pts 206Whereas an MP4 file outputs as media time :
frame 0 pts 540000
frame 1 pts 738000 -
FFmpeg 5 C api codec : how many times will EOF be returned by the receiving end ?
3 février 2024, par Guanyuming HeEdit : I may have written my questions unclearly at first, so I rewrote them. Sorry if you had found my questions confusing.


I'm new to FFmpeg api programming (I'm using version 5.1) and am learning from the documentation and official examples.


In the documentation page about send/receive encoding and decoding API overview, end of stream situation is discussed briefly :




End of stream situations. These require "flushing" (aka draining) the codec, as the codec might buffer multiple frames or packets internally for performance or out of necessity (consider B-frames). This is handled as follows :






Instead of valid input, send
NULL
to theavcodec_send_packet()
(decoding) oravcodec_send_frame()
(encoding) functions. This will enter draining mode.
Callavcodec_receive_frame()
(decoding)
oravcodec_receive_packet()
(encoding) in a loop untilAVERROR_EOF
is returned. The functions will not returnAVERROR(EAGAIN)
, unless you forgot to enter draining mode.
Before decoding can be resumed again, the codec has to be reset withavcodec_flush_buffers()
.



As I understand it, when I get
AVERROR_EOF
, I have reached a special point where I need to drain buffered data from the codec and finally reset the codec withavcodec_flush_buffers()
. Without doing it, I cannot continue decoding/encoding.

Is my understanding correct ?


If so, then I have some questions :


- 

- How many times at most can EOF be returned by the receiving end during one complete process, for example, decoding ?
- If the answer to the first question is infinity, then : If I received an EOF from the receiving end when I already finished sending data (e.g. when after EOF is returned by
av_read_frame()
), how should I tell if it's really finished ? Here there is no return code only for indicating if the receiving is finished. - The data returned from the
receive_...
functions during draining, should I take them as valid ?








I might have found answers to those in the official examples, but I'm not sure if the answer is universally true. I noticed that in some official examples, like in transcode_aac.c, draining is only done for the first EOF reached, and then after the second one is received, it is regarded that there are really nothing left. Any data received during draining is also written to the final output.


Am I correct on interpreting the example ? If so, can I say that the answer to question 1 is once, and the answer to question 3 is yes ?


I appreciate your response and time in advance. :)


-
movenc : Add a unit test for signaling of the track start times
10 novembre 2015, par Martin Storsjö