Conversion to webm file duration issue

VLC version: My VLC version is off course the latest one (VLC 2.1.5)

What I did: I tried to convert a *.VOB file into a *.webm file. I also tried with an *.mp4 file into a *.webm file, and I noticed the same issue.

Problem description: My input file (.VOB) duration is 31min14s The output file (.webm) real duration is well 31min14s, but 1h27min19s is displayed in the navigation bar!!!

prabou

added Component::Stream output: Muxers label

I can add that this issue has been reproduced on both: -my office PC, which is a Windows 7 Enterprise SP1 -my personnal computer which is a Linux Mint 17 MATE

Since this has not seen any progress, I will add something what I have discovered on VLC 3.0.18: The duration of the converted video is always set to whatever the current time is. If I was to convert a video to WebM right now, the duration would be somewhere around 17:25:00 (My time zone is EST).

That's weird, indeed.

assigned to @asenat

AFAICT this is only happening in 3.0.x and not in master/4.0

Did you test in 4.0?

If you mean the 4.0-dev tag (1f2e534f) I'm not able to build that here (my system ffmpeg isn't compatible and contrib ffmpeg borks on git.libav.org), but I did test in master (3cb6645b)

changed milestone to %3.0.x maintenance

From what I can tell, this isn't (e.g., vp8/vp9) webm specific, it's for any format using the avformat muxer in 3.0.x. I tested:

• h264/mp4: default was fine, forcing mux=avformat led to a borked duration
• ogg/theora: same

and since we have no mkv/webm muxer, there is only avformat's which is what the OP is about.

Yes, it’s a bug from our avformat module

Ok from a bit more digging I think it's not just the avformat muxer that's the problem, it's just the only one (at least that I've seen) that's not hiding what I think is an issue upstream in the pipeline. It seems that in 3.0.x, muxers are being fed input with pts starting at e.g., 732698107 as soon as they call block_FifoGet on their input, as opposed to saner values that we see in 4.0.x (e.g., 0).

For some reason, muxers like mp4 seem to be compensating and so the final file is ok, but the avformat muxer is not. So either there's some correction missing in avformat or the issue with the input needs to be fixed.

You must workaround this in avformat module.

We changed the behaviour in 4.0 for the core for the new clock, but this won't be fixable in the same way for 3.0.

Ergo, the workaround in avformat in 3.0

This is the simplest/dumbest workaround, but it does work: !3409 (merged)

TBF, it'd be nice to fix it in 3.0.x

mentioned in merge request !3409 (merged)

mentioned in commit fdfb5bc2

changed milestone to %3.0.19

added Status::fixed label

closed

mentioned in issue #27987 (closed)

mentioned in issue #14585 (closed)