Serviio

It appears that between v0.6.0.1 and v0.6.1 the transcoding behavior changed a bit. With v0.6.0.1 when you put a maxVBitrate attribute on it didn't appear to include the -sameq switch on the generated ffmpeg command line. With v0.6.1 it does. This is causing me a problem with transcoding video from a Minolta Dimage Z3. With -sameq the video quality of the file ends up being very degraded but without it the video is fine. With -sameq the bit rate goes from 479 to 614. Without it the bit rate goes from 3826 to 4353. The size of the output file grows about 10 times when -sameq is not specified.

Does anyone know if this change in intentional. If so, is there a way to get the -sameq switch to be left off the ffmpeg command line as before?

Thanks,

digitalhack

Below are the configuration file extract and the two different ffmpeg commands that are generated.

From profile.xml:

<!-- transcode added to support video from Minolta Dimage -->
<Video targetContainer="mpegts" targetACodec="ac3" targetVCodec="mpeg2video" aSamplerate="44100" maxVBitrate="5000">
<Matches container="mp4" vCodec="mjpeg" />
</Video>

From v0.6.0.1 log:

2012-01-07 22:41:34,103 DEBUG [ProcessExecutor] Starting C:\Program Files (x86)\Serviio\bin\\..\lib/ffmpeg.exe -i C:\ServiioLibrary\Video\chesapeake classicalgas.MOV -y -threads 1 -vcodec mpeg2video -b 5000k -maxrate 5000k -bufsize 5097k -r 30 -g 15 -copyts -acodec ac3 -ab 128k -ar 44100 -ac 1 -map 0:0 -map 0:1 -sn -f mpegts C:\Windows\TEMP\Serviio\transcoding-temp-34-MPEG2TS.stf

From v0.6.1 log:

2012-01-08 16:11:37,159 DEBUG [ProcessExecutor] Starting C:\Program Files (x86)\Serviio\bin\\..\lib/ffmpeg.exe -i C:\ServiioLibrary\Video\chesapeake classicalgas.MOV -y -threads 1 -async 1 -vcodec mpeg2video -sameq -b 5000k -maxrate 5000k -bufsize 5000k -r 30 -g 15 -copyts -acodec ac3 -ab 128k -ar 44100 -ac 1 -map 0:0 -map 0:1 -sn -f mpegts C:\Windows\TEMP\Serviio\transcoding-temp-34-MPEG2TS.stf

Below is the format of the source file according to ffmpeg:

Seems stream 0 codec frame rate differs from container frame rate: 600.00 (600/1) -> 30.00 (30/1)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'C:\ServiioLibrary\Video\chesapeake classicalgas.MOV':
Metadata:
creation_time : 2008-06-22 14:11:44 Duration: 00:01:31.90, start: 0.000000, bitrate: 8577 kb/s
Stream #0:0(eng): Video: mjpeg (jpeg / 0x6765706A), yuvj422p, 640x480, 8381kb/s, 30 fps, 30 tbr, 600 tbn, 600 tbc
Metadata:
creation_time : 2008-06-22 14:11:44
handler_name :
Stream #0:1(eng): Audio: pcm_s16be (twos / 0x736F7774), 7840 Hz, 1 channels, s16, 125 kb/s
Metadata:
creation_time : 2008-06-22 14:11:44
handler_name :

yes, it is intentional. without sameq it produced dodgy output quality-wise with maxrate. you can see the q parameter when transcoding goes to high numbers (like 30) which means the quality suffers (the lower the better). You should see that when using sameq the q value stays at 1 and only increases once the rate boundary is hit. I think this is the correct behaviour.

You can also disable sameq in the console (Generate best video quality on Transcoding tab), it'll use -qscale 3.0 instead of sameq, which will keep the q value at 3 - still produce decent quality but utilizing less CPU.

Thanks.

The behavior you describe makes sense but the desired end result isn't what is happens with these files. If you check out the attached file it is a log of two manual runs of ffmpeg. The first one has the -sameq and q is equal to 13. The second one doesn't have -sameq and q is mostly set to 2 with the occasional 1.6. The quality of the second file is much better than the first.

Another thing in the logs is that there are some error messages that appear in the conversions. The only one that looks like it is generated based on the serviio command line used for ffmpeg is that ffmpeg complains that -b is ambiguous. It needs to be either -b:a or -b:v. I think based on how it is being used it needs to be -b:v.

I think you're right. It looks like -b and -qscale/-sameq are mutually exclusive - I'll remove the -sameq parameter for the next patch version.

There is no reference to the "-sameq" option in the ffmpeg documentation.
You probably have to change to -b:v option to remove the ffmepg message :
"Please use -b:a or -b:v, -b is ambiguous"

and what about this message on log ?
"[mpeg2video @ 02bc7da0] impossible bitrate constraints, this will fail"

EDIT:libavcodec src:


EDIT2: it seems that when you use -maxrate option (with -bufsize option) like this : -maxrate 30000k -bufsize 30000k
it will transcode with a CBR, so is recommended to also add -minrate option equal to -maxrate option value.(to be confirmed)

For what it is worth...

I put together a small wrapper around ffmpeg. The wrapper drops the -sameq switch when -b was found and changes -b to -b:v. These changes solve the problems with the transcoded video. I plan to use this until the changes make it into a patch.

Thanks to all for the help,

digitalhack

I added the following line to ServiioService.exe.vmoptions:



serviio-ffmpeg.pl contains the following:

Thanks for that tips, I modify the perl script to include the "Aspect Ratio fixing" workaround:
I add another test like this on your script.

Not sure it was a good idea to remove -qscale/-sameq option, in fact when maxVBitrate is used on profile, ffmpeg command line used "-b:v", "maxrate=" and "bufsize=" options.
But for example, if you set maxVBitrate=10000, -b:v 10000k -maxrate=10000k, it seems that become a "Constant Video Bitrate" at 10Mbps stream not a "Clipped Video Bitrate" !!

Original file
I try with BigBuckBunny-DivXPlusHD.mkv sample file, with bitrateviewer => average 6Mbps with 21Mbps peak


Transcoded in mpeg2video :

with -sameq only => average 15Mbps with 64Mbps peak !!! not supported by devices


with -b:v 10000k -maxrate 10000k -bufsize 10000k => average 9Mbps with 18Mbps peak , looks like a constant bitrate video stream


with -sameq -b:v 17000k -maxrate 17000k -bufsize 17000k => average 11Mbps with 30Mbps peak, looks like a clipped bitrate video stream but still have high peak birate


Don't know what is the solution...

try to play with bufsize, I think that made some difference. It's more or less contant bitrate, yes. When FFmpeg works you can see the changing q attribute, the higher the more compression to fit into the max bitrate value.