
Recherche avancée
Médias (1)
-
The pirate bay depuis la Belgique
1er avril 2013, par
Mis à jour : Avril 2013
Langue : français
Type : Image
Autres articles (46)
-
Qu’est ce qu’un éditorial
21 juin 2013, parEcrivez votre de point de vue dans un article. Celui-ci sera rangé dans une rubrique prévue à cet effet.
Un éditorial est un article de type texte uniquement. Il a pour objectif de ranger les points de vue dans une rubrique dédiée. Un seul éditorial est placé à la une en page d’accueil. Pour consulter les précédents, consultez la rubrique dédiée.
Vous pouvez personnaliser le formulaire de création d’un éditorial.
Formulaire de création d’un éditorial Dans le cas d’un document de type éditorial, les (...) -
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 -
Contribute to translation
13 avril 2011You can help us to improve the language used in the software interface to make MediaSPIP more accessible and user-friendly. You can also translate the interface into any language that allows it to spread to new linguistic communities.
To do this, we use the translation interface of SPIP where the all the language modules of MediaSPIP are available. Just subscribe to the mailing list and request further informantion on translation.
MediaSPIP is currently available in French and English (...)
Sur d’autres sites (6525)
-
Why I became a HTML5 co-editor
15 août 2012, par silviaA few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.
Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.
But what does REC level really mean for HTML ?
In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).
Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.
Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here.
So, why am I doing it ? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.
I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.
I am not yet completely sure what the editorship will entail. Will we look at tests, too ? Will we get involved in HTML.next ? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well ! I look forward to the new experiences.
-
Why I became a HTML5 co-editor
1er janvier 2014, par silviaA few weeks ago, I had the honor to be appointed as part of the editorial team of the W3C HTML5 specification.
Since Ian Hickson had recently decided to focus solely on editing the WHATWG HTML living standard specification, the W3C started looking for other editors to take the existing HTML5 specification to REC level. REC level is what other standards organizations call a “ratified standard”.
But what does REC level really mean for HTML ?
In my probably somewhat subjective view, recommendation level means that a snapshot is taken of the continuously evolving HTML spec, which has a comprehensive feature set, that is implemented in a cross-browser interoperable way, has a complete test set for the features, and has received wide review. The latter implies that other groups in the W3C have had a chance to look at the specification and make sure it satisfies their basic requirements, which include e.g. applicability to all users (accessibility, internationalization), platforms, and devices (mobile, TV).
Basically it means that we stop for a “moment”, take a deep breath, polish the feature set that we’ve been working on this far, and make sure we all agree on it, before we get back to changing the world with cool new stuff. In a software project we would call it a release branch with feature freeze.
Now, as productive as that may sound for software – it’s not actually that exciting for a specification. Firstly, the most exciting things happen when writing new features. Secondly, development of browsers doesn’t just magically stop to get the release (REC) happening. And lastly, if we’ve done our specification work well, there should be only little work to do. Basically, it’s the unthankful work of tidying up that we’re looking at here.
So, why am I doing it ? I am not doing this for money – I’m currently part-time contracting to Google’s accessibility team working on video accessibility and this editor work is not covered by my contract. It wasn’t possible to reconcile polishing work on a specification with the goals of my contract, which include pushing new accessibility features forward. Therefore, when invited, I decided to offer my spare time to the W3C.
I’m giving this time under the condition that I’d only be looking at accessibility and video related sections. This is where my interest and expertise lie, and where I’m passionate to get things right. I want to make sure that we create accessibility features that will be implemented and that we polish existing video features. I want to make sure we don’t digress from implementations which continue to get updated and may follow the WHATWG spec or HTML.next or other needs.
I am not yet completely sure what the editorship will entail. Will we look at tests, too ? Will we get involved in HTML.next ? This far we’ve been preparing for our work by setting up adequate version control repositories, building a spec creation process, discussing how to bridge to the WHATWG commits, and analysing the long list of bugs to see how to cope with them. There’s plenty of actual text editing work ahead and the team is shaping up well ! I look forward to the new experiences.
-
ffmpeg concat vertical video, different dimensions [duplicate]
16 octobre 2020, par MorrisContext :
3 input videos :


foo.mov
: 1080x1920 (vertical, NOT horizontal) with audio.

bar.mp4
andfiz.mp4
: 480x360, with audio.
(Note :.mp4
, differs from.mov
)

Goal : to concat all 3 videos. Output
out.mp4
should be 480x360. Squeezefoo.mov
but keep its aspect ratio, taking up 100% height, but the slim video should stand only in the center, with left and right sides being black (or other color) void.foo.mov
should not be cropped.

I currently have this command below (added new-line characters for better visualization) for concating, but need to fill the missing code at
PLACEHOLDER1
to generatev0
, such thatv0
is resized to 480x360 like described above. If my attempt so far is correct, please help completePLACEHOLDER1
; else, please offer a better solution with explanation.

ffmpeg 
-r 24 -i foo.mov 
-r 24 -i bar.mp4 
-r 24 -i fiz.mp4
-filter_complex 
"[0:v] PLACEHOLDER1 [v0];
[v0][1][2] concat=n=3:v=1:a=1 [v][a]" 
-map "[v]" -map "[a]" out.mp4



Running


ffmpeg -n -i foo.MOV -i bar.mp4 -i fiz.mp4



gives this info :


ffmpeg version 4.3.1 Copyright (c) 2000-2020 the FFmpeg developers
 built with Apple clang version 11.0.3 (clang-1103.0.32.62)
 [...configuration omitted...]
 libavutil 56. 51.100 / 56. 51.100
 libavcodec 58. 91.100 / 58. 91.100
 libavformat 58. 45.100 / 58. 45.100
 libavdevice 58. 10.100 / 58. 10.100
 libavfilter 7. 85.100 / 7. 85.100
 libavresample 4. 0. 0 / 4. 0. 0
 libswscale 5. 7.100 / 5. 7.100
 libswresample 3. 7.100 / 3. 7.100
 libpostproc 55. 7.100 / 55. 7.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'foo.MOV':
 Metadata:
 major_brand : qt 
 minor_version : 0
 compatible_brands: qt 
 creation_time : [omitted]
 com.apple.quicktime.make: [omitted]
 com.apple.quicktime.model: [omitted]
 com.apple.quicktime.software: [omitted]
 com.apple.quicktime.creationdate: [omitted]
 Duration: 00:00:04.71, start: 0.000000, bitrate: 17579 kb/s
 Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1920x1080, 17492 kb/s, 24 fps, 24 tbr, 600 tbn, 1200 tbc (default)
 Metadata:
 rotate : 90
 creation_time : [omitted]
 handler_name : Core Media Video
 encoder : H.264
 Side data:
 displaymatrix: rotation of -90.00 degrees
 Stream #0:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 44100 Hz, mono, fltp, 63 kb/s (default)
 Metadata:
 creation_time : [omitted]
 handler_name : Core Media Audio
 Stream #0:2(und): Data: none (mebx / 0x7862656D), 9 kb/s (default)
 Metadata:
 creation_time : [omitted]
 handler_name : Core Media Metadata
 Stream #0:3(und): Data: none (mebx / 0x7862656D), 0 kb/s (default)
 Metadata:
 creation_time : [omitted]
 handler_name : Core Media Metadata

Input #1, mov,mp4,m4a,3gp,3g2,mj2, from 'bar.mp4':
 Metadata:
 major_brand : isom
 minor_version : 512
 compatible_brands: isomiso2avc1mp41
 encoder : Lavf58.29.100
 Duration: 00:00:01.94, start: 0.000000, bitrate: 641 kb/s
 Stream #1:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/unknown/smpte170m), 480x360 [SAR 1:1 DAR 4:3], 354 kb/s, 24.58 fps, 24.58 tbr, 113734695.00 tbn, 49.16 tbc (default)
 Metadata:
 handler_name : VideoHandler
 Stream #1:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 280 kb/s (default)
 Metadata:
 handler_name : SoundHandler
 
Input #2, mov,mp4,m4a,3gp,3g2,mj2, from 'fiz.mp4':
 Metadata:
 major_brand : isom
 minor_version : 512
 compatible_brands: isomiso2avc1mp41
 encoder : Lavf58.29.100
 Duration: 00:00:01.98, start: 0.000000, bitrate: 725 kb/s
 Stream #2:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, smpte170m/unknown/smpte170m), 480x360 [SAR 1:1 DAR 4:3], 442 kb/s, 24.58 fps, 24.58 tbr, 113734695.00 tbn, 49.16 tbc (default)
 Metadata:
 handler_name : VideoHandler
 Stream #2:1(und): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 278 kb/s (default)
 Metadata:
 handler_name : SoundHandler