mirror of
https://gitlab.freedesktop.org/gstreamer/gstreamer.git
synced 2024-12-25 01:30:38 +00:00
54482a54d8
The new property "output-order" can be set to either "display" order which is the default where frames will be outputting in display order, or "decoded-order" which will be outputting the frames in decoded order. The "decoded order" output is generally useful for debugging. But there are few customers who use it for low-latency streaming. For eg if the customer already knows that the stream doesn't have b-frames (which means no algorithm requires for display order calculation), then they can use "decoded-order" output to skip some of the DPB logic to avoid the frame accumulation at start-up. The root cause of the above issue is a bit of unclarity in h264 spec + lazy implementation of many H264 encoders; This is well handled in gstreamer-vaapi using "low-latency" property: https://bugzilla.gnome.org/show_bug.cgi?id=762509 https://bugzilla.gnome.org/show_bug.cgi?id=795783 |
||
|---|---|---|
| .. | ||
| acmenc | ||
| acmmp3dec | ||
| androidmedia | ||
| applemedia | ||
| bluez | ||
| d3dvideosink | ||
| decklink | ||
| directsound | ||
| dshowdecwrapper | ||
| dshowsrcwrapper | ||
| dshowvideosink | ||
| dvb | ||
| fbdev | ||
| ipcpipeline | ||
| kms | ||
| msdk | ||
| nvdec | ||
| nvenc | ||
| opensles | ||
| shm | ||
| tinyalsa | ||
| uvch264 | ||
| vcd | ||
| vdpau | ||
| wasapi | ||
| winks | ||
| winscreencap | ||
| Makefile.am | ||
| meson.build | ||