Opened 10 years ago

Closed 9 years ago

#3060 closed enhancement (fixed)

Option to disable "index seek table" and "index table iirc" in NUT muxer

Reported by: MB Owned by:
Priority: wish Component: avformat
Version: git-master Keywords: nut
Cc: Blocked By:
Blocking: Reproduced by developer: no
Analyzed by developer: no

Description

I need to send both audio and video through pipes.

For example, to send ffmpeg output to decklink:

ffmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f nut - | bmdplay -f pipe:0

At present, nut is the only container that allows me to pass audio with no problems. Unfortunately, memory grows a lot while executing the previous cmd line and this prevents a 24/7 usage.

A mailing list user (Paul B Mahol) suggested that this issue could be solved by disabling "index seek table" and "index table iirc" on nut muxer.

thanks

Change History (4)

in reply to:  description ; comment:1 by Carl Eugen Hoyos, 10 years ago

Keywords: pipe removed
Priority: normalwish
Status: newopen
Version: unspecifiedgit-master

Replying to mbat:

ffmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f nut - | bmdplay -f pipe:0

At present, nut is the only container that allows me to pass audio with no problems.

Your request is probably valid but why don't you use a transport stream (a container invented for this purpose afaict) with low quantiser video and high bitrate audio? Is performance really a problem (but bandwidth not)?

in reply to:  1 ; comment:2 by MB, 10 years ago

Replying to cehoyos:


why don't you use a transport stream


If you mean:
fmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f mpegts - | bmdplay -f pipe:0
This does not work. Even with latest builds.

If you mean:
ffmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f mpegts udp://127.0.0.1:1400 and then read the stream with some tool.
This does not work. Even with latest builds (and VLC). And I can see a considerable cpu usage (20x compared with pipe solution).

If you mean:
ffmpeg -i anyvideo.mpg -vcodec libx264 [opts] -acodec libvo_aacenc [opts] -f mpegts udp://127.0.0.1:1400 and then read the stream with some tool.
This works. But:

  1. Decklink needs uncompressed frames. It is a non-sense decode->encode->decode again if I just need to decode once. Plus you have a quality degradation which is not always acceptable for this kind of hardware (A. who buys a decklink wants the maximum output quality, B. Sometimes you need to analyze SDI output with some instuments so you need the original decompressed frame).
  2. High cpu usage when you could use 2% cpu as a maximum.


Is performance really a problem (but bandwidth not)?


I'm not obsessed with optimization, but if you can do that with 2% of cpu, why doing it with 40%? Plus, using pipes, bandwidth is not a problem.

I hope I have been clear enough. Of course I may be wrong on some of my considerations, so let me know if something is not correct for you.

To summarize, my final goal is sending ffmpeg output to decklink decompressing frames just once (and with minimal resource usage). If nut muxer could disable index seek tables and iirc, the goal would be reached.

Thanks

in reply to:  2 comment:3 by Carl Eugen Hoyos, 10 years ago

Replying to mbat:

Replying to cehoyos:

why don't you use a transport stream with low quantiser video and high bitrate audio?

If you mean:
fmpeg -i anyvideo.mpg -vcodec rawvideo -acodec pcm_s16le -f mpegts - | bmdplay -f pipe:0

I meant:
$ ffmpeg -i anyvideo.mpg -vcodec mpeg2video -qscale 2 -mbd 2 -acodec ac3 -ab 664k -f mpegts

But I realize now you could just send the input mpeg stream.

comment:4 by Michael Niedermayer, 9 years ago

Resolution: fixed
Status: openclosed

FFmpeg supports "-write_index 0" since 82beb46e65e5f820b187355bf757725c22a59c45

Note: See TracTickets for help on using tickets.