[Android] Bump the tested hash to the latest one from today

Rafaël Carré funman at videolan.org
Tue Feb 5 16:37:39 CET 2013


Le 05/02/2013 14:06, Hugues FRUCHET a écrit :

>>> Is there a patch or an option to set in order  to disable the checks on lateness and let audio be rendered without any check ?
> 
> 
> 
>> No there's no such patch.
> 
>> I think you should increase the audio packets PTS if you're sending them
> 
>> to the output a while after decoding.
> 
> [HFR] I don't see how to do that, I don't know what is the ref time on the VLC point of view (I cannot be sure of the system time used by VLC). As far as I have seen in gstreamer for ex., the pre-roll phase is here to do this (get rid of initial config/setup phase of decoder).

On entry, i_pts should be set already as the desired presentation
timestamp and IIUC this pts should be copied to the block you are
outputting.

Audio packets are written to audio output immediately after that.

You can get current time with mdate() (in microseconds).

> 
> 
> 
>> Why do you need high latency in your decoder?
> 
> [HFR] I don't need audio latency, it's something I had to deal with, based on current implementation.
> 
> To summarize, I suppose that the decoders are assumed by VLC to be "0-delay" (or few delay), it's why I have reduced to a minimum
> 
> The latency, but this is not needed for Stagefright, so I am wondering why such difference.

Yes, decoded audio is written immediately after decoding in VLC.

> 
>>> 2)      A/V sync issues with video late
> 
>>> With some files, video is rendered completely out of sync regarding audio, video is late by some seconds and some video drops are observed.
> 
>>> I don't have fresh log to give on this exact issue I have faced some weeks ago, but I'll restart this activity this week, and I want to restart with a better basis
> 
>>> regarding VLC debug tips.
> 
>>> *Have you some patch or options to set in order to disable audio and let video be rendered as fast as it can ? This would allow to test the pure performance of video chain, including OMX decoder, YUV=>RGB conversion & display. With Android Gallery apk, I don't face perf issue and A/V is in sync
> 
> 
> 
> [HFR] I have redone measurements, problem I have is that FillBufferDone are there in average every 56 ms while 40ms expected (25fps H264 movie)

Hum we might have a problem here. I will try to have a look.

>> I do have a patch to test decoder performace, but that completely
> 
>> bypasses display/rendering. It's not very convenient as it disables
> 
>> audio/video output completely (it's not configurable at runtime so you
> 
>> have to use a custom patch).
> 
> [HFR] I think it could be usefull for me, my favorite Android utility is "Stagefright" in cmd line (adb shell stagefright --help), a utility which replaces the stagefright player by a limited player with no output and "decode in buffer as fast as possible" strategy. Then a perf figure is displayed allowing to know the unit perf of decoder, getting rid of video output.
> 
> Would be nice to have the same with VLC omx integration so I could know if my perf problem comes from OMX buffers handling for ex.

Could you come on IRC so we talk about this in real time?

>> I might be able to adapt it to add YUV->RGB conversion, I need to check.
> 
> [HFR] I have tested by disabling the YUV to RGB conversion in VLC (comment of nv12_rgb_neon in NV12_RGBA in yuv_rgb.c.
> 
> Only 6ms gained (50 ms instead 56ms for FillBufferDone period), so it's not the problem.

OK

>> BTW did you try the YV12 rendering option in advanced preferences? (It
> 
>> is broken on several devices but might work for you)
> 
> [HFR]I don't have "Advanced preferences" in preferences, I have "Advanced debugging" with SetLocale but I don't know how to use it.

Advanced debugging -> Force YV12 format

> 
> Anyway seems not YUV->RGB conversion issue.

Agree

>>> *For YUV=>RGB conversion, how can I know the performance (duration) ? is the neon optim enabled or not (trace ?)
> 
> 
> 
>> Performance is not checked atm but we could add some counters.
> 
>> NEON should be enabled, you can see it in logcat : look for "yuv_rgb_neon".
> 
> [HFR]OK
> 
> 
> 
>>> *When reading code, I cannot found the A/V sync mechanism I usually encounter in Stagefright/AwesomePlayer.cpp (or other players I have encountered in the past) which consist to take the audio clock (system clock if no audio) as reference and render the decoded video frames when the audio clock has elapsed based on the video frames timestamp. Have you some doc which explain this ?
> 
> 
> 
>> No there are no docs, the video output code was written by fenrir and
> 
>> he's not available to explain it.
> 
> 
> 
>> Video logic is all in src/video_output, and audio rendering
> 
>> synchronization logic is performed by audio_output_t->time_get
> 
> [HFR]OK, I'll have a look to this
> 
> [HFR]If I want to disable completely audio side of playback (skip audio samples at demuxing side for ex.), what is your recommendation ?

Add "--no-audio" to libvlc_new() arguments, or just use a sample without
audio (=


More information about the Android mailing list