
Recherche avancée
Médias (1)
-
Bug de détection d’ogg
22 mars 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Video
Autres articles (32)
-
Demande de création d’un canal
12 mars 2010, parEn fonction de la configuration de la plateforme, l’utilisateur peu avoir à sa disposition deux méthodes différentes de demande de création de canal. La première est au moment de son inscription, la seconde, après son inscription en remplissant un formulaire de demande.
Les deux manières demandent les mêmes choses fonctionnent à peu près de la même manière, le futur utilisateur doit remplir une série de champ de formulaire permettant tout d’abord aux administrateurs d’avoir des informations quant à (...) -
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 -
Taille des images et des logos définissables
9 février 2011, parDans beaucoup d’endroits du site, logos et images sont redimensionnées pour correspondre aux emplacements définis par les thèmes. L’ensemble des ces tailles pouvant changer d’un thème à un autre peuvent être définies directement dans le thème et éviter ainsi à l’utilisateur de devoir les configurer manuellement après avoir changé l’apparence de son site.
Ces tailles d’images sont également disponibles dans la configuration spécifique de MediaSPIP Core. La taille maximale du logo du site en pixels, on permet (...)
Sur d’autres sites (6966)
-
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 6c54dbcb69 : Merge "BITSTREAM : Handle transform size and motion vectors more logically for no
1er juillet 2014, par Alex ConverseChanged Paths :
Modify /test/test-data.sha1
Modify /test/test.mk
Modify /test/test_vectors.cc
Modify /vp9/encoder/vp9_rdopt.c
Merge "BITSTREAM : Handle transform size and motion vectors more logically for
non-420." -
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"