Jump to content

About DOVI Media Info and Media File Conversions


neik
 Share

softworkz
Message added by softworkz,

These posts were split-out from the following plugin topic for being unrelated:

 

Recommended Posts

Not sure if this is new but just noticed this in the quick-extract logs of the core:

DOVI configuration record: version: 1.0, profile: 8, level: 7, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1

The core is also doing some progress apparently...

  • Thanks 1
Link to comment
Share on other sites

rbjtech
11 hours ago, neik said:

Not sure if this is new but just noticed this in the quick-extract logs of the core:

DOVI configuration record: version: 1.0, profile: 8, level: 7, rpu flag: 1, el flag: 0, bl flag: 1, compatibility id: 1

The core is also doing some progress apparently...

Hi - yea @softworkz mentioned this the other day - ffmpeg and maybe emby have likely added the latest ffmpeg DV developments to their build.

So while this is 'progress' (DV was created in 2014!) - ffmpeg is still missing HDR10+, HLG, Atmos, DTS:X etc etc - so a LONG way to go to match the capabilities of MediaInfo.

Link to comment
Share on other sites

1 hour ago, rbjtech said:

So while this is 'progress' (DV was created in 2014!)

Don't blame ffmpeg! 

Blame Dolby for trying to keep all their stuff secret instead of developing open standards for which they are even legally attacking individual ffmpeg developers for implementing their "inventions".

Also, blame the industry for adopting such standards - like ATSC for example for making DV and AC-4 part of their 3.0 standard. 

 

1 hour ago, rbjtech said:

ffmpeg is still missing HDR10+,

It can already decode HDR10+ data:

image.png.e7a1c2e2fb9895394a54d363fea47b31.png

Link to comment
Share on other sites

DOVI Stream Info:

image.png.a8b14d68dc739877e9de5ecc91436924.png

 

and per-frame decoded data:

 

image.png.3ff7133df1f8f8d51549f7ff717fb44f.pngimage.png.e6ab7a3392f9120415460989d4ba5c87.pngimage.png.3b201b76d1fde8c79305a2542052b554.png

 

 

Link to comment
Share on other sites

FrostByte
32 minutes ago, softworkz said:

 

and per-frame decoded data:

 

image.png.3ff7133df1f8f8d51549f7ff717fb44f.pngimage.png.e6ab7a3392f9120415460989d4ba5c87.pngimage.png.3b201b76d1fde8c79305a2542052b554.png

 

 

@softworkzare you able to see the following from DV profile 7 metadata then using ffmpeg?  That is MEL according to the DV profiles and levels specifications.  Your example looks to be DV8 (no EL).

 

"nlq_offset": 0
"vdr_in_max_int": 1
"vdr_in_max": 0
"linear_deadzone_slope_int": 0
"linear_deadzone_slope": 0
"linear_deadzone_threshold_int": 0
"linear_deadzone_threshold": 0

 

Link to comment
Share on other sites

This is from a profile 7 flle:

Stream Info:

    "streams": [
        {
            "index": 0,
            "codec_name": "hevc",
            "codec_long_name": "H.265 / HEVC (High Efficiency Video Coding)",
            "profile": "Main 10",
            "codec_type": "video",
            "codec_tag_string": "[0][0][0][0]",
            "codec_tag": "0x0000",
            "width": 3840,
            "height": 2160,
            "coded_width": 3840,
            "coded_height": 2160,
            "closed_captions": 0,
            "film_grain": 0,
            "has_b_frames": 2,
            "sample_aspect_ratio": "1:1",
            "display_aspect_ratio": "16:9",
            "pix_fmt": "yuv420p10le",
            "level": 153,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_transfer": "smpte2084",
            "color_primaries": "bt2020",
            "chroma_location": "topleft",
            "refs": 1,
            "r_frame_rate": "24000/1001",
            "avg_frame_rate": "24000/1001",
            "time_base": "1/1000",
            "start_pts": 0,
            "start_time": "0.000000",
            "nb_read_frames": "202",
            "extradata_size": 138,
            "disposition": {
                "default": 1,
                "dub": 0,
                "original": 0,
                "comment": 0,
                "lyrics": 0,
                "karaoke": 0,
                "forced": 0,
                "hearing_impaired": 0,
                "visual_impaired": 0,
                "clean_effects": 0,
                "attached_pic": 0,
                "timed_thumbnails": 0,
                "captions": 0,
                "descriptions": 0,
                "metadata": 0,
                "dependent": 0,
                "still_image": 0
            },
            "tags": {
                "language": "eng",
                "BPS": "89535914",
                "DURATION": "00:00:11.012000000",
                "NUMBER_OF_FRAMES": "264",
                "NUMBER_OF_BYTES": "123246186",
                "_STATISTICS_WRITING_APP": "mkvmerge v66.0.0 ('Josie') 64-bit",
                "_STATISTICS_WRITING_DATE_UTC": "2022-03-27 14:52:12",
                "_STATISTICS_TAGS": "BPS DURATION NUMBER_OF_FRAMES NUMBER_OF_BYTES"
            },
            "side_data_list": [
                {
                    "side_data_type": "DOVI configuration record",
                    "dv_version_major": 1,
                    "dv_version_minor": 0,
                    "dv_profile": 7,
                    "dv_level": 6,
                    "rpu_present_flag": 1,
                    "el_present_flag": 1,
                    "bl_present_flag": 1,
                    "dv_bl_signal_compatibility_id": 6
                }
            ]
        },

Single Frame data:

        {
            "media_type": "video",
            "stream_index": 0,
            "key_frame": 0,
            "pts": 6757,
            "pts_time": "6.757000",
            "pkt_dts": 6757,
            "pkt_dts_time": "6.757000",
            "best_effort_timestamp": 6757,
            "best_effort_timestamp_time": "6.757000",
            "pkt_duration": 41,
            "pkt_duration_time": "0.041000",
            "pkt_pos": "77407181",
            "pkt_size": "444614",
            "width": 3840,
            "height": 2160,
            "pix_fmt": "yuv420p10le",
            "sample_aspect_ratio": "1:1",
            "pict_type": "B",
            "coded_picture_number": 0,
            "display_picture_number": 0,
            "interlaced_frame": 0,
            "top_field_first": 0,
            "repeat_pict": 0,
            "color_range": "tv",
            "color_space": "bt2020nc",
            "color_primaries": "bt2020",
            "color_transfer": "smpte2084",
            "chroma_location": "topleft",
            "side_data_list": [
                {
                    "side_data_type": "Mastering display metadata",
                    "red_x": "34000/50000",
                    "red_y": "16000/50000",
                    "green_x": "13250/50000",
                    "green_y": "34500/50000",
                    "blue_x": "7500/50000",
                    "blue_y": "3000/50000",
                    "white_point_x": "15635/50000",
                    "white_point_y": "16450/50000",
                    "min_luminance": "1/10000",
                    "max_luminance": "10000000/10000"
                },
                {
                    "side_data_type": "Content light level metadata",
                    "max_content": 1000,
                    "max_average": 976
                },
                {
                    "side_data_type": "Dolby Vision RPU Data"
                },
                {
                    "side_data_type": "Dolby Vision Metadata",
                    "rpu_type": 2,
                    "rpu_format": 18,
                    "vdr_rpu_profile": 1,
                    "vdr_rpu_level": 0,
                    "chroma_resampling_explicit_filter_flag": 0,
                    "coef_data_type": 0,
                    "coef_log2_denom": 23,
                    "vdr_rpu_normalized_idc": 1,
                    "bl_video_full_range_flag": 0,
                    "bl_bit_depth": 10,
                    "el_bit_depth": 10,
                    "vdr_bit_depth": 12,
                    "spatial_resampling_filter_flag": 0,
                    "el_spatial_resampling_filter_flag": 1,
                    "disable_residual_flag": 0,
                    "vdr_rpu_id": 0,
                    "mapping_color_space": 0,
                    "mapping_chroma_format_idc": 0,
                    "nlq_method_idc": 0,
                    "nlq_method_idc_name": "linear_dz",
                    "num_x_partitions": 2047,
                    "num_y_partitions": 1,
                    "components": [
                        {
                            "pivots": "0 1023",
                            "pieces": [
                                {
                                    "mapping_idc": 0,
                                    "mapping_idc_name": "polynomial",
                                    "poly_order": 1,
                                    "poly_coef": "0 8388608"
                                }
                            ],
                            "nlq_offset": 0,
                            "vdr_in_max": 8388608,
                            "linear_deadzone_slope": 0,
                            "linear_deadzone_threshold": 0
                        },
                        {
                            "pivots": "0 1023",
                            "pieces": [
                                {
                                    "mapping_idc": 0,
                                    "mapping_idc_name": "polynomial",
                                    "poly_order": 1,
                                    "poly_coef": "0 8388608"
                                }
                            ],
                            "nlq_offset": 0,
                            "vdr_in_max": 8388608,
                            "linear_deadzone_slope": 0,
                            "linear_deadzone_threshold": 0
                        },
                        {
                            "pivots": "0 1023",
                            "pieces": [
                                {
                                    "mapping_idc": 0,
                                    "mapping_idc_name": "polynomial",
                                    "poly_order": 1,
                                    "poly_coef": "0 8388608"
                                }
                            ],
                            "nlq_offset": 0,
                            "vdr_in_max": 8388608,
                            "linear_deadzone_slope": 0,
                            "linear_deadzone_threshold": 0
                        }
                    ],
                    "dm_metadata_id": 0,
                    "scene_refresh_flag": 0,
                    "ycc_to_rgb_matrix": "9574/8192 0/8192 13802/8192 9574/8192 -1540/8192 -5348/8192 9574/8192 17610/8192 0/8192",
                    "ycc_to_rgb_offset": "16777216/268435456 134217728/268435456 134217728/268435456",
                    "rgb_to_lms_matrix": "7222/16384 8771/16384 390/16384 2654/16384 12430/16384 1300/16384 0/16384 422/16384 15962/16384",
                    "signal_eotf": 65535,
                    "signal_eotf_param0": 0,
                    "signal_eotf_param1": 0,
                    "signal_eotf_param2": 0,
                    "signal_bit_depth": 12,
                    "signal_color_space": 0,
                    "signal_chroma_format": 0,
                    "signal_full_range_flag": 1,
                    "source_min_pq": 7,
                    "source_max_pq": 3079,
                    "source_diagonal": 42
                }
            ]
        },

 

Edited by softworkz
  • Like 1
Link to comment
Share on other sites

rbjtech
1 hour ago, softworkz said:

Don't blame ffmpeg! 

Blame Dolby for trying to keep all their stuff secret instead of developing open standards for which they are even legally attacking individual ffmpeg developers for implementing their "inventions".

Also, blame the industry for adopting such standards - like ATSC for example for making DV and AC-4 part of their 3.0 standard. 

 

It can already decode HDR10+ data:

image.png.e7a1c2e2fb9895394a54d363fea47b31.png

I'm not 'blaming' anybody !

If Dolby want to protect their IP from being decoded by unlicensed software/hardware - then that seems reasonable to me ?

Link to comment
Share on other sites

Just because you said:

3 hours ago, rbjtech said:

So while this is 'progress' (DV was created in 2014!) - ffmpeg is still missing HDR10+, HLG, Atmos, DTS:X etc

If the standard was open, ffmpeg would probably have had it in 2014 already 🙂 

Link to comment
Share on other sites

MagicDoubleM
On 6/13/2022 at 3:06 PM, rbjtech said:

:)

The basic MKV container conversion is a good thing to have in the toolbox - as it's basically an enabler for the main MediaInfo function that only works on MKV's ;)

But for other more complex DV conversions, then we would be going down a rabbit hole that we really don't wanna contemplate entering .. !!

I'd like to see the DTS to 'Add Dolby track' added - but that is very simple process.

btw - we are just testing the new formatting of the Plugin - each function now has it's own tab (like Introskip did) - it looks very wizzy now - Dave has done an amazing job of making it all look as nice as it functions ;)   He is also adding an event listener to run the task on demand - ie as you add new items.

Once final testing is done - then it can go into the catalog.

@Cheesegeezer

 

I do agree. Converting to mkv makes total sense, since it's enabling the plugin to do what it's intended to do. Everything else was just brainstorming and getting excited about the idea to do more in that process. Even the mentioned audio transcoding might be better placed in another plugin at another time (but i'll gladly take in any form, hehe)

Link to comment
Share on other sites

Please please please guys - don't do all those conversions as if your media files were zip files. Only very rarely does this make anything better, but often the opposite.
At some day I will have enough from looking at all those kaputt-converted files and I'll quit. 🙂

  • Haha 1
Link to comment
Share on other sites

rbjtech
8 hours ago, MagicDoubleM said:

I do agree. Converting to mkv makes total sense, since it's enabling the plugin to do what it's intended to do. Everything else was just brainstorming and getting excited about the idea to do more in that process. Even the mentioned audio transcoding might be better placed in another plugin at another time (but i'll gladly take in any form, hehe)

So the concept of a 'MKV toolbox' came about as building on a Plugin is much easier than creating one from scratch and if the themes are related (ie MKV manipulation) then I personally don't see any issues with it all going into the same plugin.  Now it uses Tab's - it's much easier to see this is a separate 'function'.

Where the line needs to be drawn is where you are using the plugin to do independent functions - the HDR>SDR BIF generator actually falls into the category.  In it's current simplistic form - it probably doesn't warrant it's own plugin - but if it's expanded to add lets say multi-threaded normal BIF creation - then a stand alone plugin would probably be the way to go.

This is @Cheesegeezer's plugin at the end of the day - so he has the final say ;)

  • Like 1
Link to comment
Share on other sites

rbjtech
8 hours ago, softworkz said:

Please please please guys - don't do all those conversions as if your media files were zip files. Only very rarely does this make anything better, but often the opposite.
At some day I will have enough from looking at all those kaputt-converted files and I'll quit. 🙂

Why do you feel that converting to the MKV container is not the way to go ?   The plugin relies on the media being MKV - as it is the only container that allows you to modify the headers without re-writing the entire file. 

The conversion is a 1:1 container swap - 'mkvmerge -o output.mkv input.ext' - that's it - it is not doing anything else.

To add, MP4's with any form of DV in them are NOT converted by default - as we know they can cause issues.

Personally, I think a MKV toolset like this to 'fix up' bad or missing codec from media files is long overdue - and will actually reduce support calls to emby.  How many support requests have there been about DV not playing or no audio from a DTS-HD only stream for example ? 

Edited by rbjtech
  • Like 2
Link to comment
Share on other sites

MagicDoubleM
12 hours ago, rbjtech said:

Why do you feel that converting to the MKV container is not the way to go ?   The plugin relies on the media being MKV - as it is the only container that allows you to modify the headers without re-writing the entire file. 

The conversion is a 1:1 container swap - 'mkvmerge -o output.mkv input.ext' - that's it - it is not doing anything else.

To add, MP4's with any form of DV in them are NOT converted by default - as we know they can cause issues.

Personally, I think a MKV toolset like this to 'fix up' bad or missing codec from media files is long overdue - and will actually reduce support calls to emby.  How many support requests have there been about DV not playing or no audio from a DTS-HD only stream for example ? 

Also, it's about options you chose to turn on (or not), these are not default settings. And regarding the comparison to zip files, actually it's not a far stretch to compare mkv/mp4 to compression formats like zip and rar.

To me a file itself isn't sacred and needs to stay bit identical forever, as long as the content streams themselves remain untouched/preserved/under my control. But the container and metadata, sure let's fiddle around if it adds something to the experience.

Link to comment
Share on other sites

2 minutes ago, MagicDoubleM said:

And regarding the comparison to zip files, actually it's not a far stretch to compare mkv/mp4 to compression formats like zip and rar.

That's exactly the problem: a wrong understanding of container formats 😭

Link to comment
Share on other sites

MagicDoubleM
11 minutes ago, softworkz said:

That's exactly the problem: a wrong understanding of container formats 😭

I know it's not exactly the same, hence the phrasing. And in the end, in most cases it doesn't mean any losses/problems to me(!) if i convert between them.

Why hold on an mp4 (which you can recreate) when the mkv puts the same pixels on your screen and audio on your speakers and then has a little bonus in regards of streamlined metadata?

Link to comment
Share on other sites

Time stamps, interleaving, packet writing/partitioning/layout, packet level information, side data handling, mux offsets, out-of-stream information, bitstream format support, stream information, seekability, indexing, stream type/codec support, quality and completeness of codec support, codec extradata handling, frame extradata handling, indication, indexing, ...

Those were just the very first things that I could name quickly, so it's far from complete.

"Media container" is actually not a very good term, because these are not really just a kind of "container". That's why I made the comparison to "zip files", in which you combine a number of "stream files" together, while the "stream files" would always be the same, just in a different container.

It's not as simple as that. The only reason why it sometimes appears to be like that, is that many people have worked hard and put a lot for effort into making it look like it was as easy as that. But container conversions and re-muxings are never perfect 1:1 representations of the original. 

  • In rare cases it can bring an improvement
    (e.g. old AVI files with broken or missing index entries, where seeking to the end takes endlessly long)
  • In the majority of cases it works out okay when you use the right tools and know how to use them in the right way
    (many don't unfortunately)
  • Then there are those cases where it doesn't turn out well
    not a huge percentage but also not rare
    • In a majority of those cases it's clear to users that it was their own fault because it's obvious (e.g. no playing or with noticeable issues)
    • Then there are cases where after some comparison with other files or players, it becomes evident that it's an issue with the file
      (either from a user's own investigation, or from the initial stages of Emby support)
       
    • But the remaining cases at this point - are those that make me suffer...

      Why?

      Because in most cases, you can't easily know whether it's a technical issue in the software - or just an incorrectly authored file.

      The effort for finding out is often the same, and it's frustrating to find out that it was for nothing.

 

That's why I ask you to be careful, avoid conversions unless really necessary and don't encourage others to do so.

It is Emby's very job to handle all of your media files,

  • no matter which format or origin
  • in the best possible way
  • for all kinds of playback or other target situations.

But we can be doing well in this discipline only, when we can rely on files being professionally authored (ideally) or at least by some who know what they are doing and how to do it, and (better only) for a solid reason.

So, to be honest: converting DV files to MKV for the reason that MKV provides a few more metadata fields is a pretty bad idea!

DV is not even officially supported in MKV, but even when it was: what you get is never an exact equivalent to the original file. Whether those converted files will work in Emby for all DV profiles, I can't promise. I also can't promise whether Emby will correctly detect them as DV with the correct profile.

Please avoid going crazy for file conversions.

Thanks
sw

(this is a general statement for all current and future readers, not targeting anyone in this conversation directly 🙂 )

Edited by softworkz
  • Like 1
Link to comment
Share on other sites

rbjtech

Thanks for the detailed response as always @softworkz

I consider myself a reasonably experienced AV enthusiast when it comes to conversion - obviously not at your level, but I've been around since the original MPG1 format first began ..

The very first thing I said to Dave was to exclude all MP4's with any form of DV in them - as it's a complete minefield as you say.

IF there was a way to modify the headers of MP4's - then we would have gone down that route instead - but unfortunately, the format is poor in relation to the flexibility of MKV.

I believe Dave ( @Cheesegeezer) has decided to move the conversion function to an isolated Plugin (I'm not particularly involved with that side of the plugin being honest) - so the users consciously have to install and run it.

I'd be interested to see how the Emby conversation process works with DV - does that do anything special as that allows you to save to MKV, I presume it doesn't tonemap  ...  ?

 

Edited by rbjtech
  • Like 1
Link to comment
Share on other sites

Cheesegeezer
9 hours ago, softworkz said:

That's why I ask you to be careful, avoid conversions unless really necessary and don't encourage others to do so.

It is Emby's very job to handle all of your media files,

  • no matter which format or origin
  • in the best possible way
  • for all kinds of playback or other target situations.

 

Very good reply Fella. 
so if its such a bad idea why does Emby offer a converter for files? What does emby use to convert the files? FFMPEG? 
 

as Rich says this is a tool for those that are interested and a conscious decision to install and use it.  It has been completely removed from this plugin MediaInfo Plugin now.
 

This isn’t a tool that should be taken lightly and not just thrown together. I might not even release it if I’m not 100% happy and that is something I can’t say at the moment. Either way its a great learning project for me. So regardless of your comments, i plan to continue to complete this or get to a stage where it’s not worthy of release. 
 

cheers

  • Like 1
Link to comment
Share on other sites

 

1 hour ago, Cheesegeezer said:

This isn’t a tool that should be taken lightly and not just thrown together. I might not even release it if I’m not 100% happy and that is something I can’t say at the moment. Either way its a great learning project for me. So regardless of your comments, i plan to continue to complete this or get to a stage where it’s not worthy of release. 

What you are doing, developing, learning and even publishing as a plugin is all fine.
The one bit I responded to was the idea of converting files to MKV due to having more metadata capabilities.

But my primary scope is often - like here - the takeaway for other readers, which would have been like "conversions are fine and easy and hey yea - good idea, I will start to convert all my media to MKV, tomorrow".
I thought it would be clear that it's not directly targeted at you guys (and 10 minutes later I even added a note about it - in case you missed it..)

1 hour ago, rbjtech said:

I'd be interested to see how the Emby conversation process works with DV - does that do anything special

1 hour ago, Cheesegeezer said:

so if its such a bad idea why does Emby offer a converter for files? What does emby use to convert the files? FFMPEG? 

 

Good question, simple answer: I think it shouldn't offer/advertise it like that. Because this is in no way a professional and reliable implementation for bulk file conversion.
Each time I see a user posting something like: "I will convert all of my library to HEVC using the Emby conversion feature to save storage space", this is giving me an "Oh No moment".

So, let me explain what this feature is and what it isn't (or shouldn't be considered neither advertised to be): The origin of this is download and synchronization of media to client devices (primarily mobile devices). And when we think about one of the things where Emby is really good at, then that is the adaption and ability to play back any media on any device.
The next step from there is just logical and makes a lot of sense: When Emby "knows" how to treat media in order to make it work on certain clients, why use that capability just for playback? There are cases and reasons where you want to have files physically on your Emby client, so you can even watch offline. Yet, you might not want or need an original 50 GB 4k source file for watching on a phone display, or clients might not be able to play a certain file.

The solution for that was to employ the same logic that Emby uses for playback, in order to convert a media file from your library specifically for a certain target device, so it can be downloaded or auto-synchronized to the device.
=> This is a great feature which makes a lot of sense

A next step was to say: Well, the conversation is useful because it allows to direct play files on a device as it doesn't need live transcoding due to the pre-conversion, but you might want the pre-conversion without to download all of those pre-converted files to clients. This caused the feature to be extended in a way that you can do conversions at the server without downloading to a client. This reasonable as well, but one thing needed to be given up for this, which is the conversion being made for a specific target device. So - a kind of "generic mobile device" profile was introduced which you can choose for the conversion. But "generic" also means that it is no longer really "safe" to work for playback at a certain mobile client.
At a similar time, the "versions" feature was introduced which allows to have multiple versions of the same media file, and offers selection between those versions in the clients. 
=> the versions feature itself is a great feature as well, it can be used for multiple purposes (e.g. HDR/nonHDR, rated/unrated, studio/directors cut)

But that's the way how conversions are ending up as well: as alternate versions. For the original idea of having client-specific pre-converted files at the server, it would have been required to have the server auto-select the most suitable file to use. That part has not been completed and it would even be somewhat difficult due to the versions feature being a multi-purpose feature and not just used for having different pre-transcoded versions.
=> That's probably still useful for many users like it is, you just need to manually select the "right" version (and otherwise, Emby will still be live-transcoding the selected version in a way that it will work.

The final step is what I consider really problematic. Emby's capability for transcoding for a specific device is presented as a generic conversion feature, even though it's "just" the "transcode for a specific device" implementation. Emby is quite good, but it is not free from errors. Sometimes, playback doesn't work well in cases, but then it can be fixed or worked around, by treating the source file in a different way - as long as these would still exist...
=> The conversion feature is not suitable for bulk converting your library, and what's really unfortunate is the option to replace the original files after conversion as this suggests the conversion would be safe and reliable enough to do so. Which it isn't.

Link to comment
Share on other sites

Cheesegeezer

I really think you should start another discussion topic @softworkz if you wish to continue this.  

All i can really see here...... from the start of the Feature Request Topic a while ago which how it this plugin was born, and even here is an outright opposition to everything that is being done.

Although your justifications may make you feel better, you are completely contradicting your initial statements regarding why it's SUCH A BAD idea to convert anything.  So what you are saying is converting media so that emby know how to treat is... is ok to convert, because that's better, than someone preferring their media in mkv because that's how they like their media and may use other tools to insert chapters and edit other info internally within the Mkv.

That's all i'm saying in this thread... we can go to pm if you really feel the need to write a novel on such a trivial plugin.  As it stands, this MKVConvert Plugin will never make it to the store. or even go up as a Tool in the forums.  Completely seperate from MediaInfo and never it made it out.

image.jpeg.508cc10cd37309faa827411918118fa5.jpeg

Edited by Cheesegeezer
Link to comment
Share on other sites

3 minutes ago, Cheesegeezer said:

Although your justifications may make you feel better, you are completely contradicting your initial statements regarding why it's SUCH A BAD idea to convert anything.

Where's the contradiction? I say that you also should not use Emby's conversion feature to convert all your media containers.
(at large scale, replacing the original files).

Link to comment
Share on other sites

Cheesegeezer
1 minute ago, softworkz said:

Where's the contradiction? I say that you also should not use Emby's conversion feature to convert all your media containers.
(at large scale, replacing the original files).

So it wasn't ever design to be a fire and forget plugin.

image.thumb.png.393b9a129c710a7865bbcb7c9c152568.png

image.thumb.png.fa609d3464536b66c9c267f02385c1c8.png

Link to comment
Share on other sites

MagicDoubleM

I understand the concerns from a developer's perspective, I can imagine there have been a lot of headaches caused by messed up files. Totally agree about being cautious about conversations. But the use case here isn't that complicated and proven to work in many cases. You also have to take in consideration that not everyone's priority is to preserve files in their original form. As long as it's playing fine, it's fine. Most of these things are replaceable or will be upgraded at some point anyway. So from a practical standpoint, I'm not panicking when I see the feature here, especially when there's that backup feature too.

I'm following digital video since it's birth, have been working with codecs and containers from the very beginning, modded/coded my own tools for special scenarios. So I can imagine what you're dealing with and why you panic, but I also see how good tools like the mkvtoolset have become.

 

 

Edited by MagicDoubleM
grammar
  • Agree 1
Link to comment
Share on other sites

As it seems that some of my points still haven't been understood well enough:

  • I am not "panicking"
  • Again: what I stated were general concerns and not meant to discredit @Cheesegeezer's great plugin contributions in any way!
  • Conversion plugins are totally fine and I don't mind any such plugins to be added to the catalog
    Just make sure that
    • You don't create the impression that such conversions are safe or guaranteed to be lossless
    • If possible, please don't offer an option to automatically delete the original files
  • Like 1
Link to comment
Share on other sites

MagicDoubleM
58 minutes ago, softworkz said:

As it seems that some of my points still haven't been understood well enough:

  • I am not "panicking"
  • Again: what I stated were general concerns and not meant to discredit @Cheesegeezer's great plugin contributions in any way!
  • Conversion plugins are totally fine and I don't mind any such plugins to be added to the catalog
    Just make sure that
    • You don't create the impression that such conversions are safe or guaranteed to be lossless
    • If possible, please don't offer an option to automatically delete the original files

All well understood and agreed to.

“Panicking” was just a little exaggeration, meant to be funny. But yeah, humor often doesn't work that well in written form on forums.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...