Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#4613 closed defect (invalid)

FFMPEG produces OGV videos whose duration can't be estimated by Totem, VLC and Dragon Player

Reported by: gouessej Owned by:
Priority: normal Component: undetermined
Version: git-master Keywords: ogg theora vorbis
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

Summary of the bug:
Most players under Mageia Linux are unable to run the OGV videos converted from MP4. They don't start automatically in Totem, VLC and Dragon Player, and they don't start at all in Totem and Dragon Player, they indicate that the duration is 0 seconds.

ffprobe indicates:
nb_frames=N/A
nb_read_frames=132
nb_read_packets=N/A

ffplay tells:
"Stream #1: not enough frames to estimate rate; consider increasing probesize"
but following this advice has no effect.

How to reproduce:
ffmpeg -i Video20150609_185820_.mp4 -q:v 10 -q:a 10 -analyzeduration 2147483647 -probesize 2147483647 -report -y Video20150609_185820.ogv

ffmpeg version: 2.7 (static binary build downloaded 10/06/2015)

Attachments (3)

ffmpeg-20150611-193831.log (9.0 KB) - added by gouessej 4 years ago.
Video20150609_185820_.mp4 (1.3 MB) - added by gouessej 4 years ago.
input file (MP4)
ffmpeg_bug_4613_wrong_duration_ogv.png (1.8 MB) - added by gouessej 4 years ago.
Wrong duration (00:00 and --:--) in VLC 2.1.6 for the long OGV video

Change History (50)

Changed 4 years ago by gouessej

Changed 4 years ago by gouessej

input file (MP4)

comment:1 Changed 4 years ago by cehoyos

  • Keywords ogg added; theora ogv removed

Please test current FFmpeg git head and please provide an ogv file for which the other players show the correct duration.
Note that FFmpeg does show the correct duration for the output file here.

comment:2 Changed 4 years ago by gouessej

I'll build FFMPEG as soon as possible. I'm under Mageia Linux 4.1, I tried with vlc 2.1.6, totem 3.10 and dragon 4.12.

Please can you tell me exactly which command you used to show the duration of the video? I'd like to use the same command.

I will provide an ogv file exhibiting the expected behaviour very soon.

comment:3 Changed 4 years ago by gouessej

Firefox 31.7.0 isn't concerned by this bug.

This ogv file works flawlessly with ffplay, Mozilla Firefox, Dragon, Totem and VLC:
https://videos.files.wordpress.com/QRXrtxyt/christel-keiser-01_fmt1.ogv

ffplay shows the correct duration (5:28).

comment:4 Changed 4 years ago by gouessej

VLC 2.1.6 fails to show the correct duration in the bottom right corner for the converted video (OGV) whereas it shows the correct duration for the original video (MP4). It starts the buggy videos only on demand, when I click on the "play" button and the longer the buggy ogv video is, the longer it takes to start playing it.

Note that ffplay shows the correct duration in all cases, sorry if it wasn't clear or if my explanations were confusing.

comment:5 follow-up: Changed 4 years ago by cehoyos

Any chance that we could test a ten seconds video instead of one second?
(I cannot reproduce your issue, totem shows the duration fine.)

Please test vlc 2.2.1, nothing else is supported.

Last edited 4 years ago by cehoyos (previous) (diff)

comment:6 follow-ups: Changed 4 years ago by cehoyos

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

comment:7 in reply to: ↑ 5 Changed 4 years ago by gouessej

Replying to cehoyos:

Any chance that we could test a ten seconds video instead of one second?
(I cannot reproduce your issue, totem shows the duration fine.)

Which version of totem do you use?

Please test vlc 2.2.1, nothing else is supported.

Ok I'll try to play the video with this version of VLC.

Note that when I convert the video with this online service, dragon succeeds in playing it but totem still shows "0 seconds":
http://video.online-convert.com

The difference is in the compatible brands: COMPATIBLE_BRANDS: isomiso2avc1mp41 (working) isom3gp4 (not working at all with dragon). In both cases, VLC 2.1.6 shows 0:00 and Totem shows "0 seconds".

comment:8 in reply to: ↑ 6 Changed 4 years ago by gouessej

Replying to cehoyos:

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

I get tons of error messages when I try to do the same:

[ogg @ 0x4246ce0] Non-monotonous DTS in output stream 0:1; previous: 14453954, current: 14453888; changing to 14453955. This may result in incorrect timestamps in the output file.
[libvorbis @ 0x407cce0] Queue input is backward in time

comment:9 in reply to: ↑ 6 Changed 4 years ago by gouessej

Replying to cehoyos:

I tested the following command:

$ ffmpeg -i christel-keiser-01_fmt1.ogv out.ogv

FFmpeg, vlc and totem all show the correct duration for the output file.

Despite the error messages during the conversion, I confirm that vlc and totem show the correct duration for this output file on my machine too. Note that the converted file is smaller than the original file. The frame rate is 25.

comment:10 Changed 4 years ago by gouessej

When I do this:
ffmpeg -i Video20150609_185820_.mp4 Video20150609_185820.ogv

the video is horrible but works in all tested players and they show the correct duration. Note that this time I see COMPATIBLE_BRANDS: isomiso2avc1mp41 when using ffplay.

comment:11 follow-up: Changed 4 years ago by gouessej

When I add "-q:v 6", the compatible brands are again isomiso2avc1mp41 but the wrong duration appears anew in Totem and VLC. The problem seems to come from that.

comment:12 Changed 4 years ago by gouessej

In the meantime, I confirm that VLC 2.1.6 shows the right duration on longer ogv videos, I've just tried with a converted video during about 18 seconds. There is just a problem of startup on very short videos sometimes but it has probably nothing to do with ffmpeg.

The problem is still there with totem and dragon.

comment:13 Changed 4 years ago by gouessej

The duration is still wrong (00:00) in VLC 2.1.6 on a longer video when I include the part that prints "Stream #1: not enough frames to estimate rate; consider increasing probesize" with ffmpeg.

I'll upload this long video on my FTP soon.

comment:14 Changed 4 years ago by gouessej

I can't compile VLC 2.2.1:
codec/avcodec/video.c: In function ‘InitVideoDec?’:
codec/avcodec/video.c:344:25: erreur: ‘CODEC_FLAG_OUTPUT_CORRUPT’ undeclared (first use in this function)

p_context->flags |= CODEC_FLAG_OUTPUT_CORRUPT;


codec/avcodec/video.c:344:25: note: each undeclared identifier is reported only once for each function it appears in
Makefile:13985: recipe for target 'codec/avcodec/libavcodec_plugin_la-video.lo' failed
Makefile:17327: recipe for target 'all-recursive' failed
Makefile:7725: recipe for target 'all' failed
Makefile:2233: recipe for target 'all-recursive' failed
Makefile:2117: recipe for target 'all' failed
make: * [all] Error 2

Changed 4 years ago by gouessej

Wrong duration (00:00 and --:--) in VLC 2.1.6 for the long OGV video

comment:15 follow-up: Changed 4 years ago by gouessej

The long video whose duration is wrongly shown (00:00 and --:--) in VLC 2.1.6 in its bottom right corner is here:
http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

The upload is still in progress.

comment:16 Changed 4 years ago by cehoyos

If your distribution does not offer current vlc, you have to compile it with internal FFmpeg.

comment:18 in reply to: ↑ 11 Changed 4 years ago by cehoyos

Replying to gouessej:

When I add "-q:v 6", the compatible brands are again isomiso2avc1mp41

I cannot reproduce this.

but the wrong duration appears anew in Totem and VLC.

I cannot reproduce this.

comment:19 in reply to: ↑ 17 Changed 4 years ago by gouessej

Replying to cehoyos:

Replying to gouessej:

http://tuer.sourceforge.net/videos/Video20150609_185820.ogv

410

I'll upload another video that doesn't exceed the max size but with a duration greater than one second, sorry.

comment:21 follow-up: Changed 4 years ago by gjdfgh

Have you considered that ogv should not be used? It's a terrible container format, and issues like this one are the least problem.

Use mkv instead.

comment:22 Changed 4 years ago by gouessej

Are those warnings important? I'm compiling the very latest version of FFMPEG.

libavformat/utils.c: In function ‘av_stream_get_end_pts’:
libavformat/utils.c:119:5: attention : ‘pts’ is deprecated (declared at libavformat/avformat.h:861) [-Wdeprecated-declarations]

return st->pts.val;

libavformat/utils.c: In function ‘avformat_find_stream_info’:
libavformat/utils.c:3039:9: attention : ‘max_analyze_duration’ is deprecated (declared at libavformat/avformat.h:1407) [-Wdeprecated-declarations]

max_analyze_duration = ic->max_analyze_duration;

comment:23 in reply to: ↑ 21 Changed 4 years ago by gouessej

Replying to gjdfgh:

Have you considered that ogv should not be used? It's a terrible container format, and issues like this one are the least problem.

Use mkv instead.

Webm videos don't work very well on very low end machines, especially computers whose CPU has a single core.

If the FFMPEG team considers that OGV shouldn't be used, then OGV shouldn't be supported in FFMPEG. I really do my best to help the developers to reproduce this bug, I have already spent hours and I'm going to try with the very latest version when the compilation has come to an end.

comment:24 follow-up: Changed 4 years ago by gjdfgh

WebM is different from Matroska (WebM only supports VP8 and VP9.)

Matroska itself does support exactly the same codecs as OGV, and more. This includes Theora and Vorbis (the codecs you apparently want to use). The CPU usage for decoding will be exactly the same. Matroska isn't slower to read than OGV either.

You are probably under the mistaken impression that Matroska is inherently slower than OGV, because you've only looked at Matroska files using H264. H264 is indeed slower to decode than Theora, but again, you can use Theora in Matroska.

(By the way, while I'm not entirely sure, I bet using mpeg2 would possibly be faster to decode than Theora, because FFmpeg likely has more optimizations for such an ubiquitous codec as mpeg. But I'm just guessing and don't have the knowledge or numbers to back this up.)

comment:25 in reply to: ↑ 24 Changed 4 years ago by gouessej

Replying to gjdfgh:

WebM is different from Matroska (WebM only supports VP8 and VP9.)

Matroska itself does support exactly the same codecs as OGV, and more. This includes Theora and Vorbis (the codecs you apparently want to use). The CPU usage for decoding will be exactly the same. Matroska isn't slower to read than OGV either.

You are probably under the mistaken impression that Matroska is inherently slower than OGV, because you've only looked at Matroska files using H264. H264 is indeed slower to decode than Theora, but again, you can use Theora in Matroska.

(By the way, while I'm not entirely sure, I bet using mpeg2 would possibly be faster to decode than Theora, because FFmpeg likely has more optimizations for such an ubiquitous codec as mpeg. But I'm just guessing and don't have the knowledge or numbers to back this up.)

Matroska isn't supported by the html5 video tag. I don't use MP4 because I'm against software patents and I really think that webm encourages planned obsolescence.

Videopress uses ogv under the hood and the working ogv video I gave as an example was produced by Videopress. It is possible to use ogv successfully.

comment:26 follow-up: Changed 4 years ago by gjdfgh

Matroska isn't supported by the html5 video tag.

But OGV is? No it isn't. OGV is just a pain generator.

comment:27 in reply to: ↑ 26 Changed 4 years ago by gouessej

Replying to gjdfgh:

Matroska isn't supported by the html5 video tag.

But OGV is? No it isn't. OGV is just a pain generator.

It works in Firefox, Iceweasel, Opera, Chrome and Chromium. I don't mind MS IE/Edge and Safari.

comment:28 follow-up: Changed 4 years ago by gjdfgh

That's actually just 2 browsers. (Or 3, if you _really_ want to count Opera as separate browser.) Anyway, you don't have any reason not to use a better format.

And OGV of all things? OGV is such a terrible nightmare technically. And you use that on purpose? Once more I lose faith in humanity.

comment:29 in reply to: ↑ 28 Changed 4 years ago by gouessej

Replying to gjdfgh:

That's actually just 2 browsers. (Or 3, if you _really_ want to count Opera as separate browser.) Anyway, you don't have any reason not to use a better format.

And OGV of all things? OGV is such a terrible nightmare technically. And you use that on purpose? Once more I lose faith in humanity.

Matroska isn't supported by the video tag, otherwise it would have been an interesting solution and I tried webm before using ogv.

comment:30 Changed 4 years ago by gouessej

This bug isn't reproducible in VLC 2.2.0, someone confirmed it shows the correct duration:
http://jogamp.org/log/irc/jogamp_20150612234958.html#l33

comment:31 Changed 4 years ago by gouessej

The bug is reproducible under Ubuntu 14.04 LTS with Totem 3.10.1 and Xine 0.99.7:
http://jogamp.org/log/irc/jogamp_20150612234958.html#l49

Someone else confirmed that the bug isn't reproducible with VLC git master (2.2.1?).

comment:32 Changed 4 years ago by gouessej

The gnome file manager nautilus version 3.10.1 fails to report it too as it relies on Videos (=Totem):
http://jogamp.org/log/irc/jogamp_20150612234958.html#l66

comment:33 in reply to: ↑ 20 Changed 4 years ago by cehoyos

  • Component changed from ffmpeg to undetermined
  • Resolution set to worksforme
  • Status changed from new to closed

Replying to gouessej:

You can find the original file (longer, 3 seconds) here:
http://tuer.sourceforge.net/videos/Video20150609_185820_.mp4

I converted this file with the following command line:

$ ffmpeg -i Video20150609_185820_.mp4 -q:v 6 out.ogg

The output file shows the correct duration with vlc, totem and FFmpeg here.

Please only reopen this ticket if you can provide a longer input file. Either upload to http://www.datafilehost.com/ (100MB limit) or read https://ffmpeg.org/bugreports.html (NO hard filesize limit).

comment:34 follow-up: Changed 4 years ago by gouessej

I use the following command line:
ffmpeg -i Video20150609_185820_.mp4 -q:v 10 -q:a 10 -analyzeduration 2147483647 -probesize 2147483647 -report -y Video20150609_185820.ogv

I get the following output:
ffmpeg started on 2015-06-14 at 19:39:48
Report written to "ffmpeg-20150614-193948.log"
ffmpeg version 2.7- http://johnvansickle.com/ffmpeg/ Copyright (c) 2000-2015 the FFmpeg developers

built with gcc 4.9.2 (Debian 4.9.2-20)
configuration: --enable-gpl --enable-version3 --disable-shared --disable-debug --enable-runtime-cpudetect --enable-libmp3lame --enable-libx264 --enable-libx265 --enable-libwebp --enable-libspeex --enable-libvorbis --enable-libvpx --enable-libfreetype --enable-fontconfig --enable-libxvid --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libtheora --enable-libvo-aacenc --enable-libvo-amrwbenc --enable-gray --enable-libopenjpeg --enable-libopus --enable-libass --enable-gnutls --enable-libvidstab --enable-libsoxr --cc=gcc-4.9
libavutil 54. 27.100 / 54. 27.100
libavcodec 56. 41.100 / 56. 41.100
libavformat 56. 36.100 / 56. 36.100
libavdevice 56. 4.100 / 56. 4.100
libavfilter 5. 16.101 / 5. 16.101
libswscale 3. 1.101 / 3. 1.101
libswresample 1. 2.100 / 1. 2.100
libpostproc 53. 3.100 / 53. 3.100

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Video20150609_185820_.mp4':

Metadata:

major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.36.100

Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 11207 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
Metadata:

handler_name : VideoHandler?

Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:

handler_name : SoundHandler?

Output #0, ogg, to 'Video20150609_185820.ogv':

Metadata:

major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.36.100
Stream #0:0(eng): Video: theora (libtheora), yuv420p, 1920x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
Metadata:

handler_name : VideoHandler?
encoder : Lavc56.41.100 libtheora
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41

Stream #0:1(eng): Audio: vorbis (libvorbis), 48000 Hz, stereo, fltp (default)
Metadata:

handler_name : SoundHandler?
encoder : Lavc56.41.100 libvorbis
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41

Stream mapping:

Stream #0:0 -> #0:0 (h264 (native) -> theora (libtheora))
Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))

Press [q] to stop, ? for help
frame= 91 fps=2.9 q=0.0 Lsize= 22066kB time=00:00:03.04 bitrate=59306.7kbits/s dup=1 drop=0
video:21862kB audio:101kB subtitle:0kB other streams:0kB global headers:7kB muxing overhead: 0.474406%

I still reproduce this bug. Totem 3.10.1 doesn't play the video and claims that the duration is "0 seconds".

comment:35 in reply to: ↑ 34 ; follow-up: Changed 4 years ago by cehoyos

Replying to gouessej:

  Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Please reopen this ticket (only) if you can provide a longer input sample.

comment:36 in reply to: ↑ 35 ; follow-up: Changed 4 years ago by gouessej

Replying to cehoyos:

Replying to gouessej:

  Duration: 00:00:03.03, start: 0.033333, bitrate: 11221 kb/s

Please reopen this ticket (only) if you can provide a longer input sample.

I'm uploading the original video (MP4, 149 MB) on Data File Host right now.

comment:37 in reply to: ↑ 36 Changed 4 years ago by cehoyos

Replying to gouessej:

I'm uploading the original video (MP4, 149 MB) on Data File Host right now.

Data File Host has a 100MB limit. But I strongly believe that you could find a file that is longer than three seconds but less than 100MB if you try.

comment:38 Changed 4 years ago by gouessej

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:39 follow-up: Changed 4 years ago by cehoyos

Do I understand correctly that you actually don't want to report that GStreamer does not show a duration for the output file (it does here) but that it does not play the output file (I can reproduce that)?

comment:40 in reply to: ↑ 39 Changed 4 years ago by gouessej

Replying to cehoyos:

Do I understand correctly that you actually don't want to report that GStreamer does not show a duration for the output file (it does here) but that it does not play the output file (I can reproduce that)?

Actually, I don't know what Dragon (the default KDE video player) uses but I can file a bug report against Gstreamer too. Sorry, I'm not looking for another flame war.

comment:41 follow-up: Changed 4 years ago by cehoyos

I am just trying to understand your issue: You reported that some players do not show a duration but my guess is currently that your actual issue is that the output file did not play for you. Am I wrong?

comment:42 in reply to: ↑ 41 Changed 4 years ago by gouessej

Replying to cehoyos:

I am just trying to understand your issue: You reported that some players do not show a duration but my guess is currently that your actual issue is that the output file did not play for you. Am I wrong?

I use FFMPEG to convert MP4 files from my smartphone (Samsung Galaxy 3 4G/LTE i9305) into OGV. The resulting videos can't be played in several major players whereas the original files can and those players are able to play some OGV files successfully. I think that something goes wrong during the conversion, even VLC 2.2.0 stutters a lot when playing them.

comment:43 Changed 4 years ago by cehoyos

  • Keywords theora vorbis added
  • Resolution set to invalid
  • Status changed from reopened to closed
  • Version changed from 2.7 to git-master

The issue that GStreamer (or at least some versions of GStreamer) cannot detect audio in high-bitrate ogg files (bitrate > 25MBit) and subsequently fails playback completely can be reproduced when reencoding the attached sample Video20150609_185820_.mp4 (the duration is always correctly shown here). It works fine here with -q:v 6 and -b:v 15M (leading to ~20MBit) and fails here with -q:v 7 and -b:v 20M (leading to ~25MBit).
I don't think there is any indication for a bug in FFmpeg.
The output file does not play here with GStreamer, I believe the issue is reproducible with versions 1.0 and 0.10.

$ ffmpeg -i Video20150609_185820_.mp4 -q:v 7 out.ogv
ffmpeg version N-72941-g4ec14ce Copyright (c) 2000-2015 the FFmpeg developers
  built with gcc 4.7 (SUSE Linux)
  configuration: --enable-gpl --enable-libtheora --enable-libvorbis
  libavutil      54. 27.100 / 54. 27.100
  libavcodec     56. 41.100 / 56. 41.100
  libavformat    56. 36.100 / 56. 36.100
  libavdevice    56.  4.100 / 56.  4.100
  libavfilter     5. 17.100 /  5. 17.100
  libswscale      3.  1.101 /  3.  1.101
  libswresample   1.  2.100 /  1.  2.100
  libpostproc    53.  3.100 / 53.  3.100
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'Video20150609_185820_.mp4':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.36.100
  Duration: 00:00:01.03, start: 0.033333, bitrate: 10523 kb/s
    Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p, 1920x1080, 10727 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
    Metadata:
      handler_name    : VideoHandler
    Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 130 kb/s (default)
    Metadata:
      handler_name    : SoundHandler
Output #0, ogg, to 'out.ogv':
  Metadata:
    major_brand     : isom
    minor_version   : 512
    compatible_brands: isomiso2avc1mp41
    encoder         : Lavf56.36.100
    Stream #0:0(eng): Video: theora (libtheora), yuv420p, 1920x1080, q=2-31, 200 kb/s, 30 fps, 30 tbn, 30 tbc (default)
    Metadata:
      handler_name    : VideoHandler
      encoder         : Lavc56.41.100 libtheora
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
    Stream #0:1(eng): Audio: vorbis (libvorbis), 48000 Hz, stereo, fltp (default)
    Metadata:
      handler_name    : SoundHandler
      encoder         : Lavc56.41.100 libvorbis
      major_brand     : isom
      minor_version   : 512
      compatible_brands: isomiso2avc1mp41
Stream mapping:
  Stream #0:0 -> #0:0 (h264 (native) -> theora (libtheora))
  Stream #0:1 -> #0:1 (aac (native) -> vorbis (libvorbis))
Press [q] to stop, [?] for help
frame=   31 fps=7.8 q=0.0 Lsize=    3441kB time=00:00:01.04 bitrate=26962.4kbits/s dup=1 drop=0
video:3405kB audio:12kB subtitle:0kB other streams:0kB global headers:7kB muxing overhead: 0.668602%

comment:44 Changed 4 years ago by gouessej

Thank you for your detailed explanations, they will be very useful to fix the bug within GStreamer. Thank you for your patience too. I'll fill a bug report against GStreamer as soon as possible.

comment:45 follow-up: Changed 4 years ago by cehoyos

Please note that I did not test current GStreamer!
Additionally, I (strongly) suggest you do not report "no duration estimated" if your actual issue is "no playback".

comment:46 in reply to: ↑ 45 Changed 4 years ago by gouessej

Replying to cehoyos:

Please note that I did not test current GStreamer!
Additionally, I (strongly) suggest you do not report "no duration estimated" if your actual issue is "no playback".

Ok but Totem 3.10.1 still shows "0 seconds" and plays nothing. I see what you mean. I'll do my best. Then, I have to get the source code of GStreamer, build it and test it with the resulting video.

comment:47 Changed 4 years ago by gouessej

Note: See TracTickets for help on using tickets.