The VideoLAN Forums

I tried to save streamed H264 to H264 file. Neither "open network stream/save to file" nor "Wizard" can save to H264 files. H264 streams out directly (without saving) works fine. Any clue?

Here is an example showing it doesn't work in saving H264 file:

From VLC -> "File" button
-> Wizard, check “Transcode/Save to file”, then Next
-> check “Select a stream”, click “Choose”
-> select “Network”, check “RTSP”, fill URL “rtsp://127.0.0.1/myh264.mp4”, click “OK”, then "Next"
-> check “Transcode video” and “Transcode audio”, choose “Dummy” for both audio and video, then "Next"
-> check "MP4"
-> choose the file directory/name to save, click “finish” to save to file.

The saved file is small and cannot be played back.

Use the options menu called "Stream output" instead. It can be found in the Open fie dialog under Advanced Options "Stream/Save" Settings button.

Assuming the source is h.264 with aac audio you can select MP4 for the encapsulation method and select the file target / destination. Don't forget to give the file name a .mp4 extension. Nothing else need be selected. If you want to watch the file while transcoding, select "Play locally" But you may want to check your Task Manager to be sure you have the CPU power to do this. Also if you open Messages before you start the process you can see any errors to troubleshoot any problems you encounter.

If you do run across problems check Messages while playing the file first to be sure the problem is not the source file.


Amendment to this post: H.264 does not copy into a MP4 container. It will copy into a MPEG-TS container but the quality and stability suffers. So the process can be accomplished as a transcode to a MP4 container.

I have no idea as to why I remember doing a copy action. Must be getting old.

Thanks for your suggestion! I tried exactly as you said, still doesn't work. The created H264 file is pretty small (1.13KB in size). It sames the saving stops very shortly after I started recording, so the CPU usage keeps lower than 7%.

Use the options menu called "Stream output" instead. It can be found in the Open fie dialog under Advanced Options "Stream/Save" Settings button.

Assuming the source is h.264 with aac audio you can select MP4 for the encapsulation method and select the file target / destination. Don't forget to give the file name a .mp4 extension. Nothing else need be selected. If you want to watch the file while transcoding, select "Play locally" But you may want to check your Task Manager to be sure you have the CPU power to do this. Also if you open Messages before you start the process you can see any errors to troubleshoot any problems you encounter.

If you do run across problems check Messages while playing the file first to be sure the problem is not the source file.

You can try the transcode process by checking the video and audio boxes and selecting h.264 for the video and mp4a for the audio the container is mp4 you must name the saved file anything.mp4

Out of curiosity what did messages say?
Exactly what is the source format?
Are you sure the source doesn't have problems?

Thanks for your suggestions, but it still doesn't work.

I checked my H264 file, should be a good one. I can playback, stream without saving, ...

Here is the message when I use 'Wizard' to setup saving to H264 file:

-------
[00000291] logger interface: VLC media player - version 0.8.5 Janus - (c) 1996-2
006 the VideoLAN team
[00000291] logger interface:
Warning: if you can't access the GUI anymore, open a command-line window, go to
the directory where you installed VLC and run "vlc -I wx"

[00000291] logger interface: using logger...
Sending request: OPTIONS rtsp://127.0.0.1/wseH264.mp4 RTSP/1.0
CSeq: 1
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received OPTIONS response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 1
Public: DESCRIBE, SETUP, TEARDOWN, PLAY, PAUSE, OPTIONS, ANNOUNCE


Sending request: DESCRIBE rtsp://127.0.0.1/wseH264.mp4 RTSP/1.0
CSeq: 2
Accept: application/sdp
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received DESCRIBE response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 2
Last-Modified: Tue, 20 Dec 2005 22:48:08 GMT
Cache-Control: must-revalidate
Content-length: 1403
Date: Thu, 11 May 2006 14:56:12 GMT
Expires: Thu, 11 May 2006 14:56:12 GMT
Content-Type: application/sdp
x-Accept-Retransmit: our-retransmit
Content-Base: rtsp://127.0.0.1/wseH264.mp4/
Content-Location: rtsp://127.0.0.1/wseH264.mp4/


Need to read 1403 extra bytes
Read 1403 extra bytes: v=0
o=- 2209248031 1135118888000 IN IP4 127.0.0.1
s=\wseH264.mp4
u=http://epox3.dgbt.crc.ca
e=admin@epox3.dgbt.crc.ca
c=IN IP4 0.0.0.0
t=0 0
t=0 0
a=mpeg4-iod:"data:application/mpeg4-iod;base64,AoIrAE///w/+/wOBNgABQJhkYXRhOmFwc
GxpY2F0aW9uL21wZWc0LW9kLWF1O2Jhc2U2NCxBVlFCS0FVZkF5UUF5UUFFRFNFUkFOak1BQWJHWUFBR
3htQUdFQUJFQUFGZmtBQUJYNUFnQUFBQUFBTUJLQUtmQXlRQVpRQUVEVUFWQUFNQUFBRGF3QUFBMnNBR
0VBQkVBQUJXSWdBQlg1QWdBQUFBQUFNPQQNAQUAAMgAAAAAAAAAAAYJAQAAAAAAAAAAA2kAAkBGZGF0Y
TphcHBsaWNhdGlvbi9tcGVnNC1iaWZzLWF1O2Jhc2U2NCx3QkFTZ1RBcUJXMG1FRUg4QUFBQi9BQUFCR
UtDS0NuNAQSAg0AACAAAAAAAAAAAAUDAABABgkBAAAAAAAAAAA="
a=range:npt:0-34.08688888
a=range:npt=0- 34.08689
a=control:*
m=video 0 RTP/AVP 96
b=AS:480
a=rtpmap:96 H264/90000
a=fmtp:96 profile-level-id=42E00D; sprop-parameter-sets=Z0LgDZWgsTsBEAAAPoAABhqG
DAAbGgDZauAAIA==,aM48gA==; parameter-sets=Z0LgDZWgsTsBEAAAPoAABhqGDAAbGgDZauAAIA
==,aM48gA==; packetization-mode=1
a=cliprect:0,0,144,176
a=framerate:25.00000000
a=mpeg4-esid:201
a=range:0-34.08688735
a=x-envivio-verid:000122C1
a=control:trackID=65335
a=range:npt=0- 33.96000
m=audio 0 RTP/AVP 97
b=AS:63
a=rtpmap:97 mpeg4-generic/22050/1
a=fmtp:97 profile-level-id=15; config=1388; streamtype=5; mode=AAC-hbr; SizeLeng
th=13; IndexLength=3; IndexDeltaLength=3
a=mpeg4-esid:101
a=range:0-34.08688735
a=x-envivio-verid:000122C1
a=control:trackID=65435
a=range:npt=0- 34.08689

Sending request: SETUP rtsp://127.0.0.1/wseH264.mp4/trackID=65335 RTSP/1.0
CSeq: 3
Transport: RTP/AVP;unicast;client_port=1520-1521
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received SETUP response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 3
Last-Modified: Tue, 20 Dec 2005 22:48:08 GMT
Cache-Control: must-revalidate
Session: 87308095203957;timeout=0
Date: Thu, 11 May 2006 14:56:12 GMT
Expires: Thu, 11 May 2006 14:56:12 GMT
Transport: RTP/AVP;unicast;client_port=1520-1521;source=127.0.0.1;server_port=69
72-6973;ssrc=9A066CD5


Sending request: SETUP rtsp://127.0.0.1/wseH264.mp4/trackID=65435 RTSP/1.0
CSeq: 4
Transport: RTP/AVP;unicast;client_port=1522-1523
Session: 87308095203957
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received SETUP response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 4
Session: 87308095203957;timeout=0
Last-Modified: Tue, 20 Dec 2005 22:48:08 GMT
Cache-Control: must-revalidate
Date: Thu, 11 May 2006 14:56:12 GMT
Expires: Thu, 11 May 2006 14:56:12 GMT
Transport: RTP/AVP;unicast;client_port=1522-1523;source=127.0.0.1;server_port=69
72-6973;ssrc=FC8B5BDC


Sending request: PLAY rtsp://127.0.0.1/wseH264.mp4 RTSP/1.0
CSeq: 5
Session: 87308095203957
Range: npt=0.000-
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received PLAY response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 5
Session: 87308095203957;timeout=0
Range: npt=0.00000-34.08600
RTP-Info: url=trackID=65335;seq=23696;rtptime=1411074037,url=trackID=65435;seq=2
0272;rtptime=2598892159


Sending request: TEARDOWN rtsp://127.0.0.1/wseH264.mp4 RTSP/1.0
CSeq: 6
Session: 87308095203957
User-Agent: VLC media player (LIVE555 Streaming Media v2006.03.16)


Received TEARDOWN response: RTSP/1.0 200 OK
Server: 4Sight/5.0 (Build=138; Platform=Windows)
Cseq: 6
Session: 87308095203957;timeout=0
Connection: Close


[00000284] main playlist: nothing to play
-------

Did you see the amendment to my earlier post?? IE h.264 can NOT be copied to a mp4 container without transcoding. I have no idea as to why I remember being able to copy it, but is doesn't work without transcoding.

But, Perhaps I am still not being direct enough! Don't use the Wizard! When you are having problems streaming, back up and separate streaming from transcoding by making a local transcode of a file to file and proving the result. Considering you appear to be receiving the stream and you say there is no problem. Perhaps it would be best to gain a sample h.264 and experiment with transcoding as this appears to be your problem.

H.264 encapsulated into MPEG-TS is poor quality and is not stable. H.264 can not be copied into a MP4 or MOV container without transcoding.

I will admit that I thought you were trying to send the stream and not receive the stream and save it. But when you have problems it is still better to separate the functions to see exactly what the problem is.

In this case, depending on the resolution of coarse, it would probably better to transcode into another format. If you want a QT compatible file choose mp4v, mp4a and mp4 for the encapsulation method. Be sure to name the file anything.mp4 and save it to a directory you can find.

Thanks DJ!

I did the transcoding, it didn't work.

Here is what I did:

In the "Transcodeing options", check 'video codec' and choose 'h264' with 'Bitrate' close to original video to be streamed.

Do the same thing for audio in the "Transcoding options".

Check 'MP4' in the "Encapsulation Method".

Click 'OK' to start streaming/transcoding...

If you have VLC installed on your PC, try 'rtsp://142.92.36.55/wseH264.mp4' to stream, then try to save it to a h264 file, since it doesn't work in here.

Thanks again!

Did you see the amendment to my earlier post?? IE h.264 can NOT be copied to a mp4 container without transcoding. I have no idea as to why I remember being able to copy it, but is doesn't work without transcoding.

But, Perhaps I am still not being direct enough! Don't use the Wizard! When you are having problems streaming, back up and separate streaming from transcoding by making a local transcode of a file to file and proving the result. Considering you appear to be receiving the stream and you say there is no problem. Perhaps it would be best to gain a sample h.264 and experiment with transcoding as this appears to be your problem.

H.264 encapsulated into MPEG-TS is poor quality and is not stable. H.264 can not be copied into a MP4 or MOV container without transcoding.

I will admit that I thought you were trying to send the stream and not receive the stream and save it. But when you have problems it is still better to separate the functions to see exactly what the problem is.

In this case, depending on the resolution of coarse, it would probably better to transcode into another format. If you want a QT compatible file choose mp4v, mp4a and mp4 for the encapsulation method. Be sure to name the file anything.mp4 and save it to a directory you can find.

There are several possibilities:

1. You are still not understanding the transcode functions and you are not going to get around this one until you learn to do this and prove it with a local file using a similar source.

2. The stream is copy protected and VLC does not support DRM.

3. Your machine may not be powerful enough to stream and transcode h.264 at the same time. This is why I recommended another format.

You are not taking the time to work out your own problems by using the suggestions but instead relying on someone else to solve it for you. In my opinion this is not how life works, assuming you really want a proper end result.

I try to never force but only suggest. Even when asked for an opinion, I often will find something good to say before offering any possible suggestions to get a response before suggesting as some only want a pat on the back and not any support. But at the same time nothing is really appreciated unless you work for it. This is part of the learning experience for us and builds satisfaction and experience in coping with the next problem encountered. I case you didn't notice, I also try to admit to my mistakes and try to correct them rather than hide them or be stubborn in standing by a obvious error on my part.

I think you will find that the transcode functions do work in VLC, but depending on the source and your understanding of the functions perhaps the end result will not be as expected as there are to many combinations and standards that are source sensitive and format dependent for any given container.

However I did confirm last night that a H.264 with aac source could be transcoded into a h.264 with aac into a mp4 container. I was surprised when I could not copy it into the mp4 container, but keep in mind that there is no purpose for this exercise other than its possible use in streaming and even then because of the overhead (CPU goes to 100% for 720p for me) it is not likely to work well in this situation. Therefore I suggested a easier and still compatible format that will perform the same purpose.

Well, I tried other formats such as MPEG-4, I can stream out, I can transcode and I can copy it to a MPEG-4 file.

The original H.264 files are not big in size (e.g. video avc1, 394Kbps, size 176*144; audio AAC LC, 56Kbps, ...). I can stream them out without problem. As far as copying (saving) to H.264 file, I think it might just be a small bug.

My question is: how far from streaming (since I can play in real-time the streamed H.264 file) to saving/copying to a file (like H.264 file) without doing transcoding, just save it. Which part of source code I need to start with? Hope some can point it out.

I really appreciate those suggestions from DJ! I need to dig into the source code to figure out. Any further suggestions are very appreciated.

Considering you seem to be so up on this and ready to jump into the code, you don't happen to have the CCCP codec pack or Haali media splitter installed do you???

Wei,

I am in the same situation (i.e. want to write to MP4 directly from H.264 w/o transcoding). Did you have any success in figuring out what was missing in the code?

Thanks

The problem with saving H264 RTSP, is that RTP only specifies the PTS of video frames, and not the DTS (decoding timestamp). This means that this DTS needs to be reconstructed.

For mpeg4 and a few other formats, this is implemented. Unfortunately, for H264, it is EXTREMELY complicated to reconstruct this value.
It is not implemented yet, and most likely will not be for a while.

Thank you very much for your answer, DJ.

I'm not sure I understand every bit of the decoding process, since I'm fairly new in the field (i.e. thanks for your patience in advance ). Here are some more questions:

How does the playback works, then? Doesn't the h264 de-packetizer need to extract decoding time information?

Also, does the DTS need to be exact when stored in the MP4 file, or is it possible to find an approximation more easily (from the PTS maybe)?

Thanks a lot,
hacoLA

The information arrives in the order it is supposed to be decoded. The problem is that we need to internally map that to a time in the same timebase of the presentation time. It is extremely difficult to do especially in H264. It really is too difficult to explain. We are talking about a codec that is described in a 1000 page document.

The problem is that we need to internally map that to a time in the same timebase of the presentation time.

VLC is obviously capable of playing the live stream. How does it determine the DTS then? Does it have to?

We are talking about a codec that is described in a 1000 page document.

I thought there could be a way of doing that without knowing anything about the codec (i.e. payload format of RTP stream), like it can be done with others. Guess not. Anyway, thanks for your answers.

Where can I find more information about this? Is it in the ISO/IEC 14496-10 AVC specification?

For decoding now, it takes everything in the order it arrives, and "waits" untill it has sufficient information. Then decodes a frame, and puts it into a holding pattern for the PTS time.

However for storing in most files you need a more accurate time, and more important, a time in the same timebase as PTS. Which is a problem, since internally in vlc, there is no active relation between those. They are assumed to be there always.

I guess I'm a little confused with this timing information. Correct me if I'm wrong:

- PTS (presentation time stamp): time instant at which the corresponding packet should be presented to the viewer (i.e. it must be decoded by that time).
- CTS (composition time stamp): time instant at which the corresponding packet was sampled from the original stream. In this case, it is also equal to the RTP time stamp, and to the PTS (as you mentioned).
- DTS (decoding time stamp): time instant at which the corresponding packet should be given to the decoder

From these, we see that DTS must be <= CTS so the decoded packet can be ready to be presented in time.

(these are my definitions, btw, so I might be wrong!)

For the purpose of my better understanding of the problem let's assume that, at any point in time in the stream, all the information needed to decode a frame is included within a window of 5 seconds of streaming (I don't know if there's a way to find this exact number, but let's set it to 5 arbitrarily). In other words, once we have received a packet, we know that 5 seconds later we are sure to have all the information we need to decode it. Our goal is to infer the DTS from the PTS.

So, for each packet that we store in the MP4 file, we:
- set its DTS to PTS
- set its CTS to PTS+5 seconds

Then it is guaranteed that the decoder will have all the necessary information to decode each packet, in time for their own CTS. Right?

As always, your answers are very much appreciated!!

One of the problems is that in H264 there are no strict limits on this.
You can have an almost arbitrary number or frames depending upon eachother. This means that theoretically, you might have to buffer 30seconds for instance before you can reconstruct. VLC is not an editor. It is a live and realtime system on which you cannot easily impose such restrictions. For the decoder there is no problem here, because only the ORDER is important. For writing files however you also need the TIME, which can take an unknown amount of time to calculate.

Ergo, it's difficult. Probably not impossible, but not as easy as with previous formats either.

One of the problems is that in H264 there are no strict limits on this.

I see, yes that is definitely a problem in that case.

For writing files however you also need the TIME, which can take an unknown amount of time to calculate.

To summarize, the buffering for 30sec would potentially work (not in VLC because of its live streaming nature, but maybe in another application), but there is no guarantee that the reconstructed timings will be correct.

It's kinda weird that the MPEG-4 people didn't think about this issue, with, as you mentioned, all these previous formats which make this process easy? It seems like the only way to properly record an H264 stream is by decoding and re-encoding it? Doesn't make a lot of sense to me, and these additional heavy computations could have been avoided so easily... Anyway. Thanks so much for all your answers.

Hi,
Does the latest release of VLC support recording H.264 RTP stream?
Warm Regards,
prb