How does MLV App deal with dropped frames?

[ilia3101]

Especially if there's audio

[masc4ii]

Hm... I never had a file with a dropped frame, so I can't tell for sure. I would expect at least on export, that the audio would loose sync on a dropped frame... but I never tried. No idea for internal handling.

[ilia3101]

Yeah I guess most people have drop frames disabled, but you can enable it. I will have to investigate. I wonder if the camera numbers the frames with a gap to indicate that there is one missing, or maybe the hardware timestamp must be used to figure this out.

[bouncyball-git]

@ilia3101: I've implemented hardware timestamp sorting long time ago ;) (frame_index_sort() function in video_mlv.c)

Masc supplied me with the awful MLV with unsorted frames. It played with chops and hiccups before I changed file reading alg simply not to rely on frame number taken from the VIDF header struct. Now it handles this file almost perfectly (almost because this MLV had dropped frames too)

@masc4ii: do you still have that MLV? - some machine's moving its arm (like printer) :)

[masc4ii]

I am not sure if I still have it. Problem: I don't see those problems 😄
I know that you're sorting those frames using the timestamp. But what happens when a frame is missing? E.g. do we show the previous frame twice?

[bouncyball-git]

Also I put the brute force code (video_mlv.c) to handle corrupted header MLVs. I have one sample MLV (someone posted on the forum, girl walks on the street and some guy comes along with her and talks to her...) and it is working nicely. Loading a bit slower but finally indexing is done and file plays fine.

[bouncyball-git]

I am not sure if I still have it. Problem: I don't see those problems smile

hehehe

I know that you're sorting those frames using the timestamp. But what happens when a frame is missing? E.g. do we show the previous frame twice?

nope :( it just omits it and goes on... audio can be not synced. That MLV of yours had no audio and I could not test it.

[ilia3101]

It played with chops and hiccups before I changed file reading alg simply not to rely on frame number taken from the VIDF header struct. Now it handles this file almost perfectly (almost because this MLV had dropped frames too)

So the hardware timestamp is also useful. Interesting. What is the unit of time that it counts in? Milliseconds? Or just something arbitrary?

[bouncyball-git]

Microseconds.

[bouncyball-git]

If you see my old, awful but working ;) MLV generating code in raw2dng - timestamp, MLV ID and so on... all necessary data is generated.

I love your LibMLV idea!

btw in dng.c (mlvapp) we have 2 functions: raw data unpacker to 16bit word (written by dmilligan) and 16bit to any bit packer (written by me. I'm using this to produce any bit depth DNGs). You can make use of them, your packers are may be a bit faster but anyway one function instead of 3 and the possibility to pack to ANY bit depth is not bad I think.

[ilia3101]

btw in dng.c (mlvapp) we have 2 functions: raw data unpacker to 16bit word (written by dmilligan) and 16bit to any bit packer (written by me. I'm using this to produce any bit depth DNGs). You can make use of them, your packers are may be a bit faster but anyway one function instead of 3 and the possibility to pack to ANY bit depth is not bad I think.

Wow thank you! Packing to any bitdepth is nice (I guess that means any within 8-16). I will put your function to use. But was dmilligan's unpacking code originally released with a permissive (non GPL) license? I just wanna be careful to avoid putting actual GPL stuff in the new library without original author's permission. (and what do you think of this issue in general)

[bouncyball-git]

Wow thank you! Packing to any bitdepth is nice (I guess that means any within 8-16). I will put your function to use.

You can go all the way down :) (step is 1bit)

But was dmilligan's unpacking code originally released with a permissive (non GPL) license?

It is a part of MLVFS. So... I guess it is GPL3

[ilia3101]

You can go all the way down :) (step is 1bit)

Wow I can't wait to try out 1 bit MLV!

It is a part of MLVFS. So... I guess it is GPL3

I guess 10-12-14 bit unpacking support will do for now, but since implementing those bitdepths myself (pack and unpack) I have a idea of how to adapt it for any bitdepth.

Back to this issue: I will film a clip with audio + dropped frames as soon as I can to finally test how this is handled.