After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 615623 - Append support in wavenc
Append support in wavenc
Status: RESOLVED WONTFIX
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.25
Other All
: Normal enhancement
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2010-04-13 08:49 UTC by Kunal Sinha
Modified: 2011-07-27 10:17 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kunal Sinha 2010-04-13 08:49:39 UTC
wavenc element should be able to support append mode operation. In certain use cases, it is desirable to append the newly encoded data to an existing file.

The expected behavior of wavenc is append mode is as follows:
1)	Restrict duplicate header inclusions (middle of the encoded data stream).
2)	Update the chunk size and other relevant fields in the main header (considering the newly encoded and previously existing file data).

Thanks,
Kunal
Comment 1 Stefan Sauer (gstreamer, gtkdoc dev) 2010-04-15 10:37:01 UTC
None of the muxers support append right now. This is quite normal, as they don't know about where the data is written or sent.

There is no design for supporting that usecase in gstreamer yet at all. Feel free to study the existing muxers and demuxer and propose how it could be done.
Comment 2 Sebastian Dröge (slomo) 2011-05-24 13:00:18 UTC
Anything going to happen here?
Comment 3 Stefan Sauer (gstreamer, gtkdoc dev) 2011-05-24 15:32:57 UTC
Sinha, what use-cases do you have in mind? Some application might be able to just pause the recording and continue the file. Appending to an existing file brings some constraints. E.g. would the muxer need to check the file and constrain the caps to the format in the file. Maybe the whole thing can be done with a bin, filesrc ! demuxer, checking the caps, setting them on a capsfilter before the muxer and using filesink with append=true.
Comment 4 Kunal Sinha 2011-06-03 09:39:55 UTC
I think the two cases mentioned above needs to be handled essentially.

1) Pausing of pipeline should allow normal resume operation.
2) Constraining of the caps to format of the file needs to be handled.
3) If the file is altogether a new file, append=true needs to be overlooked as we need to dump the headers too.


Thanks,
Kunal
Comment 5 Stefan Sauer (gstreamer, gtkdoc dev) 2011-06-03 10:28:57 UTC
(In reply to comment #4)
> I think the two cases mentioned above needs to be handled essentially.
> 
> 1) Pausing of pipeline should allow normal resume operation.

That should work already (GST_STATE_PAUSED).

> 2) Constraining of the caps to format of the file needs to be handled.
> 3) If the file is altogether a new file, append=true needs to be overlooked as
> we need to dump the headers too.
> 
> 
> Thanks,
> Kunal

Kunal, I meant to ask for what kind of application would you need it?
Comment 6 Tim-Philipp Müller 2011-06-03 10:45:00 UTC
I think this is outside of scope for wavenc.

It's up to you to ensure a contiguous input stream of whatever format, using e.g. gnonlin or input-selectors or whatever.

If the format changes mid-stream, just writing a new wav header and continuing to write into the same file seems quite wrong to me. Is this supposed to be officially supported? (does windows media player play such files?)
Comment 7 Akhil Laddha 2011-07-15 08:05:57 UTC
Kunal, can you please respond to comment#6 ?
Comment 8 Kunal Sinha 2011-07-27 06:55:52 UTC
I think format changes mid-stream cannot be handled in case of wav as in case of amr etc. The encoding is configured for a pre-defined set of bitrate and appending that file on those changes cannot be catered by our wavenc.

I think this should be out of scope for wavenc.
Comment 9 Tim-Philipp Müller 2011-07-27 10:17:24 UTC
> I think this should be out of scope for wavenc.

Ok, will close as WONTFIX then, thanks.