Low-quality output.

[vaibhavpandeyvpz]

I was trying out this library but to my surprise, it decreases the video quality with default configuration. I did not specify any change to output format and simply wrote a pass-through task to test and the output video is highly pixelated.

The code I used to run the transcoder is as follows:

val mt = MediaTransformer(context)
mt.transform(
    UUID.randomUUID().toString(),
    Uri.parse(input),
    output,
    null,
    null,
    listener,
    MediaTransformer.GRANULARITY_NONE,
    null)

Is there anything I am missing? The code in demo app is split just too much to understand easily.

[izzytwosheds]

your input looks ok. I would not recommend using GRANULARITY_NONE, though - you will get too many callbacks. Use GRANULARITY_DEFAULT instead, if you are updating UI.

Low quality output should not be happening, that sounds like a bug. What is the input file parameters? number of tracks, bitrates, resolution, etc.

[vaibhavpandeyvpz]

I tried GRANULARITY_DEFAULT too but nothing changed. Comparing the source file and the transcoded file, I noticed that original had a bitrate of ~1800 however the transcoded file got a bitrate of ~320.

[vaibhavpandeyvpz]

@izzytwosheds I need you to kindly shed some light on it (if you got time) about why this would be happening?

[izzytwosheds]

GRANULARITY_DEFAULT does not affect output size, it just significantly reduces the number of times TransformationListener.onProgress is called. I ran a smoke test on my end, bitrate estimation logic seems to be working correctly, but the bitrate of target video is half the bitrate requested from the encoder. I am investigating that, will keep you posted.

[vaibhavpandeyvpz]

OK, great. I will be waiting for you. Thanks for your time and effort you are putting into this to maintain.

Sent from my iPhone

On 21-Aug-2020, at 7:27 PM, Izzat Bahadirov notifications@github.com wrote:

 GRANULARITY_DEFAULT does not affect output size, it just significantly reduces the number of times TransformationListener.onProgress is called. I ran a smoke test on my end, bitrate estimation logic seems to be working correctly, but the bitrate of target video is half the bitrate requested from the encoder. I am investigating that, will keep you posted.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[vaibhavpandeyvpz]

Any updates? @izzytwosheds

[izzytwosheds]

I recently pushed an update to master which picks highest available profile, which should help with quality. It is not yet released to bintray, though. Can you try transcoding your video using latest master and let me know if this fixed your problem?

[izzytwosheds]

LiTr 1.4.0 is released which has the util method that should help with quality by querying for highest supported profile. Try it out, let me know if it helped.