Здравствуйте, Conductor, Вы писали:


S>>Правда, автор решения пишет, что работает не всегда -- https://stackoverflow.com/q/68024094/241446
S>>Тут еще есть обсуждение.
S>>По итогу, все переходят на splitmuxsrc, хотя мне concat нравится больше.
C>В первом случае ("gst-launch-1.0 concat name=c ! filesink location=result.mp4 filesrc location=1.mp4 ! c. filesrc location=2.mp4 ! c.") он тебе сделал ровно то, что ты просил — объединил два файла как файлы, а не их содержимое (не потоки), и ему было абсолютно пофигу, что у них внутри. С тем же успехом можно было (вообще без gstreamer'а) выделить элементарный буфер размером в сумму размеров исходных файлов, и скопировать как есть в первую часть данные первого файла, а во вторую — второго. Эффект был бы тот же самый — воспроизведение доходит до конца данных первого файла и завершает работу.
C>Ведь в твоей же ссылке https://coaxion.net/blog/2014/08/concatenate-multiple-streams-gaplessly-with-gstreamer явно написано:
C>

C># Basically: $ cat file1 file2 > both
C>gst-launch-1.0 concat name=c ! filesink location=both filesrc location=file1 ! c. filesrc location=file2 ! c.

Видел, вот я и подумал "ого, как просто!", а дальше умный gst вывезет что речь идет о 2х mp4 файлах. Ан нет.

C>А во втором случае объединяется уже содержимое — ты же видишь: demux + parse + mux.

Уловил, благодарю.

Здравствуйте, Conductor, Вы писали:


S>>Правда, автор решения пишет, что работает не всегда -- https://stackoverflow.com/q/68024094/241446
S>>Тут еще есть обсуждение.
S>>По итогу, все переходят на splitmuxsrc, хотя мне concat нравится больше.
C>В первом случае ("gst-launch-1.0 concat name=c ! filesink location=result.mp4 filesrc location=1.mp4 ! c. filesrc location=2.mp4 ! c.") он тебе сделал ровно то, что ты просил — объединил два файла как файлы, а не их содержимое (не потоки), и ему было абсолютно пофигу, что у них внутри. С тем же успехом можно было (вообще без gstreamer'а) выделить элементарный буфер размером в сумму размеров исходных файлов, и скопировать как есть в первую часть данные первого файла, а во вторую — второго. Эффект был бы тот же самый — воспроизведение доходит до конца данных первого файла и завершает работу.
C>Ведь в твоей же ссылке https://coaxion.net/blog/2014/08/concatenate-multiple-streams-gaplessly-with-gstreamer явно написано:
C>

C># Basically: $ cat file1 file2 > both
C>gst-launch-1.0 concat name=c ! filesink location=both filesrc location=file1 ! c. filesrc location=file2 ! c.

Видел, вот я и подумал "ого, как просто!", а дальше умный gst вывезет что речь идет о 2х mp4 файлах. Ан нет.

C>А во втором случае объединяется уже содержимое — ты же видишь: demux + parse + mux.

Уловил, благодарю. Пока, увы, слабо ориентируюсь.

Еще вопрос в догонку -- попытался переиспользовать вот этот пайплайн:

gst-launch-1.0 concat name=c ! queue ! m.video_0 qtmux name=m ! filesink location=result.mp4 filesrc location=1.mp4 ! qtdemux ! h264parse ! c. filesrc location=2.mp4 ! qtdemux ! h264parse ! c.

все делаю по феншую -- 1) присваиваю всем location 2) pipeline.setstate(playing) 3)жду через шину EOS! Error (блокирующий вызов) 4) далее pipeline.setstate(ready) и pipeline.setstate(null);

и по кругу с другими файлами -- ломается, qtdemux not-linked, т.е. там pad'ы что ли как-то динамически появляются. В общем,
я этот вопрос еще поисследую, но меня интересуте другой вопрос:
а имеет ли смысл pipeline'ы переиспользовать или может проще новый создавать каждый раз? Не проводили эксперименты,
есть мнение на этот счет? Может, с конкретно этим пайплайном (см. выше), плюнуть и каждый раз занового его создавать?