'Re: [datatype-dev] Re: [Porting-android] CR:Changes to fix [Bug 9914]'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       helix-datatype-dev
Subject:    Re: [datatype-dev] Re: [Porting-android] CR:Changes to fix [Bug 9914]
From:       "Varun Kathuria" <vkathuria () real ! com>
Date:       2009-12-23 6:24:27
Message-ID: 36D6199E7FAE40A9AB38D59C225493EB () abc
[Download RAW message or body]

Hi Eric,

I have reverted back the fix in HEAD for now. In this case it is already a 
scanning 32K bytes of data & giving bitrate near to avg. bitrate. So i think 
it is already a longer time fix.

Thanks
Varun Kathuria

----- Original Message ----- 
From: "Eric Hyche" <ehyche@real.com>
To: "Jamie Gordon" <jgordon@real.com>; <datatype-dev@helixcommunity.org>
Cc: <vkathuria@real.com>
Sent: Wednesday, December 23, 2009 2:43 AM
Subject: RE: [datatype-dev] Re: [Porting-android] CR:Changes to fix [Bug 
9914] the duration a particular mp3 file is wrong

This is not really a problem during playback. During playback, we 
continually update the average bitrate and re-adjust our estimate of the 
duration.

This problem is occurring when we are scanning media for import to the media 
library. In this case, we only retrieve file header and stream header from 
the .mp3 file format and we don't actually deliver any packets.

So in this case, since import time is not that critical, then maybe we may 
want to modify the .mp3 file format to detect this situation (when it is 
being used just to collect meta-data) and go ahead and scan the full file in 
this case.

Varun: the fix you described is fine for now on the client branches (but not 
on the HEAD). But we probably want to make the change I've described above 
for a longer-term fix.

Eric

Eric Hyche
Principal Engineer, RealNetworks
ehyche@real.com
________________________________________
From: Jamie Gordon
Sent: Tuesday, December 22, 2009 3:03 PM
To: Eric Hyche
Cc: vkathuria@real.com
Subject: Re: [datatype-dev] Re: [Porting-android] CR:Changes to fix [Bug 
9914] the duration a particular mp3 file is wrong

On 12/22/2009 11:41 AM, Eric Hyche wrote:
> Thanks Jamie. So apparently this bug is complaining about the fact
> that we underestimate the VBR bitrate over the first 64k bytes, and
> therefore overestimate the duration of the file. I think this is in
> the "mediascanner" part of the Netbook code, where it uses dtdriver
> to get meta-data about the file.
>
I think you mean the other way around - for the content in question we
overestimate the bitrate and therefore underestimate the duration.

> Given this, the only things I know to do are:
>
> - just scan more than 64k to get a better estimate; or - completely
> scan .mp3 VBR files to find the exact duration; - just live with this
> relatively minor bug
>
Yeah, the issue with scanning further is of course the excessive
start-up time, especially if you try to scan the whole file and it is
really long! Is it really scanning 64k now? If so, then I would imagine
the 10% adjustment is way too big. Maybe it would be better to just skip
the first N frames (maybe 10? 20?) to ignore opening frames, and then
64KB, or maybe a minimum time period, is wide enough to get a pretty
good average.

Or, maybe adjust the bitrate for "AvgBitRate" but use the unmodified
average to calculate the duration, so we would be erring on the side of
overestimating duration rather than underestimating.

-Jamie

> Eric
>
> Eric Hyche Principal Engineer, RealNetworks ehyche@real.com
> ________________________________________ From: Jamie Gordon Sent:
> Tuesday, December 22, 2009 2:17 PM To: Eric Hyche Cc: Varun Kathuria;
> porting-android@helixcommunity.org; datatype-dev@helixcommunity.org
> Subject: Re: [datatype-dev] Re: [Porting-android] CR:Changes to fix
> [Bug 9914] the duration a particular mp3 file is wrong
>
> The 10% is addition is there because when there is no header, the
> bitrate has to be estimated based on the first N frames. Since the
> first several frames are typically lower bitrate than the average
> (due to most audio files beginning with silence, etc.), simply
> averaging them tends to underestimate. Since underestimating has
> worse potential outcome than overestimating, the base average of the
> first N frames is adjusted upward.
>
> On 12/22/2009 9:07 AM, Eric Hyche wrote:
>> I looked through CVS annotate to try to get an idea of why the
>> adding of 10% to the calculcated VBR bitrate was there, but
>> couldn't find anything. So therefore, this change looks OK to me.
>>
>> Eric
>>
>> On Dec 22, 2009, at 6:58 AM, Varun Kathuria wrote:
>>
>>> Synopsis: Changes to fix [Bug 9914] the duration a particular mp3
>>> file is wrong Overview:
>>>
>>> When we play mp3 vbr file without xing header then we are getting
>>> wrong duration. It is because we are calculating wrong bitrate.
>>> In sample mp3 vbr file, we get the filebitrate as 126.2 kbps and
>>> then we add 126/10 i.e 12(approx) in that & get 138 kbps bitrate
>>> which is wrong. So file of 4:58 sec gives wrong duration as 4:30
>>> sec. Fixed the issue & now we are getting right duration.
>>>
>>> Files Added: None
>>>
>>> Files Modified: /cvsroot/datatype/mp3/fileformat/mp3ff.cpp Image
>>> Size and Heap Use impact (Client -Only): None.
>>>
>>> Platforms and Profiles Affected: None
>>>
>>> Distribution Libraries Affected: None
>>>
>>> Distribution library impact and planned action: None
>>>
>>> Platforms and Profiles Build Verified: BIF branch
>>> ->hxclient_3_6_1_atlas_restricted Target(s)      ->android_all
>>> Profile          ->helix-client-android-full SYSTEM_ID
>>> ->android-donut-arm-qsd_8x50
>>>
>>> Branch atlas310, atlas361,head, 401brizo
>>>
>>> Files Attached: diff_9914.txt
>>>
>>> Thanks & Regards, Varun Kathuria <diff_9914.txt><ATT00001..txt>
>> Eric Hyche (ehyche@real.com) Principal Engineer RealNetworks, Inc.
>>
>>
>>
>> _______________________________________________ Datatype-dev
>> mailing list Datatype-dev@helixcommunity.org
>> http://lists.helixcommunity.org/mailman/listinfo/datatype-dev= 

_______________________________________________
Datatype-dev mailing list
Datatype-dev@helixcommunity.org
http://lists.helixcommunity.org/mailman/listinfo/datatype-dev
[prev in list] [next in list] [prev in thread] [next in thread] 