[FFmpeg-user] Measuring received stream quality
Miguel Matos
razielukain at gmail.com
Fri Feb 8 17:24:56 CET 2013
Hi Carl,
On 7 Feb 2013, at 17:55, Carl Eugen Hoyos wrote:
> Miguel Matos <razielukain <at> gmail.com> writes:
>
>> The log produced when the stream received is not 'perfect'
>> contains a bunch of errors like "end mismatch left=4677 147B52"
>> and "concealing 520 DC, 520 AC, 520 MV errors in P frame".
>>
>> I would like some pointers or explanation on the meaning of
>> these errors, namely what they semantically mean and what's
>> behind values like 520 DC and so on.
>
> I can only tell you that MV probably stands for motion vector.
>
>> Ideally, I would like to have some kind of measurement of the
>> quality of the received stream and answer some questions like:
>> - does no errors reported imply the stream was played crystal
>> clear ?
>
> Please define "crystal clear".
A stream that played perfectly for instance without packet losses and/or late packets.
In short, the equivalent of playing from a local file.
>
>> - is it possible to create a mapping of the errors/amount of
>> errors to a better metric like the number of
>> unplayable/unviewable frames ?
>
> The number should be 0 in nearly all cases because FFmpeg by
> default uses error concealment.
> (I believe you get a specific error if a frame gets completely
> lost.)
I see.
I'll do some more tests to check if that's the case.
>
>
>> Note that visual inspection of the video does not work
>> because we need some quantifiable metric, just a 'looks good'
>> is not enough.
>
> I don't think what you want is currently implemented in FFmpeg,
> but I am not completely sure that it is possible in general
> (in a way that actually makes sense).
>
> Your transport layer should easily allow to tell you about lost
> information though.
Yes, the thing is that we are precisely tinkering with the transport layer, lost packets are unlikely, but late packets may happen.
We need some kind of metric for the video quality so that we are able to adjust the parameters at the transport level.
Thanks for the feedback.
Regards,
Miguel Matos
>
> Carl Eugen
>
> _______________________________________________
> ffmpeg-user mailing list
> ffmpeg-user at ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-user
More information about the ffmpeg-user
mailing list