Earlier, Brion Vibber wrote:
Apparently the US Library of Congress has been archiving videos as MXF (the container format that MOX is planned to be based off) with lossless-mode JPEG 2000 for the video payload... and they're pushing a baseline format around that for digital video preservation.
This is also the basis of the 'DCP' format used for distribution to theatres with digital projectors, so there's simplicity in standardizing that for archival of finished films.
Of course JPEG 2000 and MXF both specification with gratis distribution, but I'm not aware of any patent restrictions on implementations.
-r
wow everyone... this is great stuff where this thread is going! (sorry, not really an addition to the topic discussed. But I wanted to show my appreciation somehow...)
2014-11-10 19:52 GMT+01:00 Ralph Giles giles@thaumas.net:
Earlier, Brion Vibber wrote:
Apparently the US Library of Congress has been archiving videos as MXF (the container format that MOX is planned to be based off) with lossless-mode JPEG 2000 for the video payload... and they're pushing a baseline format around that for digital video preservation.
This is also the basis of the 'DCP' format used for distribution to theatres with digital projectors, so there's simplicity in standardizing that for archival of finished films.
Of course JPEG 2000 and MXF both specification with gratis distribution, but I'm not aware of any patent restrictions on implementations.
-r
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
I second what Sebastian said -- glad we could revive Wikivideo-L to have deeper technical discussions like this that don't annoy the multimedia-L list.
When I have more time, I'd like to test our more of what Brion said. The solution may be right under our nose with older, but tested, solutions like MJPEG/PCM, though we'd still be requiring pretty fast bandwidth to deal with them.
-Andrew
-Andrew Lih Associate professor of journalism, American University Email: andrew@andrewlih.com WEB: http://www.andrewlih.com BOOK: The Wikipedia Revolution: http://www.wikipediarevolution.com PROJECT: Wiki Makes Video http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wiki_Makes_Video
On Mon, Nov 10, 2014 at 1:55 PM, Sebastiaan ter Burg terburg@wikimedia.nl wrote:
wow everyone... this is great stuff where this thread is going! (sorry, not really an addition to the topic discussed. But I wanted to show my appreciation somehow...)
2014-11-10 19:52 GMT+01:00 Ralph Giles giles@thaumas.net:
Earlier, Brion Vibber wrote:
Apparently the US Library of Congress has been archiving videos as MXF (the container format that MOX is planned to be based off) with lossless-mode JPEG 2000 for the video payload... and they're pushing a baseline format around that for digital video preservation.
This is also the basis of the 'DCP' format used for distribution to theatres with digital projectors, so there's simplicity in standardizing that for archival of finished films.
Of course JPEG 2000 and MXF both specification with gratis distribution, but I'm not aware of any patent restrictions on implementations.
-r
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
-- Sebastiaan ter Burg *Projectleider Culturele Samenwerking* *Wikimedia Nederland* ________________________________ tel.: +31 30 32 00 238 gsm: +31 6 480 88 615 e-mail: terburg@wikimedia.nl wiki: Ter-burg https://nl.wikipedia.org/wiki/Gebruiker:Ter-burg ________________________________ www: www.wikimedia.nl wiki: nl.wikimedia.org ________________________________ *Postadres*: * Bezoekadres:* Postbus 167 Mariaplaats 3 3500 AD Utrecht Utrecht ________________________________
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Yeah I'd recommend simple MJPEG/PCM for now as something that "works as-is" with some limitations[1], but investing a little time and effort on things like MOX or JPEG2000-in-MXF / Dirac-in-MXF might be wise for the future.
[1] no 4:2:2, 4:4:4, or alpha; highest qual settings are still much lower bandwidth and presumably quality than the ProRes generation. Probably still suitable for many purposes though.
-- brion
On Mon, Nov 10, 2014 at 11:23 AM, Andrew Lih andrew@andrewlih.com wrote:
I second what Sebastian said -- glad we could revive Wikivideo-L to have deeper technical discussions like this that don't annoy the multimedia-L list.
When I have more time, I'd like to test our more of what Brion said. The solution may be right under our nose with older, but tested, solutions like MJPEG/PCM, though we'd still be requiring pretty fast bandwidth to deal with them.
-Andrew
-Andrew Lih Associate professor of journalism, American University Email: andrew@andrewlih.com WEB: http://www.andrewlih.com BOOK: The Wikipedia Revolution: http://www.wikipediarevolution.com PROJECT: Wiki Makes Video http://en.wikipedia.org/wiki/Wikipedia:WikiProject_Wiki_Makes_Video
On Mon, Nov 10, 2014 at 1:55 PM, Sebastiaan ter Burg <terburg@wikimedia.nl
wrote:
wow everyone... this is great stuff where this thread is going! (sorry, not really an addition to the topic discussed. But I wanted to show my appreciation somehow...)
2014-11-10 19:52 GMT+01:00 Ralph Giles giles@thaumas.net:
Earlier, Brion Vibber wrote:
Apparently the US Library of Congress has been archiving videos as MXF (the container format that MOX is planned to be based off) with lossless-mode JPEG 2000 for the video payload... and they're pushing a baseline format around that for digital video preservation.
This is also the basis of the 'DCP' format used for distribution to theatres with digital projectors, so there's simplicity in standardizing that for archival of finished films.
Of course JPEG 2000 and MXF both specification with gratis distribution, but I'm not aware of any patent restrictions on implementations.
-r
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
-- Sebastiaan ter Burg *Projectleider Culturele Samenwerking* *Wikimedia Nederland* ________________________________ tel.: +31 30 32 00 238 gsm: +31 6 480 88 615 e-mail: terburg@wikimedia.nl wiki: Ter-burg https://nl.wikipedia.org/wiki/Gebruiker:Ter-burg ________________________________ www: www.wikimedia.nl wiki: nl.wikimedia.org ________________________________ *Postadres*: * Bezoekadres:* Postbus 167 Mariaplaats 3 3500 AD Utrecht Utrecht ________________________________
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
On 2014-11-10 02:37 PM, Brion Vibber wrote:
Yeah I'd recommend simple MJPEG/PCM for now as something that "works as-is" with some limitations[1], but investing a little time and effort on things like MOX or JPEG2000-in-MXF / Dirac-in-MXF might be wise for the future.
[1] no 4:2:2, 4:4:4, or alpha; highest qual settings are still much lower bandwidth and presumably quality than the ProRes generation. Probably still suitable for many purposes though.
-- brion
I'm joining the list a little late and in the middle of this discussion, but have there been requirements defined and if so, can someone point me to them? What are the guidelines that make one existing option better than another? Are looking for lossless-only sources? What is the target material, because not all material uploaded IS lossless. I am sure these have been answered, but I am not yet aware of them.
Thanks!
It's a little vague at this point but I think the keys are:
* For reuse, we want something that's *super-easy* to consume in existing pro, prosumer and consumer editing tools
* Obviously staying out of the patented arena (ProRes ??, AVC-Intra, etc) is a plus * Consuming those formats where ffmpeg takes them is probably ok (but patents??????)
* For archival, we may want something higher quality or less convenient, as long as we can convert with easy tools
Lossless is probably not necessary, but near-lossless that's good enough for reediting is strongly desired.
-- brion
On Mon, Nov 10, 2014 at 11:43 AM, Basil Mohamed Gohar < basilgohar@librevideo.org> wrote:
On 2014-11-10 02:37 PM, Brion Vibber wrote:
Yeah I'd recommend simple MJPEG/PCM for now as something that "works as-is" with some limitations[1], but investing a little time and effort on things like MOX or JPEG2000-in-MXF / Dirac-in-MXF might be wise for the future.
[1] no 4:2:2, 4:4:4, or alpha; highest qual settings are still much lower bandwidth and presumably quality than the ProRes generation. Probably still suitable for many purposes though.
-- brion
I'm joining the list a little late and in the middle of this discussion, but have there been requirements defined and if so, can someone point me to them? What are the guidelines that make one existing option better than another? Are looking for lossless-only sources? What is the target material, because not all material uploaded IS lossless. I am sure these have been answered, but I am not yet aware of them.
Thanks!
Libre Videohttp://librevideo.org
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Brion,
So for the lag in following-up on here. Latter half of November was very busy for me.
I'm interested in taking these requirements and beginning gathering facts with them, with the idea of starting to formulate a proposal. Should we start with these loose requirements, or go further in specifying them first?
On 11/10/2014 03:02 PM, Brion Vibber wrote:
It's a little vague at this point but I think the keys are:
- For reuse, we want something that's *super-easy* to consume in
existing pro, prosumer and consumer editing tools
- Obviously staying out of the patented arena (ProRes ??, AVC-Intra,
etc) is a plus
- Consuming those formats where ffmpeg takes them is probably ok (but
patents??????)
- For archival, we may want something higher quality or less convenient,
as long as we can convert with easy tools
Lossless is probably not necessary, but near-lossless that's good enough for reediting is strongly desired.
-- brion
On Mon, Nov 10, 2014 at 11:43 AM, Basil Mohamed Gohar <basilgohar@librevideo.org mailto:basilgohar@librevideo.org> wrote:
__ On 2014-11-10 02:37 PM, Brion Vibber wrote:Yeah I'd recommend simple MJPEG/PCM for now as something that "works as-is" with some limitations[1], but investing a little time and effort on things like MOX or JPEG2000-in-MXF / Dirac-in-MXF might be wise for the future. [1] no 4:2:2, 4:4:4, or alpha; highest qual settings are still much lower bandwidth and presumably quality than the ProRes generation. Probably still suitable for many purposes though. -- brionI'm joining the list a little late and in the middle of this discussion, but have there been requirements defined and if so, can someone point me to them? What are the guidelines that make one existing option better than another? Are looking for lossless-only sources? What is the target material, because not all material uploaded IS lossless. I am sure these have been answered, but I am not yet aware of them. Thanks! -- Libre Video http://librevideo.org _______________________________________________ Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org <mailto:Wikivideo-l@lists.wikimedia.org> https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
On 2014-11-10 11:37 AM, Brion Vibber wrote:
Dirac-in-MXF might be wise for the future.
FWIW, Brendan confirmed he was interested in Dirac for lossless support. Although he also cited speed as a reason not to use VP9...
https://groups.google.com/a/webmproject.org/d/msg/webm-discuss/V2cf-fEV7_o/T...
-r
I think it's crucially important that examples that are being considered actually be tested in a reproduceable manner before claims about performance/speed/efficiency are made. I'm not directing this at you, Ralph, of course, nor anyone else on this list, but I am having flashbacks to the rtcweb discussion [0] regarding H.261 vs. MPEG-1 vs. Theora vs. whatever, where 5+ year old assumptions about codecs were being flashed around, and when comparisons where actually made [1], the discussion changed tone and direction completely.
So, this does kind of fall back onto "what are the actual goals/requirements we're trying to meet" needing to be clearly specified, so that we can then test the formats we have available against those requirements and make an intelligent decision.
[0] https://www.ietf.org/mail-archive/web/rtcweb/current/msg10382.html [1] https://media.basilgohar.com/rtcweb/
On 11/12/2014 04:20 PM, Ralph Giles wrote:
On 2014-11-10 11:37 AM, Brion Vibber wrote:
Dirac-in-MXF might be wise for the future.
FWIW, Brendan confirmed he was interested in Dirac for lossless support. Although he also cited speed as a reason not to use VP9...
https://groups.google.com/a/webmproject.org/d/msg/webm-discuss/V2cf-fEV7_o/T...
-r
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
I am having problems seeing a clear line in this discussion. Could someone help me clarify what the archival file format is going to be used for exactly?
* Internal format for the "video server"? (e.g. export rendered sequences to the archival format and create lossy/SD transcodes for consumption (w.commons) and keep the archival format for future/subsequent edits) * Uploading videos to the "video server"? (I.e. Prior to upload to the video editing server, every video has to be transcoded into the archival format... Needs a lot of bandwith, imo...) * Storing source videos on the video editing server? (I.e. After upload to the server, every video is being transcoded into the archival format and deleted after successful transcoding) * Uploading lossless video to commons? (Patent situation needs to be considered...) * Several of the above and/or other?
--Marco
Hi,
Am 14.11.2014 05:52, schrieb Marco F:
I am having problems seeing a clear line in this discussion. Could someone help me clarify what the archival file format is going to be used for exactly?
the discussion is a bout a free, high quality format we could allow to be uploaded to Commons, in order to allow sharing of raw material.
The video editing server is trying to solve the same problem - sharing raw footage - in a different way. It is not dependant on a free file format and is not subject of this discussion - I just brought it up as an alternate way dealing with this problem.
- Internal format for the "video server"? (e.g. export rendered
sequences to the archival format and create lossy/SD transcodes for consumption (w.commons) and keep the archival format for future/subsequent edits)
the video editing server will accept and store the raw material in its original file format, as provided by the camera. It can deal with almost any codec - everything FFMpeg can read.
- Uploading videos to the "video server"? (I.e. Prior to upload to the
video editing server, every video has to be transcoded into the archival format... Needs a lot of bandwith, imo...)
the upload is something we cannot avoid - any kind of sharing in whatever format, on Commons or elsewhere, will involve at least an initial upload.
The video editing server does not use an intermediate format. It stores the original files as they come in. It transcodes only to create proxy clips which are much smaller and we already have determined the format for those: WebM.
- Storing source videos on the video editing server? (I.e. After upload
to the server, every video is being transcoded into the archival format and deleted after successful transcoding)
no, nothing will be deleted. We need the orginal files to render the videos. Once a producer uploads the project file created from the WebM proxy clips, the server will replace the proxy clips with the original files in the project file and then render it.
- Uploading lossless video to commons? (Patent situation needs to be
considered...)
The rendered files will be (for now) high quality WebM. Those will then be moved to Commons. If another producer wants to remix a video, all the source material can be found on the video editing server and the proxy clips thereof can be downloaded, along with the project files, and remixed. Once the remix is ready the producer uploads the new project file and the server will go through the render process again.
If Commons decides to accept new video formats we can consider the video editing server to render the videos in a new format. For now WebM is the best option, we also have to consider that the videos on Commons should also work on the web.
/Manuel
Marco,
The first objective is to be able to share high quality footage with each other to enable offline cooperative editing. The second would be online cooperative editing. The server that does this would be separate from commons, only final edits would go to commons.
A rough sketch (that I need to update following the discussions lately): https://docs.google.com/a/wikimedia.nl/presentation/d/1sS8WnMO6iFidEPkyNMk2g...
Sebastiaan ter Burg
E | terburg@wikimedia.nl W | http://www.wikimedia.nl M | +31648088615 T | @ter_burg
~message sent on the move~
On 14 nov. 2014, at 05:52, Marco F maic23@live.de wrote:
I am having problems seeing a clear line in this discussion. Could someone help me clarify what the archival file format is going to be used for exactly?
- Internal format for the "video server"? (e.g. export rendered sequences to the archival format and create lossy/SD transcodes for consumption (w.commons) and keep the archival format for future/subsequent edits)
- Uploading videos to the "video server"? (I.e. Prior to upload to the video editing server, every video has to be transcoded into the archival format... Needs a lot of bandwith, imo...)
- Storing source videos on the video editing server? (I.e. After upload to the server, every video is being transcoded into the archival format and deleted after successful transcoding)
- Uploading lossless video to commons? (Patent situation needs to be considered...)
- Several of the above and/or other?
--Marco _______________________________________________ Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Dear all,
I’m happy to announce that finally the development contract by VWA has been awarded to Dan Dennedy, lead developer of MLT and of Shotcut. He will develop it on a VM on the Internet Archive cluster. Target date is January. The specs are here: https://de.wikipedia.org/wiki/Wikipedia:WikiTV/Schnittserver/Specification
Best, Volker
Am 14.11.2014 um 09:08 schrieb Sebastiaan ter Burg / Wikimedia Nederland terburg@wikimedia.nl:
Marco,
The first objective is to be able to share high quality footage with each other to enable offline cooperative editing. The second would be online cooperative editing. The server that does this would be separate from commons, only final edits would go to commons.
A rough sketch (that I need to update following the discussions lately): https://docs.google.com/a/wikimedia.nl/presentation/d/1sS8WnMO6iFidEPkyNMk2g...
Sebastiaan ter Burg
E | terburg@wikimedia.nl W | http://www.wikimedia.nl M | +31648088615 T | @ter_burg
~message sent on the move~
On 14 nov. 2014, at 05:52, Marco F maic23@live.de wrote:
I am having problems seeing a clear line in this discussion. Could someone help me clarify what the archival file format is going to be used for exactly?
- Internal format for the "video server"? (e.g. export rendered sequences to the archival format and create lossy/SD transcodes for consumption (w.commons) and keep the archival format for future/subsequent edits)
- Uploading videos to the "video server"? (I.e. Prior to upload to the video editing server, every video has to be transcoded into the archival format... Needs a lot of bandwith, imo...)
- Storing source videos on the video editing server? (I.e. After upload to the server, every video is being transcoded into the archival format and deleted after successful transcoding)
- Uploading lossless video to commons? (Patent situation needs to be considered...)
- Several of the above and/or other?
--Marco _______________________________________________ Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
Wikivideo-l mailing list Wikivideo-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikivideo-l
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 2014-11-13 8:20 PM, Basil Mohamed Gohar wrote:
I think it's crucially important that examples that are being considered actually be tested in a reproduceable manner before claims about performance/speed/efficiency are made.
Yes, of course. It's also helpful to ask developers about the scope for optimizations. Live capture and production work have very different requirements from the more popular distribution and conferencing applications.
Traditionally this has resulted in separate codec designs. Dirac Pro is of course an exception here. :)
-r
wikivideo-l@lists.wikimedia.org