14 replies to this topic

[lanfear]

Hi there!

 

Some AVC format movies shot using cellphones in "portrait" mode have a rotate attribute, which says how the movie should be rotated at playback.

 

Rotation in ZP has been discussed earlier (see thread below), and it was dismissed with the arguments that it was not doable by ZP devs. Is this still the case? Is it up to the filters to read the attributes and format videos accordingly?

 

Video rotation option

http://forum.inmatri...showtopic=13163

 

Thanks for any info!

[ehathgepiurhe]

H lanfear,

Yes, that is still the case. Filter wise, there are two places this could be added - in the video renderer, or the video decoder.

With regards to the video renderer, we really only have one choice. That being madVR - the reason being that none of the other video renderers that Zoom supports are under active development. Last time I checked, madshi had been asked to add such an option to madVR, and hadn't ruled it out, but had put it down as a low priority. Assuming madshi did add it, bLight would then have to add support for the new option to Zoom itself. I personally don't think that the video renderer is the best place to put it however - the reason being that if it was added to madVR, only people who use madVR could make use of it (considering madVR is not the Zoom default, I'd suggest that it is likely the majority of Zoom users do not use madVR).
 
The other possibility around madVR support is that bLight wants to add pixel shader support to Zoom Player (to be used in conjunction with madVR, which has supported pixel shaders for a while now). I think it may be possible to do rotation via a pixel shader (there seems to be a rotate shader script in JanWillem32's pixel shader pack). If so, that wouldn't require madshi to explicitly add support to madVR for rotation, nor would bLight have to do anything except aside from adding pixel shader support, which he already wants to do. The downside is that you would need to activate the pixel shader manually for each video (whereas if madshi added support directly to the renderer, the video would be rotated automatically). Pixel shader thread is here for information:
http://forum.inmatri...showtopic=13987

With regards to the video decoder, we basically have two choices: ffdshow, and LAV Video. Development on ffdshow has ceased, so we can rule it out. That leaves LAV. I think that the video decoder is a better place for it, as Zoom by default uses LAV Video for quite a number of formats, making it more likely that someone who wants to use the rotate function would have access to the component to be able to achieve it. Again however, anyone choosing not to use LAV would be out of luck.

Having said all that, I would still like to see this option to be in the player itself. Yes, I can understand the argument that some of the more esoteric features should be in the filters - but considering the way that portrait videos are generated (a fairly simple rotation of the video camera is all it takes to record one), I think the player is the correct place for this option.

What I would suggest is for anyone wanting a rotate function, to do two things:
1. Hop over to Doom9, and post a message in the LAV and madVR threads, adding your support for a rotate option to be added. Threads are here:

http://forum.doom9.o...ad.php?t=156191 (LAV)

http://forum.doom9.o...ad.php?t=146228 (madVR)

bLight has indicated here that nev has stated he wouldn't add the option to LAV so that may be a dead end, but it wouldn't hurt to ask again:

http://forum.doom9.o...069#post1594069 (see also madshi's post right after that, where he says rotation is on his list for madVR)

2. Hop into the pixel shader thread I linked above, and add your support for that feature to be added to Zoom.

If we can't get the feature added to Zoom itself, the best we can do is to get support for it both in the video renderer and the video decoder. That way, it would maximise the number of people who would be able to access it. The tracker report for support for this in Zoom is closed, but I will add this thread to the end of the report, as more support for the feature itself. That way, if the opportunity does arise in the future, we can say that more people support it being added.

ehat

Edited by ehathgepiurhe, 18 November 2013 - 08:41 AM.
Added link to bLight's Doom9 post, re nev's response (must have imagined nev's other response, so removed it from my response)

[lanfear]

Hi ehathgepiurhe, and thanks for your super-ambitious response! I'm very impressed.

 

Just wanted to say that I need to read it a few times more in full to digest, will reply soon.

[ehathgepiurhe]

It's been a bit quiet over the holiday break, so I've spent some time on this today (actually, I ended up spending most of the day on it, but that's another story!). With some advice and assistance from bLight, this is what I managed to work out. This is a bit of a wall of text - but that's unavoidable I'm afraid.

 

1. JanWillem32's rotate PS does not actually do what the name implies. Yes, it sort of rotates the video image - but only after splitting it into a red channel, a green channel, and a blue channel...and displaying all them separately:

http://i.imgur.com/m3cNrQ3.jpg

 

It's a mess in other words, so we can rule out a PS method of rotation, unless someone knows of a proper PS rotation script.

 

2. I mentioned the possibility of having this in LAV - forget that. It won't work. For the reason why, see the next two points, in particular #4.

 

3. One possibility I did not mention previously was finding a DS filter that does rotation. As it turns out, there is such a filter:

http://videoprocessi...rge.net/#rotate

 

Admittedly, it does have some downsides. First, it is not automatic rotation - it does not detect the rotation flags and rotate automatically in other words (you have to trigger the rotation manually, which is a little tedious). Second, it only works on RGB24 and RGB32, so you need to also insert the Colour Space Converter filter into the playback chain. However, on the plus side, it is freeware and open source (I believe there are other rotation filters out there, but payware - and of course, if you know enough about DS, you could simply create your own filter). Loading this into the Zoom Player filter chain, we get mixed results. Rotation of 90 degrees, 270 degrees and diagonal all produce totally garbled output:

http://i.imgur.com/4riVR5p.jpg

 

Rotation of 180 degrees, vertical or horizontal works fine (though vertical does not seem to actually change the image at all - but it doesn't garble it either, so I call it 'working'). That is the same with all the renderers Zoom supports. This leads into the next point, and this is where bLight's advice was especially handy.

 

4. The video renderer has to be able to accept dynamic resolution changes or rotation will not work. This is likely the problem with the rotation filter - 180 degrees is not changing the width x height of the video clip, but 90 degrees would, as the test clip was not the same width as it was height. As stated above, all the video renderers Zoom supports failed with this, so none of them support this at this time. Now, as posted in the thread linked in the first post, SMPlayer (a Windows GUI around the *nix mplayer) does support rotation, and in fact, works fine with that test clip. However, as a *nix program, it is not really a standard DS player, so it won't really be using the DS video renderers that Zoom and other Windows native players are restricted to - so we can forget about it. However, there is a Windows native program that does support rotation, and that is MPC-BE (though BE is a fork of MPC-HC, which in turn is a fork of MPC, MPC-HC does not support rotation, only BE does).

 

I did some testing with BE, and found that it automatically rotated the test clip, but only when using it's own EVR CP. It does not support rotation for normal EVR, nor madVR, nor any of the other renderers. The changelog for BE gives these two items:

+ MP4/MOV Splitter - added support for AMR Wide band audio tracks, support for Rotate tag;

+ Support for reading Rotate tag from QuickTime files (using internal splitter) and video rotation (if video renderer supports it);

 

I did in fact use the standalone versions of both the MPC MP4/MOV splitter and the MPC video decoder, and loaded them into Zoom. The test clip was not rotated, pretty much demonstrating again that renderer support is required - and that this support is just not there in any of the current standard DS renderers. Both MPC-HC and MPC-BE have CP versions of EVR, but only BE has modified that further to support rotation.

 

What does this all mean? Two things. Firstly, bLight could theoretically write a CP for Zoom Player. That is not going to happen, so we can rule it out to start with. Secondly, with that being the case, we need madshi to add rotation support (or at least support for dynamic resolution changes) to madVR. At that point in time, depending on what madshi did exactly, we may have a way forward (it may be that we would still have to use a separate filter where we had to rotate manually, or madVR might be able to do it automatically itself, or even if madVR did not do the rotation automatically, Zoom may be able to retrieve and send the flag to madVR to trick it into doing it automatically). We just won't know until madshi makes a move (so to speak).

 

So, keeping in mind that madshi is not accepting feature requests at the moment (he has stated multiple times that he wants to focus on other stuff until at least v1.0 is released), what we need to do is to forget everything I mentioned in my previous post, and to keep this feature request visible to him. But not so frequently as to cause madshi to go 'I have told you before that I am not accepting feature requests at the moment' (some individuals over on Doom9 have received this response multiple times now).

 

ehat

[ehathgepiurhe]

Just another small update.

 

1. I asked the dev's of the rotation filter why the video is corrupted when rotated at certain angles, but have yet to receive a full reply (I did get an initial reply, asking for a test clip and some details such as the filter chain in use etc, which I provided but have heard nothing since then).

 

2. JanWillem32 kindly created a proper rotatation PS script. It works pretty well in MPC-HC and MPC-BE (you can find it in JanWillem's thread over on Doom9 if you are are interested in seeing how it works). I sent it to bLight, and he said that he would look into it for Zoom, he just needed some time to do some testing with it - not sure whether he meant as part of the full PS support for madVR, or as a separate (interim) option. We'll see.

 

3. With the new 0.60 release of LAV, nev has added this to LAV Splitter:

 

Additional metadata from the source file is exported through IPropertyBag (including "ROTATION" for video orientation information)

 

This does not mean that LAV will rotate videos:

 

 

All it does is allow the player to read the metadata, anything else is up to the player.

[STi Sev]

Other than built-in codecs, this is one of the most highly prized features I want. It's a shame there are technical limitations

[ehathgepiurhe]

Yes - I still think the chances are good we will get it, it's more just a question of when in my mind. I'm not going to let bLight forget it - I just need to be careful that I don't raise it that often that he thinks I am nagging about it So there is a bit of a balancing act there.

 

In the short term, I expect that the PS option will be more likely to happen than the madVR support (the latter is the best option, with LAV now passing that rotation information onwards, there would be nothing stopping the rotation from happening automatically - whereas the PS option has to be activated manually).

 

Anyway, I will keep this on the radar, that's all I can do for the moment.

 

ehat

[ehathgepiurhe]

There has been some more progress on this one - minor progress admittedly, but progress nonetheless bLight has now integrated the rotation pixel shader that JanWillem32 wrote directly into Zoom. At the moment, the script is triggered by Shift+R, and rotates the video 90 degrees clockwise for each press of the hotkey. It's not ideal that it has to be triggered manually, but for the moment, it is probably the best we can do - I haven't fully explored with bLight the implications of LAV now passing along the rotation metadata, but my understanding is that we still need madVR to add rotation support to make this an automatic rotation method. I know nev said "...anything else is up to the player" - but I don't believe Zoom can do anything except for passing this along to the video renderer to process (I think had the player been able to do anything with that information - as in use it to rotate the video itself - bLight would have added support for it rather than integrating the pixel shader as he has done). Also, the feature does require you to be using madVR.

 

Anyway, putting that aside, the one thing that Zoom does not do as yet is to compensate for the cropping that happens because of width/height differences in the video (in other words, for videos where the video width is different to the video height). Here is a screenshot:

http://i.imgur.com/QgdqTzg.jpg

 

The video was a little dark which has reflected in the screenshots - apologies for that, I should have picked a better example video - so you may have to brighten your screen a little to see all the details. There are 4 separate images in the screenshot, marked 1.1, 1.2, 2.1 and 2.2. Image 1.1 is the normal, non-rotated video. Image 1.2 is the 90 degrees rotation. Image 2.1 is the 180 degrees rotation and finally image 2.2 is the 270 degrees rotation (aka -90 degrees). If you look at the non-rotated image (1.1), focus on two things. First, to the left of the animal skull at the top left hand side of the video, you can see some objects (shelves with bottles on them). Secondly, there is a pistol on the bench down at the bottom right hand side of the video. You can see an object (a bottle) to the right of the pistol barrel.

 

Now look at the 90 degrees image (1.2). You can see that the objects to the left of the skull and the object to the right of the pistol barrel have been cut off. This is because there is no compensation for the sudden change in width and height of the video once it has been rotated.

 

If you then move to the 180 degree image (2.1), the video is back to normal (shows full details), except it is upside down. Though obviously, if the video was accidentally filmed upside down, it would now be the right way up!

 

Lastly, look at the 270 degree image (2.2) - again, the previously mentioned details have been cut-off.

 

The video I used to take the screenshots was 1280x720 - if the video was the same width and height, it should not be affected by this (but honestly, I don't know if I have a single video that has the same width and height in my collection, so I think these are relatively rare). So, still some more work to be done (I think the next step is for bLight to investigate how the player compensates for the change in video dimensions - whether that is a player function, whether it needs video renderer support or whatever), but we are getting there (I like to think of this feature request as the 'little engine that could' request - as in, "I think I can, I think I can...").

 

ehat

Edited by ehathgepiurhe, 07 February 2014 - 09:46 AM.
Forgot to mention madVR requirement

[lanfear]

I don't really understand all the technical details, but I'm impressed with the progress nonetheless.

 

Good work ehat & bLight!

[ehathgepiurhe]

Though v9.0 now has a manual rotate function for madVR users (Shift+R), there are still two pieces of the puzzle missing:

 

1. madVR needs to add a function for automatic resizing of the video. At the moment, there is no way to compensate for the cropping that happens because of width/height differences in the video (in other words, for videos where the video width is different to the video height - see the screenshot in my previous post). As it turns out, the player cannot do this by itself - it requires renderer support; and

 

2. madVR needs to add a function to do something automatically with the rotation data that LAV now passes onwards. This would mean that if a video has a rotation flag set, rotation would happen automatically when you play it.

 

I see #1 as the bigger issue at the moment - #2 would be a 'nice to have' in comparison.

 

Regards,

 

ehat

[STi Sev]

This is still one of two of my most-requested, most-desired features. I understand why it can't happen from Zoomplayer's end.

 

Anyways, for those who are interested: I requested Donation coders to create an app that will convert these videos easily.

https://www.donation...61667#msg361667

 

ehathgepiurhe,

I could not find this "SHIFT R" feature you speak of.

 

1. I checked madVR settings

2. I checked zoomplayer and searched for "madvr". 

[ehathgepiurhe]

Hi,

As long as you are using the default key file, simply hit shift + r while a video is playing to rotate it. There is no option in Zoom that you have to change to enable it, so you won't find anything listed in either Zoom's options or madVR's options.

If shift + r does not work for you, ensure that Zoom is actually using madVR (it hasn't fallen back to one of the other renderers for example), and if you are not using the default key file, then add that function to your custom key file (if you are using a custom key file based on a pre v9 version of Zoom, shift + r was mapped to the aspect ratio options).

ehat

[ehathgepiurhe]

Though v9.0 now has a manual rotate function for madVR users (Shift+R), there are still two pieces of the puzzle missing:

1. madVR needs to add a function for automatic resizing of the video. At the moment, there is no way to compensate for the cropping that happens because of width/height differences in the video (in other words, for videos where the video width is different to the video height - see the screenshot in my previous post). As it turns out, the player cannot do this by itself - it requires renderer support; and
 
2. madVR needs to add a function to do something automatically with the rotation data that LAV now passes onwards. This would mean that if a video has a rotation flag set, rotation would happen automatically when you play it.

I see #1 as the bigger issue at the moment - #2 would be a 'nice to have' in comparison.

 
Rumour has it that we may have #1 addressed in the very near future...
 
ehat

[ehathgepiurhe]

Ok, as promised, #1 has now been addressed with the release of Zoom v11.1 Beta 2. It includes this:

 

  + The video rotate feature (Shift+"R") now uses a new MadVR feature that
    no longer crops part of the image while rotating.  The latest version of
    MadVR is now required to perform video rotation.

 

In other words, no longer will parts of the video be cropped off when rotating Please note that the current stable madVR version - 0.89.12 - does not actually support this feature as yet however. There is a later test version which madshi has not released publically as yet which does so, and it works nicely. The next stable version of madVR - when released - should have this functionality (so it will be available to everyone), and it will quite possibly have another function that people who are interested in rotation may appreciate as well...ie, one that will address #2 as well (yes, automatic rotation based on the file metadata passed through to madVR by LAV Video) It's been a long time coming, but I think with the release of the next madVR stable version, we may have reached the end of this particular journey

 

ehat

[ehathgepiurhe]

The madVR version which supports rotation has now been released:

http://forum.doom9.o...postcount=34004

 

These are the two relevant changes:

 

* added support for rotation (0°, 90°, 180°, 270°) via key shortcut and API
* videos are automatically rotated now, if the container/splitter says so

 

ehat