View Full Version : x264 ==> Mplayer
koliva
22nd April 2013, 16:59
Currently I am using SMPlayer but it shows such an image (see attachment) on the screen. I can recognize the head of the guy in this image but it is far from its original :) Could you please tell me where I am doing wrong?
MasterNobody
22nd April 2013, 17:55
Could you please tell me where I am doing wrong?
You don't provide enough information on the problem. Your code sample is too short and show only one aspect of what you do (there are also code for how you initialize libx264 and how your write resulting file from buffer). Also in such questions it is good to provide short encoded samples so anyone can looks what you have as output (not some not useful screenshots).
koliva
23rd April 2013, 11:03
You don't provide enough information on the problem. Your code sample is too short and show only one aspect of what you do (there are also code for how you initialize libx264 and how your write resulting file from buffer). Also in such questions it is good to provide short encoded samples so anyone can looks what you have as output (not some not useful screenshots).
Here is the file where I dumped my encoded data.
I must say that the encoded data can be decoded and shown on the screen using libavcodec. So there is no problem with the encoded bitstream. The only problem might be that I need to set some extra parameters so that my dumped file can be playable with SMPlayer. Can you comment on this?
LoRd_MuldeR
23rd April 2013, 11:05
What do you output? Raw H.264 bitstream? Or some container like MKV or MP4?
Does re-muxing your stream, e.g. with MP4Box (MP4) or MKVToolnix (MKV) make any difference?
koliva
23rd April 2013, 11:43
What do you output? Raw H.264 bitstream? Or some container like MKV or MP4?
Does re-muxing your stream, e.g. with MP4Box (MP4) or MKVToolnix (MKV) make any difference?
I just dump in a binary file. It is raw H.264 stream. I use no container. Preferably I don't want to use any container since this is only for testing purposes. However, if there is no other way, I will do it. I haven't tried the re-muxing tools that you mentioned. I am going to have a look.
f.open(QIODevice::Text | QIODevice::WriteOnly | QIODevice::Append);
You're using Windows and opening the file in text mode. Bad idea:
http://qt-project.org/doc/qt-4.8/qiodevice.html#OpenModeFlag-enum
QIODevice::Text 0x0010
When reading, the end-of-line terminators are translated to '\n'. When writing, the end-of-line terminators are translated to the local encoding, for example '\r\n' for Win32.
It would also be a bit more efficient to keep the file open while writing the stream instead of reopening for every frame.
LoRd_MuldeR
23rd April 2013, 21:04
It would also be a bit more efficient to keep the file open while writing the stream instead of reopening for every frame.
...and much less error-prone.
koliva
24th April 2013, 08:59
You're using Windows and opening the file in text mode. Bad idea:
http://qt-project.org/doc/qt-4.8/qiodevice.html#OpenModeFlag-enum
It would also be a bit more efficient to keep the file open while writing the stream instead of reopening for every frame.
That's perfect. How could I miss the text mode :stupid:
Have a great day.
vBulletin® v3.8.11, Copyright ©2000-2026, vBulletin Solutions Inc.