Movie Strip not showing in video editing preview only sound is working #78046

New Issue

Ram Noureddine · 2020-06-19T22:23:20+02:00

Ram Noureddine commented

2020-06-19 22:23:20 +02:00

System Information
Operating system: Windows-10-10.0.19041-SP0 64 Bits
Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 446.14

Blender Version
Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 14:38, hash: 211b6c29f7
Worked: (newest version of Blender that worked as expected)

Short description of error
I was dragging and dropping my usual .mp4 file to my video editing project, the sounds are working but the video isn't showing. I tried the same .mp4 file in VFX project and it worked there. I

{F8632488}then tried to import the same video file using the add - movie strip but I got an error. Then I renamed the file containing the following characters: Call of Duty®_ Modern Warfare® 2020-06-15 18-19-35. And it worked. Bare in mind I have 15 other movie strips carrying the same characters but different numbers. I am using an external drive. I drag and dropped the file (like I normally do) and the preview doesn't show. I copied the file to my computer and still the preview did not show. If I have a video with these characters, then the preview doesn't show: Call of Duty®_ Modern Warfare® 2020-06-15 03-56-05 Call of Duty®_ Modern Warfare® 2020-06-15 03-20-53 Call of Duty®_ Modern Warfare® 2020-06-15 02-33-57 Call of Duty®_ Modern Warfare® 2020-06-15 02-27-21. HOWEVER, if I have the following characters, the video preview in the video editing shows and works just fine: Call of Duty®_ Modern Warfare® 2020-04-26 21-00-17 Call of Duty®_ Modern Warfare® 2020-04-26 21-16-20 Call of Duty®_ Modern Warfare® 2020-04-26 22-10-30 and so on with previous dates. By renaming the rest of my new .mp4 files, all of them work correctly in the video editing sequencer.

Exact steps for others to reproduce the error
Open Blender
Select the blend.file that you are working on
drag and drop a .mp4 video to the sequencer with the following characters of the file name: Call of Duty®_ Modern Warfare® 2020-06-15 18-19-35
Click play

COD Pro Kills Part 1.blend

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce GTX 1050 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 446.14 **Blender Version** Broken: version: 2.83.0, branch: master, commit date: 2020-06-03 14:38, hash: `211b6c29f7` Worked: (newest version of Blender that worked as expected) **Short description of error** I was dragging and dropping my usual .mp4 file to my video editing project, the sounds are working but the video isn't showing. I tried the same .mp4 file in VFX project and it worked there. I ![Annotation 2020-06-19 210737.png](https://archive.blender.org/developer/F8632487/Annotation_2020-06-19_210737.png) {[F8632488](https://archive.blender.org/developer/F8632488/Thank_you_bencrulis.png)}then tried to import the same video file using the add - movie strip but I got an error. Then I renamed the file containing the following characters: Call of Duty®_ Modern Warfare® 2020-06-15 18-19-35. And it worked. Bare in mind I have 15 other movie strips carrying the same characters but different numbers. I am using an external drive. I drag and dropped the file (like I normally do) and the preview doesn't show. I copied the file to my computer and still the preview did not show. If I have a video with these characters, then the preview doesn't show: Call of Duty®_ Modern Warfare® 2020-06-15 03-56-05 Call of Duty®_ Modern Warfare® 2020-06-15 03-20-53 Call of Duty®_ Modern Warfare® 2020-06-15 02-33-57 Call of Duty®_ Modern Warfare® 2020-06-15 02-27-21. **HOWEVER,** if I have the following characters, the video preview in the video editing shows and works just fine: Call of Duty®_ Modern Warfare® 2020-04-26 21-00-17 Call of Duty®_ Modern Warfare® 2020-04-26 21-16-20 Call of Duty®_ Modern Warfare® 2020-04-26 22-10-30 and so on with previous dates. By renaming the rest of my new .mp4 files, all of them work correctly in the video editing sequencer. ![Thank you bencrulis.png](https://archive.blender.org/developer/F8632490/Thank_you_bencrulis.png) **Exact steps for others to reproduce the error** Open Blender Select the blend.file that you are working on drag and drop a .mp4 video to the sequencer with the following characters of the file name: Call of Duty®_ Modern Warfare® 2020-06-15 18-19-35 Click play [COD Pro Kills Part 1.blend](https://archive.blender.org/developer/F8632478/COD_Pro_Kills_Part_1.blend)

Ram Noureddine commented

2020-06-19 22:23:20 +02:00

Added subscriber: @ramramosol

Richard Antalik commented

2020-06-23 11:25:54 +02:00

Added subscriber: @iss

Richard Antalik commented

2020-06-23 11:25:54 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Richard Antalik commented

2020-06-23 11:25:54 +02:00

I assume this will be issue in movie loading code somewhere since sound is working correctly.

Before classifying as a bug I will like to actually look at the code.

I assume this will be issue in movie loading code somewhere since sound is working correctly. Before classifying as a bug I will like to actually look at the code.

Sergey Sharybin commented

2020-06-24 11:29:41 +02:00

Added subscriber: @Sergey

Sergey Sharybin commented

2020-06-24 11:29:41 +02:00

@iss, are you able to reproduce the issue? I've tried renaming a lot of files here and everything still works correct.

What is most likely happening is that somewhere in either own or FFmpeg code non-widechar version of file operation is used, which makes it so files with non-ASCII symbols can not be opened on Windows.

In order to dig deeper we really need to have small video (could be default cube rendered with few frames) which demonstrates the issue. We can use it for debugging and to add to the regression set collection.

@iss, are you able to reproduce the issue? I've tried renaming a lot of files here and everything still works correct. What is most likely happening is that somewhere in either own or FFmpeg code non-widechar version of file operation is used, which makes it so files with non-ASCII symbols can not be opened on Windows. In order to dig deeper we really need to have small video (could be default cube rendered with few frames) which demonstrates the issue. We can use it for debugging and to add to the regression set collection.

Richard Antalik commented

2020-06-24 11:45:53 +02:00

@Sergey yes, I was able to reproduce with following file: F8640318

@Sergey yes, I was able to reproduce with following file: [F8640318](https://archive.blender.org/developer/F8640318/C_a_l_l___o_f___D_u_t_y_______M_o_d_e_r_n___W_a_r_f_a_r_e_______________________________________________________________________2020-06-15_02-33-57.MP4)

Sergey Sharybin commented

2020-06-24 12:03:47 +02:00

@iss, do you mind trying to download file and reproduce it again? Just to be sure phabricator doesn't "sanitize" the name in some way. Also, can you share your exact steps, maybe I'm missing something.
For me the file opens fine in both Movie Clip and Sequencer editors.

@iss, do you mind trying to download file and reproduce it again? Just to be sure phabricator doesn't "sanitize" the name in some way. Also, can you share your exact steps, maybe I'm missing something. For me the file opens fine in both Movie Clip and Sequencer editors.

Richard Antalik commented

2020-06-24 12:20:43 +02:00

Hmm filename is messed up by phabricator. But if I change file name to Call of Duty®_ Modern Warfare® 2020-06-15 02-33-57.MP4 I can reproduce.

Hmm filename is messed up by phabricator. But if I change file name to `Call of Duty®_ Modern Warfare® 2020-06-15 02-33-57.MP4` I can reproduce.

Richard Antalik commented

2020-06-24 12:35:26 +02:00

I can open file though in movie clip editor, so issue will be on our side, which I suspect would be the case. I can look into this. Should be pretty straight forward to track how the string is processed.

As for steps, I just drag&drop from desktop to VSE or clip editor.

I can open file though in movie clip editor, so issue will be on our side, which I suspect would be the case. I can look into this. Should be pretty straight forward to track how the string is processed. As for steps, I just drag&drop from desktop to VSE or clip editor.

Philipp Oeser commented

2020-06-24 12:47:03 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2020-06-24 12:47:03 +02:00

reminds me of #69430

Sergey Sharybin commented

2020-06-24 12:54:04 +02:00

There are two aspects here:

Drag&drop does appear to work in Clip Editor, and in VSE it creates sequences but shows empty image. This aspect should be fixable.
Doing Shift-A -> Movie does not create a strip.

The reason for that is because the name contains some weird character sequences which don't appear to be valid UTF-8. They are ignored in Explorer, so can not really see them (is more sivible when doping dir in cmd). Those characters pushes full path past FILE_MAX define. And this is something where story becomes interesting. Technically, the constant is wrong for POSIX (where PATH_MAX is 4K AFAIR), but is also wrong for Windows, where wide-char API can deal with paths up to full NTFS 32K length.

Didn't manage to quickly solve this, there are some issues which are being discovered after increasing the constant.

The reason drag&drop works is because Win32 API sanitized path for us a bit, making it possible to open.

Realistically I think we should fix drag&drop case. The "overflowing" path is more of a limitation of the current design, which renders to "Known Issue".

There are two aspects here: - Drag&drop does appear to work in Clip Editor, and in VSE it creates sequences but shows empty image. This aspect should be fixable. - Doing Shift-A -> Movie does not create a strip. The reason for that is because the name contains some weird character sequences which don't appear to be valid UTF-8. They are ignored in Explorer, so can not really see them (is more sivible when doping `dir` in `cmd`). Those characters pushes full path past `FILE_MAX` define. And this is something where story becomes interesting. Technically, the constant is wrong for POSIX (where PATH_MAX is 4K AFAIR), but is also wrong for Windows, where wide-char API can deal with paths up to full NTFS 32K length. Didn't manage to quickly solve this, there are some issues which are being discovered after increasing the constant. The reason drag&drop works is because Win32 API sanitized path for us a bit, making it possible to open. Realistically I think we should fix drag&drop case. The "overflowing" path is more of a limitation of the current design, which renders to "Known Issue".

Richard Antalik commented

2021-01-25 09:04:40 +01:00

This doesn't work in sequencer because media location is stored as directory and filename separately. Problem is with filename buffer that is 256 bytes long while actual filename is 348 bytes long.

I assume this scheme is used because it is more efficient to store image sequences this way and 256 character filename limit was common at the time.

Not sure what is best way forward here.

StripElem.name buffer can be extended, but total path lenght would exceed FILE_MAX which may cause problems. It would be best if FILE_MAX would be much larger to allow this extension. Still problem is that NTFS seems to allow ~2^16 bytes for both path and filename.
Movie files can use separate buffer for storing path. I don't think this would complicate code too much, it may actually eliminate joining path for these files that is all over the place. Also readability probably wouldn't suffer much if we separate movies from image sequences.
Leave code as is and add error message that filename is too long when trying to load file.

@Sergey what do you think?

This doesn't work in sequencer because media location is stored as directory and filename separately. Problem is with filename buffer that is 256 bytes long while actual filename is 348 bytes long. I assume this scheme is used because it is more efficient to store image sequences this way and 256 character filename limit was common at the time. Not sure what is best way forward here. - `StripElem.name` buffer can be extended, but total path lenght would exceed FILE_MAX which may cause problems. It would be best if FILE_MAX would be much larger to allow this extension. Still problem is that NTFS seems to allow ~2^16 bytes for both path and filename. - Movie files can use separate buffer for storing path. I don't think this would complicate code too much, it may actually eliminate joining path for these files that is all over the place. Also readability probably wouldn't suffer much if we separate movies from image sequences. - Leave code as is and add error message that filename is too long when trying to load file. @Sergey what do you think?

Sergey Sharybin commented

2021-01-25 14:42:52 +01:00

We shouldn't be introducing special filepath handling to a specific area. As in, if we decide supporting such paths is important, it should be possible to open .blend files, images, movie clips (and not just strips).

Think what we should do here is:

Increase FILE_MAX to 4K. This way we become POSIX compatible, and possibly solve more real world scenarios. While doing this it is important to remember that in DNA values are hardcoded, so need to search for PATH_MAX usage are replace value in those lines.
Have more proper error message when opening file name which exceeds filepath limix.

Ideally the filepaths will be allocated dynamically, but this is a huge change, which is outside of what is possible as a bugfix.

We shouldn't be introducing special filepath handling to a specific area. As in, if we decide supporting such paths is important, it should be possible to open .blend files, images, movie clips (and not just strips). Think what we should do here is: * Increase `FILE_MAX` to 4K. This way we become POSIX compatible, and possibly solve more real world scenarios. While doing this it is important to remember that in DNA values are hardcoded, so need to search for `PATH_MAX` usage are replace value in those lines. * Have more proper error message when opening file name which exceeds filepath limix. Ideally the filepaths will be allocated dynamically, but this is a huge change, which is outside of what is possible as a bugfix.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Movie Strip not showing in video editing preview only sound is working #78046