if I want to create a new preset with DNxHD codec and with "based on source (repack)" option the video section looks like this (in german language... lastest version):
Normally (e.g. h264) it should look like this:
So at the moment it's unusable!
The options are different, but I've used mine, which looks like yours ... so I'm wondering what you mean by "unusable"?
Ah so it's the same in the english version?
Well, there are no checkboxes on the right side.
All values like hight, width, framerate and so on are missing.
And then there are 3 checkboxes below that with no value text. I can uncheck them and nothing happen or I dont know what happens, because the whole window content is messed up.
The same with the Audio section. Nearly all the information is missing:
Can you post a screenshot of your window. I'm not sure, if we are talking about the same thing.
Maybe I should reinstall it in english to see, if it's just a error in the german version.
Ok, same thing in english version. This only happens with "Format" DNxHD and "Based on Preset" Match Source (Rewrap).
Have you actually exported using that preset, and then say dropped the file onto MediaInfo, gone to Tree View, and seen the results of what it put out?
For me, it matched the original file. Period.
Which is what I expected of "match source" ... though admittedly, some of the other "match source" options sure don't seem to. Which is why I'd tested it. But I test everything anyway.
Well, no I didn't tested the output. But that's not the point anyway.
If I choose "match source" and I want to leave everthing the same expect for example the framerate, i can not change it, because simply the parameter is not shown in this window. If I choose h.264 instead of DNxHD, the possibility to change just the framerate und leave the other parameters untouched is there.
I'm pretty sure, that in previous version of AME the "match source" windows all were looking the same regardless of which format I choose.
So this is a kind a graphics bug.
Can you post a screenshot of your Preset Settings window?
It's the same as yours, for the DNxHD/R. As I noted above.
The difference between a bug and a Design Feature ... is the bug works different than the engineers expected. The Design Feature works as expected. This is a Design Feature thing. They've designed this to work this way.
You and I may not like it, but ... that's a design issue. I'm sure they'd point out that if you want to change anything, there's only what ... 38 or whatever DNxHD/R presets to choose from. And I've no clue why they do the options thing to allow more 'after-market' choices with a Match/Re-Wrap choice in H.264 than DNxHD/R.
You're more than welcome to submit a feature request for this change ... it's the one way we users can at least get things put on the list of possible things for fixes/changes/new features that the upper managers look at to choose things to do.
It seems to be a bug in the latest version. We have created an internal bug to track this issue. Thanks for reporting the issue and sorry for the inconvenience.
To clarify on match source rewrap for DNx vs match source for H.264; when rewrap preset in DNx is selected, video frames from the source are copied to the output (called smart render) without decode and then re-encode of the video frames, so this option results in faster render times preserving the source. The match source preset for H.264 tries to match the output setting with that of the source setting, but it will result in re-encode (decode & encode) because we don't support smart render for H.264 output. This also means with match source for H.264 you can individually match source basic video settings while you can't do that with rewrap preset.
thanks for your response and that you can confirm the bug.
I don't need this function every day, but it made me mad that nobody out there found this bug except me.
I'm looking foreward to the fix.
I'm not sure what the bug is ...
In the DNxHD explanation you give, that's clearly a designed (planned) operation, and involves a true re-wrap without re-encoding the data, which is a great thing. It would be nice of course if this was actually explained somewhere.
That's very different than the H.264 operations you explain, where that does do a re-encode, and therefore allows mods to the encoded result. While there are times it's appropriate to mod the output, and nice to have, that does seem a completely different process than the one used for the DNxHD/R match-source rewrap.
Which leaves me wondering, other than the difference not being obvious nor explained, where's the "bug"?
maybe I use the word "bug" wrong (sorry, I'm from Germany).
The only thing I was complaining about, is the layout of the DNxHD/match-source rewrap window compared to the other codecs match-source rewrap windows.
It's just a graphical error (checkboxs at the wrong places, missing checkboxes, no text, etc).
It's not about the functionality.