View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006971||MediaMonkey (current)||Other||public||2010-12-11 20:02||2011-03-07 22:34|
|Target Version||4.1||Fixed in Version|
|Summary||0006971: My first impressions about new v4.0 video database|
|Description||1) The new Actors field from the Songs table is the only one named in plural, other multi-item fields like Artist or Genre are in singular, which is inconsistent and confusing. The Properties dialog box displays Actor(s), but also Producer instead of Producer(s), Screenwriter instead of Screenwriter(s)...|
2) I don't know any video application that use term "Dimensions" which you are using in Properties dialog box and for column in the main tracklist. It is mostly Resolution, but I also seen Image Size, Frame Size, Video Size, but never Dimensions.
3) After all required and requested video fields that I mentioned earlier, you have added only VideoWidth, VideoHeight and FrameRate. There are SubTitle and Language fields, but they are not displayed in Properties dialog box anyway and cannot represent multi-audio/subtitle streams in video files.
Here are fields that you need to add if you want true video related database:
a) Video bitrate (which should be separated from audio bitrate(s));
b) Video codec;
c) Audio codec(s) (well, this is rather complex one, since you should add one new table, e.g. AudioStreams, so one video file from the Songs table could be linked to one or more records from that new table by its ID, but in that case you could have represented each audio stream from some video file with its independent technical characteristics as audio bitrate, sample rate, number of channels, audio codec, ...);
d) Language(s) (should be stored independently for each audio stream in that new suggested AudioStreams table as well, but it would be even better if you add one more table with the language names, e.g. Languages, so instead of having each audio stream with string for its language name, it could contain languageID which could be linked to that second table with the actual names, which removes redundancy of strings and reduce database size);
e) Subtitle(s) (well, this one could be stored into existing SubTitle field and could be used in same way as Involved People field, but it would be better to use the suggested Languages table linked by languegeID for the same mentioned reason);
f) Country (or Countries, for co-productions);
g) Storyline/Synopsis (we really don't want to use Comment or some Custom field for that);
h) URL (even Winamp has this on the ID3v2 tab);
i) Total number of files/discs (this is already missing for audio database);
j) Actors names in movie (should be used in same way as musician roles in Involved People field, which is still not realized after several years of asking).
|Tags||No tags attached.|
|Fixed in build|
Re: "- Video bitrate (which should be separated from audio bitrate(s));"
Some video players display three values regarding bitrates relating to videos. There's the video bitrate, the audio bitrate, as well as a "total bitrate" which gives the user the sum of bitrates used to play the file. The last one seems like it could be useful, such as if video streaming is involved?
||Assigned to Rusty for triage|
Re: Total bitrate
Yeah, that could be useful to get displayed somewhere, e.g. in the Properties dialog box (actually, that value is already displayed into the Properties dialog box and stored into database, instead of separate video bitrate and audio bitrate(s)). However, I am not sure if this should be stored into database since it could be easily calculated from the existing fields.
By the way, I think that the total bitrate is not just simple sum of video and audio bitrates. Firstly, you could have several audio streams within single video file. Then you could have one or more subtitle streams. There are also control and navigational data stored into file, e.g. private streams in VOB files, which should be also taken in account if you want to calculate bandwidth for some video streaming.
The situation is much more complex with video files which have two or more video streams, e.g. DVDs with multiple video angles, since their appearance is not always linear as it is a case with audio steams assigned to some video stream. For example, Buena Vista movies are using multiple video angles/streams only during the end of the movie when there are displayed casts and credits independently for each language as a new angle. There are also discs with different video content of the same movie (e.g. regular version and director's cut) where the most part of the movie is represented as one video stream, but only different parts of the movie are represented with multiple video streams. Anyway, this is all to much to consider and I don't suggest a support for video files with multiple video streams, but in my opinion multiple audio and subtitle streams should be supported since they could be important for non-English users.
Thanks for the feedback.
1) Multi-attribute fields are now properly labelled
2) Agreed--string change should be: Dimensions --> Resolution. Added to 0007413
3) Re. additional fields, I'm going to open new bugs to cover that, pending decision of how we want to phase this in. e.g. it can be divided as follows:
i) Add support for displaying file properties (e.g. Video codec, video bitrate, audio codec, audio bitrate, language, subtitle)
ii) Add attributes to db and make them editable (e.g. add all the above + make e.g. language / subtitles editable)
iii) Support for multiple streams in relation to properties from i) and ii)
iv) Add other attributes e.g. country, storyline, url, (need to verify tagging support)
4) Number of discs is tracked at 0004920 . As to whether we need to add this field to the 'basic' Properties tab, I'm not sure.
5) Support for Actor(s) in the same manner as involved people (need to verify tagging support): Need to add a new bug for this.
Setting to Immediate for triage:
a) the following strings need to be added immediately for 4.0:
Language(s) (added at 0007413)
Note that the following strings already exist: