I'm still fighting against the avdec_h264 latency problem.
The pipeline (which I translated into C code) on my receiver is:
gst-launch-1.0 -v souphttpsrc location=http://127.0.0.1:8080/stream.ts ! tsdemux name=demuxer demuxer. ! h264parse ! avdec_h264 ! autovideosink
In gstavviddec.c the following lines reduce the latency if the upstream is live:
{
GstQuery *query;
gboolean is_live;
if (ffmpegdec->max_threads == 0) {
if (!(oclass->in_plugin->capabilities & CODEC_CAP_AUTO_THREADS))
ffmpegdec->context->thread_count = gst_ffmpeg_auto_max_threads ();
else
ffmpegdec->context->thread_count = 0;
} else
ffmpegdec->context->thread_count = ffmpegdec->max_threads;
query = gst_query_new_latency ();
is_live = FALSE;
/* Check if upstream is live. If it isn't we can enable frame based
* threading, which is adding latency */
if (gst_pad_peer_query (GST_VIDEO_DECODER_SINK_PAD (ffmpegdec), query)) {
gst_query_parse_latency (query, &is_live, NULL, NULL);
}
gst_query_unref (query);
if (is_live)
ffmpegdec->context->thread_type = FF_THREAD_SLICE;
else
ffmpegdec->context->thread_type = FF_THREAD_SLICE | FF_THREAD_FRAME;
}
If I set the is-live property ( g_object_set (G_OBJECT (souphttpsource), "location", argv[1], "is-live", TRUE, NULL); ) then the decoder's latency is reduced, according to the lines above,
BUT some latency is added on the souphttpsrc element.
How can I avoid that?
For now, the only solution I have is to HACK the code of gstavviddec.c and force ffmpegdec->context->thread_type = FF_THREAD_SLICE also in the case that is-live == FALSE (with the consequence that I don't get latency neither on the souphttpsrc neither on the avdec_h264 element)
It seems to me something that should be fixed in the library, though...
Locked
