Encoding format string

[amindfv at mailbox.org]

Hi Eslam - thank you very much for the information about GST_DEBUG_DUMP_DOT_DIR. I'd never used it before, and it's given me a ton of insight about what's going on (though unfortunately I still haven't fixed the issue).

A few things I notice from the pipeline, as rendered in the .dot files:

  - At some point in the pipeline, a GstVideoConvert element has a sink pad with format I420_10LE (good), but its source pad has format I420 (not good)
  - Later in the same pipeline, a GstVideoRate element has a sink pad with framerate 24/1, but source pad with framerate 30/1 (also not good). Later, in the GstEncodeBin, the framerate is converted back to 24/1.
  - In some .dot files, a GESSmartMixer (inside a NleOperation) downgrades the geometry from 4K to 1280x720 (definitely not good). Not sure what it means but the "interlace-mode: progressive" label also disappears.

This is after explicitly adding a framerate to my encoding profile, as in:

   ges-launch-1.0 [...] --format 'video/quicktime,variant=iso:video/x-raw(ANY),framerate=24/1,width=4096,height=2160->video/x-h264|element-properties,target-bitrate=200000'

As my deadline draws near, I'm starting to prioritize what's most urgent. For me, that's:

  - set bitrate <-- most important
  - preserve geometry
  - set framerate
  - set pixel format (I420_10LE vs. 1420)
  - encode as MP4/h264 <-- least important

Any help is, as always, much appreciated!

Thanks,
Tom



On Tue, Oct 25, 2022 at 11:31:20AM +0200, Eslam Ahmed via gstreamer-devel wrote:
> You are welcome :)
> Just a quick FYI, I have never used GES ever before but I think I might
> have an idea of what's happening.
> 
> Running something so simple as: ges-launch-1.0 +clip
> /home/avidbeam/Videos/Ped01-1.mp4 -o /home/avidbeam/Videos/render.mp4 gives
> "streaming stopped, reason not-negotiated"
> 
> We need to set the GST_DEBUG_DUMP_DOT_DIR environment variable to a valid
> directory path to understand the created pipeline so run again with:
> GST_DEBUG_DUMP_DOT_DIR=./ ges-launch-1.0 +clip
> /home/avidbeam/Videos/Ped01-1.mp4 -o /home/avidbeam/Videos/render.mp4
> 
> You should be able to see 5 files ending with the .dot extension, these are
> the graphs created by gstreamer. opening ges-launch-error.dot file (you can
> use xdot viewer on linux) I was able to see that gstreamer was using a gpu
> decoder (nvidia decoder) that has higher priority than your normal CPU
> decoder and thus producing frames on the GPU yet it was using the wrong
> color space converter (videoconvert) when it should have used
> (nvvideoconvert) that can deal with frames on the GPU. Blacklisting nvidia
> decoder might just solve the issue for me.
> 
> I suggest you do the same and figure out what's wrong in your pipeline, you
> might have a similar case. I have attached my ges-launch-error.dot for
> reference.
> 
> Good Luck!
> 
> Best Regards,
> Eslam Ahmed
> 
> 
> On Tue, Oct 25, 2022 at 10:52 AM amindfv at mailbox.org <amindfv at mailbox.org>
> wrote:
> 
> > Sure, thanks!
> >
> > Here's a basic example of what I've tried:
> >
> >     ges-launch-1.0 --track-types=video +clip /home/foo/bar0.mp4
> > inpoint=16.0 duration=2.0 +clip /home/foo/bar1.mp4 inpoint=15.0
> > duration=3.0 --outputuri file:///foo/bar/render.mp4 --format
> > 'video/quicktime:video/x-h264,variant=iso,width=4096,height=2160|target-bitrate=500000a'
> >
> > This and similar experiements result in "streaming stopped, reason
> > not-negotiated" errors.
> >
> > (I haven't even tried specifying pixel format; I've just hoped that it
> > would stay consistent throughout the pipeline)
> >
> > Thanks,
> > Tom
> >
> > On Tue, Oct 25, 2022 at 10:21:27AM +0200, Eslam Ahmed wrote:
> > > Can you share your pipeline?
> > >
> > > Best Regards,
> > > Eslam Ahmed
> > >
> > >
> > > On Tue, Oct 25, 2022 at 9:47 AM amindfv--- via gstreamer-devel <
> > > gstreamer-devel at lists.freedesktop.org> wrote:
> > >
> > > > Hello, can anyone help here? I'm working with quite a simple setup: all
> > > > clips have the same geometry, bitrate, fixed framerate, etc., and I
> > simply
> > > > want to render a file with matching specs (geometry, bitrate, and
> > notably
> > > > 10-bit color pixel format).
> > > >
> > > > I'm using `ges-launch` and all I need, as far as I know, is a
> > `--format`
> > > > string to specify this.
> > > >
> > > > Any help would be very appreciated.
> > > >
> > > > Thanks,
> > > > Tom
> > > >
> > > > On Fri, Oct 21, 2022 at 01:40:45PM -0700, amindfv--- via
> > gstreamer-devel
> > > > wrote:
> > > > > Running on very little sleep with a deadline looming, I find myself
> > > > unable to come up with a GstEncoding profile for `ges-launch-1.0` (a
> > task
> > > > that seems simple enough).
> > > > >
> > > > > I've got input sources that are 4096x2160 with a pixel format of
> > > > yuv420p10le; I'd like to preserve that as the output format (and make
> > sure
> > > > the pixel format isn't getting downgraded anywhere in the pipeline).
> > I'd
> > > > also like to make sure the bitrate stays at 200mb/s.
> > > > >
> > > > > I've tried things from this page (
> > > >
> > https://gstreamer.freedesktop.org/documentation/pbutils/encoding-profile.html?gi-language=c
> > ),
> > > > and come up with things like
> > > > >
> > > > >
> > > >
> > video/quicktime,variant=iso:video/x-h264,width=4096,height=2160|target-bitrate=200000
> > > > >
> > > > > (There's one video track, no audio)
> > > > >
> > > > > But I get errors from ges-launch like:
> > > > >
> > > > >     ERROR from element qtdemux27: Internal data stream error./>
> > > > >
> > > > >     Debugging info: ../gst/isomp4/qtdemux.c(6545): gst_qtdemux_loop
> > ():
> > > >
> > /GESPipeline:gespipeline0/GESTimeline:gestimeline0/GESVideoTrack:gesvideotrack0/NleComposition:video_nlecomposition0/GstBin:current-bin/NleSource:GESVideoUriSource:nlesource0/GstBin:videosrcbin/GstURIDecodeBin:uridecodebin0/GstDecodeBin:decodebin56/GstQTDemux:qtdemux27:
> > > > > streaming stopped, reason not-negotiated (-4)
> > > > >
> > > > >
> > > > > As I say, I'm on quite a deadline; any help would be very
> > appreciated!
> > > > >
> > > > > Thanks,
> > > > > Tom
> > > >
> >