
Recherche avancée
Médias (1)
-
Richard Stallman et le logiciel libre
19 octobre 2011, par
Mis à jour : Mai 2013
Langue : français
Type : Texte
Autres articles (111)
-
Mise à jour de la version 0.1 vers 0.2
24 juin 2013, parExplications des différents changements notables lors du passage de la version 0.1 de MediaSPIP à la version 0.3. Quelles sont les nouveautés
Au niveau des dépendances logicielles Utilisation des dernières versions de FFMpeg (>= v1.2.1) ; Installation des dépendances pour Smush ; Installation de MediaInfo et FFprobe pour la récupération des métadonnées ; On n’utilise plus ffmpeg2theora ; On n’installe plus flvtool2 au profit de flvtool++ ; On n’installe plus ffmpeg-php qui n’est plus maintenu au (...) -
Personnaliser en ajoutant son logo, sa bannière ou son image de fond
5 septembre 2013, parCertains thèmes prennent en compte trois éléments de personnalisation : l’ajout d’un logo ; l’ajout d’une bannière l’ajout d’une image de fond ;
-
Ecrire une actualité
21 juin 2013, parPrésentez les changements dans votre MédiaSPIP ou les actualités de vos projets sur votre MédiaSPIP grâce à la rubrique actualités.
Dans le thème par défaut spipeo de MédiaSPIP, les actualités sont affichées en bas de la page principale sous les éditoriaux.
Vous pouvez personnaliser le formulaire de création d’une actualité.
Formulaire de création d’une actualité Dans le cas d’un document de type actualité, les champs proposés par défaut sont : Date de publication ( personnaliser la date de publication ) (...)
Sur d’autres sites (9940)
-
Fixing "RTP : dropping old packet received too late" in FFMPEG
25 juin 2014, par user985030I have been using FFMPEG 0.6 for years with no problems and recently ported much of my code to 2.2 ; however, there is still a problem that I cannot resolve after fixing many of the deprecated functions. I am generating simulated video and then using RTSP to unicast this generated stream. The problem is that when I change the height and width of my video data, I basically recreate a new stream to send the subscribed client. The algorithm I used to do this in 0.6 worked like a charm, never had any problems. Now that I have upgraded, I get "RTP : dropping old packet received too late" as soon as I change my frame size. I think I have been dropping packets all along, but the new code is causing connection issues for me. The packets being dropped in the past were negligible and I really didn’t care if I missed them as long as the stream eventually corrected itself. Is there a flag that I can set to not drop these packets ? Or at least recover more quickly ? I believe that this has something to do with receiving packets out of order. There is a section of code that does a diff in FFMPEG in the rtpdec.c file in the function rtp_parts_one_packet. The only reference I found similar to my issue is here :
http://en.it-usenet.org/thread/16949/6708/#post6707. Any tips would be greatly appreciated. In the meantime, I am just going to patch the FFMPEG code to not do the following check :
if (diff < 0) {
/* Packet older than the previously emitted one, drop */
av_log(s->st ? s->st->codec : NULL, AV_LOG_WARNING,
"RTP: dropping old packet received too late\n");
return -1;
}By commenting out the above code, I am able to run my streaming application like I used to, but I have a feeling that I am not doing something correctly but I am not sure what it is. Thanks for any advice !
-
Revision 727f384085 : Merge "Separates profile 2 into 2 profiles 2 and 3"
18 juillet 2014, par Deb MukherjeeChanged Paths :
Modify /test/invalid_file_test.cc
Modify /test/test-data.sha1
Modify /test/test.mk
Modify /vp9/decoder/vp9_decodeframe.c
Merge "Separates profile 2 into 2 profiles 2 and 3" -
Revision bd756699b9 : Merge "Add a test that tests invalid partitions for profile 1"
2 juillet 2014, par Jim BankoskiChanged Paths :
Modify /test/test-data.sha1
Modify /test/test.mk
Merge "Add a test that tests invalid partitions for profile 1"